2.本稿について

Bluetooth®Mesh Primerは、製品設計者や開発者などの技術専門家が、正式な技術仕様を参照したり、より深く掘り下げたりする前に、Bluetooth Mesh 技術について素早く学ぶことができるように作成されました。

本稿の目的は、正式な仕様書と同じ内容を再現したり、同じ深さまでカバーしたりすることではない。時折、仕様書からの簡単な抜粋が含まれるかもしれない。本書は、重要なBluetooth Mesh の概念を紹介・説明し、他のリソースや仕様書への道筋を示し、できれば学習曲線が少しでも険しくなくなるように、方向付ける役割を果たすものだと考えていただきたい。

3.はじめに

3.1Bluetooth 技術の進化

Bluetooth テクノロジーは2000年以来存在している。当初は、他の中間ネットワーキング機器を必要とせずに、2つのデバイスがワイヤレスでデータを交換できるようにするために作成され、すぐにワイヤレスマウスや自動車用ハンズフリーキットなどの製品で役割を見つけました。このBluetooth テクノロジーの最初のバージョンは、最初のBluetooth 製品で使用され、正式にはBluetooth BR (Basic Rate) として知られ、物理層で毎秒 100 万ビット[1](Mb/s) で動作する。その後、ビットレートを2Mb/sに倍増した同じ技術の高速バージョンが登場し、Bluetooth BR/EDR（EDRはEnhanced Data Rateの略）と呼ばれるようになった。

Bluetooth 低エネルギー（LE）は、Bluetooth コア仕様のバージョン4.0で初めて登場した[2]。これは、Bluetooth テクノロジーの新バージョンであり、前身であるBluetooth BR/EDR を置き換えるのではなく、新世代の製品に最適な能力と品質を備え、新たな困難な技術的・機能的要件を満たす能力を備えた代替品として、 BR/EDR と並存するものであった。

Bluetooth LEは、1つの機器が同時に無制限の数の受信機にデータを送信できるブロードキャスト・モードにより、2つの機器間のポイント・ツー・ポイント通信以外のトポロジーをサポートする。

Bluetooth LEはまた、Bluetooth Mesh ネットワークの基盤でもあり、何万台ものデバイスのネットワークを構築し、それぞれがネットワーク内の他のどのデバイスとも通信できるようにする。

3.2Bluetooth Mesh ネットワーキング

Bluetooth Mesh ネットワーキングは、商業ビルの問題や機会に適用できる、安全で拡張性のある標準化された無線通信技術を提供するために作られた。

ネットワーク化された照明制御は、Bluetooth Mesh の重要なアプリケーションであり、物理的に広いスペースにわたる手動および自動の照明制御が可能です。 1つのネットワーク操作で、個々の照明または照明グループに対応することができます。

Bluetooth Mesh ネットワークに基づくネットワーク照明制御で可能になる主なことをいくつか紹介しよう。

• オンとオフの切り替えができる。
• その明るさ（より正確には明度）は、人間の目の光に対する感度の変化を補正する知覚的に均一な尺度に沿って制御することができる。
• 色温度、色相、彩度を変更できる。
• センサーは、多かれ少なかれ、部屋の測定可能な特性に関する情報を関連する照明に届けることができるため、環境条件に応じて照明の状態を自動的に調整することができる。Bluetooth Mesh 、センサーと照明の間でメッセージを交換するための集中型ルーターは必要ない。
• シーンと呼ばれる特定の状態値の任意のコレクションを定義することができ、ライトは1回のリクエストで1つのシーンから別のシーンに切り替えることができる。
• 照明のグループに影響を与えるシーンの変更は、特定の時点で自動的に行われるようにスケジュールすることができます。
• 部屋の使用状況に応じたシーンの自動トリガーや、使用者がいない場合のスタンバイ状態への自動移行が可能。これは省エネに役立ちます。
• 照明の状態を変更するための事前定義されたスケジュールを設定する機能をサポート。
• メーカーが必要に応じて機器に機能を追加できるようにするベンダーモデルのコンセプトをサポートする。

ネットワークにおける照明の制御は、直接的な無線通信の範囲に制限されない。スイッチやセンサーのようなデバイスは、ビルのはるか遠く、おそらく数十階上にある照明を制御することができる。

Bluetooth Mesh テクノロジーのセキュリティは当初から設計されており、以下のような潜在的な問題や脅威に対処している：

• 情報の機密性の保護
• デバイスとネットワークのプライバシー・メカニズムにより、デバイスが追跡されるのを防ぎます。
• ネットワーク制御メッセージの操作防止
• デバイスの動作をネットワークの特定の部分のみに制限する。
• リプレイ攻撃防止
• ネットワークへのデバイスの追加が安全なプロセスで行われるようにする。
• 廃棄されたデバイスが後日不正アクセスに使用される危険性を排除し、デバイスをネットワークから安全に削除できるようにする。
• より大規模なネットワークのセキュリティを損なうことなく、ネットワーク内の関連機能へのゲストアクセスを提供したり、取り消したりする機能を提供する。

Bluetooth Mesh ネットワークとワイヤレス・ネットワーク照明制御を備えたビルは、さまざまなメリットを享受できる。

• センサーが周囲の明るさや部屋の使用状況などのデータを提供し、自動的に照明レベルを調整できるため、エネルギー効率が向上する。
• 照明は、スイッチやスマートフォンアプリケーションのユーザーインターフェース（UI）に触れるだけで、プレゼンテーションや大企業の円卓会議など、部屋の現在の用途に合わせて最適に再設定することができる。
• Bluetooth Mesh デバイスが利用可能な使用状況とデバイスの健全性データによって、プロアクティブ・メンテナンスが促進される。
• 建物内の物理的なレイアウトや照明条件の変更も簡単に行えます。ワイヤレスだ！
• Bluetooth Mesh テクノロジーは、プロトコル・スタック全体と、デバイスの動作、能力、インターフェイスにまたがる一連の標準仕様によって定義されている。このことは、どのメーカーの製品であっても相互運用が可能であることを意味する。Bluetooth Mesh テクノロジーを採用する企業は、単一のメーカーや小規模で閉鎖的なグループに縛られることはありません。

4.主な特徴とコンセプト

Bluetooth Mesh ネットワーク・トポロジーを理解するには、Bluetooth LE の世界のどこにもない一連の基本的な機能、技術用語、概念について学ぶ必要がある。このセクションでは、最も基本的な機能、用語、概念について説明する。

4.1Bluetooth 運用モード

Bluetooth LE は、デバイスが相互に通信できる多くの異なる方法を定義する。これらは正式には「Bluetooth コア仕様」で定義され、本稿では非公式に「オペレーショナル・モード」と呼ぶ。

様々な動作モードは、デバイスによって形成されるトポロジー、可能な通信方向、接続指向モードか接続レスモードかといったモードの基礎となる技術的な点など、多くの点で異なる。

コネクションオリエンテッド通信では、デバイスはまず、送受信タイミングパラメータなど、その後の通信の重要な局面で合意できる情報を交換する。コネクションレス型通信では、このようなことは起こらず、送受信タイミングも同様に事前合意されない。Bluetooth LEでは、コネクション型通信は常に2つのデバイス間で行われるのに対し、コネクションレス型通信は、1つの送信デバイスが複数の受信デバイスと通信する際に、パラメータに関する事前合意情報の有無にかかわらず使用することができる。

トポロジーは、通信機器間に形成されうる関係の冗長性に関係する。3つの異なるトポロジーが認識されている：

• 一対一
• 一対多
• 多対多

ある動作モードでは、アプリケーション・データの通信は一方向のみであるが、他の動作モードでは双方向通信が可能である。

モードによっては、パケットの送信に正確に規則的なスケジュールを使用する場合もあれば、不規則な場合もある。

現在、7つのオペレーションモードが定義されている。それらは以下の通りである：

• LE 非同期接続指向論理トランスポート（LE ACL）
• LE広告放送（ADVB）
• LE定期広告（PADVB）
• LE 応答付き定期広告（PAwR）
• コネクテッド・アイソクロナスストリーム（CIS）
• ブロードキャスト・アイソクロナスストリーム（BIS）
• Channel Sounding (CS)

Bluetooth Core Specificationでは、各モードを詳細に定義している。

表1は、比較のために7つの動作モードの主な属性をまとめたものである。なお、Channel Sounding （CS）は、2つのデバイス間の距離の安全な計算のみをサポートするように設計された特別なモードであり、アプリケーション・データの転送には使用されない。

Operational Mode	Connection-Oriented or Connectionless	Topology	Transmit Schedule	Direction of Application Data
LE ACL	connection-oriented	point-to-point	regular	bidirectional
ADVB	connectionless	one-to-many	irregular	unidirectional
PADVB	connectionless	one-to-many	regular	unidirectional
PAwR	connectionless	one-to-many	regular	bidirectional
CIS	connection-oriented	point-to-point	regular	bidirectional
BIS	connectionless	one-to-many	regular	unidirectional
CS	N/A	one-to-one	regular	N/A

表1 -Bluetooth 運用モードの属性

Bluetooth Mesh テクノロジーは動作モードではありません。これは、Bluetooth LE を無線ネットワーキング技術として使用することを可能にする、一連の定義された手順、標準的なアプリケーション層の動作、その他の機能を有するプロトコルである。このプロトコルは、Bluetooth LE のコア機能（いくつかの動作モードを含む）の上に構築されており、ある時はコネクションレスで動作し、ある時はコネクションオリエンテッドな通信を使用する。原則として、Bluetooth Mesh ネットワークによって形成されるトポロジーは多対多である。なぜなら、どのデバイスも他のどのデバイスとも通信する可能性があり、アプリケーションデータの通信はどちらの方向にも起こり得るからである。

通信は、Bluetooth LE がベアラと呼ばれるメカニズムを用いて適切な方法で伝送するメッセー ジを用いて実現される。デバイスは、エンド・ツー・エンドの通信範囲が個々のデバイス（mesh ）の無線通信範囲をはるかに超えて拡張されるように、ネットワーク全体にわたって他のデバイスにメッセージを中継することができる。

4.2 デバイスとノード

mesh ネットワークの一部であるデバイスはノードと呼ばれ、そうでないものはプロビジョニングされていないデバイスと呼ばれる。

プロビジョニングされていないデバイスをノードに変換するプロセスをプロビジョニングと呼ぶ。

プロビジョニングとは、プロビジョニングされていないデバイスが一連のセキュリティキーを所有し、ユニキャストアドレスが割り当てられ、Provisionerと呼ばれるデバイスのデータベースに登録される手順である。Provisioner は通常、タブレットまたはスマートフォンです。

4.3 エレメント

ノードの中には複数の構成部分を持ち、それぞれが独立して制御できるものがあります。Bluetooth Mesh の用語では、これらのパーツをエレメントと呼ぶ。図1は、LED照明製品をBluetooth Mesh ネットワークに追加した場合、3つのエレメントを持つ1つのノードが形成されます。

