Introduction

A couple of months ago at CES 2020 (January 2020), the Bluetooth SIG introduced the latest version of Bluetooth, version 5.2. This announcement was made alongside the announcement of the next generation of Bluetooth audio, named: LE Audio.

The major change introduced in version 5.2 is a new feature called Isochronous Channels (ISOC). ISOC lays the foundation for the implementation of LE Audio in BLE devices, supporting Bluetooth 5.2 or later.

However, ISOC is not the only newly added feature in this latest version. In today’s post, we’ll look at the three major features introduced in version 5.2, two of which are not directly related to LE Audio.

The three features are:

  • Isochronous Channels (ISOC)
  • LE Power Control (LEPC)
  • Enhanced Attribute Protocol (EATT)

The Next Generation of Bluetooth Audio: LE Audio

Before we cover the Isochronous Channels feature in more detail, let’s talk a bit about LE Audio and what it means for us as both consumers and developers.

From the very start, Bluetooth technology has proven itself to be the go-to solution for wireless audio. These days, Bluetooth audio devices are everywhere from wireless speakers and vehicle infotainment systems to wireless headphones and earbuds. In fact, the most common use of Bluetooth is in streaming audio applications.

Traditionally, the Bluetooth radio used for these applications is the original Bluetooth radio commonly referred to as Bluetooth Classic or BR/EDR (Basic Rate/Enhanced Data Rate) which existed since version 1.0 of the specification. The new LE Audio, on the other hand, operated on Bluetooth Low Energy (BLE).

LE Audio not only accomplishes the same features and specifications of Bluetooth Classic but also introduces a few new features as well as improve on existing ones.

Here are some highlights of the new LE Audio:

  • Introduces a new high quality, low-power audio codec called the Low Complexity Communications Coded (LC3).
  • LC3 provides high quality even at lower data rates than the standard SBC codec used in Bluetooth Classic implementations.
  • Supports multiple, synchronized audio data streams. This characteristic allows the implementation of truly wireless earbuds (independent synchronized audio streams directly to each earbud: L & R) as well as broadcasting audio streams to multiple listeners.
  • Multi-stream capabilities also provide support for streaming audio streams in multiple languages. It also allows sharing of audio content whether it’s a personal use-case such as sharing with friends and family or a location-based use-case such as public venues, TVs in gyms, or public announcements in airports.
  • One of the major applications that will benefit from LE Audio is Bluetooth hearing aids. Hearing aid devices require low and efficient power consumption. Being able to utilize BLE with its efficient power consumption characteristic, hearing aids are not only able to last longer on a single charge but manufacturers are also able to make these devices smaller and more discreet.

Keep in mind that the implementation of LE Audio in devices from different manufacturers while achieving interoperability relies on multiple LE Audio profiles that are set to be released in the latter part of 2020.

1. Isochronous Channels (ISOC)

If you look up the definition of the word “Isochronous”, you’ll find that it means “occurring at the same time”. In the context of BLE, it means supporting (1) data transmissions that are time-sensitive and (2) synchronized rendering of these data streams across multiple receivers. As we mentioned earlier, this new feature serves as the foundation for LE Audio.

It introduces a new Physical channel in BLE: the Isochronous Physical Channel (ISOC), which can be used on any of the LE PHYs: the 1M, 2M PHY, and LE Coded PHY (including both s=2 and s=8 configurations).

Connection-oriented and Connectionless Communication

ISOC supports both connection-oriented and connectionless communication. In BLE terminology, this means that both connections and broadcasts are supported.

In connections, each stream is referred to as a Connected Isochronous Stream (CIS). When CISes need to be synchronized, such as ones sent to left and right earbuds, they are configured to be part of a single group referred to as a Connected Isochronous Group (CIG).

Streams that are part of the same CIG share timing reference data which is necessary for synchronized stream rendering on multiple receivers. CIGs allow bi-directional data transfer such as in earbuds that contain microphones and for sending control data to the source device.

Note that a device may create multiple Connected Isochronous Groups.

Connected Isochronous Streams (CIS) and Connected Isochronous Groups (CIG)

For connectionless communication (broadcasts), a group of synchronized streams may be used to stream data from a single source to multiple sinks. Each stream is referred to as a Broadcast Isochronous Stream (BIS). A group of BISes are referred to as a Broadcast Isochronous Group (BIG).

An example of this is a TV streaming audio data to multiple sinks such as different individuals wearing earbuds.

Just as in the case of CIGs, a device may create multiple BIGs.

Broadcast Isochronous Streams (CIS) and Broadcast Isochronous Groups (CIG)

ISO Interval

The most important parameter that pertains to ISOC is the ISO Interval. It defines the interval at which Events occur. Each event is split into multiple subevents.

The ISO Interval ranges from 5 milliseconds to 4 seconds.

In Connection-oriented communication, in each subevent, the master will send a packet to the slave, and the slave will respond with a packet. In connectionless communication, however, only the master will send a packet in each subevent. In this case, these packets could either be isochronous data or broadcast control information.

Retransmissions

