Wi‑Fi 7

Auf Geräten mit Android 13 oder höher wird der Standard Wi‑Fi 7 (IEEE 802.11be) unterstützt. Auf dieser Seite werden die Wi‑Fi 7-Funktionen von Android beschrieben, einschließlich Baseline und Multi-Link Operation (MLO).

Grundlegende Wi‑Fi 7-Funktionen

In diesem Abschnitt werden die grundlegenden Wi‑Fi 7-Funktionen beschrieben, die in Android 13 und höher enthalten sind.

Unterstützung von Wi‑Fi 7 auf Geräten

Das Android-Framework enthält die WifiManager#isWifiStandardSupported(int standard)-API, die Apps mit dem Argument ScanResults.WIFI_STANDARD_11BE aufrufen können, um zu prüfen, ob ein Gerät Wi‑Fi 7 unterstützt.

Wenn diese API aufgerufen wird, prüft das WLAN-Modul, ob das config_wifi11beSupportOverride-Konfigurations-Overlay als Überschreibung verwendet wird, und führt die folgenden Schritte aus:

  • Wenn das Overlay auf true gesetzt ist, wird davon ausgegangen, dass das Gerät Wi‑Fi 7 unterstützt, unabhängig von der Antwort von nl80211. Diese Überschreibung ist nur für Gerätehersteller nützlich, die keine Treiber haben, die Wi‑Fi 7 unterstützen.
  • Wenn das Overlay auf false (Standardwert) festgelegt ist, verwendet das WLAN-Modul die Informationen aus nl80211. Das WLAN-Modul fordert die Informationen von wificond an, das den nl80211-Befehl NL80211_CMD_GET_WIPHY aufruft. Wenn das Attribut NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY in der Antwort des Treibers enthalten ist, wird davon ausgegangen, dass das Gerät Wi‑Fi 7 unterstützt.

Unterstützung von Wi‑Fi 7 für gescannte Zugriffspunkte

Das Android-Framework enthält die int ScanResult#getWifiStandard() API, die Apps aufrufen können, um zu prüfen, ob ein gescannter Zugriffspunkt (AP) Wi‑Fi 7 unterstützt. Wenn der AP Wi‑Fi 7 unterstützt, gibt die API ScanResults.WIFI_STANDARD_11BE zurück. Das Gerät muss Wi‑Fi 7 nicht unterstützen, damit Apps diese API verwenden können.

Wenn diese API aufgerufen wird, prüft das WLAN-Modul, ob EHT Capability IE in den zurückgegebenen Ergebnissen des Konnektivitätsscans enthalten ist. Wenn EHT Capability IE in den Scanergebnissen enthalten ist, unterstützt der gescannte AP Wi‑Fi 7. Die AOSP-Klasse WifiTracker zeigt diese Supportinformationen in der Benutzeroberfläche an, wenn sie im ausführlichen Modus ausgeführt wird.

STA-Verbindungsmodus

Das Android-Framework enthält die int WifiInfo#getWifiStandard()-API, die Apps aufrufen können, um zu prüfen, ob der aktuelle STA-Verbindungsmodus (Station) Wi-Fi 7 ist. Der STA-Verbindungsmodus ist Wi‑Fi 7, wenn sowohl das Gerät als auch der verbundene AP Wi‑Fi 7 unterstützen. Wenn der Verbindungsmodus WLAN 7 ist, gibt die API ScanResults.WIFI_STANDARD_11BE zurück.

Wenn getWifiStandard aufgerufen wird, bestimmt das WLAN-Modul den Modus durch Aufrufen der ISupplicantStaIface#getConnectionCapabilities()-HAL-API. Bei der Implementierung dieser HAL-API in der wpa_supplicant-AIDL-Ebene wird während der Verbindungsherstellung geprüft, ob sich EHT Capability IE sowohl in AssocReq als auch in AssocRsp befindet.

Netzwerkauswahl

In Android 13 werden bei der Netzwerkauswahl mehrere Parameter verwendet, um zu bestimmen, mit welchem AP eine Verbindung hergestellt werden soll. Einer der Parameter ist der geschätzte Durchsatz des AP, der mit dem Block ThroughputPredictor geschätzt wird. Der ThroughputPredictor-Block verwendet die PHY-Parameter sowohl des Geräts als auch des gescannten AP.

