9 OPERATIONAL MODES AND PROCEDURES – LE PHYSICAL TRANSPORT

LE 物理的トランスポート上では、いくつかの異なるモード及び手続きが同時に実行されることがある。 以下のモード及び手順は、LE 物理トランスポート上で使用するために定義される。

• ブロードキャスト・モード及び観測手順
• ディスカバリーモードと手順
• 接続モードと手順
• ボンディングモードと手順
• 定期的な広告モードと手順 上記の各モードおよび手順は、互いに独立しているが、ほとんどのデバイスが互いに通信するためには、モードおよび手順の組み合わせが必要であるので、密接に関連している。 モードと手順の両方とも、ユーザの直接的な行動の結果として、またはデバイスによって自律的に、それぞれ入力または実行されてもよい。

ホストは、上記のモード及び手順のいずれかを実行する前に、[Vol.6]Part B 4.6 節で定義されたローカルリンクレイヤの機能情報を用いて、コントローラを構成しなければならない。

これらのモードおよび手順で使用される広告の種類は、関連する GAP ロールのそれぞれについて、2.2.2.2 表 2.1 に定義する。

9.1 BROADCAST MODE AND OBSERVATION PROCEDURE

ブロードキャストモードと観測手順は、2 つのデバイスが広告イベントを使用して一方向コネクションレスで通信することを可能にします。 ブロードキャストモードと観測手順をサポートするために、特定のGAPロールで動作するデバイスの要件は、表9.1に定義されています。

-- Table 9.1: Broadcast mode and observation procedure requirements --

9.1.1 Broadcast mode

9.1.1.1 Definition

ブロードキャストモードは、デバイスが広告イベントでコネクションレスデータを送信するための方法を提供する。

9.1.1.2 Conditions

ブロードキャストモードのデバイスは、非接続可能な広告イベントを使用してデータを送信しなければならない。

ブロードキャストモードの装置は、ブロードキャスタのアドレスを除外して、非接続型で非走査型の無向広告イベント、または非接続型で非走査型の有向広告イベントを匿名で送信することができる。

広告データは、[Core Specification Supplement]パートA、セクション1.3で定義されているAdvertising Data (AD)タイプのフォーマットを使用してフォーマットされなければならない。 ブロードキャストモードの機器は、「Core Specification Supplement」パートAの1.3節に規定する「Flags AD Type」に「LE General Discoverable Mode」フラグ又は「LE Limited Discoverable Mode」フラグを設定してはならない。

注：ブロードキャスト・モードでデバイスによって送信されたすべてのデータは、データを受信した可能性のあるデバイスからの確認応答がないため、信頼性がないと考えられます。

デバイスは、複数の独立した広告セットを構成し、有効にすることができます。 各広告セットは、独立した広告フィルタポリシーを有してもよい。

9.1.2 Observation procedure

9.1.2.1 Definition

観測手順は、広告イベントを送信している装置からコネクションレスデータを受信するための方法を提供する。

9.1.2.2 Conditions

観測手順を実行するデバイスは、広告イベントを受信するために、パッシブ走査またはアクティブ走査を使用することができる。

Observation手順を実行するデバイスは、スキャン可能な広告イベントを使用して広告を行うブロードキャスト・モードのデバイスによって送信されたスキャン応答データを受信するために、アクティブ・スキャンを使用してもよい。

観察手順を実行するデバイスが広告イベントで解決可能なプライベートアドレスを受信した場合、デバイスは、10.8.2.3項で定義されている解決可能なプライベートアドレス解決手順を使用して、プライベートアドレスを解決してもよい。

注：ブロードキャストモードのデバイスがダイナミックデータを送信する使用例では、受信デバイスは、ホストがコントローラによって受信されたすべての広告パケットを受信するように、コントローラの重複フィルタリング機能を無効にする必要があります。

9.2 DISCOVERY MODES AND PROCEDURES

すべてのデバイスは、非発見可能モードまたは発見可能モードのいずれかでなければならない。 発見可能モードのデバイスは、一般発見可能モードまたは限定発見可能モードのいずれかであること。 非発見可能モードのデバイスは、発見可能ではない。 一般発見可能モードまたは限定発見可能モードのいずれかで動作しているデバイスは、発見したデバイスによって発見される。 他のデバイスを発見しているデバイスは、セクション9.2.5に定義されている限定発見手順またはセクション9.2.6に定義されている一般発見手順のいずれかを実行します。

一部のデバイスは、レガシー広告PDUを使用して広告イベントのみをスキャンする場合があります。 そのため、拡張広告PDUを使用する広告イベントを使用するデバイスは、レガシー広告PDUを使用する広告イベントを使用する広告セットも使用することが推奨されます。

9.2.1 Requirements

-- Table 9.2: Device Discovery requirements --

9.2.2 Non-discoverable mode

9.2.2.1 Description

非発見可能モードに設定されたデバイスは、一般的な発見手順または限定的な発見手順のいずれかを実行しているデバイスによって発見されることはない。

9.2.2.2 Conditions

非発見可能モードの装置は、広告イベントを送信してもよい。 デバイスが広告イベントを送信する場合は、フラグADタイプ（[Core Specification Supplement]パートAの1.3節参照）に「LE General Discoverable Mode」フラグ又は「LE Limited Discoverable Mode」フラグを設定してはならない。

デバイスが広告イベントを送信する場合、ホストは以下のようにコントローラを構成することを推奨します。

• ホストは、すべての広告セットの広告フィルタポリシーを「ホワイトリストのデバイスからのみスキャンと接続要求を処理する」または「すべてのデバイスからスキャンと接続要求を処理する」のいずれかに設定する必要があります。

• ホストは、9.3.11項で定義されているように広告間隔を設定する必要があります。

9.2.3 Limited Discoverable mode

9.2.3.1 Description

限定的発見可能モードで構成されたデバイスは、限定的または一般的なデバイス発見手順を実行する他のデバイスによって、限られた期間だけ発見可能である。 限定発見可能モードは、通常、ユーザーが特定のアクションを実行して、限られた期間だけデバイスを発見可能にする場合に使用されます。

9.2.3.2 Conditions

デバイスがペリフェラルな役割にある間は、デバイスは限定的な検出可能モードをサポートすることができる。 デバイスがブロードキャスタ、オブザーバ、またはセントラルの役割のみにある間、デバイスは限定発見可能モードをサポートしてはならない。

限定発見可能モードのデバイスは、[Core Specification Supplement]、パートA、セクション1.3で定義されているように、以下のすべてのフラグを設定して、[Core Specification Supplement]、パートA、セクション1.3で定義されているように、フラグADタイプを含む広告データを含む広告イベントタイプを送信しなければならない。

• LE Limited Discoverable Mode フラグを１に設定する。

• LE 一般発見可能モードフラグをゼロに設定する。

• LE限定発見可能モードフラグが１に設定されているLE専用デバイス・タイプのデバイスの場合。

