Bluetooth Mesh 仕様 – 3. Mesh networking（その６）

はじめに
1. 3.9 メッシュビーコン
2. 3.10 メッシュネットワーク管理

はじめに

Bluetooth Meshの仕様について、Bluetooth SIGで公開されている「Mesh Profile Specification 1.0.1」に基づき、学習を兼ねて記載して行こうと思っています。本文章では、3章の「メッシュネットワーキング」の次の節について記載いたします。

3.9 メッシュビーコン
3.10 メッシュネットワーク管理

記載内容に誤り等がありましたら、ご連絡いただければ幸いです。

3.9 メッシュビーコン

メッシュビーコンは、ノードおよびプロビジョニングされていないデバイスによって定期的にアドバタイズされるパケットです。

メッシュビーコンは、«メッシュビーコン» AD タイプに含まれています。メッシュビーコンアドバタイズデータペイロードの最初のオクテット（[ビーコンタイプ]フィールド）は、ビーコンのタイプを決定します。メッシュビーコンは、プロキシプロトコルを使用して他のベアラに転送されます（セクション 6 を参照）。

メッシュビーコン AD タイプのフォーマットを図3.44 に示します。

ビーコンタイプの値は表3.52 で定義されています。

値	定義
0x00	プロビジョニングされていないデバイスビーコン
0x01	安全なネットワークビーコン
0x02 – 0xFF	将来の使用のために予約済み

表3.52：ビーコンタイプの値

メッシュビーコンは、接続不可およびスキャン不可の無向アドバタイジングイベントでアドバタイズされます。

3.9.1 エンディアン

セクション 3.1.1.1 で説明されているように、メッシュビーコンのすべてのマルチオクテット数値は「ビッグエンディアン」で送信されるものとします。

3.9.2 プロビジョニングされていないデバイスビーコン

プロビジョニングされていないデバイスビーコンは、プロビジョナーが検出できるように、プロビジョニングされていないデバイスによって使用されます。
このビーコンのフォーマットを図3.45 に示し、表3.53 で定義します。

フィールド	サイズ（オクテット）	説明
ビーコンタイプ	1	プロビジョニングされていないデバイスビーコンタイプ（0x00）
デバイス UUID	16	このデバイスを一意に識別するデバイス UUID （セクション 3.10.3 を参照）
OOB 情報	2	表3.54 を参照
URI ハッシュ	4	URI AD タイプでアドバタイズされた関連 URI のハッシュ（オプションのフィールド）

表3.53：プロビジョニングされていないデバイスのビーコンのフォーマット

表3.54 に示されている OOB 情報フィールドは、デバイスの公開鍵などの OOB データの可用性を示すことにより、プロビジョニングプロセスを推進するために使用されます。

ビット	説明
0	その他
1	電子/ URI
2	2D 機械可読コード
3	バーコード
4	近距離無線通信（NFC）
5	数字
6	文字列
7	将来の使用のために予約済み
8	将来の使用のために予約済み
9	将来の使用のために予約済み
10	将来の使用のために予約済み
11	On box
12	Inside box
13	On piece of paper
14	内部マニュアル
15	On device

表3.54：OOB 情報フィールド

プロビジョニングされていないデバイスビーコンに加えて、デバイスは、公開鍵のような帯域外（OOB）情報を指す Uniform Resource Identifier（URI）データ型（ [7] で定義）を使用して、接続できない個別のアドバタイズパケットをアドバタイズする場合もあります。アドバタイズされた URI とプロビジョニングされていないデバイスビーコンの関連付けを可能にするために、ビーコンにはオプションの 4 オクテット URI ハッシュフィールドを含めることができます。

URI ハッシュフィールドの値は、次の式を使用して計算されます。

URI ハッシュ= s1（URIデータ）[0-3]

URI データは、[7] で定義されているように、Uniform Resource Identifier（URI）データ型を含むバッファーです。

