Bluetooth supports three topologies: star (point-to-point or broadcast for beacons), connected (bidirectional data exchange with security), and mesh (building-scale multi-hop using managed flooding). The choice depends on power budget, range requirements, and network device count.
Bluetooth supports three main topologies: star (point-to-point or broadcast for beacons), connected (bidirectional data exchange with security), and mesh (building-scale multi-hop networks using managed flooding). The choice between them is driven by power budget, range requirements, and the number of devices in the network. Advertising interval is the single largest factor affecting beacon battery life.
By the end of this chapter, you will be able to:
Bluetooth devices can connect in different patterns. A point-to-point connection links two devices directly (like your phone to your earbuds). A star network connects multiple devices to one central hub. Bluetooth Mesh creates a web of interconnected devices that can relay messages across large areas, like smart lighting in an entire building.
“Bluetooth networks come in different shapes, just like how you can arrange desks in a classroom!” Sammy the Sensor said. “A star topology is like desks arranged in a circle around the teacher – everything goes through one central device. That is how most BLE connections work, with your phone in the middle.”
“Broadcast topology is my favorite,” Lila the LED announced. “It is like a lighthouse sending light in all directions. A BLE beacon just broadcasts its signal to anyone listening – no pairing needed, no handshakes, no waiting. That is how stores know when you walk past a display!”
Max the Microcontroller rubbed his chin thoughtfully. “But the real game-changer is Bluetooth Mesh. Imagine a chain of people passing a message across a football field. Each device receives the message and relays it to the next one. That way, even if I cannot reach the gateway directly, my message can hop through other devices until it gets there. It works for entire buildings!”
“Each topology has different power needs,” Bella the Battery explained. “A simple point-to-point connection is the most efficient – just two devices talking. Broadcasting uses a bit more because the beacon never stops. And mesh uses the most energy because every device might need to relay messages for others. Choosing the right shape is key to making me last as long as possible!”
Before diving into this chapter, you should be familiar with:
The simplest BLE topology is the star broadcast pattern, where a beacon advertises to multiple receivers without establishing connections.
Characteristics:
BLE devices can work in two modes:
1. Advertising Mode (Broadcasting):
Examples:
2. Connected Mode (Two-way communication):
Advertising power consumption scales linearly with interval frequency. Given a CR2032 coin cell battery (220 mAh capacity) and typical nRF52 BLE chip specifications:
\[ \begin{aligned} \text{TX events per second} &= \frac{1000 \text{ ms}}{\text{interval (ms)}} \times 3 \text{ channels} \\[0.4em] \text{Active time per event} &= 0.5 \text{ ms (TX)} + 0.1 \text{ ms (setup)} = 0.6 \text{ ms} \\[0.4em] I_{\text{avg}} &= I_{\text{TX}} \times \text{duty cycle} + I_{\text{sleep}} \times (1 - \text{duty cycle}) \\[0.4em] \text{Battery life (hours)} &= \frac{\text{Capacity (mAh)}}{I_{\text{avg}} \text{ (mA)}} \end{aligned} \]
For 20 ms interval (minimum): \[ \begin{aligned} \text{Events/sec} &= \frac{1000}{20} \times 3 = 150 \text{ events/sec} \\[0.4em] \text{Duty cycle} &= \frac{150 \times 0.6}{1000} = 0.09 = 9\% \\[0.4em] I_{\text{avg}} &= 15\text{ mA} \times 0.09 + 0.002\text{ mA} \times 0.91 = 1.35 + 0.002 \approx 1.35\text{ mA} \\[0.4em] \text{Life} &= \frac{220}{1.35} \approx 163 \text{ hours} \approx 7 \text{ days} \end{aligned} \]
For 1000 ms interval (power-optimized): \[ \begin{aligned} \text{Events/sec} &= \frac{1000}{1000} \times 3 = 3 \text{ events/sec} \\[0.4em] \text{Duty cycle} &= \frac{3 \times 0.6}{1000} = 0.0018 = 0.18\% \\[0.4em] I_{\text{avg}} &= 15\text{ mA} \times 0.0018 + 0.002\text{ mA} \times 0.9982 = 0.027 + 0.002 \approx 0.029\text{ mA} \\[0.4em] \text{Life} &= \frac{220}{0.029} \approx 7,586 \text{ hours} \approx 316 \text{ days} \end{aligned} \]
Key insight: Increasing the advertising interval from 20 ms to 1000 ms (50x longer) extends battery life from 7 days to 316 days (45x improvement). The relationship is nearly linear because duty cycle dominates over sleep current at high advertising rates.
Note on TX current: This example uses 15 mA TX current, which corresponds to nRF52 operating at +4 dBm output power. At the more common 0 dBm setting, TX current is approximately 5–7 mA, yielding a longer 20 ms-interval life of roughly 11 days. The relative improvement from interval tuning remains the same regardless of TX power setting.
Adjust the advertising interval and observe how it affects battery life for a CR2032-powered BLE beacon.
viewof advInterval = Inputs.range([20, 10000], {
value: 1000,
step: 10,
label: "Advertising Interval (ms)"
})
viewof txCurrent = Inputs.range([5, 25], {
value: 15,
step: 0.5,
label: "TX Current (mA)"
})
viewof batteryCapacity = Inputs.range([100, 1000], {
value: 220,
step: 10,
label: "Battery Capacity (mAh)"
}){
const channels = 3;
const eventDuration = 0.6; // ms per event (TX + setup)
const sleepCurrent = 0.002; // mA
const eventsPerSec = (1000 / advInterval) * channels;
const dutyCycle = (eventsPerSec * eventDuration) / 1000;
const avgCurrent = txCurrent * dutyCycle + sleepCurrent * (1 - dutyCycle);
const batteryHours = batteryCapacity / avgCurrent;
const batteryDays = batteryHours / 24;
const color1 = "#2C3E50";
const color2 = batteryDays > 180 ? "#16A085" : batteryDays > 30 ? "#E67E22" : "#E74C3C";
return html`<div style="background: #f8f9fa; border-radius: 8px; padding: 1.2rem; font-family: Arial, sans-serif;">
<div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(180px, 1fr)); gap: 1rem; margin-bottom: 1rem;">
<div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${color1};">
<div style="font-size: 0.85rem; color: #666;">TX Events/sec</div>
<div style="font-size: 1.5rem; font-weight: bold; color: ${color1};">${eventsPerSec.toFixed(1)}</div>
</div>
<div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${color1};">
<div style="font-size: 0.85rem; color: #666;">Duty Cycle</div>
<div style="font-size: 1.5rem; font-weight: bold; color: ${color1};">${(dutyCycle * 100).toFixed(2)}%</div>
</div>
<div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${color1};">
<div style="font-size: 0.85rem; color: #666;">Avg Current</div>
<div style="font-size: 1.5rem; font-weight: bold; color: ${color1};">${avgCurrent < 1 ? (avgCurrent * 1000).toFixed(0) + " uA" : avgCurrent.toFixed(2) + " mA"}</div>
</div>
<div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${color2};">
<div style="font-size: 0.85rem; color: #666;">Battery Life</div>
<div style="font-size: 1.5rem; font-weight: bold; color: ${color2};">${batteryDays < 1 ? (batteryHours).toFixed(0) + " hours" : batteryDays < 365 ? batteryDays.toFixed(0) + " days" : (batteryDays / 365).toFixed(1) + " years"}</div>
</div>
</div>
<div style="font-size: 0.8rem; color: #666;">Assumes CR2032 coin cell, nRF52 BLE chip, 3 advertising channels, ${eventDuration} ms per TX event, ${sleepCurrent} mA sleep current.</div>
</div>`;
}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.
Bluetooth Mesh extends BLE beyond point-to-point connections to building-scale deployments.
Characteristics:
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 |
Bluetooth Mesh uses managed flooding for message delivery, which eliminates the need for routing tables on resource-constrained devices.
Key node types:
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:
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:
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:
Redesign with optimized Friend polling:
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.
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:
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 |
| 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 |
BLE discovery involves the interplay between advertising and scanning timing.
Scanner Parameters:
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 alignsBluetooth 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 |
Use this decision framework to choose the right Bluetooth technology:
Choose BLE Advertising (Beacons) when:
Choose BLE Connected Mode when:
Choose Bluetooth Mesh when:
Choose Classic Bluetooth when:
Silvair (acquired by Signify/Philips in 2021) deployed one of the largest Bluetooth Mesh lighting installations at a 50,000 m2 office campus in Krakow, Poland. The deployment illustrates both the strengths and engineering constraints of Bluetooth Mesh at scale.
Deployment Numbers:
| Parameter | Value |
|---|---|
| Total luminaires | 1,800 Bluetooth Mesh nodes |
| Building area | 50,000 m2 across 4 floors |
| Relay density | ~36 relays per 1,000 m2 |
| Proxy nodes per floor | 6 (at elevator lobbies and stairwells) |
| Average hops per command | 3.2 |
| Command latency (p95) | 180 ms |
| Energy savings vs static lighting | 38% reduction in lighting electricity |
Why Bluetooth Mesh over Zigbee or Wired DALI?
The decision framework came down to three factors:
Smartphone compatibility: Bluetooth Mesh proxy nodes allow any smartphone to control lighting – no dedicated gateway hardware. Zigbee requires a coordinator/gateway box on every floor. For a 4-floor building, this eliminated $2,400 in gateway hardware and ongoing maintenance.
Retrofit cost: DALI wiring for 1,800 fixtures would require $180,000–$250,000 in cable runs through existing ceilings. Bluetooth Mesh uses the existing mains power wiring only. Total installation was completed in 3 weeks versus an estimated 12 weeks for DALI.
Managed flooding simplicity: Each luminaire acts as a relay without needing routing tables. Zigbee’s mesh routing requires each node to maintain neighbor tables (200–500 bytes per neighbor), which is feasible for 50-node networks but creates memory pressure at 1,800 nodes.
Engineering Tradeoff – Flooding Bandwidth:
Bluetooth Mesh’s managed flooding means every message is relayed by every node within TTL range. At 1,800 nodes with TTL=5, a single group command generates roughly 1,800 relay events. Silvair solved bandwidth saturation through:
This kept the network utilization below 40% of theoretical airtime capacity, leaving headroom for bursty group commands during morning arrival and evening departure.
This chapter covered Bluetooth network topologies:
Deploying one smartphone per sensor in a point-to-point topology for a 20-sensor building monitoring system requires 20 smartphones or 20 sequential connection cycles from a single gateway. Use BLE star topology (single central, multiple peripherals) or BLE Mesh for multi-sensor deployments. A single ESP32 can maintain 10–20 simultaneous BLE connections, serving as a hub for many sensors.
BLE Mesh adds significant complexity: provisioning, key management, model configuration, and relay node placement. For deployments under 20 devices within a 50 m radius of a gateway, BLE star topology achieves better latency, simpler firmware, and easier debugging. Use BLE Mesh only when you need: range beyond direct gateway reach, no infrastructure (gateway-less operation), or >20 devices.
BLE advertising data is transmitted in cleartext and can be received by any BLE scanner within range. Broadcasting patient vital signs, access control codes, or proprietary sensor data in advertising PDUs exposes it to passive eavesdropping. Use encrypted connection-based GATT for sensitive data; use advertising only for non-sensitive discovery metadata (device name, service UUID, TX power).
BLE Mesh networks with insufficient relay nodes have coverage holes where messages cannot reach their destination. Each relay node increases network delay by one hop latency (~10–50 ms). For reliable coverage, ensure every node is within range of at least 2 relay nodes (for redundancy), and use the mesh provisioner’s network analyzer to map relay coverage before deployment.
| Chapter | What You Will Learn | Why It Matters |
|---|---|---|
| Bluetooth Piconet Architecture | Classic Bluetooth piconet structure, central/peripheral roles, scatternets, and the 7-device active limit | Understand the Classic BT foundation that BLE departs from, and when scatternets are used |
| BLE GATT Protocol | Services, characteristics, descriptors, and the attribute protocol that enables BLE data exchange | GATT is the application-layer framework on top of every BLE connected-mode topology |
| BLE Security | Pairing, bonding, encryption, and LE Secure Connections | Security is topology-dependent — mesh uses its own provisioning and application-layer encryption |
| Bluetooth Mesh Deep Dive | Provisioning, publish/subscribe model, scenes, and node configuration | Operational detail needed to deploy the mesh topology covered conceptually in this chapter |
| BLE Power Optimization | Connection intervals, latency settings, and duty-cycle tuning for battery-powered devices | Topology choice is only the first step — parameter tuning determines real-world battery life |
| Zigbee and Thread | Alternative mesh protocols for IoT — 802.15.4 PHY, coordinator/router/end-device roles | Compare Bluetooth Mesh trade-offs against Zigbee and Thread for smart-building deployments |