Pour les appareils exécutant Android 13 ou version ultérieure, Android prend en charge la norme Wi-Fi 7 (IEEE 802.11be). Cette page décrit les fonctionnalités d'Android Wi-Fi 7, y compris le fonctionnement de base et multi-liens (MLO).
Fonctionnalités de base du Wi-Fi 7
Cette section décrit les fonctionnalités de base du Wi-Fi 7 incluses dans Android 13 et versions ultérieures.
Prise en charge du Wi-Fi 7 de l'appareil
Le framework Android inclut l'API WifiManager#isWifiStandardSupported(int standard)
, que les applications peuvent appeler avec l'argument ScanResults.WIFI_STANDARD_11BE
, pour vérifier si un appareil prend en charge le Wi-Fi 7.
Lorsque cette API est appelée, le module Wi-Fi vérifie si la superposition de configuration config_wifi11beSupportOverride
est utilisée comme remplacement et effectue les opérations suivantes :
- Si la superposition est définie sur
true
, l'appareil est supposé prendre en charge le Wi-Fi 7 quelle que soit la réponse de nl80211. Ce remplacement n'est utile que pour les fabricants d'appareils qui ne disposent pas de pilotes prenant en charge le Wi-Fi 7. - Si la superposition est définie sur
false
(valeur par défaut), le module Wi-Fi utilise les informations du nl80211. Le module Wi-Fi demande les informations à wificond, qui appelle la commande nl80211NL80211_CMD_GET_WIPHY
. Si l'attributNL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY
figure dans la réponse du pilote, l'appareil est supposé prendre en charge le Wi-Fi 7.
Prise en charge du point d'accès scanné Wi-Fi 7
Le framework Android inclut l'API int ScanResult#getWifiStandard()
, que les applications peuvent appeler pour vérifier si un point d'accès (AP) analysé prend en charge le Wi-Fi 7. Si le point d'accès prend en charge le Wi-Fi 7, l'API renvoie ScanResults.WIFI_STANDARD_11BE
. L'appareil n'est pas tenu de prendre en charge le Wi-Fi 7 pour que les applications utilisent cette API.
Lorsque cette API est appelée, le module Wi-Fi vérifie si EHT Capability IE
figure dans les résultats renvoyés de l'analyse de connectivité. Si EHT Capability IE
figure dans les résultats de l'analyse, le point d'accès analysé prend en charge le Wi-Fi 7. La classe AOSP WifiTracker
affiche ces informations de prise en charge dans l'interface utilisateur lors de l'exécution en mode détaillé.
Mode de connexion STA
Le framework Android inclut l'API int WifiInfo#getWifiStandard()
, que les applications peuvent appeler pour vérifier si le mode de connexion de la station actuelle (STA) est Wi-Fi 7. Le mode de connexion STA est Wi-Fi 7 lorsque l'appareil et l'appareil connecté AP prend en charge Wi-Fi 7. Si le mode de connexion est Wi-Fi 7, l'API renvoie ScanResults.WIFI_STANDARD_11BE
.
Lorsque getWifiStandard
est appelé, le module Wi-Fi détermine le mode en appelant l'API HAL ISupplicantStaIface#getConnectionCapabilities()
. L'implémentation de cette API HAL dans la couche wpa_supplicant
AIDL vérifie si EHT Capability IE
est à la fois dans AssocReq
et AssocRsp
lors de l'établissement de la connexion.
Sélection de réseau
Dans Android 13, la sélection du réseau utilise plusieurs paramètres pour déterminer à quel point d'accès se connecter. L'un des paramètres est le débit estimé du point d'accès, qui est estimé à l'aide du bloc ThroughputPredictor
. Le bloc ThroughputPredictor
utilise les paramètres PHY de l’appareil et du point d’accès analysé.
Dans Android 13, ThroughputPredictor
utilise les fonctionnalités AP suivantes dans son calcul :
- Prise en charge du Wi-Fi 7 (802.11be)
- Prise en charge d'une largeur de canal de 320 MHz
L'inclusion de ces capacités dans la logique ThroughputPredictor
augmente les chances de sélectionner des points d'accès compatibles Wi-Fi 7 lorsque l'appareil peut utiliser ces fonctionnalités.
Portée basée sur Wi-Fi RTT
Android fournit une prise en charge API pour le préambule EHT et une largeur de canal de 320 MHz pour le Wi-Fi RTT . Cela permet la prise en charge des capacités liées au Wi-Fi 7 dans la plage RTT chaque fois qu'elles sont prises en charge par la puce.
API HAL
Les API HAL suivantes prennent en charge les fonctionnalités Wi-Fi 7 pour la télémétrie basée sur RTT :
-
EHT
: Constante dansenum RttPreamble
etenum WifiRatePreamble
-
WIDTH_320
: Constante dansenum WifiChannelWidthInMhz
-
BW_320MHz
: Constante dansenum RttBw
Apis
Les applications peuvent utiliser les API suivantes pour la télémétrie basée sur Wi-Fi 7 RTT :
-
ScanResult#PREAMBLE_EHT
-
ResponderConfig#PREAMBLE_EHT
(SystemApi)
AP souple
Android prend en charge le Wi-Fi 7 dans Soft AP et offre les fonctionnalités suivantes.
Démarrer l'AP logiciel
Android prend en charge le démarrage de Soft AP en mode Wi-Fi 7. Ceci est régi par la configuration de superposition config_wifiSoftapIeee80211beSupported
.
Le module Wi-Fi utilise la superposition config_wifiSoftapIeee80211beSupported
pour définir le booléen HwModeParams#enable80211BE
dans l'appel API IHostApd#addAccessPoint()
. Dans la couche hostapd AIDL, cette valeur est utilisée pour définir les paramètres hostapd.conf
.
API HAL
Le booléen enable80211BE
dans HwModeParams
dans hostapd HAL prend en charge le démarrage de Soft AP en mode Wi-Fi 7.
Signaler les informations sur le point d'accès logiciel
Android inclut la prise en charge de l'API pour inclure les informations sur la largeur des canaux Wi-Fi 7 et 320 MHz dans les informations Soft AP signalées.
API HAL
La constante WIFI_STANDARD_11BE
dans l'interface Generation.aidl
AIDL dans le HAL hostapd, qui est utilisée dans l' ApInfo
signalé dans le rappel IHostapdCallback#onApInstanceInfoChanged()
, prend en charge la génération de rapports sur les informations Soft AP.
Apis
Les applications peuvent utiliser les méthodes suivantes (API système) dans SoftApInfo
pour signaler les informations Soft AP.
-
SoftApInfo#getWifiStandard()
: renvoieScanResults.WIFI_STANDARD_11BE
si le Soft AP est démarré en mode Wi-Fi 7. -
SoftApInfo#getBandwidth()
: renvoieSoftApInfo#CHANNEL_WIDTH_320MHZ
si la largeur de canal de 320 MHz est utilisée.
Fonctionnalités MLO Wi-Fi 7
Le fonctionnement multi-liens (MLO) est la fonctionnalité principale de la spécification Wi-Fi 7 (802.11be). MLO est une fonctionnalité obligatoire pour les appareils multi-liens (MLD) fonctionnant en Wi-Fi 7, que ce soit simultanément ou non.
Figure 1. Diagramme MLO.
Comme le montre la figure 1, AP-MLD et STA-MLD disposent de plusieurs instances AP ou STA exécutées sur chaque liaison. Chaque lien possède une adresse MAC AP ou STA distincte. L'AP ou la STA dispose également d'une adresse MAC MLD pour identifier l'appareil.
Représentation du lien MLO
La classe android.net.wifi.MloLink
représente le lien MLO. Cette classe comprend les paramètres suivants :
-
int getLinkId()
: ID de lien tel qu'annoncé par l'AP MLD. -
MacAddress getApMacAddress()
: adresse MAC du point d'accès. Le BSSID de l'instance AP pour ce lien. -
MacAddress getStaMacAddress()
: adresse MAC STA. Adresse MAC attribuée localement pour l'instance STA sur le lien. -
int getChannel()
: canal de lien. Le numéro de canal du lien. -
int getBand()
: Bande de lien. La bande du lien. int getState()
: état du lien. Il peut s'agir de l'un des états suivants :-
MLO_LINK_STATE_INVALID
: invalide. Utilisé pour les cas d'initialisation et d'erreur. -
MLO_LINK_STATE_UNASSOCIATED
: non associé. Le lien n'est pas associé à un point d'accès. -
MLO_LINK_STATE_IDLE
: Inactif. Le lien est associé mais n'est pas actif (aucun identifiant de trafic (TID) n'est mappé au lien). -
MLO_LINK_STATE_ACTIVE
: Actif. Le lien est associé et actif (au moins un TID est mappé au lien). Un lien actif peut être en mode d’économie d’énergie car l’infrastructure ne surveille pas l’état d’alimentation du lien.
-
Informations MLO du point d'accès Wi-Fi 7 analysées
Les applications peuvent obtenir les paramètres MLO pour un AP MLD Wi-Fi 7 lorsque le module Wi-Fi reçoit un objet ScanResult
de l'AP-MLD. L'AOSP WifiTracker
affiche les paramètres MLO lors de l'exécution en mode détaillé.
Le module Wi-Fi collecte les informations MLO en procédant comme suit :
- Analyse l'élément d'information multi-liens (IE) inclus dans la réponse de la balise ou de la sonde pour lire l'adresse MAC AP MLD et l'ID de lien actuel.
- Analyse l'IE du rapport de voisin réduit (RNR) inclus dans la réponse de la balise ou de la sonde pour lire la liste des informations sur les liens affiliés.
Apis
Pour obtenir des informations AP MLO analysées, les applications peuvent utiliser les API suivantes :
-
ScanResult#BSSID
: L'adresse MAC de l'instance AP (pour le lien sur lequel le résultat de l'analyse est reçu) -
MacAddress ScanResult#getApMldMacAddress()
: renvoie l'adresse MAC MLD du point d'accès. -
int ScanResult#getApMloLinkId()
: renvoie l'ID du lien sur lequel le ScanResult a été reçu. -
List<MloLink> ScanResult#getAffiliatedMloLinks()
: renvoie une liste d'objetsMloLink
pour tous les liens annoncés par l'AP-MLD, y compris le lien sur lequel le ScanResult a été reçu.
Informations sur le MLO du point d'accès Wi-Fi 7 connecté
Lorsqu'un appareil se connecte à un AP-MLD Wi-Fi 7, le framework collecte les paramètres MLO de la connexion à partir de l'objet WifiInfo
. L'objet AOSP WifiTracker
affiche ces informations lors de l'exécution en mode détaillé.
Lorsque l'appareil se connecte à l'AP-MLD, le module Wi-Fi copie les informations MLO de l'objet ScanResult
reçu de l'AP. Le module appelle ensuite l'API HAL ISupplicantStaIface#getConnectionMloLinksInfo()
pour lire les adresses MAC de chaque lien pour AP et STA, et pour mettre à jour l'état des liens associés.
Apis
Pour obtenir des informations de connexion MLO, les applications peuvent utiliser les API suivantes :
-
WifiInfo#getBSSID()
: Renvoie l'adresse MAC de l'instance AP (pour le lien sur lequel l'appareil est associé). -
MacAddress WifiInfo#getApMldMacAddress()
: renvoie l'adresse MAC MLD du point d'accès. -
int WifiInfo#getApMloLinkId()
: renvoie l'ID de lien pour le lien sur lequel la STA s'est associée à l'AP. -
List<MloLink> WifiInfo#getAffiliatedMloLinks()
: renvoie une liste d'objetsMloLink
pour tous les liens annoncés par l'AP-MLD, y compris le lien associé. Les adresses MAC AP et STA peuvent être interrogées sur chaque objetMloLink
.
Analyse AP-MLD
Le logiciel du fournisseur fournit au cadre Wi-Fi les résultats d'analyse pour chaque réponse de balise ou de sonde qu'il reçoit. Cela signifie que le cadre Wi-Fi :
- Peut recevoir plusieurs objets
ScanResults
du même AP-MLD (car l'AP peut avoir plusieurs liens de balisage). - Peut recevoir uniquement un ensemble partiel des résultats d'analyse pour les liaisons AP d'un AP-MLD, car certains de ces signaux de liaison peuvent ne pas être reçus par le micrologiciel.
Le logiciel du fournisseur rapporte uniquement les résultats d'analyse reçus par voie hertzienne et ne doit pas créer (synthétiser artificiellement) des résultats d'analyse basés sur des liens annoncés par l'AP-MLD.
Le logiciel du fournisseur doit inclure la variante de base multi-liens et les IE RNR reçus des instances AP dans les résultats d'analyse rapportés. Si les détails du point d'accès affilié sont manquants dans les résultats de l'analyse, le logiciel du fournisseur peut envoyer des demandes de sonde multi-liens (une trame de demande de sonde qui comprend un élément multi-liens de demande de sonde) pour inclure l'ensemble complet ou partiel de capacités, de paramètres et d'éléments de fonctionnement. de l'AP avec l'AP-MLD ciblé dans la trame de réponse.
Le logiciel du fournisseur peut déclencher une vérification ML (en utilisant la variante de demande de sonde ML IE dans la trame de demande de sonde) si nécessaire.
Association réseau AP-MLD
Lorsqu'un appareil rejoint un réseau AP-MLD, le logiciel du fournisseur utilise le lien AP sélectionné (lien associé) pour la signalisation. Le logiciel du fournisseur peut s'associer à tout ou partie des liens pris en charge par l'appareil.
En cas d'association réussie, le pilote signale ISupplicantStaIfaceCallback#onStateChanged()
avec le BSSID d'un lien pour l'AP-MLD. Le pilote sélectionne ensuite un lien de l'AP-MLD à condition que les résultats de l'analyse aient été signalés au framework pour ce lien.
Notation du réseau
Pour les appareils exécutant Android 14 ou version ultérieure, Android Wi-Fi Network Selection prend en charge Wi-Fi 7 MLO. Cela signifie qu'Android sélectionne le meilleur réseau Wi-Fi pour l'appareil en fonction du nombre de liens disponibles pour MLO.
Pour prendre en charge MLO, l'algorithme de sélection de réseau utilise les capacités MLO suivantes de la puce Wi-Fi :
- Nombre maximal de liens STR
- Nombre maximal de liens d'association
- Combinaisons de bandes simultanées
Figure 2. Sélection du réseau MLO.
Nombre maximal de liens STR
La transmission et la réception simultanées (STR) sont un système de contention de support Wi-Fi pour un fonctionnement multi-liens. L'isolation du signal entre les différentes liaisons est suffisante pour que les liaisons puissent fonctionner indépendamment et soient capables de transmettre et de recevoir simultanément sur différentes liaisons. STR est différent de l'ancienne STA à liaison unique (SL) et de l'ancienne STA double bande double simultanée (DBDC). Les STA affiliées à un STA MLD partagent un numéro de séquence d'émetteur (SN) commun et un espace commun pour la transmission de données attribué à différentes liaisons si la transmission de plusieurs liaisons a la même catégorie d'accès (AC).
Le nombre maximum de liens STR utilisés peut être différent du nombre maximum de radios supportées par la puce. Dans l'exemple de la figure 2, le nombre maximum de liens STR est de 2.
Les interfaces AIDL HAL suivantes prennent en charge le nombre maximal de liens STR et le nombre maximal de capacités de nombre de liens d'association :
hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl
hardware/interfaces/wifi/aidl/android/hardware/wifi/WifiChipCapabilities.aidl
Nombre maximal de liens d'association
Plusieurs liaisons peuvent fonctionner sur une seule radio à l’aide du schéma de contention Enhanced Multi-Link Single Radio (eMLSR). Un appareil multiliaison utilise eMLSR sur un ensemble de liaisons s'il peut recevoir certaines trames de contrôle de base et effectuer simultanément une évaluation de canal clair (CCA) sur l'ensemble de liaisons. Cependant, le MLD transmet ou reçoit des données sur une seule liaison (la liaison choisie dynamiquement dans chaque période d'opportunité de transmission (TXOP)) à la fois.
Une station MLD peut maximiser le nombre de liens d'association pour une meilleure fiabilité, un meilleur débit et une latence plus faible (par rapport à une station existante à liaison unique) en fonctionnant simultanément en STR et eMLSR si elle est prise en charge par la puce. Dans la figure 2, le nombre maximum de liens d’association est de 3.
Les interfaces AIDL HAL suivantes prennent en charge la capacité maximale de nombre de liens d'association :
hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl
hardware/interfaces/wifi/aidl/android/hardware/wifi/WifiChipCapabilities.aidl
Combinaisons de bandes simultanées
Le framework interroge la puce pour obtenir les combinaisons radio autorisées (via l'interface IWifiChip.aidl
AIDL) qui peuvent fonctionner simultanément. À partir de ces informations, le cadre dérive d’éventuelles combinaisons de bandes simultanées. Voici un exemple de liste de combinaisons de bandes simultanées (GHz) :
- 2.4
- 5
- 6
- 2,4 x 5
- 2,4 x 6
- 5x6
L'interface AIDL HAL suivante prend en charge les combinaisons radio simultanées :
hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl
Sélection de réseau
Lors de la sélection du réseau (MLO), la liste des candidats est regroupée par membres ayant la même adresse MAC MLD. Le score de débit multi-liens maximum prévu est calculé pour chaque groupe, sur la base du nombre maximum de liens STR et des combinaisons de bandes simultanées prises en charge par la puce. Si le candidat est compatible multi-liens et que la puce prend en charge STR, le score de débit prédit est remplacé par le score de débit prédit multi-liens. Cela donne un coup de pouce aux candidats MLO lors de la sélection du réseau.
Lors de la connexion à un réseau AP-MLD, l'infrastructure effectue la sélection du SSID en fonction des informations reçues dans l'objet ScanResults
, telles que rapportées par le logiciel du fournisseur. Lors de la sélection du SSID par le framework, le logiciel du fournisseur est responsable de la sélection du BSSID pour le meilleur AP (ou lien AP) à utiliser pour l'association.
Gestion des adresses MAC STA de l'appareil
Cette section décrit comment les adresses MAC STA des appareils (adresses MAC MLD et adresses MAC STA par liaison) sont gérées.
Adresse MAC MLD
Le framework Wi-Fi gère l'adresse MAC MLD de l'appareil. L'adresse MAC MLD est gérée de la même manière qu'un périphérique non MLD gère sa propre adresse MAC. L'adresse MAC peut être une adresse MAC aléatoire ou une adresse MAC fournie par le matériel en fonction du choix de l'utilisateur. L'adresse MAC MLD est définie par le framework à l'aide de l'API HAL IWifiStaIface#setMacAddress()
.
Adresse MAC STA par lien
Le logiciel du fournisseur gère les adresses MAC STA des instances (pour chaque lien). Lorsqu'un appareil s'associe à un point d'accès, le logiciel du fournisseur attribue une adresse MAC d'instance pour chaque lien associé.
Le logiciel du fournisseur attribue des adresses MAC par liaison en fonction de son algorithme. L'algorithme doit être reproductible et être fonction des éléments suivants :
- Adresse MAC STA-MLD définie par le framework Wi-Fi.
- ID de lien (reçu d'AP)
Cela signifie que si le framework réutilise la même adresse MAC MLD, le fournisseur doit réutiliser les mêmes adresses MAC par instance associées, et vice versa. Cela garantit que lorsque l'adresse STA-MLD générée par le framework est persistante pour un SSID, les adresses MAC par STA sont également persistantes.
Ce qui suit est un exemple d'algorithme pour l'attribution d'adresses MAC STA par liaison (les fournisseurs peuvent implémenter n'importe quel algorithme répondant aux critères de l'algorithme) :
- Octet 0 : assurez-vous que le bit administré localement est défini
- Octet 1-4 : identique à l'adresse MAC STA-MLD
- Octet 5 : Par-STA = (STA-MLD + ID de lien + 1) MOD (256)
Gestion multi-liens
Le micrologiciel du fournisseur peut effectuer une commutation de liaison et gérer l'état d'économie d'énergie des liaisons pour l'activation ou la désactivation sans intervention de la structure Wi-Fi.
Le framework Wi-Fi n'attend pas de notification lorsque l'état de la liaison est modifié.
Gestion de l'état d'économie d'énergie
L'état d'économie d'énergie est activé par défaut sur le framework Wi-Fi. En état d'économie d'énergie, le micrologiciel du fournisseur gère l'état d'économie d'énergie des liaisons individuelles en fonction des modèles de trafic et des décisions d'activation ou de désactivation des liaisons.
Cependant, la structure Wi-Fi peut forcer la désactivation de l’état d’économie d’énergie en appelant l’API HAL ISupplicantStaIface::setPowerSave(false)
. Si l'état d'économie d'énergie est désactivé par le framework, le micrologiciel du fournisseur doit conserver au moins un lien actif (économie d'énergie désactivée). Dans cet état, l'implémentation du micrologiciel décide quel lien est défini.
Chemin de données
Ceci décrit l'implémentation du micrologiciel du fournisseur pour gérer le trafic de liaison montante et de téléchargement.
Trafic de liaison montante
Le micrologiciel achemine le trafic de liaison montante vers une (ou plusieurs) liaisons en fonction de sa mise en œuvre interne. Le micrologiciel du fournisseur décide quand effectuer l’équilibrage de charge, la duplication ou l’agrégation du trafic en fonction des modèles de trafic. Nous recommandons de dupliquer le trafic du micrologiciel vers plusieurs liens dans les cas suivants :
- Lorsque le mode à faible latence est défini via l'API HAL
IWifiChip#setLatencyMode()
. - Lorsqu'il y a du trafic avec la priorité utilisateur 6 et 7.
Trafic descendant
Le micrologiciel doit remplacer l'adresse MAC (de destination) par STA de l'en-tête MAC par le MAC MLD-STA et l'adresse MAC (source) par AP de l'en-tête MAC par l'adresse MAC MLD-AP. Le micrologiciel doit effectuer cette substitution d'adresse MAC avant de passer par le filtre APF car les commandes de filtre APF ont des filtres basés sur les adresses MAC MLD. Il existe un seul filtre APF pour tous les liens d'un AP-MLD.
Concurrence
Les scénarios de concurrence, dans lesquels une radio est utilisée pour une nouvelle interface, doivent avoir la priorité sur la dédiation de plusieurs radios pour les liens de la même interface. Les scénarios de concurrence doivent également avoir la priorité sur le MLO, quel que soit celui qui arrive en premier. L'utilisation de plusieurs liens pour une seule interface est opportuniste, ce qui signifie que plusieurs liens ne sont utilisés que lorsque :
- MLO est requis en fonction de la décision du micrologiciel pour l'équilibrage de charge, l'agrégation ou la duplication.
- MLO est disponible , ce qui signifie qu'une radio n'est pas requise par une autre interface.
Mappage TID-lien
Pour les appareils exécutant Android 14 ou version ultérieure, lorsque le point d'accès Wi-Fi 7 annonce une désactivation temporaire de l'un des liens via un élément de mappage TID-lien transmis dans les trames de balise, de réponse de sonde et de réponse d'association, le Wi-Fi 7 La station continue la connexion avec l'AP en utilisant les liaisons restantes établies, sans effectuer une autre association.
Pour les appareils exécutant Android 13 ou une version antérieure, la structure Wi-Fi ne prend pas en charge la réception de notifications lorsque l'état du lien est modifié en raison du mappage TID-lien, même si le lien associé n'est pas lié à un TID.
AIDL HAL
Le demandeur Wi-Fi notifie au framework Wi-Fi les modifications du mappage TID-lien via les interfaces AIDL suivantes :
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
Les applications peuvent obtenir des informations sur les modifications du mappage TID-lien à l'aide des API suivantes :
-
ConnectivityManager.NetworkCallback.onCapabilitiesChanged()
: rappel réseau déclenché par le framework en cas de changement de mappage TID-lien. -
WifiInfo#getAssociatedMloLinks()
: Renvoie les liens MLO associés. -
MloLink#getState()
: Renvoie l'état du lien,MLO_LINK_STATE_ACTIVE
ouMLO_LINK_STATE_IDLE
.
Capacités de négociation de mappage TID à lien
Pour les appareils exécutant Android 14 ou version ultérieure, les API suivantes sont disponibles pour obtenir les capacités de négociation de carte TID-lien pour la station et le point d'accès.
Capacité de la puce
Les interfaces suivantes prennent en charge la capacité de la puce pour la négociation de mappage TID-lien.
AIDL HAL
L'interface AIDL pour la négociation de mappage TID-lien se trouve dans FeatureSetMask
dans hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl
. La capacité T2LM_NEGOTIATION = 1 << 8
indique que la puce prend en charge le mappage TID-lien. Apis
-
WifiManager.isTidToLinkMappingNegotiationSupported()
: renvoie la puce qui prend en charge la négociation de mappage TID-lien.
Capacité AP
Les interfaces suivantes prennent en charge la capacité AP pour la négociation de mappage TID-lien.
AIDL HAL
Le framework interroge la capacité AP auprès du demandeur ainsi que la capacité de connexion actuelle.
-
apTidToLinkMapNegotiationSupported
: vérifie si un point d'accès prend en charge la capacité de négociation de carte TID-à-lien.
Apis
-
WifiInfo.isApTidToLinkMappingNegotiationSupported()
: indique si AP prend en charge la négociation de mappage TID-lien.
Statistiques de la couche de liaison
Les statistiques de la couche de liaison incluent des détails spécifiques à la liaison Wi-Fi tels que RSSI, divers compteurs de paquets TX et RX et des statistiques radio. Le cadre Wi-Fi interroge périodiquement les statistiques de la couche de liaison et le RSSI pour sélectionner le meilleur réseau ou pour évaluer la qualité du réseau connecté. Pour les appareils exécutant Android 14 ou version ultérieure, les statistiques de la couche de liaison incluent la prise en charge multi-liens. Pour prendre en charge le Wi-Fi 7, Android prend en charge MLO dans les statistiques de la couche de liaison et dans l'interrogation du signal.
Les statistiques spécifiques aux liens se trouvent dans les interfaces AIDL de couche liaison suivantes :
-
hardware/interfaces/wifi/aidl/android/hardware/wifi/StaLinkLayerIfaceStats.aidl
-
hardware/interfaces/wifi/aidl/android/hardware/wifi/StaLinkLayerLinkStats.aidl
L'API système android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener()
écoute toutes les statistiques de la couche de liaison. Le framework appelle périodiquement cette API pour mettre à jour les statistiques d'utilisation du Wi-Fi.
Les API spécifiques aux liens suivantes sont disponibles dans 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)
Pour interroger les ID de lien disponibles, les applications peuvent appeler la méthode android.net.wifi.WifiUsabilityStatsEntry#getLinkIds()
.
Les API dans android.net.wifi.WifiUsabilityStatsEntry
pour un lien unique (et non MLO) renvoient les statistiques agrégées pour les connexions MLO. Voici les critères d'agrégation :
Les statistiques de paquets agrégées suivantes utilisent la somme des statistiques par lien :
public long getTotalTxSuccess() public long getTotalTxRetries() public long getTotalTxBad() public long getTotalRxSuccess() public int getRxLinkSpeedMbps()
Les statistiques suivantes utilisent les données du lien avec le RSSI le plus élevé :
public int getRssi() public int getLinkSpeedMbps() public long getTotalBeaconRx() public int getTimeSliceDutyCycleInPercent() public ContentionTimeStats getContentionTimeStats(@WmeAccessCategory int ac) public List<RateStats> getRateStats()
Statistiques de la couche de liaison dans Android 13
Pour les appareils exécutant Android 13, les statistiques de la couche de liaison ne prennent pas en compte l'utilisation de plusieurs liens pour une seule interface. Pour prendre en charge MLO, le logiciel du fournisseur doit appliquer la logique d'agrégation suivante lors du rapport LinkLayerStats
via l'API HAL IWifi# getLinkLayerStats_1_6()
. Le meilleur lien est celui ayant le RSSI le plus élevé.
-
StaLinkLayerStats.iface.beaconRx
: rapporte le nombre de balises pour le meilleur lien utilisé pour l'interface. -
StaLinkLayerStats.iface.avgRssiMgmt
: RapportavgRssiMgmt
pour le meilleur lien utilisé pour l'interface. -
StaLinkLayerStats.iface.wmeXxPktStats
(Xx = Vo, Vi, Be,Bk) : rapporte les statistiques agrégées des paquets (total) sur les liens de l'interface. -
StaLinkLayerStats.iface.wmeXxContentionTimeStats
(Xx = Vo, Vi, Be,Bk) : signale les statistiques de temps de contention pour le meilleur lien utilisé sur l'interface (statistiques de temps de contention les plus basses).
Reconfiguration du lien MLO
Lorsqu'un des liens du point d'accès Wi-Fi 7 est réutilisé, le point d'accès peut annoncer la suppression du lien via la reconfiguration du lien MLO. Les stations peuvent maintenir une connectivité transparente avec le point d'accès sans réassociation sur les liaisons restantes.
L'interface AIDL onMloLinksInfoChanged
, située dans le demandeur Wi-Fi à l' ISupplicantStaIfaceCallback.aidl
, prend en charge la reconfiguration du lien (suppression AP du lien).
Lorsque la structure Wi-Fi traite la suppression d'un lien, l'état du lien est défini sur MLO_LINK_STATE_UNASSOCIATED
. Le framework déclenche ensuite ConnectivityManager.NetworkCallback#onCapabilitiesChanged()
pour un changement d’état de lien.
La méthode WifiInfo#getAffiliatedMloLinks
renvoie les liens MLO affiliés. La méthode MloLink#getState
renvoie l'état du lien. Si le lien est supprimé, l'état du lien renvoyé est MLO_LINK_STATE_UNASSOCIATED
.
Stratégie MLO de puce
MLO permet aux appareils d'envoyer et de recevoir des données sur plusieurs liaisons Wi-Fi en même temps, ce qui peut améliorer les performances des applications ayant des exigences spécifiques telles qu'une faible latence, une bande passante élevée et une faible consommation. Les fournisseurs de puces peuvent développer des algorithmes sur la manière d'utiliser les liens disponibles.
Les applications privilégiées peuvent modifier ces algorithmes à l'aide de la méthode setMloMode
dans Wifimanager
et définir les modes suivants :
-
MLO_MODE_DEFAULT = 0
-
MLO_MODE_LOW_LATENCY = 1
-
MLO_MODE_HIGH_THROUGHPUT = 2
-
MLO_MODE_LOW_POWER = 3
Le framework utilise setMloMode
dans l'interface IWifiChip
AIDL pour définir le mode MLO.