Wi-Fi 7

Para dispositivos com o Android 13 ou mais recente, o Android oferece suporte ao padrão Wi-Fi 7 (IEEE 802.11be). Esta página descreve os recursos do Android Wi-Fi 7, incluindo a operação de referência e multilink (MLO).

Recursos de referência do Wi-Fi 7

Esta seção descreve os recursos básicos do Wi-Fi 7 incluídos no Android 13 e versões mais recentes.

Suporte a Wi-Fi 7 no dispositivo

O framework do Android inclui a API WifiManager#isWifiStandardSupported(int standard), que os apps podem chamar com o argumento ScanResults.WIFI_STANDARD_11BE para verificar se um dispositivo é compatível com o Wi-Fi 7.

Quando essa API é chamada, o módulo Wi-Fi verifica se a sobreposição de configuração config_wifi11beSupportOverride é usada como uma substituição e faz o seguinte:

  • Se a sobreposição estiver definida como true, o dispositivo será considerado compatível com o Wi-Fi 7, independente da resposta do nl80211. Essa substituição é útil apenas para fabricantes de dispositivos que não têm drivers que retornam suporte ao Wi-Fi 7.
  • Se a sobreposição estiver definida como false (valor padrão), o módulo Wi-Fi vai usar as informações do nl80211. O módulo Wi-Fi solicita as informações do wificond, que chama o comando nl80211 NL80211_CMD_GET_WIPHY. Se o atributo NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY estiver na resposta do driver, o dispositivo será considerado compatível com o Wi-Fi 7.

Suporte a APs Wi-Fi 7 verificados

O framework do Android inclui a API int ScanResult#getWifiStandard(), que os apps podem chamar para verificar se um ponto de acesso (AP) digitalizado oferece suporte ao Wi-Fi 7. Se o AP for compatível com o Wi-Fi 7, a API vai retornar ScanResults.WIFI_STANDARD_11BE. O dispositivo não precisa oferecer suporte ao Wi-Fi 7 para que os apps usem essa API.

Quando essa API é chamada, o módulo Wi-Fi verifica se EHT Capability IE está nos resultados retornados da verificação de conectividade. Se EHT Capability IE estiver nos resultados da verificação, o AP verificado oferece suporte ao Wi-Fi 7. A classe WifiTracker do AOSP mostra essas informações de suporte na interface do usuário quando executada no modo detalhado.

Modo de conexão STA

O framework do Android inclui a API int WifiInfo#getWifiStandard(), que os apps podem chamar para verificar se o modo de conexão da estação (STA) é Wi-Fi 7. O modo de conexão STA é Wi-Fi 7 quando o dispositivo e o AP conectado são compatíveis com Wi-Fi 7. Se o modo de conexão for Wi-Fi 7, a API vai retornar ScanResults.WIFI_STANDARD_11BE.

Quando o getWifiStandard é chamado, o módulo Wi-Fi determina o modo chamando a API HAL ISupplicantStaIface#getConnectionCapabilities(). A implementação dessa API HAL na camada AIDL wpa_supplicant verifica se EHT Capability IE está em AssocReq e AssocRsp durante a configuração da conexão.

Seleção de rede

No Android 13, a seleção de rede usa vários parâmetros para determinar a qual AP se conectar. Um dos parâmetros é a capacidade estimada do AP, que é estimada usando o bloco ThroughputPredictor. O bloco ThroughputPredictor usa os parâmetros PHY do dispositivo e do AP verificado.

No Android 13, ThroughputPredictor usa os seguintes recursos de AP no cálculo:

  • Suporte ao Wi-Fi 7 (802.11be)
  • Suporte a largura de canal de 320 MHz

A inclusão desses recursos na lógica ThroughputPredictor aumenta as chances de selecionar pontos de acesso compatíveis com o Wi-Fi 7 quando o dispositivo pode usar esses recursos.

Alcance baseado em RTT do Wi-Fi

O Android oferece suporte de API para o preâmbulo EHT e a largura de canal de 320 MHz para Wi-Fi RTT. Isso permite o suporte a recursos relacionados ao Wi-Fi 7 no RTT, variando sempre que o chip oferece suporte.

APIs HAL

As APIs HAL a seguir oferecem suporte aos recursos do Wi-Fi 7 para medição de distância baseada em RTT:

APIs

Os apps podem usar as seguintes APIs para o cálculo de distância baseado em RTT do Wi-Fi 7:

Soft AP

O Android oferece suporte ao Wi-Fi 7 no Soft AP e oferece os seguintes recursos.

Iniciar o Soft AP

O Android oferece suporte para iniciar o Soft AP no modo Wi-Fi 7. Isso é governado pela configuração de sobreposição config_wifiSoftapIeee80211beSupported.

O módulo Wi-Fi usa a sobreposição config_wifiSoftapIeee80211beSupported para definir o HwModeParams#enable80211BE booleano na chamada de API IHostApd#addAccessPoint(). Na camada AIDL do hostapd, esse valor é usado para definir os parâmetros hostapd.conf.

APIs HAL

O booleano enable80211BE em HwModeParams no HAL do hostapd oferece suporte à inicialização do soft AP no modo Wi-Fi 7.

Relatar informações sobre o AP virtual

O Android inclui suporte de API para incluir informações de largura de canal de 320 MHz e Wi-Fi 7 nas informações de AP suave relatadas.

APIs HAL

A constante WIFI_STANDARD_11BE na interface AIDL Generation.aidl do hostapd HAL, que é usada no ApInfo informado no callback IHostapdCallback#onApInstanceInfoChanged(), oferece suporte ao envio de informações do Soft AP.

APIs

Os apps podem usar os seguintes métodos (APIs do sistema) em SoftApInfo para informar informações sobre o AP virtual.

Recursos do MLO Wi-Fi 7

A operação de várias ligações (MLO) é o principal recurso da especificação Wi-Fi 7 (802.11be). O MLO é um recurso obrigatório para dispositivos multilink (MLD, na sigla em inglês) executados no Wi-Fi 7, seja de forma concorrente ou não.

Diagrama de MLO

Figura 1. Diagrama de MLO.

Conforme mostrado na Figura 1, o AP-MLD e o STA-MLD têm várias instâncias de AP ou STA em execução em cada link. Cada link tem um endereço MAC de AP ou STA separado. O AP ou STA também tem um endereço MAC MLD para identificar o dispositivo.

A classe android.net.wifi.MloLink representa o link MLO. Essa classe inclui os seguintes parâmetros:

Informações do MLO do AP Wi-Fi 7 digitalizado

Os apps podem receber os parâmetros de MLO de um AP MLD do Wi-Fi 7 quando o módulo do Wi-Fi recebe um objeto ScanResult do AP-MLD. O WifiTracker do AOSP mostra os parâmetros de MLO quando executado no modo detalhado.

O módulo Wi-Fi coleta as informações do MLO da seguinte forma:

  • Analisa o elemento de informação de vários links (IE) incluído na resposta de sondagem ou do beacon para ler o endereço MAC MLD do AP e o ID de link atual.
  • Analisa o IE de relatório de vizinho reduzido (RNR, na sigla em inglês) incluído na resposta de sondagem ou farol para ler a lista de informações de links afiliados.

APIs

Para receber informações de MLO de APs digitalizados, os apps podem usar as seguintes APIs:

Informações do MLO do AP Wi-Fi 7 conectado

Quando um dispositivo se conecta a um AP-MLD do Wi-Fi 7, o framework coleta os parâmetros de MLO da conexão do objeto WifiInfo. O objeto WifiTracker do AOSP mostra essas informações quando executado no modo detalhado.

Quando o dispositivo se conecta ao AP-MLD, o módulo Wi-Fi copia as informações do MLO do objeto ScanResult recebido do AP. Em seguida, o módulo chama a API HAL ISupplicantStaIface#getConnectionMloLinksInfo() para ler os endereços MAC de cada link para AP e STA e atualizar o estado dos links associados.

APIs

Para receber informações de conexão de MLO, os apps podem usar as seguintes APIs:

Verificação de AP-MLD