図1 - 3つの要素からなる照明ノード

4.4 メッセージ

ノードが他のノードのステータスを照会したり、他のノードを何らかの方法で制御する必要がある場合、適切なタイプのメッセージを送信します。ノードが他のノードにステータスを報告する必要がある場合は、メッセージを送信します。mesh ネットワークの通信はすべてメッセージ指向で、多くのメッセージ・タイプが定義されており、それぞれに固有のオペコードがあります。

メッセージは大きく2つに分類される：

• 確認されたメッセージは、それを受信したノードからの応答を必要とする。応答には2つの目的がある。それは、関連するメッセージが受信されたことを確認することと、メッセージ受信者に関するデータを元のメッセージ送信者に返すことである。アクノレッジされたメッセージの送信者は、期待された応答を受け取らなかった場合、メッセージを再送することができる。したがって、アクノレッジされたメッセージは冪等でなければならない。したがって、確認応答付きメッセージは冪等でなければならない。これは、確認応答付きメッセージがノードに複数回到着した場合の影響は、それが1回しか受信されなかった場合と同じになることを意味する。
• 未承認のメッセージには返事は不要です。

ほとんどのBluetooth Mesh シナリオは、メッセージングのこのモデルは非常によくスケールするので、確認されていないメッセージを使用することを含む。これは、メッセージのコピーを複数回連続して再送信するようにノードを構成することで信頼性を高めている。

確認応答を返す必要のあるメッセージは、ターゲットが 1 台のデバイスの場合はうまく機能しますが、複数のデバイスのグループをターゲットにする場合はうまく機能しません。ノードやそのエレメントのコンフィギュレーションに関わるメッセージのほとんどは、確認応答付きメッセージを使用します。

リレーとして知られるシステムによって、メッセージをすぐ近くの無線範囲を超えて届けることができる。中継については4.19 メッセージ中継で説明する。

4.5 住所

Bluetooth Mesh アドレスには3つのタイプがある。

ユニキャストアドレスは、1つのエレメントを一意に識別する。ユニキャストアドレスは、プロビジョニングプロセス中にデバイスに割り当てられる。

グループアドレスはマルチキャストアドレスである。このアドレス・タイプは、パブリッシュとサブスクライブと呼ばれるプロセスを通じて、複数のデバイスが同じ送信メッセージを受信することを可能にする。グループ・アドレスは、Bluetooth SIG 、固定グループ・アドレスとして定義されるか、動的に割り当てられる。SIG 固定グループ・アドレスは7つ定義されている。これらは、オール・ノード、オール・リレー、オール・フレンド、 オール・プロキシ、オール・ディレクテッド・フォワーディング・プロキシ、 オール・イプト・ノード、オール・イプト・ボーダー・ルーターと名付けられる。プロキシ、フレンド、リレーという用語については、後ほど説明する。

動的グループアドレスは、設定アプリケーションを介してユーザーによって確立され、例えば、建物の各部屋に対応するグループアドレスを定義するなど、建物の物理的な構成を反映することが期待される。

仮想アドレスはグループアドレスに似ており、パブリッシュとサブスクライブを 通じて、1つの送信メッセージを複数のデバイスが受信できるようにする。このアドレスは128ビットのUUID値の形をとり、任意のエレメントと関連付けることができ、ラベルによく似ている。例えば、仮想アドレスは製造時点で事前に設定することができ、mesh ネットワークに配備されている、製造元が製造したすべての会議室プロジェクターのアドレスを簡単に設定できるなどのシナリオに使用できる。

4.6 発行／購読

メッセージを送信する行為はパブリッシングとして知られている。ノードは、処理のために特定のアドレスに送られたメッセージだけを受信するように設定され、これはサブスクライブと呼ばれる。

通常、メッセージはグループアドレスまたはバーチャルアドレスに宛てて送られます。グループ名とバーチャル・アドレス名は、エンド・ユーザーにとって容易に理解できる意味を持ち、デバイスを設定する際に簡単かつ直感的に使用できる。

図2では、Switch 1というノードがグループ・アドレスReceptionにパブリッシュしていることがわかります。ノードLight 1、Light 2、Light 3はそれぞれReceptionアドレスをサブスクライブしているため、このアドレスにパブリッシュされたメッセージを処理します。つまり、ライト1、ライト2、ライト3は、スイッチ1を使用してオン/オフを切り替えることができます。

スイッチ2はグループアドレス「Accounts」にパブリッシュします。 ライト3だけがこのアドレスにサブスクライブしているので、スイッチ2によって制御されている唯一のライトです。この例は、ノードが複数の異なるアドレスにアドレスされたメッセージをサブスクライブできるという事実も示していることに注意してください。これは強力かつ柔軟です。

同様に、スイッチ5と スイッチ6の両方が同じ引受先アドレスに発行していることに注目してください。

パブリッシュ/サブスクライブ・コミュニケーション・モデルによるグループ・アドレスとバーチャル・アドレスの使用には、ネットワークへのノードの削除、交換、追加が他のノードの再構成を必要としないという追加的な利点がある。経理部門に追加の照明を設置する場合のことを考えてみてください。新しいデバイスは、プロビジョニングプロセスを使用してネットワークに追加され、アカウントアドレスにサブスクライブするように構成される。他のノードはネットワークのこの変更によって影響を受けません。スイッチ 2 は以前と同じようにAccountsにメッセージを発行し続けますが、ライト 3と新しいライトの両方が応答します。

図2 - 発行と購読

4.7 ステートとプロパティ

要素はさまざまな状態になる可能性があり、これはBluetooth Mesh では状態値という概念で表現されている。

ステートとは、エレメントとそのモデルの1つに含まれる、ある型の値のことである。）状態はまた、関連する振る舞いを持ち、他の文脈で再利用されることはありません。

Bluetooth Mesh は、Generic OnOffと呼ばれる状態を定義している。ライトはこの状態を持ち、Onの値でライトが点灯し、Offの値でライトが消灯します。

ジェネリックという言葉の意味については後述する。

プロパティは、要素に関連する値を含むという点ではステートに似ている。 しかし、他の点ではステートとは異なる。

Bluetooth LE[3]に慣れ親しんだ読者であれば、特性についてご存知であろうし、異なる GATT サービス内など、異なるコンテクストにまたがって再利用可能な、定義された動作を伴わないデータ型であることを想起されよう。mesh プロパティは、Bluetooth Mesh デバイスにおいて特性を解釈するためのコンテキストを提供する。

プロパティに関連するコンテキストの重要性と使用法を理解するために、例えば、現在屋内周囲温度と 現在屋外周囲温度など、多くの関連プロパティを持つ8ビットの温度状態タイプである特性Temperature 8を考えてみましょう。これらの2つのプロパティにより、センサーは、受信クライアントが温度値が持つコンテキストを判断できるような方法でセンサーの読み取り値を公開することができ、その真の意味をより理解することができます。

4.8 ステートと基本操作

メッセージは、mesh デバイスに作用する操作を呼び出すメカニズムである。メッセージ・タイプは、状態または状態値の集合に対する操作を定義します。すべてのメッセージは、Bluetooth Mesh がサポートする操作のタイプを反映して、3つのタイプに大別されます。3つのタイプの省略名は GET、SET、STATUS です。

GETメッセージは、1つ以上のエレメントに指定された状態の値を要求する。STATUSメッセージはGETに応答して送られ、関連する状態の値を含む。

SET メッセージは与えられた状態の値を変更します。確認された SET メッセージは、SET メッセージに対する応答として STATUS メッセージが返されます。

STATUSメッセージは、GETメッセージに応答して送信されたり、SETメッセージに応答して送信されたり、他のメッセージとは無関係に送信されたりする。

メッセージによって参照される特定の状態は、メッセージのオペコードから推測される。一方、プロパティは、16 ビットのプロパティ ID を使って、ジェネリック・プロパティ関連メッセージの中で明示的に参照されます。

4.9 状態遷移

ある状態から別の状態への変化は状態遷移と呼ばれる。遷移は瞬時に起こることもあれば、遷移時間と呼ばれる一定期間にわたって実行されることもある。状態遷移は、アプリケーション層の動作やノードの外観に影響を与える可能性があります。

4.10 バウンド状態

状態間には、一方の変化が他方の変化を誘発するような関係が存在することがある。このような関係はステート・バインディングと呼ばれる。1つの状態が他の複数の状態に束縛されることもある。

例えば、調光スイッチで制御されるライトを考えてみよう。ライトは2つの状態、ジェネリック・オンオフと ジェネリック・レベルを持ち、それぞれがもう一方に束縛されています。ジェネリック・レベルの値がゼロになるまで（完全に調光されるまで）ライトの明るさを下げると、ジェネリック・オンオフがオン状態からオフ状態に遷移します。

4.11 モデル

モデルは、前述の概念をまとめ、オブジェクト指向ソフトウェア開発におけるクラスや オブジェクトのように、状態データと関連するメッセージ・タイプや機能の組み合わせを定義する。

モデルは通常、サーバーモデルか クライアントモデルのどちらかである。

• サーバーモデルは、状態、状態遷移、状態バインディング、およびそのモデルを含むエレメントが送受信できるメッセージのコレクションを定義します。また、サポートされるメッセージ、状態、状態遷移に関連する振る舞いも定義します。
• クライアントモデルはステートを定義しません。その代わりに、対応するサーバーモデルで定義されたステートの状態をGET、SET、または取得するために送受信するメッセージを定義します。

モデルは、他のモデルを拡張することによって作成することができる。拡張されていないモデルはルート・モデルと呼ばれる。

モデルは不変であり、振る舞いを追加したり削除したりして変更することはできない。新しいモデル要求を実装するための正しい、そして唯一許されるアプローチは、既存のモデルを拡張することです。

ファウンデーション・モデルとは、mesh ネットワークを構成・管理するために必要なモデルである。その他のモデルは、特定のクラスの製品に必要とされる特定のタイプの機能に関係する。

4.12 ジェネリック

ONとOFFという単純な考え方に代表されるように、多くの異なるタイプのデバイスは、しばしば意味的に等価な状態を持つことが認識されている。照明、扇風機、電源ソケットを考えてみよう。

その結果、Bluetooth Mesh モデル仕様では、Generic OnOffや Generic Levelといった一連の再利用可能な汎用ステートを定義している。

同様に、ジェネリック・ステートを操作する一連のジェネリック・メッセージも定義されている。例えば、Generic OnOff Getや Generic Level Setなどがある。

ジェネリック・ステートとジェネリック・メッセージは、ジェネリック・オンオフ・サーバーのようなジェネリック・サーバー・モデルや、ジェネリック・レベル・クライアントのようなジェネリック・クライアント・モデルなど、一般化されたモデルで使用される。

ジェネリックを使うことで、新しいモデルを作成することなく、Bluetooth Mesh 、幅広いタイプのデバイスをサポートすることができる。モデルは、他のモデルを拡張することによっても作成できることを忘れないでください。このように、ジェネリック・モデルは、新しいタイプのデバイスのためのモデルを素早く作成するための基礎となります。

