Bluetooth LE Audio

The Bluetooth^® Core Specification 5.2 [2] defined by the Bluetooth Special Interest Group (SIG) introduced the next generation of Bluetooth audio called the low energy (LE) audio. LE audio operates on the Bluetooth LE standard. For more information about the Bluetooth LE stack, see Bluetooth Protocol Stack.

What Is LE Audio?

This figure shows the taxonomy of Bluetooth audio.

Bluetooth audio can be classified as – classic audio (operates on the basic rate/enhanced data rate (BR/EDR) physical layer (PHY)) and LE audio (operates on the Bluetooth LE PHY). LE audio is the next generation of Bluetooth audio, which supports development of the same audio products and use cases as the classic audio. It also enables creation of new products and use cases and presents additional features and capabilities to help improve the performance of classic audio products. Some of the key features and use cases of LE audio include enabling audio sharing, providing multistream audio, and supporting hearing aids. For more information about LE audio features and use cases, see Features of LE Audio and Use Cases of LE Audio, respectively.

Features of LE Audio

This figure illustrates the salient features of LE audio.

Low Complexity Communication Codec (LC3)

LE audio includes a new high quality, low power codec, known as LC3. It supports a wide range of sample rates, bit rates, and frame rates giving the product developers maximum flexibility to optimize their products to deliver the best possible audio experience to end users. As compared to the subband codec (SBC) implemented by classic audio, LC3 is much more efficient in processing and delivering audio. A comparison between LC3 and SBC related to the standard stereo listening test [1] verifies that LC3 delivers high quality audio at low data rates. The results shown in [1] show that even at half of the bit rate, LC3 provides far superior audio experience than SBC.

The intrinsic shortcomings of SBC resulted in the manufacturers of audio equipment such as Bluetooth headphones turning to proprietary solutions such as audio codec 3 (AC3) and AptX. Such proprietary solutions need specific hardware support and add costs over standards-based implementations. The introduction of LC3 removes the dependency on the proprietary solutions, resulting in lower device costs. LC3 enables the product developers to have an efficient tradeoff between sound quality and power consumption. The high quality, low power characteristic of LC3 enables the product developers to optimize the longevity of the device battery.

Multistream Audio

Multistream audio enables you to transmit multiple, independent, and synchronized audio streams between an audio source device, such as a smartphone, and one or more audio sink devices like earbuds or earphones. To support multistream audio, the Bluetooth Core Specification 5.2 [2] introduced the connected isochronous stream (CIS) and connected isochronous group (CIG). For more information about the CIS and CIG, see CIS and CIG. This figure shows how LE audio enables you to send multiple audio streams between a source and sink.

Classic Bluetooth audio supports only a single point-to-point audio stream over the advanced audio distribution profile (A2DP). However, LE audio enables you to handle multiple isochronous audio streams with synchronization between them. The multistream support of LE audio can improve the performance of truly wireless earphones by providing a better stereo imaging experience, making the use of voice assistant services more seamless, and making switching between multiple audio source devices smoother [1].

Hearing Aids Support

LE audio provides exclusive support for hearing aids. Typically, hearing aid devices require low and efficient power consumption. LE audio supports high quality, low power capability of LC3 and the efficient power consumption characteristic of the Bluetooth LE standard. LE audio-supported hearing aids are interoperable, enabling you to connect to most smartphones, TVs, and laptops and making these devices much more accessible to people with hearing loss.

Broadcast Audio Sharing

LE audio now supports the ability to broadcast one or more audio streams to an unlimited number of audio sink devices. Broadcast audio opens significant new opportunities for innovation, such as a new Bluetooth use case, audio sharing. Broadcast audio sharing can be personal (share audio with people around you) or location-based (share audio in public places like airports).

Support For LE Audio In Bluetooth Core Specification

The Bluetooth Core Specification 5.2 [2] introduced these updates pertaining to LE audio.

Changes to Link Layer (LL) State Machine

The functioning of the LL is described in terms of a state machine. This figure shows the state diagram of the LL state machine.

