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 d'Android Wi-Fi 7, y compris l'opération de référence et l'opération multiliaison (MLO).

Fonctionnalités de base de Wi-Fi 7

Cette section décrit les fonctionnalités de référence du Wi-Fi 7 incluses dans Android 13 et versions ultérieures.

Compatibilité de l'appareil 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 supposé être compatible avec le Wi-Fi 7, quelle que soit la réponse de nl80211. Ce forçage n'est utile que pour les fabricants d'appareils qui ne disposent pas de pilotes prenant en charge le Wi-Fi 7.
  • Si le calque est défini 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 supposé être compatible avec le Wi-Fi 7.

Compatibilité avec le Wi-Fi 7 des points d'accès scanné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) scanné est compatible avec le Wi-Fi 7. Si l'AP est compatible avec le Wi-Fi 7, l'API renvoie ScanResults.WIFI_STANDARD_11BE. L'appareil n'est pas obligé de prendre en charge 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 la connectivité. Si EHT Capability IE figure dans les résultats de l'analyse, l'AP analysé est compatible avec le Wi-Fi 7. La classe AOSP WifiTracker affiche ces informations de compatibilité 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 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 à 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 scanné.

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

  • Compatibilité avec le 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 les utiliser.

Mesure des distances en fonction du DAR Wi-Fi

Android prend en charge l'API pour le préambule EHT et la largeur de canal de 320 MHz pour le RTT Wi-Fi. Cela permet de prendre en charge les fonctionnalités liées au Wi-Fi 7 dans la plage RTT chaque fois qu'elle est prise 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 de la distance basée sur le RTT Wi-Fi 7:

Soft AP

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

Démarrer le point d'accès virtuel

Android prend en charge le démarrage du 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 la superposition config_wifiSoftapIeee80211beSupported pour définir la valeur booléenne 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

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

Signaler des informations sur les vulnérabilités partielles

Android prend en charge les API pour inclure des informations sur le Wi-Fi 7 et la largeur de canal de 320 MHz dans les informations sur le point d'accès logiciel.

API HAL

La constante WIFI_STANDARD_11BE dans l'interface AIDL Generation.aidl du HAL hostapd, utilisée dans le ApInfo signalé dans le rappel IHostapdCallback#onApInstanceInfoChanged(), accepte la création de rapports sur les informations Soft AP.

API

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

MLO Wi-Fi 7 fonctionnalités

