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 Wi-Fi Aware (si el dispositivo admite esa tecnología). 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 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 Wi-Fi RTT. Según la interfaz que se implemente, esto es lo que sucede:
- AIDL:
hardware/interfaces/wifi/aidl - HIDL:
hardware/interfaces/wifi/1.0o una versión posterior
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 o el firmware:
Framework:
- Código del AOSP
- Habilita la 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 el 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 compatibilidad con la función 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, todo lo necesario para esta función se incluye en AOSP.
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 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 de paquetes de RTT de Wi-Fi se ejecutan con lo siguiente:
Pruebas de servicio:
atest com.android.server.wifi.rttPruebas del administrador:
atest android.net.wifi.rttCTS
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 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 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 de 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 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 de LTF de dos y en los anchos de banda enumerados (160 MHz, 80 MHz, 40 MHz y 20 MHz), se espera que el KPI de 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.
Para ello, se puede comparar 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 está calibrado para la RTT. 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 medición de rango en cada marcador, junto con la distancia del 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.