Wifi 7

Para dispositivos con Android 13 o superior, Android admite el estándar Wi-Fi 7 (IEEE 802.11be). Esta página describe las funciones de Android Wi-Fi 7, incluida la operación básica y de enlace múltiple (MLO).

Funciones básicas de Wi-Fi 7

Esta sección describe las funciones básicas de Wi-Fi 7 incluidas en Android 13 y versiones posteriores.

Compatibilidad con dispositivos Wi-Fi 7

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

Cuando se llama a esta API, el módulo Wi-Fi comprueba si la superposición de configuración config_wifi11beSupportOverride se utiliza 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 es útil solo para los fabricantes de dispositivos que no tienen controladores que devuelvan soporte para Wi-Fi 7.
  • Si la superposición se establece en false (valor predeterminado), el módulo Wi-Fi utiliza la información de nl80211. El módulo 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 es compatible con Wi-Fi 7.

Compatibilidad con AP Wi-Fi 7 escaneado

El marco de Android incluye la API int ScanResult#getWifiStandard() , a la que las aplicaciones pueden llamar para verificar si un punto de acceso (AP) escaneado admite Wi-Fi 7. Si el AP admite Wi-FI 7, la API devuelve ScanResults.WIFI_STANDARD_11BE . No es necesario que el dispositivo sea compatible con Wi-Fi 7 para que las aplicaciones utilicen esta API.

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

Modo de conexión STA

El marco de trabajo de Android incluye la API int WifiInfo#getWifiStandard() , a la que las aplicaciones pueden llamar para verificar si el modo de conexión de la estación actual (STA) es Wi-Fi 7. El modo de conexión de STA es Wi-Fi 7 cuando tanto el dispositivo como el conectado AP admite 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 Wi-Fi determina el modo llamando a la API HAL ISupplicantStaIface#getConnectionCapabilities() . La implementación de esta API HAL en la capa AIDL wpa_supplicant verifica si EHT Capability IE está tanto en AssocReq como AssocRsp durante la configuración de la conexión.

Seleccion de red

En Android 13, la selección de red utiliza varios parámetros para determinar a qué AP conectarse. Uno de los parámetros es el rendimiento estimado del AP, que se estima utilizando el bloque ThroughputPredictor . El bloque ThroughputPredictor utiliza los parámetros PHY tanto del dispositivo como del AP escaneado.

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

  • Soporte de Wi-Fi 7 (802.11be)
  • Soporte de ancho de canal de 320 MHz

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

Rango basado en Wi-Fi RTT

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

API HAL

Las siguientes API HAL admiten las capacidades de Wi-Fi 7 para alcance basado en RTT:

API

Las aplicaciones pueden usar las siguientes API para el alcance basado en RTT de Wi-Fi 7:

AP suave

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

Iniciar AP suave

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

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

API HAL

El booleano enable80211BE en HwModeParams en hostapd HAL admite el inicio de Soft AP en modo Wi-Fi 7.

Informar información de AP blando

Android incluye soporte API para incluir información de ancho de canal de Wi-Fi 7 y 320 MHz en la información de Soft AP reportada.

API HAL

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

API

Las aplicaciones pueden utilizar los siguientes métodos (API del sistema) en SoftApInfo para informar información de Soft AP.

Funciones de MLO Wi-Fi 7

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

diagrama MLO

Figura 1. Diagrama MLO.

Como se muestra en la Figura 1, tanto AP-MLD como STA-MLD tienen múltiples instancias de AP o STA ejecutándose en cada enlace. Cada enlace tiene una dirección MAC AP o STA separada. El AP o STA también tiene una dirección MAC MLD para identificar el dispositivo.

La clase android.net.wifi.MloLink representa el enlace MLO. Esta clase incluye los siguientes parámetros:

  • int getLinkId() : ID del enlace anunciado por AP MLD.
  • MacAddress getApMacAddress() : dirección MAC del AP. El BSSID de la instancia AP para ese enlace.
  • MacAddress getStaMacAddress() : dirección MAC de STA. La dirección MAC asignada localmente para la instancia de STA en el enlace.
  • int getChannel() : canal de enlace. El número de canal del enlace.
  • int getBand() : Banda de enlace. La banda del enlace.

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

    • MLO_LINK_STATE_INVALID : no válido. Se utiliza para casos de inicialización y error.
    • MLO_LINK_STATE_UNASSOCIATED : No asociado. El enlace no está asociado con un AP.
    • MLO_LINK_STATE_IDLE : Inactivo. El enlace está asociado pero no activo (no hay ningún identificador de tráfico (TID) asignado al enlace).
    • MLO_LINK_STATE_ACTIVE : Activo. El enlace está asociado y activo (al menos un TID está asignado al enlace). Un enlace activo puede estar en modo de ahorro de energía porque el marco no monitorea el estado de energía del enlace.

