Bluetooth Specification 5.0 (Core_v5.0.pdf) の Architecture & Terminology Overview P.166 - P264 の日本語訳です。
- 内容については無保証です。
- 翻訳の間違い等は、twitterのDM等でご連絡をお願いします。
- どうもありがとう Google翻訳
gitbookで編集して公開しました。
https://www.gitbook.com/book/eggman/bluetooth-5-overview/details
以下は下訳です。
Bluetooth無線技術は、ポータブル型および/また据置型電子デバイスを接続するケーブルを置き換えることを目的とした短距離通信システムです。 Bluetooth無線技術の特徴は、堅牢性、低消費電力、低コストです。 コア仕様の多くの機能はオプションであり、製品の差別化を可能にします。
Bluetooth無線技術システムには、基本レート（BR）と低エネルギー（LE）という2つの形式があります。 両方のシステムには、デバイスの検出、接続の確立と接続のメカニズムが含まれています。 基本レートシステムには、オプションのEDR（拡張データレート）と代替メディアアクセス制御（MAC）および物理（PHY）レイヤ拡張が含まれます。 基本レートシステムは、Basic Rateで721.2kb/s、Enhanced Data Rateで2.1Mb/s、802.11 AMPで最大54Mb/sの高速動作を実現します。 LEシステムには、BR/EDRよりも低消費電流、低複雑性、低コストを必要とする製品を実現するための機能が含まれています。 LEシステムは、データレートが低く、デューティサイクルが低いユースケースやアプリケーション用にも設計されています。 ユースケースまたはアプリケーションによっては、任意の部品を含む1つのシステムが他のシステムよりも最適な場合があります。
両方のシステムを実装するデバイスは、両方のシステムを実装する他のデバイスと、どちらかのシステムを実装するデバイスと通信できます。 一部のプロファイルとユースケースは、いずれかのシステムでのみサポートされます。 したがって、両方のシステムを実装するデバイスは、ほとんどのユースケースをサポートする能力を備えています。
Bluetoothコアシステムは、ホストと1つまたは複数のコントローラで構成されています。 ホストとは、コア以外のプロファイルの下にあり、ホストコントローラインターフェイス（HCI）の上にあるすべてのレイヤーとして定義された論理エンティティです。 コントローラは、HCIの下のすべてのレイヤーとして定義された論理エンティティです。 ホストとコントローラの実装には、HCIのそれぞれの部分が含まれている場合があります。 このコア仕様のバージョンでは、プライマリコントローラとセカンダリコントローラの2種類のコントローラが定義されています。
Bluetoothコアのインプリメンテーションには、次のいずれかの構成のプライマリコントローラしかありません。
- ラジオ、ベースバンド、リンクマネージャ、およびオプションでHCIを含むBR/EDRコントローラ。
- LE PHY、Link Layer、およびオプションでHCIを含むLEコントローラ。
- BR/EDRコントローラ部分とLEコントローラ部分（前の2つの箇条書きで識別された部分）を1つのコントローラに統合。
Bluetoothコアシステムは、以下の構成によって記述される1つ以上のセカンダリコントローラをさらに有することができます。
Figure 1.1
Figure 1.2
本書では、Bluetoothシステムアーキテクチャ、通信トポロジ、およびデータトランスポート機能の概要について説明します。 本書のこの巻のテキストは、情報として扱われ、背景や文脈設定のために使用されるべきです。
基本レート / 拡張データレート（BR/EDR）無線（物理層またはPHY）は、2.4 GHzの無免許ISM帯域で動作します。 このシステムは、干渉およびフェージングに対抗するために周波数ホッピングトランシーバを使用し、多くのFHSSキャリアを提供します。 基本レート無線動作は、整形されたバイナリ周波数変調を使用してトランシーバの複雑さを最小限に抑えます。 シンボルレートは1メガビット/秒（Mb / s）のビットレートをサポートする1メガシンボル/秒（Msym / s）、または2Mbpsまたは3Mb / sの総エアビットレートであるエンハンストデータレートを使用します。 これらのモードは、基本レートと拡張データレートとしてそれぞれ知られています。
典型的な動作の間、物理的な無線チャネルは、共通のクロックおよび周波数ホッピングパターンに同期されるデバイスのグループによって共有されます。 1つのデバイスが同期参照を提供し、マスターと呼ばれます。 マスタのクロック周波数ホッピングパターンに同期された他のすべてのデバイスは、スレーブとして知られています。 このように同期されたデバイスのグループは、ピコネットを形成します。 これは、Bluetooth BR/EDR無線技術における基本的な通信形式です。
ピコネット内のデバイスは、特定の周波数ホッピングパターンを使用します。 特定の周波数ホッピングパターンは、Bluetoothアドレスの特定のフィールドとマスタのクロックによってアルゴリズム的に決定されます。 基本的なホッピングパターンは、ISM帯域で79MHzの周波数を1MHz単位で擬似ランダムに並べたものです。 ホッピングパターンは、干渉デバイスによって使用される周波数の一部を除外するために、スレーブ単位で適合させることができます。 適応ホッピング技法は、それらが同じ場所に配置されている場合、静的（非ホッピング）ISMシステムとのBluetooth共存を改善します。
物理チャネルは、スロットと呼ばれる時間単位に細分されます。 データは、これらのスロットに配置されたパケットとしてBluetoothデバイス間で送信されます。 状況が許せば、単一のパケットに多数の連続したスロットを割り当てることができます。 周波数ホッピングは、パケットの送信または受信の間に行ってもよいです。 Bluetooth技術は、時分割複信（TDD）方式を用いて全二重伝送の効果を提供します。
物理チャネルの上には、リンクとチャネルと関連制御プロトコルの層があります。 物理チャネルから物理チャネル、物理リンク、論理トランスポート、論理リンク、L2CAPチャネルまでのチャネルおよびリンクの階層構造。 これらはセクション3.3からセクション3.6でより詳細に議論されますが、ここではこのセクションの残りの部分の理解を助けるために紹介されています。
通常、物理チャネル内では、マスタデバイスとスレーブデバイスとの間に物理的なリンクが形成されます。 これには、物理的なリンクが関連付けられていない照会スキャンおよびページスキャンの物理チャネルが含まれます。 物理リンクは、コネクションレススレーブブロードキャスト物理リンクの場合を除いて、マスタデバイスとスレーブデバイス間の双方向パケット転送を提供します。 その場合、物理リンクは、マスタから潜在的に無制限の数のスレーブへの単方向パケット転送を提供します。 物理チャネルには複数のスレーブデバイスが含まれる可能性があるため、どのデバイスが物理リンクを形成するかという制約があります。 各スレーブとマスターの間には物理的なリンクがあります。 物理リンクは、ピコネット内のスレーブ間で直接形成されることはありません。
物理リンクは、ユニキャスト同期、非同期およびアイソクロナストラフィック、およびブロードキャストトラフィックをサポートする1つまたは複数の論理リンクのトランスポートとして使用されます。 論理リンク上のトラフィックは、リソースマネージャ内のスケジューリング機能に割り当てられたスロットを占有することによって、物理リンク上に多重化されれます。
ベースバンドおよび物理層の制御プロトコルは、ユーザデータに加えて論理リンクを介して搬送されます。 これはリンクマネージャプロトコル（LMP）です。 ピコネットでアクティブなデバイスには、LMPプロトコルシグナリングを転送するために使用されるデフォルトの非同期接続指向の論理トランスポートがあります。 歴史的な理由から、これはACL論理トランスポートと呼ばれます。 コネクションレススレーブブロードキャストデバイスを除き、プライマリACL論理トランスポートは、デバイスがピコネットに参加するたびに作成されます。 コネクションレススレーブブロードキャストデバイスは、単にコネクションレススレーブブロードキャストパケットを聴くためにピコネットに参加することができます。 その場合、コネクションレススレーブブロードキャスト論理トランスポートが作成され（CSB論理トランスポートとも呼ばれます）、ACL論理トランスポートは必要ありません。 すべてのデバイスで、必要に応じて同期データストリームを転送するために追加の論理トランスポートを作成することができます。
Link Manager機能は、LMPを使用してピコネット内のデバイスの動作を制御し、下位のアーキテクチャレイヤ（無線レイヤとベースバンドレイヤ）を管理するサービスを提供します。 LMPプロトコルは、プライマリACLおよびアクティブスレーブのブロードキャスト論理トランスポートで伝送されます。
ベースバンド層の上にあるL2CAP層は、アプリケーションおよびサービスにチャネルベースの抽象化を提供します。 アプリケーションデータのセグメンテーションと再アセンブリ、共有論理リンクを介した複数チャネルの多重化と逆多重化を実行します。 L2CAPには、デフォルトのACL論理トランスポートを介して伝送されるプロトコル制御チャネルがあります。 L2CAPプロトコルに提出されたアプリケーションデータは、L2CAPプロトコルをサポートする任意の論理リンク上で搬送されてもよい。
BR/EDRラジオと同様に、LEラジオは免許不要の2.4 GHz ISM帯域で動作します。 LEシステムは、干渉およびフェージングに対抗するために周波数ホッピングトランシーバを使用し、多くのFHSSキャリアを提供します。 LE無線操作では、整形されたバイナリ周波数変調を使用してトランシーバの複雑さを最小限に抑えます。 LEは、変調の違い、適用可能なコーディング、および結果として生じるデータレートに関して、サポートされるPHYを記述するためにBR/EDRおよびAMPとは異なる用語を使用します。 必須のシンボルレートは1メガシンボル/秒（Msym/s）です. 1シンボルは1ビットを表し、1Mビットのメガビット（Mb/s）のビットレートをサポートします。これはLE 1M PHYと呼ばれます。 1Mシンボル/秒のシンボルレートは、誤り訂正符号化を任意にサポートすることができ、これは、LE符号化PHYと呼ばれます。 これは2つの符号化方式のいずれかを使用することができます。 S=2は2シンボルで1ビットを表し、従って500kb/sのビットレートをサポートし、S=8は8シンボルで1ビットを表し、従って125kb/sのビットレートをサポートします。 オプションのシンボルレート2Msym/sがサポートされ、ビットレートは2Mb/sで、これはLE 2M PHYと呼ばれます。 2Msym/sのシンボルレートは、符号化されていないデータのみをサポートします。 LE 1MおよびLE 2Mは、まとめてLE未符号化PHYと呼ばれます。 （3.2.2節）では、この用語について詳しく説明します。
LEは、周波数分割多重アクセス（FDMA）と時分割多重アクセス（TDMA）の2つの多重アクセス方式を採用しています。 FDMA方式では、40MHzの物理チャネルを2MHzで分離して使用します。 3つはプライマリー広告チャネルとして使用され、37はセカンダリー広告チャネルおよびデータチャネルとして使用されます。 1つのデバイスが所定の時間にパケットを送信し、対応するデバイスが所定の間隔の後にパケットで応答するTDMAベースのポーリング方式が使用されます。
物理チャネルは、イベントとして知られる時間単位に細分されます。 これらのイベントに位置するパケットのLEデバイス間でデータが送信されます。 イベントには、広告、拡張広告、定期的な広告、および接続イベントの4種類があります。
広告PHYチャネル上で広告パケットを送信する装置は、広告主と呼ばれます。 広告装置に接続する意思なしに広告チャネル上で広告パケットを受信する装置は、スキャナと呼ばれます。 広告PHYチャネル上の送信は、広告イベントにおいて発生します。 各広告イベントの開始時に、広告主は、広告イベントタイプに対応する広告パケットを送信します。 広告パケットのタイプに応じて、スキャナは、同じ広告PHYチャネル上の広告主に、同じ広告PHYチャネル上の応答が続くことを要求することができます。 広告PHYチャネルは、同じ広告イベントで広告主によって送信された次の広告パケット上で変化します。 広告主は、イベント中いつでも広告イベントを終了することができます。 第1の広告PHYチャネルは、次の広告イベントの開始時に使用されます。
Figure1.3
LEデバイスは、広告イベントを使用する2つ以上のデバイス間の一方向通信またはブロードキャスト通信の場合、通信全体を満たすことができます。 また、広告イベントを使用して、データチャネルを使用する2つ以上のデバイス間のペアワイズ双方向通信を確立したり、セカンダリ広告チャネルを使用して定期的なブロードキャストを確立することもできます。
別のデバイスへの接続を形成する必要があるデバイスは、接続可能な広告パケットを待ち受けます。 そのような装置はイニシエータと呼ばれる。広告主が接続可能な広告イベントを使用している場合、イニシエータは、接続可能な広告パケットを受信した同じ広告PHYチャネルを使用して接続要求を行うことができます。 広告イベントが終了し、広告主が接続要求を受信して受け入れた場合、接続イベントが開始されます。 接続が確立されると、イニシエータは、ピコネットと呼ばれるものでマスタデバイスになり、広告デバイスはスレーブデバイスになります。 接続イベントは、マスタとスレーブの間でデータパケットを送信するために使用されます。 接続イベントでは、各接続イベントの開始時にチャネルホッピングが発生します。接続イベント内で、マスタとスレーブは、同じデータPHYチャネルを使用してデータパケットを交互に送信します。 マスタは、各接続イベントの開始を開始し、いつでも各接続イベントを終了できます。
Figure1.4
ピコネット内のデバイスは、開始デバイスによって送信された接続要求に含まれるフィールドによってアルゴリズム的に決定される特定の周波数ホッピングパターンを使用する。 LEで使用されるホッピングパターンは、ISM帯域の37個の周波数の擬似ランダム順序です。 ホッピングパターンは、干渉デバイスによって使用される周波数の一部を除外するように適合させることができます。 適応ホッピング技術は、これらが共に配置され、ローカル無線環境に関する情報にアクセスするか、または他の手段によって検出された場合に、スタティック（非ホッピング）ISMシステムとのBluetooth共存を改善します。
物理チャネルの上には、リンク、チャネル、および関連する制御プロトコルの概念があります。 階層は、物理チャネル、物理リンク、論理トランスポート、論理リンク、およびL2CAPチャネルです。 これらはセクション3.3からセクション3.6でより詳細に議論されますが、ここではこのセクションの残りの部分の理解を助けるために紹介されています。
物理チャネル内では、デバイス間に物理的なリンクが形成されます。 アクティブな物理リンクは、マスタとスレーブの間で双方向のパケット転送を行います。 LE物理チャネルは複数のスレーブデバイスを含むことができるので、どのデバイスが物理リンクを形成するかという制約があります。 各スレーブとマスターの間には物理的なリンクがあります。 スレーブは一度に複数のマスターとの物理リンクを持つことができます。 デバイスは同時にマスターとスレーブになることが許可されています。 物理リンクは、ピコネット内のスレーブ間で直接形成されることはない。 現時点では、マスターデバイスとスレーブデバイス間の役割変更はサポートされていません。 広告および定期的な物理リンクは、広告主から潜在的に無制限の数のスキャナまたはイニシエータへの一方向パケット転送を提供します。
物理リンクは、非同期トラフィックをサポートする1つまたは複数の論理リンクのトランスポートとして使用されます。 論理リンク上のトラフィックは、リソースマネージャ内のスケジューリング機能によって割り当てられた物理リンク上に多重化されます。
リンク層および物理層の制御プロトコルは、ユーザデータに加えて論理リンクを介して搬送されます。 これはリンクレイヤプロトコル（LL）です。 アクティブなデバイスは、LLプロトコルシグナリングを転送するために使用されるデフォルトのLE非同期接続論理トランスポート（LE ACL）を有します。 デフォルトのLE ACLは、デバイスがピコネットに参加するたびに作成されるACLです。
リンク層機能は、LLプロトコルを使用してピコネット内のデバイスの動作を制御し、下位のアーキテクチャ層（PHYおよびLL）を管理するサービスを提供します。
BR/EDRの場合と同様に、リンクレイヤの上にあるL2CAPレイヤは、アプリケーションとサービスにチャネルベースの抽象化を提供します。 アプリケーションデータの断片化とデフラグを実行し、共有論理リンクを介して複数のチャネルを多重化および逆多重化します。 L2CAPには、プライマリACL論理トランスポートを介して伝送されるプロトコル制御チャネルがあります。
L2CAPに加えて、LEはL2CAPの上に存在する2つの追加のプロトコルレイヤーを提供します。 セキュリティマネージャプロトコル（SMP）は、固定L2CAPチャネルを使用してデバイス間のセキュリティ機能を実装します。 もう1つは、固定L2CAPチャネルを介して少量のデータを通信する方法を提供する属性プロトコル（ATT）です。 属性プロトコルは、他のデバイスのサービスおよび機能を決定するためにデバイスによっても使用されます。 属性プロトコルは、BR/EDR上でも使用できます。
代替MAC/PHY（AMP）は、Bluetoothコアシステムのセカンダリコントローラです。 主無線であるBR/EDR無線は、発見、関連付け、接続確立、および接続維持を行うために使用される。 BR/EDR無線を介して2つのデバイス間でL2CAP接続が確立されると、AMPマネージャは他のデバイスで使用可能なAMPを検出できます。 AMPが2つのデバイス間で共通の場合、コアシステムは、BR/EDRコントローラからAMPコントローラへデータトラフィックを移動するためのメカニズムを提供します。
各AMPは、MACとPHYの上にあるプロトコル適応層（PAL）で構成されています。 PALは、Bluetoothのプロトコルと動作（HCIで指定されている）を基盤となるMACとPHYの特定のプロトコルにマッピングする責任があります。
L2CAPチャネルは、AMPで作成されるか、AMPに移動されます。 L2CAPチャネルは、それらの能力が必要でないとき、またはAMP物理リンクがリンク監視タイムアウトを有するときに、BR/EDR無線に戻すこともできる。 2つのBR/EDRデバイスを接続するACLリンク上のリンク監視タイムアウトは、それらのデバイス間のすべてのAMP物理リンクの切断を強制します。
AMPは、システムの消費電力を最小限に抑えるために、必要に応じて有効または無効にすることができます。
以下の用語が本仕様書に現れる場合、それらは表1.1で与えられた意味を持っています。
| 名称 | 意味 |
|---|---|
| Active Slave Broadcast (ASB) | L2CAPユーザトラフィックといくつかの種類のLMPトラフィックをBR/EDRコントローラを介してピコネット内のすべてのアクティブデバイスに転送するために使用される論理トランスポート。 3.5.4.4項を参照してください。 |
| Ad Hoc Network | 典型的には自発的に作成されるネットワーク。 アドホックネットワークは正式なインフラストラクチャを必要とせず、時間的および空間的な範囲において制限される。 |
| Advertiser | 広告チャネル上の広告イベント中に広告パケットをブロードキャストするBluetooth低エネルギーデバイス |
| Advertising Event | 広告主によって送信された異なる広告チャネル上の1つから3つの広告パケットのシリーズ。 |
| Advertising Packet | 広告PDUを含むパケット。 [Vol 6]パートB、セクション2.3.1を参照のこと |
| AMP | 代替メディアアクセスコントローラ（MAC）および物理層（PHY）または代替MAC / PHYを含む。 |
| AMP Controller | AMP PHY、AMP MAC、プロトコル適応レイヤ、およびHCIレイヤを指す用語。 |
| BD_ADDR | Bluetoothデバイスのアドレス、BD_ADDRは、Bluetoothデバイスを識別するために使用されます。 |
| Bluetooth | Bluetoothは無線通信リンクであり、周波数ホッピングトランシーバを使用して2.4GHzの免許不要のISM帯域で動作します。 これにより、Bluetoothホスト間のリアルタイムAVおよびデータ通信が可能になります。 リンクプロトコルは、タイムスロットに基づいている。 |
| Bluetooth Baseband | リアルタイムの音声、データ情報ストリーム、およびBluetoothデバイス間のアドホックネットワークの交換をサポートするために、メディアアクセスおよび物理レイヤーの手順を指定または実装するBluetoothシステムの部分。 |
| Bluetooth Clock | 312.5μsごとに動作するBR/EDRコントローラサブシステム内部の28ビットクロック。 このクロックの値は、さまざまな物理チャネルのスロット番号とタイミングを定義します。 |
| Bluetooth Controller | セカンダリコントローラの有無にかかわらず、プライマリコントローラを指す一般的な用語。 |
| Bluetooth Device | Bluetoothシステムを使用して短距離無線通信が可能なデバイス。 |
| Bluetooth Device Address | 各Bluetoothデバイスを識別するために使用される48ビットのアドレス。 |
| BR/EDR | Bluetooth基本レート（BR）および拡張データレート（EDR）。 |
| BR/EDR Controller | Bluetooth Radio、Baseband、Link Manager、およびHCIレイヤーを指す用語。 |
| BR/EDR Piconet Physical Channel | 各スロットがRFホップ周波数に関連するタイムスロットに分割されたチャネル。 連続ホップは通常、異なるRFホップ周波数に対応し、1600ホップ/秒の標準ホップ速度で発生します。 これらの連続したホップは、擬似ランダムホッピングシーケンスに従い、79 RFチャネルセットをホッピングするか、または適応周波数ホッピング（AFH）が使用されている場合は必要に応じてより少ないチャネルをホッピングします。 |
| BR/EDR/LE | Bluetooth基本レート（BR）、拡張データレート（EDR）および低エネルギー（LE）を含む。 |
| C-plane | コントロールプレーン |
| Channel | コンテキストに応じて、物理チャネルまたはL2CAPチャネル。 |
| Connect (to service) | サービスへの接続の確立。 まだ行われていない場合は、物理リンク、論理トランスポート、論理リンク、およびL2CAPチャネルの確立も含まれます。 |
| Connectable device | 範囲内のBR/EDRデバイスで、ページスキャン物理チャネルで定期的に聴取し、そのチャネルのページに応答します。 接続可能な広告イベントを使用して広告を出すLEデバイス。 |
| Connected devices | 2台のBR/EDRデバイスとそれらの間に物理的なリンクがあります。 |
| Connecting | デバイス間の接続が確立されているときのデバイス間の通信におけるフェーズ。 （リンク確立フェーズが完了した後、接続フェーズが続きます。） |
| Connection | L2CAPチャネルにマッピングされた2つのピアアプリケーションまたは上位レイヤプロトコル間の接続。 |
| Connection establishment | チャネルにマッピングされた接続を作成する手順。 |
| Connection Event | 同じ物理チャネル上でマスタとスレーブの間で送信される一連の1つ以上のインタリーブデータパケット。 |
| Connectionless Slave Broadcast (CSB) | マスターが情報を無制限のスレーブにブロードキャストできるようにする機能。 |
| Connectionless Slave Broadcast Receiver | コネクションレススレーブブロードキャスト送信機からブロードキャスト情報を受信するBluetoothデバイス。 デバイスはピコネットのスレーブです。 |
| Connectionless Slave Broadcast Transmitter | 1つまたは複数のコネクションレススレーブブロードキャスト受信者による受信のために、コネクションレススレーブブロードキャストメッセージを送信するBluetoothデバイス。 デバイスはピコネットのマスターです。 |
| Controller | HCI以下のすべてのレイヤを指す集合的な用語。 |
| Coverage area | 2つのBluetoothデバイスが許容できる品質とパフォーマンスでメッセージを交換できるエリア。 |
| Creation of a secure connection | 認証と暗号化を含む接続を確立する手順。 |
| Creation of a trusted relationship | リモートデバイスがトラステッドデバイスとしてマークされている手順。 これには、将来の認証のための共通リンクキーの保存、またはリンクキーが利用できない場合のペアリングが含まれます。 |
| Device discovery | Bluetoothデバイスアドレス、クロック、デバイスクラスフィールド、および使用可能なページスキャンモードを検出可能なデバイスから取得する手順。 |
| Discoverable device | 範囲内のBR/EDRデバイス。定期的に照会スキャン物理チャネルをリッスンし、そのチャネルの照会に応答します。 検索可能なフラグが広告データに設定された接続可能またはスキャン可能な広告イベントで広告を掲載している範囲内のLEデバイス。 このデバイスは検出可能モードです。 |
| Discoverable Mode | BR/EDRで照会スキャンを実行している、またはLEで発見可能なフラグが設定された、発見可能か接続可能な広告イベントで広告しているBluetoothデバイス。 |
| Discovery procedure | BR/EDRで照会手順を実行している、またはLEで発見可能なフラグが設定された、発見可能または接続可能な広告イベントを使用して広告主をスキャンしているBluetoothデバイス。 |
| HCI | |
| Host | |
| Initiator | |
| Inquiring device | |
| Inquiry | |
| Inquiry scan | |
| Interoperability | |
| Isochronous data | |
| Known device | |
| L2CAP | |
| L2CAP Channel | |
| L2CAP Channel establishment | |
| LE | |
| Link | |
| Link establishment | |
| Link key | |
| LMP authentication | |
| LMP pairing | |
| Logical link | |
| Logical transport | |
| Name discovery | |
| Packet | |
| Page | |
| Page scan | |
| Paging device | |
| Paired device | |
| Passkey | |
| Physical Channel | |
| Physical Link | |
| Physical Transport | |
| Piconet | |
| Piconet Master | |
| Piconet Slave | |
| PIN | |
| PMP | |
| Profile Broadcast Data (PBD) | |
| Scanner | |
| Scatternet | |
| Service discovery | |
| Service Layer Protocol | |
| Silent device | |
| Synchronization Scan Physical Channel | |
| Synchronization Train | |
| U-plane | |
| Unknown device | |
| Table 1.1: Nomenclature |
Bluetoothコアシステムは、ホスト、プライマリコントローラ、ゼロ個以上のセカンダリコントローラで構成されています。 Bluetooth BR/EDRコアシステムの最小限の実装は、Bluetooth仕様によって定義される4つの最下層および関連するプロトコルならびに1つの共通のサービス層プロトコルをカバーする。サービスディスカバリプロトコル（SDP）および全体のプロファイル要件は、汎用アクセスプロファイル（GAP）で指定されています。 BR/EDRコアシステムは、外部参照MAC/PHYをサポートするAMPマネージャプロトコルおよびプロトコル適応レイヤ（PAL）を含む代替MAC/PHY（AMP）のサポートを含む。 Bluetooth LEのみのコアシステムの最小限の実装は、Bluetooth仕様によって定義された4つの最下層および関連するプロトコルならびに2つの共通のサービス層プロトコルをカバーする。セキュリティマネージャ（SM）と属性プロトコル（ATT）と全体のプロファイル要件は、汎用属性プロファイル（GATT）と汎用アクセスプロファイル（GAP）で指定されています。 Bluetooth BR/EDRとLEを組み合わせた実装には、上記の最小実装の両方が含まれます。
完全なBluetoothアプリケーションでは、Bluetooth仕様で定義されている数多くの追加サービスおよび上位レイヤプロトコルが必要ですが、ここでは説明しません。 コアシステムアーキテクチャをFigure 2.1に示します。
Figure 2.1
Figure 2.1にコアブロックを示し、それぞれに関連する通信プロトコルを示します。 Link Manager、Link Controller、BR/EDR Radioブロックは、BR/EDRコントローラを構成します。 AMP PAL、AMP MAC、およびAMP PHYは、AMPコントローラを構成します。 Link Manager、Link Controller、およびLE Radioブロックは、LEコントローラを構成します。 L2CAP、SDP、およびGAPブロックは、BR/EDRホストを構成します。 L2CAP、SMP、属性プロトコル、GAPおよび汎用属性プロファイル（GATT）ブロックはLEホストを構成します。 BR/EDR / LEホストは、それぞれのホストからのブロックセットを結合します。 これは、コントローラとホストとの間の標準的な物理的通信インタフェースを含む一般的な実装である。このインタフェースはオプションですが、アーキテクチャはその存在と特性を考慮して設計されています。 Bluetooth仕様は、BluetoothコントローラとBluetoothホスト間の共通インタフェースを定義することにより、独立したBluetoothシステム間の相互運用を可能にし、同等のレイヤ間で交換されるプロトコルメッセージを定義し、独立したBluetoothサブシステム間の相互運用性も規定します。
多数の機能ブロックとそれらの間のサービスとデータのパスが示されています。 図に示された機能ブロックは有益である。 一般に、Bluetooth仕様では、相互運用性に必要な場合を除いて、実装の詳細は定義されていません。 したがって、Figure 2.1の機能ブロックは、システムの動作の説明を助けるために示されています。 実装は、Figure 2.1に示すシステムとは異なる場合があります。
BluetoothデバイスがBluetooth仕様に従ってプロトコルシグナリングを交換するすべてのデバイス間動作に対して、標準的な相互作用が定義されています。 Bluetoothコアシステムプロトコルは、無線（PHY）プロトコル、リンク制御（LC）およびリンクマネージャ（LM）プロトコルまたはリンク層（LL）プロトコル、AMP PAL、論理リンク制御および適応プロトコル（L2CAP）、およびAMPマネージャプロトコル これらはすべて、Bluetooth仕様の後続部分で完全に定義されています。 さらに、サービスディスカバリプロトコル（SDP）および属性プロトコル（ATT）は、一部のBluetoothアプリケーションで必要となるサービスレイヤプロトコルです。
Bluetoothコアシステムは、図に省略記号として示されている複数のサービスアクセスポイントを介してサービスを提供します。 これらのサービスは、Bluetoothコアシステムを制御する基本プリミティブで構成されています。 サービスは3つのタイプに分けることができます。 Bluetoothデバイスの動作とモードを変更するデバイス制御サービス、トラフィックベアラ（チャネルとリンク）を作成、変更、解放するトランスポート制御サービス、およびトラフィックベアラを介して送信するデータを送信するために使用されるデータサービスがあります。 最初の2つをC面に属するものと最後のものをU面に属するものと考えることは一般的である。
Bluetoothコントローラサブシステムへのサービスインタフェースは、プライマリコントローラが標準部品とみなされるように定義される。 この構成では、Bluetoothコントローラは最低4つのレイヤを操作します。 Bluetoothホストは、L2CAPレイヤーおよび他の上位層を操作します。 標準インタフェースはHCI（Host Controller Interface）と呼ばれ、サービスアクセスポイントは図2.1のBluetoothコントローラサブシステムの上端にある省略記号で表されます。 この標準サービスインタフェースの実装はオプションです。
Bluetoothアーキテクチャは、1つまたは複数のHCIトランスポートを介して通信する別々のホストおよびコントローラの可能性によって定義されるため、いくつかの一般的な仮定がなされている。 Bluetoothコントローラは、ホストと比較してデータバッファリング機能が制限されているとみなされます。 したがって、L2CAPレイヤは、L2CAP PDUをピアデバイスに転送するためにコントローラに送信するときに、単純なリソース管理を実行することが期待されます。 これには、L2CAP SDUをより管理しやすいPDUに分割した後、コントローラバッファに適したサイズの開始パケットと継続パケットに分割すること、Quality of Service（QoS）約束を持つチャネルの可用性を確保するためのコントローラバッファの使用の管理が含まれます
BR/EDRベースバンド、LEリンクレイヤ、およびAMP MACレイヤは、Bluetoothでの基本的な確認応答/リピート要求（ARQ）プロトコルを提供します。 L2CAP層は、オプションで、L2CAP PDUにさらなる誤り検出および再送信を提供することができる。 この機能は、ユーザーデータの未検出エラーの確率が低い要件のアプリケーションに推奨されます。 L2CAPのさらなるオプション機能は、受信デバイスのバッファ割り当てを管理するために使用できるウィンドウベースのフロー制御です。 これらのオプション機能は両方とも、特定のシナリオでQoSパフォーマンスを向上させます。 LEシステムを使用する場合、すべてのL2CAP機能を使用できるわけではありません。
これらの仮定は、単一のシステム内のすべてのレイヤーを結合する組み込みBluetooth実装では必ずしも必要ではありませんが、一般的なアーキテクチャモデルとQoSモデルは、これらの前提を念頭に置いて定義されています。
Bluetoothコアシステムの実装の自動適合テストが必要です。 これは、テスターがPHYインターフェース、および直接テストモード（DTM）、汎用テスト方法（GTM）、テスト制御インターフェース（TCI）、およびHCI上のテストコマンドおよびイベントなどのテストインターフェースを介して、 適合性テストにのみ必要です。
テスターは、リモートデバイスからの要求に対する正しい応答を保証するために、PHYインターフェースを介してテスト中実装（IUT）と交換します。 テスタは、HCI、DTM、GTM、またはTCIを介してIUTを制御し、IUTにPHYインターフェイスを介した交換を開始させ、これらもまた適合していることを確認することができます。
TCIは、各アーキテクチャレイヤーとプロトコルのテストに異なるコマンドセット（サービスインターフェイス）を使用します。 HCIコマンドセットのサブセットは、BR/EDRコントローラサブシステム内の各レイヤおよびプロトコルのTCIサービスインターフェイスとして使用されます。 L2CAPレイヤおよびプロトコルのテストには、別個のサービスインターフェイスが使用されます。 L2CAPサービスインターフェイスは、Bluetoothコア仕様で定義されていないため、テストコントロールインターフェイス仕様で別途定義されています。 L2CAPサービスインターフェイスの実装は、適合性テストにのみ必要です。
このセクションでは、Figure 2.1に示す各ブロックの機能と責任について説明します。 すべての実装は、Bluetooth仕様の後続部分で説明されているプロトコル仕様に準拠しなければならず、 以下に概説され、Bluetooth仕様の後続部分で指定されたシステムの動作上の側面を実装しなければならない。
チャネル・マネージャは、サービス・プロトコルおよびアプリケーション・データ・ストリームの転送のためのL2CAPチャネルの作成、管理およびクローズを担当します。 チャネルマネージャは、L2CAPプロトコルを使用してリモート（ピア）デバイス上のチャネルマネージャと対話し、これらのL2CAPチャネルを作成し、エンドポイントを適切なエンティティに接続します。 チャネルマネージャは、ローカルリンクマネージャまたはAMP PALとやりとりして、必要に応じて新しい論理リンクを作成し、これらのリンクを構成して、転送されるデータの種類に必要なサービス品質を提供します。
L2CAPリソースマネージャブロックが担当するのは、 ベースバンドへのPDUフラグメントの提出の順序を管理すること、 そして、コントローラリソースの枯渇のために物理チャネルへのアクセスが拒否されることがないQoSコミットメントを伴うL2CAPチャネルを保証するために、チャネル間のいくつかの相対スケジューリングをすること。 これは、アーキテクチャーモデルがコントローラーに無制限バッファーがあると仮定しないか、またはHCIが無限大帯域幅のパイプであると仮定しないために必要です。
L2CAPリソースマネージャは、アプリケーションがネゴシエートされたQoS設定の範囲内でL2CAP SDUを送信していることを確認するためにトラフィック適合ポリシングを実行することもできます。 一般的なBluetoothデータトランスポートモデルでは、正常に動作するアプリケーションを前提としており、実装がこの問題にどのように対処するかを定義していません。
セキュリティマネージャプロトコル（SMP）は、暗号化キーと識別キーを生成するために使用されるピアツーピアプロトコルです。 このプロトコルは、専用の固定L2CAPチャネルで動作します。 SMPブロックはまた、暗号化キーおよび識別キーの記憶を管理し、ランダムアドレスを生成し、ランダムアドレスを既知のデバイスアイデンティティに解決する役割を担う。 SMPブロックは、コントローラと直接インターフェースして、暗号化またはペアリング手順中に暗号化および認証に使用される格納されたキーを提供します。
属性プロトコル（ATT）ブロックは、属性サーバと属性クライアントとの間のピアツーピアプロトコルを実装する。 ATTクライアントは、専用固定L2CAPチャネルを介してリモートデバイス上のATTサーバーと通信します。 ATTクライアントは、コマンド、要求、および確認をATTサーバーに送信します。 ATTサーバーは、応答、通知、および指示をクライアントに送信します。 これらのATTクライアントのコマンドと要求は、ATTサーバーでピアデバイス上の属性の値を読み書きする手段を提供します。
AMPマネージャは、L2CAPを使用してリモートデバイスのピアAMPマネージャと通信するレイヤです。 また、AMPコントロールのためにAMP PALと直接インターフェースします。 AMPマネージャは、リモートAMPを検出し、その可用性を決定する責任があります。 また、リモートAMPに関する情報も収集します。 この情報は、AMP物理リンクの設定および管理に使用されます。 AMPマネージャは、専用のL2CAPシグナリングチャネルを使用して、リモートAMPマネージャと通信します。
汎用属性プロファイル（GATT）ブロックは、属性サーバの機能、およびオプションで属性クライアントの機能を表します。 プロファイルは、属性サーバーで使用されるサービス、特性、および属性の階層を記述します。 このブロックは、サービス特性および属性の検出、読み取り、書き込み、および表示のためのインタフェースを提供します。 GATTは、LEプロファイルサービス発見のためにLEデバイスで使用されます。
ジェネリックアクセスプロファイル（GAP）ブロックは、モード、転送、プロトコル、アプリケーションプロファイルで使用されるアクセス手順など、すべてのBluetoothデバイスに共通の基本機能を表します。 GAPサービスには、デバイス検出、接続モード、セキュリティ、認証、関連モデル、およびサービス検出が含まれます。
BR/EDRとLEシステムが結合された実装では、アーキテクチャブロックがシステム間で共有されるか、または各システムがブロックのインスタンス化を独自に行うことがあります。
デバイスマネージャは、Bluetoothデバイスの一般的な動作を制御するベースバンド内の機能ブロックです。 近くのBluetoothデバイスの有無の問い合わせ、Bluetoothデバイスへの接続、またはローカルBluetoothデバイスを他のデバイスで検出または接続可能にするなど、データ転送に直接関係しないBluetoothシステムのすべての操作を担当します。
デバイスマネージャは、その機能を実行するために、ベースバンドリソースコントローラからトランスポートメディアへのアクセスを要求する。
また、デバイスマネージャは、デバイスのローカル名、格納されているリンクキー、その他の機能の管理など、いくつかのHCIコマンドが暗示するローカルデバイスの動作を制御します。
リンクマネージャは、論理リンク（および、必要に応じて関連する論理トランスポート）の作成、変更、解放、およびデバイス間の物理リンクに関連するパラメータの更新を担当します。 リンクマネージャは、BR/EDRのLink Managerプロトコル（LMP）とLEのLink Layer Protocol（LL）を使用して、リモートBluetoothデバイスのリンクマネージャと通信することでこれを実現します。
LMまたはLLプロトコルを使用すると、必要に応じてデバイス間で新しい論理リンクと論理トランスポートを作成、 論理的なトランスポートでの暗号化を有効にするなどのリンクとトランスポートの属性の一般的な制御、 物理リンク上のBR/EDRにおける送信電力の適応、 または論理リンクのBR/EDRでのQoS設定の調整ができます。
ベースバンドリソースマネージャは、無線媒体へのすべてのアクセスを担当する。 それは2つの主な機能を持っています。 その中心には、アクセス契約を交渉したすべてのエンティティに物理チャネルの時間を与えるスケジューラがあります。 もう1つの主な機能は、これらのエンティティとのアクセス契約を交渉することです。 アクセス契約は、ユーザアプリケーションに期待される性能を提供するために必要とされる特定のQoSを提供するというコミットメントである。
アクセス契約およびスケジューリング機能は、プライマリコントローラの使用を必要とするすべての動作を考慮する必要があります。 これには、（例えば）論理リンクを介して接続されたデバイス間の通常のデータ交換、および論理トランスポート、 適応型周波数ホッピングモードの使用中に、問い合わせを実行したり、接続を確立したり、発見可能または接続可能にしたり、 未使用のキャリアから読み取ったりするための無線媒体の使用を含む。
BR/EDRシステムでは、論理リンクのスケジューリングによって、以前に使用されたものとは異なる物理チャネルへの論理リンクが変更されることがあります。 これは、スキャタネットへの関与、定期的な照会機能、またはページスキャンによる（たとえば）可能性があります。 物理チャネルがタイムスロットアライメントされていない場合、リソースマネージャはまた、元の物理チャネル上のスロットと新しい物理チャネル上のスロットとの間の再調整時間を考慮する。 場合によっては、両方の物理チャネルの参照として使用される同じデバイスクロックのために、スロットは自然に整列されます。
リンクコントローラは、データペイロードからのBluetoothパケットの符号化および復号、ならびに物理チャネル、論理トランスポートおよび論理リンクに関するパラメータを担当する。
リンクコントローラは、フロー制御と肯定応答および再送信要求信号を通信するために使用されるでBR/EDRのリンク制御プロトコルシグナリングおよびLEのリンク層プロトコル（リソースマネージャのスケジューリング機能に近い）を実行します。 これらの信号の解釈は、ベースバンドパケットに関連する論理トランスポートの特性である。 リンク制御シグナリングの解釈および制御は、通常、リソースマネージャのスケジューラに関連付けられます。
PHYブロックは、物理チャネル上の情報パケットの送受信を担当します。 ベースバンドとPHYブロックとの間の制御経路は、ベースバンドブロックがPHYブロックのタイミング及び周波数キャリアを制御することを可能にする。 HYブロックは、物理チャネルとベースバンドとの間でデータストリームを必要なフォーマットに変換します。
AMP HCIは、AMPコントローラとホスト（L2CAPおよびAMPマネージャ）間の論理インターフェイスです。 HCIは、ホストコントローラとAMPコントローラが物理的に分離されている場合に使用されるオプションのレイヤーです。 AMPをサポートするには、追加のHCIコマンドとイベントが必要です。 これらの新しいコマンドおよびイベントは、AMP物理および論理リンク管理、QoS、およびフロー制御に関連しています。
AMPコントローラごとのHCIの論理的なインスタンス化と、BR/EDRコントローラの別の論理的なインスタンス化があります。 物理HCIトランスポート層は、複数のコントローラが単一の物理ユニットに存在する場合に、同じ物理トランスポートバスを介して複数のコントローラの多重化を管理します。
AMP PALは、AMP MACとホスト（L2CAPおよびAMPマネージャ）を接続するAMPレイヤーです。 これはホストからのコマンドを特定のMACサービスプリミティブとプリミティブに変換してコマンドに変換し、AMP MACのプリミティブをホストの理解可能なイベントに変換します。 AMP PALは、AMPチャネル管理、指定されたフロー仕様に従ったデータトラフィック、および電力効率のサポートを提供します。
AMP PALがAMP自体に排他的にアクセスする必要はありません。 実装者は、他のプロトコルをAMPの同時クライアントにすることを許可することもできます。 他のプロトコルがAMPへのアクセスを共有できるようにするための特定のメカニズムは、この仕様の範囲外です。
一般的なPALアーキテクチャをFigure 2.2に示します。
Figure 2.2
PALおよび基礎となるMAC/PHYの能力は、AMPマネージャプロトコルによってAMP_InfoおよびAMP_Assoc構造を介して交換される。 AMP_Infoには、帯域幅の可用性、最大PDUサイズ、PAL機能、AMP_Assocの長さ、フラッシュタイムアウト情報などのPALの汎用機能が含まれています。 AMP_Assocの内容はPALに依存し、基礎となるMAC/PHYに関連しています。
AMP MACは、IEEE802基準層モデルで定義されたMAC層である。 アドレッシングやチャネルの制御やアクセスのためのメカニズムなどのサービスを提供します。 AMP MACは、AMP PHYレイヤーとAMP PALレイヤーの間にあります。
AMP PHYはAMP物理層です。
Bluetoothデータトランスポートシステムは、階層化されたアーキテクチャに従う。 Bluetoothシステムのこの記述は、L2CAPチャネルまでのBluetoothコアトランスポート層を記述する。 すべてのBluetooth動作モードは、Figure 3.1に示されているものと同じ汎用トランスポートアーキテクチャに従います。
Figure 3.1
効率性および従来の理由から、Bluetoothトランスポートアーキテクチャは、論理リンクと論理トランスポートとを区別する論理レイヤのサブディビジョンを含む。 このサブディビジョンは、2つ以上のデバイス間で独立したトランスポートを提供する論理リンクの一般的な概念を提供します。 論理トランスポートサブレイヤは、（主にレガシー動作の理由から）いくつかの論理リンクタイプ間の依存関係を記述するために必要です。
バージョン1.2より前のバージョンでは、Bluetoothコアの仕様でACLとSCOリンクが物理リンクとして記述されていました。 Extended SCO（eSCO）が追加され、将来の拡張のためには、これらをより正確にその目的をカプセル化する論理トランスポートタイプと考える方が良いでしょう。 しかしながら、それらは、LT_ADDRおよび受領確認/繰返し要求（ARQ）スキームのような資源のそれらの共用のために望まれるほど独立していない。 したがって、アーキテクチャは、これらの論理トランスポートを単一のトランスポート層で表現することができません。 付加的な論理トランスポート層は、この挙動を説明するための何らかの方法をとる。
Bluetoothコアシステムは、サービスプロトコルおよびアプリケーションデータの転送のための多数の標準トラフィックベアラを提供する。 これらは以下のFigure 3.2に示されています（表現を簡単にするために、これは左のレイヤーと下のレイヤーの上位レイヤーで示されています）。
Figure 3.2
アプリケーションで使用できるコアトラフィックベアラは、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のものへの代替の輸送経路の使用は、アプリケーショントラフィックタイプの特性が保持されている場合にのみ許容されます。
図3.2に、さまざまなアプリケーショントラフィックタイプを示します。 これらは、Bluetoothコアシステムに送信されるデータの種類を分類するために使用されます。 介入するプロセスが修正する場合、元のデータトラフィックタイプは、Bluetoothコアシステムに送信されるタイプと異なる場合があります。 例えば、ビデオデータは一定のレートで生成されるが、中間のコーディングプロセス、MPEG4エンコーディングによって、これを可変レートに変更してもよい。 Bluetoothコアシステムの目的のために、提出されたデータの特性のみが重要である。
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チャネルとベースバンド論理リンク上に多重化する。
アプリケーションがインストリーム・フレーミングを含んでいる可能性があるため、アプリケーションがフレーム内のデータ配信を必要としない場合、またはデータが純粋なストリームであるため、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システムではサポートされていません。
Bluetoothは無線通信システムです。 劣悪なRF環境では、このシステムは本質的に信頼性が低いと考えられるべきです。 これに対抗するために、システムは各層で保護レベルを提供する。 ベースバンドパケットヘッダは、受信機による誤り訂正を可能にする順方向誤り訂正（FEC）符号化と、訂正後に残る誤りを検出するヘッダ誤り検査（HEC）を使用する。 特定のベースバンドパケットタイプには、ペイロードのFECが含まれます。 さらに、いくつかのベースバンドパケットタイプは、巡回冗長エラーチェック（CRC）を含む。
ACL論理トランスポートのエラー検出アルゴリズムの結果は、単純なARQプロトコルを駆動するために使用されます。 これは、受信機のエラーチェックアルゴリズムをパスしないパケットを再送信することにより、信頼性を高める。 このスキームを変更して、パケットの耐用年数が満了した場合に送信機で送信に失敗したパケットを破棄することによって、待ち時間に敏感なパケットをサポートすることが可能です。 eSCOリンクは、このスキームの修正バージョンを使用して、限定された数の再送信を可能にすることによって信頼性を向上させる。
このARQスキームによって得られる結果の信頼性は、エラーを検出するHECおよびCRCコードの能力と同様に信頼できるものである。 ほとんどの場合、これで十分ですが、長いパケットタイプの場合、検出されないエラーの確率は、典型的なアプリケーション、特に大量のデータが転送されるアプリケーションをサポートするには高すぎます。
L2CAPレイヤーは、ベースバンドレイヤーで時々検出されないエラーを検出し、影響を受けたデータの再送信を要求するように設計された追加レベルのエラー制御を提供します。 これにより、一般的なBluetoothアプリケーションで必要とされるレベルの信頼性が提供されます。
ブロードキャストリンクはフィードバックルートを持たず、ARQ方式を使用することはできません（ただし、受信側は受信パケット内のエラーを検出できます）。 代わりに、各パケットは、受信機が少なくとも1つのコピーをうまく受信できることを期待して複数回送信される。 このアプローチにもかかわらず、成功した受領の保証はまだないので、これらのリンクは信頼できないと考えられます。
要約すると、リンクまたはチャネルが信頼できると特徴付けられる場合、これは、受信機が受信パケットのエラーを検出し、エラーが除去されるまで再送信を要求できることを意味する。 使用された誤り検出システムのために、受信したデータには依然として若干の残存（検出されない）誤りが残ることがある。 L2CAPチャネルの場合、これらのレベルは他の通信システムに匹敵しますが、論理リンクでは残留エラーレベルはやや高くなります。
送信機は、受信機がシーケンス内のすべてのパケットを受信しないように、送信キューからパケットを除去することができる。 この場合、行方不明パケットの検出はL2CAPレイヤーに委任されます。 ほとんどの場合、これで十分ですが、長いパケットタイプの場合、検出されないエラーの確率は、典型的なアプリケーション、特に大量のデータが転送されるアプリケーションをサポートするには高すぎます。
信頼性の低いリンクでは、受信機は受信パケットのエラーを検出することができますが、再送信を要求することはできません。 受信者が渡したパケットにエラーはないかもしれませんが、シーケンス内のすべてのパケットが受信されるという保証はありません。 したがって、リンクは基本的に信頼性が低いと考えられます。 このようなリンクの使用は限られており、通常、上位層からのデータが有効である間は、そのデータの連続的な繰り返しに依存します。
ストリームリンクは、現在の動作状態に応じて、信頼できるリンクと信頼できないリンクとの間のどこかに信頼性特性を有する。
BR/EDRのように、劣悪なRF環境では、LEシステムは本質的に信頼性が低いと考えられるべきです。 これに対抗するために、システムは各層で保護レベルを提供します。 LLパケットは、パケットペイロードの内容をカバーするために24ビットの巡回冗長エラーチェック（CRC）を使用します。 CRC検証がパケットペイロードで失敗すると、パケットは受信側によって確認応答されず、パケットは送信側によって再送されます。
ブロードキャストリンクはフィードバック経路を持たず、（受信機は依然として受信パケット内のエラーを検出することができるが）肯定応答方式を使用することはできない。 代わりに、各パケットは、受信機が少なくとも1つのコピーを首尾よく受信することができる確率を高めるために、複数回送信される。 このアプローチにもかかわらず、成功した受領の保証はまだないので、これらのリンクは信頼できないと考えられます。
要約すると、リンクまたはチャネルが信頼できると特徴付けられる場合、これは、受信機が受信パケットのエラーを検出し、エラーが除去されるまで再送信を要求できることを意味する。
信頼性の低いリンクでは、受信機は受信パケットのエラーを検出することができますが、再送信を要求することはできません。 受信者が渡したパケットにエラーはないかもしれませんが、シーケンス内のすべてのパケットが受信されるという保証はありません。 したがって、リンクは基本的に信頼性が低いと考えられます。 このようなリンクの使用は限られており、通常、上位層からのデータが有効である間は、そのデータの連続的な繰り返しに依存します。
各AMPの信頼性は、基礎となるMAC / PHY技術に依存します。 一部のAMPは、フラッシュとしてマークされている場合にのみユーザートラフィックをフラッシュしますが、他のAMPではユーザートラフィックをフラッシュできます。
Bluetoothコアは、AMP上で使用されるL2CAPチャネルに対して拡張再送信モードまたはストリーミングモードの使用を強制することにより、コア上のプロトコルおよびプロファイルの信頼性レベルを維持します。
BluetoothトランスポートアーキテクチャエンティティはFigure 3.3に示されており、後のセクションの最下位レイヤから上に説明されています。
Figure 3.3
BR/EDR物理トランスポートは、BR/EDR物理チャネルをカプセル化する。 BR/EDR物理トランスポートを使用する転送は、BR/EDR汎用パケット構造を使用します。 LE物理トランスポートは、LE物理チャネルをカプセル化する。 LE物理トランスポートを使用する転送は、LE汎用パケット構造を使用します。
一般的なパケット構造は、Bluetooth BR/EDRシステムに見られるアーキテクチャレイヤをほぼ反映しています。 BR/EDRパケット構造は、通常の動作において最適な使用のために設計されている。 これはFigure 3.4に示されています。
Figure 3.4
通常、パケットには、トランザクションで必要なレイヤーを表すのに必要なフィールドだけが含まれます。 したがって、照会スキャン物理チャネル上の単純な照会要求は、論理リンクまたは上位層を作成または要求せず、したがって、（物理チャネルに関連付けられた）チャネルアクセスコードのみからなる。
すべてのパケットにチャネルアクセスコードが含まれます。 これは、特定の物理チャネル上の通信を識別し、物理的に近接して同じRFキャリアを使用している別の物理チャネル上のパケットを除外または無視するために使用されます。
BR/EDRパケット構造内には、物理リンクに関する情報を表すまたは含む直接フィールドは存在しない。 この情報は、パケットヘッダ内に搬送される論理トランスポートアドレス（LT_ADDR）とチャネルアクセスコード（CAC）との組み合わせによって暗示される。
ほとんどのBR/EDRパケットにはパケットヘッダが含まれています。 パケットヘッダーは、物理リンク、論理トランスポート、論理リンクをサポートする物理チャネル上で送信されるパケットに常に存在します。 パケットヘッダはLT_ADDRを運び、各受信デバイスは、パケットがデバイス宛であるかどうかを判断し、パケットを内部的にルーティングするために使用します。
BR/EDRパケットヘッダーには、論理トランスポートごとに動作するリンク制御（LC）プロトコルの一部も含まれます（論理トランスポートで実行される共有LCプロトコルを操作するACLおよびSCOトランスポートを除く）。
拡張データレート（EDR）パケットは、ペイロードの前にガード時間と同期シーケンスを持っています。 これは、変調方式の物理層変更に使用されるフィールドです。
ペイロードヘッダーは、複数の論理リンクをサポートする論理トランスポート上のすべてのパケットに存在します。 ペイロードヘッダは、ペイロードをルーティングするために使用される論理リンク識別子フィールドと、ペイロードボディの長さを示すフィールドとを含む。 一部のパケットタイプには、受信パケットの大部分のエラーを検出するために使用されるパケットペイロードの最後にCRCも含まれます。 AES-CCM暗号化をイネーブルにすると、ACLパケットにはCRCフィールドの直前にメッセージ整合性チェック（MIC）が含まれます。
EDRパケットには、CRCの後にトレーラがあります。
パケットペイロード本体は、ユーザデータを転送するために使用される。 このデータの解釈は、論理トランスポート識別子と論理リンク識別子に依存します。 ACL論理トランスポートの場合、Link Managerプロトコル（LMP）メッセージとL2CAP信号は、アプリケーションからの一般的なユーザーデータと共に、パケットペイロード本体で転送されます。
SCO、eSCO、およびCSB論理トランスポートの場合、ペイロード本体には論理リンクのユーザーデータが格納されます。
LE無線操作は3つのPHYに基づいており、2つの変調方式を使用しています。 Table 3.1に、各LE PHYのプロパティをまとめています。 送信される各パケットは単一のPHYを使用します。 各PHYは単一の変調方式を使用します。 PHYのうち2つは符号化されていません。 つまり、各ビットはパケット内の単一の無線シンボルに直接マッピングされ、3番目のPHYは誤り訂正符号化されます。 2つの符号化方式、S = 8およびS = 2があり、ここで、Sはビット当たりのシンボル数である。
Table 3.1
Table 3.1で参照される「アクセスヘッダ」は、PDUヘッダの開始前に特定のPHYに関連するパケットフォーマットのすべてのビットを含むが、プリアンブルは含まない。 プリアンブルは、すべてのPHYで符号化されていないため、除外されます。
Table 3.1で言及される「ペイロード」は、PDUヘッダからパケットの終わりまでのパケットフォーマットのすべてのビットを含む。
リンクレイヤエアインタフェースパケットの一般的な構造は、LEシステムで見られるアーキテクチャレイヤを厳密に反映している。 LE Uncoded PHYのパケット構造は、通常の動作で最適に使用されるように設計されており、Figure 3.5に示されています。
Figure 3.5
LE Coded PHYのパケット構造は、拡張された範囲の動作において最適な使用のために設計され、Figure 3.6に示されている
Figure 3.6
LE Coded PHYを使用する場合は、無線オンタイムによる電力消費とデューティサイクルのスケジューリングおよび共存に対する影響を注意深く検討することをお勧めします。 無線で送信される各パケットがLE 1Mより約8倍大きくなる無線オンタイムとデューティサイクルを考慮すると、S=8コーディング（125 kb/s）のLEコード化PHYは最悪の場合を表します。
Table 3.2は、AdvDataのサイズが異なる広告イベントのオンエア時間を示しています。 1つは、AdvDataがプライマリ広告チャネルで送信される、接続およびスキャン可能な無向の広告イベントを使用することです。 2番目のイベントは、AdvDataがセカンダリ広告チャネルにオフロードされるイベントを使用しています。 プライマリおよびセカンダリの広告チャネルの使用方法は、3.3.2.2項で説明しています。 カッコ内の数字は、仮想的なものであり、準拠した実装では有効でないケースを示しています。
Table 3.2
注：オフロードのないイベントは、3つのADV_IND PDUを使用して計算され、オフロードのイベントは、AuxPtrフィールドとADIフィールドのみを含む3つのADV_EXT_IND PDUと、AdvAおよびADIフィールドが存在し、AdvDataを保持するAUX_ADV_IND PDUを使用しました。
Table 3.3は、ペイロードサイズの範囲について、LE 1M PHYおよびLE Coded PHY（S=8コーディング）を経由する接続のリンクレイヤデータチャネルPDUパケット期間の違いを示しています。 特定の実装の接続デューティサイクルは、この情報から簡単に計算できます。
Table 3.3
物理リンク識別子は、リンク層エアインタフェースパケットに含まれていない。 物理チャネル識別子は固定されているか、接続設定で決定されるか、または定期的な広告設定で決定される。 すべてのLEパケットにはアクセスアドレスが含まれます。これは、物理チャネル上の通信を識別し、物理的に近接して同じPHYチャネルを使用している異なる物理チャネル上のパケットを除外または無視するために使用されます。 アクセスアドレスは、パケットが非周期的広告に使用される広告物理チャネル（したがって、広告物理リンク）、定期広告に使用される定期物理チャネル、またはピコネット物理チャネル（したがってアクティブな物理的チャネルデバイスへのリンク）。 非周期的広告に使用されるLE広告物理チャネルは、固定アクセスアドレスを使用する。 定期広告に使用されるLE周期的物理チャネルおよびLEピコネット物理チャネルは、ランダムに生成された32ビット値をそれらのアクセスアドレスとして使用する。 これにより、LE定期広告またはLEピコネットで対処することができる、多数の周期的な広告および多数の能動的な装置が提供される。
全てのLEパケットはPDUヘッダを含む。 PDUヘッダは、物理チャネルを介して搬送される広告ブロードキャストまたは論理リンクのタイプを決定する。
広告チャネルPDUの場合、PDUヘッダは、広告ペイロードのタイプ、広告に含まれるアドレスのデバイスアドレスタイプ、および広告チャネルPDUペイロード長を含む。 ほとんどの広告チャネルPDUペイロードは、広告主のアドレスおよび広告データを含む。 1つの広告チャネルPDUペイロードは、広告主のデバイスアドレスと、広告が向けられるイニシエータのデバイスアドレスのみを含む。 スキャン要求ペイロードを含む広告チャネルPDUには、スキャナのデバイスアドレスと広告主のデバイスアドレスが含まれます。 スキャン応答を有する広告チャネルPDUは、広告主のデバイスアドレスとスキャン応答データとを含む。 接続要求ペイロードを含む広告チャネルPDUは、イニシエータのデバイスアドレス、広告主のデバイスアドレス、および接続設定パラメータを含む。
データチャネルPDUの場合、PDUヘッダは、論理リンク識別子（LLID）、次のシーケンス番号（NESN）、シーケンス番号（SN）、さらなるデータ（MD）およびペイロード長を含む。 制御コマンドを含むデータチャネルPDUの場合、データチャネルPDUペイロードは、コマンドに固有のコマンドオペコードおよび制御データを含む。 データPDUの認証に使用されるオプションのメッセージ整合性チェック（MIC）値があります。 データであるデータチャネルPDUの場合、データチャネルPDUペイロードはL2CAPデータを含む。
いくつかのタイプの物理チャネルが定義される。 すべてのBluetooth物理チャネルは、一時的なパラメータと組み合わされたPHY周波数のセットによって特徴付けられ、空間的な考慮事項によって制限されます。 基本的かつ適応されたピコネット物理チャネルでは、周波数ホッピングを使用して、干渉の影響を低減するため、および規制上の理由から周期的に周波数を変更する。
Bluetooth BR/EDRシステムとLEシステムは、物理チャネルの使用方法が若干異なります。
BR/EDRコアシステムでは、ピアデバイスは、通信のために共有物理チャネルを使用する。 これを達成するには、トランシーバを同じPHY周波数に同時にチューニングする必要があり、互いの公称範囲内にある必要があります。
RFキャリアの数が限られており、多くのBluetoothデバイスが同じ空間的および時間的エリア内で独立して動作している場合、 2つの独立したBluetoothデバイスが同じRFキャリアに同調されたトランシーバを有する可能性が高くなり、その結果物理的なチャネルの衝突が生じる。 この衝突の望ましくない影響を緩和するために、物理チャンネル上の各送信は、物理チャンネルに同調された装置による相関コードとして使用されるアクセスコードで始まる。 このチャネルアクセスコードは、物理チャネルのプロパティです。 アクセスコードは、すべての送信パケットの先頭に存在します。
いくつかのBR/EDR物理チャネルが定義されています。 それぞれが最適化され、異なる目的で使用されます。 これらの物理チャネルのうちの2つ（基本ピコネットチャネルおよび適合ピコネットチャネル）は、接続されたデバイス間の通信に使用され、特定のピコネットに関連付けられます その他のBR/EDR物理チャネルは、Bluetoothデバイスの検出（照会スキャンチャネル）および接続（ページスキャンチャネル）に使用されます。 同期スキャン物理チャネルは、デバイスによって、コネクションレススレーブブロードキャスト物理リンクに関するタイミングおよび周波数情報を取得するため、または現在のピコネットクロックを回復するために使用されます。
Bluetoothデバイスは、任意の時点で1つのBR/EDR物理チャネルしか使用できません。 複数の同時動作をサポートするために、デバイスはチャネル間で時分割多重を使用します。 このようにして、Bluetoothデバイスは、いくつかのピコネット内で同時に動作するように見えるだけでなく、発見可能で接続可能であるように見える。
Bluetoothデバイスが物理チャネルのタイミング、周波数、アクセスコードに同期されるたびに、このチャネルに「接続」されていると言われます（チャネル上の通信に積極的に関与しているかどうかにかかわらず）。 Bluetooth仕様では、デバイスはいつでも1つの物理チャネルにしか接続できないと想定しています。 アドバンスドデバイスは複数の物理チャネルに同時に接続することができますが、仕様ではこれが可能であるとは想定していません。
基本的なピコネットチャネルは、通常の動作中に接続されたデバイス間の通信に使用されます。
基本的なピコネットチャネルは、PHYチャネルを介してホッピングする擬似ランダムシーケンスによって特徴付けられる。 ホッピングシーケンスはピコネットに固有であり、マスタのBluetoothデバイスアドレスによって決定されます。 ホッピングシーケンスのフェーズは、マスタのBluetoothクロックによって決定されます。 ピコネットに参加しているすべてのBluetoothデバイスは、時間とホップに同期しています。
チャネルは、各スロットがPHYホップ周波数に対応するタイムスロットに分割される。 連続ホップは、異なるPHYホップ周波数に対応する。 タイムスロットには、ピコネットマスターのBluetoothクロックに応じて番号が付けられます。 パケットは、スロット境界で開始するように調整されたピコネットに参加するBluetoothデバイスによって送信される。 各パケットは、ピコネットマスターのBluetoothデバイスアドレスから派生したチャネルアクセスコードで始まります。
基本的なピコネットチャネルでは、マスターはチャネルへのアクセスを制御します。 マスタは偶数番号のタイムスロットでのみ送信を開始します。 マスタによって送信されたパケットは、スロット開始と整列され、ピコネットタイミングを定義する。 マスタによって送信されるパケットは、パケットタイプに応じて最大5つのタイムスロットを占有することができる。
各マスター送信は、論理トランスポートの1つに関する情報を運ぶパケットです。 スレーブデバイスは、応答して物理チャネル上で送信することができる。 応答の特性は、対処される論理的な転送によって定義されます。
例えば、非同期接続指向論理トランスポート（ACL）上で、アドレスされたスレーブ装置は、名目上次の（奇数番号の）スロット開始と整列した同じ論理トランスポートに関する情報を含むパケットを送信することによって応答する。 そのようなパケットは、パケットタイプに応じて、最大5つのタイムスロットを占有することができる。 ブロードキャスト論理トランスポートでは、スレーブは応答できません。
基本的なピコネットチャネルは、ピコネットマスタデバイス上で利用可能なリソースによってのみ制限される任意の数のBluetoothデバイスによって共有されてもよい。 1台のデバイスだけがピコネットマスターであり、他はすべてピコネットスレーブです。 すべての通信はマスターとスレーブの間で行われます。 ピコネットチャネル上のスレーブデバイス間の直接通信はありません。
ただし、ピコネット内でサポートできる論理トランスポートの数には制限があります。 つまり、チャネルを共有するBluetoothデバイスの数には理論的な制限はありませんが、マスターとのデータ交換に積極的に関与できるデバイスの数には限界があります。
基本的なピコネットチャネルは、汎用通信に使用されるいくつかの物理リンク、論理トランスポート、論理リンク、L2CAPチャネルをサポートします。
適合したピコネットチャネルは、基本的なピコネットチャネルと2つの点で異なる。 第1に、スレーブが送信する周波数は、前の送信においてマスタによって使用される周波数と同じである。 換言すれば、周波数は、マスタとそれに続くスレーブパケットとの間で再計算されない。 第2に、適応されたピコネットチャネルは、完全な79の周波数より少ない数に基づいてもよい。 「使用されていない」とマークされることによって、いくつかの周波数がホッピングパターンから除外されてもよい。 残りの79の周波数が含まれています。 2つのシーケンスは、基本疑似ランダムホッピングシーケンスが未使用周波数を選択するたびに、使用されたセットから選択された代替物で置き換えられることを除いて、同じである。 使用される周波数の組は、同じ適合化されたピコネットチャネル上の異なる物理リンク間で変化してもよい。
適合したピコネットチャネルは、基本的なピコネットチャネルと同じタイミングおよびアクセスコードを使用するので、2つのチャネル上の物理リンクはしばしば一致する。 基本的なピコネットチャネルまたは適合したピコネットチャネルのいずれかのスレーブがマスターとの同期を調整できるようにすることにより、意図的な利点が得られます。
適応されたピコネット物理チャネルのトポロジーおよびサポートされるレイヤは、基本的なピコネット物理チャネルと同一であるが、1つの例外として、適応されたピコネット物理チャネルでは、単一のマスタが単一のCSB論理トランスポートを使用して無制限のスレーブにデータを送信することが可能である。 ただし、この場合、データはマスターからスレーブへのみ転送され、スレーブからマスターへは転送されません。
デバイスが発見されるために、照会スキャンチャネルが使用される。 発見可能なデバイスは、その照会スキャンチャネルで照会要求をリッスンし、その要求に対する応答を送信します。 デバイスが他のデバイスを発見するために、疑似ランダム方式ですべての可能性のある照会スキャンチャネル周波数を反復（ホップ）し、各周波数で照会要求を送信し、応答を待ち受けます。
照会スキャンチャネルは、より遅いホッピングパターンに従い、アクセスコードを使用して、異なる物理チャネルを使用する2つの同じ場所に配置されたデバイスによる同じ無線周波数の時々の占有を区別します。 デバイスが他のデバイスを発見するために、疑似ランダム方式ですべての可能性のある照会スキャンチャネル周波数を反復（ホップ）し、各周波数で照会要求を送信し、応答を待ち受けます。
照会スキャンチャネルで使用されるアクセスコードは、すべてのBluetoothデバイスによって共有される照会アクセスコードの予約済みセットから取得されます。 一般的な照会には1つのアクセスコードが使用され、制限付きの照会には複数の追加アクセスコードが予約されています。 各デバイスは、複数の異なる照会スキャンチャネルにアクセスできます。 これらのチャネルのすべてが同一のホッピングパターンを共有するので、複数の照会スキャンチャネルが複数のアクセスコードを同時に相関させることができる場合、装置は同時に複数の照会スキャンチャネルを占有することができる。
照会スキャンチャネルの1つを使用するデバイスは、他のBluetoothデバイスからこのチャネル上で照会メッセージを受信するまで、そのチャネル上で受動的なままです。 これは、適切な照会アクセスコードによって識別されます。 照会走査装置は照会応答手順に続き、照会装置に応答を返す。
デバイスが他のBluetoothデバイスを検出するためには、照会スキャンチャネルを使用して照会要求を送信します。 発見するデバイスに関する事前知識がないため、照会スキャンチャネルの正確な特性を知ることはできません。
装置は、照会スキャンチャネルがホップ周波数の数が減少し、ホッピングの速度が遅いという事実を利用する。 照会装置は、照会スキャンホップ周波数のそれぞれについて照会要求を送信し、照会応答をリッスンする。 送信はより高速なレートで行われ、照会装置は適度に短い時間内にすべての照会スキャン周波数をカバーすることができる。
照会および発見可能なデバイスは、照会機能を果たすために単純なパケットの交換を使用します。 このトランザクション中に形成されるトポロジは、単純かつ一時的なポイントツーポイント接続です。
問い合わせ可能なデバイスと発見可能なデバイスとの間でパケットを交換する間に、これらのデバイス間に一時的な物理リンクが存在すると考えられる。 しかしながら、この概念は物理的表現を持たないが、デバイス間の簡単なトランザクションによってのみ暗示されるので、全く無関係である。 それ以上のアーキテクチャレイヤはサポートされていないと考えられます。
接続可能なデバイス（接続を受け入れる準備ができているデバイス）は、ページスキャンチャネルを使用します。 接続可能なデバイスは、そのページスキャンチャネル上でページ要求をリッスンし、受信すると、このデバイスとの一連の交換を開始します。 デバイスが別のデバイスに接続するためには、疑似ランダム方式ですべてのページスキャンチャネル周波数を反復（ホップ）し、各周波数でページ要求を送信し、応答を待ち受けます。
ページスキャンチャネルは、スキャンデバイスのBluetoothデバイスアドレスから派生したアクセスコードを使用して、チャネル上の通信を識別します。 ページスキャンチャネルは、基本および適合したピコネットチャネルのホップ速度よりも遅いホッピング速度を使用する。 ホップ選択アルゴリズムは、走査装置のBluetooth装置クロックを入力として使用する。
ページスキャンチャネルを使用するデバイスは、別のBluetoothデバイスからページリクエストを受信するまでパッシブのままです。 これは、ページスキャンチャネルアクセスコードによって識別されます。 次に、2つのデバイスがページ手順に従って接続を確立します。 ページ手順が正常に終了した後、両方の装置はページング装置をマスタとすることを特徴とする基本ピコネットチャネルに切り替える。
デバイスが別のBluetoothデバイスに接続するためには、デバイスはページリクエストを送信するためにターゲットデバイスのページスキャンチャネルを使用します。 ページング装置がターゲット装置のページスキャンチャネルの位相を知らない場合、ページング装置はターゲット装置の現在のホップ周波数を知らない。 ページングデバイスは、ページスキャンホップ周波数のそれぞれについてページ要求を送信し、ページ応答をリッスンする。 これは、より速いホップ速度で行われ、ページング装置が合理的に短い時間内にすべてのページスキャン周波数をカバーできるようにする。
ページングデバイスは、ターゲットデバイスのBluetoothクロック（2つのデバイス間の以前の照会トランザクションの間に、またはデバイスとのピコネットへの以前の関与の結果として示される）に関する何らかの知識を有することができ、 この場合、ターゲットデバイスのページスキャンチャネルの位相を予測することができます。 ページングプロセスとページスキャンプロセスの同期を最適化し、接続の形成をスピードアップするために、この情報を使用する場合があります。
ページングおよび接続可能なデバイスは、ページング機能を実行するために単純なパケット交換を使用します。 このトランザクション中に形成されるトポロジは、単純かつ一時的なポイントツーポイント接続です。
ページングと接続可能なデバイスとの間でパケットを交換する間に、これらのデバイス間に一時的な物理リンクが存在すると考えられる。 しかしながら、この概念は物理的表現を持たないが、デバイス間の簡単なトランザクションによってのみ暗示されるので、全く無関係である。 それ以上のアーキテクチャレイヤはサポートされていないと考えられます。
CSB論理トランスポートで送信されたパケットを受信するには、デバイスは、まず、それらのパケットのタイミングチャネルと周波数チャネルに関する情報を取得する必要があります。 デバイスがCoarse Clock Adjustment通知を失った場合は、現在のピコネットクロックを回復する必要があります。 同期スキャンチャネルは、これらの目的のために提供される。 走査装置は、同期走査チャネル上の同期列パケットをリッスンする。 同期トレインパケットが受信されると、デバイスはCSB論理トランスポート上で送信されたパケットの受信を開始するか、またはピコネットクロックを回復するのに必要なタイミングおよび周波数情報を有するため、同期トレインパケットの受信を停止することがあります。
同期走査チャネルは、同期列送信機のBluetoothデバイスアドレスから導出されたアクセスコードを使用して、チャネル上の同期列パケットを識別する。 同期トレインパケットが受信されると、スキャンBR/EDRコントローラは、ホストおよび適用可能なプロファイルの必要性に応じて、CSB論理トランスポートで送信されたパケットの受信を開始することがあります。
このスキャン中に形成されるトポロジは一時的でポイントツーマルチポイントです。 同じ同期列送信機からの同期列パケットを同時に受信する走査装置は無制限にすることができる。
同期列送信装置から走査装置へのパケットの一方向の流れがある。 これは、走査装置が必要な情報を受信するまでのみ存在する一時的な物理リンクと考えられる。 それ以上のアーキテクチャレイヤはサポートされていないと考えられます。
LEコアシステムでは、2つのBluetoothデバイスが共有物理チャネルを使用して通信します。 これを達成するには、トランシーバを同じPHY周波数に同期して調整する必要があり、相互の公称範囲内にある必要があります。
PHYチャネルの数は限られており、多くのBluetoothデバイスは同じ空間的および時間的領域内で独立して動作することができるので、 同じPHYチャネルに同調されたトランシーバを有する2対の独立したBluetooth装置が存在する可能性が高く、結果として衝突する。 アクセスコードを使用してピコネットを識別するBR/EDRとは異なり、LEはランダムに生成されたアクセスアドレスを使用してデバイス間の物理チャネルを識別します。 2つのデバイスが同じエリア内の同じPHYチャネルを共有する場合、ターゲットデバイスのアクセスアドレスは、通信がどのデバイスに向けられるかを決定する相関器として使用されます。
3つのLE物理チャネルが定義される。 それぞれが最適化され、異なる目的で使用されます。 LEピコネットチャネルは、接続されたデバイス間の通信に使用され、特定のピコネットに関連付けられています。 LE広告チャネルは、LEデバイスへの広告をブロードキャストするために使用されます。 これらの広告は、ユーザーデータを検出、接続、またはスキャナまたはイニシエータデバイスに送信するために使用できます。 定期的な物理チャネルは、指定された間隔で周期的な広告でユーザデータをスキャナ装置に送信するために使用される。
LEデバイスは、これらのLE物理チャネルのうちの1つをいつでも使用することができます。 複数の同時動作をサポートするために、デバイスはチャネル間で時分割多重を使用します。 このようにして、Bluetoothデバイスは、広告ブロードキャストを同時に送信しながら、接続されたデバイスをサポートするように見える。
LEデバイスが物理チャネルのタイミングおよび周波数に同期されるときはいつでも、LEデバイスはこのチャネルに接続または同期されていると言われます（チャネルを介した通信に積極的に関与しているかどうかにかかわらず）。 Bluetooth仕様では、デバイスは一度に1つの物理チャネルにしか接続できないと仮定しています。 アドバンスドデバイスは、複数の物理チャネルに同時に接続または同期することができる可能性がありますが、仕様ではこの前提はありません。
LEピコネットチャネルは、通常動作中に接続されたLEデバイス間の通信に使用されます。
LEピコネットチャネルは、PHYチャネルの擬似ランダムシーケンスと、マスタによって提供される3つの追加パラメータによって特徴付けられます。 第1のものは、ピコネットで使用されるPHYチャネルのセットを示すチャネルマップである。 第2のものは、PHYチャネルの完全なセットへのインデックスとして使用される疑似乱数である。 3番目は、接続要求後にマスタによって送信される最初のデータパケットのタイミングです。
チャネルは、各接続イベントがPHYホップチャネルに対応する接続イベントに分割されます。 連続する接続事象は、異なるPHYホップチャネルに対応する。 接続確立後にマスタによって送信される最初のパケットは、将来のすべての接続イベントのタイミングのためのアンカーポイントを設定します。 接続イベントでは、マスタはピコネット内のスレーブにパケットを送信し、スレーブはそれ自身のパケットで応答してもしなくてもよい。
LEピコネットチャンネルでは、マスターはチャンネルへのアクセスを制御します。 マスターは定期的に発生する接続イベントで送信を開始します。 マスタによって送信されたパケットは、接続イベントの開始と整合し、ピコネットのタイミングを定義します。 マスタによって送信されるパケットの長さは、10〜265オクテットの範囲で異なる場合があります。
各マスタ送信には、論理転送の1つに関する情報を運ぶパケットが含まれています。 スレーブデバイスは、応答として物理チャネルで送信できます。
LEピコネットチャネルは、干渉を避けるために使用されるPHYチャネルのセットを変更できる点で、BR/EDR適合ピコネットチャネルに類似している。 チャネルマップの使用チャネルのセットは、接続のセットアップ中にマスターによって確立されます。 接続中、マスタは、新しい干渉源を避けるために、必要なときにチャネルマップを変更することができます。
37のLEピコネットチャネルがあります。 マスタは、使用チャネルを示すチャネルマップを介してこの数を減らすことができます。 ホッピングパターンが使用されていないチャネルにヒットすると、使用されていないチャネルは、使用されたチャネルのセットからの代替と置き換えられます。 LE Piconet物理チャネルは、任意のLE PHYを使用できます。
LEピコネットチャネルは、ピコネットマスタデバイス上で利用可能なリソースによってのみ制限される任意の数のLEデバイスで共有できます。 ピコネットマスターは1台のみです。 他のすべてはピコネットのスレーブである。 すべての通信はマスターとスレーブの間で行われます。 ピコネットチャネル上のスレーブデバイス間の直接通信はありません。
ピコネット内でサポートできる論理的トランスポートの数には実質的に制限がありません。 これは、マスタとチャネルを共有するBluetoothデバイスの数に理論上の制限がないことを意味します。
LEデバイスは、一度に1つ以上のピコネットに属することが許可されている。 すなわち、LEデバイスは、ゼロ個以上のピコネット内のスレーブであってもよく、別のピコネットのマスターであってもよい。
2つのLEデバイスアイデンティティまたは解決できないプライベートアドレスの間には、1つのLEピコネットチャネルしか存在できません。
LEピコネットチャネルは、汎用通信に使用されるL2CAPチャネルをサポートします。
LE広告チャネルは、2つのデバイス間の接続をセットアップしたり、接続されていないデバイス間でブロードキャスト情報を通信したりするために使用されます。
LEの広告チャネルには、プライマリ広告チャネルとセカンダリ広告チャネルの2つがあります。
プライマリアドバタイズメントチャネルは、LE周波数スペクトル全体に均一に分散された3つの固定PHYチャネルのセットです。 干渉を低減するために、広告装置によって第1の広告用PHYチャネルの数を減らすことができる。 プライマリ広告チャネルは、LE 1MまたはLE Coded PHYのいずれかを使用できます。
プライマリ広告チャネルは、各広告イベントが3つの広告PHYチャネルすべてをホップすることができる広告イベントに分割される。 連続する広告イベントは、最初の広告PHYチャネルで開始されます。 広告イベントは、妨害回避を助けるためにランダムな遅延でわずかに修正された規則的な間隔で行われる。
プライマリ広告チャネルでは、広告装置はチャネルへのアクセスを制御する。 広告装置は、広告イベントにおいてその送信を開始し、広告パケットを3つの広告PHYチャネルのうちの1つ以上に送信する。 各広告パケットは、一定の間隔で異なる広告PHYチャネル上で送信される。 7つのタイプの広告イベントを使用することができ、各広告イベントタイプは異なるサイズの広告パケットを有する。 これらの広告パケットのPDUペイロードは、長さが6オクテットから37オクテットまで変化し得る。
広告装置によって送信されたいくつかの広告イベントは、聴取装置が、広告パケットが受信された同じ広告PHYチャネル上でスキャン要求または接続要求パケットを同時に送信することを可能にする。 広告装置は、同じ広告イベント内の同じ広告PHYチャネル上でスキャン応答パケットを再び送信することができる。 スキャン応答パケットのペイロードは、長さが6オクテットから37オクテットまで変化し得る。
セカンダリ広告チャネルは、LE周波数スペクトルにわたって広がった37個の固定PHYチャネルのセットである。 これらは、データチャネルで使用される同じ固定LE PHYチャネルです。 セカンダリ広告チャネルは、データチャネルと同じチャネルインデックスを使用します。 セカンダリ広告チャネル上で使用される広告パケットのペイロードは、長さが0から255オクテットまで変化し得る。 セカンダリ広告チャネル上の広告パケットは、広告イベントの一部ではなく、拡張広告イベントの一部である。 これらの拡張された広告イベントは、プライマリ広告チャネル上の広告イベントと同時に開始し、セカンダリ広告チャネル上の最後のパケットで終了する。
第2の広告チャネルは、第1の広告チャネル上で送信されるであろうデータをオフロードするために使用される。 セカンダリ広告チャネル上の広告パケット（「補助パケット」）は、十分な空中時間が利用可能であるときに、広告主によってスケジュールされる。 プライマリ広告チャネル上の広告パケットは、PHYチャネルと、補助パケットの開始時間に対するオフセットとを含む。
セカンダリ広告チャネルは、任意のLE PHYを使用することができる。 同じ拡張広告イベントにおける第2の広告チャネル上のすべての広告パケットは、第1の広告チャネル上の広告パケットで指定されたものと同じPHYを使用する。
LE広告チャネルは、任意の数のLEデバイスによって共有することができます。 任意の数のLEデバイスが、広告チャネルを共有しながら広告パケットを送信することができる。 任意の数の走査装置が広告チャネルで聴くことができる。 広告装置は、LEピコネットチャネル上で同時にアドバタイズして接続することができる。 スキャニング装置は、1つまたは複数のLEピコネットチャネルに同時に接続することもできます。
LE周期的物理チャネルは、未接続デバイス間の定期的なブロードキャストをセットアップするために使用される。
周期的な物理チャネルは、PHYチャネルの疑似ランダムシーケンスと、広告主によって提供される追加のパラメータによって特徴付けられる。 これらは、周期的ブロードキャストで使用されるPHYチャネルのセット、チャネルホッピングシーケンスを決定するために使用されるイベントカウンタ、第1の周期的ブロードキャストパケットのタイミングを示すオフセット、および連続する定期的ブロードキャストの間の間隔を示すチャネルマップである。
チャネルは、周期的な広告イベントに分割され、周期的な広告イベントの開始はPHYホップチャネルに対応する。 連続した定期的な広告イベントの開始は、異なるPHYホップチャネルに対応する。 ブロードキャストが確立された後に広告主によって送信される最初のパケットは、将来のすべての定期的な広告イベントのタイミングのためのアンカーポイントを設定する。
周期的な物理チャネル上で、広告装置はチャネルへのアクセスを制御する。 広告主は、定期的に発生する定期的な広告イベントで送信を開始する。 広告主によって送信されたパケットは、定期的な広告イベントおよび指定された放送タイミングに合わせられる。 広告主によって送信されたパケットのペイロードは、0オクテットから255オクテットまでの長さが異なる場合があります。
各広告主送信には、PADVB論理転送に関する情報を運ぶパケットが含まれています。 スキャナーは物理チャネルで送信できません。
37のPHYチャネルがあります。 広告主は、使用チャネルを示すチャネルマップを介してこの数を減らすことができる。 ホッピングパターンが使用されていないチャネルにヒットすると、使用されていないチャネルは、使用されたチャネルのセットからの代替と置き換えられます。 周期的な物理チャネルは任意のPHYを使用することができる。 すべての周期的広告イベントは、周期的物理チャネルの特性を記述するパケット内の広告主によって使用されるのと同じPHYを使用する。
LE周期的物理チャネルは、任意の数のLEデバイスによって共有することができる。 任意の数のLEデバイスが、周期的な物理PHYチャネルを共有しながら、定期的な広告パケットを送信することができる。 任意の数の走査装置が周期的な物理チャネル上で聴取することができる。 広告装置は、アドバタイズして、LE周期的物理チャネル上で同時に同期することができる。 スキャンデバイスも同期させることができます
AMP物理チャネルは、通常の動作中に接続されたデバイス間の通信に使用されます。 これは、関連するBR/EDRコントローラ間の適合したピコネットチャネルと並行して使用されます。
AMP物理チャネル特性は、参照されるMACおよびPHYに依存する。 各PALのMACとPHYについては、第5巻を参照してください。
AMP物理チャネルは、任意の数のBluetoothデバイスによって共有されてもよく、 ピコネットBR/EDRマスタデバイスで使用可能なリソースと使用可能なLT_ADDRの数によってのみ制限されます。 AMP物理チャネル内の役割は使用されません。 すべての通信は、BR/EDRピコネットマスタと単一のBR/EDRピコネットスレーブ間で行われます。 BR/EDRピコネットスレーブデバイスとAMP物理チャネルとの間の直接通信はありません。
AMP物理チャネルを共有できるBluetoothデバイスの数には理論的な制限はありませんが、基本および適応型ピコネットチャネルと同様に、マスターとのデータ交換に積極的に関与するデバイスの数には限界があります 。
AMP物理チャネルは、汎用通信に使用される多くの物理リンク、論理転送、論理リンク、およびL2CAPチャネルをサポートします。
物理リンクは、Bluetoothデバイス間のベースバンド接続を表します。 物理リンクは常に正確に1つの物理チャネルに関連付けられます（ただし、物理チャネルは複数の物理リンクをサポートできます）。 Bluetoothシステム内では、物理リンクは、送信されたパケットの構造内に直接的な表現を持たない仮想概念である。
BR/EDRでは、アクセスコードパケットフィールドは、マスタBluetoothデバイスのクロックおよびアドレスと共に、物理チャネルを識別するために使用される。 LEでは、チャネル選択アルゴリズム＃1の場合のhopIncrementを含むアクセスアドレスおよびチャネルマップ、またはチャネル選択アルゴリズム＃2の場合のイベントカウンタが、物理チャネルを識別するために使用される。 BR/EDRおよびLEの場合、物理リンクを直接識別するパケットの後続部分はありません。 代わりに、物理リンクは、各論理転送が1つの物理リンク上でのみ受信されるので、論理転送との関連によって識別されてもよい。
一部の物理リンクタイプには、変更可能なプロパティがあります。 この例はリンクの送信電力です。 他の物理リンクタイプには変更可能なプロパティはありません。 変更可能な特性を有する物理的リンクの場合、これらの特性を適合させるためにLMプロトコル（BR/EDR）が使用される。 LMプロトコル（BR/EDR）が（論理リンクによって）上位層でサポートされるとき、適切な物理リンクは、LMシグナリングを伝送する論理リンクからの含意によって識別される。 送信が多数の異なる物理リンクを介してブロードキャストされる状況では、送信パラメータは、すべての物理リンクに適合するように選択される。
基本的なピコネット物理チャネルは、アクティブでなければならない物理リンクをサポートする。 適合したピコネット物理チャネルは、アクティブおよびコネクションレススレーブブロードキャストを含むいくつかの物理リンクをサポートすることができる。 アクティブな物理リンクは、マスタとスレーブ間のポイントツーポイントリンクです。 コネクションレススレーブブロードキャスト物理リンクは、マスタとゼロ以上のスレーブ間のポイントツーマルチポイントリンクです。 スレーブがピコネット内で同期されるとき、ピコネット物理チャネル上の少なくとも1つの物理リンクが常に存在する。
マスターとスレーブデバイス間の物理リンクは、デバイス間にデフォルトのACL論理トランスポートが存在する場合にアクティブになります。 アクティブな物理リンクは、自身の直接の識別情報を持っていませんが、1対1対応のデフォルトのACL論理トランスポートIDとの関連付けによって識別されます。
アクティブな物理リンクは、各方向の無線送信電力の関連する特性を有する。スレーブデバイスからの送信は、常に、アクティブな物理リンクを介してマスタに向けられ、スレーブでこのリンクの特性である送信電力をマスタ方向に使用する。 マスタからの送信は、単一のアクティブな物理リンク（特定のスレーブへ）または多数の物理リンク（ピコネット内のスレーブのグループへ）を介して送信される場合があります。 ポイントツーポイント伝送の場合、マスタは問題の物理リンクに対して適切な送信電力を使用する。 （ポイントツーマルチポイント送信の場合、マスタはアドレス指定されたデバイスのセットに適した送信電力を使用する）。
アクティブな物理リンクをホールドまたはスニフモードにすることができます。 これらのモードの効果は、物理リンクがアクティブでトラフィックを伝送する可能性のある期間を変更することです。 スケジューリング特性を定義した論理トランスポートは、これらのモードの影響を受けず、あらかじめ定義されたスケジューリング動作に従って継続します。 デフォルトのACL論理転送および未定義のスケジューリング特性を持つ他のリンクは、アクティブな物理リンクのモードに従います。
CSB論理トランスポートが存在するピコネット内でスレーブが同期されている場合、スレーブにはコネクションレススレーブブロードキャスト物理リンクが存在します。 マスタ上では、スレーブが同期しているかどうかにかかわらず、CSB論理トランスポートが存在する場合に、コネクションレススレーブブロードキャスト物理リンクが存在します。
コネクションレススレーブブロードキャスト物理リンクは、マスタとゼロ以上のスレーブ間のポイントツーマルチポイント単方向リンクです。 コネクションレススレーブブロードキャスト物理リンクは、スレーブからマスタへのフィードバックがないため、電力制御をサポートしていません。 トラフィックは、常に1つのマスタからゼロ以上のスレーブに向けられます。
コネクションレススレーブブロードキャストパケットは定期的に送信されます。 BR/EDRコントローラは、ホストから要求された範囲内のインターバルを選択します。
照会スキャンおよびページスキャンチャネルの場合、物理リンクは比較的短時間存在し、いかなる方法でも制御または変更することはできない。 これらのタイプの物理的リンクは、これ以上詳しく述べられていない。
LEピコネット物理チャネルは、LEアクティブな物理リンクをサポートする。 物理リンクは、マスタとスレーブ間のポイントツーポイントリンクです。 スレーブがマスターと接続しているときは、常に存在します。
LE広告チャネルは、LE広告物理リンクをサポートする。 物理リンクは、広告主装置と1つ以上のスキャナまたはイニシエータ装置との間のブロードキャストである。 広告主が広告イベントをブロードキャストしているときには常に表示されます。
LE周期的物理チャネルは、LE周期的物理リンクをサポートする。 物理リンクは、広告主装置と1つ以上のスキャナ装置との間のブロードキャストである。 これは、広告主が定期的な広告イベントを放送しているときに常に表示されます。
マスタとスレーブデバイス間の物理リンクは、デバイス間にデフォルトのLE ACL論理トランスポートが存在する場合にアクティブになります。 アクティブな物理リンクはそれぞれ、別個のピコネット物理チャネルに関連付けられ、リンク層パケットで使用されるランダムに生成されたアクセスアドレスによって識別される。 各アクセスアドレスは、アクティブな物理リンクのマスタおよびスレーブと1対1の関係にあります。
広告装置と開始装置との間に、接続（アクティブな物理リンク）を形成する目的のための広告物理リンクは、比較的短期間存在することができる。 これらの広告物理リンクは、いかなる方法でも制御または変更することはできません。これらのタイプの物理リンクは、それ以上詳しく説明されていません。
広告装置と、ユーザデータの定期的な放送に使用される走査装置との間の広告物理リンクは、より長い期間存在することができる。 プロトコル内の物理リンクに関する識別情報はありません。 広告装置とスキャニング装置との関係は、Bluetooth装置のアドレスを使用して確立されなければならない。
広告装置と1つ以上の走査装置との間の周期的な物理的リンクは、通常、長期間にわたって存在する。 定期的な物理的リンクはそれぞれ、別々の周期的な物理チャネルに関連付けられ、リンク層パケットで使用されるランダムに生成されたアクセスアドレスによって識別される。 各アクセスアドレスは、定期的な物理リンクの広告主と1対1の関係にあります。
AMP物理リンクは常に1つのAMP物理チャネルに関連付けられます（ただし、AMP物理チャネルは複数のAMP物理リンクをサポートすることがあります）。 AMP物理リンクは、2つのPAL間のポイントツーポイントリンクです。 AMP物理リンクの特性は、基礎をなすAMP技術に依存する。
さまざまなアプリケーション・データ転送要件をサポートするために、さまざまな論理リンクを使用できます。 各論理リンクは、多数の特徴を有する論理トランスポートに関連付けられている。これらの特性には、フロー制御、肯定応答/反復メカニズム、シーケンス番号付け、およびスケジューリング動作が含まれます。 論理トランスポートは、（論理トランスポートのタイプに応じて）異なるタイプの論理リンクを運ぶことができます。 いくつかのBluetooth論理リンクの場合、これらは同じ論理転送に多重化されます。 論理トランスポートは、基本または適合したピコネット物理チャネル上のアクティブな物理リンクによって搬送することができる。
論理トランスポート識別とリアルタイム（リンク制御）シグナリングは、パケットヘッダ内で運ばれ、いくつかの論理リンクについては、ペイロードヘッダ内で識別が行われる。単一スロット応答時間を必要としない制御シグナリングは、LMPプロトコルを使用して実行される。
Table 3.4に、すべての論理トランスポートタイプ、サポートされている論理リンクタイプ、どのタイプの物理リンクと物理チャネルがそれらをサポートできるか、および論理トランスポートの目的の簡単な説明を示します。
Table 3.4
各リンクタイプの分類は、3つのカテゴリ内の選択手順に従う。
最初のカテゴリはキャスティングのカテゴリです。 これは、ユニキャストまたはブロードキャストのいずれかです。
-
ユニキャストリンク。 ユニキャストリンクは、ちょうど2つのエンドポイント間に存在します。 トラフィックは、ユニキャストリンク上でいずれの方向に送信されてもよい。
-
ブロードキャストリンク。 ブロードキャストリンクは、1つのソースデバイスと0個以上のレシーバデバイス間に存在します。 トラフィックは単方向であり、すなわち、ソースデバイスから受信デバイスにのみ送信される。 ブロードキャストリンクはコネクションレスです。 つまり、これらのリンクを作成する手順はなく、いつでもデータを送信することができます。 ブロードキャストリンクは信頼性が低く、データが受信される保証はありません。
第2のカテゴリは、リンクのスケジューリングおよび肯定応答スキームに関連し、リンクによってサポートされるトラフィックのタイプを意味する。 これらは同期、アイソクロナスまたは非同期です。 特定のアイソクロナスリンクは定義されていませんが、デフォルトのACLリンクはこのように動作するように設定できます。
-
同期リンク。 同期リンクは、転送されたデータをBluetoothピコネットクロックに関連付ける方法を提供します。 これは、物理チャネル上に規則的なスロットを予約し、これらの規則的な間隔で固定サイズのパケットを送信することによって達成される。 そのようなリンクは、等速データの等時性データに適している。
-
非同期リンク。 非同期リンクは、時間ベースの特性を持たないデータを転送する方法を提供します。 データは、正常に受信されるまで通常は再送されると予想され、各データエンティティは、ストリーム内の以前のまたは連続するエンティティの受信時を参照することなく、受信後の任意の時点で処理されることができる（データエンティティの順序付けが保存される ）。
-
アイソクロナスリンク。 アイソクロナスリンクは、時間ベースの特性を持つデータを転送する方法を提供します。 データは、受信または期限切れになるまで再送することができる。 リンク上のデータレートは一定である必要はありません（これは同期リンクとの主な違いです）。
最後のカテゴリは、リンクによって運ばれるデータのクラスに関連しています。 これは、制御（LMPまたはPAL）データまたはユーザーデータのいずれかです。 ユーザーデータカテゴリは、L2CAP（またはフレーム）データとストリーム（またはフレームなし）データに細分されます。
-
コントロールリンク。 制御リンクは、2つのリンクマネージャ間でLMPメッセージを転送する場合にのみ使用されます。 これらのリンクは、ベースバンド層の上には見えないため、アプリケーションによって直接インスタンス化、設定、または解放することはできません。 暗黙的にこの影響を受ける接続サービスと切断サービスを使用すること以外はできません。 ARQスキームを規定する規則の下で、制御リンクトラフィックは常にL2CAPリンクトラフィックよりも優先されます。
-
L2CAPリンク。 L2CAPリンクは、L2CAPシグナリングチャネル（デフォルトのACL-U論理リンクのみ）またはフレーム化されたユーザデータをユーザがインスタンス化したL2CAPチャネルに送信するL2CAP PDUを転送するために使用されます。 ベースバンドに提出されたL2CAPフレームは、利用可能なベースバンドパケットよりも大きい場合があります。 LLIDフィールド内に埋め込まれたリンク制御プロトコルは、フレームが多数のフラグメントで受信機に送信されるとき、フレーム開始およびフレーム継続セマンティクスを保存する。
-
ストリームリンク。 ストリームリンクは、データを配信する際に保存されるべき固有のフレーミングを持たないユーザーデータを転送するために使用されます。 紛失したデータは、受信機でパディングすることで置き換えることができます。
非同期接続指向（ACL）論理転送は、LMPおよびL2CAP制御シグナリングおよびベストエフォート型非同期ユーザデータを伝送するために使用されます。 ACL論理トランスポートは、単純なチャネル信頼性を提供するために1ビットのARQN / SEQN方式を使用します。 ピコネット内のすべてのアクティブなスレーブデバイスには、デフォルトのACLと呼ばれるピコネットマスターへの1つのACL論理転送があります。
デバイスがピコネットに参加するとき（基本ピコネット物理チャネルに接続するとき）、デフォルトのACLがマスタとスレーブの間に作成されます。 このデフォルトACLには、ピコネットマスターによって論理トランスポートアドレス（LT_ADDR）が割り当てられます。 このLT_ADDRは、必要に応じてアクティブな物理リンクを識別するためにも使用されます（同じ目的のためにピコネット・アクティブ・メンバー識別子として有効に使用されます）。
デフォルトのACLのLT_ADDRは、同じマスターとスレーブ間の同期接続された論理転送に再利用されます。 （これは以前のBluetooth仕様との互換性のためです）。 したがって、LT_ADDRはデフォルトACLを識別するのに十分ではありません。 ただし、ACLで使用されるパケットタイプは、同期接続指向の論理転送で使用されるパケットタイプとは異なります。 したがって、ACL論理トランスポートは、パケットタイプフィールドと組み合わせてパケットヘッダ内のLT_ADDRフィールドによって識別することができる。
デフォルトのACLは、パケットが期限切れになった後に自動的にパケットをフラッシュするように設定して、アイソクロナスデータ転送に使用できます。 非同期トラフィックは、非同期パケットを非自動フラッシュ可能とマークすることで、アイソクロナストラフィック用に設定されたACL論理転送を介して送信できます。 これにより、アイソクロナスと非同期の両方のトラフィックを同時に1つのデバイスに転送することができます
アクティブな物理リンクからデフォルトのACLが削除されると、マスターとスレーブの間に存在する他のすべての論理転送も削除されます。 予期しないピコネット物理チャネルへの同期の喪失の場合、この同期損失が検出された時点で、物理リンクおよびすべての論理転送および論理リンクが存在しなくなる。
同期接続指向（SCO）論理転送は、マスタと特定のスレーブ間の対称的なポイントツーポイント転送です。 SCO論理転送は、物理チャネル上にスロットを予約するので、マスタとスレーブ間の回線交換接続と見なすことができます。 SCO論理転送は、ピコネットクロックに同期した64kb/sの情報を伝送する。 通常、この情報はエンコードされた音声ストリームです。 3つの異なるSCO構成が存在し、堅牢性、遅延および帯域幅消費のバランスを提供します。
各SCO-S論理リンクは、デバイス間のデフォルトのACL論理転送と同じLT_ADDRが割り当てられた単一のSCO論理転送によってサポートされます したがって、LT_ADDRフィールドは、受信したパケットの宛先を識別するのに十分ではない。 SCOリンクは予約されたスロットを使用するため、デバイスは、SC_リンク上の伝送を識別するために、LT_ADDR、スロット番号（物理チャネルの特性）およびパケットタイプの組み合わせを使用する。
スロットはSCO用に予約されていますが、プライオリティの高い別のチャネルからのトラフィックに予約スロットを使用することはできます。 これは、QoSコミットメントの結果として必要となる場合や、物理チャネル帯域幅がSCOによって完全に占有されている場合にデフォルトACLでLMPシグナリングを送信する場合があります。 SCOは異なるパケットタイプをACLに伝送するので、パケットタイプはSCOトラフィック（スロット番号とLT_ADDRに加えて）を識別するために使用されます。
SCOリンクを介して転送されるBluetoothコア仕様で定義されたアーキテクチャ層はありません。 移送される64kb/sストリームに対していくつかの標準フォーマットが定義されているか、アプリケーションがストリームのエンコーディングを解釈する場所でフォーマットされていないストリームが許可されている。
拡張同期接続指向（eSCO）論理転送は、マスタと特定のスレーブ間の対称または非対称のポイントツーポイント転送です。 eSCOは、物理チャネル上にスロットを予約しているため、マスタとスレーブ間の回線交換接続と見なすことができます。 eSCOリンクは、パケットと選択可能なスロット期間でパケットタイプと選択可能なデータコンテンツのより柔軟な組み合わせをサポートし、同期ビットレートの範囲をサポートできるという点で、標準SCOリンクに比べて多くの拡張を提供します。
eSCOリンクは、（再送信がないSCOリンクとは異なり）パケットの制限された再送信を提供することもできます。 これらの再送信が必要な場合、予約されたスロットに続くスロットで行われます。そうしないと、スロットは他のトラフィックに使用されます。
各eSCO-S論理リンクは、単一のeSCO論理トランスポートによってサポートされ、eSCOの期間、ピコネット内で一意のLT_ADDRによって識別されます。 eSCO-Sリンクは、LMシグナリングを使用して作成され、SCO-Sリンクと同様のスケジューリングルールに従います。
eSCO-Sリンクを介して転送されるBluetoothコア仕様で定義されたアーキテクチャ層はありません。 代わりに、アプリケーションは、転送されているデータに適したストリームの転送特性に従って、必要な目的に応じてデータストリームを使用することができます。
アクティブスレーブブロードキャスト論理トランスポートは、ASBによって使用されている物理チャネルに現在接続されているピコネット内のすべてのデバイスに、LMP制御シグナリングおよびコネクションレスL2CAPユーザトラフィックを転送するために使用されます。 肯定応答プロトコルはなく、トラフィックはピコネットマスターからスレーブへの一方向です。 ASBチャネルは、L2CAPグループトラフィック（1.1仕様のレガシー）に使用され、L2CAP接続指向チャネルまたはL2CAP制御シグナリングに使用されることはありません。
ASB論理トランスポートは、確認応答の欠如のために本質的に信頼性がありません。 信頼性を向上させるために、各パケットは何度も送信されます。 同一のシーケンス番号が、スレーブデバイスにおける再送信のフィルタリングを支援するために使用される。 ASB論理転送は、予約されたLT_ADDRによって識別される。
ASBは、ピコネットが存在する場合はいつでも暗黙的に作成され、ピコネット内に存在するアクティブな物理リンク（基本または適合したピコネット物理チャネル上で動作しているかどうかにかかわらず） 適応されたピコネット物理チャネル上の基本および適合ピコネット物理チャネルおよび異なるチャネルマップはほとんど一致しているので、スレーブ装置は、どのASBチャネルがパケットを送信するために使用されているかを区別することができない。 これにより、ASBチャネルの一般的な信頼性が向上します。 （おそらく、一般的な欠落したパケットよりも信頼性が低いわけではありませんが）。
マスターデバイスは、2つの可能なASBのうちの1つだけを使用することを決定することができます（基本および適応ピコネット物理チャネルの両方を持つ場合）。 または適応されたピコネット物理チャネル上で使用中のチャネルマップのうちの1つのみ（複数のマップを有する場合）。 すべてのスレーブをアドレスすることが可能な十分な再送または送信すべきスロットの慎重な選択のように、
ASBチャネルは、L2CAP制御信号を搬送するために決して使用されない。
LE非同期接続（LE ACL）論理転送は、LLおよびL2CAP制御シグナリングおよびベストエフォート型非同期ユーザデータを搬送するために使用される。 LE ACL論理トランスポートは、1ビットのNESN / SN方式を使用して簡単なチャネルの信頼性を提供します。 LEピコネット内のすべてのアクティブなスレーブデバイスは、デフォルトのLE ACLと呼ばれるピコネットマスターへのLE ACL論理トランスポートを1つ持っています。
デフォルトのLE ACLは、デバイスがピコネットに参加するとき（LEピコネットの物理チャネルに接続するとき）、マスタとスレーブ間で自動的に作成されます。 このアクセスアドレスは、必要に応じてアクティブな物理リンクとアクティブなピコネット物理チャネルを識別するためにも使用されます。
デフォルトのLE ACLがLEのアクティブな物理リンクから削除されると、マスタとスレーブの間に存在する他のすべてのLE論理転送も削除されます。 LEピコネット物理チャネルへの予期せぬ同期の損失の場合、LE物理リンクとすべてのLE論理転送およびLE論理リンクは、この同期損失が検出された時点で存在しなくなる。
LE広告ブロードキャスト論理転送は、ブロードキャスト制御およびユーザデータを所与の領域内のすべてのスキャンデバイスに転送するために使用される。 肯定応答プロトコルはなく、トラフィックは広告装置から主に一方向である。 スキャンデバイスは、論理トランスポートを介して要求を送信して、追加のブロードキャストユーザーデータを取得したり、LE ACL論理トランスポート接続を形成することができます。 LE広告放送ロジカルトランスポートデータは、LE広告ブロードキャストリンク上でのみ運ばれる。
ADVB論理トランスポートは、本来、肯定応答がないために信頼性が低い。 信頼性を向上させるために、各パケットは、LE広告ブロードキャストリンクを介して何度も送信される。
ADVBは、広告装置が広告を開始するたびに作成されます。 ADVB論理転送は、広告主のBluetoothデバイスアドレスと広告セットによって識別されます。
CSB論理トランスポートは、プロファイルブロードキャストデータをコネクションレススレーブブロードキャスト論理トランスポートに接続されたすべてのデバイスに転送するために使用されます。 肯定応答スキームはなく、トラフィックはマスタからゼロ以上のスレーブへの一方向です。 信頼性を向上させるために、プロファイルブロードキャストデータを複数回送信することができる。
CSB論理トランスポートは、コネクションレススレーブブロードキャストが開始されるたびにトランスミッタ上に作成されます。 コネクションレススレーブブロードキャスト受信が設定されるたびに、CSB論理トランスポートがレシーバ上に作成されます。 CSB論理トランスポートは、その目的のためにコネクションレススレーブブロードキャストトランスミッタによって特別に予約されたピコネット内の一意のLT_ADDRによって識別される。
LE周期的広告ブロードキャスト論理トランスポートは、定期的なブロードキャスト制御およびユーザデータを所定の領域内のすべてのスキャンデバイスに転送するために使用される。 データは、いくつかの期間にわたって一定であってもよいし、頻繁に変化してもよい。 承認プロトコルはなく、トラフィックは広告デバイスから一方向です。 LE周期的広告ブロードキャスト論理トランスポートデータは、LE定期物理リンク上でのみ伝送される。
PADVB論理トランスポートは、本来、肯定応答がないために信頼性が低い。 信頼性を向上させるために、送信間の期間は、各パケットがLE周期的物理リンクを介して何度も送信されるように、データ変更の間隔よりも短くすることができる。
PADVBは、広告装置が定期的な広告を開始するたびに作成されます。 PADVB論理転送は、広告主のBluetoothデバイスのアドレス、タイミング、および広告セットによって識別されます。
いくつかの論理トランスポートは、同時に多重化された、または選択された、異なる論理リンクをサポートすることができる。
BR / EDR論理トランスポート内では、論理リンクは、データペイロードを搬送するベースバンドパケットのペイロードヘッダ内の論理リンク識別子（LLID）ビットによって識別される。 論理リンクは、論理トランスポート上でデータを送受信することができる限られたコアプロトコルセットを区別します。 すべての論理トランスポートがすべての論理リンクを運ぶことができるわけではありません（サポートされているマッピングはFigure 3.2に示されています）。 特に、BR/EDR SCOおよびeSCO論理トランスポートは、一定のデータレートストリームのみを運ぶことができ、これらはLT_ADDRによって一意に識別されます。 このような論理トランスポートは、その長さが事前に分かっているため、ペイロードヘッダーを含まないパケットのみを使用し、LLIDは必要ありません。
ACL制御論理リンク（ACL-CおよびASB-C）は、ピコネット内のデバイス間でBR / EDR LMPシグナリングを伝送するために使用されます。 ACL-C制御リンクはデフォルトのACL論理転送でのみ実行され、ASB-C制御リンクはASB論理転送でのみ実行されます。 各制御リンクは、常に同じ論理転送で搬送される対応するデータリンクより優先されます。
ユーザの非同期/アイソクロナス論理リンク（ACL-UおよびASB-U）は、すべての非同期およびアイソクロナスフレームのユーザデータを伝送するために使用されます。 ACL-UリンクはデフォルトのACL論理転送でのみ実行され、ASB-UリンクはASB論理転送でのみ実行されます。 ACL-UおよびASB-Uリンク上のパケットは、2つの予約済みLLID値の1つによって識別されます。 1つの値は、ベースバンドパケットがL2CAPフレームの開始を含み、他の値が前のフレームの継続を示すかどうかを示すために使用される。 これにより、フラッシュされたパケットに続くL2CAPリアセンブラの正しい同期が保証されます。 この技法を使用すると、すべてのベースバンドパケットでより複雑なL2CAPヘッダーが不要になります（ヘッダーはL2CAP開始パケットでのみ必要です）が、新しいL2CAPフレームが送信される前に完全なL2CAPフレームが送信されるという要件が追加されます。 （このルールの例外は、部分的に送信されたL2CAPフレームをフラッシュして、別のL2CAPフレームを優先する機能です）。
同期化（SCO-S）および拡張同期（eSCO-S）論理リンクは、フレーミングなしでストリームに配信されるアイソクロナスデータをサポートするために使用されます。 これらのリンクは、一定の速度で一定のサイズの単位でデータが配信される単一の論理転送に関連付けられています。 これらのトランスポート上のパケットには、単一の論理リンクしかサポートできないため、LLIDはありません。パケット長とスケジューリング期間は事前定義され、リンクの存続期間中は固定されたままです。 可変レートアイソクロノスデータは、SCO-SまたはeSCO-S論理リンクによって伝送することはできません。 この場合、データは、ペイロードヘッダーを持つパケットを使用するACL-UまたはASB-U論理リンク上で伝送されなければなりません。
PBD論理リンクは、等時性のフレーム化されていないデータを複数の受信者にブロードキャストするために使用され、CSB論理トランスポートに常駐します。
LE論理転送内では、論理リンクは、データペイロードを運ぶベースバンドパケットのペイロードヘッダ内の論理リンク識別子（LLID）ビットによって識別される。 論理リンクは、論理トランスポート上でデータを送受信することができる限られたコアプロトコルセットを区別します。 すべての論理トランスポートがすべての論理リンクを運ぶことができるわけではありません（サポートされているマッピングはFigure 3.2に示されています）。
LE ACL制御論理リンク（LE-C）は、ピコネット内のデバイス間でLE LLシグナリングを伝送するために使用される。 制御リンクは、デフォルトのLE ACL論理転送でのみ実行されます。
ユーザー非同期論理リンク（LE-U）は、すべての非同期およびフレーム化されたユーザーデータを伝送するために使用されます。 LE-UリンクはLE論理転送で運ばれます。 LE-Uリンク上のパケットは、2つの予約済みLLID値のうちの1つによって識別される。 1つの値は、ベースバンドパケットがL2CAPフレームの開始を含むかどうかを示すために使用され、もう1つは、前のフレームまたは空のPDUの継続を示す。 これにより、L2CAPリアセンブ러の正しい同期が保証されます。 この技術を使用すると、すべてのベースバンドパケットでより複雑なL2CAPヘッダーが不要になりますが、新しいL2CAPフレームが送信される前に完全なL2CAPフレームが送信されるという要件が追加されます。
LE広告ブロードキャストコントロール論理リンク（ADVB-C）は、所定のエリア内の未接続デバイス間でLE LLシグナリングを伝送するために使用される。 このシグナリングは、追加のブロードキャストユーザデータ（スキャン要求）または接続要求を収集するための制御コマンドです。 制御リンクは、LE広告放送およびLE定期的な広告放送論理転送で運ばれます。
LE広告放送ユーザデータ論理リンク（ADVB-U）は、機器間で使用されるLE広告放送およびLE周期的広告放送ユーザデータを、機器間の接続またはLE-Uを必要とせずに搬送するために使用される。 ユーザーデータリンクは、LE広告ブロードキャストユーザーデータ用のLE広告ブロードキャスト論理転送と、LE定期ブロードキャストユーザーデータ用のLE定期ブロードキャスト広告転送で運ばれます。
各PALは、制御論理リンクに関して異なって機能する。 存在する場合、この論理リンクはAMP-C論理リンクと呼ばれます。
AMPユーザの非同期/アイソクロナス論理リンク（AMP-U）は、すべての非同期および等時性フレーム・ユーザ・データをAMPで伝送するために使用されます。 ACL-U論理リンクとは異なり、AMP-Uは物理リンクごとに複数の論理リンクハンドルをサポートし、各論理リンクハンドルは異なるサービス品質機能を持つことができます。 AMP-U論理リンクが基礎となるMAC / PHYにどのようにマップされるかの詳細は、PALによって記述される。
L2CAPは多重化の役割を提供し、多くの異なるアプリケーションがACL-UまたはAMP-U論理リンクを共有できます。 アプリケーションとサービスプロトコルは、チャネル指向のインターフェイスを使用してL2CAPとインターフェイスし、他のデバイス上の同等のエンティティへの接続を作成します。
L2CAPチャネルエンドポイントは、チャネル識別子（CID）によってクライアントに識別されます。 これはL2CAPによって割り当てられ、任意のデバイス上の各L2CAPチャネルエンドポイントは異なるCIDを持ちます。
L2CAPチャネルは、アプリケーションに適切なサービス品質（QoS）を提供するように構成することができる。 L2CAPは、チャネルをACL-U論理リンク、LE-U、またはAMP-U論理リンクの1つにマッピングします。
L2CAPは、接続指向のチャネルとグループ指向のチャネルをサポートします。 グループ指向チャネルは、ASB-U論理リンクにマッピングされてもよいし、順にACL-U論理リンクを介して各メンバーへの反復送信として実装されてもよい。
L2CAPの主な役割は、チャネルの作成、設定、および解体のほかに、チャネルクライアントからのサービスデータユニット（SDU）をACL-U、LE-U、またはAMP-U論理リンクに多重化し、 優先順位に従ってSDUを選択する単純なレベルのスケジューリングを実行することができる。
L2CAPは、ピアL2CAPレイヤでチャネルごとにフロー制御を提供できます。 このオプションは、チャネルが確立されたときにアプリケーションによって選択されます。 L2CAPはまた、 （a）検出されなかったエラーがアプリケーションに渡される確率を低減するため、 （b）ベースバンド層がACL-U論理リンク上でフラッシュを実行するときに、ユーザデータの一部が失われたことから回復するために、 拡張されたエラー検出および再送信を提供することができる
HCIが存在する場合には、L2CAPはまた、ベースバンドバッファに収まる断片にL2CAP SDUを分割し、HCIを介してトークンベースのフロー制御手順を動作させ、フラグメントを許可されたときにのみベースバンドに提出することも要求される。 これは、スケジューリングアルゴリズムに影響を与える可能性があります。
BR / EDRコントローラを使用してリンクが作成されるたびに、そのリンクはピコネットのコンテキスト内にあります。 ピコネットは、同じBR / EDR物理チャネルを占有する2つ以上のデバイスで構成されます。
接続されたBR / EDRデバイスは、共通のクロックおよびホッピングシーケンスと同期することによって、同じ物理チャネル上で通信します。 共通（ピコネット）クロックは、ピコネットのマスタと呼ばれるピコネット内のデバイスのBluetoothクロックと同一であり、ホッピングシーケンスはマスタのクロックとマスタのBluetoothデバイスアドレスから取得されます。 他のすべての同期デバイスは、ピコネット内のスレーブと呼ばれます。
マスタとスレーブという用語は、ピコネット内でこれらの役割を記述するときにのみ使用されます。
多くの独立したピコネットが近接して存在することがあります。 各ピコネットは、異なる物理チャネル（すなわち、異なるマスタデバイスおよび独立したタイミングおよびホッピングシーケンス）を有する。
Bluetoothデバイスは、2つ以上のピコネットに同時に参加することができます。 これは、時分割多重方式でこれを行います。 Bluetoothデバイスは、複数のピコネットのマスターになることはありません。 （BR / EDRではピコネットはマスターのBluetoothクロックと同期して定義されているため、2つ以上のピコネットのマスタになることはできません）。 Bluetoothデバイスは、多くの独立したピコネットのスレーブになる可能性があります。
2つ以上のピコネットのメンバーであるBluetoothデバイスは、スキャッタネットに関与していると言われています。 スキャッタネットに関与しても、ブルートゥースデバイスのネットワークルーティング機能や機能を必ずしも意味するものではありません。 Bluetoothコアプロトコルは、そのような機能を提供するものではなく、上位プロトコルの責任であり、Bluetoothコア仕様の範囲外です。
Figure 4.1: Example Bluetooth BR/EDR topology
Figure 4.1では、以下に説明するいくつかのアーキテクチャ上の特徴を示すトポロジの例を示します。 デバイスAは、デバイスB、C、DおよびEをスレーブとして持つピコネット内のマスタ（斜線領域で表され、ピコネットAと呼ばれます）です。 他の3つのピコネットが示されている：a）デバイスFをマスタとする1つのピコネット（ピコネットFとして知られている）、デバイスE、G、Hがスレーブであり、 b）マスタであるデバイスD（ピコネットDとして知られている）とスレーブであるデバイスJとを有する1つのピコネットは、 c）デバイスMをマスタ（ピコネットMとして知られている）とデバイスEをスレーブとし、多くのデバイスNをスレーブとする1つのピコネット。
ピコネットAには、2つの物理チャネルがあります。 デバイスBおよびCは、適応型周波数ホッピングをサポートしていないため、基本ピコネット物理チャネル（青色エンクロージャで表されます）を使用しています。 デバイスDおよびEは、適応周波数ホッピングをサポートすることができ、適応されたピコネット物理チャネル（赤いエンクロージャで表される）を使用している。 デバイスAは、適応型周波数ホッピングが可能であり、どちらのスレーブがアドレス指定されているかによって、両方の物理チャネル上でTDMベースで動作する。
ピコネットDとピコネットFは、どちらも基本的なピコネット物理チャネル（シアンとマゼンタのエンクロージャでそれぞれ表されている）のみを使用しています。 ピコネットDの場合、これは、デバイスJが適応ホッピングモードをサポートしていないためである。 デバイスDは適応型ホッピングをサポートしていますが、このピコネットでは使用できません。 ピコネットFでは、Fは適応ホッピングをサポートしないため、このピコネットでは使用できません。
ピコネットM（オレンジ色のエンクロージャで表される）は、プロファイルブロードキャストデータをEおよびNを含む多くのスレーブデバイスに送信するために、適応型ピコネット物理チャネル上のコネクションレススレーブブロードキャスト物理リンクを使用します。
デバイスKは、他のデバイスと同じ地域に表示されます。 現在、ピコネットのメンバーではありませんが、他のBluetoothデバイスに提供するサービスはあります。 現在、別のデバイスからの照会要求を待っている照会スキャンの物理チャネル（緑色のエンクロージャで表される）をリスンしています。
デバイスLは、他のデバイスと同じ地域に表示されます。 現時点ではピコネットのメンバーではありませんが、現在、同期スキャンの物理チャネル（茶色のエンクロージャで表されています）を待機しており、別のデバイスから同期トレインを待っています。
Figure 4.2: Example of Bluetooth LE topology
図4.2に、以下で説明する多くのLEアーキテクチャ機能を示すトポロジの例を示します。 デバイスAは、デバイスBおよびCをスレーブとして持つピコネット内のマスタ（斜線領域で表され、ピコネットAと呼ばれます）です。 BR / EDRスレーブとは異なり、LEスレーブはマスターと共通の物理チャネルを共有しません。 各スレーブは、マスタと別の物理チャネルで通信します。 他の1つのピコネットは、デバイスFがマスタ（ピコネットFとして知られている）とデバイスGがスレーブとして示されている。 デバイスKはスキャッタネット（スキャッタネットKとして知られている）にある。 デバイスKは、デバイスLのマスタであり、デバイスMのスレーブである。デバイスOは、スキャッタネット（スキャッタネットO）としても知られている。
デバイスOはデバイスPのスレーブ、デバイスQはスレーブです。注：この図では、実線の矢印がマスタからスレーブを指しています。 点線の矢印は、接続開始を示し、接続可能な広告イベントを使用して開始者から広告主を指示する。 広告を出しているデバイスは星印で表示されます。
表示される他の5つのデバイスグループがあります：
- 1 デバイスDは広告主であり、デバイスAもイニシエータである（グループDと呼ばれる）。
- 2 装置Eはスキャナであり、装置Cもまた広告主（グループCとして知られている）である。
- 3 デバイスHは広告主であり、デバイスIおよびJはスキャナ（グループHとして知られている）である。
- 4 デバイスKもまた広告主であり、デバイスNはイニシエータ（グループKとして知られる）である。
- 5 デバイスRは広告主であり、デバイスOはイニシエータ（グループRと呼ばれる）でもあります。
デバイスAおよびBは、1つのLEピコネット物理チャネル（青色のエンクロージャと濃いグレーの背景で表されます）を使用しています。 デバイスAとCは、別のLEピコネット物理チャネル（青いエンクロージャと薄い灰色の背景で表されます）を使用しています。 Dグループでは、デバイスDは、広告物理チャネル（緑色のエンクロージャで表される）上の接続可能な広告イベントを使用して広告を行い、デバイスAはイニシエータである。 デバイスAは、デバイスDとの接続を形成し、そのデバイスをピコネットAに追加することができる。 グループCでは、デバイスCは、デバイスEによってスキャナとして捕捉される任意のタイプの広告イベントを使用して、広告物理チャネル（オレンジ色の筐体によって表される）上にも広告を掲載している。 グループDおよびグループCは、衝突を回避するために、異なる広告PHYチャネルまたは異なるタイミングを使用している可能性がある。
ピコネットFでは、1つの物理チャネルが存在する。 デバイスFおよびGは、LEピコネット物理チャネル（アクアエンクロージャで表される）を使用しています。 デバイスFはマスタであり、デバイスGはスレーブである。
グループHでは、1つの物理チャネルが存在する。 デバイスH、IおよびJは、LE広告物理チャネル（紫色のエンクロージャで表される）を使用しています。 デバイスHは広告主であり、デバイスIおよびJはスキャナである。
スキャッタネットKにおいて、デバイスKおよびLは、1つのLEピコネット物理チャネルを使用している。 デバイスKおよびMは別のLEピコネット物理チャネルを使用している。 グループKにおいて、デバイスKはまた、広告物理チャネル上の接続可能な広告イベントを使用して広告を出しており、デバイスNは、イニシエータである。 デバイスNはデバイスKとの接続を形成することができ、デバイスKは2つのデバイスのスレーブであり、同時に1つのデバイスのマスタである。
スキャタネットOでは、デバイスOおよびPは1つのLEピコネット物理チャネルを使用しています。 デバイスOおよびQは別のLEピコネット物理チャネルを使用しています。 グループRにおいて、デバイスRは、広告物理チャネル上の接続可能な広告イベントを使用して広告を行い、デバイスOは、開始者である。 デバイスOは、デバイスRが2つのデバイスのスレーブであり、同時に1つのデバイスのマスタであるデバイスRとの接続を形成することができる。
ブルートゥースデバイスの典型的な動作モードは、（ピコネット内の）他のブルートゥースデバイスに接続され、それらのブルートゥースデバイスとデータを交換することである。 ブルートゥースはアドホックな無線通信技術であるため、後続の通信が行われるようにピコネットを形成することができる多くの操作手順が存在する。 手順およびモードは、アーキテクチャの異なる層に適用され、したがって、デバイスは、これらの手順およびモードのいくつかに同時に従事することができる。
Bluetoothデバイスは、近くのデバイスを検出するために、またはそれらの地域でのデバイスによって発見されるように照会プロシージャを使用します。
照会手順は非対称である。 近くの他のデバイスを見つけようとするBluetoothデバイスは、照会デバイスと呼ばれ、積極的に照会要求を送信します。 発見可能なBluetoothデバイスは、発見可能なデバイスとして知られており、これらの問い合わせ要求を待ち受け、応答を送信する。 照会手順は、照会要求および応答に対して特別な物理チャネルを使用する。
調査中および発見可能なデバイスは、すでにピコネット内の他のBluetoothデバイスに接続されている可能性があります。 照会スキャンまたは物理チャネルの照会または占有に費やされるたびに、既存の論理転送でのQoSコミットメントの要求とバランスを取る必要があります。
問合せ手順は、問合せおよび問合せ応答情報の交換中に一時的な物理的リンクが存在すると考えられるが、物理チャネルの上のいずれかのアーキテクチャ層を使用しない。
拡張照会応答は、照会応答手順中に雑多な情報を提供するために使用することができる。 データ型は、ローカル名やサポートされるサービスなどのために定義されます。そうでなければ、接続を確立することによって得られなければならない情報です。 拡張問い合わせ応答でローカル名とサポートされているサービスのリストを受け取るデバイスは、リモート名要求とSDPサービス検索を行うために接続する必要がないため、有益な情報に時間が短縮されます。 デバイスが、サポートされているすべてのサービスとそのローカル名の大部分を、その名前が長すぎて完全に送信できない場合、拡張された照会応答で含めることが推奨されます。
拡張照会応答手順は、標準照会応答手順と下位互換性があります。
接続を形成する手順は非対称であり、一方のブルートゥースデバイスがページ（接続）手順を実行し、他方のブルートゥースデバイスは接続可能（ページスキャン）である必要があります。 この手順は、ページ・プロシージャが特定の1つの特定のBluetooth装置によってのみ応答されるように、対象とされる。
接続可能デバイスは、ページング（接続）デバイスからの接続要求パケットをリッスンするために特殊な物理チャネルを使用します。 この物理チャネルには、接続可能なデバイスに固有の属性があります。したがって、接続可能なデバイスを認識しているページングデバイスだけがこのチャネルで通信できます。
ページングデバイスと接続可能デバイスは、すでに他のBluetoothデバイスに接続されている可能性があります。 ページングに費やされた時間またはページスキャン物理チャネルを占有する時間は、既存の論理トランスポート上のQoSコミットメントの要求とバランスをとる必要があります。
BR / EDRコントローラで正常に接続された後、 両方のデバイスが接続されるピコネット物理チャネルが存在し、 デバイス間に物理的なリンクがあり、 デフォルトのACL-C、ACL-U、ASB-C、およびASB-Uの論理リンクがあります。 これらのリンクの2つ（ACL-CおよびASB-C）は、LMP制御プロトコルを転送し、Link Managerの上にあるレイヤーからは見えません。 ACL-Uリンクは、L2CAPシグナリングプロトコルと任意の多重化L2CAPベストエフォートチャネルを転送します。 ASB-Uリンクは、ピコネット上のすべてのスレーブにブロードキャストされるL2CAPチャネルを転送します。 基本的なACL論理転送を参照するのは一般的ですが、これはコンテキストで解決できますが、通常はデフォルトのACL-U論理リンクを参照します。
接続モードでは、追加の論理リンクを作成および解放し、ピコネット物理チャネルに接続したまま物理および論理リンクのモードを変更することができます。 また、デバイスが、照会、ページングまたはスキャン手順を実行すること、または元のピコネット物理チャネルから切断することなく、他のピコネットに接続することも可能である。 これらのアクションは、Link ManagerプロトコルをリモートBluetoothデバイスと交換するLink Managerを使用して実行されます。
AMP物理リンクは、接続モードで確立することができます。 AMP物理リンクが作成されると、L2CAPユーザデータを転送するために、1つ以上のAMP-U論理リンクが確立される。
スレーブデバイスがピコネットにアクティブに接続されている間は、スレーブとマスタデバイス間のデフォルトのACL論理転送が常に存在します。 既定のACL論理トランスポートを削除する唯一の方法は、ピコネット物理チャネルからデバイスを切り離すことです。その時点で、デバイス間のL2CAPチャネル、論理リンク、および論理トランスポートの階層全体が削除されます。
ホールドモードは一般的なデバイスモードではありませんが、物理リンク上の予約されていないスロットに適用されます。 このモードでは、物理リンクは、同期リンクタイプSCOおよびeSCOの動作のために予約されているスロット中にのみアクティブです。 すべての非同期リンクは非アクティブです。 ホールドモードは呼び出しごとに1回動作し、完了すると終了して前のモードに戻ります。
スニッフィングモードは一般的なデバイスモードではありませんが、デフォルトのACL論理転送に適用されます。 このモードでは、これらの論理転送の可用性は、存在期間と不在期間からなるデューティサイクルを定義することによって変更されます。 スニッフィングモードでデフォルトのACL論理転送を持つデバイスは、不在期間を使用して、別の物理チャネル上でアクティビティに関与するか、省電力モードに入ることができます。 スニフモードは、デフォルトのACL論理トランスポート（すなわち、それらの共有ACL論理トランスポート）にのみ影響し、アクティブである追加のSCOまたはeSCO論理トランスポートには適用されない。 ピコネット物理チャネル上の物理リンクの有無の周期は、物理リンク上に構築されるすべての論理トランスポートの集合として導出される。
スニフサブレーティングは、アクティブデューティサイクルをさらに低減するメカニズムを提供し、スニフモードの省電力機能を向上させます。 Sniff subratingはホストが最大送信と受信の待ち時間を指定することによって保証されたアクセスのような接続を作成することを可能にします。 これにより、ベースバンドは、リンクマネージャコマンドを使用してスニフモードを終了して再入力せずに、低電力性能を最適化することができます。
ブロードキャスト論理トランスポートには、存在または不在の定義された期待はありません。 マスタデバイスは、ピコネット物理チャネル内の物理リンク存在期間と一致するようにブロードキャストをスケジュールすることを目指すべきであるが、これは常に可能でも実用的でもない。 ブロードキャストの繰り返しは、存在期間が重複しないで複数のスレーブに到達する可能性を向上させるために定義されています。 しかし、ブロードキャスト論理転送は信頼できるものとはみなされません。
役割切り替え手順は、ピコネットに接続された2つのデバイスの役割を入れ替える方法です。 この手順では、元のマスタデバイスによって定義された物理チャネルから、新しいマスタデバイスによって定義された物理チャネルに移動する必要があります。 ある物理チャネルから次の物理チャネルへとスワップするプロセスでは、BR / EDRコントローラ上の物理リンクおよび論理転送の階層が削除され、 トポロジによって暗示され、保存されていないASB論理転送を除き、再構築されます。 ロールスイッチ手順はAMP物理チャネルに影響しないことに注意してください。 ロール切り替えの後、元のマスタがチャネルに接続している他のスレーブを持っていた場合、元のピコネット物理チャネルは存在しなくなるか、または継続することがあります。
この手順では、デフォルトのACL論理リンクとサポートするレイヤーだけを新しい物理チャネルにコピーします。 追加の論理転送はこの手順ではコピーされません。必要に応じてこれを上位層で実行する必要があります。 影響を受けるトランスポートのLT_ADDRは、新しい物理チャネルで再割り当てされるため、変更される可能性があります。 元の論理トランスポート上にQoSコミットメントがある場合、これらは、役割切り替え後も保持されません。 ロールスイッチが完了した後、これらを再ネゴシエートする必要があります。
拡張データレートは、最大スループットを向上させ、複数の接続をより良くサポートし、消費電力を削減する目的で、Bluetoothパケットの容量とタイプを拡張する方法です。アーキテクチャの残りの部分は変更されません。 拡張データレートは、各論理トランスポートで独立して動作するモードとして選択することができる。 有効になると、パケットヘッダーのパケットタイプビットは、基本レートモードの意味とは異なる解釈をします。 この異なる解釈は、ヘッダ内の論理トランスポートアドレスフィールドと関連して明らかにされる。 この解釈の結果、パケットペイロードヘッダおよびペイロードは、パケットタイプに従って受信および復調されることが可能になる。 拡張データレートは、ACLおよびeSCO論理トランスポートに対してのみ有効にすることができ、SCOおよびブロードキャスト論理トランスポートに対して有効にすることはできません。
コネクションレススレーブブロードキャストモードは、ピコネットマスタが、BR / EDR適合ピコネット物理チャネルを使用して任意の数の接続されたスレーブデバイスにプロファイルブロードキャストデータを送信することを可能にする。 このモードに入るために、マスターは専用のCSB論理トランスポートとして特定の論理トランスポートを予約し、コネクションレススレーブブロードキャスト物理リンクと同期トレインプロシージャを使用してデータのブロードキャストを開始します。 プロファイルレスブロードキャストデータ論理リンクが定義され、これはコネクションレススレーブブロードキャスト論理トランスポートを使用してプロファイルブロードキャストデータを搬送する。 プロファイルブロードキャストデータは、フレームなしであり、L2CAPをバイパスします。
コネクションレススレーブブロードキャストパケットを受信するには、デバイスが、すでにCSB論理トランスポートを確立しているコネクションレススレーブブロードキャストトランスミッタに接続する必要があります。 接続するには、デバイスは同期スキャン手順に従って物理リンクのタイムスケジュールを取得し、次にコネクションレススレーブブロードキャストパケットの受信を開始します。 接続されると、コネクションレススレーブブロードキャストレシーバは、専用のCSB論理トランスポートおよびPBD論理リンクでプロファイルブロードキャストデータを受信できます。
デバイスフィルタリング手順は、コントローラが通信応答を必要とするデバイスの数を減らすための方法です。 すべてのデバイスからの要求に応答する必要がないため、LEコントローラが必要とする送信回数が削減され、消費電力が削減されます。 また、コントローラがホストとの間で行う必要のある通信も削減されます。 これは、ホストが関与する必要がないため、追加の電力節約をもたらす。
広告またはスキャンデバイスは、デバイスフィルタリングを使用して、広告パケット、スキャンリクエストまたは接続リクエストを受信するデバイスを制限することができる。 LEにおいて、走査装置によって受信されるいくつかの広告パケットは、走査装置が広告装置に要求を送信することを要求する。 この広告は、デバイスフィルタリングが使用され、広告デバイスがフィルタリングされている場合は無視することができます。 同様の状況が接続要求で発生します。 デバイスフィルタを使用して、広告主が応答する必要のあるデバイスを制限する場合を除き、接続要求は広告主によって応答されなければなりません。 広告主は、デバイスフィルタを使用して、スキャン要求または接続要求を受け入れるデバイスを制限することもできます。
このデバイスフィルタリングは、コントローラのLLブロックにある「ホワイトリスト」を使用して行われます。 ホワイトリストは、ローカルデバイスとの通信が許可されているリモートデバイスを列挙します。 ホワイトリストが有効な場合、ホワイトリストにないデバイスからの送信はLLによって無視されます。 デバイスのフィルタリングはLL内で行われるため、広告パケットをフィルタリング（または無視）することで電力消費に大きな影響を与えることができます。スキャン要求または接続要求は、処理のために上位層に送信されません。
特定の手順でのデバイスフィルタリングの使用は、デバイスが誤って無視されないように注意深く評価する必要があり、接続の確立や広告ブロードキャストの受信時に相互運用性の問題を引き起こす可能性があります。
広告主は広告手順を使用して、地域内のデバイスへの単方向ブロードキャストを実行する。 一方向放送は、広告装置とリスニング装置との間の接続なしに生じる。 広告手順は、近くにある開始装置との接続を確立するために使用することができ、または広告チャネルを受信する走査装置にユーザデータの定期的なブロードキャストを提供するために使用することができる。 広告手順は、すべての広告放送にプライマリ広告チャネルを使用する。 しかしながら、データは、1次広告チャネルの占有率と総オンエア時間とを減少させるために、1つ以上の補助パケットで2次広告チャネルにデータをオフロードすることができ、また1つのパケットに収まるデータの最大値をより長くすることができる。
LEピコネットに接続されたLEデバイスは、任意のタイプの広告イベントを使用して広告することができる。 既に確立された接続を維持するのに必要な接続要件とのバランスを取る必要がある（デバイスがピコネット内のスレーブであれば、それはマスタとの接続を維持する必要があり、デバイスがマスタである場合 ピコネット内の1つまたは複数のスレーブとの接続を維持する必要があります）。
広告デバイスは、広告デバイスから追加のユーザデータを取得するために、聴取デバイスからのスキャン要求を受信することができる。 スキャン応答は、広告デバイスによって、スキャン要求を行うデバイスに送信される。
広告装置は、イニシエータ装置から接続要求を受信することができる。 広告デバイスが接続可能な広告イベントを使用していて、開始デバイスがデバイスフィルタリング手順によってフィルタリングされていない場合、広告デバイスは広告を停止し、接続モードに入る。 デバイスは、接続モードに入ってから再度広告を開始できます。
LEコード化されていないPHYに広告を掲載する場合、スキャン要求とスキャン応答は元の広告と同じPHYチャネル上で発生するか、セカンダリ広告チャネルにオフロードできます。 LEコード化されていないPHYに広告を掲載する場合、接続要求と接続応答はセカンダリ広告チャネルにオフロードされます。 LE符号化PHYに広告を掲載する場合、スキャン要求、スキャン応答、接続要求、および接続応答は常にオフロードされます。 広告データと同様に、オフロードは、第1の広告チャネル上の最初の広告が第2の広告チャネル上の補助パケットを指すようにすることによって行われる。 スキャン要求とスキャン応答、接続要求、および接続応答は、補助パケットと同じPHYおよび同じチャネル上で行われます。
走査装置は、走査手順を使用して、広告チャネルを使用する広告装置からのユーザデータの一方向の放送を聞く。 走査装置は、走査要求を行うことによって、広告装置から追加のユーザーデータを要求することができる。 広告装置は、これらの要求に応答して、広告チャネルを介して走査装置に送信される追加のユーザーデータを送信する。
スキャン手順は、LEピコネットの他のLEデバイスに接続して使用することができます。 接続中にスキャンに費やされる時間は、ピコネット内の他のLEデバイスとの既存の接続を維持するために必要な接続要件とのバランスを取る必要があります。
ブロードキャストが接続可能な広告イベントであり、スキャンデバイスがイニシエータモードにある場合、スキャンデバイスは、プライマリ広告チャネルまたはセカンダリ広告チャネル上の接続要求を広告デバイスに送信することによって接続を開始することができる。 プライマリチャネルで接続要求が送信されると、スキャンデバイスはイニシエータモードのスキャンを停止して追加のブロードキャストを検出し、接続モードに入ります。 セカンダリチャネルで接続要求が送信されると、スキャンデバイスはイニシエータモードから抜け出し、追加のブロードキャストのスキャンを中止し、接続応答を受信すると接続モードに入ります。 デバイスは、接続モードに入った後にスキャン手順を使用できます。 マスタデバイスの場合、イニシエータモードを使用し、接続可能なアドバタイズメントをスキャンする方法は、マスタのLEピコネットに追加デバイスを追加する方法です。
ブルートゥースデバイスは、広告手順およびスキャン手順を使用して、近くのデバイスを発見するか、または所定のエリア内のデバイスによって発見される。 発見手順は非対称である。 近くの他のデバイスを見つけようとするBluetoothデバイスは、発見デバイスとして知られ、スキャン可能な広告イベントを広告するデバイスを待ち受けます。 発見可能なブルートゥースデバイスは、発見可能なデバイスとして知られており、広告ブロードキャスト物理チャネル上でスキャン可能な広告イベントを積極的にブロードキャストする。
発見可能 discovering なデバイスと発見可能 discoverable なデバイスは、すでにピコネット内の他のBluetoothデバイスに接続されている可能性があります。 広告ブロードキャスト物理チャネルを調べたり占有したりするのに費やされる時間は、ピコネット内の他のLEデバイスとの既存の接続を維持するのに必要な接続要件とのバランスを取る必要があります。
走査装置による装置フィルタリングを用いることにより、走査装置が所与の領域内の全ての装置を発見するのを防止する。
接続を形成する手順は非対称であり、一方のブルートゥースデバイスが広告手順を実行し、他方のブルートゥースデバイスがスキャン手順を実行することが必要である。広告手順は、1つのデバイスだけが広告に応答するように、ターゲットにすることができる。 走査装置は、広告装置が接続可能な方法で存在することを最初に発見することによって広告装置を目標にすることもでき、 デバイスフィルタを使用して、そのデバイスから接続可能な広告イベントのみをスキャンします。 ターゲット広告装置から接続可能な広告イベントを受信した後、ターゲット広告装置への接続要求をプライマリー広告チャネルまたはセカンダリ広告チャネルを介して送信することによって接続を開始することができる。
接続中にスキャンに費やされる時間は、ピコネット内の他のLEデバイスとの既存の接続を維持するために必要な接続要件とのバランスを取る必要があります。
接続手順が成功すると、デバイスはピコネット内で物理的に相互に接続されます。これは、両方が接続されているピコネット物理チャネルが存在し、デバイス間に物理的なリンクがあり、デフォルトのLE-CおよびLE-U論理リンクが存在することを意味します。接続モードでは、適応周波数ホッピングシーケンスの変更やデータパケットの長さの変更など、ピコネット物理チャネルに接続したまま物理リンクおよび論理リンクのプロパティを変更することができます。また、元のピコネット物理チャネルから切り離すことなく、デバイスが広告、スキャン、または発見手順を実行することも可能である。
追加の論理リンクは、これらのリンクの作成と設定をネゴシエートするために、LLプロトコルメッセージをリモートBluetoothデバイスと交換するLink Managerを使用して作成されます。これらのリンクの1つ（LE-C）は、LL制御プロトコルを転送し、Link Managerの上にあるレイヤーには見えません。他のリンク（LE-U）は、L2CAPシグナリングプロトコルおよび任意の多重化L2CAPベストエフォートチャネルを伝送する。一般的には、LE ACLの論理トランスポートを参照するのが一般的です。これはコンテキストによって解決できますが、通常はデフォルトのLE-U論理リンクを参照します。また、これら2つの論理リンクが論理転送を共有することにも注意してください。
スレーブデバイスがピコネットにアクティブに接続されている間は、スレーブとマスタデバイス間のデフォルトLE ACL論理転送が常に存在します。 デフォルトのLE ACL論理トランスポートを削除する方法は、ピコネット物理チャネルからデバイスを切り離すことです。この時点で、デバイス間のL2CAPチャネル、論理リンク、論理トランスポートの階層全体が削除されます。
広告主は、定期的な広告手順を使用して、エリア内のデバイスに対して一方向の定期的なブロードキャストを実行する。 一方向放送は、広告装置とリスニング装置との間の接続なしに生じる。 定期的な広告手順は、近隣の装置と同期するために使用され、広告チャネルを受信している走査装置にユーザデータの確定的な定期的なブロードキャストを提供する。 広告手順は、プライマリおよびセカンダリ広告チャネルを使用して、定期的な広告に関する制御およびユーザ情報をブロードキャストする。
周期的な物理チャネル上の他のLEデバイスと同期化されたLEデバイスは、定期的な広告イベントを使用する。 他のLEデバイスと接続または同期している間、定期的な広告に費やされる時間は、既に確立された接続または同期を維持するのに必要な接続および同期要件とバランスをとる必要があります。
定期的な広告に同期させる手順は非対称であり、一方のブルートゥースデバイスが広告手順を実行し、他方のブルートゥースデバイスがスキャン手順を実行することが必要である。 走査装置は、広告装置が存在することを最初に発見し、所定の領域に定期的な広告を放送することによって、広告装置を目標とすることができる。 ターゲットとされた広告デバイスから同期情報を含む広告イベントを受信した後、それは定期的な広告イベントに同期することができる。 同期デバイスは、既に広告、スキャン、またはピコネット内の他のBluetoothデバイスに接続されているか、または他の定期広告に同期されている可能性があります。 定期的な広告との同期に費やされる時間は、すでに確立された接続や同期を維持するために必要な要件とバランスを取る必要があります。
同期手順が成功すると、デバイスは物理的に互いに同期されます。 これは、両方が同期され、デバイス間に定期的な物理リンクがあり、ADVB-UおよびADVB-C論理リンクがある定期的な物理チャネルがあることを意味します。 デバイスが、LE周期的物理チャネルから切り離す必要なく、広告、スキャン、または発見手順を実行することも可能である。
AMPマネージャは、ローカルAMPコントローラを検出し、AMPがシステムから動的に追加または削除されるため、そのリストを長期にわたって維持する責任があります。 ローカルAMPマネージャは、リモートAMPマネージャからAMPのリストを要求することができる。 リモートデバイスからAMPのリストが要求された後、AMPがシステムに追加または削除されると、ローカルAMPマネージャはそのリモートAMPマネージャにその変更を通知します。
各AMPはIDとタイプで識別されます。 AMPのリストが受信されると、AMPマネージャは各AMPの情報（AMP_Info）を要求することができる。
リモートデバイスでAMP物理リンク（AMPチャネル）を介してL2CAPチャネルを設定するには、 AMPマネージャは最初にリモートAMPを検出し、リモートAMPに関する必要な情報を収集して、最適な方法で物理リンクをセットアップしてから、物理リンクの作成を開始します。 これは、専用のL2CAPチャネルを介して行われます。
AMPマネージャは、リモートAMPについて収集したリモートAMP情報をローカルAMP PALに提供します。 ローカルAMP PALは、この情報を使用してAMP物理リンクを作成します。
物理リンクが存在すると、L2CAPは目的のQoSでAMP論理リンクを作成します。 論理リンク上にL2CAPチャネルが作成され、その時点でチャネルはデータ通信の準備ができています。
Bluetoothセキュリティモデルには、ペアリング、ボンディング、デバイス認証、暗号化、メッセージの整合性という5つの異なるセキュリティ機能が含まれています。
- ペアリング：1つまたは複数の共有秘密鍵を作成するプロセス
- ボンディング：ペアリング中に作成されたキーを保存して以後の接続で使用することで、信頼できるデバイスのペアを形成する
- デバイス認証：2つのデバイスが同じキーを持っていることの確認
- 暗号化：メッセージ機密性
- メッセージの完全性：メッセージの偽造からの保護
Bluetoothコアのセキュリティアーキテクチャは、時間の経過とともに進化しています。 当初、ペアリングはSAFER +に基づくE21またはE22アルゴリズムを利用していました。 このペアリングのバージョンは、「BR / EDRレガシーペアリング」と呼ばれます。 デバイス認証は当初はSAFER +に基づいたE1アルゴリズムに基づいていました。 暗号化は、Massey-Rueppelアルゴリズムから導出されたE0アルゴリズムを利用する。 暗号メッセージの完全性のための規定もなかった。 CRCはいくつかの完全性保護を提供するが、容易に偽造することができるので、暗号の完全性を提供するとはみなされないことに留意されたい。
コア仕様のバージョン2.1 + EDRでは、FIPS承認アルゴリズム（SHA-256、HMAC-SHA-256およびP-192楕円曲線）を使用するSecure Simple Pairingを導入し、また Just Works、Numeric Comparison、Passkey Entry、Out-Of-Bandの4つの関連モデルを導入しました（セクション5.2を参照）。 Secure Simple Pairingが導入されたとき、デバイスの認証と暗号化は同じままでした。
コア仕様のバージョン3.0 + HSでは、AMPのサポートが追加されました（5.5節を参照）。
バージョン4.0では、低エネルギー（セクション5.4参照）のセキュリティモデル全体が追加されましたが、BR / EDRまたはAMPのセキュリティ機能は変更されませんでした。
バージョン4.1では、セキュア接続機能がBR / EDRフィジカルトランスポートに追加されました。この機能は、P-256楕円曲線、FIPS承認アルゴリズム（HMAC-SHA-256およびAES-CTR）を使用するデバイス認証を使用するようにSecure Simple Pairingをアップグレードしました。 セキュア接続には、メッセージの整合性（AES-CCM）も追加されました。
バージョン4.2では、LE物理的トランスポートにセキュア接続機能が追加されました。これにより、LEペアリングをFIPS承認アルゴリズム（AES-CMACおよびP-256楕円曲線）にアップグレードし、 Bluetooth LE物理転送で使用される数値比較関連モデルを適合させます。 いずれかの物理トランスポートでセキュア接続を使用して生成されたキーのための規定も含まれているため、ユーザーはもう一方の物理トランスポートでもう一度ペアリングする必要がありません。 Bluetoothコア仕様4.0および4.1で定義されているLEペアリングは、LEレガシーペアリングと呼ばれます。
BR / EDRとAMPのセキュリティキー階層をFigure 5.1に示します。 キー階層は、物理リンクがセキュア接続を使用しているか、従来のセキュリティ手順とアルゴリズムを使用しているかによって異なります。
Figure 5.1: BR/EDR and AMP Key Hierarchy
LEのセキュリティキー階層をFigure 5.2に示します。 鍵階層は、物理リンクがLEセキュア接続またはLEレガシーペアリング手順およびアルゴリズムを使用しているかどうかによって異なります。
Figure 5.2: LE Key Hierarchy
Secure Simple Pairingの主な目的は、ユーザーのペアリング手順を簡素化することです。 副次的な目標は、Bluetoothワイヤレステクノロジのセキュリティを維持または向上させることです。 多くのテクノロジや製品では、高いレベルのセキュリティと使いやすさがスペクトルの反対側にあることが多いため、エンドユーザーの視点から複雑さを最小限に抑えながらセキュリティを最大限に高めるように注意が払われています。
セキュアシンプルペアリングには、パッシブ盗聴からの保護とMITM（Man-in-the-Middle）攻撃（アクティブ盗聴）からの保護の2つのセキュリティ目標があります。 Bluetoothコア仕様バージョン2.0 + EDRおよびそれ以前のバージョンで使用されているペアリングアルゴリズムを使用して16文字の英数字PINを使用することによって提供される最大セキュリティレベルを超えることが、Secure Simple Pairingの目標です。 Bluetoothコア仕様2.0 + EDRおよびそれ以前のバージョンに準拠している多くのBluetoothデバイスでは、4桁のPINまたはリンクのセキュリティを大幅に制限する一般的に既知の値の固定PINを使用しています。
強力な暗号化アルゴリズムと結合された強力なリンクキーは、ユーザーが受動的な盗聴から保護するために必要です。リンクキーの強さは、攻撃者が知らない生成プロセスのエントロピー（またはランダム性）の量に基づいています。レガシー・ペアリングを使用すると、エントロピーの唯一のソースは、多くの場合、ユーザーによって選択されるか、または所定の製品に対して固定される典型的な4桁のPINである。したがって、ペアリング手順と1つの認証交換が記録されていれば、一般的に利用可能なコンピューティングハードウェア上で非常に短い時間内にPINを見つけるために徹底的な検索を実行できます。 セキュアなシンプルペアリングでは、記録された情報からリンクキーを導出するために、公開鍵暗号の難しい問題を攻撃者が解決しなければならないため、記録攻撃はさらに困難になります。 この保護は、パスキーの長さまたはユーザーが処理する必要のある他の数値には依存しません。 セキュアシンプルペアリングは、ユーザーが何もする必要がない場合でも、記録および受動的な盗聴攻撃に対して同じ抵抗を与えます。
セキュアシンプルペアリングでは、盗聴攻撃を阻止する手段としてECDH（Elliptic Curve Diffie Hellman）公開鍵暗号を使用します。 ECDHは受動的な盗聴攻撃に対して非常に高いレベルの強度を提供しますが、受動的な盗聴攻撃（セクション5.2.3を参照）よりも実際に実行するのがはるかに難しいMITM攻撃を受ける可能性があります。
Bluetoothコア仕様バージョン2.0 + EDR以前のセキュリティプロトコルを16桁数字PINで使用すると、約53ビットのエントロピーが達成されます 一方、16文字の大文字と小文字を区別するPINは、62文字セット全体（[0、... 9、 'A'、... 'Z'、 'a'、...'z']）を使用すると約95ビットのエントロピーを生成します。 セキュアな接続機能をサポートしていないデバイス（コア仕様v4.1で導入されました）では、 セキュアシンプルペアリングには、FIPS認定のP-192楕円曲線を使用して約96ビットのエントロピーがあり、少なくとも16ビットの英数字で大文字と小文字を区別するPINを使用して、Bluetoothコア仕様2.0 + EDRのエントロピーと少なくとも同等です。 セキュア接続機能をサポートするデバイスの場合、Secure Simple Pairingには、FIPS認定のP-256楕円曲線を使用して約128ビットのエントロピーがあります。 ECDH暗号は、Diffie Hellman（一般的にDH76と呼ばれる）よりも選択されました。これは、一般的なBluetoothコントローラの計算量が少なく、計算能力が低い可能性が低いためです。
MITM（Man-in-the-Middle）攻撃は、ユーザーが2つのデバイスを接続する場合に発生しますが、 お互いに直接接続するのではなく、ペアにしようとしているデバイスの役割を果たす第3の（攻撃している）デバイスに無意識に接続します。次に、第3の装置は、2つの装置間で情報を中継し、それらが直接接続されているという錯覚を与える。攻撃装置は、2つの装置間の通信を盗聴することさえできます（アクティブな盗聴と呼ばれます）、接続に関する情報の挿入と変更が可能です。この種の攻撃では、2つのデバイス間で交換されるすべての情報が侵害され、攻撃者が各デバイスにコマンドと情報を注入して、デバイスの機能を損なう可能性があります。 攻撃の被害を受けたデバイスは、攻撃者が存在する場合にのみ通信することができます。 攻撃者がアクティブでないか範囲外の場合、2つの犠牲デバイスは互いに直接通信することができず、ユーザーはそれに気付くでしょう。
MITM攻撃を防ぐために、Secure Simple Pairingでは、数値比較またはパスキー入力の2つのユーザー補助数値メソッドを提供しています。 セキュアシンプルペアリングで16桁の10進数を使用する場合、使いやすさは16桁の16進数のPINでレガシーペアリングを使用する場合と同じになります。 この場合、MITMが自身のリンクキーを挿入する機会は、1016 = 253のペアリングインスタンスの1であり、不必要に低い可能性があります。
セキュア・シンプル・ペアリングは、MITMが成功した攻撃をマウントできる確率で1万分の1を提供するという目標で、MITM攻撃からユーザーを保護します。 MITM保護の強みは、数値比較とパスキー入力に6桁の数字を使用することで、ユーザーの影響を最小限に抑えるように選択されました。 このレベルのMITM保護は、ほとんどの場合、失敗したMITM攻撃の結果として接続プロセスが失敗した場合に、潜在的なMITM攻撃者の存在をユーザーに警告することができるため、選択されました。 ほとんどのユーザーは、パスキーを改ざんしていなければ、 認証には4桁のキー（銀行カードのPINコード）で十分ですが、6桁の数字を使用するとSecure Simple PairingはFIPSに準拠します。これはユーザビリティの影響をほとんど感じることができませんでした。
セキュアシンプルペアリングでは、数値比較、ジャストワーク、アウトオブバンド、パスキーエントリと呼ばれる4つの関連モデルが使用されます。 これらの関連モデルのそれぞれについては、以下のセクションで詳しく説明します。 使用される関連モデルは、2つのデバイスのI / O機能に基づいて決定的です。
数値比較関連モデルは、両方のデバイスが6桁の数字を表示することができ、両方ともユーザーが「はい」または「いいえ」と入力できるシナリオ用に設計されています。 このモデルの良い例は、携帯電話/ PCのシナリオです。
ユーザーは両方のディスプレイに6桁の数字（「000000」から「999999」まで）を表示し、両方のデバイスで数字が同じかどうかを尋ねられます。 両方のデバイスに「はい」と入力すると、ペアリングは成功します。
数値の比較には2つの目的があります。 第1に、多くのデバイスは固有の名前を持たないので、正しいデバイスが互いに接続されていることをユーザに確認する。 第2に、数値比較はMITM攻撃に対する保護を提供します（5.2.3項を参照）。
数値比較とBluetoothコア仕様およびそれ以前のバージョンで使用されているPINエントリモデルとの間には、暗号の観点から大きな違いがあることに注意してください。 数値比較連想モデルでは、6桁の数値は、Bluetoothセキュリティモデルの場合のように、セキュリティアルゴリズムの成果物であり、入力への入力ではありません。 表示された数を知ることは、2つの装置間で交換される符号化データを解読する際には有益ではない。
ジャストワークス協会モデルは、少なくとも1つの装置が6桁の数字を表示することができないディスプレイも、6桁の数字を入力できるキーボードをもたないシナリオ用に主に設計されている。 このモデルの良い例は、ほとんどのヘッドセットにディスプレイがない携帯電話/モノラルヘッドセットのシナリオです。
Just Works協会モデルでは数値比較プロトコルが使用されますが、ユーザーに数字が表示されることはなく、アプリケーションはユーザーに接続を受け入れるよう求めることがあります（正確な実装は最終製品の製造元に委ねられています）。
Just Works協会モデルは、Numeric Comparisonアソシエーションモデルと同じ保護を受動盗聴に対して提供しますが、MITM攻撃に対する保護は提供しません。
固定PINのヘッドセットの今日の経験と比較すると、受動盗聴に対する高度の保護が実現されているため、ジャストワークス協会モデルのセキュリティレベルはかなり高くなっています。
アウトオブバンド（OOB）アソシエーションモデルは、帯域外メカニズムを使用してデバイスを検出するだけでなく、ペアリングプロセスで使用される暗号番号を交換または転送するシナリオ用に主に設計されています。 セキュリティの観点から有効であるために、帯域外チャネルは、Bluetooth無線チャネルと比較してセキュリティの点で異なる特性を提供する必要があります。 帯域外チャネルは、MITM攻撃に耐性がある必要があります。 そうでない場合、認証中にセキュリティが侵害される可能性があります。
ユーザーのエクスペリエンスは帯域外メカニズムによって少し異なります。 一例として、近接フィールド通信（NFC）ソリューションでは、ユーザは最初に2つのデバイスを一緒に接触させ、第1のデバイスを他のデバイスとペアリングするオプションが与えられる。 「はい」と入力すると、ペアリングは成功です。 これは、交換された情報が両方のデバイスで使用されるシングルタッチ体験です。 交換される情報には、暗号情報だけでなく、発見情報（Bluetoothデバイスアドレスなど）も含まれます。 デバイスの1つはBluetoothデバイスアドレスを使用して他のデバイスとの接続を確立します。 残りの交換された情報は、認証時に使用されます。
OOBメカニズムは、読み取り専用または読み取り/書き込みのいずれかとして実装できます。 一方の側が読み取り専用の場合、一方向の認証が実行されます。 両側が読み取り/書き込みの場合、双方向認証が実行されます。
OOBプロトコルは、以前のOOBの情報交換によってペアリングプロセスがアクティブ化され、その1つ（または両方）のデバイスがIO機能としてOOBを指定した場合にのみ選択されます。 プロトコルは、交換された情報を使用し、単に接続を確認するようユーザーに求める。
OOBアソシエーションモデルは、暗号情報とBluetoothデバイスアドレスを交換できる任意のOOBメカニズムをサポートします。 OOBアソシエーションモデルは、ユーザーがBluetooth接続をアクティブにしたソリューションをサポートしておらず、認証にOOBを使用したいだけです。
Passkey Entryアソシエーションモデルは、1つのデバイスに入力機能があり、6桁の数字を表示する能力を持たず、もう1つのデバイスに出力機能があるシナリオ用に設計されています。 このモデルの良い例は、PCとキーボードのシナリオです。
ユーザは、ディスプレイ上に6桁の数字（「000000」から「999999」まで）を表示し、次に他のデバイスに番号を入力するように求められます。 2番目のデバイスに入力された値が正しい場合、ペアリングは成功です。 Passkey Entryと、Bluetooth Core Specification 2.0 + EDRおよびそれ以前のバージョンで使用されているPINエントリモデルとの間には、暗号の観点から大きな違いがあることに注意してください。 Passkey Entryアソシエーションモデルでは、2.0 + EDRセキュリティモデルの場合のように、6桁の数字はセキュリティアルゴリズムとは独立しており、入力には関係しません。 入力された番号を知ることは、2つの装置間で交換される符号化されたデータを解読する際には有益ではない。
次の図は、検出に使用されるテクノロジの観点からのSecure Simple Pairingと、異なる関連付けの可能性を示しています。
Figure 5.3: Secure Simple Pairing Association Models
デバイスでBR / EDR物理転送でFIPS承認アルゴリズムのみが使用されることが必要なデバイスは、BR / EDR物理転送でセキュア接続のみモードに入る必要があります。 セキュアな接続のみモードは「FIPSモード」と呼ばれることがあります。 このモードは、セキュリティで保護された接続をサポートしていないデバイスとの下位互換性を維持するよりも、セキュリティが高いデバイスが重要である場合に使用する必要があります。 ホストは、ペアリング中にP-256楕円曲線が使用され、安全な認証シーケンスが使用され、AES-CCMが暗号化に使用されることを強制する。
デバイスでLE物理転送でFIPS承認アルゴリズムのみを使用する必要がある場合は、LE物理転送でセキュア接続のみモードに入る必要があります。 セキュアな接続のみモードは「FIPSモード」と呼ばれることがあります。 このモードは、LEセキュア接続をサポートしていないデバイスとの下位互換性を維持するよりも、デバイスが高いセキュリティを持つことが重要である場合に使用する必要があります。 このモードでは、ホストはペアリング中にP-256楕円曲線が使用されるように強制します。
BR / EDR / LEデバイスがセキュア接続のみモードで設定されている場合、BR / EDRとLEトランスポートは両方ともセキュア接続専用モードになります。
Bluetoothコア仕様v4.0（LEレガシーペアリング）で導入されたペアリングメカニズムは、セキュアなシンプルペアリングなどのBR / EDRセキュリティ機能に関するセキュリティ面でいくつかの違いがあります。 アソシエーション・モデルは、ユーザーの観点からBR / EDRセキュア・シンプル・ペアリングに似ていて、同じ名前を持っていますが、提供される保護の質に違いがあります。
Bluetooth LEは、Just Works、Numeric Comparison、Out of Band、Passkey Entryという4つの関連モデルを使用しています。 LEのレガシーペアリングには数値比較がありません。
LEレガシーペアリングでは、これらの関連モデルのそれぞれは、以下の点を除いてBR / EDRセキュアシンプルペアリングに似ています。
- Just WorksとPasskey Entryは、パッシブな盗聴保護を提供しません。 これは、Secure Simple PairingがElliptic Curve Diffie-Hellmanを使用し、LEのレガシーペアリングが使用しないためです。
LEセキュアコネクションのペアリングでは、4つのアソシエーションモデルは機能的にBR / EDRセキュアコネクションと同等です。
各関連モデルの使用は、デバイスのI / O機能に基づいています。
Bluetooth LEの鍵生成は、他のLEデバイスとは独立した各LEデバイスのホストによって実行されます。 ホストで鍵生成を実行することにより、鍵生成アルゴリズムをコントローラを変更することなくアップグレードすることができます。 注：BR / EDRのキー生成は、コントローラで実行されます。
Bluetooth LEは、それぞれ特定の目的のために、以下のように複数のキーを使用します。:
- データとデバイス認証の機密性
- 暗号化されていないデータの認証
- デバイスアイデンティティ
LEでは、秘密性と認証を提供するために使用される鍵は、ペアリング中に各デバイスからの貢献を組み合わせることによって生成されます。
Bluetooth LEの暗号化は、AES-CCM暗号を使用します。 BR / EDRと同様に、LE暗号化はコントローラで実行されます。
Bluetooth LEは、信頼関係を持つ2つのデバイス間で暗号化されていないATTベアラを介して認証データを送信する機能をサポートしています。 これは、CSRK（Connection Signature Resolving Key）でデータに署名することによって達成されます。 送信側デバイスは、データPDUの後ろに署名を置きます。 受信デバイスは署名を検証し、署名が検証されている場合、データPDUは信頼できるソースから来たものとみなされます。 署名は、署名アルゴリズムによって生成されたメッセージ認証コードとカウンタで構成されます。 このカウンタは、再生攻撃から保護するために使用され、送信された署名付データPDUごとに増分されます。
Bluetooth LEは、頻繁にBluetoothデバイスアドレスを変更することにより、LEデバイスを一定期間追跡する機能を削減する機能をサポートしています。
プライバシー機能を使用するデバイスが既知のデバイスに再接続するためには、プライベートアドレスと呼ばれるデバイスアドレスを他のデバイスで解決できる必要があります。 プライベートアドレスは、ボンディング手順中に交換されるデバイスの解決IDキー（IRK）を使用して生成されます。
プライバシー機能には2つのバリエーションがあります。 第1の変形例では、プライベートアドレスが解決され、ホストによって生成される。 第2の変形例では、ホストがコントローラデバイス識別情報を提供した後にホストを関与させることなく、プライベートアドレスが解決され、コントローラによって生成される。 さらに、コントローラの解決リストがボンディングされたデバイスに必要なすべてのデバイスID解決鍵を格納できない場合、第2の変形例はホストを含むことができる。
プライバシーのモードには、デバイスプライバシーモードとネットワークプライバシーモードの2つがあります。 デバイスプライバシーモードのデバイスは、デバイスのプライバシーのみに関心があり、ピアデバイスがそのIRKを過去に配信したとしても、自分の識別アドレスを含むピアデバイスからの広告パケット、およびプライベートアドレスを含む広告パケットを受け入れます 。 ネットワークプライバシーモードでは、デバイスはプライベートアドレスを含むピアデバイスからの広告パケットのみを受け入れます。 既定では、プライベートアドレスが解決されてコントローラによって生成されるとき、ネットワークプライバシモードが使用されます。
ホストは、デバイスアイデンティティを追加および削除することによって解決リストを維持する。 ホストは、完全な解決リストまたは解決リストのサブセットをコントローラに提供することができる。 デバイスIDは、ピアのIDアドレスとローカルおよびピアのIRKペアで構成されます。
コントローラがアドレス解決を実行し、ホストが解決リストに含まれるピアデバイスを参照する必要がある場合、ホストはピアのデバイスIDアドレスを使用します。 同様に、コントローラーからホストへのすべての着信イベントは、ピアの装置アドレスが解決されていれば、ピアの装置識別情報を使用します。 コントローラが広告内のピアのデバイス識別アドレスを解決できない場合、コントローラはホストで解決のためにイベントをホストに渡すことがあります。
コントローラーでアドレス解決が実行されると、ホワイトリストに含まれているかどうかをチェックする前にピアのデバイスIDアドレスを解決できるため、デバイスのフィルタリングが可能になります。
Figure 5.4に、コントローラ解決リストとコントローラホワイトリストの関係を論理的に示します。 解決リストとホワイトリストの実際の実装は、このモデルに従う必要はありません。 解決リストはホワイトリストから独立していてもよい。
Figure 5.4: Logical Representation of the Resolving List and Device White List
注：ホワイトリストのすべてのデバイスがデバイスIDアドレスであるとは限りません。
ホストでアドレス解決が排他的に実行されると、デバイスフィルタリングを無効にする必要があるため、デバイスの消費電力が増加する可能性があります。
AMPセキュリティは、Bluetooth 2.1 + EDRコア仕様で導入されたものと同じSecure Simple Pairing関連モデルを使用しているため、ユーザーエクスペリエンスを変更しません。 ユーザーの観点からは、すべての無線が1つのプロセスで「ペアリング」されています。
AMPセキュリティは、セキュア・シンプル・ペアリング・プロセス中に開始されます。 BR / EDRのリンクキーは、Secure Simple Pairingのフェーズ4で生成されます。 BR / EDRリンクキーから256ビットの汎用AMPリンクキー（GAMP_LK）が生成されます。 一般的なAMPリンクキーは、ペアリングが完了するとBR / EDRリンクキーとともにセキュリティデータベースに保存されます。
AMPセキュリティはBR / EDRリンクキーには影響しません。そのため、一般的なAMP機能をサポートしないデバイスでは、後方互換性が維持されます。
最初にAMPを使用する場合は、新しいAMPタイプのセキュア・シンプル・ペアリング関数h2とAMPタイプのKeyIDを使用して、そのAMPタイプのAMPマネージャーによって専用のAMPキーが作成されます。 Dedicated AMP Link Keyの長さは、AMP Typeに依存します。 以前の接続のためにPair-Wise Masterキーがすでに存在する場合、AMPリンクキーは作成されず、保存されたキーが再利用されます。
Dynicated AMP Link Keyは、物理リンクの作成プロセス中にPALに送信されます。 各PALは、物理リンク確立プロセスのセキュリティフェーズでDedicated AMP Link Keyの使用を担当します。 専用のAMPリンクキーは、同じAMPで複数のセッションに使用されることに注意してください。
専用のAMPキーが正常に作成されるたびに、汎用AMPリンクキーが更新されます。 これは、KeyID 'gamp'を持つh2関数を使用して実行されます。
2台のBR / EDR / LEデバイスが両方のトランスポートでセキュア接続をサポートする場合、両方のトランスポートのキーが1回のペアリング手順で生成されることがあります。 1つのトランスポートから別のトランスポートにキーを変換できるため、2回ペアリングする必要がなくなり、より優れたユーザーエクスペリエンスが実現します。
BR / EDR物理トランスポート上のセキュアシンプルペアリングのフェーズ4で生成されたBR / EDRのリンクキーは、LEトランスポートで使用するための長期キー（LTK）に変換することができます。 同様に、LE物理転送上のペアリングフェーズ2の間に生成されたLTKは、BR / EDR物理転送で使用するためにBR / EDRリンク鍵に変換することができる。
Bluetoothシステムにおけるアプリケーションの相互運用性は、Bluetoothプロファイルによって達成されます。 Bluetoothプロファイルは、Bluetoothシステムの各層の必要な機能および機能を、PHYからL2CAPおよびコア仕様外の他のプロトコルに定義する。 プロファイルは、デバイス間の特定のレイヤーのピアツーピア相互作用だけでなく、レイヤー間の垂直方向の相互作用を定義します。
Figure 6.1: Bluetooth Profiles
さらに、アプリケーションの動作とデータフォーマットもプロファイルによって定義されます。 2つのデバイスがBluetoothプロファイルのすべての要件を満たす場合、アプリケーションの相互運用性が有効になります。
すべてのプロファイルは、デバイスが接続し、利用可能なアプリケーションサービスと、アプリケーションレベルの接続を確立するために必要な接続情報を見つけるために必要なサービス検出要件を記述します。
Bluetoothシステムは、すべてのBluetoothデバイスが実装するベースプロファイルを定義します。 このプロファイルは、Bluetoothデバイスの基本要件を定義する汎用アクセスプロファイル（GAP）です。 たとえば、BR / EDRの場合、無線、ベースバンド、リンクマネージャ、L2CAP、およびサービスディスカバリプロトコル機能を含むようにBluetoothデバイスを定義します。 LEの場合、物理レイヤ、リンクレイヤ、L2CAP、セキュリティマネージャ、属性プロトコル、および汎用属性プロファイルを定義します。 これにより、さまざまなレイヤーがすべて結びついて、Bluetoothデバイスの基本要件が形成されます。 また、デバイスの検出、接続の確立、セキュリティ、認証、アソシエーションモデル、およびサービス検出の動作と方法についても説明します。
BR / EDRでは、GAPは各デバイスに存在する可能性のある機能を持つ単一の役割を定義します。 この機能には、デバイスが互いを検出し、接続を確立し、認証に使用されるセキュリティ関連モデルがどのように記述されるかが含まれます。 BR / EDRでは、この機能が両方のデバイスに存在する可能性があります。 デバイスがすべてのデバイスとの接続を検出または確立する場合は、デバイスが開始機能と受け入れ機能の両方を実装する必要があります。 デバイスには、開始機能または受け入れ機能のいずれかのみが含まれていてもよいが、遠隔デバイスに発見のための補完機能をサポートしたり、デバイスとの接続を確立する必要がある。 BR / EDRの場合、コントローラはすべての機能をサポートする必要がありますが、ホストはデバイスがサポートする他のプロファイルまたはユースケースに基づいてこの機能を制限することがあります。
LEでは、GAPは4つの特定の役割を定義しています：ブロードキャスタ、オブザーバ、ペリフェラル、およびセントラル。 デバイスは、基盤コントローラがそれらの役割または役割の組み合わせをサポートするならば、複数のLE GAPの役割をサポートすることができる。 各ロールは、基本となるコントローラの要件を指定します。 これにより、特定のユースケースに対してコントローラを最適化することができます。
Broadcasterの役割は、トランスミッタ専用のアプリケーションに最適化されています。 放送局の役割をサポートするデバイスは、放送データに広告を使用します。 ブロードキャスターの役割は接続をサポートしていません。 Observerの役割は、受信者専用アプリケーションに最適化されています。 オブザーバー役割をサポートする装置は、放送業者の補完的装置であり、広告に含まれる放送データを受信する。 オブザーバーの役割は接続をサポートしていません。 Peripheralロールは、単一の接続をサポートし、中央デバイスより複雑ではないデバイスに最適化されています。 ペリフェラルロールをサポートするデバイスは、コントローラのスレーブロールをサポートするコントローラのみを必要とします。 中央の役割は複数の接続をサポートし、周辺機能のデバイスとのすべての接続のイニシエータです。 中心的な役割を果たすデバイスは、コントローラのマスタ役割をサポートするコントローラを必要とし、一般に他のLE GAPの役割と比べてより複雑な機能をサポートします。
すべてのBluetoothデバイスはGAPを実装する必要があるため、Bluetoothデバイスによって実装される追加のプロファイルはすべてGAPのスーパーセットになります。 アプリケーションの複雑さ、または多くのアプリケーション間でBluetoothシステムの機能の共通要件を再利用する能力に応じて、GAPのスーパーセットでも、別のプロファイルのスーパーセットでもある追加の汎用プロファイルを作成できます。 アプリケーションの相互運用性を表すトップレベルのプロファイルは、アプリケーションプロファイルと呼ばれます。
Figure 6.2: Profile Hierarchy
アプリケーションプロファイルには、参照によって、Bluetoothシステムの一般的な要件のセットを記述するGAPおよびその他の一般的なプロファイルが含まれます。
汎用属性プロファイル（GATT）は、属性プロトコル（ATT）の上に構築され、共通操作と、属性プロトコルによって転送され格納されるデータのフレームワークを確立します。 GATTは、サーバーとクライアントの2つの役割を定義します。 GATTの役割は、必ずしも特定のGAPの役割に結びついているわけではなく、上位層のプロファイルによって指定されている可能性があります。 GATTとATTは輸送に固有のものではなく、BR / EDRとLEの両方で使用することができます。 ただし、GATTとATTはサービス発見に使用されるため、LEに実装するために必須です。
GATTサーバは、属性プロトコルを介して転送されるデータを格納し、GATTクライアントからの属性プロトコル要求、コマンドおよび確認を受け入れる。 GATTサーバは、指定されたイベントがGATTサーバ上で発生したときに、要求に対する応答を送信し、設定されたときに、指示および通知を非同期的にGATTクライアントに送信します。
GATTは、GATTサーバに含まれるデータのフォーマットも指定します。 アトリビュートプロトコルによって転送されるアトリビュートは、サービスと特性としてフォーマットされます。 サービスには特性のコレクションが含まれている場合があります。 特性には、特性値を記述する単一の値と任意の数の記述子が含まれます。
サービス、特性、および特性記述子の定義された構造により、プロファイルに特定されないGATTクライアントは、GATTサーバを横断して特性値をユーザに表示することができる。 特性記述子は、ユーザが値を理解できるようにする特性値の記述を表示するために使用することができる。
GATTプロファイルは、プロファイルデータが交換される構造を指定します。 この構造は、プロファイルで使用されるサービスや特性などの基本要素を定義します。
階層の最上位レベルはプロファイルです。 プロファイルは、ユースケースを満たすために必要な1つ以上のサービスで構成されます。 サービスは、特性や他のサービスへの参照で構成されています。 各特性は値を含み、その値に関するオプションの情報を含むことができます。 サービスおよび特性ならびに特性の成分（すなわち、値および記述子）は、プロファイルデータを含み、すべてサーバ上の属性に格納される。
Figure 6.3: GATT-Based Profile Hierarchy
サービスは、デバイスまたはデバイスの一部の特定の機能または機能を達成するためのデータおよび関連する動作の集合である。 サービスは、他のプライマリまたはセカンダリサービス、および/またはサービスを構成する一連の特性を参照することがあります。
サービスには、プライマリとセカンダリの2種類があります。 プライマリサービスは、デバイスの主要機能を提供するサービスです。 セカンダリサービスは、デバイスの補助機能を提供するサービスであり、デバイス上の少なくとも1つのプライマリサービスから参照されます。
以前のクライアントとの下位互換性を維持するために、サービス定義の後のリビジョンでは、新しい参照サービスまたはオプションの特性のみを追加できます。 後のサービス定義のリビジョンは、サービス定義の以前のリビジョンからの動作の変更が禁止されています。
特定のユースケースを満たすために、1つ以上のプロファイルでサービスを使用することができます。
参照サービスとは、別のサービス定義を参照するサービスの一部として、別のサービス定義をサーバーに組み込むためのメソッドです。 サービスが別のサービスを参照する場合、参照されるサービス全体は、ネストされた参照サービスおよび特性を含む新しいサービスの一部になります。 参照されるサービスは依然として独立したサービスとして存在します。 ネストされた参照の深さには制限がありません。
特性とは、サービスで使用される値と、値がどのようにアクセスされるか、および値がどのように表示または表現されるかに関する情報などのプロパティおよび構成情報です。 特性定義には、特性宣言、特性特性、および値が含まれます。 また、特性値に関してサーバーの値または許可構成を記述する記述子を含むこともできます。
Bluetoothデバイスは、免許不要の2.4 GHz工業、科学および医療（ISM）バンドで動作します。 他の多くの技術は、無線LAN、コードレス電話、電子レンジを含むISM帯域を利用しています。 ISMバンドは、Bluetoothデバイスが他の技術の妨害者または被害者であるかもしれない他の周波数帯域にも十分に近い。 ラジオは、コロケートされていてもコロケーションされていなくてもよい。 「配置された」という用語は、コア仕様では、コア仕様では同じ製品（マルチ無線端末またはMRT）内にあるとみなされ、干渉を緩和するためにその活動を調整するメカニズムを備えている場合としない場合があります 。
適切な共存メカニズムを選択するには、無線間の予想される分離の量を決定することが重要です。 十分な分離を行うと、周波数分割複信（FDD）技術が最も効率的です。 不十分なアイソレーションまたは共用アンテナでは、時分割デュプレキシング（TDD）技術を使用する必要があります。 多くの場合、許容できるレベルの性能を達成するためには、FDD技術とTDD技術の組み合わせが必要です。
Bluetoothコア仕様は、他のデバイスへの干渉を軽減し、他のデバイスからの干渉を最小限に抑えるさまざまな機能をサポートしています。 概して、ソリューションの種類は次のカテゴリに分類されます。
Table 7.1: Interference mitigation types
Bluetoothコア仕様には、配置されたデバイスまたは配置されていないデバイスからの干渉の低減を特に対象とする機能があります。
Table 7.2: Interference mitigation features
アダプティブ周波数ホッピング（AFH）により、Bluetoothデバイスは、2.4 GHz ISM帯域の干渉に対する耐性を向上させ、他のデバイスへの干渉を回避します。 基本的な原理は、ブルートゥースチャネルが、使用チャネルがホッピングシーケンスの一部であり、使用されていないチャネルが、擬似ランダム方式で使用チャネルによってホッピングシーケンスに置き換えられる、使用済みおよび未使用の2つのカテゴリに分類されることである。 この分類メカニズムにより、Bluetoothデバイスは、Core Specification v1.1で必要とされる79個のチャネルのすべてを使用することができます。 Bluetooth仕様で許容されるチャネルの最小数は20です。
コア仕様は、ホッピングシーケンスを変更および構成するために必要な、ホッピングカーネル、ベースバンド動作、リンクマネージャプロトコル（LMP）コマンド、およびホストコントローラインターフェイス（HCI）コマンドおよびイベントを含む相互運用性を保証するために必要なAFHの側面を定義する。 Bluetooth仕様は、スレーブがチャネル分類情報をマスタに報告することを可能にするメカニズムも定義しています。
適応型周波数ホッピングは、多くのソースから得られたメトリックを利用します。 これらのメトリックが分析され、その結果のChannel_Mapが適応周波数ホッピングカーネルによって使用されます。 メトリックは、無線による測定、ホストからのデータ（HCI_set_AFH_Channel_Classificationコマンドによる）、またはスレーブまたは他のハードウェア共存インタフェースからのレポートから得られます。
AFHは共存の重要な要素ですが、状況によっては十分ではありません。
ブルートゥースと無線LANの共存は、従来、2つのプロトコル間のトラフィックに優先順位を付けるために、適応型周波数ホッピング（AFH）と専用技術を組み合わせたものでした。 Bluetoothコア仕様では、BluetoothコントローラとワイヤレスLANデバイス間のシグナリングは指定されていません。
ブルートゥースラジオと2.4GHz ISMバンドに隣接する周波数帯で動作する共同配置されたMWS無線との間には、大きな干渉が存在する可能性があります。 この干渉は、他の無線機が送信している間に一方の無線機が受信するのを防ぐことができる。
「LTEおよびWiMAXとの共存に関するフィルタの推奨事項」ホワイトペーパー1では、場合によっては、配置された干渉を許容レベルまで低減できるフィルタ仕様について説明しています。 ブルートゥースコア仕様には、Bluetoothコントローラおよびホストの機能、および配置されたMWSとBluetoothラジオ間のシグナリングおよびメッセージングメカニズムなどの従来のフィルタリングに対する補完的なソリューションが含まれています。 Figure 7.1に、これらのメカニズムの一般的なアーキテクチャモデルを示します。 このアーキテクチャは、分離が制限された別個のアンテナを前提としています。
Figure 7.1: MWS Coexistence Architecture
2つのタイプの解決策が検討されている。第1の解決策では、Bluetooth送信（TX）および受信（RX）は共に配置されたMWS活動によって制約される。この種の解決法は、純粋なTDM（時分割多重）モードと呼ばれる。第2の解決策では、Bluetooth受信のみが配置されたMWS送信によって影響され、Bluetooth送信は、配置されたMWSの動作に影響を与えない。この種の解決策は、ハイブリッドモードと呼ばれ、例えば、BluetoothトランシーバのISM帯域に急峻なロールオフ帯域選択フィルタ（BSF）を使用することによって達成される。ハイブリッドモードは、BluetoothデバイスがMWSダウンリンク時間中に安全に送信できるフィルタリングによって、MWSに対するBluetooth送信の影響が十分に低減されている場合に適用されます。 これには、Bluetooth BSFとMWS BSFの両方の制約だけでなく、BluetoothとMWSの動作周波数範囲の間に周波数ガードバンドが必要です。時間領域ソリューションの要件はまだ残っていますが、Bluetooth受信を保護するためだけです。
これらのソリューションは、MWS共存シグナリングメカニズム（[Vol 7]パートAを参照）と複数のトランスポートレイヤ（[Vol 7]パートBおよびCを参照）によって容易になります。
MWS技術は、ライセンスされた帯域で動作し、ワイドエリアネットワークサービスをサポートするための集中スケジューリングを使用します。 MWS無線は、ネットワーク基地局と時間と周波数の両方を同期させます。 基地局は、どのMWS無線が送受信するか、およびいつMWS無線がいつ、いつ受信するかを決定する。 MWS無線は、送信または受信のタイミングを制御できません。 Bluetooth通信がMRTのMWS受信を妨げると、MWS無線はBluetooth無線が自由に送信すると使用不能になります。 図7.2は、Bluetoothの活動がどのようにMWS受信機会に干渉し、同様にMWS送信がBluetooth受信を妨げるかを示しています。 図7.2の例では、MRTのBluetoothデバイスがピコネットのマスタとして動作しています。 「M」でマークされたブロックは単一スロットのマスター送信であり、「S」でマークされたブロックは単一スロットスレーブ送信である。 MWSデバイスによる受信がブルートゥース送信によって破損される可能性のある時刻は、赤色で示されます。
Figure 7.2: MWS receptions interfered with by uncontrolled Bluetooth transmissions
（Bluetoothスロット境界がMWSフレーム境界と整列しているとき）最良の相対タイミング関係であっても、MRTのBluetooth無線装置は、配置されたMWS無線との時間多重化のために、送信および受信の機会が減少する。 ブルートゥース無線機は、図7.3に示すように、MWSフレームごとに1回の送受信機会しか得られません。
Figure 7.3: Bluetooth radio has reduced transmission/receiving opportunities
その結果、4つのうち3つ（5ミリ秒のMWSフレームの場合）、または8つのうちの7つ（10ミリ秒のMWSフレームの場合）に、MWSアクティビティによってブルートゥースのスロットペアがパンクチャされる可能性があります。 さらに、ブルートゥース照会およびページングは一度に16チャネルのシーケンスを使用するので、MRT内のブルートゥース無線が照会またはページングを実行しているとき、チャネルシーケンスは5ミリ秒ごとに繰り返され、同じチャネルが、配置されたMWS活動によって繰り返しパンクチャされる 、Figure 7.4を参照のこと。 結果として、遠隔走査装置が現在のタイムアウト内にページまたは照会IDを受信することができなくなる可能性が高い。
照会またはページング・チャネル・シーケンスが繰り返しパンクチャされると、トレイン・ナッギングを使用して、チャネル・シーケンスをシフトするためにクロック・ビットに追加のオフセットを追加することができます。
Figure 7.4: Bluetooth radio can suffer Inquiry/Page failures
MWS送信がMRTのBluetooth受信に干渉するため、リモートの照会/ページデバイスから送信されたIDの最大50％は、Figure 7.5に示すように、MRTのスキャンを実行しているBluetooth無線によって受信されません。
スキャンに使用できないスロットのパターンに基づいて、一般化されたインターレーススキャンを使用して、バックツーバックスキャン中の2回目のスキャンの位相を調整できます。
Figure 7.5: Bluetooth radio can suffer inquiry scan/page scan failures
このセクションでは、MWSシステムのBluetooth CLKとMWSシステムのダウンリンク時間とアップリンク時間が一致するように、MWSシステムとのBluetooth CLKの同期を示す例を示します。 この例の外部フレームは、LTE TDDフレーム構成＃1および特殊サブフレーム構成＃1である。 任意の外部TDD / TDMAプロトコルに同じメカニズムを使用することができます。 この例では、10ミリ秒の時間間隔が示されています。
[Vol 7]パートAは、MWSフレームのタイミングを、共存シグナリングにおけるFRAME_SYNC信号からの固定オフセットとして定義します。 これをFSとしてFigure 7.6に示します。 FSは、MWSフレーム内の特定のオフセットとしてホストによって定義できます。 ピコネットマスタの場合、FSにとって最も有用な位置は、アップリンクと次のダウンリンクとの間の境界である。 これは、マスタがアップリンク中にマスタスロットで送信し、次にダウンリンク中に次のスレーブスロットで受信する必要があるためです。 FSをこの境界に置くと、マスターはBluetoothクロックを簡単に整列させて、これらのスロットの間に置くことができます。 スレーブでは状況が逆になります.FSは、ダウンリンクと次のアップリンクの境界で最も有効です。
HCIコマンドSet_External_Frame_Configuration（[Vol 2]パートE、セクション7.3.81）は、MWSフレームタイミングを記述するために使用されます。 この知識は、FSとともに、Bluetoothコントローラが相互干渉の影響を最小限に抑えるように、BluetoothクロックをMWSフレームタイミングに合わせることを可能にします。 これをFigure 7.6に示します。 赤い楕円形は、MWSとBluetoothの両方が同時に送受信し、互いに干渉しないスロットペアを示します。 MWSフレーム構造は、ダウンリンク部分（「D」）、アップリンク部分（「U」）、およびガード期間（「GP」）によって分離されたダウンリンクおよびアップリンク部分を含む特殊部分（「S」）を含む。
Figure 7.6: Alignment of MWS frame timing and Bluetooth clock
注：LTEでは、インプリメンテーションが正確なLTEタイミングにアクセスできない場合、ダウンリンクとアップリンクの境界は特別なLTEサブフレーム内のGPの中央であると想定できます。
前のセクションで説明したように、MWSとBluetoothクロックを正しく調整すると、両方のテクノロジのスループットが大幅に向上します。 マスタは、不整合を緩和するために自由に2つのメカニズムを持っています。
Loarse Clock Adjustmentsを使用して、LMP_clk_adj PDUを使用してBluetooth CLKを移動できます。 clk_adj_usパラメータは、スロットをFRAME_SYNC信号で示されたMWSアライメントポイントに合わせるために使用されます。 clk_adj_slotsパラメータを使用して、CLKの複数のスロットを時間的に前方に移動することができます。 これは、例えば、 eSCO。 Coarse Clock Adjustmentは、MWS接続やローミングによりMWSフレームのタイミングが変化する場合など、ごくまれにしか使用されません。 粗時計の調整は、ピコネット内のすべてのスレーブがそれをサポートしている場合にのみ使用できます。
マスターのもう1つのオプションは、クロックのドラッグを使用することです。 これは、所望のCLK位相が達成されるまで、スロットを数μs短くまたは長くすることによって、クロックの位相をゆっくりと前後に調整する方法です。 これは、レガシーデバイスが変更を追跡できるように設計されているため、非常に遅い調整レートであるため、デバイス間の最大自然ドリフトより速いレートでクロックドラッグを実行しないでください。 このため、主な用途は、MWSシステムとのずれが検出された場合、時間の経過と共に小さな修正を容易にすることです。 Coarse Clock Adjustmentをサポートしていないデバイスが接続されている場合、Clock Draggingを使用してスレーブをゆっくり動かすことが唯一の選択肢です。
できるだけ早く反応してミスアライメントを修正できるので、配置されたデバイスをマスターにすることをお勧めします。 スレーブが一緒に配置されたデバイスであれば、ロールスイッチを実行してマスタにすることを検討する価値があります。 あるいは、スレーブは、ピコネットクロック調整要求LMPパケットをマスタに送信することができる。 マスターには、粗いクロック調整、クロックのドラッグ、または要求を拒否するオプションがあります。
スロットアベイラビリティマスク（SAM）は、2つのブルートゥースデバイスが、送信および受信に利用可能なタイムスロットを互いに示すことを可能にする。 SAMスロットマップは、ブルートゥーススロットの可用性またはその他を指定します。 スロットは、外部条件（MWS共存など）または内部条件（スカッタネット契約など）のために利用できない可能性があります。 SAMは、BR / EDRタイムスロットのスケジューリングに新しい必須規則を課すものではありません。 代わりに、コントローラがBluetoothスロットのスケジューリングを改良してパフォーマンスを向上させるための情報を提供するだけです。
SAMスロットマップは、スケジューリング要件に基づいてコントローラ自体によって計算されます。 SAM専用に定義されたHCIコマンドはなく、デバイスがマップを交換して使用中のマップを示すことを可能にするLMPシーケンスだけです。 HCIは、 "Set_External_Frame_Configuration"（[Vol 2]パートE、セクション7.3.81を参照）および "Set_MWS_PATTERN_Configuration"（[Vol 2]パートE、セクション7.3.85を参照）およびリアルタイム信号（MWS_PATTERN_IndexやFRAME_SYNCなど） Coexistence Logical Interface（[Vol 7] Part A参照）には、MWSの共存に使用する適切なSAM_IndexおよびSAMアンカーポイントに関する情報が含まれています。 したがって、これらはこれらのLMP配列を誘発し得る。
コントローラは、LMP_SAM_switchシーケンスを開始する前にピコネットクロック調整を実行して、MWSフレームごとに使用可能なスロットペアの数を増やすことを選択できます。