Bluetooth Low Energy (BLE)-Gerät

Die GFPS-Implementierung (Google Schnelles Pairing Service) für BLE-Geräte ist mit der Bluetooth Core Specification v4.2 oder höher kompatibel.

Der folgende Nachtrag zur Spezifikation für „Schnelles Pairing“ ermöglicht die Unterstützung von Geräten, die nur Low Energy (LE) und Low Energy Audio (LEA) unterstützen, in GFPS.

Konformitätsstufen

Die in der Spezifikation erwähnten Schlüsselwörter „shall“, „must“, „will“, „should“, „may“ und „can“ werden im Folgenden erläutert:

Begriff Beschreibung
shall is required to (muss): Wird verwendet, um Anforderungen zu definieren.
must wird verwendet, um Folgendes auszudrücken:
eine natürliche Folge einer zuvor angegebenen obligatorischen Anforderung
ODER
eine unbestreitbare Tatsachenbehauptung (eine, die unabhängig von den Umständen immer wahr ist).
will it is true that (es ist wahr, dass) – wird nur in Tatsachenbehauptungen verwendet.
sollte wird empfohlen: Wird verwendet, um anzugeben, dass eine von mehreren Möglichkeiten als besonders geeignet empfohlen wird, aber nicht erforderlich ist.
may is permitted to: wird verwendet, um Optionen zuzulassen.
dir is able to (ist in der Lage, zu) – wird verwendet, um eine Aussage kausal zu verknüpfen.

Schlüsselbasiertes Kopplungsmerkmal

Nachricht vom Suchenden an den Anbieter

In der Rohanfrage type 0x00 des schlüsselbasierten Kopplungsmerkmals wird Bit 4 verwendet, um anzugeben, ob der Sucher die BLE-Gerätespezifikation unterstützt, und Bit 5, um anzugeben, ob der Sucher LE Audio unterstützt.

Oktett Datentyp Beschreibung Wert Obligatorisch?
0 uint8 Mitteilungsart 0x00 = Schlüsselbasierte Kopplungsanfrage Obligatorisch
1 uint8 Flags
  • Bit 0 (MSB): veraltet und von Seeker ignoriert.
  • Bit 1: 1, wenn der Sucher den Anbieter auffordert, die Kopplung zu initiieren, und diese Anfrage die BR/EDR-Adresse des Suchers enthält. Andernfalls 0.
  • Bit 2: 1, wenn der Seeker den Provider auffordert, den vorhandenen Namen zu melden. Andernfalls 0.
  • Bit 3: 1, wenn dies für das rückwirkende Schreiben des Kontoschlüssels gilt. Andernfalls 0.
  • Bit 4: 1, wenn der Seeker die BLE-Gerätespezifikation unterstützt. Andernfalls 0.
  • Bit 5: 1, wenn der Sucher LE Audio unterstützt. Andernfalls 0.
  • Die Bits 6 und 7 sind für die zukünftige Verwendung reserviert und werden ignoriert.
 variiert Obligatorisch
2–7 uint48 Entweder:
  • Aktuelle BLE-Adresse des Anbieters
  • Identitätsadresse des Anbieters
 variiert Obligatorisch
8–13 uint48 BR/EDR-Adresse des Suchers variiert Wird nur angezeigt, wenn Bit 1 oder 3 des Flags 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 das Merkmal „Schlüsselbasiertes Pairing“ verwendet werden, um dem Suchenden zusätzliche Bonding-Optionen bereitzustellen.

Oktett Datentyp Beschreibung Wert
0 uint8 Mitteilungsart 0x02 = Erweiterte Antwort für schlüsselbasierte Kopplung
1 uint8 Flags
  • Bit 0 (MSB): 1, wenn der Anbieter ein reines LE-Gerät ist, andernfalls 0. Wenn Bit 0 auf 1 gesetzt ist, geht der Seeker davon aus, dass Bit 1 auf 1 gesetzt ist.
  • Bit 1: 1, wenn der Anbieter LE-Bonding bevorzugt, andernfalls 0.
  • Bit 2: 1, wenn der Adresstyp der zweiten Adresse „Zufällig“ ist, 0, wenn „Öffentlich“.
  • Bit 3–7 sind für die zukünftige Verwendung reserviert und werden ignoriert.
 variiert
