Bluetooth has been around for a while. In fact, it recently it celebrated its 20th year anniversary!
The introduction of the Bluetooth Low Energy (BLE) standard came in 2010 to address the rapid growth of use cases in the Internet of Things (IoT) field including sensors, wearables, medical devices, etc. However, one thing that BLE lacked since the beginning was the capability of supporting a many-to-many topology (often referred to as mesh), where multiple BLE devices can send each other messages and relay messages to other devices within a network.
This all changed in July 2017 when the Bluetooth SIG released the Bluetooth mesh standard.
We’ll be going over the most important basics you need to know to better understand Bluetooth mesh and how it works. The topic of Bluetooth mesh is extensive and cannot be covered in a single post, so we’ll be covering it in a series of blog posts. In today’s tutorial, we’ll be going over the following aspects:
- Basics of Bluetooth mesh
- Managed Flooding
But first, a few important notes regarding Bluetooth mesh:
- 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 specification).
- That said, Bluetooth mesh builds on top of BLE and utilizes many of the concepts in BLE.
- There are two main states that a BLE device operates in: advertising (or scanning), or in a connection. Bluetooth mesh utilizes only the advertising/scanning states of BLE devices. This means that devices that are part of a Bluetooth mesh network do not connect to each other the way traditional BLE devices do. But rather they relay information to each other via advertising packets which are received by the other devices via Scanning (there is one exception though, involving what’s called a Proxy node, which we’ll cover shortly).
- 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).
- Currently, as of the time of this article (September 2018), Bluetooth mesh does not support Bluetooth 5 features such as advertising extensions and the long-range mode (coded PHY).
- 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?
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 BLE.
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.
With Bluetooth mesh, a new topology is introduced for BLE. Devices can now operate in a many-to-many topology, or what’s called mesh, where devices can set up connections with multiple other devices within the network.
From Wikipedia’s page on mesh networking:
A mesh network is a local network topology in which the infrastructure nodes (i.e. bridges, switches and other infrastructure devices) connect directly, dynamically and non-hierarchically to as many other nodes as possible and cooperate with one another to efficiently route data from/to clients. This lack of dependency on one node allows for every node to participate in the relay of information. Mesh networks dynamically self-organize and self-configure, which can reduce installation overhead. The ability to self-configure enables dynamic distribution of workloads, particularly in the event that a few nodes should fail. This in turn contributes to fault-tolerance and reduced maintenance costs.
There are two main benefits of a mesh network:
- Extended range:
Since nodes can relay messages to far away nodes via the nodes in between them, this allows a network to extend its range and expand the reach of devices.
- Self-healing capabilities:
Self-healing refers to the fact that there is no single point of failure. If a node drops from the mesh network, the other nodes can still participate and send messages to one another. However, this is only partially true for Bluetooth mesh since it has different types of nodes within the network, some of which other nodes may depend on.
Comparison With Other Wireless Mesh Networks
There are a few differences between the Bluetooth mesh protocol and other mesh networks out there (including 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.
- Even though Bluetooth mesh builds on top of BLE and utilizes the Bluetooth brand, it is actually a new technology that has yet to prove itself in the market.
- The main focus of the current Bluetooth mesh standard (version 1.0) is for lighting applications. That’s not to say it cannot work for other applications, it’s just simply easier to currently apply it to lighting systems.
Let’s go over some of the most important concepts within Bluetooth mesh.
Bluetooth Mesh Concepts
There are many concepts that we need to cover to better understand the way Bluetooth mesh operates. We’ll cover all of them starting with this post, and continuing in the upcoming posts within this series.
A 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.
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.
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.
Some states may be bound to each other, meaning that a change in one state triggers a change in the other. There may be two or more states bound to each other. Let’s take for example a light dimmer: it will likely have a level state as well as an on/off state. If the level state value changes to zero, it will trigger the on/off state to transition to off. If the level value changes from zero to a non-zero value, then that triggers the on/off state to transition to on.
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: provides read-only access
- Admin property: provides read-write access
In Bluetooth mesh, all communications within the network are message-oriented, and nodes send messages to control or relay information to each other. 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.
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.
In the case where 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).
Messages in a Bluetooth mesh network must be sent to and from an address. There are three types of addresses:
- Unicast Address: an address that uniquely identifies a single node assigned during the provisioning process (which we’ll cover in an upcoming post).
- Group Address: an address used to identify a group of nodes. A group address usually reflects a physical grouping of nodes such as all nodes within a specific room. A group address could either be:
- Defined by the Bluetooth SIG, also referred to as a SIG-Fixed Group Address. These include All-proxies, All-friends, All-relays, and All-nodes group addresses.
- Dynamic Group Address, which is defined by the user via a configuration application.
- Virtual Address: an address that may be assigned to one or more elements, spanning one or more nodes. This acts as a label and takes the form of a 128-bit UUID with which any element can be associated. Virtual addresses are likely to be preconfigured at the time of manufacturing.
The way messages are exchanged in a Bluetooth mesh network is via the publish-subscribe pattern. From Wikipedia’s page on the publish-subscribe pattern:
In software architecture, publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead categorize published messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are.
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 groupor virtual addresses.
Here’s an example of a mesh network in a home that’s comprised 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 reconfiguration of nodes.
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 perspective 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 that the receiving node(s) should not relay the message.
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 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.
There are several other types of nodes in a mesh network which we’ll be covering in a later post.
In this post, we covered the basics and some of the most important terminologies in Bluetooth mesh. In the upcoming posts within this series, we’ll be covering more aspects of Bluetooth mesh including:
- The architecture of Bluetooth mesh
- The types of nodes in a Bluetooth mesh network
- The provisioning process
In addition, later on, we’ll get into some of the practical aspects of Bluetooth mesh and how to implement it for the Nordic nRF52 platform.