911 Bluetooth Network Topologies
911.1 Learning Objectives
By the end of this chapter, you will be able to:
- Differentiate between star, broadcast, and mesh topologies in Bluetooth
- Understand BLE advertising modes for beacon and broadcast applications
- Design Bluetooth Mesh networks for building-scale deployments
- Analyze power consumption trade-offs for different topology choices
- Implement the BLE state machine for optimal power management
911.2 Prerequisites
Before diving into this chapter, you should be familiar with:
- Bluetooth Overview: Basic understanding of Bluetooth technology
- Classic Bluetooth vs BLE: Understanding the differences between Classic and BLE
- Topologies Fundamentals: General knowledge of network topologies
911.3 Star (Broadcast) Topology
The simplest BLE topology is the star broadcast pattern, where a beacon advertises to multiple receivers without establishing connections.
Characteristics:
- One-to-many, connectionless broadcast (advertising)
- No pairing required for receivers to hear advertisements
- Receivers can be many scanners (phones, gateways, etc.)
- Use cases: Retail beacons, indoor navigation, asset tracking
911.3.1 BLE Advertising Modes
BLE devices can work in two modes:
1. Advertising Mode (Broadcasting):
- A beacon periodically sends tiny radio packets such as “ID: 123”.
- Nearby phones scan the advertising channels; when they hear the ID they know which beacon they are close to.
- No connection is required – the phone can react (e.g., show a notification) based only on the broadcast.
Examples:
- Store beacons announcing promotions as you walk by
- COVID contact tracing (phones broadcasting anonymous IDs)
- Lost item trackers (AirTag, Tile)
2. Connected Mode (Two-way communication):
- A central device (usually a phone) establishes a BLE connection to one peripheral (e.g., fitness band).
- The peripheral sends sensor data such as heart rate and steps; the phone can also write settings such as alarms or display units.
- This is full bidirectional data exchange with security, reliability and flow control on top of the radio link.
911.3.2 Advertising Power Optimization
The Mistake: Setting the BLE advertising interval to 20ms (the minimum allowed) for a battery-powered beacon because “faster discovery means better user experience,” then finding batteries drain in weeks instead of months.
Why It Happens: Developers optimize for discovery latency without calculating the power cost. At 20ms intervals, the radio transmits 50 times per second on 3 channels (150 TX events/second). This continuous activity prevents the MCU from entering deep sleep and dominates power consumption.
The Fix: Match advertising interval to your actual discovery latency requirements. For most beacon applications, 100-1000ms intervals provide acceptable discovery time with dramatically better battery life:
Power comparison (nRF52 @ 0dBm TX, 3 channels):
20ms interval (minimum):
- TX events/second: 150
- Average current: ~850 uA
- CR2032 life: 220mAh / 0.85mA = 259 hours = 11 days
100ms interval (balanced):
- TX events/second: 30
- Average current: ~180 uA
- CR2032 life: 220mAh / 0.18mA = 1,222 hours = 51 days
1000ms interval (power-optimized):
- TX events/second: 3
- Average current: ~25 uA
- CR2032 life: 220mAh / 0.025mA = 8,800 hours = 366 days
Discovery latency (typical scanner at 100ms window):
- 20ms interval: ~60ms average discovery
- 100ms interval: ~150ms average discovery
- 1000ms interval: ~1.5s average discoveryUse 100-300ms for consumer devices needing responsive discovery. Use 1-10s for asset tracking where battery life trumps discovery speed.
911.4 Mesh Topology
Bluetooth Mesh extends BLE beyond point-to-point connections to building-scale deployments.
Characteristics:
- Many-to-many communication
- Self-healing networks
- Multi-hop range extension
- Addressing up to ~32k unicast nodes (practical scale depends on airtime and relay overhead)
- Use cases: Building automation, lighting, smart metering
Mesh Advantages:
| Advantage | Benefit |
|---|---|
| Extended Range | Multi-hop routing beyond single connection range |
| Self-Healing | Automatic re-routing around failures |
| Reliability | Multiple paths ensure message delivery |
| Scalability | No single bottleneck point |
| Energy Efficiency | Lower transmit power with powered routers |
911.4.1 Bluetooth Mesh Architecture
Bluetooth Mesh uses managed flooding for message delivery, which eliminates the need for routing tables on resource-constrained devices.
Key node types:
- Relay nodes: Forward messages through the mesh (typically mains-powered)
- Proxy nodes: Bridge between mesh and non-mesh BLE devices (smartphones)
- Friend nodes: Store messages for low-power nodes while they sleep
- Low Power Nodes (LPN): Battery-powered sensors that sleep most of the time
Scenario: A commercial building needs to deploy 200 smart lights across 3 floors using Bluetooth Mesh. The building has concrete floors (high RF attenuation) and requires smartphone control from any location.
Given:
- 200 BLE mesh-capable light fixtures (relay nodes)
- 3 floors, approximately 2000 m^2 per floor
- Concrete floor attenuation: ~15-20 dB
- Smartphone app for user control (requires proxy node)
- Maximum acceptable command latency: 500ms
Steps:
Calculate relay density: Each relay node covers ~10m radius indoors. For 2000 m^2 per floor, need approximately 60-70 lights per floor acting as relays. With 200 lights, coverage is adequate.
Design for floor isolation: Concrete attenuates signals significantly. Install 2-3 proxy nodes per floor at stairwells/elevators where some cross-floor signal may exist. These proxy nodes bridge BLE mesh to smartphone GATT connections.
Configure TTL (Time To Live): With average 3-4 hops to reach any light on a floor, set TTL=7 to allow cross-floor commands while preventing excessive flooding. Each hop adds ~10-20ms latency.
Plan provisioning: Use a provisioner app to add all 200 devices to the network. Assign group addresses: Floor1_All (0xC001), Floor2_All (0xC002), Floor3_All (0xC003), Building_All (0xC000).
Calculate worst-case latency: Maximum 6 hops x 50ms per hop = 300ms, well within 500ms requirement.
Result: Building-wide lighting control with smartphone access from any location. Commands propagate via managed flooding through relay nodes, with proxy nodes enabling smartphone connectivity. Group addressing allows “all off” commands for entire floors or building.
Key Insight: Bluetooth Mesh’s managed flooding eliminates the need for routing tables on resource-constrained light bulbs. Every mains-powered light becomes a relay, creating dense coverage. The TTL parameter balances network-wide reach against flooding overhead.
Scenario: A warehouse deploys battery-powered temperature/humidity sensors that must report every 5 minutes while achieving 2+ year battery life on a CR2032 coin cell.
Given:
- 50 battery-powered sensors (Low Power Nodes - LPN)
- 20 mains-powered access points (Friend Nodes)
- CR2032 battery capacity: 220 mAh
- Sensor sleep current: 2 uA
- Sensor TX current: 15 mA for 5ms per transmission
- Poll interval requirement: sensors wake every 10 seconds to check for commands
Analysis:
Configure Friend relationship: Each LPN establishes friendship with a nearby Friend Node. The Friend stores messages destined for the LPN while it sleeps.
Calculate LPN power budget:
- Sleep current: 2 uA x 24 hours = 48 uAh/day
- Sensor reading + TX (every 5 min = 288/day): 288 x 15mA x 5ms = 21.6 mAh/day… Too high!
Redesign with optimized Friend polling:
- Data transmissions: 96/day (every 15 minutes)
- TX: 96 x 3ms x 15mA = 4.32 mAh/day
- Poll: 96 x 2ms x 15mA = 2.88 mAh/day
- Total: 7.25 mAh/day -> 220mAh / 7.25 = 30 days… Still short of 2 years
Result: Analysis reveals CR2032 cannot achieve 2-year life with BLE Mesh polling overhead. Design decision: Use BLE advertising-only mode (no mesh) for sensors, with mesh-connected gateways that aggregate data.
Key Insight: BLE Mesh’s Low Power Node feature reduces power versus always-on relays, but the Friend polling overhead still consumes significant energy. For multi-year battery life with very infrequent data, advertising-only beacons to mesh-connected gateways may be more power-efficient than full mesh participation.
911.5 BLE Connection State Machine
Understanding the BLE Link Layer state machine is critical for power optimization. Devices spend most time in Standby (~1 uA) with brief bursts in active states.
States:
- Standby: Initial state - radio is off, minimal power consumption
- Advertising: Broadcasting presence on advertising channels (37, 38, 39)
- Scanning: Listening for advertising packets from peripherals
- Initiating: Central sending connection request to advertiser
- Connected: Bidirectional data exchange established
State Transitions:
| From | To | Trigger |
|---|---|---|
| Standby | Advertising | Start Advertising (peripheral) |
| Standby | Scanning | Start Scanning (central) |
| Advertising | Connected | Connection Request received |
| Scanning | Initiating | Matching advertiser discovered |
| Initiating | Connected | Connection established |
| Connected | Standby | Disconnect |
911.5.1 Power Profile Comparison
| Mode | Average Current | Battery Life (CR2032) |
|---|---|---|
| Classic (audio streaming) | ~30 mA | ~7 hours |
| BLE Sensor (1s updates) | ~15 uA | ~1.5 years |
| BLE Beacon (200ms interval) | ~50 uA | ~5 months |
| BLE Beacon (1s interval) | ~10 uA | ~2.5 years |
911.6 Scanning and Discovery
BLE discovery involves the interplay between advertising and scanning timing.
Scanner Parameters:
- Scan Interval: How often the scanner listens (e.g., every 200ms)
- Scan Window: How long the scanner listens each interval (e.g., 50ms)
- Duty Cycle: Scan Window / Scan Interval (e.g., 50/200 = 25%)
Discovery Time Calculation:
Discovery time depends on when the scan window overlaps with an advertisement on any of the 3 advertising channels.
Example:
- Advertising interval: 100ms
- Scan interval: 200ms
- Scan window: 50ms (25% duty cycle)
Average discovery time: 100-300ms
- Best case: Advertisement occurs during active scan window
- Worst case: Several cycles before timing aligns911.7 Power Classes
Bluetooth defines power classes for different range requirements:
| Class | Power | Range | Application |
|---|---|---|---|
| 1 | 100 mW (20 dBm) | ~100m | Industrial, long-range |
| 2 | 2.5 mW (4 dBm) | ~10m | Mobile devices |
| 3 | 1 mW (0 dBm) | ~1m | Ultra-low power |
911.8 Technology Selection Guide
Use this decision framework to choose the right Bluetooth technology:
Choose BLE Advertising (Beacons) when:
- One-to-many broadcast is needed
- No bidirectional communication required
- Receivers don’t need to pair
- Simplest implementation, lowest power
Choose BLE Connected Mode when:
- Bidirectional communication needed
- Security/encryption required
- Larger data payloads (MTU up to 512 bytes)
- Reliable delivery with acknowledgments
Choose Bluetooth Mesh when:
- Building-scale coverage needed
- Self-healing networks required
- Many-to-many communication patterns
- Mains-powered relay infrastructure available
Choose Classic Bluetooth when:
- Audio streaming (A2DP)
- High-bandwidth file transfer
- Legacy device compatibility
- Continuous data streams
911.9 Summary
This chapter covered Bluetooth network topologies:
- Star/Broadcast topology enables one-to-many advertising for beacons and asset tracking
- Mesh topology extends BLE to building-scale with managed flooding and self-healing
- The BLE state machine governs device behavior and power consumption
- Advertising intervals dramatically affect battery life (20ms vs 1000ms = 30x difference)
- Power classes (1, 2, 3) provide flexibility for different range requirements
- Low Power Nodes in mesh can extend battery life but add polling overhead
911.10 What’s Next
The next chapter, Bluetooth Piconet Architecture, dives deep into the Classic Bluetooth piconet structure with central/peripheral roles, scatternets, and the 7-device active limit.