Wi-Fi 7

对于搭载 Android 13 或更高版本的设备，Android 支持 Wi-Fi 7 (IEEE 802.11be) 标准。本页将介绍 Android Wi-Fi 7 的功能，包括基准和多链路操作 (MLO)。

基准 Wi-Fi 7 功能

本部分介绍了 Android 13 及更高版本中包含的基准 Wi-Fi 7 功能。

支持 Wi-Fi 7 的设备

Android 框架包含 WifiManager#isWifiStandardSupported(int standard) API，其中应用可以使用 ScanResults.WIFI_STANDARD_11BE 参数调用该 API，以检查设备是否支持 Wi-Fi 7。

调用此 API 时，Wi-Fi 模块会检查 config_wifi11beSupportOverride 配置叠加层是否用作替换项，并执行以下操作：

• 如果叠加层设置为 true，则无论 nl80211 的响应为何，系统都会假定设备支持 Wi-Fi 7。此替换项仅适用于没有返回 Wi-Fi 7 支持信息的驱动程序的设备制造商。
• 如果叠加层设置为 false（默认值），Wi-Fi 模块将使用 nl80211 中的信息。Wi-Fi 模块会调用 nl80211 命令 NL80211_CMD_GET_WIPHY，向 wificond 请求信息。如果驱动程序的响应中包含 NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY 属性，则系统会假定设备支持 Wi-Fi 7。

支持 Wi-Fi 7 的扫描的 AP

Android 框架包含 int ScanResult#getWifiStandard() API，其中应用可以调用该 API 来检查扫描的接入点 (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，则表示扫描的 AP 支持 Wi-Fi 7。在详细模式下运行时，AOSP WifiTracker 类会在界面中显示此支持信息。

STA 连接模式

Android 框架包含 int WifiInfo#getWifiStandard() API，其中应用可以调用该 API 来检查当前站点 (STA) 连接模式是否为 Wi-Fi 7。当设备和连接的 AP 都支持 Wi-Fi 7 时，STA 连接模式为 Wi-Fi 7。如果连接模式为 Wi-Fi 7，则该 API 会返回 ScanResults.WIFI_STANDARD_11BE。

当调用 getWifiStandard 时，Wi-Fi 模块会通过调用 ISupplicantStaIface#getConnectionCapabilities() HAL API 来确定模式。wpa_supplicant AIDL 层中此 HAL API 的实现会在连接设置期间检查 EHT Capability IE 是否同时位于 AssocReq 和 AssocRsp。

网络选择

在 Android 13 中，网络选择会使用多个参数来确定要连接到哪个 AP。其中一个参数是 AP 的估计吞吐量，它是使用 ThroughputPredictor 代码块进行估算的。ThroughputPredictor 代码块使用设备和扫描的 AP 的 PHY 参数。

在 Android 13 中，ThroughputPredictor 会在计算时使用以下 AP 功能：

• 支持 Wi-Fi 7 (802.11be)
• 支持 320 MHz 信道宽度

当设备可以使用这些功能时，在 ThroughputPredictor 逻辑中纳入这些功能，可提高选择支持 Wi-Fi 7 的 AP 的几率。

基于 Wi-Fi RTT 的范围

Android 为 EHT 前导码和 Wi-Fi RTT 的 320 MHz 信道宽度提供 API 支持。只要芯片支持，RTT 范围内的 Wi-Fi 7 相关功能就会受到支持。

HAL API

以下 HAL API 支持基于 RTT 范围的 Wi-Fi 7 功能：

• EHT：enum RttPreamble 和 enum WifiRatePreamble 中的常量
• WIDTH_320：enum WifiChannelWidthInMhz 中的常量
• BW_320MHz：enum RttBw 中的常量

API

应用可使用以下 API 实现基于 Wi-Fi 7 RTT 的范围：

• ScanResult#PREAMBLE_EHT
• ResponderConfig#PREAMBLE_EHT (SystemApi)

软 AP

Android 在软 AP 中支持 Wi-Fi 7 并提供以下功能。

启动软 AP