2 uint8 Anzahl der Adressen des Anbieters
(In der aktuellen Version ist die Anzahl 1 oder 2, da wir den Blockverschlüsselungsmodus in AES-CTR ändern müssen, wenn die Anzahl >= 3 ist.)		 variiert
3–8 oder
3–14
  • Die erste Adresse muss die Identitätsadresse des primären Geräts sein und muss koppelbar sein, wenn die BR/EDR-Kopplung bevorzugt wird.
  • Die zweite Adresse muss die Bondable-Adresse des sekundären Geräts sein, sofern das sekundäre Gerät verfügbar ist.
 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 verstehen.

  • Wenn Bit 4 den Wert 0 hat, ignoriert der Anbieter Bit 5 und antwortet im Format type 0x01.
  • Wenn Bit 4 den Wert 1 hat,
    • Ein LE-only-Anbieter muss mit type 0x02 antworten, um die LE-Bonding-Präferenz anzugeben.
    • Ein Dual-Mode-Anbieter kann mit type 0x02 antworten, um entweder die BR/EDR- oder die LE-Bonding-Präferenz anzugeben.
  • Informationen zu LE Audio-Anbietern (LEA) im Dualmodus findest du unter Beispiel: Kopplung mit LEA-Anbieter im Dualmodus.

Nachrichtenstream-PSM-Merkmal (Protocol Service Multiplexor)

Zur Unterstützung des Nachrichtenstreams für BLE-Geräte wird bei der Funktion „Schnelles Pairing“ ein BLE-L2CAP-Kanal zum Senden und Empfangen von Nachrichten eingerichtet und aufrechterhalten. Schnelles Pairing Der L2CAP-Server muss die LE-guthabenbasierte Flusssteuerung implementieren.

Mit diesem Merkmal kann der Sucher den PSM-Wert lesen und dann eine sichere L2CAP-Verbindung über den PSM-Wert herstellen.

Merkmal des Fast Pair Service Verschlüsselt Berechtigungen UUID
Nachrichtenstream-PSM Ja Lesen FE2C1239-8366-4814-8EB0-01DE32100BEA
Oktett Datentyp Beschreibung Wert
0 uint8 Bundesland
  • 0x00 = Unbekannt. FP Seeker versucht es mehrmals.
  • 0x01 = Bereit für Verbindung
  • 0x02 = Nicht verfügbar. FP Seeker verwendet diese Komponente dieses Mal nicht, um eine Verbindung herzustellen
 variiert
1–2 uint16 Der PSM-Wert muss zwischen 0x80 und 0xFF liegen. variiert

Hinweis: TWS besteht aus zwei Komponenten: einer primären und einer sekundären. Die Rolle dieser Komponenten ist unter bestimmten Bedingungen austauschbar. Angenommen, A ist die primäre Komponente und B die sekundäre Komponente. Wenn der Akku von Komponente A leer ist , muss Komponente B die Rolle der primären Komponente übernehmen. Dieses Szenario wird als role switch bezeichnet.

Wenn der Anbieter nach role switch den Nachrichtenstream für die Funktion „Schnelles Pairing“ nicht verarbeiten kann, muss er die bestehende L2CAP-Verbindung proaktiv trennen. Der Schnelles Pairing-Sucher kann dann die L2CAP-Nachrichtenstreamverbindung mit der neuen primären Komponente wiederherstellen.

Zusätzliche Passkey-Eigenschaft

Dieses Merkmal dient dem Schutz vor MITM-Angriffen auf die zusätzlichen Komponenten.

CSIS Fake Member MITM Protection

Für die Funktion „Schnelles 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.

Definition des Merkmals

Merkmal des Dienstes „Schnelles Pairing“ Verschlüsselt Berechtigung UUID
Zusätzlicher Passkey Nein Lesen,Schreiben,Benachrichtigen FE2C123A-8366-4814-8EB0-01DE32100BEA

Nachrichten

Das Nachrichtenformat wird auf Lese-, Schreib- und Benachrichtigungsvorgänge angewendet.

Verschlüsseltes Datenformat

Die verschlüsselten Daten werden über eine GATT-Verbindung für „Schnelles Pairing“ gesendet.

Oktett Datentyp Beschreibung Wert
0-15 uint128 Verschlüsselter zusätzlicher Passkey-Block variiert
Rohdatenformat

Nach dem Entschlüsseln der verschlüsselten Daten mit dem gemeinsamen Secret sieht das Format so aus:

Oktett Datentyp Beschreibung Wert
0 uint8 Mitteilungsart einer der folgenden Werte:
  • 0x00 = Passkey des Suchers
  • 0x01 = Passkey des Anbieters
