Bluetooth Mesh 仕様 – 2. Mesh system architecture

はじめに
2 Mesh system architecture

はじめに

Bluetooth Meshの仕様について、Bluetooth SIGで公開されている「Mesh Profile Specification 1.0.1」に基づき、学習を兼ねて記載して行こうと思っています。ここでは、2章の「Mesh system architecture」について記載いたします。
記載内容に誤り等がありましたら、ご連絡いただければ幸いです。

2 Mesh system architecture

このセクションでは、メッシュネットワークの運用と階層化されたシステムアーキテクチャの概要を説明します。

2.1 階層化アーキテクチャ

メッシュプロファイル仕様は、図2.1に示すように、階層化アーキテクチャとして定義されています。

2.1.1 モデルレイヤー

モデルレイヤーは、一般的なユーザーシナリオの操作を標準化するために使用されるモデルを定義し、Bluetoothメッシュモデル仕様[11]またはその他の上位レイヤー仕様で定義されます。上位レイヤーのモデル仕様の例には、照明やセンサーのモデルが含まれます。

2.1.2 ファンデーションモデルレイヤー

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

2.1.3 アクセスレイヤー

アクセスレイヤーは、上位レイヤーのアプリケーションが上位トランスポートレイヤーをどのように使用できるかを定義します。アプリケーションデータのフォーマットを定義します。上位トランスポートレイヤーで実行されるアプリケーションデータの暗号化と復号化を定義および制御します。また、受信アプリケーションデータが適切なネットワークとアプリケーションキーのコンテキストで受信されたかどうかを確認してから、上位レイヤーに転送します。

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

上位トランスポートレイヤーは、アプリケーションデータを暗号化、復号化、および認証し、アクセスメッセージの機密性を提供するように設計されています。また、フレンド機能で使用される場合を含め、ノード間の上位トランスポートレイヤーを管理するためにトランスポート制御メッセージがどのように使用されるかを定義します。

2.1.5 下位トランスポートレイヤー

下位トランスポートレイヤーは、上位トランスポートレイヤーメッセージをセグメント化して複数の下位トランスポートPDUに再構成し、大きな上位トランスポートレイヤーメッセージを他のノードに配信する方法を定義します。また、セグメンテーションと再組み立てを管理するための単一の制御メッセージも定義します。

2.1.6 ネットワークレイヤー

ネットワークレイヤーは、トランスポートメッセージが1つ以上のエレメントにどのようにアドレス指定されるかを定義します。トランスポートPDUをベアラレイヤーで転送できるようにするネットワークメッセージのフォーマットを定義します。ネットワークレイヤーは、メッセージを中継/転送するか、さらに処理するために受け入れるか、拒否するかを決定します。また、ネットワークメッセージを暗号化および認証する方法も定義します。

2.1.7 ベアラレイヤー

ベアラレイヤーは、ネットワークメッセージがノード間でどのように転送されるかを定義します。アドバタイジングベアラとGATTベアラの2つのベアラが定義されています。将来、追加のベアラが定義される可能性があります。

2.2 メッシュ操作の概要

この仕様で定義されているメッシュネットワーク操作は、次のように設計されています。

メッセージを1つの要素から1つ以上の要素に送信できるようにします。
メッセージを他のノードを介して中継して、通信範囲を拡張できるようにします。
盗聴攻撃、man-in-the-middle攻撃、リプレイ攻撃、ゴミ箱攻撃、ブルートフォースキー攻撃、およびここに記載されていない追加のセキュリティ攻撃の可能性を含む、既知のセキュリティ攻撃に対するセキュアなメッセージ。
今日の市場にある既存のデバイスで動作します。
タイムリーにメッセージを配信します。
1つ以上のデバイスが移動したり、動作を停止したりしても、動作を継続します。そして
メッシュプロファイル仕様の将来のバージョンをサポートするための上位互換性が組み込まれています。

この仕様は、他のノードがメッセージを受信してこれらのメッセージを中継できるように、ブロードキャストチャネルを使用してメッセージを送信するマネージドフラッドベースのメッシュネットワークを定義します。したがって、元のメッセージの範囲が拡張されます。マネージドフラッドメッシュネットワーク内の任意のデバイスは、メッセージをリッスンおよびリレーしているデバイスの密度が十分にある限り、いつでもメッセージを送信できます。ルーティング機能を追加し、ルーティングベースのメッシュネットワークを定義するための拡張機能は、この仕様の将来の改訂で検討される可能性があります。

この仕様では、マネージドフラッドメッシュネットワークでのメッセージの無制限の中継を制限するために使用される方法がいくつかあります。使用される2つの主な方法は、ネットワークメッセージキャッシュ方法と存続時間方法です。

ネットワークメッセージキャッシュは、すべてのメッセージをキャッシュリストに追加することにより、デバイスが以前に受信したメッセージを中継しないように設計されています。メッセージを受信すると、リストと照合され、すでに存在する場合は無視されます。まだ受信されていない場合は、将来無視できるようにキャッシュに追加されます。このリストが長くなりすぎるのを防ぐために、キャッシュされるメッセージの数は実装によって制限されます。

各メッセージには、メッセージを中継できる回数を制限する存続可能時間（TTL）値が含まれています。メッセージが受信され、デバイスによって中継されるたびに（最大126回）、TTL値は1ずつデクリメントされます。

2.2.1 ネットワークとサブネット

メッシュネットワークは、4つの共通リソースを共有するノードで構成されています。

