1 序論

ここでは、ホストコントローラインタフェース(HCI)のコマンドやイベントとリンク層(LL)との間の典型的な相互作用を示します。 これは、「リンク層」からのリンク層制御手順に関して、「Bluetooth Host Controller Interface Functional Specification」で規定されている手順のメッセージシーケンスチャート(MSC)に焦点を当てています。 このセクションでは、最も有用なシナリオのみを示しており、すべての可能な代替案を網羅しているわけではありません。 さらに、メッセージシーケンスチャートは、エアインタフェースやホストインタフェース上のエラーを考慮していません。 すべてのメッセージシーケンスチャートでは、すべてのイベントがマスクされていないことを前提としているため、コントローラはイベントをフィルタアウトしません。

これらのメッセージシーケンスチャートのメッセージのシーケンスは説明のためのものです。 リンクレイヤやHCIが許可している場合、メッセージは異なる順序で送信されても構いません。 これらのチャートのいずれかがリンクレイヤまたはHCIパートのテキストと異なる場合は、それらのパートのテキストは規範的なものとみなされるものとする。 本パートは，情報を提供するものである。

1.1 記法

メッセージ・シーケンス・チャート（MSC）で使用される表記法は、楕円、細長い六角形、箱、線、矢印で構成されています。 上段にシャドウボックス、下段に実線の楕円で終わる縦線は、デバイス内に存在するプロトコルエンティティを示しています。 このような場合は、このようなエンティティは、そのエンティティ間の相互作用と、それらのエンティティが存在する可能性のある状態を記述します。

以下のシンボルは、相互作用と状態を表しています。

六角形 このヘキサゴン以下のトランザクションを開始するために必要な条件を示す。 六角形の位置と幅は、どのエンティティまたはエンティティがこの決定を行うかを示す。

ボックス トランザクションのグループを置き換えます。 ユーザーのアクション、またはベースバンド内のプロシージャを示すことができます。

破線ボックス トランザクションのオプショングループ。

ソリッドアロー メッセージ、シグナル、またはトランザクションを表します。 リンク層とHCIトラフィックの表示に使用できます。 いくつかのベースバンド・パケット・トラフィックも表示されます。 これらは、パケットのタイプ、またはパケット内にACK信号があることを示す表示のいずれかに続いてBBという接頭辞が付けられています。

破線矢印 オプションのメッセージ、シグナル、またはトランザクションを表します。 リンク層およびHCIトラフィックの表示に使用することができます。

1.2 CONTROL FLOW

いくつかのメッセージシーケンスは、いくつかのチャートに分割されています。 これらのチャートは、ステップ番号の後に任意の文字で複数のパススルーを持つ異なるステップ番号で順番にマークされています。 数字は、通常の順序または要求された順序を示す。 文字は代替パスを表す。 例えば、ステップ3の後にステップ4があり、ステップ5bの代わりにステップ5aを実行することができます。

1.3 サンプルMSC

図1.1に示す例では、AとBという名前の2つのデバイスの相互作用を示すプロトコルエンティティが示されています。 このセクションの他のMSCでは、2つ以上のデバイスの相互作用を示している場合があります。

1.4 フォワード互換性

本編のメッセージシーケンスの多くは、該当するシーケンスよりも後に仕様に追加された拡張または拡張された バリアントを持つHCIコマンドやイベントを使用しています。 いくつかの場合（例えば、[Vol.2]パートEの3.1.1節を参照）では、ホストはMSCに示されているバージョンではなく、新しいバージョンを使用することが要求されます。 これが要求されていない場合でも、ホストの実装者は新しいバージョンを使用することを好むかもしれません。

このような状況では、MSC は新しい機能を使用するために書き換えられたのではなく、変更されていないままになっています。 一般的には、新しいコマンドやイベントは古いものを直接置き換えることになりますが、これは必ずしもそうとは限らず、読者は想定すべきではありません。

2 スタンバイ州

2.1 初期設定

LE コントローラの初期設定を行うには、以下の一連の動作が必要となる場合があります。

最初に、ホストは、No OPeration コマンド・オペコードの Command Complete イベントを使用して、ホストが現在送信を許可されている HCI コマンド・パケットの数をコントローラが示すのを待ちます。 次に、コントローラを既知の状態にリセットします。 次に、このコントローラで低エネルギーがサポートされていることを確認するために、ローカルでサポートされている機能を読み取る必要があります。 次に、イベントマスクとLEイベントマスクを設定し、コントローラがホストに生成するイベントを有効にします。 次に、Read Buffer Size と LE Read Buffer Size コマンドを使用して、データフローに使用可能なバッファをチェックします。 次に、ローカルでサポートされている LE 機能を読み込み、使用したい機能を選択します。 最後に、コントローラにパブリック・デバイス・アドレスがあれば、それを読み込みます（図 2.1 参照）。

