Understanding the Architecture of the Bluetooth Low Energy Protocol Stack

This paper provides an in-depth introduction to the architecture of the Bluetooth Low Energy (BLE) protocol stack and explores how to leverage existing BLE applications to fully realize the potential of low-power wireless communication. Such knowledge is essential for efficiently and reliably designing, troubleshooting, and optimizing applications.

Bluetooth Low Energy (BLE) is a key technology in the Internet of Things (IoT) ecosystem. Initially developed as a wireless protocol to replace cables in consumer electronics such as keyboards, mice, and headphones, BLE has since expanded its capabilities far beyond being just a cable replacement. Today, it plays a vital role in various industries including healthcare, retail, automotive, as well as industrial applications like location tagging and instrument control.

According to the 2023 Bluetooth Market Update, the compound annual growth rate (CAGR) for shipments of devices featuring Bluetooth wireless technology is projected to be 9% from 2023 to 2027. Under this growth trend, it is anticipated that BLE device shipments will more than double by 2027, with 97% of all Bluetooth-enabled devices adopting BLE.

BLE is a wireless technology introduced with the Bluetooth 4.0 specification in July 2010. Formerly known as Bluetooth Smart, BLE is specifically designed for ultra-low-power devices.

While traditional Bluetooth technology, which we are familiar with, is primarily used for pairing smartphones with headphones and transferring large amounts of data such as music and photos, BLE serves different purposes. Although traditional Bluetooth can handle substantial data transfers, it consumes more battery power in doing so. In contrast, BLE is optimized for applications that do not require extensive data transmission, making it an ideal choice for various power-sensitive applications. Traditional Bluetooth remains active and consumes power even when not in use, whereas BLE spends most of its time in sleep mode, waking up only to establish connections, which typically last just a few milliseconds. This efficient power management, combined with data rates of up to 1 Mbps (reaching 2 Mbps in BLE 5.0), enables BLE devices to operate with extremely low power consumption.

Figure 1. (a) Key points of Classic Bluetooth and (b) Bluetooth Low Energy specifications.2

Figure 2. (a) Applications of Classic Bluetooth and (b) Bluetooth Low Energy.2

Bluetooth Specifications

As illustrated in Figures 1 and 2:

► Classic Bluetooth: Represents the earliest version of Bluetooth, featuring high data rate capabilities suitable for streaming, high-bandwidth file transfers, and headsets. It utilizes 79 RF channels, including 32 advertising channels to allow other devices to discover and connect.

► Bluetooth Low Energy: Targets low-power applications with infrequent data transfers, such as sensors and other low-bandwidth transmissions. It employs 40 RF channels, with 3 channels dedicated to device discovery.

Overview of BLE Applications

A typical BLE application consists of two devices: a peripheral and a central device. Before establishing a connection, the peripheral advertises its presence through a process known as BLE advertising. The central device scans for available peripherals. Once the central device locates the desired peripheral, a connection is established between them. Subsequently, applications on each device can communicate with each other by transferring data through different layers of the BLE protocol stack. Refer to Figure 3.

For example, a smartphone can act as the central device, while a fitness tracker serves as the peripheral. The fitness tracker, functioning as a server, collects data such as heart rate, blood pressure, ECG, step count, and even sleep patterns. It broadcasts its presence to nearby devices, including the smartphone acting as a client. The smartphone retrieves this data from the fitness tracker and displays it on a user-friendly application. This is just one example of the numerous applications enabled by BLE, with more to be discussed later in the article.

Figure 3. Layers of peripheral and central devices

 

BLE Protocol Stack Architecture

The BLE protocol stack architecture (as shown in Figure 4) is a structured software framework that enables communication between BLE devices. It defines the necessary layers and protocols for establishing, maintaining, and terminating Bluetooth connections, facilitating data exchange between devices.

The BLE protocol stack architecture is typically divided into three main layers: the application layer, the host layer, and the controller layer. The application layer is the topmost layer of the protocol stack. Applications running on BLE devices utilize and process actual data at this layer. The host layer resides between the application layer and the controller layer in the protocol stack, implementing all higher-level protocols and profiles required for BLE communication. Additionally, it provides high-level Application Programming Interfaces (APIs) that enable applications to interact with lower layers of the protocol stack. The controller layer represents the hardware portion of the BLE protocol stack, responsible for transmitting and receiving Bluetooth signals. It handles tasks such as frequency hopping, modulation, and demodulation of signals. These layers work in tandem to achieve efficient and reliable communication between BLE devices.