Android 支持在 Wi-Fi 7 模式下启动软 AP。这将受 config_wifiSoftapIeee80211beSupported 叠加层配置的约束。

Wi-Fi 模块使用叠加层 config_wifiSoftapIeee80211beSupported 在 IHostApd#addAccessPoint() API 调用中设置布尔值 HwModeParams#enable80211BE。在 hostapd AIDL 层中，此值用于设置 hostapd.conf 参数。

HAL API

hostapd HAL 的 HwModeParams 中的 enable80211BE 布尔值支持在 Wi-Fi 7 模式下启动软 AP。

报告软 AP 信息

Android 包含 API 支持，可在报告的软 AP 信息中纳入 Wi-Fi 7 和 320 MHz 信道宽度信息。

HAL API

hostapd HAL 的 Generation.aidl AIDL 接口中的 WIFI_STANDARD_11BE 常量适用于 IHostapdCallback#onApInstanceInfoChanged() 回调中所报告的 ApInfo，以支持报告软 AP 信息。

API

应用可以使用 SoftApInfo 中的以下方法（系统 API）来报告软 AP 信息。

• SoftApInfo#getWifiStandard()：如果软 AP 在 Wi-Fi 7 模式下启动，则返回 ScanResults.WIFI_STANDARD_11BE。
• SoftApInfo#getBandwidth()：如果使用 320 MHz 信道宽度，则返回 SoftApInfo#CHANNEL_WIDTH_320MHZ。

MLO Wi-Fi 7 功能

多链路操作 (MLO) 是 Wi-Fi 7 (802.11be) 规范中的主要功能。无论是并发还是非并发，MLO 都是支持 Wi-Fi 7 的多链路设备 (MLD) 的一项强制性功能。

图 1. MLO 示意图。

如图 1 所示，AP-MLD 和 STA-MLD 的每个链路上都运行着多个 AP 或 STA 实例。每个链路都有一个单独的 AP 或 STA MAC 地址。AP 或 STA 还有一个用于识别设备的 MLD MAC 地址。

MLO 链路表示法

android.net.wifi.MloLink 类表示 MLO 链路。此类包含以下参数：

• int getLinkId()：AP MLD 通告的链路 ID。
• MacAddress getApMacAddress()：AP MAC 地址。该链路的 AP 实例的 BSSID。
• MacAddress getStaMacAddress()：STA MAC 地址。链路上为 STA 实例在本地分配的 MAC 地址。
• int getChannel()：链路信道。链路的信道编号。
• int getBand()：链路频段。链路的频段。

• int getState()：链路状态。可以是以下状态之一：

  • MLO_LINK_STATE_INVALID：无效。用于初始化和错误案例。
  • MLO_LINK_STATE_UNASSOCIATED：未关联。该链路未与 AP 相关联。
  • MLO_LINK_STATE_IDLE：空闲。链路已关联但未处于活跃状态（没有任何流量标识符 (TID) 映射到链路）。
  • MLO_LINK_STATE_ACTIVE：活跃。链路已关联且处于活跃状态（至少有一个 TID 映射到链路）。活跃链路可以处于节能模式，因为框架不会监控链路的电源状态。

扫描的 Wi-Fi 7 AP MLO 信息

当 Wi-Fi 模块从 AP-MLD 接收 ScanResult 对象时，应用可以获取 Wi-Fi 7 AP MLD 的 MLO 参数。在详细模式下运行时，AOSP WifiTracker 会显示 MLO 参数。

Wi-Fi 模块通过执行以下操作来收集 MLO 信息：

• 解析信标或探测响应中包含的多链路信息元素 (IE)，以读取 AP MLD MAC 地址和当前链路 ID。
• 解析信标或探测响应中包含的精简邻居报告 (RNR) IE，以读取附属链路信息的列表。

API

如需获取扫描的 AP MLO 信息，应用可以使用以下 API：

• ScanResult#BSSID：AP 实例 MAC 地址（适用于接收扫描结果的链路）
• MacAddress ScanResult#getApMldMacAddress()：返回 AP 的 MLD MAC 地址。
• int ScanResult#getApMloLinkId()：返回接收 ScanResult 的链路的链路 ID。
• List<MloLink> ScanResult#getAffiliatedMloLinks()：针对 AP-MLD 通告的所有链路（包括接收 ScanResult 的链路），返回 MloLink 对象的列表。

