1 INTRODUCTION

Bluetooth 仕様のこのセクションでは、L2CAP と呼ばれる論理リンク制御および適応レイヤプロトコルを定義しています。 L2CAP は、プロトコル多重化機能とセグメンテーションおよび再構成動作を備えた上位層プロトコルに、コネクション指向のコネクションレスデータサービスを提供します。 L2CAPでは、上位層のプロトコルおよびアプリケーションが、最大64キロバイトの長さの上位層データパケット（L2CAP Service Data Units、SDU）を送受信することができます。 また、L2CAPでは、チャンネルごとのフロー制御と再送も可能です。

L2CAPレイヤは、1つ以上の論理リンク上で多重化されたL2CAPチャネルという名前の論理チャネルを提供します。

1.1 L2CAP FEATURES

L2CAP の機能要件には、プロトコル/チャネル多重化、セグメンテーションおよび再構成（SAR）、チャネルごとのフロー制御、およびエラー制御が含まれます。 L2CAP は、以下のいずれかで構成される下位レイヤの上に配置されます。

1. BR/EDR コントローラとゼロ以上の AMP コントローラ、または
2. BR/EDR/LEコントローラ（BR/EDRとLEをサポート）とゼロ以上のAMPコントローラ、または
3. LEコントローラー（LEのみ対応 L2CAP は、上位層プロトコルとのインターフェイスです。

図 1.1 は、L2CAP をアーキテクチャ コンポーネントに分解したものです。 チャネル マネージャは、コントロール プレーン機能を提供し、すべての内部シグナリング、L2CAP ピアツーピアシグナリング、上位層および下位層とのシグナリングを担当します。 セクション6で説明されているステートマシン機能を実行し、セクション4およびセクション5で説明されているメッセージフォーマットを使用します。 再送およびフロー制御ブロックは、パケット再送を使用して、チャネルごとのフロー制御およびエラー回復を提供します。 リソースマネージャは、チャネルマネージャ、再送・フロー制御ブロック、および再送・フロー制御サービスを必要としないそれらのアプリケーションデータストリームにフレームリレーサービスを提供する責任を負う。 下層インターフェイスで提供される設備を介して、複数の L2CAP チャネルに関連するパケットの送受信を調整する責任があります。

• プロトコル/チャンネル多重化 L2CAP は、個々のコントローラ上での多重化、および複数のコントローラ間での多重化をサポートしています。 L2CAPチャンネルは、一度に1つのコントローラ上で動作するものとします。

チャネルのセットアップ中、プロトコル多重化機能は、正しい上位層プロトコルへの接続をルーティングするために使用されます。

データ転送では、複数の上位レイヤエンティティを区別するために、論理チャネル多重化が必要となります。 同じプロトコルを使用する上位層エンティティが複数存在する場合があります。

• セグメンテーションと再構成 リソース マネージャが提供するフレーム中継サービスでは、トランスポート フレームの長さは、L2CAP 上で実行している個々のアプリケーションによって制御されます。 多くの多重化されたアプリケーションでは、L2CAPがPDUの長さを制御している方が、より良いサービスを提供できます。 これにより、次のような利点が得られます。

  はじめに a) セグメンテーションにより、レイテンシ要件を満たすためにアプリケーションデータ単位のインターリーブが可能になります。

b) L2CAPがパケットサイズを制御することで、メモリやバッファの管理が容易になる。

c) 再送によるエラー訂正をより効率的に行うことができる。

d) L2CAP PDUが破損または紛失したときに破棄されるデータ量を、アプリケーションのデータ単位よりも小さくすることができる。

e) アプリケーションパケットを下層パケットにマッピングするために必要なセグメンテーションからアプリケーションを切り離すことができる。

• L2CAPチャンネルごとのフロー制御 コントローラは、エア上を通過するデータに対してエラーおよびフロー制御を提供し、HCI トランスポート上を通過するデータに対しては HCI フロー制御が存在します。 複数のデータ ストリームが、別々の L2CAP チャネルを使用して同じコントローラ上で実行される場合、各チャネルには個別のフロー制御が必要になります。 ウィンドウベースのフロー制御スキームが提供されます。

