Czas błądzenia (RTT) przez Wi-Fi jest dostępna w Androidzie 9 i umożliwia urządzeniom pomiar odległości od innych urządzeń pomocniczych: niezależnie od tego, czy są to punkty dostępu; (punkty dostępowe) lub połączenia równorzędne Wi-Fi Aware (w przypadku Wi-Fi Aware) jest obsługiwana na urządzeniu). Funkcja opracowana na podstawie standardów IEEE 802.11mc oraz protokół IEEE 802.11az (dostępny od Androida 15), umożliwia aplikacjom zwiększenie dokładności i świadomości lokalizacji.
Przykłady i źródło
Aby korzystać z tej funkcji, wdróż interfejs HAL dostawcy. Na Androidzie 14 i nowszych interfejs HAL dostawcy jest zdefiniowany przy użyciu AIDL. W Androidzie 13 i starszych wersjach interfejs HAL dostawcy jest zdefiniowany za pomocą HIDL. Android 8.0 HIDL zastąpiła poprzednią strukturę HAL (Sprzętową warstwę abstrakcji) używaną do usprawnia implementacje, określając typy i metody wywołań metod interfejsów i pakietów.
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 później.
Starsza wersja HAL Wi-Fi pozwala sprawdzić, jak ma się ona do Interfejsy AIDL i HIDL: hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h.
Implementacja
Aby wdrożyć RTT Wi-Fi, musisz udostępnić zarówno platformę, jak i oprogramowanie HAL/firmowe pomoc:
Platforma:
- Kod AOSP
- Włącz RTT Wi-Fi: wymaga flagi funkcji
Obsługa protokołu HAL Wi-Fi (IEEE 802.11mc lub IEEE 802.11az) (co oznacza, że obsługa oprogramowania układowego)
Aby wdrożyć tę funkcję, zaimplementuj interfejs Wi-Fi AIDL lub HIDL. i włącz flagę funkcji:
W usłudze
device.mkw lokalizacjidevice/<oem>/<device>zmodyfikuj Zmienna środowiskowaPRODUCT_COPY_FILESz obsługą sieci Wi-Fi Funkcja 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 wszystkie dane wymagane przez tę funkcję są uwzględnione w raporcie AOSP.
randomizacja MAC
Aby zwiększyć prywatność, adres MAC używany podczas transakcji RTT w sieci Wi-Fi musi być nie może być losowy, czyli nie może być zgodny z natywnym adresem MAC sieci Wi-Fi; za pomocą prostego interfejsu online. Wyjątkiem są jednak sytuacje, gdy urządzenie jest powiązane z punktem dostępu, może używać adresu MAC, z którym jest powiązany we wszystkich transakcjach RTT albo z innym punktem dostępowym.
Weryfikacja
Dla tej funkcji dostępne są testy CTS (Android Compatibility Test Suite). Wykryte przez CTS gdy funkcja jest włączona i automatycznie uwzględnia powiązane testy. Tę funkcję możesz też przetestować za pomocą Vendor Test Suite (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
Dla tej funkcji dostępne są testy CTS (Android Compatibility Test Suite). Wykryte przez CTS gdy funkcja jest włączona i automatycznie uwzględnia powiązane testy. An Punkt dostępu obsługujący RTT Wi-Fi (IEEE 802.11mc) musi znajdować się w zasięgu testowane urządzenie.
Testy CTS można aktywować za pomocą:
atest WifiRttTest
Kalibracja
Aby funkcja RTT Wi-Fi działała prawidłowo, zakresy zwrócone w standardach 802.11mc lub 802.11az powinny być zgodne z kluczowymi wskaźnikami wydajności (KPI), opisane w tej sekcji.
W przypadku protokołu 11 mc dla wymienionych przepustowości (80 MHz, 40 MHz) 20 MHz) i rozmiar serii 8, KPI szacowanego zakresu powinien osiągnięcie tej dokładności przy 90. percentylu błędu.
- 80 MHz: 2 metry
- 40 MHz: 4 metry
- 20 MHz: 8 metrów
W przypadku protokołu 11az konfiguracja MIMO anteny i długie trenowanie na dokładność mogą wpływać powtarzanie w polu (LTF). Na typowym telefonie komórkowym (z 2 telefonami) anteny) i punktu dostępu (4 anteny), system ma 2x4 MIMO konfiguracji. W przypadku takiej konfiguracji z zastosowaniem współczynnika powtórzeń LTF wynoszącego 2. i przy wymienionych przepustowościach (160 MHz, 80 MHz, 40 MHz, 20 MHz), wskaźnik KPI dla szacowanego zakresu powinien osiągnąć: do 90. percentyla błędu.
- 160 MHz: 0,5 metra.
- 80 MHz: 1 metr.
- 40 MHz: 2 metry
- 20 MHz: 4 metry
Aby zapewnić prawidłowe działanie funkcji, przeprowadź kalibrację. które są niezbędne.
Można to osiągnąć, porównując zakres danych podstawowych z szacowaną liczbą RTT coraz większa odległość. Aby uzyskać podstawową zgodność, zweryfikuj z urządzeniem, o którym wiadomo, że jest skalibrowany za pomocą protokołu RTT. Kalibracja zakresu powinna zostać przetestowana w następujących warunkach:
- Duże otwarte laboratorium lub korytarz bez metalu. obiektów, które mogą powodować wyjątkowo częste występowanie wielu ścieżek.
- Co najmniej tor lub ścieżka wzrokowa rozciągająca się na 25 m.
- Znaczniki w odstępach co 0,5 metra od jednego końca trasy do drugiego.
mieć punkt dostępu z obsługą RTT na jednym końcu ścieżki. zamontowany 20 cm nad podłogą oraz ruchomy uchwyt do telefonu z Androidem (lub innym testowanym urządzeniu mobilnym z Androidem), które można przesunąć i wyrównane ze znacznikami 0, 5 m, także na wysokości 20 cm na podłodze.
Przy każdym znaczniku powinno zostać zapisanych 50 wyników dotyczących zakresu, i odległość od punktu dostępu. Statystyki, takie jak średnia zakresu i wariancja, należy obliczać dla każdej pozycji znacznika.
Na podstawie wyników w kroku 5 można narysować wykres dla danych podstawowych (oś X) w odniesieniu do szacowanego zakresu (oś Y) i oszacowanej najlepiej dopasowanej linii regresji. Idealna kalibracja urządzenia wyświetli linię gradientu 1,0 z przesunięciem 0,0 m. osi Y. Odchylenia od tych wartości są dopuszczalne, jeśli znajdują się w KPI dla odpowiedniej przepustowości. Jeśli wyniki wykraczają poza KPI, funkcja urządzenia powinna zostać ponownie skalibrowana, aby wyniki były zgodne z KPI. specyfikacji.