Wi-Fi 7

Для устройств под управлением Android 13 или выше Android поддерживает стандарт Wi-Fi 7 (IEEE 802.11be). На этой странице описываются функции Android Wi-Fi 7, включая базовую линию и многоканальную работу (MLO).

Базовые функции Wi-Fi 7

В этом разделе описываются базовые функции Wi-Fi 7, включенные в Android 13 и более поздние версии.

Поддержка Wi-Fi 7 на устройстве

Платформа Android включает API WifiManager#isWifiStandardSupported(int standard) , который приложения могут вызывать с аргументом ScanResults.WIFI_STANDARD_11BE , чтобы проверить, поддерживает ли устройство Wi-Fi 7.

При вызове этого API модуль Wi-Fi проверяет, используется ли наложение конфигурации config_wifi11beSupportOverride в качестве переопределения, и выполняет следующие действия:

  • Если оверлей установлен на true , предполагается, что устройство поддерживает Wi-Fi 7 независимо от ответа от nl80211. Это переопределение полезно только для производителей устройств, у которых нет драйверов, возвращающих поддержку Wi-Fi 7.
  • Если наложение установлено на false (значение по умолчанию), модуль Wi-Fi использует информацию из nl80211. Модуль Wi-Fi запрашивает информацию из wificond, который вызывает команду nl80211 NL80211_CMD_GET_WIPHY . Если атрибут NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY присутствует в ответе от драйвера, предполагается, что устройство поддерживает Wi-Fi 7.

Поддержка сканируемой точки доступа Wi-Fi 7

Платформа Android включает API int ScanResult#getWifiStandard() , который приложения могут вызывать для проверки того, поддерживает ли сканируемая точка доступа (AP) Wi-Fi 7. Если AP поддерживает Wi-Fi 7, API возвращает ScanResults.WIFI_STANDARD_11BE . Устройство не обязательно должно поддерживать Wi-Fi 7, чтобы приложения могли использовать этот API.

При вызове этого API модуль Wi-Fi проверяет, есть ли EHT Capability IE в возвращаемых результатах сканирования подключений. Если EHT Capability IE есть в результатах сканирования, сканируемая точка доступа поддерживает Wi-Fi 7. Класс AOSP WifiTracker отображает эту информацию о поддержке в пользовательском интерфейсе при работе в режиме verbose.

Режим подключения STA

Платформа Android включает API int WifiInfo#getWifiStandard() , который приложения могут вызывать для проверки того, является ли режим подключения текущей станции (STA) Wi-Fi 7. Режимом подключения STA является Wi-Fi 7, когда и устройство, и подключенная точка доступа поддерживают Wi-Fi 7. Если режим подключения — Wi-Fi 7, API возвращает ScanResults.WIFI_STANDARD_11BE .

При вызове getWifiStandard модуль Wi-Fi определяет режим, вызывая ISupplicantStaIface#getConnectionCapabilities() HAL API. Реализация этого HAL API в слое wpa_supplicant AIDL проверяет, находится ли EHT Capability IE в AssocReq и AssocRsp во время настройки соединения.

Выбор сети

В Android 13 выбор сети использует несколько параметров для определения того, к какой точке доступа подключаться. Одним из параметров является предполагаемая пропускная способность точки доступа, которая оценивается с помощью блока ThroughputPredictor . Блок ThroughputPredictor использует параметры PHY как устройства, так и сканируемой точки доступа.

В Android 13 ThroughputPredictor использует в своих расчетах следующие возможности AP:

  • Поддержка Wi-Fi 7 (802.11be)
  • Поддержка ширины канала 320 МГц

Включение этих возможностей в логику ThroughputPredictor повышает шансы выбора точек доступа с поддержкой Wi-Fi 7, когда устройство может использовать эти функции.

Диапазон на основе Wi-Fi RTT

Android обеспечивает поддержку API для преамбулы EHT и ширины канала 320 МГц для Wi-Fi RTT . Это обеспечивает поддержку возможностей Wi-Fi 7 в диапазоне RTT, когда это поддерживается чипом.

API HAL

Следующие API HAL поддерживают возможности Wi-Fi 7 для определения дальности на основе RTT:

API-интерфейсы

Приложения могут использовать следующие API для определения дальности на основе RTT по Wi-Fi 7:

Мягкий AP

Android поддерживает Wi-Fi 7 в Soft AP и предоставляет следующие функции.

