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-BefehlNL80211_CMD_GET_WIPHY
aufruft. Wenn das AttributNL80211_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:
-
EHT
: Konstante inenum RttPreamble
undenum WifiRatePreamble
-
WIDTH_320
: Konstante inenum WifiChannelWidthInMhz
-
BW_320MHz
: Konstante imenum RttBw
APIs
Apps können die folgenden APIs für Wi-Fi 7 RTT-basiertes Ranging verwenden:
-
ScanResult#PREAMBLE_EHT
-
ResponderConfig#PREAMBLE_EHT
(SystemApi)
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.
-
SoftApInfo#getWifiStandard()
: GibtScanResults.WIFI_STANDARD_11BE
zurück, wenn der Soft AP im Wi-Fi 7-Modus gestartet wird. -
SoftApInfo#getBandwidth()
: GibtSoftApInfo#CHANNEL_WIDTH_320MHZ
zurück, wenn die 320-MHz-Kanalbreite verwendet wird.
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.
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.
MLO-Linkdarstellung
Die Klasse android.net.wifi.MloLink
repräsentiert den MLO-Link. Diese Klasse umfasst die folgenden Parameter:
-
int getLinkId()
: Link-ID, wie vom AP MLD angekündigt. -
MacAddress getApMacAddress()
: AP-MAC-Adresse. Die BSSID der AP-Instanz für diesen Link. -
MacAddress getStaMacAddress()
: STA-MAC-Adresse. Die lokal zugewiesene MAC-Adresse für die STA-Instanz auf dem Link. -
int getChannel()
: Kanal verknüpfen. Die Kanalnummer des Links. -
int getBand()
: Band verknüpfen. Das Band des Links. int getState()
: Linkstatus. Kann einer der folgenden Zustände sein:-
MLO_LINK_STATE_INVALID
: Ungültig. Wird für Initialisierungs- und Fehlerfälle verwendet. -
MLO_LINK_STATE_UNASSOCIATED
: Nicht verknüpft. Der Link ist keinem AP zugeordnet. -
MLO_LINK_STATE_IDLE
: Inaktiv. Der Link ist zugeordnet, aber nicht aktiv (dem Link ist keine Verkehrskennung (TID) zugeordnet). -
MLO_LINK_STATE_ACTIVE
: Aktiv. Der Link ist verknüpft und aktiv (mindestens eine TID ist dem Link zugeordnet). Eine aktive Verbindung kann sich im Energiesparmodus befinden, da das Framework den Energiestatus der Verbindung nicht überwacht.
-
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:
-
ScanResult#BSSID
: Die MAC-Adresse der AP-Instanz (für den Link, über den das Scan-Ergebnis empfangen wird) -
MacAddress ScanResult#getApMldMacAddress()
: Gibt die MLD-MAC-Adresse des AP zurück. -
int ScanResult#getApMloLinkId()
: Gibt die Link-ID für den Link zurück, auf dem das ScanResult empfangen wurde. -
List<MloLink> ScanResult#getAffiliatedMloLinks()
: Gibt eine Liste vonMloLink
Objekten für alle vom AP-MLD angekündigten Links zurück, einschließlich des Links, über den das ScanResult empfangen wurde.
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:
-
WifiInfo#getBSSID()
: Gibt die MAC-Adresse der AP-Instanz zurück (für den Link, mit dem das Gerät verknüpft ist). -
MacAddress WifiInfo#getApMldMacAddress()
: Gibt die MLD-MAC-Adresse des AP zurück. -
int WifiInfo#getApMloLinkId()
: Gibt die Link-ID für den Link zurück, über den die STA eine Verbindung zum AP hergestellt hat. -
List<MloLink> WifiInfo#getAffiliatedMloLinks()
: Gibt eine Liste vonMloLink
Objekten für alle vom AP-MLD angekündigten Links zurück, einschließlich des zugehörigen Links. Für jedesMloLink
Objekt können sowohl die AP- als auch die STA-MAC-Adresse abgefragt werden.
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
Abbildung 2. MLO-Netzwerkauswahl.
Maximale STR-Linkanzahl
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:
hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl
hardware/interfaces/wifi/aidl/android/hardware/wifi/WifiChipCapabilities.aidl
Maximale Anzahl von Assoziationslinks
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:
hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl
hardware/interfaces/wifi/aidl/android/hardware/wifi/WifiChipCapabilities.aidl
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:
hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl
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.
STA-MAC-Adresse pro Link
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)
Multi-Link-Handhabung
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.
Uplink-Verkehr
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.
Downlink-Verkehr
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.
TID-zu-Link-Zuordnung
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.
AIDL HAL
Der Wi-Fi-Supplicant benachrichtigt das Wi-Fi-Framework über TID-zu-Link-Zuordnungsänderungen über die folgenden AIDL-Schnittstellen:
hardware/interfaces/wifi/supplicant/aidl/android/hardware/wifi/supplicant/ISupplicantStaIfaceCallback.aidl
hardware/interfaces/wifi/supplicant/aidl/android/hardware/wifi/supplicant/ISupplicantStaIface.aidl
hardware/interfaces/wifi/supplicant/aidl/android/hardware/wifi/supplicant/MloLinksInfo.aidl
APIs
Apps können mithilfe der folgenden APIs Informationen über TID-zu-Link-Zuordnungsänderungen abrufen:
-
ConnectivityManager.NetworkCallback.onCapabilitiesChanged()
: Netzwerkrückruf, der vom Framework ausgelöst wird, wenn sich die Zuordnung von TID zu Link ändert. -
WifiInfo#getAssociatedMloLinks()
: Gibt die zugehörigen MLO-Links zurück. -
MloLink#getState()
: Gibt den Status des Links zurück,MLO_LINK_STATE_ACTIVE
oderMLO_LINK_STATE_IDLE
.
TID-zu-Link-Mapping-Aushandlungsfunktionen
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
-
WifiManager.isTidToLinkMappingNegotiationSupported()
: Gibt den Chip zurück, der die TID-zu-Link-Zuordnungsaushandlung unterstützt.
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.
-
apTidToLinkMapNegotiationSupported
: Überprüft, ob ein AP die TID-zu-Link-Kartenaushandlungsfunktion unterstützt.
APIs
-
WifiInfo.isApTidToLinkMappingNegotiationSupported()
: Gibt zurück, ob der AP die TID-zu-Link-Zuordnungsaushandlung unterstützt.
Link-Layer-Statistiken
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:
-
hardware/interfaces/wifi/aidl/android/hardware/wifi/StaLinkLayerIfaceStats.aidl
-
hardware/interfaces/wifi/aidl/android/hardware/wifi/StaLinkLayerLinkStats.aidl
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()
Link-Layer-Statistiken in Android 13
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 SieavgRssiMgmt
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).
Neukonfiguration der MLO-Verbindung
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.