ブルートゥース® 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.4ISOAL拡張

アイソクロナス・アダプテーション・レイヤー（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 つの方法は、位相ベース測距 PBR）とラウンドトリップタイミング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つの機器間で行われます。自分から他の機器までの距離を計算したい機器をイニシエータ呼びます。もう一方の機器はリフレクタ呼ばれます。

channel sounding 間、イニシエータ リフレクタ 間では、事前に合意されたタイムスロットの間に複数の双方向交換が行われる。

Bluetoothスタックでは、channel sounding 主にBluetoothコントローラの機能であり、スタックのhost 部分とは対照的です。イニシエータコントローラは、host （Host ）を使用して、低レベルの測定値を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 物理チャネルを使用します。

イニシエータ リフレクタ 役割は、それぞれセントラルデバイスまたはペリフェラルデバイスのいずれかが担うことができる。

3.2.2.3 距離測定方法

3.2.2.3.1位相ベース測距 PBR

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

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

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

PBR使用する場合、イニシエータ 所定の周波数_f1で信号をリフレクタ送信する。リフレクタ イニシエータ 信号を返送し、イニシエータ その応答を受信して受信信号の位相を測定する。

図7 -イニシエータ channel sounding 信号を送り、リフレクタ エコーする

次に、イニシエータ 、今度は異なる周波数_f2で別の無線信号を送信する。リフレクタ 、受信した信号を再びイニシエータ エコーバックする。周波数を変えると波長が変わり、その結果、イニシエータ リフレクタ 応答を受信する際に測定する位相_Pf2も変わります。

イニシエータ 、周波数差（f₁-_f2）、位相差（_Pf1 -_Pf2）、および光速を含む式を使用して、2つのデバイス間の距離を計算することができます。

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

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

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

3.2.2.3.2 往復タイミングRTT

RTT 方式は、イニシエータ リフレクタ パケットを送信し、リフレクタ 同じパケットを送り返す。この点においてのみ、PBR 方式との類似性がある。

距離測定の計算を可能にするため、イニシエータ パケットを送信する際にタイムスタンプを記録する。この時刻はTime of DepartureまたはToDと呼ばれる。リフレクタ応答パケットを受信すると、リフレクタ再びタイムスタンプを記録し、この時刻を「到着時刻（Time of Arrival）」または「到着時刻（ToA）」と呼ぶ。

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

ブルートゥース® Channel Sounding RTT 、リフレクタ 受信したCSパケットを折り返してイニシエータ 送り返すまでの時間を確実に知ることができるため、この時間値を計算に使用することで、より正確な飛行時間を算出することができる。 

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

3.2.2.4Channel Sounding 初期化

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

ブルートゥース®Channel Sounding 、独自のセキュリティ機能があります。最初に実行されるchannel sounding 手順は、CS セキュリティ・スタート手順です。この手順では、初期化ベクトル（IV）、インスタンス化ノンス （IN）、パーソナライゼーション・ベクトル（PV）の値が両方のデバイスに設定されます。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 方式を使用する場合、リフレクタ イニシエータ 受信した信号を同じ周波数でエコーバックすることが期待される。しかし、どのような装置でも、発生する信号の周波数にある程度の不正確さが生じる可能性があり、意図する周波数や希望する 周波数と、実際に測定された発生信号の周波数が異なることがある。周波数は波長に直接関係しており、PBR 法はこの関係に依存している。したがってリフレクタ エコー信号の周波数の不正確さは、距離測定の精度に影響を与える可能性がある。その結果、デバイスは、基準周波数の集合に対して、生成された信号の周波数と予想または要求された周波数との間の差の測定値を提供する、分数周波数オフセット作動誤差（FAE）テーブルと呼ばれるデータのテーブルを製造業者によって装備されている場合があり、ppm（Parts Per Million）で表されます。 モード0を使用する[1]FAEテーブル要求手順を使用すると、イニシエータ リフレクタ 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 一連の手順で行われる。各手順はいくつかのイベントで構成され、各イベントはさらにサブイベントに分割される。この階層スキームにおける時間の最終的な区分がステップである。イニシエータ リフレクタ 間の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までの番号が振られている。モードは、そのステップで行われる交換の詳細とその目的を定義する。

• モード-0ステップは較正に関係し、イニシエータ 、ある周波数の発生がリフレクタ自身とどの程度異なるかを判断します。これにより、周波数生成の差異を補正するための計算に使用されるフラクショナル・フリケンシー・オフセット（FFO）と呼ばれる値が得られます。Mode-0ステップでは、CS Syncパケットを交換します。
• Mode-1ステップでは、ラウンドトリップ・タイミングRTT方式のアプリケーション CS Syncパケットを使用する。
• モード2のステップでは、PBRためにCSトーンを交換する。
• 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チャネル・マップと呼ばれる特別なチャネル・マップは、チャネル選 択に含めるべきチャネルと避けるべきチャネルを示す。リンクレイヤー 制御手順により、イニシエータ リフレクタ ローカルの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.8LE 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 の比較

帯域幅-ビット周期製品 （BT）は、信号の属性であり、帯域幅とシンボルの持続時間の関係についての情報を提供する。

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

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

3.2.2.9Channel Sounding SNR制御

一部の無線送信機には、信号対雑音比（SNR）を特定の範囲内になるように調整する機能があります。SNR コントロール機能 、CS モード 1 およびモード 3 ステップの CS Sync パケット送信時に使用する SNR 出力レベルを、イニシエータ リフレクタ 合意することができます。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）を使用して生成または選択される。イニシエータとリフレクタ 、同じ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 AcceptList（4.1.2 Filter Policiesを参照）を使用しないことを推奨する。パーソナルオーディオデバイスがボンディングされている可能性が高いが、LE Audio はパーソナルオーディオ以上のものである。

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

LE Audio ユースケースは、アドバタイザーモニター 機能 design 反映された重要なシナリオのひとつです。

 

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

5.2.1 概要

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

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

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

アドバタイザーモニターは、フィルター受け入れリスト（4.1.2 Filter Policiesを参照)、したがって、スキャンデバイスと結合されているかどうかに関係なく、結合されたデバイスのみにフィルタ受諾リストを使用し、一般的にすべてのデバイスにアドバタイザーモニター 使用することが容易になります。

改善されたエネルギー効率とより良いユーザ体験を通じて、アドバタイザーモニター 機能 恩恵を 受ける多くの状況と製品 種類がある。オーディオストリームを開始するLE Audio デバイス（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スレッショルドの低値と高値、タイマーと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 非同期通信

ここで、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上で実行されるユーザー・アプリケーション いずれかです。ブルートゥースコア仕様、アイソクロナス通信のためのデータを提供するレイヤーを単に上位レイヤーと呼びます。

リンクレイヤー 、アイソクロナス論理トランスポートの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の開始部分なのか、 続きなのか、終了部分なのかを示す。

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

フレーム化された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.2ISOAL拡張

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コントローラとリモートデバイスのコントローラの両方でサポートされているかどうかを確認する必要があります。そのために、ブルートゥースコア仕様 、以下の8オクテットのビットマスクを定義しました。 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 でリモート・デバイスによって応答される。全てのFeatureSet 取得されると、その詳細は 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コマンドとイベントの新しいバージョンは、ホストによる拡張機能 セット機能 使用を可能にするために定義されている。 

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

8.1 背景

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

8.1.1 フレーム間スペース

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

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

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

8.1.2 接続状態

図9は、リンクレイヤー 状態 マシンを示している。接続状態、2つの論理トランスポートタイプが動作可能である。これらは、非同期コネクション指向論理トランスポート (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で使用されるオーディオコーデック