2.2 ランダムデバイスアドレス

デバイスはランダムなデバイスアドレスを使用することができますが、このアドレスは広告、スキャン、またはイニシエート中に使用される前に設定する必要があります(図2.2参照)。

2.3 ホワイトリスト

広告、スキャン、またはイニシエートがホワイトリストを使用する前に、ホワイトリストをクリアし、必要に応じてデバイスを追加することができます（図 2.3 を参照）。

2.4 解決リストへのIRKの追加

広告、スキャン、またはイニシエートが解決リストを使用できるようになる前に、 必要に応じて解決リストをクリアしてデバイスを追加することができます (図 2.4 を参照)。

2.5 デフォルトデータ長

接続を作成する前に、ホストは新しい接続に使用するコントローラの最大送信パケットサイズと最大パケット送信時間の優先値を指定することができます。 これは、マスタまたはスレーブのいずれかで行うことができます。

2.6 定期的な広告主リスト

定期広告主リストは、必要に応じてクリアし、エントリを追加してから利用することができる（図2.6参照）。

3 広告掲載状態

3.1 誘導型広告

デバイスは、広告を有効にすることで広告状態に入ることができます。 また、これを行う前に広告パラメータを設定する必要があります（図3.1参照）。

3.2 ダイレクトアドバタイジング

デバイスは、イニシエータからの接続を許可するために有向広告を使用することがあります。 高デューティサイクルのダイレクトアドバタイズメントは、コントローラでは時間的に制限されているため、接続が作成される前に失敗する可能性があります。 この例では、失敗した場合のみを示しています（図3.2を参照）。 Low duty cycle directed advertisingも同様に、Advertising Stateに入るためには有効にする必要があります。 デバイスは、これを行う前に広告パラメータも構成する必要があります（図3.3を参照）。

3.3 ADV_EXT_INDを使用した広告

デバイスは、セットの広告を有効にすることで広告状態に入ることができます。 また、これを行う前に広告セットパラメータを構成する必要があります（図3.4を参照）。

3.4 スキャン要求通知

デバイスは、広告セットでスキャン要求通知を有効にすることができる（図3.5参照）。

3.5 広告期間の終了

デバイスは、限られた時間だけセットを広告することで、広告状態に入ることができます（図3.6参照）。

3.6 期間限定広告

デバイスは、セット内の定期的な広告を有効にすることで、広告状態に入ることができます。 また、その前に広告セットのパラメータを設定しておく必要があります（図3.7を参照）。

3.7 コネクションレスコンスタントトーン拡張伝送

デバイスは、Constant Tone Extension（図3.8参照）を含む定期的な広告パケットを送信することができます。

4 スキャン状態

4.1 PASSIVE SCANNING

デバイスはパッシブスキャンを使用して、エリア内の広告デバイスを見つけることができます。 これは、ピアデバイスから広告パケットを受信し、ホストに報告します(図4.1参照)。

4.2 アクティブ・スキャン

デバイスはアクティブ・スキャニングを使用して、ユーザー・インターフェースの入力に有用なデバイスに関するより多くの情報を得ることができます。 アクティブ・スキャニングには、より多くのリンク・レイヤー広告メッセージが含まれます（図4.2参照）。

4.3 プライバシーのあるダイレクト広告のためのパッシブ・スキャニング

デバイスがコントローラでプライバシーをサポートしていない場合、コントローラ解決リストを通したフィルタリングを必要とせずに、プライバシーをサポートしているデバイスから LE Directed Advertising Report イベントを転送することを選択することができる。

4.4 プライバシーを使用したアクティブ・スキャン

デバイスはアクティブ・スキャンを使用して、ユーザー・インターフェースを作成するのに有用なデバイスに関するより多くの情報を取得してもよい。 アクティブ・スキャニング中にプライバシーを使用して、アクティブ・スキャニング中にどちらかのデバイスを追跡することをより困難にしてもよい（図4.4参照）。

4.5 プライバシーとコントローラに基づく解決可能なプライベート・アドレス生成を用いたアクティブ・スキャニング

コントローラは、デバイスがアクティブスキャンとプライバシー広告を使用している場合、両方のデバイスで使用されている解決可能なプライベートアドレスを定期的に更新します。 ホストはいつでもコントローラから現在使用されているアドレスを取得することができます(図4.5参照)。

4.6 セカンダリ広告チャンネルでのアクティブスキャン

デバイスは、ユーザー・インターフェースを埋め込むのに有用なデバイスに関するより多くの情報を得るために、セカンダリ広告物理チャネルでアクティブ・スキャンを使用することができます（図4.6を参照）。

