Bluetooth^® Mesh Device Firmware Update

Technical Overview

Release :	1.0.0
Document Version :	1.0
Last updated :	September 19, 2023
Authors :	Martin Woolley, Bluetooth SIG Hannu Mallat, Silicon Laboratories Omkar Kulkarni, Nordic Semiconductor

Revision History

Version	Date	Author	Changes
1.0.0	September 19, 2023	Martin Woolley, Bluetooth SIG Hannu Mallat, Silicon Laboratories Omkar Kulkarni, Nordic Semiconductor	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. Background

Bluetooth^® Mesh 1.1 introduced a new set of capabilities which allow the firmware running on devices to be updated across the network. Relevant background is presented before reviewing capabilities, benefits, and technical highlights of this feature.

1.1 Firmware and Bluetooth Mesh Devices

The low-level software which controls a device’s hardware is usually called firmware. Bluetooth Mesh devices run firmware which implements the Bluetooth Mesh protocols and the underlying layers of a Bluetooth LE host and controller. The mesh models which a device uses are themselves implemented in firmware, as are any other device-specific behaviors and capabilities that fall outside of the Bluetooth specifications. The firmware on a device plays a critical role in making the device what it is.

1.2 Keeping Firmware Up to Date

Firmware needs to be kept up to date and manufacturers will often release firmware updates. New firmware might fix issues, add new features, improve security, provide better performance, or offer some other benefit. Keeping software up to date, whether that software is device firmware, application software, or an operating system update, is generally accepted to be good practice.

How you update software depends on the type of software and the platform that it is for. Automated software updates that require little or no involvement from the user are the norm for modern smartphone and desktop operating systems.

Bluetooth^® Mesh 1.0 offers no automatic or standardized mechanism for detecting that new firmware is available for a device, for acquiring it or for installing it. These tasks must be carried out manually and the installation of firmware updates done direct to the device using whatever proprietary interface is provided for this purpose. In a mesh network consisting of multiple vendors’ devices the process may involve multiple proprietary tools and become very convoluted.

1.3 Binary Images

Firmware updates are usually packed in a single, binary file known as an image. The format of image files varies and depends on the target platform and its manufacturer. Unpacking, verifying, and installing firmware requires a proprietary, manufacturer-specific procedure.

1.4 Firmware Updates and Security

Installing new firmware carries with it certain security risks. How do you know that the software being installed is from the manufacturer, as claimed? How do you know it has not been tampered with, perhaps incorporating malicious code?

Such matters fall outside the Bluetooth^® specifications. In general, though, to ensure that firmware images have not been tampered with, it is recommended that only file(s) that have been digitally signed by the originator are used. Digital signatures prevent files from being tampered with without detection and verify the originator of the file. Similarly, establishing a server from which a firmware update might be downloaded, as a trusted source, is usually achieved through the use of digital certificates.

1.5 Models

Models are the building blocks of application layer Bluetooth^® Mesh device behaviors. A model is a software component that implements a specific set of behaviors and has associated with it a defined set of messages and states. There are client models, which send and receive messages only, and there are server models, which send and receive messages and which contain state values which are acted upon by the model’s messages.

2. About Device Firmware Update

2.1 Capabilities and Benefits

2.1.1 Device Firmware Update

The new Device Firmware Update (DFU) feature of Bluetooth^® Mesh adds a standard way for nodes in the network to have their firmware kept up to date. Its functionality includes monitoring for the availability of new firmware updates, acquiring the binary images, distributing within the network, and the updating of selected nodes.

A typical network will usually contain many products of the same type from the same manufacturer. The DFU feature provides a multicast firmware distribution capability, which leverages the broadcast communication used in Bluetooth Mesh so that a single firmware update image can be distributed to multiple devices in one go, using a minimum number of radio transmissions.

DFU substantially reduces the manual effort required by the building maintenance team to keep firmware running in the network’s devices up to date.

2.1.2 Plug and Play

The DFU feature allows updating of devices that are composed of many subsystems, each with its own firmware. Each such firmware instance is listed in the Firmware Information List of the device.

The Firmware Information List is dynamic, meaning that when plug-and-play components are added or removed the subsystem changes are reflected in the Firmware Information List of the device.

Of relevance to the new plug-and-play capability, Bluetooth Mesh Protocol Specification 1.1 introduces a new formal name for the lifecycle of a device and 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 (the features, the elements, and models) and the unicast addresses of the node’s elements do not change.

Starting a new term may be needed to support a change in the hardware configuration of a physical device, such as attaching an auxiliary sensor, or to support a change in subsystem configuration on the node, such as an intra-luminaire network. The changes are indicated by the node by populating Composition Data Page 128 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.

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

2.2 Technical Highlights

2.2.1 DFU Roles

The DFU system defines a number of node roles. The roles are:

Role	Description
Initiator	The Initiator identifies available firmware updates for a given list of nodes in the network. It executes procedures defined in the DFU specification under the control of an application. The Initiator typically runs on a device which supports both Bluetooth^® Mesh and has internet connectivity, such as a smartphone or gateway device, and periodically checks manufacturers’ websites for new firmware releases. Having identified relevant updates, it acquires them and sends the new firmware images to a Distributor node.
Distributor	The Distributor receives new firmware images from an Initiator and is responsible for sending them to appropriate nodes in the network for installation. The Distributor is typically a physically separate device to the Initiator so that the Initiator (which will often be a smartphone application) does not need to be in range of the network during the entire process. The Distributor can be thought of as acting an intermediary for the Initiator.
Target	Target is the name given to a node which can receive a firmware image from a Distributor and install it.
Stand-alone Updater	A Stand-alone Updater fulfils the role of a combined Initiator and Distributor, acquiring firmware updates and sending them directly to Target nodes without the need for an intermediate Distributor.

2.2.2 Models

The DFU feature is based upon a number of new mesh models and a series of associated procedures that involve them.

The Transport models provide a generalized mechanism for transferring Binary Large Objects (BLOBs) between nodes.
The Firmware Distribution models support procedures which distribute firmware updates to Target nodes.

The Firmware Update models support procedures for updating device firmware.

Each model is involved in a series of procedures, which collectively allow available firmware updates to be identified, obtained, and distributed to relevant nodes, verified and installed.

2.2.3 Roles and Models

The following table is reproduced from the DFU specification and shows the relationship between DFU roles and the new models.

Role	Firmware Distribution Client	Firmware Distribution Server	Firmware Update Client	Firmware Update Server	BLOB Transfer Client	BLOB Transfer Server
Target	–	–	–	M	–	M
Initiator	M	–	M	–	M	–
Distributor	–	M	M	–	M	M
Stand-alone Updater	–	–	M	–	M	–

M: Support for this model by this role is mandatory.

A mesh node can support multiple roles by instantiating relevant models for each role.

2.2.4 Firmware Update Procedure Overview

There are a number of variations in the way in which the acquisition, distribution, and installation of firmware updates might be carried out. For example:

Firmware may be obtained by the Distributor from a vendor’s web site using the standard Firmware Check Over HTTPS procedure or by using an implementation-specific procedure.
An Initiator node may obtain a firmware image and send it to the Distributor for distribution to Updating nodes or it may send information with which the Distributor may obtain the firmware image itself.

A representative example of how the Initiator node, Distributor node, and one or more Target nodes may work together to obtain, distribute, and install a firmware update is depicted in Figure 1 and described in the text which follows it.

2.2.4.1 Find and Distribute Firmware Updates

Figure 1 – Obtaining and Distributing Firmware Updates

Figure 1 shows a series of procedures being carried out which obtain firmware updates from a vendor web site and then distribute and install them on a set of Updating nodes. Interactions between the nodes that are playing the various DFU roles are shown and where appropriate, the particular models involved are indicated.

In summary, it depicts the following:

The Initiator obtains information about the firmware that is currently running on a list of nodes specified by a higher layer application.
The Initiator checks for relevant updates to this firmware, in this case using HTTPS requests sent to a vendor web site. If there is an available update, it is downloaded. If not, the process is terminated at this point.
The Initiator then adds details of the list of Updating nodes to the Distribution Receivers List state of a Firmware Distribution Server on the Distributor node. Note that for the sake of simplicity, each node in the list should be able to accept the same firmware image.
The Initiator uses the Upload Firmware and the Transfer BLOB procedures to transfer the firmware image to the Distributor.
The Initiator then instructs the Distributor to initiate distribution.
The Firmware Update Client on the Distributor informs the corresponding server model on each Updating node that a firmware update procedure is starting and expects to receive a status message in reply.
7. The Distributor uses the BLOB Transfer procedure to transfer the firmware image to each Updating n

2.2.4.2 Check Distribution Progress

While the distribution of firmware to Updating nodes is taking place, the Initiator may ask the Distributor for information about the progress being made.

Figure 2 – Initiator checking the progress being made by the Distributor

2.2.4.3 Verify and Install Firmware

On receiving a complete binary image, the Updating node(s) will execute an implementation-specific verification check, for example, by checking a digital signature on the BLOB. The Distributor will monitor the status of the proceedings at the Updating node and, when appropriate, will instruct the Updating node to install the firmware update.

Figure 3 – Updating node verifying the firmware image and, when instructed to, installing it

2.2.5 File Formats

Firmware update files retrieved using the defined Firmware Retrieval Over HTTPS procedure shall use an archive file format that is defined in the Bluetooth Mesh Protocol Specification. The format includes a manifest file which describes the contents of the file, the binary firmware image file itself, and an optional metadata file which contains additional information about the firmware image. Both the manifest and metadata files use a defined JSON format.

2.2.6 Firmware Subsystem

A node may partition its firmware into a number of parts, each of which may be updated independently of the others. Each independent part is called a firmware subsystem. The mesh networking stack on a node might be an independent firmware subsystem, for example.

