3.1 CORE TRAFFIC BEARERS

Bluetoothコアシステムは、サービスプロトコルおよびアプリケーションデータの転送のための多数の標準トラフィックベアラを提供します。 これらは以下のFigure 3.2に示されています（表現を簡単にするために、これは左のレイヤと下のレイヤの上位レイヤで示されています）。

Figure 3.2　Bluetooth traffic bearers

アプリケーションで使用できるコアトラフィックベアラは、Figure 3.2に斜線の丸い四角で示されています。 これらのサービスを提供するために定義されたアーキテクチャレイヤについては、第2章で説明します。 データトラフィックタイプの多くは、通常、そのタイプのデータトラフィックの転送に適しているトラフィックベアラにリンクされています。

論理リンクの名前は、関連する論理トランスポートの名前と、転送されるデータのタイプを示す接尾辞を使用して命名されます。 （LMPまたはLLメッセージを運ぶ制御リンクの場合はC、 ユーザデータ(L2CAP PDUs)を伝送するL2CAPリンクの場合はU、 フォーマットされていない同期またはアイソクロナスデータを伝送するストリームリンクの場合はS） あいまいさを導入することなく、論理リンクから接尾辞を削除するのは一般的です、 したがって、デフォルトACL論理トランスポートへの参照は、 LMPプロトコルが議論されている場合はACL-C論理リンク、 LLプロトコルが議論されている場合はLE-C論理リンク、 PALプロトコルが議論されている場合はAMP-C論理リンク、 L2CAPレイヤが議論されている場合は、ACL-U、LE-U、またはAMP-U論理リンクを使用します。

Figure 3.2のアプリケーショントラフィックタイプのBluetoothコアトラフィックベアラへのマッピングは、トラフィック特性をベアラ特性と照合することに基づいています。 これらのマッピングを使用することをお勧めします。これらのマッピングは、データを特定の特性でもって輸送する最も自然で効率的な方法を提供します。

しかし、アプリケーション（またはBluetoothコアシステムの実装）は、異なるトラフィックベアラを使用するか、または異なるマッピングを使用して同様の結果を得ることができます。 たとえば、スレーブが1つだけのBR/EDRピコネットでは、マスタはASB-U論理リンクではなくACL-U論理リンクを介してL2CAPブロードキャストを転送することを選択できます。 これは、おそらく帯域幅の点でより効率的です（物理チャネル品質がそれほど劣化していない場合）。 Figure 3.2のものへの代替の輸送経路の使用は、アプリケーショントラフィックタイプの特性が保持されている場合にのみ許容されます。

Figure 3.2に、さまざまなアプリケーショントラフィックタイプを示します。 これらは、Bluetoothコアシステムに送信されるデータの種類を分類するために使用されます。 介入するプロセスを修正する場合、元のデータトラフィックタイプは、Bluetoothコアシステムに送信されるタイプと異なる場合があります。 例えば、ビデオデータは一定のレートで生成されるが、中間のコーディングプロセス、MPEG4エンコーディングによって、これを可変レートに変更してもよいです。 Bluetoothコアシステムの目的のために、提出されたデータの特性のみが重要です。

3.1.1 Framed Data Traffic

L2CAPレイヤサビスは、非同期および等時性のユーザーデータ用のフレーム指向のトランスポートを提供します。 アプリケーションは、可変サイズのフレームでこのサービスにデータを送信し（チャネルの最大ネゴシエーション）、これらのフレームは、リモートデバイス上の対応するアプリケーションに同じ形式で配信されます。 アプリケーションに追加のフレーミング情報をデータに挿入する必要はありませんが、これが必要な場合（フレーミングがBluetoothコアシステムには見えません）、そうすることもできます。

2つのBluetoothデバイス間のユニキャスト（ポイントツーポイント）データの転送用に、接続指向のL2CAPチャネルを作成できます。 接続指向のチャネルは、チャネル上で転送されるデータに特定のプロパティを適用できるコンテキストを提供します。 例えば、サービス品質パラメータまたはフローおよびエラー制御モードが適用されてもよいです。 接続指向のL2CAPチャネルは、L2CAP接続手順を使用して作成されます。

コネクションレスBR/EDR L2CAPチャネルは、データのブロードキャストまたはユニキャストデータの転送のために存在します。 ピコネットトポロジーの場合、マスタデバイスは常にブロードキャストデータのソースであり、スレーブデバイスは受信者です。 コネクションレスL2CAPチャネルのブロードキャストトラフィックは一方向です。 コネクションレスL2CAPチャネル上で送信されるユニキャストデータは、一方向性または双方向性となります。 L2CAPコネクションレスチャネルで送信されるユニキャストデータは、L2CAP接続指向チャネルを開くことによって発生する追加レイテンシなしで、Basicモードで動作するL2CAPコネクション指向チャネルと同じレベルの信頼性でデータを送信する代替メカニズムを提供します。 LE L2CAPコネクションレスチャネルはサポートされていません。

