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 Wi-Fi 7 na urządzeniu

Platforma Androida zawiera interfejs API WifiManager#isWifiStandardSupported(int standard), którego aplikacje mogą używać z argumentem ScanResults.WIFI_STANDARD_11BE, aby sprawdzić, czy urządzenie obsługuje Wi-Fi 7.

Gdy wywołasz ten interfejs 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 wysyła żądanie informacji do wificond, który 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.

Gdy wywołasz ten interfejs API, moduł Wi-Fi sprawdza, czy EHT Capability IE znajduje się w zwróconych wynikach skanowania pod kątem łączności. Jeśli w wynikach skanowania występuje wartość 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 poziomie AIDL wpa_supplicant sprawdza, czy EHT Capability IE znajduje się zarówno w AssocReq, jak 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 używa parametrów PHY zarówno urządzenia, jak i skanowanego punktu dostępu.

W Androidzie 13 ThroughputPredictor do obliczeń używa tych funkcji 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 odległości na podstawie RTT w sieci Wi-Fi

Android udostępnia interfejs API obsługujący wstęp EHT i szerokość 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 tylko jest to obsługiwane przez chip.

Interfejsy HAL API

Te interfejsy HAL obsługują funkcje Wi-Fi 7 dotyczące pomiaru zasięgu na podstawie RTT:

Interfejsy API

Aplikacje mogą używać tych interfejsów API do określania zasięgu w sieci Wi-Fi 7 na podstawie RTT:

Programowe AP

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 ustawiania 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

Argument boolean HwModeParams w interfejsie hostapd HAL o nazwie enable80211BE obsługuje uruchamianie 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 HAL API

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 systemowych) w SoftApInfo, aby przekazywać informacje o Soft AP.

Funkcje MLO Wi-Fi 7

Działanie w wielu linkach (MLO) to główna funkcja w specyfikacji Wi-Fi 7 (802.11be). MLO to obowiązkowa funkcja na urządzeniach 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. W trybie szczegółowym AOSP WifiTracker wyświetla parametry MLO.

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.
  • Przetwarza raport o skrajnych wartościach sąsiada (RNR) IE zawarty w odpowiedzi na sygnał lub zapytanie, aby odczytać listę informacji o powiązanych linkach.

Interfejsy API

Aby uzyskać zeskanowane informacje AP MLO, aplikacje mogą używać tych interfejsów API:

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

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 połączy się z AP-MLD, moduł Wi-Fi skopiuje informacje MLO z obiektu ScanResult otrzymanego od AP. 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 wieloma linkami beaconów.
  • Możesz otrzymać tylko częściowy zestaw wyników skanowania dotyczących połączeń z punktami dostępu w AP-MLD, ponieważ niektóre sygnały połączeń mogą nie być odbierane przez oprogramowanie.

Oprogramowanie dostawcy raportuje tylko wyniki skanowania otrzymane drogą radiową i nie może tworzyć (sztucznie syntetyzować) wyników skanowania na podstawie linków reklamowych w AP-MLD.

Oprogramowanie dostawcy musi zawierać podstawowe linki wielodostępne i identyfikatory RNR 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.

W razie potrzeby oprogramowanie dostawcy może wywołać sprawdzanie ML (za pomocą wariantu zapytania o sprawdzenie ML w ramce zapytania o sprawdzenie)

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 zgłasza ISupplicantStaIfaceCallback#onStateChanged() z BSSID łącza dla AP-MLD. Następnie kierowca wybiera link do AP-MLD, o ile 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 dostępnych połączeń MLO.

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

  • Maksymalna liczba linków STR
  • Maksymalna liczba połączeń z powiązaniami
  • Jednoczesne kombinacje pasm

Wybór sieci MLO Wi-Fi

Rysunek 2. Wybór sieci MLO.

