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 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. Na Androidzie 13 i starszych interfejs HAL dostawcy jest zdefiniowany za pomocą HIDL. W Androidzie 8.0 HIDL zastąpił poprzednią strukturę warstwy abstrakcji sprzętu (HAL), która była używana do usprawniania 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:
- AIDL:
hardware/interfaces/wifi/aidl
- HIDL:
hardware/interfaces/wifi/1.0
lub nowsza.
Aby sprawdzić, jak jest to powiązane z interfejsami AIDL i HIDL, możesz zapoznać się z starszą wersją HAL Wi-Fi: 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.mk
wdevice/<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 wbudowanym 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.rtt
Testy menedżera:
atest android.net.wifi.rtt
CTS
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 WifiRttTest
Kalibracja
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 sprawdzić, czy implementacja funkcji działa prawidłowo, konieczne jest przeprowadzenie testu kalibracyjnego.
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ść, zalecamy zweryfikowanie rozwiązania na urządzeniu, które zostało skalibrowane pod kątem RTT. Zalecamy testowanie kalibracji zakresu 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 zabezpieczenie punktu dostępu obsługującego RTT na jednym końcu toru zamontowanego 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ż na wysokości 20 cm nad podłogą.
Zalecamy zarejestrowanie 50 wyników pomiaru odległości przy każdym znaczniku wraz z odległością od punktu dostępu. Statystyki, takie jak średnia zakresu i wariancja, 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, zalecamy ponowną kalibrację funkcji urządzenia, aby wyniki mieściły się w specyfikacji KPI.