8. An Overview of Bluetooth Low Energy Platform

Bluetooth ^® low energy technology was introduced in 2010 as part of the Bluetooth ^® version 4.0 Core Specification published by the Bluetooth Special Interest Group (SIG). Starting from Version 4.0 onwards, the Bluetooth standard supports two distinct wireless technology systems: the Bluetooth low energy and the Basic Rate (BR), often referred as Basic Rate / Enhanced Data Rate (BR/EDR).

During the early stages of Bluetooth low energy design, the SIG focus was on developing a low complexity radio standard with the lowest possible power consumption, offering low bandwidth optimization, thus enabling low cost applications. In this context, Bluetooth low energy was designed to transmit very small packets of data each time, while consuming significantly less power than similar BR/EDR devices. Moreover, its design also supports efficient implementations having a tight energy and silicon budget, facilitating applications to operate for an extended period of time using a single coin cell battery.

Note

The following sections are based on the book “Getting Started with Bluetooth Low Energy” by Kevin Townsend, Carles Cufí, Akiba, Robert Davidson.

8.1. Devices Mode

Devices that support Bluetooth ^® low energy and BR/EDR are referred as dual-mode devices and are branded as Bluetooth ^®. Typically, inside the Bluetooth ecosystem, a mobile phone or laptop computer is considered a dual-mode device, unless specifically stated otherwise. Devices that only support Bluetooth low energy are referred to as single-mode devices.

Figure 1 Bluetooth ^® Branding

8.1.1. Single Mode Devices

A Single-mode (Bluetooth low energy) device only implements Bluetooth low energy. It can communicate with both single-mode and dual-mode devices, however not with devices that only support BR/EDR. Bluetooth low energy support is a must-have for single-mode devices to handle incoming messages and issue a response.

8.1.2. Dual Mode Devices

A Dual-mode BR/EDR/LE, Bluetooth low energy device, implements both BR/EDR and Bluetooth low energy and can communicate with any Bluetooth device.

8.2. Main Building Blocks

In the classic Bluetooth standard, the protocol stack consists of two blocks; the Controller and the Host. In Bluetooth BR/EDR devices, these two are usually implemented separately. However, more recent Bluetooth devices include an increased level of integration. The main building blocks that exist in almost every Bluetooth device are the following:

• The Application that uses the Bluetooth protocol stack interface to implement a particular use case.
• The Host that contains the upper layers of the Bluetooth protocol stack.
• The Controller that contains the lower layers of the Bluetooth protocol stack, including the radio.

Bluetooth specifications also offer a standard communication protocol between the host and the controller called Host Controller Interface (HCI), which allows interoperability between hosts and controllers when these are developed by different entities.

8.3. Hardware configurations

These main building blocks can be implemented in a single integrated circuit (IC) or System on Chip (SoC) device, or they can be split and executed in more than one ICs that are connected through a suitable communication interface and protocol (UART, USB, SPI, or other).

8.3.1. Integrated Processor

Most sensor applications tend to use the SoC hardware configuration as it reduces overall system complexity and associated printed circuit board (PCB) realization costs.

8.3.2. External Processor

Powerful computing devices like smartphones and tablets usually opt for the external processor, with the corresponding HCI protocol which may be either proprietary or standard. This approach also allows additional BLE connectivity with specialized microcontrollers to be integrated without modifying the overall design.

Figure 2 shows a comparison between the two approaches when Bluetooth is implemented:

Figure 2 Integrated vs external processor BLE hardware configurations

8.4. Network Modes

BLE devices use two distinct communication methods, each with certain benefits and limitations: Broadcasting and Connecting. Both methods follow certain procedures established by the Generic Access Profile (GAP) as described in 8.5.1 section.

8.4.1. Broadcasting

When using connectionless broadcasting, a Bluetooth low energy device sends data out to any scanning device or receiver that is within acceptable listening range. Essentially, this mechanism allows a Bluetooth low energy device to send data out one-way to anyone or anything that is able to pick up the transmission.

Broadcasting defines two separate roles:

• Broadcaster Sends non-connectable advertising packets periodically to anyone willing to receive them.
• Observer: Repeatedly scans the pre-set frequencies to receive any non-connectable advertising packets.

Broadcasting is the only way for a device to transmit data to more than one peer at a time. The broadcast data is sent out using the advertising features of Bluetooth low energy.

8.4.2. Connecting

For bi-directional data transmission in BLE a connection needs to be present. A connection in BLE is nothing more than an established, periodical exchange of data at certain specific points in time (connection events) between the two BLE peers involved in it. Typically, the data are exchanged only between the two BLE connection peers, and no other device is involved. Connections define two separate roles:

• Central (master): Repeatedly scans the pre-set BLE frequencies for connectable advertising packets and, when suitable, initiates a connection. Once the connection is established, the central manages the timing and initiates the periodical data exchanges.
• Peripheral (slave): A device that sends connectable advertising packets periodically and accepts incoming connections. Once in an active connection, the peripheral follows the central’s timing and exchanges data regularly with it.

For a connection to be initiated, the central device picks up the connectable advertising packets from a peripheral and then sends a request to the peripheral device to establish an exclusive connection between the two devices. Once the connection is established, the peripheral stops advertising and the two devices can begin exchanging data in both directions. Although the central is the device that manages the connection establishment, data can be sent independently by either device during each connection event, and the roles do not impose restrictions in data throughput or priority. It is therefore possible for a device to act as a central and a peripheral at the same time, for a central device to be connected to multiple peripherals as well as for a peripheral device to be connected to multiple centrals.

Connections provide the ability to organize the data with much finer-grained control over each field or property using additional protocol layers, more specifically, the Generic Attribute Profile (GATT). GATT organizes data around units called services and characteristics. Moreover, connections allow for higher throughput and support the establishment of a secure encrypted link, as well as negotiation of connection parameters to fit the data model.

A Bluetooth low energy device can have multiple services and characteristics, organized in a meaningful structure called a GATT Table. Services can contain multiple characteristics, each with their own access rights and descriptive metadata.

8.5. Profiles

The Bluetooth specification clearly separates the concept of Protocol and Profile. This distinction is made due to the different purposes each concept serves and the overall specifications are divided into:

• Protocols: They are the building blocks used by all devices conforming to the Bluetooth specification; protocols are essentially forming the layers that implement the different packet formats, routing, multiplexing, encoding, and decoding that allow data to be sent effectively between peers.
• Profiles: which are vertical slices of functionality defining either basic modes of operation required by all devices (such as the Generic Access Profile and the Generic Attribute Profile) or specific use cases (Proximity Profile, Glucose Profile). Profiles essentially specify how protocols should be used to achieve an objective, whether generic or specific.

8.5.1. Generic Profiles

Generic profiles are defined by the Bluetooth specification and two of them are fundamental as they ensure the interoperability between BLE devices from different vendors:

• Generic Access Profile (GAP): Specifies the usage model of the lower-level radio protocols to define roles, procedures, and modes that allow devices to broadcast data, discover devices, establish connections, manage connections, and negotiate security levels; GAP is essentially, the uppermost control layer of BLE. This profile is mandatory for all BLE devices, and all must comply with it.
• Generic Attribute Profile (GATT): Addresses data exchanges in BLE and specifies the basic data model and procedures to allow devices to discover, read, write, and push data elements between them. It is basically, the topmost data layer of BLE.

GAP and GATT are so fundamental to BLE that they are often used as the base for the provision of application programming interfaces (APIs) that act as the entry point for the application to interact with the protocol stack.

8.5.2. Use-Case-Specific Profiles

Use-case-specific profiles are usually limited to GATT-based profiles. Typically these profiles use the procedures and operating models of the GATT profile as a base building block for all further extensions. However, in version 4.1 of the specification, Logical Link Control and Adaptation Protocol (L2CAP) connection-oriented channels have been introduced, which indicates that GATT-less profiles are also possible.

8.5.2.1. SIG-defined GATT-based profiles

In addition to providing a solid reference framework for the control and data layers of devices involved in a Bluetooth low energy network, the Bluetooth SIG also provides a predefined set of use-case profiles based on GATT. These completely cover all procedures and data formats required to implement a wide range of specific use cases such as:

• Find Me Profile: it allows devices to physically locate other devices (for example using a smartphone to find a BLE enabled keyring, or vice versa).
• Proximity Profile: it detects the presence or absence of nearby devices (beep if an item is forgotten when leaving an area like a room).
• HID over GATT Profile: it transfers Human Interface Device (HID) data over BLE (for keyboards, mice, remote controls).
• Glucose Profile: it securely transfers glucose levels over BLE.
• Health Thermometer Profile: it transfers body temperature readings over BLE.

