RE: Doubt with IV Index and sequence number

tesc — Tue, 13 May 2025 11:50:34 GMT

Hi,

[quote user=""]Is the way to retrieve the current IV Index from the network to be able to manually configure it on a new master node in case of replacement, is it through the Secure Network Beacons? How could it be done?[/quote]

The IV Update, where the network moves from one IV Index to the next, is a time consuming process of at least 96 + 96 hours to do the full cycle. If you replace the node early enough, when the IV Update is in progress, the replacement would automatically take part of the IV Update. This assuming that the IV Index of the replacement is the IV Index which the network is transitioning away from at the moment.

If the IV Index of the replacement is lagging behind by less than 42, the replacement will automatically, when getting the secure beacon with the current IV Index, initiate the IV Recovery Procedure.

Thus, IV Index should not be an issue, provided that you backup the IV Index at least once every 336 days or so, which is the maximum rate at which an IV Index can fall out of the 42 wide interval range for allowing IV Recovery.

If the IV Index is more than 42 behind the current one, IV Recovery is not possible (by spec) and the node must be reprovisioned into the network (appearing as a new device.)

[quote user=""]Is it possible to force the new master node to listen to the Secure Network Beacons and update its IV Index automatically to the current network value?[/quote]

This will already happen if lagging behind by 42 or less in IV Index.

Please note that the mechanisms regarding IV Index, which I have described above, are first and foremost for the scenario of a node being turned off or otherwise removed from the network, for a prolonged period of time. While the IV Index mechanisms might make it easier to replace a node the way you draft in your question, there is still the issue of sequence number, which is not easily read out from the node.

[quote user=""]How could it handle the sequence number so that it could replace the master node and have its messages listened to by all other nodes (i.e., load a valid sequence number)?[/quote]

The best practice for this would be not to replace the node (including address and sequence number), but rather to provision the replacement master device into the network as a new node (with new unicast addresses.)

Bluetooth mesh is made with this in mind: Instead of addressing messages to unicast addresses directly, it is encouraged to use group addresses (or for some use cases virtual addresses). The way it works, is that the node sending messages publish to a group (or virtual) address, and the node or nodes receiving messages subscribe to that same group (or virtual) address. Thus, in order to replace one node in the network, you only have to provision the new node into the network and set up the publications and/or subscriptions on that node, so that it inherits all roles and functionality of the old node.

In your example with a "master node", the preferred way to solve that would be to reserve a group address for the master node, and when installing the master node (or replacing it) to configure the models of the master node to subscribe to that group address. Then all other nodes can publish messages to the master node regardless of it being original or replacement, using the designated group address, without reconfiguration of any remaining node in the network.

[quote user=""]What practices do you recommend to ensure network continuity in case of master node failure, especially regarding IV Index, sequence number and node synchronization?[/quote]

If the master node acts as provisioner and/or configurator, then I would make sure to backup the configuration database from that device, or keep the configuration database (or information therein) at a backup location. This would be information about some or all other nodes on the network, such as the Device Keys for configuring them, their unicast addresses, and so on. For instance, nRF Mesh for iOS/Android has functionality for exporting and importing the configuration database, so that one smartphone can seamlessly take over for a different smartphone by copying the configuration database over from the former to the new smartphone.

Regards,
Terje