Bluetooth Low Energy(BLE)デバイス

BLE デバイス向けの Google ファスト ペアリング サービス(GFPS)の実装は、Bluetooth Core Specification v4.2 以降に対応しています。

ファスト ペアリング仕様の次の追加条項により、GFPS で低エネルギー(LE)のみのデバイスと低エネルギー音声(LEA)デバイスをサポートできるようになります。

適合性レベル

仕様で言及されているキーワード「shall」、「must」、「will」、「should」、「may」、「can」について説明します。

用語 説明
すること 必須 - 要件を定義するために使用します。
必要 は、
前述の必須要件の自然な結果
または
議論の余地のない事実の記述(状況に関係なく常に真実である記述)を表現するために使用されます。
します それは本当である - 事実の陳述でのみ使用されます。
should is recommended that - 複数の可能性の中で、特に適している方法を推奨する場合に使用します。必須ではありません。
~する可能性がある 許可される - オプションを許可するために使用します。
データ プロダクト できる - 因果関係でステートメントを関連付けるために使用されます。

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

求職者から事業者へのメッセージ

キーベースのペアリング特性の未加工リクエスト type 0x00 は、シーカーが BLE デバイス仕様をサポートしているかどうかをビット 4 で示し、シーカーが LE Audio に対応しているかどうかをビット 5 で示します。

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

提供者から求職者へのメッセージ

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

Octet データ型 説明
0 uint8 メッセージの種類 0x02 = 鍵ベースのペア設定拡張レスポンス
1 uint8 フラグ
  • ビット 0(MSB): プロバイダが LE のみのデバイスの場合は 1、それ以外の場合は 0。ビット 0 が 1 に設定されている場合、シーカーはビット 1 も 1 に設定されていると想定します。
  • ビット 1: プロバイダが LE ボンディングを優先する場合は 1、それ以外の場合は 0。
  • ビット 2: 2 番目のアドレスのアドレスタイプがランダムの場合は 1、パブリックの場合は 0。
  • ビット 3 ~ 7 は、将来の使用のために予約されており、無視します。
変動あり
2 uint8 プロバイダのアドレスの数
(現在のバージョンでは、数字が 3 以上の場合はブロック暗号モードを AES-CTR に変更する必要があるため、数字は 1 または 2 です)
変動あり
3 ~ 8 または
3 ~ 14
  • 最初のアドレスはプライマリの ID アドレスで、BR/EDR ボンディングが優先される場合はボンディング可能である必要があります。
  • 2 つ目のアドレスは、セカンダリが利用可能な場合はセカンダリのボンディング アドレスにする必要があります。
変動あり
9 ~ 15 または 15 ランダム値(salt) 変動あり

BLE デバイス仕様をサポートするプロバイダは、ビット 4 とビット 5 を読み取ってシーカーの機能を把握する必要があります。

  • ビット 4 が 0 の場合、プロバイダはビット 5 を無視し、type 0x01 形式で応答する。
  • ビット 4 が 1 の場合、
    • LE のみのプロバイダの場合、type 0x02 で応答して LE ボンディングの設定を示します。
    • デュアルモード プロバイダの場合、type 0x02 で応答して、BR/EDR または LE ボンディングの設定を指定できます。
  • LE Audio(LEA)デュアルモード プロバイダのケースについては、例: LEA デュアルモード プロバイダとのペア設定を参照してください。

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

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

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

ファスト ペアリング サービスの特性 暗号化あり 権限 UUID
Message Stream PSM はい 読み取り FE2C1239-8366-4814-8EB0-01DE32100BEA
Octet データ型 説明
0 uint8 状態
  • 0x00 = 不明。FP Seeker は複数回再試行します。
  • 0x01 = 接続の準備が整いました
  • 0x02 = 使用不可。FP Seeker は、このコンポーネントを使用して接続しません
変動あり
1 - 2 uint16 PSM 値は 0x80 ~ 0xFF の範囲で指定してください。 変動あり

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

role switch の後、プロバイダがファスト ペアリングのメッセージ ストリームを処理できない場合、既存の L2CAP 接続をプロアクティブに切断します。ファスト ペアリング シーケンサーは、新しいプライマリ コンポーネントとの L2CAP メッセージ ストリーム接続を再確立できます。

