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

はじめに

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

• 3.6 上位トランスポートレイヤー

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

3.6 上位トランスポートレイヤー

上位トランスポートレイヤーは、アクセスレイヤーまたは内部で生成された上位トランスポートレイヤーの制御メッセージからアクセスペイロードを取得し、それらのメッセージをピアの上位トランスポートレイヤーに送信します。

アクセスレイヤーからのメッセージの場合、メッセージの暗号化と認証はアプリケーションキーを使用して実行されます。 これにより、受信側の上位トランスポートレイヤーが受信したメッセージを認証できるようになります。

上位トランスポートレイヤーによって内部的に生成されるトランスポート制御メッセージは、ネットワークレイヤーでのみ暗号化および認証されます。

3.6.1 エンディアン

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

3.6.2 上位トランスポートアクセスPDU

ネットワーク PDU の CTL フィールドが0の場合、上位トランスポートアクセス PDU にはアクセスペイロードが含まれ、上位トランスポートアクセス PDU と呼ばれます。

アクセスペイロードは、アプリケーションキーまたはデバイスキーを使用して暗号化され、暗号化されたアクセスペイロードと関連するメッセージ整合性チェック値は、上位トランスポートアクセス PDU に結合されます。 上位トランスポートアクセス PDU フィールドを表3.15に示し、図3.15に示します。

フィールド名	オクテット	説明
Encrypted Access Payload	1 to 380	暗号化されたアクセスペイロード
TransMIC	4 to 8	アクセスペイロードのメッセージ整合性 チェック値

3.6.2.1 暗号化されたアクセスペイロード

アクセスペイロードは、アクセスレイヤーによって提供されます。 TransMIC が 32 ビットの場合、アクセスペイロードの長さは 1 オクテットから 380 オクテットです。 TransMIC が 64 ビットの場合、アクセスペイロードの長さは 1 オクテットから 376 オクテットまでです。

3.6.2.2 TransMIC

トランスポートのメッセージ整合性チェック（TransMIC）は、アクセスペイロードが変更されていないことを認証する 32 ビットまたは 64 ビットのフィールドです。 SEG が 1 に設定されているセグメント化されたメッセージの場合、TransMIC のサイズは、下位トランスポート PDU の SZMIC フィールドの値によって決定されます。 セグメント化されていないメッセージの場合、TransMIC のサイズはデータメッセージの場合は 32 ビットです。

注：制御メッセージには TransMIC がありません。

3.6.3 上位トランスポート制御PDU

CTL ビットが1の場合、上位トランスポート PDU にはトランスポート制御メッセージが含まれます。 トランスポート制御メッセージには、パラメータのフォーマットを決定する7ビットのオペコードがあります。 このオペコードフィールドはパラメータフィールドには含まれていませんが、下位トランスポート PDU のセグメント化されていない制御メッセージまたはセグメント化された制御メッセージの各セグメントに含まれています。

上位トランスポート制御 PDU は、上位トランスポートレイヤーでは認証されず、代わりにネットワークレイヤーによって実行される認証に依存します。 すべての上位トランスポート制御 PDU は、64 ビットの NetMIC を使用します。

下位トランスポートレイヤーは、ネットワークレイヤーを介して配信するために、メッセージをより小さな PDU にセグメント化する場合があります。 したがって、表3.16 に反映されているように、トランスポート制御 PDU のペイロードサイズを維持することをお勧めします。ここで、値は、パケット数に応じた最大の有用なパラメータフィールドサイズを表します。

パケット数	トランスポート制御 PDU ペイロードサイズ
1	11（非セグメント化）
1	8（セグメント化）
2	16
3	24
n	n*8
32	256

上位トランスポート制御PDUの最大サイズは256オクテットです。

3.6.4 上位トランスポートレイヤーの動作

3.6.4.1 アクセスペイロードの送信

すべてのアクセスメッセージは、アプリケーションキーまたはデバイスキーのコンテキストで送信されます。アクセスペイロードは、このアプリケーションキーまたはデバイスキーを使用して暗号化され、TransMIC はセクション 3.8.6 で定義されているメッセージ整合性チェック値に設定されます。次に、上位トランスポート PDU は、セクション3.5.4.1で定義されているように処理されます。

シーケンス番号（SEQ）がこのメッセージに割り当てられます。下位トランスポートレイヤーでセグメント化されたメッセージのコンテキストでは、この SEQ は、セクション 3.5.3.1 で定義されているように、受信者がアクセスメッセージを認証および復号化するために使用されるシーケンス番号である SeqAuth の下位 24 ビットに対応します。

下位トランスポート PDU の AKF フィールドと AID フィールドは、上位トランスポート PDU の暗号化と認証に使用されるアプリケーションキーまたはデバイスキーに従って設定する必要があります。アプリケーションキーを使用する場合は、AKF フィールドを1に設定し、AIDフィールドをアプリケーションキー識別子（AID）に設定する必要があります。デバイスキーを使用する場合は、AKF フィールドを0 に設定し、AID フィールドを 0b000000 に設定する必要があります。

上位トランスポートレイヤーは、その宛先への前の上位トランスポート PDU が完了するかキャンセルされるまで、新しいセグメント化された上位トランスポート PDU を特定の宛先に送信してはなりません。

3.6.4.2 上位トランスポートPDUの受信

上位トランスポートアクセス PDU を受信すると、AKF フィールド、AID フィールドが一致するすべての既知のアプリケーションキーあるいはデバイスキーで認証されます。上位トランスポートアクセス PDU が認証され、リプレイ攻撃がチェックされている場合（セクション 3.8.8 を参照）、送信元アドレス、宛先アドレス、復号化と認証に使用されるキーなど、このメッセージのコンテキスト情報とともにアクセス層に配信されます。

上位トランスポート制御 PDU を受信すると、PDU の宛先アドレスがこのノードの要素のユニキャストアドレスと照合され、一致する場合はメッセージが処理されます（セクション 3.6.6 を参照）。

このノードがフレンド機能をサポートし、この機能が有効になっている場合、ノードは低電力ノードとフレンドシップを持っており、このメッセージの宛先アドレスは、この低電力ノードのフレンドサブスクリプションリストに現在あるアドレスであり、メッセージは適切なフレンドキューに保存されます。

3.6.5 トランスポート制御メッセージ

トランスポート制御メッセージは、単一のセグメント化されていない制御メッセージまたは一連のセグメント化された制御メッセージのいずれかを使用して送信できます。 これらの各メッセージには、パラメータフィールドのフォーマットを決定する7ビットのオペコードフィールドがあります。 各トランスポート制御メッセージは、可能な限り少ない数の下位トランスポート PDU で送信されます。

オペコード 0x00 は、下位トランスポートレイヤーで終了し、メッセージのセグメンテーションと再構成で使用され、上位トランスポートレイヤーから送信されないものとします。 他のすべての制御メッセージは、上位トランスポートレイヤーで終了します。

