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

はじめに
3 Mesh networking

はじめに

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

3.1 慣例
3.2 機能
3.3 ベアラ
3.4 ネットワークレイヤー

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

3 Mesh networking

このセクションは、セクション2.1で説明されている階層化アーキテクチャのように構成されています。さらに、メッシュセキュリティとメッシュネットワーク管理に関するセクションがあります。

3.1 慣例

この仕様には、次の規則が適用されます。

3.1.1 エンディアンとフィールドの順序

ネットワークレイヤー、下位トランスポートレイヤー、上位トランスポートレイヤー、メッシュビーコン、およびプロビジョニングの場合、セクション 3.1.1.1 で説明されているように、すべてのマルチオクテット数値はビッグエンディアンで送信されます。
アクセスレイヤーとファンデーションモデルの場合、セクション 3.1.1.2 で説明されているように、すべてのマルチオクテット数値はリトルエンディアンでなければなりません。
ネットワークデータ構造が複数のフィールドで構成されている場合、フィールドは表に上から下にリストされ、対応する図に左から右に表示されます（つまり、表の一番上の行は図の左側に対応します）。表3.1に、複数のフィールドで構成されるデータ構造の例を示します。

フィールド	サイズ（ビット）	フィールドコンテンツの説明
Field 0	4	このフィールドの先頭はオクテット0です（対応する図の左端のオクテット）
Field 1	12	このフィールドの開始はオクテット0で、オクテット1で終了します。
Field 2	16	このフィールドの開始はオクテット2で、オクテット3で終了します。

表3.1：フィールドの順序付けの例

テーブルで定義されたデータ構造を、ビッグエンディアンを使用するレイヤーの一連のオクテットに変換するには、次の手順を使用します。
N個の未割り当てビットを持つ2進数が作成されます。数値のビットNは、テーブル内のすべてのフィールドのビット数の合計に等しくなります。番号の最上位ビット（MSb）がフィールド0（テーブルの最初の行）の値に設定され、次に番号の割り当てられていないMSbがフィールド1の値に設定されます。この手順は、テーブルの連続するフィールドに対して続行されます。数値の最下位ビット（LSb）がテーブルの最後のフィールドの値に設定されると終了します。
最後のステップとして、数値はビッグエンディアン形式で送信されます（つまり、最も重要なオクテットが最初に送信されます）。
これを図3.1に示します。

たとえば、フィールド0は4ビット幅で値が0x6、フィールド1は12ビット幅で値が0x987、フィールド2は16ビット幅で値が0x1234です。 2進数の値は0x69871234であり、0x69、0x87、0x12、0x34として送信されます。
テーブルで定義されたデータ構造を、リトルエンディアンを使用するレイヤーの一連のオクテットに変換するには、次の手順を使用します。 N個の未割り当てビットを持つ2進数が作成されます。数値のビット数Nは、テーブル内のすべてのフィールドのビット数の合計に等しくなります。番号のLSbsはフィールド0（テーブルの最初の行）の値に設定され、次に番号の割り当てられていないLSbsはフィールド1の値に設定されます。この手順はテーブルの連続するフィールドに対して続行され、数値は、テーブルの最後のフィールドの値に設定されます。最後のステップとして、数値はリトルエンディアン形式で送信されます（つまり、最下位のオクテットが最初に送信されます）。これを図3.2に示します。

たとえば、フィールド0は4ビット幅で値が0x6、フィールド1は12ビット幅で値が0x987、フィールド2は16ビット幅で値が0x1234です。 2進数の値は0x12349876であり、0x76、0x98、0x 34、0x12として送信されます。

3.1.1.1 ビッグエンディアン

複数オクテット値が「ビッグエンディアン」（「ネットワークバイトオーダー」とも呼ばれる）で送信されるように定義されている場合、このセクションの規則が適用されます。たとえば、値0x123456は、0x12、0x34、および0x56（最も重要なオクテットが最初）として送信されます。

3.1.1.2 リトルエンディアン

複数オクテット値が「リトルエンディアン」で送信されるように定義されている場合、このセクションの規則が適用されます。たとえば、値0x123456は、0x56、0x34、および0x12（最下位オクテットが最初）として送信されます。

3.2 機能

この仕様では、次の4つのオプション機能を定義しています。

リレー機能（セクション3.4.6.1を参照）
プロキシ機能（セクション3.4.6.2を参照）
フレンド機能（セクション3.6.6.3を参照）
低電力機能（セクション3.6.6.4を参照）

