Bluetooth Low Energy (BLE) Introduction Part 2

Last Updated on: June 29th, 2022

In our previous tutorial (Part 1) we have seen the very basics of BLE. Now we will see Bluetooth Low Energy (BLE) Introduction Part 2. In this part, we will discuss the BLE Protocol stack. Before that quick recap about the BLE.

You can also read, Bluetooth interfacing with LPC2148, Bluetooth interfacing with PIC16F877A, and Bluetooth interfacing with 8051.

Quick Review

Bluetooth Low Energy is also called as BLE and Bluetooth Smart. The main big advantage of the BLE is it consumes very very little power. BLE, unlike the classic Bluetooth standard, is designed to reduce power consumption, allowing your BLE device to run for months or years on a coin-cell battery.

BLE device communicates to other devices in two methods.

Broadcasting: Broadcasting is the act of sending data out to all the listening devices. (One to Many)

Connections: A connection is a permanent, periodical data exchange of packets between two devices. (One to One).

BLE devices have two roles.

Central/Master: Central devices scanning the advertising packets from nearby peripheral devices and initiates the connection.

Peripherals/Slave: Peripheral devices send the advertising packets periodically. And also accepts the incoming connection.

Now we will get into our BLE Protocol stack.

Bluetooth Low Energy (BLE) Introduction – Part 2

BLE Protocol Stack

BLE, like many other wireless technologies, is organized in a number of layers. Each layer has its purpose and plays a significant role in making a BLE device function properly. As we discussed before there are three building blocks present in the BLE.

1. Application

2. Host

3. Controller

Each of these basic building blocks of the protocol stack is split into several layers that provide the functionality required to operate:

Application

The application, like in all other types of systems, is the highest layer and the one responsible for containing the logic, user interface, and data handling of everything related to the actual use-case that the application implements. The architecture of an application is highly dependent on each particular implementation.

Host

The host contains the following layers.

• Generic Access Profile (GAP)

• Generic Attribute Profile (GATT)

• Logical Link Control and Adaptation Protocol (L2CAP)

• Attribute Protocol (ATT)

• Security Manager (SM)

• Host Controller Interface (HCI), the Host side

Controller

The controller contains the following layers.

• Host Controller Interface (HCI), Controller side

• Link Layer (LL)

• Physical Layer (PHY)

Controller Layers

Physical Layer (PHY)

The physical (PHY) layer is the part that actually contains the analog communications circuitry, capable of modulating and demodulating analog signals and transforming them into digital symbols.

The BLE can communicate over 40 channels from 2.4000 GHz to 2.4835 GHz. 37 of these channels are used for connection data and the last three channels (37, 38, and 39) are used as advertising channels to set up connections and send broadcast data.

The standard uses a technique called frequency-hopping spread spectrum, in which the radio hops between channels on each connection event using the following formula:

channel = (curr_channel + hop) mod 37

The value of the hop is communicated when the connection is established and is therefore different for every newly established connection. This technique minimizes the effect of any radio interference potentially present in the 2.4 GHz band across any single channel, especially since WiFi and classic Bluetooth are prevalent in this band and devices might experience heavy interference near devices with strong transmission power.

Link Layer(LL)

The Link Layer is the part that directly interfaces with the PHY, and it is usually implemented as a combination of custom hardware and software. It is responsible for all of the timing requirements defined by the specification.

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 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).

Bluetooth Device Address (BDA)

The fundamental identifier of a Bluetooth device, similar to an Ethernet Media Access Control (MAC) address, is the Bluetooth device address. This 48-bit (6-byte) number uniquely identifies a device among peers. There are two types of device addresses, and one or both can be set on a particular device:

1. Public device address

2. Random device address

Public device address

This is the equivalent to a fixed, BR/EDR, factory-programmed device address. It must be registered with the IEEE Registration Authority and will never change during the lifetime of the device.

Random device address

This address can either be preprogrammed on the device or dynamically generated at run time.

The Link Layer also takes care of the Bluetooth Device Address.

The Link Layer is also in charge of establishing connections, it filters out advertising packets depending on the Bluetooth address or based on the data itself. And also manages the connection interval – The time between the beginning of two consecutive connection events. The link-layer can also configure Encryption, which is highly desirable in case of a lot of devices present in the same range.

It is important to note that the Link Layer acts as a reliable data bearer. All packets received are checked against a 24-bit CRC and re-transmissions are requested when the error checking detects a transmission failure. There is no upper limit for re-transmissions; the Link Layer will resend the packet until it is finally acknowledged by the receiver.

Other than advertising, scanning, establishing (and tearing down) connections, and transmitting and receiving data, the Link Layer is also responsible for several control procedures, including these two critical processes:

1. Changing the connection parameters

2. Encryption

Host Controller Interface (HCI)

Host Controller Interface (HCI) is a standard protocol that allows for the communication between a host and a controller to take place across a serial interface.

Typical examples of this configuration include most smartphones, tablets, and personal computers, in which the host (and the application) runs in the main CPU, while the controller is located in a separate hardware chip connected via a UART or USB. This is similar to the model used by other technologies, such as WiFi or Ethernet: the TCP/IP stack runs on the main processor, while the lower-level layers execute in a separate IC.

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 means of transport, each of which augments the HCI protocol for a specific physical transport (UART, USB, SDIO, etc.).

