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，則系統會假設裝置支援 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。如果裝置和已連線的 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 提供 API 支援，可針對 Wi-Fi RTT 使用 EHT 前置碼和 320 MHz 通道寬度。這樣一來，只要晶片支援 Wi-Fi 7 相關功能，即可在 RTT 測距功能中支援這些功能。

HAL API

下列 HAL API 支援 Wi-Fi 7 功能，以 RTT 為準：

API

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

軟體存取點

Android 支援 Soft 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。

回報 Soft 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 資訊。

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 參數。在詳細模式中執行時，Android 開放原始碼計畫 WifiTracker 會顯示 MLO 參數。

Wi-Fi 模組會透過以下方式收集 MLO 資訊：

  • 剖析訊號塔或探測器回應中包含的多連結資訊元素 (IE)，讀取無線基地台 MLD MAC 位址和目前的連結 ID。
  • 剖析信標或探測回應中包含的縮減鄰點報告 (RNR) IE，以讀取關聯連結資訊的清單。

API

如要取得掃描的 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 位址，並更新相關連結的狀態。

API

如要取得 MLO 連線資訊，應用程式可使用下列 API：

AP-MLD 掃描

供應商軟體會將每個接收的信標或探測回應的掃描結果，提供給 Wi-Fi 架構。這表示 Wi-Fi 架構：

  • 可能會從同一個 AP-MLD 接收多個 ScanResults 物件 (因為 AP 可能有多個信標連結)。
  • 可能只會收到 AP-MLD 無線基地台連結的部分掃描結果，因為韌體可能無法接收部分連結信號。

供應商軟體只會回報透過無線方式接收的掃描結果，且不得根據 AP-MLD 的廣告連結建立 (人為合成) 掃描結果。

供應商軟體必須在已回報的掃描結果中，納入從 AP 執行個體收到的基本變數多重連結和 RNR IEs。如果掃描結果中缺少相關的 AP 詳細資料，供應商軟體可傳送多連結探測要求 (包含探測要求多重連結元素的探測要求框架)，以在回應影格中納入 AP 的完整或部分功能、參數和作業元素，並將目標 AP-MLD 納入回應範圍。

供應商軟體可視需要觸發 ML-probing (在探針要求框架中使用探針要求變化版本 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 x 5
  • 2.4 x 6
  • 5 x 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 位址。架構會使用 IWifiStaIface#setMacAddress() HAL API 設定 MLD 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 篩選器指令包含以 MLD MAC 位址為依據的篩選器，因此韌體必須在通過 APF 篩選器前執行此 MAC 位址替換作業。單一 APF 篩選器可用於 AP-MLD 的所有連結。

並行

並行作業情境 (使用單一介面時，將單一無線電連線至多個介面) 的優先順序，必須高於將多個無線電連線至同一個介面的優先順序。無論哪個情境先發生，並行處理情境也必須優先於 MLO。為單一介面使用多個連結是可行的方式，也就是說，只有在下列情況下才會使用多個連結：

  • 根據用於負載平衡、匯總或複製的韌體決策，「必須」採用 MLO。
  • MLO 可以使用，這表示其他介面不需要無線電。

對於搭載 Android 14 以上版本的裝置，當 Wi-Fi 7 AP 透過透過信標、探測回應及關聯回應影格傳輸的 TID 連結對應元素，宣布暫時停用其中一個連結時，Wi-Fi 7 站會使用您設定的其餘連結繼續與 AP 連線，不會執行其他關聯。

如果是搭載 Android 13 以下版本的裝置，即使相關連結未連結至 TID，Wi-Fi 架構不支援在連結狀態因 TID 連結對應而改變時接收通知。

Wi-Fi 申請者會透過下列 AIDL 介面，將 TID 至連結對應項目的變更通知給 Wi-Fi 架構：

應用程式可以使用下列 API，取得 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

AP 功能

下列介面支援 AP 功能，可協商 TID 與連結的對應。

AIDL HAL

此架構會向申請端查詢 AP 功能，以及目前的連線功能。

API

連結層統計資料包含 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 中的 API 適用於單一連結 (而非 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，供應商軟體在透過 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 介面位於 ISupplicantStaIfaceCallback.aidl 的 Wi-Fi 申請者中，可支援連結重新設定 (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 模式。