追加のパスキー特性

この特性は、追加コンポーネントに MITM 保護を提供します。

CSIS Fake Member MITM 保護

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

特徴の定義

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

メッセージ

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

暗号化されたデータ形式

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

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

共有シークレットを使用して暗号化されたデータを復号した後の形式は次のとおりです。

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

プライマリ(最初に接続されたコンポーネント)は、Fast Pair シーカーと追加の接続コンポーネント間のブリッジです。特性はガイドラインに従う必要があります。

  • Fast Pair シーカーから書き込みリクエストを受信した場合、プロバイダは次の処理を行う必要があります。
    • ボンディングされるコンポーネントのアドレスを設定する
    • ボンディングされるコンポーネントにパスキーを送信する
    • ステータス コードを保留中(0x01)に設定
  • ボンディングされるコンポーネントからパスキーを受け取る前に読み取りリクエストを受信すると、プロバイダは以下を含むメッセージを返す必要があります。
    • パスキー(任意の値)
    • ボンディングされるコンポーネントのアドレス
    • 保留中のステータス コード、0x01
  • プロバイダが Fast Pair シーカに通知を送信する前に、
    • ボンディングされるコンポーネントのパスキーと
    • ボンディングされるコンポーネントのアドレス
    • 成功ステータス コード、0x00
  • プロバイダ側で回復不能なエラーが発生した場合は、結果を設定します。
    • パスキー(任意の値)
    • ボンディングされるコンポーネントのアドレス
    • 失敗ステータス コード、0x02

詳細については、MITM 図 1MITM 図 2 をご覧ください。

LE デバイスの要件

LE Advertising

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

ボンディング機能

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

LEA デバイスの要件

LEA 広告

デュアルモード デバイスの場合: 検出可能モードでは、プロバイダは ID アドレスを使用して Fast Pair データをアドバタイズする必要があります。検出不可モードの場合、プロバイダは RPA でファスト ペアリング データをアドバタイズする必要があります。下位互換性を確保するために、以前のデバイスをサポートするには、従来の広告(BT 4.2)を使用することを強くおすすめします。デバイスを出荷時の設定にリセットするたびに IRK を変更する必要があります。

デュアルモード以外のデバイスの場合: 検出可能モードまたは検出不可モードの場合、プロバイダは RPA で拡張広告(BT 5.0)を使用して FastPair データをアドバタイズする必要があります。

FP サービスデータを含む LE 接続可能なアドバタイズには、Bluetooth アダプター プロファイル(BAP 1.0.1)共通オーディオ プロファイルの要件に従って CAS UUID を含める必要があります。検出不能なアドバタイズメントの場合、バッテリーと SASS データが含まれるために以前のアドバタイズに十分な容量がない場合は、スキャン レスポンスに CAS UUID を含める必要があります。

LEA ボンディング機能

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

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

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

内部通信は Initial PairSubsequent Pair に使用されます。

  • キーベースのペアリング手順がプライマリ コンポーネントを通過すると、プライマリ コンポーネントは残りのコンポーネントの IO 機能を変更するメッセージを送信します。
  • ファスト ペアリングが完了すると、プライマリ コンポーネントは残りのコンポーネントの IO 機能をリセットするメッセージを送信します。
  • 追加のパスキー手順を実行する場合、主要コンポーネントはファスト ペアリング シーカーと残りのコンポーネント間のパスキー配信を処理する必要があります。

IO 機能の変更にかかる時間

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

UI 表示を非表示にする

ヘッドセットがペア設定の準備ができていない場合は、プロバイダは type 0b0010 を使用してアカウント キーデータの UI 非表示インジケーターを設定し、その後のペア設定 UI を表示しないようにシーカーに通知する必要があります(広告ペイロード: ファストペア アカウント データを参照)。

LE Audio デバイスの要件

Bluetooth の要件

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

CTKD サポート

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

ターゲットに関するお知らせ

ペリフェラル デバイスは、Targeted Announcement を使用して、ペア設定されたセントラル デバイスからの接続を要求します。ターゲット設定されたお知らせは、CAP 1.0 の表 8.4(p48/58)に従って、接続管理の BAP と CAP で定義されています。

