Evitar canal Wi-Fi/Celular Coex

La función para evitar canales de coex de Wi-Fi/celular, introducida en Android 12, identifica y evita el uso de canales Wi-Fi inseguros en los casos en que pueda haber interferencias desde/hacia canales celulares. Esto incluye interfaces como STA, SoftAp, Wi-Fi Direct (P2P), Wi-Fi Aware (NAN).

Esta página analiza lo siguiente:

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

Fondo

Para 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 celulares y Wi-Fi están dentro de una separación de frecuencia corta (canales vecinos) o cuando hay interferencias armónicas y de intermodulación.

Este tipo de interferencia se convierte en un problema cuando una antena está transmitiendo y otra recibiendo al mismo tiempo. En este caso, la antena transmisora ​​inunda la antena receptora, afectando su calidad de recepción.

Este documento se refiere al transmisor que interfiere como el agresor y al receptor que sufre la interferencia como la víctima . Se denomina canal inseguro al canal Wi-Fi que es el agresor o la víctima.

La función de evitación de canales Wi-Fi/coex celular proporciona un enfoque consistente para evitar canales, reduciendo la necesidad de código propietario que diverge del marco de Wi-Fi. Además, la función permite a los fabricantes de dispositivos configurar, habilitar, deshabilitar y anular la función.

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

1. Módem informa cambio en la frecuencia celular
2. El algoritmo de evitación de Coex calcula canales Wi-Fi inseguros
3. El algoritmo de evitación de Coex informa al servicio Wi-Fi
4. El marco o el controlador realiza la acción Wi-Fi adecuada

Figura 1. Esquema para evitar canales

Informar un cambio en la frecuencia celular

El servicio de telefonía informa los canales celulares actualmente en uso. 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 coex que el módem debe completar.

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

Calcular canales Wi-Fi inseguros

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

Existen múltiples tipos de interferencias que requieren diferentes fórmulas: vecinas y armónicas/intermodulación . Debido a las diferencias físicas en la antena y el diseño entre dispositivos, los patrones de interferencia vecina y armónica/intermodulación para cada dispositivo son diferentes. Para tener en cuenta esto, los fabricantes de dispositivos deben proporcionar una tabla de búsqueda para conectar los parámetros en fórmulas genéricas para los dos tipos de interferencia. Estos parámetros se definen por banda de celda y están referenciados por las bandas de los canales de celda activos.

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

En general, la función para evitar canales utiliza un enfoque de mejor esfuerzo para evitar canales Wi-Fi inseguros y optimizar el rendimiento. Pero en ciertos casos (por ejemplo, debido a los requisitos del operador), es obligatorio que ciertas interfaces eviten canales inseguros para ciertas bandas celulares. En tales casos, las restricciones obligatorias se representan como una máscara de bits que contiene valores que indican si se deben prohibir ciertos canales, como Wi-Fi Direct (P2P), SoftAp y Wi-Fi Aware (NAN). Si bien un canal inseguro actúa como una recomendación contra el uso de ese canal para todos los casos de uso, las restricciones obligatorias marcan casos de uso específicos que deben evitarse de forma obligatoria.

Si todos los canales de la banda de 2,4 GHz o 5 GHz están marcados 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 celdas perturbadoras como la opción más segura. Estos canales predeterminados no se informan como canales inseguros cuando el resto de la banda sí se informa como inseguro.

Lista de anulación

Un enfoque formulado es limitado en los casos en que la interferencia depende en gran medida del ancho de banda (y, por lo tanto, los canales con mayor ancho de banda pueden ser inseguros, pero no los canales con menor ancho de banda). En casos como el de LAA, es beneficioso omitir los cálculos y utilizar una lista específica de canales inseguros.

Para hacer esto, puede especificar una lista de anulación de canales no seguros en la tabla de búsqueda para ciertas entradas. Una lista de anulación en una entrada de tabla significa que el cálculo para ese canal celular en particular se omite y que la lista de anulación especifica los canales Wi-Fi inseguros para el canal celular coincidente.

