本頁面由 Cloud Translation API 翻譯而成。

Wi-Fi/細胞共存通道避開

Android 12 推出的 Wi-Fi/行動網路並存管道避免功能，可在行動網路頻道可能產生干擾的情況下，識別並避免使用不安全的 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 和 Licensed Assisted Access (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 頻道

當數據機回報行動頻率變化時，共存通道演算法會計算行動網路和 Wi-Fi 通道之間的干擾情形，並判斷哪些 Wi-Fi 通道不安全。

有幾種干擾類型需要使用不同的公式：相鄰和諧波/調變。由於裝置之間的天線和版面配置有實體差異，因此每部裝置的鄰近和諧波/調變干擾模式皆不相同。為此，裝置製造商必須提供查詢表，將參數插入兩種干擾類型的一般公式。這些參數會依儲存格頻帶定義，並由有效儲存格管道的頻帶參照。

您可以在查詢表格中定義最大功率上限。如果已定義最大功率上限，則不安全的管道會以提供的功率上限傳輸。如果沒有功率上限，管道會以全功率傳輸。

一般來說，頻道避免功能會盡力避免使用不安全的 Wi-Fi 頻道，以便提升效能。但在某些情況下 (例如因電信業者規定)，某些介面必須避免使用某些行動頻帶的不安全通道。在這種情況下，強制限制會以位元遮罩的形式呈現，其中包含值，用於決定是否禁止特定管道，例如 Wi-Fi Direct (P2P)、SoftAp 和 Wi-Fi Aware (NAN)。雖然不安全的管道會建議您避免在所有用途中使用該管道，但強制限制會標示特定用途，以便您避免使用這些用途。

如果 2.4 GHz 或 5 GHz 頻帶的每個頻道都標示為不安全，查詢表可以為每個干擾性小區頻帶定義預設的 2.4 GHz 頻道或 5 GHz 頻道，做為最安全的選擇。當頻道頻譜的其他頻道遭回報為不安全時，這些預設頻道不會被回報為不安全頻道。

覆寫清單

在干擾嚴重依賴頻寬的情況下，公式方法的效用就會受到限制 (因此頻寬較大的頻道可能不安全，但頻寬較小的頻道則不會)。在某些情況下 (例如 LAA)，建議您略過計算，並使用指定的不安全管道清單。

如要這麼做，您可以在查詢表中為特定項目指定不安全管道的覆寫清單。表格項目中的覆寫清單表示系統會略過該特定的單元格頻道計算，並由覆寫清單指定相符單元格頻道的不安全 Wi-Fi 頻道。

針對頻寬敏感的情況，您可以在覆寫清單中指定特定頻道和頻寬，藉此有選擇性地避免特定頻寬。這是因為每個 Wi-Fi 頻道號碼都對應至指定頻寬。

覆寫清單會以清單的形式呈現，列出每個 Wi-Fi 頻帶的頻道號碼或預先定義的類別關鍵字：

2G 類別：

all (整個 2.4 GHz 頻帶)

5g 類別：

all (整個 5 GHz 頻帶)
20mhz (5 GHz 20 MHz 頻道)
40mhz (5 GHz 40 MHz 頻道)
80mhz (5 GHz 80 MHz 頻道)
160mhz (5 GHz 160 MHz 頻道)

相鄰頻道干擾

為了判斷鄰近頻道的干擾情形，共存避免演算法會確保攻擊者和受害者頻道之間的距離 ΔF 不會低於指定的閾值。

管道干擾

圖 2. 攻擊者和受害者頻道之間的距離

閾值取決於裝置的實際設定，以及每個干擾頻帶在查詢表項目中提供的閾值值。系統會將不干擾的頻帶視為表格項目，因此不需要計算不安全的頻道 (這也是大多數情況)。

鄰近干擾參數

wifiVictimMhz：Wi-Fi 受害者 (無線網路上行鏈路) 的 MHz 距離閾值
cellVictimMhz：細胞受害者的 MHz 距離閾值 (細胞下行鏈路)

演算法會針對每個有效的單元格管道執行以下操作：

針對頻道的頻帶，嘗試尋找查詢表項目。如果找不到表格項目，則會傳回該單元格管道沒有不安全管道。
根據行動網路頻帶，指出哪個 Wi-Fi 頻帶有風險，以及干擾來自頻帶的哪一側 (例如較低的 2.4 GHz 頻道、較高的 2.4 GHz 頻道、較低的 5 GHz 頻道)。
如果 wifiVictimMhz 存在，且單元格式通道有上行鏈路和
1. 如果 Wi-Fi 頻帶的低頻部分有風險
  1. 將 wifiVictimMhz 新增至行動上行鏈路的最高頻率，找出不安全管道的上限。
  2. 找出下限重疊的首個 20 MHz Wi-Fi 頻道。
  3. 標記 Wi-Fi 頻道、包含該頻道的每個較大頻寬頻道 (例如 40 Mhz、80 Mhz)，以及與不安全頻道相同頻帶的每個較低頻道。
2. 如果 Wi-Fi 頻帶的上層有風險
  1. 將 wifiVictimMhz 減去蜂巢式上行鏈路的最低頻率，找出不安全頻道的下限。
  2. 找出上限邊界重疊的 Wi-Fi 頻道。
  3. 標記 Wi-Fi 頻道、包含該頻道的每個較大的頻道 (例如 40 MHz、80 MHz)，以及與不安全頻道相同頻帶的每個較高頻道。
如果 cellVictimMhz 存在，且單元格通道有下行鏈路。
1. 使用 cellVictimMhz 做為閾值執行步驟 3，並比較小區下行鏈路，而非小區上行鏈路。
將表格項目的電源上限套用至計算出的不安全管道。

不安全管道的計算

圖 3. 鄰近頻道干擾的安全頻道計算

諧波或互調失真

針對諧波或調變失真，coex 引擎會計算諧波或調變信號的範圍，並評估與潛在受害頻道的重疊百分比。如果重疊部分超過重疊門檻，演算法會將此視為不安全的情況。計算受害管道上諧波或互調失真重疊百分比時，可使用下列公式：

$$ overlap = \frac{min(distortion_{high}, victim_{high}) - max(distortion_{low}, victim_{low})}{victim_{bandwidth}} $$

在諧波失真的情況下，演算法會考量蜂巢式上行鏈路對 Wi-Fi 鏈路造成的諧波失真。接著，系統會根據小區上行鏈路頻率和諧波度 $ N $，將高失真和低失真替換為諧波值。

$$ harmonic_{high} = N * uplink_{high} $$

$$ harmonic_{low} = N * uplink_{low} $$

不安全的管道計算諧波失真

圖 4. 諧波失真的不安全頻道計算

在交調情況下，演算法會考量蜂巢式上行鏈路和 Wi-Fi 通道的交調失真，並影響蜂巢式下行鏈路通道。接著，系統會根據小區上行頻率、Wi-Fi 頻率和兩個交互調製係數 $ M $、$ N $，將高失真和低失真替換為交互調值。

$$ intermod_{high} = |M*wifi_{high} + N*uplink_{high}| $$

$$ intermod_{low} = |M*wifi_{low} + N*uplink_{low}| $$

不安全的管道計算交互調失真

圖 5. 互調失真現象的安全頻道計算

您可以在查詢表格中為每個干擾性小區頻帶指定 $ M $、$ N $ 和重疊值。如果某個頻帶沒有干擾，則該頻帶項目的值會從表格中省略。您可以分別定義兩組 Wi-Fi 2.4 GHz 和 5 GHz 頻帶的這些值。

與鄰近干擾演算法類似，此演算法會重複使用每個干擾型小區頻帶定義的相同功率上限值。

演算法會針對每個有效的單元格管道執行以下操作：

對於儲存格通道的頻帶，它會嘗試尋找查詢表項目。如果找不到資料表項目，則會傳回此頻道沒有不安全管道。
如果已定義參數，則會從諧波中找出不安全的 2.4 GHz 頻道。
1. 找出 2.4 GHz 的諧波次數 N。
2. 根據 N 和小區上行鏈路，計算諧波高頻率和諧波低頻率。
3. 找出位於諧波下限以下的首個 20 MHz Wi-Fi 頻道。
4. 計算諧波與 Wi-Fi 頻道的重疊情形，如果重疊情形超過 2.4 GHz Wi-Fi 重疊門檻，就會將頻道標示為不安全。
5. 找出第一個 20 MHz Wi-Fi 頻道，該頻道位於來自上方的諧波上限內。
6. 計算諧波與 Wi-Fi 頻道的重疊情形，如果重疊情形超過 2.4 GHz Wi-Fi 重疊門檻，就會將頻道標示為不安全。
7. 將介於兩者之間的每個 20 MHz 頻道標示為不安全頻道。
如果已定義參數，則會從諧波中找出不安全的 5 GHz 頻道。
1. 找出 5 GHz 的諧波次數 N。如果 N 為 0，請跳至步驟 5。
2. 根據 N 和小區上行鏈路，計算諧波高頻率和諧波低頻率。
3. 找出不安全的 20 MHz 頻道。
  1. 找出位於下方諧波下限內的第一個 20 MHz Wi-Fi 頻道。
  2. 計算 Wi-Fi 頻道上諧波的重疊情形，如果重疊情形超過 2.4 GHz Wi-Fi 重疊門檻，就會將頻道標示為不安全。
  3. 找出第一個 20 MHz Wi-Fi 頻道，該頻道位於來自上方的諧波上限內。
  4. 計算 Wi-Fi 頻道上諧波的重疊情形，如果重疊情形超過 2.4 GHz Wi-Fi 重疊門檻，就會將頻道標示為不安全。
  5. 將介於兩者之間的每個 20 MHz 頻道標示為具有指定功率上限的不安全頻道。
4. 找出不安全的 40 MHz、80 MHz 和 160 MHz 頻道
  1. 重複執行步驟 3a，但使用 40 MHz、80 MHz 和 160 MHz。
  2. 不計算諧波邊緣的通道重疊，而是重複使用較小構成通道的計算重疊 (例如，如果兩個 20 Mhz 通道組成一個 40 Mhz 通道，且重疊率分別為 30% 和 90%，則 40 Mhz 通道的平均重疊率為 60%)。
如果定義參數，則會從交互調中找出不安全的 2.4 GHz 頻道。
1. 找出 2.4 GHz 的互調係數 N、M。
2. 針對每個 2.4 GHz Wi-Fi 頻道：
  1. 根據 N、M、小區上行鏈路和 Wi-Fi 通道，計算交互調低頻和交互調高頻。
  2. 計算小區下行鏈路的互調疊加，如果疊加超過 2.4 GHz 小區重疊門檻，就會將頻道標示為不安全。
如果已定義參數，則會從交互調中找出不安全的 5 GHz 頻道。
1. 使用 5 GHz Wi-Fi 頻道和 5 GHz 小區重疊門檻重複執行步驟 4。
將表格項目的電源上限套用至計算出的不安全管道。

最終結果

計算鄰近和諧波干擾的兩組不安全頻道後，系統會計算最終組合 (並在發生衝突時選取較低的功率上限)，並在未套用強制限制的情況下，從組合中移除預設頻道。

演算法的運作方式如下：

如果每個 2.4 GHz Wi-Fi 頻道都標示為不安全，請從設定中移除預設的 2.4 GHz Wi-Fi 頻道。
如果每個 5 GHz Wi-Fi 頻道都標示為不安全頻道，請從設定中移除預設的 5 GHz Wi-Fi 頻道。
傳回最終的不安全管道組合。

對照表格式

查詢表會以 XML 檔案的形式呈現，位於可重疊的設定字串 config_wifiCoexTableFilepath 中，並由下列 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) 而言，每個上行鏈路或下行鏈路的諧波或互調干擾範圍可能不會產生足夠的重疊，導致獨立產生干擾，但在合併時可能會產生足夠的重疊。演算法會個別考量每個諧波或交調範圍，並取回傳回的 unsafe 管道聯合。就交互調變化而言，這表示評估每個 UL 到每個 DL 的交互調變化範圍。

