BT Mesh secure beacon propagation speed during IV update

[tmennink]

I have a question about propagation speed of the secure network beacon over a bluetooth mesh networks.

Last year we installed a mesh network consisting of 1750 light fixture each with a NRF52840 bluetooth mesh node. These lights are dimmable, and arranged in a total of 60+ groups. There is an edge device with a nrf52840 dongle that controls the dimming setting of all the groups, this one transmits somewhere between 20.000 and 100.000 messages per day. This is a higly dynamic installation where our lights compensate for fluctuations in natural daylight, so the dim levels throughout the facility fluctuate all the time.

This has been running flawless for many months, however the transmitting node is close to reaching the sequence limit and it will start the IV update procedure. This will involve propagating a secure network beacon throughout the network signaling the update procedure state should be entered. Once this has been done, as I understand it, one of the nodes in the network will increment its IV and switch to normal mode. This node will transmit a secure beacon with the incremented IV and "normal mode", triggering immediate increment of the IV index by all the nodes receiving that secure beacon.

I was wondering, how soon will those nodes also start relaying the secure network beacon? And will they be competing with surrounding nodes transmitting the old IV index beacon? As I understood each node strives towards making sure there is a beacon approximately every 10 seconds, so if it does not see one for more than that, it will transmit it's own. Will a node that has already increased its IV index, see an old beacon and transmit the new beacon faster to make sure it will "win"?  Or is it a matter of change which nodes win, irrespective if they have an old or new beacon, and will it just be a matter of luck before all nodes have finally seen the new beacon?

[Hieu]

Hi tmennink,

My sincerest apology for the long wait. I have not had the productivity necessary.

Your accidental answer verification has been undone.

I will now answer your questions with reference to the Mesh Profile Specification v1.0.1.

I was wondering, how soon will those nodes also start relaying the secure network beacon?

From Section 3.10.5, page 130:

A node that is in Normal Operation state that receives and accepts a Secure Network beacon with the IV Update Flag set to 1 (indicating the IV Update in Progress state) should transition to the IV Update in Progress state as soon as possible.

And will they be competing with surrounding nodes transmitting the old IV index beacon? As I understood each node strives towards making sure there is a beacon approximately every 10 seconds, so if it does not see one for more than that, it will transmit it's own. Will a node that has already increased its IV index, see an old beacon and transmit the new beacon faster to make sure it will "win"?  Or is it a matter of change which nodes win, irrespective if they have an old or new beacon, and will it just be a matter of luck before all nodes have finally seen the new beacon?

Firstly, it is not that a node that strives to transmit a Secure Network Beacon (SNB) every 10 seconds. The network as a whole strives to have a beacon approximately every 10 seconds based on calculation. Thus, the calculation might result in a much larger time between when two consecutive time a node transmitting a SNB (a computed Beacon Interval). 

From Section 3.9.3.1, page 123:

The expected behavior is that each node receives one beacon for a given subnet approximately every 10 seconds.
...
If the computed Beacon Interval is less than 10 seconds, it should be set to 10 seconds. If the computed Beacon Interval is greater than 600 seconds, it should be set to 600 seconds.

Secondly, there is no issue with competition. Even if coincidentally two or more nodes on far ends of the network start the IV update procedure at the same time, they will strive for the same thing, and won't conflict.

When a node, which has updated its IV Index, receives the IV Update SNB with the same IV Index, it will simply not change anything. 

If you wish to know the details of the spec, here are the relevant sections:

3.9.3: Secure Network Beacon
3.9.3.1: Secure Network Beacon Behavior
3.10.5: IV Update procedure
3.10.5.1: IV Update procedure test
3.10.6: IV Index recovery procedure

Once again, I apologize for the late answer. Please don't hesitate to let me know if anything is still unclear.

Best regards,

Hieu

[tmennink]

Hi Hieu,

Thank you for your answer. Meanwhile I also did some research, this is what I was able to find out:

The zephyr code that handles the beacon timing is deterministic, it follows a couple of rules to determine if it should send a beacon itself or wait to receive one. It's the Zephyr implementation of what you describe.

What I was fearing, and what seems to be confirmed by the simulation, is that quite quickly a sort of oscillating pattern arises where only a handful of nodes are sending out beacons approximately every 10 seconds, while all other nodes never take a turn because the cadence of the beacons they receive from that handful of nodes will never trigger them to send out a beacon themselves. I've also seen this during testing with two dongles: The one that is the first to send out the first beacon, will continue to do so, the other one never sends a beacon. (for 600 seconds, that is).

In my simulations I see that without any extra rules,  it is possible that a node that went into IV update mode, sends out a beacon once, but this only propagates to a small group of nearby other nodes. Luckily there is the rule of no more than 600 seconds between beacon transmissions for any node, and this will eventually force every node to send out a beacon. The only "bad" thing that can happen is, if you turn on the entire network all at once, all those nodes will reach their 10 minute limit at approximately the same time. This might cause a large burst of beacons coming all at the same time.

This is the link to the line of code that is responsible for the node sending out a beacon or not.

github.com/.../beacon.c

But anyhow, it seems we don't have to worry that an IV update gets stuck in a small part of the network, it will be forced to propagate everywhere. I expect this to happen over the course of about 4 hours maximum.

[Hieu]

Hi tmennink,

tmennink said:

Luckily there is the rule of no more than 600 seconds between beacon transmissions for any node, and this will eventually force every node to send out a beacon. The only "bad" thing that can happen is, if you turn on the entire network all at once, all those nodes will reach their 10 minute limit at approximately the same time. This might cause a large burst of beacons coming all at the same time.

[...]

But anyhow, it seems we don't have to worry that an IV update gets stuck in a small part of the network, it will be forced to propagate everywhere. I expect this to happen over the course of about 4 hours

Yes, I share the same conclusion as you. If you calculate that it will be done in about 4 hours, then that would be all right. As noted in Section 3.10.5, still in the Mesh Profile Specification v1.0.1, a node must go into IV Update In Progress at least 96 hours before the sequence numbers are exhausted. The update thus will complete in time.

tmennink said:

What I was fearing, and what seems to be confirmed by the simulation, is that quite quickly a sort of oscillating pattern arises where only a handful of nodes are sending out beacons approximately every 10 seconds, while all other nodes never take a turn because the cadence of the beacons they receive from that handful of nodes will never trigger them to send out a beacon themselves.

Is there still a concern about this? Are you worried that the update will not propagate across the network in a short enough time, or is it about something else?

[tmennink]

Hi

The process is clear now. Although there also are some slight differences between different SDK versions, we have started the IV update process in our test network, and things should be finished by next week.