各機能の強化は専用のセクションで説明され、関連する背景情報の説明から始まる。これは、Bluetooth Low Energy（LE）の特定の側面に初めて接する読者にとって、より使いやすくなることを意図したものである。とはいえ、背景のセクションは完全に網羅されているわけではないので、馴染みのない用語や概念に遭遇した読者は、Bluetooth LE入門書をダウンロードして読むことを推奨する。

2.概要

2.1 ブルートゥースChannel Sounding

Bluetooth®Channel Sounding は、2つのデバイス間（Bluetooth ）の安全な測距を可能にします。測距とは、ある物体から別の物体までの距離を測定するために、特定の技術を使用することを意味します。

ワイヤレス測距は、デジタル・キー・ソリューションや「Find My」ネットワークなど、さまざまな製品に応用されている。新しいBluetooth Channel Sounding 機能は、このような製品が一般的に持つ困難な精度とセキュリティ要件を満たすことができる標準ベースの技術的アプローチを提供するように設計されています。

2.2 意思決定に基づく広告フィルタリング

Bluetooth LE Extended Advertising 機能は、プライマリおよびセカンダリ無線チャネルで送信される一連の関連パケットを含む。

決定ベースの広告フィルタリングにより、スキャンデバイスは、プライマリ広告チャネルで受信したパケットのコンテンツを使用して、次にセカンダリチャネルで関連するパケットをスキャンするかどうかを決定することができる。これにより、アプリケーションに関連するPDUが含まれていない可能性のあるパケットをセカンダリチャネルでスキャンする時間を短縮し、スキャン効率を向上させます。

2.3 広告主の監視

オブザーバ・デバイスのホスト・コンポーネントは、Bluetooth LE コントローラに重複するアドバタイジング・パケットのフィルタリングを指示することができる。このタイプのフィルタリングが有効な場合、ホストは各ユニーク・デバイスから単一のアドバタイジング・パケットのみを受信する（このコンテキストにおけるユニーク・デバイスを構成するコア仕様の定義に従う）。これはホストの効率を向上させるが、オブザーバーデバイスが今接続を試みるべき状況になったときに、そのデバイスがまだ範囲内にあるかどうかをホストが知る手段がないという欠点がある。このため、オブザーバーは、以前に発見されたデバイスのために高デューティサイクルのスキャニングを行うが、そのデバイスはもはや範囲内にないため、エネルギーを浪費する可能性がある。

新しいモニタリング・アドバタイザー機能は、ホスト・コントローラー・インターフェイス（HCI）イベントを使用して、対象デバイスが範囲内外に移動するたびにホストに通知する。

2.4 ISOALの強化

アイソクロナス・アダプテーション・レイヤー（ISOAL）は、より大きなデータ・フレームをより小さなリンク層パケットで伝送することを可能にし、受信機によるデータの正しい処理に必要な関連タイミング情報の再構成を保証する。

ISOALは特定の変数に応じて、フレーム化されたPDUまたはフレーム化されていないPDUを生成することができる。フレーム化されたPDUが生成される場合、結果として待ち時間が増加する可能性がある。

Bluetooth Core Specification version 6.0では、この問題に特に敏感なユースケースのために、遅延を短縮する新しいフレーミング・モードを定義することによって、ISOALが改善された。同じ機能により信頼性も向上している。

2.5 LL拡張機能セット

デバイスは、それぞれがサポートするリンク層機能に関する情報を交換することができる。この機能は、Bluetooth LE の高度化と多機能化に伴い、より多くの機能をサポートするために強化されてきた。

2.6 フレーム空間の更新

Bluetooth コア仕様の以前のバージョンでは、コネクションイベントまたはコネクテッド・アイソクロナスストリーム（CIS）サブイベントにおいて、隣接するパケットの送信を区切る時間の一定値が定義されている。この値は仕様ではT_IFSと呼ばれ、150 µsの固定値であった。

コア仕様のバージョン6.0では、コネクションまたは接続されたアイソクロナスストリームで使用されるフレーム間隔は交渉可能であり、150μsより短くても長くてもよい。

3.ブルートゥースChannel Sounding

3.1 背景

このセクションでは、Bluetooth LE テクノロジーの概要を説明し、Bluetooth®Channel Sounding の新機能をより理解しやすくします。

3.1.1 デバイスの位置決めとBluetooth LE

Bluetooth コア仕様でBluetooth LE が最初に規定されて以来、到着角度（AoA）および出発角度（AoD）方向探知のようなコア機能と、Find Me プロファイルのような多数の関連プロファイルにより、Bluetooth LE は位置情報サービスのための一般的な技術として確立してきた。

図1 - AoAとAoDを使った方向探知

さらに、標準的なBluetooth LE広告パケット内で送信されるいくつかの独自のビーコンメッセージフォーマットが広く採用されている。

多くのアプリケーションでは、2つのBluetooth デバイス間の距離を計算する必要がある。Bluetooth Core Specificationバージョン6.0がリリースされる以前は、パスロス計算と呼ばれる方法しか使用できませんでした。この方法では、受信デバイスが受信信号強度（RSSIと呼ばれる）を測定し、送信機から1メートルなどの基準距離でリモートデバイスが送信する信号の強度を知る必要があります。さらに、関連する物理学では、受信機での信号強度は送信機からの距離の2乗に反比例することが示されている。送信機の基準信号強度、RSSIとこの単純な数学的関係で、距離値を計算することができます。

図2 - 距離に対する逆2乗パスロス

パスロス計算は、距離計算の精度が要求され、その一貫性と信頼性が特に高くない場合に適しています。2つのデバイス間の距離が比較的小さい場合、信号強度が最初に急激に低下する（図2参照）ため、パスロス計算ではそれなりに良い結果が得られます。しかし、距離が長くなると、わずかな信号強度の変動が大きな可能距離範囲に対応し、計算が小さな誤差に非常に敏感になります。この方法は、干渉やその他の環境要因の影響を受けやすい。また、安全性に欠け、例えば距離スプーフィングなどの攻撃を受ける危険性がある。

資産追跡やキーレス・エントリー、イグニッション・システムなど、より困難なアプリケーションの要件には、より正確で信頼性の高い結果をもたらす、より洗練され、安全で、標準化されたアプローチが必要です。

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

Bluetooth Core Specificationは、Bluetooth データ・トランスポート・アーキテクチャを構成するいくつかの概念を定義している。これらの概念の中には、物理トランスポート、物理チャネル、物理リンク、論理リンク、および論理トランスポートがある。トポロジー、タイミング、信頼性、電力、チャネルの使用などの特性に関連する特定の特性を持つ。運用モードや 運用モードという用語は、様々なデータ・トランスポート・アーキテクチャ構成を指すために非公式に使用されることがある。

図3 -Bluetooth データ・トランスポート・アーキテクチャの一部

図3はデータトランスポートアーキテクチャの一部を示し、最も一般的に使用される2つの論理トランスポートと、それらに関連する物理リンク、物理チャネル、および物理トランスポートコンポーネントをハイライトしている。これらの論理トランスポートはどちらもBluetooth®Channel Sounding に関連しています。

3.1.2.1 LE-ACL

LE-ACL は最も一般的に使用されるBluetooth LE 論理トランスポート・タイプの 1 つであり、2 つのデバイス間のコネクション指向のデータ通信を提供する。実際、ACL 接続は一般に単に接続と呼ばれる。

接続を要求するデバイスはセントラルと呼ばれる。この要求を受け取り、許可する装置をペリフェラルと呼ぶ。

2つのデバイスがACL接続を確立するとき、その後の通信を支配するいくつかのタイミング・パラメーターについて合意する。これらのパラメータの中で重要なのは、接続間隔である。 コネクション・インターバル・パラメータは 、無線がこのコネクションのサービスに使用できる頻度をミリ秒単位で定義する。

ACL接続は暗号化されていてもよく、その場合、すべてのペイロードはパケット送信の前にリンクレイヤーによって暗号化され、相手デバイスのリンクレイヤーによって受信されたときに復号化される。

3.1.2.2 ADVB

ADVBはAdvertising Broadcast論理トランスポートである。コネクションレス通信モードを提供し、1つまたは複数のデバイスに同時にデータを転送したり、ペリフェラルデバイスの存在を示して他のデバイスに発見させたりするために使用される。

3.2 Bluetooth®についてChannel Sounding

3.2.1 概要

Bluetooth LE の Bluetooth®Channel Sounding 機能は、2つの異なる距離測定方法から構成され、それぞれ単独で、または組み合わせて使用することができます。この 2 つの方法は、Phase-Based Ranging（PBR）と Round-Trip Timing（RTT）と呼ばれる。

このシステムは、パスロス法よりもはるかに正確な距離測定値の算出をサポートし、干渉や環境要因の影響を受けにくく、多くのセキュリティ・メカニズムを組み込んでいる。

このセクションでは、Bluetooth®Channel Sounding について紹介する。より詳細で包括的な説明については、関連論文Secure Fine Ranging withBluetooth Channel Sounding を参照してください。 Bluetooth SIG ウェブサイトhttps://www.bluetooth.com から入手できます。

3.2.2 テクニカル・ハイライト

3.2.2.1 システム・アーキテクチャ

Bluetooth®Channel Sounding は、1:1 のトポロジーで接続された 2 つのデバイス間で行われる。自分から他のデバイスまでの距離を計算したいデバイスは Initiator と呼ばれる。もう一方のデバイスは Reflector と呼ばれる。

channel sounding の間、事前に合意されたタイムスロットの間、複数の双方向の交換が Initiator と Reflector の間で行われる。

Bluetooth スタックにおいて、channel sounding は、スタックのホスト部とは対照的に、主にBluetooth コントローラの機能である。Initiator のコントローラは、Host Controller Interface (HCI)を使用して、低レベルの測定値をホストに、そして最終的にはアプリケーションレイヤーに渡す。距離測定を計算するために、コントローラによって提供されたchannel sounding データを使用することは、アプリケーションの責任である。

図 4 - CS デバイスの役割とホスト/コントローラ機能の分布

Bluetooth Channel Sounding を使用する機器は、アンテナアレイを含むことがある。これにより、一連の異なる通信経路を提供し、マルチパス伝搬の影響を軽減することで、距離測定の精度を向上させることができる。

3.2.2.2 Bluetooth®Channel Sounding とデータトランスポートアーキテクチャ

図5は完全なデータ・トランスポート・アーキテクチャのサブセットを示し、channel sounding をサポートするために追加された新しい物理リンクと物理チャネルのタイプを示している。

図5 - CSとデータ・トランスポート・アーキテクチャ

Channel sounding は、2つのデバイス間のACL接続を使用して開始される。channel sounding が開始されると、ACL 接続はリンク層制御交換のトランスポートとして機能し続け、channel sounding 無線アクティビティスケジューリングのタイミング基準を提供する。Channel sounding は、新しいChannel Sounding 物理リンクとChannel Sounding 物理チャネルを使用する。

Initiator と Reflector の役割はそれぞれ、Central デバイスまたは Peripheral デバイスのどちらかが引き受けることができる。

3.2.2.3 距離測定方法

3.2.2.3.1 位相ベース測距（PBR）

PBR法は、位相として知られる無線信号の基本的な特性と、周波数および波長との関係を利用する。位相は波周期の何分の一かと考えることができ、一般に0～2πラジアンの角度で表される。位相の変化は、位相回転に起因することもある。

図6-数波周期内の位相値の例

図6は、無線信号内の点に対応する位相値の例を示している。複数の波周期にわたって値が周期的に繰り返されていることに注意してください。

PBR を使用する場合、Initiator は所定の周波数_f1で Reflector に信号を送信する。Reflector は、その応答を受信した Initiator に信号を返送し、受信した信号の位相を測定する。

図 7 - Initiator がchannel sounding の信号を送信し、Reflector がエコーする。

Reflector は、受信した信号を再度 Initiator にエコーバックする。周波数を変えると波長が変わり、その結果、Reflector からの応答を受信した Initiator が測定した位相_Pf2も変化する。

Initiator は、周波数差(f₁-_f2)、位相差(Pf₁-_Pf2)、および光速を含む公式を用いて、2 つのデバイス間の距離を計算することができる。