Unter Android 13 verwendet ThroughputPredictor die folgenden AP-Funktionen für die Berechnung:

  • Unterstützung von Wi‑Fi 7 (802.11be)
  • Unterstützung von 320‑MHz-Kanalbreite

Wenn diese Funktionen in die ThroughputPredictor-Logik aufgenommen werden, erhöht sich die Wahrscheinlichkeit, dass Wi‑Fi 7-fähige APs ausgewählt werden, wenn das Gerät diese Funktionen nutzen kann.

RTT-basierte WLAN-Entfernungsmessung

Android bietet API-Unterstützung für die EHT-Präambel und eine Kanalbreite von 320 MHz für Wi-Fi RTT. Dadurch werden Wi-Fi 7-Funktionen im RTT-Bereich unterstützt, sofern der Chip dies unterstützt.

HAL-APIs

Die folgenden HAL-APIs unterstützen die Wi-Fi 7-Funktionen für RTT-basierte Entfernungsbestimmung:

APIs

Apps können die folgenden APIs für die Wi‑Fi 7-basierte RTT-Entfernungsmessung verwenden:

Soft-AP

Android unterstützt Wi‑Fi 7 im Soft-AP-Modus und bietet die folgenden Funktionen.

Soft-AP starten

Android unterstützt das Starten von Soft‑APs im WLAN 7‑Modus. Dies richtet sich nach der Konfiguration des config_wifiSoftapIeee80211beSupported-Overlays.

Das WLAN-Modul verwendet das Overlay config_wifiSoftapIeee80211beSupported, um den booleschen Wert HwModeParams#enable80211BE im IHostApd#addAccessPoint()-API-Aufruf festzulegen. In der hostapd-AIDL-Ebene wird dieser Wert verwendet, um die hostapd.conf-Parameter festzulegen.

HAL-APIs

Der boolesche Wert enable80211BE in HwModeParams in der hostapd-HAL unterstützt das Starten des Soft-AP im WLAN 7-Modus.

Soft-AP-Informationen melden

Android bietet API-Unterstützung, um Informationen zu Wi‑Fi 7 und einer Kanalbreite von 320 MHz in die gemeldeten Soft-AP-Informationen aufzunehmen.

HAL-APIs

Die WIFI_STANDARD_11BE-Konstante in der Generation.aidl-AIDL-Schnittstelle im hostapd-HAL, die in der ApInfo verwendet wird, die im IHostapdCallback#onApInstanceInfoChanged()-Callback gemeldet wird, unterstützt das Melden von Soft-AP-Informationen.

APIs

Apps können die folgenden Methoden (System-APIs) in SoftApInfo verwenden, um Soft-AP-Informationen zu melden.

MLO-Funktionen für Wi-Fi 7

Multi-Link Operation (MLO) ist die Hauptfunktion in der Wi‑Fi 7-Spezifikation (802.11be). MLO ist eine obligatorische Funktion für Geräte mit mehreren Links (Multi-Link Devices, MLD), die in Wi‑Fi 7 ausgeführt werden, unabhängig davon, ob gleichzeitig oder nicht gleichzeitig.

MLO-Diagramm

Abbildung 1: MLO-Diagramm.

Wie in Abbildung 1 dargestellt, werden sowohl für AP-MLD als auch für STA-MLD mehrere AP- oder STA-Instanzen auf jeder Verbindung ausgeführt. Jede Verbindung hat eine separate AP- oder STA-MAC-Adresse. Der AP oder die STA hat auch eine MLD-MAC-Adresse, um das Gerät zu identifizieren.

Die Klasse android.net.wifi.MloLink stellt den MLO-Link dar. Diese Klasse umfasst die folgenden Parameter:

Gescannte MLO-Informationen für Wi‑Fi 7-APs

Apps können die MLO-Parameter für eine Wi‑Fi 7-AP-MLD abrufen, wenn das WLAN-Modul ein ScanResult-Objekt von der AP-MLD empfängt. Im AOSP-WifiTracker werden die MLO-Parameter angezeigt, wenn der ausführliche Modus ausgeführt wird.

