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 los que podría haber interferencia 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 analizan los siguientes temas:

  • 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 evasión de canales
  • Comportamiento del framework para controlar la elusión de canales
  • Comportamiento del proveedor de chips para evitar canales
  • Detalles de implementación para la evitación de canales
  • Pruebas para validar el comportamiento de evitación de canales

Información general

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 Wi-Fi y de telefonía celular tienen una separación de frecuencia corta (canales vecinos) o cuando hay interferencia armónica 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 interferencia 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 denomina canal inseguro.

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 se desvía del framework de Wi-Fi. Además, la función permite que los fabricantes de dispositivos la configuren, habiliten, inhabiliten y anulen.

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

  1. El módem informa un cambio en la frecuencia celular
  2. El algoritmo de elusión de Coex calcula los canales de Wi-Fi no seguros
  3. El algoritmo de elusió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 evitación de canales

Figura 1: Esquema de evitación de canales

Informa un cambio en la frecuencia celular

El servicio de telefonía informa los canales celulares que se están usando actualmente. Cuando cambia la frecuencia celular operativa, 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 requerida para las fórmulas de coexistencia que debe completar el módem.

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

Cómo calcular los canales de Wi-Fi no seguros

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

Existen varios tipos de interferencia que requieren diferentes fórmulas: vecina y armónica/intermodulación. Debido a las diferencias físicas en la antena y el diseño entre los dispositivos, los patrones de interferencia armónica o de intermodulación y de dispositivos vecinos son diferentes para cada dispositivo. Para tener en cuenta esto, los fabricantes de dispositivos deben proporcionar una tabla de búsqueda 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 se hace referencia a ellos en las bandas de los canales de celda activos.

Se puede definir un límite de potencia máximo en la tabla de búsqueda. Si se define un límite de potencia máximo, el canal no seguro transmite con el límite de potencia proporcionado. Si no hay un límite de potencia, el canal transmite a plena 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 ciertos casos (por ejemplo, debido a los requisitos de los operadores), es obligatorio que ciertas interfaces eviten 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 directo (P2P), SoftAp y Wi-Fi Aware (NAN). Si bien un canal no seguro actúa como una recomendación para no usar ese canal en todos los casos de uso, las restricciones obligatorias marcan casos de uso específicos para la evitación obligatoria.

Si todos los canales de la banda de 2.4 GHz o 5 GHz se marcan como no seguros, la tabla de búsqueda puede definir un canal predeterminado de 2.4 GHz o un canal predeterminado de 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 anulaciones

Un enfoque basado en fórmulas es limitado en los casos en los que la interferencia depende en gran medida del ancho de banda (y, por lo tanto, los canales con mayor ancho de banda podrían ser inseguros, pero no los canales con menor ancho de banda). En algunos casos, como con la LAA, es beneficioso omitir los cálculos y usar una lista especificada de canales no seguros.

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

En los casos en los que el ancho de banda es importante, puedes evitar selectivamente ciertos anchos de banda especificando ciertos canales con ciertos anchos de banda en la lista de anulaciones. Esto se debe a que cada número de canal Wi-Fi corresponde a un ancho de banda específico.

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

Categorías de 2G:

  • all (toda la banda de 2.4 GHz)

Categorías de 5G:

  • all (toda la banda de 5 GHz)
  • 20mhz (canales de 5 GHz y 20 MHz)
  • 40mhz (canales de 5 GHz y 40 MHz)
  • 80mhz (canales de 5 GHz y 80 MHz)
  • 160mhz (canales de 5 GHz y 160 MHz)

Interferencia de canales adyacentes

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

Interferencia del canal

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

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

