BLE Mesh provisioner functionality

RE: BLE Mesh provisioner functionality

Hung Bui — Fri, 02 Feb 2018 12:54:03 GMT

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.

RE: BLE Mesh provisioner functionality

alasknnj — Sun, 28 Jan 2018 21:21:10 GMT

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.

RE: BLE Mesh provisioner functionality

leonwj — Sun, 28 Jan 2018 20:24:23 GMT

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.

RE: BLE Mesh provisioner functionality

alasknnj — Sun, 28 Jan 2018 11:25:41 GMT

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.

RE: BLE Mesh provisioner functionality

leonwj — Sat, 27 Jan 2018 23:41:19 GMT

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

RE: BLE Mesh provisioner functionality

leonwj — Sat, 27 Jan 2018 23:35:47 GMT

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.

RE: BLE Mesh provisioner functionality

alasknnj — Sat, 27 Jan 2018 10:48:07 GMT

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)?

RE: BLE Mesh provisioner functionality

alasknnj — Sat, 27 Jan 2018 00:29:15 GMT

Thanks for your guidance, I will check the post.

RE: BLE Mesh provisioner functionality

leonwj — Sat, 27 Jan 2018 00:21:16 GMT

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.

RE: BLE Mesh provisioner functionality

alasknnj — Fri, 26 Jan 2018 23:38:38 GMT

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.

RE: BLE Mesh provisioner functionality

leonwj — Fri, 26 Jan 2018 23:28:16 GMT

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

RE: BLE Mesh provisioner functionality

alasknnj — Fri, 26 Jan 2018 22:50:30 GMT

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.

RE: BLE Mesh provisioner functionality

leonwj — Fri, 26 Jan 2018 22:46:36 GMT

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.

RE: BLE Mesh provisioner functionality

alasknnj — Fri, 26 Jan 2018 22:28:27 GMT

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?

RE: BLE Mesh provisioner functionality

leonwj — Fri, 26 Jan 2018 22:17:17 GMT

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,