L'opération multiligne (MLO) est la fonctionnalité principale de la spécification Wi-Fi 7 (802.11be). MLO est une fonctionnalité obligatoire pour les appareils multiliaisons (MLD) exécutés 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, le MLD de l'AP et le MLD de l'STA comportent plusieurs instances d'AP ou de STA exécutées sur chaque lien. Chaque lien dispose d'une adresse MAC AP ou STA distincte. L'AP ou l'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 de liaison tel qu'il est annoncé par le MLD de l'AP.
  • 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 de l'AS. Adresse MAC attribuée localement à l'instance STA sur le lien.
  • int getChannel() : chaîne d'association. Numéro de canal associé au lien.
  • int getBand() : bracelet à maillons. Bracelet du maillon.

  • int getState() : état de la liaison. 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 pas associé à un point d'accès.
    • MLO_LINK_STATE_IDLE : inactif. Le lien est associé, mais pas actif (aucun identifiant de trafic (TID) n'y est mappé).
    • MLO_LINK_STATE_ACTIVE : actif. La liaison est associée et active (au moins un TID est mappé sur la liaison). Un lien actif peut être en mode économie d'énergie, car le framework ne surveille pas l'état d'alimentation du lien.

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

Les applications peuvent obtenir les paramètres MLO d'un MLD Wi-Fi 7 AP lorsque le module Wi-Fi reçoit un objet ScanResult de l'AP-MLD. Le WifiTracker AOSP 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 multilien (IE) inclus dans la réponse de la balise ou de la vérification pour lire l'adresse MAC AP MLD et l'ID de lien actuel.
  • Analyse l'IE RNR (Reduced Neighbor Report) inclus dans la réponse du balise ou de l'exploration pour lire la liste des informations sur les liens affiliés.

API

Pour obtenir des informations sur les MLO de l'AP numérisées, les applications peuvent utiliser les API suivantes:

Informations sur le MLO de l'AP Wi-Fi 7 connecté

Lorsqu'un appareil se connecte à un réseau Wi-Fi 7 AP-MLD, le framework collecte les paramètres MLO de la connexion à partir de l'objet WifiInfo. L'objet WifiTracker AOSP affiche ces informations lorsqu'il s'exécute en mode verbeux.

Lorsque l'appareil se connecte au point d'accès AP-MLD, le module Wi-Fi copie les informations MLO de l'objet ScanResult reçu du point d'accès. Le module appelle ensuite l'API HAL ISupplicantStaIface#getConnectionMloLinksInfo() pour lire les adresses MAC de chaque liaison pour les points d'accès et les STA, et pour mettre à jour l'état des liaisons associées.

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 balise ou réponse de sonde qu'il reçoit. Cela signifie que le framework Wi-Fi:

  • Peut recevoir plusieurs objets ScanResults du même point d'accès (AP-MLD), car celui-ci peut avoir plusieurs liens de balisage.
  • Il est possible que le routeur ne reçoive qu'un ensemble partiel des résultats de l'analyse des liens des points d'accès d'un AP-MLD, car certains de ces signaux de liaison peuvent ne pas être reçus par le 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 doit pas créer (synthétiser artificiellement) des résultats d'analyse basés sur les liens annoncés par l'AP-MLD.

Le logiciel du fournisseur doit inclure les IEs multi-maillons et RNR de la variante de base reçues des instances de point d'accès dans les résultats d'analyse. Si les détails des points d'accès affiliés sont manquants dans les résultats de l'analyse, le logiciel du fournisseur peut envoyer des requêtes de sonde multi-maillons (cadre de requête de sonde incluant un élément de sonde multi-maillons) pour inclure l'ensemble complet ou partiel des fonctionnalités, des paramètres et des éléments d'opération du point d'accès avec le AP-MLD ciblé dans le cadre de la réponse.

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

Association de réseau AP-MLD

Lorsqu'un appareil rejoint un réseau AP-MLD, le logiciel du fournisseur utilise la liaison AP sélectionnée (lien associé) pour la signalisation. Le logiciel du fournisseur peut s'associer à tous ou à certains des liens compatibles avec l'appareil.

Une fois l'association réussie, le pilote signale ISupplicantStaIfaceCallback#onStateChanged() avec le BSSID d'un lien pour le MLD de l'AP. 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.

É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 MLO Wi-Fi 7. 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 le MLO, l'algorithme de sélection de réseau utilise les fonctionnalités MLO suivantes de la puce Wi-Fi:

  • Nombre maximal de liens STR
  • Nombre maximal de liens d'association
  • Combinaisons de bracelets simultanées

Sélection du réseau MLO Wi-Fi

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

La transmission et la réception simultanées (STR, Simultaneous Transmit and Receive) est un schéma de contention de support Wi-Fi pour l'opération multi-liaison. L'isolation du signal entre les différents maillons est suffisante pour que les maillons puissent fonctionner indépendamment et qu'ils soient capables de transmettre et de recevoir simultanément dans différents maillons. Le STR est différent de l'ancienne STA à liaison unique (SL) et de l'ancienne STA à double bande et double transmission simultanée (DBDC). Les STA affiliées à une MLD STA partagent un numéro de séquence de l'émetteur (SN) commun et un espace commun pour la transmission de données alloué à différentes liaisons si la transmission de plusieurs liaisons a la même catégorie d'accès (AC).

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

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

Plusieurs liaisons peuvent fonctionner sur une seule radio à l'aide du schéma de contention eMLSR (Enhanced Multi-Link Single Radio). Un appareil multiliaison utilise l'eMLSR sur un ensemble de liaisons s'il peut recevoir certaines trames de contrôle de base et effectuer simultanément une évaluation claire des canaux (CCA) sur l'ensemble de liaisons. Toutefois, le MLD ne transmet ou ne reçoit des données que sur un seul lien (le lien choisi dynamiquement à chaque période d'opportunité de transmission (TXOP)) à la fois.

Une station MLD peut maximiser le nombre de liaisons d'association pour améliorer la fiabilité, le débit et la latence (comparé à une ancienne station à liaison unique) en fonctionnant simultanément dans STR et eMLSR si la puce est compatible. Dans la figure 2, le nombre maximal de liens d'association est de trois.

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

Combinaisons de bracelets simultanées

Le framework interroge la puce pour obtenir les combinaisons radio autorisées (via l'interface AIDL IWifiChip.aidl) pouvant 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 HAL AIDL 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 de débit multiliaison maximal prévu est calculé pour chaque groupe, en fonction du nombre maximal de liaisons STR et des combinaisons de bandes simultanées prises en charge par le chip. 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 score de débit prévu pour plusieurs liaisons. Cela donne 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 effectue la sélection du SSID en fonction des informations reçues dans l'objet ScanResults, comme indiqué 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 du meilleur point d'accès (ou lien du point d'accès) à utiliser pour l'association.

Gestion de l'adresse MAC de l'appareil STA

Cette section explique comment les adresses MAC des STA de l'appareil (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 du MLD est gérée de la même manière qu'un appareil autre que MLD gère 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 des STA d'instance (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 dépendre 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 associées par instance, 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 sont également persistantes.

Voici un exemple d'algorithme d'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 d'administration locale est défini
  • Octets 1 à 4: identiques à l'adresse MAC du STA-MLD
  • Octet 5: par STA = (STA-MLD + ID de liaison + 1) MOD (256)

Le micrologiciel du fournisseur peut effectuer la commutation de liaison et gérer l'état d'économie d'énergie des liaisons pour les activer ou les désactiver sans intervention du framework Wi-Fi.

Le framework Wi-Fi ne s'attend pas à une notification lorsque l'état du lien 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'état d'économie d'énergie des liens individuels en fonction des modèles 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 garder au moins un lien actif (économie d'énergie désactivée). Dans cet état, l'implémentation du micrologiciel détermine quelle liaison est définie.

Chemin d'accès aux données

Il décrit l'implémentation du micrologiciel du fournisseur pour gérer le trafic en uplink et en téléchargement.

Le micrologiciel achemine le trafic de liaison montante vers un ou plusieurs liens en fonction de son implémentation interne. Le micrologiciel du fournisseur décide quand effectuer l'équilibrage de charge, la duplication ou l'agrégation du trafic en fonction des tendances du trafic. Nous vous recommandons de dupliquer le trafic du micrologiciel sur plusieurs liens dans les cas suivants:

  • Lorsque le mode à faible latence est défini via l'API HAL IWifiChip#setLatencyMode().
  • En cas de trafic avec une priorité utilisateur 6 et 7.

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

Simultanéité

Les scénarios de simultanéité, dans lesquels une radio est utilisée pour une nouvelle interface, doivent avoir la priorité sur la dédicace de plusieurs radios pour les liaisons de la même interface. Les scénarios de simultanéité doivent également avoir la priorité sur les MLO, quel que soit l'ordre dans lequel ils sont exécutés. L'utilisation de plusieurs liens pour une seule interface est opportuniste, ce qui signifie que plusieurs liens ne sont utilisés que lorsque:

  • 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 point d'accès Wi-Fi 7 annonce la désactivation temporaire de l'un des liens via un élément de mappage TID-link transmis dans les trames de balise, de réponse de sonde et de réponse d'association, la station Wi-Fi 7 poursuit la connexion avec le point d'accès à l'aide des liens restants configurés, sans effectuer une 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 de la mise en correspondance TID-liaison, même si la liaison associée n'est pas associée à un TID.

Le demandeur Wi-Fi informe le framework Wi-Fi des modifications de mappage TID-to-link via les interfaces AIDL suivantes:

Les applications peuvent obtenir des informations sur les modifications de mappage TID-to-link à 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 fonctionnalités de négociation de la carte TID-to-link pour la borne et l'AP.

Fonctionnalité de la puce

Les interfaces suivantes prennent en charge la capacité de la puce pour la négociation de mappage TID-to-link.

HAL AIDL

L'interface AIDL pour la négociation de la mise en correspondance TID-link se trouve dans FeatureSetMask dans hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl. La capacité T2LM_NEGOTIATION = 1 << 8 indique que la puce est compatible avec le mappage TID à liaison. API

Capacité du point d'accès

Les interfaces suivantes prennent en charge la capacité de l'AP à négocier la mise en correspondance TID-link.

HAL AIDL

Le framework interroge la capacité de l'AP auprès du demandeur, ainsi que la capacité de connexion actuelle.

API

Les statistiques de la couche de liaison incluent des détails spécifiques à la liaison Wi-Fi, tels que le RSSI, divers compteurs de paquets TX et RX, ainsi que des statistiques radio. Le framework Wi-Fi interroge périodiquement les statistiques de la 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 version ultérieure, les statistiques de la couche de liaison incluent la prise en charge de la multiliaison. Pour prendre en charge le Wi-Fi 7, Android prend en charge MLO dans les statistiques de la couche de liaison et l'interrogation de signaux.

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

L'API système android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() écoute toutes les statistiques de la couche de liaison. Le framework appelle régulièrement cette API pour mettre à jour les statistiques d'usabilité 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 d'association disponibles, les applications peuvent appeler la méthode android.net.wifi.WifiUsabilityStatsEntry#getLinkIds().

Les API de android.net.wifi.WifiUsabilityStatsEntry pour un seul lien (et 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 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 de la liaison 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 de liaison ne tiennent pas compte de l'utilisation de plusieurs liaisons pour une seule interface. Pour prendre en charge la MLO, le logiciel du fournisseur doit appliquer la logique d'agrégation suivante lors de la création de rapports sur LinkLayerStats via l'API HAL IWifi# getLinkLayerStats_1_6(). Le meilleur lien est celui qui affiche le RSSI le plus élevé.

  • StaLinkLayerStats.iface.beaconRx: indique 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): génère les rapports sur les statistiques agrégées des paquets (total) sur les liens de l'interface.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk): indique les statistiques de temps de contention pour le meilleur lien utilisé sur l'interface (statistiques de temps de contention les plus faibles).

Lorsqu'un des liens du point d'accès Wi-Fi 7 est réutilisé, le PA peut annoncer la suppression du lien via la reconfiguration du lien MLO. Les stations peuvent maintenir une connectivité fluide avec le PA sans réassociation sur les liens restants.

L'interface AIDL onMloLinksInfoChanged, située dans le demandeur Wi-Fi à l'adresse ISupplicantStaIfaceCallback.aidl, prend en charge la reconfiguration du lien (suppression du lien par le point d'accès).

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

La méthode WifiInfo#getAffiliatedMloLinks renvoie les liens MLO associés. La méthode MloLink#getState renvoie l'état de l'association. Si le lien est supprimé, l'état du lien renvoyé 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 applications qui présentent des exigences spécifiques, telles qu'une faible latence, une bande passante élevée et une faible consommation d'énergie. Les fournisseurs de chips peuvent développer des algorithmes pour 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.