La fonctionnalité Wi-Fi Round Trip Time (RTT) d'Android 9 permet aux appareils compatibles de mesurer la distance qui les sépare 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 (disponibles à 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 Vendor HAL. Dans Android 14 et versions ultérieures, l'interface Vendor HAL est définie à l'aide d'AIDL. Dans 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 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 l'interface Wi-Fi pour utiliser la fonctionnalité Wi-Fi RTT. Selon l'interface implémentée, il s'agit de :
- AIDL :
hardware/interfaces/wifi/aidl - HIDL :
hardware/interfaces/wifi/1.0ou version ultérieure.
Vous pouvez vous référer à l'ancienne HAL Wi-Fi pour voir comment elle est corrélée aux interfaces AIDL et HIDL : hardware/libhardware_legacy/+/android16-release/include/hardware_legacy/rtt.h.
Implémentation
Pour implémenter Wi-Fi RTT, vous devez fournir une assistance pour le framework, le HAL et le micrologiciel :
Framework :
- Code AOSP
- Activer le Wi-Fi RTT : nécessite un flag de fonctionnalité
Prise en charge de la couche d'abstraction matérielle (HAL) Wi-Fi RTT (IEEE 802.11mc ou IEEE 802.11az) (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 le flag de fonctionnalité :
Dans
device.mksitué dansdevice/<oem>/<device>, modifiez la variable d'environnementPRODUCT_COPY_FILESpour inclure la compatibilité avec 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 nécessaire pour cette fonctionnalité est inclus dans AOSP.
Randomisation de l'adresse MAC
Pour renforcer 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 intégrée 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 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é. Le 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 la Vendor Test Suite (VTS).
Tests unitaires
Les tests du package Wi-Fi RTT sont exécutés à l'aide des éléments suivants :
Tests de service :
atest com.android.server.wifi.rttTests pour les administrateurs :
atest android.net.wifi.rttCTS
Des tests Android Compatibility Test Suite (CTS) existent pour cette fonctionnalité. Le CTS détecte lorsque la fonctionnalité est activée et inclut automatiquement les tests associés. Un point d'accès compatible avec 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 des méthodes suivantes :
atest WifiRttTestCalibrage
Pour que le Wi-Fi RTT 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) décrits dans cette section.
Pour le protocole 11mc, aux bandes passantes listées (80 MHz, 40 MHz, 20 MHz) et avec une taille de rafale de 8, le KPI pour une estimation de portée devrait atteindre la précision suivante au 90e centile 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, Long Training Field) affectent la précision. Avec un téléphone mobile typique (utilisant deux antennes) et un point d'accès (quatre antennes), le système dispose d'une configuration MIMO 2x4. Pour une telle configuration utilisant un facteur de répétition LTF de deux et aux bandes passantes listées (160 MHz, 80 MHz, 40 MHz, 20 MHz), le KPI pour une estimation de la portée devrait atteindre la précision 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 vérifier que l'implémentation de la fonctionnalité fonctionne correctement, il est nécessaire de tester la calibration.
Pour ce faire, comparez une plage de vérité terrain à la plage RTT estimée à des distances croissantes. Pour une conformité de base, nous vous recommandons de valider votre solution sur un appareil connu pour être calibré RTT. Nous vous recommandons de tester la calibration de la plage dans les conditions suivantes :
- Un grand laboratoire ouvert ou un couloir ne comportant pas beaucoup d'objets métalliques susceptibles d'entraîner une occurrence anormalement élevée de trajets multiples.
- Au moins une trajectoire ou un chemin en visibilité directe (LOS) s'étendant sur 25 m.
- Repères de 0,5 mètre de chaque côté de la piste.
Un emplacement pour fixer un point d'accès compatible avec la technologie RTT à une extrémité de la piste, à 20 cm au-dessus du sol, et un support mobile pour un téléphone Android (ou un autre appareil mobile Android en cours de test) qui peut être déplacé le long de la piste et aligné sur les repères de 0,5 m, également à 20 cm au-dessus du sol.
Nous vous recommandons d'enregistrer 50 résultats de mesure de distance à chaque repère, ainsi que la distance par rapport au point d'accès. Les 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 tracé pour la vérité terrain (axe X) par rapport à la plage estimée (axe Y), et une ligne de régression du meilleur ajustement peut être estimée. L'étalonnage idéal de l'appareil se traduit 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 de la bande passante correspondante. Si les résultats sont en dehors du KPI, nous vous recommandons de recalibrer la fonctionnalité de l'appareil pour les ramener dans les spécifications du KPI.