ブルートゥース® 低エネルギー入門書

バージョン	日付	著者	変更点
1.0.0	2022年4月22日	マーティン・ウーリー、BluetoothSIG	初期バージョン。
1.0.4	6 2022年6月	マーティン・ウーリー、BluetoothSIG	リンクレイヤー改善：チャンネル分類がオプションの実装機能であることを明確にするための文言の改善、チャンネルマップアップデートとチャンネルステータスレポートの区別、AFHが規制の文脈では異なる意味を持つ可能性があることのフラグ付け。
1.1.0	2023年1月17日	マーティン・ウーリー、BluetoothSIG	Bluetooth^®コア仕様5.4を反映し、レスポンスによる定期アドバタイズ情報を追加しました。
1.2.0	2024年3月15日	イフティ・アニーズ、BluetoothSIG	フォーマットの更新と、オブザーバーの役割に関する14.2の誤字の修正。
1.3.0	2024年10月15日	マーティン・ウーリー、BluetoothSIG	^Bluetooth® Channel Sounding、Decision-Based Advertising Filtering、およびアドバタイザーモニター各機能に関する情報に加え、フレーム間スペースタイミング変数の許容値が改訂されました。

2.本稿について

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

ブルートゥースSIG から入手可能なBluetooth LE に関する仕様書、論文及びその他の教育用資料が多数存在する。本稿の更なる目的は、それらの存在と目的について認識を高め、読者がこのテーマとその支援資料の方向性を理解する一助とすることである。

大半のBluetooth LE 製品は、データ交換のためにコネクションレス通信（アドバタイジング）とポイント・ツー・ポイント接続の組み合わせを使用するか、アドバタイジング・パケットのブロードキャストのみによって通信を行う。本リソースは、これらのカテゴリーに分類される製品に使用されるBluetooth LE スタックをカバーする。一方、Bluetooth mesh は本リソースではカバーしていない。Bluetooth メッシュはBluetooth LE の特殊な用途であり、他の情報資源を参照する必要がある。

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

3.はじめに

ブルートゥース・テクノロジーは2000年に登場した。当初は、他の中間ネットワーク機器を必要とせず、2つのデバイスがワイヤレスでデータを交換できるようにするために作られたが、すぐにワイヤレスマウスや自動車用ハンズフリーキットなどの製品にその役割を見出した。後者は製品あり、オーディオはこのブルートゥース・テクノロジーのオリジナル・バージョンのキラー・アプリケーションであることが証明された。それは長年にわたって続いた。

ブルートゥース・テクノロジーの最初のバージョンは、ブルートゥースBR（ベーシック・レート）として知られている。物理層での生のデータ・レートは100万ビット/秒（1 mb/s）だった。

その後、Bluetooth BR/EDR Data Rate）として知られるBluetooth技術の高速バージョンが定義された。これは2 mb/sのデータ・レートを提供するが、2つのデバイス間で直接データを交換するようなユースケース向けに設計されている。

Bluetooth Low Energy（LE）は、ブルートゥースコア仕様[1]のバージョン4.0で初めて具体化されました。これはBluetooth技術の新バージョンで、前身であるBluetooth BR/EDR置き換えるのではなく、新世代の製品に最適な機能と品質を備え、新たな困難な技術的・機能的要件を満たすことができる代替技術として位置づけられました。

Bluetooth LE 、2つのデバイス間のポイント・ツー・ポイント通信以外のトポロジーをサポートし、1つのデバイスが同時に無制限の数のレシーバーにデータを送信することを可能にする様々なブロードキャストベースのモードを備えています。また、Bluetooth Mesh Networkingの基盤でもあり、数万台のデバイスからなるネットワークを構築し、それぞれがネットワーク内の他のデバイスと通信することができます。

2つのデバイス間の1対1通信は、コネクション型通信とコネクションレス型通信の両方でサポートされる。一対多の通信はコネクションレス型ブロードキャストによってサポートされる。

アプリケーションデータの通信方向は、Bluetooth LE 使用方法によって異なります。ここでモードという用語はこの略語として使用されることに注意。モードにはコネクション型通信とコネクションレス型通信がある。いくつかのモードはアプリケーションデータの双方向交換をサポートしますが、場合によってはアプリケーションデータは一方向にしか送信できません。

通常、アプリケーションデータは時間とクリティカルな関係を持ちませんが、そのような関係を持つ場合もあり、デバイスは受信データを処理する際にその関係を維持する必要があります。Bluetooth LE 、コネクションオリエンテッドモードとコネクションレスモードの両方でアイソクロナス通信をサポートしています。アイソクロナス通信は、まさにデータが時間に縛られるような場合のために設計されています。オーディオはその良い例です。

Bluetooth LE には、位置情報関連のアプリケーションで使用されるように設計された、多くのデバイス測位機能があります。

方向検知は、レシーバー送信信号の方向を計算できる2つの異なる方法を定義している。この2つの方法は、到着角AoA）と出発角AoD）と呼ばれています。
Bluetooth^® Channel Sounding 、2つのデバイスが協力し、一方のデバイスがもう一方のデバイスからの距離を安全に計算することを可能にします。

この新しいBluetooth技術の当初のdesign 目標のひとつは、エネルギーの使用効率が非常に高いことでした。小さなコインサイズのバッテリーで数日から数週間以上動作するデバイスが想定されており、このエネルギー効率の追求がBluetooth LE定義する多くの特徴を説明している。特に、スマートフォンの大容量バッテリーのような比較的豊富な電力源を持つデバイスが、コイン電池で動作する同クラスのデバイスよりも多くの力仕事をこなせるよう、デバイスに非対称の能力と責任を割り当てるdesign いる。このようなdesign 決定が、Bluetooth LE 現在のような低消費電力ワイヤレス通信技術とし、その後の数年間で、多くの種類の製品に広く採用されるようにしたのである。

4.Bluetooth LE 仕様

Bluetooth LE を深く理解するには、適用される仕様に精通している必要がある。Bluetooth LE のアーキテクチャ、手順、プロトコルは、ブルートゥースコア仕様呼ばれる主要仕様で完全に定義されている。製品間で相互運用可能な Bluetooth の使用方法は、プロファイルと サービスと呼ばれる 2 種類の仕様の集合体によってカバーされています。図 1 は、Bluetooth LE 仕様の種類とその関係を示しています。

図1 -Bluetooth LE 仕様

4.1ブルートゥースコア仕様

ブルートゥースコア仕様、Bluetooth LE Bluetooth Classicの両方の主要仕様です。この仕様は

は、Bluetooth技術のアーキテクチャと、様々なスタック構成のレイヤーを定義しています。
は重要な特徴を説明し、定義している。
は、サポート業務を支える正式な手順を定義している。
は、デバイスがスタックの関連レイヤー間で通信するプロトコルを定義する。

ブルートゥースコア仕様必然的に大きくなる。

要約すると、ブルートゥースコア仕様、Bluetooth技術がどのように動作するか、Bluetoothスタックまたはその機能の1つ以上を実装する際の開発者の要件を定義しています。

4.2 プロファイルの仕様

つのBluetooth LE デバイスが接続を介して通信する場合、通常、クライアントサーバーの関係が形成されている。サーバは状態データを格納し、クライアントは何らかの方法でそのデータを使用します。

Bluetoothキーフォブを考えてみよう。その目的は、鍵をどこかに置いて一時的に紛失したときに、鍵を見つけるのを助けることだ。スマートウォッチがクライアント機能し、Bluetoothキーフォブがサーバーとして機能する。スマートウォッチのディスプレイ上のボタンを押すと、キーフォブの状態変化し、それに反応して大きな音が鳴るので、再び鍵を見つけることができる。

プロファイル仕様は、（スマートウォッチやキーフォブのような）関連デバイスが担う役割を定義し、特に、クライアント動作と、それが動作すべき接続サーバー上のデータを定義する。

キーファインダーの例では、スマートウォッチまたは同じ役割を担う他のデバイスの動作は、Find Me Profile仕様で定義されている。

4.3 サービス仕様

サーバー上の状態データは、特性および記述子[2]として知られる、正式に定義されたデータ項目に存在する。特性および記述子は、サービスとして知られる構成要素の中にグループ化される。サービスは、その中に含まれる特性と記述子に意味と動作を割り当てるためのコンテキストを提供する。

サービス仕様は、1つのサービスを、それが含む特性および記述子とともに定義する。様々な条件や状態データ値に応答して、サービスをホストするデバイスが示すべき動作は、サービス仕様で定義される。

サービス仕様は、サーバー機器の動作の一面を定義したものと考えることができる。

スマートウォッチとキーフォブの例では、キーフォブがサーバーとして機能し、即時アラートサービスを実装している。

4.4 プロトコル仕様

標準化されたBluetoothアプリケーションの中には、独自のプロトコルを必要とするものがあり、これらのプロトコルには独自の仕様があります。主なBluetooth Mesh仕様はプロトコル仕様です。

4.5割当番号

Bluetooth LE 様々な側面は一意識別子を利用する。例えば、全てのサービス、特性及び記述子は、特定のデバイス上の特定のインスタンスではなく、関連するサービス、特徴又は記述子のタイプを識別する汎用一意識別子（UUID）を持つ。企業は、特定のプロファイルで要求される一意の企業識別子によって識別されるかもしれない。

BluetoothSIG 割り当てられた識別子は、次のように知られている。 割当番号このような識別子の全リストは、BluetoothSIG ウェブサイトの割当番号ページから入手できます。

5.Bluetooth LE スタック

5.1 ハイレベル・アーキテクチャ

Bluetooth LE スタックは多くのレイヤと機能モジュールから構成され、その一部は必須で、一部はオプションである。スタックのこれらの部分は、以下の 2 つの主要なアーキテクチャ・ブロックに分散されています。 host標準論理インターフェースは、これら 2 つのコンポーネントが通信する方法を定義します。

host オペレーティングシステムのようなものであることが多い。コントローラはチップ上のシステムであることが多い。しかし、これは必ずしもそうではなく、Bluetoothの仕様はそのような実装の詳細を義務付けていません。重要なのは、host コントローラがアーキテクチャ内の別々の論理コンテナとして動作し、何らかの方法で物理的に別々のコンポーネントに実装され、その間の通信に標準インターフェースが定義されていることです。これにより、Bluetoothシステムは異なるメーカーのhost コントローラのコンポーネントで構成することができます。

図 2 は、Bluetooth LE スタックとそのレイヤー、及びhost コントローラのコンポーネント間の配分を示している。

Host （Host ）は、これらの間の論理インターフェイスを示すが、物理コンポーネントではない。HCIは、基礎となる物理的なトランスポートに関して、さまざまな方法で実装することができますが、論理的または機能的なインターフェイスは常に同じです。

LC3 は Low Complexity Communication Codec で、Bluetooth LE Audio で使用されるデフォルトのオーディオコーデックです。標準的なBluetooth LE スタックの一部ではありませんが、LE Audio 製品には必ず含まれており、LC3 コンポーネントはhost またはコントローラに実装されています。

図 3 は通信システムの標準 OSI 参照モデルを示している。物理層やデータリンク層など、OSI 層のサブセット及ぶ他の多くの無線システムとは対照的に、Bluetooth LE スタックは OSI 参照モデルの全層に及ぶことに留意すべきである。フルスタック通信システムであるBluetooth技術が持つ利点の1つは、他の標準化団体への外部依存がないことです。このような依存関係は、技術の進化を制約する可能性があります。

図2 -Bluetooth LE スタック

図3 - OSI参照モデル

ブルートゥース・メッシュ・プロトコルはBluetooth LE コア機能を使用し、コア・Host ブルートゥース・メッシュ・プロトコルと手順を実装する特殊なレイヤーのコレクションを追加します。host 、図 2 のhost 部分に示されるレイヤーのうち、接続形成能力など他の製品要件をサポートするために必要なレイヤーを含むことができます。

この資料では、ブルートゥース・メッシュについてはこれ以上触れていないため、このテーマに関する教育資料をお探しの方は、セクション18をご参照ください。以下に追加リソースを示します。

図4 - Bluetooth Meshスタック

5.2 レイヤーの概要

図 2 に示されるBluetooth LE スタックの各層の主な責務と特徴の概要は以下の通り：

レイヤー	主な責任
物理層	変調方式、周波数帯域、チャネルの使用、レシーバー、レシーバー特性など、無線（RF）の使用に関連する Bluetooth 技術のすべての側面を定義する。
リンクレイヤー	論理トランスポートとして知られるコネクションレス、コネクションオリエンテッド、アイソクロナス通信のために、基礎となる無線を使用するいくつかの異なる方法を定義する。
Channel Sounding	他のデバイスまでの距離を計算するために、アプリケーション層が使用する可能性のある測定を行う能力をデバイスに提供する。すなわち、位相ベース測距 PBR）とラウンドトリップタイミングRTT）である。これらの方式は、組み合わせて使用することも、別々に使用することもできる。
アイソクロナス・アダプテーション・レイヤー(ISOAL)	フレーム化されたPDUの分割と再組み立て、またはフレーム化されていないPDUの断片化と再結合。
Host (HCI)	host コンポーネントとコントローラ間のコマンドとデータの双方向通信用に、明確に定義された機能インターフェイスを提供する。
論理リンク制御適応プロトコル(L2CAP)	host内でプロトコルのマルチプレクサとして動作し、プロトコルが適切なhost コンポーネントによってサービスされるようにする。L2CAPの下のレイヤと上のレイヤの間でPDU/SDUのセグメンテーションと再アセンブルを実行する。
セキュリティ・マネージャー・プロトコル(SMP)	ペアリングなどのセキュリティ手順の実行時に使用されるプロトコル。
属性プロトコル(ATT)	ATTクライアント ATTサーバーが使用するプロトコルで、サーバーの属性テーブルのデータの発見と使用を可能にする。
汎用属性プロファイル(GATT)	サービス、特性および記述子として知られる高レベルのデータ型を、属性テーブルの基礎となる属性の観点から定義する。属性テーブルを操作するためにATTを使用するための高レベルの手順を定義する。
ジェネリック・アクセス・プロファイル(GAP)	コネクションレス通信のためのアドバタイジングの使用方法や、デバイスディスカバリの実行方法など、非接続状態あるときに使用される可能性のある動作モードと手順を定義する。

6.物理層

Bluetooth LE の物理層は、無線トランスミッターどのように送受信のためにデジタルデータのエンコード及びデコードに使用されるか、また、適用されるその他の無線関連のパラメータやプロパティを定義する。

6.1 周波数帯域

Bluetooth LE 2.4GHzの免許不要帯域2400MHzから2483.5MHzで動作し、各チャンネルは2MHz幅で40チャンネルに分割される。チャネルの使用方法は、リンクレイヤーデータ・トランスポート・アーキテクチャによって定義されます。

図5 -Bluetooth LE チャンネル

6.2 変調方式

6.2.1 ガウス周波数シフト・キーイング

送信前にスタックの上位レイヤーからデジタルデータをエンコードし、受信した無線信号をデコードするために、Bluetooth LE はガウス周波数シフト・キーイング（GFSK）と呼ばれる変調方式を使用します。GFSK は、選択されたチャネルの中心周波数（キャリア）を持つ信号を、デジタル値 1 を表すために指定された量だけシフトアップするか、バイナリ値 0 を表すために同じ量だけシフトダウンすることで機能します。急激な周波数変化に伴うノイズを低減するため、信号にはガウスフィルタリングが適用されます。

図6は基本的な周波数シフトキーイングプロセスを示す。周波数がシフトされる量は周波数偏差として知られ、使用する PHY バリアントによって少なくとも +/-185 kHz または少なくとも 370 kHz であることに注意(PHYについては 6.3 PHY バリアントで説明)。

図6 -Bluetooth LE周波数シフト・キーイング

6.2.2 振幅シフト・キーイング

Channel Sounding （「8.^Bluetooth® チャンネル・サウンディング」参照）は、一部の伝送にASK（Amplitude Shift Keying）と呼ばれる変調方式を使用します。ASKは2つのシンボル状態を持つ2値変調方式です。1つ目は、選択した周波数で固定振幅の搬送波を一定時間送信するもの。もう1つは、選択された周波数で該当する時間帯に送信されないことである。

6.3 PHY バリアント

多くの変調方式バリエーションが定義されている。各変種はPHYと呼ばれ、名前がある。物理レイヤーの伝送速度は、ビット毎秒ではなく、シンボル毎秒で測定される。

Bluetooth LE バイナリ変調方式を採用しており、1つのアナログ・シンボルがスタックの上位の1つのデジタル・ビットを表す。

各 PHY は、帯域幅-ビット周期製品 (BT)と呼ばれるプロパティ含む。BT は信号の帯域幅とシンボルの持続時間の関係を決定する。

BTの値は、シンボルを構成する無線パルスの形状とスパンに影響する。BTの値が高いほどパルスは細く四角くなり、低いほどパルスは太く丸くなる。

ブルートゥースコア仕様定義された PHY タイプは以下の通りである：

LE 1MPHY は、最低 185kHz の周波数偏差で 1Msym/s のシンボルレートを使用し、特別なコーディングは使用しない。全てのデバイスは、LE 1M PHY をサポートしなければならない。この PHY では BT=0.5 である。
について LE 2MPHY は LE 1M に似ているが、2 Msym/s のシンボルレートを使用し、少なくとも 370 kHz の周波数偏差が必要である。LE 2M PHY のサポートはオプションである。この PHY では BT=0.5 である。
LE 2M 2BTPHY は 2Msym/s のシンボルレートを持つが、少なくとも 420kHz の周波数偏差を必要とする。この PHY では BT=2 である。
について LE CodedPHY は、1Msym/s のシンボルレートを使用するが、パケットは、リンクレイヤー定義されている FEC (Forward Error Correction) と呼ばれる符号化の対象となる。FEC は、送信の有効範囲を広げるが、アプリケーションデータレートを下げる。LE Coded PHY のサポートはオプションである。この PHY では BT=0.5 である。

PHY の比較を以下に示す：

	LE 1M	LE Coded S=2	LE Coded S=8	LE 2M	LE 2M 2BT
シンボル・レート	1 Ms/s	1 Ms/s	1 Ms/s	2 Ms/s	2 Ms/s
プロトコル・データ・レート	1 Mbit/s	500 Kbit/s	125 Kbit/s	2メガビット/秒	2メガビット/秒
おおよその最大アプリケーションデータレート	800 kbps	400 kbps	100 kbps	1400 kbps	該当なし[3]。
ブリティッシュ・テレコム	0.5	0.5	0.5	0.5	2.0
エラー検出	CRC	CRC	CRC	CRC	該当なし[4]。
エラー訂正	なし	FEC	FEC	なし	なし
レンジ倍率（約）	1	2	4	0.8	0.8
必要条件	必須	オプション	オプション	オプション	オプション

定義

期間	定義
シンボル・レート	物理層でアナログ・シンボルが伝送される速度。
プロトコル・データ・レート	アプリケーション含む Bluetooth プロトコルデータユニット(PDU)に関するビットの伝送レート。
おおよその最大アプリケーションデータレート	通信デバイス上のアプリケーション間でアプリケーションデータを転送できるおおよその最大レート。データは各種 PDU のペイロード部で転送され、残りのプロトコル・データ・レートは Bluetooth プロトコル・データで消費されます。
CRC	Cyclic Redundancy Check（巡回冗長検査）。伝送エラーの検出に使用されるフィールド。このフィールドとその使用法はリンクレイヤー定義されている。

6.4 時間分割

Bluetooth LE 無線機は半二重デバイスであり、送信と受信の両方が可能であるが、同時に両方はできない。しかし、全ての PHY は時分割複信(TDD)方式で使用され、全二重無線機のように見える。

6.5 送信電力とレシーバー感度

物理層は、出力電力要件を含むトランスミッター特性を定義しており、仕様では、最大電力設定時の出力電力レベルは0.01mW（-20dBm）から100mW（+20dBm）の間でなければならない。

世界各地の規制機関[5]は、これらの要件を上書きする可能性があり、実装者は、デバイスが適用される地域の規制に準拠していることを確認しなければならない。

レシーバー感度は、特定のビット誤り率（BER）が発生するレシーバー入力レベルとして定義される。リンクレイヤー各パケットに1つの巡回冗長検査（CRC）フィールドを付加し、これを復号化されたパケット内の1つ以上のビットの誤りを検出するメカニズムとして使用するため、指定されたBERは受信したパケットの長さに応じて変化します。パケットの長さは様々であり、パケットごとに1つのCRCが存在するため、パケットの長さは計算上のBERに影響する。

Bluetooth LE レシーバー感度に関する議論では、通常 0.1% の BER が引用される。これは 37 オクテット長までのパケットで許容される最大エラー率である。

物理層で定義されるその他のレシーバー特性には、干渉性能、帯域外ブロッキング、相互変調特性、最大使用可能入力レベル、受信信号強度表示（RSSI）の要求精度などがある。

6.6 アンテナ切り替え

6.6.1方向検知

Bluetooth LE 受信信号が送信された方向を計算する2つの方法をサポートしています。1つ目は到着角度（ AoA ）と2番目の出発角（ AoDどちらの方法も、アンテナアレイを備えた1つのデバイスと、方向探知信号の送信中に1つのアンテナから別のアンテナに切り替えるプロセスを必要とします（ AoD 方法）または信号を受信するとき（ AoA 方法）。方向検知信号は、Constant Tone Extension (CTE) フィールドを含む標準の Bluetooth パケットです。

アンテナアレイには様々な設計があり、あるアンテナから次のアンテナへの切り替えは、様々な切り替えパターンに従うことができます。これはhost制御されますが、物理層はアンテナ切り替えのプロセス、関連するレシーバー要件、いくつかの有用な定義について、一般的に適用可能なルールも定義しています。

ブルートゥースコア仕様、第6巻パートAの第5節でこのトピックをより詳細に取り上げている。AoA AoD 方向検知機能詳細は、ブルートゥースコア仕様バージョン5.1の機能概要ペーパーに記載されている。

6.6.2Channel Sounding

Bluetooth®Channel Sounding 、2つのデバイスの一方または両方に複数のアンテナを使用することができ、アンテナの選択と使用に関するルールがあります。8.Bluetooth^®チャンネルサウンディング」をご参照ください。

7.リンクレイヤー

7.1リンクレイヤー概要

リンクレイヤー仕様は、ブルートゥースコア仕様中で、Host ス機能仕様のセクションに次いで大きい。しかし、間違いなく最も複雑です。

リンクレイヤー多くの責任がある。それは、空中で送信されるいくつかのタイプのパケットと、関連するエア・インターフェース・プロトコルを定義する。その動作は明確に定義された状態マシンに従う。状態、リンクレイヤー多くの異なる方法で動作し、多くの種類のイベントによって駆動される。リンクの状態リンク使用パラメータに影響を与える多数の制御手順が定義されている。無線チャネルの選択と分類は、リンクレイヤー仕様で定義されている。

リンクレイヤー、コネクテッド通信とコネクションレス通信の両方をサポートし、決定論的なイベントタイミングと（わずかに）ランダムなイベントタイミングをサポートします。2つのデバイス間のポイントツーポイント通信と、1つのデバイスから無制限の受信デバイスへの1対多通信の両方を同時にサポートする。リンクレイヤーどのように使用されるかによって、アプリケーションデータの転送は双方向になることもあれば、一方向にのみ転送されることもある。

Bluetooth LE 多機能性の多くは、リンクレイヤー洗練さに根ざしている。

7.2 パケット

