Introduction to Bluetooth Low Energy / Bluetooth 5

Overview

In this lesson we will take a look at the Bluetooth Low Energy (BLE) protocol, its versions and architecture. The key information needed to get started with BLE on an nRF5x chip is provided per each layer of the architecture. We will also understand the main differences between Bluetooth Low Energy and Bluetooth Classic. Gaining fundamental knowledge about the BLE architecture will pay off, and will significantly help when we reach Lesson 4, and start diving into Nordic Semiconductor BLE Protocol Stack (SoftDevice) API. In the exercise section of this lesson, you will be introduced to the general structure of a connection-orinted BLE firmware, and the minimum nRF5 SDK modules needed to make a BLE device discoverable and connectable.

Bluetooth Low Energy vs Bluetooth Classic

Before we examine the BLE architecture, we will first compare it to Bluetooth Classic. Bluetooth Low Energy, which was initially advertised as “Bluetooth Smart”, is a light-weight independent branch of the original “now known as Classic Bluetooth ” and was introduced as part of the Bluetooth 4.0 core specification in 2010. It is a wireless communication standard for short range, ultra-low-power personal area network operated in the unlicensed 2.4 GHz ISM band. The figure below shows the timeline of BLE and Bluetooth Classic, highlighting its major releases and main features introduced in each release. As can be seen from the figure below, prior to 2010, there was only one main type of Bluetooth, after 2010 we have BLE and Bluetooth Classic.

When people talk about Bluetooth nowadays, there are two main types. The first type is the Classic, which could be Bluetooth Basic Rate (BR), Enhanced Data Rate(EDR) or the High Speed (HS). The Bluetooth Classic is intended for short-range communication with a relatively higher throughput than BLE. This type of Bluetooth is still used in our cars, Bluetooth-enabled headsets, speakers and smart printers to transfer files. This type of Bluetooth has no regard to power consumption. You typically can not efficiently operate a Bluetooth Classic device on a coin cell battery.

The second type is Bluetooth Low Energy (BLE), which emerged along with the Bluetooth specification 4.0 in 2010. BLE is a massive divergence from the Bluetooth Classic . BLE is not compatible with the Bluetooth Classic. It is different hardware, different architecture, different specification, and hence different target applications. BLE is intended for Ultra-Low-Power (ULP) low-bandwidth applications, like the IoT. The key features of the BLE protocol:

• Ultra-Low-Power(Coin-cell battery 1+ year).
• Small packets size(244 Bytes payload max).
• Short receive (RX) and transmit TX windows.
• Race to idle:
  • Turn radio on as seldom as possible.
  • Turn radio off as soon as possible.
• Low memory footprint(Small protocol stack size, starting from a hundred Kilobyte).
• Fast connection(less than 6 ms) and disconnection time.
• Simple stateless operation, data in form of key-value pairs (attribute).

Below are the architecture block diagrams for both Bluetooth Classic and Bluetooth Low Energy. We will only focus on the architecture of BLE:

One important consideration to keep in mind is that a device could support one of these two types of Bluetooth or both. In the case of both the device is known as Smart Ready and it would contain both hardware for Classic and for BLE. Most modern smart phones, workstations, and laptops have Bluetooth connectivity chips which support both Classic and Low Energy(Smart Ready). These chips are more commonly known as Dual-mode Bluetooth chips.

On the other hand, all Nordic nRF5x SoCs only support BLE. They do not support the Bluetooth Classic, and hence they are not Dual-mode Bluetooth chips. Nordic nRF5x SoCs are customized and tailored to ultra-low-power applications.

There are a number of short-range low power wireless protocols like ZigBee, and Z-Wave out there for engineers and product designers, but what makes BLE interesting is that, unlike the others, it’s natively supported in almost all smartphones and popular OS’s.

Bluetooth Low Energy Architecture

The BLE architecture is split into three main building blocks outlined below. We will examine each of these blocks individually starting from the bottom. The key essential information about each layer to get stared with BLE on an nRF5x chip is provided.

