IV index update procedure for mobile application

[ivnn]

Could you pls explain what to do in the following case:
The mobile app was inactive for some time and the IV index of the network went high for example 3, but the mobile was offline and stayed with an IV index = 0.
I have checked mobile is still able to connect to mesh but all the commands are rejected.
The question is what mobile should do to restore the right IV index?
Thanks for your support tesc 

[tesc]

Hi,

Is this your own app? The nRF Mesh app should do the IV Index Recovery procedure automatically, when detecting it is lagging behind in IV Index.

Regards,
Terje

[ivnn]

Yes it’s own app, could you please advise the process which flow app should start when iv network index is different?

thanks

[tesc]

Hi,

I will check internally if we have any libraries or guidance for this. Is your app for Android or for iOS, and are you using any of our Android libraries for it (if so which ones)?

Regards,
Terje

[ivnn]

Both platform, nrf mesh lib

If it’s possible pls share your approach 

thanks

[Aleksander Nowakowski]

Hello,

Both Android and iOS apps support IV Update procedure. The first thing which the apps receive after connecting to Proxy Node is a Secure Network beacon or a Private Mesh beacon, which contain the current IV Index. The app then checks the timestamp of the last IV Index update and verifies, that it is possible, that the IV Index got incremented by that many. Each "step" takes 96h, that is it must take at least 96h for the IV Index to get updated from index N (normal operation) to index N+1 (update active) and from N+1 (update active) to N+1 (normal operation), 192h together. The apps also support IVUpdate Test Mode, where this time can be decreased by 96h (but not more).

If you test IV Update, do the following:

1. Set up a network.
2. Enable IV Update Test mode on all nodes under test + on the mobile apps.
3. Trigger IV Update byu 1 step (normal -> active or active -> normal) on one of the nodes (apps can't initiate update procedure).
4. Wait until the information is distributed to ALL nodes, including mobile apps. The apps should receive a beacon with updated value and should change internal state.
5. With IV Update Test mode, all nodes should accept the new IV value and should start sending/receiving messages accordingly.
6. Repeat states 3-5 to increment IV by more values.

It is not possible to join a network after it went through such test procedure for nodes (including apps) that have not been a part of it, or required time didn't pass. E.g., you can't connect to a Proxy node which IV was updated by Y without waiting Y*96h, or (Y-1)*96h with IV Test mode enabled.

If a node joins a network after a long time, during which the IV Index has increased by some value, the apps will accept the new IV value assuming the time was long enough. This is called IV Recovery Procedure. There's also a max limit of the IV Index value to recover: 42. Nodes should exchange messages with the network at least that often, so the IV value increment is smaller. Our nRF Mesh libraries allow to override this restriction by setting a flag in network parameters (but it is not set in the nRF Mesh apps).

There's also a way to "workaround" IV issues when using nRF Mesh apps:

1. Have a network, which went through IV Test procedure and IV Index got updated in a shorter time than necessary for it to be accepted.
2. Export mesh network configuration to a json file (this file will not have IV Index information).
3. Erase app's settings - this will effectively forget all stored indexes AND sequence numbers.
4. Import saved network.

After importing and reconnecting the network the app will accept ANY Secure Network beacon/Private Mesh beacon and will set the current IV Index value to received authenticated value. They can't verify it in any way, so they assume it's valid.

If the IV Index was incremented by less than 2 it may be required to change the phone's Unicast Address, as other nodes may ignore messages sent with sequence numbers reset to 0. If the IV incremented by 2+, the SeqAuth will be higher than the values in RPL anyway, so no need to do this.