Wi-Fi 7

Para dispositivos com o Android 13 ou mais recente, oferece suporte ao padrão Wi-Fi 7 (IEEE 802.11be). Esta página descreve o Android Recursos do Wi-Fi 7, incluindo valor de referência e operação 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 mais recentes.

Compatibilidade com o Wi-Fi 7 do dispositivo

O framework do Android inclui a WifiManager#isWifiStandardSupported(int standard) que os aplicativos podem chamar com a ScanResults.WIFI_STANDARD_11BE para verificar se um dispositivo é compatível com 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 compatíveis com o Wi-Fi 7.
  • Se a sobreposição for definida como false (valor padrão), o módulo de Wi-Fi usa as informações de nl80211. O módulo Wi-Fi solicita as informações do wificond, que chama o comando nl80211 NL80211_CMD_GET_WIPHY. Se o O atributo NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY está na resposta do padrão, presume-se que o dispositivo tenha suporte a Wi-Fi 7.

Verificação de compatibilidade com Wi-Fi 7 de AP

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

Quando essa API é chamada, o módulo de Wi-Fi verifica se EHT Capability IE está nos resultados retornados da verificação de conectividade. Se EHT Capability IE estiver em e os resultados da verificação, o AP verificado é compatível com Wi-Fi 7. A classe WifiTracker do AOSP exibe essas informações de suporte no usuário ao ser executado no modo detalhado.

Modo de conexão STA

O framework do Android inclui a int WifiInfo#getWifiStandard() API, que os apps podem chamar para verificar se a conexão da estação atual (STA) o modo Wi-Fi 7. O modo de conexão STA é Wi-Fi 7 quando o dispositivo e e se o AP conectado oferecer suporte ao Wi-Fi 7. Se o modo de conexão for Wi-Fi 7, a API retorna ScanResults.WIFI_STANDARD_11BE

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

Seleção de rede

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

No Android 13, o ThroughputPredictor usa o seguintes recursos de AP em seu cálculo:

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

A inclusão desses recursos na lógica do ThroughputPredictor aumenta a chances de selecionar APs compatíveis com Wi-Fi 7 quando o dispositivo puder usá-los atributos de machine learning.

Intervalo por Wi-Fi RTT

O Android oferece suporte à API para preâmbulo de EHT e largura de canal de 320 MHz para RTT do Wi-Fi. Isso permite suporte de recursos relacionados ao Wi-Fi 7 em alcance de RTT sempre que for com suporte do chip.

APIs HAL

As seguintes APIs HAL são compatíveis com 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:

AP de software

O Android é compatível com o Wi-Fi 7 em Soft AP e oferece o seguinte atributos de machine learning.

Iniciar soft AP

O Android é compatível com a inicialização do Soft AP no modo Wi-Fi 7. Isso é regido pela sobreposição config_wifiSoftapIeee80211beSupported configuração do Terraform.

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

APIs HAL

A enable80211BE booleano em HwModeParams no hostapd HAL oferece suporte iniciando o Soft AP no modo Wi-Fi 7.

Relatar informações de AP de software

O Android oferece suporte a APIs para incluir o Wi-Fi 7 e a largura do canal de 320 MHz nas informações de Soft AP relatadas.

APIs HAL

A constante WIFI_STANDARD_11BE nas Generation.aidl A interface AIDL na HAL hostapd, que é usada nas ApInfo informadas em IHostapdCallback#onApInstanceInfoChanged() suporte a relatórios de informações de soft AP.

APIs

Os aplicativos podem usar os seguintes métodos (APIs do sistema) em SoftApInfo para relatar informações de AP de software.

Recursos do MLO Wi-Fi 7

A operação de vários links (MLO, na sigla em inglês) é o principal recurso do Wi-Fi 7 (802.11be) especificação. O MLO é um recurso obrigatório para dispositivos de vários links (MLD) em execução no Wi-Fi 7, de forma simultânea ou não simultânea.

Diagrama do MLO

Figura 1. Diagrama do MLO.

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

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

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

Os apps podem receber os parâmetros MLO para um Wi-Fi 7 AP MLD quando o módulo Wi-Fi recebe um ScanResult do AP-MLD. O WifiTracker do AOSP exibe os parâmetros do MLO quando: em execução no modo detalhado.

Para coletar as informações do MLO, o módulo de Wi-Fi faz o seguinte:

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

APIs

Para receber informações verificadas da AP MLO, os apps podem usar as seguintes APIs:

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

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

Quando o dispositivo se conecta com o AP-MLD, o módulo Wi-Fi copia o MLO informações do objeto ScanResult recebidas do AP. O módulo então chama a API HAL ISupplicantStaIface#getConnectionMloLinksInfo(); para ler os endereços MAC de cada link para o AP e o 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 o framework de Wi-Fi com os resultados da verificação para cada resposta de beacon ou sondagem que recebe. Isso significa que o Wi-Fi framework:

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

O software do fornecedor relata apenas os resultados recebidos via OTA e precisa não criar (sintetizar artificialmente) os resultados da verificação com base em links anunciados usando no AP-MLD.

O software do fornecedor precisa incluir a variante básica de vários links e RNR IEs recebidos das instâncias de AP nos resultados de verificação informados. Se o PA afiliado faltarem detalhes nos resultados da verificação, o software do fornecedor poderá enviar links solicitações de sondagem (frame de solicitação de sondagem que inclui uma solicitação de link múltiplo de sondagem) elemento) para incluir o conjunto completo ou parcial de capacidades, parâmetros e elementos de operação do AP com o AP-MLD visado no frame de resposta.

O software do fornecedor Pode acionar a sondagem de ML (usando a variante de ML IE da solicitação de sondagem no frame de solicitação da 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 AP selecionado (link associado) para sinalização. O software do fornecedor pode associar a todos ou alguns links suportados pelo dispositivo.

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

Pontuação de rede

Para dispositivos com o Android 14 ou mais recente, Seleção de rede Wi-Fi do Android oferece suporte ao Wi-Fi 7 MLO. Isso significa que o Android seleciona Rede Wi-Fi do 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 o MLO a seguir: do chip Wi-Fi:

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

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) é um esquema de contenção média de Wi-Fi para operação de vários vínculos. O isolamento de indicador entre links diferentes é suficiente para que os links possam operar de forma independente e possam transmitir e recebendo simultaneamente em links diferentes. O STR é diferente do single legado link (SL) STA e STA legado de banda dupla simultânea (DBDC, na sigla em inglês). Afiliados a STAs com um STA MLD compartilham um número de sequência do transmissor (SN) comum espaço para transmissão de dados alocado para links diferentes se vários links transmissão têm 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 com suporte do chip. No exemplo da Figura 2, o STR máximo a contagem de links é 2.

As seguintes interfaces HAL de AIDL oferecem suporte à contagem máxima de links STR. e número máximo de recursos de contagem de vinculações de associação:

Vários links podem operar em um único rádio usando o esquema de contenção, Rádio única com vários links aprimorado (eMLSR, na sigla em inglês). Um dispositivo de vários links usa eMLSR em uma conjunto de links se puder receber certos frames de controle básicos e executar avaliação de canal (CCA) 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 vínculos de associação para melhorar confiabilidade, melhor capacidade de processamento e menor latência (em comparação com um único link estação legada) operando simultaneamente em STR e eMLSR se compatível com as ícone. Na Figura 2, o número máximo de vínculos de associação é 3.

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

Combinações simultâneas de pulseiras

O framework consulta o ícone para conseguir as combinações de opção permitidas (usando a interface AIDL IWifiChip.aidl) que podem operar simultaneamente. A partir deste informações, o framework gera possíveis combinações de bandas simultâneas. A Veja a seguir um exemplo de lista de combinações simultâneas de bandas (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 as mesmo endereço MAC MLD. A pontuação máxima prevista da capacidade de processamento de vários links é calculados para cada grupo, com base na contagem máxima de STR links e eventos diferentes de banda compatíveis com o chip. Se o candidato aceitar várias vinculações e o chip oferecer suporte a STR, a pontuação de capacidade prevista será substituída pelo pontuação de capacidade prevista de vários links. Isso dá um impulso aos candidatos ao MLO durante a seleção da rede.

Ao entrar em uma rede AP-MLD, o framework realiza a seleção do SSID com base nas informações recebidas no objeto ScanResults, conforme relatado pelo fornecedor de software. 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) para usar associação.

Processamento de endereços MAC STA do dispositivo

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

Endereço MAC do MLD

O framework Wi-Fi gerencia o endereço MAC MLD do dispositivo. O MAC do MLD é tratado da mesma forma que um dispositivo não MLD lida com seu próprio endereço MAC. O endereço MAC pode ser um endereço MAC aleatório ou um MAC 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 do STA da instância (para cada link). Quando um associado a um AP, o software do fornecedor atribui uma instância MAC para cada link associado.

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

  • 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 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 são persistentes.

Veja 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 do algoritmo):

  • Octeto 0: verificar se o bit administrado localmente está definido
  • Octeto 1 a 4: igual ao endereço MAC do STA-MLD
  • Octeto 5: Per-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 Wi-Fi de análise de dados em nuvem.

A estrutura de Wi-Fi não espera uma notificação quando o estado do link é mudou.

Gerenciamento do estado de economia de energia

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

No entanto, o framework de 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 precisa manter pelo menos um link ativo (economia de energia desativada). Nesse caso, o firmware define qual link é definido.

Caminho dos dados

Isso descreve a implementação de firmware do fornecedor para lidar com uplink e tráfego de download.

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

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

O firmware precisa substituir o endereço MAC (destino) por STA do MAC cabeçalho com o MAC MLD-STA e 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 o Os comandos de filtro do APF têm filtros baseados nos endereços MAC do MLD. Há um único Filtro do APF para todos os links de um AP-MLD.

Simultaneidade

Cenários de simultaneidade, em que um rádio é usado para uma nova interface, devem ter prioridade em relação à dedicação de vários rádios para links da mesma interface. Os cenários de simultaneidade também devem ter prioridade sobre o MLO, não importa qual tenha surgido primeiro. Usar vários links para uma única interface é oportunista, ou seja, que 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, o que significa que um rádio não é exigido por outra interface.

Para dispositivos com o Android 14 ou mais recente, quando o O Wi-Fi 7 AP anuncia a desativação temporária de um dos links por meio de um Elemento de mapeamento TID para vinculação transmitido no beacon, na resposta da sondagem e quadros de resposta de associação, a estação Wi-Fi 7 continuará a conexão com o AP usando os links restantes que estão configurados, sem realizar outra associação.

Em dispositivos com o Android 13 ou versões anteriores, não oferece suporte ao recebimento de notificações quando o estado do link é mudou devido ao mapeamento TID-to-link, mesmo que o link associado não esteja vinculado um TID.

O suplicante de Wi-Fi notifica o framework de Wi-Fi sobre o mapeamento TID-to-link mudanças por meio das seguintes interfaces AIDL:

Os aplicativos podem obter informações sobre alterações no mapeamento de TID-to-link usando o as seguintes APIs:

Para dispositivos com o Android 14 ou mais recente: As APIs estão disponíveis para obter os recursos de negociação de mapas TID para vincular para a estação e o AP.

Capacidade do chip

As interfaces a seguir são compatíveis com o recurso de chip para mapeamento TID-to-link. negociação.

HAL da AIDL

A interface da AIDL para negociação do mapeamento TID para vinculação está em FeatureSetMask em hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl. A O capability T2LM_NEGOTIATION = 1 << 8 indica que o ícone oferece suporte a Mapeamento de TID para vinculação. APIs

Recurso do ponto de acesso

As interfaces a seguir são compatíveis com o recurso AP para o mapeamento TID-to-link negociação.

HAL da AIDL

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

APIs

As estatísticas da camada de enlace incluem detalhes específicos de link Wi-Fi como RSSI, várias conexões contadores de pacotes RX e estatísticas de rádio. O framework de Wi-Fi pesquisa periodicamente estatísticas da camada de links e RSSI para selecionar a melhor rede ou avaliar a qualidade da rede conectada. Para dispositivos com Android 14 ou superior, as estatísticas da camada de links incluem suporte a vários links. Para oferecer suporte ao Wi-Fi 7, o Android oferece suporte ao MLO nas camadas de enlace estatísticas e sondagem de sinais.

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

A android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() A API do sistema 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 seguintes APIs específicas de link 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 aplicativos podem chamar o método android.net.wifi.WifiUsabilityStatsEntry#getLinkIds() .

APIs na android.net.wifi.WifiUsabilityStatsEntry para link único (não MLO), retorna as estatísticas agregadas para conexões MLO. A estes são os critérios de agregação:

  • As seguintes estatísticas de pacote agregadas 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, estatísticas da camada de links não levam em conta uso de vários links para uma única interface. Para dar suporte ao MLO, os softwares de fornecedores precisa aplicar a lógica de agregação a seguir ao informar LinkLayerStats. usando a API HAL IWifi# getLinkLayerStats_1_6(). O melhor link é com o RSSI mais alto.

  • StaLinkLayerStats.iface.beaconRx: informa a contagem de beacons para o melhor usado para a interface.
  • StaLinkLayerStats.iface.avgRssiMgmt: relatório avgRssiMgmt para o melhor link usado para a interface.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk): relatório as estatísticas agregadas do pacote (total) nos links da interface.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk): informa as estatísticas de tempo de contenção para o melhor link usado no interface (estatísticas de menor tempo de contenção).

Quando um dos links do ponto de acesso do Wi-Fi 7 é reutilizado, o AP pode anunciar a remoção da vinculação pela reconfiguração de links do MLO. Estações possa manter uma conectividade perfeita com o AP sem precisar se associar novamente links restantes.

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

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

A WifiInfo#getAffiliatedMloLinks retorna os links MLO afiliados. A MloLink#getState retorna o estado do link. Se o link for removido, o link retornado estado é 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 que têm 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 aplicativos privilegiados podem modificar esses algoritmos usando a setMloMode em Wifimanager e defina 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.