Wi-Fi 7

Na urządzeniach z Androidem 13 lub nowszym Android obsługuje standard Wi-Fi 7 (IEEE 802.11be). Na tej stronie opisano funkcje Wi-Fi 7 w Androidzie, w tym działanie w trybie podstawowym i wielolinkowym (MLO).

Podstawowe funkcje Wi-Fi 7

W tej sekcji opisano podstawowe funkcje Wi-Fi 7 dostępne w Androidzie 13 i nowszych.

Obsługa sieci Wi-Fi 7 urządzenia

Platforma Androida obejmuje interfejs API WifiManager#isWifiStandardSupported(int standard), który aplikacje mogą wywoływać za pomocą argumentu ScanResults.WIFI_STANDARD_11BE w celu sprawdzenia, czy urządzenie obsługuje Wi-Fi 7.

Po wywołaniu tego interfejsu API moduł Wi-Fi sprawdza, czy nakładka konfiguracji config_wifi11beSupportOverride jest używana jako zastąpienie i wykonuje te czynności:

  • Jeśli wartość nakładki to true, przyjmuje się, że urządzenie obsługuje Wi-Fi 7 niezależnie od odpowiedzi z nl80211. Ta zmiana jest przydatna tylko dla producentów urządzeń, którzy nie mają sterowników obsługujących Wi-Fi 7.
  • Jeśli wartość nakładki to false (wartość domyślna), moduł Wi-Fi używa informacji z nl80211. Moduł Wi-Fi prosi o informacje od wificond, co wywołuje polecenie nl80211 NL80211_CMD_GET_WIPHY. Jeśli w odpowiedzi z sterownika występuje atrybut NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY, przyjmuje się, że urządzenie obsługuje Wi-Fi 7.

Obsługa skanowanych punktów dostępu Wi-Fi 7

Platforma Androida zawiera interfejs API int ScanResult#getWifiStandard(), którego aplikacje mogą używać do sprawdzania, czy zeskanowany punkt dostępu (AP) obsługuje Wi-Fi 7. Jeśli punkt dostępu obsługuje Wi-Fi 7, interfejs API zwraca ScanResults.WIFI_STANDARD_11BE. Aby aplikacje mogły korzystać z tego interfejsu API, urządzenie nie musi obsługiwać Wi-Fi 7.

Po wywołaniu tego interfejsu API moduł Wi-Fi sprawdza, czy w zwróconych wynikach skanowania połączenia znajduje się EHT Capability IE. Jeśli w wynikach skanowania widać EHT Capability IE, oznacza to, że skanowany punkt dostępu obsługuje Wi-Fi 7. Klasa AOSP WifiTracker wyświetla te informacje w interfejsie użytkownika, gdy działa w trybie obszernym.

Tryb połączenia STA

Platforma Androida zawiera interfejs API int WifiInfo#getWifiStandard(), którego aplikacje mogą używać do sprawdzania, czy bieżący tryb połączenia stacji (STA) to Wi-Fi 7. Tryb połączenia STA to Wi-Fi 7, gdy zarówno urządzenie, jak i połączony punkt dostępu obsługują Wi-Fi 7. Jeśli tryb połączenia to Wi-Fi 7, interfejs API zwracaScanResults.WIFI_STANDARD_11BE.

Gdy wywoływana jest metoda getWifiStandard, moduł Wi-Fi określa tryb, wywołując interfejs API HAL ISupplicantStaIface#getConnectionCapabilities(). Implementacja tego interfejsu HAL na warstwie AIDL wpa_supplicant sprawdza, czy EHT Capability IE jest w obiektach AssocReq i AssocRsp podczas konfigurowania połączenia.

Wybór sieci

W Androidzie 13 wybór sieci korzysta z kilku parametrów, aby określić, z którym punktem dostępu się połączyć. Jednym z parametrów jest szacunkowa przepustowość AP, która jest szacowana za pomocą bloku ThroughputPredictor. Blok ThroughputPredictor wykorzystuje parametry PHY zarówno urządzenia, jak i zeskanowanego punktu dostępu.

