Introduction to Bluetooth LE Audio

Coming soon

1. Introduction

Bluetooth® Low Energy (Bluetooth® LE or BLE) Audio is the new Bluetooth® feature enabling the Audio Streaming over Bluetooth Low Energy. In today's Bluetooth® devices, almost everything was done with the Bluetooth® Low Energy. Except the audio streaming that requires a Dual Mode controller for streaming audio with Classic Bluetooth®. The Bluetooth® Special Interest Group (Bluetooth® SIG) thought of a solution for 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 Classic (BR/EDR) Audio, Bluetooth® LE Audio reduce the power consumption and allow a whole world of new 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.

2. LC3 Codec

Bluetooth® LE Audio is based on a new audio codec : LC3 for Low Complexity Communication Codec. This codec is mandatory and brings a new quality higher than any codec based on Classic Bluetooth® Audio.

Ref : https://www.bluetooth.com/bluetooth-resources/mrn-e-audio/

3. Isochronous Channels

Bluetooth® LE Audio is also based on a Bluetooth® 5.2 optional feature : Isochronous Channels. This a link layer feature. This feature enables the transmission of a stream over a new connection (isochronous stream). If we compare a Isochronous Stream to a ACL Data transfer (used in today's Classic Bluetooth® Audio applications) we can list some important differences :

ACL data transfer 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.

There are 2 types of isochronous streams :

• Connected Isochronous Stream (CIS) : enabling the user to have an audio stream over a Bluetooth® connection as todays headset. It's also able to stream to 2 devices 2 synchronized audio streams, for earbuds or hearing aids.
• Broadcast Isochronous Stream (BIS) : enabling a user to broadcast to any able to receive it 1 or 2 audio streams. It does not need a connection meaning there could be an infinite number of receivers.

This 2 types of isochronous streams adds new features, it's defining the latency for the system (which 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).

• periodic advertising + extended

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 :

File:Package Overview.png

Figure 1.2 STM32WBA Bluetooth® Package Overview

The base of the audio framework is the audio stream management, defined by the Basic Audio Profile (BAP) and its services :

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

BAP brings 2 types of streams : Unicast and Broadcast.

5. Unicast

Unicast is a 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 a ACL connection to exchange all of the information over GATT and LLCP. It's divided in 2 roles :

• Unicast Client : Establish connection to Unicast Server, Discover its capabilities and configure the Audio Stream. This role would be used by a smartphone, a laptop, a television etc.
• Unicast Server : Advertise its role, expose its capabilities, accept 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) etc. 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. The stream can be low quality or high quality. They are selected by the Unicast Client from what the Unicast Server exposes. All this possibilities are also listed in the BAP Specification. The principal use cases are :

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

6. Broadcast

Broadcast is a non connected Audio Stream, based on Broadcast Isochronous Stream (BIS).The first device is the sender, sending Audio data over BIS, and expose 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 brings also another notion : as broadcast is not connected, we need a way to synchronize to the stream if the receiver device doesn't have any screen, buttons … This role is called Broadcast Assistant, that would be a phone for example controlling a Scan Delegator, that would be some hearing device. The phone would scan and send the information to the hearing device of the selected stream.

Broadcast brings 4 roles :

• Broadcast Source :
• Broadcast Sink :
• Broadcast Assistant :
• Scan Delegator :

7. Profiles

The Generic Audio Framework brings 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 service (Media Control Service - MCS): The peripheral device would be able to control the central with any action : start, pause, play, stop the media, and read any information (track name, track position, next track etc.)
• Call Control Profile (CCP) and its service (Telephone Bearer Service - TBS) : The peripheral would be able to do any action the phone can do : answer, decline, hold, terminate the call, and also see any information (caller name, signal, provider …)
• 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 service (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 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. It enables also to link commands together when they need to be send to multiple peripherals inside 1 coordinated set. (

9. Difference between LE Audio and Classic Audio

First, Bluetooth Low Energy allows a reduce consumption of more than XXX [ref]. Second, it's based on the Isochronous Channels in the Link Layer [ref]. It handles the audio data packet in a way to define anchor points, retransmissions to be able to qualify the latency of the whole system. It defines 2 streams : Connected Isochronous Stream (CIS), allowing to perform a stream over a connected BLE link and Broadcast Isochronous Stream (BIS) allowing to broadcast a stream to anyone able to scan it. Third, as A2DP and XXXX was the profile handling the audio streaming over BR/EDR. The SIG defined a whole framework of profile handling the audio stream and all the associated functions.

- Power consumption and BLE

- Broadcast

- Multi stream (earbuds)

- Framework