トランスポート制御メッセージのオペコードの要約については、表3.39を参照してください。

3.6.5.1 フレンドポーリング

フレンドポーリングメッセージは、低電力ノードによって送信され、フレンドノードに低電力ノード用に保存されたメッセージを送信するように要求します。

フレンドポーリングメッセージのパラメータは、表3.17で定義されています。

フィールド	サイズ （ビット）	説明
Padding	7	0b0000000。 他のすべての値は禁止されています。
FSN	1	フレンドシーケンス番号。フレンドノードから 低電力ノードへの以前のメッセージの受信を 確認するために使用されます

トランスポート制御メッセージの Opcode フィールドは 0x01 に設定されます。
セクション 3.6.6.4.2 で定義されているように、FSN フィールドは 0 または 1 に設定する必要があります。
このメッセージは、ネットワーク PDU の TTL フィールドを 0 に設定します。
このメッセージは、フレンドシップのセキュリティ資格情報を使用して送信されます。

3.6.5.2 フレンド更新

フレンド更新メッセージは、フレンドノードから低電力ノードに送信され、ネットワークのセキュリティパラメータ（セクション 3.6.6.1 を参照）が変更または変更されていること、またはフレンドキューが空であることを低電力ノードに通知します。

フレンド更新メッセージのパラメータは、表3.18 で定義されています。

フィールド	サイズ （オクテット）	説明
Flags	1	IV 更新フラグとキー更新フラグが含まれています
IV Index	4	フレンドノードが認識している現在の IV インデックス値
MD	1	フレンドキューが空かどうかを示します

トランスポート制御メッセージのオペコードフィールドは 0x02 に設定されます。
Flags フィールドは、表3.19 で定義されている 8 ビットフィールドです。

ビット	定義
0	キー更新フラグ 0: Not-In-Phase2 1: In-Phase2
1	IV 更新フラグ 0: 通常オペレーション 1: IV更新がアクティブ
2 – 7	将来の使用のために予約済み

キー更新フラグは、キー更新手順が進行中であるかどうかを示します（セクション 3.10.4 を参照）。

IV 更新フラグは、IV更新手順が進行中であるかどうかを示します（セクション 3.10.5 を参照）。

IV インデックスフィールドには、現在の IV インデックスが含まれます。

表3.20で定義されているように、MD フィールドは、フレンドキューが空であるかどうかを示すように設定されます。

値	説明
0	フレンドキューが空である
1	フレンドキューは空ではない
2 – 255	禁止

このメッセージは、ネットワーク PDU の TTL フィールドを 0 に設定します。

このメッセージは、フレンドシップのセキュリティ資格情報を使用して送信されます。

3.6.5.3 フレンドリクエスト

フレンドリクエストメッセージは、低電力ノードによってすべてのフレンドグループに送信され、フレンドの検索を開始します。
フレンドリクエストメッセージのパラメータは表 3.21 で定義されています。

フィールド	サイズ （オクテット）	説明
Criteria	1	フレンドシップネゴシエーションに参加するために フレンドノードがサポートする必要がある基準
ReceiveDelay	1	低電力ノードによって要求された受信遅延
PollTimeout	3	低電力ノードによって設定された PollTimeout タイマーの 初期値
PreviousAddress	2	以前のフレンドの主要要素のユニキャストアドレス
NumElements	1	低電力ノードの要素数
LPNCounter	2	低電力ノードが送信したフレンドリクエストメッセージの数

トランスポート制御メッセージのオペコードフィールドは 0x03 に設定されます。

基準フィールドのフォーマットは、表 3.22 で定義されています。

フィールド	サイズ （ビット）	説明
RFU		将来の使用のために予約済み
RSSIFactor		フレンドオファー遅延の計算で使用される フレンドノードによって測定された RSSI の 参考値
ReceiveWindowFactor		フレンドオファー遅延の計算で使用される サポートされている受信ウィンドウの参考値
MinQueueSizeLog		フレンドノードがフレンドキューに保存できる メッセージの最小数

RSSIFactor フィールドはフレンドオファー遅延の計算で使用され（セクション 3.6.6.3.1 を参照）、値は表3.23で定義されています。

値	RSSIFactor
0b00	1
0b01	1.5
0b10	2
0b11	2.5

ReceiveWindowFactor フィールドはフレンドオファー遅延の計算で使用され（セクション 3.6.6.3.1 を参照）、値は表 3.24 で定義されています。

値	Receive Window Factor
0b00	1
0b01	1.5
0b10	2
0b11	2.5

MinQueueSizeLog フィールドは log2(N) として定義されます。ここで、N は、フレンドノードがフレンドキューに格納できる最大サイズの下位トランスポート PDU の最小数であり、表 3.25 で定義されている値の 1 つを持ちます。

値	説明
0b000	禁止
0b001	N = 2
0b010	N = 4
0b011	N = 8
0b100	N = 16
0b101	N = 32
0b110	N = 64
0b111	N = 128

ReceiveDelay フィールドは、表 3.26 で定義されている有効な範囲内に設定する必要があります。

値	説明
0x00 – 0x09	禁止
0x0A – 0xFF	1ミリ秒単位の受信遅延

PollTimeout フィールドは、表 3.27 で定義されている有効な範囲内に設定する必要があります。

値	説明
0x000000 – 0x000009	禁止
0x00000A–0x34BBFF	100ミリ秒単位のPollTimeout
0x34BC00–0xFFFFFF	禁止

以前のアドレスフィールドは、以前のフレンドのユニキャストアドレス、または以前のフレンドシップが確立されていない場合は割り当てられていないアドレスに設定されます。

NumElements フィールドは、低電力ノードの要素数に設定する必要があります。この値は、このメッセージの SRC アドレスを使用して、低電力ノードに割り当てられたユニキャストアドレスの範囲を計算するためにフレンドノードによって使用されます。

NumElements の値は、表 3.28 で定義されています。

値	説明
0x00	禁止
0x01 – 0xFF	要素数

LPNCounter フィールド値は、低電力ノードがこれまでに送信したフレンドリクエストメッセージの数に設定されます。

このメッセージは、ネットワーク PDU の TTL フィールドを 0 に設定します。

このメッセージは、マスターセキュリティ資格情報を使用して送信されます。

3.6.5.4 フレンドオファー

フレンドオファーメッセージは、フレンドシップを提供するためにフレンドノードによって送信されます。

フレンドオファーメッセージのパラメータは、表3.29で定義されています。

フィールド	サイズ （オクテット）	説明
ReceiveWindow	1	フレンドノードでサポートされている 受信ウィンドウ値
QueueSize	1	フレンドノードで使用可能なキューサイズ
SubscriptionListSize	1	低電力ノードのフレンドノードでサポートできる サブスクリプションリストのサイズ
RSSI	1	フレンドノードによって測定された RSSI
FriendCounter	2	フレンドノードが送信した フレンドオファーメッセージの数

