Bluetooth Mesh 仕様 – 4. Foundation models(その1)

Bluetooth Mesh
  1. はじめに
  2. 4 ファンデーションモデル
    1. 4.1 規約
      1. 4.1.1 エンディアン
      2. 4.1.2 ログフィールドの変換
    2. 4.2 状態定義
      1. 4.2.1 組成データ
        1. 4.2.1.1 組成データページ0
      2. 4.2.2 公開モデル
        1. 4.2.2.1 公開アドレス
        2. 4.2.2.2 公開期間
        3. 4.2.2.3 公開AppKeyインデックス
        4. 4.2.2.4 公開フレンドシップ資格情報フラグ
        5. 4.2.2.5 公開TTL
        6. 4.2.2.7 公開再送信間隔ステップ
      3. 4.2.3 サブスクリプションリスト
      4. 4.2.4 NetKeyリスト
      5. 4.2.5 AppKeyリスト
      6. 4.2.6 モデルからAppKeyリスト
      7. 4.2.7 デフォルト TTL
  3. 4.2.8 リレー
      1. 4.2.9 注意喚起タイマー
      2. 4.2.10 セキュアネットワークビーコン
      3. 4.2.11 GATTプロキシ
      4. 4.2.12 ノードアイデンティティ
      5. 4.2.13 フレンド
  4. 4.2.14 キー更新フェーズ
      1. 4.2.15 動作障害
        1. 4.2.15.1 現在の障害
        2. 4.2.15.2 登録済みの障害
      2. 4.2.16 ヘルスファスト期間除数
      3. 4.2.17 ハートビートパブリケーション
        1. 4.2.17.1 ハートビートの発行先
        2. 4.2.17.2 ハートビート発行数
        3. 4.2.17.3 ハートビート発行期間ログ
        4. 4.2.17.4 ハートビートパブリケーション TTL
        5. 4.2.17.5 ハートビートパブリケーション機能
        6. 4.2.17.6 Heartbeat Publication NetKeyインデックス
      4. 4.2.18 ハートビートサブスクリプション
        1. 4.2.18.1 ハートビートサブスクリプションソース
        2. 4.2.18.2 ハートビートサブスクリプションの宛先
        3. 4.2.18.3 ハートビートサブスクリプションカウント
        4. 4.2.18.4 ハートビートサブスクリプション期間ログ
  5. 4.2.18.5 ハートビートサブスクリプションの最小ホップ
  6. 4.2.19 ネットワーク送信
        1. 4.2.19.1 ネットワーク送信カウント
        2. 4.2.19.2 ネットワーク送信間隔ステップ
      1. 4.2.20 リレー再送信
        1. 4.2.20.1 リレー再送信カウント
  7. 4.2.20.2 リレー再送信間隔ステップ
  8. 4.2.21 PollTimeoutリスト

はじめに

Bluetooth Meshの仕様について、Bluetooth SIGで公開されている「Mesh Profile Specification 1.0.1」に基づき、学習を兼ねて記載して行こうと思っています。本文章では、4章の「ファンデーションモデル」の次の節について記載いたします。

  • 4.1 規約
  • 4.2 状態の定義

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

4 ファンデーションモデル

ファンデーションモデルは、メッシュネットワークの構成と管理に必要なアクセスレイヤーの状態、メッセージ、およびモデルを定義します。

4.1 規約

4.1.1 エンディアン

セクション3.1.1.2で説明されているように、このレイヤーのすべてのマルチオクテット数値は「リトルエンディアン」でなければなりません。

4.1.2 ログフィールドの変換

2オクテット値を1オクテットフィールドに圧縮するために、次の対数変換が使用されます。任意の2オクテット値は、最大整数nを表す1オクテットフィールド値にマップされます。ここで、2(n-1)は2オクテット値小さいか、あるいは同じです。この変換を表4.1に示します。

ログフィールド値2 オクテット値
0x010x0001
0x020x0002 から 0x0003
0x030x0004 から 0x0007
0x040x0008 から 0x000F
0x050x0010 から 0x001F
0x060x0020 から 0x003F
0x070x0040 から 0x007F
0x080x0080 から 0x00FF
0x090x0100 から 0x01FF
0x0A0x0200 から 0x03FF
0x0B0x0400 から 0x07FF
0x0C0x0800 から 0x0FFF
0x0D0x1000 から 0x1FFF
0x0E0x2000 から 0x3FFF
0x0F0x4000 から 0x7FFF
0x100x8000 から 0xFFFF
表4.1:ログフィールド値

4.2 状態定義

ノードの状態は、1つ以上の状態定義を使用して定義されます。 このセクションでは、この仕様全体で使用される状態を定義します。
この仕様の一部として必要とされない状態定義は、メッシュモデル仕様[11]で定義されており、メッシュ状態定義と同じ形式とアーキテクチャに従います。

4.2.1 組成データ

