6B - arakomiuma/bt GitHub Wiki

1.4 物理チャネル

[Vol.6] Part A, Section 2 で規定されているように、2.4GHz の ISM 帯には 40 個の RF チャネルが定義されている。これらのRFチャネルは、広告物理チャネル、周期物理チャネル、およびデータの3つのLE物理チャネルに割り当てられる。広告物理チャネルは、デバイスの発見、接続の開始、およびデータの放送のために、４０個のＲＦチャネルすべてを使用する。これらのＲＦチャネルは、初期広告およびすべてのレガシー広告活動に使用される「プライマリ広告物理チャネル」として知られる３つのＲＦチャネルと、関係する通信の大部分に使用される「セカンダリ広告物理チャネル」として知られる３７個のＲＦチャネルに分割される。データ物理チャネルは、接続されたデバイス間の通信に最大37個のRFチャネル（4.5.8項参照）を使用します。これらのRFチャネルのそれぞれには、一意のチャネルインデックスが割り当てられます（セクション1.4.1参照）。周期的物理チャネルは、広告物理チャネル上の第２の広告物理チャネルと同じＲＦチャネルを使用する。

通信を希望する２つのデバイスは、共有物理チャネルを使用する。これを実現するために、それらのトランシーバは、同時に同じRFチャネルにチューニングされなければならない。

RFチャネルの数には限りがあり、多くのBluetoothデバイスが同じ空間的・時間的領域内で独立して動作している可能性があることを考えると、2つの独立したBluetoothデバイスがトランシーバを同じRFチャネルにチューニングしてしまい、物理チャネルの衝突を引き起こす可能性が高くなります。この衝突の望ましくない影響を軽減するために、物理チャネル上の各送信は、物理チャネルにチューニングされたデバイスによる相関コードとして使用されるアクセスアドレスで始まります。このアクセス・アドレスは物理チャネルのプロパティです。アクセス・アドレスは、すべての送信パケットの開始時に存在します。

リンク・レイヤが使用する物理チャネルは一度に1つです。

リンク層は、物理チャネルのタイミング、周波数、アクセスアドレスに同期している場合は、データ物理チャネル上では「接続」、周期的な物理チャネル上では「同期」している（チャネル上での通信に積極的に関与しているか否かは問わない）。

1.4.1 物理チャネルの指標

表 1.2 に PHY チャネルから物理チャネルインデックスと物理チャネルタイプへのマッピングを示す。表 1.2 の「●」は、指定されたチャネルタイプで PHY チャネルとインデックスが使用されていることを示す。

-- Table 1.2: Mapping of PHY channel to physical channel index and channel type --

中略

3.2 データホワイトニング

データホワイトニングは、データ・ビット・ストリーム中の長いゼロまたは１の連続（例えば、0000000b または 1111111b）を避けるために使用される。ホワイトニングは、すべてのリンクレイヤパケットのＰＤＵ及びＣＲＣに適用され、送信機でのＣＲＣ生成後に実行されるものとする。パケットの他の部分のホワイトニングは行わない。脱ホワイトニングは、受信機でのCRCチェックの前に行う（図3.1参照）。

ホワイトナーとデホワイトナーは、多項式x7 + x4 + 1の7ビット線形フィードバックシフトレジスタを使用して、同じように定義されています。ホワイトニングまたはディホワイトニングの前に、シフトレジスタは、パケットが送信される物理チャネルインデックスから導出されるシーケンスで初期化されます。

ポジション0は1に設定されます。
位置１から位置６は、位置１の最上位ビットから位置６の最下位ビットまで、送信時または受信時に使用されるチャネルのチャネルインデックスに設定される。

例えば、チャネルインデックスが 23（0x17）の場合、以下のように設定されます。ポジション0=1 ポジション1=0 ポジション2＝1 ポジション3=0 ポジション4＝1 ポジション5＝1 ポジション6＝1

図3.4は、データホワイトニングを生成するためのリニアフィードバックシフトレジスタ（LFSR）の例を示しています。

中略

4.2 タイミング要件

4.2.1 節に規定する場合はアクティブクロック精度を使用し、それ以外の場合はスリープクロック精度を使用する。

4.2.1 アクティブクロック精度

接続イベント中、アクティブスキャン中、及び接続要求時のパケット送信の平均タイミングは、アクティブクロックの精度を用いて、±50ppm以下のドリフトで決定される。すべての瞬間的なタイミングは、平均タイミングから2μsを超えてはならない。注：これは、パケットの開始が前のパケットの終了から150±2μs後に送信されることを意味する。より具体的には、これらの要件は、間の間隔に適用される。

同一接続イベント内の隣接パケット
広告パケットと、SCAN_REQ、AUX_SCAN_REQ、CONNECT_IND、またはAUX_CONNECT_REQ PDUを含むパケット。
SCAN_REQ を含むパケットと SCAN_RSP PDU を含む応答パケット
AUX_SCAN_REQ PDUを含むパケットとAUX_SCAN_RSP PDUを含む応答パケット
AUX_CONNECT_REQ PDUを含むパケットと、AUX_CONNECT_RSP PDUを含む応答パケット。

4.2.2 スリープ・クロックの精度

他のすべての活動の平均タイミングは、睡眠時計の精度を用いて、±500ppm 以下のドリフトで決定される。すべての瞬間的なタイミングは、平均タイミングから 16μs を超えてはならない。接続において、デバイスは、直近に送信された LL_CLOCK_ACCURACY_REQ または LL_CLOCK_ACCURACY_RSP PDU の SCA フィールドに示されたワーストケースよりも精度の低いスリープクロックを使用してはならない。リンク層が現在の接続において、スリープクロック精度更新手順（5.1.14 節参照）を開始していない場合には、マスタは接続の作成に使用した CONNECT_IND PDU 又は AUX_CONNECT_REQ PDU の SCA で示されたワーストケースと同程度の精度のスリープクロックを使用し、スレーブは±500ppm 以上の精度のスリープクロックを使用するものとする。注意：したがって、これらの要件は、接続イベントのアンカーポイント間の時間（4.5.7 節参照）、アドバタイジング及び周期的アドバタイジング間隔及び advDelay 値（4.4.2.2 節参照）、同じ拡張アドバタイジングイベント又は周期的アドバタイジングイベント内のパケット間の全ての間隔、及びアドバタイジング PDU の AuxPtr フィールド及び SyncInfo フィールドで指定された全てのオフセットに適用される。注意：これは、合計±1000ppm のスリープクロック精度を持つ 1 s の接続間隔では、スレーブコントローラがほぼ完全な接続間隔でスリープクロックを使用していたと仮定すると、アンカーポイントの両側に 1 ms + 16 μs のウィンドウが広がることを意味します。

4.2.3 レンジ遅延

2 つのデバイスが数メートル以上離れている場合、それらの間で信号が伝搬するのにかかる時間は、4.2.1 節で定義されているアクティブクロックの精度と比較して非常に大きくなります。デバイスが最大 D メートル離れている可能性のあるパケットをリッスンしている場合、パケットが送信されたであろう公称最新時間（例えば T_IFS + 2 μs）の後、余分に 2D * 4 ns をリッスンしなければなりません。 (1/c ~= 3.3 * 屈折率 ns/m なので、4 ns は保守的な余裕を与えます。) 図 4.2 は、マスターパケット送信に対する範囲遅延を示しています。

4.2.4 ウィンドウの拡大

様々な状況において、リンクレイヤはあるウィンドウ内（receiveWindowStart から receiveWindowEnd まで）またはある時刻（この場合、 receiveWindowStart と receiveWindowEnd はその時刻）にパケットを受信することを期待していますが、スリープクロックの精度（4.2.2 節参照）の関係上、送信側のリンクレイヤではそのウィンドウの正確なタイミングが不確かな場合があります。したがって、受信側はこの不確実性を考慮してリスニング時間を調整しなければならない。この待ち受け時間の増加をウィンドウ拡大と呼ぶ。クロックの不確かさが純粋に百万分の一（ppm）単位で与えられると仮定すると、次のように計算されます。 windowWidening = ((txSCA + rxSCA) / 1000000) * (receiveWindowEnd - timeOfLastSync) + 32 μs ここで、rxSCA は受信リンク層のスリープクロック精度であり、その他のパラメータは表 4.1 に示すとおりである。なお、txSCA は送信リンク層のスリープクロック精度、timeOfLastSync は受信リンク層が送信リンク層と同期できた直近の時刻である。受信側に送信リンク層のクロックの精度が高い場合、受信側は windowWidening の値を小さくしてもよい。受信側は、receiveWindowStart の前の windowWidening から始まり、receiveWindowEnd の後の windowWidening までリッスンする。

中略

4.4 非接続状態

4.4.1 スタンバイ状態

スタンバイ状態はリンク層のデフォルト状態である。リンクレイヤは、スタンバイ状態ではパケットの送受信を行わない。リンク層は、スタンバイ状態を解除して、アドバタイジング状態、スキャニング状態又はイニシエータ状態に移行することができる。

4.4.2 広告状態

リンクレイヤは、ホストからの指示があった場合、アドバタイズ状態とする。広告状態になった場合、リンク層は広告イベント、定期的な広告イベント、またはその両方で広告 PDU（2.3.1 節参照）を送信する。各広告イベントは、使用済みのプライマリ広告物理チャネルインデックス上に送信される1つ以上の広告PDUで構成される。広告イベントは、使用済みのプライマリ広告物理チャネルインデックスのそれぞれについて1つの広告PDUが送信された後に終了する（4.4.2.1項参照）。広告イベント内の一部の広告PDUが省略され、広告イベントの開始が遅れたり、広告イベントが早く閉じたりしてもよいし、他の機能に対応するために広告イベント全体が省略されてもよい。連続する2つの広告イベント間の時間は、セクション4.4.2.2.2で定義される。広告イベントは、以下のタイプのいずれかとすることができる。

接続可能でスキャン可能な無指向イベント
接続可能な無指向イベント
コネクテッドディレクションイベント
非接続型非スキャン型イベント
非接続型の非スキャン型イベント
スキャン可能な無指向イベント
スキャン可能な指示イベント広告イベントで使用されるプライマリ広告物理チャネルインデックスごとに、最大1つの広告PDUを送信しなければならない。特に指定がない限り、プライマリ広告物理チャネルインデックスは、どのような順序でも使用することができる。広告イベントタイプは、許容される応答 PDU を決定する。表4.2に、各広告イベントの許容応答を示します。接続可能でスキャン可能な無向イベント、接続可能で無向イベント、接続可能で無向イベント、接続可能で有向イベントを総称して接続可能イベントと呼び、残りのイベント（非接続可能でスキャン不可能な無向イベント、非接続可能でスキャン不可能な有向イベント、スキャン可能で無向イベント、スキャン可能で有向イベント）を総称して非接続可能イベントと呼びます。接続可能なイベントと走査可能な未指示イベント、走査可能な未指示イベント、走査可能な有向イベント、走査可能な有向イベントを総称して走査可能イベントと呼び、残りのイベント（非接続可能なイベントと非走査可能な無向イベント、非接続可能なイベントと非走査可能な有向イベント、接続可能な無向イベント、接続可能な有向イベント）を総称して非走査可能イベントと呼ぶことにします。広告主が、明示的に許可されていない広告イベントのPDUを受信した場合、それは無視されなければならない。 PDUを受信しないか、受信したPDUが無視された場合、広告主は、次に使用されるプライマリ広告チャネルインデックスに広告PDUを送信するか、広告イベントをクローズしなければならない。

4.4.2.1 広告チャネルインデックスの選択

広告イベントは、3 つの事前定義されたプライマリ広告物理チャネルを使用します。プライマリアドバタイジング物理チャンネルインデックスは使用されるか、または未使用です。 AUX_ADV_IND と AUX_CHAIN_IND PDU の場合、AuxPtr フィールドの Channel Index サブフィールドで使用されるセカンダリアドバタイジングチャンネルインデックスは実装固有のものです。衝突を避けるために十分なチャンネルダイバーシティを使用することを推奨する。各周期的広告列車は 16 ビットのイベントカウンタ（paEventCounter）を持たなければならない。このカウンタの初期値は実装に依存する。このカウンタは、AUX_SYNC_IND PDU が実際に送信されたかどうかに関わらず、周期的広告間隔（4.4.2.2.3 節参照）ごとに 1 つずつインクリメントされなければならない。 AUX_SYNC_IND PDU は、このイベントカウンタを使用してチャネル選択アルゴリズム #2（4.5.8.3 節参照）を使用する。リンク層は、ホストが指定したプライマリ及びセカンダリの広告物理チャネルインデックスを使用し、使用したプライマリ及びセカンダリの広告物理チャネルインデックスは、広告状態になった時に有効とする。リンク層は、ホストが「unknown」とマークしたセカンダリチャネルを全て使用する必要はない。

4.4.2.2 広告イベント

広告イベントは、プライマリ広告物理チャネル上で送信される１つ以上の広告PDUとして定義される。通常は、各広告イベントのすべての使用済み広告インデックス上にPDUが送信される。広告イベントは、CONNECT_INDを受信した後、またはSCAN_RSPが送信されたときに、早期に閉じることができる。セカンダリ広告物理チャネルで送信される広告パケットは、広告イベントの一部ではありません。 ADV_EXT_IND PDUを使用する広告イベントも、拡張広告イベントの一部である可能性があります。同じ広告イベント内のAuxPtrフィールドを含むすべてのADV_EXT_IND PDUは、同じAUX_ADV_INDパケットを指すものとする。

4.4.2.2.1 広告間隔

低デューティサイクルモードで使用されるすべての無指向型広告イベントまたは接続可能な指向型広告イベントについて、同じ広告セット（4.4.2.10項参照）の2つの連続した広告イベント（T_advEvent）が開始するまでの時間は、各広告イベントについて以下のように計算されます。 T_advEvent = advInterval + advDelay 広告間隔（advInterval）は、20ms～10,485.759375s の範囲で、0.625ms の整数倍とする。 advDelay は、0ms から 10ms の範囲の擬似乱数値とする。広告イベントごとにリンク層が生成する。図 4.3 に示すように、広告イベントは advDelay を用いて時間的に摂動される。

4.4.2.2.2 拡張広告イベント

拡張広告イベントは、広告イベントの開始時に始まり、その広告イベントのPDUとその下位セットで構成される。拡張広告イベントは、そのような最後のPDUで終了する。複数の拡張広告イベントが互いに重なることがある。これは、複数の広告イベント中の AuxPtr フィールドを含む ADV_EXT_IND PDU が同じ AUX_ADV_IND パケットを指している場合や、ADV_EXT_IND PDU と AUX_ADV_IND PDU の間に別の広告イベントが介在している場合に発生する可能性があります。 T_advEvent、advInterval、advDelayは、4.4.2.2.1項と同じ意味を持ちます。図4.4は、重複する拡張広告イベントの例を示しています。補助広告セグメントは、拡張広告イベントの最初のAUX_ADV_IND PDUで始まり、拡張広告イベントの終了時に終了します（1つの補助広告セグメントは複数の拡張広告イベントに属することができます）。同じ広告セットの2つの補助広告セグメントは、互いに重なってはなりません。図4.5に、複数の拡張広告イベントに属する補助広告セグメントの例を示す。広告主は、2つのPDUが同じ受信ウィンドウ内に入るように、補助広告セグメント内にPDUを配置してはならない。広告主がTミリ秒のオフセットを含むAuxPtrフィールドを持つPDUを送信する場合、元のPDUの補助パケットの開始から2.5*Tマイクロ秒以内に、補助パケットと同じRFチャネル上で他のパケットの送信を開始してはならない。

4.4.2.2.3 周期的な広告イベント

周期的広告間隔は、同一広告セットからの2つのスケジュールされたAUX_SYNC_IND PDUが開始されるまでの間隔である（何らかの理由でPDUが送信されない場合でも）。周期的広告間隔は、7.5msから81.91875秒の範囲内で1.25msの整数倍でなければならない。周期広告イベントは、AUX_SYNC_IND PDUとその下位セットから構成される。同一の周期的アドバタイズメントトレインに対する2つの周期的アドバタイズメントイベントは、互いに重なってはならない。周期的広告が有効な間は、周期的広告間隔を変更してはならない。

4.4.2.3 接続可能で走査可能な無指向イベントタイプ

接続可能でスキャン可能な無向広告イベントタイプが使用されると、広告表示（ADV_IND PDU）がリンク層から送信されます。接続可能でスキャン可能な無向広告イベントタイプを使用すると、スキャナまたはイニシエータは、スキャン要求または接続要求のいずれかで応答することができる。スキャナは、広告主に関する追加情報を要求するためにスキャン要求（SCAN_REQ PDU）を送信することができる。イニシエータは、接続要求（CONNECT_IND PDU）を送信して、リンクレイヤに接続状態にすることを要求することができる。リンクレイヤは、スキャナまたはイニシエータからの要求に対して、同じプライマリ広告チャネルインデックスをリッスンする。広告主は、広告フィルタポリシーで許可されたスキャナから自装置アドレスを含むSCAN_REQ PDUを受信した場合、同じプライマリ広告チャネルインデックス上のSCAN_RSP PDUで応答する。 SCAN_RSP PDUが送信された後、または、広告フィルタポリシーがSCAN_REQ PDUの処理を許可しなかった場合、広告主は、次に使用されるプライマリ広告チャネルインデックスに移動して別のADV_IND PDUを送信するか、広告イベントを閉じなければならない。広告主が、広告フィルタポリシーで許可されたイニシエータから、自分のデバイスアドレスを含むCONNECT_IND PDUを受信した場合、リンク層は、広告状態を終了し、4.5.5節で定義されたスレーブロールでの接続状態に遷移する。広告フィルタポリシーが受信したCONNECT_IND PDUの処理を許可しなかった場合、広告主は、次に使用されるプライマリ広告チャネルインデックスに移動して別のADV_IND PDUを送信するか、広告イベントを終了する。広告イベント内の連続する2つのADV_IND PDUの開始間の時間は、10ms以下でなければならない。広告イベントは、広告間隔内に閉じなければならない。図 4.7 に、すべてのプライマリ広告物理チャネルインデックスを使用し、SCAN_REQ または CONNECT_IND PDU を受信しない場合の広告イベントの例を示す。 SCAN_REQ PDUを受信し、SCAN_RSP PDUを送信する間、すべてのプライマリ広告物理チャネルインデックスを使用した広告イベントの2つの図を図4.8と図4.9に示します。図4.10は、第2のプライマリ広告チャネルインデックスでCONNECT_IND PDUを受信している間の広告イベントを示しています。リンク層のプライバシーが有効になっている場合は、6.2.1 節の要件に従うこと。

4.4.2.4 接続可能な指向イベントタイプ

接続可能な誘導型広告イベントタイプを使用すると、リンク層から誘導型広告表示が送信されます。接続可能な直接広告イベントタイプを使用すると、イニシエータが応答して、広告主とイニシエータの両方が接続状態になるようにすることができます。接続可能な有向広告イベントタイプは、ADV_DIRECT_IND PDU（4.4.2.4.1 節～4.4.2.4.3 節参照）または ADV_EXT_IND PDU（4.4.2.4.4 節参照）のいずれかを使用することができる。単一の接続可能な指向型広告イベントは、これら2つのPDUタイプのうちの1つだけを使用しなければならない。リンク層のプライバシーが有効化されている場合は、セクション6.2.2.2の要件にも従うこと。

4.4.2.4.1 ADV_DIRECT_IND を使用する接続可能な有向イベントタイプ

