Wi-Fi 7

En dispositivos que ejecutan Android 13 o versiones posteriores, Android admite el estándar Wi-Fi 7 (IEEE 802.11be). En esta página, se describen las funciones de Android Wi-Fi 7, incluidos el modelo de referencia y la operación de varios vínculos (MLO).

Funciones de Wi-Fi 7 de referencia

En esta sección, se describen las funciones de Wi-Fi 7 de referencia que se incluyen en Android 13 y versiones posteriores.

Compatibilidad con Wi-Fi 7 del dispositivo

El framework de Android incluye la API de WifiManager#isWifiStandardSupported(int standard), a la que las apps pueden llamar con el argumento ScanResults.WIFI_STANDARD_11BE para verificar si un dispositivo es compatible con Wi-Fi 7.

Cuando se llama a esta API, el módulo Wi-Fi verifica si la superposición de configuración config_wifi11beSupportOverride se usa como anulación y hace lo siguiente:

  • Si la superposición se establece en true, se supone que el dispositivo es compatible con Wi-Fi 7, independientemente de la respuesta de nl80211. Esta anulación es útil solo para fabricantes de dispositivos que no tienen controladores que devuelvan compatibilidad con Wi-Fi 7.
  • Si la superposición se establece en false (valor predeterminado), el módulo Wi-Fi usa la información de nl80211. El módulo Wi-Fi solicita la información de wificond, que llama al comando nl80211 NL80211_CMD_GET_WIPHY. Si el atributo NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY está en la respuesta del controlador, se supone que el dispositivo es compatible con Wi-Fi 7.

Compatibilidad con Wi-Fi 7 de AP escaneada

El framework de Android incluye la API de int ScanResult#getWifiStandard(), a la que las apps pueden llamar para verificar si un punto de acceso (AP) escaneado admite Wi-Fi 7. Si el AP admite Wi-Fi 7, la API muestra ScanResults.WIFI_STANDARD_11BE. No es necesario que el dispositivo admita Wi-Fi 7 para que las apps usen esta API.

Cuando se llama a esta API, el módulo Wi-Fi verifica si EHT Capability IE está en los resultados que se muestran del análisis de conectividad. Si EHT Capability IE está en los resultados del análisis, el AP analizado admite Wi-Fi 7. La clase WifiTracker de AOSP muestra esta información de compatibilidad en la interfaz de usuario cuando se ejecuta en modo detallado.

Modo de conexión STA

El framework de Android incluye la API de int WifiInfo#getWifiStandard(), a la que las apps pueden llamar para verificar si el modo de conexión de la estación (STA) actual es Wi-Fi 7. El modo de conexión de STA es Wi-Fi 7 cuando tanto el dispositivo como el AP conectado admiten Wi-Fi 7. Si el modo de conexión es Wi-Fi 7, la API muestra ScanResults.WIFI_STANDARD_11BE.

Cuando se llama a getWifiStandard, el módulo de Wi-Fi determina el modo llamando a la API de HAL ISupplicantStaIface#getConnectionCapabilities(). La implementación de esta API de HAL en la capa del AIDL wpa_supplicant verifica si EHT Capability IE está en AssocReq y AssocRsp durante la configuración de la conexión.

Selección de red

En Android 13, la selección de red usa varios parámetros para determinar a qué AP conectarse. Uno de los parámetros es la capacidad de procesamiento estimada del AP, que se estima con el bloque ThroughputPredictor. El bloque ThroughputPredictor usa los parámetros PHY del dispositivo y del AP analizado.

En Android 13, ThroughputPredictor usa las siguientes capacidades de AP en su cálculo:

  • Compatibilidad con Wi-Fi 7 (802.11be)
  • Compatibilidad con un ancho de canal de 320 MHz

Si incluyes estas capacidades en la lógica de ThroughputPredictor, aumentas las posibilidades de seleccionar AP compatibles con Wi-Fi 7 cuando el dispositivo puede usar estas funciones.

Rango basado en el RTT de Wi-Fi

Android proporciona compatibilidad con la API para el preámbulo de EHT y el ancho de canal de 320 MHz para el RTT de Wi-Fi. Esto permite la compatibilidad con las funciones relacionadas con Wi-Fi 7 en el rango de RTT siempre que el chip las admita.

APIs de HAL

Las siguientes APIs de HAL admiten las funciones de Wi-Fi 7 para el rango basado en RTT:

APIs

Las apps pueden usar las siguientes APIs para el rango basado en RTT de Wi-Fi 7:

Soft AP

Android admite Wi-Fi 7 en Soft AP y proporciona las siguientes funciones.

Cómo iniciar un AP suave

Android admite el inicio de AP virtual en el modo Wi-Fi 7. Esto se rige por la configuración de la superposición config_wifiSoftapIeee80211beSupported.

El módulo Wi-Fi usa la superposición config_wifiSoftapIeee80211beSupported para establecer el valor booleano HwModeParams#enable80211BE en la llamada a la API de IHostApd#addAccessPoint(). En la capa AIDL de hostapd, este valor se usa para establecer los parámetros hostapd.conf.

APIs de HAL

El valor booleano enable80211BE en HwModeParams en el HAL de hostapd admite el inicio del AP en segundo plano en el modo Wi-Fi 7.

Informa la información del AP virtual

Android incluye compatibilidad con la API para incluir información de Wi-Fi 7 y ancho de canal de 320 MHz en la información del AP virtual informada.

APIs de HAL

La constante WIFI_STANDARD_11BE de la interfaz del AIDL de Generation.aidl en la HAL del hostapd, que se usa en el ApInfo informado en la devolución de llamada IHostapdCallback#onApInstanceInfoChanged(), admite la generación de informes de información del PA secundario.

APIs

Las apps pueden usar los siguientes métodos (APIs del sistema) en SoftApInfo para informar información de AP virtual.

Funciones de MLO Wi-Fi 7

La operación de varios vínculos (MLO) es la función principal de la especificación Wi-Fi 7 (802.11be). MLO es una función obligatoria para los dispositivos multivínculo (MLD) que se ejecutan en Wi-Fi 7, ya sea de forma simultánea o no.

Diagrama de MLO

Figura 1: Diagrama de MLO.

Como se muestra en la Figura 1, tanto el AP-MLD como el STA-MLD tienen varias instancias de AP o STA que se ejecutan en cada vínculo. Cada vínculo tiene una dirección MAC de AP o STA independiente. El AP o STA también tiene una dirección MAC de MLD para identificar el dispositivo.

La clase android.net.wifi.MloLink representa el vínculo de MLO. Esta clase incluye los siguientes parámetros:

  • int getLinkId(): ID de vínculo tal como lo anuncia el MLD del AP.
  • MacAddress getApMacAddress(): dirección MAC del AP El BSSID de la instancia del AP para ese vínculo.
  • MacAddress getStaMacAddress(): dirección MAC de la STA Es la dirección MAC asignada de forma local para la instancia de STA en el vínculo.
  • int getChannel(): Vincula el canal. El número del canal del vínculo.
  • int getBand(): Bando de vínculo. Es la banda del vínculo.

  • int getState(): estado del vínculo. Puede ser uno de los siguientes estados:

    • MLO_LINK_STATE_INVALID: No válido. Se usa para la inicialización y los casos de error.
    • MLO_LINK_STATE_UNASSOCIATED: No asociado. El vínculo no está asociado a un AP.
    • MLO_LINK_STATE_IDLE: Inactivo. El vínculo está asociado, pero no está activo (no hay ningún identificador de tráfico (TID) asignado al vínculo).
    • MLO_LINK_STATE_ACTIVE: activo El vínculo está asociado y activo (al menos un TID está asignado al vínculo). Un vínculo activo puede estar en modo de ahorro de energía porque el framework no supervisa su estado.

Se escaneó la información de Wi-Fi 7 AP MLO

Las apps pueden obtener los parámetros de MLO para un MLD de AP Wi-Fi 7 cuando el módulo Wi-Fi recibe un objeto ScanResult del AP-MLD. El WifiTracker del AOSP muestra los parámetros del MLO cuando se ejecuta en modo detallado.

El módulo Wi-Fi recopila la información de MLO de la siguiente manera:

  • Analiza el elemento de información de varios vínculos (IE) incluido en la baliza o la respuesta de sondeo para leer la dirección MAC de MLD del AP y el ID de vínculo actual.
  • Analiza el IE del informe de vecino reducido (RNR) incluido en la respuesta del sondeo o la baliza para leer la lista de información de los vínculos afiliados.

APIs

Para obtener información de la MLO de AP escaneada, las apps pueden usar las siguientes APIs:

Información de AP MLO de Wi-Fi 7 conectado

Cuando un dispositivo se conecta a un AP-MLD Wi-Fi 7, el framework recopila los parámetros de MLO de la conexión del objeto WifiInfo. El objeto WifiTracker de AOSP muestra esta información cuando se ejecuta en modo detallado.

Cuando el dispositivo se conecta con el AP-MLD, el módulo Wi-Fi copia la información del MLO del objeto ScanResult que se recibe del AP. Luego, el módulo llama a la API de HAL de ISupplicantStaIface#getConnectionMloLinksInfo() para leer las direcciones MAC de cada vínculo para AP y STA, y actualizar el estado de los vínculos asociados.

APIs

Para obtener información de conexión de MLO, las apps pueden usar las siguientes APIs:

Escaneo de AP-MLD

El software del proveedor proporciona al framework de Wi-Fi los resultados del análisis de cada píxel contador o respuesta de sondeo que recibe. Esto significa que el framework de Wi-Fi hace lo siguiente:

  • Es posible que reciba varios objetos ScanResults del mismo AP-MLD (porque el AP puede tener varios vínculos de beacon).
  • Es posible que solo recibas un conjunto parcial de los resultados de la búsqueda de los vínculos del AP de un AP-MLD porque es posible que el firmware no reciba algunos de estos indicadores de vínculo.

El software del proveedor solo informa los resultados de análisis recibidos por aire y no debe crear (sintetizar de forma artificial) resultados de análisis basados en los vínculos anunciados por el AP-MLD.

El software del proveedor debe incluir los IEs de multivínculo y RNR de la variante básica que se reciben de las instancias de AP en los resultados de análisis informados. Si faltan detalles del AP afiliado en los resultados de la búsqueda, el software del proveedor puede enviar solicitudes de sondeo de varios vínculos (marco de solicitud de sondeo que incluye un elemento de solicitud de sondeo de varios vínculos) para incluir el conjunto completo o parcial de capacidades, parámetros y elementos de operación del AP con el AP-MLD de destino en el marco de respuesta.

El software del proveedor puede activar la sondeo de AA (con el IE de variante de solicitud de sondeo de AA en el marco de solicitud de sondeo) si es necesario.

Asociación de red AP-MLD

Cuando un dispositivo se une a una red AP-MLD, el software del proveedor usa el vínculo del AP seleccionado (vínculo asociado) para la señalización. El software del proveedor se puede asociar a todos o algunos de los vínculos que admite el dispositivo.

Cuando se realiza una asociación correcta, el controlador informa ISupplicantStaIfaceCallback#onStateChanged() con el BSSID de un vínculo para el AP-MLD. Luego, el controlador selecciona un vínculo del AP-MLD, siempre que los resultados del análisis se hayan informado al framework para ese vínculo.

Puntuación de red

En dispositivos que ejecutan Android 14 o versiones posteriores, la selección de redes Wi-Fi de Android admite MLO de Wi-Fi 7. Esto significa que Android selecciona la mejor red Wi-Fi para el dispositivo en función de la cantidad de vínculos disponibles para MLO.

Para admitir MLO, el algoritmo de selección de red usa las siguientes capacidades de MLO del chip Wi-Fi:

  • Recuento máximo de vínculos de STR
  • Cantidad máxima de vínculos de asociación
  • Combinaciones de bandas simultáneas

Selección de red de MLO de Wi-Fi

Figura 2: Selección de red de MLO.

La transmisión y recepción simultáneas (STR) es un esquema de contención de medios Wi-Fi para la operación de varios vínculos. El aislamiento de señal entre los diferentes vínculos es suficiente para que estos puedan funcionar de forma independiente y sean capaces de transmitir y recibir de forma simultánea en diferentes vínculos. La STR es diferente de la STA de un solo vínculo (SL) heredado y de la STA de doble banda y doble transmisión simultánea (DBDC) heredada. Las STA afiliadas a una MLD de STA comparten un número de secuencia de transmisor (SN) común y un espacio común para la transmisión de datos asignado a diferentes vínculos si la transmisión de varios vínculos tiene la misma categoría de acceso (AC).

La cantidad máxima de vínculos STR que se usan puede ser diferente de la cantidad máxima de radios compatibles con el chip. En el ejemplo de la Figura 2, el recuento máximo de vínculos STR es 2.

Las siguientes interfaces de HAL de AIDL admiten la cantidad máxima de vínculos de STR y la cantidad máxima de capacidades de recuento de vínculos de asociación:

Varios vínculos pueden operar en una sola radio con el esquema de contención, la radio de un solo vínculo con múltiples enlaces mejorados (eMLSR). Un dispositivo multivínculo usa eMLSR en un conjunto de vínculos si puede recibir ciertas tramas de control básicas y realizar una evaluación de canal claro (CCA) de forma simultánea en el conjunto de vínculos. Sin embargo, el MLD transmite o recibe datos en un solo vínculo (el que se elige de forma dinámica en cada período de oportunidad de transmisión [TXOP]) a la vez.

Una estación MLD puede maximizar la cantidad de vínculos de asociación para obtener una mejor confiabilidad, una mejor capacidad de procesamiento y una latencia más baja (en comparación con una estación heredada de un solo vínculo) si opera de forma simultánea en STR y eMLSR, si el chip es compatible. En la Figura 2, el recuento máximo de vínculos de asociación es 3.

Las siguientes interfaces de HAL de AIDL admiten la función de recuento máximo de vínculos de asociación:

Combinaciones simultáneas de correas

El framework consulta el chip para obtener las combinaciones de radio permitidas (a través de la interfaz AIDL de IWifiChip.aidl) que pueden funcionar de forma simultánea. A partir de esta información, el framework deriva posibles combinaciones de bandas simultáneas. La siguiente es una lista de ejemplo de combinaciones de banda simultáneas (GHz):

  • 2.4
  • 5
  • 6
  • 2.4 × 5
  • 2.4 × 6
  • 5 × 6

La siguiente interfaz de la HAL del AIDL admite combinaciones de radio simultáneas:

Selección de red

Durante la selección de red (MLO), la lista de candidatos se agrupa por miembros con la misma dirección MAC de MLD. La puntuación máxima de capacidad de procesamiento de múltiples vínculos prevista se calcula para cada grupo, según el recuento máximo de vínculos STR y las combinaciones de bandas simultáneas que admite el chip. Si el candidato es compatible con varios vínculos y el chip admite STR, la puntuación de rendimiento pronosticado se reemplaza por la puntuación de rendimiento pronosticado de varios vínculos. Esto da un impulso a los candidatos de MLO durante la selección de red.

Cuando se une a una red AP-MLD, el framework realiza la selección del SSID según la información recibida en el objeto ScanResults, como lo informa el software del proveedor. Cuando el framework selecciona el SSID, el software del proveedor es responsable de seleccionar el BSSID para el mejor AP (o vínculo de AP) que se usará para la asociación.

Control de la dirección MAC de STA del dispositivo

En esta sección, se describe cómo se manejan las direcciones MAC de STA del dispositivo (direcciones MAC de STA de MLD y direcciones MAC de STA por vínculo).

Dirección MAC de MLD

El framework de Wi-Fi administra la dirección MAC de MLD del dispositivo. La dirección MAC de MLD se controla de la misma manera que un dispositivo que no es de MLD controla su propia dirección MAC. La dirección MAC puede ser una dirección MAC aleatoria o una dirección MAC aprovisionada por hardware según la elección del usuario. El framework configura la dirección MAC de MLD con la API de HAL de IWifiStaIface#setMacAddress().

El software del proveedor administra las direcciones MAC de la instancia de STA (para cada vínculo). Cuando un dispositivo se asocia con un AP, el software del proveedor asigna una dirección MAC de instancia para cada vínculo asociado.

El software del proveedor asigna direcciones MAC por vínculo según su algoritmo. El algoritmo debe ser repetible y ser una función de lo siguiente:

  • Dirección MAC de STA-MLD establecida por el framework de Wi-Fi.
  • ID del vínculo (recibido del AP)

Esto significa que, si el framework reutiliza la misma dirección MAC de MLD, el proveedor debe reutilizar las mismas direcciones MAC por instancia asociadas y viceversa. Esto garantiza que, cuando la dirección STA-MLD generada por el framework sea persistente para un SSID, las direcciones MAC por STA también sean persistentes.

El siguiente es un algoritmo de ejemplo para la asignación de direcciones MAC de STA por vínculo (los proveedores pueden implementar cualquier algoritmo que cumpla con los criterios del algoritmo):

  • Octeto 0: Asegúrate de que el bit administrado de forma local esté configurado
  • Octetos 1 a 4: Igual que la dirección MAC de STA-MLD
  • Octeto 5: Por STA = (STA-MLD + ID de vínculo + 1) MOD (256)

