Wi-Fi RTT (IEEE 802.11mc)

La fonctionnalité Wi-Fi Round Trip Time (RTT) d'Android 9 permet aux appareils pris en charge de mesurer une distance par rapport à d'autres appareils pris en charge : qu'il s'agisse de points d'accès (AP) ou de pairs Wi-Fi Aware (si Wi-Fi Aware est pris en charge sur le appareil). Cette fonctionnalité, basée sur le protocole IEEE 802.11mc, permet aux applications d'utiliser une précision et une connaissance améliorées de la localisation.

Exemples et source

Pour utiliser cette fonctionnalité, implémentez l’interface Vendor HAL. Sous Android 14 et versions ultérieures, l’interface Vendor HAL est définie à l’aide de AIDL. Sous Android 13 et versions antérieures, l’interface Vendor HAL est définie à l’aide de HIDL. Dans Android 8.0, HIDL a remplacé la précédente structure Hardware Abstraction Layer (HAL) utilisée pour rationaliser les implémentations en spécifiant les types et les appels de méthode collectés dans les interfaces et les packages.

Suivez l'interface Wi-Fi pour utiliser la fonction Wi-Fi RTT. Selon l'interface implémentée, il s'agit de :

  • AIDL : hardware/interfaces/wifi/aidl
  • HIDL : hardware/interfaces/wifi/1.0 ou version ultérieure.

Vous pouvez vous référer à l'ancien Wi-Fi HAL pour voir comment il est en corrélation avec les interfaces AIDL et HIDL : hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h .

Mise en œuvre

Pour implémenter le Wi-Fi RTT, vous devez fournir à la fois la prise en charge du framework et du HAL/micrologiciel :

  • Cadre:

    • Code AOSP
    • Activer Wi-Fi RTT : nécessite un indicateur de fonctionnalité
  • Prise en charge Wi-Fi RTT (IEEE 802.11mc) HAL (ce qui implique la prise en charge du micrologiciel)

Pour implémenter cette fonctionnalité, implémentez l'interface Wi-Fi AIDL ou HIDL et activez l'indicateur de fonctionnalité :

  • Dans device.mk situé dans device/<oem>/<device> , modifiez la variable d'environnement PRODUCT_COPY_FILES pour inclure la prise en charge de la fonctionnalité 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
    

Sinon, tout ce qui est requis pour cette fonctionnalité est inclus dans AOSP.

Randomisation MAC

Pour améliorer la confidentialité, l'adresse MAC utilisée lors des transactions Wi-Fi RTT doit être aléatoire, c'est-à-dire qu'elle ne doit pas correspondre à l'adresse MAC native de l'interface Wi-Fi. Cependant, à titre exceptionnel, lorsqu'un appareil est associé à un point d'accès, il peut utiliser l'adresse MAC à laquelle il est associé pour toute transaction RTT avec cet point d'accès ou avec d'autres points d'accès.

Validation

Des tests CTS (Android Compatibility Test Suite) existent pour cette fonctionnalité. CTS détecte lorsque la fonctionnalité est activée et inclut automatiquement les tests associés. Cette fonctionnalité peut également être testée à l'aide de Vendor Test Suite (VTS) et de actes/sl4a , une suite de tests qui effectue des tests d'intégration approfondis.

Tests unitaires

Les tests du package Wi-Fi RTT sont exécutés en utilisant :

Tests de service :

atest com.android.server.wifi.rtt

Tests du gestionnaire :

atest android.net.wifi.rtt

Tests d'intégration (ACTS)

La suite de tests actes/sl4a, décrite dans /tools/test/connectivity/acts_tests/tests/google/wifi/rtt/README.md , fournit des tests fonctionnels, de performances et de stress.

CTS

Des tests CTS (Android Compatibility Test Suite) existent pour cette fonctionnalité. CTS détecte lorsque la fonctionnalité est activée et inclut automatiquement les tests associés. Un point d'accès prenant en charge le Wi-Fi RTT (IEEE 802.11mc) doit être à portée de l'appareil testé.

Les tests CTS peuvent être déclenchés à l'aide de :

atest WifiRttTest

Étalonnage

Pour que le Wi-Fi RTT fonctionne correctement, les plages renvoyées dans le protocole 802.11mc sont idéalement précises au sein de l'indicateur clé de performance (KPI). Pour l'erreur CDF de 90 %, pour les bandes passantes répertoriées, le KPI recommandé pour une estimation de plage devrait avoir les tolérances suivantes :

  • 80 MHz : 2 mètres
  • 40 MHz : 4 mètres
  • 20 MHz : 8 mètres

Pour garantir le bon fonctionnement de la mise en œuvre de la fonctionnalité, des tests d’étalonnage sont nécessaires.

Ceci peut être réalisé en comparant une plage de vérité terrain avec la plage estimée RTT à des distances croissantes. Pour une conformité de base, vous devez valider votre solution par rapport à un appareil connu pour être calibré RTT. L'étalonnage de la plage doit être testé dans les conditions suivantes :

  1. Un grand laboratoire ouvert ou un couloir ne contenant pas beaucoup d'objets métalliques pouvant entraîner des occurrences inhabituellement élevées de trajets multiples.
  2. Au moins une piste/un chemin à visibilité directe (LOS) s'étendant sur 25 m.
  3. Balises au pas de 0,5 mètre d’un bout à l’autre de la piste.
  4. Un endroit pour sécuriser un point d'accès compatible RTT à une extrémité du rail monté à 20 cm au-dessus du sol, et un support mobile pour un téléphone Android (ou autre appareil mobile Android testé) qui peut être déplacé le long du rail et aligné avec le Balises de 0,5 m, également à 20 cm du sol. Remarque : Cette tâche répétitive peut être effectuée par un petit robot, mais un opérateur humain convient également.
  5. 50 résultats de télémétrie doivent être enregistrés à chaque marqueur, ainsi que la distance depuis le point d'accès. Les statistiques, telles que la moyenne et la variance de l'étendue, doivent être calculées pour chaque position de marqueur.

À partir des résultats de l'étape 5, un graphique peut être établi pour la vérité terrain (axe des x) par rapport à la plage estimée (axe des y) et une ligne de régression la mieux ajustée estimée. L'étalonnage idéal de l'appareil donnera lieu à une ligne de pente de 1,0, avec un décalage de 0,0 m sur l'axe y. Les écarts par rapport à ces valeurs sont acceptables s'ils se situent dans les limites du KPI pour la bande passante correspondante. Si les résultats sont en dehors du KPI, la fonctionnalité de l'appareil doit être recalibrée pour amener les résultats dans les spécifications du KPI.