Das WLAN-Modul erfasst die MLO-Informationen auf folgende Weise:

  • Parst das im Beacon oder in der Probe-Antwort enthaltene IE (Informationselement) für mehrere Links, um die AP-MLD-MAC-Adresse und die aktuelle Link-ID zu lesen.
  • Parst das RNR-IE (Reduced Neighbor Report Information Element), das in der Beacon- oder Probe-Antwort enthalten ist, um die Liste der zugehörigen Links zu lesen.

APIs

Apps können die folgenden APIs verwenden, um Informationen zum maschinellen Lernen für gescannte Zugriffspunkte abzurufen:

Informationen zu verbundenen Wi‑Fi 7-APs mit MLO

Wenn ein Gerät eine Verbindung zu einem Wi-Fi 7-AP-MLD herstellt, erfasst das Framework die MLO-Parameter der Verbindung aus dem WifiInfo-Objekt. Das AOSP-Objekt WifiTracker zeigt diese Informationen an, wenn es im ausführlichen Modus ausgeführt wird.

Wenn das Gerät eine Verbindung zum AP-MLD herstellt, kopiert das WLAN-Modul die MLO-Informationen aus dem ScanResult-Objekt, das vom AP empfangen wurde. Das Modul ruft dann die ISupplicantStaIface#getConnectionMloLinksInfo()-HAL-API auf, um die MAC-Adressen der einzelnen Links für AP und STA zu lesen und den Status der zugehörigen Links zu aktualisieren.

APIs

Apps können die folgenden APIs verwenden, um Informationen zur MLO-Verbindung abzurufen:

AP-MLD-Scan

Die Anbietersoftware stellt dem WLAN-Framework die Scanergebnisse für jedes empfangene Beacon oder jede empfangene Probe-Antwort zur Verfügung. Das bedeutet, dass das WLAN-Framework:

  • Möglicherweise werden mehrere ScanResults-Objekte von derselben AP-MLD empfangen, da der AP mehrere Beaconing-Verbindungen haben kann.
  • Möglicherweise erhalten Sie nur einen Teil der Scanergebnisse für die AP-Links eines AP-MLD, da einige dieser Linksignale möglicherweise nicht von der Firmware empfangen werden.

Die Anbietersoftware meldet nur Scanergebnisse, die über die Luftschnittstelle empfangen wurden, und darf keine Scanergebnisse auf Grundlage der vom AP-MLD beworbenen Links erstellen (künstlich synthetisieren).

Die Software des Anbieters muss die grundlegenden Multi-Link- und RNR-IEs enthalten, die von den AP-Instanzen in den gemeldeten Scanergebnissen empfangen wurden. Wenn in den Scanergebnissen Details zu verbundenen APs fehlen, kann die Anbietersoftware Multi-Link-Probe-Anfragen (Probe-Request-Frame, der ein Multi-Link-Element für Probe-Anfragen enthält) senden, um den vollständigen oder teilweisen Satz von Funktionen, Parametern und Betriebselementen des AP mit dem Ziel-AP-MLD im Antwort-Frame einzuschließen.

Die Anbietersoftware kann bei Bedarf ML-Probing auslösen (mit der Probe-Req-Variante „ML IE“ im Probe-Req-Frame).

AP-MLD-Netzwerkzuordnung

Wenn ein Gerät einem AP-MLD-Netzwerk beitritt, verwendet die Anbietersoftware den ausgewählten AP-Link (zugeordneter Link) für die Signalisierung. Die Anbietersoftware kann mit allen oder einigen der vom Gerät unterstützten Links verknüpft werden.

Nach erfolgreicher Zuordnung meldet der Treiber ISupplicantStaIfaceCallback#onStateChanged() mit der BSSID einer Verbindung für die AP-MLD. Der Treiber wählt dann einen Link des AP-MLD aus, sofern Scanergebnisse für diesen Link an das Framework gemeldet wurden.

Netzwerkbewertung

Auf Geräten mit Android 14 oder höher wird Wi‑Fi 7 MLO von Android Wi‑Fi Network Selection unterstützt. Das bedeutet, dass Android das beste WLAN für das Gerät basierend auf der Anzahl der für MLO verfügbaren Links auswählt.

Zur Unterstützung von MLO verwendet der Algorithmus zur Netzwerkauswahl die folgenden MLO-Funktionen des WLAN-Chips:

  • Maximale Anzahl von STR-Links
  • Maximale Anzahl von Verknüpfungen
  • Gleichzeitige Bandkombinationen