リンクレイヤー 2 つのパケットタイプを定義する。第 1 は、符号化されていない PHY(図 7 参照)、LE 1M とLE 2M で使用され、第 2 は、LE Coded PHY(図 8 参照)で使用される。他のパケットタイプはChannel Sounding使用するために定義されている。

図 7 - LE アンコード PHY のリンクレイヤー

図 8 -LE Coded PHY のリンクレイヤー

どちらのパケット・タイプも、プリアンブル、アクセス・アドレス、およびCRCフィールドを含む。表1に、これらの共通フィールドのそれぞれを説明する。

リンクレイヤー・パケット・フィールド名	項目
前文	プリアンブルによって、レシーバー信号の周波数に正確に同期し、自動利得制御を実行し、シンボルのタイミングを推定することができる。
アクセス・アドレス	アクセス・アドレス、受信機が信号をバックグラウンド・ノイズから区別し、受信デバイスに対するパケットの関連性を判断するために使用される。例えば、接続されたデバイスのペアが、同じランダムに割り当てられたアクセス・アドレスパケットを交換するとします。接続に参加していないデバイスは、このようなパケットを無視します。同様に、すべてのレガシーアドバタイズ、0x8E89BED6の値を持つ同じアクセス・アドレス使用します。
CRC	巡回冗長検査はエラー検出に使用される。その値はトランスミッター、パケット内の他のビットの値を用いて計算される。パケットを受信すると、受信デバイスもCRCフィールドを構成するビットとは別に、受信パケット内のビットの値からCRC値を計算します。そして、レシーバー計算したCRCは、パケット内のCRCフィールドの値と比較されます。2つのCRC値が一致すれば、パケットは正しく受信されたことになる。一致しない場合、そのパケットには1つ以上のビットの誤りがあると判断される。

表1 - 一般的なリンクレイヤー

リンクレイヤー PDU フィールドは、Bluetooth LE 使用方法に応じて様々な異なるプロトコル・データ・ユニット（PDU）を含むことがある。Constant Tone Extension（CTE）は、2 つの方向検知方式（Angle of Arrival または Angle of Departure）のいずれかが使用されている場合にのみ存在する。

PDUとCRCフィールドは、パケットを送信する前にホワイトニングと呼ばれる処理が行われる。ホワイトニングの目的は、レシーバー周波数ロックのドリフトを引き起こす可能性があるため、パケット内のゼロまたは1の長いシーケンスを避けることである。ホワイトニング処理は、CRCがチェックされる前に、元のビットストリームに戻すためにレシーバー反転されます。

PDUフィールドは暗号化されていてもよく、その場合はPDUが改竄されることを防ぐメッセージ完全性チェックフィールドを含む[6]。

LE Coded PHY が使用されるとき、ビットストリームは送信前に追加処理を受ける。前方誤り訂正(FEC)エンコーダとパターンマッパのアプリケーション、追加データを生成するレシーバー

7.3状態マシン

リンクレイヤー、図9に示す状態機械によって制御される。

図9 -リンクレイヤー状態マシン

状態詳細については、リンクレイヤー仕様書を参照のこと。要約を表2に示す。なお、いくつかの用語については、このセクションの後半で説明する。

状態	項目
スタンバイ	デバイスはパケットを送信も受信もしない。
開始	特定のデバイスからの広告パケットに応答し、接続を要求する。
広告	広告パケットを送信し、他のデバイスが広告パケットに応答して送信したパケットを処理する可能性がある。
接続	他の機器との接続において。
スキャニング	他のデバイスからの広告パケットをリッスンする。
アイソクロナス放送	アイソクロナスデータパケットをブロードキャストする。
同期	特定のデバイスから送信された特定の広告列車に属する定期アドバタイズリッスンする。

表2 -リンクレイヤー州

接続状態、2つの重要なデバイスの役割が定義される。セントラル（Central）の役割とペリフェラル（Peripheral）の役割である。接続を開始し、Initiating状態 Connection状態遷移するデバイスは、Central の役割を引き受ける。接続要求を受け入れ、Advertising状態 Connection状態遷移するデバイスは、Peripheral の役割を引き受ける。

例えば、アプリケーション使用するためにスマートフォンに測定値を送信する心拍モニターを考えてみよう。通常、スマートフォンはセントラル（中央）の役割を担い、心拍数モニターはペリフェラル（周辺）の役割を担う。スマートフォンは、その広告パケットをスキャンすることでモニターを検出し、通常はユーザーの関与のもと、モニターへの接続を開始する。接続が完了すると、心拍プロファイル仕様に定義された追加手順に従い、アプリケーションモニターに対し、接続を介して測定値の送信を開始するよう指示する。

状態マシンのインスタンスは、一度に1つの状態存在できない。リンクレイヤー実装は、同時に複数の状態マシンインスタンスをサポートしてもよい。

すべての役割と状態組み合わせが許されるわけではない。ブルートゥースコア仕様詳細がある。

7.4 チャンネルの選択

6.1 周波数帯域」で述べたように、Bluetooth LE 2.4 GHz 周波数帯域を 40 チャンネルに分割します。リンクレイヤーこれらのチャンネルがどのように使用されるかを制御し、これはBluetooth LE 通信に使用される全体的な方法（より正式には現在の物理チャンネル-これは7.7項「データトランスポートアーキテクチャ」でカバーされる）に依存します。

Bluetooth LE 様々な方法でスペクトラム拡散技術を使用し、複数のチャンネルを経由してデータを通信する。これにより、衝突の可能性を減らし、通信の信頼性を高めている。

Bluetooth LE 使われるスペクトラム拡散技術のよく知られた例として、アダプティブ周波数ホッピングがある。これは、パケット通信に使用される無線チャネルが一定間隔で変化するものである。チャネルは、チャネル選択アルゴリズムと、各チャネルを使用または未使用のいずれかに分類するチャネルマップと 呼ばれるデータテーブルを使用して選択されます。実装では、各チャネルの通信品質を監視することができ、あるチャネルが、おそらく他のソースからの干渉が原因で、パフォーマンスが悪いことが判明した場合、チャネル・マップを更新して、そのチャネルの分類を未使用に 設定することができ、これにより、このチャネルはアルゴリズムによって選択されなくなります。このようにして、チャネル選択アルゴリズムは、経験される条件に適応し、最も信頼性の高いパフォーマンスを得るために最適化されます。

無線チャンネルがどのように使用されるかは、Bluetooth LE 論理トランスポートと関連する物理チャンネルについて後述する際に更に説明される。

7.5 フィルタポリシー

リンクレイヤー、LE スタックの上位レイヤーが処理すべき無関係な PDU で煩わされないように、様々な基準を用いて受信パケットをフィルタリングする能力を有する。パケットをフィルタリングして破棄するか、さらなる処理のために選択するかを決定する際に適用される基準は、多数のリンクレイヤー・フィルタ・ポリシーによって定義され、実装される。リンクレイヤー広告状態、スキャン状態、開始状態、および定期的な同期確立状態のそれぞれについて、個別のフィルタポリシーがある。

フィルタポリシーは、異なるリンクレイヤー状態に対して定義された数のモードで動作する。デフォルトのモードでは、パケットフィルタリングは行われません。他のモードでは、多くの場合、フィルタアクセプトリストと呼ばれるデバイスアドレスのリストを使用します。これらの場合、アドレスフィルタアクセプトリストのメンバーあるデバイスからのパケットは、おそらくフィルタリングされない。詳細はブルートゥースコア仕様書を参照されたい。

アプリケーションは、HCIコマンドを使用して、フィルタアクセプタリストを入力し、異なるリンクレイヤー状態のフィルタポリシーモードを設定することができます。

デシジョンスキャンフィルターポリシーモードと呼ばれる特別なフィルターポリシーモードのセットが定義されており、その使用は決定ベースのアドバタイズフィルタリングフィルタリング(DBAF)と呼ばれます。 DBAF では、単にチェックするよりも高度なフィルタリング条件を使用できます。メンバーシップフィルタ受け入れリストを作成する必要があります。

DBAFモードは、スキャンフィルタポリシーにのみ適用され、プライマリチャネルで受信した特定のタイプの広告PDUにのみ適用される。決定走査フィルターモードによってもたらされる可能性のあるフィルタリングは、拡張アドバタイズ適用され、この件に関するより多くの情報は7.7.2.3.7決定ベースのアドバタイズフィルタリングある。

7.6アドバタイザーモニター

7.6.1 フィルタリングとプレゼンス

アドバタイジングはコネクションレス通信トランスポートとして使用できるが、おそらく最も一般的な用途はデバイスの発見を可能にすることだろう。

デバイス発見には、広告パケットのスキャンが含まれる。広告パケットの受信は、広告デバイスが存在することを示す役割を果たし、広告PDUのタイプによっては、デバイスが接続可能であることを示す場合もある。

アドバタイジング・パケットは LE コントローラによって処理され、詳細はリンクレイヤー仕様に定義される。スタックのHost レイヤーは、Host 送信されるイベントを使用して、アドバタイジング・パケットの到着とその内容を通知される。

デバイスは、20ミリ秒に1回から10秒に1回までアドバタイズできる。24 秒に 1 回、受信したパケットごとに HCI イベントを生成し、おそらくすべてのイベントがアプリケーション関数を呼び出すことになるため、アドバタイズは物理的な HCI トランスポート、Bluetooth LE Host 、そしてアプリケーション多くの負荷をかけることになります。幸い、これを回避する方法があります。

アドバタイズがデバイスの検出のみを目的として実行される場合、通常、パケットのコンテンツは変更されない。受信中のアドバタイジングパケットに関連するコールを受信したいアプリケーション、複数のHCIコマンドのいずれかを使用して、コントローラに指示する。これらのHCIコマンドによって、アプリケーション、Filter_Duplicates という適切な名前のHCIパラメータ設定することで、重複の受信を希望するかどうかを示すことができる。重複フィルタリングを指定すると、HCIイベントと関連するアプリケーション呼び出しは、広告デバイスごとに1回だけ発生する。

しかし、重複をフィルタリングすることには潜在的な欠点がある。重複をフィルタリングしない場合、アプリケーション通常、関心のあるデバイスがまだ範囲内にあるかどうかを知っている。アプリケーションそのデバイスの広告データの受信を停止した場合、そのデバイスはもう圏外にあると考えることができる。しかし、重複フィルタリングを有効にすると、HCIの広告イベントがないことは、デバイスが圏外になったことを示す指標ではなくなります。重複パケットをブロードキャストしており、それがフィルタリングされている可能性が高いからだ。

デバイスの存在を認識できなくなることは、接続を確立する際に特に問題となる。範囲内のデバイスをスキャンし、GUI上のリストから選択するようユーザーに提示するアプリケーション想像してほしい。ユーザーが選択すると、アプリケーション選択されたデバイスとの接続を要求する。接続が必要な場合、LE コントローラはまず高デューティ・サイクルのスキャンを実行しなければならない。これは、同じチャネルで接続要求を返信する前に、ターゲット・デバイスから広告パケットを受信できるようにするためです。高デューティ・サイクルは、広告パケットを迅速に受信するアグレッシブなスキャンであるが、使用エネルギーの点でコストがかかる。接続するデバイスがまだ範囲内にある場合は良いのですが、ユーザーが選択するまでの間に範囲外に出てしまった場合、この比較的高価なスキャン動作はエネルギーの無駄になります。

例えば、信号強度が低い場合、そのデバイスがアプリケーションユースケースにとって意味があるほど近くにないことを示す指標となり得るため、デバイスへの接続中アプリケーション見合わないこともある。つまり、技術的にはデバイスはまだ存在するかもしれないが、信号強度が低いため、デバイスと接続するためにスキャンすることは、実際にデバイスが圏外にある場合と同様にエネルギーの無駄になる。

アドバタイザーモニター機能、重複する広告パケットをフィルタリングすることができるが、デバイスがまだ存在しているかどうか、そのデバイスへの接続中保証するのに十分な信号強度かどうかを追跡する能力を失うことはない。

7.6.2 広告モニタリングの使用

LE コントローラーは、監視広告主リストと呼ばれるリストを管理する。アプリケーションは HCI コマンドを使用して、低 RSSI（信号強度）しきい値、高 RSSI しきい値、およびタイムアウト値とともに、関心のあるデバイスをリストに追加できます。アプリケーション、別のコマンドを使用して、広告主監視を有効または無効にすることもできます。

表3は、指定されたデバイスに対する広告主モニタリングの動作を決定するパラメータを説明する。

パラメータ	項目
アドレスタイプ	モニタするデバイスのアドレスアドレスタイプ。これらの2つのパラメータにより、コントローラはデバイスを識別し、監視することができます。
RSSI しきい値低	この監視対象デバイスからのすべての広告パケットのRSSIが、パラメータ示される期間、この値以下に留まる場合、信号の喪失が発生したという。これが発生すると、コントローラはHCI LE Monitor Advertisers Reportイベントを使用してhost 通知します。このデバイスの状態、Awaiting RSSI Highに設定される。
RSSI しきい値 High	この監視対象デバイスから受信した広告パケットのRSSIがこの値以上で、デバイスの状態「Awaiting RSSI High」である場合、コントローラはHCI LE Monitor Advertisers Reportイベントをhost 送信し、デバイスが範囲内にあることを通知する。このデバイスの状態、もはや高しきい値を超える RSSI を待っていないことを示すためにクリアまたはセットされ、信号の喪失を監視するために使用されるタイマーはリセットされる。
タイムアウト	信号の損失を監視するために使用される秒単位の時間。この時間内に RSSI の測定値が RSSI Threshold Lowパラメータ超えなければ、信号消失が発生したとみなされます。

表3 - 監視対象の広告主パラメータ

アドバタイザーモニター機能、重複広告をフィルタリングするようコントローラに指示されているかどうかに関係なく使用できるが、重複フィルタリングが有効になっているときに使用すると、明らかに最も有益である。

図10は、アドバタイザーモニター機能含むシナリオ例を示す。図の左側は、広告パケットを受信し、HCIコマンドを使用して広告モニタを設定し、HCIイベントを使用して、設定されたRSSIしきい値に基づいて、広告デバイスが範囲内および範囲外に移動することを示すシーケンス図である。右側は、デバイスの信号強度が変化し、その結果、状態変化し、HCIイベントが発生することを示している。

図10 -アドバタイザーモニター例

表4は、図10のラベル付き注目点を説明したものである。

ポイント	説明
A	スキャナのhost 、モニタできる広告デバイスの数をコントローラに問い合わせることから開始します。次に、host 、RSSI low、RSSI high、およびタイムアウト値(図示せず)とともに、デバイスをリストに追加する。最後に、host 、アドバタイザモニタを有効にするようコントローラに指示する。
B	この時点で、図は最初のデバイスが送信した広告パケットを示し始める。デバイスはこの時点より前にアドバタイズしていた可能性がありますが、パケットはここからしか表示されないことに注意してください。受信したパケットのRSSIは設定された低いしきい値よりも大きいため、各パケットを受信するたびに監視対象デバイスのタイマーはリセットされます。
C	ポイントCの次に受信した数個のパケットは、RSSIが低RSSIしきい値よりも低いため、タイマーが最後にリセットされたのはポイントCであり、タイマーはその時点から実行される。
D	一連の低 RSSI パケットが受信され、ポイント D でタイムアウトが発生する。コントローラは、LE Monitor Advertisers Report イベントを条件 == 0x00 で送信することで、信号の喪失状態をhost 示します。デバイスは現在、アドバタイザーモニター「高 RSSI 待機状態」にある。
E	点Eで、RSSIが低いしきい値を超えている一連のパケットの最初のものが受信される。このようなパケットごとにタイマーがリセットされる。
F	ポイント F で、RSSI 値が RSSI High しきい値を超える。host 、コントローラから送信された LE Monitor Advertisers Report イベント（条件 == 0x01 ）によって、モニタされたデバイスが十分に強い信号で範囲内に戻ったことが通知されます。デバイスは、もはや高 RSSI 待機状態。

表4 -アドバタイザーモニター例における注目点

7.7 データ・トランスポート・アーキテクチャ

ブルートゥースコア仕様アーキテクチャセクションは、Bluetoothデータトランスポートアーキテクチャを構成する多くの概念を定義しています。これらの概念の中で重要なものは、物理チャネル、物理リンク、論理リンク、論理トランスポートです。トポロジー、タイミング、信頼性、チャネルの使用など、特定の要件を持つ異なるアプリケーションタイプをサポートするために、特定の組み合わせが定義されています。

物理チャネルは、Bluetooth を使用するいくつかの異なる通信方法の 1 つを定義します。例えば、LE ピコネット物理チャネルを使用して、接続された 2 つのデバイス間で通信を行うことができます。あるいは、LE Advertising 物理チャネルは、1 つのデバイスから無制限の他のデバイスへのブロードキャスト無接続通信に使用することができます。LE 定周期物理チャネルもデータ・ブロードキャストに使用できるが、決定論的なタイム・スケジュールで定期的に使用される。オブザーバレシーバー）・デバイスはそのタイム・スケジュールを決定し、スキャン・スケジュールの同期に使用することができます。

物理リンクは、単一の物理チャネルをベースとし、電力制御の使用の有無など、そのリンクの特定の特性を指定する。

論理リンクとトランスポートは、特定の物理チャネルタイプを使用して、物理リンク上で特定のデータ通信要件をサポートする適切な手段を提供するように設計された様々なパラメータを持つ。

例えば、Bluetooth LE における信頼性の高い双方向のポイント・ツー・ポイント通信は、LE ピコネット物理チャネルに基づく物理リンク上で、制御データ用の LE-C リンク又はユーザ・データ用の LE-U リンクのいずれかによる LE 非同期接続指向論理（ACL）トランスポートを使用する。

一方、Bluetooth LE における信頼性の低い一方向ブロードキャスト通信は、LE Advertising Physical Channel に基づく物理リンク上で、制御データ用の ADVB-C リンク又はユーザ・データ用の ADVB-U リンクのいずれかによる LE Advertising Broadcast（ADVB）論理トランスポートを使用する。

7.8 論理トランスポート

7.8.1 LE ACL - LE 非同期接続指向論理トランスポート

7.8.1.1 基本

つのBluetooth LE 機器が接続される場合、それらは非同期接続指向の論理トランスポート（LE-ACL または単に ACL）を使用する。LE-ACL は、最も一般的に使用されるBluetooth LE 論理トランスポートの一つであり、コネクション指向のデータ通信を提供する。実際、ACL 接続は一般に単に接続と呼ばれる。

デバイスは、接続を要求するPDUで受信した広告パケットに応答することで、広告デバイスとの接続を確立することができる。要求には多くのパラメータが指定される。これらのパラメータの中には、アクセスアドレス、接続間隔、周辺レイテンシ、監視タイムアウト、チャネルマップ がある。

接続を要求するデバイスは、Standby状態 Initiating状態遷移し、Connection状態入り、Central の役割を引き受ける。もう一方のデバイスは、Advertising 状態から Connection 状態に遷移し、Peripheral の役割を担う。

接続間隔パラメータ、無線がこの接続のサービスに使用できる頻度をミリ秒単位で定義します。接続間隔が満了するたびに、接続イベントが開始され、この時点で、接続のセントラル・デバイスはパケットを送信することができます。所与の接続のための接続イベントは、各イベントでインクリメントされるカウンタ値である16ビットの識別子を持ちます。各接続イベントの開始時に、適用可能なチャネル選択アルゴリズムを使用して、使用する無線チャネルが選択されます。

監視タイムアウトパラメータ、リンクレイヤー失われたとみなされる前に、2つのリンクレイヤーを受信するまでの最大時間を指定する。

セントラルデバイスと同じ合意された接続パラメータを持つペリフェラルデバイスは、セントラルデバイスからの送信パケットをいつ、どのチャンネルで予期するかを知っているため、正確に同時にそのチャンネルでリッスンすることを選択し、セントラルからのパケットを受信することができます。セントラルのパケットの最後のビットを受信した後、ペリフェラルは短い時間（デフォルト150マイクロ秒）待機し、その後セントラルデバイスに返信することができます。パケット送信間の期間はフレーム間空間時間（IFS）と呼ばれることに注意してください。

その後、セントラルとペリフェラルは交互にパケットの送信と受信を行い、接続イベント中に実装で定義された数のパケットを交換することができる。Peripheralの動作は、ゼロでないPeripheral Latencyパラメータ値によって変更されることがある。

図11は、2つの接続イベント中の基本的なパケット交換を示しており、C>Pはセントラル・デバイスによるパケット送信を、P>Cはペリフェラルによるパケット送信を示している。

図 11 - LE-ACL 接続を介した基本的なパケット交換

LE ACL 接続を介して交換されるパケットには、リンクレイヤー制御手順に関連する LL データ PDU または LL 制御 PDU が含まれる。

7.8.1.2 注文と謝辞

LE-ACLは、データが正しい順序で処理され、パケットの受信が確認され、次のパケットに進むか、それとも前のパケットを再送信するかを決定するために使用されることを保証するシステムを組み込んでいる。

データパケットには3つの重要なフィールドがあり、通信の信頼性を高めるのに貢献している。これらのフィールドは、シーケンスナンバー（SN）、次に期待されるシーケンスナンバー（NESN）、モア・データ・フィールドと呼ばれる。これら3つのフィールドはすべてシングルビットフィールドであり、これらを使用することで、確認応答のシステムと、受信したパケットの順序が正しいかどうかをチェックする方法が提供される。

通信は、中央装置（装置A）がSNとNESNを共にゼロに設定したリンクレイヤー送信することから始まる。これ以降、パケット交換が行われるたびに、すべてが正常であれば、デバイスAによって設定されたSNフィールドの値はゼロと1の間で交互に変化します。従って、ペリフェラル・デバイス（デバイスB）は、次に受信するパケットのSN値がどうあるべきかを常に知っており、これをチェックする。

デバイスBがデバイスAから期待されるSN値のパケットを受信した場合、NESNを論理値NOT(SN)に設定したリンクレイヤー応答する。例えば、受信した SN 値が 1 であった場合、応答の NESN は 0 になります。

デバイス A が次のパケットで SN に使用する予定の値に NESN が設定された応答をデバイス B から受信すると、デバイス A はこれをデバイス B からの確認応答とみなし、最後に送信されたパケットを正しく受信したことを確認します。図12はこれを示している。

図12 -リンクレイヤーパケット交換の成功

デバイスBが間違ったSN値を持つパケットを受信した場合、そのパケットは前に受信したパケットの再送であるとみなし、そのパケットを承認するが、さらなる処理のためにスタックに上げることはしない。

デバイスAが、デバイスBからのリプライで予期しないNESN値を受信した場合、またはリプライをまったく受信しなかった場合、最初に使用したSN値と同じSN値でパケットを再送信する。通信が失敗したと判断するまでの再送回数については、コントローラの実装によって、さまざまなアルゴリズムを自由に実装できる。図13を参照。

図13 -リンクレイヤー再送

各パケットにはCRCフィールドが含まれ、暗号化されたパケットにはMICフィールドも含まれる。パケットを受信すると、リンクレイヤー CRCと、もしあればMICをチェックする。いずれかのチェックに失敗した場合、パケットは確認されず、一般的にパケットの送信元がパケットを再送することになる。図14を参照。

図14 -リンクレイヤー CRCエラー処理

7.8.1.3 ペリフェラル遅延

ペリフェラルは全ての接続イベント中、セントラルデバイスからのパケットをリッスンする必要はありません。ペリフェラルレイテンシパラメータ、ペリフェラルがリッスンする必要のない連続接続イベント数を定義します。これによりペリフェラルは電力を節約できます。

