Bluetooth advertising processing techniques

Processing of wireless advertising packets can be processed by a controller when the advertising packet includes an indication of a preference for processing the advertising packet by the controller. If the advertising packet does not include an indication of a preference for processing the advertising packet by the controller, the advertising packet can be processed by a host. In addition, if the advertising packet includes an indication of a preference for processing by the controller, but the controller cannot process the advertising packet, the advertising packet can be processed by the host.

BACKGROUND OF THE INVENTION

Computing systems have made significant contributions toward the advancement of modern society and are utilized in a number of applications to achieve advantageous results. Numerous devices, such as desktop personal computers (PCs), laptop PCs, tablet PCs, netbooks, smart phones, servers, Internet-of-Things (IoT) devices and the like have facilitated increased productivity and reduced costs in communicating and analyzing data in most areas of entertainment, education, business, and science. One common aspect of such computing devices is the wireless communication of data between devices.

Bluetooth® is a wireless communication standard that uses short-range radio links to communicate data between computing devices in a Wireless Personal Area Network, and wireless access to Local Area Networks (LANs), Public Switched Telephone Network (PSTN), mobile telephone networks, and the like. The Bluetooth protocol can utilize advertising techniques to broadcast information to other devices and establish connections between devices. However, processing of the advertising packets may impact the performance of Bluetooth devices. Accordingly, there is a continuing need for improved advertising packet processing techniques.

SUMMARY OF THE INVENTION

The present technology may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the present technology directed toward techniques for processing wireless advertising messages.

In one embodiment, the techniques can include determining, by a wireless controller of an observer device, if an advertising message includes an indication of a preference for processing one or more portions of the advertising message by the wireless controller. In one implementation, the indication of the preference for processing the advertising message by the wireless controller can be encoded as in a data type field corresponding to the data for preferred processing by the wireless controller. When the advertising message includes the indication of the preference for processing the advertising message by the wireless controller, the wireless controller of the observer device can process the corresponding one or more portions of the advertising message. When the advertising message does not include the indication of the preference for processing the advertising message by the wireless controller, the wireless controller can send the advertising message to a wireless host for processing.

In another embodiment, a wireless controller of an observer device can determine if an additional controller advertising data (ACAD) field includes an indication of a preference for processing by the wireless controller. When the ACAD field does not include an indication of a preference for processing the ACAD field by the wireless controller, the wireless controller can process the corresponding one or more portions of the ACAD field. When the ACAD field includes an indication of a preference for processing the ACAD field by the wireless controller, the wireless controller can determine if it can process the ACAD field. When the ACAD field cannot be processed by the wireless controller, the wireless controller can extract data from the ACAD field and send the extracted data to a wireless host of the observer device for processing. When the ACAD filed can be processed by the wireless controller, the wireless controller can process the corresponding one or more portions of the ACAD field.

DETAILED DESCRIPTION OF THE INVENTION

Some embodiments of the present technology which follow are presented in terms of routines, modules, logic blocks, and other symbolic representations of operations on data within one or more electronic devices. The descriptions and representations are the means used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. A routine, module, logic block and/or the like, is herein, and generally, conceived to be a self-consistent sequence of processes or instructions leading to a desired result. The processes are those including physical manipulations of physical quantities. Usually, though not necessarily, these physical manipulations take the form of electric or magnetic signals capable of being stored, transferred, compared and otherwise manipulated in an electronic device. For reasons of convenience, and with reference to common usage, these signals are referred to as data, bits, values, elements, symbols, characters, terms, numbers, strings, and/or the like with reference to embodiments of the present technology.

It should be borne in mind, however, that all of these terms are to be interpreted as referencing physical manipulations and quantities and are merely convenient labels and are to be interpreted further in view of terms commonly used in the art. Unless specifically stated otherwise as apparent from the following discussion, it is understood that through discussions of the present technology, discussions utilizing the terms such as “receiving,” and/or the like, refer to the actions and processes of an electronic device such as an electronic computing device that manipulates and transforms data. The data is represented as physical (e.g., electronic) quantities within the electronic device's logic circuits, registers, memories and/or the like, and is transformed into other data similarly represented as physical quantities within the electronic device.

