Scalability and Provisioner Backup Considerations for BLE Mesh Network

Hello,

I am currently working on a BLE Mesh–based control system and would appreciate guidance on a few architectural and scalability concerns.

System Overview
The network uses a star topology, with a central node (nRF52840 DK) interfacing with a PC via a serial connection. This central node receives commands from the PC and translates them into corresponding BLE Mesh messages (e.g., setting a level server or querying a sensor value from a specific node).

From a physical topology perspective, nodes are deployed linearly, spaced 40 meters apart, with the central node located anywhere in the network.

Provisioning Approach
Currently, provisioning and configuration are handled entirely by the central node. Upon receiving a serial command, the central node provisions and configures a device with the specified UUID within the mesh network. Node removal is handled through a similar process. The central node, therefore, maintains the network's Configuration Database.

This approach works well for small deployments (on the order of tens of nodes). However, we have concerns regarding scalability and robustness as the network grows.

Questions and Concerns

  1. Provisioner State Backup and Recovery
    Since the central node acts as the sole provisioner and stores the network’s CDB, is there a recommended way to back up or preserve this information?
    Ideally, if the central node fails or becomes corrupted, we would like to restore the provisioner state to a replacement device and allow the network to continue operating without requiring re-provisioning of all nodes.
    Would reading and restoring the entire flash contents of the central node be a viable or supported approach, or is there a more appropriate mechanism within the BLE Mesh stack for this purpose? Is this possible?

  2. Remote Provisioning
    How would remote provisioning apply to a network with this topology and operational model?
    Are there known limitations or best practices when using remote provisioning in large, linearly distributed networks?

  3. Provisioning via nRF Mesh App
    Would migrating the provisioning process to the nRF Mesh mobile application be beneficial in terms of scalability, maintainability, or robustness compared to using a custom central-node-based provisioner?

Future Scale
While this product is still in development, the target deployment is to support hundreds of independent networks, each with tens of nodes, for a total of potentially thousands of devices.

Any recommendations or references to best practices for provisioning, backup strategies, and large-scale BLE Mesh deployments would be greatly appreciated.

Best regards, Santiago

Parents
  • Hi Santiago, 

    Sorry for the late response. What you wrote makes total sent. In fact that what was BLE mesh designed for. The database should be stored on a standard computer/mobile phone with way to back up and restore database (to the cloud if necessary) not directly on a microcontroller. 

    I would suggest to take a look here: https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/connectivity/bluetooth/api/mesh/shell.html#configuration_database  and get familiar with the BLE mesh shell module. 
    While it does not provide an application level API, it does the next best thing by providing shell commands for most Bluetooth Mesh features. It should be possible to control everything that you need from a script, using a Dongle or DK with the Bluetooth Mesh Shell test sample.

    You can do provisioning, setup/restore a CDM database on the provisioner, and do remote provisioning from the Mesh Shell. You can find remote provisioning functions in the document above. 

    It's also possible to do provisioning/remote provisioning from the nRF Mesh app. It's up to you to choose which architecture you want to implement. 

    I don't see a problem with the lineal mesh you are doing. Of course it may limit the benefit of using a mesh network, but it should still function, especially if one node can be in the range of several nodes close to it. 

Reply
  • Hi Santiago, 

    Sorry for the late response. What you wrote makes total sent. In fact that what was BLE mesh designed for. The database should be stored on a standard computer/mobile phone with way to back up and restore database (to the cloud if necessary) not directly on a microcontroller. 

    I would suggest to take a look here: https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/connectivity/bluetooth/api/mesh/shell.html#configuration_database  and get familiar with the BLE mesh shell module. 
    While it does not provide an application level API, it does the next best thing by providing shell commands for most Bluetooth Mesh features. It should be possible to control everything that you need from a script, using a Dongle or DK with the Bluetooth Mesh Shell test sample.

    You can do provisioning, setup/restore a CDM database on the provisioner, and do remote provisioning from the Mesh Shell. You can find remote provisioning functions in the document above. 

    It's also possible to do provisioning/remote provisioning from the nRF Mesh app. It's up to you to choose which architecture you want to implement. 

    I don't see a problem with the lineal mesh you are doing. Of course it may limit the benefit of using a mesh network, but it should still function, especially if one node can be in the range of several nodes close to it. 

Children
Related