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

O recurso de prevenção de coexistência em canais Wi-Fi/celular, lançado no Android 12, identifica e evita o uso de canais Wi-Fi não seguros em casos de possível 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 os seguintes tópicos:

• Informações que o modem celular precisa informar à estrutura do Android
• Algoritmos que a estrutura Wi-Fi usa para calcular os canais a serem 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 evitar canais
• Comportamento da estrutura para lidar com a prevenção de canais
• Comportamento do fornecedor de chips para lidar com a prevenção de canais
• Detalhes da implementação para evitar canais
• Testes para validar o comportamento de evitação de canais

Contexto

Em dispositivos com tecnologias celulares, como LTE, 5G NR e acesso assistido por licença (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 pequena separação de frequência (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.

Neste documento, o transmissor interferente é chamado de agressor e o receptor que sofre a interferência é chamado de vítima. O canal Wi-Fi que é o agressor ou a vítima é chamado de canal inseguro.

O recurso de prevenção de coexistência em canais Wi-Fi/celular oferece uma abordagem consistente para evitar canais, 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 canais controlando os canais Wi-Fi. O esquema de prevenção de canais Wi-Fi pode ser descrito como uma série de quatro etapas abstratas:

1. Os relatórios do modem mostram mudanças na frequência celular
2. O algoritmo de prevenção de coexistência calcula canais Wi-Fi não seguros
3. O algoritmo de prevenção de coexistência informa o serviço Wi-Fi
4. O framework ou driver realiza a ação de Wi-Fi adequada

Figura 1. Esquema de prevenção de canais

Informar uma mudança na frequência celular

O serviço de telefonia informa os canais de celular em uso no momento. Quando a frequência celular operacional muda, o modem informa essa informação ao serviço de telefonia por IRadio::PhysicalChannelConfig. Essas informações incluem indicações para acesso assistido licenciado (LAA) e agregação de operadoras (CA).

No Android 12, os seguintes campos em 1.6 IRadio::PhysicalChannelConfig fornecem as informações necessárias para as fórmulas de coexistência 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 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 celular e Wi-Fi e determina qual conjunto de canais Wi-Fi não é seguro.

Há vários tipos de interferência que exigem fórmulas diferentes: vizinha 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/de intermodulação e de vizinhança são diferentes para cada dispositivo. Para considerar isso, os fabricantes de dispositivos precisam fornecer uma tabela de consulta para inserir parâmetros em fórmulas genéricas dos dois tipos de interferência. Esses parâmetros são definidos por banda de célula e referenciados pelas bandas dos canais de célula ativos.

É possível definir um limite máximo de energia 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, o canal vai transmitir com potência máxima.

Em geral, o recurso de prevenção de canais usa uma abordagem de melhor esforço 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 determinadas interfaces evitem canais não seguros para determinadas bandas de 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). Um canal não seguro funciona como uma recomendação contra o uso desse canal em todos os casos de uso, enquanto as restrições obrigatórias marcam casos de uso específicos para evitar obrigatoriamente.

Se todos os canais da banda de 2,4 GHz ou 5 GHz forem marcados como não seguros, a tabela de pesquisa poderá definir um canal padrão de 2,4 GHz ou 5 GHz por banda de célula interferente como a opção mais segura. Esses canais padrão não são considerados inseguros quando o restante da banda é considerado inseguro.

Observação: o modem precisa limitar a frequência das notificações para evitar o envio de spam para o callback onPhysicalChannelConfigurationChanged().

Lista de substituições

Uma abordagem baseada em fórmulas é limitada em casos em que a interferência depende muito da largura de banda. Assim, canais com largura de banda maior podem ser inseguros, mas não canais com largura de banda menor. Em casos como o LAA, é benéfico ignorar os cálculos e usar uma lista especificada de canais não seguros.

Para 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 é ignorado 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 canais com larguras de banda específicas na lista de substituição. Isso acontece porque cada número de canal Wi-Fi corresponde a uma largura de banda específica.

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

Categorias de 2g:

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

Categorias de 5G:

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

Interferência de canais vizinhos

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

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

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

Parâmetros de interferência vizinha

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

Observação: os dois limites (wifiVictimMhz e cellVictimMhz) podem ser fornecidos para uma única banda no caso de FDD. Cada um dos limites se aplica aos canais FDD de uplink e downlink correspondentes. Os limites podem ser os mesmos para uma banda TDD.

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

1. Para a faixa do canal, tenta encontrar uma entrada de tabela de pesquisa. Se nenhuma entrada de tabela for encontrada, a função vai retornar sem canais não seguros para esse canal de célula.
2. Com base na banda de celular, identifica qual banda de Wi-Fi está em risco e de qual lado da banda vem a interferência (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 da célula tiver uplink e

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

      1. Encontra o limite superior de canais não seguros adicionando wifiVictimMhz à maior frequência do uplink da célula.
      2. Encontra o primeiro canal Wi-Fi de 20 MHz cuja borda inferior se sobrepõe ao limite.
      3. Marca o canal Wi-Fi, todos os canais de largura de banda maior 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 de canais não seguros subtraindo wifiVictimMhz da frequência mais baixa do uplink da célula.
      2. Encontra o primeiro canal Wi-Fi cuja borda superior se sobrepõe ao 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 banda que o canal não seguro.

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

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

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

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

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

Para distorção harmônica ou de intermodulação, o mecanismo de coexistência calcula o intervalo do sinal harmônico ou de intermodulação e avalia a porcentagem de sobreposição com um possível canal afetado. Se a sobreposição exceder um limite, o algoritmo vai considerar isso uma situação de risco. O cálculo da porcentagem de sobreposição da distorção harmônica ou de intermodulação em um canal afetado é feito com a seguinte equação:

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

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

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

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

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

No caso da intermodulação, o algoritmo considera a distorção de intermodulação do uplink da célula e o canal Wi-Fi que prejudica o canal de downlink da célula. Em seguida, ele substitui a distorção alta e 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 $ e $ N $.

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

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

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

É possível especificar valores de $ M $, $ N $ e de sobreposição na tabela de pesquisa por faixa de célula interferente. Se não houver interferência em uma banda, os valores serão omitidos da tabela para essa entrada. Dois conjuntos desses valores para as bandas de 2,4 GHz e 5 GHz do Wi-Fi podem ser definidos de forma independente.

Assim como o algoritmo de interferência vizinha, ele reutiliza o mesmo valor de limite de energia definido por banda de célula interferente.

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

1. Para a banda do canal da célula, ele tenta encontrar uma entrada de tabela de pesquisa. Se nenhuma entrada de tabela for encontrada, a resposta será sem 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 alta e a baixa frequência harmônicas 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 do harmônico vindo 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 do Wi-Fi de 2,4 GHz.
   5. Encontra o primeiro canal Wi-Fi de 20 MHz que está dentro do limite superior do harmônico vindo 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 do Wi-Fi de 2,4 GHz.
   7. Marca todos os canais de 20 MHz entre eles como não seguros.

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 e a baixa frequência harmônicas com base em N e no 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 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 do 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 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 do Wi-Fi de 2,4 GHz.
      5. Marca todos os canais de 20 MHz entre eles como um canal não seguro com o limite de energia especificado.

   4. Encontra canais de 40 MHz, 80 MHz e 160 MHz não seguros

      1. Repete a etapa 3a, mas com 40 MHz, 80 MHz e 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 formam um canal de 40 MHz e têm sobreposição de 30% e 90%, a média é 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 e M para 2, 4 GHz.

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

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

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

   1. Repete 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ência vizinha e harmônica são calculados, o conjunto final é calculado unindo os dois conjuntos (e selecionando o limite de potência 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 funciona da seguinte maneira:

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

Observação: o algoritmo não aborda o cálculo de restrições obrigatórias porque elas são um caso especial.

Formato da tabela de consulta

As tabelas de pesquisa são representadas em um arquivo XML localizado na string de configuração sobreponível 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

Este é 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 operadoras

Para agregação de operadora (CA, na sigla em inglês), 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 harmônico ou de intermodulação de forma independente e usa a união dos canais não seguros retornados. Para o caso de 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 assistido por licença (LAA, na sigla em inglês) é identificado como banda 46. O algoritmo trata essa banda de forma semelhante a outras. Nesse caso, todos os canais de 5 GHz podem ser definidos como uma lista de substituição na tabela de pesquisa.

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

Informar o serviço de Wi-Fi

Depois que o algoritmo de canal de coexistência calcula os canais não seguros, use a seguinte estrutura de dados @SystemApi definida no framework do Android para fornecer aos apps do sistema os canais não seguros e as restrições deles.

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 de Wi-Fi

Quando o serviço 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 motorista tem um papel importante na prevenção de canais, é essencial transmitir os canais não seguros para o motorista e o firmware. Para isso, use a seguinte API HAL IWifiChip.

Para AIDL:

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

Para HIDL (1.5 ou mais recente):

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 prevenção de canais pode ser aplicada com o ACS. Os cenários descrevem o comportamento do algoritmo de prevenção de canais e do driver ou firmware.

Inicie o SoftAP com o ACS ativado (ainda não há SoftAP em execução)

1. Se os canais não forem seguros e houver uma restrição de SoftAP

   1. O framework remove canais não seguros da lista do ACS.
   2. Se a lista estiver vazia, o framework vai 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 não seguros.

O SoftAP está ativo com o ACS ativado, e os canais não seguros são atualizados.

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

   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. Nenhuma ação é realizada pelo framework. O driver ou firmware do fornecedor evita os canais não seguros ou aplica o limite de energia se a prevenção não for possível.

Wi-Fi Direct (P2P)

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

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

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

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

Wi-Fi Aware (NAN)

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

Desativar o algoritmo

Se 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 "false", o algoritmo padrão será desativado. Em seguida, use seu próprio algoritmo de banda externa para gerar uma lista de canais não seguros a serem conectados ao framework usando a seguinte API do sistema.

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

Validar a implementação

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

Testes do CTS

• WifiManagerTest.java

  • testCoexMethodsShouldFailNoPermission()
  • testListenOnCoexUnsafeChannels()

Testes de ACTS

• WifiManagerTest.py

  • test_set_get_coex_unsafe_channels()

Testes VTS

• Se o AIDL for implementado: wifi_chip_aidl_test.cpp

  • TEST_P(WifiChipAidlTest, SetCoexUnsafeChannels)

• Se o HIDL for implementado: wifi_chip_hidl_test.cpp

  • TEST_P(WifiChipHidlTest, setCoexUnsafeChannels)