Auswahl von WLAN-MLO-Netzwerken

Abbildung 2: MLO-Netzwerkauswahl.

STR (Simultaneous Transmit and Receive) ist ein Verfahren zur Konfliktlösung für WLAN-Medien für den Betrieb mit mehreren Links. Die Signalisolation zwischen den verschiedenen Links ist ausreichend, sodass die Links unabhängig voneinander funktionieren und gleichzeitig über verschiedene Links senden und empfangen können. STR unterscheidet sich von den alten Single-Link-STAs (SL-STAs) und den alten Dual-Band-Dual-Concurrent-STAs (DBDC-STAs). STAs, die mit einer STA-MLD verbunden sind, haben eine gemeinsame Sendersequenznummer (SN) und einen gemeinsamen Speicherplatz für die Datenübertragung, der verschiedenen Links zugewiesen wird, wenn mehrere Linksübertragungen dieselbe Zugriffskategorie (AC) haben.

Die maximale Anzahl der verwendeten STR-Links kann sich von der maximalen Anzahl der vom Chip unterstützten Funkgeräte unterscheiden. Im Beispiel in Abbildung 2 beträgt die maximale Anzahl von STR-Links 2.

Die folgenden AIDL-HAL-Schnittstellen unterstützen die maximale Anzahl von STR-Links und die maximale Anzahl von Assoziationslinks:

Mehrere Links können über das Contention-Schema „Enhanced Multi-Link Single Radio“ (eMLSR) auf einem einzelnen Funkgerät betrieben werden. Ein Gerät mit mehreren Links verwendet eMLSR über eine Reihe von Links, wenn es bestimmte grundlegende Steuerungsframes empfangen und gleichzeitig eine Clear Channel Assessment (CCA) für die Links durchführen kann. Der MLD überträgt oder empfängt jedoch jeweils nur Daten über eine Verbindung (die Verbindung, die in jedem TXOP-Zeitraum dynamisch ausgewählt wird).

Eine MLD-Station kann die Anzahl der Assoziationsverbindungen maximieren, um eine höhere Zuverlässigkeit, einen besseren Durchsatz und eine geringere Latenz zu erreichen (im Vergleich zu einer Legacy-Station mit einer einzelnen Verbindung), indem sie gleichzeitig in STR und eMLSR arbeitet, sofern der Chip dies unterstützt. In Abbildung 2 beträgt die maximale Anzahl von Verknüpfungen 3.

Die folgenden AIDL-HAL-Schnittstellen unterstützen die Funktion „Maximale Anzahl von Verknüpfungen“:

Gleichzeitige Bandkombinationen

Das Framework fragt den Chip über die AIDL-Schnittstelle IWifiChip.aidl nach den zulässigen Funkkombinationen ab, die gleichzeitig ausgeführt werden können. Aus diesen Informationen leitet das Framework mögliche gleichzeitige Bandkombinationen ab. Im Folgenden finden Sie eine Beispielliste mit gleichzeitigen Bandkombinationen (GHz):

  • 2.4
  • 5
  • 6
  • 2,4 × 5
  • 2,4 × 6
  • 5 × 6

Die folgende AIDL-HAL-Schnittstelle unterstützt gleichzeitige Funkkombinationen:

Netzwerkauswahl

Bei der Netzwerkauswahl (MLO) wird die Kandidatenliste nach Mitgliedern mit derselben MLD-MAC-Adresse gruppiert. Die maximale vorhergesagte Multi-Link-Durchsatzbewertung wird für jede Gruppe basierend auf der maximalen Anzahl von STR-Links und den vom Chip unterstützten gleichzeitigen Bandkombinationen berechnet. Wenn der Kandidat Multi-Link-fähig ist und der Chip STR unterstützt, wird der vorhergesagte Durchsatzwert durch den vorhergesagten Multi-Link-Durchsatzwert ersetzt. Dadurch werden MLO-Kandidaten bei der Netzwerkauswahl bevorzugt.

Beim Beitritt zu einem AP-MLD-Netzwerk wählt das Framework die SSID anhand von Informationen aus, die im ScanResults-Objekt enthalten sind und von der Software des Anbieters gemeldet werden. Nachdem das Framework die SSID ausgewählt hat, ist die Anbietersoftware dafür verantwortlich, die BSSID für den besten AP (oder AP-Link) auszuwählen, der für die Zuordnung verwendet werden soll.

