前言

本篇文章是SIG Mesh保护网络安全的一种机制之一，同时也是红旭无线SIG Mesh理论教程的收尾之作；本身这个机制是不需要应用层的用户去干预的，SIG MESH协议栈会根据自身的情况，自主地去触发并维护这个IV Index更新进程；但是，为了让开发者知其然而知其所以然，小编认为还是很有必要讲解一番。

为什么要IV Index更新

在讲解IV Index更新之前，就不得不提及Sequence Number；甚至我们可以认为IV Index就是专门用于Sequence Number的补充；不知道读者们还有没有印象，小编在BLE Mesh各层帧包格式详解中提及到的Network PDU，每个节点发送的Network PDU里都包含有一个SEQ字段，且每个新的Network PDU均会在此前SEQ的基础上加1；然而，SEQ只有24bits的长度，因此总会有用完的时候，这里Mesh Spec给出关于SEQ的相关数据可以参考，如下所示：

如果节点的元素以每5秒频率发送一包Network PDU，那么24bits长度的SEQ将只能持续2.6年，即2.6年之后SEQ就会增加到0xFFFFFF

因此，为了避免这种情况发生，专门又定义了一个IV Index用于补充SEQ长度不足；由于IV Index有32bits的长度，因此想要耗尽IV Index，需要花费5万亿年的时间，对于渺小的人类来说，这个时间已经足够用到地球毁灭了，这也是为什么要IV Index更新的原因；当然，IV Index除了这个作用之外，还用于SIG MESH网络中的应用层和网络层的认证加密；由于这个操作基本上由协议栈自动计算完成，无需应用层处理；因此这里不细述，想了解更多的详情可以参考 《Mesh Spec的3.8.5 Nonce》 章节内容；

IV Index Update Procedure

IV Index Update进程在小编看来，相较于密钥更新过程来说，这个操作还是相对比较简单的；其不需要专门的命令来触发这个动作，而是可以由MESH网络中任意一个节点发起；然而，这并不是表示可以随便进行IV Index Update Procedure，那么其又有什么要求呢？下面的几个章节将会一一讲解；但是，在讲解之前还是需要先了解下IV Index的两种状态：

Normal
Update

不同的IV Index状态，收发的Network PDUs中所携带的IV Index值是不一样的：

IV Index	IV Update Flag	IV UpdateProcedure State	IV Index Accepted	IV Index used when transmitting
n	0	Normal	n-1, n	n
m (m=n+1)	1	In Progress	m-1, m	m-1
m	0	Normal	m-1, m	m

为了让读者们更加直观地理解上述的表格，可以查看下述的框图 （小编这里以n = 4为例）：

什么时候触发

触发IV Index更新进程的条件，有如下两种：

条件1： 当Sequence Number接近用完时，就会触发节点发起IV Index更新进程；那么什么时候才算接近用完呢？Nordic的SDK则是这样处理即：
当Sequence Number大于等于(2^24-1)/2时，就会发起IV Index Update Procedure
条件2： 当IV Index Update Procedure计时器大于等于96小时时，就会触发IV Index Update Procedure

针对条件1，其中Sequence Number将近用完的阀值并不是强制非要一定这样，只是为了保守起见最好是一半；因为当节点处于IV Index更新状态，但是还未恢复到Normal状态之前，Sequence Number仍然还是在旧的基础上叠加，还仍未复位为0，需要一定的余量用于IV Index更新状态下时使用；至于为什么，参考下述的什么时候结束章节的内容；同时其仍然有96小时这个条件的限制，也就是说就算节点的Sequence Number已经达到设置的阀值，但此时的IV Index Update Procedure计时器仍然小于96小时，那么IV Index Update Procedure是不会执行的；然而，条件2则可以无视条件1的约束，这也间接地说明条件1是硬性的要求

什么时候结束

当节点进入到IV Index更新状态时，并不能马上回到Normal状态，其仍然需要在IV Index更新状态下运行至少96小时，才可以回到Normal状态了；但是，当运行大于等于144小时时，仍然还没有回到Normal的话，则要强制回到Normal状态；这也就是说每192小时只能发起一次IV Index Update （Normal->Update:96小时，Update->Normal:96小时）

如何处理

