Wi-Fi 7

Em dispositivos com 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 Wi-Fi 7 do Android, incluindo operação básica e de vários links (MLO, na sigla em inglês).

Recursos básicos 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 em dispositivos

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 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 for definida como false (valor padrão), o módulo Wi-Fi 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 Wi-Fi 7.

Suporte a Wi-Fi 7 para APs verificados

O framework do Android inclui a API int ScanResult#getWifiStandard(), que os apps podem chamar para verificar se um ponto de acesso (PA) digitalizado é compatível com Wi-Fi 7. Se o PA for compatível com Wi-Fi 7, a API vai retornar ScanResults.WIFI_STANDARD_11BE. Não é necessário que o dispositivo seja compatível com 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 será compatível com Wi-Fi 7. A classe WifiTracker do AOSP mostra essas informações de suporte na interface do usuário ao executar 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 atual (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 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, o ThroughputPredictor usa os seguintes recursos de AP no cálculo:

  • Compatibilidade com Wi-Fi 7 (802.11be)
  • Suporte à largura de banda de 320 MHz

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

Alcance baseado em RTT do Wi-Fi

O Android oferece suporte à API para o preâmbulo EHT e largura de banda de canal de 320 MHz para o Wi-Fi RTT. Isso permite o suporte a recursos relacionados ao Wi-Fi 7 no intervalo de RTT sempre que o chip for compatível.

APIs HAL

As seguintes APIs HAL oferecem suporte aos recursos do Wi-Fi 7 para alcance baseado em RTT:

APIs

Os apps podem usar as seguintes APIs para alcance baseado em RTT do Wi-Fi 7:

Soft AP

O Android é compatível com Wi-Fi 7 em Soft AP e oferece os seguintes recursos.

Iniciar AP suave

O Android oferece suporte para iniciar um ponto de acesso de software no modo Wi-Fi 7. Isso é controlado pela configuração de sobreposição config_wifiSoftapIeee80211beSupported.

O módulo Wi-Fi usa a sobreposição config_wifiSoftapIeee80211beSupported para definir o booleano HwModeParams#enable80211BE 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 do hostapd oferece suporte para iniciar o AP suave no modo Wi-Fi 7.

Relatar informações de ponto de acesso de software

O Android inclui suporte à API para incluir informações sobre Wi-Fi 7 e largura de banda de canal de 320 MHz nas informações de ponto de acesso (AP) de software informadas.

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 a informações de ponto de acesso (AP) de software.

APIs

Os apps podem usar os seguintes métodos (APIs do sistema) em SoftApInfo para informar dados de AP suave.

Recursos de Wi-Fi 7 MLO

A operação multilinck (MLO) é o principal recurso da especificação Wi-Fi 7 (802.11be). O MLO é um recurso obrigatório para dispositivos de várias conexões (MLD) executados em Wi-Fi 7, simultânea ou não simultaneamente.

Diagrama de MLO

Figura 1. Diagrama de MLO.

Como 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 do MLO. Essa classe inclui os seguintes parâmetros:

Informações de MLO do AP Wi-Fi 7 digitalizadas

Os apps podem receber os parâmetros de MLO para um AP MLD Wi-Fi 7 quando o módulo 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 de MLO fazendo o seguinte:

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

APIs

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

Informações sobre MLO de AP Wi-Fi 7 conectado

Quando um dispositivo se conecta a um AP-MLD Wi-Fi 7, o framework coleta os parâmetros MLO da conexão do objeto WifiInfo. O objeto AOSP WifiTracker 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 de 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 do MLO, os apps podem usar as seguintes APIs:

Verificação de AP-MLD

O software do fornecedor fornece ao framework Wi-Fi os resultados da verificação de cada beacon ou resposta de sondagem recebida. Isso significa que a estrutura Wi-Fi:

  • Pode receber vários objetos ScanResults do mesmo AP-MLD (porque o AP pode ter vários links de beacon).
  • Talvez você 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 com base em links anunciados pelo AP-MLD.

O software do fornecedor precisa incluir as IEs de variante básica com vários links e RNR recebidas das instâncias de PA nos resultados de verificação informados. Se os detalhes do PA afiliado estiverem faltando 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 vários links de solicitação de sondagem) para incluir o conjunto completo ou parcial de recursos, parâmetros e elementos de operação do PA com o AP-MLD segmentado no frame de resposta.

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

Associação de rede AP-MLD

Quando um dispositivo entra em uma rede AP-MLD, o software do fornecedor usa o link de AP selecionado (link associado) para sinalização. O software do fornecedor pode se associar a todos ou a alguns dos links compatíveis com o 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 Android 14 ou mais recente, a seleção de rede Wi-Fi do Android é compatível com MLO Wi-Fi 7. 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:

  • Número máximo de links de STR
  • Número máximo de links de associação
  • Combinações de bandas simultâneas

Seleção de rede Wi-Fi MLO

Figura 2. Seleção de rede de MLO.