• エラー制御と再送 L2CAPチャネルを1つのコントローラから別のコントローラに移動すると、データが失われることがあります。 また、一部のアプリケーションでは、一部のコントローラが提供できる残差エラーレートよりもはるかに小さい残差エラーレートを必要とする場合があります。 L2CAPは、エラーチェックとL2CAP PDUの再送を提供します。 L2CAPのエラーチェックは、コントローラが、エラーを含むがコントローラベースの整合性チェックに合格したパケットを誤って受け入れることによるエラーから保護します。 L2CAP のエラーチェックと再送は、コントローラによるフラッシングによるパケットの損失からも保護します。 エラー制御は、フロー制御メカニズムが最初の送信と同様に再送をスロットル化するという意味で、フロー制御と連動して動作します。

• ストリーミングのサポート オーディオなどのストリーミングアプリケーションでは、合意されたデータレートでL2CAPチャネルを設定するため、コントローラ内のフロー制御メカニズムを含め、データの流れを変化させたくありません。 フラッシュ タイムアウトは、送信側でデータの流れを維持するために使用されます。 ストリーミングモードは、受信側でのHCIおよびコントローラベースのフロー制御の適用を停止するために使用されます。

• フラグメンテーションとリコンビネーション 一部のコントローラは、伝送能力が制限されている場合があり、L2CAPセグメンテーションによって作成されたフラグメントサイズとは異なるフラグメントサイズを必要とする場合があります。 そのため、L2CAP以下のレイヤは、各レイヤの能力に適合するフラグメントを作成するために、L2CAP PDUをさらにフラグメント化して再結合することがあります。 L2CAP PDUの送信中に、フラグメント化および再結合の多くの異なるレベルが両方のピアデバイスで発生する可能性がある。

HCI ドライバまたはコントローラは、ホスト コントローラ インタフェース トランスポート スキームのパケット サイズ制約を考慮して、L2CAP PDU をフラグメント化することがあります。 これにより、HCI データ パケット ペイロードには、L2CAP PDU の開始フラグメントと継続フラグメントが含まれます。 同様に、コントローラは、L2CAP PDUをフラグメント化して、コントローラパケットにマッピングすることができます。 これにより、L2CAP PDUの開始フラグメントと継続フラグメントを含むコントローラパケットのペイロードが生成される場合があります。

プロトコルスタックの各レイヤは、L2CAP PDUの異なるサイズのフラグメントを渡してもよく、レイヤによって作成されたフラグメントのサイズは、各ピアデバイスで異なっていてもよい。 PDUがスタック内で断片化されていても、受信側のL2CAPエンティティは、元のL2CAP PDUを得るために断片を再結合します。

• サービスの質 L2CAP 接続確立プロセスでは、2 台の Bluetooth デバイス間で期待されるサービス品質（QoS）に関する情報を交換することができます。 各 L2CAP 実装は、プロトコルで使用されるリソースを監視し、QoS 契約が確実に履行されるようにします。

BR/EDRまたはBR/EDR/LEコントローラの場合、L2CAPは、HCI ACLデータパケット内のPacket_Boundary_Flagに適切な値を設定することで、パケットを自動的にフラッシュ可能または非自動的にフラッシュ可能としてマークすることで、同一のACL論理リンク上の等時性データフロー（Guaranteed）と非同期データフロー（Best Effort）の両方をサポートすることができます（[Vol.2]パートE、セクション3.3を参照）。 自動フラッシュ可能なL2CAPパケットは、L2CAPチャネルがマッピングされているACL論理リンクに設定された自動フラッシュタイムアウトに従ってフラッシュされます（[Vol.2]パートE、3.3節参照）。 自動的にフラッシュされないL2CAPパケットは、自動フラッシュ タイムアウトの影響を受けず、フラッシュされません。 すべてのL2CAPパケットは、HCI_Flushコマンドを使用してフラッシュすることができます（[Vol.2]パートE、セクション3.3参照）。

AMPコントローラの場合、L2CAPは、単一の論理リンク（アグリゲーション）を介して、同じリモートデバイスに向かうすべての非同期データフローを配置します。 L2CAPは、各アイソクロナスデータフローを独自の論理リンク上に配置します。

1.2 ASSUMPTIONS

プロトコルは以下の前提に基づいて設計されています。