実際には、デバイスは通常2つ以上の異なる周波数で2つ以上の信号を交換します。これは、より低レベルの測定値を利用することで、アプリケーションが計算する距離測定の精度を向上させることができるからです。

Initiator が測定する位相値は、デバイス間の距離が長くなるにつれて変化するが、ある時点でゼロにリセットされ、位相値は繰り返され始める。これは、図 6 に示すように、位相回転の周期的な性質によるものである。距離測定の文脈では、同じ位相値が複数の異なる距離で発生する可能性があるため、この現象は距離曖昧性として知られています。距離アンビギュイティが最初に発生する正確なタイミングは、channel sounding 信号の周波数の差に依存します。この差の値は周波数分離として知られている。一般に、周波数分離が大きいほど、距離アンビギュイティは早く発生する。Bluetooth CSは1MHzの周波数分離を使用しており、距離のあいまいさは150m付近まで生じない。

距離のあいまいさの問題は、PBRを2番目の距離測定法であるラウンドトリップ・タイミングと併用することで解決できる。

3.2.2.3.2 往復タイミング（RTT）

RTT方式は、 InitiatorがReflectorにパケットを送信し、Reflectorが同じパケットを送り返すことを含む。この点においてのみ、PBR方式との類似性がある。

距離測定の計算を可能にするために、Initiator はパケット送信時にタイムスタンプを記録する。この時刻は、Time of Departure または ToD として知られている。Reflector からの応答パケットを受信するとき、それは再度タイムスタンプを記録し、この時刻は Time of Arrival または ToA として知られている。

ToDとToAの間の経過時間をTA-_Dと呼ぶとすれば、TA-_Dに光速（c）を掛け、（これは双方向の往復時間なので）2で割ることで移動距離の尺度を得ることができる。しかし、リフレクターがパケットを受信し、それを処理し、応答を作成し、それを送信するのにかかる時間は考慮されていないため、これは非常に粗雑な距離の見積もりとなる。しかし、光速（真空中）で移動する無線通信は、1マイクロ秒で300メートルも移動するため、飛行時間の計算における非常に小さな誤差が、計算距離に非常に大きな影響を与える可能性がある。したがって、無線信号が実際に飛行中に費やす時間を正確に測定することが、RTT法で正確な距離測定を行うための鍵となります。

Bluetooth Channel Sounding の RTT は、Reflector が受信した CS パケットを折り返して Initiator に送り返すまでの時間がわかっていることを保証する。

Bluetooth Core Specificationは、ToAとToDのタイムスタンプを取得するためのいくつかの異なる方法を定義している。どの方法を選択するかは、複雑さとその精度で異なる。最も正確な時間キャプチャ方法は、分数タイミング推定として知られています。ToAとToDの値をできるだけ正確にキャプチャすることで、最も正確な距離測定が可能になります。

3.2.2.4Channel Sounding 初期化

channel sounding を開始する前に、 Initiator と Reflector は暗号化された ACL 接続を確立していなければならない。この接続は、channel sounding 初期化手順に関連するリンクレイヤー制御 PDU のセキュアな交換のために使用される。

Bluetooth®Channel Sounding には独自のセキュリティ機能があります。最初に実行されるchannel sounding 手順は、CS Security Start 手順です。この手順では、両デバイスに初期化ベクタ（IV）、インスタンス化ノンス（IN）、パーソナライズ・ベクタ（PV）の値が設定されます。この値は、channel sounding の間、新しいセキュリティ機能である決定論的ランダム・ビット生成器（DRBG）の入力として使用されます。DRBG は、channel sounding セキュリティ機能の多くで使用されています（「3.2.2.10 Bluetooth」を参照）。 3.2.2.10 Bluetooth®Channel Sounding セキュリティの概要).暗号化された ACL 接続のセキュリティは、この重要なデータの交換を保護します。

Bluetooth®Channel Sounding 機能により、開発者は、使用される距離測定方法、測定の精度、手順による遅延、セキュリティ、その他の変数を制御したり、影響を与えたりするためのさまざまなオプションを利用できます。channel sounding また、CS Capabilities Exchange 手順を使用することで、2 台のデバイスが機能や嗜好に関する情報を交換することができます。

ケイパビリティ・データを交換したデバイスは、CS Configuration手順に参加し、channel sounding 手順の開始時に適用されるコンフィグレーション・パラメータに合意する。

PBR 方式を使用する場合、Reflector は Initiator から受信した信号を同じ周波数でエコーバックすることが期待される。しかし、すべてのデバイスは、意図された、あるいは望まれた 周波数と、実際に測定された生成信号の周波数が異なる場合、生成信号の周波数にある程度の不正確さを示すことがある。周波数は波長に直接関係しており、PBR法はこの関係に依存している。したがって、リフレクタからのエコー信号の周波数の不正確さは、距離測定の精度に影響を与える可能性がある。その結果、デバイスは、基準周波数の集合に対して、生成された信号の周波数と予想または要求された周波数との間の差の測定値を提供する、分数周波数オフセット作動誤差（FAE）テーブルと呼ばれるデータのテーブルを製造業者によって装備されている場合があり、ppm（Parts Per Million）で表されます。モード0を使用する[1]FAE Table Request]プロシージャを使用して、"Initiator "は、"Reflector "に FAE テーブルを要求することができ、その計算を実行するときに、このデータを考慮に入れることができる。

初期化手順が完了すると、channel sounding 。これには、アプリケーションで距離計算に使用できる測定値を取得する目的で、2つのデバイスがさまざまな種類の一連の交換を行うことが含まれる。

3.2.2.5 タイムディビジョン

Channel sounding には、一般的なBluetooth データトランスポートアーキテクチャ（3.2.2.2Channel Sounding およびデータトランスポートアーキテクチャを参照）のChannel Sounding 物理チャネルの使用が含まれる。これは、時間がどのように細分化され、RF活動に使用されるかを定義する。

3.2.2.5.1 イベント、サブイベント、ステップ

Channel sounding は一連の手続きの中で行われる。各手順はいくつかのイベントで構成され、各イベントはさらにサブイベントに分割される。この階層的なスキームにおける最終的な時間の区分がステップである。Initiator と Reflector の間の RF の交換は、ステップの中で行われる。

図8 -Channel Sounding 手続きの構成例

様々な設定パラメータが、異なるレベルのエレメント間の関係のカーディナリティ（例えば、サブイベントごとのステップ数）、イベントの持続時間、ステップで行われるアクティビティなど、この構造の側面を制御する。例えば、1つのサブイベントには常に最低2ステップ、最大160ステップが存在する。プロシージャーごとに最大256のステップがある。

3.2.2.5.2 タイミング・アンカー・ポイント

すべてのchannel sounding 手順、イベント、サブイベント及びステップの開始時刻は、channel sounding を開始するためのリンク・レイヤーの手順が実行された関連する LE ACL 接続の選択された接続イベントに直接的又は間接的に固定される。

3.2.2.6 Bluetooth®Channel Sounding ステップ

3.2.2.6.1 パケットとトーン

CSステップ中、デバイスはCS同期パケットとして知られる一連のパケットと、オプションとしてCSトーンとして知られるトーンを交換します。

CS Sync パケットは、LE 1M または LE 2M PHY のいずれかを使用して伝送できる。GFSK[2]変調方式は、他のBluetooth LE パケットと同様に、いずれの場合も使用される。

CSトーンは、振幅シフト・キーイング（ASK）を使用して、周波数が固定されたシンボルを作成する信号である。

ステップには関連するモードがあり、0から3までの番号が振られている。モードは、そのステップで行われる交換の詳細とその目的を定義する。

mode-0 ステップは較正に関係し、ある周波数の Reflector の発生が、どの程度 Initiator と異なるかを決定する。これは、周波数生成の差異を補正するための計算で使用される、Fractional Frequency Offset (FFO)と呼ばれる値をもたらす。Mode-0のステップでは、CS Syncパケットを交換する。
モード-1ステップでは、ラウンドトリップ・タイミング（RTT）法の適用にCS同期パケットを使用する。
モード 2 のステップでは、Phase-Based Ranging（PBR）のために CS Tone を交換する。
mode-3 ステップは CS Sync パケットと CS トーンの両方を交換し、RTT および PBR メソッドの両方のデータを 1 つのステップで収集できるようにする。モード 3 のサポートはオプションである。

どのステップ・モードがchannel sounding 手順で使用されるかは、Bluetooth Core Specificationのルールと、2つのデバイスによって合意された設定に依存する。これには、RTT および/または PBR など、どの距離測定方法を使用するかが含まれる。

3.2.2.6.2 モードの組み合わせとシーケンス

Bluetooth Channel Sounding は、アプリケーション層が設定中に行使する多くの制御を与えられながら、手順内で様々なパターンでステップモードを組み合わせたりシーケンス化したりすることを可能にする。アプリケーション・レイヤーは、channel sounding 手順の繰り返し回数や、交換されるパケットやトーンの数、ある面ではその内容に影響を与えるその他の変数も設定できます。

アプリケーションは、確立を求める最適な構成を決定する際に、距離測定の要求精度、遅延許容度、セキュリティニーズなどの問題を考慮する。例えば、交換機の数が多ければ多いほど、一般的に多くの測定値が得られ、精度の向上に役立つかもしれないが、その代償として待ち時間が長くなる。

各サブイベントには、常に少なくとも2つの異なるステップ・モードが存在する。モード0は常にすべてのサブイベントを開始し、1つまたは2つの他のモードが同じサブイベント内の他のステップに使用されることがある。これは、Bluetooth Core Specificationに示されており、ここでも表1に繰り返されている特定の許容される組み合わせに従う。

Main_Mode	Sub_Mode
Mode-1	None
Mode-2	None
Mode-3	None
Mode-2	Mode-1
Mode-2	Mode-3
Mode-3	Mode-2

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

表1では、Main_ModeとSub_Modeという用語も紹介している。これらの用語は、いくつかの設定パラメーターを用いてステップ・モードの繰り返しパターンを作成する方法に関するものである。設定手順により、モード1～3のいずれかがメイン・モードとなり、オプションで別のモードがサブ・モードとなる。

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

1つ以上のmode-0ステップがサブイベントを開始する。
その後、n個のメイン・モード・ステップのシーケンスが続くが、nはランダムに選択され、設定された範囲内に収まる。
一つのサブモードステップは、Bluetooth Core Specificationがsub_mode insertionと呼ぶプロセスに従って、n個のメインモードステップのシーケンスに続く。

ステップ・モード・シーケンスは、サブイベントが常に1つ以上のモード0ステップで始まらなければならないという一般的なルール以外には、サブイベントの境界に縛られることはない。フルシーケンスは複数のサブイベントにまたがることができる。

3.2.2.7 RFチャンネル

3.2.2.7.1 チャネルとチャネル・フィルタリング

channel sounding の目的のため、72 チャンネルが定義され、各チャンネルは 1MHz の幅と一意のチャンネル・インデックス値を持つ。これらのチャネルの配置により、LE の一次広告チャネルは確実に回避される。

チャンネル幅を通常の2MHzではなく1MHzにすることで、隣接するチャンネルを使用するPBR信号間の周波数分離を確保し、150m付近まで距離の曖昧さが生じないようにしている。

CS Channel Map と呼ばれる特別なチャネルマップは、どのチャネルをチャネル選択に含め、どのチャネルを避けるべきかを示す。リンクレイヤの制御手順によって、Initiator と Reflector は、ローカルの RF の状態に基づいて、このテーブルの更新を行うことができる。

周波数ホッピングは、利用可能としてマークされたチャンネルから新しいチャンネルを選択することを含む。これは通常、メイン・モード反復と呼ばれるモード・シーケンス機能が使用されている場合を除き、各ステップの実行直前に行われる。

3.2.2.7.2 チャンネルの選択

Channel Sounding 、3つのチャンネル選択アルゴリズム（CSA）が新たに定義された。これらは総称してCSA #3、個別にCSA #3a、CSA #3b、CSA #3cと呼ばれている。

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

CSA#3bとCSA#3cはどちらも非Mode-0ステップで使用するように設計されているが、channel sounding プロシージャーインスタンスではどちらか一方しか使用できない。

