Introduction to Bluetooth LE Audio

Coming soon

1. Introduction

Bluetooth® Low Energy Audio is the new feature enabling the Audio Streaming over Bluetooth® Low Energy.

Almost every Bluetooth® devices are now using the BLE. Except for the audio streaming devices that require a Dual Mode controller for streaming audio over Classic Bluetooth®. The Bluetooth® Special Interest Group (Bluetooth® SIG) thought of a solution to enable and enhance the streaming audio over BLE.

Classic Bluetooth® (BR/EDR) Audio is already the most used audio wireless system in the world today. Bluetooth® LE Audio is coming as the next generation of it. Comparing to Classic Bluetooth®, BLE reduce the power consumption and allow a whole new world of possibilities to the audio stream.

One of them is the Auracast™ Broadcast Audio. Auracast™ is the new Bluetooth® standard. It enables listeners to share audio to multiple users. It's defined over these 3 fundamentals :

• Share your audio : Auracast™ broadcast will let you invite others to share in your audio experience bringing us closer together
• Unmute the world : Auracast™ broadcast audio will enable you to fully enjoy televisions in public spaces unmuting what was once silent and creating a more complete watching experience
• Hear your best: Auracast™ broadcast will allow you to hear best in the places you go.

More information here about BLE Audio and Auracast™:

2. LC3 Codec

Bluetooth® LE Audio is based on a new audio codec : LC3 for 'Low Complexity Communication Codec'. Its designed by Fraunhofer. This codec is mandatory and free to use in BLE Audio products, meaning BLE Audio will be fully interoperable, not depending of vendor specific codecs. LC3 brings a new quality, higher than the mandatory codec used on Classic Bluetooth® Audio. The codec has been mostly designed for embedded products with its low complexity and its low memory footprint.

The LC3 :

• is channel independent : can be configured/used for mono or stereo streams
• is suitable for both music and voice (from narrow band : 8kHz to full band : 48kHz)
• interworks perfectly with mobile codec (permits to have few audio loss).
• permits a low latency (which is defined in the Audio Profiles)

Comparing LC3 to the mandatory codec of Classic Bluetooth® Audio :

• is ----- SBC
• is ----- OPUS

If you need more information some studies done by the Bluetooth® SIG are here :

You can find more information about the LC3 and its integration in our solution inside LC3 Codec .

3. Link Layer and Isochronous Channels

Bluetooth® LE Audio is also based on a Bluetooth® 5.2 optional feature : Isochronous Channels. This is a link layer feature. This feature enables the transmission of a stream over a new connection : the Isochronous Stream.

There are 2 types of isochronous streams :

• Connected Isochronous Stream (CIS) : enabling the user to have an audio stream over a Bluetooth® connection. This is the classic way of doing BLE Audio (1 connection for 1 device, like a headset). With 2 CIS, we can stream synchronized audio streams to 2 different devices (for earbuds or hearing aids)
• Broadcast Isochronous Stream (BIS) : enabling a user to broadcast 1 or 2 audio streams to any receiver able to receive it . It does not need a connection meaning there could be an infinite number of receivers.

This 2 types of isochronous streams add new features to BLE :

• It's defining the latency for the system for the whole streaming time (without any drift). This latency is lower than classic Bluetooth® audio).
• It's also defining the retransmissions at the same time. We can ask for a system based on the lowest latency possible (some packets can be missed because there are really a few retransmissions), or on the better quality possible (all packets should be received but the latency is higher to enable this possibility).

If we compare an Isochronous Stream to a ACL Data transfer or Classic Bluetooth® Audio we can list some important differences :

Classic Bluetooth® Audio	ACL Data Transfer	Bluetooth® LE Audio
	Data is sent over ACL Data transfer	Data is sent over Isochronous data stream
	Data is continuous	Data is synchronized on a timestamp
	All packets are transmitted, leading to an infinity of retransmissions if the link has bad quality	Data has a validity in time, becoming obsolete after a certain time
	Data is irrelevant with missing packets	Each packet has a certain amount of audio
	Latency is not defined and can have some lags or drifts.	Latency is always defined in the system and can't change during the stream.

It enables the sender to "stream" audio as a radio. If the receiver missed a few packets, it will have some glitches (corrected by the LC3 Packet Lost Control - PLC), but it would still be synchronized, with the same latency and anchor points.

Apart from the Isochronous Channels, BLE Audio needs 2 more features :

• Extended Advertising : it enables to advertise more information, needed to expose some audio capabilities for example
• Periodic Advertising : this feature enables advertising which is periodic and not random. An observer can be synchronized to get some information, and see any changes during time.

4. Audio profiles

Now that the base of the Bluetooth® LE Audio (LC3 and isochronous channels) is enabled, the Bluetooth® SIG developed a whole new framework to be able to configure all types of audio streams :

Figure 1.1 Generic Audio Framework (to modify)

Figure 1.1 Generic Audio Framework (to modify)

The base of the audio framework is the audio stream management, defined by the Basic Audio Profile (BAP). It's the mandatory profile for Bluetooth® LE Audio. It defines the streams types, the configurations, the capabilities, the quality, the latency, etc.

BAP is used with 3 services :

• Published Audio Capabilities Service (PACS) : made to expose audio capabilities of the device.
• Audio Stream Control Service (ASCS) : enable to configure the Unicast Stream.
• Broadcast Audio Scan Service (BASS) : permits to solicit for clients to scan on behalf of the server for broadcast Audio Streams.

BAP defines 2 types of streams : Unicast and Broadcast, listed below.

5. Unicast

