Wi-Fi 7

Para dispositivos con Android 13 o versiones posteriores, Android es compatible con el estándar Wi-Fi 7 (IEEE 802.11be). En esta página, se describe el funcionamiento Funciones de Wi-Fi 7, incluidos el modelo de referencia y la operación de varios vínculos (MLO)

Funciones de Baseline Wi-Fi 7

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

Compatibilidad con dispositivos Wi-Fi 7

El framework de Android incluye las WifiManager#isWifiStandardSupported(int standard) a las que las apps pueden llamar con el 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 está 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 el comando nl80211 NL80211_CMD_GET_WIPHY. Si el botón El atributo NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY se encuentra en la respuesta del , se supone que el dispositivo es compatible con Wi-Fi 7.

Compatibilidad con Wi-Fi 7 de AP escaneada

El framework de Android incluye las int ScanResult#getWifiStandard() API, a las que las apps pueden llamar para verificar si un punto de acceso (AP) analizado sea compatible con Wi-Fi 7. Si el PA 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 apps usen esta API.

Cuando se llama a esta API, el módulo Wi-Fi comprueba si EHT Capability IE está en los resultados devueltos del análisis de conectividad. Si EHT Capability IE está en los resultados de la búsqueda, el PA escaneado admite Wi-Fi 7. La clase WifiTracker del AOSP muestra esta información de compatibilidad en el usuario cuando se ejecuta en modo detallado.

Modo de conexión de STA

El framework de Android incluye las int WifiInfo#getWifiStandard() API, a las que las apps pueden llamar para comprobar si la 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 PA conectado es compatible con Wi-Fi 7. Si el modo de conexión es Wi-Fi 7, la API devoluciones ScanResults.WIFI_STANDARD_11BE

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

Selección de red

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

En Android 13, ThroughputPredictor usa lo siguiente: 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 mejora el posibilidades de seleccionar PA compatibles con Wi-Fi 7 cuando el dispositivo pueda usar atributos.

Rango basado en Wi-Fi RTT

Android proporciona compatibilidad de API con el preámbulo EHT y el ancho de canal de 320 MHz para Wi-Fi RTT Esto permite la compatibilidad de capacidades relacionadas con Wi-Fi 7 en RTT cuando compatibles con el chip.

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 el rango basado en Wi-Fi 7 RTT:

PA secundario

Android admite Wi-Fi 7 en Soft AP y ofrece lo siguiente: atributos.

Iniciar PA secundario

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

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

APIs de HAL

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

Envía información no definitiva de AP

Android admite la API para incluir Wi-Fi 7 y ancho de canal de 320 MHz en la información de Soft AP que se informó.

APIs de HAL

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

APIs

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

Funciones de MLO Wi-Fi 7

La operación de varios vínculos (MLO) es la función principal de Wi-Fi 7 (802.11be). especificación. El MLO es una función obligatoria para dispositivos con varios vínculos (MLD) se ejecuten en Wi-Fi 7, ya sea en simultáneo o no.

Diagrama de MLO

Figura 1: Diagrama de MLO.

Como se muestra en la Figura 1, tanto AP-MLD como STA-MLD tienen varios AP o STA. las instancias 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.

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

  • int getLinkId(): Es el ID de vínculo anunciado por el MLD de AP.
  • MacAddress getApMacAddress(): Dirección MAC del AP. El BSSID de la instancia del AP de ese vínculo.
  • MacAddress getStaMacAddress(): Dirección MAC de STA. La dirección MAC asignada de forma local para la instancia de STA en el vínculo.
  • int getChannel(): Vincular canal. El número del canal del vínculo.
  • int getBand(): Correa de eslabones. La banda del eslabón.

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

    • MLO_LINK_STATE_INVALID: La información no es válida. Se usa para casos de inicialización y error.
    • MLO_LINK_STATE_UNASSOCIATED: No asociado. El vínculo no está asociado con un AP.
    • MLO_LINK_STATE_IDLE: Inactivo. El vínculo está asociado, pero no activo (sin identificador de tráfico (TID) está asignado al vínculo).
    • MLO_LINK_STATE_ACTIVE: Activa. El vínculo está asociado y activo (se asigna al menos un TID a del vínculo). Un vínculo activo puede estar en modo de ahorro de energía porque no supervisa el estado de energía del vínculo.

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

