Bluetooth Low Energy (BLE) 101 Tutorial: Intensive Introduction

Yahya Tawil

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:

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 :

As examples:

 

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:

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

As a quick example: Imagine “Control GPIOs” is a service while “set output”, “set input”, “get interrupts”, “get input” … etc are the characteristics.

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.

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:

 

Related Articles
↑
Exit mobile version