組成データの状態には、ノード、ノードに含まれる要素、およびサポートされているモデルに関する情報が含まれます。 組成データは、数ページの情報で構成されています。 組成データページ0は必須です。 他のすべてのページはオプションです。 この仕様で定義されていないすべての組成データページは、将来の使用のために予約されています。
状態のサイズは、最大有効アクセスペイロードサイズを超えてはなりません(表3.42)。

4.2.1.1 組成データページ0

組成データページ0のフォーマットは表4.2に定義されています。

CID2Bluetooth SIGによって割り当てられた
16ビットの会社識別子が含まれています
(リストは [6]で入手できます)
PID2ベンダーが割り当てた
16ビットの製品 ID が含まれています
VID2ベンダーが割り当てた
16ビットの製品バージョン識別子が
含まれています
CRPL2デバイス内のリプレイ保護リストエントリの
最小数を表す16ビット値が含まれます
(セクション 3.8.8を参照)。
Features2表4.3 で定義されているように、
デバイスの機能を示すビットフィールドが
含まれています
Elements可変長要素の説明のシーケンスが含まれています
表4.2:組成データページ0のフィールド

機能フィールドには、セクション3.2で定義されているノード機能を示すビットフィールドが含まれています。 機能フィールドのフォーマットは、表4.3で定義されています。

ビット機能説明
0リレーリレー機能のサポート:0 = False、1 = True
1プロキシプロキシ機能のサポート:0 = False、1 = True
2フレンドフレンド機能のサポート:0 = False、1 = True
3低電力低電力機能のサポート:0 = False、1 = True
4 – 15RFU将来の使用のために予約済み
表4.3:機能フィールドのフォーマット

要素フィールドには、1つ以上の要素の説明のシーケンスが含まれています。 各要素の説明のフォーマットは、表4.4で定義されています。

フィールドサイズ
(オクテット)
説明
Loc2ロケーション記述子が含まれています
NumS1この要素のSIGモデルIDの数が含まれます
NumV1この要素のベンダーモデルIDの数が含まれます
SIG Models可変長NumS SIG モデルIDのシーケンスが含まれています
Vender Models可変長NumV ベンダーモデルIDのシーケンスが含まれています
表4.4:要素説明のフォーマット

Locフィールドには、Bluetooth SIG割り当て番号[4]のGATT Bluetooth名前空間記述子セクションで定義されているロケーションの説明が含まれています。 GATT単位表に定義されていない値は、将来の使用のために予約されています。

SIGモデルフィールドには、一連のNumS SIGモデルIDが含まれています。 このシーケンスに含まれる拡張モデルごとに、それが拡張するすべてのモデルも含まれるものとします。

ベンダーモデルフィールドには、一連のNumVベンダーモデルIDが含まれています。

図4.1:組成データページ 0 のフォーマット

図4.1の例は、2つの要素を持つ組成データページ0を示しています。 各要素には、ロケーション、SIG モデルIDの数、およびベンダーモデルIDの数が含まれます。 この例では、最初の要素には、3つのSIG モデルIDがあり、ベンダーモデルIDはありません。また、2番目の要素には、2つのSIG モデルIDと2つのベンダーモデルIDがあります。

4.2.2 公開モデル

公開モデルの状態は、モデルによって公開されるメッセージのパラメーターを制御する複合状態です。 状態には、公開アドレス、公開期間、公開AppKeyインデックス、公開フレンドシップ資格情報フラグ、公開TTL、公開再送信カウント、および公開再送信間隔ステップが含まれます。 要素内では、各モデルにモデル公開状態の個別のインスタンスがあります。 上位レイヤーの仕様で定義されたモデルでは、モデル公開状態のインスタンスを使用してメッセージの公開を制御することを強くお勧めします。

4.2.2.1 公開アドレス

公開アドレスの状態は、モデルによって送信されるメッセージの宛先アドレスを決定します。 公開アドレスは、割り当てられていないアドレス、ユニキャストアドレス、ラベルUUID、またはグループアドレスでなければなりません。

モデルの公開が無効になっている場合、モデルの公開アドレスは割り当てられていないアドレスに設定されます。

モデルの公開アドレスが割り当てられていないアドレスである場合、モデルは非アクティブです。未承諾メッセージは送信されず、受信確認済みメッセージにのみ応答メッセージを送信できます。

4.2.2.2 公開期間

公開期間の状態は、モデルによってステータスメッセージが公開される間隔を決定します。 これは1オクテットの値であり、ステップ分解能を表す2ビットフィールドとステップ数を表す6ビットフィールドの2つのフィールドで構成されます。 この状態のフォーマットは表4.5で定義されています。

フィールドサイズ
(オクテット)
説明
Number of Steps6ステップ数
Step Resolution2ステップ数フィールドの分解能
表4.5:公開期間のフォーマット
図4.2:公開期間のフォーマット

ステップ分解能フィールドは、ステップ数フィールドの分解能を列挙し、値は表4.6で定義されています。

