Evitar a coexistência em canais Wi-Fi/celular

O recurso de evitar a coexistência de canais Wi-Fi/celular, introduzido no Android 12, identifica e evita o uso de canais Wi-Fi não seguros em casos em que pode haver interferência de ou para canais celulares. Isso inclui interfaces como STA, SoftAp, Wi-Fi Direct (P2P), Wi-Fi Aware (NAN).

Nesta página, abordamos o seguinte:

  • Informações que o modem celular precisa informar ao framework do Android
  • Algoritmos que o framework do Wi-Fi usa para calcular os canais de Wi-Fi que precisam ser evitados
  • Tabelas de configuração que os fabricantes de dispositivos precisam fornecer para o framework Wi-Fi
  • APIs do sistema, configurações e APIs HAL relacionadas ao recurso de evitação de canal
  • Comportamento do framework para lidar com a evasão de canais
  • Comportamento do fornecedor de chips para lidar com a evasão de canais
  • Detalhes de implementação para evitar canais
  • Testes para validar o comportamento de evitar o canal

Contexto

Para dispositivos com tecnologias celulares, como LTE, 5G NR e acesso assistido licenciado (LAA, na sigla em inglês), os canais celulares em uso podem interferir no canal Wi-Fi em uso. Isso ocorre quando os canais de celular e Wi-Fi estão dentro de uma separação de frequência curta (canais vizinhos) ou quando há interferência harmônica e de intermodulação.

Esse tipo de interferência se torna um problema quando uma antena está transmitindo e outra está recebendo ao mesmo tempo. Nesse caso, a antena transmissora inunda a antena receptora, afetando a qualidade da recepção.

Este documento se refere ao transmissor que causa a interferência como o agressor e ao receptor que sofre a interferência como a vítima. O canal Wi-Fi que é o agressor ou a vítima é chamado de canal não seguro.

O recurso de evitar o canal de coexistência Wi-Fi/celular oferece uma abordagem consistente para evitar o canal, reduzindo a necessidade de código proprietário que diverge do framework Wi-Fi. Além disso, o recurso permite que os fabricantes de dispositivos configurem, ativem, desativem e substituam o recurso.

O recurso evita o uso de canais controlando os canais Wi-Fi. O esquema de evitação de canal Wi-Fi pode ser descrito como uma série de quatro etapas abstratas:

  1. O modem informa uma mudança na frequência da rede celular
  2. O algoritmo de prevenção de coex calcula canais Wi-Fi não seguros
  3. O algoritmo de evitação de coexistência informa o serviço Wi-Fi
  4. O framework ou driver realiza a ação apropriada no Wi-Fi

Esquema de evitação de canais

Figura 1. Esquema de evitação de canais

Informar uma mudança na frequência da rede celular

O serviço de telefonia informa os canais de celular atualmente em uso. Quando a frequência celular operacional muda, o modem informa essas informações ao serviço de telefonia por meio de IRadio::PhysicalChannelConfig. Essas informações incluem indicações para acesso assistido licenciado (LAA, na sigla em inglês) e agregação de operadora (CA, na sigla em inglês).

No Android 12, os campos a seguir em 1.6 IRadio::PhysicalChannelConfig fornecem informações necessárias para as fórmulas de coex que o modem precisa preencher.

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 canais de Wi-Fi não seguros

Quando o modem informa uma mudança na frequência celular, o algoritmo do canal de coexistência calcula a interferência entre os canais celulares e Wi-Fi e determina quais conjuntos de canais Wi-Fi não são seguros.

Há vários tipos de interferência que exigem fórmulas diferentes: vizinhança e harmônica/intermodulação. Devido às diferenças físicas na antena e no layout entre os dispositivos, os padrões de interferência harmônica/intermodulação e de vizinhos são diferentes para cada dispositivo. Por isso, os fabricantes de dispositivos precisam fornecer uma tabela de consulta para conectar os parâmetros a fórmulas genéricas dos dois tipos de interferência. Esses parâmetros são definidos por faixa de célula e são referenciados pelas faixas dos canais de célula ativos.

Um limite máximo de energia pode ser definido na tabela de pesquisa. Se um limite máximo de energia for definido, um canal não seguro vai transmitir com o limite de energia fornecido. Se não houver um limite de energia, o canal vai transmitir com potência total.

