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

O recurso de prevenção de canal coex Wi-Fi/celular, introduzido no Android 12, identifica e evita o uso de canais Wi-Fi inseguros nos casos em que pode haver interferência de/para canais de celular. 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 relatar à estrutura do Android
  • Algoritmos que o framework Wi-Fi usa para calcular os 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 canal
  • Comportamento da estrutura para lidar com a evitação de canal
  • 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 evitação de canal

Fundo

Para dispositivos com tecnologias de celular, como LTE, 5G NR e Licensed Assisted Access (LAA), os canais de celular 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 recebendo ao mesmo tempo. Neste caso, a antena transmissora inunda a antena receptora, impactando sua qualidade de recepção.

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

O recurso de prevenção de canal coex Wi-Fi/celular fornece uma abordagem consistente para evitar canal, 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, ativem e desativem e substituam o recurso.

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

  1. Modem informa alteração na frequência do celular
  2. Algoritmo de prevenção Coex calcula canais Wi-Fi inseguros
  3. Algoritmo de prevenção Coex informa o serviço Wi-Fi
  4. Framework ou driver executa a ação Wi-Fi apropriada

Esquema de prevenção de canal

Figura 1. Esquema de prevenção de canal

Como relatar uma alteração na frequência do celular

O serviço de telefonia informa os canais de celular atualmente em uso. Quando a frequência de operação do celular muda, o modem reporta esta informação ao serviço de telefonia através de IRadio::PhysicalChannelConfig . Essas informações incluem indicações para acesso assistido licenciado (LAA) e agregação de operadora (CA).

A partir do Android 12, os campos a seguir 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;
}

Calculando 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 celular e Wi-Fi e determina qual conjunto de canais Wi-Fi não são seguros.

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

Um limite máximo de energia pode ser definido na tabela de pesquisa. Se for definido um limite máximo de energia, um canal não seguro transmite com o limite de energia fornecido. Se não houver limite de energia, 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 para otimizar o desempenho. Mas em certos casos (por exemplo, devido aos requisitos da operadora), é obrigatório que certas interfaces evitem canais inseguros para determinadas bandas de celular. 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). Enquanto um canal não seguro atua 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 para serem evitados compulsoriamente.

Se todos os canais da banda de 2,4 GHz ou 5 GHz estiverem marcados como inseguros, 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 escolha mais segura. Esses canais padrão não são relatados como canais inseguros quando o restante da banda é relatado como inseguro.

Substituir lista

Uma abordagem formulada é limitada nos casos em que a interferência depende muito 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 com LAA, é benéfico pular os cálculos e usar uma lista especificada de canais inseguros.

Para fazer isso, você pode especificar 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 foi 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, 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:

2g categorias:

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

5g categorias:

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

Interferência de canal vizinho

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

Interferência de canal

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