図15は、ペリフェラルのレイテンシが1であり、そのため代替接続イベントの間だけリッスンしているペリフェラルの動作を示す。セントラルは、ペリフェラルがリッスンしていないイベント中に送信するかもしれないが、そのようなパケットは受信されず、したがって確認されず、接続イベントを終了する。

図15 - ペリフェラル・レイテンシー＝1のACL接続

7.8.1.4 チャンネルの使用

LE-ACL は適応型周波数ホッピングとして知られる方式を採用している。各接続イベントの開始時に周波数ホッピングが発生し、チャネル選択アルゴリズムを用いて利用可能なチャネルのセットから無線チャネルが決定論的に選択される。その後、接続中の各デバイスは選択されたチャネルに切り替わり、時間の経過と一連の接続イベントにより、2.4GHz帯に分散して頻繁に変化する一連の異なるチャネルを使用して通信が行われるため、衝突が発生する確率が大幅に低下する。

Bluetooth LE で使用するために定義された 40 チャンネルのうち、37 チャンネル（汎用チャンネルと呼ばれる）は LE-ACL 接続で使用可能である。

ある環境では、Bluetooth無線チャネルの中には干渉の影響でうまく機能していないものがあるかもしれませんが、他のチャネルは確実に機能しています。時間の経過とともに、環境内の他の無線通信デバイスの出入りに応じて、信頼できるチャネルと信頼できないチャネルのリストが変化する可能性があります。

コネクション内のセントラル・デバイスは、汎用チャンネルを使用するものと使用しないものに分類するチャンネル・マップを保持する。このチャネル・マップは、どのチャネルが使用され、どのチャネルが使用されないかについての同じ情報をそれぞれが持つように、リンクレイヤー手順を使用してペリフェラルと共有されます。チャネル選択アルゴリズムは、未使用と指定されたチャネルが回避されることを保証する。

デフォルトでは、すべての汎用チャネルは使用済みと指定されるが、セントラル・デバイスは実装固有の技術を使用して、各チャネルがどの程度機能しているかをモニタすることができる。セントラル・デバイスが、1つ以上のチャネルが十分に機能していないと判断した場合、チャネル・マップのそれらの分類を未使用に更新することができる。逆に、以前は良好に動作していなかったチャネルが現在良好に動作していることが判明した場合、チャネルマップのその分類を使用済みに更新することができる。チャネルマップの更新はペリフェラルデバイスと共有される。

ペリフェラルはまた、それ自身のチャンネルモニタリングを実行し、間隔をおいて、各チャンネルのステータスを良、不良、不明と分類したチャンネルステータスレポートをセントラルデバイスに送信することができる。セントラルはチャネルマップのチャネル分類について、自身の無線状態とリモートペリフェラルデバイスが経験する無線状態の両方を考慮して決定することができます。

このようにして、Bluetooth LE デバイスは利用可能なチャネルの最適なサブセット使用することが可能になり、例えば、静的に割り当てられたチャネルを使用する他の無線技術と効果的に共存することができます。これがBluetooth適応型周波数ホッピングシステムの 適応的な側面です。

注:規制機関は、適応周波数ホッピングや関連用語をブルートゥースコア仕様異なる定義にする可能性がある。製品開発ライフサイクルの初期段階で、対象市場における周波数利用に関する規制を検討することが推奨される。セクション 18.Additional Resources」に 、規制に関するガイダンスを提供する BluetoothSIGの Regulatory Aspects Document へのリンクがあります。

図16は、テスト中に接続された2台のデバイスがどのようにチャネルを使用したかを示し、ISM 2.4GHzスペクトラムで無線がどのように使用されているかを示しています。チャートの下部には、チャネル・インデックスとMHz単位の周波数が表示されています。チャネルインデックスは、無線チャネルを参照する間接的な方法です。

図16 - チャネル間で通信を分散する適応型周波数ホッピング

7.8.1.5リンクレイヤー

リンクレイヤー仕様書には、多くの管理手順が規定されている。その一部を表5に示す。

制御手順	項目
コネクション・アップデート	セントラルデバイスまたはペリフェラルデバイスのどちらかが、接続パラメータ接続間隔、ペリフェラルレイテンシ、監視タイムアウトの変更を要求できるようにする。
チャンネルマップ更新	セントラルデバイスがその最新のチャンネルマップデータを接続されたペリフェラルに転送することを許可します。
暗号化	セントラルまたはペリフェラルのいずれかでパケットの暗号化を有効にする。
機能交換	セントラルまたはペリフェラルが、ビットマップフィールドとしてエンコードされた、各デバイスがサポートするリンクレイヤー機能の交換を開始できるようにする。
定期アドバタイズ同期転送	セントラルまたはペリフェラルのいずれかが、LE ACL 接続を介して、他方のデバイスに発見された定期アドバタイズ列車に関連する定期アドバタイズ[7]同期情報を転送できるようにする。
CIS作成手順	セントラルデバイスがペリフェラルとコネクテッドアイソクロナスストリーム（CIS）[8]を作成できるようにする。
電源制御リクエスト	一方のピアが他方のピアに送信電力レベルの調整を要求できるようにする。
チャンネル分類レポート	ペリフェラルがチャンネル分類データを接続されたセントラルに報告することを許可します。

表5 -リンクレイヤー管理手順の例

7.8.1.6 サブレート接続

サブレート接続とは、LE ACL 接続に追加プロパティを割り当て、いくつかの点で異なる動作をさせるものである。追加プロパティは、サブレート係数、サブレート・ベース・イベント、継続番号と呼ばれる。

サブレイティッド接続プロパティは、接続イベントの特定のサブセット、接続されたデバイスによってアクティブに使用され、無線は他の接続イベントでは使用されないことを示すメカニズムを提供する。従って、サブレート接続は、ACL接続間隔が短くても、デューティ・サイクルを低くすることができます。

図17は、サブレート接続に関する基本概念を示している。

図17-サブレート係数=5の基本的なサブレート接続

ここでは、5つの接続イベントのうち1つだけが使用されていることがわかる。残りの4つはスキップされるため、これらの接続イベント中は無線アクティビティがありません。この使用される接続イベントとスキップされる接続イベントの比率は、サブレート係数 パラメータ決定され、この例では5に設定されています。

無線機がリンクレイヤー送受信に使用される接続イベントは、サブレイヤー接続イベントと呼ばれる。

基本的なACL接続パラメータと、接続のサブレーティングを管理するパラメータとの関係を考えると、サブレーティングされた接続は、ACL接続イベントが発生する頻度を制御する接続間隔と、サブレーティングパラメータが適用された後に、それらのACL接続イベントが実際に使用される頻度を決定する有効接続間隔の両方を持つと考えることができる。

リンクレイヤー、異なるリンクレイヤー制御手順のセットを使用し、特に、サブレイテッドコネクションパラメータの更新手順は、一般的な制御更新手順とは異なる動作をします。特に、サブレイヤー接続パラメータの更新手順は、一般的なコントロール更新手順とは動作が異なります。サブレイヤー接続パラメータの変更はほぼ瞬時に適用されますが、一般的なパラメータ変更は反映されるまでにかなりの時間がかかります。従って、サブレイテッド接続の利点は、低デューティサイクルで消費電力が少ない持続的接続を確立でき、ユーザが気付くような遅延なしに、高デューティサイクルで高帯域幅の接続に切り替えられることである。この機能は、補聴器スマートフォンなど、いくつかのLE Audio シナリオで特に適用可能である。

ブルートゥースコア仕様バージョン5.3機能強化のペーパーには、サブレート接続をテーマとした章があり、さらなる情報源として推奨されています。

7.8.2 ADVB - LE広告放送

7.8.2.1 基本

LE 広告ブロードキャスト（または単に広告）はコネクションレス通信モードを提供する。データ転送や、接続するペリフェラル・デバイスの有無を示すために使用されます。

一般的に、広告パケットは、範囲内の任意のスキャンデバイスによって受信されることを意図しており、そのようなものとして、広告は、1対多のトポロジーで複数のスキャンデバイスに同時にデータを転送するために使用することができる。しかし、有向広告として知られる広告の特別な形式が定義されており、これは1つの広告デバイスから、そのBluetoothデバイスアドレス識別される1つの特定のスキャンデバイスへのデータの無接続通信を可能にします。

ADVB論理トランスポートに適用されるアドバタイジングは、アドバタイジングデバイスからスキャニングデバイスへの一方向のみのアプリケーションデータの通信をサポートするが、そのようなデバイスは、さらなる情報またはコネクションの形成を要求するPDUでアドバタイジングパケットに返信することができる。スキャニングデバイスが更なる情報を得るために返信する場合、そのデバイスはアクティブスキャニングを実行していると言われる。そうでない場合は、パッシブ・スキャンを行っていると言われる。

アドバタイジングは、受信者から確認応答が送信されないため、一般に信頼性の低いトランスポートと呼ばれる。

ブルートゥースコア仕様、以下の2つの広告手順が定義されている。 レガシーアドバタイズそして 拡張アドバタイズ.

7.8.2.2レガシーアドバタイズ

7.8.2.2.1 チャネルの使用とパケットサイズ

ADV_IND PDUタイプ(7.8.2.2.3レガシーアドバタイズ関連するPDUタイプ参照)を使用するレガシーアドバタイズ、6オクテットのヘッダーと最大31 オクテットのペイロードを持つ37オクテットの長さである。広告パケットの同一コピーは、プライマリ広告チャネルとして知られる番号37、38、39の最大3つの専用チャネルで、一度に1チャネルずつ、ある順序で送信される。

図18 -レガシーアドバタイズチャネル利用

7.8.2.2.2 スケジューリング

広告パケットの送信は、広告イベントが発生するたびに行われる。アドバタイジングイベントのスケジューリングはタイミングパラメータによって制御され、基本的なケースでは、他のアドバタイジングデバイスとのしつこい衝突を避けるために、意図的に少し不規則になっている。advDelayとして知られる値は、各広告イベントで0～10msの範囲の擬似ランダム値が割り当てられ、これは通常の広告間隔(advInterval)に追加されるので、広告イベントは時間的に乱される。図19は、ブルートゥースコア仕様第6巻パートBの図4.5を再現し、advDelayパラメータ効果を示している。

図19 - advDelayを使って時間的に摂動させた広告イベント

このように広告イベントをスケジューリングすることは、衝突を避けるのに役立つが、受信機が広告パケットを効率的に受信することが難しくなり、広告イベントの予測不可能なタイミングに対応するために、より高いRXデューティサイクルが必要となる。

7.8.2.2.3レガシーアドバタイズ関連する PDU タイプ

いくつかの PDU タイプがレガシーアドバタイズ使用するために定義されている。異なるタイプのPDUは、パケットが任意のスキャンデバイスに向けられる無指向性広告と、パケットが特定のデバイスに向けられる有指向性広告のために使用される。PDUタイプはまた、アクティブスキャンが許可されているかどうかを示し、受信者は更なるデータの要求を返信し、広告デバイスが接続可能かどうかを示す。全てのレガシーアドバタイズ、37、38、39 番のプライマリチャネルの 1 つ以上で行われ、LE 1M PHY のみを使用する。

表 6 にレガシーアドバタイズ PDU の一覧を示す。

PDU名	項目	チャンネル	PHY	送信者	スキャン可能	接続可能
ADV_IND	無指向性広告	プライマリー	LE 1M	ペリフェラル	Y	Y
ADV_DIRECT_IND	ダイレクト広告	プライマリー	LE 1M	ペリフェラル	N	Y
ADV_NONCONN_IND	無指向性、非連結性、非スキャンナブル広告	プライマリー	LE 1M	ペリフェラル	N	N
ADV_SCAN_IND	無指向性、スキャン可能な広告	プライマリー	LE 1M	ペリフェラル	Y	N
SCAN_REQ	スキャン要求	プライマリー	LE 1M	セントラル	該当なし	該当なし
SCAN_RSP	スキャン応答	プライマリー	LE 1M	ペリフェラル	該当なし	該当なし
CONNECT_IND	接続リクエスト	プライマリー	LE 1M	セントラル	該当なし	該当なし

表 6 -レガシーアドバタイズ PDU

ブルートゥースコア仕様リンクレイヤー 4.4節に、すべての広告PDUタイプの詳細が記載されている。

7.8.2.3拡張アドバタイズ

ブルートゥース・コア仕様バージョン5では、広告の実行方法に大きな変更が加えられた。広告、スキャン、接続中 8つの新しいPDUが追加され、新しい手順が定義された。この新しいアドバタイズ機能のセットは、総称して次のように呼ばれる。 拡張アドバタイズ.

拡張アドバタイズは、より大容量のデータをブロードキャストし、決定論的なスケジュールで広告を実行し、異なるコンフィギュレーションに支配された複数の異なる広告データセットを送信することを可能にする。また、コンテンションとデューティ・サイクルに関しても大きな改善が見られます。

拡張アドバタイズは、ADVBとPADVBの両方の論理トランスポートで使用される。

7.8.2.3.1 チャネルの使用とパケットサイズ

ラジオ・チャンネルは、レガシーアドバタイズ実施時の使用方法とは異なり、プライマリ広告チャンネル37、38、39はデータ量が少なく、汎用チャンネル0～36はデータ量が多い。

7.8.2.2レガシーアドバタイズ述べたように、レガシーアドバタイズ同じペイロードを3つの異なるプライマリ広告チャネルで最大3回送信する。拡張アドバタイズは、プライマリ・チャンネルから参照する小さなヘッダを付けて、ペイロード・データを1回だけ送信する。したがって、送信されるデータの総量は、レガシーアドバタイズ使用する同等の場合よりも少なくなり、実効デューティ・サイクルが短縮される。

図20 - コンテンションとデューティ・サイクルの低減

拡張アドバタイズでは、パケットの長さを255オクテットまで許容する。これは、ペイロードを0～36のチャンネル番号範囲の汎用チャンネルのいずれかにオフロードすることで実現されている。

図21 -拡張アドバタイズより大きな広告パケットとチャネルオフロードをサポート

拡張アドバタイズ行う場合、37、38、39番のプライマリ・チャンネルではヘッダーデータのみが送信される。これにはAuxPtrと呼ばれるフィールドが含まれる。

AuxPtrフィールドは、0〜36番のチャンネルセットから汎用チャンネルで送信されるペイロードを含む関連する補助パケットを参照する。AuxPtrは、補助パケットが送信されるチャネルを示す汎用チャネルのインデックスを含むので、受信者はそのチャネルがどこにあるかを知ることができる。汎用チャネル上で送信され、プライマリチャネル上のパケットからAuxPtrフィールドによって参照されるパケットは、従属パケットとして知られ、参照されるパケットは上位パケットとして知られる。

AuxPtrのチャネル・インデックス値の選択は実装に依存し、ブルートゥースコア仕様「衝突を避けるために十分なチャネル多様性を使用する」ことのみを推奨している。

7.8.2.3.2 パケット・チェイニング

アプリケーションさらに多くのデータ(最大1,650バイト)をブロードキャストする必要がある場合、コントローラは、データを断片化し、各パケットにデータのサブセット含むパケットをチェーンすることができる。各チェーンパケットは、AuxPtrヘッダーフィールドで次のチェーンを参照しながら、異なるチャネルで送信できる。図22はこれを示している。

図22-パケット・チェイニングによる拡張アドバタイズ

7.8.2.3.3 広告セット

レガシーアドバタイズ、広告のペイロードとパラメータが変化することを正式に規定しない。拡張アドバタイズは、複数の異なる広告データセットを持つための標準的なメカニズムを含む。

アドバタイジングセットは、与えられたパケットがどのセットに属するかを示すために使用されるIDを持ち、各セットは、アドバタイジング間隔や使用されるPDUタイプなどの独自のアドバタイジングパラメータを持つ。

異なるセットのスケジューリングと送信のタスクは、電力効率がはるかに低いHost駆動されるのではなく、コントローラ内のリンクレイヤー委ねられる。Host 、最初に広告セットとそれぞれのパラメータをコントローラに通知するだけでよいリンクレイヤー

7.8.2.3.4定期アドバタイズ

拡張アドバタイズには、決定論的なスケジューリングを使用する広告方法が含まれており、その詳細はスキャン・デバイスによって発見され、同期される可能性がある。これは 定期アドバタイズ.定期定期アドバタイズ別個の論理トランスポートとして定義されるため、7.8.3節「PADVB - LE定期アドバタイズ」で説明される。

7.8.2.3.5拡張アドバタイズ関連するPDUタイプ

拡張アドバタイズ使用するために、多くの PDU タイプが定義されている。表 7 に拡張アドバタイズ PDU の一覧を示す。

PDU名	項目	チャンネル	PHY	送信者
ADV_EXT_IND	拡張アドバタイズ	プライマリー	LE 1M、LE Coded	ペリフェラル
ADV_DECISION_IND。	決定PDU	プライマリー	LE 1M、LE Coded	ペリフェラル
AUX_ADV_IND	下位拡張アドバタイズ	汎用	LE 1M、LE 2M、LE Coded	ペリフェラル
AUX_CHAIN_IND	追加広告データ	汎用	LE 1M、LE 2M、LE Coded	ペリフェラル
AUX_SYNC_IND	定期アドバタイズ同期	周期的	LE 1M、LE 2M、LE Coded	ペリフェラル
AUX_SCAN_REQ	補助スキャン要求	汎用	LE 1M、LE 2M、LE Coded	セントラル
AUX_SCAN_RSP	補助スキャン応答	汎用	LE 1M、LE 2M、LE Coded	ペリフェラル
AUX_CONNECT_REQ	補助接続要求	汎用	LE 1M、LE 2M、LE Coded	セントラル
AUX_CONNECT_RSP	補助コネクト・レスポンス	汎用	LE 1M、LE 2M、LE Coded	ペリフェラル

表7拡張アドバタイズ PDU

ADV_EXT_IND、AUX_ADV_IND、AUX_SCAN_RSP、AUX_SYNC_IND、AUX_CHAIN_IND、AUX_CONNECT_RSP タイプの PDU のペイロードは、共通拡張アドバタイズ知られる同じフォーマットで定義される。これにはAuxPtrフィールドやAdvModeなどのフィールドが含まれる。AdvModeは、個別のPDUタイプではなく、広告モードの接続可能プロパティとスキャン可能プロパティを示すために2ビットを使用する。

ブルートゥースコア仕様リンクレイヤー 4.4節に、すべての広告PDUタイプの詳細が記載されている。

7.8.2.3.6 スケジューリング

拡張アドバタイズ 、拡張アドバタイズ 行われる。拡張アドバタイズ、アドバタイズイベントと同時に開始され、 AuxPtrフィールドを持つ上位パケットとそれに関連する下位パケットを含む。

7.8.2.3.7決定ベースのアドバタイズフィルタリング

注意力散漫

ADV_EXT_IND PDU を受信すると、スキャナは常に AuxPtr フィールドを追い、関連する下位 PDU (例えば AUX_ADV_IND PDU) をスキャンする。アプリケーションによっては、これは非効率的な動作となり、プライマリ・チャンネルのレシーバーパフォーマンスに悪影響を与えることがあります。

次のシナリオを考えてみよう：

スキャナは ADV_EXT_PDU を受信する。
スキャナは、AuxPtrフィールドの情報を使って、指示されたセカンダリ・チャンネルのスキャンに切り替える。
スキャナは期待通りに AUX_ADV_IND PDU を受信する。
拡張アドバタイズ PDUを受信するが、AdvDataペイロードフィールドをチェックする。

ここで起きたことは、ディストラクションと呼ばれる。拡張アドバタイズ PDUのペイロードがアプリケーション有用であるかどうかを、それをスキャンして評価のためにアプリケーション渡すことなしに事前に知る方法はなかった。また、AuxPtrで示されるセカンダリ・チャンネルでスキャンが行われている間、プライマリ・チャンネルはスキャンされなかったので、他のADV_EXT_IND PDUが見逃された可能性がある。このように、このような状況やアプリケーションによっては、注意散漫が問題になることがあります。

DBAFは注意散漫の問題を解決する。

DBAFと広告装置

DBAF が使用されている場合、広告デバイスは ADV_EXT_IND PDU の代わりに ADV_DECISION_IND PDU をプライマリチャネルに送信する。

図23 - ADV_DECISION_IND

図24は「Decision Data」フィールドを拡大したものである。

図 24 - ADV_DECISION_IND Decision Data フィールド

解決可能なタグフィールドは、そのアプリケーション属するPDUのラベルとして使用される、アプリケーションハッシュ値を含む。これは、スキャナがAuxPtrに従って、関連する補助PDUをスキャンすべきケースを識別するための簡単な方法を提供する。将来のプロファイルでは、解決可能なタグのハッシュ値を作成するために使用されるキー値をデバイス間で共有する方法を定義することが期待される。

その他の判断材料となるデータは、「任意データ」フィールドに含めることができる。

DBAFとスキャン装置

スキャンアプリケーション、関連する補助PDUについてセカンダリチャネルでスキャンするかどうかを決定するために、コントローラがADV_DECISION_PDUに対して評価しなければならない論理テストを策定することができる。テストは、ADV_DECISION_IND PDUのDecision Dataフィールドのデータ、または広告モードフィールドAdvModeなどの他のフィールドに適用できる。さらに、受信信号強度インジケータ（RSSI）を決定テストに含めることができる。

テスト要件は、アプリケーション呼び出すHCIコマンドを介してコントローラに伝えられる。テストはグループ化することができ、グループは論理AND演算または論理OR演算を含む比較的複雑な複合条件の要素を形成することができる。例えば

(グループ1テスト1) AND (グループ1テスト2) AND (グループ1テスト3)
(第1グループ) OR (第2グループ) OR (第3グループ) OR (第4グループ)

アプリケーション、使用する必要がある決定スキャンフィルタポリシーモードをコントローラに通知する。オプションは次のとおりです：

決定なしモード。このモードでは、決定PDUは無視される。
All-PDUsモード。すべての種類の広告 PDU が選択される。決定 PDU はhost指定するチェックの対象となる。その他の広告PDUは基本フィルタポリシーに従う。
デシジョン専用モード。決定PDUのみが選択される。これらはhost指定されたチェックを受ける。合格したものはHCI広告レポートでhost 報告される。失敗したものは破棄される。

7.8.2.4レガシーアドバタイズ拡張アドバタイズ比較

表8は、レガシーアドバタイズ拡張アドバタイズ比較をまとめたものである。

	レガシーアドバタイズ	拡張アドバタイズ
host 広告データの最大サイズ	31バイト	1,650バイト	拡張アドバタイズはフラグメンテーションをサポートしており、host 広告の最大データサイズを50倍大きくすることができる。
パケットあたりの最大host 広告データ	31バイト	254バイト	拡張拡張アドバタイズ PDUは、8倍大きな広告データフィールドをサポートする共通拡張アドバタイズ使用する。
TXチャンネル	37,38,39	0-39	拡張アドバタイズは、37 の汎用チャネルをセカンダリ広告チャネルとして使用する。ただし、ADV_EXT_IND PDU タイプは、一次広告チャネル（37,38,39）でのみ送信可能である。
PHYサポート	LE 1M	LE 1MLE 2M（ADV_EXT_IND PDU を除くLE Coded	ADV_EXT_IND PDU を除く全ての拡張アドバタイズ PDU は、3 つの LE PHY のいずれかを使用して伝送されるが、ADV_EXT_IND PDU は LE 1M またはLE Coded PHY を使用して伝送される。
最大アクティブ広告コンフィギュレーション	1	16	拡張アドバタイズは、広告デバイスが一度に最大16の異なる広告設定をサポートし、セットで定義された時間間隔に従って各広告セットの広告をインターリーブすることを可能にする広告セットを含みます。
コミュニケーション・タイプ	非同期	非同期同期	拡張アドバタイズ定期アドバタイズ送信機と受信機の間で広告データの時間同期通信を可能にします。

