How Bluetooth Low Energy Actually Works: The Radio Protocol Built for Tiny Batteries

Bluetooth Low Energy sounds self-explanatory until you try to build something with it. Then you discover that "low energy" is not one feature but a chain of careful design choices about radio timing, packet structure, connection scheduling, sleep behaviour, and how much work the device does while the transmitter is on. BLE is what happens when a protocol is designed around coin cells instead of mains power and around short bursts of data instead of long-lived saturated links.

People often talk about Bluetooth as if it were one thing. It is not. Classic Bluetooth and Bluetooth Low Energy are related but architecturally different systems. BLE is the one used by fitness sensors, smart locks, beacons, keyboards, tags, thermometers, wearables, and an enormous number of embedded products that need to communicate without draining their batteries in days.

This post explains how BLE actually works: the radio channels, advertising and scanning, connection establishment, packet timing, GATT services, PHY options, security modes, and the real tradeoffs between latency, throughput, and battery life.

1. BLE Was Built Around a Different Goal Than Wi-Fi

Wi-Fi is optimised for useful throughput over a shared local network. BLE is optimised for small bursts of data with long sleep periods between them.

That design goal changes everything:

• packet sizes are small
• the radio is active for very short windows
• devices spend most of their life asleep
• discovery is designed for intermittent low-duty-cycle communication
• connection timing is negotiated explicitly

If you compare BLE to Wi-Fi by asking only "which one is faster," BLE looks weak. If you compare them by asking "which one lets a €3 sensor run for two years on a CR2032 battery," BLE starts to make sense immediately.

This is why BLE appears in products like:

• heart-rate straps
• door sensors
• temperature probes
• asset tags
• industrial telemetry widgets
• smart home accessories

Most of those devices do not need megabits per second. They need to wake up, move a few bytes, and disappear back into sleep quickly.

2. The BLE Radio Band and Channel Plan

BLE operates in the 2.4 GHz ISM band, the same broad band used by Wi-Fi, microwave ovens, classic Bluetooth, Zigbee, and many proprietary radios. That means BLE lives in a crowded RF environment by default.

BLE divides the band into 40 RF channels, each 2 MHz wide:

• 3 advertising channels
• 37 data channels

The advertising channels are:

• channel 37 at 2402 MHz
• channel 38 at 2426 MHz
• channel 39 at 2480 MHz

Those positions are not arbitrary. They were chosen to reduce overlap with the most common 2.4 GHz Wi-Fi channel centres. In simplified terms:

• Wi-Fi channels 1, 6, and 11 dominate many deployments
• BLE advertising channels sit in gaps intended to improve discovery reliability

The remaining 37 data channels carry actual connected traffic.

Why Only Three Advertising Channels

Discovery is expensive because scanners have to listen and advertisers have to transmit without knowing exactly when the scanner is listening. BLE solves this probabilistically. A peripheral sends the same advertising event on one or more of the three advertising channels. A scanner hops through listening windows. If the timing lines up on any one of those channels, discovery succeeds.

Using just three channels for discovery keeps the scanning problem manageable. Using the rest for data gives the connection phase more spectral flexibility.

3. Advertising: How BLE Devices Announce Themselves

Advertising is the first thing most BLE peripherals do. The device is not yet connected. It is shouting short structured messages into the air at chosen intervals.

A basic advertising cycle looks like this:

1. sleep
2. wake up
3. transmit advertising packet on channel 37
4. transmit on channel 38
5. transmit on channel 39
6. go back to sleep

Then repeat after the advertising interval plus a small random delay called advDelay.

That random delay matters more than it first appears. If every advertiser transmitted on a perfectly fixed schedule, devices with similar intervals would collide repeatedly in the same pattern. A little randomness breaks that lockstep and improves the odds that future advertising events land in cleaner airtime.

Advertising Interval

The advertising interval is configurable, often between tens of milliseconds and several seconds. That choice has direct consequences:

• shorter interval: faster discovery, worse battery life
• longer interval: slower discovery, better battery life

For example:

A tracker beacon in a museum in Paris might advertise every 1000 ms because users can tolerate slow discovery. A wireless button that should pair instantly might use 20 to 50 ms during pairing mode and then switch to a much slower interval later.

Advertising Packet Contents

Advertising data is compact. It can carry fields such as:

• device name, shortened or complete
• service UUIDs
• manufacturer-specific data
• transmit power hint
• flags indicating discoverability

A simplified advertising payload might look like:

Flags: LE General Discoverable, BR/EDR not supported
Complete Local Name: "TempNode-07"
16-bit Service UUID: 0x1809
Manufacturer Data: company=0x1234, sensor_state=0x02, battery=87

That is often enough for a mobile app to decide whether it cares about the device before connecting at all.

GAP: The Generic Access Profile

GAP is the layer that governs advertising, scanning, and connection establishment. It defines the roles devices play and the procedures they follow to find each other.

GAP defines four roles:

• Broadcaster: transmits advertising packets but never accepts connections. Beacons use this role.
• Observer: receives advertising packets but never initiates connections. A passive scanner collecting telemetry uses this role.
• Peripheral: advertises and accepts connections from a central. Most BLE sensors and accessories operate as peripherals.
• Central: scans for advertisers and initiates connections. Phones and gateways typically act as centrals.