W Androidzie 13 funkcja ThroughputPredictor korzysta z tych możliwości AP:

  • Obsługa Wi-Fi 7 (802.11be)
  • Obsługa szerokości kanału 320 MHz

Uwzględnienie tych funkcji w logice ThroughputPredictor zwiększa szanse na wybranie AP obsługujących Wi-Fi 7, gdy urządzenie może korzystać z tych funkcji.

Określanie zakresu przy użyciu sieci Wi-Fi RTT

Android zapewnia obsługę interfejsu API w przypadku wprowadzenia EHT i szerokości kanału 320 MHz w przypadku Wi-Fi RTT. Umożliwia to obsługę funkcji związanych z Wi-Fi 7 w zakresie RTT, gdy jest to obsługiwane przez układ.

Interfejsy API HAL

Poniższe interfejsy API HAL obsługują możliwości Wi-Fi 7 w zakresie opartym na RTT:

Interfejsy API

Aplikacje mogą używać tych interfejsów API do określania zakresu za pomocą protokołu Wi-Fi 7 RTT:

Miękki punkt dostępu

Android obsługuje Wi-Fi 7 w trybie Soft AP i zapewnia te funkcje:

Uruchamianie Soft AP

Android obsługuje uruchamianie Soft AP w trybie Wi-Fi 7. Jest to regulowane przez konfigurację nakładki config_wifiSoftapIeee80211beSupported.

Moduł Wi-Fi używa nakładki config_wifiSoftapIeee80211beSupported do ustawienia wartości logicznej HwModeParams#enable80211BE w wywołaniu interfejsu API IHostApd#addAccessPoint(). Na warstwie hostapd AIDL ta wartość jest używana do ustawiania parametrów hostapd.conf.

Interfejsy HAL API

Wartość logiczna enable80211BE w HwModeParams w hosta HAL obsługuje uruchamianie funkcji Soft AP w trybie Wi-Fi 7.

Raportowanie informacji o Soft AP

Android obsługuje interfejs API, który umożliwia uwzględnienie w raportowanych informacjach o Soft AP informacji o szerokości kanału Wi-Fi 7 i 320 MHz.

Interfejsy API HAL

Konstanta WIFI_STANDARD_11BE w interfejsie AIDL Generation.aidl w hostapd HAL, który jest używany w ApInfo raportowanym w wywołaniu zwrotnym IHostapdCallback#onApInstanceInfoChanged(), obsługuje raportowanie informacji o Soft AP.

Interfejsy API

Aplikacje mogą używać tych metod (interfejsów API systemu) w SoftApInfo, aby zgłaszać informacje o Soft AP.

Funkcje MLO Wi-Fi 7

Operacja z wieloma linkami (MLO) to główna funkcja specyfikacji Wi-Fi 7 (802.11be). MLO to obowiązkowa funkcja dla urządzeń wielolinkowych (MLD) działających w sieci Wi-Fi 7, niezależnie od tego, czy działają one równolegle, czy nie.

Schemat MLO

Rysunek 1. Schemat MLO

Jak widać na rysunku 1, zarówno w przypadku AP-MLD, jak i STA-MLD, na każdym połączeniu działa wiele instancji AP lub STA. Każde połączenie ma osobny adres MAC AP lub STA. AP lub STA ma też adres MAC MLD, który służy do identyfikacji urządzenia.

Klasa android.net.wifi.MloLink reprezentuje link MLO. Ta klasa zawiera te parametry:

zeskanowane informacje o AP MLO 7 Wi-Fi

Aplikacje mogą pobierać parametry MLO dla AP MLD 7 w Wi-Fi, gdy moduł Wi-Fi otrzyma obiekt ScanResult z AP MLD. AOSP WifiTracker wyświetla parametry MLO podczas działania w trybie szczegółowym.