BR/EDR L2CAPチャネルには、データフレームの配信に関する制約を定義する関連するQoS設定があります。 これらのQoS設定は、（例えば）データがアイソクロナスであることを示すために使用されてもよく、 寿命が限られて無効になったり、所定の期間内にデータを配信したり、データが信頼でき、エラーなく配信される必要がありますが、これには時間がかかります。

一部のL2CAPチャネルは、ACL-Uおよび/またはLE-U論理リンクが確立されたときに作成される固定チャネルです。 これらの固定チャネルは、固定チャネル構成と固定構成を持ち、作成後の構成のネゴシエーションを許可しません。 これらの固定チャネルは、BR/EDRおよびLE L2CAPシグナリング（ACL-UまたはLE-U）、コネクションレスチャネル（ACL-UおよびASB-U）、AMPマネージャプロトコル（ACL-U）、セキュリティマネージャプロトコル（LE-U）、属性プロトコル（ACL-UまたはLE-U）、およびAMPテストマネージャ（ACL-U）をサポートします。

L2CAPチャネルマネージャは、L2CAPチャネルデータフレームを適切なベースバンド論理リンク上に転送するように構成し、おそらくこれを同様の特性を有する他のL2CAPチャネルとベースバンド論理リンク上に多重化します。

3.1.2 Unframed Data Traffic

アプリケーションがインストリーム・フレーミングを含んでいる可能性があるため、アプリケーションがフレーム内のデータ配信を必要としない場合、またはデータが純粋なストリームであるため、L2CAPチャネルの使用を回避し、ベースバンド論理リンクを直接使用できます。

Bluetoothコアシステムは、SCO-SまたはeSCO-S論理リンクを使用して、アイソクロナスで一定のレート（ビットレートまたはフレームレートのプリフレームデータ）のアプリケーションデータの直接転送をサポートします。 これらの論理リンクは、物理チャネル帯域幅を予約し、ピコネットクロックにロックされた一定レートのトランスポートを提供します。 データは固定された間隔で固定サイズのパケットで転送され、チャネル確立中にこれらのパラメータの両方がネゴシエートされます。 eSCOリンクは、ビットレートのより大きな選択肢を提供し、エラーの場合には限定された再送信を使用することにより、より大きな信頼性を提供します。 Enhanced Data RateオペレーションはeSCOではサポートされていますが、SCO論理トランスポートではサポートされていません。 SCOおよびeSCO論理トランスポートは、多重化論理リンクまたはBluetoothコア内のそれ以上のレイヤリングをサポートしていません。アプリケーションは、提出されたストリームが一定のレートのストリームであるか、または一定のレートのストリームであると仮定すれば、提出されたSCO/eSCOストリーム内のいくつかのストリームをレイヤすることを選択することができます。

Bluetoothコアシステムは、プロファイルブロードキャストデータ（PBD）論理リンクを使用してアプリケーションデータを直接転送することもサポートしています。 この論理リンクは、物理チャネル帯域幅を予約し、ピコネットクロックにロックされた一定レートの転送を提供し、一定間隔でデータを転送するため、SCO-SおよびeSCO-Sに似ています。 SCO-SやeSCO-Sとは異なり、多重化された論理リンクやBluetoothコア内のレイヤリングはサポートされていません。

アプリケーションは、ベースバンドで使用可能なものから最も適切なタイプの論理リンクを選択し、データストリームを転送するように作成および設定し、完了したら解放します。 （アプリケーションは通常、フレーム化されたL2CAPユニキャストチャネルを使用して、Cプレーン情報をリモートデバイスのピアアプリケーションに転送します。）

アプリケーションデータがアイソクロナスであり、可変レートの場合、これはL2CAPユニキャストチャネルによってのみ運ばれるため、フレームデータとして扱われます。

Unframedデータトラフィックは、LEシステムではサポートされていません。

3.1.3 Reliability of Traffic Bearers

3.1.3.1 BR/EDR Reliability

Bluetoothは無線通信システムです。 劣悪なRF環境では、このシステムは本質的に信頼性が低いと考えられるべきです。 これに対抗するために、システムは各層で保護レベルを提供します。 ベースバンドパケットヘッダは、受信機による誤り訂正を可能にする順方向誤り訂正（FEC）符号化と、訂正後に残る誤りを検出するヘッダ誤り検査（HEC）を使用する。 特定のベースバンドパケットタイプには、ペイロードのFECが含まれます。 さらに、いくつかのベースバンドパケットタイプは、巡回冗長エラーチェック（CRC）を含みます。

