Method and system for multi-stage device filtering in a Bluetooth low energy device

Communication method and system

The present invention relates to a communication system. More specifically, the present invention relates to a method and system for multi-level device filtering in a Bluetooth low energy device.

Bluetooth Low Energy (BLE) is a specification that enables radio frequency communications to operate in the globally recognized 2.4 GHz industrial, scientific, and medical (ISM) frequency band. The BLE specification supports a physical layer bit rate of 1 Mbit/s across a range of 5 to 15 meters. The BLE wireless technical specification has two characteristic implementation modes, namely "dual mode" and "single mode". In dual-mode implementation, the BLE function is an additional feature in the traditional Bluetooth, namely, the Bluetooth reference rate (BR) and the Bluetooth enhanced data rate (EDR). The BLE function shares a large number of existing functions, and thus is similar to the existing Bluetooth BR/EDR-enabled devices. Ratio has the smallest cost increase. The dual-mode implementation is targeted at mobile devices and personal computers. The single-mode implementation has optimized power consumption and cost. The single-mode implementation is characterized by a lightweight link layer (LL), which provides ultra-low power idle mode operation, simple device search and reliable point-to-multipoint data transmission, and has advanced Energy saving and encryption function. The single-mode implementation is aimed at, for example, small, button-type battery-powered devices in the sports and fitness, health care, entertainment and toys, and mobile accessory product categories. BLE provides a connection between a mobile device or personal computer and a small button battery powered device.

Comparing the system of the present invention which will be introduced later in conjunction with the drawings, other limitations and drawbacks of the prior art will be obvious to those of ordinary skill in the art.

A method and/or system for multi-level device filtering in a Bluetooth low energy device, which will be described in detail below in conjunction with at least one drawing, and a more complete introduction is given in the claims.

According to one aspect, there is provided a communication method, the method comprising: in a Bluetooth Low Energy (BLE) device: filtering data packets received from an advertising BLE device, wherein the filtering utilizes the hardware of the BLE device; and if If the advertising BLE device is not recognized by the hardware filtering, the firmware of the BLE device is used to filter the data packet received from the advertising BLE device.

Preferably, the method further includes dividing device identity information for a plurality of preferred BLE devices to form a whitelist for the hardware, a whitelist for the firmware, and a whitelist for the host of the BLE device, respectively.

Preferably, the device identity information includes the private device identity information and/or non-private device identity information for a plurality of preferred BLE devices.

Preferably, the method further includes using the hardware to search for the device identity information of the advertised BLE device in the whitelist for the hardware.

Preferably, the method further includes performing a loop redundancy check on the received data packet in the hardware based on the search.

Preferably, the method further includes, based on the loop redundancy check, sending, by the hardware, a response to the received data packet to the advertising BLE device.

Preferably, the method further includes, if the device identity information of the advertising BLE device is not found by the hardware, using the firmware to search for the announcement in the whitelist for the firmware The device identity information of the BLE device.

Preferably, the method further includes inserting the device identity information of the advertised BLE device into the whitelist for the hardware if the device identity information of the advertised BLE device is found by the firmware .

Preferably, the method further includes waking up the host of the BLE device if the device identity information of the advertising BLE device is not found by the firmware.

Preferably, the method further includes waking up the host of the BLE device based on the attribute type information of the received data packet if the device identity information of the advertising BLE device is not found by the firmware.

According to one aspect, a communication system includes: one or more processors and/or circuits used in a Bluetooth Low Energy (BLE) device, the one or more processors and/or circuits are used for: Filter data packets received from an advertising BLE device, where the filtering uses the hardware of the BLE device; and if the advertising BLE device is not recognized by the hardware filtering, use the firmware of the BLE device to filter all Describe the data packet received from the advertising BLE device.

Preferably, the one or more processors and/or circuits are used to divide device identity information for multiple preferred BLE devices to form a whitelist for the hardware, a whitelist for the firmware, and a whitelist for the firmware, respectively. The whitelist of the host of the BLE device.

Preferably, the device identity information includes private device identity information and/or non-private device identity information for the plurality of preferred BLE devices.

Preferably, the one or more processors and/or circuits are configured to use the hardware to search for the device identity information of the advertised BLE device in the whitelist for the hardware.

Preferably, the one or more processors and/or circuits are configured to perform a loop redundancy check on the received data packet in the hardware based on the search.

Preferably, the one or more processors and/or circuits are configured to send a response to the notification BLE device for the received data packet by the hardware based on the loop redundancy check.

