無線網絡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 ，則假定裝置支援 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。

掃描 AP Wi-Fi 7 支持

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。當裝置和連線的裝置均處於Wi-Fi 7 狀態時，STA 連接模式為Wi-Fi 7. AP 支援 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 功能：

蜜蜂

應用程式可以使用以下 API 進行基於 Wi-Fi 7 RTT 的測距：

軟AP

Android 在 Soft AP 中支援 Wi-Fi 7 並提供以下功能。

啟動軟AP

Android 支援在 Wi-Fi 7 模式下啟動 Soft 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 ，支援上報 Soft AP 資訊。

蜜蜂

應用程式可以使用SoftApInfo中的以下方法（系統API）來上報Soft AP資訊。

MLO Wi-Fi 7 功能

多鏈路操作 (MLO) 是 Wi-Fi 7 (802.11be) 規格中的主要功能。 MLO 是在 Wi-Fi 7 中運行的多鏈路設備 (MLD) 的必備功能，無論是並發還是非並發。

MLO圖

圖 1.MLO圖。

如圖1所示，AP-MLD和STA-MLD的每條鏈路都運行有多個AP或STA執行個體。每個連結都有一個單獨的 AP 或 STA MAC 位址。 AP或STA還有一個MLD MAC位址來識別設備。

android.net.wifi.MloLink類別表示 MLO 連結。此類別包含以下參數：

掃描的 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，以讀取附屬連結資訊清單。

蜜蜂

要獲取掃描的 AP MLO 信息，應用程式可以使用以下 API：

連接的 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 位址，並更新關聯連結的狀態。

蜜蜂

要獲取 MLO 連接訊息，應用程式可以使用以下 API：

AP-MLD掃描

供應商軟體向 Wi-Fi 框架提供其收到的每個信標或探測回應的掃描結果。這意味著 Wi-Fi 框架：

  • 可能從相同 AP-MLD 接收多個ScanResults物件（因為 AP 可以有多個信標連結）。
  • 可能僅收到 AP-MLD 的 AP 連結的部分掃描結果集，因為韌體可能無法接收其中一些連結訊號。

供應商軟體僅報告透過無線方式接收到的掃描結果，且不得根據 AP-MLD 公佈的連結建立（人工合成）掃描結果。

供應商軟體必須在報告的掃描結果中包含從 AP 執行個體接收到的基本變體多連結和 RNR IE。如果掃描結果中缺少附屬 AP 詳細信息，供應商軟體可以發送多鏈路探測請求（包含探測請求多鏈路元素的探測請求幀）以包括完整或部分功能、參數和操作元素集響應幀中具有目標AP-MLD 的AP 的資訊。

如果需要，供應商軟體可以觸發 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 連結數
  • 最大關聯連結數
  • 同時頻段組合

Wi-Fi MLO 網路選擇

圖 2.MLO網路選擇。

同時傳送和接收 (STR) 是一種用於多連結操作的 Wi-Fi 媒體爭用方案。不同鏈路之間的訊號隔離足夠，使得鏈路能夠獨立工作，並且能夠在不同鏈路中同時發送和接收。 STR 不同於傳統單連結 (SL) STA 和傳統雙頻雙並發 (DBDC) STA。如果多個連結傳輸具有相同的存取類別(AC)，則附屬於STA MLD的STA共用公共發射機序號(SN)和指派給不同連結的用於資料傳輸的公共空間。

使用的 STR 鏈路的最大數量可能與晶片支援的最大無線電數量不同。在圖 2 的範例中，最大 STR 連結計數為 2。

以下 AIDL HAL 介面支援最大 STR 連結計數和最大關聯連結計數功能：

使用競爭方案、增強型多連結單無線電 (eMLSR)，多個連結可以在單一無線電上運作。如果多鏈路設備可以接收某些基本控制訊框並同時在一組鏈路上執行空閒通道評估 (CCA)，則它會在一組鏈路上使用 eMLSR。然而，MLD 一次僅在一條連結（在每個發送機會 (TXOP) 週期中動態選擇的連結）上發送或接收資料。

