コア アーキテクチャのブロック
目次
コア システムの定義Bluetooth コア システムは、Bluetooth 仕様で定義されている 4 つの下位レイヤとそれに関連するプロトコルを対象にしています。さらに、1 つの共通サービス レイヤ プロトコル、サービス検索プロトコル (SDP)、およびプロファイル全体の要件が一般アクセス プロファイル (GAP) で指定されています。完全な Bluetooth アプリケーションには、Bluetooth 仕様で定義されているいくつかの追加サービスと上位レイヤ プロトコルが必要です。
Bluetooth コントローラ3 つの下位レイヤは、Bluetooth コントローラと呼ばれるサブシステムにグループ化されることがあります。これは一般的な実装方法で、Bluetooth コントローラと、Bluetooth ホストと呼ばれるその他の Bluetooth システム (L2CAP、サービス レイヤ、上位レイヤなど) との標準的な物理通信インタフェースが必要です。このインタフェースはオプションですが、このインタフェースが存在することとその特徴を考慮して設計されています。Bluetooth 仕様を使用して、同等のレイヤ間で交換するプロトコル メッセージを定義することで、独立した Bluetooth 対応システム間で相互運用することができます。また、Bluetooth コントローラと Bluetooth ホスト間に共通インタフェースを定義することで、独立した Bluetooth サブシステム間で相互運用することもできます。
こうしたシステム間には、多数の機能ブロック、サービスとデータのパスがあります。この機能ブロックは参考情報です。一般的に、相互運用性に必要な場合を除き、Bluetooth 仕様では詳細な実装方法は定義されません。
コア システムのプロトコルとシグナリングすべてのデバイス間操作について、標準の対話方法が定義されています。デバイス間操作を行う場合、Bluetooth デバイスは Bluetooth 仕様に従ってプロトコル シグナリングを交換します。Bluetooth コア システムのプロトコルは、無線 (RF) プロトコル、リンク制御 (LC) プロトコル、リンク マネージャ (LM) プロトコル、論理リンク制御および適合プロトコル (L2CAP) です。いずれも、Bluetooth 仕様の以降の部分で定義されています。また、サービス検索プロトコル (SDP) は、すべての Bluetooth アプリケーションに必要なサービス レイヤ プロトコルです。
Bluetooth コア システムでは、上図で楕円形で示されている多数のサービス アクセス ポイントを経由してサービスを提供します。このサービスは、Bluetooth コア システムを制御する基本プリミティブから構成されます。このサービスは 3 種類に分類できます。Bluetooth デバイスの動作とモードを変更するデバイス制御サービス、トラフィック経路 (チャネルとリンク) の作成、変更、解放を行うトランスポート制御サービス、トラフィック経路で伝送するデータを提供するデータ サービスの 3 つです。一般的に、最初の 2 つのサービスは C-plane に所属し、最後のサービスは U-plane に所属します。
ホスト コントローラ インタフェース (HCI) : Bluetooth スタックをコントローラとホストに分離 Bluetooth コントローラ サブシステムのサービス インタフェースは、Bluetooth コントローラを標準部品として扱うことができるように定義されています。このような構成の場合、Bluetooth コントローラで 3 つの下位レイヤが操作され、L2CAP レイヤはその他の Bluetooth アプリケーションと共にホスト システムに含まれます。この標準インタフェースはホスト コントローラ インタフェース (HCI) と呼ばれます。この標準サービス インタフェースの実装はオプションです。
Bluetooth アーキテクチャでは、HCI 経由で通信する別個のホストとコントローラを考慮して定義されているため、一般的な想定事項が多数あります。Bluetooth コントローラには、ホストと比較してデータ バッファリング機能が限られていると想定されます。そのため、相手側デバイスに対するトランスポートのコントローラへ L2CAP PDU を送信するときに、L2CAP レイヤで何らかの単純なリソース管理が実行されると考えられます。このとき、L2CAP SDU を管理しやすい PDU に分割してから、コントローラのバッファに適したサイズの開始パケットと連続パケットに PDU を細分化したり、サービス品質 (QoS) の確約と共にチャネルの可用性を確保するためにコントローラのバッファの使用を管理することも考えられます。
L2CAP レイヤのエラー検出ベースバンド レイヤでは Bluetooth 技術の基本 ARQ プロトコルを実現します。L2CAP レイヤでは、オプションで、L2CAP PDU に高度なエラー検出機能や再送信機能を提供できます。この機能は、ユーザー データでエラーが検出されない可能性を低くする必要があるアプリケーションにお勧めします。L2CAP のその他のオプション機能として、受信側デバイスのバッファ割り当て管理に使用できる、ウィンドウベースのフロー制御機能があります。どちらのオプション機能も、状況によっては QoS のパフォーマンスが向上します。
こうした想定は、1 つのシステムにすべてのレイヤを統合している組み込みの Bluetooth 技術実装には不要なこともありますが、汎用的なアーキテクチャのモデルや QoS モデルは、幅広い用途に対応するため、実質的にこの想定を考慮して定義されています。
インタフェースのテスト : RF とテスト制御インタフェース (TCI)Bluetooth コア システムの実装について自動の準拠テストを実行する必要があります。すべての Bluetooth システムに共通の RF インタフェース、および準拠テストにのみ必要なテスト制御インタフェース (TCI) を利用してテスターが実装を制御することで、この準拠テストを実行できます。
テスターは、RF インタフェース経由でテスト対象実装 (IUT) との交換を利用し、リモート デバイスからのリクエストに対して適切に応答できるようにします。RF インタフェース経由の交換についても準拠性を確認するために、テスターは、TCI 経由で IUT を制御して、IUT で RF インタフェース経由の交換を開始するようにします。
TCI では、各アーキテクチャ レイヤとプロトコルをテストするために、さまざまなコマンド セット (サービス インタフェース) が使用されます。Bluetooth コントローラ サブシステム内の各レイヤと各プロトコルごとに、HCI コマンド セットのサブセットが TCI サービス インタフェースとして発行されます。L2CAP レイヤとプロトコルのテストには、別のサービス インタフェースが使用されます。L2CAP サービス インタフェースは Bluetooth コア仕様で定義されていないため、TCI 仕様で別に定義されています。L2CAP サービス インタフェースの実装は、準拠テストの場合にのみ必要です。
先頭へ
コア アーキテクチャのブロック
チャネル マネージャサービス プロトコルとアプリケーション データ ストリームのトランスポートに関する、L2CAP チャネルの作成、管理、破棄は、チャネル マネージャの役割です。チャネル マネージャは、L2CAP プロトコルを使用してリモート (相手側) デバイスのチャネル マネージャと対話して L2CAP チャネルを作成し、それぞれのエンドポイントを適切なエンティティに接続します。チャネル マネージャは、ローカルのリンク マネージャと対話して (必要に応じて) 新しい論理リンクを作成し、このリンクを構成してトランスポートするデータの種類に必要な QoS を実現します。
L2CAP リソース マネージャPDU 区分をベースバンドに提示する順序の管理、チャネル間の相対的なスケジュール作成は、L2CAP リソース マネージャ ブロックの役割です。これは、Bluetooth コントローラのリソースが足りないために、QoS が確約された L2CAP チャネルから物理チャネルにアクセス拒否されないようにするためです。このような処理が必要なのは、Bluetooth コントローラのバッファリングに制限がないこと、または HCI が無限の帯域のパイプであることをアーキテクチャ モデルでは想定していないためです。
L2CAP リソース マネージャは、ネゴシエートした QoS 設定の範囲内で、アプリケーションから L2CAP SDU を確実に送信するために、トラフィック適合措置を実行することもあります。一般的な Bluetooth データ トランスポート モデルでは、仕様どおりに動作するアプリケーションを想定しているため、実装でこのような問題に対処する方法については定義されていません。
デバイス マネージャデバイス マネージャは、Bluetooth 対応デバイスの一般的な動作を制御するベースバンドの機能ブロックです。データ トランスポートに直接関係がない Bluetooth システムの運用でも、たとえば、付近の Bluetooth 対応デバイスを照会する役割、他の Bluetooth 対応デバイスに接続する役割、またはローカルの Bluetooth 対応デバイスを他のデバイスから発見可能または接続可能にする役割があります。
デバイス マネージャは、その機能を実行するために、ベースバンド リソース コントローラからのトランスポート メディアへのアクセス権を要求します。
デバイス マネージャは、多数の HCI コマンドで示されるローカル デバイスの動作も制御します。たとえば、デバイスのローカル名、格納済みのリンク キー、他の機能を管理する場合です。
先頭へ
リンク マネージャリンク マネージャの役割は、論理リンク (必要に応じて関連する論理トランスポートも) の作成、変更、および解放の他に、デバイス間の物理リンクに関連するパラメータの更新です。この処理は、リンク管理プロトコル (LMP) を使用してリモートの Bluetooth デバイスと通信することで実行されます。
LMP は、必要に応じて新規の論理リンクの作成やデバイス間の論理トランスポートの他、リンク属性と伝送属性の一般的な制御も可能です。たとえば、論理伝送の暗号化を有効にすること、物理リンク上の送信電力の適合、論理リンクの QoS 設定の調整などです。
ベースバンド リソース マネージャベースバンド リソース マネージャの役割は、無線メディアへのすべてのアクセス管理です。主に 2 つの機能があります。中心の機能は、アクセス契約をネゴシエートしたすべてのエンティティに対して、物理チャネル上の時間を認めるスケジューラです。もう 1 つの機能は、このようなエンティティとの間でアクセス契約をネゴシエートすることです。アクセス契約とは、事実上、ユーザー アプリケーションが期待されるパフォーマンスを実現する上で必要な、一定の QoS を提供するための確約です。
アクセス契約とスケジュール機能は、Bluetooth 無線の使用を必要とする動作を考慮する必要があります。この場合、たとえば、論理リンクや論理トランスポート上で接続したデバイス間の通常のデータ交換が含まれます。また、問い合わせを実行する無線メディア、接続を確立する無線メディア、発見または接続を可能にする無線メディア、AFH モードの使用時に未使用のキャリアから読み取る無線メディアの利用も含まれます。
場合によっては、論理リンクのスケジュールを指定した結果、以前に使用した物理チャネルとは異なるチャネルに変更されることがあります。変更の理由は、たとえば、スキャッタネット、定期的な照会機能、またはページのスキャンが関係する場合などです。物理チャネルはタイム スロットが調整されていないため、リソース マネージャには、元の物理チャネル上のスロットと新しい物理チャネル上のスロットとで時間を再調整する役割もあります。場合によっては、双方の物理チャネルの参照に、同じデバイスの時計が使用されるため、スロットは自然と調整されることがあります。
リンク コントローラリンク コントローラの役割は、物理チャネル、論理トランスポート、論理リンクに関するデータ ペイロードとパラメータに含まれる Bluetooth パケットのエンコードとデコードです。
リンク コントローラでは、リンク制御のプロトコル シグナリングが実行されます (リソース マネージャのスケジュール機能と密接に連携しています)。このシグナリングは、フロー制御、受領リクエスト、再送信の信号を通信するときに使用されます。このような信号の解釈は、ベースバンド パケットと関連付けられた論理トランスポートの特徴です。通常、リンク制御シグナリングの解釈と制御は、リソース マネージャのスケジューラと関連付けられます。
RFRF ブロックの役割は、物理チャネル上の情報パケットを送受信することです。ベースバンド ブロックと RF ブロック間の制御パスでは、ベースバンド ブロックで RF ブロックのタイミングと周波数のキャリアを制御できるようになっています。RF ブロックでは、物理チャネルやベースバンドから送受信したデータ ストリームが必要な形式に変換されます。
先頭へ
|