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

ブルートゥース®コア仕様v6.2(以下、ブルートゥース®コア6.2)には、いくつかの機能 強化が含まれています。本稿では、各機能強化の概要を説明します。

注:本書はマーケティング文書であり、ブルートゥース® コア仕様に取って代わるものではありません。機能 拡張は、関連する背景情報から始まる専用のセクションで説明されています。これは、ブルートゥース® LE に馴染みのない読者を支援することを意図している。しかしながら、背景のセクションは完全には網羅されていない。馴染みのない用語や概念に遭遇した読者は、ブルートゥース® LE 入門書をダウンロードして読むことを推奨する。

接続間隔の短縮(SCI)により、最小接続間隔が7.5 msから375 µsに短縮され、高性能HIDデバイス、リアルタイムHMIシステム、センサーなどのデバイス応答が高速化されます。

Channel Sounding 攻撃耐性は、高度なRF振幅攻撃を検出、軽減することで安全なレンジングを強化し、車載、スマートホーム、産業環境におけるリレーやスプーフィング脅威からの保護を追加します。

HCI USB LE Isochronous Supportは、Host (HCI)パケット伝送を統一し、シームレスなブルートゥース® LE オーディオの統合を容易にするバルクシリアライゼーションモードを導入することにより、USB上でのアイソクロナス通信を標準化します。

LEテスト・モードの強化により、無線PHYテスト用の統合テスト・プロトコル(UTP)、標準化されたメッセージング、テスト制御の改善により、無線(OTA)サポートによる柔軟で安全なRFテストが可能になります。

ブルートゥース®ブルートゥース® LE 、無線デバイスの遅延、スループット、消費電力のバランスを取るために、設定可能な接続間隔を利用しています。従来、最小接続間隔は7.5ms、分解能は1.25msでした。これは多くのアプリケーションには十分ですが、AR/VR、ゲーム、リアルタイム・センシングなど、待ち時間の影響を受けやすいユースケースには制限があります。

最新のブルートゥース® 仕様では、最小接続間隔を375μs、分解能125μsに短縮しています。これにより、ミリ秒以下の通信サイクルが可能になり、より高速なデータ交換と応答性の高いユーザー体験がサポートされます。

このセクションでは、接続間隔の短縮の背景となる動機、それを可能にする仕様変更、および開発者が設計に組み込む際の主な考慮事項について説明します。

接続間隔の短縮(SCI)機能強化は、サポートされる最小間隔をわずか375µsに短縮し、125µsの細かい分解能でこの問題に対処する。この変更をサポートするため、仕様にはいくつかの重要な更新が導入されています:

  • 新しいリンクレイヤー 制御PDU:新しい短い接続間隔のネゴシエーションに使用される。
  • HCIコマンドとイベントを更新:Host 接続パラメータの制御を提供
  • 機能交換メカニズム:デバイスが新しいケイパビリティのサポートを示すことを可能にする
  • フラッシュ可能なACLデータをサポート:送信バッファに古いデータが蓄積されるのを防ぐ

新しいモデルの下で接続間隔を効果的に管理するために、SCIはタイミングパラメーターの交渉と適用に3つの値の枠組みを導入している。これらの値は

接続値項目使用方法
ベースライン接続間隔値(BCV)SCIがサポートされていない場合のデフォルトの接続間隔範囲。7.5ms以上、1.25msの倍数。
丸められた接続間隔値(RCV)SCIがサポートされている場合、必須の接続間隔範囲。1.25ms以上、1.25msの倍数。
拡張接続間隔値(ECV)SCIがサポートされている場合に利用可能なオプションの拡張範囲。これらの値は上位レイヤーを通してペリフェラルからセントラルに伝達される。1.25ms以下、125μs単位で375μsまでの接続間隔が可能。また、125μsの分解能で1.25ms以上のインターバルもサポート(例えば、BCVでは不可能な32ms)。

短いインターバルの手順を開始する前に、デバイスは機能 情報を交換する。

新しい機能 ビット

  • 接続間隔の短縮 - コントローラのサポート(ピアに送信)
  • 接続間隔の短縮 -Host サポート(ピアに送信、host
  • LE フラッシャブル ACL データhost、ピアに送信されない)

ルール

  • 両方のピアで間隔短縮のサポートがアドバタイズされている場合、新しいリンクレイヤー PDUを使用することができる。
  • そうでなければ、接続はベースライン接続間隔値(BCV≥7.5ms、1.25msの倍数)に制限されたままである。
  • LE Flushable ACL Dataが設定されていない場合、Host データをflushable としてマークできず、コントローラはすべてのACL PDUを送信しなければならない。

実際には、フラッシュ可能なACLデータ機能 、データ・レートが増加したときに古いトラフィックが蓄積されるのを防ぐことによって、短い接続間隔を補完する。

従来のLL_CONNECTION_UPDATE_IND PDUは低遅延アプリケーションに十分な柔軟性がないため、接続レートネゴシエーションのために2つの新しいPDUが作成された:

  • LL_CONNECTION_RATE_REQ- 新しいタイミングパラメータの完全な提案を含むリクエスト(ペリフェラルによって送信される)
  • LL_CONNECTION_RATE_IND- 特定のイベントカウントで最終パラメータを確認し、強制する応答 インスタント(常にセントラルから送信される)

LL_CONNECTION_RATE_REQ - "提案"
この PDU は、ペリフェラルが更新を提案するために送信する。これは、許容可能な接続間隔の範囲、最小および最大サブレート係数、ペリフェラルの最大待ち時間、データ送信後の必要な連続アクティブイベント数、監視タイムアウト、好ましい周期性、および所定の接続イベントカウンタに参照される最大4つのアンカーオフセット候補を提供する。

