WLAN 7

Für Geräte 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 (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 für Wi-Fi 7 des Geräts

Das Android-Framework umfasst die API WifiManager#isWifiStandardSupported(int standard) , 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 Wi-Fi-Modul, ob das Konfigurations-Overlay config_wifi11beSupportOverride als Override verwendet wird, und führt Folgendes 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 Außerkraftsetzung ist nur für Gerätehersteller nützlich, die keine Treiber haben, die Wi-Fi 7 unterstützen.
  • Wenn das Overlay auf false (Standardwert) eingestellt ist, verwendet das Wi-Fi-Modul die Informationen von nl80211. Das Wi-Fi-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.

Gescannter AP Wi-Fi 7-Unterstützung

Das Android-Framework enthält die int ScanResult#getWifiStandard() API, die Apps aufrufen können, um zu überprüfen, ob ein gescannter Access Point (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 Wi-Fi-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 Unterstützungsinformationen in der Benutzeroberfläche an, wenn sie im ausführlichen Modus ausgeführt wird.

STA-Verbindungsmodus

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

Wenn getWifiStandard aufgerufen wird, bestimmt das Wi-Fi-Modul den Modus durch Aufrufen der HAL-API ISupplicantStaIface#getConnectionCapabilities() . Die Implementierung dieser HAL-API in der AIDL-Schicht wpa_supplicant prüft, ob sich EHT Capability IE während des Verbindungsaufbaus sowohl in AssocReq als auch in AssocRsp befindet.

Netzwerkauswahl

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

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

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

Die Einbeziehung dieser Funktionen in ThroughputPredictor Logik erhöht die Chancen für die Auswahl von Wi-Fi 7-fähigen APs, wenn das Gerät diese Funktionen nutzen kann.

Wi-Fi RTT-basierte Entfernungsmessung

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

HAL-APIs

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

APIs

Apps können die folgenden APIs für Wi-Fi 7 RTT-basiertes Ranging verwenden:

Soft-AP

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

Starten Sie Soft AP

Android unterstützt das Starten von Soft AP im Wi-Fi 7-Modus. Dies wird durch die Overlay-Konfiguration config_wifiSoftapIeee80211beSupported geregelt.

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

HAL-APIs

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

Soft-AP-Informationen melden

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

HAL-APIs

Die WIFI_STANDARD_11BE Konstante in der AIDL-Schnittstelle Generation.aidl in der hostapd-HAL, die in der im IHostapdCallback#onApInstanceInfoChanged() Rückruf gemeldeten ApInfo verwendet wird, unterstützt die Meldung 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 das Hauptmerkmal der Wi-Fi 7 (802.11be)-Spezifikation. MLO ist eine obligatorische Funktion für Multi-Link-Geräte (MLD), die gleichzeitig oder nicht gleichzeitig in Wi-Fi 7 ausgeführt werden.

MLO-Diagramm

Abbildung 1. MLO-Diagramm.

Wie in Abbildung 1 dargestellt, verfügen sowohl AP-MLD als auch STA-MLD über mehrere AP- oder STA-Instanzen, die auf jeder Verbindung ausgeführt werden. Jeder Link verfügt über eine separate AP- oder STA-MAC-Adresse. Der AP oder STA verfügt außerdem über eine MLD-MAC-Adresse zur Identifizierung des Geräts.

Die Klasse android.net.wifi.MloLink repräsentiert den MLO-Link. Diese Klasse umfasst die folgenden Parameter:

Gescannte Wi-Fi 7 AP MLO-Informationen

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

Das Wi-Fi-Modul sammelt die MLO-Informationen wie folgt:

  • Analysiert das in der Beacon- oder Probe-Antwort enthaltene Multi-Link-Informationselement (IE), um die AP-MLD-MAC-Adresse und die aktuelle Link-ID zu lesen.
  • Analysiert den RNR-IE (Reduced Neighbor Report), der in der Beacon- oder Probe-Antwort enthalten ist, um die Liste der Informationen zu verbundenen Links zu lesen.

APIs

Um gescannte AP-MLO-Informationen zu erhalten, können Apps die folgenden APIs verwenden:

MLO-Informationen zum verbundenen Wi-Fi 7 AP

Wenn ein Gerät eine Verbindung zu einem Wi-Fi 7 AP-MLD herstellt, erfasst das Framework die MLO-Parameter der Verbindung vom 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 Wi-Fi-Modul die MLO-Informationen aus dem vom AP empfangenen ScanResult Objekt. Das Modul ruft dann die HAL-API ISupplicantStaIface#getConnectionMloLinksInfo() auf, um die MAC-Adressen jedes Links für AP und 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-Scannen

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

  • Empfängt möglicherweise mehrere ScanResults Objekte von demselben AP-MLD (da der AP über mehrere Beaconing-Links verfügen kann).
  • Empfängt möglicherweise nur einen Teilsatz der Scan-Ergebnisse für die AP-Links eines AP-MLD, da einige dieser Link-Signale möglicherweise nicht von der Firmware empfangen werden.

Die Software des Anbieters meldet nur drahtlos empfangene Scan-Ergebnisse und darf keine Scan-Ergebnisse basierend auf vom AP-MLD angekündigten Links erstellen (künstlich synthetisieren).

Die Anbietersoftware muss die von den AP-Instanzen empfangenen Multi-Link- und RNR-IEs der Basisvariante in die gemeldeten Scan-Ergebnisse einbeziehen. Wenn zugehörige AP-Details in den Scan-Ergebnissen fehlen, kann die Software des Anbieters Multi-Link-Probe-Anfragen (Probe-Request-Frame, der ein Probe-Request-Multi-Link-Element enthält) senden, um den vollständigen oder teilweisen Satz von Funktionen, Parametern und Betriebselementen einzubeziehen des AP mit der angestrebten AP-MLD im Antwortrahmen.

Die Software des Anbieters kann bei Bedarf ML-Probing auslösen (unter Verwendung der Probe-Req-Variante ML IE im Probe-Req-Frame).

AP-MLD-Netzwerkassoziation

Wenn ein Gerät einem AP-MLD-Netzwerk beitritt, verwendet die Software des Anbieters den ausgewählten AP-Link (zugeordneter Link) zur Signalisierung. Die Herstellersoftware kann alle oder einige der vom Gerät unterstützten Links verknüpfen.

Bei erfolgreicher Zuordnung meldet der Treiber ISupplicantStaIfaceCallback#onStateChanged() mit der BSSID eines Links für den AP-MLD. Der Treiber wählt dann einen Link des AP-MLD aus, vorausgesetzt, dass Scanergebnisse für diesen Link an das Framework gemeldet wurden.

Netzwerkbewertung

Für Geräte mit Android 14 oder höher unterstützt die Android Wi-Fi Network Selection Wi-Fi 7 MLO. Das bedeutet, dass Android basierend auf der Anzahl der für MLO verfügbaren Links das beste Wi-Fi-Netzwerk für das Gerät auswählt.

Zur Unterstützung von MLO nutzt der Netzwerkauswahlalgorithmus die folgenden MLO-Funktionen des Wi-Fi-Chips:

  • Maximale STR-Linkanzahl
  • Maximale Anzahl von Assoziationslinks
  • Gleichzeitige Bandkombinationen

Auswahl des Wi-Fi-MLO-Netzwerks

Abbildung 2. MLO-Netzwerkauswahl.

Simultanes Senden und Empfangen (STR) ist ein Wi-Fi-Medium-Konkurrenzschema für den Multi-Link-Betrieb. Die Signalisolierung zwischen verschiedenen Verbindungen ist ausreichend, sodass die Verbindungen unabhängig voneinander arbeiten und in verschiedenen Verbindungen gleichzeitig senden und empfangen können. STR unterscheidet sich von Legacy Single Link (SL) STA und Legacy Dual Band Dual Concurrent (DBDC) STA. Mit einer STA-MLD verbundene STAs teilen sich eine gemeinsame Sendersequenznummer (SN) und einen gemeinsamen Raum für die Datenübertragung, der verschiedenen Verbindungen zugewiesen ist, wenn die Übertragung mehrerer Verbindungen dieselbe Zugriffskategorie (AC) hat.

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

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

Mithilfe des Konkurrenzschemas Enhanced Multi-Link Single Radio (eMLSR) können mehrere Verbindungen auf einem einzigen Funkgerät betrieben werden. Ein Multi-Link-Gerät verwendet eMLSR über eine Reihe von Verbindungen, wenn es bestimmte grundlegende Kontrollrahmen empfangen und gleichzeitig eine Clear Channel Assessment (CCA) für die Reihe von Verbindungen durchführen kann. Allerdings sendet oder empfängt das MLD Daten jeweils nur über eine Verbindung (die Verbindung, die dynamisch in jeder Übertragungsmöglichkeitsperiode (TXOP) ausgewählt wird).

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

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

Gleichzeitige Bandkombinationen

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

  • 2.4
  • 5
  • 6
  • 2,4 x 5
  • 2,4 x 6
  • 5 x 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. Der maximale vorhergesagte Multi-Link-Durchsatzwert wird für jede Gruppe basierend auf der maximalen STR-Linkanzahl 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 Durchsatz-Score durch den Multi-Link-Prognose-Durchsatz-Score ersetzt. Dies gibt MLO-Kandidaten bei der Netzwerkauswahl einen Auftrieb.

Beim Beitritt zu einem AP-MLD-Netzwerk führt das Framework die SSID-Auswahl basierend auf den im ScanResults Objekt empfangenen Informationen durch, die von der Anbietersoftware gemeldet werden. Bei der SSID-Auswahl durch das Framework 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.

Handhabung der STA-MAC-Adresse des Geräts

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

MLD-MAC-Adresse

Das Wi-Fi-Framework verwaltet die MLD-MAC-Adresse des Geräts. Die MLD-MAC-Adresse wird genauso behandelt wie ein Nicht-MLD-Gerät seine eigene MAC-Adresse. Die MAC-Adresse kann je nach Wahl des Benutzers eine zufällige MAC-Adresse oder eine von der Hardware bereitgestellte MAC-Adresse sein. Die MLD-MAC-Adresse wird vom Framework mithilfe der HAL-API IWifiStaIface#setMacAddress() festgelegt.

Die Anbietersoftware verwaltet Instanz-STA-MAC-Adressen (für jeden Link). Wenn ein Gerät eine Verbindung zu einem AP herstellt, weist die Herstellersoftware jedem zugeordneten Link eine Instanz-MAC-Adresse zu.

Die Herstellersoftware weist basierend auf ihrem Algorithmus MAC-Adressen pro Link zu. Der Algorithmus muss wiederholbar sein und eine Funktion von Folgendem sein:

  • Vom Wi-Fi-Framework festgelegte STA-MLD-MAC-Adresse.
  • Link-ID (vom AP erhalten)

Das heißt, wenn das Framework dieselbe MLD-MAC-Adresse wiederverwendet, muss der Anbieter dieselben zugeordneten MAC-Adressen pro Instanz wiederverwenden und umgekehrt. Dies garantiert, dass, wenn die vom Framework generierte STA-MLD-Adresse für eine SSID persistent ist, auch die MAC-Adressen pro STA persistent sind.

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

  • Oktett 0: Stellen Sie sicher, dass das lokal verwaltete Bit gesetzt ist
  • Oktett 1–4: Identisch mit der STA-MLD-MAC-Adresse
  • Oktett 5: Per-STA = (STA-MLD + Link-ID + 1) MOD (256)

Die Hersteller-Firmware kann ohne Eingaben vom Wi-Fi-Framework eine Verbindungsumschaltung durchführen und den Energiesparstatus der Verbindungen zur Aktivierung oder Deaktivierung verwalten.

Das Wi-Fi-Framework erwartet keine Benachrichtigung, wenn sich der Verbindungsstatus ändert.

Verwaltung des Energiesparzustands

Der Energiesparstatus ist im Wi-Fi-Framework standardmäßig aktiviert. Im Energiesparzustand verwaltet die Hersteller-Firmware den Energiesparzustand einzelner Links basierend auf Verkehrsmustern und Entscheidungen zur Linkaktivierung oder -deaktivierung.

Das Wi-Fi-Framework kann jedoch die Deaktivierung des Energiesparstatus erzwingen, indem es die HAL-API ISupplicantStaIface::setPowerSave(false) aufruft. Wenn der Energiesparstatus durch das Framework deaktiviert ist, muss die Hersteller-Firmware mindestens eine Verbindung aktiv halten (Energiesparmodus deaktiviert). In diesem Zustand entscheidet die Firmware-Implementierung, welcher Link gesetzt wird.

Datenweg

Hier wird die Firmware-Implementierung des Anbieters für die Verarbeitung des Uplink- und Download-Verkehrs beschrieben.

Die Firmware leitet den Uplink-Verkehr basierend auf ihrer internen Implementierung an einen (oder mehrere) Links weiter. Die Hersteller-Firmware entscheidet anhand von Verkehrsmustern, wann Lastausgleich, Duplizierung oder Aggregation des Datenverkehrs durchgeführt wird. In den folgenden Fällen empfehlen wir die Firmware, den Datenverkehr auf mehrere Links zu duplizieren:

  • Wenn der Modus mit niedriger Latenz über die HAL-API IWifiChip#setLatencyMode() festgelegt wird.
  • Wenn Verkehr mit Benutzerpriorität 6 und 7 vorhanden ist.

Die Firmware muss die (Ziel-)pro-STA-MAC-Adresse des MAC-Headers durch die MLD-STA-MAC und die (Quell-)pro-AP-MAC-Adresse des MAC-Headers durch die MLD-AP-MAC-Adresse ersetzen. Die Firmware muss diese MAC-Adressenersetzung durchführen, bevor sie den APF-Filter passiert, da die APF-Filterbefehle über Filter verfügen, die auf MLD-MAC-Adressen basieren. Es gibt einen einzigen APF-Filter für alle Links eines AP-MLD.

Parallelität

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

  • MLO ist basierend auf der Firmware-Entscheidung für Lastausgleich, Aggregation oder Duplizierung erforderlich .
  • MLO ist verfügbar , was bedeutet, dass für eine andere Schnittstelle kein Radio erforderlich ist.

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

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

Der Wi-Fi-Supplicant benachrichtigt das Wi-Fi-Framework über TID-zu-Link-Zuordnungsänderungen über die folgenden AIDL-Schnittstellen:

Apps können mithilfe der folgenden APIs Informationen über TID-zu-Link-Zuordnungsänderungen abrufen:

Für Geräte mit Android 14 oder höher stehen die folgenden APIs zur Verfügung, um die TID-zu-Link-Kartenaushandlungsfunktionen für die Station und den AP zu erhalten.

Chipfähigkeit

Die folgenden Schnittstellen unterstützen die Chipfähigkeit für die TID-zu-Link-Mapping-Aushandlung.

AIDL HAL

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

AP-Fähigkeit

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

AIDL HAL

Das Framework fragt beim Supplicant die AP-Fähigkeit zusammen mit der aktuellen Verbindungsfähigkeit ab.

APIs

Zu den Link-Layer-Statistiken gehören Wi-Fi-verbindungsspezifische Details wie RSSI, verschiedene TX- und RX-Paketzähler sowie Funkstatistiken. Das Wi-Fi-Framework fragt regelmäßig Verbindungsschichtstatistiken und RSSI ab, um das beste Netzwerk auszuwählen oder die Qualität des verbundenen Netzwerks zu bewerten. Für Geräte mit Android 14 oder höher umfassen die Link-Layer-Statistiken die Multi-Link-Unterstützung. Zur Unterstützung von Wi-Fi 7 unterstützt Android MLO sowohl in den Link-Layer-Statistiken als auch in der Signalabfrage.

Linkspezifische Statistiken sind in den folgenden Link-Layer-AIDL-Schnittstellen zu finden:

Die System-API android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() überwacht alle Link-Layer-Statistiken. Das Framework ruft diese API regelmäßig auf, um die WLAN-Benutzerfreundlichkeitsstatistiken 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 einzelne Links (nicht MLO) geben die aggregierten Statistiken für MLO-Verbindungen zurück. Das Folgende sind die Aggregationskriterien:

  • Die folgenden aggregierten Paketstatistiken verwenden die Summe der Statistiken pro Link:

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

  • Die folgenden Statistiken verwenden die Daten des Links mit dem höchsten RSSI:

    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 berücksichtigen Link-Layer-Statistiken nicht die Verwendung mehrerer Links für eine einzelne Schnittstelle. Um MLO zu unterstützen, muss Anbietersoftware die folgende Aggregationslogik anwenden, wenn sie LinkLayerStats über die IWifi# getLinkLayerStats_1_6() HAL-API meldet. Der beste Link ist der Link mit dem höchsten RSSI.

  • StaLinkLayerStats.iface.beaconRx : Melden Sie die Beacon-Anzahl 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 (insgesamt) über die Links der Schnittstelle.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be, Bk): Melden Sie die Konfliktzeitstatistiken für den besten Link, der auf der Schnittstelle verwendet wird (niedrigste Konfliktzeitstatistiken).