4.7 スキャンタイムアウト

デバイスは、限られた時間だけスキャンすることができる（図 4.7 を参照）。

4.8 定期的な広告のスキャン

デバイスは、定期的な広告主との同期を確立し、定期的な広告パケットをホストに報告することができます（図4.8を参照）。

4.9 周期的広告のスキャニングのキャンセル

デバイスは、定期的な広告主との同期を確立するための保留中の要求をキャンセルすることができます。 この例では、同期化に失敗した後に同期化がキャンセルされたことを示しています（図4.9を参照）。

4.10 周期的広告の同期化タイムアウト

デバイスは、定期的な広告主との同期を失う可能性があります（図4.10参照）。

4.11 定期的な広告の受信の停止

周期的な広告主と同期した後、ホストは同期を終了させることができます（図 4.11 参照）。

4.12 コネクションレスコンスタントトーン拡張受信

デバイスは、Constant Tone Extensionを含む定期的な広告パケットを受信し、ホストにIQサンプルを送信することができます（図4.12参照）。

4.13 レポートの別個のイネーブルとの同期化

デバイスは、定期的な広告列車との同期を確立した後、レポートを有効にしてもよいし、無効にしてもよい。

5 起動状態

5.1 接続の初期化

デバイスは広告主への接続を開始できます。 この例では、開始が成功し、両方のデバイスがアプリケーション・データを送信できることを示しています（図 5.1 を参照）。

5.2 イニシアチブのキャンセル

デバイスは、保留中の接続作成をキャンセルすることができます。 この例では、開始に失敗した後、開始のキャンセルが行われたことを示しています（図 5.2 参照）。

5.3 プライバシーを使用した間接広告を使用した接続の開始

デバイスは、広告主への接続を開始することができます。 接続の開始時にプライバシーを使用して、接続のセットアップ中にどちらかのデバイスを追跡することをより困難にすることができます。 この例では、両方のデバイスがアプリケーション・データを送信できるようになり、接続が成功したことを示しています（図 5.3 を参照）。

5.4 プライバシーを使用したダイレクト広告を使用した接続の開始

デバイスは、Directed Advertisingを使用している広告主に接続を開始することができます。 接続の開始時にプライバシーを使用して、接続のセットアップ中にどちらかのデバイスを追跡したり、単一の開始者をターゲットにしたりすることをより困難にすることができます。 この例では、開始が成功し、両方のデバイスがアプリケーション・データを送信できるようになっています（図 5.4 を参照）。

5.5 接続の確立に失敗した接続の初期化

この例では、デバイスB（広告主）がデバイスAから送信されたデータ物理チャネルPDUに応答しないため、確立に失敗したイニシエーションを示しています。

5.6 第2の広告物理チャネル上での接続の初期化

デバイスは、セカンダリ・チャネルで広告主との接続を開始できます。 この例では、開始が成功し、両方のデバイスがアプリケーションデータを送信できるようになります（図 5.6 を参照）。

5.7 チャネル選択アルゴリズム#2 コネクションの開始

デバイスがチャネル選択アルゴリズム#2機能をサポートしている場合、広告物理チャネルPDUのChSelフィールドが1に設定されている広告主に対して、チャネル選択アルゴリズム#2を使用する接続を開始することができます。 この例では、チャネル選択アルゴリズム#2を使用した接続の開始に成功したことを示しています。

6 接続状態

6.1 データの送信

2 つのデバイスが接続状態になると、どちらかのデバイスがデータを送信できます。 この例では、両方のデバイスがデータを送信する様子を示しています。 例えば、Attribute Protocol が読み取り要求を行い、読み取り応答が返された場合などです（図 6.1 参照）。

6.2 コネクションの更新

接続のマスタは、リンクレイヤ制御手順を使用して接続の更新を要求することができます（図 6.2 参照）。

6.3 チャネルマップの更新

マスタのコントローラは、ホストからいくつかのチャネル分類データを受信し、チャネル更新リンク層制御手順を実行することができます（図6.3参照）。

6.4 機能交換

マスタデバイスとスレーブデバイスの両方が、リモートデバイスで利用可能な機能のセットを発見することができます。 これを実現するために、Feature Exchange Link Layer Control Procedure を使用します（図 6.4 および図 6.5 を参照）。

6.5 バージョン交換

どちらのデバイスでもバージョン交換手順を実行することができます（図6.6および図6.7を参照）。

6.6 暗号化の開始

接続で暗号化が開始されていない場合は、マスターによって暗号化が開始されることがあります（図 6.8 を参照）。

6.7 長期キーなしで暗号化を開始する

接続上で暗号化が開始されていない場合、マスターによって暗号化が開始されることがあります。 図 6.9 にスレーブがマスタの長期鍵を持っていない場合の失敗例を示します。

