A method, system and device for filtering bluetooth data packets and a storage medium

Abstract

The application discloses a filtering method, system and device of a Bluetooth data packet and a storage medium. The method comprises the following steps: receiving a plurality of data packets through a digital circuit, wherein the data packets comprise device address information; performing filtering processing on the data packets according to configuration information, and deleting data packets that do not meet the conditions; wherein the configuration information is provided by a firmware program; the configuration information comprises a protocol data unit type and an effective data packet length; searching for a filtering information list, deleting data packets corresponding to device address information that does not meet the conditions, and obtaining filtered data packets; and the filtering information list is provided by an SRAM. The embodiment of the application is beneficial to reducing power consumption in a data packet receiving process and improving data packet analysis efficiency. The method can be widely applied to the technical field of Bluetooth.

Description

Technical Field

[0001] This application relates to the field of Bluetooth technology, and in particular to a method, system, apparatus and storage medium for filtering Bluetooth data packets. Background Technology

[0002] With the development of network communication technology, Bluetooth communication technology has been widely used. During Bluetooth data packet transmission, interference from other low-power Bluetooth device data packets may occur. Therefore, when receiving Bluetooth data packets, it is necessary to filter out data packets from other devices. One approach is to implement the data packet filtering function in the firmware; however, this method consumes a lot of power and has low scanning efficiency. Alternatively, the data packet filtering function can be implemented in digital circuitry, but this method is also inefficient. Summary of the Invention

[0003] The purpose of this application is to at least partially solve one of the technical problems existing in the prior art.

[0004] Therefore, the purpose of this invention is to provide an efficient method, system, apparatus, and storage medium for filtering Bluetooth data packets.

[0005] To achieve the above-mentioned technical objectives, the technical solutions adopted in the embodiments of this application include:

[0006] On the one hand, embodiments of this application provide a method for filtering Bluetooth data packets, including the following steps:

[0007] This application provides a Bluetooth data packet filtering method, comprising: receiving a plurality of data packets via digital circuitry, the data packets including device address information; filtering the data packets according to configuration information, deleting data packets that do not meet the conditions; wherein the configuration information is provided by firmware; the configuration information includes protocol data unit type and valid data packet length; searching a filtering information list, deleting data packets corresponding to device address information that does not meet the conditions, and obtaining filtered data packets; the filtering information list is provided by SRAM. This application embodiment receives data packets via digital circuitry and then filters the data packets through interaction with firmware and SRAM. Receiving filtered data packets via digital circuitry reduces power consumption and improves data packet parsing efficiency. Therefore, this application embodiment helps reduce power consumption during data packet reception while improving data packet parsing efficiency.

[0008] In addition, the Bluetooth data packet filtering method according to the above embodiments of this application may also have the following additional technical features:

[0009] Furthermore, the Bluetooth data packet filtering method of this application embodiment further includes:

[0010] If the device address information is RPA and the device address information is not included in the filter information list, the device address information is parsed and the parsing result is written into the filter information list.

[0011] Further, in one embodiment of this application, the filtering information list includes a first sub-table and a second sub-table; wherein, the device address information in the first sub-table is used to characterize address information that can be successfully resolved, and the device address information in the second sub-table is used to characterize address information that cannot be successfully resolved; the method further includes:

[0012] If the device address information is the address of the peer device, the peer IPK is retrieved from the first sub-table to parse the device address information;

[0013] Alternatively, if the device address information is a local device address, the local IPK is retrieved from the first sub-table to parse the device address information;

[0014] If any IPK in the first sub-table fails to successfully parse the device address information, the device address information is written into the second sub-table.

[0015] Alternatively, if an IPK exists in the first sub-table that can successfully parse the device address information, the device address information is written into the first sub-table.

[0016] Furthermore, in one embodiment of this application, the method further includes the following steps:

[0017] If a periodic broadcast packet is received, the address information of the periodic broadcast packet is compared with the specified address information;

