Bluetooth®高データスループット の技術概要

バージョン：	1.0
発行日：	2026年11月3日
著者	アルフレッド・ペレス

1.はじめに

Bluetooth®は、オーディオ、ウェアラブル、ヒューマンインターフェースデバイス、スマートホーム、産業用、自動車用、その他多くの市場分野にわたる幅広いアプリケーションやユースケースを可能にする、汎用性が高く広く普及している無線技術です。その成功は、エネルギー効率、相互運用性、使いやすさ、そして機能と性能の継続的な進化といった基本的な特長に根ざしています。 これらの特長が相まって、Bluetooth技術は規模を拡大し、堅牢な開発および製品 エコシステムを実現・支援するとともに、世界中の企業や消費者からの信頼を獲得してきました。

しかし、ワイヤレスアプリケーションの分野も進化を続けています。Bluetooth接続が長年にわたり活躍してきたシステムは、ますます高度化しており、これまで以上に多くのデータを生成、処理、管理するようになっています。例えばオーディオ市場では、シームレスなパフォーマンスと体験を実現するために、より高い忠実度やマルチストリームといったユースケースが求められており、これにはより大きなデータ容量と高速な通信が不可欠となっています。 Bluetoothにとって、これは既存の能力を超える、増大するスループット要件への対応が必要となっていることを意味します。このニーズに対応するため、Bluetooth Special Interest Group（SIG）は、Bluetooth LEに対して「Bluetooth®高データスループット （HDT）」と呼ばれる、アーキテクチャおよびパフォーマンスの大幅な強化を導入しています。

2016年にLE 2M PHYが導入されて以来、Bluetooth LEがサポートするPHYの最大ビットレートは2 Mbpsでした。Bluetooth® HDTにより、Bluetooth LEの性能と機能が大幅に拡張され、PHYの最大ビットレートが約4倍に増加するとともに、容量、エネルギー効率、信頼性も向上しました。 全体として、Bluetooth HDTはデータ転送時間を短縮し、より負荷の高いアプリケーションワークロードに対応するとともに、将来のイノベーションに向けた余地を生み出し、現代のアプリケーションのニーズに合わせて進化し続けるBluetooth技術ロードマップの基盤を確立しています。

本書は、Bluetooth高データスループット に関する技術的な概要を大まかに解説するものであり、読者がこのBluetooth技術における重要なマイルストーンについて基本的な理解を深めることを目的としています。

2.背景

原則として、通信システムにおいてスループットを向上させることの主な利点は単純明快です。すなわち、スループットが高くなれば、デバイス間で一定量のデータを転送するのに必要な時間が短縮されるか、あるいは逆に、所定の時間内に交換できるデータ量が増えるということです。しかし、伝送をより短時間で完了させることには、他にも貴重な利点があります。例えば、システム内のトランスミッター やレシーバー が稼働する時間が短くなるため、消費電力の削減につながる可能性があります。 また、これにより空いたエアタイムを解放し、管理された共存メカニズムを通じて、追加の通信リンクや、同じ場所に配置された他のシステムが利用できるよう再割り当てすることが可能になります。

実際には、通信システムのスループットを向上させるには、帯域幅（BW）、信号対雑音比（SNR）、およびスペクトル効率という3つの基本的な設計変数を調整する必要があります。シャノンの定理¹ は、帯域幅（BW）と信号対雑音比（SNR）がチャネル容量にどのように影響するかを定式化したもので、容量は帯域幅に比例して増加し、信号対雑音比には対数関数的に増加することを示している。しかし、シャノンの定理によって予測される容量に近づくためには、高いスペクトル効率を達成することが不可欠である。 スペクトル効率とは、利用可能な帯域幅1ヘルツあたりに何ビット/秒（bps/Hz）を伝送できるかを表す指標である。実際のシステムにおいて、スペクトル効率は、変調次数、符号化効率、シンボルレートといった物理層の設計選択や、帯域幅をどれだけ効率的に利用できるかに影響を与えるその他の実装要因に依存する。

Bluetooth技術は、簡潔性、信頼性、世界中で利用可能な免許不要周波数帯での効率的な動作、そしてBluetooth LEの場合はエネルギー効率を優先する原則に基づいて設計されています。このため、Bluetooth LEの無線部は、シンプルで堅牢、かつ低複雑度の変調方式であるガウス周波数シフトキーイング（GFSK）に基づく物理層で開発されており、前方誤り訂正は限定的であるか、あるいは全く採用されていません。 GFSK PHYの簡潔さは、これまでBluetoothに役立ってきており、今後も引き続き役立つでしょう。しかし、そのスペクトル効率は低いため、スループットを大幅に向上させるための選択肢は限られています。

再びシャノンの定理に言及すると、GFSK PHYのスループットを向上させるための1つのアプローチとして、その帯域幅（BW）を拡大することが考えられますが、2.4 GHz ISM帯の制約、そして何よりも、それに伴うアーキテクチャやエネルギー効率への影響を考えると、これは現実的ではありません。 別のアプローチとして、SNRを向上させることも考えられますが、これにも課題があります。送信電力は規制制限 によって制限されており、レシーバー のノイズ性能を改善する余地はごくわずかです。したがって、より現実的な選択肢は、スペクトル効率の限界に取り組むことであり、まさにこれがBluetooth® HDTが実現していることです。

Bluetooth HDTでは、Bluetooth LEと同じチャネル帯域幅およびチャネル間隔で動作する新しいPHYが導入されています。 しかし、さらに重要なのは、このPHYがコヒーレントな高次変調方式と前方誤り訂正（FEC）を組み込み、高いスペクトル効率を実現している点です。また、Bluetooth HDTでは、適応変調およびリンク適応をサポートするための新しいパケットフォーマットとリンクレイヤー の更新が導入されており、マルチパスやフェージングに対する耐性を向上させると同時に、新しいPHYのスペクトル効率目標の達成にも寄与しています。さらに、Bluetooth HDTでは、新しいHDT機能をサポートするための新しいHCIコマンドおよびイベントを定義し、関連するセキュリティ強化も導入しています。

以下の章では、Bluetooth HDTの構成要素に基づいて、その詳細な概要を解説します。本書では、Bluetooth HDTの主要な構成要素について、アーキテクチャ、物理層（PHY）、パケット、リンクレイヤー （LL）、暗号化、ホストコントローラインターフェース（HCI）、およびスタックのISOAL層とホスト層の更新を含む「その他」の順で解説しています。

3. Bluetooth® HDTアーキテクチャ

Bluetooth HDTの技術的な側面について詳しく説明する前に、HDTがBluetooth技術にもたらすメリットや価値について、大まかな概要を把握しておくと役立ちます。

• サポートされる最大ビットレートを7.5 Mbpsに引き上げます
• 単なるスループットの向上にとどまらず、ワイヤレス性能を大幅に向上させます
• これにより、既存のBluetoothアプリケーションやユースケースをサポートするために利用可能な容量と機能が拡張されます
• これにより、高解像度オーディオやロスレスオーディオといった、より充実した新しいユースケースが可能になります

これらの利点は、Bluetoothコア仕様に導入されたアーキテクチャ上の革新と機能強化によって実現されています。このセクションでは、Bluetooth HDTの主要なアーキテクチャ原則の概要を説明します。

3.1 概要

Bluetooth HDTの背後にある本質的なアーキテクチャ上の目標は、Bluetooth LEとの下位互換性を維持しつつスループットを大幅に向上させ、より高いビットレートを効率的かつ確実にサポートするために必要な性能（例えば、感度の向上、干渉に対する耐性の向上、マルチパスやフェージング条件に対する堅牢性など）を実現し、かつ、従来のBluetoothシステムと比較して実装の複雑さを管理可能なレベルに抑えながら、これらの目標を達成することである。

Bluetooth HDTによって導入された革新や機能強化を視覚化する簡単な方法は、それらをBluetooth LEスタックの構造に照らし合わせて確認することです。これを説明するために、図3.1には、HDTを実現するために更新されたレイヤーが星印で示された、Bluetooth LEスタックの簡略図を示しています。

図3.1 – HDT向けのBluetooth LEスタックの更新

一段階下へ降りて中程度の視点に立ってみると、HDTを実現またはサポートするために各スタック層で施された主な革新と機能強化は、次のように要約できます。

物理層（PHY）

• 高次コヒーレント変調方式とパンクチャリング付き前方誤り訂正に基づく、GFSK以外の新しいPHY
• 最大7.5 Mbpsまでの5種類のビットレートをサポート

リンクレイヤー (LL)

• 新しいパケット構造
• 3つの新しいパケット形式のバリエーション
• HDT構成情報の交換に関する新しい手順
• PHYアップデートおよびCIS作成に関する情報交換の手順の更新
• HDT暗号化とMICサイズの拡大

ホスト・コントローラ・インターフェース（HCI）

• パラメータの設定、ペイロードの読み取り、テストの有効化などを行うための新しいコマンド
• HDTレートや暗号化機能の有効化などに関する新たなイベントが報告されました

また、アイソクロナス・アダプテーション・レイヤー（ISOAL）およびBluetooth LEスタックのホスト層にも、小規模な更新が施されています。ホスト層の更新は主に、MICの長さに関する要件の検証と適用をサポートするものであり、一方、ISOALの更新は、新しいPHYによって可能になった、より大きなデータペイロードの転送をサポートするものです。

技術的な解像度が高い、最終的な低レベルな視点については、本論文の以下の各節で取り上げる。具体的には、第4節で物理層、第5節でパケット、第6節でリンクレイヤー 、第7節で暗号化、第8節でHCI、そして第9節でその他（ISOALやホスト層など）について解説する。

3.2 アーキテクチャの原則

Bluetooth高データスループット （HDT）は、Bluetooth LEの拡張機能であり、独立した技術や並行する技術ではありません。Bluetooth LEで使用されているアーキテクチャの枠組み（例：同じ物理チャネル、論理トランスポート、論理リンクなど）を維持しつつ、新たな機能を導入しています。

HDTは、2.4 GHz ISM帯で動作し、同じチャネル分割方式を採用する既存のGFSKベースのBluetooth LEデバイスと下位互換性があります。 具体的には、接続は常にGFSK PHYを使用して確立され、その後、デバイスは任意でHDT PHYに切り替えることができます。HDTは、LE接続内でGFSK PHYとHDT PHYの間を動的に移行できるように設計されており、これにより、HDT対応デバイスはレガシーなBluetooth LE動作と共存し、必要に応じてレガシーモードにフォールバックすることが可能です。なお、HDTの初期バージョンでは、いかなる形式のアドバタイズもサポートされていない点に留意する必要があります。

HDTは、帯域幅（BW）や信号対雑音比（SNR）を向上させるのではなく、スペクトル効率を高めることで、より高いスループットを実現します。これは、高次コヒーレント変調方式に基づき、前方誤り訂正およびパンクチャリングを組み合わせた新しいPHYの導入によって実現されています。

HDTは、高いデータレートを効率的にサポートする新しいパケット構造を導入し、さまざまな運用シナリオにおいてオーバーヘッド、堅牢性、効率性のバランスをとるのに役立つ複数のパケットフォーマットを定義しています。特に、あるパケットフォーマット（PF1）では、単一のHDTパケットが、異なるアプリケーションや論理リンクからの複数のペイロードを伝送し、ペイロードデータをブロックに分割することが可能です。この柔軟性により、集約、無線リソースの効率的な利用、再送信の最適化が可能となり、本論文の後半で論じるその他の利点ももたらされます。

HDTは、高データレートでの信頼性の高いパケット解釈、適応変調、およびパケットごとの動的なレート適応を実現するように設計されています。このPHYは、常に最も堅牢な方式で変調を行うとともに、パケット構造において制御情報をペイロードデータとは別に管理・処理することで、通信経路の状態が悪い場合でも、パケットの制御情報がデコードされる確率を最大化します。

干渉、マルチパス、フェージングに対する耐性を向上させるため、HDTではパケット構造内にPHYを意識したメカニズムが組み込まれています。HDT PHYを使用して送信されるパケットは、PHYインターバルに分割されることがあり、各インターバルは、受信時のチャネルトラッキングや位相補正を支援するために有用な既知のシーケンスによって区切られています。このアプローチにより、パケットの途中でのレシーバー 再同期が可能となり、適応変調や動的レート選択をサポートしつつ、高データレートにおける信頼性を向上させます。

明確にするために述べると、データをブロックとPHYインターバルに分割する処理は互いに独立しています。主な違いは、ブロックが論理的なペイロード分割の仕組みであるのに対し、PHYインターバルはPHYレベルの伝送分割の仕組みであるという点です。PF1では、暗号化されている場合はそのMICを含め、各ペイロードをブロックに分割することができ、各ブロックは独自のCRCによって保護されます。 こうして形成されたペイロードゾーンは、PHY層において「PHYインターバル」と呼ばれる固定長のシンボルストリームに分割されます。各PHYインターバルの後には、終端シンボルシーケンスが続き、最後のインターバルを除いて、PHYインターバル・トレーニング・シーケンス（PITS）が続きます。したがって、ブロックの境界とPHYインターバルの境界は異なる目的を果たしており、同じ分割を表すものではありません。 ブロックはペイロードの構成、エラー検出、および選択的再送信をサポートするのに対し、PHYインターバルは、管理可能な復号間隔と定期的なレシーバー 再トレーニングを通じて、堅牢な無線伝送をサポートします。

また、HDTでは、物理リンクを一意に識別するための物理チャネルアドレス（PCA）メカニズムが導入されています。この機能強化により、GFSK PHYにおけるアクセスアドレスの役割を維持しつつ、広大なアドレス空間を提供することで、デバイス密度の高い環境においてメリットがもたらされます。物理チャネル識別メカニズムを分離することで、RF環境が混雑している場合でも、HDTパケットを効率的にフィルタリングし、アクティブな接続に正しく関連付けることが可能になります。1つの物理チャネルには複数のPCAを割り当てることができ、それぞれが異なるPHYで使用されます。

最後に、Bluetooth LEのセキュリティモデルを変更することなく、セキュリティ上の配慮がHDTに組み込まれています。HDTでは、リンクレイヤー において、より長いメッセージ整合性チェック（MIC）サイズのサポートが導入され、長いペイロードに対するデータ認証が強化されています。また、Bluetooth LEにおける暗号化鍵の確立と管理のための新しいフレームワークを導入する、暗号化鍵スケジュール（EKS）機能 もサポートしています。 EKSは、暗号化された接続を保護するために必要なセッションキーやその他の暗号値を生成し、アクティブな接続中に暗号化キーの更新を可能にします。HDTにおいて、EKSは、GFSKとHDTのPHY間を移行する際、接続を切断したり暗号化を再起動したりすることなく、暗号化キーとMICサイズの変更を円滑に調整することを可能にします。

明らかに、HDTを実現するための新しいPHYの導入は、HDTの実装には新しいハードウェア、ひいては新しい無線モジュールが必要になることを意味します。Bluetooth HDTはGFSKベースのBluetoothデバイスとの下位互換性がありますが、GFSKのみに対応するデバイスは、新しい、より高いスループットレベルをサポートすることはできません。

4. Bluetooth® HDT 物理層 (PHY)

Bluetooth HDT物理層（PHY）は、より高いスループットを実現するための無線レベルのメカニズムを定義しています。これは、必須のLE 1M PHY、およびGFSK変調に基づくオプションのLE 2M 、LE 2M 2BT、LE Coded PHYと共存する、オプションのBluetooth LE PHYとして規定されています。HDT PHYは2.4 GHz ISM帯で動作し、GFSKベースのPHYと同じチャネル帯域幅およびチャネル間隔を使用します。

このセクションでは、HDT PHYの3つの基本的な分野、すなわち変調とビットレート、ビットストリーム処理、および同期と堅牢性について詳しく解説します。

4.1 変調方式とビットレート

変調とは、通信のために情報を物理的な搬送波信号にマッピングするプロセスである。Bluetooth LEのPHYでは、このマッピングは従来、ガウス周波数シフトキーイング（GFSK）を用いて行われてきた。GFSKでは、RF搬送波信号の周波数をわずかにシフトさせることで情報が伝達され、送信される各シンボルに1ビットのデータが符号化される。

Bluetooth HDT PHYでは、データを複素数値のシンボルとして表現し、1シンボルあたり複数のビットを符号化する3つのコヒーレント変調方式が採用されています：

• π/4 直交位相変調（π/4 QPSK）
• 8相位変調（8PSK）
• 16 直交振幅変調（16QAM）

これらの変調方式は、RF搬送波の位相の変化、あるいは16QAMの場合は搬送波の位相と振幅の両方の変化を通じて情報を伝達します。通信中、送信されるシンボルは、同相（I）および直交（Q）と呼ばれる2つの信号成分で構成され、設計上、各I/Q信号ペアは特定のシンボル値を表します。 特定の変調方式において、すべての可能なI/Q信号ペアを複素平面上の点としてプロットしたものを、コンステレーション図と呼ぶ。図4.1は、π/4 QPSK、8PSK、および16QAMのコンステレーション図を示している。

図4.1 – HDT変調方式のコンステレーション図

コヒーレント変調とは、通信システムの送信側と受信側の間で周波数および／または位相のロックが成立することを意味し、これは同期の確保や誤り確率の低減に有効である。非コヒーレント方式では、このようなロックは成立しないため、システムはより単純になるが、同等の条件下では一般的にコヒーレント変調よりも誤りが発生しやすくなる。HDTはコヒーレント変調を採用している。

HDT PHYは、新しい変調方式と、畳み込み前方誤り訂正（FEC）およびパンクチャリングを組み合わせています。FECは、コーディング率½の畳み込み符号化に基づいて実装されており、パンクチャリングはより高いコーディング率を実現するために使用されます。 全体として、HDTは5種類のビットレートをサポートしており、いずれも2 Msym/sの固定シンボルレートで動作する。アーキテクチャ上、これらの異なるビットレートは単一のPHYのモードとして扱われる。表4.1に、各ビットレートの関連特性の概要を示す。

表4.1 – HDT率

HDTレート	PHYビットレート	変調方式	1シンボルあたりのビット数	コントローラの実装
HDT2	2 Mbps	π/4 QPSK	2	必須
HDT3	3 Mbps	π/4 QPSK	2	必須
HDT4	4 Mbps	8PSK	3	必須
HDT6	6 Mbps	16QAM	4	オプション
HDT7.5	7.5 Mbps	16QAM	4	オプション

HDT4までのレートは必須であり、HDT4を超えるレートはオプションです。HDT6がサポートされている場合、HDT7.5はオプションとなります。HDT7.5がサポートされている場合、HDT6も必須となります。各レートについて、受信（Rx）がサポートされている場合は送信（Tx）はオプションとなり、Txがサポートされている場合はRxが必須となります。

記号座標表や実装要件など、詳細については、『Bluetooth Core Specification 7.0』の関連セクションを参照してください。

4.2 ビットストリームの処理

デジタルデータをシンボルに変換し、無線通信リンクを介して送受信するには、「ビットストリーム処理パイプライン」と呼ばれる、よく構造化された処理モデルを通じて、当該データの流れを管理する必要があります。

Bluetooth HDTのPHY仕様では、図4.2のブロック図に示すように、HDTトラフィック向けの決定論的なビットストリーム処理パイプラインが定義されている。これは、GFSKベースのLE PHYに見られるパイプラインを拡張したもので、インターバル間隔とパンクチャリングが追加されている。選択されたPHYレートにかかわらず、すべての処理段階は常に同じ順序で実行される。

送信側では、生データビットは、暗号化（有効になっている場合）、巡回冗長検査（CRC）の生成、データホワイトニング、インターバル間隔調整、前方誤り訂正（FEC）符号化、およびパンクチャリングの処理を順次経ます。 その結果得られたビット列は、その後、無線で送信されるシンボルを表す変調済みI/Q信号に変換される。なお、インターバル・スペーシングは、HDTパケットフォーマット1（PF1）が使用される場合（ペイロード・ビットストリームを分割し、複数のPHYインターバルをサポートするため）にのみ適用される点に留意すべきである。パケット構造およびフォーマットの完全な定義については、第5節で詳述する。

受信側では、受信したシンボルは、送信されたデータビットを抽出するために、対応する逆処理段階を経ます（パンクチャリングを除く）。

図4.2 – HDTビットストリーム処理パイプライン

パイプラインのすべての段階は、HDTビットストリーム処理において共通していますが、PHYでは、制御情報とペイロードデータに対して異なる処理ルールを適用します。制御情報が別個に扱われるのは、新しいHDTパケット構造において、ペイロードを伝送するセクションとは分離された「制御ヘッダー」が定義されているためです。このパケット構造における分離は、後述するように、重要なPHYレベルの性能目標をサポートするためのアーキテクチャ上の決定によるものです。

レシーバー は、パケット内の後続する高スループットペイロードを抽出するためには、制御ヘッダーを正しく復号する必要があります。 通信チャネルの状態が悪い場合でも、制御情報の復号成功確率を最大化するため、制御情報は常にHDTで利用可能な最も堅牢な変調方式であるπ/4 QPSKで変調されます。そのため、制御データのビットストリーム処理では、ホワイトニングを省略し、パンクチャリングを行わないFECに対して½の符号化率を使用することで、独自のシンボルストリームを形成します。これにより、高いデータレートにおけるパケットの解釈信頼性が向上します。

制御情報をペイロードとは別に事前に処理することで、パケット単位での動的なデータレート適応も可能になります。具体的には、パケットの制御ヘッダーには、その後に続くペイロードを運ぶセクションに関する、パケット形式、選択されたデータレート、PHYインターバルの設定などの詳細情報が含まれています。 制御情報を事前に受信・復号することで、レシーバー を適切な復調および復号設定に構成してペイロードを処理できるようになり、さらに重要な点として、必要に応じてパケットごとにそれらの設定を変更することが可能になります。また、フェージングや時間変動チャネルにおけるリンクの堅牢性を向上させるために、送信されるペイロードデータが複数のPHYインターバルに分割される場合、レシーバー がパケット途中のレシーバー 再同期に対応できるよう準備することも可能になります。

参考までに、表4.2には、ビットストリーム処理パイプラインの各段階における役割と、理解しておくべき関連事項の概要がまとめられています。

表4.2 – HDTビットストリーム・パイプラインの各ステージの概要

ビットストリーム段階	概要
暗号化	• さらなる処理の前に暗号変換を適用することで、データの機密性を確保します • 暗号化が有効な場合、ペイロードに適用されます（例：HDTパケットのPDUヘッダーおよびペイロードゾーン） •第7節で詳述されているHDT暗号化フレームワークに準拠しています • パイプラインの早い段階で実行され、後続のエラー検出および訂正段階との互換性を維持しつつ、セキュリティの適用範囲を最大化します
CRC	• ペイロードブロック単位で計算されます（暗号化が適用されている場合は、暗号化後のデータ）。 • ランダムエラーとバーストエラーの両方に対するエラー検出機能を提供します
ホワイトニング	• ビットパターンをランダム化し、同一のビットが連続する長いシーケンスを分割することで、信頼性の高いクロック回復のためにストリーム内に十分な遷移を確保します • ペイロード（例：HDTパケット内のPDUヘッダーおよびペイロードゾーン）にのみ適用されます。コントロールヘッダーの直後の最初のPDUヘッダービットから始まり、パケット内のペイロードゾーンの最後のデータビットで終了します
間隔	• HDTパケットフォーマット1に固有の機能 • ペイロードゾーンを固定長の伝送区間に分割可能 • チャネル推定の更新のために、PHYインターバルトレーニングシーケンス（PITS）を定期的に挿入可能
FEC符号化	• 送信されるすべてのデータ（例：HDTパケット内の制御ヘッダー、PDUヘッダー、ペイロードゾーン）に適用される • 基本コーディング率を½とする、非系統的かつ非再帰的な畳み込み符号化を使用する（制約長K=6） • ランダムエラーおよび短バーストエラーの両方に対して誤り訂正機能を提供する
穿刺	• FEC符号化されたビットストリームから特定のビットを選択的に除去する • 単一の基数1/2の畳み込み符号化器と組み合わせたさまざまなパンクチャリングパターンにより、チャネル状況に応じて適応的に変更可能な複数のデータレートが生成される • HDTのパンクチャリングパターンは、各ターゲットデータレートにおけるフリーディスタンスを最大化する。フリーディスタンスとは、ノイズに対する符号レートの堅牢性を測定する指標である（パラメータ ） • PF1はペイロードゾーンにパンクチャリングを行うが、PDUヘッダーには行わない。PF0は両方にパンクチャリングを行う

参考までに、各HDTデータレートにおけるパンクチャリング関連パラメータの概要を表4.3に示す。なお、HDT3とHDT6はパンクチャリングパターンとコードレートが同じであるが、使用する変調方式は異なる。

表4.3 – HDT穿孔パラメータの概要

HDTレート	穿孔パターン（1＝残す、0＝省略）	穿孔効率（Ep）	有効コードレート
HDT2	[1 1]	1.0 (2/2)	1/2
HDT3	[1 1 0 1 0 1]	0.667 (4/6)	3/4
HDT4	[1 1 0 1]	0.75（3/4）	2/3
HDT6	[1 1 0 1 0 1]	0.667 (4/6)	3/4
HDT7.5	[1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 1 0 1 0 0 1 0 1 0 1 1 0 0 1]	0.933 (28/30)	15/16

4.3 同期と堅牢性

HDTで使用される高次コヒーレント変調方式は、GFSKと比較して、位相ノイズや周波数ノイズ、ドリフト、およびチャネル変動に対して本質的に敏感である。そのため、HDT PHYでは、高データレートにおける正確な同期と堅牢な復号をサポートするために設計されたいくつかのメカニズムが導入されており、これにより、望まれるスペクトル効率の向上を実現するとともに、チャネルの劣化、フェージング、マルチパス歪みといった厳しい無線環境においても、信頼性の高い性能を発揮する。

表4.4は、トレーニングシーケンス（短・長）、ガードインターバル、終了シンボル、PHYインターバル、およびPHYインターバル・トレーニングシーケンス（PITS）といった各メカニズムの役割と、それらを理解するために知っておくべき関連事項について、概要を示しています。

表4.4 – HDTの学習および同期メカニズムの概要

メカニズム	概要
ショート・トレーニング・シーケンス（STS）	• 初期パケットの迅速な検出、大まかなタイミング調整、およびAGCの安定化を可能にする • すべてのHDTパケットの冒頭であるプリアンブルに現れ、連続して複数回繰り返される • パケットへの信頼性の高いエントリポイントを確立する
ロング・トレーニング・シーケンス（LTS）	• 精密なタイミング調整、周波数オフセットの推定・補正、および初期チャネル推定を可能にする • HDTパケットのプリアンブル内でも、STSの後に現れ、連続して数回繰り返される • コヒーレント復調のためのレシーバー を準備する
ガード間隔（GI）	• トレーニングシーケンス、シンボルストリーム、および変調または符号化の境界間の切り替えによる過渡現象を吸収するための時間バッファ • プリアンブル内、STSとLTSの間には明示的に、またパケット全体では終端シンボルを通じて暗黙的に現れる •レシーバー フィルタおよびタイミングループが、LTSの精密な同期が行われる前に安定化するよう確保し、シンボルストリーム間のスムーズな遷移を保証する
終了記号	• シンボルストリーム間に明確な境界を設け、シンボルストリームの遷移に伴う過渡的な影響を吸収する • パケット内の各独立して処理されるシンボルストリームの末尾に配置する（例：制御ヘッダーの後、PDUヘッダーゾーンの後、パケットフォーマット1における各PHYインターバルの後など） • FECデコーダが状態 をフラッシュし、次のセグメント／ストリームが始まる前にリセットできるようにする • パケットフォーマット1においては、独立して処理されるシンボルストリーム間のエラー伝播を抑制するために特に重要である
PHYインターバル	• 長いペイロードを、より小さく、デコードしやすい単位に分割できるようにする • パケットフォーマット 1 (PF1) HDT パケットのペイロードゾーンにのみ出現する • 長い PF1 ペイロード内の各区間間で、定期的なチャネル追跡および再トレーニングを有効にする
PHYインターバルトレーニング・シーケンス（PITS）	• パケットの途中での再学習を有効にし、複数のPHYインターバルに分割されたペイロードを堅牢に受信するために、位相およびチャネル推定を更新する • パケットフォーマット1（PF1）のHDTパケットのペイロードゾーンにのみ出現する

HDT PHYにおける同期および堅牢性の要素が相まって、信頼性の高い高スループット動作を可能にする階層的なフレームワークを構成しています。まず、STSおよびLTSを用いた堅牢なプリアンブルベースのトレーニングを通じて、初期捕捉が行われます。その後、ガードインターバルおよび終端シンボルを活用することで、明確な遷移と明示的な復号境界が確立され、維持されます。 最後に、PHYインターバルおよびそれに関連するトレーニングシーケンスを通じて、パケット途中の再同期が可能となり、より長いパケットやより高いデータレートで動作する際の、変化するチャネル状況に適応します。この構造化されたアプローチにより、フェージング、位相ドリフト、マルチパス効果に対する耐性が確保され、HDTは堅牢性と効率性を兼ね備えながら、大幅なスループットの向上を実現します。

5. Bluetooth® HDT パケット

Bluetooth® HDT は、前節で導入された PHY レベルの機能と、後述の第 6 節で説明するリンクレイヤー のインテリジェンスおよび手順とを結びつける新しいパケット構造を定義しており、これにより、実用的かつ確実に、より高いスループットと堅牢なパフォーマンスを実現します。

このセクションでは、HDTパケットの構造とパケット形式について解説し、それぞれのゾーン、部分、および／またはフィールドについて概要を説明します。

5.1 HDTパケット構造の概要

図5.1に示すように、HDTパケットの構造は、プリアンブル、制御ヘッダー、PDUヘッダーゾーン、およびペイロードゾーンの4つのゾーンで構成されています。プリアンブルと制御ヘッダーは必須であり、すべてのHDTパケット形式に必ず含まれていなければなりません。PDUヘッダーゾーンおよびペイロードゾーンの有無は、選択されたパケット形式によって異なります。

図5.1 – HDTパケットの構造

HDTパケット構造の階層構造は、PDUヘッダーおよびペイロードゾーンが4層の詳細情報を格納するように設計されています。通信の明確化のため、パケットの最上位層に関連するフィールドは「ゾーン」、その一つ下の層に関連するフィールドは「ポーション」、そして最下位2層のフィールドは単に「フィールド」と呼ばれます。 例えば、HDTパケット構造のPDUヘッダーゾーンには、LL記述子フィールドが指定されたTXポーションが含まれており、そこには各ペイロードのリンクレイヤー （ ）IDを持つLLIDフィールドが含まれている、状態 。この命名法を採用する利点は、このセクションの後半で明らかになるだろう。

大まかに言えば、HDTパケット構造における各ゾーンの役割と構成は、次のように要約できます。

前文

• レシーバー が受信パケットの開始位置を特定し、トランスミッター と同期して、タイミング、周波数、または位相のずれを補正するとともに、無線チャネルによって生じる振幅および位相の歪みを低減するためのチャネル推定を実行できるようにします。
• 短いトレーニングシーケンス（STS）を9回繰り返し、その後ガードインターバル（GI）を挟み、さらに長いトレーニングシーケンス（LTS）を2回繰り返す構成となっている

制御ヘッダー

• これにより、レシーバー は、着信パケットを正しい物理リンクに関連付け、重要な制御情報を確実に復号化（専用のヘッダー誤り検出機能を使用）し、ペイロードの復調や処理が行われる前にこれらを実行できるようになります。
• HDTパケットアドレス（HPA-A）、パケット形式、レート選択など、制御に関する詳細情報を伝える7つのフィールドで構成されています。

PDUヘッダーゾーン

• レシーバー が、ペイロードゾーンに続くペイロードデータを解釈および管理するために必要なプロトコルレベルのメタデータを伝送します。これには、パケットタイプ（例：トランスポート、リンクIDなど）やペイロードの長さなどが含まれます。
• 「Initial」、「RX」、「TX」、「Extended Header」、「Header Error Correct (HEC-P)」の5つの部分で構成されています。

ペイロードゾーン

• 送信されたペイロードブロック（暗号化されている場合はメッセージ整合性チェックを含む）およびCRCを、使用されるパケット形式に従って整理して格納する
• 資料の各セクションで取り上げられている詳細

5.2 HDTパケットのフォーマット

さまざまな通信シナリオにおいて効率性と柔軟性を実現するため、HDTでは、「ショート」、「パケットフォーマット0（PF0）」、および「パケットフォーマット1（PF1）」の3つのパケットフォーマットを定義しています。

ショートフォーマット

ショートパケット形式は、送信するデータがない場合に最適な、オーバーヘッドを最小限に抑えた構造である。これにより、空中伝送時間の使用を削減でき（例えば、長さは常に正確に69マイクロ秒である）、デバイス間の同期や確認応答の交換に有用である。構造的には、図5.2に示すように、ショート形式はプリアンブルと制御ヘッダーのみで構成されている。

図5.2 – HDTパケット（ショートフォーマット）

パケットフォーマット 0 (PF0)

パケットフォーマット0（PF0）は、セグメント化されていないペイロードを単一のブロックで送信するのに最適な、複雑度の低い構造です。構造的には、PF0はプリアンブル、制御ヘッダー、PDUヘッダーゾーン、およびペイロードゾーン（ペイロードが空の場合は省略可能）で構成されています。

ペイロードゾーン内の単一のブロックには、暗号化されている場合、MICが含まれます。また、ペイロードゾーンには、PDUヘッダー全体、ペイロードブロック、およびMICの合計に基づいて計算される、エラー検出用のCRCも含まれます。図5.3は、PF0の構造を示しています。

図5.3 – HDTパケットフォーマット0（PF0）

パケットフォーマット 1 (PF1)

パケットフォーマット1（PF1）は、大量のデータを効率的かつ確実に伝送するのに最適な、最も高性能で堅牢な構造です。構造的には、PF1はプリアンブル、制御ヘッダー、PDUヘッダーゾーン、およびペイロードゾーンで構成されています。

PF1では、ペイロードゾーン内に最大4つの異なるペイロード（例えば、送信待ちの次の4つのペイロード）を集約することができ、暗号化が有効になっている場合は、それぞれにMICが割り当てられます。各ペイロードはブロック（1～16）に分割可能であり、各ブロックごとにCRCが計算されます。最後のブロックを除くすべてのブロックは同じサイズですが、ペイロードごとにサイズが異なる場合があります。図5.4は、PF1の構造を示しています。下付き文字M、N、Pは、それぞれペイロード0、1、2のブロック数を表しています。

図5.4 – HDTパケットフォーマット1（PF1）

ブロックとは、HDTパケットのペイロードゾーンにおける、新しいペイロード送信および検証単位です。HDTでは、ペイロードを単一の塊として扱うのではなく、一連のブロックとして処理します。各ブロックは独自のCRCによって保護されており、これによりレシーバー がブロックを個別に検証できるようになっています。 この概念の根本的な利点は、より大きなペイロードやパケットを送信する際に、選択的確認応答と再送信を可能にし、より高いスループットを実現できることです。パケットの一部が正常に受信された時点でその部分に対して確認応答を行うことができ、干渉によってペイロードの一部が破損した場合でも、HDT PHYは欠落または破損したブロックのみを再送信すればよく、正常に受信されたブロックは保持されます。

ブロック単位の粒度により、多重化と持続的なスループットがサポートされ、PF1が1つのパケットに最大4つのペイロードを集約する機能を補完します。特定のペイロードに対するブロックサイズは、PDUヘッダーゾーンのTX部分で指定されます。

一般的に、HDTでは、ペイロード番号とスライディング・ペイロード・ウィンドウを用いて、ペイロードの送信、確認応答、および再送信を管理します。ACLまたはCIS接続の各方向において、ペイロード・ウィンドウには、CurrentPayloadNumberから始まり、送信または再送信の対象となる1つから4つのペイロードが含まれます。ウィンドウの先頭にあるペイロードが確認応答されると、CurrentPayloadNumberがインクリメントされ、ウィンドウが前方へ移動します。 ExpectedPayloadNumberは、相手デバイスから次に受信される予定のペイロードを識別します。SNおよびNESNは、それぞれCurrentPayloadNumberおよびExpectedPayloadNumberの下位3ビットを格納しており、これによりデバイスはペイロードウィンドウの状態 を追跡することができます。 このペイロード番号付けモデルは、PF0とPF1の両方に適用されます。PF0はウィンドウ内の最初のペイロードのみを送信または再送信できますが、PF1はウィンドウ内のペイロードから選択されたブロックを送信または再送信できます。

要約すると、表5.1には3つのパケット形式の比較が示されている。

表5.1 – HDTパケット形式の概要

	ショート	PF0	PF1
最大積載量	該当なし	494オクテット	8175オクテット
こんな時に便利	同期、確認応答	スループットの向上	最高の処理能力、効率、および／または堅牢性
主な利点	送信するペイロードデータがない場合、および連続する完全なペイロードのみに対して確認応答が必要な場合、通信時間を短縮します。	• 実装が簡単 • オーバーヘッドが低い • MIC を含む単一のペイロードブロック	• 1パケットあたりのペイロードは最大4つまで • ペイロードのブロック分割 • 選択的（ブロック）確認応答 • ペイロードブロックは複数のパケットにまたがる場合がある • PHYインターバル、PITSを用いた位相追跡

それでは、パケット構造の各ゾーンについて、もう少し詳しく簡単に振り返ってみましょう

5.3 前文

図5.5は、プリアンブルの構造とタイミングを示しています。トレーニングシーケンスおよびガードインターバルの技術的な詳細については、『Bluetoothコア仕様書』第6巻、パートA、セクション7.4を参照してください。

図5.5 – HDTパケットのプリアンブル

5.4 制御ヘッダー

図5.6は、コントロールヘッダーの形式と各フィールドを示しています。

図5.6 – HDTパケットの制御ヘッダー

• HPA-A（HDTパケットアドレス – 部分）：40ビットのHPAのうち、ビット39～24。レシーバー が着信パケットをフィルタリングし、候補となる物理リンクを特定できるようにする部分アドレスを提供します。
• NESN（Next Expectedシーケンスナンバー ）：ExpectedPayloadNumber の最下位 3 ビットを含み、対等デバイスから受信したペイロードに関する累積的な確認応答情報を提供します。確認済みのペイロードがペイロードウィンドウ内を順次進むにつれて、NESN は対等デバイスから次に受信が予想されるペイロードを反映します。
• PFI（パケット形式インジケータ）： パケットに使用されるフォーマットを示します。このフィールドは動的であり、パケットごとに変化する可能性があります。
  • 0：ショートまたはフォーマット 0；1：フォーマット 1
  • 「Short」はいつでも挿入できます
  • いつでもPF0からPF1に切り替えることができます
  • 特定の状況下では、PF1からPF0への切り替えが可能です
• RI（レートインジケーター）： PDUヘッダーおよびペイロードゾーンのデータレートを指定します。このフィールドは動的であり、パケットごとに変化するため、チャネル状況に応じてPHYのレート適応を迅速に行うことができます。
  • 0b000: ショートフォーマット（データゾーンなし）
  • 0b001-0b101：2 Mbps から 7.5 Mbps までの通信速度。
• RFU（将来の使用のために予約）
• PDU制御： コンテンツはパケット形式によって異なります
  • 概要：即時リンク制御のためのMD/CIE（More Data/Close Isochronous Event）、3ビットのRFU、およびSNR（信号対雑音比）フィールドが含まれています。
  • フォーマット 0：CRCを除いた、PDUヘッダーとペイロードゾーンを合わせた総長さを指定する9b値
  • フォーマット 1：6b の PDU ヘッダーゾーン長（HEC-P 部分を除く）、PHY インターバルあたりのペイロードシンボル数を示す 2b の PHY INT [00: 128; 01: 256; 10: 384; 11: 512]、および 1 ビットの RFU ビットを含む
• HEC-C（ヘッダーエラーチェック – 制御）：先行するすべての制御ヘッダーフィールドに対して計算され、完全なHPAを用いて初期化された24ビットのCRCであり、これによりレシーバー は、該当するHPAに基づいて制御ヘッダーの妥当性を検証し、パケットを対応する物理リンクに正しく関連付けることができる。

5.5 PDUヘッダー領域

図5.7は、PDUヘッダーゾーンの形式と各部分を示しています。

図5.7 – HDTパケットのPDUヘッダーゾーンの部分

冒頭部分

「初期部分」は、PDUヘッダーゾーン全体の制御マップおよびエントリポイントとして機能する8bのフィールドである。これは、オプション部分の有無を定義し、トランスポート固有の制御情報を格納する。初期部分の解釈はトランスポートの種類によって異なり、その概要は表5.2にまとめられている。

表5.2 – 輸送種別ごとの「初期部分」フィールド

ビット	ACL	CIS	ビス
0	XHP（拡張ヘッダーあり）	XHP（拡張ヘッダーあり）	XHP（拡張ヘッダーあり）
1	RxPP（処方薬分が含まれている）	RxPP（処方薬分が含まれている）	修正済み 0（Rx部分なし）
2	MD (More Data): 継続的な送信のために接続イベントを開いたままにする	CIE（Close Isochronous Event）：サブイベントの早期完了を示す	CSTF（制御サブイベント送信フラグ）：後続のパケットにBIG制御PDUが含まれることを示す。データPDU内で設定される。
3-5	SN (シーケンスナンバー)：ペイロードウィンドウ内における送信者の現在の位置を識別する、CurrentPayloadNumberの下位3ビット	SN（データPDUのACLと同様）	CSSN（制御サブイベントシーケンスナンバー ）
6-7 (PF0)	LLID（論理リンクID）	LLID（論理リンクID）	LLID（論理リンクID）
6-7 (PF1)	TxPP（Tx部分存在）＋RFU	TxPP（Tx部分存在）＋RFU	TxPP（Tx部分存在）＋RFU

処方薬分

Rxポートは、ピアデバイスから送信されたデータが受信されたことを示すために選択的確認応答が必要な場合、ACLまたはCISパケットに含まれます。そのフォーマットとフィールドを図5.8に示します。最大4つのペイロードに対して、きめ細かなフィードバックを提供することができます。

図5.8 – PDUヘッダーゾーン、受信（Rx）部分のフォーマットとフィールド

• RxPayloadMap：このパケットで、今後予想される4つのペイロード（P+0～P+3）のうち、どのペイロードの受信確認が行われているかを示します。
• RxAck P+k（ペイロードごとに2b）： 各ペイロード k に対する確認応答の粒度を指定します。
  • 00: 受信確認なし。ペイロードも特定のブロックも受信・検証されていません。
  • 01: 完全に受信確認済み。ペイロード全体が正しく受信されました（このペイロードにはRxBitmapは続きません）。
  • 10/11: 部分的な受信確認。ペイロード内の特定の論理ブロックについては受信確認が行われるが、すべてではない。このペイロードには、1オクテットまたは2オクテットのRxBitmapが続く。
• RxBitmap (8ビットまたは16ビット)： 1が設定されているビットは、対応する論理ブロック（ペイロードのセグメンテーションで定義されるもの）が正常に受信され、検証されたことを示すビットマスクです。そのサイズは、ペイロード内のブロック数（Nb+1）によって決まります。
  • 不要なビットはすべて1に設定されるため、0xFFおよび0xFFFFのみが、完全な受信および検証完了を示すことになる
  • For 8b bitmask, the 8 most significant bits are set to 1; an 8b mask can only be used if Nb<8 or if all blocks after number 8 have already been acknowledged

Tx 部分

Txポートションは、送信された内容を記述するためにフォーマット1のパケットに含まれており、これによりレシーバー が特定のペイロードからブロックを認識・再構築できるようになります。そのフォーマットとフィールドを図5.9に示します。最大4つのペイロードについて、詳細な情報を指定することができます。

図5.9 – PDUヘッダーゾーン、送信（Tx）部分のフォーマットとフィールド

• TxPayloadMap：送信ウィンドウ内の次の 4 つのペイロード（P+0 から P+3）のうち、どのペイロードのブロックがこのパケットに含まれているかを示します
• DscType P+k（ペイロードあたり2b）： ペイロード k に対する以下の LL 記述子の形式について説明します。
  • 00: なし（このペイロードからのブロックなし）
  • 01: 2オクテットの記述子
  • 10: 5オクテット記述子
  • 11: 6オクテット記述子
• LL記述子（2、5、または6オクテット）： ブロックが存在する特定のペイロードに関するメタデータが含まれています
  • ペイロードの長さ (13b)：ペイロード全体の合計長さ（MICが存在する場合はそれを含む）
  • LLID (2b)、RFU (1b)：論理リンク識別子および予約ビット
  • 注 (4b):ブロック数 – 1; 0 = 1ブロック、15 = 16ブロック。ペイロードがいくつのブロックに分割されるかを定義します。
  • ブロックサイズ (9b)： ペイロード内の最後のブロックを除くすべてのブロックのサイズ（32～511オクテットの範囲）。最後のブロックのサイズは可変であり、32オクテットから「Blocksize+32」オクテットまでの範囲の任意の値となり得る。
    • Nb=0 の場合、単一のブロックのサイズは 0 から 510 オクテットの範囲内の任意の値となります。
  • TxBlockMap (8ビットまたは16ビット)： このパケットに含まれる特定のブロック（Nb および BlockSize で定義される）を示すビットマスク。1 は、そのブロックが存在することを示す。
    • 不要なビットは0に設定されます

拡張ヘッダー

拡張ヘッダーは、固定のオーバーヘッドを課すことなく、さまざまなオプション機能をサポートする、フラグベースのコンパクトな構造体である。その存在は、初期部分にあるXHP（Extended Header Present）ビットによって示される。フラグオクテット0を除くすべてのフィールドはオプションである。そのフォーマットとフィールドを図5.10に示す。

図5.10 – PDUヘッダーゾーン、拡張ヘッダー部分のフォーマットとフィールド

• フラグビットのエンコーディング：機能は 7×O+B 方式で指定されます。ここで、O は 0 を基点とするフラグオクテットのインデックス、B はビット位置（1～7。ビット 0 は将来の使用のために予約されています）を表します。フラグビットを 1 に設定すると、対応する機能 が存在し、そのデータオクテットが機能 データ領域に含まれていることを示します。
• 機能 データの順序： 機能 のデータオクテットは、すべてのフラグオクテットの後に、機能 のIDの厳密な数値順で連結されます。

拡張ヘッダーは、HDTにとって極めて重要な、厳選された一連の機能をサポートしており、それぞれの機能には特定の目的と厳格な実装規則が定められています。これらの機能は、論理トランスポートタイプ（ACL、CIS、BIS）に合わせて設計されており、表5.3にまとめられています。

表5.3 – 拡張ヘッダーの機能

Feat. No.	ACL	サイズ	CIS	サイズ	ビス	サイズ
1	拡張ヘッダー「機能 」のデータ長	10月1日	拡張ヘッダー「機能 」のデータ長	10月1日	拡張ヘッダー「機能 」のデータ長	10月1日
2	リンクの品質	10月2日	リンクの品質	10月2日	—	—
3	—	—	NPI	10月0日	—	—
4	流量制御	10月0日	—	—	—	—
5	NPI	10月0日	—	—	—	—

機能 データ長

• 拡張ヘッダー内の、その後のすべての機能 データオクテットの合計長を返します。
• 機能 拡張ヘッダーを含むすべてのフォーマット0パケットにおいて、これは必須です。フォーマット0パケットにはPDUヘッダーゾーンの明示的な長さフィールドがないため、この要件は極めて重要です。レシーバー は、この値に基づいてペイロードゾーンの開始位置を正しく特定します。
• このフィールドをPF1に含めることは可能ですが、PF0の場合のようにパケットをデコードする必要はありません（通常、通信時間を節約するために省略されます）。
• 後続する機能 データオクテットの総数を表す符号なし整数を格納する、1オクテットのフィールド

リンクの品質

• トランスミッター に対し、直前に受信したパケットの品質に関するフィードバックを提供することで、適応データレート（ADR）制御を可能にする
• 両方のデバイスが「リンク品質フィードバック（機能 ）」に対応している場合にのみ使用可能です。
• 次のように構成された2オクトのフィールド：
  • RSSI（ビット0～7）：受信信号強度表示
  • SNR（ビット8～12）：信号対雑音比
  • 優先レート（ビット13～15）： レシーバーが後続の送信に対して推奨するPHYデータレート（HDT2～HDT7.5）を表す3bコード。値が0の場合は、特定の推奨がないことを示す。

流量制御

• 状態 の2つの値：STOPとGO
• ACL接続に対して、パケット単位の即時フロー制御を提供します
• この機能 を含むパケットを受信すると、レシーバーのリンクレイヤー は、対応する方向のローカルフロー制御状態 を STOP に設定しなければなりません。
• 「状態 」を停止する　その影響： STOP状態 にいる間、トランスミッター が送信できるのは以下のものに限られます：
  • 少なくとも1つのブロックについてすでに受信確認が行われているペイロードのブロック（すなわち、再送信）
  • 制御用PDU（LLID = 0b11 で識別されるもの）
• GOへの復帰：フロー制御状態 は、Stop機能 を含まない有効なパケットを次に受信すると、GOに戻ります。これは、STOPの状態を維持したい場合、ショートフォーマットのパケットを送信できないことを意味します。状態

Null PDU インジケータ (NPI)

• Null PDU（データを含む意図のないプロトコルプレースホルダー）と、Empty PDU（ペイロードの長さがゼロである有効なデータPDU）を明確に区別する。
• この機能 は、ペイロードゾーンが空（長さ = 0）であるフォーマット0のパケットでのみ有効です。
• 意味論：
  • NPI = 1:この PDU はヌル PDU です。これはプレースホルダー（タイミングや確認応答などの目的）として機能し、有効な PayloadNumber とは関連付けられていません。データシーケンスを前進させることはありません。
  • NPI = 0 または機能 が存在しない場合：この PDU は有効な PayloadNumber に関連付けられています。ペイロードにデータオクテットが含まれている場合もあれば、空の PDU である場合もあります。

HEC-P

HEC-P（ヘッダー誤り検査 – PDUヘッダー）は、PDUヘッダーゾーン全体（それ自体を除く）を対象とする24ビットのCRCです。これはPF1にのみ存在し（PF0では省略されます）、HPAによって初期化されます。

5.6 ペイロードゾーン

ペイロードゾーンの構造は、データの構成、送信、および保護の方法を定義する、選択されたパケットフォーマットによって決定されます。表5.4では、パケットフォーマット0とフォーマット1におけるペイロードゾーンの主な相違点を比較・要約しています。

表5.4 – PF0とPF1のペイロードゾーンの比較

	PF0	PF1
ペイロードデータ	単一の連続したブロックに格納され、伝送される	最大4つのペイロードを集約し、セグメント化して、複数のブロックのシーケンスとして送信される
1パケットあたりの最大ペイロード	1	1～4（TxPayloadMap によって特定されたもの）
積載容量（サイズ）	0～494オクテット + マイク（ある場合）	0～8175オクテット＋MIC（存在する場合）
CRC保護	PDUヘッダー領域とペイロード領域を合わせた範囲をカバーする32bの単一CRC	ブロックごとに32bのCRC。各ブロックの直後に、そのブロック固有のCRCが続く。
重要な考慮事項	シンプルさ。一般的なPDUモデルに似ている	パケット長の延長によりスループットが向上し、選択的ブロック確認応答および再送信が可能
PHYインターバルのサポート	いいえ	はい

PF1では、通信中の堅牢性を高めるため、PHY層におけるインターバルへの分割、および終端処理とPITSが必須となります（ただし、ペイロードゾーンが1インターバルより短い場合は除く）。

リンクレイヤー 層では、選択的確認応答および再送信を可能にするため、ペイロードはブロックに分割されます。これらのブロックは、リンクレイヤー によってブロックマップ／ビットマップを介して追跡および参照されます。PHY層では、ビットストリーム処理パイプライン内のインターバル間隔設定段階を通じて、ペイロードゾーンが「PHYインターバル」と呼ばれる固定長のシンボルストリームにさらに分割されます。

PHYインターバルは、所定数のペイロードを伝送するシンボルで構成され、その後に終了シンボルシーケンスおよびPHYインターバル・トレーニング・シーケンス（PITS）が続きます（ただし、最後のインターバルを除く）。PITSは既知のトレーニングパターンを提供し、これによりレシーバー はパケットの途中でタイミングおよび搬送波周波数／位相の基準値を更新し、PF1によって伝送されるより長い集約ペイロードに対するチャネル劣化の影響を管理・軽減することで、スループットを最大化することができます。

PHYインターバルのサイズ設定は、表5.5に示すように、コントロールヘッダー内のPHY INTフィールドによって行われます。

表5.5 – PHYインターバルごとのシンボル数

PHY INT	区間ごとの記号数
0b00	128
0b01	256
0b10	384
0b11	512

このPHYインターバル用のビットストリームには、必要なFEC終端ビットおよび（必要な場合の）ゼロパディングも含まれています。変調後、PHYインターバルあたりの実際のシンボル数は、データレートによって若干変動する場合があります。詳細は表5.6を参照してください。

また、PHYレートが異なると、シンボルあたりのビット数も異なる点に注意してください。したがって、PHY INT 0b00 のデータは、HDT2 では 128 ビット（16 オクテット）、HDT3 では 192 ビット（24 オクテット）、HDT4 では 256 ビット（32 オクテット）、 HDT6では384ビット（48オクテット）、HDT7.5では480ビット（60オクテット）となります。

表5.6 – データレートごとのPHYインターバルのシンボル数

PHY INT	HDT2	HDT3	HDT4	HDT6	HDT7.5
0b00	133	132	131	130	130
0b01	261	260	259	258	258
0b10	389	388	387	386	386
0b11	517	516	515	514	514

視覚化のため、図5.11ではPF1の構造を再掲し、ペイロードゾーンがPHYインターバルにさらに細分化されている様子を示しています。

図5.11 – PF1ペイロードゾーンのブロックおよびPHYインターバルへの分割

PHY層の観点から、図5.12では、3つのHDTパケット形式すべてをシンボル単位で示した別の図を示しており、これも視覚化を目的としています。

図5.12 – HDTパケット形式のPHY層からの視点

HDTパケット内のシンボルストリームの終了位置は、終了シンボルによって示されることに留意されたい。各終了シンボルセットは、先行するシンボルストリームの変調方式に従って変調された、すべてゼロビットのシンボル2つで構成される。PF0の場合、終了シンボルはコントロールヘッダーの後、およびPDUヘッダーとペイロードの結合体の後に挿入される。 PF1の場合、終端シンボルは、制御ヘッダーの後、PDUヘッダーの後、および各PHYインターバルの後に現れます。

6. Bluetooth® HDTリンクレイヤー (LL)

Bluetooth HDTでは、Bluetooth LEのリンクレイヤー の機能を拡張し、新しいPHYおよびパケット形式をサポートするとともに、HDTが目指すスループット、パフォーマンス、信頼性、およびセキュリティの向上を実現するための、新規または更新された機能、手順、および制御PDUが導入されています。

大まかに言えば、機能（features）はデバイスがサポートし得る能力を定義し、手順（procedures）は、デバイスがそれらの能力を使用または管理するために実行する必要がある連携動作を定義します。制御PDU（Control PDUs）とは、手順を実行するために必要な情報、パラメータ、および／または状態 の変更を伝達するために、デバイス間で交換される「制御PDU（リンクレイヤー ）」メッセージのことです。このように、機能は利用可能な能力を記述し、手順はデバイスがその使用をどのように連携させるかを定義し、制御PDUはその連携を実行するために使用されるメッセージを提供します。

このセクションでは、Bluetooth HDTによって実現されたリンクレイヤー の機能拡張の概要を説明し、HDTを有効化するためのリンクレイヤー の新規機能、バージョンアップされた機能、および更新された機能、手順、ならびに制御PDUについてまとめます。

6.1 HDT向けの新しいリンクレイヤー 機能の概要

HDTの開始と管理

Bluetooth® HDT は、データ物理チャネルおよび ACL トランスポートを介して行われる接続ベースの操作を通じて開始および管理されます。ただし、デバイス間で HDT 対応のリンクが確立されると、そのリンクを使用して ACL 接続や接続されたアイソクロナス・ストリーミングをサポートすることができます。

アイソクロナス放送の場合、デバイスはGFSKベースのアドバタイジングを使用して定期アドバタイズ を特定する必要があります。その後、ACL接続を必要とせずに、1つ以上のBISを含むBIGを送信または受信することができます。HDT PHYは現在、いかなる形式のアドバタイジングもサポートしていません。

全体として、HDTの動作は、定義されたリンクレイヤー プロシージャを通じて、常に明示的に開始されなければなりません。また、リンクの両方向において対称的なPHYの使用が求められます（ブロードキャストを除く）。つまり、送信および受信の双方で、状況に応じてHDT PHYを使用するか、あるいは双方でGFSK PHYを使用する必要があります。HDT PHYを使用する場合、データレートはパケットごとに個別に変更可能であり、両方向で同じレートを使用する必要はありません。

新しい HDT 構成交換手順により、デバイスは通信を行い、サポートされている HDT 機能（最大データレート、パケット形式、ペイロードサイズなど）についてネゴシエーションを行うことができます。 その後、バージョンアップされた LL_PHY_REQ [v2]、LL_PHY_RSP [v2]、および LL_PHY_UPDATE_IND [v2] 制御 PDU を使用して PHY 更新手順を実行することで、通信を HDT PHY に切り替えたり、HDT への移行や HDT からの移行を管理したりすることができます。 デバイス間の HDT 機能が互換性がない場合、サポートされていない場合、または運用上の条件により必要とされる場合、通信は GFSK PHY のまま維持されるか、GFSK PHY に戻ることができます。その際、可視性と制御を確保するため、すべての PHY状態 の変更は HCI イベントを通じてホストに報告されます。

HDT データ長管理およびスケジューリング

HDTは、リンクレイヤー がHDTおよびGFSK PHYを介した各接続ごとに、送信長とタイミングパラメータを個別に管理できるデータ長管理機能を導入しています。さらに、これらのパラメータの値の範囲制限 が更新されたことで、より大きなパケットペイロードが可能になった一方で、パケットの最大送信時間制限 も確保されています。 コントローラは、パケットの送信時間を制限内に収めるために、必要に応じて大きなペイロードを複数のブロックに分割したり、選択されたデータレートを調整したりすることができます。これにより、Bluetooth LE接続イベントや、複数のリンクおよび／またはアイソクロナスストリームの同時動作に関するタイミングおよびスケジューリング要件を確実に満たすことができます。

「データ長更新」手順により、デバイスはLLデータPDUに使用する最大送信/受信長およびタイミングパラメータを通信できます。バージョンアップされたLL_LENGTH_REQ [v2]およびLL_LENGTH_RSP [v2]制御PDUを使用してこの手順を実行することで、パラメータが適用されるPHYを指定することができます。

HDTリンクの品質

HDTは、Bluetooth LEにオプションのリンク品質フィードバック（LQF）機能をもたらし、専用のリンクレイヤー プロシージャを通じて、チャネル状態に関するリアルタイム情報の交換を可能にします。この機能が有効になっている場合、送信パケットにリンク品質メトリクスが含まれ、コントローラ間で継続的に通信されます。この情報により、無線状態の変化に応じて、送信パラメータの調整、異なるHDTデータレートの選択、あるいは状況に応じてGFSK PHYへの復帰など、リンク運用に関する動的な判断を行うことが可能になります。

デバイスは、新しい「HDT リンク品質有効化」手順と、新しい制御 PDU「LL_HDT_LQF_REPORTING_IND」を併用することで、パケットへのリンク品質情報の含め始めや含め終わりのタイミングを示すことができます。

HDTおよびアイソクロナスチャネル

HDTは、Bluetooth LEのアイソクロナス転送機能を拡張し、新しいHDT PHYを介した接続型またはブロードキャスト型のアイソクロナスストリームをサポートします。

デバイスは、HDT固有の動作パラメータ（例：HDT PHY、データレート、ペイロードウィンドウサイズ、 など）をネゴシエートし、バージョンアップされたLL_CIS_REQ [v2]およびLL_CIS_IND [v2]制御PDUを用いた「接続型アイソクロナスストリーム作成手順」により、HDT PHYを介して大容量のペイロードを確実に配信できる、時間制限付きのアイソクロナスストリームを確立できます。 特に、高スループットのコネクテッド・アイソクロナス通信は、Bluetooth LE による高品質なオーディオソリューションやアプリケーションの実現に不可欠である。

放送に関しては、リンクレイヤーのエアインターフェースプロトコルにおけるアイソクロナス放送（状態 ）が更新され、HDTデータ長管理のためのBIGパラメータ 値の範囲が拡大され、BIGInfoヘッダーフィールドが改訂され、ブロック単位のACKサポートが追加されました。これにより、同期受信機は、定期アドバタイズ およびアイソクロナス放送向けに定義された既存のタイミングおよび同期要件に従い、HDTを活用して高スループットの放送ストリームを受信できるようになります。

HDTのセキュリティと暗号化

HDTは、Bluetooth LEのセキュリティを強化し、より長いメッセージ整合性チェック（MIC）サイズのサポートと、暗号化キーの生成および更新を行うための新しい暗号化キースケジュール（EKS）機能 を導入しています。リンクレイヤー は、通信を暗号化したまま、デバイス間のパラメータ交換を調整し、HDT動作への移行を管理します。

新しい「鍵スケジュールによる暗号化開始」手順により、デバイスは、LL_ENC_ECDH_REQ および LL_ENC_ECDH_RSP 制御 PDU を通じて、暗号化関連パラメータを交換し、HDT でサポートされる新しい MIC サイズ（128b または 64b）のいずれかを接続用に選択することができます。 デバイスによってリンク暗号化用の長期鍵およびセッション鍵が計算されると、LL_START_ENC_REQ および LL_START_ENC_RSP PDU を通じて暗号化が開始されます。なお、EKS は GFSK PHY でも使用可能ですが、その場合は適用可能な MIC サイズは 32b のみとなります。

さらに、EKS（機能 ）をサポートするデバイスについては、PHY更新および暗号化リフレッシュ手順により、バージョンアップされたLL_PHY_REQ [v2]、LL_PHY_RSP [v2]、およびLL_PHY_UPDATE_IND [v2]制御PDUを使用することで、接続を切断したり暗号化を一時停止したりすることなく、PHYの変更と暗号化のキー更新 を同時に実施することが可能です。 明確にするために、MICサイズの変更は常にキー更新 を強制しますが、キー更新 はMICサイズの変更を強制しません。

本書の第7節では、HDT暗号化についてさらに詳しく解説しています。

HDTの信頼性と流量制御

HDTは、ペイロードのブロック単位の評価を行い、伝送エラーを検出して管理するためのリンクレイヤー メカニズムを実現します。Bluetooth LEの既存のシーケンス番号および確認応答メカニズムは、ペイロードの累積確認応答やパケット順序の維持のために引き続き使用されますが、HDTはこれらにブロックの選択的確認応答機能を補完します。 HDTパケット内のSN、NESN、RxPayloadMap、RxBitmap、Nb、およびBlockSizeフィールドは、LLによって、ブロックが確認応答されたかどうかを検証し、それに基づいて再送信が必要かどうかを判断するために使用されます。これにより、大規模なペイロードのうち影響を受けた部分のみを再送信することで、再送信のオーバーヘッドを最小限に抑えることができます。

また、HDTは、追加のバッファリングや処理時間が必要な場合に、受信側が新しいペイロードの送信を一時的に停止できる「即時フローオフ」メカニズムを通じて、リンクレイヤー のフロー制御を強化します。拡張パケットヘッダーに含まれる情報を用いて、レシーバー は、再送信処理を継続させつつ、新しいデータの送信を停止するよう相手側に通知することができます。レシーバー が追加のトラフィックを受け入れる準備が整うと、接続の再設定や上位層による介入を必要とせずに、通常のデータ送信を再開することができます。

6.2 HDT向けのリンクレイヤー の機能

Bluetooth LEのリンクレイヤー は、Bluetoothコア仕様の[Vol 6] Part B、セクション4.6で定義されているFeatureSet ビットマスクを使用して、コントローラがサポートする機能を識別します。HDTについては、FeatureSet において、基本的なHDT機能のサポートを示すビットに加え、より高いHDTレート、パケットフォーマット1、リンク品質フィードバック、およびHDT PHY上でのアイソクロナス動作など、オプションのHDT機能のサポートを示す追加のビットが導入されています。

以下に、HDT機能のサポートを表すために導入された、HDT関連のFeatureSet ビットを挙げます：

• 77 –高データスループット
• 78 – HDT6レートの受信
• 79 – HDT6レートの送信
• 80 – HDT7.5のレートを受け取る
• 81 – HDT7.5レートの送信
• 82 – HDT パケット形式 1
• 83 – リンクの品質に関するフィードバック
• 84 – LE HDT PHY 上のアイソクロナス・ブロードキャスター
• 85 – LE HDT PHY におけるレシーバー の同期

FeatureSet の各ビットについて、本仕様書では、コントローラが対応する機能をサポートしていることを示すために満たすべき要件を定義している。これには、該当する場合、関連するPHY機能、パケット形式、手順、および制御PDUが含まれる。

高データスループット FeatureSet ビットに関連する必須要件については、以下で説明します。オプションのHDT機能のサポートを示す残りのすべてのFeatureSet ビットについては、その完全な定義および関連するサポート要件について、『Bluetoothコア仕様書』[第6巻]パートB、セクション4.6を参照してください。

HDT（高データスループット）

高データスループット 機能をサポートするコントローラは、LE暗号化（ダイバーシファイア付き）、LEデータパケット長拡張、暗号化キースケジュール、およびチャネル選択アルゴリズム#2の各機能に加え、以下のHDT機能もサポートしていなければならない：

• LE HDT PHY（[第6巻] パートA、3.6節および4.1.2節を参照）
• HDTシンボルストリームの処理（『第6巻』A部、第7節）、ただし以下を除く：
  • PHYインターバル（『第6巻』A部、7.2節）
  • 16QAMのシンボルマッピング（[第6巻] A部、7.3.3節）
  • PITS（[第6巻] パートA、7.4.5節）
• トランスミッター RMS EVM レベル（『第6巻』A部、付録C）
• LE HDT PHY のパケット形式（[第6巻] パートB、2.7節）のうち、以下を除く：
  • パケット形式 1
  • ペイロードブロックの構造（『第6巻』B部、2.7.4節）
  • リンク品質（[第6巻] B部、2.7.2.4.1節）
• 32b CRCの生成（『第6巻』B部、3.1.2節）
• LE HDT におけるビットストリーム処理（[第 6 巻] パート B、3.4 節）、ただし以下を除く：
  • 区間間隔（『第6巻』B部、3.4.2節）
• HDT構成交換手順（[第6巻] パートB、5.1.34節）、ただし以下を除く：
  • LE HDT PHY におけるアイソクロナス・ブロードキャスター、同期受信機、およびブロードキャスト・アイソクロナス・ストリーム、グループ、PDU に関連する用途
• LL_LENGTH_REQ [v2] および LL_LENGTH_RSP [v2] PDU
• LL_HDT_CONFIG_REQ および LL_HDT_CONFIG_RSP PDU

さらに、高データスループット 機能およびConnected Isochronous Stream（CentralまたはPeripheral）機能 をサポートするコントローラは、以下もサポートする必要があります：

• LL_CIS_REQ [v2] および LL_CIS_IND [v2]

詳細については、（[第6巻] パートB、4.6.54節）を参照してください。

6.3 HDTにおけるリンクレイヤー の手順

6.3.1 新しい手順

HDT機能をサポートするため、ACLリンク向けのリンクレイヤー 制御プロトコルに以下の手順が導入されています：

• HDT構成の交換手順
• HDTリンク品質有効化の手順

以下に、これらの機能の概要と、その開始および完了に関わるPDUについて説明します。なお、これらの手順は、ACLリンクの接続状態 を入力した後にのみ実行できることに注意してください。

HDT構成の交換手順

LE HDT PHY 上の接続に関連付けられた設定値を変更します。交換される値は、LE HDT PHY 上の既存の ACL や CIS には影響を与えません。 変更された値は、その後作成されるCISおよび、GFSK PHYからLE HDT PHYに切り替わった際のACLに対して有効になります。この手順は、LL_HDT_CONFIG_REQ PDUを送信することで開始され、LL_HDT_CONFIG_RSP PDUを受信した時点で完了します。送信される各PDUは送信側のデバイスの設定のみに関連するため、双方で開始された手順間の衝突があっても問題はありません。

HDTリンク品質有効化の手順

指定されたトランスポート上で送信される各パケットにおいて、リンク品質フィードバックの送信を開始または停止するよう、リモートコントローラに要求します。この手順は、LL_HDT_LQF_REPORTING_IND PDU を送信することで開始され、LL_HDT_LQF_REPORTING_IND PDU の確認応答を受信した時点で完了します。リンク品質フィードバックは無効化する場合も、この同じ手順で行います。

6.3.2 更新された手順

HDT機能のサポートを可能にするため、ACL制御に関する以下の手順が変更されました：

• 暗号化の手順
  • 「Diversifiers」を用いた暗号化の手順（その1）
  • 暗号化：キースケジュール手順から始める（その1）
  • 「ダイバーシファイアを用いた暗号化の開始」および「キースケジュールを用いた暗号化の開始」の手順（その2）
  • 暗号化の一時停止手順
• データ長更新手順
• PHYの更新および暗号化のリフレッシュ手順
• 接続型等時性ストリームの作成手順
• フレームスペース更新 手順

以下に、更新された各手順の機能と、その手順を開始および完了するために必要なPDUの概要を示します。繰り返しになりますが、これらの手順は、ACLリンクの接続状態 にアクセスした後でのみ実行できる点にご注意ください。

暗号化の手順

データPDUの暗号化と認証を有効にし、ペイロードの機密性と完全性を保護します。 セントラルとペリフェラル双方が暗号化キースケジュール（EKS）機能 をサポートしている場合、セントラルは「暗号化開始（キースケジュール使用）」手順を開始します。そうでない場合は、「暗号化開始（ダイバーシファイア使用）」手順を開始します。接続が暗号化されると、セントラルとペリフェラル双方がEKSをサポートしている場合は、リンクレイヤー が「PHY更新および暗号化更新」手順を使用して暗号化キーを変更できます。そうでない場合は、「暗号化一時停止」手順を介して変更します。

「ダイバーシファイアによる暗号化開始」と「キースケジュールによる暗号化開始」の手順は、いずれも2つの部分で構成されています。第1の部分は両者で異なりますが、第2の部分は両者とも同じです。

「Diversifiers」を用いた暗号化の手順（その1）

暗号化を有効にするには、セントラルとペリフェラルがそれぞれ初期化ベクトル（IV）とセッションキーダイバーシファイア（SKD）の自身の部分を生成し、LL_ENC_REQおよびLL_ENC_RSP PDUを介してそれらを交換します。その後、各LLがIVとSKDの部分を結合します。ペリフェラルホストは、使用する長期鍵（LTK）を自身のLLに通知します。 暗号化は、LL_START_ENC_REQ および LL_START_ENC_RSP PDU を用いた 3 ウェイ・ハンドシェイクによって開始される。

暗号化：キースケジュール手順から始める（その1）

暗号化を有効にするには、セントラルとペリフェラルがそれぞれ公開鍵（PubKey）と乱数（Rand）を生成し、LL_ENC_ECDH_REQ および LL_ENC_ECDH_RSP PDU を通じてそれらを交換します。 GFSK PHY の場合、接続では 32b の MIC が使用されます。HDT PHY の場合、64b の MIC を使用するようにフラグが設定されていない限り、接続では 128b の MIC が使用されます。

「ダイバーシファイアによる暗号化開始」および「キースケジュールによる暗号化開始」の手順（その2）

暗号化に使用する長期鍵（LTK）の種類（例：オポチュニスティック暗号化を使用する場合はすべてゼロ）およびその出所（例：ホストからLLへ提供されるもの）を決定します。 セントラル（Central）の場合、ホストは常にLTKをリンクレイヤー に提供する。ペリフェラル（Peripheral）の場合、LTKを提供する場合もあれば提供しない場合もある。提供された場合、LLはそれを用いてセッションキーを計算する。 セッションキーの計算は、ダイバーシファイアを用いた暗号化開始については[Vol 3] Part H, Section 2.2.1に基づき、キースケジュールを用いた暗号化開始については[Vol 6] Part E, Section 4.2.1に基づいて行われる。

暗号化の一時停止手順

両方の「暗号化開始」手順をカプセル化しています。したがって、同じ更新が適用されます。

データ長更新手順

LLデータPDUの現在の最大受信（Max Rx）および送信（Tx）ペイロード長と時間の最新値を、ピアデバイスに送信するために使用されます（connMaxRxOctets、connMaxRxTime、connMaxTxOctets、およびconnMaxTxTime）。 仕様の文言を更新し、コントローラが接続に対して複数のパラメータセットをサポートしている場合、この手順ではどのセットを更新するかを指定できることを明確にしました。この手順は、セントラルまたはペリフェラルが LL_LENGTH_REQ PDU を発行することで開始されます。この要求に対しては、LL_LENGTH_RSP PDU で応答します。この応答により、要求 PDU で指定されたパラメータセットが更新されます。

PHYの更新および暗号化のリフレッシュ手順

ACL接続の送信（Tx）または受信（Rx）PHY（あるいはその両方）を変更する場合、あるいはデバイスがEKS（機能 ）をサポートしている場合に、暗号化キーおよびIVを更新する場合に使用されます。 CISに関連付けられたPHYや鍵/IVには影響しません。リクエストはLL_PHY_REQ PDUを使用して開始されます。リクエストに対する応答はLL_PHY_RSP PDUで行われます。セントラルは、常に最後のステップとしてLL_PHY_UPDATE_IND PDUを送信します。

HDTでは、PHY更新の要求または応答を行う前に、転送中またはキューに格納されているデータをどのように扱うか、暗号化キー更新 の管理方法、無効な動作などについて明確化する規則の文言が導入されています。 さらに、HDT では、暗号化キー更新 の要求を必須とする（LL_PHY_REQ/RSP の場合）または示す（LL_PHY_UPDATE_IND の場合）ための Refresh フィールド、および HDT PHY での推奨 MIC 長を示すための MIC_Length フィールドを備えた PDU の [v2] を導入しています。 なお、64bのMIC長が選択されるのは、双方がそれを要求する場合に限られることに注意してください。一方のデバイスが、相手側が要求するセキュリティレベルを低下させることはできません。

接続型等時性ストリームの作成手順

セントラルとペリフェラル間でCISを確立するために使用される。この要求は、セントラルがLL_CIS_REQ PDUを使用してのみ開始する。要求が受け入れられた場合、ペリフェラルはLL_CIS_RSP PDUを使用して応答し、拒否された場合はLL_REJECT_EXT_IND PDUと適切な理由コードを使用して応答する。 応答を受けると、セントラルはLL_CIS_IND PDUで返信してCISを作成するか、LL_REJECT_EXT_IND PDUでCISをキャンセルします。HDTでは、GFSKまたはHDT PHY上でのCIS作成要件、およびPDUバージョン、対称型PHY、EKS（機能 ）の使用に関するルールを明確に定めています。

6.4 HDT用リンクレイヤー 制御PDU

6.4.1 新しい制御用PDU

以下は、無線によるHDTサポートに関する新たに定義された手順に関連する要求、応答、または指示を伝達するために導入された、新しい制御PDU（データ物理チャネル用）です。

• (0x40) LL_ENC_ECDH_REQ
• (0x41) LL_ENC_ECDH_RSP
• (0x42) LL_HDT_CONFIG_REQ
• (0x43) LL_HDT_CONFIG_RSP
• (0x44) LL_HDT_LQF_REPORTING_IND.

以下に、CtrDataフィールドのフォーマットと、その下にある各フィールドの1行の説明を示します。

LL_ENC_ECDH_REQ

• Flags_C: Centralの暗号化フラグ [bit0: 0=128ビットMIC、1=64ビットMIC；bit1: 機会的暗号化]
• Rand_C: セントラルが提供する乱数
• KeyType_C: セントラルが使用する公開鍵の種類 [0=P-256楕円曲線を用いて導出されたもの]
• PubKey_C: CentralのECDH公開鍵 [Pubkey_C31-0 = X座標、Pubkey_C63-32 = Y座標]

LL_ENC_ECDH_RSP

• Flags_P: 周辺機器の暗号化フラグ [bit0: 0=128ビットMIC、1=64ビットMIC]
• Rand_P: 周辺機器から提供される乱数
• KeyType_P: 周辺機器が使用する公開鍵の種類 [0=P-256楕円曲線を用いて導出されたもの]
• PubKey_P: 周辺機器のECDH公開鍵 [Pubkey_C31-0 = X座標、Pubkey_C63-32 = Y座標]

LL_HDT_CONFIG_REQ および LL_HDT_CONFIG_RSP

• ACL_RX_Payload_Window_Size: ACL接続でRX方向に使用されるPayloadWindowSizeより1小さい値に設定します。デフォルト = 0
• Max_CIS_TX_Payload_Window_Size: 関連するCISでTX方向に使用される最大ペイロードウィンドウサイズより1小さい値に設定します。デフォルト値 = 0
• Max_CIS_RX_Payload_Window_Size：関連付けられたCISでRX方向に使用される最大ペイロードウィンドウサイズより1小さい値に設定します。デフォルト値 = 0
• ACL_RX_Rates：ACL接続において、コントローラがリモートコントローラから受信を許可されているレート [bit0: HDT2; bit1: HDT3; bit2: HDT4; bit3: HDT6; bit4: HDT7.5]
• Max_ACL_RX_Octets_Per_Packet: ACL 接続において、1 パケットで受信可能なデータの最大オクテット数。MIC、終端シーケンス、PITS などは含まれません。

LL_HDT_LQF_REPORTING_IND

• トランスポート：[bit0: ACL; bit1: CIS] に対して、LQF レポート機能が有効か無効かを示す論理トランスポート

6.4.2 更新された制御PDU

以下は、無線によるHDTサポートに関する更新されたリンクレイヤー 手順に関連する要求、応答、または指示を伝達するために、フィールドの変更または追加が行われた、更新済みの制御PDU（データ物理チャネル用）です。

• (0x14) LL_LENGTH_REQ
• (0x15) LL_LENGTH_RSP
• (0x16) LL_PHY_REQ
• (0x17) LL_PHY_RSP
• (0x18) LL_PHY_UPDATE_IND
• (0x1F) LL_CIS_REQ
• (0x21) LL_CIS_IND
• (0x23) LL_POWER_CONTROL_REQ。

CtrDataフィールドのフォーマット、およびその下位にある各フィールド（変更されたもの、または追加されたものを含む）の1行の説明を以下に示します。注：HDT対応のための変更の結果、これらのLL制御PDUには、[v1]または[v2]で示される複数のフォーマットが存在するようになりました。CtrDataフィールド内の各フィールドは、それが含まれるすべてのフォーマットにおいて同じ意味を持ちます。

LL_LENGTH_REQ および LL_LENGTH_RSP

• PHY_S：PDUがどのPHYパラメータセットに適用されるかを示します [0=GFSK; 1=HDT]。LL_LENGTH_RSPでは、このフィールドは無視されます。

LL_PHY_REQ および LL_PHY_RSP

• TX_PHYS:トランスミッター 送信側は、[bit0: LE_1M; bit1: LE_2M; bit2:LE Coded; bit4: HDT] の使用を優先する
• RX_PHYS:レシーバー 送信側は、[bit0: LE_1M; bit1: LE_2M; bit2:LE Coded; bit4: HDT] の使用を優先します。
• 更新：キー更新 [1=必須]；指定されていない場合は値=0、接続が暗号化されていない場合や、いずれかのデバイスがEKSに対応していない場合は無視されます。機能
• MIC_Length: [1=HDT用の64ビットMICを要求、0または指定なし=HDT用の128ビットMIC]; 接続が暗号化されていない場合、鍵が更新されていない場合、またはGFSK PHYに変更された場合は無視される

LL_PHY_UPDATE_IND

• PHY_C_TO_P: セントラルから送信されるパケット用のPHY [bit0: LE_1M; bit1: LE_2M; bit2:LE Coded; bit4: HDT]
• PHY_P_TO_C: 周辺機器から送信されるパケット用のPHY [bit0: LE_1M; bit1: LE_2M; bit2:LE Coded; bit4: HDT]
• インスタント：将来発生する特定の接続イベント。接続イベントカウンターの値によって参照される。
• アドレス：ACL接続において、その時点以降に使用されるPHYの物理チャネルアドレス
• 更新：1＝暗号化キーが更新されます。0または指定なし＝暗号化キーは更新されません、または接続は暗号化されません。
• MIC_Length: [1=HDT用のリフレッシュおよび64ビットMIC、0または指定なし=HDT用の128ビットMIC]; 接続が暗号化されていない場合、キーがリフレッシュされていない場合、またはGFSK PHYに変更された場合は無視される

LL_CIS_REQ

• Max_Payload_C_To_P: セントラルがCIS PDU内で送信できるリンクレイヤー の最大ペイロードサイズ（バイト単位）
• Max_Payload_P_To_C: 周辺機器がCIS PDU内で送信できるリンクレイヤー の最大ペイロードサイズ（バイト単位）
• Rates_C_To_P: セントラルから許可されるレート [bit0: HDT2; bit1: HDT3; bit2: HDT4; bit3: HDT6; bit4: HDT7.5]
• Rates_P_To_C: 周辺機器から許可されるレート [bit0: HDT2; bit1: HDT3; bit2: HDT4; bit3: HDT6; bit4: HDT7.5]
• Payload_Window_Size_C_To_P: セントラルが追跡、送信、再送信できるウィンドウ内のペイロードの数（1～4）
• Payload_Window_Size_P_To_C: 周辺機器が追跡、送信、再送信できるウィンドウ内のペイロードの数（1～4）
• MIC_Length：CISがHDT PHY上にあり、かつ暗号化されている場合、1は64ビットのMIC、0は128ビットのMICを意味する。それ以外の場合は無視される。
• SE_Length：サブイベントのために確保する必要がある時間（マイクロ秒単位）

LL_CIS_IND

• GFSK PHY上のCISの場合：AAはCISのアクセスアドレス、またはPDUにPCA-Hが含まれている場合は0
• HDT PHYのCISがAA=HPA31-0の場合、PCA-Hが存在し、かつHPA39-32に設定されている必要があります。

LL_POWER_CONTROL_REQ

• PHY：リクエストの対象となるPHY [bit0: 1M; bit1: 2M; bit2: 符号化 S=8; bit3: 符号化 S=2; bit4: HDT]

7. Bluetooth® HDTの暗号化

HDTは、Bluetooth LEの暗号化および認証の枠組みを強化し、より強力なデータ保護を実現するとともに、既存のセキュリティモデルとの互換性を維持し、Bluetooth技術が業界や規制上のセキュリティ動向に対応できるようにします。

このセクションでは、Bluetooth® HDTによって促進された暗号化関連の機能強化の概要と、それらを実現するために導入された新機能、手順、およびパラメータの概要について説明します。

7.1 HDT暗号化機能の強化の概要

HDTでは、より長いメッセージ整合性チェック（MIC）サイズのサポートおよびBluetooth Core 7.0で導入された新しい暗号化キースケジュール（EKS）機能 のサポートを導入することで、Bluetooth LEの暗号化機能を強化しています。ただし、暗号化および認証プロセス全体については、引き続き確立された暗号アルゴリズムに依存しており、共有秘密鍵の確立にはECDH、鍵導出にはAES-CMAC、データの暗号化および整合性保護にはAES-CCMが使用されています。

より大きなMICサイズのサポート

GFSKベースのBluetooth PHYでは、暗号化されたパケットに付加されるMICの長さは32ビット（4オクテット）と固定されています。HDTでは、パケットのペイロードが長くなるほど、データの破損や改ざんが見過ごされる確率を低減するために、より長いMICが必要となります。そのため、HDTでは以下のMICサイズに対応しています：

• 64b（8オクテット）
• 128b（16オクテット）

MICのサイズは、リンクレイヤー によって管理される暗号化セットアップフェーズで決定されます。いずれかの側が128bを希望する場合、128bが選択されます。新しいMICサイズは、HDT PHYを介して送信されるパケットにのみ適用されます（GFSKベースのPHYでは、引き続き32bのMICが使用されます）。選択されたMICサイズは、NISTの推奨事項に従い、接続全体で対称的に適用され、使用中のセッションキーに紐付けられます。

パケットフォーマット 1（PF1）の HDT パケットの場合、暗号化されたペイロードと MIC は、送信前（暗号化後）にブロック単位に分割されます。したがって、各ブロックは受信と同時に復号化できますが、MIC の検証は、すべてのブロックが正常に受信され、再構成された後にのみ行われます。

暗号化キースケジュール（EKS）のサポート

HDTで動作させるには、デバイスはGFSK PHYを使用してリンクを確立し、サポートされているHDT機能を検出するとともに、構成パラメータを選択・交換した後、PHY更新および暗号化更新手順を経てHDT PHYに切り替える必要があります。暗号化の観点からは、これに伴いMICサイズが32bから64bまたは128bに変更されるため、その結果として暗号化鍵の変更が必要となります。

暗号化キースケジュール（EKS）機能 を使用すると、暗号化キーの生成、管理、更新が可能となり、接続を切断したり暗号化手順を再起動したりすることなく、PHY（およびMICサイズ）の変更に対応できます。ECDHで導出された共有秘密鍵とAES-CMACベースの鍵導出関数を使用することで、EKSは以下の機能をサポートします：

• 機会的暗号化
• 完全前方秘匿性（PFS）
• 鍵およびMICの更新を同期させたシームレスなPHY遷移
• ACLおよびCISトランスポートにおけるストリームごとのキー分離

「オポチュニスティック暗号化」を使用すると、デバイスは事前に共有されたライフタイムキー（LTK）がなくても暗号化された接続を確立できるため、デバイスがペアリングされていない場合でも暗号化された通信が可能になります。これにより、「LE セキュア接続 」の「Just Works」方式を使用してデバイスをペアリングした場合と同等の機密性と完全性が確保されますが、認証機能や中間者攻撃（MITM）に対する保護機能は提供されません。

PFS では、デバイスの LTK、秘密鍵、または現在のセッションキーが侵害されても、それ以前のセッションキーが漏洩することはありません。したがって、以前の暗号化セッションの安全性は維持されます。暗号化の更新後にセッションキーが漏洩しても、暗号化の更新前の以前のセッションキーに関する情報は一切明らかになりません。セッションキーのみが判明した場合、他のセッションキーやトラフィックシークレットを導き出すことはできません。トラフィックシークレットが判明した場合、それ以降のトラフィックシークレットは導き出すことができますが、それ以前のものは導き出すことはできません。

これまではストリームごとの鍵の分離が可能でしたが、その際には「Diversifiers を使用した暗号化」のプロセスを最初から繰り返す必要がありました。EKS PFS により、このプロセスが大幅に簡素化されました。現在、CIS セッションの有効期間は限られています。これは、CIS セッションキーを更新できないためです。

HDTをサポートするデバイスでは、EKSのサポートが必須となります。接続を構成する両方のデバイスがEKSをサポートしている場合、EKSの使用が必須となります。EKSがサポートされていない場合は、ダイバーシファイアによる暗号化が引き続き適用されます。

新しい関数、プロシージャ、およびパラメータ

EKS（機能 ）の一環として、新しい暗号関数、新しい暗号タグ値、およびセッションキーを導出するための新しい手順が導入されました。また、AES-CCMアルゴリズムで使用されるカウンターモードブロックには、新しいサイズでのMIC計算に対応するため、新しいフィールドと値が追加されました。

7.2 鍵導出に関する更新

暗号ツールボックス

EKSの鍵導出階層には、以下の要素が含まれます。

• 派生秘密鍵：デバイス間のECDH共有秘密鍵から導出され、EKSキー階層の一部として使用されるベースキー
• トラフィックの秘密：派生秘密鍵から取得した鍵で、セッション鍵とIVを生成する
• セッションキーおよび初期化ベクトル（IV）：AES-CCMアルゴリズムにおいて、MICの生成、およびパケットの暗号化と認証に使用される

EKSサポートのために導入された新しい暗号関数は、AES-CMAC関数に基づいています（『Bluetoothコア仕様書』[第3巻] パートH、セクション2.2.5を参照）。これらは、LTKおよびECDH共有秘密鍵と組み合わせて、鍵導出階層全体をサポートしています。新しい関数によって実現されるCMACベースの鍵導出階層を図7.1に示します。

図7.1 – EKSを用いたCMACベースの鍵導出階層

新しい暗号関数およびタグの概要を表7.1および表7.2に示す。タグ付き入力により、鍵間の暗号的な分離が確保される。

表7.1 – 暗号ツールボックスの関数

機能	項目
k1	AES-CMAC を使用して、既存の鍵とコンテキスト固有の情報から新しい 128 ビットの鍵を導出します。他の鍵導出の基盤として使用されます。
k2	ECDHの共有秘密鍵から初期の「派生秘密鍵」を導出します。これは、接続における鍵階層のルートとなります。
k3	再ペアリングを行わずにセッションキーの更新に対応できるよう、トラフィックのシークレットを更新します
kv1	トラフィック・シークレットから128ビットのセッションキーを導出します。AES-CCM暗号化に使用されます。
kv2	トラフィック・シークレットから64ビットの初期化ベクトル（IV）を導出します。AES-CCMにおいて、ノンス の構築に使用されます。
kv12	関数ではなく、トラフィック・シークレットからセッションキーとIVを導出する際、kv1とkv2が常に組み合わせて使用されることを示す表記法です。
ee1	ベースキー（例：LTK や ECDH の出力）およびコンテキストタグ、あるいは以前に導出された秘密鍵から、派生秘密鍵を導出します。
ee2	ベースキーとコンテキストからトラフィックシークレットを導出する
ee12	関数ではなく、ee1とee2の両方が常に組み合わせて使用され、派生秘密鍵とトラフィック秘密鍵の両方が導出されることを示す表記法である。

表7.2 – 暗号タグの値

識別子	値	導出	使用
タグ	0x6465_72697665_64206873	「派生型hs」	k2
tagda	0x646572_69766564_2041434C	「派生ACL」	当初の派生した秘密
tagdc	0x646572_69766564_20434953	「派生CIS」	その後導き出された秘密
tagta	0x747261_66666963_2041434C	「トラフィックACL」	ACLのトラフィックに関する秘密
tagtc	0x747261_66666963_20434953	「トラフィックCIS」	CISのトラフィックに関する秘密
tagtr	0x747261_66666963_20757064	「交通情報」	k3
タグ	0x6B6579	「キー」	kv1
tagiv	0x6976	「iv」	kv2

暗号化手順

ACL暗号化を開始する

EKS を使用して ACL 接続の暗号化を開始する場合、デバイスはまず公開鍵を交換し、「鍵スケジュールによる暗号化開始（Encryption Start with Key Schedule）」手順に従って ECDH 共有秘密鍵を作成する必要があります。次に、受信した公開鍵の妥当性を検証し、ee12関数を使用して ACL の派生秘密鍵（Derived Secret）およびトラフィック秘密鍵（Traffic Secret）の初期値を計算する必要があります。最後に、デバイスはkv12関数を使用して、初期セッション鍵および IV を計算する必要があります。

デバイスがペアリングされていない場合、値がゼロのLTKが使用され、オポチュニスティック暗号化が可能になります。オポチュニスティック暗号化により、LTKが利用できない場合でも、暗号化を維持したまま、デバイスはGFSK PHYからHDT PHYに切り替えることができます。

CISのトラフィックに関する秘密

新しいコネクテッド・アイソクロナス・ストリーム（CIS）が作成されるたびに、デバイスは、CIS固有の識別子（CIG_ID、CIS_ID）を用いてee12関数を呼び出し、そのCIS用の新しい派生秘密値および初期トラフィック秘密値を生成します。これにより、ストリームごとの鍵の分離が可能となり、マルチストリーム環境におけるセキュリティが強化されます。その後、デバイスはkv12関数を用いて、そのCIS用の初期セッション鍵およびIVを計算する必要があります。

現在、各CISには、セッションキーを更新できないため、その有効期間（2^39パケット）を通じて1つのトラフィックシークレットが割り当てられています。

ACLセッションキー更新

HDTは、ホスト側の介入を必要とせずに、接続中のセッションキー更新 をサポートしています。トラフィックシークレットは、k3関数を使用してデバイスによって更新され、その後、kv12関数を介して新しいセッションキーとIVが導出されます。この更新処理では、パケットカウンターとペイロードの番号付けの両方が保持されるため、データ配信を中断することなくパケットの順序付けを継続することができます。これは、前回の更新から2^39パケット以内にセッションキーを更新しなければならないことを意味します。

PHYの遷移との統合

Bluetooth LEでは、暗号化セッション中にPHYを切り替える場合、通常は暗号化を一時停止してから再開する必要がありました。HDTは、EKSをPHYの切り替えに統合することで、この要件を解消します：

• 32bのMICを備えたGFSK PHYから、64bまたは128bのMICを備えたHDT PHYへ、あるいはその逆へ切り替える際、リンクレイヤー はEKSを使用して、キー更新 を連携して実行します。
• GFSK PHY上のキー更新 は、別のGFSK PHYへの変更と連動させることも可能です。
• PHYの切り替えに伴いMICサイズの変更が必要となる場合、新しいセッションキーとMICサイズは、PHYの切り替えと同時に有効になります。
• 2つのGFSK PHY間の切り替え時にはキー/MICの変更は行われず、HDT PHYに留まっている間も、必ずしも変更が行われる必要はありません。
• この連携により、保護されていないデータが露出することなく、またホストの再認証を必要とすることなく、継続的な暗号化が維持されます。

この統合により、PHYの切り替えが簡素化されるほか、NISTの要件に従い、MICサイズの変更には常に鍵の変更が伴うことが保証されるため、セキュリティが強化されます。

注意点として、HDT PHY上でLL_PHY_REQ/RSPおよびLL_PHY_UPDATE_INDが送信される場合、手順の一部においてACLユーザーデータ（制御プレーンデータは除く）を一時停止する必要があります。

7.3 暗号化の更新

CCMアルゴリズム

暗号化および認証において、CCMアルゴリズムでは、ペイロードと追加パラメータを、CCMノンス 、カウンターモードブロック、および暗号化ブロックという形式に構成する必要があります。CCMノンス は各パケットに一意性を付与し、カウンターモードブロックはMICの計算に使用され、暗号化ブロックはペイロードとMICを暗号化するために使用されるキーストリームを提供します。

EKSおよび可変長MICへの対応に伴い、GFSK PHYとHDT PHYに基づく動作の違いに対応するため、またリンクレイヤー の手順で定められたMICサイズ（32b、64b、または128b）を考慮するために、カウンターモードブロックのフォーマットおよびフィールドに更新が加えられました。

8. Bluetooth® HDT ホストコントローラインターフェース（HCI）

Bluetooth® HDT では、ホスト・コントローラ・インターフェース（HCI）の機能を拡張し、より高いスループット、パフォーマンスと堅牢性の向上、およびセキュリティの強化を実現するため、新しいコマンドやイベントが導入され、既存のコマンドやイベントも更新されています。

このセクションでは、HDT対応のための新規、バージョンアップされた、および更新されたHCIコマンドとイベントの概要を説明します。また、HDTサポートにおける主要なHCIコマンドとイベントの典型的な相互作用を示すメッセージシーケンスチャートも、Bluetooth LEのリンクレイヤー とともに掲載されています。

8.1 新規または更新されたHCIコマンドおよびイベントの概要

表8.1、8.2、および8.3には、HDTサポートに関する新規、バージョンアップされた、および更新されたHCIコマンドおよびイベントの概要がそれぞれ示されています。 明確にするために、バージョンアップされたコマンドおよびイベントは、HDTサポートのための新しいコマンドパラメータまたは戻り値パラメータを導入するものであるのに対し、更新されたコマンドおよびイベントは、既存のコマンドパラメータまたは戻り値パラメータに、HDTの有効化およびサポートのための新しい値を追加するのみである。各コマンドまたはイベントのサポート要件を含む詳細については、『Bluetoothコア仕様書』[Vol 4]、Part E、Section 3を参照のこと。

表8.1 – HDTサポートのための新しいHCIコマンドおよびイベント

コマンド／イベント	項目
LE 読み取り暗号化キースケジュール デバッグモード コマンド	EKSベースの暗号化を使用する際、デバッグモードの情報を読み取るために使用されます
「LE Set HDT Default Parameters」コマンド	ホストが、ローカルのコントローラのデフォルトのHDTパラメータを設定するために使用します
LE セット HDT パラメータ テスト コマンド	ホストが、接続の HDT テストパラメータを設定するために使用します
LEテストレポート：HDTリンク品質イベント	受信したHDT PHYテストパケットのリンク品質情報を報告します
LE 書き込み暗号化キーのスケジュール設定（デバッグモード）コマンド	EKSベースの暗号化中に、ホストがデバッグモードを設定するために使用されます

表8.2 – HDTサポートに向けたHCIコマンドおよびイベントのバージョンアップ

コマンド／イベント	項目
暗号化変更イベント [v3]	指定された Connection_Handle に対する暗号化の変更が完了したことを示します。
暗号化キー更新 イベント完了 [v2]	暗号化が一時停止された後に再開された際、指定された Connection_Handle に対して暗号化キーが更新されたホストを示します。
LE CIS 定例イベント [v3]	コントローラーがCISを確立したことを示す
LE Create BIG コマンド [v2]	BIGのBISを1つ以上作成します
LE Create BIG イベント全編 [v2]	コントローラが、ホストから要求されたBISの作成処理を完了したことを示します
LE Create BIG テストコマンド [v2]	テスト目的で、あるBIGのBISを1つ以上作成するために使用されます
LE データ長変更イベント [v2]	によってパケットの最大サイズが変更されたことを示すために使用されます。リンクレイヤー
LE 暗号化有効化コマンド [v2]	リンクレベルの暗号化を有効にするために使用されます
LE 最大データ長読み取りコマンド [v2]	ホストが、コントローラがサポートする MaxTxOctets、MaxTxTime、MaxRxOctets、および MaxRxTime パラメータを読み取れるようにします
LE 推奨デフォルトデータ長を読み取るコマンド [v2]	ホストが、コントローラに提案されたGFSK PHY上のHDT PHYまたは新規接続について、初期のMaxTxOctetsおよびMaxTxTimeを読み取れるようにする
LEレシーバー テストコマンド [v4]	LEのレシーバー テストを実行します
「LE CIG パラメータの設定」コマンド [v2]	コントローラ内のCIGに関連付けられた1つ以上のCISのパラメータを設定するために、セントラルのホストによって使用されます。
LE セット CIG パラメータ テストコマンド [v2]	テスト目的のみに使用されます。コントローラー内のCIGに関連付けられた1つまたは複数のCISのパラメータを設定するために、セントラルのホストによって使用されます。
LE データ長設定コマンド [v2]	コントローラに対して最大パケットサイズを提案するために使用されます
LE テスト終了コマンド [v2]	現在のレシーバー またはトランスミッター のテストを終了します
LEトランスミッター テストコマンド [v5]	LEのトランスミッター テストを実行します
LE Write 推奨デフォルトデータ長コマンド [v2]	ホストが、HDT PHY または GFSK PHY 上の新規接続に対して、初期の MaxTxOctets および MaxTxTime の値を提案できるようにします
「暗号化キーの更新」コマンド [v2]	ホストが、暗号化を一時停止してから再開することで、コントローラに暗号化キーの更新を行わせるために使用されます

表 8.3 – HDT サポートに向けた HCI コマンドおよびイベントの更新

コマンド／イベント	項目
LE BIG Sync 定例イベント	コントローラが、要求されたBISとの同期を試行し、完了したことを示します
「LE BIGInfo」広告レポートイベント	コントローラが、BIGInfoフィールドを含むアドバタイジングPDUを受信したことを示します
LE CS セット・プロシージャ・パラメータ コマンド	ホストが、ローカルコントローラによる1つまたは複数のCSプロシージャのスケジューリングに関するパラメータを設定するために使用されます。
LE 拡張読み取り送信電力レベルコマンド	ACL接続上のローカルコントローラの現在および最大送信電力レベルを読み取るために使用されます
LEフレームスペース更新 イベント全編	フレーム空間の値に変更があったことをホストに通知するために使用されます
「LE PHY Update Complete」イベント	各方向の現在のPHYをホストに通知するために使用される
LE PHYコマンドの読み取り	各方向の現在のPHYを読み取るために使用されます
LE リモート送信電力レベル読み取りコマンド	ACL接続において、リモートコントローラが使用している送信電力レベルを読み取るために使用されます
LE デフォルトの PHY コマンドの設定	ローカルデバイスの新規接続において、優先するPHYを設定するために使用されます
LE イベントマスクの設定コマンド	ホストに対してHCIがどのイベントを生成するかを制御するために使用されます
LEのPHYコマンドの設定	Connection_Handle の PHY の変更を要求するために使用されます
LE送信電力報告イベント	ACL接続における送信電力レベルを報告するために使用されます
「イベントマスクの設定」ページ 2 のコマンド	ホストに対してHCIがどのイベントを生成するかを制御するために使用されます

8.2 新しいHCIコマンドとイベント

LE 読み取り暗号化キースケジュール デバッグモード コマンド

暗号化キースケジュールに基づく暗号化を使用する際のデバッグモードを返します。このコマンドは、それ以降のすべての接続に対して有効となり、既存の接続には影響しません。

「LE Set HDT Default Parameters」コマンド

中央ホストまたは周辺ホストが、その後のすべての接続で使用する HDT PHY のデフォルトパラメータを指定できるようにします。既存の接続には影響しません。

• Preferred_MIC_Length – LE HDT PHY 上のすべての暗号化接続で使用する推奨 MIC 長を示します
• Preferred_Packet_Format – LE HDT PHY でのデータ伝送に使用する優先 HDT パケット形式を示します
• Preferred_ACL_Rates – LE HDT PHY上のACL接続で優先的に使用するレートを示します

LE セット HDT パラメータ テスト コマンド

テスト目的のみに使用されます。HDT PHY を使用する際、中央ホストまたは周辺ホストが、Connection_Handle で指定された ACL または CIS 接続のテストパラメータを設定するために使用されます。ホストは、HCI_LE_Read_Maximum_Data_Length を使用して、ローカルコントローラがサポートする HDT ペイロードおよびパケット機能情報を読み取ることができます。

• MIC_Length – ハンドルで指定されたACL接続の暗号化に使用するMICの長さを示します
• Packet_Format – PDUヘッダーゾーンを持つすべての送信パケットに使用するフォーマットを示します
• Blocks_Per_Payload – PF1 を使用する場合、その接続でペイロードごとに使用するブロック数を示します
• TX_Rate – ACL接続での送信時に使用するHDTレートを指定します（CISの場合は無視されます）

LEテストレポート：HDTリンク品質イベント

ローカルコントローラが、受信したLE HDT PHYテストパケットからリンク品質の結果を報告する際に生成されます。

• Subevent_Code – イベントのサブイベントコード
• Channel_Index – テストパケットを受信するRFチャネル
• Report_Status – コントローラーに送信すべきレポートがまだ残っているかどうかを指定します
• Report_Count – パケットごとに報告されるRSSI[i]およびSNR[i]のパラメータ 値の数を指定します
• RSSI[i] – 受信順に並べられた個々のテストパケットに対応するRSSI値
• SNR[i] – 受信順に基づいて、個々のテストパケットに関連付けられたSNR値

LE 書き込み暗号化キーのスケジュール設定（デバッグモード）コマンド

デバッグ用機器が暗号化された接続を監視できるように、暗号化キースケジュールに基づく暗号化に事前定義されたECDH鍵ペアを使用するようコントローラを設定するために使用されます。このコマンドは、それ以降のすべての接続に対して有効となり、既存の接続には影響しません。

8.3 バージョンアップされた HCI コマンドおよびイベント

暗号化変更イベント [v3]

暗号化モードの変更が完了したことを示すために使用されます。[v3] では、EKS ベースの暗号化が使用されている場合の接続の MIC 長、および「Key Schedule LL を使用した暗号化開始」手順でデバッグ用キーペアが使用されているかどうかを示す新しいイベントパラメータが導入されました。

暗号化キー更新 イベント完了 [v2]

指定された Connection_Handle に対して暗号化キーが更新されたことをホストに通知するために使用されます。[v2] では、Encryption Change [v3] イベントと同じ目的で、イベントパラメータ MIC_Length、Key_Schedule_Enabled、および Key_Schedule_Debug_Flag が導入されています。このイベントが LE PHY 更新手順によって生成された場合、HCI_LE_PHY_Update_Complete イベントの直後に送信されます。

LE CIS 定例イベント [v3]

CISが正常に確立されたか、または失敗した（例：拒否された、あるいは確立前に切断された）ことをホストに通知します。[v3] では、以下のイベントパラメータが導入され、HDTの使用を指定するための PHY イベントパラメータに新しい値が追加され、Max_Payload イベントパラメータの上限が 8175 オクテットに引き上げられました。

• Rates_C_To_P – 中央から周辺方向における特定のLE Coded またはHDTデータレートの使用を示します
• Rates_P_To_C – 周辺機器から中央機器への方向において、特定のLE Coded またはHDTデータレートが使用されていることを示します。
• Config_ID – CIG 構成識別子
• TL_Group_ID – Config_ID に関連付けられたトランスポート遅延グループ識別子
• Encryption_Enabled – CIS で暗号化が有効になっているかどうか、およびその種類（例：EKS、オポチュニスティック）を示します。
• MIC_Length – 暗号化に使用するMICの長さを示します

LE Create BIG コマンド [v2]

1つ以上のBISを使用してBIGを作成するために使用されます。BIG内のすべてのBISは、すべてのパラメータについて同じ値を持ちます。[v2]では、以下のコマンドパラメータが導入されたほか、HDT PHYによるパケット送信を示すための新しいPHYビット番号パラメータ が追加されました。

• Coded_Rates –LE Coded のPHYで優先的に使用するレートを示します
• HDT_Rates – HDT PHY において優先的に使用するレートを示します
• HDT_MIC_Length – HDT 経由の暗号化に使用する MIC の長さを示します
• HDT_Packet_Format – BISがHDT PHY上で動作している際の、データ伝送に推奨されるHDTパケット形式を示します。

LE Create BIG イベント全編 [v2]

HCI_LE_Create_BIG または HCI_LE_Create_BIG_Test コマンドが完了したことを示し、成功した場合は、リンクレイヤー がアイソクロナス・ブロードキャスティング状態 に入ったことを示します。[v2] では、以下のイベントパラメータが導入され、HDTの使用を指定するための PHY イベントパラメータ に新しい値が追加され、Max_Payload サイズの上限が 8175 オクテットに引き上げられました。

• 料金 – 「LE Coded 」または「HDT PHY」に適用されるコードまたは料金を示します。
• Encryption_Enabled – BIGで暗号化が有効になっているかどうかを示します
• MIC_Length – 暗号化に使用するMICの長さを示します

LE Create BIG テストコマンド [v2]

テスト目的のみに使用されます。1つ以上のBISからBIGを作成するために使用されます。BIG内のすべてのBISは、すべてのパラメータについて同じ値を持ちます。[v2]では、以下のコマンドパラメータが導入され、HDT PHYによるパケット送信を示すための新しいPHYビット番号パラメータ が追加され、Max_Payloadサイズの上限が8175オクテットに引き上げられました。

• Coded_Rates –LE Coded のPHYで優先的に使用するレートを示します
• HDT_Rates – HDT PHY において優先的に使用するレートを示します
• HDT_MIC_Length – HDT 経由の暗号化に使用する MIC の長さを示します
• HDT_Packet_Format – BISがHDT PHY上で動作している際の、データ伝送に推奨されるパケット形式を示します
• HDT_Blocks_Per_Payload – PF1 との接続で使用するペイロードあたりのブロック数を示します

LE データ長変更イベント [v2]

リンクレイヤー データPDUのペイロードの最大長、またはLLデータPDUを含むパケットの双方向における最大伝送時間のいずれかに変更があった場合、ホストに通知します。[v2]では、イベントパラメータが適用されるPHYを示すために、PHYSイベント「パラメータ 」が導入されました。また、Max_TX_OctetsおよびMax_RX_Octetsのサイズの上限が8175オクテットに引き上げられました。

LE 暗号化有効化コマンド [v2]

リモートデバイスに関連付けられた指定された暗号化キーの認証を行い、認証後に接続を暗号化するために使用されます。[v2] では、HDT PHY 上の ACL 接続において、暗号化に推奨される MIC 長を示す HDT_MIC_Length および Encryption_Type コマンドパラメータが導入されました。これらは、EKS またはオポチュニスティック暗号化のタイプを指定するためのものです。

LE 最大データ長読み取りコマンド [v2]

ホストが、LLデータPDUの送受信に関して、コントローラがサポートする最大ペイロードサイズおよびパケット持続時間を読み取れるようにします。[v2]では、どのPHYのパラメータを読み取るかを指定するためのPHYコマンド「パラメータ 」が導入されたほか、HDT（機能 ）のサポートに向けた以下の戻りパラメータも追加されました。また、「Supported_Max_TX/RX_Octets」の値範囲の上限が8175オクテットに引き上げられました。

• Supported_Max_TX_Payload_Window_Size – コントローラがサポートする送信ペイロードウィンドウサイズの最大値
• Supported_Max_RX_Payload_Window_Size – コントローラがサポートする受信ペイロードウィンドウサイズの最大値
• Supported_Max_RX_Octets_Per_Packet – 1つのパケットで受信可能なペイロードの最大合計オクテット数

LE 推奨デフォルトデータ長を読み取るコマンド [v2]

ホストが、コントローラに設定されたLLデータPDU送信パラメータの推奨デフォルト値（Suggested_Max_TX_Octets、Suggested_Max_TX_Time）を読み取れるようにします。 [v2] では、送信パラメータの読み取り対象となる PHY（GFSK または HDT）を指定するためのコマンド「パラメータ PHYS」が導入され、返される Suggested_Max_TX_Octets の値範囲の上限が 8175 オクテットに引き上げられました。

LEレシーバー テストコマンド [v4]

IUTが一定間隔でテスト参照パケットを受信するテストを開始するために使用されます。[v4] では、HDT PHY に対して SNR 測定を行うかどうかを指定するためのコマンド HDT_SNR_Testパラメータ が導入されました。また、HDT PHY の使用を示すための PHY の新しい値も追加されています。

「LE CIG パラメータの設定」コマンド [v2]

セントラルのホストが、CIGを作成し、コントローラ内でそのCIGに関連付けられた1つ以上のCISのパラメータを設定するために使用されます。[v2]では、HDT PHYのサポートのために以下のコマンドパラメータが導入されたほか、HDT PHYの使用を示すためのPHY_C_To_P[i]およびPHY_P_To_C[i]の新しいビット番号が追加されました。

• Coded_Rates_C_To_P[i] – 中央から周辺機器への通信において、LE Coded のPHYよりも優先して使用するべき伝送速度を示す
• Coded_Rates_P_To_C[i] – 周辺機器から中央機器への通信において、LE Coded のPHYよりも優先して使用するべき伝送速度を示す
• HDT_Rates_C_To_P[i] – 中央から周辺機器へのHDT PHYにおいて、優先的に使用する転送速度を示す
• HDT_Rates_P_To_C[i] – 周辺機器から中央機器へのHDT PHY経由で使用する優先レートを示す
• HDT_MIC_Length[i] – 暗号化に使用するMICの長さを示します
• HDT_Packet_Format[i] – コントローラが使用する推奨のHDTパケット形式を示します

LE セット CIG パラメータ テストコマンド [v2]

テスト目的のみに使用されます。セントラルのホストが、CIG を作成し、コントローラ内でその CIG に関連付けられた 1 つ以上の CIS のパラメータを設定するために使用されます。 [v2] では、HDT PHY サポートのために以下のコマンドパラメータが導入され、Max Payload コマンドパラメータの上限が 8175 オクテットに引き上げられ、HDT PHY の使用を示すために PHY_C_To_P[i] および PHY_P_To_C[i] の新しいビット番号が定義されています。

• Coded_Rates_C_To_P[i] – 中央から周辺機器へのLE Coded PHYにおいて、優先的に使用する伝送レートを指定する
• Coded_Rates_P_To_C[i] – 周辺機器から中央機器へのLE Coded PHY経由で使用する優先レートを示す
• HDT_Rates_C_To_P[i] – 中央から周辺機器へのHDT PHYにおいて、優先的に使用する転送速度を示す
• HDT_Rates_P_To_C[i] – 周辺機器から中央機器へのHDT PHY経由で使用する優先レートを示す
• HDT_MIC_Length[i] – HDT 経由の暗号化に使用する MIC の長さを示します
• HDT_Packet_Format[i] – コントローラが使用する推奨のHDTパケット形式を示します
• HDT_Payload_Window_Size_C_To_P[i] – セントラルからペリフェラルへ送信される際に使用されるペイロードウィンドウのサイズを示す
• HDT_Payload_Window_Size_P_To_C[i] – 周辺機器から中央機器へ送信されるペイロードウィンドウのサイズを示す

LE データ長設定コマンド [v2]

ホストが、特定の接続におけるLLデータPDUに使用する最大送信ペイロードサイズおよび時間を指定できるようにします。[v2]では、パラメータが適用されるPHY（GFSKまたはHDT）を指定するためのコマンド「パラメータ PHYS」が導入され、TX_Octetsの値の範囲の上限が8175オクテットに引き上げられました。

LE テスト終了コマンド [v2]