3.9.3 セキュアネットワークビーコン

セキュアネットワークビーコンは、サブネットとそのセキュリティ状態を識別するためにノードによって使用されます。

このビーコンのフォーマットを図3.46 に示し、表3.55 で定義します。

フィールド	サイズ（オクテット）	説明
Beacon Type	1	セキュアネットワークビーコン（0x01）
Flags	1	キー更新フラグとIV更新フラグが含まれています
Network ID	8	ネットワーク ID の値が含まれています
IV Index	4	現在の IV インデックスが含まれています
Authentication Value	8	セキュリティネットワークビーコンを認証します

表3.55：セキュアネットワークビーコンフォーマット

Flags フィールドは、表3.56 で次のように定義されています。

ビット	定義
0	Key Refresh Flag 0: False 1: True
1	IV Update Flag 0: Normal operation 1: IV Update active
2 – 7	将来の使用のために予約済み

表3.56：フラグフィールドの定義

Network ID フィールドには、このネットワークの Network ID が含まれます。

IV Index フィールドには、このメッシュネットワークの現在の IV Index が含まれます。

Authentication Value フィールドは、次のように計算されます。

Authentication Value = AES-CMACBeaconKey (Flags || Network ID || IV Index) [0–7]

セキュアネットワークビーコンの生成を図3.47 に示します。

3.9.3.1 セキュアネットワークビーコンの動作

セキュアネットワークビーコンが既知のサブネットで受信され認証されると、ノードは IV インデックスの更新（セクション 3.10.5 を参照）およびキーの更新手順（セクション 3.10.4 を参照）を監視する必要があります。セキュアネットワークビーコンを認証するために、ノードはセクション 3.9.3 で定義されているように認証値を計算し、受信したセキュアネットワークビーコンのAuthentication Value フィールドと等しいかどうかをチェックします。

セキュアネットワークビーコンは、ノードがメンバーであるサブネットごとに送信され、サブネットを識別し、IV インデックスの更新（セクション 3.10.5 を参照）およびキーの更新手順（セクション 3.10.4 を参照）について通知します。

リレーノードとフレンドノードはビーコンを送信する必要があり、他のノードはビーコンを送信する場合があります。 2 つの連続するビーコンを送信する間の時間は、ビーコン間隔と呼ばれます。実装は、他のノードがあまりにも多くのビーコンでネットワークに過負荷をかけるのを防ぐために、バックオフ手順とともにビーコン間隔を定義する場合があります。予想される動作は、各ノードが特定のサブネットに対して約 10 秒ごとに 1 つのビーコンを受信することです。

サブネットごとに、ビーコン間隔を決定するために、ノードはビーコンを継続的に監視し、特定の監視期間にわたってサブネットのビーコン数のローリングカウントを維持する必要があります。ビーコン間隔は、次の式を使用して決定する必要があります。

ビーコン間隔 = 観測期間 *（観測されたビーコンの数 + 1）/ 予想されるビーコンの数

計算されたビーコン間隔が 10 秒未満の場合は、10 秒に設定する必要があります。計算されたビーコン間隔が 600 秒より大きい場合は、600 秒に設定する必要があります。

秒単位の観測期間は、通常、通常のビーコン間隔の 2 倍にする必要があります。サブネットごとに個別のセキュアネットワークビーコンがあるため、予想されるビーコンの数、観測されるビーコンの数、および観測期間はサブネットごとに異なる場合があります。

観測されたビーコンの数は、観測期間中にこのサブネットで観測されたビーコンの数です。

予想されるビーコンの数は、観測期間を 10 秒で割ったものです。

3.10 メッシュネットワーク管理

3.10.1 メッシュネットワークの作成手順

メッシュネットワークを作成するには、プロビジョナーが必要です。プロビジョナーは、ネットワークキーを生成し、IV インデックスを提供し、ユニキャストアドレスを割り当てる必要があります。

