Wi-Fi/Cellular Coex 信道迴避

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/蜂窩 coex 信道避免功能提供了一種一致的信道避免方法,減少了對與 Wi-Fi 框架不同的專有代碼的需求。此外,該功能允許設備製造商配置、啟用和禁用以及覆蓋該功能。

該功能通過控制 Wi-Fi 信道來執行信道迴避。 Wi-Fi 信道迴避方案可以描述為一系列四個抽象步驟:

  1. 調製解調器報告蜂窩頻率的變化
  2. Coex 迴避算法計算不安全的 Wi-Fi 信道
  3. Coex 迴避算法通知 Wi-Fi 服務
  4. 框架或驅動程序執行適當的 Wi-Fi 操作

通道迴避方案

圖1.通道避免方案

報告蜂窩頻率的變化

電話服務報告當前使用的蜂窩信道。當工作蜂窩頻率變化時,調製解調器報告此信息通過電話服務IRadio::PhysicalChannelConfig 。該信息包括許可輔助接入 (LAA) 和載波聚合 (CA) 的指示。

從Android的12,在以下領域1.6 IRadio::PhysicalChannelConfig提供所需的共擠式調製解調器必須填入信息。

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直(P2P),軟AP,和Wi-Fi感知(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 :用於無線網絡連接的受害者兆赫距離閾值(小區上行鏈路)
  • cellVictimMhz :用於小區受害者兆赫距離閾值(小區下行鏈路)

對於每個活動小區信道,該算法的行為如下:

  1. 對於頻道的頻段,嘗試查找查找表條目。如果沒有找到表條目,則返回該單元格通道沒有不安全的通道。
  2. 根據蜂窩頻段,確定哪個 Wi-Fi 頻段存在風險以及乾擾來自頻段的哪一側(例如,較低的 2.4GHz 信道、較高的 2.4GHz 信道、較低的 5​​GHz 信道)。
  3. 如果wifiVictimMhz存在並且小區信道具有上行鏈路和

    1. 如果 Wi-Fi 頻段的下半部分有風險

      1. 通過將 wifiVictimMhz 添加到小區上行鏈路的最高頻率來查找不安全信道的上限。
      2. 查找下邊緣與限制重疊的第一個 20Mhz Wi-Fi 信道。
      3. 標記 Wi-Fi 通道、包含它的每個較大帶寬通道(例如,40Mhz、80Mhz),以及與不安全通道相同頻段的每個較低通道。
    2. 如果 Wi-Fi 頻段的上部有風險

      1. 通過將 wifiVictimMhz 減去蜂窩上行鏈路的最低頻率,找到不安全信道的下限。
      2. 查找上邊緣與限制重疊的第一個 Wi-Fi 信道。
      3. 標記 Wi-Fi 頻道、包含它的每個較大頻道(例如,40Mhz、80Mhz)以及與不安全頻道相同頻段的每個較高頻道。
  4. 如果cellVictimMhz存在並且小區信道具有的下行鏈路。

    1. 執行步驟3使用cellVictimMhz作為閾值,並比較針對小區下行鏈路而不是小區的上行鏈路。
  5. 將表條目的功率上限應用於計算出的不安全通道。

不安全通道計算

用於相鄰信道干擾圖3.不安全信道計算

諧波/互調失真

對於諧波/互調失真,coex 引擎計算諧波/互調信號的範圍並評估它與潛在受害通道的重疊百分比。如果重疊超過重疊閾值,則算法認為這是不安全的情況。受害信道上諧波/互調失真百分比重疊的計算使用以下等式進行:

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

在諧波失真情況下,該算法考慮了損害 Wi-Fi 信道的小區上行鏈路信道的諧波失真。然後,它用基於小區上行鏈路頻率和諧波度的諧波值代替高失真和低失真。

$$ 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.4GHz 和 5GHz 頻段的兩組這些值。

與相鄰干擾算法類似,該算法重複使用每個乾擾小區頻帶定義的相同功率上限值。

對於每個活動小區信道,該算法的行為如下:

  1. 對於小區信道的頻帶,它試圖找到一個查找表條目。如果未找到表條目,則返回此通道沒有不安全的通道。
  2. 如果定義了參數,則從諧波中查找不安全的 2.4GHz 通道。

    1. 求出 2.4GHz 的諧波次數 N。
    2. 基於N和小區上行計算諧波高頻和諧波低頻。
    3. 查找位於來自下方的諧波下限內的第一個 20MHz Wi-Fi 信道。
    4. 計算諧波在 Wi-Fi 信道上的重疊,如果重疊超過 2.4GHz Wi-Fi 重疊閾值,則將該信道標記為不安全。
    5. 查找位於上方諧波上限內的第一個 20MHz Wi-Fi 信道。
    6. 計算諧波在 Wi-Fi 信道上的重疊,如果重疊超過 2.4GHz Wi-Fi 重疊閾值,則將該信道標記為不安全。
    7. 將中間的每個 20MHz 頻道標記為不安全頻道。
  3. 如果定義了參數,則從諧波中查找不安全的 5GHz 通道。

    1. 求出 5GHz 的諧波次數 N。如果 N 為 0,則跳到步驟 5。
    2. 根據N和小區上行計算諧波高頻和諧波低頻。
    3. 查找不安全的 20Mhz 頻道。

      1. 查找位於來自下方的諧波下限內的第一個 20MHz Wi-Fi 信道。
      2. 計算諧波在 Wi-Fi 信道上的重疊,如果重疊超過 2.4GHz Wi-Fi 重疊閾值,則將該信道標記為不安全。
      3. 查找位於上方諧波上限內的第一個 20MHz Wi-Fi 信道。
      4. 計算諧波在 Wi-Fi 信道上的重疊,如果重疊超過 2.4GHz Wi-Fi 重疊閾值,則將該信道標記為不安全。
      5. 將中間的每個 20MHz 頻道標記為具有指定功率上限的不安全頻道。
    4. 查找不安全的 40MHz、80MHz、160MHz 頻道

      1. 重複步驟 3a,但頻率為 40MHz、80MHz、160MHz。
      2. 不計算諧波邊緣上信道的重疊,而是重用較小組成信道的計算重疊(例如,如果兩個 20Mhz 信道組成一個 40Mhz 信道並且有 30% 和 90% 重疊,則平均重疊為 60% 40Mhz 頻道)。
  4. 如果定義了參數,則從互調中查找不安全的 2.4GHz 信道。

    1. 求出 2.4GHz 的互調係數 N、M。
    2. 對於每個 2.4GHz Wi-Fi 信道:

      1. 根據N、M、小區上行、Wi-Fi信道計算互調低頻和互調高頻。
      2. 計算互調在小區下行鏈路上的重疊,如果重疊超過 2.4GHz 小區重疊閾值,則將信道標記為不安全。
  5. 如果定義了參數,則從互調中查找不安全的 5GHz 信道。

    1. 使用 5GHz Wi-Fi 信道和 5GHz 小區重疊閾值重複步驟 4。
  6. 將表條目的功率上限應用於計算出的不安全通道。

最後結果

在計算了來自相鄰和諧波干擾的兩組不安全信道後,通過取兩組的並集(如果有衝突,則選擇較低的功率上限)計算最終集合,如果有,則從集合中刪除默認信道沒有強制限制。

該算法的行為如下:

  1. 如果每個 2.4GHz Wi-Fi 信道都被標記為不安全信道,則從集合中刪除默認的 2.4GHz Wi-Fi 信道。
  2. 如果每個 5GHz Wi-Fi 信道都被標記為不安全信道,則從集合中刪除默認的 5GHz Wi-Fi 信道。
  3. 返回最後一組不安全的通道。

查找表格式

查找表被表示在位於overlayable配置字符串的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),每個上行鏈路/下行鏈路的諧波/互調範圍可能不會產生足夠的重疊來獨立地引起干擾,但在組合時可能會產生足夠的重疊。該算法獨立考慮每個諧波/互調範圍,並結合返回的不安全通道。對於互調情況,這意味著評估每個 UL 到每個 DL 的互調範圍。

