Werbesignal des Anbieters

Werbung: Wenn sichtbar

Wenn das Anbietergerät über BR/EDR erkennbar ist (d. h. im Kopplungsmodus), muss es die Daten der Fast Pair-Modell-ID über BLE übertragen und die BLE-Adresse darf nicht geändert werden.

Werbeintervall: Wann die Anzeige sichtbar ist

Das Intervall zwischen Anzeigen sollte nicht länger als 100 ms (10 Hz) sein. Bei einer hohen Rate kann der Seeker den Provider schnell finden, auch wenn er im Energiesparmodus scannt.

Werbe-Payload: Fast Pair-Model-ID-Daten

Die Anzeige muss den Datentyp „Nutzungsdaten“ enthalten (siehe oben). § 1.11. Die UUID muss die Schnelles Pairing-Dienst-UUID von 0xFE2C sein. Die Nutzungsdaten müssen Folgendes enthalten:

Oktett Datentyp Beschreibung Wert
0–2 uint24 24-Bit-Modell-ID variiert

LE Audio Sharing Advertising-Payload: Fast Pair-Modell-ID-Daten und FP-Funktionszuordnung

Die Dienstdaten müssen Folgendes enthalten:

Oktett Datentyp Beschreibung Wert
0 uint8 Version und Flags 
0bVVVVFFFF
  • V = Version
  • F = Flags
0x00
1 uint8 Feldlänge und -typ
0bLLLLTTTT
  • L = Länge der Modell‑ID in Byte
  • T = Typ
0bLLLL0111
  • Länge = 0bLLLL = variiert
  • type = 0b0111, Modell-ID
2 – s Modell-ID variiert
s + 1 uint8 Feldlänge und -typ
0bLLLLTTTT
  • L = Länge in Byte
  • T = Typ
0bLLLL1000
s + 2 uint8 FP-Funktionsübersicht variiert
FP-Funktionsübersicht

Die FP-Funktionskarte ist eine Bitmap, die angibt, welche FP-Funktionen der Anbieter unterstützt. Das erste Byte der Bitmap ist so definiert:

Bitmap Beschreibung
0bRRRRRRSO R – Reserviertes Bit, wird vom Seeker vorerst ignoriert und muss auf 0 gesetzt werden.
S – Unterstützung für FP LE Audio Sharing (auf 1 gesetzt, wenn aktiviert, sonst 0).
O – Out-of-Box-Bit (OOB), auf 1 gesetzt, wenn das Gerät fabrikneu ist.

Wenn der Anbieter die FP LE Audio Sharing-Spezifikation unterstützt (d. h. Temporäres Pairing, LE Audio Sharing Advertising Payload und Hearable control version 2), setze das FP LE Audio Sharing-Unterstützungsbit auf 1. Andernfalls setze es auf 0.

Wenn der Anbieter nicht mit einem FP-Sucher gekoppelt wurde und fabrikneu ist (d. h. keine FP-Kontoschlüssel auf dem Anbieter vorhanden sind), setzen Sie das OOB-Bit auf 1. Andernfalls setzen Sie es auf 0.

Werbung: Wenn nicht auffindbar

Wenn das Anbietergerät nicht erkennbar ist (d. h. nicht im Kopplungsmodus), muss es gemäß den folgenden Richtlinien Fast Pair-Kontodaten bewerben.

Durch die Werbung für die Kontodaten können Suchende in der Nähe erkennen, wenn ein Anbieter zu ihrem Konto gehört, und die Kopplung initiieren, ohne den Anbieter zuerst in den Kopplungsmodus versetzen zu müssen. Dies ist ein häufiger Grund für Nutzerbeschwerden. Mit Seekers können Nutzer diese Übertragung ignorieren, wenn sie nicht auf die Kopplung mit dem Anbieter warten oder die Übertragung nicht relevant ist (z. B. wenn sie bereits gekoppelt sind). Außerdem werden offensichtlich schlechte Übertragungen automatisch herausgefiltert, z. B. wenn die Kontodaten falsch konfiguriert sind.

Werbeintervall: Wenn nicht erkennbar

Das Intervall zwischen den Anzeigen sollte höchstens 250 ms (4 Hz) betragen.

Werbe-Payload: Fast Pair-Kontodaten

Die Anzeige muss den Datentyp „Service Data“ (Nutzungsdaten) enthalten, ebd., § 1.11. Die UUID muss die Schnelles Pairing-Dienst-UUID von 0xFE2C sein. Die Nutzungsdaten müssen Folgendes enthalten:

Oktett Datentyp Beschreibung Wert
0 uint8 Version und Flags 
0bVVVVFFFF
  • V = Version
  • F = Flags
0x00
(für zukünftige Verwendung reserviert)
1 – variiert Kontoschlüsseldaten variiert

Die Kontoschlüsseldaten enthalten:

Oktett Datentyp Beschreibung Wert
0 uint8 Feldlänge und -typ
0bLLLLTTTT
  • L = Länge des Kontoschlüsselfilters in Byte
  • T = Typ
0bLLLL0000
  • Länge = 0bLLLL = variiert
  • type = 0b0000 (UI-Hinweis anzeigen) oder 0b0010 (UI-Hinweis ausblenden), Account Key Filter
