This week we will continue our tutorial series on Bluetooth mesh. Here’s where you can find part 1, part 2, and part 3. But before we get into the practical implementation of an example on the nRF52 series platform, let’s better understand how Bluetooth mesh works on the platform. We’ll go over:
- The basics and architecture of the nRF5 SDK for Mesh
- How to install and configure the SDK
- Which development boards are compatible
nRF5 SDK for Mesh
The goal of an SDK is to provide the developer with a set of APIs to make implementation easier and abstract out any unnecessary complexities in the underlying stack. Here’s a diagram showing the architecture of the nRF5 SDK for Mesh:
Let’s go through each of the layers within the architecture.
- Models: as we’ve talked about in the previous posts within this series, models define the behaviors and messages that are specific to a certain application. Models are similar to GATT in BLE in the sense that there are standard models defined by the Bluetooth SIG, but the developer is also given the freedom to define and develop their own (usually to implement a custom application or functionality that’s not satisfied by any standardized models).
- Access: think of the Access layer as a model multiplexing layer. It’s responsible for determining which mesh messages are meant for a specific model and forwarding it along to the intended model.
- DSM (Device State Manager): the DSM handles the task of storing the encryption keys and addresses used by the mesh stack. For each model that is configured and assigned application keys and addresses, the DSM stores these values in persistent storage (so they can be retrieved after a power cycle). It provides handles to these values to enable the models to use them.
- Core: the Core layer within the nRF5 SDK for Mesh consists of a transport and network layer.
- Transport layer: this layer is responsible for encrypting mesh packets with application keys (AppKeys) and splitting them into mesh packets to be transmitted over the air. It also handles re-assembling incoming packet segments and combining them into a format that can be passed on to the Access layer.
- Network layer: this layer encrypts all transport layer packet segments with the network key (NetKey) and populates the source and destination addresses before passing it on to the Bearer layer to be sent out over the air. On the receiving end, it decrypts the packets, looks at the source and destination addresses to determine whether the packet should be relayed up the stack.
- Provisioning: provisioning is a requirement for any mesh network. Each device needs to go through the provisioning process before it joins the network. The mesh stack provides two ways of provisioning a device: either directly through what’s called the PB-ADV (advertising provisioning bearer) or through remote provisioning. The PB-ADV provisioning can only happen between two devices that are within range of each other. Remote provisioning allows the two devices to complete the process without being in the range of each other, with the help of the other devices in the mesh network.
Important note: keep in mind that the remote provisioning feature is Nordic-specific and cannot be used with devices from other vendors.
- DFU: this layer/module handles the process of updating the firmware of the device. It allows concurrent, authenticated firmware transfers to all devices within the mesh network without affecting the operation of the application. This is different and incompatible with the DFU process used in the nRF5 SDK for BLE devices.
Important note: keep in mind that the nRF5 Mesh DFU feature is also Nordic-specific and cannot be used with devices from other vendors.
- Bearer: this level/module is used only internally and not accessible to the application layer. It handles the low-level radio controller operations needed to comply with the timings and packet format of BLE.
SDK Installation and Configuration
There are a few required tools that need to be installed before being able to build an nRF5 mesh example or application. These tools are summarized in the following table:
In addition to these required tools, there are two options for the build environment: either using CMake or using SES (Segger Embedded Studio). We will focus on the SES solution since it’s easier and more straight-forward to use.
From Nordic’s documentation:
Python is not required to build the mesh stack and examples, but it is required when working with DFU, the Interactive PyACI, generating SEGGER Embedded Studio projects and when building documentation. The nRF5 SDK for Mesh uses Python 3, however, the nrfutil tool used for DFU transfers over serial requires Python 2.7.
In order to get the installation fully working, follow the instructions laid out on the following pages:
- Building the mesh stack and examples
- Building with SEGGER Embedded Studio
- nRF5 SDK for Mesh Segger Embedded Studio first time setup
The following chipsets and development kits are supported by the nRF5 SDK for Mesh:
In our implementation examples, we’ll be using a mix of the nRF52840 and nRF52832 development kits.
nRF52 Bluetooth Mesh Examples
There are quite a few examples provided with the nRF5 SDK for Mesh. Each requiring a different number of development kits (or devices) and demonstrating different concepts and features within Bluetooth mesh. Some of these examples include:
- Light switch
- Experimental dimming
- Remote provisioning client
- Remote provisioning server
- and more…
In this post, we covered some of the basics of the nRF5 SDK for Mesh. In the next post in the series, we’ll take a look at the different examples in more depth, choose one of them, and start implementing it.