Запустить мягкую точку доступа

Android поддерживает запуск Soft AP в режиме Wi-Fi 7. Это регулируется конфигурацией наложения config_wifiSoftapIeee80211beSupported .

Модуль Wi-Fi использует оверлей config_wifiSoftapIeee80211beSupported для установки булевого значения HwModeParams#enable80211BE в вызове API IHostApd#addAccessPoint() . В слое AIDL hostapd это значение используется для установки параметров hostapd.conf .

API HAL

Логическое значение enable80211BE в HwModeParams в hostapd HAL поддерживает запуск Soft AP в режиме Wi-Fi 7.

Сообщить информацию о Soft AP

Android включает поддержку API для включения информации о ширине канала Wi-Fi 7 и 320 МГц в сообщаемую информацию о Soft AP.

API HAL

Константа WIFI_STANDARD_11BE в интерфейсе Generation.aidl AIDL в hostapd HAL, которая используется в ApInfo , сообщаемой в обратном вызове IHostapdCallback#onApInstanceInfoChanged() , поддерживает передачу информации о программной точке доступа.

API-интерфейсы

Приложения могут использовать следующие методы (системные API) в SoftApInfo для предоставления информации о Soft AP.

Возможности MLO Wi-Fi 7

Многоканальная работа (MLO) — это основная функция спецификации Wi-Fi 7 (802.11be). MLO — это обязательная функция для многоканальных устройств (MLD), работающих в Wi-Fi 7, как одновременно, так и не одновременно.

Диаграмма МЛО

Рисунок 1. Диаграмма MLO.

Как показано на рисунке 1, и AP-MLD, и STA-MLD имеют несколько экземпляров AP или STA, работающих на каждом канале. Каждый канал имеет отдельный MAC-адрес AP или STA. AP или STA также имеет MAC-адрес MLD для идентификации устройства.

Класс android.net.wifi.MloLink представляет собой ссылку MLO. Этот класс включает следующие параметры:

  • int getLinkId() : идентификатор ссылки, объявленный AP MLD.
  • MacAddress getApMacAddress() : MAC-адрес точки доступа. BSSID экземпляра точки доступа для этой ссылки.
  • MacAddress getStaMacAddress() : MAC-адрес STA. Локально назначенный MAC-адрес для экземпляра STA на ссылке.
  • int getChannel() : Канал ссылки. Номер канала ссылки.
  • int getBand() : Полоса связи. Полоса связи.

  • int getState() : Состояние ссылки. Может быть одним из следующих состояний:

    • MLO_LINK_STATE_INVALID : Недопустимо. Используется для инициализации и случаев ошибок.
    • MLO_LINK_STATE_UNASSOCIATED : Не ассоциировано. Ссылка не связана с точкой доступа.
    • MLO_LINK_STATE_IDLE : Бездействует. Ссылка связана, но не активна (ссылке не сопоставлен идентификатор трафика (TID)).
    • MLO_LINK_STATE_ACTIVE : Активно. Ссылка связана и активна (ссылке сопоставлен как минимум один TID). Активная ссылка может находиться в режиме энергосбережения, поскольку фреймворк не отслеживает состояние питания ссылки.

Отсканированная информация MLO точки доступа Wi-Fi 7

Приложения могут получить параметры MLO для Wi-Fi 7 AP MLD, когда модуль Wi-Fi получает объект ScanResult от AP-MLD. AOSP WifiTracker отображает параметры MLO при работе в подробном режиме.

Модуль Wi-Fi собирает информацию MLO, выполняя следующие действия:

  • Анализирует многоканальный информационный элемент (IE), включенный в ответ маяка или зонда, для считывания MAC-адреса MLD точки доступа и текущего идентификатора канала.
  • Анализирует IE сокращенного отчета о соседях (RNR), включенного в ответ маяка или зонда, для считывания списка информации о аффилированных ссылках.

API-интерфейсы

Для получения отсканированной информации AP MLO приложения могут использовать следующие API:

  • ScanResult#BSSID : MAC-адрес экземпляра точки доступа (для ссылки, по которой получен результат сканирования)
  • MacAddress ScanResult#getApMldMacAddress() : возвращает MAC-адрес MLD точки доступа.
  • int ScanResult#getApMloLinkId() : возвращает идентификатор ссылки, по которой был получен ScanResult.
  • List<MloLink> ScanResult#getAffiliatedMloLinks() : возвращает список объектов MloLink для всех ссылок, объявленных AP-MLD, включая ссылку, по которой был получен ScanResult.

