Bluetooth Low Energy（BLE）デバイス

BLE デバイス向けの Google ファスト ペアリング サービス（GFPS）の実装は、Bluetooth Core Specification v4.2 以降と互換性があります。

ファスト ペアリング仕様の次の追記により、GFPS で Low Energy（LE）のみと Low Energy Audio（LEA）デバイスのサポートが可能になります。

適合性レベル

仕様で言及されているキーワード「shall」、「must」、「will」、「should」、「may」、「can」は、以下のように説明されます。

用語 説明
しなければならない is required to - 要件を定義するために使用されます。
must は、
以前に述べた必須要件の自然な結果
または
反論の余地のない事実の記述（状況に関係なく常に真であるもの）を表すために使用されます。
will it is true that - 事実の陳述でのみ使用されます。
should is recommended that - 複数の可能性の中から、特に適切であるとして推奨されるが、必須ではないことを示すために使用されます。
その場合、 is permitted to - オプションを許可するために使用されます。
データ プロダクト is able to - 因果関係のある文を結び付けるために使用されます。

キーベースのペア設定特性

Seeker から Provider へのメッセージ

キーベースのペア設定特性の Raw Request type 0x00 は、ビット 4 を使用してシーカーが BLE デバイス仕様をサポートしているかどうかを示し、ビット 5 を使用してシーカーが LE Audio をサポートしているかどうかを示します。

オクテット データ型 説明 値 必須かどうか
0 uint8 メッセージの種類 0x00 = キーベースのペア設定リクエスト 必須
1 uint8 フラグ
  • ビット 0（MSB）: 非推奨であり、Seeker によって無視されます。
  • ビット 1: シーカーがプロバイダにボンディングの開始をリクエストし、このリクエストにシーカーの BR/EDR アドレスが含まれている場合は 1。それ以外の場合は 0。
  • ビット 2: シーカーがプロバイダに既存の名前を通知するようリクエストする場合に 1。それ以外の場合は 0。
  • ビット 3: アカウントキーの遡及書き込みの場合は 1。それ以外の場合は 0。
  • ビット 4: シーカーが BLE デバイス仕様をサポートしている場合は 1。それ以外の場合は 0。
  • ビット 5: Seeker が LE Audio に対応している場合は 1。それ以外の場合は 0。
  • ビット 6 ～ 7 は将来の使用のために予約されており、無視されます。
 varies 必須
2 ～ 7 uint48 次のいずれか:
  • プロバイダの現在の BLE アドレス
  • プロバイダの Identity アドレス
 varies 必須
8 ～ 13 uint48 シーカーの BR/EDR アドレス varies フラグ ビット 1 または 3 が設定されている場合にのみ存在します
n - 15 ランダムな値（ソルト） varies 必須

プロバイダからシーカーへのメッセージ

リクエストのビット 4 が設定されている場合、キーベースのペア設定特性の新しいレスポンス メッセージ type 0x02 を使用して、シーカーに追加のボンディング オプションを提供できます。

オクテット データ型 説明 値
0 uint8 メッセージの種類 0x02 = Key-based Pairing Extended Response
1 uint8 フラグ
  • ビット 0（MSB）: プロバイダが LE 専用デバイスの場合は 1、それ以外の場合は 0。ビット 0 が 1 に設定されている場合、Seeker はビット 1 が 1 に設定されていると想定します。
  • ビット 1: プロバイダが LE ボンディングを優先する場合は 1、それ以外の場合は 0。
  • ビット 2: 2 番目のアドレスのアドレスタイプがランダムの場合は 1、パブリックの場合は 0。
  • ビット 3 ～ 7 は将来の使用のために予約されており、無視されます。
 varies
2 uint8 プロバイダのアドレスの数
（現在のバージョンでは、数が 3 以上の場合にブロック暗号モードを AES-CTR に変更する必要があるため、数は 1 または 2 です）		 varies
3 - 8 または
3 - 14
  • 最初のアドレスはプライマリの Identity アドレスで、BR/EDR ボンディングが優先される場合はボンディング可能であること
  • セカンダリが利用可能な場合、2 番目のアドレスはセカンダリのバインド可能なアドレスになります。
 varies
9 ～ 15 または 15 ランダムな値（ソルト） varies