Em geral, o recurso de evitação de canal usa uma abordagem de esforço máximo para evitar canais Wi-Fi não seguros e otimizar o desempenho. No entanto, em alguns casos (por exemplo, devido a requisitos da operadora), é obrigatório que algumas interfaces evitem canais não seguros para determinadas faixas de rede celular. Nesses casos, as restrições obrigatórias são representadas como uma máscara de bits que contém valores para proibir determinados canais, como Wi-Fi Direct (P2P), SoftAp e Wi-Fi Aware (NAN). Embora um canal não seguro atue como uma recomendação contra o uso dele para todos os casos de uso, as restrições obrigatórias marcam casos de uso específicos para evitar o uso obrigatório.

Se todos os canais da banda de 2,4 GHz ou 5 GHz estiverem marcados como não seguros, a tabela de pesquisa poderá definir um canal padrão de 2,4 GHz ou um canal padrão de 5 GHz por banda de célula interferente como a opção mais segura. Esses canais padrão não são informados como não seguros quando o resto da banda é informado como não seguro.

Lista de substituições

Uma abordagem de fórmula é limitada em casos em que a interferência é altamente dependente da largura de banda. Portanto, os canais com largura de banda maior podem não ser seguros, mas os canais com largura de banda menor podem ser. Em casos, como no LAA, é vantajoso pular os cálculos e usar uma lista especificada de canais não seguros.

Para fazer isso, especifique uma lista de substituição de canais não seguros na tabela de pesquisa para determinadas entradas. Uma lista de substituição em uma entrada de tabela significa que o cálculo para esse canal de célula específico é pulado e que os canais Wi-Fi não seguros para o canal de célula correspondente são especificados pela lista de substituição.

Para casos sensíveis à largura de banda, é possível evitar seletivamente determinadas larguras de banda especificando determinados canais com determinadas larguras de banda na lista de substituição. Isso acontece porque cada número de canal Wi-Fi corresponde a uma largura de banda especificada.

A lista de substituições é representada por uma lista de números de canais ou palavras-chave de categoria predefinidas para cada banda de Wi-Fi:

Categorias de 2G:

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

Categorias do 5G:

  • all (toda a faixa de 5 GHz)
  • 20mhz (canais de 20 MHz de 5 GHz)
  • 40mhz (canais de 40 MHz de 5 GHz)
  • 80mhz (canais de 80 MHz a 5 GHz)
  • 160mhz (canais de 160 MHz de 5 GHz)

Interferência em canais vizinhos

Para determinar a interferência de canais vizinhos, o algoritmo de evitação de coexistência garante que a distância ΔF entre um canal agressor e um canal vítima não seja menor que um limite especificado.

Interferência no canal

Figura 2. Distância entre um canal agressor e um canal vítima

O limite é determinado pela configuração física do dispositivo e pelo valor do limite fornecido na entrada da tabela de consulta por banda de interferência. As faixas consideradas não interferências não têm uma entrada de tabela, e os canais não seguros não precisam ser calculados (na maioria das vezes).

Parâmetros de interferência de vizinhos

  • wifiVictimMhz: limite de distância em MHz para uma vítima de Wi-Fi (link de uplink da célula)
  • cellVictimMhz: limite de distância em MHz para uma vítima de célula (link de entrada da célula)

O algoritmo se comporta da seguinte maneira para cada canal de célula ativo:

  1. Para a banda do canal, tenta encontrar uma entrada de tabela de pesquisa. Se nenhuma entrada da tabela for encontrada, retornará sem canais não seguros para esse canal de célula.
  2. Com base na banda celular, identifica qual banda Wi-Fi está em risco e de qual lado da banda a interferência vem (por exemplo, canais de 2,4 GHz mais baixos, canais de 2,4 GHz mais altos, canais de 5 GHz mais baixos).

  3. Se wifiVictimMhz estiver presente e o canal de célula tiver uplink e

    1. Se a parte inferior da banda Wi-Fi estiver em risco

      1. Encontre o limite máximo de canais não seguros adicionando wifiVictimMhz à frequência mais alta do uplink da célula.
      2. Encontra o primeiro canal de Wi-Fi de 20 Mhz cuja borda inferior sobrepõe o limite.
      3. Marca o canal Wi-Fi, todos os canais de largura de banda maiores que o contêm (por exemplo, 40 Mhz, 80 Mhz) e todos os canais mais baixos da mesma banda que o canal não seguro.

    2. Se a parte superior da banda Wi-Fi estiver em risco

      1. Encontra o limite inferior dos canais não seguros subtraindo o wifiVictimMhz da frequência mais baixa do uplink da célula.
      2. Encontra o primeiro canal de Wi-Fi cuja borda superior sobrepõe o limite.
      3. Marca o canal Wi-Fi, todos os canais maiores que o contêm (por exemplo, 40 Mhz, 80 Mhz) e todos os canais mais altos da mesma faixa que o canal não seguro.

  4. Se cellVictimMhz estiver presente e o canal de célula tiver um downlink.

    1. Executa a etapa 3 usando cellVictimMhz como limite e compara com o downlink da célula em vez do uplink da célula.

  5. Aplica o limite de energia da entrada da tabela aos canais não seguros calculados.