この手順は、LE 符号化された PHY 上で接続可能な誘導型イベントタイプを使用する場合には使用しない。ＡＤＶ＿ＤＩＲＥＣＴ＿ＩＮＤを使用する接続可能な指示付き広告イベントタイプは、イニシエータがリンク層接続を確立するためにプライマリ広告物理チャネル上の接続要求で応答することを可能にする。 ADV_DIRECT_IND PDU には、イニシエータのデバイスアドレスと広告主のデバイスアドレスの両方が含まれる。アドレスを指定したイニシエータのみが、広告主にCONNECT_IND PDUを送信することで、広告主とのリンクレイヤ接続を開始することができます。広告主によって送信されるすべてのADV_DIRECT_IND PDUの後、広告主は、同じプライマリ広告チャネルインデックス上のCONNECT_IND PDUをリッスンしなければならない。受信したSCAN_REQ PDUは無視されるものとする。広告主が自分のデバイスアドレスを含むCONNECT_IND PDUを受信し、ADV_DIRECT_IND PDUにイニシエータデバイスアドレスが含まれている場合、リンク層は広告状態を終了し、4.5.5節で定義されているスレーブロールでの接続状態に遷移する。そうでなければ、広告主は、次に使用されるプライマリ広告チャネルインデックスに移動して別のADV_DIRECT_IND PDUを送信するか、Advertisingイベントを終了する。コネクティブルディレクテッド広告は、低デューティサイクルまたは高デューティサイクルモードで使用することができる。低デューティサイクルの接続可能な指示型広告は、特定のデバイスとの再接続が必要だが、時間が重要ではない場合や、中央のデバイスが範囲内にあるかどうかがわからない場合のために設計されています。高負荷サイクル接続可能な指向型広告は、高速なリンクレイヤ接続のセットアップが不可欠な場合（再接続など）向けに設計されています。注：高デューティサイクル接続可能な指向型広告は、消費電力と帯域幅を必要とする広告スキームであるため、高速接続セットアップが必要な場合にのみ使用するべきです。

4.4.2.4.2 低デューティサイクル接続可能な指向型広告

低デューティサイクルの接続可能な有向広告では、広告イベント内で連続する2つのADV_DIRECT_IND PDUが開始するまでの時間は、10ms以下でなければならない。広告イベントは、広告間隔内に閉じなければならない。図 4.11 に、すべてのプライマリ広告物理チャネルインデックスを使用し、CONNECT_IND PDU を受信しない広告イベントの例を示す。図4.12は、ADV_DIRECT_IND広告PDUを使用した広告イベントを示しており、その間にCONNECT_IND PDUが第2の第1の広告チャネルインデックスで受信されます。

4.4.2.4.3 高デューティサイクルの接続可能な指示型広告

高デューティサイクルで接続可能なダイレクトアドバタイズメントモードでは、同一アドバタイズメントチャネルインデックス上に送信された 2 つの連続する ADV_DIRECT_IND PDU の開始までの時間は、3.75msec 以下とする。リンク層は、アドバタイズ状態に移行してから 1.28 秒以内にアドバタイズ状態を終了する。リンク層は、使用されているプライマリ広告チャネルインデックスのうち、最も使用されていないプライマリ広告チャネルインデックスから広告を開始し、他のプライマリ広告チャネルインデックスを順次通過させる。図 4.13 に、CONNECT_IND PDU を使用しない 2 つの Advertising イベントにおける 5 つの ADV_DIRECT_IND PDU のシーケンスを、すべてのプライマリ広告物理チャネルを使用した場合の例を示す。

4.4.2.4.4 ADV_EXT_INDを使用した接続可能な指向イベントタイプ

この手順は、LE 符号化された PHY で接続可能な誘導型イベントタイプを使用する場合に使用する。 ADV_EXT_IND を用いた connectable 有向イベントタイプは、イニシエータがリンク層接続を確立するために、セカンダリ広告物理チャネル上の接続要求で応答することを可能にする。 ADV_EXT_IND PDU において、AdvMode フィールドは connectable に設定され、ADI フィールドは存在しなければならず、PDU は AdvA 及び TargetA フィールドを含んではならない。 ADV_EXT_IND PDU の AuxPtr フィールドは、AdvMode フィールドが connectable に設定されている AUX_ADV_IND PDU を指すものとする。 ADV_EXT_IND PDU と AUX_ADV_IND PDU の ADI フィールドは同じでなければならない。広告主が送信するこのイベントに関連したAUX_ADV_IND PDUの後、広告主は、同じセカンダリ広告チャネルインデックス上のAUX_CONNECT_REQ PDUをリッスンしなければならない。受信したAUX_SCAN_REQ PDUはすべて無視される。広告主は、自分のデバイスアドレスを含むAUX_CONNECT_REQ PDUを受信し、イニシエータのデバイスアドレスがAUX_ADV_IND PDUに含まれていた場合、同じセカンダリ広告チャネルインデックス上でそれらのアドレスを含むAUX_CONNECT_RSP PDUで応答する。 AUX_CONNECT_RSP PDU が送信された後、リンク層はアドバタイズメント状態を終了し、4.5.5 節で定義されたスレーブ役割のコネクション状態に遷移する。セカンダリ広告物理チャネルで受信したAUX_SCAN_REQ PDUはすべて無視されるものとする。広告イベント内の連続した2つの接続可能な指向型ADV_EXT_IND PDUの開始間の時間は、10ms以下でなければならない。広告イベントは、広告間隔内に閉じなければならない。セカンダリチャネルのチャネルインデックス SAdv_idx は、ADV_EXT_IND PDU の AuxPtr フィールドに含まれる。図 4.14 は、AUX_CONNECT_REQ PDU を受信しない広告イベントを示す。図4.15は、第2のセカンダリ広告チャネルインデックスでAUX_CONNECT_REQ PDUを受信している間の、接続可能な指向型ADV_EXT_IND広告PDUを使用した広告イベントを示しています。

4.4.2.5 スキャン可能な無指向イベントタイプ

走査可能無向広告イベントタイプが使用される場合、走査可能無向広告表示（ADV_SCAN_IND または走査可能無向広告 ADV_EXT_IND PDU）がリンク層から送信される。スキャン可能な無向広告イベントは、ADV_SCAN_INDまたはスキャン可能な無向広告ADV_EXT_IND PDUのいずれかを使用しなければならないが、両方を使用してはならない。リンク層のプライバシーが有効になっている場合は、セクション6.2.3の要件にも従わなければならない。

4.4.2.5.1 ADV_SCAN_INDを使用したスキャン可能な無指向イベントタイプ

スキャン可能な無指向イベントタイプは、スキャナが広告主に関する追加情報を要求するためのスキャン要求（SCAN_REQ PDU）で応答することを可能にする。リンク層は、スキャナからの要求に対して、同じプライマリ広告チャネルインデックスをリッスンする。受信したCONNECT_IND PDUは無視される。広告主は、広告フィルタポリシーによって許可されたスキャナから、そのデバイスアドレスを含むSCAN_REQ PDUを受信した場合、同じ広告チャネルインデックス上のSCAN_RSP PDUで応答しなければならない。 SCAN_RSP PDUが送信された後、または広告フィルタポリシーがSCAN_REQ PDUの処理を許可していない場合、広告主は、次に使用されるプライマリ広告チャネルインデックスに移動して別のADV_SCAN_IND PDUを送信するか、広告イベントを終了しなければならない。広告イベント内の連続する2つのADV_SCAN_IND PDUの開始間の時間は、10ms以下でなければならない。広告イベントは、広告間隔内に閉じなければならない。 SCAN_REQ PDU を受信しなかった場合の広告イベントの構造を、すべてのプライマリ広告物理チャネルを使用した場合の図 4.16 に示す。 SCAN_REQ PDU を受信し、SCAN_RSP PDU を送信した 2 つの広告イベントの例を、すべてのプライマリ広告物理チャネルを使用する場合の図 4.17 と図 4.18 に示す。

4.4.2.5.2 ADV_EXT_IND を使用したスキャン可能な無指向イベントタイプ

ADV_EXT_IND PDUを使用したスキャン可能な無指向イベントタイプは、任意のスキャナがスキャン要求で応答し、セカンダリ広告物理チャネル上でスキャン応答データを受信することを可能にする。 ADV_EXT_IND PDUにおいて、AdvModeフィールドはスキャン可能に設定され、ADIフィールドは存在しなければならず、PDUはAdvAフィールドを含んではならない。 ADV_EXT_IND PDU の AuxPtr フィールドは AdvMode フィールドが scannable に設定されている AUX_ADV_IND PDU を指すものとする。 ADV_EXT_IND PDU と AUX_ADV_IND PDU の ADI フィールドは同じでなければならない。スキャナは、ＡＵＸ＿ＳＣＡＮ＿ＲＥＱＰＤＵを用いて、ＡＵＸ＿ＥＸＴ＿ＩＮＤＰＤＵが指す受信したＡＵＸ＿ＡＤＶ＿ＩＮＤＰＤＵと同じセカンダリ広告チャネル・インデックス上でスキャン要求を送信してもよい。広告主が送信するAUX_ADV_IND PDUが送信されるたびに、広告主は、スキャナからの同じセカンダリ広告チャネルインデックス上のAUX_SCAN_REQ PDUをリッスンしなければならない。受信したAUX_CONNECT_REQ PDUはすべて無視されるものとする。広告主は、広告フィルタポリシーで許可されたスキャナから自分のデバイスアドレスを含むAUX_SCAN_REQ PDUを受信した場合、次の広告イベントの開始前に、同じセカンダリ広告物理チャネルインデックス上のAUX_SCAN_RSP PDUで応答しなければならない。 AUX_SCAN_RSP PDUが送信された後、または広告フィルタポリシーでAUX_SCAN_REQ PDUの処理が禁止されている場合、広告イベントは終了する。セカンダリ広告物理チャネル上のAUX_CONNECT_REQ PDUはすべて無視されるものとする。広告イベント内の連続する2つのADV_EXT_IND PDUの開始間の時間は、10ms以下でなければならない。広告イベントは、広告間隔内で閉じなければならない。図 4.19 に、AUX_SCAN_REQ PDU を受信しない広告イベントを示す。 AUX_SCAN_REQ PDU を受信し、セカンダリ広告物理チャネルで AUX_SCAN_RSP PDU を送信する広告イベントの例を図 4.20 に示す。

4.4.2.6 非接続型および非スキャン型の無指向イベント・タイプ

非接続不可・非スキャン不可無向広告イベントタイプを使用する場合は、リンク層から非接続不可・非スキャン不可無向広告インディケーション（ADV_NONCONN_IND PDU または非接続不可・非スキャン不可無向広告 ADV_EXT_IND PDU）が送信され、リンク層からは非接続不可・非スキャン不可無向広告インディケーション（ADV_NONCONN_IND PDU または非接続不可・非スキャン不可無向広告 ADV_EXT_IND PDU）が送信される。非接続不可・非スキャン不可の無向広告イベントは、ADV_NONCONN_INDまたは非接続不可・非スキャン不可の無向広告ADV_EXT_IND PDUのいずれかを使用しなければならないが、両方を使用してはならない。 ADV_NONCONN_IND PDU は、LE 符号化 PHY 上で使用してはならない。非接続型及び非スキャン可能な無向イベントタイプは、スキャナが広告主から情報を受信することを可能にする。この情報は、ADV_NONCONN_IND PDU または ADV_EXT_IND PDU の AuxPtr フィールドが指す AUX_ADV_IND PDU のいずれかに含まれる。広告主は、次に使用されるプライマリ広告チャネルインデックスに移動するか、または送信される各ADV_NONCONN_IND PDUまたはADV_EXT_IND PDUの後に広告イベントを閉じる。リンク層はリッスンを行わないため、スキャナやイニシエータからのリクエストを受信することができない。広告イベント内の連続した 2 つの ADV_NONCONN_IND または ADV_EXT_IND PDU の開始間の時間は、10ms 以下でなければならない。広告イベントは、広告間隔内に終了しなければならない。 ADV_EXT_IND PDU が使用された場合、ADVMode は非接続可能かつ非スキャン可能に設定されなければならない。 ADV_EXT_IND PDU が使用された場合、コントローラは補助パケットを使用することができる。広告にACADまたはAdvDataが含まれている場合は、補助パケットを使用しなければならない。 ADV_EXT_IND PDU が補助パケットなしで使用される場合、AuxPtr フィールドを含まず、AdvA フィールドを含まなければならない。 ADV_EXT_IND PDU が補助パケットと共に使用される場合、それは AuxPtr フィールドと ADI フィールドを含むものとする。 ADV_EXT_IND PDU またはそれが指す AUX_ADV_IND のいずれかが AdvA フィールドを含んでいてもよいが、両方ではない。 AUX_ADV_IND PDU において、ADVMode は非接続可能で非スキャン可能に設定され、ADI フィールドが存在しなければならない。 ADV_EXT_IND PDU と AUX_ADV_IND PDU の ADI フィールドは同じでなければならない。 LE コード化 PHY では、ADV_EXT_IND PDU は ADVA フィールドを含まない。注：コントローラは、どの PDU が ADVA フィールドを含むかを決定することができ、媒体の全体的な効率的な使用に基づいてこの選択を行うべきである。 TargetA フィールドは、どの PDU にも存在してはならない。図4.21は、すべての主要な広告物理チャネルが使用されている場合の、接続可能ではなく、スキャン不可能な無方向広告イベントの例を示しています。図4.22は、非接続型でスキャン不能な無方向広告ADV_EXT_IND PDUの例を示す。図4.23は、ホスト広告データがAUX_CHAIN_IND PDUを使用してフラグメント化されている場合の非接続可能で非スキャン可能な無向ADV_EXT_IND PDUの例を示しています。リンク層のプライバシーが有効になっている場合は、セクション6.2.3の要件にも従うこと。

4.4.2.7 接続可能な無指向イベントタイプ

ADV_EXT_IND PDU を使用した接続可能な無指向広告イベントタイプは、イニシエータがセカンダリ広告物理チャネル上のリンクレイヤ接続を確立するための接続要求で応答することを可能にする。 ADV_EXT_IND PDU において、AdvMode フィールドは接続可能に設定され、ADI フィールドは存在しなければならず、PDU は AdvA 及び TargetA フィールドを含んではならない。 AuxPtr フィールドは、AdvMode フィールドが connectable に設定され、AdvA と ADI フィールドが存在する AUX_ADV_IND PDU を指すものとする。 ADV_EXT_IND PDU と AUX_ADV_IND PDU の ADI フィールドは同じでなければならない。イニシエータは、AUX_ADV_IND PDUと同じセカンダリ広告物理チャネル上のAUX_CONNECT_REQ PDUを使用して接続要求を送信し、リンク層が接続状態に入るように要求することができる。広告主がこのイベントに関連してAUX_ADV_IND PDUを送信するたびに、広告主は、同じセカンダリ広告チャネルインデックス上のAUX_CONNECT_REQ PDUをリッスンしなければならない。受信したAUX_SCAN_REQ PDUはすべて無視されるものとする。広告主は、広告フィルタポリシーで許可されたイニシエータからデバイスアドレスを含むAUX_CONNECT_REQ PDUを受信した場合、同じセカンダリ広告チャネルインデックス上のAUX_CONNECT_RSP PDUで応答しなければならない。 AUX_CONNECT_RSP PDU が送信された後、リンク層はアドバタイズメント状態を終了し、4.5.5 節で定義されたスレーブロールのコネクション状態に遷移する。広告イベント内の連続する 2 つの ADV_EXT_IND PDU の開始間の時間は、10msec 以下とする。広告イベントは、広告間隔内で閉じなければならない。図 4.24 は、AUX_CONNECT_REQ PDU を受信しない場合の広告イベントを示す。図 4.25 は、AUX_CONNECT_REQ PDU を受信し、セカンダリ広告チャネルインデックスで AUX_CONNECT_RSP PDU が送信される広告イベントを示す。リンク層のプライバシーが有効になっている場合は、セクション6.2.4の要件にも従うこと。

4.4.2.8 走査可能な指示イベントタイプ

ADV_EXT_IND PDUを使用したスキャン可能な指示広告イベントタイプは、特定のスキャナが二次広告物理チャネル上でスキャン応答データを受信するためのスキャン要求で応答することを可能にする。 ADV_EXT_IND PDUにおいて、AdvModeフィールドはスキャン可能に設定されなければならず、ADIフィールドは存在しなければならず、PDUはAdvA及びTargetAフィールドを含んではならない。 ADV_EXT_IND PDU の AuxPtr フィールドは、AdvA、TargetA、ADI フィールドが全て存在する AUX_ADV_IND PDU を指すものとする。 ADV_EXT_IND PDU と AUX_ADV_IND PDU の ADI フィールドは同じでなければならない。 AUX_ADV_IND PDUが送信されるたびに、広告主は、ターゲット・スキャナからの同じセカンダリ広告チャネル・インデックス上のAUX_SCAN_REQ PDUをリッスンしなければならない。広告主は、自分のデバイスアドレスを含むAUX_SCAN_REQ PDUを受信し、スキャナのデバイスアドレスがAUX_ADV_IND PDUに含まれている場合、次の広告イベントの前に、同じセカンダリ広告チャネルインデックス上のAUX_SCAN_RSP PDUで応答するものとする。 AUX_SCAN_RSP PDUは、スキャン応答データを含むものとする。他のスキャナからのAUX_SCAN_REQ PDU、または受信したAUX_CONNECT_REQ PDUは無視されるものとする。広告イベント内の連続する2つのADV_EXT_IND PDUの開始間の時間は、10ms以下でなければならない。広告イベントは、広告間隔内で終了しなければならない。 AUX_SCAN_REQパケットがセカンダリ広告物理チャネルのAUX_SCAN_RSPパケットと組み合わせて使用される方法については、セクション4.4.2.5.2を参照のこと。リンク層のプライバシーが有効になっている場合は、セクション6.2.5の要件にも従わなければならない。

4.4.2.9 非接続型及び非スキャン型指向イベントタイプ

ADV_EXT_IND PDUを使用した非接続可能かつ非スキャン可能な指向型広告イベントタイプにより、広告主は、特定のスキャナを対象としたセカンダリ広告物理チャネル上に送信された広告データと一緒に、プライマリ広告物理チャネル上に非接続可能かつ非スキャン可能な指向型ADV_EXT_IND PDUを送信することが可能となる。 ADV_EXT_IND PDUのAdvModeフィールドは、非接続可能かつ非スキャン可能に設定する。コントローラは、広告にACADまたはAdvDataが含まれている場合、補助パケットを使用するものとする。それ以外の場合、コントローラは補助パケットを使用してもよい。補助パケットを使用しない場合、ADV_EXT_IND PDU は AuxPtr フィールドを含まず、AdvA と TargetA フィールドを含むものとする。補助パケットが使用される場合、ADV_EXT_IND PDU は AuxPtr フィールドと ADI フィールドを含まなければならない。 ADV_EXT_IND PDU 又はそれが指す AUX_ADV_IND PDU のいずれかが AdvA フィールドを含んでもよい(AdvA フィールドは完全に省略されてもよい。その場合、広告は匿名である)。 TargetAフィールドはどちらかのPDUに存在しなければならないが、両方に存在してはならない。 AUX_ADV_IND PDU では、AdvMode は非接続可能で非スキャン可能に設定され、ADI フィールドは存在しなければならない。 ADV_EXT_IND PDU と AUX_ADV_IND PDU の ADI フィールドは同じでなければならない。 LE 符号化 PHY では、ADV_EXT_IND PDU は ADVA 及び TargetA フィールドを含んではならない。注意：ホストは、どの PDU が ADVA または TargetA フィールドを含むかを指定することはできない。コントローラは、媒体の全体的な効率的な使用に基づいて、この選択を行うべきである。リンクレイヤはリッスンしないため、スキャナやイニシエータからのリクエストを受信することはできません。リンクレイヤのプライバシーが有効になっている場合は、セクション6.2.5の要件にも従わなければならない。

4.4.2.10 広告セット

広告主のホストは、リンク層に広告イベントをインターリーブするように指示することができる。広告データをまとめて広告セットと呼ぶ。リンクレイヤは複数の広告セットをサポートすることができ、各広告セットは広告PDUの種類、広告間隔、PHYなどの異なる広告パラメータを持つ。 ADV_EXT_IND、AUX_ADV_IND、AUX_SYNC_IND PDU で広告を行う場合は、ADI フィールドの Advertising SID サブフィールドで広告セットを識別する。リンク・レイヤは、ホストの指示に従い、Advertising SIDサブフィールドを設定しなければならない。スキャナは、Advertising SIDに基づいて広告をフィルタリングしてもよい。各広告セットの広告イベントは、広告状態の別個のインスタンスとみなされ、それぞれが独自の広告間隔を持つ（セクション4.4.2.2.1参照）。図4.26は、複数の広告セットを使用した広告の例を示しています。リセットされると、すべての広告セットは破棄されます。広告データを含む広告セットが作成された場合、コントローラは、そのセットが少なくとも31オクテットの広告データを含むことを保証しなければならない。この保証は、ホストが最初にそのセットの広告データを指定した後、または別の広告セットを作成した後には、もはや適用されないものとする。広告セットがスキャン可能な広告セットを作成した場合、コントローラは、そのセットが少なくとも31オクテットのスキャン応答データを含むことができることを保証しなければならない。この保証は、そのセットがスキャン不可能になった場合、またはホストが最初にそのセットのスキャン応答データを指定した後、または別の広告セットを作成した後には、もはや適用されない。