Host Layers

Logical Link Control and Adaptation Protocol (L2CAP)

This layer does two main tasks,

1. Protocol multiplexer

2. Fragmentation and recombination

Protocol multiplexer

This layer act as a protocol multiplexer. This means, that takes multiple protocols from the upper layers and encapsulates them into the standard BLE packet format (and vice versa).

Fragmentation and recombination

On the Transmitter side, it takes large packets from the upper layers and breaks them up into chunks that fit into the 27-byte maximum payload size of the BLE packets.

On the Receiver side, it receives multiple packets that have been fragmented and recombines them into a single large packet that will then be sent upstream to the appropriate entity in the upper layers of the host. For Bluetooth Low Energy, the L2CAP layer is in charge of routing two main protocols:

1. Attribute Protocol (ATT)

2. Security Manager Protocol (SMP)

The ATT forms the basis of data exchange in BLE applications, while the SMP provides a framework to generate and distribute security keys between peers.

Attribute Protocol (ATT)

The Attribute Protocol (ATT) is a simple client/server stateless protocol based on attributes presented by a device. In BLE, each device is a client, a server, or both, irrespective of whether it’s a master or slave. A client requests data from a server, and a server sends data to clients.

The protocol is strict when it comes to its sequencing. if a request is still pending (no response for it has been yet received) no further requests can be sent until the response is received and processed. This applies to both directions independently in the case where two peers are acting both as a client and server.

Each server contains data organized in the form of attributes, each of which is assigned a 16-bit attribute handle, a universally unique identifier (UUID), a set of permissions, and finally, of course, a value. The attribute handle is simply 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 writes a request to the server with the handle. The server will respond with the attribute value or an acknowledgment. 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 operation if that is not the case.

The set of operations possible over ATT fall within the following categories:

• Error Handling

• Error Response

• Server Configuration

• Find Information

• Read Operations

• Write Operations

• Queued Writes

• Server Initiated

All operations except the ones in the server-initiated category (and a few select others) are grouped into request/response pairs. Requests are always sent by the client and responses are issued by the server as a reply to a request.

Security Manager (SM)

The Security Manager (SM) is both a protocol and a series of security algorithms designed to provide the Bluetooth protocol stack with the ability to generate and exchange security keys, which then allow the peers to communicate securely over an encrypted link, to trust the identity of the remote device, and finally, to hide the public Bluetooth Address if required to avoid malicious peers tracking a particular device.

It does two roles,

1. Initiator

2. Responder

Initiator – Always corresponds to the Link Layer master and therefore the GAP central.

Responder – Always corresponds to the Link Layer slave and therefore the GAP peripheral.

Generic Access Profile (GAP)

GAP is an acronym for the Generic Access Profile, and it controls connections and advertising in Bluetooth. GAP is what makes your device visible to the outside world, and determines how two devices can (or can’t) interact with each other.

GAP establishes different sets of rules and concepts to regulate and standardize the low-level operation of devices:

• Roles and interaction between them

• Operational modes and transitions across those

• Operational procedures to achieve consistent and interoperable communication

• Security aspects, including security modes and procedures

• Additional data formats for non-protocol data

Roles

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

• Broadcaster

• Observer

• Central

• Peripheral

Already we have discussed these roles.

Each particular device can operate in one or more roles at a time, and the specification imposes no restrictions in this regard.

Many developers mistakenly try to associate the BLE GATT client and server roles with GAP roles. There is no connection between those at all, and any device can be a GATT client, server, or both, depending on the application and situation.

Consider, for example, a fitness tracker paired with a smartphone. The fitness tracker’s GAP role is peripheral, and it acts as a GATT server when the phone requests data from its sensors. It can also sometimes act as a GATT client when it requests accurate time data from the smartphone to update its internal clock for data timestamping. The GATT client/server roles depend exclusively on the direction in which the data requests and responses transactions flow, whereas GAP roles stay constant as peripheral for the fitness tracker and central for the smartphone.

Modes

Mode is a state in which the device can switch to for a certain amount of time to achieve a particular goal or, more specifically, to allow a peer to perform a particular procedure. Switching modes can be triggered by user interface actions or automatically when required, and devices tend to switch modes more frequently than roles.

Procedures

A procedure is a sequence of actions (usually Link Layer control sequences or packet exchanges) that allows a device to attain a certain goal. A procedure is typically associated with a mode on the other peer, so they are often tightly coupled together.

Security

GAP builds on top of the Security Manager and the Security Manager Protocol by defining security modes and procedures that specify how peers set the level of security required by particular data exchange and later how that security level is enforced.

Additional GAP Data Formats

In addition to all of the above, GAP is also used as a placeholder for certain additional data format definitions that are related to the modes and procedures defined by the GAP specification.

Generic Attribute Profile (GATT)

