Bluetooth Low Energy (BLE) 101 Tutorial: Intensive Introduction

Bluetooth is quite known wireless protocol used intensively in mobile phones industry. Back in 2001, Sony Ericsson T36 mobile phone was the first mobile phone with built-in bluetooth connectivity. Bluetooth has evolved over the years to meet the new requirements of the technology market. Bluetooth has announced in Bluetooth Version 4.0 a new protocol called Bluetooth Low Energy (BLE) targeting mainly IoT devices powered from very low capacity batteries.

So starting from version 4.0 back in 2010, Bluetooth has three protocols: Classic Bluetooth, Bluetooth high speed and Bluetooth Low Energy (BLE). The Bluetooth 4.0 specification permits either or both of single-mode and dual-mode devices. Single-mode devices support only BLE, while dual-mode ones can operate in BLE or Classic Bluetooth protocol. However, “Bluetooth Smart Ready” refers to dual-mode device, and “Bluetooth Smart” refers to BLE single-mode device.

Bluetooth documentation uses a lot of terminologies, this tutorial intends to keep things simple and practical. So let’s demonstrate the most important terminologies.

Why it’s called Bluetooth Stack?

probably, this is the first  term you will read in most resources. Bluetooth has several protocol layers which form a stack. You can think of it like the OSI model in networks, where each layer has a specific job. Layers deal with radio signals, others with encryption/decryption, fragmentation/defragmentation, and others manage how to access data and broadcast device information. Thus, this is is very similar to the OSI model.

Image Courtesy of Getting Started with Bluetooth Low Energy Book by Akiba, Carles Cufí, Kevin Townsend, and Robert Davidson

Image Courtesy of Performance Evaluation of Bluetooth Low Energy: A Systematic Review. Sensors 2017, 17, 2898.

Before giving an overview for each layer, you should know about the main blocks of Bluetooth stack:

• Controller: Combines LE PHY and Link Layer layers which are responsible for all operations related to radio connection, transaction and more.
• Host: Combines L2CAP, SMP, GAP, ATT and GATT layers that manage how to access real data, discover BLE devices and more.
• Host-Controller Interface (HCI): a linking layer (interface) between the Host and Controller. This interface provides a standard method of accessing the Bluetooth baseband capabilities (a protocol with specific commands).
• Application: here where you have your real code, on an MCU flash memory for instance.

Image Courtesy of Getting Started with Bluetooth Low Energy Book by Akiba, Carles Cufí, Kevin Townsend, and Robert Davidson

Back to practical terms, according to these 3 main fragments, different BLE chipsets may contain :

• Controller only with HCI interface.
• Controller and Host with Proper Protocol.
• System on Chip (SoC) combining Host, Controller and Application (a processor with flash memory to run your code).

As examples:

• CC256x from TI represents an example of a chip that only contains a controller and HCI interface.
  Note: HCI protocol is defined in Bluetooth specification

  CC256x Internal Block Diagram – Datasheet

• ESP32 from Espressif or NRF5xxxx from Nordic Semiconductor (.i.e NRF52832) are examples of SoCs combine what It’s needed to run your application without any external IC.

BLE Software Stack

Another important term is “BLE Software Stack”, which is the software responsible to manage the BLE layers and radio hardware. Each silicon provider has its own implementation of the software stack. Softdevice is the BLE stack for NRF chipsets, ported version of Bluedroid is for ESP32 and Bluegiga is for SiliconLabs products.

However, some SoC vendors give developers the option to use the SoC as only a BLE controller like ESP32.

What A Novice Need to Know about BLE Stack?

Bluetooth details are very ramified in a way that made the Bluetooth V4.2 specification a 2700-page-long document!

To avoid the maze of new terms and information, just keep your focus to understand BLE in a  top-bottom approach. Where only you need to understand what GAP, ATT and GATT are responsible of and in a later step SMP. Besides that, a basic understanding of how Bluetooth works (connection, advertising, ..etc) is a must.

Advertising (Advertiser & Scanner)

BLE devices broadcast some information to make any other near device know about its presence. The broadcasters are called “advertisers” and devices that receive these advertisements are called “scanners”.  The advertising packets can be observed by all scanners, thus they are initially connectionless packet. This very similar to “Access Points” in WiFi where SSID, encryption type and other information are broadcasted to all nearby devices.

Advertise packets data can be as long as 31 Bytes, formatted as follows:

• 1st byte: Length excluding the length byte (this byte).
• 2nd byte: AD type, which could be one of the types specified by Bluetooth specification.
• Last, AD data with variable length according to AD type.
• The previous is called an “AD structure”, and advertising data can have more than one AD structure.

Bluetooth 4.2 Specification

Examples:

1- This is a part of a code for ESP32 to define an advertising data