[0018] If the comparison result is unsuccessful parsing, the address information of the periodic broadcast packet is parsed using the address information in the third sub-table; the filter information list includes the third sub-table, which is established according to relevant protocols.

[0019] Furthermore, in one embodiment of this application, the method further includes:

[0020] The first instruction is received through the firmware program;

[0021] If the first instruction is a form instruction, the firmware program performs read and write operations on the relevant sub-tables of the filter information list.

[0022] If the first instruction is a data packet instruction, the configuration information is created through the firmware program, and the CPU is controlled to enter a sleep state.

[0023] Furthermore, in one embodiment of this application, the method further includes:

[0024] If the data packet reception is complete, an interrupt is generated by the digital circuit and the interrupt is sent to the firmware program.

[0025] Furthermore, in one embodiment of this application, the method further includes:

[0026] The CPU is woken up by digital circuitry, and the CPU executes the firmware program to process the filtered data packets.

[0027] On the other hand, embodiments of this application propose a Bluetooth data packet filtering system, including:

[0028] The first module is used to receive several data packets via digital circuitry, the data packets including device address information;

[0029] The second module is used to filter the data packets according to the configuration information and delete data packets that do not meet the conditions; wherein, the configuration information is provided by the firmware program; the configuration information includes the protocol data unit type and the effective data packet length;

[0030] The third module is used to search the filter information list, delete the data packets corresponding to device address information that does not meet the conditions, and obtain the filtered data packets; the filter information list is provided by SRAM.

[0031] On the other hand, embodiments of this application provide a Bluetooth data packet filtering device, including:

[0032] At least one processor;

[0033] At least one memory for storing at least one program;

[0034] When the at least one program is executed by the at least one processor, the at least one processor implements any of the Bluetooth packet filtering methods described above.

[0035] On the other hand, embodiments of this application provide a storage medium storing a processor-executable program, which, when executed by a processor, is used to implement any of the Bluetooth data packet filtering methods described above.

[0036] This application embodiment receives data packets via digital circuitry and then filters these packets through interaction with firmware and SRAM. Receiving filtered data packets via digital circuitry reduces power consumption and improves data packet parsing efficiency. Therefore, this application embodiment helps reduce power consumption during data packet reception while simultaneously improving data packet parsing efficiency. Attached Figure Description

[0037] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the following description is provided with accompanying drawings of the relevant technical solutions in the embodiments of this application or the prior art. It should be understood that the accompanying drawings described below are only for the purpose of clearly illustrating some embodiments of the technical solutions in this application. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0038] Figure 1 A flowchart illustrating an embodiment of the Bluetooth data packet filtering method provided in this application;

[0039] Figure 2 A schematic diagram of the structure of one embodiment of the Bluetooth data packet filtering system provided in this application;

[0040] Figure 3 Example diagram of an embodiment of the protocol data unit type provided in this application;

[0041] Figure 4 A schematic diagram of the structure of one embodiment of the filter information list provided in this application;

[0042] Figure 5 A schematic diagram of another embodiment of the filter information list provided in this application;

[0043] Figure 6 A flowchart illustrating an embodiment of filtering based on configuration information provided in this application;

[0044] Figure 7 A flowchart illustrating one embodiment of local address filtering provided in this application;

[0045] Figure 8 A flowchart illustrating one embodiment of the maintenance filter information list provided in this application;

[0046] Figure 9 A flowchart illustrating one embodiment of peer address filtering provided in this application;

[0047] Figure 10 A flowchart illustrating one embodiment of the firmware program provided in this application;

[0048] Figure 11 A schematic diagram of the structure of one embodiment of the Bluetooth data packet filtering system provided in this application;

[0049] Figure 12 This is a schematic diagram of one embodiment of the Bluetooth data packet filtering device provided in this application. Detailed Implementation