1 – s Kontoschlüsselfilter variiert
s + 1 uint8 Feldlänge und -typ
0bLLLLTTTT
  • L = Länge in Byte
  • T = Typ
0b00100001
  • length = 0b0010 = 2
  • type = 0b0001, Salt
s + 2 – s + 3 uint16 Salt variiert

Kontoschlüsselfilter

Mit dem beworbenen Kontoschlüsselfilter kann ein Suchender schnell prüfen, ob ein Anbieter einen bestimmten Kontoschlüssel besitzt (mit einer geringen Wahrscheinlichkeit für Falschmeldungen, im Durchschnitt viel weniger als 0,5%), bevor er weitere Interaktionen durchführt. Der Seeker kann automatisch eine Verbindung herstellen und versuchen, den Vorgang zu starten, wenn er einen Filter mit dem Typ 0 empfängt, der eine UI-Anzeige enthält, die möglicherweise einen seiner Kontoschlüssel enthält. Dadurch soll die Rate der Falschmeldungen weiter reduziert werden. In einigen Situationen möchte der Anbieter möglicherweise vom Suchenden erkannt werden, obwohl er noch nicht bereit für die Kopplung ist. Wenn die Kopfhörer beispielsweise wieder in das Case gelegt werden, soll die nachfolgende Benachrichtigung zur Kopplung nicht mehr angezeigt werden, da die Kopplung vom Headset abgelehnt werden könnte.

Der Kontoschlüsselfilter ist ein Bloom-Filter variabler Länge, der so erstellt wird:

  1. Sei n die Anzahl der Kontoschlüssel (n >= 1) in der gespeicherten Liste der Kontoschlüssel.
  2. Sei s die Größe des Filters in Byte, die auf (1, 2*n + 3) gekürzt wird. Wenn beispielsweise ein Schlüssel gespeichert wird, ist s = 4 Byte.
    uint8_t s = (((uint8_t)(( float )1.2 * n)) + 3);
  3. Initialisiere den Filter F als Array mit s Bytes, die jeweils auf 0 gesetzt sind.
    uint8_t F[s] = {0};
  4. Für jeden Kontoschlüssel K in der gespeicherten Liste der Kontoschlüssel:
    a. Sei V = concat(K, Salt).

    // In the sample code, the size of salt is 2 bytes.
    #define SALT_SIZE 2
    
    uint8_t V[FASTPAIR_ACCOUNT_KEY_SIZE + SALT_SIZE];
    for (uint8_t keyIndex = 0; keyIndex < n; keyIndex++)
      {
         // concat (K, Salt)
          fastpair_get_account_key_by_index(keyIndex, V);
    
          uint8_t randomSalt = (uint8_t)rand();
          V[FASTPAIR_ACCOUNT_KEY_SIZE] = randomSalt;
          ... }
    

    b. Berechne den Hash von V mit SHA256. Das Ergebnis ist ein 32-Byte-Wert H = {H0, …, H31}.

    uint8_t H[32] = {0};
    SHA256_hash_function(V, H);
    

    c. Teilen Sie H in acht 4‑Byte-Ganzzahlen ohne Vorzeichen im Big-Endian-Format auf: X = {X0, …, X7}, wobei X0 = 0xH0H1H2H3.

         uint32_t X[8];
         for (index = 0; index < 8; index++)
         {
            X[index] = (((uint32_t)(H[index * 4])) << 24) |
                        (((uint32_t)(H[index * 4 + 1])) << 16) |
                        (((uint32_t)(H[index * 4 + 2])) << 8) |
                        (((uint32_t)(H[index * 4 + 3])) << 0);
         }
    

    d. Für jedes Xi:
    i. Sei M = Xi modulo der Anzahl der Bits im Filter (s * 8).
    ii. Ruft das Byte in F am Index (M / 8), abgerundet, ab.
    iii. Setzen Sie im Byte das Bit am Index (M % 8) auf 1.
    iv. Mit anderen Worten:

        // M = Xi % (s * 8)
        // F[M/8] = F[M/8] | (1 << (M % 8))
        for (index = 0; index < 8; index++)
        {
            uint32_t M    = X[index] % (s * 8);
            F[M / 8] = F[M / 8] | (1 << (M % 8));
        }
    

Fügen Sie den Filter F als Feld „Account Key Filter“ in die Werbedaten ein. Dieser Wert hat keine „Endianness“, da es kein mehr oder weniger signifikantes Byte gibt. Ändern Sie die Byte-Reihenfolge nicht.

Salzfeld

Der Salt ist ein Zufallswert, der beim Erstellen des Bloom-Filters an Kontoschlüssel angehängt wird. Dieser Salt sollte jedes Mal neu generiert werden, wenn die RPA für den Anbieter aktualisiert wird, um das Tracking bei der Adressrotation zu vermeiden.

So generieren Sie den Kontoschlüsselfilter mit dem Salt:

  1. Generieren Sie einen zufälligen 2‑Byte-Wert für S. Dieser Wert hat keine „Endianness“, da es kein mehr oder weniger signifikantes Byte gibt. Ändern Sie die Byte-Reihenfolge nicht.
  2. Verwenden Sie das 2‑Byte-S als Salt.
  3. Fügen Sie in den beworbenen Schnelles Pairing-Kontodaten den generierten Filter in das Feld „Account Key Filter“ und S in das Feld „Salt“ ein.