Информация о подключенной точке доступа Wi-Fi 7 MLO

Когда устройство подключается к точке доступа Wi-Fi 7 AP-MLD, фреймворк собирает параметры MLO соединения из объекта WifiInfo . Объект AOSP WifiTracker отображает эту информацию при работе в подробном режиме.

Когда устройство подключается к AP-MLD, модуль Wi-Fi копирует информацию MLO из объекта ScanResult , полученного от AP. Затем модуль вызывает API HAL ISupplicantStaIface#getConnectionMloLinksInfo() для считывания MAC-адресов каждой ссылки как для AP, так и для STA, а также для обновления состояния связанных ссылок.

API-интерфейсы

Для получения информации о подключении MLO приложения могут использовать следующие API:

  • WifiInfo#getBSSID() : возвращает MAC-адрес экземпляра точки доступа (для ссылки, к которой подключено устройство).
  • MacAddress WifiInfo#getApMldMacAddress() : возвращает MAC-адрес MLD точки доступа.
  • int WifiInfo#getApMloLinkId() : возвращает идентификатор ссылки, по которой STA связалась с AP.
  • List<MloLink> WifiInfo#getAffiliatedMloLinks() : возвращает список объектов MloLink для всех ссылок, объявленных AP-MLD, включая связанную ссылку. MAC-адреса AP и STA можно запросить для каждого объекта MloLink .

AP-MLD сканирование

Программное обеспечение поставщика предоставляет фреймворку Wi-Fi результаты сканирования для каждого полученного им ответа маяка или зонда. Это означает, что фреймворк Wi-Fi:

  • Может получать несколько объектов ScanResults от одного и того же AP-MLD (поскольку AP может иметь несколько маяковых ссылок).
  • Может быть получен только частичный набор результатов сканирования для каналов связи AP-MLD, поскольку некоторые из этих сигналов связи могут не приниматься прошивкой.

Программное обеспечение поставщика сообщает только результаты сканирования, полученные по беспроводной сети, и не должно создавать (искусственно синтезировать) результаты сканирования на основе ссылок, рекламируемых AP-MLD.

Программное обеспечение поставщика должно включать базовые варианты многоканальных и RNR IE, полученные от экземпляров AP, в сообщаемые результаты сканирования. Если в результатах сканирования отсутствуют сведения об аффилированной AP, программное обеспечение поставщика может отправлять многоканальные запросы зондирования (фрейм запроса зондирования, включающий элемент многоканального запроса зондирования), чтобы включить полный или частичный набор возможностей, параметров и элементов работы AP с целевым AP-MLD в ответный фрейм.

При необходимости программное обеспечение поставщика может запустить ML-зондирование (используя вариант запроса зонда ML IE в кадре запроса зонда).

Ассоциация сетей AP-MLD

Когда устройство присоединяется к сети AP-MLD, программное обеспечение поставщика использует выбранную ссылку AP (ассоциированную ссылку) для сигнализации. Программное обеспечение поставщика может ассоциироваться со всеми или некоторыми ссылками, которые поддерживаются устройством.

При успешной ассоциации драйвер сообщает ISupplicantStaIfaceCallback#onStateChanged() с BSSID ссылки для AP-MLD. Затем драйвер выбирает ссылку AP-MLD при условии, что результаты сканирования были переданы фреймворку для этой ссылки.

Сетевой скоринг

Для устройств под управлением Android 14 или выше функция Android Wi-Fi Network Selection поддерживает Wi-Fi 7 MLO. Это означает, что Android выбирает лучшую сеть Wi-Fi для устройства на основе количества доступных соединений для MLO.

Для поддержки MLO алгоритм выбора сети использует следующие возможности MLO чипа Wi-Fi:

  • Максимальное количество ссылок STR
  • Максимальное количество ассоциативных связей
  • Одновременные комбинации полос

Выбор сети Wi-Fi MLO

Рисунок 2. Выбор сети MLO.

Одновременная передача и прием (STR) — это схема конкуренции за среду Wi-Fi для многоканальной работы. Изоляция сигнала между различными каналами достаточна, чтобы каналы могли работать независимо и могли передавать и принимать данные одновременно в разных каналах. STR отличается от устаревшей одноканальной (SL) STA и устаревшей двухдиапазонной двухконкурентной (DBDC) STA. STA, связанные с STA MLD, имеют общий порядковый номер передатчика (SN) и общее пространство для передачи данных, выделенное для разных каналов, если передача по нескольким каналам имеет одну и ту же категорию доступа (AC).

