Funkcja Wi-Fi Round Trip Time (RTT) w Androidzie 9 umożliwia obsługiwanym urządzeniom pomiar odległości od innych obsługiwanych urządzeń: punktów dostępu (AP) lub urządzeń Wi-Fi Aware (jeśli urządzenie obsługuje Wi-Fi Aware). Ta funkcja oparta na protokołach IEEE 802.11mc i IEEE 802.11az (dostępna od Androida 15) umożliwia aplikacjom korzystanie z większej dokładności i świadomości lokalizacji.
Przykłady i źródło
Aby korzystać z tej funkcji, zaimplementuj interfejs HAL dostawcy. W Androidzie 14 i nowszych interfejs HAL dostawcy jest zdefiniowany za pomocą AIDL. W Androidzie 13 i starszych wersjach interfejs HAL dostawcy jest zdefiniowany za pomocą HIDL. W Androidzie 8.0 HIDL zastąpił poprzednią strukturę warstwy abstrakcji sprzętu (HAL), która służyła do upraszczania implementacji przez określanie typów i wywołań metod zebranych w interfejsach i pakietach.
Postępuj zgodnie z instrukcjami w interfejsie Wi-Fi, aby korzystać z funkcji Wi-Fi RTT. W zależności od zaimplementowanego interfejsu jest to:
- AIDL:
hardware/interfaces/wifi/aidl - HIDL:
hardware/interfaces/wifi/1.0lub nowsza.
Aby sprawdzić, jak starsza wersja HAL Wi-Fi jest powiązana z interfejsami AIDL i HIDL, zapoznaj się z tym plikiem:hardware/libhardware_legacy/+/android16-release/include/hardware_legacy/rtt.h.
Implementacja
Aby wdrożyć Wi-Fi RTT, musisz zapewnić obsługę zarówno platformy, jak i HAL/oprogramowania sprzętowego:
Platforma:
- Kod AOSP
- Włączanie Wi-Fi RTT: wymaga flagi funkcji
Obsługa HAL Wi-Fi RTT (IEEE 802.11mc lub IEEE 802.11az) (co oznacza obsługę oprogramowania sprzętowego)
Aby wdrożyć tę funkcję, zaimplementuj interfejs Wi-Fi AIDL lub HIDL i włącz flagę funkcji:
W sekcji
device.mkwdevice/<oem>/<device>zmień zmienną środowiskowąPRODUCT_COPY_FILES, aby uwzględnić obsługę funkcji Wi-Fi RTT:PRODUCT_COPY_FILES += frameworks/native/data/etc/android.hardware.wifi.rtt.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.wifi.rtt.xml
W przeciwnym razie wszystko, co jest potrzebne do korzystania z tej funkcji, jest zawarte w AOSP.
Randomizacja adresu MAC
Aby zwiększyć prywatność, adres MAC używany podczas transakcji Wi-Fi RTT musi być losowy, tzn. nie może być zgodny z natywnym adresem MAC interfejsu Wi-Fi. Jednak w wyjątkowych przypadkach, gdy urządzenie jest powiązane z punktem dostępu, może używać adresu MAC, z którym jest powiązane, w przypadku wszystkich transakcji RTT z tym punktem dostępu lub z innymi punktami dostępu.
Weryfikacja
Dla tej funkcji istnieją testy pakietu CTS (Compatibility Test Suite) na Androida. CTS wykrywa, kiedy funkcja jest włączona, i automatycznie uwzględnia powiązane z nią testy. Tę funkcję można też przetestować za pomocą pakietu testów dostawcy (VTS).
Testy jednostkowe
Testy pakietów Wi-Fi RTT są wykonywane za pomocą:
Testy usług:
atest com.android.server.wifi.rttTesty menedżera:
atest android.net.wifi.rttCTS
Dla tej funkcji istnieją testy pakietu CTS (Compatibility Test Suite) na Androida. CTS wykrywa, kiedy funkcja jest włączona, i automatycznie uwzględnia powiązane z nią 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 uruchamiać za pomocą tych metod:
atest WifiRttTestKalibracja
Aby Wi-Fi RTT działało prawidłowo, zakresy zwracane w protokołach 802.11mc lub 802.11az powinny być dokładne w ramach kluczowych wskaźników wydajności (KPI) opisanych w tej sekcji.
W przypadku protokołu 11mc przy podanych szerokościach pasma (80 MHz, 40 MHz, 20 MHz) i rozmiarze pakietu 8 oczekuje się, że wskaźnik KPI dla szacowania zasięgu osiągnie następującą dokładność na 90 percentylu błędu.
- 80 MHz: 2 metry
- 40 MHz: 4 metry
- 20 MHz: 8 metrów
W przypadku protokołu 11az na dokładność wpływają konfiguracja MIMO anteny i powtórzenie długiego pola szkoleniowego (LTF). W przypadku typowego telefonu komórkowego (z 2 antenami) i punktu dostępu (z 4 antenami) system ma konfigurację MIMO 2x4. W przypadku takiej konfiguracji z czynnikiem powtórzeń LTF równym 2 i przy podanych szerokościach pasma (160 MHz, 80 MHz, 40 MHz, 20 MHz) wskaźnik KPI dla szacowania zasięgu powinien osiągnąć podaną poniżej dokładność przy 90 percentylu błędu.
- 160 MHz: 0,5 m
- 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 testu kalibracji.
Można to osiągnąć, porównując rzeczywisty zakres z zakresem szacowanym na podstawie czasu RTT przy rosnących odległościach. Aby sprawdzić podstawową zgodność, przetestuj rozwiązanie na urządzeniu, które zostało skalibrowane pod kątem RTT. Kalibrację zakresu należy przetestować w tych warunkach:
- Duże otwarte laboratorium lub korytarz, w którym nie ma wielu metalowych obiektów, które mogą powodować nietypowo częste występowanie wielodrożności.
- co najmniej ścieżkę lub trasę w linii prostej o długości 25 m;
- Znaczniki co 0,5 metra od jednego końca toru do drugiego.
Miejsce na zamocowanie punktu dostępu obsługującego RTT na jednym końcu toru, 20 cm nad podłogą, oraz ruchome mocowanie telefonu z Androidem (lub innego testowanego urządzenia mobilnego z Androidem), które można przesuwać wzdłuż toru i ustawiać w linii z oznaczeniami co 0,5 m, również 20 cm nad podłogą.
Przy każdym znaczniku należy zarejestrować 50 wyników pomiarów odległości wraz z odległością od punktu dostępu. Statystyki, takie jak średnia i wariancja zakresu, powinny być obliczane dla każdej pozycji znacznika.
Na podstawie wyników z kroku 5 można narysować wykres, na którym na osi X będą znajdować się dane podstawowe, a na osi Y – szacowany zakres. Można też wyznaczyć linię regresji najlepiej dopasowaną do tych danych. Idealna kalibracja urządzenia da linię o nachyleniu 1,0 i przesunięciu 0,0 m na osi Y. Odchylenia od tych wartości są dopuszczalne, jeśli mieszczą się w zakresie wskaźnika KPI dla odpowiedniej przepustowości. Jeśli wyniki są poza zakresem KPI, należy ponownie skalibrować funkcję urządzenia, aby wyniki mieściły się w specyfikacji KPI.