Bluetooth Low Energy (BLE) is a low power wireless technology used for connecting devices with each other. BLE operates in the 2.4 GHz ISM (Industrial, Scientific, and Medical) band, and is targeted towards applications that need to consume less power and may need to run on batteries for longer periods of time—months, and even years.
Bluetooth started as a short-distance cable replacement technology. For example, to replace wires in devices such as a mouse, keyboard, or a PC communicating with a Personal Digital Assistant (PDA) which were popular in the late 1990s and early 2000s. The first official version of Bluetooth was released by Ericsson in 1994, named after King Harald “Bluetooth” Gormsson of Denmark who helped unify warring factions in the 10th century CE.
Bluetooth Low Energy (BLE), however, was introduced in the 4.0 version of the Bluetooth specification in 2010. The original Bluetooth defined in the previous versions is referred to as Bluetooth Classic. BLE was not an upgrade to the original Bluetooth: Bluetooth Classic, but rather it’s a new technology that utilizes the Bluetooth brand but focuses on the Internet of Things (IoT) applications where small amounts of data are transferred at lower speeds. It’s important to note that there’s a big difference between Bluetooth Classic and Bluetooth Low Energy in terms of technical specification, implementation and the types of applications they’re each suitable for.
Some of the notable differences include:
- Bluetooth Classic: used for streaming applications such as audio streaming and file transfers.
- BLE: used for sensor data, control of devices, and low-bandwidth applications.
- BLE: low power, low duty data cycles.
- Bluetooth Classic: not optimized for low power, has a higher data rate.
- BLE: Operates over 40 RF (Radio Frequency) channels.
- Bluetooth Classic: Operates over 79 RF channels.
- BLE: connections are much quicker (discovery occurs on 3 channels).
- Bluetooth Classic: discovery on 32 channels, leading to slower connections.
BLE has gone through some major revisions and changes in the short time since its official release in 2010, with the most recent major update being Bluetooth 5 in December 2016. Bluetooth 5.0 introduced many important upgrades to the Bluetooth specification, most of which were focused on BLE. Some of the most important enhancements include twice the speed, four times the range, and eight times the advertising data capacity.
Advantages and Disadvantages
Every technology has its own benefits and limitations, and BLE is no exception. It’s important to know these pros and cons to be able to determine whether BLE is suitable for your specific application and use case or not.
Benefits of BLE
- Lower power consumption even when compared to other low power technologies. BLE achieves the optimized and low power consumption by keeping the radio off as much as possible and sending small amounts of data at low transfer speeds.
- No cost to access the official specification documents. With most other wireless protocols and technologies, you would have to be a member of the official group or consortium for that technology in order to access the specification.
- Lower cost of modules and chipsets, even when compared to other similar technologies.
- Most importantly, its existence in most smartphones in the market.
Limitations of BLE
- Data Throughput: the data throughput of BLE is limited by the physical radio layer (PHY) data rate, which is the rate at which the radio transmits data. This rate depends on the Bluetooth version used. For Bluetooth 4.2 and earlier, the rate is fixed at 1 Mbps. For Bluetooth 5 and later, however, the rate varies depending on the mode and PHY used. The rate can be 1 Mbps like earlier versions, or 2 Mbps when utilizing the high-speed feature.
- Range: Bluetooth Low Energy (and Bluetooth in general) was designed for short range applications and hence its range of operation is limited. There are a few factors that limit the range of BLE:
- BLE operates in the 2.4 GHz ISM spectrum which is greatly affected by obstacles that exist all around us such as metal objects, walls, and water (especially human bodies)
- Performance and design of the antenna of the BLE device.
- Physical enclosure of the device.
- Device orientation.
- Gateway Requirement for Internet Connectivity: In order to transfer data from a BLE-only device to the Internet, another BLE device that has an IP connection is needed to receive this data and then, in turn, relay it to another IP device (or to the Internet).
Bluetooth Low Energy Architecture
Here’s a diagram showing the different levels of the architecture of BLE:
The good thing is that, as a developer looking to develop BLE applications, you won’t have to worry much about the layers below the Security Manager and Attribute Protocol. But lets at least cover the definitions of these layers:
- The physical layer (PHY) refers to the physical radio used for communication and for modulating/demodulating the data. It operates in the ISM band (2.4 GHz spectrum).
- The Link Layer is the layer that interfaces with the Physical Layer (Radio) and provides the higher levels an abstraction and a way to interact with the radio (through an intermediary level called the HCI layer which we’ll discuss shortly). It is responsible for managing the state of the radio as well as the timing requirements for adhering to the Bluetooth Low Energy specification.
- Direct Test Mode: the purpose of this mode is to test the operation of the radio at the physical level (such as transmission power, receiver sensitivity, etc.).
- The Host Controller Interface (HCI) layer is a standard protocol defined by the Bluetooth specification that allows the Host layer to communicate with the Controller layer. These layers could exist on separate chips, or they could exist on the same chip.
- The Logical Link Control and Adaptation Protocol (L2CAP) layer acts as a protocol multiplexing layer. It takes multiple protocols from the upper layers and places them in standard BLE packets that are passed down to the lower layers beneath it.
The Generic Access Profile (GAP)
So, what is GAP anyway?
GAP stands for Generic Access Profile. It provides a framework that defines how BLE devices interact with each other. This includes:
- Roles of BLE devices
- Advertisements (Broadcasting, Discovery, Advertisement parameters, Advertisement data)
- Connection establishment (initiating connections, accepting connections, Connection parameters)
The different roles of a BLE device are:
- Broadcaster: a device that sends out Advertisements and does not receive packets or allow Connections from others.
- Observer: a device that listens to others sending out Advertising Packets, but does not initiate a Connection with the Advertising device.
- Central: a device that discovers and listens to other devices that are Advertising. A Central also has the capability of connecting to an Advertising device.
- Peripheral: a device that Advertises and accepts Connections from Central devices.
Keep in mind that a single device may operate in multiple Roles at the same time. For example, your smartphone can operate in the Central role when communicating with your smartwatch, and also act in the Peripheral role while communicating with a PC.
In the Advertising state, a device sends out packets containing useful data for others to receive and process. The packets are sent at a fixed interval defined as the Advertising Interval. There are 40 RF channels in BLE, each separated by 2 MHz (center-to-center), as shown in the following figure. Three of these channels are called the Primary Advertising Channels, while the remaining 37 channels are used for Secondary Advertisements and for Data Packet transfer during a Connection.
Advertisements always start with Advertisement Packets sent on the 3 Primary Advertising Channels (or a subset of these Channels). This allows Centrals to find the Advertising device (Peripheral or Broadcaster) and parse its Advertising packets. The Central can then Initiate a Connection if the Advertiser allows it (Peripheral devices).
Centrals tune into the three Primary Advertising Channels one at a time. So, in order for a Central to discover a Peripheral, the Central has to be tuned into the same channel that the Peripheral is Advertising on at that given point. To increase the possibility of this happening, and in order to make it happen quickly, the different advertising and scanning parameters can be adjusted.
In order for two BLE devices to connect to each other, the following needs to happen:
- The Peripheral needs to start Advertising and send out Connectable Advertisement packets.
- The Central device needs to be Scanning for Advertisements while the Peripheral is Advertising.
- If the Central happens to be listening on an Advertising Channel that the Peripheral is Advertising on, then the Central device discovers the Peripheral and is able to read the Advertisement packet and all the necessary information in order to establish a Connection.
- The Central then sends a Connection Request packet.
- The peripheral always listens for a short interval on the same Advertising Channel after it sends out the Advertising packet. This allows it to receive the Connection Request packet from the Central device — which triggers the forming of the Connection between the two devices.
After that, the Connection is considered “created ”, but not yet “established ”. A Connection is considered “established ” once the device receives a packet from its peer device. After a Connection becomes established, the Central becomes known as the Master, and the Peripheral becomes known as the Slave. The Master is responsible for managing the Connection, controlling the Connection Parameters and the timing of the different events within a Connection.
During a Connection Event, the Master and Slave alternate sending data packets to each other until neither side has data to send. Here are a few aspects of Connections that are very important to know:
- A Connection Event contains at least one packet sent by the Master.
- The Slave always sends a packet back if it received a packet from the Master.
- If the Master does not receive a packet back from the Slave, the Master will close the Connection Event — it resumes sending packets at the next Connection Event.
- The Connection Event can be closed by either side.
- The starting points of consecutive Connection Events are spaced by a period of time called the Connection Interval.
The most important parameters that define a Connection include:
- Connection Interval: the interval at which two connected BLE devices wake up the radio and exchange data (at each Connection Event).
- Slave Latency: this value allows the Peripheral to skip a number of consecutive Connection Events and not listen to the Central at these Connection Events without compromising the Connection. For example, a Slave Latency of 3 allows a Slave to skip 3 Connection Events and a value of 0 means that the Slave has to send data to the Master at every Connection Event.
- Supervision Timeout: the maximum time between two received data packets before the Connection is considered lost.
The Generic Attribute Profile (GATT)
The main reason to connect two BLE devices to each other is to transfer data between them. Without a Connection, it is not possible to have a bidirectional data transfer between two BLE devices.
Which brings us to the concept of GATT… so what the heck is GATT?!
The Generic Attribute Profile (GATT) defines the format of the data exposed by a BLE device. It also defines the procedures needed to access the data exposed by a device.
There are two Roles within GATT: Server and Client. The Server is the device that exposes the data it controls or contains, and possibly some other aspects of its behavior that other devices may be able to control. A Client, on the other hand, is the device that interfaces with the Server with the purpose of reading the Server’s exposed data and/or controlling the Server’s behavior.
Keep in mind that a BLE device can act as the Server and a Client at the same time. Simply put, it acts as the Server for the sake of exposing its own data, and as a Client when accessing another device’s data.
Services and Characteristics
Services and Characteristics are probably the two most used terms in BLE! That’s why understanding them is crucial, especially for BLE devices that establish a connection with each other.
…but that doesn’t mean they have to be complicated.
On the contrary, they are very simple and easy to understand!
To better understand GATT, we need to cover a few important concepts (including Services and Characteristics):
- Attributes: a generic term for any type of data exposed by the Server and defines the structure of this data. For example, Services and Characteristics (both defined below) are types of Attributes.
- Services: a grouping of one or more Attributes (some of which are Characteristics). It’s meant to group together related Attributes that satisfy a specific functionality on the Server. For example, the SIG-adopted Battery Service contains one Characteristic called the Battery Level.
- Characteristics: a Characteristic is always part of a Service and it represents a piece of information/data that a Server wants to expose to a client. For example, the Battery Level Characteristic represents the remaining power level of a battery in a device which can be read by a Client.
- Profiles: Profiles are much broader in definition from Services. They are concerned with defining the behavior of both the Client and Server when it comes to Services, Characteristics and even Connections and security requirements. Services and their specifications, on the other hand, deal with the implementation of these Services and Characteristics on the Server side only.
A simplified representation of a Service:
In BLE, there are six types of operations on Characteristics:
- Commands: sent by the Client to the Server and do not require a Response (defined below). One example of a Command is a Write Command, which does not require a Response from the Server.
- Requests: sent by the Client to the Server and require a Response. Some examples of Requests include: Read Requests and Write Requests.
- Responses: sent by the Server in response to a Request.
- Notifications: sent by the Server to the Client to let the Client know that a specific Characteristic Value has changed. In order for this to be triggered and sent by the Server, the Client has to enable Notifications for the Characteristic of interest. Note that a Notification does not require a Response from the Client to acknowledge its receipt.
- Indications: sent by the Server to the Client. They are very similar to Notifications but require an acknowledgment to be sent back from the Client to let the Server know that the Indication was successfully received.
Note: Notifications and Indications are exposed via the Client Characteristic Configuration Descriptor (CCCD) Attribute. Writing a “1” to this Attribute value enables Notifications, whereas writing a “2” enables Indications. Writing a “0” disables both Notifications and Indications.
- Confirmations: sent by the Client to the Server. These are the acknowledgment packets sent back to the Server to let it know that the Client received an Indication successfully.
We’ve barely scratched the surface on BLE and the ins and outs of the technology!
If you’re interested in learning more about BLE including:
- More detailed information about the different roles of BLE devices.
- How to design your device’s GATT, services, and characteristics.
- Security in BLE.
- Bluetooth 5 and its exciting new features that achieve 2x the speed, 4x the range, and 8x the advertising capacity.
- An introduction to Bluetooth mesh and how it works
- and more!
… then check out my e-book “Intro to Bluetooth Low Energy“: