Wi-Fi/cellular coex channel avoidance

The Wi-Fi/cellular coex channel avoidance feature, introduced in Android 12, identifies and avoids using unsafe Wi-Fi channels in cases where there might be interference from or to cellular channels. This includes interfaces such as STA, SoftAp, Wi-Fi Direct (P2P), Wi-Fi Aware (NAN).

This page discusses the following:

  • Information the cellular modem must report to the Android framework
  • Algorithms the Wi-Fi framework uses to calculate Wi-Fi channels to be avoided
  • Configuration tables that device manufacturers must provide for the Wi-Fi framework
  • System APIs, configurations, and HAL APIs related to the channel avoidance feature
  • Framework behavior for handling channel avoidance
  • Chip vendor behavior for handling channel avoidance
  • Implementation details for channel avoidance
  • Tests for validating channel avoidance behavior

Background

For devices with cellular technologies such as LTE, 5G NR, and Licensed Assisted Access (LAA), the cellular channels in use can interfere with the Wi-Fi channel in use. This occurs when the cellular and Wi-Fi channels are within short frequency separation (neighboring channels) or when there is harmonic and intermodulation interference.

This type of interference becomes a problem when one antenna is transmitting and another is receiving at the same time. In this case, the transmitting antenna floods the receiving antenna, impacting its reception quality.

This document refers to the interfering transmitter as the aggressor and the receiver experiencing the interference as the victim. The Wi-Fi channel that is either the aggressor or the victim is referred to as an unsafe channel.

The Wi-Fi/cellular coex channel avoidance feature provides a consistent approach for channel avoidance reducing the need for proprietary code that diverges from the Wi-Fi framework. Additionally, the feature allows device manufacturers to configure, enable and disable, and override the feature.

The feature performs channel avoidance by controlling the Wi-Fi channels. The Wi-Fi channel avoidance scheme can be described as a series of four abstract steps:

  1. Modem reports change in cellular frequency
  2. Coex avoidance algorithm calculates unsafe Wi-Fi channels
  3. Coex avoidance algorithm informs Wi-Fi service
  4. Framework or driver performs appropriate Wi-Fi action

Channel avoidance scheme

Figure 1. Channel avoidance scheme

Report a change in cellular frequency

The telephony service reports the cellular channels currently in use. When the operating cellular frequency changes, the modem reports this information to the telephony service through IRadio::PhysicalChannelConfig. This information includes indications for licensed assisted access (LAA) and carrier aggregation (CA).

From Android 12, the following fields in 1.6 IRadio::PhysicalChannelConfig provide required information for the coex formulas that the modem must populate.

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;
}

Calculate unsafe Wi-Fi channels

When the modem reports a change in cellular frequency, the coex channel algorithm calculates the interference between cellular and Wi-Fi channels and determines what set of Wi-Fi channels are unsafe.

There are multiple types of interference requiring different formulas: neighboring and harmonic/intermodulation. Due to the physical differences in antenna and layout between devices, the patterns of neighboring and harmonic/intermodulation interference for each device are different. To account for this, device manufacturers must provide a lookup table to plug parameters into generic formulas for the two types of interference. These parameters are defined per cell band and are referenced by the bands of the active cell channels.

A maximum power cap can be defined in the lookup table. If a maximum power cap is defined, an unsafe channel transmits with the provided power cap. If there's no power cap, the channel transmits at full power.

In general, the channel avoidance feature uses a best effort approach to avoid unsafe Wi-Fi channels to optimize performance. But in certain cases (for example, because of carrier requirements), it's mandatory for certain interfaces to avoid unsafe channels for certain cellular bands. In such cases, mandatory restrictions are represented as a bitmask containing values for whether to prohibit certain channels such as Wi-Fi Direct (P2P), SoftAp, and Wi-Fi Aware (NAN). While an unsafe channel acts as a recommendation against using that channel for all use cases, mandatory restrictions mark specific use cases for mandatory avoidance.

If every channel of the 2.4 GHz or 5 GHz band is marked unsafe, the lookup table can define a default 2.4 GHz channel or a default 5 GHz channel per interfering cell band as the safest choice. These default channels aren't reported as unsafe channels when the rest of the band is reported unsafe.

Override list

A formulaic approach is limited in cases where interference is heavily bandwidth dependent (and thus channels with larger bandwidth might be unsafe but not channels with smaller bandwidth). In cases, such as with LAA, it's beneficial to skip the calculations and use a specified list of unsafe channels.

To do this, you can specify an override list of unsafe channels in the lookup table for certain entries. An override list in a table entry signifies that the calculation for that particular cell channel is skipped and that the unsafe Wi-Fi channels for the matching cell channel are specified by the override list.

For bandwidth-sensitive cases, you can selectively avoid certain bandwidths by specifying certain channels with certain bandwidths in the override list. This is because each Wi-Fi channel number corresponds to a specified bandwidth.

The override list is represented by a list of channel numbers or pre-defined category keywords for each Wi-Fi band:

2g categories:

  • all (entire 2.4 GHz band)

5g categories:

  • all (entire 5 GHz band)
  • 20mhz (5 GHz 20 MHz channels)
  • 40mhz (5 GHz 40 MHz channels)
  • 80mhz (5 GHz 80 MHz channels)
  • 160mhz (5 GHz 160 MHz channels)

Neighboring channel interference

To determine neighboring channel interference, the coex avoidance algorithm makes sure the distance ΔF between an aggressor and victim channel doesn't go under a specified threshold.

Channel interference

Figure 2. Distance between an aggressor and victim channel

The threshold is determined by the physical configuration of the device and the threshold value provided in the lookup table entry per interfering band. Bands that are considered non-interfering don't have a table entry and unsafe channels don't need to be calculated (this is the majority of the time).

Neighboring interference parameters

  • wifiVictimMhz: MHz distance threshold for a Wi-Fi victim (cell uplink)
  • cellVictimMhz: MHz distance threshold for a cell victim (cell downlink)

The algorithm behaves as follows for each active cell channel:

  1. For the channel's band, tries to find a lookup table entry. If no table entry is found, returns with no unsafe channels for that cell channel.
  2. Based on the cellular band, identifies which Wi-Fi band is at risk and which side of the band the interference comes from (for example, lower 2.4 GHz channels, higher 2.4 GHz channels, lower 5 GHz channels).

  3. If wifiVictimMhz is present and the cell channel has uplink and

    1. If the lower part of the Wi-Fi band is at risk

      1. Finds the upper limit of unsafe channels by adding wifiVictimMhz to the cell uplink's highest frequency.
      2. Finds the first 20 Mhz Wi-Fi channel whose lower edge overlaps the limit.
      3. Marks the Wi-Fi channel, every larger bandwidth channel that contains it (for example, 40 Mhz, 80 Mhz), and every lower channel of the same band as the unsafe channel.

    2. If the upper part of the Wi-Fi band is at risk

      1. Finds the lower limit of unsafe channels by subtracting wifiVictimMhz to the cell uplink's lowest frequency.
      2. Finds the first Wi-Fi channel whose upper edge overlaps the limit.
      3. Marks the Wi-Fi channel, every larger channel that contains it (for example, 40M hz, 80 Mhz), and every higher channel of the same band as the unsafe channel.

  4. If cellVictimMhz is present and the cell channel has downlink.

    1. Performs step 3 using cellVictimMhz as the threshold and compares against cell downlink instead of cell uplink.

  5. Applies the table entry's power cap to the calculated unsafe channels.

Unsafe channel calculation

Figure 3. Unsafe channel calculation for neighboring channel interference

Harmonic or intermodulation distortion

For harmonic or intermodulation distortion, the coex engine calculates the range of the harmonic or intermodulation signal and evaluates the percent overlap it has with a potential victim channel. If the overlap exceeds an overlap threshold, the algorithm considers this an unsafe situation. The calculation of the percent overlap of the harmonic or intermodulation distortion on a victim channel is performed with the following equation:

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

In the harmonic distortion case, the algorithm considers the harmonic distortion of a cell uplink channel victimizing Wi-Fi channels. It then substitutes the distortion high and distortion low with the harmonic values based on the cell uplink frequencies and a harmonic degree $ N $.

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

Unsafe channel calculation harmonic distortion

Figure 4. Unsafe channel calculation for harmonic distortion

In the intermodulation case, the algorithm considers the intermodulation distortion of the cell uplink and the Wi-Fi channel victimizing the cell downlink channel. It then substitutes the distortion high and distortion low with the intermodulation values based on the cell uplink frequencies, Wi-Fi frequencies, and the two intermodulation coefficients $ M $, $ N $.

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

Unsafe channel calculation intermodulation distortion

Figure 5. Unsafe channel calculation for intermodulation distortion

You can specify $ M $, $ N $ and overlap values in the lookup table per interfering cell band. If there is no interference for a band, then the values are omitted from the table for that band entry. Two sets of these values for the Wi-Fi 2.4 GHz and 5 GHz bands can be independently defined.

Similar to the neighboring interference algorithm, the algorithm reuses the same power cap value defined per interfering cell band.

The algorithm behaves as follows for each active cell channel:

  1. For the cell channel's band, it tries to find a lookup table entry. If no table entry is found, returns with no unsafe channels for this channel.

  2. Finds the unsafe 2.4 GHz channels from harmonics if parameters are defined.

    1. Finds the harmonic degree N for 2.4 GHz.
    2. Calculates the harmonic high frequency and the harmonic low frequency based on N and the cell uplink.
    3. Finds the first 20 MHz Wi-Fi channel that is within the lower bound of the harmonic coming from below.
    4. Calculates the overlap of the harmonic over the Wi-Fi channel and marks the channel as unsafe if the overlap exceeds the 2.4 GHz Wi-Fi overlap threshold.
    5. Finds the first 20 MHz Wi-Fi channel that is within the upper bound of the harmonic coming from above.
    6. Calculates the overlap of the harmonic over the Wi-Fi channel and marks the channel as unsafe if the overlap exceeds the 2.4 GHz Wi-Fi overlap threshold.
    7. Marks every 20 MHz channel in between as an unsafe channel.

  3. Finds the unsafe 5 GHz channels from harmonics if parameters are defined.

    1. Finds the harmonic degree N for 5 GHz. If N is 0, skips to step 5.
    2. Calculates the harmonic high frequency and the harmonic low frequency based on N and the cell uplink.

    3. Finds unsafe 20 Mhz channels.

      1. Finds the first 20 MHz Wi-Fi channel that is within the lower bound of the harmonic coming from below.
      2. Calculates the overlap of the harmonic over the Wi-Fi channel and marks the channel as unsafe if the overlap exceeds the 2.4 GHz Wi-Fi overlap threshold.
      3. Finds the first 20 MHz Wi-Fi channel that is within the upper bound of the harmonic coming from above.
      4. Calculates the overlap of the harmonic over the Wi-Fi channel and marks the channel as unsafe if the overlap exceeds the 2.4 GHz Wi-Fi overlap threshold.
      5. Marks every 20 MHz channel in between as an unsafe channel with the specified power cap.

    4. Finds unsafe 40 MHz, 80 MHz, 160 MHz channels

      1. Repeats step 3a but with 40 MHz, 80 MHz, 160 MHz.
      2. Instead of calculating the overlaps of the channels on the harmonic edge, reuses the calculated overlaps from the smaller constituent channels (for example, if two 20 Mhz channels make a 40 Mhz channel and have 30% and 90% overlap, then the average is 60% overlap for the 40 Mhz channel).

  4. Finds the unsafe 2.4 GHz channels from intermodulation if parameters are defined.

    1. Finds the intermodulation coefficients N, M for 2.4 GHz.

    2. For each 2.4 GHz Wi-Fi channel:

      1. Calculates the intermodulation low frequency and intermodulation high frequency based on N, M, cell uplink, and Wi-Fi channel.
      2. Calculates the overlap of the intermodulation over cell downlink and marks the channel as unsafe if the overlap exceeds the 2.4 GHz cell overlap threshold.

  5. Finds the unsafe 5 GHz channels from intermodulation if parameters are defined.

    1. Repeats step 4 using the 5 GHz Wi-Fi channels and 5 GHz cell overlap threshold.

  6. Applies the table entry's power cap to the calculated unsafe channels.

Final result

After both sets of unsafe channels from neighboring and harmonic interference are calculated, the final set is calculated by taking the union of both sets (and selecting the lower power cap if there are collisions), and removing the default channels from the set if there are no mandatory restrictions applied.

The algorithm behaves as follows:

  1. If every 2.4 GHz Wi-Fi channel is marked as an unsafe channel, removes the default 2.4 GHz Wi-Fi channel from the set.
  2. If every 5 GHz Wi-Fi channel is marked as an unsafe channel, removes the default 5 GHz Wi-Fi channel from the set.
  3. Returns the final set of unsafe channels.

Lookup table format

The lookup tables are represented in an XML file located in the overlayable config string config_wifiCoexTableFilepath, and is defined by the following 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>

Example XML table

The following is an example XML lookup table:


<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>

Carrier aggregation

For carrier aggregation (CA), the harmonic or intermodulation ranges for each uplink or downlink might not produce enough overlap to cause interference independently, but might produce enough overlap when combined. The algorithm considers each harmonic or intermodulation range independently and takes the union of the returned unsafe channels. For the intermodulation case, this means assessing the intermodulation range of every UL onto every DL.

The algorithm makes no distinction between PCELL, PSCELL, or SCELL and treats them as equal.

License Assisted Access

License Assisted Access (LAA) is identified as band #46. The algorithm treats this band similar to other bands. In this case, the full 5 Ghz channels can be set as an override list in the lookup table.

Depending on carrier requirements, the channel avoidance algorithm sets mandatory restrictions on SoftAP and Wi-Fi Direct (P2P) for the entire 5 GHz Wi-Fi band. For the algorithm to handle this use case, the carrier config value restrict_5g_softap_wifi_direct_for_laa must be defined. If the cell channel is on LAA and restrict_5g_softap_wifi_direct_for_laa is true, the algorithm returns the set of unsafe channels with the entire 5 Ghz band and sets the mandatory restriction flags for SoftAP and Wi-Fi Direct (P2P).

Inform Wi-Fi service

After the coex channel algorithm has calculated the unsafe channels, to provide your system apps with the unsafe channels and their restrictions, use the following @SystemApi data structure defined in the Android framework.

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();
}

Use the following WifiManager @SystemApi methods and callback to enable the apps to get updated values when the unsafe channels change.

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);
}

Perform Wi-Fi action

When the Wi-Fi service receives information about the set of unsafe channels, it performs the appropriate action to ensure that those channels are avoided. This section describes the behavior of the Wi-Fi service in different scenarios.

Inform the driver

Because the driver has a major role in performing channel avoidance, it's essential to convey the unsafe channels to the driver and firmware. To do this, use the following IWifiChip HAL API.

For AIDL:

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

For HIDL (1.5 or higher):

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

SoftAP

SoftAP is the main use case for unsafe channel avoidance. The following section outlines the key SoftAp scenarios where channel avoidance can be applied with ACS. The scenarios describe the behavior of the channel avoidance algorithm and the driver or firmware.

Start SoftAP with ACS enabled (no SoftAP is up yet)

  1. If channels are unsafe and there is a SoftAP restriction

    1. The framework removes unsafe channels from the ACS list.
    2. If the list is empty, the framework stops SoftAP.

  2. If channels are unsafe and there are no restrictions

    1. The vendor driver or firmware gives priority to the safe channels over the unsafe channels.

SoftAP is up with ACS enabled and unsafe channels are updated

  1. If the SoftAP channel is unsafe and there's a SoftAP restriction

    1. The framework updates the ACS list by removing the unsafe channels.
    2. If the list is empty, the framework closes SoftAP.

  2. If the SoftAP channel is unsafe and there are no restrictions

    1. No action is taken by the framework. The vendor driver or firmware handles avoiding the unsafe channels or applying the power cap if avoidance isn't feasible.

Wi-Fi Direct (P2P)

  1. If there are unsafe channels with Wi-Fi Direct (P2P) restrictions.

    1. The framework requests wpa_supplicant to avoid the unsafe channels using the HAL method ISupplicantP2pIface::setDisallowedFrequencies().

  2. If there are unsafe channels without restrictions.

    1. The vendor driver or firmware applies the power cap if an unsafe channel without Wi-Fi Direct (P2P) restriction is used.

Wi-Fi Aware (NAN)

The framework isn't involved in channel selection for Wi-Fi Aware (NAN) and no framework action is taken. The vendor driver or firmware is responsible for Wi-Fi Aware (NAN) channel avoidance.

Disable the algorithm

If you want to disable the default algorithm implementation and pass your own list of unsafe channels for avoidance, configure the overlay config_wifiDefaultCoexAlgorithmEnabled. If the overlay is set to false, the default algorithm is disabled. You can then use your own out-of-band proprietary algorithm to generate a list of unsafe channels to plumb to the framework using the following system API.

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

Validate the implementation

To validate your implementation of the Wi-Fi/cellular coex channel avoidance feature, use the following tests.

CTS tests

  • WifiManagerTest.java

    • testCoexMethodsShouldFailNoPermission()
    • testListenOnCoexUnsafeChannels()

ACTS tests

  • WifiManagerTest.py

    • test_set_get_coex_unsafe_channels()

VTS tests

  • If AIDL is implemented: wifi_chip_aidl_test.cpp

    • TEST_P(WifiChipAidlTest, SetCoexUnsafeChannels)

  • If HIDL is implemented: wifi_chip_hidl_test.cpp

    • TEST_P(WifiChipHidlTest, setCoexUnsafeChannels)