ACL論理トランスポートのエラー検出アルゴリズムの結果は、単純なARQプロトコルを駆動するために使用されます。 これは、受信機のエラーチェックアルゴリズムをパスしないパケットを再送信することにより、信頼性を高めます。 このスキームを変更して、パケットの耐用年数が満了した場合に送信機で送信に失敗したパケットを破棄することによって、待ち時間に敏感なパケットをサポートすることが可能です。 eSCOリンクは、このスキームの修正バージョンを使用して、限定された数の再送信を可能にすることによって信頼性を向上させます。

このARQスキームによって得られる結果の信頼性は、エラーを検出するHECおよびCRCコードの能力と同様に信頼できるものです。 ほとんどの場合、これで十分ですが、長いパケットタイプの場合、検出されないエラーの確率は、典型的なアプリケーション、特に大量のデータが転送されるアプリケーションをサポートするには高すぎます。

L2CAPレイヤは、ベースバンドレイヤで時々検出されないエラーを検出し、影響を受けたデータの再送信を要求するように設計された追加レベルのエラー制御を提供します。 これにより、一般的なBluetoothアプリケーションで必要とされるレベルの信頼性が提供されます。

ブロードキャストリンクはフィードバックルートを持たず、ARQ方式を使用することはできません（ただし、受信側は受信パケット内のエラーを検出できます）。 代わりに、各パケットは、受信機が少なくとも1つのコピーをうまく受信できることを期待して複数回送信されます。 このアプローチにもかかわらず、成功した受領の保証はまだないので、これらのリンクは信頼できないと考えられます。

要約すると、リンクまたはチャネルが信頼できると特徴付けられる場合、これは、受信機が受信パケットのエラーを検出し、エラーが除去されるまで再送信を要求できることを意味します。 使用された誤り検出システムのために、受信したデータには依然として若干の残存（検出されない）誤りが残ることがあります。 L2CAPチャネルの場合、これらのレベルは他の通信システムに匹敵しますが、論理リンクでは残留エラーレベルはやや高くなります。

送信機は、受信機がシーケンス内のすべてのパケットを受信しないように、送信キューからパケットを除去することができます。 この場合、行方不明パケットの検出はL2CAPレイヤに委任されます。 ほとんどの場合、これで十分ですが、長いパケットタイプの場合、検出されないエラーの確率は、典型的なアプリケーション、特に大量のデータが転送されるアプリケーションをサポートするには高すぎます。

信頼性の低いリンクでは、受信機は受信パケットのエラーを検出することができますが、再送信を要求することはできません。 受信者が渡したパケットにエラーはないかもしれませんが、シーケンス内のすべてのパケットが受信されるという保証はありません。 したがって、リンクは基本的に信頼性が低いと考えられます。 このようなリンクの使用は限られており、通常、上位層からのデータが有効である間は、そのデータの連続的な繰り返しに依存します。

ストリームリンクは、現在の動作状態に応じて、信頼できるリンクと信頼できないリンクとの間のどこかに信頼性特性を有します。

3.1.3.2 LE Reliability

BR/EDRのように、劣悪なRF環境では、LEシステムは本質的に信頼性が低いと考えられるべきです。 これに対抗するために、システムは各層で保護レベルを提供します。 LLパケットは、パケットペイロードの内容をカバーするために24ビットの巡回冗長エラーチェック（CRC）を使用します。 CRC検証がパケットペイロードで失敗すると、パケットは受信側によって確認応答されず、パケットは送信側によって再送されます。

ブロードキャストリンクはフィードバック経路を持たず、（受信機は依然として受信パケット内のエラーを検出することができるが）肯定応答方式を使用することはできない。 代わりに、各パケットは、受信機が少なくとも1つのコピーを首尾よく受信することができる確率を高めるために、複数回送信されます。 このアプローチにもかかわらず、成功した受領の保証はまだないので、これらのリンクは信頼できないと考えられます。

要約すると、リンクまたはチャネルが信頼できると特徴付けられる場合、これは、受信機が受信パケットのエラーを検出し、エラーが除去されるまで再送信を要求できることを意味します。

信頼性の低いリンクでは、受信機は受信パケットのエラーを検出することができますが、再送信を要求することはできません。 受信者が渡したパケットにエラーはないかもしれませんが、シーケンス内のすべてのパケットが受信されるという保証はありません。 したがって、リンクは基本的に信頼性が低いと考えられます。 このようなリンクの使用は限られており、通常、上位層からのデータが有効である間は、そのデータの連続的な繰り返しに依存します。

3.1.3.3 AMP Reliability

各AMPの信頼性は、基礎となるMAC/PHY技術に依存します。 一部のAMPは、フラッシュとしてマークされている場合にのみユーザートラフィックをフラッシュしますが、他のAMPではユーザートラフィックをフラッシュできます。

Bluetoothコアは、AMP上で使用されるL2CAPチャネルに対して拡張再送信モードまたはストリーミングモードの使用を強制することにより、コア上のプロトコルおよびプロファイルの信頼性レベルを維持します。