[0050] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application. The step numbers in the following embodiments are set only for ease of explanation, and there is no limitation on the order between the steps. The execution order of each step in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0051] Bluetooth protocols specify that BLE uses a 6-byte Bluetooth device address to determine if a received data packet belongs to the target device. The Resolvable Private Address (RPA) within the device address requires address resolution to determine if it is indeed the target device. Furthermore, the protocols define fields such as PDU type, payload length, SID, DID, and CRC in the BLE data packet. These fields can all be used as conditions for data packet filtering during protocol implementation. Data packet filtering methods in related technologies are broadly classified into two types.

[0052] The first method is to implement the packet filtering function in the firmware. When the BLE controller receives a packet, the digital circuit does not care whether the packet is correct. It receives all the packets and puts the data in SRAM. When the central processing unit (CPU) starts working after the packets are received, the packets in SRAM are filtered according to the protocol requirements.

[0053] The second method is to implement the data packet filtering function in the digital circuit. The filtering conditions are pre-written into the SRAM using the firmware program. The digital circuit determines whether the filtering conditions are met when receiving data packets. If the conditions are not met, it stops receiving and discards the current data packet.

[0054] The two methods above have the following drawbacks:

[0055] 1. High power consumption. For Method 1, which involves the digital circuit receiving all data packets and then waking up the CPU to filter packets through the firmware, the hardware needs to receive the entire data packet completely, and the CPU processing time is relatively long, resulting in high power consumption.

[0056] 2. The scanning success rate is low. Receiving a packet from a non-target device completely wastes at least the duration of the Bluetooth signal, during which time data packets from the target device cannot be received.

[0057] 3. Address resolution is slow. Method 2 requires CPU intervention for address resolution when an RPA is received in scan mode, which is slower.

[0058] The problem addressed by this application is how to filter out data packets from other Bluetooth Low Energy devices in a short time and with low power consumption, while correctly receiving the target device's data packets, when there is interference from other Bluetooth Low Energy devices in the air. This application provides richer filtering functions, utilizes digital circuitry for address resolution, reduces CPU involvement time during data packet filtering, lowers power consumption, and immediately discards non-target data packets and re-receives them, thereby improving data packet filtering speed and scanning success rate.

[0059] The Bluetooth data packet filtering method and system proposed according to the embodiments of this application will be described in detail below with reference to the accompanying drawings. First, the Bluetooth data packet filtering method proposed according to the embodiments of this application will be described with reference to the accompanying drawings.

[0060] Reference Figure 1 This application provides a method for filtering Bluetooth data packets. This method can be applied to a terminal, a server, or software running on either a terminal or server. The terminal can be a tablet, laptop, desktop computer, etc., but is not limited to these. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The Bluetooth data packet filtering method in this application mainly includes the following steps:

[0061] S100: Receives several data packets via digital circuitry, the data packets including device address information;

[0062] S200: Based on the configuration information, it filters data packets and deletes those that do not meet the requirements; the configuration information is provided by the firmware program; the configuration information includes the protocol data unit type and the effective data packet length;

[0063] S300: Search the filter information list, delete the data packets corresponding to device address information that does not meet the conditions, and obtain the filtered data packets; the filter information list is provided by SRAM.

[0064] In some possible implementations, embodiments of this application employ a collaborative approach involving firmware, digital circuitry, and SRAM to filter Bluetooth data packets. The filtering includes PDU type filtering, payload length filtering, device address filtering, periodic broadcast synchronization address filtering, ADI field filtering, and privacy protection filtering. The digital circuitry automatically resolves resolvable addresses. The firmware is used to configure packet filtering parameters, process filtering results, and manage the list. The SRAM contains a list structure of filtering information conforming to the functions of this application, storing device address, RPA, IRK, and other related information. The digital circuitry comprises a preprocessor (PPC), a filter, and an address resolver (AR), which respectively execute the preprocessing and unpacking, packet filtering, and address resolution functions.

[0065] Among some possible implementations, refer to Figure 2 The diagram shown is a structural schematic of the filtration system provided in this application. Figure 1 As shown, the system structure of this invention includes three parts: firmware program, digital circuit, and filter information list. The functions of each part are as follows:

[0066] The firmware is primarily used to manage the contents of each sub-list in the filtering information list, enable digital circuits, and configure the registers required by the digital circuits. The digital circuits are mainly used to parse data packets, compare the packet content with the register configuration information, and perform packet filtering according to the protocol. The filtering information list, stored in SRAM, contains information such as device addresses, which serves as the basis for hardware to perform data packet filtering. Based on this filtering system, the Bluetooth data packet filtering method provided in this application may include the following steps: Before receiving a data packet, the firmware writes information such as the BLE state (broadcast / scan / initiate state, etc.), the PDU Type of the data packet to be received, the local device address, the peer device address, and the filtering strategy into the relevant registers, enables the digital circuits, and puts the CPU into sleep mode. When receiving data packets, the digital circuitry uses register information to determine if the received packet meets the requirements. It then checks the filter information list to see if the device address matches the filtering policy. Packets that meet the criteria are received normally, while those that don't are discarded. If the received packet's device address is RPA and not found in the list, it's written to the AR FIFO for the AR module to resolve. Successful resolution results in the packet being written to the resolve list; unsuccessful resolution results in the report list. After packet reception, the CPU is woken up to execute the firmware program for packet processing. Furthermore, the firmware program manages the filter information list using HCI commands.

[0067] It is understood that the configuration information is used to provide packet filtering parameters. Specifically, the configuration information may include: device status, expected PDU Type, expected peer device address, privacy protection policy, filtering policy, expected SID and DID fields, and other related information. It is also understood that the following information should be written to the register when configuring the filtering parameters to provide the configuration information:

[0068] Expected Protocol Data Unit Type (PDU type): Based on the current BLE behavior configuration, the allowed PDU types to be received are, such as... Figure 3 As shown, exemplarily, when a device is in broadcast mode and has finished sending the ADV_IND broadcast packet and is ready to receive data packets, it is allowed to receive SCAN_REQ and CONNECT_IND packets, and the PDU type should be set to 0b0011 or 0b0101. It is understood that... Figure 3 The protocol data unit types shown are exemplary examples, and this application does not impose any specific limitations.

[0069] Expected effective packet length: This includes the maximum and minimum lengths. The parameters are configured in the register according to the length requirements for different scenarios specified in the protocol. For example, in traditional scanning, the maximum length should be set to 37 and the minimum length should be set to 0.

[0070] Filter policy: The filtering policy originates from the HCI command. HCI will issue different filtering policies in broadcast, scan and initiate states. The filtering policy will combine the device addresses in the filter information list to determine which device PDUs are allowed to be received.

[0071] In some possible implementations, the digital circuit provided in this application mainly includes three modules: a preprocessor (PPC), a filter (FILTER), and an address resolver (AR). The functions of each module are as follows:

[0072] PPC: Used to filter PDUs based on the expected PDU type and payload length range set in advance by the software; unpack the PDUs, extract internal signals and addresses, and provide them to the FILTER.

[0073] FILTER: Performs a table lookup based on address type and filtering strategy to filter out PDUs from addresses that should not be received; when a resolvable address that cannot be found is received, it is passed to the AR module for parsing.

[0074] AR: Selects the resolvable address to write the FILTER to the AR FIFO based on the configuration, or the resolvable address configured by the software; maintains the resolve list and report list.

[0075] In some possible implementations, this application provides a filtering information list via SRAM. This filtering information list contains six lists: resolve list, white list, black list, duplicated list, periodic list, and report list. The memory structure of each list is as follows: Figure 4 As shown, the structure of address is as follows: Figure 5 Therefore, this application embodiment further includes the step of: constructing a filtering information list, which includes several sub-tables. The device address information in the first sub-table is used to represent address information that can be successfully resolved, the device address information in the second sub-table is used to represent address information that cannot be successfully resolved, and the third sub-table is established according to relevant protocols. The first sub-table includes local IPK bits, peer IPK bits, local RPA bits, and peer PRA bits. Each bit is used to identify the device address information stored in the filtering information list. For example, the description of each field of address and the existence list are shown in Table 1; the definition of each list and read / write permissions are shown in Table 2. Through the definitions in Table 1 and Table 2, it is convenient for the filtering information list to store and retrieve data, which helps to save storage space and improve read / write efficiency.