These are not just labels. They determine which Link Layer states a device can enter and what PDU types it sends. A broadcaster never enters the initiating or connection states. A peripheral never sends CONNECT_IND packets.

GAP also defines discoverability modes. A device can be:

• non-discoverable (not visible to general scanning)
• limited discoverable (visible for a short window, such as during a button press)
• general discoverable (visible to anyone scanning)

The advertising data flags field encodes this:

Flags byte = 0x06
  bit 1: LE General Discoverable Mode
  bit 2: BR/EDR Not Supported

A device that sets only the limited discoverable flag signals that it is temporarily available. A phone's scanning UI might filter non-discoverable devices from its list entirely, which is why a BLE peripheral that does not set the right flags can appear "invisible" even though it is actively advertising.

GAP also controls the advertising PDU type. The most common types are:

A beacon that never accepts connections uses ADV_NONCONN_IND. A sensor waiting to be paired uses ADV_IND. A device reconnecting to a bonded phone after a power cycle might use ADV_DIRECT_IND to target that specific central quickly.

4. Scanning: The Other Half of Discovery

A BLE scanner does not just "listen continuously" unless power consumption is irrelevant. It typically follows two timing parameters:

• scan interval
• scan window

The scan interval is how often the scanner begins a listening cycle. The scan window is how long it actually listens during that cycle.

If:

• scan interval = 100 ms
• scan window = 50 ms

then the scanner listens half the time.

This introduces the same tradeoff on the central side:

• larger scan window: better discovery speed, more power draw
• smaller scan window: lower power draw, slower discovery

Phones often scan aggressively during active pairing screens and much less aggressively in the background.

Passive and Active Scanning

BLE supports:

• passive scanning
• active scanning

In passive scanning, the scanner only listens for advertising packets.

In active scanning, if the advertiser allows it, the scanner can send a SCAN_REQ and receive a SCAN_RSP. That lets the advertiser expose extra metadata without placing everything in the base advertisement.

This helps with a common product need: keep normal advertising short for power and airtime reasons, but offer richer data when an interested scanner asks.

5. Connection Establishment: From Advertising to Scheduled Events

Once a central device wants to connect to a peripheral, the model changes completely. BLE stops being a loose discovery system and becomes a scheduled conversation.

The central sends a connection request that includes parameters like:

• access address
• CRC initialisation
• connection interval
• peripheral latency
• supervision timeout
• channel map
• hop increment

The peripheral accepts, and both sides now know exactly when future connection events should occur.

Why This Is Efficient

Unlike Wi-Fi, BLE does not keep endpoints awake waiting for arbitrary traffic. It schedules specific connection events. Outside those windows, both sides can sleep.

That is the core battery-saving trick.

Suppose:

• connection interval = 100 ms
• actual packet exchange in event = 2 ms

Then the radio is awake only about 2 percent of the time, ignoring wake overhead. In real embedded products this kind of duty-cycle reduction is the difference between replacing a battery monthly and replacing it yearly.

The CONNECT_IND Packet

The connection request is not a vague handshake. It is a precise packet (the CONNECT_IND PDU) that carries everything the peripheral needs to synchronise with the central. The payload is 34 bytes and contains:

Offset  Field                Size     Description
0       InitA                6 bytes  Initiator address
6       AdvA                 6 bytes  Advertiser address
12      Access Address       4 bytes  Random 32-bit value for this connection
16      CRC Init             3 bytes  CRC seed
19      WinSize              1 byte   Transmit window size (units of 1.25 ms)
20      WinOffset            2 bytes  Transmit window offset
22      Interval             2 bytes  Connection interval (units of 1.25 ms)
24      Latency              2 bytes  Peripheral latency (number of events)
26      Timeout              2 bytes  Supervision timeout (units of 10 ms)
28      ChM                  5 bytes  Channel map (37-bit bitmap)
33      Hop + SCA            1 byte   Hop increment (5 bits) + sleep clock accuracy (3 bits)

The access address is generated randomly by the central and used by both sides to identify packets belonging to this connection. The channel map is a 37-bit field marking which data channels are currently usable. The hop increment (a value between 5 and 16) seeds the channel selection algorithm that determines which channel each connection event uses.

The sleep clock accuracy (SCA) field tells the peripheral how accurate the central's clock is. This matters because between connection events, both sides' clocks drift. A worse SCA means the peripheral must open its receive window earlier and close it later to account for that drift, which costs extra power.

6. Connection Parameters: The Real Power-Latency Dial

Three connection parameters matter more than almost anything else in BLE behaviour:

• connection interval
• slave, now peripheral, latency
• supervision timeout

Connection Interval

This is the time between the start of consecutive connection events. It can be short, which gives low latency and higher throughput, or long, which saves power.

Typical intuition:

Peripheral Latency

Peripheral latency allows the peripheral to skip a number of connection events if it has nothing to send. This is a major power feature.

If:

• interval = 50 ms
• peripheral latency = 4

the peripheral can ignore up to four scheduled events and wake only on the fifth, effectively participating every 250 ms when idle.

