Elusión de canales coex de Wi-Fi/datos móviles

La función de elusión de canales coex de Wi-Fi/datos móviles, que se introdujo en Android 12, identifica y evita el uso de canales de Wi-Fi no seguros en los casos en que pueda haber interferencias de los canales de datos móviles o hacia ellos. Esto incluye interfaces como STA, SoftAp, Wi-Fi Direct (P2P) y Wi-Fi Aware (NAN).

En esta página, se analiza lo siguiente:

  • Información que el módem celular debe informar al framework de Android
  • Algoritmos que usa el framework de Wi-Fi para calcular los canales de Wi-Fi que se deben evitar
  • Tablas de configuración que los fabricantes de dispositivos deben proporcionar para el framework de Wi-Fi
  • APIs del sistema, configuraciones y APIs de HAL relacionadas con la función de evitación de canales
  • Comportamiento del framework para controlar la elusión de canales
  • Comportamiento del proveedor de chips para controlar la evitación de canales
  • Detalles de la implementación para evitar canales
  • Pruebas para validar el comportamiento de evasión de canales

Segundo plano

En el caso de los dispositivos con tecnologías celulares, como LTE, 5G NR y acceso asistido con licencia (LAA), los canales celulares en uso pueden interferir con el canal Wi-Fi en uso. Esto ocurre cuando los canales de telefonía celular y Wi-Fi están dentro de una separación de frecuencia corta (canales adyacentes) o cuando hay interferencias armónicas y de intermodulación.

Este tipo de interferencia se convierte en un problema cuando una antena transmite y otra recibe al mismo tiempo. En este caso, la antena transmisora inunda la antena receptora, lo que afecta su calidad de recepción.

En este documento, se hace referencia al transmisor que genera interferencias como el agresor y al receptor que experimenta la interferencia como la víctima. El canal Wi-Fi que es el agresor o la víctima se conoce como un canal no seguro.

La función de elusión de canales coex de Wi-Fi/datos móviles proporciona un enfoque coherente para la elusión de canales, lo que reduce la necesidad de código propietario que diverge del framework de Wi-Fi. Además, la función permite a los fabricantes de dispositivos configurar, habilitar, inhabilitar y anular la función.

La función realiza la elusión de canales controlando los canales Wi-Fi. El esquema de evitación de canales Wi-Fi se puede describir como una serie de cuatro pasos abstractos:

  1. Los informes del módem cambian en la frecuencia de la red móvil
  2. El algoritmo de evitación de coex calcula los canales de Wi-Fi no seguros
  3. El algoritmo de evitación de coex informa al servicio de Wi-Fi
  4. El framework o el controlador realizan la acción de Wi-Fi adecuada.

Esquema de evasión de canales

Figura 1: Esquema de evitación de canales

Cómo informar un cambio en la frecuencia de la red móvil

El servicio de telefonía informa los canales celulares que se están usando actualmente. Cuando cambia la frecuencia celular de funcionamiento, el módem informa esta información al servicio de telefonía a través de IRadio::PhysicalChannelConfig. Esta información incluye indicaciones para el acceso asistido con licencia (LAA) y la agregación de operadores (CA).

A partir de Android 12, los siguientes campos en 1.6 IRadio::PhysicalChannelConfig proporcionan la información necesaria para las fórmulas de coexistencia que el módem debe propagar.

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

Calcula los canales de Wi-Fi no seguros

Cuando el módem informa un cambio en la frecuencia de los datos móviles, el algoritmo de canal de coexistencia calcula la interferencia entre los canales de datos móviles y Wi-Fi, y determina qué conjunto de canales de Wi-Fi no son seguros.

Existen varios tipos de interferencia que requieren fórmulas diferentes: interferência de canales adyacentes y intermodulación o interferencia armónica. Debido a las diferencias físicas en la antena y el diseño entre los dispositivos, los patrones de interferencia vecina y de intermodulación y armónica son diferentes para cada dispositivo. Para tener en cuenta esto, los fabricantes de dispositivos deben proporcionar una tabla de consulta para conectar parámetros en fórmulas genéricas para los dos tipos de interferencia. Estos parámetros se definen por banda de celda y las bandas de los canales de celda activos hacen referencia a ellos.

Se puede definir un límite de potencia máxima en la tabla de consulta. Si se define un límite máximo de potencia, un canal no seguro transmite con el límite de potencia proporcionado. Si no hay un límite de potencia, el canal transmite a máxima potencia.

