Wi-Fi-RTT (IEEE 802.11mc)

Mit der Funktion Wi-Fi Round Trip Time (RTT) in Android 9 können unterstützende Geräte die Entfernung zu anderen unterstützenden Geräten messen. Dabei spielt es keine Rolle, ob es sich um Zugangspunkte (APs) oder um Wi-Fi Aware-Peers handelt (falls Wi-Fi Aware auf dem Gerät unterstützt wird). Diese Funktion basiert auf dem IEEE 802.11mc-Protokoll und ermöglicht Apps eine verbesserte Standortgenauigkeit und ‐erkennung.

Beispiele und Quelle

Implementieren Sie zur Verwendung dieser Funktion die HAL-Schnittstelle des Anbieters. Ab Android 14 wird die HAL-Schnittstelle des Anbieters mithilfe von AIDL definiert. In Android 13 und niedriger wird die HAL-Schnittstelle des Anbieters mithilfe von HIDL definiert. In Android 8.0 ersetzt HIDL die vorherige HAL-Struktur (Hardware Abstraktionsschicht), die zur Optimierung von Implementierungen verwendet wurde. Dazu werden Typen und Methodenaufrufe angegeben, die in Schnittstellen und Paketen erfasst wurden.

Folgen Sie der WLAN-Benutzeroberfläche, um die WLAN-RTT-Funktion zu verwenden. Je nachdem, welche Schnittstelle implementiert ist, geschieht Folgendes:

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

Sie können dem alten WLAN-HAL entnehmen, wie es mit den AIDL- und HIDL-Schnittstellen korreliert: hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h.

Implementierung

Zum Implementieren von WLAN-RTT müssen Sie sowohl Framework- als auch HAL-/Firmware-Unterstützung bereitstellen:

  • Rahmenwerk:

    • AOSP-Code
    • WLAN-RTT aktivieren: Funktions-Flag erforderlich
  • Wi-Fi RTT (IEEE 802.11mc) HAL-Unterstützung (was Firmware-Unterstützung impliziert)

Implementieren Sie zum Implementieren dieser Funktion die Wi-Fi AIDL- oder HIDL-Schnittstelle und aktivieren Sie das Funktions-Flag:

  • Ändern Sie in device.mk in device/<oem>/<device> die Umgebungsvariable PRODUCT_COPY_FILES, um die WLAN-RTT-Funktion zu unterstützen:

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

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

Randomisierung bei MAC

Um den Datenschutz zu verbessern, muss die bei WLAN-RTT-Transaktionen verwendete MAC-Adresse zufällig angeordnet sein. Sie darf also nicht mit der nativen MAC-Adresse der WLAN-Schnittstelle übereinstimmen. Wenn ein Gerät jedoch mit einem ZP verknüpft ist, kann es die MAC-Adresse verwenden, der es für alle RTT-Transaktionen mit diesem ZP oder anderen ZPs zugeordnet ist.

Zertifizierungsstufe

Für diese Funktion gibt es CTS-Tests (Android Compatibility Test Suite). CTS erkennt, wann die Funktion aktiviert ist, und schließt die zugehörigen Tests automatisch ein. Diese Funktion kann auch mit der Vendor Test Suite (VTS) getestet werden.

Einheitentests

Die Tests des WLAN-RTT-Pakets werden folgendermaßen ausgeführt:

Diensttests:

atest com.android.server.wifi.rtt

Tests für Manager:

atest android.net.wifi.rtt

Logo: CTS

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

Die CTS-Tests können folgendermaßen ausgelöst werden:

atest WifiRttTest

Kalibrierung

Damit die WLAN-RTT eine gute Leistung erzielt, sind die im 802.11mc-Protokoll zurückgegebenen Bereiche idealerweise innerhalb des Leistungsindikators (KPI) genau. Für den CDF-Fehler von 90% wird erwartet, dass der empfohlene KPI für eine Bereichsschätzung bei den aufgeführten Bandbreiten die folgenden Toleranzen hat:

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

Um sicherzustellen, dass die Implementierung der Funktion korrekt funktioniert, ist ein Kalibrierungstest erforderlich.

Dazu wird ein Ground-Truth-Bereich mit dem geschätzten RTT-Bereich bei zunehmenden Entfernungen verglichen. Für die grundlegende Konformität sollten Sie Ihre Lösung mit einem Gerät validieren, das bekanntermaßen RTT-kalibriert ist. Die Bereichskalibrierung sollte unter folgenden Bedingungen getestet werden:

  1. Ein großes offenes Labor oder ein Korridor mit wenigen Metallobjekten, was zu ungewöhnlich hohen Vorkommen von Mehrwege führen kann.
  2. Mindestens eine Sichtverbindung oder ein Pfad mit einer Länge von 25 m
  3. Markierungen in 0,5-Meter-Schritten von einem Ende des Tracks zum anderen.
  4. Einen Ort, an dem ein RTT-fähiger Zugangspunkt an einem Ende der 20 cm über dem Boden angebrachten Schiene und eine bewegliche Halterung für ein Android-Smartphone (oder ein anderes zu testendes Android-Mobilgerät) gesichert werden können, die entlang der Spur bewegt werden kann und an den 0, 5-m-Markierungen 20 cm über dem Boden ausgerichtet ist.

  5. Für jede Markierung sollten 50 Entfernungsergebnisse zusammen mit der Entfernung vom Zugangspunkt aufgezeichnet werden. Für jede Markierungsposition sollten Statistiken berechnet werden, z. B. Bereichsmittelwert und Varianz.

Aus den Ergebnissen in Schritt 5 kann ein Diagramm für die Grundwahrheit (x-Achse) und den geschätzten Bereich (y-Achse) und eine am besten geeignete Regressionslinie gezeichnet werden. Die ideale Gerätekalibrierung ergibt eine Linie mit einem Farbverlauf von 1,0 mit einem Versatz von 0,0 m auf der y-Achse. Abweichungen von diesen Werten sind akzeptabel, wenn sie im KPI für die entsprechende Bandbreite liegen. Wenn die Ergebnisse außerhalb des KPI liegen, sollte die Gerätefunktion neu kalibriert werden, damit die Ergebnisse innerhalb der KPI-Spezifikation liegen.