That keeps the connection logically alive without paying the full active cost every interval.

Supervision Timeout

This is the maximum time the connection can go without successful communication before it is considered lost.

It must be large enough to tolerate skipped events and occasional interference, but not so large that dead links linger forever.

A badly chosen supervision timeout creates ugly behaviour:

• too short: connections drop under mild RF trouble
• too long: dead devices appear connected for ages

Connection Parameter Update Negotiation

After a connection is established, either side may request new parameters. The peripheral typically initiates this with an LL_CONNECTION_PARAM_REQ control PDU or, on older stacks, an L2CAP Connection Parameter Update Request.

The request contains proposed minimum and maximum intervals, the desired peripheral latency, and a supervision timeout. The central can accept, reject, or propose alternatives.

This negotiation matters because the initial parameters chosen during CONNECT_IND are the central's best guess. The peripheral often knows better what it needs. A heart-rate strap might request a 1-second interval during idle periods to conserve power but switch to 15 ms during an active workout session when the user wants real-time data on their phone.

On mobile platforms, this negotiation can be frustrating. iOS and Android both have opinions about acceptable ranges:

Apple publishes "Accessory Design Guidelines" that specify acceptable connection parameter ranges. Peripherals that request parameters outside those ranges get rejected silently, which leads to confused engineers who cannot understand why their Nordic or ESP32 firmware works fine on Android but not on iPhones.

7. Channel Hopping and Interference Avoidance

BLE does not stay on one RF channel during a connection. It hops across data channels using a deterministic sequence known to both endpoints.

This has two big benefits:

1. narrowband interference hurts only some events
2. coexistence with Wi-Fi and other 2.4 GHz systems improves

The connection setup includes a channel map that marks usable data channels. If certain channels are consistently bad, they can be removed from use.

Adaptive Frequency Hopping

BLE uses adaptive frequency hopping, or AFH. The idea is simple:

• observe channel quality
• avoid persistently bad channels
• keep using a changing set of good ones

If a factory floor in Rotterdam has heavy interference near part of the band from local equipment, the BLE stack can de-emphasise those channels rather than repeatedly suffering the same loss.

This is not perfect. The 2.4 GHz band is still crowded. But hopping makes BLE more robust than a fixed-frequency narrowband radio would be.

Channel Selection Algorithms

BLE defines two channel selection algorithms. Algorithm #1 (CSA #1) is the original from BLE 4.0. It uses a simple formula:

unmappedChannel = (lastUnmappedChannel + hopIncrement) mod 37

If the resulting channel is marked as unused in the channel map, the algorithm remaps it to a used channel with a modular mapping. This is deterministic: both sides compute the same sequence from the same seed.

Algorithm #2 (CSA #2), introduced in BLE 5.0, is more sophisticated. It uses a permutation-based pseudo-random mapping that distributes hops more uniformly across used channels. CSA #2 reduces the probability of consecutive hops landing on adjacent frequencies, which improves resilience against wideband interferers.

The algorithm in use is indicated during connection setup. Devices that support CSA #2 advertise this in their feature set, and the central selects it when both sides support it.

8. BLE Packet Structure and Airtime

BLE packets are small, and small packets are part of the battery story.

A BLE link-layer packet on the 1M PHY has this structure:

+----------+----------------+--------+---------+-----+
| Preamble | Access Address | Header | Payload | CRC |
| 1 byte   | 4 bytes        | 2 bytes| 0-257   | 3   |
+----------+----------------+--------+---------+-----+

The preamble is 0xAA for data channels (alternating bits to help the receiver synchronise its clock recovery). For advertising channels, the preamble depends on the access address.

The advertising channels use a well-known access address:

0x8E89BED6

Connected data channels use a connection-specific access address chosen during setup.

Why the Access Address Matters

It helps the receiver distinguish valid packets for this BLE conversation from random noise or traffic belonging to someone else. The radio can filter early and avoid wasting work on irrelevant signals.

A Real Advertising Packet in Hex

Here is what an advertising packet looks like on the wire (captured from a Nordic nRF52840 temperature beacon):

AA D6BE898E  2025  17FF4C000215 AABBCCDD EEFF0011 22334455 6677 C5
|  |         |     |
|  |         |     Advertising payload (iBeacon format)
|  |         Header: PDU type=ADV_NONCONN_IND, length=0x25
|  Access address (advertising)
Preamble
 
Breakdown of the payload:
  02 01 06              Flags: General Discoverable, BR/EDR not supported
  1A FF 4C 00           Manufacturer Specific (Apple)
  02 15                 iBeacon identifier
  AA BB CC DD EE FF     UUID (first 6 bytes)
  00 11 22 33 44 55     UUID (last 6 bytes)
  66 77                 Major: 0x6677
  C5                    TX Power: -59 dBm

Each field has a specific purpose. The flags AD structure is 3 bytes total (length, type, value). The manufacturer-specific data uses company identifier 0x004C (Apple), which is how iOS devices recognise iBeacon frames without parsing the full payload.

Airtime Example