En general, la función de evitación de canales usa un enfoque de mejor esfuerzo para evitar canales Wi-Fi no seguros y optimizar el rendimiento. Sin embargo, en algunos casos (por ejemplo, debido a los requisitos del operador), es obligatorio que ciertas interfaces eviten los canales no seguros para ciertas bandas celulares. En esos casos, las restricciones obligatorias se representan como una máscara de bits que contiene valores para prohibir ciertos canales, como Wi-Fi Direct (P2P), SoftAp y Wi-Fi Aware (NAN). Si bien un canal no seguro actúa como una recomendación para no usarlo en todos los casos de uso, las restricciones obligatorias marcan casos de uso específicos para evitarlos de manera obligatoria.

Si todos los canales de la banda de 2.4 GHz o 5 GHz están marcados como no seguros, la tabla de consulta puede definir un canal predeterminado de 2.4 GHz o 5 GHz por banda de celda interferente como la opción más segura. Estos canales predeterminados no se informan como canales no seguros cuando el resto de la banda se informa como no seguro.

Lista de excepciones

Un enfoque formulaico es limitado en los casos en que la interferencia depende en gran medida del ancho de banda (por lo que los canales con un ancho de banda más grande pueden no ser seguros, pero sí los canales con un ancho de banda más pequeño). En casos, como con LAA, es beneficioso omitir los cálculos y usar una lista especificada de canales no seguros.

Para ello, puedes especificar una lista de anulación de canales no seguros en la tabla de consulta para ciertas entradas. Una lista de anulación en una entrada de tabla significa que se omite el cálculo de ese canal de celda en particular y que la lista de anulación especifica los canales de Wi-Fi no seguros para el canal de celda coincidente.

En el caso de los casos sensibles al ancho de banda, puedes evitar de forma selectiva ciertos anchos de banda especificando ciertos canales con ciertos anchos de banda en la lista de anulación. Esto se debe a que cada número de canal Wi-Fi corresponde a un ancho de banda especificado.

La lista de anulación se representa con una lista de números de canal o palabras clave de categorías predefinidas para cada banda Wi-Fi:

Categorías de 2g:

  • all (banda completa de 2.4 GHz)

Categorías de 5g:

  • all (banda completa de 5 GHz)
  • 20mhz (canales de 20 MHz de 5 GHz)
  • 40mhz (canales de 40 MHz de 5 GHz)
  • 80mhz (canales de 80 MHz de 5 GHz)
  • 160mhz (canales de 160 MHz de 5 GHz)

Interferencia de canales adyacentes

Para determinar la interferencia de canales vecinos, el algoritmo de evitación de coex asegura que la distancia ΔF entre un canal agresor y uno víctima no sea inferior a un umbral especificado.

Interferencia de canales

Figura 2: Distancia entre el canal de un agresor y el de la víctima

El umbral se determina según la configuración física del dispositivo y el valor del umbral proporcionado en la entrada de la tabla de búsqueda por banda interferente. Las bandas que se consideran no interferentes no tienen una entrada de tabla, y no es necesario calcular los canales no seguros (la mayoría de las veces).

Parámetros de interferencia vecina

  • wifiVictimMhz: Umbral de distancia de MHz para una víctima de Wi-Fi (vínculo de subida de telefonía celular)
  • cellVictimMhz: Umbral de distancia de MHz para la víctima de una celda (vínculo de bajada de la celda)

El algoritmo se comporta de la siguiente manera para cada canal de celda activo:

  1. Para la banda del canal, intenta encontrar una entrada en la tabla de consulta. Si no se encuentra ninguna entrada de la tabla, no se muestran canales no seguros para ese canal de celda.
  2. En función de la banda celular, identifica qué banda Wi-Fi está en riesgo y de qué lado de la banda proviene la interferencia (por ejemplo, canales de 2.4 GHz más bajos, canales de 2.4 GHz más altos, canales de 5 GHz más bajos).

  3. Si wifiVictimMhz está presente y el canal de celda tiene un vínculo ascendente y

    1. Si la parte inferior de la banda Wi-Fi está en riesgo

      1. Para encontrar el límite superior de los canales no seguros, agrega wifiVictimMhz a la frecuencia más alta de la conexión ascendente celular.
      2. Busca el primer canal de Wi-Fi de 20 MHz cuyo borde inferior se superpone con el límite.
      3. Marca el canal Wi-Fi, cada canal de ancho de banda más alto que lo contiene (por ejemplo, 40 MHz, 80 MHz) y cada canal inferior de la misma banda como el canal no seguro.

    2. Si la parte superior de la banda Wi-Fi está en riesgo

      1. Para encontrar el límite inferior de los canales no seguros, se resta wifiVictimMhz a la frecuencia más baja de la conexión ascendente celular.
      2. Busca el primer canal de Wi-Fi cuyo borde superior se superpone con el límite.
      3. Marca el canal Wi-Fi, cada canal más grande que lo contenga (por ejemplo, 40 MHz, 80 MHz) y cada canal más alto de la misma banda como el canal no seguro.

  4. Si cellVictimMhz está presente y el canal de la celda tiene un vínculo de bajada.

    1. Realiza el paso 3 con cellVictimMhz como umbral y lo compara con el vínculo descendente de la celda en lugar del vínculo ascendente de la celda.

  5. Aplica el límite de energía de la entrada de la tabla a los canales no seguros calculados.