The Bluetooth Core Specification 5.2 [2] added a new state, Isochronous Broadcasting, to the LL state machine. In the Isochronous Broadcasting state, the LL transmits the isochronous data packets on an isochronous physical channel. The Isochronous Broadcasting state can be entered from the Standby state. If a device is in the Isochronous Broadcasting state, then it is referred to as an isochronous broadcaster.

Note

For more information about different states of the LL state machine, see Volume 6, Part B, Section 1.1 of the Bluetooth Core Specification 5.2 [2].

LE Isochronous Channels and the Bluetooth Data Transport Architecture

The LE isochronous channels feature enables you to transfer latency-sensitive data between the devices. This feature provides a mechanism to ensure synchronization between multiple sink devices receiving data from the same source. The expired data (data that violates the time-bound validity period) that is not transmitted, is discarded. Consequently, the receiving devices receive data that is valid with respect to its age and acceptable latency.

The Bluetooth data transport architecture now supports LE isochronous channels. The LE isochronous channels can be connection-oriented or connectionless. In both cases, the isochronous communication is realized using the new LE isochronous physical channel. This physical channel uses frequency hopping and specifies the timing of the first packet. This timing acts as a reference point for the timing of the subsequent packets. The LE isochronous physical channel can operate on an LE Uncoded (LE1M and LE2M) or LE Coded Bluetooth LE PHY. The LE isochronous physical channel uses LE-Stream (LE-S) and LE-Frame (LE-F) logical links to transmit audio data and framed data packets, respectively. The connection-oriented isochronous channels use LE-CIS logical transport and support bidirectional communication. This figure shows the procedure of connection-oriented isochronous channel data transport.

A single LE-CIS stream provides point-to-point isochronous communication between two connected devices. A flushing period is specified for the LE-CIS logical transport. Any packet that has not been transmitted within the flushing period is discarded. This figure shows the procedure of connectionless isochronous channel data transport.

Connectionless isochronous communication uses broadcast isochronous streams (BIS) and supports only unidirectional communication. The BIS uses LE-S or LE-F logical links over the LE isochronous physical channel for user data, with the new LE-broadcast control (LEB-C) logical link used for control requirements. A single BIS can stream identical copies of data to multiple receiver devices.

CIS and CIG

A CIS is a logical transport that enables connected devices to transfer isochronous data unidirectionally and bidirectionally. The isochronous data can be transferred either in an LE-S or LE-F logical link by using the CIS logical transport. Each CIS is associated with an LE asynchronous connection (ACL). A CIS supports variable-size packets and the transmission of one or more packets in each isochronous event. This capability enables LE audio to support a range of data rates. A CIG consists of two or more CISs that have the same ISO interval (time between the anchor points of adjacent CISs) and that are expected to have a time relationship at the application layer, or of a single CIS. This figure shows the CIS and CIG servicing left and right stereo ear buds.

The maximum number of CISs in a CIG is 31. A CIG comes into existence when its first CIS is created, and it ceases to exist when all of its constituent CISs are destroyed.

This figure illustrates the concept of CIS events and subevents.

Each CIS event occurs at a regular ISO Interval, which is in the range from 5 ms to 4 s in multiples of 1.25 ms. Each CIS event is partitioned into one or more subevents. In a CIS, during a subevent, the Central transmits once and the Peripheral responds as shown in the preceding figure. A CIS event is an opportunity for the Central and Peripheral to exchange CIS protocol data units (PDUs). A subevent ends at the end of the Peripheral's packet, if any, and at the end of the Central's packet. The isochronous channel is changed at the end of each subevent. The LL closes a CIS event at the end of its last subevent.

All CISes in a CIG has the same Central but may have different Peripheral's. A CIG event consists of the corresponding CIS events of the CISes currently making up that CIG. Each CIG event starts at the anchor point of the earliest (in transmission order) CIS of the CIG and ends at the end of the last subevent of the latest CIS of the same CIG event. Any two CIG events on the same CIG do not overlap because the last CIS event of a given CIG event ends before the first CIS anchor point of the next CIG event.

Consider a use case where an audio stream from a smartphone (the source) is to be played in the left and right buds (the two sinks) of LE earphones. The left and right buds each establish a CIS stream with the source device. Both the CIS streams are part of the same CIG. A fragment of audio produced by the source is encoded into a packet and a copy is transmitted to each sink device over its stream, one at a time during a series of consecutive CIS events. The audio playback must not start until all devices in the CIG have received the packet.

