6 Bluetooth Architecture
- Piconet: The basic Bluetooth network topology: one master device and up to 7 active slaves sharing a time-division channel
- Scatternet: Network formed by two or more overlapping piconets, where a bridge device participates as master in one piconet and slave in another
- FHSS (Frequency Hopping Spread Spectrum): Classic Bluetooth’s interference avoidance mechanism; hops across 79 × 1 MHz channels at 1600 hops/second using a pseudo-random sequence derived from the master’s clock and address
- BLE Channel Map: 40 channels (2 MHz wide each); 3 fixed advertising channels (37=2402 MHz, 38=2426 MHz, 39=2480 MHz) placed to avoid Wi-Fi overlap; 37 data channels with adaptive frequency hopping
- HCI (Host Controller Interface): Standardized command/event API between the Bluetooth host stack (on application CPU) and controller (on radio chip)
- L2CAP Segmentation: Layer that fragments large application payloads into MTU-sized ATT/RFCOMM PDUs for transmission over the air
- RFCOMM: Classic Bluetooth serial port emulation protocol (SPP profile) built on L2CAP, providing RS-232 cable replacement semantics
- Bluetooth SIG: Standards body that maintains Bluetooth specifications and manages the adopted profiles registry
6.1 Learning Objectives
By the end of this chapter, you will be able to:
- Distinguish between Classic Bluetooth and BLE and justify when to select each technology for a given IoT application
- Analyze the Bluetooth protocol stack including the Host Controller Interface (HCI), L2CAP, and GATT layers
- Explain piconet and scatternet topologies and their role limitations (central, peripheral, observer, broadcaster)
- Apply the BLE advertising and connection process from discovery through bonding to configure a working BLE system
- Evaluate Bluetooth for IoT applications considering power, range, data rate, and interoperability trade-offs
- Design a GATT service hierarchy for a BLE IoT sensor with appropriate characteristic properties
If you take away only three things from this chapter:
- Bluetooth has two distinct radio systems – Classic Bluetooth (BR/EDR) is optimized for continuous streaming (audio, file transfer) at milliamp power levels, while BLE is designed for intermittent sensor data at microamp levels with months-to-years battery life. They share the 2.4 GHz band but are NOT backward compatible.
- GATT (Generic Attribute Profile) is the data architecture of BLE – it organizes data into Services (collections of related data) and Characteristics (individual data points with read/write/notify properties), identified by standardized UUIDs. Understanding GATT is essential for any BLE IoT project.
- The advertising/scanning mechanism is what makes BLE power-efficient – instead of maintaining always-on connections, BLE devices broadcast short advertisement packets at configurable intervals (20 ms to 10.24 s), and central devices scan periodically. This asymmetric design lets peripherals sleep over 99% of the time.
Hey Sensor Squad! Imagine our friends are at a playground and they need to talk to each other wirelessly.
Sammy the Sensor is wearing a fitness tracker. Every few seconds, it shouts out “Hey! I’m Sammy’s tracker! I have heart rate data!” – that is like BLE advertising. Sammy’s tracker does not need to shout all the time, so it takes little naps between shouts to save battery. That is why fitness trackers last for months!
Lila the LED has Bluetooth headphones. She is streaming music from her phone – a constant flow of sound data. That is Classic Bluetooth – like having a long phone call. It uses more battery because the connection stays open the whole time.
Max the Microcontroller is the “boss” (the central device). He connects to up to 7 friends at once in a group called a piconet. Think of Max standing in the middle of a circle with friends around him – he takes turns talking to each one. “Sammy, what’s your heart rate? Bella, what’s the temperature?”
Bella the Buzzer has a smart lock on her treehouse. When Max’s phone gets close, Bella’s lock detects it and unlocks automatically. But first, they have to do a secret handshake called pairing – Max types a code, and now they trust each other forever (that is bonding!).
Why two types? It is like the difference between sending a text message (BLE – quick, saves battery) and making a video call (Classic – lots of data, uses more power). You pick the right one for the job!
Real-world example: Your smart home might use BLE for door sensors (tiny battery, sends “open/closed” a few times a day) and Classic Bluetooth for your wireless speaker (streaming music continuously).
6.2 Overview
Bluetooth is one of the most ubiquitous wireless technologies in IoT, powering everything from fitness trackers and smart locks to industrial sensors and building automation systems. This chapter series provides a comprehensive guide to Bluetooth technology, covering both Classic Bluetooth and Bluetooth Low Energy (BLE).
The simple explanation: Bluetooth is a wireless technology that lets devices communicate over short distances (typically 1-100 meters) without wires. It was originally designed to replace serial cables, and has evolved into the backbone of wearable and smart home IoT.
An analogy: Think of Bluetooth like a wireless conversation between two devices that are close together. Just like how you can talk to a friend standing next to you without needing a phone line, Bluetooth lets devices “talk” to each other without wires.
Two types of Bluetooth:
- Classic Bluetooth (BR/EDR): Like a phone call – good for long, continuous conversations (music streaming, file transfers). Uses more power.
- BLE (Bluetooth Low Energy): Like text messages – quick updates, then the device goes back to sleep (fitness trackers, door sensors, beacons). Uses very little power.
Key terms to know:
| Term | Meaning |
|---|---|
| BLE | Bluetooth Low Energy – the low-power variant designed for IoT |
| GATT | Generic Attribute Profile – how BLE organizes and exchanges data |
| Piconet | A small Bluetooth network with 1 central and up to 7 peripherals |
| Advertising | BLE devices broadcasting their presence to be discovered |
| Pairing/Bonding | Security handshake that establishes trust between devices |
| Profile | A predefined behavior pattern (e.g., heart rate, audio) |
Where is it used? Fitness wearables, smart locks, asset tracking beacons, medical devices, smart home sensors, industrial monitoring, and retail proximity marketing.
Why not just use Wi-Fi? Wi-Fi uses 100-1000x more power than BLE. A BLE sensor can run for 2+ years on a coin cell battery, while a Wi-Fi sensor might last only days. Bluetooth is the right choice when you need low power, short range, and simple device-to-device communication.
6.2.1 Bluetooth Protocol Architecture
The Bluetooth protocol stack is divided into two main parts: the Controller (hardware) and the Host (software), connected by the Host Controller Interface (HCI). This separation allows different hardware and software implementations to interoperate.
6.2.2 BLE Advertising and Connection Process
The following sequence diagram shows how a BLE peripheral (sensor) advertises its presence, a central device (phone/gateway) scans and discovers it, and the connection is established through a well-defined handshake.
BLE uses three dedicated advertising channels: channel 37 at 2402 MHz, channel 38 at 2426 MHz, and channel 39 at 2480 MHz. These frequencies are deliberately spread across the 2.4 GHz band to avoid the busiest Wi-Fi channels (1, 6, and 11). The remaining 37 channels are used for data after a connection is established.
6.2.3 GATT Data Model
GATT (Generic Attribute Profile) organizes BLE data into a hierarchical structure of Profiles, Services, and Characteristics. This diagram shows the data model for a typical IoT environmental sensor.
6.2.4 Piconet and Scatternet Topology
Bluetooth devices organize into piconets (one central, up to seven active peripherals). Multiple piconets can overlap to form scatternets, where a device participates in multiple piconets by time-division multiplexing.
6.2.5 Classic Bluetooth vs BLE Decision Tree
Use this decision tree to determine whether Classic Bluetooth or BLE is the right choice for your IoT application.
6.3 Chapter Series
This comprehensive topic has been organized into focused chapters for easier learning:
6.3.1 Core Concepts
| Chapter | Description | Reading Time |
|---|---|---|
| Classic Bluetooth vs BLE | Evolution, differences, power consumption | 15 min |
| Bluetooth Topologies | Star, broadcast, mesh configurations | 12 min |
| Piconet Architecture | Central/peripheral roles, 7-device limit | 10 min |
| Connection Establishment | Discovery, pairing, bonding | 15 min |
| Protocol Stack | GATT architecture, notifications | 12 min |
| Bluetooth Profiles | SPP, HID, A2DP, HFP | 10 min |
6.3.2 Hands-On Learning
| Chapter | Description | Time |
|---|---|---|
| Hands-On Lab | Build BLE sensor beacon (Wokwi) | 30 min |
6.4 Quick Comparison
| Aspect | Classic Bluetooth | BLE |
|---|---|---|
| Bluetooth Version | 1.0 - 3.0+ (BR/EDR) | 4.0+ (LE) |
| Purpose | Audio streaming, files | Sensors, beacons |
| Power | Medium (30-100 mA) | Very low (10-50 uA avg) |
| Battery Life | Days-weeks | Months-years |
| Data Rate | 1-3 Mbps | 125 kbps (LE Coded), 1 Mbps (LE 1M), 2 Mbps (LE 2M in BLE 5.0) |
| Range | ~10-100 m | ~10-100 m (up to 400 m BLE 5) |
| Channels | 79 (1 MHz each) | 40 (2 MHz each, 3 advertising at 37/38/39) |
| Latency | ~100 ms | ~6 ms |
| Topology | Piconet (star) | Star, broadcast, mesh |
| Best For | Headphones, speakers | Fitness trackers, locks, sensors |
1. Assuming BLE is backward compatible with Classic Bluetooth. Classic and BLE are entirely separate radio systems sharing only the 2.4 GHz band. A BLE-only device cannot communicate with a Classic-only device. “Dual-mode” chips support both, but at increased cost and power. Always check that both devices support the same protocol variant.
2. Setting advertising intervals too short for battery-powered devices. An advertising interval of 20 ms (minimum) can drain a CR2032 coin cell in days. For most IoT sensors, intervals of 1-10 seconds provide adequate discovery time while enabling multi-year battery life. Only use short intervals for latency-critical applications like asset tracking.
3. Ignoring connection parameter negotiation. Default connection parameters are often suboptimal. A connection interval of 7.5 ms (minimum) keeps both devices awake frequently, wasting power. For sensor data reported every few seconds, use longer connection intervals (500 ms-4 s) with peripheral latency to skip unnecessary connection events.
4. Not implementing bonding for persistent IoT deployments. Pairing establishes temporary security keys; bonding stores them persistently. Without bonding, devices must re-pair after every power cycle, causing user friction and security exposure. Always implement bonding for production IoT devices.
5. Exceeding the 7-device active piconet limit without awareness. A Bluetooth central can maintain connections to only 7 active peripherals simultaneously. Designs requiring more connections need connection multiplexing (connect/disconnect cycling), scatternet bridging, or Bluetooth Mesh (which uses connectionless advertising, not piconets).
6.5 Worked Example: Designing a BLE Environmental Monitoring System
Scenario: You are designing a BLE-based environmental monitoring system for a small office (15 x 15 meters). The system needs 12 battery-powered sensors (temperature, humidity, CO2) reporting to a single gateway every 30 seconds. Each sensor uses a CR2032 coin cell (220 mAh). The system must operate for at least 18 months without battery replacement.
Step 1: Choose BLE vs Classic Bluetooth
- Sensors send ~20 bytes of data every 30 seconds – intermittent, low data rate
- Battery life requirement of 18 months rules out Classic Bluetooth (milliamp current draw)
- No audio or high-throughput requirements
- Decision: BLE is the correct choice
Step 2: Calculate Advertising Parameters
For sensors reporting every 30 seconds, we do not need fast advertising. Using a connection-based approach:
- Advertising interval: 1 second (1000 ms) – balance between discovery time and power
- Advertising duration: 10 seconds max before connection
- Average advertising current: ~15 uA at 1-second interval
Step 3: Optimize Connection Parameters
- Connection interval: 1 second (1000 ms) – sensor only wakes once per second when connected
- Peripheral latency: 29 – sensor can skip 29 out of 30 connection events, waking only to send data
- Supervision timeout: 10 seconds – detect lost connections
- Effective wake frequency: once every 30 seconds
Step 4: Estimate Battery Life
| State | Current | Duty Cycle | Average |
|---|---|---|---|
| Sleep | 1 uA | 99.9% | 0.999 uA |
| Advertising (startup) | 8 mA | 0.05% | 4.0 uA |
| Connected TX | 12 mA | 0.01% | 1.2 uA |
| Processing | 5 mA | 0.005% | 0.25 uA |
| Total average | ~6.4 uA |
Battery life = 220 mAh / 0.0064 mA = 34,375 hours = ~3.9 years
This exceeds the 18-month requirement with significant margin, allowing for component variation and aging.
Step 5: Address the 12-Sensor Limit
A single BLE central supports 7 active connections. With 12 sensors, we have two options:
- Option A: Connection cycling – Gateway connects to 7 sensors, collects data, disconnects, then connects to the remaining 5. With 30-second reporting, there is ample time.
- Option B: Two gateways – Each handles 6 sensors. More reliable but higher infrastructure cost.
Decision: Option A is sufficient since the 30-second reporting interval allows time for connection cycling across all 12 sensors within each reporting period.
Step 6: GATT Service Design
Environmental Sensor Profile
+-- Environmental Sensing Service (0x181A)
| +-- Temperature (0x2A6E) [Read, Notify] sint16 x 0.01
| +-- Humidity (0x2A6F) [Read, Notify] uint16 x 0.01
+-- Custom CO2 Service (128-bit UUID)
| +-- CO2 Level [Read, Notify] uint16 ppm
+-- Battery Service (0x180F)
+-- Battery Level (0x2A19) [Read, Notify] uint8 %Result: The system achieves 3.9 years battery life (exceeding the 18-month target), accommodates all 12 sensors through connection cycling, and uses standardized GATT services for interoperability.
6.6 Knowledge Check
Test your understanding of Bluetooth fundamentals with these questions:
6.7 Learning Paths
Quick Start (1 hour):
- Classic vs BLE - Understand the difference
- Hands-On Lab - Build something
Full Coverage (3+ hours):
- Classic vs BLE
- Topologies
- Piconet Architecture
- Connection Establishment
- Protocol Stack
- Profiles
- Hands-On Lab
6.8 Worked Example: BLE Coin Cell Battery Life for a Door Sensor
A smart home door sensor uses BLE to notify a hub each time the door opens or closes. The sensor runs on a CR2032 coin cell (225 mAh). Estimate battery life under realistic usage.
Device Behavior:
- Door events: average 20 open/close cycles per day (40 BLE notifications)
- Each notification: wake from sleep, send 1 BLE advertisement packet, return to sleep
- Once per hour: send a heartbeat/battery status advertisement (24 per day)
- Total daily transmissions: 40 + 24 = 64
Power Profile:
| State | Current | Duration per Event | Events/Day | Daily Charge |
|---|---|---|---|---|
| Deep sleep | 1.5 uA | 23.97 hours | continuous | 35.96 uAh |
| Wake + TX (notification) | 8 mA | 3 ms | 40 | 0.267 uAh |
| Wake + TX (heartbeat) | 8 mA | 3 ms | 24 | 0.160 uAh |
| MCU processing (reed switch ISR) | 3 mA | 0.5 ms | 40 | 0.017 uAh |
| Total daily | 36.40 uAh |
Battery Life Calculation:
\[ \text{Battery life} = \frac{225{,}000 \text{ uAh}}{36.40 \text{ uAh/day}} = 6{,}181 \text{ days} = 16.9 \text{ years (theoretical)} \]
Apply Derating Factors:
| Factor | Multiplier | Reasoning |
|---|---|---|
| Usable capacity (CR2032 self-discharge) | 0.85 | 15% lost over 5 years |
| Temperature variation | 0.90 | Cold weather reduces capacity |
| Quiescent current variability | 0.80 | Real chips draw 2-5 uA, not ideal 1.5 uA |
| Combined | 0.612 |
\[ \text{Practical life} = 16.9 \times 0.612 = \textbf{10.3 years} \]
Sensitivity Analysis – What Drains Batteries Faster?
| Change | New Battery Life | Impact |
|---|---|---|
| Baseline (above) | 10.3 years | - |
| Busy door (80 events/day) | 9.8 years | -5% (TX energy is tiny) |
| Connected mode instead of advertising | 2.1 years | -80% (connection overhead dominates) |
| 100 ms advertising interval (always advertising) | 48 days | -99% (continuous advertising kills battery) |
| Add temperature sensor reading (2 mA, 50 ms, 24x/day) | 8.7 years | -16% |
The critical insight: for event-driven BLE sensors, sleep current dominates battery life, not transmission energy. The 1.5 uA sleep current accounts for 99.3% of daily energy. Choosing a BLE SoC with 1 uA sleep current instead of 3 uA doubles effective battery life. Conversely, keeping BLE connected (even with peripheral latency) or advertising continuously destroys battery life because the radio never fully sleeps.
Sleep current’s impact on battery life is nonlinear. Consider a CR2032 (225 mAh) door sensor with 40 daily events.
\[\text{Daily Energy} = \text{Sleep Current} \times 24\text{h} + \text{Event Energy} \times \text{Events}\]
With 1.5µA sleep: \(1.5\mu\text{A} \times 24\text{h} + 0.267\text{mAh} = 36.27\mu\text{Ah/day}\)
\[\frac{225{,}000\mu\text{Ah}}{36.27\mu\text{Ah/day}} \approx 6{,}205 \text{ days} = 17 \text{ years}\]
With 5µA sleep: \(5\mu\text{A} \times 24\text{h} = 120\mu\text{Ah}\) dominates → only 5.1 years. Triple the sleep current cuts battery life by 70%.
6.9 Summary and Key Takeaways
Bluetooth is a foundational short-range wireless technology for IoT, with two distinct variants serving different application needs. This chapter introduced the core architecture and design considerations.
Architecture and Protocol Stack:
- The Bluetooth stack separates into Host (GATT, ATT, L2CAP) and Controller (Link Layer, PHY), connected by HCI
- GATT organizes data into Services and Characteristics with typed properties (Read, Write, Notify, Indicate)
- The 2.4 GHz ISM band is shared between Classic (79 channels) and BLE (40 channels, 3 dedicated to advertising)
Classic vs BLE:
- Classic Bluetooth (BR/EDR) supports 1-3 Mbps for continuous streaming (audio, file transfer) at milliamp power levels
- BLE supports 125 kbps (LE Coded) to 2 Mbps (LE 2M, BLE 5.0) for intermittent data at microamp average power, enabling multi-year coin cell operation
- They are NOT backward compatible – dual-mode chips are needed if both variants must be supported
Topology and Scaling:
- Piconet: Star topology with 1 central and up to 7 active peripherals
- Scatternet: Bridge nodes interconnect multiple piconets via time-division multiplexing
- Bluetooth Mesh: Connectionless flooding network supporting up to 32,000 nodes for building-scale IoT
Power Optimization Essentials:
- Advertising interval is the primary lever for BLE power consumption (20 ms to 10.24 s)
- Connection parameters (interval, peripheral latency, supervision timeout) determine connected-mode power
- A well-optimized BLE sensor drawing ~5-10 uA average can operate 2-4 years on a CR2032 coin cell
Design Decision Framework:
- Use Classic Bluetooth when: continuous audio streaming, sustained throughput > 1 Mbps, or legacy device compatibility is needed
- Use BLE when: battery life is critical, data is intermittent, or mesh networking is required
- Use Bluetooth Mesh when: building-scale coverage with hundreds of nodes is needed without infrastructure
6.10 What’s Next
| Next Chapter | Topic | Why Read It |
|---|---|---|
| Classic Bluetooth vs BLE | Side-by-side comparison of BR/EDR and LE variants | Solidify your ability to select the right Bluetooth variant for any IoT scenario |
| Bluetooth Topologies | Star, broadcast, and mesh network configurations | Design multi-device Bluetooth networks beyond the simple central-peripheral pair |
| Piconet Architecture | Central/peripheral roles and the 7-device limit | Implement connection cycling and understand scatternet bridging |
| Connection Establishment | Discovery, pairing, and bonding procedures | Configure secure BLE connections and troubleshoot pairing failures |
| Protocol Stack | GATT service hierarchy, ATT operations, notifications | Design and implement custom GATT services for IoT sensor data |
| Hands-On Lab | Build a BLE sensor beacon in Wokwi (ESP32) | Apply everything from this chapter in a working BLE simulation |
Deep Dives:
- Bluetooth Security - Encryption and pairing
- Bluetooth Applications - Real-world deployments
Comparisons:
- Zigbee Fundamentals - Mesh networking
- Thread Operation - IPv6-based mesh
- LPWAN Comparison - Long-range options