ES: Bluetooth Fundamentals

It is maintained by the Bluetooth Special Interest Group (Bluetooth SIG).

At the RF level:

• Frequency band: 2.402 GHz – 2.480 GHz
• Channel width:
• Classic: 1 MHz
• BLE: 2 MHz
• Modulation:
• Classic: GFSK / π/4-DQPSK / 8DPSK
• BLE: GFSK only

Classic Bluetooth

When we speak about Classic Bluetooth, we are referring to BR/EDR (Basic Rate / Enhanced Data Rate) defined by the Bluetooth Special Interest Group and originally introduced in Bluetooth 1.0.

Classic Bluetooth was designed for:

• Continuous streaming
• Higher throughput
• Audio transport
• Cable replacement

Classic Bluetooth operates in the unlicensed 2.4 GHz ISM band. This band is shared with WiFi, Zigbee, and many other devices, making interference management critical.

Key physical parameters:

• Frequency range: 2.402 GHz – 2.480 GHz
• 79 channels
• 1 MHz per channel
• 1600 frequency hops per second
• Gaussian Frequency Shift Keying (GFSK) for BR

Because the band is noisy, Bluetooth uses Frequency Hopping Spread Spectrum (FHSS) to improve resilience.

• 1600 hops per second

Why Frequency Hopping?

Because the 2.4 GHz band is noisy:

• WiFi
• Microwave ovens
• Zigbee
• Other Bluetooth devices

Instead of staying on one frequency, it hops:

Time →
Channel:
   10 → 45 → 2 → 67 → 19 → 55 → 1 → ...

Modulation and Data Rates

Classic Bluetooth supports:

• 1 Mbps (BR) - Basic Rate
• 2 Mbps (EDR) - Enhanced Data Rate
• 3 Mbps (EDR)

Modulation types:

• GFSK (Basic Rate)
• π/4-DQPSK (2 Mbps)
• 8-DPSK (3 Mbps)

Higher rate → less robustness → more sensitive to interference.

Network Topology

Classic Bluetooth forms a Piconet, which is a master-slave star topology.

In a Piconet:

• One device acts as Master
• Up to 7 active Slaves
• Master controls clock and hopping
• Slaves synchronize to Master

        Slave1
           |
Slave2 — Master — Slave3
           |
        Slave4

The master:

• Controls clock
• Controls frequency hopping
• Allocates time slots

Slaves cannot talk directly. All traffic passes through master.

Time Division Duplexing and Slots

Classic Bluetooth uses Time Division Duplex (TDD) with fixed time slots of 625 microseconds. Communication is structured and deterministic.

Transmission rules:

• Master transmits on even slots
• Slave responds on odd slots
• Packets may occupy 1, 3, or 5 slots

Time →
Slot 0: Master TX
Slot 1: Slave TX
Slot 2: Master TX
Slot 3: Slave TX

Engineering implications:

• Predictable timing simplifies RF coexistence
• Multi-slot packets increase throughput
• Missed slots cause retransmissions

Security insight:

• If attacker predicts clock → predicts hopping sequence
• Timing analysis can leak synchronization data

Logical Link Types — SCO and ACL

Classic Bluetooth defines two primary logical links that determine communication behavior.

• SCO (Synchronous Connection-Oriented)
• ACL (Asynchronous Connection-Less)

SCO (Synchronous Connection-Oriented) is designed for real-time audio.

Characteristics:

• Fixed reserved slots
• Low latency
• No retransmission
• Constant bandwidth

Used in:

• Headsets
• Hands-free devices
• Car audio systems

ACL (Asynchronous Connection-Less) is designed for data transfer.

Characteristics:

• Retransmission supported
• Flow control
• Error detection
• Variable bandwidth

Used in:

• File transfer
• Serial Port Profile (SPP)
• Configuration data

SCO → Real-time → No retry
ACL → Data      → Retry on error

Protocol Stack Architecture

Classic Bluetooth follows a layered architecture separating RF hardware from application logic.

Stack overview:

Application
   |
Profiles (SPP, A2DP, HFP)
   |
RFCOMM
   |
L2CAP
   |
HCI
   |