Figure 4. BLE protocol stack architecture

 

Applications

The application layer is utilized to fulfill specific application requirements of BLE devices. It interacts with lower layers of the protocol stack through the Generic Attribute Profile (GATT), based on services, characteristics, and corresponding data defined by GATT.

The characteristics and behaviors of devices are designed at the application layer. This includes defining services and characteristics, specifying data exchange methods, and implementing event handling logic for connection, disconnection, data updates, etc. The primary role of the application layer is to customize the BLE protocol stack according to the specific needs of the device and its intended usage scenario.

 

Host

The host layer encompasses the remaining upper-layer protocols of the BLE protocol stack, specifically including the Logical Link Control and Adaptation Protocol (L2CAP), Security Manager Protocol (SMP), Attribute Protocol (ATT), Generic Attribute Profile (GATT), and Generic Access Profile (GAP). L2CAP serves as a channel interface between upper and lower layer protocols, responsible for segmenting and encapsulating application data and transmitting data packets using ACL links. L2CAP correctly locates endpoints on devices through Channel Identifiers (CIDs) and channel multiplexing. Refer to Figure 5.

Figure 5. L2CAP data packet

 

L2CAP Signaling

In the BLE protocol stack, commands are exchanged between devices in the form of requests and responses. Here are some key points regarding commands:

► Commands are sent as requests and responses.

► Each Protocol Data Unit (PDU) can transmit one command.

► PDUs containing L2CAP signaling messages are referred to as C-frames (control frames), while data frames are classified as B-frames (basic information frames) and LE-frames (low energy information frames). Refer to Figure 6.

Figure 6. L2CAP frame format

► Command Reject

■ Response sent when the command code is unrecognizable or the command length is incorrect

■ Possible reasons

■ Unknown command

■ Exceeds L2CAP signaling Maximum Transmission Unit (MTU)

■ Invalid CID in the request

► Connection Parameter Update Request

■ Sent by an LE node to an LE master node to request a new set of connection parameters

■ Connection Parameters

■ Interval min

■ Interval max

■ Node latency

■ Timeout multiplier

► Connection Parameter Update Response

■ Sent by the LE master node to the LE node in response to a Connection Parameter Update Request

The Security Manager Protocol (SMP) defines the pairing, authentication, and encryption procedures between BLE devices. SMP commands utilize L2CAP services to execute these procedures. An SMP command packet consists of a code field and a data field. The code field identifies the type of command, while the length and format of the data field depend on the command type. All SMP procedures implement a 30-second timeout to determine procedure failure. Refer to Table 1.

 

Table 1. SMP Command Codes

 

The Attribute Protocol (ATT) defines rules for accessing device attributes or data. It supports discovering, reading, and writing attributes on remote devices. ATT follows a client-server model. The server exposes a set of attributes, while the client can discover, read, and write these attributes. The attribute structure in ATT consists of a handle, type, value, and permissions. The attribute handle is a unique non-zero identifier assigned to each attribute on the server. The attribute type specifies the meaning of the attribute through a Universally Unique Identifier (UUID). The UUID can be a 16-bit UUID assigned by the Bluetooth Special Interest Group (SIG) or a custom 128-bit UUID. The attribute value represents the actual data value of the attribute, while the attribute permissions determine the allowed access levels for the attribute. Refer to Figure 7.

Figure 7. Attribute structure

ATT defines six types of Protocol Data Units (PDUs): request, response, command, confirmation, notification, and indication (Figure 8). Request PDUs are sent by the client to the server, requesting a reply. Response PDUs are replies from the server to the client in response to requests. Command PDUs are sent by the client to the server without requiring a reply. Indication PDUs are sent by the server to the client, requiring a response. Confirmation PDUs are sent by the client to the server as a response to indications. Notification PDUs are sent by the server to the client without requiring a response. Through these PDU types, clients and servers can exchange information and exercise control at the ATT layer of the BLE protocol stack.

Figure 8. Different types of attribute PDUs

An ATT PDU packet consists of an opcode, attribute parameters, and an authentication signature (Figure 9). The opcode field identifies the method/type of the PDU, such as a request or response. It also includes a command flag indicating whether the PDU type is a command and an authentication signature flag indicating whether the packet uses an authentication signature.

Figure 9. ATT PDU packet format

Figure 10. BLE layer data packet format

Figure 10 summarizes the data packet formats at each layer of the BLE protocol stack architecture and provides an overview of the data structure.