演算法不會區分 PCELL、PSCELL 或 SCELL，而是將這些值視為相同。

授權輔助存取

授權輔助存取 (LAA) 會標示為頻帶 #46。演算法會將這個頻段視為其他頻段。在這種情況下，可將完整的 5 GHz 頻道設為查詢表中的覆寫清單。

視電信業者需求而定，管道避免演算法會針對整個 5 GHz Wi-Fi 頻帶的 SoftAP 和 Wi-Fi Direct (P2P) 設定強制限制。演算法必須定義載具設定值 restrict_5g_softap_wifi_direct_for_laa，才能處理這個用途。如果小區域頻道為 LAA，且 restrict_5g_softap_wifi_direct_for_laa 為 true，演算法會傳回包含整個 5 GHz 頻帶的不安全頻道組合，並為 SoftAP 和 Wi-Fi Direct (P2P) 設定強制限制標記。

通知 Wi-Fi 服務

共用通道演算法計算出不安全的通道後，請使用 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 服務在不同情況下的行為。

通知駕駛員

由於驅動程式在執行管道避開功能時扮演重要角色，因此必須將不安全的管道傳送至驅動程式和韌體。方法是使用下列 IWifiChip HAL API。

AIDL：

void setCoexUnsafeChannels(in CoexUnsafeChannel[] unsafeChannels,
  in int restrictions)