Data retransmissions are supported by Isochronous channels, but they differ between connection-oriented and connectionless communication. In the case of Broadcast Isochronous Streams, retransmissions are sent by the Master without influence from the slave(s), and in the case of Connected Isochronous Streams, retransmissions are sent when a Slave has not acknowledged a packet.

Also, note that retransmissions are sent on different channels than the original packet to reduce the risk of packet loss or corruption.

2. LE Power Control (LEPC)

In wireless communication, the received signal strength indicator (RSSI) can be used to estimate the distance of the receiver from a transmitter if the original transmit power is known to the receiver.

Wireless receivers have an optimal received signal strength range. Higher or lower than this range may cause issues with decoding the received signal, so the RSSI within this range provides better signal quality.

With the new LE Power Control feature (LEPC), a receiving device monitoring the level of the signal (the RSSI) from a connected device may request a change in the transmit power level used by its peer in either direction. A transmitter may also change the transmit power voluntarily and relay that information to the receiver.

Utilizing LEPC and keeping the RSSI within the optimal range of the receiver provides a few benefits including:

  • Better control over the quality of the signal.
  • Reducing error rates at the receiving end.
  • Improving coexistence with other signals in the 2.4 GHz band, including ones other than Bluetooth (such as Wi-Fi and Zigbee).

Support for this feature is optional, but if the two devices support this feature, then they must use it for power management control.

3. Enhanced Attribute Protocol (EATT)

The new Enhanced Attribute Protocol (EATT) is an upgraded version of the original Attribute Protocol (ATT).

Whereas the original unenhanced Attribute protocol operates in a sequential manner, the Enhanced Attribute Protocol provides a way to perform concurrent/parallel transactions between a BLE client and a server and potentially reduce the latency of operations in some applications.

For example, this is useful on a smartphone where multiple apps may be interfacing with a Bluetooth Low Energy device. By utilizing EATT, an app’s Attribute transaction would not be blocked while another app’s ATT transaction is in progress, essentially allowing different apps to interact with a Bluetooth Low Energy device in parallel and potentially reducing latency.

The way this works is by separating the L2CAP layer Maximum Transmission Unit (MTU) from the Attribute layer’s MTU. Here’s an example to better visualize this:

Enhanced Attribute Protocol: ATT MTU vs. L2CAP MTU

If the L2CAP layer MTU is smaller than the Attribute layer MTU, then this will cause the L2CAP layer to break up the PDUs coming from the (upper) Attribute layer into smaller chunks and interleave the PDU chunks coming from different applications.

In this example, we have App A that is sending a PDU larger than the L2CAP MTU size, which means it will be broken up into chunks of sizes up to the L2CAP MTU. This will allow the PDUs from App A and App B to be interleaved instead of App B’s PDU being blocked by App B’s PDU.

The last couple of things we want to mention is that:

  • The Enhanced Attribute Protocol is optional per the specification
  • It requires encryption of the connection between the two Bluetooth Low Energy devices. This makes it inherently more secure than the original unenhanced Attribute Protocol.

Summary & Closing

In this post, we went over the three major features introduced in the latest version of Bluetooth: version 5.2. The features are:

  • Isochronous Channels (ISOC)
  • LE Power Control (LEPC)
  • Enhanced Attribute Protocol (EATT)

Take your BLE knowledge to the next level

If you’re interested in staying up-to-date on the latest developments in BLE including exclusive reports and guides on the latest Bluetooth specifications and enhancements, then check out the Bluetooth Developer Academy.

By joining the Bluetooth Developer Academy, you will get access to a growing library of courses and tutorials.

Here’s what one Academy member has to say:

If you’re developing a BLE project, you need two things, a good BLE sniffer and the Bluetooth Developer Academy. I am very happy to be part of this community and look forward to what comes next.

– Christopher Gates, Principal System Security Architect – Velentium

The current courses include:

  • The Basics of Bluetooth Low Energy
  • Analysis of BLE events using a BLE sniffer
  • Long-range mode (Coded PHY) using Bluetooth 5.0
  • Developing nRF52 applications using Visual Studio Code
  • Over the Air Device Firmware Update (OTA DFU) – nRF52 use case
  • Getting Started with Zephyr (including adding custom GATT Services and Characteristics)
  • The Developer’s Guide to what’s new in Bluetooth 5.2
  • SweynTooth: A Summary for BLE Developers
  • Introduction to BLE Security
  • Getting Started with BlueZ development
  • Introduction to BLE Development for iOS
  • …and more courses added each month!

For a full list of courses included, check out the Courses Library here:

Bluetooth Developer Academy Courses Library

The Academy also features a thriving community of Bluetooth experts, developers, and innovators. You’ll get to connect and interact with other experts in the Bluetooth space, learn from others’ experience and knowledge, and share yours.

Also included in the Academy is access to private support from me personally.

In the community, you will find:

  • Discussions around new features such as long-range mode (Bluetooth 5.0) and direction-finding (Bluetooth 5.1).
  • Discussions around the capabilities of different BLE sniffers.
  • Comparisons of BLE support and restrictions in iOS and Android.
  • Various technical questions and answers to these questions.
  • Listing of Bluetooth-related job openings.
  • And many more discussions!

Learn More About the Bluetooth Developer Academy