Release :	1.0.0
Document Version :	1.0
Last updated :	September 19, 2023
Authors :	Martin Woolley, Bluetooth SIG Szymon Slupik, SILVAIR Inc. Omkar Kulkarni, Nordic Semiconductor Hannu Mallet, Silicon Labs Damon Barnes, Bluetooth SIG

Revision History

Version	Date	Author	Changes
1.0.0	September 19, 2023	Martin Woolley, Bluetooth SIG Szymon Slupik, SILVAIR Inc. Omkar Kulkarni, Nordic Semiconductor Hannu Mallet, Silicon Labs Damon Barnes, Bluetooth SIG	Initial version

Note

The Bluetooth Mesh Profile Specification has been renamed and is now called the Bluetooth Mesh Protocol Specification. References in this and related papers will use this name when referring to the version 1.1 specification but continue to refer to the version 1.0 specification as the Bluetooth Mesh Profile Specification.

1. Introduction

The Bluetooth Special Interest Group (SIG) announced feature enhancements to Bluetooth^® Mesh technology on September 19, 2023. The press release announces a collection of new major features, minor enhancements, and all-new mesh device profiles. This paper summarizes each area of change and provides references to other papers which examine the new major features in more detail. The minor mesh enhancements are reviewed in this paper. In section 3, the all-new Bluetooth^® Mesh Device Profiles are introduced. A reference material list for all content assets and specification documents is provided in section 4.

Readers who are new to Bluetooth Mesh are advised to first read the Bluetooth SIG paper Bluetooth Mesh Networking – An Introduction for Developers.

Note that occasionally, the terms Mesh 1.1 or Bluetooth Mesh 1.1 will be used as an abbreviation for Bluetooth Mesh Protocol or Model Specification Version 1.1 and similarly, the terms Mesh 1.0 or Bluetooth Mesh 1.0 will be used as an abbreviation for Bluetooth Mesh Profile Specification Version 1.0.

2. New Bluetooth^® Mesh Features

2.1 Bluetooth Mesh Directed Forwarding

A message relaying method known as Bluetooth Mesh Managed Flooding was defined in version 1.0 of the Bluetooth Mesh profile. It provides an effective, reliable, flexible, and low-maintenance way of delivering messages over multiple hops to their destination in a Bluetooth Mesh network. The new Bluetooth Mesh Directed Forwarding feature provides an additional multi-hop message delivery method, which in some situations is more efficient than Bluetooth Mesh Managed Flooding.

Bluetooth Mesh Directed Forwarding establishes collections of relay nodes which can service the targeted delivery of messages from a source address to a destination address. These sets of relay nodes establish a path from a source to a destination. Membership of a path is arranged such that messages are only ever relayed by nodes that can propagate a message towards the intended destination. This can result in a more efficient utilization of the network and radio channels.

Automation is a key feature of Bluetooth Mesh Directed Forwarding. Paths are created automatically when they are needed, and they are automatically checked at intervals to ensure that they are still needed in the network and are still able to deliver messages as required. The latter point is an important capability when we consider that networks and their devices may change over time.

See the Bluetooth Mesh Directed Forwarding Technical Overview paper for more information on this subject.

2.2 Bluetooth Mesh Device Firmware Update

Bluetooth^® Mesh devices run firmware, the software which controls the hardware and implements the product’s primary behaviors. Firmware must be kept up to date, and the new Bluetooth Mesh Device Firmware Update feature of Bluetooth Mesh makes it possible to discover and apply firmware updates to devices across the network.

A firmware update requires transferring of large amount of firmware data to all nodes in the network. Therefore, the Bluetooth Mesh Device Firmware Update feature provides several parameters to control the cadence and size of individual mesh messages carrying firmware data to allow background transfer of firmware without affecting the other activities on the mesh network.

The Bluetooth Mesh Device Firmware Update enables multicast updates, which is ideal for installations such as lighting networks consisting of many identical devices. Once the firmware is transferred to target nodes, the update can be applied on all nodes at a planned time, for instance, outside office hours, to minimize disruptions.

The Bluetooth Mesh Device Firmware Update feature is designed in a way that allows updating of a multi-vendor mesh network with ease.

See the Bluetooth Mesh Device Firmware Update Technical Overview paper for more information on this subject.

2.3 Bluetooth Mesh Remote Provisioning

Provisioning is the name of the process used to add a device to a mesh network. It is carried out using a Provisioner. Previously the Provisioner needed to be in direct radio range of the new device and to communicate with it over a Bluetooth link. This would be a problem for fixed location devices and would require the users of mobile Provisioners to physically walk towards the devices to provision them and cover the area of installation. The new Bluetooth Mesh Remote Provisioning feature adds the ability for provisioning to be carried out over the mesh network, with provisioning messages taking one or more hops to reach the remote, Unprovisioned Device.

After provisioning a new device, it is configured. Some devices are complex and have correspondingly complex configuration requirements, and devices may need to be fully or partially reconfigured after a firmware update that adds new features. Bluetooth Mesh Remote Provisioning also includes procedures which provide a plug-and-play device composition update capability for complex devices.

The Bluetooth Mesh Remote Provisioning feature also provides procedures to automate the handling of important events in the lifecycle of a Bluetooth Mesh network, such as the secure transfer of ownership after the network has been initially created by allowing device keys of all devices to be regenerated.

See the Bluetooth Mesh Remote Provisioning Technical Overview paper for more information on this subject.

2.4 Bluetooth Mesh Certificate-based Provisioning

Devices being provisioned to the mesh network are identified by UUIDs. To prevent impersonation of a legitimate device, when onboarding a device in a network using public key obtained out of band, it is necessary to ascertain that given public key really belongs to a device with a specific UUID.

The new Bluetooth Mesh Certificate-based Provisioning feature makes use of Public Key Infrastructure to authenticate Unprovisioned Device’s public key and UUID information. The X.509 format digital certificates may be provided by device manufacturers or vendors and used in the provisioning process. This feature improves Bluetooth Mesh provisioning in the following ways: Allows devices’ out-of-band (OOB) public key to be obtained and authenticated in interoperable manner (while devices remain out of sight), increases security through a superior authentication scheme, and lends itself to the bulk provisioning of many devices at the same time.

See the Bluetooth Mesh Certificate-based Provisioning Technical Overview paper for more information on this subject.

2.5 Private Beacons

Bluetooth^® Mesh uses the technique of beaconing in a number of procedures and defines a network beacon message. The new Private Beacons feature improves security by ensuring that no static information in beacon messages is visible to devices outside of the network. This improves privacy in cases such as those that involve wearable devices which may move in and out of the network and which might otherwise have been trackable by observing plain text data in mesh network beacons.

See the Bluetooth Mesh Private Beacons Technical Overview paper for more information on this subject.

2.6 Bluetooth Mesh Subnet Bridging

A Bluetooth^® Mesh network can include one or more subnets. Subnets are often used to securely isolate parts of a network from each other using different network security keys for different parts of the network.

Previously, there was no way for devices in different subnets to communicate unless they were also members of a common subnet and used that subnet’s when exchanging messages. The new Bluetooth Mesh Subnet Bridging feature makes communication between devices in different subnets possible without prior knowledge of a common subnet and its NetKey with the help of an intermediate bridge node implementing this feature. In addition, separate parts of the same subnet can be bridged to support use cases such as a hotel guest sitting in the lobby of the hotel but still being able to control smart devices in their room, all of which are in their own subnet.

See the Bluetooth Mesh Subnet Bridging Technical Overview paper for more information on this subject.

2.7 Minor Mesh Enhancements

A number of smaller features, collectively referred to here as minor mesh enhancements, are also added to Bluetooth^® Mesh technology. It should be noted that whilst the changes covered under this heading may be minor, in some cases the benefits are substantial. The following sections provide a summary overview for each enhancement and concludes with informational updates to Bluetooth Mesh.

2.7.1 On-Demand Private GATT Proxy

2.7.1.1 Background

Proxy nodes support both Bluetooth^® LE (with GAP and GATT) and Bluetooth Mesh. The proxy acts as an intermediary and makes it possible for applications on devices, such as smartphones, to send and receive mesh messages to and from the network over a GATT connection to the proxy.

When configuring Bluetooth Mesh 1.0 proxy nodes, the only option the commissioner has is to enable or disable proxy advertisements. From a user experience perspective, enabling proxy on all nodes is preferred but that has an impact on the available bandwidth and consequently may negatively impact performance of the mesh network.

2.7.1.2 On-Demand Private GATT Proxy Enhancement