Moduł Wi-Fi zbiera informacje o MLO w ten sposób:

  • Analizuje element informacji o wielu linkach (IE) zawarty w odpowiedzi beacona lub sondy, aby odczytać adres MAC MLD punktu dostępu i bieżący identyfikator linku.
  • Analizuje IE raport o ograniczonych sąsiadach (RNR) uwzględniony w odpowiedzi na sygnał typu beacon lub sondę, aby odczytać listę informacji o powiązanych linkach.

Interfejsy API

Do pobierania przeskanowanych informacji MLO punktu dostępu aplikacje mogą używać tych interfejsów API:

Informacje o połączonym MLO przez sieć Wi-Fi 7 AP

Gdy urządzenie łączy się z AP-MLD Wi-Fi 7, framework zbiera parametry MLO połączenia z obiektu WifiInfo. Obiekt AOSP WifiTracker wyświetla te informacje, gdy działa w trybie obszernym.

Gdy urządzenie łączy się z AP-MLD, moduł Wi-Fi kopiuje informacje MLO z obiektu ScanResult otrzymanego od punktu dostępu. Następnie wywołuje interfejs API HAL, aby odczytać adresy MAC każdego połączenia zarówno AP, jak i STA, oraz zaktualizować stan powiązanych połączeń.ISupplicantStaIface#getConnectionMloLinksInfo()

Interfejsy API

Aby uzyskać informacje o połączeniu MLO, aplikacje mogą używać tych interfejsów API:

Skanowanie AP-MLD

Oprogramowanie dostawcy udostępnia platformie Wi-Fi wyniki skanowania dla każdego otrzymanego sygnału beacon lub odpowiedzi. Oznacza to, że platforma Wi-Fi:

  • Może otrzymywać wiele obiektów ScanResults z tego samego punktu dostępu z MLD (ponieważ punkt dostępu może mieć wiele linków beaconów).
  • Możesz otrzymać tylko częściowy zestaw wyników skanowania dotyczących połączeń z punktami dostępu w urządzeniu AP-MLD, ponieważ niektóre sygnały połączeń mogą nie być odbierane przez oprogramowanie układowe.

Oprogramowanie dostawcy raportuje tylko wyniki skanowania bezprzewodowo i nie może tworzyć (sztucznie syntetyzować) wyników skanowania na podstawie linków reklamowanych przez AP-MLD.

Oprogramowanie dostawcy musi zawierać podstawowe informacje o linku i RNR IEs otrzymane z instancji AP w raportowanych wynikach skanowania. Jeśli w wynikach skanowania brakuje informacji o powiązanych AP, oprogramowanie dostawcy może wysyłać żądania próbkowania z wielu linków (ramka żądania próbkowania, która zawiera element żądania próbkowania z wielu linków), aby uwzględnić pełny lub częściowy zestaw funkcji, parametrów i elementów operacji AP z docelowym AP-MLD w ramce odpowiedzi.

Oprogramowanie dostawcy może w razie potrzeby aktywować sondowanie ML (za pomocą wariantu żądania sondowania ML IE w ramce żądania sondowania).

Powiązanie sieci AP-MLD

Gdy urządzenie dołącza do sieci AP-MLD, oprogramowanie dostawcy używa wybranego linku AP (powiązanego linku) do sygnalizacji. Oprogramowanie dostawcy może kojarzyć wszystkie lub niektóre linki obsługiwane przez urządzenie.

Po pomyślnym powiązaniu sterownik wysyła raportISupplicantStaIfaceCallback#onStateChanged() z BSSID łącza dla AP-MLD. Następnie kierowca wybiera link do AP-MLD, pod warunkiem że wyniki skanowania zostały zgłoszone do tego linku.

Ocena sieci

Na urządzeniach z Androidem 14 lub nowszym selekcja sieci Wi-Fi na Androidzie obsługuje Wi-Fi 7 MLO. Oznacza to, że Android wybiera najlepszą sieć Wi-Fi dla urządzenia na podstawie liczby połączeń dostępnych w ramach MLO.