Verarbeitung der STA-MAC-Adresse des Geräts

In diesem Abschnitt wird beschrieben, wie STA-MAC-Adressen von Geräten (MLD-MAC-Adressen und STA-MAC-Adressen pro Link) verarbeitet werden.

MLD-MAC-Adresse

Das WLAN-Framework verwaltet die MLD-MAC-Adresse des Geräts. Die MLD-MAC-Adresse wird genauso behandelt wie die MAC-Adresse eines Geräts ohne MLD. Die MAC-Adresse kann je nach Auswahl des Nutzers eine zufällige oder eine hardwareseitig bereitgestellte MAC-Adresse sein. Die MLD-MAC-Adresse wird vom Framework über die IWifiStaIface#setMacAddress()-HAL-API festgelegt.

Die STA-MAC-Adressen der Instanz (für jede Verbindung) werden von der Anbietersoftware verwaltet. Wenn ein Gerät einem AP zugeordnet wird, weist die Anbietersoftware jeder zugeordneten Verbindung eine Instanz-MAC-Adresse zu.

Die Anbietersoftware weist anhand ihres Algorithmus MAC-Adressen pro Link zu. Der Algorithmus muss wiederholbar sein und eine Funktion der folgenden Elemente sein:

  • STA-MLD-MAC-Adresse, die vom WLAN-Framework festgelegt wird.
  • Link-ID (vom AP erhalten)

Wenn das Framework also dieselbe MLD-MAC-Adresse wiederverwendet, muss der Anbieter dieselben zugehörigen MAC-Adressen pro Instanz wiederverwenden und umgekehrt. So wird sichergestellt, dass die vom Framework generierte STA-MLD-Adresse für eine SSID persistent ist und die MAC-Adressen pro STA ebenfalls persistent sind.

Im Folgenden finden Sie ein Beispiel für einen Algorithmus für die Zuweisung von STA-MAC-Adressen pro Link (Anbieter können jeden Algorithmus implementieren, der die Algorithmuskriterien erfüllt):

  • Oktett 0: Prüfen, ob das Bit für die lokale Verwaltung festgelegt ist
  • Oktett 1–4: Identisch mit der STA-MLD-MAC-Adresse
  • Oktett 5: Per-STA = (STA-MLD + Link-ID + 1) MOD (256)

Die Anbieter-Firmware kann Link-Wechsel durchführen und den Energiesparmodus der Links für die Aktivierung oder Deaktivierung ohne Eingabe des WLAN-Frameworks verwalten.

Das WLAN-Framework erwartet keine Benachrichtigung, wenn sich der Linkstatus ändert.

Verwaltung des Energiesparmodus

Der Energiesparmodus ist im WLAN-Framework standardmäßig aktiviert. Im Energiesparmodus verwaltet die Anbieter-Firmware den Energiesparmodus einzelner Links basierend auf Verkehrsmustern und Entscheidungen zur Aktivierung oder Deaktivierung von Links.

Das WLAN-Framework kann den Energiesparmodus jedoch durch Aufrufen der ISupplicantStaIface::setPowerSave(false)-HAL-API deaktivieren. Wenn der Energiesparmodus vom Framework deaktiviert wird, muss die Anbieter-Firmware mindestens eine aktive Verbindung aufrechterhalten (Energiesparmodus deaktiviert). In diesem Zustand wird durch die Firmware-Implementierung festgelegt, welcher Link gesetzt wird.

Datenpfad

Hier wird die Anbieter-Firmware-Implementierung für die Verarbeitung von Uplink- und Download-Traffic beschrieben.

Die Firmware leitet Uplink-Traffic basierend auf ihrer internen Implementierung an einen oder mehrere Links weiter. Die Firmware des Anbieters entscheidet anhand von Traffic-Mustern, wann Load-Balancing, Duplizierung oder Aggregation von Traffic erfolgen soll. Wir empfehlen, den Firmware-Duplikatverkehr in den folgenden Fällen auf mehrere Links zu verteilen:

  • Wenn der Modus für geringe Latenzzeit über die IWifiChip#setLatencyMode()-HAL-API festgelegt wird.
  • Wenn Traffic mit Nutzerpriorität 6 und 7 vorhanden ist.

