Mesh 1.1: Directed Forwarding and Subnet Bridging
New features in Bluetooth Mesh 1.1 specification
Mesh 1.1 Features
Bluetooth Mesh 1.1 (ratified 2023) addresses the three biggest limitations of the 1.0 specification: inefficient flooding, inability to reach isolated subnets from a single provisioner, and slow remote device management. The three headline features — Directed Forwarding, Subnet Bridging, and Remote Provisioning — transform Bluetooth Mesh from a flat flooding network into a managed, scalable infrastructure.
Directed Forwarding
Classic Bluetooth Mesh uses managed flooding: every relay node rebroadcasts every packet it receives (TTL permitting). In a dense network this causes significant air-time contention and wasted energy, as most retransmissions do not contribute to delivery.
Directed Forwarding establishes on-demand routing paths between source and destination. A Directed Forwarding Originator floods a Path Discovery request; relay nodes along the best path respond, creating a Forwarding Table entry. Subsequent messages from the same source to the same destination follow the stored path — only nodes on the path rebroadcast.
| Metric | Managed Flooding | Directed Forwarding |
|---|---|---|
| Network air-time at saturation | High (O(N) retransmissions) | Low (path-limited) |
| Latency (first message) | Low (parallel flooding) | Higher (path discovery) |
| Latency (subsequent messages) | Low | Very low (no flooding) |
| Battery impact on non-path nodes | Wakes for every packet | Wakes only if on active path |
| Configuration required | None | Path Discovery enabled per node |
Path entries expire (configurable lifetime) and are refreshed automatically when traffic resumes. Lane Count extends each path to carry multiple concurrent streams, similar to MPLS traffic engineering.
Subnet Bridging
A single Bluetooth Mesh network is bounded by a shared Network Key (NetKey). All nodes in the network can decrypt and relay all messages — a flat security model. Large deployments often split into multiple subnets (different NetKeys per floor, building wing, or tenant) for administrative isolation.
Pre-1.1, messages could not cross subnet boundaries without a full application-layer gateway. Subnet Bridging adds a Bridge node role: a node that holds multiple NetKeys and translates messages at the network layer between subnets.
The Bridge maintains a Bridging Table — a list of (NetKey_A, address_A) → (NetKey_B, address_B) entries. The Configuration Client programs these entries remotely. Bridged messages are decrypted under the source NetKey, re-encrypted under the destination NetKey, and retransmitted on the destination subnet.
Security properties:
- Bridge node must be trusted (holds multiple NetKeys)
- Bridge does not decrypt upper-transport layer (app key remains end-to-end)
- Access control is per Bridging Table entry, not per address
Remote Provisioning
In Mesh 1.0, adding a new node required the Provisioner to be within direct BLE advertising range of the unprovisioned device. For large buildings this meant physically walking to each device — impractical for 1,000-node deployments.
Remote Provisioning extends provisioning across the mesh. A Remote Provisioning Server model runs on already-provisioned nodes near the new device. The Provisioner communicates with the Remote Provisioning Server via the mesh (encrypted), and the server acts as a relay for the provisioning protocol packets between Provisioner and the new device.
Remote Provisioning workflow:
- Provisioner queries Remote Provisioning Servers for scanned unprovisioned devices
- Server returns list of detected Unprovisioned Device Beacons with ATT">UUID and RSSI
- Provisioner selects the best server (highest RSSI to target) and opens a Remote Provisioning Link
- Standard provisioning handshake (invite → capabilities → key exchange → auth → data) tunneled through the mesh
- New node receives NetKey, AppKey, and address; becomes a full mesh node
This enables zero-touch provisioning workflows where devices are pre-loaded with a UUID at the factory, physically installed anywhere in the building, and provisioned from a dashboard without physical access.
Additional Mesh 1.1 Enhancements
| Feature | Description |
|---|---|
| Enhanced Provisioning Authentication | New Input/Output OOB methods including Certificate-Based (PKI) |
| Private Beacons | Randomized beacon payload to prevent long-term tracking of mesh nodes |
| Opcodes Aggregator | Bundle multiple model operations into a single Access message, reducing air-time |
| Large Composition Data | Supports nodes with more than 16 elements (addresses the 255-byte PDU limit) |
Mesh 1.1 is backward compatible: 1.0 nodes continue to operate as managed-flooding relays on a mixed network. Only nodes that implement 1.1 features (advertised in the node's Features field) participate in Directed Forwarding or Remote Provisioning.
Frequently Asked Questions
Yes, our guides range from beginner introductions to advanced topics. Each guide indicates its difficulty level and prerequisites so you can find the right starting point.