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 Wi-Fi 7 de Android, incluidas las operaciones básicas y de varios vínculos (MLO).

Funciones básicas de Wi-Fi 7

En esta sección, se describen las funciones básicas de Wi-Fi 7 incluidas en Android 13 y versiones posteriores.

Compatibilidad del dispositivo con Wi-Fi 7

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 admite Wi-Fi 7.

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

  • Si la superposición se establece en true, se supone que el dispositivo admite Wi-Fi 7, independientemente de la respuesta de nl80211. Esta anulación solo es útil para los fabricantes de dispositivos que no tienen controladores que admitan Wi-Fi 7.
  • Si la superposición está configurada como false (valor predeterminado), el módulo Wi-Fi usa la información de nl80211. El módulo de Wi-Fi solicita la información a 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 admite Wi-Fi 7.

Compatibilidad con Wi-Fi 7 de AP analizado

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) analizado admite Wi-Fi 7. Si el AP admite Wi-Fi 7, la API devuelve 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 de Wi-Fi verifica si EHT Capability IE se encuentra en los resultados devueltos del análisis de conectividad. Si EHT Capability IE se encuentra 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 de la 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 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 devuelve 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 de AIDL de 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 calcula con el bloque ThroughputPredictor. El bloque ThroughputPredictor usa los parámetros de 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

Incluir estas capacidades en la lógica de ThroughputPredictor aumenta las probabilidades de seleccionar AP compatibles con Wi-Fi 7 cuando el dispositivo puede usar estas funciones.

Medición de rango basada en 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 Wi-Fi RTT. Esto permite la compatibilidad con las capacidades relacionadas con Wi-Fi 7 en el rango de RTT siempre que el chip lo admita.

APIs de HAL

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

APIs

Las apps pueden usar las siguientes APIs para la medición basada en RTT de Wi-Fi 7:

Soft AP

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

Iniciar AP suave

Android admite el inicio del AP suave en modo Wi-Fi 7. Esto se rige por la configuración de la capa superpuesta config_wifiSoftapIeee80211beSupported.

El módulo de 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 de hostapd.conf.

APIs de HAL

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

Informa la información de Soft AP

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

APIs de HAL

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

APIs

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

Funciones de MLO Wi-Fi 7

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

Diagrama de MLO

Figura 1: Diagrama de MLOps.