a) 「BR/EDR Not Supported」フラグを1に設定する。

b) 「同時 LE と BR/EDR to Same Device Capable (Controller)」フラグをゼロに設定する。

c) 「LE/BR/EDRと同一デバイス対応(ホスト)への同時接続」フラグをゼロに設定する。

また、広告データには、より高速な接続体験を可能にするために、以下のADタイプを含めることが望ましい。

• TX Power Level ADタイプは、[Core Specification Supplement]、パートA、セクション1.5で定義されています。

• コア仕様補足]、パートA、セクション1.5で定義されているローカル名のADタイプ。

• コア仕様補足]パートA第1.1節に定義されているサービスUUIDsのADタイプ。

• スレーブ接続間隔範囲 [Core Specification Supplement]、パートA、セクション1.9で定義されているADタイプ。

デバイスは、TGAP(lim_adv_timeout)を超えてはならない。

デバイスが限定発見可能モードにある間、ホストは以下のようにコントローラを構成する。

• ホストは、広告フィルタポリシーを「すべてのデバイスからのスキャンと接続要求を処理する」に設定する。

• ホストは、9.3.11項で定義されているように広告間隔を設定する。 デバイスは、接続が確立されるまで、限定的な検出可能モードのままとする。

が確立されるか、ホストがモードを終了します。

注：頻繁に変更されるレガシー広告イベントで使用されるホストデータは広告データに配置し、静的データはスキャン応答データに配置する必要があります。

注：広告間隔の選択は、消費電力とデバイスの検出時間との間のトレードオフです。

デバイスは、複数の独立した広告セットを構成し、有効にしてもよい。 各広告セットは、独立した広告フィルタポリシーを持つことができます。

9.2.4 一般的な検出可能モード

9.2.4.1 説明

一般発見可能モードで構成されたデバイスは、一般発見手順を実行するデバイスによって発見可能になるように意図されています。 一般的な発見可能モードは、デバイスが長期間発見可能であることを意図している場合に一般的に使用されます。

9.2.4.2 条件

デバイスがペリフェラルな役割にある間は、デバイスは一般的な検出可能モードをサポートすることができる。 デバイスがブロードキャスタ、オブザーバ、またはセントラルの役割のみにある間は、デバイスは一般発見可能モードをサポートしないものとする。

一般発見可能モードのデバイスは、[Core Specification Supplement]、パートA、セクション1.3で定義されているように、以下のすべてのフラグが設定されているフラグADデータ型を含む広告データで広告イベントを送信しなければならない。

• LE Limited Discoverable Mode フラグをゼロに設定する。

• LE 一般発見可能モードフラグを１に設定する。

• LE限定発見可能モードフラグがゼロに設定されている LE 専用デバイス・タイプのデバイスの場合。

a) 「BR/EDR Not Supported」フラグが１に設定される。

b) 「同一デバイス・キャパブル（コントローラ）への LE と BR/EDR の同時接続」フラグをゼロに設定する。

c) 「同時 LE 及び BR/EDR から同一デバイス対応（ホスト）」フラグはゼロに設定される。

広告データは、より速い接続体験を可能にするために、以下のADタイプも含むことが望ましい。

• TX Power Level AD タイプ：「Core Specification Supplement」パート A 1.5 節に定義されている TX Power Level AD タイプ。

• コア仕様補足]、パートA、セクション1.5で定義されているローカル名のADタイプ。

• Service UUUIDs [Core Specification Supplement]、パートA、セクション1.1で定義されているサービスUUIDsのタイプ。

• スレーブ接続間隔範囲 [Core Specification Supplement]、パートA、セクション1.9で定義されているADタイプ。

デバイスが一般発見可能モードにある間、ホストは、以下のようにコントローラを構成する。

• ホストは、すべての広告セットの広告フィルタポリシーを「すべてのデバイスからのスキャンと接続要求を処理する」に設定しなければならない。

• ホストは、9.3.11 節に定義されているように広告間隔を設定する。 デバイスは、接続が確立されるまで、一般的な検出可能モードのままであること。

が確立されるか、ホストがモードを終了します。

注：頻繁に変更されるレガシー広告イベントで使用されるホストデータは広告データに配置し、静的データはスキャン応答データに配置する必要があります。

注：広告間隔の選択は、消費電力とデバイスディスカバリー時間のトレードオフである。

9.2.5 限定的なディスカバリー手順

9.2.5.1 説明

限定的発見手順を実行する装置は、限定的発見可能モードの装置から、装置アドレス、広告データ、およびスキャン応答データのみを受信する。

-- Figure 9.1: A Central performing limited discovery procedure discovering Peripherals in the limited discoverable mode --

9.2.5.2 条件

デバイスが中央の役割にある間、デバイスは限定的なディスカバリ手順をサポートすることができる。 デバイスがブロードキャスタ、オブザーバ、ペリフェラルの役割にある間は、デバイスは限定的な発見手順をサポートしない。

デバイスがサポートする全ての PHY をスキャンすることを推奨する。

ホストが限定的発見手順を実行する場合、ホストは以下のようにコントローラを設定する。

1. ホストは、スキャナフィルタポリシーを「すべての広告パケットを処理する」に設定する。
2. ホストは、9.3.11 節で定義されたスキャン間隔とスキャンウィンドウを設定する。
3. ホストは、コントローラがアクティブスキャンを使用するように設定する。

ホストは、広告パケットのスキャンを開始し、LE 1M PHY でスキャンする場合は TGAP(lim_disc_scan_min)、LE Coded PHY でスキャンする場合は TGAP(lim_disc_scan_min_coded)の最小値の間継続するものとする。

ホストは、広告データ中の Flags AD タイプをチェックしなければならない。 フラグ AD タイプが存在し、LE 限定発見可能フラグが１に設定されている場合、ホストはそのデバイスを発見されたデバイスと見なすものとする。 フラグ AD タイプは、[Core Specification Supplement]、パート A、セクション 1.3 に定義されている。 発見されたデバイスの広告データは、他の AD タイプ、例えば、サービス UUIDs AD タイプ、TX パワーレベル AD タイプ、ローカル名 AD タイプ、スレーブ接続間隔範囲 AD タイプを持つデータを含んでもよい。 ホストは、接続確立手順のいずれかを実行する際にデータを使用することができる。

ホストは、フラグ AD タイプの「同時 LE 及び BR/EDR to Same Device Capable (Controller)」及び「同時 LE 及び BR/EDR to Same Device Capable (Host)」ビットを無視するものとする。

9.2.6 一般的なディスカバリー手順

9.2.6.1 説明

一般発見手順を実行する装置は、限定発見可能モードまたは一般発見可能モードの装置から、装置アドレス、広告データ、およびスキャン応答データを受信する。

-- Figure 9.2: A Central performing General Discovery procedure discovering Peripherals in the Limited Discoverable mode and General Discoverable mode --

9.2.6.2 条件

