10 BLE Mesh Networking
More
Depth: Practitioner
Progress saves as you read. Mark sections complete as you go; your progress appears in the sidebar.
10.1 Learning Objectives
This section: Learning Objectives
By the end of this chapter, you will be able to:
- Design and deploy BLE Mesh networks for building automation use cases
- Analyze Bluetooth Mesh node roles and assign them correctly to deployment scenarios
- Calculate TTL values for mesh networks based on network diameter and relay spacing
- Explain the Friend/Low Power Node relationship and when to use it for battery-powered devices
- Walk through mesh provisioning and identify what NetKey, AppKey, and DevKey each protect
- Diagnose mesh propagation failures using TTL, relay placement, and key-boundary evidence
10.2 Introduction
This section: Introduction — As Bluetooth deployments scale beyond simple point-to-point connections, mesh networking becomes a critical consideration.
As Bluetooth deployments scale beyond simple point-to-point connections, mesh networking becomes a critical consideration. This chapter covers BLE Mesh for large-scale deployments: how managed flooding replaces a fixed route, how to size relay density and TTL for a real building, how devices join the network through provisioning, and what evidence proves a mesh deployment actually works in the field.
This chapter moves from network shape to field proof:
- First you build the mesh mental model: publishers, relays, subscribers, Friends, Low Power Nodes, TTL, and duplicate suppression.
- Then you size a building deployment with the chapter’s own 40m x 30m office example, relay spacing, TTL, and propagation-delay numbers, and see the same decisions scaled up to a 500-light, 10-floor case study.
- Next you provision devices onto the mesh and see how NetKey, AppKey, and DevKey separate network membership from application access.
- Finally you try the hands-on nRF Connect lab and review the commissioning evidence that proves flooding is bounded and relay placement is resilient.
Checkpoint callouts recap what you can now do. Anything titled “Deep Dive” is optional on a first read, unless you are collecting design evidence.
If you only have 5 minutes, here’s what you need to know about Bluetooth Mesh:
- Mesh has 32,767 unicast element addresses - Unlike a Classic seven-active-device piconet, mesh uses managed flooding for building-scale deployments; practical node capacity depends on elements per node, traffic, and hardware
- Node Types Matter - Relay nodes forward messages (mains-powered), LPNs sleep to save power, Friend nodes buffer messages for LPNs
- TTL covers the relay path - TTL ≥ the measured maximum relay-hop count; add a tested margin because installed paths can change, while excess TTL increases relay traffic
- Provisioning and configuration establish three key roles - Provisioning creates a per-device DevKey and distributes a NetKey; subsequent configuration distributes and binds AppKeys. These differ from BLE connection keys such as the LTK
Bottom line: Bluetooth Mesh can support smart building control with selected mains-powered relays and sleeping Low Power Nodes that have suitable Friends.
BLE Mesh is like a bucket brigade for data - instead of one device trying to reach another across a building, messages get passed from neighbor to neighbor until they arrive. Each “helper” device (relay node) passes the message along, so you can cover an entire office building with one network.
Why it matters: A smart building might have 500+ sensors, lights, and switches. Mesh offers local relay paths for control messages; a gateway-based architecture is another option whose coverage and failure points need a separate design.
A single Classic seven-active-device piconet cannot serve hundreds of simultaneous active devices. Bluetooth Mesh is one building-scale control architecture and offers:
- 32,767 unicast element addresses in one network, with practical node count lower when nodes have multiple elements
- Alternate relay paths that can maintain delivery after a failure when coverage and TTL permit
- Multiple paths that can improve reliability, subject to interference and congestion
- Building-scale impact: A 50-floor office building can use a Bluetooth Mesh design for lighting control, occupancy sensing, and environmental monitoring; a single Classic seven-active-device piconet cannot provide that many-to-many network.
Remember the 7-device piconet limitation? Mesh solves this by allowing messages to “hop” through intermediate devices:
- Traditional: Hub connects to max 7 devices directly
- Mesh: Devices relay messages, extending range and capacity
- Scale: 32,767 unicast element addresses; provisioned node capacity also depends on traffic and resources
Think of it like passing a note through a classroom - each student passes it forward until it reaches the destination.
Imagine a huge building where lights need to talk to each other, but they’re too far apart to shout directly!
Temperature Terry was worried. “I’m on the 10th floor and I need to tell the light on the 1st floor to turn on. But I can only shout to lights that are nearby!”
the microcontroller had an idea. “What if we play a relay race with our messages? You tell ME your message, and I’ll pass it to my neighbor, and they’ll pass it to THEIR neighbor, until it reaches the 1st floor!”
the battery nodded. “That’s exactly what BLE Mesh does! Each device helps pass messages along, like a game of telephone - but without the message getting confused!”
the LED was excited. “So instead of one person shouting really loud, we have lots of helpers passing the message? That’s teamwork!”
“Exactly!” said Max. “And if one helper is busy or sleeping, the message can go through a DIFFERENT helper. The message always finds a way!”
Key Concepts for Kids:
| Word | What It Means |
|---|---|
| Mesh Network | Devices help pass messages to each other, like a relay race |
| Relay | A device that receives a message and passes it along |
| TTL (Time-To-Live) | How many helpers can pass the message before it stops |
| Flooding | Sending a message through MANY paths so it definitely arrives |
10.3 Prerequisites
This section: Prerequisites
Before diving into this chapter, you should be familiar with:
- Bluetooth Fundamentals: Understanding of Bluetooth vs BLE basics
- Bluetooth Protocol Stack: Knowledge of GATT and ATT protocols
- Bluetooth Topologies: Understanding piconet and scatternet limitations
10.4 BLE Mesh Networking
This section: BLE Mesh Networking — BLE Mesh (Bluetooth Mesh Profile 1.0, 2017) enables many-to-many device communication for building automation and large-scale IoT deployments.
BLE Mesh (Bluetooth Mesh Profile 1.0, 2017) enables many-to-many device communication for building automation and large-scale IoT deployments.
Prerequisites tell you what Bluetooth is; this section answers the deployment question: how can a command cross a building without every device holding a direct connection to every other device?
10.4.1 Mesh Architecture
BLE Mesh uses managed flooding rather than a single fixed route. Nodes relay messages only while the message still has TTL remaining, and subscribers act on messages addressed to their group.
| Mesh role | What it does in a building deployment | Design note |
|---|---|---|
| Publisher | Sends a model message, such as “lights on” or “temperature = 22 C” | Usually a switch, sensor, gateway, or automation rule |
| Relay nodes | Re-broadcast selected messages and decrement TTL | Use mains-powered fixtures or wall devices |
| Subscribers | Listen for messages sent to a group or virtual address | One message can control many lights or displays |
| Friend node | Buffers messages while a Low Power Node sleeps | Place near battery-powered sensors and switches |
| Low Power Node | Sleeps most of the time, then polls its Friend | Useful for battery devices that do not relay traffic |
10.4.2 BLE Mesh Protocol Stack
Understanding the layered architecture helps troubleshoot issues and design better solutions:
BLE Mesh sits above ordinary BLE advertising or GATT bearers. Troubleshooting is easier if you move from the application model downward to the bearer.
Layer Responsibilities:
| Layer | Function | Key Concepts |
|---|---|---|
| Application | Domain-specific behavior | Models define device capabilities |
| Foundation | Device management | Configuration, health monitoring |
| Access | Message formatting | Element addressing, key binding |
| Transport | Reliable delivery | Segmentation, app-level encryption |
| Network | Mesh routing | Relay, proxy, network encryption |
| Bearer | Physical transport | ADV (broadcast) or GATT (connection) |
10.4.3 Mesh Message Flow
The following sequence shows how messages flow through a BLE Mesh network using managed flooding:
| Step | Message state | What happens |
|---|---|---|
| 1. Publish | TTL = 3 | The publisher sends a message to a group address. |
| 2. First relay | TTL = 2 | Nearby relays that have not seen the message forward it once. |
| 3. Second relay | TTL = 1 | Farther relays forward again, extending coverage. |
| 4. Subscriber receives | TTL may be 1 or 0 | Subscribed nodes process the message if the group address matches. |
| 5. Cache suppresses duplicates | Same sequence number seen again | Relays drop duplicates so flooding does not become infinite. |
10.4.4 Node Types
| Node Type | Role | Power Source |
|---|---|---|
| Relay Node | Forwards messages through network | Mains-powered |
| Low Power Node (LPN) | Sleeps most of time, polls Friend | Battery |
| Friend Node | Buffers messages for LPN | Mains-powered |
| Proxy Node | Bridges GATT clients to mesh | Mains-powered |
| Provisioner | Adds devices to network | Mobile app |
10.4.5 Node Roles Decision Tree
Use this decision route to match responsibility to energy and connectivity. Start by asking whether the device is mains powered and continuously available; that can justify Relay or Friend work. If it sleeps on a battery, select Low Power behavior and pair it with a Friend. Use Proxy only when a non-mesh GATT client needs a bridge, and reserve Provisioner authority for authenticated commissioning. A node may support several roles, but each role needs explicit power, availability, and security evidence.
| Device constraint | Best mesh role | Why |
|---|---|---|
| Mains-powered and always present | Relay Node | It can spend energy forwarding messages for nearby nodes. |
| Battery-powered and mostly sleeping | Low Power Node | It saves energy by polling instead of listening continuously. |
| Mains-powered near several LPNs | Friend Node | It can store messages until sleeping devices wake and poll. |
| Smartphone or gateway must connect through GATT | Proxy Node | It bridges non-mesh GATT clients into the mesh. |
| Installer app or commissioning tool | Provisioner | It authenticates and adds new nodes to the network. |
This section:
Checkpoint: Mesh Roles and Message Flow
You now know:
- BLE Mesh scales beyond the classic 7-device piconet model by using managed flooding and group subscriptions.
- A relay rebroadcasts only while TTL remains, and the duplicate cache prevents the same sequence number from flooding forever.
- Battery nodes should be Low Power Nodes, not relays; a nearby Friend buffers their messages until the next poll.
10.4.6 TTL (Time-To-Live)
Messages include a TTL counter that prevents infinite loops:
- Publisher sets initial TTL (e.g., 5)
- Each relay decrements TTL before forwarding
- When TTL reaches 0, message is not relayed further
- TTL ≥ the measured maximum relay-hop count; add margin tested against installed paths and relay traffic
Problem: Messages not reaching all devices.
Cause: TTL too low for network diameter.
Solution: Set TTL to the measured hop count plus an explicit margin, then test delivery and relay traffic. The example below adds two hops.
import math
def calculate_ttl(network_diameter_meters, relay_spacing_meters):
hops_needed = math.ceil(network_diameter_meters / relay_spacing_meters)
safety_margin = 2
return min(hops_needed + safety_margin, 127)10.4.7 Mesh Capacity Planning
| Deployment | Devices | Relay Nodes | Notes |
|---|---|---|---|
| Small (home) | < 50 | 5-10 | Single room coverage |
| Medium (office) | 50-200 | 20-40 | Multiple zones |
| Large (building) | 200-1000 | 100-200 | Segment by floor |
| Enterprise | 1000+ | Per-floor | Use subnet isolation |
10.4.8 Worked Example: Office Lighting Mesh Design
An office floor (40m x 30m = 1,200 m^2^) needs BLE Mesh lighting control for 120 LED fixtures plus 20 wall switches and 10 occupancy sensors.
Step 1 — Device roles:
- 120 LED fixtures: Relay nodes (mains-powered, forward mesh traffic)
- 20 wall switches: 15 mains-powered (relay), 5 battery (LPN)
- 10 occupancy sensors: LPN (battery-powered, poll Friend every 2 s)
Step 2 — Network diameter:
- Longest path: corner-to-corner = sqrt(40^2^ + 30^2^) = 50 m
- Indoor relay spacing: ~8 m (conservative for office partitions)
- Maximum hops: 50 / 8 = 6.25, round up to 7
- Recommended TTL: 7 + 2 (safety) = TTL = 9
Step 3 — Message traffic estimate:
- “All lights on” group command: 1 publish, flooded through ~135 relays
- Each relay handles the message once before any configured retransmissions (the message cache suppresses duplicates)
- Baseline relay forwards: ~135 (one per relay node, before retransmissions)
- For an assumed full-size 47-byte LE 1M advertising packet: 47 × 8 / 1,000,000 = 0.376 ms on one channel
- Illustrative hop-delay budget: TTL × assumed 10 ms per hop = 9 × 10 ms = 90 ms; this excludes contention and retries and is not a measured settling time
Mesh propagation delay scales with TTL and hop processing time. For the office example with TTL=9:
With an assumed 10 ms per hop (receive + process), excluding contention and retries:
In this full-size-packet example, transmission on all three primary advertising channels costs ms per advertising event. For 135 baseline relay forwards, the sum is ms of radio airtime across transmitters. This is an illustrative aggregate, not a measured end-to-end delay: relays can transmit concurrently on different channels, while collisions, random advertising delay, and configured retransmissions can extend delivery. Measure the installed mesh against the lighting response target.
Step 4 — Friend node assignment:
- 15 LPNs (5 switches + 10 sensors) need Friend nodes
- Each Friend buffers up to 16 messages
- Assign 1 Friend per 3-4 LPNs (4 Friends minimum)
- Pick LED fixtures closest to each LPN cluster
Planning result: 120 fixtures give one potential relay per 10 m^2^, but enabling every relay may increase collisions. TTL=9 covers the seven-hop geometric estimate with two hops of margin; the 90 ms propagation figure is an assumed delay budget to test, not a coverage or latency guarantee.
This section:
Checkpoint: Sizing a Mesh
You now know:
- The office floor is 40m x 30m, so the longest path is 50 m and the conservative relay spacing is about 8 m.
- The calculation rounds 50 / 8 = 6.25 up to 7 hops, then adds a safety margin to reach TTL = 9.
- The traffic estimate uses an assumed 90 ms delay budget and 152.28 ms of aggregate airtime for 135 full-size three-channel advertising events, before retransmissions.
10.5 Real-World Application: Smart Office Lighting
This section: Real-World Application: Smart Office Lighting — The worked example above sizes a single 40m x 30m floor.
The worked example above sizes a single 40m x 30m floor. The case study below scales the same relay-density, TTL, and Friend/LPN decisions up to an entire ten-floor building, and turns them into a complete design record: node counts, TTL, LPN polling, group addressing, subnet isolation, and measured response.
Scenario: A 10-floor office building needs unified lighting control with occupancy sensing.
Solution Architecture:
| Component | Count | Node Type | Power |
|---|---|---|---|
| Light fixtures | 500 | Relay Node | Mains |
| Occupancy sensors | 100 | LPN | Battery (3-year design target) |
| Friend nodes | 20 | Friend + Relay | Mains |
| Control panels | 10 | Proxy Node | Mains |
| Provisioner | 1 | Mobile app | N/A |
Key Design Decisions:
- TTL = 15: A 60 m path at 8 m spacing rounds up to 8 hops; seven additional hops provide margin in this example (twice the hop estimate would be 16)
- LPN poll interval = 30s: Motion sensors don’t need instant config updates
- Group addresses per floor:
0xC001(Floor 1),0xC002(Floor 2), etc. - Subnet isolation: Separate NetKeys for lighting vs. HVAC
Design targets to verify: 94% lighting-energy reduction through occupancy-based control, 3-year sensor battery life, and <100 ms light response time. These figures require measured baseline energy, device current, and site latency; the topology calculation alone cannot establish them.
This section:
Checkpoint: Deployment Evidence
You now know:
- A 500-light office design can combine 500 relay fixtures, 100 battery LPN occupancy sensors, 20 Friend nodes, and 10 Proxy control panels.
- The case study sets TTL = 15 from a 60m building diameter and 8m relay spacing, then groups floors with addresses such as
0xC001. - A credible commissioning record proves bounded flooding, Friend/LPN delivery, key separation, and alternate delivery when one relay is powered off.
This section:
10.5.1 Friend and Low Power Node Relationship
Battery-powered devices (LPNs) need a Friend node to buffer messages while they sleep:
| Phase | Friend node behavior | Low Power Node behavior |
|---|---|---|
| Friendship setup | Allocates queue space for the LPN | Chooses a nearby Friend and negotiates poll timing |
| LPN sleeping | Receives and buffers messages addressed to the LPN | Turns radio off to save battery |
| Poll event | Sends queued messages during the receive window | Wakes, polls Friend, and listens briefly |
| Queue cleanup | Drops delivered or expired messages | Returns to sleep after receiving updates |
LPN Configuration Parameters:
| Parameter | Description | Typical Value |
|---|---|---|
| Poll Timeout | Max time between polls | 10s - 300s |
| Receive Delay | Delay before listening | 10 ms - 255 ms |
| Receive Window | Listen duration | 10 ms - 255 ms |
| Friend Queue Size | Messages Friend can buffer | Example allocation: 2-16 messages; verify the implementation |
10.5.2 Publish/Subscribe Model
BLE Mesh uses a publish/subscribe messaging pattern. Devices publish messages to group addresses, and all nodes subscribed to that group receive the message. This decouples senders from receivers, enabling flexible many-to-many communication.
| Group address | Example publishers | Example subscribers | Result |
|---|---|---|---|
0xC001 Floor 1 lights | Wall switch, schedule rule | All Floor 1 luminaires | One command controls a whole floor. |
0xC010 HVAC zone | Temperature sensor | Damper controller, thermostat display | Sensor data reaches every device that needs it. |
0xC100 Emergency lighting | Fire panel, gateway | Stairwell and exit lights | Critical commands fan out through multiple relay paths. |
10.5.3 Mesh Provisioning Workflow
Before a device can participate in the mesh, it must be provisioned (securely added to the network):
| Provisioning phase | What happens | Why it matters |
|---|---|---|
| Beacon discovery | Unprovisioned device advertises that it is ready to join | Provisioner can find the new device. |
| Invite and capabilities | Provisioner starts the link and reads supported authentication methods | Prevents using a method the device cannot support. |
| Public key exchange | Devices establish cryptographic material | Protects the provisioning session. |
| Authentication | User confirms passkey, numeric value, QR, NFC, or OOB data | Defends against adding the wrong physical device. |
| Provisioning data | Provisioner assigns an address and NetKey; both sides derive the DevKey | Device becomes a provisioned mesh node; AppKeys and models still need configuration. |
Provisioning Keys:
| Key | Purpose | Distribution |
|---|---|---|
| NetKey | Network-level encryption | All nodes in same network |
| AppKey | Application-level encryption | Nodes in same application group |
| DevKey | Device-specific configuration | Unique per device |
Mesh NetKey, AppKey, and DevKey serve different purposes from BLE pairing keys such as LTK and IRK. The NetKey protects network traffic, AppKeys protect application messages, and the DevKey protects device configuration. A GATT proxy connection may use BLE link encryption if the peers pair, but mesh packet security does not depend on that link pairing.
Try it yourself using the free nRF Mesh app:
- Download: nRF Mesh (iOS/Android) from Nordic Semiconductor
- Get hardware: 3x nRF52840 DK boards (DigiKey listed $48.95 each on 2026-10-08) or use nRF52 dongles.
- Flash mesh firmware: Nordic provides pre-built examples
Lab Steps:
- Flash
mesh_lightexample to two boards (these become light bulbs) - Flash
mesh_light_switchto one board (this becomes the switch) - Open nRF Mesh app and provision all three devices
- Create a group address and bind the switch and lights to it
- Press the switch button - both lights should respond!
Learning Objectives:
- Experience provisioning workflow
- Understand group addressing
- See managed flooding in action
- Measure latency and reliability
No hardware? Try the Nordic Mesh Simulator online.
10.6 Start With the Story
This section: Start With the Story — A mesh message sounds easy until a light switch, relay, group address, battery sensor, and gateway all share the same air.
A mesh message sounds easy until a light switch, relay, group address, battery sensor, and gateway all share the same air. BLE Mesh works because managed flooding, TTL, provisioning, keys, models, and publication rules make that shared space governable.
Read this chapter from one command outward. Ask how the message joins the network, who is allowed to relay it, how far it should travel, and what evidence shows the mesh can survive real placement.
10.7 Deep Dive: Mesh Relay Evidence and Key Boundaries
This section: Deep Dive: Mesh Relay Evidence and Key Boundaries — BLE Mesh commissioning evidence should prove that managed flooding is bounded, not just that one test command worked.
BLE Mesh commissioning evidence should prove that managed flooding is bounded, not just that one test command worked. For a three-room lighting group, record the source sequence number, TTL at each relay, duplicate-cache drops, and the received count at the far fixture. Then repeat the test with one relay powered off; if the command still reaches the far fixture through another relay, the design has path diversity rather than a hidden single point of failure.
Friend/LPN evidence is different. A battery sensor can sleep only if a nearby Friend buffers messages while the sensor radio is off. Record the Friend assigned to each LPN, the poll interval, queue size, and a delayed-command test. For example, if a door sensor polls every 30 seconds, a configuration update sent while it sleeps should arrive on the next poll instead of disappearing into the flood.
Mesh key evidence should separate forwarding from reading. A hallway relay needs the NetKey so it can authenticate and forward network traffic, decrement TTL, and reject malformed packets. It should not need the lighting AppKey unless it actually controls a lighting model. A useful commissioning record lists which AppKeys each model is bound to and includes a test where a relay forwards an application message it cannot decrypt at the application layer.
| Review question | Evidence to keep |
|---|---|
| Is flooding bounded? | TTL values, duplicate-cache drops, and far-node receive counts. |
| Is relay placement resilient? | Retry with one relay powered off and confirm alternate delivery. |
| Can sleeping nodes receive commands? | Friend mapping, LPN poll interval, queue size, and delayed-command test. |
| Are application domains isolated? | NetKey/AppKey binding list and relay-forward-without-payload-decode proof. |
10.8 Common Pitfalls
This section: Common Pitfalls
Mistake: Using 20-100 ms advertising intervals expecting better discovery.
Result: Battery drains in weeks instead of years.
Fix: Use these intervals:
- Pairing mode: 100-200 ms for 30-60 seconds
- Normal beacons: 500-1000 ms
- Power-critical: 1000-10000 ms
Mistake: Assuming BLE and Classic are interchangeable.
Reality:
- Different radio protocols
- Incompatible stacks
- Different profiles
Rule: Use BLE for sensors, Classic for audio streaming.
10.9 Inline Knowledge Check
This section: Inline Knowledge Check
10.10 Practice Activities
This section: Practice Activities
Managed flooding for stage lights
Narrated audio tour. The full transcript is below. These are schematic teaching states, not measured protocol or elapsed lifecycle time. Choose Reduced motion for a complete still at each beat. Explanations beyond the model remain in captions.
Full transcript — ble-mesh (8 beats)
B1 — Lighting commissioning
You are the technician setting up a building's lighting control. One wall switch must reach both stage lights, so a missed command leaves part of the group unchanged. Your job is to choose how messages travel while keeping repeated traffic under control.
Model caption: Your switch must reach both stage lights while repeated traffic stays controlled.
B2 — Group publishing
Bluetooth Low Energy is the radio family used by Bluetooth Mesh. Mesh uses managed flooding: selected devices pass a message onward. A switch publishes a command to a group address, and lights subscribed to that group can act when the command reaches them.
Model caption: Bluetooth Mesh builds on Bluetooth Low Energy. Selected relays carry a group command toward subscribed lights.
B3 — Relay choice and cache
A relay is a device enabled to pass messages onward. The chapter recommends mains powered fixtures or wall devices for that work. Choosing relays matters because enabling every fixture may increase collisions. Managed flooding also uses a message cache, which remembers messages already received and discards duplicates.
Model caption: Choose relays deliberately; the chapter recommends mains powered devices and warns that enabling every fixture may increase collisions. A cache discards repeated messages.
B4 — First hop
Time to live is the message's limit on forwarding. Take the teaching model's stage lighting example, starting at three, with balanced relays and one transmission per relay. The switch sends without subtracting, so Relay A and Relay B each receive the value three. Neither stage light has received the command yet.
Model caption: Initial time to live: three. Relay A and Relay B receive three from the switch. Stage lights reached: zero of two.
B5 — First relay wave
During the first relay wave, each forwarding relay subtracts one: three minus one gives two. Stage light one receives the command at two. Relay C also receives it at two from Relay A. When Relay B sends another copy to Relay C, the cache discards that duplicate.
Model caption: Three minus one gives two. Stage light one receives at two. Relay C accepts A's first copy and discards B's duplicate. One of two lights reached.
B6 — Second relay wave
During the second relay wave, Relay C subtracts one again: two minus one gives one. Stage light two receives the command at one. Both intended lights have now received it. In the teaching model, a relay needs a received value greater than one to forward, so forwarding stops at one.
Model caption: Two minus one gives one. Stage light two receives at one; both lights have received the command. The model forwards only received values greater than one.
B7 — Duplicates still cost airtime
The misconception is that discarding duplicates removes their radio cost. A copy has already used radio time before a receiver discards it. Stage light one hears another copy during the second wave, but its cache discards it. Two lights reached therefore does not mean only two transmissions occurred.
Model caption: Both lights received the command. Stage light one then discards another copy, which already consumed radio time. Delivery count is not transmission count.
B8 — Limit the spread
For your lighting job, remember: managed flooding carries the command outward, while relay choice, time to live, and caching limit the spread.
Model caption: Managed flooding carries the command outward, while relay choice, time to live, and caching limit the spread.
10.11 Summary
This section: Summary
This chapter covered BLE Mesh for large-scale deployments:
- BLE Mesh: Managed flooding, publish/subscribe, 32K+ node capacity
- Node Types: Relay, Low Power, Friend, Proxy, Provisioner
- TTL Management: Prevents infinite loops, must match network diameter
- Friend/LPN: Battery nodes sleep and poll a Friend that buffers their messages
- Provisioning: Beacon discovery, authentication, address and NetKey distribution, DevKey derivation; AppKeys follow in configuration
- Deployment Evidence: Bounded flooding, relay-failure path diversity, and key-boundary proof
10.11.1 Key Takeaways
BLE Mesh Sizing:
- Home: fewer than 50 devices; use roughly 10-20% relays.
- Office: 50-200 devices; use roughly 15-25% relays.
- Building: 200-1000 devices; use roughly 10-20% relays, with relay placement checked per floor.
Planning estimate: TTL = ceil(distance / relay_spacing) + tested hop margin; measure actual relay paths before deployment.
10.13 What’s Next
This section: What’s Next
| Topic | Why Read It Next | Link |
|---|---|---|
| BLE Pairing Methods | Choose and configure Just Works, Passkey Entry, Numeric Comparison, or Out-of-Band pairing for a mesh network’s proxy and provisioning connections | BLE Pairing Methods |
| Bluetooth Security: Encryption and Key Management | Review the BLE connection-level key hierarchy (LTK, IRK, CSRK) that protects a Proxy Node’s GATT link into the mesh | Encryption and Key Management |
| BLE Field Debugging and Internals | Diagnose connection, notification, and MTU failures on the GATT side of a mesh deployment, with ESP32 war stories and internals | BLE Field Debugging |
| BLE Implementation and Labs | Apply mesh provisioning and GATT service design hands-on using the nRF5 SDK and ESP-IDF | BLE Implementation |
| Zigbee and Thread Architecture | Evaluate BLE Mesh against competing mesh protocols — Zigbee, Thread, and Matter — for building automation deployments | Zigbee Fundamentals |
| Bluetooth Assessment | Test and consolidate your understanding across all Bluetooth and BLE Mesh topics with comprehensive knowledge checks | Bluetooth Assessment |
Find help
3 reviewed answers.
Where should I start in a module?
Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.
Modules and pathsReviewed
What can I try when a project does not work?
Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.
When you are stuckReviewed
How do interactive examples work?
Use the interactive guide to check how examples and simulations work before changing your project.
Interactive examples guideReviewed