How does Bluetooth Low Energy work?

Bluetooth Low Energy is one of the two radios defined by the Bluetooth Core Specification; the other is Bluetooth Classic. The Bluetooth SIG’s LE Primer says that being highly efficient with energy was one of the original design goals, aimed at devices running from small coin-cell batteries. Android’s documentation puts it the same way: compared with Classic Bluetooth, BLE is designed for significantly lower power consumption.

Much of how BLE works follows from that goal. Radio activity happens in short, scheduled events, such as advertising events and connection events, and the Primer describes connection settings that keep a link at a low duty cycle, with the radio unused in skipped events. The design is also deliberately asymmetric: the Primer explains that a device with a plentiful power source, such as a smartphone, does more of the heavy lifting than a peer running on a coin cell.

BLE operates in the unlicensed 2.4 GHz band, which the SIG gives as 2400 to 2483.5 MHz. It divides that band into 40 channels, each 2 MHz wide, and gives them two jobs:

• Three primary advertising channels, numbered 37, 38 and 39, carry the short packets devices use to announce themselves.
• Thirty-seven general-purpose channels carry the data of connections, and with extended advertising, most advertising data too.

Connected devices do not stay on one channel. They use adaptive frequency hopping: at each connection event both devices switch to a channel chosen by a shared algorithm, and channels that perform badly, for example because of interference, can be marked unused so the algorithm avoids them.

Range varies widely. The SIG states that the effective, reliable range between Bluetooth devices is “anywhere from more than a kilometer down to less than a meter”, set by the radio mode in use, receiver sensitivity, transmit power, antenna design and what lies between the devices.

Before two devices can talk, one has to know the other exists. BLE solves this with advertising. A device in the advertising state transmits small packets on the advertising channels, at regular intervals with a small random delay added each time so that nearby advertisers do not keep colliding. Apple’s documentation describes an advertising packet as a relatively small bundle of data that may say what the device offers, such as its name and main function.

Another device in the scanning state listens on those channels. Scanning is how a phone builds a list of nearby devices. Advertising can also carry data on its own, without any connection: the SIG’s Generic Access Profile defines a Broadcaster role that sends data in advertisements and an Observer role that only receives them.

Advertisements are public. The Primer notes that even a device advertising in non-discoverable mode is visible over the air, and that this is not a security feature.

To exchange data in both directions, two devices form a connection. A scanning device that wants to connect responds to an advertisement with a connection request on the same channel. In the link layer’s terms, the device that initiates the connection takes the Central role, and the advertising device that accepts it takes the Peripheral role.

Once connected, the two devices meet at regular connection events set by a connection interval. The Central may transmit first, and the two take turns sending and receiving. A Peripheral can be allowed to skip a number of connection events to save power.

Roles matter for phone apps. Android’s documentation points out that two devices that only support the peripheral role cannot talk to each other, and neither can two that only support the central role. Phone-to-phone BLE works because a phone can take the peripheral role as well as the central one; Apple’s documentation, for example, says iOS devices can act as peripherals serving data to other devices, including other iPhones. What is a BLE central and a BLE peripheral? goes into the details.

Connected devices exchange data through the Generic Attribute Profile (GATT), which is built on the Attribute Protocol (ATT). One device acts as a GATT server holding data, and the other as a client that reads and writes it.

• A characteristic holds a single value, plus optional descriptors that describe it, such as a unit of measure.
• A service groups related characteristics, such as a heart rate service containing a heart rate measurement.
• Each service, characteristic and descriptor type is identified by a UUID.

A server can also push changes to a client. Notifications are sent without any reply, while indications ask the client to confirm receipt.

The GATT roles are separate from the connection roles. In Android’s example, a phone acts as central and GATT client while a fitness tracker acts as peripheral and GATT server, but the app could equally make the phone the GATT server. What are GATT services and characteristics? covers the data model.

Both major phone platforms build their BLE APIs on these concepts. Android provides built-in support for the central role and APIs for scanning, connecting to a GATT server and transferring data, and also lets an app run a GATT server. Apple’s Core Bluetooth framework represents the local central and peripheral roles with CBCentralManager and CBPeripheralManager, and supports iPhones acting as peripherals for other devices.

One caution from Android’s documentation is worth keeping in mind: once two devices are paired, data exchanged between them is accessible to all apps on the device, so apps handling sensitive data should add their own app-layer security.