In this application, the use of the disjunctive is intended to include the conjunctive. The use of definite or indefinite articles is not intended to indicate cardinality. In particular, a reference to “the” object or “a” object is intended to denote also one of a possible plurality of such objects. It is also to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting.

FIG. 1, a block diagram of a Bluetooth® network, in accordance with aspects of the present technology, is shown. The network can include a plurality of Bluetooth enabled computing devices110-150. The Bluetooth enabled computing devices110-150can be desktop Personal Computers (PCs), laptop PCs, tablet PCs, printers, smart phones, smart televisions, gaming consoles, infotainment centers, Internet-of-Thing (IoTs) devices, and the like. Each device110-150can be characterized according to its broadcasting role, and/or its connecting role. A broadcaster130-140can be a device that broadcasts public advertising data packed but does not have an explicitly connection to another device to transfer data. An observer device140,150can listen to the data in the advertising packets sent by a broadcaster. However, no connection happens between broadcasting devices and observer devices. In connecting roles, devices explicitly connect and handshake to transfer data. A peripheral device110-140can advertise its presence so central devices can establish a connection. A central device140,150can initiate a connection with a peripheral device110-140by first listening to advertising packets broadcast by a device. When a central device wants to connect to a peripheral device, the central device can send a request connection data packet to the peripheral device. If the peripheral device accepts the request from the central device, a connection can be established. Aspects of the present technology are primarily directed toward advertising in the broadcasting role, and therefore the connection role will not be discussed in further detail.

FIG. 2, a block diagram of a Bluetooth® device, in accordance with aspects of the present technology, is shown. The Bluetooth architecture can include a Bluetooth Host layer205, a Host Controller Interface (HCI) transport layer210, and a Bluetooth Controller layer215. The Host205can be configured to implement the core Bluetooth protocols, including the Bluetooth stack and the high-level layers of the Bluetooth architecture, such as Application Specific Interfaces (APIs) and profiles. The Controller215can be configured to implement the lower levels of the Bluetooth architecture. The HCI transport layer210can be configured to deliver data between the Host205and the Controller215. Each layer can be a collection of components that include protocol implementations for APIs, application, services, and the like.

In one implementation, the Host205can include the logical layer of the Bluetooth architecture such as Bluetooth Stack components220-245, profile components250-260, and Operating System Embedded Compact components265-280. The Bluetooth Stack components220-245can include a COM Port Emulation layer220that can support virtual COM ports over RFCOMM channels, a Service Discovery Protocol (SDP) layer225that can manage the discovery and publishing of supported Bluetooth services and parameters between devices, a Radio Frequency Communications (RFCOMM) Serial Port Emulation layer230that can emulate RS-232 serial ports over the L2CAP layer240, a Bluetooth Network Encapsulation Protocol (BNEP) layer235that can encapsulate network packets into a standard format so they can be transmitted over the L2CAP layer240, and the Logical Link Control and Adaptation Protocol (L2CAP) layer that can communicate directly with a HCI245to provide the Bluetooth Stack component220-245with access to the Controller215. The profile components250-160can include a Bluetooth-Enabled Applications layer250that can implement Bluetooth functionality, a Profile layer255to provide specifications that describe Bluetooth application and how Bluetooth devices communicate, and a Stack Extension layer260that can provide Bluetooth-enabled application with access to the layer of the Bluetooth Stack220-245.

The Controller215can include a Link Manager Protocol (LMP) layer285that can manage logical link establishment between Bluetooth device, a Baseband layer290that can form the physical layer of the Bluetooth architecture, and a Radio layer295that can transmit and receive data. Details concerning the Host205, HCI transport210and Controller215are provided in the Bluetooth protocol specifications and therefore further general description of the Bluetooth architecture that are not germane to an understanding of aspects of the present technology will not be described further herein.

The Bluetooth protocol can provide for discovery and setup of services between devices. The Bluetooth protocol can also advertise the services that the devices provide. In one implementation, advertising techniques, in the Bluetooth Low Energy (BLE) protocol subset, can provide for the rapid build-up of simple links between computing devices. Using advertisements, a device can broadcast packet to every device around it. A receiving device can act on information in the broadcast packet or connect to the broadcasting device to receive more information. In BLE, a device can be in a low power mode most of the time and enter an operating mode to advertise and connect when needed. The advertisement packets can be sent, on predetermined channel of the 2.4 GHz spectrum used by Bluetooth. For BLE, the advertisement packets can be sent by a peripheral device on Channels 37, 38 and 39 periodically with both a fixed interval and a random delay. The fixed interval with the random delay can help to reduce collisions between advertisements from different devices. A central device scanning for devices or beacons can listen to the predetermined channels for the advertisement packets, which helps it discover devices nearby.

