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 通道避開配置：

  1. 數據機回報行動頻率變更
  2. 排除共存演算法會計算不安全的 Wi-Fi 頻道
  3. 排除共存演算法有助於 Wi-Fi 服務
  4. 架構或驅動程式執行適當的 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 頻道)

相鄰頻道干擾

為判斷相鄰管道幹擾，共事排除演算法會確保侵略者與受害管道之間的距離 segmentF 距離未達到指定的門檻。

管道干擾

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

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

鄰近干擾參數

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

在每個使用中的儲存格頻道，演算法的行為如下：

  1. 針對頻道的頻帶，嘗試尋找查詢表項目。如果找不到任何資料表項目，就會傳回該儲存格頻道沒有不安全的頻道。
  2. 根據行動網路頻帶，找出哪個 Wi-Fi 頻帶有風險，以及干擾來自頻帶的哪一側 (例如較低的 2.4 GHz 頻道、較高的 2.4 GHz 頻道、較低的 5 GHz 頻道)。

  3. 如果 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 頻道、包含該頻道的每個較大的頻道 (例如 40M hz、80 Mhz)，以及與不安全頻道相同頻帶的每個較高頻道。

  4. 如果 cellVictimMhz 存在，且單元格通道有下行鏈路。

    1. 使用 cellVictimMhz 做為閾值執行步驟 3，並比較小區下行鏈路，而非小區上行鏈路。

  5. 將表格項目的電源上限套用至計算出的不安全管道。

不安全管道的計算

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

諧波或互調失真

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

$$ 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 頻帶的兩組這些值。

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

演算法會針對每個有效的單元格管道，以以下方式運作：

  1. 針對儲存格頻道所屬樂團，系統會嘗試尋找對照表項目。 如果找不到表格項目，則會傳回此頻道沒有不安全管道。

  2. 如果已定義參數，則會從諧波中找出不安全的 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 頻道標示為不安全頻道。

  3. 如果已定義參數，則會從諧波中找出不安全的 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%)。

  4. 在已定義參數的情況下，尋找不安全的 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. 在已定義參數的情況下，尋找不安全的 5 GHz 通道。

    1. 使用 5 GHz Wi-Fi 頻道和 5 GHz 小區重疊門檻重複執行步驟 4。

  6. 將表格項目的功率上限套用至計算得出的不安全管道。

最終結果

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

演算法的運作方式如下：

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

對照表格式

查詢表會以 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);

軟碟機

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

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

  1. 如果頻道不安全且有 SoftAP 限制

    1. 這個架構會將不安全的頻道從 ACS 清單中移除。
    2. 如果清單空白，架構會停止 SoftAP。

  2. 如果頻道不安全且沒有任何限制

    1. 供應商驅動程式或韌體會優先使用安全管道，而非不安全管道。

SoftAP 支援 ACS，並更新不安全的頻道

  1. 如果 SoftAP 頻道不安全，且有 SoftAP 限制

    1. 架構會移除不安全的管道，以更新 ACS 清單。
    2. 如果清單為空白，架構會關閉 SoftAP。

  2. 如果 SoftAP 頻道不安全，且沒有任何限制

    1. 架構不會採取任何行動。廠商驅動程式或韌體會負責避免不安全的通道，或在避免不可行時套用電源上限。

Wi-Fi Direct (P2P)

  1. 有未受 Wi-Fi Direct (P2P) 限制的安全管道。

    1. 架構會要求 wpa_supplicant，避免使用 HAL 方法 ISupplicantP2pIface::setDisallowedFrequencies() 的不安全的管道。

  2. 如有未受限制的危險管道。

    1. 如果使用沒有 Wi-Fi Direct (P2P) 限制的不安全通道，供應商驅動程式或韌體會套用電源上限。

Wi-Fi 感知 (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)