メッセージの送信元と宛先を識別するために使用されるネットワークアドレス（セクション3.4.2を参照）。
ネットワークレイヤーでメッセージを保護および認証するために使用されるネットワークキー（セクション3.8.6.3を参照）。
アクセスレイヤーでメッセージを保護および認証するために使用されるアプリケーションキー（セクション3.8.6.2を参照）。そして
ネットワークの寿命を延ばすために使用されるIVインデックス（セクション3.8.4を参照）。

ネットワークには、「エリア」の分離を容易にする1つ以上のサブネットを含めることができます（たとえば、ホテルネットワーク内の分離されたホテルの部屋のサブネット）。サブネットは、ネットワークキーを共有しているため、ネットワークレイヤーで相互に通信できるノードのグループです。ノードは、1つ以上のネットワークキーを知っていることにより、1つ以上のサブネットに属することができます。プロビジョニング時に、デバイスは1つのサブネットにプロビジョニングされ、構成モデルを使用してさらに多くのサブネットに追加できます。

プライマリNetKeyに基づくプライマリサブネットと呼ばれる特別なサブネットが1つあります（セクション3.8.6.4を参照）。プライマリサブネット上のノードはIV更新手順（セクション3.10.5を参照）に参加し、IV更新を他のサブネットに伝播しますが、他のサブネット上のノードはIVインデックス更新のみをそれらのサブネットに伝播します。

ネットワークリソースは、構成クライアントと呼ばれる構成クライアントモデルを実装するノード（通常はスマートフォンまたはその他のモバイルコンピューティングデバイス）によって管理され、構成サーバーモデル（セクション4.4.1を参照）を使用して構成時にノードに割り当てられます（セクション5を参照）。特に、プロビジョナーはアドレスの割り当てを管理して、重複するユニキャストアドレスが割り当てられないようにします。一方、構成クライアントは、ネットワークキーとアプリケーションキーを生成して配布し、相互に通信する必要のあるデバイスがネットワークとアクセスレイヤーの両方に適切なキーを共有するようにします。構成クライアントは、更新されたネットワークキーとアプリケーションキーの配布など、個々のノードとの通信を保護するために使用されるデバイスキー（セクション3.8.6.1を参照）も認識しています。

2.2.2 デバイスとノード

メッシュネットワークのメンバーではないデバイスは、プロビジョニングされていないデバイスと呼ばれます。メッシュネットワークのメンバーであるデバイスは、ノードと呼ばれます。プロビジョナーは、プロビジョニングされていないデバイスとノード間の遷移を管理するために使用されます。

プロビジョニングされていないデバイスは、メッシュメッセージを送受信できません。ただし、その存在をプロビジョナーにアドバタイズします。プロビジョナーは、認証された後、プロビジョニングされていないデバイスをメッシュネットワークに招待し、プロビジョニングされていないデバイスをノードに変換します。

ノードはメッシュメッセージを送受信でき、メッシュネットワークを介してプロビジョナーと同じデバイスである構成クライアントによって管理され、ノードが他のノードと通信する方法を構成します。構成クライアントは、メッシュネットワークからノードを削除できます。これにより、ノードはプロビジョニングされていないデバイスに戻ります。

デバイスは、メッシュネットワークにプロビジョニングされた後、別のメッシュネットワークにプロビジョニングされるように提供することで、ノードの複数のインスタンスをサポートできます。メッシュネットワークの各インスタンスは、プロビジョニング中にデバイスによって取得されたアドレスとデバイスキーによって決定されます。

2.2.3 メッシュネットワークへのデバイスの追加

デバイスはプロビジョナーによってメッシュネットワークに追加され、その時点でデバイスはノードになります。メッシュネットワークへのデバイスのプロビジョニングは、Bluetoothワイヤレステクノロジーで通常使用されるポイントツーポイントのボンディングおよびペアリングとは異なります。
デバイスのプロビジョニングは、単純なアドバタイジングベアラまたはポイントツーポイントGATTベースのベアラのいずれかを使用して有効になります。単一のプロビジョニングプロトコルが両方のベアラで使用されます。アドバタイジングベースのベアラを介したプロビジョニングは、すべてのデバイスで実装されます。GATTベースのベアラを介したプロビジョニングにより、レガシー電話などのデバイス（つまり、アドバタイジングベアラを介したプロビジョニングをネイティブにサポートしていないデバイス）をプロビジョナにすることができます。

複数のデバイスのプロビジョニングを支援するために、デバイスには、プロビジョナーが設定できるアテンションタイマーがあります。ゼロ以外の値に設定すると、デバイスは可能な限りの手段を使用して自身を識別します。たとえば、デバイスがライトを点滅させたり、音を出したり、振動したりする場合があります。アテンションタイマーが時間切れになると、デバイスは自身の識別を停止します。これにより、プロビジョナーは単一のメッセージをデバイスに送信してデバイスにそれ自体を識別させ、デバイスは指定された時間が経過すると自動的にそれ自体の識別を停止します。

これら2つのベアラで実行するプロトコルは、Bluetoothコア仕様のv4.2のSecurity Managerプロトコルから派生したものであり、ライトやスイッチなど、ユーザーインターフェイスが非常に制限されているデバイスを認証する機能を導入しています。Security Managerプロトコルには、信頼できるベアラが必要です。これは、アドバタイジングプロビジョニングベアラでは保証できません。したがって、この仕様で使用されるプロトコルは、ベアラに関係なくメッセージの信頼性の高い配信を可能にするように設計されています。Security Managerプロトコルとの類似性により、そのような機能を実装したデバイスで既存のコードを大幅に再利用できます。

2.2.4 通信サポート

現在の多くのデバイスは、更新せずにメッシュメッセージをアドバタイズまたは理解することができません。これらのデバイスが、オペレーティングシステムの更新や同様のハードウェア/ソフトウェアの更新を必要とせずに、メッシュネットワーク内のノードと通信できるようにするため、この仕様では、既存のすべてのデバイスでGATT接続を使用できるようにします。

