Wi-Fi 7

Pour les appareils équipés d'Android 13 ou version ultérieure, Android est compatible avec la norme Wi-Fi 7 (IEEE 802.11be). Cette page décrit Android Les fonctionnalités Wi-Fi 7, y compris le mode de référence et le mode multiliaison (MLO)

Fonctionnalités Wi-Fi 7 de référence

Cette section décrit les fonctionnalités Wi-Fi 7 de base incluses dans Android 13 ou version ultérieure.

Compatibilité avec le Wi-Fi 7 de l'appareil

Le framework Android inclut WifiManager#isWifiStandardSupported(int standard) que les applications peuvent appeler ScanResults.WIFI_STANDARD_11BE pour vérifier si un appareil est compatible avec le Wi-Fi 7.

Lorsque cette API est appelée, Module Wi-Fi vérifie si la superposition de configuration config_wifi11beSupportOverride est utilisé comme forçage et effectue les opérations suivantes:

  • Si la superposition est définie sur true, l'appareil est supposé être compatible avec le Wi-Fi 7. quelle que soit la réponse de nl80211. Ce forçage n'est utile que des fabricants d'appareils qui n'ont pas de pilotes qui renvoient la prise en charge du Wi-Fi 7.
  • Si la superposition est définie sur false (valeur par défaut), le module Wi-Fi utilise les informations de nl80211. Le module Wi-Fi demande les informations à wificond, qui appelle la commande nl80211 NL80211_CMD_GET_WIPHY. Si le L'attribut NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY se trouve dans la réponse du l'appareil est supposé être compatible avec le Wi-Fi 7.

Compatibilité avec le point d'accès analysé Wi-Fi 7

Le framework Android inclut int ScanResult#getWifiStandard() que les applications peuvent appeler pour vérifier si un point d'accès analysé compatible avec le Wi-Fi 7. Si le point d'accès est compatible avec le Wi-Fi 7, l'API renvoie ScanResults.WIFI_STANDARD_11BE L'appareil n'est pas nécessaire pour être compatible avec 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 est dans les résultats renvoyés par l'analyse de connectivité. Si EHT Capability IE se trouve dans le point d'accès scanné est compatible avec le Wi-Fi 7. La classe AOSP WifiTracker affiche ces informations d'assistance dans l'utilisateur lors de l'exécution en mode détaillé.

Mode de connexion STA

Le framework Android inclut int WifiInfo#getWifiStandard() API, que les applications peuvent appeler pour vérifier si la connexion de la station actuelle (STA) est le Wi-Fi 7. Le mode de connexion STA est le Wi-Fi 7 lorsque l'appareil et le point d'accès connecté est compatible avec le Wi-Fi 7. Si le mode de connexion est Wi-Fi 7, l'API retours ScanResults.WIFI_STANDARD_11BE

Lorsque getWifiStandard est appelé, le module Wi-Fi détermine le mode en en appelant la méthode API HAL ISupplicantStaIface#getConnectionCapabilities(). La de cette API HAL dans la couche AIDL wpa_supplicant vérifie si EHT Capability IE se trouve à la fois dans AssocReq et dans AssocRsp pendant la période de configuration de la connexion.

Sélection du réseau

Sous 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, estimé à l'aide du Bloc ThroughputPredictor. La Le bloc ThroughputPredictor utilise les paramètres PHY de l'appareil et du analysé le point d'accès.

Dans Android 13, ThroughputPredictor utilise le les capacités de point d'accès suivantes dans son calcul:

  • Compatibilité avec le Wi-Fi 7 (802.11be)
  • Compatibilité avec une largeur de canal de 320 MHz

L'inclusion de ces fonctionnalités dans la logique ThroughputPredictor les chances de sélectionner des points d'accès compatibles Wi-Fi 7 lorsque l'appareil peut les utiliser caractéristiques.

Mesure des distances en fonction du DAR Wi-Fi

Android est compatible avec les API pour le préambule EHT et la largeur de canal de 320 MHz pour Texte en temps réel Wi-Fi : Cela permet la prise en charge des fonctionnalités liées au Wi-Fi 7 dans le DAR, qui varie prises en charge par la puce.