図3 - 一般的なモデル

4.13 シーン

シーンは保存された状態の集まりであり、特別なタイプのメッセージの受信に応答して、または指定されたスケジュールされた時間に、呼び出して現在の状態にすることができる。シーンは16ビットのシーン番号で識別され、mesh ネットワーク内でユニークです。

シーンは、一連のノードを、1つの協調動作で、以前に保存された、補完的な状態の所定のコレクションに設定することを可能にする。

朝、受付の温度を20℃にし、LEDライトを一定の明るさにし、受付デスクのランプを暖かみのある黄色に設定したいとします。このシナリオ例の様々なノードを手動でこれらの状態に設定した後、コンフィギュレーション・アプリケーションを使用してシーンとして保存し、後で適切なシーン関連のmesh メッセージを送信することで要求に応じて、またはスケジュールされた時間に自動的にシーンを呼び出すことができます。

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

Bluetooth Mesh ネットワークは、アドレス空間、ネットワーク・キー、アプリケーション・キー、IVインデックスという4つの共通リソースによって定義される。Bluetooth Mesh ネットワークは、一連のサブネットに細分化できる。TCP/IPのようなプロトコルに基づくネットワークとは異なり、特定のネットワークに属することは、デバイスのアドレスには一切関係しない。その代わり、Bluetooth Mesh ネットワークとサブネットメンバーシップ は、主にノードにネットワーク・キーを発行することで実現されます（4.15 鍵参照）。1つのエレメントに複数のネットワーク・キーを発行することができるため、複数のサブネットのメンバー 。サブネットは互いに完全に分離していることもあれば、重複していたり、別のサブネットに完全に含まれていることもある。

サブネットには、以下のような用途がある：

• あるデバイスグループを他の無関係なデバイスから隔離することで、ネットワークにセキュリティを加える。
• サブネットの境界を越えてメッセージが流れないようにすることで、無線スペクトラムの利用をより効率的にすることができる。
• ネットワーク管理を容易にする。例えば、「ゲスト・デバイス」は、サブネットとそのネットワーク・キーを使って、ネットワークのごく一部に一時的にアクセスすることができる。

図4は、ホテルの各客室に使用されるサブネットを示したものである。

1つのサブネットはプライマリ・サブネットに指定される。ネットワークの恒久的なメンバーになると予想されるデバイスは、プライマリ・サブネットのメンバーになる。

図4-ホテルの各部屋のデバイスを分離するためにサブネットを使用した例

4.15 キー

Bluetooth Mesh プロトコル仕様では、いくつかのタイプのセキュリティ・キーが定義されている。

• 各ノードには一意のデバイスキー（DevKey）があります。このキーの値を知っているのは、キーが発行されたデバイスと Provisioner だけです。このキーは、構成プロセスを安全に行うために使用されます。
• デバイスには少なくとも1つの共有ネットワーク・キー（NetKey）が発行される。このタイプのキーは、ネットワーク・レイヤでの通信を保護します。特定のNetKeyを所有することで、ノードは関連するネットワークまたはサブネットの一部となる。プライマリNetKeyと呼ばれる特別なキーは、プライマリmesh ネットワークに関連します。
• mesh ネットワークには、少なくとも1つのアプリケーション・キー（AppKey）がある。ネットワークがサポートするアプリケーションの例としては、照明、空調、暖房などがある。AppKey は、上位トランスポート層での通信を保護するために使用され、セキュリティの観点から、異なるアプリケーション間でメッセージングを分割する効果がある。

デバイス・キーとプライマリ・ネットワーク・キーは、プロビジョニング・プロセス（「4.16 プロビジョニング」参照）中に各ノードに提供される。アプリケーション・キーと、必要に応じてサブネットに対応するさらなるネットワーク・キーは、コンフィギュレーション中にデバイスに発行される（4.17 コンフィギュレーション参照）。

4.16 プロビジョニング

プロビジョニングとは、デバイスがmesh ネットワークに参加し、ノードとなるプロセスである。これにはいくつかの段階があり、さまざまなセキュリティ・キーが生成され、それ自体が安全なプロセスである。

プロビジョニングは通常、スマートフォンやタブレットなどのデバイス上のアプリケーションを使って行われる。他のアーキテクチャ（クラウドベースのプロビジョニングなど）も可能である。この容量では、プロビジョニングプロセスの駆動に使用されるデバイスを「Provisioner」、プロビジョニングされるデバイスを「Provisionee」と呼ぶ。

Provisioner は、直接電波の届く範囲にあるデバイスのプロビジョニングを行うことができます。リモートプロビジョニングと呼ばれるオプション機能を使用すると、ネットワーク内の任意の場所にあるデバイスを、Provisionerから任意の距離でプロビジョニングできます。

4.16.1 直接プロビジョニング

ダイレクト・プロビジョニング・プロセスは、5つのステップを経て進行する。

ステップ1.ビーコン

未プロビジョニングデバイスは、未プロビジョニングデバイスビーコンをブロードキャストすることで、プロビジョニングが可能であることを示す。これは、広告パケットのペイロードフィールドにMesh ビーコン広告データ（AD）タイプが含まれることで示される。

ユーザーは、例えばボタンを押すことによって、このように新しいデバイスの広告を開始する必要があるかもしれない。

ステップ2.招待状

このステップでは、Provisioner は Provisionee に Provisioning Invite PDU の形式で招待を送信する。ビーコンしている被提供デバイスは、Provisioning Capabilities PDU で自分自身に関する情報を応答する。

ステップ 3.公開鍵の交換

Provisioner と Provisionee は、直接または帯域外（OOB）方式で、静的または一時的な公開鍵を交換する。

サポートされている場合、X.509 証明書を公開鍵の認証に使用できる。 4.16.3 証明書ベースのプロビジョニング』参照。

ステップ4.認証

このステップでは、ProvisionerとProvisioneeは特定のアクションを実行して認証を行う。たとえば、Provisionee は、その能力に適したアクションを使用して、ランダムな 1 桁または複数桁の数値を何らかの形式でユーザーに出力することができる。たとえば、複数桁の数値を表示する。次に、ユーザーは、新しいデバイスが出力した数字を Provisioner に入力し、2 台のデバイス間で、乱数を含む暗号交換が行われ、2 台のデバイスのそれぞれが他方のデバイスに対する認証を完了する。同様に、Provisioner は、被提供者に入力しなければならない値を出力することもできる。デバイスの入出力機能によって、さまざまな認証方法が可能である。

ステップ5.プロビジョニングデータの配布

認証が正常に完了すると、2 台のデバイスはそれぞれ、秘密鍵と交換したピア公開鍵からセッ ション・キーを生成する。セッション・キーはその後、ネットワーク・キー（NetKey）と呼ばれるセキュリティ・キーと、デバイス・キー（DevKey）と呼ばれるデバイス固有のキーなど、プロビジョニング・プロセスの完了に必要なデータの配布を保護するために使用される。デバイスキーは、Provisioner と Provisionee がそれぞれ独立して計算するため、無線で送信されることはない。

プロビジョニングが完了すると、プロビジョニングされたデバイスは、DevKey、ネッ トワークの NetKey、IV インデックスとして知られるmesh セキュリティパラ メータ、および Provisioner によって割り当てられたユニキャストアドレスを持つ。これでノードと呼ばれるようになる。

4.16.2 リモートプロビジョニング

リモートプロビジョニング（RPR）を使用すると、Provisionerとプロビジョニングされていないデバイスは、2つのデバイス間のネットワークを介した通信経路が形成されていれば、場所を問わない。これは、多くの実世界の状況に対して、より実用的なプロビジョニングアプローチを提供する。

図 5 - リモート・プロビジョニング

4.16.3 証明書ベースのプロビジョニング

プロビジョニング・プロセスには、認証ステップが含まれる。認証は、たとえば複数桁の数字を表示するなど、さまざまな方法で実現できる。一般に、認証には、（たとえば）LEDの点滅数をカウントできるように、プロビジョニングを実行する人の視界にプロビジョニングされるデバイスがあることが必要である。しかし、これは必ずしも現実的ではない。特に、リモート・プロビジョニングが使用されている場合、プロビジョニングされるデバイスは、おそらく建物の反対側にあるなど、完全に視界から外れている可能性がある。

Bluetooth Mesh は、プロビジョニング時に X.509 証明書の使用をサポートしています。X.509証明書を使用してプロビジョニングされるデバイスは、視界に入る必要がないため、リモート・プロビジョニングを非常によく補完する。

4.17 コンフィギュレーション

各ノードは、標準構成サーバー・モデル内に実装され、構成クライアント・モデルを使用してアクセスされる、構成状態の標準セットをサポートします。構成状態データは、ノードの構成と、特定のアプリケーションやデバイス・タイプの動作に依存しない機能に関係します（これらは、デバイスに実装された他のモデルによって管理されます）。

コンポジション・データの状態はページに分割され、その要素やサポートするモデルなど、ノードに関する情報が含まれます。Large Composition Data Serverモデルはこのステートを補完し、複雑な構成と多数のコンポーネントを持つデバイスのサポートを提供します。DALI（Digital Addressable Lighting Interface）デバイスは、そのようなデバイスの代表例です。

DALIデバイスは通信バスを中心に構築されており、最大128個のコンポーネント（DALI用語ではバス ユニットと呼ばれる）を簡単に抜き差しすることができる。mesh ネットワークの一部である場合、DALIコンポーネントは、DALIデバイス全体を表す複雑なmesh ノードの要素となります。デバイスのファームウェアがバスに接続されたコンポーネントの変更を検出した場合、その構成データは自動的に更新され、プラグアンドプレイ機能を提供することができる。

ノードがサポートする機能（「4.18 機能」を参照）は、Configuration Server ステートによって示されます。ノードがサブスクライブしているアドレスは、サブスクリプション・リスト状態に格納されます。ノードがメンバー であるネットワークを示すネットワーク・キーとサブネット・キーは NetKey List 状態に格納され、アプリケーション・キーは AppKey List 状態に格納されます。

一連のコンフィギュレーション・メッセージによって、コンフィギュレーション・クライアント・モデルとコンフィギュレーション・サーバー・モデルは、コンフィギュレーション・サーバー・モデルの状態に対するGET、SET、STATUS操作をサポートすることができます。

4.18 特徴

すべてのノードはmesh メッセージの送受信が可能ですが、ノードのオプション機能がいくつかあり、特別な機能を追加することができます。このようなオプション機能には、リレー機能、プロキシ機能、フレンド機能、および低電力機能の4つがあります。サポートされている機能は、ある時点で有効または無効にすることができます。

4.18.1 リレーノード

中継機能をサポートするノードは中継ノードと呼ばれ、受信したメッセージを再送信することができます。中継とは、メッセージがmesh ネットワーク全体を横断し、中継されることで機器間を複数ホップすることができる仕組みのことである。