Die Firmware muss die (Ziel-)MAC-Adresse des MAC-Headers pro STA durch die MLD-STA-MAC-Adresse und die (Quell-)MAC-Adresse des MAC-Headers pro AP durch die MLD-AP-MAC-Adresse ersetzen. Die Firmware muss diese MAC-Adressersetzung vor dem Durchlaufen des APF-Filters durchführen, da die APF-Filterbefehle Filter basierend auf MLD-MAC-Adressen haben. Es gibt einen einzelnen APF-Filter für alle Links einer AP-MLD.

Gleichzeitigkeit

Gleichzeitigkeitsszenarien, in denen ein Funkgerät für eine neue Schnittstelle verwendet wird, müssen Vorrang vor der Zuweisung mehrerer Funkgeräte für Links derselben Schnittstelle haben. Gleichzeitigkeitsszenarien haben immer Vorrang vor MLO, unabhängig davon, was zuerst kam. Die Verwendung mehrerer Links für eine einzelne Schnittstelle ist opportunistisch. Das bedeutet, dass mehrere Links nur verwendet werden, wenn:

  • MLO ist erforderlich basierend auf der Firmware-Entscheidung für Load Balancing, Aggregation oder Duplizierung.
  • MLO ist verfügbar, d. h., ein Funkgerät wird nicht von einer anderen Schnittstelle benötigt.

Wenn auf Geräten mit Android 14 oder höher ein Wi‑Fi 7-Zugangspunkt eine vorübergehende Deaktivierung einer der Verbindungen über ein TID-zu-Link-Mapping-Element ankündigt, das in Beacon-, Probe Response- und Association Response-Frames übertragen wird, setzt die Wi‑Fi 7-Station die Verbindung mit dem Zugangspunkt über die verbleibenden eingerichteten Verbindungen fort, ohne eine weitere Association durchzuführen.

Bei Geräten mit Android 13 oder niedriger unterstützt das WLAN-Framework nicht den Empfang von Benachrichtigungen, wenn sich der Linkstatus aufgrund der TID-zu-Link-Zuordnung ändert, auch wenn der zugehörige Link nicht mit einer TID verknüpft ist.

Der WLAN-Supplicant benachrichtigt das WLAN-Framework über Änderungen bei der Zuordnung von TID zu Link über die folgenden AIDL-Schnittstellen:

Apps können Informationen zu Änderungen bei der Zuordnung von Geräte-IDs zu Links über die folgenden APIs abrufen:

Auf Geräten mit Android 14 oder höher sind die folgenden APIs verfügbar, um die Verhandlungsfunktionen für die TID-zu-Link-Zuordnung für die Station und den AP abzurufen.

Chip-Funktion

Die folgenden Schnittstellen unterstützen die Chipfunktion für die Aushandlung der TID-zu-Link-Zuordnung.

AIDL-HAL

Die AIDL-Schnittstelle für die Aushandlung der TID-zu-Link-Zuordnung befindet sich in FeatureSetMask in hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl. Die Funktion T2LM_NEGOTIATION = 1 << 8 gibt an, dass der Chip die Zuordnung von TID zu Link unterstützt. APIs

AP-Funktion

Die folgenden Schnittstellen unterstützen die AP-Funktion für die Aushandlung der TID-zu-Link-Zuordnung.

AIDL-HAL

Das Framework fragt die AP-Funktion vom Supplicant zusammen mit der aktuellen Verbindungsfunktion ab.

APIs

Die Statistiken der Link-Schicht enthalten WLAN-Link-spezifische Details wie RSSI, verschiedene TX- und RX-Paketzähler sowie Funkstatistiken. Das WLAN-Framework fragt regelmäßig Statistiken der Link-Ebene und RSSI ab, um das beste Netzwerk auszuwählen oder die Qualität des verbundenen Netzwerks zu bewerten. Bei Geräten mit Android 14 oder höher enthalten die Statistiken der Verbindungsschicht Unterstützung für mehrere Verbindungen. Zur Unterstützung von Wi‑Fi 7 unterstützt Android MLO sowohl in Link Layer-Statistiken als auch beim Signal-Polling.

Linkspezifische Statistiken finden Sie in den folgenden AIDL-Schnittstellen der Linkebene:

Die System-API android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() überwacht alle Statistiken der Link-Ebene. Das Framework ruft diese API regelmäßig auf, um Statistiken zur WLAN-Nutzbarkeit zu aktualisieren.

