10  Bluetooth Network Architecture

Piconets, Scatternets, and Power Classes

Keywords

bluetooth, piconet, scatternet, master-slave, power class, network topology

In 60 Seconds

Bluetooth networks use a piconet topology where one master device controls up to 7 active slaves using time-division multiplexing. Power classes (1, 2, 3) determine range from 1m to 100m, and scatternets connect multiple piconets for larger deployments. For modern IoT needing more than 7 devices, consider BLE Mesh (32,000+ nodes).

Key Concepts

• Piconet Master: Device controlling the hopping sequence and time slots in a Classic Bluetooth piconet; all slaves synchronize their clocks to the master
• Scatternet Bridge: Device participating as master in one piconet and slave in another, forwarding traffic between the two networks
• BLE Star Topology: Standard BLE network shape where one central device maintains simultaneous connections to multiple peripherals (up to ~20 on ESP32)
• BLE Mesh Provisioner: Device that onboards unprovisioned nodes into a Bluetooth Mesh network by assigning unicast addresses and distributing network/application keys
• Relay Node: BLE Mesh node that re-broadcasts received mesh messages to extend the network beyond direct radio range, implementing managed flooding
• Subnet: Logical BLE Mesh network partition sharing a Network Key (NetKey); enables traffic isolation within a larger physical mesh
• TTL (Time To Live): BLE Mesh field (0–127) decremented at each relay hop; message is discarded when TTL reaches 0, preventing infinite flooding loops
• Friend/Low Power Node Pair: BLE Mesh optimization where a mains-powered Friend node buffers messages for a sleepy Low Power Node, enabling battery-operated mesh devices

Minimum Viable Understanding

Bluetooth networks use a piconet topology where one master device controls up to 7 active slave devices using time-division multiplexing. Power classes (Class 1, 2, 3) determine transmission range from 1m to 100m, and scatternets connect multiple piconets via bridge devices for larger deployments. For modern IoT requiring more than 7 devices, consider BLE Mesh (32,000+ nodes) or connection rotation strategies.

10.1 Learning Objectives

By the end of this chapter, you will be able to:

• Explain the piconet topology and master-slave relationship in Classic Bluetooth
• Analyze the 7-device active slave limitation and its implications for IoT design
• Compare Bluetooth power classes and their range characteristics
• Design Bluetooth network architectures for IoT applications using piconets, scatternets, and BLE Mesh
• Calculate connection parameter impacts on battery life for BLE-connected sensors
• Distinguish between scatternet and BLE Mesh topologies and justify when to select each

10.2 Introduction

Bluetooth networks use a specific topology called a piconet - a small network with one master device and up to seven active slave devices. Understanding this architecture is essential for designing IoT systems that effectively use Bluetooth connectivity.

This chapter explores the fundamental network structures, power classes that determine range, and how scatternets can extend connectivity beyond the basic piconet limitations.

For Beginners: Master and Slave Devices

In Bluetooth, one device acts as the “boss” (master) and controls when other devices (slaves) can talk. It’s like a classroom where the teacher (master) calls on students (slaves) to speak.

Key Rules:

• Only 1 master per network
• Up to 7 active slaves can “speak”
• Slaves can only talk when the master allows them
• Slaves cannot talk directly to each other

Sensor Squad: The Bluetooth Classroom!

“A Bluetooth piconet is like a classroom!” Sammy the Sensor explained. “There is one teacher – the master device – who controls when each student gets to speak. Up to seven students – the slave devices – can be active at once. If I want to send my sensor data, I have to wait until the master calls on me!”

“Think of power classes like different-sized megaphones,” Lila the LED suggested. “A Class 3 device whispers across about one meter. A Class 2 device talks across a room at about ten meters. And a Class 1 device can shout across a whole football field at one hundred meters! Most IoT devices use Class 2 – just enough range without wasting energy.”

