Wi-Fi RTT (IEEE 802.11mc)

La fonction Wi-Fi Round Trip Time (RTT) d'Android 9 permet aux appareils prenant en charge de mesurer une distance par rapport à d'autres appareils prenant en charge : qu'il s'agisse de points d'accès (AP) ou d'homologues 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 le langage de conception d'interface matérielle Wi-Fi (HIDL) fourni dans le projet Open Source Android (AOSP). Dans Android 8.0, HIDL remplace la structure précédente de la couche d'abstraction matérielle (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 le Wi-Fi HIDL pour utiliser la fonctionnalité Wi-Fi RTT : 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 corrélé avec la nouvelle interface HIDL : hardware/libhardware_legacy/+/master/include/hardware_legacy/rtt.h .

Mise en œuvre

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

  • 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 le Wi-Fi 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 ce point d'accès ou avec d'autres points d'accès.

Validation

Des tests Android Compatibility Test Suite (CTS) existent pour cette fonctionnalité. CTS détecte quand 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 d'acts/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 à l'aide de :

Essais de service :

atest com.android.server.wifi.rtt

Épreuves du gestionnaire :

atest android.net.wifi.rtt

Essais d'intégration (ACTS)

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

CTS

Des tests Android Compatibility Test Suite (CTS) existent pour cette fonctionnalité. CTS détecte quand 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 se trouver à 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 bien, les plages renvoyées dans le protocole 802.11mc sont idéalement précises dans l'indicateur de performance clé (KPI). Pour l'erreur CDF de 90 %, aux bandes passantes répertoriées, le KPI recommandé pour une estimation de plage devrait avoir les tolérances suivantes :

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

Pour s'assurer que la mise en œuvre de la fonctionnalité fonctionne correctement, des tests d'étalonnage sont nécessaires.

Ceci peut être réalisé en comparant une plage de vérité terrain à 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 qui ne contient pas beaucoup d'objets métalliques pouvant entraîner des occurrences inhabituellement élevées de trajets multiples.
  2. Au moins une piste/chemin en visibilité directe (LOS) s'étendant sur 25 m.
  3. Marqueurs de 0,5 mètre d'incréments d'un bout à l'autre de la piste.
  4. Un emplacement 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 un autre appareil mobile Android testé) pouvant être déplacé le long du rail et aligné avec le Marqueurs de 0,5 m, également à 20 cm au-dessus 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 la plage, doivent être calculées pour chaque position de marqueur.

À partir des résultats de l'étape 5, un graphique peut être tracé pour la vérité terrain (axe des x) par rapport à la plage estimée (axe des y) et une ligne de régression de meilleur ajustement estimée. L'étalonnage idéal de l'appareil se traduira par une ligne de gradient 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 le 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 la spécification du KPI.