Bluetooth Mesh is gaining a stronger position to become the go-to technology for professional lighting and other building-related control networks, with a noticeable increase in focus on commercial spaces. The potential reason for this turn of events is the Bluetooth Mesh’s decentralized mode of operation which decreases the effort of infrastructure planning and installation. In addition, no strict necessity for gateways, standardized security, scalability, reliability, and the ubiquity of Bluetooth in mobile phones play a factor.

The latest releases of Bluetooth Mesh specifications introduce features that aim to enable the expansion of Bluetooth Mesh-based systems with a new set of use cases. It also brings new, reliable, and standardized features for firmware updates and provisioning that are often a challenge for developers. These features are designed to minimize the workload of skilled technicians leading to substantial cost savings. With significant improvements in these areas, Bluetooth Mesh-based systems gain another competitive advantage in the IoT industry.

The two major features of this release are the Mesh Device Firmware Update (DFU) Model and Remote Provisioning. The Mesh DFU Model defines substantial features to standardize the update process, along with additional procedures to improve usability. Bluetooth Mesh is also enhanced with the Binary Large Object (BLOB) Transfer Model, which is used by the Mesh DFU for image distribution. The other long-awaited feature, Remote Provisioning, means a direct RF connection is no longer required to provision a device, as provisioning can now be done over the network.

This blog post will give you an introduction to these two key features, as well as the various use cases they address. We will also cover the security reinforcements and new routing capabilities added to the new release. Lastly, we will address the incorporation of standardized Bluetooth Mesh profiles for widespread applications, specifically the introduction of Bluetooth Networked Lighting Control (NLC).

Mesh DFU

The implementation of firmware updates for large networks is often challenging. Especially when maintenance workload optimization and reliability need to be top-notch. The newly introduced Bluetooth Mesh Device Firmware Upgrade Model (Bluetooth Mesh DFU) provides standard procedures for remote image distribution and for the management of the update process that meet these requirements. This standard enables developers to implement firmware upgrades that are fully remote or can be conducted by a technician locally within a simple and reliable procedure.

To understand the basic concepts of the Bluetooth Mesh DFU, let’s begin with the nodes’ roles.

• Target – a node that is being updated.
• Initiator - checks for the available firmware updates on the web and controls the update procedures. This role can be implemented by a smartphone or a gateway.
• Distributor – receives the new firmware image from the Initiator, delivers it to the Target nodes, and monitors the progress of the process.
• Standalone Updater – a node that has both the Initiator and Distributor roles.

Figure 1: Bluetooth Mesh DFU setup with a separate Initiator and Distributor

Figure 2: Bluetooth Mesh DFU setup with a gateway Standalone Updater, meaning that it has both Initiator and Distributor roles

With Bluetooth Mesh DFU, the first step for the Initiator, after checking available images on the web, is to recognize the devices in the network that need to be updated. After this stage, the image distribution begins.

The newly introduced Mesh Binary Large Object (BLOB) Transfer Model is specifically designed to send BLOBs through the mesh network effectively, and it is used in Mesh DFU for the transfer of the image from the Distributor to the Target nodes. It provides options for multicast or unicast transfer to distribute the image to multiple Target nodes efficiently. First, the Distributor splits the firmware image into suitably sized blocks. Each block contains several chunks of image data. The Distributor starts transferring these blocks, one by one, to the Target nodes listed by the Initiator. While transferring the blocks, the Distributor gathers information about possible missing chunks from the Target nodes and resends these chunks. The BLOB Transfer Model also defines the procedure for determining the percentage of image transfer completed for each Target node so that this information can be provided to the user. The verification method is vendor specific. The Distributor uses this procedure to determine whether the firmware image was verified successfully on each Target node. After the verification, depending on the selected policy, the Distributor can trigger the installation of a firmware image immediately or wait for a command from the Initiator.

The security of the entire process is assured with the encryption and authentication of messages up to the access layer. Additionally, the firmware image can be encrypted using the vendor-specific method.

Bluetooth Mesh DFU considers a few possible setups. For example, having a separate Initiator and Distributor makes it possible to implement the system in a way where the technician only has to initiate the update process on each floor and can proceed to the next floor while the software is being updated independently. It’s also possible to implement the Standalone Updater (a node that has both the Initiator and Distributor roles) in the internet gateway to enable remote updates of the Target nodes by downloading the image from a cloud.

In addition to these core features, Bluetooth Mesh DFU also addresses other corner cases, ensuring that they are handled correctly and minimizing the need for additional effort from the technicians. The specification considers situations where the Initiator is intermittently in range of the network. It provides the means to handle interrupted update procedures on the Target node and enables the system to remain functional while the update is being executed. The specification also includes a mechanism for updating Low Power Nodes. Bluetooth Mesh also provides the means to separately update the firmware subsystems (ex., application, stack) and to manage the dependencies.

Remote provisioning

While the updates conducted by the technicians are costly in the maintenance process, the provisioning process also plays a significant role in costs when it comes to installation. Up until the introduction of Bluetooth Mesh 1.1, the Provisioner had to be in range of the device being provisioned onto the network (Provisionee). The Bluetooth Mesh 1.1 specification resolves this issue by introducing Remote Provisioning.

Figure 3: Remote Provisioning

Remote Provisioning adds a possibility of relaying Provisioning PDUs through the network to a relay node that is in the RF range of the unprovisioned device. This relay node runs a Remote Provisioning Server. The Provisioner runs a Remote Provisioning Client. The relaying node can scan for devices, connect a device to the network temporarily using the data provided by the Provisioner, and relay the following Provisioning PDUs to complete the provisioning process.

This feature also covers the scenario of adding application-level features. With Bluetooth Mesh 1.1, it’s possible to add new functionalities to the devices without the need for re-provisioning after a firmware upgrade.

