3.3.2 LE 物理チャネル

LE コアシステムでは、2 つの Bluetooth デバイスは、通信のために共有の物理チャネルを使用します。 これを達成するために、それらのトランシーバは、同時に同じ PHY 周波数にチューニングされ、互いに公称範囲内にある必要がある。 PHY チャネルの数が限られており、多くの Bluetooth デバイスが同じ空間的・時間的領域内で独立して動作することを考えると、独立した Bluetooth デバイスの 2 つのペアのトランシーバが同じ PHY チャネルにチューニングされていると、衝突が発生する可能性が高い。 アクセスコードがピコネットを識別するために使用される BR/EDR とは異なり、LE は、デバイス間の物理的なチャネルを識別するためにランダムに生成されたアクセスアドレスを使用します。 2 つのデバイスが同じエリア内で同じ PHY チャネルを共有している場合、通信がどのデバイスに向けられているかを決定するための相関器として、ターゲットデバイスのアクセスアドレスが使用されます。 3 つの LE 物理チャネルが定義されています。 それぞれが最適化され、異なる目的のために使用されます。 LE piconet 物理チャネルは、接続されたデバイス間の通信に使用され、特定の piconet に関連付けられます。 LE 広告物理チャネルは、LE デバイスに広告を放送するために使用される。 これらの広告は、スキャナまたはイニシエータ・デバイスへのユーザ・データの発見、接続、または送信に使用することができる。 周期的物理チャネルは、指定された間隔で周期的広告でスキャナ・デバイスにユーザ・データを送信するために使用される。 LEデバイスは、任意の時間にこれらのLE物理チャネルのうちの1つだけを使用することができる。 複数の同時動作をサポートするために、デバイスはチャネル間で時分割多重化を使用します。 このようにして、Bluetooth デバイスは、広告放送を同時に送信しながら、接続されたデバイスをサポートして いるように見せることができます。 LEデバイスが物理チャネルのタイミング及び周波数に同期しているときはいつでも、それはこのチャネルに接続されているか、または同期していると言われる（チャネル上の通信に積極的に関与しているかどうかに関わらず）。 Bluetooth 仕様は、デバイスが一度に 1 つの物理チャネルにのみ接続できることを前提としている。 高度なデバイスは、複数の物理チャネルに同時に接続または同期することが可能な場合がありますが、仕様ではこのような仮定はしていません。 LE piconet 物理チャネルと LE 広告ブロードキャストチャネルの両方のパケットには、方向探知の目的で使用できる Constant Tone Extension を含めることができる。

3.3.2.1 LE piconet 物理チャネル

3.3.2.1.1 概要

LE piconet 物理チャネルは、通常の動作中に接続された LE デバイス間の通信に使用される。

3.3.2.1.2 特性

LE piconet 物理チャネルは、PHY チャネルの擬似ランダムなシーケンスと、マスターによって提供される 3 つの追加パラメータによって特徴付けられる。 1 つ目は、ピコネットで使用される PHY チャンネルのセットを示すチャンネルマップである。 2 番目は、PHY チャンネルの完全なセットへのインデックスとして使用される疑似乱数である。 3 番目は、接続要求後にマスタから送信される最初のデータパケットのタイミングである。 チャネルは接続イベントに分割され、各接続イベントは PHY ホップチャネルに対応する。 連続した接続イベントは異なる PHY ホップチャネルに対応する。 接続確立後にマスタが送信する最初のパケットは、今後の接続イベントのタイミングのアンカーポイントを設定する。 接続イベントでは、マスターはパイコネット内のスレーブにパケットを送信し、スレーブはそれ自身のパケットで応答することができます。 LE piconet 物理チャネルでは、マスターはチャネルへのアクセスを制御します。 マスタは、一定の間隔で発生する接続イベントで送信を開始します。 マスタによって送信されるパケットは、接続イベントの開始に合わせて整列され、ピコネットのタイミングを定義します。 各マスタの送信には、論理トランスポートの1つの情報を運ぶパケットが含まれています。 スレーブデバイスは、それに応答して物理チャネルで送信することができます。 LE piconet 物理チャネルは、干渉を避けるために使用される PHY チャネルのセットを変更することができるという点で、BR/EDR 準拠の piconet チャネルに似ています。 チャンネルマップで使用されるチャンネルのセットは、接続セットアップ中にマスターによって確立されます。 接続中、マスターは、新しい干渉を避けるために必要なときにチャネルマップを変更することができます。 LE piconet チャンネルは 37 個あります。 マスターは、使用されているチャンネルを示すチャンネルマップを介して、この数を減らすことができます。 ホッピングパターンが未使用チャネルにヒットした場合、未使用チャネルは使用チャネルのセットから代替チャネルに置き換えられます。 LE Piconet 物理チャネルは、任意の LE PHY を使用することができる。

3.3.2.1.3 トポロジー

LE piconet 物理チャネルは、任意の数の LE デバイスで共有することができ、piconet マスター・デバイスで利用可能なリソースによってのみ制限されます。 1 つのデバイスのみが piconet マスターとなり、他のデバイスはすべて piconet スレーブとなります。 すべての通信は、マスターデバイスとスレーブデバイスの間で行われます。 piconet チャネル上のスレーブデバイス間の直接通信はありません。 ピコネット内でサポートできる論理トランスポートの数には実質的に制限がありません。 これは、マスターとチャネルを共有する Bluetooth デバイスの数に理論的な制限がないことを意味します。 LE デバイスは、一度に 1 つ以上のピコネットに属することが許可されている。 つまり、LE デバイスは、0 つ以上のピコネットのスレーブであることも、別のピコネットのマスターであることもあり得る。 2 つの LE デバイス・アイデンティティー又は解決不可能なプライベート・アドレスの間には、1 つの LE ピコネット物理チャネルのみが存在することができる。