説明
0b00ステップ分解能は、100ミリ秒です
0b01ステップ分解能は、1秒です
0b10ステップ分解能は、10秒です
0b11ステップ分解能は、 10分です
表4.6:ステップ分解能の値

ステップ数フィールドはステップ数を表す値であり、値は表4.7で定義されています。

説明
0x00公開期間が無効になっています
0x01 – 0x3Fステップ数
表4.7:ステップ数の値

公開期間は、次の式を使用して計算されます。

公開期間 = ステップ分解能*ステップ数

たとえば、ステップ分解能が0b10で、ステップ数が0x31の場合、公開期間は490秒になります。

4.2.2.3 公開AppKeyインデックス

公開AppKeyインデックスの状態は、モデルによって送信されるメッセージで使用されるアプリケーションキーのグローバルAppKeyインデックスです。 公開AppKeyインデックスは、セクション4.2.6で定義されているAppKeyリストのモデルに含まれている必要があります。

4.2.2.4 公開フレンドシップ資格情報フラグ

公開フレンドシップ資格情報フラグは、モデルからのメッセージの公開に使用される資格情報を制御する1ビットの状態です。 公開フレンドシップ資格情報フラグの値を表4.8に示します。

説明
0公開のためにマスターセキュリティマテリアルが
使用されます
1公開のためにフレンドセキュリティマテリアルが
使用されます
表4.8:公開フレンドシップ資格情報フラグの値

公開フレンドシップ資格情報フラグが1に設定されていて、フレンドシップセキュリティマテリアルが利用できない場合は、マスターセキュリティマテリアルが使用されます。

4.2.2.5 公開TTL

公開TTLの状態は、モデルによって公開された送信メッセージのTTL値を決定し、値は表4.9で定義されています。 公開TTLを0xFFに設定すると、メッセージはセクション4.2.7で定義されているデフォルトのTTLを使用します。

説明
0x00 – 0x7F1オクテット整数として表される公開TTL値
0x80 – 0xFE禁止
0xFFデフォルトのTTLを使用する
表4.9:公開TTLの値

注:公開TTLの状態が1に設定されている場合、セクション 3.4.5で定義されているように、送信メッセージはローカル要素にのみ公開されます。

4.2.2.7 公開再送信間隔ステップ

公開再送信間隔ステップの状態は、モデルによって公開されるメッセージの再送信間の間隔を制御する5ビット値です。 状態は、モデルによって公開されたメッセージが再送信される前に発生する50ミ リ秒のステップ数を表します。

再送信間隔は、次の式を使用して計算されます。

再送信間隔 = (公開再送信間隔ステップ+1)*50

たとえば、値0b10000は、850ミリ秒の間隔を表します。

4.2.3 サブスクリプションリスト

サブスクリプションリストの状態は、グループアドレスとラベルUUIDのリストです。

サブスクリプションリストは、セクション3.7.4.2で定義されているアクセスメッセージを受信するときにモデルによって使用されます。上位レイヤーの仕様で定義されたモデルでは、サブスクリプションリスト状態のインスタンスを使用してメッセージの受信を制御することを強くお勧めします。

モデルがその要素で別のモデルを拡張しない限り、要素内では、各モデルにサブスクリプションリストの個別のインスタンスがあります。 他のモデルを拡張するモデルのインスタンス(つまり、拡張関係ツリー内のすべてのモデル)は、要素ごとにサブスクリプションリストの単一のインスタンスを共有する必要があります。

状態のサイズは、最大有効アクセスペイロードサイズを超えてはなりません(表3.42)。

4.2.4 NetKeyリスト

NetKeyリストの状態は、NetKeyのインデックス付きリストです。

NetKeyリストの各エントリは、最大2つのキー値(古いキー値と新しいキー値)を保持します。 古いキーと新しいキー値の使用については、キーの更新手順で説明されています(セクション3.10.4を参照)。

NetKeyリストには、少なくとも1つのNetKeyが含まれている必要があります。

状態のサイズは、最大有効アクセスペイロードサイズを超えてはなりません(表3.42)。

4.2.5 AppKeyリスト

AppKeyリストの状態は、AppKeyのインデックス付きリストです。

AppKeyリストの各エントリは、AppKeyインデックスと、最大2つのキー値(古いキー値と新しいキー値)を保持します。 古いキーと新しいキー値の使用については、キーの更新手順で説明されています(セクション3.10.4を参照)。

状態のサイズは、最大有効アクセスペイロードサイズを超えてはなりません(表3.42)。

4.2.6 モデルからAppKeyリスト

モデルからAppKeyリストの状態は、モデルとAppKey間の関係のリストです。 モデルは、1つ以上のAppKeyに関連付けることができます。

状態のサイズは、最大有効アクセスペイロードサイズを超えてはなりません(表3.42)。

4.2.7 デフォルト TTL

デフォルトTTLの状態は、メッセージの送信時に使用されるTTL値を決定します。 デフォルトTTLは、アプリケーションがTTLを指定しない限り、アクセスレイヤーによって適用されます。 デフォルトTTL値は表4.10で定義されています。