[0076]

[0077] Table 1. Meaning and List of Fields in the Address Table

[0078]

[0079] Table 2 defines the lists and their read / write permissions.

[0080] Optionally, in one embodiment of this application, the method further includes:

[0081] If the device address information is RPA and the device address information is not included in the filter information list, the device address information is parsed and the parsing result is written into the filter information list.

[0082] Optionally, in one embodiment of this application, the filtering information list includes a first sub-table and a second sub-table; wherein, the device address information in the first sub-table is used to characterize address information that can be successfully resolved, and the device address information in the second sub-table is used to characterize address information that cannot be successfully resolved; the method further includes:

[0083] If the device address information is the address of the peer device, retrieve the peer IPK from the first sub-table to parse the device address information;

[0084] Alternatively, if the device address information is a local device address, retrieve the local IPK from the first sub-table to parse the device address information;

[0085] If any IPK in the first sub-table fails to resolve the device address information, the device address information is written into the second sub-table.

[0086] Alternatively, if IPK exists in the first sub-table and can successfully resolve device address information, write the device address information into the first sub-table.

[0087] In some possible implementations, the operating logic of the PPC module in the digital circuit refers to Figure 6 As shown, for example, the process of filtering data packets according to the configuration information can be as follows: First, compare the relevant fields of the received data packet with the PDU type and payload length set in the register. If they do not match, the packet is rejected. If the data packet contains TargetA and is not a resolvable address, check if it matches the local address. If they do not match, the packet is discarded. Then, the information is sent to the FILTER by parsing the contents of each field of the data packet. Finally, the FILTER is enabled to start working. Specifically, the information for data packet parsing is shown in Table 3. The information in Table 3 can be used for subsequent processing by the FILTER module.

[0088] signal name Bit width describe peer_check_en [0:0] Does the data packet contain the peer's address? local_check_en [0:0] Does the data packet contain a local address? syncinfo_vld [0:0] Does it have a syncinfo field? rx_adi [15:0] The value of the adi field in the received packet rsv_pdu_type [3:0] PDU type of received data packet pp_dvce_addr [47:0] Addresses to be parsed and filtered pp_dvce_addr_type [0:0] Address types to be parsed and filtered aux_adv_mode [1:0] The adv mode field of extended type PDU aux_adi_flag [0:0] Does the adi field exist? aux_drc_flag [0:0] Is the received package an extended targeted broadcast?

[0089] Table 3 Information extracted from PPC unpacking

[0090] In some possible implementations, the FILTER module includes local address filtering; see the details below. Figure 7 As shown in the diagram, this process only needs to be entered when TargetA is an RPA. The process involves searching the first sub-table (resolvelist) for a match with the local RPA. This mainly involves comparing TargetA in the package with the local RPA in the resolvelist. If a match is found, the step is considered successful.

[0091] In some possible implementations, the AR module in the digital circuit is used for maintaining the first sub-table and the second sub-table (report list). Specifically, the AR module's workflow is as follows: Figure 8As shown, the process is as follows: IRKs are retrieved sequentially from the resolvelist (peer IRK for resolving peer device addresses, local IRK for resolving local device addresses), and each RPA is parsed one by one. If a particular IRK successfully resolves an RPA, that RPA is added to the resolvelist to replace the previous RPA. If all IRKs fail to resolve an RPA, it is added to the report list. In the diagram, the address resolution method is based on AES calculation.

[0092] Optionally, in one embodiment of this application, the method further includes the following steps:

[0093] If a periodic broadcast packet is received, compare the address information of the periodic broadcast packet with the specified address information;

[0094] If the comparison result is unsuccessful, the address information of the periodic broadcast packet is parsed using the address information in the third sub-table; the filter information list includes the third sub-table, which is established according to the relevant protocol.