GATT EATT サーバーのサポート

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

プロバイダが単一のデバイスではなく、CSIP 実装で調整されたセットである場合、サービス検出の回数を減らして接続を高速化するために、プロバイダは Bluetooth 5.1 で定義されている GATT キャッシュを実装する必要があります。

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

LE 広告

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

GATT サービスの公開設定

GATT データベースは、すべての LE トランスポート GATT 接続で同じである必要があります。LE Audio サービス(0x184E)は、ファスト ペアリング接続の GATT データベースに含める必要があります。

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

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

プロバイダは、LEA をサポートしていないシーカーとの下位互換性を確保する必要があります。

コンポーネント
  • プロバイダ: A2DP/HFP/LEA
  • シーケンサ: A2DP/HFP
最初のペア / 後続のペアの想定される動作
  • プロバイダは、ID アドレス(初期)または RPA(後続)を使用して Fast Pair サービスデータ(0xFE2C)をアドバタイズします。
    • 従来の広告を使用する
  • シーカーは、最初のペア設定の場合は ID アドレス、その後のペア設定の場合は RPA を含むプロバイダのアドバタイズを受信します。
  • シーカーがキーベースのペア設定リクエストを送信します。
    • キーベースのペアリングリクエストのフラグビット 5 が 0 に設定される
  • プロバイダは、次のいずれかの公開アドレスで鍵ベースのペア設定レスポンスを送信します。
    • メッセージ タイプ 0x01 が使用されている場合、アドレスはパブリック アドレスである必要があります
    • メッセージ タイプ 0x02 が使用されている場合
      • ビット 0 は 0 にする必要があります
      • ビット 1 は 0 とします。
      • 住所は公共の住所である必要があります
  • シーカーが BR/EDR トランスポートでボンドを作成します。
    • BR/EDR の IO 機能が DisplayYesNo に設定されている
  • 検索者とプロバイダがファストペア パスキーの検証手順を実施する

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

コンポーネント
  • プロバイダ
    • A2DP/HFP/LEA をサポート
    • 単一コンポーネント
  • 求職者
    • SupportA2DP/HFP/LEA
最初のペア / 後続のペアの想定される動作
  • プロバイダは、ID アドレス(初期)または RPA(後続)を使用して Fast Pair サービスデータ(0xFE2C)をアドバタイズします。
    • 従来の広告を使用する
  • シーカーがキーベースのペア設定リクエストを送信します。
    • 鍵ベースのペア設定リクエストのフラグビット 5 が 1 に設定されている
  • プロバイダは、メッセージ タイプ 0x02 で鍵ベースのペア設定レスポンスを送信します。
    • ビット 0 は 0 にする必要があります
    • ビット 1 は 1 にする必要があります
    • 住所が身分証明書の住所と一致している
  • シーカーは、LE トランスポートの既存の LE 接続とボンドを作成します。
    • CTKD の方向は LE から BR/EDR へ
    • IO 機能が LE で DisplayYesNo に設定されている
  • シーカーとプロバイダがファスト ペアリングのパスキーの検証手続きを行う

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

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

MITM のシーケンス図

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

通知によってボンディングされるコンポーネントからパスキーを取得する

読み取りによってボンディングされるコンポーネントからパスキーを取得する

報告されている問題

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

一方、LEA をサポートしているが、LEA を介した正しいファスト ペアリングを実装していないヘッドセットで、多くの問題が発生しています(クラシック経由のファスト ペアリングのみ)。具体的には、プロバイダの RPA が正しい ID 解決キー(IRK)によって生成されず、住所を解決できない場合などです。ヘッドセットの構成を網羅的にテストすることはできませんでしたが、限定的なテストで、イヤホンのバッテリー残量の通知が表示されない、オーディオ スイッチング(SASS)機能がない、最初のペア設定とその後のペア設定が広範囲にわたって失敗するなどのさまざまな問題が明らかになりました。

したがって、パートナーには、デュアルモードをサポートする新しいデバイスとフィールド(無線アップデート経由)の既存のデバイスの両方にファスト ペアリング-LEA 仕様を実装することを強くおすすめします。