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 Wi‑Fi 7-Funktionen von Android beschrieben, einschließlich Baseline- und Multi-Link-Betrieb (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.

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 config_wifi11beSupportOverride-Konfigurations-Overlay als Überschreibung verwendet wird. Dabei geschieht Folgendes:

  • 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 ZP 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(). Bei der Implementierung dieser HAL API in der wpa_supplicant-AIDL-Ebene wird geprüft, ob sich EHT Capability IE während der Verbindungseinrichtung sowohl in AssocReq als auch in AssocRsp befindet.

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. So können Wi‑Fi 7-bezogene Funktionen in RTT-Bereichen unterstützt werden, sofern sie vom Chip unterstützt werden.

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 Abstandsmessung 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.

Informationen zum Soft-AP 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 Soft-AP-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-Informationen so:

  • 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 verbundenen Links zu lesen.

APIs

Um gescannte Informationen zu MLOs von Ladestationen abzurufen, können Apps die folgenden APIs verwenden:

Informationen zum verbundenen Wi-Fi 7-Zugangspunkt

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 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 vom ZP empfangenen ScanResult-Objekt. 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 jeden empfangenen 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.
  • Es werden möglicherweise nur teilweise Scanergebnisse für die ZP-Links eines ZP-MLD empfangen, da einige dieser Linksignale möglicherweise nicht von der Firmware 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 der erfolgreichen 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 Scanergebnisse für diesen Link an das Framework gesendet 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 Armbandkombinationen

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. STR unterscheidet sich von älteren STAs mit einem einzelnen Link (SL) und älteren STAs mit doppelter Bandbreite und doppelter Gleichzeitigkeit (DBDC). STAs, die mit einer STA-MLD verbunden sind, teilen sich eine gemeinsame Sendersequenznummer (SN) und einen gemeinsamen Bereich für die Datenübertragung, der verschiedenen Verbindungen zugewiesen wird, wenn mehrere Verbindungen dieselbe Zugriffskategorie (AC) 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 Verknüpfungs-Link-Funktionen:

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 Multi-Link-Gerät verwendet eMLSR über mehrere Links, wenn es bestimmte grundlegende Steuerframes empfangen und gleichzeitig eine CCA (Clear Channel Assessment) auf den Links ausführen kann. Allerdings überträgt oder empfängt das MLD jeweils nur Daten über einen Link (den Link, der in jedem TXOP-Zeitraum (Transmit Opportunity) dynamisch ausgewählt wird).

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 maximale Anzahl von Verknüpfungslinks:

Gleichzeitige Armbandkombinationen

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 × 6
  • 5 × 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 basierend auf den 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 dieselbe 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). Wenn ein Gerät mit einem ZP verbunden wird, weist die Anbietersoftware jeder verknüpften Verbindung eine MAC-Instanzadresse zu.

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

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

Das bedeutet, dass der Anbieter dieselbe MLD-MAC-Adresse wiederverwenden muss, wenn das Framework dieselbe MAC-Adresse verwendet, die der Instanz zugeordnet ist, 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
  • Oktett 1–4: Entspricht der MAC-Adresse der STA-MLD
  • Oktett 5: 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 Firmware des Anbieters den Energiesparmodus der einzelnen Links basierend auf den Verkehrsmustern und Entscheidungen zur Aktivierung oder Deaktivierung von Links.

Das Wi‑Fi-Framework kann den Energiesparmodus jedoch erzwingen, indem es die ISupplicantStaIface::setPowerSave(false) HAL API aufruft. Wenn der Energiesparstatus vom Framework deaktiviert wird, muss die Firmware des Anbieters mindestens einen Link aktiv halten (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 den 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.
  • Wenn es Traffic mit Nutzerpriorität 6 und 7 gibt.

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 einzelnen APF-Filter für alle Links einer AP-MLD.

Gleichzeitigkeit

Bei Parallelitätsszenarien, in denen ein Funkschnittstellenmodul für eine neue Schnittstelle verwendet wird, müssen diese Vorrang vor der Verwendung mehrerer Funkschnittstellenmodule für Verbindungen derselben Schnittstelle haben. Szenarien für Parallelität müssen auch Vorrang vor MLO haben, unabhängig davon, welches zuerst eingetreten ist. Die Verwendung mehrerer Links für eine einzelne Schnittstelle ist opportunistisch, d. h., 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 auf Geräten mit Android 14 oder höher der Wi‑Fi 7-Zugangspunkt eine vorübergehende Deaktivierung eines der Links über ein TID-zu-Link-Zuordnungselement ankündigt, das in Beacon-, Probe-Response- und Association-Response-Frames übertragen wird, stellt die Wi‑Fi 7-Station die Verbindung mit dem Zugangspunkt über die verbleibenden eingerichteten Links fort, ohne eine weitere Verknüpfung durchzuführen.

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 TID-zu-Link-Zuordnungsfunktionen für die Station und den ZP abzurufen.

Chipfunktion

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

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 vom 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 Bitübertragungsschicht als auch bei der Signalabfrage.

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

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 der Verbindung 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 Sicherungsschicht nicht berücksichtigt, ob mehrere Links für eine einzelne Schnittstelle verwendet werden. Zur Unterstützung von MLO muss die Anbietersoftware beim Melden von LinkLayerStats über die IWifi# getLinkLayerStats_1_6() HAL API die folgende Aggregationslogik anwenden. Die beste Verbindung ist die 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): Hier werden die aggregierten Paketstatistiken (insgesamt) über die Links der Schnittstelle erfasst.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk): Hier werden die Statistiken zur Beanspruchungszeit für den besten Link auf der Schnittstelle erfasst (niedrigste Statistiken zur Beanspruchungszeit).

Wenn einer der Links des Wi‑Fi 7-Zugangspunkts umfunktioniert wird, kann der Zugangspunkt das Entfernen des Links über die MLO-Link-Neukonfiguration ankündigen. Stationen können eine nahtlose Verbindung zum ZP aufrechterhalten, ohne dass eine erneute Verknüpfung der verbleibenden Verbindungen erforderlich ist.

Die AIDL-Schnittstelle onMloLinksInfoChanged im Wi‑Fi-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.