Wi-Fi /セルラーCoexチャネルの回避

Android12で導入された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、Licensed Assisted Access（LAA）などのセルラーテクノロジーを搭載したデバイスの場合、使用中のセルラーチャネルが、使用中のWi-Fiチャネルと干渉する可能性があります。これは、セルラーチャネルとWi-Fiチャネルが短い周波数分離（隣接チャネル）内にある場合、または高調波と相互変調の干渉がある場合に発生します。

このタイプの干渉は、1つのアンテナが送信し、別のアンテナが同時に受信している場合に問題になります。この場合、送信アンテナが受信アンテナにフラッディングし、受信品質に影響を与えます。

このドキュメントでは、干渉する送信機を攻撃者と呼び、干渉を経験している受信者を被害者と呼びます。攻撃者または被害者のいずれかであるWi-Fiチャネルは、安全でないチャネルと呼ばれます。

Wi-Fi /セルラーcoexチャネル回避機能は、チャネル回避のための一貫したアプローチを提供し、Wi-Fiフレームワークから分岐する独自のコードの必要性を減らします。さらに、この機能により、デバイスメーカーは機能を構成、有効化、無効化、およびオーバーライドできます。

この機能は、Wi-Fiチャネルを制御することによってチャネル回避を実行します。 Wi-Fiチャネル回避スキームは、一連の4つの抽象的なステップとして説明できます。

  1. モデムはセルラー周波数の変化を報告します
  2. Coex回避アルゴリズムは安全でないWi-Fiチャネルを計算します
  3. Coex回避アルゴリズムが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チャネルの計算

モデムがセルラー周波数の変化を報告すると、coexチャネルアルゴリズムがセルラーチャネルとWi-Fiチャネル間の干渉を計算し、安全でないWi-Fiチャネルのセットを判別します。

異なる式を必要とする干渉には複数のタイプがあります：隣接および高調波/相互変調。デバイス間のアンテナとレイアウトの物理的な違いにより、各デバイスの隣接干渉と高調波/相互変調干渉のパターンは異なります。これを説明するために、デバイスメーカーは、2種類の干渉の一般的な式にパラメーターをプラグインするためのルックアップテーブルを提供する必要があります。これらのパラメータはセルバンドごとに定義され、アクティブなセルチャネルのバンドによって参照されます。

最大電力上限は、ルックアップテーブルで定義できます。最大パワーキャップが定義されている場合、安全でないチャネルは提供されたパワーキャップで送信します。パワーキャップがない場合、チャネルはフルパワーで送信します。

一般に、チャネル回避機能は、パフォーマンスを最適化するために安全でない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チャネル）

隣接チャネル干渉

隣接チャネル干渉を決定するために、coex回避アルゴリズムは、アグレッサーチャネルとビクティムチャネル間の距離ΔFが指定されたしきい値を下回らないようにします。

チャネル干渉

図2.攻撃者と被害者のチャネル間の距離

しきい値は、デバイスの物理構成と、干渉帯域ごとのルックアップテーブルエントリで提供されるしきい値によって決定されます。非干渉と見なされるバンドにはテーブルエントリがなく、安全でないチャネルを計算する必要はありません（これはほとんどの場合です）。

隣接する干渉パラメータ

  • wifiVictimMhz ：Wi-Fi被害者のMHz距離しきい値（セルアップリンク）
  • cellVictimMhz ：セルビクティムのMHz距離しきい値（セルダウンリンク）

アルゴリズムは、アクティブなセルチャネルごとに次のように動作します。

  1. チャネルの帯域について、ルックアップテーブルエントリを見つけようとします。テーブルエントリが見つからない場合は、そのセルチャネルの安全でないチャネルなしで戻ります。
  2. セルラー帯域に基づいて、どのWi-Fi帯域が危険にさらされているか、および帯域のどちら側から干渉が発生しているかを識別します（たとえば、低い2.4GHzチャネル、高い2.4GHzチャネル、低い5GHzチャネル）。

  3. wifiVictimMhzが存在し、セルチャネルにアップリンクと

    1. Wi-Fi帯域の下部が危険にさらされている場合

      1. セルのアップリンクの最高周波数にwifiVictimMhzを追加して、安全でないチャネルの上限を見つけます。
      2. 下端が制限と重なっている最初の20MhzWi-Fiチャネルを検索します。
      3. Wi-Fiチャネル、それを含むすべてのより広い帯域幅チャネル（たとえば、40Mhz、80Mhz）、および安全でないチャネルと同じ帯域のすべてのより低いチャネルをマークします。

    2. Wi-Fi帯域の上部が危険にさらされている場合

      1. セルのアップリンクの最低周波数からwifiVictimMhzを差し引くことにより、安全でないチャネルの下限を見つけます。
      2. 上端が制限と重なっている最初のWi-Fiチャネルを検索します。
      3. Wi-Fiチャネル、それを含むすべての大きなチャネル（たとえば、40Mhz、80Mhz）、および安全でないチャネルと同じ帯域のすべての上位チャネルをマークします。

  4. cellVictimMhzが存在し、セルチャネルにダウンリンクがある場合。

    1. しきい値としてcellVictimMhzを使用してステップ3を実行し、セルのアップリンクではなくセルのダウンリンクと比較します。

  5. テーブルエントリのパワーキャップを、計算された安全でないチャネルに適用します。

安全でないチャネル計算

図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周波数、および2つの相互変調係数$ 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帯域のこれらの値の2つのセットは、独立して定義できます。