1. コントローラは、個々のパケットの破損や重複はあるかもしれませんが、データパケットの整然とした配信を提供します。 BR/EDRまたはBR/EDR/LEコントローラを持つデバイスの場合、2つのデバイス間に1つ以上のACL-U論理リンクは存在しません。 特定のAMPコントローラを持つデバイスの場合、2つのデバイス間に1つ以上のAMP-U論理リンクが存在する可能性があります。 BR/EDR/LE または LE コントローラを搭載したデバイスの場合、2 台のデバイス間には LE-U 論理リンクは 1 つ以上存在しません。

2. コントローラは常に全二重通信チャネルの印象を与えます。 これは、すべてのL2CAP通信が双方向であることを意味するものではありません。 一方向トラフィックには、二重チャネルは必要ありません。

3. L2CAP レイヤーは、コントローラで利用可能なメカニズムに基づいて、拡張 L2CAP レイヤーで有効にできる追加のパケットセグメンテーション、エラー検出、および再送に基づいて、ある程度の信頼性を持つチャネルを提供します。 一部のコントローラは、データの整合性チェックを実行し、正常に確認されるかタイムアウトが発生するまでデータを再送します。 他のコントローラは、一定回数までデータを再送し、データがフラッシュされます。 確認応答が失われることがあるため、データが正常に送信された後でもタイムアウトが発生することがあります。

注：BR/EDRまたはBR/EDR/LEコントローラでベースバンドブロードキャストパケットを使用することは信頼性が低く、すべてのブロードキャストは、同じシーケンスビットでL2CAPパケットの最初のセグメントを開始します。

4. コントローラは、空中を通過するデータに対してエラーおよびフロー制御を提供し、HCIフロー制御はHCIトランスポートを通過するデータに対して存在しますが、一部のアプリケーションでは、一部のコントローラが提供するよりも優れたエラー制御を必要とする場合があります。 また、コントローラ間でチャネルを移動するには、L2CAP フローとエラー制御が必要です。 フローおよびエラー制御ブロックは、4つのモードを提供します。 エンハンスト再送モードと再送モードは、セグメンテーション、フロー制御、およびL2CAP PDU再送を提供します。 フロー制御モードは、セグメンテーションとフロー制御機能のみを提供します。 ストリーミング・モードは、セグメンテーションと受信機側パケット・フラッシングを提供します。

1.3 SCOPE

以下の機能は、L2CAP の責任範囲外です。

• L2CAPは、SCOまたはeSCO論理トランスポートに指定された同期データをトランスポートしません。
• L2CAPは、信頼性の高いブロードキャストチャネルをサポートしていません。セクション 3.2 を参照してください。

1.4 TERMINOLOGY

以下の形式的な定義が適用されます。

-- Table 1.1: Terminology --

2 GENERAL OPERATION

L2CAP は、「チャンネル」という概念に基づいています。 L2CAP チャネルの各エンドポイントは、チャネル識別子（CID）によって参照されます。

2.1 CHANNEL IDENTIFIERS

チャネル識別子(CID)は、デバイス上の論理チャネルのエンドポイントを表すローカル名です。 CIDの範囲は図2.1に示すように論理リンクに関連する。 ヌル識別子(0x0000)は、決してデスティネーションエンドポイントとして使用してはならない。 0x0001～0x003F の識別子は、特定の L2CAP 機能のために予約されている。 これらのチャネルは、固定チャネルと呼ばれる。 最低限、L2CAP シグナリングチャネル（固定チャネル 0x0001）または L2CAP LE シグナリングチャネル（固定チャネル 0x0005）をサポートするものとする。 固定チャネル 0x0005 がサポートされている場合は、固定チャネル 0x0004 および 0x0006 がサポートされるものとする（表 2.2 を参照）。 その他の固定チャネルをサポートしてもよい。 リモートデバイスが ACL-U 論理リンク上でどの固定チャネルをサポートしているかを決定するために、 情報要求/応答メカニズム(セクション 4.10 及びセクション 4.11)を使用する。

