Wi-Fi RTT (IEEE 802.11mc)

Die Wi-Fi Round Trip Time (RTT) -Funktion in Android 9 ermöglicht es unterstützenden Geräten, eine Entfernung zu anderen unterstützenden Geräten zu messen: unabhängig davon, ob es sich um Access Points (APs) oder Wi-Fi Aware-Peers handelt (sofern Wi-Fi Aware auf dem unterstützt wird). Gerät). Diese auf dem IEEE 802.11mc-Protokoll basierende Funktion ermöglicht es Apps, eine verbesserte Standortgenauigkeit und -erkennung zu nutzen.

Beispiele und Quelle

Um diese Funktion zu nutzen, implementieren Sie die Vendor HAL-Schnittstelle. In Android 14 und höher wird die Vendor HAL-Schnittstelle mithilfe von AIDL definiert. In Android 13 und niedriger wird die Vendor HAL-Schnittstelle mit HIDL definiert. In Android 8.0 ersetzte HIDL die bisherige HAL-Struktur (Hardware Abstraction Layer), die zur Optimierung von Implementierungen durch die Angabe von Typen und Methodenaufrufen verwendet wurde, die in Schnittstellen und Paketen gesammelt wurden.

Folgen Sie der Wi-Fi-Schnittstelle, um die Wi-Fi-RTT-Funktion zu nutzen. Je nachdem, welche Schnittstelle implementiert ist, ist dies:

  • AIDL: hardware/interfaces/wifi/aidl
  • HIDL: hardware/interfaces/wifi/1.0 oder höher.

Sie können auf die ältere Wi-Fi-HAL zurückgreifen, um zu sehen, wie sie mit den AIDL- und HIDL-Schnittstellen korreliert: hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h .

Implementierung

Um Wi-Fi RTT zu implementieren, müssen Sie sowohl Framework- als auch HAL-/Firmware-Unterstützung bereitstellen:

  • Rahmen:

    • AOSP-Code
    • Wi-Fi RTT aktivieren: erfordert ein Feature-Flag
  • Wi-Fi RTT (IEEE 802.11mc) HAL-Unterstützung (was Firmware-Unterstützung impliziert)

Um diese Funktion zu implementieren, implementieren Sie die Wi-Fi AIDL- oder HIDL-Schnittstelle und aktivieren Sie das Feature-Flag:

  • Ändern Sie in device.mk unter device/<oem>/<device> die Umgebungsvariable PRODUCT_COPY_FILES , um Unterstützung für die Wi-Fi RTT-Funktion einzubeziehen:

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

Ansonsten ist alles, was für diese Funktion erforderlich ist, in AOSP enthalten.

MAC-Randomisierung

Um den Datenschutz zu verbessern, muss die bei Wi-Fi-RTT-Transaktionen verwendete MAC-Adresse zufällig sein, dh sie darf nicht mit der nativen MAC-Adresse der Wi-Fi-Schnittstelle übereinstimmen. Wenn ein Gerät jedoch mit einem AP verknüpft ist, kann es ausnahmsweise die MAC-Adresse, mit der es verknüpft ist, für alle RTT-Transaktionen mit diesem AP oder mit anderen APs verwenden.

Validierung

Für diese Funktion gibt es Tests der Android Compatibility Test Suite (CTS). CTS erkennt, wenn die Funktion aktiviert ist, und schließt automatisch die zugehörigen Tests ein. Diese Funktion kann auch mit der Vendor Test Suite (VTS) und Acts/sl4a getestet werden, einer Testsuite, die umfangreiche Integrationstests durchführt.

Unit-Tests

Die Wi-Fi-RTT-Pakettests werden ausgeführt mit:

Servicetests:

atest com.android.server.wifi.rtt

Managertests:

atest android.net.wifi.rtt

Integrationstests (ACTS).

Die unter /tools/test/connectivity/acts_tests/tests/google/wifi/rtt/README.md beschriebene Testsuite „acts/sl4a“ bietet Funktions-, Leistungs- und Stresstests.

CTS

Für diese Funktion gibt es Tests der Android Compatibility Test Suite (CTS). CTS erkennt, wenn die Funktion aktiviert ist, und schließt automatisch die zugehörigen Tests ein. Ein Access Point, der Wi-Fi RTT (IEEE 802.11mc) unterstützt, muss sich in Reichweite des zu testenden Geräts befinden.

Die CTS-Tests können ausgelöst werden mit:

atest WifiRttTest

Kalibrierung

Damit Wi-Fi RTT eine gute Leistung erbringt, sind die im 802.11mc-Protokoll zurückgegebenen Bereiche idealerweise innerhalb des Key Performance Indicator (KPI) genau. Für den CDF-Fehler von 90 % wird bei den aufgeführten Bandbreiten erwartet, dass der empfohlene KPI für eine Reichweitenschätzung die folgenden Toleranzen aufweist:

  • 80 MHz: 2 Meter
  • 40 MHz: 4 Meter
  • 20 MHz: 8 Meter

Um sicherzustellen, dass die Implementierung der Funktion ordnungsgemäß funktioniert, sind Kalibrierungstests erforderlich.

Dies kann erreicht werden, indem eine Ground-Truth-Reichweite mit der geschätzten RTT-Reichweite bei zunehmenden Entfernungen verglichen wird. Für eine grundlegende Konformität sollten Sie Ihre Lösung anhand eines Geräts validieren, von dem bekannt ist, dass es RTT-kalibriert ist. Die Bereichskalibrierung sollte unter den folgenden Bedingungen getestet werden:

  1. Ein großes offenes Labor oder ein Korridor, in dem sich nicht viele Metallgegenstände befinden, kann zu ungewöhnlich häufigem Auftreten von Mehrwegeffekten führen.
  2. Mindestens eine Sichtlinie (LOS) über 25 m.
  3. Markierungen in 0,5-Meter-Schritten von einem Ende der Strecke zum anderen.
  4. Ein Ort zur Befestigung eines RTT-fähigen Access Points an einem Ende der Schiene, der 20 cm über dem Boden montiert ist, und einer beweglichen Halterung für ein Android-Telefon (oder ein anderes zu testendes Android-Mobilgerät), die entlang der Schiene bewegt und an der Schiene ausgerichtet werden kann 0,5-m-Markierungen, ebenfalls 20 cm über dem Boden. Hinweis: Diese sich wiederholende Aufgabe kann von einem kleinen Roboter ausgeführt werden, aber auch ein menschlicher Bediener ist in Ordnung.
  5. An jeder Markierung sollten 50 Entfernungsmessungsergebnisse zusammen mit der Entfernung vom Zugangspunkt aufgezeichnet werden. Statistiken wie Bereichsmittelwert und Varianz sollten für jede Markerposition berechnet werden.

Aus den Ergebnissen in Schritt 5 kann ein Diagramm für die Grundwahrheit (x-Achse) im Vergleich zur geschätzten Reichweite (y-Achse) und eine geschätzte Regressionslinie mit der besten Anpassung erstellt werden. Bei idealer Gerätekalibrierung ergibt sich eine Linie mit einer Steigung von 1,0 und einem Versatz von 0,0 m auf der Y-Achse. Abweichungen von diesen Werten sind akzeptabel, wenn sie innerhalb des KPI für die entsprechende Bandbreite liegen. Wenn die Ergebnisse außerhalb des KPI liegen, sollte die Gerätefunktion neu kalibriert werden, um die Ergebnisse innerhalb der KPI-Spezifikation zu bringen.