トランスポート制御メッセージのオペコードフィールドは 0x04 に設定されます。

ReceiveWindow の値は、表 3.30 で定義されています。

値	説明
0x00	禁止
0x01 – 0xFF	1ミリ秒単位の受信ウィンドウ

QueueSize フィールドには、フレンドノードが低電力ノード用に保存できるメッセージの数が含まれます。

SubscriptionListSize フィールドには、フレンドノードが低電力ノードでサポートできるサブスクリプションリストのエントリの数が含まれます。

RSSI フィールドには符号付き 8 ビット値が含まれ、dBm で測定された受信信号強度の指標として解釈されます。 これは、フレンドリクエストのフレンドノードによって測定されます。 信号強度の表示が利用できない場合、値は 0x7F（127 dBm）でなければなりません。

FriendCounter フィールド値は、フレンドノードが送信したフレンドオファーメッセージの数に設定されます。

このメッセージは、ネットワーク PDU の TTL フィールドを 0 に設定します。

このメッセージは、マスターセキュリティ資格情報を使用して送信されます。

3.6.5.5 フレンドクリア

フレンドクリアメッセージがフレンドノードに送信され、フレンドシップの削除について通知されます。

フレンドクリアメッセージのパラメータは、表 3.31 で定義されています。

フィールド	サイズ （オクテット）	説明
LPNAddress	2	削除される低電力ノードのユニキャストアドレス
LPNCounter	2	新しい関係の LPNCounter の値

トランスポート制御メッセージのオペコードフィールドは 0x05 に設定されます。

LPNAddress フィールドは、削除される低電力ノードのユニキャストアドレスに設定されます。

LPNCounter フィールドは、関係の確立に使用された最新のフレンドリクエストの LPNCounter 値に設定されます。

これは確認済みメッセージであり、送信ノードは応答としてフレンドクリア確認メッセージを受信することを期待しています。 フレンドノードが応答を受信しない場合、新しいフレンドノードは、応答を受信するか、低電力ノードのポーリングタイムアウトに達するまで、2倍の間隔（2、4、8、16秒など）でメッセージを再送信する必要があります。 。

このメッセージは、マスターセキュリティ資格情報を使用して送信されます。

3.6.5.6 フレンドクリア確認

フレンドクリア確認メッセージは、フレンドシップが終了したことを確認するために、フレンドクリアメッセージに応答して古いフレンドノードによって送信されます。 フレンドクリアメッセージが TTL 0 で受信された場合、確認では TTL 0 も使用する必要があります。

フレンドクリア確認メッセージパラメータは、表 3.32 で定義されています。

フィールド	サイズ （オクテット）	説明
LPNAddress	2	削除される低電力ノードのユニキャストアドレス
LPNCounter	2	対応するフレンドクリアメッセージの LPNCounter の値

トランスポート制御メッセージのオペコードフィールドは 0x06 に設定されます。

LPNAddress フィールドは、削除された低電力ノードのユニキャストアドレスに設定されます。

LPNCounter フィールドは、対応するフレンドクリアメッセージの LPNCounter 値に設定されます。

メッセージは、前のフレンド関係のポーリングタイムアウト内に受信した有効なフレンドクリアメッセージに応答してのみ送信する必要がありますが、その期間に受信した有効なフレンドクリアメッセージごとにフレンドクリア確認メッセージを送信する必要があります。 フレンドクリアメッセージ（フレンドシップを開始したもの）の LPNCounter フィールドの値をフレンドクリアメッセージの LPNCounter フィールドの値から差し引いた結果が 65536 を法とする場合、フレンドクリアメッセージは有効であると見なされます。 0 から 255 までの範囲。

このメッセージは、マスターセキュリティ資格情報を使用して送信されます。

3.6.5.7 フレンドサブスクリプションリスト追加

フレンドサブスクリプションリスト追加メッセージは、低電力ノードからフレンドノードに送信され、メッセージが保存されるグループアドレスと仮想アドレスのリストを示します。

フレンドサブスクリプションリストの追加メッセージパラメータは、表 3.33 で定義されています。

フィールド	サイズ （オクテット）	説明
TransactionNumber	1	トランザクションを識別するための番号
AddressList	2*N	グループアドレスと仮想アドレスのリスト。 ここで、Nはこのメッセージ内のグループアドレスと 仮想アドレスの数です。

トランスポート制御メッセージのオペコードフィールドは 0x07 に設定されます。

TransactionNumber フィールドは、個々のトランザクションを区別するために使用されます（セクション3.6.6.4.3を参照）。

AddressList フィールドには、フレンドサブスクリプションリストに追加するグループアドレスと仮想アドレスのリストが含まれている必要があります。

注：このメッセージがセグメント化されていない制御メッセージとして送信される場合、AddressList フィールドに5つを超えるアドレスを含めることはできません。

このメッセージは、ネットワーク PDU の TTL フィールドを 0 に設定します。

このメッセージは、フレンドシップのセキュリティ資格情報を使用して送信されます。

3.6.5.8 フレンドサブスクリプションリスト削除

フレンドサブスクリプションリストの削除メッセージは、低電力ノードからフレンドノードに送信され、フレンドサブスクリプションリストから削除するグループアドレスと仮想アドレスを示します。

フレンドサブスクリプションリストの削除メッセージパラメータは、表 3.34 で定義されています。

フィールド	サイズ （オクテット）	説明
TransactionNumber	1	トランザクションを識別するための番号
AddressList	2*N	グループアドレスと仮想アドレスのリスト。 ここで、Nはこのメッセージ内のグループアドレスと 仮想アドレスの数です。

トランスポート制御メッセージのオペコードフィールドは 0x08 に設定されます。

TransactionNumber フィールドは、個々のトランザクションを区別するために使用されます（セクション 3.6.6.4.3 を参照）。

AddressList フィールドには、フレンドサブスクリプションリストから削除するグループアドレスと仮想アドレスのリストが含まれている必要があります。

注：このメッセージがセグメント化されていない制御メッセージとして送信される場合、AddressList フィールドに 5 つを超えるアドレスを含めることはできません。

このメッセージは、ネットワーク PDU の TTL フィールドを 0 に設定します。

このメッセージは、フレンドシップのセキュリティ資格情報を使用して送信されます。

3.6.5.9 フレンドサブスクリプションリストの確認

フレンドサブスクリプションリストの確認メッセージは、フレンドノードから低電力ノードに送信され、フレンドサブスクリプションリストの追加メッセージまたはフレンドサブスクリプションリストの削除メッセージに応答します。

トランスポート制御メッセージのオペコードフィールドは 0x09 に設定されます。

フレンドサブスクリプションリストの確認メッセージパラメータは、表 3.35 で定義されています。

フィールド	サイズ （オクテット）	説明
TransactionNumber	1	トランザクションを識別するための番号

TransactionNumber フィールドは、個々のトランザクションを区別するために使用されます（セクション 3.6.6.4.3 を参照）。

