Foundations of LE Audio: Periodic Advertising

The Bluetooth Specification was updated to include extended advertising and periodic advertising as enhancements over legacy advertising, expanding the potential for applications like LE Audio Broadcasts.

In Bluetooth LE’s 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.

The introduction of the Bluetooth Core Specification Version 5.0 marked a turning point, introducing ‘periodic advertising.’ This deterministic approach ensures that advertising occurs at predictable intervals.

Once a scanner syncs with a periodic advertiser, it knows exactly when to expect the next packet. This allows for selective activation of the scanner’s radio at predetermined times, resulting in significant power savings.

Importantly, periodic advertising offers the distinct advantage of frequent data changes, unlike its legacy counterpart. This makes it ideal for applications requiring frequently updated broadcasts.

Moreover, periodic advertising also supports the transmission of larger data packets. Being a component of the extended advertising feature, it uses secondary channels to relay heftier advertising messages. These packets can hold up to 254 octets each and be chained to deliver an impressive total of 1650 octets.

In this article, we’ll take a closer look at the layers of the Bluetooth LE protocol—focusing on the PHY, LL, HCI, and the GAP—and explore how they intertwine to make periodic advertising a reality.

Note: In Core Version 5.4 onwards, there are two types of ‘periodic advertising’:’Periodic advertising without responses’ (introduced in Core 5.0) and ‘Periodic advertising with responses’ (a new, enhanced option that will be described in another article). In this article, when we mention ‘periodic advertising’, we’re referring to the ‘periodic advertising without responses’ type.

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 to cater for periodic advertising:

1. Channel Utilization

Periodic advertising uses all 40 RF channels available in Bluetooth LE. Specifically, three primary channels (CH37, CH38, CH39) handle the transmission of pointers which direct to the secondary channels (CH0-CH36). The secondary channels are dynamically allocated for conveying synchronization information and the periodic advertising train.

This offloading strategy alleviates potential bottlenecks on the primary channels,and also provides more bandwidth to relay longer advertising messages, thereby enhancing overall system efficiency.

2. Versatility with PHY Radios

Periodic advertising is a subset of the LE extended advertising feature and thus leverages the complete range of PHY radios—1M, 2M, and Coded PHY—to offer versatile solutions. The selection of the PHY layer can be strategically aligned with the application’s specific requirements.

For example, the 2M PHY is ideally suited for high-speed data transfer, while the Coded PHY is engineered for long-range transmissions, deliberately sacrificing speed for extended reach.

3. Channel Selection Algorithm #2 (CSA #2)

Bluetooth LE uses the Adaptive Frequency Hopping (AFH) technique to diversify its use of the 37 secondary channels, to 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. Devices compliant with BLE 5.0 default to CSA #2, and here’s why that’s a significant upgrade:

• Compatibility: Unlike CSA #1, which is limited to connection events, CSA #2 is adaptable for both connection and periodic advertising events.
• Improved Interference Handling: CSA #1 is limited to producing only 12 distinct channel sequences. Also, channels are selected sequentially based on fixed hop intervals determined during connection establishment, which make it less robust against interference.
  CSA #2, on the other hand, offers a wider variety of channel sequences and better interference tolerance. It uses a pseudo-random number generator, and a changing event counter along with the device’s access address, to calculate semi-random channel indices. This approach minimizes channel overlap and significantly reduces the risk of channel collisions.

Nuances of CSA #2 in Periodic Advertising

Each periodic advertising event—also known as a ‘periodic advertising train’—features a 16-bit event counter (paEventCounter). The starting value of this counter depends on how the system is set up. However, the counter increases by one for every periodic advertising interval.

This counter, and the 16-bit access address of the periodic advertiser (known as channel Identifier), are fed to CSA #2’s pseudo-random number generator. From this, a pseudo-random number is generated and then processed using a modulo-37 operation to decide the channel index.

If the selected channel happens to be blocked because it had been marked as having a lot of interference, CSA #2 uses a remapping algorithm and reassigns an available alternative.

Moreover, in addition to its high interference tolerance, the hopping sequence of CSA #2 is more unpredictable than that of CSA #1. This unpredictability acts as a barrier against eavesdropping.

