Wi-Fi 7

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

Baseline Wi-Fi 7-Funktionen

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

Wi‑Fi 7-Unterstützung des Geräts

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 Konfigurations-Overlay config_wifi11beSupportOverride als Überschreibung verwendet wird, und führt Folgendes aus:

  • Wenn das Overlay auf true gesetzt ist, wird davon ausgegangen, dass das Gerät unabhängig von der Antwort von nl80211 Wi‑Fi 7 unterstützt. Diese Überschreibung ist nur für Gerätehersteller nützlich, die keine Treiber haben, die die Unterstützung von Wi‑Fi 7 zurückgeben.
  • Wenn das Overlay auf false (Standardwert) gesetzt ist, verwendet das WLAN-Modul die Informationen von nl80211. Das WLAN-Modul fordert die Informationen von wificond an, das den Befehl nl80211 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.

Gescannter ZP mit Wi‑Fi 7-Unterstützung

Das Android-Framework enthält die int ScanResult#getWifiStandard() API, die Apps aufrufen können, um zu prüfen, ob ein gescannter Zugangspunkt (AP) Wi‑Fi 7 unterstützt. Wenn der ZP Wi‑Fi 7 unterstützt, gibt die API ScanResults.WIFI_STANDARD_11BE zurück. Das Gerät muss nicht WLAN 7 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-WifiTracker-Klasse 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 Verbindungsmodus der Station (STA) Wi‑Fi 7 ist. Der STA-Verbindungsmodus ist Wi‑Fi 7, wenn sowohl das Gerät als auch der verbundene ZP Wi‑Fi 7 unterstützen. Wenn der Verbindungsmodus Wi-Fi 7 ist, gibt die API ScanResults.WIFI_STANDARD_11BE zurück.

Wenn getWifiStandard aufgerufen wird, bestimmt das WLAN-Modul den Modus durch Aufrufen der HAL-API ISupplicantStaIface#getConnectionCapabilities(). Die Implementierung dieser HAL API auf der AIDL-Ebene wpa_supplicant prüft beim Einrichten der Verbindung, ob EHT Capability IE sowohl in AssocReq als auch in AssocRsp enthalten ist.

Netzwerkauswahl

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

In Android 13 verwendet ThroughputPredictor bei der Berechnung die folgenden AP-Funktionen:

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

Wenn Sie diese Funktionen in die ThroughputPredictor-Logik einbeziehen, erhöht sich die Wahrscheinlichkeit, dass WLAN 7-kompatible ZP ausgewählt werden, wenn das Gerät diese Funktionen nutzen kann.

RTT-basierte WLAN-Messung

Android bietet API-Unterstützung für EHT-Präambel und 320 MHz Kanalbreite für Wi‑Fi RTT. Dies ermöglicht die Unterstützung von Wi-Fi 7-bezogenen Funktionen in der RTT-Bereichsauswahl, wenn dies vom Chip unterstützt wird.

HAL APIs

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

APIs

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

Soft-AP

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

Soft-AP starten

Android unterstützt das Starten von Soft-APs im WLAN 7-Modus. Dies wird durch die config_wifiSoftapIeee80211beSupported-Overlay-Konfiguration gesteuert.

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 Wi‑Fi 7-Modus.

Soft AP-Informationen melden

Android unterstützt die API, um Informationen zu Wi‑Fi 7 und zur Kanalbreite von 320 MHz in die gemeldeten Soft-AP-Informationen aufzunehmen.

HAL APIs

Die Konstante WIFI_STANDARD_11BE in der Generation.aidl-AIDL-Schnittstelle in der 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 SoftAP-Informationen zu melden.

MLO Wi-Fi 7-Funktionen

Der Multi-Link-Betrieb (MLO) ist die Hauptfunktion der Wi‑Fi 7-Spezifikation (802.11be). MLO ist eine obligatorische Funktion für Multi-Link-Geräte (MLD), die unter Wi‑Fi 7 ausgeführt werden, unabhängig davon, ob sie gleichzeitig oder nicht gleichzeitig ausgeführt werden.