このメッセージは、ネットワーク PDU の TTL フィールドを 0 に設定します。

このメッセージは、フレンドシップのセキュリティ資格情報を使用して送信されます。

3.6.5.10 ハートビート

ハートビートメッセージはノードによって送信され、他のノードがサブネットのトポロジを決定できるようにします。

ハートビートメッセージのパラメータは、表 3.36 で定義されています。

フィールド	サイズ （オクテット）	説明
RFU	1	将来の使用のために予約済み
InitTTL	7	メッセージの送信時に使用される初期 TTL
Features	16	ノードの現在アクティブな機能の ビットフィールド

トランスポート制御メッセージのオペコードフィールドは 0x0A に設定されます。

InitTTL の値は、表 3.37 で定義されています。

値	説明
0x00 – 0x7F	メッセージ送信時の初期TTL

InitTTL フィールドには、メッセージの送信時に使用される初期TTLが含まれます。

Features フィールドには、セクション3.1で定義されているように、ノードが現在使用している機能を示すビットフィールドが含まれています。 Features フィールドの形式は、表 3.38 で定義されています。

ビット	機能	説明
0	Relay	使用中のリレー機能： 0 = False、1 = True
1	Proxy	使用中のプロキシ機能： 0 = False、1 = True
2	Friend	使用中のフレンド機能： 0 = False、1 = True
3	Low Power	使用中の低電力機能： 0 = False、1 = True
4 – 15	RFU	将来の使用のために予約済み

3.6.5.11 オペコードの要約

表3.39に、トランスポート制御メッセージで使用されるオペコードの要約を示します。

値	オペコード	説明
0x00	ー	下位のトランスポート層用に予約済み
0x01	Friend Poll	低電力ノードからそのフレンドノードに送信され、 低電力ノード用に保存されているメッセージを 要求します。
0x02	Friend Update	フレンドノードから低電力ノードに送信され、 セキュリティアップデートについて通知されます。
0x03	Friend Request	低電力ノードによってすべてのフレンドの 固定グループアドレスに送信され、 フレンドの検索を開始する。
0x04	Friend Offer	フレンドノードから低電力ノードに送信され、 フレンドになることを提案します
0x05	Friend Clear	フレンドノードにフレンドシップの削除について 低電力ノードの以前のフレンドを通知する。
0x06	Friend Clear Confirm	以前のフレンドからフレンドノードに 以前のフレンドシップが削除されたことを 通知する
0x07	Friend Subscription List Add	フレンドノードにフレンドサブスクリプション リストに1つ以上のアドレスを追加するために 送信する
0x08	Friend Subscription List Remove	フレンドノードにフレンドサブスクリプション リストから1つ以上のアドレスを削除するために 送信する
0x09	Friend Subscription List Confirm	フレンドサブスクリプションリストの更新を 確認するためにフレンドノードから送信する
0x0A	Heartbeat	他のノードがサブネットのトポロジを決定するために ノードによって送信する
0x0B – 0x7F	RFU	将来の使用のために予約済み

3.6.6 フレンドシップ

フレンドノードは、低電力ノードのメッセージを保存することができます。

3.6.6.1機能の概要

低電力ノードの消費電力を最適化するために、ポーリングメカニズムを使用して低電力ノードの受信ウィンドウを最小化します。 これにより、低電力ノードは、メッセージの受信が可能になる時期を示すことにより、フレンドノードから更新を受信できます。

フレンドシップは、低電力ノードとフレンドノード間のフレンド関係の期間中、静的であるタイミングパラメータを定義します。

フレンドシップでは、次のタイミングパラメータが使用されます。

• ReceiveDelay
• ReceiveWindow
• PollTimeout

ReceiveDelay は、低電力ノードが要求を送信してから応答をリッスンするまでの時間です。 この遅延により、フレンドノードは応答を準備する時間を確保できます。

ReceiveWindow は、低電力ノードが応答をリッスンする時間です。 低電力ノードは、フレンドノードからメッセージを受信すると、追加のメッセージのリッスンを停止できます。

リクエストには、フレンドポーリングメッセージ、フレンドサブスクリプションリスト追加メッセージ、またはフレンドサブスクリプションリスト削除メッセージを指定できます。 フレンドポーリングメッセージへの応答は、フレンド更新メッセージまたは保存されたメッセージにすることができます。 フレンドサブスクリプションリストの追加メッセージまたはフレンドサブスクリプションリストの削除メッセージへの応答は、フレンドサブスクリプションリストの確認メッセージです。

タイミングパラメータを図 3.17 に示します。

PollTimeout タイマーは、低電力ノードによって送信された2つの連続する要求間の時間を測定するために使用されます。 PollTimeout タイマーの期限が切れる前にフレンドノードがリクエストを受信しなかった場合、フレンドシップは終了したと見なされます。 これを図 3.18 に示します。

フレンドシップを確立するために、低電力機能をサポートするノードは、フレンドリクエストをすべてのフレンドアドレスに送信します。メッセージは、フレンド機能をサポートするこのノードの無線範囲内のすべてのノードによってピックアップされます。

フレンドリクエストメッセージには、このノードが将来のフレンドノードでサポートする必要がある要件を定義するいくつかのパラメータが含まれています。フレンド機能をサポートし、フレンドリクエストメッセージの要件をサポートできる各ノードは、フレンドオファーメッセージをリクエストしているノードに送り返すことで応答します。オファーには、各オファーリングノードの機能に関する追加情報も含まれています。これにより、低電力ノードは、これらのオファーのどれを受け入れるかを決定できます。

次に、低電力ノードは、選択したフレンドノードにフレンドポーリングメッセージを送信し、フレンドノードはフレンド更新メッセージで応答します。この時点で、図3.19に示すように、フレンドシップが確立されます。

低電力ノードが以前に別のフレンドノードのフレンドであった場合、新しいフレンドノードは古いフレンドノードに、現在はこの低電力ノードの現在のフレンドであることを通知します（セクション 3.6.6.3.1 を参照）。

フレンドシップが確立されると、フレンドノードは低電力ノードのフレンドサブスクリプションリストを保存します。これは、低電力ノードがサブスクライブされているグループアドレスと仮想アドレスのコレクションです。このリストにより、フレンドノードは低電力ノードがサブスクライブしているメッセージを保存できます。

特定の NetKey の IV インデックス、IV 更新フラグ、およびキー更新フラグの値は、セキュリティパラメータと呼ばれます。セキュリティパラメータの値の少なくとも1つが変更されるたびに、新しいセキュリティパラメータはセキュリティ更新と呼ばれます。

フレンドノードは、低電力ノードのすべてのメッセージと、低電力ノードの最新のセキュリティ更新をフレンドキューに保存します。これらを総称して、保存されたメッセージと呼びます。

保存されたメッセージを取得するために、低電力ノードはフレンドポーリングメッセージを送信し、フレンドノードは保存されたメッセージで応答します。