The Bluetooth SIG’s Specification in its Adopted Documents page provides a full list of SIG-approved profiles (for more information please visit https://www.bluetooth.com/specifications/adopted-specifications ). A developer can also browse directly the list of all currently adopted services for the Bluetooth services and characteristics at the Bluetooth Developer Portal.

8.5.2.2. Vendor-Specific Profiles

Vendors are allowed by the Bluetooth specification to define their own profiles for use cases that are not covered by the SIG-defined profiles. Those profiles can be kept private to the two peers involved in the use case (for example, a new sensor accessory and a Smartphone application), or they can also be published by the vendor so that other parties can provide implementations of the profile based on the vendor-supplied specification. An example of a published vendor-specific profile is Apple’s iBeacon.

8.5.3. Generic Access Profile Layer

The Generic Access Profile (GAP) layer is responsible for the overall connection functionality; it handles the device’s access modes and procedures including device discovery, directly interfacing with the application and/or profiles, and handling device discovery and connection-related services for the device. In addition, GAP takes care of the initiation of security features.

Essentially, GAP can be considered as Bluetooth low energy’s upper control layer, given that it specifies how devices perform control procedures such as device discovery and secure connection establishment. This ensures interoperability and thus allows data exchange between devices from different vendors.

GAP specifies four roles that a device can adopt in a BLE network:

• Broadcaster: The device is advertising with specific data, letting any initiating devices know for example that it is a connectable device. This advertisement contains the device address and optional additional data such as the device name.
• Observer: When a scanning device receives an advertisement it sends a “scan request” to the advertiser. The advertiser responds with a “scan response”. This is the process of device discovery, after which the scanning device is aware of the presence of the advertising device, and knows that it is possible to establish a connection with it.
• Central: when initiating a connection, the central must specify a peer device address to connect to. If an Advertisement is received which matches the peer device’s address, the central device will then send out a request to establish a connection (link) with the advertising device with a set of connection parameters.
• Peripheral: once a connection is established, the device will function as a slave if it was the advertiser and as master if it was the initiator.

Fundamentally, GAP establishes different sets of rules and concepts that regulate and standardize the low-level operation of devices, in particular:

• The Roles and interaction between them.
• The Operational modes and transitions across those devices.
• The Operational procedures to achieve consistent and interoperable communication.
• All Security aspects, including security modes and procedures.
• Additional data formats for non-protocol data.

8.5.4. Generic Attribute Profile Layer

The Generic Attribute Profile (GATT) layer is a service framework that defines all sub-procedures for using the Attribute Protocol (ATT). It describes in detail how profile and user data is to be exchanged over a Bluetooth low energy connection. In contrast to GAP which defines the low-level interactions with devices, GATT deals only with actual data transfer procedures and formats.

GATT also provides the reference framework for all the GATT-based profiles defined by the SIG. Effectively by covering the precise use cases for the profiles, it ensures interoperability between devices from different vendors; all the standard Bluetooth low energy profiles are therefore based on GATT and must comply with it to operate correctly. This makes GATT a key section of the Bluetooth low energy specification, since every data collection that is relevant to applications and users must be formatted, packed, and transmitted according to its rules.

GATT defines two roles for the interacting BLE devices:

• Client: It sends requests to a server, receives responses and potentially server initiated updates and notifications as well. The GATT client does not know anything in advance about the server’s attributes, so it must first inquire about the presence and nature of those attributes by performing service discovery. After completing service discovery, it can start reading and writing the attributes found in the server, as well as receiving server-initiated updates and notifications. It corresponds to the ATT client.
• Server: It receives requests from a client and issues responses. It also sends server-initiated updates and notifications when configured to do so. The server role is responsible for organizing the user data in attributes and making them available to the client. Every Bluetooth low energy device sold must include at least a basic GATT server that can respond to client requests, even if only to return an error response. It corresponds to the ATT server.

It is worth mentioning once again that GATT and GAP roles are completely independent yet concurrently compatible to each other. For instance, it is possible for both a GAP central and a GAP peripheral to act as a GATT client or server, or even both at the same time.

GATT uses ATT as a transport protocol for data exchange between devices. This data is organized hierarchically in sections called services, which group conceptually related pieces of user data called characteristics.

8.6. Protocol Stack

A single-mode Bluetooth low energy device is from an architecture point of view similar to all Bluetooth devices in that it is divided into three blocks: controller, host, and application. These basic building blocks each consist of several layers which are tightly integrated in the so-called Protocol Stack as shown in Figure 3.

Figure 3 Bluetooth low energy Protocol Stack Layers

The following sections summarize each of these blocks along with the layers each one covers.

8.7. Controller

The Controller includes all the lower level functionality necessary for a Bluetooth low energy device to communicate; it consists of the Physical Layer (PHY), the Link Layer (LL) and the controller side of the Host Controller Interface (HCI).

8.7.1. Physical Layer (PHY)

In the Physical Layer (PHY) the key block is the 1Mbps adaptive frequency-hopping Gaussian Frequency-Shift Keying (GFSK) radio. This operates in the unlicensed 2.4 GHz Industrial, Scientific, and Medical (ISM) band.

8.7.2. Link Layer (LL)

The Link Layer (LL) directly interfaces with the PHY; it is the hard real-time layer of the protocol stack as it must comply with all the timing requirements defined in the specification. Given that many of the calculations performed by the LL are computationally expensive, they are usually implemented with hardware accelerators. This helps prevent overloading of the Central Processing Unit (CPU) that runs all software layers in the stack, therefore the LL implementation is a combination of custom hardware and software. The functionality provided by the LL usually includes Preamble, Access Address, air protocol framing, CRC generation and verification, data whitening, random number generation and AES encryption. It is usually kept isolated from the higher layers of the protocol stack by an interface that hides this complexity and its real-time requirements.

The LL principally controls the Radio Frequency (RF) state of the device and manages the link state of the radio which is how the device connects to other devices. A Bluetooth low energy device can be a master, a slave, or both depending on the use case and the corresponding requirements. A master can connect to multiple slaves and a slave can be connected to multiple masters. Typically, devices such as smartphones or tablets tend to act as a master, while smaller, simpler, more memory-constrained devices such as standalone sensors generally adopt the slave role. A device can only be in one of the following five states: standby, advertising, scanning, initiating, or connected as shown in Figure 4.

Figure 4 Link Layer States

Advertisers transmit data without being connected, while scanners listen for advertisers. An initiator is a device that is responding to an advertiser with a connection request. If the advertiser accepts the connection request, both the advertiser and initiator will enter a connected state. When a device is in a connection state, it will be connected in one of two roles: master or slave. Typically, devices that initiate connections will be masters and devices that advertise their availability and accept connections will be slaves. Therefore, the Link Layer defines the following roles:

• Advertiser: a device sending advertising packets.
• Scanner: a device scanning for advertising packets.
• Master: a device that initiates a connection (initiator) and manages it later.
• Slave: a device that accepts a connection request and follows the master’s timing.

These roles can be logically grouped into two pairs: advertiser and scanner (when not in an active connection) and master and slave (when in a connection).

8.7.2.1. Bluetooth Device Address

The Bluetooth device address is the primary identifier of a Bluetooth device. This is just the same as an Ethernet Media Access Control (MAC) address which uniquely identifies a wired ethernet device. It is a 48-bit (6-byte) number that uniquely identifies a device among peers. There are two types of device addresses, and it is possible for a device to obtain one or both types:

• Public device address

This is the equivalent to a fixed, factory-programmed device address as used in BR/EDR devices as well. It must be registered with the Institute of Electrical and Electronics Engineers (IEEE) Registration Authority and should never change throughout the device’s lifetime.

• Random device address

This address can either be pre-programmed or dynamically generated at runtime on the device. There are numerous use cases in which such addresses are useful in Bluetooth low energy.

8.7.2.2. Advertising and Scanning

The Bluetooth low energy specification allows only one packet format and two types of packets, advertising and data.

Advertising packets are used for two purposes:

• To broadcast data for applications that do not need the overhead of a full connection establishment. This is used in Beacon applications.
• To discover slaves and connect with them so that data can be exchanged.

Data packets are used for user data transport between the master and the slave devices, in a bi-directional manner.

Finally, the Link Layer acts as a reliable data bearer since all received packets are checked against a 24-bit Cyclic Redundancy Check (CRC) and retransmissions are scheduled when the error checking mechanism detects a transmission failure. Since there is no pre-defined retransmission upper bound, the Link Layer will continuously resend the packet until it is finally acknowledged by the receiver.

8.7.3. Host Controller Interface – Controller side

The Host Controller Interface (HCI) interface at the Controller side, provides a mean of communication to the host via a standardized interface; the Bluetooth specification defines HCI as a set of commands and events for the host and the controller to interact with each other, along with a data packet format and a set of rules for flow control and other procedures. Additionally, the spec defines several transports, each of which augments the HCI protocol for a specific physical transport (UART, USB, SDIO, etc.).

8.8. Host

The Host block consists of a set of layers, each with specific role and functionality, which communicate with each other to make the overall block operate. As shown in Figure 3 these layers are the Logical Link Control and Adaptation Protocol (L2CAP), the Attribute Protocol (ATT), the Security Manager (SM) and finally the Generic Attribute Profile (GATT) and Generic Access Profile (GAP).

8.8.1. Host Controller Interface – Host Side

The HCI interface at the Host side provides a mean of communication to the controller via a standardized interface. As it matches the Controller Side HCI, this layer can be implemented either through a software API or over a hardware interface (UART, SDIO, USB etc).

8.8.2. Logical Link Control and Adaptation Protocol

The Logical Link Control and Adaptation Protocol (L2CAP) layer provides data encapsulation services to the upper layers, thus allowing logical end-to-end communication using data transfer. Essentially, it serves as a protocol multiplexer that takes multiple protocols from the upper layers and encapsulates them into the standard Bluetooth low energy packet format and vice versa. L2CAP is also responsible for package fragmentation and reassembly. During this process large packets originating from the upper layers of the transmitting side are fitted into the 27-byte maximum payload size of the Bluetooth low energy packets. The reverse process takes place at the receiving end, where the fragmented large upper layer packets are reassembled from multiple small Bluetooth low energy packets and transmitted up towards the appropriate upper level entity.

The L2CAP layer is in charge of routing two main protocols: the Attribute Protocol (ATT) and the Security Manager Protocol (SMP). Moreover, L2CAP can create its own user-defined channels for high-throughput data transfer, a feature called LE Credit Based Flow Control Mode.

8.8.3. Attribute Protocol

The ATT layer enables a Bluetooth low energy device to provide certain pieces of data, known as attributes, to another BLE device. In the context of ATT, the device exposing attributes is referred to as the server, and the peer device interested and working with these attributes is referred to as the client. The Link Layer state (master or slave) of the device is independent from the ATT role of the device. For example, a master device may either be an ATT server or an ATT client, while a slave device may also be either an ATT server or an ATT client. It is also possible for a device to be both an ATT server and an ATT client simultaneously.

Essentially ATT is a simple client/server stateless protocol based on the attributes presented by a device. A client requests data from a server, and a server sends data to clients. The protocol is strict which means that in case of a pending request (i.e. no response has yet been received for a previously issued request), no further requests can be submitted until the response to the first request is received and processed. This applies to both directions independently in the case where two peers are acting both as a client and server.

EEach ATT server contains data organized in the form of attributes, each of which is assigned a 16-bit attribute handle, called Universally Unique Identifier (UUID), a set of permissions, and finally a value. Effectively, the attribute handle is an identifier used to access an attribute value. The UUID specifies the type and nature of the data contained in the value. When a client wants to read or write attribute values from or to a server, it issues a read or write request to the server using the attribute handle. The server will respond with the attribute value or an acknowledgement. In the case of a read operation, it is up to the client to parse the value and understand the data type based on the UUID of the attribute. On the other hand, during a write operation, the client is expected to provide data that is consistent with the attribute type and the server is free to reject the write operation if the data is not in the specified format.

8.8.4. Security Manager

The Security Manager (SM) layer defines the method for pairing and key distribution and provides functions for the other layers of the protocol stack to securely connect and exchange data with another Bluetooth low energy device. It includes both a protocol and a series of security algorithms that are designed to provide the Bluetooth low energy protocol stack with the ability to generate and exchange security keys. This allows the peers to communicate securely over an encrypted link, to trust the identity of the remote device, and if required, to hide the public Bluetooth Address. It defines two roles:

• Initiator: which always corresponds to the Link Layer master
• Responder: which always corresponds to the Link Layer slave

Moreover, it provides support for the following three procedures:

• Pairing: the procedure by which a security encryption key is generated and manipulated to enable a secure encrypted link. This key is temporary and not stored or available for subsequent connections.
• Bonding: a sequence of pairing followed by the generation and exchange of permanent security keys. These are typically stored in non-volatile memory and therefore enable the creation of a permanent bond between two devices, which will allow them to quickly set up a secure link in subsequent connections without having to perform a bonding procedure again.
• Encryption Reestablishment: after a bonding procedure is complete, keys might have been stored on both sides of the connection. If encryption keys have been stored, this procedure defines how to use those keys in subsequent connections to re-establish a secure, encrypted connection without having to go through the pairing (or bonding) procedure again.

Pairing can therefore create a secure link that will only last for the lifetime of the connection. Bonding will create a permanent association (also called bond) in the form of shared security keys that will be used in later connections until either side decides to delete them. Sometimes documentation and APIs use the term pairing with bonding instead of simply bonding, since a bonding procedure always includes an initial pairing phase.

Although it is always up to the initiator to request the start of a specific security procedure, the responder can asynchronously request the start of any of the procedures listed above. There are no guarantees however for the responder that the initiator will fulfil the request. Therefore, the request is optional rather than binding. This security request can logically be issued only by the slave or the peripheral end of the connection.