[0095] In some possible implementations, the FILTER module of the digital circuit includes two modes: local device address filtering and peer device address filtering. The peer device address filtering process is as follows: Figure 9 The relevant nodes in the diagram are explained below:

[0096] Pass: This indicates that the data packet meets the current filtering criteria and can proceed to the next step.

[0097] Discard: This means that the data packet does not meet the current filtering conditions. You can stop receiving the current data packet immediately. In a scanning scenario, after discarding the current data packet, you can re-receive broadcast packets without waking up the CPU.

[0098] Upon receiving a periodic broadcast packet: the syncinfo_vld signal in the table is used to determine if the SID and address of periodic sync need to be filtered when the syncinfo_vld signal is generated and the register is configured as periodic_en. The actual ID address will be parsed and matched with the specified address or the address in the periodic list.

[0099] Compare with the specified address: The Host determines this, and the firmware program writes it into the register.

[0100] Successfully compared with the last received address: The digital circuit records the address of the peer device in a register every time it receives a data packet, so that it can be compared in this scenario.

[0101] Resolve list lookup: The criteria are that the RPA is in the resolve list and the res_ind, mem_si, and other fields meet the expectations.

[0102] White list filtering, dual-list filtering, and black list filtering: Whether filtering is needed depends on the BLE status and filtering strategy. The filtering method is to check if the device address exists in the corresponding list.

[0103] Write to AR FIFO: Write the RPA into the FIFO of the AR module. When the FIFO is not empty, the AR module will start resolving the resolvable address.

[0104] Optionally, in one embodiment of this application, the method further includes:

[0105] Receive the first instruction via firmware program;

[0106] If the first instruction is a form instruction, the firmware program performs read and write operations on the relevant sub-tables of the filter information list.

[0107] If the first instruction is a data packet instruction, the firmware program creates configuration information and controls the CPU to enter a sleep state.

[0108] In some possible implementations, the firmware program in this application embodiment mainly includes common functions: configuring registers related to packet filtering parameters, processing digital circuit filtering results, and managing all lists except the report list. Its workflow is as follows: Figure 10 As shown in the diagram, some nodes are described as follows: Configure filter packet data parameters; the specific configuration of the filtering strategy is shown in Table 3 above. An interrupt is generated upon completion of packet reception: the interrupt is generated by the digital circuitry. Read and write SRAM to manage the filter information list: manage the list according to the specific command and the principles in Tables 1 and 2.

[0109] In some possible implementations, the filtering strategy configuration is shown in Table 4, specifically:

[0110] Device status: Current device status, including initiating state, scanning state, broadcast state, etc.;

[0111] Whether to enable privacy protection: This configuration determines whether to look up the corresponding ID address by address resolution or list lookup when receiving an RPA;

[0112] Anticipated ADI: Writes the required secondary broadcast ADI field to the register in advance, and allows reception only when the ADI matches (this function is optional).

[0113] Specify peer address: In the initiation state or during periodic synchronization, the filter policy can be set to specify the receiving peer address. In both states, the filter policy can be used to determine whether to receive PDUs with fixed addresses only.

[0114]

[0115] Table 4 Filter policy configuration and scenarios

[0116] In some possible implementations, the firmware program in this embodiment also manages the filter list information. Specifically, the firmware program's management of the list in the filter information list depends on receiving HCI commands from the Host, and the operations of each table are as follows:

[0117] Resolve list: Perform read and write operations on the list according to the add, remove, clear, and read commands of HCI.

[0118] white list: performs read and write operations on the filter accept list based on the add, remove, clear, and read commands of HCI.

[0119] black list: Add the device to the list after establishing a connection with the peer device, and remove it after disconnection.

[0120] Duplicated list: During scanning, the scanned packets are added to this list based on the scanning parameters. The list is cleared after the scan is complete.

[0121] Periodic list (third sub-list): Read and write operations are performed on this list according to the add, remove, clear, and read commands of HCI.

[0122] Optionally, in one embodiment of this application, the method further includes:

[0123] If the data packet reception is complete, the digital circuit generates an interrupt and sends the interrupt to the firmware program.

