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

  • Если для параметра overlay задано значение true , предполагается, что устройство поддерживает Wi-Fi 7 независимо от ответа от nl80211. Это переопределение полезно только для производителей устройств, у которых нет драйверов, возвращающих поддержку Wi-Fi 7.
  • Если параметру overlay задано значение 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() , который приложения могут вызывать для проверки поддержки Wi-Fi 7 сканируемой точкой доступа (AP). Если AP поддерживает Wi-Fi 7, API возвращает ScanResults.WIFI_STANDARD_11BE . Для использования этого API устройствам не требуется поддержка Wi-Fi 7.

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

Режим подключения 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 определяет режим, вызывая HAL-API ISupplicantStaIface#getConnectionCapabilities() . Реализация этого HAL-API на уровне AIDL wpa_supplicant проверяет наличие EHT Capability IE в AssocReq и AssocRsp во время установки соединения.

Выбор сети

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

В 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 и предоставляет следующие функции.

Запустить 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() , поддерживает отчетность по информации Soft AP.

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

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

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

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

диаграмма MLO

Рисунок 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 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 , полученного от точки доступа. Затем модуль вызывает HAL-API ISupplicantStaIface#getConnectionMloLinksInfo() для чтения MAC-адресов каждого канала связи как для точки доступа, так и для 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-адреса точек доступа и STA можно запросить для каждого объекта MloLink .

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

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

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

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

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

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

Сетевая ассоциация AP-MLD

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

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

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

Для устройств под управлением Android 14 и более поздних версий функция выбора сети Wi-Fi Android поддерживает 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 поддерживают максимальное количество ассоциативных связей:

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

Фреймворк запрашивает у чипа допустимые комбинации радиочастот (через интерфейс AIDL IWifiChip.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 для наилучшей точки доступа (или канала связи между точками доступа) для использования при ассоциации.

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

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

MAC-адрес MLD

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

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

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

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

Это означает, что если фреймворк повторно использует один и тот же MAC-адрес MLD, поставщик должен повторно использовать те же связанные MAC-адреса для каждого экземпляра, и наоборот. Это гарантирует, что если сгенерированный фреймворком адрес STA-MLD является постоянным для SSID, MAC-адреса для каждого 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 может принудительно отключить режим энергосбережения, вызвав HAL-функцию ISupplicantStaIface::setPowerSave(false) . Если режим энергосбережения отключен фреймворком, прошивка поставщика должна поддерживать хотя бы один канал активным (режим энергосбережения отключен). В этом состоянии реализация прошивки определяет, какой канал будет установлен.

Путь данных

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

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

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

Прошивка должна заменить MAC-адрес (назначения) для каждой станции (STA) в заголовке MAC на MAC-адрес MLD-STA, а MAC-адрес (источника) для каждой точки доступа (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-канала находится в FeatureSetMask в hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl . Возможность T2LM_NEGOTIATION = 1 << 8 указывает на то, что чип поддерживает сопоставление TID-канала. 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. Станции могут поддерживать бесперебойное соединение с точкой доступа без повторной ассоциации на оставшихся каналах.

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

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

Метод WifiInfo#getAffiliatedMloLinks возвращает аффилированные ссылки MLO. Метод 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.