Preferably, the one or more processors and/or circuits are configured to, if the device identity information of the advertised BLE device is not found by the hardware, use the firmware to target the firmware Searching for the device identity information of the advertising BLE device in the white list.

Preferably, the one or more processors and/or circuits are configured to, if the device identity information of the advertised BLE device is found by the firmware, then the device identity information of the advertised BLE device Insert the whitelist of the hardware.

Preferably, the one or more processors and/or circuits are configured to wake up the host of the BLE device if the device identity information of the advertised BLE device is not found by the firmware.

Preferably, the one or more processors and/or circuits are configured to, if the device identity information of the advertising BLE device is not found by the firmware, based on the attribute type information of the received data packet To wake up the host of the BLE device.

The various advantages, various aspects and innovative features of the present invention, as well as the details of the embodiments exemplified therein, will be described in detail in the following description and drawings.

The following will provide some embodiments of methods and systems for multi-level device filtering in Bluetooth low energy devices. In various embodiments of the present invention, a Bluetooth Low Energy (BLE) device, such as a scanner and/or an initiator, can receive an announcement packet transmitted from an announcement BLE device (annunciator). The BLE device can be configured to use the hardware of the BLE device to filter the received advertisement packets to search for the annunciator of interest before the packet is processed. When the annunciator is not found by the hardware device, the BLE device can use the BLE device's firmware to continue to filter the received notification packets. Preferably, the device identity information of the BLE device can be divided to form a whitelist for hardware, a whitelist for firmware, and a whitelist for the host, which are used for corresponding device filtering. Device identity information may include non-private device identity, such as 48-bit Bluetooth low energy device address, and/or private device identity information, such as resolvable private address (RPA) and/or identity root key (IRK) , Used to support both confidentiality and whitelist registration. Whitelist registration is a method of blocking access to devices that are not on the whitelist. The BLE device can use the hardware used for device filtering to start searching for the annunciator of interest in order to obtain the fast response time of the annunciator of interest. When the annunciator is filtered and found by the hardware device, the BLE device can use the hardware to perform a CRC check on the received notification packet. If the CRC check passes, the hardware can send a response to the annunciator. When the annunciator is filtered and found by the firmware device, the device identity information of the annunciator can be inserted into the hardware whitelist for subsequent notification data packets from the annunciator. When the annunciator is not found using firmware device filtering, the firmware can be used to wake up the host to continue device filtering in the host according to the device configuration. For example, the firmware can be used to wake up the host based on the attribute type information of the received notification packet to process the received notification packet for the service.

FIG. 1 is a diagram of an exemplary Bluetooth low energy (BLE) communication system for supporting multi-level device filtering in a Bluetooth low energy device according to an embodiment of the present invention. 1, there is shown a Bluetooth Low Energy (BLE) communication system 100, which includes a plurality of BLE devices, in which annunciators 110-120, a scanner 130, an initiator 140, a master device 150 and a slave device 160 are shown -170.

The BLE communication system 100 is configured to use a frequency division multiple access (FDMA) scheme and a time division multiple access (TDMA) scheme to support voice and/or data communication. The communication system 100 can be configured to divide multiple physical channels, for example 40 physical channels, into an announcement channel and a data channel for each FDMA scheme. In the notification channel, the BLE device can function as an annunciator, scanner, or initiator. In the data channel, the BLE device can act as a master device or a slave device. The communication system 100 is used to utilize a TDMA-based polling scheme in the link layer communication between the master device 150 and the slave devices 160-170.

The annunciator, such as the annunciator 120, may include appropriate logic, circuits, interfaces, and/or code for periodically broadcasting announcements in the announcement channel. The annunciator 120 may be configured to advertise services and/or the availability of link layer connections within an event. The announcement event may start when an announcement packet sent by the annunciator 120 occurs. Once the peer-to-peer BLE device has established a link layer connection, the annunciator 120 will become a slave device.

The scanner 130 may include appropriate logic, circuits, interfaces, and/or codes for searching and advertising BLE devices within the device search range. The scanner 130 is used to perform passive scanning or active scanning. In passive scanning, the scanner 130 is used to monitor the notification data packet, and may not return a message to the annunciator. During active scanning, the scanner 130 may request the annunciator to transmit additional information not included in the received notification packet. The scanner 130 is used to extract, for example, an access address, from the received notification data packet, so as to obtain the device identity of the desired annunciator. The scanner 130 may be configured to search for the desired annunciator device identity in the white list for device filtering. The whitelist may include device identities of preferred BLE devices. The white list may be stored in the local memory of the scanner 130, for example. The scanner 130 may be configured to process the announcement packets received from the annunciators in the whitelist.