BLE デバイス仕様をサポートするプロバイダは、ビット 4 とビット 5 を読み取ってシーカーの機能を理解しなければなりません。

  • ビット 4 が 0 の場合、プロバイダはビット 5 を無視し、type 0x01 形式で応答しなければなりません。
  • ビット 4 が 1 の場合、
    • LE 専用プロバイダの場合、LE 接続の優先度を示す type 0x02 で応答します。
    • デュアルモード プロバイダは、type 0x02 で応答して、BR/EDR または LE のボンディング設定を示すことができます。
  • LE Audio（LEA）デュアルモード プロバイダのケースについては、例: LEA デュアルモード プロバイダとのペア設定を参照してください。

メッセージ ストリーム PSM（プロトコル サービス マルチプレクサ）特性

BLE デバイスのメッセージ ストリームをサポートするため、ファスト ペアリングはメッセージの送受信用の BLE L2CAP チャネルを確立して維持します。ファスト ペアリング L2CAP サーバーは LE クレジット ベースのフロー制御を実装しなければなりません。

この特性により、シーカーは PSM 値を読み取り、PSM 値によって安全な L2CAP 接続を確立できます。

ファスト ペアリング サービスの特性 暗号化あり 権限 UUID
メッセージ ストリーム PSM ○ 読み取り FE2C1239-8366-4814-8EB0-01DE32100BEA
オクテット データ型 説明 値
0 uint8 State
  • 0x00 = 不明。FP Seeker は数回再試行します
  • 0x01 = 接続の準備が整いました
  • 0x02 = 利用不可。FP Seeker は今回このコンポーネントを使用して接続しません
 varies
1 - 2 uint16 PSM 値は 0x80 ～ 0xFF の範囲でなければなりません varies

注: TWS には、プライマリとセカンダリの 2 つのコンポーネントがあります。これらのコンポーネントの役割は、特定の条件で交換可能です。A がプライマリ コンポーネントで B がセカンダリ コンポーネントであると仮定します。コンポーネント A のバッテリーが消耗したため、コンポーネント B がプライマリ コンポーネントの役割を担う必要があります。このシナリオを role switch と呼びます。

role switch の後、プロバイダがファスト ペアリング メッセージ ストリームを処理できない場合、既存の L2CAP 接続を積極的に切断しなければなりません。ファスト ペアリング シーカーは、新しいプライマリ コンポーネントとの L2CAP メッセージ ストリーム接続を再確立できます。

パスキーの追加の特性

この特性は、追加のコンポーネントで MITM 保護を提供するためのものです。

CSIS Fake Member MITM Protection

ファスト ペアリングでは、ペア設定手順の一環として MITM 保護が必要です。CSIS は MITM 保護を提供しないため、複数のコンポーネントの FP の現在の設計を拡張して、追加のコンポーネントで MITM 保護を提供する必要があります。

特性の定義

ファスト ペアリング サービス特性 暗号化あり 権限 UUID
追加のパスキー ○ 読み取り、書き込み、通知 FE2C123A-8366-4814-8EB0-01DE32100BEA

メッセージ

メッセージ形式は、読み取り、書き込み、通知のオペレーションに適用されます。

暗号化されたデータ形式

暗号化されたデータは、ファスト ペアリングの GATT 接続を使用して送信されます。

オクテット データ型 説明 値
0-15 uint128 暗号化された追加のパスキー ブロック 可変
元データの形式

共有シークレットを使用して暗号化されたデータを復号すると、形式は次のようになります。

オクテット データ型 説明 値
0 uint8 メッセージの種類
    のいずれか
  • 0x00 = シーカーのパスキー
  • 0x01 = プロバイダのパスキー
1～3 uint24 6 桁のパスキー 可変
4～9 uint48 ターゲット ボンディング コンポーネントのアドレス 可変
10 uint8 ステータス コード。読み取りオペレーションでのみ使用されます 次のいずれか
  • 0x00 = 成功
  • 0x01 = 保留中。FP Seeker はタイムアウトするまで再試行する
  • 0x02 = 失敗。FP Seeker の停止再試行
11～15 ランダムな値（ソルト） 可変

プライマリ（最初にペア設定されたコンポーネント）は、ファスト ペアリング シーカーと追加のコンポーネント間のブリッジです。特性はガイドラインに準拠するものとします。

  • Fast Pair Seeker から書き込みリクエストを受信した場合、Provider は、
    • ボンディングされるコンポーネントのアドレスを設定する
    • ペア設定されるコンポーネントにパスキーを送信する
    • ステータス コードを保留中（0x01）に設定
  • ペア設定されるコンポーネントからパスキーを受け取る前に読み取りリクエストを受け取った場合、プロバイダは
    • パスキー、任意の値
    • バインドされるコンポーネントのアドレス
    • 保留中のステータス コード、0x01
  • プロバイダが Fast Pair シーカーに通知を送信する前に、
    • ボンディングされるコンポーネントのパスキー
    • バインドされるコンポーネントのアドレス
    • 成功ステータス コード、0x00
  • プロバイダ側で回復不能なエラーが発生した場合は、結果を
      に設定します。
    • パスキー、任意の値
    • バインドされるコンポーネントのアドレス
    • 失敗ステータス コード、0x02