デバイスが中央の役割にある間は、デバイスは一般的なディスカバリ手順をサポートしなければならない。 デバイスがブロードキャスタ、オブザーバ、ペリフェラルの役割にある間は、デバイスは一般的なディスカバリー手順をサポートしない。

デバイスがサポートする全ての PHY をスキャンすることを推奨する。

ホストが一般発見手順を実行するとき、ホストは以下のようにコントローラを設定する。

1. ホストは、スキャナフィルタポリシーを「すべての広告パケットを処理する」に設定する。
2. セクション9.3.11.で定義されているように、スキャン間隔とスキャンウィンドウを設定する。
3. ホストは、コントローラがアクティブスキャンを使用するように設定する。

ホストは、広告パケットのスキャンを開始し、LE 1M PHY でスキャンする場合は TGAP(gen_disc_scan_min)以上、LE Coded PHY でスキャンする場合は TGAP(gen_disc_scan_min_coded)以上継続する。 プロシージャは、ホストによって早期に終了してもよい。

ホストは、広告データ中のＦｌａｇｓ ＡＤタイプをチェックしなければならない。 Flags AD タイプ（[Core Specification Supplement]、パート A、セクション 1.3 参照）が存在し、LE 一般発見可能モードフラグが１に設定されているか、LE 限定発見可能モードフラグが１に設定されている場合、 ホストはデバイスを発見されたデバイスとみなすものとし、そうでなければ広告データは無視されるものとする。 発見されたデバイスの広告データは、他の AD タイプ、例えば、サービス UUIDs AD タイプ、TX パワーレベル AD タイプ、ローカル名 AD タイプ、スレーブ接続間隔範囲 AD タイプ等のデータを含むことができる。 ホストは、第 9.3 節で定義された接続確立手順のいずれかを実行する際に、そのデータを使用することができる。

ホストは、Flags AD タイプの「同時 LE 及び BR/EDR to Same Device Capable (Controller)」及び「同時 LE 及び BR/EDR to Same Device Capable (Host)」ビットを無視するものとする。

9.2.7 名前検出手順

9.2.7.1 説明

名前発見手順は、リモート接続可能なデバイスのBluetoothデバイス名を取得するために使用します。

9.2.7.2 条件

限定発見手順または一般発見手順のいずれかを実行中に完全なデバイス名が取得できなかった場合は、名前発見手順を実行してもよい。

名前発見手順は、以下のように行う。

1. ホストは、接続確立手順のいずれかを用いて接続を確立しなければならない。 第9.3項に定義されているように、メンターの手続きを行うこと。

2. ホストは GATT を使用してデバイス名の特性を読み取るものとする。 手順 文字UUIDを使用した読み込み【第3巻】G編 4.8.2.

3. GATT 手続きの終了後、接続を終了することができる。

9.3 接続モードと手順

接続モードと手順により、デバイスは他のデバイスとの接続を確立することができます。

デバイスが接続されると、接続のパラメータは、接続パラメータ更新手順を使用して更新することができます。 接続されたデバイスは、Terminate Connection手順を使用して接続を終了することができます。 接続モードと手順をサポートするためのデバイスの要件は、表9.3に定義されています。 これらの要件は、デバイスが動作している特定の役割を参照する。 複数の役割をサポートするデバイスは、その役割で動作している間、指定された役割のために指定されたモードと手順をサポートしなければならない。

9.3.1 要件

-- Table 9.3: Connection modes and procedures requirements --

9.3.2 非接続モード

9.3.2.1 説明

非接続モードの装置は、接続の確立を許可しないこと。

9.3.2.2 条件

デバイスがペリフェラル・ロールにある間、デバイスは非接続モードをサポートしなければならない。 ブロードキャスターまたはオブザーバーの役割にあるデバイスは接続を確立できないため、デバイスは非接続可能モードをサポートしていると考えられる。

非接続モードのペリフェラル・デバイスは、非接続可能な広告イベントを送信することができる。 この場合、ホストは以下のようにコントローラを構成することをお勧めします。

• ホストは、広告フィルタポリシーを「ホワイトリストのデバイスからのみスキャンと接続要求を処理する」または「すべてのデバイスからスキャンと接続要求を処理する」のいずれかに設定する必要があります。

• ホストは、9.3.11項に定義されているように広告間隔を設定する。

デバイスは、複数の独立した広告セットを構成し、有効にしてもよい。 各広告セットは、独立した広告フィルタポリシーを持つことができる。

9.3.3 Directed Connectable モード

9.3.3.1 説明

有向接続可能モードの装置は、自動接続確立手順または一般接続確立手順を行う既知の相手装置からの接続要求を受 け付けること。

9.3.3.2 条件

デバイスがペリフェラルの役割を果たしている間は、デバイスは指示接続モードをサポートすることができます。 このモードは、デバイスが既知のピア・デバイス・アドレスを持っている場合にのみ使用する。 デバイスがブロードキャスタ、オブザーバ、またはセントラルの役割のみにある間は、デバイスは直接接続可能モードをサポートしてはならない。 ペリフェラルデバイスは、接続可能な直接広告イベントを送信しなければならない。 デバイスは、複数の独立した広告セットを構成し、有効にすることができる。 各広告セットは、独立した広告フィルタポリシーを持つことができる。

9.3.4 直接接続可能モード

9.3.4.1 説明

無指向接続モードの装置は、自動接続確立手順または一般接続確立手順を行う装置からの接続要求を受け付けること。

9.3.4.2 条件

デバイスがペリフェラル・ロールにある間は、そのデバイスは無指向接続モードをサポートしなければならない。 デバイスがブロードキャスタ、オブザーバ、またはセントラルの役割にある間は、そのデバイスは無指向接続モードをサポートしてはならない。 ペリフェラル・デバイスは、セクション9.3.11で定義されたガイドラインに従うことが望ましい。 ペリフェラルデバイスは、接続可能でスキャン可能な無向広告イベントまたは接続可能な無向広告イベントのいずれかを送信しなければならない。 デバイスは、複数の独立した広告セットを構成し、有効にしてもよい。 各広告セットは、独立した広告フィルタポリシーを持つことができる。

9.3.5 自動接続確立手順

9.3.5.1 説明

自動接続確立手順では、ホストは、コントローラが有向接続モードまたは無向接続モードで1台以上のデバイスと自律的に接続を確立するように設定することができます。 コントローラのホワイトリストは、デバイスアドレスを格納するために使用されます。 この手順では、コントローラのイニシエータホワイトリストを使用します。 コントローラは、ホワイトリストに保存されているアドレスと一致するデバイスアドレスを持つデバイスと自律的に接続を確立します。

9.3.5.2 条件

デバイスが中央の役割にある間、デバイスは自動接続確立手順をサポートすることができる。 デバイスがブロードキャスタ、オブザーバ、またはペリフェラルの役割のみにある間は、デバイスは自動接続確立手順をサポートしてはならない。

-- Figure 9.3: Flow chart for a device performing the Auto Connection Establishment procedure --