説明
0x00,
0x02 – 0x7F
デフォルトTTL状態
0x01,
0x80 – 0xFF
禁止
表4.10:デフォルトTTL値

4.2.8 リレー

リレー状態は、リレー機能のサポートを示します。 リレー機能がサポートされている場合、これはリレー機能が有効か無効かを示すとともに制御します。 値は表4.11に定義されています。

説明
0x00ノードは、リレー機能をサポートしているが
無効になっている。
0x01ノードは、リレー機能をサポートしていて
有効になっている
0x02リレー機能は、サポートされていない
0x03 – 0xFF禁止
表4.11:リレーの値

リレー機能がサポートされていない場合、リレー状態値は0x02であり変更されません。

リレー機能がサポートされている場合、リレー状態値0x02は使用されません。

4.2.9 注意喚起タイマー

注意喚起タイマーの状態は、注意喚起タイマー状態がオンかオフかを決定します。 これは通常、要素が人間に対して注意喚起を可能にすることを目的としており、とりわけ、プロビジョニング中に使用されます(セクション5.4.2を参照)。

デバイスが注意喚起タイマーをサポートしていない可能性があります。 注意喚起タイマーをサポートしていないデバイスでは、注意喚起タイマーの状態は、常にゼロに設定されます。

要素の注意喚起タイマーがゼロ以外の場合、注意喚起タイマーの状態はオンです。 要素の注意喚起タイマーがゼロの場合、注意喚起タイマーの状態はオフです。

注意喚起タイマー状態がオンの場合、この値は、要素が人間に対して注意喚起を続ける時間を決定します。この要素は、人間が認識できる方法で動作することによってそれを行います(たとえば、ランプが点滅し、モーターが音を立て、LEDが点滅します)。正確な動作は実装固有であり、デバイスのタイプによって異なります。識別方法がデバイスの物理的状態を上書きする場合がありますが、要素の通常の動作は引き続きアクティブです。

注意喚起タイマーは瞬間的な状態であり、秒単位の値で示される時間アクティブになります。 値は、ゼロに達するまで1秒ごとに1ずつ減少します。 この状態の値は、表4.12で定義されています。

説明
0x00オフ
0x01 – 0xFFオン、秒単位の残り時間
表4.12:注意喚起タイマーの値

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

セキュアネットワークビーコンの状態は、ノードがセキュアネットワークビーコンメッセージを定期的にブロードキャストしているかどうかを決定します(セクション3.9.3を参照)。 この状態の値は、表4.13で定義されています。

説明
0x00ノードがセキュアネットワークビーコンを
ブロードキャストしていません
0x01ノードはセキュアネットワークビーコンを
ブロードキャストしています
0x02 – 0xFF禁止
表4.13:セキュアネットワークビーコンの値

4.2.11 GATTプロキシ

GATTプロキシ状態は、プロキシ機能(セクション3.4.6.2を参照)がサポートされているかどうかを示します。 この機能がサポートされている場合、状態はプロキシ機能を示すとともに制御します。

注:プロキシ機能が無効になっている場合、GATTクライアントデバイスはGATTを介してそのノードに接続し、構成と制御を行うことができます。 GATTベアラからのメッセージはアドバタイジングベアラに中継されません。

この状態の値は、表4.14 で定義されています。

説明
0x00プロキシ機能はサポートされているが
無効になっています
0x01プロキシ機能はサポートされていて
有効になっています
0x02プロキシ機能はサポートされていません
0x03 – 0xFF禁止
表4.14:GATTプロキシの値

プロキシ機能がサポートされていない場合、GATTプロキシの状態値は0x02であり変更されません。

プロキシ機能がサポートされている場合、GATTプロキシ状態値0x02は使用されません。

4.2.12 ノードアイデンティティ

ノードアイデンティティの状態は、ノードがサブネット上のノードアイデンティティメッセージでアドバタイズしているかどうかを決定します(セクション7.2.2.2.3を参照)。 メッシュプロキシサービスが公開されている場合、ノードはサブネット上のノードアイデンティティでアドバタイズするように構成できます。 この状態の値は、表4.15で定義されています。

説明
0x00サブネットのノードアイデンティティを
使用したアドバタイズが停止されている
0x01サブネットのノードアイデンティティを
使用したアドバタイズが実行されています
0x02ノードアイデンティティを使用した
アドバタイズはサポートされていません
0x03 – 0xFF禁止
表4.15:ノードアイデンティティの値

メッシュプロキシサービスが公開されていない場合、ノードアイデンティティの状態値は0x02であり変更されません。

メッシュプロキシサービスが公開されている場合、ノードアイデンティティ状態値0x02は使用されません。

4.2.13 フレンド

フレンド状態は、フレンド機能のサポートを示します。 フレンド機能がサポートされている場合、これはフレンド機能が有効か無効かを示すとともに制御します。 この状態の値は、表4.16で定義されています。

