Bluetooth Architecture from Scratch
The Bluetooth architecture determines which functions should be operational in an implementation and how they should be organised
Bluetooth is composed of multiple technologies, protocols, and elements. Their relationship and usage are complex, presenting a barrier to entry when starting to study this technology. This article aims to serve as an introduction to the architecture of a Bluetooth communication device and clarify the role each of its components plays.
The architecture described in the extensive Bluetooth standard dictates which functions must exist in an implementation and how they should be organized, so knowing it greatly facilitates understanding the operation of a device, a codebase, or Bluetooth as a technology in general.
However, as it is structured, the standard is not the best study documentation for easily and simply starting in Bluetooth technology, so introductory documentation with a didactic intention on this topic is necessary.
This article will focus on explaining three fundamental points:
- The separation of the architecture into two main components: host and controller.
- The protocol stack.
- The Bluetooth architecture in detail and where each layer of the protocol stack is implemented.
But first, it is necessary to talk about BR/EDR and LE.
Bluetooth Versions: BR/EDR and LE
Before delving into the architectural components of Bluetooth, it is advisable to address a differentiation that runs through the entire architecture since two versions of Bluetooth are available:
- BR/EDR: Also called Bluetooth Classic as it was the first to appear.
- LE: Bluetooth Low Energy born with the intention of being incorporated into low-energy consumption devices.
Bluetooth BR (Basic Rate) is the first version of Bluetooth and was later extended with EDR (Extended Data Rate), which allows for a higher maximum data transmission rate.
Maximum transfer rate in Bluetooth Basic Rate (BR):
- 1 Mbps (megabit per second)
Maximum transfer rates in Bluetooth Extended Data Rate (EDR):
- 2 Mbps with EDR 2
- 3 Mbps with EDR 3
BR and EDR are fully compatible, so they are considered a single system and referred to as BR/EDR.
Bluetooth LE (Low Energy) was later developed as a low-power alternative for simpler and cheaper devices, initially with a lower data transmission rate than BR/EDR, although in the latest versions of the protocol, they have increased to almost match those of BR/EDR
Maximum transfer rates in Bluetooth Low Energy (BLE):
- Bluetooth 4.0 and 4.1: 1 Mbps
- Bluetooth 4.2: 1 Mbps (improvement in data efficiency and capacity for larger packets)
- Bluetooth 5.0 and 5.1: 2 Mbps (doubled compared to previous versions)
- Bluetooth 5.2: 2 Mbps (improvements in terms of data capacity, efficiency, and range)
- Bluetooth 5.3 and 5.4: 2 Mbps (improvements that increase efficiency, security, and functionality)
Although both function similarly when discovering devices and establishing connections, the mechanisms they work with are very different and incompatible with each other, so they can be seen as different technologies with similar names.
Separation between Host and Controller
A Bluetooth device is composed of two types of elements: a host and one or more controllers.
- Host: Serves as an interface for applications and the operating system and implements the protocols of the higher layers. It communicates with the OS applications to perform tasks with Bluetooth.
- Controller: Implements the basic functions and protocols of the stack and supports the different Bluetooth technologies: BR/EDR and LE. A controller can support BR/EDR, LE, or both combined.
The host can be seen as the computer running Windows that receives processed Bluetooth packets and communicates with user applications, while the controller would be the Bluetooth USB dongle that runs firmware and performs low-level tasks such as capturing packets, announcing the device, channel synchronization, etc.Host and controller communicate with each other using the HCI (Host Controller Interface) packet transmission protocol, allowing the host to send actions to a controller and receive events in response, controlling the state of communications at a high level.
A controller can support BR/EDR, LE, or a combination of both, while the host is the same for both technologies. This is because the fundamental differences are found in the lower-level protocols of the stack (physical and media access protocols), each implementing its own set of commands and packets, while the higher-layer protocols implemented in the host are not exclusive to BR/EDR or LE and are common to both. Thus, a host can speak to any controller in the same language; the controller must implement the support for BR/EDR and BLE and is agnostic to the host.
An interesting consequence of the separation between host and controller is that the host does not have information on everything that happens in the controller, only what the controller informs it of through HCI packets. This is especially relevant because, in complex systems like PCs and smartphones, the host is generally implemented as part of the operating system, while the controller is in the firmware of a separate hardware peripheral over which the OS does not have direct control.
That is, a user interacting only with the host will generally not have control or knowledge of what happens in the layers implemented in the controller since it is an isolated element, usually with proprietary firmware from the manufacturer.
Bluetooth Protocol Stack
The standard defines a general Bluetooth stack divided into layers and sublayers. Each layer implements a set of related functions necessary for the layer immediately above and uses the functions implemented by the directly lower layer. Thus, the lower layers implement low-level functions like hardware interaction, while the higher layers implement functions closer to the user application, such as managing device discovery, making connections, etc.
A Bluetooth data packet is received by the lower layers, which interpret the content and send the result to the upper layers until it reaches the user layers.
The physical layer in a Bluetooth connection is responsible for the actual data transmission through the communication medium, i.e., the air. This layer defines aspects related to signal modulation, operating frequencies, and radiofrequency spectrum management. Its main function is to establish and maintain the physical link between Bluetooth devices, allowing the transfer of data bits through radio waves. Simply put, it is the foundation that allows devices to “hear” and “talk” to each other through wireless signals.
For example, it determines the frequencies at which it emits, the duration of messages, and synchronization in message transmission to avoid two devices transmitting simultaneously.
This layer divides its functions into three sublayers:
- Physical Transport: Handles data packaging and transmission via radio waves.
- Physical Channel: Defines frequency and synchronization parameters for packet transmission. There are different types of physical channels, each with different parameters.
- Physical Link: A communication session established between devices using a specific physical channel.
Logical Bluetooth Layer
The logical layer in a Bluetooth connection manages how data is organized and transmitted between devices. This layer handles functions such as link multiplexing, flow control, and error handling. Essentially, the logical layer ensures that data is sent and received in an orderly and efficient manner, allowing reliable and coordinated communication between Bluetooth devices.
The logical layer ensures communication stability and reliability to the upper layers (L2CAP) and controls aspects such as data flow type (synchronous or asynchronous), packet numbering, acknowledgment messages (ACK), or retransmission of lost packets. It creates “logical links,” which are communication sessions that guarantee specific communication conditions between devices. There are different types of logical links that provide different communication requirements.
An example of the functions of the logical layer is the ACL (Asynchronous Connection-oriented Link), used in both BR/EDR and LE, and it provides communication with specific characteristics:
- Point-to-point communication: Only two devices communicate with each other, not in broadcast.
- Reliable communication: The receipt of packets is guaranteed through mechanisms such as acknowledgment and retransmission of lost packets.
- Bidirectional communication: Both ends of the communication can send and receive data.
- Connection-oriented communication: There is a process of session establishment and termination, and data cannot be sent outside of this.
- Asynchronous communication: Data is sent in packets separated by arbitrary waits, unlike synchronous communication, where a constant flow of data is sent without intermediate waits.
This type of link is used in BR/EDR to transmit control frames and packets, and in LE for about 90% of all traffic.
There are other types of links for transmitting data in broadcast or continuous data streams.
Links:
- SCO (Synchronous Connection-Oriented Link): In Bluetooth BR/EDR for real-time voice data transmission.
- eSCO (Extended Synchronous Connection-Oriented Link): Evolution of SCO, improving audio quality.
- LE Coded PHY (Long Range): In Bluetooth LE to improve connection range and robustness.
- Broadcast:
- Isochronous: Introduced in Bluetooth 5.2, used for LE audio transmission (LE Audio).
Bluetooth L2CAP Layer
The L2CAP (Logical Link Control and Adaptation Protocol) layer allows data from different applications to be sent over the same ACL logical link. It provides a common interface for all higher-level protocols in the stack (called “application protocols”) by creating “L2CAP channels.”
An L2CAP channel (not to be confused with physical channels) is an abstraction used to transmit data between the two ends of a Bluetooth communication without dealing with the aspects of logical links, physical links, etc. It can be understood as an application-level tunnel.
It is a fundamental protocol that encapsulates almost all types of Bluetooth communication except for stream and broadcast data, which use other logical links.
In different sections of the standard, the concept of “connection” is referenced, and although there is no exact and unequivocal definition of what it means, it can be deduced that a connection in Bluetooth refers to the establishment of a communication session between two or more devices, establishing for this purpose a physical link, a logical link, and an L2CAP channel.
Relationship between Physical Architecture and Protocol Stack
Analyzing the Bluetooth physical architecture in detail and relating it to the protocol stack shows that BR/EDR and LE functions are implemented differently within the same structure. This means each has its own specific characteristics and mechanisms to manage communication.
- The physical transport layer (PHY) in BR/EDR and LE is responsible for data packaging and transmission and reception via the antenna in the physical transport sublayer.
- The baseband in BR/EDR groups many Bluetooth functions and manages channels and physical links, as well as the logical layer.
- The LMP (Link Manager Protocol) is a control protocol that establishes and manages the state of connections between two devices. This includes connection establishment, authentication, encryption, link maintenance, and disconnection, covering both physical and logical links.
Through HCI, the host can instruct the controller to initiate or stop high-level procedures, but the details are managed internally in the controller using LMP. Security functions are also delegated to the controller, and the host only intervenes when cryptographic material such as keys or data about the remote device and connection is requested.
A similar structure is found in LE, where the component called the “Link Layer” manages all aspects related to physical channels and links, as well as logical links. In this case, there is also a protocol to manage and negotiate the state of a connection, called LLCP (Link Layer Control Protocol), but unlike LMP, LLCP does not control the security functions of the connection.
These security functions in LE are implemented in a protocol above L2CAP, called SMP (Security Manager Protocol). On the other hand, LLCP is not mentioned as frequently as LMP, as it is usually referred to more generally as LL (Link Layer Protocol).
The rest of the layers, those implemented in the host, are encapsulated in L2CAP or use some of the logical links directly.
The HCI interface, which communicates the host with the controller, allows sending commands (HCI commands) and receiving events (HCI events) in addition to encapsulating L2CAP packets or application protocol data intended for logical links, but it is not strictly necessary for the implementation of a Bluetooth device. HCI communicates the host and the controller in complex systems where they are in separate hardware elements and need a standard communication interface. However, both components can be implemented in the same hardware device (for example, in the same SoC), so this communication interface is not necessary and can be replaced by a simpler programming API.
Conclusion and Closing
The complexity of Bluetooth protocols and elements makes studying the technology significantly challenging, but understanding the fundamental components makes the other functionalities and concepts easier to grasp.
After this introduction to the basic concepts of the technology, reading documentation, code, or the Bluetooth standard itself will be much simpler, and it will be much easier to understand each element’s role within the technology.