The Zephyr™ RTOS has included support for Bluetooth™ Low Energy (BLE) connectivity since its inception. Zephyr OS 1.9 now includes a qualification-ready controller subsystem implementation to allow MCUs with a BLE radio to be connected to a processor running a BLE Host stack. Taking a closer look at the different layers that make up a full BLE protocol stack helps explain this capability.
There are 3 main layers that together constitute a full BLE protocol stack:
- BLE Host: This layer sits right below the application, and it is comprised of the multiple (non real-time) network and transport protocols enabling applications to communicate with peer devices in a standard and interoperable way
- BLE Controller: The BLE Controller implements the Link Layer (LL), the low-level, real-time protocol which provides, in conjunction with the BLE Radio Hardware, standard interoperable over the air communication. The LL schedules packet reception and transmission, guarantees the delivery of data, and handles all the LL control procedures
- BLE Radio Hardware: The required analog and digital baseband functional blocks that permit the Link Layer firmware to send and receive in the 2.4GHz band of the spectrum
The Bluetooth Specification describes the format in which a BLE Host must communicate with a BLE Controller. This is called the Host Controller Interface (HCI) protocol. HCI can be implemented over a range of different physical transports like UART, SPI or USB. This protocol defines the commands that a Host can send to a Controller and the events that it can expect in return, and also the format for user and protocol data that needs to go over the air. The HCI ensures that different BLE Host and Controller implementations can communicate in a standard way making it possible to combine BLE Hosts and Controllers from different vendors.
The three separate layers of the protocol and the standardized interfaces make it possible to implement the Host and Controller on different platforms. The two following typical configurations are commonly used:
- Single-chip configuration: In this configuration, a single microcontroller contains all three layers and the application itself. This can also be called a system-on-chip (SoC) implementation. In this case the BLE Host and the BLE Controller communicate directly through function calls and queues in RAM. The Bluetooth specification does not specify how HCI is implemented in this single-chip configuration and so how HCI commands, events and data flows between the two can be implementation-specific. The Zephyr OS supports this configuration on Nordic Semiconductor ICs, for those applications and designs that require a small footprint and the lowest possible power consumption, since everything runs on a single IC
- Dual-chip configuration: Using two separate ICs, one running the Application and the Host, and a second one with the Controller and the Radio Hardware. This is sometimes also called a connectivity-chip configuration. This configuration allows for a wider variety of combinations of Hosts when using the Zephyr OS as a Controller. Since HCI ensures interoperability among Host and Controller implementations, including of course Zephyr’s very own BLE Host and Controller, users of the Zephyr Controller can choose to use whatever Host running on any platform they prefer. For example, the host can be the Linux BLE Host stack (BlueZ) running on any processor capable of supporting Linux. The Host processor may also run Zephyr and the Zephyr OS BLE Host.
The Zephyr software stack as an RTOS is highly configurable, and in particular, the BLE subsystem can be configured in multiple ways during the build process to include only the features and layers that are required to reduce RAM and ROM footprint as well as power consumption. Here’s a short list of the different BLE-enabled builds that can be produced from the Zephyr project codebase:
- Combined build: This includes the Application, the Host and the Controller, and it is used exclusively for single-chip (SoC) configurations
- Host build: A Zephyr OS Host build will contain the Application and the BLE Host, along with an HCI driver (UART or SPI) to interface with an external Controller chip
- Controller build: When built as a BLE Controller, Zephyr project contains the Link Layer and a special application (hci_uart or hci_spi) that acts as a bridge between the UART and SPI peripherals and the Controller subsystem, listening for HCI commands, sending application data and responding with events and received data
The picture below shows the SoC or single-chip configuration when using a Zephyr OS combined build (a build that includes both a BLE Host and a Controller in the same image):
This configuration is only possible today on Nordic Semiconductor ICs, since they are the only IC family that is fully supported by Zephyr Project’s built-in BLE Controller. In the future however, the project intends to extend this support for many other SoC families, provided that their BLE Radio Hardware interfaces are publicly documented and therefore suitable for an open source implementation.
When using connectivity or dual-chip configurations, several Host and Controller combinations are possible, some of which are depicted below:
When using a Zephyr OS Host (left side of image), two instances of Zephyr OS must be built with different configurations, yielding two separate images that must be programmed into each of the chips respectively. The Host build image contains the application, the BLE Host and the selected HCI driver (UART or SPI), while the Controller build runs either the hci_uart or the hci_spi app to provide an interface to the BLE Controller.
This configuration is not limited to using a Zephyr OS Host, as the right side of the image shows. One can indeed take one of the many existing GNU/Linux distributions, most of which include Linux’s own BLE Host (BlueZ), to connect it via UART (SPI is not supported by BlueZ) to one or more instances of the Zephyr OS Controller build. BlueZ as a Host supports multiple Controllers simultaneously for applications that require more than one BLE radio operating at the same time but sharing the same Host stack.
In order to use a Zephyr OS Controller build in a commercial product, this needs to go through the Bluetooth Special Interest Group’s (SIG) qualification process. The Controller subsystem must adhere to the Bluetooth Specification and conform to the expected behavior in Bluetooth Low Energy devices. The qualification process is mandatory for all Bluetooth products, and consists of a series of tests defined by the SIG that are run against the particular implementation. Test evidence is then provided to the Bluetooth SIG to prove that the device is indeed compliant before a qualification is granted.
As part of this blog post, Nordic Semiconductor is happy to announce that Zephyr OS 1.9 passes all the required HCI and Link Layer conformance tests in order to qualify a design based on an IC of the nRF5x family as a Controller Subsystem. Pre-certification of the Zephyr OS Controller Subsystem allows end-product makers to rapidly develop BLE end-user product with confidence that their solution can be certified. Nordic will make available the qualification QDIDs (Qualified Design IDs) for the combination of the Zephyr OS 1.9 Controller build with our nRF5x series of ICs, which can then be used when qualifying end-products to fast-track product qualification, i.e. Link Layer and HCI tests do not need to be repeated by end-product makers.
The Zephyr OS Controller build, like the rest of the RTOS, is configurable. However, qualification listings include references to implemented features, which means that the features qualified for the granted QDID need to be incorporated into the Controller build. The following features have been incorporated and certified for the Controller build:
- All Bluetooth 5.0 features except Advertising Extensions on nRF52x ICs
- All Bluetooth 5.0 features except Advertising Extensions, Data Length Extension, 2Mbps and coded PHYs and Controller-based Privacy on nRF51x ICs
Note that Nordic’s qualification will only cover the BLE Controller, which means that whichever Host is used for a particular design will have to be qualified independently.
In order to test the BLE Controller yourself and verify if it suits the needs of your future product, feel free to grab the 1.9 release and test it out!
