nRF5 SDK for Mesh v5.0.0
Bluetooth mesh stack architecture

The mesh stack consists of a number of subsystems that are interfaced through a set of API modules, and are involved in the Bluetooth mesh network data flow. The API modules hide the complexity of their subsystems. The functionality provided in the API is sufficient to make a functioning Bluetooth mesh device, so that there is no need to bypass the API.

Basic architecture of the Bluetooth mesh stack in the nRF5 SDK for Mesh

The Bluetooth mesh stack's structure corresponds to the structure of the Bluetooth mesh specification and follows the same naming conventions:

Check the official Bluetooth mesh glossary for definitions of the most important mesh-related terms used in this documentation. You can also read Basic Bluetooth mesh concepts for a concise introduction to the Bluetooth mesh.

Bluetooth mesh network data flow

The following figure demonstrates how the data packets flow between mesh network nodes and their layers within the Bluetooth mesh stack structure.

Basic data flow within a mesh network in the nRF5 SDK for Mesh

For example, after a light switch is pressed on the source node, the following process takes place:

The light bulb model may respond to acknowledge the transmission, following the same procedure back to the light switch node, which can notify the application that the on/off message was received.


API: Mesh Models

The models define the behavior and communication formats of all data that is transmitted across the mesh network. Equivalent to Bluetooth Low Energy's GATT services, the Bluetooth mesh models are independent, immutable implementations of specific behaviors or services. All Bluetooth mesh communication happens through models, and any application that exposes its behavior through the mesh must channel the communication through one or more models.

The Bluetooth mesh specification defines a set of immutable models for typical usage scenarios, but vendors are also free to implement their own models.

You can read more about models, including how to implement your own models, in Bluetooth mesh models.


API: Access

The access layer controls the device's model composition. It holds references to:

As the device receives Bluetooth mesh messages, the access layer finds which models the messages are for and forwards them to the model implementations.

Device State Manager

API: Device State Manager

The Device State Manager stores the encryption keys and addresses used by the Bluetooth mesh stack. When models get assigned application keys and publish addresses through configuration server, the Device State Manager stores the raw values and provides handles to these values. The models can use the handles when referencing these values.

The Device State Manager stores its data in persistent storage, which it can recover on bootup.

Mesh Core

API: Core

Consisting of a network and a transport layer, the Mesh Core module provides the Bluetooth mesh-specific transport for the messages.

The transport layer provides in-network security by encrypting Bluetooth mesh packets with application keys and splitting them into smaller segments that can go on air. he transport layer re-assembles incoming packet segments and presents the full Bluetooth mesh message to the access layer.

The network layer encrypts each transport layer packet segment with a network key and populates the source and destination address fields. When receiving a Bluetooth mesh packet, the network layer decrypts the message, inspects the source and destination addresses, and decides whether the packet is intended for this device and whether the network layer should relay it.

The Mesh Core provides protection against malicious behavior and attacks against the Bluetooth mesh network through two-layer encryption, replay protection, and packet header obfuscation.


API: Provisioning

Provisioning is the act of adding a device to a Bluetooth mesh network. The provisioning module takes care of both sides of this process, by implementing a provisioner role (the network owner) and a provisionee role (the device to add).

For detailed information about the provisioning process, see Implementing provisioning.

The mesh stack provides two ways to provision a device:

The remote provisioning is a Nordic proprietary feature that cannot be used with devices from other vendors.

The remote provisioning example demonstrates remote provisioning. The light switch example shows the provisioner and provisionee side of PB-ADV as a first step to establishing the network.


API: Bearer

The Bearer is the low-level radio controller that provides an asynchronous interface to the radio packet sending and receiving for the upper layers. It enforces Bluetooth low energy compliance for packet formats and timing, and operates directly on radio hardware through the SoftDevice Timeslot API.

The Bearer is an internal module that normally does not need to be accessed by the application.



The Device Firmware Upgrade module provides firmware update capabilities over the Bluetooth mesh by cooperating with a bootloader. It is capable of concurrent, authenticated firmware transfers to all devices in a network, without halting the application.

  • The proprietary mesh DFU is a Nordic proprietary feature that cannot be used with devices from other vendors.
  • DFU procedure is not compatible with the Bluetooth low energy secure DFU procedure used in the nRF5 SDK.

For more information about DFU, see the DFU protocol section, including information about how to run the proprietary mesh DFU.

Mesh Stack

API: Mesh stack

The Mesh Stack module is a thin wrapper around the top-level Bluetooth mesh modules that makes it easy to get started using Bluetooth mesh. It takes care of mesh initialization and enabling. It also contains functions for storing and erasing provisioning and state related data.


API: Serial

The serial module provides full serialization of the Bluetooth mesh API, allowing other devices to control the nRF5 mesh device through a UART interface. Intended for network gateways and similar complex applications, the serial interface provides a way to access the mesh network through a Nordic device, without making it the unit's main controller.

The serial interface is based on the nRF8001 ACI serial interface and optionally supports SLIP-encoded operation. The serial protocol can be run as a stand-alone application (see serial example) or alongside a normal Bluetooth mesh application.

For an overview of the serial packet format, commands, and events, as well as the related Interactive PyACI script, the Serial interface section.

Documentation feedback | Developer Zone | Subscribe | Updated