Baseband
   |
RF

Each layer has a clear responsibility.

Baseband:

• Frequency hopping
• Slot timing
• Packet assembly

HCI (Host Controller Interface):

• Communication between MCU and controller
• UART / USB / SPI transport
• Command and event interface

txt

STM32 (Host)
   |
   | UART
   |
BT Module (Controller + RF)

L2CAP (Logical Link Control and Adaptation Protocol):

• Multiplexing higher protocols
• Packet segmentation
• QoS management

RFCOMM (Emulates RS-232 serial port.):

• Serial cable emulation
• Used in SPP (Serial Port Profile (SPP))

Embedded system architecture example:

MCU + RTOS
   |
   | UART (HCI)
   |
Bluetooth Module
   |
Antenna

Connection Cycle

Bluetooth Classic (BR/EDR = Basic Rate / Enhanced Data Rate) is designed for:

• Audio streaming
• Continuous data
• High throughput

Examples:

• Headphones
• Speakers
• Car infotainment

Classic Bluetooth is connection-heavy and session-oriented.

Step 1 — Inquiry (Device Discovery)

A device looking for others enters Inquiry Mode.

Master ---- Inquiry ---->
Device A --- Response --->
Device B --- Response --->

Master (Inquiry)  
↓  
Broadcasts Inquiry Packets  
↓  
Nearby devices respond with:  
- BD_ADDR (Bluetooth Device Address)  
- Clock information  
- Class of device

This phase is power expensive.

Step 2 — Paging (Connection Establishment)

After selecting a device:

Master ---- Page Request ---->
Slave  ---- Page Response --->

Now a physical link is established.

Step 3 — Link Setup

The devices negotiate:

• Role (Master/Slave)
• Clock synchronization
• Frequency hopping pattern

Classic Bluetooth uses:

txt

79 channels
1 MHz spacing
Frequency hopping at 1600 hops/sec

Step 4 — L2CAP Channel Setup

Logical channels are established using:

• L2CAP (Logical Link Control and Adaptation Protocol)

Then higher protocols:

• RFCOMM (serial emulation)
• A2DP (Advanced Audio Distribution Profile)
• HFP (Hands-Free Profile)

Example audio stack:

Application (Music)
   ↓
A2DP
   ↓
L2CAP
   ↓
Baseband
   ↓
Radio

Step 5 — Pairing & Encryption

Security happens via:

• PIN-based pairing (legacy)
• Secure Simple Pairing (SSP)

Encryption uses E0 (older) or AES in modern devices.

Step 6 — Active Continuous Connection

Classic Bluetooth remains active continuously:

Current
   ^
   |~~~~~~~~~~~~~~ Constant RF activity ~~~~~~~~~~~~~
   +-----------------------------------------------> Time

Power usage = High

Step 7 — Disconnect

Connection terminates explicitly: Master ---- Disconnect ---->

Bluetooth Profiles and Application Layer

Profiles define how devices behave at the application level. They standardize interoperability between vendors.

They sit at the top of the Bluetooth stack and standardize application-level behavior so devices from different vendors can interoperate.

Profiles are defined by the Bluetooth Special Interest Group.

Without profiles, two Bluetooth devices would connect physically — but would not know:

• What services are available
• What data format to use
• How to interpret commands
• How to maintain session rules

Profiles solve interoperability.

Common Classic profiles:

• SPP (Serial Port Profile)
• A2DP (Advanced Audio Distribution Profile)
• HFP (Hands-Free Profile)
• HID (Human Interface Device) (Keyboard/Mouse)

Example flow for audio streaming: Phone → A2DP → Headset

Design considerations:

• Only enable required profiles
• Disable unused services
• Validate profile security requirements

Pairing and Security Mechanisms

Classic Bluetooth security evolved significantly over time. Early versions relied on PIN-based pairing, which was vulnerable.

Modern versions use Secure Simple Pairing (SSP) with ECDH.

Security modes:

• Mode 1: No security
• Mode 2: Service-level security
• Mode 3: Link-level security
• Mode 4: Secure Simple Pairing (mandatory in modern stacks)

Security elements:

• Link keys
• Encryption keys
• Authentication mechanisms

Common attacks:

• BlueSnarfing
• MITM during pairing
• Downgrade attacks
• Weak PIN brute force

Mitigation strategies:

• Enforce SSP only
• Disable legacy pairing
• Require authenticated pairing
• Keep stack updated
• Remove unused profiles

Power Consumption Characteristics

Classic Bluetooth was not designed for ultra-low power IoT sensors. It assumes longer connection intervals and continuous streaming.

Power characteristics:

• Continuous radio activity
• Frequent slot usage
• Higher duty cycle

Comparison:

Classic BT → Audio / streaming
BLE        → Sensors / low duty

Design implication:

• Not ideal for battery-powered sensors
• Suitable for audio or constant data streams

When to Use Classic Bluetooth

Classic Bluetooth remains relevant when the application requires sustained throughput or audio streaming.

Use Classic Bluetooth when:

• Continuous data streaming is needed
• Audio transport is required
• Legacy compatibility matters
• SPP cable replacement is needed

Avoid it when:

• Ultra-low power is critical
• Only small sensor packets are sent
• Mesh networking is required

Bluetooth Low Energy (BLE)

Bluetooth Low Energy (BLE) is not just a wireless protocol — it is a carefully engineered low-power communication system defined and maintained by the Bluetooth Special Interest Group (Bluetooth SIG).

Bluetooth Versions to BLE

BLE first appeared in Bluetooth 4.0 (2010).

But each version added important capabilities that impact embedded design decisions.

• Bluetooth 4.0
• Introduced Low Energy mode
• 1M PHY only
• Basic GATT
• Bluetooth 4.2
• LE Secure Connections (ECDH security)
• Data Length Extension (larger packets)
• Bluetooth 5.0
• 2M PHY (double speed)
• LE Coded PHY (long range)
• Extended advertising
• Bluetooth 5.1
• Direction Finding (AoA/AoD)
• Bluetooth 5.2
• LE Audio
• Isochronous Channels
• Bluetooth 5.4
• Encrypted advertising

So when you select a chip (ESP32, nRF52, STM32WB), always ask:

• Which Bluetooth version?
• Which PHY modes?
• Does it support LE Secure Connections?

This directly affects security, range, and throughput.

The Physical Layer (PHY) — Where Everything Starts

BLE operates in the 2.4 GHz ISM band: 2.400 GHz – 2.4835 GHz

It divides the band into 40 channels: |37|38|39|0|1|2|3| ... |36|

• Channels 37, 38, 39 → Advertising
• Channels 0–36 → Data
• Channel spacing = 2 MHz

Bluetooth 5 introduced multiple PHY modes:

• 1M PHY → 1 Mbps (default)
• 2M PHY → 2 Mbps (higher throughput)
• LE Coded S=2 → 500 kbps (longer range)
• LE Coded S=8 → 125 kbps (maximum range)

Range vs Speed relationship:

Higher Speed  → Shorter Range
Lower Speed   → Longer Range

This is achieved using Forward Error Correction (FEC).

And now that we understand the radio, we move to how BLE saves power using time.

The BLE Time Model — The Secret of Low Power

BLE is not continuous like WiFi.

It works using connection events.

<------ Connection Interval ------>

| TX | RX | Sleep | Sleep | Sleep |

Key parameters:

• Connection Interval (CI)
• Slave Latency
• Supervision Timeout

Example:

CI = 100 ms
Latency = 4

Effective wake-up = 100 × (4 + 1) = 500 ms

So the peripheral wakes up only every 500 ms.

That’s why coin-cell devices survive years.

This time-based design is controlled by the Link Layer.

The Protocol Stack — Layer by Layer

BLE uses a layered architecture.

Application
   |
  GATT
   |
  ATT
   |
  L2CAP
   |
  Link Layer
   |
   PHY

Each layer has a clear responsibility.

Link Layer (LL)

Controls:

• Connection establishment
• Channel hopping
• Acknowledgment
• Timing control

BLE uses Adaptive Frequency Hopping (AFH):

Packet 1 → Channel 5
Packet 2 → Channel 19
Packet 3 → Channel 33

