Beta Solutions Blog

A Closer Look at the New Bluetooth Mesh

Date:  Oct 26, 2017


After a few years of being "around the corner" Bluetooth Mesh is finally here. Several product designers and developers have made their own meshes based on Bluetooth LE in the long wait for a standard (indeed we have also developed our own). However, we no longer need to rely on custom requirements. The new specification aims to be another contender in the Smart Home and Industrial Automation IoT markets, which are currently dominated by a plethora of other protocols (e.g. ZigBee, Z-Wave, WiFi, Thread). Shortly after its release earlier this year major players in the Bluetooth Special Interest Group (Bluetooth SIG) had software ready to go. With all the hype we are sure that the mesh will be implemented across various industries and applications. But what exactly is this new mesh, and why would you want it implemented in your products over other wireless protocols?

The New Mesh

Traditional communication is often point to point, whether it be a direct connection from your phone to a wireless headset, or a more complex connection from your laptop to a server which runs through various routers, switches, and adapters. Data often travels through a set route that is determined by central controllers and gateways in the network. Mesh networks tend to move away from the dedicated router approach. Devices themselves are allowed to act as relays of information. When data needs to travel between points in a network, the data will move through other untargeted devices to get to the final destination. This is the world of IoT. Below is a diagram of a mesh network when compared with a more traditional point to point system:


Figure 1. A very simplistic view of a mesh system compared to a more standard point to point protocol. In the mesh nodes will re-transmit data to other nodes that are further away.
Figure 2. Point to point, or point to multi-point systems will often just be a one to one or one to many connection, such as a connection from your wireless mouse, keyboard, or headset to a central laptop.



The Bluetooth Mesh implements a new form of mesh protocol, and it does it well through existing Bluetooth LE hardware. This means it's very likely your Smart Phone will implement some aspects of the new mesh in the near future. You'll likely be able to connect to your Bluetooth Smart Home devices without the need for a central hub. However, from a more technical point of view, this means implementing a Bluetooth Mesh has a fair bit of complexity attached when it comes to laying out a network. With IoT also comes the concern of security which is handled much like the traditional Bluetooth security features that we're used to with "authentication" and "pairing" protocols, among new "provisioning" protocols. 
If you're just curious about the new technology and how it fits into the IoT landscape, skip ahead to the "Comparison with Alternative Technologies" section. However, for the more technical readers we'll now get to the nuts and bolts of the mesh, where we'll take a slightly more in depth look at 1. The mesh topology in general, 2. The communication protocol between nodes, and 3. Some of the security features in place.

1. Bluetooth Mesh Topology

The Bluetooth Mesh is a flood mesh. When a message is transmitted across the network, all devices (nodes) that are configured as relays will re-transmit the message. A message will only have a limited number of "hops", or re-transmissions, before it stops. This extends the range of Bluetooth LE to incredible distances, where the specification gives a theoretical limit of up to 127 hops, otherwise known as a message's Time To Live (TTL). The network can be described by the following diagram:


*Figure 2. An example Bluetooth Mesh network topology. It is fairly complex, with various features that could be supported, or not supported by any one node.


Every node can send or receive messages across the mesh, but there are also additional mesh related features that a node could support. The four features are:


  • Relay Feature
    A relay is able to re-transmit messages it receives to the rest of the network through the advertisment bearer.
  • Proxy Feature
    Provides the relay feature, as well as allows messages to be re-transmitted through the GATT bearer. This would allow devices such as phones to communicate with the mesh through a standard Bluetooth LE GATT protocol.
  • Low-power Feature
    A node that operates at significantly low power, requiring a "friend" node to store messages
  • Friend Feature
    A node that stores messages for low-power nodes, and forwards these only when the low-power node requests them.


Proxy nodes include a standard Bluetooth LE GATT service with two Proxy Data attributes. A Smart Phone could connect to any Proxy node to transmit messages to the rest of the network through these attributes via a "Proxy Protocol".


Low-power nodes require friend nodes in the mesh. A "friendship" is negotiated when a friend node sees a friendship request being advertised by a low power node on the network. If a friendship is established a friend will hold messages for the low power node until it asks for them. This allows a low-power node to turn off its receiver a majority of the time and achieve very low power consumption. However, other nodes on the network are expected to receive messages in real time, requiring higher power. This means they would likely require continuous external power, or much more regular battery replacement.

2. Bluetooth Mesh Messaging

The mesh network moves away from the well-known GATT model for Bluetooth LE. It implements unique data structures called "elements". Every element must have one or more models, where the models determine and implement the behaviour of a node, while the states inside them define the current condition of the element.


*Figure 3. Pictorial representation of the new element model. Nodes can have multiple elements with multiple models. States within these models define the current state of a device.