1-3 uint24 6-stelliger Passkey variiert
4–9 uint48 Adresse der Ziel-Bonding-Komponente variiert
10 uint8 Statuscode, der nur von Lesevorgängen verwendet wird Eine der folgenden Optionen:
  • 0x00 = Erfolg
  • 0x01 = Ausstehend. FP Seeker-Wiederholung bis Zeitüberschreitung
  • 0x02 = Fehler. FP-Sucher – Wiederholungsversuch beenden
11–15 Zufälliger Wert (Salt) variiert

Die primäre (erste gekoppelte Komponente) ist die Brücke zwischen dem Schnellen Pairing-Sucher und den zusätzlichen gekoppelten Komponenten. Die Eigenschaft muss den folgenden Richtlinien entsprechen:

  • Wenn der Anbieter eine Schreibanfrage vom Fast Pair-Sucher erhält, muss er Folgendes tun:
    • Adresse der Komponente festlegen, die verbunden wird
    • Hauptschlüssel an die zu koppelnde Komponente senden
    • Statuscode auf „Ausstehend“ (0x01) festlegen
  • Wenn der Anbieter eine Leseanfrage erhält, bevor er den Passkey von der zu koppelnden Komponente erhalten hat, muss er eine Nachricht mit
    • Passkey, beliebiger Wert
    • Adresse der Komponente, die verbunden wird
    • Statuscode „Ausstehend“, 0x01
  • Bevor der Anbieter eine Benachrichtigung an den Schnelles Pairing-Sucher sendet, legt er das Ergebnis für die Leseanfrage mit
    • Hauptschlüssel der zu verbindenden Komponente
    • Adresse der Komponente, die verbunden wird
    • Erfolgsstatuscode, 0x00
  • Wenn auf der Anbieterseite ein nicht behebbarer Fehler auftritt, legen Sie das Ergebnis fest.
    • Passkey, beliebiger Wert
    • Adresse der Komponente, die verbunden wird
    • Fehlerstatuscode, 0x02

Weitere Informationen finden Sie in MITM-Diagramm 1 und MITM-Diagramm 2.

Anforderungen an LE-Geräte

LE Advertising

Im sichtbaren oder nicht sichtbaren Modus muss der Anbieter RPA verwenden, um Fast Pair-Daten zu bewerben.

Bonding-Funktion

Bei LE-fähigen Geräten muss der Seeker eine Verbindung mit der vorhandenen LE-Verbindung herstellen. Nachdem die schlüsselbasierte Kopplung für „Schnelles Pairing“ erfolgreich überprüft wurde, muss der Anbieter die Kopplung mit RPA zulassen und die IO-Funktion für die Passkey-Überprüfung für „Schnelles Pairing“ auf „DisplayYesNo“ festlegen.

Geräteanforderungen für LEAs

LEA Advertising

Für Dual-Mode-Geräte: Im Modus „Sichtbar“ muss der Anbieter Schnelles Pairing-Daten mit der Identitätsadresse bewerben. Im nicht sichtbaren Modus muss der Anbieter Schnelles Pairing-Daten mit RPA bewerben. Es wird dringend empfohlen, die Legacy-Advertising-Funktion (BT 4.2) zu verwenden, um ältere Geräte für die Abwärtskompatibilität zu unterstützen. Der IRK muss geändert werden, wenn das Gerät auf die Werkseinstellungen zurückgesetzt wird.

Für Geräte ohne Dualmodus: Für den Modus „Sichtbar“ oder „Nicht sichtbar“ muss der Anbieter erweitertes Advertising (BT 5.0) mit RPA verwenden, um Fast Pair-Daten zu bewerben.

Die LE-verbindbare Werbung, die FP-Dienstdaten enthält, muss die CAS-UUID gemäß den Anforderungen des Bluetooth Adapter Profile (BAP 1.0.1) und des Common Audio Profile enthalten.

Der Anbieter kann die LEA-Fähigkeit angeben, indem er die CAS-UUID (0x1853) entweder in die Dienstdaten (Anzeigentyp 0x16) oder in die 16-Bit-Dienstklassen-UUIDs (Anzeigentyp 0x02 oder 0x03) aufnimmt, unabhängig vom Sichtbarkeitsmodus.