This avoids WiFi interference.

L2CAP (Logical Link Control and Adaptation Protocol)

Handles:

• Multiplexing higher-level protocols
• Fragmenting large packets
• Reassembling data

Without L2CAP, large GATT packets would not work.

ATT (Attribute Protocol)

Everything in BLE is an attribute.

Structure: | Handle | Type | Value |

Operations:

• Read
• Write
• Notify
• Indicate

ATT is transaction-based.

GATT (Generic Attribute Profile)

Defines the structure of data exposed by a device.

Hierarchy:

Device
 └── Service
       └── Characteristic
             └── Descriptor

Example: Temperature Sensor

Service: Environmental Sensing
  Characteristic: Temperature
      Value: 24.5 °C

So GATT is like a structured database exposed over radio.

And now that data flows, we must secure it.

BLE Security Architecture

Security is handled by SMP (Security Manager Protocol).

BLE encryption uses: AES-CCM (128-bit)

Bluetooth 4.2 introduced: ECDH (Elliptic Curve Diffie-Hellman)

Key types:

• STK → Short Term Key
• LTK → Long Term Key
• IRK → Identity Resolving Key
• CSRK → Signature Key

Security Levels:

• Just Works (no MITM protection)
• Passkey
• Numeric Comparison
• Out Of Band (OOB)

Secure Design Rule:

• Never ship production IoT with Just Works
• Always enable LE Secure Connections
• Store bonding keys securely

BLE Packet Structure (Bit-Level View)

Each BLE packet looks like this:

| Preamble (1B) |
| Access Address (4B) |
| Header (2B) |
| Payload (0–251B) |
| CRC (3B) |

Data Length Extension (DLE) allows: Payload up to 251 bytes

Throughput depends on:

• PHY mode
• Connection interval
• Packet length

Throughput conceptually: Throughput ≈ Payload / Connection Interval

BLE Connection Cycle

BLE is event-driven and power-optimized.

Designed for:

• Sensors
• Wearables
• IoT nodes
• Intermittent data

The lifecycle is fundamentally different.

Step 1 — Advertising

Peripheral sends small packets periodically.

Peripheral ---- ADV ---->
Peripheral ---- ADV ---->
Peripheral ---- ADV ---->

Advertising interval: 20 ms → 10.24 seconds

Advertising channels: 37 | 38 | 39

This phase is very low duty cycle.

Step 2 — Scanning

Central device scans:

Central (Scanner)
     ↓
Listens on advertising channels

Optional:

Central ---- Scan Request ---->
Peripheral ---- Scan Response --->

Step 3 — Connection Request

When central decides to connect:

Central ---- CONNECT_REQ ---->
Peripheral → switches to data channels

Now Link Layer connection is established.

Step 4 — Connection Events Begin

BLE uses connection events instead of continuous streaming.

<------ Connection Interval ------>

| TX | RX | Sleep | Sleep | Sleep |

Parameters negotiated:

• Connection Interval
• Slave Latency
• Supervision Timeout

Example:

CI = 100 ms
Latency = 4

Peripheral wakes every 500 ms

This is the power magic.

Step 5 — Service Discovery (GATT)

Central discovers services:

Central → Read by Group Type
Peripheral → Service UUIDs

Structure:

Device
 └── Service
       └── Characteristic
             └── Descriptor

This is database-driven communication.

Step 6 — Pairing & Bonding

Handled by SMP (Security Manager Protocol).

Methods:

• Just Works
• Passkey
• Numeric Comparison
• OOB

Modern BLE uses: ECDH + AES-CCM

Keys stored for bonding.

Step 7 — Data Exchange

Using:

• Read
• Write
• Notify
• Indicate

Example:

Peripheral → Notify Temperature
Central → ACK

Only during connection events.

Step 8 — Supervision or Disconnect

If no packets received within: Supervision Timeout

Connection drops automatically.

Or central disconnects explicitly.

Classic Bluetooth vs BLE

Classic Bluetooth = Persistent streaming session.

BLE = Scheduled burst communication engine.

That difference changes everything:

• Hardware design
• Power budget
• Security model
• Firmware architecture
• Product lifetime