表8 レガシーと拡張アドバタイズ比較

7.8.3 PADVB - LE定期アドバタイズ放送

7.8.3.1 基本

ADVB 論理トランスポート(7.8.2 ADVB - LE Advertising Broadcast 参照)によって実行されるアドバタイジングは、アドバタイジングパケット送信のタイミングにある程度のランダム性を含む。持続的なパケット衝突を回避するために、広告イベントのスケジューリングに 0～10ms のランダムな遅延が意図的に挿入される。レガシーアドバタイズ実行する場合、これは広告が機能する唯一の方法である。

定期アドバタイズは、決定論的なスケジュールに従ってパケットを送信することを含み、他のデバイスがパケットのスキャンを広告デバイスのスケジュールに同期させるメカニズムを提供する。定期アドバタイズは常にスキャン不可能であり、接続不可能である。

定期アドバタイズは、スキャンを実行するためのエネルギー効率の高い方法を提供することで、オブザーバー・デバイスに利益をもたらすことができ、LE Audio 放送ソリューションの重要なコンポーネントである。

定期アドバタイズ間隔と呼ばれる一定間隔で行われ、アドバタイズデータのペイロードは変化する可能性がある。一連のAUX_SYNC_INDと関連するAUX_CHAIN_IND PDUは、定期アドバタイズ 形成すると言われる。

定期アドバタイズ、1つのAUX_SYNC_IND PDUが送信され、その後に、hostペイロードが断片化を必要とするかどうかに応じて、0個以上の AUX_CHAIN_IND PDUが続く。

AUX_ADV_IND PDUは、共通拡張アドバタイズ一部であり、チャネルとタイミング・オフセット情報を含むSyncInfoと呼ばれるフィールドを含む。

7.8.3.2 チャンネルの使用

定期アドバタイズは37の汎用広告チャンネルを使用する。チャンネルは、paEventCounterと呼ばれるイベントカウンターフィールドを入力とするチャンネル選択アルゴリズム#2を使用して、定期アドバタイズ開始時に選択される。このカウンタは、定期アドバタイズインクリメントされる。AUX_SYNC_IND PDU に関連するすべての補助 AUX_CHAIN_IND PDU は、実装固有のアルゴリズムを使用してチャネルが選択され、AuxPtr フィールドで指定される。図 25 を参照。

7.8.3.3 スケジューリング

定期アドバタイズ間隔は、指定された広告セットに対する定期アドバタイズ発生する頻度を決定する。これは、図25に示すように、AUX_SYNC_IND PDUの送信で始まり、0個以上の一連の AUX_CHAIN_IND PDUで続く。

図25 -定期アドバタイズ

図25は、異なるプライマリ広告チャネル上の複数のADV_EXT_IND PDUの可能性を1つのボックスで表して簡略化していることに注意。

7.8.3.4 同期の確立

スキャニング・デバイスは、2つの方法のいずれかで定期アドバタイズ同期することができる。AUX_ADV_IND PDU を走査し、SyncInfo フィールドの内容を使用して、使用される定期アドバタイズ間隔、タイミング・オフセット及びチャンネル情報を確立するか、又は AUX_ADV_IND PDU からこの情報を決定した別のデバイスから LE-ACL 接続を介してこの情報を受信する。この方法は定期アドバタイズ同期転送手順として知られている。

7.8.4PAwR - LE 応答付き定期アドバタイズ

7.8.4.1 基本

PAwR いくつかの点で定期アドバタイズ（PADVB）と似ている：

PADVBは、1つのデバイス（ブロードキャスター）から1つ以上の受信デバイス（オブザーバー）にデータを送信し、1対多の通信トポロジーを形成することがアプリケーション。PAwR同様である。
PAwR PADVBはどちらもコネクションレス通信方式を採用している。
広告パケットの送信は一定の間隔で周期的に行われ、どちらの場合もスケジュールのランダムな摂動はない。
オブザーバは、AUX_ADV_IND PDU から、または定期アドバタイズ同期転送（PAST）手順を使用して、ブロードキャスターが使用する定期的な送信スケジュールを確立することができる。

PAwR PADVBと以下のように異なる：

PADVB はブロードキャスターからオブザーバーへの一方向のデータ通信のみをサポートする。PAwR Observers はレスポンスパケットを Broadcaster に送り返すことができる。PAwR は双方向のコネクションレス通信メカニズムを提供する。
応答なしの 定期アドバタイズ (PADVB)の同期情報は、AUX_ADV_IND PDUのSyncInfoフィールドに含まれる。応答ありの 定期アドバタイズ PAwR)の同期情報は、AUX_ADV_IND PDUのSyncInfoフィールドとACADフィールドに含まれる。
PADVBブロードキャスターは、広告イベント内で送信をスケジュールする。PAwR ブロードキャスターは、一連の イベントとサブイベントで送信をスケジュールし、オブザーバーは、特定のサブイベントまたはサブイベントの間だけ聞くように同期していることが期待される。
PAwR ブロードキャスターは、送信タイムスロットを使用して、特定のデバイスに接続要求（AUX_CONNECT_REQ PDU）を送信し、そのデバイスとの LE-ACL 接続を確立することができる。PADVB にはこの機能はない。
応答のない定期アドバタイズ（PADVBアプリケーション、データは時々しか変化しない傾向がある。PAwR 、アプリケーションデータが頻繁に変化することを想定して設計されている。
PADVBでは、同じ広告セットに同期したすべてのオブザーバー・デバイスに、同じアプリケーションデータが配信されます。PAwR、異なるデータを各オブザーバデバイスまたはオブザーバデバイスのセットに配信することができます。

定期アドバタイズ同期転送（PAST）手順のサポートは、PADVBではオプションですが、PAwR必須です。

7.8.4.2 チャンネルの使用

チャネル選択はチャネル選択アルゴリズム#2を使用して達成され、定期アドバタイズ行われる(7.8.4.3 スケジューリング参照)。サブイベントで送信された PDU に対する応答は、同じチャネルを使用する。これには、AUX_SYNC_SUBEVENT_IND PDU に応答して送信される AUX_SYNC_SUBEVENT_RSP PDU と、AUX_CONNECT_REQ PDU に応答して送信される AUX_CONNECT_RSP PDU が含まれる。

7.8.4.3 スケジューリング

他の広告モードと同様に、活動はPAwR 場合、応答イベントPAwR イベント）を持つ定期アドバタイズ 知られているイベントで行われます。これらのイベントは一定の間隔で発生し、スケジューリングにランダムな変動はありません。イベントは、定期アドバタイズ間隔msごとに開始される。

各PAwR イベントはいくつかのサブイベントで構成され、広告パケットが送信されるのはサブイベント中である。Host イベントごとに最大128までのサブイベント数を設定する。サブイベントは定期アドバタイズサブイベント間隔ms ごとに開始する。Host 、HCI_LE_Set_Periodic_Advertising_Parameters V2（またはそれ以降）と呼ばれるHost （HCI）コマンドを使用して、イベントごとのサブイベント数と定期アドバタイズ間隔を設定します。

図 26 -PAwR イベントとサブイベントを参照。

図26 -PAwR イベントとサブイベント[9]

このパケットには通常AUX_SYNC_SUBEVENT_IND PDUが含まれるが、代わりにAUX_CONNECT_REQ PDUが含まれることもある。応答スロット遅延定期アドバタイズ Response Slot Delay)として知られる遅延の後、オブザーバーデバイスからの応答を受信するための一連のタイムスロットが、同じサブイベント内で予約される。AUX_SYNC_SUBEVENT_IND PDUに対する応答は、AUX_SYNC_SUBEVENT_RSP PDUで送られる。Host HCIコマンドHCI_LE_Set_Periodic_Advertising_Parametersで必要な応答スロット数を設定する。図27にPAwR サブイベントの構造を示す。

図27-応答スロットを持つPAwR サブイベント

7.8.4.4 同期の確立

7.8.4.4.1 全般

同期のプロセスは、Observerデバイスに、広告デバイスから送信される関連パケットを効率的にスキャンして受信するために必要な情報を提供する。PAwR場合、これには3つの側面がある：

Observerは、応答イベントを持つ定期アドバタイズ どれくらいの頻度で発生するか、また、そのようなイベントが次にいつ発生するかを知る必要がある。この情報は、定期アドバタイズ間隔と呼ばれるパラメータ、syncPacketWindowOffsetと呼ばれる計算値で提供される。
オブザーバーは、サブイベントについての情報を必要とする。サブイベントの発生頻度や、応答イベントを持つサブイベントの数などである定期アドバタイズ また、応答送信のために予約された、各サブイベント内のタイムスロットに関する詳細も知る必要がある。この情報は、Subevent_Interval、 Num_Subevents、Response_Slot_Delay、Response_Slot_Spacing、およびNum_Response_Slotsとして知られるパラメータに含まれる。
最後に、オブザーバーは、どのサブイベント番号をスキャンすべきか、どの応答スロットを使用すべきか、送信される応答パケットで使用するアクセスアドレス必要である。

(1)のイベントタイミング情報と(2)のサブイベント情報を取得することで、オブザーバはPAwR 広告トレインのイベントとサブイベントのタイミングパラメータと構造を完全に記述することができる。しかし、(3)の情報があって初めて、関連性のあるデータを含むと予想されるパケットのみを受信するようにスキャンをスケジューリングし、応答パケットの送信をスケジューリングすることができる。

(1)と(2)は、ブルートゥースコア仕様定義されているように、PAwR 論理トランスポートによって処理される。このレベルの同期情報を取得するために使用できる2つの手順がある。この2つの手順については、7.8.4.4.2定期アドバタイズ同期情報のスキャンと、7.8.4.4.3定期アドバタイズ同期転送(PAST)で説明する。

(3)は、アプリケーション層によって対処されなければならず、電子棚ラベルESL）プロファイルなど、適用可能なBluetoothプロファイル仕様で定義される場合があります。

7.8.4.4.2定期アドバタイズ同期情報のスキャン

PAwR PADVBはそれぞれ、スキャニングによる定期アドバタイズ同期情報の取得に同様の手順を用いている。

PAwR PADVBの両方で、Observerはセカンダリ広告チャネルで送信されたAUX_ADV_INDパケットをスキャンする。AUX_ADV_INDはSyncInfoフィールドを含む。SyncInfoフィールドには、定期アドバタイズ間隔値と、syncPacketWindowOffsetと呼ばれる変数を計算するためのいくつかのデータ項目が含まれる。これら2つの値を取得することで、Observerは、7.8.4.4.1 Generalの(1)に従って、応答イベントを持つ定期アドバタイズ いつ発生するかを計算することができる。

PAwR また、同期手順を完了する前に、7.8.4.4.1一般の(2)に従って、サブイベントと応答スロットに関する情報を必要とする。この情報は、定期アドバタイズ間隔が取得されたのと同じAUX_ADV_IND PDUにあるが、PDUの追加コントローラ広告情報(ACAD)フィールドにある定期アドバタイズ応答タイミング情報と呼ばれる広告データ型(AD型)にある。

7.8.4.4.3 同期転送(PAS定期アドバタイズ )

PAST 手順を使用する場合、接続を介して同期パラメータを渡すデバイスが、他のデバイスに代わってスキャンすることにより、最初に同期パラメータを取得することがある。しかしPAwR の場合、PAST のサポートは必須であるため、PAwR ブロードキャスターは LE ACL 接続を介して必要な同期データをオブザーバーに渡すことができる。この方法を取る場合、どちらのデバイスも AUX_ADV_IND PDU のスキャンは必要ない。

7.8.4.4.4 サブイベントの同期と応答スロットの割り当て

サブイベントの同期は、オブザーバーデバイスがスキャンを実行すべきサブイベントを、オブザーバーデバイスに示すことに関係する。つまたは複数のオブザーバーデバイスは、同じサブイベントに同期することができる。個々のObserverは、1つまたは複数のサブイベント中に受信するように同期されるかもしれない。

さらに、オブザーバーが応答PDUを送ることができるためには、どのサブイベント応答スロットを使用するかを決定するための何らかの根拠が必要である。

いずれもアプリケーション層の責任である。

7.8.5 LE BIS および LE CIS - 非同期通信

7.8.5.1 基本

アイソクロナス通信は、Bluetooth LE 使用してデバイス間で時間的制約のあるデータを転送する方法を提供します。同じソースから異なる時間にデータを受信する複数のシンク・デバイスが、そのデータの処理を同期することを可能にするメカニズムを提供します。LE Audio はアイソクロナス通信を使用します。

アイソクロナス通信を使用する場合、データには時間的な有効期間があり、その期間が終了すると期限切れとなる。まだ送信されていない期限切れデータは破棄される。つまり、デバイスが受信するデータは、プロファイルで指定された有効期限と許容可能なレイテンシに関するルールに従ってのみ有効であることを意味します。

データは等時性ストリームで転送され、ストリームは等時性グループに属する。デバイスは、受信したパケットを同時に処理する前に、同じグループのメンバーであるすべてのストリームが関連するパケットを配信する機会を持てるように、一定時間待機する。例えば、ステレオ音楽は、左ステレオチャンネル用と右ステレオチャンネル用の 2つのストリームを使用して配信されます。この2つのストリームは同じグループのメンバーであるため、2つのストリームから受信したパケットのレンダリングは同時に行われ、ユーザーは意図したとおりにステレオ音楽を聴くことができます。

LE Isochronous 物理チャネルを使用する 2 つの論理トランスポートが定義されている。コネクテッド Isochronous ストリーム（LE CIS または単にCIS）はコネクション指向の通信を使用し、データの双方向転送をサポートする。ブロードキャスト Isochronous ストリーム（LE BIS または単にBIS）はコネクションレス・ブロードキャスト通信を使用し、データの単方向通信を提供する。

7.8.5.2 接続された非同期ストリーム

7.8.5.2.1 CISの概要

単一の CIS ストリームは、接続された 2 つのデバイス間でポイント・ツー・ポイントの等時性通信を提供し、CIS PDU として知られるリンクレイヤー PDU でデータを転送する。LE-CIS（CIS）論理トランスポートは、図 28 図 28 のデータ・トランスポート・アーキテクチャ全体の中に描かれている。

図 28 - ブルートゥース・データ・トランスポート・アーキテクチャにおける LE-CIS

LE-S と LE-F の 2 つの論理リンクが定義され、フレームなし（LE-S）とフレームあり（LE-F）の両方のデータをサポートする。LE-S と LE-F の使い分けは Isochronous Adaptation Layer の関心事である。

CIS ストリームは LE 等時性物理チャネルを使用し、Bluetooth LE PHY のいずれかを使用することができる。

双方向通信はCISによってサポートされ、確認応答プロトコルが使用される。

CISストリームは、CIG（Connected Isochronous Groups）と呼ばれるグループのメンバーであり、各グループは1つ以上のCISを含むことができる。図29を参照。

CIG ごとに最大 31 の CIS が存在する可能性がある。セントラル・デバイスは複数の CIG を作成することができる。しかし、利用可能な通信時間や他の実装の詳細によって、これらの制限より低い値になることがよくあります。

図29 - 2つのCISを含むCIG

7.8.5.2.2 チャンネルの使用

コネクテッド・アイソクロナスストリームは、チャネル選択アルゴリズム#2による適応型周波数ホッピングを使用する。

7.8.5.2.3 スケジューリング

CIGとそのメンバー CISのスケジューリングは、CIGイベント、CISイベント、サブイベントのシステムによって管理される。

CIG イベントは、CIG に属する CIS 全体にわたるアクティビティのスケジューリングの開始を通知するもので、グループ内の最初の CIS のアンカー・ポイントで発生する。CIGイベントは、ISO_Intervalと呼ばれるパラメータ指定された間隔で発生します。

各CISイベントは1つ以上のサブイベントに分割される。使用中のサブイベントの数は、NSEと呼ばれるパラメータストリームで示される。接続されたアイソクロナスストリームでは、図30に示すように、サブイベント中にセントラルが1回送信（T）し、ペリフェラルが応答（R）する。サブイベントの間隔は、Sub_Intervalと呼ばれるCISパラメータ指定される持続時間によって区切られる。Sub_Intervalは、CISイベントごとにサブイベントが1つしかない場合は常にゼロに設定され、そうでない場合はISO Intervalより小さい400マイクロ秒以上に設定されます。

なお、チャンネルはサブイベントごとに変更される。

各 CIS は、CIG イベント中に順次サービスされることもあれば、異なる CIS のサブイベントがインターリーブされることもあります。図 30 に、3 つの CIS を含み、各 CIS が順次サービスされる CIG の例を示します。

図30 - CISイベントとサブイベント

各CISには、フラッシュタイムアウト（FT）やバースト番号（BN）など、サブイベント数（NSE）以外にも重要なパラメータがある。

各ペイロード(例えば、LC3[10]のようなオーディオコーデックによって出力されるオーディオデータのチャンク)は、正常に伝送される(確認応答によって示される)最大数の CIS イベントが与えられ、これは FTパラメータ指定される。試行は、そのような各 CIS イベントの各サブイベントで行うことができ、FT イベント内で成功しない場合、パケットはフラッシュされる(破棄される)。異なるデータ（すなわち、ペイロード）を含む複数のPDUが同時に利用可能な場合があり、CISは、同じCISイベント中に複数の異なるPDUを送信することを許可する。各 CIS イベントでサービス可能な異なる PDU の数は、バースト番号（BN）パラメータ指定される。

7.8.5.2.4 同期処理

CIG は、CIG_Sync_Delay と呼ばれるタイミング・パラメータ持ちます。同じ CIG 内の CIS はそれぞれ、CIS_Sync_Delay と呼ばれるパラメータ持ち、これは、グループ内のすべてのストリームにわたる、レシーバによるアイソクロナスデータ処理（通常は、オーディオレンダリング）の同期に使用される。受信機は、受信したデータをレンダリングする前に、このパラメータ示された時間だけ待機する。

図31 - CIGにおけるCISデータの同期レンダリング

図 31 に示すように、各ストリームは異なる CIS_Sync_Delay 値を持つ。CIG 内の最初の CIS ストリームでは、グループ・レベルのパラメータ CIG_Sync_Delay に設定される。CIS_Sync_Delay は、グループ内の他のストリームごとに、徐々に低い値に設定される。これは、グループ内の早い段階でサービスされたストリームから受信するデバイスは、グループのCISイベント処理の遅い段階で送信されたパケットを受信するデバイスよりも、受信したパケットの内容をレンダリングするまでに長く待たなければならないことを意味する。プロファイルのような上位レイヤの仕様は、ローカル処理の遅延を考慮できるように、データがレンダリングされるべき時間の計算に使用するために、さらなるプレゼンテーション遅延の使用を規定することができる。この段階的な遅延システムの正味は、各シンクデバイスが受信したデータを同時に処理することである。

7.8.5.2.5 CISストリーム作成

接続されたアイソクロナスストリームを確立するには、まずACL接続を作成する必要がある。この接続には2つの目的がある。第一に、リンクレイヤー制御PDUの交換を可能にする。次に、ストリームが確立された後、CISイベントをスケジュールするためのタイミング基準点を提供する。

セントラルデバイスは常に CIS を作成する手順を開始する。これは、LL_CIS_REQ PDUと呼ばれるリンクレイヤー制御PDUを送信することによって行われる。すべてが順調であれば、ペリフェラルは LL_CIS_RSP PDU で返信し、その後セントラルが LL_CIS_IND PDU を送信したときにストリームが確立されたとみなされる。このPDUには、CISイベントのタイミングとレンダリング前に適用する遅延を決定する重要なパラメータが含まれている。具体的には、CIS_Offset は、ACLアンカーポイント(接続イベントで最初のパケットが送信される時間)と、ストリームの最初のCISイベントとの間のマイクロ秒単位のオフセットを提供する。CIG_Sync_Delay には、CIG 全体の同期遅延値がマイクロ秒単位で格納され、CIS_Sync_Delay には、このストリームで使用される同期遅延値が格納される。

ストリームが作成された後、ストリームは、その作成に使用されたACL接続とは無関係に、またそれと並行して実行される。しかし、ACL接続が終了すると、関連するCISも終了しなければならない。

7.8.5.2.6 CIS暗号化

CISが使用するリンクは、2つのピアデバイスがペアリングされている場合、暗号化されることがある。

7.8.5.3 非同期ストリームのブロードキャスト

7.8.5.3.1 BISの概要

BISストリームは、1つのトランスミッター多数のレシーバー機器との間でブロードキャスト同時通信を提供する。データは、BIS データ PDU として知られるリンクレイヤー PDU で伝送される。制御情報はBIS 制御 PDU で伝送される。

LE-BIS（BIS）論理トランスポートは、図 32 のデータ・トランスポート・アーキテクチャ全体の中に描かれている。

図 32 - ブルートゥース・データ・トランスポート・アーキテクチャにおける LE-BIS

BIS上のデータ・ブロードキャストは、それに応じて定義されたLE-SとLE-Fの論理リンク・タイプにより、フレーム化またはフレーム化されていない場合がある。LEB-C論理リンクは制御情報を伝送する。

BIS ストリームは LE 等時性物理チャネルを使用し、Bluetooth LE PHY のいずれかを使用する。

BISストリームは、Broadcast Isochronous Groups（BIG）と呼ばれるグループのメンバであり、各グループには1つまたは複数のBISが含まれる。図 33 を参照。

図33 - 2つのBISを含むBIG

1つのBIGにつき最大31のBISが存在する可能性がある。セントラル・デバイスは複数の BIG を作成できます。しかし、利用可能な通信時間や他の実装の詳細によって、これらの制限より低い値になることがよくあります。

BISがサポートするのは単方向通信のみである。

CISとは対照的に、BISには確認応答プロトコルが組み込まれていない。このため、BISトランスポートは本質的に信頼性が低い。しかし、これに対抗するために、無条件のパケット再送システムが使用される。BISは、通信が一方向であるため、（CISの場合のように）ペリフェラル応答用にスロットを確保する必要がない。従って、与えられた放送時間の間に、2倍の数のサブイベントが送信のためにスケジュールされる可能性があり、信頼性を向上させる再送信の機会が増える。さらに、再送信は異なるサブイベントで送信されるため、それらは異なるチャネルで送信される。選択されたチャネルは、前回の送信から少なくとも6MHz離れていなければならず、これは特定のチャネルでの干渉によるパケット損失の可能性を軽減するのに役立ちます。

7.8.5.3.2 チャンネルの使用

ブロードキャスト・アイソクロナスストリームは、チャネル選択アルゴリズム#2による適応型周波数ホッピングを使用する。

7.8.5.3.3 スケジューリング

BIGとそのメンバー BISのスケジューリングは、BIGイベント、BISイベント、およびサブイベントのシステムによって管理される。さらに、BIG全体に関連する制御PDUの送信のために、特別な制御サブイベントが定義される。

BIGイベントは、BIGに属するBISにわたるアクティビティのスケジューリングの開始を通知する。BISイベントは、BIGの開始点（BIGアンカー・ポイントと呼ばれる）から、BIS_Spacingと呼ばれるBIGのパラメータ指定された値の倍数の間隔で開始する。

各BISイベントは1つ以上のサブイベントに分割される。使用中のサブイベントの数は、NSEと呼ばれるパラメータストリームで示される。サブイベントの間、放送事業者は1つのパケットを送信する。通信は単方向であり、パケットを受信する必要はない。サブイベントは、Sub_Intervalと呼ばれるBIGパラメータ指定される持続時間によって間隔を置かれる。