• Application: User application interfacing with the BLE protocol stack. Most of the time, this is the firmware of the nRF5x chip, that we will write as developers tailoring the exact needs and constrains of the product being designed. This is pure software, part of this code will be imported from the nRF5 SDK.
• Host: Upper layers of the BLE protocol stack. Usually we rely on a manufacturer library to interact with this layer. In our case of the nRF5x, it is the SoftDevice protocol stack. SoftDevice is covered in-depth in Lesson 4.
• Controller: Lower layer of the BLE protocol stack, including the radio. Seldomly we directly interact with this layer, instead the SoftDevice interact with the controller on our behalf. Most of this layer is implemented in hardware, the remaining part is implemented by the SoftDevice.

Controller

1. Physical Layer (PHY) : The physical layer(aka PHY) is responsible for the RF modulation and demodulation. The RF is operated in the 2.4 GHz ISM unlicensed band, which is shared with several other popular wireless protocols like Wi-Fi and Classic Bluetooth . It contains the analog communications circuitry responsible for translation of digital data over the air. It is the lowest layer of the protocol stack, and provides its services to the Link Layer. The communication spectrum is divided into 40 RF channels on 2 MHz spacing from 2.4000 GHz to 2.4835 GHz, starting at 2402 MHz. It’s worth noting that channels 37, 38, and 39 are called advertisement channels , while the remaining channels are called data channels. Advertisement channels are used for: device discovery, during connection establishment, and for broadcasting. While the data channels are used for: bidirectional communication between connected devices, advertisement extensions (BLE 5 onward only). BLE uses a Frequency hopping scheme. This is intended to reduce interference of neighboring 2.4GHz based devices ( Like other Bluetooth-enabled devices, or even Wi-Fi devices), the scheme determines which channel should be used next for the next connection event(covered next), among the 37 data channels.

 

The nRF Connect – RSSI Viewer app will help us monitor these channels and estimate surrounding 2.4GHz interference. The app shows the Received Signal Strength Indicator(RSSI) in decibel-milliwatts (dBm) per channel in the 2.4000 GHz to 2.4835 GHz BLE bandwidth.

One important note to keep in mind is that depending on which nRF5x chip you are using, there could be up to three different types of physical layers(PHYS) available on the same chip die (As covered previously in the Foundation Level of this course). These PHYs are listed below :

• BLE_GAP_PHY_1MBPS. The standard BLE 4.x physical layer capable of a theoretical 1Mbps data rate. Available in all nRF5x devices(Both nRF51 and nRF52).
• BLE_GAP_PHY_2MBPS. The high speed physical layer capable of a theoretical 2Mbps data rate. Added in BLE specification 5 and available in all nRF52 devices only.
• BLE_GAP_PHY_CODED. The coded ( aka: Long Range, aka: full house coverage) physical layer which is capable of either a theoretical 500Kbps or a theoretical 125Kbps data rate. With this physical layer, BLE range is extended up to 1Kilomete line-of-sight. See this demo YouTube video by Nordic Semiconductor, where two nRF52840 DK communicate with each other using the coded PHY over a relatively long distance. This PHY is available in some nRF52 devices like the nRF52840 , nRF52833, nRF52820, and the nRF52811. It uses a special encoding technique to encode the transmitted data called Forward Error-correcting Codes (FEC) , and hence the name. With FEC, each bit is now either sent by the radio as two bits (S=2) or eight (S=8). This effectively increases the range by x4, of course, this is on the expense of the data rate.

Regardless of the PHY type, the transmitted power by the PHY radio on an nRF5x chip is configurable through the SoftDevice API. We will set the value of the transmitted power based on the needs of the application and use cases. The transmitted power have a significant impact on the device range. The allowable values are between -40dBm to 4dBm (8dBm exclusively in the case of nRF52840, nRF52833, and nRF52820). dBm stands for decibel-milliwatts, which references 1mw at 0dB. Therefore, a 0dBm means that the transmit power is 1mw, 4dBm = 2.5mw , while -40dBm = 0.0001 mw and so on.