Max the Microcontroller added, “The really cool part is scatternets. When one piconet is not enough, a device can act as a bridge between two piconets, like a student who belongs to two different clubs and passes messages between them. This lets us connect way more than just seven devices!”

“But for really big networks,” Bella the Battery said, “we skip piconets entirely and use BLE Mesh. It can connect over thirty-two thousand devices across an entire building! And unlike Classic Bluetooth’s always-on piconet, BLE Mesh uses a flooding approach where messages hop from device to device, keeping my energy use nice and low.”

10.3 Piconet Architecture

A piconet is the fundamental Bluetooth network topology:

10.3.1 Structure

Figure 10.1: Piconet structure showing master device with 7 active slaves (3-bit AMA addressing) and parked slaves in standby.

10.3.2 Key Characteristics

Feature	Value	Description
Active Slaves	7 maximum	3-bit Active Member Address (AMA)
Parked Slaves	255 maximum	8-bit Parked Member Address (PMA)
Master	1 only	Controls timing and slot allocation
Addressing	3-bit AMA	001-111 for active slaves

10.3.3 Why Only 7 Active Slaves?

The limitation comes from the 3-bit Active Member Address (AMA) in the packet header:

• 3 bits = 2³ = 8 possible addresses (000-111)
• Address 000 is reserved for broadcast
• Addresses 001-111 available for 7 active slaves

Putting Numbers to It

How many bits would we need to support 50 active slaves?

To find the required address bits: \[ \text{Number of addresses} = 2^n \geq 51 \text{ (50 devices + 1 broadcast)} \]

Solving for \(n\): \[ 2^n \geq 51 \implies n \geq \log_2(51) \approx 5.67 \implies n = 6 \text{ bits} \]

With 6-bit addressing, we get \(2^6 = 64\) addresses. Reserving address 0 for broadcast leaves 63 usable addresses—enough for 50 active slaves.

Packet overhead impact: Expanding from 3 to 6 bits adds 3 bits (0.375 bytes) to every packet header. For a piconet transmitting 1,600 packets/second: \[ \text{Overhead} = 1{,}600 \times 0.375 = 600 \text{ bytes/second} = 4.8 \text{ kbps} \]

This represents only 0.16% of Bluetooth’s 3 Mbps capacity—a negligible cost. The 7-device limit was a design choice from the 1990s optimizing for low complexity, not a fundamental technical constraint.

7-Device Limitation Impact

This is a fundamental protocol constraint, not a hardware limitation. If your IoT application requires more than 7 simultaneously active devices:

1. Use BLE instead: Modern BLE supports 20+ concurrent connections
2. Deploy multiple piconets: Use scatternet topology
3. Use Bluetooth Mesh: Supports 32,000+ nodes
4. Time-division approach: Rotate which devices are active

10.3.4 Why Was Bluetooth Designed This Way?

When Bluetooth was first specified in the late 1990s, the designers made a deliberate trade-off. A 3-bit address field keeps the packet header compact (saving energy on every transmission) and the master’s scheduling logic simple (polling 7 slaves in round-robin is straightforward). At the time, the primary use case was replacing RS-232 serial cables between a PC and peripherals – a keyboard, mouse, headset, and printer rarely exceeded 4-5 devices. The 7-slave limit seemed generous.

The real lesson for IoT system designers: protocol constraints chosen for one era can become bottlenecks in another. BLE, designed 12 years later with IoT in mind, expanded the addressing and scheduling to support 20+ simultaneous connections, and BLE Mesh removed the limit entirely by shifting from connection-based to broadcast-based communication.

10.4 Master-Slave Communication

In a piconet, all communication flows through the master:

10.4.1 Time Division Multiplexing (TDM)

Figure 10.2: Bluetooth TDM showing master transmitting in even slots, slaves responding in odd slots.

10.4.2 Communication Rules

1. Master controls channel access using TDM
2. Master transmits in even time slots (0, 2, 4, …)
3. Slaves respond in odd time slots (1, 3, 5, …)
4. Slaves can ONLY transmit after being addressed by master