O software do fornecedor fornece ao framework do Wi-Fi os resultados da verificação de cada resposta de farol ou sonda que ele recebe. Isso significa que o framework Wi-Fi:

  • Pode receber vários objetos ScanResults do mesmo AP-MLD, porque o AP pode ter vários links de beaconing.
  • Talvez receba apenas um conjunto parcial dos resultados da verificação dos links de AP de um AP-MLD porque alguns desses sinais de link podem não ser recebidos pelo firmware.

O software do fornecedor informa apenas os resultados da verificação recebidos por transmissão sem fio e não pode criar (sintetizar artificialmente) resultados da verificação com base nos links anunciados pelo AP-MLD.

O software do fornecedor precisa incluir a variante básica de vários links e as IEs de RNR recebidas das instâncias de AP nos resultados de verificação informados. Se os detalhes do AP afiliado não estiverem nos resultados da verificação, o software do fornecedor poderá enviar solicitações de sondagem de vários links (frame de solicitação de sondagem que inclui um elemento de sondagem de vários links) para incluir o conjunto completo ou parcial de recursos, parâmetros e elementos de operação do AP com o AP-MLD de destino no frame de resposta.

O software do fornecedor pode acionar a sondagem de ML (usando o IE de variante de sondagem de ML no frame de sondagem de solicitação) se necessário.

Associação de rede AP-MLD

Quando um dispositivo se junta a uma rede AP-MLD, o software do fornecedor usa o link de AP selecionado (link associado) para sinalização. O software do fornecedor pode ser associado a todos ou alguns dos links aceitos pelo dispositivo.

Após a associação, o driver informa ISupplicantStaIfaceCallback#onStateChanged() com o BSSID de um link para o AP-MLD. Em seguida, o driver seleciona um link do AP-MLD, desde que os resultados da verificação tenham sido informados ao framework para esse link.

Pontuação da rede

Para dispositivos com o Android 14 ou mais recente, a seleção de rede Wi-Fi do Android oferece suporte ao Wi-Fi 7 MLO. Isso significa que o Android seleciona a melhor rede Wi-Fi para o dispositivo com base no número de links disponíveis para MLO.

Para oferecer suporte ao MLO, o algoritmo de seleção de rede usa os seguintes recursos do chip Wi-Fi:

  • Contagem máxima de links STR
  • Contagem máxima de links de associação
  • Combinações de bandas simultâneas

Seleção de rede MLO Wi-Fi

Figura 2. Seleção de rede MLO.

A transmissão e recepção simultâneas (STR, na sigla em inglês) é um esquema de contenção de meio Wi-Fi para operação de vários links. O isolamento de sinal entre links diferentes é suficiente para que eles possam operar de forma independente e transmitir e receber simultaneamente em links diferentes. A STR é diferente da STA de link único legado (SL, na sigla em inglês) e da STA de banda dupla simultânea (DBDC, na sigla em inglês) legada. As STAs afiliadas a uma MLD de STA compartilham um número de sequência de transmissor (SN, na sigla em inglês) comum e um espaço comum para a transmissão de dados alocada a links diferentes se várias transmissões de links tiverem a mesma categoria de acesso (AC, na sigla em inglês).

O número máximo de links STR usados pode ser diferente do número máximo de rádios aceitos pelo chip. No exemplo da Figura 2, a contagem máxima de links STR é 2.

As interfaces HAL do AIDL a seguir oferecem suporte ao número máximo de links STR e ao número máximo de recursos de contagem de links de associação:

Vários links podem operar em um único rádio usando o esquema de contenção, o rádio único de vários links aprimorado (eMLSR, na sigla em inglês). Um dispositivo com vários links usa eMLSR em um conjunto de links se puder receber determinados frames de controle básicos e realizar a avaliação do canal claro (CCA, na sigla em inglês) simultaneamente no conjunto de links. No entanto, o MLD transmite ou recebe dados em apenas um link (o link escolhido dinamicamente em cada período de oportunidade de transmissão (TXOP)) por vez.

Uma estação MLD pode maximizar o número de links de associação para melhorar a confiabilidade, o throughput e a latência (em comparação com uma estação legada com um único link) ao operar simultaneamente no STR e no eMLSR, se o chip oferecer suporte a eles. Na Figura 2, a contagem máxima de links de associação é 3.

As interfaces HAL AIDL a seguir oferecem suporte à capacidade máxima de contagem de links de associação:

Combinações de bandas simultâneas

O framework consulta o chip para receber as combinações de rádio permitidas (pela interface AIDL IWifiChip.aidl) que podem operar simultaneamente. Com base nessas informações, o framework extrai possíveis combinações simultâneas de bandas. Confira a seguir um exemplo de lista de combinações de faixas simultâneas (GHz):

  • 2.4
  • 5
  • 6
  • 2,4 x 5
  • 2,4 x 6
  • 5 x 6

A interface AIDL HAL a seguir oferece suporte a combinações de rádio simultâneas:

Seleção de rede

Durante a seleção de rede (MLO, na sigla em inglês), a lista de candidatos é agrupada por membros com o mesmo endereço MAC do MLD. A pontuação máxima de throughput de vários links prevista é calculada para cada grupo com base na contagem máxima de links STR e nas combinações de banda simultâneas aceitas pelo chip. Se o candidato tiver capacidade de link múltiplo e o chip oferecer suporte ao STR, a pontuação de throughput prevista será substituída pela pontuação de throughput prevista de link múltiplo. Isso aumenta os candidatos de MLO durante a seleção de rede.

Ao ingressar em uma rede AP-MLD, o framework executa a seleção de SSID com base nas informações recebidas no objeto ScanResults conforme informado pelo software do fornecedor. Após a seleção do SSID pelo framework, o software do fornecedor é responsável por selecionar o BSSID do melhor AP (ou link de AP) a ser usado para associação.

Processamento de endereços MAC de STA do dispositivo

Esta seção descreve como os endereços MAC STA do dispositivo (endereços MAC MDL e endereços MAC STA por link) são processados.

Endereço MAC do MLD

O framework Wi-Fi gerencia o endereço MAC do MLD do dispositivo. O endereço MAC MLD é processado da mesma forma que um dispositivo não MLD processa o próprio endereço MAC. O endereço MAC pode ser aleatório ou provisionado pelo hardware com base na escolha do usuário. O endereço MAC do MLD é definido pelo framework usando a API HAL IWifiStaIface#setMacAddress().

O software do fornecedor gerencia os endereços MAC STA de instância (para cada link). Quando um dispositivo se associa a um AP, o software do fornecedor atribui um endereço MAC de instância para cada link associado.

O software do fornecedor atribui endereços MAC por link com base no algoritmo. O algoritmo precisa ser repetível e ser uma função dos seguintes elementos:

  • Endereço MAC STA-MLD definido pelo framework do Wi-Fi.
  • ID do link (recebido do AP)

Isso significa que, se o framework reutilizar o mesmo endereço MAC do MLD, o fornecedor precisa reutilizar os mesmos endereços MAC associados por instância e vice-versa. Isso garante que, quando o endereço STA-MLD gerado pelo framework for persistente para um SSID, os endereços MAC por STA também serão persistentes.

Confira a seguir um exemplo de algoritmo para atribuição de endereço MAC de STA por link. Os fornecedores podem implementar qualquer algoritmo que atenda aos critérios:

  • Octeto 0: verifique se o bit administrado localmente está definido
  • Octeto 1 a 4: igual ao endereço MAC STA-MLD
  • Octeto 5: por STA = (STA-MLD + ID do link + 1) MOD (256)

O firmware do fornecedor pode realizar a troca de links e gerenciar o estado de economia de energia dos links para ativação ou desativação sem entrada do framework Wi-Fi.

O framework Wi-Fi não espera uma notificação quando o estado do link é alterado.

Gerenciamento do estado de economia de energia

O estado de economia de energia é ativado por padrão no framework do Wi-Fi. No estado de economia de energia, o firmware do fornecedor gerencia o estado de economia de energia de links individuais com base nos padrões de tráfego e nas decisões de ativação ou desativação de links.

No entanto, o framework Wi-Fi pode forçar o desligamento do estado de economia de energia chamando a API HAL ISupplicantStaIface::setPowerSave(false). Se o estado de economia de energia for desativado pelo framework, o firmware do fornecedor precisará manter pelo menos uma ligação ativa (economia de energia desativada). Nesse estado, a implementação do firmware decide qual link é definido.