Wenn bei nicht erkennbaren Anzeigen aufgrund der Einbeziehung von Akku- und SASS-Daten nicht genügend Platz in der Legacy-Anzeige verfügbar ist, muss die CAS-UUID in die Scanantwort aufgenommen werden.

LEA-Bonding-Funktion

Der Seeker muss eine Verbindung mit der vorhandenen LE-Verbindung herstellen. Nachdem die schlüsselbasierte Kopplung für „Schnelles Pairing“ bestätigt wurde, muss der Dual-Mode-Anbieter die Kopplung mit der Identitätsadresse und der RPA zulassen, während der Nicht-Dual-Mode-Anbieter die Kopplung mit der RPA zulassen und die IO-Funktion für die Bestätigung des Hauptschlüssels für „Schnelles Pairing“ auf „DisplayYesNo“ festlegen muss.

Interner Kommunikationskanal zwischen Komponenten

Die bestehende GATT-Verbindung wird beibehalten, um MITM-Schutz für die zusätzlichen Komponenten zu bieten. Die primäre verbundene Komponente verarbeitet die Nachrichtenübermittlung zwischen dem Schnelles Pairing-Sucher und den übrigen Komponenten.

Die interne Kommunikation wird für Initial Pair und Subsequent Pair verwendet.

  • Wenn das schlüsselbasierte Kopplungsverfahren für die primäre Komponente erfolgreich ist, sendet die primäre Komponente eine Nachricht, um die E/A-Funktion der verbleibenden Komponenten zu ändern.
  • Wenn die schnelle Kopplung abgeschlossen ist, sendet die primäre Komponente eine Nachricht, um die E/A-Funktion der verbleibenden Komponenten zurückzusetzen.
  • Beim Ausführen des Verfahrens für zusätzliche Passkeys muss die primäre Komponente die Passkey-Übermittlung zwischen dem Schnelles Pairing-Sucher und den verbleibenden Komponenten verarbeiten.

Zeit zum Ändern der IO-Funktion

  • Ändern der E/A-Funktion in „DisplayYesNo“, wenn das schlüsselbasierte Kopplungsverfahren erfolgreich war
    • Wenn das Gerät mehrere Komponenten hat, müssen alle Komponenten auf „DisplayYesNo“ festgelegt 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. Siehe Nachricht vom Sucher an den Anbieter.
  • IO-Funktion auf Standardeinstellung ändern
    • Erstmalige Kopplung
      • Wenn die LE-Verbindung getrennt wird, wird die Sitzung für „Schnelles Pairing“ beendet.
      • Wenn nach dem Koppeln des primären Geräts innerhalb von 15 Sekunden keine weitere Anfrage zum Schreiben des Hauptschlüssels eingeht, wird die Schnelles Pairing-Sitzung beendet.
      • Wenn nach dem Empfang einer zusätzlichen Passkey-Schreibanfrage die zu koppelnde Komponente nicht innerhalb von 15 Sekunden gekoppelt wird, wird die „Schnelles Pairing“-Sitzung beendet.
      • Wenn nach dem Koppeln aller Komponenten innerhalb von 15 Sekunden keine Anfrage zum Schreiben des Kontoschlüssels erfolgt, wird die Sitzung für die Funktion „Schnelles Pairing“ beendet.
      • Nachdem die Schreibanfrage für den Kontoschlüssel empfangen wurde, wird ein Zeitlimit von 15 Sekunden festgelegt, um die Sitzung für „Schnelles Pairing“ zu beenden.
    • Nachfolgende Kopplung
      • Wenn die LE-Verbindung getrennt wird, wird die Sitzung für „Schnelles Pairing“ beendet.
      • Wenn nach dem Koppeln des primären Geräts innerhalb von 15 Sekunden keine weitere Anfrage zum Schreiben eines Passkeys erfolgt, wird die Schnelles Pairing-Sitzung beendet.
      • Wenn nach dem Empfang einer zusätzlichen Passkey-Schreibanfrage die zu koppelnde Komponente nicht innerhalb von 15 Sekunden gekoppelt wird, wird die „Schnelles Pairing“-Sitzung beendet.
      • Wenn alle Komponenten verbunden sind, beende die Sitzung für „Schnelles Pairing“.

UI-Anzeige ausblenden

Wenn das Headset nicht für die Kopplung bereit ist, verwendet der Anbieter type 0b0010, um die Anzeige der Benutzeroberfläche für Kontoschlüsseldaten auszublenden. Dadurch wird der Sucher angewiesen, die nachfolgende Benutzeroberfläche für die Kopplung nicht anzuzeigen (siehe Advertising-Nutzlast: Schnelles Pairing-Kontodaten).