Note

• For more information about CIS, see Volume 6, Part B, Section 4.5.13 of the Bluetooth Core Specification 5.2 [2].

• For more information about CIG, see Volume 6, Part B, Section 4.5.14 of the Bluetooth Core Specification 5.2 [2].

BIS and Broadcast Isochronous Group (BIG)

A BIS is a logical transport that enables a device to transfer isochronous data (framed or unframed). A BIS supports variable-size packets and the transmission of one or more packets in each isochronous event, enabling LE audio to support a range of data rates. The data traffic is unidirectional from the broadcasting device. Therefore, no acknowledgment protocol exists, making broadcast isochronous traffic unreliable. To improve the reliability of packet delivery, the BIS supports multiple retransmissions.

A BIG contains two or more BISs that have the same ISO interval and that are expected to have a time relationship at the application layer, or of a single BIS. The maximum number of BISs in a BIG is 31. This figure shows the BIS and BIG servicing a pair of left and right stereo ear buds.

For each BIS within a BIG, a schedule of transmission time slots (known as events and subevents) exist. This figure shows the concept of BIS and BIG events and subevents.

Each BIS event starts at the BIS anchor point and ends after its last subevent. Each BIG event starts at the BIG anchor point and ends after the control subevent, if one exists. If a control subevent does not exist, the BIG event ends at the end of the last BIS event. A BIS subevent enables an isochronous broadcaster to transmit a BIS PDU and enables a synchronized receiver to receive it. The LL must transmit one BIS data PDU at the start of each subevent of the isochronous broadcasting event. For each BIS event, the source of the data must send a burst of data consisting of burst number (BN) payloads. The subevents of each BIS event are each partitioned into groups of BN subevents. Each BIG event contains an optional control subevent. If a control subevent is present, the LL transmits a single BIG control PDU at the start of the control subevent to send control information about the BIG. The LL does not transmit a BIG Control PDU at any other time.

Note

For more information about BIG and BIS, see Volume 6, Part B, Section 4.4.6 of the Bluetooth Core Specification 5.2 [2].

Isochronous Physical Channel Protocol Data Unit (PDU)

The isochronous physical channel PDU contains a 16-bit header, a variable size payload, and an optional message integrity check (MIC) field. This figure shows the packet structure of isochronous physical channel PDU.

The format of the Header and Payload fields depend on the type of isochronous physical channel PDU that is being used. The isochronous physical channel PDU is a CIS PDU or a BIS PDU when used on a CIS or BIS, respectively. The MIC field is included in all PDUs that contain a nonzero Payload transmitted on an encrypted CIS or BIS. If a PDU is sent on an nonencrypted CIS or BIS or has a zero-length Payload, then the MIC field is not present.

This figure shows the packet structure of an isochronous physical channel PDU Header for a CIS PDU.

A CIS PDU can be a CIS data PDU or a CIS null PDU. A CIS Data PDU carries isochronous data, whereas a CIS null PDU is used when no data exists to be sent. This table explains the contents of the Header field.

Header Field Name	Description
LL identifier (LLID)	The LLID field indicates the type of content of the Payload field of the CIS Data PDU. These are the valid values of this field. 0b00 – Unframed CIS data PDU (end fragment of an service data unit (SDU) or a complete SDU) 0b01 – Unframed CIS data PDU (start or continuation fragment of an SDU) 0b10 – Framed CIS data PDU (one or more segments of an SDU) 0b11 – Reserved for future use For a CIS null PDU, the LLID is reserved for future use (RFU).
Next expected sequence number (NESN)	The LL uses this field to either acknowledge the last PDU sent by the peer device, or to request the peer device to resend the last PDU sent.
Sequence number (SN)	This field sets the identification number for LL packets. For a CIS null PDU, the SN is RFU.
Close isochronous event (CIE)	The device uses this field to close a CIS event early.
Null PDU indicator (NPI)	This field indicates whether the CIS PDU is a CIS data PDU or a CIS null PDU. If the CIS PDU is a CIS null PDU, then LL sets this field.
Length	This field indicates the size (in octets) of the Payload and MIC, if included.