Максимальное количество используемых STR-линков может отличаться от максимального количества радиомодулей, поддерживаемых чипом. В примере на рисунке 2 максимальное количество STR-линков равно 2.

Следующие интерфейсы AIDL HAL поддерживают максимальное количество ссылок STR и максимальное количество возможностей подсчета ссылок ассоциации:

Несколько каналов могут работать на одном радио с использованием схемы конкуренции Enhanced Multi-Link Single Radio (eMLSR). Многоканальное устройство использует eMLSR по набору каналов, если оно может получать определенные базовые кадры управления и выполнять оценку чистоты канала (CCA) одновременно на наборе каналов. Однако MLD передает или получает данные только по одному каналу (каналу, выбранному динамически в каждом периоде возможности передачи (TXOP)).

Станция MLD может максимизировать количество ассоциативных связей для лучшей надежности, лучшей пропускной способности и меньшей задержки (по сравнению с устаревшей станцией с одной связью) путем одновременной работы в STR и eMLSR, если это поддерживается чипом. На рисунке 2 максимальное количество ассоциативных связей равно 3.

Следующие интерфейсы AIDL HAL поддерживают максимальное количество связей ассоциации:

Одновременные комбинации полос

Фреймворк запрашивает чип, чтобы получить разрешенные комбинации радио (через интерфейс IWifiChip.aidl AIDL), которые могут работать одновременно. Из этой информации фреймворк выводит возможные одновременные комбинации диапазонов. Ниже приведен пример списка одновременных комбинаций диапазонов (ГГц):

  • 2.4
  • 5
  • 6
  • 2,4 х 5
  • 2,4 х 6
  • 5 х 6

Следующий интерфейс AIDL HAL поддерживает одновременные комбинации радио:

Выбор сети

Во время выбора сети (MLO) список кандидатов группируется по членам с одинаковым MAC-адресом MLD. Максимальная прогнозируемая оценка пропускной способности многоканального соединения рассчитывается для каждой группы на основе максимального количества каналов STR и одновременных комбинаций полос, поддерживаемых чипом. Если кандидат поддерживает многоканальное соединение и чип поддерживает STR, прогнозируемая оценка пропускной способности заменяется на прогнозируемую оценку пропускной способности многоканального соединения. Это дает толчок кандидатам MLO во время выбора сети.

При присоединении к сети AP-MLD фреймворк выполняет выбор SSID на основе информации, полученной в объекте ScanResults , как сообщает программное обеспечение поставщика. После выбора SSID фреймворком программное обеспечение поставщика отвечает за выбор BSSID для лучшей точки доступа (или ссылки AP) для использования при ассоциации.

Обработка MAC-адресов STA устройства

В этом разделе описывается, как обрабатываются MAC-адреса STA устройств (MAC-адреса MLD и MAC-адреса STA для каждого канала).

MAC-адрес MLD

Wi-Fi-фреймворк управляет MLD MAC-адресом устройства. MLD MAC-адрес обрабатывается так же, как не-MLD-устройство обрабатывает свой собственный MAC-адрес. MAC-адрес может быть случайным MAC-адресом или аппаратно-предусмотренным MAC-адресом в зависимости от выбора пользователя. MLD MAC-адрес устанавливается фреймворком с помощью IWifiStaIface#setMacAddress() HAL API.

Программное обеспечение поставщика управляет MAC-адресами экземпляров STA (для каждой ссылки). Когда устройство связывается с точкой доступа, программное обеспечение поставщика назначает MAC-адрес экземпляра для каждой связанной ссылки.

Программное обеспечение поставщика назначает MAC-адреса по ссылкам на основе своего алгоритма. Алгоритм должен быть повторяемым и быть функцией следующего:

  • MAC-адрес STA-MLD, установленный фреймворком Wi-Fi.
  • Идентификатор ссылки (получен от AP)

Это означает, что если фреймворк повторно использует тот же самый MLD MAC-адрес, поставщик должен повторно использовать те же самые связанные MAC-адреса per-instance, и наоборот. Это гарантирует, что когда фреймворк генерирует адрес STA-MLD, который является постоянным для SSID, MAC-адреса per-STA также являются постоянными.

