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]

I have edited the question to give further details, but bear in mind that the use case detailed is actually very broad, and actually defines the architecture for the platform we are trying to develop. We just want to evaluate Bluetooth mesh as a possible way to implement this with what's currently available.

[Hung Bui]

If you looked at our light switch client code, you can find that after provision 3 nodes into the network, it will stop enterring waiting for unprovisioning mode. Basically stop being a provisioner and just work as a normal node  (one node with 4 elements in this case). 

I don't see any problem with your plan as long as you can have a way of communication inside the network so that the new provisioner won't reassign an address that given to a node to a new node. Or you can simply set different address spaces for different provisioneers so they won't overlap. Note that there shouldn't be a case that 2 provioners provision 1 node at the same time because a provisioning link has to be established and one node can't have 2 links at the same time.