Inside the Link Layer (LL) and the Host Controller Interface (HCI)

Bluetooth LE’s Link Layer also has specialized roles, radio states, PDU types, and advertising options to accommodate the periodic advertising feature. The HCI standardizes how the host communicates with the controller. The host uses HCI command packets for sending commands to the controller, and event packets relay notifications back to the host.

To better illustrate how these components interact, let’s delve into an example involving two devices—Device A and Device B.

Device A : Initiating Periodic Advertising

A section from the Bluetooth Specification (version 5.4 | Vol 6, Part B, section 4.4.2.12) describes periodic advertising as follows: “When advertising data is required to be sent regularly at a fixed interval, periodic advertising is used. Periodic advertising consists of advertisements sent at a fixed interval, with the advertisement data changing from time to time.”

To set up Device A as a periodic advertiser, follow these steps:

1. Setting Up Extended Advertising and Periodic Advertising Parameters

Device A prepares two crucial sets of data for periodic advertising:

• Control Information for Synchronization: This control information is broadcasted using extended advertising events. It allows scanner devices to sync with Device A’s advertising schedule. It is encapsulated in the SyncInfo field of the AUX_ADV_IND extended advertising packet.
• Advertisement Data: The actual advertisement data are stored in AUX_SYNC_IND packet and, for data exceeding 254 octets, in additional AUX_CHAIN_IND packets. This advertising data can be changed regularly and it is broadcasted at regular intervals using periodic advertising events.

This step is achieved using the ‘HCI LE Set Extended Advertising Parameters’ and the ‘HCI LE Set Periodic Advertising Parameters’ commands respectively.

For the parameter list of the HCI_LE Set Extended Advertising Parameters Command, the following details must be provided:

• Advertising_Event_Properties: Define the advertising options. Can the advertising be scannable, connectable, both, or neither? It’s important to note that according to specification, for periodic advertising, events are required to be non-connectable and non-scannable.
• Primary_Advertising_Interval_Min & Primary_Advertising_Interval_Max: Specify the minimum and maximum time intervals for broadcasting ADV_EXT_IND packets on primary channels. The permitted range spans from 20 ms to 10,485.759375 s.
• Primary_Advertising_Channel_Map: Choose the primary channels for broadcasting the ADV_EXT_IND packets. By default, all three primary channels are used, but you have the flexibility to modify this.
• Primary_Advertising_PHY: Opt for the PHY layer to be used for the primary advertising channels. The available choices are 1M and LE Coded PHY.
• Secondary_Advertising_PHY: Select the PHY layer for the secondary advertising channels. The options here include 1M, 2M, and LE Coded.
• Secondary_Advertising_Max_Skip: Specify the maximum number of advertising events to skip before sending the AUX_ADV_IND packet, which includes synchronization control information. Select a value between 1 and 255.
• Advertising_SID: Extended advertising allows up to 16 unique advertising sets. A value between 0 and 15 needs to be designated for the selected set. This identifier will appear in the ADI field of the extended header for all packets belonging to this set.

Upon successful execution of the HCI_LE_Set_Extended_Advertising_Parameters command, an HCI_Command_Complete event will be generated, confirming that your settings have been applied.

Secondly, for the HCI LE Set Periodic Advertising Parameters command, the main information you need to prepare is:

• Periodic_Advertising_Interval_Min & Periodic_Advertising_Interval_Max: Decide on the interval for your periodic advertising events. Choose between 5 ms and 81.91875 s. While the Core specification allows the minimum and maximum intervals to be the same, it’s often recommended to set differing values. This provides the controller with flexibility to optimize the advertising interval based on other activities. However, theremay be situations where a specific interval is required, such as compliance with a particular protocol or standard.

Upon executing the HCI_LE_Set_Periodic_Advertising_Parameters command, as shown in the figure 4 below, an HCI_Command_Complete event will be generated.

Note: It’s worth noting that the actual data that is periodically advertised can be changed multiple times while periodic advertising is enabled, by calling the LE Set Periodic Advertising Data command.

2. Performing the Advertising Procedure

The Bluetooth Specification (Vol 1, Part A, Section 4.2.2.7) defines the advertising procedure as, “the procedure where the device uses the primary and secondary advertising physical channel to broadcast control information about the periodic advertising, referred to as the periodic advertising synchronization information.“

To broadcast the periodic advertising synchronization information, the Host sends the HCI “LE Set Extended Advertising Enable Command” to Device A’s link layer. Upon receiving this command, Device A’s controller transitions its radio from the stand-by state to the advertising state, where it carries out the advertising procedure:

• Broadcast Control Information: Device A sends out ADV_EXT_IND packets over its primary channels. These packets contain an ‘AuxPtr’ field, which specifies the secondary channel index , the timing offset and the PHY of the AUX_ADV_IND packet that contains the control information for its periodic advertising train.

3. Periodic Advertising Events

To broadcast the periodic advertising train, the Host sends the HCI “LE Set Periodic Advertising Enable Command” to Device A’s link layer.

• Send Advertising data at periodic and deterministic intervals: Using the channel index, timing offset and PHY specified in the ‘AuxPtr’ field of the AUX_ADV_IND packet, Device A begins its periodic advertising. Here, it broadcasts AUX_SYNC_IND packets containing the advertising data, and possibly additional AUX_CHAIN_IND packets for larger datasets.

The figure below gives a good overview of the above steps:

Device B: The Scanning Process for Synchronization

Device B can use two methods to synchronize with an advertiser’s schedule. The scanning procedure and the Periodic Advertisement Synchronization Transfer (PAST) procedure (introduced in Core 5.1). However, for the current discussion, the scanning procedure will be explored.

To set up Device B as a synchronized scanner, it performs the periodic advertising synchronization establishment procedure. For that, it needs to undertake two primary steps: first, scan for control information related to the periodic advertising train; second, establish a periodic advertising sync to receive the periodic adverts.

These actions are executed using the HCI LE Set Extended Scan Parameters and the HCI LE Periodic Advertising Create Sync commands, as shown in Figure 6 below.

To configure Device B using the HCI LE Set Extended Scan Parameters command, the following details must be provided:

• Scanning_PHYs: Decide on the PHYs that the scanner should focus on for receiving ADV_EXT_IND advertisement packets. The available choices are LE 1M PHY, LE Coded PHY, or both.
• Scan_Type[i]: Determine the scanning mode. Two options are presented: active scanning, which allows the device to send scan request PDUs, and passive scanning. Given that periodic advertisements are neither connectable nor scannable, opting for passive scanning is advisable.
• Scan_Interval[i]: Set the scanning interval for the link layer’s scanning events. The permissible range for this interval lies between 2.5 ms and 40.959375 s.
• Scan_Window[i]: Specify the duration the scanner will spend on the primary advertising channel(s). Again, the allowable window is constrained between 2.5 ms and 40.959375s.

Once these extended advertising parameters are in place, your device is primed to listen for ADV_EXD_IND and AUX_ADV_IND packets. This enables it to collect the necessary synchronization control information for the next phase: entering the synchronization state.

The process by which Device B scans for this synchronization control information can be outlined as follows:

1. Stand-by to Scanning State: When Device B wants to receive periodic advertisements from Device A, its host instructs its Link Layer to transition from the stand-by state into the scanning state. The scanning task is simple yet pivotal: locate ADV_EXT_IND packets from Device A.
2. Locating the SyncInfo: After capturing an ADV_EXT_IND packet, Device B zeroes in on the ‘AuxPtr’ field. This field guides Device B to the secondary channel and provides a timing offset, both of which are necessary to locate the ADV_AUX_IND packet. This latter packet is a goldmine—it contains the synchronization details for Device A’s periodic advertising train.

Upon receiving complete synchronization information, the host directs the link layer to initiate a new state machine that promptly transitions into the Synchronization state, while the existing state machine continues to operate in the Scanning state.

The Synchronization state has two sub-states: ‘Synchronizing’ and ‘Synchronized.’ In the Synchronizing sub-state, Device B leverages the gathered synchronization information to successfully capture the first ADV_SYNC_IND packet. Once this packet is received, Device B is considered to be in sync with the periodic advertiser, Device A. It then transitions to the Synchronized sub-state to listen for the periodic adverts.

The host uses the HCI_LE_Periodic_Advertising_Create_Sync command to instruct the link layer to enter the synchronization state. And for this HCI command, the following details are to be provided:

