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 les fonctionnalités Wi-Fi 7 d'Android, y compris le fonctionnement de base et le fonctionnement multi-liaisons (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.

Compatibilité des appareils avec le Wi-Fi 7

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 est compatible avec 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 considéré comme compatible avec le Wi-Fi 7, quelle que soit la réponse de nl80211. Cette substitution n'est utile que pour les fabricants d'appareils qui ne disposent pas de pilotes compatibles avec le 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 l'attribut NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY figure dans la réponse du pilote, l'appareil est considéré comme compatible avec le Wi-Fi 7.

Compatibilité avec le Wi-Fi 7 pour les points d'accès analysés

Le framework Android inclut l'API int ScanResult#getWifiStandard(), que les applications peuvent appeler pour vérifier si un point d'accès (PA) analysé est 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'a pas besoin d'être compatible avec le Wi-Fi 7 pour que les applications puissent utiliser 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 par l'analyse de connectivité. Si EHT Capability IE figure dans les résultats de l'analyse, cela signifie que le point d'accès analysé est compatible avec le Wi-Fi 7. La classe WifiTracker de l'AOSP affiche ces informations d'assistance dans l'interface utilisateur lorsqu'elle est exécutée 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 STA (station) actuel est le Wi-Fi 7. Le mode de connexion STA est Wi-Fi 7 lorsque l'appareil et le point d'accès connecté sont compatibles avec le 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 AIDL wpa_supplicant vérifie si EHT Capability IE se trouve à la fois dans AssocReq et AssocRsp lors de la configuration de la connexion.

Sélection du réseau

Dans Android 13, la sélection du réseau utilise plusieurs paramètres pour déterminer le point d'accès auquel 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 capacités de PA suivantes dans son calcul :

  • Prise en charge du Wi-Fi 7 (802.11be)
  • Prise en charge de la largeur de canal de 320 MHz

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

Mesure de distance basée sur le Wi-Fi RTT

Android fournit une assistance API pour le préambule EHT et la largeur de canal de 320 MHz pour Wi-Fi RTT. Cela permet la prise en charge des fonctionnalités liées au Wi-Fi 7 dans la plage RTT chaque fois que la puce le permet.

API HAL

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

API

Les applications peuvent utiliser les API suivantes pour la mesure de distance basée sur le Wi-Fi 7 RTT :

Soft AP

Android est compatible avec le Wi-Fi 7 dans le point d'accès logiciel et fournit les fonctionnalités suivantes.

Démarrer le point d'accès logiciel

Android permet de démarrer un point d'accès logiciel en mode Wi-Fi 7. Cela est régi par la configuration de la superposition config_wifiSoftapIeee80211beSupported.

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

API HAL

Le booléen enable80211BE dans HwModeParams du HAL hostapd permet de démarrer le point d'accès logiciel en mode Wi-Fi 7.

Signaler des informations sur le point d'accès logiciel

Android inclut la prise en charge de l'API pour inclure les informations sur la bande passante Wi-Fi 7 et 320 MHz dans les informations Soft AP signalées.

API HAL

La constante WIFI_STANDARD_11BE dans l'interface AIDL Generation.aidl du HAL hostapd, qui est utilisée dans ApInfo signalé dans le rappel IHostapdCallback#onApInstanceInfoChanged(), permet de signaler les informations sur le point d'accès logiciel.

API

Les applications peuvent utiliser les méthodes suivantes (API système) dans SoftApInfo pour signaler les informations sur le point d'accès logiciel.

Fonctionnalités MLO Wi-Fi 7

Le fonctionnement multi-liaisons (MLO) est la principale fonctionnalité de la spécification Wi-Fi 7 (802.11be). MLO est une fonctionnalité obligatoire pour les appareils multilink (MLD) fonctionnant en Wi-Fi 7, que ce soit de manière simultanée ou non.

Schéma MLO

Figure 1 : Schéma MLO.