説明
0x00ノードは、フレンド機能をサポートしているが
無効になっている
0x01ノードは、フレンド機能をサポートしており
有効になっている
0x02フレンド機能はサポートされていません
0x03 – 0xFF禁止
表4.16:フレンドの値

フレンド機能がサポートされていない場合、フレンド状態の値は0x02であり変更されません。

フレンド機能がサポートされている場合、フレンド状態値0x02は使用されません。

フレンド機能がサポートされていて、フレンド状態が値0x00に変更され、ノードが1つ以上の低電力ノードのフレンドである場合、ノードはすべてのフレンド関係を終了し、関連するフレンドキューをクリアする必要があります。

4.2.14 キー更新フェーズ

キー更新フェーズの状態は、NetKeyリスト内の各NetKeyのキー更新手順(セクション3.10.4を参照)を示すとともに制御します。 この状態の値は、表4.17で定義されています。

説明
0x00通常の操作; キーの更新手順が
アクティブではありません
0x01キー更新手順の最初のフェーズ
0x02キー更新手順の第2フェーズ
0x03 – 0xFF禁止
表4.17:キー更新フェーズの状態の値

表4.18は、この状態を使用して制御できる、キー更新フェーズ状態のすべての可能な遷移を定義しています。 他のすべての遷移は、キー更新手順によって内部的に処理されます(たとえば、デバイスがキー更新を受信したときの0x00から0x01への遷移)。

古い状態遷移新しい状態説明
0x000x030x00キー更新フェーズ0x00から3への遷移は
状態は変化しません。
0x010x020x02キー更新フェーズ0x01から2への遷移は
キー更新フェーズ0x02へ移動します。
0x010x030x00キー更新フェーズ0x01から3への遷移は
キー更新フェーズ3を呼び出してから
キー更新フェーズ0x00に移動します。
0x020x020x02キー更新フェーズ0x02から0x02への遷移は
状態は変化しません。
0x020x030x00キー更新フェーズ0x02から3への遷移は
キー更新フェーズ3を呼び出してから
キー更新フェーズ0x00に移動します。
表4.18:制御可能なキー更新遷移の値

4.2.15 動作障害

動作障害の状態は、要素の警告またはエラー状態を表す複合状態です。
動作障害の状態は会社IDによって識別され、複数の会社IDのノードに存在する場合があります。

4.2.15.1 現在の障害

現在の障害の状態は、最後に実行されたセルフテストの1オクテット値と、要素の現在の警告またはエラー状態をそれぞれ表す1オクテット値のシーケンスを含む配列です。 この状態のフォーマットは、表4.19で定義されています。

フィールドサイズ説明
Test ID1最近実行されたセルフテストの
識別子
FaultArrayN現在のフォールトの配列
表4.19:現在の障害のフォーマット

テストIDの値は、表4.20で定義されています。

説明
0x00標準テスト
0x01 – 0xFFベンダー固有のテスト
表4.20:テストIDの値

FaultArrayの値は表4.21で定義されています。

値0x01〜0x7Fは、Bluetoothによって割り当てられた番号であり、値は特定の警告およびエラー状態を表します。 値0x80〜0xFFはベンダー固有であり、デバイスメーカーによって定義された警告およびエラーを表すために使用される場合があります。 警告またはエラー状態が存在しない場合、現在のフォールトのFaultArrayは空です。FaultArrayはリアルタイムの状態を反映します。 これは、障害状態が発生すると、対応するレコードがFaultArrayに存在し、障害状態が存在しない場合、対応するレコードがFaultArrayから自動的に削除されることを意味します。

警告は、設計限界内で動作している要素の状態を示しますが、設計限界に近いことを示します。

エラーは、要素の状態が設計限界を超えており、その機能を実行できない可能性があることを示しています。

説明
0x00いずれの障害もない
0x01警告:バッテリー低下
0x02エラー:バッテリー低下
0x03警告:供給電圧が低すぎる
0x040エラー:供給電圧が低すぎる
0x05警告:供給電圧が高すぎる
0x06エラー:供給電圧が高すぎる
0x07警告:電源遮断
0x08エラー:電源遮断
0x09警告:無負荷
0x0Aエラー:無負荷
0x0B警告:過負荷
0x0Cエラー:過負荷
0x0D警告:過熱
0x0Eエラー:過熱
0x0F警告:結露
0x10エラー:結露
0x11警告:振動
0x12エラー:振動
0x13警告:構成
0x14エラー:構成
0x15警告:要素が校正されていない
0x16エラー:要素が校正されていない
0x17警告:メモリー
0x18エラー:メモリー
0x19警告:セルフテスト
0x1Aエラー:セルフテスト
0x1B警告:低入力
0x1Cエラー:低入力
0x1D警告:高入力
0x1Eエラー:高入力
0x1F警告:入力無変更
0x20エラー:入力無変更
0x21警告:アクチュエータブロック
0x22エラー:アクチュエータブロック
0x23警告:ハウジングオープン
0x24エラー:ハウジングオープン
0x25警告:改ざん
0x26エラー:改ざん
0x27警告:デバイス移動
0x28エラー:デバイス移動
0x29警告:デバイス落下
0x2Aエラー:デバイス落下
0x2B警告:オーバーフロー
0x2Cエラー:オーバーフロー
0x2D警告:空(empty)
0x2Eエラー:空(empty)
0x2F警告:内部バス
0x30エラー:内部バス
0x31警告:Mechanism Jammed
0x32エラー:Mechanism Jammed
0x33 – 0x7F将来の使用のために予約済み
0x80 – 0xFFベンダー固有の警告/エラー
表4.21:フォールトの値
4.2.15.2 登録済みの障害

