Periodic Advertising Sync Transfer (PAST) is a Link Layer procedure [Vol 6, Part B, Section 5.1.13] that enables a device to share synchronization information about a periodic advertising train (PADV) with its connected peer.
This article explains how PAST works and highlights its benefits for power-constrained and limited user-interface LE Audio Broadcast devices.
How PAST Works
The LE Periodic Advertising feature allows a device to share its advertising data at regular, predictable intervals. It also provides control information that a listening scanner device can use to align its scanning schedule with the advertiser’s.
This control information is called periodic advertising synchronization information. It details the interval timings and the frequency hopping sequence used by the periodic advertiser. To obtain this information, the listening device performs the periodic advertising synchronization establishment procedure.
There are two ways to implement the periodic advertising synchronization establishment procedure. The first method involves the scanner device performing the scanning procedure, where it listens for non-connectable and non-scannable advertising packets containing the periodic advertising synchronization information.
The second method uses the PAST procedure. PAST was introduced in January 2021 as part of the Core Specification update v5.1. It allows a device to share synchronization details needed to receive periodic advertisements with another device through an ACL connection. This means a scanner can delegate the task of scanning for the periodic advertising synchronization information to another device. That device then relays this information back using PAST.
When the PAST procedure is initiated, a PAST sender, also known as the Initiating device, shares the periodic advertising synchronization information with a connected peer using a data packet called the LL_PERIODIC_SYNC_IND PDU. The procedure is complete when this packet has been sent or received.
LL_PERIODIC_SYNC_IND PDU
The LL_PERIODIC_SYNC_IND PDU is a Link Layer Control PDU. It is used by a device to inform its connected peer about the synchronization details needed to synchronize with a specific PADV.
PAST Topologies
In the PAST procedure, three devices are generally involved [Vol 6, Part B, Section 5.1.13.1]:
- Periodic Advertiser: This device advertises the PADV and its associated synchronization information.
- Initiating Device: This device relays the periodic advertising synchronization information to a connected peer device.
- Receiving Device: This device receives the synchronization information from a connected peer device.
PAST can be implemented in two topologies:
1. Transfer by Scanner: In this topology, the periodic advertiser, initiating device, and receiving device are three different devices. The initiating device scans for PADV from the periodic advertiser. It also has an ACL connection with the receiving device and sends it the synchronization information needed to synchronize with the periodic advertiser.
2. Transfer by Advertiser: In this topology, the periodic advertiser and the initiating device are the same device. The periodic advertiser transfers the periodic advertising synchronization information about its periodic advertising set to the receiving device.
Generic Access Profile (GAP) Modes and Procedures for PAST
The GAP layer defines the modes and access procedures that devices use when working with PAST.
Transfer by Scanner
When implementing PAST with three devices, Device A is the periodic advertiser, Device B is the initiating device, and Device C is the receiving device. Here’s how the GAP modes and procedures work:
- Device A (Periodic Advertiser): It acts as the GAP Broadcaster. It sends out periodic advertising synchronization information through the GAP periodic advertising synchronizability mode and broadcasts periodic advertisements (PADV) using the GAP periodic advertising mode.
- Device B (Initiating Device): It scans for periodic advertising synchronization details as the GAP Observer. And then uses the GAP Central/Peripheral role to transfer this information to Device C using the GAP periodic advertising synchronization transfer procedure.
- Device C (Receiving Device): It receives the periodic advertising synchronization information as the GAP Central/Peripheral. It also acts as a GAP Observer, using the information to sync with Device A and receive its periodic advertisements.
Transfer by Advertiser
When implementing PAST with two devices, Device A acts as both the periodic advertiser and the initiating device, while Device C is the receiving device.
Device A sends periodic advertisements and maintains an ACL connection with the scanner device. Through this connection, Device A provides the necessary synchronization information to the scanner. In this case, the GAP modes and procedures are as follows:
- Device A (Periodic Advertiser & Initiating Device): As the GAP Broadcaster, it sends out periodic advertisements. It also acts as the GAP Central/Peripheral, using the Periodic Advertising Synchronization Establishment procedure to send synchronization information to the connected scanner.
- Device C (Receiving Device): Acts as the GAP Central/Peripheral, it receives periodic advertising synchronization details through the GAP periodic advertising synchronization establishment procedure. It also functions as the GAP Observer, using the received synchronization information to synchronize with the periodic advertiser and receive its periodic advertisements.
Host Controller Interface (HCI) Commands for PAST
In both topologies, on the receiving device, the Host issues the ‘HCI_LE_Set_Periodic_Advertising_Sync_Transfer_Parameters’ command. This command tells the Controller what it should do when it receives the periodic advertising synchronization information ( LL_PERIODIC_SYNC_IND PDU).
Transfer by Scanner
In this PAST topology, three different devices are involved: Device A, Device B, and Device C. Device A is the periodic advertiser, Device B is the initiating device, and Device C is the receiving device.
Device A sends out periodic advertisements. Device B and Device C are connected. Device C wants to receive PADV from Device A, and so solicits Device B to handle scanning for the needed periodic synchronization information.
Device B scans for Device A’s PADV. Then, Device B’s Host uses the HCI_LE_Periodic_Advertising_Sync_Transfer command to tell its Controller to transfer the PADV’s periodic advertising synchronization information to Device C’s Controller using the PAST procedure.
The HCI commands and Link Layer messages between these three devices is shown in Figure 7 below:
Transfer by Advertiser
In this topology, two devices are involved: Device A and Device B. Device A acts as both the periodic advertiser and the initiating device.
The Host of Device A sends the HCI_LE_Periodic_Advertising_Set_Info_Transfer_Parameters command. This command instructs Device A’s Controller to transfer the synchronization information about a periodic advertisement (PADV) in one of its advertising sets to Device B, the receiving device.
The HCI commands and Link Layer messages between the two devices is shown in Figure 8 below:
PAST and LE Audio
LE Audio uses the Basic Audio Profile (BAP) to define roles and procedures for Bluetooth LE devices involved in sending and receiving audio.
For broadcasting Audio Streams, BAP specifies four device roles: Broadcast Source, Broadcast Sink, Scan Delegator, and Broadcast Assistant.
A Broadcast Source device transmits broadcast Audio Streams to unconnected devices using one or more Broadcast Isochronous Streams (BISes) within a Broadcast Isochronous Group (BIG). A BIG is a group of a maximum of 31 time-related BISes.
Additionally, a Broadcast Source also transmits extended advertising (EA) and periodic advertising (PADV) PDUs. EA PDU points to the PADV. The PADV PDU transmits the configuration parameters (BASE data) and synchronization information (BIGInfo data) for the broadcast Audio Streams.
A Broadcast Sink device discovers and receives broadcast Audio Streams. It scans for EA that point to PADV that points to a BIG that contains one or more BISes used to transport the broadcast Audio Streams. However, scanning for EA PDUs can drain the power of small-battery devices quickly.
Remote Broadcast Scanning and Scan Offloading
A Scan Delegator delegates the task of scanning for SyncInfo from EA PDUs to another device, known as the Broadcast Assistant. This process is known as Remote Broadcast Scanning. It helps the Scan Delegator save power by reducing its scanning activities.
A Broadcast Assistant establishes a connection with the Scan Delegator. It then sends SyncInfo to the Scan Delegator through the LL_PERIODIC_SYNC_IND PDU, using the PAST procedure. This action is referred to as Scan Offloading or ScanInfo Transfer.
Scan Delegators can use the SyncInfo data to synchronize to a PADV. This helps it find BASE configurations that describe the broadcast audio stream or BIGInfo data.
PAST allows an LE Audio Broadcast Sink to offload the scanning for SyncInfo needed to receive PADV to another more resourceful device. This is useful for Broadcast Sink devices with limited power. These devices save energy by relying on connected peers that do not have the same power limitations to find the PADV leading to the relevant BIS channel.
Additionally, PAST also reduces redundancy. A Central device can scan and distribute synchronization details to connected Peripheral devices, instead of multiple Peripherals scanning independently for the same synchronization information.
Broadcast Audio Scan Service Characteristics
The Broadcast Assistant and the Scan Delegator use the Broadcast Audio Scan Service (BASS) to communicate about broadcast Audio Streams. The Scan Delegator acts as the BASS server, while the Broadcast Assistant is the BASS client.
The Scan Delegator solicits one or more Broadcast Assistants to scan on its behalf by advertising connectable EA PDUs with the BASS UUID. The Broadcast Assistant(s) in proximity scan for these solicitations from the Scan Delegator and reply by initiating a connection with the Scan Delegator.
BASS has two characteristics: Broadcast Audio Scan Control Point characteristic and the Broadcast Receive State characteristic.
The Broadcast Assistant updates the Scan Delegator on its Remote Broadcast Scanning status by writing values to the Broadcast Audio Scan Control Point characteristic. An opcode value of 0x01 signifies that Remote Broadcast Scanning has started, while 0x00 indicates that it has stopped and so the Broadcast Assistant is no longer scanning on behalf of the Scan Delegator.
The Scan Delegator may change its scanning behavior based on the Remote Broadcast Scanning status of the Broadcast Assistant. It can either stop scanning if the Broadcast Assistant is scanning on its behalf or start scanning when the Broadcast Assistant stops. The specific behavior is determined by the implementation.
The Broadcast Assistant uses the Broadcast Receive State characteristic, either by reading it or receiving a notification, to check if the Scan Delegator requests SyncInfo data. It looks for a value of 0x01 (SyncInfo Request) in the PA_Sync_State field of this characteristic. The Broadcast Assistant should not transfer SyncInfo data to the Scan Delegator until it detects this 0x01 value in the PA_Sync_State field.
Once the Broadcast Assistant confirms that the Scan Delegator is requesting SyncInfo data, it will transfer the data using the PAST procedure. This procedure is completed when the Broadcast Assistant sends an LL_PERIODIC_SYNC_IND PDU to the Scan Delegator.
LL_PERIODIC_SYNC_IND PDU: AdvA and ID fields
When initiating PAST, the default behavior of the Broadcast Assistant is to match the LL_PERIODIC_SYNC_IND PDU AdvA parameter and the AdvA field of the ADV_EXT_IND PDUs from the Broadcast Source identified by the Broadcast Receive State characteristic requesting for the SyncInfo.
The Broadcast Assistant should only use a different AdvA parameter if:
- It is aware that the Broadcast Source has updated the AdvA parameter for that advertising set.
- The new AdvA value is derived from the same Identity Resolving Key (IRK) used to generate both the Resolvable Private Address for the original AdvA parameter and the Source_Address field in the Broadcast Receive State characteristic.
The Broadcast Assistant writes the ID field in the LL_PERIODIC_SYNC_IND PDU using the table below:
Concluding Remarks
This article explains what PAST is and how the Core Specification enables it at the Link Layer, GAP, and HCI layers. PAST is useful when a Broadcast Sink, limited by battery life, cannot continuously search for SyncInfo that leads to a PADV and then to a BIS.
In such cases, the Broadcast Sink may use a collocated Scan Delegator to assign the task of scanning for SyncInfo to another device, the Broadcast Assistant. The SyncInfo data is then received from the Broadcast Assistant using the PAST procedure.
References & Additional Resources
- “Core Specification 5.4” Bluetooth.com,
www.bluetooth.com/specifications/specs/core-specification-5-4/. Accessed 10 July 2024. - “Basic Audio Profile 1.0” Bluetooth.com,
https://www.bluetooth.com/specifications/specs/basic-audio-profile-1-0/. Accessed 16 July 2024. - “Broadcast Audio Scan Service 1.0” Bluetooth.com,
https://www.bluetooth.com/specifications/specs/bass-1-0/. Accessed 16 July 2024. - “Fundamentals of LE Audio: Extended Advertising”, Cloud2GND.com,
https://cloud2gnd.com/foundations-of-le-audio-extended-advertising/. Accessed 16 July 2024. - “Fundamentals of LE Audio: Periodic Advertising”, Cloud2GND.com,
https://cloud2gnd.com/discovering-auracast-the-public-broadcast-profile/. Accessed 16 July 2024. - “Fundamentals of LE Audio: Broadcast Isochronous Streams”, Cloud2GND.com,
https://cloud2gnd.com/fundamentals-of-le-audio-broadcast-isochronous-streams/. Accessed 16 July 2024.
