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

La fonctionnalité Wi-Fi Round Trip Time (RTT) d'Android 9 permet aux appareils compatibles de mesurer la distance avec d'autres appareils compatibles, qu'il s'agisse de points d'accès (PA) ou de pairs Wi-Fi Aware (si Wi-Fi Aware est compatible avec l'appareil). Cette fonctionnalité, basée sur les protocoles IEEE 802.11mc et IEEE 802.11az (disponible à partir d'Android 15), permet aux applications d'utiliser une précision et une connaissance de la position améliorées.

Exemples et source

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

Suivez les instructions de l'interface Wi-Fi pour utiliser la fonctionnalité RTT Wi-Fi. 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 reporter à l'ancien HAL Wi-Fi pour voir comment il se rapporte aux interfaces AIDL et HIDL : hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h.

Implémentation

Pour implémenter le RTT Wi-Fi, vous devez fournir une compatibilité avec le framework et le HAL/micrologiciel:

  • Cadre:

    • Code AOSP
    • Activer le RTT Wi-Fi: nécessite un flag de fonctionnalité

  • Compatibilité HAL Wi-Fi (IEEE 802.11mc ou IEEE 802.11az) avec HAL (ce qui implique la compatibilité avec le micrologiciel)

Pour implémenter cette fonctionnalité, implémentez l'interface AIDL ou HIDL Wi-Fi, puis 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é RTT Wi-Fi:

    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 nécessaire pour cette fonctionnalité est inclus dans AOSP.

Randomisation MAC

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

Validation

Des tests CTS (Compatibility Test Suite) existent pour cette fonctionnalité. CTS détecte quand la fonctionnalité est activée et inclut automatiquement les tests associés. Vous pouvez également tester cette fonctionnalité à l'aide de la suite de test de fournisseur (VTS).

Tests unitaires

Les tests du package RTT Wi-Fi sont exécutés à l'aide des éléments suivants:

Tests de service:

atest com.android.server.wifi.rtt

Tests administrateur:

atest android.net.wifi.rtt

CTS

Il existe des tests CTS (Android Compatibility Test Suite) pour cette fonctionnalité. CTS détecte quand la fonctionnalité est activée et inclut automatiquement les tests associés. Un point d'accès compatible avec le RTT Wi-Fi (IEEE 802.11mc) doit se trouver à portée de l'appareil testé.

Les tests CTS peuvent être déclenchés à l'aide des éléments suivants:

atest WifiRttTest

Calibrage

Pour que le RTT Wi-Fi fonctionne correctement, les plages renvoyées dans les protocoles 802.11mc ou 802.11az doivent être précises dans les indicateurs clés de performance (KPI), comme décrit dans cette section.

Pour le protocole 11mc, pour les bandes de fréquences indiquées (80 MHz, 40 MHz, 20 MHz) et pour une taille de rafale de 8, le KPI pour une estimation de la portée devrait atteindre la précision suivante au 90e percentile d'erreur.

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

Pour le protocole 11az, la configuration MIMO de l'antenne et la répétition du champ d'entraînement long (LTF) affectent la précision. Avec un téléphone mobile standard (utilisant deux antennes) et un point d'accès (quatre antennes), le système présente une configuration MIMO 2x4. Pour une telle configuration utilisant un facteur de répétition LTF de 2 et aux bandes passantes répertoriées (160 MHz, 80 MHz, 40 MHz, 20 MHz), le KPI d'une estimation de plage devrait atteindre la justesse suivante au 90e centile d'erreur.

  • 160 MHz:0,5 mètre
  • 80 MHz:1 mètre
  • 40 MHz:2 mètres
  • 20 MHz:4 mètres

Pour vous assurer que l'implémentation de la fonctionnalité fonctionne correctement, vous devez effectuer des tests de calibrage.

Pour ce faire, vous pouvez comparer une plage de vérité terrain à la plage estimée du DAR à des distances croissantes. Pour obtenir une conformité de base, vous devez valider votre solution par rapport à un appareil connu pour être calibré en DAR. 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 peut entraîner des occurrences inhabituellement élevées de multichemin.
  2. Au moins une voie ou un chemin en ligne de vue (LOS) s'étendant sur 25 m.
  3. Repères espacés de 0,5 mètre d'une extrémité à l'autre de la voie.

  4. Un emplacement pour fixer un point d'accès compatible avec le RTT à une extrémité du rail, à 20 cm du sol, et un support mobile pour un téléphone Android (ou tout autre appareil mobile Android testé) pouvant être déplacé le long du rail et aligné sur les repères de 0,5 m, également à 20 cm du sol.

  5. 50 résultats de distance doivent être enregistrés à chaque repère, ainsi que la distance par rapport au point d'accès. Des statistiques, telles que la moyenne et la variance de la plage, doivent être calculées pour chaque position de repère.

À partir des résultats de l'étape 5, un graphique peut être établi pour la vérité terrain (axe X) par rapport à la plage estimée (axe Y), et une ligne de régression de meilleure approximation peut être estimée. Une calibration idéale de l'appareil génère une ligne de gradient 1,0, avec un décalage de 0,0 m sur l'axe des ordonnées. Les écarts par rapport à ces valeurs sont acceptables s'ils se situent dans le KPI de la bande passante correspondante. Si les résultats ne respectent pas le KPI, la fonctionnalité de l'appareil doit être recalibrée pour que les résultats soient conformes aux spécifications du KPI.