PolarSPARC |
Introduction to Bluetooth Low Energy (BLE)
Bhaskar S | 11/26/2022 |
Overview
Bluetooth Low Energy (or BLE for short) standard was added to the Bluetooth Core Specification in version 4.0. Bluetooth Low Energy, as the name indicates, is a short-range, interoperable, wireless connectivity standard for small battery-operated devices with low power consumption and intermittent data transfer needs. This standard is different from the core Bluetooth Classic standard, which is commonly used for connectivity of higher bandwidth needs, such as the headphones, speakers, smartphones, laptops, etc.
BLE uses the 2.4 GHz Industrial Scientific Medical (ISM) frequency radio spectrum since it has no licensing requirements. However, the 2.4 GHz radio spectrum has some challenges relating to poor propagation charateristics due to absorption of the radio signals by some elements like water.
The BLE radio spectrum is divided into 40 frequency channels, each of 2 Mhz frequency. The maximum supported data transfer rate is in the range 1 Mbps to 2 Mbps. Also, the maximum support distance (range) is between 30 feet to 100 feet.
Architecture Stack
The following illustration shows the high-level architecture of BLE:
The architecture stack is divided into thre core layers which are as follows:
Controller :: the physical hardware that operates at the ISM band and is responsible for the actual transmit and/or receive of the radio signals through the 40 radio frequency channels
Host :: the software layer that interfaces with the Controller and is responsible for how two or more devices communicate with one another
Application(s) :: the software layer that enables developers to build applications to tackle specific use-cases
We will delve a little more into the different layers of the architectural stack as follows:
Physical Layer :: the hardware layer that is responsible for transmitting and receiving bits as electromagnetic radio waves using the 2.4 GHz ISM frequency band that is split into 40 separate radio frequency channels, each 2 MHz apart from one another
The following illustration shows the BLE 40 radio frequency channels:
The three channels 37, 38, and 39 are referred to as the Primary Advertising Channels and the remaning channels 0 through 36 are referred to as the Secondary Advertising Channels
Link Layer :: is the most complex part of the architecture stack and the is responsible for advertising, scanning, creating and maintaining connections. It defines the data packet formats for transmission, bit stream processing, and error checking.
This layer provides support for both connectionless and connection-oriented communication.
Every BLE device has an associated 48-bit device address, which is similar to a MAC address.
Any BLE device can operate in one of the following states:
Standby :: the default state in which no data is either transmitted or received
Advertising :: a device sends out advertising packets for other devices to discover it
Scanning :: a device scans for other dvices that are sending out advertising packets
Initiating :: a scanning device decides to establish a connection with a device that is sending out advertising packets
Connected :: a device has established a connection with another device and is exchanging data at regular intervals
The device that initiates and establishes a connection is called the Master and the device that was sending out advertising packets is called the Slave
Host Controller Interface :: allows for communication between the Host and the Controller using well-defined functional interfaces. It allows a Host to send commands and data to the Controller and the Controller to send events and data to the Host
Logical Link Control and Adaptation Protocol :: is responsible for channel multiplexing, flow control, and data packet segmentation/reassembly
Security Manager Protocol :: manages all the security aspects of a device and is responsible for the following aspects:
Pairing :: the process of generating a shared secret key between two devices
Bonding :: the process of storing the generated shared key on both sides of the two communicating devices
Authentication :: the process of verifying the two communicating devices share the same secret key
Encryption :: the process of encrypting the data exchanged between the two communicating devices using the shared secret key
Data Integrity :: the process of ensuring data has not been altered or corrupted during the data exchange
Attribute Protocol :: ATT for short, it defines how data elements (referred to as the Attributes) are structured and exchanged between two communicating devices, with one device acting as a client and the other as a server.
The device that exposes the set of data elements is known the Server, while the device that connects to the Server for the purposes of reading the exposed data or for controlling the behavior of the Server is known as the Client.
Every Attribute is made up of the following items:
Attribute Type :: a 16-bit industry assigned, pre-defined UUID, such as battery level, latitude, longitude, temperature, etc. It is a 128-bit UUID for non-standard, custom types
Attribute Handle :: a 16-bit identifier assigned by the Server and used by the Client to reference that Attribute
Attribute Value :: a variable length Attribute value
Attribute Permissions :: the permissions associated with the Attribute to determine if that Attribute can be read or written to
Generic Attribute Profile :: GATT for short, is a higher level abstraction over Attributes and is used to define generic functionality, which encompasses the following core concepts:
Profile :: a well-defined set of functional procedures that define how two devices can connect with each other to discover and use functionality. They are an embodiment of a use-case
Characteristic :: represents a data Attribute, along with some metadata information (referred to as the Descriptor)
Service :: a collection of one or more related Attributes and Characteristics that support a particular functionality on the Server device. For example, a Location service includes the Attributes related to the Latitude and Longitude. They are akin to standard services in the TCP world such as SMTP, SSH, etc.
Just like the Attribute, each industry defined Service (such has Battery Level Service) has a 16-bit pre-defined UUID OR a 128-bit UUID for non-standard, custom Services
Generic Access Profile :: defines a standard framework and procedures related to device discovery and establishment of connections between two devices. The implementation of the standard framework is what enables how two devices discovery, connect, and communicate with one another to exchange data. This layer defines the different roles a device can play which are as follows:
Broadcaster :: a device that only contains a transmitter and periodically broadcasts advertising data packets in a connectionless manner. It does not allow any connection from another device
Observer :: a device that only contains a receiver and is able to discovers devices by receiving advertising data packets in a conecctionless manner. It does not have the capability to initiate a connection with the advertiser
Peripheral :: a device that contains both the transmitter and receiver and announces its presence by broadcasting advertising packets. It is able to accept a connection from another device
Central :: a device with both the transmitter and receiver that is able to discover and listen to other devices that are sending advertising data packets. It is also capable of establishing a connection with the Peripherals
BLE Packet
Every BLE packet has the following format:
The fields in the BLE packet are described as follows:
Preamble :: the first bit are always set to either 01010101 or 10101010. This is so that the receiver can synchronize and determine the frequencies for a 0 and a 1. The Advertising packet always use 10101010, while the data packets use 10101010 if least significant bit of Access Address is a 0 and 01010101 if least significant bit of Access Address is a 1
Access Address :: they are of two types - Advertising Access Address or Data Access Address. The Advertising Access Address in all advertising packets use a fixed value of 0x8E89BED6. For Data Access Address in the data packets, it consists of 32 bit random value (which follow specifc rules) generated by BLE device in Initiating state. The same value of the Data Access Address is used once a connection is established and helps in correlation of data packets
Header(s) :: the header is further broken down as follows:
The Packet Type is the most important and can have values as follows:
Type Value | Flag | Description |
---|---|---|
0000 | ADV_IND | Connectable undirected |
0001 | ADV_DIRECT_IND | Connectable directed |
0010 | ADV_NONCONN_IND | Non-connectable undirected |
0011 | SCAN_REQ | Active scanning request |
0100 | SCAN_RSP | Active scanning response |
0101 | CONNECT_REQ | Connection request |
0110 | ADV_SCAN_IND | Scannable undirected |
For Tx Addr Type and Rx Addr Type, a value of 0 means public address (assigned by the Bluetooth organization) and a value of 1 means random private address
Length(s) :: for advertising packets, the length field is 6 bits in size with valid values from 6 through 37. For data packets, on the other hand the length field is 5 bits in size with valid values from 0 through 31
Payload(s) :: the actual data (be it advertising or service) being transmitted
CRC(s) :: used for error checking and is calculated over the Header, the Length, and the Payload fields
High-Level Functionality
In the Advertising state, a device transmits advertising packets containing some relevant and useful information, such as the local name of the device, whether another device can connect to this device, a list of Service UUIDs supported by this device, etc.
As was indicated above in Figure.2, there are three Primary Advertising channels - 36, 37, and 38 that a device will start advertising on them. The size of the advertising data is limited to about 31 bytes.
Note that only a Broadcaster or a Peripheral can transmit advertising packets.
An advertising packet can be one of several types, which are as follows:
Connectable and Scannable Undirected :: allows other devices to receive the advertising packets, send a scan request to the advertising device, and establish a connection with the advertising device
Connectable Undirected :: allows other devices to receive the advertising packets and establish a connection with the advertising device
Connectable Directed :: allows a SPECIFIC device to receive the advertising packets and establish a connection with the advertising device
Non-Connectable and Non-Scannable Undirected :: allows other devices to ONLY receive the advertising packets
Non-Connectable and Non-Scannable Directed :: allows a SPECIFIC device to ONLY receive the advertising packets
Scannable Undirected :: allows other devices to send a scan request to the advertising device to receive additional data
Scannable Directed :: allows a SPECIFIC device to send a scan request to the advertising device to receive additional data
A typical Advertising Interval is in the range of 20 ms to a maximum of 10 sec.
In order to receive the advertising packets, a device needs to tune into the three Primary Advertising channels one at a time. A device that listens for advertisements and then sends scan requests to the advertising device is said to be in a Active Scanning Mode. On the other hand, if the listening device does NOT send any scan requests to the advertising device, then it is said to be in Passive Scanning Mode.
Note that only a Central can transmit scan request packets.
A connection between two devices can happen when one device is a Peripheral and the other device is a Central. In order to make a connection, a Peripheral device needs to transmit connectable advertising packets. A Central device must be scanning for these connectable advertising packets on the thre Primary Advertising channels. Once a Central device reads a connectable advertising packet, it can initiate a connection request to the advertising Peripheral. Once a connection is established between a Peripheral and a Central, the Peripheral can receives requests for a Service and the Peripheral can send a response related to the Service back to the Central using the Secondary Adevertising channels.
The following illustration depicts the interaction flow between a Peripheral and a Central:
References