In an exemplary embodiment of the present invention, the scanner 130 is used to support both confidentiality and whitelist registration during device search. In this regard, the scanner 130 is used to form a whitelist for device filtering using device identities, such as 48-bit Bluetooth low energy device addresses, device class bits, and resolvable private addresses (RPA). ) And/or Identity Root Key (IRK). In an exemplary embodiment of the present invention, the scanner 130 is used to store respective white lists for different parts of the processing source. In this regard, the scanner 130 is configured to divide the device identities of the preferred BLE devices according to the corresponding processing time and/or available memory, and respectively generate or form a hardware white list, a firmware white list, and a host white list. The scanner 130 can store the hardware white list, the firmware white list, and the host white list in a dedicated local memory. In the dedicated local memory, the white list can be quickly read by the hardware, firmware, and host, respectively. .

In an exemplary embodiment of the present invention, the scanner 130 is used to perform multi-level device filtering based on the corresponding white list, using hardware, and then using firmware and a host. For example, after receiving the notification data packet, the scanner 130 is used to extract the access code from the received notification data packet. The device identity of the required annunciator for the received advertisement packet can be obtained according to the extracted access code. The scanner 130 may determine whether the desired annunciator is on the white list before processing the received notification data packet. In this regard, the scanner 130 is used to use hardware to initiate a search for the device identity of the desired annunciator. When the hardware is used to find a match for the desired annunciator in the hardware whitelist, the scanner 130 is used to perform a loop redundancy check (CRC) using the hardware to check the possibility in the received notification packet Transmission error. If the CRC check is passed, the hardware sends a response to the annunciator. When the hardware does not find a match for the desired annunciator in the hardware whitelist, the scanner 130 can use the firmware to continue searching. In this regard, the scanner 130 is used to perform a binary tree search for the desired annunciator in the firmware whitelist using firmware. When the firmware is used to find a match for the desired annunciator in the firmware whitelist, the scanner 130 is used to insert the obtained device identity of the desired annunciator into the hardware whitelist, and is used to subsequently receive notification data from the desired annunciator Bag. In order to preserve the size of the hardware whitelist, the scanner 130 may delete one or more appropriate entries in the hardware whitelist when necessary. When the firmware does not find a match for the desired annunciator in the firmware whitelist, the scanner 130 is used to wake up the host to continue searching in the host according to the device configuration.

In an exemplary embodiment of the present invention, the scanner 130 is configured to perform device filtering based on the attribute type information of the received advertisement packet. When the scanner 130 fails to use the hardware and firmware to identify the required annunciator of the received notification data packet, the scanner 130 is used, for example, to determine the received notification data packet based on the corresponding payload content stored in the hardware The attribute type information for. When the received notification packet indicates the desired attribute type information (such as the desired location and/or location-related data), the scanner 130 is used to wake up the host to continue searching for the desired annunciator in the host, or even when using hardware When neither the body nor the firmware finds a match for the required annunciator, the received notification packet is still processed in the host for the corresponding service.

The initiator 140 may include appropriate logic, circuits, interfaces, and/or codes for requesting the establishment of a link layer connection with the desired annunciator. The initiator 140 is used to monitor the traffic on the notification channel. After receiving the notice data packet of interest, the initiator 140 is used to determine or identify the required annunciator for transmitting the notice data packet of interest. The initiator 140 may be configured to process the announcement data packets from the annunciators in the whitelist. In this regard, the initiator 140 is used to perform device filtering to search for the desired annunciator, and the filtering method is similar to the multi-level device filtering method described above for the scanner 130. Once the desired annunciator is found in the whitelist, the initiator 140 may send a Connect-REQ data packet in the notification channel, where the desired annunciator (for example, annunciator 120) is being announced. The Connect-REQ data packet may include connection parameters such as frequency hopping length, and the connection parameters may be used to calculate the data channel in order to establish a link layer connection with the annunciator 120.