フレンドキューに保存されたメッセージは、確認応答とともに順番に低電力ノードに配信されます。 これを適切に行うために、フレンドシーケンス番号が使用されます。 この値は低電力ノードに保存され、各フレンドポーリングメッセージで送信されます。 低電力ノードがフレンドポーリングに応答してメッセージを受信し、このメッセージがフレンドシップセキュリティ資格情報を使用して正常に認証された場合、低電力ノードはこのフレンドシーケンス番号を変更する必要があります。 この低電力ノードが次にポーリングするときに、フレンドノードは次のメッセージを送信できます。 フレンドポーリングメッセージへの応答がなかった場合、低電力ノードはフレンドシーケンス番号を変更せず、フレンドノードは送信した最後のメッセージが受信されなかったと判断して再送信できます。

3.6.6.2 フレンドシップのセキュリティ

フレンドノードと低電力ノードの間にフレンドシップが確立されると、フレンドノードから低電力ノードへのすべてのネットワークメッセージは、フレンドシップセキュリティ資格情報から作成されたフレンドシップセキュリティマテリアルを使用して保護されます（セクション 3.8.6.3.1 を参照）。フレンドシップのセキュリティ資格情報は、低電力確立手順中に交換されます（セクション 3.6.6.4.1 を参照）。

フレンドポーリング、フレンド更新、フレンドサブスクリプションリストの追加/削除/確認メッセージ、およびフレンドノードが低電力ノードに配信する保存済みメッセージは、常にフレンドシップセキュリティ資格情報を使用して暗号化されます。 フレンドクリアおよびフレンドクリア確認メッセージは、常にマスターセキュリティ資格情報を使用して暗号化されます。

フレンドシップ資格情報の公開フラグの値（セクション 4.2.2.4 を参照）に応じて、低電力ノードはフレンドシップセキュリティ資格情報またはマスターセキュリティ資格情報のいずれかを使用してメッセージを送信します（セクション 3.8.6.3.1 を参照）。

他のすべてのネットワークメッセージは、マスターセキュリティ資格情報を使用して送信されます。

図 3.20 は、フレンドシップセキュリティ資格情報（破線）とマスターセキュリティ資格情報（実線）を使用して保護されたメッセージを示しています。低電力ノードは、マスターセキュリティ資格情報を使用してフレンドリクエストメッセージを送信することから始まります。フレンドノードは、再びマスターセキュリティ資格情報を使用してフレンドオファーメッセージで応答します。低電力ノードとフレンドノードの両方でマスターセキュリティ資格情報を使用する必要があります。どちらのデバイスも他方とフレンドシップを持っていないため、フレンドシップセキュリティ資格情報を使用できないためです。低電力ノードは友情の申し出を受け入れ、友情のセキュリティ資格情報を使用してこれを確認するために友情投票を送信します。フレンドノードは、フレンド更新メッセージを使用してこれに応答します。低電力ノードは、フレンドノードからのフレンドサブスクリプションリスト確認メッセージを使用して確認されたフレンドサブスクリプションリスト追加メッセージを使用して、フレンドサブスクリプションリストを構成できるようになりました。これらのメッセージは両方とも、フレンドシップセキュリティ資格情報を使用して送信されます。

しばらくして、フレンドノードは別のデバイスから低電力ノードに配信する必要のあるメッセージ（InMsg）を受信するため、このメッセージをフレンドキューに保存します。 低電力ノードは、フレンドシップセキュリティ資格情報を使用して保護されたフレンドポーリングメッセージを送信します。このメッセージに、フレンドノードは保存された InMsg で応答します。

次に、低電力ノードは、OutMsg1 と OutMsg2 の2つのメッセージを送信することを決定します。 OutMsg1 は、フレンドセキュリティ資格情報を使用してセキュリティで保護されて送信されるため、フレンドノードのみがこのメッセージを受信して中継します。 フレンドノードが OutMsg1 を中継すると、マスターセキュリティ資格情報を使用してメッセージが再送信されます。 OutMsg2 は、マスターセキュリティ資格情報を使用してセキュリティで保護されて送信されるため、フレンドノードおよび低電力ノードの範囲内の他のリレーノードはメッセージをリレーできます。 OutMsg2 は、中継されると、マスターセキュリティ資格情報を使用して再送信されます。

3.6.6.3 フレンド機能

フレンド機能は、フレンドの確立、フレンドメッセージング、およびフレンド管理の3つの必須操作を定義します。フレンドノードによって発信されたすべてのトランスポート制御メッセージは、SRC フィールドがフレンドノードのプライマリ要素のユニキャストアドレスに設定されたセグメント化されていない制御メッセージとして送信されます。

3.6.6.3.1 フレンドの確立

フレンド機能をサポートし、機能が有効になっていて、フレンドリクエストメッセージ（セクション 3.6.5.3 を参照）を受信し、メッセージパラメータで指定された最小要件を満たすノードは、フレンドオファーメッセージ（セクション 3.6.5.4 を参照）で応答するものとします。

フレンドリクエストメッセージの送信元アドレスが、現在フレンドノードとフレンドシップにあるローパワーノードのアドレスである場合、フレンドノードはその低電力ノードが終了した既存のフレンドシップも考慮します。
フレンドオファーメッセージは、フレンドリクエストメッセージの送信元アドレスに等しい宛先と 0 に設定された TTL 値で送信されます。

ノードは、0 に初期化された 2 オクテット値であるフレンドノードカウンター（FriendCounter）を保持するものとします。この値は、フレンドオファーメッセージで送信され、フレンドオファーメッセージの結果としてフレンドシップが確立された場合に、フレンドシップセキュリティ資料を導出するために使用されます。各フレンドオファーメッセージが送信された後、FriendCounter 値は 1 ずつ増加します。FriendCounter はラップする場合があります。

フレンドリクエストメッセージを受信してからフレンドオファーメッセージを送信するまでの時間はフレンドオファー遅延と呼ばれ、サポートされている ReceiveWindow のフレンドリクエストメッセージとによって測定された RSSI で定義されている RSSIFactor フィールドと ReceiveWindowFactor フィールドに基づいてフレンドリクエストメッセージのフレンドノードによって計算されます。

フレンドオファー遅延により、低電力ノードは、提供された ReceiveWindow の大きさ、および信号品質の重要性を判断するために、潜在的なフレンドノードからフレンドオファーメッセージを受信できます。 一部の低電力ノードは、ReceiveWindow が非常に小さい フレンドノードを優先するため、ReceiveWindowFactor を RSSIFactor よりも重要に設定します。他の低電力ノードは、信号強度が非常に良好なフレンドを優先するため、RSSIFactor を ReceiveWindowFactor よりも重要に設定します。 つまり、低電力ノードは、低電力ノードの要件に一致するノードのフレンドオファーをフレンドからより早く受信し、フレンドノードを検索するときに低電力ノードが消費する電力を削減する必要があります。