MLO-Diagramm

Abbildung 1: MLO-Diagramm.

Wie in Abbildung 1 dargestellt, haben sowohl die AP-MLD als auch die STA-MLD mehrere AP- oder STA-Instanzen, die auf jedem Link ausgeführt werden. Jeder Link hat eine separate MAC-Adresse für ZP oder STA. Der ZP oder 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 WLAN 7-Zugangspunkte

Apps können die MLO-Parameter für einen Wi‑Fi 7-AP-MLD abrufen, wenn das WLAN-Modul ein ScanResult-Objekt vom AP-MLD empfängt. Die AOSP-WifiTracker zeigt die MLO-Parameter an, wenn sie im ausführlichen Modus ausgeführt wird.

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

  • Hier wird das Multi-Link-Informationselement (IE) geparst, das im Beacon oder in der Antwort auf die Probe enthalten ist, um die MAC-Adresse des MLP des ZP und die aktuelle Link-ID zu lesen.
  • Hier wird das IE „Reduced Neighbor Report“ (RNR) geparst, das in der Beacon- oder Probeantwort enthalten ist, um die Liste der Informationen zu den verknüpften Links zu lesen.

APIs

Zum Abrufen gescannter AP-MLO-Informationen können Apps die folgenden APIs verwenden:

Verbundenes WLAN 7 AP MLO-Informationen

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-WifiTracker-Objekt zeigt diese Informationen im ausführlichen Modus an.

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

APIs

Um MLO-Verbindungsinformationen abzurufen, können Apps die folgenden APIs verwenden:

AP-MLD-Scan

Die Anbietersoftware stellt dem Wi‑Fi-Framework die Scanergebnisse für jedes empfangene Beacon oder jede empfangene Probeantwort zur Verfügung. Das bedeutet, dass das Wi-Fi-Framework

  • Es können mehrere ScanResults-Objekte von derselben AP-MLD empfangen werden, da der Zugangspunkt mehrere Beaconing-Links haben kann.
  • Möglicherweise erhält nur ein Teil der Scanergebnisse für die AP-Links eines AP-MLD, da einige dieser Linksignale von der Firmware möglicherweise nicht empfangen werden.

Die Anbietersoftware darf nur Scanergebnisse melden, die per Funk empfangen wurden. Sie darf keine Scanergebnisse auf der Grundlage von von der AP-MLD beworbenen Links erstellen (künstlich synthetisieren).

Die Anbietersoftware muss die grundlegenden Varianten der Multi-Link- und RNR-IEs enthalten, die von den AP-Instanzen in den gemeldeten Scanergebnissen empfangen wurden. Wenn in den Scanergebnissen keine Details zu verbundenen ZP fehlen, kann die Anbietersoftware Multi-Link-Sondenanfragen senden (Sondenanfrage-Frame mit einem Multi-Link-Element für die Sondenanfrage), um die vollständigen oder teilweisen Funktionen, Parameter und Betriebselemente des ZP mit der Ziel-ZP-MLD in den Antwortframe aufzunehmen.

Die Anbietersoftware kann bei Bedarf ML-Prüfungen auslösen (mithilfe der Probe-Req-Variante „ML IE“ im Probe-Req-Frame).

AP-MLD-Netzwerkverknüpfung

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

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

Netzwerkbewertung

Auf Geräten mit Android 14 oder höher wird Wi‑Fi 7 MLO von der Android-WLAN-Netzwerkauswahl 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 Netzwerkauswahlalgorithmus die folgenden MLO-Funktionen des WLAN-Chips:

  • Maximale Anzahl von STR-Links
  • Maximale Anzahl von Verknüpfungslinks
  • Gleichzeitige Kombinationen von Bändern

Auswahl des Wi-Fi MLO-Netzwerks

Abbildung 2. MLO-Netzwerkauswahl