詳しくは、MITM の図 1 と MITM の図 2 をご覧ください。

LE デバイスの要件

LE Advertising

検出可能モードまたは検出不可モードの場合、プロバイダは RPA を使用して FastPair データをアドバタイズします。

ボンディング機能

LE 対応デバイスの場合、シーカーは既存の LE 接続でボンドを作成する必要があります。ファスト ペアリング キーベースのペア設定の検証に合格した後、プロバイダは RPA とのボンディングを許可し、ファスト ペアリング パスキーの検証のために IO 機能を DisplayYesNo に設定しなければなりません。

LEA デバイスの要件

LEA Advertising

デュアルモード デバイスの場合: 検出可能モードの場合、プロバイダは Identity アドレスでファスト ペアリング データをアドバタイズしなければなりません。検出不可モードの場合、プロバイダは RPA を使用してファスト ペアリング データをアドバタイズしなければなりません。下位互換性のために、以前のデバイスをサポートするには、以前のアドバタイズメント（BT 4.2）を使用することを強く推奨します。デバイスが出荷時の設定にリセットされるたびに IRK を変更する必要があります。

デュアルモードではないデバイスの場合: 検出可能モードまたは検出不可能モードの場合、プロバイダは RPA を使用した拡張アドバタイズ（BT 5.0）を使用して FastPair データをアドバタイズしなければなりません。

FP サービスデータを含む LE 接続可能なアドバタイズメントは、Bluetooth Adapter Profile（BAP 1.0.1）および Common Audio Profile の要件に準拠して CAS UUID を含みます。

プロバイダは、検出可能モードに関係なく、サービスデータ（AD タイプ 0x16）または 16 ビット サービス クラス UUID（AD タイプ 0x02 または 0x03）のいずれかに CAS UUID（0x1853）を含めることで、LEA 機能を指定できます。

バッテリーと SASS データが含まれているため、従来のアドバタイズメントに十分なスペースがない非検出可能なアドバタイズメントの場合、そのスキャン レスポンスに CAS UUID を含めることが必須です。

LEA ボンディング機能

Seeker は既存の LE 接続とのペア設定を作成する必要があります。ファスト ペアリング キーベースのペア設定の検証に合格した後、デュアルモード プロバイダは Identity アドレスと RPA とのボンディングを許可し、非デュアルモード プロバイダは RPA とのボンディングを許可し、ファスト ペアリング パスキーの検証のために IO 機能を DisplayYesNo に設定しなければなりません。

コンポーネント間の内部通信チャネル

既存の GATT 接続は、追加のコンポーネントで MITM 保護を行うために維持されます。プライマリ結合コンポーネントは、ファスト ペアリング シーカーとその残りのコンポーネント間のメッセージ配信を処理します。

内部通信は Initial Pair と Subsequent Pair に使用されます

  • キーベースのペア設定手順がプライマリ コンポーネントで成功した場合、プライマリ コンポーネントは残りのコンポーネントの IO 機能を変更するメッセージを送信しなければなりません。
  • ファスト ペアリングが完了すると、プライマリ コンポーネントは、残りのコンポーネントの IO 機能をリセットするメッセージを送信しなければなりません。
  • 追加のパスキー手順を実行する場合、プライマリ コンポーネントはファスト ペアリング シーカーとその残りのコンポーネント間のパスキーの配信を処理しなければなりません。

