RE: BT Mesh IV Update Parameters / Timers

Elfving — Fri, 22 Oct 2021 11:15:25 GMT

Hey Damij!
I have gotten a little bit more info about some of the details in your case, in case it is helpful:

- The nodes stopping and starting all of a sudden might be because those nodes wait until iv recovery timeout expires to run IV Index Recovery procedure: https://github.com/NordicSemiconductor/nRF5-SDK-for-Mesh/blob/master/mesh/core/src/net_state.c#L245. You may try to reduce NETWORK_MIN_IV_RECOVERY_INTERVAL_MINUTES or even set it to zero for debugging purposes so that a node won't wait for timeout to run the IV Index Recovery procedure.

-When increasing the flash block size number, you need to have a look at NETWORK_MIN_IV_UPDATE_INTERVAL_MINUTES parameter. The node will still try to use the same IV Index for the specified time: https://github.com/NordicSemiconductor/nRF5-SDK-for-Mesh/blob/master/mesh/core/src/net_state.c#L164. For debugging purposes, you may enable the IV Update Test Mode: https://github.com/NordicSemiconductor/nRF5-SDK-for-Mesh/blob/master/mesh/core/src/net_state.c#L661, which will force a node to move to the IV Update in Progress state if the node is going to run out of seqnums.

- IV_UPDATE_TIMEOUT_PERIODIC_SAVE_MINUTES is used to store the iv update timeout with the defined regularity so that after the boot-up a node can recover the timer that will move it to IV Update in Progress state. This parameter can be reduced, but this may increase the wear of the flash.

Best regards,

Elfving

RE: BT Mesh IV Update Parameters / Timers

Elfving — Thu, 14 Oct 2021 14:10:54 GMT

Hey Domij! Sorry about the delay.

Could you tell me more about this project? Are there more nodes in the network? With the nodes being offline that much it might be that mesh isn't the best solution for you.

[quote user=""]In general the setup works well. However after some seemingly random time of a few days/weeks one or multiple sensors randomly stop transmitting. Then it takes a few hours up to a few days until the nodes by themselves are able to transmit again. To me, that sounds like the IV update is not working as required.[/quote]

In what way would you say it isn't working as required? An IV update can take between 96-144 hours, and I would assume closer to 144 if the nodes are turning off and on frequently. So to me it seems that it might work the way it is meant to.

[quote user=""]

We increased the flash block size number to reduce strain on the flash:

[/quote]

In general that might postpone the issue, but also push it forward (and in your case extremely much so). Increasing the block size is a double edged sword, in that a higher value will give you a longer time until you would need to write to flash, though a bigger jump on reboot. On reboot you wouldn't know where to start the sequence number after all, so you start on the next block. Which is presumably what your nodes are doing on every reboot. This is a problem in and of itself, though increasing the block size will make that jump even longer and the need for an IV update even faster.

[quote user=""]What happens when a node runs out of sequence numbers when it has not yet updated the IV?[/quote]

I am little bit uncertain about what concretely happens in our stack, though the node won't be able to send messages until the IVI Update is finished.

[quote user=""]We overwrote the intervals specified in the net_state.c. Because our devices typically only stay on for maximum 12h at a time, we never reach the required 144h/192h timer values. [/quote][quote user=""]

Are those timer values stored in flash at some stage or do they restart from 0 after a reboot?

[/quote]

I don't think they are stored in flash. If they aren't then this sounds like a problem. I will have to get back to you on that. Though I should mention that when you change these definitions, besides what is in the application, you also move away from the Bluetooth spec.

[quote user=""]

What exactly is the IV update timeout?

[/quote]

This seems to be a way that the IV update progress is being stored, so this timer is being stored atleast.

[quote user=""]

Could you please help me understand the 144h limit described in the mesh profile specification "3.10.5 IV Update procedure":

[/quote]

It is the maximum time for it be in IV Update state. I think they justified it as being 96*1.5, not to match a specific number but so that it statistically turns out to work well.

[quote user=""]What would be an appropriate setting for the NETWORK_MIN_IV_RECOVERY_INTERVAL_MINUTES?[/quote]

The standard 30minutes sounds good, though for your situation I'd understand if you would want it more often.

Best regards,

Elfving