接続されたアイソクロナスグループごとに、BIG内のBISイベントのスケジューリングはシーケンシャルでもインターリーブでもよい。

BIGイベントには、常にBIGの最後のサブイベントとしてスケジュールされるコントロールのサブイベントが含まれることがある。

なお、チャンネルはサブイベントごとに変更される。

図 28 に、BIG と BIS のイベントとサブイベントの例を示す。BIGイベント#1の終わりにBIG制御サブイベント（Tcと指定）が送信されることに注意。

図 34 - BIG/BIS イベント・スケジューリング

7.8.5.3.4 同期処理

BIGにおけるブロードキャスト・アイソクロナスストリーム間のデータの同期処理は、接続されたアイソクロナス通信で使用されるアプローチと同様の方法で達成される。受信者は、BIGとその全体的なパラメータに関する情報を所有し、どのストリームを受信することを選択したかを知っている。BIGのタイミングパラメータは、すべてのストリームに一様に適用される。全体的なBIG_Sync_Delay値とBIS_Spacingパラメータ使用することで、受信者は、受信したデータを処理する前に、他のストリームと同期するように待機する時間を計算することができる。

7.8.5.3.5 BISストリーム作成

デバイスがBIS内でブロードキャストされたパケットを受信し、同じBIGのメンバーである他のストリームを受信している他のデバイスと同時に、そのようなパケットのコンテンツをレンダリングまたは処理できるようにするには、デバイスはまず、BISを定義するBIGとパラメータ（含まれるストリームの数、各ストリームに関連するイベント間およびサブイベント間の間隔、タイミングアンカーポイントを計算するためのタイミングオフセット情報など）を検出する必要があります。これをサポートするために、放送事業者は、必要なパラメータを通信するために、定期アドバタイズ使用する。BIGInfoとして知られる複合フィールドは、ACAD（Additional Controller Advertising Data）フィールド内のAUX_SYNC_IND PDUでブロードキャストされ、必要なデータを含む。

BIGInfo を受信する方法は2つある。最初の場合、レシーバー、定義された手順を使用して、定期アドバタイズ列車（7.8.3.1 基本参照）に直接同期し、AUX_SYNC_IND PDUを受信し、ACAD内からBIGInfoを抽出しなければならない。しかし、定期アドバタイズスキャンと同期は、消費電力の点で高価な手順となります。そのため、2つ目のケースでは、デバイスは、定期アドバタイズ列車を検出して同期する行為を、別のデバイス（通常は、より大きな電力リソースを持つデバイス）に委任することができる。BIGInfoを取得した後、スキャンを委任されたデバイスは、より効率的なACL接続を介して、ブロードキャスト・アイソクロナス・ストリームの受信を希望するデバイスにこの情報を渡します。これは、定期アドバタイズ同期転送（PAST）と呼ばれる手順を使用して達成される。

7.8.5.3.6 BIG暗号化

BIGは暗号化されていてもよい。この場合、その BIS を受信するデバイスがブロードキャスト・デバイスとペアリングされている必要はない。その代わりに、暗号化キーの導出に使用されるパラメータ配布する必要がある。これは、帯域外で実行することも、上位プロファイルに記載された手順に従うこともできる。

7.8.5.4 再送信と信頼性

信頼性は、BISまたはCISストリームの連続するサブイベント内で同一パケットを再送することで向上する。BISの場合、再送は無条件に行われるが、CISの場合はペリフェラルが送信を確認しなかった場合に行われる。

BISの場合、（CISの場合のように）ペリフェラル応答用にスロットを確保する必要がないため、一定量のエアタイム中に2倍の数のサブイベントが送信のためにスケジュールされる可能性があり、信頼性を高める再送信の機会が増える。

再送信は、異なるサブイベントを占有するため、異なるチャネルで送信され、選択されたチャネルは、最後の送信から少なくとも6MHzでなければならない。これは、特定のチャンネルでの干渉によるパケットロスの可能性を軽減するのに役立つ。

8.Bluetooth^® Channel Sounding

8.1Channel Sounding入門

BluetoothChannel Sounding 、Bluetooth LE コントローラーのオプション機能です。使用すると、アプリケーションリモートデバイスとの現在の距離を計算するためのデータを生成します。リモートデバイスもchannel sounding 使用し、最初のデバイスとの一連の無線信号交換に参加します。

BluetoothChannel Sounding 、信号強度（Received Signal Strength Indicator、RSSI）を距離の代用として使用する方法よりも、より正確で信頼性が高く、大幅に安全です。BluetoothChannel Sounding 初期の実装では、最大100mの距離で±20cmの精度を達成することが実証されています。RSSIに基づく距離推定は、例えば数メートル以上の距離では特に劣り、信頼性に欠ける。また、固有のセキュリティもないため、使用方法には細心の注意が必要です。

ブルートゥースコア仕様、BluetoothChannel Sounding生成されたデータを使用して距離を計算するアルゴリズムを提供しないことに注意する必要があります。これはアプリケーション層の責任です（8.14 距離測定アプリケーションを参照）。

Channel Sounding 、キーレス・エントリーやイグニッション・システムなど、車のような貴重品を保護するために十分なセキュリティが必要なアプリケーションで、距離を安全に計算できるように設計されている。

8.2 デバイスの役割

BluetoothChannel Sounding 、2つのデバイスの役割を定義しています。イニシエータ イニシエータはchannel sounding 手順を開始するデバイスで、最終的に生成したデータをアプリケーション渡し、そこで距離値を計算します。もう1つのデバイスは リフレクタ.すべての場合において、channel sounding 、イニシエータ信号を送信し、リフレクタそれ自身の送信でそれに返信することを含む。

図35-CS中のイニシエータリフレクタ間の信号交換

実際、後述するように、完全なchannel sounding 手順には、さまざまな種類の、さまざまなシーケンスによる一連の送信が含まれる。

8.3 データトランスポートアーキテクチャにおけるBluetoothChannel Sounding

Bluetooth LE データ・トランスポート・アーキテクチャは、7.7 データ・トランスポート・アーキテクチャで紹介されている。Channel Sounding 、図 36 に他のトランスポートの例と共に示すように、物理チャネルと物理リンクから構成される。

図36 - データ・トランスポート・アーキテクチャにおけるBluetoothChannel Sounding

8.4 ブルートゥース2Channel Sounding 法

Channel Sounding 興味深い理由はたくさんある。しかし、ブルートゥースコア仕様アプリケーション 2つの異なる距離測定方法が定義されており、2つの方法のどちらか一方を使用するか、または最大限のセキュリティを確保するために両方の方法を組み合わせて使用することができます。この2つの方式は、位相ベース測距 PBR）」と「ラウンドトリップ・タイミングRTT）」と呼ばれ、それぞれの基本的な理論について次に説明する。セキュリティについてはセクション8.13「セキュリティ」で詳しく述べる。

8.4.1位相ベース測距

PBR 、無線伝送が一連の波で構成され、波の周期として知られる各波の物理的な長さは、伝送周波数が変化しない限り一定であるという事実を利用する。

図37 - 2つの波のサイクル（それぞれ波長が示されている

波長の何分の一かは位相と呼ばれる量で表される。位相は角度（度またはラジアン）で表されます。信号の波長と位相がPBR 動作の中心にある。

図38は、波周期内のいくつかの点をマークし、その位置に対応する位相値をラジアン単位で示したものである。

図38 - 位相値の例

信号の波長と、イニシエータ内のレシーバー測定された位相値だけでは、2つのデバイス間の距離を計算することはできない。そこでPBR 、それぞれ異なる周波数（f1とf2）を持ち、したがってそれぞれ異なる波長を持つ2つの異なる信号を交換することによって機能する。

イニシエータ周波数f1で送信する。リフレクタこの送信を受信し、同じ周波数でイニシエータ送り返す。イニシエータ応答送信の位相(p1)を測定し、それを記録する。次に、イニシエータ周波数f2で別のchannel sounding 信号を送信する。再び、リフレクタ同じ周波数f2で同様の送信で応答し、イニシエータ応答を受信した時点の位相（p2）を測定する。

図39-周波数f1での最初のPBR 信号交換

図40-周波数f2での2回目のPBR 信号交換

2channel sounding 信号で測定された位相値の差（p2 - p1）から、簡単な数学を使って2つの装置間の距離を推測することができます。

実際には、BluetoothがPBR 使用する方法は、ここで説明したものよりももう少し複雑だが、その核となるのはこの基本的な方法論である。

しかし、距離の計算に位相値を使うには複雑な問題がある。位相値は、信号の複数の波周期に沿って測定される場合、周期的である。ある波周期で測定すると、0ラジアンから2πラジアン（0度から360度）までのすべての値を通過します。しかし、信号の次の波周期では、位相は再び0ラジアンから始まり、もう一度2πラジアンまでのすべての値を通過する。これが波の周期ごとに繰り返される。図41にこの周期パターンを示す。

図41-位相値の周期性

PBR文脈では、これは結果をもたらす。位相値はデバイス間の距離によって変化します。しかし、ある物理的距離では、位相値は繰り返され始めます。その結果、同じ位相差値によって複数の距離が暗示される可能性があります。これは距離の曖昧性として知られています。幸い、BluetoothChannel Sounding design 、8.10 チャネルとチャネル選択で説明するように、実際にはこの問題は発生しません。

8.4.2 往復のタイミング

無線信号は光速で伝わる。RTT 法では、イニシエータリフレクタ信号の往復にかかる時間を測定し、リフレクタ受信した信号を処理し、応答を作成して送信するのに必要な時間を考慮する。距離は、測定された機器間の往復時間に光速を掛け、その結果を2で割ることで計算できる。

図42 -RTT 送信とタイミングポイント

図42はRTT パケットの交換を表している。緑色の点線( ---- )は、2つの信号のどちらも空中にない経過時間を表す。タイムラインには4つのポイントがマークされており、表9で説明されている。

インスタント・イン・タイム	説明
_ToDA	デバイスAからの出発時間。これは、デバイスAによって信号が空中で送信された時間である。
_ToAB	機器Bに到着した時間。これは、信号が機器Bのアンテナに到着した時間です。
_ToDB	デバイスBからの出発時間。これはデバイスBが空中で送信した時間である。
_ToAA	機器A到着時刻。これは、機器Bからの信号が機器Aのアンテナで受信された時刻です。

表9 -RTT タイミングインスタント

往復時間、RTT 、図42に描かれているタイミング・インスタントの観点から、以下のように表すことができる：

RTT = 2 * ToF = (_ToAA-_ToDA) - (_ToDB-_ToAB)

この用語はリフレクタターンアラウンドタイムである。イニシエータ、送信してからリフレクタ応答を受信するまでの経過時間からこの値を引く。しかし、イニシエータ、リフレクタイニシエータ信号を処理して応答を返すまでにかかった時間をどうやって知るのだろうか。

答えは簡単だ。リフレクタかかる時間は、Channel Sounding 始まる前に2つの機器の間で合意された一定の時間である。

実際、Channel Sounding 開始する前に、一連の手順を実行しなければならない。リンクレイヤー仕様では、制御手順のコレクションを定義しており、その多くがChannel Sounding設定と開始に関するものである。

8.5Channel Sounding リンクレイヤー制御手順

channel sounding開始するためには、2 つのデバイスは最初に LE-ACL 接続を確立しなければならない（7.8.1 LE ACL - LE 非同期コネクション・オリエンテッド・ロジカルトランスポート参照）。channel sounding 制御手順が接続を利用する前に、リンク上で暗号化が有効でなければならず、従って 2 つのchannel sounding ペアリングされている必要がある。

2つの機器間の暗号化された接続が確立されると、以下のリンクレイヤー制御手順が実行される：

Channel Sounding
Channel Sounding 能力交換
Channel Sounding
モード0FAEテーブル・リクエスト
Channel Sounding

8.5.1Channel Sounding

Channel Sounding 、Bluetooth LE の他の側面には見られない独自のセキュリティ機能が数多くあります。そのうちのいくつかは、初期化ベクタ（CS_IV）、初期化ノンス（CS_IN）、パーソナライゼーション・ベクタ（CS_PV）と呼ばれる 3 つの数値パラメータに依存しています。

Channel Sounding 手順の間、2 つのデバイスの各々が 3 つのセキュリパラメータそれぞれの値を生成し、暗号化された LE-ACL 接続を介して相手デバイスに渡す。その後、3 種類の値の各ペアが各デバイスによって連結され、プロセス終了時に、各デバイスは同じ 128 ビット CS_IV、64 ビット CS_IN、128 ビット CS_PV 値を所有する。

8.5.2Channel Sounding 能力交換

すべてのchannel sounding 同じ機能を持つわけではありません。例えば、サポートされるchannel sounding 方法（8.4 章「2 つの BluetoothChannel Sounding 方法」参照）は異なる場合があります。合計で 22 のchannel sounding 機能パラメータが定義されています。

2つのデバイスが共にサポートできるchannel sounding 到達するためには、まず、それらの能力に関する情報を交換しなければならない。リンクレイヤーこのために LL_CS_CAPABILITIES_REQ と LL_CS_CAPABILITIES_RSP PDU を定義している。

8.5.3Channel Sounding 設定

各装置のchannel sounding 能力に関する情報に基づいて、両者がサポートできる選択されたコンフィギュレーションが、リンクレイヤー LL_CS_CONFIG_REQおよびLL_CS_CONFIG_RSP PDUを使用して交換される。

イニシエータまたはリフレクタ channel sounding 役割は、プロセスを駆動するアプリケーション LL_CS_CONFIG_REQ PDU でその選択を送信し、相手デバイスがそれに応答することで、この手順の間に決定される。

8.5.4 Mode-0 FAE テーブル要求

すべてのデバイスは、送信周波数の設定にある程度の不正確さを示し、これは必要な周波数が含まれるRFチャンネルによって異なる場合があります。

Fractional Frequency Offset Actuation Error (FAE)は、デバイスが送信周波数を設定する際の不正確さの尺度である。意図した周波数と実際に発生した周波数との差をppm（百万分の一）で表す。

イニシエータ、リフレクタ FAEを考慮したキャリブレーションを実行する必要があり、そのためにはリフレクタ FAEデータのテーブルが必要である。このデータは、リンクレイヤーモード0FAEテーブル要求制御手順によって取得される。これには、イニシエータ LL_CS_FAE_REQ PDUを送信し、リフレクタそのFAEテーブルを含むLL_CS_FAE_RSP PDUで返信することが含まれる。デバイスのFAEテーブルは製造時に設定されることに注意。

Mode-0については「8.8 ステップとモード」で説明する。

8.5.5Channel Sounding

セキュリティ・マテリアルの交換、コンフィギュレーションの合意、及び利用可能な場合には FAE データの共有が完了した後、イニシエータ LE コントローラにchannel sounding開始を指示することができる。これには、リンクレイヤー制御 PDU「LL_CS_REQ」、「LL_CS_RSP」及び「LL_CS_IND」の交換が含まれる。

Channel sounding 、CSステップと呼ばれる様々な動作のシーケンスで進行し、多くのタイミング・パラメータに従う。これらはChannel Sounding 時に交換される。

8.6 タイムディビジョン

7.8 論理的なトランスポート」で説明した論理的なトランスポートはすべて、アクティビティが発生する時間軸を、イベントや場合によってはサブイベントという観点から構造化する。channel sounding シーケンスとスケジューリングは、より高度で可変的であり、これに対応するために、4つのレベルの時間分割が定義されている。

channel sounding 実行される場合、1つまたは複数のCSプロシージャが連続して実行される。CS手順はCSイベントに分割され、各CSイベントはCSサブイベントに分割される。各 CS サブイベント内では、2 つ以上の一連のCS 手順がスケジューリングされ、CS 手順内で RF 送受信アクティビティが実行されます。図 43 は、コンフィギュレーション例で使用される場合のこれらの概念を示しています。

図43 - CSの時分割コンセプト

8.7 パケットとトーン

CSのステップの中で行われるRF活動は、2つの形態のいずれかを取る：

パケット- ガウス周波数シフト・キーイング（GFSK）で変調されたバイナリ・データ。
トーン- データを含まない無線送信。無線信号そのものの特性がPBR 方式で使用され、デジタル・ドメインからのデータを必要としない。

Channel sounding CS_Syncパケットとして知られ、多くの種類が定義されている。CS_Sync パケットは、校正ステップ中およびRTT 方式が使用されているときに送信される。channel sounding 使用されるトーンはCS Tonesと呼ばれ、PBR 方式が使用されているときに使用される。

8.8 ステップとモード

CSステップは、Channel Sounding使用される時分割・スケジューリング方式の最下位レベルである。ステップには関連するモードがあり、4つが定義されている。

モード	項目
0	mode-0は較正のために使用される。
1	mode-1はRTT 方式に関するものである。
2	mode-2はPBR 方式に関するものである。
3	mode-3は、単一のデュアル・メソッド・ステップでRTT PBR 両方をサポートする。

8.8.1 モード0

ステップモード-0の目的は、イニシエータフラクショナル周波数オフセット（FFO）として知られる値を計算できるようにすることである。

周波数、波長、位相の関係を考慮すると、channel sounding 装置で生成される信号の周波数は、BluetoothChannel Sounding 機能する上で重要な要素です。しかし、生成された信号の周波数が意図した周波数にどれだけ近いかは様々であり、ある程度の不正確さは常に予想されます。

FFOは、与えられたターゲット周波数の生成において、リフレクタイニシエータどの程度異なるかを示す指標である。FFOの計算には、リフレクタ受信したCSトーンの周波数と、イニシエータ 8.5.4 Mode-0 FAE Table Request制御手順で取得したリフレクタMode-0 FAE Tableが含まれる。

FFOは、イニシエータリフレクタ差を補正し、最終的に結果の精度を向上させるために計算に使用される。

図44は、モード0ステップでイニシエータリフレクタ送信するパケットとトーンを示している。

図44-モード0でのパケットとトーンの送信

ブルートゥースコア仕様、図に示されラベル付けされたタイムスロットを定義する。ラベルとその意味を表10に示す。

T_SY	同期シーケンスの時間。
T_RD	送信ランプダウンの時間。これは5μsで、トランスミッター RFチャネルからエネルギーを除去するために使用される。
T_IP1	イニシエータ送信終了からリフレクタ送信開始までの間奏時間。持続時間は10μs～145μsの間で変化し、能力交換手順で決定される。
T_GD	ガード時間。常に10μ秒。
T_FM	周波数測定時間。ステップモード0では常に80μs。

表10 - CSステップのタイムスロット

すべてのCSサブイベントは、少なくとも1つのモード0ステップから始まる。

8.8.2 モード-1

モード 1 のステップでは、往復時間測定するために CS_Sync パケットを交換します。図 45 に、このステップ・モードで定義されたパケット交換とタイム・スロットを示します。

図45-モード1でのパケット交換RTT

往復時間計算を可能にするために、イニシエータ CS_Syncパケットを送信する際のタイムスタンプと、リフレクタCS_Syncパケットを受信する際のタイムスタンプを取得する。ブルートゥースコア仕様いくつかのタイムスタンプ方式を定義しており、それぞれ精度が異なる。

8.8.3 モード2

モード 2 のステップは、PBR 方式による距離測定に関するものである。イニシエータとリフレクタ CSトーンを交換し、各デバイスは同じ周波数で送信する。PBR 方式が使用される場合、複数のアンテナが関与する可能性があり、これは図46に示すタイムスロットの意味に反映される。

図 46 - モード 2PBR）の CS トーン交換

図46にはいくつかのタイムスロット・ラベルが追加されているが、これについては表11で説明する。

T_SW	アンテナ切り替えのための予約時間。
T_PM	位相測定トーンの送信時間。
T_IP2	CSトーン間の間奏時間。
N_AP	アンテナ経路の数。

表 11 - 追加のPBR タイム・スロット・ラベル

8.8.4 モード3

モード 3 ステップは、RTT 計算とPBR 計算の両方の基礎を、すべて 1 つのステップでイニシエータ提供する。図 47 は、このステップ・モードで行われる CS_Sync パケットと CS トーンの交換を示している。

図47-モード3ステップで交換されるパケットとトーン

8.9 モード・シーケンス

CS手順は常に、2つまたは3つの異なるモードをミックスした複数のCSステップで構成される。一般的に、実行されるステップの数が多ければ多いほど、距離計算のために取得されるデータ量が多くなり、より良い結果が得られる。実行されるCS手順、CSイベント、CSサブイベント、CSステップの数、および使用されるステップ・モードの組み合わせは、アプリケーションによって構成されます。これはモード・シーケンスとして知られています。

モード0は常に関与しており、すべてのCSサブイベントは、モード0の連続する1つ、2つ、または3つのステップから開始しなければならない。少なくとも1つ、多くても2つの他のモードがステップシーケンスに存在しなければならない。しかし、すべての組み合わせが許されるわけではなく、ブルートゥースコア仕様それらの組み合わせを定義している。ある構成において、選択されたモード0でないモードのうち1つをMain_Modeとし、もう1つ（もしあれば）をSub_Modeとする。ブルートゥースコア仕様、これらの用語の意味とモード・シーケンスへの影響に関する詳細が記載されている。

表12に、許容されるモード0以外の組み合わせを示す。

メインモード	サブモード
モード1	なし
モード2	なし
モード3	なし
モード2	モード1
モード2	モード3
モード3	モード2

表 12 - 許容されるモード 0 以外のモードの組み合わせ。

一般的に、ステップモードのシーケンスはこのパターンに従う：

1つ以上のモード0ステップがサブイベントを開始する。
nはランダムに選択され、channel sounding 設定手順で指定された範囲に入る。
1つのsub_modeステップは、n個のmain modeステップのシーケンスに続く。

図48はその例である。

図48 - 設定パラメーターを含むステップ・モード・シーケンスの例

8.10 チャンネルとチャンネル選択

セクション 6.1 周波数帯域は、Bluetooth LE 2.4 GHz の周波数帯域を 2 MHz 幅の 40 チャンネルに分割する方法を説明します。セクション7.8「論理トランスポート」では、リンクレイヤー仕様で定義された様々な論理トランスポートがチャンネルを選択する方法について説明します。BluetoothChannel Sounding 両方の点で異なるアプローチを取ります。

8.10.1 RFチャンネル

BluetoothChannel Sounding 、リンクレイヤー論理トランスポートが使用されている場合と同様に、2.4GHzの免許不要帯域で動作します。しかし、この帯域は 1MHz 幅の 79 チャネルに分割され、このうち 72 チャネルがchannel sounding使用可能です。これらのチャネルの配置により、LEプライマリ広告チャネルは確実に回避される。

表13は、channel sounding 、チャンネル・インデックス値、および各チャンネルがchannel sounding中に使用可能かどうかを示している。

CSチャンネル指数	RF中心周波数	可
0	2402MHz	いいえ
1	2403 MHz	いいえ
2	2404MHz	はい
...	...	...
22	2424MHz	はい
23	2425MHz	いいえ
24	2426MHz	いいえ
25	2427MHz	いいえ
26	2428 MHz	はい
...	...	...
76	2478MHz	はい
77	2479 MHz	いいえ
78	2480 MHz	いいえ

表 13 - CS チャネル・インデックスと RF 物理チャネル

チャンネル幅を通常の2MHzではなく1MHzにすることで、距離の曖昧さ （8.4.1位相ベース測距説明）が150m付近まで生じないようにしています。これは、BluetoothChannel Sounding 設計されているアプリケーションの種類には十分すぎるほどです。