登録済み障害状態は、最後に実行されたセルフテストの1オクテット値であり、現在の障害FaultArrayのシャドウ配列です。 この状態の形式は表4.22で定義されています。

フィールドサイズ説明
Test ID1最近実行されたセルフテストの識別子
FaultArrayN登録済みの障害の配列
表4.22:登録済み障害のフォーマット

テストIDの値は、表4.23で定義されています。

説明
0x00標準テスト
0x01 – 0xFFベンダー固有テスト
表4.23:テストIDの値

現在の障害状態(セクション4.2.15.1 を参照)で障害状態が存在する場合は常に、対応するレコードが登録済み障害FaultArrayに追加されます。 FaultArrayは、専用のHealth Fault Clearメッセージでクリアされます(セクション4.3.3.3を参照)。

4.2.16 ヘルスファスト期間除数

ヘルスファスト期間除数の状態は、Health Current Statusメッセージを公開する頻度の増加を制御する 1 オクテットの値です。 ヘルスファスト期間除数の状態の値の範囲は0〜15であり、他のすべての値は禁止されています。 これは、ヘルス公開期間を 2n で除算するために使用されます。ここで、nはヘルスファスト期間除数の状態の値です。

4.2.17 ハートビートパブリケーション

ハートビートパブリケーションの状態は、定期的なハートビートトランスポート制御メッセージの送信を制御する複合状態です。

4.2.17.1 ハートビートの発行先

ハートビートパブリケーションの状態は、ハートビートメッセージの宛先アドレスを決定します。 ハートビート発行先は、割り当てられていないアドレス、ユニキャストアドレス、またはグループアドレスである必要があり、他のすべての値は禁止されています。

注:ハートビートの発行先が割り当てられていないアドレスに設定されている場合、ハートビートメッセージは送信されません。

4.2.17.2 ハートビート発行数

ハートビートパブリケーションカウント状態は、送信される定期的なハートビートトランスポート制御メッセージの数を制御する16ビット値です。 0xFFFFに設定すると、各ハートビートメッセージの送信後にデクリメントされません。 0x0000に設定すると、ハートビートメッセージは送信されません。0x0001以上または0xFFFE以下の値に設定すると、各ハートビートメッセージの送信後にデクリメントされます。

ハートビートパブリケーションカウントログは、ハートビートパブリケーションカウント値を表します。 値が0x00と0x0000のハートビートパブリケーションカウントログとハートビートパブリケーションカウントは同等です。 0xFFのハートビートパブリケーションカウントログ値は、0xFFFFのハートビートパブリケーションカウント値と同等です。 0x01と0x11の間のハートビートパブリケーションカウントログ値は、2(n-1)がハートビートパブリケーションカウント値以上である最小の整数nを表すものとします。 たとえば、ハートビートパブリケーションカウント値が0x0579の場合、ハートビートパブリケーションカウントログ値は0x0Cになります。

説明
0x00ハートビートメッセージが定期的に送信されていません
0x01 – 0x11送信されていないハートビートメッセージの数 2(n-1)
0x12 – 0xFE禁止
0xFFハートビートメッセージが無期限に送信されています
表4.24:ハートビートパブリケーションカウントログ値
4.2.17.3 ハートビート発行期間ログ

ハートビート発行期間ログの状態は、定期的なハートビートトランスポート制御メッセージのリズムを制御する8ビット値です。 値は 2(n-1) 秒として表されます。 たとえば、値0x04の公開期間は8秒で、値0x07の公開期間は64秒です。 この状態の値は、表4.25で定義されています。

説明
0x00ハートビートメッセージが定期的に送信されていません
0x01 – 0x11最小の整数n。2(n-1) はハートビートパブリケーションカウント値以上です。
0x12 – 0xFF禁止
表4.25:ハートビート発行期間のログ値
4.2.17.4 ハートビートパブリケーション TTL

ハートビートパブリケーションのTTL状態は、ハートビートメッセージの送信時に使用されるTTL値を決定します。 この状態の値は、表4.26で定義されています。

説明
0x00 – 0x7FハートビートパブリケーションTTLの状態
0x80 – 0xFF禁止
表4.26:ハートビートパブリケーションのTTL値
4.2.17.5 ハートビートパブリケーション機能

