What’s New in Bluetooth 5.4?

What’s New in Bluetooth 5.4?

The Bluetooth Special Interest Group (SIG) continues to evolve and make new technical advancements with the Bluetooth wireless protocol. It seems the Bluetooth SIG just completed its launch of the LE Audio specification and now the SIG has released yet its newest standard, Bluetooth 5.4. Bluetooth 5.4 introduces several new features that enable the exchange of application data using secure, connectionless bidirectional communication which was not previously possible with Bluetooth LE. These new enhancements allow for more scalability, energy efficiency, flexibility in topologies supported and is well suited to applications requiring bi-directional messages between a central hub and a large number of devices. 

Highlights of Bluetooth 5.4 are:

• Periodic Advertising with Response (PAwR)
• Encrypted Advertising Data
• LE GATT Security Levels Characteristic
• Advertising Coding Selection.

In this post, we’ll discuss some of the most significant points of each feature of the recently completed specification including the upcoming Electronic Shelf Label (ESL) Profile. The ESL industry as well as other industries requiring support of large many-to-one network topologies will be able to take advantage of the new Bluetooth 5.4 features to support a standards-based solution. 

Periodic Advertising with Response (PAwR)

PAwR is the key feature of Bluetooth 5.4 that allows for the bidirectional data exchange in a large one-to-many connectionless topology. To fully understand how PAwR works and its benefits it is important to first review the evolution on Bluetooth LE advertising. The original form of advertising is now known as Legacy Advertising. Extended advertising was introduced in Bluetooth 5. This feature added two additional ways advertisements can be made in addition to Legacy Advertising: Irregular Extended Advertising and LE Periodic Advertising Broadcast (PADVB).

Legacy Advertising

The original form of advertising known as Legacy Advertising transmitted identical copies of application data in packets on three primary channels (37, 38, 39), one channel at a time. Advertising occurs at a pseudo-random sequence across the three channels at a regular scheduled advertising interval. To help avoid persistent collisions with other advertising devices, advertisements are made slightly irregular with the addition of a pseudo-random value (advDelay) of 0 – 10mS added to the scheduled interval. The addition of advDelay results in what is considered irregular scheduling of advertising events. Legacy advertising is considered unidirectional as only the advertising packets can contain application data. 

Extended Advertising – Irregular Extended Advertising

To distinguish between the two new modes of advertising, this mode is referred to as “Irregular” Extended Advertising due to the irregular delay of 0-10mS added to the scheduled interval. 

Irregular Extended Advertising is similar to Legacy Advertising but now allows for packets to be up to 255 bytes. This is accomplished by offloading application data onto one of the other 37 channels previously only used for connection events. 

Only header data, including a new field AuxPtr, is transmitted on the three primary channels via a new advertisement PDU, ADV_EXT_IND. The AuxPtr field provides a pointer to the packet containing the actual application data transmitted on a secondary channel (channels 0 – 36). Secondary channel advertisements are made using AUX_ADV_IND PDUs.

Extended advertising packets can also be chained to support even larger amounts of data to broadcast. Up to six 255 byte PDU’s can be chained for up to 1650 bytes total of application data.

Extended Advertising – LE Periodic Advertising Broadcast (PADVB)

The random delays (0 – 10mS) included in each advertising event of Legacy Advertising and Irregular Extended Advertising makes it impossible for an observer to determine the advertising schedule. PADVB  adds the ability to perform periodic and deterministic advertising which allows observers to synchronize their scanning with the schedule of the advertising device. PADVB, as with Irregular Extended Advertising, makes use of the 37 channels previously used only by connection events. Again, the ADV_EXT_IND PDU is transmitted on primary advertisement channels and contains the AuxPtr field which points to an associated AUX_ADV_IND PDU transmitted on the secondary channels. This PDU contains a new header field; SyncInfo, which  provides Synchronization Information including timing and timing offset information. With synchronization information obtained from the AUX_ADV_IND PDU the observer will only scan now for a new PDU type called AUX_SYNC_PDU_IND. This new advertisement PDU will occur at known timing intervals allowing an observer to only scan for application data at a precise time making the scanning device more energy efficient. PADVB supports unidirectional communication as observers can’t respond to the AUX_SYNC_PDU_IND.

Figure 1: LE Periodic Advertising Broadcast (PADVB)

Periodic Advertising Sync Transfer (PAST)