At the original 1M PHY, one bit takes 1 microsecond. A 27-byte packet on the air is not just 27 microseconds because you also have headers, CRC, inter-frame spacing, and potential response packets. But the total event is still tiny compared with Wi-Fi transactions.

For a minimal data packet (empty PDU, used for keepalive):

Preamble:        1 byte  =   8 us
Access Address:  4 bytes =  32 us
Header:          2 bytes =  16 us
CRC:             3 bytes =  24 us
Total:          10 bytes =  80 us

Add the inter-frame space (T_IFS = 150 us) and the acknowledgement packet (another 80 us), and one empty connection event takes about 310 microseconds on the air. At a 1-second connection interval, the radio duty cycle for keepalive is 0.031%.

That is the point. BLE is engineered around short radio-on intervals.

For intuition, imagine a sensor that wakes every second, transmits one small packet, receives an acknowledgment, and goes back to sleep. The useful RF work may only occupy a tiny fraction of that second. Most of the battery win comes from how aggressively the protocol lets the device disappear between those events.

9. PHY Modes: 1M, 2M, and Coded PHY

BLE is not stuck with one physical layer mode. BLE 5.0 introduced two additional PHY options alongside the original.

Common PHY options include:

• LE 1M PHY
• LE 2M PHY
• LE Coded PHY, often called long range

1M PHY

This is the baseline. 1 megasymbol per second, GFSK modulation, 1 bit per symbol. Good compatibility, moderate data rate, common default. Every BLE device must support it.

2M PHY

This doubles the symbol rate to 2 megasymbols per second. A packet that takes 80 microseconds on 1M takes 40 microseconds on 2M (excluding the preamble, which is 2 bytes on 2M instead of 1).

Lower airtime can improve energy efficiency if the link quality is good enough, because the radio turns off sooner. Nordic Semiconductor's measurements on the nRF52840 show that switching from 1M to 2M PHY for a typical sensor notification reduces the energy per packet by roughly 30%, not 50%, because the fixed overhead of waking the radio and ramping the PLL stays constant.

But 2M PHY is not automatically better. It usually has less range margin than 1M for the same transmit power and environment. The higher symbol rate means less energy per bit at the receiver, which reduces sensitivity by approximately 3 dB.

Coded PHY

Coded PHY adds forward error correction to improve sensitivity and range. It uses two coding schemes:

• S=2: each bit is encoded as 2 symbols. Data rate drops to 500 kbps. Sensitivity improves by roughly 5 dB over 1M.
• S=8: each bit is encoded as 8 symbols. Data rate drops to 125 kbps. Sensitivity improves by roughly 12 dB over 1M.

That 12 dB improvement with S=8 translates to roughly 4x the range in open-air line-of-sight conditions. A sensor in a large warehouse outside Copenhagen that cannot maintain a link at 30 metres on 1M PHY might reach 100 metres or more on Coded PHY S=8.

The tradeoff is airtime. A packet that takes 80 microseconds on 1M takes 640 microseconds on Coded S=8. Longer airtime means the radio is on longer per event, more vulnerability to interference during transmission, and lower overall throughput.

Coded PHY also has a unique preamble and coding structure. The access address and coding indicator are always sent at 125 kbps (S=8 coding), but the payload can use either S=2 or S=8. This two-stage approach lets the receiver lock onto the signal reliably before switching to the higher rate for the payload when conditions allow.

10. Data Length Extension and Throughput Reality

Early BLE versions had small payload limits that made throughput feel modest. BLE 4.0 limited link-layer payloads to 27 bytes. BLE 4.2 introduced Data Length Extension, or DLE, allowing payloads up to 251 bytes.

This helps because overhead becomes a smaller fraction of each transmission.

A simplistic throughput comparison on 1M PHY:

Even so, BLE is still not trying to be Wi-Fi. Real throughput depends on:

• PHY mode
• packet size
• connection interval
• number of packets per event
• retransmissions
• central platform behaviour

Developers often read a theoretical maximum in a specification and then wonder why their phone app gets far less in practice. The answer is usually that the full stack, especially on mobile operating systems, has constraints and scheduling behaviour that the raw link budget does not reveal.

The theoretical maximum throughput on 2M PHY with DLE (251 bytes) and six packets per connection event is roughly 1.4 Mbps. In practice, most real applications see 200 to 800 kbps depending on the platform, stack, and RF conditions.

ATT MTU and Application Fragmentation

At the GATT layer, application payload size is also shaped by the ATT Maximum Transmission Unit, or MTU. If the MTU is small, larger values get fragmented across multiple protocol operations even before link-layer realities are considered.

A simplified example:

ATT MTU = 23 bytes
ATT header = 3 bytes
usable attribute payload = 20 bytes

This is why so many BLE examples talk about "20-byte chunks." It is not a universal BLE law, but it was a common practical ceiling for a long time and it still shapes a lot of application code and assumptions.

When larger MTUs and DLE are negotiated successfully, throughput improves a lot. When they are not, developers often misdiagnose the resulting slowness as "Bluetooth is bad" rather than "our negotiated payload path is tiny."

A proper high-throughput BLE setup negotiates both DLE at the link layer and a large ATT MTU (up to 512 bytes is common) at the GATT layer. The two are independent but both matter. DLE without a large MTU still fragments at the application layer. A large MTU without DLE still fragments at the link layer.