Aby obsługiwać MLO, algorytm wyboru sieci korzysta z tych funkcji MLO w chipie Wi-Fi:

  • Maksymalna liczba linków STR
  • Maksymalna liczba linków powiązań
  • Kombinacje pasm równoczesnych

Wybór sieci MLO Wi-Fi

Rysunek 2. Wybór sieci MLO.

STR (Jednoczesne wysyłanie i odbieranie) to schemat rywalizacji o medium Wi-Fi w przypadku działania z wieloma linkami. Odizolowanie sygnałów między różnymi połączeniami jest wystarczające, aby połączenia działały niezależnie oraz mogły przesyłać i odbierać jednocześnie w różnych połączeniach. STR różni się od starszych STA z jednym łączem (SL) i starszych STA z podwójnym łączem (DBDC). STA powiązane z STA MLD mają wspólny numer sekwencji nadajnika (SN) i wspólny obszar transmisji danych przydzielony do różnych połączeń, jeśli wiele połączeń ma tę samą kategorię dostępu (AC).

Maksymalna liczba używanych połączeń STR może różnić się od maksymalnej liczby obsługiwanych przez chip radiów. W przykładzie na rys. 2 maksymalna liczba linków STR wynosi 2.

Te interfejsy HAL AIDL obsługują maksymalną liczbę linków STR i maksymalną liczbę linków skojarzenia:

W jednym radiu może działać wiele linków przy użyciu schematu rywalizacji – Enhanced Multi-Link Single Radio (eMLSR). Urządzenie wielolinkowe używa eMLSR na zestawie linków, jeśli może odbierać określone podstawowe ramki sterujące i jednocześnie wykonywać na tym zestawie ocenę kanału (CCA). Jednak MLD przesyła lub odbiera dane tylko przez jeden link (wybrany dynamicznie w każdym okresie możliwości transmisji (TXOP)).

Stacja MLD może zmaksymalizować liczbę linków powiązania, aby zapewnić większą niezawodność, większą przepustowość i krótszy czas oczekiwania (w porównaniu ze stacją starszego typu z pojedynczym łączem), działając jednocześnie w trybie STR i eMLSR, jeśli jest to obsługiwane przez układ. Na rys. 2 maksymalna liczba powiązań wynosi 3.

Te interfejsy AIDL HAL obsługują maksymalną liczbę połączeń:

Kombinacje pasm równoczesnych

Platforma wysyła zapytanie do elementu, aby uzyskać dozwolone kombinacje opcji radiowych (przez interfejs AIDL IWifiChip.aidl), które mogą działać jednocześnie. Na podstawie tych informacji framework określa możliwe kombinacje pasm. Oto przykładowa lista kombinacji pasm jednoczesnych (GHz):

  • 2.4
  • 5
  • 6
  • 2,4 x 5
  • 2,4 x 6
  • 5 x 6

Następujące interfejsy AIDL HAL obsługują jednoczesne kombinacje radia:

Wybór sieci

Podczas wyboru sieci (MLO) lista kandydatów jest grupowana według członków z tym samym adresem MAC MLD. Maksymalna przewidywana przepustowość wielu połączeń jest obliczana dla każdej grupy na podstawie maksymalnej liczby połączeń STR i jednoczesnych kombinacji pasm obsługiwanych przez układ. Jeśli kandydat obsługuje połączenia wielolinkowe, a chip obsługuje STR, przewidywana przepustowość zostanie zastąpiona przewidywaną przepustowością w przypadku połączenia wielolinkowego. Zwiększa to szanse kandydatów na MLO w trakcie wyboru sieci.

Podczas łączenia się z siecią AP-MLD framework wybiera SSID na podstawie informacji otrzymanych w obiekcie ScanResults, zgodnie z danymi przekazanymi przez oprogramowanie dostawcy. Po wybraniu SSID przez platformę oprogramowanie dostawcy jest odpowiedzialne za wybór BSSID najlepszego AP (lub linku AP) do użycia do powiązania.

