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.

[alasknnj]

I see. To use a smartphone or a tablet as provisioner would actually be better however, from what I have seen, that's still in development. I also don't think that this is the best path for the application, but it's the first solution I came up with after reading through the BLE mesh documentation, I was actually trying to evaluate it's feasibility.

[leonwj]

If you are on (plan to be on) nrf5x devices then try to have a look at this post it's not the most definitive but will give you some initial guidance. Although the setup time in terms of development environment etc. is quite high it will allow you to get a firm practical grasp of Bluetooth mesh. Once you are able to provision simple devices via the SiLabs Smartphone (PB-GATT) app, you can then look at setting up publication/subscription groups and heartbeat messages etc.

Some of the members on my team went this route for their basic understanding of mesh and then moved onto implementing mesh nodes via the Nordic Mesh SDK. They now happily switch between both Zephyr and the Nordic SDK depending upon the functionality they want to implement but then that's the 'beauty' of having a mesh standard in place.

[alasknnj]

Thanks for your guidance, I will check the post.

[alasknnj]

Just another point, if you may. Setting a device as a provisioner in the application turns it into a heavy process, but does it continue as so if it no longer acts as a provisioner. What I mean is, does the provisioning implementation compromise the device (process wise) after being set as provisioner, even after not acting as so in an arbitrary amount of time (if that's possible)?

[leonwj]

I'm not entirely sure what you mean by, "but does it continue as so if it no longer acts as a provisioner"...

You should note that every Bluetooth mesh network must have at least one Provisioner, so that device/functionality cannot simply be removed from the mesh network. The Provisioner assigns unicast addresses/node ids to newly provisioned devices, however there is also a configuration phase where (network keys, device keys etc.) are distributed to the new mesh node. This configuration phase is carried out by the Configuration Client model. Although not mandated to be the same device, typically the Provisioner will also couple that configuration client so this device will also be responsible for mesh network management etc. (see section 3.10 of the Bluetooth Mesh Profile Specification) for more info on this.