ハートビートパブリケーション機能の状態は、変更されたときにハートビートメッセージの送信をトリガーする機能を決定します。 この状態の値は、表4.27で定義されています。

ビット機能説明
0リレーリレー機能の変更により、ハートビートメッセージがトリガーされます
:0 = False、1 = True
1プロキシプロキシ機能の変更により、ハートビートメッセージがトリガーされます
:0 = False、1 = True
2フレンドフレンド機能の変更により、ハートビートメッセージがトリガーされます
:0 = False、1 = True
3低電力低電力機能の変更により、ハートビートメッセージがトリガーされます
:0 = False、1 = True
4 – 15RFU将来の使用のために予約済み
表4.27:ハートビートパブリケーション機能の値
4.2.17.6 Heartbeat Publication NetKeyインデックス

Heartbeat Publication NetKey Indexの状態は、ハートビートメッセージの送信に使用されるNetKeyのグローバルNetKeyインデックスを決定します。

4.2.18 ハートビートサブスクリプション

ハートビートサブスクリプションの状態は、定期的なハートビートトランスポート制御メッセージの受信を制御する複合状態です。

4.2.18.1 ハートビートサブスクリプションソース

ハートビートサブスクリプションソースの状態は、ノードが処理するハートビートメッセージの送信元アドレスを決定します。 ハートビートサブスクリプションソースは、割り当てられていないアドレスまたはユニキャストアドレスである必要があり、他のすべての値は禁止されています。 ハートビートサブスクリプションソースが割り当てられていないアドレスに設定されている場合、ハートビートメッセージは処理されていません。

4.2.18.2 ハートビートサブスクリプションの宛先

ハートビートサブスクリプションの宛先の状態は、ハートビートメッセージの宛先アドレスを決定します。 これは、ノードがハートビートメッセージを受信できるようにプロキシフィルターを構成するためにノードで使用できます。たとえば、GATTベアラーを使用して接続されているノードやフレンドシップ内のノードなどです。 ハートビートサブスクリプションの宛先は、割り当てられていないアドレス、ノードのプライマリユニキャストアドレス、またはグループアドレスである必要があり、他のすべての値は禁止されています。 ハートビートサブスクリプションの宛先が割り当てられていないアドレスに設定されている場合、ハートビートメッセージは処理されていません。

4.2.18.3 ハートビートサブスクリプションカウント

ハートビートサブスクリプションカウントの状態は、最新のConfig Heartbeat Subscription Setメッセージを受信してから受信した定期的なハートビートトランスポート制御メッセージの数を制御する16ビットカウンターです。 カウンタは0xFFFFでカウントを停止します。 この状態の値は、表4.28で定義されています。

ハートビートサブスクリプションカウントログは、ハートビートサブスクリプションカウント値の表現です。 値が0x00と0x0000のハートビートサブスクリプションカウントログとハートビートサブスクリプションカウントは同等です。 0xFFのハートビートサブスクリプションカウントログ値は、0xFFFFのハートビートサブスクリプションカウント値と同等です。0x01から0x10までのハートビートサブスクリプションカウントログ値は、表4.1で定義されている変換を使用して、ハートビートサブスクリプションカウント値を表すものとします。

説明
0x0000 – 0xFFFE受信したハートビートメッセージの数
0xFFFF0xFFFEを超えるメッセージが受信されました
表4.28:ハートビートサブスクリプションカウント値
4.2.18.4 ハートビートサブスクリプション期間ログ

ハートビートサブスクリプション期間の状態は、定期的なハートビートトランスポート制御メッセージを処理する期間を制御する16ビット値です。0x0000に設定すると、ハートビートメッセージは処理されません。 0x0001以上の値に設定すると、ハートビートメッセージが処理されます。 この状態の値は、表4.29で定義されています。

ハートビートサブスクリプション期間ログは、ハートビートサブスクリプション期間の値を表します。 値が0x00と0x0000のハートビートサブスクリプション期間ログとハートビートサブスクリプション期間は同等です。0x01と0x11の間のハートビートサブスクリプション期間ログ値は、表4.1で定義された変換を使用して、ハートビートサブスクリプション期間値を表すものとします。

説明
0x00ハートビートメッセージが処理されていません
0x01 – 0x11定期的なハートビートメッセージを処理するための
2(n-1) 秒の残りの期間
0x12 – 0xFF禁止
表4.29:ハートビートサブスクリプション期間の値

4.2.18.5 ハートビートサブスクリプションの最小ホップ

ハートビートサブスクリプションの最小ホップ状態は、最新のConfig Heartbeat Subscription Setメッセージを受信してから、ハートビートメッセージを受信するときに登録される最小ホップ値を決定します。 この状態の値は、表4.30で定義されています。

説明
0x00ハートビートメッセージを受信していません
0x01 – 0x7Fハートビートサブスクリプションの最小ホップ状態
0x80 – 0xFF禁止
表4.30:ハートビートサブスクリプションの最小TTL値