Slaves Cannot Communicate Directly

In a piconet, Slave A cannot send data directly to Slave B. All communication must route through the master:

Correct: Slave A → Master → Slave B (two hops)

Impossible: Slave A → Slave B (direct)

For direct peer-to-peer communication, use BLE Mesh or establish separate point-to-point connections.

Knowledge Check: Master-Slave Communication Flow

10.5 Power Classes and Range

Bluetooth devices are categorized into power classes that determine transmission range:

10.5.1 Power Class Comparison

Class	Max Power	Typical Range	Use Cases
Class 1	100 mW (20 dBm)	~100m	Industrial, warehouse scanners
Class 2	2.5 mW (4 dBm)	~10m	Smartphones, headphones, most IoT
Class 3	1 mW (0 dBm)	~1m	Ultra-low power wearables

Figure 10.3: Bluetooth power classes with typical ranges and use cases.

10.5.2 BLE 5.0 Extended Range

BLE 5.0 introduced Coded PHY for extended range:

PHY Mode	Data Rate	Range	Use Case
1M PHY	1 Mbps	~50m	Standard BLE
2M PHY	2 Mbps	~30m	High throughput
Coded (S=2)	500 kbps	~200m	Extended range
Coded (S=8)	125 kbps	~400m+	Long range IoT

10.6 Scatternet Topology

When applications require more than 7 devices or need inter-piconet communication, scatternets connect multiple piconets:

10.6.1 Scatternet Structure

Figure 10.4: Scatternet topology with bridge device connecting two piconets, enabling communication between networks.

10.6.2 Bridge Device Roles

A bridge device can participate in multiple piconets by:

1. Slave-Slave: Slave in both piconets (time-division participation)
2. Master-Slave: Master in one piconet, slave in another
3. Time-sharing: Alternates between piconets

Scatternet vs Mesh

Feature	Scatternet	BLE Mesh
Topology	Multiple connected piconets	Managed flooding
Scale	~20-50 devices	32,000+ devices
Complexity	High (manual bridging)	Lower (automatic routing)
Use Case	Legacy systems	Modern building automation

For new IoT deployments requiring many devices, BLE Mesh is recommended over scatternet.

10.7 Operating Modes and Power States

Bluetooth devices can operate in different power states to balance responsiveness with power consumption:

10.7.1 Power States

Figure 10.5: Bluetooth power states transitioning between Active, Sniff, Hold, and Park modes.

State	Description	Power	Wake-up Time
Active	Full communication	Highest	Immediate
Sniff	Listens at intervals	Medium	Fast
Hold	Scheduled burst mode	Low	Predetermined
Park	Synchronized standby	Lowest	Slow (~2s)

10.7.2 BLE Connection States

BLE uses a simpler connection state model:

Figure 10.6: BLE connection state machine showing transitions between Standby, Advertising, Scanning, Initiating, and Connection states.

10.8 Connection Parameters

BLE connection parameters significantly impact power consumption and latency:

10.8.1 Key Parameters

Parameter	Range	Description
Connection Interval	7.5ms - 4s	Time between connection events
Slave Latency	0 - 499	Number of events slave can skip
Supervision Timeout	100ms - 32s	Max time without communication

10.8.2 Parameter Impact

Figure 10.7: Connection interval tradeoffs between latency and power consumption.

Application	Recommended Interval	Slave Latency
Game controller	7.5-15ms	0
Fitness tracker	100-200ms	4-10
Environmental sensor	1000-4000ms	10-20
Beacon	Advertising only	N/A

10.8.3 Worked Example: Connection Parameter Power Impact

A heart rate monitor sends 4-byte readings every second. Compare two parameter configurations on a CR2032 (220 mAh):

Configuration A – Low latency (game controller)