8.10.2 チャンネルフィルター

適応型周波数ホッピング（AFH）については7.4 チャネル選択で説明した。AFHの適応的な側面は、デバイスが各RFチャネルの性能を測定し、特定のチャネルを使用すべきかどうかについて通信デバイス間で情報を共有することである。これによって、デバイスは動作しているRF環境に適応し、過度の干渉を受けるチャネルを避けることができる。

Channel Sounding 、同じ理由でチャンネル・インデックス・フィルター・ビット・マップを維持する。マップ内の各チャンネルは、含まれるか除外されるかのどちらかにマークされる。チャネル選択プロセスでは、除外とマークされたチャネルが決して選択されないようにします。イニシエータリフレクタ、Channel Sounding 更新手順を使用して、RFチャネルのパフォーマンス情報を互いに共有します。

8.10.3 チャネル選択と周波数ホッピング

図49に示すように、各CSステップが実行される前にチャンネルが直接選択される。

図49 - ステップ実行前の周波数ホッピング

ブルートゥースコア仕様、BluetoothChannel Sounding専用の 3 つのチャンネル選択アルゴリズムが定義されています。これらは CSA #3a、CSA #3b、CSA #3c として知られている。

CSA#3aは、モード0ステップで使用するチャンネルを選択するためだけに使用する。

CSA#3bとCSA#3cはどちらも非Mode-0ステップ用に設計されているが、CS処置中はどちらか一方のみを使用することができる。

CSA#3aとCSA#3bは非常によく似た方法で動作する。それぞれ、チャンネルマップに含まれるとマークされたすべてのチャンネルのインデックスを含むチャンネルリストを使用する。チャンネルのchannel sounding 始まると、チャンネルリストはシャッフルされ、チャンネル選択では、シャッフルされたリスト内の各チャンネルを1つずつ使用する。CSA#3aのルールは、シャッフルされたリスト内のすべてのチャンネルインデックスが使用されると、関連するチャンネルリストが再生成され、再シャッフルされ、再び使用が開始されるというものである。CSA#3bは、シャッフルされたリストが再生成される前に、何度か繰り返される。

CSA#3cはCSA#3bとは全く異なり、より複雑であるが、状況によっては反射信号経路を検出する上で利点があるかもしれない。詳細はブルートゥースコア仕様書を参照されたい。CSA #3cへの対応はオプションです。

8.11 アンテナ切り替えとアンテナ経路

デバイスは、位相ベース測距使用するために、最大4つのアンテナのアレイを持つことができる。デバイスの1つのアンテナから他のデバイスのアンテナの1つへの送信は、アンテナパスを構成します。最大4つのアンテナパスが許可され、これにより、表14に示すように、イニシエータリフレクタ各々におけるアンテナアレイサイズの順列が8のリストに制限されます。

アンテナ構成指数（ACI）	装置アンテナの数	デバイスBのアンテナ数	アンテナパス数 (N_AP)
0	1	1	1
1	2	1	2
2	3	1	3
3	4	1	4
4	1	2	2
5	1	3	3
6	1	4	4
7	2	2	4

表14 - アンテナ・アレイのサイズ順列とアンテナ・パス

以下の図は、2つの異なるアンテナ構成とそれに関連するアンテナ経路の例を示しています。

図50 - 3:1アンテナ構成（ACI=2、N_AP=3）

図 51 - 2:2 アンテナ構成（ACI=7、N_AP=4）

アンテナの切り替えは、mode-2 および mode-3 ステップの CS Tone の送信中に行われる。これは、図46および図47に示すタイムスロット持続時間の計算式におけるN_AP（アンテナ経路数）の項に反映されている。

8.12RTT 精度

真空中の光速は秒速299,792,458メートルである。つまり、わずか1マイクロ秒で光は300メートル近く進む。もちろん、電波も光速で伝わる。

そのため、RTT メソッドを使用する場合、イニシエータToDとToAのタイムスタンプを正確に取得することが重要である。捕捉されたタイムスタンプのごくわずかな誤差が、結果として得られる距離計算に大きな誤差をもたらすことがある。

距離推定のために十分な精度でタイムスタンプを取得することは、エンジニアにとって大きな課題である。ブルートゥースコア仕様、いくつかのアプローチを紹介しています。

アクセス・アドレス：アクセス・アドレス CS_Syncパケットの最初のフィールドであり、32ビット長である。タイムスタンプの方法の1つは、アクセス・アドレス受信された時刻を取得することであるが、具体的にどのように行うべきかの詳細は実装に任されている。
部分的タイミング推定:アクセスアドレス到着を使用するよりも正確である可能性が高い。一般的に、分数法では、CS_Syncパケットの末尾に配置されるフィールドを解析して、非常に小さなタイミング誤差を決定する。この目的のために、CS_Sync パケットに 2 つのフィールドのうちの 1 つを追加することができます。
- ランダム・シーケンス：受信信号のサンプリングは、受信信号の位相と同期している可能性は低く、これが小さなタイミング・エラーの原因となる。ランダムシーケンスフィールドを解析することで、実際のサンプリングポイントと最適であったであろうサンプリングポイントとの差を明らかにすることができる。これを利用して、タイムスタンプ値の精度を向上させることができる。
- サウンディング・シークエンス：これは1と0を交互に並べたものである。GFSKで変調して送信すると、1と0を表すシンボルは周波数が異なり、2つの異なるトーンを構成していると考えることができる。2つのトーン間の位相差を分析することで、タイミングエラーを測定することができ、タイムスタンプの改善に利用できる。

一般的に、一連のステップにわたって計測を行うことで、値の分布を分析し、タイムスタンプの精度を向上させることができる。

8.13 セキュリティ

距離測定システムにおけるセキュリティには、いくつかの新しい課題がある。一般的に、保護すべき脅威は、悪意のあるデバイスが、信頼できる2つのデバイスの一方（特に、BluetoothChannel Sounding場合はイニシエータ）を騙して、もう一方の信頼できるデバイスが実際よりも近くにあると思わせることである。

次の 2 つのセクションでは、2 種類の攻撃について簡単に説明します。セクション 8.13.3 BluetoothChannel Sounding セキュリティ機能では、これらのタイプの攻撃（およびその他）から保護する BluetoothChannel Sounding 機能を要約します。

8.13.1 スプーフィング

ある種の攻撃では、信頼されたデバイスの1つが攻撃デバイスによって模倣される。リプレイ攻撃はそのような例の1つで、悪意のあるデバイスが、信頼されたデバイス間で正常な対話が行われている間に交換されたパケットを記録する。そしてその後、記録されたパケットの一部を使用して、信頼されたデバイスがあたかも正当な相手と対話中であるかのように振る舞うような応答を送信します。

図52では、AliceとBobはセキュリティの低い独自のワイヤレス距離測定システムにおける2つの信頼できるデバイスを表している。攻撃者は悪意のあるデバイスで、この攻撃の最初の段階では、アリスとボブ間のやり取りを単に聞き、パケットを記録する。

図53では、攻撃の第2段階は、第1段階で記録されたパケットを利用して、アリスが信頼できるデバイス、ボブとの交換であるかのように騙す。

図52 - リプレー攻撃パート1

図53 - リプレー攻撃パート2

Channel Sounding 、この種の攻撃に対する複数の防御機能がある。

8.13.2 リレー攻撃

もう一つの潜在的な攻撃はリレー攻撃と呼ばれるものである。これは物理層で動作する中間者（MITM）攻撃、信頼できるデバイスから他のデバイスに信号を中継するが、リアルタイムで何らかの方法で信号を操作し、デバイスが実際よりも近くにあるかのように見せかける。

図54 - リレー攻撃

Channel Sounding 、この種の攻撃に対する複数の防御機能がある。

8.13.3Channel Sounding 機能

BluetoothChannel Sounding 、広範なセキュリティ機能が含まれており、Generic Access Profileでは、channel sounding適用される4つのセキュリティレベルが定義されています。

Channel Sounding 定義されているセキュリティ機能の全リストは、4つのカテゴリーに分類することができます。

8.13.3.1PBR 法とRTT 法の併用

BluetoothChannel Sounding 、距離測定の位相ベース測距ラウンドトリップタイミング法の両方をサポートしています。ステップモードシーケンスの柔軟性により、アプリケーションは両方の方法を同時に使用することができます。これにより、これら2つの全く異なる方法で生成されたデータのクロスチェックを実行することができます。

channel sounding 信号の位相と計算されたラウンドトリップタイムの両方を操作して、誤解を招くような一貫性のある結果を与えるように、両方の方法を同時に攻撃する複雑さは、セキュリティの専門家によって非常に高いとみなされています。これだけでも、攻撃を検知するための強力なメカニズムである。

8.13.3.2 ビットストリームおよび送信パターンのランダム化

Channel Sounding 、決定論的ランダム・ビット生成器（DRBG）と呼ばれる関数の仕様が含まれている。この関数を繰り返し呼び出すことで、傍目にはランダムで予測不可能な値のシーケンスが生成されます。

しかしDRBGは、Channel Sounding 手順で両方のデバイスが確立した初期化ベクトル（CS_IV）、ノンス（CS_IN）、パーソナライゼーション・ベクトル（CS_PV）の値を使用します。したがって、3つのDRBGパラメータを持つデバイスにとっては決定論的なシーケンスとなりますが、そうでないデバイス（攻撃者など）にとっては予測不可能なシーケンスとなります。CS_IV、CS_IN、および CS_PV は、channel sounding 実行されるたびに異なる値を持ち、暗号化された LE-ACL 接続を介して部分的な値の交換から生成されることから、攻撃者は使用中の DRBGパラメータ値を知らないものと安全に想定できる。

DRBGは、ビット・ストリームの内容と全体的な伝送パターンの両方をランダム化するために使用される。ブルートゥースコア仕様、channel sounding 領域がランダムに選択され、ランダムに生成されたビット・パターンに設定されることが規定されている。さらに、モード2とモード3のステップには、トーン拡張スロットと呼ばれる時間スロットが定義されており、このスロットの間に送信を行うかどうかはDRBGの呼び出しに依存する。

この2つの方法でDRBGを使用することは、イニシエータリフレクタ両方が、送信内容とトーン拡張スロットの送信トーンの有無をランダム化できることを意味する。DRBGは定義上決定論的であるため、イニシエータリフレクタ（それぞれCS_IV、CS_IN、CS_PVを持つ）は、攻撃者が予想できないことを予想できる。いずれかのchannel sounding 予期しないビット値または予期しない送信（または予期しない送信の不在）を検出した場合、これは潜在的な攻撃として扱われます。

リプレイ攻撃は、2つのデバイスがchannel sounding 行うたびに送信されるパケットとトーンのシーケンスが変化するため成功せず、記録された過去の一連のやり取りを再生するだけでは簡単に検出されてしまう。

8.13.3.3 記号操作に対する防御

中間者（MITM）が正規の送信デバイスから部分的に受信した無線シンボルの値を予測し、それらのシンボルの完全なバージョンを早期に中継することで、タイミングを操作し、正規の受信者が往復時間、つまり距離を誤算するような物理層攻撃が数多く知られている。攻撃者の信号は通常増幅されるため、ターゲット・デバイスは、マルチパス伝搬による反射とみなされ無視される可能性のある弱い元の信号ではなく、操作された信号を主要な信号とみなす。この攻撃は、タイミングを進めるためにシンボルの持続時間をフルに利用するもので、持続時間の長いシンボルは短いシンボルよりもこの種の攻撃に弱い。

LE 2M 2BT PHY の帯域幅ビット周期製品値 2.0 は、他の PHY のパルスより短いシンボルパルスとなり、この種の攻撃のリスクを低減する。

リレー攻撃に対する防御として使用できるもう一つの機能、SNR制御と呼ばれるものである。

SNR制御により、イニシエータレシーバー事前に合意した量のランダムノイズをいくつかの信号に混ぜることができる。シンボル操作リレー攻撃は、攻撃者が正規の信号を非常に素早く、シンボルの全時間よりもはるかに短い時間で分離して操作できることに依存しています。信号にノイズを注入することで、攻撃者の分析が完了するのが難しくなり、遅くなるため、このような攻撃が成功する可能性が低くなります。一方、イニシエータリフレクタ、事前にSNRを合意しているため、人為的に追加されたノイズを簡単にフィルタリングすることができます。

8.13.3.4 RF信号解析技術と攻撃検知

BluetoothChannel Sounding 仕様には、攻撃検出システムの記述と、攻撃が進行中である確率を報告するための標準化されたメトリックである NADM（Normalized Attack Detector Metric）が含まれている。 NADM は、表 15 に示すように、関連する形容詞の用語とスライディングスケールを使用します。

NADM値	項目
0x00	攻撃の可能性は極めて低い
0x01	攻撃の可能性は極めて低い
0x02	攻撃の可能性は低い
0x03	攻撃は可能
0x04	攻撃の可能性が高い
0x05	攻撃の可能性は非常に高い
0x06	攻撃の可能性は極めて高い
0xFF	ランダムシーケンスやサウンディングシーケンスを持たないRTT タイプのデフォルト値。

表15 - NADMの値

攻撃の可能性を示す指標としては、予期せぬビット値や位相調整があり、比較の対象となる基準信号の特性はブルートゥースコア仕様与えられる。

8.14 距離測定アプリケーション

BluetoothChannel Sounding 自体は距離値を計算しません。その代わり、独自の距離計算アルゴリズムで使用できるタイミング情報や振幅・位相値（IQサンプル）などの素材をアプリケーションに提供します。標準アルゴリズムは、相互運用性に関係しないため定義されておらず、製造業者はそのアルゴリズムが達成できる結果の品質によって自由に差別化することができます。

Channel Sounding 使用するアプリケーションには、以下を含むがこれに限定されない多くの責任がある：

BluetoothChannel Sounding 提供されるデータを使用して距離測定値を計算するアルゴリズムを実装する。
使用するステップ・モードやそのシーケンス、タイミング・パラメータを含め、アプリケーションニーズや優先順位に適した構成を選択する。これには、生成するchannel sounding 測定データ量に対するレイテンシなどの問題のバランスを取ることも含まれます。
Host （HCI）コマンドを使用し、「5 BluetoothChannel Sounding リンクレイヤー制御手順」で説明した制御手順を開始し、進行させる。
GAPで定義されたchannel sounding セキュリティ・レベルの1つを選択し、セキュリティ要件を考慮してchannel sounding 設定する。
NADM値で表される攻撃検知情報を、アプリケーション適した方法で処理する。

BluetoothChannel Sounding 仕様は、正確で安全な距離測定アプリケーションのための厳格で標準的、かつ相互運用可能なフレームワークとして機能する一方で、開発者には特定の優先順位に沿ってアプリケーションを最適化する柔軟性が与えられます。

9.アイソクロナス・アダプテーション・レイヤー

9.1 基本

Isochronous Adaptation Layer (ISOAL)の目的は、オーディオデバイスを含む接続型アイソクロナス通信とブロードキャスト型アイソクロナス通信の両方に影響を与える可能性のある潜在的なアドレスすることです。これは、アイソクロナス通信の他のアプリケーションしれない。

9.1.1 オーディオ・サンプリング 101

デジタルオーディオは、アナログオーディオ信号をサンプリングし、サンプリングされたオーディオにコーデックを適用してデジタルサンプルデータを圧縮処理してから、保存またはBluetooth LE オーディオの場合は送信します。エンコードされたデジタルオーディオデータの読み取りまたは受信時に、コーデックがデータをデコードし、元のアナログオーディオを（ほぼ）再現するために使用される一連のデジタルサンプルを生成することで、プロセスは逆転します。図55は、オーディオ信号のサンプリング、エンコード、および送信に関わるステップと、エンコードされたオーディオデータの受信、デコード、および最終的なレンダリングに関わる逆のステップを示しています。

図55 - オーディオ処理ステップ

オーディオコーデックの重要な目標の1つは、限られた（そして貴重な！）帯域幅を持つリンク上で効率的に伝送できるように、オーディオデータのサイズを小さくすることです。サンプリングは、一定間隔で信号の振幅を測定し、記録することを含む。サンプルを記録する周波数はサンプルレートとして知られている。図 56 の縦線は、曲線で表された、連続的に変化するオーディオ信号のサンプルを表しています。この一連のサンプルによって、元のアナログ信号の近似的な表現が作られます。サンプルの採取頻度が高ければ高いほど（つまりサンプルレートが高ければ高いほど）、その近似はオリジナルに近くなり、プロセスを逆にしてオリジナルのオーディオを再現すればするほど、より良い結果と知覚品質が得られます。

サンプリングのさらなる次元はビット深度である。サンプリングされた信号の振幅は、整数値で表される必要がある。一つのアプローチは、振幅値の可能な範囲を256の個別の振幅バンドに分割し、それぞれを0から255の間の数値で表現することです。この方式では、1つのサンプルは、サンプリングされた振幅値が該当する帯域を記録するために1バイト（8ビット）しか必要としないため、ビット深度は8ビットと言われます。振幅の可能な範囲をより細かいバンドに分割することで、サンプル値をより細かく表現できるようになり、より質の高い結果が得られる可能性があります。例えばビット深度が24ビットの場合、0から16,777,215までの整数で振幅値の範囲を表すことができます。しかし、各サンプルは3バイトを必要とするため、ビット深度を上げてサンプリングすると、3倍のデータが生成されます。

デジタル・サンプリングは大量のデータを生成することができる。3分の曲を44.1kHz（CD品質）、ビット深度24でサンプリングしたとしよう。計算してみると、曲全体をデジタル形式でほぼ表現するのに必要な生のサンプリング・データ量は、24メガバイト近くになる。コンピュータの4テラバイトのハードディスクにデータを保存するだけなら気にすることはないが、帯域幅の限られた通信回線でデータを送信する場合には問題になる。そこでコーデックの出番となる。

図56 - 連続アナログ信号を表す離散サンプル

9.1.2 コーデックとフレーム

Bluetooth LE オーディオで使用されているLC3のようなコーデックは、生のデジタルサンプルデータを元のサイズの25％以下に圧縮する可能性があります（ただし、実際の結果は元のオーディオコンテンツに大きく依存することに注意してください）。これはかなりの節約です。

コーデックは一般的に、一連の連続したサンプルのパターンを認識し、利用することで動作します。この原理を説明するためだけの非常に簡単な例を挙げると、データセットに100個の連続したサンプル値が含まれており、そのすべてが同じ値、例えば50であったとすると、ビット深度が8ビットであると仮定した場合、コーデックはこれを、個々のサンプルのリスト[50,50,50...,50]を含む元の100バイトの連続ではなく、[100,50]を含む2バイトとして表現するかもしれません。コーデックが機能するためには、一度に1つのサンプルを分析するのではなく、一連のサンプル全体を分析してエンコードする必要があることは明らかです（1つのサンプルからは多くのパターンは見つかりません！）。

コーデックによって一度に分析されるサンプルの集まりは、フレームと呼ばれます。フレームは一定の長さを持ち、通常はミリ秒単位で測定され、サンプルレートによって決められた数のサンプルを含みます。例えば、サンプルレートが44.1KHzの場合、10msのフレームには4410サンプルが含まれます。

オーディオ製品によっては、異なるフレーム持続時間が使われることがあります。10msと7.5msが一般的です。あるデバイス（ソース）があるフレーム継続時間でオーディオを生成し、別のデバイス（シンク）がそれを消費するが、異なるフレーム継続時間を使用する場合、解決しなければならない問題があります。そこでISOALの登場です。

9.2 額装と非額装

デバイスがアイソクロナス通信を使用する場合、送信デバイスと受信デバイスが使用するフレーム継続時間は同じである必要はない。このため、2つの状況が考えられる：

最初のデバイスが使用するフレーム持続時間は、もう一方のデバイスが使用するフレーム持続時間の正確な倍数である。
最初のデバイスが使用するフレーム持続時間は、もう一方のデバイスが使用するフレーム持続時間の正確な倍数ではない。

最初の状況では、大きいフレーム継続時間と小さいフレーム継続時間の関係は単純であり、2つの間でデータを変換することは簡単な操作である。1つまたは複数の要求されるリンクレイヤー PDUのペイロードで送信されるデータは、フレーム化されていないと言われ、2つの要件間のフレーム持続時間の適応をサポートするための追加データを含まない。

第二に、リンクレイヤー PDUは、より大きなペイロードの一部を、その一部がフレームの開始であるか、継続であるか、フレームの終了であるかを示す短いヘッダーフィールドとともに含むことができる。このようにフォーマットされたデータは、フレーム化されていると言われる。

Connected Isochronous PDU と Broadcast Isochronous PDU（リンクレイヤー定義）には、LLID と呼ばれるフィールドが含まれる。LLIDは、リンクレイヤー PDUのペイロードがフレーム化されたデータを含むか、フレーム化されていないデータを含むかを示す。ISOAL は、データがフレーム化されているか否かに応じて、リンクレイヤー受信したデータに異なる処理を適用する。同様に、フレーミングが必要かどうかは、上位レイヤーの SDU で受信し、リンクレイヤー ISO PDU で送信するためにリンクレイヤー渡すデータの ISOAL の処理に影響する。

9.3 フラグメンテーションと組み換え

データがフレーム化されていない場合、再結合によって、1つまたは複数のリンクレイヤー PDUのペイロードに含まれる一連の1つまたは複数のフラグメントから、1つのサービスデータユニット(SDU)が作成される。その後、ISOALはSDUを上位レイヤーに渡す。これを図57に示す。

図57 - フレーム化されていないISO PDUの再結合

上位レイヤのSDUをより小さなペイロードに分割してリンクレイヤー PDUで送信する必要があり、フレーミングが不要な場合、その処理はフラグメントと呼ばれる。これを図 58 に示す。

図58 - フレーム化されていないISO PDUを作成するフラグメンテーション

フレームなしPDUには、それに続くデータがSDUの開始、前のSDUの続き、またはこのSDUの終了のいずれかであることを示すフィールドを含むヘッダーがある。PDUには、フレームなしSDUのフラグメントが1つだけ含まれる。

9.4 分割と再組み立て

データがフレーム化されている場合、再組み立ては1つ以上のリンクレイヤー PDUのペイロードに含まれる一連の1つ以上のセグメントから1つのサービスデータユニット(SDU)を作成する。その後、ISOALはSDUを上位レイヤーに渡す。これを図59に示す。

図 59 - フレーム化された ISO PDU の再組み立て

上位レイヤのSDUをより小さなペイロードに分割してリンクレイヤー PDUで送信する必要があり、フレーミングが必要な場合、その処理はセグメンテーションと 呼ばれる。これを図60に示す。

図60 - フレーム化されたISO PDUを作成するセグメンテーション

フレーム化されたPDUのセグメントは、それに続くデータがSDUの開始、前のSDUの続き、またはこのSDUの終了であることを示すフィールドと、タイミングオフセット情報を含むヘッダーを持つ。PDUはフレーム化されたSDUの複数のフラグメントを含むことができる。

10.Host

10.1 基本

Host （HCI）は、host コントローラにコマンドを発行し、コントローラがhost通信するための標準化されたインタフェースを定義する。仕様書はいくつかの部分に分かれており、最初の部分は機能的な用語のみでインターフェイスを定義しており、特定の実装メカニズムについては考慮されていない。

HCIはBluetooth LE Bluetooth BR/EDR両方で使用される。

10.2 HCI機能仕様書

機能インターフェースは、コマンドとイベントで定義される。これらは基本的に、host コントローラ間で交換されるメッセージである。コマンドは、host コントローラに送信され、イベントはコントローラからhost送信される。イベントは、コマンドに対する応答である場合もあれば、未承諾メッセージで送信される場合もあります。図 61 を参照。