3.3.2.1.4 サポートされているレイヤー

LE piconet 物理チャネルは、汎用通信に使用される L2CAP チャネルをサポートします。

3.3.2.2 広告物理チャネル

3.3.2.2.1 概要

LE 広告物理チャネルは、2 つのデバイス間の接続を設定したり、接続されていないデバイス間で放送情報を通信するために使用される。

3.3.2.2.2 特性

LE 広告物理チャネルには、プライマリー広告物理チャネルとセカンダリー広告物理チャネルという 2 つの LE 広告物理チャネルがある。 一次広告物理チャネルは、LE 周波数スペクトルに均等に広がる 3 つの固定 PHY チャネルのセットである。 一次広告物理チャネルの数は、干渉を低減するために、広告装置によって減少させることができる。 プライマリ広告物理チャネルは、LE 1MまたはLE Coded PHYのいずれかを使用することができる。 一次広告物理チャネルは、各広告イベントがすべての一次広告ＰＨＹチャネル上でホップすることができる広告イベントに分割される。 広告イベントは、干渉回避を助けるためにランダムな遅延でわずかに変更された一定の間隔で発生します。 プライマリ広告物理チャネル上では、広告デバイスは物理チャネルへのアクセスを制御する。 広告デバイスは、広告イベントで送信を開始し、1 つ以上のプライマリ広告 PHY チャネル上で広告パケットを送信する。 各広告パケットは、一定の間隔で異なる広告ＰＨＹチャネル上で送信される。 広告イベントの７つのタイプを使用することができ、各広告イベントタイプは、異なるサイズの広告パケットを有する。 これらの広告パケットのＰＤＵペイロードは、６オクテットから３７オクテットまでの長さで変化することができる。 広告デバイスによって送信されるいくつかの広告イベントは、リスニングデバイスが、広告パケットが受信されたのと同じ広告ＰＨＹチャネル上でスキャン要求または接続要求パケットを同時に送信することを可能にする。 広告デバイスは、同じ広告イベント内の同じ広告ＰＨＹチャネル上で再度スキャン応答パケットを送信することができる。 スキャン応答パケットのペイロードは、６オクテットから３７オクテットまでの長さで変化することができる。 第２の広告物理チャネルは、ＬＥ周波数スペクトルを横切って広がる３７個の固定ＰＨＹチャネルのセットである。 これらは、データ物理チャネルによって使用されるのと同じ固定LE PHYチャネルである。 セカンダリ広告物理チャネルは、データ物理チャネルと同じチャネルインデックスを使用します。 セカンダリ広告物理チャネルで使用される広告パケットのペイロードは、0 オクテットから 255 オクテットまでの長さで変化させることができます。 セカンダリ広告物理チャネル上の広告パケットは、広告イベントの一部ではなく、拡張広告イベントの一部である。 これらの拡張広告イベントは、プライマリ広告物理チャネル上の広告イベントと同時に開始し、セカンダリ広告物理チャネル上の最後のパケットで終了します。 セカンダリ広告物理チャネルは、そうでなければプライマリ広告物理チャネルで送信されるであろうデータをオフロードするために使用されます。 セカンダリ広告物理チャネル上の広告パケット（「補助パケット」）は、十分な無線時間が利用可能な場合に、広告主によってスケジュールされます。 プライマリ広告物理チャネル上の広告パケットは、PHYチャネルと、補助パケットの開始時刻に対するオフセットを含む。 セカンダリ広告物理チャネルは、任意のLE PHYを使用することができる。 同じ拡張広告イベント内のセカンダリ広告物理チャネル上のすべての広告パケットは、プライマリ広告物理チャネル上の広告パケットで指定された同じ PHY を使用します。

3.3.2.2.3 トポロジー

LE 広告物理チャネルは、任意の数の LE デバイスで共有することができます。 任意の数のLEデバイスは、広告物理チャネルを共有しながら広告パケットを送信することができます。 任意の数の走査デバイスは、広告物理チャネル上でリッスンすることができる。 広告デバイスは、広告を掲載し、同時に LE ピコネット物理チャネル上に接続することができる。 また、スキャニングデバイスは、１つ以上のLEピコネット物理チャネルに同時に接続されてもよい。

3.3.2.3 周期的な物理チャネル

3.3.2.3.1 概要

LE 周期的物理チャネルは、未接続機器間の周期的ブロードキャストを設定するために使用されます。

3.3.2.3.2 特性

周期的な物理チャネルは、ＰＨＹチャネルの擬似ランダムなシーケンスと、広告主によって提供される追加のパラメータとによって特徴付けられる。 これらは、周期的ブロードキャストで使用されるＰＨＹチャネルのセットを示すチャネルマップ、チャネルホッピングシーケンスを決定するために使用されるイベントカウンタ、最初の周期的ブロードキャストパケットのタイミングを示すオフセット、および連続する周期的ブロードキャスト間の間隔である。 チャネルは、周期的広告イベントの開始がＰＨＹホップチャネルに対応する周期的広告イベントに分割される。 連続する周期的広告イベントの開始は、異なるＰＨＹホップチャネルに対応する。 放送が確立された後に広告主によって送信される最初のパケットは、将来のすべての周期的な広告イベントのタイミングのためのアンカーポイントを設定する。 周期的な物理チャネルでは、広告装置は、物理チャネルへのアクセスを制御する。 広告主は、一定の間隔で発生する周期的な広告イベントでその送信を開始する。 広告主によって送信されるパケットは、周期的広告イベントと指定されたブロードキャストタイミングに整列される。 広告主によって送信されるパケットのペイロードは、0オクテットから255オクテットまでの長さで変化する可能性があります。 各広告主送信には、PADVB論理トランスポート上の情報を運ぶパケットが含まれています。 スキャナは物理チャネルで送信できません。 37 個の PHY チャネルがあります。 広告主は、使用チャネルを示すチャネルマップを介してこの数を減らすことができます。 ホッピングパターンが未使用チャネルにヒットした場合、未使用チャネルは使用チャネルのセットから代替チャネルに置き換えられる。 周期的な物理チャネルは、任意のＰＨＹを使用することができる。 全ての周期的な広告イベントは、周期的な物理チャネルの特性を記述したパケットの中で、広告主が使用するのと同じ PHY を使用する。