El firmware del proveedor puede realizar el cambio de vínculo y administrar el estado de ahorro de energía de los vínculos para la activación o desactivación sin entrada del framework de Wi-Fi.

El framework de Wi-Fi no espera una notificación cuando cambia el estado de la vinculación.

Administración del estado de ahorro de energía

El estado de ahorro de energía está habilitado de forma predeterminada en el framework de Wi-Fi. En el estado de ahorro de energía, el firmware del proveedor administra el estado de ahorro de energía de los vínculos individuales en función de los patrones de tráfico y las decisiones de activación o desactivación de los vínculos.

Sin embargo, el framework de Wi-Fi puede forzar la inhabilitación del estado de ahorro de energía llamando a la API de HAL de ISupplicantStaIface::setPowerSave(false). Si el framework inhabilita el estado de ahorro de energía, el firmware del proveedor debe mantener al menos un vínculo activo (ahorro de energía inhabilitado). En este estado, la implementación del firmware decide qué vínculo se establece.

Ruta de datos

Aquí se describe la implementación del firmware del proveedor para controlar el tráfico de uplink y descarga.

El firmware enruta el tráfico de uplink a uno (o más) vínculos según su implementación interna. El firmware del proveedor decide cuándo realizar el balanceo de cargas, la duplicación o la agregación de tráfico en función de los patrones de tráfico. Recomendamos que el firmware duplique el tráfico en varios vínculos en los siguientes casos:

  • Cuando se configura el modo de baja latencia a través de la API de HAL de IWifiChip#setLatencyMode().
  • Cuando hay tráfico con prioridad del usuario 6 y 7.

El firmware debe reemplazar la dirección MAC por STA (destino) del encabezado MAC con la MAC de MLD-STA y la dirección MAC por AP (fuente) del encabezado MAC con la dirección MAC de MLD-AP. El firmware debe realizar esta sustitución de dirección MAC antes de pasar por el filtro de APF porque los comandos del filtro de APF tienen filtros basados en direcciones MAC de MLD. Hay un solo filtro APF para todos los vínculos de un AP-MLD.

Simultaneidad

Las situaciones de simultaneidad, en las que se usa una radio para una interfaz nueva, deben tener prioridad sobre la dedicación de varias radios para los vínculos de la misma interfaz. Las situaciones de simultaneidad también deben tener prioridad sobre MLO, sin importar cuál haya ocurrido primero. El uso de varios vínculos para una sola interfaz es oportunista, lo que significa que se usan varios vínculos solo en los siguientes casos:

  • MLO es obligatorio según la decisión de firmware para el balanceo de cargas, la agregación o la duplicación.
  • MLO está disponible, lo que significa que otra interfaz no requiere una radio.

En el caso de los dispositivos que ejecutan Android 14 o versiones posteriores, cuando el AP Wi-Fi 7 anuncia una inhabilitación temporal de uno de los vínculos a través de un elemento de asignación de TID a vínculo transmitido en la trama de respuesta de la baliza, la respuesta de la sonda y la trama de respuesta de asociación, la estación Wi-Fi 7 continúa la conexión con el AP usando los vínculos restantes que están configurados, sin realizar otra asociación.

En el caso de los dispositivos con Android 13 o versiones anteriores, el framework de Wi-Fi no admite recibir notificaciones cuando cambia el estado del vínculo debido a la asignación de TID a vínculo, incluso si el vínculo asociado no está vinculado a un TID.

El solicitante de Wi-Fi notifica al framework de Wi-Fi los cambios de asignación de TID a vínculo a través de las siguientes interfaces de AIDL:

Las apps pueden obtener información sobre los cambios de asignación de TID a vínculo con las siguientes APIs:

En dispositivos que ejecutan Android 14 o versiones posteriores, las siguientes APIs están disponibles para obtener las capacidades de negociación de mapas de TID a vínculo para la estación y el AP.

Capacidad del chip

Las siguientes interfaces admiten la capacidad del chip para la negociación de asignación de TID a vínculo.

HAL del AIDL

La interfaz AIDL para la negociación de asignación de TID a vínculo está en FeatureSetMask en hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl. La función T2LM_NEGOTIATION = 1 << 8 indica que el chip admite la asignación de TID a vínculo. APIs

Capacidad de punto de acceso

