Esta página foi traduzida pela API Cloud Translation.

Evitação de Canal Coex Wi-Fi/Celular

O recurso de evitar canal coex Wi-Fi/celular, introduzido no Android 12, identifica e evita o uso de canais Wi-Fi inseguros em casos em que possa haver interferência de/para canais celulares. Isso inclui interfaces como STA, SoftAp, Wi-Fi Direct (P2P), Wi-Fi Aware (NAN).

Esta página discute o seguinte:

Informações que o modem celular deve reportar à estrutura do Android
Algoritmos que a estrutura Wi-Fi usa para calcular canais Wi-Fi a serem evitados
Tabelas de configuração que os fabricantes de dispositivos devem fornecer para a estrutura Wi-Fi
APIs do sistema, configurações e APIs HAL relacionadas ao recurso de prevenção de canais
Comportamento da estrutura para lidar com a evitação de canais
Comportamento do fornecedor de chips para lidar com a evitação de canais
Detalhes de implementação para evitar canais
Testes para validar o comportamento de evitar canais

Fundo

Para dispositivos com tecnologias celulares como LTE, 5G NR e Acesso Assistido Licenciado (LAA), os canais celulares em uso podem interferir no canal Wi-Fi em uso. Isso ocorre quando os canais celulares e Wi-Fi estão dentro de uma curta 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 recebendo ao mesmo tempo. Neste caso, a antena transmissora inunda a antena receptora, impactando na sua qualidade de recepção.

Este documento refere-se ao transmissor interferente 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 é denominado canal inseguro .

O recurso de prevenção de canais coex Wi-Fi/celular fornece uma abordagem consistente para evitar canais, reduzindo a necessidade de código proprietário que diverge da estrutura Wi-Fi. Além disso, o recurso permite que os fabricantes de dispositivos configurem, habilitem e desabilitem, e substituam o recurso.

O recurso evita canais controlando os canais Wi-Fi. O esquema para evitar canais Wi-Fi pode ser descrito como uma série de quatro etapas abstratas:

Modem relata mudança na frequência celular
Algoritmo de prevenção Coex calcula canais Wi-Fi inseguros
Algoritmo de prevenção Coex informa o serviço Wi-Fi
Estrutura ou driver executa ação Wi-Fi apropriada

Esquema para evitar canais

Figura 1. Esquema para evitar canais

Relatando uma mudança na frequência celular

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

A partir do Android 12, os seguintes campos em 1.6 IRadio::PhysicalChannelConfig fornecem as informações necessárias para as fórmulas coex que o modem deve 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;
}

Cálculo de canais Wi-Fi inseguros

Quando o modem relata uma mudança na frequência do celular, o algoritmo do canal coex calcula a interferência entre os canais celulares e Wi-Fi e determina qual conjunto de canais Wi-Fi não é seguro.

Existem vários tipos de interferência que requerem 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 vizinha e harmônica/intermodulação para cada dispositivo são diferentes. Para levar em conta isso, os fabricantes de dispositivos devem fornecer uma tabela de consulta para inserir parâmetros em fórmulas genéricas para os dois tipos de interferência. Esses parâmetros são definidos por banda celular e são referenciados pelas bandas dos canais celulares ativos.

Um limite máximo de energia pode ser definido na tabela de consulta. Se um limite máximo de potência for definido, um canal inseguro transmitirá com o limite de potência fornecido. Se não houver limite de potência, o canal transmite 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 inseguros e otimizar o desempenho. Mas em certos casos (por exemplo, devido a requisitos da operadora), é obrigatório que determinadas interfaces evitem canais inseguros para determinadas bandas celulares. Nesses casos, as restrições obrigatórias são representadas como uma máscara de bits contendo valores para proibir determinados canais, como Wi-Fi Direct (P2P), SoftAp e Wi-Fi Aware (NAN). Embora um canal inseguro atue como uma recomendação contra o uso desse canal para todos os casos de uso, as restrições obrigatórias marcam casos de uso específicos que devem ser evitados compulsoriamente.

Se cada canal da banda de 2,4 GHz ou 5 GHz estiver marcado como inseguro, a tabela de consulta 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 escolha mais segura. Esses canais padrão não são reportados como canais inseguros quando o restante da banda é reportado como inseguro.

Substituir lista