• Connection interval: 15 ms, slave latency: 0
• Connection events per second: 1000 / 15 = 67 events
• Energy per empty event (wake + RX + sleep): ~25 uAs
• Energy for 1 data event: ~40 uAs
• Total per second: 66 x 25 + 1 x 40 = 1,690 uAs
• Average current: 1,690 uA = 1.69 mA
• Battery life: 220 mAh / 1.69 mA = 130 hours (5.4 days)

Configuration B – Power-optimized (fitness tracker)

• Connection interval: 200 ms, slave latency: 4
• Effective event rate: every 200 ms x (4+1) = every 1,000 ms
• Connection events per second: 1 event
• Energy per data event: ~40 uAs
• Total per second: 1 x 40 = 40 uAs
• Average current: 40 uA (plus ~2 uA sleep = 42 uA)
• Battery life: 220 mAh / 0.042 mA = 5,238 hours (218 days)

Result: Proper parameter tuning extends battery life from 5 days to 7 months – a 40x improvement – with identical data throughput (1 reading per second).

Try It: Connection Parameter Power Calculator

Adjust connection interval and peripheral latency to see how they affect battery life for a BLE sensor sending 1 reading per second.

viewof ciParam = Inputs.range([7.5, 4000], {step: 7.5, value: 200, label: "Connection Interval (ms)"})
viewof latParam = Inputs.range([0, 30], {step: 1, value: 4, label: "Peripheral Latency (skip N events)"})
viewof battParam = Inputs.range([50, 500], {step: 5, value: 220, label: "Battery Capacity (mAh)"})

{
  const effectiveWakeMs = ciParam * (latParam + 1);
  const eventsPerSec = 1000 / effectiveWakeMs;
  const energyPerEvent = 40; // uAs (wake + RX/TX)
  const sleepUA = 2; // uA
  const activeMs = 3; // ms per event
  const avgCurrentUA = (eventsPerSec * energyPerEvent) + sleepUA;
  const avgCurrentMA = avgCurrentUA / 1000;
  const lifeHours = battParam / avgCurrentMA;
  const lifeDays = lifeHours / 24;

  let lifeStr, lifeColor;
  if (lifeDays < 7) { lifeStr = `${lifeDays.toFixed(1)} days`; lifeColor = "#E74C3C"; }
  else if (lifeDays < 90) { lifeStr = `${(lifeDays / 7).toFixed(1)} weeks`; lifeColor = "#E67E22"; }
  else if (lifeDays < 365) { lifeStr = `${(lifeDays / 30).toFixed(1)} months`; lifeColor = "#3498DB"; }
  else { lifeStr = `${(lifeDays / 365).toFixed(1)} years`; lifeColor = "#16A085"; }

  return html`<div style="border:1px solid #E0E0E0;border-radius:8px;padding:16px;background:#FAFAFA;font-family:Arial,sans-serif;">
    <div style="display:flex;flex-wrap:wrap;gap:16px;margin-bottom:12px;">
      <div style="flex:1;min-width:160px;background:#2C3E5011;border-radius:6px;padding:12px;text-align:center;">
        <div style="color:#7F8C8D;font-size:0.85em;">Effective Wake Rate</div>
        <div style="color:#2C3E50;font-size:1.3em;font-weight:bold;">every ${(effectiveWakeMs/1000).toFixed(2)} s</div>
      </div>
      <div style="flex:1;min-width:160px;background:#16A08511;border-radius:6px;padding:12px;text-align:center;">
        <div style="color:#7F8C8D;font-size:0.85em;">Average Current</div>
        <div style="color:#16A085;font-size:1.3em;font-weight:bold;">${avgCurrentUA.toFixed(1)} uA</div>
      </div>
      <div style="flex:1;min-width:160px;border-radius:6px;padding:12px;text-align:center;background:${lifeColor}11;">
        <div style="color:#7F8C8D;font-size:0.85em;">Battery Life</div>
        <div style="color:${lifeColor};font-size:1.5em;font-weight:bold;">${lifeStr}</div>
      </div>
    </div>
    <p style="margin:4px 0 0;color:#7F8C8D;font-size:0.85em;">Events/sec: ${eventsPerSec.toFixed(2)} | Radio wakes: ${(eventsPerSec * 3600).toFixed(0)}/hour | Skips ${latParam} of ${latParam + 1} connection events</p>
  </div>`;
}