各固定チャネルの特性は、チャネルごとに定義される。 固定チャネルの特性には、構成パラメータ（信頼性、MTU サイズ、QoS など）、セキュリ ティ、L2CAP 構成メカニズムを使用したパラメータ変更機能などがある。 表 2.1 に、定義されている固定チャネルの一覧を示し、関連するチャネル特性が定義されている場所を参照し、チャネルが動作する論理リンクを指定します。 固定チャネルは、ACL-U または LE-U 論理リンクがセットアップされるとすぐに利用可能になります。 チャネルが作成されたときに通常実行されるすべての初期化は、ACL-UまたはLE-U論理リンクが設定されたときに、サポートされている固定チャネルのそれぞれに対して実行されなければならない。 固定チャネルは、ACL-U、ASB-U、またはLE-U論理リンク上でのみ動作し、移動してはならない。

実装は、2 つの同時にアクティブな L2CAP チャネルが同じ CID を共有してはならないとの規定のもと、その特定の実装に最適な方法で、残りの CID を自由に管理することができます。 ACL-U、ASB-U、および LE-U 論理リンクごとに、異なる CID 名空間が存在します。 AMP-U 論理リンクは、関連する ACL-U 論理リンクと CID ネームスペースを共有します。 表 2.1 と表 2.2 に、各論理リンクの CID ネームスペースの定義とパーティショニングをまとめます。

-- Figure 2.1: Dynamically allocated CID assignments --

動的に割り当てられたＣＩＤの割り当ては、特定の論理リンクに対する相対的なものであり、デバイスは他のデバイスから独立してＣＩＤを割り当てることができる。 したがって、単一のローカルデバイスに接続された複数のリモートデバイスによって（リモート）チャネルエンドポイントに同じＣＩＤ値が割り当てられた場合でも、ローカルデバイスは、各リモートＣＩＤを異なるデバイスに一意に関連付けることができる。 さらに、同じリモートデバイスによって同じＣＩＤ値が（リモート）チャネルエンドポイントに割り当てられている場合でも、これらは異なる論理リンクにバインドされるため、区別することができる。

ACL-U、ASB-U、AMP-U 論理リンクの CID 名空間は以下の通りです。

-- Table 2.1: CID name space on ACL-U, ASB-U, and AMP-U logical links --

LE-U 論理リンクの CID 名空間は以下の通りです。

-- Table 2.2: CID name space on LE-U logical link --

2.2 OPERATION BETWEEN DEVICES

図 2.2 は、個別のデバイス内の対応するピア L2CAP エンティティ間の通信における CID の使用を示しています。 コネクション指向のデータ チャネルは、2 つのデバイス間の接続を表し、論理リンクと組み合わせた CID は、チャネルの各エンドポイントを識別します。 ブロードキャスト伝送に使用する場合、コネクションレス チャネルは、データ フローを単一の方向に制限します。 コネクションレス チャネルは、アクティブ ブロードキャストを使用して、すべてのアクティブ スレーブにデータを送信するために使用することができます。 ユニキャスト伝送に使用する場合、コネクションレスチャネルはマスターとスレーブの間でどちらの方向にも使用できます。

また、特別な目的のために予約された多数のCIDもあります。 L2CAP 信号チャネルは、予約チャネルの例です。 固定チャネル 0x0001 は、コネクション指向のデータチャネルを作成して確立し、コネクション指向チャネルの特性の変更をネゴシエートし、ACL-U 論理リンク上で動作するコネクションレスチャネルの特性を発見するために使用されます。

L2CAPシグナリングチャネル（0x0001）とサポートされているすべての固定チャネルは、2つのデバイス間でACL-U論理リンクが確立されるとすぐに利用可能になります。 別の CID（0x0002）は、ブロードキャストまたはユニキャストにかかわらず、すべての着信および発信のコネクションレス・データ・トラフィック用に予約されています。 コネクションレス データ トラフィックは、2 つのデバイス間で ACL-U 論理リンクが確立され、送信デバイスがリモート デバイスがコネクショ ンレス トラフィックをサポートしていると判断すると、すぐに流れる可能性があります。

L2CAP LEシグナリング チャネル（0x0005）とサポートされているすべての固定チャネルは、2つのデバイス間でLE-U論理リンクが確立されると、すぐに利用可能になります。

-- Figure 2.2: Channels between devices --