Simultaneous Transmit and Receive (STR) ist ein Wi‑Fi-Medium-Konfliktverfahren für den Multi-Link-Betrieb. Die Signalisolierung zwischen den verschiedenen Verbindungen ist ausreichend, damit die Verbindungen unabhängig voneinander arbeiten und gleichzeitig in verschiedenen Verbindungen senden und empfangen können. Die STR unterscheidet sich von Legacy-Single-Link-STA und Legacy-Dual-Band-Dual-Band-STA (Dual-Band-Dual-Band-STA), die mit STA MLD verknüpft ist. Sie haben eine gemeinsame Sendersequenznummer (SN) und einen gemeinsamen Raum für die Datenübertragung, der verschiedenen Links zugewiesen ist, wenn mehrere Links die gleiche Zugriffskategorie haben.

Die maximale Anzahl der verwendeten STR-Links kann von der maximalen Anzahl der vom Chip unterstützten Funkschnittstellen abweichen. 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 Funktionen zum Zählen von Verknüpfungslinks:

Mehrere Links können mit dem CSMA/CA-Verfahren (Carrier Sense Multiple Access/Collision Avoidance) „Enhanced Multi-Link Single Radio“ (eMLSR) über ein einziges Funkgerät betrieben werden. Ein Mehrfachverbindungsgerät verwendet eMLSR über eine Reihe von Links, wenn es bestimmte grundlegende Kontrollframes empfangen und gleichzeitig die Clear Channel Assess (CCA) für diese Verbindungen durchführen kann. Das MLD überträgt oder empfängt jedoch Daten immer nur über eine Verbindung (die Verbindung, die dynamisch in jeder Übertragungsmöglichkeit (TXOP) ausgewählt wird) gleichzeitig.

Eine MLD-Station kann die Anzahl der Verknüpfungslinks maximieren, um eine bessere Zuverlässigkeit, einen besseren Durchsatz und eine geringere Latenz zu erzielen (im Vergleich zu einer Legacy-Station mit einem einzelnen Link). Dazu muss sie gleichzeitig in STR und eMLSR betrieben werden, sofern dies vom Chip unterstützt wird. In Abbildung 2 ist die maximale Anzahl der Verknüpfungslinks 3.

Die folgenden AIDL HAL-Schnittstellen unterstützen die Funktion zur maximalen Anzahl von Verknüpfungslinks:

Gleichzeitige Kombinationen von Bändern

Das Framework fragt den Chip ab, um die zulässigen Funkkombinationen (über die IWifiChip.aidl AIDL-Schnittstelle) zu erhalten, die gleichzeitig betrieben werden können. Anhand dieser 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 x 6
  • 5 x 6

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

Netzwerkauswahl

Bei der Netzwerkauswahl (MLO) wird die Kandidatenliste nach Mitgliedern mit derselben MLD-MAC-Adresse gruppiert. Der maximale prognostizierte Multi-Link-Durchsatz wird für jede Gruppe basierend auf der maximalen STR-Link-Anzahl und den vom Chip unterstützten gleichzeitigen Bandkombinationen berechnet. Wenn der Kandidat für mehrere Verbindungen geeignet ist und der Chip STR unterstützt, wird der vorhergesagte Durchsatzwert durch den vorhergesagten Durchsatzwert für mehrere Verbindungen ersetzt. Das gibt MLO-Kandidaten bei der Auswahl des Netzwerks einen Vorteil.

Wenn ein AP-MLD-Netzwerk beigetreten wird, führt das Framework die SSID-Auswahl anhand der Informationen aus, die im ScanResults-Objekt von der Anbietersoftware empfangen wurden. Nach der Auswahl der SSID durch das Framework ist die Anbietersoftware für die Auswahl der BSSID für den besten ZP (oder ZP-Link) verantwortlich, der für die Verknüpfung verwendet werden soll.

MAC-Adressen-Verwaltung der STAs von Geräten

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 auf die gleiche Weise behandelt wie die MAC-Adresse eines Nicht-MLD-Geräts. Die MAC-Adresse kann eine zufällige MAC-Adresse oder eine von der Hardware bereitgestellte MAC-Adresse sein, je nach Auswahl des Nutzers. Die MLD-MAC-Adresse wird vom Framework mithilfe der IWifiStaIface#setMacAddress() HAL API festgelegt.

