BLE Mesh provisioner functionality

[alasknnj]

I've just read the BLE Mesh documentation, very informative, but I still have some questions related to the concept and implementation, which are:

• Can a device toggle functionality between provisioner and provisioneer, or even act as both?
• How does the network react to two provisioners in the same network?

Thanks

---

As requested, I will explain a little better the use case and what I want to try. Rather than asking about the use case, I would like to know more about the feasibility of the process in which the use case is implemented, more specifically the Nordic implementation for the mesh rather than the mesh specification itself.

So, the use case is for a user to be able to set a mesh network to be used for interaction with phone or tablet. The user will establish a network over a set of identical devices which will then use the network to run an application managed by the phone/tablet.

I am aware that the mesh specification allows for a phone or tablet to act as provisioner and manage the devices, which would actually be the ideal scenario. However, until the Nordic implementation for PB-GATT is out or if anyone can point me a PB-ADV that works with Nordic mesh implementation, I can't try this setup.

To try to work this around, I wanted to know if the following procedure could be done, taking into consideration Nordic's current SDK, because from what I gathered reading the mesh documentation, it should be possible.

The procedures would be to make the device boot as a provisionee, and after an arbitrary amount of time, if not connected, either change or reboot as a provisioner, so that any future device could start provisioning with it.

After a certain number of devices are added to the mesh, according to the limit set by the application on the phone/tablet connected to any of the devices, or the provisioner device (not necessarily through mesh, which in documentation is mentioned as possible, but I do not know whether it's currently implemented), the provisioner would either stop provisioning or reboot as provisionee (if it's possible for a provisionee to get a device key for itself), and thus leading the mesh to a network composed of only provisionees and a fully working network.

For this procedure, I assumed many things as implemented in the Nordic's latest Mesh Sdk as well as some technicalities which could be very implement-specific.

My question is if this procedure is feasible, if it's feasible but very inefficient, or not possible at all.

I came across Bluetooth mesh recently and read what I could from the documentation and questions here, but I still have some doubts which led to this question. If any of my assumptions were wrong or if you could point me a different approach, such as leonwj's suggestion, I would be very happy to look it up.

Thanks.

[leonwj]

Hello alasknnj,

Within the Bluetooth Mesh specification the Provisioner is defined as a device that can both

(a) create a mesh network, as well as

(b) provision/add new, unprovisioned devices (Provisionee's) into that same mesh network.

For any single mesh network the Provisioner is initially simply a random device looking for Provisionee's to join its network and without a Provisioner, provisionee's are devices that will simply send out unprov'd beacons looking for a network to join. Once a Provisioner has selected a device (Provisionee) to join its network, it will provide the unprovisioned device with the provisioning data that allows it to become a node within that mesh network and proceed with authentication steps etc. From that point, mesh devices/nodes can happily function within the network without going through the Provisioner. As such, and within the context of your question, the Provisioner can't toggle between being a provisioner and provisionee or act as both (at least not within the same mesh network).

Additionally, although the Bluetooth Mesh specification mandates that each mesh network must have a single Provisioner (obviously to perform initial mesh network creation and provisioning), it doesn't preclude additional provisioner devices being added/used in that same mesh network. So it is certainly possible to have multiple provisioners. What the specification doesn't currently do however, is set a standard for how those multiple provisioners would share the same namespace and synchronize mesh network changes between themselves. At the present time, this functionality would be implementation specific. So for example, you would potentially have to ensure that 2 or more Provisioners don't assign the same device key or Node Id to different devices or that 2 different Provisioners don't try to add the same device to the network at the same time etc.

I hope that this provides the clarification that you were looking for but let us know if you require any further insight.

Regards,

[alasknnj]

Therefore, I could not implement an application in which the device starts as a provisionee, and upon not being connected to a mesh network after some time, act as a provisioner for future devices?

[leonwj]

So based upon your comment, I'm assuming that the basis of your use case would be that...

(1) your device would initially sit around waiting for a mesh network to join (i.e. act as a Provisionee), however after some arbitrary period of time it would decide that since it had nobody to 'play with'...

(2) it would then decide to setup a mesh network of its own (i.e. as Provisioner)

It would be good if you could elaborate further on the use case that you have in mind.

[alasknnj]

That's precisely the case. The details are not finished, but basically I wanted a mesh network without a different device in it (functionality wise), that is, any device could start the mesh and if one is has already started, the other devices should join it.

[leonwj]

(1) Right, but remember that in general you're mainly dealing with constrained devices (and provisioning is a resource heavy process) so having 'top-heavy' functionality built into a device that may not be used is something that would need to be factored into your design process.

(2) That being said, it's envisaged that your typical Provisioner would provide a UI i.e. tablet/smartphone and so will be specialized devices in the first place. Therefore any mesh network designer would/should know whether they have an existing/functional mesh network before attempting to deploy any devices.

Given the above, the greater task would be to ensure that Provisioner(s) redundancy is achieved via device backup/cloud storage etc. so that the mesh isn't left 'in limbo' through data/device loss. But again the mesh specification leaves this task to the implementer of the mesh network.