How to use Bluetooth Mesh GATT provisioning with regular BLE stack?

[gsegment]

I am running an example from Mesh SDK (v2.1.1) named "ble_app_uart_coesixt". I see device in Bluetooth list, everything is ok. But I need to provision this device using my smartphone without other devices. My goal is to provision device and than communicate with regular BLE uart profile. I can't understand how to combine "light_switch proxy_client" with coexist example. As I see it is just GATT service, and I don't need a "proxy" feature itself, only need to provision device with BLE. How can I do it?

[Bjørn Kvaale]

Hi,

You will need to use the proxy functionality to provision the device via the nrf mesh iOS/Android app. It might be easiest to try out the light switch proxy client & proxy server examples first & then add the uart functionality to those examples, like explained here. It could also be useful to take a look at this Youtube video on provisioning with the nrf mesh app.

Kind Regards,

Bjørn

[gsegment]

I got an update Mesh 2.2.0. Seems your team forget to add ticker.c/ticker.h source files or forget to remove them from the included files in the project.

I did the same steps, now it seems working but not fully.

1. sd_ble_gap_adv_set_configure returns NRF_ERROR_NO_MEM. I had to comment all advertising calls in main.c, so in this case only mesh uses it.
2. An error occurs when calling sd_ble_gatts_exchange_mtu_reply at mesh_gatt.c.517. I had to commect all m_gatt calls in main.c to let only mesh have access to sd_ble_gatts_*
3. This configuration runs without BLE services (because I had to comment adv and gatt), but all other code do not provide conflicts, so I can do a provision.
4. I will try to figure out the way to start BLE services. I hope you can advice me

[gsegment]

I am confused. Imagine that we have mesh network. When this network is not configured, I can use smartphone and do a provision of all devices via proxy feature, right? After all nodes configred I need to be able to communicate (control) with devices via different (another) smartphone, this new smartphone does not have any mesh network keys, so how it can use proxy feature without "be provisioned"? How node can can be controlled by proxy feature? For the BLE there is whitelist and bonding process, but how node can accept or decline smartphone with proxy? 

[Bjørn Kvaale]

What do you mean by "how node can be controlled by proxy feature?" Do you want to change configuration parameters with the second smartphone (the one that was not used during provisioning) or do you just want to talk to the mesh network with the second smartphone?

[gsegment]

This means that I want to control (on/off/etc) the specific device, without access to whole network. For example, I have a configured light switch and hundred of devices in a single network, and I have a guest that want to control this lightswitch, but this guest is not an owner of this network and there can be a lot of different people who want to control light switch when they are inside a room. 

[Bjørn Kvaale]

Thanks for the detailed explanation. There is something called temporary guest access in the mesh specification. The guest node still needs to be provisioned & then it will be provided a temporary network & application key. The light bulb needs to be controlled by the guest would also have a subnet network key, as well as a temporary application key. You will still need to provision this guest node unfortunately.

Take a look at this excerpt from the profile spec in section 3.10.2

"It is possible to provide a node with temporary guest access to a mesh network. This is done by creating a separate guest subnet by providing a separate network key to the guest and to the nodes the guest will have access to.
Separate application keys are also provided to the guest to restrict the models that the guest has access to at the access layer.
The guest never obtains application keys or network keys used by nodes and models that are excluded from guest access. Only nodes that belong to the guest subnet will communicate with the guest node; within these nodes, only models bound to the guest application keys can be used by the guest. This allows guest access to be very finely controlled down to specific nodes and functionalities.
Guests cannot initiate IV Index updates on the primary subnet. This protects the IV Index, which is a network shared resource, from a potentially malicious behavior.
Guest access is configured by a Configuration Client using the Configuration Server model that is secured by device keys. Multiple guests may be provided with guest access, each within their own guest subnet and model domain.
Guest access is revoked by refreshing application and network keys through the Key Refresh procedure (see Section 3.10.4)."

The main reason for making it this "complicated" is increased security.

