Wi-Fi 7

На устройствах с Android 13 или более поздней версии поддерживается стандарт 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. Если ТД поддерживает 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(). Реализация этого API HAL на уровне AIDL wpa_supplicant проверяет, находится ли EHT Capability IE в AssocReq и AssocRsp во время настройки подключения.

Выбор сети

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

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

  • Поддержка 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:

Точка доступа Soft AP

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

Запустить точку доступа

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

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

HAL API

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

Отправка отчетов о точке доступа SoftAP

В Android добавлена поддержка API, позволяющая включать информацию о Wi-Fi 7 и ширине канала 320 МГц в отчеты о программных точках доступа.

API HAL

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

API

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

Функции MLO Wi-Fi 7

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

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

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

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

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

  • int getLinkId(): Идентификатор связи, указанный в 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 сопоставлен со ссылкой). Активная ссылка может находиться в режиме энергосбережения, поскольку фреймворк не отслеживает состояние питания ссылки.

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

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

Модуль Wi-Fi собирает информацию MLO следующим образом:

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

API

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

API

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

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

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

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

  • Может получить несколько объектов ScanResults от одного и того же AP-MLD, поскольку ТД может иметь несколько ссылок для передачи сигналов.
  • Может получить только часть результатов сканирования для ссылок ТД из файла AP-MLD, поскольку некоторые сигналы ссылок могут не приниматься встроенным ПО.

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

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

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

Сетевое подключение AP-MLD

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

После успешной установки связи драйвер сообщает 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.Устройство рассматривает несколько каналов Wi-Fi в разных диапазонах (2,4 ГГц, 5 ГГц, 6 ГГц) для оптимального подключения на основе возможностей чипа, таких как максимальное количество каналов STR, максимальное количество каналов ассоциации и комбинации одновременных диапазонов.

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

Одновременная передача и прием (STR) – это схема конкуренции за среду Wi-Fi для многоканальной работы. Изоляция сигналов между разными каналами связи достаточна для того, чтобы каналы могли работать независимо и передавать и принимать данные одновременно. STR отличается от устаревших STA с одним каналом (SL) и устаревших STA с двумя каналами и двумя одновременными подключениями (DBDC). 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 x 5
  • 2,4 x 6
  • 5 x 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

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

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

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

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

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

Путь к данным

Это описание реализации встроенного ПО поставщика для обработки входящего и исходящего трафика.

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

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

Встроенное ПО должно заменить MAC-адрес (получателя) для каждой станции в заголовке MAC на MAC-адрес станции MLD, а MAC-адрес (источника) для каждой точки доступа в заголовке MAC – на MAC-адрес точки доступа MLD. Встроенное ПО должно выполнить замену 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 HAL

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

Возможности ТД

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

AIDL HAL

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

  • apTidToLinkMapNegotiationSupported: проверяет, поддерживает ли ТД возможность согласования сопоставления TID и ссылки.

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.

В android.net.wifi.WifiUsabilityStatsEntry доступны следующие API, относящиеся к ссылкам:

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 через IWifi# getLinkLayerStats_1_6() HAL API. Лучшая связь – это связь с самым высоким значением 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, расположенный в supplicant Wi-Fi по адресу ISupplicantStaIfaceCallback.aidl, поддерживает перенастройку связи (удаление точки доступа из связи).

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

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

Стратегия "Чип МЛО"

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 в интерфейсе AIDL IWifiChip.