ローカル遅延は、次の式で計算されます。
ローカル遅延 = ReceiveWindowFactor * ReceiveWindow-RSSIFactor * RSSI
ここで：
ReceiveWindowFactor は、フレンドリクエストメッセージからの番号です。
ReceiveWindow は、対応するフレンドオファーメッセージで送信される値です。
RSSIFactor は、フレンドリクエストメッセージの番号です。
RSSI は、フレンドノードで受信したフレンドリクエストメッセージの受信信号強度です。

ローカル遅延値が 100 より大きい場合、ミリ秒単位のフレンドオファー遅延値はローカル遅延値に設定されます。 それ以外の場合、フレンドオファー遅延は 100 ミリ秒に設定されます。

ノードがフレンドオファーメッセージを送信してから1秒以内にフレンドポーリングメッセージを受信すると、フレンドシップが確立され、ノードはこのフレンドポーリングメッセージから FSN フィールド値を保存します。 そうでなければ、確立は失敗します。

フレンドノードは、低電力ノードからのフレンドポーリングメッセージの受信から、最小の  ReceiveDelay ミリ秒の後、最大の ReceiveDelay ミリ秒と ReceiveWindow ミリ秒の合計の前にフレンド更新メッセージで応答するものとします。

図 3.21 は、フレンド機能が有効になっている複数のノードが同じフレンドリクエストメッセージを受信するフレンドシップの確立を示しています。

フレンドシップが確立された後、フレンドノードはフレンドサブスクリプションリストを長さゼロ（空）のリストに初期化し、低電力ノードのメッセージをフレンドキューに保存し始めます。

フレンドシップが確立された後、フレンドリクエストメッセージの PreviousAddress フィールドに、フレンドノード自身のユニキャストアドレスではない有効なユニキャストアドレスが含まれている場合、
フレンドノードは、以下の手順に従って、そのユニキャストアドレスへのフレンドクリアメッセージ（セクション 3.6.5.5 を参照）の送信を開始します。

1. TTL は有効な最大値に設定されます。
2. 最初のフレンドクリアメッセージは、フレンドシップが確立されるとすぐに送信されます。 同時に、フレンドクリアリピートタイマーは 1 秒に設定された期間で開始され、フレンドクリア手順タイマーはフレンドポーリングタイムアウト値の 2 倍に等しい期間で開始されます。
3. フレンドクリアメッセージ（セクション 3.6.5.6 を参照）に応答してフレンドクリア確認メッセージを受信した場合、両方のタイマーがキャンセルされ、手順が完了します。
4. フレンドクリアリピートタイマーが時間切れになると、新しいフレンドクリアメッセージが送信され、タイマーは前のフレンドクリアリピートタイマー期間の2倍の期間で再開されます。 たとえば、最初の有効期限が切れた後、期間は 2 秒に設定されます。 次の有効期限では、4 秒に設定されます。
5. フレンドクリア手順タイマーが時間切れになると、フレンドクリアリピートタイマーがキャンセルされ、手順が完了します。

この手順の例を図 3.22 に示します。
フレンドシップが確立されると、フレンドノードはフレンドメッセージング（セクション 3.6.6.3.2 を参照）で定義されているように低電力ノードと通信し、フレンド管理（セクション 3.6.6.3.3 を参照）で定義されているように管理できます。

3.6.6.3.2 フレンドメッセージング

フレンドノードが、低電力ノードから受信した最後のフレンドポーリングメッセージと同じ FSN フィールド値を持つフレンド低電力ノードからフレンドポーリングメッセージを受信すると、そのメッセージが破棄されていない限り、フレンドノードは以前に送信したのとまったく同じメッセージで応答する必要があります。以前に送信されたメッセージが破棄された場合、フレンドキュー内の最も古いエントリが送信されます。

フレンドノードは、低電力ノードからの最後のフレンドポーリングメッセージとは異なるFSNフィールド値を持つフレンド低電力ノードからフレンドポーリングメッセージを受信すると、フレンドキューから最も古いメッセージを送信します。

保存されたメッセージを低電力ノードに送信する場合、メッセージは変更されずに送信されます。フレンドノードの IV インデックスが変更された場合、たとえば、ノードが新しい IV インデックスで送信している場合、低電力ノードに送信されるメッセージは、フレンドノードがそれらに対して受信したIVインデックスのコンテキストで送信されます。

注：上記の要件は、低電力ノードが少なくとも 96 時間に 1 回、保存されているすべてのメッセージを収集する必要があることを意味します。そうしないと、フレンドノードが保存されたメッセージを破棄してから低電力ノードがメッセージを受信する可能性があります。

各メッセージは、フレンドの低電力ノードからのフレンドポーリングメッセージの受信から、最小のReceiveDelay ミリ秒の後、最大の ReceiveDelay ミリ秒と ReceiveWindow ミリ秒の合計のより前に送信されるものとします。

PollTimeout タイマーの期限が切れる前に、フレンドポーリング、フレンドサブスクリプションリストの追加、またはフレンドサブスクリプションリストの削除メッセージがフレンドノードによって受信されない場合、フレンドシップは終了し、フレンドノードはフレンドキュー内のすべてのエントリを破棄します。

フレンドサブスクリプションリスト確認メッセージは、フレンドサブスクリプションリスト追加メッセージまたはフレンドサブスクリプションリスト削除メッセージの受信から、最小 ReceiveDelay ミリ秒後、ReceiveDelay ミリ秒と ReceiveWindow ミリ秒の合計の最大より前に送信されるものとします。

フレンドノードがフレンドクリアメッセージを受信し、LPNAddress フィールドがフレンド低電力ノードであり、LPNCounter フィールドが（セクション 3.6.5.6 ）で定義された範囲内にある場合、フレンドシップは終了し、フレンドノードはフレンドキュー内のすべてのエントリを破棄します。

3.6.6.3.3 フレンド管理

フレンドノードが低電力ノードからフレンドサブスクリプションリスト追加メッセージ（セクション3.6.5.7 を参照）を受信した場合、メッセージに含まれるアドレスまたはアドレスのリストをフレンドサブスクリプションリストに追加し、フレンドサブスクリプションリストで応答するものとします。 メッセージ（セクション 3.6.5.9 を参照）は、TransactionNumber フィールドの値を受信したフレンドサブスクリプションリスト追加メッセージと同じ値に設定します。

フレンドノードが低電力ノードからフレンドサブスクリプションリスト削除メッセージ（セクション3.6.5.8 を参照）を受信した場合、メッセージに含まれているアドレスまたはアドレスのリストをフレンドサブスクリプションリストから削除するものとします。そして、TransactionNumber フィールドの値を受信したフレンドサブスクリプションリスト削除メッセージと同じ値に設定するフレンドサブスクリプションリスト確認メッセージで応答します。