GATT is an acronym for the Generic Attribute Profile, and it defines the way that two Bluetooth Low Energy devices transfer data back and forth using concepts called Services and Characteristics. It makes use of a generic data protocol called the Attribute Protocol (ATT), which is used to store Services, Characteristics, and related data in a simple lookup table using 16-bit IDs for each entry in the table.

GATT comes into play once a dedicated connection is established between two devices, meaning that you have already gone through the advertising process governed by GAP.

Once a connection is established between peripherals and the central devices, however, communication can take place in both directions, which is different than the one-way broadcasting approach using only advertising data and GAP.

Roles

An important concept to understand with GATT is the server/client relationship.

GATT Client

The Central device (phone/Tablet) is known as GATT Client. The GATT client corresponds to the ATT client. It sends requests to a server and receives responses (and server-initiated updates) from it. 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.

GATT Server

The Peripheral device (sensors) is known as GATT Server. The GATT server corresponds to the ATT server. It receives requests from a client and sends responses back.

It is worth mentioning once more that GATT roles are both completely independent of GAP roles and also concurrently compatible with each other. That means that both a GAP central and a GAP peripheral can act as a GATT client or server, or even act as both at the same time.

UUIDs

A universally unique identifier (UUID) is a 128-bit (16 bytes) number that is guaranteed (or has a high probability) to be globally unique.

Attributes

Attributes are the smallest data entity defined by GATT (and ATT). They are addressable pieces of information that can contain relevant user data (or metadata) about the structure and grouping of the different attributes contained within the server. Both GATT and ATT can work only with attributes, so for clients and servers to interact, all information must be organized in this form.

Conceptually, attributes are always located on the server and accessed (and potentially modified) by the client.

Handle

The attribute handle is a unique 16-bit identifier for each attribute on a particular GATT server. It is the part of each attribute that makes it addressable, and it is guaranteed not to change between transactions or, for bonded devices, even across connections. Because value 0x0000 denotes an invalid handle, the amount of handles available to every GATT server is 0xFFFE (65535), although in practice, the number of attributes in a server is typically closer to a few dozen.

Type

The attribute type is nothing other than a UUID. This can be a 16-, 32-, or 128-bit UUID, taking up 2, 4, or 16 bytes, respectively. The type determines the kind of data present in the value of the attribute, and mechanisms are available to discover attributes based exclusively on their type.

Permissions

Permissions are metadata that specify which ATT operations can be executed on each particular attribute and with which specific security requirements.

ATT and GATT define the following permissions:

Access Permissions

Similar to file permissions, access permissions determine whether the client can read or write (or both) an attribute value. Each attribute can have one of the following access permissions:

• None – The attribute can neither be read nor written by a client.

• Readable – The attribute can be read by a client.

• Writable – The attribute can be written by a client.

• Readable and writable – The attribute can be both read and written by the client.

Value

The attribute value holds the actual data content of the attribute. There are no restrictions on the type of data it can contain (you can imagine it as a non-typed buffer that can be cast to whatever the actual type is, based on the attribute type), although its maximum length is limited to 512 bytes by the specification.

Attribute and Data Hierarchy

The attributes in a GATT server are grouped into services, each of which can contain zero or more characteristics. These characteristics, in turn, can include zero or more descriptors. This hierarchy is strictly enforced for any device claiming GATT compatibility (essentially, all BLE devices sold), which means that all attributes in a GATT server are included in one of these three categories, with no exceptions. No dangling attributes can live outside of this hierarchy, as exchanging data between BLE devices depends on it.

Services

Services are used to break data up into logic entities and contain specific chunks of data called characteristics. A service can have one or more characteristics, and each service distinguishes itself from other services by means of a unique numeric ID called a UUID, which can be either 16-bit (for officially adopted BLE Services) or 128-bit (for custom services).

Characteristics

You can understand characteristics as containers for user data. They always include at least two attributes:

• The characteristic declaration (which provides metadata about the actual user data)

• The characteristic value (which is a full attribute that contains the user data in its value field)

So, we have discussed all the BLE basics. Hope you would understand and enjoy it at the same time. Thanks for reading :-).

You can also read the below tutorials.

Linux Device Driver Tutorials	C Programming Tutorials
FreeRTOS Tutorials	NuttX RTOS Tutorials
RTX RTOS Tutorials	Interrupts Basics
I2C Protocol – Part 1 (Basics)	I2C Protocol – Part 2 (Advanced Topics)
STM32 Tutorials	LPC2148 (ARM7) Tutorials
PIC16F877A Tutorials	8051 Tutorials
Unit Testing in C Tutorials	ESP32-IDF Tutorials
Raspberry Pi Tutorials	Embedded Interview Topics
Reset Sequence in ARM Cortex-M4	BLE Basics
VIC and NVIC in ARM	SPI – Serial Peripheral Interface Protocol
STM32F7 Bootloader Tutorials	Raspberry PI Pico Tutorials
STM32F103 Bootloader Tutorials	RT-Thread RTOS Tutorials
Zephyr RTOS Tutorials - STM32	Zephyr RTOS Tutorials - ESP32
AUTOSAR Tutorials	UDS Protocol Tutorials
Product Reviews	STM32 MikroC Bootloader Tutorial
VHDL Tutorials