Photo credit: Bluetooth.com
Bluetooth MESH is a mesh network protocol standardised by the Bluetooth SIG, the specifications of which were made public in July 2017. Since then, a majority of SoC founding designers have proposed an official implementation and a SDK. This is the case of Nordic Semiconductor, Silicon Labs and Texas Instruments.
A new network topology
Unlike the classic BLE, which imposes a star network topology, Bluetooth MESH makes it possible to create a mesh network. This means a large number of devices (up to 50) can connect and interact with one another, and the range of communication can be extended using multi-hop and broadcasting techniques such as Flooding. A very good example is the smart home.
Broadcast Protocol: Managed Flooding
The initial Bluetooth MESH specification is based on a Managed Flooding type mesh. Broadcast channels are used to transmit messages. Messages are received by other nodes and relayed. This allows the network to be extended and many nodes (about 50) to be integrated.
Mesh networks are most often of a partial type, i.e. messages are relayed from node to node until all nodes have received the original message. Mesh networks that use flooding are considered easier to implement and more resilient than routing-based mesh networks, and also offer better scalability.
Architecture of the Protocol Stack: Comparison with BLE
Compatibility with “standard” BLE
“Standard” BLE devices using GATT that are currently in use are not able to send Bluetooth MESH messages, nor are they able to interpret them.
The Bluetooth SIG has therefore provided backward compatibility by including GATT features in Bluetooth MESH nodes that allow connectivity to any device that supports GATT, as long as the device is compatible with Bluetooth 4.0 or later.
Different Types of Nodes
In addition to their ability to send and receive messages, Bluetooth MESH introduces different Features that can be cumulated on each node:
- Relay: receive and retransmit messages,
- Proxy: receive and forward MESH messages between “standard” BLE equipment (GATT) and MESH (Publish/Subscribe),
- Low Power: for equipment with limited energy resources. They can only receive and send messages to nodes with the Friend Feature,
- Friend: serves to receive and relay messages to Low Power nodes.
The topology and different node types on a Bluetooth MESH network
Network Settings: Resources
The nodes are configured with four Resources that define a Bluetooth MESH network and allow you to join it:
- Address: network addresses are required to identify message sources and destinations,
- NetKey: the network key is used to secure and authenticate messages at the network layer,
- AppKey: Application keys are used for similar purposes but at the application layer,
- IV Index: this index is the Time To Live (TTL) used to extend or limit the life of the network.
Network keys and application keys are generated using a random number generator, as defined in the Bluetooth specification. These two keys are shared across all nodes in the network (NetKey) or across nodes which participate in a given mesh application (AppKey).
Communication is only possible if it is done with the appropriate network key.
Devices in a Bluetooth MESH network can send information to multiple devices in the network. The applicable term is Publish. Devices can also be configured to track information from one or more sources or from a Group. This is called Subscribe.
The Periodic Publish feature serves to send messages periodically.
Example: a house has a kitchen with one switch and two lights. Each light must be controlled by this switch. In this case, the switch publishes its status on the “kitchen” topic and each of the lights subscribes to this topic. Each room in the house is managed in the same way. A light can also subscribe to several topics.
Looking for more information about RTone?
Devices that are not yet part of a Bluetooth MESH network are referred to as unprovisioned. These devices advertise their presence and can be added to the MESH to become network nodes through a process called Provisioning. During Provisioning, the Provisioner, which is usually a smartphone, provides the node with the NetKey, IV index and a unicast address for each node element.
The provisioning cycle of Bluetooth MESH devices
All communications in a Bluetooth MESH network are based on message transmissions.
The transport layer of the protocol manages message segmentation when the maximum payload size is reached. In addition, messages may or may not require an acknowledgement.
Format of Bluetooth MESH packets (PDU)
A multitude of IoT use cases require that the user be able to control a single node, a group of nodes or all nodes simultaneously. This feature is provided in Bluetooth MESH using Unicast, Virtual and Group addresses.
Group addresses are also used for multicast and can represent multiple elements in one or more nodes.
It is important to note that Bluetooth MESH enables flexible grouping of all types of devices.
The Bluetooth SIG has taken security concerns seriously and made security a mandatory feature of Bluetooth MESH. All traffic is encrypted and it is impossible to send unencrypted messages. The security model used in Bluetooth MESH is therefore stronger than for Bluetooth Classic or BLE.
Achieving a high level of security depends on encryption and authentication at the network and transport layers. A Message Integrity Check (MIC) is used on these two layers.
Moreover, all messages are encrypted and authenticated at the network and application level using two different keys and the AES-128-CCM algorithm.
The device key is used to authenticate and encrypt communications between the Provisioner and a node. The other nodes have no way of interpreting communications between these two devices.
The DevKey is the most critical key in the mesh network.
The flexibility of the mesh network is provided by the fact that any node can be configured to use just one or more networks simultaneously. This enables us to use one or more subnets by defining subnet NetKeys. Sub-networks are groups of nodes that can communicate with each other at the network layer.
Alternatively, a node can belong to two or more totally separate mesh networks. A good example of such a case would be a mobile phone that could be part of a home mesh network, an office Bluetooth MESH network and a vehicle Bluetooth MESH network.
The maximum number of different network keys in an installation is 4096, which allows compartments to be created within a network if necessary.
NetKey is used to derive other keys using the AES-CMAC cryptographic hash.
A mesh network can contain one or more applications, each with a unique AppKey. Nodes that are configured with an AppKey can receive and transmit messages related to that application while relaying messages from nodes in different applications. This allows applications to be compartmentalised, which increases security.
Network PDU encryption
The only unencrypted parts of the Bluetooth MESH PDU are the IV index and the network identifier (NID). The rest of the PDU is encrypted using AES-CCM. This makes it impossible to passively listen to the network structure since the header, TTL, sequence number, source, etc. are not sent without being encrypted.
Nonces are generated from sequence numbers and other network headers.
The integrity of the message is protected by a 32 or 64 bit MIC.
The message has a unique 24-bit sequence number. Protection against replay attacks is ensured by using a sequence number which the nodes keep track of according to the source address.
Conclusion and References
This article presented the specifications of Bluetooth MESH, a protocol for deploying a mesh network of connected objects with a Bluetooth Low Energy module. Bluetooth MESH allows you to interconnect a large number of devices and extend the network range. It provides default security that includes key distribution, encryption and equipment authentication.
Many use cases can be considered, especially for smart home (home automation), industry 4.0 or Smart City applications
- “Bluetooth® mesh networking, An Introduction for Developers”, Martin Woolley, Sarah Schmidt, Bluetooth SIG.
- “Mesh Model Specification 1.0”, 2017, Bluetooth SIG.
- “Mesh Peripheral Properties 1.0”, 2017, Bluetooth SIG.
- Adomnicai et al. (2018). Hardware Security Threats Against Bluetooth Mesh Networks, 2018 IEEE Conference on Communications and Network Security.
- Baert, J. Rossey, A. Shahid, and J. Hoebeke, “The Bluetooth Mesh Standard: An Overview and Experimental Evaluation,” Sensors, vol. 18, No. 8, p. 2409, Jul. 2018.
- Murillo, B. Reynders, A. Chiumento, and S. Pollin, “A Multiprotocol Low-Cost Automated Testbed for BLE Mesh,” IEEE Common. Mag., vol. 57, No. 3, pp. 76-83, Mar. 2019.