The Bluetooth Special Interest Group (SIG) has released a standard for Bluetooth mesh networking. The mesh capability is based on Bluetooth Low Energy (LE) and utilizes the PHY and link layer for Bluetooth 4.x. So supporting it on existing hardware will typically be a matter of providing a suitable protocol stack and application support. For example, Silicon Labs’ Bluetooth mesh stack (Fig. 1) builds on the existing Bluetooth link layer.
Current mesh models target control applications such as lighting control and sensor networks. These applications typically involve smaller packets, so the 1 Mbit/s speed should prove to be more than adequate. Larger messages can be sent across the mesh, though, and are supported through a segmentation and reassembly procedure in the mesh protocol stack.
Bluetooth mesh underwent comprehensive, multi-vendor interoperability testing throughout the specification development process. This should allow a mixture of third-party nodes to properly interact within a mesh network. The success of Bluetooth, in general, in terms of compatibility between third-party products is an achievement that will extend to mesh products. Vendor-specific models are also supported within Bluetooth mesh, as well as Bluetooth Generic Attribute (GATT) profiles and services.
Bluetooth mesh employs a managed-flooding model where nodes echo data that is being sent through the mesh. Typically flooding works for small networks with dozens of nodes but the Bluetooth mesh approach is designed to scale to thousands of nodes. A single switch node might need to turn on hundreds of lights in a building at the same time.
Bluetooth mesh supports sending messages to either unicast addresses or one of two types of multicast address. Group addresses can be user-defined and will typically correspond to types of devices in certain parts of a building, such as “First Floor Lights.” The specification also defines some special group addresses which identify collections of the various types of node in a mesh network. They are named All-proxies, All-friends, All-relays, and All-nodes.
Virtual addresses provide a means of associating one or more labels with nodes and allow mesh messages to be sent to all nodes with a particular label value, anywhere in the mesh network. CAN networks actually use this addressing scheme where it is really the packet that is identified, rather than the node. This actually works well with the flooding model.
A publish/subscribe communication model is supported by Bluetooth mesh. For example (Fig. 2), switches publish the area they control so that when a switch is toggled, the corresponding subscription for a light allows the light to change state.
The mesh technology employs 4.x Bluetooth provisioning and security. It uses a two-key approach like LoRaWAN, where a network key provides access to the mesh network and applications keys provide access to services on the network. This approach allows secure mixing of devices on a network while providing a level of control among applications services.
Bluetooth already has multiple standards and protocol stacks. Many systems support more than one of these, allowing the system to access devices that support different standards. They often timeshare the networking hardware because of the differences between protocols, so the Bluetooth mesh support will just be another added to this list. As it is not compatible with any existing standard, new protocol stacks for the likes of Android and iOS will be needed to talk to a Bluetooth mesh network. Silicon Labs has an Android app and stack at this point, with IOs on the horizon. Other Bluetooth hardware vendors have similar support.
Silicon Labs’ Blue Gecko (Fig. 3) will be able to be part of a Bluetooth mesh network using its latest protocol stack. The software development tools for the board include the Simplicity Studio. The Studio includes a graphical GATT editor and hardware configuration tool. The network analyzer tool will work with any compliant Bluetooth mesh and nodes.
The Blue Gecko development board includes an Ethernet connection. This allows debugging and packet trace with the network analyzer tool over Ethernet, so the mesh network does not have to handle any debugging overhead. This type of backend debugging is invaluable for any type of wireless network, but especially for mesh networks.