The master device 150 may include appropriate logic, circuits, interfaces, and/or code for communicating with slave devices such as slave devices 160-170. The master device 150 is used to support multiple link layer connections to each slave device (for example, slave devices 160-170) at the same time. The master device 150 is used to manage various aspects of data packet communication in the link layer connection with the related slave device (for example, the slave device 170). For example, the master device 150 may be enabled to determine the operation schedule in the link layer connection with the slave device 170. The master device 150 is used to use its own transmission to start the data packet exchange sequence in the link layer connection. The link layer connection can include periodic connection events in the data channel. Data packet transmission can occur within the connection event.

A slave device, such as the slave device 170, may include appropriate logic, circuits, interfaces, and/or code for communicating with a master device, such as the master device 150, in a related link layer connection. The slave device 170 may be associated with a link layer connection with the master device 150. The slave device 170 is used for synchronizing with the starting point of the connection event, which is called an anchor point from the perspective of the slave device, and is used for data communication with the master device 150. The slave device 170 may think that the establishment of the link layer connection with the master device 150 can be completed after receiving the connection request (CONNECT-REQ) data packet from the master device 150. The slave device 170 is used to calculate the data channel index using a channel selection algorithm for each connection event related to the link layer connection. The data channel index may be determined based on, for example, the hop length (Hop_length) in the received CONNECT-REQ data packet. The slave device 170 can be enabled to move to the data channel with the calculated data channel index to communicate data packets with the master device 150. The slave device 170 is used to transmit the data packet in the data channel after receiving the data packet from the master device 150 in the related link layer connection.

In an exemplary operation, an annunciator such as an annunciator 120 is used to transmit an announcement packet to a BLE device in an announcement channel, for example, the scanner 130 and/or the initiator 140. The scanner 130 is used to search for devices within the range by scanning the notification data packet. In an exemplary embodiment of the present invention, the scanner 130 may be configured to support both confidentiality and whitelist registration during device search. In this regard, the whitelist used by the scanner 130 may include device identification information, for example, 48-bit Bluetooth low energy device addresses, device class bits, RPA and/or IRK. In an exemplary embodiment of the present invention, the scanner 130 may be configured to manage or save the device identity of the preferred BLE device in the hardware white list, the firmware white list, and the host white list, respectively, to reduce the power consumption of the device. In this regard, a multi-level device filtering method can be adopted by the scanner 130 during device search. More specifically, the scanner 130 is configured to use hardware, then firmware and host, to perform device filtering according to the corresponding whitelist.

When the hardware is used to find or identify the device identity of the required annunciator for the received notification packet in the hardware whitelist, the scanner 130 can perform a CRC in the hardware for the transmission error in the received notification packet check. For a successful CRC check, the scanner 130 is used to transmit a response in the hardware to the desired annunciator. If the hardware does not find a match for the desired annunciator, the firmware can be used to continue device filtering. When the firmware is used to find a match for the desired annunciator, the scanner 130 can insert the device identity of the desired annunciator into the hardware whitelist for subsequent reception of notification data packets from the desired annunciator. When the firmware does not find a match for the desired annunciator, the scanner 130 may be configured to wake up the host to continue device filtering in the host according to the device configuration. In this regard, in an exemplary embodiment of the present invention, the scanner 130 may be configured to determine whether to wake up the host to continue device filtering, or process the received information for the corresponding service based on the attribute type information related to the received advertisement packet. Announce the package. For example, when the received notification packet can correspond to attribute type information such as a specific location of interest, the scanner 130 can be configured to wake up the host to continue device filtering, or even if the required hardware or firmware is not found When the annunciator, the received notification data packet is still processed in the host.

When announcing the link layer connection, the annunciator 120 is used to listen to the CONNECT-REQ data packet from the initiator 140, for example. The initiator 140 can be configured to send CONNECT-REQ data packets to the annunciators in the whitelist. Similar to the scanner 130, the initiator 140 is used to support both confidentiality and whitelist registration during device filtering. The multi-level device filtering method may be applied by the starter 140 to reduce power consumption. When receiving the CONNECT-REQ data packet addressed to the annunciator 120 from the initiator 140, the annunciator 120 can switch to the data channel and operate as a slave device. After being confirmed by the master device 150, the slave device 170 is used to perform BLE data packet transmission communication using the connection parameters specified by the master device 150.

Fig. 2 is a block diagram of an exemplary Bluetooth Low Energy (BLE) device for performing multi-level device filtering during device search in accordance with an embodiment of the present invention. 2, a scanner 200 is shown. The scanner 200 includes a BLE module 210, a host processor 220, a user interface 230, and a memory 240. The BLE module 210 includes a hardware unit 212 and a firmware unit 214.