When a broadcaster device110-140is advertising it can periodically transmit packets containing information such as preamble, access address, CRC, Bluetooth address of sender, and the like. Referring now toFIG. 3, an extended advertising payload format, in accordance with aspects of the present technology, is shown. The extended advertising payload format305can include an extended header length310, an advertisement mode (AdvMode)315, an extended header320, and advertisement data (AdvData)325. In one implementation, the extended header length310can comprise 6 bits that can define the length of the extended header. The advertisement mode315can comprise 2 bits that can define modes such as non-connectable and non-scannable, connectable and non-scannable or non-connectable and scannable. The extended header320can comprise 0-63 octets of bits that can define attributes of the extended advertising event. The advertisement data325can comprise 0-254 octets of bits that can contain advertising data. The format of the extended. header320, as illustrated inFIG. 4. can include extended header flags field330, AdvA field335, TargetA field340, RFU field345, ADI field350, AuxPtr field355, SyncInfo field360, TxPower field365, and ACAD field370. The extended header flags field330can comprise 1 octet of bits that can indicate which extended header fields335-370are present. The AdvA field335can comprise six octets of bits that can contain the advertiser's device address. The TargetA field340can comprise six octets of bits that can contain the address of the observer device to which the advertisement is directed. The RFU field350can comprise one octet of bits reserved for future use. The ADI field350can comprise two octets of bits that can identify different advertising sets and identify if the advertising data is a duplicate. The AuxPtr field355can comprise three octets of bits that can indicate whether some or all of the advertising data in in a subsequent auxiliary packet. The SyncInfo field360can comprise 18 octets of Kits that can indicate the presence of a periodic advertisement. The TxPower field365can comprise one octet of bits that can indicate the transmission power level. The ACAD field370can comprise the remainder of the extended header320that includes the additional controller advertising data. In one implementation, the ADV_EXT_IND, AUX_ADV_IND, AUX_SCAN_RSP, AUX_SYNC_IND, AUX_CHAIN_IND, AND AUX_CONNECT_RSP advertising channel PDUs can share the same extended advertising channel PDU payload format illustrated inFIG. 3.

In aspects, the ACAD field370cannot be fragmented across multiple advertising data Protocol Data Units (PDUs). The ACAD field370can fit inside a single advertising data PDU. The ACAD field370can hold data from a controller115of a broadcaster130, and can be intended to be used by a controller115of an observer140. The ACAD field370can use the same format at the AdvData field325in various advertising channel PDUs. In aspects, the AdvData field325may contain advertising data from a host105of a broadcaster, and can be intended to be used by a host105and an observer140.

Referring now toFIG. 4, a format of the AdvData field in accordance with aspects of the present technology is shown. The AdvData field325can include a significant part405and a non-significant part410. The significant part405can include a sequence of one or more advertising data (AD) structures415-425. Each AD structure can include a length field430, which contains a length of octets value, and a data field435of the length of octets. The first octet of the data field can include an AD type field440, with the rest containing the AD data445. The non-significant part410extends the AdvData field325and can contain all-zero octets when needed to fill the AdvData field325. However, the non-significant part410may not be transmitted. In addition, the scan response may have the same format as the AdvData field325. Conventionally, the ACAD and AdvData can share the same format. The ACAD is conventionally processed by the controller, and the AdvData is processed by the host.

Referring now toFIGS. 5 and 6, a method of processing Advertising Event (AE) packets, in accordance with aspects of the present technology. The method may be implemented as computing device-executable instructions (e.g., computer program) that are stored in computing device-readable media (e.g., computer memory) and executed by a computing device (e.g., processor). The method includes the use of an Advertising Data (AD) data type that indicates a preference for processing the data in the packet by a Bluetooth Controller subsystem. If the controller subsystem can process the data in accordance with the indicated preference, the data can be processed by the controller instead of the host. If the controller subsystem cannot process the data in accordance with the indicated preference, the data can be sent to the Bluetooth host subsystem for processing. The method can include carrying the AD data type in an advertising channel packet data unit (PDU). A controller of an observer can check if it can process the AD data type. If the AD data type can be processed by the controller, the data is extracted from the advertising data and processed by the controller. If the AD data type cannot be processed by the controller, the data is kept intact and sent to the host for further processing.