フレンドノードは、低電力ノードからのフレンドポーリングメッセージの受信から、最小のReceiveDelay ミリ秒の後、最大の ReceiveDelay ミリ秒と ReceiveWindow ミリ秒の合計より前にフレンド更新メッセージで応答するものとします。

3.6.6.4 低電力機能

低電力機能をサポートするノードは、低電力確立、低電力メッセージング、および低電力管理の3つの必須操作をサポートする必要があります。

低電力ノードによって発信されたすべてのトランスポート制御メッセージは、SRC フィールドが低電力機能をサポートするノードのプライマリ要素のユニキャストアドレスに設定されたセグメント化されていない制御メッセージとして送信されます。

3.6.6.4.1 低電力の確立

低電力確立操作は、低電力機能をサポートするノードとフレンド機能をサポートするノード間のフレンドシップを確立するために使用されます。

この操作は、フレンドリクエストメッセージを送信することで開始されます。

フレンドリクエストメッセージは、TTL を 0 に設定し、DST フィールドをすべてのフレンドアドレスに設定して送信されます。 ノードは、0 に初期化された 2 オクテット値である低電力ノードカウンター（LPNCounter）を保持する必要があります。この値は、フレンドリクエストメッセージで送信され、フレンドリクエストメッセージの結果としてフレンドシップが確立された場合に、フレンドシップセキュリティコンテキストを導出するために使用されます。 各フレンドリクエストメッセージが送信された後、この値は 1 ずつ増加します。LPNCounter はラップする場合があります。

フレンドリクエストから 100 ミリ秒が経過した後、ノードは潜在的なフレンドノードによって送信されたフレンドオファーメッセージを最大 1 秒間リッスンする必要があり、フレンドシップを確立するためにフレンドノードの1つを選択できます。 低電力ノードは、受信したフレンドオファーを受け入れるか、比較のために他のフレンドオファーメッセージを引き続きリッスンする場合があります。

受け入れ可能なフレンドオファーメッセージが受信されない場合、ノードは新しいフレンドリクエストメッセージを送信する場合があります。 2 つの連続するフレンドリクエストメッセージ間の時間間隔は 1.1 秒より長くなければなりません。

フレンドオファーメッセージを送信した潜在的なフレンドとのフレンドシップを確立するために、ノードはフレンドシーケンス番号をゼロに設定し、フレンドオファーメッセージの受信後 1 秒以内に選択したフレンドノードにフレンドポーリングメッセージを送信する必要があります。 フレンドアップデートメッセージが応答で受信されると、フレンドシップが確立され、それをサポートするノードの低電力機能が使用され、それをサポートするノードのフレンド機能が使用されます。

ノードは、数回の試行（6 回の試行など）後にフレンド更新メッセージを受信しない場合、低電力確立操作を再開する必要があります。

低電力確立操作の複数の障害は、低電力ノードに有効な IV インデックスがなく、IV インデックス回復手順を開始する必要があることを示している可能性があります（セクション 3.10.6 を参照）。

フレンドシップが確立されると、低電力ノードは、低電力メッセージング（セクション 3.6.6.4.2 を参照）で定義されているようにフレンドノードと通信し、低電力管理（セクション 3.6.6.4.3 を参照）で定義されているようにフレンドシップを管理できます。

3.6.6.4.2 低電力メッセージング

低電力メッセージング操作は、低電力ノードによって実行され、フレンドノードから保存されたメッセージとセキュリティ更新を受信します。

この操作は、低電力ノードからフレンドノードへの非同期要求と、フレンドノードから低電力ノードへの定期的応答で構成されます。

フレンドノードとフレンドである低電力ノードは、PollTimeout タイマーが期限切れになる前に、フレンドポーリングメッセージをフレンドノードに送信する必要があります。

フレンドポーリングメッセージでは、TTL フィールドは 0 に設定されます。
原則として、低電力ノードは、MD フィールドが 0 に設定されたフレンド更新メッセージを受信するまでフレンドポーリングメッセージを送信し続ける必要があります。これを図3.23に示します。

低電力ノードは、フレンドクリアを送信することにより、フレンドとのフレンドシップを終了できます。 フレンドクリアメッセージは、TTL 0 を使用して送信する必要があります。

FSN フィールドは、フレンドシーケンス番号の値に設定されます。

低電力ノードがフレンドノードから応答を受信し、その応答が最後に受信した下位トランスポート PDU の複製ではない場合、フレンドシーケンス番号を切り替えます。

低電力ノードが ReceiveWindow 内で応答を受信しない場合は、FriendPoll メッセージを再送信する必要があります。 このメッセージを 3 回再送信することをお勧めします。これにより、信頼性と消費電力のバランスが取れます。

PollTimeout タイマーの期限が切れる前に、複数の Friend Poll メッセージに対する応答が受信されなかった場合、フレンドシップは終了します。 低電力ノードは、低電力確立操作を繰り返す場合があります。

低電力ノードがフレンド更新メッセージを受信した場合、セキュアネットワークビーコンで受信された場合と同じルールを使用して、フラグフィールドと IV インデックスフィールドを処理します（セクション 3.9.3.1、3.10.4、および 3.10.5 を参照）。

3.6.6.4.3 低電力管理

低電力管理操作は、フレンドノードのサブスクリプションリストを管理するために使用されます。

低電力ノードは、低電力ノードがサブスクライブしているグループアドレスまたは仮想アドレスのリストを含む 1 つまたは複数のフレンドサブスクリプションリスト追加メッセージをフレンドノードに送信する場合があります。このタイプのメッセージは、サブスクリプションが変更されたときに、低電力ノードによっていつでも送信される可能性があります。

低電力ノードは、低電力ノードがサブスクライブしなくなったグループアドレスまたは仮想アドレスのリストを含む 1 つ以上のフレンドサブスクリプションリスト削除メッセージをフレンドノードに送信する場合があります。このタイプのメッセージは、サブスクリプションが変更されたときに、低電力ノードによっていつでも送信される可能性があります。

低電力ノードは、TransactionNumber 値を 0x00 に設定して開始する必要があります。新しいフレンドサブスクリプションリストの追加またはフレンドサブスクリプションリストの削除ごとに TransactionNumber をインクリメントして、TransactionNumber がフレンドサブスクリプションリストの確認メッセージの TransactionNumber フィールドと一致するようにします。

3.6.6.5 セグメンテーションと再組み立ての例

セクション 3.5.3.3 および 3.5.3.4 で定義されているセグメンテーションおよび再アセンブリの動作は、低電力ノードとの間で送受信されるセグメント化されたメッセージにも適用されます。 唯一の違いは、低電力ノードがセグメントとセグメント確認応答を含むすべての着信メッセージをフレンドキューに依存しているため、フレンドノードが低電力ノードのセグメント化されたトランザクションを確認応答することです。

このセクションでは、低電力ノードでのセグメンテーションと再アセンブリの 2 つの例を示します。

3.6.6.5.1 受信セグメント化メッセージ