Mesh ネットワークPDUにはTTL（Time to Live）と呼ばれるフィールドがある。これは整数値をとり、メッセージがネットワークを通過するホップ数を制限するために使用される。例えばTTLを3に設定すると、メッセージは最大2回中継されることになる。TTLを0に設定すると、メッセージはまったく中継されなくなり、送信元デバイスから宛先デバイスまで直接1ホップしか移動しなくなります。TTL値を1にすると、そのメッセージはすでに何回か中継されており、再度中継されるべきではないことを意味する。TTL = 1で送信されたメッセージはデバイスを離れないため、ループバックを経由してノード上のローカル通信にのみ使用できる。

ネットワークと無線スペクトラムを最も効率的に使用するために、Directed Forwardingと呼ばれるオプション機能を使用することができます。ディレクティッド・フォワーディングは、情報提供されたより効率的な方法で中継を使用します。

中継の仕組みについては4.19 メッセージの中継を参照のこと。

4.18.2 低消費電力ノードとフレンドノード

ノードの種類によっては、電源が限られており、できるだけエネルギーを節約する必要があります。このようなタイプのデバイスは、主にメッセージの送信に関係するが、時折メッセージを受信する必要がある。

小さなコイン電池で動く温度センサーを考えてみよう。温度が設定された上下のしきい値を上回ったり下回ったりするたびに、1分間に1回、温度の読み取り値を送信する。温度がこれらのしきい値内にとどまる場合、メッセージは送信されない。これらの動作は簡単に実装でき、消費電力に関する問題は特に発生しない。

しかし、ユーザーはセンサーにメッセージを送り、温度しきい値の状態値を変更することもできる。これは比較的稀なイベントであるが、センサーはこれをサポートしなければならない。メッセージを受信する必要性は、デューティサイクルと消費電力に影響を与える。100%の受信（RX）デューティサイクルは、センサーが温度閾値設定メッセージを見逃さないことを保証するが、法外な量の電力を使用する。低いデューティ・サイクルはエネルギーを節約しますが、センサーがコンフィギュレーション・メッセージを見逃すリスクがあります。

この難問に対する答えは、フレンド・ノードと友情の概念である。

この例の温度センサーのようなノードは、低消費電力ノード（LPN）に指定され、センサーの設定データにそのことを示す機能フラグが設定されることがあります。

LPNは、電力に制約のない（例えばAC電源が常設されている）別のノードと連携して動作します。このデバイスをフレンド・ノードと呼びます。フレンドノードはLPN宛のメッセージを保存し、LPNがフレンドノードにメッセージ待ちのポー リングをするたびにメッセージを送ります。LPNは、電力を節約する必要性と、メッセージを受信して処理するタイミングとのバランスを取るため、比較的頻繁にフレンドをポーリングすることはありません。その際、MD (More Data) と呼ばれるフラグで、Friend ノードからさらに送信するメッセージがあるかどうかを LPN に知らせます。

LPNとフレンド・ノードの関係はフレンドシップとして知られています。フレンドシップは、Bluetooth Mesh ネットワークにおいて、メッセージを受信する必要がある、電力に制約のあるノードが効率的に機能するための鍵となります。

4.18.3 プロキシ・ノード

4.18.3.1 プロキシノードについて

ほとんどのスマートフォンやタブレットを含め、Bluetooth LE をサポートするデバイスは世界中に膨大に存在する。通常、このようなデバイスにはBluetooth Mesh ネットワーキング・スタックが搭載されているが、GATT（Generic Attribute Profile）で定義された手順を使って他のデバイスと接続し、相互作用する機能がある。

プロキシー・ノードは GATT サービスといくつかの特性を実装し、他のBluetooth LE デバイスがBluetooth Mesh ネットワークにメッセージを送受信するために使用することができます。プロキシ・ノードは GATT サーバーとして機能し、他のデバイスは GATT クライアントとなる。

Proxyプロトコルと呼ばれるプロトコルが定義されている。GATTデバイスは、Proxyノードによって実装されたGATT特性内からProxyプロトコルPDUを読み書きする。ProxyノードはこれらのPDUをmesh ネットワークPDUに、またはネットワークPDUから変換する。Proxyプロトコルの使用に関して、ProxyノードはProxyサーバ、他のデバイスはProxyクライアントとみなされる。

プロキシクライアントデバイスは、ネットワークのメンバー 、他のデバイスと同様に、最初にプロビジョニングする必要があります。

プロキシノードは、完全なBluetooth Mesh ネットワーキング・スタックを持たないBluetooth LE 機器がmesh ネットワークのノードと対話できるようにする。実際には、完全なオペレーティング・システムと高解像度ディスプレイを持つ強力なデバイスに、ネットワーク内の照明などのデバイスと対話するためのグラフィカル・ユーザー・インターフェース（GUI）をユーザーに提供するアプリケーションを搭載できることを意味する。

図6 -mesh プロキシノードを介して通信するスマートフォン

4.18.3.2 プロキシ発見

プロキシノードは2つのモードのいずれかで動作し、スマートフォンのアプリケーションのようなプロキシクライアントによって2つの方法のいずれかで検出され、エンゲージされる。

4.18.3.2.1 連続広告モード

このモードでは、ProxyノードはProxyクライアントデバイスが存在するかどうかに関係なく、間隔を置いて広告パケットをブロードキャストする。ブロードキャストパケットには、サービスデータと呼ばれる広告データ項目が含まれ、GATTMesh Proxy ServiceのUUID識別子と他のサービスデータが含まれる。Mesh Proxy ServiceのUUIDが存在することで、広告デバイスがProxyノードであることが識別される。Proxyクライアントは、Mesh Proxy Service UUIDを含む広告パケットをスキャンすることでProxyノードを発見し、Proxyノードに接続し、接続を介してProxy PDUを交換することができる。Proxyノードは広告ベアラを使用してmesh ネットワークとの間でPDUを中継する。

このアプローチで使用される無差別で多かれ少なかれ永続的な広告は、最適とは言えず、Bluetooth の広告チャネルを無駄に使用している。mesh ネットワークの大多数のノードが使用する広告ベアラは、これらのチャネルが利用可能であることに依存している。

4.18.3.2.2 オンデマンド・プライベート・プロキシ・モード

勧誘と呼ばれる技法を含む、より効率的な第二のアプローチが定義されている。これはオンデマンドプライベートGATTプロキシ(On-Demand Private GATT Proxy)と呼ばれ、サポートはオプションである。

このアプローチでは、ProxyサーバーがProxyクライアントが存在し、そのサー ビスを必要としていることを認識するまで、広告は開始されない。

On-Demand Proxy機能をサポートするProxyクライアントは、広告によってProxyノードのサービスが必要であることを示す。プロキシが送信する広告パケットには、Solicitation PDUと呼ばれるPDUが含まれる。これには、Mesh Proxy Solicitation ServiceのUUIDとその他の情報が含まれる。

プロキシ・サーバ・ノードはパッシブ・スキャンと呼ばれるスキャンを行う。パッシブスキャンはパケットの送信を伴わないため、無線チャネルに影響を与えない。ProxyクライアントからSolicitation PDUを受信して認証されると、ProxyノードはProxyクライアントが接続できるように広告を開始し、標準的な方法で確立された接続を介してProxy PDUの交換を開始する。

オンデマンド・プライベートGATTプロキシは、プロキシクライアントが広告を出すべきだと指示したときだけ広告を出すことで、広告チャネルを効率的に利用する。また、Mesh プライベートビーコンを使用するため、プライバシーも向上する。7.7 プライバシー参照。

4.19 メッセージ中継

4.19.1 マルチホップ・メッセージ配信

Bluetooth Mesh ネットワークは広いエリアにまたがることがあり、建物の一部分にあるノードは他のノードから直接電波が届かないことが多い。発信ノードがメッセージを送信する宛先ノードからどれだけ離れていても、すべてのノード間でメッセージベースの通信を可能にするために、Bluetooth Mesh 、特定のノードによってメッセージが再送信され、宛先に到着するまでネットワークを介してノードからノードにホップするシステムを使用します。

一般的に、メッセージを再送信するプロセスは中継と呼ばれ、これが中継ノードの機能である。

中継は2つの異なる方法のいずれかで機能する。1つ目は管理されたフラッディングと呼ばれる方法で、2つ目は有向転送と呼ばれる方法である。

4.19.2 管理された洪水

リレーノードはデフォルトで、より単純なマネージドフラッディングアプローチを使用する。マネージドフラッディングでは、Relayが受信したメッセージが再送される。

しかし、特定の条件下では、Relayは再送信を行わないため、電波スペクトラムの効率向上に役立ちます。例えば、以下のようなものがあります：

• PDUにはTTL（Time to Live）というフィールドがある。送信者はこのフィールドに整数値を設定し、メッセージの中継回数を制限する。これにより、メッセージがネットワーク上で無意味にリレーされるのを防ぐことができる。
• 受信したメッセージの詳細はリレーによってキャッシュされる。キャッシュはリレーの前にチェックされる。メッセージがキャッシュにあった場合、そのメッセージは以前に受信され、再送されたものとみなされる。

4.19.3 直接転送

有向転送アプローチは、管理されたフラッディングよりも洗練されており、無線スペクトラムをより効率的に使用する。有向転送を使用する場合

• Relayノードは、そのノードがメンバー 、そのメッセージを経由して宛先に到達できる一連のノードであることを知っている場合にのみ、メッセージを再送信する。このノードを経由しても宛先に到達できない場合、メッセージは破棄されます。こうして無線送信が削減され、スペクトラムの利用がより効率的になるため、ネットワーク内のメッセージングにより多くの容量が残され、衝突が発生する確率が減少します。
• 宛先への配送が可能なノードのシーケンスは、コンフィギュレーション中に手動で作成されるか、さまざまなシステム手順によって自動的に作成・維持される。

セクション6.4中継では、有向転送についてさらに詳しく説明する。

ディレクティッド・フォワーディングの詳細については、Bluetooth Mesh ディレクティッド・フォワーディングを参照のこと。

4.20 デバイスファームウェアの更新

4.20.1 ファームウェアについて

Bluetooth Mesh デバイスは、Bluetooth Mesh プロトコルとデバイスがサポートするモデルを実装するファームウェアを実行している。

通常、ファームウェアはその寿命の間に更新される必要がある。Bluetooth Mesh 機器のファームウェアを更新する理由は以下の通りである：

• デバイスがサポートするBluetooth Mesh プロトコルのバージョンをアップグレードする。
• さらなるmesh モデルへの対応により、新たな機能を追加する。
• バグを修正する

4.20.2 実際的な問題

Bluetooth Mesh ネットワークのデバイスは、物理的に届きにくい場所に設置されていることが多い（例 えば、天井に取り付けられている）。現実的な観点からは、物理的な有線接続に依存するファームウェア・アップデートの手順は、 問題となる可能性が高い。アップデートされる機器との直接通信に依存する無線アップデート・メカニズムでさえ、特に大規 模な建物においては、最適とは言えない。

