Wi-Fi RTT (IEEE 802.11mc, IEEE 802.11az)

Funkcja czasu RTT (Round Trip Time) Wi-Fi w Androidzie 9 umożliwia urządzeniom obsługującym pomiar odległości do innych urządzeń obsługujących: punktów dostępu (AP) lub urządzeń z funkcją Wi-Fi Aware (jeśli urządzenie obsługuje tę funkcję). Ta funkcja oparta na protokole IEEE 802.11mc i IEEE 802.11az (dostępnym od Androida 15) umożliwia aplikacjom korzystanie z ulepszonej dokładności i świadomości lokalizacji.

Przykłady i źródło

Aby korzystać z tej funkcji, zaimplementuj interfejs Vendor HAL. W Androidzie 14 i nowszych interfejs HAL dostawcy jest definiowany za pomocą AIDL. Na Androidzie 13 i starszych interfejs HAL dostawcy jest definiowany za pomocą HIDL. W Androidzie 8.0 interfejs HIDL zastąpił poprzednią strukturę warstwy abstrakcji sprzętowej (HAL), która służyła do uproszczenia implementacji przez określenie typów i wywołań metod zebranych w interfejsach i pakietach.

Aby korzystać z funkcji RTT przez Wi-Fi, postępuj zgodnie z instrukcjami w interfejsie Wi-Fi. W zależności od zaimplementowanego interfejsu:

  • AIDL: hardware/interfaces/wifi/aidl
  • HIDL: hardware/interfaces/wifi/1.0 lub nowsza.

Aby sprawdzić, jak starsza wersja interfejsu HAL dla Wi-Fi koreluje z interfejsami AIDL i HIDL, możesz zapoznać się ze starszą wersją interfejsu HAL dla Wi-Fi: hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h.

Implementacja

Aby wdrożyć Wi-Fi RTT, musisz zapewnić obsługę zarówno w ramach, jak i w HAL/oprogramowaniu sprzętowym:

  • Platforma:

    • Kod AOSP
    • Włączanie RTT Wi-Fi: wymaga flagi funkcji

  • Obsługa HAL dla Wi-Fi RTT (IEEE 802.11mc lub IEEE 802.11az) (co oznacza obsługę oprogramowania układowego)

Aby wdrożyć tę funkcję, zaimplementuj interfejs Wi-Fi AIDL lub HIDL i włącz flagę funkcji:

  • W pliku device.mk, który znajduje się w folderze device/<oem>/<device>, zmień zmienną środowiskową PRODUCT_COPY_FILES, aby uwzględnić obsługę funkcji RTT Wi-Fi:

    PRODUCT_COPY_FILES += frameworks/native/data/etc/android.hardware.wifi.rtt.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.wifi.rtt.xml

W innych przypadkach wszystko, czego potrzeba do obsługi tej funkcji, jest zawarte w AOSP.

losowe generowanie adresów MAC.

Aby zwiększyć prywatność, adres MAC używany podczas transakcji RTT w sieci Wi-Fi musi być losowy, czyli nie może być zgodny z domyślnym adresem MAC interfejsu Wi-Fi. Jednak jako wyjątek, gdy urządzenie jest powiązane z punktem dostępu, może używać adresu MAC, z którym jest powiązane, do wszystkich transakcji RTT z tym punktem dostępu lub innymi punktami dostępu.

Weryfikacja

Ta funkcja jest objęta testami Compatibility Test Suite (CTS) na Androida. CTS wykrywa, kiedy funkcja jest włączona, i automatycznie uwzględnia powiązane testy. Funkcję tę można też przetestować za pomocą pakietu testów dostawcy (VTS).

Testy jednostkowe

Testy pakietu RTT Wi-Fi są wykonywane za pomocą:

Testy usługi:

atest com.android.server.wifi.rtt

Testy menedżera:

atest android.net.wifi.rtt

CTS