Parâmetros de interferência vizinhos

  • wifiVictimMhz : limite de distância de MHz para uma vítima de Wi-Fi (uplink de celular)
  • cellVictimMhz : limite de distância de 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:

  1. Para a banda do canal, tenta encontrar uma entrada na tabela de pesquisa. Se nenhuma entrada de tabela for encontrada, retorna sem canais não seguros para esse canal de célula.
  2. Com base na banda de celular, identifica qual banda 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 celular 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. Localiza o primeiro canal Wi-Fi de 20 Mhz cuja borda inferior se sobrepõe ao limite.
      3. Marca o canal Wi-Fi, cada canal de largura de banda maior que o contém (por exemplo, 40Mhz, 80Mhz) e cada canal inferior da mesma banda como o canal não seguro.
    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. Localiza o primeiro canal Wi-Fi cuja borda superior se sobrepõe ao limite.
      3. Marca o canal Wi-Fi, cada canal maior que o contém (por exemplo, 40Mhz, 80Mhz) e cada canal superior da mesma banda como 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 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 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 o alcance do sinal harmônico/intermodulação e avalia a porcentagem de sobreposição que tem com um canal potencial vítima. Se a sobreposição exceder um limite de sobreposição, o algoritmo considera essa situação insegura. O cálculo do percentual de sobreposição 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 de uplink de célula vitimizando 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 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 da intermodulação, o algoritmo considera a distorção da intermodulação do uplink da célula e do canal Wi-Fi vitimizando o canal do 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, frequências de Wi-Fi e os 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élula interferente. 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 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 energia definido por banda de célula interferente.

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

  1. Para a banda do canal da célula, ele tenta encontrar uma entrada na tabela de pesquisa. Se nenhuma entrada de tabela for encontrada, retorna sem canais não seguros para este canal.
  2. Encontra os canais inseguros de 2,4 GHz 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 do harmônico vindo de baixo.
    4. Calcula a sobreposição do harmônico sobre o 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. Localiza 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 sobre o 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.
  3. 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 5GHz. 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 20Mhz.

      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 sobre o 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. Localiza 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 sobre o 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 o passo 3a mas com 40MHz, 80MHz, 160MHz.
      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 20Mhz formam um canal de 40Mhz e têm 30% e 90% de sobreposição, então a média é de 60% de sobreposição para o canal de 40Mhz).
  4. Localiza os canais inseguros de 2,4 GHz da intermodulação se os parâmetros estiverem 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 sobre o 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.
  5. Encontra os canais inseguros de 5 GHz da intermodulação se os parâmetros estiverem 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 inseguros calculados.

Resultado final

Depois que ambos os conjuntos de canais inseguros de interferências vizinhas e harmônicas são calculados, o conjunto final é calculado tomando a união de ambos os conjuntos (e selecionando o limite de energia 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:

  1. Se cada canal Wi-Fi de 2,4 GHz estiver marcado como um canal não seguro, remove o canal Wi-Fi padrão de 2,4 GHz do conjunto.
  2. Se cada canal Wi-Fi de 5 GHz estiver marcado como um canal não seguro, remove o canal Wi-Fi padrão de 5 GHz do conjunto.
  3. Retorna o conjunto final de canais não seguros.

Formato da tabela de pesquisa

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

Veja a seguir 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), os intervalos de harmônicos/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 combinados. O algoritmo considera cada faixa de harmônicos/intermodulação de forma independente e faz a união dos canais inseguros retornados. Para o caso de intermodulação, isso 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 nº 46. O algoritmo trata esta banda de forma semelhante a outras bandas. Nesse caso, os canais completos 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 canal define restrições obrigatórias no SoftAP e 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 da célula estiver em LAA e restrict_5g_softap_wifi_direct_for_laa for true , o algoritmo retornará o conjunto de canais inseguros com toda a banda de 5Ghz e definirá os sinalizadores 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 tiver calculado os canais não seguros, para fornecer aos aplicativos do sistema os canais não seguros 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 e retorno de chamada WifiManager @SystemApi para permitir que os aplicativos obtenham valores atualizados quando os canais não seguros forem alterados.

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 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 API HAL 1.5::IWifiChip .

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

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

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

    1. A estrutura remove os canais inseguros da lista ACS.
    2. Se a lista estiver vazia, a estrutura para o SoftAP.
  2. Se os canais não são seguros e não há 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

  1. 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.
  2. 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 prevenção não for viável.

Wi-Fi Direto (P2P)

  1. Se houver canais inseguros com restrições de Wi-Fi Direct (P2P).

    1. A estrutura solicita wpa_supplicant para evitar os canais inseguros usando o método HAL ISupplicantP2pIface::setDisallowedFrequencies() .
  2. Se houver canais inseguros sem restrições.

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

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 da 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 seguinte API do sistema.

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 seguintes testes.

Testes CTS

  • WifiManagerTest.java

    • testCoexMethodsShouldFailNoPermission()
    • testListenOnCoexUnsafeChannels()

Testes ACTS

  • WifiManagerTest.py

    • test_set_get_coex_unsafe_channels()

Testes VTS

  • wifi_chip_hidl_test.cpp

    • TEST_P(WifiChipHidlTest, setCoexUnsafeChannels)