Bluetooth Mesh は、デバイスのファームウェアをネットワーク全体からアップデートすることを可能にする一連の手順を定義しており、どのノードに対しても、どの物理的な場所からでもアップデートを開始することができる。

このデバイス・ファームウェア・アップデート（DFU）機能については、次に説明する。

4.20.3 DFU機能

Bluetooth Mesh DFU 機能は、ファームウェア・アップデート・ファイル（多くの場合、バイナリー・イメー ジとして知られる）を、1 回の操作で、1 つまたは複数のターゲット・デバイスのセット に、ネットワークを介してワイヤレスで配布することを可能にする。DFU は、ファームウェアを最新の状態に保つための便利なツールであり、人的リソース、 ネットワーク・リソース、無線リソースを効率的に利用することができる。

4.20.3.1 DFUモデルと役割

Bluetooth Mesh DFU機能には、3組のクライアントとサーバーモデルが含まれる。

• BLOB転送モデルは、ノード間でバイナリラージオブジェクト（BLOB）を転送するための一般化されたメカニズムを提供する。ファームウェア・アップデート・ファイルはBLOBの一例です。
• ファームウェア配布モデルは、アップデートされるノードにファームウェア・アップデート・ ファイルを配布する手順をサポートします。ファームウェア配布手順は、BLOB 転送モデルを使用します。
• ファームウェア・アップデート・モデルは、デバイスのファームウェアにアップデートを適用する手順をサポートしています。

多くのDFUの役割が定義されている：

Role	Description	Models
Target	A node which receives firmware updates. A Target is able to report the version of firmware it is running and the location from which updates can be obtained.	Firmware Update Server BLOB Transfer Server
Initiator	Usually runs on a device that both supports Bluetooth Mesh and has internet connectivity. Examples of such devices include smartphones and gateway devices. Periodically or on request, an Initiator checks manufacturers’ websites for new firmware releases. It then downloads update files and sends them to a Distributor node.	Firmware Distribution Client Firmware Update Client BLOB Transfer Client
Distributor	Receives firmware update files from an Initiator and sends them to Target nodes for installation. Acts as an intermediary for the Initiator which means the Initiator does not need to be in range of the mesh network for the full duration of the distribution and update procedures.	Firmware Distribution Server Firmware Update Client BLOB Transfer Client BLOB Transfer Server
Standalone Updater	A Stand-alone Updater fulfils the role of a combined Initiator and Distributor, acquiring firmware updates and sending them directly to Updating Nodes without the need for an intermediate Distributor.	Firmware Update Client BLOB Transfer Client

 

4.20.3.2 ファームウェア更新プロセス[4]

4.20.3.2.1 ファームウェアアップデートの取得

Mesh DFU モデル仕様は、Firmware Check Over HTTPS手順を定義している。この手順は Initiator（または Standalone Updater）によって呼び出され、通常、以下のことを含む：

1. アプリケーション層からターゲットノードのリストを受け取る
2. リスト上の各ターゲットノードに対して
   1. バージョン番号や、アップデートを取得できる場所のURI（Uniform Resource Identifier）など、現在インストールされているファームウェアに関する情報を取得する。
   2. URIにHTTP GETリクエストを送信し、ファームウェア・アップデートが利用可能であれば、レスポンスでファームウェア記述ファイルをダウンロードする。

ファームウェア記述ファイルは JSON 形式のファイルで、ファームウェア・アップデートが 分割されたファイル数や、アップデートの合計サイズ（バイト）などの情報を提供する。

その後、HTTPS プロトコルを使用してファームウェア・アップデート・ファイルを取得するために、Firmware Retrieval over HTTPS手順が使用される。Initiator がこれを行うことも、Distributor にファームウェアアップデートの取得を指示することもできる。

この仕様では、ファームウェアのアップデートを、ベンダー固有のアプローチでチェックし、 取得することも可能であることに注意されたい。

4.20.3.2.2 ファームウェアアップデートの配布

Initiator は、ファームウェアのアップデートとターゲットノードの詳細を Distributor に送信するために、BLOB Transfer Client Model にバックアップされた Firmware Distribution Client Model を使用する。その後、Distributor は、ファームウェア更新クライアントモデルと BLOB 転送クライアントモデルを使用して、各 Target ノードに更新を送信する。

4.20.3.2.3 ファームウェアのインストール

ターゲットは、ベンダー固有の手順でアップデートを確認し、インストールする。進捗情報は、ディストリビューターが入手できます。

4.20.3.2.4 DFUセキュリティ

リモート・ソースからファームウェアを入手し、それをBluetooth Mesh ネットワークのノードにインス トールすることには、セキュリティ・リスクがある。リモート・ソースが信頼に足るものであり、ファームウェア・アップデート・ ファイルが改ざんされていないことを検証する方法が必要である。

DFU 仕様では、標準的なファームウェア・チェックおよびファームウェア取得 手順の中で、リモート・サーバーからのダウンロードに安全な HTTPS プロトコルの使用を義務付けています。これにより、ダウンロードは暗号化され、機内で検知されずに改ざんされることはありません。HTTPS はまた、リモートサーバーがその身元を認証できるデジタル証明書を持つことを要求します。

HTTPS を介したファームウェア・チェックと HTTPS を介したファームウェア取得の手順は、主要なセキュリ ティ問題に対処している。デバイスが使用するベンダー固有のインストール手順は、さらなるセキュリティ・チェックのための他の機会を提供する。

5.システムアーキテクチャ

5.1 はじめに

このセクションでは、Bluetooth Mesh アーキテクチャ、mesh ネットワーキング・スタックのレイヤー、テクノロジーを定義する技術仕様について詳しく見ていく。

5.2Bluetooth Mesh 仕様

Bluetooth Mesh は仕様の集合体によって定義される。

• Mesh プロトコル仕様は、Bluetooth Mesh テクノロジーのアーキテクチャ、プロトコル、手順、基盤モデル、その他の中核概念を定義している。
• Mesh モデル仕様では、基礎モデルで定義されている以上の機能を提供する追加モデルを定義している。
• デバイスのファームウェア・アップデートと BLOB 転送機能にはそれぞれ専用の仕様があり、それぞれのモデルが定義されている。
• プロファイル仕様のコレクションは、特定のクラスの製品をさらに標準化するための追加要件と実装の詳細を定義し、結果として相互運用性を向上させる。

5.3Bluetooth Mesh スタック

図7は、Bluetooth Mesh のアーキテクチャを、そのレイヤーとBluetooth Core Specificationの一部への依存関係という観点から示している。スタックは2つある。mesh ネットワーキング・スタックは、Bluetooth Mesh ネットワーク内のノード間の通信を可能にする。mesh プロビジョニング・スタックは、デバイスのプロビジョニングを可能にする。

図7 -Bluetooth Mesh アーキテクチャ

図 7 には、Bluetooth Core Specification (LE Physical Transport) とラベル付けされたコンポーネントがある。これは、Bluetooth Mesh によって活用される、Bluetooth LE の中核機能一式を表している。

Bluetooth LE システムはコントローラと ホストで構成される。これらは物理的に別個のコンポーネントであることが多いが、何らかの方法（例：UART）で接続され、ホスト・コントローラー・インターフェイス（HCI）として知られる標準コマンドとイベントのセットを使用して通信する。mesh ネットワーキング・スタックのレイヤーはすべてホスト・コンポーネントに常駐している。mesh ネットワーキング・スタックは、リンク層や物理層など、コントローラ内で動作するBluetooth LE スタックの一部に依存している。これらの層とBluetooth LE の基本アーキテクチャの詳細については、 Bluetooth The Low Energy Primerを参照。

mesh アーキテクチャーの各レイヤーを、一番下のレイヤーから順に見ていこう。

5.4 ベアラ層

Mesh メッセージは、その伝送のために基礎となる通信システムを必要とする。ベアラ層は、mesh PDUが所定の通信システムでどのように処理されるかを定義する。一般的なメッセージング目的で使用される2つの主要ベアラが定義されており、これらは広告ベアラと GATTベアラと呼ばれる。

広告ベアラはmesh PDU を送受信するため、Bluetooth LE 広告及びスキャニング機能を活用する。

GATTベアラは、広告ベアラをサポートしないデバイスが、Proxyプロトコルとして知られるプロトコルを使用して、mesh ネットワークのノードと間接的に通信することを可能にする。Proxyプロトコルは、Mesh Proxy Data InおよびMesh Proxy Data Outという2つのGATT特性を含む、Mesh Proxy Serviceと呼ばれるGATTサービスを含むGATTオペレーション内にカプセル化される。

Proxyノードは、Mesh Proxy Serviceとその特性を実装する。GATTベアラと広告ベアラの両方をサポートしているため、2種類のベアラ上でメッ セージを変換して中継することができる。

GATTベアラは、Proxy機能をサポートしていないノードでもサポートされる場合がある。

5.5 ネットワーク層

ネットワーク層は、トランスポート層のPDUをベアラ層で扱えるようにするために、様々なメッセージアドレスタイプとネットワークメッセージフォーマットを定義する。

複数のベアラをサポートすることができ、各ベアラは、同じノードに属するエレメント間の通信に使用されるローカル・インタフェースを含め、複数のネットワーク・インタフェースを持つことができる。

ネットワーク・レイヤは、どのネットワーク・インタフェースを介してメッセー ジを出力するかを決定する。ベアラ・レイヤから到着したメッセージには入力フィルタが適用され、さらなる処理のためにネッ トワーク・レイヤに配送すべきかどうかが決定される。出力メッセージには出力フィルタが適用され、それらがドロップされるか、ベアラ・レイヤに配信されるかが制御される。

リレー機能とプロキシ機能は、ネットワークレイヤーによって実装されるかもしれない。

5.6 下位トランスポート層

下位トランスポートレイヤーは上位トランスポートレイヤーからPDUを受け取り、対向 デバイス上の下位トランスポートレイヤーに送る。必要に応じて、PDUのセグメンテーションと再アセンブリを実行する。単一のトランスポートPDUに収まらない長いパケットに対しては、下位トランス ポートレイヤーはセグメンテーションを実行し、PDUを複数のトランスポートPDU に分割する。他のデバイス上の受信側下位トランスポートレイヤーは、セグメントを単一 の上位トランスポートレイヤーPDUに再組み立てし、これをスタック上に渡す。

5.7 上位トランスポート層

上位トランスポートレイヤーは、アクセスレイヤーとの間でやり取りされるアプリケーショ ンデータの暗号化、復号化、認証に責任を持つ。また、異なるピアノードの上位トランスポートレイヤー間で内部 的に生成され送信されるトランスポート制御メッセージにも責任を持つ。これには、フレンドシップ、有向転送、ハートビートに関連するメッセージが含まれる。

5.8 アクセス層

アクセスレイヤーは、モデルが上位トランスポートレイヤーをどのように利用す るかを定義する責任を負う。これには以下が含まれる：