Anforderungen an LE Audio-Geräte

Bluetooth-Anforderungen

Empfehlungen für LE Audio-Headsets für Android

CTKD-Unterstützung

Bei Dual-Mode-Geräten ist CTKD von LE zu BR/EDR obligatorisch und entspricht den BAP-Anforderungen.

Zielankündigung

Ein Peripheriegerät muss die gezielte Ankündigung verwenden, um eine Verbindung von einem gekoppelten zentralen Gerät anzufordern. Targeted Announcements sind in BAP und CAP für die Verbindungsverwaltung gemäß CAP 1.0, Tabelle 8.4 (S. 48/58) definiert.

GATT-EATT-Serverunterstützung

Mit EATT kann das zentrale Gerät mehrere GATT-Transaktionen parallel senden, wenn das Gerät gekoppelt ist. Bei Geräten, die CSIP unterstützen, wird die Leistung der Profilverbindung erhöht und dann bald das CSIP-Bonding-Verfahren für die anderen Kopfhörer gestartet.

Wenn der Anbieter kein einzelnes Gerät, sondern ein koordiniertes Set mit CSIP-Implementierung ist, sollte er das in Bluetooth 5.1 definierte GATT-Caching implementieren, um die Anzahl der Service Discoveries zu reduzieren und die Verbindung zu beschleunigen.

Anforderungen für die Funktion „Schnelles Pairing“

LE Advertising

Wenn das Gerät mehrere Komponenten hat, müssen die Schnelles Pairing-Daten im sichtbaren oder nicht sichtbaren Modus von der primären Komponente gesendet werden. Wenn das Gerät nicht für die nachfolgende Kopplung bereit ist, kann die sekundäre Komponente Schnelles Pairing-Daten für erweiterte Funktionen bewerben. Weitere Informationen findest du unter UI-Anzeige ausblenden.

GATT-Dienstsichtbarkeit

Die GATT-Datenbank muss für alle LE-Transport-GATT-Verbindungen gleich sein. Der LE-Audiodienst (0x184E) muss in der GATT-Datenbank der Verbindung für „Schnelles Pairing“ enthalten sein.

Beispiel: Kopplung mit LEA-Dual-Mode-Anbieter

Szenario 1: Der Seeker unterstützt LEA nicht

Der Provider muss abwärtskompatibel mit dem Seeker sein, der LEA nicht unterstützt.

Komponenten
  • Anbieter: A2DP/HFP/LEA
  • Seeker: A2DP/HFP
Erwartetes Verhalten bei der ersten Kopplung / nachfolgenden Kopplungen
  • Der Anbieter bewirbt die „Schnelles Pairing“-Dienstdaten (0xFE2C) mit der Identitätsadresse (anfänglich) oder der RPA (nachfolgend).
    • Legacy-Advertising verwenden
  • Der Seeker empfängt die Anzeige des Providers mit der Identitätsadresse für die erste Kopplung oder der RPA für die nachfolgende Kopplung.
  • Der Sucher sendet eine schlüsselbasierte Kopplungsanfrage.
    • Das Flag-Bit 5 der schlüsselbasierten Kopplungsanfrage ist auf 0 gesetzt.
  • Der Anbieter sendet eine schlüsselbasierte Kopplungsantwort mit der öffentlichen Adresse in einem der folgenden Formate:
    • Wenn der Nachrichtentyp 0x01 verwendet wird, muss die Adresse eine öffentliche Adresse sein.
    • Wenn der Nachrichtentyp 0x02 verwendet wird:
      • Bit-0 muss 0 sein
      • Bit-1 muss 0 sein
      • Die Adresse muss eine öffentliche Adresse sein.
  • Der Sucher erstellt eine Bindung mit BR/EDR-Transport.
    • IO-Funktion ist für BR/EDR auf „DisplayYesNo“ festgelegt
  • Der Seeker und der Provider führen das Verfahren zur Passkey-Überprüfung für die Funktion „Schnelles Pairing“ durch.

Szenario 2: Der Seeker unterstützt LEA

Komponenten
  • Anbieter
    • Unterstützung für A2DP/HFP/LEA
    • Einzelne Komponente
  • Seeker
    • Unterstützung von A2DP/HFP/LEA