The BLE module 202 may include appropriate logic, circuits, interfaces, and/or codes for transmitting and/or receiving signals through the Bluetooth low energy wireless interface. The received signal may include an announcement packet received through an announcement packet.

The BLE module 202 can be configured to save the hardware white list 212a and the firmware white list 214a respectively, so as to perform device filtering on the received notification data packets. The hardware unit 212 may include appropriate logic, circuits, interfaces, and/or codes, and the logic, circuits, interfaces, and/or codes are used to provide BLE baseband functions and BLE radio support. The firmware unit 214 may include appropriate logic, circuits, interfaces, and/or codes to provide support for the link management function of the BLE device 200. The BLE module 202 is used to process the received annunciator data packet, where the annunciator is the preferred annunciator in the white list 212a and/or the white list 214a.

The BLE module 202 is used for using hardware and/or firmware to simultaneously support confidentiality and whitelist registration during device search. The hardware whitelist 212a and the firmware whitelist 214a may include various device identities, such as 48-bit Bluetooth low energy device addresses, device class bits, RPA and/or IRK, for device filtering.

In the exemplary embodiment of the present invention, the BLE module 202 is used to perform device filtering in the hardware unit 212, and if no match is found using the hardware unit 212, the device filtering is performed in the firmware unit. For example, after receiving the notification data packet, the BLE module 202 can use the hardware whitelist to start searching for the required annunciator in the hardware unit 212 for the received notification data packet. When a match for the desired annunciator is found in the hardware whitelist 212a, the BLE module 202 can perform a CRC check in the hardware unit 212a for possible transmission errors in the received notification packet. If the CRC check is passed, the BLE module 202 is used to use the hardware unit 212 to transmit a response to the desired annunciator. When no match for the desired annunciator is found in the hardware whitelist 212a, the BLE module 202 can use the firmware unit 214 to continue searching. In this regard, a binary tree search for the desired annunciator can be performed in the firmware unit 214. When a match for the desired annunciator is found in the firmware white list 214a, the BLE module 202 is used to insert the device identity of the desired annunciator into the hardware white list 212a, which is used to subsequently receive notification data packets from the desired annunciator .

The BLE module 202 is also used to delete one or more entries in the hardware whitelist 212a as needed. When no match for the required annunciator is found in the firmware whitelist, the firmware unit 214 is used to wake up the host processor 220 to continue searching in the host according to the device configuration. For example, when a match for the desired annunciator is not found in the hardware white list 212a and the firmware white list 214a, the firmware unit 214 can be configured to evaluate and receive the corresponding load content based on, for example, the corresponding load content stored in the hardware unit 212 Attribute type information related to the announcement packet. When the received notification packet indicates the attribute type information such as the desired location and/or location-related data, the firmware unit 214 is used to wake up the host processor 220 to continue searching for the required annunciator in the host, or even when using hardware When the body unit 212 and the firmware unit 214 do not find a match for the required annunciator, they still process the notification data received from the host.

The host processor 220 may include appropriate logic, circuits, interfaces, and/or codes for managing and/or controlling the operation of device components, such as the BLE module 202 and the user interface 230. The host processor 220 is used to perform various signal processing tasks related to the BLE module 202.

In an exemplary embodiment of the present invention, the host processor 220 is used to divide the device identity of the preferred BLE device to form a hardware white list 212a, a firmware white list 214a, and a host based on the corresponding allowable processing time and/or available memory. Whitelist 220a. The host processor 220 is used to store the hardware white list 212a, the firmware white list 214a, and the host white list 220a in the memory 240. They can be read by the hardware unit 212, the firmware unit 214, and the host processor 220, respectively. Filter on the corresponding equipment.

In an exemplary embodiment of the present invention, the host processor 220 may be awakened by the firmware unit 214 in the BLE module 210 to use the whitelist 220a to perform device filtering and/or process the received notification data packet for the corresponding service.

The user interface 230 may include appropriate logic, circuits, interfaces, and/or codes for serving the scanner 200 by inputting user input and/or providing various services to the user.

The memory 240 may include appropriate logic, circuits, interfaces, and/or codes to enable storage of data and/or other information that can be utilized by the host processor 220. For example, the host memory 240 can be used to store data transmitted via the BLE module 202. The host memory 240 can store a hardware white list 212a, a firmware white list 214a, and a host white list 220a, which are used to use hardware, firmware, and device filtering of the host, respectively. The hardware whitelist 212a, firmware whitelist 214a, and host whitelist 220a may include various device identities, such as 48-bit Bluetooth low energy device addresses, device class bits, RPA and/or IRK, for use in the host Support confidentiality and whitelist registration at the same time. The memory 240 may include RAM, ROM, low-latency non-volatile memory such as flash memory, and/or other suitable electronic data memory capable of storing data and commands.