6.8 イベントマスク付き暗号化の開始

接続上で暗号化が開始されていない場合、マスタによって暗号化が開始されることがあります。 図 6.10 にスレーブが HCI_LE_Long_Term_Key_Request イベントをマスクアウトした場合の失敗例を示します。

6.9 スレーブがエンクリプションをサポートしていない状態でエンクリプションを開始する

接続で暗号化が開始されていない場合は，マスタで暗号化が開始されることがあります。 図6.11に暗号化機能をサポートしていないスレーブの失敗例を示します。

6.10 暗号化の再起動

暗号化がすでに接続で開始されている場合、マスターによって再起動されることがあります。 これは、Security Managerプロトコルによってネゴシエートされたより強力な暗号化を使用するために必要な場合があります(図6.12参照)。

6.11 DISCONNECT

接続をアクティブにしておく必要がなくなると、ホストは接続を切断することができます。 これはどちらのデバイスでも行えます（図 6.13 および図 6.14 を参照）。

6.12 CONNECTION PARAMETERS REQUEST

接続のマスタまたはスレーブは、リンクレイヤ制御手順（図 6.15～図 6.22 参照）を使用して、接続パラメータの変更を要求することができます。

6.13 LE PING

ホストは、HCI_Write_Authenticated_Payload_Timeoutコマンドを使用して、リンク層が暗号化を使用する際に強制する有効なMICを含むパケット間の最大間隔を変更することができます。

リンク層は、リモートデバイスが LE Ping 機能をサポートしていない場合でも、LE Ping 手順を使用してリモートデバイスを認証することができます。 この手順は、有効な MIC を含むパケットをリモートデバイスから勧誘する場合にも使用できる。 LL A はマスターであってもスレーブであってもよい。 図6.23に示すシーケンスで、LL B が LL_UNKNOWN_RSP PDU で応答した場合、LL A は同一接続に対して別の LL_PING_REQ を送信してはならない。

有効な MIC を持つパケットが LE 認証済みペイロードのタイムアウト時間内に受信されなかった場合、ホストはタイマーの期限が切れたことを通知する。

ホストが Authenticated Payload Timeout を設定すると、TLE_Authenticated_Payload タイマーはリセットされる。

6.14 データ長の更新

接続が作成されると、ホストは、接続に使用する最大送信パケットサイズと最大パケット送信時間を提案することができます。 これは、マスターまたはスレーブのいずれかで行われます。

6.15 PHY UPDATE

接続のマスタまたはスレーブは、リンク層の制御手順を用いて PHY の変更を要求することができる(図 6.28 から図 6.36 参照)。 図 6.30 及び図 6.33 に示す一連のイベントは、機能交換の前にのみ発生し、1 回の接続につき 1 回しか発生しない。

6.16 使用チャネルの最小数の要求

スレーブデバイスが Minimum Number of Used Channels 手続きをサポートしている場合、指定された PHY で使用される最小チャネル数を要求することができる。 この例は、要求が成功して、要求された最小使用チャネル数でチャネルマップが更新されたことを示している。

6.17 LL 手続き コレシジョン

マスタとスレーブのリンクレイヤは、同時に同じ LL 手続きを開始することができます。

6.18 コンスタントトーン拡張要求

接続のマスタまたはスレーブは、リモートデバイスに対して、コンスタントトーン拡張を含む LL_CTE_RSP PDU の送信を要求することができます（図 6.39～図 6.41 参照）。 図6.40に示す一連のイベントは、機能交換の前にのみ発生する可能性があり、1接続につき1回のみ発生する可能性があります。 これは、[Vol.6]パートB、セクション4.6で要求されているように、リンクレイヤは、相手がサポートしていないことを知っている手順を使用してはならないためです。

7 周期的な広告の同期転送

以下の例では、装置Ｂが定期広告を実施している。 デバイスＡまたはデバイスＢのいずれかがデバイスＣと接続状態にあり、定期広告列車に関する定期広告同期情報をデバイスＣに転送する。

7.1 スキャナによる転送、初期障害時のレポート

走査装置（Ａ）は、周期的広告同期情報を装置Ｃに転送し、周期的広告列車のリッスンを開始するが、明示的に要求された場合にのみホストにレポートを送信する。

7.2 スキャナによる転送、最初に有効になったレポート

走査装置（Ａ）は、定期広告同期情報を装置Ｃに転送し、装置Ｃは定期広告列車のリスニングを開始し、直ちにホストにレポートを送信する。

7.3 広告主による転送

広告主（Ｂ）は、その定期広告に関する定期広告同期情報を装置Ｃに直接転送するが、この例では、ホストＣへのレポートは無効化されている。