ブルートゥース® Core 6.0機能 概要

1.はじめに

ブルートゥース® コア仕様6.0ブルートゥース® コア6.0）には、いくつかの機能 強化が含まれています。本稿では、各機能強化の概要を説明します。注：本書はマーケティング資料であり、ブルートゥース® コア仕様に取って代わるものではありません。

機能 拡張は専用のセクションで説明され、関連する背景情報の説明から始まる。これは、Bluetooth LE のある側面に初めて遭遇する読者にとって、より簡単なものとなることを意図している。とはいえ、背景のセクションは完全に網羅されているわけではないので、馴染みのない用語や概念に遭遇した読者は、Bluetooth LE Primer をダウンロードして読むことを推奨する。

2.概要

2.1ブルートゥース® Channel Sounding

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

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

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

ブルートゥースの拡張アドバタイズ 機能 、プライマリおよびセカンダリの無線チャンネルで送信される一連の関連パケットを含む。

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

2.3 広告主の監視

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

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

2.4 ISOALの強化

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

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

ブルートゥース® コア6.0では、この問題に特に敏感なユースケース向けに待ち時間を短縮する新しいフレーミング・モードを定義することで、ISOALが改善されました。同じ機能 信頼性も向上しています。

2.5 LL拡張機能 セット

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

2.6フレームスペース更新

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

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

3.ブルートゥース®Channel Sounding

3.1 背景

ブルートゥース® Channel Sounding 機能理解を深めるために、Bluetooth LE 技術の概要を説明します。

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

ブルートゥースコア仕様 Bluetooth LE 最初に規定されて以来、方向検知 コア機能や、Find Meプロファイルなどの多くの関連プロファイルにより、Bluetooth LE 位置情報サービスのための一般的な技術として確立された。

図1 -AoA AoD 方向検知

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

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

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

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

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

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

ブルートゥースコア仕様 、Bluetooth データ・トランスポート・アーキテクチャを構成するいくつかの概念を定義しています。これらの概念の中には、物理トランスポート、物理チャネル、物理リンク、論理リンク、および論理トランスポートがあります。トポロジー、タイミング、信頼性、電力、チャネル使用などの特性に関連する特定の特性を持つ、さまざまなアプリケーション タイプをサポートするために使用される特定の組み合わせや構成が定義されています。動作モードまたは動作モードという用語は、様々なデータ・トランスポート・アーキテクチャ構成を指すために非公式に使用されることがある。

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

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

3.1.2.1 LE-ACL

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

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

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

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

3.1.2.2 ADVB

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

3.2ブルートゥース® Channel Sounding

3.2.1 概要

Bluetooth LE ブルートゥース® Channel Sounding 機能 、2 つの異なる距離測定方法で構成され ています。この 2 つの方法は、Phase-Based Ranging（PBR）と Round-Trip Timing（RTT）と呼ばれます。

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

このセクションでは、ブルートゥース® Channel Sounding説明します。より詳細で包括的な説明については、BluetoothSIG Web サイトwww.bluetooth.com）から入手可能な関連論文『Secure Fine Ranging withブルートゥース® Channel Sounding』を参照してくださいwww.bluetooth.com

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

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

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

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

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

図 4 - CS デバイスの役割とhost機能の分布

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

3.2.2.2ブルートゥース® 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では1 MHzの周波数分離を使用しており、距離の曖昧さは150メートル付近まで生じません。

距離のあいまいさの問題は、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法で正確な距離測定を行うための鍵となります。

ブルートゥース® Channel Sounding RTT は、Reflector が受信した CS パケットを折り返し、 Initiator に送り返すまでの時間を確実に知ることができる。 

ブルートゥースコア仕様 、ToAとToDのタイムスタンプを取得するためのいくつかの異なる方法を定義している。メソッドの選択は、複雑さとその精度で異なります。最も正確なタイムキャプチャ方法は 部分的タイミング推定.ToAとToDの値をできるだけ正確にキャプチャすることで、最も正確な距離測定が可能になります。

3.2.2.4Channel Sounding 初期化

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

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

ブルートゥース® 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 Procedure を使用することで、 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ブルートゥース® 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パケットを交換する。
• Mode-1ステップでは、ラウンドトリップ・タイミング（RTT）方式のアプリケーション CS Syncパケットを使用する。
• モード 2 のステップでは、Phase-Based Ranging（PBR）のために CS Tone を交換する。
• mode-3 ステップは CS Sync パケットと CS トーンの両方を交換し、RTT および PBR メソッドの両方のデータを 1 つのステップで収集できるようにする。モード 3 のサポートはオプションである。

どのステップ・モードがchannel sounding 手順で使用されるかは、ブルートゥースコア仕様 ルールと2つのデバイスが合意した設定に依存する。これには、RTT や PBR など、どの距離測定方法を使用するかが含まれます。

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