连接的 Wi-Fi 7 AP MLO 信息

当设备连接到 Wi-Fi 7 AP-MLD 时，框架会从 WifiInfo 对象收集连接的 MLO 参数。在详细模式下运行时，AOSP WifiTracker 对象会显示此信息。

当设备与 AP-MLD 连接时，Wi-Fi 模块会从 AP 收到的 ScanResult 对象中复制 MLO 信息。然后，该模块会调用 ISupplicantStaIface#getConnectionMloLinksInfo() HAL API 来读取 AP 和 STA 每个链路的 MAC 地址，并更新关联链路的状态。

API

如需获取 MLO 连接信息，应用可以使用以下 API：

• WifiInfo#getBSSID()：返回 AP 实例的 MAC 地址（适用于与设备关联的链路）。
• MacAddress WifiInfo#getApMldMacAddress()：返回 AP 的 MLD MAC 地址。
• int WifiInfo#getApMloLinkId()：返回 STA 与 AP 关联的链路的链路 ID。
• List<MloLink> WifiInfo#getAffiliatedMloLinks()：针对 AP-MLD 通告的所有链路（包括关联链路），返回 MloLink 对象的列表。您可以在每个 MloLink 对象上查询 AP 和 STA MAC 地址。

AP-MLD 扫描

供应商软件会向 Wi-Fi 框架提供收到的每个信标或探测响应的扫描结果。这意味着 Wi-Fi 框架：

• 可能会从同一 AP-MLD 接收多个 ScanResults 对象（因为 AP 可以有多个信标链路）。
• 可能仅接收 AP-MLD 的 AP 链路的部分扫描结果集，因为固件可能无法接收其中某些链路信号。

供应商软件仅报告通过无线方式接收的扫描结果，且不得根据 AP-MLD 通告的链路创建（人工合成）扫描结果。

供应商软件必须在报告的扫描结果中加入从 AP 实例接收到的基本变体多链路和 RNR IE。如果扫描结果中缺少附属 AP 的详细信息，供应商软件可以发送多链路探测请求（包含探测请求多链路元素的探测请求帧）以包含完整或部分功能、参数和操作元素集，它们在响应帧中以 AP-MLD 为目标。

如果需要，供应商软件可以触发 ML 探测（在探测请求帧中使用探测请求变体 ML IE）。

AP-MLD 网络连接

当设备加入 AP-MLD 网络时，供应商软件会使用选定的 AP 链路（关联链路）进行信号传输。供应商软件可以与设备支持的全部或部分链路相关联。

关联成功后，驱动程序会报告 ISupplicantStaIfaceCallback#onStateChanged() 及 AP-MLD 链路的 BSSID。然后，驱动程序选择 AP-MLD 链路，前提是已向该链路的框架报告扫描结果。

网络评分

对于搭载 Android 14 或更高版本的设备，Android Wi-Fi 网络选择支持 Wi-Fi 7 MLO。这意味着 Android 会根据 MLO 的可用链路数量为设备选择最佳 Wi-Fi 网络。

为了支持 MLO，网络选择算法使用 Wi-Fi 芯片中的以下 MLO 功能：

• 最大 STR 链路数
• 最大关联链路数
• 同步频段组合

图 2. MLO 网络选择。

最大 STR 链路数

同步传输和接收 (STR) 是一种适用于多链路操作的 Wi-Fi 媒介争用方案。不同链路之间的信号隔离足以使链路能够独立运行，并且能够在不同的链路中同步传输和接收。STR 与旧版单链路 (SL) STA 和旧版双频双并发 (DBDC) STA 不同。如果多个链路传输具有相同的接入类别 (AC)，则附属于 STA MLD 的 STA 共享一个通用发射器序列号 (SN) 和一个分配给不同链路的通用数据传输空间。

已使用的 STR 链路数量上限可能与芯片支持的无线装置数量上限不同。在图 2 的示例中，最大 STR 链路数为 2。