In aspects, a method of processing AE packets by a host205of a broadcaster (e.g., advertiser), as illustrated inFIG. 5, can include receiving advertising data, at520. The host205can determine if the advertising data includes a data type for preferred processing by a controller215of an observer (e.g., recipient), at530. The advertising data can be encoded along with a data type indicating a preference for processing by a controller of the observer in an advertising message, at540, when it is determined that the advertising data includes a data type for preferred processing by the controller. In one implementation, the advertising message can be a Bluetooth Low Energy (BLE) AdvData packet. Referring now toFIG. 7, an exemplary AD data format, in accordance with aspects of the present technology is shown. The AD data format can include an AD type440and AD Data445. The data type indicating a preference for processing by a controller can be encoded as a given value. In aspects, the AD Data445may optionally include an AD sub type710and an AD sub-type data720to provide further variants.

The host can also determine if there are any other advertising data for encoding in the advertising message, at550. When there is additional advertising data, the advertising data can be encoded in the advertising message, at560. The advertising data can also be encoded with a data type that does not indicate a preference for processing, by the controller of the observer in an advertising message, at560, when it is determined that the advertising data does not include a data type for preferred processing by the controller. The advertising message, after encoding of the advertising data, can be broadcast to one or more observers,570.

In aspects, a method of processing AE packets by a controller215of an observer, as illustrated inFIG. 6, can include receiving an advertising message, at620. In one implementation, the advertising message can be a Bluetooth Low Energy (BLE) AdvData packet. The controller can determine if the advertising message includes a data type indicating a preference for processing by the controller, at630. Referring again toFIG. 7, the AD data format can include an AD type440and AD Data445. The data type indicating a preference for processing by a controller can be encoded as a given value. In aspects, the AD Data445may optionally include an AD sub-type710and an AD sub-type data720to provide further variants. When the advertising message includes a data type indicating a preference for processing by the controller, the controller can also determine if the controller can process the data having the data type indicating a preference for processing by the controller, at640. When the controller can process the data having the data type indicating a preference for process by the controller, the data can be processed by the controller, at650. The controller can also determine if there is any other data in the advertising message for processing by the host, at660. When the advertising message does not include a data type indicating a preference for processing by the controller, the controller cannot process the data having a data type indicating a preference for processing by the controller, and/or there is other data in the advertising message for processing by the host, the controller can send the advertising message to the host for processing, at670.

Conventionally, the AdvData is processed by the host205. However, the host205of the observer needs to be woken up from a low power state to process the AdvData. Therefore, including, a data type indicating a preference for processing by the controller215advantageously allows the host205to remain in the low power state if the controller215of the observer can process the AdvData. However, the data type indicating a preference for processing by the controller215advantageously provides for backward compatibility in the situations where the controller215of the observer cannot process the given AdvData.

Referring now toFIGS. 8 and 9a method of processing Advertising Event (AE) packets, in accordance with aspects of the present technology. The method may be implemented as computing device-executable instructions (e.g., computer program) that are stored in computing device-readable media (e.g., computer memory) and executed by a computing device (e.g., processor). The method includes the use of an Advertising Data (AD) data type that indicates a preference for processing the data in the packet by a Bluetooth Controller subsystem. If the controller subsystem can process the data in accordance with the indicated preference, the data can be processed by the controller instead of the host. If the controller subsystem cannot process the data in accordance with the indicated preference, the data can be sent to the Bluetooth host subsystem for processing. The method can include carrying the AD data type in an ACAD field. When it is carried in the ACAD field, a controller of an observer can check if it can process the data type of the ACAD field. If the data type of the ACAD field can be processed by the controller, the data is processed by the controller. If the ACAD cannot be processed by the controller, the data type can be extracted from the ACAD field and sent to a host of the observer for further processing. The method can also include the controller configured to extract advertising data that is preferably to be processed by the controller but cannot be processed by the controller from an advertising data packet and moved to an ACAD field in an advertising PDU before transmission to the host.