channel sounding の間、2つのチャンネルリストが保持される。最初のものは CSA #3a とモード 0 ステップのチャンネル選択でのみ使用される。もう 1 つは、CSA #3b または CSA #3c でモード 0 以外のステップに使用される。

CSA#3aとCSA#3bは同じように動作するが、異なるチャンネルリストに対して動作する。それぞれが同じアルゴリズムを使用し、含まれるとマークされたチャネルの順番をランダム化し、シャッフルされたチャンネルリストを作成する。シャッフルされたチャンネルリストの各エントリーは一意であり、一度だけ使用される。シャッフルチャンネルリストのすべてのエントリが使用されると、シャッフルチャンネルリストは再生成され、新しいランダム化されたチャンネルリストが作成される。

CSA #3cのアルゴリズムはCSA #3bと大きく異なる。チャネルマップに含まれるチャネルのサブセットがグループに編成され、そのグループ内で形状を形成するチャネルパターンが生成される。CSA #3c は、状況によっては、反射された信号経路を検出するのに有利な場合がある。詳細はBluetooth Core Specification を参照。 CSA #3cのサポートはオプションです。

3.2.2.8 LE 2M 2BT PHY

Bluetooth LE の物理層は、PHY として知られるいくつかの許可された構成の定義を含む。PHY の定義には、使用される変調方式と、シンボルレート、最小周波数偏差、帯域幅-ビット周期積（BT）などのパラメータが含まれる。

Bluetooth コア仕様のバージョン 6.0 以前には、3 つの PHY が定義されていた。それらの名前は、LE 1M、LE 2M、LE Coded である。LE Coded PHY は、パケットがエラー検出と訂正を可能にする追加的な符号化の対象となることを除けば、 LE 1M と同じである。

LE 2M 2BT と呼ばれる新しい物理層構成がバージョン 6.0 で導入された。この新しい PHY は、Bluetooth®Channel Sounding でのみ使用可能である。

表 2 に 4 つの PHY の比較を示す。

	LE 1M	LE Coded	LE 2M	LE 2M 2BT
Symbol Rate	1 Msym/s	1 Msym/s	2 Msym/s	2 Msym/s
BT	0.5	0.5	0.5	2.0
Min. Frequency Deviation	185 kHz	185 kHz	370 kHz	420 kHz
Error Detection	CRC	CRC	CRC	N/A
Error Correction	NONE	FEC	NONE	N/A
Requirement	Mandatory	Optional	Optional	Optional. Only to be used with Channel Sounding.

表 2 - PHY の比較

帯域幅-ビット周期積（Bandwidth-Bit Period Product：BT）は、信号の属性で、帯域幅とシンボルの持続時間の関係を示す情報である。

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

BT値を2.0にすると、channel sounding 、ある種の物理層攻撃に対する安全性が向上する。参照 3.2.2.10 Bluetooth®Channel Sounding セキュリティの概要.

3.2.2.9Channel Sounding ステップのSNRコントロール

無線トランスミッタの中には、その信号対雑音比（SNR）を指定された範囲内に収まるように調整する機能を持つものがある。SNR Control 機能は、CS Sync パケット送信のために、CS mode-1 と mode-3 ステップ中に使用する SNR 出力レベルに Initiator と Reflector デバイスが合意することを可能にする。SNR を調整することは、人為的に信号にノイズを混ぜることを含む。出力 SNR は両方のデバイスに既知であるため、このノイズの存在は 2 つの CS デバイスにとって問題ではありません。この手法により、ある種の物理層メイン・イン・ザ・ミドル攻撃のリスクが低減される。

3.2.2.10 Bluetooth®Channel Sounding セキュリティの概要

距離測定ソリューションに特有のセキュリティ問題は、一般的に、信頼されていないデバイスが、ある信頼されたデバイスを騙して、別の信頼されたデバイスが、何らかのアクションを許可または実行するために十分に近くにあると思い込ませる脅威を伴う。例えば、キーレス・エントリー・システムでは、悪意のあるデバイスがドア・ロックを欺き、関連する信頼できるワイヤレス・キー・カードが、ドアが自動的に解錠されるために十分に近くにあると思わせることができれば、権限のない者が侵入することができる。

距離測定に関連する一連の攻撃は、セキュリティ専門家によって認識されている。信頼されたデバイスからの通信を偽造する（スプーフィングとして知られる）スタンドアローンの悪意のあるデバイスを含むものもあれば、信頼されたデバイスからの信号を中継する中間者（MITM）攻撃の一種であり、通常、その過程で信号またはそのデジタル・コンテンツを操作し、信頼されたデバイスに信頼された相手との距離を誤算させる。このような攻撃の詳細は、巧妙さ、実装の複雑さ、コストにおいて様々である。

Bluetooth Channel Sounding には、距離計測のセキュリティ上の脅威への対策として機能する機能のコレクションが含まれている。これらの機能は4つのカテゴリーに分類される：

PBRとRTTの併用。

PBR法とRTT法の両方のデータを使って距離を計算することで、値をクロスチェックすることができる。有意な差がある場合、アプリケーションは疑ってかかるべきである。両方の方法をターゲットとし、クロスチェックによる検出を避けるために互換性のある十分に類似した結果を生成する攻撃は、実装が非常に複雑でコストがかかるとみなされる。

ビットストリームと送信パターンのランダム化。

ランダム・ビット値は、ビット・ストリームのランダムに選択された位置に伝送される。値と位置は、新しい決定論的ランダムビット生成器(DRBG)を使用して生成または選択される。Initiator と Reflector は、同じ IN、IV、PV 値を持つ ( 3.2.2.4 Bluetooth®Channel Sounding 初期化を参照)。を参照)、その結果、DRBG のそれぞれのインスタンスは、呼び出されたときにランダムに生成されたビットの同じストリームを生成する。つまり、2つの正規デバイスは、どのようなランダムなビット値がどこで生成されるかを知っていることになります。悪意のあるデバイスはIN、IV、PVの値を知らないため、これらの値を推測することしかできません。すべての交換でビットストリームのすべてのランダムな部分を推測できる確率は非常に低い。さらに、いくつかのタイムスロットはランダムに送信に使用されたり使用されなかったりしますが、これもDRBGによって制御され、正規のCS機器によってのみ予測可能です。

シンボル操作に対する防御

ある種のMITM攻撃は、ターゲット・デバイスが他の正当なデバイスまでの距離を誤って計算するように、無線シンボルを操作することを含む。このような攻撃は、潜在的なRFチャネルの範囲から攻撃者がほんのわずかなマイクロ秒の間に送信を見つけ、シンボルを素早く操作することに依存しています。
SNRコントロール機能を使用する際、送信にノイズが加わると、攻撃者が信号解析に費やさなければならない処理時間が増えます。十分な余分な処理時間が必要な場合、攻撃は効果がなくなります。
LE 2M 2BT PHY は、シンボルスパンが短いので、この方法でシンボルを傍受し、操作するのが難しい。

攻撃検知を含むRF信号解析技術

Bluetooth Core Specification には、Bluetooth®Channel Sounding に対する攻撃検知システムの記述が含まれている。これには、攻撃が進行中である確率をアプリケーション層に報告するための標準化されたメトリックが含まれています。このメトリックはNADM（Normalized Attack Detector Metric）と呼ばれます。NADM値は、受信信号の評価に基づいてコントローラによって割り当てられ、攻撃の可能性を示すスライディングスケールの形式をとる。表3は、Bluetooth Core Specificationから抜粋したNADM値の定義である。

NADM Value	Description
0x00	Attack is extremely unlikely
0x01	Attack is very unlikely
0x02	Attack is unlikely
0x03	Attack is possible
0x04	Attack is likely
0x05	Attack is very likely
0x06	Attack is extremely likely
0xFF	Unknown NADM. Default value for RTT types that do not have a random sequence or sounding sequence.

表3 - NADM値

さらに、Bluetooth コントローラの実装者およびアプリケーション開発者は、Bluetooth Channel Sounding セキュリティ機能によって提供される標準的なセキュリティ機能を、必要に応じて追加のセーフガードで補強することができる。

3.2.3 Bluetooth®に関する詳細情報Channel Sounding

Bluetooth Channel Sounding 機能のより広範なレビューについては、このトピックに特化した論文がBluetooth SIG によって作成されています。この論文のタイトルは『Secure Fine Ranging with Bluetooth®』 Channel Sounding で、 Bluetooth SIG ウェブサイトからダウンロードできます。

Bluetooth コア仕様は、実装者のための唯一の参考資料である。

4.意思決定に基づく広告フィルタリング

4.1 背景

本セクションでは、Bluetooth LE テクノロジーのうち、意思決定に基づく広告フィルタリング（DBAF）機能に関連する側面について説明する。

4.1.1 リンク層の状態

リンク・レイヤはBluetooth LE スタックの中で最も洗練された部分の一つである。リンク・レイヤは、様々な論理トランスポートの定義の一部である送受信機の動作パターンと同様に、無線伝送用のパケットと PDU を定義する。

デバイスはリンク・レイヤの1つ以上のインスタンスを持ち、各インスタンスはある時点で特定の状態にある。状態とその間の許容される遷移は、リンク・レイヤのステート・マシンによって定義される。

図9 - リンク層のステートマシン

表4は、各リンク・レイヤ状態の簡単な説明である。

State	Description
Standby	Device neither transmits nor receives packets.
Initiating	Responds to advertising packets from a particular device to request a connection.
Advertising	Transmits advertising packets and potentially processes packets sent in response to advertising packets by other devices.
Connection	In a connection with another device.
Scanning	Listening for advertising packets from other devices.
Isochronous Broadcast	Broadcasts isochronous data packets.
Synchronization	Listens for periodic advertising belonging to a specific advertising train transmitted by a particular device.

表 4 - リンク層の状態の説明

広告、スキャン、開始の各状態は、DBAF機能に関連している。

4.1.2 フィルター・ポリシー

フィルタポリシーは、リンク層が受信したパケットを受け入れ、次の処理段階に渡すかどうかを決定する基準を定義する。異なる状態で使用するために、多くのフィルター・ポリシーが定義されている。フィルター・ポリシーは、HCIコマンドを使ってホスト側で選択・設定することができる。

スキャンとイニシエータのリンク・レイヤ状態で使用されるフィルタ・ポリシーは、DBAFに関連している。

スキャニング状態にあるとき、受信した広告パケットに対して、リンク・レイヤ・インスタンスによってスキャニング・フィルタ・ポリシーが適用される。DBAF機能が追加される前は、2つの基本的なスキャニング・フィルター・ポリシーが定義されていた。フィルタリングされていないスキャニング・フィルタ・ポリシーでは、受信したすべての広告パケットが受け入れられる。フィルターされたスキャニング・フィルター・ポリシーを使用する場合、（ホストによって入力される）フィルター受け入れリストで識別されるデバイスからの広告パケットだけが受け入れられる。拡張スキャニング・フィルター・ポリシーは、PDUが広告パケットの宛先となるターゲット・デバイスのアドレスを含む、有向広告で使用するために定義される。

イニシエータフィルタポリシーは、スキャニングフィルタポリシーに似ているが、接続可能な広告PDUを選択することを意図している。[3]を選択するためのものである。DBAFの前に、2つのイニシエータフィルタポリシーが定義されていた。最初の場合、特定のデバイスからの接続可能な広告パケットのみが選択される。2つ目は、フィルタアクセプタリストのメンバであるすべてのデバイスからの接続可能な広告パケットが受け入れられる。

すべての場合において、フィルター・ポリシーの適用は、受信したパケットを受け入れるか、廃棄するかのどちらかをリンク層が決定することになる。

4.1.3 拡張広告

Bluetooth Core Specificationでは、いくつかの形式の広告が定義されている。広告ブロードキャスト(ADVB)論理トランスポートは、わずかにランダム化されたタイミングスケジュールに合わせて広告パケットを送信する。ADVBには、レガシー広告と呼ばれる基本的な形式と、拡張広告と呼ばれるより高度な形式がある。

レガシー広告では、チャンネルインデックス値が37、38、39の3つのプライマリ広告チャンネルのみでパケットを送信し、その他のセカンダリ広告チャンネルには関与しない。