Ta funkcja jest objęta testami Compatibility Test Suite (CTS) na Androida. CTS wykrywa, kiedy funkcja jest włączona, i automatycznie uwzględnia powiązane testy. Punkt dostępu obsługujący Wi-Fi RTT (IEEE 802.11mc) musi znajdować się w zasięgu testowanego urządzenia.

Testy CTS można wywołać za pomocą:

atest WifiRttTest

Kalibracja

Aby RTT Wi-Fi działał prawidłowo, zakresy zwracane w protokołach 802.11mc lub 802.11az powinny być dokładne w zakresie kluczowych wskaźników wydajności (KPI) opisanych w tej sekcji.

W przypadku protokołu 11mc przy wymienionych przepustowościach (80 MHz, 40 MHz, 20 MHz) i rozmarze bursta 8 oczekuje się, że KPI dla oszacowania zakresu osiągnie podaną niżej dokładność w 90. procencie błędów.

  • 80 MHz: 2 metry
  • 40 MHz: 4 metry
  • 20 MHz: 8 metrów

W przypadku protokołu 11az dokładność zależy od konfiguracji anteny MIMO i powtarzania długiego pola treningowego (LTF). W przypadku typowego telefonu komórkowego (z 2 antenami) i punktu dostępowego (z 4 antenami) system ma konfigurację 2 x 4 MIMO. W przypadku takiej konfiguracji z wykorzystaniem współczynnika powtórzeń LTF równego 2 i podanymi przepustowościami (160 MHz, 80 MHz, 40 MHz, 20 MHz) wskaźnik KPI dla oszacowania zakresu powinien osiągnąć podaną niżej dokładność w 90. percentilu błędu.

  • 160 MHz: 0,5 metra
  • 80 MHz: 1 metr
  • 40 MHz: 2 metry
  • 20 MHz: 4 metry

Aby mieć pewność, że implementacja funkcji działa prawidłowo, konieczne jest przeprowadzenie testów kalibracji.

Można to osiągnąć, porównując rzeczywisty zasięg z szacowanym zasięgiem RTT na coraz większe odległości. Aby zapewnić podstawowe zgodność, należy sprawdzić rozwiązanie na urządzeniu, które zostało skalibrowane pod kątem RTT. Kalibrację zakresu należy przetestować w tych warunkach:

  1. duże otwarte laboratorium lub korytarz bez dużej ilości metalowych obiektów, które mogą powodować nadmierną ilość ścieżek;
  2. co najmniej ścieżka widoczności wzrokowej (LOS) o długości 25 m.
  3. znaczniki co 0,5 metra od jednego końca toru do drugiego;

  4. Miejsce do zamocowania punktu dostępu z możliwością przesyłania RTT na jednym końcu toru, zamontowanego 20 cm nad podłogą, oraz ruchomego uchwytu na telefon z Androidem (lub inne testowane urządzenie mobilne z Androidem), który można przesuwać wzdłuż toru i ustawić na wysokości markerów 0,5 m, również 20 cm nad podłogą.

  5. W przypadku każdego znacznika należy zarejestrować 50 wyników pomiaru odległości oraz odległość od punktu dostępu. Statystyki, takie jak średnia i odchylenie standardowe zakresu, powinny być obliczane dla każdej pozycji znacznika.

Na podstawie wyników z kroku 5 można narysować wykres z wartością rzeczywistą (oś X) w porównaniu ze szacowanym zakresem (oś Y) oraz z szacowaną linią regresji. Idealna kalibracja urządzenia spowoduje powstanie linii o gradientzie 1,0 i odstępie 0,0 m na osi y. Odchylenia od tych wartości są dopuszczalne, jeśli mieszczą się w ramach KPI dla odpowiedniej przepustowości. Jeśli wyniki wykraczają poza zakres KPI, należy ponownie skalibrować funkcję urządzenia, aby wyniki mieściły się w ramach specyfikacji KPI.