In an exemplary operation, the scanner 200 is used to search for devices within the range by scanning the notification data packet in the notification channel. In order to reduce power consumption, the scanner 200 may be configured to perform device filtering through multiple processing stages, namely using the hardware unit 212, the firmware unit 214, and the host processor 220, respectively. The host processor 220 is used to divide the device identities of the preferred BLE devices to form a hardware white list 212a, a firmware white list 214a, and a host white list 220a, respectively, for device filtering in a corresponding processing stage. Each whitelist can include device identities such as 48-bit Bluetooth low energy device addresses, device class bits, RPA, and/or IRK, which are used to support both confidentiality and whiteness at the corresponding processing stage during device filtering. List registration.

The scanner 200 is used to start device filtering in the hardware unit 212 by using the hardware whitelist 212a. When the required annunciator for the received notification data packet is found or identified in the hardware whitelist 212a, the hardware unit 212 is used to perform a CRC check for the transmission error in the received notification data packet. For a successful CRC check, the hardware unit 212 is used to transmit a response to the desired annunciator. If no match for the required annunciator is found in the hardware unit 212, the scanner 200 can continue device filtering in the firmware unit 214. When a match for the required annunciator is found in the firmware unit 214, the firmware unit 214 is used to insert the device identity of the required annunciator into the hardware whitelist 212a for subsequently accepting the notification data packet from the required annunciator. However, when no match for the required annunciator is found in the firmware unit 214, the firmware unit 214 may be configured to wake up the host processor 220 to continue device filtering in the host according to the device configuration. In this regard, the firmware unit 214 may be configured to determine whether to wake up the host processor 220 to continue device filtering in the host based on the attribute type information associated with the received advertisement packet. For example, when the received notification packet can indicate information such as the expected location or the attribute type of the expected service, the firmware unit 214 can be configured to wake up the host processor 220 to continue device filtering in the host, or even when the hardware unit is used. 212 and the firmware unit 214 still process the received notification data packet when the required annunciator is not found. The service corresponding to the received notification packet may be provided to the user via the user interface 230.

3 is a flowchart of exemplary steps that can be executed by a Bluetooth Low Energy (BLE) device to simultaneously perform Resolvable Private Address (RPA) resolution and whitelist registration during device search, according to an embodiment of the present invention. Referring to FIG. 3, the exemplary steps may begin with step 302. In step 302, a BLE device such as the scanner 200 is used to monitor the transmission on the advertising channel. In step 304, the scanner 200 is used to divide a plurality of non-resolvable private address (RPA) information (such as the public, static and/or non-private address of the preferred BLE device) and/or RPA information (such as connected peers) IRKS of the BLE device) to form a hardware white list, a firmware white list 214a, and a host white list 220a that can be used by the hardware unit 212, the firmware unit 214, and the host processor 220, respectively, for device filtering. In step 306, the scanner 200 is used to receive the notification data packet on the notification channel. In step 308, the scanner 200 is configured to use hardware such as the hardware unit 212 to initiate device filtering for the required annunciator of the received advertisement packet. In step 310, the hardware unit 212 is configured to detect the announcement data packet based on the access address association for the received announcement data packet. In step 312, the hardware unit 212 is used to obtain the device identity for the desired annunciator from the extracted access address. In step 314, the hardware unit 212 can determine whether the obtained device identity for the desired annunciator is RPA. When the obtained device identity for the desired annunciator is RPA, then control goes to step 316. In step 316, the hardware unit 212 is configured to perform device filtering by comparing the obtained device identity with the RPA-related entries in the white list 212a. The exemplary steps end at step 320.

In step 314, when the obtained device identity for the desired annunciator is non-RPA, control goes to step 318. In step 318, the hardware unit 212 is used to perform device filtering by comparing the obtained device identity with public, static or non-RPA entries in the whitelist 212a. The exemplary steps end at step 320.