Las apps pueden obtener los parámetros del MLO para un MLD de Wi-Fi 7 AP cuando el módulo de Wi-Fi recibe un ScanResult de AP-MLD. El WifiTracker de AOSP muestra los parámetros del MLO cuando que 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 respuesta de sondeo para leer la dirección MAC de MLD de AP y el ID de vínculo actual.
  • Analiza el IE del informe de vecino reducido (RNR) incluido en la baliza o la sonda para leer la lista de información sobre los vínculos afiliados.

APIs

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

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

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

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

APIs

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

Análisis de AP-MLD

El software del proveedor proporciona el framework de Wi-Fi con los resultados de la búsqueda para para cada respuesta de sonda o baliza que recibe. Esto significa que el Wi-Fi en la nube:

  • Puede recibir varios objetos ScanResults del mismo AP-MLD (porque el AP puede tener varios vínculos de balizas).
  • Puede recibir sólo un conjunto parcial de los resultados del análisis para los enlaces de AP de un AP-MLD porque es posible que el equipo no reciba algunos de estos indicadores de vínculo .

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

El software del proveedor debe incluir la variante básica de varios vínculos y los IEs de RNR recibidos de las instancias de AP en los resultados del análisis informados. Si está afiliado AP Si faltan detalles en los resultados del análisis, el software del proveedor puede enviar varios vínculos solicitudes de sondeo (marco de solicitud de sondeo que incluye una solicitud de sondeo de varios vínculos) elemento) 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 del AA (con la variante de solicitud de sondeo ML IE en el marco de requisitos del 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 AP seleccionado (vínculo asociado) para su indicación. El software del proveedor puede se asocian a todos o algunos de los vínculos que admite el dispositivo.

Cuando la asociación se realice correctamente, el conductor informará ISupplicantStaIfaceCallback#onStateChanged() por el BSSID de un vínculo para y el AP-MLD. Luego, el conductor selecciona un vínculo del AP-MLD proporcionado que los resultados del análisis se informaron al framework de ese vínculo.

Puntuación de red

Para dispositivos con Android 14 o versiones posteriores, haz lo siguiente: Selección de red Wi-Fi de Android sea compatible con Wi-Fi 7 MLO. Esto significa que Android selecciona Red Wi-Fi para el dispositivo según la cantidad de vínculos disponibles para MLO.

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

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

Selección de red Wi-Fi MLO

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 una operación con varios vínculos. El aislamiento de la señal entre los diferentes vínculos es suficiente. para que los enlaces funcionen de forma independiente y sean capaces de transmitir y que reciben simultáneamente en diferentes vínculos. El STR es diferente del único heredado vínculo (SL) STA y STA heredado de doble banda simultánea (DBDC). STA afiliadas con un STA MLD comparten un número de secuencia de transmisor (SN) común espacio para la transmisión de datos asignado a distintos vínculos si hay varios transmisión tienen la misma categoría de acceso (AC).

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

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

Múltiples vínculos pueden operar en una sola radio mediante el esquema de contención. Radio única de varios vínculos mejorada (eMLSR). Un dispositivo con varios vínculos usa eMLSR mediante un conjunto de vínculos si puede recibir ciertos marcos de control básicos y realizar acciones la evaluación de canales (CCA) simultáneamente en el conjunto de vínculos. Sin embargo, el MLD transmite o recibe datos en un solo vínculo (el vínculo elegido de forma dinámica en cada período de oportunidad de transmisión (TXOP) a la vez.

Una estación de MLD puede maximizar la cantidad de vínculos de asociación para mejorar mayor confiabilidad, mejor capacidad de procesamiento y menor latencia (en comparación con un solo vínculo) estación heredada) operando simultáneamente en STR y eMLSR si lo admite el chip. En la Figura 2, el recuento máximo de vínculos de asociación es 3.

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

Combinaciones simultáneas de correas

El framework consulta el chip para obtener las combinaciones de botones de selección permitidas (a través de la interfaz IWifiChip.aidl del AIDL) que pueden operar de forma simultánea De esto información, el framework deriva posibles combinaciones de bandas simultáneas. El a continuación, se muestra 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 el misma dirección MAC de MLD. La puntuación máxima prevista de la capacidad de procesamiento de varios vínculos es para cada grupo en función del recuento máximo de vínculos STR y los de correas distintas admitidas por el chip. Si el candidato admite varios vínculos y el chip admite STR, la puntuación de capacidad de procesamiento prevista se reemplaza por de capacidad de procesamiento predicada de varios vínculos. Esto impulsa a los candidatos del MLO durante la selección de la red.

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

Control de direcciones MAC de STA del dispositivo

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

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

El software del proveedor asigna direcciones MAC por vínculo en función de su algoritmo. El El algoritmo debe ser repetible y ser una función de los siguientes elementos:

  • Dirección MAC de STA-MLD establecida por el framework de Wi-Fi.
  • ID del vínculo (recibido de 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. Esta garantiza que cuando el framework genere la dirección STA-MLD un SSID, las direcciones MAC por STA también son persistentes.

El siguiente es un ejemplo de algoritmo para asignar direcciones MAC de STA por vínculo (los proveedores pueden implementar cualquier algoritmo que cumpla con los criterios correspondientes):

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

El firmware del proveedor puede cambiar 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 de la red Wi-Fi en un framework de aplicaciones.

El framework de Wi-Fi no espera una notificación cuando el estado del vínculo es cambió.

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 la estado de ahorro de energía, el firmware del proveedor administra el ahorro de energía estado de los vínculos individuales en función de los patrones de tráfico y la activación de vínculos, o de desactivación de los datos.

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 ISupplicantStaIface::setPowerSave(false). Si el botón estado de ahorro de energía inhabilitado por el framework, el firmware del proveedor debe mantener al menos un vínculo activo (ahorro de energía inhabilitado). En este estado, el firmware implementación decide qué vínculo establecer.

Ruta de acceso a los datos

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

El firmware enruta el tráfico de subida a uno (o más) vínculos según su para implementarlos. El firmware del proveedor decide cuándo realizar el balanceo de cargas la duplicación o la agregación de tráfico según los patrones de tráfico. Recomendaciones el firmware duplica el tráfico a varios vínculos en los siguientes casos:

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

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

Simultaneidad

Las situaciones de simultaneidad, en las que se usa un radio para una interfaz nueva, deben tener prioridad sobre dedicar 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 se produzca antes de empezar. Usar varios vínculos para una sola interfaz es oportunista, es decir, que se usen 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 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 la Wi-Fi 7 AP anuncia la inhabilitación temporal de uno de los vínculos a través de un el elemento de asignación de TID a vínculo transmitido en la baliza, la respuesta de sondeo y de respuesta asociados, la estación de Wi-Fi 7 continúa la conexión con con los vínculos restantes configurados, sin realizar otra asociación.

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

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

Las aplicaciones pueden obtener información sobre los cambios en la asignación de TID a vínculo mediante el las siguientes APIs:

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

Capacidad del chip

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

HAL del AIDL

La interfaz del 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. El La capability T2LM_NEGOTIATION = 1 << 8 indica que el chip admite Asignación de TID a vínculo. APIs

Capacidad de punto de acceso

Las siguientes interfaces admiten la capacidad del PA para la asignación de TID a enlace la negociación de productos.

HAL del AIDL

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

APIs

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

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

El android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() La API del sistema detecta todas las estadísticas de la capa de vínculos. 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ínculo disponibles, las aplicaciones pueden llamar al android.net.wifi.WifiUsabilityStatsEntry#getLinkIds() .

APIs en android.net.wifi.WifiUsabilityStatsEntry para vínculo único (no MLO), devuelve las estadísticas agregadas de las conexiones de MLO. El estos son los criterios de agregación:

  • Las siguientes estadísticas agregadas de paquetes utilizan 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()

Estadísticas de la capa de vínculos para dispositivos que ejecutan Android 13 no tienen en cuenta la el uso de varios vínculos para una sola interfaz. Para admitir la MLO, se provee de software debe aplicar la siguiente lógica de agregación cuando se informe LinkLayerStats mediante la API de HAL de IWifi# getLinkLayerStats_1_6(). El mejor vínculo con el RSSI más alto.

  • StaLinkLayerStats.iface.beaconRx: Informa la cantidad de balizas de la mejor manera. que se usa para la interfaz.
  • StaLinkLayerStats.iface.avgRssiMgmt: Informe avgRssiMgmt para el mejor vínculo para la interfaz.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk): Informe las estadísticas agregadas de los paquetes (total) en los vínculos de la interfaz.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk): Informar las estadísticas del tiempo de contención para el mejor vínculo utilizado en el (estadísticas de tiempo de contención más bajas).

Cuando uno de los vínculos del punto de acceso Wi-Fi 7 se reutiliza, el AP puede anunciar la eliminación del vínculo mediante la reconfiguración de vínculos de la MLO. Estaciones puede mantener una conectividad sin interrupciones con AP sin una reasociación en el vínculos restantes.

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

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

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

Estrategia de MLO de chip

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

Las apps con privilegios pueden modificar estos algoritmos usando el setMloMode en Wifimanager y configura la 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 del AIDL para configurar el modo MLO.