Understanding IV Index Recovery in Bluetooth® Mesh (with esp-idf)
Michael Bertel |
TL;DR
If some of your Bluetooth® Mesh nodes are offline or join later, they might miss an IV Index update and then can’t talk to the rest of the network anymore.
ESP-IDF only auto-recovers when the IV Index difference is 2 or more (to avoid accidental updates).
If your use case needs automatic recovery even with a +1 difference of the iv-index, you must enable CONFIG_BLE_MESH_IVU_RECOVERY_IVI—otherwise, you risk broken communication.
In a project where I wrote the embedded software, we used Bluetooth® Mesh to handle the communication between nodes.
The development went very well but we had some major issues after shipping the product as the Bluetooth® Mesh seemed to stop working after a random time.
We debugged and ended up reprogramming all the devices. Everything worked well until a random time, and so on.
If you use the Bluetooth® Mesh yourself (or plan to do so) and have issues with the iv index - this blog may help you.
Disclaimer: All the information you need is probably in the official Mesh Profile Specification of Bluetooth®!
This is just a brief blog post which would have helped me when handling these problems.
Dev-Stack:
- Bluetooth® Mesh
- esp32c3 with esp-idf
What is the IV Index?
The IV Index is a 32-bit value that is a shared network resource (i.e. all nodes in a mesh network share the same value of the IV Index and use it for all subnets they belong to).
You can think of it like a shared "version number" for the entire network that makes sure all nodes are speaking the same encrypted language.
So basically all nodes in one network should work with the same iv index. After some time (i.e. when the node believes it is at risk of exhausting its sequence numbers) one node decides to perform an iv index update.
Each time a message is sent in the mesh, it also uses a sequence number (like a message counter). Together with the IV Index, this sequence number helps create a unique "key" for the message encryption.
However, sequence numbers have a limit (24 bit). Once they are at risk to become too high, the network needs to increase the IV Index to prevent reusing the same encryption data. This process is called an IV Update.
In short:
The IV Index keeps your Bluetooth® Mesh network in sync and secure. It ensures that messages remain unique and protected over time.
What we did wrong
In our use case it might happen that nodes are offline or might join the mesh later. So not all nodes are active at the same time.
Therefore it might happen that an iv index update gets missed by a node. In which case the node can no longer communicate with the rest of the network.
Obviously there is a solution for this in the reference: the IV Index Recovery procedure.
The +1 Gap in Bluetooth® Mesh (IV Index Recovery Procedure)
But there is a small problem: the “+1 gap”.
By default the esp-idf implementation only performs the Recovery procedure when the iv-index gap is ≥ 2.
This is to stop the node from updating too soon by accident, but in my case it caused a massive problem in production.
To change this behaviour you need to activate the config CONFIG_BLE_MESH_IVU_RECOVERY_IVI.
> Recovery the IV index when the latest whole IV update procedure is missed
This option must be enabled so that a device that misses an IV index update automatically catches up – even if the difference is only +1. Without this option, IV recovery only occurs when the difference is +2 or greater, which leads to one-sided communication.