Bluetooth Low Energy (LE)

Energy-efficient Bluetooth for IoT and sensor applications.

The Rise of the Connected Device: Why Bluetooth LE was Born

While Bluetooth Classic brilliantly solved the problem of wireless audio streaming and continuous data transfer, the dawn of the 21st century brought a new technological revolution: the Internet of Things (IoT). Suddenly, the world envisioned a future where everyday objects could become "smart". Thermostats, light bulbs, fitness trackers, medical sensors, and countless other small devices needed a way to communicate wirelessly. However, their needs were fundamentally different from those of a wireless headset.

These new devices did not need to stream megabytes of data every second. Instead, they needed to send tiny packets of information intermittently: a temperature reading every few minutes, a heart rate update every second, a simple "on" or "off" command for a light. Most importantly, these devices needed to run for months, or even years, on a single, tiny coin-cell battery. Using Bluetooth Classic for such applications would be like using a fire hose to water a houseplant; its power consumption was simply too high for this new class of battery-sipping gadgets.

Recognizing this critical gap, the Bluetooth Special Interest Group (SIG) introduced Bluetooth Low Energy (LE) as part of the Bluetooth 4.0 specification in 2010. Bluetooth LE was not an evolution of Classic but a complete, ground-up redesign with one primary, overarching goal: extreme power efficiency. Its design philosophy is built around keeping the device's radio turned off for the maximum amount of time, only waking up for a few milliseconds to send or receive a small burst of data, and then immediately returning to a deep sleep state. This fundamental difference in architecture is what enables a whole new universe of connected devices, making the IoT a practical reality.

A Simpler, Smarter Radio: The Bluetooth LE Physical Layer

To achieve its remarkable power efficiency, Bluetooth LE employs a physical layer that, while sharing the same 2.4 GHz ISM band as its Classic counterpart, operates in a fundamentally different and more streamlined manner.

A Different Channel Layout

While Bluetooth Classic divides the 2.4 GHz spectrum into 79 channels each 1 MHz wide, Bluetooth LE uses a simpler scheme with 40 channels, each 2 MHz wide. This wider channel spacing makes the radios less susceptible to frequency drift and interference, allowing for simpler and less expensive hardware designs. These 40 channels are divided into two distinct types:

  • Advertising Channels (3 Channels): These are the "public broadcast" channels of the Bluetooth LE world. There are only three of them (Channels 37, 38, and 39). Their frequencies were strategically chosen to fall between the primary Wi-Fi channels (1, 6, and 11), minimizing the probability of direct interference. All device discovery, broadcasting of data, and connection initiation happens exclusively on these three channels. A device looking to connect only needs to listen on these three specific frequencies, rather than all 79, which drastically reduces power consumption during the discovery phase.
  • Data Channels (37 Channels): The remaining 37 channels (Channels 0 through 36) are used for bidirectional data transfer once a connection has been established. After two devices agree to connect on an advertising channel, they switch to the data channels and begin frequency hopping across these 37 channels in a synchronized pattern, similar to Bluetooth Classic, to maintain a robust connection.

Modulation and Data Rate

The standard modulation scheme for Bluetooth LE is the same as for Bluetooth Classic's Basic Rate: . At a symbol rate of 1 Msps, this yields a raw data rate of 1 Mbps. While Bluetooth 5 and later versions introduced options for a higher speed (2 Mbps) and a long-range coded mode, this foundational 1 Mbps rate is the baseline for all LE communication, providing a reliable and power-efficient method for transmitting short bursts of data.

Adaptive Frequency Hopping (AFH)

Like its Classic counterpart, LE uses to survive in the noisy 2.4 GHz environment. An LE device can continuously monitor the channels in its hopping map. If it detects that a certain channel is consistently noisy or occupied by another technology like Wi-Fi, it can communicate this to its connected peer, and both devices will remove that "bad" channel from their shared hopping sequence. This allows the connection to dynamically adapt to its radio environment, avoiding interference and maintaining a stable link.

New Roles for a New Paradigm: Central, Peripheral, and GATT

The Master/Slave architecture of Bluetooth Classic, designed for stable, one-to-one connections, was not flexible enough for the dynamic world of IoT. Bluetooth LE introduces a new set of roles and, most importantly, a standardized framework for data organization 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. It cannot initiate a connection itself; instead, it "advertises" its presence and the data services it offers, waiting for a Central device to connect to it. In the GATT framework, the Peripheral acts as the Server, because it "serves" data to a client.

The Central (GATT Client)

The Central is typically a more powerful device, like a smartphone, tablet, or computer. It is the device that wants the data. A Central device "scans" for advertising Peripherals and can choose to initiate a connection with one of them. In the GATT framework, the Central acts as the Client, because it requests data from the Server.

This model is highly efficient. A single Peripheral can advertise to many Centrals at once, and a single Central can be connected to multiple Peripherals simultaneously.

GATT: The Universal Language of LE Data

The is the heart of Bluetooth LE data exchange. It provides a universal, standardized way to structure and organize data on a Peripheral, making it understandable to any Central that connects. GATT is structured as a simple hierarchy:

  1. Profile: A high-level, pre-defined collection 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". This allows for plug-and-play interoperability.
  2. 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 unique number called a .
  3. 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: A set of permissions defining what a Central can do with it (e.g., Read, Write, Notify).
  4. 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: A Step-by-Step Guide

The entire lifecycle of a Bluetooth LE interaction, from discovery to data exchange, is meticulously designed for power efficiency.

Step 1: Advertising

A Peripheral (e.g., a smart thermostat) wanting to be discovered starts broadcasting short "advertising packets" periodically on the three advertising channels (37, 38, 39). These packets contain basic information like its name and the key services it offers, allowing a Central to decide if it wants to connect without wasting energy on a full inquiry.

Step 2: Scanning

A Central (e.g., a smartphone) wanting to connect enters a scanning state, where it briefly listens on the advertising channels for these broadcast packets. 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 crucial connection parameters, such as the , which defines how often the devices will wake up to communicate.

Step 4: Exchanging Data via GATT

Once connected, both devices switch to the data channels and begin frequency hopping. The smartphone's app will now explore the thermostat's GATT server to discover its 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 incredibly 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.

    Bluetooth Low Energy (LE) | Teleinf Edu