To enable Bluetooth LE Audio, Bluetooth Core Specification v5.2 introduced Isochronous Streams as the transport mechanism for Audio Streams. Isochronous Streams are categorized into two main types: the Unicast or Connected Isochronous Stream (CIS) and the Broadcast Isochronous Stream (BIS).
The focus here is on the latter, BIS. BIS allows Bluetooth LE Audio to cater to broadcast applications where an audio source can broadcast LE Audio to many devices without establishing connections. Examples of such applications include sharing music with friends, broadcasting Game Audio during group game play, and activating sound in previously muted public TVs.
To fully grasp how different LE Audio profiles broadcast audio data, one must know a fair amount about BIS. This article dives into the nuts and bolts of BIS, exploring its key concepts to better understand how it is being used to transform audio sharing and public listening experiences.
What is a Broadcast Isochronous Stream ?
A BIS is a logical transport used for broadcasting isochronous data, such as audio data, between unconnected LE devices. It is also used to carry control information for stream management. The key characteristics of BIS include:
- Connectionless Nature: BIS works without the need for link establishment procedures, allowing any in-range device to receive unencrypted data from an Isochronous Broadcaster. Devices with the encryption key can also receive encrypted data.
- Unidirectional Traffic: Data transmission is only from the Isochronous Broadcaster to the Synchronized Receiver(s). There is no bidirectional data transmission. The Isochronous Broadcaster acts as the sender, while the Synchronized Receiver is the recipient.
- Unreliable: BIS has no acknowledgement scheme to facilitate flow control or to guarantee that data has been received. This makes BIS inherently unreliable. However, to improve reliability, it uses retransmission and pre-transmission strategies.
- Flexible Data Rates: BIS can manage data packets of varying sizes. It can also send one or multiple packets per BIS event. This flexibility allows implementers to customize packet size, the number of packets sent during each transmission, and transmission interval timing. As a result, BIS supports a wide range of transmission speeds to meet different data rate requirements.
- Allows Isochronous Communication: BIS can transmit time-sensitive data at precise intervals, includes flushing mechanisms, and supports synchronized data reception across multiple receivers.
The BIS PDU and Structure
In a BIS, data is sent in the form of Link Layer (LL) Protocol Data Units (PDUs), called BIS Data PDUs. Each BIS PDU consists of a 16-bit header and a payload, which can be up to 251 octets in size. Additionally, there’s an optional MIC (Message Integrity Check) included only when the data is encrypted.
The BIS PDU header contains the following key fields:
- LLID (Link Layer ID): This field shows whether the payload data is fragmented or complete, framed or unframed, or if the PDU is a BIG (Broadcast Isochronous Group) Control PDU.
- CSSN (Control Subevent Sequence Number): This is used by Synchronized Receivers to identify if a BIG Control PDU is a repeat or a new transmission.
- CSTF (Control Subevent Transmission Flag): This indicates the presence of a control subevent, which provides control information to all Synchronized Receivers.
- Length: It specifies the size of the payload and includes the MIC, if present.
BIS Timing
Data transmission in a BIS logical transport is through a sequence of BIS events broadcasted at regular intervals. This constant time interval between the BIS event transmissions is called the ISO_Interval, and it ranges from 5 milliseconds to 4 seconds, in increments of 1.25 milliseconds. The start of each ISO_Interval in a BIS event is known as the BIS anchor point.
Each BIS event consists of one or more subevents. A subevent offers an opportunity slot for the Isochronous Broadcaster to transmit a single BIS Data PDU and for a Synchronized Receiver to receive it.
The time between the start of two consecutive subevents in a BIS event is called the Sub_Interval spacing, and it remains constant for the lifetime of the BIS. The total number of subevents in a BIS event is denoted by the Number of Subevents (NSE) parameter.
How the BIS Adds Robustness to Transmissions
Compared to wired transmissions, wireless transmissions are inherently less reliable. This is especially true in wireless broadcast topologies, where data is transmitted in one direction only, without any acknowledgment of receipt.
BIS, being a broadcast topology, compensates for the lack of an acknowledgment scheme by providing a retransmission strategy.
During each BIS event, the Isochronous Broadcaster may transmit the same BIS Data PDU multiple times across different subevents. This redundancy increases the likelihood that a Synchronized Receiver, missing a packet in one subevent, will successfully receive it in subsequent subevents. Also, in the case where pre-transmission is used, the receiver has additional chances to receive the packet in subevents earlier than its transmission time, as explained below.
Additionally, to increase the system’s resilience to channel interference, every subevent is transmitted over a different RF frequency selected using the Channel Selection Algorithm #2.
The arrangement of the retransmissions in a BIS event is influenced by two key controller parameters, the Burst Number (BN), and Number of Subevents (NSE) and, along with a derived metric known as the Group Count (GC):
- BN parameter: It specifies the number of original BIS Data PDUs that can be scheduled for transmission and retransmission. These Data PDUs are grouped and called a ‘burst’. The BN value can range from 0 to 7. A BN of 2, for example, means each burst has two unique BIS Data PDUs, and thus the BIS event uses two subevents for each transmission, and two subevents for each retransmission, if present.
- NSE parameter: It indicates the total number of subevents within a single BIS event. For example, an NSE value of 4 means there are four separate opportunities for transmitting a BIS Data PDU in that event.
- GC parameter: The GC parameter is used to organize the subevents in a BIS event into groups based on the BN value. It’s calculated as NSE divided by BN (NSE/BN), ensuring each group has enough subevents for a complete burst. The groups are numbered from 0 to GC-1 and transmitted sequentially. Also, the NSE/BN ratio must always result in a whole integer. For instance, 2/1, 6/2, 6/3 and 4/2 are valid, while 3/2, 5/2, and 7/5 are invalid.
A GC value greater than one means that the BIS event includes redundant transmissions. The first group, labeled g0, is responsible for transmitting the first instance of new BIS Data PDUs. The subsequent groups focus on either retransmitting the burst initially sent in g0 or pre-transmitting the burst that will be included in the first group of a future BIS event.
PreTransmissions: Retransmissions Across Multiple BIS Events
A pre-transmission involves sending data before its designated BIS event occurs. This process increases time diversity among the retransmissions and aids in combating interference, which could impact the entire frequency band used for a BIS event.
For instance, if interference disrupts the primary BIS event, there’s a chance that the pre-transmitted data (sent during earlier subevents) was transmitted successfully. This redundancy ensures that even if one transmission period is heavily affected by interference, earlier transmissions might still get through, thus maintaining the integrity and continuity of the data stream.
The pre-transmission process works by partitioning the groups of subevents in the current BIS event into ones that will carry retransmissions of data associated with the current BIS event and others that will carry retransmissions of data carried by subevent(s) in group g0 in future BIS events.
To decide which groups do what, the group count parameter is used along with two other parameters:
- Immediate Repetition Count (IRC): It denotes the number of groups which carry data associated with the current BIS event.
- Pretransmission Offset (PTO): The PTO offset is used to determine the offset of future event(s) whose data will be retransmitted in the current BIS event.
These three parameters are applied on the following rules:
- g < IRC : In the current BIS event, all the group numbers less than the IRC value are used to carry the current BIS event’s data.
- g ≥ IRC : The subevents whose group number is greater than the IRC are used to carry data for future BIS events. Specifically, the data is from future BIS events derived by PTO × (g − IRC + 1) BIS events after the current BIS event.
In Figure 5, each BIS event comprises six subevents (NSE=6). These subevents are divided into three groups (g0,g1,g2), with each group containing two subevents, to handle the burst of two payloads (BN=2). With the IRC parameter set at two (IRC=2), the first two groups (g0 and g1) transmit the payloads for the current BIS event, while the third group (g2) transmits payloads for a future event.
To trace the origin of payloads in group g2, the group number ‘2’ is used in the equation:
For example, if the current BIS event is labeled event x, then the payloads in its g2 group will be from event (x + 2).
The BIG Structure
A Broadcast Isochronous Group (BIG) is a collection of one or more BISes. There can be a maximum of 31 BISes in a single BIG. While each BIS within a BIG has its own isochronous flow of data, they all share a common timing reference at the application layer, known as the BIG Synchronization point.
BIG Synchronization Point
The BIG synchronization point is a reference timing point that allows multiple Synchronized Receivers, receiving data from the same Isochronous Broadcaster at different times to synchronize their reception of that data.
At the BIG synchronization point, all devices synchronized to the BIG are aware that every other device has had the chance to receive its relevant BIS(es) from the BIG.
Take, for example, stereo music delivered through a BIG event with two BISes, one for the left and one for the right audio channel. These BISes are sent sequentially, resulting in the Synchronized Receivers (e.g., left and right earbuds) receiving their Audio Streams at different times.
However, due to the common BIG Synchronization Point between the BISes within the same BIG event, audio reception between the left and right earbuds is synchronized. The BIG Synchronization point does this by ensuring that the earbud receiving its Stream first will wait for the second one to receive its Stream.
The BIG synchronization point is located at the end of the last BIS subevent in the last BIS event in a BIG. The beginning of the BIG event is called the BIG Anchor point. The time lapse between the BIG anchor point and the BIG synchronization point is specified using the delay parameter, BIG_Sync_Delay, as shown in the figure below.
Presentation Delay in Broadcast Audio Profile (BAP), ensures that devices simultaneously present audio to the users.
To ensure synchronized audio playback on multiple Synchronized Receivers, BIS ensures that broadcast streams arrive at each Synchronized Receiver’s Host at precisely the same time. For example, left and right audio is made available to the left and right earbuds’ Host for rendering at the same time.
Packing of BISes in a BIG
The Isochronous Broadcaster user/application/Host can suggest the preferred method for arranging multiple BISes in a BIG, which can be either sequential or interleaved. This suggestion is included as a Packing parameter in the HCI_LE_Create_BIG command.
It’s important to note that this suggestion is merely a recommendation, and the Controller has the discretion to ignore it. Furthermore, it becomes meaningless when there is only one BIS in the BIG.
The implemented Packing of the BISes affects the relationship between the BIS_Spacing and the Sub_Interval timing parameters. The BIS_Spacing parameter is the time interval between the start of two consecutive BIS events within a BIG, while the Sub_Interval parameter is the time interval between start of two consecutive subevents within a single BIS event.
Sequential Packing
When the Controller uses the sequential Packing, it results in the BIS_Spacing value being greater than the Sub_Interval value, (BIS_Spacing parameter > Sub_Interval parameter ), and the BISes within the BIG occur consecutively, one after the other.
Interleaved Packing
When the Controller uses the interleaved Packing, it results in the BIS_Spacing value being less than the Sub_Interval value, BIS_Spacing parameter > Sub_Interval parameter , (BIS_Spacing parameter < Sub_Interval parameter), and the BISes within the BIG overlap and interlace.
Control Subevent in a BIG
A BIS event only transports data, while a BIG event can transport both data and control information. Data transmission within a BIG event occurs through BIS event subevents, while control information, such as channel map updates and BIG termination details, is conveyed through the BIG Control PDU delivered by a control subevent.
To support the interoperability of how the control information is transmitted, the following Generic Access Profile (GAP) procedures can be implemented:
- GAP Broadcast_Isochronous_Channel_Map_Update procedure: This procedure allows the Broadcaster to transmit a new channel map using the BIG_Channel_Map_IND control PDU. When a Synchronized Receiver receives the channel map update message, it uses the new channel map when receiving data from the BIG at the specified instant.
- GAP Broadcast_Isochronous_Terminate procedure: This procedure allows the Broadcaster to terminate a BIG by sending the BIG_ Terminate_IND control PDU which lets the Synchronized Receiver(s) know the reason for the termination as well as when the BIG will be terminated.
Control Subevent Timing
Inside a BIG event, there can only be one control subevent, which is always scheduled after the last subevent of the last BIS. The time from the BIG anchor point to the start of the control subevent is called the BIG_Control_Offset, and it is calculated differently depending on whether the BISes are packed sequentially or in an interleaved manner.
- In a sequential packing: The BIG_Control_Offset = Num_BISBIS_Spacing
- In an interleaved packing: BIG_Control_Offset = NSESub_Interval
When the Isochronous Broadcaster needs to deliver control information, the control subevent is initially transmitted in six consecutive BIG events as shown in Figure 11 below. Afterward, it may be sent in any subsequent BIG event.
In a BIG event with a control subevent, all BIS Data PDUs have their control subevent transmission flag (CSTF) set to one, indicating the presence of control information for Synchronized Receivers.
Each BIG Control PDU is assigned a control subevent sequence number (CSSN) to help Synchronized Receivers distinguish between new and retransmitted control information.
The CSSN starts at one, wraps to zero when it reaches seven, and increments at the beginning of a BIG event containing the first transmission of a new BIG Control PDU. Importantly, it remains unchanged during retransmissions, and all BISes within a BIG share the same CSSN value.
Take note that the presence of a control subevent in a BIG does not change the NSE value and it also does not affect timing of the BIG synchronization point.
Encrypted BIG
A BIS transmission can be either encrypted or unencrypted, with the encryption’s security influenced by the type of pairing used. There are two types of pairing: Authenticated pairing, which includes Man-In-The-Middle (MITM) protection, and Unauthenticated pairing, which lacks MITM protection.
GAP defines security mode 3, which outlines the encryption requirements for BIS security across three distinct levels.
| Security Mode 3 Levels | Security Requirements |
| Level 1 | No security (no authentication and no encryption) |
| Level 2 | Use of an unauthenticated Broadcast_Code |
| Level 3 | Use of an authenticated Broadcast_Code |
In level 1, BIS payloads are transmitted without encryption and can be intercepted by any listening device.
In level 2, an Isochronous Broadcaster uses a 128-bit Broadcast_Code to derive the session key for encrypting BIS payloads. Listening devices may receive the Broadcast_Code to decrypt the data using an unauthenticated pairing method.
Level 3 offers the highest security, requiring that only those listening devices receiving the Broadcast_Code through an authenticated method can access the BIS payloads. If not authenticated, it will result in an error indication to the user, such as insufficient security for the Broadcast_Code.
For user-interface consistency and interoperability, GAP recommends referring to the Broadcast_Code as the ‘Bluetooth Privacy Code’ in user interfaces. It should consist of four to sixteen characters, with a 16-character code being recommended for maximum entropy.
The Bluetooth Privacy Code is then converted into a 128-bit value using UTF-encoding. These resulting bytes are organized into 8-bit fields, starting from the least significant bit. If necessary, padding with zeros is applied to the most significant bits.
For example, the Broadcast_Code as the Bluetooth Privacy Code string ‘GymTime$2day’ is represented as the 128-bit Broadcast_Code value 0x00000000_79616432_24656D69_546D7947.
Broadcast Features Across GAP, Link Layer and HCI
To broadcast data using BISes within a BIG, a device needs to first configure advertising PDUs containing BIG synchronization information and then the isochronous data. This synchronization information is needed for Scanners to achieve synchronization with a BIG that transports relevant broadcast streams.
GAP provides two modes to the GAP Broadcaster to define its behavior during discovery and in the Isochronous Broadcasting State. These modes are:
- GAP Broadcasting Isochronous Synchronizability mode: For transmitting BIG synchronization information in a periodic advertising train(PA). Each BIG is associated with a PA that contains BIGInfo [Volume 6, Part B, Section 4.46.11] in its ACAD field [Volume 6, Part B, Section 2.3.4.8]. BIGInfo points to the BIG and provides the necessary data that enables synchronization to it.
- GAP Isochronous Broadcasting mode: For transmitting the isochronous broadcast data.
To create a BIG, the Host of a device sets up and configures the BIG using the HCI_LE_Create_BIG command. The BIGInfo is added to the ACAD field in the PA, and the BIS are created. The Controller broadcasts a BIS Empty Data PDU, and then sends HCI_LE_Create_BIG_Complete event to the Host to indicate that the HCI_LE_Create_BIG command has successfully completed and its Link Layer has entered the Isochronous Broadcasting state.
A Controller broadcasting BIS data is in the Link Layer (LL) Isochronous Broadcasting state, and has the LL Isochronous Broadcaster role.
To create the PDUs transmitted in the BIS, the Host uses the HCI_LE_ISO_Data_Path command to set up the isochronous data path with codec processing in Controller or Host. To terminate broadcasting a BIG in the Controller, the Host uses the HCI_LE_Terminate_BIG command and the Isochronous Broadcaster broadcasts the BIG_ Terminate_IND control PDU.
Synchronizing with a BIG
The GAP provides the GAP Observer role and the GAP Broadcast Isochronous Synchronization Establishment procedure for the Synchronized Receiver to define its behavior in the Synchronization State. The GAP Broadcast Isochronous Synchronization Establishment procedure defines the way for a device to synchronize to a BIG.
To receive broadcast streams, the Host of a device uses the HCI_LE_BIG_Create_Sync command to synchronize to a BIG in the Controller. The Controller of a device enters the Link Layer Synchronization state.
The Synchronization state has two substates. The Controller enters the Synchronizing sub-state to receive synchronization information from the PA associated with the BIG. After it has used this BIG synchronization information to successfully receive a BIS PDU from the BIG, it enters the Synchronized sub-state and becomes a Synchronized Receiver.
The Host of the Synchronized Receiver uses the HCI_LE_ISO_Data_Path to do codec processing in the Controller or Host on the received broadcast streams. To stop synchronization to a BIG, the Host uses the HCI_LE_BIG_Terminate_Sync command.
Concluding Remarks
AuracastTM and other LE Audio broadcast applications rely on BIS. This article provides detailed information on BIS. To fully understand BIS, it is recommended to also read about the Connected Isochronous Stream (CIS), as comparing BIS with CIS can be informative. More information on CIS is available in the ‘Connected Isochronous Stream’ article from the Fundamental Series.
References
- “Core Specification 5.4” Bluetooth.com,
www.bluetooth.com/specifications/specs/core-specification-5-4/. Accessed 16 Jan 2024. - “Discovering AuracastTM – The Public Broadcast Profile”, Cloud2GND.com,
https://cloud2gnd.com/discovering-auracast-the-public-broadcast-profile/. Accessed 16
Jan 2024. - “Public Broadcast Profile 1.0” Bluetooth.com,
https://www.bluetooth.com/specifications/specs/public-broadcast-profile-1-0/. Accessed
16 Jan 2024. - “Basic Audio Profile 1.0” Bluetooth.com,
https://www.bluetooth.com/specifications/specs/basic-audio-profile-1-0/. Accessed 16
Jan 2024.