API HAL

Les API HAL suivantes sont compatibles avec les fonctionnalités Wi-Fi 7 pour la mesure de distance basée sur le DAR:

API

Les applications peuvent utiliser les API suivantes pour la mesure des distances DAR du Wi-Fi 7:

Soft AP

Android est compatible avec le Wi-Fi 7 dans Soft AP et fournit les éléments suivants : caractéristiques.

Démarrer Soft AP

Android permet de lancer Soft AP en mode Wi-Fi 7. Ce paramètre est régi par la superposition config_wifiSoftapIeee80211beSupported configuration.

Le module Wi-Fi utilise la superposition config_wifiSoftapIeee80211beSupported pour définir la valeur booléenne HwModeParams#enable80211BE dans IHostApd#addAccessPoint(). Dans la couche hostapd AIDL, cette valeur est utilisée pour définir les paramètres hostapd.conf.

API HAL

La enable80211BE booléen dans HwModeParams dans le HAL hostapd prend en charge démarre Soft AP en mode Wi-Fi 7.

Signaler des informations sur les vulnérabilités partielles

Android est compatible avec les API, y compris pour les canaux Wi-Fi 7 et 320 MHz de largeur. les informations dans les informations soft AP signalées.

API HAL

La constante WIFI_STANDARD_11BE dans Generation.aidl L'interface AIDL dans le HAL hostapd, qui est utilisée dans le ApInfo signalé dans le IHostapdCallback#onApInstanceInfoChanged() , permet de signaler les informations Soft AP.

API

Les applications peuvent utiliser les méthodes suivantes (API système) dans SoftApInfo pour signaler les informations soft AP.

MLO Wi-Fi 7 fonctionnalités

Le fonctionnement multiliaison (MLO) est la principale fonctionnalité du Wi-Fi 7 (802.11be). spécifique. La MLO est une fonctionnalité obligatoire pour les appareils multiliaisons (MLD) fonctionnant en Wi-Fi 7, que ce soit simultanément ou non simultanément.

Schéma MLO

Figure 1 : Schéma MLO.

Comme le montre la figure 1, les modules AP-MLD et STA-MLD ont tous les deux plusieurs points d'accès ou STA. qui s'exécutent sur chaque association. Chaque liaison a une adresse MAC d'accès ou de STA distincte. Le point d'accès ou la STA dispose également d'une adresse MAC MLD permettant d'identifier l'appareil.

La android.net.wifi.MloLink représente le lien MLO. Cette classe comprend les paramètres suivants:

  • int getLinkId(): ID d'association tel qu'annoncé par l'AP MLD.
  • MacAddress getApMacAddress(): adresse MAC du point d'accès. Le BSSID de l'instance du point d'accès pour cette liaison.
  • MacAddress getStaMacAddress(): Adresse MAC STA. Adresse MAC attribuée localement pour l'instance STA sur le lien.
  • int getChannel(): Associer la chaîne. Numéro de canal associé au lien.
  • int getBand(): Bracelet maillons. Bracelet du maillon.

  • int getState(): État de l'association. Les états possibles sont les suivants:

    • MLO_LINK_STATE_INVALID: Non valide. 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)) est mappée au lien).
    • MLO_LINK_STATE_ACTIVE: Actif. Le lien est associé et actif (au moins un TID est mappé sur le lien). Un lien actif peut être en mode Économie d'énergie, car le ne surveille pas l'état de puissance du lien.

Informations MLO Wi-Fi 7 AP analysées

Les applications peuvent obtenir les paramètres MLO d'un MLD Wi-Fi 7 AP lorsque le module Wi-Fi reçoit une ScanResult de l'AP-MLD. Le WifiTracker d'AOSP affiche les paramètres MLO lorsque en mode détaillé.

Le module Wi-Fi collecte les informations MLO en procédant comme suit:

  • analyse l'élément d'information multilien (IE) inclus dans la balise ; Vérifiez la réponse pour lire l'adresse MAC du point d'accès MLD et l'ID de liaison actuel.
  • Analyse l'EI du rapport de voisinage réduit (RNR) inclus dans la balise ou la sonde réponse pour lire la liste d'informations sur les liens affiliés.