Improved provisioning security and Private Beacons

Provisioning is a crucial process from a security point of view as it gives the unprovisioned device access to the network. Therefore, security solutions for this procedure need to ensure protection. Bluetooth Mesh Profile 1.1 improves this aspect by introducing Enhanced Provisioning Authentication (EPA) and Certificate-Based Provisioning (CBP).

EPA provides a stronger authentication mechanism that is more robust towards Man-In-The-Middle (MITM) attacks and provides the ability to enforce authentication from the side of an unprovisioned device. This feature prevents a situation where an unprovisioned device could be provisioned by any Provisioner by choosing not to authenticate. Meaning a malicious actor could provision all the devices in a yet-to-be-commissioned building using a third-party Provisioner, causing a costly need to physically access every device to recover it from this situation. Now, unprovisioned devices supporting Bluetooth Mesh Profile 1.1 improvements can choose to require authentication and reject provisioning attempts from provisioners that do not use an authentication mechanism.

Certificate-Based Provisioning adds a standardized, optional Out-Of-Band (OOB) verification step to validate the device’s UUID and public key contained in the device certificate using Public Key Infrastructure (PKI) with X.509 certificates.

Another new feature, Private Beacons,  provides improved protection against unauthorized tracking of mesh beacon senders. This feature adds additional protection by obfuscating the beacon data and improving the beacon structure. Consider the case of a workplace with an automated lighting system based on the presence of a Bluetooth Mesh tag embedded in badges carried by the workers. It’s understandable that a person can be concerned about their privacy and may not feel comfortable carrying this badge outside of the workplace. Beacons transmitted by the tag without the Private Beacons feature contain static data that can be used for tracking. This can potentially be used by a malicious observer for unauthorized tracking. With the obfuscation and improved structure provided by Private Beacons, the risk of recognizing this beacon data and using it for tracking is mitigated.

Mesh subnet bridging and directed forwarding

Bluetooth Mesh 1.1 also aims to unlock new possibilities. Subnet bridging and directed forwarding are new features that facilitate larger and more complex mesh networks with new routing options and utilizing the network topology for access control.

Subnets can isolate device groups in the network for access control, usability reasons, and traffic management, all without sharing the primary network key. With the subnet bridging feature, users can access a subnet from other areas of the network through dedicated bridge nodes. With this high-level description, let’s try to imagine an example use case that could benefit from this new feature.

Consider a hotel environment with subnets deployed in individual rooms and public areas. Subnets can be defined to cover separate rooms. Guests who have access to their room’s subnet can control lights, heating, and similar devices in the room. Subnets can also cover public spaces like the patio, restaurant, or gym, so devices within these subnets can be controlled by the hotel staff. These subnets can also be used to provide notifications to guests. Having the topology of the subnets aligned with the physical layout of the building allows for traffic optimization and efficient utilization of the network. Access management is also simplified with the subnets in place. Access to selected features of the hotel can be controlled with the authorization system based on access to particular subnets.

Subnet bridging is the missing piece of the puzzle for the advanced use cases that utilize subnets in commercial buildings. With this feature, users can communicate with a subnet through a bridge node from other parts of the network, meaning a user doesn’t have to be in direct RF range of a subnet to interact with devices in it. The hotel guests can now control the heating in their room while eating dinner in the restaurant through the mesh network alone.

Bluetooth Mesh directed forwarding addresses a challenge that arises due to the increasing size and complexity of Bluetooth Mesh networks. Larger networks require more advanced routing mechanisms to handle the increased data traffic through the network. Bluetooth Mesh directed forwarding introduces and standardizes routing in the network. This reduces the traffic by limiting relaying that does not help in reaching the destination node while still allowing for multiple relays for redundancy. Routes are maintained with periodical route discovery to adjust to changes in the network topology, for example, if certain relays in the network fail.

Bluetooth Mesh profiles and Networked Lighting Control

Bluetooth Mesh has introduced a naming convention change, renaming “Mesh Profile” to “Mesh Protocol”. This change is intended to highlight the true nature of Bluetooth Mesh, and to align with more general Bluetooth naming conventions. From now on, the name Profile will be used for defining standardized profiles dedicated to common use cases. The Bluetooth Networked Lighting Control (NLC) profiles are the first ones to be introduced that are based on mesh topology.

NLC profiles define profiles for common use cases related to lighting systems. This standardization enables interoperability between devices from different vendors by requiring a minimum set of features and performance parameters. Each Bluetooth NLC profile has a separate specification document. The Bluetooth NLC profile specifications aren’t adopted yet, but the drafts are publicly available. The nRF Connect SDK 2.4.0 provides a demonstration of how to implement each of these profiles as part of the Bluetooth Mesh samples.

The complete list of currently specified Bluetooth NLC profiles:

• Basic lightness controller
• Energy monitor
• Basic scene selector
• Dimming control
• Ambient light sensor
• Occupancy sensor

nRF Connect SDK samples

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/protocols/bt_mesh/nlc.html#ug-bt-mesh-nlc 

Further reading

Bluetooth Specifications: https://www.bluetooth.com/specifications/specs/
The following specifications are related to this blog post:

• Mesh Protocol v1.1
• Mesh Binary Large Object Transfer Model v1.0
• Mesh Device Firmware Update Model v1.0
• Bluetooth NLC Profiles:
  • Ambient Light Sensor NLC Profile v1.0
  • Basic Lightness Controller NLC Profile v1.0
  • Basic Scene Selector NLC Profile v1.0
  • Dimming Control NLC Profile v1.0
  • Energy Monitor NLC Profile v1.0
  • Occupancy Sensor NLC Profile v1.0