表 2.3 に、各種チャネルタイプとそのソース及びデスティネーション識別子を示す。 動的に割り当てられた CID は、論理リンクとともにローカルエンドポイントを識別するために割り当てられ、ACL-U では 0x0040～0xFFFF、LE-U では 0x0040～0x007F の範囲とする。 セクション 6 では、動的に割り当てられた CID を持つ各接続指向チャネルに関連付けられたステートマシンを記述する。 3.1 節と 3.3 節では、接続指向チャネルに関連付けられたパケットフォーマットについて説明する。 セクション3.2では、コネクションレスチャネルに関連付けられたパケットフォーマットについて記述する。

-- Table 2.3: Types of channel identifiers --

2.3 OPERATION BETWEEN LAYERS L2CAP の実装は、以下に説明する一般的なアーキテクチャに従う必要があります。 L2CAP 実装は、上位層プロトコルと下位層プロトコルの間でデータを転送します。 このドキュメントでは、L2CAP 実装によってエクスポートされるべきサービスの数を列挙します。 各実装は、L2CAP 実装間で使用するシグナリングコマンドのセットもサポートするものとする。 また、L2CAP 実装は、下位レイヤから特定のタイプのイベントを受け入れ、上位レイヤへのイベントを生成できるように準備しておく必要があります。 これらのイベントがレイヤー間でどのように受け渡されるかは、実装固有のものです。

-- Figure 2.3: L2CAP transaction model --

2.4 MODES OF OPERATION

L2CAPチャンネルは、各L2CAPチャンネルで選択された5つの異なるモードのいずれかで動作します。

モードは以下のとおりです。

• 基本L2CAPモード（Bluetooth v1.1のL2CAP仕様と同等） 1
• フロー制御モード
• 再送モード
• 拡張再送信モード
• ストリーミングモード
• LEクレジットベースのフロー制御モード 各モードは、7.1 節に記載された設定手順を使用して有効にする。 基本 L2CAP モードは、他のモードが合意されていない場合に使用されるデフォルトモードとする。 Enhanced Retransmission モードは、AMP-U 論理リンク上に作成されたすべての信頼性の高いチャネルと、7.10 節で説明したように動作する ACL-U 論理リンクに対して使用する。 拡張再送モードは、セクション7.10で説明したように動作していないACL-U論理リンク上に作成された信頼性の高いチャネルに対して有効にすべきである。 ストリーミングモードは、セクション7.10で説明したように動作するAMP-U論理リンク及びACL-U論理リンク上に作成されたストリーミングアプリケーションに使用すること。 ストリーミングモードは、セクション7.10で説明したように動作していないACL-U論理リンク上で作成されたストリーミングアプリケーションに対して有効にすること。 L2CAP エンティティの両方でサポートされている場合は、拡張再送モードまたはストリーミング モードのいずれかを有効にする必要があります。 フロー制御モードおよび再送モードは、拡張再送モードまたはストリーミングモードのいずれもサポートしていない L2CAP エンティティと通信する場合にのみ有効にするものとする。

フロー制御モード、再転送モード、および拡張再転送モードでは、ピア・エンティティとの間で交換されたPDUには番号が付けられ、確認される。 PDU内のシーケンス番号は、バッファリングを制御するために使用され、TxWindowサイズは、必要なバッファ空間を制限するため、および／またはフロー制御のための方法を提供するために使用される。

フロー制御モードでは、再送は行われないが、欠落したＰＤＵは検出され、紛失として報告されることがある。

再送モードでは、必要に応じてＰＤＵを再送することにより、すべてのＰＤＵがピアに配信されることを保証するためにタイマーが使用される。 go-back-nリピートメカニズムは、プロトコルを単純化し、バッファリング要件を制限するために使用されます。

拡張再送モードは、再送モードに似ています。 リモート L2CAP エンティティからの応答を要求するために POLL ビットを設定する機能が追加され、エラー回復の効率を向上させるために SREJ S フレームが追加され、ローカルビジー状態を報告するために R ビットを置き換えるために RNR S フレームが追加されます。

ストリーミング モードは、リアルタイム アイソクロナス トラフィック用です。 PDUには番号が付けられていますが、確認はされません。 送信側では、タイムリーに送信されないパケットをフラッシュするために、有限のフラッシュタイムアウトが設定されています。 受信側では、新しいPDUを受信したときに受信バッファが一杯になると、以前に受信したPDUが新しく受信したPDUに上書きされます。 欠落した PDU を検出し、紛失として報告することができます。 TxWindow サイズは、ストリーミング モードでは使用されません。