Obsługa adresów MAC STA urządzenia

W tej sekcji opisano sposób obsługi adresów MAC STA urządzenia (adresów MAC MDL i adresów MAC STA na łącze).

Adres MAC MLD

Usługa Wi-Fi zarządza adresem MAC MLD urządzenia. Adres MAC MLD jest obsługiwany tak samo jak adres MAC urządzenia bez MLD. Adres MAC może być losowym adresem MAC lub adresem MAC skonfigurowanym przez sprzęt na podstawie wyboru użytkownika. Adres MAC MLD jest ustawiany przez framework za pomocą interfejsu IWifiStaIface#setMacAddress() HAL API.

Oprogramowanie dostawcy zarządza adresami MAC STA instancji (dla każdego łącza). Gdy urządzenie łączy się z AP, oprogramowanie dostawcy przypisuje adres MAC instancji do każdego powiązanego łącza.

Oprogramowanie dostawcy przypisuje adresy MAC poszczególnym linkom zgodnie ze swoim algorytmem. Algorytm musi być powtarzalny i być funkcją tej funkcji:

  • Adres MAC STA-MLD ustawiony przez interfejs Wi-Fi.
  • Identyfikator linku (otrzymany od punktu dostępu)

Oznacza to, że jeśli framework używa tego samego adresu MAC MLD, sprzedawca musi ponownie użyć tych samych adresów MAC powiązanych z poszczególnymi instancjami i odwrotnie. Dzięki temu, gdy adres STA-MLD wygenerowany przez framework jest trwały w przypadku SSID, adresy MAC poszczególnych STA są również trwałe.

Poniżej przedstawiamy przykładowy algorytm przypisywania adresów MAC STA do poszczególnych połączeń (dostawcy mogą stosować dowolny algorytm, który spełnia kryteria algorytmu):

  • Oktet 0: upewnij się, że ustawiony jest bit zarządzany lokalnie
  • Oktet 1–4: taki sam jak adres MAC STA-MLD
  • Oktet 5: Per-STA = (STA-MLD + link ID + 1) MOD (256)

Firmware dostawcy może przełączać połączenia i zarządzać stanem oszczędzania energii połączeń w celu ich aktywacji lub dezaktywacji bez udziału platformy Wi-Fi.

Framework Wi-Fi nie oczekuje powiadomienia o zmianie stanu połączenia.

Zarządzanie stanem oszczędzania energii

Tryb oszczędzania energii jest domyślnie włączony w ramach platformy Wi-Fi. W stanie oszczędzania energii oprogramowanie sprzętowe producenta zarządza stanem oszczędzania energii poszczególnych linków na podstawie wzorów ruchu i decyzji dotyczących aktywacji lub dezaktywacji linków.

Jednak framework Wi-Fi może wymusić wyłączenie trybu oszczędzania energii, wywołując interfejs API HAL ISupplicantStaIface::setPowerSave(false). Jeśli stan oszczędzania energii jest wyłączony przez platformę, oprogramowanie sprzętowe dostawcy musi zachować co najmniej jedno aktywne połączenie (stan oszczędzania energii wyłączony). W takiej sytuacji o tym, który link zostanie ustawiony, decyduje implementacja oprogramowania.

Ścieżka danych

Ten artykuł opisuje implementację oprogramowania dostawcy do obsługi ruchu związanego z przesyłaniem i pobieraniem.

Firmware kieruje ruch w stronę serwera do jednego lub większej liczby połączeń na podstawie swojej wewnętrznej implementacji. Firmware dostawcy decyduje, kiedy należy przeprowadzić równoważenie obciążenia, duplikowanie lub agregację ruchu na podstawie wzorów ruchu. Zalecamy dublowanie ruchu w pamięci ROM na wielu linkach w tych przypadkach:

  • Gdy tryb niskiego opóźnienia jest ustawiony za pomocą interfejsu IWifiChip#setLatencyMode() HAL API.
  • Gdy występuje ruch o priorytecie 6 i 7.

