Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Evitar canal Wi-Fi/Celular Coex

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

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

Esta página trata sobre lo siguiente:

  • Información que el módem celular debe reportar al marco de 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 de HAL relacionadas con la función de evitación de canales
  • Comportamiento del marco para manejar la evasión de canales
  • Comportamiento del proveedor de chips para manejar la evasión de canales
  • Detalles de implementación para la evitación de 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 celular y Wi-Fi están dentro de 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, afectando su calidad de recepción.

Este documento se refiere al transmisor que interfiere 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 evasión de canales coex de Wi-Fi/celular proporciona un enfoque coherente para evitar canales que reduce la necesidad de un código propietario que diverge del marco de Wi-Fi. Además, la función permite a los fabricantes de dispositivos configurar, habilitar y deshabilitar y anular la función.

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

  1. Módem informa cambio en la frecuencia celular
  2. Algoritmo de evasión 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

Esquema de evitación de canales

Figura 1. Esquema de evitación de canales

Reportar 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 IRadio::PhysicalChannelConfig . Esta información incluye indicaciones para el acceso asistido con licencia (LAA) y la agregación de portadores (CA).

A partir de Android 12, los siguientes campos en 1.6 IRadio::PhysicalChannelConfig brindan la información requerida para las fórmulas coex 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álculo de 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 celular y Wi-Fi y determina qué conjunto de canales Wi-Fi no son seguros.

Existen múltiples tipos de interferencia que requieren diferentes fórmulas: vecinos y armónicos/intermodulación . Debido a las diferencias físicas en la antena y el diseño entre los dispositivos, los patrones de interferencia vecina y armónica/intermodulación para cada dispositivo son diferentes. Para dar cuenta de 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 máximo de potencia en la tabla de búsqueda. 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 límite de potencia, el canal transmite a máxima potencia.

En general, la función de evasión de canales utiliza un enfoque de mejor esfuerzo para evitar canales de Wi-Fi inseguros para 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 para 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 para evitarlos obligatoriamente.

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 celda de interferencia como la opción más segura. Estos canales predeterminados no se informan como canales inseguros cuando el resto de la banda se informa como no seguro.

Lista de reemplazo

Un enfoque basado en fórmulas está limitado en los casos en que la interferencia depende en gran medida del ancho de banda (y, por lo tanto, los canales con un ancho de banda mayor pueden no ser seguros, pero no los canales con un ancho de banda menor). En casos, como con LAA, es beneficioso omitir los cálculos y usar 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 la tabla significa que se omite el cálculo para ese canal de celda en particular y que la lista de anulación especifica los canales Wi-Fi no seguros para el canal de celda coincidente.

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

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

2g categorías:

  • all (toda la banda de 2,4 GHz)

categorías 5g:

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

Interferencia de canal vecino

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

Interferencia de canal

Figura 2. Distancia entre 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 es la mayoría de las veces).

Parámetros de interferencia vecina

  • wifiVictimMhz : Umbral de distancia en MHz para una víctima Wi-Fi (enlace ascendente celular)
  • 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 celular 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 de celda.
  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 de la celda.
      2. Encuentra el primer canal Wi-Fi de 20Mhz cuyo borde inferior se superpone al límite.
      3. Marca el canal Wi-Fi, cada canal de mayor ancho de banda que lo contenga (por ejemplo, 40 Mhz, 80 Mhz) y cada canal inferior de la misma banda que el 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 contenga (por ejemplo, 40Mhz, 80Mhz) y cada canal superior de la misma banda que el canal inseguro.
  4. Si cellVictimMhz está presente y el canal celular tiene enlace descendente.

    1. Realiza el paso 3 utilizando cellVictimMhz como umbral y compara con el enlace descendente de la celda en lugar del enlace 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 canal inseguro

Figura 3. Cálculo de canal inseguro para interferencia de canal vecino

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 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/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 de celda que se aprovecha de 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 la celda y un grado armónico $ N $.

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

Distorsión armónica de cálculo de canal inseguro

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 afecta al canal del 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 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 de cálculo de canal inseguro

Figura 5. Cálculo de canal inseguro para distorsión de intermodulación

Puede especificar $ M $, $ N $ y superponer valores en la tabla de búsqueda por banda de celda de interferencia. Si no hay interferencia para una banda, los valores se omiten de la tabla para la entrada de esa banda. Se pueden definir de forma independiente dos conjuntos de estos valores para las bandas Wi-Fi de 2,4 GHz y 5 GHz.