• メッセージデータのフォーマットを定義する。
• 上位トランスポート層で実行される暗号化と復号化プロセスを定義し、制御する。
• 上位のトランスポートレイヤーから受信したデータが、正しいネットワークとモデル向けであることを、データをスタック上に転送する前に検証する。

5.9 ファンデーション・モデル層

ファウンデーション・モデル層は、mesh ネットワークのコンフィギュレーションと管理に関係するモデルの実装を担当する。

5.10 モデル層

モデルレイヤーはモデルの実装に関係し、1つ以上のモデル仕様で定義されたビヘイビア、メッセージ、ステート、ステートバインディングの実装を行う。

6.メッセージング

このセクションでは、Bluetooth Mesh ネットワークにおけるメッセージングがどのように機能するかについて説明し、セクション4で説明した主要なコンセプトのいくつかをまとめる。主要な機能と概念

6.1 メッセージの公表と配信

Wi-Fiを使用するネットワークは、アクセスポイントと呼ばれる中央のネットワークノードを中心に構成され、すべてのネットワークトラフィックはアクセスポイントを経由する。ルーターが利用できなくなると、ネットワーク全体が利用できなくなる。

対照的に、Bluetooth Mesh 、電波の届く範囲にいるノードには直接、離れている場合は中継ノードを経由してメッセージを配信する。ノードがパブリッシュすると、メッセージは特定のノードに直接ルーティングされるのではなく、ブロードキャストされます。すべてのノードは、直接無線範囲内にあるノードからのすべてのメッセージを受信します。そのように設定されている場合、ノードは管理されたフラッディングまたは有向転送のいずれかを使用し、受信したメッセージをリレーします。

6.2 マルチパス配信

ブロードキャスト通信と中継を使用することの重要な帰結は、メッセージがネットワークを通る複数の経路を経由して宛先に到着できることである。これは、Bluetooth Mesh が信頼性の高いネットワーク技術であることに貢献している。

6.3 スタックのトラバース

メッセージの受信は、パケットがBluetooth LE コントローラのリンク層で受信されることから始まる[5]。そのペイロードは、次にホストのBluetooth Mesh ベアラ層に渡され、そこからmesh ネットワーク層に渡される。

ネットワーク・レイヤーは、メッセージをより上位のスタックに渡すか、破棄するかを決定するために、様々なチェックを適用する。

さらに、PDUにはNetwork IDフィールドがあり、メッセージがどのNetKeyで暗号化されたかを高速に判断できる。ネットワーク ID が受信ノードのネットワークレイヤーに認識されない場合、対応する NetKey を持っておらず、そのサブネットのメンバー ではないことを示すので、PDU は破棄される。ネットワーク・メッセージ完全性チェック（MIC）フィールドもある。MICチェックに失敗した場合、メッセージは破棄される。

メッセージは発信者の範囲内にあるすべてのノードによって受信されるが、その多くが、そのノードが属するネットワークやサブネットの関係で、そのノードに関係ないことが明らかになると、すぐに破棄される。

同じ原理が、上位のトランスポートレイヤーでも適用される。しかし、ここでは、メッセージに関連付けられ、PDUのアプリケーション識別子(AID)フィールドで識別されるAppKeyに対してチェックが行われる。AIDがこのノードで認識できない場合、PDUは上位トランスポートレイヤーに よって破棄される。トランスポートメッセージ完全性チェック(TransMIC)が失敗した場合、メッセージは破棄される。

上位のトランスポート層はアクセス層にメッセージを渡す。そこから、受信したメッセージのタイプに基づいて適切なモデル関数を呼び出すために、モデルレイヤーが使われる。

6.4 中継

中継の基本概念はセクション4.19「メッセージ中継」で紹介した。有向転送(directed forwarding)メソッドは、管理フラッディング(managed flooding)メソッドよりも複雑なので、このセクションでさらに説明する。

6.4.1 直接転送

6.4.1.1 管理された洪水との比較

管理されたフラッディングが使用される場合、TTLフィールドによって示される最大ホップ数がすでに経過している場合などの限られた状況を除いて、リレーノードは受信したすべてのメッセージを再送する。これはシンプルで効果的なメカニズムであるが、無線スペクトラムの使用に関しては最も効率的とは言えない。メッセージは、宛先ノードのいずれかがリレーノードに対してある方向に位置しているかどうかに関係なく、ネットワークを横切って全方向に伝搬される。

図8と図9は、Bluetooth Mesh ネットワークを備え、ステージ上の照明を制御するスイッチを含む大きな会議場を描いている。メッセージは1ホップで中継されなければならない。

スイッチの範囲内に2つのリレーノードがある。ステージ照明スイッチが使用されると、メッセージが送信され、両方のリレーで受信され、再送信されるため、メッセージはターゲット照明に向かっても、ターゲット照明から遠ざかってもネットワーク内を移動します。 

図8 - 点灯/消灯メッセージを放送する照明スイッチ

図9-2つのリレーがメッセージを受信し、両方が再送信する

これは最適とは言えません。ステージから最も遠いRelayノードは、スイッチからステージ照明へのオン/オフ制御メッセージの配信に貢献できません。

有向転送は管理されたフラッディングとは異なり、中継ノードの状態データが、メッセージによってアドレス指定された1つ以上のノードへのパス上にあることを示す場合にのみ中継が行われる。有向転送を使用できる中継ノードは有向中継ノードと呼ばれる。

図10は、会議ホールの照明スイッチとリレー・ノードが使用した場合の有向転送の効果を示しています。照明スイッチからのオン/オフ・メッセージの伝搬は、ステージ上の照明に向かってのみ行われ、ネットワークの他の部分には伝搬されません。

図10 - 有向転送の効果

パスの概念は、有向転送において正式に定義されたものである。

6.4.1.2 進路と車線

有向フォワーディングは、与えられたソースアドレスから特定のデスティネーションアドレスにメッセージを配送することができる有向リレーノードのシーケンスを定義または発見することを含む。このようなノードシーケンスはパスと呼ばれる。

パスの定義では、送信元アドレスは常にユニキャストアドレスであるが、宛先アドレスはグループアドレスを含め、どのようなタイプでもよい。宛先アドレスが複数のノードに対応する場合、有向転送パスを有向中継ノードのシーケンスの集合として記述する方がより正確である。

ダイレクト・リレー・ノードのフォワーディング・テーブルと呼ばれる状態データ項目は、リレーがサービスできるパスを示す。これは、送信元アドレスと宛先アドレスのペアのリストから構成される。メッセージを受信すると、Directed RelayはForwarding Tableを参照し、その中にメッセージの送信元アドレスと宛先アドレスのエントリがあれば、そのメッセージは中継される。そうでない場合、メッセージは破棄される。

特定のターゲットノードに到達するために、メッセージが中継される有向中継ノードのシーケンスが複数存在する可能性がある。これはマルチレーンパスを作成することで利用できる。レーンはDirected Relayノードのシーケンスであり、その点ではパスと同じです。1つの送信元ノードから1つの宛先ノードへのメッセージ配送に複数の代替ノードシーケンスが利用可能な場合、レーンという用語はシーケンスに使用され、パスという用語はすべてのレーンの集合に使用されます。マルチレーンパスは冗長性が高いため、Directed Relayノードのシーケンスの1つが何らかの理由で使用できない場合でも、メッセージが配送される可能性が高くなるという利点があります。 

6.4.1.3 パスの作成とメンテナンス

パスは、Configuration Managerツールを使って手動で作成されるか、一連の自動化された手順の実行によって動的に発見され、確立される。

自動パス作成が使用されている場合、プロセスはいくつかのステージにわたって実行される。パスが必要な送信元アドレスと宛先アドレスのペアについては、特別なメッセージを使用してネットワークを探索し、送信元から宛先までメッセージを届けることができる中継ノード列を見つけることを目標とします。この過程でパスメトリックと呼ばれる測定値が設定され、代替シーケンス間の比較が行われ、最適なものが選択されます。パスメトリックとは、送信元ノードから所定の中継シーケンスを経由して宛先まで到達するのに要するホップ数を単純にカウントしたものである。より少ないホップで構成されるパスの方が、より多くのホップを必要とするパスよりも優れている。

送信元/宛先アドレスペアのパスとして機能するノードの最短シーケンスが発見されると、そのシーケンス内のノードは、そのパスの一部であることを示すように、制御メッセージを使用して更新される。

7.セキュリティ

7.1Bluetooth Mesh におけるセキュリティは必須である。

Bluetooth LE により、プロファイル設計者は様々なセキュリティ・メカニズムを利用できる。 これには、2 つのデバイスのペアリングが機能する様々な方法、広告パケットにおけるプライベート・デバイス・アドレスの使用、GATT 特性に付随するセキュリティ・ルールが含まれる。しかし、セキュリティは完全にオプションであり、セキュリティ保護や制約のない、完全にオープンなデバイスを持つことも許される。Bluetooth SIG の仕様が適用されない場合（例えば、カスタム・プロファイルやサービスを扱う場 合）、デバイスの設計者や製造者は、脅威を分析し、セキュリティ要件を決定し、それらの要 件を満たすためにBluetooth LE のセキュリティ機能をどのように使用するかを決定する責任を負う。

対照的に、Bluetooth Mesh セキュリティは必須である。ネットワーク、デバイス、個々のアプリケーションはすべてセキュアであり、セキュリティをオフにしたり、低下させたりすることはできない。

7.2 セキュリティの基礎

以下の基本的なセキュリティ声明は、すべてのBluetooth Mesh ネットワークに適用される：

1. mesh メッセージはすべて暗号化され、認証される。
2. ネットワーク・セキュリティー、アプリケーション・セキュリティー、デバイス・セキュリティーは、それぞれ独立に扱われる。後述の「7.3 懸念事項の分離とセキュリティ・キー」を参照のこと。
3. セキュリティ・キーは、キー・リフレッシュ手順と ノード・プロビジョニング・プロトコル・インターフェイス手順を使用して、mesh ネットワークの有効期間中に変更することができる。
4. メッセージの難読化は、ノードの追跡を困難にするプライバシー・メカニズムを提供する。
5. Mesh プライベート・ビーコンは、デバイス追跡に使用される可能性のある静的情報がノードからブロードキャストされないことを保証する。
6. Mesh セキュリティは、リプレイ攻撃からネットワークを保護する。
7. デバイスがmesh ネットワークに追加され、ノードとなるプロビジョニング・プロセスは安全なプロセスであり、X.509デジタル証明書のサポートも含まれている。
8. ゴミ箱攻撃を防ぐ方法で、ノードをネットワークから安全に削除することができる[6]。

7.3 懸念事項の分離とセキュリティ・キー

Bluetooth Mesh セキュリティの中心には、3種類のセキュリティ・キーがある。これらの鍵は、ネットワークのさまざまな側面にセキュ リティを提供する。Bluetooth Mesh セキュリティの設計において、異なるタイプのセキュリティ・キーを使用することは、関心の分離として知られる重要な原則の一例である。