4.4.2.11 AdvDataInfo(ADI)の使用

ADVDataInfo（ADI）フィールドは、AUX_ADV_IND PDU または AUX_SCAN_RSP PDU のいずれかに含まれる広告セットと重複するアドバタイズメントを識別するために使用されます。 ADV_EXT_IND PDUを使用したスキャン可能な広告イベントの場合、AdvDataはAUX_ADV_IND PDUでは許可されていないので、ADIはAUX_SCAN_RSP PDUに含まれるAdvDataのみを参照します。与えられたアドバタイジングセットのアドバタイジングＤＩＤは、ランダムに選択された値で初期化されなければならない。ホストが与えられた広告セットについて新しい広告データ又はスキャン応答データを提供するたびに（それが以前のデータと同じであるかどうかは問わない）、広告ＤＩＤは更新されなければならない。新しい値は、以前に使用された値と同じではないランダムに選択された値でなければならない。備考：Advertising DIDフィールド値をランダムに選択することは、同じADIフィールド値を含む異なる広告主からのPDUの可能性を減少させる。注意：広告セットにSyncInfoフィールドが追加されたり、広告セットから削除されたりした場合、Advertising DIDを変更する必要はありません。しかし、それが変更されない場合、Advertising DIDキャッシュのエントリ（セクション4.3.3参照）は、SyncInfoフィールドを含む広告を無視することを意味するため、スキャナは定期的な広告に同期することに失敗する可能性があります。したがって、広告主は、定期的な広告トレインが有効になっているときにAdvertising DIDを更新する必要があります。あるいは、ホストは、広告を有効にする前に定期的な広告を有効にするべきである。

4.4.2.12 定期的な広告掲載

広告データを一定の間隔で定期的に送信する必要がある場合には、定期広告を利用します。定期広告とは、一定の間隔で広告データを随時変更しながら送信する広告のことです。このような一連の広告を構成するAUX_SYNC_IND PDUとAUX_CHAIN_IND PDUが周期的広告トレインを構成します。周期的広告が行われる場合、広告主はAUX_ADV_IND PDUsのSyncInfoフィールドに記述されている一定の間隔（周期的広告間隔-4.4.2.2.3項参照）でAUX_SYNC_IND PDUsを送信しなければならない。周期的広告を含む広告セットは、ＡＵＸ＿ＡＤＶ＿ＩＮＤＰＤＵのＳｙｎｃＩｎｆｏフィールドを含むＡＵＸ＿ＡＤＶ＿ＩＮＤＰＤＵを指すＡＵＸ＿ＥＸＴ＿ＩＮＤＰＤＵのＡＤＶＤａｔａＩｎｆｏフィールドによって識別される。 AUX_SYNC_IND PDU とそれを指す PDU は、常に同じ PHY で送信されるものとする。周期的広告列車のために使用されるPHY、アクセスアドレス、及びAUX_SYNC_IND PDUのCRCInit値は、その列車が有効化されている間、変更されてはならない。周期的広告列車を指し示す広告は、匿名であってはならない。定期広告列車が有効になるたびに、コントローラは、その列車の最初のAUX_SYNC_IND PDUを指すAUX_ADV_IND PDUを少なくとも1つ送信しなければならず、それ以降は、その列車を指す広告PDUを送信するか否かの要件はない。ホストは、定期的に広告データをリンク層に送信してもよい。この広告データは、リンクレイヤによって周期的なAUX_SYNC_IND PDUとその下位セットに配置される。リンクレイヤは、新しい広告データを受信するまで、ホストが最後に送信した広告データを繰り返す。 AUX_SYNC_IND PDUは、ホストがリンク層に周期的広告列車の終了を指示するまで継続して送出される。周期的広告列車のパケットには、コンスタントトーン拡張が含まれている場合があります。ホストは、定期的な広告列車が開始する前にこれを有効にしてもよいし、定期的な広告が進行している間にコンスタントトーン拡張を含めることを有効または無効にしてもよい。広告セットが最初に定期広告用に設定されたとき、コントローラは、その広告セットが少なくとも31オクテットの広告データを含むことができることを保証しなければならず、そうでなければ、その広告セットに定期広告を許可しないものとする。この保証は、ホストが最初にそのセットに定期的な広告データを指定した後、または別の広告セットを作成した後は、もはや適用されないものとする。図4.27に定期広告の例を示す。

4.4.3 スキャン状態

リンクレイヤは、ホストからの指示があった場合、スキャニング状態とする。スキャニングを行う場合、リンクレイヤはプライマリ広告物理チャネルをリッスンしなければならない。スキャニングには、パッシブとアクティブの 2 種類があり、ホストによって決定されます。スキャニングのタイミングや広告チャネルインデックスの選択に厳密なルールはありません。スキャン中、リンクレイヤは、スキャンウィンドウである scanWindow の間、プライマリ広告チャネルインデックスをリッスンします。スキャン間隔（scanInterval）は、2 つの連続したスキャンウィンドウの開始間の間隔として定義される。リンクレイヤは、スケジューリング上の競合がない限り、ホストからの指示に従い、scanInterval毎に完全なscanWindowをリッスンしなければならない。各スキャンウィンドウにおいて、リンク層は、異なるプライマリ広告チャネルインデックスでスキャンを行う。リンクレイヤは、全てのプライマリ広告物理チャネルインデックスを使用しなければならない。 scanWindow及びscanIntervalのパラメータは、40.96秒以下とする。ホスト側で scanWindow と scanInterval が同じ値に設定されている場合は、リンク層は継続してスキャンを行う。スキャナフィルタポリシーは、スキャン時に広告PDUまたはスキャン応答PDUを受信した場合に適用する。 AuxPtr フィールドが存在する PDU を受信する際に、スキャナはそれが指す補助 PDU もリッスンし（AuxPtr フィールドで指定された PHY をサポートしていることを条件に）、PDU の下位セット全体の受信を試みるべきである。その間、セクション 4.2.4 で指定されたウィンドウの拡大を行うべきである。スキャナがAuxPtrフィールドを含むADV_EXT_IND PDUを受信するとき、スキャナは常に補助パケットをリッスンするか、時にはリッスンをスキップするかのどちらかである。後者の場合には、以下の要件が適用されるものとする。受信した各Advertising SID値について

コントローラは、各広告デバイスが使用する1つ以上の最近のAdvertising DID値のキャッシュを保持し(この目的のため、すべての匿名広告は、すべての実デバイスとは異なる1つのデバイスからのものとして扱われる)、ADIフィールドを含むPDUを受信するたびにそれらを更新しなければならない。コントローラは、いつでもキャッシュエントリを削除してもよい。コントローラは、ADV_EXT_IND PDUの下位セット全体の受信に失敗した場合、ADV_EXT_IND PDUに関連するキャッシュエントリを削除すべきである。
コントローラは、キャッシュがデバイスによって使用されているADIフィールドのAdvertising DID値を指定するエントリを持っている場合にのみ、補助パケットのリスニングをスキップしてもよい；ADV_EXT_IND PDUがAdvAフィールドを含んでいる場合、そのエントリはそのデバイスのものでなければならない。そうでなければ、コントローラは、補助パケットのリスニングをスキップしてはならない。
キャッシュ内容にかかわらず、別の広告主が同じAdvertising DID値を使用し始めた場合や、既存の広告主が拡張ヘッダに大幅な変更を加えた場合（SyncInfoフィールドを含むなど）には、コントローラは時々AUX_ADV_IND PDUをリッスンすべきである。リンク層のプライバシーが有効になっている場合は、セクション6.3の要件にも従わなければならない。

4.4.3.1 パッシブスキャニング

パッシブスキャン時には、リンク層はパケットを受信するだけで、パケットを送信しない。

4.4.3.2 アクティブ・スキャニング

アクティブスキャニング状態では、リンクレイヤは広告PDUをリッスンし、広告PDUの種類に応じて、広告主に追加情報の送信を要求することができる。スキャニング状態に移行した後、リンクレイヤは、スキャナフィルタポリシーにより許可された広告主からスキャン可能なPDU（ADV_IND、ADV_SCAN_IND、またはスキャン可能なAUX_ADV_IND PDU）を受信した場合、スキャン要求PDUで応答した後、スキャン応答PDUをリッスンするものとする。それは、スキャン応答PDUを正常に受信するまで、同じ広告主に応答し続けるものとする。その後、同じ広告主からの後続のスキャン可能なPDUに応答してもよいし、無視してもよい。リンク層は、それらがレガシーPDUである場合、または、同じ広告主からの最後の広告で同じ広告SIDフィールドを持つ広告からAdvertising DIDフィールドが変更されていない場合には、それらを無視しなければならず、それ以外の場合にはそれらを無視してはならない。リンク層は、ADV_IND PDU または ADV_SCAN_IND PDU を受信した広告主に対してのみ SCAN_REQ PDU を送信する。リンク層は、スキャン可能なAUX_ADV_INDを受信した広告主に対してのみ、AUX_SCAN_REQ PDUを送信する。リンク・レイヤは、TargetAフィールドが存在し、リンク・レイヤのデバイス・アドレスと一致しない場合、スキャン可能なAUX_ADV_IND PDUを無視する。スキャナは、複数のスキャナからのスキャン要求ＰＤＵの衝突を最小化するために、バックオフ手順を実行しなければならない。そのような手順の例を次の段落に示す。バックオフ手順は、backoffCountとupperLimitの2つのパラメータを使用して、スキャン応答PDU上で衝突が発生した場合に送信されるスキャン要求PDUの数を制限する。スキャニング状態に入ると、upperLimitとbackoffCountは１に設定される。スキャナフィルタポリシーによって許可され、スキャン要求ＰＤＵが送信されるべき、受信されたＡＤＶ＿ＩＮＤ、ＡＤＶ＿ＳＣＡＮ＿ＩＮＤ、またはスキャン可能なＡＵＸ＿ＡＤＶ＿ＩＮＤＰＤＵ毎に、バックオフカウントは、ゼロの値になるまで１ずつ減少する。スキャン要求ＰＤＵは、backoffCountがゼロになったときにのみ送信される。スキャン要求 PDU を送信した後、リンク層はその広告主からのスキャン応答 PDU をリッスンする。その広告主からのスキャン応答 PDU を受信しなかった場合は失敗とみなし、それ以外の場合は成功とみなす。 2回連続して失敗するごとに、上限値は256に達するまで2倍になる。 2回連続して成功するごとに、上限値は1になるまで半分になります。リンク層は、スキャン応答 PDU の受信に成功または失敗した後、backoffCount に 1 から upperLimit を含む疑似乱数を設定する。デバイスが異なるバックオフアルゴリズムを使用している場合、デバイスは責任を持って媒体を共有しなければならない。 SCAN_REQ PDU を受信し、SCAN_RSP PDU を送信する間の全ての広告物理チャネルインデックスを用いた広告イベントの図を図 4.8 及び図 4.9 に示す。

4.4.3.3 広告セット

ADV_EXT_IND PDUは、ADIフィールドを含んでもよい。 ADIフィールドが存在する場合、それは、同じセットに属するアドバタイジングデータを識別するために使用することができる。これは、ADIのAdvertising SIDサブフィールドで指定される。 Advertising SIDは、広告主のHostによって設定されます。

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

ホストから指示があった場合、スキャナはAUX_ADV_IND PDUのSyncInfoフィールドにある定期的な広告同期情報を探さなければならない。 SyncInfo の Sync Packet Offset がゼロの場合、定期的な広告同期情報は不完全であり、スキャナは完全な情報を得るために後続の広告をリッスンしなければならない。完全な情報を受信した場合、スキャナは直ちに同期状態に移行する新しいステートマシンを開始しなければならず、既存のステートマシンはスキャニング状態のままである。ホストは、コントローラに対して、特定のタイプのコンスタントトーン拡張機能を持つ、またはコンスタントトーン拡張機能を持たない定期的な広告列車に同期しないように指示することができる。コントローラが同期中にそのような一定トーン拡張を持つAUX_SYNC_INDを受信した場合、その同期化の試みは失敗し、停止するものとする。一旦同期化された後は、一定トーン拡張機能の有無やタイプが同期化に影響を与えることはありません。

4.4.3.5 広告レポート

リンク層は、プライマリ広告チャネル上の各広告 PDU 及び広告主からの各スキャン応答 PDU について、本節に別段の記載がある場合を除き、広告レポートをホストに送信する。コントローラがAUXPtrフィールドを持つADV_EXT_IND PDUを受信した場合、コントローラは、対応するAUX_ADV_IND PDUを受信するまでレポートを遅延させ、レポートはPDU内の情報を結合するものとする。広告レポートには、少なくとも広告主のデバイスアドレスと広告データまたはスキャン応答データ（下位のAUX_CHAIN_IND PDUに含まれるデータを含む）が含まれていなければならない。注：コントローラは、データの合計が単一のイベントに収まらない場合など、複数のHCIイベントを使用してレポートを送信することができる。ホストは、重複する広告レポートをフィルタリングして送信しないように要求することができます。受信したADV_EXT_IND PDUがADIフィールドを含む場合、重複広告レポートとは、同じAdvertising SIDを持つADI値を含む前のレポートが同じAdvertising DIDを持つ、同じデバイスアドレスの広告レポートのことである。この目的のために、すべての匿名広告は、すべての非匿名デバイスとは異なる単一デバイスからのものとして扱われる。 ADV_EXT_IND PDUがADIフィールドを含まない場合、またはレガシーPDUが受信された場合、重複広告レポートは、リンク層がスキャニング状態のままである間、同じデバイスアドレスに対する広告レポートである。いずれの場合も、実際のデータは変更される可能性があり、広告データまたはスキャン応答データは、重複広告レポートを決定する際に重要であるとは考えられない。

4.4.4 開始状態

リンクレイヤは、ホストからの指示があった場合には、イニシエート状態とする。イニシエート時には、リンクレイヤはプライマリ広告物理チャネルをリッスンする。

イニシエータのタイミングや広告チャネルインデックスの選択に厳密なルールはありません。

イニシエート中、リンクレイヤは、スキャンウィンドウである scanWindow の間、プライマリ広告チャネルインデックスをリッスンする。スキャン間隔（scanInterval）は、2 つの連続したスキャンウィンドウの開始間の間隔として定義される。

リンクレイヤは、スケジューリング上の競合がない限り、ホストからの指示に従い、scanInterval毎に完全なscanWindowをリッスンしなければならない。リンク層は、各スキャンウィンドウにおいて、異なるプライマリ広告チャネルのインデックスをリッスンする。リンクレイヤは、全てのプライマリ広告チャネルインデックスを使用する。

scanWindow及びscanIntervalのパラメータは、40.96秒以下とする。ホスト側で scanWindow と scanInterval が同じ値に設定されている場合は、リンクレイヤは継続してリッスンする。

接続可能な広告に応答する接続指示又は要求は、どちらの広告PDUにAdvAフィールドが含まれているかに応じて、プライマリ広告又はセカンダリ広告の物理チャネルのいずれかで送信されなければならない。以下のサブセクションでは、2つの手順について説明する。

リンク層のプライバシーが有効になっている場合は、第6.4節の要件にも従わなければならない。

4.4.4.1 プライマリ広告物理チャネル上の接続要求

この手順は、LE 符号化 PHY 上で接続を確立する場合には使用しないものとする。

イニシエータのフィルタポリシーによって許可されるADV_IND PDUを受信した場合、イニシエータは、広告主にCONNECT_IND PDUを送信しなければならない。イニシエータのリンクレイヤデバイスアドレスを含み、イニシエータのフィルタポリシーで許可されたADV_DIRECT_IND PDUを受信した場合、イニシエータはCONNECT_IND PDUを広告主に送信しなければならず、それ以外の場合は無視される。

CONNECT_IND PDU を送信した後、リンク層はイニシエータ状態を終了し、4.5.4 節で定義されたマスターロールの接続状態に遷移する。

4.4.4.2 セカンダリ広告物理チャネル上の接続要求

この手順は、LE 符号化 PHY 上で接続を確立する際に使用する。

接続可能なADV_EXT_IND PDUを受信した場合、イニシエータは、セカンダリ広告物理チャネル上の接続可能なAUX_ADV_INDをリッスンしなければならない。接続可能な無指向AUX_ADV_IND PDU、またはイニシエータのリンク層デバイスアドレスを含む接続可能な無指向AUX_ADV_IND PDUを受信し、イニシエータのフィルタポリシーによって許可されている場合、イニシエータはAUX_CONNECT_REQ PDUを広告主に送信しなければならず、そうでない場合は無視されるものとする。

イニシエータは、AUX_CONNECT_REQ PDUを送信した後、広告主がAUX_CONNECT_RSP PDUを送信するのを待たなければならない。

AUX_CONNECT_RSP PDUを受信すると、リンク層はイニシエータ状態を終了し、4.5.4節で定義されたマスターロールのコネクション状態に遷移する。イニシエータは、広告主からAUX_CONNECT_RSP PDUを受信しない場合、次の接続可能なAUX_ADV_IND PDUに応答する前に、4.4.3.2節のSCAN_REQについて記述したバックオフアルゴリズムを使用しなければならない。

4.4.5 同期状態

リンク層は、ホストからの指示があり、定期的な広告同期情報を取得した場合、同期状態に入る。この情報は、AUX_ADV_IND PDU の SyncInfo フィールド（4.4.3.4 節参照）や、接続された機器から送信された LL_PERIODIC_SYNC_IND PDU から取得することができる。

この状態では、リンク層は 4.4.2.1 節で規定されたセカンダリ広告チャネルのインディクスで、同期情報で指定された周期的広告列車を形成する AUX_SYNC_IND PDU をリッスンする。コントローラは、これらのAUX_SYNC_IND PDUのいずれかを最初に正常に受信すると、ホストに通知し、その後、周期的広告列車に同期していると言われ、それまでは同期していると言われる。コントローラは、これらのAUX_SYNC_IND PDUのいずれかを、最初にリスンした周期的広告イベントから始まる6つの周期的広告イベント内に受信しなかった場合、ホストに通知し、スタンバイ状態に遷移するものとする。

デバイスは、既に同期している広告列車と同じアドレス、アドレスタイプ、広告SIDを持つ定期広告列車に同期しようとしてはならない。

リンク層は、ホストから要求があった場合、定期広告で受信した広告データをホストに報告する。ホストは、全ての広告データを報告しないことを指定することができる。リンク層は、広告主のクロックとの同期を維持するために必要な場合や、チャンネルマップの更新を受信するために必要な場合を除き、コンスタントトーン拡張からのデータやサンプルをホストに報告しないAUX_SYNC_IND PDUを聞く必要はない。

リンク層は、4.2.4 節で指定されたウィンドウ拡大を実行しなければならない。同期中にウィンドウ拡大が((periodicInterval/2) - T_IFS μs)に達した場合、コントローラはホストに通知し、スタンバイ状態に移行する。

4.5 接続状態

イニシエータがプライマリ広告物理チャネルのCONNECT_IND PDUを広告主に送信し、広告主がイニシエータからプライマリ広告物理チャネルのCONNECT_IND PDUを受信し、広告主がイニシエータにセカンダリ広告物理チャネルのAUX_CONNECT_RSP PDUを送信し、イニシエータが広告主からセカンダリ広告物理チャネルのAUX_CONNECT_RSP PDUを受信すると、リンク層はコネクション状態になります。

コネクション・ステートに入ると、接続が作成されたとみなされます。この時点では、接続は確立されたとはみなされません。接続が確立されたとみなされるのは、データ物理チャネルパケットがピアデバイスから受信されてからです。作成された接続と確立された接続の唯一の違いは、使用されるリンク・レイヤーの接続監視タイムアウト値です（セクション4.5.2参照）。