如果晶片支援的話，MLD 站可以透過在STR 和eMLSR 中同時運行來最大化關聯鏈路的數量，以獲得更好的可靠性、更好的吞吐量和更低的延遲（與單鏈路傳統站相比）。在圖 2 中，最大關聯連結數為 3。

以下 AIDL HAL 介面支援最大關聯連結計數功能：

同時頻段組合

此框架查詢晶片以取得可同時運作的允許的無線電組合（透過IWifiChip.aidl AIDL 介面）。根據該訊息，該框架得出可能的同時頻帶組合。以下是同時頻段組合 (GHz) 的範例清單：

  • 2.4
  • 5
  • 6
  • 2.4×5
  • 2.4×6
  • 5×6

以下 AIDL HAL 介面支援同時無線電組合：

網路選擇

在網路選擇 (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 位址（針對每個連結）。當設備與 AP 關聯時，供應商軟體會為每個關聯連結指派一個實例 MAC 位址。

供應商軟體根據其演算法分配每個連結的 MAC 位址。該演算法必須是可重複的且是以下函數：

  • STA-MLD MAC 位址由 Wi-Fi 框架設定。
  • 連結 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 的流量時。

韌體必須以 MLD-STA MAC 取代 MAC 標頭的（目標）每 STA MAC 位址，並以 MLD-AP MAC 位址取代 MAC 標頭的（來源）每 AP MAC 位址。韌體必須在通過 APF 過濾器之前執行此 MAC 位址替換，因為 APF 過濾器命令具有基於 MLD MAC 位址的過濾器。 AP-MLD 的所有連結都有一個 APF 過濾器。

並發性

將無線電用於新介面的並發場景必須優先於將多個無線電專用於同一介面的連結。並發場景也必須優先於 MLO，無論哪一個先發生。對單一介面使用多個連結是機會主義的，這意味著僅在以下情況下使用多個連結：

  • MLO是否需要根據韌體決策來實現負載平衡、聚合或複製。
  • MLO可用，這意味著其他介面不需要無線電。

對於運行 Android 14 或更高版本的設備，當 Wi-Fi 7 AP 透過在信標、探測響應和關聯響應幀中傳輸的 TID 到鏈路映射元素宣布暫時禁用其中一條鏈路時，Wi-Fi 7站使用已建立的剩餘連結繼續與AP 的連接，而不執行其他關聯。

對於運行 Android 13 或更低版本的設備，Wi-Fi 框架不支援在連結狀態因 TID 到連結映射而更改時接收通知，即使關聯的連結未連結到 TID。

Wi-Fi 請求方透過以下 AIDL 介面向 Wi-Fi 框架通知 TID 到連結對映的變更：

應用程式可以使用以下 API 取得有關 TID 到連結映射變更的資訊：

對於運行 Android 14 或更高版本的設備，可以使用以下 API 來取得網站和 AP 的 TID 到連結對映協商功能。

晶片能力

以下介面支援 TID 到鏈路映射協商的晶片功能。

輔助哈爾

用於 TID 到鏈路映射協商的 AIDL 介面位於hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl中的FeatureSetMask中。 T2LM_NEGOTIATION = 1 << 8功能表示晶片支援 TID 到連結映射。蜜蜂

AP能力

以下介面支援 AP 進行 TID 到連結映射協商的能力。

輔助哈爾

框架向請求者查詢 AP 能力以及目前的連線能力。

蜜蜂

鏈路層統計數據包括 Wi-Fi 鏈路特定的詳細信息，例如 RSSI、各種 TX 和 RX 數據包計數器以及無線電統計數據。 Wi-Fi 框架定期輪詢鏈路層統計資料和 RSSI，以選擇最佳網路或評估所連接網路的品質。對於運行 Android 14 或更高版本的設備，鏈路層統計資訊包括多鏈路支援。為了支援 Wi-Fi 7，Android 在連結層統計和訊號輪詢中支援 MLO。

在以下鏈路層 AIDL 介面中可以找到特定於鏈路的統計資料：

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 的設備，鏈路層統計資訊不考慮單一介面的多個連結的使用情況。為了支援 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)：報告介面上使用的最佳連結的爭用時間統計資料（最低爭用時間統計資料）。

當 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 模式。