11. GATT and ATT: The Data Model Most Developers Actually Touch

At the application-facing layer, most BLE products use:

• ATT, Attribute Protocol
• GATT, Generic Attribute Profile

This is the part mobile developers see when they discover services and characteristics.

Attributes

An attribute is a typed record identified by a handle. It may represent:

• a service
• a characteristic
• a descriptor

Every attribute has four fields:

+--------+------+-------------+-------+
| Handle | Type | Permissions | Value |
+--------+------+-------------+-------+

The handle is a 16-bit integer (0x0001 to 0xFFFF) that uniquely identifies the attribute within the server's database. The type is a UUID (16-bit for standard Bluetooth SIG types, 128-bit for custom). Permissions control access (readable, writable, requires encryption, requires authentication).

The Attribute Database Layout

A GATT server's attribute database is a flat sequential table of attributes. Services, characteristics, and descriptors are all just attributes with specific type UUIDs. The hierarchy is implied by ordering, not by nesting.

Here is what a real attribute table looks like for a simple temperature sensor:

Handle  Type UUID    Description
0x0001  0x2800      Primary Service: Generic Access (0x1800)
0x0002  0x2803      Characteristic: Device Name
0x0003  0x2A00      Device Name Value: "TempNode-07"
0x0004  0x2803      Characteristic: Appearance
0x0005  0x2A01      Appearance Value: 0x0300 (Thermometer)
0x0006  0x2800      Primary Service: Health Thermometer (0x1809)
0x0007  0x2803      Characteristic: Temperature Measurement
0x0008  0x2A1C      Temperature Measurement Value
0x0009  0x2902      CCCD (Client Characteristic Configuration Descriptor)
0x000A  0x2803      Characteristic: Temperature Type
0x000B  0x2A1D      Temperature Type Value: 0x02 (Body)

Handle 0x2803 is the Characteristic Declaration. It contains the characteristic's properties (read, write, notify, indicate), the value handle, and the characteristic UUID. Handle 0x2902 is the Client Characteristic Configuration Descriptor (CCCD), which the client writes to enable notifications or indications.

Services and Characteristics

GATT organises data into services, each containing characteristics. A characteristic usually has:

• a UUID
• a value
• properties such as read, write, notify, indicate

A heart-rate monitor might expose:

• Heart Rate Service, UUID 0x180D
• Heart Rate Measurement characteristic, UUID 0x2A37

A temperature sensor might expose:

• Health Thermometer Service, UUID 0x1809
• Temperature Measurement characteristic, UUID 0x2A1C

Service Discovery Protocol

When a central connects, it typically performs service discovery by sending ATT requests:

1. Read By Group Type Request (type = 0x2800) to find all primary services
2. Read By Type Request (type = 0x2803) within each service's handle range to find characteristics
3. Find Information Request to discover descriptors

This discovery can take multiple round trips, each consuming a connection event. On a slow connection interval (say, 500 ms), discovering a complex GATT database can take several seconds. This is one reason cached service databases and bonding (which preserves the GATT cache) improve user experience.

Why GATT Feels Awkward Sometimes

GATT is clean for small structured state. It becomes awkward when developers try to treat BLE like a raw bidirectional socket. Large transfers, firmware updates, and custom streaming over GATT are possible, but they require care and usually involve chunking, acknowledgments, and application-level framing.

This is why many serious BLE products have a custom profile design even if they still live within GATT semantics.

12. Notifications, Indications, Reads, and Writes

Characteristic access patterns matter a lot for responsiveness and reliability.

Read

The client asks for the current value. Good for infrequent polling. Wasteful for continuously changing sensor data.

Write

The client sends a new value. This can be:

• write request, acknowledged
• write command, unacknowledged

Notification

The server pushes a new value without requiring an application-level acknowledgment.

Indication

The server pushes a new value and requires confirmation from the client.

Operationally:

• notifications are lighter and more common
• indications are slower but reliable at the application layer

A cycling power meter streaming measurements several times per second usually uses notifications. A medical device sending a state transition that must be confirmed may prefer indications.

Firmware update flows often combine multiple patterns:

• write commands for fast block transfer
• notifications for progress or state
• a final acknowledged control write before reboot

That mix exists because no single GATT operation is ideal for every phase of the workflow.

13. Security: Pairing, Bonding, and What Actually Gets Protected

BLE security has improved over time, but it has also accumulated a reputation for confusion because there are several pairing models, legacy compatibility concerns, and user-interface limitations on small devices.

Important concepts:

• pairing, establishing keys
• bonding, storing those keys for future reuse
• encryption, protecting the link
• authentication, validating who you paired with

The Security Manager Protocol (SMP)

All BLE pairing runs through SMP, which operates over a dedicated L2CAP channel (CID 0x0006). The pairing process has three phases:

Phase 1: Pairing Feature Exchange. Both devices exchange their I/O capabilities, authentication requirements, and supported key sizes. This exchange determines which pairing method will be used.

The Pairing Request and Pairing Response PDUs contain:

Field                    Size     Values
IO Capability            1 byte   DisplayOnly, DisplayYesNo, KeyboardOnly,
                                  NoInputNoOutput, KeyboardDisplay
OOB Data Flag            1 byte   0x00 (not present) or 0x01 (present)
AuthReq                  1 byte   Bonding, MITM, SC, Keypress flags
Max Encryption Key Size  1 byte   7 to 16
Initiator Key Dist       1 byte   Bitmap of keys to distribute
Responder Key Dist       1 byte   Bitmap of keys to distribute

Phase 2: Key Generation. Depending on whether Legacy Pairing or LE Secure Connections is used, the devices either generate a Short-Term Key (STK) or a Long-Term Key (LTK) using Elliptic Curve Diffie-Hellman (ECDH) on the P-256 curve.

LE Secure Connections (introduced in BLE 4.2) is substantially stronger than Legacy Pairing. Legacy Pairing uses a temporary key derived from a 6-digit passkey or just zeros (for Just Works), which is vulnerable to passive eavesdropping if the pairing exchange is captured. Secure Connections uses ECDH, so even capturing the full pairing exchange does not reveal the LTK without breaking the discrete logarithm problem on P-256.

Phase 3: Key Distribution. After encryption is established, the devices exchange additional keys: the Identity Resolving Key (IRK) for private address resolution, the Connection Signature Resolving Key (CSRK) for signed writes, and (in Legacy Pairing) the LTK itself via the Encryption Information and Master Identification PDUs.

Common Pairing Methods

• Just Works
• Passkey Entry
• Numeric Comparison
• Out of Band

These differ mainly in MITM resistance and usability.

For example:

• Just Works is easy, but weak against active man-in-the-middle attacks during pairing
• Passkey Entry adds user confirmation
• Numeric Comparison is stronger when both devices have displays

Tiny embedded devices often have terrible UI, which means security choices are constrained by product design, not just cryptographic ideals.

Privacy Addresses

BLE devices can also use resolvable private addresses (RPAs) instead of fixed public addresses to reduce tracking. This matters because always advertising the same hardware identity makes a person very easy to track in public spaces.

An RPA is generated from the device's IRK and a random number, then rotated periodically (typically every 15 minutes). Only a device that knows the IRK can resolve the RPA back to the original identity. A phone that has bonded with a fitness tracker can recognise it even after the address changes, but a passive observer in a shopping centre in Milan sees a different address every 15 minutes.

The RPA format has a specific structure: the two most significant bits of the address are 01, followed by 22 random bits (the prand), then 24 bits that are a hash of the IRK and prand. A bonded device checks whether hash(IRK, prand) == lower24bits to resolve the address.

Privacy is not automatic, though. Product teams have to configure and use these mechanisms correctly.

14. BLE 5.x Features: Extended Advertising and Beyond

BLE 5.0 and later revisions introduced several features beyond PHY changes that significantly expanded what the protocol can do.

Extended Advertising

Legacy advertising is limited to 31 bytes of payload (37 bytes total, minus the 6-byte address). Extended advertising, introduced in BLE 5.0, increases the maximum advertising payload to 254 bytes per PDU and supports chaining up to 1,650 bytes total across fragments.

Extended advertising works by sending a short pointer packet on the primary advertising channels (37, 38, 39) called an ADV_EXT_IND. This packet contains no advertising data itself. Instead, it includes an AuxPtr field that tells the scanner which secondary data channel to listen on and when:

ADV_EXT_IND on channel 37:
  Header: Extended, no payload
  AuxPtr: channel=9, offset=300us, PHY=1M
 
AUX_ADV_IND on data channel 9:
  AdvA: AA:BB:CC:DD:EE:FF
  AdvData: [up to 254 bytes]
  AuxPtr: (chain to next fragment if needed)

This design keeps the primary advertising channels clear. The actual data payload moves to the less congested data channels, reducing collisions during discovery in dense environments.

Periodic Advertising

Periodic advertising lets a device broadcast data at fixed intervals without requiring connections. The scanner synchronises to the advertiser's schedule using a SYNC_IND from an AUX_ADV_IND, and then receives periodic AUX_SYNC_IND packets at predictable times.

This is useful for broadcasting telemetry to multiple receivers simultaneously. A digital signage controller in a train station in Frankfurt could broadcast schedule updates to dozens of display panels without maintaining individual connections to each one.

LE Audio and Isochronous Channels

BLE 5.2 introduced isochronous channels and the LE Audio specification. Isochronous channels provide time-bounded data delivery, which classic BLE's asynchronous connection events cannot guarantee.

LE Audio uses the LC3 codec (Low Complexity Communication Codec), which delivers better audio quality than SBC at lower bit rates. A pair of wireless earbuds using LE Audio at 32 kbps per channel can match the perceptual quality of classic Bluetooth's SBC at 198 kbps.

Broadcast Isochronous Streams (BIS) allow one device to stream audio to an unlimited number of receivers without connections. This enables the "Auracast" use case: a television in a hotel lobby in Vienna could broadcast its audio to any compatible hearing aid or earbud in the room.

15. Battery Life: Where the Energy Actually Goes

People sometimes assume transmission power is the whole battery story. It is not. Energy use comes from:

• radio transmit time
• radio receive time
• wake-up overhead
• CPU processing
• sensor sampling
• application behaviour

In many BLE designs, the biggest lever is not transmit power. It is how often the device wakes up and how long it stays awake.

Consider two designs for a door sensor:

Design A

• advertises every 100 ms all day
• keeps connection alive continuously
• transmits battery level too often

Design B

• sleeps almost all the time
• advertises only when needed
• sends one short state update on open or close
• uses long idle intervals otherwise

Design B usually wins battery life by a huge margin even if both use the same radio chip and transmit power.

This is why BLE product engineering is mostly scheduling engineering.

One subtle trap is receive cost. Engineers focus on transmit current because it is easy to imagine the radio shouting, but listening burns energy too. A design that scans too often, keeps connection intervals too short, or waits around for optional traffic can waste power even if it barely transmits.

Real Power Measurements

To make the tradeoffs concrete, here are actual current measurements from a Nordic nRF52832 development board (3.0 V supply, 0 dBm TX power, 1M PHY):

Notice that RX current (5.4 mA) is nearly identical to TX current (5.3 mA). The radio front-end draws similar power whether transmitting or receiving. This means unnecessary listening windows cost almost as much as unnecessary transmissions.

For a CR2032 coin cell (typical capacity: 225 mAh), an advertising-only beacon at 1-second intervals on 1M PHY draws roughly:

Per advertising event:
  3 channels x (preamble + packet + IFS) = ~3 x 0.4 ms = 1.2 ms
  Average current during TX: 5.3 mA
  Wake-up overhead: ~0.1 ms at 5.0 mA
 
Energy per event: 5.3 mA x 1.2 ms + 5.0 mA x 0.1 ms = 6.86 uA*s
 
Average current: 6.86 uA*s / 1s = 6.86 uA
Add sleep current: 1.5 uA
Total average: ~8.4 uA
 
Battery life: 225 mAh / 8.4 uA = ~26,800 hours = ~3 years

Change the advertising interval to 100 ms and battery life drops to roughly 4 months. That single parameter, advertising interval, is the difference between a product that works and one that gets returned.

16. BLE Mesh Networking

Standard BLE is point-to-point (or point-to-multipoint with one central and several peripherals). Bluetooth Mesh, published in 2017, adds a managed flooding network on top of BLE's advertising bearers.

How Mesh Works

Mesh nodes communicate by broadcasting messages on the advertising channels. Every node that receives a mesh message may relay it by rebroadcasting. This managed flood propagation reaches nodes that are not within direct radio range of the originator.

The mesh stack sits above BLE's advertising layer:

Application Layer
  |
Model Layer (defines behaviours: on/off, dimming, sensor)
  |
Foundation Model Layer (configuration, health)
  |
Access Layer (encryption, authentication)
  |
Transport Layer (segmentation, reassembly)
  |
Network Layer (relay, addressing, obfuscation)
  |
Bearer Layer (advertising bearer or GATT bearer)
  |
BLE Link Layer

Mesh uses two keys for security: a Network Key (NetKey) shared by all nodes in a subnet, and an Application Key (AppKey) that restricts message decryption to nodes that need to process the payload. A relay node can forward an encrypted mesh message without being able to read its contents, because relaying only requires the NetKey while reading the application data requires the AppKey.

Mesh Limitations

Managed flooding has inherent scaling constraints. Every message is rebroadcast by every relay node, which means network traffic grows rapidly with node count and message rate. In practice, Bluetooth Mesh works well for infrequent state changes (lighting control, building automation) but poorly for high-frequency sensor streams.

The Mesh 1.1 specification introduced directed forwarding, which allows the network to learn paths and avoid flooding by routing messages along discovered routes. This significantly reduces airtime in large deployments but adds complexity to provisioning and configuration.

A typical deployment: a lighting control system in a hotel in Barcelona with 200 luminaires, each acting as a mesh relay node. An occupancy sensor detects a guest in a corridor and publishes a "presence detected" message. The message floods through nearby relays, reaches the relevant luminaire group, and the lights turn on. Total latency is typically 50 to 200 ms depending on the number of hops.

17. Why Phones Sometimes Behave Strangely With BLE

Engineers new to BLE often assume weird behaviour is always the peripheral's fault. It often is not.

Phones impose their own policies:

• scan throttling in background
• connection parameter negotiation preferences
• platform-specific limits on notification rate
• OS mediation of pairing UX
• app lifecycle interruptions

An Android or iPhone app may not get the same scan responsiveness in the background as it gets on an active pairing screen. Some platforms resist extremely short connection intervals to protect battery life. Some queue writes in ways that surprise developers.

iOS is particularly opinionated. It enforces a minimum connection interval of 15 ms, rejects supervision timeouts it considers too short, throttles background scanning to roughly one scan every 4 seconds, and limits the number of concurrent BLE connections (the exact limit varies by device but is typically around 10 to 15 active connections).

Android varies by OEM and version. Some Samsung devices handle BLE differently from Pixel devices running the same Android version because the Bluetooth stack has manufacturer-specific patches. Background scanning behaviour changed significantly between Android 8 and Android 12, with progressively stricter limitations on how often apps can start and stop scans.