Información escaneada de Wi-Fi 7 AP MLO

Las aplicaciones pueden obtener los parámetros MLO para un MLD de AP Wi-Fi 7 cuando el módulo 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 Wi-Fi recopila la información MLO haciendo lo siguiente:

  • Analiza el elemento de información (IE) de enlace múltiple incluido en la respuesta de baliza o sonda para leer la dirección MAC MLD del AP y el ID del enlace actual.
  • Analiza el IE del informe de vecino reducido (RNR) incluido en la respuesta de la baliza o la sonda para leer la lista de información de enlaces afiliados.

API

Para obtener información escaneada de AP MLO, las aplicaciones pueden usar las siguientes API:

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

Cuando un dispositivo se conecta a un AP-MLD Wi-Fi 7, el marco recopila los parámetros MLO de la conexión del objeto WifiInfo . El objeto AOSP WifiTracker 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 MLO del objeto ScanResult recibido del AP. Luego, el módulo llama a la API HAL ISupplicantStaIface#getConnectionMloLinksInfo() para leer las direcciones MAC de cada enlace tanto para AP como para STA, y para actualizar el estado de los enlaces asociados.

API

Para obtener información de conexión MLO, las aplicaciones pueden usar las siguientes API:

Escaneo AP-MLD

El software del proveedor proporciona al marco Wi-Fi los resultados del escaneo para cada respuesta de baliza o sonda que recibe. Esto significa que el marco Wi-Fi:

  • Puede recibir múltiples objetos ScanResults del mismo AP-MLD (porque el AP puede tener múltiples enlaces de baliza).
  • Es posible que reciba solo un conjunto parcial de los resultados de la exploración para los enlaces AP de un AP-MLD porque es posible que el firmware no reciba algunas de estas señales de enlace.

El software del proveedor informa solo los resultados del escaneo recibidos por aire y no debe crear (sintetizar artificialmente) resultados de escaneo basados ​​en enlaces anunciados por AP-MLD.

El software del proveedor debe incluir la variante básica de multienlace y RNR IE recibidos de las instancias de AP en los resultados del análisis informados. Si faltan detalles del AP afiliado en los resultados del escaneo, el software del proveedor puede enviar solicitudes de sonda multienlace (marco de solicitud de sonda que incluye un elemento de solicitud de sonda multienlace) para incluir el conjunto completo o parcial de capacidades, parámetros y elementos de operación. del AP con el AP-MLD objetivo en el marco de respuesta.