適用於 HIDL (1.5 以上版本)：

setCoexUnsafeChannels(vec<CoexUnsafeChannel> unsafeChannels,
  bitfield<IfaceType> restrictions);

SoftAP

軟 AP 是避免使用不安全頻道的常見用途。以下章節將概略說明可使用 ACS 避免頻道的幾個主要 SoftAp 情境。這些情境說明瞭管道避開演算法和驅動程式或韌體的行為。

啟動已啟用 ACS 的 SoftAP (尚未啟用 SoftAP)

如果頻道不安全，且有 SoftAP 限制
1. 架構會從 ACS 清單中移除不安全的管道。
2. 如果清單為空白，架構就會停止 SoftAP。
如果頻道不安全且沒有任何限制
1. 供應商驅動程式或韌體會優先使用安全管道，而非不安全管道。

SoftAP 已啟用 ACS，且已更新不安全的頻道

如果 SoftAP 頻道不安全，且有 SoftAP 限制
1. 架構會移除不安全的管道，以更新 ACS 清單。
2. 如果清單為空白，架構會關閉 SoftAP。
如果 SoftAP 頻道不安全，且沒有任何限制
1. 架構不會採取任何行動。供應商驅動程式或韌體會負責避免使用不安全的管道，或在無法避免的情況下套用電源上限。