static uint8_t raw_adv_data[] = {

       /* Len:2, Type:1 (flags), Data:6 */

       0x02, 0x01, 0x06,

       /* Len:2, Type:a (tx power), Data:eb*/

       0x02, 0x0a, 0xeb,

       /* Len:3, Type:3 (Complete List of 16-bit Service Class UUIDs), Data: FF 00 */

       0x03, 0x03, 0xFF, 0x00,

       /* Len:16, Type:9 (Complete Local Name) */

       0x0f, 0x09, 'E', 'S', 'P', '_', 'G', 'A', 'T', 'T', 'S', '_', 'D','E', 'M', 'O'

};

2- This is another example of AD packet’s raw data shown in SiliconLabs blog:

Image Courtesy of SiliconLabs

Is that all what AD packet contains? No, there is the header that contains other important information about connectability type of that device.

Image Courtesy of Bluetooth SIG Website

The  following table from the Getting Started with Bluetooth Low Energy Book shows the options of PDU types, and for more details about these type read Bluetooth SIG blog post “Bluetooth Low Energy – It starts with Advertising”:

Moreover, the AD packet can be employed to implement a connectionless protocol like the very-known one, iBeacon from Apple or Eddystone beacon format from Google. Connectionless terms means that the receiver can receive the packet without a real dedicated connection with the receiver.

Despite the meaning and details of ibeacon fields using the AD packet, this was worth mention for a future interest for readers.

How Your Device Data Is Stored ?

At this point you know how to advertise your device and the format of AD packets. Now, what if your BLE device needs to send battery level to a mobile phone, or what if you need to control a relay using an App. How data is stored and how to exchange values? Let’s see.

The very basic building block is called Attribute Protocol (ATT), which defines the basic structure of how “device” data is stored and exchanged. At a very basic level of understanding, you can see your BLE device has a database table with entries with special format and fields. Each entry should have this structure:

Bluetooth V 4.2 Specification

Where, “Attribute Handle” (2 Bytes) represents like a unique ID for each entry, “Attribute Type” is a unique number called UUID (later you will see 2 Bytes and 16 Bytes version of UUID) to point to the Attribute value kind/length ..etc, and finally the “Attribute Permissions” defines whether read or write access is permitted for a given attribute. Bluetooth SIG has some reserved UUID to make them standard between different devices that implement the same services, all UUIDs are found in Bluetooth website.

The device which contains this database to be accessed called the “server”, while the device to access this remote database called the “client”. The server contains a number of attributes, and here the “GATT Profile” comes to define a more generic structure to control how to use the Attribute Protocol to discover, read, write ..etc data.

The “GATT” has a logical hierarchy consists of: one or more services, and each service has one or more characteristic. Remember that all have the general structure of attributes (Handler, UUID and value).

Bluetooth V 4.2 Specification

To sum up, this example shows exactly what we just described in the previous paragraph

Image is adapted from Nordic Semiconductor video tutorial via Youtube

You can see that every entry has a unique Handler, UUID (type) and a value.

• Lines 0x0001, 0x0006, 0x0007 and 0x000B declare for primary services, which are respectively 0x1800 UUID for GAP service, 0x1801 UUID for GATT service, 0x180F UUID for Battery service and last one is a user defined service with custom UUID (16 B version), and this UUID can be choosed by the developer.
  
  Note: UUID of services are found on Bluetooth website
• After each service declaration, there is a characteristic declaration ( 0x2803 type). Lines 0x00002, 0x0004, 0x0008 and 0x000C are of that type. Now, the value of these lines should follow the format in the next table:

Bluetooth V 4.2 Specification

Let’s take a line and analyze it according to that format:

Attribute Handle: 0x00008 Attribute Type: 0x2803 Attribute Value: 0x12 0x00009 0x2A19

Thus, Characteristic Properties (0x12) will be to set permission to subscribe to notifications which are sent from server to client when a change in value happens and to send read requests.

Bluetooth V 4.2 Specification

Now Characteristic value attribute handel is a pointer that holds the handler of the attribute which holds the Characteristic value. This line pointer is equal to 0x00009, which will be used to store/read the battery level. Finally, the Characteristic UUID is a 2 Bytes value which could be a value from Bluetooth SIG set reserved Characteristic UUID values , or a user-defined one. In our case it refers to battery level Characteristic.

Conclusion

As been told before, Bluetooth and BLE protocols have dozens of terms, and only practice could make things crystal clear. This introduction is not complete, but it shell gives a good background to cover BLE programming in ESP32 later or to any other reader intend to use a chip from other silicon provider. Many terms will be clarified and revisited in the next part of this article, which will be a hands-on testing of BLE in ESP32.

Many references were used to combine these information to name a few:

• BLUETOOTH SPECIFICATION Version 4.2 Vol 0-4.
• Introduction to Bluetooth Smart – Nordic Semiconductor video tutorial via Youtube.
• Mohammed Afaneh’s series of BLE introduction via Youtube.
• Getting Started with Bluetooth Low Energy Book by Akiba, Carles Cufí, Kevin Townsend, and Robert Davidson.
• Inside Bluetooth Low Energy Second Edition by Naresh Guptaa.