The day after the Bluetooth SIG announced the 1.0 spec of the Bluetooth mesh we are happy to announce the nRF5 SDK for Mesh for our nRF51 and nRF52 Series SoCs. This first (v0.9.1) release is packed with new features and concepts for Bluetooth.
What is Bluetooth mesh? The mesh capability is a significant update and enables a radical new approach to making Bluetooth applications. With this update to Bluetooth, there are significant changes and many new concepts to learn for developers and product makers. From a holistic point of view, mesh enables Bluetooth to expand its range/coverage and increases the # of nodes in the network and enables many-to-many (m:m) communication.
nRF5 SDK for Mesh
The below figure is showing a Bluetooth mesh network, which can be created with the nRF5 SDK for Mesh.
All nodes in a network are capable of sending and receiving messages. A relay node has the additional capability of re-broadcasting messages. (To support battery powered nodes; the Low Power nodes and Friend nodes are defined in the Bluetooth SIG specification. This functionality is not implemented in v0.9.1 but will be added at a later stage.) Bluetooth mesh relies only on scanning and advertising, so it means that every received packet is broadcasted by relays, until the packet is received by the destination node (a so-called managed flooding mesh). A simple, but effective way of spreading information across the mesh network with no single point of failure. In order to avoid excessive and unnecessary network traffic/flooding, there are mechanisms to reduce traffic, such as adjustable scanning and advertising intervals and a time-to-live (TTL) counter, which defines how many times a packet can be broadcasted.
The network latency and node power consumption depends on how much of the time is spent in scanning and advertising. The latency is on average 15ms per hop and the power consumption of the nodes is largely determined by the receive current (if everything is configured for minimum latency which means radio is on close to 100% of the time). Smartphone/mobile phone connectivity to the mesh node is realized using a concurrent Bluetooth Mesh stack and the standard Nordic Bluetooth stack (GATT/GAP). Thus, the mobile phone is not part of the mesh network, but the messages to/from the phone can be bridged into the network via the mesh node with concurrent mesh and GATT/GAP. If you want to dig deeper into Bluetooth mesh and how it works in the nRF5 SDK for mesh, I suggest having a look in our documentation which can be found here.
SDK Architecture
The architecture of the nRF5 SDK for mesh is show in the figure below. As you can see, the mesh stack is a new stack consisting of new layers as specified by the Bluetooth SIG, i.e., Bearer, Network, Transport (Lower/Upper), Access and Foundation models. Above those layers, mesh models are defined (Lighting, sensor etc.) which is similar to the profiles in standard Bluetooth low energy. As shown in the figure, the mesh stack utilizes the Nordic SoftDevice time-slot API to allow for concurrency with GATT/GAP based devices. This is the way we support connectivity with phones/tablets/PCs that do not support the Bluetooth mesh standard.
A typical use case for the mesh is to have beacons with a mesh as a back bone network to push out updates etc or use beacons for asset tracking. We have therefore created a Beacon API as part of the Mesh SDK to do concurrent Beaconing and mesh networking. We have also created a serializer API, so that the mesh can be controlled from an external host. This is especially useful for customers who are designing a Bluetooth Mesh gateway, i.e. a bridge between the Bluetooth Mesh and other protocols such as Ethernet/WIFI/LTE.
A key feature needed when developing products for an evolving standard such as Bluetooth mesh is the capability to upgrade nodes. We therefore implemented 2 different over-the-air DFU modes. One is a side-by-side DFU to avoid application down time, the other is designed to minimize the flash memory footprint with the disadvantage that the application is down during the roll out of the new FW.
Provisioning
Before a device can participate in a mesh network, it must be provisioned. During provisioning, a device gets added to the network and is assigned a range of unicast addresses, a network key, and a device key. The provisioning is done by a Provisioner, which is a trusted device with access to the full list of devices in the network and their addresses. Another proprietary feature (not part of the Bluetooth SIG Mesh 1.0 spec) we have implemented in the SDK is a remote provisioning feature that allows provisioning nodes outside of direct radio contact with the provisioner
Development tools
The nRF5 SDK for Mesh also includes Segger Embedded Studio project files and a Python shell script to communicate with the mesh network from a PC via the serializer API. To get started with development we recommend to use the nRF52-DK, nRF51-DK and/or the nRF51 Dongle.
Future developments
I hope you get a chance to try this out and stay tuned for more releases! We will for sure not stop here. In the future releases we are working on implementing the Low Power and Friend features to allow customers to use battery operated or possibly even energy harvesting devices. We will also release implementations of the standard models as defined by the specification. Feel free some feedback on what models you will need. Currently, the mesh nodes need a SoftDevice, as they use support functions from the SoftDevice even when GATT/GAP is not used. In the future it will be possible to enable the mesh stack to be used without the SoftDevice. This would allow our customers to use devices with smaller Flash and RAM memory (like the nRF52810) when phone connectivity (GATT/GAP) is not needed. We will also include more examples as we continue the journey towards a production release of the SDK. High on the priority list is a concurrent Mobile phone / tablet connectivity example.
In the table below I listed have the features of our first Bluetooth mesh SDK. The blog post will be too long to go through all the features and they are described in the documentation.
Again, feel free to provide feedback on features that you would like to see in the nRF5 SDK for Mesh.
Features
- Bluetooth Mesh software core stack
- Based on Bluetooth 4.0 PHY
- Bearer, Network, Transport, Access layers and Foundation models
- Support for node with relay feature
- Configurable scanning interval (from 3ms-10240ms) and duty cycle
- Configurable advertisement interval (from 20ms-10240ms)
- Example applications and proprietary models
- Broadcast flooding mesh
- Theoretically up to 32,000 nodes
- No routing feature or routing tables
- No single point of failure
- Node to Node and Node to group communication
- Configurable time to live (TTL)
- Two-layer 128-bit AES-CCM network and transport security
- Provisioning support
- Standard provisioning over advertisement bearer
- Proprietary “remote” provisioning over relaying nodes
- Persistent (Flash) storage of configuration data
- Support for concurrent beaconing
- Support for concurrent standard GATT/GAP connections
- Connectivity to PCs and tablets
- Integrated with Nordic standard SoftDevice
- Support for network processor “two chip” configuration
- Serialization over UART
- Python driver for easy PC connectivity
- Python shell based test and demo framework for PC
- Support for over-the-air secure background DFU
- Application and/or stacks
- Cross-platform toolchain
- Segger Embedded Studio
- arm-gcc and armcc
- Windows, Linux and Mac-os
nRF5 SDK for Mesh 0.9.1 content
- Core Bluetooth mesh software stack up to Access layer (source code)
- Foundation Models, Application layer including DFU, remote provisioning model, persistent storage and serializer (source code)
- Examples for beaconing, lighting control and provisioning (source code)
- S132v3.0, S130v2.0.1 and S110v8.0.0 SoftDevices
- Python shell based test and demo framework (source code)
- Binaries for bootloader
- Segger Embedded Studio project files
Compatibility and requirements
- nRF51822 and nRF52832 SoC
- nRF51-DK, nRF51-Dongle and nRF52-DK
- Recommended > = 200kB Flash and > =32kB RAM
- nRF5 SDK (v10.0.0 for s110, v12.1.0 for s130 and s132)
- Segger Embedded Studio v3.22 or v3.24