Cálculo de canales no seguros

Figura 3: Cálculo de canal no seguro para la interferencia de canales vecinos

Distorsión armónica o de intermodulación

Para la distorsión armónica o de intermodulación, el motor de coexistencia calcula el rango de la señal armónica o de intermodulación y evalúa el porcentaje de superposición que tiene con un posible canal víctima. Si la superposición supera un umbral de superposición, el algoritmo considera que se trata de una situación insegura. El cálculo del porcentaje de superposición de la distorsión armónica o de intermodulación en un canal víctima se realiza con la siguiente ecuación:

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

En el caso de la distorsión armónica, el algoritmo considera la distorsión armónica de un canal de enlace ascendente celular que afecta a los canales Wi-Fi. Luego, sustituye la distorsión alta y la distorsión baja con los valores armónicos basados en las frecuencias de enlace ascendente de las celdas y un grado armónico $ N $.

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

Distorsión armónica del cálculo de canales no seguros

Figura 4: Cálculo de canal no seguro para distorsión armónica

En el caso de intermodulación, el algoritmo considera la distorsión de intermodulación del enlace ascendente de la celda y el canal Wi-Fi que acosa el canal de enlace descendente de la celda. Luego, sustituye la distorsión alta y la distorsión baja con los valores de intermodulación en función de las frecuencias de enlace ascendente de la celda, las frecuencias de Wi-Fi y los dos coeficientes de intermodulación $ M $, $ N $.

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

Distorsión de intermodulación del cálculo de canales no seguros

Figura 5: Cálculo de canal no seguro para la distorsión de intermodulación

Puedes especificar $ M $, $ N $ y los valores de superposición en la tabla de consulta por banda de celda interferente. Si no hay interferencia para una banda, los valores se omiten de la tabla para esa entrada de banda. Se pueden definir de forma independiente dos conjuntos de estos valores para las bandas de Wi-Fi de 2.4 GHz y 5 GHz.

Al igual que el algoritmo de interferencia vecina, el algoritmo reutiliza el valor de límite de potencia definido por cada banda de celda interferente.

