Doubt with IV Index and sequence number

Hello,

I am working with a Bluetooth Mesh network where a master node (antenna) is in charge of setting up and managing the network of nodes. This master node also deploys a web server and an embedded system that allows to send commands to the nodes.

My goal is to be able to replace the master node in case of failure, connecting another one with the same key and performing exactly the same function, keeping the network intact and operational. That is, if the master node fails, I can replace it without losing the network or its functionality, and the new node that I incorporate will take the place of the previous one, as if nothing had happened.

The problem I encounter is related to the IV index and the sequence number. I understand that each message in the Bluetooth Mesh network includes an IV Index and a sequence number, which act as a counter to ensure security and avoid repeated messages. If the master node fails and I have no way of knowing the IV Index of the network and the sequence number that this master node was going by, when I connect a new master node that will have to be connected to the network. 
If the master node fails and I have no way of knowing the IV index of the network and the sequence number by which this master node was going, when connecting a new master node to replace it, it would need the IV index to be the same of the network and the sequence number to be at least greater than the last one handled by the previous master node. Otherwise, messages sent from this new node will not be accepted by the existing nodes in the network, as they expect a different IV Index and/or a sequence number higher than the last one used by the previous master node.

One option I had explored was to persist these two values in the master node. But the fact of being able to replace the antenna I want to do it in case the node breaks down (the micro). That is, I want to be able to replace it in case at some point, the node stops offering the slightest functionality. Therefore, persisting this data in the node itself, is not a valid option in this case.

I have investigated and understand that:

When a node joins an existing network, it must synchronize its IV Index with that of the network in order to communicate properly.

If a node has an outdated IV Index, it can listen to Secure Network Beacons containing the current IV Index and perform a recovery procedure to update its value.

Given this, my questions are:

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?

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?

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)?

What practices do you recommend to ensure network continuity in case of master node failure, especially regarding IV Index, sequence number and node synchronization?

I thank you in advance for your help and guidance on this subject.

Best regards.

Parents
  • Hi,

    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?

    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.)

    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?

    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.

    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)?

    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.

    What practices do you recommend to ensure network continuity in case of master node failure, especially regarding IV Index, sequence number and node synchronization?

    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

Reply
  • Hi,

    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?

    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.)

    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?

    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.

    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)?

    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.

    What practices do you recommend to ensure network continuity in case of master node failure, especially regarding IV Index, sequence number and node synchronization?

    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

Children
No Data
Related