What the standard is for
The Bluetooth SIG’s Mesh Protocol specification defines the requirements for an interoperable mesh network built on Bluetooth Low Energy. The SIG positions it for control, monitoring, and automation systems in which many devices talk to each other, with networked lighting control as the leading example. Its FAQ is just as clear about what it is not for: it is optimised for small messages between many devices, not for media streaming.
A light switch does not address a light directly. Devices publish messages to addresses, often group addresses such as “reception”, and other devices subscribe to the addresses they care about. Adding a new light means provisioning it and subscribing it to the right group; nothing else in the network has to change. The SIG also stresses that such systems need no central controller.
Joining the network: provisioning
A new device starts as an unprovisioned device. Provisioning turns it into a node, and it is usually run by an app on a phone or tablet acting as the Provisioner. The primer describes five steps:
- Beaconing. The device advertises an Unprovisioned Device beacon.
- Invitation. The Provisioner invites it, and the device replies with its capabilities.
- Public key exchange. The two exchange public keys, directly or out of band.
- Authentication. The user confirms the device, for example by entering a number it displays or by counting LED flashes.
- Distribution. Both sides derive a session key and use it to deliver the network key, the IV Index, and a unicast address. The device key is calculated independently on each side and never sent over the air.
Optional features add remote provisioning, for devices out of the Provisioner’s direct radio range, and certificate-based provisioning with X.509 certificates, so devices need not be in sight.
Keys: network, application, and device
Bluetooth Mesh separates who can relay a message from who can read it.
- Network key (NetKey). Holding it makes a node a member of the network or of a subnet. It lets a node decrypt and authenticate up to the network layer, enough to relay, but not to read application data.
- Application key (AppKey). Secures application data in the upper transport layer. The lighting application’s key is held by lights and switches, not by the thermostats, which hold the heating system’s key.
- Device key (DevKey). Unique to each node and known only to that node and the Provisioner, it secures configuration.
Keys can be replaced during the life of the network with the Key Refresh procedure, so a device removed from the network is left holding keys that no longer work. Against replay, each element increments a sequence number with every message it publishes, and receivers discard a message whose sequence number is not higher than the last valid one from that element.
How messages travel: managed flooding
Most nodes send and receive mesh messages over the advertising bearer, which uses ordinary BLE advertising and scanning. A published message is broadcast, and every node in radio range hears it. Nodes with the relay feature enabled then retransmit it. This is managed flooding, the default way messages cross the network, and flooding in a mesh network explains the general technique.
Two rules keep it under control:
- TTL. Each message carries a time to live that limits how many times it can be relayed. The primer’s example: a TTL of 3 means at most two relays, and a TTL of 0 means the message is not relayed at all.
- Message cache. Relays remember messages they have handled and discard a copy they have already seen instead of sending it again.
Managed flooding, defined in version 1.0, sends messages in every direction, whether or not a destination lies that way. Version 1.1, which the SIG announced in 2023, added directed forwarding as an option: a relay retransmits only if its forwarding table shows it lies on a path between the message’s source and destination, which can make more efficient use of the network and radio channels.
Node features: relay, proxy, friend, and low power
Every node can send and receive. Four optional features, each of which can be enabled or disabled, give some nodes extra roles:
| Feature | What it does |
|---|---|
| Relay | Retransmits received messages so they can make multiple hops |
| Proxy | Runs a GATT service so a device without the mesh advertising bearer can send and receive mesh messages through it |
| Friend | Stores messages for a low-power node and hands them over when asked |
| Low power | Sleeps most of the time and polls its Friend for waiting messages |
The proxy feature is the way in for devices such as smartphones. A Proxy node acts as a GATT server with the Mesh Proxy Service, and the phone, as a provisioned Proxy client, exchanges mesh messages with it over a GATT connection. The SIG’s FAQ recommends the advertising bearer for smartphone apps where the operating system allows it and the proxy protocol where it does not. Is a phone mesh over BLE the same as Bluetooth Mesh? looks at that difference.
Friendship suits devices such as a coin-cell temperature sensor, which cannot listen all the time but still needs to receive the occasional configuration change. A mains-powered neighbour holds those messages until the sensor wakes and asks for them.