進行中のテストをすべて停止するために使用されます。[v2] では、HDT PHY で受信したブロック数を示す `パラメータ Num_Blocks` の戻り値が導入されました。

LEトランスミッター テストコマンド [v5]

IUTが一定間隔でテスト用参照パケットを生成するテストを開始するために使用されます。[v5] では、HDT伝送テスト用に以下のコマンドパラメータが導入され、HDT PHYの使用を示すための新しい PHY 値が追加されました。

• HDT_Rate_Indicator – HDT PHYの伝送速度を指定します
• HDT_Packet_Format_Indicator – HDTパケットの形式を指定します
• HDT_Payload_Length – パケット形式 0 におけるペイロードの長さを指定します（PF1 では無視されます）。
• HDT_PHY_Interval – PHYインターバルあたりのペイロードシンボル数を指定します
• HDT_Num_Blocks[i] – ペイロード内のブロック数（Nb）を指定します（PF0の場合はNb=0）。
• HDT_Block_Size[i] – ペイロード内の各ブロックの長さを指定します（最後のブロックを除く）。
• HDT_Final_Block_Size[i] – 送信される最後のブロックの長さを指定します

LE Write 推奨デフォルトデータ長コマンド [v2]

ホストが、コントローラのLLデータPDU送信パラメータに対する推奨デフォルト値（Suggested_Max_TX_Octets、Suggested_Max_TX_Time）を指定・書き込みできるようにします。 [v2] では、送信パラメータが指定される PHY（GFSK または HDT）を示すコマンド `パラメータ PHYS` が導入され、`Suggested_Max_TX_Octets` の値の範囲の上限が 8175 オクテットに引き上げられました。

「暗号化キーの更新」コマンド [v2]

ホストが、Encryption Refresh プロシージャを使用して、Connection_Handle で識別される ACL 接続上の暗号化キーをコントローラに更新させるために使用されます。この接続で HDT PHY を使用する場合、MIC Length が指定されます。

8.4 HCI コマンドおよびイベントの更新

LE BIG Sync 定例イベント

Max_Payload イベントの「パラメータ 」値の範囲の上限が 8175 オクテットに拡大されました。

「LE BIGInfo」広告レポートイベント

Max_Payloadイベントのパラメータ 値の上限が8175オクテットに引き上げられました。また、HDT PHY上でBIGが送信されたことを示す新しいPHYイベントパラメータ 値が定義されました。

LE CS セット・プロシージャ・パラメータ コマンド

HDT PHYの使用状況を示すために、新しいPHYコマンド「パラメータ 」の値が定義されました。

LE 拡張読み取り送信電力レベルコマンド

HDT PHY アソシエーションを指定するために、PHY コマンドおよびリターンパラメータの新しい値が定義されました。

LEフレームスペース更新 イベント全編

HDT PHYの使用状況を示すため、PHYSイベント「パラメータ 」の新しいビット番号が定義されました。

「LE PHY Update Complete」イベント

HDT PHY を使用した送受信を示すために、TX_PHY および RX_PHY イベントパラメータの新しい値が定義されました。

LE PHYコマンドの読み取り

HDT PHYの使用状況を示すために定義された、TX_PHY および RX_PHY の戻りパラメータの新しい値。

LE リモート送信電力レベル読み取りコマンド

HDT PHY アソシエーションを指定するために、PHY コマンド「パラメータ 」の新しい値が定義されました。

LE デフォルトの PHY コマンドの設定

HDT PHYの使用を示すために、TX_PHY および RX_PHY コマンドパラメータの新しい値が定義されました。

LE イベントマスクの設定コマンド

マスクに、「LE CIS Established [v3]」、「LE Create BIG Complete [v2]」、「LE Data Length Change [v2]」、および「LE Test Report HDT Link Quality」の4つのイベントが追加されました。

LEのPHYコマンドの設定

HDT PHYの使用状況や設定を示すために、TX_PHY、RX_PHY、およびPHY_Optionsコマンドパラメータの新しいビット番号が定義されました。

LE送信電力報告イベント

HDTのPHY使用状況を示すために、新しいPHYイベント「パラメータ 」の値が定義されました。

「イベントマスクの設定」ページ 2 のコマンド

「暗号化の変更 [v3]」、「暗号化キー更新 完了 [v2]」、および「暗号化キーのデバッグレポート」の3つのイベントがマスクに追加されました。

8.5 メッセージシーケンス図

以下の図は、Bluetooth LEリンクレイヤー における HDT サポートに関連する HCI コマンドとイベントの典型的な相互作用を示しています。

GFSK PHY から HDT PHY への切り替え

暗号化されていないACL接続

図8.1 – 暗号化されていないACL接続でのHDT PHYへの切り替え

暗号化されたACL接続

図8.2 – 暗号化されたACL接続でのHDT PHYへの切り替え

HDT PHY から GFSK PHY への切り替え

暗号化されていないACL接続

図8.3 – 暗号化されていないACL接続におけるHDT PHYからGFSK PHYへの切り替え

暗号化されたACL接続

図8.4 – 暗号化されたACL接続におけるHDT PHYからGFSK PHYへの切り替え

データ長の更新

図8.5 – データ長の更新

HCI_LE_Set_Data_Length コマンドの [v2] 以降、HCI_LE_Data_Length_Change イベント、LL_LENGTH_REQ PDU、および LL_LENGTH_RSP PDU を使用して、HDT PHY のパラメータを変更します。

HDTを介したCIGの設定

図8.6 – HDT PHY上のCIGおよびCISの構成

キースケジュールによる暗号化の開始

図8.7 – キースケジュールによる暗号化の開始

キースケジュールを使用したオポチュニスティック暗号化を開始する

図8.8 – オポチュニスティック暗号化の開始

キースケジュールによる暗号化の再開始

図8.9 – キースケジュールによる暗号化の再開

キースケジュールによる暗号化の更新

図8.10 – キースケジュールによる暗号化の更新

9. その他

Bluetooth® HDT では、Bluetooth LE スタックのホスト層および ISOAL 層に対する更新が導入されています。ホスト層の更新は主に、MIC 長さの要件の検証と適用をサポートするものであり、一方、ISOAL 層の更新は、新しい HDT PHY によって可能となった、より大きなデータペイロードの転送をサポートするものです。

9.1. 論理リンク制御および適応プロトコル（L2CAP）

HDTでは、クレジットベースのフロー制御（CBFC）を用いたL2CAPデータチャネルの作成において、MICの長さを追加のセキュリティ基準としています。

CBFCは、レシーバー で付与されたクレジットを用いて、デバイス間のデータ伝送を制御し、接続指向型のL2CAPチャネルを管理する仕組みです。CBFCには、LEモードとEnhancedモードの2種類があります。大まかに言えば、LE CBFCでは接続ごとに1つのL2CAPチャネルを確立するのに対し、Enhanced CBFCでは複数のチャネルを同時に確立することができます。どちらのモードも、クレジットベースの接続要求とそれに対応する応答の交換を含むL2CAP手順を通じて有効化されます。

HDTは、クレジットベースのL2CAPチャネルの確立時に実行されるセキュリティ検証を拡張し、デバイスが従来の認証、認可、および暗号化鍵サイズのチェックに加え、MICの長さに関する要件を確認・強制できるようにします。また、応答パケットの「Result」データフィールドに、ネゴシエーションされたMICの長さが不十分であるために接続要求が拒否されたことを示す値を導入しています。

9.2. 汎用アクセスプロファイル（GAP）

HDTは、LEセキュリティモード1の仕様およびサービス認証手順に小幅な更新を加え、Bluetooth LEデバイスがGeneric Access Profile（GAP）を通じてサービスにアクセスする際のセキュリティ要件を評価・満たす方法を強化しました。

GAPでは、セキュリティモードによって、デバイスがサービスや属性に安全にアクセスするためにBluetooth LE接続が満たすべき要件が定義されています。LEセキュリティモード1は、認証と暗号化のさまざまな組み合わせを用いた4つのセキュリティレベルを通じて、LE ACL接続のセキュリティを規定しています。

HDTは、HDT PHY上で動作する暗号化接続において、128ビット相当の強度を持つ長期鍵（LTK）の使用を義務付けることで、LEセキュリティモード1を拡張しています。関連するLTKが要求される128ビット相当の強度を満たしていない場合、デバイスは接続をHDT PHYに移行すること、またはHDT PHYを使用するCISを確立することを禁止されています。

また、HDTでは、サービス要求への対応およびサービス要求の開始に使用されるGAPの手順も更新されています。サービスに、現在の接続では満たされないレベルのセキュリティが要求される場合、GAPはサービス要求を評価し、ネゴシエーションされたMICの長さがサービスの要件を満たさない場合は、エラーコード「MIC Length Too Short」を返してその要求を拒否できるようになりました。

デバイスがサービス要求を開始した際、MICの長さが不十分な場合、GAPは、要求を再試行する前に必要なMICの長さを確保するため、PHY更新および暗号化更新手順を起動することができる。必要なMICの長さを確保できない場合、その要求は拒否される。

詳細については、『コア仕様書』第3巻C部を参照してください。

9.3. 属性プロトコル（ATT）

HDTでは、属性プロトコル（ATT）によって管理される属性へのアクセスにおいて、MICの長さを追加のセキュリティ基準としています。

ATTは、Bluetooth LEデバイスが、クライアントがサーバーによって公開された属性を検出、読み取り、書き込み、およびその他の方法でアクセスできるようにするために使用するプロトコルです。

HDTでは、ネゴシエートされたMICの長さが要求された属性のセキュリティ要件を満たしていないために、属性アクセス要求が拒否されたことを示す新しいエラーコード「MIC Length Too Short」を導入しました。このエラーコードはATT属性権限に組み込まれており、属性の検出、読み取り、書き込み操作など、保護された属性にアクセスするすべてのATT手順でサポートされています。

新しいエラーコードに対応するように更新されたATT PDUは、コア仕様の第3巻パートFに記載されており、参考までに以下に一覧を示します。

• ATT_ERROR_RSP
• ATT_FIND_INFORMATION_REQ
• ATT_FIND_BY_TYPE_VALUE_REQ
• ATT_READ_BY_TYPE_REQ
• ATT_READ_REQ
• ATT_READ_BLOB_REQ
• ATT_READ_MULTIPLE_REQ
• ATT_READ_BY_GROUP_TYPE_REQ
• ATT_READ_MULTIPLE_VARIABLE_REQ
• ATT_WRITE_REQ
• ATT_PREPARE_WRITE_REQ

9.4. 汎用属性プロファイル（GATT）

HDTでは、GATTプロファイルで定義されている手順に軽微な更新を加え、ATTレベルのMIC長さのセキュリティチェックおよび新たな「MIC長さが短すぎる」エラー状態の認識と伝播に役立つ特性値および記述子の読み取り・書き込みを行うようにしました。

更新されたGATTの手順は、『コア仕様書』第3巻G部に記載されており、参考までに以下に列挙する。

• 固有値を読み取る
• 長特性値を読み取る
• 複数の特性値を読み取る
• 複数の可変長特性値を読み取る
• 固有値の記述
• 長い特性値を記述する
• 特徴値 信頼性の高い書き込み
• 特性記述子の読み取り
• 長い特性記述子を読み込む
• 特性記述子の書き込み
• 長い特性記述子の記述

9.5. 等時性適応層（ISOAL）

HDTは、HDT PHYによって可能となる大容量データペイロードの転送をサポートするために必要な、アイソクロナス適応層（ISOAL）の更新を導入しました。

ISOALは、アイソクロナス転送（LE AudioのCISおよびBISストリームで使用されるもの）を介して交換されるサービスデータ単位（SDU）の分割および再構成を担当する。

より大きなSDUセグメントに対応するため、HDTでは、ISOALフレーム化PDUセグメンテーションヘッダーのフォーマットを更新し、Lengthフィールドを8ビットから12ビットに拡張しています。Lengthフィールドは、フレーム化PDU内に含まれるSDUセグメントのサイズ（オクテット単位）を示します。既存のヘッダーフォーマットとの互換性を維持するため、この12ビットの値は、セグメンテーションヘッダー内で「Length High」フィールドと「Length Low」フィールドに分割されています。

これらの変更により、ISOAL で表現可能な SDU セグメントの最大サイズが拡大され、既存の ISOAL セグメンテーションおよび再組み立てアーキテクチャとの互換性を維持しつつ、より大きなペイロードを効率的に転送できるようになります。詳細については、『Bluetooth コア仕様』第 6 巻、パート G を参照してください。

これらの変更はISOAL内で実装されますが、その影響はBluetoothスタックの上位層にまで及ぶ可能性があります。 ISOALは、より大きなSDUセグメントをサポートすることで、コントローラがより大きなアイソクロナス・ペイロードを転送できるようにし、最終的にはより大きなISOデータパケットを通じてホストに配信することが可能になります。セグメンテーションと再組み立ては、ほとんどのホストおよびアプリケーションソフトウェアに対して透過的なままですが、HDTによって提供されるペイロード容量の増加により、基盤となるISOALのセグメンテーションおよび再組み立てアーキテクチャを変更することなく、より要求の厳しいアイソクロナス・データストリームをサポートできるようになります。

10. まとめ

Bluetooth®高データスループット は、Bluetooth LEの機能と性能を大幅に向上させ、新世代のワイヤレス体験の基盤を築くとともに、Bluetoothエコシステム全体における新たなイノベーションの機会を創出します。

新しいBluetooth HDT PHYは、Bluetooth LEの性能限界を拡大し、より高いスペクトル効率、適応型データレート、および変化するチャネル条件下でも信頼性の高い通信を維持するように設計されたメカニズムを通じて、サポートされる最大ビットレートを7.5 Mbpsに引き上げます。

新しいBluetooth HDTパケット構造は、大容量のPHYを補完するものであり、効率性、堅牢性、およびオーバーヘッドのバランスをとるよう設計された柔軟なフォーマットを備えています。コントロールヘッダーとペイロードを分離することで、重要なパケット情報をより堅牢に処理できると同時に、ペイロード伝送における動的なデータレートをサポートします。ペイロードの大型化、ペイロードの集約、ブロック単位の伝送、および選択的な再送信により、HDTはより大量のデータを効率的に転送できるようになり、伝送エラーの影響を最小限に抑えることができます。

HDTリンクレイヤー の機能強化により、HDTの動作設定および管理、GFSKとHDT PHY間の切り替えの調整、リンク状態の変化への対応、アイソクロナス通信のサポート、およびBluetooth HDTで導入された強化されたセキュリティ機能の管理に必要なインテリジェンスが提供されます。

HDTは、MICサイズの拡大と暗号化キースケジュール（EKS）機能 のサポートにより、Bluetooth LEのセキュリティを強化しています。これにより、より大きなペイロードに対する保護が強化されるほか、デバイスがGFSK動作とHDT動作の間で切り替わる際の、連携した鍵の更新が可能になります。また、EKSでは、オポチュニスティック暗号化、完全前方秘匿性（PFS）、より柔軟な暗号化鍵管理などの機能も導入されています。

HCI層およびホスト層の更新により、HDTコントローラの機能がより広範なBluetooth LEスタックに統合され、ホスト側には、HDTの設定やパラメータの指定、HDTの動作監視、および新しいPHYで導入された大容量のペイロードや強化されたセキュリティ要件への対応に必要なインターフェースが提供されるようになった。

確立されたBluetoothアプリケーションやユースケースにおいて、Bluetooth HDTは、開発者が新世代の製品に活用できる機能を提供し、データ転送速度の向上、容量の拡大、効率の改善、そしてより堅牢なワイヤレス性能の実現を可能にします。同時に、HDTはBluetooth LEの可能性を広げ、高解像度・ロスレスオーディオといったより洗練された体験や、データ要件がますます厳しくなる新興アプリケーションに必要な、さらなる性能と容量を提供します。

全体として、Bluetooth技術は、その普及に貢献してきた相互運用性、効率性、柔軟性を維持しつつ、新たな用途に対応するために絶えず進化を続けてきました。Bluetooth®高データスループット は、その進化における重要な次のステップであり、Bluetooth LEが、それを基盤とするアプリケーションやユーザー体験とともに進化し続けるために必要な、さらなる性能と容量を提供します。

実装要件および技術的な詳細については、『Bluetooth Core Specification 7.0』を参照してください。

1.C. E. シャノン、「通信の数学的理論」、『Bell System Technical Journal』、第27巻、379–423頁および623–656頁、1948年7月および10月。