ブルートゥース®Channel Sounding 、アプリケーション 設定時に多くの制御を行うことで、手順内の様々なパターンでステップモードを組み合わせ、シーケンスすることができます。アプリケーション 、channel sounding 手順の繰り返し回数や、交換されるパケットやトーンの数、場合によってはその内容に影響を与えるその他の変数も設定できます。

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

各サブイベントには、常に少なくとも2つの異なるステップモードが存在する。モード0は常にすべてのサブイベントを開始し、1つまたは2つの他のモードは、ブルートゥースコア仕様 提示され、ここで表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. 1つ以上のmode-0ステップがサブイベントを開始する。
2. その後、n個のメイン・モード・ステップのシーケンスが続くが、nはランダムに選択され、設定された範囲内に収まる。
3. ブルートゥースコア仕様 、1つのサブモードステップが、サブモード挿入と呼ばれるプロセスに従って、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 はどちらも非モード 0 ステップ用に設計されているが、channel sounding 手順インスタンスでは 2 つのうち 1 つしか使用できない。

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

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

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

3.2.2.8 LE 2M 2BT PHY

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

ブルートゥースコア仕様バージョン 6.0 以前には、3 つの PHY が定義されていた。それらの名前は、LE 1M、LE 2M、LE Coded である。LE Coded PHY は、LE 1M と同じであるが、パケットに付加的な符号化が施され、エラー検出と訂正が可能である。

LE 2M 2BT と呼ばれる新しい物理層構成がバージョン 6.0 で導入された。この新しい PHY は、ブルートゥース® 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 の比較

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

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

BT値を2.0にすると、ある種の物理層攻撃に対するchannel sounding 安全性が向上する。参照 3.2.2.10ブルートゥース® 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ブルートゥース® Channel Sounding 概要

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

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

ブルートゥース®Channel Sounding 、距離測定のセキュリティ上の脅威に対する対策として機能する機能が搭載されています。これらの機能は4つのカテゴリーに分類されます：

1. PBRとRTTの併用。

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

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

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

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

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

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

• ブルートゥースコア仕様 、ブルートゥース® Channel Soundingための攻撃検知システ ムの記述が含まれる。これには、攻撃が進行中である確率をアプリケーション 報告するための標準化されたメトリックが含まれる。このメトリックは正規化攻撃検出メトリック（NADM）と呼ばれる。NADM値は、受信信号の評価に基づいてコントローラによって割り当てられ、攻撃の可能性を示すスライディングスケールの形式をとる。表 3 にブルートゥースコア仕様引用した 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コントローラの実装者およびアプリケーション 開発者は、必要に応じて、ブルートゥース® Channel Sounding セキュリティ機能によって提供される標準のセキュリティ機能を、追加のセーフガードで補強することができます。

3.2.3ブルートゥース® Channel Sounding詳細情報

ブルートゥース® Channel Sounding 機能のより広範なレビューについては、BluetoothSIGこのトピックに特化したペーパーを作成しています。 ブルートゥース® Channel Sounding安全なファイン・レンジング（Secure Fine Ranging withブルートゥース® Channel Sounding）と題されたこの論文は、BluetoothSIG ウェブサイトからダウンロードできます。

ブルートゥースコア仕様 ブルートゥースコア仕様は実施者にとって唯一の参考資料である。

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コマンドを使ってhost 側で選択・設定することができる。

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

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

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

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

4.1.3拡張アドバタイズ

ブルートゥースコア仕様、いくつかの形式の広告が定義されている。 広告ブロードキャスト(ADVB)論理トランスポートは、わずかにランダム化された タイミングスケジュールで広告パケットを送信する。ADVBには、レガシー広告として知られる基本的な形式と、拡張アドバタイ ズとして知られるより洗練された形式がある。 拡張アドバタイズ.

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

拡張アドバタイズは 40 のBluetooth LE RF チャンネル全てを使用します。ヘッダ・データは、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は拡張ヘッダーを含む。これは、ブルートゥースコア仕様記載された規則に従って、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はアプリケーション 含まない。場合によっては、オブザーバ（スキャン装置）は 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 はアドバタイジングイベントタイプを示す。

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)フィールドにどのサブフィールドが存在するかを示す。セットされたビットは、ブルートゥースコア仕様フィールド内のビット位置に関連付けられたサブフィールドの存在を示す。位置ゼロのビットは解決可能タグサブフィールドに関連する。それ以外のビットは将来の使用（RFU）のために予約されている。

4.2.3.1.2 デシジョンPDUの設定

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

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

HCI コマンド、LE セット拡張アドバタイズ 、例えば広告間隔を含む広告セッ トの主要変数を設定するために使用されます。コマンドのパラメータの1つであるAdvertising_Event_Propertiesは、設定されているアドバタイジング・セットに関連する様々なhost 要件を示すビット・マスクです。例えば、ビット0が設定されている場合、host コントローラが接続可能なアドバタイジングモードを使用する必要があることを意味します。ビット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を使用して、host 、関連する広告イベントで決定PDUを送信するようにコントローラに指示できる。スキャニングデバイスのコントローラが使用するために指定できる決定PDUのチェックが洗練されているため、広告主のデバイスアドレス および/またはADIフィールドが不要になる可能性があり、ビット8および9では、いずれかまたは両方を除外することができるため、LE 1Mにわたってパケットを8オクテット短縮し、エアタイムを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つの配列パラメータにより、host 実行するテストを設定することができる。

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テストを以下のように評価する：

