The Thousand-Foot Picture
This month Robert begins by describing Bluetooth protocol stacks, a quick overview of Bluetooth Classic, then he explains what BLE is and what its protocol stack looks like. Finishing with a presentation of dual-mode devices.
n Part 1 of this article series (“No Blues with Bluetooth: Part 1,” Circuit Cellar 405, April 2024), I presented a quick introduction to Bluetooth—its history and inventors, the importance of the Bluetooth Special Interest Group (SIG), which specifies and promotes the protocol, its huge market presence, its intellectual property management and costs, and so forth. I also explained that each new Bluetooth version (from 1.0 in 1999 to 5.4 and beyond) provides two kinds of improvements: bug corrections and new features. Remember that all new features are always optional; manufacturers can decide to support them or not. In particular, Bluetooth 4.0 introduced a life-changing optional feature: Bluetooth Low Energy (BLE). Since then, there are two types of Bluetooth: The older one (which I will call “Bluetooth Classic” to avoid any confusion), which is still active, in particular for audio, and BLE. Both are Bluetooth, but they use very different protocols.
This month, I will talk about Bluetooth protocol stacks. I’ll provide you with a quick overview of Bluetooth Classic, as several concepts are still applicable to BLE. Then I’ll explain what BLE is and what its protocol stack looks like. I will finish with a presentation of dual-mode devices. This will be a good basis for the next articles, in which I will go far deeper into BLE.
Bluetooth classic
Once upon a time, in 1999, Bluetooth appeared. In this first type, Bluetooth Classic, the basic topology of a Bluetooth network is called a piconet (Figure 1). A piconet includes a controller (usually a smartphone, but it could be anything else), and a set of remote devices (headset, keyboard, printer, you name it). A controller can exchange data with a maximum of seven remotes. More precisely, up to 255 remotes can be known by the controller, but only seven can be actively connected at a given time. The other ones are in park mode and can be put back into service only by the controller.
The piconet is the basic Bluetooth Classic structure, with a controller and up to seven connected remotes.
In terms of radio frequencies, I am sure you know that Bluetooth uses the ubiquitous 2.4GHz frequency band, also used by other protocols like Wi-Fi, Zigbee, and Matter, to name a few. This frequency band is usable worldwide, and spreads from 2400MHz to 2483.5MHz. In this band, Bluetooth Classic defines 79 channels, each 1MHz wide. The first is centered at 2402MHz, the last at 2480MHz (Figure 2). This allows for guard bands at the two extremes to reduce out-of-the-band emissions.
Bluetooth Classic uses 79 channels in the 2.4GHz band, and hops channel to channel 1600 times per second.
How does Bluetooth Classic use these 79 frequency channels? By switching frequently from channel to channel. More exactly, Bluetooth Classic stays on a given channel for only 625µs, then jumps to another channel using a predefined channel-hopping sequence. Yes, Bluetooth Classic hops from channel to channel no less than 1600 times per second (1s/625µs)! This predefined hopping sequence is specific to each controller, and known by its remotes. That way, even if several piconets are running in the same area, the probability of collision stays low. In case of collision between two piconets, only one time slot will be jeopardized. Each piconet will then jump on a different channel.
The controller manages communication with its connected remotes via a polling mechanism. The controller sends a frame to its first remote on a given channel, and expects an answer from this remote 625µs later on the next channel of the hopping sequence. It then sends a frame to the second remote, and so on. Frames can contain useful data or be empty if nodes have nothing to send. This process keeps the controller and remotes synchronized. This is a simplified description, but you get the idea. Lastly, the throughput of the link is 2Mbs, or optionally, 3MBps (Enhanced Data Rate, EDR).
Adaptive?
I don’t plan to spend too much time talking about Bluetooth Classic as my intent is to focus on BLE, but there is an important feature that you must be aware of. As explained, the Bluetooth frequency band is the same as Wi-Fi. Therefore, there is a high risk of interference between the two. Early in Bluetooth’s development, specifically in Bluetooth 1.2, a feature was introduced to reduce these risks: adaptive frequency hopping (AFH). How does AFH work?
As explained, Bluetooth Classic packets are initially transmitted on 79 channels, with a hop every 625µs. Suppose that there is some Wi-Fi traffic in the area. Wi-Fi channels are at least 20MHz wide, so this will introduce errors on several Bluetooth channels (Figure 3). The piconet controller will then detect that some channels are more error-prone than others and will generate a new frequency-hopping sequence that will avoid these channels. This is AFH. The process is repeated frequently:
Adaptive Frequency Hopping is a feature that allows users to avoid corrupted channels, through a change in the frequency hopping sequence.
It is typical to have several frequency sequence changes in a single minute as the radio environment is never stable. AFH is a nice example of the complexity of Bluetooth. Imagine what’s needed to specify and code such a feature. First, you must detect which channels could be used. Then, you must inform all remotes that there will soon be a change in the hopping sequence. You must double-check that all remotes got this information before the change, as otherwise remotes will be lost. And all this must be done concurrently with the actual data traffic. Not so small a task, is it?
Protocol stacks
In a minute, I’ll show you the Bluetooth Classic and BLE protocol stacks. But first, maybe it would be useful to remind you what a so-called protocol stack is, and why this notion was introduced. Well, it comes from the early days of network communications—probably from the first X25 packet-switched telecommunication networks in the ‘70s.
It quickly became clear that the specification, development, and validation of such a protocol is a complex task. Bits must be transferred, then packets, which may need to be repeated. Packets are part of communication flows, which may be multiplexed and routed. Communication flows may transport different kinds of information using different encapsulations, and so on.
In order to reduce this complexity, it was far easier to split the protocol into layers, like a cake (Figure 4). The idea is that each layer manages only a specific abstraction aspect of the protocol and is linked with other layers through well-defined interfaces. That way, each layer can be specified, coded, and tested independently from the others. Moreover a layer can be exchanged with another one painlessly, as long as the interfaces stay the same.
An illustration of the protocol stack concept, here with the example of TCP/IP.
To better understand this concept, consider, for example, a protocol we all use daily: the Internet. Assume that your PC is connected through an Ethernet link (a physical layer). As part of Windows, a device driver manages this physical layer and is interfaced with a standard packet-level protocol named IP (which is also part of Windows). On top of IP, a choice of higher-level protocols manage either connection-oriented links (TCP) or raw packet transmission (UDP). Then, on top of TCP or UDP, a standardized interface (sockets) allows the use of any application-level protocol like HTTP for web access, SMTP for mail, and so forth.
Now think about that. If you disconnect your PC from the Ethernet link, it will probably automatically switch to a nearby Wi-Fi network. I’m sure you know that such a change is transparent from an application layer standpoint: Your web connection isn’t disturbed except from the performance standpoint, and even the TCP/IP layers inside Windows don’t know that the physical layer has changed. As the interfaces between layers are well specified, the low Ethernet layers were simply replaced by their Wi-Fi counterparts transparently.
Similarly, you know that you can run web and mail applications simultaneously, right? In that example, HTTP and SMTP frames are sent through TCP/IP and through the physical layer. This is fully transparent for the network and physical layers, and these layers don’t even have to know what application layers are in use.
This is the magic of protocol stacks: Each layer is independent from the others. Please keep this concept in mind as I move on to the Bluetooth stack.
Bluetooth protocol stack
Now, it is time to have a look at the Bluetooth Classic protocol stack (Figure 5). Starting from the bottom, the PHY layer manages the actual modulation, whereas the baseband and link manager protocol (LMP) layers take care of all RF link management tasks: addressing, packet frame format, channel hopping, AFH, synchronization, network discovery, encryption, and so on. The link manager layer is then connected to the Logical Link Control Adaptation Protocol layer (L2CAP), through an interface named Host Control Interface (HCI).
Here is the Bluetooth Classic protocol stack.
I will talk about HCI in a minute, but let’s stay on L2CAP for the moment. This L2CAP layer has two important tasks. First, it manages segmentation. This means it can receive arbitrarily large messages from the upper layers and split them into small chunks compatible with the low layers. On the receive side, it checks that all chunks have been received and reassembles them in good order. L2CAP also takes care of multiplexing, meaning that several data flows coming from higher layers can be multiplexed on the same radio link; packets from different application protocols are merged on the same radio link.
On top of L2CAP, there are the actual Bluetooth Classic application layers. As its name suggests, Service Discovery Protocal (SDP) is used to discover which services are supported by a given Bluetooth device. RFCOMM is one of the most used Bluetooth Classic application protocols, as it provides a kind of transparent UART link between the controller and a remote. Last, Human Interface Device (HID) is dedicated to keyboards, mouses, and similar devices; PAN provides a network emulation protocol; and AVP supports stereo audio streaming.
If you look again at Figure 5, you will see that there is a strange “SCO audio” on the left part of the diagram, short-circuiting all LMP, L2CAP, and application layers. This SCO audio is part of history: When the first Bluetooth chips appeared, microcontrollers were 8-bit 8051s running at 1MHz or so. Such processors were not able to manage digital audio in software. Therefore, the full Bluetooth stack was only used to establish the link, and then a fast channel (SCO audio) was switched on to send or receive digital audio packets directly from the baseband, without any software processing. These packets could then be passed through a DAC and sent to the earing set. Even if 32-bit processors no longer have such limitations, SCO audio is still there due to compatibility concerns. You use it when you switch on your Bluetooth hands-free kit or earphone to answer a call.
Finally, on top of the application layers, there are so-called Bluetooth application profiles (in green in Figure 5). Application profiles are basically sets of instructions for using a given protocol stack in a certain way. Let’s take an example: the Basic Imaging Profile (BIP), which allows the sending of images between devices. BIP states that the RFCOMM protocol must be used to transfer the flow, and specifies how to encode the image, how to resize it if needed, how to send it through the RFCOMM virtual UART, and so forth. I will not go through the long list of Bluetooth Classic profiles, but there are tens of them [1].
Let me add a word on two other common profiles—the Headset Profile (HSP) and the Advanced Audio Distribution Profile (A2DP). HSP uses SCO audio and is used for… headsets. It provides a bidirectional, full duplex, monophonic audio channel, but with a phone line quality. A2DP provides a high-quality stereophonic audio link, but which is monodirectional only. Think about your earbuds. Which Bluetooth profiles do they use? Well, it depends. When you are listening to music, this is probably A2DP. But when you are receiving a call, this switches to HSP!
An important point to note: If you are interested, all detailed Bluetooth specifications are available free of charge from the Bluetooth SIG website. So don’t hesitate to download and read some of them—it’s a rewarding experience. For example, you will find A2DP or HSP specifications easily [2]. The Bluetooth core specification is also available for download from the same site, but this is a more serious reading—about 3,100 pages.
What is HCI?
Now, back to the Host Control Interface (HCI) I mentioned. HCI is the interface between the low layers and the first high layer, L2CAP. All interfaces between layers are standardized, but this HCI interface is, well, more important than the others. In a nutshell, HCI is usually the interface between hardware and software. This means that layers below HCI are nearly always managed by a piece of silicon (a Bluetooth chipset), whereas layers above HCI are usually managed by firmware or software running on a processor. For example, imagine that you buy a USB Bluetooth dongle and connect it to a Rapsberry Pi (Figure 6). The layers under HCI are running in the dongle, and the layers above are part of the Linux BlueZ stack running on the RPi. And HCI is the protocol running through the USB connection between the two, through another UART emulation service (USB CDC class). And as HCI is standardized, all Bluetooth dongles are compatible.
Host Control Interface (HCI) can be understood as the interface between hardware and software.
By the way, there are HCI analyzers around, so it is actually possible to spy an HCI connection and discover all exchanges between lower and higher Bluetooth stack layers. The open-source Wireshark protocol-analyzing software could be used for that purpose. And if you have an Android phone, this is indeed easy: Android allows you to dump all HCI flow to a file on your SD card, and you can then transfer this file to your PC and analyze it with Wireshark. The process is not obvious, but well documented. See Circuit Cellar’s Article Materials and Resources webpage for an example [3].
What is Bluetooth low energy?
Now, on to BLE. There are plenty of good books on BLE (see [4] and [5]), but nonetheless I’ll provide a short introduction, here. As shown in Figure 7, BLE was designed to link plenty of non-audio devices to a smartphone. The idea, proposed by Nokia and adopted by the SIG, was to develop a protocol as close as possible to Bluetooth Classic (in order to support it easily without any extra cost on the smartphone side). However, BLE avoids several limitations of Bluetooth Classic. First, there is no longer a limit on the number of connected devices; this is virtually limited only by the RAM size and stack implementation. Second, BLE allows significantly lower-power devices than Bluetooth Classic. In particular, BLE allows devices to stay in deep sleep for long periods while still being connected to their counterpart. The latency required to establish a connection is also far shorter than with Bluetooth Classic. As I will explain later, this allows the design of BLE devices to run for years on a small Lithium coin battery. Last, BLE was intended to be far simpler than Bluetooth Classic, in order to reduce memory sizes and processor costs. The protocol stack is indeed greatly simplified.
Bluetooth Low Energy (BLE) is designed to be used simultaneously with Bluetooth Classic, but targets different applications.
As nothing comes for free, there is a downside: BLE throughput was not targeted to be as high as Bluetooth Classic—more precisely, 1MBps versus 2MBps or 3MBps. This was not an issue as the applications of BLE were not audio. 1MBps is large enough to transfer small data packets occasionally.
A caution here: As I will explain in subsequent installments of this article, BLE has changed significantly since its introduction in Bluetooth 4.0. In the later versions (5.0 and above), BLE has become as powerful as Bluetooth Classic and probably as complex—maybe even more complex. Anyway, simplicity and lower performance were the initial aims for BLE.
BLE protocol stack
Maybe it’s finally time to examine the BLE protocol stack, and to compare it with Bluetooth Classic. As illustrated in Figure 8, there are some similarities, but both stacks are quite different. BLE also has, of course, PHY and link layers, but they are different from Bluetooth Classic. I will cover these in detail in my next article, so you just have to wait a little longer before you know everything about them. These BLE low layers are interfaced to the higher layers through HCI, exactly the same HCI as the one I discussed above.
And here is the BLE protocol stack. Compare it with the Bluetooth Classic examble (Figure 5).
On top of HCI, BLE also uses L2CAP. It manages segmentation and multiplexing, like it does for Bluetooth Classic. But the resemblance stops there. On top of L2CAP, BLE proposes only one application protocol, named the Attribute Protocol (ATT), and only one profile, the Generic Attribute Profile (GATT). This looks far simpler, but as I will explain, that’s only half true. Having only one profile for a large set of different kinds of devices means that this profile must be super flexible. If you suspect that this is not so simple, you are right.
Finally, I didn’t talk about the last two entities on the BLE protocol stack. As you may have guessed, the Security Manager (SM) manages the security of the link, even if it is in a very different way than Bluetooth Classic. I will probably have to devote a full article to this topic too… Last, the Generic Access Profile (GAP) allows one to discover devices and their services.
How about dual-mode devices?
From the beginning, BLE was developed to allow fluent interworking with Bluetooth Classic. More precisely, the intent was to make life easy for phone manufacturers: A dual-mode Bluetooth Classic/BLE chip should cost no more than a standard Bluetooth chip. Moreover, a phone must be able to be connected simultaneously with Bluetooth Classic devices (headsets and such) and with BLE devices.
How this could be achieved? Look at Figure 9 for the answer. The key is that both stacks use the same HCI protocol and the same L2CAP layer. Below HCI, a dual-mode chip needs to support the two physical layers and baseband layers. They are not the same between BLE and Bluetooth Classic, but they do have enough similarities to share a large part of the hardware. In particular, it is quite easy to design the RF sections for a dual-mode compatibility, as I will explain in the next article.
A dual-mode Bluetooth device is made possible thanks to the common HCI interface and L2CAP layers.
As the HCI interface is the same, this dual-mode Bluetooth chip can be interfaced to a host processor through a single link. This link, for example, USB, simply supports different HCI command sets for BLE and Bluetooth Classic.
Look again at Figure 9. L2CAP is common for both stacks. Indeed, L2CAP already provided multiplexing service between different protocols for Bluetooth Classic. Well, in a dual-mode system, L2CAP simply multiplexes both Bluetooth Classic and BLE protocols! Frames coming from Bluetooth Classic devices are forwarded to the relevant Bluetooth Classic protocol layer, whereas frames coming from BLE devices are forwarded to ATT or SM layers.
Easy isn’t it? That’s why you can buy dual-mode Bluetooth modules or dual-mode Bluetooth dongles.
Stay tuned!
Here we are. I have, of course, only scratched the surface of this subject, but I hope you get the idea. Bluetooth is a quite complex protocol, but could be more easily understood through the protocol stack diagrams. I intend to stop talking about Bluetooth Classic in future articles, as BLE is the future. In my next piece, I will dig far deeper into BLE, starting with a presentation of its physical layer and discovery mechanism: beacons and advertising. So, stay connected!
Editor’s Note: Part 1 of this series, “No Blues with Bluetooth,” appeared in issue #405 (April 2024). Going forward, the series will be appearing monthly, with Part 3 of the series appearing in issue #408 (July 2024).
REFERENCES
[1] Wikipedia—List of Bluetooth profiles: https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles
[2] Bluetooth specifications: https://www.bluetooth.com/specifications/specs/
[3] “A Comprehensive Guide to Analyzing Bluetooth Low Energy Snoop Dumps on Android via Wireshark”, Shubham Kumar Gupta, Stackademic, Shubham Kumar Gupta
https://blog.stackademic.com/a-comprehensive-guide-to-analyzing-bluetooth-low-energy-snoop-dumps-on-android-via-wiresharkhttps://blog.stackademic.com/a-comprehensive-guide-to-analyzing-bluetooth-low-energy-snoop-dumps-on-android-via-wireshark
[4] “Getting Started with Bluetooth Low Energy”, Kevin Townsend, O’Reilly Media, ISBN 978-1491949511
[5] “Bluetooth Low Energy, The Developer’s Handbook”, Robin Heydon, Pearson, ISBN 978-0132888363
RESOURCES
Bluetooth | www.bluetooth.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JUNE 2024 #407 – Get a PDF of the issue
— ADVERTISMENT—
—Advertise Here—
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.