プライマリ広告物理チャネル上でCONNECT_IND PDUを使用して接続が最初に作成された場合は、双方向でLE 1M PHYを使用する。接続がセカンダリチャネルでＡＵＸ＿ＣＯＮＮＮＥＣＴ＿ＲＥＱ及びＡＵＸ＿ＣＯＮＮＮＥＣＴ＿ＲＳＰＰＤＵを使用して最初に作成された場合は、両方向でＡＵＸ＿ＣＯＮＮＥＣＴ＿ＲＥＱ及びＡＵＸ＿ＣＯＮＮＥＣＴ＿ＲＳＰＰＤＵに使用されたものと同じＰＨＹを使用するものとする。いずれかの PHY は、PHY 更新手順（セクション 5.1.10）を使用して、その後変更することができる。 LE 符号化 PHY が使用されている場合、各パケットの符号化は、セクション 2.2.3 で定義されている CI によって決定され、各方向と特定の方向の隣接パケットで異なる場合があります。

つのデバイスが接続中の場合、２つのデバイスは異なる役割で動作する。マスタ役割のリンクレイヤはマスタと呼ばれる。スレーブ役割のリンク層はスレーブと呼ばれます。マスタは、接続イベントのタイミングを制御します。接続イベントとは、マスタとスレーブの間の同期点である。 2 つの LE デバイス・アドレス間には、確立されているか否かに関わらず、1 つの接続しか存在しないものとする。イニシエータは、既に接続している広告主に接続要求を送信してはならない。

広告主は、既に接続しているイニシエータから接続要求を受信した場合、その要求を無視しなければならない。

イニシエータがADV_INDまたはADV_DIRECT_IND PDUに応答してCONNECT_IND PDUを送信し、どちらかまたは両方のデバイスのPDUがChSelフィールドを0に設定していた場合、チャネル選択アルゴリズム#1(項4.5.8.2参照)を接続に使用しなければならない。そうでない場合は、チャネル選択アルゴリズム#2(セクション4.5.8.3参照)が使用されるものとする。

4.5.1 接続イベント

接続状態のリンク層は、接続イベントにおいてのみ、データ物理チャネルPDU（2.4項参照）を送信するものとする。マスタ及びスレーブは、セクション4.5.8で定義されているように、各接続イベントのデータチャネルインデックスを決定しなければならない。同じデータチャネルインデックスは、接続イベント内のすべてのパケットに使用されなければならない。各接続イベントは、通常、マスタによって送信された少なくとも1つのパケットを含む。ただし、マスタは、スケジューリングの競合により接続イベントでの送信に完全に失敗することがあるが、各接続監視タイムアウト期間内に少なくとも1つのデータチャネルPDUを送信しなければならない（4.5.2項参照）。

接続イベントの間、マスタとスレーブはパケットの送受信を交互に行う。接続イベントは、両デバイスがパケットを送信し続けている間はオープンとみなす。スレーブは、セクション4.5.6で規定されているように無効なCRCが複数連続して一致した後を除き、有効なCRC一致に関わらずマスタからパケットを受信した場合には、常にパケットを送信するものとする。マスタは、セクション4.5.6で規定されているように、無効なCRCの複数の連続したマッチの後を除き、有効なCRCマッチに関係なくスレーブからパケットを受信した場合には、パケットを送信することができる。受信したパケットの終了を決定する際、ヘッダのLengthとCPフィールド、およびCTEInfoフィールドのCTETimeフィールド（存在する場合）は、CRCマッチが無効であっても正しいと仮定されますが、受信デバイスが他の方法で正しいLengthとCTETimeを決定できる場合、ヘッダの値の代わりにそれらの値を使用することができます。

接続イベントは、セクション4.5.6で定義されているように、どちらのデバイスによっても閉じることができる。

接続イベントのタイミングは、接続間隔(connInterval)とスレーブのレイテンシ(connSlaveLatency)の2つのパラメータによって決定されます。

接続イベントの開始点をアンカーポイントと呼ぶ。アンカーポイントでは、マスターは通常、スレーブへのデータ物理チャネルPDUの送信を開始しなければならない。接続イベントの開始は、connIntervalの間隔で規則的に間隔をあけて行われ、重なってはならない。マスタは、次の接続イベントのアンカーポイントの前に少なくともT_IFSで接続イベントが閉じるようにしなければならない。スレーブは、アンカーポイントでマスタが送信したパケットをリッスンする。

connIntervalは、イニシエータのリンク層がCONNECT_INDまたはAUX_CONNECT_REQ PDUでホストから与えられた範囲から設定し、Connection Updateプロシージャ（5.1.1項参照）またはConnection Parameters Requestプロシージャ（5.1.7項参照）を使用して変更することができます。

スレーブのレイテンシは、スレーブが接続イベントの数を減らして使用することを可能にします。 connSlaveLatencyパラメータは、スレーブデバイスがマスタをリッスンする必要のない連続した接続イベントの数を定義します。 connSlaveLatencyの値は、Supervision Timeout（セクション4.5.2参照）を発生させてはならない。 connSlaveLatencyは、0から((connSupervisionTimeout / (connInterval*2)) - 1)の範囲の整数でなければならない。また、connSlaveLatency パラメータは 500 以下とする。 connSlaveLatencyが0に設定されている場合、スレーブデバイスはすべてのアンカーポイントでリッスンする。スレーブレイテンシを適用してもマスタからのパケットを受信しない場合は、各アンカーポイントでリッスンし、マスタからのパケットを受信するまでスレーブレイテンシを適用しないこと。 connSlaveLatencyの値やスケジューリングの競合にかかわらず、スレーブは、各接続監視タイムアウト期間内に少なくとも1回はマスタをリッスンすること（4.5.2項参照）。

マスタ及びスレーブは、リンク層接続ごとに、connEventCount を含む 16 ビットの接続イベントカウンタ（connEventCounter）を持つこと。このカウンタは、最初の接続イベントでゼロに設定されなければならない。 connEventCounter は、0xFFFF～0x0000 の範囲で折り返して使用する。このカウンタは、リンク層の制御手順を同期させるために使用される。

両方のデバイスは、それらのイベントにおいてスレーブの遅延のためにスレーブがマスタをリッスンしていない場合や、イベント中にマスタが送信に失敗した場合でも、すべての接続イベントについて connEventCounter をインクリメントしなければならない。

4.5.2 スーパービジョンタイムアウト

デバイスが圏外に移動したり、激しい干渉を受けたり、停電状態になったりと、様々な理由で接続が切れてしまうことがあります。このような場合には、事前の予告なしに発生する可能性があるため、マスタ、スレーブ双方で接続状態を監視することが重要となります。

マスタ及びスレーブは、リンクロスを検知するために、リンクレイヤ接続監視タイマ TLLconnSupervision を使用します。有効なパケットを受信した場合は、タイマをリセットする。

接続が確立される前にリンク層接続監視タイマが 6 * connInterval に達した場合（4.5 節参照）、接続は失われたものとみなす。これにより、確立に失敗した接続を迅速に終了させることができる。

接続監視タイムアウト（connSupervisionTimeout）は、接続が失われたとみなされるまでの2つの受信データチャネルPDU間の最大時間を定義するパラメータである。 connSupervisionTimeoutは、100msから32.0秒の範囲で10msの倍数であり、(1 + connSlaveLatency) * connInterval * 2より大きくなければならない。

接続が確立された後の接続状態において、タイマーが connSupervisionTimeout の値に達した場合は、接続が失われたものとみなす。

接続が失われたと判断された場合、リンク層はそれ以上のパケットを送信しない。リンク層は接続状態を終了し、スタンバイ状態に移行する。ホストに接続切れの通知を行う。コントローラは、直近の接続イベントが終了し、次のアンカーポイントまでにタイマが connSupervisionTimeout 値に達することを条件に、より早く通知を送信することができる。

各接続監視タイムアウト期間は、有効なパケットを受信した後の接続イベントから始まり、タイマーが connSupervisionTimeout 値に到達する前の最後の接続イベントで終了します。

4.5.3 接続イベント送信ウィンドウ

マスタが複数の接続や他のアクティビティに効率的に接続イベントをスケジュールできるようにするために、マスタは、最初の接続イベントのアンカーポイントを選択した時間にスケジュールする柔軟性を持っています。 CONNECT_INDおよびAUX_CONNECT_REQ PDUには、マスターがアンカーポイントを設定するためのコネクションステートで最初のパケットを送信できるタイミングと、スレーブがリッスンしなければならないタイミングを決定するためのパラメータが含まれています。

CONNECT_INDおよびAUX_CONNECT_REQ PDUは、送信ウィンドウを決定するために使用される3つのパラメータを含む。送信ウィンドウは、CONNECT_IND PDUまたはAUX_CONNECT_REQ PDUを含むパケットの終了後、transmitWindowDelay + transmitWindowOffsetで開始し、transmitWindowSizeパラメータは送信ウィンドウのサイズを定義する。 connInterval は、送信ウィンドウの最大オフセットとサイズの計算に使用する。 transmitWindowOffset 及び transmitWindowSize パラメータは、リンク層で決定する。

送信ウィンドウオフセットは、0ms から connInterval までの範囲で 1.25ms の倍数とする。また、transmitWindowSize は、1.25ms 以上 10ms 以下の範囲で 1.25ms の倍数とし、（connInterval - 1.25ms）とする。

したがって、最初のパケットの開始は、CONNECT_IND PDU または AUX_CONNECT_REQ PDU を含むパケットの終了後、transmitWindowDelay + transmitWindowOffset よりも早く、かつ、transmitWindowDelay + transmitWindowOffset + transmitWindowSize よりも遅くならない。

また、CONNECT_IND PDU を使用する場合は 1.25ms、LE アンコード PHY で AUX_CONNECT_REQ PDU を使用する場合は 2.5ms、LE 符号化 PHY で AUX_CONNECT_REQ PDU を使用する場合は 3.75ms とする。

4.5.4 接続のセットアップ - マスター・ロール

イニシエータがプライマリ広告物理チャネルでCONNECT_IND PDUを送信するか，セカンダリ広告物理チャネルでAUX_CONNECT_RSP PDUを受信した後，リンクレイヤはマスターロールでコネクション状態となる。マスタは、リンクレイヤ接続監視タイマTLLconnSupervisionをリセットする。リンク層は、接続が作成されたことをホストに通知する。最初の接続イベントは、4.5.8 節のデータチャネルインデックスを使用する。

マスタは、4.5.3 節で規定された送信ウィンドウ内で最初のパケットの送信を開始する。マスタの最初のパケットは、送信ウィンドウを超えて送信することが許される。

マスタが接続状態で送信した最初のパケットは、最初の接続イベントのアンカーポイントを決定し、したがって、この接続における将来のすべての接続イベントのタイミングを決定する。

第２の接続イベントのアンカーポイントは、第１の接続イベントのアンカーポイントの後のconnIntervalでなければならない。 4.5.1 節で規定されたすべての通常の接続イベント送信ルールが適用される。

マスタ側から見た LL 接続設定手順のタイミングの例を図 4.28 および図 4.29 に示す。

-- Figure 4.28: Master’s view of LL connection setup with CONNECT_IND -- -- Figure 4.29: Master’s view of LL connection setup with AUX_CONNECT_REQ --

4.5.5 接続のセットアップ - スレーブの役割

広告主がプライマリ広告物理チャネルでCONNECT_IND PDUを受信した後、またはセカンダリ広告物理チャネルでAUX_CONNECT_RSP PDUを送信した後、リンクレイヤはスレーブロールでコネクション状態となる。スレーブは、リンクレイヤ接続監視タイマ TLLconnSupervision をリセットする。リンク層は、接続が作成されたことをホストに通知する。最初の接続イベントは、4.5.8 節のデータチャネルインデックスを使用する。

スレーブは、4.5.3 節で規定された送信ウィンドウ内の最初のパケットのリッスンを開始し、その間、4.2.4 節で規定されたウィンドウ拡大を行う。その間、4.2.4 節で規定されたウィンドウ拡大を行う。

スレーブがコネクションステートで受信した最初のパケットは、有効なCRCの一致（すなわち、アクセスコードの一致のみ）に関係なく、最初のコネクションイベントのアンカーポイントを決定し、したがって、このコネクション内のすべての将来のコネクションイベントのタイミングを決定します。

送信ウィンドウでパケットが受信されない場合、スレーブは後続の送信ウィンドウでパケットの受信を試みるものとする。後続の送信ウィンドウは、前の送信ウィンドウの開始後、同じ送信ウィンドウサイズで connInterval を開始するものとする。データチャネルインデックスは、4.5.8 節に規定する次のデータチャネルインデックスとする。また、connEventCount を 1 つインクリメントする。

スレーブ側から見た手順の例を図 4.30 及び図 4.31 に示す。この例では、スレーブはマスタからの第 1 パケット（すなわち、connEventCount = 0）の受信に失敗し、第 2 パケット（すなわち、connEventCount = 1）からアンカーポイントのタイミングを取得する。

-- Figure 4.30: Slave closing LL connection setup in the second LL connection event with CONNECT_IND -- -- Figure 4.31: Slave closing LL connection setup in the second LL connection event with AUX_CONNECT_REQ --

スレーブはマスターからNESNが1に設定されたパケットを受信するまでは、すべての接続イベントでアクティブであるものとする。それ以降は、セクション4.5.1で定義されているようにスレーブのレイテンシを使用することができる。

4.5.6 接続イベントの終了

データ物理チャネルPDUのヘッダのMDビットは、デバイスが送信するデータの数が多いことを示すために使用されます。どちらのデバイスもパケットにMDビットを設定していない場合、スレーブからのパケットは接続イベントを閉じます。どちらかまたは両方のデバイスがMDビットを設定している場合、マスタは別のパケットを送信することで接続イベントを継続することができ、スレーブはそのパケットを送信した後にリッスンする必要があります。

パケットの受信に失敗した場合、または接続イベント内で無効なCRC一致のパケットを2つ連続して受信した場合は、イベントを終了するものとする。

MDビットの使用法を表4.3にまとめました。

-- Table 4.3: MD bit usage for closing connection events --

4.5.7 睡眠クロックの精度

スリープクロック精度（4.2.2 節参照）のため、スレーブにはマスタのアンカーポイントの正確なタイミングの不確実性がある。このため、スレーブは、マスタをリッスンする接続イベントごとにマスタのアンカーポイントに再同期する。スレーブがアンカーポイントでマスタからパケットを受信した場合、ＣＲＣの一致に関わらず、スレーブはアンカーポイントのタイミングを更新しなければならない。

スレーブは、各アンカーポイントで、接続更新手順（5.1.1項参照）及び接続パラメータ要求手順（5.1.7項参照）の間に、4.2.4項に記載されているウィンドウの拡大を実行すること。その際、マスタのクロックに関するより正確な情報がない場合、スレーブは、接続上の最新のCONNECT_IND、AUX_CONNECT_REQ、LL_CLOCK_ACCURACY_REQ、またはLL_CLOCK_ACCURACY_RSP PDUからのマスタのスリープクロック精度(masterSCA)を使用しなければならない。

ウインドウ幅は、((connInterval/2) - T_IFS μs)より小さくなければならない。 windowWidening の大きさが ((connInterval/2) - T_IFS μs) に達した場合、接続は失われたものとみなす。

4.5.8 データと周期的な物理チャネルインデックスの選択

4.5.8.1 チャネルの分類

マスタのリンク層は、データチャネルを、使用済みチャネル（接続に使用される）と未使用チャネル（接続に使用されない）に分類する。これをチャネルマップと呼ぶ。使用済みチャネルの最小数は2とする。

ホストは、リンクレイヤにチャネル分類情報を提供することができる。リンク層は、ホストから提供された情報を使用することができる。スレーブは、マスタからのチャネルマップを CONNECT_IND PDU または AUX_CONNECT_REQ PDU で受信する。マスタがチャネルマップを変更した場合は、5.1.2 節の通りスレーブに通知する。

4.5.8.2 チャンネル選択アルゴリズム #1

チャネル選択アルゴリズム #1 は、接続イベントのチャネル選択のみをサポートします。

チャンネル選択アルゴリズム #1 は、2 つの段階で構成されています：アンマップされていないチャンネルインデックスの計算と、このインデックスを使用されているチャンネルのセットからデータの物理チャンネルインデックスにマッピングすることです。

unmappedChannelおよびlastUnmappedChannelは、2つの連続した接続イベントのアンマップされていないチャネルインデックスである。 unmappedChannel は、現在の接続イベントのマッピングされていないチャネル・インデックスです。 lastUnmappedChannelは、前の接続イベントのアンマップされていないチャネルインデックスである。 lastUnmappedChannel は、最初の接続イベントでは 0 とする。

イベントである。

接続イベントの開始時に、以下の基本アルゴリズムを用いて unmappedChannel を計算する。

unmappedChannel = (lastUnmappedChannel + hopIncrement) mod 37 接続イベントが終了すると、lastUnmappedChannelはの値を使用する。

unmappedChannelがチャネルマップに従って使用済みチャネルである場合、チャネル選択アルゴリズム#1は、接続イベントのためのデータ物理チャネルインデックスとしてunmappedChannelを使用するものとする。

unmappedChannelがチャネルマップに従って未使用チャネルである場合、以下のアルゴリズムを用いて、unmappedChannelをチャネルマップ内の使用チャネルの１つに再マッピングするものとする。

remappingIndex = unmappedChannel mod numUsedChannels ここで numUsedChannels は、チャンネルマップで使用されているチャンネルの数です。

すべての使用済みチャネルを昇順に格納したリマッピングテーブルが作成され、インデックスはゼロから始まります。次に、remappingIndex を使用して、リマッピングテーブルから接続イベントのデータ物理チャネルインデックスを選択します。

完全な手順を図 4.32 に示します。

-- Figure 4.32: Block diagram of Channel Selection algorithm #1 --

4.5.8.3 チャンネル選択アルゴリズム #2

4.5.8.3.1 概要

チャネル選択アルゴリズム＃２は、接続イベントおよび周期的広告イベントのためのチャネル選択をサポートする。

接続イベントまたは定期的な広告パケットであり得るイベントの開始時に、ここで説明するアルゴリズムは、イベントチャネルインデックスを生成します（これは、適切な場合には、データまたは定期的な物理チャネルインデックスです）。

アルゴリズム全体のブロック図を図4.33に示す。

-- Figure 4.33: General block diagram of Channel Selection algorithm #2 --

4.5.8.3.2 入力と基本コンポーネント

このアルゴリズムは、以下の入力と基本的な構成要素を利用している。

6 ビットの入力 N は、使用チャネルとして分類されるチャネルの数である。
16ビット入力のchannelIdentifierは、任意の接続または定期的な広告列車に対して固定されており、アクセスアドレスから次のように計算される。

channelIdentifier = (Access Address31-16) XOR (Access Address15-0)

16 ビットの入力カウンタは、イベントごとに変化します。データ接続の場合は、4.5.1 節に定義された接続イベントカウンタ connEventCounter となります。定期的な広告の場合は、セクション4.4.2.1に定義されたイベントカウンタpaEventCounterである。

XOR」操作は、常に16ビットのビット単位のXORを参照する。

記号は、フロア関数（引数以下の最大の整数）を表すために使用される。

順列演算は、図 4.34 に示すように、下位 8 ビットの入力ビットと上位 8 ビットの入力ビットを別々にビット反転することで構成される。

-- Figure 4.34: Permutation operation --

図4.35に示すように、MAM(Multiply, Add, and Modulo) ブロックは、乗算演算、加算演算、およびモデューロ演算を実行します。

-- Figure 4.35: Multiply, Add, and Modulo block operation --

入力aとbが与えられたMAM演算の出力は、次のようになります。

output = (17 x a + b) mod 2^16

使用されているすべてのチャンネルを、0 からインデックスを付けて昇順に格納したリマッピングテーブルが作成されます。

4.5.8.3.3 アンマッピングされたイベントチャンネルの選択

アンマップされていないイベントチャネル選択処理は２段階で構成されています。まず、符号なし疑似乱数 prn_e を生成した後、prn_e からアンマップドチャネルインデックス unmappedChannel を導出する。

第 1 段階は図 4.36 に示す通りとする。

-- Figure 4.36: Event pseudo-random number generation --

次に、unmappedChannelはprn_e modulo 37として計算されます。全体の処理のブロック図を図4.37に示す。

-- Figure 4.37: Unmapped channel selection process --

4.5.8.3.4 使用チャネルインデックスへのイベントマッピング

unmappedChannel がチャネルマップに従った使用済みチャネルのチャネルインデックスであれば、それをイベントのチャネルインデックスとして使用する。 unmappedChannelがチャンネルマップに従った未使用チャンネルのチャンネルインデックスであれば、prn_eとN（使用チャンネル数）から、まず値remappingIndexを次のように計算してイベント用のチャンネルインデックスを算出します。