ホストが自動接続確立手順を実行すると、ホストは以下のようにコントローラを設定します。

1. ホストは、自動接続先となるデバイスアドレスのリストをホワイトリストに書き込む。
2. ホストは、イニシエータフィルタポリシーを「ホワイトリストの全デバイスからの接続可能な広告パケットを処理する」に設定する。
3. ホストは、9.3.11項で定義されているように、スキャン間隔とスキャンウィンドウを設定しなければならない
4. ホストは、9.3.12項に定義されているように接続パラメータを設定する必要があります。

この手順は、接続が確立されたとき、またはホストが手順を終了したときに終了します。

9.3.6 一般接続確立手順

9.3.6.1 説明

一般的な接続確立手順により、ホストは有向接続可能モードまたは無向接続可能モードで既知のピアデバイスのセットとの接続を確立することができます。

9.3.6.2 条件

デバイスが中央の役割にある間は、デバイスは一般的な接続確立手順をサポートすることができる。 デバイスがブロードキャスタ、オブザーバ、またはペリフェラルの役割にのみある間は、デバイスは一般的な接続確立手順をサポートしてはならない。

-- Figure 9.4: Flow chart for a device performing the General Connection Establishment procedure --

ホストが一般的な接続確立手順を実行すると、ホストは以下のようにコントローラを設定します。

1. ホストは、[Vol 2]パートE、セクション7.8.10で定義されているように、スキャナフィルタポリシーを「すべてを受け入れる」オプションのいずれかに設定しなければならない。
2. ホストは、9.3.11 節に定義されているようにスキャン間隔を設定すること。
3. ホストは、9.3.11項で定義されたスキャンウィンドウを設定すること。
4. ホストはスキャンを開始する。
5. ホストは、9.3.12項に定義されているように接続パラメータを設定しなければならない。

ホストが接続を試みる可能性のあるデバイスを発見した場合、ホストはスキャンを停止し、直接接続確立手順を使用して接続を開始しなければならない。 この手順は、接続が確立されたとき、またはホストがこの手順を終了したときに終了する。

9.3.7 選択的接続確立手順

9.3.7.1 説明

選択的接続確立手順は、ホストがホワイトリストのデバイスアドレスのセットを使用して、ホストが選択した接続設定パラメータとの接続を確立することを可能にします。

9.3.7.2 条件

デバイスが中央の役割にある間は、デバイスは選択的接続確立手順をサポートすることができる。 デバイスがブロードキャスタ、オブザーバ、またはペリフェラルの役割のみにある間は、デバイスは選択的接続確立手順をサポートしてはならない。 図9.5にデバイスが選択的接続確立手順を実行する場合のフローチャートを示す。

ホストが選択的接続確立手順を実行する場合、ホストは以下のようにコントローラを設定します。

1. ホストは、選択的に接続するデバイスアドレスのリストをホワイトリストに書き込む。
2. ホストは、[Vol.2]パートE 7.8.10項で定義されているように、スキャナフィルタポリシーを「accept only」オプションに設定する。
3. ホストは、9.3.11項で定義されているようにスキャン間隔を設定すること。
4. ホストは、9.3.11項で定義されたスキャンウィンドウを設定すること。
5. ホストは、アクティブスキャンまたはパッシブスキャンを開始する。

ホストは、接続先のピアデバイスの1つを発見した場合、スキャンを停止し、そのピアデバイスの接続設定パラメータを持つ直接接続確立手順を使用して接続を開始しなければならない。

この手順は、接続が確立されたとき、またはホストが手順を終了したときに終了する。

-- Figure 9.5: Flow chart for a device performing the Selective Connection Establishment proced --

9.3.8 直接接続確立手順

9.3.8.1 説明

直接接続確立手順は、ホストが選択した接続設定パラメータを使用して、単一のピアデバイスとの接続を確立することを可能にします。

9.3.8.2 条件

デバイスが中央の役割にある間は、デバイスは直接接続確立手順をサポートしなければならない。 デバイスがブロードキャスタ、オブザーバ、またはペリフェラルの役割のみにある場合、デバイスは直接接続確立手順をサポートしてはならない。

-- Figure 9.6: Flow chart for a device performing the Direct Connection Establishment procedure --

ホストが直接接続確立手順を実行する場合、ホストは以下のようにコントローラを設定します。

1. ホストは、イニシエータフィルタポリシーを「ホワイトリストを無視し、ホストが指定した特定の単一デバイスからの接続可能な広告パケットをプロセスする」に設定しなければならない。
2. ホストは、ピアアドレスを特定の単一デバイスのデバイスアドレスに設定する。
3. ホストは、9.3.12 節で定義された接続パラメータを設定しなければならない。
4. ホストは接続を開始しなければならない。

この手順は、接続が確立したとき、またはホストが手順を終了したときに終了する。

9.3.9 接続パラメータ更新手順

9.3.9.1 説明

接続パラメータ更新手順では、ペリフェラルまたはセントラルが確立した接続のリンクレイヤ接続パラメータを更新することができます。

9.3.9.2 条件

デバイスが中央の役割にある間、デバイスは接続パラメータ更新手順をサポートしなければならない。 デバイスがペリフェラル・ロールのみにある場合、デバイスは接続パラメータ更新手順をサポートすることができる。 デバイスがブロードキャスタまたはオブザーバの役割にある間は、デバイスは接続パラメータ更新手順をサポートしてはならない。

接続パラメータ更新手順を開始するセントラルは、セントラル又はペリフェラルのいずれかが接続パラメータ要求リンクレイヤ制御手順をサポートしていない場合には、[Vol 6]パートB、セクション5.1.1.1に定義されているリンクレイヤ接続更新手順を、必要な接続パラメータと共に使用しなければならない。

セントラル及びペリフェラルの両方がConnection Parameters Request Link Layer Control手順をサポートしている場合、接続パラメータ更新手順を開始するセントラル又はペリフェラルは、必要な接続パラメータを添えて[Vol 6] Part B, Section 5.1.7に定義されているConnection Parameters Request Link Layer Control手順を使用しなければならない。

中央又はペリフェラルのいずれかが、接続パラメータ要求リンク層制御手順をサポートしていない場合、接続パラメータ更新手順を開始するペリフェラルは、必要な接続パラメータとともに、[Vol 3]パートAのセクション4.20に定義されているL2CAP接続パラメータ更新要求コマンドを使用しなければならない。 周辺機器は、L2CAP接続パラメータ更新応答を受信してからTGAP(conn_param_timeout)以内に、L2CAP接続パラメータ更新要求コマンドを送信してはならない。 セントラルは、ペリフェラルが開始した接続パラメータ更新を受け入れた場合、TGAP(conn_param_timeout)内で、必要な接続パラメータを使用して、[Vol 6]パートB、セクション5.1.1.1に定義されているリンクレイヤ接続更新手順を開始する必要があります。