由BLE Mesh各层帧包格式详解可知，每个节点乃至节点的每个元素，其发送的Network封包中所携带的SEQ值均不一样，但是同一个SIG Mesh网络中的节点所使用的IV Index必须要统一；因此如果某个节点自身还未发起IV Index更新进程，就是说还未处于IV Index更新状态或者已经处于IV Index更新状态；但是其又接收到其他节点发送的IV Index更新的Secure Network Beacon，上述不同的情况，处理的方法也不尽相同：

如果当前节点处于Normal状态，接收到的Secure Network Beacon的IV Index大于节点本身IV Index + 1，且此时SNB携带的IV Update Flag等于1时 （例如接收到的SNB所携带的IV Index是3,IV Update Flag为1，而节点此时的IV Index是0，那么3>(0+1)），则该节点应执行IV Index Recovery Procedure
如果当前节点处于Normal状态，接收到的Secure Network Beacon的IV Index大于节点本身IV Index，且此时SNB携带的IV Update Flag等于0时 （例如接收到的SNB所携带的IV Index是1，IV Update Flag为0，而节点此时的IV Index是0，那么1 > 0)），则该节点应执行IV Index Recovery Procedure
如果当前节点处于Normal状态，接收到的Secure Network Beacon的IV Index等于节点本身IV Index + 1，且此时SNB携带的IV Update Flag等于1时 （例如接收到的SNB所携带的IV Index是1，IV Update Flag为1，而节点此时的IV Index是0，那么1 ==(0+1)），则该节点应执行IV Index Update Procedure
如果当前节点处于IV Update状态，接收到的Secure Network Beacon的IV Index等于节点本身的IV Index，且此时SNB携带的IV Update Flag等于0时 （例如接收到的SNB所携带的IV Index是1，IV Update Flag为0，而节点此时的IV Index是1，那么1 == 1），则该节点应回到Normal状态，并将Sequence Number重置为0；但是这个回到Normal状态的动作，仍然受96小时的限制；这也就是说节点也必须要在IV Update状态下待够96小时，否则无法回到Normal状态，相关的内容在上述的什么时候结束章节也有提及

除了上述的这些不同的处理情况，仍然有如下两个情况小编觉得应该有所了解：

如果节点发送了分段的Access or Control Message, 其还没有收到分段应答；那么此时执行IV Index Update --> IV Index Normal转换，就应该临时暂停，需要等到分段应答收到或者应答超时了，方可进行转换
当SIG Mesh网络处于Normal状态时，此时有新的设备加入这个网络，那么新加入的节点仍然存于Normal状态并使用当前MESH网络的IV Index值
当SIG Mesh网络处于Update状态时，此时有新的设备加入这个网络，那么新加入的节点却是处于Normal状态，并使用新的IV Index值

实例

针对上述如何处理的场景3，下图是该情况的实例㧓包：

从上图我们可以看到，F6:84:BE:AB:05:BE节点是处于Normal状态且其当前的IV Index是1，当它接收到D4:6A:02:F2:A2:B4节点携带IV Index等于2的SNB消息时，F6:84:BE:AB:05:BE节点立马发起IV Index Update Procedure，IV Index值摇身一变就也变成2了并处于IV Index更新状态，这个与我们在上面的场景3所说的是完全吻合的；

针对上述如何处理的场景4，下图是该情况的实例㧓包：

同样的，从上面的图中可知：F6:84:BE:AB:05:BE节点是处于Update状态且其当前的IV Index是4，当它接收到D4:6A:02:F2:A2:B4节点携带IV Index等于4的SNB消息时，F6:84:BE:AB:05:BE节点立马发起IV Index Update Procedure，IV Index值摇身一变就也变成4了并处于IV Index Normal状态，而且我们还可以看到此时F6:84:BE:AB:05:BE节点发的第一包Network PDU的Sequence Number为0，这个与我们在上面的场景4所描述的是完全吻合的；

针对上述如何处理的场景2，下图是该情况的实例㧓包：

从上图可知：F6:84:BE:AB:05:BE节点是处于Normal状态且其当前的IV Index是4，当它接收到D4:6A:02:F2:A2:B4节点携带IV Index等于6且IV Update Flag为Normal的SNB消息时，F6:84:BE:AB:05:BE节点立马发起IV Index Recovery Procedure，这个与我们在上面的场景2所描述的是完全吻合的；

针对上述如何处理的场景1，下图是该情况的实例㧓包：