図3.24 のメッセージシーケンスチャート（MSC）は、低電力ノードに向けられたセグメント化されたメッセージの例です。フレンドノードは個別に再構成を実行し、すべてのセグメントを受信するまで必要な確認応答を送信します。受信した時点で、フレンドノードはセグメントをフレンドキューに配置して、低電力ノードに配信できるようにします。 別のソースからのセグメント化されていないメッセージは、トランザクションの途中で受信され、独立して処理されます。

3.6.6.5.2 送信セグメント化メッセージ

図3.25 に示す MSC は、低電力ノードによって送信されるセグメント化されたメッセージの例を示しています。低電力ノードは、すべての着信メッセージをフレンドキューに依存しているため、確認応答もポーリングする必要があります。 別のソースからのセグメント化されていないメッセージは、トランザクションの途中で受信され、独立して処理されます。

3.6.7 ハートビート

ハートビートは、ネットワーク上のノードを監視し、ノードが互いにどれだけ離れているかを検出するために使用されます。

3.6.7.1 機能の概要

ノードがメッシュネットワーク内にまだ存在してアクティブであるかどうかを判断するには、このノードからメッセージを受信する必要があります。 メッシュネットワーク内のすべてのノードにメッセージを送信して応答を引き出すことは、エネルギーの浪費になります。したがって、各ノードは、単一のメッセージを定期的に送信するように構成できます。 このメッセージはハートビートメッセージと呼ばれます。

ハートビートメッセージは、2 つの主要な機能に使用できます。 最初の機能は、ノードがメッシュネットワーク内でまだアクティブであるかどうかを判断することです。 2 番目の関数は、ノードがどれだけ離れているかを判断することです。

ハートビートメッセージは、構成サーバーモデルで構成されているように、定期的に送信されます。 ハートビートメッセージは、限られた回数だけ送信することも、無期限に送信することもできます。 ハートビートメッセージは設定された宛先に送信されます。ハートビートメッセージの送信にはグループアドレスを使用することをお勧めします。 メッセージは、特定のTTL値で構成することもできます。

ハートビートメッセージを受信すると、カウントされます。 受信したハートビートメッセージの数は、ハートビートメッセージを送信するノードからメッセージを配信するためのメッシュネットワークの信頼性を判断するのに役立ちます。

各ハートビートメッセージには、元のハートビートメッセージを送信するときに使用される初期TTL値が含まれています。 これにより、受信デバイスは、ホップ数と呼ばれるこのメッセージが再送信された回数を判別できます。また、ホップの最小数と最大数の記録を使用して、メッシュネットワークの信頼性を判別することもできます。

したがって、ハートビートメッセージの使用を使用して、特定のノードのアドレス指定に使用するのに最適なTTL値を決定できます。

ハートビートメッセージには、現在使用されているノードの機能も含まれます。 さまざまな機能が有効または無効になっているときにハートビートメッセージを送信するようにノードを構成できます。 これにより、メッシュネットワーク内のさまざまなノードで利用可能な機能を決定できます。

3.6.7.2 ハートビートメッセージの公開

ハートビートメッセージの公開は、ハートビート公開状態によって制御されます（セクション 4.2.17 を参照）。

ハートビート公開先（セクション 4.2.17.1 を参照）アドレスが割り当てられていないアドレスに設定されている場合、ハートビートメッセージは公開されません。 ハートビート公開カウント状態の値（セクション4.2.17.2を参照）が 0x0000 の場合、定期的なハートビートメッセージは公開されません。

ハートビートメッセージは、DST フィールドをハートビート公開状態の値に設定し、TTL フィールドをハートビート公開 TTL 状態の値に設定して発行する必要があります（セクション 4.2.17.4 を参照）。

ハートビートメッセージの定期的な公開は、ハートビート公開カウント状態によって有効になります（セクション 4.2.17.2 を参照）。 ハートビートメッセージを公開した後、ハートビート公開カウントカウンターが 0xFFFF 未満の場合、ハートビート公開カウントカウンターは 1 減少します。カウンターは 0x0000 で停止します。 最初のハートビートメッセージは、ハートビート公開期間の状態（セクション4.2.17.3 を参照）が定期的な公開用に構成された後、できるだけ早く公開されるものとします。 次のハートビートメッセージは、ハートビート公開期間の状態で定義された秒数の後に公開されます（セクション 4.2.17.3 を参照）。

ハートビートメッセージのトリガーされた公開は、ハートビート公開機能の状態によって有効になります（セクション4.2.17.5を参照）。

• リレービットが 1 に設定されている場合、ノードのリレー状態（セクション4.2.8を参照）が変更されると、ハートビートメッセージが公開されます。
• プロキシビットが 1 に設定されている場合、ノードのGATTプロキシ状態（セクション4.2.11を参照）が変更されると、ハートビートメッセージが公開されます。
• フレンドビットが 1 に設定されている場合、ノードのフレンド状態（セクション4.2.13を参照）が変更されると、ハートビートメッセージが公開されます。
• 低電力ビットが 1 に設定されている場合、ハートビート

3.6.7.3 ハートビートメッセージの受信

ハートビートメッセージの受信は、ハートビートサブスクリプションの状態によって制御されます（セクション4.2.18を参照）。ハートビートサブスクリプション期間の状態は、ハートビートメッセージが受信された期間の残りの秒数を識別するカウントダウンタイマーです。 タイマーが 0x0000 の値に達すると、ハートビートメッセージの受信が無効になります。

SRC フィールドがハートビートサブスクリプションソース状態（セクション4.2.18.1を参照）以外の値に設定されているか、DST フィールドがハートビートサブスクリプション宛先状態（セクション4.2.18.2を参照）以外の値に設定されているハートビートメッセージは処理されません。 。
ハートビートメッセージを受信すると、ハートビートサブスクリプションカウント状態の値（セクション4.2.18.3を参照）が増加します。 カウンターは折り返されません。 0xFFFF でカウントを停止します。ハートビートメッセージを受信すると、ホップ値は、メッセージからの InitTTL 値と、RxTTL と呼ばれる受信したネットワーク PDU TTL フィールド値を使用して次のように計算されます。

ホップ = InitTTL – RxTTL + 1
注：メッセージが直接受信された場合（たとえば、InitTTL 値と受信されたネットワーク PDU TTL フィールド値が同じである場合）、ホップ値は 0x01 になります。 メッセージが最大長のパスを使用して配信された場合、InitTTL は 0x7F になり、受信したネットワーク PDU TTL フィールド値は 0x01 になるため、ホップは 0x7F になります。

ホップ値がハートビートサブスクリプションの最小ホップ状態よりも低い場合は、ハートビートサブスクリプションの最小ホップ状態の新しい値として設定されます。 ホップ値がハートビートサブスクリプションの最大ホップ状態よりも高い場合は、ハートビートサブスクリプションの最大ホップ状態の新しい値として設定されます。