Do you want the guest node to be another mesh device or a smartphone connected via the proxy node?

If so, it is possible to do the inverse of what we are doing with the nrf mesh app, where the phone can be provisioned via the proxy node. The phone would run the PB-GATT provisionee attribute table on the app (could be a modified nrf mesh app). Another node in the network that allows provisioning will then connect to this guest phone & then do the provisioning process. The main purpose of this exercise is to distribute the network & application keys to the guest so that it can participate as a guest in the mesh network.

You may be able to do this via a proprietary way by distributing a temporary network & app key to the guest smartphone, but it is most likely better to follow the spec like described above.

Kind Regards,

Bjørn

[gsegment]

Thanks for response,

Bjørn Kvaale said:

Another node in the network that allows provisioning will then connect to this guest phone

As I know there can be only one provisioner node in the network? And in my case the provisioner can be different smartphone that can't be used for guest. Is it possible to make "virtual" provisioner and use smartphone's BLE as relay (PB-GATT connection) between remote server (as provisioner) and real node?

And if there is a lot of guests, what provisoner will do with unique indexes that should be assigned to every new connected device (smartphone)?

[Bjørn Kvaale]

gsegment said:

As I know there can be only one provisioner node in the network?

 Essentially yes. Although you could theoretically have multiple provisioners that make different mesh networks & find a way of communicating within the different mesh networks. I am not sure I would recommend this.

gsegment said:

Is it possible to make "virtual" provisioner and use smartphone's BLE as relay (PB-GATT connection) between remote server (as provisioner) and real node?

 Do you want to use the remote provisioning functionality from our mesh sdk & provision nodes out of reach of the smartphone via relaying the information through intermediary nodes? Could you explain what you mean by virtual provisioner?

gsegment said:

And if there is a lot of guests, what provisoner will do with unique indexes that should be assigned to every new connected device (smartphone)?

The provisioner will store these unique application & network keys in the device state manager.

[gsegment]

Bjørn Kvaale said:

Do you want to use the remote provisioning functionality from our mesh sdk & provision nodes out of reach of the smartphone via relaying the information through intermediary nodes? Could you explain what you mean by virtual provisioner?

My idea was not to do a standard provision. I mean that if we know provisioner keys than we can remotely prepare a "new" node and send subnet key and node ID to a guest's smartphone via internet/wifi. And guest's smartphone can become a node instantly without a real device need and not using "provisioning functionality from mesh sdk". What do you think about this?

Bjørn Kvaale said:

The provisioner will store these unique application & network keys in the device state manager.

Yes, but I was talking about node IDs. Bluetooth mesh can handle 16-bit addresses, but at provisioning stage the provisioner acquiring short ID for a new node. So when guest has been provisioned and later leaves, how we can handle >16 bit IDs acquiring? At the same time there is small amount of smartphones connected, but over time it can become large.  

[Bjørn Kvaale]

1) Do you want to be Bluetooth Mesh compliant? If so, I believe these provisioning you want to do might break the Bluetooth Mesh specs, thereby making it very difficult to become certified. You can naturally make your own proprietary mesh solution if that is easier & you do not need Bluetooth Mesh compliance. I would just make sure to focus on the security aspect, as a subnetwork key will give access to the network layer of the sub network.

2) By node IDs, are you referring to the unicast addresses that are provided to the nodes in the nRF Mesh app for example?

I would strongly recommend to take a look at Section 3.10.2 & 3.10.4 from the Mesh Profile Spec. These two sub-chapters explain temporary guest access & the key refresh procedure when a guest node is e.g. removed from the network. That way, the keys that are no longer used by the guest device are essentially thrown away.

gsegment said:

So when guest has been provisioned and later leaves, how we can handle >16 bit IDs acquiring?

 I believe this will be similar to when a node leaves the mesh network. Are you referring to the unicast address again with the >16 bit IDs? Are you wondering what happens to the unicast addresses that were given to the guest networks?