拡張アドバタイジングはBluetooth LE RF チャンネルの全 40 チャンネルを使用する。ヘッダ・データは、ADV_EXT_IND PDU として知られる PDU タイプでプライマリ・チャネルに送信される。この PDU タイプは AdvData フィールドを含まないため、アプリケーション・データのペイロードは伝送されない。その代わりに、多くの場合、AUX_ADV_IND PDUを含む関連する補助パケットを参照するAuxPtrと呼ばれるフィールドを含み、37のセカンダリ広告チャネルの1つで送信される。AdvDataペイロードフィールドを含むのはこのPDUである。

AuxPtr は、補助パケットが伝送されるチャネル、使用される PHY、タイミングオフセットを示すチャネルインデックス値を含む。セカンダリチャネル上で送信され、プライマリチャネル上のパケットから AuxPtr フィールドによって参照されるパケットは、補助パケットとして知られ、参照されるパケットは、上位パケットとして知られる。

より大きなアプリケーションデータペイロードは断片化され、一連のリンクされたPDUとして送信されるかもしれない。このシリーズは AUX_ADV_IND PDU で始まり、いくつかの AUX_CHAIN_IND PDU で続く。AUX_ADV_IND PDUと連続する各AUX_CHAIN_IND PDUは、AuxPtrフィールドを使用してリンクされる。図 10 に、PDU チェーニングを特徴とする拡張広告の例を示す。

図10 - PDUチェーニングによる拡張広告

ADV_EXT_INDのような拡張広告PDUには拡張ヘッダーが含まれる。これには、Bluetooth Core Specification に記載されている規則に従って、PDU内の存在が必須、オプション、または条件付きである一連のフィールドが含まれる。

4.1.4 開始状態

開始状態では、デバイスはスキャン状態から接続状態への移行を求める。これは、ターゲットデバイスからの接続可能な広告PDUをリッスンし、それを受信した場合、CONNECT_IND PDU（レガシー広告）またはAUX_CONNECT_REQ PDU（拡張広告）で返信することで行う。

4.1.5 問題点

DBAFは、長時間の広告が使用されるような状況において、スキャン装置の効果的なデューティ・サイクルを改善する。これは、注意散漫として知られる問題に対処することで実現します。

4.1.5.2 注意力散漫

4.1.5.2.1 注意散漫とは何か？

プライマリチャネルで送信されるADV_EXT_IND PDUはアプリケーションレイヤーデータを含まない。場合によっては、Observer(スキャンデバイス)は AuxPtr を追いかけ、セカンダリチャネルで関連する補助 PDU を受信し、AdvData ペイロードフィールドの内容を調べてから、アドバタイズされたデータに興味があるかどうかを判断しなければならない。そのためには、プライマリ・チャネルのスキャンを停止し、AuxPtrフィールドで示されるセカンダリ・チャネルのスキャンに切り替えなければならない。

シナリオによっては、多くの場合、アドバタイズされたデータは何の興味もないことが判明するかもしれない。これは、ObserverがAuxPtrによって示されるセカンダリチャネルでスキャンしている間、プライマリチャネルではもはやスキャンしておらず、その結果、関連するパケットを見逃している可能性があるためである。

このように、AuxPtrに従ってアプリケーションレイヤーにとって興味のないパケットをスキャンし、受信するという状況は、ディストラクションとして知られている。

注意散漫はオブザーバの有効デューティサイクルを低下させる。注意散漫の結果、プライマリチャネルでパケットを逃すと、コネクションレスデータ転送メカニズムとして拡張広告を使用するデバイスが経験する全体的なデータ転送レートを低下させ、他のデバイスでは待ち時間を増加させる可能性があります。

4.1.5.2.2 広告セットと重複データ

拡張アドバタイジングPDUの拡張ヘッダーフィールドには、AdvDataInfo (ADI)と呼ばれるオプションフィールドが含まれる。ADIは2つのサブフィールド、Advertising Data ID (DID)とAdvertising Set ID (SID)を含む。SIDは、送信されたPDUが属する広告セットを識別する。DIDは、同じ広告装置によって送信され、同じ広告セットのメンバーであるPDUが新しいデータを含むときにのみ変化する乱数を含む。

AdvDataInfo は、プライマリチャネルで送信され、補助パケットが関連付けられた ADV_EXT_IND PDU に含めることができる。これにより、スキャンデバイスは関連する広告セットに属するPDUのみを選択し、既に受信した重複データを認識することができる。これらの条件のいずれかが適用されるとき、オブザーバはセカンダリチャネルで補助パケットをスキャンする必要性を回避することができる。

AdvDataInfoフィールドは、セカンダリチャンネルの無駄なスキャンを避けるのに役立つが、シナリオによっては十分に洗練されたメカニズムではない。

4.2 意思決定に基づく広告フィルタリングについて

4.2.1 概要

DBAFは、非公式に決定PDUと呼ばれるADV_DECISION_INDという新しいタイプの拡張広告PDUを導入する。このPDUタイプはADV_EXT_IND拡張広告PDUの代わりに使用されることを意図しており、同様にプライマリチャネルで送信される。

決定PDUは、スキャナが、関連するAUX_ADV_IND補助パケットに関心があるかどうか、したがって、そのAuxPtrフィールドで参照されるセカンダリチャネルでスキャンを開始するかどうかについて、より良い情報に基づいた決定を行うために評価することができる、アプリケーションで指定されたデータを含む。

広告デバイスは、関連デバイスが受信パケットが関連するかどうかを容易にチェックできるように、決定PDUのコンテンツを構成することができる。

スキャニングデバイスは、受信したデシジョンPDUのコンテンツに対して一連の論理チェックを適用するようにフィルターポリシーを設定することができ、これにより関連するパケットを確実に識別し、関連する補助パケットをスキャンしてアプリケーションのペイロードデータを取得することができる。

図11 - DBAFの概要

4.2.2 メリット

DBAFの利点は、受信パケットのコントローラによるフィルタリングを、アプリケーションがより高度に制御できることにある。アプリケーション指定のフィルタリングチェックに合格しない決定PDUは破棄され、補助パケットのスキャンは実行されないため、注意散漫になることはない。

ADV_EXT_IND拡張広告PDUの代わりに決定PDUを使用することで、実効デューティサイクルを大幅に改善し、ディストラクションの問題によるプライマリチャネルでのパケット見逃しの発生を低減できる可能性がある。これは、拡張広告を使用する広告デバイスが多数存在する環境で特に顕著になる。

拡張広告がデータ転送の基礎となるベアラとして使用されている場合（例えば、メッセージングトランスポートとして）、データスループット率は、そうでなければ妨害となるような通信があっても低下しない。

4.2.3 テクニカル・ハイライト

4.2.3.1 広告

4.2.3.1.1 決定 PDU

正式には ADV_DECISION_IND PDU として知られる決定 PDU は、LE 1M または LE Coded PHY 上のリンク層パケットで伝送される。図 12 は、ADV_DECISION_IND PDU の構造と、それが LE 1M （符号化なし）PHY 上のリンク層パケット内にどのように格納されるかを示している。

図 12 - LE アンコード・リンク・レイヤー・パケットと ADV_DECISION_IND PDU

AdvMode と Extended Header フィールドは、すべての拡張広告 PDU に現れる。AdvMode はアドバタイジングイベントタイプを示し、3つの値が定義されている。

AdvMode	Mode
0b00	Non-connectable and non-scannable
0b01	Connectable and non-scannable
0b10	Non-connectable and scannable
0b11	Reserved for future use

拡張ヘッダフィールドは、PDU タイプ、広告モード、PHY、アプリケーションの好みのような要因に依存する、様々な標準フィールドを含む。重複データの識別に使用される DID を含む AdvDataInfo (ADI) フィールドは、拡張ヘッダーフィールドである。

AuxPtrは、デシジョンPDUに含まれなければならない唯一の拡張ヘッダーフィールドである。

決定PDUに固有のフィールドは、決定タイプフラグフィールドと決定データフィールドである。

スキャンデバイスは、受信した決定PDUに対して行うチェックを指定することができ、そのようなチェックは、決定データフィールドで広告デバイスによって提供される、拡張ヘッダからのフィールド、信号強度（RSSI）または特定のタイプの補足データを含むことができる。

決定データには標準サブフィールドがあり、現在指定されているのは1つだけである。これは「解決可能なタグ」フィールドである。他のサブフィールドは将来定義されるかもしれない。解決可能タグのような標準サブフィールドで消費されないスペースは、追加の任意のデータに使用することができる。

図13 - 「決定データ」フィールド

決定タイプフラグ(Decision Type Flags)フィールドは、決定データ(Decision Data)フィールドにどのサブフィールドが存在するかを示す。設定されたビットは、Bluetooth Core Specification のフィールド内のビット位置に関連付けられたサブフィールドの存在を示す。位置ゼロのビットは解決可能タグサブフィールドに関連する。他のすべてのビットは将来の使用のために予約されている（RFU）。

4.2.3.1.2 デシジョンPDUの設定

広告主のホストは、決定PDUを使用して広告を設定し、開始する責任を負う。

決定タイプ・フラグと決定データ・フィールドの値はホストから供給されなければならない。これは HCI コマンド、LE Set Decision Data を使用して達成される。このコマンドのパラメータは、アドバタイジング・セットを識別するアドバタイジング・ハンドル、デシジョン・タイプ・フラグ、デシジョン・データ長、デシジョン・データである。このコマンドは、アドバタイジング・セットの作成後、アドバタイジング開始後を含め、いつでも呼び出すことができる。つまり、アプリケーションレイヤーは、必要なときにいつでも決定データフィールドを変更できる。

HCI コマンドLE Set Extended Advertising Parametersは、例えばアドバタイジング間隔を含むアドバタイジング・セットの主要変数を設定するために使用されます。コマンドのパラメータの1つであるAdvertising_Event_Propertiesは、設定されているアドバタイジング・セットに関連する様々なホスト要件を示すビット・マスクです。例えば、ビット0が設定されている場合、ホストはコントローラが接続可能なアドバタイジングモードを使用する必要があることを意味します。ビット1が設定されている場合、アドバタイジングはスキャナブルである必要があります。

Advertising Event Properties パラメータ定義が更新され、ビット 7、8、9 を決定 PDU と組み合わせて使用できるようになった。表 5 に、これらのビットの意味をまとめる。

Bit	Meaning
7	Use decision PDUs when advertising
8	Include AdvA in the extended header of all decision PDUs
9	Include ADI in the extended header of all decision PDUs

表 5 - 広告イベントのプロパティと決定 PDU

示されるように、広告イベントプロパティのビット7を使用して、ホストは、関連する広告イベントで決定PDUを送信するようにコントローラに指示することができる。スキャニングデバイスのコントローラが使用するために指定できるデシジョンPDUチェックが洗練されているため、アドバタイザーのデバイスアドレスおよび/またはADIフィールドが不要な場合があり、ビット8および9により、いずれかまたは両方を除外することができるため、パケットを8オクテット短縮し、LE 1Mの通信時間を64μs短縮できる可能性がある。

4.2.3.2 スキャン

4.2.3.2.1 決定スキャニングフィルタポリシーモード

スキャニング・デバイス上のアプリケーションが決定ベースの広告フィルタリングの使用を希望する場合、Bluetooth コントローラにその旨を示す必要がある。これは、HCILE Set Extended Scan Parametersコマンドと、Scanning Filter Policyパラメータのビット 2 と 3 を使用します。

これらのビットを使って、3つのモードのいずれかを選択することができる。

Value	Meaning
0b00	No decisions mode. In this mode, decision PDUs are ignored.
0b01	All-PDUs mode. All types of advertising PDU are selected. Decision PDUs are subject to checks specified by the host. Other advertising PDUs are subject to the basic filter policy.
0b11	Decisions-only mode. Only decision PDUs are selected. These are subject to checks specified by the host. Those that pass are reported to the host in HCI advertising reports. Those that fail are discarded.

4.2.3.2.2 決定指示

スキャン・デバイス上のアプリケーションは、LE Set Decision Instructionsコマンドを使用して、フィルタ・ポリシーの実行においてリンク・レイヤがデシジョン PDU に適用しなければならないテストを指定します。