Para casos sensibles al ancho de banda, puede evitar selectivamente 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 específico.

La lista de anulación está representada por una lista de números de canales o palabras clave de categorías predefinidas para cada banda Wi-Fi:

categorías 2g:

• all (banda completa de 2,4 GHz)

Categorías 5g:

• all (banda completa 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 del canal vecino

Para determinar la interferencia del canal vecino, el algoritmo de evitación de coex se asegura de que la distancia ΔF entre un canal agresor y víctima no baje de un umbral específico.

Figura 2. Distancia entre un canal agresor y víctima

El umbral está determinado por la configuración física del dispositivo y el valor de umbral proporcionado en la entrada de la tabla de búsqueda por banda de interferencia. Las bandas que se consideran que no interfieren no tienen una entrada en la tabla y no es necesario calcular los canales inseguros (esto ocurre la mayoría de las veces).

Parámetros de interferencia vecinos

• wifiVictimMhz : Umbral de distancia en MHz para una víctima de Wi-Fi (enlace ascendente de celda)
• cellVictimMhz : Umbral de distancia en MHz para una célula víctima (enlace descendente de célula)

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 búsqueda. Si no se encuentra ninguna entrada en la tabla, regresa sin canales inseguros para ese canal celular.
2. Según la banda celular, identifica qué banda 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 celular tiene enlace ascendente y

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

      1. Encuentra el límite superior de canales inseguros agregando wifiVictimMhz a la frecuencia más alta del enlace ascendente del celular.
      2. Encuentra el primer canal Wi-Fi de 20 Mhz cuyo borde inferior se superpone al límite.
      3. Marca el canal Wi-Fi, cada canal de ancho de banda mayor que lo contiene (por ejemplo, 40 Mhz, 80 Mhz) y cada canal inferior de la misma banda como canal inseguro.

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

      1. Encuentra el límite inferior de canales inseguros restando wifiVictimMhz a la frecuencia más baja del enlace ascendente de la celda.
      2. Encuentra el primer canal Wi-Fi cuyo borde superior se superpone al límite.
      3. Marca el canal Wi-Fi, cada canal más grande que lo contiene (por ejemplo, 40M hz, 80 Mhz) y cada canal superior de la misma banda como canal inseguro.

4. Si cellVictimMhz está presente y el canal celular tiene enlace descendente.

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

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

Figura 3. Cálculo de canales inseguros para interferencias de canales vecinos

Distorsión armónica/intermodulación

Para la distorsión armónica/intermodulación, el motor coex calcula el rango de la señal armónica/intermodulación y evalúa el porcentaje de superposición que tiene con un canal víctima potencial. Si la superposición excede 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/intermodulación en un canal víctima se realiza con la siguiente ecuación:

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

Figura 4. Cálculo de canales inseguros para distorsión armónica

En el caso de la intermodulación, el algoritmo considera la distorsión de intermodulación del enlace ascendente de la celda y el canal Wi-Fi que victimiza 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 basados ​​en las frecuencias de enlace ascendente de la celda, las frecuencias de Wi-Fi y los dos coeficientes de intermodulación $ M $, $ N $.

Figura 5. Cálculo de canales inseguros para distorsión de intermodulación

Puede especificar $ M $, $ N $ y valores superpuestos en la tabla de búsqueda por banda de celdas que interfieren. Si no hay interferencia en 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 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 células interferentes.

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 en la tabla de búsqueda. Si no se encuentra ninguna entrada en la tabla, regresa sin canales inseguros para este canal.

2. Encuentra los canales inseguros de 2,4 GHz debido a los armónicos si se definen parámetros.

   1. Encuentra el grado armónico N para 2,4 GHz.
   2. Calcula la frecuencia armónica alta y la frecuencia baja armónica en función de N y el enlace ascendente de la celda.
   3. Encuentra el primer canal Wi-Fi de 20 MHz que se encuentra dentro del límite inferior del armónico que viene desde abajo.
   4. Calcula la superposición del armónico sobre el canal Wi-Fi y marca el canal como inseguro si la superposición excede el umbral de superposición Wi-Fi de 2,4 GHz.
   5. Encuentra el primer canal Wi-Fi de 20 MHz que se encuentra dentro del límite superior del armónico que viene desde arriba.
   6. Calcula la superposición del armónico sobre el canal Wi-Fi y marca el canal como inseguro si la superposición excede el umbral de superposición Wi-Fi de 2,4 GHz.
   7. Marca cada canal de 20 MHz intermedio como canal inseguro.

3. Encuentra los canales inseguros de 5 GHz por armónicos si se definen parámetros.

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

   3. Encuentra canales inseguros de 20 Mhz.

      1. Encuentra el primer canal Wi-Fi de 20 MHz que se encuentra dentro del límite inferior del armónico que viene desde abajo.
      2. Calcula la superposición del armónico sobre el canal Wi-Fi y marca el canal como inseguro si la superposición excede el umbral de superposición Wi-Fi de 2,4 GHz.
      3. Encuentra el primer canal Wi-Fi de 20 MHz que se encuentra dentro del límite superior del armónico que viene desde arriba.
      4. Calcula la superposición del armónico sobre el canal Wi-Fi y marca el canal como inseguro si la superposición excede el umbral de superposición Wi-Fi de 2,4 GHz.
      5. Marca cada canal de 20 MHz intermedio como canal inseguro con el límite de alimentación especificado.

   4. Encuentra canales inseguros de 40 MHz, 80 MHz y 160 MHz

      1. Repite el paso 3a pero con 40 MHz, 80 MHz, 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, entonces el promedio es 60%). % de superposición para el canal de 40 Mhz).

