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 de reconocimiento de Wi-Fi (si el dispositivo admite Wi-Fi Aware). Esta función, basada en los protocolos IEEE 802.11mc y IEEE 802.11az (disponibles a partir de Android 15), permite que las apps usen el reconocimiento y la precisión de ubicación mejorados.
Ejemplos y fuente
Para usar esta función, implementa la interfaz de la 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, el HIDL reemplazó la estructura anterior de la capa de abstracción de hardware (HAL) utilizada para optimizar las implementaciones especificando tipos y llamadas de método recopilados en interfaces y paquetes.
Sigue la interfaz Wi-Fi para emplear la función Wi-Fi RTT. Según la interfaz que se implemente, sucederá lo siguiente:
- AIDL:
hardware/interfaces/wifi/aidl - HIDL:
hardware/interfaces/wifi/1.0o versiones posteriores
Puedes consultar el HAL de Wi-Fi heredado para ver cómo se correlaciona con las interfaces de AIDL y HIDL: hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h.
Implementación
Para implementar la RTT de Wi-Fi, debes proporcionar compatibilidad con el framework y el HAL/firmware:
Marco de trabajo:
- Código del AOSP
- Habilitar RTT de Wi-Fi: requiere una marca de función
Compatibilidad con Wi-Fi RTT (IEEE 802.11mc o IEEE 802.11az) con HAL (lo que implica compatibilidad con firmware)
Para implementar esta función, implementa la interfaz de 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 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 se incluye en el AOSP.
Aleatorización de MAC
Para mejorar la privacidad, se debe aleatorizar la dirección MAC que se usa durante las transacciones de Wi-Fi RTT, 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 de RTT con ese AP o con otros AP.
Validación
Existen pruebas del conjunto de pruebas de compatibilidad (CTS) de Android para esta función. CTS detecta cuando la función está habilitada y, luego, incluye automáticamente las pruebas asociadas. Esta función también se puede probar con el Paquete de pruebas de proveedores (VTS).
Pruebas de unidades
Las pruebas del paquete Wi-Fi RTT se ejecutan con lo siguiente:
Pruebas de servicio:
atest com.android.server.wifi.rtt
Pruebas del administrador:
atest android.net.wifi.rtt
CTS
Existen pruebas del conjunto de pruebas de compatibilidad (CTS) de Android para esta función. CTS detecta cuando la función está habilitada y, luego, incluye automáticamente las pruebas asociadas. Un punto de acceso que admita el RTT de Wi-Fi (IEEE 802.11mc) debe estar dentro del alcance del dispositivo en prueba.
Las pruebas de CTS se pueden activar con lo siguiente:
atest WifiRttTest
Calibración
Para que la RTT de Wi-Fi tenga un buen rendimiento, los rangos que se muestran 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 las siguientes bandas de ancho de banda (80 MHz, 40 MHz y 20 MHz) y un tamaño de ráfaga de 8, se espera que el KPI para una estimación de rango logre 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 de 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 (con 2 antenas) y un punto de acceso (4 antenas), el sistema tiene una configuración MIMO de 2×4. Para una configuración de este tipo que usa un factor de repetición LTF de dos y con los anchos de banda enumerados (160 MHz, 80 MHz, 40 MHz, 20 MHz), se espera que el KPI para una estimación de rango logre 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, se necesitan pruebas de calibración.
Esto se puede lograr comparando un rango de verdad fundamental con el rango estimado de RTT a distancias crecientes. Para obtener la conformidad básica, debes validar tu solución en un dispositivo que se sepa que tiene la RTT calibrada. La calibración del rango se debe probar en las siguientes condiciones:
- Un laboratorio grande y abierto, o un pasillo que no tenga muchos objetos de metal, lo que puede generar ocurrencias inusualmente altas de multiruta.
- Al menos una ruta o un tramo de línea de visión (LOS) que se extienda por 25 m.
- Marcadores de incrementos de 0.5 metros de un extremo de la pista al otro
Un lugar para colocar un punto de acceso compatible con RTT en un extremo del riel, montado a 20 cm del suelo, 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 suelo
Se deben registrar 50 resultados de rango en cada marcador, junto con la distancia desde el punto de acceso. Las estadísticas, como la media y la varianza del rango, deben calcularse para cada posición del marcador.
A partir de los resultados del paso 5, se puede dibujar un gráfico de la verdad fundamental (eje x) en comparación con el rango estimado (eje y) y una línea de regresión de mejor ajuste estimada. 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. Se aceptan desviaciones de estos valores si están dentro del KPI del 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 estén dentro de la especificación del KPI.