E.g. A lightbulb:



- Will have a generic "lightbulb" element, but could also have temperature elements, and so on.
- The lightbulb element could have an "On/Off" model, and a "Brightness" model.
- Each of these models will have their own unique states, where the On/Off would have a boolean "on" or "off" state, whereas the brightness could have a state value of 0 to 10.

Figure 4. Example lightbulb node.


The mesh also supports composite states, where two or more values can make up a state, allowing you to define data structures. States can also be bound together by a model, where in the example above, setting a brightness could also turn on the lightbulb.


The network communicates via the same client-server architecture Bluetooth developers are used to. Devices acting as clients can read states or write messages to elements on servers. Models will determine whether there is an action taken for a given message, and whether a state change will occur. A publish-subscribe mechanism is in place, where devices can publish messages to certain addresses. If another device is subscribed to messages on that address, it will receive the message. These messages are allowed to be either acknowledged or unacknowledged.
The mesh network communicates via two different messages.


  • Control Messages:
    Mesh related messages related to things like regular heartbeats and friend requests.
  • Access Messages:
    Used to retrieve, set, and report the values of states in server models.


For addressing of messages, there are a few options in place. 


  • Unicast Address:
    Every element in the network has a unique unicast address. This achieves basic point-to-point communication
  • Group Address:
    These are addresses that group multiple elements across one or more devices. There are custom dynamic groupings which can be set up by a user on the fly, as well as a few Bluetooth specified group addresses including "All Proxies," "All Friends," "All Relays," and "All Nodes" in the network. It is expected meshes will use group addresses to address things like different rooms or floors of a building.
  • Virtual Address:
    A hashed address of specific Label UUIDs. A Label UUID is a generic 128 bit value associated with one or more elements in a network. These are expected to be vendor specific addresses, where vendors can identify/address their own devices within a network.


Previous to setup, elements will generally have unassigned addresses. Elements with an unassigned address are banned from communicating with the network. When a mesh connection is established, a provisioner will assign appropriate addresses (see the next section for a brief overview of provisioning).

3. Security of the Bluetooth Mesh

Devices can be added to or removed from a mesh via a new process called "provisioning." Devices that can be added to a mesh will act as beacons and advertise their intent to join a network. Nodes acting as provisioners will scan for these beacons and extend an invite to the network. A pairing process similar to standard Bluetooth LE is followed, where keys are exchanged and an authentication protocol is chosen based on the input and output capabilities of the device. The standard example is having a screen on one device display a number that is entered as a passkey on another device.


There are three types of keys present in the network, giving multiple layers of security


  • Network key
    A key shared by nodes on a mesh. This key will be used across all devices on a network to transmit and relay information. A device could store one or more network keys, and therefore be part of one or more subnets.
  • Application key
    Bluetooth Mesh uses a concept of "Separation of Concerns." Essentially the idea is that a device such as a light bulb has no business knowing the content of messages sent to door locks. A separate application key can be used to share information across the network for specific devices. Unrelated relays will still re-transmit these messages, but will have no idea of the content of these messages.
  • Device key
    A key unique to the device and provisioner. 


Overall the Bluetooth Mesh is expected to be a very secure network. In addition to the keys mentioned above which keep data private and secure from listeners, the specification also provides protection against:


  • Replay attacks
    A replay attack is an attack where a message that has been previously sent across the network is simply repeated (e.g. An "open door" message is seen by an attacker and is used later when the homeowner has left). A Bluetooth Mesh handles this through the use of sequence numbers. Devices have unique counters associated with them that are transmitted and incremented with each message. For a message to be considered valid by another device, it will need to see an incremented count on the given source address.
  • Man-in-the-Middle attacks
    A man-in-the middle attack occurs when an attacker pretends to be another device. When a user tries to connect to a legitimate device it could instead connect to the attacker, posing a risk to exchanging critical security data. The Bluetooth Mesh has a few guards for this. Authentication is often required to add devices to a network, requiring "Out of Band" keys. A user can validate the correct device is being connected to through the input of a displayed passkey, or through other procedures. Furthermore, the use of public and private keys at the time of making a connection through the "Elliptic Curve Diffie-Hellman" protocol prevents valid encrypted data from being seen by an attacker.
  • Trashcan Attacks
    Network and application keys are stored on devices semi-permanently. When a device is thrown out or sold, it is important these are removed from the network by a provisioner. The provisioner blacklists the device and negotiates new application and network keys to be distributed through a network. As it takes time for low power devices to receive the keys, this creates a period where both old and new keys are considered valid on the network, a time which Bluetooth calls "Phase 2". At the end of this phase all old keys become invalid.

Comparison with Alternative Technologies

