Google is committed to advancing racial equity for Black communities. See how.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

RTT Wi-Fi (IEEE 802.11mc)

La función de tiempo de ida y vuelta de Wi-Fi (RTT) en Android 9 permite que los dispositivos compatibles midan una distancia a otros dispositivos compatibles: ya sean puntos de acceso (AP) o pares de Wi-Fi Aware (si Wi-Fi Aware es compatible con el dispositivo). Esta función, 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 el lenguaje de diseño de interfaz de hardware Wi-Fi (HIDL) proporcionado en el proyecto de código abierto de Android (AOSP). En Android 8.0, HIDL reemplaza la estructura de Capa de abstracción de hardware (HAL) anterior que se usaba para simplificar las implementaciones al especificar tipos y llamadas a métodos recopilados en interfaces y paquetes.

Siga el HIDL de Wi-Fi para emplear la función RTT de Wi-Fi: hardware/interfaces/wifi/1.0 o posterior.

Puede consultar el HAL de Wi-Fi heredado para ver cómo se correlaciona con la nueva interfaz HIDL: hardware / libhardware_legacy / + / master / include / hardware_legacy / rtt.h.

Implementación

Para implementar Wi-Fi RTT, debe proporcionar compatibilidad con el marco y HAL / firmware:

  • Marco de referencia:

    • Código AOSP
    • Habilitar Wi-Fi RTT: requiere una marca de función
  • Compatibilidad con Wi-Fi RTT (IEEE 802.11mc) HAL (que implica compatibilidad con firmware)

Para implementar esta función, implemente Wi-Fi 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 soporte para 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 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 de Android Compatibility Test Suite (CTS) para esta función. CTS detecta cuando la función está habilitada e incluye automáticamente las pruebas asociadas. Esta función también se puede probar utilizando Vendor Test Suite (VTS) y act / sl4a , un conjunto de pruebas que realiza pruebas de integración exhaustivas.

Pruebas unitarias

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

Pruebas de servicio:

% ./frameworks/opt/net/wifi/tests/wifitests/runtests.sh -e package
com.android.server.wifi.rtt

Pruebas de administrador:

% ./frameworks/base/wifi/tests/runtests.sh -e package android.net.wifi.rtt

Pruebas de integración (ACTS)

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

CTS

Existen pruebas de Android Compatibility Test Suite (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 mediante:

% 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 de 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:

  • 80 MHz: 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 de verdad del 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 de rango debe probarse en las siguientes condiciones:

  1. Un gran laboratorio abierto o un corredor que no tiene muchos objetos metálicos que pueden resultar en ocurrencias inusualmente altas de múltiples rutas.
  2. Al menos una pista / camino de línea de visión (LOS) que se extiende por 25 m.
  3. Marcadores de incrementos de 0,5 metros de un extremo de la pista al otro.
  4. Un lugar para asegurar un punto de acceso con capacidad RTT en un extremo del riel montado a 20 cm sobre el piso 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 del riel y alinear con el Marcadores de 0,5 m, también a 20 cm del suelo. Nota: esta tarea repetitiva puede realizarla un pequeño robot, pero un operador humano también está bien.
  5. Se deben registrar 50 resultados de distancia en cada marcador, junto con la distancia desde el punto de acceso. Las estadísticas, como la media del rango y la varianza, deben calcularse para cada posición de marcador.

A partir de los resultados del paso 5, se puede dibujar un gráfico para la verdad del terreno (eje x) contra el 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 1.0, con una compensación 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 del KPI.