The Bluetooth Core Specification Version 5.0 includes LE Extended Advertising (EA) and LE Periodic Advertising (PADV) as enhancements over the LE legacy advertising feature. These features expand the potential for applications such as LE Audio Broadcasts.
In legacy advertising, each advertising event is intentionally interspersed with a small, random delay between 0 ms and 10 ms to prevent collisions. While effective for advertisers, this makes it difficult for scanners to predict the next event. As a result, scanners have to either frequently activate their radios or keep them on longer, leading to higher power consumption.
Periodic advertising, on the other hand, is a deterministic approach that enables advertising events to occur at fixed, predictable intervals.
Once a scanner has synchronized with a periodic advertiser, it knows exactly when to expect the next advertisement packet. This allows for selective activation of the scanner’s radio at predetermined times, resulting in significant power savings.
PADV also allows for frequent data updates and supports larger payloads than legacy advertising. This makes it more suitable for applications that require larger advertisement data or for those where the advertisement data changes periodically.
This article examines the layers of the Bluetooth LE protocol, specifically the PHY, LL, HCI, and GAP, to understand how they interact to enable PADV. It also explains how devices use PADV through the Basic Audio Profile (BAP) for advertising and discovering broadcast Audio Streams.
| Note: Starting from Bluetooth Core Version 5.4, there are two types of periodic advertising: ‘Periodic Advertising without Responses’ (introduced in Core 5.0) and ‘Periodic Advertising with Responses’ (introduced in Core 5.4). However, in this article, the mention of ‘periodic advertising’ refers to ‘Periodic Advertising without Responses’. |
Inside the Physical Layer (PHY)
The Physical Layer is the foundational layer in any wireless communication protocol, and Bluetooth LE is no exception. It’s responsible for the actual transmission and reception of raw data bits over the radio waves.
Here are the PHY’s four standout features that cater to periodic advertising:
1. Channel Use
Periodic advertising uses all the 40 RF channels Bluetooth LE provides. Three of these channels (37, 38, 39) are primary channels that send small header packets with pointers to the secondary channels (0-36). The secondary channels are then used to transmit synchronization information and advertisement data.
In legacy advertising, the advertisement data is sent on the primary channels. However, in periodic advertising, this data is moved to the secondary channels. This offloading reduces congestion on the primary channels since only small header pointers are sent there. It also increases frequency diversity, expanding the number of channels from 3 to 37.
Additionally, the secondary channels can handle larger advertisement messages, up to 254 bytes, compared to just 37 bytes in legacy advertising. And, if the advertisement data is too large for one packet, multiple packets on the secondary channels can be chained together, allowing for payloads up to 1650 bytes.
2. Versatility with PHY Radios
PADV supports all of the PHY radios—1M, 2M, and Coded PHY—to offer versatile solutions. The choice of PHY layer can be tailored to the application’s needs. For instance, the 2M PHY is best for high-speed data transfer, while the Coded PHY is designed for long-range transmissions, trading speed for greater distance.
3. Uses Channel Selection Algorithm #2 (CSA #2)
Bluetooth LE uses the Adaptive Frequency Hopping (AFH) technique to diversify its use of the 37 secondary channels. This helps maintain robust communication, especially in crowded radio environments.
AFH uses two algorithms—CSA #1 and the newer CSA #2, introduced in Bluetooth v5.0—for its channel selection process. PADV uses the CSA #2 algorithm. Table 1 compares the two, with CSA #2 showing improved interference handling compared to CSA #1.
| Paramater | CSA #1 | CSA #2 |
| Interference Handling | -It generates only 12 channel sequences. -Channel indices are selected sequentially with fixed hop intervals set during connection setup. This makes it less robust against interference. | -It offers more channel sequences and thus better interference resistance than CS#1. -To reduce the risk of channel overlap, it uses a pseudo-random number generator and varying inputs to derive semi-random channel indices. – The hopping sequence of CSA #2 is more unpredictable to outside parties than that of CSA #1. This unpredictability acts as a barrier against eavesdropping. |
Characteristics of the LE Periodic Physical Channel
The LE periodic physical channel uses pseudo-random RF frequencies and is optimized for advertisers to broadcast data to one or more listening scanners at fixed, precise intervals. The data can change between broadcasts. This channel has four main characteristics:
- Unique Identification: Each periodic advertisement packet on the channel includes a randomly generated 32-bit access address and an event counter. These elements identify the channel and help ensure that packets are accurately directed. This helps prevent collisions, especially in crowded areas where two or more devices try to transmit data on the same frequency at the same time.
- Channel Control: Advertisers control the LE periodic physical channel, choosing which RF channels to use and when to send out the data. Scanners, on the other hand, can only listen and receive data; they cannot send anything back on this channel.
- Periodic Advertising Events: The LE periodic physical channel is divided into regular time units called periodic advertising events. Each event has its own RF channel. The first packet, sent after the channel is established, sets the timing for all subsequent events.
- Topology: The LE periodic physical channel supports an unlimited number of LE devices for both advertising and scanning. Scanners can also synchronize to multiple LE periodic physical channels at the same time, allowing them to receive data from several sources simultaneously.
- Unreliable: The LE periodic physical channel is unreliable. There is no guarantee that all sent packets are received, and even when the scanner detects errors in the received packets, it cannot request a retransmission. Unlike isochronous streams, PADV does not have retransmission mechanisms to resend the same data packet during the same transmission event to improve robustness. If advertisement data is missed during a PADV event, it may not be received unless repeated in a later PADV event.
Inside the Link Layer (LL) and the Host Controller Interface (HCI)
Bluetooth LE’s LL provides roles, radio states, PDU types, and advertising options to accommodate the PADV feature. The HCI standardizes communication between the Host and Controller in the periodic advertiser and scanner.
To illustrate how the LL and HCI components interact, below is an example involving two devices—Device A and Device B. Device A is the LL advertiser and Device B is the LL scanner.
Device A : Initiating Periodic Advertising
Periodic advertising is a feature that enables an LE Controller to send advertisements at fixed, regular intervals. The advertisement data can be updated or kept the same, depending on the application’s needs. This feature also allows scanners to discover the advertising device’s schedule and synchronize their scanning to it.
PADV requires two types of data: the actual advertisement data, or user-plane data, and the control information, or control-plane data, known as periodic advertising synchronization information.
The periodic advertiser, Device A, sends advertisement data in a series of regular time units called periodic advertising events. The time interval between the periodic advertising events is known as the periodic advertising interval. It ranges from 7.5 ms to 81.91875 s, with increments of 1.25 ms.
The data is transmitted using the AUX_SYNC_IND PADV PDU. If the data exceeds 254 octets, it is split across one or more AUX_CHAIN_IND PDUs. Together, the AUX_SYNC_IND and AUX_CHAIN_IND PDUs form a periodic advertising train. And so, each periodic advertising event starts with an AUX_SYNC_IND PDU, followed by zero or more AUX_CHAIN_IND PDUs.
To enable scanner devices to discover and receive the periodic advertising train, Device A transmits synchronization information using EA PDUs.
During EA, Device A sends out ADV_EXT_IND PDUs over the primary channels. These packets contain an Auxiliary Pointer (AuxPtr) [Volume 6, Part B, Section 2.3.4.5]. The AuxPtr specifies the secondary channel index, timing offset, and PHY of the AUX_ADV_IND EA PDU.
To set up Device A for PADV, the Host first configures the parameters for EA and PADV using the ‘HCI LE Set Extended Advertising Parameters’ and ‘HCI LE Set Periodic Advertising Parameters’ commands. Both advertising features require their parameters to be set before they can be enabled.
Next, the Host enables PADV first, followed by EA, using the ‘HCI LE Set Periodic Advertising Enable’ command and the ‘HCI LE Set Extended Advertising Enable’ command.
| Note: PADV is enabled before EA because EA will not start providing SyncInfo until the PADV is enabled. The type of EA associated with PADV should be non-connectable and non-scannable. |
Once PADV and EA are enabled, Device A’s LL enters the LL Advertising State, allowing it to start sending EA and PADV advertisements. To add actual advertisement data to the periodic advertising train, the Host uses the ‘HCI LE Set Periodic Advertising Data’ command.
| Note: The actual advertisement data can be changed multiple times while periodic advertising is enabled, by calling the ‘LE Set Periodic Advertising Data’ command. |
Device B: Scanning for Periodic Advertisements
For Device B to receive Device A’s periodic advertising train, it first needs to obtain the AUX_ADV_IND EA PDU from Device A. Device B then uses the SyncInfo in this PDU to locate and synchronize with the periodic advertising train. The procedure to obtain the SynInfo is called the periodic advertising synchronization establishment procedure.
There are two methods for implementing this procedure: the scanning procedure and the Periodic Advertisement Synchronization Transfer (PAST) procedure [Volume 6, Part B Section 5.1.13].
This article only focuses on how to use the scanning procedure to listen for non-connectable and non-scannable EA PDUs that contain synchronization information about a periodic advertising train.
To set up and enable scanning, Device B’s Host uses the ‘HCI LE Set Extended Scan Parameters’ and ‘HCI LE Set Extended Scan Enable’ commands. This makes Device B’s LL transition from the Standby State to Scanning State to listen for the ADV_EXT_IND PDU from Device A.
When Device B’s LL receives the ADV_EXT_IND PDUs, it reads the AuxPtr field to find the secondary channel and timing offset needed to receive the AUX_ADV_IND PDU with the synchronization information for Device A’s periodic advertising train.
After obtaining the complete synchronization information, Device B’s Host uses the ‘HCI LE Periodic Advertising Create Sync’ command to tell Device B’s LL to start a new state machine that immediately transitions to the Synchronization State.
| Note: Before the scanner can enter the Synchronization State, it needs all the periodic advertising synchronization information. If the sync Packet Offset value in the SyncInfo is zero, that means the information isn’t complete yet. In that case, the scanner should wait for the next advertisement to get the remaining information. |
The Synchronization state has two sub-states: ‘Synchronizing’ and ‘Synchronized.’ In the Synchronizing sub-state of the Synchronization State, Device B has all the synchronization information and uses it to receive the first AUX_SYNC_IND PDU.
| Note: In the Synchronizing sub-state, if the Controller doesn’t receive any AUX_SYNC_IND PDU within 6 periodic advertising events, starting from the first event it listened for, the device returns to the Stand-by State. |
When Device B’s LL receives this PDU, it notifies the Host with an ‘LE Periodic Advertising Sync Established’ event. Device B is then considered synchronized with the periodic advertiser and moves to the Synchronized sub-state in the Synchronization State to listen for periodic advertisements. If periodic advertising reporting is enabled, all received PADV packets will be reported to the Host.
Periodic Sync Establishment Link layer Filter Policy
The periodic sync establishment filter policy enables a scanner to manage and prioritize which EA PDUs to process when synchronizing with a periodic advertising train. It lets the scanner focus on PDUs from a specific device or those from a predefined list of advertisers. This helps the scanner ignore irrelevant data and reduces unnecessary processing.
This filter policy provides two modes, but only one can be used at a time:
- The Link Layer can ignore the Periodic Advertiser List and focus on a specific device chosen by the Host.
- The Link Layer can process advertising PDUs from all devices in the Periodic Advertiser List.
With this filter policy, PDUs from advertisers that are not on the Periodic Advertiser List or have incorrect Advertising SIDs [Volume 6, Part B Section 2.3.4.4] are ignored.
Inside the Generic Access Profile (GAP)
To accommodate periodic advertising, the GAP layer defines the following roles, operational access mode and procedure pairs :
- GAP Broadcaster and GAP Observer roles
- Periodic Advertising Synchronizability mode and Periodic Advertising Synchronization Establishment procedure
- Periodic Advertising mode and Periodic Advertising Synchronization Establishment procedure
GAP Roles for PADV
For unidirectional connectionless communication between LE devices using extended and periodic advertising events, the GAP layer mandates two clear role assignments: one device must act as a Broadcaster. This device configures its LL as an advertiser and broadcasts periodic advertising synchronization information and periodic advertisements.
Concurrently, at least one other device must take on the Observer role. Such a device sets its LL to operate as a scanner. It performs the periodic advertising synchronization establishment procedure and listens for the periodic advertising synchronization information and the periodic advertisements sent by the GAP Broadcaster.
GAP Modes and Procedures
Typically, when two devices interact at GAP level, one enters a mode and the other executes a procedure.
First Mode-Procedure Pair: Synchronization
- Periodic Advertising Synchronizability Mode: A GAP Broadcaster uses the periodic advertising synchronizability mode to send the periodic advertising synchronization information using non-connectable and non-scannable extended advertising events.
- Periodic Advertising Synchronization Establishment procedure: A GAP Observer uses the periodic advertising synchronization establishment procedure to scan for extended advertising events that carry the periodic advertising synchronization information.
Second Mode-Procedure Pair: Data Transfer
- Periodic Advertising Mode: A GAP Broadcaster implements the periodic advertising mode to send advertising data using periodic advertising events.
- Periodic Advertising Synchronization Establishment Procedure: A GAP Observer uses the periodic advertising synchronization establishment procedure to receive the periodic advertisements.
Periodic Advertising and LE Audio
The BAP profile defines the Broadcast Source role for a device that broadcasts audio data using one or more Broadcast Isochronous Streams (BISes) within a Broadcast Isochronous Group (BIG). A periodic advertising train associated with each BIG.
A Broadcast Source uses periodic advertising to send Basic Audio Announcements, which help other devices discover and receive a BIG with relevant broadcast Audio Streams.
These Basic Audio Announcements include the Basic Audio Announcement UUID and Broadcast Audio Source Endpoint (BASE) information. Both are found in the AdvData field [Volume 6, Part B Section 2.3.4.4] of the AUX_SYNC_IND PADV PDU.
The BASE data describes the broadcast Audio Stream. It provides details like codec audio capabilities, audio location of the rendering device, language, and audio ContextType or use-case.
The Broadcast Source also uses PADV to send synchronization information, called BIGInfo, which is necessary for locating and syncing with the BIG and BIS timings. BIGInfo is found in the ACAD field [Volume 6, Part B Section 2.3.4.8] of the AUX_SYNC_IND PADV PDU.
To discover Basic Audio Announcements, listening devices scan for EA PDUs containing Broadcast Audio Announcements. These announcements include the Broadcast Audio Announcement UUID and possibly a Broadcast_ID and a Broadcast Name.
The UUID tells devices that the EA PDUs point to a periodic advertising train associated with a BIG. The Broadcast_ID is unique to each BIG and it helps devices quickly determine if the referenced BIG is relevant to them.
After a listening device receives an EA PDU containing the relevant Broadcast Audio Announcements, it uses the SyncInfo in the EA PDU to synchronize with the PADV. It then accesses the Broadcast Audio Announcements and BIGInfo in the indicated PADV PDU to find and synchronize with the appropriate BIG and BIS(es).
Concluding Remarks
The Bluetooth Specification has evolved to include periodic advertising, a significant improvement over legacy advertising. This enhancement is a key component in meeting the demands of broadcasting isochronous streams in emerging applications like LE Audio broadcasts. Key layers such as PHY, LL, HCI, and GAP have been revised to support the periodic advertising feature.
In unidirectional connectionless communication via periodic advertising, the Broadcaster must first share synchronization information about the periodic advertising train. Observers can gather this synchronization information in two main ways. One is through scanning, as detailed in this article. The other is via the PAST feature, which is discussed in the Fundamentals Series: Periodic Advertising Sync Transfer article.
References & Additional Resources
- “Core Specification 5.0” Bluetooth.com, www.bluetooth.com/specifications/specs/core-specification-5-0/. Accessed 01 Sep. 2023
- “Core Specification 5.4” Bluetooth.com, www.bluetooth.com/specifications/specs/core-specification-5-4/. Accessed 27 Oct. 2023.
- “The Bluetooth® Low Energy Primer”, Bluetooth.com, https://www.bluetooth.com/bluetooth-resources/the-bluetooth-low-energy-primer/ Accessed 27 Oct. 2023
- “Discovering Auracast™ – The Public Broadcast Profile”, Cloud2GND.com, https://cloud2gnd.com/discovering-auracast-the-public-broadcast-profile/