3.3 ベアラ

この仕様では、メッシュメッセージを転送できる2つのメッシュベアラを定義しています。

アドバタイジングベアラ（セクション 3.3.1 を参照）
GATTベアラ（セクション 3.3.2 を参照）

ノードは、アドバタイジングベアラまたはGATTベアラ、あるいはその両方をサポートするものとします。

3.3.1 アドバタイジングベアラ

アドバタイジングベアラを使用する場合、メッシュパケットは、[4]で定義されている≪メッシュメッセージ≫で識別されるメッシュメッセージADタイプを使用して、Bluetooth Low Energy アドバタイジング PDU のアドバタイジングデータで送信されるものとします。
メッシュメッセージADタイプには、表3.2で定義されているネットワークPDUが含まれています。

長さ	ADタイプ	内容
0xXX	<<Mesh Message>>	ネットワークPDU

表3.2：メッシュメッセージADタイプ

メッシュメッセージADタイプを使用するアドバタイズメントは、接続不可能でスキャン不可能な無向アドバタイジングイベントである必要があります。ノードが接続可能なアドバタイズメントまたはスキャン可能なアドバタイジングイベントでメッシュメッセージADタイプを受信した場合、メッセージは無視されます。

無向（undirected）とは、不特定多数のデバイスを対象とすることです。
有向（directed）とは、特定デバイスを対象とすることです。

注意：
アドバタイジングパケットにフラグADタイプを含める必要がないため、接続不可能なアドバタイズメントが使用されます。これにより、2つの追加オクテットをネットワークPDUに割り当てることができます（[7]を参照）。すべてのアドバタイジングチャネルでパケットの衝突の可能性を低くするには、アドバタイジングイベント内の連続するパケット間のギャップをランダム化することをお勧めします（[1]を参照）。

アドバタイジングベアラのみをサポートするデバイスは、受信するメッシュメッセージまたはプロビジョニングPDUの欠落を回避するために、可能な限り100％に近いデューティサイクルでパッシブスキャンを実行する必要があります。

パッシブスキャンとは、アドバタイザのパケットを受信するだけのスキャンのことです。

すべてのデバイスは、GAPオブザーバーの役割とGAPブロードキャスターの役割の両方をサポートする必要があります。

3.3.2 GATT ベアラ

GATTベアラは、アドバタイジングベアラをサポートできないデバイスがメッシュネットワークに参加できるようにするために提供されています。GATTベアラは、プロキシプロトコル（セクション6を参照）を使用して、GATT接続を介して2つのデバイス間でプロキシPDUを送受信します。

GATTベアラは、特性を使用して、属性プロトコルを使用してメッシュメッセージの通知を書き込んだり受信したりします。

GATTベアラは、GATTベアラクライアントとGATTベアラサーバーの2つの役割を定義します。

GATTベアラクライアントは、GATTクライアントでなければならない。

GATTベアラサーバーはGATTサーバーでなければならない。

GATTベアラサーバーは、セクション7.2で定義されているように、唯一のメッシュプロキシサービスをインスタンス化するものとします。

GATTベアラクライアントは、メッシュプロキシサービスをサポートするものとします。

GATTベアラクライアントは、GATT Discover All Primary ServicesサブプロシージャまたはGATT Discover Primary Services by Service UUIDサブプロシージャのいずれかを使用してプライマリサービスディスカバリを実行し、メッシュプロキシサービスを検出する必要があります。

GATTの要求に応じて、GATTベアラクライアントは、このプロファイルで使用されるサービスのサービスレコードにおける追加のオプション特性に寛容でなければなりません。

GATTベアラクライアントは、サービスの特性を検出するために、GATTサービスのすべての特性の検出サブプロシージャまたはUUIDサブプロシージャによるGATTの特性の検出のいずれかを使用するものとします。

GATTベアラクライアントは、GATT Discover All Characteristic Descriptorsサブプロシージャを使用して、次のセクションで説明する特性記述子を検出する必要があります。

GATTベアラクライアントは、メッシュプロキシデータ入力特性、メッシュプロキシデータ出力特性、およびそのクライアント特性構成記述子（Client Characteristic Configuration descriptor）を検出する必要があります。クライアント特性構成記述子（Client Characteristic Configuration descriptor）が検出されると、この特性を使用した通知が有効になります。