API

Pour obtenir des informations sur la MLO AP, les applications peuvent utiliser les API suivantes:

Informations MLO Wi-Fi 7 AP connecté

Lorsqu'un appareil se connecte à un réseau Wi-Fi 7 AP-MLD, le framework collecte Paramètres MLO de la connexion à partir de l'objet WifiInfo. L'AOSP L'objet 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 le MLO des informations de l'objet ScanResult reçu du point d'accès. Le module appelle l'API HAL ISupplicantStaIface#getConnectionMloLinksInfo() de lire les adresses MAC de chaque liaison pour les points d'accès et les STA, et de mettre à jour l'état des liens associés.

API

Pour obtenir des informations sur la connexion MLO, les applications peuvent utiliser les API suivantes:

Analyse AP-MLD

Le logiciel du fournisseur fournit au framework Wi-Fi les résultats de la recherche pour chaque réponse reçue par la balise ou la sonde. Cela signifie que le réseau Wi-Fi framework:

  • Peut recevoir plusieurs objets ScanResults du même AP-MLD (car le point d'accès peut avoir plusieurs liens de balisage).
  • Pourrait ne recevoir qu’un ensemble partiel des résultats d’analyse pour les liens du point d’accès de un AP-MLD car certains de ces signaux de liaison peuvent ne pas être reçus par le du micrologiciel.

Le logiciel du fournisseur ne génère des rapports que sur les résultats d'analyse reçus Over The Air et ne pas créer (synthétiser artificiellement) les résultats d'analyse basés sur les liens annoncés par le module AP-MLD.

Le logiciel du fournisseur doit inclure la variante de base multilien et les IE RNR reçues des instances du point d'accès dans les résultats d'analyse signalés. Si l'organisme affilié sont manquantes dans les résultats de l'analyse, le logiciel du fournisseur peut envoyer les requêtes de vérification (trame de requête de vérification qui inclut une liaison multilien de requête de vérification) ) pour inclure l'ensemble complet ou partiel des capacités, paramètres et les éléments opérationnels du point d'accès avec l'AP-MLD ciblé dans trame de réponse.

Le logiciel du fournisseur Peut déclencher la vérification du ML (en utilisant l'IE de ML correspondant à la variante de vérification de la vérification dans le frame des requêtes de vérification) si nécessaire.

Association de réseau AP-MLD

Lorsqu'un appareil rejoint un réseau AP-MLD, le logiciel du fournisseur utilise le point d'accès sélectionné (lien associé) pour le signalement. Le logiciel du fournisseur peut associer à tout ou partie des liens pris en charge par l'appareil.

Une fois l'association effectuée, le conducteur signale ISupplicantStaIfaceCallback#onStateChanged() par le BSSID d'un lien pour le module AP-MLD. Le pilote sélectionne ensuite un lien vers l'AP-MLD à condition que les résultats de l'analyse ont été communiqués au framework pour ce lien.

Évaluation du réseau

Pour les appareils équipés d'Android 14 ou version ultérieure, Sélection du réseau Wi-Fi Android compatible avec le Wi-Fi 7 MLO. Autrement dit, Android sélectionne les meilleurs Réseau Wi-Fi de l'appareil en fonction du nombre de liens disponibles pour le MLO.

Pour prendre en charge le MLO, l'algorithme de sélection du réseau utilise le MLO suivant : 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) est un schéma de conflit de moyen Wi-Fi pour avec plusieurs liaisons. L'isolation des signaux entre les différentes liaisons est suffisante. afin que les liens puissent fonctionner de manière indépendante et soient capables de transmettre et reçoivent simultanément dans des liens différents. Le taux de conversion est différent de l'ancien link (SL) et l'ancienne DBDC (double bande) simultané. Affiliés à une STA avec un STA MLD partagent un numéro de séquence d'émetteur (SN) commun et un d'espace pour la transmission de données alloué à différentes liaisons si plusieurs liaisons ont la même catégorie d'accès (AC).

Le nombre maximal de liens STR utilisés peut être différent du nombre maximal compatibles avec la puce. Dans l'exemple de la figure 2, le STR maximal le nombre de liens est de 2.

Les interfaces HAL AIDL suivantes acceptent le nombre maximal de liens STR et nombre maximal de liens d'association:

Plusieurs liens peuvent fonctionner sur une même radio en utilisant le système de contention, Enhanced Multi-Link Single Radio (eMLSR) Un appareil multiliaison utilise la norme eMLSR s'il peut recevoir certaines trames de contrôle de base et effectuer d'évaluation de la chaîne simultanément sur l'ensemble de liens. Toutefois, le MLD transmet ou reçoit des données sur une seule liaison (la liaison choisie dynamiquement lors de chaque période d'opportunité de transmission (TXOP)) à la fois.