Uma abordagem estereotipada é limitada nos casos em que a interferência depende fortemente da largura de banda (e, portanto, 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 pular os cálculos e usar uma lista específica de canais inseguros.

Para fazer isso, você pode especificar uma lista de substituição de canais inseguros na tabela de consulta para determinadas entradas. Uma lista de substituição em uma entrada de tabela significa que o cálculo para aquele canal de célula específico foi ignorado e que os canais Wi-Fi inseguros para o canal de célula correspondente são especificados pela lista de substituição.

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

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

Categorias 2g:

all (toda a banda de 2,4 GHz)

Categorias 5g:

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

Interferência de canal vizinho

Para determinar a interferência do canal vizinho, o algoritmo de evitação coex garante que a distância ΔF entre um canal agressor e uma vítima não fique abaixo de um limite especificado.

Interferência de canal

Figura 2. Distância entre canal agressor e 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 interferente. As bandas consideradas não interferentes não possuem entrada na tabela e os canais inseguros não precisam ser calculados (isso ocorre na maioria das vezes).

Parâmetros de interferência vizinhos

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

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

Para a banda do canal, tenta encontrar uma entrada na tabela de consulta. Se nenhuma entrada de tabela for encontrada, retorna sem canais inseguros para esse canal de célula.
Com base na banda celular, identifica qual banda Wi-Fi está em risco e de qual lado da banda vem a interferência (por exemplo, canais inferiores de 2,4 GHz, canais superiores de 2,4 GHz, canais inferiores de 5 GHz).
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 inseguros adicionando wifiVictimMhz à frequência mais alta 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 inferiores da mesma banda que o canal inseguro.
2. Se a parte superior da banda Wi-Fi estiver em risco
  1. Encontra o limite inferior de canais inseguros subtraindo wifiVictimMhz à 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 inseguro.
Se cellVictimMhz estiver presente e o canal da célula tiver 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.
Aplica o limite de energia da entrada da tabela aos canais inseguros calculados.

Cálculo de canal inseguro

Figura 3. Cálculo de canal inseguro para interferência de canal vizinho

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

Para distorção harmônica/intermodulação, o mecanismo coex calcula a faixa do sinal harmônico/intermodulação e avalia a porcentagem de sobreposição que ele possui com um canal vítima em potencial. Se a sobreposição exceder um limite de sobreposição, o algoritmo considera esta uma situação insegura. O cálculo da sobreposição percentual da distorção harmônica/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 uplink celular vitimando canais Wi-Fi. Em seguida, ele substitui a distorção alta e a distorção baixa pelos valores harmônicos baseados 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} $$

Distorção harmônica de cálculo de canal inseguro

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 da célula e do canal Wi-Fi que vitima o canal de downlink da célula. Em seguida, ele substitui a distorção alta e a distorção baixa pelos valores de intermodulação baseados nas frequências de uplink da célula, nas frequências 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 de cálculo de canal inseguro

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

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

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

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

Para a banda do canal celular, ele tenta encontrar uma entrada na tabela de consulta. Se nenhuma entrada de tabela for encontrada, retorna sem canais inseguros para este canal.
Encontra os canais inseguros de 2,4 GHz a partir de harmônicos se os parâmetros forem definidos.
1. Encontra o grau harmônico N para 2,4 GHz.
2. Calcula a alta frequência harmônica e a baixa frequência 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 da harmônica no canal Wi-Fi e marca o canal como inseguro se a sobreposição exceder o limite de sobreposição 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 da harmônica no canal Wi-Fi e marca o canal como inseguro se a sobreposição exceder o limite de sobreposição Wi-Fi de 2,4 GHz.
7. Marca cada canal de 20 MHz intermediário como um canal inseguro.
Encontra os canais inseguros de 5 GHz a partir de harmônicos se os parâmetros forem definidos.
1. Encontra o grau harmônico N para 5 GHz. Se N for 0, salta para o passo 5.
2. Calcula a alta frequência harmônica e a baixa frequência harmônica com base em N e no uplink da célula.
3. Encontra canais inseguros de 20 MHz.
  1. Encontra o primeiro canal Wi-Fi de 20 MHz que está dentro do limite inferior da harmônica vinda de baixo.
  2. Calcula a sobreposição da harmônica no canal Wi-Fi e marca o canal como inseguro se a sobreposição exceder o limite de sobreposição Wi-Fi de 2,4 GHz.
  3. Encontra o primeiro canal Wi-Fi de 20 MHz que está dentro do limite superior da harmônica vinda de cima.
  4. Calcula a sobreposição da harmônica no canal Wi-Fi e marca o canal como inseguro se a sobreposição exceder o limite de sobreposição Wi-Fi de 2,4 GHz.
  5. Marca cada canal de 20 MHz intermediário como um canal inseguro com o limite de energia especificado.
4. Encontra canais inseguros de 40 MHz, 80 MHz, 160 MHz
  1. Repete 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 formam um canal de 40 MHz e têm 30% e 90% de sobreposição, então a média é 60 % de sobreposição para o canal de 40 Mhz).
Encontra os canais de 2,4 GHz inseguros 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 Wi-Fi de 2,4 GHz:
  1. Calcula a baixa frequência de intermodulação e a alta frequência de intermodulação com base em N, M, uplink de célula e canal Wi-Fi.
  2. Calcula a sobreposição da intermodulação no downlink da célula e marca o canal como inseguro se a sobreposição exceder o limite de sobreposição da célula de 2,4 GHz.
Encontra os canais de 5 GHz inseguros 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.
Aplica o limite de energia da entrada da tabela aos canais inseguros calculados.

Resultado final

Após o cálculo de ambos os conjuntos de canais inseguros de interferência vizinha e harmônica, o conjunto final é calculado tomando a união de ambos os conjuntos (e selecionando o limite de potência mais baixo se houver colisões) e removendo os canais padrão do conjunto se houver nenhuma restrição obrigatória aplicada.

O algoritmo se comporta da seguinte forma:

Se cada canal Wi-Fi de 2,4 GHz estiver marcado como canal inseguro, remove o canal Wi-Fi padrão de 2,4 GHz do aparelho.
Se cada canal Wi-Fi de 5 GHz estiver marcado como canal inseguro, remove o canal Wi-Fi padrão de 5 GHz do aparelho.
Retorna o conjunto final de canais inseguros.

Formato da tabela de pesquisa

As tabelas de consulta são representadas em um arquivo XML localizado na sequência de configuração sobreposta config_wifiCoexTableFilepath e são definidas pelo XSD a seguir.


<?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

A seguir está 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 portadora (CA), as faixas harmônicas/intermodulação para cada uplink/downlink podem não produzir sobreposição suficiente para causar interferência de forma independente, mas podem produzir sobreposição suficiente quando combinadas. O algoritmo considera cada faixa harmônica/intermodulação de forma independente e faz a união dos canais inseguros retornados. Para o caso de intermodulação, isto significa avaliar a faixa de intermodulação de cada UL em cada DL.

O algoritmo não faz distinção entre PCELL/PSCELL/SCELLs e os trata como iguais.

Acesso assistido por licença

O License Assisted Access (LAA) é identificado como banda #46. O algoritmo trata esta banda de forma semelhante a outras bandas. Neste caso, os canais completos de 5 Ghz podem ser definidos como uma lista de substituição na tabela de consulta.

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 lide com esse caso de uso, o valor de configuração da operadora restrict_5g_softap_wifi_direct_for_laa deve ser definido. Se o canal do celular estiver em LAA e restrict_5g_softap_wifi_direct_for_laa for true , o algoritmo retorna o conjunto de canais inseguros com toda a banda de 5 Ghz e define os flags de restrição obrigatórios para SoftAP e Wi-Fi Direct (P2P).

Informando o serviço Wi-Fi

Depois que o algoritmo do canal coex calcular os canais inseguros, para fornecer aos aplicativos do sistema os canais inseguros e suas restrições, use a seguinte estrutura de dados @SystemApi definida na estrutura 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 WifiManager @SystemApi e retorno de chamada para permitir que os aplicativos obtenham valores atualizados quando os canais inseguros mudam.

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

Executando ação de Wi-Fi

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

Informando o motorista

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

Para AIDL:

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

Para HIDL (1,5 ou superior):

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

SoftAP

SoftAP é o principal caso de uso para evitar canais inseguros. A seção a seguir descreve os principais cenários de SoftAp onde a prevenção de canais pode ser aplicada com ACS. Os cenários descrevem o comportamento do algoritmo de prevenção de canal e do driver ou firmware.

Iniciando o SoftAP com ACS habilitado (nenhum SoftAP está ativo ainda)

Se os canais não forem seguros e houver uma restrição SoftAP
1. A estrutura remove canais inseguros da lista ACS.
2. Se a lista estiver vazia, a estrutura interrompe o SoftAP.
Se os canais não forem seguros e não houver restrições
1. O driver/firmware do fornecedor dá prioridade aos canais seguros sobre os canais inseguros.

SoftAP está ativo com ACS habilitado e canais inseguros são atualizados

Se o canal SoftAP não for seguro e houver uma restrição SoftAP
1. A estrutura atualiza a lista ACS removendo os canais inseguros.
2. Se a lista estiver vazia, o framework fecha o SoftAP.
Se o canal SoftAP não for seguro e não houver restrições
1. Nenhuma ação é tomada pela estrutura. O driver/firmware do fornecedor evita os canais inseguros ou aplica o limite de energia se a evitação não for viável.

Wi-Fi direto (P2P)

Se houver canais inseguros com restrições de Wi-Fi Direct (P2P).
1. A estrutura solicita wpa_supplicant para evitar canais inseguros usando o método HAL ISupplicantP2pIface::setDisallowedFrequencies() .
Se houver canais inseguros sem restrições.
1. O driver/firmware do fornecedor aplica o limite de energia se um canal inseguro sem restrição de Wi-Fi Direct (P2P) for usado.

Com reconhecimento de Wi-Fi (NAN)

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

Desativando o algoritmo

Se você quiser desabilitar a implementação do algoritmo padrão e passar sua própria lista de canais inseguros para evitar, configure a sobreposição config_wifiDefaultCoexAlgorithmEnabled . Se a sobreposição for definida como falsa, o algoritmo padrão será desabilitado. Você pode então usar seu próprio algoritmo proprietário fora de banda para gerar uma lista de canais inseguros para conectar à estrutura usando a API do sistema a seguir.

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

Validando a implementação

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

Testes CTS

WifiManagerTest.java
- testCoexMethodsShouldFailNoPermission()
- testListenOnCoexUnsafeChannels()

Testes ATOS

WifiManagerTest.py
- test_set_get_coex_unsafe_channels()

Testes VTS

Se AIDL for implementado: wifi_chip_aidl_test.cpp
- TEST_P(WifiChipAidlTest, SetCoexUnsafeChannels)
Se HIDL for implementado: wifi_chip_hidl_test.cpp
- TEST_P(WifiChipHidlTest, setCoexUnsafeChannels)