Ниже приведен пример алгоритма назначения MAC-адресов STA для каждого канала (поставщики могут реализовать любой алгоритм, отвечающий критериям алгоритма):

  • Октет 0: Убедитесь, что локально администрируемый бит установлен
  • Октет 1-4: То же, что и MAC-адрес STA-MLD
  • Октет 5: Per-STA = (STA-MLD + идентификатор канала + 1) MOD (256)

Прошивка поставщика может выполнять переключение каналов и управлять состоянием энергосбережения каналов для активации или деактивации без ввода данных со стороны инфраструктуры Wi-Fi.

Платформа Wi-Fi не ожидает уведомления при изменении состояния соединения.

Управление состоянием энергосбережения

Состояние энергосбережения включено по умолчанию в фреймворке Wi-Fi. В состоянии энергосбережения встроенное ПО поставщика управляет состоянием энергосбережения отдельных ссылок на основе шаблонов трафика и решений об активации или деактивации ссылок.

Однако фреймворк Wi-Fi может принудительно отключить состояние энергосбережения, вызвав API ISupplicantStaIface::setPowerSave(false) HAL. Если состояние энергосбережения отключено фреймворком, прошивка поставщика должна поддерживать по крайней мере одну активную ссылку (энергосбережение отключено). В этом состоянии реализация прошивки решает, какая ссылка установлена.

Путь данных

Здесь описывается реализация встроенного ПО поставщика для обработки восходящего и загружаемого трафика.

Прошивка направляет трафик восходящего канала на один (или несколько) каналов на основе своей внутренней реализации. Прошивка поставщика решает, когда выполнять балансировку нагрузки, дублирование или агрегацию трафика на основе шаблонов трафика. Мы рекомендуем прошивке дублировать трафик на несколько каналов в следующих случаях:

  • Когда режим малой задержки установлен через API HAL IWifiChip#setLatencyMode() .
  • При наличии трафика с приоритетом пользователя 6 и 7.

Прошивка должна заменить MAC-адрес (назначения) per-STA заголовка MAC на MAC-адрес MLD-STA и MAC-адрес (источника) per-AP заголовка MAC на MAC-адрес MLD-AP. Прошивка должна выполнить эту замену MAC-адреса перед прохождением через фильтр APF, поскольку команды фильтра APF имеют фильтры, основанные на MAC-адресах MLD. Для всех соединений AP-MLD имеется один фильтр APF.

Параллелизм

Сценарии параллелизма, где радио используется для нового интерфейса, должны иметь приоритет над выделением нескольких радио для ссылок того же интерфейса. Сценарии параллелизма также должны иметь приоритет над MLO, независимо от того, что появилось первым. Использование нескольких ссылок для одного интерфейса является оппортунистическим, то есть несколько ссылок используются только когда:

  • MLO требуется на основе решения прошивки для балансировки нагрузки, агрегации или дублирования.
  • Доступен MLO, то есть радиомодуль не требуется для другого интерфейса.

Для устройств под управлением Android 14 или более поздней версии, когда точка доступа Wi-Fi 7 объявляет о временном отключении одного из каналов связи с помощью элемента сопоставления TID-канала, передаваемого в кадрах маяка, зондирующего ответа и ответа ассоциации, станция Wi-Fi 7 продолжает соединение с точкой доступа, используя оставшиеся настроенные каналы связи, не выполняя другую ассоциацию.

Для устройств под управлением Android 13 или более ранней версии фреймворк Wi-Fi не поддерживает получение уведомлений об изменении состояния соединения из-за сопоставления TID-соединения, даже если связанное соединение не связано с TID.

Запрашивающее устройство Wi-Fi уведомляет инфраструктуру Wi-Fi об изменениях сопоставления TID-каналов через следующие интерфейсы AIDL:

Приложения могут получать информацию об изменениях сопоставления TID-ссылок, используя следующие API:

Для устройств под управлением Android 14 или более поздней версии доступны следующие API для получения возможностей согласования карты TID-канала для станции и точки доступа.

Возможности чипа

Следующие интерфейсы поддерживают возможности чипа для согласования сопоставления TID-канала.

АЙДЛ ХЭЛ

Интерфейс AIDL для согласования сопоставления TID-to-link находится в FeatureSetMask в hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl . Возможность T2LM_NEGOTIATION = 1 << 8 указывает на то, что чип поддерживает сопоставление TID-to-link. API

