Incorrect CCCD configured by nRF Mesh App on Android

[Srikkanth]

Hi,

It looks like the nRF Mesh App on Android configures incorrect CCCD when an unprovisioned device exposes both Provisioning and Proxy Service in its GATT Database.

Though according to Mesh 1.0 spec the "unprovisioned" device "shall" not expose both Provisioning and Proxy services, the nRF mesh App should also write to provisioning Data out CCCD of the unprovisioned device. The nRF mesh App on iOS seems to be doing this where as on Android it writes to the Proxy CCCD(The last encountered CCCD in Discovery process).

To observe this behavior, one could run the "MESH/CL/PROX/BV-01-C" testcase from PTS 7.2.1 or PTS 7.3.0 where PTS is the Node and Client is nRF mesh Android App.

From inter-operability point of view, there could be many available mesh devices which exposes both the services and this behavior seems to be a blocker on Android.

Regards,

Srikkanth

[Roshan Rajaratnam]

Hi Srikkanth this is the intended behavior from the app's point of view. What you are mentioning is not a blocker but a requirement of the specification. You will find this on the chapter 7 of the mesh specification, and it states that "A device may support the Mesh Provisioning Service or the Mesh Proxy Service or both. If both are supported, only one of these services shall be exposed in the GATT database at a time." Based on this we would be violating the spec if both services are exposed in the GATT Database at a time.

Hope this helps. 

Roshan

[Srikkanth]

Hi Roshan,

I do agree that this is not a blocker and also to the fact that it is a spec violation if both services are exposed.
I'm just trying to analyze from an IoP point of view about devices that do expose both the services. One example as suggested above is the PTS tool itself(again, I do agree that there is a greater possibility of PTS correcting it in later version).
What I'm trying to suggest is that if there can be a different mechanism to arrive at the assignment of "isProvisioningComplete" as "True" in the isRequiredServiceSupported(...) routine? Something like maintaining the UUID of the unprovisioned device and checking if its already provisioned etc.
Not sure if maintaining device BLE address would work as there could be devices which are using RPA but not support SMP/Bonding to share the IRKs!

Again, its not a blocker its pondering the possibility of an attempt to be lenient on non compliant[with respect to GATT services] devices!! Especially because BLE spec's ATT or GATT does not impose rules of dynamic exposure/visibility of services :)