Wi-Fi RTT (IEEE 802.11mc, IEEE 802.11az)

Mit der Funktion Wi‑Fi Round Trip Time (RTT) in Android 9 können unterstützte Geräte die Entfernung zu anderen unterstützten Geräten messen, unabhängig davon, ob es sich um Zugangspunkte (APs) oder Wi‑Fi Aware-Peers handelt (sofern Wi‑Fi Aware auf dem Gerät unterstützt wird). Diese Funktion basiert auf den Protokollen IEEE 802.11mc und IEEE 802.11az (verfügbar ab Android 15) und ermöglicht Apps eine verbesserte Standortgenauigkeit und -erkennung.

Beispiele und Quelle

Wenn Sie diese Funktion verwenden möchten, müssen Sie die HAL-Schnittstelle des Anbieters implementieren. In Android 14 und höher wird die HAL-Schnittstelle des Anbieters mit AIDL definiert. In Android 13 und niedriger wird die HAL-Schnittstelle des Anbieters mit HIDL definiert. In Android 8.0 ersetzte HIDL die vorherige HAL-Struktur (Hardware Abstraction Layer), mit der Implementierungen durch Angabe von Typen und Methodenaufrufen optimiert wurden, die in Schnittstellen und Pakete aufgenommen wurden.

Folgen Sie der Anleitung in der WLAN-Benutzeroberfläche, um die WLAN-RTT-Funktion zu verwenden. Je nach implementierter Schnittstelle ist das:

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

In der alten Wi‑Fi HAL können Sie sehen, wie sie mit den AIDL- und HIDL-Schnittstellen korreliert: hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h.

Implementierung

Wenn Sie Wi‑Fi RTT implementieren möchten, müssen Sie sowohl Framework- als auch HAL-/Firmware-Unterstützung bereitstellen:

  • Framework:

    • AOSP-Code
    • WLAN-RTT aktivieren: Erfordert ein Funktions-Flag

  • HAL-Unterstützung für Wi‑Fi RTT (IEEE 802.11mc oder IEEE 802.11az) (impliziert Firmware-Unterstützung)

Implementieren Sie dazu 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 so, dass die Unterstützung für die Wi‑Fi-RTT-Funktion enthalten ist:

    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-Adressrandomisierung

Um den Datenschutz zu verbessern, muss die MAC-Adresse, die bei Wi‑Fi-RTT-Transaktionen verwendet wird, zufällig sein. Das bedeutet, dass sie nicht mit der nativen MAC-Adresse der WLAN-Schnittstelle übereinstimmen darf. Ausnahmsweise kann ein Gerät, das mit einem ZP verknüpft ist, die MAC-Adresse, die ihm zugewiesen ist, für alle RTT-Transaktionen mit diesem ZP oder anderen ZPs verwenden.

Zertifizierungsstufe

Für diese Funktion gibt es CTS-Tests (Compatibility Test Suite). CTS erkennt, wenn 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

CTS

Für diese Funktion gibt es CTS-Tests (Compatibility Test Suite). CTS erkennt, wenn 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 mit folgenden Methoden ausgelöst werden:

atest WifiRttTest

Kalibrierung

Damit die Leistung von Wi‑Fi RTT hoch ist, sollten die in den 802.11mc- oder 802.11az-Protokollen zurückgegebenen Bereiche innerhalb der in diesem Abschnitt beschriebenen Leistungskennzahlen (KPIs) liegen.

Bei den aufgeführten Bandbreiten (80 MHz, 40 MHz, 20 MHz) und einer Burst-Größe von 8 wird für das 11mc-Protokoll mit der folgenden Genauigkeit gerechnet, wenn der Fehler beim 90. Perzentil liegt.

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

Beim 11az-Protokoll wirken sich die MIMO-Konfiguration der Antenne und die Wiederholungen im Long Training Field (LTF) auf die Genauigkeit aus. Mit einem typischen Smartphone (mit 2 Antennen) und einem Zugangspunkt (4 Antennen) hat das System eine 2x4-MIMO-Konfiguration. Für eine solche Konfiguration mit einem LTF-Wiederholungsfaktor von zwei und bei den aufgeführten Bandbreiten (160 MHz, 80 MHz, 40 MHz, 20 MHz) wird erwartet, dass der KPI für eine Bereichsschätzung die folgende Genauigkeit beim 90. Perzentil des Fehlers erreicht.

  • 160 MHz:0,5 Meter
  • 80 MHz:1 Meter
  • 40 MHz:2 Meter
  • 20 MHz:4 Meter

Um sicherzustellen, dass die Implementierung der Funktion ordnungsgemäß funktioniert, sind Kalibrierungstests 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 an einem Gerät validieren, das bekanntlich RTT-kalibriert ist. Die Bereichskalibrierung sollte unter den folgenden Bedingungen getestet werden:

  1. Ein großes offenes Labor oder ein Flur ohne viele Metallgegenstände kann zu ungewöhnlich häufigen Mehrwegeeffekten führen.
  2. Mindestens ein Sichtverbindungs-Track oder -Pfad, der sich über 25 m erstreckt.
  3. Markierungen im Abstand von 0,5 Metern von einem Ende der Strecke zum anderen.

  4. Einen Platz zum Befestigen eines RTT-fähigen Zugangspunkts an einem Ende der Schiene, 20 cm über dem Boden, und eine bewegliche Halterung für ein Android-Smartphone (oder ein anderes getestetes Android-Mobilgerät), das entlang der Schiene bewegt und mit den Markierungen von 0,5 m ausgerichtet werden kann, ebenfalls 20 cm über dem Boden.

  5. Für jede Markierung sollten 50 Entfernungsergebnisse zusammen mit der Entfernung vom Zugangspunkt aufgezeichnet werden. Statistiken wie Mittelwert und Varianz des Bereichs sollten für jede Markierungsposition berechnet werden.

Anhand der Ergebnisse aus Schritt 5 kann ein Diagramm für die Ground-Truth-Daten (x-Achse) im Vergleich zum geschätzten Bereich (y-Achse) erstellt und eine Regressionsgerade der besten Anpassung geschätzt 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 zulässig, 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, damit die Ergebnisse innerhalb der KPI-Spezifikation liegen.