コマンドに対する3つの配列パラメータにより、ホストは実行するテストを設定することができる。

Parameter	Meaning
Test_Flags[i]	The first 4 bits of this field have defined meanings. Bit 0 – Creates partitioned groups of tests. See below. Bit 1 – The test passes if the decision data contains the relevant field and the check made against its value *passes. Bit 2 – The test passes if the decision data contains the relevant field* and the check made against its value *fails. Bit 3 – The test passes if the decision data does not contains the relevant field.* The value in Test_Field[i] identifies the relevant field. Note that the term “relevant field” applies both to fields in the advertising PDU that may be used in decision checks and values which may be measured (e.g. RSSI) or otherwise calculated (e.g. path loss) and used in decision checks.
Test_Field[i]	Identifies the decision data against which the check will be made. The data available for use in decision tests are: Resolvable Tag subfield in Decision Data AdvMode – advertising mode RSSI – received signal strength indicator Path loss calculated from the TX Power field (which must be present) and RSSI AdvA — the advertising device’s address Arbitrary Data (with various options re: minimum length of such data for the field to be regarded as present) Vendor-specific
Test_Parameters[i]	Values to use in checks against the relevant field. The format of this field depends on the relevant field identified in the Test_Field[i] parameter.

4.2.3.2.3 試験グループ

3つのパラメータ配列Test_Flags、Test_Field、Test_Parametersで表されるテストの配列は、1つ以上のテストグループに分割されます。

Test_Flags[0]、Test_field[0]、Test_Parameters[0]で表される最初のテストは、最初のテストグループのメンバー。配列内のテストを繰り返し、Test_Flags[i]の最初のビットが設定されている場合、それは新しいテストグループのメンバー。設定されていない場合は、インデックス値[i - 1]で参照される、配列内の前のテストと同じグループのメンバー。表 1 に例を示す。

Index	Test Flags	Group Membership
0	0b0011	Start of a new group (bit 0 = 1).
1	0b0010	Test is a member of same group as test[0].
2	0b0011	Start of a new group (bit 0 = 1).
3	0b0100	Test is a member of same group as test[2].
4	0b0010	Test is a member of same group as test[2].

表6 - Test_Flagsビットゼロで制御されるグループメンバーシップの例

同じグループに属するテストのいずれかが失敗した場合、そのグループ内のすべてのテストが失敗したとみなされる。

4.2.3.2.4 試験評価

以下の説明では、テストとは、Test_Flags、Test_Field、Test_Parameters パラメータ配列の並列要素にエンコードされた条件であることに注意すること。チェックとは、特定のデシジョン PDU から取得または導出された特定の値を使用したテストの評価を意味する。

リンク・レイヤは、受信した各決定PDUのDBAFテストを以下のように評価する：

ホストによって指定された各試験について、関連するフィールドの可用性が最初にチェックされる。これは、受信した PDU にフィールドが存在するか、またはテストで使用する指定値を計算または測定できることを意味する。Test_Flags[i]のビット 3 は、必要なフィールドが存在しないことが、そのテストが合格であるか不合格であるかを示す。

該当するフィールドが存在する場合、Test_Field[i]とTest_Parameters[i]にエンコードされているチェックが評価されます。ビット1とビット2は、チェックが合格か不合格かを判定するために使用されます。

グループは、グループ内の各テストが同じグループ内の他のテストと論理 AND で関連する複合条件の指定を可能にする。言い換えれば、グループ全体が合格するためには、グループ内のすべてのテストが合格しなければならない。

(group 1 test 1) AND (group 1 test 2) AND (group 1 test 3)

表7 同一グループ内のテスト間の論理関係

試験指示のフルセットのコンテキストでは、1つ以上の試験グループが合格した場合、試験セット全体が合格したとみなされる。言い換えれば、各グループは論理和で他のグループと関連している。

(group 1) OR (group 2) OR (group 3) OR (group 4)

デシジョンPDUのフィールドまたはそこから派生した値に基づいて個々の条件チェックを策定する能力と、一連のテストグループに基づいてより複雑な複合条件をエンコードする能力の組み合わせにより、DBAFはアプリケーションの強力なフィルタリングメカニズムとなる。

4.2.3.2.5 関連フィールドの操作

どのようにチェックが行われ、Test_Parameters[i]エントリの内容がどのようにフォーマットされるかは、Test_Field[i]で示される関連フィールドによって異なります。Bluetooth Core Specificationには、関連するフィールドの種類ごとに、フォーマットとルールの詳細が記載されています。

解決可能なタグ

Test_Parameters[i]	PDU Data	Check
A 128-bit *key* value.	Decision Data contains a *hash* value and a pseudo random number (*prand*).	Check passes if hash value equals the value obtained by evaluating ah (key, prand). ah is a hashing function defined in the core specification.

アドモード

Test_Parameters[i]	PDU Data	Check
A 3-bit Event Type value. The three bits act as flags that map to the three possible values of the AdvMode field.	AdvMode is included in the decision PDU.	Check passes if AdvMode is any of the values indicated by an EventType flag as accepted.

RSSI

Test_Parameters[i]	PDU Data	Check
A range of RSSI values expressed as a minimum and a maximum in dBm.	Measured by the controller for each received packet.	Check passes if the measured RSSI falls within the range specified in the test.

パスロス

Test_Parameters[i]	PDU Data	Check
A range of path loss values expressed as a minimum and a maximum in dBm.	Calculated by the controller as the difference between the TX Power field in the received PDU and the RSSI for that packet.	Check passes if the calculated path loss falls within the range specified in the test.

アドバ

Test_Parameters[i]	PDU Data	Check
Contains a field called *Check* that indicates how to check the AdvA address field in the received decision PDU and zero, one or two test address values and types.	AdvA is a field which may be included in decision PDUs.	Depending on the *Check* parameter field, evaluation of the check will pass if either: 1. AdvA in the PDU is in the controller’s Filter Accept List. 2. AdvA in the PDU matches the first of two possible addresses in the Test_Parameters[i] field. 3. AdvA in the PDU matches either of the two addresses in the Test_Parameters[i] field.

任意のデータ

Test_Parameters[i]	PDU Data	Check
Contains an 8-octet *Mask* and an 8-octet *Target* value.	The decision PDU Decision Data field contains an Arbitrary Data subfield.	The controller performs a bitwise AND of the *Mask* and the Arbitrary Data value (zero-padded if necessary). If the result matches the *Target* parameter, the check passes.

ベンダー別

Test_Parameters[i]の値の解釈と、テストで適用される条件ロジックは、定義上、ベンダー固有である。

4.2.3.2.6 解決可能なタグと鍵の共有

解決可能なタグは、PDUを特定のアプリケーションとデバイスに関連するものとしてラベリングする簡単な方法を提供する。このシステムが機能するためには、ハッシュ生成とチェックに使用されるキー値を適切なデバイス間で共有する必要がある。この仕組みと手順は、将来のGATT属性およびプロファイル仕様で定義される予定です。

4.2.3.3 開始

Hostは、コントローラの開始フィルタ ポリシーを、サポートされる多くの方法で動作するように構成する。決定PDUがポリシーに関与する場合、決定命令の適用という点で、受信したPDUの処理は、スキャン状態のときと同じである。

5.広告主の監視

5.1 背景

本セクションでは、「広告主の監視」機能に関連するBluetooth LE テクノロジーの側面について説明します。

5.1.1 デバイス・ディスカバリー

Bluetooth LEにおける広告の目的の一つは、デバイスの発見を容易にすることである。小さなデータパケットを一定間隔でブロードキャストすることで、デバイスはその存在を圏内にある他のデバイスに通知する。同時に、デバイスは他のデバイスからの接続を受け入れる意思と能力を示すこともできる。

他のデバイスの発見はスキャンによって達成される。スキャニングは、デバイスの無線を一定時間ごとに受信モードにし、その間にプライマリ・チャンネル（Bluetooth LE）の送信をリッスンする。スキャニング・デバイスがリスニングしているチャンネルで広告デバイスがパケットをブロードキャストすると、スキャニング・デバイスはそのパケットを受信し、広告デバイスが発見されたと言える。

デバイス発見を目的とした広告は、Bluetooth LE技術の基本的な考え方である。

図14 - 広告とスキャン

5.1.2 接続

広告デバイスを発見したら、次のステップとして、スキャンデバイスが広告デバイスへの接続を試みるのが一般的である。

接続は、ADV_IND PDUのようなレガシー広告PDUに対する応答としてCONNECT_IND PDUを送信することによって、またはAUX_ADV_IND拡張広告PDUに対する応答としてAUX_CONNECT_REQ PDUを送信することによって達成される。いずれの場合も、接続要求は応答されるPDUと同じチャネルで送信される。

応答として接続要求を送信できるPDUを受信するためには、接続デバイスがまずスキャンを行う必要がある。多くの場合、接続は迅速に確立されることが望ましく、そのために高デューティサイクルスキャンが使用される。これは、接続可能な広告パケットをできるだけ早く受信する確率を最大化するために、無線機のスイッチを入れ、高い割合の時間、受信モードにすることを含む。一般にスキャニングは比較的電力を消費する動作であり、高デューティ・サイクル・スキャニングはさらにその傾向が強い。

図15 - 接続

5.1.3 レンジ

スキャニング・デバイスは、2つのデバイスが互いの範囲内にある場合にのみ、広告デバイスからのパケットを受信し、それに応答することができる。範囲は、送信パワー、受信感度、環境の性質など、多くの問題に左右される。送信機として動作するデバイスの範囲は、受信機として動作するデバイスの範囲と同じとは限りません。また、通信が行われている他のデバイスの範囲は、最初のデバイスが示す範囲とは異なる可能性があります。

圏外だからといって、他のデバイスから送信された信号が受信されていないとは限りません。あるデバイスは他のデバイスからの送信を受信できるかもしれないが、受信信号強度とバックグラウンド・ノイズの比（すなわちSNR）が、受信機があまり高いエラー率なしに送信からデータを抽出することを妨げる場合、2つのデバイスはどう見ても圏外であるため、圏外とみなされる。

3.1.1 位置情報サービスとBluetooth LE で説明されているように、RSSI は距離の大まかな代理として機能し、パスロスの計算に使用することができる。アプリケーションによっては、他のデバイスへの接続は、そのデバイスが圏内にあり、かつ十分に近い場合にのみ意味を持つ。ユースケースは、この評価の重要な部分かもしれない。もしかすると、ユーザーが他のデバイスにかなり近い場合にのみ、接続する意味があるかもしれません。そのため、アプリケーションが他のデバイスとの接続を正当化できるほど十分近いと判断する前に、RSSI測定が定期的に行われ、評価されることがあります。

5.1.4 重複のフィルタリング

広告パケットは、リンク層がスキャン状態にあるときに、Bluetooth LE コントローラのリンク層によって受信される。広告デバイスは、設定された時間間隔で繰り返しパケットを送信する。デバイス発見目的で使用される場合、広告パケットの内容は時間の経過とともに変化しない傾向がある。

コントローラが1つまたは複数のデバイスから受信した広告パケットのデータは、 HCIイベントでホストに通知される。ホストへの広告データの報告用に、いくつかのHCIイベントタイプが定義されている。例えば、レガシー広告の場合、LE 広告レポート・イベントが使用されます。拡張広告の場合、LE 拡張広告報告イベントが使用される。定期広告が使用されている場合、LE Periodic Advertising Report イベントが使用される。

アドバタイジング、特に環境にある複数のデバイスからのアドバタイジングは、多くのHCIアドバタイジングレポートを生成する可能性があり、それぞれが内部トランスポートを介してコントローラからホストに渡される。APIを使用して広告データの受信を登録するアプリケーションは、多くのコールバックを受信するが、これらのコールバックで配信されるデータは不変であるため、価値が疑わしいことに気付く可能性がある。

しかし、同じデバイスから変化のない広告パケットを繰り返し受信することには、それなりの価値がある。それは、スキャンデバイスが相手のデバイスが現在範囲内にあるかどうかを追跡することを可能にする。