A transmissão e recepção simultâneas (STR, na sigla em inglês) são um esquema de disputa de mídia Wi-Fi para operação de vários links. O isolamento de sinal entre diferentes links é suficiente para que eles operem de forma independente e sejam capazes de transmitir e receber simultaneamente em links diferentes. O STR é diferente do STA de link único (SL) e do STA de banda dupla e dupla simultânea (DBDC) legados. Os STAs afiliados a um STA MLD compartilham um número de série (SN) de transmissor comum e um espaço comum para transmissão de dados alocado a diferentes links 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 compatíveis com o chip. No exemplo da Figura 2, a contagem máxima de links STR é 2.

As seguintes interfaces AIDL HAL 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 disputa, Enhanced Multi-Link Single Radio (eMLSR). Um dispositivo multilinck usa eMLSR em um conjunto de links se puder receber determinados frames de controle básicos e realizar uma avaliação de canal livre (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, maior taxa de transferência e menor latência (em comparação com uma estação legada de link único) 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 seguintes interfaces AIDL HAL são compatíveis com a 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, a estrutura deriva possíveis combinações simultâneas de banda. Confira a seguir um exemplo de lista de combinações de bandas simultâneas (GHz):

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

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

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 prevista de capacidade de processamento de vários links é calculada para cada grupo com base na contagem máxima de links STR e nas combinações simultâneas de banda compatíveis com o chip. Se o candidato for compatível com vários links e o chip aceitar STR, a pontuação de taxa de transferência prevista será substituída pela pontuação de taxa de transferência prevista de vários links. Isso aumenta a capacidade dos candidatos a MLO durante a seleção de rede.

Ao se conectar a uma rede AP-MLD, a estrutura realiza 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 pela estrutura, o software do fornecedor é responsável por selecionar o BSSID para o melhor AP (ou link de AP) a ser usado para associação.

Processamento de endereço MAC STA do dispositivo

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

Endereço MAC MLD

O framework Wi-Fi gerencia o endereço MAC 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 por 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 da 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 a cada link associado.

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

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

Isso significa que, se a estrutura 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 é persistente para um SSID, os endereços MAC por STA também são persistentes.

Confira a seguir um exemplo de algoritmo para atribuição de endereço MAC 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: Per-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 da estrutura 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 Wi-Fi. No estado de economia de energia, o firmware do fornecedor gerencia o estado de economia de energia de links individuais com base em padrões de tráfego e decisões de ativação ou desativação de links.

No entanto, o framework Wi-Fi pode forçar a desativação 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 um link ativo (economia de energia desativada). Nesse estado, a implementação do firmware decide qual link será definido.

Caminho de dados

Isso 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, a duplicação ou a agregação de tráfego com base nos padrões de tráfego. Recomendamos o tráfego duplicado de firmware 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 (de destino) por STA do cabeçalho MAC pelo MAC MLD-STA e o endereço MAC (de origem) por AP do cabeçalho MAC pelo 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 do 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

Os cenários de simultaneidade, em que um rádio é usado para uma nova interface, precisam ter prioridade em relação à dedicação de vários rádios para links da mesma interface. Os cenários de simultaneidade também precisam ter prioridade sobre o MLO, não importa qual tenha sido criado primeiro. Usar vários links para uma única interface é oportunista, ou seja, vários links são usados somente quando:

  • O MLO é obrigatório com base na decisão de firmware para balanceamento de carga, agregação ou duplicação.
  • O MLO está disponível, ou seja, um rádio não é exigido por outra interface.

Para dispositivos com 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 beacons, respostas de sondagem e frames de resposta de associação, a estação Wi-Fi 7 continua a conexão com o AP usando os links restantes configurados, sem realizar outra associação.

Em dispositivos com Android 13 ou versões anteriores, a estrutura 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 suplicante Wi-Fi notifica o framework Wi-Fi sobre as mudanças no mapeamento de TID para link usando as 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 Android 14 ou mais recente, as seguintes APIs estão disponíveis para receber os recursos de negociação de mapa TID para link da estação e do AP.

Capacidade do chip

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

AIDL HAL

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 é compatível com o mapeamento de TID para link. APIs

Capacidade de AP

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

AIDL HAL

O framework consulta a capacidade de AP do suplicante junto com a capacidade de conexão atual.

APIs

As estatísticas da camada de link incluem detalhes específicos do link Wi-Fi, como RSSI, vários contadores de pacotes 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 Android 14 ou mais recente, as estatísticas da camada de link incluem suporte a vários links. Para oferecer suporte ao Wi-Fi 7, o Android é compatível com MLO nas estatísticas da camada de link e na sondagem de sinal.

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

A API do sistema android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() monitora 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 seguintes APIs específicas de links 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 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 um único link (não MLO) retornam as estatísticas agregadas das conexões MLO. Estes são os critérios de agregação:

  • As estatísticas de pacotes agregados 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 maior RSSI:

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

Em dispositivos com 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 é aquele com o maior RSSI.

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

Quando um dos links do ponto de acesso Wi-Fi 7 é reutilizado, o PA pode anunciar a remoção do link por meio da reconfiguração do link MLO. As estações podem manter a conectividade perfeita com o AP sem uma reassociação nos links restantes.

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

Quando o framework 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 no estado do link.

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

Estratégia de MLO de chip

Com o MLO, os dispositivos podem enviar e receber dados em várias conexões 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 em 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.