要求または更新された接続パラメータがセントラルまたはペリフェラルに受け入れられない場合、エラーコード 0x3B(Unacceptable Connection Parameters)で接続を切断することがあります。 デバイスは、リモート・デバイスから与えられた接続パラメータに寛容でなければなりません。

9.3.10 接続の終了手順

9.3.10.1 説明

Terminate Connection プロシージャは、ホストがピアデバイスとの接続を終了させることを可能にします。

9.3.10.2 条件

中央及び周辺機器は、接続の終了手順をサポートしなければならない。 ブロードキャスト及びオブザーバは、接続終了手順をサポートしないものとする。

接続終了手順を開始するホストは、[Vol.6] Part B 5.1.6 節で定義されたリンクレイヤ終了手順を使用しなければならない。

9.3.11 接続確立タイミングパラメータ

9.3.11.1 説明

接続確立タイミング・パラメータは、セントラル・デバイスとペリフェラル・デバイス間の初期接続確立時に使用されます。

セントラルデバイスは、接続可能なモードでペリフェラルデバイスへの接続を開始するために、GAP接続確立手順のいずれかを使用する必要があります。 これらのタイミングパラメータを使用する可能性のある手順とモードについては、セクション9.3.4～セクション9.3.8で定義されています。

9.3.11.2 条件

ユーザー起動型の GAP 接続確立手順を開始するセントラルデバイスは、LE 1M PHY でスキャンする場合、推奨されるスキャン間隔 TGAP(scan_fast_interval)とスキャンウィンドウ TGAP(scan_fast_window)を TGAP(scan_fast_period)に使用し、LE Coded PHY でスキャンする場合、スキャン間隔 TGAP(scan_fast_interval_coded)とスキャンウィンドウ TGAP(scan_fast_window_coded)を TGAP(scan_fast_period)に使用しなければならない。

バックグラウンドスキャンを行うセントラルデバイス（すなわち、ユーザが起動しない GAP 接続確立手順の一部として）は、LE 1M PHY でのスキャン時に推奨されるスキャン間隔 TGAP(scan_slow_interval1)とスキャンウィンドウ TGAP(scan_slow_window1)を使用し、LE Coded PHY でのスキャン時にはスキャン間隔 TGAP(scan_slow_interval1_coded)とスキャンウィンドウ TGAP(scan_slow_window1_coded)を使用すべきである。 あるいは、セントラルは、LE 1M PHY でスキャンする際に TGAP(scan_slow_interval2)とスキャンウィンドウ TGAP(scan_slow_window2)を使用してもよく、LE Coded PHY でスキャンする際に TGAP(scan_slow_interval2_coded)とスキャンウィンドウ TGAP(scan_slow_window2_coded)を使用すべきである。

以下の GAP モードに入るペリフェラルデバイスは、LE 1M PHY 上で広告を行う場合、推奨される広告間隔 TGAP(adv_fast_interval1)を TGAP(adv_fast_period)に使用し、LE コード化 PHY 上で広告を行う場合は TGAP(adv_fast_period)に TGAP(adv_fast_interval1_coded)を使用する必要があります。

• 無指向接続モード
• 限定的な発見可能モードと接続可能な無指向広告イベントの送信
• 一般的な発見可能モードと接続可能な無指向広告イベントの送信
• 指示された接続可能なモードと低デューティサイクルの接続可能な指示された広告イベントの送信

以下の GAP モードに入り、非接続型広告イベントを送信する場合、ペリフェラルデバイスは、LE 1M PHY 上で広告を行う場合は TGAP(adv_fast_period)に推奨される広告間隔 TGAP(adv_fast_interval2)を使用し、LE Coded PHY 上で広告を行う場合は TGAP(adv_fast_period)に TGAP(adv_fast_interval2_coded)を使用しなければならない。

• 非発見可能モード
• 非接続モード
• 限定発見モード
• 一般的な発見可能モード

高デューティサイクルの接続可能な指向型広告イベントを持つ GAP Directed Connectable Mode 以外の GAP Mode でバックグラウンド広告を行うペリフェラルデバイスは、LE 1M PHY 上で広告を行う場合は推奨される広告間隔 TGAP(adv_slow_interval)を使用し、LE Coded PHY 上で広告を行う場合は TGAP(adv_slow_interval_coded)を使用することが推奨される。

注：広告主が他のデバイスと干渉する可能性がある環境で、100ms 未満の広告間隔値が非接続型またはスキャン可能な無指向広告に使用される場合、干渉を最小化するための措置をとることが推奨されます。 例えば、広告は数秒だけ有効にして数分間は無効にするなど、交互に行うことができます。

9.3.12 接続間隔タイミングパラメータ

9.3.12.1 説明

接続間隔のタイミングパラメータは、接続内で使用されます。 初期接続間隔は、ボンディング、暗号化セットアップ、サービスディスカバリーなどの手順を迅速に完了させるために使用されます。 接続間隔は、手順の開始が完了した後、Peripheral Preferred Connection Parameters特性の値に変更する必要があります。

9.3.12.2 条件

セントラルデバイスは、Peripheral Preferred Connection Parameters 特性(セクション 12.3 参照)を読み込むか、広告データからパラメータを取得する(セクション 12.3 参照)。

接続間隔は、LE 1M PHY 上で接続を確立する場合は TGAP(initial_conn_interval)に設定し、LE Coded PHY 上で接続を確立する場合は TGAP(initial_conn_interval_coded)に設定し、スレーブレイテンシはゼロに設定すべきである。 これらのパラメータは、セントラル・デバイスがそれ以上保留中のアクションを実行しないか、またはペリフェラル・デバイスが接続パラメータ更新手順を実行するまで使用されるべきである（セクション 9.3.9 参照）。

セントラルデバイスがこれ以上保留中のアクションを実行することがなく、ペリフェラルデバイスがTGAP(conn_pause_central)内で他のアクションを開始していない後、セントラルデバイスはConnection Parameter Update手順(セクション9.3.9参照)を呼び出し、接続間隔をPeripheral Preferred Connection Parameters特性で指定されたものに変更するべきである。

中央装置がPeripheral Preferred Connection Parameters特性を読み取っていない場合、中央装置は、使用する接続パラメータを選択してもよい。

ペリフェラルデバイスが実行すべき更なる保留中のアクションを持たず、セントラルデバイスがTGAP(conn_pause_central)内で他のアクションを開始していない後、ペリフェラルデバイスは、接続パラメータ更新手順を実行してもよい（セクション9.3.9参照）。 Peripheral デバイスは、接続を確立した後、TGAP(conn_pause_peripheral)内で Connection Parameter Update 手順を実行してはならない。

キーリフレッシュ又は暗号化設定手順が必要とされ、現在の接続間隔が LE 1M PHY 又は LE 2M PHY に接続されている場合は TGAP(initial_conn_interval)よりも大きく、LE Coded PHY に接続されている場合は TGAP(initial_conn_interval_coded)よりも大きい場合は、キーリフレッシュ又は暗号化設定手順の前に接続パラメータ更新手順(セクション 9.3.9 参照)を実行すべきである。 接続間隔は、LE 1M PHY に接続した場合は TGAP(initial_conn_interval)に、LE 2M PHY に接続した場合は TGAP(initial_conn_interval_coded)に設定し、LE Coded PHY に接続した場合は TGAP(initial_conn_interval_coded)に設定し、スレーブのレイテンシはゼロに設定する。 この高速接続間隔は、キーリフレッシュまたは暗号化セットアップ手順が完了するまで維持されるべきである。 その後、ペリフェラル優先接続パラメータ特性の値に切り替えるべきである。

9.4 ボンディングの方法と手順

ボンディングでは、接続された2つの機器がセキュリティ情報とアイデンティティ情報を交換・保存し、信頼された関係を構築することができます。 Vol.3]パートHの2.4.1節で定義されているセキュリティ情報とID情報はボンディング情報とも呼ばれています。 デバイスがボンディング情報を格納すると、「デバイスがボンディングした」「ボンディングが作成された」という表現で知られています。

ボンディングには、非ボンディングモードとボンディング可能モードの2つのモードがあります。 ボンディングは、ボンダブルモードの2つのデバイス間でのみ発生する可能性があります。 ボンディングモードをサポートするデバイスの要件と手順は、表 9.4 に定義されています。

9.4.1 要件

-- Table 9.4: Bonding compliance requirements

9.4.2 ノンボンドモード

9.4.2.1 説明

ノンボンドモードのデバイスは、ピアデバイスとの間にボンドを作成することができません。

9.4.2.2 条件

デバイスがペリフェラルまたはセントラルロールにある間、デバイスは非結合モードをサポートしなければならない。 デバイスがSecurity Managerセクションで定義されているようにペアリングをサポートしていない場合、その デバイスはノンボンディングモードであるとみなされる。

Security Managerのペアリングがサポートされている場合、ホストは、[Vol 3]パートH、セクション3.5.1で定義されているように、Bonding_Flagsを「No Bonding」に設定し、ボンディング情報を交換したり、保存したりしてはならない。

9.4.3 ボンディング可能モード

9.4.3.1 説明

ボンダブルモードのデバイスは、ボンダブルモードのピアデバイスとの間にボンドを作成することができます。

9.4.3.2 条件

ホストは、ペアリング手順の間、Bonding_Flags を「Bonding」に設定しなければならない。

9.4.4 ボンディング手順

9.4.4.1 説明

ボンディング手順は、ボンディングを必要とするサービスに、ボンディングされていないデバイスがアクセスしようとするときに実行されてもよい。 このボンディング手順は、2 つのデバイス間の結合を作成する目的で実行されることがあります。

-- Figure 9.7: The bonding procedure

9.4.4.2 条件

デバイスがペリフェラルまたはセントラルの役割にある間は、デバイスはボンディング手順をサポートしてもよい。 デバイスがブロードキャスターまたはオブザーバの役割にある間は、デバイスはボンディング手順をサポートしてはならない。

Centralのホストは，[Vol 3]パートH，3.5.1節で定義されているように，Bonding_FlagsをBondingに設定して，[Vol 3]パートC，2.1節で定義されているようにペアリング処理を開始する。 ピアデバイスがボンディング可能なモードである場合，デバイスはボンディング情報を交換し，セキュリティデータベースに格納しなければならない。

デバイスが、セクション10.8.2.2.2に定義されている解決可能なプライベートアドレスの生成を サポートし、ローカルアドレスの解決可能なプライベートアドレスを生成する場合は、有効なIRKを含めて、SMPでIdentity情報を 送信しなければならない。 デバイスが自分のアドレスに対して解決可能なプライベートアドレスを生成せず、ホストが SMPでIdentity情報を送信する場合、ホストは、すべてゼロのIRKを送信するものとする。 ホストは、認証要件がIRKを配布するのに十分でない場合、ペアリング手順を中止することができる。

---

中略

10.3 認証手順

認証手順は、デバイスがリモートデバイスへのサービス要求を開始したとき、およびデバイスがリモートデバイスからサービス要求を受信したときに、要求されたセキュリティがどのように確立されるかを説明します。 認証手順は、LE セキュリティモード 1 を対象とする。 認証手順は、接続が確立された後にのみ開始されるものとする。

LE セキュリティ・モード２は、データ署名の使用に関連し、セクション 10.4 で規定する。

LE セキュリティ・モード１の認証は、セクション10.6で定義されるように暗号化を有効にすることで達成される。 暗号化のセキュリティは、実行されるペアリングのタイプによって影響を受ける。 ペアリングには、認証済みペアリングと未認証ペアリングの 2 種類がある。 認証済みペアリングでは、[Vol.3] Part H, 2.1 節で定義されているペアリング手順を、認証を「MITM 保護」に設定して実行します。 認証なしのペアリングでは，認証を「No MITM protection」に設定してペアリングを行う． 注：本節では，「認証済みペアリング」および「未認証ペアリング」という用語は，ペアリングを実行するために使用されるセキュリティ方法を指し，再接続時の以前に結合されたデバイスの認証とは関係ありません。

10.3.1 節では、デバイスがサービス要求に応答した場合の認証手順を規定する。 10.3.2 節では、デバイスがサービス要求を開始する際の認証手順を規定する。

10.3.1 サービス要求への応答

このセクションでは、ローカル デバイスは、リモート デバイスが行ったサービス要求に応答するデバイスです。 L2CAPプロトコルでは、ローカルデバイスは、リモートデバイスが接続要求を行った場合に、接続応答で応答します。 GATTでは、ローカルデバイスがGATTサーバ、リモートデバイスがGATTクライアントとなります。

ローカルデバイスがリモートデバイスからサービス要求を受信した場合、サービス要求が拒否された場合には、エラーコードを付して応答する。 エラーコードは、現在の接続が暗号化されているかどうかと、使用する LTK または STK を作成するために実行されたペアリングの種類に依存する。

ローカルデバイスがリモートデバイスからサービス要求を受信した場合、以下のルールに従って動作する。

• ローカルデバイスのセキュリティデータベースは、サービス要求を受け入れるために必要なセキュリティ設定を指定する。 暗号化とデータ署名が必要ない場合、サービス要求は受け入れられる。 暗号化が必要な場合、ローカルデバイスは表10.2で定義されているようにエ ラーコードを送らなければならない。 暗号化が必要ないがデータ署名が必要な場合、ローカルデバイスの動作はセクション10.4で定義されている通りである。

• LTKもSTKも利用可能でない場合、サービス要求はエラーコード「Insufficient Authentication」で拒否されなければならない。

注：リンクが暗号化されていない場合、エラーコード「Insufficient Authentication」は、MITM 保護が必要であることを示さない。