重要なセマンティクスは以下の通り:

  • Interval_Min / Interval_Max: connIntervalの許容範囲を125μs単位で定義する。セントラルはこれらの範囲内の値を選択しなければならない。
  • SubrateFactorMin / SubrateFactorMax: サブレート係数の許容範囲を定義する。これらの値はレイテンシーと共同で制約される:SubrateFactorMax × (Max_Latency + 1) ≤ 500。
  • Max_latency:ポストサブレートイベントで表される。実際に選択されたサブレート係数に依存しない。
  • ContinuationNumber:データイベントの後にアクティブでなければならない、後続イベントの最小数。これはHIDのようなトラフィックに有用である。
  • タイムアウト:監視タイムアウト。10ミリ秒単位。
  • PreferredPeriodicity:提案された間隔が理想的にはこの値の倍数であることを示す(125μs単位)。値0は優先しないことを意味する。
  • ReferenceConnEventCount:提供されたオフセットの評価に使用される参照カウンタ。
  • Offset0~Offset3:最大4つのアンカー・オフセット候補(分解能125 µs)。それぞれ一意で有効でなければならない。0xFFFF は、そのオフセットが未使用であることを示す。



LL_CONNECTION_RATE_IND- 「確認と実施
このPDUは、最終的に選択されたパラメータを確認するために、セントラルによってのみ送信される。Instantフィールドは、新しいパラメータが有効になる正確な接続イベントカウンタを定義する。

主なポイントは以下の通り:

  • インターバル:LL_CONNECTION_RATE_REQ で指定された範囲内でなければならない。
  • WinOffset(transmitWindowOffset):切り替え後の最初のイベントの、古いアンカーからの相対的なオフセット。
  • インスタント:イベントカウンターは、切り替えポイントを定義する。
  • SubrateFactor、latency、ContinuationNumber、timeout:セントラルが適用する最終値

ペリフェラルはインスタントで新しいパラメータを設定する。 シームレスな移行を確実にするために、双方は同期を維持しなければならない。

接続レート更新手順(セントラル駆動)

  • 開始:開始:セントラルは、機能 交換に成功し、相手が短縮接続間隔(Host support)をサポートしていることを確認した後 にのみ、この手順を開始することができる。これはHost コマンドによって、あるいはペリフェラルリクエストに応答してトリガされる。フローチャートとして図3.2.4aを参照のこと。
  • 制限事項:制限:他の手順(接続パラメータ要求、サブレート要求、CS 手順など)が進行中は開始できない。
  • 実行する:
    • セントラルは新しいインターバルを選択する(PHYの最小値を下回らない)。
    • LL_CONNECTION_RATE_INDを、選択したパラメータとともに送信する。
    • Instantはスイッチングのイベントカウントを定義する。両方のデバイスは、サブレートに関係なく、Instantとその直前のイベントの間、送信とリッスンをしなければならない。
    • Instantの後、両デバイスは新しいインターバル、レイテンシー、サブレート、監視タイムアウトで動作する。
  • 送信ウィンドウオフセット:新しいパラメータを持つ最初のパケットは、古いアンカーの後、connIntervalOLD + transmitWindowOffsetだけ遅れるかもしれない。
  • 完了:インスタントが経過し、新しいパラメータがアクティブになるか、どちらか一方がPDUを拒否すれば、手続きは完了する。監督タイマーは新しいアンカーポイントでリセットされる。

図3.2.4a セントラルAは接続レートを変更する

接続レート要求手順(ペリフェラル駆動)

  • 開始:ペリフェラルはLL_CONNECTION_RATE_REQを送信して変更を提案することができる。Host コマンドは通常、このアクションをトリガする。典型的なフローチャートの例を以下の図3.2.4bに示す。
  • 制限事項セントラルケースと同じ -パラメータ サブレート要求手続きと重複することはできない。
  • 実行する:
    • ペリフェラルは、パラメータ リクエスト(インターバル、タイムアウト、オフセット)とサブレートリクエスト(サブレート係数、レイテンシ、継続)に定義されたルールに従ってリクエストを準備する。
    • セントラルはLL_CONNECTION_RATE_INDで応答して受諾するか、LL_REJECT_EXT_INDで拒否する。
  • 拒絶の原因
    • コントローラビジー(0x3A) - 進行中の手順が競合しているため
    • 無効な LL パラメータ (0x1E) - 不正な、または範囲外のフィールド
    • サポートされていない LLパラメータ 値 (0x20) - 有効だが許容できない
    • サポートされていない機能 または値 (0x11) - 例えば、間隔が小さすぎて必要な PDU 長を収容できない。
  • 完了: セントラルが返答(受諾または拒否)し、受諾の場合はその後の更新手続きが完了した時点で手続きは終了する。

図3.2.4b:ペリフェラルBが接続レートの変更を要求し、セントラルAが受諾する

ペリフェラルがLL_CONNECTION_RATE_REQを送信するとき、またはセントラルがLL_CONNECTION_RATE_INDで応答するとき、これらのPDU内のインターバル関連フィールドは任意の値ではありません。これらは、互換性と実装の明確さのために仕様が導入している、明確に定義された接続間隔値のセット(BCV、RCV、ECV)から選択されなければならない。

セクション2.1で言及したBCV、RCV、ECVの範囲の関連性は、新しいLL PDUを解釈する際に明らかになる:

  • LL_CONNECTION_RATE_REQでは、Interval_MinおよびInterval_Maxフィールドは有効なECV値でなければならない。
  • LL_CONNECTION_RATE_INDでは、選択されたIntervalは双方が許容できる値にマップバックされなければならない。ピアがRCVしかサポートしていない場合、セントラルはそれに応じて選択を制限しなければならない。

このレイヤーアプローチは、相互運用性を壊すことなくSCIを導入できることを保証する:BCV値しか理解できないコントローラでも相互運用は可能です。SCI機能 サポートするコントローラは、この機能最小必須値としてRCVをサポートしなければなりません。さらに、ECV値はオプションであり、セントラルデバイスは上位レイヤを通じてペリフェラルがECVをサポートしていることを知る。

つまり、BCVは後方互換性を確保し、RCVはレガシー・アライメントと柔軟性のバランスをとり、ECVは超低遅延アプリケーションに必要な完全な解像度を解き放つ。

Host コントローラ・インターフェース(HCI)では、Host制御とSCI機能可視性を提供するために、いくつかの新しいプリミティブが導入されました。これらのコマンドとイベントは、オフセット・リストやインスタン トなどの低レベルの詳細を抽象化して、新しいリンクレイヤー 反映し ています。

  • HCI_LE_Connection_Rate_Request(Command)
    Host コネクションパラメータの変更を要求できるようにし、コントローラはそれをピアへの LL_CONNECTION_RATE_REQ(ペリフェラル主導型コネクションの場合)または LL_CONNECTION_RATE_INS(セントラル主導型コネクションの場合)に変換する。
  • HCI_LE_Set_Default_Rate_Parameters(Command)
    セントラル・Host 新しい接続のデフォルトの接続レート・パラメータを事前に設定できるようにすることで、各接続を個別に再設定する必要がなくなります。
  • HCI_LE_Read_Minimum_Supported_Connection_Interval (Command)
    Host コントローラーがサポートする最小間隔と分解能を問い合わせることができる。
  • LE 接続レート変更(イベント)
    レート更新が成功(適用されたインターバル、レイテンシ、監視タイムアウトを伴う)または失敗(エラ ー・ステータスを伴う)のいずれかで完了したときにHost 通知。

これらのプリミティブを組み合わせることで、Host 、柔軟だが抽象的な方法でSCIを要求、監視、設定することができる。

接続間隔が短くなると、古くなったデータがコントローラのバッ ファにすぐに蓄積されます。古くなったトラフィックが新しいトラフィックをブロックするのを防ぐために、Host 特定の ACL データをフラッシュ可能に指定することができます。

フラッシュ可能なACLデータとフラッシュ不可能なACLデータの違いを素早く理解するために、次の2つの図にその違いを示す。

水洗式ACLデータケース:

図 3.2.7a では、データパケットは ACL Flush Timeout で設定されている。リンクレイヤー 遅延が発生したとき(たとえば、パケット3が再送されるとき)、キュー内のパケット(パケット4や5のような)が設定されたタイムアウトよりも長くバッファに残っている場合、それらはフラッシュされる。この動作は、すべてのパケットが正常に配信されることを保証するよりも、伝送路のデータが新鮮であることを保証することを優先します。

図3.2.7a:コントローラにフラッシュ可能データを送信するHost 例

流せないACLデータケース:

図3.2.7bでは、データパケットにタイムアウトが設定されていないか、タイムアウトが 無限に設定されている。リンクレイヤー 遅延が発生すると、これらのデータパケット(4と5のような)はキューに残ります。それらは、古いパケット(パケット3)が正常に送信され、確認された後 にのみ送信される。この動作により、すべてのデータパケットが確実に送信され、データの完全性と信頼性が優先されます。

図3.2.7b:フラッシュ不可能なデータをコントローラに送信するHost 例

次に、ACLデータをHost コントローラにフラッシュする具体的な手順を説明する。

  • Host 、L2CAP PDUをHCIで送信するときに、その最初のフラグメントをフラッシュ可 能(flushable)としてマークする。これは、ACLデータパケットヘッダーのPacket_Boundary_Flagで示される。このようなPDUだけがフラッシングの対象となる。
  • コントローラは、各ACL論理リンクのフラッシュタイムアウトを維持する。このタイマーは、フラッシュ可能な ACL-U パケットの最初のフラグメントが格納されたときに開始する。
  • PDUのフラグメントが送信される前にフラッシュタイムアウトが終了すると、 コントローラは、まだ到着している可能性のある継続フラグメントを含め、 そのPDUのすべてのフラグメントを破棄する。ベースバンドキューは、残りのセグメントもクリアされる。
  • フラッシュ後、次の ACL-U パケットは通常通り処理される。次の送信 PDU は常に L2CAP 開始指示(LLID = 10)を持ち、ピアは、アプリケーション ペイロードの欠落を検出する必要がある場合、カウンタやタイムスタンプのような上位レイヤのメソッドを利用できる。
  • タイムアウト前にPDUの一部が送信された場合、フラッシュタイマーはキャンセルされ、パケットは正常に配送される。
  • デフォルトでは、Flush Timeoutは無限であり、明示的に設定されない限り、パケットは決してフラッシュされない。

Host コントロール

  • Host 、リンクごとのフラッシュタイムアウトを HCI_Write_Automatic_Flush_Timeout 命令
    • 0x0000は無限(フラッシュなし)を意味する。
    • 有限の値Nは、N×0.625msのタイムアウトに対応する。
  • コマンドが完了すると、コントローラは標準の Command Complete イベントを生成します。

このメカニズムにより、新しいトラフィックが古いパケットによって遅延されることなく、迅速に配信されることが保証される。

SCI機能 、ブルートゥース® LE大きな進歩です。最小間隔を 375µs に短縮し、125µs のきめ細かい分解能を実現することで、高性能ゲーミング周辺機器や没入型 VR/AR コントローラなど、超低遅延を要求する次世代アプリケーションを可能にします。

新しいリンクレイヤー PDU、堅牢なネゴシエーション手順、および更新された HCI コマンドの導入により、高速データ配信を管理するための包括的なフレームワークが提供されます。また、ACLフラッシュメカニズムにより、古いパケットが新しい伝送をブロックすることを防ぎ、応答性を向上させます。

これらの技術革新により、ブルートゥース® LE 完全な後方互換性を維持しながら、最新技術の厳しいレイテンシ要件を満たすことができます。

ブルートゥース® Channel Sounding 、ブルートゥース® コア仕様のセキュアなファインレンジ機能 、Bluetooth 接続デバイス間の安全かつ正確な距離測定を可能にするように設計されています。無線信号の物理的特性を活用することで、受信信号強度インジケータ(RSSI)方式を大幅に改善し、センチメートルレベルの精度を実現します。また、高精度位相ベース測距 ための位相ベース測距 PBR)と、リレー攻撃に対するセキュリティ対策としての往復時間 RTT)を組み合わせています。このデュアル・メソッド・アプローチは、ブルートゥース® 接続デバイス間の距離測定の精度とセキュリティの両方を向上させます。

ブルートゥース® コア仕様では、距離測定の整合性を保護するために、攻撃の可能性を示すスライディング・スケールである正規化攻撃検出メトリック(NADM:Normalized Attack Detector Metric)を定義しています。この仕様では、固定的なアルゴリズムを規定するのではなく、CS_Sync パケットに予期しないビット遷移や位相変化などの異常がないかどうかを評価する柔軟なフレームワークを提供しています。コントローラは NADM 値を生成し、Host コントローラ・インタフェース(HCI)イベントを介してhost 報告するため、アプリケーション 脅威評価を実行できる。

アーリーコミット攻撃はレンジング攻撃の一種で、信号の位相を操作して、正規の信号よりも早い到着時刻をレシーバー 認識させる攻撃です。この攻撃は、位相を調整した細工信号を注入することで機能します。一例として、各シンボルの先頭にガウシアンモノパルスを追加することで実現できます。この操作により位相が歪み、計算距離が短くなり、中間者(MITM)攻撃可能になります。このような攻撃を検出するには、正規化相互相関や位相最小二乗誤差などの方法を使用して、受信信号の位相を基準と比較し、異常な位相ジッタを特定します。

セキュリティ脅威の進化に伴い、NADMフレームワークの拡張が必要となった。振幅ベースの信号操作を悪用する新しいクラスの攻撃が特定されました。位相ベースの攻撃と同様に、これらもアーリーコミット効果を狙いますが、レシーバー内の振幅から位相への変換を悪用することで行います。この新しいレジリエンス機能 、このような脅威に直接対応するもので、既存のNADM機能の重要な拡張機能として機能し、特にブルートゥース® Channel Sounding RTT パケットに対する振幅ベースの攻撃を標的とし、これを軽減します。

振幅ベースの攻撃の核となるメカニズムは、レシーバーフロントエンドの非線形応答を利用することである。攻撃者は、通信のシンボル・タイミング・グリッドに正確に同期した正規の信号に、周期的な増幅プロファイルを適用します。この制御された振幅操作は、レシーバー予測可能な位相歪みをもたらし、知覚される信号タイミングを効果的に前方にシフトさせ、結果として高度なタイミング測定をもたらします。

最新のブルートゥース® コア仕様ブルートゥース® コア 6.2)では、このような攻撃を検出するための離散フーリエ変換(DFT)ベースの手法が導入されています。この手法が選択された理由は、予測可能な振幅攻撃はシンボル周期と相関があるため、周波数領域で明瞭で定量化可能なエネルギー・ピークとして現れるからです。これらのピークは、1倍と2倍のシンボル周波数またはその近傍に現れる。これらの特定の周波数ビンでエネルギーを測定し、信号全体のエネルギーと比較することで、DFTメトリックは攻撃を確実に検出することができます。この方法は、攻撃の周期的な性質を特にターゲットにしているため、ランダムで相関のない振幅変動による誤検出を避けることができ、他のアプローチ(安定エンベロープメトリックなど)よりも頑健です。

振幅ベースのアタック信号  は正規の信号を変調することによって構成される、 反復増幅パターン項を持つ、 これはデータパケットのシンボル周期と同じである、 .攻撃者はまず、被害者のシンボル・タイミング・グリッドを推定しなければならない。その後、周期的なゲイン・プロファイルを適用する、 これは反復項の和である、 を正規の信号に変換する。図4.2.2に示すように、簡略化した矩形波攻撃モデルをテストと特性評価に使用する。攻撃信号は次式で与えられる:  = .

図4.2.2:の関係を示す波形。  そして

 正規の信号のシンボル周波数に等しい周波数を持つ方形波に対する疑似コードは、以下のように定義される。

このモデルは、テストのための3D探索空間を形成する3つの主要パラメータによって定義される。これらのパラメータは、与えられたデバイスに対して最も効果的な攻撃コンフィギュレーションを特定するために、テスト中に体系的に探索され、以下の表にその概要が示されている:

パラメータ 定義 レンジ インデックスの範囲
ポー シンボル開始位置からのアタックパターン開始位置のオフセット時間 0.03125~0.96875、0.0625刻み [1, 16]
DC Tsymの割合としてのパルス上のアンプのデューティ・サイクル 0.03125~0.96875、0.0625刻み [1, 16]
アグ アンプ・ゲインのスケーリング係数。1.0は元の信号を表す。 2.0, 1.9, 1.8, 1.7, 1.6, 1.5, 1.45, 1.4, 1.35, 1.3, 1.275, 1.25, 1.225, 1.2, 1.175, 1.15, 1.125, 1.1, 1.075, 1.05 [1, 20]

一般的に、オフセット()とデューティ・サイクル()は、アタックがタイミングを進めるかどうかを決定し、アンプのゲイン()は、タイミングの進みの大きさを制御する。

DFTメトリックは、周波数領域で信号を分析することにより、周期的振幅攻撃の存在を検出するために設計された定量的尺度である。核となる原理は、攻撃が有効であるためには、そのエネルギーがシンボル周期と十分に相関していなければならないということです。この相関により、シンボル・レートの基本周波数と高調波周波数の近傍で、周波数領域において明瞭なエネルギー・スパイクが生じます。

  • DFT相関とは?DFT(離散フーリエ変換)とは、信号を時間領域(時間とともにどのように変化するか)から周波数領域(様々な周波数成分の強さ)に変換する数学的ツールです。この文脈では、DFT相関はDFTの出力、つまり、それぞれが信号内の特定の周波数成分の強度と位相を表す係数の集合を指す。特定の周波数での相関が高いほど、その周波数成分が信号中に多く存在することを意味する。
  • 攻撃への適用方法振幅攻撃はデータパケットシンボル周期と正確に同期した周期的パターンであるため、周波数領域でユニークなフィンガープリントを作成します。このフィンガープリントはシンボル周波数(f1=1/Tsym)とその高調波(f2=2/Tsym)に予測可能なエネルギーピークとして現れます。

DFT測定法はこの原理を利用している。DFTは、これらの特定のエネルギーにおける結合エネルギーの比率を計算する。 攻撃周波数 (そして )を信号の直流成分(ゼロ周波数)のエネルギーに変換する。参考式は

どこだ?

  • φ(f1)およびφ(f2)は、シンボル周波数(f1)およびシンボル周波数の2倍(f2)におけるDFT相関である。
  • φ(0)はDC成分でのDFT相関

DFTメトリックの値が高いほど、攻撃の可能性が高いことを示します。これは、振幅攻撃の周期的なトーン特徴 のより顕著な存在を意味するからです。このメトリックは、振幅ベースの操作を確実に識別するためのロバストな方法を提供します。

実際の検出能力を試験する前に、被試験機器(IUT)はまず特性評価を受け、操作に対する感受性を決定しなければならない。このプロセスにより、以下の特定の組み合わせが特定される。 そして  レシーバー行動に影響を与えるのに最も効果的なもの。特徴づけのプロセスには、以下のステップが含まれる:

  • 初期データの収集: イニシエータ機能するテスターデバイスは、初期アンプゲインAgを高い値に設定します。その後、デューティ・サイクル(DC)と時間オフセット(pd)の組み合わせを系統的に実行し、信号のタイミングの進み具合を記録する。このプロセスは、攻撃効果のマップを作成するように設計されている。
  • データの平滑化:ランダムなノイズ測定を軽減するため、空間フィルタを生データに適用して平滑化する。このステップにより、特定された有効な攻撃ポイントが本物であり、偶発的な測定エラーによるものではないことが保証される。
  • ローカルミニマムの探索:次にテスターデバイスは、平滑化されたデータのローカルミニマムを検索する。これらのポイントは、攻撃が最大のタイミング前進を引き起こしたパラメータ 組み合わせを表します。このようなポイントは最も攻撃的な攻撃コンフィギュレーションとみなされ、記録されます。
  • 増加利得の削減と効果判定:特定された注目ポイントごとに、テスターはインクリメンタルテストを実施する。アンプ利得(Ag)を徐々に減少させ、各ステップでZ検定と呼ばれる統計的手法を適用して、攻撃がまだ有効かどうかを判定します。核となる考え方は、攻撃信号の平均的なタイミングの進み具合を正規の信号の平均と比較し、その差が統計的に有意(つまり10nsより大きい)かどうかを判定することである。この差が十分に大きい場合、有意な差が生じなくなるまでゲインが低下するまで、攻撃コンフィギュレーションは有効であると判断される。

特性評価段階で特定されたすべての注目点のパラメータは、キーとなるデータ構造に格納され、その後の検出要件をテストするための基礎となる。

プロセスの最終段階では、必須試験を通じて IUT の NADM 性能を検証する。本節では、IUT の NADM 実装が正規の信号と振幅ベースの攻撃信号を効果的に区別できるかどうかを判断するため の試験方法について説明する。

  • 試験手順:IUT は、様々な PHY(LE1M、LE 2M、LE 2M 2BT)とRTT ステップタイプ(Mode-1、Mode-3)において、特性評価中に発見された最も効果的な 攻撃パラメータを用いて試験される。各試験では、正規の信号と攻撃者が変調した信号がランダムな順序で送信される。
  • 性能閾値:IUT は、高い信頼性で攻撃の有無を正しく識別しなければならない。各試験において、IUT が報告する NADM 値の少なくとも90%が、信号が正常か攻撃かを正しく反映しなければならない。この閾値を満たさない場合、テストは不合格となり、最終的に認証された実装がこれら特定の脅威に対して堅牢であることが保証される。

Channel Sounding 攻撃回復力のための HCI とリンクレイヤー 更新
新しいアンプリチュード・ベースの NADM 機能をサポートするために、 リンクレイヤー HCI)とリンクレイヤー リンクレイヤー )が更新されました、ブルートゥース® Host コントローラ・インターフェース(HCI)とリンクレイヤー (LL)が更新され、デバイスがこれらのセキュリティ機能と通信し、応答できるようになりました。

HCI アップデート
既存の HCI コマンドとイベントに新しいパラメータが追加され、振幅ベースの NADM サポートを管理できるようになった:

  • LE CS Read Remote Supported Capabilities Complete イベント:リモート・デバイスがサウンディングとランダム・シーケンスの両方で振幅ベースの攻撃検知をサポートしているかどうかを示すビットが含まれるようになりました。
  • LE CS Read Local Supported Capabilities コマンド:host コントローラの振幅ベースの NADM 機能をクエリできるようにする。
  • LE CS Write Cached Remote Supported Capabilities コマンド:host リモート・デバイスの能力をキャッシュし、接続プロセスを最適化できるようにする。

これらのアップデートは、デバイス間のダイナミックな能力ネゴシエーションと認識を可能にする。

リンクレイヤー(LL)の更新
LL_CS_CAPABILITIES_REQ/RSP PDU(プロトコル・データ・ユニット)が更新され、振幅ベースの NADM機能サポートを示すビットが追加された。これにより、デバイスはChannel Sounding 初期化中に、ブルートゥース® で直接セキュリティ機能を調整できるようになります。

振幅ベースの攻撃回復力の導入により、ブルートゥース® Channel Soundingセキュリティ機能が強化されます。この仕様では、正確な攻撃モデル、堅牢な DFT ベースの検出指標、徹底した多段階のテストレジ メンを定義することで、認証されたデバイスが距離測定を操作する巧妙な試みを確実に検出できるようにしています。HCIおよびリンクレイヤー 必要な更新と相まって、この機能強化は、進化する脅威を軽減するための包括的な枠組みを提供します。これは、ブルートゥース® テクノロジーの継続的なセキュリティ向上へのコミットメントを反映したものであり、新たな課題に直面しても、その精密測距技術が正確で信頼できるものであることを保証するものです。

2022年、ブルートゥース® テクノロジーはアイソクロナスデータ伝送、コネクテッド・アイソクロナスストリーム(CIS)、ブロードキャスト・アイソクロナスストリーム(BIS)のサポートを追加しました。USBベースのアイソクロナス通信機能に対する市場の要望により、BluetoothSIG HCI USB LE Isochronous Support機能開発しました。

従来、HCI USB トランスポート・レイヤーは ACL、コマンド、イベント、SCO/eSCO トラフィック用のエンドポイントを定義していた。しかし、LE Isochronous トラフィックを USB 経由で伝送するための標準化された方法は存在しなかった。このギャップにより、相互運用性の課題が生じ、実装が分断され、場合によっては、ベンダーはカスタムの USB エンドポイントを定義するか、非標準的な方法でバルク・エンドポイントを介して LE ISO トラフィックを多重化する必要があった。

アドレス ため、バルク・シリアライゼーション・モードと呼ばれる新しい動作モードが導入された。このアプローチは、LE Isochronousデータストリームの伝送に統一された標準的な方法を提供し、既存のUSBコントローラとの幅広い互換性を持つように設計されているため、新製品の市場投入までの時間を短縮するのに役立ちます。

ブルートゥース® コントローラのUSBトランスポート層は、2つのモードのいずれかで動作します:レガシー・モードとバルク・シリアライゼーション・モードです。すべてのUSBトランスポート層の実装はレガシー・モードをサポートする必要がありますが、バルク・シリアライゼーション・モードのサポートはオプションです。

  • レガシーモード:これは、異なるHost (Host )パケットタイプが専用のUSBエンドポイントを介して送信される従来のモードです。具体的には、HCIコマンドは制御エンドポイントを使用し、HCIイベントは割り込みエンドポイントを使用し、ACLデータはバルクエンドポイントを使用し、SCO/eSCOデータはアイソクロナスエンドポイントを使用します。このモードの主な制限は、LEアイソクロナスチャネル上でデータを交換するための標準化されたメカニズ ムがないことである。
  • バルク・シリアライゼーション・モード:このオプション・モードは、HCI ISOデータ・パケットを含む全てのHCIパケットをバルク・エンドポイントに統合することで、レガシー・モードの制限に対処します。このアプローチにより、LEアイソクロナスチャネル不可欠なサポートを提供しながら、幅広い既存のUSBコントローラとの互換性を最大化します。

正確な手順により、Host コントローラに新しいモードへの切り替えを指示することができます。このメカニズムは、USB仕様の重要なコンセプトである「代替設定」を活用しています。1つのUSBインターフェイスは複数の代替設定をサポートすることができ、それぞれが異なる動作モードやコンフィギュレーションを表します。

  1. サポートの表示:バルク・シリアライゼーション・モードをサポートするコントローラは、USB コンフィギュレーション記述子の最初のインターフェイスに追加のオルタネート設定(オルタネート設定 1)を含めることで、この機能を通知します。この代替設定はバルク・エンドポイントのみを含み、デフォルトのレガシー・モード設定(通常は代替設定0)と区別されます。
  2. 切り替えコマンド:Host 、標準的なUSBセレクトインターフェースリクエストを発行してこの特定の代替設定をアクティブにすることで、バルクシリアライゼーションモードへの切り替えをコントローラに指示します。これによりHost 、デバイスが接続された後にインターフェイスの動作モードを動的に変更することができます。

モード切り替えに別の設定を使用することは、既存のコントローラとの互換性リスクを低減するため、USB制御転送に基づく以前の提案よりも信頼性が高いと考えられている。

バルクシリアライゼーションモードでは、すべてのHCIトラフィックが同じバルクエンドポイントに多重化されるため、パケットタイプを区別するメカニズムが必要になります。これは、各HCIパケットの前に1バイトのHCIパケット・インジケータを付けることで達成される。
以下の表は、各HCIパケット・タイプに定義されたインジケータを指定したものである:

HCIパケット・タイプHCIパケットインジケーター
HCIコマンドパケット0x01
HCI ACLデータパケット0x02
HCI同期データ・パケット0x03
HCIイベントパケット0x04
HCI ISOデータパケット0x05
将来の使用のために予約その他のすべての値

このシステムは、受信側がデータストリームを正確に解析し、各パケットを対応するハンドラーにルーティングすることを可能にし、単一のインターフェイス上で複数のHCIデータタイプを効率的に伝送することを可能にする。

この新しいモードは、ブルートゥース® LE オーディオを有効にするだけでなく、レガシーUSBトランスポート層の持続的な競合状態を解決します。レガシー・モードでは、異なるエンドポイント・タイプがUSBフレーム内で特定の順序でサービスされるため、データやイベントの配信に順序ずれが生じる可能性があります。例えば、Host データ・パケットを、その到着を知らせるイベントよりも先に受信する可能性があります。この動作は、接続のセットアップ、切断、データの暗号化などの重要なプロセスを中断させ、ユーザー・エクスペリエンスに悪影響を及ぼす可能性があります。

バルク・シリアライゼーション・モードは、すべてのHCIパケットを単一のバルク・エンドポイントに統合することで、この問題を効果的に解消します。データが単一の順序付けられたストリームとして伝送されるため、ブルートゥース® アプリケーションの堅牢性が大幅に向上します。

ブルートゥース® LE コア仕様の更新は、バルク・シリアライゼーション・モードの定義を通じて USB トランスポート・レイヤーに重要な機能強化を導入します。この新しいモードは、USB 上で LE 等時性ストリーム(ブルートゥース® LE オーディオ・データなど)を伝送するための標準化された下位互換性のある方法を提供します。全てのHCIパケットタイプをバルクエンドポイントに統合し、シンプルなパケットインジケータを使用することで、更新された規格は競合状態を解消し、信頼性を向上させ、ブルートゥース® Host コントローラ間の堅牢な通信チャネルを確保します。これらの改善により、最新のブルートゥース® デバイスでより高度なオーディオおよびデータ・アプリケーションを実現するための基盤が構築されます。

ブルートゥース® LE 仕様は、デバイスの相互運用性と性能基準が満たされていることを保証するため の物理層(PHY)テストを定義しています。トランスミッター 性能、レシーバー 感度、ブルートゥース® Channel Soundingような新機能をカバーするこれらのテストは、コンフォーマンスと品質保証に不可欠である。歴史的に、LE 機器の無線を制御しテストする主な方法は、ダイレクト・テスト・モード(DTM) の使用であった。

DTM は、試験装置(上位テスタ)と被試験実装(IUT)間の物理的トランスポートインターフェース上で動作する。このインターフェースは通常、図1.1に示すように、Host (Host )または2線式UARTのいずれかである。テスターは標準化されたコマンドを送信し、対応するイベントを受信して IUT の無線を制御し、コンフォーマンステ ストを行う。例えば、LE_Transmitter_Test や LE_Receiver_Test のようなコマンドは、IUT を送信状態または受信状態するために使用され、LE_Packet_Report のようなイベントは、試験結果に関するフィードバックを提供する。

図 6.1.1 RFPHY テストモードのセットアップの選択肢

この方法は、物理的な I/O ポートが容易に利用可能な場合、design ・開発段階で効果的に機能する。しかし、ブルートゥース® LE ソリューションが最終製品統合されると、重大な制限が生じる。この状態、物理的な制御インターフェースにアクセスできなくなることが多く、ポストプロダクションやOTA(Over-the-Air)コンフォーマンス・テストの選択肢が著しく制限されます。さらに、有線接続の存在は時にデバイスの RF 特性に影響を与え、試験結果を歪める可能性がある。

ブルートゥース® コア仕様では、DTM の限界をアドレス するため、統一テストプロトコル(UTP)を導入しています。この新しいテストモードは、DTM に代わるものとして設計されており、OTA トランスポートをサポートすることで、物理制御インターフェイスへの依存性を排除するという重要な利点があります。UTPは、DTMと同等のRF PHYテストを可能にし、物理I/Oポートにアクセスできない場合でも完全な仕様準拠を保証します。さらに、UTP は BERレシーバー 測定を可能にし、基本的な PER 測定の枠を超える。これにより、レシーバー性能をより深く理解することができます。

典型的なUTP試験シナリオは、上位試験装置とIUTの間で定義された一連のメッセージに従う。上位テスタは、IUTがサポートするUTP機能を問い合わせることにより、プロセスを開始する。これに続いて、オプションでパラメータをリセットし、特定のトランスミッター またはレシーバー 試験用にIUTを設定することができる。その後、試験が開始、実行、停止され、IUT から試験者に詳細レポートが返される。

すべてのUTPメッセージは標準化されたTLV(Type-Length-Value)フォーマットに従う。Typeフィールド(1オクテット)はメッセージタイプを示し、Lengthフィールド(2オクテット)はペイロードのサイズを指定し、Valueフィールド(Lengthオクテット)は実際のメッセージペイロードを 含む。このTLV構造は、さまざまなメッセージに柔軟で拡張可能なフレームワークを提供する。
すべてのUTPメッセージは3つの主要なタイプに分類される:Configuration、Control、Reportである。