ネットワークキーは、コア仕様 [1] のボリューム 2、パート H、セクション 2 の要件と互換性のある乱数ジェネレーターを使用して生成する必要があります。

IV インデックスは 0x00000000 に設定されます。

ユニキャストアドレスは、プロビジョナーによって割り当てられたユニキャストアドレスに設定されるものとします。

メッシュネットワークは、上記の情報を使用して作成されます。プロビジョナーの主要な要素には、ユニキャストアドレスが割り当てられます。プロビジョナーの他の要素には、ユニキャストアドレスの後に順次アドレスが割り当てられます。

次に、プロビジョナーは、アクティブまたはパッシブスキャンを使用してプロビジョニングされていないデバイスビーコンをスキャンすることにより、プロビジョニングされていないデバイスを見つけることができます。次に、プロビジョナーはこれらのデバイスをプロビジョニングして、メッシュネットワーク内のノードになることができます。これらのノードがプロビジョニングされると、構成クライアントは、ノードにアプリケーションキーを提供し、ノードが相互に通信できるようにパブリッシュアドレスとサブスクライブアドレスを設定することで、ノードを構成できます。

注：プロビジョナーのデバイスキーは、あるプロビジョナーが別のプロビジョナーと直接通信していて、このデバイスキーが OOB で通信されている場合にのみ使用されます。プロビジョナーのデバイスキーは、複数のプロビジョナー間で調整する必要があります。

3.10.2 一時的なゲストアクセス

メッシュネットワークへの一時的なゲストアクセスをノードに提供することが可能です。これは、ゲストとゲストがアクセスできるノードに個別のネットワークキーを提供することにより、個別のゲストサブネットを作成することによって行われます。

ゲストがアクセスレイヤーでアクセスできるモデルを制限するために、個別のアプリケーションキーもゲストに提供されます。

ゲストは、ゲストアクセスから除外されたノードおよびモデルによって使用されるアプリケーションキーまたはネットワークキーを取得することはありません。ゲストサブネットに属するノードのみがゲストノードと通信します。これらのノード内では、ゲストアプリケーションキーにバインドされたモデルのみをゲストが使用できます。これにより、ゲストアクセスを特定のノードや機能に至るまで非常に細かく制御できます。

ゲストは、プライマリサブネットで IV インデックスの更新を開始できません。これにより、ネットワーク共有リソースである IV インデックスが、潜在的に悪意のある動作から保護されます。

ゲストアクセスは、デバイスキーで保護された構成サーバーモデルを使用して、構成クライアントによって構成されます。複数のゲストにゲストアクセスを提供でき、それぞれが独自のゲストサブネットとモデルドメイン内にあります。

ゲストアクセスは、キーの更新手順を介してアプリケーションキーとネットワークキーを更新することによって取り消されます（セクション 3.10.4 を参照）。

3.10.3 デバイスの UUID

ノードの展開の複雑さを軽減するために、メッシュ操作に一意の Bluetooth BD_ADDR は必要ありません。代わりに、各ノードには、デバイス UUID と呼ばれる 128 ビットの UUID が割り当てられます。デバイスメーカーは、標準の UUID に従う必要があります。

3.10.4 キーの更新手順

この手順は、1 つ以上のネットワークキーあるいは 1 つ以上のアプリケーションキーのセキュリティが危険にさらされているか、危険にさらされる可能性がある場合に使用されます。

たとえば、ノードがネットワークから削除されると、残りのすべてのノードのキーが変更され、削除されたノードは、そのノードが破棄された後に侵害された場合に使用されている新しいセキュリティ資格情報を認識できなくなります。これは「ゴミ箱攻撃」として知られています。

この手順では、一部のノードをブラックリストに登録できます（つまり、侵害された、またはセキュリティリスクがあると見なされる一部のノードと新しいキーを共有しない）新しいキーの配布は、構成クライアントと各ノード間のプロビジョニング中に確立されたデバイスキーに基づいているためです。