Une station de MLD peut maximiser le nombre de liens d'association pour mieux plus fiable, un meilleur débit et une latence plus faible (par rapport à une liaison l'ancienne station) en opérant simultanément dans STR et eMLSR si la d'un chip. Dans la figure 2, le nombre maximal de liens d'association est de 3.

Les interfaces AIDL HAL suivantes acceptent le nombre maximal de liens d'association capacité:

Combinaisons de bandes simultanées

Le framework interroge la puce pour obtenir les combinaisons radio autorisées (via l'interface AIDL IWifiChip.aidl) qui peuvent fonctionner simultanément. Source : informations, le framework dérive les combinaisons de bandes simultanées possibles. La Voici un exemple de liste de combinaisons de bandes simultanées (GHz):

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

L'interface HAL AIDL suivante accepte les combinaisons radio simultanées:

Sélection du réseau

Lors de la sélection du réseau (MLO), la liste des candidats est regroupée par membres avec le paramètre la même adresse MAC MLD. Le score de débit multiliaison maximal prévu est calculé pour chaque groupe, en fonction du nombre maximal de liens STR et des impressions simultanées combinaisons de bandes prises en charge par la puce. Si le candidat est compatible avec plusieurs liaisons et que la puce est compatible avec STR, le score de débit prédit est remplacé par le le score de débit prévu pour plusieurs liaisons. Cela donne un coup de pouce aux candidats à la MLO lors de la sélection du réseau.

Lorsque vous rejoignez un réseau AP-MLD, le framework effectue la sélection du SSID en fonction sur la base des informations reçues dans l'objet ScanResults tel que signalé par le fournisseur logiciels. Lors de la sélection du SSID par le framework, le logiciel du fournisseur est responsable de la sélection du BSSID du meilleur point d'accès (ou liaison du point d'accès) à 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 les 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. MAC MLD est gérée de la même manière qu'un appareil non MLD gère sa propre adresse MAC. L'adresse MAC peut être une adresse MAC aléatoire ou une adresse MAC provisionnée matérielle en fonction du choix de l'utilisateur. L'adresse MAC du MLD est définie par le framework à l'aide de l'API HAL IWifiStaIface#setMacAddress().

Le logiciel du fournisseur gère les adresses MAC des instances STA (pour chaque liaison). Lorsqu'un associe un appareil à 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. La L'algorithme doit être reproductible et être une fonction des éléments suivants:

  • Adresse MAC STA-MLD définie par le framework Wi-Fi.
  • ID de lien (reçu de l'AP)

Cela signifie que si le framework réutilise la même adresse MAC MLD, le fournisseur doivent réutiliser les mêmes adresses MAC associées par instance, et inversement. Ce garantit que, lorsque l'adresse STA-MLD générée par le framework est persistante un SSID, les adresses MAC par STA sont également persistantes.

Voici un exemple d'algorithme pour l'attribution d'adresses MAC STA par liaison (les fournisseurs peuvent implémenter n'importe quel algorithme qui répond aux critères de l'algorithme):

  • Octet 0: Assurez-vous que le bit administré localement est défini
  • Du 1er au 4 oct. : Identique à l'adresse MAC STA-MLD
  • 5 octobre: par STA = (STA-MLD + ID de lien + 1) MOD (256)

Le micrologiciel du fournisseur peut changer de liaison et gérer l'état d'économie d'énergie des liens pour l'activation ou la désactivation sans l'intervention du Wi-Fi. d'infrastructure.

Le framework Wi-Fi ne s'attend pas à recevoir 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 dans le framework Wi-Fi. Dans l'état d'économie d'énergie, le micrologiciel du fournisseur gère l'économie d'énergie l'état des liens individuels en fonction des tendances du trafic et de leur activation ou les décisions de désactivation.

Cependant, le framework Wi-Fi peut forcer la désactivation de l'état d'économie d'énergie en appeler l'API HAL ISupplicantStaIface::setPowerSave(false) ; Si le l'état d'économie d'énergie est désactivé par le framework, le micrologiciel du fournisseur doit maintenir au moins un lien actif (mode d'économie d'énergie désactivé). Dans cet état, le micrologiciel détermine quelle association est définie.

Chemin d'accès aux données

Ceci décrit l’implémentation du micrologiciel du fournisseur pour gérer les liaisons montantes et le trafic de téléchargement.

Le micrologiciel achemine le trafic de liaison montante vers une ou plusieurs liaisons en fonction de ses la mise en œuvre. Le micrologiciel du fournisseur décide du moment où effectuer l'équilibrage de charge, la duplication ou l'agrégation du trafic en fonction des modèles de trafic. Nous vous recommandons du micrologiciel duplique le trafic vers plusieurs liens dans les cas suivants:

  • Lorsque le mode à faible latence est défini via IWifiChip#setLatencyMode() API HAL.
  • Lorsque du trafic est associé aux priorités 6 et 7 de l'utilisateur.

Le micrologiciel doit remplacer l'adresse MAC (de destination) par STA de l'adresse MAC en-tête avec l'adresse MAC MLD-STA et l'adresse MAC (source) par point d'accès 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 le Les commandes de filtre APF ont des filtres basés sur les adresses MAC MLD. Il n'y a qu'un seul filtre APF pour toutes les liaisons d'un AP-MLD.

Simultanéité

Les scénarios de simultanéité, dans lesquels un signal radio est utilisé pour une nouvelle interface, doivent avoir plutôt que de consacrer plusieurs radios pour les liens de la même interface. Les scénarios de simultanéité doivent aussi être prioritaires sur la MLO, quelle que soit leur origine en premier. L'utilisation de plusieurs liens pour une même interface est opportuniste, ce qui signifie que plusieurs liens ne sont utilisés que dans les cas suivants:

  • La MLO est requise en fonction du micrologiciel choisi pour l'équilibrage de charge, l'agrégation ou la duplication.
  • La MLO est disponible, ce qui signifie qu'une radio n'est pas requise par une autre interface.

Pour les appareils équipés d'Android 14 ou version ultérieure, lorsque le Le point d'accès Wi-Fi 7 annonce la désactivation temporaire de l'une des liaisons via un Élément de mappage TID-lien transmis dans la balise, la réponse de la sonde et de réponse d'association, la station Wi-Fi 7 poursuit la connexion avec le point d'accès en utilisant les liens restants qui sont configurés, sans effectuer d'autre l'association.

Sur les appareils équipés d'Android 13 ou version antérieure, le framework 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 de Wi-Fi informe le framework Wi-Fi du mappage TID-lien via les interfaces AIDL suivantes:

Les applications peuvent obtenir des informations sur les modifications apportées au mappage TID-lien en utilisant le API suivantes:

Pour les appareils équipés d'Android 14 ou version ultérieure : Des API 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 puce pour le mappage TID-lien la négociation.

AIDL HAL

L'interface AIDL pour la négociation du mappage TID-lien se trouve dans FeatureSetMask dans hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl. La La capacité T2LM_NEGOTIATION = 1 << 8 indique que le chip est compatible Mappage TID-lien. API

Capacité du point d'accès

Les interfaces suivantes prennent en charge la capacité du point d'accès pour le mappage TID-lien la négociation.

AIDL HAL

Le framework interroge la capacité du point d'accès du suppliant avec la capacité de connexion actuelle.

API

Les statistiques sur la couche de liaison incluent des informations spécifiques aux liaisons Wi-Fi, telles que le RSSI, différents signaux de transmission et les compteurs de paquets RX et les statistiques radio. Le framework Wi-Fi interroge régulièrement les statistiques de couche de liaison et le RSSI pour sélectionner le meilleur réseau ou évaluer la qualité du réseau connecté. Pour les appareils équipés d'Android 14 ou plus, les statistiques du calque de liaison incluent compatible avec plusieurs liaisons. Pour prendre en charge le Wi-Fi 7, Android est compatible avec MLO dans les deux couches de liaison les statistiques et les interrogations de signaux.

Les statistiques spécifiques aux liens sont disponibles dans les interfaces AIDL suivantes de la couche de liaison:

La android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() l'API système écoute toutes les statistiques de la couche de liaison. Le framework appelle périodiquement cette API pour mettre à jour les statistiques sur la facilité d'utilisation du Wi-Fi.

Les API spécifiques aux liens suivantes sont disponibles 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 d'association disponibles, les applications peuvent appeler la méthode android.net.wifi.WifiUsabilityStatsEntry#getLinkIds() .

API dans android.net.wifi.WifiUsabilityStatsEntry pour une seule liaison (et non pour le MLO) renvoient les statistiques agrégées pour les connexions MLO. La voici les critères d'agrégation:

  • Les statistiques agrégées suivantes concernant les paquets utilisent la somme des statistiques par liaison:

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

  • Les statistiques suivantes utilisent les données du lien ayant 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 équipés d'Android 13, statistiques sur la couche d'association ne tiennent pas compte l'utilisation de plusieurs liens pour une seule interface. Pour soutenir la MLO, le logiciel du fournisseur doit appliquer la logique d'agrégation suivante pour générer des rapports sur LinkLayerStats via l'API HAL IWifi# getLinkLayerStats_1_6(). Le meilleur lien est le avec le RSSI le plus élevé.

  • StaLinkLayerStats.iface.beaconRx: indique le nombre de balises de la meilleure utilisé pour l'interface.
  • StaLinkLayerStats.iface.avgRssiMgmt: signaler avgRssiMgmt pour le meilleur lien utilisé pour l'interface.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk): Signaler les statistiques agrégées des paquets (total) sur les liens de l'interface.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk): transmettez les statistiques de temps de conflit du meilleur lien utilisé sur le (statistiques sur les temps de conflit les plus faibles).

Lorsque l'une des liaisons du point d'accès Wi-Fi 7 est réutilisée, le point d'accès peut annoncer sa suppression via la reconfiguration des liens MLO. Arrêts peut maintenir une connectivité fluide avec le point d'accès sans réassociation au liens restants.

La onMloLinksInfoChanged interface AIDL, située chez le demandeur Wi-Fi à l'adresse ISupplicantStaIfaceCallback.aidl, prend en charge la reconfiguration des liaisons (suppression du point d'accès de la liaison).

Lorsque le framework Wi-Fi traite la suppression d'un lien, l'état de la liaison est défini à MLO_LINK_STATE_UNASSOCIATED Le framework déclenche ensuite ConnectivityManager.NetworkCallback#onCapabilitiesChanged() pour un changement d'état d'une liaison.

La WifiInfo#getAffiliatedMloLinks renvoie les liens MLO affiliés. La MloLink#getState renvoie l'état du lien. Si le lien est supprimé, le lien affiché est MLO_LINK_STATE_UNASSOCIATED

Stratégie MLO de type chips

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 applis ayant des exigences spécifiques telles que la faible latence, la bande passante élevée et la faible consommation d'énergie. Les fournisseurs de puces peuvent développer des algorithmes sur la façon d'utiliser les liens disponibles.

Les applications privilégiées peuvent modifier ces algorithmes à l'aide de la setMloMode dans Wifimanager et définissez 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 AIDL IWifiChip pour définir le mode MLO.