Wi-Fi RTT (IEEE 802.11mc)

La función de tiempo de ida y vuelta (RTT) de Wi-Fi en Android 9 permite que los dispositivos compatibles midan una distancia a otros dispositivos compatibles: ya sean puntos de acceso (AP) o pares compatibles con Wi-Fi (si Wi-Fi Aware es compatible con el dispositivo). Esta característica, basada en el protocolo IEEE 802.11mc, permite que las aplicaciones utilicen una mayor precisión y conocimiento de la ubicación.

Ejemplos y fuente

Para utilizar esta función, implemente la interfaz Vendor HAL. En Android 14 y versiones posteriores, la interfaz Vendor HAL se define mediante AIDL. En Android 13 y versiones anteriores, la interfaz HAL del proveedor se define mediante HIDL. En Android 8.0, HIDL reemplazó la estructura anterior de Capa de abstracción de hardware (HAL) utilizada para optimizar las implementaciones especificando tipos y llamadas a métodos recopiladas en interfaces y paquetes.

Siga la interfaz de Wi-Fi para emplear la función Wi-Fi RTT. Dependiendo de qué interfaz se implemente, esta es:

  • AIDL: hardware/interfaces/wifi/aidl
  • HIDL: hardware/interfaces/wifi/1.0 o posterior.

Puede consultar el Wi-Fi HAL heredado para ver cómo se correlaciona con las interfaces AIDL y HIDL: hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h .

Implementación

Para implementar Wi-Fi RTT, debe proporcionar soporte tanto de marco como de HAL/firmware:

  • Estructura:

    • código AOSP
    • Habilitar Wi-Fi RTT: requiere una marca de función

  • Soporte Wi-Fi RTT (IEEE 802.11mc) HAL (lo que implica soporte de firmware)

Para implementar esta función, implemente la interfaz Wi-Fi AIDL o HIDL y habilite el indicador de función:

  • En device.mk ubicado en device/<oem>/<device> , modifique la variable de entorno PRODUCT_COPY_FILES para incluir compatibilidad con la función 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

De lo contrario, todo lo necesario para esta función está incluido en AOSP.

Aleatorización de MAC

Para mejorar la privacidad, la dirección MAC utilizada durante las transacciones Wi-Fi RTT debe ser aleatoria, es decir, no debe coincidir con la dirección MAC nativa de la interfaz Wi-Fi. Sin embargo, como excepción, cuando un dispositivo está asociado con un AP, puede usar la dirección MAC con la que está asociado para cualquier transacción RTT con ese AP o con otros AP.

Validación

Existen pruebas del conjunto de pruebas de compatibilidad de Android (CTS) para esta función. CTS detecta cuando la función está habilitada e incluye automáticamente las pruebas asociadas. Esta característica también se puede probar utilizando Vendor Test Suite (VTS) y acts/sl4a , un conjunto de pruebas que realiza pruebas de integración exhaustivas.

Pruebas unitarias

Las pruebas del paquete Wi-Fi RTT se ejecutan utilizando:

Pruebas de servicio:

atest com.android.server.wifi.rtt

Pruebas de gerente:

atest android.net.wifi.rtt

Pruebas de integración (ACTS)

El conjunto de pruebas acts/sl4a, descrito en /tools/test/connectivity/acts_tests/tests/google/wifi/rtt/README.md , proporciona pruebas funcionales, de rendimiento y de estrés.

cts

Existen pruebas del conjunto de pruebas de compatibilidad de Android (CTS) para esta función. CTS detecta cuando la función está habilitada e incluye automáticamente las pruebas asociadas. Un punto de acceso que admita Wi-Fi RTT (IEEE 802.11mc) debe estar dentro del alcance del dispositivo bajo prueba.

Las pruebas CTS se pueden activar usando:

atest WifiRttTest

Calibración

Para que Wi-Fi RTT funcione bien, los rangos devueltos en el protocolo 802.11mc son idealmente precisos dentro del indicador clave de rendimiento (KPI). Para el error CDF del 90 %, en los anchos de banda enumerados, se espera que el KPI recomendado para una estimación de rango tenga las siguientes tolerancias:

  • 80MHz: 2 metros
  • 40MHz: 4 metros
  • 20MHz: 8 metros

Para garantizar que la implementación de la función funcione correctamente, es necesario realizar pruebas de calibración.

Esto se puede lograr comparando un rango real sobre el terreno con el rango estimado de RTT a distancias crecientes. Para una conformidad básica, debe validar su solución con un dispositivo que se sepa que está calibrado con RTT. La calibración del rango debe probarse en las siguientes condiciones:

  1. Un gran laboratorio abierto o un corredor que no tenga muchos objetos metálicos que puedan provocar una incidencia inusualmente alta de trayectorias múltiples.
  2. Al menos una pista/camino con línea de visión (LOS) que se extienda por 25 m.
  3. Marcadores en incrementos de 0,5 metros de un extremo al otro de la pista.
  4. Un lugar para asegurar un punto de acceso con capacidad RTT en un extremo de la pista montado a 20 cm sobre el suelo, y un soporte móvil para un teléfono Android (u otro dispositivo móvil Android bajo prueba) que se puede mover a lo largo de la pista y alinearse con el Marcadores de 0,5 m, también a 20 cm del suelo. Nota: Esta tarea repetitiva puede ser realizada por un pequeño robot, pero un operador humano también está bien.
  5. Se deben registrar 50 resultados de alcance en cada marcador, junto con la distancia desde el punto de acceso. Se deben calcular estadísticas, como la media y la varianza del rango, para cada posición del marcador.

A partir de los resultados del paso 5, se puede dibujar un gráfico para la verdad fundamental (eje x) frente al rango estimado (eje y) y una línea de regresión de mejor ajuste estimada. La calibración ideal del dispositivo dará como resultado una línea de gradiente de 1,0, con un desplazamiento de 0,0 m en el eje y. Las desviaciones de estos valores son aceptables si están dentro del KPI para el ancho de banda correspondiente. Si los resultados están fuera del KPI, la función del dispositivo debe recalibrarse para que los resultados estén dentro de la especificación KPI.