2.2.5 低電力サポート

この仕様内の機能により、メッシュネットワーク内の多くのデバイスをバッテリ駆動にしたり、環境発電などの手法を使用したりできます。このようなデバイスは、メッシュネットワークの一部として機能する方法に制約がある場合があります（たとえば、対話されたときにのみデータを送信するデバイス）。この仕様では、デバイスが送信を調整したり、接続を確立したり、すべての接続でセキュリティを再開したりする必要はありません。したがって、低電力動作が容易になります。低電力サポートが必要なデバイスは、フレンドシップと呼ばれる概念を使用して、デバイスに代わってメッセージを保存および中継する常時接続デバイスに関連付けることができます（セクション3.6.6を参照）。
ただし、メッセージを中継するデバイスは、ほとんどの場合メッセージを受信するだけでなく、メッセージを転送するため、通常の小型バッテリーやコンデンサーよりもはるかに多くの電力を使用する可能性があります。

2.3 アーキテクチャの概念

メッシュネットワークアーキテクチャは、状態、メッセージ、バインディング、エレメント、アドレス指定、モデル、パブリッシュ/サブスクライブ、メッシュキー、および関連付けなど、いくつかの異なる概念を使用します。

2.3.1 状態（ステート）

状態は、要素の状態を表す値です。

状態を公開するエレメントは、サーバーと呼ばれます。たとえば、最も単純なサーバーはGeneric OnOff Serverであり、オンまたはオフのいずれかであることを表します。

状態にアクセスするエレメントは、クライアントと呼ばれます。たとえば、最も単純なクライアントは、Generic OnOffモデルによって定義されたメッセージを介してGeneric OnOffサーバーを制御できるGenericOnOffクライアント（バイナリスイッチ）です。

2つ以上の値で構成される状態は、複合状態と呼ばれます。たとえば、色を変えるランプは、彩度や明るさとは別に色相を制御できます。

2.3.2 バインド状態

ある状態が別の状態にバインドされている場合、一方が変更されると、もう一方も変更されます。バインド状態は、1つまたは複数のエレメントの異なるモデルからのものである可能性があります。たとえば、一般的なタイプのバインディングは、レベル状態とオンオフ状態の間にあります。レベルを0に変更すると、バインドされたオンオフ状態がオフに変更され、レベルをゼロ以外の値に変更すると、バインドされたオンオフ状態がオンに変更されます。

2.3.3 メッセージ

メッシュネットワーク内のすべての通信は、メッセージを送信することによって実現されます。メッセージは状態に基づいて動作します。状態ごとに、サーバがサポートするメッセージの定義済みセットがあり、クライアントは状態の値を要求したり、状態を変更したりするために使用できます。サーバは、状態および/または状態の変化に関する情報を運ぶ一方的なメッセージを送信することもできます。

メッセージは、オペコード、関連するパラメーター、および動作を持つものとして定義されます。オペコードは、1オクテット（パラメーターに可能な最大のペイロードを必要とする特別なメッセージの場合）、2オクテット（標準メッセージの場合）、または3オクテット（ベンダー固有のメッセージの場合）の場合があります。

オペコードを含むメッセージの合計サイズは、基盤となるトランスポートレイヤーによって決定されます。トランスポートレイヤーは、セグメンテーションおよび再構成（SAR）メカニズムを使用する場合があります。パフォーマンスを最大化しSARのオーバーヘッドを回避するため、設計目標はメッセージを単一のセグメントに収めることです。トランスポートレイヤーは、セグメント化されていないメッセージに対して最大11オクテットを提供し、1オクテットのオペコードを使用する場合、パラメータとして使用できる最大10オクテットを残します。2オクテットのオペコードを使用する場合、パラメータに最大9オクテットを使用できます。ベンダー固有の3オクテットオペコードを使用する場合、パラメータに最大8オクテットを使用できます。

トランスポートレイヤーは、最大32セグメントを転送できるSARのメカニズムを提供します。SARを使用する場合の最大メッセージサイズは384オクテットです。これは、1オクテットのオペコードを使用する場合、（アプリケーションMICを除く）最大379オクテットをパラメータに使用できることを意味します。2オクテットのオペコードを使用する場合、パラメータには最大378オクテットを使用できます。ベンダー固有の3オクテットオペコードを使用する場合、パラメーターには最大377オクテットを使用できます。

SARは、セグメントごとにアクセスレイヤーのペイロードに余分なオーバーヘッドを効果的に課しません。10オクテットのメッセージはセグメント化されていないメッセージとして転送され、20オクテットのメッセージは2つのセグメントを使用するセグメント化されたメッセージとして転送されます。

メッセージ定義には、パラメータのテーブルが含まれています。メッセージペイロードでは、パラメータはオペコードに従い、特に指定がない限り、パラメータオフセットはオクテット単位です。

メッセージは、確認済みまたは未確認として定義されます。確認済みメッセージには応答が必要ですが、未確認メッセージには応答は必要ありません。

2.3.4 エレメント

エレメントは、ノード内のアドレス可能なエンティティです。各ノードには、プライマリエレメントである少なくとも1つのエレメントがあり、1つ以上の追加のセカンダリエレメントがある場合があります。エレメントの数と構造は静的であり、ノードの存続期間中（つまり、ノードがネットワークの一部である限り）変更されません。

