Android 12 中引入的 Wi-Fi/蜂窩 coex 通道避免功能可識別並避免在蜂窩通道可能受到干擾的情況下使用不安全的 Wi-Fi 通道。這包括 STA、SoftAp、Wi-Fi Direct (P2P)、Wi-Fi Aware (NAN) 等接口。
本頁討論以下內容：
- 蜂窩調製解調器必須向 Android 框架報告的信息
- Wi-Fi 框架用於計算要避免的 Wi-Fi 信道的算法
- 設備製造商必須為 Wi-Fi 框架提供的配置表
- 與通道避免功能相關的系統 API、配置和 HAL API
- 處理通道迴避的框架行為
- 處理通道規避的芯片供應商行為
- 通道規避的實現細節
- 驗證通道迴避行為的測試
背景
對於採用 LTE、5G NR 和許可輔助接入 (LAA) 等蜂窩技術的設備，使用的蜂窩信道可能會干擾使用的 Wi-Fi 信道。當蜂窩和 Wi-Fi 信道處於短頻率間隔內（相鄰信道）或存在諧波和互調干擾時，就會發生這種情況。
當一個天線正在發射而另一個天線同時接收時，這種類型的干擾就會成為一個問題。在這種情況下，發射天線會淹沒接收天線，影響其接收質量。
本文檔將乾擾發射機稱為攻擊者，將遭受干擾的接收機稱為受害者。作為攻擊者或受害者的 Wi-Fi 通道被稱為不安全通道。
Wi-Fi/蜂窩共存通道避免功能提供了一種一致的通道避免方法，減少了對偏離 Wi-Fi 框架的專有代碼的需求。此外，該功能允許設備製造商配置、啟用和禁用以及覆蓋該功能。
該功能通過控制 Wi-Fi 通道來執行通道規避。 Wi-Fi 信道規避方案可以描述為一系列四個抽象步驟：
- 調製解調器報告蜂窩頻率的變化
- Coex 避免算法計算不安全的 Wi-Fi 信道
- Coex 迴避算法通知 Wi-Fi 服務
- 框架或驅動程序執行適當的 Wi-Fi 操作
圖 1.通道規避方案
報告蜂窩頻率的變化
電話服務報告當前使用的蜂窩信道。當工作蜂窩頻率改變時，調製解調器通過IRadio::PhysicalChannelConfig將此信息報告給電話服務。該信息包括許可輔助接入 (LAA) 和載波聚合 (CA) 的指示。
從 Android 12 開始， 1.6 IRadio::PhysicalChannelConfig中的以下字段為調製解調器必須填充的 coex 公式提供所需的信息。
struct PhysicalChannelConfig {
/** Connection status for cell. Valid values are PRIMARY_SERVING and SECONDARY_SERVING */
CellConnectionStatus status;
/** The radio technology for this physical channel */
RadioTechnology rat;
/** Downlink Absolute Radio Frequency Channel Number */
int32_t channelNumberDownlink;
/** Uplink Absolute Radio Frequency Channel Number */
int32_t channelNumberUplink;
/** Downlink cell bandwidth, in kHz */
int32_t cellBandwidthDownlink;hte
/** Uplink cell bandwidth, in kHz */
int32_t cellBandwidthUplink;
}
計算不安全的 Wi-Fi 信道
當調製解調器報告蜂窩頻率發生變化時，coex 信道算法會計算蜂窩和 Wi-Fi 信道之間的干擾，並確定哪組 Wi-Fi 信道不安全。
有多種類型的干擾需要不同的公式：相鄰和諧波/互調。由於設備之間天線和佈局的物理差異，每個設備的相鄰和諧波/互調干擾的模式是不同的。考慮到這一點，設備製造商必須提供一個查找表，以便將參數插入到這兩種干擾的通用公式中。這些參數是按小區頻帶定義的，並由活動小區信道的頻帶引用。
可以在查找表中定義最大功率上限。如果定義了最大功率上限，則不安全的通道會使用提供的功率上限進行傳輸。如果沒有功率上限，則通道以全功率傳輸。
通常，通道迴避功能使用盡力而為的方法來避免不安全的 Wi-Fi 通道以優化性能。但在某些情況下（例如，由於運營商的要求），某些接口必須避免某些蜂窩頻段的不安全通道。在這種情況下，強制限製表示為一個位掩碼，其中包含是否禁止某些通道的值，例如 Wi-Fi Direct (P2P)、SoftAp 和 Wi-Fi Aware (NAN)。雖然一個不安全的通道作為建議反對在所有用例中使用該通道，但強制限制標記了強制避免的特定用例。
如果 2.4GHz 或 5GHz 頻段的每個信道都標記為不安全，則查找表可以將每個乾擾小區頻段的默認 2.4GHz 信道或默認 5GHz 信道定義為最安全的選擇。當頻帶的其餘部分被報告為不安全時，這些默認頻道不會被報告為不安全的頻道。
覆蓋列表
在干擾嚴重依賴帶寬的情況下，公式化方法受到限制（因此帶寬較大的通道可能不安全，但帶寬較小的通道則不安全）。在諸如 LAA 的情況下，跳過計算並使用指定的不安全通道列表是有益的。
為此，您可以在查找表中為某些條目指定不安全通道的覆蓋列表。表條目中的覆蓋列表表示跳過該特定小區信道的計算，並且匹配小區信道的不安全 Wi-Fi 信道由覆蓋列表指定。
對於帶寬敏感的情況，您可以通過在覆蓋列表中指定具有某些帶寬的某些通道來選擇性地避開某些帶寬。這是因為每個 Wi-Fi 通道號對應一個指定的帶寬。
覆蓋列表由每個 Wi-Fi 頻段的頻道號或預定義類別關鍵字列表表示：
2g類：
-
all（整個 2.4GHz 頻段）
5g類：
-
all（整個 5GHz 頻段） -
20mhz（5GHz 20MHz 頻道） -
40mhz（5GHz 40MHz 頻道） -
80mhz（5GHz 80MHz 頻道） -
160mhz（5GHz 160MHz 頻道）
鄰道干擾
為了確定相鄰信道干擾，共軛避免算法確保攻擊者和受害信道之間的距離ΔF不低於指定的閾值。
圖 2.攻擊者和受害者通道之間的距離
閾值由設備的物理配置和查找表條目中提供的每個乾擾頻帶的閾值確定。被認為是無干擾的頻段沒有表條目，並且不需要計算不安全的信道（這是大多數時間）。
相鄰干擾參數
wifiVictimMhz：Wi-Fi 受害者的 MHz 距離閾值（小區上行鏈路）-
cellVictimMhz：小區受害者的 MHz 距離閾值（小區下行鏈路）
該算法對每個活動單元通道的行為如下：
- 對於頻道的波段，嘗試查找查找表條目。如果沒有找到表條目，則返回該單元通道沒有不安全的通道。
- 根據蜂窩頻段，確定存在風險的 Wi-Fi 頻段以及乾擾來自頻段的哪一側（例如，較低的 2.4GHz 信道、較高的 2.4GHz 信道、較低的 5GHz 信道）。
如果存在
wifiVictimMhz並且小區信道具有上行鏈路和如果 Wi-Fi 頻段的下部存在風險
- 通過將 wifiVictimMhz 添加到小區上行鏈路的最高頻率來查找不安全信道的上限。
- 查找下邊緣與限制重疊的第一個 20Mhz Wi-Fi 信道。
- 將 Wi-Fi 通道、包含它的每個較大帶寬通道（例如，40Mhz、80Mhz）以及同一頻段的每個較低通道標記為不安全通道。
如果 Wi-Fi 頻段的上部有風險
- 通過將 wifiVictimMhz 減去小區上行鏈路的最低頻率來找到不安全信道的下限。
- 查找上邊緣與限制重疊的第一個 Wi-Fi 通道。
- 將 Wi-Fi 頻道、包含它的每個較大頻道（例如，40Mhz、80Mhz）以及同一頻段的每個較高頻道標記為不安全頻道。
如果存在
cellVictimMhz並且小區信道具有下行鏈路。- 使用
cellVictimMhz作為閾值執行步驟 3，並與小區下行鏈路而不是小區上行鏈路進行比較。
- 使用
將表格條目的功率上限應用於計算的不安全通道。
圖 3相鄰信道干擾的不安全信道計算
諧波/互調失真
對於諧波/互調失真，coex 引擎計算諧波/互調信號的範圍，並評估它與潛在受害通道的重疊百分比。如果重疊超過重疊閾值，則算法認為這是不安全的情況。受害通道上諧波/互調失真的重疊百分比的計算通過以下等式執行：
在諧波失真情況下，該算法考慮了受 Wi-Fi 信道影響的小區上行鏈路信道的諧波失真。然後它用基於小區上行鏈路頻率和諧波度$N$的諧波值代替高失真和低失真。
圖 4.諧波失真的不安全通道計算
在互調情況下，該算法考慮小區上行鏈路的互調失真和受害小區下行鏈路信道的Wi-Fi信道。然後，它將高失真和低失真替換為基於小區上行鏈路頻率、Wi-Fi 頻率和兩個互調係數 $M$、$N$ 的互調值。
圖 5.互調失真的不安全信道計算
您可以在查找表中為每個乾擾單元帶指定 $M$、$N$ 和重疊值。如果某個頻段沒有乾擾，則從該頻段條目的表中省略這些值。可以獨立定義 Wi-Fi 2.4GHz 和 5GHz 頻段的兩組這些值。
與相鄰干擾算法類似，該算法重用每個乾擾小區頻帶定義的相同功率上限值。
該算法對每個活動單元通道的行為如下：
- 對於信元通道的波段，它會嘗試查找查找表條目。如果沒有找到表條目，則返回該通道沒有不安全的通道。
如果定義了參數，則從諧波中查找不安全的 2.4GHz 通道。
- 求出 2.4GHz 的諧波度 N。
- 根據N和小區上行計算諧波高頻和諧波低頻。
- 查找位於下方諧波下限內的第一個 20MHz Wi-Fi 信道。
- 計算 Wi-Fi 通道上的諧波重疊，如果重疊超過 2.4GHz Wi-Fi 重疊閾值，則將該通道標記為不安全。
- 查找第一個 20MHz Wi-Fi 信道，該信道位於來自上方的諧波上限內。
- 計算 Wi-Fi 通道上的諧波重疊，如果重疊超過 2.4GHz Wi-Fi 重疊閾值，則將該通道標記為不安全。
- 將其間的每個 20MHz 頻道標記為不安全頻道。
如果定義了參數，則從諧波中查找不安全的 5GHz 通道。
- 找到 5GHz 的諧波次數 N。如果 N 為 0，則跳到步驟 5。
- 根據N和小區上行計算諧波高頻和諧波低頻。
發現不安全的 20Mhz 頻道。
- 查找位於下方諧波下限內的第一個 20MHz Wi-Fi 信道。
- 計算 Wi-Fi 通道上的諧波重疊，如果重疊超過 2.4GHz Wi-Fi 重疊閾值，則將該通道標記為不安全。
- 查找第一個 20MHz Wi-Fi 信道，該信道位於來自上方的諧波上限內。
- 計算 Wi-Fi 通道上的諧波重疊，如果重疊超過 2.4GHz Wi-Fi 重疊閾值，則將該通道標記為不安全。
- 將其間的每個 20MHz 頻道標記為具有指定功率上限的不安全頻道。
發現不安全的 40MHz、80MHz、160MHz 頻道
- 重複步驟 3a，但頻率為 40MHz、80MHz、160MHz。
- 不是計算諧波邊緣上通道的重疊，而是重用從較小的組成通道計算的重疊（例如，如果兩個 20Mhz 通道組成一個 40Mhz 通道並且有 30% 和 90% 的重疊，則平均值為 60%對於 40Mhz 頻道）。
如果定義了參數，則從互調中查找不安全的 2.4GHz 信道。
- 求出 2.4GHz 的互調係數 N、M。
對於每個 2.4GHz Wi-Fi 信道：
- 根據N、M、小區上行、Wi-Fi信道計算互調低頻和互調高頻。
- 計算小區下行鏈路上的互調重疊，如果重疊超過 2.4GHz 小區重疊閾值，則將信道標記為不安全。
如果定義了參數，則從互調中查找不安全的 5GHz 信道。
- 使用 5GHz Wi-Fi 通道和 5GHz 小區重疊閾值重複步驟 4。
將表格條目的功率上限應用於計算的不安全通道。
最後結果
在計算了來自相鄰和諧波干擾的兩組不安全信道後，通過取兩組的並集來計算最終的一組（如果有衝突，則選擇較低的功率上限），如果有，則從集合中刪除默認信道沒有施加強制性限制。
該算法的行為如下：
- 如果每個 2.4GHz Wi-Fi 信道都被標記為不安全信道，則從集合中刪除默認的 2.4GHz Wi-Fi 信道。
- 如果每個 5GHz Wi-Fi 信道都被標記為不安全信道，則從集合中刪除默認的 5GHz Wi-Fi 信道。
- 返回最後一組不安全通道。
查找表格式
查找表在位於可覆蓋配置字符串config_wifiCoexTableFilepath中的 XML 文件中表示，並由以下 XSD 定義。
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
version="1.0">
<xsd:element name="table">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="entry" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="entry">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="rat" type="ratType"/>
<xsd:element name="band" type="xsd:int"/>
<xsd:element name="powerCapDbm" type="xsd:int" minOccurs="0"/>
<xsd:choice>
<xsd:element ref="params"/>
<xsd:element ref="override"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:simpleType name="ratType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="LTE"/>
<xsd:enumeration value="NR"/>
</xsd:restriction>
</xsd:simpleType>
<!-- Define coex algorithm parameters -->
<xsd:element name="params">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="neighborThresholds" minOccurs="0"/>
<xsd:element name="harmonicParams2g" type="harmonicParams" minOccurs="0"/>
<xsd:element name="harmonicParams5g" type="harmonicParams" minOccurs="0"/>
<xsd:element name="intermodParams2g" type="intermodParams" minOccurs="0"/>
<xsd:element name="intermodParams5g" type="intermodParams" minOccurs="0"/>
<xsd:element ref="defaultChannels" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="neighborThresholds">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="wifiVictimMhz" type="xsd:int" minOccurs="0"/>
<xsd:element name="cellVictimMhz" type="xsd:int" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="harmonicParams">
<xsd:sequence>
<xsd:element name="N" type="xsd:int"/>
<xsd:element name="overlap" type="xsd:int"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="intermodParams">
<xsd:sequence>
<xsd:element name="N" type="xsd:int"/>
<xsd:element name="M" type="xsd:int"/>
<xsd:element name="overlap" type="xsd:int"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="defaultChannels">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="default2g" type="xsd:int" minOccurs="0"/>
<xsd:element name="default5g" type="xsd:int" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- Define algorithm override lists -->
<xsd:element name="override">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="override2g" minOccurs="0"/>
<xsd:element ref="override5g" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="override2g">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="category" type="overrideCategory2g" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="channel" type="xsd:int" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="override5g">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="category" type="overrideCategory5g" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="channel" type="xsd:int" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:simpleType name="overrideCategory2g">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="all"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="overrideCategory5g">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="all"/>
<xsd:enumeration value="20Mhz"/>
<xsd:enumeration value="40Mhz"/>
<xsd:enumeration value="80Mhz"/>
<xsd:enumeration value="160Mhz"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
示例 XML 表
以下是一個示例 XML 查找表：
<table>
<!-- Entry using algorithm parameters -->
<entry>
<rat>LTE</rat>
<band>40</band>
<powerCapDbm>50</powerCapDbm>
<params>
<neighborThresholds>
<wifiVictimMhz>25</wifiVictimMhz>
<cellVictimMhz>40</cellVictimMhz>
</neighborThresholds>
<harmonicParams2g>
<N>3</N>
<overlap>50</overlap>
</harmonicParams2g>
<harmonicParams5g>
<N>3</N>
<overlap>50</overlap>
</harmonicParams5g>
<intermodParams2g>
<N>-2</N>
<M>1</M>
<overlap>75</overlap>
</intermodParams2g>
<intermodParams5g>
<N>-2</N>
<M>1</M>
<overlap>75</overlap>
</intermodParams5g>
<defaultChannels>
<default2g>6</default2g>
<default5g>36</default5g>
</defaultChannels>
</params>
</entry>
<!-- Entry using the override list -->
<entry>
<rat>LTE</rat>
<band>41</band>
<powerCapDbm>50</powerCapDbm>
<override>
<override2g>
<channel>6</channel>
<channel>11</channel>
...
</override2g>
<override5g>
<category>40Mhz</category>
<channel>34</channel>
...
</override5g>
</override>
</entry>
</table>
載波聚合
對於載波聚合 (CA)，每個上行鏈路/下行鏈路的諧波/互調範圍可能不會產生足夠的重疊以獨立造成乾擾，但在組合時可能會產生足夠的重疊。該算法獨立考慮每個諧波/互調範圍，並採用返回的不安全通道的並集。對於互調情況，這意味著評估每個 UL 到每個 DL 的互調範圍。
該算法不區分 PCELL/PSCELL/SCELL 並將它們視為平等。
許可輔助訪問
許可輔助訪問 (LAA) 被標識為波段 #46。該算法將此頻段視為與其他頻段類似。在這種情況下，可以將完整的 5Ghz 頻道設置為查找表中的覆蓋列表。
根據運營商的要求，信道規避算法對整個 5GHz Wi-Fi 頻段的 SoftAP 和 Wi-Fi Direct (P2P) 設置強制限制。對於處理此用例的算法，必須定義運營商配置值restrict_5g_softap_wifi_direct_for_laa 。如果小區信道在 LAA 上並且restrict_5g_softap_wifi_direct_for_laa為true ，則算法返回整個 5Ghz 頻段的不安全信道集，並為 SoftAP 和 Wi-Fi Direct (P2P) 設置強制限制標誌。
通知 Wi-Fi 服務
在 coex 通道算法計算出不安全通道後，為了向您的系統應用程序提供不安全通道及其限制，請使用 Android 框架中定義的以下@SystemApi 數據結構。
public final class CoexUnsafeChannel {
public static final int POWER_CAP_NONE
public @WifiAnnotations.WifiBandBasic int getBand();
public int getChannel();
// Returns the specified power cap in dBm, or POWER_CAP_NONE if not specified.
public int getPowerCapDbm();
}
使用以下WifiManager @SystemApi 方法和回調使應用程序能夠在不安全通道發生更改時獲取更新的值。
public static final int COEX_RESTRICTION_WIFI_DIRECT;
public static final int COEX_RESTRICTION_SOFTAP;
public static final int COEX_RESTRICTION_WIFI_AWARE;
// Register a CoexCallback to listen on onCoexUnsafeChannelsChanged callbacks. The callback will be called whenever the unsafe channels change, as well as immediately after registering to get the current values.
public void registerCoexCallback(Executor executor, CoexCallback callback);
public void unregisterCoexCallback(CoexCallback callback);
public abstract static class CoexCallback {
//Gets called whenever getCoexUnsafeChannels()/getCoexRestrictions() have updated values
public void onCoexUnsafeChannelsChanged(List<CoexUnsafeChannels> unsafeChannels, int restrictions);
}
執行 Wi-Fi 操作
當 Wi-Fi 服務收到有關一組不安全通道的信息時，它會執行適當的操作以確保避開這些通道。本節介紹不同場景下 Wi-Fi 服務的行為。
通知司機
由於驅動程序在執行通道規避方面發揮著重要作用，因此必須將不安全的通道傳送給驅動程序和固件。為此，請使用1.5::IWifiChip HAL API。
setCoexUnsafeChannels(vec<CoexUnsafeChannel> unsafeChannels,
bitfield<IfaceType> restrictions);
軟AP
SoftAP 是避免不安全通道的主要用例。以下部分概述了可通過 ACS 應用通道避免的關鍵 SoftAp 場景。這些場景描述了通道迴避算法和驅動程序或固件的行為。
在啟用 ACS 的情況下啟動 SoftAP（尚未啟動 SoftAP）
如果通道不安全並且存在 SoftAP 限制
- 該框架從 ACS 列表中刪除不安全的通道。
- 如果列表為空，則框架停止 SoftAP。
如果渠道不安全且沒有限制
- 供應商驅動程序/固件將安全通道優先於不安全通道。
SoftAP 已啟用 ACS，並且更新了不安全通道
如果 SoftAP 通道不安全並且存在 SoftAP 限制
- 該框架通過刪除不安全的通道來更新 ACS 列表。
- 如果列表為空，則框架關閉 SoftAP。
如果 SoftAP 通道不安全且沒有限制
- 框架不採取任何行動。如果避免不可行，供應商驅動程序/固件會處理避免不安全的通道或應用功率上限。
Wi-Fi 直連 (P2P)
如果存在受 Wi-Fi Direct (P2P) 限制的不安全通道。
- 框架請求
wpa_supplicant使用 HAL 方法ISupplicantP2pIface::setDisallowedFrequencies()來避免不安全的通道。
- 框架請求
如果有不安全的渠道不受限制。
- 如果使用沒有 Wi-Fi Direct (P2P) 限制的不安全通道，供應商驅動程序/固件會應用功率上限。
Wi-Fi 感知 (NAN)
該框架不參與 Wi-Fi Aware (NAN) 的頻道選擇，也不採取任何框架操作。供應商驅動程序/固件負責避免 Wi-Fi 感知 (NAN) 通道。
禁用算法
如果您想禁用默認算法實現並傳遞您自己的不安全通道列表以避免，請配置覆蓋config_wifiDefaultCoexAlgorithmEnabled 。如果覆蓋設置為 false，則禁用默認算法。然後，您可以使用自己的帶外專有算法生成不安全通道列表，以使用以下系統 API 連接到框架。
public void setCoexUnsafeChannels(Set<CoexUnsafeChannel> coexUnsafeChannels,
int coexRestrictions);
驗證實施
要驗證您對 Wi-Fi/蜂窩 coex 信道避免功能的實施，請使用以下測試。
CTS 測試
WifiManagerTest.java-
testCoexMethodsShouldFailNoPermission() -
testListenOnCoexUnsafeChannels()
-
行為測試
WifiManagerTest.py-
test_set_get_coex_unsafe_channels()
-
VTS 測試
wifi_chip_hidl_test.cpp-
TEST_P(WifiChipHidlTest, setCoexUnsafeChannels)
-