該算法不區分 PCELL/PSCELL/SCELL 並將它們視為平等。

許可輔助訪問

許可證輔助訪問 (LAA) 被標識為頻段 #46。該算法將該頻段與其他頻段類似。在這種情況下,可以將完整的 5Ghz 通道設置為查找表中的覆蓋列表。

根據運營商的要求,信道迴避算法對整個 5GHz Wi-Fi 頻段的 SoftAP 和 Wi-Fi Direct (P2P) 設置了強制性限制。對於算法來處理這種使用情況下,該載體配置值restrict_5g_softap_wifi_direct_for_laa必須定義。如果該小區的信道是在左心耳和restrict_5g_softap_wifi_direct_for_laatrue ,則該算法返回集與整個5GHz頻段不安全信道,並為軟AP和Wi-Fi直(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)

  1. 如果通道不安全並且存在 SoftAP 限制

    1. 該框架從 ACS 列表中刪除了不安全的通道。
    2. 如果列表為空,則框架停止 SoftAP。
  2. 如果通道不安全且沒有限制

    1. 供應商驅動程序/固件優先考慮安全通道而不是不安全通道。

SoftAP 已啟用 ACS 且不安全通道已更新

  1. 如果 SoftAP 通道不安全並且存在 SoftAP 限制

    1. 框架通過刪除不安全通道來更新 ACS 列表。
    2. 如果列表為空,則框架關閉 SoftAP。
  2. 如果 SoftAP 通道不安全且沒有限制

    1. 框架不採取任何行動。如果避免不可行,供應商驅動程序/固件會處理避免不安全通道或應用功率上限。

Wi-Fi 直連 (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/蜂窩 coex 信道避免功能的實施,請使用以下測試。

CTS 測試

  • WifiManagerTest.java

    • testCoexMethodsShouldFailNoPermission()
    • testListenOnCoexUnsafeChannels()

ACTS 測試

  • WifiManagerTest.py

    • test_set_get_coex_unsafe_channels()

VTS 測試

  • wifi_chip_hidl_test.cpp

    • TEST_P(WifiChipHidlTest, setCoexUnsafeChannels)