Wi-Fi RTT (IEEE 802.11mc, IEEE 802.11az)

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, na sigla em inglês) ou outros pontos Wi-Fi Aware (se o Wi-Fi Aware for compatível com o dispositivo). Esse recurso, criado com base no protocolo 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 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 de camada de abstração de hardware (HAL, na sigla em inglês) 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.0 ou mais recente.

Consulte a HAL do Wi-Fi legada para saber 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 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 em device/<oem>/<device>, modifique a variável de ambiente PRODUCT_COPY_FILES para 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 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 é associado a um AP, ele pode usar o endereço MAC associado a qualquer transação de RTT com esse AP ou com outros APs.

Validação

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. 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 administrador:

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 Wi-Fi RTT (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, o KPI para uma estimativa de intervalo deve atingir a precisão abaixo no percentil 90 de erro.

  • 80 MHz:2 metros
  • 40 MHz:4 metros
  • 20 MHz:8 metros

No protocolo 11az, a configuração de MIMO da antena e a repetição de 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 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), o KPI para uma estimativa de intervalo deve alcançar a seguinte precisão na 90ª percentil 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 empíricas com o intervalo estimado de RTT em distâncias crescentes. Para conformidade básica, valide sua solução em relação a um dispositivo conhecido por ser calibrado para RTT. A calibragem de alcance precisa ser testada nas seguintes condições:

  1. Um laboratório grande e aberto ou um corredor sem muitos objetos de metal que possam resultar em ocorrências excepcionalmente altas de multicaminho.
  2. Pelo menos uma faixa ou um caminho de linha de visão (LOS) com extensão de 25 m.
  3. Marcadores de incrementos de 0,5 metro de um fim da pista ao outro.
  4. 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.

  5. 50 resultados de medição 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 dentro da especificação do KPI.