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 do 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 oferece suporte ao Wi-Fi 7.

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

  • Se a sobreposição for definida como true, presume-se que o dispositivo seja compatível com Wi-Fi 7, independentemente da resposta de 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 de Wi-Fi confere 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 tem suporte ao Wi-Fi 7. A classe WifiTracker do AOSP exibe 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 320 MHz de largura de canal

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 com base em RTT:

APIs

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

Soft AP

O Android oferece suporte ao Wi-Fi 7 em 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 na HAL 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 virtual relatadas.

APIs HAL

A constante WIFI_STANDARD_11BE na interface Generation.aidl AIDL no HAL hostapd, 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ários links (MLO, na sigla em inglês) é o principal recurso da especificação do Wi-Fi 7 (802.11be). O MLO é um recurso obrigatório para dispositivos de vários links (MLD, na sigla em inglês) em execução no Wi-Fi 7, seja de forma simultânea 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 do relatório de vizinho reduzido (RNR, na sigla em inglês) incluído no beacon ou na resposta de sondagem para ler a lista de informações dos 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 de Wi-Fi os resultados da verificação para cada resposta de sensor ou sondagem recebida. Isso significa que o framework de 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 indicadores 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 os IEs RNR recebidos das instâncias de AP nos resultados da 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 multilink (frame de solicitação de sondagem que inclui um elemento de solicitação de sondagem multilink) 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 associar a todos ou alguns dos links com suporte do 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 de 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 de MLO do chip Wi-Fi:

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

Seleção de rede Wi-Fi MLO

Figura 2. Seleção de rede MLO.

A transmissão e o recebimento simultâneos (STR, na sigla em inglês) são um esquema de contenção de mídia 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. O STR é diferente do STA de link único legado (SL) e do STA de banda dupla simultânea (DBDC) legado. As STAs afiliadas a um MLD da STA compartilham um número de sequência de transmissor (SN) comum e um espaço comum para transmissão de dados alocado a links diferentes, se várias transmissões de links tiverem a mesma categoria de acesso (AC).

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 melhor confiabilidade, melhor capacidade e menor latência (em comparação com uma única estação legada de link) operando simultaneamente em STR e eMLSR se compatível com o chip. Na Figura 2, a contagem máxima de links de associação é 3.

As interfaces HAL AIDL a seguir oferecem suporte ao recurso de contagem máxima 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
  • 10 x 15 cm

A seguinte interface de HAL AIDL é compatível com combinações simultâneas de rádio:

Seleção de rede

Durante a seleção de rede (MLO), a lista de candidatos é agrupada por membros com o mesmo endereço MAC 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 realiza a seleção do SSID com base nas informações recebidas no objeto ScanResults, conforme relatadas 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 na 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 do 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 do STA-MLD definido pelo framework de 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 do STA-MLD
  • Octeto 5: por STA = (STA-MLD + ID do link + 1) MOD (256)

O firmware do fornecedor pode alternar 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 estado de economia de energia a ser desativado 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 um link ativo (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 roteia o tráfego de uplink para um (ou mais) links com base na implementação interna dele. O firmware do fornecedor decide quando fazer o balanceamento de carga, a duplicação ou a 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 endereço MAC MLD-STA 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 de 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 é exigido por 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 de 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 da AIDL para negociação de mapeamento de TID para vinculação 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 link incluem detalhes específicos de link de Wi-Fi, como RSSI, vários contadores de pacotes TX e RX e estatísticas de rádio. O framework do 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.

Estatísticas específicas de links são encontradas nas seguintes interfaces AIDL da camada de links:

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

As APIs específicas para links a seguir 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 a seguir 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 links 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 lógica de agregação abaixo 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 de links (remoção do link do AP).

Quando o framework de Wi-Fi processa a remoção de um link, o estado dele é 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 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 ícones

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.