Die folgenden linkbezogenen APIs sind in android.net.wifi.WifiUsabilityStatsEntry verfügbar.

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)

Um verfügbare Link-IDs abzufragen, können Apps die Methode android.net.wifi.WifiUsabilityStatsEntry#getLinkIds() aufrufen.

APIs in android.net.wifi.WifiUsabilityStatsEntry für einzelne Links (nicht MLO) geben die aggregierten Statistiken für MLO-Verbindungen zurück. Es gelten die folgenden Aggregationskriterien:

  • Für die folgenden aggregierten Paketstatistiken wird die Summe der Statistiken pro Link verwendet:

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

  • Für die folgenden Statistiken werden die Daten des Links mit dem höchsten RSSI verwendet:

    public int getRssi()
public int getLinkSpeedMbps()
public long getTotalBeaconRx()
public int getTimeSliceDutyCycleInPercent()
public ContentionTimeStats getContentionTimeStats(@WmeAccessCategory int ac)
public List<RateStats> getRateStats()

Bei Geräten mit Android 13 werden bei den Statistiken der Link-Ebene nicht mehrere Links für eine einzelne Schnittstelle berücksichtigt. Um MLO zu unterstützen, muss die Software des Anbieters die folgende Aggregationslogik anwenden, wenn LinkLayerStats über die IWifi# getLinkLayerStats_1_6()-HAL-API gemeldet wird. Der beste Link ist der mit dem höchsten RSSI.

  • StaLinkLayerStats.iface.beaconRx: Melden Sie die Anzahl der Beacons für den besten Link, der für die Schnittstelle verwendet wird.
  • StaLinkLayerStats.iface.avgRssiMgmt: Melden Sie avgRssiMgmt für den besten Link, der für die Schnittstelle verwendet wird.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk): Melden Sie die aggregierten Paketstatistiken (gesamt) für die Links der Schnittstelle.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be, Bk): Melden Sie die Statistiken zur Konfliktzeit für die beste Verbindung, die auf der Schnittstelle verwendet wird (Statistiken zur niedrigsten Konfliktzeit).

Wenn einer der Links des WLAN‑7-Zugangspunkts umfunktioniert wird, kann der Zugangspunkt die Entfernung des Links durch die MLO-Link-Neukonfiguration ankündigen. Die Stationen können eine nahtlose Verbindung zum AP aufrechterhalten, ohne dass eine erneute Zuordnung auf den verbleibenden Links erforderlich ist.

Die AIDL-Schnittstelle onMloLinksInfoChanged im WLAN-Supplicant unter ISupplicantStaIfaceCallback.aidl unterstützt die Link-Neukonfiguration (Entfernen des Links durch den AP).

Wenn das WLAN-Framework das Entfernen einer Verbindung verarbeitet, wird der Verbindungsstatus auf MLO_LINK_STATE_UNASSOCIATED gesetzt. Das Framework löst dann ConnectivityManager.NetworkCallback#onCapabilitiesChanged() für eine Änderung des Linkstatus aus.

Die Methode WifiInfo#getAffiliatedMloLinks gibt die verknüpften MLO-Links zurück. Die Methode MloLink#getState gibt den Status der Verknüpfung zurück. Wenn der Link entfernt wird, ist der zurückgegebene Linkstatus MLO_LINK_STATE_UNASSOCIATED.

Chip-MLO-Strategie

Mit MLO können Geräte gleichzeitig Daten über mehrere WLAN-Verbindungen senden und empfangen. Das kann die Leistung von Apps mit besonderen Anforderungen wie geringer Latenz, hoher Bandbreite und geringem Stromverbrauch verbessern. Chiphersteller können Algorithmen für die Verwendung der verfügbaren Links entwickeln.

Privilegierte Apps können diese Algorithmen mit der Methode setMloMode in Wifimanager ändern und die folgenden Modi festlegen:

  • MLO_MODE_DEFAULT = 0
  • MLO_MODE_LOW_LATENCY = 1
  • MLO_MODE_HIGH_THROUGHPUT = 2
  • MLO_MODE_LOW_POWER = 3

Das Framework verwendet setMloMode in der AIDL-Schnittstelle IWifiChip, um den MLO-Modus festzulegen.