構成メッセージ
構成メッセージは、試験開始前にIUTの試験パラメータを設定するために試験者が送信する。設定メッセージは試験環境に対するきめ細かな制御を提供し、IUT が希望する試験シナリオに対して正しく設定されていることを保証する。これらのメッセージの完全なリストには以下が含まれる:

  • UTP_Set_RF_Channel:テストが実施されるRFチャンネルを指定する。
  • UTP_Set_Packet_Payload:テストパケットで使用するペイロードのタイプを設定する(疑似ランダム、オール1、オール0など)
  • UTP_Set_Payload_Length:テストデータペイロードの長さを設定する
  • UTP_Set_PHY:テストに使用する PHY(例:LE 1M、LE 2M、LE Coded)を設定する。
  • UTP_Set_Modulation_Index:トランスミッター 変調インデックスを設定する。
  • UTP_Set_CTE_Length:到着角AoA)または出発角AoD)テスト用の定数トーン拡張(CTE)の長さを指定する。
  • UTP_Set_CTE_Type:使用するCTEタイプを設定(例:AoA AoD
  • UTP_Set_CTE_Slot_Durations:CTEのスロット・デュレーションを定義します。
  • UTP_Set_CTE_Antenna_IDs:CTEに使用するアンテナパターンまたはアンテナIDを指定する。
  • UTP_Set_Packet_Count:送受信するテストパケット数を設定する
  • UTP_Set_Tx_Power_Level:IUT の送信電力レベルを調整する
  • UTP_Set_OTA_Exclusion_Period:無線テストの除外期間を設定する
  • UTP_Set_Vendor_Specific_Data:独自コンフィギュレーション用のベンダー固有メッセージ

制御メッセージ
制御メッセージは、IUT の開始、終了、および状態問い合わせを含む試験フロー全体を管理するために使用される。これらは試験シーケンスを指示するための主要コマンドとして機能し、その方向性に基づいて分類することができる。

  • 下部テスターまたは上部テスターが送信する制御メッセージ: これらのメッセージはIUTに特定の動作を指示する。
    • UTP_Query_Supported_Features:IUT がサポートする UTP 機能を報告するよう要求する。
    • UTP_Reset:IUT を初期試験構成にリセットする。
    • UTP_Start_Test: 事前に設定されたトランスミッター またはレシーバー テストを開始する。
    • UTP_Stop_Test:現在のテストを終了し、IUT に結果を報告するよう指示する。
  • IUTが送信する制御メッセージ: これらのメッセージは、コマンドに応答したり、テストの状態 示すために送信される。
    • UTP_Accept:コマンドが受け入れられたことを示す。
    • UTP_Reject:エラーによりコマンドが拒否されたことを示す
    • UTP_Reset_Accept:リセットコマンドを確認
    • UTP_Test_Ended:テストが終了したことを通知する

報告メッセージ
報告メッセージは、フィードバックと試験結果を提供するためにIUTから試験者に送られる。データを収集し、仕様に対する IUT の性能を検証するために不可欠である。これらのメッセージの完全なリストには以下が含まれる:

  • UTP_Report_Supported_Features:問い合わせに応答して送信されるこのメッセージは、IUT の UTP 機能と能力を詳述する。
  • UTP_Report_IQ_Samples:高度なテストに使用され、このメッセージは IUT のレシーバーI および Q サンプルデータを提供する。
  • UTP_Report_Receiver_Quality_Counters:受信パケット数やその他の品質メトリクスなど、レシーバー テストからの統計情報を提供します。
  • UTP_Report_Vendor_Specific_Data:独自のデータを報告するためのベンダー固有のメッセージ



UTP2線式UARTモード
DTMと同様、UTPは2線式UART物理トランスポートインターフェース上で動作します。このため、すでにこのインターフェイスを使用しているテストセットアップでは、DTM から UTP へのシームレスな移行が可能です。UTPメッセージはカプセル化され、上位テスタとIUT間のUART接続を介して交換される。

UTPHCIモード
UTPがHCIトランスポート上で動作する場合、特定のHCIコマンドとイベントが使用され、テストが容易になる。Host 、HCI_LE_UTP_Sendコマンドを使用してUTPメッセージをコントローラに送信でき、コントローラは、HCI_LE_UTP_Receiveイベントを使用してUTPメッセージの受信をHost 通知する。さらに、HCI_LE_Enable_UTP_OTA_Modeコマンドを使用すると、Host コントローラの OTA UTPモードを有効にすることができます。

UTPOTAモード
OTA(OTA)トランスポートは、UTPの最も重要な機能拡張です。このモードでは、コントロールメッセージと RF PHY テストパケットの両方が、2.4GHz RF インターフェース上でワイヤレスで交換される。

A コントローラは、UTP OTA モード手順を使って RF PHY テストモードに入る。セントラルまたはペリフェラルは、接続状態 入った後いつでも、LL_OTA_UTP_INDPDU を送信することで、この手順を開始できる。この PDU に対する確認リンクレイヤー 送受信されると、手順は完了したとみなされる。

LL_OTA_UTP_INDPDUフォーマット
LL_OTA_UTP_IND PDUのフォーマットは以下の通り:

  • Opcode (1バイト):UTP メッセージのタイプを識別する。
  • Transaction_ID(1バイト):リクエスト・メッセージとレスポンス・メッセージのペアリングに使われる識別子。
  • UTP_Message(変数)TLV(Type-Length-Value)構造に従う。これにより、コンフィギュレーションやコントロールメッセージ、任意のUTPメッセージタイプをメッセージに含めるこ とができ、高い柔軟性と拡張性を提供する。

セキュリティおよび暗号化要件
LL_OTA_UTP_IND PDUの多用途なフォーマットにより、UTPメッセージは効率的にカプセル化され、さまざまなテストシナリオにわたって送信される。
UTP OTAでは、重要なセキュリティおよび完全性チェックが実行される。UTP PDU は、以下の条件をすべて満たす場合にのみ処理される:

  1. ACL は暗号化される
  2. OTA UTP機能 コントローラでサポートされています。
  3. IUT で OTA UTP モードが有効になっている。

UTP PDUを受信したときにACLが暗号化されていない場合、コントローラは、 エラーコードInsufficient Security (0x2F) を含むLL_REJECT_EXT_INDPDUを送信して、PDUを直ちに拒否しなければならない。同様に、UTP PDUを受信したときにOTA UTPモードが有効になっていない場合、コントローラは、エラーコードCommand Disallowed(0x0C)を含むLL_REJECT_EXT_INDPDUを送信して、そのPDUを拒否しなければならない。

この仕組みにより、テスト・モードには、安全で事前に設定された条件下でのみ入ることができる。

OTAトランスミッター 試験では、上位テスタが IUT に RF PHY テストパケットの送信開始を指示する。
この試験の目的は、物理的接続が測定に影響を与えることなく、送信電力、電力密度スペクトル、変調精度な どの被試験機器のトランスミッター 特性を検証することである。図6.2.3に、OTAトランスミッター 試験の例を示す。

図6.2.3:OTAトランスミッター テスト例:下位テスターが早期にシーケンスを終了、パケット数に到達

OTAレシーバー テストでは、上位テスターがテストを開始し、下位テスターが設定された周波数で RF PHY テストパケットの送信を開始する。ロワーテスタは、設定されたパケットカウントを満たすのに必要な数の接続インターバルでパケットを送信する。

IUT はこれらのパケットを受信し、受信品質を報告する。この試験は、感度および遮断特性を含む IUT のレシーバー 性能を評価する。図6.2.4にOTAレシーバー 試験の例を示す。

図6.2.4:OTAレシーバー 試験例

ユニファイド・テスト・プロトコルの導入は、ブルートゥース® LE RF PHY のコンフォーマンステストにおける重要な進歩である。メッセージと制御メカニズムの包括的なセットを提供することにより、UTP は従来の DTM よりも柔軟で強力なソリューションを提供します。最も重要な点は、OTA トランスポートをサポートし、明確に定義された手順とリンクレイヤー ティ対策と組み合わせることで、物理インターフェース依存性という長年の制限に対処していることです。

UTP は、最終的なフォームファクタのデバイスをより実用的かつ正確にテストすることを可能にし、以前は管理が困難または 不可能であったシナリオにまでコンフォーマンステストの範囲を拡大します。

ブルートゥース® Core 6.2は、デバイスの応答性を高め、セキュリティを強化し、通信およびテスト機能を向上させる新機能を導入しています。接続間隔が大幅に短縮され、より高速で応答性の高いインタラクションが可能になるほか、高度なRF振幅攻撃から保護する高度なセキュリティ機能まで、これらの機能強化は最新のワイヤレス・エコシステムの進化するニーズにアドレス します。標準化されたUSB経由のアイソクロナス通信は、ブルートゥース® LE オーディオの統合を簡素化し、アップグレードされたテスト機能は、より柔軟で安全かつ包括的なRF検証を保証します。これらの進化により、ブルートゥース® テクノロジーは、幅広い業界やユースケースで継続的なイノベーションを実現します。

項目所在地
ブルートゥース®コア仕様v6.2 https://www.bluetooth.com/specifications/スペック/core-specification-6-2/
ブルートゥース®Channel Sounding 技術概要資料https://www.bluetooth.com/channel-sounding-tech-overview/