プロキシPDUを送信するには（セクション6.3を参照）、GATTベアラクライアントは、応答なしの書き込みサブプロシージャを使用して、メッシュプロキシデータ入力特性に書き込むことにより、プロキシPDUをGATTベアラサーバーに書き込みます。

プロキシPDUを受信するために、GATTベアラクライアントはメッシュプロキシデータ出力特性の複数の通知を受信できる必要があります。各通知には、単一のプロキシPDUが含まれています。

3.4 ネットワークレイヤー

ネットワークレイヤーは、下位トランスポートPDUをベアラレイヤーで転送できるようにするネットワークPDUフォーマットを定義します。
入力インターフェイスで受信した着信メッセージを復号化して認証し、上位レイヤーや出力インターフェイスに転送し、送信メッセージを暗号化して認証して転送し、出力ネットワークインターフェイスに配信します。

3.4.1 エンディアン

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

3.4.2 アドレス

ネットワークレイヤーは、未割り当て、ユニキャスト、仮想、およびグループの4つの基本的なタイプのアドレスを定義します。
アドレスは16ビット長で、以下の表3.3で定義されているようにエンコードされます。

値	アドレスタイプ
0b0000000000000000	未割り当てアドレス
0b0xxxxxxxxxxxxxxx (excluding 0b0000000000000000)	ユニキャストアドレス
0b10xxxxxxxxxxxxxx	仮想アドレス
0b11xxxxxxxxxxxxxx	グループアドレス

表3.3：16ビットアドレスの割り当て

3.4.2.1 未割り当てのアドレス

未割り当てアドレスとは、ノードの要素がまだ構成されていないか、アドレスが割り当てられていないアドレスです。以下の図3.3に示すように、未割り当てのアドレスの値は0x0000でなければなりません。これは、たとえば、モデルの公開アドレスを割り当てられていないアドレスに設定することにより、モデルのメッセージ公開を無効にするために使用できます。

未割り当てのアドレスは、メッセージの送信元または宛先アドレスフィールドで使用してはなりません。

3.4.2.2 ユニキャストアドレス

ユニキャストアドレスは、各要素に割り当てられた一意のアドレスです。
ユニキャストアドレスのビット15は0に設定されています。ユニキャストアドレスの値は、0x0000であってはならないため、以下の図3.4に示すように、0x0001から0x7FFFまでの任意の値を指定できます。

ユニキャストアドレスは、セクション 5.4.2.5 で説明されているように、プロビジョニング中にプロビジョニング担当者によってネットワーク上のノードの存続期間中、ノードの各要素に割り当てられます。セクション 3.10.7 で定義された手順を使用してアドレスを再利用できるように、プロビジョナーはアドレスの割り当てを解除できます。

ユニキャストアドレスは、メッセージの送信元アドレスフィールドで使用する必要があり、メッセージの宛先アドレスフィールドで使用できます。ユニキャストアドレスに送信されたメッセージは、最大で1つの要素によって処理されます。

3.4.2.3 仮想アドレス

仮想アドレスは、宛先アドレスのセットを表します。各仮想アドレスは、一元管理する必要のない128ビット値であるラベルUUIDを論理的に表します。
ラベルUUIDを公開またはサブスクライブするように1つ以上の要素をプログラムできます。ラベルUUIDは送信されず、上位トランスポートレイヤーのメッセージ整合性チェック値の追加データフィールドとして使用されます（セクション 3.8.7.1 を参照）。

仮想アドレスは、ビット15が1に設定され、ビット14が0に設定され、ビット13〜0がハッシュの値に設定された16ビット値です。このハッシュは、各ハッシュが多くのラベルUUIDを表すように、ラベルUUIDから派生したものです。

SALT = s1（“ vtad”）
hash = AES-CMAC_SALT（ラベルUUID）mod 2¹⁴

一致するハッシュを持つ仮想アドレスにアクセスメッセージが受信されると、対応する各ラベルUUIDは一致するものが見つかるまで、メッセージの認証の一部の追加データとして上位トランスポートレイヤーによって使用されます。

制御メッセージは仮想アドレスを使用できません。

ラベルUUIDは、[8]で定義されているようにランダムに生成できます。構成クライアントは仮想アドレスを割り当てて追跡できますが、2つのデバイスが帯域外（OOB）メカニズムを使用して仮想アドレスを作成することもできます。グループアドレスとは異なり、これらは関係するデバイスによって合意することが可能であり、重複する可能性が低いため、集中プロビジョニングデータベースに登録する必要はありません。