El algoritmo se comporta de la siguiente manera para cada canal de celda activo:

  1. Para la banda del canal de la celda, intenta encontrar una entrada de la tabla de búsqueda. Si no se encuentra ninguna entrada de tabla, se muestra sin canales no seguros para este canal.

  2. Encuentra los canales no seguros de 2.4 GHz a partir de los armónicos si se definen los parámetros.

    1. Encuentra el grado armónico N para 2.4 GHz.
    2. Calcula la alta frecuencia armónica y la baja frecuencia armónica en función de N y el enlace ascendente de la celda.
    3. Busca el primer canal Wi-Fi de 20 MHz que esté dentro del límite inferior de la armónica que proviene de abajo.
    4. Calcula la superposición del armónico sobre el canal Wi-Fi y marca el canal como no seguro si la superposición supera el umbral de superposición de Wi-Fi de 2.4 GHz.
    5. Busca el primer canal Wi-Fi de 20 MHz que se encuentre dentro del límite superior de la armónica que proviene de arriba.
    6. Calcula la superposición del armónico sobre el canal Wi-Fi y marca el canal como no seguro si la superposición supera el umbral de superposición de Wi-Fi de 2.4 GHz.
    7. Marca cada canal de 20 MHz intermedio como un canal no seguro.

  3. Encuentra los canales no seguros de 5 GHz a partir de los armónicos si se definen los parámetros.

    1. Encuentra el grado armónico N para 5 GHz. Si N es 0, avanza al paso 5.
    2. Calcula la frecuencia alta armónica y la frecuencia baja armónica según N y la conexión ascendente de la celda.

    3. Encuentra canales no seguros de 20 MHz.

      1. Busca el primer canal Wi-Fi de 20 MHz que esté dentro del límite inferior de la armónica que proviene de abajo.
      2. Calcula la superposición del armónico sobre el canal Wi-Fi y marca el canal como no seguro si la superposición supera el umbral de superposición de Wi-Fi de 2.4 GHz.
      3. Busca el primer canal Wi-Fi de 20 MHz que esté dentro del límite superior del armónico que proviene de arriba.
      4. Calcula la superposición del armónico en el canal de Wi-Fi y marca el canal como no seguro si la superposición supera el umbral de superposición de Wi-Fi de 2.4 GHz.
      5. Marca cada canal de 20 MHz como canal no seguro con el límite de alimentación especificado.

    4. Detecta canales no seguros de 40 MHz, 80 MHz o 160 MHz

      1. Repite el paso 3a, pero con 40 MHz, 80 MHz y 160 MHz.
      2. En lugar de calcular las superposiciones de los canales en el borde armónico, reutiliza las superposiciones calculadas de los canales constituyentes más pequeños (por ejemplo, si dos canales de 20 MHz forman un canal de 40 MHz y tienen una superposición del 30% y del 90%, el promedio es una superposición del 60% para el canal de 40 MHz).

  4. Encuentra los canales de 2.4 GHz no seguros de la intermodulación si se definen los parámetros.

    1. Encuentra los coeficientes de intermodulación N y M para 2.4 GHz.

    2. Para cada canal Wi-Fi de 2.4 GHz:

      1. Calcula la frecuencia baja y la frecuencia alta de intermodulación en función de N, M, la conexión ascendente celular y el canal Wi-Fi.
      2. Calcula la superposición de la intermodulación sobre el vínculo descendente de la celda y marca el canal como no seguro si la superposición supera el umbral de superposición de celdas de 2.4 GHz.

  5. Encuentra los canales de 5 GHz no seguros de la intermodulación si se definen los parámetros.

    1. Repite el paso 4 con los canales Wi-Fi de 5 GHz y el umbral de superposición de celdas de 5 GHz.

  6. Aplica el límite de potencia de la entrada de la tabla a los canales no seguros calculados.

Resultado final

Después de calcular ambos conjuntos de canales no seguros de la interferencia armónica y vecina, se calcula el conjunto final tomando la unión de ambos conjuntos (y seleccionando la limitación de potencia más baja si hay colisiones) y quitando los canales predeterminados del conjunto si no se aplican restricciones obligatorias.

El algoritmo se comporta de la siguiente manera:

  1. Si todos los canales Wi-Fi de 2.4 GHz están marcados como no seguros, quita el canal Wi-Fi de 2.4 GHz predeterminado del conjunto.
  2. Si todos los canales Wi-Fi de 5 GHz están marcados como no seguros, se quitará el canal Wi-Fi de 5 GHz predeterminado del conjunto.
  3. Devuelve el conjunto final de canales no seguros.

Formato de la tabla de consulta

Las tablas de consulta se representan en un archivo en formato XML ubicado en la cadena de configuración superpuesta config_wifiCoexTableFilepath y se definen con el siguiente 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>

Ejemplo de tabla XML

A continuación, se muestra un ejemplo de una tabla de búsqueda 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>

Agregación de operadores

En el caso de la agregación de portadoras (CA), es posible que los rangos de intermodulación o armónicos de cada enlace ascendente o descendente no produzcan suficiente superposición para causar interferencia de forma independiente, pero sí lo hagan cuando se combinen. El algoritmo considera cada rango armónico o de intermodulación de forma independiente y toma la unión de los canales no seguros que se muestran. En el caso de la intermodulación, esto significa evaluar el rango de intermodulación de cada UL en cada DL.

El algoritmo no distingue entre PCELL, PSCELL ni SCELL, y los trata como iguales.

Acceso asistido por licencias

El acceso asistido por licencia (LAA) se identifica como la banda n° 46. El algoritmo trata esta banda de manera similar a otras. En este caso, los canales completos de 5 GHz se pueden configurar como una lista de anulación en la tabla de búsqueda.

Según los requisitos del operador, el algoritmo para evitar canales establece restricciones obligatorias en SoftAP y Wi-Fi directo (P2P) para toda la banda de Wi-Fi de 5 GHz. Para que el algoritmo controle este caso de uso, se debe definir el valor de configuración del operador restrict_5g_softap_wifi_direct_for_laa. Si el canal de la celda está en LAA y restrict_5g_softap_wifi_direct_for_laa es true, el algoritmo muestra el conjunto de canales no seguros con toda la banda de 5 GHz y establece las marcas de restricción obligatorias para SoftAP y Wi-Fi Direct (P2P).

