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. W Androidzie 13 i starszych wersjach interfejs HAL dostawcy jest definiowany za pomocą HIDL. W Androidzie 8.0 protokół HIDL zastąpił poprzednią strukturę w postaci sprzętowej warstwy abstrakcji (HAL) używaną do usprawnienia implementacji przez określenie typów i wywołań metod zbieranych w interfejsach i pakietach.
Postępuj zgodnie z interfejsem Wi-Fi, aby zastosować funkcję RTT Wi-Fi. W zależności od tego, który interfejs został zaimplementowany, wygląda to tak:
- AIDL:
hardware/interfaces/wifi/aidl - HIDL:
hardware/interfaces/wifi/1.0lub 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ć RTT Wi-Fi, musisz zapewnić obsługę zarówno platformy, jak i oprogramowania HAL/firmowego:
Platforma:
- Kod AOSP
- Włącz RTT Wi-Fi: wymaga flagi funkcji
Obsługa RTT Wi-Fi (IEEE 802.11mc lub IEEE 802.11az) HAL (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 folderzedevice/<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.
randomizacja 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. Ta funkcja może być też testowana za pomocą pakietu testów dostawcy (VTS).
Testy jednostkowe
Testy pakietu Wi-Fi RTT są wykonywane przy użyciu:
Testy usługi:
atest com.android.server.wifi.rtt
Testy menedżera:
atest android.net.wifi.rtt
wskaźnik 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 aktywować 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 na dokładność pomiaru wpływ mają konfiguracja MIMO anteny i powtórzenie w długim polu trenowania (LTF). W przypadku typowego telefonu komórkowego (z 2 antenami) i punktu dostępu (4 anteny) system ma konfigurację MIMO 2 x 4. W przypadku takiej konfiguracji z wykorzystaniem współczynnika powtórzeń LTF 2 i podanymi przepustowościami (160 MHz, 80 MHz, 40 MHz, 20 MHz) wskaźnik KPI szacowania zakresu powinien osiągnąć podaną niżej dokładność w 90. percentylu 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 zakres danych podstawowych z szacowanym zakresem RTT przy rosnących odległościach. Aby zapewnić podstawowe zgodność, należy sprawdzić rozwiązanie na urządzeniu, które jest skalibrowane pod kątem RTT. Kalibrację zakresu należy przetestować w tych warunkach:
- Duże otwarte laboratorium lub korytarz bez wielu metalowych obiektów, który może powodować wyjątkowo częste przypadki wielościeżkowej wielościeżki.
- co najmniej ścieżka widoczności bezpośredniej o długości 25 m.
- Znaczniki w odstępach co 0,5 metra od jednego końca trasy do drugiego.
Miejsce na uchwyt z punktem dostępu obsługującym RTT na jednym końcu toru, zamontowany 20 cm nad podłogą, oraz uchwyt 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 0,5 m nad podłogą.
Przy każdym znaczniku powinno zostać zapisanych 50 wyników wyszukiwania wraz z odległością 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 oszacowaną 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 KPI, należy ponownie skalibrować funkcję urządzenia, aby uzyskać wyniki zgodne ze specyfikacją KPI.