プライマリエレメントは、プロビジョニング中にノードに割り当てられた最初のユニキャストアドレスを使用してアドレス指定されます。追加の各セカンダリエレメントは、後続のアドレスを使用してアドレス指定されます。これらのユニキャストエレメントアドレスにより、ノードはノード内のどのエレメントがメッセージを送信または受信しているかを識別できます。

ファームウェアの更新などによりエレメントの数と構造が変更された場合は、ノードを再プロビジョニングする必要があります。ノードの削除手順（セクション3.10.7を参照）は、エレメントの数または構造を変更するファームウェアの更新が実行されるときに使用されます。

メッセージは、オペコードとエレメントアドレスに基づいてモデル内でディスパッチされます。

エレメントには、同じメッセージを同じ方法で使用するモデルの複数のインスタンスを含めることはできません（たとえば、「オン」メッセージを受信します）。同じエレメント内の複数のモデルが同じメッセージを使用する場合、モデルは「重複」していると言われます。単一のノード内に重複するモデルの複数のインスタンスを実装するには（たとえば、オンとオフを切り替えることができる複数のランプを制御するため）、ノードには複数のエレメントが含まれている必要があります。たとえば、ランプに2つのランプがあり、それぞれがLight Lightness ServerモデルのインスタンスとGeneric Power OnOff Serverモデルのインスタンスを実装している場合があります。これには、ノードにランプごとに1つずつ、合計2つのエレメントが含まれている必要があります。「オン」メッセージを受信すると、ノードはエレメントのユニキャストアドレスを使用して、メッセージの宛先となるGeneric Power OnOff Serverモデルのインスタンスを識別します。

別の例では、デュアルソケット電源タップには、ソケットに接続されたアプライアンスによって消費される電力を測定できる2つの独立したエネルギー測定センサーが含まれています。これには、ノードに2つのセンサーデータ状態があり、それぞれが別々のエレメントにある必要があります。最初のエレメントであるプライマリエレメントは、ノードのユニキャストアドレスを使用して識別され、最初のエネルギーセンサーの状態と、ノードの構成を表す状態が含まれます。 2番目のエレメントであるセカンダリエレメントは、ユニキャストエレメントアドレスを使用して識別され、2番目のエネルギーセンサーの状態が含まれます。

各エレメントには、このエレメントがノードのどの部分を表すかを識別するのに役立つGATT Bluetooth名前空間記述子[5]値があります。これらの名前空間記述子の値は、GATTと同じ定義を使用します。たとえば、温度センサーの要素は”内側”と”外側”の値を使用します。

2.3.5 アドレス

アドレスは、ユニキャストアドレス、仮想アドレス、またはグループアドレスの場合があります。メッセージで使用されていない未割り当てのアドレスを表す特別な値もあります。

ユニキャストアドレスはエレメントに割り当てられ、常にノードの単一のエレメントを表します。メッシュネットワークごとに32767のユニキャストアドレスがあります。

仮想アドレスはマルチキャストアドレスであり、1つ以上のノード上の複数の要素を表すことができます。
各仮想アドレスは、ラベルUUIDを論理的に表します。これは、一元管理する必要のない128ビット値です。ラベルUUIDに送信される各メッセージには、メッセージの認証に使用されるメッセージ整合性チェック値に完全なラベルUUIDが含まれます。既知のすべてのラベルUUIDをチェックするオーバーヘッドを削減するために、ラベルUUIDのハッシュが使用されます。16384個のハッシュ値があり、それぞれが仮想アドレスのセットをコード化しています。仮想アドレスで使用されるハッシュ値は16384のみですが、各ハッシュ値は数百万の可能なラベルUUIDを表すことができます。したがって、仮想アドレスの数は非常に多いと見なされます。

グループアドレスはマルチキャストアドレスであり、1つ以上のノード上の複数のエレメントを表すことができます。メッシュネットワークごとに16384のグループアドレスがあります。それらのノードの機能に基づいて、ノードのすべてのプライマリエレメントのサブセットをアドレス指定するために使用される一連の固定グループアドレスがあります。他のすべてのグループアドレスは、動的に割り当てられたグループアドレスと呼ばれます。256個の固定グループアドレスと16128個の動的に割り当てられたグループアドレスがあります。

2.3.6 モデル

モデルは、ノードの基本的な機能を定義します。ノードには複数のモデルが含まれる場合があります。モデルは、必要な状態（セクション2.3.1で説明）、それらの状態に作用するメッセージ（セクション2.3.3で説明）、および関連する動作を定義します。

メッシュアプリケーションは、パブリッシュ/サブスクライブパラダイムと通信するクライアントサーバアーキテクチャを使用して指定されます。メッシュネットワークの性質と動作の構成は構成クライアントによって実行されるという認識のため、アプリケーションはプロファイルなどの単一のエンドツーエンド仕様で定義されていません。代わりに、アプリケーションはクライアントモデル、サーバーモデル、および制御モデルで定義されます。

この仕様では、サーバーモデル、クライアントモデル、および制御モデルの3種類のモデルを定義しています。

サーバモデル：サーバモデルは、1つ以上のエレメントにまたがる1つ以上の状態で構成されます。サーバモデルは、送信または受信できる一連の必須メッセージ、そのようなメッセージを送受信するときにエレメントに必要な動作、およびメッセージの送信または受信後に発生する追加の動作を定義します。
クライアントモデル：クライアントモデルは、サーバモデルで定義されているように、対応するサーバ状態を要求、変更、または消費するためにクライアントが使用する一連のメッセージ（必須とオプションの両方）を定義します。クライアントモデルには状態がありません。
制御モデル：制御モデルには、他のサーバモデルと通信するためのクライアントモデル機能と、他のクライアントモデルと通信するためのサーバモデル機能が含まれる場合があります。制御モデルには、制御ロジックが含まれる場合もあります。これは、制御モデルが接続する他のモデル間の相互作用を調整する一連のルールと動作です。

