O tempo de retorno do Wi-Fi (RTT) no Android 9 permite que os 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 o reconhecimento e a precisão 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 da HAL do fornecedor é definida usando a AIDL. No Android 13 e versões anteriores, a interface da HAL do fornecedor é definida usando a HIDL. No Android 8.0, o HIDL substituiu a estrutura anterior da HAL, que era usada para simplificar as implementações, especificando tipos e chamadas de método coletados em interfaces e pacotes.
Siga a interface do Wi-Fi para usar o recurso de RTT do Wi-Fi. Dependendo da interface implementada, isso é:
- AIDL:
hardware/interfaces/wifi/aidl - HIDL:
hardware/interfaces/wifi/1.0ou mais recente.
Você pode consultar a HAL de Wi-Fi legada para ver como ela se correlaciona com as interfaces AIDL e HIDL: hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h.
Implementação
Para implementar o RTT do Wi-Fi, é necessário fornecer suporte a framework e HAL/firmware:
Framework:
- Código do AOSP
- Ativar o RTT do Wi-Fi: requer uma flag de recurso
Suporte à HAL para 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 for necessário para esse recurso será incluído no AOSP.
Ordem aleatória de MAC
Para melhorar 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 é associado a um AP, ele pode usar o endereço MAC associado a ele para qualquer transação de RTT com esse AP ou com outros APs.
Validação
Existem testes do conjunto de teste de compatibilidade (CTS) do Android 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 pacote de teste de fornecedor (VTS).
Testes de unidade
Os testes de pacotes de RTT do Wi-Fi são executados usando:
Testes de serviço:
atest com.android.server.wifi.rtt
Testes do gerenciador:
atest android.net.wifi.rtt
CTS
Os testes do conjunto de teste de compatibilidade do Android (CTS) existem para esse recurso. O CTS detecta quando o recurso está ativado e inclui automaticamente os testes associados. Um ponto de acesso compatível com RTT de Wi-Fi (IEEE 802.11mc) precisa estar dentro do alcance do dispositivo em teste.
Os testes CTS podem ser acionados usando:
atest WifiRttTest
Calibração
Para que o RTT do Wi-Fi tenha um bom desempenho, os intervalos retornados nos protocolos 802.11mc ou 802.11az precisam ser precisos dentro dos principais indicadores de desempenho (KPIs), conforme descrito nesta seção.
Para o protocolo 11mc, nas larguras de banda listadas (80 MHz, 40 MHz, 20 MHz) e um tamanho de explosão de 8, espera-se que o KPI para uma estimativa de intervalo alcance a precisão abaixo 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) 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 que usa um fator de repetição de dois do LTF e nas larguras de banda listadas (160 MHz, 80 MHz, 40 MHz, 20 MHz), espera-se que o KPI para uma estimativa de intervalo atinja a seguinte precisão no percentil 90 de erro.
- 160 MHz:0,5 metro
- 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 calibração.
Isso pode ser feito comparando um intervalo de informações reais com o intervalo estimado de RTT em distâncias crescentes. Para conformidade básica, valide sua solução em um dispositivo conhecido por ser calibrado de RTT. A calibragem de alcance precisa ser testada nas seguintes condições:
- Um grande laboratório aberto ou um corredor que não tenha muitos objetos metálicos que podem resultar em ocorrências excepcionalmente altas de vários caminhos.
- Pelo menos uma faixa ou um caminho de linha de visão (LOS, na sigla em inglês) com extensão de 25 m.
- Marcadores de incrementos de 0,5 metro de um fim da pista ao outro.
Um local para fixar um ponto de acesso compatível com RTT em uma extremidade da faixa a 20 cm do chão e uma montagem móvel para um smartphone Android (ou outro dispositivo móvel Android em teste) que possa ser movido ao longo da faixa e alinhado com os marcadores de 0,5 m, também a 20 cm do chão.
50 resultados de alcance precisam ser registrados em cada marcador, junto com a distância do ponto de acesso. Estatísticas, como a média e a variação 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 informação empírica (eixo x) em relação ao intervalo estimado (eixo y) e uma linha de regressão de melhor ajuste estimada. A calibração ideal do dispositivo resultará 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 trazer os resultados para a especificação do KPI.