host指定された各試験について、関連するフィールドの可用性が最初にチェックされる。これは、受信した 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]で示される関連フィールドによって異なります。ブルートゥースコア仕様 書式やルールの詳細が記載されていますが、ここでは関連するフィールドの種類ごとにまとめています。

解決可能なタグ

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イベントでhost 通知される。host 広告データの報告用に、いくつかのHCIイベントタイプが定義されてい る。例えば、レガシー広告の場合、LE 広告レポート・イベントが使用される。拡張アドバタイズ場合、LE拡張アドバタイズ 使用される。定期広告が使用されている場合、LE 定期広告レポート・イベントが使用される。

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

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

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

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

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

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

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

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

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

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の機能 design 影響を与えた重要なシナリオの一つである。

 

5.2 広告主の監視について

5.2.1 概要

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

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

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

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

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

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

5.2.2.1 監視対象広告主リスト

ブルートゥースコア仕様 、監視対象アドバタイザリストを定義している。これは、コントローラのデータ構造で、host 追跡したいアドバタイ ザデバイスのリストを格納する。

リスト内の各デバイスにはいくつかのパラメータが付随しており、各エントリーは関連するタイマーを持つと考えることができる。さらに、各エントリには、実装によって維持される「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.2Host

host 、モニタリング・アドバタイザー・リストを設定し、Host （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は、「モニタリング広告主」の動作説明図である。図の左半分はメッセージシーケンスチャートである。 広告デバイスは全体のエンティティとして描かれているが、スキャニングデバイスはコントローラとhost 部分に分割されており、2つの部分間のHCI通信を見ることができる。  

図の右半分は、RSSI値、設定されているRSSIスレッショルドの低値と高値、タイマーと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 非同期通信

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

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

多くのオーディオ・シナリオではデータ損失の許容範囲が限られているため、信頼性は重要である。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.1 BluetoothアーキテクチャにおけるISOAL

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

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

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

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

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

6.1.3.2 ISOALが扱う問題点

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

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

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

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

コントローラのリンクレイヤーが使用するISOインターバルは、host 上位レイヤー が使用する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 フレーミングモード

フレーミングモードは ブルートゥースコア仕様定義されている。バージョン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 スタックの複雑なレイヤである。フィーチャーとして知られる数多くの機能が定義されています。

機能 サポートは多くの場合オプションです。機能 使用する前、またはこれらの機能の1つに関連または依存するLL手順に関与する前に、デバイスは、その機能 自身のBluetoothコントローラとリモートデバイスのコントローラの両方でサポートされているかどうかを確認する必要があります。そのため、ブルートゥースコア仕様 、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 として描かれているセントラルデバイスによって開始された場合の機能 交換リンクレイヤ制御手順を示している。

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

時間の経過とともに、Bluetooth はますます洗練され、その機能リストは増大しています。ブルートゥースコア仕様 バージョン6.0およびその将来のバージョンで定義されるような幅広い機能をカバーするには、FeatureSetビットマスクの64ビットではもはや十分ではありません。 

図24は、ブルートゥースコア仕様バージョン5.4におけるFeatureSetフィールドのビットの意味を定義した表の末尾を示している。ここではビット番号63だけが未割り当てである。

図24 -ブルートゥースコア仕様バージョン{アトランタバージョン番号}におけるFeatureSetフィールド

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

7.2.1 概要

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

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

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

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

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

LL 拡張機能 セットで使用するために、2 つの新しい HCI コマンドと新しい HCI イベントが定義された。これらはそれぞれ、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 イベントで開始host 報告されます。図 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 ビットの値が格納される。

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

8.フレームスペース更新

8.1 背景

このセクションでは、Bluetooth LE テクノロジーのうち、フレームスペース更新 強化に関連する部分について説明します。

8.1.1 フレーム間スペース

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

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

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

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

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

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

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

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

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

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

8.2フレームスペース更新

8.2.1 概要

ブルートゥースコア仕様バージョン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.

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

要求に応じられない場合、エラーコードに Unsupported機能 またはパラメータ値を設定した LL_REJECT_EXT_IND PDU を返し、使用中のフレーム間隔パラメータは変更されない。

8.2.2.3Host

Host 更新され、新しいフレームスペース更新 手順に対応しました。

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

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

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

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

9.結論

ブルートゥース・コア仕様バージョン6.0は、ブルートゥース・テクノロジーが定期的にアップデートされ、新機能や技術的な改良が加えられるというトレンドを引き継いでいます。

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で使用されるオーディオコーデック