Erwartetes Verhalten bei der ersten Kopplung / nachfolgenden Kopplungen
  • Der Anbieter bewirbt die „Schnelles Pairing“-Dienstdaten (0xFE2C) mit der Identitätsadresse (anfänglich) oder der RPA (nachfolgend).
    • Legacy-Advertising verwenden
  • Der Sucher sendet eine schlüsselbasierte Kopplungsanfrage.
    • Das Flag-Bit 5 der schlüsselbasierten Kopplungsanfrage 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 Adresse im Ausweisdokument
  • Der Sucher erstellt eine Bindung mit der vorhandenen LE-Verbindung über den LE-Transport.
    • CTKD-Richtung ist von LE zu BR/EDR
    • IO-Funktion ist für LE auf DisplayYesNo festgelegt
  • Der Seeker und der Provider führen das Verfahren zur Passkey-Überprüfung für die Funktion „Schnelles Pairing“ durch.

Szenario 3: Der Seeker unterstützt LEA und CSIP ist beteiligt.

Komponenten
  • Anbieter
    • Unterstützung für A2DP/HFP/LEA
    • Mehrere Komponenten
      • Primäre Komponente ist BR/EDR/LE
      • Sekundäre Komponente ist nur für LE
  • Seeker
    • Unterstützung für A2DP/HFP/LEA
Erwartetes Verhalten bei der ersten Kopplung / nachfolgenden Kopplungen
  • Die primäre Komponente kündigt die Schnelles Pairing-Dienstdaten (0xFE2C) mit der Identitätsadresse (anfänglich) oder der RPA (nachfolgend) an.
    • Legacy-Advertising verwenden
  • Der Seeker sendet eine schlüsselbasierte Kopplungsanfrage an die primäre Komponente.
    • Das Flag-Bit 5 der schlüsselbasierten Kopplungsanfrage ist auf 1 gesetzt.
  • Die primäre Komponente sendet eine Antwort auf die schlüsselbasierte Kopplung mit dem Nachrichtentyp 0x02.
    • Bit-0 muss 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 verbindbare Adresse für die sekundäre Komponente. Die zweite Komponente verwendet diese Adresse auch für die CSIP-Ankündigung.
  • Der Seeker erstellt eine Bindung mit der primären Komponente über die bestehende LE-Verbindung.
    • CTKD-Richtung ist von LE zu BR/EDR
    • IO-Funktion ist für LE auf DisplayYesNo festgelegt
  • Der Seeker stellt eine Verbindung zur sekundären Komponente her, deren Adresse aus der erweiterten Antwort für die schlüsselbasierte Kopplung stammt.
    • Die E/A-Funktion muss „DisplayYesNo“ sein, andernfalls wird die Kopplungsanfrage abgelehnt.
  • Der Seeker und der Provider führen das MITM-Schutzverfahren für die Kopplung der sekundären Komponente durch. Der Provider muss beide Szenarien implementieren.
  • Der Seeker wartet, bis er mit der sekundären Komponente verbunden ist.

Sequenzdiagramm für MITM

In dieser Sitzung wird die Abfolge des MITM-Schutzverfahrens beschrieben.

Passkey von der Komponente abrufen, die per Benachrichtigung gekoppelt wird

Passkey von der Komponente abrufen, die durch Lesen gebunden wird

Bekanntes Problem

FP für LEA wurde für die Verwendung mit Android V (Android 15) optimiert.

Andererseits sind bei Headsets, die LEA unterstützen, aber nicht die richtige Implementierung von „Schnelles Pairing“ über LEA haben (d.h. nur „Schnelles Pairing“ über Classic), zahlreiche Probleme aufgetreten. Dies ist beispielsweise der Fall, wenn die RPA des Anbieters nicht mit dem richtigen IRK (Identity Resolving Key) generiert wird und die Adresse nicht aufgelöst werden kann. Wir konnten zwar keine umfassende Liste von Kopfhörerkonfigurationen testen, aber unsere begrenzten Tests haben verschiedene Probleme aufgezeigt, darunter das Fehlen von Benachrichtigungen zum Akkustatus der Kopfhörer, das Fehlen der Funktion „Audio-Wechsel“ (SASS), weit verbreitete Fehler bei der ersten und nachfolgenden Kopplung und mehr.

Daher empfehlen wir Partnern dringend, die Schnelles Pairing-LEA-Spezifikation sowohl für neue Geräte als auch für vorhandene Geräte (über Over-the-Air-Updates) zu implementieren, die Dual-Modi unterstützen.