Cálculo de canal não seguro

Figura 3. Cálculo de canal não seguro para interferência de canal vizinho

Distorção harmônica ou intermodulação

Para distorção harmônica ou de intermodulação, o mecanismo de coex calcula o intervalo do sinal harmônico ou de intermodulação e avalia a porcentagem de sobreposição com um possível canal vítima. Se a sobreposição exceder um limite, o algoritmo vai considerar essa uma situação não segura. O cálculo da porcentagem de sobreposição da distorção harmônica ou de intermodulação em um canal vítima é realizado com a seguinte equação:

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

No caso de distorção harmônica, o algoritmo considera a distorção harmônica de um canal de uplink de celular que vitimiza canais Wi-Fi. Em seguida, substitui a distorção alta e a distorção baixa pelos valores harmônicos com base nas frequências de uplink da célula e um grau harmônico $ N $.

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

Distorção harmônica do cálculo de canal não seguro

Figura 4. Cálculo de canal inseguro para distorção harmônica

No caso de intermodulação, o algoritmo considera a distorção de intermodulação do uplink celular e do canal Wi-Fi que vitimiza o downlink celular. Em seguida, ele substitui a distorção alta e a distorção baixa pelos valores de intermodulação com base nas frequências de uplink da célula, nas frequências de Wi-Fi e nos dois coeficientes de intermodulação $ M $, $ N $.

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

Distorção de intermodulação do cálculo de canal não seguro

Figura 5. Cálculo de canal não seguro para distorção de intermodulação

Você pode especificar $ M $, $ N $ e valores de sobreposição na tabela de consulta por banda de células de interferência. Se não houver interferência para uma banda, os valores serão omitidos da tabela para essa entrada de banda. Dois conjuntos desses valores para as bandas de 2,4 GHz e 5 GHz podem ser definidos de maneira independente.

Semelhante ao algoritmo de interferência vizinho, o algoritmo reutiliza o mesmo valor de limite de energia definido por banda de célula de interferência.

