Bluetooth Low Energy (BLE) tutorial
Bluetooth Low Energy (Bluetooth LE, BLE, marketed as Bluetooth Smart) is a wireless personal area network technology designed and marketed by the Bluetooth Special Interest Group aimed at novel applications in the healthcare, fitness, beacons, security, and home entertainment industries. Compared to Classic Bluetooth, Bluetooth Smart is intended to provide considerably reduced power consumption and cost while maintaining a similar communication range.
BLE Architecture
Table shows the wireless technologies implemented for the three main device types on the market today.
Device
|
BR/EDR (classic Bluetooth) support
|
BLE (Bluetooth Low Energy) support
|
Pre-4.0
Bluetooth
|
Yes
|
No
|
4.x
Single-Mode (Bluetooth Smart)
|
No
|
Yes
|
4.x
Dual-Mode (Bluetooth Smart Ready)
|
Yes
|
Yes
|
As you can see, the Bluetooth Specification (4.0 and above) defines two wireless technologies:
- BR/EDR (classic Bluetooth)
The wireless standard that has evolved with the Bluetooth Specification since 1.0.
- BLE (Bluetooth Low Energy)
The low-power wireless standard introduced with version 4.0 of the specification.
And these are the two device types that be used with these configurations:
- Single-mode (BLE, Bluetooth Smart) device
A device that implements BLE, which can communicate with single-mode and dual-mode devices, but not with devices supporting BR/EDR only.
- Dual-mode (BR/EDR/LE, Bluetooth Smart Ready) device
A device that implements both BR/EDR and BLE, which can communicate with any Bluetooth device.
So, in practice, a typical best-case scenario should probably assume a potential maximum data throughpout in the neighborhood of 5-10 KB per second, depending on the limitations of both peers.
It’s possible to create and configure a BLE device that can reliably transmit data 30 meters or more line-of-sight, but a typical operating range is probably closer to 2 to 5 meters, with a conscious effort to reduce the range and save battery life without the transmission distance becoming a nuisance to the end user.
A Bluetooth Low Energy device can communicate with the outside world in two ways: broadcasting or connections.
The standard advertising packet contains a 31-byte payload used to include data that describes the broadcaster and its capabilities, but it can also include any custom information you want to broadcast to other devices. If this standard 31-byte payload isn’t large enough to fit all of the required data, BLE also supports an optional secondary advertising payload (called the Scan Response), which allows devices that detect a broadcasting device to request a second advertising frame with another 31-byte payload, for up to 62 bytes total.
The standard advertising packet contains a 31-byte payload used to include data that describes the broadcaster and its capabilities, but it can also include any custom information you want to broadcast to other devices. If this standard 31-byte payload isn’t large enough to fit all of the required data, BLE also supports an optional secondary advertising payload (called the Scan Response), which allows devices that detect a broadcasting device to request a second advertising frame with another 31-byte payload, for up to 62 bytes total.
A connection is a permanent, periodical data exchange of packets between two devices. It is therefore inherently private (the data is sent to and received by only the two peers involved in a connection, and no other device unless it’s indiscriminately sniffing).
Connections involve two separate roles:
- Central (master)
Repeatedly scans the preset frequencies for connectable advertising packets and, when suitable, initates a connection. Once the connection is established, the central manages the timing and initiates the periodical data exchanges.
- Peripheral (slave)
A device that sends connectable advertising packets periodically and accepts incoming connections. Once in an active connection, the peripheral follows the central’s timing and exchanges data regularly with it.
- Profiles
“Vertical slices” of functionality covering either basic modes of operation required by all devices (Generic Access Profile, Generic Attribute Profile) or specific use cases (Proximity Profile, Glucose Profile), profiles essentially define how protocols should be used to achieve a particular goal, whether generic or specific.
GENERIC PROFILES
Generic profiles are defined by the specification, and it’s important to understand how two of them are fundamental to ensuring interoperability between BLE devices from different vendors:
- Generic Access Profile (GAP)
Covering the usage model of the lower-level radio protocols to define roles, procedures, and modes that allow devices to broadcast data, discover devices, establish connections, manage connections, and negotiate security levels, GAP is, in essence, the topmost control layer of BLE. This profile is mandatory for all BLE devices, and all must comply with it.
- Generic Attribute Profile (GATT)
Dealing with data exchange in BLE, GATT defines a basic data model and procedures to allow devices to discover, read, write, and push data elements between them. It is, in essence, the topmost data layer of BLE.
Each of these basic building blocks of the protocol stack is split into several layers that provide the functionality required to operate:
Application
The application, like in all other types of systems, is the highest layer and the one responsible for containing the logic, user interface, and data handling of everything related to the actual use-case that the application implements. The architecture of an application is highly dependent on each particular implementation.
Host
Includes the following layers:
- Generic Access Profile (GAP)
The Generic Access Profile (GAP) dictates how devices interact with each other at a lower level, outside of the actual protocol stack. GAP can be considered to define the BLE topmost control layer, given that it specifies how devices perform control procedures such as device discovery, connection, security establishment, and others to ensure interoperability and to allow data exchange to take place between devices from different vendors.
- Generic Attribute Profile (GATT)
The Generic Attribute Profile (GATT) builds on the Attribute Protocol (ATT) and adds a hierarchy and data abstraction model on top of it. In a way, it can be considered the backbone of BLE data transfer because it defines how data is organized and exchanged between applications.
It defines generic data objects that can be used and reused by a variety of application profiles (known as GATT-based profiles). It maintains the same client/server architecture present in ATT, but the data is now encapsulated in services, which consist of one or more characteristics. Each characteristic can be thought of as the union of a piece of user data along with metadata (descriptive information about that value such as properties, user-visible name, units, and more).
- Logical Link Control and Adaptation Protocol (L2CAP)
The rather cryptically named Logical Link Control and Adaptation Protocol (L2CAP) provides two main pieces of functionality. First, it serves as a protocol multiplexer that takes multiple protocols from the upper layers and encapsulates them into the standard BLE packet format (and vice versa).
For Bluetooth Low Energy, the L2CAP layer is in charge or routing two main protocols: the Attribute Protocol (ATT) and the Security Manager Protocol (SMP).
- Attribute Protocol (ATT)
- Security Manager (SM)
The Security Manager (SM) is both a protocol and a series of security algorithms designed to provide the Bluetooth protocol stack with the ability to generate and exchange security keys, which then allow the peers to communicate securely over an encrypted link, to trust the identity of the remote device, and finally, to hide the public Bluetooth Address if required to avoid malicious peers tracking a particular device.
The Security Manager defines two roles:
Initiator
Always corresponds to the Link Layer master and therefore the GAP central.
Responder
Always corresponds to the Link Layer slave and therefore the GAP peripheral.
SECURITY PROCEDURES
The Security Manager provides support for the following three procedures:
Pairing
The procedure by which a temporary common security encryption key is generated to be able to switch to a secure, encrypted link. This temporary key is not stored and is therefore not reusable in subsequent connections.
Bonding
A sequence of pairing followed by the generation and exchange of permanent security keys, destined to be stored in nonvolatile memory and therefore creating a permanent bond between two devices, which will allow them to quickly set up a secure link in subsequent connections without having to perform a bonding procedure again.
Encryption Re-establishment
After a bonding procedure is complete, keys might have been stored on both sides of the connection. If encryption keys have been stored, this procedure defines how to use those keys in subsequent connections to re-establish a secure, encrypted connection without having to go through the pairing (or bonding) procedure again.
- Host Controller Interface (HCI), Host side
Controller
Includes the following layers:
- Host Controller Interface (HCI), Controller side
The Bluetooth specification defines HCI as a set of commands and events for the host and the controller to interact with each other, along with a data packet format and a set of rules for flow control and other procedures. Additionally, the spec defines several transports, each of which augments the HCI protocol for a specific physical transport (UART, USB, SDIO, etc.).
- Link Layer (LL)
The Link Layer is the part that directly interfaces with the PHY, and it is usually implemented as a combination of custom hardware and software.
- Physical Layer (PHY)
The physical (PHY) layer is the part that actually contains the analog communications circuitry, capable of modulating and demodulating analog signals and transforming them into digital symbols.
ADVERTISING AND SCANNING
BLE has only one packet format and two types of packets (advertising and data packets), which simplifies the protocol stack implementation immensely. Advertising packets serve two purposes:
- To broadcast data for applications that do not need the overhead of a full connection establishment
- To discover slaves and to connect to them
0 comments:
Post a Comment