幸いなことに、ホストがスキャンを有効にするHCIコマンド（LE Set Scan EnableおよびLE Set Extended Scan Enable）には、それぞれFilter_Duplicatesというパラメータがあります。これにより、ホストは、重複する広告レポートをコントローラに通知するかどうかを指定できます。

図16は、重複フィルタリングを有効にしていないホストでスキャンが有効になっている状態を示している。

図16 - 広告パケットとレポート

図17は、重複フィルタリングをオンにしてスキャンを有効にしている。最初に受信したアドバタイジングパケットだけが、ホストにアドバタイジングレポートを送信していることに注意。

図 17 - 重複広告 PDU のフィルタリング

Filter_Duplicatesオプションは、全デバイスからの全広告パケットに作用するため、特定のデバイスだけに適用して、他のデバイスからの広告パケットをフィルターせずに残す方法はない。

したがって、アプリケーションには選択肢がある。最初の選択肢は、すべてのアドバタイジング・レポートを受信し、別のデバイスが範囲内にあるかどうかをかなり最新の状態で認識し続けることですが、これは多くのHCIトラフィックとアプリケーションコードへのコールバックを生成することを受け入れます。もう1つの選択肢は、重複する広告レポートのレポートを抑制するが、対象のデバイスが範囲内に留まり続けているかどうかをすぐに見失うことである。これらのオプションはどちらも理想的ではありません。

5.1.5Bluetooth LE オーディオとアクセプターの可用性

Common Audio Profile (CAP) の用語では、Acceptor は Initiator と呼ばれる別のデバイスからのオーディオストリームを受諾することができるデバイスである。Filter Accept List（4.1.2「Filter Policies」参照）には、しばしば Initiator がボンディングされているデバイスのアドレスが入力されるので、 Initiator は Filter Accept List（4.1.2「Filter Policies」参照）を使用しないことを推奨する。パーソナルオーディオデバイスがボンディングされている可能性が高いが、LE Audio はパーソナルオーディオ以上のものである。

最適なユーザーエクスペリエンスのためには、オーディオストリームを確立する必要があるとき、これはできるだけ少ない待ち時間で起こるべきである。したがって、アクセプタ候補が範囲内にあるかどうかを追跡することが望まれます。再度スキャンして接続する前段階として、オーディオデバイスがまだ範囲内にあることを確認するためだけにスキャンすることは、レイテンシとユーザーエクスペリエンスに悪影響を及ぼす時間とエネルギーの浪費です。

LE Audioのユースケースは、Monitoring Advertisers機能の設計に影響を与えた重要なシナリオの一つです。

5.2 広告主の監視について

5.2.1 概要

Filter_Duplicatesパラメータを使用して、すでにホストに報告されたものと同一の広告パケットの報告を抑制すると、ホストは、その広告デバイスに接続する時が来たときに、その広告デバイスがまだ範囲内にあるかどうかわからないままになる。接続は通常、高価で高いデューティ・サイクルのスキャンを伴いますが、ターゲット・デバイスがもはや範囲内にない場合、このアクティビティは完全にエネルギーの無駄になります。広告主の監視機能は、この問題を解決します。

モニタリングアドバタイザ機能を使用する場合、ホストは、1つまたは複数のアドバタイジングデバイスの存在を追跡するようにコントローラに指示する。受信したアドバタイジングパケットごとにアドバタイジングレポートでホストを圧倒するのではなく、モニタリングアドバタイジングは、監視対象デバイスが範囲外になったときに1回、範囲内に戻ったときにもう1回、ホストに通知します。これにより、アプリケーションは接続したいデバイスを効率的に追跡することができます。また、アプリケーションの信号強度要件も考慮されます。

デバイスが範囲内にあることが通知され、アプリケーションが監視対象デバイスの1つに接続することを決定したとき、接続に先立つスキャンが無駄な努力になる可能性は低い。ターゲット・デバイスが存在し、範囲内にあるはずなので、スキャンによって広告パケットが得られ、それに応答して接続リクエストを送信することができる。

モニタリング・アドバタイザーは、フィルター・アクセプタ・リスト（4.1.2 フィルター・ポリシーを参照）とは独立して動作するため、スキャン・デバイスとボンディングされているかどうかに関係なく、ボンディングされたデバイスのみにフィルター・アクセプタ・リストを使用し、すべてのデバイス全般にモニタリング・アドバタイザーを使用することが容易になります。

エネルギー効率の改善とより良いユーザ体験を通じて、「広告主の監視」機能から恩恵を受ける多くの状況と製品タイプがある。オーディオ・ストリームを開始する LE オーディオ・デバイス（CAP イニシエータ）は、この機能が定義された製品のカテゴリの 1 つである。

5.2.2 テクニカル・ハイライト

5.2.2.1 監視対象広告主リスト

Bluetooth Core Specificationは、Monitored Advertisers Listを定義している。これは、コントローラのデータ構造で、ホストが追跡したいアドバタイザデバイスのリストを格納する。

リスト内の各デバイスにはいくつかのパラメータが付随しており、各エントリーは関連するタイマーを持つと考えることができる。さらに、各エントリには、実装によって維持される「Awaiting RSSI High」と呼ばれる状態があります。この状態は、監視対象デバイスが範囲内にあるかどうかを示します。Awaiting RSSI Highがtrueの場合、そのデバイスは圏外です。

監視対象アドバタイザリストのパラメータを理解することで、コントローラによる監視の仕組みを理解できます。

Parameter(s)	Description
Address and Address Type	The address and address type of the device to be monitored. These two parameters allow the controller to identify and monitor the device.
RSSI Threshold Low	If the RSSI of all advertising packets from this monitored device stays at or below this value for the period of time indicated by the Time Out parameter then it is said that a loss-of-signal has occurred. When this happens, the controller notifies the host using an HCI LE Monitor Advertisers Report event. The state of this device set to Awaiting RSSI High.
RSSI Threshold High	If the RSSI of an advertising packet received from this monitored device is greater than or equal to this value, and the device state is Awaiting RSSI High then the controller sends a HCI LE Monitor Advertisers Report event to the host to inform it that the device is in range. The state for this device is cleared or set to indicate that it is no longer awaiting an RSSI above the high threshold and the timer that is used to monitor for loss of signal is reset.
Time Out	A time in seconds used to monitor for signal loss. If no RSSI measurement exceeds the RSSI Threshold Low parameter in this period then loss-of-signal is said to have occurred.

5.2.2.2 ホストコントローラーインターフェース

ホストは、モニタリング・アドバタイザー・リストを設定し、ホスト・コントローラ・インターフェイス（HCI）を使用して、モニタリング・デバイスに関連するイベントを受信します。3つのコマンドと1つのイベントが定義されています。

HCI Command or Event	Description
LE Monitored Advertisers List command	Used by the host to add or remove an entry from the Monitored Advertisers List or to clear the list completely. An array of one or more devices to be monitored plus their associated RSSI thresholds and timeout parameter are provided in this command.
LE Monitored Advertisers Enable command	Allows the host to enable or disable advertiser monitoring in the controller.
LE Read Monitored Advertisers List Size command	Allows the host to determine the total number of entries the controller can currently accommodate in its Monitored Advertisers list. Note that this value may change at any time.
LE Monitored Advertisers Report event	Generated by the controller whenever for a monitored device there is a loss-of-signal or the device comes back into range. The Condition parameter indicates which of these two conditions is responsible for the event having been generated.

5.2.2.3 例

図18は、「モニタリング広告主」の動作説明図である。図の左半分はメッセージシーケンスチャートである。広告デバイスは全体として描かれているが、スキャニングデバイスはコントローラとホストの部分に分割されており、2つの部分間のHCI通信を見ることができる。

図の右半分には、RSSI値、設定されているRSSIスレッショルドの低値と高値、タイマーとAwaiting RSSI Highの状態情報が表示されています。

時間は図の上から下に流れる。左側のタイムラインには、注目すべきポイントがアルファベット順に記されている。表8にまとめる。

Point
A	The scanner’s host starts by asking the controller how many advertising devices it can monitor. The host then adds a device to the list along with RSSI low, RSSI high and timeout values (not shown). Finally, the host tells the controller to enable advertiser monitoring.
B	At this point the illustration starts to show advertising packets transmitted by the first device. Note that the device could have been advertising prior to this point but the packets are only shown from here. Received packets have an RSSI that is greater than the configured low threshold and so the timer for the monitored device is reset as each packet is received.
C	The next few packets received after point C have an RSSI that is lower than the low RSSI threshold and so it is at point C that the timer is last reset and the timer runs from that point.
D	A series of low RSSI packets are now received and at point D, a timeout occurs. The controller indicates the loss of signal condition to the host by sending a LE Monitor Advertisers Report event with condition == 0x00. The device is now in the Awaiting High RSSI state in the monitoring advertisers list.
E	At point E, the first of a series of packets whose RSSI is above the low threshold is received. For each such packet, the timer is reset.
F	At point F, the RSSI value exceeds the RSSI High threshold. The host is informed that the monitored device is back in range with a sufficiently strong signal via a LE Monitor Advertisers Report event with condition == 0x01 sent by the controller. The device is no longer in the Awaiting High RSSI state.

表8 - モニター広告主の例 - 注目のポイント

図18 - モニター広告主の使用例

6.ISOALの強化

6.1 背景

本節では、Bluetooth LE スタックの Isochronous Adaptation Layer（ISOAL）の拡張に関連するBluetooth LE テクノロジーの側面について説明する。

6.1.1 非同期通信

Bluetooth LE データ・トランスポート・アーキテクチャには、LE CIS と LE BIS 論理トランスポートが含まれる（CIS は Connected Isochronous Stream、BIS は Broadcast Isochronous Stream の略）。これらの論理トランスポートは、LE Isochronous Physical Link と LE Isochronous Physical Channel によりサポートされる。

図19 - 非同期通信とデータ・トランスポート・アーキテクチャ

アイソクロナス（等時性）通信は、デバイス間で転送されるデータに時間的制約がある場合に使用される。つまり、レシーバーが送信データを処理する際に、厳守しなければならない時間との関係がある。

Bluetooth LE Audio はアイソクロナス（等時性）通信を使用し、これによって関連するデータの複数のストリームがそれぞれのレシーバによって同時にレンダリングされることを保証します。より具体的に言うと、例えば、左ステレオチャンネルのオーディオデータと右ステレオチャンネルのオーディオデータは、オーディオソースデバイスによって異なる時刻に送信される可能性がありますが、2 つのステレオチャンネルの 2 つの別個のオーディオシンクデバイス（例えば、左右のイヤホン）によって、ユーザが期待する方法で同時にレンダリングされることを意味します。

CISはアイソクロナス通信に接続指向のアプローチを提供する。CISは一般的に、例えばスマートフォンと補聴器のような少人数のデバイスで構成される。補聴器はマイクを搭載し、音声ソースとしてもシンクとしても機能する。

BISはアイソクロナスデータのブロードキャストを含み、オーディオのようなアイソクロナスデータを多数の機器に配信することを目的としている。しかし、通信は一方向である。

特にオーディオデータを扱う場合のアイソクロナス通信には、多くの課題がある。

1つ目は、完全に独立した複数のデバイスにまたがるデータのレンダリング（この場合はオーディオの再生）を正しく同期させることだ。これはまさに、アイソクロナス通信が対処するために設計された問題である。

レイテンシーは問題になることもあれば、ならないこともあります。ユーザーが遅延を意識するのは、オーディオ機器に期待される音のタイミングと、実際に体験する音のタイミングを比較する他の基準がある場合のみです。例えば、補聴器ユーザーが、周囲の音と補聴器に送信される同じ音を聞くことができる場合、遅延が大きければ、ユーザーは周囲の音と増幅された音の間に遅延を感じるでしょう。Bluetooth アイソクロナス通信は、このようなデバイスの要件を満たすのに役立つ低遅延構成を選択することができます。

多くのオーディオ・シナリオではデータ損失の許容範囲が限られているため、信頼性は重要である。CISもBISも信頼性を高めるメカニズムを含んでいる。

6.1.2 デジタルオーディオ