This is why BLE debugging often needs traces from both sides:

• over-the-air sniffer if possible
• peripheral firmware logs
• mobile-side logs

Without both, teams often blame the wrong layer. A packet capture from a sniffer (such as the Nordic nRF Sniffer for Wireshark, or an Ellisys Bluetooth Tracker) can reveal whether the peripheral is misbehaving, whether the phone is rejecting valid parameter requests, or whether interference is causing packet loss that the application interprets as a firmware bug.

18. BLE Is Not a Mesh or a Generic Internet Link (Unless You Build It That Way)

BLE can be stretched into many shapes, but it helps to stay honest about what it is best at.

BLE is very good for:

• nearby peripherals
• low-duty-cycle sensors
• wearables
• bursts of modest data
• user-device pairing and control

BLE is not naturally good at:

• long-range coverage across a city
• high-throughput multimedia
• arbitrary many-to-many routing
• large sustained uploads

Standard BLE peripheral-central communication is not secretly a general-purpose network stack waiting to be unlocked. But BLE can serve as a bearer for higher-level protocols. Thread and Matter (used in smart home products) can use BLE for commissioning, even though the steady-state network runs over 802.15.4 or Wi-Fi. BLE serves as the onboarding channel because every phone already has it.

19. Practical Protocol Traces

Understanding BLE behaviour is much easier when you can see real packet exchanges. Here is an annotated connection sequence captured between an nRF52840 peripheral and an Android phone:

Time (ms)  Ch  Direction     PDU Type           Notes
0.000      37  Peripheral->  ADV_IND            Advertising, connectable
0.412      37  Central->     SCAN_REQ           Phone requests scan response
0.562      37  Peripheral->  SCAN_RSP           Peripheral sends extra data
1002.3     38  Peripheral->  ADV_IND            Next advertising event
1002.7     38  Central->     CONNECT_IND        Phone initiates connection
                                                 Interval=30ms, Latency=0,
                                                 Timeout=500ms, Hop=7
1033.0     14  Central->     LL_FEATURE_REQ     Central queries features
1033.2     14  Peripheral->  LL_FEATURE_RSP     DLE=yes, 2M=yes, CSA#2=yes
1063.0     21  Central->     LL_LENGTH_REQ      Propose MaxTxOctets=251
1063.1     21  Peripheral->  LL_LENGTH_RSP      Accept MaxTxOctets=251
1093.0     28  Central->     ATT Exchange MTU   Client MTU=517
1093.1     28  Peripheral->  ATT Exchange MTU   Server MTU=247
                                                 Effective MTU=247
1123.0     35  Central->     ATT Read By Group  Service discovery begins

Several things are visible in this trace. The phone performs active scanning (SCAN_REQ / SCAN_RSP) before connecting. Feature exchange happens immediately after connection. DLE negotiation follows. MTU exchange happens at the ATT layer. The effective MTU is the minimum of the two proposals (247 in this case, because the peripheral's stack limits it). The connection interval of 30 ms means each line pair is spaced 30 ms apart, hopping to a new channel each time (14, 21, 28, 35, following the hop sequence).

20. A Practical Mental Model of BLE

If you want one compact model to carry around, use this:

BLE is a short-range radio system that spends most of its time asleep, discovers peers through sparse advertising on three dedicated channels, then switches to tightly scheduled connection events on hopping data channels, with small packets and configurable timing chosen to trade latency against battery life.

That model explains most BLE design choices:

• advertising exists because always-on listening would waste power
• connection intervals exist because scheduled communication saves battery
• channel hopping exists because 2.4 GHz is crowded
• GATT exists because most BLE devices exchange small structured state
• multiple PHYs exist because range and airtime trade against each other

Once you see BLE as a scheduling and duty-cycle protocol, not just a radio, the whole stack makes more sense.

21. Why BLE Keeps Winning Embedded Products

BLE is not the best radio in every dimension. It is not the longest-range, the fastest, or the simplest protocol to debug. But it fits a huge number of commercial problems unusually well.

It gives product teams:

• smartphone compatibility out of the box
• low energy operation
• acceptable range for personal-area and room-scale use
• mature silicon availability from Nordic, TI, Dialog (Renesas), Espressif, Silicon Labs, and others
• standardised service models where they help
• enough flexibility for custom profiles where they do not

That combination is hard to beat. A smart lock in Lisbon, a heart-rate strap in Berlin, and a temperature beacon in a warehouse outside Athens do not need the same application logic, but they often need the same transport qualities: low power, cheap silicon, and reliable short-burst communication with phones or gateways.

The ecosystem continues to expand. BLE 5.3 added Channel Classification Enhancement and Connection Subrating (allowing dynamic changes to connection intervals without renegotiation). BLE 5.4 added Periodic Advertising with Responses (PAwR), designed for electronic shelf labels where a central device broadcasts pricing data and individual labels respond only when they need updates. Ericsson, Nokia, and several European semiconductor companies continue pushing the specification forward through the Bluetooth SIG.

That is BLE's real strength. It is not exciting because it is glamorous. It is successful because its constraints match real products.