DAR Wi-Fi (IEEE 802.11mc)

La fonctionnalité Délai aller-retour Wi-Fi (DAR) d'Android 9 permet aux appareils compatibles de mesurer la distance par rapport à 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 pris en charge sur l'appareil). Basée sur le protocole IEEE 802.11mc, cette fonctionnalité permet aux applications d'utiliser la détection et la précision de la localisation améliorées.

Exemples et source

Pour utiliser cette fonctionnalité, implémentez l'interface HAL du fournisseur. Dans Android 14 et versions ultérieures, l'interface HAL du fournisseur est définie à l'aide d'AIDL. Dans 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 les interfaces et les packages.

Suivez l'interface Wi-Fi pour utiliser la fonctionnalité de DAR Wi-Fi. En fonction de l'interface mise en œuvre, procédez comme suit:

  • 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 sa corrélation avec les interfaces AIDL et HIDL : hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h.

Implémentation

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

  • Cadre:

    • Code AOSP
    • Activer le DAR Wi-Fi: nécessite un flag de fonctionnalité
  • Compatibilité HAL avec le DAR Wi-Fi (IEEE 802.11mc) (ce qui implique la compatibilité avec le micrologiciel)

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

  • Dans le fichier device.mk situé dans device/<oem>/<device>, modifiez la variable d'environnement PRODUCT_COPY_FILES pour inclure la compatibilité avec la fonctionnalité de DAR 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 requis pour cette fonctionnalité est inclus dans AOSP.

randomisation MAC

Pour renforcer la confidentialité, l'adresse MAC utilisée lors des transactions DAR 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

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. Cette fonctionnalité peut également être testée à l'aide de la suite de test fournisseur (VTS).

Tests unitaires

Les tests du package DAR Wi-Fi sont exécutés à l'aide de la commande suivante:

Tests du service:

atest com.android.server.wifi.rtt

Tests du responsable:

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

Étalonnage

Pour que le DAR Wi-Fi soit performant, les plages renvoyées par le protocole 802.11mc doivent idéalement être précises au sein de l'indicateur clé de performance (KPI). Pour l'erreur CDF de 90 %, le KPI recommandé pour une estimation de plage doit avoir les tolérances suivantes pour les bandes passantes indiquées:

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

Pour vous assurer que l'implémentation de la fonctionnalité fonctionne correctement, un test de calibrage est nécessaire.

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. Grand laboratoire ouvert ou couloir qui ne comporte pas beaucoup d'objets métalliques, ce qui peut entraîner des occurrences anormalement élevées de trajets multiples.
  2. Au moins une voie ou un chemin de ligne de vue s'étendant sur 25 mètres.
  3. Les repères par incréments de 0,5 mètre s'incrémentent d'une extrémité du tracé à l'autre.
  4. Un endroit pour fixer un point d'accès compatible avec le texte en temps réel à une extrémité du rail installé à 20 cm au-dessus du sol, ainsi qu'un support mobile pour un téléphone Android (ou un autre appareil mobile Android en cours de test) pouvant être déplacé le long de la trajectoire 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, il est possible de dessiner un graphique de vérité terrain (axe des abscisses) en fonction de la plage estimée (axe des ordonnées) et d'une ligne de régression de meilleur ajustement estimée. Le calibrage idéal de l'appareil se traduit par une ligne de dégradé de 1,0 avec un décalage de 0,0 m sur l'axe Y. Les écarts par rapport à ces valeurs sont acceptables si elles 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 que les résultats soient conformes à la spécification du KPI.