単一のデバイスには、サーバー、クライアント、および制御モデルが含まれる場合があります。

たとえば、図2.2は、状態とサポートメッセージR、S、T、X、Y、Zを備えたサーバーモデル（デバイスC）を実装するデバイスの要素モデル構造を示しています。およびクライアントモデルを実装する2つのデバイス。デバイスAはメッセージX、Y、およびZをサポートし、デバイスBはメッセージR、S、T、およびZをサポートします。

別の例では、図2.3に、制御モデルを実装するデバイスのエレメントーモデル構造を示します。デバイスCは、クライアントとしてサーバモデルと通信でき（それぞれメッセージX、Y、ZとメッセージR、S、Tをサポート）、サーバとしてクライアントモデルと通信できます（メッセージA、B、Cをサポート）。

照明コントローラーは、制御モデルの実装例です。照明コントローラーは、センサー（占有率や周囲光を測定するため）および光源（ランプやその他の照明器具など）のクライアントとして機能する必要があります。照明コントローラーは、クライアントを設定するためのサーバーとしても機能します（パラメーターを構成するスマートフォンアプリケーションなど）。このような照明コントローラーは、センサーまたは光源内に含まれていてもよいし、別個のデバイスであってもよい。

モデルは、キー管理、アドレス割り当て、メッセージの中継など、デバイスの機能をネットワークノードとして定義できます。モデルは、電力制御、照明制御、センサーデータ収集など、ネットワークノードを中心に構築されたデバイスの物理的動作も定義します。リレーノードやプロキシノードなど、ネットワーク関連の機能のみを実装するノードが存在する場合がありますが、ノードの大部分は、電力の制御、発光の制御、または環境データの検知によって物理的な世界と対話できます。

メッセージは、複数の異なるモデルで使用できます。メッセージの動作は各モデルで同じであり、メッセージを送信および処理するモデルに関係なく動作が一貫しているため、クライアント、サーバー、および制御モデル間で共通の理解が可能になります。

モデルの仕様は、非常に小さく、自己完結型になるように設計されています。モデルは、仕様定義時に、同じノード内でインスタンス化する必要がある他のモデルを必要とする場合があります。これは拡張と呼ばれ、モデルが他のモデルを拡張できることを意味します。他のモデルを拡張しないモデルは、ルートモデルと呼ばれます。

モデルの仕様は不変です。目的の動作がオプションの動作であるか必須の動作であるかに関係なく、モデルの動作を削除または追加することはできません。モデルはバージョン管理されておらず、機能ビットもありません。モデルで追加の動作が必要な場合は、必要な動作を公開し、元のモデルと一緒に実装できる新しい拡張モデルが定義されます。

したがって、エレメントによってサポートされるモデルの知識によって、そのエレメントによって公開される正確な動作が決まります。

モデルは、Bluetooth SIGによって定義および採用される場合があり、ベンダーによって定義される場合があります。Bluetooth SIGによって定義されたモデルは、SIG採用モデルと呼ばれ、ベンダーによって定義されたモデルは、ベンダーモデルと呼ばれます。モデルは、SIG採用モデルの場合は16ビット、ベンダーモデルの場合は32ビットの一意の識別子で識別されます。

たとえば、図2.4は、2つのバインドされた状態と各状態で動作するメッセージのセットを持つルートモデルを実装するデバイスの要素モデル構造を示しています。ルートモデルはプライマリエレメント内にあり、セカンダリエレメントに別の状態を追加する拡張モデルによって拡張されます。メッセージは、同じエレメント上の同じ状態の複数のインスタンスを区別することはできません。したがって、特定の状態の複数のインスタンスがデバイスに存在する場合、各インスタンスは別々のエレメントにある必要があります。この例では、状態Xの2番目のインスタンスは、同じタイプの状態であり、同じタイプのメッセージを提供するため、2番目の要素に配置する必要があります。

この構造例は、複合デバイス用に乗算することができます。たとえば、複合デバイスには、同じルートモデル（または拡張モデル）の複数のインスタンスが含まれる場合があります。各インスタンスは、別々のエレメント（またはエレメントのセット）にあります。また、モデル（ルートまたは拡張）が特定の状態の複数のインスタンスを必要とする場合、状態は複数のエレメントに分散されている必要があります。これにより、特定の状態の単一のインスタンスが要素上に存在するようになります。

図2.5は、図2.4のデバイスのエレメントーモデル構造を複合デバイスに実装する方法を示しています。デバイスのエレメントーモデル構造は、組成データによって記述されます（セクション4.2.1を参照）。これは、構成サーバーモデルと構成クライアントモデル（セクション4.4.1および4.4.2を参照）を使用して、プロビジョニング後に構成クライアントによって読み取られます（セクション5を参照）。

2.3.7 デバイスの例

エレメント内のモデルの配置がデバイスの状態と動作をどのように決定するかを説明するために、例としてデュアルソケットスマート電源タップデバイス（図2.6を参照）を使用します。このデバイスには、Bluetoothの低エネルギー機能を備えた単一の無線機と2つの独立した電源ソケットがあり、それぞれが電力出力を制御できます。この例には、メッシュモデル仕様[11]で定義されている状態、メッセージ、およびモデルが含まれています。

デバイスには、2つの電源ソケットのそれぞれを表す2つのエレメント（セクション2.3.4を参照）があります。各エレメントには、ユニキャストアドレスが割り当てられています。

各エレメントの機能は、Generic Power Levelサーバモデルによって定義されます。モデルは、サーバ上の状態のセットと、状態を操作するメッセージのセットを定義します。