このことを理解し、その重要性を理解するために、中継ノードとして機能するmesh 照明を考えてみよう。リレー・ノードとして機能するライトは、ビルのドアや窓のセキュリティー・システム（Bluetooth Mesh ）に関連するメッセージを処理する。ライトはそのようなメッセージのデータにアクセスして処理できる正当な理由はないが、他のノードにリレーする必要がある。

この潜在的な利益相反に対処するため、Bluetooth Mesh 、ネットワーク層でセキュリティを提供するためのセキュリティ・キーと、照明、物理的セキュリティ、暖房などの特定のアプリケーションに関連するデータを保護するためのセキュリティ・キーとは異なるものを使用している。

mesh ネットワークのすべてのノードは、少なくとも1つのネットワーク・キー（NetKey）を所有している。この共有鍵を所有することで、ノードはネットワークのメンバー 。ネットワーク暗号化キーとプライバシー・キーはNetKeyから直接導き出される。

NetKeyを所有することで、ノードはネットワーク・レイヤまで復号化および認証することができ、中継などのネットワーク機能を実行することができる。アプリケーション・データを復号化することはできない。

特定のアプリケーションのアプリケーション・データは、正しいアプリケーション・キー（AppKey）を所有するノードによってのみ復号化できる。mesh ネットワークのノード全体では、多くの異なる AppKey が存在する可能性がありますが、通常、各 AppKey はノードの小さなサブセット、つまり特定のアプリケーションに参加できるタイプのノードによってのみ所有されます。例えば、照明と照明スイッチは照明アプリケーションのAppKeyを持つが、暖房システムのAppKeyは持たない。

AppKeyは、上位トランスポート・レイヤーがアクセス・レイヤーに渡す前に、メッ セージを復号化し認証するために使用される。

AppKey は 1 つの NetKey にのみ関連付けられます。この関連付けはキーバインディングと呼ばれ、特定のAppKeyを所有することで定義される特定のアプリケーションは、特定の1つのネットワーク上でのみ動作可能であることを意味します。

最後のキー・タイプはデバイス・キー（DevKey）である。これは特殊なアプリケーションキーです。各ノードには、Provisioner デバイスだけが知っている固有の DevKey があります。DevKey は、構成プロセス中の通信を保護するために使用されます。

図11 - セキュリティ・キーBluetooth Mesh

7.4 サブネットとサブネットブリッジ

ネットワークはサブネットに細分化することができる。各サブネットは独自のNetKeyを持ち、そのNetKeyはそのサブネットのメンバーであるノードだけが持つ。これは例えば、ホテルの各客室など、物理的に異なるエリアを隔離し、セキュリティを確保するために使用されます。この場合、特定の客室の照明などのデバイスは、同じ客室で同じサブネット上にある他のデバイスによってのみ制御できるようになります。

異なるサブネットにあるデバイス間の通信が必要な場合があります。ホテルの管理スタッフがホテルの全客室の全デバイスを一元的に制御できる必要がある場合がありますが、同時に、ある客室のデバイスを使用して別の客室のデバイスを制御したり、ある客室のデバイスからの送信を別の客室のデバイスが傍受して復号化したりすることができないようにする必要があります。Bluetooth Mesh 、これを可能にするサブネットブリッジングと呼ばれる機能があります。

サブネットブリッジ機能により、ネットワークプランナーはサブネットを使用してエリアを分離するだけでなく、セキュリティを損なうことなく、隣接する異なるサブネット内の特定のデバイス間の通信を選択的に許可することができます。これには、サブネットブリッジとして機能する1つまたは複数のノードを設定する必要があります。これらのノードは、ブリッジされる各サブネットのネットキーと、ブリッジ・コンフィギュレーション・サーバー・モデルと呼ばれるモデルとその様々なステートを所有するノードです。

サブネットブリッジは、サブネットブリッジと呼ばれるステートによって有効になる。ブリッジング・テーブルと呼ばれるステートには、特定のソース・アドレスと特定のデスティネーション・アドレス間の通信を可能にするエントリが含まれている。さらに、ブリッジング・テーブルのエントリは、最初のサブネットのネットキーと2番目のサブネットのネットキーを示す。

これはブリッジ・テーブルのステート情報であり、1つ目のNetKeyで暗号化された1つのサブネットからのメッセージを、サブネット・ブリッジとして動作するノードが復号化し、2つ目のサブネットのNetKeyで再暗号化することを可能にし、この動作を指定された送信元アドレスと宛先アドレスを持つメッセージに制限する。

7.5 ノードの削除、キーのリフレッシュ、ゴミ箱攻撃

ノードにはさまざまなセキュリティ・キー（mesh ）が入っている。ノードが故障して廃棄する必要が生じた場合、あるいは所有者がそのノードを別の所有者に売却することを決定した場合、そのデバイスとそこに含まれる鍵が、そのノードが持ち出されたネットワークへの攻撃に使用されないことが重要である。

ネットワークからノードを削除する手順が定義されています。Provisioner アプリケーションを使用してノードを拒否リストに追加し、Key Refresh 手順と呼ばれるプロセスを開始します。

キー・リフレッシュの手順により、拒否リストのメンバーを除くネットワーク上のすべてのノードに、新しいネットワーク・キー、アプリケーション・キー、および関連するすべての派生データが発行される。言い換えれば、ネットワーク・セキュリティとアプリケーション・セキュリティの基礎となるセキュリティ・キーのセット全体が置き換えられる。

その結果、ネットワークから削除され、古いNetKeyと古いAppKeyのセットを含むノードは、もはやネットワークのメンバー 、脅威とはならない。

7.6 リプレイ攻撃

リプレイ攻撃とは、盗聴者が1つまたは複数のメッセージを傍受してキャプチャし、後で再送信する技術であり、受信者を騙して攻撃デバイスが許可されていないことを実行させることを目的としている。

7.6.1 IVインデックスとシーケンス番号

Bluetooth Mesh にはリプレイ攻撃に対する保護機能がある。この保護の基本は、シーケンス番号(SEQ)とIVインデックスと呼ばれる2つのデータ項目を使用することである。エレメントはメッセージを発行するたびにSEQ値をインクリメントする。あるエレメントからのメッセージを受信したノードは、最後に有効だったメッセージの SEQ 値以下の SEQ 値を含むメッセージを破棄します。

IVインデックスはネットワーク共有リソースであり、メッセージ受信時にSEQと送信元アドレス値と共にチェックされる。SEQ、IVインデックス、およびSRC（送信元アドレス）フィールドの組み合わせ値は、エレメントが送信するすべてのmesh メッセージで常に一意である。

ネットワークは一度に1つのIVインデックス値を使用する。ただし、IV更新手順が進行している間は、手順が完了しネットワーク全体に新しい値が割り当てられるまで、2つの異なる値が使用される。

7.6.2 IVアップデート手順

シーケンス番号は24ビット長である。SEQフィールドのインクリメントを繰り返すことで、ノードは最終的にシーケンス番号の値を使い果たす可能性がある。このような事態を避けるために、IV更新と呼ばれるネットワーク手順を、このような状況に陥ったノードが開始することができる。これにより、古い値をインクリメントして新しいIVインデックス値が計算され、ネットワーク全体に割り当てられ、影響を受けるノードのエレメントはシーケンス番号をゼロにリセットする。

セキュリティ上の理由から、プライマリサブネットのメンバーであるノードだけがIVアップデート手順を開始することが許可されています。非プライマリサブネットのメンバーであるゲストデバイスのみがIVアップデートを開始することはできません。これにより、この重要な共有ネットワークリソースが保護されます。

7.7 プライバシー

NetKey から派生したプライバシー・キーは、送信元アドレスなどのネットワーク PDU ヘッダー値を難読化するために使用されます。難読化によって、何気ない受動的な盗聴が、デバイスやそれを使用する人々を追跡するために使用できないことが保証されます。また、トラフィック解析に基づく攻撃を困難にします。

Key Refresh手順やIV Update手順を含むBluetooth Mesh 手順の多くは、ビーコンを使用してネットワーク内の他のデバイスにデータをブロードキャストし、その存在と状態を示す。ビーコニングはBluetooth 広告を活用する技術である。

静的で変化しない情報の送信は、ネットワーク上を移動するデバイスを追跡し、デバイス、デバイスのユーザー、そしておそらくネットワーク全体に関する情報を推測することが可能になるため、セキュリティ・リスクを構成する可能性があります。このリスクに対処するため、Bluetooth Mesh には、Mesh プライベート・ビーコンと呼ばれる機能が含まれています。

Mesh プライベート・ビーコン送信には静的な情報は含まれません。その使用により、ビーコン・メッセージに含まれるデータを使用してデバイスが追跡される可能性を排除することで、ネットワーク・プライバシーが向上します。

8.スケーラビリティ

Bluetooth Mesh ネットワーキングの拡張性は実証済みだ。現実の世界では、6,000ものノードが商用展開されている。

Bluetooth Mesh ネットワークの理論上の最大アドレス可能エレメント数は32,767である。これは、エレメントを識別するためのユニキャストアドレスが15ビット長であることによる。つまり、ネットワークが収容できるノードの数でスケーラビリティを考えることは、このトピックを見る上で特に有用な方法ではありません。それよりも、ネットワークがサポートできる作業量、別の言い方をすれば、ネットワーク運用の量と速度という観点から考える方が適切だ。

スケーラビリティとその他のパフォーマンス指標は、ネットワーク・プランナー（10.1 プランナー参照）がネットワークを設計する際に考慮する問題です。ノードの配置と構成は、ネットワークの性能と、将来必要とされる最大のノード数への拡張のしやすさに大きな影響を与えます。

ワイヤレス・ネットワークのスケーラビリティは、共有する無線スペクトラムをいかに効率的に使用するかなど、多くの要因によって制限される傾向がある。衝突は、2つのデバイスが同じ無線チャネルで同時に送信するときに発生し、ネットワークのスケーラビリティを制限する要因になり得る。したがって、衝突によるメッセージ損失の確率を回避または低減することは、Bluetooth Mesh 、ネットワーク・プランナーが行う設計作業における重要な戦略である。

すべてのネットワークが同じとは限らない。ノードの数が比較的少ない小規模なネットワークは、小規模なネットワークのノードが物理的に近くに配置され、ノードが頻繁にメッセージを送信する場合、大規模なネットワークよりもスケーリングが難しくなる可能性があります。つまり、ネットワーク密度やノードの冗長性といった概念が重要なのだ。ネットワークに含まれるノードの絶対数だけではありません。

Bluetooth Mesh は当初からスケーラビリティを念頭に置いて設計された。PDUは小さく（長さは最大29オクテット）、このため送信に使用される通信時間が短くなり、衝突が発生する確率も低くなる。

通常、メッセージのコピーは3つの異なるチャンネルで送信される。これにより、ネットワーク容量が増加し、衝突によるメッセージ損失の確率が減少する。

有向フォワーディング機能の洗練の有無にかかわらず、中継プロセスはメッセージのための複数のパスを確立し、特に混雑したネットワークにおいて、配達の確率を高める。