Parámetros de interferencia adyacente

  • wifiVictimMhz: Umbral de distancia en MHz para una víctima de Wi-Fi (vínculo ascendente de la celda)
  • cellVictimMhz: Umbral de distancia en MHz para una celda víctima (enlace descendente 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 de la tabla de búsqueda. Si no se encuentra ninguna entrada de la tabla, se devuelve sin canales no seguros para ese canal celular.
  2. Según la banda celular, identifica qué banda de Wi-Fi está en riesgo y de qué lado de la banda proviene la interferencia (por ejemplo, canales inferiores de 2.4 GHz, canales superiores de 2.4 GHz, canales inferiores de 5 GHz).

  3. Si wifiVictimMhz está presente y el canal de celda tiene enlace ascendente y

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

      1. Encuentra el límite superior de los canales no seguros sumando wifiVictimMhz a la frecuencia más alta de la vinculación ascendente de la celda.
      2. Busca el primer canal de Wi-Fi de 20 MHz cuyo borde inferior se superponga con el límite.
      3. Marca el canal Wi-Fi, todos los canales de mayor ancho de banda que lo contienen (por ejemplo, 40 MHz, 80 MHz) y todos los canales inferiores de la misma banda que el canal no seguro.

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

      1. Encuentra el límite inferior de los canales no seguros restando wifiVictimMhz a la frecuencia más baja de la vinculación ascendente de la celda.
      2. Busca el primer canal de Wi-Fi cuyo borde superior se superpone con el límite.
      3. Marca el canal Wi-Fi, todos los canales más grandes que lo contienen (por ejemplo, 40 MHz, 80 MHz) y todos los canales superiores de la misma banda que el canal no seguro.

  4. Si cellVictimMhz está presente y el canal de la celda tiene enlace descendente.

    1. Realiza el paso 3 con cellVictimMhz como umbral y compara con la vinculación descendente de la celda en lugar de la vinculación ascendente de la celda.

  5. Aplica el límite de potencia 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 del canal adyacente

Distorsión armónica o de intermodulación

En el caso de 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, 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 vínculo ascendente de la celda que afecta a los canales de Wi-Fi. Luego, sustituye los valores de distorsión alta y distorsión baja por los valores armónicos según las frecuencias de vínculo ascendente de la celda 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 canales no seguros para la distorsión armónica

En el caso de intermodulación, el algoritmo considera la distorsión por intermodulación de la vinculación ascendente de la celda y el canal de Wi-Fi que victimiza el canal de vinculación descendente de la celda. Luego, sustituye la distorsión alta y la distorsión baja por los valores de intermodulación según las frecuencias de vínculo ascendente de la celda, las frecuencias de Wi-Fi y los dos coeficientes de intermodulación $ M$ y $N $.

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

Intermodulación de cálculo de canales no seguros

Figura 5: Cálculo de canales no seguros para la distorsión por intermodulación

Puedes especificar los valores de $ M $, $ N $ y superposición en la tabla de búsqueda 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.

De manera similar al algoritmo de interferencia vecina, el algoritmo reutiliza el mismo valor de límite de potencia definido por banda de celda interferente.

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

  1. Para la banda del canal celular, 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 de 2.4 GHz no seguros a partir de armónicos si se definen parámetros.

    1. Busca el grado armónico N para 2.4 GHz.
    2. Calcula la frecuencia armónica alta y la frecuencia armónica baja en función de N y la vinculación ascendente de la celda.
    3. Busca el primer canal de Wi-Fi de 20 MHz que se encuentre dentro del límite inferior de la armónica que proviene de abajo.
    4. Calcula la superposición de la armónica en 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 de Wi-Fi de 20 MHz que se encuentre dentro del límite superior de la armónica proveniente de arriba.
    6. Calcula la superposición de la armónica en 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. Busca los canales de 5 GHz no seguros a partir de armónicos si se definen parámetros.

    1. Busca el grado armónico N para 5 GHz. Si N es 0, se avanza al paso 5.
    2. Calcula la frecuencia armónica alta y la frecuencia armónica baja en función de N y la vinculación ascendente de la celda.

    3. Encuentra canales no seguros de 20 MHz.

      1. Busca el primer canal de Wi-Fi de 20 MHz que se encuentre dentro del límite inferior de la armónica que proviene de abajo.
      2. Calcula la superposición de la armónica 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 de Wi-Fi de 20 MHz que se encuentre dentro del límite superior de la armónica proveniente de arriba.
      4. Calcula la superposición de la armónica 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. Marca cada canal de 20 MHz intermedio como un canal no seguro con el límite de potencia especificado.

    4. Encuentra canales no seguros de 40 MHz, 80 MHz y 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 un 30% y un 90% de superposición, el promedio es un 60% de superposición para el canal de 40 MHz).

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

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

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

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

  5. Encuentra los canales de 5 GHz no seguros por intermodulación si se definen 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 por interferencia armónica y adyacente, se calcula el conjunto final tomando la unión de ambos conjuntos (y seleccionando el límite de potencia inferior 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 de Wi-Fi de 2.4 GHz están marcados como no seguros, se quita el canal de 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 quita 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 búsqueda se representan en un archivo XML ubicado en la cadena de configuración superponible 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 en XML

A continuación, se muestra un ejemplo de una tabla de búsqueda en 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 operadores (CA), es posible que los rangos de intermodulación o armónicos de cada vínculo ascendente o descendente no produzcan suficiente superposición para causar interferencia de forma independiente, pero sí podrían producir suficiente superposición cuando se combinan. 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 devuelven. 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 o SCELL, y los trata como iguales.

Acceso asistido por licencia

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

Según los requisitos del operador, el algoritmo de evitación de canales establece restricciones obligatorias en SoftAP y Wi-Fi Direct (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 devuelve 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 el servicio de Wi-Fi

Después de que el algoritmo de canales coex haya calculado los canales no seguros, para proporcionar 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 devolución de llamada de WifiManager @SystemApi 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);
}

Realiza una 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 de Wi-Fi en diferentes situaciones.

Informa al conductor

Dado que el conductor tiene un papel importante en la evitación de canales, es fundamental transmitir los canales no seguros al conductor y al firmware. Para ello, usa la siguiente API de HAL de 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 principal caso de uso para evitar canales no seguros. En la siguiente sección, se describen los principales casos de uso de SoftAP en los que se puede aplicar la evitación de canales con ACS. Las situaciones describen el comportamiento del algoritmo de evitación de canales y del controlador o firmware.

Inicia SoftAP con ACS habilitado (aún no se activó SoftAP)

  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 firmware del proveedor prioriza los canales seguros por sobre los inseguros.

SoftAP está en funcionamiento con ACS habilitado y se actualizaron 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 se encargan de evitar los canales no seguros o de aplicar el límite de potencia si no es posible evitarlo.

Wi-Fi Direct (P2P)

  1. Si hay canales no seguros con restricciones de Wi-Fi directo (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 firmware o el controlador del proveedor aplica el límite de potencia si se usa un canal no seguro sin restricción de Wi-Fi directo (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 del framework. El controlador o firmware del proveedor es responsable de evitar los canales de Wi-Fi Aware (NAN).

Inhabilita el algoritmo

Si quieres inhabilitar la implementación del algoritmo predeterminado y pasar tu propia lista de canales no seguros para evitarlos, 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 de Wi-Fi y datos móviles, usa las siguientes pruebas.

Pruebas de 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)