• LTK または STK があり、暗号化が必要な場合（LE セキュリティモード 1）で暗号化が有効になっていない場合は、エラーコード「Insufficient Encryption」でサービス要求を拒否する。 不十分な鍵サイズで暗号化が有効な場合は、サービス要求はエラーコード "Insufficient Encryption Key Size "で拒否されなければならない。

• 認証済みペアリングが要求されているが，認証されていないペアリングのみが発生し，リンクが現在暗号化されている場合，サービス要求はエラーコード "Insufficient Authentication "で拒否される。

注：認証されていないペアリングが発生し、リンクが現在暗号化されている場合、エラーコード「Insufficient Authentication」は、MITM 保護が必要であることを示す。

• LE Secure Connections のペアリングが必要だが、LE レガシー・ペアリングが発生し、リンクが現在暗号化されている場合、サービス要求は、エラー・コード「Insufficient Authentication」で拒否されるものとする。

ローカル・デバイスは、そのサービスへのアクセスに必要な最低限のセキュリティ・レベルで応答する。 ローカルデバイスがセキュリティ要求を持たない場合は、ペアリングフェーズ1で定義されたローカルデバイスが可能な最低限のセキュリティレベルをデフォルトとする（[Vol.3]パートHの2.1節参照）。

ローカルデバイスが要求されたIO能力またはOBデータ1をサポートしていない場合，ローカルデバイスは，認証済みペアリング（MITM）を必要としないものとする。

ローカルデバイスがリモートデバイスからのサービス要求に応答することを表10.2にまとめる。

-- 表10.2. ローカルデバイスがサービス要求に応答する

図10.1にサーバがサービスリクエストをどのように処理するかを示す。

-- 図10.1. 図10.1: ローカルデバイスがリモートデバイスからのサービス要求を処理する場合のフローチャート

10.3.1.1 GATTの表示と通知の取扱い

クライアントは、クライアント特性設定記述子を介してサーバを適切に設定することで、指示や通知を送信するようにサーバに「要求」します。 設定は切断と再接続の間も持続するので、再接続時に設定と照らし合わせてセキュリティ要件をチェックしてから、指示と通知を送信しなければなりません。

10.3.1.1 GATTの表示と通知の取扱い

クライアントは、クライアント特性設定記述子を介してサーバを適切に設定することで、表示や通知を送信するようにサーバに「要求」します。 設定は切断と再接続の間も持続するので、表示や通知を送信する前に、再接続時にセキュリティ要件を設定と照合しなければなりません。 サーバが、セキュリティが要求される指示または通知を送信するためにクライアントに再接続する場合、サーバは、指示または通知を送信する前に、クライアントとの間で暗号化を開始するか、または要求しなければならない。 クライアントが結合を失ったことを示すLTKを持っていない場合、暗号化を有効にすることは失敗する。

10.3.1.2 クロストランスポート鍵生成

暗号化が有効になり、正しいセキュリティレベルが達成され、両方のデバイスがクロストランスポート鍵生成をサポートした後、両方のデバイスがBR/EDRリンク鍵の導出を実行することができます。

注: LTK に 16 オクテット(128 ビット)未満の暗号化キーサイズがある場合、BR/EDR リンクキーは LTK がマスクされる前に導出されます。

10.3.2 サービスリクエストの開始

このセクションでは、ローカル デバイスは、リモート デバイスへのサービス要求を開始するデバイスです。 L2CAPプロトコルでは、ローカルデバイスが接続要求を送信し、リモートデバイスが接続応答を送信します。 GATTでは、ローカルデバイスがGATTクライアント、リモートデバイスがGATTサーバとなります。

ローカルデバイスがリモートデバイスへのサービス要求を開始する場合は、以下のルールに従って動作する。

• ローカルデバイスのセキュリティデータベースは、サービス要求を開始するために必要なセキュリティを指定する。 ローカルデバイスのセキュリティデータベースは、サービス要求を開始するために必要なセキュリ ティを指定する。 ローカルデバイスが暗号化を要求しない場合、サービス要求は暗号化もペアリングもせずに進行してもよい。

• LTKが利用できないが暗号化が必要な場合は、ローカルデバイスの必要な認証設定でペアリング手順を開始しなければならない。 ペアリング手順が失敗した場合、サービス要求は中止されなければならない。

注：暗号化が有効になっていない場合、エラーコード「Insufficient Authentication」は、ローカルデバイスにMITM保護が必要であることを示さない。

注：ローカルデバイスがペリフェラルである場合，[Vol 3]パートH，セクション2.4.6で定義されているように，スレーブ起動型セキュリティ要求を送信してもよい。

• ペアリングが発生したが，暗号化キーサイズが不十分な場合は，必要な暗号化キーサイズでペアリング手順を実行しなければならない。 ペアリング手順が失敗した場合は、サービス要求を中止する。

• LTKが利用可能で暗号化が必要な場合(LEセキュリティモード1)、セクション10.6で 定義されているようにサービスリクエストが進む前に暗号化を有効にしなければならない。 暗号化が有効化されると、サービス要求は続行されるものとする。 暗号化が失敗した場合は、リモートデバイスにボンドがもはや存在しないか、間違ったデバイスが接続されたかのいずれかである。 ローカルデバイスは、リモートデバイスを確認するためのユーザーとのやりとりの後、 再結合し、サービスディスカバリを実行し、リモートデバイスを再設定しなければならない。 ローカルデバイスが以前にリモートデバイスが「Service Changed」特性を持っていないと判断した場合、または「Database Hash」特性を読み取ってデータベースが変更されていないとローカルデバイスが判断した場合、サービス検出はスキップされる可能性があります。

• 認証されたペアリングが必要だが、認証されていないペアリングしか発生しておらず、リンクが現在暗号化されている場合、ペアリング手順は必要な認証設定で実行されるべきである。 ペアリング手順が失敗した場合，又はローカルデバイスとリモートデバイスのIO能力で認証済みペアリングが実行できない場合，サービス要求は中止されなければならない。 2つのデバイス間に結合が作成されている場合、いかなる再接続も、サービス要求を開始する前に、ローカルデバイスがリモートデバイスとの間で暗号化を有効にするか、要求する結果となるべきである。 ローカルデバイスがサービス要求を開始する前に暗号化を有効にせず、エラーコードに依存してセキュリティ要件を決定する場合、ローカルデバイスは、リンクが暗号化されていない間にリモートデバイスから「Insufficient Authentication」エラーコードを受信したことに応答して、MITM保護とのペアリングを要求してはならない。 ローカルデバイスは，ローカルデバイス自身がMITM保護を要求する場合にのみ，MITM保護要求フラグを設定しなければならない。

• サービスリクエスト時に暗号化が有効になっておらず、エラーコード「Insufficient Authentication」を受信し、ローカルデバイスが現在 LTK を持っている場合は、暗号化手順を開始する必要があります(セクション 10.6 参照)。 これが失敗した場合(リモートデバイスがボンドを失い、LTKをもはや持っていないことを示している可能性が高い)、またはローカルデバイスが正しいLTKを持っていない場合は、ペアリング手順を開始すべきである。 IO能力はペアリングフェーズ1で交換され（[Vol 3]パートH、セクション2.1参照）、セキュリティレベルはデバイスのIO能力とMITM要件によって決定されなければならない。