Generic Power Level Setメッセージをデバイスに送信して、出力電力を制御することができます。メッセージはエレメントに宛てられ、宛先アドレス（DST）フィールドにエレメントのアドレスを伝えます（セクション2.3.8を参照）。

ソケットは、Generic Level Clientモデルを実装する（そして電力制御について何も知らない）汎用デバイス（調光器など）によって制御することもできます。このモデルは、必要なレベルをゼロ、最大値、またはその間の値に設定するだけです。ソケットへの電力は、状態バインディングによって制御されます。各電源ソケットでは、Generic Power Actual状態がGeneric Level状態にバインドされています。Generic Levelクライアントは、Generic LevelメッセージをGeneric Levelサーバに送信します。
Generic Level状態が変更され、次に（定義されたバインディングを介して）電力出力を制御するGeneric Power Actual状態が変更されます。

エレメントは状態を報告できます。この例では、各ソケットは、ソケットに接続されたデバイスの電力レベルとエネルギー消費量を報告する場合があります。エネルギー消費量は、センサーサーバモデルで定義されたメッセージを使用して報告されます。各メッセージのSRCフィールドには、ソケットを識別する要素のアドレスがあります（セクション3.4.4.6を参照）。

図2.7は、デュアルソケットデバイスのエレメントーモデル構造を示しています。機能的には、デバイスの両方のエレメントは同じ機能を備えています。唯一の違いは、プライマリエレメントが他のモデルに加えて、ネットワーク管理に使用される構成サーバモデルを処理することです。各エレメントには、Health Serverモデル（セクション4.4.4を参照）やメッシュモデル仕様[11]で定義されたモデルなどの他のモデルが定義されている場合があります。

2.3.8 パブリッシュ/サブスクライブとメッセージ交換

メッシュネットワーク内でのデータのパブリッシュとサブスクリプションは、パブリッシュ/サブスクライブパラダイムを使用するものとして説明されています。メッセージを生成するノードは、メッセージをユニキャストアドレス、グループアドレス、または仮想アドレスにパブリッシュします。メッセージの受信に関心のあるノードは、これらのアドレスにサブスクライブします。

生成されたメッセージは、ユニキャスト、事前構成されたグループアドレス、または仮想アドレスの宛先メッシュアドレスに送信されます。メッセージは、他のメッセージへの返信として送信することも、一方的なメッセージにすることもできます。モデルのインスタンスが応答メッセージを送信しているとき、モデルは着信メッセージの発信者の送信元アドレスを宛先アドレスとして使用します。モデルのインスタンスが一方的なメッセージを送信している場合、モデルの公開アドレスを宛先アドレスとして使用します。ノード内のモデルの各インスタンスには、単一の公開アドレスがあります。

受信側では、ノード内のモデルの各インスタンスは、1つ以上のグループアドレスまたは仮想アドレスにサブスクライブできます。モデルのサブスクリプションリストの1つにあるグループアドレスまたは仮想アドレスにアドレス指定されたメッセージが到着するたびに、そのメッセージはノードによって処理されます。メッセージは、宛先アドレスが受信エレメントのユニキャストアドレスである場合、または宛先アドレスがこのデバイスがメンバーである固定グループアドレスである場合にも処理されます。ノードに複数のエレメントがある場合、メッセージはアドレス指定されたエレメントごとに1回処理されます。

上位レイヤーの仕様で定義されたモデルの公開アドレスとサブスクリプションリストは、構成サーバモデルによって管理されるモデル公開とサブスクリプションリストの状態を使用します。

ノードは、モデルのエレメントのインスタンスごとに複数のサブスクリプションを持つことができますが、ノードはサポートされるサブスクリプションの数を制限する場合があります。複数のサブスクリプションアドレスを使用すると、ノードは異なるグループに公開されたメッセージに応答できます。たとえば、ライトは、ベッドサイドライトグループ、ベッドルームグループ、2階グループ、およびハウスグループに送信されるメッセージにサブスクライブできます。

各メッセージは、単一のユニキャストアドレス（要素アドレス）から送信され、一意のシーケンス番号を使用してシーケンスされ、リプレイ攻撃の検出と保護を容易にします。

2.3.9 セキュリティ

すべてのメッセージは、2種類のキーを使用して暗号化および認証されます。キータイプの1つは、メッシュネットワーク内のすべての通信が同じネットワークキーを使用するように、ネットワークレイヤー通信用です。もう1つのキータイプは、アプリケーションデータ用です。ネットワークとアプリケーションのキーを分離することで、機密性の高いアクセスメッセージ（建物へのアクセス制御など）を機密性の低いアクセスメッセージ（照明など）から分離できます。メッシュネットワーク内に暗号化されていないメッセージや認証されていないメッセージはありません。

2.3.9.1 アプリケーションとネットワークのセキュリティ

上位トランスポートレイヤーとネットワークレイヤーでのメッセージの暗号化と認証は、盗聴者や悪意のある攻撃からメッシュネットワーク内の通信を保護するように設計されています。各レイヤーは、アプリケーションとネットワークエンティティを分離できるように個別のキーを維持します。

アプリケーションキーをネットワークキーから分割すると、アプリケーションメッセージの安全なリレー送信が可能になります。リレーノードは、アプリケーションデータにアクセスせずにネットワークレベルでメッセージを認証できます。たとえば、リレーノードとして機能する電球はドアのロックを解除できないようにする必要があります。