この手順は、ネットワークの運用への影響を最小限に抑えながら、ネットワークキー、アプリケーションキー、および導出したすべての資格情報を変更することで構成されます。

ノード内の各キーインデックスは、1 つまたは 2 つのキーを保持します。 2 つのキーが保持されている場合、最後に追加されたキーは新しいキーとして参照され、もう1つのキーは古いキーとして参照されます。

キー更新プロシージャは、NetKey とそれに関連する AppKey のあるキーから別のキーに変更するプロセスを管理します。新しいキー値が指定されていない AppKey は、関連付けられた NetKey が更新されたときに変更されません。

キー更新手順は、IV 更新手順とは独立しています。両方の手順は、同時に、インターリーブで、または異なる時間に実行できます。 IV 更新手順の動作は、キー更新手順に影響を与えません。また、キー更新手順は、IV 更新手順に影響を与えません。

図3.48 に示すように、キーの更新手順では、3 つのフェーズを使用して、古いキーのみを使用する現在の状態から新しいキーのみを使用する新しい状態にネットワークを移動します。

最初のフェーズでは、各ノードに新しいキーを配布します。ノードは引き続き古いキーを使用して送信しますが、古いキーと新しいキーを使用して受信できます。
2 番目のフェーズでは、すべてのノードが新しいキーを持っていることをネットワークに通知するセキュアネットワークビーコンを送信します。その後、ノードは新しいキーを使用して送信しますが、古いキーと新しいキーを使用して受信できます。
3 番目のフェーズでは、すべてのノードが古いキーを取り消す必要があることをネットワークに通知する別のセキュアネットワークビーコンを送信します。ノードは、新しいキーのみを使用して送受信します。

他のすべての NetKey とは独立して各 NetKey を更新することが可能です。ある NetKey のキー更新手順は、他の NetKey の別のキー更新手順とは異なるフェーズにある可能性があります。

図3.49 に示すように、通常操作のノードは、単一のキー、キー A1 のみを認識します。このキーは、パケットの送受信に使用されます。フェーズ 1（キー配布）が実行されると、各ノードは同じキーインデックスに格納されている新しいキーを受け取ります。ノードは引き続き古いキーであるキー A1 を使用して送信しますが、新しいキーであるキー A2 を使用してさらに受信します。すべてのノードに新しいキーが通知されると、フェーズ 2（新しいキーの使用）を開始できます。これにより、新しいキーを使用する必要があるという信号がネットワークに送信されます。したがって、ノードは新しいキーであるキー A2 を使用して送信を開始しますが、古いキーと新しいキーからも受信します。最後に、フェーズ 3（古いキーの取り消し）は古いキーを取り消します。つまり、ノードは単一のキーであるキー A2 を使用してのみ送受信します。古いキーが取り消された後、ノードは通常の操作に戻ります。

キー更新手順の堅牢性を高めるために、ノードは NetKey 値が異なり、キー更新手順が開始されていない場合、あるいは、NetKey 値がフェーズ 1 で同じである場合、有効な NetKeyIndex で Config NetKey Update メッセージを正常に処理する必要があります。

ノードがフェーズ 2 またはフェーズ 3 にある場合、Config NetKey Update メッセージはエラーを生成します。Config AppKey Update メッセージは、ノードが通常の動作、フェーズ 2、フェーズ 3 の場合、またはフェーズ 1 で、AppKey 値が異なる場合に有効な AppKeyIndex の Config AppKey Update メッセージの場合にエラーを生成します。

3.10.4.1 フェーズ1 – 新しいキーの配布

この手順は、構成クライアントによってトリガーされます。構成クライアントは、新しい NetKey とそれにバインドされた新しい AppKey を受信するノードのセットを決定する必要があります。新しいキーを受信していないノードはブラックリストに登録されます（つまり、フェーズ 3 でネットワークから効果的に削除されます）。