Caminho de dados

Esta seção descreve a implementação do firmware do fornecedor para processar o tráfego de uplink e download.

O firmware encaminha o tráfego de uplink para um (ou mais) links com base na implementação interna. O firmware do fornecedor decide quando fazer o balanceamento de carga, duplicação ou agregação de tráfego com base nos padrões de tráfego. Recomendamos que o firmware duplique o tráfego para vários links nos seguintes casos:

  • Quando o modo de baixa latência é definido pela API HAL IWifiChip#setLatencyMode().
  • Quando há tráfego com prioridade do usuário 6 e 7.

O firmware precisa substituir o endereço MAC (destino) por STA do cabeçalho MAC com o MLD-STA MAC e o endereço MAC (origem) por AP do cabeçalho MAC com o endereço MAC MLD-AP. O firmware precisa realizar essa substituição de endereço MAC antes de passar pelo filtro APF, porque os comandos de filtro APF têm filtros baseados em endereços MAC MLD. Há um único filtro APF para todos os links de um AP-MLD.

Simultaneidade

Cenários de simultaneidade, em que um rádio é usado para uma nova interface, precisam ter prioridade sobre a atribuição de vários rádios para links da mesma interface. Os cenários de simultaneidade também precisam ter prioridade sobre a MLO, não importa qual veio primeiro. O uso de vários links para uma única interface é oportunista, ou seja, vários links são usados apenas quando:

  • O MLO é necessário com base na decisão do firmware para balanceamento de carga, agregação ou duplicação.
  • O MLO está disponível, o que significa que um rádio não é necessário para outra interface.

Para dispositivos com o Android 14 ou mais recente, quando o AP Wi-Fi 7 anuncia uma desativação temporária de um dos links por um elemento de mapeamento de TID para link transmitido em frames de beacon, resposta de sondagem e associação, a estação Wi-Fi 7 continua a conexão com o AP usando os links restantes que estão configurados, sem realizar outra associação.

Para dispositivos com o Android 13 ou versões anteriores, o framework Wi-Fi não oferece suporte ao recebimento de notificações quando o estado do link é alterado devido ao mapeamento de TID para link, mesmo que o link associado não esteja vinculado a um TID.

O solicitante do Wi-Fi notifica o framework do Wi-Fi sobre as mudanças de mapeamento de TID para link através das seguintes interfaces AIDL:

Os apps podem receber informações sobre mudanças no mapeamento de TID para link usando as seguintes APIs:

Para dispositivos com o Android 14 ou mais recente, as seguintes APIs estão disponíveis para receber os recursos de negociação de mapa TID para link para a estação e o AP.

Capacidade do chip

As interfaces a seguir oferecem suporte ao recurso do chip para negociação de mapeamento de TID para link.

HAL AIDL

A interface AIDL para negociação de mapeamento de TID para link está em FeatureSetMask em hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl. O recurso T2LM_NEGOTIATION = 1 << 8 indica que o chip oferece suporte ao mapeamento de TID para link. APIs

Capacidade do AP

As interfaces a seguir oferecem suporte ao recurso de AP para a negociação de mapeamento de TID para link.

HAL AIDL

O framework consulta o capability do AP do solicitante com o capability de conexão atual.

APIs

As estatísticas da camada de vinculação incluem detalhes específicos do link Wi-Fi, como RSSI, vários contadores de pacotes de TX e RX e estatísticas de rádio. O framework Wi-Fi pesquisa periodicamente as estatísticas da camada de link e o RSSI para selecionar a melhor rede ou avaliar a qualidade da rede conectada. Para dispositivos com o Android 14 ou versões mais recentes, as estatísticas da camada de link incluem suporte a vários links. Para oferecer suporte ao Wi-Fi 7, o Android oferece suporte a MLO nas estatísticas da camada de link e na pesquisa de sinal.

As estatísticas específicas de link são encontradas nas seguintes interfaces da AIDL da camada de link:

A API do sistema android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() detecta todas as estatísticas da camada de link. O framework invoca periodicamente essa API para atualizar as estatísticas de usabilidade do Wi-Fi.

As APIs específicas para links abaixo estão disponíveis em android.net.wifi.WifiUsabilityStatsEntry.