仮想アドレスの欠点は、構成中にラベルUUIDを公開ノードまたはサブスクライブノードに転送するためにマルチセグメントメッセージが必要になることです。

以下の図3.5に示すように、仮想アドレスは0x8000から0xBFFFまでの任意の値を持つことができます。

注：32ビットMICとハッシュのサイズを考慮に入れると、同じアプリケーションキーを使用しているが異なるラベルUUIDを使用する2つの一致する仮想アドレスが衝突する可能性は、たった1/246 = 1.42×10-14です。

3.4.2.4 グループアドレス

グループアドレスは、0個以上の要素にプログラムされたアドレスです。次の図3.6に示すように、グループアドレスのビット15は1に設定され、ビット14は1に設定されています。 0xFF00から0xFFFFの範囲のグループアドレスは固定グループアドレス用に予約されており（表3.4を参照）、0xC000から0xFEFFの範囲のアドレスは通常他の用途に使用できます。

グループアドレスは、メッセージの宛先アドレスフィールドでのみ使用されます。グループアドレスに送信されたメッセージは、このグループアドレスにサブスクライブしているモデルのすべてのインスタンスに配信されます。

グループアドレスには2つのタイプがあります。動的に割り当てることができるグループアドレスと固定で割り当てられているグループアドレスです。固定グループアドレスは、以下の表3.4で定義されています。

値	固定されたグループアドレス名
0xFF00 – 0xFFFB	RFU
0xFFFC	all-proxies
0xFFFD	all-friends
0xFFFE	all-relays
0xFFFF	all-nodes

表3.4：固定されたグループアドレス

all-proxiesアドレスに送信されるメッセージは、プロキシ機能が有効になっているすべてのノードのプライマリ要素によって処理されます。

all-friendsアドレスに送信されたメッセージは、friend機能が有効になっているすべてのノードのプライマリ要素によって処理されます。

all-relaysアドレスに送信されたメッセージは、リレー機能が有効になっているすべてのノードのプライマリ要素によって処理されます。

all-nodesアドレスに送信されたメッセージは、すべてのノードのプライマリ要素によって処理されます。

3.4.3 アドレスの有効性

表3.5は、送信元アドレスフィールドと宛先アドレスフィールドでの使用に有効なアドレスタイプを示しています。

アドレスタイプ	送信元アドレスフィールドで有効	宛先アドレスフィールドで有効ーーーーーーーーーーセグメント化及び非セグメント化制御メッセージ	宛先アドレスフィールドで有効ーーーーーーーーーーーーセグメント化及び非セグメント化アクセスメッセージ
未割り当てアドレス	No	No	No
ユニキャストアドレス	Yes	Yes	Yes
仮想アドレス	No	No	Yes
グループアドレス	No	Yes	Yes

表3.5：アドレスタイプとメッセージフィールドの有効性

表3.6は、デバイスキーとアプリケーションキーでの使用に有効なアドレスタイプを示しています。

アドレスタイプ	デバイキーで有効	アプリケーションキーで有効
未割り当てアドレス	No	No
ユニキャストアドレス	Yes	Yes
仮想アドレス	No	Yes
グループアドレス	No	Yes

表3.6：アドレスタイプとアクセスレイヤーキータイプの有効性

3.4.4 ネットワーク PDU

メッシュネットワークPDU形式は、表3.7で定義されており、以下の図3.7に示されています。

フィールド名	ビット	説明
IVI	1	IV インデックスの最下位ビット
NID	7	このPDUを保護するために使用される暗号化キーとプライバシーキーを識別するために使用される NetKeyから派生した値
CTL	1	ネットワーク制御
TTL	7	Time To Live
SEQ	24	シーケンス番号
SRC	16	送信元アドレス
DST	16	宛先アドレス
TransportPDU	8 to 128	トランスポート PDU
NetMIC	32 to 64	ネットワークのメッセージ整合性チェック

表3.7：ネットワークPDUフィールドの定義

ネットワーク PDUは、NID フィールドで識別される単一のネットワークキーから派生したキーを使用して保護されます。

3.4.4.1 IVI

IVI フィールドには、このネットワークPDUを認証および暗号化するためにナンスで使用されるIVインデックスの最下位ビットが含まれます（セクション3.8.3を参照）。

3.4.4.2 NID

