The market position of Bluetooth mesh is rapidly expanding, making it the preferred technology for various control networks in the professional lighting and construction fields. It is gaining increasing attention in the commercial space, possibly due to the decentralized operation mode of Bluetooth mesh, which simplifies infrastructure planning and installation work. Additionally, this technology offers several advantages, including the absence of the need for gateways, standardized security, scalability, reliability, and the ubiquity of Bluetooth in mobile phones.
Bluetooth Mesh 1.1 introduces multiple features aimed at expanding the use cases for Bluetooth mesh-based systems. It also brings new, reliable, and standardized features for firmware updates and configuration, which can often be challenging for developers. These improvements are designed to significantly reduce the workload of skilled technicians, leading to substantial cost savings. These significant enhancements give Bluetooth mesh-based systems a competitive edge in the Internet of Things (IoT) industry.
Two major features of Bluetooth 1.1 are the Mesh Device Firmware Update (DFU) model and remote configuration. The Mesh DFU model defines the foundational characteristics of the standardized update process and provides additional methods to enhance usability. Bluetooth Mesh 1.1 also introduces the Binary Large Object (BLOB) transfer model, which Mesh DFU uses for image distribution. Another long-awaited feature is remote configuration, which means that configuration can now be done over the network without the need for a direct radio frequency connection.
This article will introduce these two key features and the various use cases they address. We will also discuss the security enhancements and brand-new routing capabilities added in the new version specification. Finally, we will explore how to integrate standardized Bluetooth mesh configuration profiles for widespread adoption, especially with the introduction of Networked Lighting Control (NLC) systems in Bluetooth networked lighting control.
Mesh DFU
Firmware updates for large-scale networks often present challenges, particularly when maintaining workload optimization and achieving top-notch reliability is required. The newly introduced Bluetooth mesh Device Firmware Update model (Bluetooth mesh DFU) provides standardized steps for remote image distribution and managing the update process to meet these requirements. This standard enables developers to achieve fully remote firmware updates or conduct local upgrades by technical personnel using simple and reliable steps.
Let’s start by introducing the basic concepts of Bluetooth mesh DFU from the perspective of nodes:
- Target: The node that is undergoing an update.
- Launcher: Responsible for checking available firmware updates on the network and controlling the update process. This role can be fulfilled by a smartphone or a gateway.
- Distributor: Receives the new firmware image from the launcher, delivers it to the target node, and monitors the progress of the transmission.
- Standalone Updater: A node that combines the roles of both launcher and distributor.
When updating Bluetooth mesh devices, the launcher, after checking available images on the network, first identifies the devices that need updates within the network and then begins distributing the image. The newly introduced Mesh Binary Large Object (BLOB) transfer model is specifically designed for efficiently sending BLOBs through the mesh network and is used in Mesh DFU to transfer images from the distributor to the target node. This transfer model offers multicast or unicast transmission options for efficiently distributing images to multiple target nodes. The distributor initially segments the firmware image into appropriately sized chunks, each containing multiple image data blocks. Then, the distributor starts transmitting these data blocks one by one to the target nodes listed by the launcher.
During the transmission of data blocks, the distributor collects information from target nodes regarding potentially missing data blocks and retransmits those blocks. The BLOB transfer model also defines steps to determine the percentage of image transfer completion for each target node, providing this information to the user, with verification methods specified by the vendor. The distributor uses this process to determine whether each target node has successfully verified the firmware image. After verification, depending on the selected strategy, the distributor can either trigger the installation of the firmware image immediately or wait for commands from the launcher.
Encrypting and verifying information down to the access layer ensures the security of the entire update process. Additionally, firmware images can be encrypted using vendor-specific methods.
Bluetooth mesh DFU accommodates several possible configurations. For example, using separate launchers and distributors to implement the system allows technicians to initiate the update process on each floor, allowing software to update itself as it progresses to the next floor. It is also possible to implement standalone updaters in Internet gateways (nodes that simultaneously have launcher and distributor roles) to perform remote updates for target nodes by downloading images from the cloud.
In addition to these core features, Bluetooth mesh DFU can be utilized for other use cases, ensuring that these processes are handled correctly and minimizing additional work for technicians. This specification considers scenarios where launchers may intermittently be within network range. It provides methods for handling interruptions in the update process on target nodes and keeps the system running smoothly during updates. The specification also includes mechanisms for updating low-power nodes. Bluetooth mesh also offers a separate firmware subsystem update (e.g., application, stack) and methods for managing dependencies.
Remote Configuration
While the cost of updates by technicians during maintenance can be high, the configuration process during installation also impacts costs. Prior to the introduction of Bluetooth Mesh 1.1, configuration parties had to be within the range of the devices (provisioning objects) to be provisioned onto the network. Bluetooth Mesh 1.1 specification addresses this issue by introducing remote configuration.
Figure 3: Remote Configuration
Remote configuration introduces a method where configuration Protocol Data Units (PDUs) are relayed over the network to relay nodes within radio range of unconfigured devices. This relay node operates a remote configuration server, while the configuring party runs a remote configuration client. The relay node can scan devices, temporarily connect them to the network using data provided by the configuring party, and relay the transmission of subsequent configuration PDUs to complete the configuration and debugging process.
This feature also covers scenarios involving the addition of application-layer functionality. With Bluetooth Mesh 1.1, new functionality can be added to devices without the need for reconfiguration after a firmware update.
Improved Configuration Security and Private Beacons
From a security perspective, configuration is a critical process because it allows unconfigured devices to access the network. Therefore, secure solutions for this process are essential to ensure safety and reliability. Bluetooth Mesh 1.1 introduces Enhanced Provisioning Authentication (EPA) and Certificate-Based Provisioning (CBP) to address these concerns.
EPA can provide stronger authentication mechanisms, better resistance to Man-in-the-Middle (MITM) attacks, and the capability to enforce authentication from the side of the unconfigured device. This feature prevents any configuring party from performing non-authenticated device provisioning, making it impossible for malicious actors to configure all devices in an undebugged building using third-party provisioning tools without physical access to each device. Now, unprovisioned devices supporting Bluetooth Mesh 1.1 improved features can choose to require authentication and reject configuration attempts from configuring parties that do not use authentication mechanisms.
Certificate-Based Provisioning adds standardized optional out-of-band (OOB) verification steps to validate device UUIDs and public keys included in device certificates using Public Key Infrastructure (PKI) with X.509 certificates.
Another new feature, Private Beacons, provides better protection against unauthorized tracking of mesh beacon senders. This feature enhances protection by obfuscating beacon data and improving beacon structure. For example, in a workplace scenario where the operation of an automatic lighting system is based on Bluetooth Mesh tags embedded in badges worn by workers, workers might be concerned about their privacy or unwilling to carry the badge outside the workplace. Without Private Beacon protection, the beacon transmitted by the tag may contain static data that could be used for unauthorized tracking by malicious observers. With the obfuscation and structural improvements of Private Beacons, the risk of beacon data being identified and tracked is reduced.
Mesh Subnet Bridging and Directed Forwarding
Bluetooth Mesh Network 1.1 is designed to unleash new possibilities. Subnet bridging and directed forwarding are both new features that utilize new routing selections and leverage network topology for access control, enabling the implementation of larger and more complex mesh networks.
Subnets can isolate device groups within the network without needing to share the main network key, facilitating access control, differentiation of availability, and traffic management. With the subnet bridging feature, users can access subnets from other areas of the network via dedicated bridging nodes. Let’s consider some use cases that could benefit from this new feature based on these descriptions.
For instance, in a hotel environment, individual rooms and public areas are equipped with subnets. Subnets can be defined to cover individual rooms. Guests accessing their room’s subnet can control lighting, heating, and similar devices within their room. Subnets can also cover public spaces like courtyards, restaurants, or gyms, allowing hotel staff to control devices within these subnet ranges. These subnets can also be used to provide notifications to guests. Aligning the subnet topology with the physical layout of the building allows for traffic optimization and efficient use of the network. By establishing subnets, access management can be simplified. To access specific features of the hotel, authorization can be granted through specific subnets for system control.
In advanced use cases involving subnets in commercial buildings, subnet bridging is a crucial component. With this feature, users can communicate with subnets from other parts of the network through bridging nodes, meaning users do not have to be within the direct radio range of the subnet to interact with devices within it. Now, hotel guests can control the heating in their rooms via the mesh network while having dinner in the restaurant.
Bluetooth Mesh Network Directed Forwarding addresses the challenges arising from the increasing scale and complexity of Bluetooth mesh networks. Larger networks require more advanced routing mechanisms to handle increased network data traffic. Bluetooth Mesh Directed Forwarding introduces routing into the network and standardizes it, reducing traffic by limiting relay operations that are not helpful to the destination node while still allowing multiple relay operations for redundancy. Regular route discovery is maintained to adapt to changes in network topology, such as the failure of some relay operations in the network.
Bluetooth Mesh Configuration Files and Networked Lighting Control Systems
Bluetooth Mesh 1.1 has renamed the “Mesh Profile” to the “Mesh Protocol.” This change is aimed at highlighting the true nature of Bluetooth Mesh and aligning with the broader Bluetooth naming conventions. Going forward, “Profiles” will be used to define standardized configuration files for common use cases. The Networked Lighting Control (NLC) profile is the first introduced profile based on the mesh topology.
The NLC profile defines configuration files for common use cases related to lighting systems. This standardization requires configuring a minimal feature set and performance parameters between devices, ensuring interoperability between devices from different vendors. Each Bluetooth NLC configuration file has a separate specification document. The Bluetooth NLC configuration file specification has not been adopted yet but the draft content is publicly available. nRF Connect SDK 2.4.0 demonstrates how to implement these configuration files.
The currently defined list of Bluetooth NLC configuration files includes:
- Basic Brightness Controller
- Energy Monitor
- Basic Scene Selector
- Dimming Control
- Ambient Light Sensor
- Occupancy Sensor
Nordic provides a variety of SoC combinations that support Bluetooth Mesh. These SoCs come with different memory sizes and features, allowing developers to make the most suitable choice for their product requirements.
The nRF5340 SoC is Nordic’s flagship product for Bluetooth Mesh. It is the first SoC in the nRF53 series and the world’s first wireless connectivity SoC with two ARM Cortex-M33 processors. With its two flexible processors, operating temperature up to 105°C, and advanced security features, it is an ideal choice for Bluetooth Mesh applications such as professional lighting, sensor networks, and asset tracking.
The nRF5340 is a full-featured SoC that combines Bluetooth 5.2, high-speed SPI, QSPI, USB, and more, along with higher performance, memory, and integration while minimizing static current consumption. It also offers various security features like Trusted Execution, Trust Anchor, and secure key storage. Additionally, out of the seven SoCs in the nRF52 series, four support Bluetooth Mesh.
All Nordic SoCs can simultaneously run Low Energy Bluetooth (BLE) and Bluetooth Mesh. They share radio resources through time division and autonomous time scheduling, ensuring devices remain interconnected. With the interoperability of Nordic’s Low Energy Bluetooth stack, developers can bridge Low Energy Bluetooth devices (such as smartphones) to the Bluetooth Mesh network. Smartphones can then be used to configure/debug new nodes and interact with the mesh network.
Source: https://www.slw-ele.com/bluetooth-mesh-1-1-new-features.html