2. Link Layer(LL) : This is the layer that interface directly with the physical layer. Most of this layer is implemented in hardware as it deals with the real-time requirements of the BLE specifications. The remaining part of this layer is implemented by the SoftDevice. The link layer is responsible for several core tasks:

• Advertising, scanning, and creating/maintaining connections.
• Encapsulating the date received from the uppers layers and generating BLE packets that are passed bit by bit to the PHY.
• BLE packets error-detecting(CRC).
• Optional Encryption/Decryption of the communication. The cipher algorithem used in BLE is AES-CCM 128-bits.
• BLE device address management.
• Defines the role and state of the device.
  • Advertiser: A device sending advertisement packets.
  • Scanner: A device scanning for advertisement packets.
  • Master: A device which initiate a connection and manage it.
  • Slave: A device that accepts a connection request and follows the master’s timing.

A device Link Layer(LL) role could change during various stages of discovery/connection(This is controlled through the GAP upper layer as we will see in-details in the next lesson). For example, Device X might start in a Scanner role indicating its interest to connect to a neighboring Device Y. Once Device Y advertisement is picked, handshaking(simplified in the diagram below) is performed and the Scanner becomes the Master and the Advertiser becomes the Slave.

Note that an nRF5x SoC can be configured to be in multi-role configuration as we will see in Lesson9 .

BLE Discovery Phase

In the discovery phase of a BLE connection or when the devices are set to be only advertiser/scanner pairs. Every time a device advertises, it send the same advertisement packet in each of the three advertising channels(37,38, and 39). The advertiser does not sends these packets continuously. This goes along with the BLE philosophy of “Turn radio on as seldom as possible” . Instead, it sends its advertisement in intervals. This interval is called the Advertiser Advertising Interval. We will configure this parameter using the SoftDevice API to fit the application needs. Typical values for the nRF5x SoCs are between 20 millisecond ( high power consumption, better user experience) to 10.24 seconds ( low power consumption, high possibility of bad user experience).

On the scanner device side; which in most cases is a mobile device, a tablet or a host machine; the scanner does not scan continuously, again, this is in sync with the BLE philosophy of “Turn radio on as seldom as possible” . Instead, it scans for advertisements in intervals. This interval is called Scanner Scan Interval. During this interval, scanning will be active only in a portion of it. This portion is called the Scanner Scan Window. Both the Scanner Scan Interval and the Scanner Scan Window are to some extent configurable through the underlying library or OS. For instance, Android offers three out-of-the-box different schemes for scanning , each one varies in the Scanner Scan Interval and the Scanner Scan Window.

From the screenshot above of the source code of the Android Scanner Manager , We can see that for the SCAN_MODE_LOW_POWER, the scan window is 512ms while the scan interval is 5.12 seconds.

In few cases, the scanner side could also be an nRF5x chip(As we will cover in-depth in Lesson 11 ), for example two nRF52840 DK boards , one will act as a scanner, and the other will act as an advertiser in the discovery phase of the connection. In such case, both the advertiser and scanner parameters are set through the SoftDevice stack protocol. In general, if we have a scan window equals to the scan interval, then the radio will be ON about 100% of the scan time( Very high power consumption). There will be a short period of a few hundred microseconds (For SoftDevice internal handling) after each scan interval where it will hop frequency to the next advertisement channel(37, 38, and 39) during this transition period, the scanner can not receive any advertisement packet.

The scan window and scan interval must be set in great consideration to the power consumption requirements of the application. The figure below illustrates these important parameters on both the scanner and advertiser sides.

Note: The Scanner and the Advertiser are two different devices that are not synchronized together. To increase the chance that the scanner will pick the advertiser signal, the Scanner Scan Interval must be at least the double of the Advertiser Advertising Interval.

BLE Connection Phase

Once a Scanner (Ex: Device X) has collected sufficient information about a connectable Advertiser of interest, it initiates a BLE connection process. The Scanner will be the Master(Link Layer Master) of the connection and the Advertiser will be the Slave of the connection(Link Layer Slave). The Slave can negotiate the following parameters related to the BLE connection with the Master:

• Connection interval: This is the time between two consecutive connection events. Typical values are between 7.5 millisecond (High data throughput, High power consumption ) to 4 seconds (Low data throughput, low power consumption).A Connection event is the time when the devises exchange data. On a connection event, both devices are transmitting and receiving data sequentially. Each connection event starts with the master transmitting and the slave receiving. Then the opposite, the slave transmits and the master receives. This periodic exchange of data happens regardless of whether the master or the slave has any useful data(user data) to send to the other end. This exchange happens periodically to maintain the status of the connection.
• Number of BLE packets per connection event: How many BLE packets are sent per connection event. This highly depends on the Library/OS used (Android, iOS, SoftDevice, etc.), and the underlying BLE hardware. For Nordic Semiconductor BLE stack (SoftDevie) it is up to 6, however, the connection master have the final word on this. The master always has the final word on all negotiable parameters.
• Slave Latency: The number of connection events that a slave can chose to skip without the risk of losing the connection. Slave latency allows a slave device to skip connection events if it does not have any useful data to send. This can help reduce power consumption on the slave side only(On the expense of lower slave responsiveness). Typical values are between 0 and 499. The slave latency must still be quicker than the Supervision Timeout covered next.
• Supervision Timeout: Length of time the master will wait for a response from the slave before the connection is marked for termination. Typical values are between 100 millisecond and 32 seconds. Supervision Timeout, of course, has direct relation with the Connection interval and Slave Latency, it should ≥ (2*Connection interval * (Slave Latency + 1)) and < 32 seconds.
• Data-Packet Length: This depends on the version of BLE used. See this figure for the comparison between the data packet length for the different BLE versions.

We will practice connection parameters negotiation with the help of the Connection Parameters Negotiation library in Lesson 3 – Exercise 1, where we will specify a range of acceptable connection interval value, when to invoke the negotiation process, how many attempts, in addition to specifying what to do when the negotiation fail/succeed.

These parameters heavily impact the throughput of a BLE connection and the power consumption as illustrated below.

Effect of connection parameters on throughput:

Effect of connection parameters on power consumption:

As for the power consumption, the following figures shows the massive effect of the Connection Interval on the nRF5 SoC overall power consumption as calculated statically using the Nordic Semiconductor Online Power Profiler. Play with the other parameters to see their effect on the total power consumption.

We will configure all of these parameters through Nordic Semiconductor BLE protocol stack (SoftDevice) on the Advertiser/Slave side, and the Scanner/Master side through the appropriate software API.

BLE packets:

The BLE packets generated by the LL has only one structure and fall under two types : Advertisement packet or Data packet .

Advertisement packets size:

• For BLE 4.0 : 31 byte payload plus optional additional 31 bytes in scan response.
• For BLE 5.0 and above: 255 byte payload through advertisement extension.

Data packets size:

• For BLE 4.0: 27 byte payload. Only 20 available for the user data.
• For BLE 4.2 and above: 251 byte payload. Only 244 available for the user data.

The Preamble is used to lock the PLL of the receiver with the PLL of the sender. In other words , it tries to align the transmit and receive windows on the two connected devices. The Access Address is mainly used to identify a connection. Examine the Data packet content, there is no MAC address sent(neither for the master nor for the slave). The only way to distinguish a connection from another is through the Access Address. The Access Address is randomly generated per BLE connection. This ensure that two connections happening on the same data channels have a very low probability to collide(1/2^32). On the other hand, in Advertisement packets, the Access Address is simply set to the fixed value of 0x8E89BED6. We will examine the Advertisement PDU(Protocol Data Unit) and data PDU in-depth in the upcoming lessons. As for the CRC (Cyclic Redundancy Check), it enables the receiver to detect if there were an error in the received packets over the air. Basically, It provides data integrity check in the Link Layer.

3. Host Controller Interface(HCI) : The HCI layer is a thin layer which transports commands and events between the host and controller layers of the BLE protocol stack. The HCI is implemented through a transport protocol such as SPI or UART. This can be utilized for dual-chip implementation, where the host and application runs on another platform. The nRF5x chip , in this case, acts purely as a controller. This style is followed by the zephyr RTOS by the Linux Foundation. In our course, we follow a single-chip implementation approach where the host+controller (implemented by the SoftDevice/hardware) + application are all implemented on a single chip (nRF5x chip).

Host

1. Logical Link Control and Adaptation Layer Protocol (L2CAP) : The L2CAP provides multiplexing for the higher layers. This enables protocols like the Attribute Protocol (ATT) and the Security Manager Protocol (SMP) to share the same BLE Controller(Link Layer and PHY). This layer is also responsible for segmentation, and reassembly operation for packets exchanged between the upper layers and the BLE Controller. Through the segmentation/reassemble feature , the L2CAP allows higher-level protocols and applications to transmit and receive upper layer data packets (L2CAP service data units, SDU) up to 64KB long.

2. Security Manager Protocol(SMP) : responsible for enabling security for applications running over BLE. It provides the following types of services:

• Device Authentication.
• Device Authorization.
• Device privacy.
• Data Integrity.
• Data Confidentiality.
• Data privacy.

3. Attribute Protocol (ATT): We rarely interact with this layer directly, instead we use the structured and abstracted GATT (covered next and thoroughly in Lesson 2 ). ATT is a simple client/server protocol based on attributes presented by a device. It defines how to transfer a unit of data (attribute). Usually, a client requests data from a server, and the server then sends data to the client. A server can also initiate a data transfer using what is known as indication and notification. Each ATT server contains data organized in the form of a flat table of attributes. An Attribute is the basic unit of data in both ATT, and hence GATT. It is a pretty much a key-values pair, similar to Python dictionaries, and associative arrays in C++.

An Attribute has four components (aka fields) :

• Handle: This is the key of the attribute that we can address the attribute with. It is a 16-bit value (0x0001 – 0xFFFF) assigned by the SoftDevice to an attribute to uniquely identify it among other attributes in the table.
• UUID: A Universally Unique Identifier, this is used to specify the type of the attribute. The UUID is either a standard Bluetooth UUID ( 16 bits, aka BLE_UUID_TYPE_BLE ) or a vendor-specific UUID (128 bits, aka BLE_UUID_TYPE_VENDOR_BEGIN ).
• Permissions: As the name implies, this field dictates the access permissions and the security level of the attribute. This enables fine-grained security enforcement.
• Value: The actual data content of the attribute.

The following two layers GATT(Data) and GAP(Control) are the layers we interact the most in the Bluetooth Low Energy stack(SoftDevice), as they provide thorough abstraction for the underlying layers. They are the focus of the next lesson, however, a brief introduction is provided here.

4. Generic Attribute Profile (GATT): This is one of the most frequently interacted with layer of the BLE stack. It further simplifies the process of exchanging data over a BLE connection. It is implemented on top of the ATT and uses it as its transport layer. Attributes in GATT are no longer laid out flat, instead they are now organized hierarchically as follows.

• Service: Group of characteristics.
• Characteristic: The actual data containers. Ex: heart rate value.
• Descriptor: Additional optional metadata of the characteristic. Ex: the unit of the characteristic (Beats per minute).

In other words, each service contains one or more characteristics, and each characteristic is a union of user data along with descriptive information(metadata).

We will study GATT , including services, characteristics, and descriptors in-depth in the next lesson.

5. Generic Access Profile (GAP): This layer defines procedures on how devices discover and connect. It also provides an upper simplified layer to the SMP for pairing , creating bonds and ensuring privacy. Through this layer we can configure the link layer to define different device roles as we will see in-depth in the following lesson :

• Peripheral (Link Layer Slave).
• Central (Link Layer Master).
• Broadcaster(Link Layer Advertiser).
• Observer (Link Layer Scanner).

Note that these roles rely on the LL roles covered previously, but they are not the same. In general, a GAP role is fixed in the design stage of the device and it imposes the other end to be in a complement pair(Broadcaster/ Observer or Central/Peripheral) to be able to communicate .

Lesson 1 – Exercises

Enroll to the Intermediate course to access full content.

References and pictures:
Nordic Semiconductor http://www.nordicsemi.com