Moving up the host layer, the next higher layer is the Generic Attribute Profile (GATT). GATT is responsible for defining the formatting, encapsulation of data or attributes, and rules for interaction between devices. GATT procedures include attribute discovery, reading, writing, notification, and indication. It provides a standard framework for managing data in BLE devices.

Multiple GATT profiles may exist within a single BLE device (Figure 11). Standard profiles are defined in the Bluetooth specification to ensure interoperability between BLE devices from different manufacturers. However, custom profiles can also be implemented based on specific application requirements. Therefore, understanding the structure of GATT profiles is crucial.

A GATT profile consists of services. A service refers to a group of related attributes defined in the ATT protocol. In GATT, the term “characteristic” is often used to refer to attributes, but a characteristic may contain descriptors that are themselves attributes. A characteristic serves as a container for user data, while descriptors provide explanations or additional information about the user data.

Figure 11. GATT profile structure

Similar to ATT, there are two roles in GATT: GATT client and GATT server. A GATT client is a device that accesses data on a remote GATT server. A GATT server is a device that supports access to its data by remote GATT clients. In GATT, the role of a device is determined by the direction of data access.

Within the host layer of the BLE protocol stack, the Generic Access Profile (GAP) is the top-level protocol that defines how Bluetooth devices access and communicate with each other. GAP covers device operating modes, discovery procedures, connection establishment, and security mechanisms. All devices supporting Bluetooth technology are required to implement GAP, as it provides a standard framework for controlling BLE devices.

GAP provides different roles for BLE devices based on their activity states. When a connection is not required, a BLE device can act as a broadcaster or an observer. A broadcaster is a device that announces its presence within a proximity range. It primarily utilizes the broadcaster role of the link layer to send advertisements. An observer, in contrast, utilizes the scanner role of the link layer to scan the relevant area for advertisements from nearby devices. In real-life scenarios, examples of broadcasters include BLE beacons, while examples of observers include BLE hubs that collect data. Refer to Figure 12.

Figure 12. Broadcaster transmitting advertisement packets to an observer

When a connection can be established, GAP provides two additional roles for BLE devices: peripheral and central device. A peripheral, similar to a broadcaster, announces its presence and waits for a connection request from a remote central device. A central device, acting as an observer, scans for peripherals and initiates a connection request to the desired peripheral. As mentioned earlier, examples of peripherals include smartwatches, fitness trackers, and home automation sensors, while examples of central devices include smartphones, tablets, and laptops. Refer to Figure 13.

Figure 13. Central/peripheral vs. broadcaster/observer

According to Bluetooth specification requirements, the GAP service must be implemented by the GATT server within a profile. The GAP service encompasses various characteristics related to basic device information, typically including: device name, device appearance, peripheral preferred connection parameters, central device address resolution, and private addresses that can only be obtained through resolution.

Controller

The controller comprises two layers: the link layer and the physical layer. The physical layer, located at the bottom of the BLE protocol stack, is responsible for the actual transmission and reception of wireless signals. The physical layer operates in the 2.4 GHz ISM band and employs a Gaussian Frequency Shift Keying (GFSK) modulation scheme. This modulation scheme enables efficient data transmission by varying the frequency of the carrier signal.

The physical layer consists of 40 channels, each spaced 2 MHz apart:

► 3 advertising channels are used for broadcasting short data packets to announce the presence of broadcasters and their available services or information.

► 37 data channels are utilized after a connection is established between a central device and a peripheral.

Prior to the release of the Bluetooth 5 core specification, BLE solely employed three fixed advertising channels (37, 38, 39). However, Bluetooth 5 introduced extended advertising, allowing the 37 data channels originally used for data transmission to be repurposed as secondary advertising channels. This extension unlocks new features in Bluetooth 5 and expands the coding scheme options for the physical layer. Refer to Figure 14.

Figure 14. BLE channels

Bluetooth 5 introduced three different physical layer (PHY) types, supporting three modulation schemes and four data transmission rates (Table 2). The default PHY is LE 1M, operating with a modulation scheme of 1 million symbols per second (1 Msym/s), achieving a data transmission rate of 1 megabit per second (1 Mbps), and a wireless transmission range of up to 100 meters. Another PHY type, LE 2M, employs a 2 Msym/s modulation scheme, increasing the data transmission rate to 2 Mbps. The third PHY type, LE Coded, supports two data transmission rates: 125 Kbps and 500 Kbps. Similar to the LE 1M mode, LE Coded adopts a 1 Msym/s symbol rate modulation scheme. With coding, at a data rate of 125 Kbps, each bit of data is expanded into 8 symbols (S=8), while at a data rate of 500 Kbps, each bit of data is expanded into 2 symbols (S=2). This coding scheme enables the LE Coded PHY to be used in long-range mode applications, with a transmission range of up to 1000 meters in open spaces (supporting forward error correction to reduce the bit error rate).

 