This figure shows the packet structure of an isochronous physical channel PDU Header for a BIS PDU.

A BIS PDU can be a BIS data PDU or a BIG control PDU. A BIS data PDU carries isochronous data. A BIG control PDU sends control information for a BIG. This table explains the contents of the Header field.

Header Field Name	Description
LLID	The LLID field indicates the type of content of the Payload field of the BIS data PDU. These are the valid values of this field. 0b00 – Unframed BIS data PDU (end fragment of an SDU or a complete SDU) 0b01 – Unframed BIS data PDU (start or continuation fragment of an SDU) 0b10 – Framed BIS data PDU (one or more segments of an SDU) 0b11 – BIG control PDU
Control subevent sequence number (CSSN)	The LL uses this field to indicate the start of a BIG event that contains the first transmission of a new BIG control PDU.
Control subevent transmission flag (CSTF)	The LL uses this field to indicate whether it has scheduled a BIG control PDU to be transmitted in a BIG event.
Length	This field indicates the size (in octets) of the Payload and MIC, if included.

This figure shows the packet structure of the Payload field in a BIG control PDU.

The Opcode field specifies different types of BIG control PDUs. The Opcode field specifies the CtrData field in the Payload of BIG control PDU. For a given Opcode, the length of the CtrData field is fixed.

Note

• For more information about CIS PDU, see Volume 6, Part B, Section 2.6.1 of the Bluetooth Core Specification 5.2 [2].

• For more information about BIS PDU, see Section 2.6.2 of the Bluetooth Core Specification 5.2 [2].

• For more information about BIG control PDU, see Volume 6, Part B, Section 2.6.3 of the Bluetooth Core Specification 5.2 [2].

Isochronous Adaptation Layer (ISOAL)

To support LE audio, the Bluetooth Core Specification 5.2 [2] introduced the ISOAL in the Bluetooth stack that is present in the controller above the LL. The ISOAL enables the lower and upper layers of the stack to work together. This flexibility enables the size of isochronous data packets created and used by the upper layers to be distinct from the size used by the CIS or BIS logical transport in the LL. The ISOAL provides segmentation, fragmentation, reassembly, and recombination services for the conversion of the SDUs from the upper layer to the PDUs of the baseband resource manager and vice versa. The ISOAL enables the upper layer to use timing intervals that differ from those used by the LL so that the rate of SDUs exchanged with the upper layers is not the same as the rate with which they are exchanged with the LL. The isochronous communication mechanism uses the host controller interface (HCI) as the interface from the upper layer to the ISOAL. The SDUs are transferred to and from the upper layer by either using HCI ISO data packets or over an implementation-specific transport.

Note

For more information about ISOAL, see Volume 6, Part G of the Bluetooth Core Specification 5.2 [2].

Use Cases of LE Audio

This table shows some prominent use cases of LE audio.

Use Case	Description
Personal audio sharing	With personal audio sharing, people can share their Bluetooth audio experience with others around them. For example, group of friends can simultaneously enjoy music playing on one smartphone through their LE supported headphones. This is an example of a private group of audio sink devices sharing a single audio source.
Public assisted hearing	The dialogue of a theater play can be broadcast such that all LE hearing aid users in the audience can hear the dialogue.
Public television	At the gymnasium, all attendees with LE headphones or ear buds can listen to the television audio stream.
Multi-language flight announcements	Passengers at the airport or in an aircraft can connect their LE headphones to the flight information system, specify their preferred language, and listen to the flight information in that language.

References

[1] Bluetooth Technology Website. “Bluetooth Technology Website | The Official Website of Bluetooth Technology.” Accessed December 14, 2021. https://www.bluetooth.com/.

[2] Bluetooth Special Interest Group (SIG). "Bluetooth Core Specification." Version 5.2. https://www.bluetooth.com/.

[3] Bluetooth Special Interest Group (SIG). "Bluetooth Core Specification Version 5.2 Feature Overview. https://www.bluetooth.com/.

[4] Bluetooth Special Interest Group (SIG). "Bluetooth Core Specification." Version 5.3. https://www.bluetooth.com/.