Bluetooth SIG has finally adopted the Bluetooth® v5.4 core specification. This means that a new set of exciting features are available for Bluetooth products along with all the advantages they provide. Two of the major improvements are Periodic Advertising with Responses (PAwR) and Encrypted Advertising Data. Together, they enable connectionless, bidirectional, secure communication with thousands of very low-power end nodes in the star topology.
One example use-case that is currently very relevant is the Electronic Shelf Label profile (ESL). This is actually the first standardized use-case for PAwR and Encrypted Advertising Data. The specification is currently released as a draft version, but it is expected to be adopted soon. Having this profile in place provides a standard for the ESL use-case, so we expect applications and ecosystems based on Bluetooth to emerge rapidly in the near future.
In general, PAwR and Encrypted Advertising Data are intended for applications that involve a large number of devices transmitting small amounts of data, that accept longer latencies in exchange for extended battery life. For example, massive sensor networks that don't require immediate response or monitoring of non-dynamic systems.
Periodic Advertising with Responses
Bidirectional communication of application data in connectionless mode has been impossible in Bluetooth LE until now, and PAwR enables that. This is the key benefit of this feature.
To explain how it works, we will use the broadcaster and observer naming convention. Broadcasting is nothing new, data is sent by the broadcaster and observers scan to receive it. What is new in PAwR is that the broadcasted data is organized in small packets within deterministic time slots that the observers can precisely synchronize with and respond to. Data is sent within PAwR events that consist of PAwR subevents. Each observer can synchronize to one or multiple subevents, and being synchronized, observers actively receive only in these specific timeslots.
Bidirectional communication is implemented within subevents. The broadcaster transmits the data at the beginning of the subevent, then after a response slot delay, observers can send their responses. Orchestration of the responses is handled on the application level.
The efficiency of this solution is a result of the observers’ capability for scanning only for specific subevents. Therefore, the end nodes (observers) scan only for a tiny, specific period of time. That is what makes this solution so effective in terms of power consumption.
One more feature of PAwR is the ability to establish an ACL connection, as the subevent may contain a connection request. With this feature, devices don't have to follow the legacy connection scheme with additional scanning and advertising. In fact, it wouldn’t make sense since the devices are already synchronized. A connection may be needed in some cases because only small amounts of data can be transferred over PAwR. To transfer more data, devices may set up an ACL connection.
Encrypted Advertising Data
While PAwR is addressing the scalability and ultra-low power requirements, there is a critical requirement that must be in place for all modern IoT systems, namely security. Data exchanges between the ESL access point and the devices must be encrypted to preserve confidentiality, avoid tampering, and secure the network.
Prior to Bluetooth v5.4, there was no standardized way of encrypting advertisement data. Such definitions only existed for connection-oriented communication. As most of the data exchange for ESL applications flows through PAwR, it became necessary to add an encrypted advertising data feature. This introduces a standardized way of encrypting data in advertising as well as sharing key material, which is required for data encryption. It’s worth noting that encrypting advertising data can be done not just over PAwR but also using other advertising transports.
This feature allows encrypting the totality or just a sub-set of the payload on a given advertising packet by adding a new AD type called Encrypted Advertising Data (type 0x31) that encapsulates all the AD fields to be encrypted. This means that an advertising packet payload will conceptually look as depicted below.
Advertisement Data 0 encapsulates AD 1-3, which are encrypted. That is followed by AD 4 and 5, which are unencrypted. This allows for flexibility and keeping some of the non-critical advertising data open for any observer to interpret, for example, AD Type 0x01 (Flags) or 0x09 (Complete Local Name).
Sharing encrypted data between two devices requires that they have a shared secret with which to encrypt and decrypt the data. To achieve this, a new GATT characteristic called Encrypted Data Key Material can be optionally included as part of the GAP (Generic Access Profile) service. A connected GATT client can read this characteristic over an encrypted and authenticated link, which then allows encrypted data to be exchanged over advertisements.
Electronic Shelf Label profile
An Electronic Shelf Label (ESL) is a device that displays pricing information for products on a retail store shelf. The goal is to have remote management over the displayed information about a given product, including its name, barcode, price, etc. ESLs can also be equipped with sensors e.g., battery voltage monitoring or ambient light sensing. This type of system requires versatility and is cost-sensitive, which is why digital labels are usually battery-operated. Power consumption is the critical requirement here since frequent charging or replacing batteries is not an option for this use case.
The ESL profile implements the means for this specific use case that, with the usage of PAwR, provides the lowest possible power consumption and security with new encrypted advertising. Connection-oriented communication is used for configuration, exchange of the key material for Encrypted Advertising Data, and sending larger chunks of information e.g., images. Then, the connectionless communication based on PAwR is used for regular commands and responses.
Roles in the ESL profile are defined as Access Point (AP) and Electronic Shelf Label (ESL). AP corresponds to broadcaster in the PAwR context, and ESL corresponds to observer. To manage the network, a simple addressing scheme is introduced. Each ESL has an 8-bit ESL ID. Devices are grouped with 7-bit Group IDs. The Access Point can manage up to 32 640 devices.
For the communication from AP to ESLs, PAwR’s subevents are related directly to the ESL’s Groups. Devices assigned to group #0 synchronize to receive subevent #0 and so on. Data packets transmitted to each group contain the sequence of commands addressed to subsequent ESL IDs.
As mentioned before, response orchestration is managed at the application level. In the ESL profile, responses are managed dynamically. Each ESL receives all commands addressed to its group. The device must ignore all commands addressed to the others, but it is required to use the response slot corresponding to the order of the received command. For example, ESL ID #1 receives the following message: [ESL ID #0, cmd], [ESL ID #1, cmd], [ESL ID #3, cmd]. It will respond in response slot #1.
Security for ESL is provided with the Encrypted Advertising Data introduced in Bluetooth v5.4. ESL devices typically require an initial connection to the AP for commissioning, at which time the key material can also be read and assigned to allow the subsequent exchange of encrypted advertising data protected with LE Secure Connection.
The ESL profile provides a complete description of roles, states, and message sequences, as well as security requirements that describe how Encrypted Advertising Data is used for communication. For a deeper dive, we encourage you to read the specification or the technical guide for the 5.4 release (see the links at the bottom of the page).
With the enhancements of Bluetooth v5.4 introducing very low power, bidirectional, connectionless communication, many new use-cases are made possible, and ESL is the first one.
Additional features in the Bluetooth v5.4 core specification
Two more features are available in the new core specification, the first being the LE GATT Security Levels Characteristic (SLC). It is intended to limit glitches in user-experience flow caused by security conditions that may delay access to an attribute. With SLC, the client can upfront determine sufficient security mode and level to access all needed GATT attributes. If necessary, the link security can be upgraded to meet the access requirements before attempting to access GATT attributes.
Advertising Coding Selection is the second one. The S parameter defines the Forward Error Correction (FEC) and takes one of two values, S=2 or S=8. It controls how much error correction data is generated and to what extent the communication range might be increased. With Advertising Coding Selection, the host is enabled to deterministically select the coding scheme that the controller should use for transmitting advertising PDUs. This improves a condition where for instance, a device could receive S8-coded PDUs but would respond in S2 coded, so the peer device might be just out of reach to receive those. In this case, the host can instruct the controller to transmit with S8 as well.
Summary
Bluetooth v5.4 brought some new interesting features that will for sure expand the range of Bluetooth applications and help to standardize more markets. We are looking forward to seeing ecosystems grow and your new ideas brought to life. Our technical support team is here to help with evaluation and support on your projects. Follow our product news for updates on the availability of these features in nRF Connect SDK. Subscribe here.
Further reading:
- Technical overview of Bluetooth v5.4 (from Bluetooth SIG)
- Recording of a lecture about PAwR and ESL profile (from Bluetooth SIG)
- ESL profile specification
- ESL service specification
- Bluetooth v5.4 core specification
- Nordic Semiconductor: Bluetooth Low Energy
- Getting started with Bluetooth Electronic Shelf Labels (ESL) and Periodic Advertising with Responses (PAwR)
- Periodic Advertising with Responses (PAwR): A practical guide
Do you want more content like this? Feel free to like this blog post, and leave a comment below to tell us what you would like to use the new Bluetooth LE features for!
Top Comments