[0124] Optionally, in one embodiment of this application, the method further includes:

[0125] The CPU is woken up by digital circuitry, and the CPU executes the firmware program to process the filtered data packets.

[0126] In some possible implementations, interrupting and waking up the CPU alleviates the problem of the CPU being in an on state throughout the entire data packet transmission process, which helps to reduce the energy consumption of data packet filtering.

[0127] In summary, this application filters BLE Bluetooth data packets through the interactive collaboration of firmware programs, digital circuits, and a filtering information list. The filtering content includes PDU type filtering, payload length filtering, device address filtering, periodic broadcast synchronization address filtering, ADI field filtering, privacy protection filtering, and resolvable address resolution. This achieves the received data packet filtering function. Furthermore, this application provides a storage structure for each list for device filtering, which reduces space waste while fulfilling the functionality. Additionally, the report list in this application is used to store unresolved RPAs, preventing repeated resolution of the same RPA and improving address resolution speed.

[0128] Based on this, the filtering method in this application embodiment has lower power consumption and higher scanning success rate. Specifically, in this application, the packet filtering work is mainly completed by digital circuits with less CPU involvement, resulting in significantly lower power consumption compared to related technologies. Furthermore, in scanning scenarios, it can quickly discard non-target device packets for rescanning, improving the scanning success rate. Simultaneously, the embodiments of this application offer rich functionality, specifically covering various packet filtering requirements such as device filtering and privacy protection as mandated by relevant protocols. In addition, the method in this application embodiment features fast address resolution and a small digital circuit area. Specifically, the embodiments of this application combine the device filtering and privacy protection functions of relevant protocols, and RPA resolution can be autonomously completed by digital circuits, improving address resolution speed and reducing digital circuit area compared to related technologies. It should be noted that the method and system provided in this application have completed unit verification and integration verification in relevant projects, and the above-mentioned effects are expected to be achieved.

[0129] Secondly, refer to the appendix Figure 11 This application describes a Bluetooth data packet filtering system according to an embodiment of the present application.

[0130] Figure 11 This is a schematic diagram of a Bluetooth data packet filtering system according to an embodiment of this application. The system specifically includes:

[0131] The first module 111 is used to receive several data packets through digital circuits, the data packets including device address information;

[0132] The second module 112 is used to filter data packets according to configuration information and delete data packets that do not meet the conditions; wherein, the configuration information is provided by the firmware program; the configuration information includes protocol data unit type and effective data packet length;

[0133] The third module 113 is used to search the filter information list, delete the data packets corresponding to the device address information that does not meet the conditions, and obtain the filtered data packets; the filter information list is provided by SRAM.

[0134] It is evident that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0135] Reference Figure 12 This application provides a Bluetooth data packet filtering device, comprising:

[0136] At least one processor 410;

[0137] At least one memory 420 is used to store at least one program;

[0138] When at least one program is executed by at least one processor 410, the at least one processor 410 implements a Bluetooth packet filtering method.

[0139] Similarly, the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0140] This application embodiment also provides a computer-readable storage medium storing a program executable by a processor 410, which, when executed by the processor 410, is used to perform the above-described Bluetooth data packet filtering method.

[0141] Similarly, the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0142] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0143] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated to the contrary, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of conventional technology for an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0144] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several programs to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0145] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequential list of executable programs for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, a program execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can retrieve and execute a program from or in conjunction with such a program execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit a program for use by or in conjunction with a program execution system, apparatus, or device.

[0146] More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0147] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable program execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0148] In the foregoing description of this specification, the references to terms such as "one embodiment," "another embodiment," or "some embodiments," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0149] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