Bluetooth Mesh targets the Smart Home lighting market with its first release. Much like it did for many services and characteristics in Bluetooth LE, the Bluetooth SIG has released specifications for exactly how a lightbulb, among other devices, should look and act on a mesh network. This ensures interoperability between devices, and also future-proofs products, as a lightbulb made 20 years from now will likely look like it currently does on the mesh.


However, the Smart Home market is already dominated by ZigBee and Z-Wave products. Wi-Fi products also exist, Google supports its own Thread protocol, and other lesser known protocols can also be found floating around. With all these options already in place it's somewhat difficult to see how the Bluetooth Mesh will fit in. Below is a brief overview of some of the benefits and down-sides of the various technologies


ZigBee


Pros:


  • Scalability. Very high number of nodes possible in a network.
  • Power. Very low power consumption.
  • Support. Well supported, and been in the market for a long time, providing simple and fast development times.


Cons:


  • Requires a network co-ordinator, creating a single point of failure (Though later versions of Zigbee (3.0+) now support a distributed network model)
  • Interoperability. Although Zigbee specifies protocols for various devices, these are not strictly followed by all manufacturers. Some devices will simply be incompatible.
  • Security. Security vulnerabilities due to standards not being strictly followed by all manufacturers. The standards themselves provide robust security measures. However. a single vulnerable device can compromise the whole system.


Z-Wave


Pros:


  • Less Interference. Operates outside of the standard 2.4GHz band which is already swamped by WiFi, Zigbee, and Bluetooth products. 
  • Interoperability. Requires developers to be part of the Z-Wave Alliance (Confidence that all devices are tested, secure, and interoperable)
  • Power. Very low power consumption. Routing tables used for efficient communication.


Cons:


  • Requires a primary controller
  • Interoperability. Not guaranteed to work across countries due to different operating frequencies and regulations in these countries.
  • Price. Tends to be more costly than alternative technology
  • Scalability. Supports 232 nodes, which is low compared to other technologies, but sufficient for most applications
  • Development costs and time. Requires developers to be part of the Z-Wave Alliance (limits time to market, requires extensive testing)
  • Data rates. Relatively slow data rates.


WiFi


Pros:


  • Data rates. High bandwidth; Can stream data at very high rates
  • Integration. Interfaceable to smart phones, tablets, pc's, etc.


Cons:


  • Power. Very power hungry, where battery operated devices would require constant replacement
  • Remotely Hackable. WiFi networks are often directly connected to the internet, creating vulnerabilities for malicious remote access.
  • Setup Complexity. Initial setup of devices is often complex, requiring custom methods to transfer WiFi passwords and network data previous to joining a network.
  • Dedicated routers. Requires dedicated routers, repeaters, and other network extenders. 


Bluetooth Mesh


Pros:


  • Scaleable. Up to 32,767 devices
  • Interoperability. Well-defined models ensure interoperability, and future-proofing
  • Existing Bluetooth hardware. Bluetooth devices are everywhere - Existing Bluetooth LE (4.x /5.0) device hardware should support some aspects of the mesh, likely only requiring a software update. This includes Smart Phones which should allow for easy mesh setup and device configuring.
  • Range. Long range between nodes (though range is dependent on hardware)
  • Data rates. Relatively high data rates. (Though not high enough to support audio streams like Bluetooth BR/EDR).


Cons:


  • Interoperability. Existing Smart Home hubs do not all currently support Bluetooth LE, reducing interoperability between devices.
  • Complexity. Fairly complex setup, requiring some understanding of node functionality and supported features
  • Unknown Risks. An emerging technology. Unknown compatibilities with existing devices, and popularity.
  • Wasted Power. A flood mesh, meaning transmissions are mostly wasted in larger networks. Relays need to be powered or require regular battery replacement.


Conclusion

The Bluetooth Mesh looks like it will be a solid contender in the IoT market. The protocol provides security and scalability for a range of home and industrial applications. However, the Smart Home market is already largely dominated by ZigBee and Z-wave devices, among other protocols. At a first glance, the complexity of the mesh topology can be off-putting for a new automation system, where a user would likely require some understanding of the various node features and requirements. Nevertheless, perhaps the main advantage for Bluetooth Mesh is that Bluetooth devices are already everywhere, and the mesh can be applied to existing hardware with software updates. Support for the mesh has already started, with modules and software updates already available from major players in the Bluetooth market. It should only be a matter of time until a software update comes along to allow your Smart Phone to implement and control some mesh related features. With all the hype it will be interesting to see how widely this new protocol will be adopted in new as well as existing products.


We'd be excited to hear how this new technology can be used in your Smart Home or other ideas. If you're interested in bringing your product idea to life, please do get in touch via our contact page or give us a call.


References


Share by: