At the heart of every Bluetooth device is a Bluetooth stack. The stack runs the radio and communications according to the protocol stack. But how is this stack used? How can you use it to build products? What do you need?
We’re going to go over all the details to explain a Bluetooth stack and talk about Bluetooth Low Energy and Bluetooth Classic.
Anatomy of a Bluetooth Stack
A Bluetooth Stack is actually made up of two main parts, the Host and the Controller. These two parts communicate over a standard communications interface called HCI – Host Controller Interface – which, as its name indicates, interfaces the Host and the Controller parts of the Bluetooth Stack. A complete Bluetooth product has basically three different parts. Let’s go through them from the bottom up:
- Controller – The Bluetooth Controller is the lowest level Bluetooth component that controls the radio and performs the real-time packet management and processing. It communicates with the Bluetooth Host component using the HCI (Host Controller Interface). Controllers can be a Low Energy (BLE) Controller, a Classic Controller, or a Dual Mode controller which is both.
- Host – The Host is the top level Bluetooth Stack component that provides a consistent interface for controlling the Stack by sending commands, receiving responses and events. It implements various services and profiles. The host API is called by the Application. Bluetooth Hosts typically provide the functionality that the controller provides. A Bluetooth Classic Host interfaces with a Bluetooth Classic controller
- Application – This is the specific code for your product which interfaces with the Host or some intermediate layer, configures the stack (for example LE advertising information), and receives events
You may think “why isn’t the Bluetooth Stack just one software stack”? In many cases it can be treated as one, but there are a few good reasons for splitting it architecturally:
- The Controller is the real-time part of the system, responsible for keeping timing and controlling the radio, link and baseband controller, and physical layer. On the other hand, the Host is much less sensitive to precise timing requirements and the real time requirements are much simpler, with only some timers. The Controller acts in the order of microseconds and milliseconds, while the Host usually deals with seconds
- From the start it was understood that Bluetooth would run on a variety of platforms, both embedded and computers. Each of these have different capabilities, processing power and memory. By keeping the Host and Controller separate it allows devices to implement only the controller and leave the host to another device. A USB dongle can be the Controller while the computer could run the host.
- Product requirements are different among devices. Splitting the Host and Controller enables you to mix and match capabilities, and change controllers later.
- You don’t always need to upgrade the complete stack to take advantage of new features. Fixes and updates could be done to the Host, which is mostly software, instead of impacting the firmware / hardware of the controller. Because the Controller operates the radio, changes to its functionality are more likely to be limited to prevent breaking backwards compatibility, or may require significant hardware. The Host however can remain flexible
- Bluetooth is a transport, and it can carry many types of data. The Controller doesn’t need to change in order to support new data protocols. The low level can remain the same, but the type of data, the security and other parameters can be changed with software updates. Think of it like building new protocols on top of TCP/IP.
- Bluetooth Controllers contain a lot of “secret sauce” as far as algorithms and operations, and separating them allows vendors to differentiate them
The image above shows a few things:
The Host and Controller can be mixed and matched. Because HCI is standardized interface, it’s possible to use a Hosts with different Controllers. For example, you can use a Broadcom Bluetooth chipset in one design, then switch to a Qualcomm chipset in another design. The Bluetooth Host component can stay the same and your application doesn’t need to change.
You can also have the Host, Controller and App in the same chip. A Bluetooth chip can act as a complete Product (Application + Host + Controller), or it can act as a Network Processor (Host + Controller), or it can simply be a controller.
Let’s go over different examples of Bluetooth Stack configurations.
Single Chip BLE SoCs
BLE System On Chip devices are single chips capable in running in any of the three configuration. They can be self contained and run the full stack and application, or they can be used for to provide Network Processor or Controller only functionality.
A very popular example is Nordic’s nRF52, nRF53, and nRF54 line of BLE SoCs. They are usually used as a complete BLE SoC product containing the Application, Host, and Controller together. But the nRF52 and nRF54 can also be used as a Network processor or just a controller, with some other device running the Application or the Application and the Host.
You can see an example above. Many products already have a processor, like the STM32. Instead of a significant product redesign, you can just add a nRF52x device to the processor to act as a Network Processor. This means you don’t have to deal with the intricacies of the Bluetooth Stack. You can just call functions and communicate.
This approach has become very common in medical devices, where the safety critical processing happens on a dedicated processor and an nRF52840 is attached to provide connectivity.
TI CC2564x – Bluetooth Dual Mode Controller
The CC2564x is a popular Bluetooth Classic + Bluetooth LE Controller. In order to use it, you need an external processor running a Host stack. TI provides out of the box support for MSP430, STM32, and Linux capable processors. The embedded stack was originally Ethermind from MindTree, but around 2012 was switched to Bluetopia from StoneStreet One. For Linux processors, BlueZ is used or the Bluetopia can be used as well.
Infineon AIROC Bluetooth LE & Bluetooth
Broadcom was a big name in connectivity. A few years ago they sold their IoT connectivity portfolio to Cypress Semiconductor. Cypress itself was acquired by Infineon, resulting in Infineon having a great lineup of BLE + Bluetooth devices. The CYW20819 is a Dual Mode single chip solution, which means you can develop a complete application and use the Bluetooth stack for both BLE and Bluetooth Classic applications.
These chips can also have an HCI UART interface which allows them to
Bluetooth Host Controller Interface (HCI)
HCI is both a physical interface and a simple protocol that allows Processors running a Host stack and a Controller to communicate. The Physical layer can run on a variety of physical transports:
- HCI UART Transport Layer – Standard UART with Flow Control (RTC/CTS), commonly called H4. This is one of the most common HCI transport mechanism for talking to external chips
- USB Transport Layer – Runs HCI over UART with specific Endpoints for control, data and streaming
- Secure Digital (SD) Transport
- Three-wire UART – Commonly called H3 – also uses UART but encapsulates packets with a header and frames them using a SLIP protocol. Usually used for an unreliable packet stream
Although not specifically defined, when the Host and Controller are implemented in the same chip, they use what is essentially a Virtual HCI – HCI data is passed between the Host and Controller using functions or some other internal message mechanism.
Typically, the HCI layer that is in the Host is called the Upper HCI, while the BR/EDR/LE Controller HCI is the Lower HCI.
Bluetooth Stacks
Nordic Semiconductor Bluetooth Stacks
Nordic’s longtime Bluetooth Stack is called the SoftDevice. It’s a Complete Controller + Host with a custom API that enables you to build complete products.
The SoftDevice is currently in maintenance mode, and while you can use it, you should consider developing new products using Zephyr instead.
A few years ago Nordic switched to support Zephyr, an RTOS with its own Bluetooth Stack. When using Zephyr to develop products, you have two Bluetooth Stack options:
- Use the Zephyr Host and the Nordic BLE Controller which is closed source.
- Use the Zephyr Host and Controller which are open source
Because the Nordic Controller is maintained by Nordic and receives significant testing and updated features, it’s the recommended way to go. But there are plenty of cases where the Zephyr Bluetooth Stack can be used.
BlueZ Bluetooth Stack
BlueZ has a long history as a stack and is the main Bluetooth Stack for Linux, mainly because it’s an Open Source project using the GNU General Public License (GPL).
If you’re running a Linux on a processor, whether it’s embedded Linux or on a desktop computer, then BlueZ is the stack. It was originally developed by Qualcomm, which still provides some support, though other companies such as Intel provide developers to the project to keep updating it.
The BlueZ Bluetooth Stack is Host only. The Controller is provided by a USB Dongle or a PCIe card, or can be integrated to a motherboard.
BlueZ was the original stack used by Android, before being replaced by BlueDroid due to licensing issues with GPL.
BlueDroid
BlueDroid is Broadcom’s Bluetooth Stack, which was heavily used by Android from Android 4.2 until Android 13. The switch to BlueDroid from BlueZ was terrible, with missing functionality and stability issues which weren’t resolve until Android 5 came around. If you developed with Android 4.2, you remember the issues which made Bluetooth LE apps almost unusable.
Aside from Android, BlueDroid is the default Host stack in Espressif’s ESP32 devices, especially those that also support Bluetooth Classic. The stack has been modified by Espressif to simplify it and fix issues, since the original BlueDroid stack was quite complicated.
Google Gabeldorsche Android Stack
Google finally realized that the BlueDroid stack was difficult to work with and decided to completely revamp Bluetooth for Android and write their own custom Host Stack that splits things properly into multiple threads, even apparently using Rust to bring memory protection.
BlueKitchen
Mattias Ringwald is a Bluetooth Stack developer that has developed BlueKitchen, a Host Bluetooth stack supporting both Bluetooth Classic and BLE. For a complete Bluetooth solution, you can use any controller and any . The Stack is dual licensed – open source for personal projects and with a royalty for commercial projects.
It has been used by quite a few projects that needed a stable stack including those using the CC2564 chipset and many others. It has a wide range of supported platforms.
Zephyr
The Zephyr project is a complete RTOS that includes a Bluetooth Stack. The stack includes a Host capable of Bluetooth Classic + BLE, and also a BLE Only Controller.
Nordic Semiconductor has thrown its full support behind Zephyr, committing resources for several years, helping make Zephyr successful. When building a Bluetooth product, developers can choose to use Nordic’s BLE Controller or Zephyr’s controller.
Because it’s completely open source, it’s been adapted to run on a variety of platforms including EFR32, STM32WB.
RivieraWaves BLE Stack
NimBLE Apache Mynewt
NimBLE is a fully open-source Bluetooth Low Energy (BLE) stack licensed under Apache 2.0 and developed by the Apache Mynewt community. It is designed with efficiency, modularity, and low memory usage in mind, making it ideal for devices with constrained RAM and flash storage—typical of many IoT and embedded applications.
Though it originated as part of the Apache Mynewt RTOS, NimBLE is platform-agnostic and has been successfully ported to other real-time operating systems and SDKs such as Zephyr OS, ESP-IDF (used by Espressif chips like the ESP32), and FreeRTOS.
Qualifying a Product with Bluetooth Stacks
At the end of the day, developers are looking to get a product out to the market, which means Qualifying it to earn the Bluetooth mark. While the topic of qualification can be a bit complicated, the Bluetooth Stack plays a critical role in certifying a Bluetooth product.
As a product developer, it’s unlikely you’ve developed your own Bluetooth stack. We say that because the complexity in doing means it makes little sense for most companies to do it. Instead, you’re using a Bluetooth stack. Most likely it’s the one the chipset vendor of the device you chose. Why? Because even integrating a Bluetooth stack can be a significant effort, and most vendors already offer stacks.
So how do you qualify a Bluetooth product if you’re using a vendor’s stack? That vendor has already tested and certified their stack. Before the most recent changes, the stack would get a QDID. This ID would tell the Bluetooth SIG that you’re using that specific stack. Your qualification would essentially reference the QDID of the stack, because you’re using it as is.
If you had built your own stack or changes were made, you would need to qualify the stack as a component to be used in the overall design. Because this process is expensive and time consuming, changes to a stack typically are done only when there’s major changes or enough changes.
Changes to the application don’t typically need to be re-qualified.
References
https://www.espressif.com/sites/default/files/documentation/esp32_bluetooth_architecture_en.pdf
https://www.xda-developers.com/android-13-gabeldorsche-bluetooth-stack