Proxy clients (such as smartphones) can now signal to a proxy node that it should start advertising. This is accomplished by the proxy client broadcasting non-connectable non-scannable undirected advertising Solicitation PDUs.

A proxy node is no longer required to continuously advertise per Bluetooth Mesh 1.0 behavior. Instead, it performs passive scanning and on receiving a Solicitation PDU from a proxy client which contains network identity data matching the network of the proxy node, it commences advertising using the Private Network Identity type. The proxy client may then connect to the proxy.

The On-Demand Private GATT Proxy feature makes RF utilization more efficient and, thus, enhances scalability. The absence of unsolicited GATT Proxy service advertisements, and the fact that sending a valid solicitation request requires the knowledge of a NetKey, also makes it more difficult for an attacker to identify proxy nodes in the network.

2.7.2 Performance Improvements

2.7.2.1 Segmentation and Reassembly (SAR) Enhancements

2.7.2.1.1 Background

The upper transport layer of the Bluetooth^® Mesh stack can perform segmentation and reassembly of mesh Access messages which are too long to be sent in a single transmission. Such messages are split into segments, each 12 octets long, except for the final segment, which may be shorter. On receiving the individual segments, a reassembly process results in the original Access message being reconstituted.

This can cause inefficient mesh message transfers within a mesh network when devices from different vendors happen to use different default values for SAR behaviors.

2.7.2.1.2 SAR Configuration Models

Parameters which govern the primary aspects of the segmentation and reassembly (SAR) process may now be configured within the new SAR Configuration Server model using the new SAR Configuration Client model. This model contains two composite states, SAR Transmitter and SAR Receiver.

The SAR Transmitter state contains parameters to be used when acting as the transmitter of a segmented message. It also includes the timing interval to be used between segment transmissions and parameters relating to the retransmission of segments to unicast addresses and multicast addresses.

The SAR Configuration Server model helps improve the performance of some configuration tasks, especially in networks containing devices from multiple manufacturers.

2.7.2.2 Message Aggregation

2.7.2.2.1 Background

There are situations where a series of different types of acknowledged Access messages are sent in a certain sequence. Each Access message results in a status message which acts as a response and typically contains a status code. For example, during the configuration of a new node, the act of binding AppKeys to models will involve a number of acknowledged messages and their associated status response messages.

2.7.2.2.2 Opcode Aggregator Models

New models called the Opcodes Aggregator Server model and Opcodes Aggregator Client model, and an associated procedure called the Message Request List Processing procedure, have been introduced. The procedure allows a sequence of different Access messages to be collapsed into a single Access message of a type called the OPCODES_AGGREGATOR_SEQUENCE message. This message type contains an array of Access message opcodes and associated parameter values. All message opcodes in the array must identify message types that are handled by the same server model. This is a security feature and requires that the AppKey with which the OPCODES_AGGREGATOR_SEQUENCE access layer fields are encrypted is one which the server model is bound to.

The Message Request List Processing procedure results in each of the actions indicated by the contained access codes and parameters being carried out and a single OPCODES_AGGREGATOR_STATUS message being returned in response.

Message opcode aggregation compresses the amount of data and time involved in what would otherwise have been a series of Access messages and responses and reduces that series of exchanges to a single request and response.

2.7.3 Complex Devices

2.7.3.1 Models Metadata

2.7.3.1.1 Background

Bluetooth^® Mesh 1.0 defines the configuration server model. This is a model implemented by all devices and contains configuration and Composition Data in a number of states.

The Composition Data state is structured as a series of pages, each of which is readable using a configuration server model request and the corresponding response. Specific pages are referenced by page number. Amongst other things, the Composition Data page 0 state defines the elements that the node is composed of, and each element definition indicates the models that the element supports.

Some devices require extensive and variable data to describe their composition, configuration data, and other attributes. DALI (Digital Addressable Lighting Interface) devices, for example, are built around a communication bus, into which up to 128 components may be plugged or unplugged easily. When part of a mesh network, a DALI component becomes an element in a complex mesh node which represents the DALI device as a whole. A DALI node has a large and complex composition, and its metadata requirements vary according to the specific types of components that are connected to the DALI message bus.

The composition and metadata relating to large, complex devices like this cannot always be accommodated using the messages defined by the configuration server model, since pages may be too large to fit in single Access message responses.