• サービス要求時に暗号化が有効になっておらず，エラーコード "Insufficient Encryption "を受信し，ローカルデバイスが現在LTKを持っている場合は，暗号化手順を開始しなければならない（10.6節参照）。 暗号化の開始に失敗した場合（リモート・デバイスがボンドを失い、LTK を持たなくなったことを示している可能性 が高い）、またはローカル・デバイスが正しい LTK を持っていない場合は、ペアリング手順を開始すべきである。

• LE Secure Connections 認証ペアリングが必要だが、リモートデバイスが LE Secure Connections をサポートしていない場合、サービス要求は中止されるものとする。

図 10.2 に、クライアントがサービス要求を発行する方法を示す。

-- 図 10.2. 図 10.2: ローカル・デバイスがリモート・デバイスにサービス要求を発行する場合のフロー・チャート

10.3.2.1 クロストランスポート鍵の生成

暗号化が有効になり、正しいセキュリティレベルが達成され、両方のデバイスがクロストランスポート鍵生成をサポートした後、両方のデバイスがBR/EDRリンク鍵の導出を実行することができます。

注：LTKに16オクテット（128ビット）未満の暗号化キーサイズがある場合、LTKがマスクされる前にBR/EDRリンクキーが導出されます。

10.4 データ署名

データ署名方式は、暗号化されていない接続で2台の機器間で認証されたデータを転送するために使用されます。 このデータ署名方式は、高速な接続設定と高速なデータ転送を必要とするサービスで使用する。 サービス要求が LE セキュリティモード 2 を指定する場合は、接続データ署名手順を使用する。

10.4.1 接続データ署名手順

デバイスは、接続において署名データを送信する相手デバイスの集合毎に、新たに接続署名解決鍵 CSRK を生成する。 CSRK については、[Vol.3]パート H 2.4.2.2.2 節で定義する。

ここで、m は署名するデータ PDU、k は CSRK、SignCounter はカウンタ値である。 署名は、カウンタ値と、署名アルゴリズムによって生成されたメッセージ認証コード（MAC）から構成される。 カウンタ値は、送信された新しいデータＰＤＵごとに１ずつインクリメントされなければならない。

署名データのフォーマットを図 10.3 に示す。

-- 図 10.3：符号付きデータの一般的なフォーマット

10.4.2 署名データの認証手続き

暗号化が必要なく、かつ CSRK が利用可能な場合（LE セキュリティモード 2）、書き込み操作を含むサービス要求を行 う際には、データ署名手順が使用されるものとする。

注：サーバ上の結合の存在は、セクション10.6で定義されている暗号化手順を使用してサーバとの暗号化を正常に有効にすることによって決定することができる。 上位レイヤのプロファイルでは、クライアントが認証手順を実行しないことを許可してもよい。 あるいは、上位レイヤプロトコルは、署名チェックがボンドを失ったために失敗したことをクライアントに通知してもよく、クライアントは、その後、ユーザに通知するか、またはボンドを再確立するために再度ペアリングを試みるための措置をとってもよい。

署名されたデータを受信したデバイスは、署名アルゴリズムを実行することでそれを認証しなければならない。 ここで、m は認証されるデータ PDU、k は格納された CSRK、SignCounter は受信したカウンタ値である。 署名アルゴリズムによって計算されたMACが受信したMACと一致しない場合、検証は失敗し、ホストは受信したデータPDUを無視するものとする。

サーバはSigned Writeコマンドに応答しないので、上位層アプリケーションは無視された要求を必ずしも通知されない。 したがって、クライアントがセキュリティ攻撃を試みる悪意のあるデバイスである場合には、サーバはリンクを切断することが推奨される。

サーバが署名付き書き込みコマンドを受信した際に格納されている CSRK を持たない場合、サーバは受信したデータ PDU を無視する。 サーバは署名付き書込みコマンドに応答しないので、上位レイヤアプリケーションは無視された要求を必ずしも通知されない。 切断は、デバイスがペアリングされる必要があることをユーザに対して適切に示すものであってもよいが、実装者は、ＣＳＲＫを確立するためにデバイスがペアリングされる必要があることをユーザに対してより有益な表示を提供することを検討することが推奨される。

サーバが、応答を要求する書き込み操作のためのクライアントからの要求(すなわち、Signed WriteコマンドまたはWriteコマンド以外のもの)を受信し、暗号化が有効になっていない場合、サーバは、エラーコード「Insufficient Authentication」で応答しなければならない。

リンクが暗号化されており、サーバがデータ署名を要求するが暗号化を要求しないクライアントからの要求を受信した場合、リンクの暗号化された状態が署名要求を満たすと考えられるため、サーバは、他に有効であれば、その要求を完了しなければならない。

セクション10.2.2で要求されているように、与えられたリンクでは、暗号化と同時に署名されたデータは使用されない。 したがって、クライアントがサーバがまだ結合されていることをテストしたい、したがって暗号化を有効にしたい場合、サーバが上記の推奨通りリンクを切断しないと仮定して、さらなるデータ転送は署名なしで行われなければならない。

上位レイヤがサーバ上に結合が存在しないと判断した場合、クライアントは、リモートデバイスを確認するためのユーザとの対話の後、再度結合を行い、サービス検出を実行し、サーバを再設定しなければならない。 クライアントが以前にサーバが「Service Changed」特性を持たないと判断していた場合、または「Database Hash」特性を読み取ってデータベースが変更されていないとクライアントが判断した場合、サービス発見はスキップされてもよい。

受信デバイスは、受信したSignCounterを、同じピアデバイスから以前に受信したSignCounterと比較することで、リプレイ攻撃から保護しなければならない。 SignCounter が以前に使用されていた場合、受信デバイスはデータ PDU を無視しなければならない。

10.5 認可手続き

サービスは、アクセスを許可する前に承認を必要とする場合があります。 認可とは、手続きを継続するためのユーザーによる確認のことです。 認証は必ずしも認可を与えるものではありません。 認証に成功した後、ユーザの確認によって認可が与えられることがある。

10.6 暗号化手順

セントラルは、完全性と機密性を提供するために、[Vol 3] Part H, Section 2.4.4 で定義されている Encryption Session Setup を使用して接続を暗号化することができます。

ペリフェラルは，完全性と機密性を確保するために，[Vol 3] Part H 2.4.6 節で定義されている Slave Initiated Security Request を用いて接続を暗号化することができる。

暗号化手順が失敗し、セントラル又はペリフェラルのいずれかが接続確立のためにリゾルバブル・プライベート・アドレスを使用した場合、現在のリゾルバブル・プライベート・アドレスは直ちに破棄され、新しいリゾルバブル・プライベート・アドレスが生成されなければならない。