構成クライアントは、ブラックリストに登録されていない各ノードに新しいキーを送信する必要があります。新しいキーは、Config NetKey Update メッセージと Config AppKey Update メッセージを使用して配布されます。セクション 4.3.2.32 および 4.3.2.38 を参照してください。

新しいキーを受信すると、ノードはそれらを保存します。このフェーズでは、ノードは古いキーを使用して送信し、古いキーと新しいキーの両方を使用して受信します。

構成クライアントは、低電力ノードの待ち時間が非常に長くなる可能性があるため、新しいキーがそれらのノードに配信されるまでにさらに時間がかかる可能性があることに注意する必要があります。
PollTimeout タイマーの現在の値を取得し、この値に基づいて NetKey または AppKey の更新の再試行をスケジュールするために、低電力ノードに送信されるキー更新メッセージに対して OBO フィールドが 1 に設定されたセグメント確認応答を受信すると、構成クライアントは、低電力ノードのフレンドノードに対して PollTimeout List プロシージャを実行できます（Segment Acknowledgement の SRC フィールドの値を使用してフレンドノードを識別します）

フェーズ 1で新しい NetKey を使用してキー更新フラグが 0 に設定されたセキュアネットワークビーコンを受信すると、ノードはすぐにフェーズ 3 に移行し、フェーズ 2 を事実上スキップします。

ブラックリストに登録されていないすべてのノードが新しいキーを受信したと構成クライアントが判断すると、フェーズ 1 が完了し、フェーズ 2 に移行します。

注：メッシュプロキシサービスのアドバタイズメントは NetKey 値に依存し、該当する場合はフェーズ 1 からの移行時に更新する必要があります。

3.10.4.2 フェーズ 2 – 新しいキーへの切り替え

構成クライアントは、キー更新フラグが 1 に設定されたセキュアネットワークビーコンの送信を開始し、新しい NetKey を使用して保護するか（セクション 3.9.3 を参照）、または 1 つ以上のノードへの 0x02 に設定された遷移パラメーターの構成キー更新フェーズセットメッセージを送信してキー更新フェーズ移行を開始します。

リレーノードまたはフレンドノードは、特定の NetKey のフェーズ 2 にある場合、キー更新フラグが 1 に設定された新しい NetKey のセキュアネットワークビーコンを送信し、古い NetKey のセキュアネットワークビーコンの送信を停止します。

キー更新フラグが 1 に設定されたセキュアネットワークビーコンまたはフレンド更新メッセージ、またはフェーズパラメータが 0x02 に設定された構成キー更新フェーズセットメッセージを受信すると、ノードはこの NetKey のキー更新フェーズをフェーズ 2 に設定する必要があります。フェーズ 2 の場合、ノードは新しいキーを使用してメッセージとセキュアネットワークビーコンのみを送信し、古いキーと新しいキーを使用してメッセージを受信し、新しい NetKey を使用してセキュリティで保護されたセキュアネットワークビーコンのみを受信します。

構成クライアントは、低電力ノードの待機時間が非常に長い可能性があるため、低電力ノードがフレンドノードからキー更新フラグ情報を受信するのにさらに時間がかかる可能性があることに注意する必要があります。

ブラックリストに登録されていないすべてのノードがフェーズ 2 にあると構成クライアントが判断すると、フェーズ 2 が完了し、フェーズ 3 に移行します。

3.10.4.3 フェーズ 3 – 古いキーを取り消す

構成クライアントは、キー更新フラグが 0 に設定されたセキュアネットワークビーコンの送信を開始するか、新しい NetKey を使用して保護するか（セクション 3.9.3 を参照）、1 つ以上のノードで 0x03 に設定された遷移パラメーターの構成キー更新フェーズセットメッセージを送信してキー更新フェーズ移行を開始します。構成クライアントは古いキーを取り消すものとします。