IO 機能を変更する時間

  • キーベースのペア設定手順が完了した場合、IO 機能を DisplayYesNo に変更
    • デバイスに複数のコンポーネントがある場合、すべてのコンポーネントを DisplayYesNo に設定しなければなりません。
    • ただし、キーベースのペア設定リクエストのビット 3 が 1 に設定されている Retroactive Pair については、プロバイダは IO ケーパビリティを DisplayYesNo に変更してはなりません。シーカーからプロバイダへのメッセージを参照してください。
  • IO 機能をデフォルト設定に変更
    • 初期ペア設定
      • LE 接続が切断された場合、ファスト ペアリング セッションを終了
      • プライマリがバインドされた後、15 秒以内にパスキーの書き込みリクエストが追加でなければ、ファスト ペアリング セッションを終了
      • 追加のパスキー書き込みリクエストを受信した後、15 秒以内にペア設定されるコンポーネントがペア設定されない場合、ファスト ペアリング セッションを終了
      • すべてのコンポーネントがバインドされた後、15 秒以内にアカウントキーの書き込みリクエストがない場合は、ファスト ペアリング セッションを終了します。
      • アカウントキーの書き込みリクエストを受信したら、ファスト ペアリング セッションを終了するまでのタイムアウトを 15 秒に設定
    • 後続のペア設定
      • LE 接続が切断された場合、ファスト ペアリング セッションを終了
      • プライマリがバインドされた後、15 秒以内にパスキーの書き込みリクエストが追加でなければ、ファスト ペアリング セッションを終了する
      • 追加のパスキー書き込みリクエストを受信した後、15 秒以内にペア設定されるコンポーネントがペア設定されない場合、ファスト ペアリング セッションを終了
      • すべてのコンポーネントがバインドされたら、ファスト ペアリング セッションを終了します

UI インジケーターを非表示

ヘッドセットがペア設定の準備ができていない場合、プロバイダは type 0b0010 を使用してアカウント キーデータの UI 表示を非表示に設定し、シーカーに後続のペア設定 UI を表示しないよう指示します（アドバタイズ ペイロード: Fast Pair アカウント データを参照）。

LE Audio デバイスの要件

Bluetooth の要件

Android、LE Audio ヘッドセットの推奨事項をご覧ください。

CTKD のサポート

デュアルモード デバイスの場合、LE から BR/EDR への CTKD は必須であり、BAP の要件に沿っています。

Target Announcement

周辺機器は、ペア設定された中央機器からの接続を求めるために、ターゲット アナウンスを使用しなければなりません。ターゲット アナウンスメントは、CAP 1.0 の表 8.4（p48/58）に従って、接続管理のために BAP と CAP で定義されています。

GATT EATT サーバーのサポート

EATT を使用すると、デバイスがペア設定されている場合、セントラル デバイスは複数の GATT トランザクションを並列で送信できます。CSIP をサポートするデバイスでは、プロファイル接続のパフォーマンスが向上し、すぐに他のイヤホンの CSIP ボンディング手順が開始されます。

プロバイダが単一のデバイスではなく、CSIP 実装による協調セットである場合、サービス ディスカバリの回数を減らし、接続を高速化するために、プロバイダは Bluetooth 5.1 で定義されている GATT キャッシュ保存を実装すべきです。

ファスト ペアリングの要件

LE Advertising

検出可能モードまたは検出不可モードの場合、デバイスに複数のコンポーネントがある場合、ファスト ペアリング データはプライマリ コンポーネントによってアドバタイズされなければなりません。デバイスが後続のペア設定の準備ができていない場合、セカンダリ コンポーネントは拡張機能のファスト ペアリング データをアドバタイズできます。UI の表示を非表示にするを参照してください。

GATT サービスの可視性

GATT データベースは、すべての LE トランスポート GATT 接続で同じでなければなりません。LE Audio サービス（0x184E）は、ファスト ペアリング接続の GATT データベースに含まれるものとします。

例: LEA デュアルモード プロバイダとのペア設定

シナリオ 1 - Seeker が LEA をサポートしていない場合

プロバイダは、LEA をサポートしていないシーカーとの下位互換性を有するものとします。

コンポーネント
  • プロバイダ: A2DP/HFP/LEA
  • シーカー: A2DP/HFP
初回ペア設定 / その後のペア設定で想定される動作
  • プロバイダは、ID アドレス（初回）または RPA（以降）で Fast Pair サービスデータ（0xFE2C）をアドバタイズします。
    • 以前の広告を使用する
  • シーカーは、初期ペア設定の場合は ID アドレス、後続のペア設定の場合は RPA を含むプロバイダの広告を受信します。
  • シーカーがキーベースのペア設定リクエストを送信します。
    • キーベースのペア設定リクエストのフラグビット 5 が 0 に設定されている
  • プロバイダは、次のいずれかで公開アドレスを含む鍵ベースのペア設定レスポンスを送信します。
    • メッセージ タイプ 0x01 が使用される場合、アドレスはパブリック アドレスでなければなりません
    • メッセージ タイプ 0x02 が使用されている場合
      • ビット 0 は 0 にする必要があります
      • ビット 1 は 0 にします
      • アドレスは公開アドレスとする
  • Seeker が BR/EDR トランスポートとのボンドを作成します。
    • BR/EDR の IO ケーパビリティが DisplayYesNo に設定されている
  • シーカーとプロバイダがファスト ペアリング パスキー検証手順を行う