2.2.7 Update URIs

The Firmware Update Server model includes a state called the Firmware Information List state. It consists of Update URIs and associated Firmware IDs. The Firmware ID identifies a firmware subsystem on the node and the Update URI state value indicates the location of updates for this firmware. The mesh DFU specification indicates how this information is to be used to construct download URIs for use in the Firmware Check over HTTP procedure and might result in a URI such as this one:

https://mesh.example.com/check-for-updates/check?cfwid=02FF10000203

2.2.8 Transport Concepts

The BLOB Transfer models are designed to enable the transfer of any type of binary large object. In version 1.1 of the Bluetooth^® Mesh Protocol Specification, their only use is in the distribution of firmware images to Updating nodes, however. An understanding of the generalized capabilities of the BLOB Transfer models is important in understanding how the device firmware update feature works.

Figure 4: BLOB Transfer model. Showing the division of an image into blocks and division of blocks into chunks

2.2.8.1 BLOB ID

All BLOBs are allocated a unique, 8-octet identifier for use during the BLOB transfer procedures.

2.2.8.2 Blocks and Chunks

A BLOB is divided into a series of blocks by the BLOB Transfer Client. The block size is determined with reference to the capabilities of the destination BLOB Transfer Server, which are queried by the client.

Blocks are divided into chunks of equal size (apart from the last chunk, which may be smaller than the others if the block size is not an exact multiple of the chunk size).

Each BLOB Transfer Server calculates a number of parameters, including the largest chunk size it can handle. The maximum chunk size calculation involves the Maximum Transmit Unit (MTU) of the client and the server. When a transfer is being initialized, the client calculates a chunk size to be used by this transfer which all receivers can accommodate.

Each chunk is allocated a 16-bit chunk number to identify it within its parent block.

2.2.8.3 Transfer Modes

Two BLOB transfer modes are defined.

In the Push BLOB Transfer Mode, the client controls the flow. One block at a time is transferred, as a series of chunks to either a unicast address or a multicast address. The client then queries the server to determine which chunks were received and any chunks that are missing are retransmitted.

In the Pull BLOB Transfer Mode, the server controls the flow. This mode is designed primarily for use by Low Power Nodes and is used to transfer a BLOB from a client to one server at a time only.

2.2.8.4 Transfer Status Tracking

The nature of a Bluetooth^® Mesh network, with its multi-path and multi-hop messaging and system of retransmissions to increase reliability, means that the order of delivery of messages cannot be in any way guaranteed. As such, BLOB transfer messages that convey the chunks of the blocks into which a BLOB has been divided also cannot be guaranteed to arrive in any particular order. So, the BLOB transfer client may select blocks in any order and having selected a block, may send its chunks in any order.

A state called Missing Chunks, which belongs to the BLOB Transfer Server model provides a means by which the status of each chunk in the active block can be tracked. The Missing Chunks state contains a bit mask which is used as follows; each bit position in the state value indicates the status of the corresponding chunk with that chunk number. So, for example, bit position 7 indicates the status of chunk number 7 of the current block. A value of 1 means that the chunk has not been received whereas a value of 0 means that it has.

A BLOB Transfer Client retrieves the value of the Missing Chunks state from the servers it is transferring to and uses it to identify chunks that were not received and which still need to be transmitted or which need to be retransmitted.

2.2.9 Security

Maintaining up-to-date software is a generally accepted best practice in keeping computing devices of all types secure. But acquiring and installing software brings with it its own security risks. Critically, you need to be sure that you are acquiring the software from a trustworthy source and that the downloaded code has not in any way been tampered with and cannot be tampered with whilst it is being downloaded. Note that using HTTPS also prevents passive snoopers from discovering which firmware versions you are currently running in your network and which versions you are updating to. This can be valuable information if attacker knows of specific vulnerabilities in specific firmware versions.

The DFU specification requires the implementor to decide how to address these two issues.

The Check for Updated Firmware procedure gives the implementor the choice of using either the specified Firmware Check Over HTTPS and Firmware Retrieval Over HTTPS procedures or an implementation-specific set of procedures.

The Firmware Check Over HTTPS and/or Firmware Retrieval Over HTTPS procedures only allow the secure HTTPS protocol to be used. The HTTPS protocol ensures that data in-flight is encrypted and requires the server to have a digital certificate, which allows the HTTP client to authenticate the server’s claimed identity. Data is encrypted and any attempt to tamper with data that is sent between the two endpoints will be detected.

It is recommended that implementors use the most secure options possible for firmware update checking and retrieval.

3. Close

The Bluetooth^® Mesh device firmware update makes it easy to follow best practice and keep device firmware up to date on devices acting as nodes in the network. It is designed to make monitoring for the availability of new releases from vendors automatic and to support a user experience which is simple and as unobtrusive as possible.

Bluetooth^® Mesh Device Firmware Update