特に、1つのデバイスが他のデバイスのグループを1回の操作で制御しようとするマルチキャストシナリオ（Bluetooth Mesh ネットワークでは非常に典型的な状況）では、認識されないメッセージによってネットワークトラフィックが削減される。

分散型の設計哲学は、Bluetooth Mesh 。これは、より高いレベルのスケーラビリティをサポートし、他の同等の技術とも差別化される。例えば、センサーは中間的な照明コントローラーを必要とせず、照明と直接通信する。

Bluetooth SIG ウェブサイトには、Bluetooth Mesh ネットワークにおけるスケーラビリティというテーマについて、より深く掘り下げた記事が掲載されている。

9.Bluetooth ネットワーク照明制御（NLC）

Bluetooth Mesh が設計された主な用途の一つは、大規模ビルにおけるネットワーク化された照明機器の制御である。

ライト（正式には照明器具と呼ばれることもある）は複雑で、独立して制御可能な複数のランプを備え、明るさと色の制御をサポートし、人間が操作するスイッチによる手動制御と、遠隔のワイヤレスセンサーによる環境測定制御の両方が可能である。

Bluetooth Mesh モデル仕様は、照明のようなデバイスが、スイッチのオン・オフといったネットワーク上の特定の機能を得るために実装する、標準化された機能ブロックを定義しています。モデルのモジュール化された性質は、革新的な多機能製品の作成をサポートします。個々のモデルは洗練されていることが多く、状態や動作を制御するために多数のパラメータが用意されています。このことが、ネットワーク照明制御技術としてのBluetooth Mesh の柔軟性と汎用性をさらに高めています。

Bluetooth Mesh のさまざまな重要な側面はオプションである。これには、サポートされるベアラのリスト、デバイスをプロビジョニングする方法、サポートされるノード機能（すなわち、プロキシ、リレー、LPN、およびフレンド）などが含まれる。Bluetooth Mesh の各仕様には、しばしば依存関係があります。

Bluetooth Mesh テクノロジーの柔軟な性質は、かなりの利点である。しかしこれは、標準化によって異なるメーカーの製品間の相互運用性を達成するという目標とのバランスを取る必要がある。技術が構成可能で可変的であればあるほど、相互運用性を保護することは時として難しくなる。このため、Bluetooth Mesh NLCデバイス・プロファイル仕様のシリーズでは、さまざまなタイプのデバイスについて、標準的なコンフィギュレーションやその他のアプリケーション層の要件および推奨事項を定義しています。関連するプロファイルに準拠することで、同じプロファイルを実装する他の製品との相互運用が可能になります。

以下の製品タイプのNLCプロファイル仕様が定義されている。

• 環境光センサー NLCプロファイル
• ベーシック・ライトネス・コントローラー NLCプロファイル
• ベーシックシーンセレクター NLCプロファイル
• 調光制御 NLCプロファイル
• エネルギーモニターNLCプロフィール
• NLCプロファイル

物理層からアプリケーション層まで、デバイスの全レイヤーを定義するBluetooth Mesh は、無線照明制御のための初のフルスタック規格である。

10.Bluetooth Mesh ステークホルダー

主な利害関係者とその役割について理解することは、Bluetooth Mesh ネットワークがどのように計画され、作られ、維持され、管理されているかについての理解を深めるのに役立つ。このセクションでは、標準的な役割をいくつか挙げ、説明する。

10.1 プランナー

プランナーには、作成されるネットワークの定義に関係する、広範な一連の責任がある。これらの責任を3つのサブカテゴリーに分類して考えることは有益である：

• 物理的計画
• 機能計画
• ネットワーク計画

同じ人がすべてのサブカテゴリーを担当することもあれば、スペシャリストに分散させることもある。

物理的計画とは、建物内の機器の物理的配置を定義することである。建築家、インテリアデザイナー、工業デザイナーは、一般的に物理的なプランニングを担当する。

機能計画は、デバイスの機能特性とネットワーク内の他のデバイスとの機能的関係を定義することに関係する。機能計画は物理計画に影響を与えるかもしれない。

ネットワーク・プランニングは、必要な機能性と信頼性が達成されるように、デバイスの必要な構成を決定することに関係する。例えば、どのデバイスをフレンドノード、低電力ノード、リレーノード、プロキシノードとして機能させるかを決定するのはこの役割です。ネットワークプランナーは物理的なプランニングに影響を与えます。

10.2 インストーラー

インストーラーは、建物内に機器を物理的に設置する。通常、穴を開けたり、はしごに登ったり、ドライバーを使ったり、電源を接続したりする。

10.3 委員

プランナーによって作成された設計に従って、インストーラーによってデバイスが物理的に設置された後、この役割はデバイスをプロビジョニングすることによって、新しいBluetooth Mesh ネットワークの一部にする。プロビジョニング後、コミッショナーは各新規ノードが機能およびネットワーク計画作業によって指定された機能と構成を持つように設定する。通常、プロビジョニングとコンフィギュレーションは同時に、同じツール（多くの場合、スマートフォンのアプリケーション）を使って実行される。

10.4 ビル・メンテナンスの役割

ビルメンテナンスの役割は、プランナー、インストーラー、コミッショナーの役割の側面を含むが、新しいネットワークを構築するのではなく、ビル内の既存のネットワークに責任を持つ、もう1つの幅広い役割である。ビルメンテナンス担当が行うタスクの例としては、デバイスの交換（インストール、プロビジョニング、コンフィギュレーションが必要）、問題の診断と解決、不要になったデバイスの安全な廃棄などがある。

10.5 ビル所有者

ビルのオーナーはビルを所有し、ネットワークが要求通りに機能し、安全で、期待される投資収益率（ROI）を実現することを懸念している。

11.結論

本稿では、Bluetooth Mesh 、その主な機能、概念、用語について紹介した。Bluetooth だが、我々が知っているようなものではない。Bluetooth 、新しいトポロジーを使ってデバイスが通信する新しい方法をサポートする技術である。

そして何よりも、Bluetooth 、この最も広範な低消費電力ワイヤレス技術を、まったく新しいユースケースや産業分野に完璧に適合させている。

12.追加リソース

本セクションでは、様々な観点からBluetooth LE に関する学習を支援するその他のリソースを掲載する。

Resource	Description	Location
Bluetooth Mesh Protocol Specification	This specification defines the Bluetooth Mesh architecture and its protocols and procedures.	https://www.bluetooth.com/specifications/specs/mesh-protocol/
Mesh Models	Defines the full set of standard Bluetooth Mesh models.	https://www.bluetooth.com/specifications/specs/mesh-model-1-1/
Bluetooth Core Specification	Defines all layers of the Bluetooth stack and associated protocols and procedures. Covers both Bluetooth LE and Bluetooth BR/EDR.	https://www.bluetooth.com/specifications/specs/
Profile and service specifications	A service specification defines a single GATT service along with the characteristics and descriptors that it contains. The behaviors to be exhibited by the GATT server device hosting the service in response to various conditions and state data values are defined in the service specification.   Profile specifications define the roles that related devices assume and in particular, define the behavior of the client device and the data on the connected server that it should work with.	https://www.bluetooth.com/specifications/specs/
The Bluetooth Low Energy Primer	The Bluetooth Low Energy (LE) Primer explains every layer of the Bluetooth LE stack, starting with the physical layer at the bottom and ending with the generic access profile at the top. Topics related to the layered architecture of the stack, such as security, are covered too. This is the place to start if you’re new to Bluetooth LE and want to learn about the technology from a technical perspective.	https://www.bluetooth.com/bluetooth-resources/the-bluetooth-low-energy-primer/
Bluetooth Mesh 1.1 – Feature Summary	Version 1.1 of the Bluetooth Mesh protocol specification introduced several substantial new features. This paper summarizes the changes at a high level and provides links to papers that provide greater detail on each of the new features.	https://www.bluetooth.com/mesh-feature-enhancements-summary/
Study Guide – An Introduction to Bluetooth Low Energy Development	An educational resource for developers wishing to learn about software development for connection-oriented scenarios involving smartphones and peripheral devices. Includes a series of hands-on projects with solutions.	https://www.bluetooth.com/bluetooth-resources/bluetooth-le-developer-starter-kit/
Study Guide – An Introduction to Bluetooth Mesh Software Development	An educational resource for developers wishing to learn about Bluetooth Mesh and about the implementation of mesh models in microcontrollers. Includes a series of hands-on projects with solutions.	https://www.bluetooth.com/bluetooth-resources/bluetooth-mesh-developer-study-guide/
Study Guide – An Introduction to the Bluetooth Mesh Proxy Function	An educational resource for developers wishing to learn how to create GUI applications for devices such as smartphones which allow interaction with nodes in a Bluetooth Mesh network. Includes a series of hands-on projects with solutions.	https://www.bluetooth.com/bluetooth-resources/bluetooth-mesh-proxy-kit/
Paper – Bluetooth Mesh Networking – An Introduction for Developers	An educational resource for anyone interested in learning about the key concepts and capabilities of Bluetooth Mesh.	https://www.bluetooth.com/bluetooth-resources/bluetooth-mesh-networking-an-introduction-for-developers/
Paper – Bluetooth Mesh Models – A Technical Overview	An educational resource for anyone interested in better understanding the standard models available for use in Bluetooth Mesh products.	https://www.bluetooth.com/bluetooth-resources/bluetooth-mesh-models/
Study Guide – Understanding  Bluetooth LE Security	An educational resource which explains and illustrates all aspects of security in Bluetooth LE (excluding Bluetooth Mesh). Suitable for both complete beginners to the subject of security and those with prior experience. Includes a series of hands-on projects with solutions.	https://www.bluetooth.com/bluetooth-resources/le-security-study-guide/
Paper – Bluetooth Security and Privacy Best Practices Guide	A guide which is intended to help implementers better understand why certain available security and privacy choices are better or worse than others for specific applications, and what risks and pitfalls remain in the specifications.	https://www.bluetooth.com/bluetooth-resources/bluetooth-security-and-privacy-best-practices-guide/
Article – Scalability in Bluetooth Mesh networks	A blog post which examines the question of scalability, offers a definition and explores the factors that govern the issue in larger networks.	https://www.bluetooth.com/blog/mesh-in-large-scale-networks/

[1]無線伝送レートを議論する場合、ビットではなく、1秒あたりのシンボルを使うのが一般的である。しかし、Bluetooth 、デジタル・ビットとアナログ・シンボルの間には1対1の対応がある。

[2] Bluetooth の仕様はセクション5で紹介する。システム・アーキテクチャ

[Bluetooth LE入門』は、LE全般の入門書として読むことを薦める。

[4]Standalone Updater の役割は、このセクションの Initiator や Distributor への言及に置き換えることができる。

[5]6.3Bluetooth Mesh スタック参照

[ゴミ箱攻撃は、廃棄されたデバイスを回収し、そのデバイスに含まれるセキュ リティ・キーを回収し、悪意を持って使用するものである。