• Option Parameters: Options are available for the scanner to determine which periodic advertiser to synchronize with. Either a periodic advertiser list can be used or specific parameters such as Advertising_SID, Advertiser Address_Type, and Advertiser Address can be selected. Choices also exist regarding whether the scanner should filter incoming advertisements and if it should dispatch an HCI_LE_Periodic_Advertising_Report event to the host for every received event.
• Skip: his parameter dictates the maximum number of consecutive periodic advertising events the scanner might skip following a successful reception. The skip count varies between 0 (0x0000) and 499 (0x01F3).
• Sync_Timeout: This setting determines the maximal permissible time between successive packet receptions. If a packet is not received within this interval, synchronization is lost. The acceptable timeout spans from 100 ms to 163.84 s, with the calculation being Time = N × 10 ms, and N ranging from 0x000A to 0x4000.

After configuration, the controller sends a LE Periodic Advertising Sync Established event upon receiving the first ADV_SYNC_IND packet. Subsequent ADV_SYNC_IND packets will generate reports to the host if HCI_LE_Periodic_Advertising_Report is enabled.

Note: Once synced, the scanner only listens to ADV_SYNC_IND packets and not the ADV_EXT_IND and the AUX_ADV_IND packets. Synchronization is lost and reset if the Sync Timeout is exceeded.

Periodic Sync Establishment Link layer Filter Policy

When scanning, each periodic advertisement event is reported back to the application. In environments saturated with advertising activities, indiscriminate processing of all advertisements can severely strain memory and power resources.

To counteract this, the link layer provides the periodic sync establishment filter policy. The policy mitigates this by selectively filtering periodic advertising PDUs to reduce the amount of advertising report notifications to the host, thus reducing the heap usage and risk of stack overflow.

This policy dictates how a scanner’s Link layer handles advertising PDUs to sync with a periodic advertising train. It operates in one of two modes set by the Host:

• The Link layer attempts to sync to a single device that is specified by the Host.
• The Link layer attempts to sync to any one of multiple devices specified by the Host (in the so-called Periodic Advertiser List).

If a received PDU includes a SyncInfo field from an unlisted advertiser or one not specified by the host or has an incorrect Advertising SID, the SyncInfo is ignored. Also, only one mode can be active at a time.

Timing of Periodic Advertising Events

Refer to Fig 7 above: each periodic advertising event starts with a single AUX_SYNC_IND PDU, followed by zero or more AUX_CHAIN_IND PDUs if the payload from the host needs fragmentation. These events occur at fixed intervals known as the periodic advertising interval.

Note that the interval between primary channel advertising events carrying the ADV_EXT_IND packets is separate from the periodic advertising interval.

For the primary channel advertising events, the min-max interval is 20 ms to 10485.759375 s, calculated as Time = N × 0.625 ms, with N ranging from 0x000020-0xFFFFFF.

And for periodic advertising events, the min-max interval is 7.5 ms to 81.91875 s, calculated as Time = N × 1.25 ms, with N ranging from 0x0006 to 0xFFFF.

Refer to Fig. 8. When the syncPacketOffset value of the SyncInfo data field is zero, the periodic advertising synchronization information is incomplete and the scanner should listen for a subsequent AUX_ADV_IND packet to be able to obtain the complete information.

Also, when the controller does not receive any AUX_SYNC_IND packets forming the periodic advertising train within six periodic advertising events, starting with the first periodic advertising event it listened for, synchronization is regarded as lost and the link layer state machine transitions from the synchronization state to the stand-by state.

LE Periodic Physical Channel

The LE Periodic Physical Channel is a sequence of pseudo-random RF frequencies optimized for periodic broadcasts of changing data between unconnected devices.

This channel has four main characteristics:

• Unique Identification: Every periodic advertisement packet on the channel includes a randomly generated 32-bit access address and an event counter which are both used to uniquely identify the periodic physical channel it’s using. This design avoids collisions in crowded environments by ensuring each packet can be accurately directed, even when multiple devices operating in close proximity share the same RF frequency.
• Channel Control: Only the advertising device controls the LE periodic physical channel; scanners can’t transmit on it. The advertiser sets the channel map, designating which of the 37 channels will be used for periodic broadcasts, the timing offset for the first periodic broadcast packet, and the periodic advertising interval.
• Structure of Periodic Advertising Events: The LE periodic physical channel is structured into periodic advertising events, with each event occurring on a different PHY hop channel. The first packet sent by the advertiser after the periodic broadcast is established sets the timing anchor for future events, and all events use the same PHY as the one the advertiser used for the AUX_ADV_IND packet. Also, additional packets can also be sent between these regular events.
• Topology: Topology-wise, 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 simultaneously.

Bluetooth LE categorizes the application data that is transmitted using this LE periodic physical channel as unreliable. This means even when the receiver has detected errors in the received packets, it can not request a retransmission. Also, there is no guarantee that all packets sent are received.

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

To ensure seamless, unidirectional connectionless communication through extended advertising and periodic advertising events, the GAP mandates clear role assignments: One device must act as the Broadcaster. This device sets its link layer to be an advertiser. It then broadcasts periodic advertising synchronization information and periodic adverts.

Concurrently, at least one other device takes on the Observer role. This device sets its link layer to operate as a scanner. It performs the periodic advertising synchronization procedure and listens for the periodic adverts sent by the 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 device in this mode automatically assumes the role of a GAP Broadcaster. It sends synchronization information for a periodic advertising train using non-connectable and non-scannable extended advertising events.
• Periodic Advertising Synchronization Establishment procedure: Observer devices, in response, carry out this procedure to scan for extended advertising events that carry synchronization information.

Second Mode-Procedure Pair: Data Transfer

• Periodic Advertising Mode: A device in this mode also acts as a GAP Broadcaster. It transmits advertising data at specific, predictable intervals and follows a frequency- hopping sequence defined in the synchronization information.
• Periodic Advertising Synchronization Establishment Procedure: Observer devices use this procedure to scan for periodic advertising events. They do so at predefined intervals and according to the frequency-hopping sequence outlined in the synchronization information.

How Periodic Advertising Relates to LE Audio

Once you understand the intricacies of periodic advertising—including its function and how various levels of the Bluetooth specification support it—you may wonder how this feature integrates with the LE Audio Broadcast application.

First, let’s clarify the needs of LE Audio Broadcast: it requires a connectionless method for transmitting a large amount of isochronous data.

Periodic advertising facilitates this by offering a synchronized, periodic transport between an LE Audio Broadcaster (also known as an isochronous broadcaster) and its synchronized Observers.

The isochronous broadcaster uses periodic advertising to share synchronization information and BASE information specific to its isochronous broadcast streams with its Observers. This specific synchronization data is termed as “BIGInfo,” and it is located in the ACAD field of the AUX_SYNC_IND packet.

We have covered the nuances of LE Audio Broadcasts in our Discovering Auracast – the Public Broadcast Profile whitepaper.

Conclusion

The Bluetooth Specification has evolved to include periodic advertising, a significant enhancement over legacy advertising, to meet the demands of broadcasting isochronous streams in emerging applications like LE Audio broadcasts. Key layers such as the PHY, LL, HCI, and GAP have been revised to support this new feature.

In unidirectional, connectionless communication via periodic advertising, the Broadcaster must first share synchronization information about its periodic advertising train. Observer devices can gather this synchronization information in two primary methods: one through scanning, as detailed in this article, and the other via the PAST feature, which will be the focus of our upcoming fundamentals series.

The Observer then uses the obtained synchronization information to find and synchronize to the periodic advertising trains.

References & Additional Resources

1. “Core Specification 5.0” Bluetooth.com,
   www.bluetooth.com/specifications/specs/core- specification-5-0/. Accessed 01 Sep. 2023
2. “Core Specification 5.4” Bluetooth.com,
   www.bluetooth.com/specifications/specs/core- specification-5-4/. Accessed 27 Oct. 2023.
3. “The Bluetooth® Low Energy Primer”, Bluetooth.com,
   https://www.bluetooth.com/bluetooth-resources/the-bluetooth-low-energy-primer/.
   Accessed 27 Oct. 2023
4. “Discovering Auracast™ – The Public Broadcast Profile”, Cloud2GND.com, Accessed