3.3.2.3.3 トポロジー

LE 周期的物理チャネルは、任意の数の LE デバイスによって共有することができる。 任意の数のLEデバイスは、同じ周期的物理PHYチャネルを共有しながら、周期的広告パケットを送信することができる。 任意の数の走査デバイスは、周期的物理チャネル上でリッスンすることができる。 広告デバイスは、広告を出し、同時にLEの周期的物理チャネル上で同期することができる。 走査デバイスはまた、１つ以上のLE周期的物理チャネルに同時に同期されてもよい。

---

中略

3.4.3 LE 物理チャネルがサポートする LE リンク

LE piconet 物理チャネルは、LE アクティブ物理リンクをサポートします。 物理リンクは、マスターとスレーブ間のポイント・ツー・ポイント・リンクです。 スレーブがマスタと接続しているときは、常に存在します。 LE 広告物理チャネルは、LE 広告物理リンクをサポートします。 物理リンクは、広告主デバイスと 1 つ以上のスキャナまたはイニシエータデバイスとの間のブロードキャストです。 広告主が広告イベントをブロードキャストしているときは、常に存在する。 LE 周期的物理チャネルは、LE 周期的物理リンクをサポートする。 物理リンクは、広告主デバイスと1つ以上のスキャナデバイスとの間のブロードキャストである。 広告主が定期的な広告イベントを放送しているときは、常に存在する。

3.4.3.1 アクティブな物理リンク

マスターとスレーブ・デバイス間の物理リンクは、デフォルトのLE ACL論理トランスポートがデバイス間に存在する場合、アクティブになります。 アクティブな物理リンクは、それぞれ個別のピコネット物理チャネルに関連付けられており、リンク・レイヤー・パケットで使用されるランダムに生成されたアクセス・アドレスによって識別されます。 各アクセス・アドレスは、アクティブな物理リンクのマスターおよびスレーブと1対1の関係を持っています。

3.4.3.2 物理リンクの広告

接続を形成する目的のための広告装置と開始装置との間の広告物理リンク（アクティブ物理リンク）は、比較的短い期間存在することができる。 これらの広告物理リンクは、いかなる方法でも制御または変更することができず、これらのタイプの物理リンクは、さらに精緻化されない。 広告装置とユーザデータの定期的な放送に使用される走査装置との間の広告物理リンクは、より長い期間存在することができる。 プロトコル内には、物理リンクに関する識別情報は存在しない。 広告装置と走査装置の関係は、Bluetooth装置のアドレスを使用して確立されなければならない。

3.4.3.3 周期的な物理リンク

広告装置と１つ以上の走査装置との間の周期的な物理リンクは、通常、長期間にわたって存在する。 周期的な物理リンクは、それぞれ別個の周期的な物理チャネルに関連付けられており、そのチャネルは、リンクレイヤパケットで使用されるランダムに生成されたアクセスアドレスによって識別される。 各アクセスアドレスは、周期的物理リンクの広告主と１対１の関係を有する。

---

中略

3.5.4.6 LE 非同期接続（LE ACL

LE 非同期接続（LE ACL）論理トランスポートは、LL および L2CAP 制御シグナリングとベストエフォート非同期ユーザーデータを伝送するために使用されます。 LE ACL 論理トランスポートは、1 ビット NESN/SN スキームを使用して、シンプルなチャネル信頼性を提供します。 LE ピコネット内のすべてのアクティブなスレーブ・デバイスは、デフォルト LE ACL として知られているピコネット・マスターへの LE ACL 論理トランスポートを 1 つ持っています。

デフォルト LE ACL は、デバイスがピコネットに参加する（LE ピコネット物理チャネルに接続する）と、マスターとスレーブの間で自動的に作成されます。

このデフォルト LE ACL は、piconet マスターによってアクセス・アドレスが割り当てられます。 このアクセス・アドレスは、必要に応じてアクティブな物理リンクとアクティブなピコネット物理チャネルを識別するためにも使用されます。

デフォルト LE ACL が LE アクティブ物理リンクから削除された場合、マスターとスレーブの間に存在する他のすべての LE 論理トランスポートも削除されます。 LE ピコネット物理チャネルへの予期せぬ同期の喪失の場合、LE 物理リンクおよびすべての LE 論理トランスポートと LE 論理リンクは、この同期の喪失が検出された時点で存在しなくなる。

---

中略

3.5.5.2 LE 論理リンク

LE論理トランスポート内では、論理リンクは、データペイロードを運ぶベースバンドパケットのペイロード ヘッダー内の論理リンク識別子(LLID)ビットによって識別される。 論理リンクは、論理トランスポート上でデータを送受信できるコアプロトコルの限定されたセットを区別する。 すべての論理トランスポートがすべての論理リンクを運ぶことができるわけではありません(サポートされているマッピングを図3.2に示します)。

3.5.5.2.1 制御論理リンク(LE-C)

LE ACL 制御論理リンク（LE-C）は、ピコネット内のデバイス間で LE LL 信号を伝送するために使用されます。 制御リンクは、デフォルトのLE ACL論理トランスポート上でのみ伝送される。