Informa sobre el servicio de Wi-Fi

Una vez que el algoritmo del canal coex haya calculado los canales no seguros, para proporcionarles a las apps del sistema los canales no seguros y sus restricciones, usa la siguiente estructura de datos @SystemApi definida en el framework de Android.

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

Usa los siguientes métodos y devoluciones de llamada de @SystemApi de WifiManager para permitir que las apps obtengan valores actualizados cuando cambien los canales no seguros.

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

Realizar acción de Wi-Fi

Cuando el servicio de Wi-Fi recibe información sobre el conjunto de canales no seguros, realiza la acción adecuada para garantizar que se eviten esos canales. En esta sección, se describe el comportamiento del servicio Wi-Fi en diferentes situaciones.

Informa al conductor

Debido a que el controlador tiene un papel importante en la evasión de canales, es esencial transmitir los canales no seguros al controlador y al firmware. Para ello, usa la siguiente API de HAL IWifiChip.

Para AIDL:

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

Para HIDL (1.5 o versiones posteriores):

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

SoftAP

SoftAP es el caso de uso principal para evitar canales no seguros. En la siguiente sección, se describen las situaciones clave de SoftAp en las que se puede aplicar la evitación de canales con ACS. Las situaciones describen el comportamiento del algoritmo de evitación de canales y el controlador o firmware.

Inicia el SoftAP con ACS habilitado (aún no hay SoftAP activo)

  1. Si los canales no son seguros y hay una restricción de SoftAP

    1. El framework quita los canales no seguros de la lista de ACS.
    2. Si la lista está vacía, el framework detiene SoftAP.

  2. Si los canales no son seguros y no hay restricciones

    1. El controlador o el firmware del proveedor priorizan los canales seguros sobre los no seguros.

SoftAP está activado con ACS habilitado y se actualizan los canales no seguros.

  1. Si el canal de SoftAP no es seguro y hay una restricción de SoftAP

    1. El framework actualiza la lista de ACS quitando los canales no seguros.
    2. Si la lista está vacía, el framework cierra SoftAP.

  2. Si el canal de SoftAP no es seguro y no hay restricciones

    1. El framework no realiza ninguna acción. El controlador o el firmware del proveedor controlan la evitación de los canales no seguros o la aplicación del límite de energía si no es posible evitarlos.

Wi-Fi Direct (P2P)

  1. Si hay canales no seguros con restricciones de Wi-Fi Direct (P2P).

    1. El framework solicita wpa_supplicant para evitar los canales no seguros con el método HAL ISupplicantP2pIface::setDisallowedFrequencies().

  2. Si hay canales no seguros sin restricciones.

    1. El controlador o el firmware del proveedor aplican la limitación de energía si se usa un canal no seguro sin restricción de Wi-Fi Direct (P2P).

Reconocimiento de Wi-Fi (NAN)

El framework no participa en la selección de canales para Wi-Fi Aware (NAN) y no se realiza ninguna acción en el framework. El controlador o firmware del proveedor es responsable de evitar los canales de Wi-Fi Aware (NAN).

Inhabilita el algoritmo

Si deseas inhabilitar la implementación del algoritmo predeterminado y pasar tu propia lista de canales no seguros para evitarlo, configura la superposición config_wifiDefaultCoexAlgorithmEnabled. Si la superposición se establece como falsa, se inhabilita el algoritmo predeterminado. Luego, puedes usar tu propio algoritmo propietario fuera de banda para generar una lista de canales no seguros que se conectarán al framework con la siguiente API del sistema.

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

Valida la implementación

Para validar tu implementación de la función de evitación de canales de coexistencia Wi-Fi/celular, usa las siguientes pruebas.

Pruebas del CTS

  • WifiManagerTest.java

    • testCoexMethodsShouldFailNoPermission()
    • testListenOnCoexUnsafeChannels()

Pruebas de ACTS

  • WifiManagerTest.py

    • test_set_get_coex_unsafe_channels()

Pruebas de VTS

  • Si se implementa AIDL: wifi_chip_aidl_test.cpp

    • TEST_P(WifiChipAidlTest, SetCoexUnsafeChannels)

  • Si se implementa HIDL: wifi_chip_hidl_test.cpp

    • TEST_P(WifiChipHidlTest, setCoexUnsafeChannels)