注：ACL-U 論理リンク上で動作する L2CAP チャネルには、L2CAP Basic モードを使用することができますが、Enhanced Retransmission モードまたは Streaming モードを使用するように設定されている L2CAP チャネルのみを、AMP-U 論理リンク上で動作するように移動することができます。 (セクション 4.16 を参照)。

LEクレジット・ベース・フロー・コントロール・モードは、LE L2CAP接続指向チャネルで、L2CAPデータ（すなわち、シグナリング・パケットではない）のクレジット・ベース・スキームを使用したフロー制御のために使用されます。 これは、LE L2CAP 接続指向チャネルに使用する唯一のモードです。

RFCOMM などの多重化レイヤに使用される L2CAP チャネルは、さまざまな上位レイヤのプロトコルを提供することができる。 ローカルデバイスとリモートデバイスが、信頼性が要求される多重化レイヤ（RFCOMM など）上のプロファイルに対する AMP の相互サポートと相補的なサポートを有する場合、多重化レイヤは、マルチプレクサを利用するプロファイルが AMP-U 論理リンクに移動されるのを妨げられないように、エンハンスト再送信モードを使用するように構成されるべきである。 同様に、ローカルデバイスとリモートデバイスが相互にAMPをサポートし、信頼性を必要としない多重化レイヤ上のプロファイルを補完的にサポートしている場合には、多重化レイヤはストリーミングモードを使用して、マルチプレクサを利用するプロファイルがAMP-U論理リンクに移動するのを妨げないように構成する必要があります。

レガシープロファイル実装の下でエンハンスト再送信モードとストリーミングモードを使用する場合は、ACL-U論理リンク上でベーシックモードで同じプロファイルを使用した場合のパフォーマンスと比較して、パフォーマンスに悪影響を及ぼさないように、パラメータの選択に注意が必要です。 相互にサポートされるAMPが存在しない場合や、AMPの恩恵を受けるであろうプロファイルの補完的なサポートが存在しない場合は、パフォーマンスへの負の影響のリスクを最小限に抑えるためにBasicモードを構成することが望ましい場合があります。

2.5 MAPPING CHANNELS TO LOGICAL LINKS

L2CAPは、チャネルをコントローラの論理リンクにマッピングし、コントローラの物理リンク上で実行します。 ローカル コントローラとリモート コントローラ間を結ぶすべての論理リンクは、単一の物理リンク上で実行されます。 BR/EDR 物理リンクごとに ACL-U 論理リンクが 1 つ、LE 物理リンクごとに LE-U 論理リンクが 1 つあり、AMP 物理リンクごとに AMP-U 論理リンクが複数ある場合もあります。

2つのデバイス間のBR/EDR物理リンクを経由するすべてのベストエフォートチャネルとギャランティードチャネルは、1つの ACL-U論理リンクにマッピングされなければならない。 2 つのコントローラ間の AMP 物理リンクを通過するすべてのベストエフォートチャネルは、1 つの AMP-U 論理リンクにマッピングされるものとし、2 つのコントローラ間を通過する各ギャランティードチャネルは、1 つのギャランティードチャネルにつき 1 つの AMP-U 論理リンクを持つ独自の AMP-U 論理リンクにマッピングされるものとします。 2 つのデバイス間の LE 物理リンクを経由するすべてのチャネルは、ベストエフォートとして扱われ、単一の LE-U 論理リンクにマッピングされるものとする。

保証チャネルがコントローラに作成または移動された場合は、対応する保証論理リンクを作成し、チャネルトラ フィックを伝送するものとする。 Guaranteed 論理リンクの作成には、アドミッション制御が含まれます。 アドミッション制御とは、既存の保証を損なうことなく保証が達成できることを検証することである。 AMP コントローラの場合、L2CAP は、コントローラに対して Guaranteed 論理リンクの作成を指示し、コントローラがアドミッション制御を行う。 BR/EDR コントローラの場合、アドミッション制御（Guaranteed 論理リンクの作成）は、L2CAP レイヤが行うものとする。