El Tiempo de ida y vuelta (RTT) de Wi-Fi de Android 9 permite que los dispositivos compatibles medir una distancia a otros dispositivos compatibles: si son puntos de acceso (PA) o pares de Wi-Fi Aware (si Wi-Fi Aware) es compatible con el dispositivo). Esta función, compilada según el estándar IEEE 802.11mc y el protocolo IEEE 802.11az (disponible a partir de Android 15) permite que las apps usen el reconocimiento y la precisión de la ubicación mejoradas.
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 el AIDL. En Android 13 y versiones anteriores, la interfaz de la HAL del proveedor se define con el HIDL. En Android 8.0, el uso de HIDL reemplazó la estructura anterior de la capa de abstracción de hardware (HAL) que se usaba para para optimizar las implementaciones especificando los tipos y las llamadas de método que se recopilan 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 posterior.
Puedes consultar la HAL de Wi-Fi heredada para ver cómo se correlaciona con la Interfaces de AIDL y HIDL: hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h.
Implementación
Para implementar Wi-Fi RTT, debes proporcionar el framework y la HAL/firmware soporte:
Marco de trabajo:
- Código del AOSP
- Habilitar Wi-Fi RTT: 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 Wi-Fi AIDL o HIDL. y habilita la marca de función:
En
device.mk, ubicado endevice/<oem>/<device>, modifica el Variable de entornoPRODUCT_COPY_FILESpara incluir compatibilidad con Wi-Fi Función de 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, la dirección MAC que se usa durante las transacciones de Wi-Fi RTT debe ser aleatoria, es decir, no debe coincidir con la dirección MAC nativa de la red Wi-Fi interfaz de usuario. Sin embargo, como excepción, cuando un dispositivo está asociado con un PA, Puede usar la dirección MAC con la que está asociada 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. El CTS detecta Cuando se habilita la función y se incluyen automáticamente las pruebas asociadas. Esta función también se puede probar con Conjunto 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. El CTS detecta Cuando se habilita la función y se incluyen automáticamente las pruebas asociadas. Los El punto de acceso compatible con Wi-Fi RTT (IEEE 802.11mc) debe estar dentro del rango de el dispositivo que está a prueba.
Las pruebas del CTS se pueden activar usando lo siguiente:
atest WifiRttTest
Calibración
Para que Wi-Fi RTT tenga un buen rendimiento, los rangos devueltos en el formato 802.11mc u 802.11az protocolos deben ser precisos dentro de los indicadores clave de rendimiento (KPI) como que se describe en esta sección.
Para el protocolo 11mc, en los anchos de banda indicados (80 MHz, 40 MHz, 20 MHz) y un tamaño de aumento de actividad de 8, se espera que el KPI para una estimación de rango logre la siguiente exactitud en el percentil 90 de error.
- 80 MHz: 2 metros
- 40 MHz: 4 metros
- 20 MHz: 8 metros
Para el protocolo 11az, la configuración de la antena MIMO y el la repetición de campo (LTF) afecta la exactitud. Con un teléfono celular típico (con 2 antenas) y punto de acceso (4 antenas), el sistema tiene un puerto MIMO 2x4 configuración. Para una configuración de este tipo con un factor de repetición LTF de dos y en los anchos de banda indicados (160 MHz, 80 MHz, 40 MHz, 20 MHz), se espera que el KPI de una estimación de rango logre lo siguiente: la exactitud 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, la calibración se necesitan pruebas.
Esto se puede lograr comparando un rango de verdad fundamental con el RTT estimado a distancias crecientes. Para un cumplimiento básico, debes validar tu en un dispositivo calibrado con RTT. La calibración de rango debe probarse en las siguientes condiciones:
- Un laboratorio abierto grande o un pasillo que no tiene mucho metal que pueden generar casos inusualmente altos de rutas múltiples.
- Al menos una ruta de línea de visión (LOS) o una ruta de 25 m de extensión.
- Marcadores con incrementos de 0,5 metros de un extremo de la pista al otro
Un lugar para asegurar un punto de acceso capaz de RTT en un extremo de la pista montado a 20 cm del suelo y un soporte móvil para un teléfono Android (u otro dispositivo móvil Android sometido a prueba) que se pueda mover a lo largo del y alineado con los marcadores de 0.5 m, también a 20 cm de altura hasta el piso.
Se deben registrar 50 resultados de rango en cada marcador, junto con el distancia desde el punto de acceso. Las 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 de la verdad fundamental (eje x) con el rango estimado (eje Y) y la línea de regresión de mejor ajuste estimado. Ideales la calibración del dispositivo generará una línea de gradiente de 1.0, con un desplazamiento de 0.0m activado el eje Y. Se aceptan desviaciones de estos valores si se encuentran dentro del KPI para el ancho de banda correspondiente. Si los resultados están fuera del KPI, se debe recalibrar la función del dispositivo para que los resultados estén dentro del KPI especificación.