Urządzenie Bluetooth Low Energy (BLE)
Implementacja usługi Szybkie parowanie Google (GFPS) w przypadku urządzeń z BLE jest zgodne ze standardem Bluetooth Core Specification w wersji 4.2 lub nowszej.
Ten aneks do specyfikacji Szybkie parowanie umożliwi obsługę w przypadku urządzeń Low Energy (LE) i LEA (Low Energy Audio) w GFPS.
Poziomy zgodności
Poniżej przedstawiamy wyjaśnienia dotyczące słów kluczowych „musi”, „musi”, „będzie”, „powinien”, „może” i „może” wymienionych w specyfikacji:
| Termin | Opis |
|---|---|
| powinien | jest wymagany – służy do definiowania wymagań. |
| musi | jest używany do wyrażenia: jest naturalną konsekwencją wcześniej sprecyzowanego obowiązkowego wymogu LUB niepodważalnego stwierdzenia faktów (takiego, które zawsze jest prawdziwe niezależnie od okoliczności). |
| będzie | To prawda, że – używane tylko w stwierdzeniach faktów. |
| powinien | jest zalecany – służy do wskazania, że spośród kilku możliwości jedna z nich jest rekomendowana jako szczególnie odpowiednia, ale niewymagana. |
| maj | jest dozwolone – służy do zezwalania na opcje. |
| puszka | jest w stanie – używane w odniesieniu do stwierdzenia w sposób przyczynowy. |
Cecha parowania opartego na kluczu
Wiadomość od szukającego do dostawcy
Żądanie nieprzetworzone type 0x00 charakterystyki parowania opartego na kluczach używa bitu 4
aby wskazać, czy Seeker obsługuje specyfikację urządzenia BLE i używa
Bit 5 wskazujący, czy Seeker obsługuje LE Audio.
| Oktet | Typ danych | Opis | Wartość | Obowiązkowe? |
|---|---|---|---|---|
| 0 | uint8 |
Typ wiadomości | 0x00 = prośba o sparowanie na podstawie klucza |
Obowiązkowe |
| 1 | uint8 |
Flagi
|
różni się | Obowiązkowe |
| 2–7 | uint48 |
Wykonaj 1 z tych czynności:
|
różni się | Obowiązkowe |
| 8–13 | uint48 |
Adres BR/EDR szukającego | różni się | Widoczne tylko wtedy, gdy ustawiony jest bit 1 lub 3 flagi |
| n – 15 | Wartość losowa (sól) | różni się | Obowiązkowe |
Wiadomość od dostawcy do szukającego
Po ustawieniu bitu 4 żądania nowa wiadomość odpowiedzi type 0x02 dla
Charakterystyka parowania opartego na kluczach może posłużyć do uzyskania dodatkowego wiązania
w narzędziu Seeker.
| Oktet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0 | uint8 |
Typ wiadomości | 0x02 = rozszerzona odpowiedź na parowanie oparte na kluczu |
| 1 | uint8 |
Flagi
|
różni się |
| 2 | uint8 |
Liczba adresów Dostawcy (w obecnej wersji numer to 1 lub 2, ponieważ musimy zmienić tryb szyfrowania blokowego na AES-CTR, jeśli liczba >= 3) |
różni się |
| 3–8 lub 3–14 |
|
różni się | |
| 9–15 lub 15 | Wartość losowa (sól) | różni się |
Dostawca, który obsługuje specyfikację urządzenia BLE, powinien odczytać bit 4 i bit 5. aby poznać możliwości Poszukiwacza,
- Gdy bit 4 ma wartość 0, Dostawca zignoruje bit 5 i zareaguje z użyciem formatu
type 0x01. - Gdy bit 4 ma wartość 1,
- W przypadku dostawcy obsługującego tylko LE powinien on odpowiedzieć kodem
type 0x02, aby wskazać LE preferencja wiązania. - W przypadku dostawcy w trybie podwójnym może odpowiedzieć, używając
type 0x02, aby wskazać: preferowanie wiązania BR/EDR lub LE.
- W przypadku dostawcy obsługującego tylko LE powinien on odpowiedzieć kodem
- W przypadku zgłoszeń dostawców LEA (LEA) dotyczących trybu dual mode: Przykład: parowanie z dostawcą LEA dual mode Provider
Charakterystyka strumienia wiadomości PSM (usługa protokołu protokołu Multiplexor)
Aby obsługiwać strumień wiadomości na urządzeniach BLE, Szybkie parowanie ustanawia utrzymywać kanał BLE L2CAP do wysyłania i odbierania wiadomości. Szybkie parowanie Serwer L2CAP powinien wdrożyć kontrolę przepływu opartą na kredytach LE.
Ta cecha pozwala Poszukiwaczowi odczytać wartość PSM, a następnie określić bezpiecznego połączenia L2CAP za pomocą wartości PSM.
| Charakterystyka usługi Szybkie parowanie | Zaszyfrowane | Uprawnienia | UUID |
|---|---|---|---|
| PSM strumienia wiadomości | Tak | Odczyt | FE2C1239-8366-4814-8EB0-01DE32100BEA |
| Oktet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0 | uint8 |
Stan
|
różni się |
| 1–2 | uint16 |
Wartość PSM powinna mieścić się w zakresie od 0x80 do 0xFF | różni się |
Uwaga: w przypadku TWS dostępne są 2 rodzaje informacji.
składowe: główny i dodatkowy. Rola tych komponentów jest
wymienne w pewnych warunkach. Przy założeniu, że A jest składnikiem głównym, a B
komponent wtórny z powodu wyczerpywania się baterii komponentu A, komponent B musi
aby odgrywał rolę głównego komponentu. Ten scenariusz nazywa się role switch.
Po role switch, jeśli dostawca
nie może obsłużyć strumienia komunikatu Szybkie parowanie, spowoduje to proaktywne odłączenie
istniejącego połączenia L2CAP. Poszukiwacze Szybkiego parowania mogą wtedy ponownie utworzyć L2CAP
za pomocą nowego komponentu głównego.
Dodatkowa cecha klucza dostępu
Cecha ta ma zapewnić ochronę w ramach zarządzania zasobami reklamowymi w czasie
Ochrona MITM dla fałszywego członka grupy CSIS
Szybkie parowanie wymaga ochrony MITM w ramach procedury parowania. Jako CSIS nie zapewnia ochrony MITM. Obecny projekt FP dla wielu komponentów należy rozszerzyć, aby zapewnić ochronę MITM w przypadku
Definicja cechy
| Cecha usługi Szybkie parowanie | Zaszyfrowane | Uprawnienie | UUID |
|---|---|---|---|
| Dodatkowy klucz dostępu | Tak | Odczyt,pisanie,powiadamianie | FE2C123A-8366-4814-8EB0-01DE32100BEA |
Wiadomości
Format wiadomości ma zastosowanie do operacji odczytu, zapisu i powiadamiania.
Format zaszyfrowanych danych
Zaszyfrowane dane są wysyłane przy użyciu połączenia Szybkie parowanie GATT.
| Oktet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0-15 | uint128 | Dodatkowy zaszyfrowany blok klucza dostępu | różni się |
Format nieprzetworzonych danych
Po odszyfrowaniu zaszyfrowanych danych przy użyciu udostępnionego obiektu tajnego format ma on następujący format:
| Oktet | Typ danych | Opis | Wartość |
|---|---|---|---|
| 0 | uint8 | Typ wiadomości | jedno z
|
| 1-3 | uint24 | 6-cyfrowy klucz dostępu | różni się |
| 4-9 | uint48 | Adres komponentu powiązania docelowego | różni się |
| 10 | uint8 | Kod stanu, używany tylko w ramach operacji odczytu | Jedna z opcji
|
| 11-15 | Wartość losowa (sól) | różni się |
Podstawowy (pierwszy powiązany komponent) to most między Szybkim parowaniem. Poszukiwanie i dodatkowe składniki wiążące. Cecha musi być postępuj zgodnie z wytycznymi:
- Po otrzymaniu żądania zapisu od Szybkiego parowania Dostawca powinien
- Ustaw adres powiązanego komponentu
- Wyślij klucz dostępu do powiązanego komponentu
- Ustaw kod stanu na Oczekujący, 0x01
- podczas odbierania żądań odczytu przed otrzymaniem klucza dostępu z komponentu;
jeśli są powiązane, Dostawca zwróci wiadomość z
- Klucz dostępu, dowolna wartość
- Adres powiązanego komponentu
- Kod stanu oczekiwania, 0x01
- Zanim dostawca wyśle powiadomienie do Szybkiego parowania, ustawia wynik
dla żądania odczytu za pomocą funkcji
- Klucz dostępu z wiązanego komponentu
- Adres powiązanego komponentu
- Kod stanu powodzenia 0x00
- Jeśli po stronie dostawcy wystąpił nieodwracalny błąd, ustaw wynik
- Klucz dostępu, dowolna wartość
- Adres powiązanego komponentu
- Kod stanu błędu 0x02
Zobacz schemat MITM 1 oraz Aby uzyskać więcej informacji, schemat MITM 2.
Wymagania dotyczące urządzeń LE
Reklama LE
W przypadku trybu wykrywalnego lub niewykrywalnego Dostawca powinien używać RPA do reklamować dane Szybkiego parowania.
Możliwość wiązania
W przypadku urządzeń obsługujących LE, Seeker musi utworzyć wiązanie z istniejącym Połączenie z LE. Po przejściu weryfikacji parowania za pomocą klucza Szybkie parowanie Dostawca zezwoli na powiązanie z RPA i wybierze opcję DisplayYesNo w celu weryfikacji klucza dostępu do Szybkiego parowania.
Wymagania dotyczące urządzeń LEA
Reklama LEA
W przypadku urządzeń w trybie podwójnym: W trybie wykrywalności Dostawca powinien reklamować dane Szybkiego parowania z tożsamością adresu. W przypadku trybu niewykrywalnego Dostawca reklamuje dane Szybkiego parowania za pomocą RPA. Zdecydowanie zalecamy korzystanie ze starszych wersji reklam (BT 4.2), urządzeń, by zapewnić zgodność wsteczną. Po każdym przywróceniu urządzenia do ustawień fabrycznych musisz zmienić IRK.
W przypadku urządzeń bez trybu podwójnego: W przypadku trybu wykrywalnego lub niewykrywalnego Dostawca używa rozszerzeń (BT 5.0) za pomocą RPA w celu reklamowania danych Szybkiego parowania.
Reklama LE dostępna w sieci, która zawiera dane usługi FP, będzie zawierać: CAS UUID zgodnie z profil adaptera Bluetooth (BAP 1.0.1) oraz Wspólny profil audio . Dotyczy reklam niewidocznych, gdy brakuje miejsca w starszych reklamach ze względu na uwzględnienie danych dotyczących baterii i SASS, w takim przypadku należy podać identyfikator CAS UUID w odpowiedzi na skanowanie.
Możliwość wiązania LEA
Seeker musi utworzyć powiązanie z istniejącym połączeniem LE. Po zaliczeniu weryfikacji parowania za pomocą klucza szybkiego parowania, dostawca trybu podwójnego umożliwia utworzenie powiązania z adresem tożsamości i RPA, podczas gdy Dostawca nie będzie tworzenie powiązania z RPA i ustawienie możliwości IO na DisplayYesNo na potrzeby Szybkiego parowania. Weryfikacja klucza dostępu.
Kanał komunikacji wewnętrznej między komponentami
Istniejące połączenie GATT jest przechowywane, aby zapewnić ochronę MITM w z dodatkowymi komponentami. Główny powiązany komponent będzie obsługiwać wiadomość między Szybkim parowaniem i jego pozostałymi komponentami.
Initial Pair i Subsequent Pair korzystają z komunikacji wewnętrznej
- Gdy procedura parowania opartego na kluczach zostanie przekazana na komponent główny, podstawowy powinien wysłać wiadomość, aby zmienić możliwości zamówienia reklamowego komponenty
- Po zakończeniu Szybkiego parowania główny komponent wyśle wiadomość z prośbą o zresetowanie urządzenia. Możliwości pozostałego komponentu we/wy
- Podczas wykonywania procedury Dodatkowego klucza dostępu główny komponent obsługuje dostarczania kluczy między funkcją Fast Pair Seeker i jej pozostałymi komponentami
Czas zmienić możliwości wejścia-wyjścia
- Zmień możliwość zamówienia reklamowego na DisplayYesNo po zaliczeniu procedury parowania opartego na kluczu
- Jeśli urządzenie składa się z kilku komponentów, wszystkie z nich powinny być ustawione na DisplayYesNo
- Jedyny wyjątek, którego Dostawca powinien
nie zmieniaj możliwości wejścia-wyjścia na DisplayYesNo,
Retroactive Pair, której Bit 3 żądania parowania opartego na kluczu ma wartość 1, patrz Wiadomość od użytkownika szukającego do dostawcy
- Zmień ustawienie możliwości wejścia-wyjścia na domyślne
- Wstępne parowanie
- Jeśli połączenie z LE jest odłączone, zakończ sesję Szybkie parowanie
- Po utworzeniu powiązania podstawowego, jeśli nie ma dodatkowego zapisu klucza dostępu żądanie w 15 sekund, zakończ sesję Szybkie parowanie
- Po otrzymaniu dodatkowego żądania zapisu klucza dostępu, jeśli komponent tworzenie wiązania nie następuje w ciągu 15 sekund, zakończ sesję Szybkiego parowania
- Po powiązaniu wszystkich komponentów, jeśli nie ma zapisu klucza konta żądania w ciągu 15 sekund, zakończ sesję Szybkiego parowania
- Po otrzymaniu żądania zapisu klucza konta ustaw limit czasu oczekiwania na 15 sekund na Zakończ sesję Szybkiego parowania
- Kolejne parowanie
- Jeśli połączenie z LE jest odłączone, zakończ sesję Szybkie parowanie
- Po utworzeniu powiązania podstawowego, jeśli nie ma dodatkowego zapisu klucza dostępu żądania w ciągu 15 sekund, zakończ sesję Szybkiego parowania
- Po otrzymaniu dodatkowego żądania zapisu klucza dostępu, jeśli komponent tworzenie wiązania nie następuje w ciągu 15 sekund, zakończ sesję Szybkiego parowania
- Gdy wszystkie komponenty będą powiązane, zakończ sesję Szybkie parowanie
- Wstępne parowanie
Ukryj wskaźniki interfejsu
Gdy zestaw słuchawkowy nie jest gotowy do sparowania, Dostawca powinien używać type 0b0010
aby ustawić wskazanie w interfejsie użytkownika na potrzeby danych kluczy konta, aby instruować, że ma się nie wyświetlać
interfejsu parowania (patrz Ładunek reklamowy: dane konta Szybkie parowanie).
Wymagania LE Audio
Wymagania Bluetooth
Zobacz rekomendacje dotyczące gogli Android, LE Audio.
Zespół pomocy CTKD
W przypadku urządzenia w trybie podwójnym: CTKD z LE na BR/EDR jest obowiązkowe i zgodne z BAP.
Ogłoszenie dotyczące celu
Urządzenie peryferyjne powinno używać ukierunkowanego powiadomienia do pozyskiwania połączenia ze sparowanego urządzenia centralnego. Kierowane ogłoszenia są zdefiniowane w BAP i CAP do zarządzania połączeniami zgodnie z tabelą 8.4 CAP 1.0 (p48/58).
Obsługa serwera GATT EATT
EATT umożliwia urządzeniu centralnemu równoczesne wysyłanie wielu transakcji GATT gdy urządzenie jest powiązane. W przypadku urządzeń obsługujących CSIP wartość ta wzrośnie wydajność połączenia z profilem, a wkrótce rozpocznie się tworzenie powiązań za pomocą CSIP; dla pozostałych słuchawek.
Solidne buforowanie GATT (zdecydowanie zalecane)
Jeśli Dostawca nie jest pojedynczym urządzeniem, lecz zestawem skoordynowanym z implementacją CSIP, w celu zmniejszenia liczby wykrywa usługi i przyspiesza połączenie, Dostawca powinien wdrożysz buforowanie GATT zdefiniowane w Bluetooth 5.1.
Wymagania dotyczące Szybkiego parowania
Reklama LE
Na potrzeby trybu wykrywalnego lub niewykrywalnego, jeśli urządzenie ma wiele komponentów, dane Szybkiego parowania powinny być rozgłaszane przez komponent główny. Jeśli urządzenie nie jest gotowe do kolejnego parowania, komponent dodatkowy może reklamować dane Szybkiego parowania w przypadku rozszerzonych funkcji. zobacz Ukryj wskaźniki interfejsu.
Widoczność usługi GATT
Baza danych GATT powinna być taka sama dla wszystkich połączeń GATT transportu LE. LE Audio (0x184E) powinna być uwzględniona w bazie danych GATT połączenia Szybkie parowanie.
Przykład: parowanie z dostawcą trybu podwójnego LEA
Scenariusz 1 – gdy Seeker nie obsługuje LEA
Dostawca musi mieć zgodność wsteczną z Poszukiwaczem, który nie wesprzeć LEA.
Komponenty
- Dostawca: A2DP/HFP/LEA
- Szukający: A2DP/HFP
Oczekiwane działanie w pierwszej / kolejnej parze
- Dostawca reklamuje usługę Szybkie parowanie
(0xFE2C) z adresem tożsamości (początkowym) lub RPA (następnym).
- Użyj starszej wersji reklam
- Poszukiwacz otrzymuje reklama z adresem tożsamości na potrzeby wstępnego parowania lub RPA do późniejszego sparowania.
- Poszukiwacz wysyła żądanie parowania opartego na kluczu
- Bit-5 żądania parowania opartego na kluczu jest ustawione na 0
- Dostawca wysyła odpowiedź dotyczącą parowania opartego na kluczu z adresem publicznym w jednym z
następujące:
- Jeśli używany jest komunikat typu 0x01, należy podać adres publiczny.
- Jeśli używany jest typ wiadomości 0x02
- Bit-0 musi mieć wartość 0.
- Bit-1 będzie mieć wartość 0
- Adres powinien być adresem publicznym.
- The Seeker tworzy wiązanie z transportem BR/EDR
- Możliwość zamówienia reklamowego jest ustawiona na DisplayYesNo dla BR/EDR
- Procedura weryfikacji klucza dostępu w ramach Szybkiego parowania:
Scenariusz 2 – gdy Seeker obsługuje LEA
Komponenty
- Dostawca
- Obsługa A2DP/HFP/LEA
- Jeden składnik
- Poszukiwacz
- SupportA2DP/HFP/LEA,
Oczekiwane działanie w pierwszej / kolejnej parze
- Dostawca reklamuje usługę Szybkie parowanie
(0xFE2C) z adresem tożsamości (początkowym) lub RPA (następnym).
- Użyj starszej wersji reklam
- Poszukiwacz wysyła żądanie parowania opartego na kluczu
- Bit-5 żądania parowania opartego na kluczu jest ustawione na 1
- Dostawca wysyła odpowiedź dotyczącą parowania za pomocą klucza z komunikatem typu 0x02
- Bit-0 musi mieć wartość 0.
- Bit-1 musi mieć wartość 1.
- Adres to Adres tożsamości
- Poszukiwacz tworzy więź z istniejącym
Połączenie LE w transporcie LE
- Kierunek CTKD jest ustawiony z LE na BR/EDR
- Możliwość wejścia-wyjścia jest ustawiona na DisplayYesNo dla LE
- Procedura weryfikacji klucza dostępu w ramach Szybkiego parowania:
Scenariusz 3 – gdy Seeker obsługuje LEA i CSIP
Komponenty
- Dostawca
- Obsługa A2DP/HFP/LEA
- Wiele komponentów
- Główny komponent to BR/EDR/LE.
- Komponent dodatkowy jest tylko LE
- Poszukiwacz
- Obsługa A2DP/HFP/LEA
Oczekiwane działanie w pierwszej / kolejnej parze
- Główny komponent reklamuje Szybkie parowanie.
dane usługi (0xFE2C) z adresem tożsamości (początkowym) lub RPA (następnym).
- Użyj starszej wersji reklam
- Poszukiwacz wysyła żądanie parowania opartego na kluczu do komponentu głównego.
- Bit-5 żądania parowania opartego na kluczu jest ustawione na 1
- Główny komponent wysyła odpowiedź w ramach parowania na podstawie klucza z komunikatem 0x02.
- Bit-0 musi mieć wartość 0.
- Bit-1 musi mieć wartość 1.
- Adres jest następujący :
- Pierwszy adres to adres tożsamości głównego komponentu
- Drugi adres to adres elementu dodatkowego, który można powiązać drugi komponent także używa tego adresu do wyświetlania reklam CSIP.
- Poszukiwacz tworzy wiązanie z pierwiastkiem
w istniejącym połączeniu LE.
- Kierunek CTKD jest ustawiony z LE na BR/EDR
- Możliwość wejścia-wyjścia jest ustawiona na DisplayYesNo dla LE
- Poszukiwacz tworzy wiązanie z wtórnymi
komponent, którego adres pochodzi z rozszerzonej odpowiedzi na potrzeby parowania opartego na kluczach
- Możliwość zamówienia reklamowego powinna mieć wartość DisplayYesNo. W przeciwnym razie odrzuć prośbę o sparowanie.
- procedurę ochrony MITM w odniesieniu do powiązania jako dodatkowy, Dostawca powinien wdrożyć w obu sytuacjach
- Poszukiwacz czeka, aż utworzy powiązanie z komponentem dodatkowym
Schemat sekwencyjny dla MITM
Ta sesja ma na celu opisanie sekwencji procedury ochrony MITM.
Uzyskaj klucz dostępu z komponentu powiązanego za pomocą powiadomienia
Uzyskaj klucz dostępu z komponentu powiązanego przez odczyt
Znany problem
Aplikacja FP dla LEA została zoptymalizowana pod kątem współpracy z Androidem V(Android 15).
W przeciwnym razie napotkaliśmy wiele problemów ze słuchawkami obsługującymi LEA. ale nie ma odpowiedniej implementacji Szybkiego parowania na LEA (tj. tylko Szybkie parowanie Klasyczna). Konkretnie i na przykład wtedy, gdy RPA dostawcy nie jest generowana za pomocą prawidłowego klucza do rozpoznawania tożsamości (IRK) i adresu nie można rozpoznać. Chociaż nie udało nam się przetestować szczegółowej listy zestawów słuchawkowych nasze ograniczone testy wykazały różne problemy, w tym aby wyświetlać powiadomienia o baterii dousznej, brak przełączania dźwięku (SASS) funkcjonalności, powszechne błędy początkowe i kolejnych błędów parowania itp.
Dlatego zdecydowanie zalecamy partnerom wdrożenie Szybkiego parowania. specyfikacja zarówno nowych, jak i istniejących urządzeń (za pomocą aktualizacji bezprzewodowych), które obsługują tryby podwójny.