NID フィールドには、このネットワーク PDUの認証と暗号化に使用される暗号化キーとプライバシーキーを簡単に検索できる7ビットのネットワーク識別子が含まれています（セクション3.8.6.3.1を参照）。

NID 値は、暗号化キーおよびプライバシーキーと組み合わせたネットワークキーから取得されます。これは、メインネットワークメッセージと、フレンドとその低電力ノード間のプライベートネットワークメッセージで異なる方法で導出されます（セクション3.8.6.3.1を参照）。

3.4.4.3 CTL

CTLフィールドは、表3.8に示すように、メッセージが制御メッセージまたはアクセスメッセージの一部であるかどうかを判別するために使用される1ビット値です。

CTLフィールドが0に設定されている場合、NetMICは32ビット値であり、下位トランスポート PDUにはアクセスメッセージが含まれます。

CTLフィールドが1に設定されている場合、NetMICは64ビット値であり、下位トランスポート PDUには制御メッセージが含まれます。

CTL フィールド	メッセージタイプ	NetMIC サイズ（ビット）
0	アクセスメッセージ	32
1	制御メッセージ	64

表3.8：CTL フィールドのメッセージタイプとNetMIC サイズ

3.4.4.4 TTL

TTLフィールドは7ビットフィールドです。次の値が定義されています。

0 = リレーされておらず、リレーされません
1 = リレーされた可能性がありますが、リレーされません
2〜126 = リレーされた可能性があり、リレーすることができる
127 = リレーされておらず、リレー可能

このフィールドの初期値は、送信層（下位トランスポートレイヤー、上位トランスポートレイヤー、アクセス、基盤モデル、モデル）またはアプリケーションによって設定され、リレーノードとして動作するときにネットワークレイヤーによって使用されます。

ゼロのTTL値を使用すると、ノードはリレーされないことがわかっているネットワーク PDUを送信できるため、受信ノードは送信ノードが単一の無線リンクから離れていると判断できます。 1以上のTTL値の使用は、そのような決定には使用できません。

3.4.4.5 SEQ

SEQ フィールドは24ビット整数です。結合されたSEQ フィールド、IV インデックスフィールド、およびSRC フィールド（セクション3.4.4.6を参照）は、この要素が発信する新しいネットワーク PDUごとに一意の値でなければなりません。

3.4.4.6 SRC

SRC フィールドは、このネットワーク PDUを発信した要素を識別する16ビット値です。このアドレスはユニキャストアドレスでなければなりません。
SRC フィールドは、元の要素によって設定され、リレーノードとして動作するノードによって変更されません。

3.4.4.7 DST

DST フィールドは、このネットワーク PDUが向けられている1つまたは複数の要素を識別する16ビット値です。このアドレスは、ユニキャストアドレス、グループアドレス、または仮想アドレスでなければなりません。

DST フィールドは発信元ノードによって設定され、リレーノードとして動作するノードのネットワーク層には影響されません。

3.4.4.8 TransportPDU

ネットワーク層の観点から見たTransportPDU フィールドは、データのオクテットのシーケンスです。 CTL ビットが0の場合、TransportPDU フィールドは最大128ビットでなければなりません。 CTL ビットが1の場合、TransportPDU フィールドは最大96ビットでなければなりません。
TransportPDU フィールドは、発信元の下位トランスポート層によって設定され、ネットワークレイヤーによって変更されないものとします。

3.4.4.9 NetMIC

NetMIC フィールドは、DST および TransportPDUが変更されていないことを認証する32ビットまたは64ビットのフィールド（CTL ビットの値に応じて）です。

CTL ビットが0の場合、NetMIC フィールドは32ビットになります。 CTL ビットが1の場合、NetMIC フィールドは64ビットになります。

NetMIC は、このネットワークPDUを送信または中継する各ノードのネットワークレイヤーによって設定されます。

3.4.5 ネットワークインターフェイス

ネットワークレイヤーは、複数のベアラを介したメッセージの送受信をサポートします。ベアラの複数のインスタンスが存在する場合があります。ベアラの各インスタンスは、ネットワークインターフェイスを介してネットワーク層に接続されます。同じノード内の要素間でメッセージを送信できるようにするには、ローカルインターフェイスが使用されます。

たとえば、ノードには3つのインターフェイスがあります。1つはアドバタイジングベアラを介してメッセージを送受信するために使用され、2つは GATT ベアラに接続されます。1つはGATT 接続を介して接続されたクライアントごとに使用されます。

