Bluetooth LE Introduction
Bluetooth Classic supported wireless audio streaming and continuous data transfer. At the beginning of the 21st century, the growth of the Internet of Things (IoT) increased the need for connectivity in small devices. Thermostats, light bulbs, fitness trackers, medical sensors, and other devices needed a way to communicate wirelessly. Their requirements differed from those of a wireless headset.
These devices did not need to stream megabytes of data every second. They sent small packets intermittently: a temperature reading every few minutes, a heart rate update every second, and a simple "on" or "off" command for a light. They needed to run for months or years on a single coin-cell battery. Bluetooth Classic would consume too much power for these applications.
To address these requirements, the Bluetooth Special Interest Group (SIG) introduced Bluetooth Low Energy (LE) in Bluetooth Core 4.0, dated 30 June 2010. LE was introduced as a separate radio and Link Layer variant alongside Bluetooth Classic BR/EDR while sharing architectural elements such as HCI. Its primary goal was low power consumption. In a typical cycle, the device's radio remains off for most of the time, wakes for a few milliseconds to send or receive a small packet, and then returns to sleep. This architecture supports IoT devices with intermittent data exchange.
The Bluetooth LE Physical Layer
Bluetooth LE uses a physical layer in the 2.4 GHz ISM band shared with Bluetooth Classic, but with separate channel, packet, and PHY parameters. Short packets and the ability to limit receiver active time support operation in battery-powered devices.
A Different Channel Layout
While Bluetooth Classic BR/EDR divides the 2.4 GHz spectrum into 79 channels each 1 MHz wide, Bluetooth LE uses 40 channels, each 2 MHz wide. LE channel center frequencies range from 2402 to 2480 MHz. These 40 channels are divided into primary advertising channels and general-purpose channels:
- Primary Advertising Channels (3 channels): These are channels 37, 38, and 39 used by legacy primary advertising. Their frequencies are positioned to limit overlap with commonly used Wi-Fi channels: channel 37 is before typical Wi-Fi channel 1, channel 38 is between channels 1 and 6, and channel 39 is after channel 11. Legacy discovery, data broadcasting, and connection initiation use these channels. Extended advertising can carry auxiliary data on channels 0 through 36.
- General-Purpose Channels (37 channels): Channels 0 through 36 carry bidirectional data after a connection is established and can also carry auxiliary extended-advertising data. After two devices establish a connection, they hop across the available data channels in a synchronized pattern. The channel map can exclude channels affected by interference from other systems.
Modulation and Data Rate
Bluetooth LE and Bluetooth Classic Basic Rate use , but their PHY parameters and packet formats are specified separately. Mandatory LE 1M uses a symbol rate of 1 Msym/s and provides a raw rate of 1 Mb/s. LE 2M is an optional 2 Mb/s PHY, while LE Coded provides 125 kb/s and 500 kb/s variants. Application throughput also depends on packet overhead, connection interval, and retransmissions.
Adaptive Frequency Hopping (AFH)
Like its Classic counterpart, LE uses to operate in the noisy 2.4 GHz environment. An implementation may classify channel conditions and communicate interference information to its peer. The devices can then update their shared channel map and skip a channel with poor conditions. This allows the connection to adapt to its radio environment and maintain a stable link.
GAP and GATT Roles: Central and Peripheral
Bluetooth LE uses the Central/Peripheral GAP roles alongside the older master/slave terminology found in Classic descriptions. GAP roles specify which device initiates or accepts a connection, while GATT Client/Server roles describe attribute exchange independently of GAP roles. Bluetooth LE uses a standardized data-organization framework called the Generic Attribute Profile (GATT).
The Peripheral (GATT Server)
The Peripheral is typically the small, battery-powered IoT device. It is the device that has the data. For example, a heart rate monitor is a Peripheral. In a typical configuration it accepts a connection from a Central and advertises its presence and data services. In the example GATT arrangement, the Peripheral acts as the Server because it provides data to a client; GAP and GATT roles remain independent.
The Central (GATT Client)
The Central is typically a device with more processing and energy resources, like a smartphone, tablet, or computer. It is the device that wants the data. A Central scans for advertising Peripherals and can initiate a connection. In the example GATT arrangement, the Central acts as the Client because it requests data from the Server; GATT roles can be combined with GAP roles according to device functions.
This model supports simultaneous connections. A controller may allow one Peripheral to advertise to many Centrals and one Central to maintain connections with multiple Peripherals simultaneously. The actual number of connections depends on controller resources and implementation.
GATT: LE Data Model and Procedures
The defines how a connected LE device exposes services, characteristics, descriptors, and procedures. A Central can discover these elements on a Peripheral and use them according to an application profile. GATT procedures use ATT, while an application profile specifies how the elements are used for a particular use case, so it is not an internal GATT hierarchy level:
- Application Profile:A high-level, pre-defined specification of services that together define a specific use case. For example, the "Heart Rate Profile" specifies that a device must contain a "Heart Rate Service". The profile uses GATT and enables plug-and-play interoperability.
- Service: A collection of related data points, called characteristics. A service is like a folder that groups together similar information. For instance, a "Heart Rate Service" would contain heart rate data, while a "Battery Service" would contain battery level information. Each service is identified by a .
- Characteristic:The actual data value. This is the core piece of information. A characteristic is like a file within the service folder. Examples include "Heart Rate Measurement" or "Battery Level". Each characteristic has:
- A Value: The actual data (e.g., the number
120). - A UUID: A unique identifier for that specific type of data.
- Properties: Flags describing supported operations such as Read, Write, Notify, and Indicate. Access permissions are defined separately.
- A Value: The actual data (e.g., the number
- Descriptor:Optional extra information that describes a characteristic, such as a human-readable description (e.g., "Beats per minute") or the valid range for its value.
The LE Connection Process
The entire lifecycle of a Bluetooth LE interaction, from discovery to data exchange, uses procedures that limit radio active time.
Step 1: Advertising
A Peripheral (e.g., a smart thermostat) wanting to be discovered periodically broadcasts short legacy primary advertising packets on channels 37, 38, and 39. Extended advertising can move part of the data to channels 0 through 36. The packets contain basic information such as the name and key services, allowing a Central to decide whether to connect.
Step 2: Scanning
A Central (e.g., a smartphone) wanting to connect enters a scanning state and briefly listens on the primary advertising channels and, when applicable, the auxiliary channels of extended advertising. The phone's app can then display a list of nearby devices that are advertising.
Step 3: Connecting
When the user selects the thermostat in the app, the smartphone (Central) sends a connection request packet to the thermostat (Peripheral). This packet includes connection parameters, such as the , which defines how often the devices will wake up to communicate. Intervals below the standard minimum require both devices to support Shorter Connection Intervals from Core 6.2.
Step 4: Exchanging Data via GATT
Once connected, both devices switch to the data channels and begin frequency hopping. The smartphone's app now discovers the thermostat's GATT services and characteristics (e.g., "Temperature Service" with a "Current Temperature" characteristic). The user can now interact with this data:
- Reading Data: The app sends a "read" request to get the current temperature from the thermostat.
- Writing Data: The user changes the target temperature in the app. The app sends a "write" command to the thermostat's "Target Temperature" characteristic, changing its setting.
- Subscribing with Notifications: The app can subscribe to the "Current Temperature" characteristic. Now, the thermostat will automatically send an update (a "notification" packet) to the phone whenever the temperature changes, without the phone having to ask. This is power-efficient compared to repeatedly polling for the value.
Step 5: Terminating
When the interaction is finished, either the Central or the Peripheral can send a command to terminate the connection. The Peripheral then returns to its advertising state, ready for a new connection.