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.
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.
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.
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
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.
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.
I think the provisioner is much complexer than the other mesh devices.One of the important function of provisioner is to config the status(such as the publish/subscription address) of all the nodes,just like a manager role of the mesh network. Is that right? and what the recommend for a device for provisioner?
Thanks a lot
@Hung thank you very much.
@Yatekii: No there is no particular reason that it has to be SDK v12, just because we had our development started with S132 v3.0.
@Folu: No,not something coming in near future.
Hey Hung, how about friend node support for BLE mesh?