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]

...(continuation), therefore from a practical perspective the designated Provisioner(s) in a single mesh network will need to be available/functional for the entirety of the life of that network.

[alasknnj]

Sorry, I wasn't clear. I have seen other questions regarding provisioning, and from what I understood, If a provisioner device were to be removed from the network, the mesh would still work, however no new device would be able to join the network, and it could not rely on the provisioner for management. From what I have seen on the documentation, it also seems the case. It's possible right? I just wanted to know if instead of removing the provisioner device of the mesh, it could simply stop provisioning, and therefore closing the mesh for new devices to connect, and still be part of the network. Or is it not possible at all? Thanks for your attention to my doubts.

[leonwj]

As stated in the original answer and subsequent comments above,

(1) "...From that point, mesh devices/nodes can happily function within the network without going through the Provisioner." and

(2) "...typically the Provisioner will also couple that configuration client so this device will also be responsible for mesh network management etc."

Given the above, can I suggest that you clearly document the use case for your mesh network to need to function without the need for provisioning and/or configuration client functionality, and then we can offer guidance on its validity/feasibility.

[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.