int getRssi(int linkId)
int getLinkState(int linkId)
int getRadioId(int linkId)
int getTxLinkSpeedMbps(int linkId)
long getTotalTxSuccess(int linkId)
long getTotalTxRetries(int linkId)
long getTotalTxBad(int linkId)
long getTotalRxSuccess(int linkId)
long getTotalBeaconRx(int linkId)
int getRxLinkSpeedMbps(int linkId)
int getTimeSliceDutyCycleInPercent(int linkId)
ContentionTimeStats getContentionTimeStats(int linkId, @WmeAccessCategory int ac)
List<RateStats> getRateStats(int linkId)

Para consultar os IDs de link disponíveis, os apps podem chamar o método android.net.wifi.WifiUsabilityStatsEntry#getLinkIds().

As APIs em android.net.wifi.WifiUsabilityStatsEntry para link único (não MLO) retornam as estatísticas agregadas para conexões de MLO. Confira os critérios de agregação:

  • As estatísticas de pacotes agregadas a seguir usam a soma das estatísticas por link:

    public long getTotalTxSuccess()
public long getTotalTxRetries()
public long getTotalTxBad()
public long getTotalRxSuccess()
public int getRxLinkSpeedMbps()

  • As estatísticas a seguir usam os dados do link com o RSSI mais alto:

    public int getRssi()
public int getLinkSpeedMbps()
public long getTotalBeaconRx()
public int getTimeSliceDutyCycleInPercent()
public ContentionTimeStats getContentionTimeStats(@WmeAccessCategory int ac)
public List<RateStats> getRateStats()

Para dispositivos com o Android 13, as estatísticas da camada de link não consideram o uso de vários links para uma única interface. Para oferecer suporte ao MLO, o software do fornecedor precisa aplicar a seguinte lógica de agregação ao informar LinkLayerStats pela API HAL IWifi# getLinkLayerStats_1_6(). O melhor link é o com o RSSI mais alto.

  • StaLinkLayerStats.iface.beaconRx: informa a contagem de beacons do melhor link usado para a interface.
  • StaLinkLayerStats.iface.avgRssiMgmt: informe avgRssiMgmt para o melhor link usado para a interface.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk): informa as estatísticas de pacotes agregadas (total) nos links da interface.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk): informa as estatísticas de tempo de disputa do melhor link usado na interface (estatísticas de tempo de disputa mais baixas).

Quando um dos links do ponto de acesso Wi-Fi 7 é reaproveitado, o AP pode anunciar a remoção do link pela reconfiguração do link MLO. As estações podem manter a conectividade perfeita com o AP sem uma nova associação nos links restantes.

A interface AIDL onMloLinksInfoChanged, localizada no solicitante do Wi-Fi em ISupplicantStaIfaceCallback.aidl, oferece suporte à reconfiguração do link (remoção do link do AP).

Quando o framework do Wi-Fi processa a remoção de um link, o estado do link é definido como MLO_LINK_STATE_UNASSOCIATED. Em seguida, o framework aciona ConnectivityManager.NetworkCallback#onCapabilitiesChanged() para uma mudança de estado de link.

O método WifiInfo#getAffiliatedMloLinks retorna os links de MLO afiliados. O método MloLink#getState retorna o estado do link. Se o link for removido, o estado do link retornado será MLO_LINK_STATE_UNASSOCIATED.

Estratégia de MLO de chip

O MLO permite que os dispositivos enviem e recebam dados em vários links Wi-Fi ao mesmo tempo, o que pode melhorar o desempenho de apps com requisitos específicos, como baixa latência, alta largura de banda e baixo consumo de energia. Os fornecedores de chips podem desenvolver algoritmos sobre como usar os links disponíveis.

Os apps privilegiados podem modificar esses algoritmos usando o método setMloMode no Wifimanager e definir os seguintes modos:

  • MLO_MODE_DEFAULT = 0
  • MLO_MODE_LOW_LATENCY = 1
  • MLO_MODE_HIGH_THROUGHPUT = 2
  • MLO_MODE_LOW_POWER = 3

O framework usa setMloMode na interface AIDL IWifiChip para definir o modo MLO.