Comme le montre la figure 1, les AP-MLD et STA-MLD comportent plusieurs instances AP ou STA exécutées sur chaque lien. Chaque lien possède une adresse MAC AP ou STA distincte. Le point d'accès 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 inclut les paramètres suivants :

  • int getLinkId() : ID du lien tel qu'annoncé par l'AP MLD.
  • MacAddress getApMacAddress() : adresse MAC du point d'accès. BSSID de l'instance AP pour ce lien.
  • MacAddress getStaMacAddress() : adresse MAC du STA. Adresse MAC attribuée localement à l'instance STA sur le lien.
  • int getChannel() : Associer une chaîne. Numéro de chaîne du lien.
  • int getBand() : bracelet à maillons. Bande du lien.

  • int getState() : État du lien. Les états possibles sont les suivants :

    • MLO_LINK_STATE_INVALID : non valide. Utilisé pour l'initialisation et les cas d'erreur.
    • MLO_LINK_STATE_UNASSOCIATED : non associé. Le lien n'est associé à aucun point d'accès.
    • MLO_LINK_STATE_IDLE : inactif. Le lien est associé, mais 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). Une liaison active peut être en mode économie d'énergie, car le framework ne surveille pas l'état d'alimentation de la liaison.

Informations MLO sur les points d'accès Wi-Fi 7 analysés

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 lorsqu'il est exécuté en mode détaillé.

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

  • Analyse l'élément d'information (IE) multilien inclus dans la réponse de balise ou de sonde pour lire l'adresse MAC MLD du point d'accès et l'ID de lien actuel.
  • Analyse l'élément d'information (IE) du rapport sur les voisins réduits (RNR) inclus dans la réponse de la balise ou de la sonde pour lire la liste des informations sur les liens affiliés.

API

Pour obtenir des informations sur les AP et les MLO analysés, les applications peuvent utiliser les API suivantes :

Informations sur le point d'accès Wi-Fi 7 MLO connecté