アイソクロナス通信はオーディオ・アプリケーションのためだけのものではありませんが、もともと設計された主要な用途です。デジタルオーディオデータが生成される方法によって特定の課題が生じますが、Bluetooth LE スタックの Isochronous Adaptation Layer (ISOAL)と呼ばれるレイヤーがそれらに対処します。

オーディオはサンプリングと呼ばれるプロセスを経てデジタルフォーマットに変換されます。サンプリングは、一定間隔で信号の振幅を測定し記録することを含み、これは、Bluetooth LE Audioの文脈では、最終的に送信される必要のあるデータである、かなりの量のデータを生成します。

Bluetooth LE AudioはLC3と呼ばれるコーデックを使用しています。[4]これはサンプルデータに圧縮アルゴリズムを適用し、そのサイズを大幅に縮小します。コーデックは一般的に、一連の連続したサンプルに見られるパターンを認識し、利用することで機能します。そのため、コーデックが機能するためには、一度に分析する一連のサンプル全体が必要です。

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

6.1.3 ISOAL

6.1.3.1Bluetooth アーキテクチャにおけるISOAL

デジタルオーディオのようなデータは、システムのアプリケーション層によって生成される。これはBluetooth スタックのホスト部分に存在し、一般的にオペレーティング・システム（OS）サービスまたはOS上で動作するユーザー・アプリケーションのいずれかである。Bluetooth Core Specificationでは、アイソクロナス通信にデータを提供するレイヤーを単に上位レイヤーと呼ぶ。

Bluetooth リンク層は、アイソクロナス論理トランスポートの1つを使用して、1つ以上の他のデバイスとデータを通信する。リンク層は、通常チップ上のシステムであるBluetooth コントローラーに実装される。

ISOALはサービス・データ・ユニット（SDU）でアイソクロナスデータをISOALと交換し、ISOALはプロトコル・データ・ユニット（PDU）をリンク層と交換する。図20は、Bluetooth システムのこれら3つの部分の関係を示している。

図 20 -Bluetooth アーキテクチャにおける ISOAL

ホストとコントローラは通常、独立したコンポーネントであり、USBやUARTなどのサポートされているトランスポートのいずれかを介して、ホスト・コントローラ・インターフェイスを使用して互いに通信します。

6.1.3.2 ISOALが扱う問題点

上位レイヤーのデータ・プロデューサーの運用パラメータとリンク・レイヤーの運用パラメータの違いが、複雑な問題を引き起こす可能性がある重要な領域が2つある。

1つ目は、上位レイヤーで生成されるSDUのサイズに関するものである。SDUは、リンクレイヤーがサポートする最大サイズのPDUよりもかなり大きいのが普通である。

ISOALは、リンクレイヤーが1つのPDUで処理できるよりも大きなSDUを上位レイヤーが生成できるようにする。

つ目の問題はタイミングだ。リンクレイヤーによるデータの伝送は、間隔をおいて発生するイベントで行われる。この間隔は様々な値を取ることができ、一般にISO間隔と呼ばれる。フレームは上位レイヤによって同じ間隔で生成され、SDU（Service Data Unitの略）でスタックに渡される。上位レイヤーのSDU生成に支配的な時間間隔の時間は、SDU間隔と呼ばれる。

コントローラのリンクレイヤーが使用するISOインターバルは、ホストの上位レイヤーが使用するSDUインターバルと同じでないことが多く、2つのインターバル値は互いの整数倍ではない。さらに、これら2つのレイヤのアクティビティ間に同期がないことが一般的であり、その結果、データがシステムを通過するときに待ち時間が発生することがある。リンク層がイベント中に上位層から送信するデータを持っていない場合、ヌルPDUが送信されることに注意すべきである。

図21は、SDUとPDUの生成が同期していない場合の影響を示している。

図21 - 非同期のSDUとPDUの生成

送信されるデータは時間に強く拘束されており、受信側はその時間関係を復元し、データが処理されたときに期待通りの結果が得られるようにしなければならない。これは常に問題となるが、上位レイヤーとトランスポートの間に同期がない場合はより複雑になる。

ISOALは、上位レイヤによるSDUの生成速度と、リンクレイヤによるアイソクロナスPDUの送信速度が異なり、それらの動作が非同期であることを許容する。

6.1.3.3 ISOAL処理パス

アイソクロナス（等時性）データがISOALを通過する経路は2通りあり、図22では異なる色で描かれている。

SDU間隔がISO間隔の整数倍であり、上位レイヤーとトランスポートレイヤーの動作が同期している場合、フラグメントと呼ばれる処理によってフレーム化されていないPDUが生成される。そうでない場合、フレーム化されたPDUが生成され、セグメンテーションと呼ばれる処理が適用される。

図22- ISOAL

6.1.3.4 フレームなしPDUとフレーム付きPDU

フレームなしPDUパスが使用される場合、リンクレイヤーが許容する最大PDUサイズよりも大きなSDUは、フラグメントと呼ばれる処理によって小さな部分に分割される。ヘッダーは、フラグメントがSDU全体であるか、SDUの開始、続行、終了のいずれであるかを示す。

逆方向では、リンクレイヤーから受信したフレーム化されていない小さなPDUからSDUが再結合される。

フレーム化されたPDUパスが使用される場合、セグメンテーションと呼ばれる処理がSDUに適用される。フラグメンテーションと同様に、これはSDUをヘッダー付きの小さな部分に分割するが、SDUの開始を示すヘッダーにはタイミングオフセット情報も含まれるため、受信者はこの重要なタイミング情報を再組み立てして保持することができる。

SDUは、フラグメンテーションまたはセグメンテーションプロセスの結果に応じて、1つまたは複数のリンクレイヤPDUで送信される。

6.1.3.5 フレーミングモード

フレーミングモードは、Bluetooth Core Specificationで定義されている。バージョン6.0以前では、2つのフレーミングモードのみが定義されており、それぞれフレームあり、フレームなしのケースに対応していた。

6.1.3.6 ISOALセグメンテーションの問題点

ISOALフレーミングプロセスは、上位レイヤーから渡されたデータの2つの側面を扱う。それは、より小さなPDUに分割することによって、より大きなSDUを送信することを可能にすることと、データが持つ時間との関係が保持され、再構築できることを保証することである。

セグメンテーションには2つの問題がある。

第一は信頼性である。どのような無線通信システムでも、パケットロスの確率は常に存在する。たとえば、オーディオデータを含むSDUが、対応する一連のリンクレイヤーパケットで無線伝送するために複数のPDUに分割される場合、これらのパケットのいずれか1つ以上が失われ、その結果、SDU全体が危険にさらされる確率が高くなる。

2つ目は待ち時間に関するものである。セグメンテーションが適用される場合、受信デバイスの上位レイヤーは、SDUを再アセンブルして処理する前に、SDUのすべてのセグメントを受信するまで待つ必要がある。オーディオの場合、これはオーディオフレームを再作成し、LC3[5]コーデックを使用してデコードしてから、オーディオのレンダリングステージに進むことを意味する。この待ち時間は待ち時間となる。

6.2 ISOALの強化について

Isochronous Adaptation 層には、Unsegmented Framed モードと呼ばれる新しいフレーミング・モードがあります。ホストは、HCI LE Set CIG Parameters コマンドまたは LE Create BIG コマンドの Framing パラメータに 0x02 を指定することにより、このモードを選択できます。

非セグメンテーションフレームモードでは、フレーム化されたPDUを使用することができ、各SDUのタイミング情報は保持されるが、セグメンテーションを適用する必要はない。この新しいフレーミングモードには2つの利点がある。まず、セグメンテーション処理による遅延がなくなる。2つ目は、パケットロスによるSDUロスのリスクが減ることである。

6.2.1 待ち時間の短縮

フレーミングプロセスからセグメンテーションを排除することで、各リンクレイヤーパケットは事実上 SDU 全体を含む。これは、LE Audio の場合、オーディオフレーム全体に相当し、上位レイヤーは、受信したオーディオデータをデコードし処理できる状態になるまで、一連のパケットの受信を待つ必要がない。

6.2.2 信頼性の向上

セグメンテーションが適用される場合、1つのSDUは複数のパケットのペイロードとして伝送される。パケットロスの確率が一定であると仮定すると、SDU全体を伝送するために必要なパケットが多くなるほど、SDUの1つまたは複数の部分が失われる可能性が高くなる。

セグメント化されていないフレーミングモードが使用される場合、最大PDUサイズは常に、セグメント化の必要なくSDU全体を含むのに十分である。したがって、上位レイヤからのSDUとリンクレイヤが送信するPDUの間には1対1の関係がある。その結果、セグメンテーションによって各SDUに対して複数のPDUが生成される場合のように、パケットロスのリスクが増加することはない。

7.LL拡張フィーチャーセット

7.1 背景

リンク・レイヤ（LL）は、Bluetooth LEスタックの複雑なレイヤである。フィーチャーとして知られる数多くの機能が定義されている。

機能のサポートは、多くの場合オプションである。機能を使用する前、またはこれらの機能に関連または依存するLLプロシージャを実行する前に、デバイスは、その機能が、自身のコントローラ(Bluetooth )とリモートデバイスのコントローラの両方でサポートされているかどうかを確認する必要がある。そのために、Bluetooth Core Specificationは、FeatureSetと呼ばれる8オクテットのビットマスクと、機能交換手順を定義した。

FeatureSetの定義では、その64ビットにそれぞれ意味が割り当てられている。ビット値が1であれば、そのフィーチャーがサポートされていることを意味し、0であればサポートされていないことを意味する。

フィーチャー交換リンクレイヤ制御手順は、コネクション内のセントラルデバイスによって開始されたとき、LL_FEATURE_REQとLL_FEATURE_RSP PDUの交換を含む。ペリフェラルもこの手順を開始することができますが、LL_PERIPHERAL_FEATURE_REQ PDU を送信し、それに対してセントラルは LL_FEATURE_RSP で返信します。これら3つのPDUタイプはすべて、送信デバイスがサポートするフィーチャーを示すFeatureSetビットマスクを含む。図 23 は、ここではデバイス A として描かれているセントラル・デバイスによって開始されたときの Feature Exchange リンクレイヤー制御手順を示している。

図 23 - セントラル主導の LL 機能交換手順

時間の経過とともに、Bluetooth はますます洗練され、その機能リストは増大している。FeatureSet のビットマスクの64ビットは、Bluetooth Core Specification バージョン6.0とその将来のバージョンで定義されるような、広範囲の機能をカバーするにはもはや十分ではない。

図24は、Bluetooth Core Specificationのバージョン5.4におけるFeatureSetフィールドのビットの意味を定義した表の最後を示している。ここでは、ビット番号63だけが未割り当てである。

図24 -Bluetooth Core Specificationのバージョン{Atlanta version number}におけるFeatureSetフィールド

7.2 LL拡張機能セットについて

7.2.1 概要

LL 拡張フィーチャーセットは 、フィーチャーセットフィールド内でビットが割り当てられたフィーチャー以外のフィーチャーを、デバイスがサポートするかしないかを示すことができる手段を提供する。これは、将来にわたってBluetooth テクノロジーの進化をサポートするように設計されており、1984 のサポート表示ビットを収容するのに十分な容量を備えている。

7.2.2 テクニカル・ハイライト

LL 拡張フィーチャー・セットは 、それ自体がリンク・レイヤー・フィーチャーであり、デバイスがサポートするかしないかのどちらかである。これはFeatureSetフィールドのビット番号63の値で示される。

FeatureSetのビットマスクは拡大され、アドレス指定可能なページに分割されている。ページ0には最初の64ビットが含まれ、これらはBluetooth Core Specificationのバージョン6.0以前のフィールドの仕様に従って定義されている。その後、1から順に番号付けされた10ページが続き、各ページのサイズは192ビット（24オクテット）である。

LL 拡張フィーチャーセット機能をサポートするデバイスは、フィーチャーページ交換手順を使用して、互いの拡張フィーチャーセットを発見することができる。この手順は、セントラル・デバイスまたはペリフェラル・デバイスのいずれかによって開始される。

つの新しい HCI コマンドと新しい HCI イベントが、LL 拡張フィーチャー・セットと共に使用するために定義された。これらはそれぞれ、LE Read All Local Supported Features コマンド、LE Read All Remote Features コマンド、LE Read All Remote Features Complete イベントである。