4. Encuentra los canales inseguros de 2,4 GHz a partir de la intermodulación si se definen parámetros.

   1. Encuentra los coeficientes de intermodulación N, M para 2,4 GHz.

   2. Para cada canal Wi-Fi de 2,4 GHz:

      1. Calcula la baja frecuencia de intermodulación y la alta frecuencia de intermodulación en función de N, M, enlace ascendente de celda y canal Wi-Fi.
      2. Calcula la superposición de la intermodulación sobre el enlace descendente de la celda y marca el canal como inseguro si la superposición excede el umbral de superposición de celda de 2,4 GHz.

5. Encuentra los canales inseguros de 5 GHz a partir de la intermodulación si se definen parámetros.

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

6. Aplica el límite de energía de la entrada de la tabla a los canales inseguros calculados.

Resultado final

Después de calcular ambos conjuntos de canales inseguros debido a interferencias vecinas y armónicas, el conjunto final se calcula tomando la unión de ambos conjuntos (y seleccionando el límite de potencia más bajo si hay colisiones) y eliminando los canales predeterminados del conjunto si hay no se aplican restricciones obligatorias.

El algoritmo se comporta de la siguiente manera:

1. Si cada canal Wi-Fi de 2,4 GHz está marcado como canal no seguro, elimina el canal Wi-Fi predeterminado de 2,4 GHz del conjunto.
2. Si cada canal Wi-Fi de 5 GHz está marcado como canal no seguro, elimina el canal Wi-Fi de 5 GHz predeterminado del conjunto.
3. Devuelve el conjunto final de canales inseguros.

Formato de tabla de búsqueda

Las tablas de búsqueda se representan en un archivo XML ubicado en la cadena de configuración superpuesta config_wifiCoexTableFilepath y se definen mediante 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 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

Para la agregación de portadoras (CA), los rangos de armónicos/intermodulación para cada enlace ascendente/enlace descendente podrían no producir suficiente superposición como para causar interferencia de forma independiente, pero podrían producir suficiente superposición cuando se combinen. El algoritmo considera cada rango de armónicos/intermodulación de forma independiente y toma la unión de los canales inseguros devueltos. Para el caso de intermodulación, esto significa evaluar el rango de intermodulación de cada UL en cada DL.