Unicast is the connected Audio Stream, based on the Connected Isochronous Stream (CIS). It means that with Unicast you can create connected audio streams over CIS. To create a Unicast Stream, we first need an ACL connection to exchange all of the useful information over GATT and LLCP. Unicast is divided in 2 roles :

• Unicast Client : Establishes connection to Unicast Server, discovers its capabilities and configure the Audio Stream. This role would be used by a smartphone, a laptop, a television etc.
• Unicast Server : Advertises its role, exposes its capabilities, accepts the Unicast Server to configure the Audio Stream. This role would be used by headphone, hearing aids, speaker, earbuds, or even a microphone.

Moreover, the Unicast Client can be able to stream to 2 Unicast Server synchronously.

To start a Unicast Audio Stream, over the ACL connection The Unicast Client and Server exchange the information about the quality of the stream, the retransmissions, the number of audio channels (mono/stereo), and the latency.

The stream can be

• unidirectional (for music) or bidirectional (for calls). This is called the topologies of the audio stream. They are selected by the Unicast Client from what the Unicast Server exposes. All the possible topologies are listed in the BAP Specification.
• low quality or high quality. The quality is also selected by the Unicast Client from what the Unicast Server exposes. All this possibilities are also listed in the BAP Specification.
• low latency or high reliability. This is exchanged between Unicast Client and Unicast Server. This is described in the BAP Specification.

The principal use cases are :

• 1 phone connected to 1 headset/speaker
• 1 phone connected to 2 earbuds/hearing aids.

SCHEMA

6. Broadcast

Broadcast is a non connected Audio Stream, based on Broadcast Isochronous Stream (BIS).The first device is the sender, it broadcasts Audio data over BIS, and exposes its broadcast information over extended advertising and periodic advertising. Any receiver capable of scanning and getting synchronized to this audio stream will be able to hear it. This is a new use case allowing an infinity number of users to listen to the same audio stream.

It can be music on a phone to share with friends, or an announcement like a conference translated in another language directly, or a train announcement to receive it directly in the earbuds.

This stream is public but it can be encrypted and you'll need to get a password to synchronize. As the stream is broadcasted, it can only be unidirectional.

BAP add also another feature . As broadcast is not connected, we need a way to synchronize to the stream directedly on the receive device. But most of the time these devices don't have any screen or too few buttons to select efficiently the audio stream. This role is called Broadcast Assistant, that would be a phone for example controlling a hearing device. The phone would scan and send the selected stream's information to the hearing device.

Broadcast defines 4 roles :

• Broadcast Source : establishes a BIS and advertise all the information over extended advertising and periodic advertising.
• Broadcast Sink : scan advertising to find Broadcast Source, and get synchronized to receive the Audio Stream
• Broadcast Assistant : scan advertising to find Broadcast Source, discovers the scan delegator (and broadcast sink) capabilities and send the information to get synchronized.
• Scan Delegator : exposes its capabilities and wait for a broadcast assistant to get information to which broadcast source to synchronize.

The principal use cases are :

• 1 phone/laptop/television sending the same audio to multiple audio devices.
• 1 announcement in an public spaces for anyone wanting to receive through Bluetooth®.
• 1 video or conference broadcasted for people with hearing loss, or translated in other languages.

SCHEMA

7. Remote Control Profiles

The Generic Audio Framework defines also new profiles to control some audio linked process :

Now that the audio stream is up, we need other profiles to configure the listening part. Are we listening to music, having a call ? This is the role of these other profiles, adding even more interoperability with any device.

• Media Control Profile (MCP) and its services ((Generic) Media Control Service - GMCS & MCS): The peripheral device would be able to control the central with any action : start, pause, play, stop the media, and read some information as track name, track position, next track etc.

• Call Control Profile (CCP) and its services ((Generic) Telephone Bearer Service - GTBS & TBS) : The peripheral would be able to do any action the phone can do : answer, decline, hold, terminate the call, and also see some information as caller name, signal, provider, etc.

• Coordinated Set Identification Profile (CSIP) and its service (Coordinated Set Identification Service - CSIS) : It enables multiple devices to identify as a coordinated set (earbuds or sound system for example). With these information, the central will be able to connect to all devices of this set and configure them together, for audio streams and controls.

• Microphone Control Profile (MICP) and its service (Microphone Control Service - MICS): It allows the user to control the audio input selection and its properties as the volume offset, mute and unmute etc.

• Volume Control Profile (VCP) and its serviced (Volume Control Service - VCS, Volume Offset Control Service - VOCS, Audio Input Control Service - AICS): It allows the user to control the volume of the audio stream, with the offset, the current volume position, the mute and unmute, etc. It permits also to select the audio output of the audio stream.

The Common Audio Profile (CAP) is made to be able to control BAP with all of the profiles below, creating a full framework to handle the audio streams. It enables to link some commands of calls or media with the start/stop of the audio stream, or read its information (music title, caller name ...) It enables also to link commands together when they need to be send to multiple peripherals inside one coordinated set (like 2 earbuds).

More details of the profiles and its parameters/possibilities are listed inside Architecture and Integration.

8. Use Case Profile

Above the CAP, we have the Use Case Profiles. They defines some capabilities and procedures to be able to interact with the most devices possible.

• Public Broadcast Profile (PBP) : Made for public broadcast (as announcements) and receivers (any user). It uses only the broadcast streams.

2 applications made with PBP are already available : STM32WBA Public Broadcast Profile

• Telephony and Media Audio Profile (TMAP) : Made for call and media use cases, it can use broadcast and unicast.

2 applications made with TMAP are already available: STM32WBA Telephony & Media Audio Profile

• Hearing Aid Profile (HAP) : Made for hearing aids use cases.

• Gaming Audio Profile (GMAP) : Made for gaming use cases.