Die Anbietersoftware verwaltet die MAC-Adressen der Instanz-STAs (für jeden Link). Bei der Verknüpfung eines Geräts mit einem ZP weist die Anbietersoftware jeder zugehörigen Verbindung eine MAC-Adresse der Instanz zu.

Die Anbietersoftware weist MAC-Adressen pro Link basierend auf ihrem Algorithmus zu. Der Algorithmus muss reproduzierbar sein und eine Funktion der folgenden Faktoren sein:

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

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

Im Folgenden finden Sie einen Beispielalgorithmus für die MAC-Adresszuweisung von STAs 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 gesetzt ist
  • 1.–4. Okt.: Wie STA-MLD-MAC-Adresse
  • 5. Okt.: Pro-STA = (STA-MLD + Link-ID + 1) MOD (256)

Die Firmware des Anbieters kann die Link-Umschaltung ausführen und den Energiesparstatus der Links für die Aktivierung oder Deaktivierung verwalten, ohne dass Eingaben vom WLAN-Framework erforderlich sind.

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

Energiesparmodus verwalten

Der Energiesparmodus ist im WLAN-Framework standardmäßig aktiviert. Im Energiesparmodus verwaltet die Anbieterfirmware den Energiesparmodus einzelner Verbindungen anhand von Traffic-Mustern und Entscheidungen zur Aktivierung oder Deaktivierung.

Das WLAN-Framework kann jedoch erzwingen, dass der Energiesparmodus deaktiviert wird, indem die ISupplicantStaIface::setPowerSave(false) HAL API aufgerufen wird. Wenn der Energiesparmodus vom Framework deaktiviert wird, muss die Anbieterfirmware mindestens eine Verbindung aktiv lassen (Energiesparmodus deaktiviert). In diesem Status entscheidet die Firmwareimplementierung, welcher Link festgelegt wird.

Datenpfad

Hier wird die Firmwareimplementierung des Anbieters 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 durchgeführt werden soll. Wir empfehlen, den Traffic in den folgenden Fällen mit der Firmware auf mehrere Links zu duplizieren:

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

Die Firmware muss die MAC-Adresse (Ziel) pro STA des MAC-Headers durch die MLD-STA-MAC-Adresse und die MAC-Adresse (Quelle) pro AP des MAC-Headers durch die MLD-AP-MAC-Adresse ersetzen. Die Firmware muss diese MAC-Adresssubstitution ausführen, bevor sie den APF-Filter passiert, da die APF-Filterbefehle auf MLD-MAC-Adressen basieren. Es gibt einen einzigen APNF-Filter für alle Links einer AP-MLD.

Gleichzeitigkeit

Nebenläufigkeitsszenarien, bei denen ein Funkschnittstelle für eine neue Oberfläche verwendet wird, müssen Vorrang vor der Zuweisung mehrerer Funkschnittstellen für Verbindungen derselben Schnittstelle haben. Parallelitätsszenarien müssen auch Vorrang vor MLO haben, unabhängig davon, welches zuerst eintritt. Die Verwendung mehrerer Links für eine einzelne Schnittstelle ist opportunistisch. Das bedeutet, dass mehrere Links nur in folgenden Fällen verwendet werden:

  • MLO ist erforderlich, basierend auf der Firmwareentscheidung für Load Balancing, Aggregation oder Duplizierung.
  • MLO ist verfügbar, d. h., ein Funkschnittstellenmodul wird von keiner anderen Schnittstelle benötigt.

Wenn der Wi-Fi 7 AP bei Geräten mit Android 14 oder höher die vorübergehende Deaktivierung einer der Verbindungen über ein TID-zu-Link-Zuordnungselement ankündigt, das in Beacon-, Sondereaktions- und Zuordnungsantwortframes übertragen wird, hält die Wi-Fi 7-Station die Verbindung mit dem AP mithilfe der verbleibenden Verbindungen, die eingerichtet sind, ohne eine weitere Verknüpfung fort.

