Bluetooth Low Energy (BLE)-Gerät
Die Implementierung des Google Fast Pair Service (GFPS) für BLE-Geräte ist mit der Bluetooth Core Specification Version 4.2 oder höher kompatibel.
Mit dem folgenden Zusatz zur Fast Pair-Spezifikation wird die Unterstützung von LE- (Low Energy) und LEA-Geräten (Low Energy Audio) in GFPS ermöglicht.
Konformitätsstufen
Die in der Spezifikation genannten Schlüsselwörter „shall“, „must“, „will“, „should“, „may“ und „can“ werden unten erläutert:
| Laufzeit | Beschreibung |
|---|---|
| shall | is required to – wird zum Definieren von Anforderungen verwendet. |
| muss | wird verwendet, um eine natürliche Folge einer zuvor genannten obligatorischen Anforderung ODER eine unbestreitbare Tatsachenbehauptung (die unabhängig von den Umständen immer wahr ist) auszudrücken. |
| wird | Stimmt es, dass es nur in Tatsachenbehauptungen verwendet wird. |
| sollte | wird empfohlen: Hiermit wird angegeben, dass eine von mehreren Möglichkeiten als besonders geeignet empfohlen wird, aber nicht erforderlich ist. |
| Mai | is permitted to: Wird verwendet, um Optionen zuzulassen. |
| kann | ist in der Lage: Wird verwendet, um eine Aussage auf kausale Weise zu verknüpfen. |
Schlüsselbasierte Kopplungseigenschaft
Nachricht vom Suchenden an den Anbieter
Die Rohanfrage type 0x00 der Charakteristik der schlüsselbasierten Kopplung gibt mit Bit 4 an, ob der Seeker die BLE Device Specification unterstützt, und mit Bit 5, ob der Seeker LE Audio unterstützt.
| Octet | Datentyp | Beschreibung | Wert | Ist das obligatorisch? |
|---|---|---|---|---|
| 0 | uint8 |
Mitteilungsart | 0x00 = Schlüsselbasierte Kopplungsanfrage |
Obligatorisch |
| 1 | uint8 |
Flags
|
variiert | Obligatorisch |
| 2–7 | uint48 |
Sie haben folgende Möglichkeiten:
|
variiert | Obligatorisch |
| 8–13 | uint48 |
Adresse des Antragstellers für die Beantragung einer Aufenthaltsgenehmigung | variiert | Nur vorhanden, wenn Flags-Bit 1 oder 3 gesetzt ist |
| n – 15 | Zufälliger Wert (Salt) | variiert | Obligatorisch |
Nachricht vom Anbieter an den Suchenden
Wenn Bit 4 der Anfrage festgelegt ist, kann die neue Antwortnachricht type 0x02 für die Eigenschaft „Schlüsselbasiertes Koppeln“ verwendet werden, um dem Sucher zusätzliche Kopplungsoptionen zur Verfügung zu stellen.
| Octet | Datentyp | Beschreibung | Wert |
|---|---|---|---|
| 0 | uint8 |
Mitteilungsart | 0x02 = Erweiterte Antwort für die Schlüsselbasierte Kopplung |
| 1 | uint8 |
Markierungen
|
variiert |
| 2 | uint8 |
Anzahl der Adressen des Anbieters (in der aktuellen Version ist die Zahl 1 oder 2, da wir den Blockverschlüsselungsmodus in AES-CTR ändern müssen, wenn die Zahl größer als 3 ist) |
variiert |
| 3–8 oder 3–14 |
|
variiert | |
| 9–15 oder 15 | Zufälliger Wert (Salt) | variiert |
Ein Anbieter, der die BLE-Gerätespezifikation unterstützt, muss Bit 4 und Bit 5 lesen, um die Funktionen des Suchers zu ermitteln.
- Wenn Bit 4 den Wert 0 hat, ignoriert der Anbieter Bit 5 und antwortet im
type 0x01-Format. - Wenn Bit 4 1 ist,
- Bei einem Nur-LE-Anbieter muss er mit
type 0x02antworten, um die LE-Bonding-Präferenz anzugeben. - Bei Dual-Mode-Anbietern kann mit
type 0x02geantwortet werden, um entweder die BR/EDR- oder LE-Kopplungspräferenz anzugeben.
- Bei einem Nur-LE-Anbieter muss er mit
- Für Anwendungsfälle mit LE Audio (LEA)-Dualmode-Anbietern siehe Beispiel: Koppeln mit einem LEA-Dualmode-Anbieter.
Charakteristik der Nachrichtenstream-PSM (Protocol Service Multiplexor)
Um den Nachrichtenstream für BLE-Geräte zu unterstützen, richtet Fast Pair einen BLE-L2CAP-Kanal zum Senden und Empfangen von Nachrichten ein und unterhält ihn. Der Fast Pair-L2CAP-Server muss eine LE-Guthabenbasierte Ablaufsteuerung implementieren.
Mit dieser Eigenschaft kann der Sucher den PSM-Wert lesen und dann eine sichere L2CAP-Verbindung über den PSM-Wert herstellen.
| Fast Pair-Diensteigenschaft | Verschlüsselt | Berechtigungen | UUID |
|---|---|---|---|
| Nachrichtenstream – PSM | Ja | Lesen | FE2C1239-8366-4814-8EB0-01DE32100BEA |
| Octet | Datentyp | Beschreibung | Wert |
|---|---|---|---|
| 0 | uint8 |
Status
|
variiert |
| 1–2 | uint16 |
Der PSM-Wert muss zwischen 0x80 und 0xFF liegen. | variiert |
Hinweis:Für TWS gibt es zwei Komponenten: primär und sekundär. Die Rolle dieser Komponenten ist unter bestimmten Bedingungen austauschbar. Angenommen, A ist die primäre Komponente und B die sekundäre Komponente. Aufgrund der Akkuentladung bei Komponente A muss Komponente B die Rolle der primären Komponente übernehmen. Dieses Szenario wird als role switch bezeichnet.
Wenn der Anbieter den Fast Pair-Nachrichtenstream nach role switch nicht verarbeiten kann, muss er die bestehende L2CAP-Verbindung proaktiv trennen. Der Fast Pair-Sucher kann dann die L2CAP-Nachrichtenstreamverbindung mit der neuen primären Komponente wiederherstellen.
Zusätzliche Passkey-Eigenschaft
Diese Eigenschaft bietet MITM-Schutz für die zusätzlichen Komponenten.
CSIS Fake Member MITM Protection
Für das schnelle Pairing ist im Rahmen des Kopplungsvorgangs ein MITM-Schutz erforderlich. Da CSIS keinen MITM-Schutz bietet, muss das aktuelle Design für FP für mehrere Komponenten erweitert werden, um MITM-Schutz für die zusätzlichen Komponenten zu bieten.
Charakteristische Definition
| Fast Pair-Diensteigenschaft | Verschlüsselt | Berechtigung | UUID |
|---|---|---|---|
| Zusätzlicher Passkey | Ja | Lesen,Schreiben,Benachrichtigen | FE2C123A-8366-4814-8EB0-01DE32100BEA |
Nachrichten
Das Nachrichtenformat wird auf Lese-, Schreib- und Benachrichtigungsvorgänge angewendet.
Format für verschlüsselte Daten
Die verschlüsselten Daten werden über die Fast Pair GATT-Verbindung gesendet.
| Oktett | Datentyp | Beschreibung | Wert |
|---|---|---|---|
| 0-15 | uint128 | Verschlüsselter Block mit zusätzlichen Passkeys | variiert |
Format der Rohdaten
Nach der Entschlüsselung der verschlüsselten Daten mit dem gemeinsamen Geheimnis hat das Format das folgende Format:
| Oktett | Datentyp | Beschreibung | Wert |
|---|---|---|---|
| 0 | uint8 | Mitteilungsart | eine von
|
| 1-3 | uint24 | 6-stelliger Passkey | variiert |
| 4-9 | uint48 | Adresse der Zielbindungskomponente | variiert |
| 10 | uint8 | Statuscode, wird nur für Lesevorgänge verwendet | Eine der
|
| 11–15 | Zufälliger Wert (Salt) | variiert |
Die primäre Verbindung (erste verknüpfte Komponente) ist die Brücke zwischen dem schnellen Pairing-Sucher und den zusätzlichen Bindungskomponenten. Das Merkmal muss den Richtlinien entsprechen:
- Wenn der Anbieter eine Schreibanfrage vom Fast Pair Seeker erhält, muss er
- Adresse der gebundenen Komponente festlegen
- Senden Sie den Passkey an die zu verknüpfende Komponente.
- Statuscode auf „Ausstehend“, 0x01 setzen
- Wenn der Anbieter eine Leseanfrage erhält, bevor er den Passkey von der gekoppelten Komponente erhält, muss er eine Nachricht mit folgendem Inhalt zurückgeben:
- Passkey, beliebiger Wert
- Adresse der zu verklebten Komponente
- Statuscode „Ausstehend“, 0x01
- Bevor der Anbieter eine Benachrichtigung an den Fast Pair Seeker sendet, setzt er das Ergebnis für den Leseaufruf mit
- Passkey der zu verknüpfenden Komponente
- Adresse der zu verklebten Komponente
- Erfolgreicher Statuscode, 0x00
- Wenn ein nicht wiederherstellbarer Fehler auf Anbieterseite auftritt, setze das Ergebnis auf
- Passkey, beliebiger Wert
- Adresse der zu verklebten Komponente
- Fehlerstatuscode, 0x02
Weitere Informationen finden Sie in den Abbildungen MITM-Diagramm 1 und MITM-Diagramm 2.
Anforderungen an LE-Geräte
LE Advertising
Sowohl im Sichtbarkeitsmodus als auch im nicht sichtbaren Modus muss der Anbieter RPA verwenden, um FastPair-Daten zu veröffentlichen.
Bonding-Fähigkeit
Bei LE-fähigen Geräten muss der Sucher eine Verknüpfung mit der vorhandenen LE-Verbindung herstellen. Nachdem die keybasierte Kopplungsbestätigung für das schnelle Pairing bestanden wurde, muss der Anbieter die Kopplung mit RPA zulassen und die IO-Funktion für die Bestätigung des Fast Pair-Passkeys auf „DisplayYesNo“ setzen.
LEA-Geräteanforderungen
LEA Advertising
Für Dual-Mode-Geräte: Im Modus „Auffindbar“ muss der Anbieter Fast Pair-Daten mit der Identitätsadresse angeben. Im Modus „Nicht auffindbar“ bewirbt der Anbieter Daten über schnelles Pairing mit RPA. Wir empfehlen dringend, Legacy-Anzeigen (BT 4.2) zu verwenden, um ältere Geräte zur Abwärtskompatibilität zu unterstützen. Der IRK muss bei jedem Zurücksetzen des Geräts auf die Werkseinstellungen geändert werden.
Für Geräte ohne Dual-Modus: Für den Modus „Sichtbar“ oder „Nicht auffindbar“ muss der Anbieter Extended Advertising (BT 5.0) mit RPA verwenden, um FastPair-Daten zu bewerben.
Die LE-verbindbare Werbung mit FP-Dienstdaten muss die CAS-UUID gemäß den Anforderungen des Bluetooth-Adapterprofils (BAP 1.0.1) und des Common Audio Profile enthalten. Wenn für nicht auffindbare Anzeigen in der alten Werbung aufgrund der Aufnahme von Akku- und SASS-Daten nicht genügend Speicherplatz verfügbar ist, muss in diesem Fall die CAS-UUID in die Scanantwort aufgenommen werden.
LEA-Bonding-Funktion
Der Seeker muss eine Bindung zur vorhandenen LE-Verbindung herstellen. Nachdem die keybasierte Kopplungsbestätigung für das schnelle Pairing bestanden wurde, muss der Dual-Mode-Anbieter die Kopplung mit der Identitätsadresse und RPA zulassen. Anbieter ohne Dual-Mode müssen die Kopplung mit RPA zulassen und die IO-Funktion für die Bestätigung des Passkeys für das schnelle Pairing auf „DisplayYesNo“ setzen.
Interner Kommunikationskanal zwischen Komponenten
Die vorhandene GATT-Verbindung wird beibehalten, um MITM-Schutz für die zusätzlichen Komponenten zu bieten. Die primär verbundene Komponente soll Nachrichtenübermittlungen zwischen dem „Fast Pair Seeker“ und seinen verbleibenden Komponenten verarbeiten.
Die interne Kommunikation wird für Initial Pair und Subsequent Pair verwendet
- Wenn das schlüsselbasierte Kopplungsverfahren die primäre Komponente weitergibt, sendet die primäre Komponente eine Nachricht, um die E/A-Funktionen der verbleibenden Komponenten zu ändern.
- Wenn schnelles Pairing abgeschlossen ist, sendet die Hauptkomponente eine Nachricht, um die E/A-Funktionen ihrer verbleibenden Komponenten zurückzusetzen.
- Bei der Ausführung des zusätzlichen Passkey-Verfahrens muss die primäre Komponente die Passkey-Übermittlungen zwischen dem Fast Pair Seeker und den übrigen Komponenten verarbeiten.
Zeit, die I/O-Funktion zu ändern
- Ändern Sie die IO-Funktion in „DisplayYesNo“, wenn das schlüsselbasierte Kopplungsverfahren bestanden hat.
- Wenn das Gerät mehrere Komponenten hat, müssen alle Komponenten auf DisplayYesNo eingestellt werden.
- Eine Ausnahme, bei der der Anbieter die E/A-Funktion nicht in „DisplayYesNo“ ändern darf, ist
Retroactive Pair, dessen Bit 3 der schlüsselbasierten Kopplungsanfrage auf 1 gesetzt ist. Weitere Informationen finden Sie unter Nachricht vom Sucher an den Anbieter.
- E/A-Funktion auf Standardeinstellung ändern
- Erste Kopplung
- Wenn die LE-Verbindung getrennt ist, „Schnelles Pairing“ beenden
- Wenn nach der Kopplung des primären Geräts innerhalb von 15 Sekunden keine weitere Schreibanfrage für den Passkey erfolgt, wird die Fast Pair-Sitzung beendet.
- Wenn eine zusätzliche Passkey-Schreibanfrage eingegangen ist und die zu verknüpfende Komponente nicht innerhalb von 15 Sekunden verbunden ist, beenden Sie die Sitzung mit dem schnellen Pairing.
- Wenn alle Komponenten verbunden sind und innerhalb von 15 Sekunden keine Anfrage zum Schreiben des Kontoschlüssels erfolgt, beenden Sie die Sitzung mit dem schnellen Pairing.
- Nach Erhalt der Schreibanfrage für den Kontoschlüssel ein Zeitlimit von 15 Sekunden festlegen, um die Fast Pair-Sitzung zu beenden
- Nachfolgende Kopplung
- Wenn die LE-Verbindung getrennt ist, „Schnelles Pairing“ beenden
- Wenn nach der Kopplung des primären Geräts innerhalb von 15 Sekunden keine weitere Schreibanfrage für den Passkey erfolgt, die Fast Pair-Sitzung beenden
- Wenn die zu verknüpfende Komponente nach Erhalt einer zusätzlichen Passkey-Schreibanfrage nicht innerhalb von 15 Sekunden verknüpft ist, beenden Sie die Fast Pair-Sitzung.
- Wenn alle Komponenten verbunden sind, Fast Pair-Sitzung beenden
- Erste Kopplung
UI-Anzeige ausblenden
Wenn das Headset nicht zum Koppeln bereit ist, muss der Anbieter type 0b0010 verwenden, um die UI-Anzeige für Kontoschlüsseldaten auszublenden, damit der Seeker angewiesen wird, die UI für nachfolgende Kopplung nicht anzuzeigen (siehe Werbenutzlast: Kontodaten über schnelles Pairing).
Geräteanforderungen für LE Audio
Bluetooth-Anforderungen
Empfehlungen für Android-LE Audio-Kopfhörer
CTKD-Unterstützung
Für Geräte im Dual-Modus ist CTKD von LE zu BR/EDR obligatorisch und entspricht den BAP.
Zielankündigung
Peripheriegerät muss eine gezielte Ankündigung verwenden, um eine Verbindung von einem gekoppelten zentralen Gerät anzufordern. „Targeted Announcements“ wird in BAP und CAP für die Verbindungsverwaltung gemäß Tabelle 8.4 (Seite 48/58) von CAP 1.0 definiert.
GATT EATT-Serversupport
Mit EATT kann das zentrale Gerät mehrere GATT-Transaktionen parallel senden, wenn das Gerät verbunden ist. Bei Geräten, die CSIP unterstützen, wird die Leistung der Profilverbindung erhöht und dann beginnt bald der CSIP-Bindungsprozess für die anderen In-Ear-Kopfhörer.
Robustes GATT-Caching (dringend empfohlen)
Wenn der Anbieter kein einzelnes Gerät, sondern ein koordinierter Satz mit CSIP-Implementierung ist, sollte er GATT-Caching implementieren, wie in Bluetooth 5.1 definiert, um die Anzahl der Dienstermittlungen zu reduzieren und die Verbindung zu beschleunigen.
Anforderungen für das schnelle Pairing
LE Advertising
Wenn das Gerät im Modus „Sichtbar“ oder „Nicht sichtbar“ mehrere Komponenten hat, werden Daten über die Funktion „Schnelles Pairing“ von der Hauptkomponente beworben. Wenn das Gerät nicht für eine nachfolgende Kopplung bereit ist, kann die sekundäre Komponente Fast Pair-Daten für erweiterte Funktionen angeben. Weitere Informationen finden Sie unter UI-Anzeige ausblenden.
Sichtbarkeit des GATT-Dienstes
Die GATT-Datenbank muss für alle LE-Transport-GATT-Verbindungen gleich sein. Der LE Audio-Dienst (0x184E) muss in der GATT-Datenbank für Verbindungen über schnelles Pairing enthalten sein.
Beispiel: Kopplung mit LEA-Dual-Modus-Anbieter
Szenario 1: Wenn die Suchanfrage keine LEA unterstützt
Der Anbieter muss abwärtskompatibel mit dem Sucher sein, der keine LEA unterstützt.
Komponenten
- Anbieter: A2DP/HFP/LEA
- Sucher: A2DP/HFP
Erwartetes Verhalten bei der ersten Kopplung / nachfolgenden Kopplung
- Der Anbieter sendet Fast Pair-Dienstdaten (0xFE2C) mit der Identitätsadresse (initial) oder RPA (nachfolgend).
- Alte Anzeigen verwenden
- Der Seeker erhält die Anzeige des Anbieters mit der Identitätsadresse für die erste oder der RPA für die nachfolgende Kopplung
- Der Sucher sendet eine Anfrage zum schlüsselbasierten Koppeln.
- Das Flag-Bit 5 der schlüsselbasierten Kopplungsanfrage ist auf 0 gesetzt.
- Der Anbieter sendet eine schlüsselbasierte Kopplungsantwort mit der öffentlichen Adresse in einer der folgenden Formen:
- Wenn der Nachrichtentyp 0x01 verwendet wird, muss es sich um eine öffentliche Adresse handeln.
- Wenn der Nachrichtentyp 0x02 verwendet wird
- Bit 0 muss 0 sein.
- Bit 1 muss 0 sein.
- Die Adresse muss öffentlich zugänglich sein.
- Der Seeker schafft eine Bindung zum BR/EDR-Transport.
- Die IO-Funktion ist für BR/EDR auf „DisplayYesNo“ gesetzt.
- Der Sucher und der Anbieter führen einen Passkey für das schnelle Pairing durch.
Szenario 2: Der Suchende unterstützt die Strafverfolgungsbehörden
Komponenten
- Anbieter
- Unterstützung von A2DP/HFP/LEA
- Einzelne Komponente
- Sucher
- SupportA2DP/HFP/LEA
Erwartetes Verhalten bei der ersten Kopplung / nachfolgenden Kopplung
- Der Anbieter sendet Fast Pair-Dienstdaten (0xFE2C) mit der Identitätsadresse (initial) oder RPA (nachfolgend).
- Alte Anzeigen verwenden
- Der Sucher sendet eine Anfrage zum schlüsselbasierten Koppeln.
- Das Flag-Bit 5 der Anfrage für die schlüsselbasierte Kopplung ist auf 1 gesetzt.
- Der Anbieter sendet eine schlüsselbasierte Kopplungsantwort mit dem Nachrichtentyp 0x02.
- Bit 0 muss 0 sein.
- Bit 1 muss „1“ sein.
- Die Adresse ist die Identitätsadresse.
- Der Sucher stellt eine Verbindung zur vorhandenen LE-Verbindung im LE-Transport her.
- CTKD-Richtung ist von LE zu BR/EDR
- Die IO-Funktion ist für LE auf „DisplayYesNo“ festgelegt.
- Der Sucher und der Anbieter führen einen Passkey für das schnelle Pairing durch.
Szenario 3 – Wenn die Suchanfrage die Zusammenarbeit mit einer Strafverfolgungsbehörde und einer CSIP unterstützt
Komponenten
- Anbieter
- Unterstützung von A2DP/HFP/LEA
- Mehrere Komponenten
- Hauptkomponente ist BR/EDR/LE
- Sekundäre Komponente ist nur LE
- Sucher
- Unterstützung von A2DP/HFP/LEA
Erwartetes Verhalten für erstes und nachfolgendes Paar
- Die Hauptkomponente bietet Dienstdaten für schnelles Pairing (0xFE2C) mit der Identitätsadresse (Initiale) oder RPA (nachfolgend) an.
- Alte Anzeigen verwenden
- Der Seeker sendet eine Anfrage für eine schlüsselbasierte Kopplung an die Hauptkomponente.
- Das Flag-Bit 5 der schlüsselbasierten Kopplungsanfrage ist auf 1 gesetzt.
- Die Hauptkomponente sendet eine schlüsselbasierte Kopplungsantwort mit dem Nachrichtentyp 0x02.
- Bit-0 wird 0 sein.
- Bit 1 muss „1“ sein.
- Die Adresse lautet:
- Die erste Adresse ist die Identitätsadresse der primären Komponente.
- Die zweite Adresse ist die Adresse für die Bündelung der sekundären Komponente. Die zweite Komponente verwendet diese Adresse auch für die CSIP.
- Der Seeker baut eine Bindung zur primären Komponente der vorhandenen LE-Verbindung auf.
- CTKD-Richtung ist von LE zu BR/EDR
- Die IO-Funktion ist für LE auf „DisplayYesNo“ festgelegt.
- Der Sucher stellt eine Verbindung zur sekundären Komponente her, deren Adresse aus der erweiterten Antwort der schlüsselbasierten Kopplung stammt.
- Die IO-Funktion muss „DisplayYesNo“ sein. Andernfalls wird die Kopplungsanfrage abgelehnt.
- Der Sucher und der Anbieter führen ein MITM-Schutzverfahren für die Kopplung der sekundären Komponente durch. Der Anbieter muss beide Szenarien implementieren.
- Der Sucher wartet, bis eine Verbindung zur sekundären Komponente hergestellt wurde.
Sequenzielles Diagramm für MITM
In dieser Sitzung wird die Abfolge der MITM-Schutzverfahren beschrieben.
Passkey von der Komponente abrufen, die über eine Benachrichtigung gekoppelt wird
Passkey von der Komponente abrufen, die durch Lesen gekoppelt wird
Bekanntes Problem
FP für LEA wurde für Android V(Android 15) optimiert.
Umgekehrt haben wir zahlreiche Probleme mit Headsets festgestellt, die LEA unterstützen, aber nicht die korrekte Implementierung von „Schnelles Pairing über LEA“ haben (d.h. nur „Schnelles Pairing über Classic“). Das ist beispielsweise der Fall, wenn die RPA des Anbieters nicht vom richtigen Identitätsauflösungsschlüssel (Identity Resolving Key, IRK) generiert wird und die Adresse nicht aufgelöst werden kann. Wir konnten zwar nicht alle Headsetkonfigurationen testen, aber unsere begrenzten Tests haben verschiedene Probleme aufgedeckt, darunter das Ausbleiben von Benachrichtigungen zur Akkulaufzeit der In-Ear-Kopfhörer, fehlende Funktionen für die Audioumschaltung (SASS) und häufige Probleme bei der Erst- und Folgekopplung.
Daher empfehlen wir Partnern dringend, die Fast Pair-LEA-Spezifikation sowohl für neue Geräte als auch für bestehende Geräte im Einsatz (über Over-the-air-Updates) zu implementieren, die Dualmodi unterstützen.