O algoritmo se comporta da seguinte maneira para cada canal de célula ativo:

  1. Para a banda do canal de célula, ele tenta encontrar uma entrada de tabela de pesquisa. Se nenhuma entrada de tabela for encontrada, a API vai retornar que não há canais não seguros para esse canal.

  2. Encontra os canais de 2,4 GHz não seguros de harmônicos se os parâmetros forem definidos.

    1. Encontra o grau harmônico N para 2,4 GHz.
    2. Calcula a frequência alta e a frequência baixa harmônica com base em N e no uplink da célula.
    3. Encontra o primeiro canal Wi-Fi de 20 MHz que está dentro do limite inferior da harmônica vinda de baixo.
    4. Calcula a sobreposição do harmônico no canal Wi-Fi e marca o canal como não seguro se a sobreposição exceder o limite de sobreposição de Wi-Fi de 2,4 GHz.
    5. Encontra o primeiro canal Wi-Fi de 20 MHz que está dentro do limite superior da harmônica vinda de cima.
    6. Calcula a sobreposição do harmônico no canal Wi-Fi e marca o canal como não seguro se a sobreposição exceder o limite de sobreposição de Wi-Fi de 2,4 GHz.
    7. Marca cada canal de 20 MHz entre eles como um canal não seguro.

  3. Encontra os canais de 5 GHz não seguros de harmônicos se os parâmetros forem definidos.

    1. Encontra o grau harmônico N para 5 GHz. Se N for 0, pule para a etapa 5.
    2. Calcula a alta frequência harmônica e a baixa frequência harmônica com base em N e o uplink da célula.

    3. Encontra canais de 20 Mhz não seguros.

      1. Encontra o primeiro canal Wi-Fi de 20 MHz que está dentro do limite inferior do harmônico vindo de baixo.
      2. Calcula a sobreposição da harmônica no canal Wi-Fi e marca o canal como não seguro se a sobreposição exceder o limite de sobreposição de Wi-Fi de 2,4 GHz.
      3. Encontra o primeiro canal Wi-Fi de 20 MHz que está dentro do limite superior do harmônico vindo de cima.
      4. Calcula a sobreposição da harmônica no canal Wi-Fi e marca o canal como não seguro se a sobreposição exceder o limite de sobreposição de Wi-Fi de 2,4 GHz.
      5. Marca cada canal de 20 MHz entre eles como um canal não seguro com o limite de energia especificado.

    4. Detecta canais inseguros de 40 MHz, 80 MHz e 160 MHz

      1. Repita a etapa 3a, mas com 40 MHz, 80 MHz, 160 MHz.
      2. Em vez de calcular as sobreposições dos canais na borda harmônica, reutiliza as sobreposições calculadas dos canais constituintes menores. Por exemplo, se dois canais de 20 Mhz formarem um canal de 40 Mhz e tiverem sobreposição de 30% e 90%, a média será de 60% de sobreposição para o canal de 40 Mhz.

  4. Encontra os canais de 2,4 GHz não seguros da intermodulação se os parâmetros forem definidos.

    1. Encontra os coeficientes de intermodulação N, M para 2,4 GHz.

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

      1. Calcula a frequência baixa e a frequência alta de intermodulação com base em N, M, uplink de célula e canal Wi-Fi.
      2. Calcula a sobreposição da intermodulação na transmissão de dados de e marca o canal como não seguro se a sobreposição exceder o limite de 2,4 GHz.

  5. Encontra os canais de 5 GHz não seguros da intermodulação se os parâmetros forem definidos.

    1. Repita a etapa 4 usando os canais Wi-Fi de 5 GHz e o limite de sobreposição de células de 5 GHz.

  6. Aplica o limite de energia da entrada da tabela aos canais não seguros calculados.

Resultado final

Depois que os dois conjuntos de canais não seguros de interferências vizinhos e harmônicas forem calculados, o conjunto final será calculado pela união dos dois conjuntos (e selecionando o limite de energia mais baixo se houver colisões) e removendo os canais padrão do conjunto se não houver restrições obrigatórias aplicadas.

O algoritmo se comporta da seguinte maneira:

  1. Se todos os canais Wi-Fi de 2,4 GHz forem marcados como não seguros, o canal Wi-Fi de 2,4 GHz padrão será removido do conjunto.
  2. Se cada canal de Wi-Fi de 5 GHz for marcado como não seguro, o canal padrão de 5 GHz será removido do conjunto.
  3. Retorna o conjunto final de canais não seguros.

Formato da tabela de consulta

As tabelas de pesquisa são representadas em um arquivo XML localizado na string de configuração sobreposta config_wifiCoexTableFilepath e são definidas pelo seguinte 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>

Exemplo de tabela XML

Confira abaixo um exemplo de tabela de pesquisa 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>

Agregação de operadora

Para agregação de operadora (CA), os intervalos harmônicos ou de intermodulação de cada uplink ou downlink podem não produzir sobreposição suficiente para causar interferência de forma independente, mas podem produzir sobreposição suficiente quando combinados. O algoritmo considera cada intervalo de harmônico ou intermodulação de forma independente e considera a união dos canais não seguros retornados. No caso da intermodulação, isso significa avaliar o intervalo de intermodulação de cada UL em cada DL.

O algoritmo não faz distinção entre PCELL, PSCELL ou SCELL e os trata como iguais.

Acesso assistido por licença

O acesso com licença (LAA, na sigla em inglês) é identificado como a banda 46. O algoritmo trata essa banda de forma semelhante a outras. Nesse caso, os canais de 5 Ghz completos podem ser definidos como uma lista de substituição na tabela de pesquisa.

Dependendo dos requisitos da operadora, o algoritmo de evitação de canal define restrições obrigatórias no SoftAP e no Wi-Fi Direct (P2P) para toda a faixa de 5 GHz do Wi-Fi. Para que o algoritmo lide com esse caso de uso, o valor de configuração da operadora restrict_5g_softap_wifi_direct_for_laa precisa ser definido. Se o canal de célula estiver no LAA e restrict_5g_softap_wifi_direct_for_laa for true, o algoritmo retornará o conjunto de canais não seguros com toda a banda de 5 Ghz e definirá as flags de restrição obrigatória para SoftAP e Wi-Fi Direct (P2P).