Auf Geräten mit Android 13 oder niedriger wird vom WLAN-Framework nicht unterstützt, Benachrichtigungen zu erhalten, wenn sich der Linkstatus aufgrund der Zuordnung von TIDs zu Verbindungen ändert, auch wenn die zugehörige Verbindung nicht mit einer TID verknüpft ist.

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

Mit den folgenden APIs können Apps Informationen zu Änderungen bei der Zuordnung von TIDs zu Verbindungen abrufen:

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

Chipfunktion

Die folgenden Oberflächen unterstützen die Chipfunktion für die Verhandlung zwischen TID und Link.

AIDL HAL

Die AIDL-Schnittstelle für die Verhandlung der Zuordnung von TIDs zu Verbindungen 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 TIDs zu Verbindungen unterstützt. APIs

ZP-Funktion

Die folgenden Schnittstellen unterstützen die AP-Funktion für die Verhandlung der Zuordnung von TIDs zu Verbindungen.

AIDL HAL

Das Framework fragt die ZP-Funktion des Supplicant zusammen mit der aktuellen Verbindungsfunktion ab.

APIs

Die Statistiken der Sicherungsschicht umfassen WLAN-spezifische Details wie RSSI, verschiedene TX- und RX-Paketzähler sowie Funkstatistiken. Das WLAN-Framework führt regelmäßig Umfragen zu Statistiken der Sicherungsschicht und zum RSSI durch, um das beste Netzwerk auszuwählen oder die Qualität des verbundenen Netzwerks zu bewerten. Bei Geräten mit Android 14 oder höher umfassen die Statistiken der Sicherungsschicht die Unterstützung mehrerer Verbindungen. Zur Unterstützung von Wi‑Fi 7 unterstützt Android MLO sowohl bei Statistiken der Sicherungsschicht als auch bei der Signalabfrage.

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

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

Die folgenden linkspezifischen 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 einen einzelnen Link (nicht MLO) geben die zusammengefassten Statistiken für MLO-Verbindungen zurück. Folgende Aggregationskriterien sind verfügbar:

  • Für die folgenden zusammengefassten 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 wird bei den Statistiken der Linkebene nicht die Nutzung mehrerer Links für eine einzelne Schnittstelle berücksichtigt. Zur Unterstützung von MLO muss die Anbietersoftware die folgende Aggregationslogik anwenden, wenn LinkLayerStats über die IWifi# getLinkLayerStats_1_6() HAL API gemeldet wird. Der beste Link ist der Link mit dem höchsten RSSI.

  • StaLinkLayerStats.iface.beaconRx: Die Anzahl der Beacons für die beste Verbindung, die für die Benutzeroberfläche verwendet wird.
  • StaLinkLayerStats.iface.avgRssiMgmt: Geben Sie avgRssiMgmt für die beste Verbindung an, die für die Schnittstelle verwendet wird.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk): Die aggregierten Paketstatistiken (insgesamt) werden über die Links der Schnittstelle gemeldet.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be, Bk): Hier werden die Statistiken zur Beanspruchungszeit für den besten Link erfasst, der auf der Schnittstelle verwendet wird (niedrigste Statistiken zur Beanspruchungszeit).

Wenn einer der Verbindungen des Wi-Fi 7-Zugangspunkts wiederverwendet wird, kann der AP die Entfernung der Verbindung durch Neukonfiguration der MLO-Verbindung ankündigen. Stationen können eine nahtlose Verbindung zum ZP aufrechterhalten, ohne dass eine erneute Verknüpfung der verbleibenden Links erforderlich ist.

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

Wenn das WLAN-Framework das Entfernen eines Links verarbeitet, wird der Linkstatus auf MLO_LINK_STATE_UNASSOCIATED gesetzt. Das Framework löst dann einen Linkstatuswechsel für ConnectivityManager.NetworkCallback#onCapabilitiesChanged() aus.

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

Chip-MLO-Strategie

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

Berechtigte 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 IWifiChip-AIDL-Schnittstelle, um den MLO-Modus festzulegen.