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 nl80211NL80211_CMD_GET_WIPHY
. Si el botón El atributoNL80211_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:
EHT
: Constante enenum RttPreamble
yenum WifiRatePreamble
WIDTH_320
: Constante enenum WifiChannelWidthInMhz
BW_320MHz
: Constante enenum RttBw
APIs
Las apps pueden usar las siguientes APIs para el rango basado en Wi-Fi 7 RTT:
ScanResult#PREAMBLE_EHT
ResponderConfig#PREAMBLE_EHT
(SystemApi)
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.
SoftApInfo#getWifiStandard()
: Resultado que se muestraScanResults.WIFI_STANDARD_11BE
si el PA secundario se inicia en el modo Wi-Fi 7.SoftApInfo#getBandwidth()
: Resultado que se muestraSoftApInfo#CHANNEL_WIDTH_320MHZ
si se usa el ancho de canal de 320 MHz
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.
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.
Representación de vínculos de MLO
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:
ScanResult#BSSID
: La dirección MAC de la instancia de AP (para el vínculo en el cual se obtiene recibidos)MacAddress ScanResult#getApMldMacAddress()
: Muestra la dirección MAC de MLD del AP.int ScanResult#getApMloLinkId()
: Devuelve el ID de vínculo del vínculo en el que se recibió el ScanResult.List<MloLink> ScanResult#getAffiliatedMloLinks()
: Devuelve una lista de objetosMloLink
para todos los vínculos anunciados por el AP-MLD incluido el vínculo en el que se recibió ScanResult.
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:
WifiInfo#getBSSID()
: Devuelve la dirección MAC de la instancia de AP (para el vínculo en el cual se encuentra el asociados).MacAddress WifiInfo#getApMldMacAddress()
: Muestra la dirección MAC de MLD del AP.int WifiInfo#getApMloLinkId()
: Devuelve el ID de vínculo del vínculo en el que el STA se asoció con el AP.List<MloLink> WifiInfo#getAffiliatedMloLinks()
: Devuelve una lista de objetosMloLink
para todos los vínculos anunciados por el AP-MLD, incluido el vínculo asociado. Tanto las direcciones MAC de AP como las de STA pueden en cada objetoMloLink
.
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
Figura 2: Selección de red de MLO.
Recuento máximo de vínculos STR
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:
hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl
hardware/interfaces/wifi/aidl/android/hardware/wifi/WifiChipCapabilities.aidl
Recuento máximo 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:
hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl
hardware/interfaces/wifi/aidl/android/hardware/wifi/WifiChipCapabilities.aidl
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:
hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl
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()
.
Dirección MAC de STA por vínculo
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)
Control de varios vínculos
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.
Tráfico de enlace de subida
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,
Tráfico de enlace descendente
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.
Asignación de TID a vínculo
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.
HAL del AIDL
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:
hardware/interfaces/wifi/supplicant/aidl/android/hardware/wifi/supplicant/ISupplicantStaIfaceCallback.aidl
hardware/interfaces/wifi/supplicant/aidl/android/hardware/wifi/supplicant/ISupplicantStaIface.aidl
hardware/interfaces/wifi/supplicant/aidl/android/hardware/wifi/supplicant/MloLinksInfo.aidl
APIs
Las aplicaciones pueden obtener información sobre los cambios en la asignación de TID a vínculo mediante el las siguientes APIs:
ConnectivityManager.NetworkCallback.onCapabilitiesChanged()
: Devolución de llamada de red activada por el framework cuando hay un TID para vincular cambio en la asignación.WifiInfo#getAssociatedMloLinks()
: Muestra los vínculos de MLO asociados.MloLink#getState()
: Devuelve el estado del vínculo.MLO_LINK_STATE_ACTIVE
oMLO_LINK_STATE_IDLE
Capacidades de negociación de asignación de TID a vínculo
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
WifiManager.isTidToLinkMappingNegotiationSupported()
: Muestra el chip que admite la negociación de asignación de TID a vínculo.
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.
apTidToLinkMapNegotiationSupported
: Comprueba si un PA admite la capacidad de negociación de mapas de TID a enlace.
APIs
WifiInfo.isApTidToLinkMappingNegotiationSupported()
: Muestra si AP admite la negociación de asignación de TID a vínculo.
Estadísticas de la capa de vínculos
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:
hardware/interfaces/wifi/aidl/android/hardware/wifi/StaLinkLayerIfaceStats.aidl
hardware/interfaces/wifi/aidl/android/hardware/wifi/StaLinkLayerLinkStats.aidl
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 en Android 13
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
: InformeavgRssiMgmt
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).
Reconfiguración de vínculos de MLO
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.