[0150] The above is a detailed description of the preferred embodiments of this application, but this application is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A method for filtering Bluetooth data packets, characterized in that, Includes the following steps: A digital circuit receives several data packets, the data packets including device address information; the digital circuit includes a preprocessor, a filter, and an address resolver. Based on the configuration information, the data packets are filtered, and data packets that do not meet the conditions are deleted; wherein, the configuration information is provided by the firmware program; the configuration information includes the protocol data unit type and the effective data packet length; The filter information list is searched, and data packets corresponding to device address information that do not meet the conditions are deleted to obtain filtered data packets; the filter information list is provided by SRAM. The step of filtering the data packets according to the configuration information and deleting data that does not meet the conditions includes: The preprocessor compares and matches the field information of the received data packet with the protocol data unit type and effective data packet length set in the firmware program, and determines the matching result; If the match result is unsuccessful, the data packet is discarded; If the matching result is successful, an address comparison match is performed. If the address comparison match is successful, the field information obtained from parsing the data packet is transmitted to the filter; otherwise, the data packet is discarded.

2. The Bluetooth data packet filtering method according to claim 1, characterized in that, The method further includes: If the device address information is RPA and the device address information is not included in the filter information list, the device address information is parsed and the parsing result is written into the filter information list.

3. The Bluetooth data packet filtering method according to claim 2, characterized in that, The filtering information list includes a first sub-table and a second sub-table; wherein, the device address information in the first sub-table is used to represent address information that can be successfully resolved, and the device address information in the second sub-table is used to represent address information that cannot be successfully resolved; the method further includes: If the device address information is the address of the peer device, the peer IPK is retrieved from the first sub-table to parse the device address information; Alternatively, if the device address information is a local device address, the local IPK is retrieved from the first sub-table to parse the device address information; If any IPK in the first sub-table fails to successfully parse the device address information, the device address information is written into the second sub-table; Alternatively, if an IPK exists in the first sub-table that can successfully parse the device address information, the device address information is written into the first sub-table.

4. The Bluetooth data packet filtering method according to claim 1, characterized in that, The method further includes the following steps: If a periodic broadcast packet is received, the address information of the periodic broadcast packet is compared with the specified address information; If the comparison result is unsuccessful parsing, the address information of the periodic broadcast packet is parsed using the address information in the third sub-table; the filter information list includes the third sub-table, which is established according to relevant protocols.

5. The Bluetooth data packet filtering method according to claim 1, characterized in that, The method further includes: The first instruction is received through the firmware program; If the first instruction is a form instruction, the firmware program performs read and write operations on the relevant sub-tables of the filter information list. If the first instruction is a data packet instruction, the configuration information is created through the firmware program, and the CPU is controlled to enter a sleep state.

6. The Bluetooth data packet filtering method according to claim 1, characterized in that, The method further includes: If the data packet reception is complete, an interrupt is generated by the digital circuit and the interrupt is sent to the firmware program.

7. The Bluetooth data packet filtering method according to claim 1, characterized in that, The method further includes: The CPU is woken up by digital circuitry, and the CPU executes the firmware program to process the filtered data packets.

8. A Bluetooth data packet filtering system, characterized in that, include: The first module is used to receive several data packets via digital circuitry, the data packets including device address information; the digital circuitry includes a preprocessor, a filter, and an address resolver. The second module is used to filter the data packets according to the configuration information and delete data packets that do not meet the conditions; wherein, the configuration information is provided by the firmware program; the configuration information includes the protocol data unit type and the effective data packet length; The third module is used to search the filter information list, delete the data packets corresponding to device address information that does not meet the conditions, and obtain the filtered data packets; the filter information list is provided by SRAM. The step of filtering the data packets according to the configuration information and deleting data that does not meet the conditions includes: The preprocessor compares and matches the field information of the received data packet with the protocol data unit type and effective data packet length set in the firmware program, and determines the matching result; If the match result is unsuccessful, the data packet is discarded; If the matching result is successful, an address comparison match is performed. If the address comparison match is successful, the field information obtained from parsing the data packet is transmitted to the filter; otherwise, the data packet is discarded.

9. A Bluetooth data packet filtering device, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the Bluetooth packet filtering method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a processor-executable program, characterized in that: The processor-executable program, when executed by the processor, is used to implement the Bluetooth packet filtering method as described in any one of claims 1 to 7.

Images