以下 AIDL HAL 接口支持最大 STR 链路数和最大关联链路数计数功能：

• hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl

  • getWifiChipCapabilities()

• hardware/interfaces/wifi/aidl/android/hardware/wifi/WifiChipCapabilities.aidl

  • maxMloStrLinkCount
  • maxMloAssociationLinkCount

最大关联链路数

使用争用方案、增强多链路单无线电 (eMLSR) 操作，可在单个无线装置上运行多个链路。如果多链路设备可以接收某些基本控制帧并同时对这组链路执行干净信道评估 (CCA)，则会对一组链路使用 eMLSR。但是，MLD 每次仅在一个链路（在每个传输机会 (TXOP) 周期中动态选择的链路）上传输或接收数据。

如果芯片支持的话，MLD 站可以通过在 STR 和 eMLSR 中同时运行，来最大限度地增加关联链路的数量，以获得更好的可靠性、更好的吞吐量和更低的延迟（与单链路传统站点相比）。在图 2 中，最大关联链路数为 3 个。

以下 AIDL HAL 接口支持最大关联链路数计数功能：

• hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl

  • getWifiChipCapabilities()

• hardware/interfaces/wifi/aidl/android/hardware/wifi/WifiChipCapabilities.aidl

  • maxMloAssociationLinkCount

同步频段组合

框架会查询芯片，以获取可以同时运行的允许的无线装置组合（通过 IWifiChip.aidl AIDL 接口）。框架会根据这些信息推导出可能的同步频段组合。以下是同步频段组合 (GHz) 的示例列表：

• 2.4
• 5
• 6
• 2.4 x 5
• 2.4 x 6
• 5 x 6

以下 AIDL HAL 接口支持同步无线装置组合：

• hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl

  • getSupportedRadioCombinations()

网络选择

在网络选择 (MLO) 期间，候选列表按具有相同 MLD MAC 地址的成员进行分组。根据芯片支持的最大 STR 链路数量和同步频段组合，计算每个组的最高预测多链路吞吐量得分。如果候选对象支持多链路且芯片支持 STR，则预测的吞吐量得分会替换为多链路预测的吞吐量得分。这样可以网络选择过程中更好地挑选 MLO 候选对象。

加入 AP-MLD 网络时，框架会根据供应商软件报告的 ScanResults 对象中收到的信息执行 SSID 选择。框架选择 SSID 后，供应商软件负责为用于关联的最佳 AP（或 AP 链路）选择 BSSID。

设备 STA MAC 地址处理

本部分介绍如何处理设备 STA MAC 地址（MLD MAC 地址和每条链路 STA MAC 地址）。

MLD MAC 地址

Wi-Fi 框架管理设备的 MLD MAC 地址。MLD MAC 地址的处理方式与非 MLD 设备处理其自身 MAC 地址的方式相同。MAC 地址可以是随机分配的 MAC 地址，也可以是根据用户选择的硬件预配的 MAC 地址。MLD MAC 地址由框架使用 IWifiStaIface#setMacAddress() HAL API 进行设置。

每链路 STA MAC 地址

供应商软件管理实例 STA MAC 地址（针对每个链路）。当设备与 AP 相关联时，供应商软件会为每个关联链路分配一个实例 MAC 地址。

供应商软件根据其算法分配各链路的 MAC 地址。该算法必须可重复使用，并且是以下各项的函数：

• Wi-Fi 框架设置的 STA-MLD MAC 地址。
• 链路 ID（从 AP 接收）

这意味着，如果框架重复使用相同的 MLD MAC 地址，供应商必须重复使用相同的关联实例 MAC 地址，反之亦然。这保证了当框架生成的 STA-MLD 地址对于 SSID 是永久性的时，每个 STA MAC 地址也是永久性的。

以下是用于按链路 STA MAC 地址分配的算法示例（供应商可以实现任何符合算法条件的算法）：

• 八位字节 0：确保已设置本地管理的位
• 八位字节 1-4：与 STA-MLD MAC 地址相同
• 八位字节 5：每个 STA = (STA-MLD + 链路 ID + 1) MOD (256)