インターフェイスは、入力フィルターと出力フィルターを提供します。フィルタは、ベアラ固有の PDU を使用して構成することも、メッシュプロキシサービスなどのノードで公開されているサービスによって内部的に構成することもできます（セクション7.2を参照）。

3.4.5.1 インターフェイス入力フィルタ

インターフェイス入力フィルタは、着信メッシュメッセージをネットワークレイヤーに配信してさらに処理するか、ドロップするかを決定します。

3.4.5.2 インターフェイス出力フィルタ

インターフェイス出力フィルタは、発信メッシュメッセージをベアラに配信するか、ドロップするかを決定します。

アドバタイジングベアラまたは GATT ベアラに接続されたインターフェースの出力フィルターは、TTL 値が1に設定されたすべてのメッセージをドロップします。

3.4.5.3 ローカルネットワークインターフェイス

ローカルネットワークインターフェイスを使用すると、同じノード内の要素間でメッセージを送信できます。

ノードはローカルネットワークインターフェースを実装する必要があります。

ローカルネットワークインターフェイスによってメッセージを受信すると、メッセージはノードのすべての要素に配信されます。

3.4.5.4 アドバタイジングベアラネットワークインターフェイス

アドバタイジングベアラネットワークインターフェイスを使用すると、アドバタイジングベアラを使用してメッセージを送信できます（セクション3.3.1を参照）。

ネットワークレイヤーからリレーとしてタグ付けされていないネットワーク PDUを受信すると、アドバタイジングベアラネットワークインターフェイスは、ネットワーク送信状態の値を使用して、アドバタイジングベアラを介してネットワーク PDUを再送信する必要があります（セクション4.2.19を参照）。

ネットワークレイヤーからリレーとしてタグ付けされたネットワーク PDUを受信すると、アドバタイジングベアラネットワークインターフェイスは、Relay Retransmit状態の値を使用してアドバタイジングベアラを介してネットワーク PDUを再送信します（セクション4.2.20を参照）。

3.4.6 ネットワークレイヤーの動作

3.4.6.1 リレー機能

リレー機能は、ノードが受信したネットワーク PDUをアドバタイジングベアラを介してリレー/転送するために使用されます。この機能はオプションであり、サポートされている場合は有効または無効にできます。プロキシ機能がサポートされている場合は、GATTとアドバタイジングベアラの両方がサポートされます。

3.4.6.2 プロキシ機能

プロキシ機能は、GATTとアドバタイジングベアラの間でノードが受信したネットワーク PDUを中継/転送するために使用されます。この機能はオプションであり、サポートされている場合は有効または無効にできます。この機能がサポートされている場合、メッシュプロキシサービス（セクション7.2を参照）が公開されます。

3.4.6.3 ネットワーク PDUの受信

メッセージは、ベアラからネットワークインターフェイスを介してネットワークレイヤーに配信されます。インターフェイスは、入力フィルタによって定義されたフィルタリングルールを適用する必要があります（セクション3.4.5.1を参照）。メッセージが入力フィルターを通過すると、さらに処理するためにネットワークレイヤーに配信されます。

受信した各ネットワーク PDUは、後でこのメッセージの処理を変更するために使用できる追加のメタデータでタグ付けできます。

メッセージを受信すると、ノードはNID フィールド値の値が1つ以上の既知のNIDと一致するかどうかを確認する必要があります。NID フィールドの値が既知のNIDと一致しない場合、メッセージは無視されます。NID フィールド値が既知の NID と一致する場合、ノードは一致した既知の各ネットワークキーに対してメッセージを認証する必要があります。メッセージが既知のネットワークキーに対して認証されない場合、メッセージは無視されます。メッセージがネットワークキーに対して認証され、 SRC フィールドと DST フィールドが有効であると見なされ（セクション3.4.3を参照）、メッセージがネットワークメッセージキャッシュにない場合（セクション3.4.6.5を参照）、下位トランスポートレイヤーによってメッセージは処理されます。

以下に定義するように、メッセージが再送信される場合、メッセージを再送信するときに使用される IV インデックスは、メッセージが受信されたときの IV インデックスと同じでなければなりません。