Bluetooth 5.1 added the ability for acquired synchronization details to be passed to another device over a point-to-point LE-ACL connection. The periodic advertising synchronization procedure can be an expensive power procedure itself. PAST allows for a smaller more power constrained device to receive synchronization data acquired from a less-constrained device. A device can also have synchronization details passed directly from the broadcasting device itself using a LE-ACL connection. 

Periodic Advertising with Response (PAwR)

Transfer of Application data prior to Bluetooth 5.4 was accomplished via unidirectional advertisements in a one-to-many network topology. However, if bidirectional transfer of application data is required multiple LE-ACL connections or LE CIS streams from a single Central device to multiple peripheral devices can be established. Bidirectional connections are considered multiple individual one-to-one connections and the number of active connections that can be supported are limited by both memory size and Bluetooth stack. Previously these Bluetooth network topologies were not well suited for applications that need to send and receive messages between a single central device a large number of other devices. Bluetooth 5.4 has introduced Periodic Advertising with Response (PAwR) which now allows for bidirectional transfer of application data between a single central device and a large number of other devices in a star network topology. 

PAwR builds upon Periodic Advertising introduced in Bluetooth 5.0 where the procedure of acquiring advertising synchronization information is obtained by an observer during scanning. PAwR now enables bidirectional connectionless transfer of small amounts of data by adding response slots as periodic advertising subevents during a periodic advertising interval. It should be noted that if larger data transfer is needed PAwR allows for an advertising or broadcasting device to use its transmission slot to send a connection request to a specific device in the network and establish an LE-ACL connection. This is not supported in Periodic advertising (PADVB). 

With PADVB, the same application data is transmitted by a broadcasting device to all observers. PAwR allows each observer or group of observers to receive different data during a deterministic time slot.

As with PADVB , an observer scans for AUX_ADV_IND PDU’s transmitted on secondary channels pointed to by the channel AuxPtr field in the ADV_EXT_IND PDU transmitted on the primary channel. Synchronization information regarding periodic advertising interval and other data items is acquired via the AUX_ADV_IND SyncInfo field and an observer can calculate when PAwR events will occur. 

A PAwR event contains several subevents with each subevent consisting of a Broadcast data AUX_SYNC_SUBEVENT_IND PDU or connection request AUX_CONNECT_REQ PDU transmitted at a known PAwR subevent interval. Responses to AUX_SYNC_SUBEVENT_IND PDU’s are followed by a series of slots reserved for AUX_SYNC_SUBEVENT_RSP response PDU’s sent by Observers.

Figure 2: PAwR Periodic Advertising Event and Subevent Intervals

PAwR uses Channel Selection Algorithm #2 introduced in Bluetooth 5.0 to select the channel each PAwR subevent will take place at. Response PDUs in a subevent will use the same channel as the Broadcast AUX_SYNC_SUBEVENT_IND PDU.

Observers need additional information about the subevents that will tell them how often they occur, how many subevents each PAwR event consists of as well as which subevent # and particular response time slot in which it should schedule its scanning. Subevent and response slot info is found in the AUX_ADV_IND PDU which adds a new AD type called Periodic Advertising Response Timing Information and is transmitted in the Additional Controller Advertising (ACAD) Information field. 

Figure 3: PAwR AD Type in AUX_ADV_IND PDU

Observer devices (or multiple observers) need information as to which subevent it should synchronize its scanning to. Information for determining which subevent response slot to use is also needed. The application layer is responsible for determining and providing these details to observing devices. 

In the case of Electronic Shelf Label the profile deals with these details. A broadcasting device (defined as AP) establishes an LE ACL connection with the electronic shelf label device and configures various GATT characteristics. These include assignment of an ESL ID and a group ID with its value being used to indicate which subevent the label should scan on. 

In ESL, the response slot is dynamically allocated. The Broadcast payload can include one or more commands, each addressed to a specific ESL ID or ID’s within a group. The commands are transmitted as the payload of a PAwR AUX_SYNC_SUBEVENT_IND PDU during a PAwR subevent. All ESL’s that are part of that group receive the transmitted packet which contains the ESL ID or ID’s in which the messages are intended. ESL’s addresses by the command will process the command and respond with an AUX_SYNC_SUBEVENT_RSP PDU in the order each received the command. If only a single ESL was addressed in the command it will respond during slot 0. If multiple ESL’s are addressed such as ESL 0, ESL 1, ESL 6 for example, ESL 0 will respond in slot 0, ESL 1 will respond in slot 1 and ESL 6 will respond in slot 2 since it was the third in the command array.