注：デバイスが最近プロビジョニングされ、古いキーがない場合、デバイスは古いキーを認識しないため、古いキーを取り消すことはできません。

リレーノードまたはフレンドノードは、特定の NetKey のフェーズ 3 にある場合、キー更新フラグが 0 に設定された新しい NetKey のセキュアネットワークビーコンを送信する必要があります。

キー更新フラグが 0 に設定されたセキュアネットワークビーコンまたはフレンド更新メッセージ、または遷移パラメータが 0x03 に設定された構成キー更新フェーズセットメッセージを受信すると、ノードは古いキーを取り消し、キー更新フラグが 0 に設定された新しい NetKeyのセキュアネットワークビーコンを送信します。ノードは、新しいキーを使用してのみ送受信します。キー更新フラグが 1 に設定された新しい NetKey を使用して保護されたセキュアネットワークビーコンとフレンドアップデートメッセージは無視されます。古いキーが取り消された後、キー更新状態は 0 になります。

構成クライアントは、低電力ノードの待機時間が非常に長い可能性があるため、低電力ノードがフレンドノードからキー更新フラグ情報を受信するのにさらに時間がかかる可能性があることに注意する必要があります。

3.10.5 IV 更新手順

IV インデックスは、アプリケーションレイヤーとネットワークレイヤーの両方で認証付き暗号化（AES-CCM）に使用されるナンスのエントロピーを提供します。したがって、ナンスでシーケンス番号が繰り返し使用されないように、十分な頻度で変更する必要があります。 IV 更新手順は、プライマリサブネットのメンバーである任意のノードによって開始されます。これは、ノードがシーケンス番号を使い果たすリスクがあると判断した場合、または別のノードがシーケンス番号を使い果たしそうだと判断した場合に実行できます。ノードは IV インデックスを変更し、メッシュ内の他のノードに IV インデックスが更新されていることを示す指示を送信します。その後、メッシュ内の同じノードまたは他のノードによって通常の操作に戻ります。

キーインデックスが 0x000 とは異なる接続されたサブネット上で、セキュアネットワークビーコンの状態が 1 に設定されたノードが少なくとも1つ、プライマリサブネット上に存在する必要があります。

注：メッセージをほとんど送信しないノードは、IV 更新手順を開始することはめったにありません。

IV 更新手順では、次の2つの動作状態が定義されています。

通常の操作 – IV 更新フラグ = 0
進行中の IV 更新 – IV 更新フラグ = 1

通常動作状態の間、セキュアネットワークビーコンおよびフレンド更新メッセージのIV更新フラグは 0 に設定されます。この状態がアクティブな場合、ノードは現在の IV インデックスを使用して送信し、現在の IV インデックスおよび現在のIVインデックス – 1 からのメッセージを処理する必要があります。

たとえば、IV 更新フラグが 0 に設定されていて、現在の IV インデックスが 0x00101847 に等しい場合、ノードは IV インデックス 0x00101847 を使用して送信し、ネットワークレイヤーの IVI フィールドが 1 に設定されている場合は IV インデックス 0x00101847 を使用して受信したメッセージを受け入れ、ネットワークレイヤーの IVI フィールドが 0 に設定されている場合は 0x00101846 を受け入れます。

通常動作のノードは、最後の既知の IV インデックス + 1 より大きい IV インデックスを持つセキュアネットワークビーコンを受信すると、IV インデックス回復手順を開始する場合があります。セクション 3.10.6 を参照してください。

通常動作のノードが、IV インデックスが最後の既知の IV インデックス + 1 と等しい、IV 更新フラグが0に設定されたセキュアネットワークビーコンを受信した場合、ノードは、Progress 状態のIV 更新に移行せずに IV を更新するか、IV インデックス回復手順（セクション 3.10.6 ）を開始するか、セキュアネットワークビーコンを無視する場合があります。ノードは、最後の IV 更新からの時間と、IV 更新フラグが 1 に設定されたセキュアネットワークビーコンをノードが見逃した可能性に応じて選択を行います。