これは、ノードがアプリケーションキーを知らなくても、ネットワークキーから派生したキーを使用してアクセスメッセージを中継できることを意味します。したがって、アプリケーションデータを変更または理解することはできません。ネットワークキーはネットワーク内の多くのノードで広く知られているため、さまざまなアプリケーション領域を相互に保護しながらリレーノードの密度を高めることが期待されます。これには、アプリケーションごとに個別のキーが必要です。たとえば、機密性の高いドアセキュリティアプリケーションは、非機密性のドアベルおよび照明アプリケーションから分離されます。

アプリケーションキーは、使用されるアプリケーションを識別するために特定のコンテキストで使用される関連するアプリケーションキー識別子とともに直接使用されます。ただし、ネットワークキーは常にキー導出関数を介して使用され、直接使用される他のキーを生成します。このようなキーの例には、暗号化キーやプライバシーキーが含まれます。これにより、単一のネットワークキーを変更し、そのキーから派生したすべての関連する値をすばやく派生させることができます。アプリケーションキーと同様に、ネットワークキーはネットワークキー識別子を導出するためにも使用されます（セクション3.8.6を参照）。

セキュリティモデルは、メッセージを保護するために3つの個別のキー（デバイスキー（DevKey）、アプリケーションキー（AppKey）、およびネットワークキー（NetKey））を定義します。ノードにキーが与えられると、そのキーの使用が許可されます。複数のノード間で共有されるキーにより、そのキーを持つノードは、そのキーを使用してメッセージを送受信できます。

デバイスキーは、構成クライアントと単一ノード間のキーマテリアルの機密性と認証を容易にします。アプリケーションキーは、目的のノード間で送信されるアプリケーションデータの機密性と認証を容易にします。ネットワークキーは、ネットワークメッセージのプライバシー、機密性、および信頼性を促進します。ノードは、単一のデバイスキー、複数のアプリケーションキー、および複数のネットワークキーに関する知識を持っている場合があります。

デバイスキーは、上位トランスポートレイヤーのアプリケーションによって送信される情報を保護するように設計されているという点で、アプリケーションキーに似ています。ただし、デバイスキーは、構成クライアントと単一ノードによってのみ認識されます。

構成クライアントはすべてのノードのデバイスキーを認識しているため、構成クライアントは、個々のノードのデバイスキーで保護されたこれらのキーを送信することにより、ノードのセットにキーを安全に配布できます。これにより、キー配布は、知る必要のあるノードのみを対象とすることができます。デバイスキーの使用は、選択したデバイスにのみ新しいネットワークキーとアプリケーションキーの配布を許可することにより、「ゴミ箱」攻撃（ネットワークへの攻撃を実行するために使用できる、廃棄されたデバイスから情報を取得する手法）から保護するように設計されています。

アプリケーションキーは、単一のネットワークキーでのみ使用できます。これは、ネットワークキーに1つ以上のアプリケーションキーが関連付けられていることを意味します。この関連付けは、キーバインディングと呼ばれます。

アクセスレイヤーのセキュリティの粒度は、モデルごとに異なります。各サーバモデルには、モデルによって処理されるメッセージを暗号化および認証するために使用する必要のある可能なキーを定義する、一連のアプリケーションキーがバインドされています。これにより、複数のエンティティが特定のノード機能を操作できるようになります。最大251個のアプリケーションキーをモデルにバインドできます。たとえば、Light Lightness Serverモデルには、管理者、ユーザー、およびゲストがすべてライトをオンにできるため、3つのキーがバインドされています。ただし、管理者のみがランプを構成できるため、構成サーバモデルには管理者アプリケーションキーのみがバインドされています。

2.3.9.2 難読化

ネットワークセキュリティモデルは、AESを利用して、プライバシーキーを使用して送信元アドレス、シーケンス番号、およびその他のヘッダー情報を暗号化する難読化と呼ばれるプライバシーメカニズムを利用します。難読化の目的は、ノードの追跡をより困難にすることです。

2.3.9.3 ネットワークおよびアプリケーションのキー識別子

ノードには、複数のネットワークキーまたはアプリケーションキーが含まれる場合があります。

キー識別子を使用することにより、メッセージを保護するために使用されているキーのサブセットを識別することができます。たとえば、ノードは20個のキーをチェックする代わりに、キー識別子の最下位ビットが同じである2つのキーのみをチェックする必要がある場合があります。不明なキー識別子を持つメッセージを受信した場合、ノードはすぐにそのメッセージを破棄できます。

キー識別子は、キー導出関数を使用してネットワークまたはアプリケーションキーから生成されます。

この仕様は、ネットワークキーとアプリケーションキーの個別の識別子を定義します。ネットワークキー識別子は7ビット値を使用して各ネットワークPDUで送信され、アプリケーションキー識別子は6ビット値を使用して各下位トランスポートPDUで送信されます。

2.3.9.4 初期化ベクターインデックス

ネットワークPDUには、要素が16,777,216のネットワークPDUを送信できるようにする24ビットのシーケンス番号が含まれています。シーケンス番号は、一意性を提供するためにセキュリティナンスで使用されます。したがって、シーケンス番号は折り返してはなりません。要素が2Hzで新しいメッセージを送信している場合、これらのシーケンス番号は、97日後に使い果たされます。メッシュネットワークがシーケンス番号空間で許可されているよりも長い時間動作できるようにするために、セキュリティナンスに含まれるIVインデックスと呼ばれる追加の4オクテット値が定義されています。たとえば、同じ2 Hzのメッセージ周波数を使用すると、IVインデックスを使用してネットワークの寿命を数十億年で測定できます。