3.5.5.2.2 ユーザー非同期論理リンク（LE-U

ユーザー非同期論理リンク（LE-U）は、すべての非同期およびフレーム化されたユーザー・データを運ぶために使用されます。 LE-U リンクは LE 論理トランスポートで運ばれます。 LE-U リンク上のパケットは、2 つの予約された LLID 値のうちの 1 つによって識別されます。 1つの値は、ベースバンド・パケットにL2CAPフレームの開始が含まれているかどうかを示すために使用され、もう1つの値は、前のフレームの継続または空のPDUを示します。 これにより、L2CAP再アセンブラの正しい同期が保証されます。 この手法を使用することで、すべてのベースバンドパケットでより複雑な L2CAP ヘッダーを使用する必要はなくなりますが、新しい L2CAP フレームを送信する前に、完全な L2CAP フレームを送信するという要件が追加されます。

3.5.5.2.3 アドバタイジング・ブロードキャスト制御論理リンク（ADVB-C

LE広告ブロードキャスト制御論理リンク（ADVB-C）は、所定のエリア内の未接続デバイス間でLE LLシグナリングを伝送するために使用される。 このシグナリングは、追加のブロードキャスト・ユーザ・データ（スキャン要求）または接続要求を収集するための制御コマンドである。 制御リンクは、LE Advertising Broadcast および LE Periodic Advertising Broadcast 論理トランスポート上で伝送される。

3.5.5.2.4 Advertising Broadcast User Data 論理リンク（ADVB-U

LE Advertising Broadcast User Data Logical Link（ADVB-U）は、機器間の接続やLE-Uを必要とせずに、機器間で使用されるLE Advertising BroadcastとLE Periodic Advertising Broadcastのユーザーデータを運ぶために使用されます。 ユーザーデータリンクは、LE Advertising Broadcastユーザーデータ用のLE Advertising Broadcast論理トランスポートと、LE Periodic Advertising Broadcastユーザーデータ用のLE Periodic Advertising Broadcast論理トランスポートで搬送されます。

3.5.5.3 AMP論理リンク

3.5.5.3.1 AMP 制御論理リンク（AMP-C

各 PAL は、制御論理リンクの機能が異なります。 制御論理リンクが存在する場合、この論理リンクを AMP-C 論理リンクと呼びます。

3.5.5.3.2 AMP ユーザー非同期/等時性論理リンク（AMP-U

AMP ユーザー非同期/等時性論理リンク (AMP-U) は、すべての非同期および等時性フレーム化されたユーザーデータを AMP 上に伝送するために使用されます。 ACL-U 論理リンクとは異なり、AMP-U は物理リンクごとに複数の論理リンクハンドルをサポー トし、各論理リンクハンドルは異なるサービス品質機能を持つ場合があります。 AMP-U 論理リンクがどのように基礎となる MAC/PHY にマッピングされるかの詳細は、PAL で説明されています。

3.6 L2CAPチャンネル

L2CAP は、多くの異なるアプリケーションが ACL-U、ASB-U、LE-U、または AMP-U 論理リンクを共有できるように、多重化の役割を提供します。 アプリケーションおよびサービス プロトコルは、チャネル指向のインタフェースを使用して L2CAP とインタフェースし、他のデバイス上の同等のエンティティへの接続を作成します。 L2CAP チャネル エンドポイントは、チャネル識別子（CID）によってクライアントに識別されます。 これは、L2CAPによって割り当てられ、任意のデバイス上の各L2CAPチャネル エンドポイントは、異なるCIDを持っています。 L2CAP チャネルは、アプリケーションに適切な QoS (Quality of Service) を提供するように設定することができます。 L2CAP は、チャネルを ACL-U、ASB-U、LE-U、または AMP-U 論理リンクのいずれかにマッピングします。 L2CAP は、接続指向のチャネルとグループ指向のチャネルをサポートしています。 グループ指向のチャネルは、ASB-U 論理リンクにマップするか、ACL-U 論理リンク上で各メンバーへの反復送信として実装することができます。 チャンネルの作成、構成、および解体とは別に、L2CAP の主な役割は、チャンネル クライアントから ACL-U、ASB-U、LE-U、または AMP-U 論理リンクにサービス データ ユニット（SDU）を多重化し、単純なレベルのスケジューリングを実行して、相対的な優先度に従って SDU を選択することです。 L2CAP は、ピア L2CAP レイヤとのチャネルごとのフロー制御を提供することができます（ASB-U 論理リンクを除く）。 このオプションは、チャネルの確立時にアプリケーションによって選択されます。 L2CAP は、(a) 未検出のエラーがアプリケーションに渡される確率を減らし、(b) ベースバンド層が ACL-U 論理リンク上でフラッシュを実行したときに、ユーザー データの一部の損失から回復するために、強化されたエラー検出と再送を提供することもできます。 HCIが存在する場合、L2CAPは、L2CAP SDUをベースバンド バッファに収まるフラグメントにセグメント化し、HCI上でトークン ベースのフロー制御手順を動作させ、許可された場合にのみフラグメントをベースバンドに送信することも要求されます。 これは、スケジューリングアルゴリズムに影響を与える可能性があります。

4.1.2 LE topology