を使用して、リマッピングテーブルへのインデックスとして remappingIndex を使用して、イベントのチャンネルインデックスを取得します。全体的なプロセスを図4.38に示します。

-- Figure 4.38: Event mapping to used channel index process --

4.5.9 認識とフロー制御

すべてのリンクレイヤ接続において、リンクレイヤの確認応答及びフロー制御方式を使用する。リンク層は、各接続に対して、transmitSeqNum と nextExpectedSeqNum の 2 つのパラメータを持ち、それぞれ 1 ビットのサイズを持つ。transmitSeqNum は、リンク層から送信されたパケットを識別するためのパラメータである。nextExpectedSeqNum パラメータは、リンク層が送信した最後のデータ物理チャネル PDU を確認するか、または送信した最後のデータ物理チャネル PDU の再送を要求するために使用する。 transmitSeqNumパラメータ及びnextExpectedSeqNumパラメータは、接続状態に入った時点でゼロに設定する。最後のデータ物理チャネル PDU が LE 符号化 PHY 上で送信された場合、再送信時に使用される符号化方式(セクション 2.2.3 参照)は、最後のデータ物理チャネル PDU で使用されたものと同じであっても異なっていてもよい。データ物理チャネル PDU が再送されるのを待っている間に PHY 更新手順(セクション 5.1.10 参照)が発生した場合、再送時には新しい PHY が使用されなければならない。新しいデータ物理チャネル PDU は、リンク層が初めて送信するデータ物理チャネル PDU である。最後のデータ物理チャネル PDU は、リンク層が再送するデータ物理チャネル PDU である。データ物理チャネル PDU を再送する場合、LLID、SN、CP フィールド、CTEInfo フィールド（存在する場合）、及び送信されたデータ物理チャネル PDU のペイロードは、リンク層が最後に送信したデータ物理チャネル PDU のペイロードと同じでなければならない。データ物理チャネル PDU が再送された場合、SN ビットは変更されない。データ物理チャネルPDUを受信すると、SNビットはnextExpectedSeqNumと比較され、ビットが異なる場合は、これは再送されたデータ物理チャネルPDUであり、nextExpectedSeqNumは変更されてはならない。ビットが同じならば、これは新しいデータ物理チャネルPDUであり、nextExpectedSeqNumは1つインクリメントされてもよい(セクション4.5.9.1参照)。データ物理チャネルPDUが送信されると、HeaderのNESNビットはnextExpectedSeqNumにセットされる。データ物理チャネルPDUを受信したとき、そのデータ物理チャネルPDUのNESNビットがtransmitSeqNumと同じであれば、最後に送信されたデータ物理チャネルPDUは確認されておらず、再送されるものとする。そのデータ物理チャネルPDUのNESNビットがtransmitSeqNumと異なる場合、最後に送信されたデータ物理チャネルPDUは確認され、transmitSeqNumは1つインクリメントされ、新しいデータ物理チャネルPDUが送信されてもよい。上記の処理を図4.39に示す(tSqNo は transmitSeqNum を意味し、nExSqNo は nextExpectedSeqNum を意味する)。

-- Figure 4.39: Transmit and receive SN and NESN flow diagram --

データ物理チャネルPDUが無効なCRC一致で受信された場合、nextExpectedSeqNumは変更されないものとする。これは、データ物理チャネルPDUが確認されないことを意味し、ピアはデータ物理チャネルPDUを再送する。受信したデータ物理チャネルPDUが拒否されたので、ピアデバイスからのnextExpectedSeqNumは信頼できないので、このデバイスから最後に送信されたデータ物理チャネルPDUは確認されず、再送信されなければならない； transmitSeqNumは変更されてはならない。 SN、NESN及びMDビットは、CRCチェックに合格した受信された全てのデータ物理チャネルPDUから使用されなければならない。データ物理チャネルPDUペイロードは、前に受信したデータ物理チャネルPDUと同じSN値を持つすべての受信データ物理チャネルPDUで無視されなければならない。

4.5.9.1 フロー制御

リンクレイヤは、受信バッファスペースの不足などの理由でnextExpectedSeqNumの更新に失敗することがある。これにより、ピアは後日データ物理チャネルPDUを再送することになり、フロー制御が可能になる。

4.5.10 データPDU長の管理

コントローラは、以下のグローバルパラメータを保持する。

connInitialMaxTxOctets - コントローラが新規接続に使用する connMaxTxOctets の値。
connInitialMaxTxTime - コントローラが新しい接続に使用する connMaxTxTime の値を決定するために使用する値。
connInitialMaxTxTimeUncoded - コントローラがLEアンコードPHY上で新規接続に使用するconnMaxTxTimeの値。connInitialMaxTxTimeUncoded の値は、328 と connInitialMaxTxTime の値のうち大きい方でなければならない。
connInitialMaxTxTimeCoded - コントローラが LE コード化 PHY 上の新規接続に使用する connMaxTxTime の値。connInitialMaxTxTimeCoded の値は、2704 と connInitialMaxTxTime の値のうち大きい方でなければならない。
supportedMaxTxOctets - コントローラがサポートする connMaxTxOctets の最大値。
supportedMaxTxTime - コントローラがサポートする connMaxTxTime の最大値です。
supportedMaxRxOctets - コントローラがサポートするconnMaxRxOctetsの最大値です。
supportedMaxRxTime - コントローラがサポートするconnMaxRxTimeの最大値です。注：2704μs は、S=8 コーディングを使用して LE 符号化 PHY で送信されたときの 27 オクテットのペイロードを持つパケットの持続時間から導出される。

コントローラは、各接続に対して以下のパラメータを維持しなければならない。

connMaxTxOctets - ローカルデバイスがリモートデバイスに送信するペイロードの最大オクテット数。
connMaxRxOctets - ローカルデバイスがリモートデバイスから受信できるペイロードの最大オクテット数。
connRemoteMaxTxOctets - ペイロード内の最大オクテット数。リモートデバイスがローカルデバイスに送信するペイロードの最大オクテット数。
connRemoteMaxRxOctets - リモートデバイスがローカルデバイスから受信できるペイロードの最大オクテット数。
connMaxTxTime - ローカルデバイスがリモートデバイスにパケットを送信するのにかかる最大マイクロ秒数。
connMaxRxTime - ローカルデバイスがリモートデバイスからパケットを受信するのにかかる最大マイクロ秒数。
connRemoteMaxTxTime - リモートデバイスがローカルデバイスにパケットを送信するのにかかる最大マイクロ秒数。
connRemoteMaxRxTime - リモートデバイスがローカルデバイスからパケットを受信するのにかかる最大マイクロ秒数。上記パラメータの値(グローバル及び接続ごとの両方)は、それぞれ表4.4に示された範囲内でなければならない。

-- Table 4.4: Valid ranges for data PDU length management parameters --

以下の値は、コントローラが保持するパラメータから導き出されます。

connEffectiveMaxTxOctets - connMaxTxOctets と connRemoteMaxRxOctets.
connEffectiveMaxRxOctets - connMaxRxOctets と connRemoteMaxTxOctets.
connEffectiveMaxTxTimeUncoded - connMaxTxTime と connRemoteMaxRxTime.
connIntervalRequired - 値 (2*T_IFS) + min (connEffectiveMaxRxTime, ((connEffectiveMaxRxOctets * 64) + 976))。
connIntervalCodedMin - connIntervalRequired + 2704. 注: 976μs と 2704μs は、S=8 コーディングを使用して LE 符号化 PHY で送信された場合のゼロオクテットと 27 オクテットのペイロードを持つパケットの持続時間である。
connIntervalPortionAvailable - 接続のための現在の connInterval から connIntervalRequired を引いたもの。
connEffectiveMaxTxTimeAvailable - 以下のいずれか小さい方。 connEffectiveMaxTxTimeUncodedおよびconnIntervalPortionAvailable。
connEffectiveMaxTxTimeCoded - 2704と connEffectiveMaxTxTimeAvailable.
connEffectiveMaxTxTime - 接続がLEアンコードPHY上にある間はconnEffectiveMaxTxTimeUncodedに等しく、接続がLEコード化されたPHY上にある間はconnEffectiveMaxTxTimeCodedに等しくなります。
connEffectiveMaxRxTimeUncoded - connMaxRxTimeとconnRemoteMaxTxTimeの小さい方。
connEffectiveMaxRxTimeCoded - 2704 と connEffectiveMaxRxTimeUncoded の大きい方。
connEffectiveMaxRxTime - 接続がLE Uncoded PHY上にある間はconnEffectiveMaxRxTimeUncodedに等しく、接続がLE Coded PHY上にある間はconnEffectiveMaxRxTimeCodedに等しくなります。注意：対応するオクテットと時間パラメータは、相互に一貫している必要はない。例えば、いくつかの PHY では、可能な最大時間がより短い場合でも、時間パラメータが 2120μs であることは許容される。コントローラは、supportedMaxTxOctets, supportedMaxTxTime, supportedMaxRxOctets, supportedMaxRxTime の値を変更してはならない。新規接続の場合。
connMaxTxOctetsをconnInitialMaxTxOctetsに設定し、connMaxRxOctetsはコントローラが選択する。どちらかの値が27でない場合、コントローラは、実用的な機会があれば早急にデータ長更新手順(5.1.9項)を開始すべきである。
connRemoteMaxTxOctets 及び connRemoteMaxRxOctets は 27 でなければならない。LE アンコードPHY上の新規接続の場合。
connMaxTxTime は connInitialMaxTxTimeUncoded に設定し、connMaxRxTime はコントローラが選択する。どちらかの値が328でない場合、コントローラは、実用的な機会があれば、データ長更新手順(5.1.9項)を開始すべきである。
connRemoteMaxTxTime及びconnRemoteMaxRxTimeは328でなければならない。LE 符号化された PHY 上の新規接続の場合。
connMaxTxTime を connInitialMaxTxTimeCoded に設定し、connMaxRxTime をコントローラが選択する。いずれかの値が2704でない場合、コントローラは、実用的な機会が最も早い時点でデータ長更新手順(セクション5.1.9)を開始すべきである。
connRemoteMaxTxTime及びconnRemoteMaxRxTimeは2704でなければならない。コントローラは、接続状態に入った後、connMaxTxOctets、connMaxRxOctets、connMaxTxTime、およびconnMaxRxTimeの値をいつでも変更することができる。その都度、データ長更新手順を使用して、これらの値を相手装置に通信する。値は、それぞれsupportedMaxTxOctets、supportedMaxTxTime、supportedMaxRxOctets、supportedMaxRxTimeを超えてはならない。コントローラは、最大ペイロード長が connEffectiveMaxTxOctets を超えるか、または connEffectiveMaxTxTime の値が変更されている期間を除き、送信に要する時間が connEffectiveMaxTxTime マイクロ秒を超える LL データ PDU を含むパケットを送信してはならない。その期間中、コントローラは、古いパラメータには適合しているが新しいパラメータには違反しているLLデータPDUを送信用にキューに入れたままにしておくことができる。これらのＰＤＵは有効なままであり、データ長更新手順が完了した後にキューイングされたＰＤＵのみが、変更されたパラメータに適合することが要求される。ただし、コントローラは、LL_LENGTH_REQまたはLL_LENGTH_RSP PDUを送信する際に、送信用にキューに入っているLLデータPDUがないことを確認しなければならない。注：これらの要件は、LL制御PDUには適用されない（セクション4.5.11参照）。コントローラがconnMaxRxOctetsまたはconnMaxRxTimeの値を減少させた場合、新しい値を送信するデータ長更新手順(5.1.9項)が完了するまで、コントローラは新しい値を適用してはならない。コントローラは、connEffectiveMaxTxOctets、connEffectiveMaxRxOctets、connEffectiveMaxTxTime、またはconnEffectiveMaxRxTimeのいずれかのパラメータが変更された場合、ホストに通知しなければならない。

注意：これらのパラメータは、データ長更新手順(5.1.9項)、PHY更新手順(5.1.10項)、コネクション更新手順(5.1.1項)、コネクションパラメータ要求手順(5.1.7項)の一部として変更される可能性がある。

4.5.11 制御PDU長管理。

リンク層は、同一接続上でフィーチャー交換手続き（5.1.4 節参照）が完了するまでは、26 オクテットを超える CtrData を含む LL 制御 PDU を含むパケットを送信してはならない。。注： 4.6 節で規定されているように、いったん機能交換が完了すると、リンク層は、相手がサポートされていないプロシージャを使用することはできません。このため、リンク層は、26 オクテットを超える CtrData を持つ LL 制御 PDU をサポートしていない機器に送信することはない。。

5.1 リンクレイヤ制御手順

なお、以下の各項の規定は、機能に対応していないリンクレイヤの動作を記述する場合を除き、そのリンクレイヤが機能に対応している場合にのみ適用するものとする（4.6 節参照）。

5.1.1 接続の更新手順

接続のリンク層パラメータ（connInterval、connSlaveLatency、connSupervisionTimeout）は、接続状態に入った後に更新することができる。デバイスは、接続パラメータの変更を要求することができるが、その場合は、次の規則を適用する。マスタとスレーブの両方が接続パラメータ要求手順（5.1.7項参照）をサポートしている場合は、どちらかのデバイスがその手順を使用しなければならない。ただし、スレーブが提案された接続パラメータを拒否した場合、マスタは、接続更新手順を使用して接続パラメータを更新してもよい。マスタ、スレーブ、またはその両方が接続パラメータ要求手順をサポートしていない場合、マスタは LL_CONNECTION_UPDATE_IND PDU を送信する（スレーブはこの PDU を送信しない）。スレーブは、L2CAP LEシグナリングチャネルを使用するものとする（[Vol.3]パートA、セクション4.20およびセクション4.21を参照）。デバイスが接続パラメータ要求手順をサポートしているが、ピアがサポートしているかどうかがわからない場合（どちらのデバイスも以前にその手順を試行したことがないか、フィーチャ交換手順を実行したことがないため）、デバイスは、接続パラメータ要求手順を開始し、ピアがLL_UNKNOWN_RSP PDUで応答した場合には、前項に記載した方法を使用して、接続パラメータ要求手順を開始しなければならない。マスタのリンク層は、ホストから与えられた間隔範囲(connIntervalmin と connIntervalmax)から connInterval を決定する。ただし、現在の PHY が LE 符号化 PHY であり、コントローラが LE データパケット長拡張機能をサポートしている場合には、新しい接続間隔は、少なくとも connIntervalCodedMin μs でなければならない。リンク層は、選択されたインターバル値をホストに示さなければならない。 5.5 節の規定は、LL_CONNECTION_UPDATE_IND PDU に適用する。スレーブは、未来の瞬間を持つこのような PDU を受信した場合、connEventCount が Instant となる接続イベントと、その前の接続イベントをリッスンする。インスタントの前に使用される接続間隔は、connIntervalOLDとして知られている。LL_CONNECTION_UPDATE_IND PDU に含まれ、Instant で使用される接続間隔を connIntervalNEW と呼ぶ。インスタント前に使用される接続スレーブのレイテンシをconnSlaveLatencyOLDという。LL_CONNECTION_UPDATE_IND PDU に含まれ、その瞬間以降に使用される接続スレーブのレイテンシを connSlaveLatencyNEW と呼ぶ。インスタント前に使用される接続監視タイムアウトを connSupervisionTimeoutOLD と呼ぶ。LL_CONNECTION_UPDATE_IND PDU に含まれ、その瞬間以降に使用される接続監視タイムアウトを connSupervisionTimeoutNEW と呼ぶ。接続監視タイマは、その瞬間にリセットされるものとする。例えば、インスタント前の先行接続イベントとインスタント後の接続イベントとの間の間隔は、connIntervalOLDとする。即座後の接続イベントから次の接続イベントまでの間隔を connIntervalNEW とする。マスタは、新しい接続パラメータで送信される最初のパケットのタイミングを決定する際にアンカーポイントを調整してもよい。で定義されているように、送信ウィンドウが使用されます。送信ウィンドウは、瞬間前の接続イベントのアンカーポイントの後、connIntervalOLD＋transmitWindowOffsetで開始する。送信ウィンドウの開始位置は、0ms から connIntervalNEW の範囲で 1.25ms の倍数とする。また、transmitWindowSize は、1.25ms～10ms の範囲で 1.25ms の倍数とし、(connIntervalNEW - 1.25ms)の小さい方とする。注：スレーブがその瞬間に LL_CONNECTION_UPDATE_IND PDU を最初に受信した場合、スレーブはそのパケットを直ちに新しいアンカーポイントとして使用することができ、temmitWindowOffset 及び transmitWindowSize は適用されない。マスタは、セクション4.5.3で定義されているように、送信ウィンドウ内の最初のパケットの送信を開始しなければならない。マスタの最初のパケットは、送信ウィンドウを超えて送信することができる。マスタがインスタントの後に送信する最初のパケットは、接続イベントの新しいアンカーポイントを決定し、したがって、この接続における将来のすべての接続イベントのタイミングを決定する。インスタントは connIntervalOLD の後、transmitWindowOffset の前に発生します。4.5.1 節に規定されている通常の接続イベント送信ルールがすべて適用されます。送信ウィンドウの開始時に、リンク層は TLLconnSupervision をリセットする。マスタのリンク層が自律的に LL_CONNECTION_UPDATE_IND PDU を送信する場合、例えばホストからの要求がなくても、Latency 及び Timeout パラメータは変更せず、前回の LL_CONNECTION_UPDATE_IND、CONNECT_IND、AUX_CONNECT_REQ PDU と同じままとする。他のパラメータ（transmitWindowSize、transmitWindowOffset、connInterval、Instant）は、与えられた制限の範囲内で変更することができる。

5.1.2 チャンネルマップ更新手順

チャネルマップのリンクレイヤパラメータ（channelMap）は、接続状態に入ると更新されることがあります。マスタは、LL_CHANNEL_MAP_IND PDU を送信することでチャネルマップを更新することができる。スレーブはこのPDUを送信しない。マスタコントローラは、ホストから要求されなくてもチャネルマップの更新を行うことができる。節は、LL_CHANNEL_MAP_IND PDUに適用するものとする。瞬間以前に使用されていたチャンネルマップは、channelMapOLDとして知られている。LL_CHANNEL_MAP_IND PDUに含まれ、その瞬間以降に使用されるチャネルマップは、channelMapNEWとして知られている。 connEventCountがInstantフィールドと等しい場合、channelMapNEWは、現在のchannelMapでなければならない。lastUnmappedChannelはリセットされないものとする。unmappedChannelが未使用のチャネルである場合、再マッピングの際には、channelMapNEWが使用される。変更されるパラメータは、channelMapのみである。例えば、以下のようになります。接続設定時。

初期値 channelMapOLD: 0x1FFFFFFFFF (つまり全チャンネルが有効)
初期ホップインクリメント。10(10進数) その後、以下のパラメータを持つ LL_CHANNEL_MAP_IND PDU が発行される。
インスタント：100（10進数）。接続開始から接続イベントカウントのラップアラウンドが発生していないと仮定します。
channelMapNEW: 0x1FFFFFF7FF (すなわち、チャネル 11 を除くすべてのチャネルが有効) 使用チャネル。
connEventCount 99 --> データチャネルインデックス 1 (channelMapOLD)
connEventCount 100 --> データチャネルインデックス 12 (11 からリマップ) (channelMapNEW)
connEventCount 101 --> データチャネルインデックス 21 (channelMapNEW) 瞬間が経過した時点で手続きは完了し、新しいチャネルマップが適用されました。

5.1.3 暗号化手順

リンクレイヤは、ホストからの要求により、接続状態に入った後、パケットの暗号化を有効にすることができる。接続が暗号化されていない場合、リンクレイヤは暗号化開始処理のみを行う。暗号化されている場合は、まず暗号化一時停止を行い、その後暗号化開始を行う。

5.1.3.1 暗号化開始手順

