Part 7: Versions 5.0 to 6.0
In the last of seven installments about the ubiquitous wireless protocol, Robert explores the bug corrections and new features through Bluetooth Versions 6.0. Previously he wrote about secure connections and he started the series in April 2024 with a review of the low energy protocol.
Welcome back to the world of Bluetooth. In my last six articles in Circuit Cellar, published since April 2024, I presented the overall Bluetooth Low Energy (BLE) protocol. In the first article of the series (“No Blues with Bluetooth. Part 1: An Introduction.” Circuit Cellar 405, April, 2024) [1], I told you the history of Bluetooth and explained that no less than 14 Bluetooth versions have been introduced since 1999 (Figure 1). In particular, BLE was a new feature of Bluetooth 4.0.
A simplified view of all Bluetooth versions and their key optional features. In this article I focus on versions 5.0 to 6.0, introduced in the past 8 years.
Last month, I talked about Bluetooth 4.2 and its “Secured Connection” feature, which greatly improves the security of BLE. But what are the major features of the other Bluetooth versions? That’s a nice subject to close this series, isn’t it? So take a seat, and discover Bluetooth 5.0, 5.1, 5.2, 5.3, 5.4, and last but not least, the newly announced Bluetooth 6.0 (introduced in September, 2024.)
OPTIONS
Before digging into these new versions, I must remind you of a fundamental thing about Bluetooth. Each new version basically provides two things: bug corrections and new features. Bug corrections must be supported to state a compliance with a new version, but new features are always optional (at least since Bluetooth 2.0). In other words, the designer can decide whether or not to support each of the new features.
To be 100 percent clear, it is indeed possible to sell a Bluetooth 6.0 qualified device with absolutely no new features, compared to a Bluetooth 4.0 device, for example. You may argue that a customer would expect to get the newly announced features when buying a new version, but that’s not necessarily the case. Because Bluetooth is made for interoperability, two communicating devices will negotiate and will use a given feature only if both devices support it. If not, they will just avoid using it. However, if the feature is mandatory for your application, then it will be your job to close the link, and maybe to inform the end user that there is an incompatibility.
BLUETOOTH 5.0
Anyway, let’s explore each new version since Bluetooth 4.2. For simplicity, I will focus on the major new feature(s) of each version. If you need more details, don’t hesitate to download from the Bluetooth SIG website the “Bluetooth core specification” of each version, which starts with a feature list [2].
Version 5.0 was launched in 2016, so it is now an old story. This version added significant improvements to BLE in terms of radio performance, and paved the way for plenty of new applications.
New PHY Bit Rates: Do you remember that BLE uses a 1Mbps raw bit rate? Version 5.0 introduced three new optional bit rates: A faster one (2Mbps), and two slower ones (500kbps and 125kbps). The 2Mbps of course improves the link speed, but why slower bit rates? Simply because reducing the bit rate of a radio link improves the sensitivity of the receiver, and thus the range of the link. That’s why these slower bit rates are called “LE long range.” They are also called“Coded PHY,”and I will explain why in a minute.
In theory, reducing the bit rate by a factor of two gives a 3dB improvement in sensitivity. The actual figures are close (Figure 2): Switching from the standard 1Mbps to long range 125kbps gives about a 7dB improvement, or a little more than twice the range in open air (6dB). In practical terms, we were used to about 20m with a typical low-power BLE product. “Long range” means up to 50m, when propagation conditions are reasonably good. This isn’t a small improvement, even if reducing the bit rate also increases the power consumption, since transmissions take a longer time.
Version 5.0 provides three new PHY layer bit rates ranging from 125kbps to 2Mbps in addition to the standard 1Mbps. Radio sensitivity is directly linked to the bit rate.
How are these new bit rates implemented? The 2Mbps mode is simply using a faster FSK modulation, and could be activated after the two devices are connected. Long-range modes are more interesting. The difficulty is that these long-range modes must also be applicable to the advertising and discovery phase. So, a BLE scanner must be able to receive advertisement frames from standard or long-range devices. It must listen to these modulations at the same time, and this isn’t easy to do.
Of course, the Bluetooth Special Interest Group (SIG) members didn’t want to increase the cost of a BLE chip by implementing several simultaneous receivers. So, rather than changing the modulation, 500kbps and 125kbps modes are still based on a 1Mbps modulation, but with additional channel coding (Figure 3). For 500kbps, each bit is transmitted as 2 bits, therefore dividing the actual bit rate by 2. These 2 bits are calculated as exclusive OR of, respectively, the last 4 input bits or the last 4 input bits except the N-2 one. For those who like signal processing, this is a simple form of convolutional forward error correction, and it allows the receiver to improve its sensitivity by 3dB. In addition, the 125kbps version is based on the 500kbps version, but each of the 2 coded bits are sent using a sequence of 4 bits: each “0” is replace by “0011” and each “1” by “”1100.”
Long range bit rates (125 and 500kbps) are implemented using a 1Mbps PHY bit rate and digital channel coding.
Extended Advertising: Even if these improved bit rates are the most publicized new features of 5.0, another one is essential for plenty of new applications–”Extended Advertising” (Figure 4). When I presented the GAP protocol, I explained that each BLE device announces its presence by broadcasting the same advertising packet successively on three dedicated channels (channels 37, 38, and 39). This is adequate for many use cases, but traffic jams may occur on these channels if a large number of co-located devices are trying to broadcast long advertising messages.
Version 5.0 also adds an interesting Extended Advertising mode, in which the advertised data is sent on auxiliary traffic channels.
Version 5.0 provides a very interesting new feature to significantly reduce the occupancy of the advertising channels. Basically, very short advertising messages are still sent on the advertising channels (thus providing compatibility), but they don’t include any actual data. Rather, they state that there is a follow-up message that will be sent on another channel (secondary channel), which does contain data. And this follow-up may also have follow-ups, and so on. In this way, the advertising capacity of the network is greatly increased, since the full set of 36 data channels can be used.
Periodic Advertising: Finally, 5.0 introduced also another improved advertising mechanism called “Periodic Advertising.” This is a kind of enhanced implementation of extended advertising, but here there is a continuous flow of advertising messages sent on the traffic channels. Specific messages on the standard 37/38/39 advertising channels allows the next periodic advertising message to be found. This periodic advertising mode allows an unlimited number of scanning devices to synchronize with advertising devices and get their data at predictable fixed intervals — all without the need to establish a connection.
Bluetooth 5.1
What about 5.1? This version is less impressive than 5.0 but still introduces a sexy new possibility — ”Angle of Arrival (AoA) support” (Figure 5). Regular readers may remember that I wrote an article about indoor location techniques in 2022 (“The Darker Side – RF location techniques.” Circuit Cellar 379, February, 2022) [3]. One of these techniques is based on a measurement of the angle of arrival of a radio wave, thanks to phase measurement among several antennas. Two antennas are a bare minimum, but more antennas improve the performance.
Version 5.1 provides a mechanism to support location services through angle of arrival detection. This is done using a constant tone extension (CTE) field added at the end of the radio frames.
Even if such a method is possible with any radio protocol, Bluetooth version 5.1 adds a new feature which helps substantially—”Constant Tone Extension (CTE).” When this feature is supported, a device can be asked to add a short burst of a pure carrier wave after each transmission. In fact, Bluetooth doesn’t specify the phase detection and location algorithm, but this CTE feature simplifies their implementation. The same CTE extension also allows a similar mode, but with several antennas on the transmitter side—”Angle of Departure (AoD).” Here the antennas of the transmitter are switched when transmitting the CTE.
Several providers and device manufacturers have implemented AoA-based on CTE. As an example, Figure 6 shows the XPLR-AOA-1 development kit proposed by the uBlox module manufacturer. As shown on the figure, three PCB patch antennas are implemented in each direction, providing a two-dimension angle calculation.
An example of AoA evaluation kit from uBlox, using a set of three antennas in each of the two directions for 2D location
BLUETOOTH 5.2
Isochronous Channels: Do you remember that Bluetooth “classic” was invented back in 1999 to support audio applications, with BLE optimized for non-audio, low-power applications? This changed with Bluetooth 5.2, which introduced key new features to support audio on BLE. The major one is called “Isochronous Channels” (Figure 7). With this new feature, two high-throughput, continuous transmission schemes configurations are supported. First, there is a connected mode, where a controller device can send a continuous data stream over BLE to two or more remote devices. You may not know but before this, there was no Bluetooth-standardized way to connect two earbuds to the same smartphone. That’s why earbuds of different manufacturers used to be incompatible.
The key new feature of version 5.2 is Isochronous Channels, which supports baaoth connected and broadcast modes.
The second scheme is “Broadcast Isochronous Channels.” It is based on an improved version of the extended advertising introduced in 5.0. With this mode, a controller can broadcast a continuous stream to several remotes. For example this allows music to be broadcast to several loudspeakers, or shared with your friends.
You may wonder why these features are called Isochronous Channels. It’s because the key intended application is audio. Data packets must be played exactly at the same time by the different receivers, especially if one of them is in your left ear and the other in your right ear. Isochronous Channels are based on precise time slots, and the protocol ensures that all data packets are well received by each target before the end of a time slot (Figure 8).
Isochronous Channels implements time-synchronized data delivery to several remotes, illustrated here in the case of the connected mode.
What are these Isochronous Channels used for? This isn’t defined in the Bluetooth 5.2 core specification, but audio is the target. However, Isochronous Channels are only the low-level layers required for audio. Plenty of higher-level protocol layers are required for an end-to-end great user experience. Since 5.2, the Bluetooth SIG has designed an impressive set of new application layers based on Bluetooth 5.2, named “LE Audio.” It includes a new high-quality audio codec (LC3) and features to support zillions of application cases. The bad news is that I will definitely not present LE Audio here, first, because of space, and more importantly, because I’m not an expert in this field. This will require a worldwide expert to write more comprehensively about these features. Perhaps this expert will grace future pages of this magazine. Stay tuned!
BLUETOOTH 5.4
Periodic Advertisement with Response: Skipping 5.3, which was honestly a bit less exciting, let’s present a quite exotic feature introduced in 5.4. Periodic Advertisement with Response (PawR) (Figure 9). This feature targets a quite specific application—electronic shelf labels (ESL). ESLs are very low-power devices displaying product information (name, price, etc.), usually using an e-ink LCD. And of course, ESL’s information must be updated from time to time. Occasionally, they also need to send back a message to the central system—for example, acknowledgments or alarms when battery level is getting low. However, the difficulty is that a typical department store may have tens of thousands of ESLs on their shelves. Could BLE be used in such a case? Well, not before 5.4, since BLE didn’t support so many simultaneous connections. Things changed with 5.4 and the PAwR feature. Even if you are not involved with ESLs, PAwR may be a nice solution for your project if you need to implement one-to-many bidirectional links.
Version 5.4 adds Periodic Advertisement with Response, targeting massive one-to-many applications such as electronic shelf labels.
How does it work? PAwR is based on advertising, specifically on the Periodic Advertising features introduced in 5.0 and briefly presented above. This means there is no actual connection between each ESL and the controller system. Things are a bit reversed as compared to a traditional BLE system. The central system is the advertiser, and devices (here ESLs) are scanners and wake up regularly to listen to the advertisements. However, PAwR adds an improvement above Periodic Advertising—the possibility of sending back a message to the advertising system, even with a large number of devices. This is made possible thanks to a new notion of sub-events. Each periodic advertising is followed by a number of sub-events (1 to 128), and each sub-event provides a number of timeslots for devices to send their packets (up to 255 per sub-event).
PAwR may be used for plenty of applications, but the Bluetooth SIG has defined a specific application-level profile for ESLs, which is available on their website [4].
Encrypted Advertising Data: In my last article on security (“No Blues with Bluetooth, Part 6: Bluetooth Cybersecurity Basics.” Circuit Cellar 412, November, 2024) [5], I explained that BLE doesn’t provide any security for the advertisement packets, which would obviously be a problem for an application like ESLs. Fortunately, version 5.4 also adds a new feature called Encrypted Advertising Data (EAD). As its name suggests, this is a way to provide a security layer for advertisements. The scanner first needs to securely connect to the advertiser and read a specific GATT service to get the deciphering key, and can then use it to decode the advertised ciphered data.
If you are interested in this subject, there is a nice “PAwR + long range” demo published on the website of NovelBits [6].
Bluetooth 6.0
Channel Sounding: The latest Bluetooth version to date is the 6.0, which was published in August 2024. This version adds a couple of new optional features, but the most exciting is “Channel Sounding,” a new location technology. Recall that 5.1 introduced AoA, which helped to locate an object based on the angle of arrival of radio waves. AoA required several antennas. Furthermore, measuring an angle is not enough to locate an object, except if there are several locators around. Channel Sounding provides another solution: It allows you to evaluate not angles but the distance between two devices. This is done through a measurement of the round-trip delay of the radio waves. Maybe some of you are using ultrawide band (UWB) technology on their iPhones to locate Apple’s AirTags? This is roughly the same concept, but a Bluetooth radio is used instead.
How is Channel Sounding implemented? Rather than measuring actual time of flight differences (which are very small, since radio waves propagate at 300,000,000m/s), Channel Sounding measures phase differences (Figure 10). One of the devices, called the Initiator, sends a reference modulated signal on a given channel, using a new physical layer based on an Amplitude-Shift-Keying (ASK) modulation. The other device, called the Reflector, sends back the signal with a precise time delay. The Initiator then measures the phase shift between TX and RX signals. The operation is repeated on each of the available physical channels. If you do the math, you will see that doing this measurement at multiple channels allows you to get the distance. This is explained in an application note published by Bhargavi Nisarga from Texas Instruments [7].
Version 6.0 adds Channel Sounding. It is another way to measure a distance between two devices, but here using time-of-flight measurement, specifically phase measurements on different frequency channels.
Of course, this is somewhat more complex than that, because all these measurements must be done in parallel with the other BLE activities (advertisements, connection events, and so on). The BLE stack needs to take care of the negotiation and setting-up of the sounding procedure between two devices, and schedule the operations. Security is also addressed.
As in the case of AoA, the Bluetooth SIG provides the raw mechanisms to implement Channel Sounding, but not the actual location algorithm itself, which is left open for implementing companies. According to an article published by the SIG [8], Channel Sounding may achieve an accuracy of about 30cm in typical indoor environments. I haven’t tested it yet, but the first Channel Sounding evaluation kits are starting to be available, so please let us know if you get one of them.
REVISION DRAWBACKS
Optional Support of New Features: As explained, the Bluetooth SIG has done an admirable job, and introduced many new versions through the years with great new features. On the downside, I also warned you that these new features are always optional. Let me restate it once more with an example. Bluetooth 5.0 added new PHY bit rates, namely, 125kbps, 500kbps and 2Mbps in addition to the original 1Mbps. But chip and product designers may or may not support any or all of these new modes, even while stating that the product is 5.0, 5.1 or even 6.0 compliant. The information may be available in their documentation or through qualification documents found on the SIG website, but this is far from obvious for a end user.
Deprecation and Withdrawal: There is a second drawback that you must be aware of—Deprecation and Withdrawal schedules. To limit the number of old versions around, the SIG publishes a deprecation date and a withdrawal date for each version [9]. For example, version 4.1 is already withdrawn. 4.2 was deprecated in February 2023 and will be withdrawn in 2028, and even 5.0 will be deprecated in February 2027, which is not so long in the future.
What do these dates mean? According to the Bluetooth SIG, when a specification is deprecated, it is no longer maintained by the SIG. More importantly, it is no longer possible to qualify a new product based on this version, if there are tests to do in the qualification phase. It is still possible to use a deprecated version, though, if the product includes an already qualified subsystem such as a Bluetooth module. When a specification is withdrawn, however, it is no longer possible to qualify any new products at all, but existing products can still be sold. So you must first keep an eye on the deprecation and withdrawal schedules—since they can change in the future ( which has already happened), and of course, select the newest versions for your products.
STAY TUNED
Here we are. Now I think I have presented all you need to know about Bluetooth, and this article will close the “No Blues with Bluetooth” series. Please don’t hesitate to drop me an email if you would be interested in additional information, since this could be the starting point for new articles—or write them yourself. Stay tuned and “Long live Bluetooth!”
REFERENCES
[1] Robert Lacoste. “No Blues with Bluetooth, Part 4: Let’s connect with BLE.” Circuit Cellar 409, August 2024
[2] Robert Lacoste. “No Blues with Bluetooth, Part 5: GATT explained.” Circuit Cellar 410, September 2024.
[3] – Bluetooth Core Specification v.5.4 https://www.bluetooth.com
[4] – securing/gattacker–A Node.js package for BLE (Bluetooth Low Energy) security assessment using Man in the Middle and other attacks. https://github.com/securing/gattacker
[5] — Exploiting Bluetooth Low Energy using Gattacker for IoT – Step-by-Step Guide:
https://blog.attify.com/hacking-bluetooth-low-energy
[6]- Bluetooth Smart lock interception and spoofing:
[7]- Ionut Arghire. “SweynTooth: Bluetooth Vulnerabilities Expose Many Devices to Attacks.”
Security Week, February 14, 2020
https://www.securityweek.com/sweyntooth-bluetooth-vulnerabilities-expose-many-devices-attacks
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • DECEMBER 2024 #413 – Get a PDF of the issue
Sponsor this Article
Robert Lacoste lives in France, between Paris and Versailles. He has more than 30 years of experience in RF systems, analog designs and high-speed electronics. Robert has won prizes in more than 15 international design contests. In 2003 he started a consulting company, ALCIOM, to share his passion for innovative mixed-signal designs. Robert is now an R&D consultant, mentor and trainer. Robert’s bimonthly Darker Side column has been published in Circuit Cellar since 2007. You can reach him at askrobert@lacoste.link.