2.7.3.1.2 Models Metadata

Bluetooth^® Mesh now includes the concept of model metadata. Model metadata is a series of one or more properties that describe a model or the element that a model is a part of in some way. Metadata items have a 16-bit identifier which are Bluetooth SIG assigned numbers.

A new set of models, the Large Composition Data Server model and the Large Composition Data Client model, has been added to Bluetooth Mesh. The server model includes a state called the Models Metadata state, which is structured as a series of pages, starting with Models Metadata Page 0. The Large Composition Data Server model extends the Configuration Server model and defines a series of Access messages, all of which are secured with a DevKey.

Some mesh models in Bluetooth Mesh Model Specification v1.1 have been enhanced to enable the indication of one or more metadata types that they support. A client implementation may then retrieve metadata values from the Large Composition Data Server model’s Models Metadata Page 0 state. For example, the Light Lightness Server model supports the Light_Purpose metadata type. Light_Purpose metadata contains a 16-bit assigned number which indicates the purpose of the light (e.g., uplight, downlight, or nightlight).

2.7.3.1.3 Large Composition Data Values

The Composition Data state in the Configuration Server model continues to be the state which contains Composition Data for a node, indicating the elements it contains and their models. But the new Large Composition Data Server model defines messages which allow this data to be accessed as a series of portions of data using an offset parameter. This allows the large Composition Data required for complex devices such as DALI devices to be accommodated.

2.7.4 Authentication Algorithms and Provisioning

2.7.4.1 Background

When provisioning a device onto a network, the Unprovisioned Device sends Provisioning Capabilities PDUs that include an Algorithms field to the provisioner. The field indicates the algorithms that a device is capable of using to calculate confirmation values during the authentication step of the provisioning process.

Previously only one algorithm was supported. Referred to with the short name FIPS P-256 Elliptic Curve, this algorithm made use of the AES-CMAC function, as defined in RFC 4493. The FIPS P-256 Elliptic Curve algorithm generates a 128-bit confirmation value.

Additionally, older mesh devices may be provisioned without using any authentication. This creates a maintenance risk whereby a local rouge provisioner could provision all lights mounted on a high ceiling before the official provisioner arrives to commission the network, for example. If this happens, the high ceiling lights might require manual intervention to reset them to Unprovisioned state.

2.7.4.2 New Authentication Algorithm and Provisioning Improvement

Bluetooth^® Mesh Protocol Specification Version 1.1 renames the algorithm that uses AES-CMAC to BTM_ECDH_P256_CMAC_AES128_AES_CCM and introduces a new algorithm which has the name BTM_ECDH_P256_HMAC_SHA256_AES_CCM. The new algorithm uses the HMAC-SHA-256 function and generates 256-bit confirmation values.

Bluetooth Mesh compliant devices must support the new BTM_ECDH_P256_HMAC_SHA256_AES_CCM algorithm and, where the OOB Type field indicates that “Only OOB authenticated provisioning supported” by setting bit 1, this algorithm must be used. The older AES-CMAC based algorithm continues to be supported when used by older devices.

The Bluetooth^® Mesh Protocol allows Unprovisioned Devices to mandate authentication during provisioning and reject provisioning attempts without authentication. A device indicates such requirement of authentication by setting Bit 1 of OOB Type field in the Provisioning Capabilities PDU.

2.7.5 Health Fault Codes

2.7.5.1 Background

The health client and server models are concerned with fault reporting and diagnostics. The primary element of all nodes in a Bluetooth^® Mesh network must include the health server model. Other elements may inform the health server model of faults. A series of fault-related states, such as Current Fault, are defined for the health server model. Faults are represented by single octet codes. Some values in the available range are reserved for Bluetooth SIG use and others are for vendor-specific codes.

2.7.5.2 Health Fault Codes Moved to Assigned Numbers

The Bluetooth SIG defined fault codes that are used by the health server model have been designated assigned numbers in this release. This is a procedural change and makes it easier and quicker for the Bluetooth SIG to respond to members requesting new standard fault codes for use in their products.

2.7.6 Assigned Numbers

The Bluetooth SIG maintains a database of standard identifying numbers which are known as assigned numbers. The full list of Bluetooth SIG assigned Numbers.

Requesting an addition to one of the assigned number lists is a simple procedure that is available to all Bluetooth SIG members.

2.7.7. Terminology Changes

2.7.7.1 Provisionee

A device or application with which an Unprovisioned Device becomes provisioned is known as the Provisioner. To further formalize the language used when describing the act of provisioning, Bluetooth Mesh 1.1 now uses the term Provisionee to refer to the Unprovisioned Device whilst it is being provisioned through an exchange of provisioning protocol PDUs.

2.7.7.2 Terms

Mesh Protocol Specification 1.1 introduces a new formal name for the lifecycle of a device, its structure, and configuration. The concept of a Term is described in the specification as follows:

A term is a period in the lifetime of a node during which the structure of the node (i.e., the features, the elements, and models) and the unicast addresses of the node’s elements do not change.

Starting a new term may be necessary to support a change in the hardware configuration of a physical device, such as the attachment of an auxiliary sensor, or to support a change in subsystem configuration on the node, such as the attachment of a new gear to an intra-luminaire network. The changes are indicated by the node by populating Composition Data Page 128 (see Mesh Protocol Specification 1.1, Section 4.2.2.4) and take effect when a new term starts.

The initial term of a node on a network starts when the node is provisioned on the network.

A term ends and a new term starts when a Node Address Refresh procedure or a Node Composition Refresh procedure is executed (see Mesh Protocol Specification 1.1, Section 3.11.8).

The last term of a node on a network ends when the node is removed from the network.

2.7.7.3 The Model Layer

Section 3 of the Bluetooth Mesh 1.1 Protocol Specification has been expanded to include section 3.8 which defines the Model Layer and rules and recommendations for the use of models.

2.7.7.4 The IV Index Recovery Procedure and Subnets

The wording describing the IV Index Recovery procedure has been improved to explicitly cover subnets.

3. Bluetooth^® Mesh Device Profiles

Bluetooth^® Mesh technology provides a rich set of features and options to implement many lighting and sensing applications. This has helped Bluetooth Mesh establish itself as the preferred technology for scalable commercial and industrial applications. However, the optional nature of Bluetooth Mesh features can cause challenges for implementers when they must decide which options to choose for their chosen product segments. If vendors operating in the same product segments choose a different set of options that do not work well with other peer products (e.g., mesh features chosen for light bulbs are not compatible with features selected for light switches), a situation can arise where product ecosystems do not interoperate, which degrades the user experience.

To address this issue, the Bluetooth SIG has come with the concept of Bluetooth Mesh Device Profiles. These profiles are new class of mesh specifications. Device Profiles define which options and features of the mesh specifications are mandatory for a certain kind of end product. The first suite of mesh device profiles is based on the lighting system architecture described in Building a Sensor-Driven Lighting Control System Based on Bluetooth Mesh whitepaper published in 2020. Collectively these profiles are called as Bluetooth Networked Lighting Control (NLC) Profiles, and they are defined as follows:

Ambient Light Sensor NLC Profile (ALS) 1.0 – represents an ambient light level sensor.
Basic Lightness Controller NLC Profile (BLC) 1.0 – represents a luminaire with an integrated controller.
Basic Scene Selector NLC Profile (BSS) 1.0 – represents a wall switch or a wall station to select lighting scenes or turn the lights on/off.
Dimming Control NLC Profile (DIC) 1.0 – represents a wall slider, a dial, or a long-press switch function to dim lights up/down.
Energy Monitor NLC Profile (ENM) 1.0 – represents a sensor reporting energy consumption.
Occupancy Sensor NLC Profile (OCS) 1.0 – represents an occupancy sensor.

See the Bluetooth Networked Lighting Control (NLC) webpage for more information on this topic.

4. Conclusion

The feature enhancements described in this paper deliver immense value and are the result of experience gained with Bluetooth^® Mesh technology in a wide range of real-world deployments.

Bluetooth Mesh was released six years ago, and since then, numerous projects have been completed, making buildings all over the world smarter and more energy efficient. Developers, manufacturers, integrators, installers, maintenance teams, and building operators have gained valuable experience and have all contributed to the improvements made to Bluetooth Mesh technology.

The Bluetooth Mesh feature enhancements described in this paper achieve something unusual. Together, the new features deliver high security with ease of use and low cost of ownership. The business and technical case for deploying Bluetooth Mesh has never been stronger.

Bluetooth® Mesh Feature Enhancements Summary