多链路处理

供应商固件可以执行链路切换并管理链路的节能状态以便激活或停用，而无需来自 Wi-Fi 框架的输入。

链路状态发生更改时，Wi-Fi 框架不会收到通知。

节能状态管理

Wi-Fi 框架会默认启用节能状态。在节能状态下，供应商固件会根据流量模式以及链路激活或停用决策来管理各个链路的节能状态。

不过，Wi-Fi 框架可以通过调用 ISupplicantStaIface::setPowerSave(false) HAL API 强制停用节能状态。如果框架停用了节能状态，供应商固件必须使至少一个链路保持活跃状态（已停用节能模式）。在此状态下，固件实现会决定设置哪个链路。

数据路径

这介绍了用于处理上行链路和下载流量的供应商固件实现。

上行链路流量

固件根据其内部实现将上行链路流量路由到一个或多个链路。供应商固件会根据流量模式决定何时对流量执行负载均衡、复制或聚合。在以下情况下，我们建议将固件重复流量分配到多个链路：

• 通过 IWifiChip#setLatencyMode() HAL API 设置低延迟模式时。
• 当有用户流量优先级为 6 和 7 时。

下行链路流量

固件必须将 MAC 标头的（目标）每 STA MAC 地址替换为 MLD-STA MAC，并将 MAC 标头的（源）每个 AP MAC 地址替换为 MLD-AP MAC 地址。固件必须在通过 APF 过滤器之前执行此 MAC 地址替换，因为 APF 过滤器命令具有基于 MLD MAC 地址的过滤器。AP-MLD 的所有链路都有一个 APF 过滤器。

并发

并发场景（即将无线装置用于新接口）必须优先于为同一接口的链路指定多个无线装置。无论哪个先发生，并发场景都必须优先于 MLO。针对单个接口使用多个链路是机会性的，也就是说，仅当满足以下条件时，才使用多个链路：

• 需要 MLO，具体取决于固件决策，以实现负载均衡、聚合或复制。
• MLO 可用，这意味着其他接口不需要无线装置。

TID 到链路映射

对于搭载 Android 14 或更高版本的设备，当 Wi-Fi 7 AP 通过信标、探测响应和关联响应帧中传输的 TID 到链路映射元素宣布暂时停用其中一条链路时，Wi-Fi 7站使用已建立的剩余链路继续与 AP 的连接，而不执行其他关联。

对于搭载 Android 13 或更低版本的设备，即使关联的链路未关联到 TID，Wi-Fi 框架也不支持在链路状态因 TID 到链路映射而发生变化时接收通知。

AIDL HAL

Wi-Fi 客户端通过以下 AIDL 接口向 Wi-Fi 框架通知 TID 到链路映射更改：

• hardware/interfaces/wifi/supplicant/aidl/android/hardware/wifi/supplicant/ISupplicantStaIfaceCallback.aidl

  • onMloLinksInfoChanged
  • MloLinkInfoChangeReason

• hardware/interfaces/wifi/supplicant/aidl/android/hardware/wifi/supplicant/ISupplicantStaIface.aidl

  • getConnectionMloLinksInfo()

• hardware/interfaces/wifi/supplicant/aidl/android/hardware/wifi/supplicant/MloLinksInfo.aidl

  • MloLinksInfo

API

应用可以使用以下 API 获取有关 TID 到链路映射更改的信息：

• ConnectivityManager.NetworkCallback.onCapabilitiesChanged()：当 TID 到链路的映射发生变化时，框架会触发网络回调。
• WifiInfo#getAssociatedMloLinks()：返回关联的 MLO 链路。
• MloLink#getState()：返回链路的状态，MLO_LINK_STATE_ACTIVE 或 MLO_LINK_STATE_IDLE。

TID 到链路映射协商功能

对于搭载 Android 14 或更高版本的设备，可使用以下 API 获取站点和 AP 的 TID 到链路映射协商功能。

芯片功能

以下接口支持芯片功能进行 TID 到链路映射协商。

AIDL HAL