Возможности AP

Следующие интерфейсы поддерживают возможность AP для согласования сопоставления TID-канала.

АЙДЛ ХЭЛ

Фреймворк запрашивает у запрашивающей стороны возможности точки доступа вместе с текущими возможностями подключения.

  • apTidToLinkMapNegotiationSupported : проверяет, поддерживает ли точка доступа возможность согласования карты TID-to-link.

API-интерфейсы

Статистика канального уровня включает в себя данные, специфичные для канала Wi-Fi, такие как RSSI, различные счетчики пакетов TX и RX, а также радиостатистику. Платформа Wi-Fi периодически опрашивает статистику канального уровня и RSSI, чтобы выбрать лучшую сеть или оценить качество подключенной сети. Для устройств под управлением Android 14 или выше статистика канального уровня включает в себя поддержку многоканального соединения. Для поддержки Wi-Fi 7 Android поддерживает MLO как в статистике канального уровня, так и в опросе сигнала.

Статистика, специфичная для канала, содержится в следующих интерфейсах AIDL канального уровня:

API системы android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() прослушивает всю статистику уровня связи. Фреймворк периодически вызывает этот API для обновления статистики удобства использования Wi-Fi.

Следующие API-интерфейсы, специфичные для ссылок, доступны в 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)

Чтобы запросить доступные идентификаторы ссылок, приложения могут вызвать метод android.net.wifi.WifiUsabilityStatsEntry#getLinkIds() .

API в android.net.wifi.WifiUsabilityStatsEntry для одиночной ссылки (не MLO) возвращают агрегированную статистику для соединений MLO. Ниже приведены критерии агрегации:

  • Следующая агрегированная статистика пакетов использует сумму статистики по каждому соединению:

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

  • В следующей статистике используются данные из ссылки с самым высоким RSSI:

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

Для устройств под управлением Android 13 статистика уровня связи не учитывает использование нескольких ссылок для одного интерфейса. Для поддержки MLO программное обеспечение поставщика должно применять следующую логику агрегации при предоставлении LinkLayerStats через API HAL IWifi# getLinkLayerStats_1_6() . Лучшая ссылка — это ссылка с самым высоким RSSI.

  • StaLinkLayerStats.iface.beaconRx : сообщает количество маяков для лучшей ссылки, используемой для интерфейса.
  • StaLinkLayerStats.iface.avgRssiMgmt : отчет avgRssiMgmt для лучшей ссылки, используемой для интерфейса.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk): Сообщает агрегированную статистику пакетов (общую) по каналам интерфейса.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk): Сообщает статистику времени конкуренции для наилучшего соединения, используемого в интерфейсе (наименьшая статистика времени конкуренции).

Когда одно из соединений точки доступа Wi-Fi 7 переназначается, точка доступа может объявить об удалении соединения посредством перенастройки соединения MLO. Станции могут поддерживать бесшовное соединение с точкой доступа без повторной ассоциации на оставшихся соединениях.

Интерфейс AIDL onMloLinksInfoChanged , расположенный в запрашивающем устройстве Wi-Fi по адресу ISupplicantStaIfaceCallback.aidl , поддерживает перенастройку канала (удаление канала AP).

Когда фреймворк Wi-Fi обрабатывает удаление ссылки, состояние ссылки устанавливается в MLO_LINK_STATE_UNASSOCIATED . Затем фреймворк запускает ConnectivityManager.NetworkCallback#onCapabilitiesChanged() для изменения состояния ссылки.

Метод WifiInfo#getAffiliatedMloLinks возвращает аффилированные MLO Links. Метод MloLink#getState возвращает состояние ссылки. Если ссылка удалена, возвращаемое состояние ссылки — MLO_LINK_STATE_UNASSOCIATED .

Стратегия чипа MLO

MLO позволяет устройствам отправлять и получать данные по нескольким каналам Wi-Fi одновременно, что может повысить производительность для приложений, имеющих особые требования, такие как низкая задержка, высокая пропускная способность и низкое энергопотребление. Поставщики чипов могут разрабатывать алгоритмы использования доступных каналов.

Привилегированные приложения могут изменять эти алгоритмы с помощью метода setMloMode в Wifimanager и устанавливать следующие режимы:

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

Для установки режима MLO фреймворк использует setMloMode в интерфейсе IWifiChip AIDL.