はじめに
Bluetooth Meshの仕様について、Bluetooth SIGで公開されている「Mesh Profile Specification 1.0.1」に基づき、学習を兼ねて記載して行こうと思っています。本文章では、3章の「メッシュ ネットワーキング」の次の節について記載いたします。
- 3.7 アクセスレイヤー
記載内容に誤り等がありましたら、ご連絡いただければ幸いです。
3.7 アクセスレイヤー
アクセスレイヤーは、上位レイヤーのアプリケーションが上位トランスポートレイヤーをどのように使用できるかを定義します。 アプリケーションデータのフォーマットを定義します。 上位トランスポートレイヤーで実行されるアプリケーションデータの暗号化と復号化を定義するとともに制御します。 また、受信アプリケーションデータが適切なネットワークキーとアプリケーションキーのコンテキストで受信されたかどうかを確認してから、上位レイヤーに転送します。
3.7.1 エンディアン
セクション 3.1.1.2 で説明されているように、このレイヤーのすべてのマルチオクテット数値は「リトルエンディアン」でなければなりません。
3.7.2 モデル識別子
モデルは一意の識別子で識別されます。 識別子の長さは、Bluetooth SIG 採用モデル（SIG モデル ID ）の場合は 16 ビット、ベンダーモデル（ベンダーモデル ID ）の場合は 32 ビットです。 SIG モデル ID の詳細については、セクション 4.4.5 を参照してください。
ベンダーモデル ID は、Bluetooth によって割り当てられた 16 ビットの会社 ID [6] とベンダーによって割り当てられた 16 ビットのモデル ID の 2 つの値で構成されます。 各ベンダーモデル ID のフォーマットは、表 3.40 で定義されています。
| フィールド | サイズ （オクテット） | 説明 |
|---|---|---|
| 16ビットの会社識別子 | 2 | [6]を参照してください |
| 16ビットベンダーが割り当てたモデル識別子 | 2 |
3.7.3 アクセスペイロード
アクセスペイロードは、論理的には表 3.41 に示すフィールドで構成されます。
| フィールド名 | サイズ （オクテット） | 説明 |
|---|---|---|
| オペコード | 1,2, or 3 | 操作コード |
| パラメータ | 0 to 379 | アプリケーションパラメータ |
アクセスペイロードは、それぞれ 12 オクテットの最大 32 セグメントで送信できます。 これは、オクテットの最大数が TransMIC を含めて 384 であることを意味します。
4 オクテットの TransMIC の場合、アクセスペイロードの最大サイズは 380 オクテットであるため、単一のオクテットオペコードの場合、パラメータフィールドは最大 379 オクテットになります。 2 オクテットのオペコードでは、パラメータフィールドは最大 378 オクテットになります。 3 オクテットのオペコードでは、パラメータフィールドは最大 377 オクテットになります。
下位トランスポートレイヤーは、ネットワークレイヤーを介して配信するために、メッセージをより小さな PDU にセグメント化する場合があります。 表3.42は、パケット数と TransMIC のサイズに応じた最大の有用なアプリケーションパケットサイズを示しています。
| パケット数 | 最大有効アクセス ペイロードサイズ （オクテット） 32 ビット TransMIC | 最大有効アクセス ペイロードサイズ （オクテット） 64 ビット TransMIC |
|---|---|---|
| 1 | 11（非セグメント化） | n/a |
| 1 | 8（セグメント化） | 4（セグメント化） |
| 2 | 20 | 16 |
| 3 | 32 | 28 |
| n | ( n * 12 ) – 4 | ( n * 12 ) – 8 |
| 32 | 380 | 376 |
3.7.3.1 操作コード
操作コード（オペコード）は、1、2、または 3 オクテットで構成されるオクテットの配列です。 オペコードの最初のオクテットは、オペコードの一部であるオクテットの数を決定します。
オペコードの最初のオクテットの最上位ビットがゼロの場合、オペコードには 1 つのオクテットが含まれます。 最初のオクテットの最上位 2 ビットが 0b10 の場合、オペコードには 2 つのオクテットが含まれます。 最初のオクテットの最上位 2 ビットが 0b11 の場合、オペコードには 3 つのオクテットが含まれます。 これを表3.43 に示します。
| Opcode フォーマット | 説明 |
|---|---|
| 0xxxxxxx (除く 01111111) | １オクテット Opcode |
| 01111111 | 将来の使用のために予約済み |
| 10xxxxxx xxxxxxxx | ２オクテット Opcode |
| 11xxxxxx zzzzzzzz | ３オクテット Opcode |
1 オクテットのオペコードは、Bluetooth SIGで定義されたアプリケーションのオペコードに使用されます。 Bluetooth SIGで定義および割り当てることができる 1 オクテットのオペコードは 127 個あります。オペコード 0x7F は、将来の拡張のために予約されています。
2 オペコードオペコードは、Bluetooth SIG で定義されたアプリケーションオペコードに使用されます。 Bluetooth SIG で定義および割り当てることができる 16384 個の 2 オペコードオペコードがあります。
3 オペコードは、メーカー固有のオペコードに使用されます。表3.43 の「x」を使用して識別される会社識別子ごとに 64 の 3 オペコードが利用可能ですが、会社は必要に応じてさらにオペコードをサブクラス化することもできます。会社識別子は Bluetooth SIG によって定義された 16 ビット値であり、セクション 3.7.1 で定義されているエンディアンを使用して、表3.43 の「z」を使用して識別される 3 オクテットオペコードの 2 番目と 3 番目のオクテットにコード化されます。会社固有のオペコードは、識別子に関連付けられた会社によって管理されます。
たとえば、メーカー固有のオペコードが 0x23 に等しく、会社 ID が 0x0136 [6] に等しい場合、3 オペコードのオペコードは 0xE3 0x36 0x01 に等しくなります。
3.7.3.2 アプリケーションパラメータ
パラメータフィールドは、オペコードごとに個別に定義されます。 特定のパラメータは、セクション 4.3 のメッセージ定義内で定義されています。 「パラメーター」フィールドの長さはゼロオクテットにすることができます。
3.7.4 アクセスレイヤーの動作
3.7.4.1 アクセスメッセージの送信
メッセージは、モデルによって、ユニキャストアドレス、グループアドレス、または仮想アドレスである宛先アドレスに送信されます。
メッセージは、送信要素のユニキャストアドレスである送信元アドレスから送信されます。
TTL フィールドは、送信元要素からすべての宛先アドレスにメッセージを転送するために必要なホップ数に設定することにより、アプリケーションによって指定できます。 ただし、これが指定されていない場合、デフォルト TTL がアクセスレイヤーによって適用されます。
SRC フィールドは、メッセージを発信しているノード内の要素のユニキャストアドレスに設定されます。
DST フィールドは、メッセージの送信先のユニキャストアドレス、グループアドレス、または仮想アドレスに設定する必要があります。
上位レイヤーは DST フィールドの値を設定します。たとえば、メッセージが公開されている場合（セクション 3.7.6.1 を参照）、モデル公開状態（セクション 4.2.2 を参照）によって DST フィールドの値が決定されます。アプリケーションは、DST フィールドの値を指定することにより、宛先にメッセージを送信することもできます。
アクセスレイヤーはメッセージの配信を保証しません。各モデルは、メッセージを再送信するかどうか、および潜在的な重複をどのように処理するかを決定する必要があります。
ユニキャストアドレスに送信された受信メッセージに応答してメッセージが送信される場合、ノードは 20 〜 50 ミリ秒のランダムな遅延で応答メッセージを送信する必要があります。グループアドレスまたは仮想アドレスに送信された受信メッセージに応答してメッセージが送信される場合、ノードは 20 〜 500 ミリ秒のランダムな遅延で応答メッセージを送信する必要があります。これにより、複数のノードがこのメッセージにまったく同時に応答する可能性が低くなるため、メッセージの衝突ではなく、メッセージ配信の可能性が高くなります。
ノードは、ローカル状態の変化によるメッセージの公開、新しい状態への移行の進行状況、または新しい状態への移行が完了したことを示すように構成することもできます（セクション 3.7.6.1 を参照）。新しい状態への移行がユーザーの操作によって引き起こされた場合、デバイスはできるだけ早くステータスメッセージを送信する必要があります。 メッセージの公開が電源投入、新しい状態の進行状況の更新への移行、または新しい状態への移行の完了を示すために発生した場合、複数のノードが同時に状態の変化を報告している可能性があります。 衝突の可能性を減らすために、これらのメッセージは 20 〜 500 ミリ秒のランダムな遅延で送信する必要があります。
すべてのノードと他の Bluetooth デバイス間で共有される利用可能な帯域幅が限られているため、ノードが発信しているトラフィックの量を監視することが重要です。 ノードは、移動する 10 秒のウィンドウで 100 未満の下位トランスポート PDU を発信する必要があります。
3.7.4.2 アクセスメッセージの受信
次のすべての条件が満たされると、処理を行うためにモデルにメッセージが配信されます。
- オペコードは、メッセージがこの要素のモデルによって使用されていることを示します。
- 宛先アドレスは、次のいずれかに設定されている。
- モデルの要素のユニキャストアドレス。
- モデルの要素がサブスクライブされているグループまたは仮想アドレス。
- セクション 3.4.2.4 で定義されている、ノードのプライマリ要素の固定グループアドレス。
- モデルは、メッセージの転送を保護するために使用されたアプリケーションキーまたはデバイスキーにバインドされています。
3.7.4.3 セキュリティに関する考慮事項
メッセージは、上位トランスポートレイヤーによって暗号化および認証されます。 ノードによって発信されたメッセージは、モデル用に構成された AppKey または DevKey のいずれかを使用する必要があります。
応答メッセージは、対応する要求メッセージで使用されるのと同じ DevKey または AppKey を常に使用する必要があります。
3.7.4.4 メッセージエラー手順
要素が理解できないメッセージを受信した場合、そのメッセージは無視されます。
注：メッセージが異なるキーを使用して送信された場合でも、既知のネットワークキーとアプリケーションキーを使用して NetMIC および TransMIC 認証を通過すると、メッセージが有効なメッセージとして誤って識別される可能性があります。 間違ったキーを使用してそのメッセージを復号化すると、要素によって理解されないメッセージが生成されます。 このような状況が発生する可能性は低いですが、軽視できません。
理解されないメッセージには、次の条件の1つ以上を持つメッセージが含まれます。
- アプリケーションのオペコードは、メッセージを受信した要素によって不明です。
- アプリケーションオペコードのアクセスメッセージサイズが正しくありません。
- アプリケーションパラメータには、現在禁止されている値が含まれています。
注：ピアノードによって理解されない確認済みメッセージを送信する要素は、応答メッセージを受信しません。
3.7.5 未確認および確認済みメッセージ
アクセスレイヤーでは、メッセージは未確認または確認済みとして定義されます。
3.7.5.1 未確認のメッセージ
応答が不要な場合、未確認のメッセージが送信されます。
たとえば、状態が変化したときにモデルによってメッセージが公開されたり、未確認のメッセージがグループアドレスに送信されて、複数のメッセージが返送されることなくグループメンバーの状態が変更されたりする場合があります。
未確認メッセージへの応答がないため、送信要素がそのメッセージが配信または処理されたかどうかを判断することはできません。
3.7.5.2 確認済みメッセージ
確認済みメッセージは、そのメッセージに応答することにより、各受信要素によって送信および確認されます。 通常、応答はステータスメッセージです。
任意の時間内に応答が受信されない場合、メッセージの発信者はメッセージを再送信する場合があります。 使用される期間はアプリケーション固有です。
要素が複数の要素にメッセージを送信する場合、たとえば、宛先アドレスをグループアドレスに設定している場合、要素はメッセージに応答できる要素の数を知らない可能性があります。 確認応答メッセージをすべてのノードのアドレスに送信することはお勧めしません。 メッセージが正常に配信される可能性を高めるために、メッセージを送信した要素は、メッセージを受信するはずのすべてのノードが実際にメッセージを受信したと見なす前に、必要なメッセージの再送信回数を決定する必要があります。
確認応答メッセージタイムアウトと呼ばれる期間内に要素が応答を受信しない場合、要素は、追加のメッセージを送信せずに、メッセージが配信されなかったと見なす場合があります。
確認応答メッセージのタイムアウトは、最低 30 秒に設定する必要があります。 正確な値はアプリケーション固有です。
確認済みメッセージがモデルに配信されると、モデルは関連する応答メッセージを送信して、そのメッセージを確認します。 応答メッセージには、状態情報などの情報が含まれる場合があります。 応答メッセージは未確認のメッセージです。 応答メッセージの宛先は、受信した確認済みメッセージの送信元アドレスに設定する必要があります。 確認応答メッセージの TTL が 0 に設定されている場合、応答メッセージの TTL を 0 に設定することをお勧めします。
3.7.6 公開およびサブスクライブ
上位レイヤーの仕様では、データを含むメッセージを、モデルによって公開されている、またはモデルの要素によってサブスクライブされているものとして記述することができます。
公開とサブスクライブは、宛先アドレスを使用して実行されます。
公開とサブスクライブに使用される宛先アドレスの構成は、Foundation モデルによって管理されます（セクション 4 を参照）。
3.7.6.1 公開
モデルは一方的なメッセージを宛先アドレスに送信すると、データを公開します。 メッセージは、公開アドレスと呼ばれる、ユニキャスト、グループ、または仮想の宛先アドレスに送信できます。 ノード内の各モデルには、単一の公開アドレスがあります。
3.7.6.1.1状態遷移
図3.26 に示すように、要素内の状態は、瞬時に変化するか、時間の経過とともに新しい状態に遷移する可能性があります。 初期状態から目標状態までの時間が遷移時間です。 現在の状態から目標の状態までの時間が残り時間です。 新しい状態値を設定するメッセージを受信した場合、この新しい値はすぐには適用されない場合がありますが、代わりにターゲット状態として保存される場合があります。 状態は初期状態からターゲット状態に移行します。 ステータスメッセージはいつでも送信でき、遷移時間が経過していなくても常に現在の状態が含まれます。 このステータスメッセージには、現在の状態とターゲット状態の間の残り時間が含まれる場合があります。 現在の状態がターゲット状態に達すると、状態遷移は終了します。
3.7.6.1.2 状態変更の公開
状態変更に関するメッセージの公開は、モデルのモデル公開状態（セクション 4.2.2 を参照）を設定することで有効になります。 モデルの公開が有効になっている場合、上位レイヤーの仕様で特に指定されていない限り、対応するステータスメッセージは、状態遷移が終了した直後に公開されます。 2 秒を超える遷移の場合、状態遷移の開始から 1 秒以内に追加のステータスメッセージを公開することをお勧めします。
3.7.6.1.3 定期的な発行
モデルは、状態が変化したかどうかに関係なく、ステータスメッセージを定期的に送信するように構成できます。 これは、公開期間を使用して行われます（セクション 4.2.2.2 を参照）。 公開期間がゼロ以外の値に設定されている場合、上位レイヤーの仕様で特に指定されていない限り、ステータスメッセージは公開期間ごとに少なくとも 1 回公開される必要があります。 公開期間が 0 に設定されている場合、ステータスメッセージは、有効になっている場合にのみ状態変化時に公開されます。
3.7.6.1.4 再送信の公開
新しいメッセージがモデルインスタンスによって公開されている場合、モデルインスタンスによって公開された前のメッセージの保留中の再送信はすべてキャンセルされ、モデルインスタンスは、Publish RetransmitCount および PublishRetransmit IntervalSteps 状態で指定されたとおりに新しいメッセージを再送信する必要があります。
3.7.6.2 サブスクライブ
各モデルには、このモデルの要素がサブスクライブする宛先アドレスを決定する1つ以上のアドレスの 1 つ以上のサブスクリプションリスト（セクション 4.2.3 を参照）が含まれる場合があります。 これらのサブスクリプションアドレスは、グループアドレスまたは仮想アドレスにすることができます。
注：モデルは、事実上、セクション 3.7.4.2 で説明されているように、常にその要素のユニキャストアドレスにサブスクライブされます。
3.7.7 メッセージシーケンスチャートの例
このセクションでは、一般的なメッセージシーケンスチャートを示します。
3.7.7.1 承認された取得
図3.27 は、確認応答された get メッセージを使用してピア要素の状態を取得するクライアントを示しています。 サーバーは、関連するステータスメッセージで応答します。
3.7.7.2 承認済みセット
図3.28 は、承認済みの設定メッセージを使用してピア要素の状態を設定するクライアントを示しています。 サーバーは、関連するステータスメッセージで応答します。 次に、サーバーは、公開ルールに従って、モデルの公開アドレスにステータスメッセージを公開します（セクション 3.7.6.1.2 を参照）。 クライアントがこのモデルの公開アドレスにサブスクライブしている場合、クライアントは両方のステータスメッセージを受信します。
3.7.7.3 未承認のセット
図3.29 は、未承認の設定メッセージを使用してピア要素の状態を設定しているクライアントを示しています。 応答は送信されませんが、サーバーは公開ルールに従ってモデルの公開アドレスに新しい状態情報を公開します（セクション 3.7.6.1.2 を参照）。 クライアントがこのモデルの公開アドレスにサブスクライブしている場合、クライアントはステータスメッセージを受信します。
3.7.7.4 定期的に発行される承認済みセット
図3.30 は、確認済みの設定メッセージを使用してピア要素の状態を設定するクライアントを示しています。 サーバーは、関連するステータスメッセージで応答します。 次に、サーバーは、定期的な公開ルールに従って、新しい状態情報をモデルの公開アドレスに定期的に公開します（セクション 3.7.6.1.2 を参照）。