図 61 - HCI コマンドとイベント

10.3 HCIトランスポート

4つのHCIトランスポート・タイプがある：

UART
USB
セキュアデジタル（SD）
3線式UART

10.3.1 UARTトランスポート

HCI UARTトランスポートは、host コントローラの両方が同じプリント回路基板上でUARTを使用して接続されている場合に、UARTを使用してHCI通信を実装するために使用することができる。5つのパケットタイプに基づくプロトコルが定義されている。これらは、HCIコマンド・パケット、HCI ACLデータ・パケット、HCI同期データ・パケット、HCIイベント・パケット、HCI ISOデータ・パケットである。

RS232コンフィギュレーション要件が規定されている。要約すると、UARTトランスポートは8データビット、パリティなし、1ストップビット、RTS/CTSフロー制御を使用する。

10.3.2 USBトランスポート

USBは2つの方法でHCIトランスポートとして使用することができる。BluetoothコントローラをUSBドングル内に実装する。あるいは、USBを製品内部で使用して、host コントローラの実装をリンクすることもできます。

USB規格は、エンドポイントと呼ばれる、データを送信したり受信したりするバッファを定義しています。HCI USBトランスポート仕様は、存在することが期待されるエンドポイントと、それらの要求または推奨されるプロパティを示しています。

10.3.3 セキュアデジタル

HCI SDトランスポートで使用するためのプロトコルは、Secure Digital Association（SDA）によって定義され、所有されている。ブルートゥースコア仕様HCI SDトランスポートのセクションは、通信アーキテクチャの概要とともに、主にSDAが所有する外部仕様への参照で構成されている。

10.3.4 3線式UART

3線式UART HCIトランスポート仕様は、2つの3線式接続UART間でHCIコマンドとイベントを通信するためのアーキテクチャとプロトコルを記述します。信頼性、データインテグリティ、リンク確立、パワーマネージメント、ハードウェアコンフィギュレーションを扱います。

10.4 HCIの例

HCIの機能的インターフェイスが実際に使われている例をいくつか紹介しよう。

10.4.1 コネクションレスAoAAoD

図62は、コントローラの設定中にHCIコマンドとイベントが交換される様子を示しています。 host サポートするパケットの送信を準備する方向検知到着角度（ AoA ）または出発角（ AoD ）テクニック。

図 62 - コネクションレスAoD コントローラーの構成

10.4.2 LEパスロス・モニタリング

LE 経路損失モニタリングは、LE パワー制御機能一部である。接続された相手デバイスが使用する送信電力を管理し、それをレシーバー最適な電力範囲内に維持したいデバイスは、この機能を使用することができる。

図63は、LEパスロス監視を設定し、有効にするために必要なHCIコマンドを送信するhost 示しています。モニタリングが有効になると、コントローラはパスロスデータを含むLEパスロスしきい値イベントをhost送信します。

図 63 - LE 経路損失モニタリング

10.4.3 アクティブ・スキャン

アクティブ・スキャンは、レガシーアドバタイズ利用し、1つの広告パケットに含まれる以上のデータを通信する必要があるペリフェラルでサポートされる。このトピックの詳細については14.3 Discoveryセクションを参照のこと。

図64は、デバイス(デバイスA)のhost コンポーネントが、アクティブスキャンを実行するようにコントローラを設定し、別のコマンドでスキャンを有効にしてスキャンを開始する様子を示している。デバイスAのリンクレイヤー、アクティブスキャンを実行するように構成されているため、他のデバイスからADV_INDなどのスキャン可能な広告パケットを受信すると、SCAN_REQ PDUを送信して応答し、他のデバイスからSCAN_RSP PDUを受信して返信する。元の広告パケットの内容とスキャン・レスポンスは、一連の HCI LE 広告レポート・イベントでデバイス A のHost 渡されます。

図64 - アクティブ・スキャン

11.論理リンク制御適応プロトコル

11.1 基本

L2CAP（Logical Link Control and Adaptation Protocol）は、プロトコルの多重化、フロー制御、サービスデータユニット（SDU）の分割と再組み立てを行う。

L2CAPは、スタックのレイヤー間を通過するパケットのシーケンスを分離するために、チャネルの概念を使用する。固定チャネルはセットアップを必要とせず、すぐに利用可能であり、特定の上位レイヤのプロトコルに関連付けられる。チャネルは、指定されたプロトコル・サービス・マルチプレクサ(PSM)の値によって動的に生成され、プロトコルに関連付けられることもある。

図65は、L2CAPの主な機能を示している。

図 65 - L2CAP の主な機能

11.2 L2CAPとプロトコル多重化

スタック内でL2CAPの上に位置するのは、属性プロトコル(ATT)やセキュリティマネージャプロトコル(SMP)など、異なるプロトコルを使用するレイヤである。L2CAPプロトコルの多重化によって、SDUがスタックを上がって適切なレイヤに渡され、処理されるようになる。

L2CAPチャネルが属性プロトコルを処理するとき、それはATTのために予約された固定チャネルを使用し、この場合、非強化ATTベアラとして動作すると言われるか、または1つ以上の一連の動的チャネルを使用し、それぞれが拡張ATTベアラとして動作する。非強化ATTベアラは、一度に1つずつシーケンスで実行されるATTトランザクションをサポートする。拡張ATTベアラは、並列L2CAPチャネル内で順次実行される並列ATTトランザクションをサポートする。12.属性プロトコル」を参照のこと。

11.3 L2CAPとフロー制御

フロー制御は、スタックのあるレイヤーがパケットを生成する速度が、同じスタックのレイヤーやリモートデバイスのレイヤーがそれらのパケットを処理する速度を超えないようにすることに関係する。フロー制御なしでは、バッファオーバーフローのような問題が発生する危険がある。

クレジット・ベースのフロー制御は、フロー制御に対する多くの可能なアプローチのひとつである。概略は以下の通りである：

送信側デバイスは、受信側デバイスの容量を、データ損失（バッファオーバーフローなど）なしで処理できるPDU数という形で把握しています。この容量情報は、設定を通じて、または送信前に2つのデバイス間で交換された情報を通じて取得されます。データ転送始まります。
トランスミッター、レシーバー容量制限にカウンターを設定する。トランスミッターPDUが送信されるたびに、カウンタはデクリメントされる。カウンタ値がゼロになると、レシーバーレシーバーフルキャパシティになったことを認識し、レシーバーバックログを処理する間、それ以上のPDUの送信を一時的に停止する。
レシーバーバッファから1つ以上のPDUを読み込んで処理した後、対応する数のクレジットをトランスミッター返送し、トランスミッターそれを使用してカウンターをインクリメントする。カウンタがゼロでない場合、トランスミッターさらなるPDUの送信を続けることができる。

L2CAPはいくつかの動作モードを定義しており、主にフロー制御に関係している。

例えば、L2CAP非強化ATTベアラ上のATTは、フロー制御を提供しない基本L2CAPモードを使用する。これはATTを信頼性のないものにし、アプリケーションは送信されたATT PDUが受信デバイスによって失われる可能性に対応しなければならない。通知のような確認されていないPDUの場合、送信デバイスは、リンクレイヤー確認応答のおかげで、PDUがリモートデバイス上のスタックで受信されたかどうかを知ることができるが、PDUがスタックの最上位にある受信アプリケーション正常に配信されたかどうかを知る方法はない。

L2CAP enhanced ATTベアラ上のATTは、フロー制御を提供するEnhanced Credit Based Flow Control Modeを使用する。したがって、EATTは信頼性があると見なすことができる。

11.4 L2CAPの分割と再組み立て

L2CAP の上下のレイヤは、そのレイヤで作成されるタイプの PDU が許容される最大サイズを指定する最大伝送単位（MTU）サイズに従う。例えば、ATT_MTUパラメータは、ATT PDUの最大サイズを定義する。

L2CAP自身と、スタック内の上下のレイヤーは、MTUサイズが異なる場合があり、その結果、いくつかのPDU/SDUを、隣接するレイヤーが処理できる一連の小さな部分に分割したり、逆に、一連の関連する小さな部分を完全なPDU/SDUに組み直したりすることが必要になる場合がある。L2CAPが上位レイヤに対して適用するこれらの処理は、セグメンテーションと再アセンブリと呼ばれ、L2CAPと下位レイヤとの関係に関連する同等の処理は、フラグメンテーションとリコンビネーションと呼ばれる。

12.属性プロトコル

12.1 基本

アトリビュート・プロトコル（ATT）は2つのデバイスによって使用される。 クライアントとサーバーの役割の2つの装置によって使用される。サーバーは属性として知られる一連の複合データ項目を公開する。属性は属性テーブルと呼ばれるインデックス付きリストでサーバーによって整理される。

各属性は、ハンドル、UUID（Universally Unique Identifier）、値、およびパーミッションのセットを含んでいます。

ハンドルは、ATTクライアント属性テーブルの特定のエントリーを参照できる一意のインデックス値である。
UUIDは属性のタイプを識別します。
パーミッション（アクセス許可）フィールドは、読み取り、書き込み、またはその両方のアクセス形態が許可されているかどうか、およびアクセスを許可するために満たさなければならないその他のセキュリティ条件を示すフラグの集合である。
BluetoothSIG スタディガイド Bluetooth LEにおけるセキュリティの理解には、属性パーミッションに関する詳細が記載されています。
属性値フィールドは、属性値を含むバイト配列である。データ型とセマンティクスの両面でバイト配列を解釈することは、スタックの上位レイヤーの関心事である。

Generic Attribute Profile (GATT)は、属性がどのようにサービス、特性、記述子として知られるより高いレベルの構成要素を表すかを定義する。一般的に、これらのような複雑な型を表現するためには、連続したハンドル値の範囲にある属性のグループが必要であり、属性プロトコルはこの理由からハンドル値の範囲によって識別される属性のグループでの作業をサポートする。第13節を参照のこと。Generic Attribute Profile を参照のこと。

ATTは、関心のある属性または属性タイプのハンドル値を含む、ATTサーバー内の属性テーブルの詳細を発見するためにATTクライアント使用される。ハンドル値が知られているとき、それらはテーブル内の特定の属性を識別し、そしてそれに作用するためにいくつかのPDUタイプと共に使用することができる。例えば、ATT_READ_BY_GROUP_TYPE_REQ PDUは、一次サービスの定義の一部である全ての属性のハンドルとUUIDを見つけるために使用できる。これを短く表現すると、ATT_READ_BY_GROUP_TYPE_REQ PDUは、例えば、属性テーブルによって定義されたすべてのGATTプライマリサービスを見つけるために使用することができる。

発見操作をサポートするATT_READ_BY_GROUP_TYPE_REQのようなPDUを使用する場合、ハンドルの範囲が指定され、検索される属性テーブルのエントリのサブセット (これはテーブル全体かもしれない)と検索する属性タイプを示す。図66は、すべてのプライマリサービスが検索され、発見されたプライマリサービスに関連する属性を含むハンドル値の範囲を示す応答で、このプロセスを示している。

図66 - グループ・タイプ別読み取り要求と応答

ATT は、プロトコルが定義する PDU や、GATT（Generic Attribute Profile）のような上位仕様で定義される手順を使用して、接続されたBluetooth LE 機器のアプリケーションが相互に作用する主要なメカニズムの一つである。

ATTには、基本的なATTと、より新しい拡張属性プロトコル（EATT）の2種類が定義されている。

ATT はBluetooth LE とBluetooth BR/EDR両方で使用することができる。本書では、Bluetooth LE で使用される ATT のみを考慮する。

12.2 ATT PDU

属性プロトコルは31の異なるPDUを定義しており、各PDUは6つの大まかな方法のうちの1つに基づいている。

12.2.1 コマンド

ATTコマンドPDUは、呼び出されたサーバーからの応答がない状態で、クライアントサーバーに送信される。コマンドの例は、図67に示すATT_WRITE_CMDである。

図 67 - ATT_WRITE_CMD

12.2.2 リクエストとレスポンス

ATTリクエストPDUはクライアントサーバーに送られる。サーバーは30秒以内に対応するタイプの応答PDUまたはエラー応答PDU (ATT_ERROR_RSP)で応答することが期待される。30秒以内に応答しない場合はタイムアウトとなる。

リクエスト/応答PDUのペアの例は、図68に示すATT_WRITE_REQとATT_WRITE_RSP PDUである。

図 68 - ATT_WRITE_REQ

12.2.3 通知

NotificationはATT_HANDLE_VALUE_NTF型の未承諾PDUであり、サーバーからクライアント送られる。応答PDUは定義されていない。図69を参照のこと。

図 69 - ATT_HANDLE_VALUE_NTF

12.2.4 表示と確認

ATT指示PDUはサーバーからクライアント送られる。クライアント 30秒以内に、対応するタイプの確認PDUまたはエラー応答PDU (ATT_ERROR_RSP)で応答することが期待される。30秒以内に応答しない場合、タイムアウトとなる。

表示/確認PDUのペアの例は、図70 - 表示と確認に示すATT_HANDLE_VALUE_INDとATT_HANDLE_VALUE_CFM PDUである。

図70 - 表示と確認

12.2.5 PDUフォーマット

すべてのATT PDUは同じ構造を持ち、PDUタイプを識別するオペコード、パラメータセット、およびオプションの認証署名で構成される。署名フィールドはほとんど使用されず、属性プロトコルが暗号化リンク上で実行されるときには冗長であることに注意リンクレイヤー

12.2.6 最大伝送単位

ATT PDUの最大長は、確立された最大伝送単位（MTU）値に依存する。ATTに使用されるベアラ[11]に応じて、MTUを確立するために2つのメカニズムのうちの1つが使用される。

12.3 取引

ATTはトランザクションの概念を定義する。クライアント リクエストPDUは、30秒以内にサーバーから応答PDUが返されることを期待する。サーバーが送る指示は、30秒以内に確認PDUでクライアント返信されることを期待する。各リクエスト/応答ペアまたは指示/確認のペアはトランザクションを形成する。トランザクションがタイムアウトした場合、そのトランザクションは失敗したとみなされ、現在のベアラを使用していかなるタイプのPDUもそれ以上送ることはできない。

ATTは逐次トランザクションモデルを使用する。これは、ATTトランザクションが開始された場合、現在のトランザクションが完了するまで、同じベアラインスタンスによってそれ以上のATT PDUを処理できないことを意味する。トランザクションは、期待される応答または確認PDUがリモートデバイスから受信されたとき、またはトランザクションが30秒間待機した後にタイムアウトしたときに完了したとみなされる。

12.4 ベアラー

ATTは、L2CAPレイヤーの下で2つの方法のいずれかで処理され、それぞれベアラとして知られる。2つのATTベアラは、非強化ATTベアラと 拡張ATTベアラである。どちらのベアラが使用されているかは、ATTの使用方法と、場合によってはプロトコルの信頼性に影響する。Generic Attribute ProfileはATTがどのように使用されるかを扱い、例えば次のように述べている：

強化されていないATTベアラー

固定L2CAPチャネルを使用するため、このベアラのインスタンスは1つだけである。
トランザクションは、アプリケーション ATTを使用しているクライアントの数に関係なく、厳密に連続する。これは、あるアプリケーション開始されたトランザクションが、別のアプリケーション開始されたトランザクションを遅らせる可能性があることを意味する。
ATT_EXCHANGE_MTU_REQおよびATT_EXCHANGE_MTU_RSP PDUは、非強化ATTベアラ上で使用されるATT MTUの選択に影響を与えるために交換されるかもしれない。
バッファオーバーフローのような問題のために処理できない、クライアント受信したいかなる通知も破棄される。そのため、ATT_HANDLE_VALUE_NTF PDUは、非強化ATTベアラ上で使用される場合、信頼性がないとみなされる。
ATT_MULTIPLE_HANDLE_VALUE_NTF、ATT_READ_MULTIPLE_VARIABLE_REQ、 ATT_READ_MULTIPLE_VARIABLE_RSPのようないくつかのPDUタイプのサポートは、非強化ATTベアラ使用時にはオプションである。
拡張されていないATTベアラをサポートするL2CAPチャネルは、暗号化されていなくても暗号化されていてもよい。

エンハンストATTベアラ

動的 L2CAP チャネルを使用し、複数のチャネルを使用するため、複数のベアラインスタンスが許可される。
トランザクションは順次処理されるが、ベアラ単位で処理される。したがって、スタック内では、それぞれが別のエンハンストATTベアラインスタンスで処理される並列トランザクションが可能である。これには明らかな利点があり、あるアプリケーションATTの使用が他のアプリケーションによってブロックされる可能性を避けることができる。
ATT MTUは、L2CAPレイヤで使用されるMTU値に自動的に設定され、ATT_EXCHANGE_MTU_REQおよびATT_EXCHANGE_MTU_RSP PDUは、拡張ATTベアラ上で許可されない。
拡張クレジットベースフロー制御モードと呼ばれるL2CAPフロー制御方法は、拡張ATTベアラで使用される。これは、非エンハンスドATTベアラ上で使用されるときに信頼できないPDUが、エンハンスドATTベアラを使用するときに信頼できるとみなすことができるという効果がある。
ATT_MULTIPLE_HANDLE_VALUE_NTF, ATT_READ_MULTIPLE_VARIABLE_REQ および ATT_READ_MULTIPLE_VARIABLE_RSP のようないくつかの PDU のサポートは、拡張 ATT ベアラを使用するときに必須である。
拡張ATTベアラをサポートするL2CAPチャネルは、暗号化チャネルでなければならない。

12.5 EATTサポートの発見

定義されたGeneric Attribute Profileサービスは、接続されたサーバーがEATTをサポートしているかどうかをクライアント判断し、逆にEATTをサポートしていることをクライアント通知することを可能にする。

EATTがサーバーによってサポートされる場合、Server Supported Featuresと呼ばれる特徴 Generic Attribute Profileサービスに含まれなければならない。この特徴値の第 1 オクテットのビット 0 が 1 に設定されることは、EATT がサポートされていることを意味する。GATT/ATTクライアントこの特徴読み取ることで、サーバーが EATT をサポートしているかどうかを判断できる。

サポートされる機能特徴値は、特定の機能のサポートの有無を示すビットで構成されるクライアントビット1は、拡張ATTクライアントサポートされているかどうかを示す。ビット2は、ATT_MULTIPLE_HANDLE_VALUE_NTF PDUのサポートの有無を示す。クライアントこの特徴適切な値を書き込んで、サポートする機能をサーバーに通知しなければならない。

図 71 - EATT機能サポート発見

13.汎用属性プロファイル

13.1 基本

GATT（Generic Attribute Profile）は、属性テーブル（12.属性プロトコルを参照）に保持される属性に基づいて、より高いレベルのデータ型を定義する。これらのデータ型はサービス、特性、記述子と呼ばれる。GATTはまた、属性プロトコル（ATT）を介してこれらのデータ型を使用する一連の手順を定義する。アプリケーションは通常、これらの手順にマッピングされたプラットフォームAPIを使用する。

サービスは、それが含む特性を使用するためのコンテキストを提供するグループ化のメカニズムであり、定義されたタイプを持つ。多くの場合、サービスはデバイスの主要機能または能力に対応する。

特性は、状態データの個々の項目であり、タイプ、関連する値、および関連するGATT手順のセットの観点からデータがどのように使用され得るかを示す特性のセットを有する。例えば、接続されたピアデバイスは特定の特徴値を読むことはできるが、書き込むことはできないと定義することができる。

特徴はサービスに属する。同じ特徴タイプが複数のサービスのメンバーなることがあり、これらのサービスが提供する異なるコンテキストに基づいて、特徴使用規則が異なる場合があります。サービス仕様は、これらの詳細を提供します。

記述子はいくつかの特徴に属し、特徴テキスト記述のようなメタデータを含むことができ、あるいは特徴振る舞いを制御する何らかの手段を提供するかもしれない。特性は、0個以上の記述子を持つ。例えば、GATTは特徴値通知と呼ばれる操作を定義しており、これはデバイスが非同期で、相手デバイスからの応答を必要とせずに、接続された相手に特徴値を含むATT PDUを送信することを含む。特徴通知をサポートする場合、通常、通知は特徴値が変化した時か、タイマーによって制御される定期的な送信のいずれかになります。しかし、通知は相手デバイスが要求した場合にのみ送信され、これは、特徴 特徴構成 "記述子と呼ばれる特定のタイプの記述子にフラグを設定することで行われます。

サービス、特性、記述子の階層構造を図72に示す。

図72 - サービス、特性、および記述子

GATTは2つの役割を定義している。GATTクライアント ATTコマンドとリクエストをGATTサーバーに送る。GATTサーバーは、GATTクライアント受け取ったコマンドとリクエストを受け入れ、処理し、GATTクライアント ATT通知、指示、応答を送る。

すべてのGATTサーバーには2つの特別なサービスが必須である。ジェネリック・アクセス・サービスと ジェネリック・アトリビュート・サービスである。

13.2 BluetoothSIG 対カスタム

一部のサービス、特性、記述子はBluetoothSIG 定義され、そのタイプを識別する16ビットのUUID値を持っています。定義された各タイプのBluetoothSIG リストは、specifications/assigned-numbersから入手できる。実装者は、https://support.bluetooth.com/hc/en-us/articles/360062030092-Requesting-Assigned-Numbers で説明されているように、16ビットUUIDや他のタイプの割り当て番号を購入することができる。

実装者は、カスタムサービス、特性、および記述子を定義することができる。カスタムサービス、特性、および記述子は、実装者によって割り当てられた128ビットのUUID値によって識別されるか、または実装者がBluetoothSIG16ビットのUUID値を購入することができる。16ビットUUIDはまた、0000XXXX-0000-1000-8000-00805F9B34FB（XXXXは16ビットUUID値）の形で等価な128ビット値を持つ。実装者は、BluetoothSIGUUIDを購入した場合を除き、この範囲のUUIDを使用することはできません。

GATTサーバーは、BluetoothSIG 定義されたサービス、特性、記述子（属性）のみを含む場合もあれば、BluetoothSIG 定義された属性とカスタム属性を混合して含む場合もあります。

13.3 手続き

サービスディスカバリー、特徴ディスカバリー、記述子ディスカバリー、特徴値の読み書き、特徴値の通知と指示などをカバーするGATT手順が定義されている。GATT仕様は、その手順と、これらの手順が使用しなければならない基礎となるATTプロトコルとの間の明確なマッピングを提供する。

13.4 例

13.4.1 BluetoothSIG 定義の属性のみ

図73は、一連のサービスとその特徴の例を示している。つの特徴関連する記述子がある。この例の各属性はBluetoothSIG定義されている。

図73-サービス、特性、記述子の例

表示されているサービスは、標準的な近接プロファイルを実装するデバイスがおそらく持っているサービスである(即時アラートサービスと TXパワーサービスは必須ではない)。アラートレベルの 特徴、リンクロスサービス内と即時アラートサービス内の2回出現していることに注意。UUIDはいずれの場合も同じです。これが、特徴 アラート・レベル 特徴識別したものです。しかし、特徴グループ化されているサービスは、異なるコンテキストを提供し、アラート・レベル 特徴に関連するルールと動作は、2つのサービス間で異なります。

サービス変更された 特徴通知をサポートするので、関連する特徴構成記述子を持つクライアント 通知または表示をサポートする特徴、その値（クライアントが書き込むことができる）が通知または表示が現在有効かどうかを制御するので、クライアント特徴構成記述子を持たなければならない。

13.4.2 BluetoothSIG カスタム属性の混合