Encrypted Advertising Data

The addition of PAwR to the Bluetooth 5.4 specification removes limitations for applications such as ESL that require two-way communication in large one-to-many networks using a standardized protocol. However, as with all IoT devices and networks secure data exchange is a must. Previously secure communication could only be completed for connection-oriented communication. Bluetooth 5.4 has added Encrypted Advertising data as a new feature to address the need for confidential bidirectional communication of encrypted data in advertisements and scan response packets. 

Key material needed for encrypting and decrypting data is exchanged by devices by establishing an LE ACL connection. The device that will be transmitting data needs to provide secret key material to a receiving device or devices. This requires the transmit device to act as a GAP Peripheral where it can advertise and accept a connection request from a GAP Central device. 

Encrypted Advertising Data introduces a new characteristic; Encrypted Data Key Material, that the GAP Peripheral can include as a service. This service contains a 16-octel session key and 8-octet Initialization Vector (IV) that the GATT client can read over an encrypted LE ACL connection. 

The Encrypted Advertising Data feature introduces a new advertising data (AD) type called Encrypted Data which is used to carry a sequence of one or more AD types that need to be encrypted. When encryption is needed by more than a single AD type the AT types are first concatenated and encrypted together to form a single AD structure. AD types not needing to be encrypted can also be included in the same packets as the encrypted AD types. This allows portions of an advertisement packet to be exposed to any observer while other portions needing confidentiality can only be read by an intended observer having the shared secret key material. 

The LE GATT Security Levels Characteristic

When a GATT Client attempts to access a servers attributes (characteristics, descriptors) the attributes permissions are checked. If permissions are insufficient, the access is denied and all GATT features will not work properly. The client may upgrade its security level resulting in required user interaction with the device to reattempt access of the previous failed operation. 

The LE GATT Security Levels Characteristic has been added in Bluetooth 5.4 and is intended to create a better user experience to avoid interruptions in application flow caused by insufficient security conditions being met. LE GATT Security Levels Characteristic allows devices to show what security mode and level is needed for accessing all GATT server features before attempting to access GATT attributes. 

Advertising Coding Selection

For LE Coded PHY, a Forward Error Correction (FEC) algorithm is used which results in significantly longer transmission distances to be achieved. The FEC parameter (S) uses one of two values (S=2 or S=8) and controls how much data is made to fix errors and how much Bluetooth range may be achieved. S=8 coding parameter can increase the range by about 4x that of 1M PHY but lowers the data rate to 125Kbps. S=2 can increase the range by about 2x that of 1M PHY but lowers the data rate to 500Kbps

Prior to Bluetooth 5.4, specifying the value of the S coding parameter for LE Coded PHY which was to be used with extended advertising was not possible. Bluetooth 5.4 makes changes to HCI commands that allow the value for the FEC S parameter to be specified when using LE Coded PHY.

Summary

Bluetooth 5.4 introduces new features such as PAwR and Encrypted Advertisement Data that can provide a standards-based solution for Electronic Shelf Label applications. Previously the Electronic Shelf Industry (ESL) has been based on proprietary wireless protocols creating challenges in widespread adoption due to limitations in interoperability. The Bluetooth Special Interest Group (SIG) worked with members of the ESL industry to create a global standard that is highly scalable, secure and low power. The SIG has also defined a new profile called the Electronic Shelf Label Profile that makes use of Bluetooth 5.4 features and ensure ESL systems are backed by a proven standardized qualification program.

Bluetooth 5.4 features can be incorporated into firmware as new hardware is not needed to support these features. Ezurio's (formerly Laird Connectivity) portfolio includes several Nordic-based and Silicon Labs-based Bluetooth LE modules. Additionally, Silicon Labs has stated their BG22 and BG24 wireless microcontrollers will begin supporting Bluetooth 5.4. Nordic’s nRF Connect SDK is sure to also begin adding Bluetooth 5.4 features as well. 

Ezurio's Nordic-based modules include the BL65x family and utilize devices from the nRF528xx series of microcontrollers. Also, the Nordic-based BL5340 uses the nRF5340 wireless microcontroller.

Ezurio's Silicon Labs based modules include the Lyra P and Lyra S, both of which make use of the BG22 wireless microcontroller. Lyra 24 will use the BG24 wireless microcontroller.