El software del proveedor puede activar el sondeo ML (utilizando la variante de solicitud de sondeo ML IE 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 utiliza el enlace AP seleccionado (enlace asociado) para la señalización. El software del proveedor puede asociarse a todos o algunos de los enlaces que admite el dispositivo.

Tras una asociación exitosa, el controlador informa ISupplicantStaIfaceCallback#onStateChanged() con el BSSID de un enlace para AP-MLD. Luego, el controlador selecciona un enlace de AP-MLD siempre que los resultados del análisis se hayan informado al marco para ese enlace.

Puntuación de red

Para dispositivos con Android 14 o superior, la selección de red Wi-Fi de Android admite Wi-Fi 7 MLO. Esto significa que Android selecciona la mejor red Wi-Fi para el dispositivo en función de la cantidad de enlaces disponibles para MLO.

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

  • Recuento máximo de enlaces STR
  • Recuento máximo de enlaces de asociación
  • Combinaciones de bandas simultáneas

Selección de red Wi-Fi MLO

Figura 2. Selección de red MLO.

La transmisión y recepción simultáneas (STR) es un esquema de contención de medio Wi-Fi para operación multienlace. El aislamiento de señal entre diferentes enlaces es suficiente para que los enlaces puedan operar de forma independiente y sean capaces de transmitir y recibir simultáneamente en diferentes enlaces. STR es diferente de la STA heredada de enlace único (SL) y de la STA heredada de doble banda y doble concurrencia (DBDC). Las STA afiliadas a una STA MLD 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 enlaces si la transmisión de múltiples enlaces tiene la misma categoría de acceso (AC).

La cantidad máxima de enlaces STR utilizados puede ser diferente de la cantidad máxima de radios admitidas por el chip. En el ejemplo de la Figura 2, el recuento máximo de enlaces STR es 2.

Las siguientes interfaces AIDL HAL admiten el recuento máximo de enlaces STR y el número máximo de capacidades de recuento de enlaces de asociación:

Se pueden operar múltiples enlaces en una sola radio usando el esquema de contención, Enhanced Multi-Link Single Radio (eMLSR). Un dispositivo multienlace utiliza eMLSR en un conjunto de enlaces si puede recibir ciertas tramas de control básicas y realizar una evaluación clara de canal (CCA) simultáneamente en el conjunto de enlaces. Sin embargo, el MLD transmite o recibe datos en un solo enlace (el enlace elegido dinámicamente en cada período de oportunidad de transmisión (TXOP)) a la vez.

Una estación MLD puede maximizar la cantidad de enlaces de asociación para una mayor confiabilidad, un mejor rendimiento y una menor latencia (en comparación con una estación heredada de un solo enlace) al operar simultáneamente en STR y eMLSR si el chip lo admite. En la Figura 2, el recuento máximo de enlaces de asociación es 3.

Las siguientes interfaces AIDL HAL admiten la capacidad máxima de recuento de enlaces de asociación:

Combinaciones de bandas simultáneas

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

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

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

Seleccion 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 rendimiento de enlaces múltiples prevista se calcula para cada grupo, en función del recuento máximo de enlaces STR y las combinaciones de bandas simultáneas admitidas por el chip. Si el candidato tiene capacidad de enlace múltiple y el chip admite STR, la puntuación de rendimiento prevista se reemplaza con la puntuación de rendimiento prevista de enlace múltiple. Esto da un impulso a los candidatos de MLO durante la selección de la red.

Al unirse a una red AP-MLD, el marco realiza la selección de SSID en función de la información recibida en el objeto ScanResults según lo informado por el software del proveedor. Tras la selección del SSID por parte del marco, el software del proveedor es responsable de seleccionar el BSSID para el mejor AP (o enlace AP) para usar en la asociación.

Manejo de la dirección MAC de STA del dispositivo

Esta sección describe cómo se manejan las direcciones MAC de STA del dispositivo (direcciones MAC de MLD y direcciones MAC de STA por enlace).

Dirección MAC MLD

El marco Wi-Fi administra la dirección MAC MLD del dispositivo. La dirección MAC MLD se maneja de la misma manera que un dispositivo que no es MLD maneja su propia dirección MAC. La dirección MAC puede ser una dirección MAC aleatoria o una dirección MAC proporcionada por hardware según la elección del usuario. La dirección MAC de MLD la establece el marco utilizando la API HAL IWifiStaIface#setMacAddress() .

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

El software del proveedor asigna direcciones MAC por enlace según su algoritmo. El algoritmo debe ser repetible y estar en función de lo siguiente:

  • Dirección MAC STA-MLD establecida por el marco Wi-Fi.
  • ID de enlace (recibido de AP)

Esto significa que si el marco reutiliza la misma dirección MAC 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 marco 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 enlace (los proveedores pueden implementar cualquier algoritmo que cumpla con los criterios del algoritmo):

  • Octeto 0: asegúrese de que el bit administrado localmente esté establecido
  • Octeto 1-4: Igual que la dirección MAC de STA-MLD
  • Octeto 5: Por STA = (STA-MLD + ID de enlace + 1) MOD (256)

El firmware del proveedor puede realizar la conmutación de enlaces y administrar el estado de ahorro de energía de los enlaces para su activación o desactivación sin intervención del marco Wi-Fi.

El marco Wi-Fi no espera una notificación cuando se cambia el estado del enlace.

Gestión del estado de ahorro de energía.

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

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

Ruta de datos

Esto describe la implementación del firmware del proveedor para manejar el tráfico de enlace ascendente y de descarga.

El firmware enruta el tráfico de enlace ascendente a uno (o más) enlaces según su implementación interna. El firmware del proveedor decide cuándo realizar el equilibrio de carga, 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 a múltiples enlaces en los siguientes casos:

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

El firmware debe reemplazar la dirección MAC (destino) por STA del encabezado MAC con la dirección MAC MLD-STA y la dirección MAC (origen) por AP del encabezado MAC con la dirección MAC MLD-AP. El firmware debe realizar esta sustitución de la dirección MAC antes de pasar por el filtro APF porque los comandos del filtro APF tienen filtros basados ​​en direcciones MAC MLD. Existe un único filtro APF para todos los enlaces de un AP-MLD.

concurrencia

Los escenarios de concurrencia, donde se utiliza una radio para una nueva interfaz, deben tener prioridad sobre la dedicación de múltiples radios para enlaces de la misma interfaz. Los escenarios de concurrencia también deben tener prioridad sobre MLO, sin importar cuál ocurrió primero. Usar múltiples enlaces para una única interfaz es oportunista, lo que significa que se usan múltiples enlaces solo cuando:

  • Se requiere MLO según la decisión del firmware para el equilibrio, agregación o duplicación de carga.
  • MLO está disponible , lo que significa que otra interfaz no requiere una radio.

Para dispositivos con Android 14 o superior, cuando el AP Wi-Fi 7 anuncia una desactivación temporal de uno de los enlaces a través de un elemento de mapeo de TID a enlace transmitido en tramas de baliza, respuesta de sonda y respuesta de asociación, el Wi-Fi 7 La estación continúa la conexión con el AP utilizando los enlaces restantes que estén configurados, sin realizar otra asociación.

Para dispositivos con Android 13 o versiones anteriores, el marco Wi-Fi no admite la recepción de notificaciones cuando el estado del enlace cambia debido a la asignación de TID a enlace, incluso si el enlace asociado no está vinculado a un TID.

El solicitante de Wi-Fi notifica al marco de Wi-Fi los cambios en el mapeo de TID a enlace a través de las siguientes interfaces AIDL:

Las aplicaciones pueden obtener información sobre los cambios en la asignación de TID a enlace mediante las siguientes API:

Para dispositivos que ejecutan Android 14 o superior, las siguientes API están disponibles para obtener las capacidades de negociación de mapas de TID a enlace para la estación y el AP.

Capacidad de chip

Las siguientes interfaces admiten la capacidad del chip para la negociación de mapeo de TID a enlace.

AIDL HAL

La interfaz AIDL para la negociación de mapeo de TID a enlace 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 el mapeo de TID a enlace. API

capacidad AP

Las siguientes interfaces admiten la capacidad AP para la negociación de mapeo de TID a enlace.

AIDL HAL

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

API

Las estadísticas de la capa de enlace incluyen detalles específicos del enlace Wi-Fi, como RSSI, varios contadores de paquetes TX y RX y estadísticas de radio. El marco Wi-Fi sondea periódicamente las estadísticas de la capa de enlace y RSSI para seleccionar la mejor red o evaluar la calidad de la red conectada. Para dispositivos con Android 14 o superior, las estadísticas de la capa de enlace incluyen compatibilidad con múltiples enlaces. Para admitir Wi-Fi 7, Android admite MLO tanto en las estadísticas de la capa de enlace como en el sondeo de señales.

Las estadísticas específicas de enlace se encuentran en las siguientes interfaces AIDL de capa de enlace:

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

Las siguientes API específicas de enlaces 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 ID de enlaces disponibles, las aplicaciones pueden llamar al método android.net.wifi.WifiUsabilityStatsEntry#getLinkIds() .

Las API en android.net.wifi.WifiUsabilityStatsEntry para un solo enlace (no MLO) devuelven las estadísticas agregadas para las conexiones MLO. El siguiente es el criterio de agregación:

  • Las siguientes estadísticas agregadas de paquetes utilizan la suma de estadísticas por enlace:

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

  • Las siguientes estadísticas utilizan los datos del enlace 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()

Para los dispositivos que ejecutan Android 13, las estadísticas de la capa de enlace no tienen en cuenta el uso de varios enlaces para una única interfaz. Para admitir MLO, el software del proveedor debe aplicar la siguiente lógica de agregación al informar LinkLayerStats a través de la API HAL IWifi# getLinkLayerStats_1_6() . El mejor enlace es el enlace con el RSSI más alto.

  • StaLinkLayerStats.iface.beaconRx : informa el recuento de balizas para el mejor enlace utilizado para la interfaz.
  • StaLinkLayerStats.iface.avgRssiMgmt : informe avgRssiMgmt para obtener el mejor enlace utilizado para la interfaz.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk): informa las estadísticas agregadas de paquetes (totales) a través de los enlaces de la interfaz.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk): informa las estadísticas de tiempo de contención para el mejor enlace utilizado en la interfaz (estadísticas de tiempo de contención más bajas).

Cuando se reutiliza uno de los enlaces del punto de acceso Wi-Fi 7, el AP puede anunciar la eliminación del enlace mediante la reconfiguración del enlace MLO. Las estaciones pueden mantener una conectividad perfecta con el AP sin una reasociación en los enlaces restantes.

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

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

El método WifiInfo#getAffiliatedMloLinks devuelve los enlaces MLO afiliados. El método MloLink#getState devuelve el estado del enlace. Si se elimina el vínculo, el estado del vínculo devuelto es MLO_LINK_STATE_UNASSOCIATED .

Estrategia de chip MLO

MLO permite que los dispositivos envíen y reciban datos en múltiples enlaces Wi-Fi al mismo tiempo, lo que puede mejorar el rendimiento de aplicaciones que tienen requisitos específicos como baja latencia, alto ancho de banda y bajo consumo. Los proveedores de chips pueden desarrollar algoritmos sobre cómo utilizar los enlaces disponibles.

Las aplicaciones privilegiadas pueden modificar estos algoritmos utilizando el método setMloMode en Wifimanager y configurar los siguientes modos:

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

El marco utiliza setMloMode en la interfaz IWifiChip AIDL para configurar el modo MLO.