図 4.2 では、以下に説明する LE アーキテクチャ機能の多くを示すトポロジーの例を示している。 デバイス A は、デバイス B と C をスレーブとして持つピコネット（斜線部分で表され、ピコネット A として知られている）のマスターである。 BR/EDR スレーブとは異なり、LE スレーブはマスターと共通の物理チャネルを共有しません。 各スレーブは、マスタとは別の物理チャネルで通信します。 他の１つのピコネットは、デバイスＦをマスタとして（ピコネットＦとして知られている）、デバイスＧをスレーブとして示している。 デバイスＫは、スキャッタネット（スキャッタネットＫとして知られている）にある。 デバイスＫはデバイスＬのマスタであり、デバイスＭのスレーブであり、デバイスＯもスキャッタネット（スキャッタネットＯとして知られている）にある。 図では、実線の矢印はマスターからスレーブを指し、接続開始を示す破線の矢印は、接続可能な広告イベントを使用してイニシエータから広告主を指し、広告を行っているデバイスは星を使用して示されている。 示されているデバイスの他の5つのグループがあります。

1. デバイス D は広告主であり、デバイス A もイニシエータです（グループ D として知られています）。
2. デバイスEはスキャナであり、デバイスCも広告主です（グループCとして知られています）。
3. デバイスHは広告主であり、デバイスIとJはスキャナである（グループHとして知られている）。
4. デバイスKも広告主であり、デバイスNはイニシエータです（グループKと呼ばれています）。
5. デバイスRは広告主であり、デバイスOもイニシエータです（グループRとして知られています）。

デバイス A と B は、1 つの LE ピコネット物理チャネルを使用しています（青色の筐体と濃い灰色の背景で表されます）。 デバイス A と C は、別の LE ピコネット物理チャネルを使用しています（青色の筐体と明るいグレーの背景で表されます）。 グループＤでは、デバイスＤは、広告物理チャネル（緑色のエンクロージャで表され、緑色のエンクロージャで表される）上の接続可能な広告イベントを使用して広告を行っており、デバイスＡはイニシエータである。 デバイスＡは、デバイスＤとの接続を形成し、デバイスをピコネットＡに追加することができ、グループＣでは、デバイスＣもまた、デバイスＥがスキャナとして取り込んでいる任意のタイプの広告イベントを使用して、広告物理チャネル（オレンジ色の囲みで表される）上で広告を行っている。 グループＤとグループＣは、衝突を避けるために、異なる広告ＰＨＹチャネルを使用していてもよいし、異なるタイミングで使用していてもよい。 ピコネットＦでは、１つの物理チャネルがある。 デバイスＦとデバイスＧは、ＬＥのピコネット物理チャネル（アクアエンクロージャーで表される）を使用している。 デバイスFがマスターであり、デバイスGがスレーブです。 グループHでは、1つの物理チャネルがあります。 デバイス H、I、および J は、LE 広告物理チャネルを使用しています（紫色のエンクロージャで表されます）。 デバイスＨは広告主であり、デバイスＩおよびＪはスキャナである。 スキャッタネットKでは、デバイスKとLは1つのLEピコネット物理チャネルを使用しています。 デバイスKとMは、別のLEピコネット物理チャネルを使用しています。 グループＫでは、デバイスＫはまた、広告物理チャネル上の接続可能な広告イベントを使用して広告を行っており、デバイスＮはイニシエータである。 デバイスＮは、デバイスＫとの接続を形成することができ、その結果、デバイスＫは、２つのデバイスのスレーブであり、同時に１つのデバイスのマスターである。 スキャッタネットOでは、デバイスOとPは1つのLEピコネット物理チャネルを使用しています。 デバイス O と Q は、別の LE ピコネット物理チャネルを使用しています。 グループＲでは、デバイスＲは、広告物理チャネル上の接続可能な広告イベントを使用して広告を行っており、デバイスＯはイニシエータである。 デバイスOはデバイスRとの接続を形成することができ、その結果、デバイスOは2つのデバイスのスレーブであり、同時に1つのデバイスのマスターである。

5 セキュリティの概要

5.1 セキュリティ構造

Bluetoothセキュリティモデルには、ペアリング、ボンディング、デバイス認証、暗号化、メッセージの完全性という5つの異なるセキュリティ機能が含まれています。

• ペアリング：1つ以上の共有秘密鍵を作成するプロセス
• ボンディング：信頼されたデバイスペアを形成するために、ペアリング中に作成されたキーを後続の接続で使用するために保存する行為。
• デバイス認証：2つのデバイスが同じ鍵を持っていることの検証
• 暗号化：メッセージの機密性
• メッセージの完全性：メッセージの偽造から保護

Bluetooth コアのセキュリティアーキテクチャは、時間の経過とともに進化してきました。 当初、ペアリングは SAFER+ に基づいた E21 または E22 アルゴリズムを利用していました。 このバージョンのペアリングは「BR/EDRレガシーペアリング」と呼ばれています。 デバイス認証は当初、SAFER+に基づいたE1アルゴリズムに基づいていました。 暗号化には、マッセイ・ルーペル・アルゴリズムから派生したE0アルゴリズムを利用しています。 また、暗号化メッセージの完全性に関する規定もありませんでした。 CRC はある程度の完全性保護を提供しますが、簡単に偽造される可能性があるため、暗号の完全性を提供するとは考えられていません。

この仕様のバージョン 2.1 + EDR では、FIPS 承認のアルゴリズム(SHA-256、HMAC-SHA-256、および P-192 楕円曲線)を利用した Secure Simple Pairing が導入され、4 つのアソシエーションモデルが導入されました。 Just Works、数値比較、Passkey Entry、および Out-Of-Band（セクション 5.2 参照）の 4 つのアソシエーションモデルが導入された。 デバイス認証と暗号化は、Secure Simple Pairingが導入されても変わりませんでした。

仕様のバージョン3.0 + HSでは、AMPのサポートが追加された(セクション5.5参照)。

バージョン4.0では、Low Energyのセキュリティモデル全体が追加されたが（セクション5.4参照）、BR/EDRやAMPのセキュリティ機能は変更されなかった。