用于进行 TID 到链路映射协商的 AIDL 接口位于 hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl 中的 FeatureSetMask 内。T2LM_NEGOTIATION = 1 << 8 功能表示芯片支持 TID 到链路映射。API

• WifiManager.isTidToLinkMappingNegotiationSupported()：返回支持 TID 到链路映射协商的芯片。

AP 功能

以下接口支持 AP 功能以进行 TID 到链路映射协商。

AIDL HAL

框架会向客户端查询 AP 功能以及当前连接功能。

• apTidToLinkMapNegotiationSupported：检查 AP 是否支持 TID 到链路映射协商功能。

API

• WifiInfo.isApTidToLinkMappingNegotiationSupported()：返回 AP 是否支持 TID 到链路映射协商。

链路层统计数据

链路层统计数据包括 Wi-Fi 链路特定的详细信息，例如 RSSI、各种 TX 和 RX 数据包计数器以及无线装置统计信息。Wi-Fi 框架会定期轮询链路层统计数据和 RSSI，以选择最佳网络或评估连接的网络的质量。对于搭载 Android 14 或更高版本的设备，链路层统计数据包含多链路支持。为了支持 Wi-Fi 7，Android 在链路层统计数据和信号轮询中均支持 MLO。

特定于链路的统计数据可在下列链路层 AIDL 接口中找到：

• hardware/interfaces/wifi/aidl/android/hardware/wifi/StaLinkLayerIfaceStats.aidl
  • StaLinkLayerIfaceStats
• hardware/interfaces/wifi/aidl/android/hardware/wifi/StaLinkLayerLinkStats.aidl
  • StaLinkLayerLinkStats
  • StaLinkState state

android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() 系统 API 会监听所有链路层统计数据。该框架会定期调用此 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)

如需查询可用的链路 ID，应用可以调用 android.net.wifi.WifiUsabilityStatsEntry#getLinkIds() 方法。

android.net.wifi.WifiUsabilityStatsEntry 中针对单个链路（而非 MLO）的 API 会返回 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 中的链路层统计数据

对于搭载 Android 13 的设备，链路层统计数据不考虑单个接口的多个链路使用情况。为了支持 MLO，供应商软件在通过 IWifi# getLinkLayerStats_1_6() HAL API 报告 LinkLayerStats 时必须应用以下汇总逻辑。最好的链路是 RSSI 最高的链路。

• StaLinkLayerStats.iface.beaconRx：报告用于接口的最佳链路的信标计数。
• StaLinkLayerStats.iface.avgRssiMgmt：报告 avgRssiMgmt 以获取用于接口的最佳链路。
• StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk)：通过接口链路报告汇总的数据包统计数据（总计）。
• StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk)：报告接口上使用的最佳链路的争用时间统计数据（最低争用时间统计数据）。

MLO 链路重新配置

当 Wi-Fi 7 接入点的其中一个链路更改用途时，AP 可以通过 MLO 链路重新配置来宣布移除此链路。站点可以保持与 AP 的无缝连接，而无需重新关联其余链路。

onMloLinksInfoChanged AIDL 接口（位于 Wi-Fi 客户端的 ISupplicantStaIfaceCallback.aidl）支持链路重新配置（AP 移除了该链路）。

当 Wi-Fi 框架处理链路移除时，链路状态会设置为 MLO_LINK_STATE_UNASSOCIATED。随后，框架会触发 ConnectivityManager.NetworkCallback#onCapabilitiesChanged() 来更改链路状态。

WifiInfo#getAffiliatedMloLinks 方法会返回附属的 MLO 链路。MloLink#getState 方法会返回链路的状态。如果链路被移除，返回的链路状态为 MLO_LINK_STATE_UNASSOCIATED。

芯片 MLO 策略

MLO 允许设备同时在多个 Wi-Fi 链路上发送和接收数据，从而提高具有特定要求（例如低延迟、高带宽和低功耗）的应用的性能。芯片供应商可以开发关于如何使用可用链路的算法。

特权应用可以使用 Wifimanager 中的 setMloMode 方法修改这些算法并设置以下模式：

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

该框架使用 IWifiChip AIDL 接口中的 setMloMode 来设置 MLO 模式。