暗号化を有効にするためには、IVとSKDの2つのパラメータを交換する必要があります。両方ともマスター部とスレーブ部の2つの部分から構成され、LL_ENC_REQとLL_ENC_RSP PDUで交換される。これらが交換され、ホストがこの接続で使用する長期鍵をリンク層に通知した後、LL_START_ENC_REQ と LL_START_ENC_RSP PDU を使用して、3 者間ハンドシェイクを用いて暗号化を開始することができる。暗号化を開始するために、マスタのリンク層は、マスタの初期化ベクトル(IVm)とセッション鍵分散器(SKDm)を生成する。IVm は、マスタのリンク層が生成する 32 ビットの乱数とする。SKDm は、マスタのリンク層が生成する 64 ビットの乱数とする。IVm 及び SKDm は、[Vol.2]第 H 部第 2 節の乱数生成要件を用いて生成する。マスタのリンク層は、現在のデータ物理チャネルPDUの送信を確定し、コントローラにキューイングされた追加のデータ物理チャネルPDUの送信を確定してもよい。これらのデータ物理チャネルPDUが確認された後、この手順が完了するか、または別の方法で指定されるまで、マスタのリンクレイヤは、Empty PDU、LL_TERMINATE_IND PDU、およびこの手順で必要とされるPDUのみを送信するものとする。次に、マスタのリンクレイヤは、LL_ENC_REQ PDUを送信するものとし、RandフィールドとEDIVフィールドはホストによって提供される。スレーブのリンク層が暗号化をサポートしていない場合、スレーブのリンク層は、エラーコードを「Unsupported Remote Feature / Unsupported LMP Feature（0x1A）」に設定した LL_REJECT_IND または LL_REJECT_EXT_IND PDU を送信する。LL_REJECT_IND または LL_REJECT_EXT_IND PDU を受信したマスタのリンク層はホストに通知する。マスタのリンク層はこれでLLデータPDUとLL制御PDUを送信できるようになったが，これらのパケットは暗号化されない。この手順は、マスタがスレーブからＬＬ＿ＲＥＪＥＣＴ＿ＩＮＤまたはＬＬ＿ＲＥＪＥＣＴ＿ＥＸＴ＿ＩＮＤＰＤＵを受信したときにマスタにおいて完了する。マスタはＥｍｐｔｙＰＤＵを使用してこのＰＤＵをアクノリッジすべきである。スレーブがLL_REJECT_INDまたはLL_REJECT_EXT_IND PDUをマスタに送信した時点で手続きは完了する。そうでなければ、スレーブのリンク層がLL_ENC_REQ PDUを受信すると、初期化ベクトル(IVs)のスレーブ部分とセッション鍵多様化器(SKDs)のスレーブ部分を生成しなければならない。IV は、スレーブのリンク層によって生成される 32 ビットの乱数とする。SKD は、スレーブのリンク層が生成する 64 ビットの乱数とする。IV 及び SKD は、[Vol.2]パート H セクション 2 に規定される乱数生成の要件を用いて生成する。スレーブのリンク層は、現在のデータ物理チャネルPDUの送信を確定し、コントローラにキューイングされた追加のデータ物理チャネルPDUの送信を確定してもよい。これらのデータ物理チャネルＰＤＵが確認された後、この手順が完了するか、または別の指定があるまで、スレーブのリンク層は、ＥｍｐｔｙＰＤＵ、ＬＬ＿ＴＥＲＭＩＮＡＴＥ＿ＩＮＤＰＤＵ、およびこの手順で必要とされるＰＤＵのみを送信するものとする。その後、スレーブのリンク層は、LL_ENC_RSP PDUを送信する。続いて、スレーブのリンク層は、Ｒａｎｄフィールド及びＥＤＩＶフィールドを用いてホストに通知する。ＬＬ＿ＥＮＣ＿ＲＳＰＰＤＵを送信した後、スレーブのリンク層は、スレーブが送信したＬＬ制御ＰＤＵに対応するＬＬ＿ＵＮＫＮＯＷＮ＿ＲＳＰＰＤＵを受信することができる。この場合、スレーブはリンクを切断してはならない。各リンクレイヤは、初期化ベクトル部とセッション鍵分散部を次のように結合する。 SKD = SKDm || SKDs IV = IVm || IVs ＳＫＤｍは、ＳＫＤと連結される。ＳＫＤｍの最下位オクテットは、ＳＫＤの最下位オクテットとなる。SKDの最も有意なオクテットはSKDの最も有意なオクテットになる。ＩＶｍはＩＶと連結される。IVmの最下位オクテットはIVの最下位オクテットとなる。IVsの最も有意なオクテットは、IVの最も有意なオクテットになる。 Long Term Keyは、ホストからマスタ及びスレーブのリンクレイヤに提供され、以下の３つのうちいずれかの動作が発生するものとする。

本手順が一時停止暗号化手順の後に実行されており、ホストが長期鍵を提供しない場合、スレーブは、エラーコードPINまたは鍵欠落(0x06)で終了手順を実行する。
ホストが長期鍵を提供しない場合、ホストへのイベントがマスクアウトされたためか、ホストが鍵が利用できないことを示した場合、スレーブは、エラーコードがPINまたは鍵欠落（0x06）に設定されたLL_REJECT_INDを送信するか、RejectOpcodeが "LL_ENC_REQ "に設定され、エラーコードがPINまたは鍵欠落（0x06）に設定されたLL_REJECT_EXT_IND PDUを送信するものとする。LL_REJECT_IND PDU または LL_REJECT_EXT_IND PDU を受信した場合、リンクレイヤーはホストに通知する。リンク層はこれで LL データ PDU と LL 制御 PDU を送信することが可能となり、これらのパケットは暗号化されない。マスタがスレーブから LL_REJECT_IND または LL_REJECT_EXT_IND PDU を受信した時点でマスタでこの手順は完了する。スレーブではマスタから LL_REJECT_IND または LL_REJECT_EXT_IND PDU の確認応答を受信した時点で手続きは完了する。
ホストから Long Term Key が提供された場合、スレーブのリンク層は暗号化エンジンを用いて LTK を鍵とし、SKD を平文入力として sessionKey を計算する。sessionKey パラメータは、暗号化エンジンの出力に設定する。 sessionKey は、暗号化された全てのパケットの暗号化エンジンの鍵として使用される。 sessionKey が計算された後、スレーブのリンク層は LL_START_ENC_REQ PDU を送信する。このパケットは暗号化されていない状態で送信され、リンク層はこれに応答して暗号化されたパケットを受信するように設定する。マスタのリンク層は、LL_START_ENC_REQ PDUを受信すると、LL_START_ENC_RSP PDUを送信する。この PDU は暗号化された状態で送信され、リンク層は応答として暗号化されたパケットを受信するように設定する。スレーブのリンク層は、LL_START_ENC_RSP PDUを受信した場合、LL_START_ENC_RSP PDUを送信する。このパケットは暗号化して送信する。マスタのリンク層がLL_START_ENC_RSP PDUを受信すると、接続は暗号化される。リンク層は、これでLLデータPDU及びLL制御PDUを送信することができるようになり、これらのPDUは暗号化されて送信される。リンク層は、接続が暗号化されたことをホストに通知する。マスターがスレーブから LL_START_ENC_RSP PDU を受信した時点でマスター側での手続きは完了する。スレーブ側では，スレーブがマスタから LL_START_ENC_RSP PDU を受信した時点で手続きが完了する。暗号化開始手順中に、マスタのリンク層またはスレーブのリンク層が、相手リンク層から予期しないデータ物理チャネルPDUを受信した場合は、直ちに接続状態を終了し、スタンバイ状態に遷移するものとする。ホストには、エラーコード「Connection Terminated Due to MIC Failure（0x3D）」でリンクが切断されたことを通知する。

5.1.3.2 暗号化一時停止手順

リンクを切断せずに新しい暗号化キーを使用できるようにするには、暗号化を無効にしてから再度有効にしなければならない。一時停止中は、データを保護するために、データPDUは暗号化されていない状態で送信されてはならない。マスタのリンク層は、現在のデータ物理チャネルPDUの送信を確定し、コントローラにキューイングされた追加のデータ物理チャネルPDUの送信を確定してもよい。これらのデータ物理チャネルPDUが確認された後、この手順が完了するまで、マスタのリンクレイヤは、Empty PDU、LL_TERMINATE_IND PDU、およびこの手順で必要とされるPDUのみを送信するものとする。その後、マスタのリンク層は、LL_PAUSE_ENC_REQ PDUを送信する。スレーブのリンク層は、LL_PAUSE_ENC_REQ PDUを受信すると、現在のデータ物理チャネルPDUの送信を確定し、コントローラにキューイングされた追加のデータ物理チャネルPDUの送信を確定してもよい。これらのデータ物理チャネルＰＤＵが確認された後、この手順が完了するまで、スレーブのリンク層は、ＥｍｐｔｙＰＤＵ、ＬＬ＿ＴＥＲＭＩＮＡＴＥ＿ＩＮＤＰＤＵ、及びこの手順で必要とされるＰＤＵのみを送信するものとする。その後、スレーブのリンク層は、LL_PAUSE_ENC_RSP PDUを送信するものとする。このパケットは暗号化されて送信されるものとし、リンクレイヤはこれに応答して暗号化されていないパケットを受信するように設定する。マスタのリンク層は、LL_PAUSE_ENC_RSP PDUを受信すると、暗号化されていないパケットを送受信するように設定する。その後、スレーブに対して暗号化されていない LL_PAUSE_ENC_RSP PDU を送信する。スレーブのリンク層がLL_PAUSE_ENC_RSP PDUを受信した場合は、暗号化されていない状態でも送信するように設定する。暗号化開始手順は、新しいセッション鍵を使用して暗号化を再有効化するために使用されるものとする。暗号化一時停止手順中に、マスタまたはスレーブのリンク層が相手リンク層から予期しないデータ物理チャネルPDUを受信した場合は、直ちに接続状態を終了し、スタンバイ状態に遷移する。ホストには、エラーコード「Connection Terminated Due to MIC Failure（0x3D）」でリンクが切断されたことを通知する。

5.1.4 機能交換手順

現在サポートされているフィーチャセット（FeatureSet）のリンクレイヤパラメータは、コネクション状態に入った後に交換することができます。マスタとスレーブの両方でこの手順を開始することができます。フィーチャーセットの情報は、接続中でも接続間でもキャッシュされます。この情報がキャッシュされている場合は、接続の度に要求してはならない。前の接続からのデバイスのためにキャッシュされた情報は権威を持たないため、現在ピアでサポートされていない、またはピアで使用されていない機能を使用しようとする場合、実装は LL_UNKNOWN_RSP PDU を受け入れることができなければならない。 FeatureSetMパラメータは、4.6節で規定されているように特定のビットがマスクされたマスタのリンク層のフィーチャー能力である。 FeatureSetS」パラメータは、4.6 節で規定された特定のビットがマスクされたスレーブのリンク層の機能能力である。 FeatureSetUSED パラメータは、1 オクテットの長さで、FeatureSetM[0]とFeatureSetS[0]の論理和である。

5.1.4.1 マスター起動型フィーチャ交換手順

マスタのリンク層は、LL_FEATURE_REQ PDUをスレーブに送信することで、この手順を開始します。これは、ホストからの要求に応じて行うこともできるし、自律的に行うこともできる。スレーブのリンク層は、これを受信した場合、LL_FEATURE_RSP PDU を送信して応答する。マスタ側リンク層は、LL_FEATURE_REQ PDU を送信した場合、FeatureSet フィールドを FeatureSetM に設定する。スレーブ側リンク層が LL_FEATURE_RSP PDU を送信した場合は、FeatureSet フィールドのオクテット 0 を FeatureSetUSED に設定し、残りのオクテットを FeatureSetS の対応するオクテットに設定する。この手順は、マスタがスレーブから LL_FEATURE_RSP PDU を受信した時点で完了する。

5.1.4.2 スレーブ主導のフィーチャ交換手順

スレーブのリンク層は、LL_SLAVE_FEATURE_REQ PDUをマスタに送信することで、この手順を開始します。これは、ホストからの要求に応じて行うこともできるし、自律的に行うこともできる。マスタのリンク層は、これを受信した場合、LL_FEATURE_RSP PDU を送信することで応答する。スレーブのリンク層は、LL_SLAVE_FEATURE_REQ PDU を送信した場合、FeatureSet フィールドを FeatureSetS に設定する。マスタ側リンク層が LL_FEATURE_RSP PDU を送信した場合は、FeatureSet フィールドの 0 オクテットを FeatureSetUSED とし、残りのオクテットを FeatureSetM の対応するオクテットとする。スレーブのリンク層が LL_SLAVE_FEATURE_REQ PDU を、その PDU を理解していないマスタに送信した場合、スレーブは応答として LL_UNKNOWN_RSP PDU を期待する。LL_SLAVE_FEATURE_REQ PDUがホスト主導のリードリモートフィーチャースプロシージャの結果として発行された場合（[Vol 2]パートE、セクション7.8.21参照）、ホストは、ErrorCodeがUnsupported Remote Feature / Unsupported LMP Feature（0x1A）に設定された状態でリードリモートフィーチャースプロシージャが完了したことを通知しなければならない。スレーブがマスタからLL_FEATURE_RSPまたはLL_UNKNOWN_RSP PDUを受信した時点で手続きは完了する。

5.1.5 バージョン交換手順

2.4.2.2.13 節で定義したバージョン情報のリンク層パラメータ（companyID、subVerNum、linkLayerVer）は、接続状態に入った後に交換することができる。マスタまたはスレーブのリンクレイヤは、LL_VERSION_IND PDU を送信することにより、この手順を開始することができる。この手順は、ホストから要求された場合に使用する。この処理は、リンク層が自律的に開始することができる。リンク層は１回の接続中に最大１個のLL_VERSION_IND PDUを送信することができる。リンク層が LL_VERSION_IND PDU を受信し、まだ LL_VERSION_IND を送信していない場合、リンク層は相手機器に LL_VERSION_IND PDU を送信する。リンク層が LL_VERSION_IND PDU を受信した場合で、既に LL_VERSION_IND PDU を送信している場合は、リンク層は次の LL_VERSION_IND PDU を相手機器に送信してはならない。この処理は、相手機器から LL_VERSION_IND PDU を受信した時点で終了する。

5.1.6 終了処理

この手順は、接続状態での接続を任意に終了させる場合に使用します。任意終了は、ホストがリンク層に接続の終了を要求した場合に発生します。マスタまたはスレーブのリンク層は、LL_TERMINATE_IND PDU を送信することで、この手順を開始することができます。この処理は、リンク監視がタイムアウトした後やプロシージャがタイムアウトした後など、接続が切断された場合には使用しない。リンク層は、LL_TERMINATE_IND PDU が送信待ち状態となった場合にタイマを起動する。起動したリンク層は、確認応答を受信するまで、またはタイマ「Tterminate」が終了するまでの間、 LL_TERMINATE_IND PDU を送信し、接続状態を終了して待機状態に移行する。Tterminate の初期値は、connSupervisionTimeout の値とする。リンク層は、「LL_TERMINATE_IND」PDU を受信すると、確認応答を送信し、接続状態を終了し、スタンバイ状態に移行する。この処理は、確認応答を受信した時点、またはタイマの有効期限が切れた時点で終了する。

5.1.7 接続パラメータ要求手順

マスタまたはスレーブは、接続状態に入ってからいつでも、接続のためのリンク・レイヤー・パラメータ（connInterval、connSlaveLatency、およびconnSupervisionTimeout）が更新されるようにリモート・デバイスに要求するために、接続パラメータ要求手順を開始することができます。

5.1.7.1 LL_CONNECTION_PARAM_REQ PDUの発行

接続パラメータ要求手順は、LL_CONNECTION_PARAM_REQ PDU の発行により開始される。この手順は、ホストが開始した接続更新手順（[Vol 2]パートE、セクション7.8.18参照）の結果として開始されるか、リンク層が自律的に（つまり、ホストから要求されることなく）開始することができる。マスタまたはスレーブのリンク層が、そのPDUを理解していないデバイスにLL_CONNECTION_PARAM_REQ PDUを送信した場合、そのデバイスは、応答としてLL_UNKNOWN_RSP PDUを期待すべきである。ホストが開始した接続更新手続きの結果、スレーブのリンク層からLL_CONNECTION_PARAM_REQ PDUが発行された場合、ホストは、ErrorCodeがUnsupported Remote Feature／Unsupported LMP Feature（0x1A）に設定された状態で、接続更新手続きが完了したことを通知しなければならない。ホストからの接続更新手続きの結果、リンク層がこの手続きを開始した場合は、リンク層は、この手続きを終了したことを通知する。

Interval_Min、Interval_Max、Timeout、Latency の各フィールドをホストから受信した値に設定する。注：ホストから受信した値では、リンクレイヤが他のパイコネットのコミットメントを満たすことができないため、リンクレイヤはこれらのフィールドの値を変更することができる。
2.4.2.2.16 節の PreferredPeriodicity の値をゼロ以外の値に設定し、優先する周期性を示してもよい。
セクション2.4.2.16の規定に従い、Offset0～Offset5に0xFFFF以外の値を設定してもよい。Offset0～Offset5フィールドのうち1つ以上が設定されている場合。
ReferenceConnEventCountフィールドは、Offset0～Offset5フィールドのうち少なくとも1つが有効であることを示すために設定されなければならない。ReferenceConnEvent-Countフィールドが設定されている場合は、常に、PDUの最初の送信から将来の接続イベント数が32767よりも少ない接続イベントのconnEventCountに設定されなければならない。備考：PDUの再送により、PDUがリモートデバイスによって正常に受信されたときに、ReferenceConnE-ventCountが過去の最大32767イベントになることがある。ReferenceConnEventCountフィールドの設定方法の例については、5.1.7.3.2項を参照してください。
Interval_Min が Interval_Max と等しくない場合は、PerferredPeriodicity フィールドをゼロ以外の値に設定しなければならない。Interval_Min が Interval_Max の場合、PreferredPeriodicity フィールドには任意の値を設定することができ、受信側では無視する。リンク層が自律的にこの処理を開始する場合は、「Latency」フィールドを「connSlaveLatency」の現在値に、「Timeout」フィールドを「connSupervisionTimeout」の現在値（ミリ秒）に設定する。他のフィールドのいずれか（Interval_Min、Interval_Max、PreferredPeriodicity。 ReferenceConnEventCount、Offset0～Offset5）は、上記の制限の範囲内で変更することができる。リンク層は、LL_CONNECTION_PARAM_REQ のパラメータがスーパービジョンタイムアウトを起こさないようにすること。すなわち、タイムアウト（ミリ秒単位）が 2* Interval_Max *（遅延＋1）以上であること。

5.1.7.2 LL_CONNECTION_PARAM_REQ および LL_CONNECTION_PARAM_RSP PDU への応答

LL_CONNECTION_PARAM_REQ PDUを受信した場合。