あるIVインデックスから次のIVインデックスへの段階的な移行を可能にするために、各ネットワークPDUには、メッセージの送信に使用されたIVインデックスの最下位ビットが含まれています。ノードは、IV更新手順を使用して、IVインデックスを更新していることをピアノードに通知することもできます。この手順では、古いIVインデックスから新しいIVインデックスに移行するのに最低8日かかります。これにより、ノードがメッセージを送信できる頻度が24Hzに制限されます。ただし、ノードは10秒のウィンドウで100を超えるネットワークPDUを送信しないようにする必要があるため、通常、これがなくなるまでに約19日かかります。

2.3.10 フレンドシップ

フレンドシップは、低電力ノードがリッスンする必要のある時間を制限するために使用されます。ノードが継続的に受信できない場合は、処理する必要のあるメッシュメッセージを受信しない可能性があります。これには、ネットワークのセキュリティを維持するために必要なセキュリティ更新と通常のメッシュメッセージが含まれます。

低電力ノードがそのようなメッセージを受信しない場合、それは期待どおりに動作しない可能性があり、また、ネットワークの最新のセキュリティ状態を最新に保つことができず、このセキュリティが知らないうちに変更された場合、最終的にネットワークから切断される可能性があります。

フレンドシップは、低電力ノードと1つの隣接するフレンドノードの間の特別な関係です。これらのノードは、互いにシングルホップ内にあり、同じサブネット内にある必要があります。

フレンドシップは最初に低電力ノードによって確立され、開始されます。フレンドノードが確立されると、低電力ノードの消費電力を削減するのに役立ついくつかのアクションが実行されます。フレンドノードは、低電力ノードのフレンドキューを維持します。このキューには、低電力ノード宛てのすべての着信メッセージが格納されます。フレンドノードは、低電力ノードから要求されたときに、これらのメッセージを低電力ノードに配信します。また、フレンドノードはセキュリティアップデートを低電力ノードに配信します。

低電力ノードと1つのフレンドノードの間にフレンドシップが確立されると、2つのノードは”フレンド”と見なされます。

フレンドノードは、複数の低電力ノードを持つフレンドである可能性があります。低電力ノードは、単一のフレンドノードとのみフレンドになることができます。

フレンドノードと低電力ノードを示すメッシュネットワークのトポロジ例をセクション2.3.12に示し、説明します。

2.3.11 特徴

ノードの機能は、ノードがサポートする機能によって決まります。すべてのノードには、メッシュメッセージを送受信する機能があります。ノードは、オプションで1つ以上の追加機能をサポートすることもできます。

リレー機能 – アドバタイジングベアラを介してメッシュメッセージを受信および再送信して、より大規模なネットワークを実現する機能。
プロキシ機能 – GATTとアドバタイジングベアラの間でメッシュメッセージを受信および再送信する機能。
低電力機能 – フレンド機能をサポートするノードと組み合わせた場合にのみ、受信機のデューティサイクルを大幅に削減してメッシュネットワーク内で動作する機能。
フレンド機能 – 低電力機能をサポートするノードが、それらのノード宛てのメッセージを保存することによって動作するのを支援する機能。

機能をサポートするノードでは、その機能が有効または無効になっている場合があり、機能が有効になっている場合は、使用されている場合と使用されていない場合があります。

リレー機能をサポートするノードでは、この機能が無効になっている可能性がありますが、それでもリレー機能はサポートされます。その機能に必要な機能を実行していないだけです。リレー機能をサポートし、リレー機能が有効になっているノードは、リレーノードと呼ばれます。

プロキシ機能をサポートするノードでは、この機能が無効になっている可能性がありますが、プロキシ機能は引き続きサポートされます。その機能に必要な機能を実行していないだけです。プロキシ機能をサポートし、プロキシ機能が有効になっているノードは、プロキシノードと呼ばれます。

低電力機能をサポートするノードでこの機能を無効にすることはできません。低電力機能を使用してレシーバーのデューティサイクルを減らす前に、フレンド機能をサポートする別のノードとのフレンドシップを確立する必要があります。低電力機能をサポートし、フレンド機能をサポートするノードとフレンドシップを持つノードは、低電力ノードと呼ばれます。

フレンド機能をサポートするノードでは、この機能が無効になっている可能性がありますが、フレンド機能は引き続きサポートされます。その機能に必要な機能を実行していないだけです。フレンド機能をサポートし、フレンド機能が有効になっていて、低電力機能をサポートするノードとフレンドシップを持っているノードは、フレンドノードと呼ばれます。

2.3.12 トポロジー

上記のさまざまな機能をサポートするノードは、メッシュネットワークを形成できます。メッシュネットワークの図を下の図2.8に示します。

図2.8は、Q、R、およびSの3つのリレーノードを示しています。フレンド機能をサポートする3つのノードはN、O、およびPですが、Nにはフレンドシップがありません。したがって、OとPのみがフレンドノードです。低電力ノードには、I、J、K、L、およびMの5つがあります。ノードI、J、およびKのフレンドはPであり、LおよびMのフレンドはOです。ノードTは、GATTベアラーを使用してのみメッシュネットワークに接続されます。したがって、SはTとの間ですべてのメッセージを中継する必要があります。

たとえば、メッセージがTからLに送信される場合、TはGATTベアラを使用してノードSにメッセージを送信します。ノードSは、アドバタイジングベアラを使用してこのメッセージを再送信します。ノードH、R、N、およびOは、ノードSの無線範囲内にあります。したがって、彼らはこのメッセージを受け取ります。ノードLのフレンドであるノードOはメッセージを格納し、メッセージがセグメント化されたメッセージである場合、ノードOは下位トランスポートレイヤーで確認応答を返します。しばらくして、LはノードOをポーリングして新しいメッセージをチェックし、Oが最初にTから送信されたメッセージをLに転送するようにします。