LE リード・オール・リモート・フィーチャー・コマンドの呼び出しは、一連の LL_FEATURE_EXT_REQ PDU の送信につながり、各 PDU は LL_FEATURE_EXT_RSP PDU でリモート・デバイスによって応答される。全てのリモート・フィーチャーセット・ページが取得されると、その詳細は LE Read All Remote Features Complete イベントで開始ホストに報告されます。図 25 を参照。

図 25 - LL 拡張フィーチャー・セット交換

LL_FEATURE_EXT_REQ と LL_FEATURE_EXT_RSP PDU はどちらも同じ構造で、リンク層データ PDU の CtrData フィールドに 3 つのフィールドがある。表 9 にこれらの PDU タイプのフィールドを示す。

CtrData
MaxPage (1 octet)	PageNumber (1 octet)	FeaturePage (24 octets)

表 9 - LL_FEATURE_EXT_REQ および LL_FEATURE_EXT_RSP PDU の内容

MaxPageフィールドは、0でないビットが存在する最高番号のページを示すために使用される。

PageNumberフィールドは、値が要求または報告される拡張FeatureSet内の24オクテットのページ番号を識別する。

FeaturePage には、PageNumber で特定されるページに含まれる 192 ビットの値が格納される。

フィーチャー・ページ交換手順は、ホストによって開始されるか、リンク・レイヤによって自律的に開始される。既存のHCIコマンドとイベントの新しいバージョンは、ホストによる拡張機能セット機能の使用を可能にするために定義された。

8.フレーム空間の更新

8.1 背景

このセクションでは、フレーム・スペース・アップデートの拡張に関連するBluetooth LE テクノロジーの側面について説明します。

8.1.1 フレーム間スペース

リンク・レイヤーはエア・インターフェース・プロトコルを定義し、これにはインター・フレーム・スペース（IFS）と呼ばれる時間間隔の定義が含まれる。

IFSは、同じチャネルで送信される2つの連続したパケットの間に含まれなければならない。Bluetooth Core Specification version 6.0 より前のバージョンでは、この時間はシンボリック識別子 T_IFS を用いて参照され、150 µs の固定値であった。

イベントまたはサブイベントで送信された最後のパケットの終了と、次のイベント/サブイベントの開始との間に存在しなければならない最小時間持続時間も、様々なトランスポートタイプに対して定義されている。

8.1.2 コネクテッド・ステート

図9にリンクレイヤーのステートマシンを示す。つの論理トランスポートタイプが接続状態で動作可能である。これらは、非同期コネクション指向論理トランスポート（ACL）とコネクティッド・アイソクロナスストリーム（CIS）である。

ACLトランスポートは、セントラル（Central）の役割を果たすデバイスが、ペリフェラル（Peripheral）の役割を果たす別のデバイスと、接続イベント中にパケットを交換することを可能にする。

図26は、Bluetooth Core Specificationのバージョン6.0より前に定義されたACL接続の例を示している。固定値T_IFSは、セントラルからペリフェラルへ、またはペリフェラルからセントラルへ送信される同じ接続イベントのパケット間に存在しなければならない時間ギャップを定義している。さらに、あるコネクション・イベントの終了と次のコネクション・イベントの開始の間には、少なくともT_IFSの期間が必要である。

図26 ACL接続で交換されるパケット

CISは、パケットが交換されるサブイベントのシステムを使用する。バージョン6.0以前では、同じサブイベント内のパケット間のタイミングギャップも、図27に示すように固定値T_IFSとして定義されていた。さらに、記号名T_MSSを持つ最小サブイベント空間と呼ばれる期間が定義されている。あるCISサブイベントが終了してから次のサブイベントが開始するまでの間に、少なくともT_MSSの期間が必要である。バージョン6.0以前のBluetooth Core Specificationでは、T_MSSはT_IFSと同じ150μsの固定値であった。CISには、CISを確立し、CISに影響を与えるリンク層制御PDUを交換するために使用される、関連するACL接続があることに注意すべきである。

図27-接続されたアイソクロナスストリーム（CIS）で交換されるパケット

8.2 フレームスペースの更新について

8.2.1 概要

Bluetooth コア仕様書バージョン6.0では、フレーム間隔が以下のように変更されている：

ACL接続とCISに適用される時間間隔には、5つの異なるシンボル名が割り当てられている。
値は150μsに固定されなくなった。
5つのフレーム間隔タイプの各値はデフォルトで150μsであるが、接続確立後にセントラルおよびペリフェラル・デバイスによって新しい値がネゴシエートされることがある。

フレームスペースの値は、デフォルトの150μsより短くても長くてもよい。

この変更は、ACL接続と接続されたアイソクロナスストリームにのみ関連する。他のトランスポート・タイプでは、150 µsの固定フレーム間スペーシングが引き続き使用され、T_IFS_150というシンボリック名で呼ばれる。

フレームスペースの値を短くすると、全体的なスループットが向上します。より短いフレームスペースとより高いデータスループット・レートの恩恵を受けるアプリケーションの例としては、以下のようなものがある：

フィットネストラッカーは、スマートフォンやノートパソコンなどの接続機器に、すべてのデータを一度に転送しなければならない。
ファームウェアのアップデート。
Bluetooth LEオーディオ。接続されたアイソクロナスストリームで送信されるオーディオパケットは、より速く、より短いバーストで送信することができます。これにより、他のデバイスからの衝突が発生する確率を減らすことができます。
Wi-Fiなど他の目的で無線を使用するデバイスは、これらの活動のための時間がより多くある。

フレームスペースの値が長いと、比較的処理能力が低いコントローラにメリットがあり、コントローラが長いパケットを処理する時間が長くなる。

8.2.2 テクニカル・ハイライト

8.2.2.1 スペーシングの種類

ACL接続には3つのスペーシングタイプが定義されている。表 10 に、ACL 接続の新しいスペーシングタイプの概要を示す。

Spacing Type Symbolic Identifier	Definition
T_IFS_ACL_CP	The duration of the required spacing time which must exist from the end of a packet transmission by the Central device and the start of the following slot in the same connection event, which may potentially be used by the Peripheral.
T_IFS_ACL_PC	The duration of the required spacing time from the end of a packet transmission by the Peripheral device in a connection and the start of the following slot to potentially be used by the Central in the same connection event.
T_IFS_END	The minimum time to elapse between the end of a connection event and the start of the next one.

表10 - ACL接続の新しいフレーム間隔タイプと識別子

図28は、新しいスペーシング・タイプをシンボル識別子で示したACL接続における接続イベントとパケット伝送を表している。

図 28 - ACL 接続における新しいフレーム間隔タイプ

接続されたアイソクロナスストリームには、2つのスペーシングタイプが定義されている。表11に、CISの新しいスペーシングタイプをまとめる。

Spacing Type Symbolic Identifier	Definition
T_IFS_CIS	The duration of the required spacing time from the end of a packet transmission by the Central device in a CIS and the start of the following transmission by the Peripheral.
T_MSS_CIS	The minimum subevent space which is the minimum time that must elapse between the end of a packet transmitted in one subevent and the start of the next subevent.

表11 - CISの新しいフレーム間隔タイプと識別子

図29は、接続されたアイソクロナスストリームにおけるサブイベントとパケット送信を、新しいスペーシングタイプをシンボリック識別子で示したものである。

図29 - 連結アイソクロナスストリーム（CIS）における新しいフレーム間隔タイプ

コントローラは、Bluetooth LE PHY（LE 1M、LE 2M、LE Coded）ごとに、各スペーシングタイプに異なる値を使用するように設定できる。

すべての場合において、スペーシング・パラメータのデフォルト値は150μsであり、スペーシング・パラメータの設定可能な値の範囲は0～10,000μsである。

すべての場合において、±2 µsの公差が許容される。

8.2.2.2 フレーム空間の更新

リンクレイヤ仕様は、フレームスペースアップデート手順と呼ばれる新しい手順を定義している。このプロシージャを使用することで、デバイスは、あるいは全てのサポート PHY に適用可能な各スペーシングタイプの値をネゴシエートすることができる。

セントラルデバイスまたはペリフェラルデバイスのいずれかが、フレーム空間更新手順を開始することができる。これは、コネクション上で LL_FRAME_SPACE_REQ を送信することで実現されます。これに応答して、もう一方のデバイスは LL_FRAME_SPACE_RSP PDU を送信しなければならない。

LL_FRAME_SPACE_REQ PDUは、以下のフィールドを含む：

Field	Meaning
FS_MIN	The minimum requested frame spacing in microseconds.
FS_MAX	The maximum requested frame spacing in microseconds.
PHYs	A single octet bit mask where bit 0 indicates the LE 1M PHY, bit 1 indicates the LE 2M PHY and bit 2 indicates the LE Coded PHY. One or more of these bits may be set to indicate the PHYs for which the frame spacing update is being requested.
Spacing Type	A 2-octet bit mask which indicates the spacing parameters for which new values are being requested. Bit 0 indicates T_IFS_ACL_CP, bit 1 indicates T_IFS_ACL_PC, bit 2 indicates T_IFS_END, bit 3 indicates T_IFS_CIS and bit 4 indicates T_MSS_CIS.

応答デバイスは、Bluetooth コア仕様のルールを適用して要求を検証する。要求が有効で対応可能であれば、使用するフレーム空間の値を含む LL_FRAME_SPACE_RSP PDU を返します。これは要求された範囲の中で、デバイスがサポートできる最小の値となる。両デバイスは新しい値を採用し、その変更を Host に通知します。

リクエストに対応できない場合は、エラーコードに Unsupported Feature または Parameter Value を設定した LL_REJECT_EXT_IND PDU を返し、使用中のフレーム間隔パラメータは変更されない。

8.2.2.3 ホストコントローラーインターフェース

ホストコントローラーインターフェイスが更新され、新しいフレーム空間更新手順に対応しました。

この手順は、ホストが新しい HCI_LE_Frame_Space_Update コマンドをコントローラに送ることで開始される。このコマンドは、新しいフレームスペース値が要求されるスペーシングタイプと時間範囲、及び、新しい値が適用される PHY を含む。

変更は、新しい LE フレーム空間更新完了イベントを通じて、フレーム空間更新手順の完了時にホストに通知される。

図30は、フレーム空間更新手順が開始されたときに、ホストとコントローラ間およびデバイス間で発生する相互作用を示す。

図30 - フレーム空間更新HCIとリンク層の相互作用

9.結論

Bluetooth コア・スペック・バージョン6.0は、Bluetooth 、新機能や技術的な改良を加えて定期的に更新される傾向が続いている。

Channel Sounding は、信頼性が高く正確な距離測定への標準ベースの安全なアプローチを可能にし、多くの種類の製品が恩恵を受けることになる。

デシジョンベースのアドバタイジング・フィルタリングは、コネクションレス・データ転送にBluetooth 拡張アドバタイジングを使用する場合、スループットと信頼性を向上させる。

広告主を監視することは、アプリケーション開発者にとって有益であり、より良いユーザー・インターフェースの提供とユーザー体験の向上を可能にする。

ISOALの改良は、ユーザーが知覚する低遅延が重要なオーディオ・アプリケーションに恩恵をもたらすだろう。

LL拡張フィーチャー・セット機能により、現在、そして将来にわたって、最も洗練された機能豊富なデバイスのフィーチャー・サポート・ディスカバリーが可能になる。

10.参考文献

Item	Location
Bluetooth Core Specification version 6.0	https://www.bluetooth.com/specifications/specs/
The Bluetooth LE Security Study Guide	https://www.bluetooth.com/bluetooth-resources/le-security-study-guide/
Bluetooth® Channel Sounding Technical Overview paper	https://www.bluetooth.com/channel-sounding-tech-overview/

脚注

[1]モード0については、3.2.2.5.1 イベント、サブイベント、およびステップで説明する。
[2]ガウス周波数シフトキー
[3]接続可能な広告PDUは、応答として接続要求を行うことができるものである。
[4]低複雑度通信コーデック
[5]Low Complexity Communications Codec -Bluetooth LE Audioで使用されているオーディオコーデック。

Bluetooth®コア仕様書バージョン6.0

1.はじめに