Many developers assume there’s a steep learning curve when it comes to building software on top of Bluetooth. In practice, Bluetooth is much more approachable than it seems, and its core concepts are surprisingly close to the way we already think about APIs.
This article is a practical introduction to how Bluetooth works, focused on building the right mental model rather than diving into specifications or low-level details.
How bluetooth works
First of all, there are two types of Bluetooth technology: Bluetooth Low Energy (BLE, introduced in Bluetooth 4.0 and later versions) and Bluetooth Classic. Both operate using the same frequency band (between 2.400 GHz and 2.483.5 GHz), but BLE is the more popular option by far and it’s the evolution of Bluetooth Classic. It needs much less energy to operate, but with a slightly lower data transmission rate (3 Mbs compared to either 1Mbs or 2 Mbs). In this article we will be focusing on BLE.
Bluetooth is a wireless communication technology designed for short-range data transfer with minimal power consumption. Unlike classic Bluetooth, BLE remains in a low-power sleep mode until a connection is initiated, allowing devices to operate for extended periods on small batteries. It’s really efficient.
Now, there are a few important terms that you’ll come across while learning about BLE. Two of the most important are: BLE central and BLE peripheral.
Peripheral
A peripheral device is a device that announces its presence by sending out advertising packets and accepts a connection from another BLE device (the BLE central, which will be explained shortly). Once connected, the peripheral and central maintain a client–server relation, with the central managing the connection.
Typical examples of peripheral devices include a temperature sensor, fitness tracker, or smart light bulb.
Central
A central is a device that discovers and listens to other BLE devices that are advertising. It is also capable of establishing a connection to BLE peripherals (usually multiple at the same time)
Common examples of central devices include smartphones, laptops, or desktop applications acting as BLE centrals.
Connections
For two BLE devices to interact, one device must advertise while the other scans for advertising packets. Advertising packets contain basic information that allows nearby devices to discover each other.
A connection is established when a central discovers a peripheral and explicitly requests to connect. Once the peripheral accepts this request, the two devices form a connection and are ready to exchange data.
From this point on, communication happens during Connection Events. These are scheduled time windows during which the central and the peripheral are allowed to exchange data. Between connection events, devices can sleep to save power.
The time between consecutive connection events is called the Connection Interval.
Several parameters define how this connection behaves:
- Connection Interval: how often connection events occur. Short intervals reduce latency, while longer intervals save power.
- Slave Latency: allows the peripheral to skip connection events when it has no data to send, further reducing power consumption.
- Supervision Timeout: defines how long the connection can remain inactive before being considered lost.
These parameters involve trade-offs between responsiveness, reliability, and energy consumption.
A shorter connection interval allows devices to exchange data more frequently, resulting in lower latency, but at the cost of increased power consumption on both sides.
Increasing slave latency allows the peripheral to skip connection events when it has no data to send, significantly reducing power usage. However, this also means that the peripheral may take longer to react to requests from the central.
The supervision timeout acts as a safety net. A shorter timeout enables faster detection of lost connections, while a longer timeout makes the link more tolerant to temporary interference or packet loss.
In practice, many of these parameters are handled automatically by the BLE stack. Still, understanding how they work helps developers reason about latency, battery life, and communication behavior when tuning or debugging real-world applications.
Next, we’ll briefly touch on the protocols involved in BLE communication. Don’t worry, we won’t go too deep here, just enough to complete the mental model we’re building.
Protocols
Although we won’t go into protocols in depth here, it’s useful to introduce some basic concepts to understand how this communication works.
The protocol used for these devices is called ATT (Attribute Protocol). This protocol defines how a server exposes its data to a client and how this data is structured.
There are two roles within the ATT:
- The server: as you might have thought this is the device that exposes the data it controls or contains.
- Client: This 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. This role will be assumed by our central device.
All the data that the server exposes is structured as attributes. An attribute is the generic term for any type of data exposed by the server and defines the structure of this data.
Services and characteristics
Now that we understand the protocol behind this communication, let’s discuss services and characteristics, which are the core of the communication process between BLE devices.
Characteristics are the lowest-level attributes within an attribute database, and a service is a group of related characteristics.
As an analogy to REST APIs, you can think of characteristics as the “endpoints” available for a client to consume, and services as collections of those endpoints.
The protocol that defines the format for this structure is called GATT (Generic Attribute Profile), but it’s not important to go into detail right now.
Here is a visual representation:
For example, the battery level characteristic represents the remaining power level of a battery in a device which can be read by a client.
Both services and characteristics have a unique UUID, which allows the client (or central device) to communicate with or use them, in the same way that every endpoint has a unique path.
This is an example of a service and characteristics table for an environment sensor:
Each service is identified by a unique UUID, which represents a logical grouping of related functionality, similar to a base path in a REST API (for example, /environment-sensor).
Within a service, each characteristic also has its own UUID and represents a specific piece of data, comparable to an individual endpoint such as /environment-sensor/temperature.
These UUIDs describe both what data is available and how a client can interact with it. Some services and characteristics use standard 16-bit UUIDs defined by the Bluetooth specification, which represent well-known functionality shared across devices (for example, battery level information). Others use custom 128-bit UUIDs, defined by manufacturers to expose device-specific behavior that falls outside the standard.
If you remember only one thing about BLE, remember this:
BLE is about exposing data as attributes and interacting with it, regardless of which device is acting as central or peripheral.
That data is organized into attributes, and devices interact with them by performing a small set of well-defined operations. Most BLE interactions boil down to reading values, writing commands, or subscribing to updates.
Once you understand this data-centric model and the operations available on top of it, the rest of BLE starts to feel very familiar to anyone with an API background.
Attribute Operations
You can perform different operations on characteristics, similar to how REST APIs support methods like GET, POST, PUT, and PATCH. In Bluetooth Low Energy, characteristics define which operations a remote device is allowed to perform.
The most common operations are:
Read
- Allows a client to read the current value of a characteristic.
- Analogy: similar to an HTTP GET request.
Write
- Allows a client to send a value to the device.
- Analogy: similar to an HTTP PUT or POST request.
Write Without Response
- Similar to Write, but without requiring confirmation from the device. This operation is typically used when low latency and throughput are more important than receiving an explicit confirmation for each write.
- Analogy**:** Similar to publish an event to a queue
Notify
- The device automatically sends updated values to the client whenever the characteristic changes, without the client explicitly requesting them.
- Analogy: The device informs the client automatically, like a webhook.
Indicate
- Similar to Notify, but requires an acknowledgment from the client. Used when it is important to ensure that the data was successfully received.
- Analogy: Similar to a webhook that requires an explicit acknowledgment before the sender proceeds.
Final
With these core concepts in mind, BLE stops feeling like a black box and starts looking like what it really is: a structured way to expose data and interact with devices.
Whether you’re controlling a light bulb, reading sensor data, or building more advanced systems such as Neuralink implants (yes, they rely on this technology), BLE provides a solid and flexible foundation to start experimenting and shipping real-world solutions.