Como se muestra en la figura 1, tanto el AP-MLD como el STA-MLD tienen varias instancias de AP o STA ejecutándose en cada vínculo. Cada vínculo tiene una dirección MAC de AP o STA independiente. El AP o la STA también tienen 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(): Es el ID de vínculo tal como lo anuncia el MLD de la AP.
  • MacAddress getApMacAddress(): Dirección MAC del AP. Es 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 la STA en la vinculación.
  • int getChannel(): Vincula el canal. Es el número de canal del vínculo.
  • int getBand(): Correa de eslabones. Es la banda del vínculo.

  • int getState(): Estado del vínculo. Puede tener 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 activo (no hay un 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 el estado de energía del vínculo.

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

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

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

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

APIs

Para obtener información sobre la ubicación de los AP analizados, las apps pueden usar las siguientes APIs:

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

Cuando un dispositivo se conecta a un AP-MLD de Wi-Fi 7, el framework recopila los parámetros de MLO de la conexión desde el 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 recibe del AP. Luego, el módulo llama a la API de HAL ISupplicantStaIface#getConnectionMloLinksInfo() para leer las direcciones MAC de cada vínculo tanto para AP como para STA, y para 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:

Análisis de AP-MLD

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

  • Es posible que se reciban varios objetos ScanResults del mismo AP-MLD (porque el AP puede tener varios vínculos de balizamiento).
  • Es posible que solo se reciba un conjunto parcial de los resultados del análisis de los vínculos de 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 del análisis recibidos de forma inalámbrica y no debe crear (sintetizar artificialmente) resultados del análisis basados en los vínculos anunciados por el AP-MLD.

El software del proveedor debe incluir el IE de RNR y el vínculo múltiple de la variante básica recibidos de las instancias de AP en los resultados del análisis informado. Si faltan detalles de los AP afiliados en los resultados del análisis, el software del proveedor puede enviar solicitudes de sondeo de varios vínculos (trama 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 objetivo en la trama de respuesta.

El software del proveedor puede activar la detección de ML (con la IE de ML de la variante de la solicitud de detección en el marco de la solicitud de detección) si es necesario.

Asociación de red de AP-MLD

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

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

Puntuación de la 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 según la cantidad de vínculos disponibles para MLO.

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

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

Selección de red MLO de Wi-Fi

Figura 2: Selección de la red de MLO.

La transmisión y recepción simultáneas (STR) son un esquema de contención de medios Wi-Fi para el funcionamiento de múltiples vínculos. El aislamiento de la señal entre los diferentes vínculos es suficiente para que los vínculos puedan operar de forma independiente y sean capaces de transmitir y recibir simultáneamente en diferentes vínculos. La STA de STR es diferente de la STA heredada de vínculo único (SL) y de la STA heredada de doble banda y doble simultaneidad (DBDC). Las STA afiliadas a una MLD de STA comparten un número de secuencia (SN) de transmisor 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 de STR que se pueden usar puede ser diferente de la cantidad máxima de radios que admite el chip. En el ejemplo de la figura 2, el recuento máximo de vínculos de STR es 2.

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

Varios vínculos pueden operar en una sola radio con el esquema de contención, radio única de múltiples vínculos mejorada (eMLSR). Un dispositivo de múltiples vínculos usa eMLSR en un conjunto de vínculos si puede recibir ciertos tramas de control básicas y realizar una evaluación de canal libre (CCA) de forma simultánea en el conjunto de vínculos. Sin embargo, la MLD transmite o recibe datos en un solo vínculo (el vínculo 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 mejorar la confiabilidad, la capacidad de procesamiento y la latencia (en comparación con una estación heredada de un solo vínculo) operando de forma simultánea en STR y eMLSR si el chip lo admite. En la figura 2, el recuento máximo de vínculos de asociación es 3.

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

Combinaciones de bandas simultáneas

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

  • 2.4
  • 5
  • 6
  • 2.4 x 5
  • 2.4 x 6
  • 5 x 6

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

Selección de red

Durante la selección de la 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 predicha de varios vínculos se calcula para cada grupo en función del recuento máximo de vínculos de 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 capacidad de procesamiento predicha se reemplaza por la puntuación de capacidad de procesamiento predicha de varios vínculos. Esto impulsa a los candidatos a MLO durante la selección de la red.

Cuando se une a una red de AP-MLD, el framework realiza la selección del SSID en función de la información recibida en el objeto ScanResults, según 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 la STA del dispositivo

En esta sección, se describe cómo se controlan las direcciones MAC de STA del dispositivo (direcciones MAC 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 en que un dispositivo que no es MLD controla su propia dirección MAC. La dirección MAC puede ser aleatoria o estar aprovisionada por hardware, según la elección del usuario. El framework establece la dirección MAC de MLD con la API de HAL de IWifiStaIface#setMacAddress().

El software del proveedor administra las direcciones MAC de la STA de la instancia (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 una función de lo siguiente:

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

Esto significa que, si el framework reutiliza la misma dirección MAC de MLD, el proveedor debe reutilizar las mismas direcciones MAC asociadas por instancia, 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 lo serán.

A continuación, se muestra un ejemplo de algoritmo 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é establecido
  • Octetos del 1 al 4: Son los mismos que la dirección MAC de STA-MLD.
  • Octeto 5: Per-STA = (STA-MLD + ID de vínculo + 1) MOD (256)

El firmware del proveedor puede realizar el cambio de vínculos y administrar el estado de ahorro de energía de los vínculos para la activación o desactivación sin la 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 las vinculaciones individuales según los patrones de tráfico y las decisiones de activación o desactivación de la vinculación.

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

Ruta de datos

En este documento, se describe la implementación del firmware del proveedor para controlar el tráfico de carga y descarga.

El firmware enruta el tráfico de vínculo ascendente a uno (o más) vínculos según su implementación interna. El firmware del proveedor decide cuándo balancear la carga, duplicar o agregar el tráfico en función de los patrones de tráfico. Recomendamos duplicar el tráfico del firmware 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 dirección MAC por MLD-STA y la dirección MAC por AP (fuente) del encabezado MAC con la dirección MAC por MLD-AP. El firmware debe realizar esta sustitución de la dirección MAC antes de pasar por el filtro de APF, ya que los comandos del filtro de APF tienen filtros basados en direcciones MAC de MLD. Hay un solo filtro de 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 vínculos de la misma interfaz. Los casos de uso de simultaneidad también deben tener prioridad sobre el MLO, independientemente de cuál haya llegado primero. Usar varios vínculos para una sola interfaz es oportunista, lo que significa que se usan varios vínculos solo en los siguientes casos:

  • El MLO es obligatorio según la decisión del 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 dispositivos que ejecutan Android 14 o versiones posteriores, cuando el AP de 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 tramas de baliza, respuesta de sondeo y respuesta de asociación, la estación de 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 que ejecutan Android 13 o versiones anteriores, el framework de Wi-Fi no admite la recepción de 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 suplicante de Wi-Fi notifica al framework de Wi-Fi los cambios en la 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 en la asignación de TID a vínculos 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 del mapa 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 la asignación de TID a vínculo.

AIDL HAL

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

Capacidad de AP

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

AIDL HAL

El framework consulta la capacidad de AP del suplicante 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 el 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 en las estadísticas de la capa de vínculo y en el sondeo de la señal.

Las estadísticas específicas de vínculos se encuentran en las siguientes interfaces 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 periódicamente esta API para actualizar las estadísticas de usabilidad de Wi-Fi.

Las siguientes APIs específicas para 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ínculos disponibles, las apps pueden llamar al método android.net.wifi.WifiUsabilityStatsEntry#getLinkIds().

Las APIs en android.net.wifi.WifiUsabilityStatsEntry para una sola vinculación (no MLO) devuelven las estadísticas agregadas para las conexiones de MLO. Los siguientes son 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 de la vinculación 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 informe 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 balizas para el mejor vínculo utilizado en la interfaz.
  • StaLinkLayerStats.iface.avgRssiMgmt: Informa avgRssiMgmt para el mejor vínculo que se usa en la interfaz.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk): Informa las estadísticas de paquetes agregadas (totales) en los vínculos de la interfaz.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk): Informa las estadísticas del tiempo de contención para la mejor vinculación utilizada en la interfaz (las estadísticas de tiempo de contención más bajas).

Cuando se cambia el propósito 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 perfecta con el AP sin una reasociación en las vinculaciones restantes.

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

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

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

Estrategia de MLO de chip

El MLO permite que los dispositivos envíen y reciban datos en múltiples vínculos de Wi-Fi al mismo tiempo, lo que puede mejorar el rendimiento de las apps que tienen requisitos específicos, como baja latencia, alto ancho de banda y bajo consumo de energía. Los proveedores de chips pueden desarrollar algoritmos sobre cómo usar las vinculaciones 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 IWifiChip de AIDL para establecer el modo de MLO.