通常動作のノードが、最後の既知の IV インデックスよりも小さいまたは最後の既知の IV インデックス + 42 よりも大きい IV インデックスを持つセキュアネットワークビーコンを受信した場合、セキュアネットワークビーコンは無視されます。

注：この上記の要件により、ノードは 48 週間ネットワークから離れることができます。ネットワークから 48 週間以上離れているノードは、再プロビジョニングする必要があります。

このノードがプライマリサブネットのメンバーであり、プライマリサブネットの最後の既知の IV インデックスよりも大きい IV インデックスを持つセカンダリサブネットでセキュアネットワークビーコンを受信した場合、セキュアネットワークビーコンは無視されます。

通常動作で 96 時間動作した後、ノードは IV Update in Progress 状態に移行することで IV 更新手順を開始できます。ノードが通常操作状態から IV 更新進行中状態に移行すると、ノードの IV インデックスが 1 つインクリメントされます。

セクション 3.8.3 で定義されているように、通常動作状態から IV Update in Progress 状態への移行は、シーケンス番号がなくなる少なくとも 96 時間前に発生する必要があります。

IV 更新フラグが 1 に設定されたセキュアネットワークビーコンを受信および受け入れる通常動作状態のノード（ IV 更新が進行中の状態を示す）は、できるだけ早く IV 更新が進行中の状態に移行する必要があります。

IV Update in Progress 状態の間、セキュアネットワークビーコンおよびフレンド更新メッセージの IV 更新フラグは 1 に設定されます。この状態がアクティブな場合、ノードは現在の IV インデックス – 1 を使用して送信し、現在の IV インデックス – 1 および現在の IV インデックスからのメッセージを処理する必要があります。

たとえば、通常動作状態から IV Update in Progress 状態に移行する前に IV インデックスが 0x00101847 だった場合、移行後、IV 更新フラグは 1 になり、現在の IV インデックスは 0x00101848 になり、ノードは IV インデックス 0x00101847 であり、ネットワークレイヤーの IVI フィールドが 1 に設定されている場合は、IV インデックス 0x00101847 を使用して受信したメッセージを受け入れ、ネットワークレイヤーの IVI フィールドが 0 に設定されている場合は、0x00101848 を受け入れます。これにより、通常動作状態にあるすべてのノードが許可されます。古い IV インデックスを使用してこのノードにメッセージを送信し、このノードはまだ移行していないノードにメッセージを送信します。

IV Update in Progress 状態で少なくとも 96 時間後、144 時間動作する前に、ノードは IV通常動作状態に戻り、IV インデックスを変更しないものとします。遷移の時点で、ノードはシーケンス番号を 0x000000 にリセットする必要があります。

たとえば、通常の操作状態に戻ると、IV 更新フラグは 0 になり、現在の IV インデックスは0x00101848になり、ノードは、IV インデックス 0x00101848 を使用して送信し、ネットワークレイヤーの IVI フィールドが 1 に設定されている場合は、IV インデックス 0x00101847 を使用して受信したメッセージを受け入れ、ネットワークレイヤーの IVI フィールドが 0 に設定されている場合は、0x00101848 を受け入れます。これにより、ノードは、ネットワーク内のすべてのノードが通常の操作状態であろうと、IV 更新中状態であろうと、メッセージを送信できます。また、ノードは、通常操作状態またはIV 更新進行中状態にあるすべてのノードからメッセージを受信できます。 IV 更新手順の概要を以下の表3.57 に示します。

IV Index	IV Update Flag	IV Update Procedure 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

表3.57：IV 更新手順の概要

IV 更新フラグが 0（通常動作状態を示す）に設定されたセキュアネットワークビーコンを受信および受け入れる IV 更新進行中状態にあるノードは、できるだけ早く通常動作状態に移行する必要があります。