Jednoczesna transmisja i odbiór (STR) to schemat dostępu do medium Wi-Fi w przypadku operacji wielolinkowej. Izolacja sygnału między różnymi linkami jest wystarczająca, aby linki mogły działać niezależnie i mogły jednocześnie transmitować i odbierać dane w różnych linkach. 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 układ scalony radiów. W przykładzie na rysunku 2 maksymalna liczba połączeń STR wynosi 2.

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

Wiele linków może działać na jednym radiu 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ć czystą ocenę kanału (CCA) na tym zestawie linków. Jednak MLD przesyła lub odbiera dane tylko przez jeden kanał (kanał wybrany dynamicznie w każdym okresie przesyłania (TXOP)).

Stacja MLD może zmaksymalizować liczbę linków powiązań, 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 rysunku 2 maksymalna liczba linków powiązań wynosi 3.

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

Jednoczesne kombinacje pasm

Framework wysyła zapytanie do układu, aby uzyskać dozwolone kombinacje radiowe (za pomocą interfejsu IWifiChip.aidl AIDL), które mogą działać jednocześnie. Na podstawie tych informacji framework określa możliwe kombinacje pasm. Poniżej znajdziesz przykładową listę kombinacji pasm (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. Dzięki temu kandydaci do MLO będą mieli większą szansę na wybranie podczas 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 na podstawie algorytmu. Algorytm musi być powtarzalny i funkcja, która:

  • Adres MAC STA-MLD ustawiony przez ramkę Wi-Fi.
  • Identyfikator linku (otrzymany z AP)

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: sprawdź, czy bit administrowany lokalnie jest ustawiony
  • 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 HAL API 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 tym stanie implementacja oprogramowania układowego decyduje, który link jest ustawiany.

Ścieżka danych

Opis implementacji oprogramowania sprzętowego dostawcy do obsługi ruchu w kierunku i zwrotnym.

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 wzorcó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ównoległości, w których radio jest używane w nowym interfejsie, muszą mieć pierwszeństwo przed przydzielaniem wielu radiów do 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żywanie wielu linków do jednego interfejsu jest opcjonalne, co oznacza, że wiele linków jest używanych 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 do linku przesyłanego w ramach beacona, odpowiedzi na próbę 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.

W przypadku urządzeń 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 informuje framework Wi-Fi o zmianach mapowania TID na link za pomocą tych interfejsów AIDL:

Aplikacje mogą uzyskiwać informacje o zmianach mapowania identyfikatorów TID na linki za pomocą tych interfejsów API:

Na urządzeniach 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.

AIDL HAL

Interfejs AIDL do negocjowania mapowania identyfikatorów TID na linki znajduje się w FeatureSetMaskw hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl. Funkcja 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

Framework wysyła zapytanie do żądającego o możliwości AP wraz z obecnymi możliwościami 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 linku 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.

W android.net.wifi.WifiUsabilityStatsEntry dostępne są te interfejsy API dotyczące linków:

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 (a nie MLO) zwracają zbiorcze statystyki połączeń MLO. Oto kryteria agregacji:

  • Te zbiorcze statystyki pakietów korzystają z sumy statystyk dotyczących poszczególnych linków:

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

  • Statystyki poniżej korzystają z danych z linku o najwyższym współczynniku 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ą korzystania z wielu połączeń w jednym interfejsie. Aby obsługiwać MLO, oprogramowanie dostawcy musi stosować tę regułę agregacji podczas raportowania LinkLayerStats za pomocą interfejsu HAL 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): raport zbiorczych statystyk pakietów (łączne) na linkach interfejsu.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk): statystyki czasu rywalizacji dotyczące najlepszego linku używanego w interfejsie (najniższe statystyki czasu rywalizacji).

Gdy jeden z linków punktu dostępowego Wi-Fi 7 zostanie przekierowany, AP może ogłosić usunięcie linku za pomocą funkcji 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 został usunięty, zwrócony stan linku to: MLO_LINK_STATE_UNASSOCIATED.

Strategia MLO chip

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, wysoka przepustowość i mała moc. Dostawcy układów scalonych mogą opracowywać 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

Framework używa setMloMode w interfejsie IWifiChip AIDL do ustawienia trybu MLO.