In Part 1 we introduced the new Bluetooth distance measurement innovation known as Channel Sounding (technical overview) which measures Round-Trip Time (RTT) and/or Phase-Based Ranging (PBR) between two Bluetooth Low Energy devices to achieve accuracy down to 10cm. To make these measurements, both devices alternatively transmit and receive signals in a coordinated fashion.
Part 1 also focused on the protocol exchange needed to communicate capability and configuration information between the two devices. This protocol exchange is required before the signal exchanges and measurements can take place. After the protocol exchange, both devices exchange tones for distance estimation and packets containing related data. In Part 2, we will now explore the Channel Sounding (CS) signal exchange in detail. This procedure is further divided into subevents and steps for optimal coexistence and flexible scheduling with other Bluetooth communications. As the procedure begins to repeat through the available physical channels, the devices exchange measurement results after each subevent.
At the end of the protocol exchange described in Part 1, the CS procedure was configured as follows:
· CS mode set to mode-1, which is for measurement using RTT
· Number of mode-0 steps set to 3
· Channel map with 72 total channels
· Procedure contains 1 event, with 1 subevent, with a total of 75 steps (1 step per channel plus 3 mode-0 steps)
Note that the event, subevent, and step configuration in this example CS procedure is relatively simple. The protocol also allows multiple events per CS procedure and breaks an event into multiple subevents spread out in time.
The packets used in a CS step have some differences from other Bluetooth packets. A new packet type called the CS_SYNC is used, which is like a regular Bluetooth LE packet but with no header or CRC fields. There is also no whitening or encryption of the CS_SYNC.
The access address in the CS_SYNC has additional security requirements over regular Bluetooth LE. In regular LE packets, the access address used by devices in a connection remains constant for the duration of the connection. In the CS_SYNC, the access address is a cryptographically generated random sequence that changes with every step, and a different access address is used by the Initiator and Reflector. This makes it more difficult to intercept and spoof a CS procedure.
SIDEBAR: There is an additional mechanism that helps reduce the risk of a Man-In-The-Middle (MITM) attack by leveraging RTT to enable secure distance bounding. The Initiator sends these cryptographically scrambled packets to the Reflector. The distance between the devices is calculated based on the roundtrip time of flight (ToF) for the packets. RTT offers an independent distance measurement to cross-check the PBR measurement, helping minimize the risk of MITM attacks. Combining RTT with PBR, Channel Sounding enables secure and accurate distance measurements between Bluetooth devices.
A CS_SYNC packet also optionally contains a sounding sequence or a random sequence. The sounding sequence is a bit sequence of alternating 0’s and 1’s. The random sequence is a cryptographically generated random sequence.
Now let’s have a look at the CS procedure in the Ellisys the Bluetooth Vanguard protocol analyzer produced log file.
As seen in the log file above, there are references to a mode-0 step, which is for synchronization and calibration, helping compensate for clock drift and frequency offset, respectively. The results are collected in a fractional frequency offset table.
Also noted above is mode-1 which is the Round-Trip Time (RTT) procedure between the Initiator and the Reflector. This is where the CS_SYNC packets are exchanged back and forth.
Mode-1: RTT
For completeness, though not shown in this log file, are mode-2 and mode-3. Mode-2 is used to exchange PBR Channel Sounding tones between the Initiator and the Reflector, measuring phase and amplitude of the communication channel. Mode-3 is used to exchange both RTT and PBR Channel Sounding tones combined in each step. The RTT distance measurements can be cross-checked with PBR results as outlined above to minimize risk of MITM and relay attacks, which can be detected by differences in distance estimation.
To note, in a MITM attack, data would be intercepted between the Initiator and the Reflector and would be viewed and modified before the attacker relays the (sometimes altered) data to the intended recipient device. In contrast, in a relay attack, an attacker intercepts communication between the two devices and then, without viewing or manipulating it, relays it to another device. The main difference between a MITM and a relay attack is, in a relay attack, neither the sender nor the receiver needs to have initiated any communication between the two. In some cases, an attacker may modify the message but usually only to the extent of amplifying the signal.
The results from the tone exchange are then processed by an application using a distance estimation algorithm to calculate the distance between the devices. The selection of algorithm will vary based on the application’s needs and anticipated radio environment. At present, there are several 3rd party algorithm suppliers that we are in regular contact with.
In early 2024, Packetcraft began shipping a pre-release of Bluetooth Channel Sounding solution along with our Bluetooth Qualified 5.4 Link Layer software to several of our semiconductor licensees. For product information, please visit here.
You may download the protocol analyzer file which is viewed in these articles and take a closer look at how the technology works; it was captured using Packetcraft’s Link Layer implementation of Channel Sounding.
As the world prepares for the formal introduction of Channel Sounding, many product and solution companies are getting ready with applications ranging from digital key for automotive and secure building access, to Real Time Location Systems (RTLS) and proximity detection services. Packetcraft is helping both chip and product companies prepare and bring innovative products to market.
-------------------------
Viewing the protocol analyzer file requires software from Ellisys. Contact Ellisys here.