バージョン4.1では、BR/EDRの物理トランスポートにSecure Connections機能が追加され、P-256楕円曲線を利用するためにSecure Simple Pairingがアップグレードされ、FIPS承認アルゴリズム（HMAC-SHA-256およびAES-CTR）を使用するためにデバイス認証がアップグレードされました。 Secure Connections では、メッセージの完全性 (AES-CCM) も追加されました。

バージョン 4.2 では、LE 物理トランスポートに Secure Connections 機能が追加され、FIPS 承認のアルゴリズム（AES-CMAC および P-256 楕円曲線）を使用するために LE ペアリングがアップグレードされ、Bluetooth LE 物理トランスポートで使用される数値比較アソシエーションモデルが適応されました。 また、ユーザーがもう一方の物理トランスポート上で 2 度目のペアリングを行う必要性を排除するために、どちらかの物理トランスポート上で Secure Connections を使用して生成された鍵のための規定も含まれています。 本仕様のバージョン 4.0 および 4.1 で定義されている LE ペアリングは、LE レガシー・ペアリングと呼ばれる。

BR/EDR と AMP のセキュリティ鍵階層を図 5.1 に示す。 キー階層は、物理リンクがセキュア・コネクションを使用しているか、レガシー・セキュリティ手順およびアルゴリズムを使用しているかによって異なります。

-- Figure 5.1: BR/EDR and AMP key hierarchy

LE のセキュリティ・キー階層を図 5.2 に示す。 キー階層は、物理リンクが LE セキュア・コネクションを使用しているか、LE レガシー・ペアリング手順およびアルゴリズムを使用しているかによって異なります。

-- Figure 5.2: LE key hierarchy

---

中略

5.3 セキュア接続専用モード

デバイスがBR/EDR物理トランスポートでFIPS承認アルゴリズムのみを使用することを要求する場合は、BR/EDR物理トランスポートでSecure Connections Only Modeを入力する必要があります。 セキュア・コネクション・オンリー・モードは、「FIPS モード」と呼ばれることもあります。 このモードは、Secure Connections をサポートしていないデバイスとの下位互換性を維持することよりも、デバイスが高いセキュリティを持つことが重要な場合に使用するべきです。 ホストは、ペアリング中に P-256 楕円曲線が使用され、安全な認証シーケンスが使用され、暗号化に AES-CCM が使用されることを強制します。

デバイスが LE 物理トランスポートで FIPS 承認のアルゴリズムのみを使用する必要がある場合は、LE 物理トランスポートで Secure Connections Only Mode を入力する必要があります。 Secure Connections Only Mode は、「FIPS モード」と呼ばれることもあります。 このモードは、デバイスが高いセキュリティを持つことが、LE セキュア・コネクションをサポートしないデバイスとの下位互換性を維持することよりも重要な場合に使用されるべきである。 このモードでは、ホストはペアリング中に P-256 楕円曲線が使用されることを強制します。

BR/EDR/LE デバイスがセキュア・コネクション・オンリー・モードで構成されている場合、BR/EDR と LE トランスポートの両方がセキュア・コネクション・オンリー・モードになります。

5.4 LE セキュリティ

仕様のバージョン4.0で導入されたペアリング・メカニズム（LE Legacy Pairingとして知られている）は、セキュア・シンプル・ペアリングなどのBR/EDRセキュリティ機能に関して、セキュリティ面でいくつかの違いがあります。 アソシエーション・モデルは、ユーザーの視点から見ると BR/EDR セキュア・シンプル・ペアリングに似ており、同じ名前を持つが、提供される保護の質に違いがある。

5.4.1 アソシエーションモデル

Bluetooth LE は、Just Works、Numeric Comparison、Out of Band、Passkey Entry と呼ばれる 4 つのアソシエーションモデルを使用します。 LEレガシーペアリングには、Numeric Comparisonに相当するものはありません。

LE レガシー・ペアリングでは、これらの各アソシエーション・モデルは、以下の例外を除いて BR/EDR セキュア・シンプル・ペアリングに類似しています。

• Just Works と Passkey Entry は、受動的な盗聴防止機能を提供しない。 これは、Secure Simple Pairing が Elliptic Curve Diffie-Hellman を使用し、LE レガシー ペアリングが使用しないためです。

LE Secure Connections ペアリングでは、4 つのアソシエーション・モデルは機能的に BR/EDR Secure Connections と同等です。

各アソシエーション・モデルの使用は、デバイスの I/O 能力に基づいています。

5.4.2 キー生成

Bluetooth LE における鍵生成は、他の LE デバイスから独立した各 LE デバイス上のホストによって実行されます。 ホストで鍵生成を行うことで、コントローラを変更することなく鍵生成アルゴリズムをアップグレードすることができます。

注：BR/EDR でのキー生成は、コントローラで実行されます。

Bluetooth LE は、以下のように複数の鍵を使用し、それぞれが特定の目的のために使用します。

• データの機密性とデバイス認証
• 暗号化されていないデータの認証
• デバイス アイデンティティ LE では、機密性と認証を提供するために使用される鍵は、ペアリング中に各デバイスからの貢献を組み合わせて生成される。

5.4.3 暗号化

Bluetooth LEの暗号化はAES-CCM暗号を使用しています。 BR/EDR と同様に、LE の暗号化はコントローラで実行される。

5.4.4 符号化データ

Bluetooth LE は、信頼された関係にある 2 つのデバイス間で、暗号化されていない ATT ベアラを介して認証されたデータを送信する機能をサポートしています。 これは、接続署名解決キー（CSRK）でデータに署名することで実現されます。 送信デバイスは、データ PDU の後に署名を配置する。 受信デバイスは署名を検証し、署名が検証された場合、データ PDU は信頼されたソースから来たものとみなされます。 署名は、署名アルゴリズムによって生成されたメッセージ認証コードとカウンタで構成される。 カウンタはリプレイ攻撃から保護するために使用され、署名されたデータ PDU が送信されるたびに増分される。

