The Bluetooth Low Energy (LE) standard has been around for over a decade, but it wasn’t until 2017 that the Bluetooth SIG released the Bluetooth mesh standard. Competing with other mesh-capable standards like Zigbee and Thread, Bluetooth mesh is designed to enable applications within the IoT by, for the first time, allowing for many-to-many communication over Bluetooth LE.
A few things to know:
- The Bluetooth SIG refers to the standard as Bluetooth mesh (with a lower-case “m” in the word “mesh”).
- The standard is not part of the Core Bluetooth standard (rather it’s defined in its own separate set of specifications).
- That said, Bluetooth mesh builds on top of BLE and utilizes many of the concepts in BLE.
- Bluetooth mesh utilizes only the advertising/scanning states of BLE devices. This means that devices that are part of a Bluetooth mesh network must relay information to each other via advertising packets, which are received by the other devices via scanning.
- Bluetooth mesh supports all versions of BLE (going back to Bluetooth version 4.0, which is the first version of the Bluetooth specification that included BLE).
- Bluetooth mesh does not support Bluetooth 5 features such as advertising extensions and the long-range mode (coded PHY), as of October 2022.
- The maximum number of nodes within a Bluetooth mesh network (defined in version 1.0 of the specification) is 32,767 nodes.
- The maximum hops a message can travel within a Bluetooth mesh network (defined in version 1.0 of the specification) is 127 hops.
What is Bluetooth mesh networking?
The Bluetooth mesh specification was released in July of 2017 with the goal of increasing the range of Bluetooth networks and adding support for more industrial applications that utilize Bluetooth LE.
Earlier versions of Bluetooth supported two different topologies:
- One-to-one: when two BLE devices are connected.
- One-to-many: when BLE devices operate exclusively in the Broadcast state, such as Beacons.
BLE mesh introduced a new topology for BLE: many-to-many. This is generally referred to as mesh topology, where many mesh devices can communicate with many other mesh devices within the same network using mesh nodes. This essentially creates large-scale device networks (think hundreds, if not thousands, of devices) that can be used for a variety of IoT applications.
Benefits of Bluetooth mesh
The main benefits of the Bluetooth mesh standard are:
- Built on top of BLE: Bluetooth mesh uses the same protocol stack as BLE. Smart devices with Bluetooth 4.0 or later (like many smartphones today) can utilize Bluetooth mesh technology directly.
- Global interoperability: devices and products from different manufacturers are guaranteed to interoperate as long as they are Bluetooth mesh certified according to the standard.
- Scalability: one of the main goals of Bluetooth mesh was to be scalable and be able to support a large number of participating nodes within a single network. Bluetooth mesh supports up to 32,767 elements (if each node has only one element, this makes this value the maximum number of devices per mesh network).
- Reliability: another goal was to make the standard reliable and be able to handle lost and/or corrupt messages.
- Security: security in Bluetooth mesh is mandatory to implement. This is compared to BLE where it’s optional and left to the developer to decide whether to implement or not in their application.
BLE mesh vs other wireless mesh specifications (like Zigbee)
There are a few differences between the BLE mesh protocol and other mesh networks out there like Thread, Zigbee and Z-Wave. Some of the important ones are:
- Bluetooth mesh does not use the Internet Protocol (IP) — instead, it builds on top of BLE.
- Bluetooth mesh uses a managed flooding technique compared to routing techniques that other protocols use.
- Bluetooth mesh has more robust security protocols than others like Zigbee.
- Bluetooth mesh is still primarily used for building automation applications, such as automating smart home devices and lighting systems, while other protocols like Zigbee are more widely used for things like asset tracking and industrial automation.
Bluetooth mesh networking – must-know concepts
To understand how Bluetooth mesh operates, there are a few (or maybe more than a few!) concepts you need to know:
- Mesh nodes: A mesh node is a device that has joined a Bluetooth mesh network. Devices that are not part of the network are called unprovisioned devices. Once an unprovisioned device gets provisioned, it joins the network and becomes a node.
- Elements: A node may contain multiple parts which can be controlled independently. For example, a light fixture may contain multiple light bulbs which can be turned on/off independently. These different parts of a single node are referred to as elements.
- Models: A model defines some or all functionality of a given element. There are three categories of models: server model, client model, and control model.
- States: Elements can be in various conditions, represented by state values. For example, on and off are states of a lightbulb within a light fixture. A change from one state to another is called a state transition. This can be instantaneous, or it can occur over time after what’s called a transition period. When a state change occurs, it is likely to cause a change in the behavior of an element.
- Properties: Properties add some context to a state value. For example, defining that a temperature value is an outdoor or indoor temperature. There are two types of properties: manufacturer property, which provides read-only access, and admin property, which provides read-write access.
- Scenes: A scene is a stored collection of states and is identified by a 16-bit number which is unique within the mesh network. Scenes allow triggering one action to set multiple states of different nodes. They can be triggered on-demand or at a specified time.
- Messages: Messages are the mechanism by which operations on nodes are invoked. If a node needs to report its status, it also sends it via a message. A given message type represents an operation on a state or collection of multiple state values.
- Addresses: Messages in a Bluetooth mesh network must be sent to and from an address.
💡Insider Tip: If you’re a professional Bluetooth developer, check out the Bluetooth Developer Academy, where you can unlock access to in-depth BLE development video courses + more!
How does Bluetooth mesh communication work?
The way messages are exchanged in a Bluetooth mesh network is via the publish-subscribe pattern. Publishing is the act of sending a message. Subscribing is a configuration used to allow select messages to be sent to specific addresses for processing. Typically, messages are addressed to group or virtual addresses.
Types of Bluetooth mesh messages
There are three types of messages in Bluetooth mesh, each of which is defined by a unique opcode (operation code):
- A GET message: a message to request the state from one or more nodes.
- A SET message: a message to change the value of a given state.
- A STATUS message: A status message is used in different scenarios:
- In response to a GET message, containing the state value.
- In response to an acknowledged SET message.
- Sent independently of any message to report the element’s status. One example is a message that’s triggered by a timer running on the element sending this message.
Some messages require an acknowledgment message to be sent by the receiver of the original message. An acknowledgment message serves two purposes:
- Confirmation of receipt of the message.
- Return of data related to the message received.
If a response to the message is not received by the sender, or an unexpected response is received, the sender may resend the message. Multiple acknowledged messages received by a node do not affect the behavior (it’s as if the message was received once).
Managed flooding
Many mesh networks use routing mechanisms to relay messages across the network. The other extreme is to flood the network with the messages being relayed without consideration of the optimal routes these messages need to take to reach their prospective destinations. Bluetooth mesh uses a technique that’s a compromise of both of these techniques. This technique is referred to as managed flooding.
Managed flooding relies on broadcasting messages to all nodes within range of the sender node, with a few added optimizations:
- Messages have a TTL assigned
TTL stands for time-to-live, which limits the number of hops a message can take across multiple nodes within the mesh network. A value of zero indicates that a message has not been relayed and should not be relayed. This means that a node can send a message to other nodes which are in its direct radio range and indicate to the receiving node(s) that the message should not be relayed.
If a message is sent with a TTL ≥ 2, then each time it is relayed, the TTL value gets decremented. A TTL value of 1 means that the message may have been relayed at least once, but that it should not be relayed again. - Messages are cached
Message caching is required by all nodes and requires that messages received that already exist in the cache get immediately discarded. - Heartbeat messages are sent periodically
Heartbeat messages are used to indicate to other nodes that the sender is alive and active within the network. - Friendship
Friendship refers to the relationship between two nodes. These two node types are:- A low-power node, or LPN, conserves power and is not able to receive mesh messages all the time. This node spends most of its time with the radio turned off.
- A live-powered node called the friend node, which can serve as a proxy for the LPN. The friend node caches messages for the LPN to save power, so that the LPN can stay asleep most of the time and only wake up occasionally. When the LPN wakes up, it polls the friend node to read the cached messages and sends any messages it needs to send to the mesh network.
Types of nodes
All types of nodes can send and receive mesh messages. However, optional features give particular nodes special capabilities. Here are the different types of nodes with optional features enabled:
- Relay nodes
- Proxy nodes
- Friend nodes
- Low power nodes
A node may support none, some, or all of these optional features, which may be enabled or disabled at any time. For example, a single node may have the features of a relay node, proxy node, and friend node, all at the same time.
Relay nodes
A relay node is one that supports the relay feature. This means it can retransmit messages that are broadcast by other nodes. This enables extending the reach of these messages and allows them to traverse the entire network beyond the reach of the original transmitting node.
Proxy nodes
To allow communication with a mesh network from a non-mesh-supported BLE device, a special type of node called a proxy node can be utilized. A proxy node acts as an intermediary and utilizes GATT operations to allow other nodes outside of the mesh network to interface and interact with the network.
The protocol used in this case is called the proxy protocol, which is intended to be used with a connection-enabled device (using GATT).
The protocol is built on top of GATT and allows a device to read and write proxy protocol PDUs from GATT characteristics exposed by the proxy node. The proxy node performs the translation between proxy protocol PDUs and mesh PDUs.
For example, this allows a smartphone that does not implement the Bluetooth mesh protocol to interact with a mesh network via a proxy device through GATT operations.
Friend Nodes and Low Power Nodes
A friend node and a low-power node (LPN) are closely related to each other. In fact, in order for a low-power node to participate in a Bluetooth mesh network, it requires a friendship relationship with another node, called the friend node.
Here are how these two types of nodes work together:
- Low-power nodes usually have limited power supply, such as batteries, so they need to conserve energy by keeping the radio off as much as possible.
- Low-power nodes may be concerned with sending messages more than receiving them. Take, for example, a temperature sensor powered by a coin cell battery. It may need to send the temperature reading once per minute whenever that reading is above or below a set limit. If the user decides to change the threshold limit, then that gets sent in a message to the temperature sensor. In order for the sensor to not miss this threshold configuration message, it needs to be on all the time, meaning it will consume a lot of power.
- To solve the problem mentioned in the previous point, the concept of a friend node is introduced. A friend node lets the low-power node stay asleep longer.
- Friend nodes make this possible by caching messages that are destined for the low-power node. The low-power node, at its control, wakes up and polls the friend node for these cached messages. When it polls for the messages, it also sends any messages it needs to relay to the network to its friend node.
- The relationship between a friend node and a low-power node is known as “friendship.”
- Friendship is key to allowing power-constrained nodes to participate in a mesh network while keeping their power consumption optimized.
💡Insider Tip: Get exclusive access to step-by-step Bluetooth development courses as a Bluetooth Developer Academy member!
Bluetooth mesh example
Here’s an example of a mesh network in a home that’s composed of 6 light switches and 9 light bulbs. The network utilizes the publish-subscribe method to allow nodes to send messages to each other.
Nodes may subscribe to multiple addresses. An example of this is light #3 in the above figure, which is subscribed to both the kitchen and the dining room group addresses. Also, multiple nodes may publish to the same address, such as switches #5 and #6 in this example. These two switches control the same group of lights located in the garden.
The benefit of using group or virtual addresses is that adding or removing nodes does not require the reconfiguration of nodes.
Bluetooth mesh architecture
Bluetooth mesh builds on top of Bluetooth LE. It specifically utilizes the advertising state of BLE devices. Devices within a Bluetooth mesh network do not connect to each other as traditional BLE devices do. Rather, they use advertising and scanning states to relay messages to each other. There is one exception to this in a special device that can be part of the mesh network, the proxy node (which we covered in the previous section on “Node Types”).
Here’s a description for each of the layers within the architecture of Bluetooth mesh (starting with the bottom layer):
- Bluetooth Low Energy layer
As we mentioned earlier, Bluetooth mesh builds on top of Bluetooth LE, so it requires a full BLE stack to be running on the device. It utilizes the advertising and scanning states for sending and receiving messages between devices within the mesh network. It also supports the connected state and GATT for the proxy nodes. - Bearer layer
The bearer layer defines how the different mesh packets (Protocol Data Units or PDUs) are handled. There are two types of Bluetooth mesh bearers:- Advertising bearer: this bearer utilizes the advertising and scanning states of BLE devices.
- GATT bearer: this bearer utilizes the connection state of BLE devices. It allows non-mesh supporting devices to interact with the mesh network via GATT operations. This is accomplished via the proxy node.
- Lower transport layer
This layer handles two main tasks:- Segmentation of packets from the layer above (upper transport layer)
- Reassembly of packets from the layer below (bearer layer)
- Upper transport layer
This layer is Responsible for the following functionalities:- Encryption
- Decryption
- Authentication
- Transport control messages (heartbeat, friendship, etc.)
- Access layer
This layer defines how the application uses the upper transport layer. It handles the following tasks:- Application data format
- Encryption and decryption
- Data verification
- Foundation Models layer
This layer is concerned with network configuration and network management models. - Models layer
This layer addresses the implementation of models, including behaviors, messages, states, and state bindings.
The provisioning process
The provisioning process is one of the most important concepts in Bluetooth mesh. It is used for adding devices to the mesh network. A device that gets added to the network is called a node, and the device used to add a node to the network is called the provisioner (usually a tablet, smartphone, or PC).
This process involves five steps:
Step 1: Beaconing
Step 1 involves what’s called beaconing, where the unprovisioned device announces its availability to be provisioned by sending the mesh beacon advertisements in the advertisement packets. This is a new type of advertisement data type introduced in the Bluetooth mesh standard. A common way to trigger this process is via a defined sequence of button presses on the unprovisioned device.
Step 2: Invitation
When the provisioner discovers the unprovisioned device via the beacons that were sent, it sends an invitation to this unprovisioned device. This uses a new type of PDU introduced in Bluetooth mesh called the provisioning invite PDU.
The unprovisioned device then responds with information about its capabilities in a provisioning capabilities PDU, which includes:
- The number of elements the device supports.
- The set of security algorithms supported.
- The availability of its public key using an Out-of-Band (OOB) technology.
- The ability of this device to output a value to the user.
- The ability of this device to allow a value to be input by the user.
Step 3: Public key exchange
Security in Bluetooth mesh involves the use of a combination of symmetric and asymmetric keys, such as the Elliptic-curve Diffie-Hellman (ECDH) algorithm. In ECDH, public keys are exchanged between the provisioner and the device to be provisioned. This is done either directly over BLE or via an out-of-band (OOB) channel.
Step 4: Authentication
The next step is to authenticate the unprovisioned device. This usually requires an action by the user to interact with both the provisioner and the unprovisioned device. The authentication method depends on the capabilities of both devices used.
In one case, called the output OOB, the unprovisioned device could output a random single- or multiple-digit number to the user in some form, such as blinking an LED a number of times. That number is then input into the provisioning device via some input method. Other cases include an input OOB, where the number is generated by the provisioner and entered into the unprovisioned device, a static OOB, or no OOB at all.
Regardless of the authentication method used, the authentication also includes a confirmation value generation step and a confirmation check step.
Step 5: Provisioning data distribution
After authentication is complete, each device derives a session key using its private key, and the public key is sent to it from the other device. The session key is then used to secure the connection for the exchange of additional provisioning data, including the network key (NetKey), a device key, a security parameter known as the IV index, and a unicast address which is assigned to the provisioned device by the provisioner. After this step, the unprovisioned device becomes known as a node.
How is security handled in Bluetooth mesh?
The first important note regarding security in Bluetooth mesh is that it is mandatory. This is compared to BLE, where it’s optional and left to the developer to decide whether to include it or not.
Here are some of the basics of security in Bluetooth mesh:
- All mesh messages are encrypted and authenticated
- Network security, application security, and device security are all handled independently.
- Security keys can be changed during the life of the mesh network
Due to the separation of security between the network, application, and device levels, there are three types of security keys (each addressing a specific concern):
- Network key (NetKey)
Possession of this shared key makes the device part of the network (also known as a node). There are two keys derived from the NetKey: the network encryption key and the privacy key. Possession of the NetKey allows a node to decrypt and authenticate up to the network layer, allowing the relay of messages but no application data decryption. - Application Key (AppKey)
This is a key that’s shared between a subset of nodes within a mesh network, normally those that participate in a common application. For example, a lighting system AppKey would be shared between light switches and light bulbs, but not with a thermostat or a motion sensor.
An AppKey is used to decrypt and authenticate messages at the application level, but it is only valid within one mesh network, not across multiple networks. - Device Key (DevKey)
This is a device-specific key that’s used during the provisioning process for securing communication between the unprovisioned device and the provisioner.
Node removal
One major concern with a mesh network is gaining access to a network via a discarded or removed device that used to be part of the network. This can be accomplished via gaining physical access to the keys stored within the device (often referred to as a trash can attack).
In order to protect against such an attack, Bluetooth mesh defines a procedure for the removal of a node where the device is added to a blacklist and the keys are refreshed. This process distributes new network keys, application keys, and other relevant data to all nodes except those in the blacklist.
Privacy
Another concern is privacy. The way privacy is addressed in Bluetooth mesh is via the use of a privacy key that’s used to obfuscate the message header. The privacy key is derived from the network key (NetKey). For example, the source address could be obfuscated to prevent tracking of a device via its address.
Replay attacks
The last security topic we want to cover is replay attacks. A replay attack is when one or more messages are stored and replayed later by a malicious device.
Bluetooth mesh provides protection against replay attacks by:
- Utilizing a sequence number (SEQ). Elements increment the SEQ value every time they publish a message. A node, receiving a message from an element that contains an SEQ value that’s less than or equal to the one in the last valid message, will discard it (since it is likely that it relates to a replay attack).
- Using an incrementing IV index, which is an additional value that also gets validated when a message is received.
Conclusion
While some may say that Bluetooth mesh has had a slow adoption rate, there’s still real potential for it to enable IoT applications in the near future.
In this post, we covered a lot, and there’s still so much more to learn about Bluetooth mesh. Look for a series of upcoming posts covering more of the implementation aspects of the technology, where we build out both a Bluetooth mesh light bulb and a light switch.
💡 Want to get your Bluetooth-connected devices to market faster? Enroll in the Bluetooth Developer Academy today and get exclusive access to in-depth courses built for developers.