FIG. 4 is a flowchart of exemplary steps that can be performed by a Bluetooth Low Energy (BLE) device for a quick whitelist during device search according to an embodiment of the present invention. Referring to FIG. 4, the exemplary steps may begin with step 402. In step 402, a BLE device such as the scanner 200 may be configured to process the device identity for the desired annunciator during device filtering. In step 404, the scanner 200 may determine whether the device identity is found in the hardware whitelist 212a by using hardware, such as the hardware unit 212. When the hardware unit 212 is used to find the device identity in the hardware whitelist 212a, control goes to step 406. In step 406, the hardware unit 212 is configured to perform a CRC check on the transmission error in the notification data packet received from the desired annunciator. In step 408, the hardware unit 212 may determine whether the CRC check passes. When the CRC test passes, control goes to step 410. In step 420, the hardware unit 212 is used to transmit a response to the required annunciator for the received announcement packet. Exemplary steps end at step 424

In step 404, when the device identity is not found in the hardware whitelist by using the hardware unit 212, control goes to step 412. In step 412, it can be determined whether the size of the hardware whitelist 212a exceeds a predetermined limit. When the size of the hardware white list 212a exceeds the predetermined limit, control goes to step 414. In step 414, the firmware unit 214 may be configured to perform a binary tree search for the desired annunciator in the firmware whitelist 214a. In step 416, the firmware unit 214 may determine whether the device identity of the required annunciator is found in the firmware whitelist 214a. When the device identity of the desired annunciator is found in the firmware whitelist 214a, control goes to step 418. In step 418, the firmware unit 214 is used to insert the device identity into the hardware whitelist 212a after deleting one or more entries (regardless of whether it is necessary to do so). The deleted hardware whitelist entry may be transferred to the firmware whitelist 214a saved by the firmware unit 214. The exemplary procedure ends in step 424 and step 408. When the CRC check in the hardware unit 212 fails, then control goes to step 420. In step 420, the hardware unit 212 is used to terminate the transmission of the response to the desired annunciator. The exemplary step ends at step 424.

In step 412, when the size of the white list 212a does not exceed the predetermined limit, the exemplary step ends in step 424.

In step 416, when the device identity of the desired annunciator is not found in the firmware whitelist 214a using the firmware unit 214, control goes to step 422. In step 422, the firmware unit 214 is used to wake up the host processor 220 for device filtering in the host according to the device configuration. Exemplary steps end at step 424

FIG. 5 is a flowchart of exemplary steps that can be executed by a Bluetooth Low Energy (BLE) device for device filtering based on attribute type during device search according to an embodiment of the present invention. Referring to FIG. 5, the exemplary steps may begin with step 502. In step 502, the BLE device, such as the scanner 200, is configured to process the device identity of the desired annunciator during device filtering. Using hardware and firmware, the device identity of the required annunciator was not found. In step 504, it can be determined whether the notification data packet received from the desired annunciator indicates the attribute type information of interest. When the notification data packet received from the desired annunciator relates to the attribute type information of interest, control goes to step 506. In step 506, the firmware unit 214 is used to wake up the host processor 220 to continue device filtering in the host, or process the received notification packet even when the required annunciator is not found by the hardware and firmware. In step 508, if desired, the host processor 220 is used to transmit a response to the desired annunciator. Exemplary steps end at step 512

In step 504, when the notification data packet received from the desired annunciator does not involve the attribute type information of interest, control goes to step 510. In step 510, the firmware unit 214 may be configured such that it does not wake up the host processor 220. In other words, device filtering can be stopped. The exemplary steps may end in step 512.

Among the various exemplary features of the method and system for multi-level device filtering in a Bluetooth low energy device, the BLE device, such as the scanner 200 in the BLE communication system 100, is used to monitor the transmission on the advertisement channel. The scanner 200 may receive an advertising packet transmitted from an advertising BLE device (for example, the annunciator 120). In various exemplary embodiments of the present invention, the scanner 200 may be configured to use the hardware unit 212a of the BLE module 210 to filter the received announcement data packet to search for the annunciator 120 before processing the received announcement data packet. When the device filtering in the hardware unit 212 does not find the annunciator 120, the scanner 200 can use the firmware unit 214 of the BLE module 210 to continue to filter the received notification data packets.

The scanner 200 is used to divide the device identity information of multiple preferred BLE devices to form a hardware white list 212a, a firmware white list 214a, and a host white list 220a for corresponding device filtering. Device identity information may include non-private device identity, such as 48-bit Bluetooth low energy device address, and/or private device identity information, such as resolvable private address (RPA) and/or identity root key (IRK) To support both confidentiality and whitelist registration during device filtering. After receiving the notification data packet from the annunciator 120, the scanner 200 is used to use the hardware unit 212 to start searching for the device identity information of the annunciator 120 in the hardware white list 212a. When the annunciator is found in the hardware white list 212a by the hardware unit 212, the hardware unit 212 may be configured to perform a CRC check on the received notification packet.