Table 2. Different PHYs in BLE

► The layer above the physical layer (PHY) is the link layer, which is responsible for managing scanning, advertising, connection establishment, connection maintenance, and link maintenance between devices. The link layer also manages channel selection for data transmission, utilizing adaptive frequency hopping spread spectrum to reduce interference. The link layer state machine defines five states: standby, advertising, scanning, initiating, and connected (Figure 15).

► In standby mode, the link layer is idle and does not transmit or receive data packets.

► In advertising state, the link layer (acting as a broadcaster) sends advertisement packets while listening for devices requesting additional information.

► In scanning state, the link layer (acting as a scanner) listens for broadcasters and can actively send scan requests to obtain more information.

► In initiating state, the link layer (acting as an initiator) listens for data packets from broadcasters and responds to advertisements by initiating connection requests to the broadcasters.

► When the link layer is connected to the link layer of another BLE device, it is in the connected state.

Figure 15. Link layer state transitions

In addition to different states, the link layer also defines events such as advertising events and connection events. Advertising events involve transmitting data packets using advertising channels, while connection events involve transmitting data packets over data channels in a connected state.

The link layer also defines the format of BLE data packets transmitted by the physical layer. The data packet format differs between coded PHY (Coded PHY) and uncoded PHY (Uncoded PHY).

Figure 16. BLE data packet for uncoded PHY

As shown in Figure 16, a BLE data packet for uncoded PHY starts with a preamble, followed by an access address, PDU, and Cyclic Redundancy Check (CRC).

As depicted in Figure 17, a BLE data packet for coded PHY consists of a preamble, Forward Error Correction (FEC) block 1, and FEC block 2.

► The preamble is an alternating sequence of 1s and 0s used for frequency synchronization. It has a length of 1 byte for LE 1M and 2 bytes for LE 2M.

► The access address serves as an association code for devices tuned to the physical channel; it has a length of 4 bytes. For physical advertising channels, the access address is a fixed value of 0x8E89BED6.

► The PDU contains the payload from upper layers of the BLE protocol stack. It can be an advertising PDU or a data PDU, potentially containing important information from sensors or other devices required for communication. More information will be discussed in the next section.

► The CRC is used for error checking.

Figure 17. BLE data packet for coded PHY

► The Constant Tone Extension (CTE) consists of a sequence of continuously modulated non-whitened 1s and is typically used selectively. The CTE is crucial for BLE’s direction-finding feature.

► FEC block 1 contains the access address, coding indicator (CI), and block terminator (TERM1). The CI indicates the coding scheme used in FEC block 2, while TERM1 is a 3-bit block terminator.

► FEC block 2 contains the PDU, CRC, and TERM2, encoded using the same coding scheme indicated by the CI field in FEC block 1.

Regardless of whether uncoded PHY or coded PHY is used, the BLE data packet PDUs can be categorized into two types: advertising channel PDUs and data channel PDUs. Refer to Figures 18 to 21.

Figure 18. Advertising physical channel PDU

Figure 19. Advertising physical channel PDU header

As shown in Figure 19, advertising channel PDUs are used for advertising events. They consist of a 2-byte header and a payload of up to 255 bytes.

The header contains the following fields: PDU type, RFU (reserved for future use) bits, ChSel, TxAdd, RxAdd, and length. The values of ChSel, TxAdd, and RxAdd bits depend on the PDU type, while the length field describes the length of the payload in bytes.

Figure 20. Data physical channel PDU

Figure 21. Data physical channel PDU header

As shown above, data channel PDUs are used in connection events. They consist of a header of 2 or 3 bytes, a payload, and a Message Integrity Check (MIC) for encrypted links.

The data channel PDU header contains the following fields: LLID, NESN, SN, MD, CP, length, and CTEInfo.

► LLID describes the type of link layer data PDU.

► NESN (Next Expected Sequence Number) identifies the next data packet expected from the peer device.

► SN (Sequence Number) identifies the current data packet.

► CP (CTEInfo Present) indicates the presence of an additional CTEInfo field.

► The length field describes the length of the payload in bytes.

► CTEInfo describes the type and length of the CTE.

 

Host Controller Interface (HCI)

HCI acts as an intermediary between the host and the controller. It provides a set of standardized commands and events to support communication between these two layers.