Similar al algoritmo de interferencia vecina, el algoritmo reutiliza el mismo valor de límite de potencia definido por banda de celda de interferencia.

El algoritmo se comporta de la siguiente manera para cada canal celular 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 de los armónicos si se definen los parámetros.

    1. Calcula 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. 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 supera 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 supera el umbral de superposición Wi-Fi de 2,4 GHz.
    7. Marca cada canal de 20 MHz intermedio como un canal inseguro.
  3. Encuentra los canales inseguros de 5 GHz de los armónicos si se definen los parámetros.

    1. Encuentra el grado armónico N para 5GHz. Si N es 0, salta al paso 5.
    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. Encuentra canales inseguros de 20Mhz.

      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 supera 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 supera el umbral de superposición Wi-Fi de 2,4 GHz.
      5. Marca cada canal de 20 MHz intermedio como un canal inseguro con el límite de potencia especificado.
    4. Encuentra canales inseguros de 40MHz, 80MHz, 160MHz

      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 hacen un canal de 40 Mhz y tienen una superposición del 30 % y el 90 %, entonces el promedio es una superposición del 60 %). para el canal de 40Mhz).
  4. Encuentra los canales inseguros de 2,4 GHz de la intermodulación si se definen los 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 intermodulación de baja frecuencia y la intermodulación de alta frecuencia 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 supera el umbral de superposición de la celda de 2,4 GHz.
  5. Encuentra los canales inseguros de 5 GHz de la intermodulación si se definen los 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 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, 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 todos los canales Wi-Fi de 2,4 GHz están marcados como canales no seguros, elimina 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 canales no seguros, elimina el canal Wi-Fi de 5 GHz predeterminado del conjunto.
  3. Devuelve el conjunto final de canales no seguros.

formato de tabla de consulta

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

Tabla XML de ejemplo

El siguiente es 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/descendente pueden no producir suficiente superposición para causar interferencia de forma independiente, pero pueden producir suficiente superposición cuando se combinan. El algoritmo considera cada rango de armónico/intermodulación de forma independiente y toma la unión de los canales inseguros devueltos. Para el caso de la 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 forma 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.

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 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 las banderas de restricción obligatorias para SoftAP y Wi-Fi Direct (P2P).

Servicio de información Wi-Fi

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

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

Realización de una acción Wi-Fi

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

Informar al conductor

Debido a que el controlador tiene un papel importante en la evitación de canales, es esencial transmitir los canales inseguros al controlador y al firmware. Para ello, utilice la API HAL 1.5::IWifiChip .

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 en los que se puede aplicar la evasión de canales con ACS. Los escenarios describen el comportamiento del algoritmo de evitación de canales y el controlador o firmware.

Inicio de SoftAP con ACS habilitado (todavía no hay ningún SoftAP activado)

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

    1. El marco elimina los canales no seguros de la lista de 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 se actualizan los canales inseguros

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

    1. El marco actualiza la lista de 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 realiza ninguna acción. El controlador/firmware del proveedor se encarga de evitar los canales inseguros o de aplicar el límite de energía si no es factible evitarlo.

Wi-Fi directo (P2P)

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

    1. El marco solicita wpa_supplicant para evitar los canales no seguros mediante 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 usa un canal inseguro sin restricción 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 toma ninguna acción del 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 no seguros para evitarlos, configure la superposición config_wifiDefaultCoexAlgorithmEnabled . Si la superposición se establece en falso, el algoritmo predeterminado está deshabilitado. Luego, puede usar su propio algoritmo patentado fuera de banda para generar una lista de canales inseguros para conectarse al marco usando la siguiente API del sistema.

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

Validación de la implementación

Para validar su implementación de la función de evitación de canal coex Wi-Fi/celular, use las siguientes pruebas.

Pruebas CTS

  • WifiManagerTest.java

    • testCoexMethodsShouldFailNoPermission()
    • testListenOnCoexUnsafeChannels()

Pruebas ACTS

  • WifiManagerTest.py

    • test_set_get_coex_unsafe_channels()

pruebas VTS

  • wifi_chip_hidl_test.cpp

    • TEST_P(WifiChipHidlTest, setCoexUnsafeChannels)