スレーブは LL_CONNECTION_PARAM_RSP PDU または LL_REJECT_EXT_IND PDU のいずれかで応答する。
マスタはLL_CONNECTION_UPDATE_IND PDUまたはLL_REJECT_EXT_IND PDUのいずれかで応答する。 LL_CONNECTION_PARAM_RSP PDUを受信した場合、マスタはLL_CONNECTION_UPDATE_IND PDUまたはLL_REJECT_EXT_IND PDUのいずれかで応答しなければならない。マスタは、LL_CONNECTION_PARAM_RSP PDUを送信してはならない。スレーブは、LL_CONNECTION_PARAM_REQ PDUに応答してのみLL_CONNECTION_PARAM_RSP PDUを送信しなければならない。受信したLL_CONNECTION_PARAM_REQ PDUにリンク層に受け入れられないパラメータが含まれている場合、装置のリンク層はLL_CONNECTION_PARAM_REQ PDUに対して次のいずれかで応答する。
LL_CONNECTION_PARAM_RSP PDU（リンク層が接続のスレーブである場合）または LL_CONNECTION_UPDATE_IND PDU（リンク層が接続のマスタである場合）。
エラーコードが「Unsupported LL Parameter Value（0x20）」に設定された LL_REJECT_EXT_IND PDU。受信した LL_CONNECTION_PARAM_REQ PDU に有効範囲外のフィールドが含まれていた場合、リンク層は LL_CONNECTION_PARAM_REQ PDU を拒否し、ErrorCode を「無効な LL パラメータ」（0x1E）とした LL_REJECT_EXT_IND PDU を発行して LL_CONNECTION_PARAM_REQ PDU を拒否する。接続パラメータ要求手順中にＬＬ＿ＲＥＪＥＣＴ＿ＥＸＴ＿ＩＮＤＰＤＵが送信された場合、その手順はＬＬ＿ＲＥＪＥＣＴ＿ＥＸＴ＿ＩＮＤＰＤＵを受信した装置では完了し、ＬＬ＿ＲＥＪＥＣＴ＿ＥＸＴ＿ＩＮＤＰＤＵの確認応答を受信した装置では完了する。受信した LL_CONNECTION_PARAM_REQ PDU が、LE 接続のアンカーポイントの変更のみを要求している場合、リンク層はホストに対してこの要求を示さない。受信した LL_CONNECTION_PARAM_REQ PDU が connInterval、connSlaveLatency 及び connSupervisionTimeout のうち 1 つ以上の変更を要求し、リンク層が選択した値がそれぞれ connInterval の範囲内であれば、リンク層はこの要求をそのホストに通知しない。この場合、リンク層は、ホストへの要求を表示せず、ホストがリモートデバイスの要求を受諾したものとして処理を行うことを選択することができる。そうでない場合、リンク層は、ホストへのイベントがマスクされていない場合には、まずホストにこの要求を示す。ローカルホストが connInterval の範囲、connSlaveLatency の値及び connSupervisionTimeout の値をスレーブのリンク層に提供していない場合、スレーブのリンク層は、ホストへのイベントがマスクされていない場合には、受信したリクエストをホストに指示してもよい。ホストへの指示中にホストへのイベントがマスクされている場合は、リンク層はエラーコードを Unsupported Remote Feature / Unsupported LMP Feature（0x1A）とした LL_REJECT_EXT_IND PDU を発行する。備考：デバイスは一時的にLL_REJECT_EXT_IND PDUを発行した可能性があり、そのため開始デバイスは再試行することができる。注意：リクエストがホストに指示されていない場合、イベントマスクは無視されます。ホストに要求を指示された場合，ホストはこの要求を受け入れるか拒否する。ホストがこの要求を拒否する場合，デバイスは，ホストによって提供された値に設定されたErrorCodeを持つLL_REJECT_EXT_IND PDUを発行しなければならない。ホストは，要求を拒否するために，エラーコードUnacceptable Connection Parameters(0x3B)のみを使用しなければならない。ホストがこの要求を受け入れた場合、又は要求がホストに指示されていなかった場合。
スレーブは、LL_CONNECTION_PARAM_REQ PDUに対して、LL_CONNECTION_PARAM_RSP PDUで応答しなければならない。LL_CONNECTION_PARAM_RSP PDUの様々なフィールドを埋めるためのルールは、5.1.7.1項で述べたように、LL_CONNECTION_PARAM_REQ PDUの様々なフィールドを埋めるためのルールと同じである。マスタのリンク層で受信したLL_CONNECTION_PARAM_RSP PDUを処理するためのルールは、本節で先に説明した受信したLL_CONNECTION_PARAM_REQ PDUを処理するためのルールと同じである。マスタは、LL_CONNECTION_PARAM_REQ PDUまたはLL_CONNECTION_PARAM_RSP PDUに対して、LL_CONNECTION_UPDATE_IND PDUで応答しなければならない。マスターは、スレーブが LL_CONNECTION_PARAM_REQ PDU または LL_CONNECTION_PARAM_RSP PDU の PreferredPeriodicity フィールドを設定している場合、PreferredPeriodicity の倍数である Interval を選択しようとすべきである。ただし、現在の PHY が LE Coded PHY であり、コントローラが LE Data Packet Length Extension 機能をサポートしている場合は、新しい接続間隔は少なくとも connIntervalCodedMin μs でなければならない。LL_CONNECTION_UPDATE_IND PDUのInstantフィールドは、5.1.1項で説明したように設定される。マスタがLL_CONNECTION_UPDATE_IND PDUを発行すると、接続パラメータは5.1.1項で説明したように更新されます。インスタントが経過し、新しい接続イベントパラメータが適用された時点で手続きは完了します。

5.1.7.3 例

5.1.7.3.1 スレーブ起動型アンカーポイント移動

次の例では、スレーブのリンク層が 3.75msec で LE 接続のアンカーポイントの変更を要求している。スレーブのリンク層は、以下のパラメータを持つ LL_CONNECTION_PARAM_REQ PDU を発行する。

Interval_Min：connInterval
Interval_Max: connInterval
レイテンシ: connSlaveLatency
タイムアウト: connSupervisionTimeout
PreferredPeriodicity: 0
ReferenceConnEventCount。<将来の接続イベント数が32767未満の値>。
オフセット0. 0x0003
オフセット1：0xFFFF
オフセット2：0xFFFF
オフセット3：0xFFFF
オフセット4：0xFFFF
オフセット5：0xFFFF マスタのリンク層がスレーブからの要求を受け付けると、スレーブは以下のパラメータセットのいずれかを含む LL_CONNECTION_UPDATE_IND PDU で応答する。全てのセットにおいて、IntervalはconnIntervalに設定され、LatencyはconnSlaveLatencyに設定され、TimeoutはconnSupervisionTimeoutに設定され、Instantは将来の接続イベント数が32767以下である任意の値に設定される。
オプション1：マスタがインスタントの後に送信する最初のパケットは、送信ウィンドウ内で、送信ウィンドウの開始から3.75msである。
3≤WinSize≤8 - WinOffset: 0
オプション２：マスターから送信された最初のパケットは、送信ウィンドウ内にあり、送信ウィンドウの先頭から2.5ms離れています。
2≤WinSize≤8
WinOffset: 1
オプション3：マスターがインスタント後に送信した最初のパケットは、送信ウィンドウ内にあり、送信ウィンドウの先頭から1.25ms離れています。
1≤WinSize≤8
WinOffset: 2
オプション４：マスターがインスタント後に送信した最初のパケットは、送信ウィンドウ内にあり、送信ウィンドウの先頭から０ｍｓである。
1≤WinSize≤8 - WinOffset. 3

5.1.7.3.2 ReferenceConnEventCount

図5.2と図5.3は、LL_CONNECTION_PARAM_REQとLL_CONNECTION_PARAM_RSP PDUのReferenceConnEventCountとOffset0～Offset5フィールドが、古い接続パラメータを持つ接続のアンカーポイントに対する新しい接続パラメータを持つ接続のアンカーポイントの可能性のある位置を示すためにどのように利用できるかの例を示している。この図では、簡単にするために、Offset0のみを示している（Offset1からOffset5までは示していない）。また、この図は、更新された接続パラメータが適用される瞬間も示しています。実際のInstantは、LL_CONNECTION_UPDATE_IND PDUのInstantフィールドが古い接続パラメータで送信された接続イベントのconnEventCountに設定されているのに対し、古い接続パラメータで送信された最後の接続イベントの後にconnIntervalOLDが発生します。 ReferenceConnEventCountは、新しい接続パラメータ上の非常に次の接続イベントの開始が、ReferenceConnEventCount接続イベントの開始からOffset0（ミリ秒単位）離れているように、古い接続パラメータ上の接続イベントのconnEventCountに設定されます。図 5.2 に、Instant が ReferenceConnEventCount の前にある場合を示します。図 5.3 に、Instant が ReferenceConnEventCount の後にある場合を示す。旧接続パラメータで送信された架空の接続イベントがInstantを超えて表示され、新接続パラメータで送信された架空の接続イベントがInstantより前に表示されています。図5.2および図5.3において、Instantから新しい接続パラメータで送信された最初の接続イベントの開始までの時間間隔Δtは、次の式を用いて計算することができる。 Δt = (connIntervalNEW - ((Instant - ReferenceConnEventCount) * connIntervalOLD) % connIntervalNEW + offset0) % connIntervalNEW 注：ReferenceConnEventCountとInstantがeventCountのラップアラウンドポイントの異なる側にある場合は、上の式には示されていません。計算されたΔtに基づいて、LL_CONNECTION_UPDATE_IND PDUのWinOffsetフィールドとWinSizeフィールドは、それに応じて設定することができる。例については5.1.7.3.3項を参照のこと。

5.1.7.3.3 スレーブ開始間隔とアンカーポイント移動

以下の例では、スレーブのリンク層が接続間隔の変更（PreferredPeriodicity と connIntervalOLD が互いに整数倍にならないように PreferredPeriodicity を指定して）と LE 接続のアンカーポイントの変更を ReferenceConnEventCount に対して 3.75ms ずつ要求していることを示しています。この例では、connIntervalOLDは0x0C（15ms）です。スレーブのリンク層は、以下のパラメータを持つ LL_CONNECTION_PARAM_REQ PDU を発行する。

Interval_Min. 0x16
インターバル_最大値: 0x20
レイテンシ: connSlaveLatency
タイムアウト: connSupervisionTimeout
PreferredPeriodicity: 0x0A
ReferenceConnEventCount. 0x1F00
オフセット0. 0x0003
オフセット1：0xFFFF
オフセット2：0xFFFF
オフセット3：0xFFFF
オフセット4：0xFFFF
オフセット5：0xFFFF マスタのリンク層は、スレーブからの要求を受け付けると、以下のパラメータセットのいずれかを含む LL_CONNECTION_UPDATE_IND PDU で応答する。全てのセットにおいて、新しい接続間隔connIntervalNEWは0x1E（37.5ms）に設定され、LatencyはconnSlaveLatencyに設定され、TimeoutはconnSupervisionTimeoutに設定され、Instantは0x1F06に設定される。 5.1.7.3.2項で説明したΔtは21(26.25ms)として計算されます。 LL_CONNECTION_UPDATE_INDのWinSizeとWinOffsetフィールドは PDUは、以下のパラメータセットの例のいずれかを含むことができます。
オプション１：マスタによって瞬間の後に送信される最初のパケットは、送信ウィンドウの内側であり、送信ウィンドウの開始から3.75 msの間にある。
3≤WinSize≤8 - WinOffset: 18
オプション２：マスターがインスタント後に送信した最初のパケットが送信ウィンドウ内にあり、送信ウィンドウの先頭から２．
2≤WinSize≤8 - WinOffset: 19
オプション３：マスターがインスタント後に送信した最初のパケットは、送信ウィンドウ内にあり、送信ウィンドウの先頭から1.25msの位置にあります。
1≤WinSize≤8 - WinOffset: 20
オプション4: マスタがインスタント後に送信する最初のパケットは、送信ウィンドウ内にあり、送信ウィンドウの先頭から0msの位置にあります。
1≤WinSize≤8 - WinOffset: 21

5.1.7.4 パケット送信時間の制限

この節は、現在の PHY が LE 符号化 PHY であり、コントローラが LE データパケット長拡張機能をサポートしている場合にのみ適用される。接続間隔を減少させるLL_CONNECTION_UPDATE_IND PDUを送受信した後、瞬間に到達するまで、リンク層は、瞬間後に適用される接続間隔を用いて計算された、送信に要する時間がconnEffectiveMaxTxTimeマイクロ秒（4.5.10項参照）よりも長くなるようなパケットを送信してはならない。スレーブがLL_CONNECTION_PARAM_REQ又はLL_CONNECTION_PARAM_RSP PDUを送信した後、Interval_Minが現在の接続間隔よりも短い間隔を示すLL_CONNECTION_UPDATE_INDを受信するまでは、LL_UNKNOWN_RSPを送信する。又はLL_REJECT_EXT_IND PDUに応答して、そのリンク層は、送信されたPDUのInterval_Min値に対応する接続間隔を用いて計算されたconnEffectiveMaxTxTimeマイクロ秒よりも長い時間を要するパケットを送信してはならない。手続き中にconnEffectiveMaxTxTimeの値が変更された場合、上記の要件は、LLデータPDUが送信のためにキューに入れられた瞬間の値に適用される。注：この節の要求事項は、4.5.10節の要求事項に追加されるものであり、これを上書きするものではない。注：リンク層が手順の開始時に送信用にキューイングされた LL データ PDU を持つ場合、あるいは手順中にキューイングされた LL データ PDU を持つ場合には、これらの要求事項を満たすためにそれらの PDU を再フラグメント化する必要があるかもしれない。

5.1.8 LE Ping 手続

LE Ping プロシージャは、サポートされている場合、リモート・リンク・レイヤーの存在を検証するためにリンク・レイヤーで使用することができます。また、この手順は、有効な MIC を含む LE ACL パケットをリモート・デバイスに送信させることにより、LE ACL 論理トランスポート上のメッセージの整合性を検証するためにも使用することができます。マスタまたはスレーブ・リンク・レイヤーのいずれかは、LL_PING_REQ PDU を送信することにより、接続状態に入った後、いつでもこの手順を開始することができます。応答するリンク層は、LL_PING_RSP PDUで応答する。この機能をサポートするリンク層は、ホストが設定した認証済みペイロードタイムアウト（[Vol.2] Part E 7.3.94 節）内に、リモートデバイスが MIC で保護されたペイロードを含むパケットを送信していない場合に LL_PING_REQ PDU を送信する。リンク層は、認証済みペイロードのタイムアウトが切れる前に、リモートデバイスがLL_PING_RSP PDUで応答するのに十分な時間を確保するために、十分に前もってLL_PING_REQ PDUを送信する。この手順は、LL_PING_RSP を受信した場合、またはリモートデバイスが LE Ping 機能をサポートしていない場合、Unknown タイプが LL_PING_REQ に設定された LL_UNKNOWN_RSP を受信した場合に完了する。

5.1.9 データ長更新手順

コントローラは、データ長更新手順を使用して、現在の最大受信LLデータPDUペイロード長とPDU時間（connMaxRxOctetsとconnMaxRxTime）の最新値と、現在の最大送信LLデータPDUペイロード長とPDU時間（connMaxTxOctetsとconnMaxTxTime）の最新値を相手デバイスに送信します。マスタ及びスレーブの両方は、LL_LENGTH_REQ PDUを送信することにより、接続状態に入った後、いつでもこの手順を開始することができる。この手順は、ホストからの要求であっても、リンクレイヤからの自律的な要求であっても、これらのパラメータのいずれかが変更された場合には、リンクレイヤによって開始される。ただし、既にリモートコントローラからの応答がない場合には、新たなプロシジャーを起動するのではなく、その応答を用いて変更内容の伝達を行う。リンク層は、LL_LENGTH_REQ PDU に対する応答である LL_LENGTH_REQ PDU または LL_LENGTH_RSP PDU を受信した場合には、その PDU に含まれる値で接続のための connRemoteMaxTxOctets、connRemoteMaxRxOctets、connRemoteMaxTxTime、および connRemoteMaxRxTime のパラメータを更新しなければならない。それは、送信のためにキューイングされたすべての新しいLLデータPDU（次のパラグラフで指定された応答を含む）に対して、更新された値の使用を直ちに開始しなければならない。既に送信キューに入っている、または一度以上送信されている LL データ PDU の長さは変更しない。注：リンクレイヤPDUはリアルタイムで処理される必要がないため、ローカルコントローラが相手デバイスからLL_LENGTH_REQ PDUを受信したときに、キューに入っているがまだ送信されていないLL_LENGTH_REQ PDUが存在する可能性がある。この状況では、各デバイスは通常通りに応答し、結果として生じる衝突は無害である。 LL_LENGTH_REQ PDUを受信すると、リンク層は、接続に対する自身のconnMaxTxOctets、connMaxRxOctets、connMaxTxTime、及びconnMaxRxTimeの値を含むLL_LENGTH_RSP PDUで応答しなければならない（リモートデバイスがより長いパケットを送信できるようにするためなど、受信した値に基づいて更新した可能性がある）。ピアデバイスがLE Coded PHY機能をサポートしない場合、LL_LENGTH_REQ及びLL_LENGTH_RSP PDUのMaxRxTime及びMaxTxTimeフィールドは、2120マイクロ秒以下の値に設定されなければならない。マスタまたはスレーブのリンク層が、そのPDUを理解していないデバイスにLL_LENGTH_REQ PDUを送信した場合、そのデバイスは、応答としてLL_UNKNOWN_RSP PDUを期待しなければならない。この手順は、開始コントローラが LL_LENGTH_RSP PDU、またはリモートデバイスが LE データパケット長拡張機能をサポートしていない場合には、Unknown タイプが LL_LENGTH_REQ に設定された LL_UNKNOWN_RSP PDU のいずれかを受信したときに完了する。

5.1.10 PHY 更新手順

PHY 更新手続きは、サポートされている場合には、送信または受信 PHY、またはその両方を変更するために使用される。この手順は、ホストからの要求に応じて、またはリンク層からの自律的な要求に応じて開始することができる。マスタまたはスレーブのいずれかが、接続状態に入った後、いつでもこの手続きを開始することができる。リンク層の PHY 設定は、接続中や接続間で変更される可能性があるため、ピアデバイスによってキャッシュされるべきではない。この手続きがマスタによって開始されると、マスタは LL_PHY_REQ PDU を送信する。スレーブは、LL_PHY_RSP PDUで応答する。その後、マスタはこれにLL_PHY_UPDATE_IND PDUで応答します。このプロシージャがスレーブによって開始されると、スレーブはLL_PHY_REQ PDUを送信する。マスタはLL_PHY_UPDATE_IND PDUで応答する。 LL_PHY_REQ 及び LL_PHY_RSP PDU の TX_PHYS 及び RX_PHYS フィールドは、送信リンク層が使用する PHY を示すために使用される。もし送信側が対称接続(二つの PHY が同じである接続)を望むならば、両方のフィールドを同じにして、一つの PHY のみを指定すべきである。 LL_PHY_UPDATE_IND PDU の M_TO_S_PHY と S_TO_M_PHY フィールドは、その瞬間以降に使用される PHY を示す。マスタが手続きを開始した場合、以下のルールを用いて、LL_PHY_REQ PDU と LL_PHY_RSP PDU の内容に基づいて、各方向で使用する PHY を決定する。

LL_PHY_UPDATE_IND PDU の M_TO_S_PHY フィールドは、マスタの TX_PHYS フィールドとスレーブの RX_PHYS フィールドから決定される。
LL_PHY_UPDATE_IND PDU の S_TO_M_PHY フィールドは、マスタの RX_PHYS フィールドとスレーブの TX_PHYS フィールドから決定されなければならない。これらの各ケースでは、以下のルールが適用される。
少なくとも一つの PHY について、対応するビットが TX_PHYS と RX_PHYS フィールドの両方で 1 に設定されている場合、マスタは、その方向の PHY のうちの一つを選択する。
TX_PHYS と RX_PHYS フィールドの両方で対応するビットが 1 に設定されている PHY がない場合、マスタはその方向の PHY を変更してはならない。スレーブが手続きを開始した場合、マスタは、以下のルールを用いてスレーブから送信された LL_PHY_REQ PDU の内容に基づいて、各方向で使用する PHY を決定する。
LL_PHY_UPDATE_IND PDU の M_TO_S_PHY フィールドは、スレーブの PDU の RX_PHYS フィールドから決定される。
LL_PHY_UPDATE_IND PDUのS_TO_M_PHYフィールドは、スレーブのPDUのTX_PHYSフィールドから決定されなければならない。これらの各ケースでは、以下のルールが適用される。
少なくとも一つの PHY について、マスターが使用したい PHY であり、スレーブの PDU の関連フィールドに対応するビットが 1 に設定されている場合、マスターは、その方向の PHY のうちの一つを選択する。
マスターが使用したい PHY がなく、スレーブの PDU の関連フィールドに対応するビットが 1 に設定されている場合、マスターはその方向の PHY を変更してはならない。この節の残りの部分は、どのデバイスが手続きを開始したかに関係なく適用される。上記の規則に関係なく、マスタは両方の方向を変更しないでよい。スレーブがＴＸ＿ＰＨＹＳフィールド及びＲＸ＿ＰＨＹＳフィールドの両方で単一のＰＨＹを指定し、両方のフィールドが同じである場合、マスタは、両方向についてスレーブによって指定されたＰＨＹを選択するか、又は両方向を変更しないままにしておかなければならない。どちらかのPHYが変更される場合は、第5.5項をLL_PHY_UPDATE_IND PDUに適用する。両方のデバイスは、その瞬間から新しい PHY を使用する。マスタまたはスレーブが、その PDU を理解していないデバイスに LL_PHY_REQ PDU を送信する場合、受信デバイスは応答として LL_UNKNOWN_RSP PDU を送信しなければならない。この手順は，次の場合に完了する。
LL_UNKNOWN_RSPまたはLL_REJECT_EXT_IND PDUが送受信されたとき。
どちらのPHYも変更しないことを示すLL_PHY_UPDATE_IND PDUが送信されたか受信されたか。
の場合、マスタは、少なくとも 1 つの PHY が変更され、その瞬間に到達したことを示す LL_PHY_UPDATE_IND PDU を送信する。この場合、マスタがその PDU を送信した時点でプロシージャ応答タイムアウトを停止し、スレーブがその PDU を受信した時点でプロシージャ応答タイムアウトを停止する。コントローラは、ＰＨＹ更新手続きが完了したときに、片方または両方のＰＨＹの変更をもたらした場合、またはホストからの要求によって手続きが開始された場合には、現在有効なＰＨＹをホストに通知する。それ以外の場合は、ホストにその手続きが行われたことを通知しないものとする。