ハートビートサブスクリプションの最大ホップ数状態は、最新のConfig Heartbeat Subscription Setメッセージを受信してから、ハートビートメッセージを受信するときに登録される最大ホップ値を決定します。 この状態の値は、表4.31で定義されています。

説明
0x00ハートビートメッセージを受信していません
0x01 – 0x7Fハートビートサブスクリプションの最大ホップ状態
0x80 – 0xFF禁止
表4.31:ハートビートサブスクリプションの最大TTL値

4.2.19 ネットワーク送信

ネットワーク送信の状態は、ノードから発信されるネットワークPDU の送信の数とタイミングを制御する複合状態です。

状態には、ネットワーク送信カウントフィールドとネットワーク送信間隔ステップフィールドが含まれ
ます。

ノードには、この状態の単一のインスタンスがあります。

4.2.19.1 ネットワーク送信カウント

ネットワーク送信カウントフィールドは、ノードから発信されたネットワークPDUのメッセージ送信数を制御する3ビット値です。送信回数は送信回数 + 1 です。 たとえば、値0b000は1回の送信を表し、値0b111は8回の送信を表します。

4.2.19.2 ネットワーク送信間隔ステップ

ネットワーク送信間隔ステップフィールドは、ノードから発信されたネットワークPDUのメッセージ送信間の間隔を制御する10ミリ秒のステップ数を表す5ビット値です。

送信間隔は、次の式を使用して計算されます。

送信間隔=(ネットワーク再送信間隔ステップ+1)*10

各送信は、各送信間の0〜10ミリ秒のランダムな値によって摂動される必要があります。

たとえば、値0b10000は、各送信間の170〜180ミリ秒の送信間隔を表します。

注:ベアラ(たとえば、アドバタイジングベアラ)は、有効と見なされる間隔のセットに制限を課す場合があるため、使用される間隔は状態の値よりも大きくなる場合があります。

4.2.20 リレー再送信

リレー再送信状態は、ノードによってリレーされるネットワークPDUの再送信のパラメータを制御する複合状態です。

この状態には、Relay Retransmit Count状態とRelay Retransmit Interval Steps状態が含まれます。

ノードには、この状態の単一のインスタンスがあります。

4.2.20.1 リレー再送信カウント

Relay Retransmit Countフィールドは、ノードによってリレーされるネットワークPDUのメッセージ再送信の数を制御する3ビット値です。 リレー再送信カウント+1は、リレーされるパケットごとにパケットが送信される回数です。 たとえば、値0b000は、再送信のない単一の送信を表し、値0b111は、合計8回の送信に対する単一の送信と7回の再送信を表します。

4.2.20.2 リレー再送信間隔ステップ

リレー再送信間隔ステップフィールドは、ノードによってリレーされるネットワークPDUのメッセージ再送信間の間隔を制御する10ミリ秒のステップ数を表す5ビット値です。

再送信間隔は、次の式を使用して計算されます。

再送信間隔=(リレー再送信間隔ステップ+1)*10

注:リンクレイヤーでは、各送信は、前の送信から0〜10ミリ秒のランダムな値によって摂動されます。

注:ベアラ(たとえば、アドバタイジングベアラ)は、有効と見なされる間隔のセットに制限を課す場合があるため、使用される間隔は状態の値よりも大きくなる場合があります。

4.2.21 PollTimeoutリスト

PollTimeoutリスト状態は、フレンドノード内の低電力ノードのPollTimeoutタイマーの現在の値のリストです。 低電力ノードごとに、PollTimeoutリストのエントリはPollTimeoutタイマーの現在の値を保持します。 複数のサブネット上に複数のフレンドシップ関係が設定されている場合、リストに保持される値は、フレンドノードが低電力ノードと確立したすべてのフレンドシップ関係のすべてのPollTimeoutタイマーの最小値です。 このリストは、低電力ノードのプライマリ要素アドレスによってインデックスが付けられています。

説明
0x000000ノードは、LPNAddressによって識別される
低電力ノードのフレンドノードではなくなりました。
0x000001 ~ 0x000009禁止
0x00000A ~ 0x34BBFF100ミリ秒単位のPollTimeoutタイマー値
0x34BC00 ~ 0xFFFFFF禁止
表4.32:PollTimeoutタイマー値

フレンド機能がサポートされていない場合、またはフレンド機能がサポートされて無効になっている場合、低電力ノードのPollTimeoutリスト状態の現在の値は0x000000に設定されます。

フレンド機能がサポートおよび有効化されていて、フレンドノードがプライマリエレメントアドレスで識別される低電力ノードとのフレンドシップを確立していない場合、その低電力ノードのPollTimeoutリスト状態の現在の値は0x000000に設定されます。

状態のサイズは、最大有効アクセスペイロードサイズを超えてはなりません(表3.42)。

タイトルとURLをコピーしました