アドバタイジングベアラから配信されたメッセージが下位トランスポートレイヤーによって処理され、リレー機能がサポートされ有効化されており、 TTL フィールドの値が2以上であり、宛先がこのノード上の要素のユニキャストアドレスではない場合、 TTL フィールド値が1減算され、ネットワークPDUがリレーとしてタグ付けされ、ネットワーク PDU がアドバタイジングベアラに接続されているすべてのネットワークインターフェイスに再送信されます。
ネットワーク PDU を同時に受信した複数のリレー間の衝突を回避するために、ネットワーク PDU の受信とネットワーク PDU のリレーの間に小さなランダム遅延を導入することをお勧めします。

GATT ベアラから配信されたメッセージが下位トランスポートレイヤーによって処理され、プロキシ機能がサポートされ有効化されており、 TTL フィールドの値が2以上であり、宛先がこのノード上の要素のユニキャストアドレスではない場合、 TTL フィールド値は1減算され、ネットワーク PDU はすべてのネットワークインターフェイスに再送信されます。

アドバタイジングベアラから配信されたメッセージが下位トランスポートレイヤーによって処理され、プロキシ機能がサポートされ有効化されており、 TTL フィールドの値が2以上であり、宛先がこのノード上の要素のユニキャストアドレスではない場合、 TTL フィールドは1減算され、ネットワーク PDU は GATT ベアラに接続されているすべてのネットワークインターフェイスに再送信されます。

図3.8は、着信ネットワーク PDU の処理ステップの例を示しています。

3.4.6.4 ネットワーク PDUの送信

メッセージは、一意のネットワークキーによって識別されるメッシュサブネットのコンテキスト内の要素によって送信されます。

IVI フィールドは、メッシュサブネットの送信に使用されている IV インデックス値の最下位ビットに設定されます。

NID フィールドは、暗号化と難読化に使用される暗号キーとプライバシーキーに関連付けられた NID 値に設定する必要があります。

CTL フィールドは上位レイヤーによって設定されます。

TTL フィールドは上位レイヤーによって設定されます。

SEQ フィールドは、ネットワークレイヤーによって要素のシーケンス番号に設定されます。そして、シーケンス番号は、新しいネットワーク PDU ごとに1ずつ増加します。

SRC フィールドは、ネットワークレイヤーによって、このネットワーク PDU を送信している要素のユニキャストアドレスに設定されます。
DST フィールドは、宛先要素を識別するためにユニキャストアドレス、グループアドレス、または仮想アドレスに設定され、下位トランスポート、上位トランスポート、またはアクセスレイヤーによって設定されます。
TransportPDUフィールドは、上位レイヤーによって設定されます。

NetMICフィールドは、セクション3.8.7.2で定義されているように設定する必要があります。

メッセージはすべてのネットワークインターフェースに配信されます。各インターフェースは、その出力フィルターによって定義されたフィルター規則を適用するものとします（セクション3.4.5.2を参照）。ネットワークPDUが出力フィルターを通過する場合、ベアラで送信されます。

3.4.6.5 ネットワークメッセージキャッシュ

不必要なセキュリティチェックと過度の中継を減らすために、ノードは最近見られたすべてのネットワーク PDU のネットワークメッセージキャッシュを含まなければなりません。すでにネットワークメッセージキャッシュにあるネットワークPDUを受信した場合、ネットワーク PDU は処理されません（つまり、すぐに破棄されます）。ネットワーク PDU が受信され、そのネットワーク PDU がネットワークメッセージキャッシュにない場合、ネットワーク PDU を処理でき（たとえば、ネットワークセキュリティと照合されます）、有効なネットワーク PDU である場合は、ネットワークメッセージキャッシュに保存されます。

ノードはネットワーク PDU 全体をキャッシュする必要はなく、NetMIC、SRC / SEQなどの値など、追跡のためにノードの一部のみをキャッシュできます。ただし、デバイスの機能の制限内で同じネットワーク PDU を複数回処理しないという条件が達成される限り、これは実装に任されます。

ネットワークメッセージキャッシュがいっぱいで、着信する新しいネットワーク PDU をキャッシュする必要がある場合、着信する新しいネットワーク PDU は、ネットワークメッセージキャッシュにすでに存在する最も古いネットワーク PDU を置き換えます。

ネットワークメッセージキャッシュは、少なくとも2つのネットワーク PDU を格納できる必要がありますが、予想されるネットワーク密度に適したネットワークメッセージキャッシュサイズを使用することを強くお勧めします。着信メッセージ処理手順の詳細は、実装に任されています。