Las siguientes interfaces admiten la capacidad del AP para la negociación de la asignación de TID a vínculo.

AIDL HAL

El framework consulta la capacidad del AP al solicitante junto con la capacidad de conexión actual.

APIs

Las estadísticas de la capa de vínculo incluyen detalles específicos del vínculo Wi-Fi, como RSSI, varios contadores de paquetes de TX y RX, y estadísticas de radio. El framework de Wi-Fi sondea periódicamente las estadísticas de la capa de vínculo y el RSSI para seleccionar la mejor red o evaluar la calidad de la red conectada. En dispositivos que ejecutan Android 14 o versiones posteriores, las estadísticas de la capa de vínculo incluyen compatibilidad con varios vínculos. Para admitir Wi-Fi 7, Android admite MLO tanto en las estadísticas de la capa de vínculos como en el sondeo de señal.

Las estadísticas específicas de los vínculos se encuentran en las siguientes interfaces de AIDL de la capa de vínculos:

La API del sistema android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() escucha todas las estadísticas de la capa de vínculo. El framework invoca esta API de forma periódica para actualizar las estadísticas de usabilidad de Wi-Fi.

Las siguientes APIs específicas de vínculos están disponibles en 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 los IDs de vínculo disponibles, las apps pueden llamar al método android.net.wifi.WifiUsabilityStatsEntry#getLinkIds().

Las APIs de android.net.wifi.WifiUsabilityStatsEntry para un solo vínculo (no MLO) muestran las estadísticas agregadas de las conexiones de MLO. A continuación, se muestran los criterios de agregación:

  • Las siguientes estadísticas de paquetes agregadas usan la suma de las estadísticas por vínculo:

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

  • Las siguientes estadísticas usan los datos del vínculo con el RSSI más alto:

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

En el caso de los dispositivos que ejecutan Android 13, las estadísticas de la capa de vínculo no tienen en cuenta el uso de varios vínculos para una sola interfaz. Para admitir el MLO, el software del proveedor debe aplicar la siguiente lógica de agregación cuando se informa LinkLayerStats a través de la API de HAL de IWifi# getLinkLayerStats_1_6(). El mejor vínculo es el que tiene el RSSI más alto.

  • StaLinkLayerStats.iface.beaconRx: Informa el recuento de píxeles contadores para el mejor vínculo que se usa en la interfaz.
  • StaLinkLayerStats.iface.avgRssiMgmt: Informa avgRssiMgmt para obtener el mejor vínculo que se usa para la interfaz.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk): Informa las estadísticas agregadas del paquete (total) en los vínculos de la interfaz.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk): Informa las estadísticas de tiempo de contención para el mejor vínculo que se usa en la interfaz (las estadísticas de tiempo de contención más bajas).

Cuando se cambia el uso de uno de los vínculos del punto de acceso Wi-Fi 7, el AP puede anunciar la eliminación del vínculo a través de la reconfiguración del vínculo MLO. Las estaciones pueden mantener una conectividad fluida con el AP sin una reasociación en los vínculos restantes.

La interfaz AIDL onMloLinksInfoChanged, ubicada en el solicitante de Wi-Fi en ISupplicantStaIfaceCallback.aidl, admite la reconfiguración del vínculo (eliminación del vínculo del AP).

Cuando el framework de Wi-Fi procesa la eliminación de un vínculo, el estado del vínculo se establece en MLO_LINK_STATE_UNASSOCIATED. Luego, el framework activa ConnectivityManager.NetworkCallback#onCapabilitiesChanged() para un cambio de estado de vínculo.

El método WifiInfo#getAffiliatedMloLinks muestra los vínculos de MLO afiliados. El método MloLink#getState muestra el estado del vínculo. Si se quita el vínculo, el estado del vínculo que se muestra es MLO_LINK_STATE_UNASSOCIATED.

Estrategia de MLO de chip

MLO permite que los dispositivos envíen y reciban datos en varios vínculos Wi-Fi al mismo tiempo, lo que puede mejorar el rendimiento de las apps que tienen requisitos específicos, como baja latencia, ancho de banda alto y baja energía. Los proveedores de chips pueden desarrollar algoritmos para usar los vínculos disponibles.

Las apps con privilegios pueden modificar estos algoritmos con el método setMloMode en Wifimanager y establecer los siguientes modos:

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

El framework usa setMloMode en la interfaz AIDL de IWifiChip para configurar el modo MLO.