La función Tiempo de ida y vuelta (RTT) de Wi-Fi en Android 9 permite que los dispositivos compatibles midan la distancia a otros dispositivos compatibles, ya sean puntos de acceso (PA) o pares con Wi-Fi Aware (si el dispositivo admite Wi-Fi Aware). Esta función, basada en los protocolos IEEE 802.11mc y IEEE 802.11az (disponibles desde Android 15), permite que las apps usen el reconocimiento y la precisión de ubicación mejoradas.
Ejemplos y fuente
Para usar esta función, implementa la interfaz HAL del proveedor. En Android 14 y versiones posteriores, la interfaz de la HAL del proveedor se define con AIDL. En Android 13 y versiones anteriores, la interfaz de la HAL del proveedor se define con HIDL. En Android 8.0, HIDL reemplazó la estructura anterior de la capa de abstracción de hardware (HAL) que se usaba para optimizar las implementaciones especificando tipos y llamadas a métodos recopilados en interfaces y paquetes.
Sigue la interfaz de Wi-Fi para usar la función de Wi-Fi RTT. Según la interfaz que se implemente, esto es lo siguiente:
- AIDL:
hardware/interfaces/wifi/aidl - HIDL:
hardware/interfaces/wifi/1.0o posterior
Puedes consultar la HAL de Wi-Fi heredada para ver cómo se correlaciona con las interfaces de AIDL y HIDL: hardware/libhardware_legacy/+/android16-release/include/hardware_legacy/rtt.h.
Implementación
Para implementar Wi-Fi RTT, debes proporcionar compatibilidad con el framework y el HAL/firmware:
Framework:
- Código del AOSP
- Habilita el RTT de Wi-Fi: Requiere una marca de función
Compatibilidad con HAL de Wi-Fi RTT (IEEE 802.11mc o IEEE 802.11az) (lo que implica compatibilidad con firmware)
Para implementar esta función, implementa la interfaz AIDL o HIDL de Wi-Fi y habilita la marca de función:
En
device.mk, ubicado endevice/<oem>/<device>, modifica la variable de entornoPRODUCT_COPY_FILESpara incluir la compatibilidad con la función de RTT de 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
De lo contrario, AOSP incluye todo lo necesario para esta función.
Aleatorización de MAC
Para mejorar la privacidad, la dirección MAC que se usa durante las transacciones de RTT de Wi-Fi debe ser aleatoria, es decir, no debe coincidir con la dirección MAC nativa de la interfaz de Wi-Fi. Sin embargo, como excepción, cuando un dispositivo está asociado a un AP, puede usar la dirección MAC con la que está asociado para cualquier transacción de RTT con ese AP o con otros APs.
Validación
Existen pruebas del Conjunto de pruebas de compatibilidad (CTS) de Android para esta función. El CTS detecta cuando la función está habilitada y, automáticamente, incluye las pruebas asociadas. Esta función también se puede probar con el conjunto de pruebas de proveedores (VTS).
Pruebas de unidades
Las pruebas del paquete de Wi-Fi RTT se ejecutan con lo siguiente:
Pruebas de servicio:
atest com.android.server.wifi.rttPruebas de administrador:
atest android.net.wifi.rttCTS
Existen pruebas del Conjunto de pruebas de compatibilidad (CTS) de Android para esta función. El CTS detecta cuando la función está habilitada y, automáticamente, incluye las pruebas asociadas. Un punto de acceso que admita Wi-Fi RTT (IEEE 802.11mc) debe estar dentro del alcance del dispositivo en prueba.
Las pruebas de CTS se pueden activar con lo siguiente:
atest WifiRttTestCalibración
Para que el RTT de Wi-Fi funcione bien, los rangos que se devuelven en los protocolos 802.11mc o 802.11az deben ser precisos dentro de los indicadores clave de rendimiento (KPI) como se describe en esta sección.
Para el protocolo 11mc, en los anchos de banda indicados (80 MHz, 40 MHz y 20 MHz) y con un tamaño de ráfaga de 8, se espera que el KPI para una estimación de rango alcance la siguiente precisión en el percentil 90 de error.
- 80 MHz: 2 metros
- 40 MHz: 4 metros
- 20 MHz: 8 metros
En el caso del protocolo 11az, la configuración MIMO de la antena y la repetición del campo de entrenamiento largo (LTF) afectan la precisión. Con un teléfono celular típico (que usa 2 antenas) y un punto de acceso (4 antenas), el sistema tiene una configuración MIMO 2x4. Para una configuración de este tipo que usa un factor de repetición de LTF de dos y en los anchos de banda indicados (160 MHz, 80 MHz, 40 MHz y 20 MHz), se espera que el KPI para una estimación de rango alcance la siguiente precisión en el percentil 90 de error.
- 160 MHz: 0.5 metros
- 80 MHz: 1 metro
- 40 MHz: 2 metros
- 20 MHz: 4 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 de verdad fundamental con el rango estimado del RTT a distancias cada vez mayores. Para la conformidad básica, debes validar tu solución con un dispositivo que se sepa que está calibrado para el RTT. La calibración de rango debe probarse en las siguientes condiciones:
- Un laboratorio abierto grande o un corredor que no tenga muchos objetos metálicos que puedan generar una cantidad inusualmente alta de trayectos múltiples.
- Al menos un tramo o una ruta de línea de visión (LOS) que se extienda por 25 m
- Marcadores con incrementos de 0.5 metros de un extremo a otro de la pista.
Un lugar para fijar un punto de acceso compatible con RTT en un extremo del riel, a 20 cm del piso, y un soporte móvil para un teléfono Android (o cualquier otro dispositivo móvil Android en prueba) que se pueda mover a lo largo del riel y alinear con los marcadores de 0.5 m, también a 20 cm del piso.
En cada marcador, se deben registrar 50 resultados de rango, junto con la distancia desde el punto de acceso. Las estadísticas, como la media y la varianza del rango, se deben calcular 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) en comparación con el rango estimado (eje Y) y se puede estimar una línea de regresión del mejor ajuste. La calibración ideal del dispositivo generará una línea de gradiente 1.0, con un desplazamiento de 0.0 m en el eje Y. Las desviaciones de estos valores son aceptables si se encuentran dentro del KPI para el ancho de banda correspondiente. Si los resultados están fuera del KPI, se debe volver a calibrar la función del dispositivo para que los resultados cumplan con la especificación del KPI.