Firmware musi zastąpić adres MAC (docelowy) dla STA w nagłówku MAC adresem MAC MLD-STA oraz adres MAC (źródłowy) dla AP w nagłówku MAC adresem MAC MLD-AP. Firmware musi wykonać tę zamianę adresu MAC przed przekazaniem filtra APF, ponieważ polecenia filtra APF mają filtry oparte na adresach MAC MLD. W przypadku wszystkich linków w AP-MLD jest jeden filtr APF.

Równoczesność

Scenariusze równoczesności, w których radio jest wykorzystywane w nowym interfejsie, muszą mieć wyższy priorytet niż poświęcenie wielu funkcji radiowych dla linków tego samego interfejsu. Scenariusze równoczesnej realizacji muszą mieć wyższy priorytet niż MLO, niezależnie od tego, który z nich pojawił się pierwszy. Użycie wielu linków w jednym interfejsie jest oportunistyczne, co oznacza, że wiele linków ma zastosowanie tylko wtedy, gdy:

  • MLO jest wymagany na podstawie decyzji oprogramowania dotyczącej równoważenia obciążenia, agregacji lub powielania.
  • MLO jest dostępny, co oznacza, że interfejs nie wymaga radia.

W przypadku urządzeń z Androidem 14 lub nowszym, gdy punkt dostępu Wi-Fi 7 ogłosi tymczasowe wyłączenie jednego z linków za pomocą elementu mapowania TID na link przesyłanego w ramkach beaconów, odpowiedzi na próby sondowania i ramek odpowiedzi na skojarzenie, stacja Wi-Fi 7 będzie kontynuować połączenie z punktem dostępu za pomocą pozostałych skonfigurowanych linków, bez wykonywania kolejnego skojarzenia.

Na urządzeniach z Androidem 13 lub niższym framework Wi-Fi nie obsługuje otrzymywania powiadomień o zmianie stanu połączenia z powodu mapowania identyfikatora TID na link, nawet jeśli powiązany link nie jest powiązany z identyfikatorem TID.

Użytkownik Wi-Fi powiadamia interfejs Wi-Fi o zmianach mapowania TID na link za pomocą tych interfejsów AIDL:

Aplikacje mogą uzyskiwać informacje o zmianach w mapowaniu identyfikatorów TID na linki, używając tych interfejsów API:

W przypadku urządzeń z Androidem 14 lub nowszym dostępne są te interfejsy API, które umożliwiają negocjowanie mapy TID-to-link dla stacji i punktu dostępu.

Możliwości układu scalonego

Te interfejsy obsługują funkcję chipa dotyczącą negocjacji mapowania TID na link.

HAL AIDL

Interfejs AIDL do negocjowania mapowania identyfikatorów TID na linki znajduje się w FeatureSetMaskw hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl. Umiejętność T2LM_NEGOTIATION = 1 << 8 wskazuje, że układ obsługuje mapowanie TID na link. Interfejsy API

Możliwości AP

Te interfejsy obsługują funkcję AP do negocjowania mapowania TID na link.

AIDL HAL

Platforma wysyła zapytania o możliwości punktu dostępu od dostawcy razem z aktualną możliwością połączenia.

Interfejsy API

Statystyki warstwy łącza obejmują szczegóły dotyczące łącza Wi-Fi, takie jak RSSI, różne liczniki pakietów TX i RX oraz statystyki radiowe. Platforma Wi-Fi okresowo wysyła zapytania o statystyki warstwy łącza i RSSI, aby wybrać najlepszą sieć lub ocenić jakość połączonej sieci. W przypadku urządzeń z Androidem 14 lub nowszym statystyki warstwy łącza obejmują obsługę wielu połączeń. Aby obsługiwać Wi-Fi 7, Android obsługuje MLO zarówno w przypadku statystyk warstwy łącza, jak i przesyłania sygnału.

