Skip to main content

Command Palette

Search for a command to run...

Bluetooth Low Energy (BLE) 101

Getting to know Bluetooth Low Energy

Updated
4 min read

Bluetooth is a short-range wireless technology standard that was introduced in 1998. It is mainly used for exchanging data between portable devices over short distances, such as wireless headphones, wireless speakers, etc.

Bluetooth Low Energy (BLE) is a low-power variant of Bluetooth Classic standard. Originally developed by Nokia under the name WIbree in 2006, this solution tried to address the scenarios that contemporary wireless technologies did not address at that time. Some targeted applications or scenarios are in the healthcare, fitness, smart home, and home entertainment industries. These applications generally have low cost and low power requirements where the devices are able to operate for months or years on a button cell.

As the smartphones, tablets, mobile computing, and Internet-of-Thing (IoT) grow rapidly, the BLE has also grown fast and has been widely adopted.

One of the strong advantage of BLE or Bluetooth is its interoperability. It means that it is easy to connect devices and smartphones from different vendors together. It is becoming so common in the Internet of Things (IoT) field to connect embedded devices, such as ESP32, with a smartphone. This opens a unique opportunity for new innovative solutions that might not possible before.

That is why being able to develop a BLE-powered application might be an important skill to have for (embedded) software engineers. In this article, I will cover the basic concepts and architecture of BLE.

Architecture

The Bluetooth Low Energy protocol stack is divided into three layers: Application, Host, and Controller.

Application Layer

This is the highest layer where applications are built using BLE as the underlying communication protocol. It contains the logic and user interface related to the actual use-case of the application. The application layer relies on the API interfaces provided by the Host Layer.

Host Layer

The Host Layer defines the BLE protocol itself. It consists of Generic Access Profile (GAP), Generic Attribute Profile (GATT), Attribute Protocol (ATT), Security Manager (SM), and Logical Link Control and Adaptation Protocol (L2CAP). GAP and GATT are the backbone of BLE data transfer protocol and it is imperative for application developers to understand these modules to successfully build a BLE-powered application. Both of them will be covered in more detail in the next section.

Host Controller Interface (HCI)

HCI is a standard protocol that acts as an interface between the host and controller layer. The connection generally takes place via a UART or USB interface. If the host and controller layer are implemented on the same chip (a system-on-chip or SoC), HCI is referred to as Virtual Host Controller Interface (VHCI).

Controller Layer

The Controller Layer consists of the Physical Layer (PHY) and Link Layer (LL). The Physical Layer interacts with the actual hardware (analog communication circuitry) for signal modulation and demodulation.

The Link Layer is implemented as a combination of custom hardware and software. The hardware side implements functionalities that are computationally expensive on separate hardware to avoid overloading the CPU running the software stack.

The software side manages the connection state between devices and device roles. A BLE device can have the following roles: Advertiser, Scanner, Master, and Slave.

User applications are not able to use the controller layer directly.

Protocol Basics

This sections describes the basics of BLE protocol within the Host Layer.

Generic Access Profile (GAP)

The Generic Access Profile (GAP) defines how devices interact with each other at a lower level. It defines the roles (i.e., Advertiser, Scanner, and Initiator) and the connection states (i.e., Idle, Device Discovery, and Connection). Note that a BLE device can have more than one role.

In Idle mode, the device is in a state without any role.

In device discovery mode, a device can become an advertiser indicating its presence to other devices. It can also adopt the scanner role. As a scanner, it continuously scans the environment and detects the presence of connectable advertisers. If the scanner wants to establish a connection with a advertiser, it switches its role to Initiator.

Once a device is connected to another device, it can adopt a peripheral role (slave) or a central role (master).

Generic Attribute Profile (GATT)

GATT defines the hierarchical data structure and data exchange mechanism between connected devices. It is built on top of Attribute Protocol (ATT), which defines the basic data structure called Attribute and data access method based on a server/ client architecture.

An attribute data structure typically consists of:

  • Handle. A unique 16-bit identifier for each attribute.
  • Type. An UUID.
  • Value.
  • Permissions. A metadata specifying whether the attribute is readable or writable or both.

GATT extends ATT by defining hierarchical data structure which consists of three concepts:

  • Characteristics
  • Service
  • Profile

Profile sits on the highest level in the hierarchy. It consists of a predefined set of service. The service itself contains a set of characteristics. Both service and characteristic are based on attributes (i.e., handle, type, value, and permissions). A characteristics itself contains the actual user data that the client can read from and write to.

This marks the end of the article. GATT is a big subject and I will cover this in more detail in the next article. I hope that you can learn something new about BLE from this article.

References

[Book] Getting Started with Bluetooth Low Energy by Kevin Townsend et. al.
[ESP-IDF] BLE-Introduction

40 views