隣接する干渉アルゴリズムと同様に、アルゴリズムは干渉セル帯域ごとに定義された同じパワーキャップ値を再利用します。

アルゴリズムは、アクティブなセルチャネルごとに次のように動作します。

  1. セルチャネルの帯域については、ルックアップテーブルエントリを見つけようとします。テーブルエントリが見つからない場合は、このチャネルの安全でないチャネルなしで戻ります。

  2. パラメータが定義されている場合、高調波から安全でない2.4GHzチャネルを検索します。

    1. 2.4GHzの高調波次数Nを求めます。
    2. Nとセルのアップリンクに基づいて、高調波高周波と高調波低周波を計算します。
    3. 下から来る高調波の下限内にある最初の20MHzWi-Fiチャネルを検索します。
    4. Wi-Fiチャネルでの高調波のオーバーラップを計算し、オーバーラップが2.4GHz Wi-Fiオーバーラップしきい値を超えた場合、チャネルを安全でないものとしてマークします。
    5. 上から来る高調波の上限内にある最初の20MHzWi-Fiチャネルを検索します。
    6. Wi-Fiチャネルでの高調波のオーバーラップを計算し、オーバーラップが2.4GHz Wi-Fiオーバーラップしきい値を超えた場合、チャネルを安全でないものとしてマークします。
    7. 間にあるすべての20MHzチャネルを安全でないチャネルとしてマークします。

  3. パラメータが定義されている場合、高調波から安全でない5GHzチャネルを検索します。

    1. 5GHzの高調波次数Nを求めます。 Nが0の場合、ステップ5にスキップします。
    2. Nとセルのアップリンクに基づいて、高調波高周波と高調波低周波を計算します。

    3. 安全でない20Mhzチャネルを検索します。

      1. 下から来る高調波の下限内にある最初の20MHzWi-Fiチャネルを検索します。
      2. Wi-Fiチャネルでの高調波のオーバーラップを計算し、オーバーラップが2.4GHz Wi-Fiオーバーラップしきい値を超えた場合、チャネルを安全でないものとしてマークします。
      3. 上から来る高調波の上限内にある最初の20MHzWi-Fiチャネルを検索します。
      4. Wi-Fiチャネルでの高調波のオーバーラップを計算し、オーバーラップが2.4GHz Wi-Fiオーバーラップしきい値を超えた場合、チャネルを安全でないものとしてマークします。
      5. 間にあるすべての20MHzチャネルを、指定された電力上限を持つ安全でないチャネルとしてマークします。

    4. 安全でない40MHz、80MHz、160MHzチャネルを検索

      1. 手順3aを繰り返しますが、40MHz、80MHz、160MHzを使用します。
      2. ハーモニックエッジでのチャネルのオーバーラップを計算する代わりに、小さい構成チャネルから計算されたオーバーラップを再利用します（たとえば、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. 5GHzWi-Fiチャネルと5GHzセルオーバーラップしきい値を使用して手順4を繰り返します。

  6. テーブルエントリのパワーキャップを、計算された安全でないチャネルに適用します。

最終結果

隣接干渉と高調波干渉からの安全でないチャネルの両方のセットが計算された後、両方のセットの和集合を取り（衝突がある場合はより低い電力上限を選択し）、存在する場合はデフォルトのチャネルをセットから削除することによって、最終セットが計算されます。必須の制限は適用されません。

アルゴリズムは次のように動作します。

  1. すべての2.4GHzWi-Fiチャネルが安全でないチャネルとしてマークされている場合は、デフォルトの2.4GHzWi-Fiチャネルをセットから削除します。
  2. すべての5GHzWi-Fiチャネルが安全でないチャネルとしてマークされている場合は、デフォルトの5GHzWi-Fiチャネルをセットから削除します。
  3. 安全でないチャネルの最終セットを返します。

ルックアップテーブル形式

ルックアップテーブルは、オーバーレイ可能な構成文字列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）の場合、各アップリンク/ダウンリンクの高調波/相互変調範囲は、独立して干渉を引き起こすのに十分なオーバーラップを生成しない可能性がありますが、組み合わせると十分なオーバーラップを生成する可能性があります。アルゴリズムは、各高調波/相互変調範囲を個別に考慮し、返された安全でないチャネルの和集合を取ります。相互変調の場合、これは、すべてのDLに対するすべてのULの相互変調範囲を評価することを意味します。

アルゴリズムはPCELL/PSCELL / SCELLを区別せず、それらを同等として扱います。

ライセンス支援アクセス

License Assisted Access（LAA）は、バンド＃46として識別されます。アルゴリズムは、このバンドを他のバンドと同様に扱います。この場合、完全な5Ghzチャネルをルックアップテーブルのオーバーライドリストとして設定できます。

キャリア要件に応じて、チャネル回避アルゴリズムは、5GHzWi-Fi帯域全体のSoftAPおよびWi-FiDirect（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を使用します。

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

SoftAP

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 Direct（P2P）

  1. Wi-Fi Direct（P2P）制限のある安全でないチャネルがある場合。

    1. フレームワークは、HALメソッドISupplicantP2pIface::setDisallowedFrequencies()を使用して、安全でないチャネルを回避するようにwpa_supplicantに要求します。

  2. 制限のない安全でないチャネルがある場合。

    1. Wi-Fi Direct（P2P）制限のない安全でないチャネルが使用されている場合、ベンダーのドライバー/ファームウェアはパワーキャップを適用します。

Wi-Fi対応（NAN）

フレームワークはWi-FiAware（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)