Informar serviço de Wi-Fi

Depois que o algoritmo de canal de coexistência calcular os canais não seguros, para fornecer aos apps do sistema os canais não seguros e as restrições deles, use a seguinte estrutura de dados @SystemApi definida no framework do 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 os seguintes métodos e callback WifiManager @SystemApi para permitir que os apps recebam valores atualizados quando os canais não seguros mudarem.

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 ação do Wi-Fi

Quando o serviço de Wi-Fi recebe informações sobre o conjunto de canais não seguros, ele realiza a ação adequada para garantir que esses canais sejam evitados. Esta seção descreve o comportamento do serviço de Wi-Fi em diferentes cenários.

Informar o motorista

Como o driver tem um papel importante na evitação de canais, é essencial transmitir os canais não seguros ao driver e ao firmware. Para fazer isso, use a API HAL IWifiChip a seguir.

Para AIDL:

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

Para HIDL (1.5 ou superior):

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

SoftAP

O SoftAP é o principal caso de uso para evitar canais não seguros. A seção a seguir descreve os principais cenários de SoftAP em que a evitação de canal pode ser aplicada com ACS. Os cenários descrevem o comportamento do algoritmo de evitação de canal e do driver ou firmware.

Inicie o SoftAP com o ACS ativado (nenhum SoftAP ainda está ativo)

  1. Se os canais forem considerados inseguros e houver uma restrição de AP virtual

    1. O framework remove os canais não seguros da lista de ACS.
    2. Se a lista estiver vazia, o framework interromperá o SoftAP.

  2. Se os canais forem considerados não seguros e não houver restrições

    1. O driver ou firmware do fornecedor prioriza os canais seguros em vez dos canais não seguros.

O SoftAP está com o ACS ativado e os canais não seguros foram atualizados

  1. Se o canal do SoftAP não for seguro e houver uma restrição

    1. O framework atualiza a lista de ACS removendo os canais não seguros.
    2. Se a lista estiver vazia, o framework vai fechar o SoftAP.

  2. Se o canal SoftAP não for seguro e não houver restrições

    1. O framework não toma nenhuma ação. O driver ou firmware do fornecedor evita os canais não seguros ou aplica o limite de energia se a evitação não for viável.

Wi-Fi Direct (P2P)

  1. Se houver canais não seguros com restrições ao Wi-Fi Direct (P2P).

    1. O framework solicita wpa_supplicant para evitar os canais não seguros usando o método HAL ISupplicantP2pIface::setDisallowedFrequencies().

  2. Se houver canais não seguros sem restrições.

    1. O driver ou firmware do fornecedor aplica o limite de energia se um canal inseguro sem restrição do Wi-Fi Direct (P2P) for usado.

Wi-Fi Aware (NAN)

O framework não está envolvido na seleção de canal para Wi-Fi Aware (NAN), e nenhuma ação do framework é realizada. O driver ou firmware do fornecedor é responsável por evitar o canal Wi-Fi Aware (NAN).

Desativar o algoritmo

Se você quiser desativar a implementação do algoritmo padrão e transmitir sua própria lista de canais não seguros para evitar, configure a sobreposição config_wifiDefaultCoexAlgorithmEnabled. Se a sobreposição for definida como falsa, o algoritmo padrão será desativado. Em seguida, use seu próprio algoritmo privativo fora da banda para gerar uma lista de canais não seguros para conectar ao framework usando a API do sistema abaixo.

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

Validar a implementação

Para validar sua implementação do recurso de prevenção de canais coex de Wi-Fi/celular, use os testes a seguir.

Testes CTS

  • WifiManagerTest.java

    • testCoexMethodsShouldFailNoPermission()
    • testListenOnCoexUnsafeChannels()

Testes ACTS

  • WifiManagerTest.py

    • test_set_get_coex_unsafe_channels()

Testes VTS

  • Se a AIDL estiver implementada: wifi_chip_aidl_test.cpp

    • TEST_P(WifiChipAidlTest, SetCoexUnsafeChannels)

  • Se o HIDL for implementado: wifi_chip_hidl_test.cpp

    • TEST_P(WifiChipHidlTest, setCoexUnsafeChannels)