O recurso tempo de retorno do Wi-Fi (RTT) do Android 9 permite que dispositivos compatíveis meçam a distância até outros dispositivos compatíveis, sejam eles pontos de acesso (APs) ou outros pontos Wi-Fi Aware (se o Wi-Fi Aware for compatível com o dispositivo). Esse recurso, criado com base nos protocolos IEEE 802.11mc e IEEE 802.11az (disponível no Android 15), permite que os apps usem a precisão e o reconhecimento de local aprimorados.
Exemplos e origem
Para usar esse recurso, implemente a interface HAL do fornecedor. No Android 14 e versões mais recentes, a interface HAL do fornecedor é definida usando AIDL. No Android 13 e em versões anteriores, a interface HAL do fornecedor é definida usando HIDL. No Android 8.0, o HIDL substituiu a estrutura anterior da camada de abstração de hardware (HAL) usada para simplificar as implementações especificando tipos e chamadas de método coletados em interfaces e pacotes.
Siga a interface Wi-Fi para usar o recurso Wi-Fi RTT. Dependendo da interface implementada, isso é:
- AIDL:
hardware/interfaces/wifi/aidl - HIDL:
hardware/interfaces/wifi/1.0ou mais recente.
Consulte o HAL Wi-Fi legado para ver como ele se correlaciona com as interfaces AIDL e HIDL: hardware/libhardware_legacy/+/android16-release/include/hardware_legacy/rtt.h.
Implementação
Para implementar o Wi-Fi RTT, é necessário oferecer suporte à estrutura e à HAL/firmware:
Framework:
- Código do AOSP
- Ativar o RTT de Wi-Fi: exige uma flag de recurso
Suporte a HAL do Wi-Fi RTT (IEEE 802.11mc ou IEEE 802.11az), o que implica suporte a firmware.
Para implementar esse recurso, implemente a interface AIDL ou HIDL do Wi-Fi e ative a flag de recurso:
Em
device.mk, localizado emdevice/<oem>/<device>, modifique a variável de ambientePRODUCT_COPY_FILESpara incluir suporte ao recurso RTT do 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
Caso contrário, tudo o que é necessário para esse recurso está incluído no AOSP.
Ordem aleatória de MAC
Para aumentar a privacidade, o endereço MAC usado durante as transações de RTT do Wi-Fi precisa ser aleatório, ou seja, não pode corresponder ao endereço MAC nativo da interface Wi-Fi. No entanto, como exceção, quando um dispositivo está associado a um PA, ele pode usar o endereço MAC com que está associado para qualquer transação de RTT com esse PA ou com outros PAs.
Validação
Existem testes do Teste de compatibilidade do Android (CTS) para esse recurso. O CTS detecta quando o recurso está ativado e inclui automaticamente os testes associados. Esse recurso também pode ser testado usando o Vendor Test Suite (VTS).
Testes de unidade
Os testes do pacote Wi-Fi RTT são executados usando:
Testes de serviço:
atest com.android.server.wifi.rttTestes de gerente:
atest android.net.wifi.rttCTS
Existem testes do Teste de compatibilidade do Android (CTS) para esse recurso. O CTS detecta quando o recurso está ativado e inclui automaticamente os testes associados. Um ponto de acesso compatível com Wi-Fi RTT (IEEE 802.11mc) precisa estar dentro do alcance do dispositivo em teste.
Os testes do CTS podem ser acionados usando:
atest WifiRttTestCalibragem
Para que o Wi-Fi RTT funcione bem, os intervalos retornados nos protocolos 802.11mc ou 802.11az precisam ser precisos dentro dos indicadores principais de desempenho (KPIs) descritos nesta seção.
Para o protocolo 11mc, nas larguras de banda listadas (80 MHz, 40 MHz, 20 MHz) e com um tamanho de burst de 8, espera-se que o KPI para uma estimativa de intervalo alcance a seguinte precisão no percentil 90 de erro.
- 80 MHz:2 metros
- 40 MHz:4 metros
- 20 MHz:8 metros
Para o protocolo 11az, a configuração MIMO da antena e a repetição do campo de treinamento longo (LTF, na sigla em inglês) afetam a precisão. Com um smartphone típico (usando duas antenas) e um ponto de acesso (quatro antenas), o sistema tem uma configuração MIMO 2x4. Para uma configuração desse tipo usando um fator de repetição de LTF de dois e nas larguras de banda listadas (160 MHz, 80 MHz, 40 MHz, 20 MHz), espera-se que o KPI para uma estimativa de intervalo alcance a seguinte precisão no 90º percentil de erro.
- 160 MHz:0,5 metros
- 80 MHz:1 metro
- 40 MHz:2 metros
- 20 MHz:4 metros
Para garantir que a implementação do recurso esteja funcionando corretamente, é necessário fazer testes de calibragem.
Isso pode ser feito comparando um intervalo de informação empírica com o intervalo estimado de RTT em distâncias cada vez maiores. Para conformidade básica, valide sua solução em relação a um dispositivo conhecido por ser calibrado com RTT. A calibragem de intervalo precisa ser testada nas seguintes condições:
- Um grande laboratório aberto ou um corredor sem muitos objetos de metal que possam resultar em ocorrências incomumente altas de multipath.
- Pelo menos uma trajetória ou caminho de linha de visada (LOS) com extensão de 25 m.
- Marcadores de incrementos de 0,5 metro de uma extremidade da pista à outra.
Um lugar para fixar um ponto de acesso compatível com RTT em uma extremidade do trilho, montado a 20 cm do chão, e um suporte móvel para um smartphone Android (ou outro dispositivo móvel Android em teste) que pode ser movido ao longo do trilho e alinhado com os marcadores de 0,5 m, também a 20 cm do chão.
50 resultados de alcance devem ser registrados em cada marcador, junto com a distância do ponto de acesso. As estatísticas, como média e variância do intervalo, precisam ser calculadas para cada posição do marcador.
Com base nos resultados da etapa 5, é possível criar um gráfico para a verdade fundamental (eixo x) em relação ao intervalo estimado (eixo y) e uma linha de regressão de melhor ajuste estimada. A calibragem ideal do dispositivo resulta em uma linha de gradiente 1,0, com deslocamento de 0,0 m no eixo y. Desvios desses valores são aceitáveis se estiverem dentro do KPI da largura de banda correspondente. Se os resultados estiverem fora do KPI, o recurso do dispositivo precisará ser recalibrado para que os resultados fiquem dentro da especificação do KPI.