Wenn eine der Verbindungen des Wi-Fi 7-Zugangspunkts umgewidmet wird, kann der AP die Entfernung der Verbindung durch eine MLO-Verbindungsneukonfiguration ankündigen. Stationen können eine nahtlose Verbindung mit dem AP aufrechterhalten, ohne dass eine Neuzuordnung der verbleibenden Verbindungen erforderlich ist.

Die onMloLinksInfoChanged AIDL-Schnittstelle, die sich im Wi-Fi-Supplicant unter ISupplicantStaIfaceCallback.aidl befindet, unterstützt die Link-Rekonfiguration (AP-Entfernung des Links).

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

Die Methode WifiInfo#getAffiliatedMloLinks gibt die verbundenen MLO-Links zurück. Die Methode MloLink#getState gibt den Status des Links zurück. Wenn der Link entfernt wird, lautet der zurückgegebene Linkstatus MLO_LINK_STATE_UNASSOCIATED .

Chip-MLO-Strategie

MLO ermöglicht es Geräten, Daten gleichzeitig über mehrere WLAN-Verbindungen zu senden und zu empfangen, was die Leistung von Apps verbessern kann, die bestimmte Anforderungen wie niedrige Latenz, hohe Bandbreite und geringen Stromverbrauch haben. Chiphersteller können Algorithmen zur Nutzung der verfügbaren Links entwickeln.

Privilegierte Apps können diese Algorithmen mithilfe der setMloMode -Methode im 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.