HCI supports multiple types of transport layers, including UART, USB, SDIO, and Three-wire UART. Each transport layer has its own specifications and requirements. This overview focuses on the UART transport layer.

According to the Bluetooth 5.2 specification, the UART transport layer supports five types of data packets: command, event, Asynchronous Connection-Oriented (ACL) data, Synchronous Connection-Oriented (SCO) data, and Isochronous (ISO) data.

► The host uses command packets to send commands to the controller. These commands instruct the controller to perform specific operations or configurations.

► The controller uses event packets to inform the host of events that have occurred. Events can include connection status changes, data reception, or other relevant information.

► ACL packets are used for exchanging data between the host and the controller. They support the transmission of asynchronous data, such as information from sensors or user input.

► SCO packets are used for exchanging synchronous data between the host and the controller. However, it should be noted that BLE does not support SCO packets, which are primarily used for voice or audio transmission in classic Bluetooth.

► ISO packets are a newly added packet type that supports the transmission of time-bounded data between devices using BLE. Isochronous packets are designed for applications requiring precise timing, such as audio streaming or real-time control.

Figure 22. Bluetooth applications

Why is it important?

BLE is widely used in various scenarios, ranging from consumer products to industrial environments, making it beneficial to understand BLE and its significance. BLE is an evolving and upgrading protocol that offers limitless possibilities for application development.

Use Cases

BLE is extensively applied across numerous industries, subtly influencing our daily lives (Figure 22). Familiarity with BLE helps individuals understand and leverage its advantages in various application scenarios. BLE has made significant contributions to many fields, driving innovation in existing processes. The following are some of these areas:

BLE in the Medical Field

BLE plays a crucial role in the medical field. BLE technology enables devices such as glucose meters and blood pressure monitors, and even implantable devices like pacemakers requiring ultra-low power consumption, to function effectively. These devices can collect data and transmit real-time reports to patients and healthcare providers. BLE is also used for patient tracking, locating room or floor numbers, and transmitting information to medical responders.

BLE in Location Tracking

With BLE technology, advanced trackers or smart tags can be attached to bags, keys, or even pets to track their locations. These tags are designed to be compact and energy-efficient, making the low energy consumption characteristic of BLE vital. Many industries also utilize BLE technology for warehouse slot monitoring, grocery store management, and indoor navigation.

BLE in Wearable Devices

The requirements for lightweight portability and long battery life in wearable devices make BLE technology an ideal choice. Devices such as smartwatches, fitness bands, and smart glasses commonly employ BLE to achieve wireless connectivity and reduce energy consumption.

BLE in Audio Streaming

BLE plays a significant role in audio streaming applications. With the introduction of LE Audio, BLE now supports low-latency audio streaming, delivering an enhanced audio experience. LE Audio adopts the Low Complexity Communication Codec (LC3), ensuring audio quality remains unaffected at low data rates. This opens up new possibilities for wireless audio consumption.

BLE in Home Automation

In the realm of home automation, BLE serves as a foundational technology for enabling smart homes. The Internet of Things (IoT) is widely applied in smart homes, and BLE supports seamless connectivity among various smart devices. A diverse range of smart devices supporting BLE is available for home automation, including key fobs, home beacons, switches, etc. BLE empowers users to control and monitor various aspects of their homes, such as smart lighting, energy-efficient home energy management, smart door locks, wireless speaker systems, home robots, and security systems.

Conclusion

In the BLE protocol stack, application data undergoes processing through multiple protocol layers before reaching the remote application on another device (which also possesses its own BLE protocol stack). The complete process is as follows:

1. Application Layer: The application selects appropriate attributes to store the data to be transmitted.
2. ATT Layer: An ATT layer packet is generated, containing information corresponding to the target attribute on the remote device.
3. L2CAP Layer: The packet from the ATT layer is processed by the L2CAP layer. If necessary, L2CAP performs data segmentation and reassembly. This layer adds an L2CAP header to each L2CAP packet.
4. Link Layer: The L2CAP packet is passed to the link layer, which then transfers the packet to the physical layer for wireless transmission. A link layer header is added to the packet, forming a Protocol Data Unit (PDU).
5. Physical Layer: Before transmission, the physical layer adds the necessary preamble, access address, and CRC to the PDU. The packet is then transmitted wirelessly.

On the receiving end, the remote BLE device receives the packet and performs the reverse process to extract the data.

 

 

OMAGINE specializing in ODM PCB design, PCB assembly, open source hardware related modules and sourcing service.