Wi-Fi 7

搭載 Android 13 以上版本的裝置支援 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 模組會向 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。應用程式使用這項 API 時，裝置不一定要支援 Wi-Fi 7。

呼叫這個 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 頻道頻寬。只要晶片支援，這項功能就能在 RTT 測距中支援 Wi-Fi 7 相關功能。

HAL API

下列 HAL API 支援 Wi-Fi 7 功能，可進行 RTT 距離測量：

API

應用程式可使用下列 API，根據 Wi-Fi 7 RTT 進行測距：

軟體 AP

Android 在軟體存取點中支援 Wi-Fi 7，並提供下列功能。

啟動軟體存取點

Android 支援在 Wi-Fi 7 模式下啟動軟體存取點。 這項設定由 config_wifiSoftapIeee80211beSupported 疊加層設定控管。

Wi-Fi 模組會使用疊加 config_wifiSoftapIeee80211beSupported，在 IHostApd#addAccessPoint() API 呼叫中設定布林值 HwModeParams#enable80211BE。在 hostapd AIDL 層中，這個值會用於設定 hostapd.conf 參數。

HAL API

主機板 HAL 中的 enable80211BE HwModeParams 布林值支援在 Wi-Fi 7 模式下啟動軟體存取點。

回報軟體無線基地台資訊

Android 包含 API 支援功能，可在回報的軟體存取點資訊中加入 Wi-Fi 7 和 320 MHz 頻道頻寬資訊。

HAL API

主機板 HAL 中 Generation.aidl AIDL 介面的 WIFI_STANDARD_11BE 常數 (用於 IHostapdCallback#onApInstanceInfoChanged() 回呼中回報的 ApInfo) 支援回報軟體存取點資訊。

API

應用程式可以在 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，以讀取相關聯結資訊清單。

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 連結可能只會收到部分掃描結果，因為韌體可能無法接收部分連結訊號。

供應商軟體報表只會掃描透過無線傳輸收到的結果，不得根據 AP-MLD 宣傳的連結建立 (人工合成) 掃描結果。

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

供應商軟體可視需要觸發 ML 探查 (使用探查要求框架中的探查要求變體 ML IE)。

AP-MLD 網路關聯

裝置加入 AP-MLD 網路時，供應商軟體會使用所選 AP 連結 (關聯連結) 進行信號傳輸。供應商軟體可以與裝置支援的部分或所有連結建立關聯。

成功建立關聯後，驅動程式會回報 AP-MLD 連結的 BSSID ISupplicantStaIfaceCallback#onStateChanged()。如果掃描結果已回報給該連結的架構，駕駛人即可選取 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 不同。與 STA MLD 相關聯的 STA 會共用傳輸器序號 (SN)，如果多個連結傳輸具有相同的存取類別 (AC)，則會共用分配給不同連結的資料傳輸空間。

使用的 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 後，供應商軟體會負責選取 BSSID，以找出最適合用於關聯的 AP (或 AP 連結)。

裝置 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 個八位元：Per-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 位址。韌體必須先執行這項 MAC 位址替換作業，再傳遞 APF 篩選器，因為 APF 篩選器指令會根據 MLD MAC 位址進行篩選。AP-MLD 的所有連結都使用單一 APF 篩選器。

並行

如果無線電用於新介面，則並行情境的優先順序必須高於為相同介面的連結分配多個無線電。無論哪個先發生，並行情境都必須優先於 MLO。針對單一介面使用多個連結是機會主義，也就是說，只有在下列情況下才會使用多個連結：

  • 根據韌體決策，MLO 為必要，可進行負載平衡、聚合或複製。
  • MLO 可用，表示其他介面不需要無線電。

如果裝置搭載 Android 14 以上版本，當 Wi-Fi 7 AP 透過信標、探查回應和關聯回應架構中傳輸的 TID 對應至連結元素，暫時停用其中一個連結時，Wi-Fi 7 站會使用其餘已設定的連結繼續與 AP 連線，不會執行其他關聯。

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

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

應用程式可以使用下列 API 取得 TID 對應連結的變更資訊：

對於搭載 Android 14 以上版本的裝置，您可以使用下列 API，取得電台和 AP 的 TID 對連結對應協商功能。

晶片功能

下列介面支援晶片功能，可進行 TID 對連結對應的協商。

AIDL HAL

TID 對連結對應協商的 AIDL 介面位於 FeatureSetMask 的 hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl中。T2LM_NEGOTIATION = 1 << 8 功能表示晶片支援 TID 對連結的對應。API

AP 功能

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

AIDL HAL

架構會從 Supplicant 查詢 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() 方法。

單一連結 (非 MLO) 的 API android.net.wifi.WifiUsabilityStatsEntry 會傳回 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 維持無縫連線，不必在剩餘連結上重新建立關聯。

位於 ISupplicantStaIfaceCallback.aidl Wi-Fi Supplicant 中的 onMloLinksInfoChanged 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 模式。