図74は、BluetoothSIG 定義されたGATT属性と、1つのカスタム特徴含む1つのカスタムサービスが混在するGATTサーバーを示している。カスタムサービスは近接モニタリングサービスと呼ばれ、0x 3E099910-293F-11E4-93BD-AFD0FE6D1DFD の UUID タイプ識別子値を持つ。その特徴、クライアント近接特徴呼ばれ、0x 3E099911-293F-11E4-93BD-AFD0FE6D1DFD の UUID 値を持つ。このサービスと特徴、教育用開発者リソース『An Introduction to Bluetooth Low Energy Development』のプロジェクトで使用されていることに注意してください。18 を参照してください。Additional Resources」を参照してください。

図74 - BluetoothSIG 定義属性とカスタム属性の混合

14.ジェネリック・アクセス・プロファイル

14.1 基本

ブルートゥースコア仕様ジェネリックアクセスプロファイル(GAP)セクションは、デバイス発見と2つのデバイス間の接続確立に関する手順を定義している。一般的なデータのコネクションレス通信の実行方法、定期アドバタイズ使用方法（7.8.3 PADVB - LE定期アドバタイズ参照）及びアイソクロナス通信の設定方法（7.8.5 LE BIS 及び LE CIS - アイソクロナス通信参照）も、GAP がカバーするトピックである。

加えて、いくつかの主要なユーザー・インターフェース規格とBluetooth LE セキュリティの特定の側面も、コア仕様のこのセクションでカバーされている。

広告パケット(advertising)の送信とスキャンによるその受信は、GAPの多くの動作の中心である。多くの異なるアドバタイジングとスキャニングのパケットタイプがあり、これらはリンクレイヤー定義されている。ペイロードフィールドはAdvDataと呼ばれ、このフィールドはすべてのPDUタイプに存在するわけではないことに注意すべきである。このフィールドが存在する場合、そのフィールドに含まれるデータはADタイプとして知られる1つ以上の長さ/タグ/値の一連の構造体として符号化される。AD Type は、bluetooth.com の仕様ページから入手できる Core Specification Supplement (CSS) ドキュメントで定義されています。

GAP はBluetooth LE とBluetooth BR/EDR両方に関連する。本節の残りの部分では、Bluetooth LE に適用される GAP のみをカバーする。さらに、広告やスキャンのような活動は GAP と中心的な関連性を持つが、これらの手順は関係する PDU タイプと同様に、実際にはリンクレイヤー実行されることに注意すべきである。

14.2 役割

GAPは4つのデバイスの役割を定義している。これらを表16に示し、説明する。

役割	項目
ブロードキャスター	何らかの広告を利用して、コネクションレスでデータを送信する機器。これには、レガシーアドバタイズ、拡張アドバタイズ、定期アドバタイズ含まれる。放送事業者は、放送アイソクロナスストリームを送信することもできる。トランスミッター保有するが、レシーバー任意である。ブロードキャスターは、セントラルデバイスからの接続を受け付けない（ペリフェラルの役割も果たしている場合を除く）。
オブザーバー	Observerは、広告パケットまたはブロードキャストアイソクロナスストリームデータパケットを受信する。他のデバイスとは接続せず、レシーバー含み、トランスミッター含んでも含まなくてもよい。Observerはコネクションレスでブロードキャストデータを受信できる。
ペリフェラル	ペリフェラルはセントラルデバイスに接続することができる。トランスミッターレシーバー含む。
セントラル	セントラルはペリフェラルとの接続を開始することができる。トランスミッターレシーバー両方を含む。

表16 - GAPの役割

セントラルと ペリフェラルという役割名は、リンクレイヤー使われている。これら2つの異なる文脈における用語は、それぞれ同じ意味ではない。

14.3 発見

ブロードキャスターまたはペリフェラル・デバイスは、非検出可能モードにあるか、GAPが定義する2つの検出可能モードのいずれかにある。非ディスカバブル・モードでアドバタイズしているとき、送信されたパケットは無線で見えるが（これはセキュリティ機能ではない）、一般ディスカバブル手順または限定ディスカバブル手順のいずれかを実行しているスキャン・デバイスは、これらのパケットを無視する。

発見可能なデバイスは、一般発見可能モードまたは限定発見可能モードのいずれかである。一般発見可能モードでは、デバイスは無期限に発見可能であるのに対し、限定発見可能モードでは、最大3分間発見可能である。

ディスカバリング・デバイスは、AdvDataフィールドのFlagsと呼ばれるAD Typeを調べることで、アドバタイジング・デバイスがどのディスカバブル・モードにあるかを認識することができる。限定された検出可能モードは、おそらくボタンを押したり、単にデバイスを手に取って動かしたりするなど、ユーザーが最近相互作用したデバイスを優先するために使用されることが多い。

セントラルまたはオブザーバーデバイスが他のデバイスを発見しようとするとき、パッシブスキャンまたはアクティブスキャンのどちらかを使用することができる。この2つのうちどちらが許可されるかは、そのデバイスが一般的な発見可能モードでデバイスを発見しようとしているか、限定的な発見可能モードでデバイスを発見しようとしているかによる。

パッシブスキャンでは、スキャンPDUを送信せずに広告PDUを受信する。能動的スキャニングは、広告 PDU を受信し、スキャニング PDU を送信することで、応答としてより多くの情報を要求する。様々な PDU タイプはリンクレイヤー定義され、7.8.2 ADVB - LE Advertising Broadcast にまとめられている。

ブルートゥースコア仕様、レガシーアドバタイズ使用するデバイスもあれば、拡張アドバタイズ使用したり、両方の広告形式をインターリーブするデバイスもあることに注意すること。発見手順の1つを実行するデバイスは、両方のタイプの広告のスキャンをインターリーブすることが推奨される。また、デバイスがサポートする全ての PHY でスキャンすることを推奨する。

図75は、GAPディスカバリー・モードと他の関連変数を示している。

14.4 接続モード

広告デバイスは、使用されるPDUレガシーアドバタイズ）またはAdvModeフィールドの値拡張アドバタイズ）によって、接続可能かどうかを示すことができる。

図75は、GAPの接続モードと他の関連変数を示している。

デバイスは、GAPで定義されている接続関連手順のいずれかを実行することで、他のデバイスとの接続を要求することができる。これには一般に、接続を許可するいくつかのタイプのいずれかを受信した PDU に対する応答として、CONNECT_IND PDU (レガシーアドバタイズ) または AUX_CONNEXT_REQ PDU拡張アドバタイズ) のいずれかを送信することが含まれる。リンクレイヤー、広告と接続要求のPDUタイプと、応答として接続要求を送信できる PDUタイプに関する規則を定義する。7.8.2.2.3レガシーアドバタイズ関連するPDUタイプ、および 7.8.2.3.5拡張アドバタイズ関連するPDUタイプを参照のこと。

14.5 有向対無向

GAPによって使用される広告は、PDUを受信するすべてのオブザーバーまたはセントラルデバイスに適用可能であることを意味する無指向であるか、または特定のデバイスだけがそのようなPDUを処理すべきであることを意味する有向のいずれかである。有向広告に関わるPDUは、意図された受信デバイスのBluetoothアドレス持つTargetAフィールドを含む。非指向広告では、TargetAフィールドは存在しない。

図75は、GAPディスカバリーとコネクション・モードの文脈における有向広告と無向広告を示している。

図75 - GAPの発見と接続モード

AD TypeFlagsは、プライマリ広告チャネルで受信したレガシーアドバタイズ表示されることに注意。しかし、拡張アドバタイズ使用されているとき、AdvData フィールドはプライマリチャネルで受信した ADV_EXT_IND PDU には存在しない。Flagsが拡張アドバタイズ使用されている場合、汎用チャネル上の補助AUX_EXT_IND PDUに表示される。

14.6 スキャン可能 vs スキャン不可能

特定の広告PDUタイプはスキャン可能であると言われる。これは、そのようなPDUを受信したデバイスが、より多くの広告データを要求するために、適切なタイプのスキャン要求PDUで応答することが許可されていることを意味する。広告PDUはリンクレイヤー定義される。詳細については、7.8.2.2.3レガシーアドバタイズ関連する PDU タイプ、および 7.8.2.3.5拡張アドバタイズ関連する PDU タイプを参照のこと。

14.7 GAPとLEセキュリティ

GAP仕様では、多くのセキュリティ用語、モード、手順を定義している。一般的に、GAPのセキュリティ手順は、セキュリティマネージャプロトコル(SMP)やリンクレイヤースタックの他のレイヤーを含むが、特定の結果を達成するためにそれらのレイヤーを使用する高レベルの手順は、ブルートゥースコア仕様第3巻パートC(Generic Access Profile)で定義されている、に定義されている。

14.8定期アドバタイズ

定期アドバタイズ（応答あり、応答なしの両方）は、リンクレイヤー実行される（7.8.3 PADVB - LE定期アドバタイズ参照）、GAP はブロードキャスターが定期アドバタイズ入る手順と、オブザーバーが定期アドバタイズ列車と同期する手順を規定している。さらに、オブザーバーがブロードキャスターから定期アドバタイズ同期パラメータを取得し、ACL接続を介して別のデバイスに渡すことを可能にする定期アドバタイズ同期転送（PAST）手順がGAPで定義されています。

14.9 非同期ブロードキャスト

同報アイソクロナスストリーム及び接続アイソクロナスストリームを使用するアイソクロナス通信は、リンクレイヤー実行されるが（7.8.5 LE BIS 及び LE CIS「アイソクロナス通信」参照）、GAP は、ブロードキャスター及びオブザーバーがこの形式の通信を行うために従わなければならない手順を規定する。

15.セキュリティ・マネージャー・プロトコル

15.1 基本

セキュリティ・マネージャー・プロトコル（SMP）は、スタックのセキュリティ・マネージャー・コンポーネントの一部である。ペアリング、ボンディング、鍵配布などのセキュリティ関連手順の実行をサポートする。

セキュリティ・マネージャー・コンポーネントは、他のレイヤーが使用できるセキュリティ機能のための暗号ツールボックスを提供し、ペアリング・アルゴリズムを定義する。

セクション16.Bluetooth LEセキュリティ」では、一般的なセキュリティについて詳しく述べている。

15.2 例

図 76 は、2 つのデバイスのペアリング中に SMP が使用されている様子を示している。SMP ペアリング機能交換の間、入出力能力と他のフラグの交換に注意。これは、どのペアリング・アルゴリズムが選択され、認証ようなステップがどのように手順に組み込まれるかを決定する重要なステップである。

図76 - ペアリング中に使用されるSMP

16.Bluetooth LEセキュリティ

セキュリティは重要なテーマであり、慎重に検討し、理解する必要がある。

Bluetooth LE は、セキュリティ機能と特徴のコレクションを提供します。これは、特定のセキュリティアドレスし、特定のセキュリティ要件を満たすためのセキュリティツールを含むツールボックスと考えるべきである。製品セキュリティ要件を確認し、その要件を満たすことは、製品チームの責任である。適切な場合、これは選択されたBluetooth LE セキュリティ機能の使用を通じて達成されるべきである。

このトピックの重要性に鑑み、BluetoothSIG このトピックに特化した教育リソースが作成されました。18.その他のリソース」を参照してください。

17.アプリケーション

他のセクションで説明したBluetooth LE 機能が最終的に活用されるのはアプリケーションです。しかし、最新のブルートゥースコア仕様すべての機能が必ずしもアプリケーションで利用できるとは限りません。その主な理由は以下の通りです：

ブルートゥースコア仕様新機能がコンポーネントに実装され、パソコンやスマートフォンなど一般に入手可能な製品に搭載されるまでには時間がかかる。
Bluetooth LE 多くの機能はオプションであり、どの機能を含め、どの機能を省略するかは実装者の決定となる。実装者はコントローラチップの製造者である場合もあれば、BluetoothHost コンポーネントを含むオペレーティングシステムの開発者である場合もあります。そのため、アプリケーション開発するデバイスがブルートゥースコア仕様あるバージョンをサポートしているからといって、そのバージョンのすべての機能をサポートしているとは限りません。
デバイス上のBluetoothスタックが特定の機能サポートしていても、それがアプリケーション開発者が使用できることを意味するわけではありません。アプリケーション開発者はスタックを直接使用するのではなく、APIを使用します。Bluetooth機能 APIがない場合、例えばBluetoothコントローラがその機能サポートしていても、アプリケーションそれを使用することはできません。

ここでの教訓は、アプリケーション開発にコミットする前に、いくつかの調査を行うことです。特に、必要な機能のサポートを確認するためにAPIドキュメントをチェックし、実行する予定のハードウェアとオペレーティングアプリケーションシステムにおけるBluetoothスタック・コンポーネントの仕様をチェックすること。

18.追加リソース

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

リソース	項目	所在地
ブルートゥースコア仕様	主要な技術仕様。Bluetooth スタックの全レイヤーと関連するプロトコルや手順を定義する。Bluetooth LE とBluetooth BR/EDR両方をカバーしています。	スペック
プロフィールとサービス仕様	サービス仕様は、1つのGATTサービスを、そのサービスに含まれる特性および記述子とともに定義する。プロファイル仕様は、関連デバイスが担う役割を定義し、特にクライアント動作と、それが動作すべき接続サーバー上のデータを定義する。	スペック
LC3	LE Audio が使用する低複雑度通信コーデックを定義する。	スペック
スタディガイド - Bluetooth低エネルギー開発入門	スマートフォンや周辺機器との接続を重視したソフトウェア開発について学びたい開発者向けの教材。解決策を含む一連のハンズオンプロジェクトが含まれています。	bluetooth-resources/bluetooth-le-developer-starter-kit/
スタディガイド - ブルートゥース・メッシュ・ソフトウェア開発入門	Bluetoothメッシュとマイクロコントローラへのメッシュモデルの実装について学びたい開発者向けの教育リソース。ソリューション付きの一連のハンズオンプロジェクトが含まれています。	bluetooth-resources/bluetooth-mesh-developer-study-guide/
スタディガイド - Bluetoothメッシュプロキシ機能入門	Bluetoothメッシュネットワークのノードとのインタラクションを可能にするスマートフォンなどのデバイス用のGUIアプリケーションの作成方法を学びたい開発者のための教育リソース。ソリューションを含む一連のハンズオンプロジェクトが含まれています。	bluetooth-resources/bluetooth-mesh-proxy-kit/
論文 - ブルートゥース・メッシュ・ネットワーキング - 開発者のための入門書	Bluetooth Meshの主要なコンセプトと機能について学びたい人のための教材です。	bluetooth-resources/bluetooth-mesh-networking-an-introduction-for-developers/
論文 - ブルートゥース・メッシュ・モデル - 技術的概要	ブルートゥース・メッシュ製品で使用可能な標準モデルについて理解を深めるための教材。	bluetooth-resources/bluetooth-mesh-models/
スタディガイド -Bluetooth LE セキュリティを理解する	Bluetooth LE meshを除く）におけるセキュリティのあらゆる側面を説明し、解説する教材。セキュリティに関する全くの初心者にも、経験者にも適しています。解決策を含む一連の実践的プロジェクトが含まれています。	bluetooth-resources/le-security-study-guide/（ブルートゥース・リソース/ル・セキュリティ・スタディ・ガイド
論文 - ブルートゥースのセキュリティとプライバシーのベストプラクティス・ガイド	このガイドは、実装者が、特定のアプリケーションにおいて、利用可能な特定のセキュリティとプライバシーの選択肢が他よりも優れている、あるいは劣っている理由や、仕様にどのようなリスクや落とし穴が残されているかをよりよく理解できるようにすることを目的としている。	ブルートゥース・リソース/ブルートゥース・セキュリティ＆プライバシー・ベスト・プラクティス・ガイド/bluetooth-security-and-privacy-best-practices-guide/
スタディガイド - Linux開発者のためのBluetoothテクノロジー	LinuxのBluetoothスタックであるBlueZを使用したソフトウェアの開発について学びたいLinux開発者のための教育リソース。ソリューション付きの一連のハンズオンプロジェクトが含まれています。	bluetooth-resources/bluetooth-for-linux/
スタディガイド - Bluetoothインターネットゲートウェイの設計と開発	インターネットからBluetooth LE およびBluetooth meshデバイスへのアクセスを提供するために使用されるBluetoothインターネットゲートウェイについて説明する教材。可能なアーキテクチャと実装アプローチを説明。ソリューションを含む一連のハンズオンプロジェクトも含まれています。	bluetooth-resources/bluetooth-internet-gateways/
スタディガイド - Web Bluetooth入門	JavaScriptのWeb Bluetooth APIを使用したWebアプリケーションの開発について学びたい開発者のための教育リソース。解決策を含む一連のハンズオンプロジェクトが含まれています。	bluetooth-resources/web-bluetooth-tutorial/
スタディガイド - Bluetoothビーコン入門	Bluetoothビーコンについて学びたい開発者向けの教育リソース。ソリューション付きの一連のハンズオンプロジェクトが含まれています。	bluetooth-resources/ビーコン・スマート・スターターキット/
論文 -ブルートゥースコア仕様バージョン5.0機能強化	ブルートゥースコア仕様バージョン 5.0 でリリースされた新機能とその他の変更点を説明。LE 2M PHY、LE Coded PHY、拡張アドバタイズ含む。	bluetooth-resources/bluetooth-5-go-faster-go-further/
論文 -ブルートゥースコア仕様バージョン5.1機能概要	バージョン5.1でリリースされた新機能とその他の変更点について説明します。ブルートゥースコア仕様. 含まれるものAoA そしてAoD 方向検知。	bluetooth-resources/bluetooth-core-specification-v5-1-機能概要/
論文 -ブルートゥースコア仕様バージョン5.2機能概要	ブルートゥースコア仕様バージョン 5.2 でリリースされた新機能やその他の変更点について説明。拡張属性プロトコル、LE パワー制御、LEアイソクロナスチャネル含む。	bluetooth-resources/bluetooth-core-specification-version-5-2-機能概要/
論文 -ブルートゥースコア仕様バージョン5.3機能概要	ブルートゥースコア仕様バージョン 5.3 でリリースされた新機能やその他の変更点を解説。サブレーティングとLE チャネル分類使用したLE強化接続アップデートを含みます。	bluetooth-resources/bluetooth-core-specification-version-5-3-enhancements/ブルートゥースコア仕様のバージョンアップ。
Bluetooth^®コア仕様バージョン5.4 - 技術概要	ブルートゥースコア仕様バージョン5.4でリリースされた新機能やその他の変更点を解説。レスポンスと暗号化アドバタイズデータ含む定期アドバタイズ。	bluetooth-resources/bluetooth-core-specification-version-5-4-technical-overview/
Bluetooth^®コア仕様v6.0の機能概要	ブルートゥースコア仕様6.0の新機能や変更点を解説。BluetoothChannel Sounding、決定ベースのアドバタイズフィルタリング、アドバタイザーモニター収録。	コア-スペシフィケーション-6-機能-概要/Core-Specification-6-機能-概要/6
Channel Sounding 技術概要	Channel Sounding詳細な技術的概要を説明。	ブルートゥース・リソース/ブルートゥース・チャンネル・サウンディング-技術的概要/bluetooth-resources/bluetooth-channel-sounding-a-technical-overview/
電子書籍 -Bluetooth LE オーディオのご紹介	ニック・ハンが書いた本で、Bluetooth LE Audioの特徴と技術的なことをわかりやすく紹介しています。	オーディオブック
規制面に関する文書	Bluetooth LE 技術及び様々な地域に適用される RF 規制に関する BluetoothSIGの理解に関するガイダンス及び支援情報を提供する。	Bluetooth-resources/bluetooth-low-energy-regulatory-aspects-document-rad/

[1]Bluetoothの仕様については、セクション4で紹介しています。

[2]サービス、特性、記述子については、Generic Attribute Profile のセクションで説明されている。

[3] LE 2M 2BTはChannel Sounding 使用され、一般的なデータ通信には使用されません。

[4] Channel Sounding 特殊なケースであり、8.Channel Sounding説明しています。

[5] Bluetooth LE 及び RF 規制の詳細については、18.Regulatory Aspects ドキュメントの追加リソース

[6]第15章では、Bluetooth LE セキュリティについてより詳しく説明する。

[7] [8]定期アドバタイズアイソクロナスストリームについては、7.8 論理トランスポートで説明している。

[9]#nse - 1はサブイベントの数から1を引いた数

[10] LE Audio使用されている低コンプレックス通信コーデック

[11]12.4 ベアラー参照

ブルートゥース® 低エネルギー入門書

1.改訂履歴

2.本稿について

3.はじめに

4.Bluetooth LE 仕様

4.1ブルートゥースコア仕様

4.2 プロファイルの仕様

4.3 サービス仕様

4.4 プロトコル仕様

4.5割当番号

5.Bluetooth LE スタック

5.1 ハイレベル・アーキテクチャ

5.2 レイヤーの概要

6.物理層

6.1 周波数帯域

6.2 変調方式

6.2.1 ガウス周波数シフト・キーイング

6.2.2 振幅シフト・キーイング

6.3 PHY バリアント

6.4 時間分割

6.5 送信電力とレシーバー 感度

6.6 アンテナ切り替え

6.6.1方向検知

6.6.2Channel Sounding

7.リンクレイヤー

7.1リンクレイヤー概要

7.2 パケット

7.3状態 マシン

7.4 チャンネルの選択

7.5 フィルタポリシー

7.6アドバタイザーモニター

7.6.1 フィルタリングとプレゼンス

7.6.2 広告モニタリングの使用

7.7 データ・トランスポート・アーキテクチャ

7.8 論理トランスポート

7.8.1 LE ACL - LE 非同期接続指向論理トランスポート

7.8.2 ADVB - LE広告放送

7.8.3 PADVB - LE定期アドバタイズ 放送

7.8.4PAwR - LE 応答付き定期アドバタイズ

7.8.5 LE BIS および LE CIS - 非同期通信

8.Bluetooth® Channel Sounding

8.1Channel Sounding入門

8.2 デバイスの役割

8.3 データトランスポートアーキテクチャにおけるBluetoothChannel Sounding

8.4 ブルートゥース2Channel Sounding 法

8.4.1位相ベース測距

8.4.2 往復のタイミング

8.5Channel Sounding リンクレイヤー 制御手順

8.5.1Channel Sounding

8.5.2Channel Sounding 能力交換

8.5.3Channel Sounding 設定

8.5.4 Mode-0 FAE テーブル要求

8.5.5Channel Sounding

8.6 タイムディビジョン

8.7 パケットとトーン

8.8 ステップとモード

8.8.1 モード0

8.8.2 モード-1

8.8.3 モード2

8.8.4 モード3

8.9 モード・シーケンス

8.10 チャンネルとチャンネル選択

8.10.1 RFチャンネル

8.10.2 チャンネルフィルター

8.10.3 チャネル選択と周波数ホッピング

8.11 アンテナ切り替えとアンテナ経路

8.12RTT 精度

8.13 セキュリティ

8.13.1 スプーフィング

8.13.2 リレー攻撃

8.13.3Channel Sounding 機能

8.14 距離測定アプリケーション

9.アイソクロナス・アダプテーション・レイヤー

9.1 基本

9.1.1 オーディオ・サンプリング 101

9.1.2 コーデックとフレーム

9.2 額装と非額装

9.3 フラグメンテーションと組み換え

9.4 分割と再組み立て

10.Host

6.5 送信電力とレシーバー感度

7.3状態マシン

7.8.3 PADVB - LE定期アドバタイズ放送

8.Bluetooth^® Channel Sounding

8.5Channel Sounding リンクレイヤー制御手順