ノードは、対応するセグメント確認メッセージを受信せずにセグメント化アクセスメッセージまたはセグメント化制御メッセージを送信した場合、この手順で定義されているように、IV 更新進行中から通常動作への状態変更を延期するものとします。状態の遅延変更は、適切なセグメント確認メッセージが受信されたとき、またはこのメッセージの配信のタイムアウトに達したときに実行されます。

注：IV 更新手順が完了すると、シーケンス番号が 0x000000 にリセットされ、SeqAuth 値が無効になるため、この要件が必要です。

ノードがネットワークに追加されると、そのノードには IV インデックスが与えられます。ネットワークが通常動作しているときにノードがネットワークに追加された場合、ノードは少なくとも 96 時間は通常動作で動作する必要があります。ネットワークが IV Update in Progress 状態のときにノードがネットワークに追加された場合、ノードには新しい IV インデックス値が与えられ、少なくとも 96 時間は通常の動作で動作します。

3.10.5.1 IV 更新テストモード

IV 更新手順の効率的なテストを可能にするために、ノードは、Bluetooth 認定プロセスに関連してテストに使用される IV 更新テストモードをサポートする必要があります。テストモードのアクティブ化は、ローカルで（ HW または SW インターフェイスを介して）実行する必要があります。 IV Update テストモードでは、96 時間の制限のみが削除されます。デバイスの他のすべての動作は変更されません。

IV 更新テストモードでは、次の 2 つの signal が定義されています。

Transit to IV Update in Progress signal
Transit to Normal signal

Transit to IV Update in Progress signal を受信すると、ノードは 96 時間の制限を無視して、IV Update in Progress 状態に移行します。
Transit to Normal signalを受信すると、ノードは 96 時間の制限を無視して、通常l状態に移行します。

3.10.6 IV インデックス回復手順

長期間ネットワークから離れているノードはIV更新手順を見逃す可能性があるため、ノードはIVインデックス回復手順をサポートする必要があります。その場合、他のノードと通信できなくなります。 IVインデックスを回復するには、ノードはネットワーク ID と現在の IV インデックスを含むセキュアネットワークビーコンをリッスンする必要があります。IV インデックスが現在の既知の IV インデックスより 1 以上高いプライマリサブネットのセキュアネットワークビーコンを受信して正常に認証すると、ノードは、このセキュアネットワークビーコンの値から、現在のIVインデックスと現在のIV更新手順の状態を設定する必要があります。

注：IV インデックス回復手順で IV インデックスを更新した後は、IV 更新手順で定義されている IV 更新手順の状態を変更するための 96 時間の制限時間は適用されません。

ノードが 10 秒ごとに 1 回、セキュアネットワークビーコンをまとめて送信する場合、低デューティサイクルノードは、メッシュメッセージを送受信する前に、現在の IV インデックスを回復するために平均 5 秒間リッスンする必要があります。低電力ノードの電力が 5 秒間リッスンするのに不十分な場合は、少なくとも 96 時間に 1 回、フレンドノードをポーリングして、現在の IV インデックスを最新の状態に保つ必要があります。

ノードは、192 時間以内に複数の IV インデックス回復を実行してはなりません。

3.10.7 ノード削除手順

場合によっては、ネットワークからノードを削除する必要があります（たとえば、セキュリティ上の理由から、またはノードのハードウェアやソフトウェアの障害が原因で）。

ノードの削除は、ノードをキー更新手順から除外することによってノードをブラックリストに登録した結果です（セクション 3.10.4 を参照）。

ノードがネットワークから削除された後、そのユニキャストアドレスはプロビジョナーによって再利用される場合があります。プロビジョナーは、SEQ 番号を再利用できるようにするために、現在の IV インデックス（削除時）が更新された後（セクション 3.10.5 を参照）にのみこれらのアドレスを再利用するものとします。