5.4.5 プライバシー機能

Bluetooth LEは、Bluetoothデバイスのアドレスを頻繁に変更することで、LEデバイスを長期間にわたって追跡する機能を軽減する機能をサポートしています。

プライバシー機能を使用するデバイスが既知のデバイスに再接続するためには、プライベート・アドレスと呼ばれるデバイス・アドレスは、他のデバイスによって解決可能でなければならない。 プライベートアドレスは、ボンディング手順の間に交換されたデバイスのresolving identity key（IRK）を使用して生成される。

用語「解決」は、受信したプライベートアドレスとIRKからデバイスのIDアドレスを計算するためにデバイスが使用するプロセスを意味し、「解決された」という状態は解決の成功結果である。

プライバシー機能には、2つのバリアントがある。 最初のバリアントでは、プライベートアドレスはホストによって解決され、生成されます。 第２のバリアントでは、プライベートアドレスは、ホストがコントローラのデバイス識別情報を提供した後、ホストが関与することなく、コントローラによって解決され、生成される。 さらに、第２のバリアントでは、コントローラ内の解決リストが、ボンデッドデバイスに必要なすべてのデバイスアイデンティティ解決キーを格納できない場合に、ホストを関与させることができる。

プライバシーには、デバイスプライバシーモードとネットワークプライバシーモードの２つのモードがある。 デバイス・プライバシー・モードのデバイスは、デバイスのプライバシーのみを気にしており、ピア・デバイスが過去にＩＲＫを配布したことがあっても、自分のＩＤアドレスを含むピア・デバイスからの広告パケットだけでなく、プライベート・アドレスを含むピア・デバイスからの広告パケットも受け入れます。 ネットワーク・プライバシー・モードでは、デバイスは、プライベート・アドレスを含むピア・デバイスからの広告パケットのみを受け入れます。 デフォルトでは、プライベートアドレスがコントローラによって解決されて生成された場合、ネットワークプライバシーモードが使用されます。

ホストは、デバイスの識別子を追加したり削除したりすることで、解決リストを維持する。 ホストは、完全な解決リストまたは解決リストのサブセットをコントローラに提供することができます。 デバイス ID は、ピアの ID アドレスとローカルとピアの IRK ペアで構成されます。

コントローラがアドレス解決を実行し、ホストが解決リストに含まれるピアデバイスを参照する必要がある場合は、ピアのデバイス ID アドレスを使用します。 同様に、コントローラからホストへのすべての着信イベントは、ピアのデバイスアドレスが解決されていれば、ピアのデバイスIDを使用します。 コントローラが広告で相手のデバイス ID アドレスを解決できなかった場合、イベントをホストに渡してホスト内で解決することができます。

コントローラでアドレス解決を行うと、ホワイトリストにあるかどうかを確認する前に、ピアのデバイス ID アドレスを解決できるため、デバイスフィルタリングが可能になります。

図 5.4 に、コントローラ解決リストとコントローラホワイトリストの関係を論理的に示します。 解決リストとホワイトリストの実際の実装は、このモデルに従う必要はありません。 解決リストはホワイトリストとは独立していても構いません。

-- Figure 5.4: Logical representation of the resolving list and Device White List

注：ホワイトリストのすべてのデバイスがデバイス ID アドレスであるわけではありません。

アドレス解決がホストでのみ実行される場合、デバイスのフィルタリングを無効にする必要があるため、デバイスの消費電力が増加する可能性があります。

6.2 ジェネリックアクセスプロファイル

Bluetooth システムは、すべての Bluetooth デバイスが実装する基本プロファイルを定義しています。 このプロファイルはGAP（Generic Access Profile）であり、Bluetoothデバイスの基本的な要件を定義します。 例えば、BR/EDR では、無線、ベースバンド、リンク・マネージャ、L2CAP、およびサービス・ディスカバリー・プロトコル機能を含む Bluetooth デバイスを定義し、LE では、物理層、リンク層、L2CAP、セキュリティ・マネージャ、属性プロトコル、および汎用属性プロファイルを定義します。 これは、Bluetooth デバイスの基本的な要件を形成するために、すべてのさまざまなレイヤーを結びつけます。 また、デバイスディスカバリ、接続確立、セキュリティ、認証、アソシエーションモデル、サービスディスカバリの動作と方法についても説明しています。

BR/EDRでは、GAPは、各デバイスに存在する可能性のある機能を持つ単一の役割を定義しています。 この機能には、デバイスがどのようにしてお互いを発見し、接続を確立し、認証に使用されるセキュリティ・アソシエーション・モデルを記述するかが含まれます。 BR/EDRでは、この機能は両方のデバイスに存在する可能性があります。 デバイスがすべてのデバイスとの接続を検出または確立したい場合は、デバイスにイニシエート機能とアクセプタンス機能の両方を実装する必要があるかもしれません。 デバイスは、イニシエート機能とアクセプタンス機能のどちらか一方だけを含んでいてもよいが、デバイスとの接続を検出または確立するためには、リモートデバイスが補完的な機能をサポートしている必要がある。 BR/EDR の場合、コントローラはすべての機能をサポートすることが要求されるが、ホストは、デバイスがサポートする 他のプロファイルまたはユースケースに基づいて、この機能を制限することができる。

LE では、GAP は 4 つの特定の役割を定義します。 ブロードキャスター、オブザーバー、ペリフェラル、およびセントラルです。 デバイスは、基礎となるコントローラがこれらの役割または役割の組み合わせをサポートすることを条件に、複数の LE GAP の役割をサポートすることができます。 各ロールは、基礎となるコントローラの要件を指定します。 これにより、コントローラを特定のユースケースに合わせて最適化することができます。

