Bluetooth SIG has recently published a new standard, the Bluetooth mesh. The mesh capability is a significant update and enables radical new applications. This in turn means that there are significant changes, and many new concepts to learn for developers and product makers. Knowing the technology well is key if you want to succeed with mesh, or any technology for that matter.
It is futile to summarize mesh in a blog post, so the aim here is to give you a rough understanding of what Bluetooth mesh is designed for, some of the new concepts, and things that are important to keep in mind. Hopefully this blog will answer the question: Is this technology right for my product?
Flooding is a networking technique where every incoming packet to one node is repeated to all connected nodes. Bluetooth mesh relies on BLE scanning and advertising, so it simply means that every received packet is broadcasted again, until the packet reaches the destination node. This is a simple, but effective way of spreading information across the mesh network.
The main advantage of a wireless mesh network is that the range extends beyond the simple point-to-point RF range. This allows the network to cover large physical areas, or give good indoor coverage where signals are faded by walls and physical objects. Another important advantage is that each packet of information will have multiple paths, and this will increase reliability. Multiple nodes rebroadcasting the same packet increases the probability that the packet reaches its destination. If a node malfunctions, the rest of the network will still function.
Since the bandwidth in the advertising channels is precious, it is import to manage its use. There are a few mechanisms in place to limit this. The first is the time-to-live (TTL) counter, that defines how many times a packet can be broadcasted, the maximum being 127. Once the counter reaches ‘1’ the broadcasting ends. The second is a message cache of transmitted packets. If a received packet is found in the cache it will not be retransmitted, because the transmission has simply gone in a circle. The last thing that limits bandwidth use is that the relaying feature is optional. So, it is possible to let some nodes communicate with the mesh, but not relay packets. Depending on the network topology, and density of nodes, it might be beneficial to restrict the number of relaying nodes.
In order to be responsive the nodes in the network needs to be almost constantly in receive mode. Speaking of power consumption, that means that the receive current will dominate. While those currents are lower in BLE than many other wireless technology we are no longer talking about battery operated applications.
But in the context of light control that is not a major issue, since lights are connected to a power source. For other units, such as light switches there is a feature called Friendship that enables nodes to only be in receive mode at scheduled events. The Low Power Node will then receive cached messages from a Friend, allowing the Low Power Node to be battery powered or use energy harvesting.
Definition of low power apart, it is clear that this technology depends on mains powered nodes. Low power nodes can be added to the network, but network itself is not a battery-operated solution. This is an important difference from existing Bluetooth technology.
In addition to address individual nodes, Bluetooth mesh also allows you to address groups of nodes. The combination of flooding mesh and group addresses makes this solution well adapted to light control. Imagine a light switch sending a radio packet instructing lights in a defined group to be switched on. In a flooding mesh the packet will spread quickly through the mesh network, and the decision to act on the message is done at each node. With this solution a large number of lights can be switched on in the same instant. Contrast this with a solution where each light use a BLE connection to switch operating in the central role and you should understand the advantage.
Is Bluetooth mesh a light control solution? Not really, but light control has been a critical use case for the specification. Bluetooth mesh really shines when you combine different technologies in one solution. One of these technologies is smart lighting, which is well covered by Bluetooth mesh. With a network of nodes that can do BLE broadcasting you get a beacon solution for free, along with a network to remotely manage the beacons. In addition, it is possible to fit sensors to the nodes and use the data for building automation and management.
The beauty of Bluetooth mesh is that the three mentioned use cases are served by one network. To power the network can be retrofitted on existing infrastructure; the lighting system, which is present in virtually every building.
With Bluetooth technology in everyone’s pocket it is also a network people can interact with. The network can include beacon signals, listen for beacons, or the user can connect through a GATT connection. That is the options for now at least, hopefully the mobile operating systems will quickly incorporate Bluetooth mesh technology.
Whenever IoT is discussed it doesn’t take long before security is mentioned, and rightly so. Bluetooth mesh has focused heavily on security and is quite forward looking in that sense. Security is key for successful adoption, but it also brings challenges.
The main challenge is to set up the network, or provisioning. To secure on-air-traffic all data is encrypted, and secure distribution of encryption keys is required. Bluetooth SIG has specified the procedures for this that ensures security, but usability is something that the product maker must ensure. If you want to differentiate your product this is good area to focus on.
After successful provisioning your data is well protected. Packets are encrypted end-to-end with AES-128, and again with AES-128 between each hop to hide the node addresses and increase privacy. Multiple application keys are supported in order so separate use cases, preventing for example to let light control open door locks. There are also procedures in place to refresh the encryption keys, and to detect replay attacks.
The success of BLE should at least in part be attributed to GATT profiles, which allowed a large number of use cases to share a common information structure. Bluetooth mesh follows the same principle, but because of the distributed nature of a mesh network the design of ‘profiles’ had to be different. And to avoid GATT profiles to be mistaken for the mesh equivalent, the term Models was introduced.
The first version of the Bluetooth mesh specification includes Foundation models which are related nodes and the network itself: Configuration, Heartbeat, and Health. The mesh specification is accompanied by the Mesh Models specification that specified models for use cases: Generic, Lighting, Sensors, and Scene. It is also possible to implement custom models, just as with GATT.
Mesh models is a large topic. The important thing is that Bluetooth mesh includes application level concepts. The implementation is light weight, backwards compatible, and will hopefully lead to an interoperable mesh solution.
First, let us dispel a common misconception; with the launch of Bluetooth 5 fresh in mind, many think that mesh is a Bluetooth 5 related feature. Actually, the mesh technology is based on BLE advertising and scanning, requiring only Bluetooth 4.0.
But above these layers just about everything is new, introducing changes that are comparable to differences between BR/EDR and BLE. Just as the burst transfer operation of BLE required changes from the continues stream BR/EDR was built for, so does the many-to-many topology require a new protocol design.
It is natural to question this design, but the good thing is that Bluetooth 4.0 compatible controllers are abundant, and the technology mature. The new technology is in most cases implemented in software, and thus easy to adapt as products are being developed.
The bandwidth and power consumption will most likely disappoint some, appearing in some way as a setback. As mentioned there are some good reasons for these design choices. For many use case there is no need for high bandwidth; the main drivers are cost and reliability. In a sense Bluetooth mesh is not new technology, but new application of a mature and proven technology.
Beside the issues regarding bandwidth and power consumption, the rest of the solution is solid in terms of networking, security, and interoperability at the application layer. Both the bandwidth and power consumption can be improved by improving the Bearer layer, either as proprietary solution, or as a future Bluetooth specification.
Bluetooth standards are under continuous change, improving the technology and introducing new capabilities. And Bluetooth mesh is no exception.
@Mark: Yes, I definitely think Bluetooth mesh is worth the consideration. Scalability is largely a question about the use case. For what you describe it is the number of sensors, and how often they report that will decide how well the mesh scales.
If the nodes are far apart you could also limit the number of relaying nodes to avoid congesting the advertising channels. It should also be possible to add routing algorithms in a addition to the stack, and it should still be interoperable.
Eirik thanks for this post - clarified some aspects of BT mesh for me. I also came across a recent post of yours promoting BT mesh for applications based around industrial lighting but nowhere can I find any suggestions as to how this is going to scale. If we're looking at applications with 1000+ sensors plus similar numbers of powered lighting/relay nodes across large industrial sites is BT mesh worth looking at or is it going to grind to a halt at a few hundred nodes or less perhaps?
With a little optimization you'll get it down to 16kb, if you want to get it even lower it's going to get hard. Not impossible probably, but very hard.
@Calin M I think FruityMesh also needs at least 16kb RAM. github.com/.../Developers
Could a fruitymesh application fit on a 51822/QFAA chip, or will it require a 51822 / QFAC?