10.9 Inline Knowledge Check

10.9.1 Knowledge Check: Piconet Active Device Limit

10.9.2 Knowledge Check: Scatternet Bridge Devices

10.9.3 Knowledge Check: BLE Power Classes

Interactive Quiz: Match Bluetooth Network Concepts

Interactive Quiz: Sequence the Bluetooth Network Setup

🏷️ Label the Diagram

💻 Code Challenge

10.10 Summary

This chapter covered Bluetooth network architecture:

• Piconet Topology: One master controls up to 7 active slaves using TDM
• AMA Addressing: 3-bit address limits active slaves; 8-bit PMA for parked slaves
• Master-Slave Rules: All communication flows through master; slaves cannot communicate directly
• Power Classes: Class 1 (~100m), Class 2 (~10m), Class 3 (~1m)
• Scatternets: Bridge devices connect multiple piconets for larger networks
• Power States: Active, Sniff, Hold, and Park modes for power management
• Connection Parameters: Interval and latency tuning balances power vs responsiveness

Common Pitfalls

1. Exceeding the 7-Active-Slave Piconet Limit

Classic Bluetooth piconets support a maximum of 7 active slaves at any time (3-bit Active Member Address: 0=broadcast, 1–7=active slaves). Attempting to connect an 8th device requires parking one existing slave (assigning a Parked Member Address), adding significant complexity. For IoT networks requiring >7 nodes, use BLE star topology or BLE Mesh instead of attempting scatternet designs.

2. BLE Mesh Flooding Overhead on Dense Networks

Default BLE Mesh managed flooding retransmits each message 3–5 times to ensure delivery, consuming ~70% of channel capacity in a 20-node network. Without proper TTL tuning and publish period configuration, dense meshes experience collisions that paradoxically reduce reliability. Use directed forwarding (BLE Mesh 1.1 feature) or reduce retransmit counts for well-connected indoor deployments.

3. Ignoring BLE Multi-Central Connections in Gateway Design

A gateway collecting data from 50 BLE sensors cannot maintain 50 simultaneous BLE connections — connection event scheduling becomes the bottleneck above ~10 simultaneous connections per BLE controller. Design gateways to use sequential scan-connect-read-disconnect cycles for infrequent data, or use BLE beacons (connectionless advertising) for highest sensor density.

4. Mixing BLE and Classic Bluetooth in the Same Piconet

Classic Bluetooth (BR/EDR) and BLE are separate radio technologies; a dual-mode device runs them as logically independent stacks sharing the same RF hardware. They cannot communicate directly with each other in the same piconet. A BLE peripheral cannot join a Classic piconet, and Classic slaves cannot receive BLE advertisements. Design your network topology using one technology consistently.

10.11 What’s Next

Topic	Description	Link
BLE Protocol Stack & GATT	Explore the BLE protocol layers, Generic Attribute Profile, and how services and characteristics enable data exchange	BLE Protocol Stack
BLE Advertising & Scanning	Understand how BLE devices broadcast data and how scanners discover them without forming connections	BLE Advertising
Bluetooth Security	Analyze pairing modes, key exchange, and encryption mechanisms that protect Bluetooth communications	Bluetooth Security
BLE in IoT Applications	Apply Bluetooth architecture knowledge to real-world IoT sensor networks and wearable device designs	BLE IoT Applications
Zigbee and Thread	Compare Bluetooth mesh with Zigbee and Thread mesh protocols for large-scale building automation	Zigbee & Thread