5.1.10.1 パケット送信時間の制限

いずれかのPHYを変更するLL_PHY_UPDATE_IND PDUを送受信した後、瞬間に到達するまで、リンク層は、瞬間の後に適用されるPHY上で送信するために、connEffectiveMaxTxTimeマイクロ秒(4.5.10項参照)よりも長い時間を要するパケットを送信してはならない。スレーブがLL_PHY_REQ PDUを送信した後、応答としてLL_PHY_UPDATE_IND、LL_UNKNOWN_RSP、またはLL_REJECT_EXT_IND PDUを受信するまで、そのリンク層は、そのLL_PHY_REQ PDUのTX_PHYSフィールドに現れたPHY上で送信するのにconnEffectiveMaxTxTimeマイクロ秒よりも長くかかるであろうパケットを送信してはならない。スレーブがPHY更新手順に応答した場合、LL_PHY_RSP PDUを送信した時に始まり、応答としてLL_PHY_UPDATE_IND PDUを受信した時に終了する期間の間、スレーブは、PHY更新手順に応答する。スレーブのリンク層は、その LL_PHY_RSP PDU の TX_PHYS フィールドとマスタの LL_PHY_REQ PDU の RX_PHYS フィールドの両方に現れる PHY 上で、送信に connEffectiveMaxTxTime マイクロ秒よりも長い時間を要するパケットを送信してはならない。 connEffectiveMaxTxTimeの値が手順中に変更された場合、上記の要件は、LLデータPDUが送信のためにキューに入れられた瞬間の値に適用される。注：この節の要求事項は、4.5.10節の要求事項に追加されるものであり、これを上書きするものではない。備考：リンク層が、手順の開始時に送信用の LL データ PDU をキューに入れていたり、手順中にキューに入れていたりする場合には、これらの要求事項に従うために、それらの PDU を再フラグメント化する必要がある場合がある。

5.1.11 最小使用チャネル数の手順

コントローラは、最小使用チャネル数プロシージャを使用して、ピアデバイスが指定された PHY で最小のチャネル数を使用するように要求する。スレーブは、接続状態に入った後、LL_MIN_USED_CHANNELS_IND PDU を送信することで、いつでもこの手続きを開始することができる。マスタはこの PDU を送信してはならない。リンク層が LL_MIN_USED_CHANNELS_IND PDU を受信した場合には、スレーブ-マスタ間の PHY が指定されたものである場合には、その接続が PDU の MinUsedChannels フィールドで指定されたチャネル数以上のチャネルを使用することを確認する。この処理は、LL_MIN_USED_CHANNELS_IND PDU のリンクレイヤ確認応答が送信または受信された時点で完了する。チャンネルマップにスレーブが規制に準拠するために必要な最小チャンネル数が含まれていない場合、スレーブは規制に準拠した状態を維持するための手順を取らなければならず、これにはリンクの切断または出力電力の低減が含まれる。

5.1.12 定音拡張要求手順

一定音拡張要求手順は、サポートされている場合、リモートリンク層に LL_CTE_RSP PDU と一定音拡張（2.5.3 節参照）を含むパケットの送信を要求するために使用されます。マスタまたはスレーブリンク層は、接続状態に入った後、LL_CTE_REQ PDUを送信することで、いつでもこの手続きを開始することができます。もし、以下の場合。

一定トーン拡張応答が有効である。
現在の送信機 PHY が一定トーン拡張を許可する PHY である。
LL_CTE_REQ PDU で要求された一定音拡張の長さが、応答するデバイスがサポートしている最大の長さを超えていない。
応答するデバイスは、現在、LL_CTE_REQ PDU で要求されたタイプの定音拡張で応答するように設定されている。その場合、リモートリンク層は、要求されたタイプの一定音拡張を含み、その長さが要求された長さ以上である LL_CTE_RSP PDU で応答しなければならない。それ以外の場合、リモートリンク層は LL_REJECT_EXT_IND PDU で応答する。定音拡張応答が無効化されているか、リンク層が要求された定音拡張のタイプ及び長さで応答するように設定されていない場合、ErrorCodeは、Unsupported LMP Parameter Value/Unsupported LL Parameter Value (0x20)に設定する。また、現在の送信機 PHY 上でコンスタントトーン拡張が許可されていない場合には、ErrorCode を「無効な LMP パラメータ／無効な LL パラメータ（0x1E）」とする。 LL_CTE_RSP PDU のコンスタントトーン拡張を受信している間に IQ サンプリング（[Vol.6]パート B 2.5.4 節参照）を行い、そのサンプリング結果をホストに報告する。マスタまたはスレーブのリンク層が、そのPDUを理解していない装置にLL_CTE_REQ PDUを送信した場合、その装置は応答としてLL_UNKNOWN_RSP PDUを期待する。この手順は、LL_CTE_REQにUnknownTypeまたはRejectOpcode（適宜）が設定された状態で、LL_CTE_RSP PDUが送受信されたか、またはLL_UNKNOWN_RSPまたはLL_REJECT_EXT_IND PDUが送受信された場合に完了する。

5.1.13 定期広告同期転送手順

コントローラは、定期広告同期転送手順を使用して、定期広告列車（4.4.3.4 節参照）に同期するために必要な同期情報を、接続されたピアデバイスに転送します。マスタまたはスレーブリンク層は、接続状態に入った後、LL_PERIODIC_SYNC_IND PDU を送信することにより、いつでもこの手順を開始することができます。ホストが転送の受信を有効にしている場合、リンク層がまだ同期していない周期的な広告列車を記述した LL_PERIODIC_SYNC_IND PDU を受信した場合、リンク層は、記述された周期的な広告列車に同期してホストに通知し、同期に失敗した場合はホストに通知する。この手順は、LL_PERIODIC_SYNC_IND PDU を送受信した時点で終了する。

5.1.13.1 タイミングの考慮事項

このセクションでは、3 つの別々のデバイスクロックの相対的なドリフトを処理する際の問題点について説明します。このセクションは、デバイスAとデバイスBが同じである場合には、2つの間にクロックドリフトがないため、適用されません。一般的に、周期的広告同期転送手順には、周期的広告主A、開始デバイスB、受信デバイスCの3つのデバイスが関与しています。したがって、デバイスＣは、周期広告に同期するためのタイミングおよび必要な受信ウィンドウを決定するための様々なステップを実行する必要がある。以下の式および図５．

内のSyncInfoに格納されているpaEventCounterの値をPEaとする。 LL_PERIODIC_SYNC_IND PDUです。
PEbは、デバイスBが受信した最近のAUX_SYNC_IND PDUのpaEventCounterの値であり、この値はLL_PERIODIC_SYNC_IND PDUのlastPaEventCounterフィールドに格納されます。
PEcは、デバイスCが受信しようとしているAUX_SYNC_IND PDUのpaEventCounterの値です。注意：PEcは、PEaの前、後、またはPEaと同じにすることができます。
のIntervalフィールドで表される周期的な広告間隔です。は、LL_PERIODIC_SYNC_IND PDU内のSyncInfoの値である。
CEsは、デバイスBとCがそれらのアンカーポイントを同期させ、そのデバイスBがLL_PERIODIC_SYNC_IND PDUのコンテンツを決定するために使用したときの接続イベントに対するconnEventCounterの値であり、この値はPDUのsyncConnEventCountフィールドに格納される。
CEtは、LL_PERIODIC_SYNC_IND PDUがデバイスBによって（再）送信され、デバイスCによって受信されたときの接続イベントのconnEventCounterの値である。
CErefは、LL_PERIODIC_SYNC_IND PDU内のconnEventCountの値である。
CEcは、デバイスＣが受信しようとしているAUX_SYNC_IND PDUの前の接続イベントである。
ＣＩは、デバイスＢとデバイスＣの間の接続のための接続間隔である。
Offset は、デバイス B と C の間の接続のための接続間隔です。 LL_PERIODIC_SYNC_IND PDU。
ターゲットは、接続イベントCEcのアンカーポイントからデバイスCが受信しようとしているAUX_SYNC_IND PDUまでの時間である。
CAa、CAb、およびCAcはそれぞれデバイスA、B、およびCのクロック精度である。CAaはLL_PERIODIC_SYNC_IND PDU内のSyncInfoのSCAフィールドに、CAbはLL_PERIODIC_SYNC_IND PDUのSCAフィールドに格納されます。 3つのデバイスすべてが完全に正確なクロックを持っていたとすると Tnominal ≤ Target < Tnominal + U どこで。デバイスCの接続Ｔｎｏｍｉｎａｌ＝（ＣＥｒｅｆ-ＣＥｃ）×ＣＩ＋オフセット-（ＰＥａ-ＰＥｃ）×ＰＡＩのオフセット単位フィールドの値に応じて、U = 30 μs または 300 μs となります。同期情報クロックドリフトとジッタのため、これは次のようになります。 Tnominal - D - 16μs ≤ Target < Tnominal + U + D + 16μs ここで。 D = (Da + Db) x (1 + CAa + CAb + CAc) Ｄａは定期広告のドリフトを表し、ＤｂはＢの時計のドリフトを表す CEsとPEbの間にある。 Da = |PEc - PEb| × PAI × (CAa + CAc) Db = |CEt - CEs| × CI × (CAb + CAc) Dは、上の次の全マイクロ秒に丸められなければなりません。これらの値がどのように導出されるかを確認するために、デバイスBは次のように計算されていることに注意してください。自身のクロックのドリフトを一切考慮せずにオフセットする。したがって、時刻ＴＰＥｂにＰＥｂが発生し、時刻ＴＣＥｓにＣＥｓが発生した場合、両方ともそれ自身のクロックに従って、デバイスＢははPEaとCErefの値を選択して計算しています。オフセット＝（ＴＰＥｂ＋（ＰＥａ-ＰＥｂ）×ＰＡＩ）-（ＴＣＥｓ＋（ＣＥｒｅｆ-ＣＥｓ）×ＣＩデバイスCがTnominalを計算するとき、ドリフトを考慮せずに計算します。そこで、上記のオフセットの式を上記のTnominalの式に代入すると、次のようになります。 Tnominal = ＣＥｒｅｆ-ＣＥｃ）×ＣＩ＋（ＴＰＥｂ＋（ＰＥａ-ＰＥｂ）×ＰＡＩ）-（ＴＣＥｓ＋（ＣＥｒｅｆ-ＣＥｓ）×ＣＩ）-（ＰＥａ-ＰＥｃ）×ＰＡＩ = ＴＰＥｂ＋（ＰＥａ-ＰＥｂ）×ＰＡＩ-（ＰＥａ-ＰＥｃ）×ＰＡＩ-ＴＣＥｓ-（ＣＥｒｅｆ-ＣＥｓ）×ＣＩ＋（ＣＥｒｅｆ-ＣＥｃ）×ＣＩ = ＴＰＥｂ＋（ＰＥｃ-ＰＥｂ）×ＰＡＩ-ＴＣＥｓ-（ＣＥｃ-ＣＥｓ）×ＣＩ＝（ＰＥｃ-ＰＥｂ）×ＰＡＩ＋（ＴＰＥｂ-ＴＣＥｓ）-（ＣＥｃ-ＣＥｓ）×ＣＩこれらの3つの項のそれぞれは、異なるクロックに基づいています。
第１項は、デバイスＡのクロックを使用して測定されるＰＡＩに依存する。しかし、デバイスCはTnominalを計算しているので、デバイスCのクロックも考慮しなければなりません。この項のドリフトはDaで表されます。
式(TPEb - TCEs)は、2 つのイベント間の B のクロックの変化であり、そのクロックを使用して測定されますが、ここでもデバイス C のクロックを考慮する必要があります。この項のドリフトはDbで表されます（Dbの式の括弧内の項は差の上限であることに注意してください）。
最後の項はデバイスCのクロック上にあるため、調整は必要ありません。 D の式の 2 番目の係数は 2 次の効果を許容します。関連する周期イベントが 12 秒間隔である場合、500 ppm のドリフトは、必要なウィンドウで 20 × 0.00052 = 3 μs の残留誤差をもたらします。デバイス C がこれらの計算を行う際にクロックドリフトを許容している場合、それに応じて使用するウィンドウを減らすことができるかもしれません。デバイスBがクロックドリフトを許容している場合(例えば、周期的な広告タイミングのドリフトを測定することによって)、実際のドリフトは上記で計算されたものよりも小さくなりますが、デバイスCはこのことに気づかないでしょう。

5.1.14 スリープクロック精度更新手順

リンク層は、相手のスリープクロック精度（masterSCA または slaveSCA-セクション 4.2.2.2 参照）の変更を相手に通知したり、LL_CLOCK_ACCURACY_REQ PDU を送信して相手のスリープクロック精度を問い合わせたりすることができる。デバイスは、この手順を１秒に１回以上開始してはならない。リンク層が現在使用しているクロックよりも精度の高いクロックを指定する場合、リンク層はこの手順を開始したり応答したりする前に、そのクロックに切り替えなければならない。リンク層は、「LL_CLOCK_ACCURACY_REQ」PDU を受信した場合、「LL_CLOCK_ACCURACY_RSP」PDU を返信する。この応答に指定されたスリープクロック精度は、当該応答を送信するリンク層で現在使用されている値を下回ってはならない。注：リンク層は、精度の変更に必要な内部調整を行うために応答を遅延させることができるが、タイムアウトを発生させるほど長くは応答を遅延させない。応答する機器が精度の低いクロックへの変更を希望する場合は、別途この処理を行う必要がある。この手順は、LL_CLOCK_ACCURACY_RSP または LL_UNKNOWN_RSP を送受信した時点で完了する。発信側リンク層が現在使用しているクロックよりも精度の低いクロックを指定した場合は、返信用の LL_CLOCK_ACCURACY_RSP PDU を受信するまでは、そのクロックに切り替えてはならない。LL_UNKNOWN_RSP PDUを受信した場合は、少なくとも接続を作成したCONNECT_IND PDU又はAUX_CONNECT_REQ PDUで指定された精度を維持しなければならない。

5.2 プロセス応答タイムアウト

本節では、5.1 節で規定したリンクレイヤ制御手順のうち、タイムアウトルールのない「接続更新」及び「チャネルマップ更新」を除くすべてのリンクレイヤ制御手順に適用されるタイムアウトルールを規定する。マスタ及びスレーブは、応答のないリンク層制御手順を検出できるように、手順応答タイムアウトタイマ TPRT を使用する。手続きが開始されると、手続き応答タイムアウトタイマはリセットされ、開始されなければならない。送信用にキューイングされた各LL制御PDUは、プロシージャ応答タイムアウトタイマをリセットする。手続きが完了すると、手続き応答タイムアウトタイマを停止する。手続き応答タイムアウトタイマが 40 秒に達した場合は、接続が失われたものとみなす。リンク層は接続状態を終了し、待機状態に移行する。ホストには、接続が失われたことを通知する。

5.3 プロシージャ通信

LL制御PDUはリアルタイムで解釈されないため、マスターのリンク層とスレーブのリンク層が互換性のないプロシージャを開始した場合に衝突が発生する可能性がある。2つの手順は、両方とも瞬間を含む場合、互換性がない。このような場合には、本節のルールに従うこと。デバイスは、非互換プロシージャを開始したPDUに応答した後、そのプロシージャが完了するまでプロシージャを開始してはならない。デバイスがプロシージャAを開始し、そのプロシージャが完了していない間に、互換性のないプロシージャBを開始したPDUをピアから受信した場合。

ピアがプロシージャＡの一部として少なくとも１つのＰＤＵを既に送信している場合、デバイスは直ちに接続状態を終了し、スタンバイ状態に遷移する。
そうでなければ、デバイスがマスタである場合、それは、ＬＬ＿ＲＥＪＥＣＴ＿ＥＸＴ＿ＩＮＤ（両方のデバイスによってサポートされている場合）またはＬＬ＿ＲＥＪＥＣＴ＿ＩＮＤ（そうでなければ）ＰＤＵを発行することによって、スレーブから受信したＰＤＵを拒否しなければならない。その後、手順Aに進むものとする。
そうでない場合（デバイスがスレーブである場合）は、マスターからの拒絶を処理する以外は、マスターから開始された手順Ｂの処理に進み、スレーブから開始された手順Ａでは、それ以上の行動を取らないものとする。ホストは、リンクが切断されたことを通知されなければならない、または拒絶PDUは、（適切な）を使用しなければならない。
プロシージャAとプロシージャBが同じプロシージャの場合は、エラーコードLMP Error Transaction Collision / LL Procedure Collision (0x23)。
手順Aが接続更新手順であり、手順Bが接続パラメータ要求手順である場合、エラーコードLMP Error Transaction Collision / LL Procedure Collision (0x23)。
それ以外の場合は、エラーコード Different Transaction Collision (0x2A)。

5.4 LE AUTHENTICATED PAYLOAD TIMEOUT

LE Authenticated PayloadTimeout（authenticatedPayloadTO）は、有効な MIC を含むパケットを受信するまでの最大時間をミリ秒単位で定義するパラメータであり、ホストは HCI_Write_Authenticated_Payload_Timeout コマンド（[Vol.2] Part E 7.3.94 節）を用いて値を変更することができる。ホストは、HCI_Write_Authenticated_Payload_Timeout コマンド（[Vol 2] Part E 7.3.94）を使用して authenticatedPayloadTO の値を変更することができます。authenticatedPayloadTOのデフォルト値は30秒です。接続が暗号化されている場合、LE Ping 機能をサポートするデバイスは、リモートデバイスから有効な MIC を含むパケットを最後に受信してからの時間を監視するために、LE Authenticated Payload タイマー TLE_Authenticated_Payload を起動するものとする。各デバイスは、有効な MIC を含むパケットの受信時にタイマー TLE_Authenticated_Payload をリセットする。 CONNECTION 状態でタイマ TLE_Authenticated_Payload が authenticatedPayloadTO 値に達した場合、ホストは HCI_Authenticated_Payload_Timeout_Expired イベント（[Vol 2] Part E、セクション 7.7.7.75）を使用して通知される。TLE_Authenticated_Payload タイマーは、期限切れ後に再起動する。タイマー TLE_Authenticated_Payload は、暗号化一時停止手順の間、実行し続けるものとする。タイマー TLE_Authenticated_Payload が実行中にホストが authenticatedPayloadTO を設定した場合はいつでも、タイマーはリセットされるものとする。

5.5 インスタントを使用した手続き

プロシージャがInstantフィールドを持つPDUを含む場合、以下の規則が適用される。 Instantフィールドは、関連する変更が適用されなければならないときのconnEventCountを示すために使用されなければならない。マスタは、スレーブがconnSlaveLatencyイベントごとに1回しか聞いていない可能性があることを考慮して、インスタントが発生する前にスレーブが聞いているであろう接続イベントを最低6個許可することが望ましい。スレーブが、(Instant - connEventCount) modulo 65536が32767より小さく、InstantがconnEventCountに等しくないそのようなPDUを受信した場合、スレーブは、マスタがPDUの確認応答を受信したことを確認するまで、またはconnEventCountがInstantに等しくなるまで、すべての接続イベントをリッスンしなければならない。スレーブは、(Instant - connEventCount) modulo 65536が32767以上であるこのようなPDUを受信した場合(インスタントが過去のものであるため)、以下の処理を行う。

PDU が LL_CONNECTION_UPDATE_IND である場合、スレーブのリンク層は、接続が失われたとみなす。
PDU が LL_CONNECTION_UPDATE_IND の場合、スレーブ側リンク層は接続が失われたとみなす。接続が失われたと判断した場合、スレーブのリンク層は接続状態を終了し、スタンバイ状態に移行し、エラーコード Instant Passed(0x28)を用いてホストに通知する。注：connEventCountと受信したInstantフィールドの比較は、connEventCountフィールドがラップした状況を処理するために、モジュロ65536数学を使用して実行されます（0から65535までの値のみが許可されます）。