Wi-Fi 7

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 nl80211 NL80211_CMD_GET_WIPHY . Si l'attribut NL80211_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 :

Apis

Les applications peuvent utiliser les API suivantes pour la télémétrie basée sur Wi-Fi 7 RTT :

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.

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.

Diagramme MLO

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.

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 :

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 :

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

Sélection du réseau Wi-Fi MLO

Figure 2. Sélection du réseau MLO.

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 :

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 :

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 :

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() .

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)

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.

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.

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.

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.

Le demandeur Wi-Fi notifie au framework Wi-Fi les modifications du mappage TID-lien via les interfaces AIDL suivantes :

Les applications peuvent obtenir des informations sur les modifications du mappage TID-lien à l'aide des API suivantes :

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

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.

Apis

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 :

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()

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 : Rapport avgRssiMgmt 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).

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.