ブロードキャスターの役割は、送信機のみのアプリケーションに最適化されています。 ブロードキャスターの役割をサポートするデバイスは、データをブロードキャストするために広告を使用します。 Broadcaster ロールは接続をサポートしません。 Observer ロールは受信機専用アプリケーションに最適化されています。 Observer ロールをサポートするデバイスは Broadcaster の補完デバイスであり、広告に含まれるブロードキャストデータを受信します。 Observer ロールはコネクションをサポートしません。 Peripheral ロールは、単一の接続をサポートし、Central デバイスよりも複雑ではないデバイスに最適化されています。 Peripheral ロールをサポートするデバイスには、コントローラのスレーブロールをサポートするコントローラのみが必要です。 Central ロールは複数の接続をサポートし、Peripheral ロールのデバイスとのすべての接続のイニシエータとなります。 Central ロールをサポートするデバイスは、Controller のマスター・ロールをサポートする Controller を必要とし、一般的に他の LE GAP ロールと比較してより複雑な機能をサポートします。

6.3 PROFILE HIERARCHY

すべての Bluetooth デバイスは GAP を実装する必要があるため、Bluetooth デバイスによって実装された追加のプロファイルは GAP のスーパーセットになります。 アプリケーションの複雑さや、多くのアプリケーション間でBluetoothシステムの機能の共通要件を再利用する能力に応じて、他のプロファイルを有効にするだけでなく、GAPまたは他の一般的なプロファイルに依存する追加の一般的なプロファイルを作成することができます。 アプリケーションの相互運用性を記述する最上位のプロファイルは、アプリケーションプロファイルと呼ばれます。

アプリケーションプロファイルには、GAPやBluetoothシステムの共通要件を記述する他の汎用プロファイルが参照されています。

6.4 GENERIC ATTRIBUTE PROFILE

Generic Attribute Profile (GATT)は、Attributeプロトコル(ATT)の上に構築され、Attributeプロトコルで転送・保存されるデータの共通操作とフレームワークを確立します。 GATTは2つの役割を定義しています。 サーバとクライアントです。 GATTの役割は、必ずしも特定のGAPの役割に縛られているわけではなく、上位層のプロファイルによって指定されている可能性があります。 GATTとATTはトランスポートに特化したものではなく、BR/EDRとLEの両方で使用できる。 しかし、GATTとATTはサービスを発見するために使用されるので、LEでの実装は必須である。

GATT サーバは、Attribute プロトコルで転送されたデータを格納し、GATT クライアントからの Attribute プロトコルの要求、コマンド、確認を受け付ける。 GATT サーバは、要求に対する応答を送信し、設定されている場合には、GATT サーバ上で指定されたイベントが発生した場合に、非同期的に GATT クライアントに指示と通知を送信します。

また、GATTはGATTサーバに含まれるデータのフォーマットを指定します。 属性は、属性プロトコルによって転送され、サービスと特性としてフォーマットされます。 サービスは、特性の集合を含むことができる。 特性は、単一の値と、その特性値を記述する任意の数の記述子を含む。

サービス、特性、特性記述子の定義された構造により、プロファイルに固有でないGATTクライアントは、GATTサーバをトラバースして、ユーザに特性値を表示することができます。 特性記述子は，その値をユーザに理解させるような特性値の記述を表示するために使用することができる。

6.5 ガットベースのプロファイル・ハイアーキシー

GATTプロファイルは、プロファイルデータを交換するための構造を規定している。 この構造は、プロファイルで使用されるサービスや特性などの基本的な要素を定義している。

階層の最上位がプロファイルである。 プロファイルはユースケースを満たすために必要な 1 つ以上のサービスで構成される。 サービスは、特性または他のサービスへの参照で構成される。 各特性は値を含み、その値に関するオプション情報を含んでもよい。 サービスと特性と特性の構成要素（すなわち，値と記述子）は，プロファイルデータを含み，すべてサーバ上の属性に格納される。

6.5.1 サービス

サービスとは、デバイスまたはデバイスの一部の特定の機能または機能を達成するためのデータおよび関連する動作の集合体である。 サービスは、他の一次サービスまたは二次サービス、および/またはサービスを構成する特性のセットを含むことができる。

サービスには、一次サービスと二次サービスの２種類がある。 一次サービスは、デバイスの一次機能を提供するサービスである。 セカンダリサービスは、デバイスの補助機能を提供するサービスであり、デバイス上の少なくとも１つのプライマリサービスから含まれる。

以前のクライアントとの下位互換性を維持するために、サービス定義の後のリビジョンでは、新たに含まれるサービスまたはオプションの特性のみを追加することができます。 サービス定義の後のリビジョンは、サービス定義の前のリビジョンからの動作を変更することも禁止されている。

サービスは、特定のユースケースを満たすために、一つ以上のプロファイルで使用することができる。

6.5.2 含まれるサービス

インクルードサービスとは、サーバ上の別のサービス定義を、それを含むサービスの一部として組み込む方法です。 サービスが別のサービスを含む場合，含まれるサービス全体は，ネストされた含まれるサービスと特性を含む新しいサービスの一部となる。 インクルードされたサービスは、依然として独立したサービスとして存在する。 ネスティングの深さに制限はありません。

6.5.3 特性

特性とは、サービスで使用される値のことで、その値がどのようにアクセスされるかに関するプロパティや設定情報、値の表示や表現方法に関する情報とともに、サービスで使用される値のことです。 特性定義は、特性宣言、特性プロパティ、および値を含む。 また、値を記述する記述子や、特性値に関するサーバーの設定を許可する記述子を含むこともあります。