Lorsqu'un appareil se connecte à un point d'accès Wi-Fi 7 AP-MLD, le framework collecte les paramètres MLO de la connexion à partir de l'objet WifiInfo. L'objet AOSP WifiTracker affiche ces informations lorsqu'il est exécuté 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 les points d'accès et les stations, et pour 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 l'analyse pour chaque réponse de balise ou de sonde qu'il reçoit. Cela signifie que le framework Wi-Fi :

  • Vous pouvez recevoir plusieurs objets ScanResults du même AP-MLD (car le point d'accès peut comporter plusieurs liens de signalisation).
  • Il est possible que vous ne receviez qu'un ensemble partiel des résultats d'analyse pour les liens AP d'un AP-MLD, car il est possible que certains de ces signaux de lien ne soient pas reçus par le micrologiciel.

Le logiciel du fournisseur ne doit signaler que les résultats d'analyse reçus par voie hertzienne et ne doit pas créer (synthétiser artificiellement) de résultats d'analyse basés sur les liens annoncés par l'AP-MLD.

Le logiciel du fournisseur doit inclure les IE de variante multilink et RNR de base reçus des instances AP dans les résultats d'analyse signalés. Si les informations sur le PA affilié sont manquantes dans les résultats de l'analyse, le logiciel du fournisseur peut envoyer des demandes de sonde multilien (trame de demande de sonde qui inclut un élément de demande de sonde multilien) pour inclure l'ensemble complet ou partiel des capacités, des paramètres et des éléments d'opération du PA avec le PA-MLD ciblé dans la trame de réponse.

Le logiciel du fournisseur peut déclencher un sondage ML (à l'aide de l'IE ML de variante de requête de sondage dans le frame de requête de sondage) si nécessaire.

Association de 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 compatibles avec l'appareil.

Une fois l'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 AP-MLD à condition que les résultats de l'analyse aient été signalés au framework pour ce lien.

Évaluation des réseaux

Pour les appareils équipés d'Android 14 ou version ultérieure, la sélection de réseau Wi-Fi Android est compatible avec le 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 du réseau utilise les fonctionnalités MLO suivantes du chipset 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, Simultaneous Transmit and Receive) sont un schéma de contention du support Wi-Fi pour le fonctionnement multi-liaisons. L'isolation du signal entre les différents liens est suffisante pour que les liens puissent fonctionner indépendamment et soient capables de transmettre et de recevoir simultanément dans différents liens. Le STR est différent des STA à liaison unique (SL) et des STA à double bande et double simultanéité (DBDC) hérités. Les STA affiliés à un STA MLD partagent un numéro de séquence (SN) d'émetteur commun et un espace commun pour la transmission de données alloué à différentes liaisons si plusieurs transmissions de 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 de radios prises en charge par la puce. Dans l'exemple de la figure 2, le nombre maximal de liens STR est de 2.

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

Plusieurs liens peuvent fonctionner sur une seule radio à l'aide du schéma de contention Enhanced Multi-Link Single Radio (eMLSR). Un appareil multi-liaisons utilise eMLSR sur un ensemble de liaisons s'il peut recevoir certains trames de contrôle de base et effectuer une évaluation claire du canal (CCA) simultanément sur l'ensemble de liaisons. Toutefois, le MLD ne transmet ni ne reçoit de données que sur un seul lien (celui choisi dynamiquement à chaque période 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 ancienne à lien unique) en fonctionnant simultanément en STR et eMLSR si la puce le permet. Dans la figure 2, le nombre maximal de liens d'association est de 3.

Les interfaces AIDL HAL suivantes sont compatibles avec la fonctionnalité de nombre maximal de liens d'association :

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. À partir de ces informations, le framework déduit les combinaisons de bandes simultanées possibles. 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 AIDL HAL suivante est compatible avec les combinaisons de radios 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 ayant la même adresse MAC MLD. Le score maximal de débit multi-liaison prédit est calculé pour chaque groupe, en fonction du nombre maximal de liaisons STR et des combinaisons de bandes simultanées prises en charge par la puce. Si le candidat est compatible avec le multi-lien et que le chip prend en charge STR, le score de débit prédit est remplacé par le score de débit prédit du multi-lien. Cela permet de donner un coup de pouce aux candidats MLO lors de la sélection du réseau.

Lorsque vous rejoignez un réseau AP-MLD, le framework sélectionne le SSID en fonction des informations reçues dans l'objet ScanResults, telles qu'indiquées par le logiciel du fournisseur. Une fois le SSID sélectionné par le framework, le logiciel du fournisseur est responsable de la sélection du BSSID pour le meilleur point d'accès (ou lien AP) à utiliser pour l'association.

Gestion de l'adresse MAC STA de l'appareil

Cette section décrit la façon dont les adresses MAC STA des appareils (adresses MAC MLD et adresses MAC STA par lien) 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 traitée de la même manière qu'un appareil non MLD traite sa propre adresse MAC. L'adresse MAC peut être une adresse MAC aléatoire ou une adresse MAC provisionnée par le matériel, selon le 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 lien en fonction de son algorithme. 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 du lien (reçu de l'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 inversement. 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 le sont également.

Voici un exemple d'algorithme pour l'attribution d'adresses MAC STA par lien (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.
  • Octets 1 à 4 : identiques à l'adresse MAC STA-MLD
  • Octet 5 : Per-STA = (STA-MLD + ID de liaison + 1) MOD (256)

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

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. En mode économie d'énergie, le micrologiciel du fournisseur gère l'état d'économie d'énergie des liens individuels en fonction des schémas de trafic et des décisions d'activation ou de désactivation des liens.

Toutefois, le framework 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 maintenir au moins un lien actif (économie d'énergie désactivée). Dans cet état, l'implémentation du micrologiciel décide du lien à définir.

Chemin d'accès aux données

Cela décrit l'implémentation du micrologiciel du fournisseur pour la gestion du trafic montant et descendant.

Le micrologiciel achemine le trafic en liaison montante vers un ou plusieurs liens en fonction de son implémentation interne. Le micrologiciel du fournisseur décide quand équilibrer la charge, dupliquer ou agréger le trafic en fonction des schémas de trafic. Nous recommandons au micrologiciel de dupliquer le trafic 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 une priorité utilisateur de 6 et 7.

Le micrologiciel doit remplacer l'adresse MAC (de destination) par STA du champ d'en-tête MAC par l'adresse MAC MLD-STA et l'adresse MAC (source) par AP du champ d'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 du filtre APF comportent des filtres basés sur les adresses MAC MLD. Il existe un seul filtre APF pour tous les liens d'un AP-MLD.

Simultanéité

Les scénarios de concurrence, dans lesquels une radio est utilisée pour une nouvelle interface, doivent avoir la priorité sur l'attribution de plusieurs radios pour les liens de la même interface. Les scénarios de concurrence doivent également être prioritaires par rapport à l'OLM, quel que soit l'ordre d'arrivée. L'utilisation de plusieurs liens pour une même interface est opportuniste, ce qui signifie que plusieurs liens ne sont utilisés que lorsque :

  • L'option MLO est requise en fonction de la décision du micrologiciel concernant l'équilibrage de charge, l'agrégation ou la duplication.
  • Le MLO est disponible, ce qui signifie qu'aucune autre interface ne nécessite de radio.

Pour les appareils équipés d'Android 14 ou version ultérieure, lorsque le point d'accès Wi-Fi 7 annonce la désactivation temporaire de l'un des liens via un élément de mappage TID-to-link transmis dans les trames de balise, de réponse à la sonde et de réponse à l'association, la station Wi-Fi 7 poursuit la connexion avec le point d'accès à l'aide des liens restants configurés, sans effectuer d'autre association.

Pour les appareils équipés d'Android 13 ou version antérieure, le framework Wi-Fi ne permet pas de recevoir de notifications lorsque l'état de la liaison est modifié en raison du mappage TID vers liaison, même si la liaison associée n'est pas liée à un TID.

Le supplicant Wi-Fi informe le framework Wi-Fi des modifications apportées au mappage TID-to-link via les interfaces AIDL suivantes :

Les applications peuvent obtenir des informations sur les modifications apportées au mappage entre les TID et les liens à l'aide des API suivantes :

Pour les appareils équipés d'Android 14 ou version ultérieure, les API suivantes sont disponibles pour obtenir les capacités de négociation de la carte TID-to-link pour la station et le point d'accès.

Capacité de la puce

Les interfaces suivantes sont compatibles avec la fonctionnalité de puce pour la négociation du mappage TID vers lien.

AIDL HAL

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

Fonctionnalité AP

Les interfaces suivantes sont compatibles avec la fonctionnalité AP pour la négociation du mappage TID-to-link.

AIDL HAL

Le framework interroge la fonctionnalité AP du demandeur ainsi que la fonctionnalité de connexion actuelle.

API

Les statistiques de la couche liaison incluent des informations spécifiques à la liaison Wi-Fi, telles que le RSSI, divers compteurs de paquets TX et RX, ainsi que des statistiques radio. Le framework Wi-Fi interroge régulièrement les statistiques de la couche 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 version ultérieure, les statistiques de la couche liaison incluent la prise en charge multi-liaison. Pour prendre en charge le Wi-Fi 7, Android est compatible avec MLO dans les statistiques de la couche liaison et l'interrogation du signal.

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

L'API système android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() écoute toutes les statistiques de la couche 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 les liens uniques (non MLO) renvoient les statistiques agrégées pour les connexions MLO. Voici les critères d'agrégation :

  • Les statistiques agrégées suivantes sur les paquets 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 équipés d'Android 13, les statistiques de la couche liaison ne tiennent pas compte de l'utilisation de plusieurs liens pour une même interface. Pour prendre en charge MLO, le logiciel du fournisseur doit appliquer la logique d'agrégation suivante lors du signalement de LinkLayerStats via l'API HAL IWifi# getLinkLayerStats_1_6(). Le meilleur lien est celui dont le RSSI est le plus élevé.

  • StaLinkLayerStats.iface.beaconRx : indique le nombre de balises pour le meilleur lien utilisé pour l'interface.
  • StaLinkLayerStats.iface.avgRssiMgmt : signalez avgRssiMgmt pour obtenir le meilleur lien utilisé pour l'interface.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk) : signale les statistiques agrégées sur les paquets (total) pour les liens de l'interface.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk) : indique les statistiques sur le temps de contention pour la meilleure liaison utilisée sur l'interface (statistiques sur le temps de contention le plus faible).

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 par le biais de la reconfiguration du lien MLO. Les stations peuvent maintenir une connectivité fluide avec le point d'accès sans réassociation sur les liens restants.

L'interface AIDL onMloLinksInfoChanged, située dans le supplicant Wi-Fi à l'adresse ISupplicantStaIfaceCallback.aidl, est compatible avec la reconfiguration des liens (suppression du point d'accès du lien).

Lorsque le framework 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 du lien.

La méthode WifiInfo#getAffiliatedMloLinks renvoie les liens MLO affiliés. La méthode MloLink#getState renvoie l'état de l'association. Si l'association est supprimée, l'état du lien renvoyé est MLO_LINK_STATE_UNASSOCIATED.

Stratégie Chip MLO

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 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 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 AIDL IWifiChip pour définir le mode MLO.