从上图可知：F6:84:BE:AB:05:BE节点是处于Normal状态且其当前的IV Index是8，当它接收到D4:6A:02:F2:A2:B4节点携带IV Index等于10且IV Update Flag为Update的SNB消息时，F6:84:BE:AB:05:BE节点立马发起IV Index Recovery Procedure，这个与我们在上面的场景1所描述的是完全吻合的；

IV Index Recovery Procedure

相较于上述的IV Index Update Procedure，IV Index Recovery Procedure主要是让那么错过IV Index Update或者当前携带的IV Index值远远小于当前正在正常运行的SIG MESH网络中的IV Index值：例如，某个节点在MESH网络进行IV Index更新时，此时它掉线或者断电了，又或者某个节点不知何故断电了，导致长时间没能跟SIG MESH的其他节点进行互动；这些情况均会触发IV Index Recovery Procedure；

什么时候触发

至于IV Index Recovery Procedure什么时候被触发，可以参考上述的如何处理

什么时候结束

IV Index Recovery Procedure跟IV Index Update Procedure不一样，前者触发并执行完了就结束了，而后者仍然需要运行至少96小时，出现这样的差异是完全符合逻辑的；前者主要是节点的IV Index值落后于当前正在正常运行的MESH网络的IV Index值，通过IV Index Recovery Procedure之后，落后的节点又重新恢复与当前MESH网络的节点进行数据交互，而后者是一方面是通知SIG MESH网络的所有节点，赶紧更新你们的IV Index值提供足够多的时间，另一方面对节点发起IV Index Update Procedure进行限制，否则就打脸上述为什么要IV Index更新章节中提到的IV Index值可以用到地球毁灭了；

如何处理

IV Index Recovery Procedure也是有条件约束的，即当接收到的Secure Network Beacon的IV Index大于节点本身IV Index + 42时，该SNB将被丢掉不做任何处理；而且当节点已经通过IV Index Recovery Procedure恢复了IV Inex值之后，也需要保持192小时，换句话就是说 “在192小时内只能执行一次IV Index Recovery Procedure”；除此之外，我们还应该关注Low Power Node这样的节点是如何处理这个IV Index Recovery Procedure？由于它们基本上是电池供电的设备，不太可能时时地获取Secure Network Beacon或者Friend Update消息，那么针对上述的情况，存在以下几种可能：

如果LPN的IV Index值落后于当前正常运行的SIG MESH网络的IV Index值，那么其可以从Friend Node的Friend Update信息中获取得到最新的IV Index值，也就是说在96小时内LPN至少需要向Friend Node发起一次Friend Poll消息来获取新的IV Index值 （前提是：此时与Friend Node的友谊关系还未中止且Friend Node仍处于IV Update状态）
由于LPN断电或者异常，导致其当前的IV Index值落后于当前正常运行的SIG MESH网络的IV Index值且同Friend Node的建立的关系也已经终止，这个时候如果Friend Node已经回到Normal状态，那么此时LPN就永远不可能再与此Friend Node建立关系了，因为此时Friend Node发出的Network PDU所携带的IV Index值已经是LPN的IV Index加1了，具体的逻辑关系可以参考上述的IV Index Update框图；因此，此时想要LPN重新回到这个SIG Mesh则需要监听当前SIG MESH网络的Secure Network Beacon，但是这样就造成LPN的耗电量急剧上升，这里小编借助Spec中描述的条件为例：
以每10秒发送一次SNB为例，那么LPN就至少需要监听5秒的SNB消息，从而恢复至当前网络最新的IV Index
如果真的遭遇这种情况，要么由用户干预，要么就持续监听5秒的SNB消息

实例

针对上述的IV Index Recovery Procedure的场景1，下图是该情况的实例㧓包：

从上图可知：F6:84:BE:AB:05:BELPN处于Normal状态且其当前的IV Index是0，当它接收到D4:6A:02:F2:A2:B4节点携带IV Index等于1且IV Update Flag为Update的Friend Update消息时，F6:84:BE:AB:05:BE节点立马发起IV Index Update Procedure，当D4:6A:02:F2:A2:B4节点回到Normal状态时，F6:84:BE:AB:05:BELPN也回到Normal状态，当F6:84:BE:AB:05:BELPN再次发送Network PDU时，IV Index值已经变为1了，这个与我们在上面的场景1所描述的是完全吻合的；至于上述的场景2跟上述的IV Index Update Procedure实例是基本一致的；