Channel Sounding is an innovative new feature coming to Bluetooth technology, enabling distance estimation between two devices with a high level of accuracy. The Bluetooth technical community, including Packetcraft, has been working on Channel Sounding implementations for many months now, and a draft Channel Sounding specification was released by the Bluetooth SIG in 2023. To provide a deeper technical understanding of the technology, Packetcraft has developed a series of articles that detail the protocol exchanges that make Channel Sounding work. We are also making the protocol analyzer log file described in these articles freely available for download.
If you’re not yet familiar with Channel Sounding, this article by Packetcraft and Imec provides a good overview. Channel Sounding can estimate the distance between two Bluetooth low energy devices by making round-trip time measurements or phase measurements. To make these measurements, both devices alternatingly transmit and receive signals in a coordinated fashion.
Prior to these coordinated signal exchanges, a sequence of protocol exchanges is required to set everything up. The two devices need to communicate capability and configuration information for the Channel Sounding (CS) procedure. They also need to establish secure communications such that the distance measurement cannot be manipulated or spoofed. This article will focus on these protocol exchanges, which take place before the signal exchanges and measurements take place.
Channel Sounding defines two device roles: Initiator and reflector. The initiator device transmits first when the devices exchange signals and is also typically the device that makes the distance measurement estimate at the end of the CS procedure. The Initiator and reflector roles are independent of the BLE Central and Peripheral roles used to establish the ACL connection.
A high-level view of the protocol exchange is shown below. The first step is to establish an encrypted ACL connection between two BLE devices. This is the same type of encrypted ACL connection that BLE devices use all the time to exchange data.Â
Next, the devices exchange Channel Sounding capabilities information security information. Based on their mutual capabilities, the devices agree on a Channel Sounding configuration for the procedure. Then, the CS procedure is started and the devices exchange signals and perform measurements in one or more CS subevents.
To take a closer look at the protocol transactions that implement these features, we’ll dig into a log file created with the Bluetooth Vanguard protocol analyzer from Ellisys. The Vanguard analyzer is one of the few Bluetooth protocol analyzers on the market today that is capable of capturing Channel Sounding signals.
The protocol exchange for the CS procedure between two devices happens at Bluetooth’s link layer, and the analyzer screenshot below shows the new link layer control protocol (LLCP) messages for Channel Sounding:
·      CS Security Request and Response
·      CS Capabilities Request and Response
·      CS Config Request and Response
·      CS Request, Response, and Indication
Now let’s look at these messages in more detail.
CS Security Request and Response
This procedure exchanges exchange three pieces of data—the CS initialization vector, the instantiation nonce, and the personalization vector—that are used as inputs to the cryptographic functions used to protect CS signals. Note that CS security is separate from the regular link layer security procedures and data encryption at the link layer. CS security cryptographically protects the CS signals and packets used to perform measurements.
CS Capabilities Request and Response
This procedure exchanges several parameters to inform a device about the peer device’s CS capabilities. While there is a mandatory minimum set of capabilities that a CS device must support, devices can also support many optional features, and both devices must agree to use parameters that they both support. The CS capabilities of a peer device can also be set by the host or can be retrieved from a previous CS capabilities LLCP exchange. These capability parameters are used in the next step—the CS Configuration procedure.
CS Config Request and Response
This procedure exchanges several parameters to set the configuration of the CS procedure. This sets parameters such as the CS channel map, CS mode (round-trip-time or phase-based ranging), the devices CS role (initiator or reflector), and the low level timing parameters of the CS signal exchange. The parameters must be selected such that they fall within the capabilities of both devices. A CS configuration also has an associated config ID, which stores the configuration for future use.
CS Request, Response, and Indication
This procedure starts the exchange of CS signals between two devices. It contains information about the timing and duration of the CS procedure and how the procedure is divided into subevents. The messages also contain the config ID exchanged during CS Config procedure to retrieve the stored configuration to be used for the procedure.Â
While the CS Request message can be sent by either a Central or Peripheral device, the CS Indication message is always sent by the Central. This is because the anchor point for the CS signal exchange is set in the CS Indication packet. As a result, the message exchange will either be CS Request / CS Indication (as in the log file above) or CS Request / CS Response / CS Indication.
After the CS Indication is sent, the CS signal exchange starts at the precise time established. This signal exchange is where the real Channel Sounding action is taking place—it is an entirely separate protocol unto itself. In Part 2 of this article, we will explore the CS signal exchange in detail. In the meantime, feel free to download the protocol analyzer file and take a closer look for yourself here.
Viewing the protocol analyzer file requires software from Ellisys.Â
Contact Ellisys here.