The Bluetooth protocol is commonplace in our lives across products like our phones, computers, headphones, and a growing number of IoT products. In 2017, seeking to leverage and further grow the ubiquity of the Bluetooth protocol, the Bluetooth SIG released Bluetooth Mesh functionality. At the surface this seems like a slam dunk concept. One, there’s already Bluetooth devices everywhere. Two, Bluetooth Low Energy (BLE) is great because of its low power performance, but it’s limited in its transmission range (often hundreds of feet, max). Bluetooth Mesh provides a solution.. Now a large area can be blanketed with numerous Bluetooth nodes to provide a low power and convenient wireless coverage through the Bluetooth Mesh protocol.
However, despite the apparent advantages, Bluetooth Mesh still has quite low adoption as I write this article (in early 2020). And why is this? It’s because Bluetooth mesh remains a highly complex and nuanced protocol. Implementing a Bluetooth Mesh solution is not just placing a handful of BLE sensors around an area and pressing an on switch. The network infrastructure needs to be thoughtfully tuned, configured, and programmed to meet a given application environment. However, for those who know how to do this right, Bluetooth Mesh can be a powerful tool in the toolkit. For the engineer who is not afraid to get into the weeds with Bluetooth Mesh, the below offers a mini tech handbook to some of the primary considerations.
Topology
The original, “OG” Bluetooth from the 2000s was a point-to-point protocol (e.g. one cell phone connecting to one wireless earpiece). When Bluetooth Low Energy (BLE) rolled out in 2010, it introduced a star topology (point-to-multipoint) such that a single central device could communicate to several peripherals. Bluetooth mesh has taken the protocol a step further to a many-to-many protocol, allowing a flexible protocol in which messages can be transmitted across all devices in a Bluetooth grid. However, it’s worth noting that Bluetooth Mesh is not fully egalitarian and not all nodes are created equally. “Edge” nodes are the mesh-capable sensors within the grid. There are also “Relay” nodes which only mesh to other nodes to forward messages along. “Proxy” nodes are connected to an internet network and operate as the source/sink for most of the messages in the network. As there are BLE devices which are not Mesh-capable, there are also “Friend” nodes which are placed next to non-Meshing BLE devices and allow them to access the network.
Networking
The maximum number of nodes in a Bluetooth Mesh network is 32,767. This network can have up to 4,096 subnets which allows for segregating the network into smaller logical sections (such as different floors in a building). Bluetooth Mesh uses a managed floor routing model for communication. This ensures that each message will get to the desired node in the mesh grid within a known number of “hops”. From a given node in the network, messages are broadcast to each node in its vicinity. After each hop, a time-to-live (TTL) value is decremented by 1. If a TTL value on a message reaches 0, the message is dropped. The maximum TTL is 126. This set the maximum number of hops that a message can make in a Bluetooth Mesh grid to 127.
Messaging
Bluetooth Mesh transmits messages in a 29-byte-payload format. Based on this payload size, the typical usage case for Bluetooth Mesh is to transfer state information between edge devices. The messaging is performed through a pub/sub paradigm. However, in contrast to a traditional pub/sub, there is no network broker. Instead the flow is governed by the managed floor routing model described above.
Provisioning
To bring a node onto the Bluetooth mesh network it must be provisioned. Provisioning can be done in a few ways, but it is most commonly performed using a provisioning mobile application (a proxy) or by another existing network node in mesh. There are 5 steps to the provisioning process:
A default encryption on BLE mesh is establishing an initial public key through an OOB mechanism. Once the initial share key is established, all communication is encrypted with an AES-128 symmetric cipher. Devices with more computational capability can use an Elliptic Curve diffie-Hellman (ECDH) to establish the initial shared key.
However, despite the apparent advantages, Bluetooth Mesh still has quite low adoption as I write this article (in early 2020). And why is this? It’s because Bluetooth mesh remains a highly complex and nuanced protocol. Implementing a Bluetooth Mesh solution is not just placing a handful of BLE sensors around an area and pressing an on switch. The network infrastructure needs to be thoughtfully tuned, configured, and programmed to meet a given application environment. However, for those who know how to do this right, Bluetooth Mesh can be a powerful tool in the toolkit. For the engineer who is not afraid to get into the weeds with Bluetooth Mesh, the below offers a mini tech handbook to some of the primary considerations.
Topology
The original, “OG” Bluetooth from the 2000s was a point-to-point protocol (e.g. one cell phone connecting to one wireless earpiece). When Bluetooth Low Energy (BLE) rolled out in 2010, it introduced a star topology (point-to-multipoint) such that a single central device could communicate to several peripherals. Bluetooth mesh has taken the protocol a step further to a many-to-many protocol, allowing a flexible protocol in which messages can be transmitted across all devices in a Bluetooth grid. However, it’s worth noting that Bluetooth Mesh is not fully egalitarian and not all nodes are created equally. “Edge” nodes are the mesh-capable sensors within the grid. There are also “Relay” nodes which only mesh to other nodes to forward messages along. “Proxy” nodes are connected to an internet network and operate as the source/sink for most of the messages in the network. As there are BLE devices which are not Mesh-capable, there are also “Friend” nodes which are placed next to non-Meshing BLE devices and allow them to access the network.
Networking
The maximum number of nodes in a Bluetooth Mesh network is 32,767. This network can have up to 4,096 subnets which allows for segregating the network into smaller logical sections (such as different floors in a building). Bluetooth Mesh uses a managed floor routing model for communication. This ensures that each message will get to the desired node in the mesh grid within a known number of “hops”. From a given node in the network, messages are broadcast to each node in its vicinity. After each hop, a time-to-live (TTL) value is decremented by 1. If a TTL value on a message reaches 0, the message is dropped. The maximum TTL is 126. This set the maximum number of hops that a message can make in a Bluetooth Mesh grid to 127.
Messaging
Bluetooth Mesh transmits messages in a 29-byte-payload format. Based on this payload size, the typical usage case for Bluetooth Mesh is to transfer state information between edge devices. The messaging is performed through a pub/sub paradigm. However, in contrast to a traditional pub/sub, there is no network broker. Instead the flow is governed by the managed floor routing model described above.
Provisioning
To bring a node onto the Bluetooth mesh network it must be provisioned. Provisioning can be done in a few ways, but it is most commonly performed using a provisioning mobile application (a proxy) or by another existing network node in mesh. There are 5 steps to the provisioning process:
- Beaconing (periodic broadcast from a new node looking for an invitation)
- Invitation to join the network from an existing network node or proxy
- Exchange and authentication of public keys (called “nonces”)
- Distribution of provisioning data (which contain the network encryption key, the unique device key, and an address that will be the network name for the new node)
A default encryption on BLE mesh is establishing an initial public key through an OOB mechanism. Once the initial share key is established, all communication is encrypted with an AES-128 symmetric cipher. Devices with more computational capability can use an Elliptic Curve diffie-Hellman (ECDH) to establish the initial shared key.