Statystyki dotyczące połączeń można znaleźć w tych interfejsach AIDL warstwy łącza:

Interfejs API systemu android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener()odbiera wszystkie statystyki warstwy łącza. Framework okresowo wywołuje ten interfejs API, aby aktualizować statystyki dotyczące użyteczności Wi-Fi.

Poniższe interfejsy API związane z połączeniami są dostępne w android.net.wifi.WifiUsabilityStatsEntry.

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)

Aby zapytać o dostępne identyfikatory linków, aplikacje mogą wywołać metodę android.net.wifi.WifiUsabilityStatsEntry#getLinkIds().

Interfejsy API w android.net.wifi.WifiUsabilityStatsEntry dotyczące pojedynczego linku (nie MLO) zwracają zbiorcze statystyki połączeń MLO. Oto kryteria agregacji:

  • Te zagregowane statystyki pakietów wykorzystują sumę statystyk poszczególnych linków:

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

  • Poniższe statystyki korzystają z danych z linku o najwyższym RSSI:

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

W przypadku urządzeń z Androidem 13 statystyki warstwy linków nie uwzględniają wykorzystania wielu linków w jednym interfejsie. Aby obsługiwać MLO, oprogramowanie dostawcy musi zastosować tę logikę agregacji podczas raportowania LinkLayerStats za pomocą interfejsu HAL API IWifi# getLinkLayerStats_1_6(). Najlepszym linkiem jest link z najwyższym wskaźnikiem RSSI.

  • StaLinkLayerStats.iface.beaconRx: raportowanie liczby beaconów dla najlepszego linku używanego w interfejsie.
  • StaLinkLayerStats.iface.avgRssiMgmt: raport avgRssiMgmt, w którym znajduje się najlepszy link do interfejsu.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk): powoduje raportowanie zbiorczych statystyk pakietów (łącznie) dotyczących połączeń interfejsu.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk): statystyki czasu konfliktu dotyczące najlepszego linku używanego w interfejsie (najniższe statystyki czasu konfliktu).

Gdy jedno z linków punktu dostępu Wi-Fi 7 zmieni się na inne, punkt dostępu może zasygnalizować usunięcie połączenia przez ponowną konfigurację połączenia MLO. Stacje mogą utrzymywać płynną łączność z AP bez ponownego tworzenia skojarzenia w pozostałych połączeniach.

Interfejs AIDL (onMloLinksInfoChanged) w aplikacji obsługującej Wi-Fi (ISupplicantStaIfaceCallback.aidl) umożliwia rekonfigurację linku (usunięcie go przez AP).

Gdy platforma Wi-Fi przetworzy usunięcie linku, stan linku zostanie ustawiony na MLO_LINK_STATE_UNASSOCIATED. Następnie framework uruchamia ConnectivityManager.NetworkCallback#onCapabilitiesChanged(), aby zmienić stan połączenia.

Metoda WifiInfo#getAffiliatedMloLinks zwraca powiązane linki MLO. Metoda MloLink#getState zwraca stan połączenia. Jeśli link zostanie usunięty, zwrócony stan linku to MLO_LINK_STATE_UNASSOCIATED.

Strategia MLO dla elementów

MLO umożliwia urządzeniom wysyłanie i odbieranie danych za pomocą wielu połączeń Wi-Fi w tym samym czasie, co może poprawić wydajność aplikacji o konkretnych wymaganiach, takich jak niskie opóźnienie, duża przepustowość i mała moc. Dostawcy elementów mogą opracować algorytmy dotyczące korzystania z dostępnych linków.

Aplikacje z uprawnieniami mogą modyfikować te algorytmy za pomocą metody setMloMode w Wifimanager i ustawić jeden z tych trybów:

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

Platforma używa setMloMode w interfejsie IWifiChip AIDL do ustawiania trybu MLO.