El algoritmo no hace distinción entre PCELL/PSCELL/SCELL y los trata como iguales.

Acceso asistido por licencia

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

Dependiendo de los requisitos del operador, el algoritmo para evitar canales establece restricciones obligatorias en SoftAP y Wi-Fi Direct (P2P) para toda la banda Wi-Fi de 5 GHz. Para que el algoritmo maneje este caso de uso, se debe definir el valor de configuración del operador restrict_5g_softap_wifi_direct_for_laa . Si el canal celular está en LAA y restrict_5g_softap_wifi_direct_for_laa es true , el algoritmo devuelve el conjunto de canales inseguros con toda la banda de 5 Ghz y establece los indicadores de restricción obligatorios para SoftAP y Wi-Fi Direct (P2P).

Informar al servicio Wi-Fi

Después de que el algoritmo del canal coex haya calculado los canales inseguros, para proporcionar a las aplicaciones de su sistema los canales inseguros y sus restricciones, utilice la siguiente estructura de datos @SystemApi definida en el marco 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();
}

Utilice los siguientes métodos WifiManager @SystemApi y devolución de llamada para permitir que las aplicaciones obtengan valores actualizados cuando cambien los canales inseguros.

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 una acción Wi-Fi

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

informar al conductor

Debido a que el controlador desempeña un papel importante a la hora de evitar canales, es esencial transmitir los canales inseguros al controlador y al firmware. Para hacer esto, use la siguiente API IWifiChip HAL.

Para AIDL:

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

Para HIDL (1.5 o superior):

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

SoftAP

SoftAP es el principal caso de uso para evitar canales inseguros. La siguiente sección describe los escenarios clave de SoftAp donde se puede aplicar la evitación de canales con ACS. Los escenarios describen el comportamiento del algoritmo de evitación de canales y el controlador o firmware.

Iniciando SoftAP con ACS habilitado (aún no hay ningún SoftAP activo)

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

   1. El marco elimina los canales inseguros de la lista ACS.
   2. Si la lista está vacía, el marco detiene SoftAP.

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

   1. El controlador/firmware del proveedor da prioridad a los canales seguros sobre los canales inseguros.

SoftAP está activo con ACS habilitado y los canales inseguros están actualizados

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

   1. El marco actualiza la lista ACS eliminando los canales inseguros.
   2. Si la lista está vacía, el marco cierra SoftAP.

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

   1. El marco no toma ninguna medida. El controlador/firmware del proveedor se encarga de evitar los canales inseguros o de aplicar el límite de energía si evitarlo no es posible.

Wi-Fi directo (P2P)

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

   1. El marco solicita wpa_supplicant que evite los canales inseguros utilizando el método HAL ISupplicantP2pIface::setDisallowedFrequencies() .

2. Si hay canales inseguros sin restricciones.

   1. El controlador/firmware del proveedor aplica el límite de energía si se utiliza un canal inseguro sin restricción de Wi-Fi Direct (P2P).

Compatible con Wi-Fi (NAN)

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

Deshabilitar el algoritmo

Si desea deshabilitar la implementación del algoritmo predeterminado y pasar su propia lista de canales inseguros para evitarlos, configure la superposición config_wifiDefaultCoexAlgorithmEnabled . Si la superposición se establece en falso, el algoritmo predeterminado está deshabilitado. Luego puede utilizar su propio algoritmo propietario fuera de banda para generar una lista de canales inseguros para conectarse al marco utilizando la siguiente API del sistema.

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

Validando la implementación

Para validar su implementación de la función de evitación de canales Coex Wi-Fi/celular, utilice las siguientes pruebas.

pruebas CTS

• WifiManagerTest.java

  • testCoexMethodsShouldFailNoPermission()
  • testListenOnCoexUnsafeChannels()

pruebas ACTAS

• WifiManagerTest.py

  • test_set_get_coex_unsafe_channels()

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