In aspects, a method of processing AE packets by a host205of a broadcaster (e.g., advertiser), as illustrated inFIG. 8, can include receiving advertising data, at820. The host205can determine if the advertising data includes a data type for preferred processing by a controller215of an observer (e.g., recipient), at830. The advertising data can be encoded along with a data type indicating a preference for processing by a controller of the observer in an additional controller advertising data (ACAD) field of an advertising channel PDU, at840, when it is determined that the advertising data includes a data type for preferred processing by the controller. In one implementation, the advertising channel PDU can be a Bluetooth Low Energy (BLE) advertising channel PDU with an (ACAD) field. Referring again toFIG. 7, the AD data format can include an AD type440and AD Data445. The data type indicating a preference for processing by a controller can be encoded as a given value. In aspects, the AD Data445may optionally include an AD sub-type710and an AD sub-type data720to provide further variants.

The host can also determine if there are any other advertising data for encoding in the advertising channel PDU, at850. When there is other advertising data, the advertising data can be encoded in an AdvData field of the advertising channel PDU, at860. When it is determined that the advertising data does not include a data type for preferred processing by the controller, the advertising data can also be encoded in an Adv Data field of the advertising channel PDU, at860. The advertising channel PDU can be broadcast to one or more observers, at870.

In aspect, a method of processing AE packets by a controller215of an observer, as illustrated inFIG. 9, can include receiving an ACAD field in an advertising channel PDU, at920. In one implementation, the advertising channel PDU can be a Bluetooth Low Energy (BLE) with an ACAD field. The controller can determine if the ACAD field includes a data type indicating a preference for processing by a controller, at930. Referring again toFIG. 7, the AD data format can include an AD type440and AD Data445. The data type indicating a preference for processing by a controller can be encoded as a given value. In aspects, the AD Data445may optionally include an AD sub-type710and an AD sub-type data720to provide further variants. When the ACAD field includes a data type indicating a preference for processing by the controller, the controller can also determine if the controller can process the data having the data type indicating a preference for processing by the controller, at940. When the controller can process the data having the data type indicating a preference for processing by the controller, the data of the ACAD can be processed by the controller, at950. In addition, when ACAD field does not include a data indicating a preference for processing by the controller, the data of the ACAD can be processed by the controller, at950. When the controller cannot process the data of the ACAD and the data type indicates a preference for processing by the controller, the controller can extract and send data to a host, at960. The controller can also determine if there is any other advertising data in the ACAD for processing by the controller, at970. When there is other data in the ACAD for processing by the controller, the additional data of the ACAD can be processed by the controller, at950.

Conventionally, the ACAD is processed by the controller215. However, the controller215of the observer may be hardware constrained, such as baying limited computing device readable memory (e.g., Random Access Memory (RAM) and/or Read Only Memory (ROM)), and therefore may be less readily upgradeable to support new functions. In contrast, the host205may more readily be upgradable by software to accommodate new functions. Accordingly, a data type can indicate a preference for processing an ACAD message by the controller of the observer to enable new controllers with appropriate functionality to process the data. However, if the controller215is not able to process the ACAD data type, the data can be extracted from the ACAD and sent to the host205as an AdvData fur further processing by the host205that can be readily updated with new functionality to support new data types.

In aspects, a Resolvable Coordinate Identifier (RCI) address type can be treated as a device address and sent in address fields of advertising PDUs as an additional way to address a device that is part of a coordinated set. Referring now toFIG. 10, a block diagram of a Bluetooth® network, in accordance with aspects of the present technology, is shown. The network can include a using device1010and a coordinated set1020of observer devices. The RCI data type can be valid in the ACAD context and a controller can optionally support the resolution of a RCI sent as either a data type in the ACAD or as an address type. The RCI can be sent to the host for further processing together with the advertising data if the controller does not support RCI resolution. RCI resolution in the controller allows filtering on RCI. Members can identify themselves as belonging to a coordinated set by exposing the RCI or by including the RCI in the AdvA of an advertising PDU. Accordingly, using device1010can discover the members of the set1020.