シナリオ 2 - Seeker が LEA をサポートしている場合

コンポーネント
  • プロバイダ
    • A2DP/HFP/LEA をサポート
    • 単一コンポーネント
  • シーカー
    • SupportA2DP/HFP/LEA
初回ペア設定 / その後のペア設定で想定される動作
  • プロバイダは、ID アドレス（初回）または RPA（以降）で Fast Pair サービスデータ（0xFE2C）をアドバタイズします。
    • 以前の広告を使用する
  • シーカーがキーベースのペア設定リクエストを送信します。
    • キーベースのペア設定リクエストのフラグビット 5 が 1 に設定されている
  • プロバイダは、メッセージ タイプ 0x02 のキーベースのペア設定レスポンスを送信します。
    • ビット 0 は 0 にする必要があります
    • ビット 1 は 1 にする
    • 住所は Identity address
  • シーカーは LE トランスポート上の既存の LE 接続とのボンドを作成します。
    • CTKD の方向は LE から BR/EDR
    • LE の IO ケーパビリティが DisplayYesNo に設定されている
  • シーカーとプロバイダがファスト ペアリング パスキー検証手順を行う

シナリオ 3 - Seeker が LEA と CSIP の関与をサポートしている場合

コンポーネント
  • プロバイダ
    • A2DP/HFP/LEA をサポート
    • 複数のコンポーネント
      • 主なコンポーネントは BR/EDR/LE
      • セカンダリ コンポーネントは LE 専用
  • シーカー
    • A2DP/HFP/LEA をサポート
初回ペア設定 / その後のペア設定で想定される動作
  • プライマリ コンポーネントは、ID アドレス（初回）または RPA（以降）でファスト ペアリング サービスデータ（0xFE2C）をアドバタイズします。
    • 以前の広告を使用する
  • シーカーがキーベースのペア設定リクエストをプライマリ コンポーネントに送信します。
    • キーベースのペア設定リクエストのフラグビット 5 が 1 に設定されている
  • プライマリ コンポーネントがメッセージ タイプ 0x02 のキーベースのペア設定レスポンスを送信します。
    • ビット 0 は 0 にする必要があります
    • ビット 1 は 1 にする
    • 住所は以下のとおりです。
      • 最初のアドレスは、プライマリ コンポーネントの ID アドレスです。
      • 2 番目のアドレスはセカンダリ コンポーネントのバインド可能なアドレスです。2 番目のコンポーネントもこのアドレスを使用して CSIP アドバタイズを行います。
  • シーカーは、既存の LE 接続でプライマリ コンポーネントとのボンドを作成します。
    • CTKD の方向は LE から BR/EDR
    • LE の IO ケーパビリティが DisplayYesNo に設定されている
  • シーカーは、キーベースのペア設定拡張レスポンスのアドレスを持つセカンダリ コンポーネントとのボンドを作成します。
    • IO 機能は DisplayYesNo でなければなりません。それ以外の場合はペア設定リクエストを拒否します
  • シーカーとプロバイダがセカンダリ コンポーネントをペア設定するための MITM 保護手順を行う場合、プロバイダは両方のシナリオを実装しなければなりません。
  • シーカーはセカンダリ コンポーネントとのバインドが完了するまで待機します

MITM のシーケンス図

このセッションでは、MITM 保護手順のシーケンスについて説明します。

通知によってバインドされているコンポーネントからパスキーを取得する

読み取りによってバインドされているコンポーネントからパスキーを取得

報告されている問題

LEA 向けの FP が、Android V（Android 15）で動作するように最適化されました。

逆に、LEA をサポートしているものの、LEA 経由の正しいファスト ペアリングの実装（つまり、Classic 経由のファスト ペアリングのみ）がないヘッドセットでは、数多くの問題が発生しています。具体的には、たとえば、プロバイダの RPA が正しい Identity Resolving Key（IRK）で生成されず、アドレスを解決できない場合です。ヘッドセットの構成を網羅的にテストすることはできませんでしたが、限定的なテストでは、イヤホンのバッテリー通知が表示されない、音声切り替え（SASS）機能がない、初回およびその後のペア設定の失敗が広範囲に及ぶなど、さまざまな問題が明らかになりました。

そのため、デュアルモードをサポートする新しいデバイスと、フィールド内の既存のデバイス（無線アップデート経由）の両方で、ファスト ペアリング-LEA 仕様を実装することを強く推奨します。