Wi-Fi Direct (P2P)

有 Wi-Fi Direct (P2P) 限制的不安全管道。
1. 架構會要求 wpa_supplicant，以便使用 HAL 方法 ISupplicantP2pIface::setDisallowedFrequencies() 避免不安全的管道。
如有未受限制的危險管道。
1. 如果使用未設有 Wi-Fi Direct (P2P) 限制的不安全管道，供應商驅動程式或韌體會套用功率上限。

Wi-Fi Aware (NAN)

此架構不會參與 Wi-Fi Aware (NAN) 的頻道選取作業，也不會採取任何架構動作。供應商驅動程式或韌體負責避免使用 Wi-Fi Aware (NAN) 頻道。

停用演算法

如要停用預設演算法實作，並傳遞自己的不安全管道清單以便避開，請設定重疊 config_wifiDefaultCoexAlgorithmEnabled。如果疊加層設為 false，系統會停用預設演算法。接著，您可以使用自己的額外專屬演算法，產生不安全管道的清單，並使用下列系統 API 將其匯入架構。

public void setCoexUnsafeChannels(Set<CoexUnsafeChannel> coexUnsafeChannels,
  int coexRestrictions);

驗證導入狀態

如要驗證您實作 Wi-Fi/行動網路並行通道避免功能的結果，請使用下列測試。

CTS 測試

WifiManagerTest.java
- testCoexMethodsShouldFailNoPermission()
- testListenOnCoexUnsafeChannels()

ACTS 測試

WifiManagerTest.py
- test_set_get_coex_unsafe_channels()

VTS 測試

如果已實作 AIDL：wifi_chip_aidl_test.cpp
- TEST_P(WifiChipAidlTest, SetCoexUnsafeChannels)
如果已實作 HIDL：wifi_chip_hidl_test.cpp
- TEST_P(WifiChipHidlTest, setCoexUnsafeChannels)