If the CRC check passes, the hardware unit 212 is used to send a response to the annunciator 120. When the annunciator 120 is not found in the hardware white list 212a by the hardware unit 212, the scanner 200 is used to use the firmware unit 214 to continue searching. When the device identity information of the annunciator 120 is not found by the firmware unit 214, the scanner 200 is used to insert the device identity information of the annunciator into the hardware whitelist 212a for subsequent reception of the notification data packet from the annunciator 120. When the annunciator 120 is not found by the firmware unit, the firmware unit 214 is used to wake up the host processor of the BLE device 200 to continue device filtering in the host according to the device configuration. For example, the firmware unit 214 is configured to wake up the host processor 220 based on the attribute type information about the received notification packet. In this regard, the host processor 220 is used to process the received notification packet for the service even when the annunciator 120 is not found by the hardware unit 212 and the firmware unit 214.

Another embodiment of the present invention may provide a machine and/or computer readable memory and/or medium, the machine code and/or computer program stored therein includes at least one code segment, and the at least one code segment is generated by the machine and/or Or the computer executes, so that the machine and/or the computer execute the above-mentioned steps for performing multi-level device filtering in the Bluetooth low energy device.

Therefore, the present invention can be implemented by hardware, software, or a combination of software and hardware. The present invention can be implemented in a centralized manner in at least one computer system, or implemented in a decentralized manner by different parts distributed in several interconnected computer systems. Any computer system or other equipment that can implement the method is applicable. The combination of commonly used software and hardware can be a general computer system with a computer program installed, and the computer system is controlled by installing and executing the program to make it run according to the method.

The present invention can also be implemented through a computer program product. The package program contains all the features that can implement the method of the present invention. When it is installed in a computer system, the method of the present invention can be implemented. The computer program in this document refers to any calculation formula that can use a set of instructions written in any programming language, code, or symbol. After one or two steps, a specific function is realized: a) conversion into other languages, decoding or symbols; b) reproduction in a different format.

Although the present invention is described through specific embodiments, those skilled in the art should understand that various changes and equivalent substitutions can be made to the present invention without departing from the scope of the present invention. In addition, various modifications can be made to the present invention for specific situations or materials without departing from the scope of the present invention. Therefore, the present invention is not limited to the disclosed specific embodiments, but should include all embodiments falling within the scope of the claims of the present invention.

<u style="single">Cross-reference to related applications</u>

This application refers to and applies to claim the priority of the US provisional patent application with the filing date of June 24, 2010 and the application number No. 61/358,352.

The present invention refers to and incorporates the content of the following patent applications: US Patent Application No. 12/546,621, dated August 24, 2009.

<p>100. . . Bluetooth Low Energy (BLE) communication system</p><p>110-120. . . Annunciator</p><p>130. . . scanner</p><p>140. . . Launcher</p><p>150. . . Master device</p><p>160-170. . . Slave device</p><p>200. . . scanner</p><p>202. . . BLE module</p><p>210. . . BLE module</p><p>212. . . Hardware unit</p><p>212a. . . Hardware whitelist</p><p>214. . . Firmware unit</p><p>214a. . . Firmware whitelist</p><p>220. . . Host processor</p><p>220a. . . Host whitelist</p><p>230. . . User interface</p><p>240. . . Memory</p>

FIG. 1 is a schematic diagram of an exemplary Bluetooth low energy (BLE) communication system for supporting multi-level device filtering in a Bluetooth low energy device according to an embodiment of the present invention;

2 is a block diagram of an exemplary Bluetooth Low Energy (BLE) device for performing multi-level device filtering during device discovery according to an embodiment of the present invention;

3 is a flowchart of exemplary steps that can be executed by a Bluetooth Low Energy (BLE) device during device discovery to support parsing and whitelisting of Resolvable Private Address (RPA) in parallel according to an embodiment of the present invention;

FIG. 4 is a flowchart of exemplary steps that can be executed by a Bluetooth Low Energy (BLE) device during device discovery for a quick whitelist search according to an embodiment of the present invention;

Fig. 5 is a flowchart of exemplary steps for device filtering based on attribute type that can be executed by a Bluetooth Low Energy (BLE) device according to an embodiment of the present invention.