Évitement des canaux Wi-Fi/Cellular Coex

La fonction d'évitement des canaux coex Wi-Fi/cellulaire, introduite dans Android 12, identifie et évite d'utiliser des canaux Wi-Fi dangereux dans les cas où il pourrait y avoir des interférences depuis/vers les canaux cellulaires. Cela inclut des interfaces telles que STA, SoftAp, Wi-Fi Direct (P2P), Wi-Fi Aware (NAN).

Cette page traite des sujets suivants :

  • Informations que le modem cellulaire doit communiquer au framework Android
  • Algorithmes utilisés par le framework Wi-Fi pour calculer les canaux Wi-Fi à éviter
  • Tableaux de configuration que les fabricants d'appareils doivent fournir pour le cadre Wi-Fi
  • API système, configurations et API HAL liées à la fonctionnalité d'évitement de canal
  • Comportement du framework pour gérer l'évitement de canal
  • Comportement du fournisseur de puces pour gérer l'évitement des canaux
  • Détails de mise en œuvre pour l'évitement de canal
  • Tests de validation du comportement d'évitement de canal

Arrière-plan

Pour les appareils dotés de technologies cellulaires telles que LTE, 5G NR et Licensed Assisted Access (LAA), les canaux cellulaires utilisés peuvent interférer avec le canal Wi-Fi utilisé. Cela se produit lorsque les canaux cellulaires et Wi-Fi se trouvent dans une courte séparation de fréquence (canaux voisins) ou lorsqu'il y a des interférences harmoniques et d'intermodulation.

Ce type d'interférence devient un problème lorsqu'une antenne émet et qu'une autre reçoit en même temps. Dans ce cas, l’antenne émettrice inonde l’antenne réceptrice, impactant ainsi sa qualité de réception.

Ce document désigne l'émetteur brouilleur comme l' agresseur et le récepteur subissant l'interférence comme la victime . Le canal Wi-Fi qui est soit l'agresseur, soit la victime est qualifié de canal non sécurisé .

La fonction d'évitement de canal coex Wi-Fi/cellulaire fournit une approche cohérente pour éviter les canaux, réduisant le besoin de code propriétaire qui s'écarte du cadre Wi-Fi. De plus, la fonctionnalité permet aux fabricants d'appareils de configurer, d'activer, de désactiver et de remplacer la fonctionnalité.

La fonction évite les canaux en contrôlant les canaux Wi-Fi. Le schéma d’évitement des canaux Wi-Fi peut être décrit comme une série de quatre étapes abstraites :

  1. Le modem signale un changement de fréquence cellulaire
  2. L'algorithme d'évitement Coex calcule les canaux Wi-Fi dangereux
  3. L'algorithme d'évitement Coex informe le service Wi-Fi
  4. Le framework ou le pilote effectue l'action Wi-Fi appropriée

Schéma d'évitement des canaux

Figure 1. Schéma d'évitement des canaux

Signaler un changement de fréquence cellulaire

Le service de téléphonie signale les canaux cellulaires actuellement utilisés. Lorsque la fréquence cellulaire de fonctionnement change, le modem signale ces informations au service de téléphonie via IRadio::PhysicalChannelConfig . Ces informations comprennent des indications pour l'accès assisté sous licence (LAA) et l'agrégation de transporteurs (CA).

À partir d'Android 12, les champs suivants dans 1.6 IRadio::PhysicalChannelConfig fournissent les informations requises pour les formules coex que le modem doit remplir.

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

Calcul des canaux Wi-Fi dangereux

Lorsque le modem signale un changement dans la fréquence cellulaire, l'algorithme du canal coex calcule les interférences entre les canaux cellulaires et Wi-Fi et détermine quel ensemble de canaux Wi-Fi est dangereux.

Il existe plusieurs types d'interférences nécessitant différentes formules : voisines et harmoniques/intermodulations . En raison des différences physiques d'antenne et de disposition entre les appareils, les modèles d'interférences voisines et harmoniques/intermodulations pour chaque appareil sont différents. Pour tenir compte de cela, les fabricants d'appareils doivent fournir une table de recherche permettant d'insérer les paramètres dans des formules génériques pour les deux types d'interférences. Ces paramètres sont définis par bande cellulaire et sont référencés par les bandes des canaux cellulaires actifs.

Un plafond de puissance maximale peut être défini dans la table de recherche. Si un plafond de puissance maximum est défini, un canal non sécurisé transmet avec le plafond de puissance fourni. S'il n'y a pas de limite de puissance, le canal transmet à pleine puissance.

En général, la fonction d'évitement de canal utilise une approche au mieux pour éviter les canaux Wi-Fi dangereux afin d'optimiser les performances. Mais dans certains cas (par exemple, en raison des exigences des opérateurs), il est obligatoire pour certaines interfaces d'éviter les canaux dangereux pour certaines bandes cellulaires. Dans de tels cas, les restrictions obligatoires sont représentées sous la forme d'un masque de bits contenant des valeurs indiquant s'il faut interdire certains canaux tels que Wi-Fi Direct (P2P), SoftAp et Wi-Fi Aware (NAN). Alors qu'un canal non sécurisé agit comme une recommandation de ne pas utiliser ce canal pour tous les cas d'utilisation, les restrictions obligatoires marquent des cas d'utilisation spécifiques à éviter obligatoirement.

Si chaque canal de la bande 2,4 GHz ou 5 GHz est marqué comme dangereux, la table de recherche peut définir un canal par défaut de 2,4 GHz ou un canal par défaut de 5 GHz par bande de cellules interférentes comme choix le plus sûr. Ces canaux par défaut ne sont pas signalés comme canaux dangereux lorsque le reste de la bande est signalé comme dangereux.

Liste de remplacement

Une approche basée sur une formule est limitée dans les cas où les interférences dépendent fortement de la bande passante (et donc les canaux avec une bande passante plus grande peuvent être dangereux, mais pas les canaux avec une bande passante plus petite). Dans des cas comme celui de LAA, il est avantageux d'ignorer les calculs et d'utiliser une liste spécifiée de canaux non sécurisés.

Pour ce faire, vous pouvez spécifier une liste de remplacement de canaux non sécurisés dans la table de recherche pour certaines entrées. Une liste de remplacement dans une entrée de tableau signifie que le calcul pour ce canal cellulaire particulier est ignoré et que les canaux Wi-Fi dangereux pour le canal cellulaire correspondant sont spécifiés par la liste de remplacement.

Pour les cas sensibles à la bande passante, vous pouvez éviter sélectivement certaines bandes passantes en spécifiant certains canaux avec certaines bandes passantes dans la liste de remplacement. En effet, chaque numéro de canal Wi-Fi correspond à une bande passante spécifiée.

La liste de remplacement est représentée par une liste de numéros de canaux ou de mots-clés de catégorie prédéfinis pour chaque bande Wi-Fi :

Catégories 2g :

  • all (toute la bande 2,4 GHz)

Catégories 5g :

  • all (toute la bande 5 GHz)
  • 20mhz (canaux 5 GHz 20 MHz)
  • 40mhz (canaux 5 GHz 40 MHz)
  • 80mhz (canaux 5 GHz 80 MHz)
  • 160mhz (canaux 5 GHz 160 MHz)

Interférence du canal voisin

Pour déterminer les interférences des canaux voisins, l'algorithme d'évitement coex s'assure que la distance ΔF entre un canal agresseur et victime ne descend pas en dessous d'un seuil spécifié.

Interférence de canal

Figure 2. Distance entre un canal agresseur et victime

Le seuil est déterminé par la configuration physique du dispositif et la valeur de seuil fournie dans l'entrée de la table de recherche par bande interférente. Les bandes considérées comme non interférentes n'ont pas d'entrée dans le tableau et les canaux non sécurisés n'ont pas besoin d'être calculés (c'est la majorité du temps).

Paramètres d'interférence voisins

  • wifiVictimMhz : Seuil de distance MHz pour une victime Wi-Fi (cell uplink)
  • cellVictimMhz : seuil de distance MHz pour une cellule victime (cell downlink)

L'algorithme se comporte comme suit pour chaque canal de cellule actif :

  1. Pour la bande de la chaîne, tente de trouver une entrée de table de recherche. Si aucune entrée de table n'est trouvée, renvoie sans canaux dangereux pour ce canal de cellule.
  2. En fonction de la bande cellulaire, identifie quelle bande Wi-Fi est à risque et de quel côté de la bande provient l'interférence (par exemple, canaux inférieurs de 2,4 GHz, canaux supérieurs de 2,4 GHz, canaux inférieurs de 5 GHz).
  3. Si wifiVictimMhz est présent et que le canal cellulaire a une liaison montante et

    1. Si la partie inférieure de la bande Wi-Fi est menacée

      1. Détermine la limite supérieure des canaux dangereux en ajoutant wifiVictimMhz à la fréquence la plus élevée de la liaison montante cellulaire.
      2. Recherche le premier canal Wi-Fi 20 MHz dont le bord inférieur chevauche la limite.
      3. Marque le canal Wi-Fi, chaque canal à plus grande bande passante qui le contient (par exemple, 40 Mhz, 80 Mhz) et chaque canal inférieur de la même bande que le canal non sécurisé.
    2. Si la partie supérieure de la bande Wi-Fi est menacée

      1. Trouve la limite inférieure des canaux dangereux en soustrayant wifiVictimMhz à la fréquence la plus basse de la liaison montante cellulaire.
      2. Recherche le premier canal Wi-Fi dont le bord supérieur chevauche la limite.
      3. Marque le canal Wi-Fi, chaque canal plus grand qui le contient (par exemple, 40 M Hz, 80 Mhz) et chaque canal supérieur de la même bande que le canal non sécurisé.
  4. Si cellVictimMhz est présent et que le canal cellulaire a une liaison descendante.

    1. Effectue l'étape 3 en utilisant cellVictimMhz comme seuil et compare la liaison descendante cellulaire au lieu de la liaison montante cellulaire.
  5. Applique le plafond de puissance de l’entrée de table aux canaux non sécurisés calculés.

Calcul de canal dangereux

Figure 3. Calcul de canal non sécurisé pour les interférences de canal voisin

Distorsion harmonique/intermodulation

Pour la distorsion harmonique/intermodulation, le moteur coex calcule la plage du signal harmonique/intermodulation et évalue le pourcentage de chevauchement qu'il présente avec un canal victime potentiel. Si le chevauchement dépasse un seuil de chevauchement, l'algorithme considère qu'il s'agit d'une situation dangereuse. Le calcul du pourcentage de chevauchement de la distorsion harmonique/intermodulation sur un canal victime est effectué avec l'équation suivante :

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

Dans le cas de la distorsion harmonique, l'algorithme prend en compte la distorsion harmonique d'un canal de liaison montante cellulaire victimisant les canaux Wi-Fi. Il remplace ensuite la distorsion élevée et la distorsion faible par les valeurs harmoniques basées sur les fréquences de liaison montante des cellules et un degré harmonique $ N $.

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

Distorsion harmonique de calcul de canal dangereux

Figure 4. Calcul de canal non sécurisé pour la distorsion harmonique

Dans le cas de l'intermodulation, l'algorithme prend en compte la distorsion d'intermodulation de la liaison montante cellulaire et le canal Wi-Fi victimisant le canal de liaison descendante cellulaire. Il remplace ensuite la distorsion élevée et la distorsion faible par les valeurs d'intermodulation basées sur les fréquences de liaison montante des cellules, les fréquences Wi-Fi et les deux coefficients d'intermodulation $ M $, $ N $.

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

Distorsion d'intermodulation de calcul de canal dangereux

Figure 5. Calcul de canal non sécurisé pour la distorsion d'intermodulation

Vous pouvez spécifier $ M $, $ N $ et les valeurs de chevauchement dans la table de recherche par bande de cellules interférentes. S'il n'y a pas d'interférence pour une bande, les valeurs sont omises du tableau pour cette entrée de bande. Deux ensembles de ces valeurs pour les bandes Wi-Fi 2,4 GHz et 5 GHz peuvent être définis indépendamment.

Semblable à l’algorithme d’interférence voisine, l’algorithme réutilise la même valeur de plafond de puissance définie par bande de cellules interférentes.

L'algorithme se comporte comme suit pour chaque canal de cellule actif :

  1. Pour la bande du canal cellulaire, il essaie de trouver une entrée dans la table de recherche. Si aucune entrée de table n'est trouvée, renvoie sans canaux dangereux pour ce canal.
  2. Recherche les canaux 2,4 GHz dangereux à partir des harmoniques si les paramètres sont définis.

    1. Recherche le degré harmonique N pour 2,4 GHz.
    2. Calcule la haute fréquence harmonique et la basse fréquence harmonique en fonction de N et de la liaison montante de la cellule.
    3. Recherche le premier canal Wi-Fi de 20 MHz situé dans la limite inférieure de l'harmonique venant d'en bas.
    4. Calcule le chevauchement de l'harmonique sur le canal Wi-Fi et marque le canal comme dangereux si le chevauchement dépasse le seuil de chevauchement Wi-Fi de 2,4 GHz.
    5. Recherche le premier canal Wi-Fi de 20 MHz situé dans la limite supérieure de l'harmonique venant d'en haut.
    6. Calcule le chevauchement de l'harmonique sur le canal Wi-Fi et marque le canal comme dangereux si le chevauchement dépasse le seuil de chevauchement Wi-Fi de 2,4 GHz.
    7. Marque chaque canal de 20 MHz intermédiaire comme canal dangereux.
  3. Recherche les canaux 5 GHz dangereux à partir des harmoniques si les paramètres sont définis.

    1. Recherche le degré harmonique N pour 5 GHz. Si N est 0, passe à l’étape 5.
    2. Calcule la haute fréquence harmonique et la basse fréquence harmonique en fonction de N et de la liaison montante de la cellule.
    3. Détecte les canaux 20 MHz dangereux.

      1. Recherche le premier canal Wi-Fi de 20 MHz situé dans la limite inférieure de l'harmonique venant d'en bas.
      2. Calcule le chevauchement de l'harmonique sur le canal Wi-Fi et marque le canal comme dangereux si le chevauchement dépasse le seuil de chevauchement Wi-Fi de 2,4 GHz.
      3. Recherche le premier canal Wi-Fi de 20 MHz situé dans la limite supérieure de l'harmonique venant d'en haut.
      4. Calcule le chevauchement de l'harmonique sur le canal Wi-Fi et marque le canal comme dangereux si le chevauchement dépasse le seuil de chevauchement Wi-Fi de 2,4 GHz.
      5. Marque chaque canal de 20 MHz intermédiaire comme canal dangereux avec le plafond de puissance spécifié.
    4. Détecte les canaux dangereux de 40 MHz, 80 MHz et 160 MHz

      1. Répète l'étape 3a mais avec 40 MHz, 80 MHz, 160 MHz.
      2. Au lieu de calculer les chevauchements des canaux sur le bord harmonique, réutilise les chevauchements calculés à partir des canaux constitutifs plus petits (par exemple, si deux canaux de 20 MHz forment un canal de 40 MHz et ont un chevauchement de 30 % et 90 %, alors la moyenne est de 60 %. % de chevauchement pour le canal 40 Mhz).
  4. Recherche les canaux 2,4 GHz dangereux issus de l'intermodulation si les paramètres sont définis.

    1. Trouve les coefficients d'intermodulation N, M pour 2,4 GHz.
    2. Pour chaque canal Wi-Fi 2,4 GHz :

      1. Calcule la basse fréquence d'intermodulation et la haute fréquence d'intermodulation en fonction de N, M, de la liaison montante cellulaire et du canal Wi-Fi.
      2. Calcule le chevauchement de l'intermodulation sur la liaison descendante cellulaire et marque le canal comme dangereux si le chevauchement dépasse le seuil de chevauchement cellulaire de 2,4 GHz.
  5. Recherche les canaux 5 GHz dangereux issus de l'intermodulation si les paramètres sont définis.

    1. Répète l'étape 4 en utilisant les canaux Wi-Fi de 5 GHz et le seuil de chevauchement de cellules de 5 GHz.
  6. Applique le plafond de puissance de l’entrée de table aux canaux non sécurisés calculés.

Résultat final

Une fois que les deux ensembles de canaux dangereux dus aux interférences voisines et harmoniques ont été calculés, l'ensemble final est calculé en prenant l'union des deux ensembles (et en sélectionnant le plafond de puissance inférieur en cas de collisions) et en supprimant les canaux par défaut de l'ensemble s'il y en a. aucune restriction obligatoire n’est appliquée.

L'algorithme se comporte comme suit :

  1. Si chaque canal Wi-Fi 2,4 GHz est marqué comme canal non sécurisé, supprime le canal Wi-Fi 2,4 GHz par défaut de l'ensemble.
  2. Si chaque canal Wi-Fi 5 GHz est marqué comme canal non sécurisé, supprime le canal Wi-Fi 5 GHz par défaut de l'ensemble.
  3. Renvoie l'ensemble final de canaux non sécurisés.

Format de table de recherche

Les tables de recherche sont représentées dans un fichier XML situé dans la chaîne de configuration superposable config_wifiCoexTableFilepath et sont définies par le XSD suivant.


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

Exemple de tableau XML

Voici un exemple de table de recherche 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>

Agrégation de transporteurs

Pour l'agrégation de porteuses (CA), les plages d'harmoniques/intermodulations pour chaque liaison montante/liaison descendante peuvent ne pas produire suffisamment de chevauchement pour provoquer des interférences indépendamment, mais peuvent produire suffisamment de chevauchement lorsqu'elles sont combinées. L'algorithme considère chaque harmonique/gamme d'intermodulation indépendamment et prend l'union des canaux non sécurisés renvoyés. Pour le cas de l'intermodulation, cela signifie évaluer la plage d'intermodulation de chaque UL sur chaque DL.

L'algorithme ne fait aucune distinction entre les PCELL/PSCELL/SCELL et les traite sur un pied d'égalité.

Accès assisté par licence

L'accès assisté par licence (LAA) est identifié comme la bande n° 46. L'algorithme traite cette bande de la même manière que les autres bandes. Dans ce cas, les canaux 5 Ghz complets peuvent être définis comme liste de remplacement dans la table de recherche.

En fonction des exigences de l'opérateur, l'algorithme d'évitement de canal définit des restrictions obligatoires sur SoftAP et Wi-Fi Direct (P2P) pour l'ensemble de la bande Wi-Fi 5 GHz. Pour que l'algorithme gère ce cas d'utilisation, la valeur de configuration de l'opérateur restrict_5g_softap_wifi_direct_for_laa doit être définie. Si le canal cellulaire est sur LAA et restrict_5g_softap_wifi_direct_for_laa est true , l'algorithme renvoie l'ensemble des canaux non sécurisés avec toute la bande 5 Ghz et définit les indicateurs de restriction obligatoires pour SoftAP et Wi-Fi Direct (P2P).

Informer le service Wi-Fi

Une fois que l'algorithme de canal coex a calculé les canaux non sécurisés, pour fournir à vos applications système les canaux non sécurisés et leurs restrictions, utilisez la structure de données @SystemApi suivante définie dans le framework 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();
}

Utilisez les méthodes WifiManager @SystemApi et le rappel suivants pour permettre aux applications d'obtenir des valeurs mises à jour lorsque les canaux non sécurisés changent.

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

Effectuer une action Wi-Fi

Lorsque le service Wi-Fi reçoit des informations sur l'ensemble des canaux non sécurisés, il effectue l'action appropriée pour garantir que ces canaux sont évités. Cette section décrit le comportement du service Wi-Fi dans différents scénarios.

Informer le conducteur

Étant donné que le pilote joue un rôle majeur dans l'évitement des canaux, il est essentiel de transmettre les canaux dangereux au pilote et au micrologiciel. Pour ce faire, utilisez l'API IWifiChip HAL suivante.

Pour l’AIDL :

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

Pour HIDL (1,5 ou supérieur) :

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

SoftAP

SoftAP est le principal cas d’utilisation pour éviter les canaux dangereux. La section suivante décrit les principaux scénarios SoftAp dans lesquels l'évitement de canal peut être appliqué avec ACS. Les scénarios décrivent le comportement de l'algorithme d'évitement de canal et du pilote ou du micrologiciel.

Démarrage de SoftAP avec ACS activé (aucun SoftAP n'est encore opérationnel)

  1. Si les canaux ne sont pas sécurisés et qu'il existe une restriction SoftAP

    1. Le framework supprime les canaux non sécurisés de la liste ACS.
    2. Si la liste est vide, le framework arrête SoftAP.
  2. Si les chaînes ne sont pas sécurisées et qu'il n'y a aucune restriction

    1. Le pilote/micrologiciel du fournisseur donne la priorité aux canaux sécurisés par rapport aux canaux non sécurisés.

SoftAP est opérationnel avec ACS activé et les canaux non sécurisés sont mis à jour

  1. Si le canal SoftAP n'est pas sécurisé et qu'il existe une restriction SoftAP

    1. Le framework met à jour la liste ACS en supprimant les canaux non sécurisés.
    2. Si la liste est vide, le framework ferme SoftAP.
  2. Si le canal SoftAP n'est pas sécurisé et qu'il n'y a aucune restriction

    1. Aucune action n’est entreprise par le framework. Le pilote/micrologiciel du fournisseur gère l'évitement des canaux non sécurisés ou l'application du plafond de puissance si l'évitement n'est pas réalisable.

Wi-Fi Direct (P2P)

  1. S'il existe des chaînes non sécurisées avec des restrictions Wi-Fi Direct (P2P).

    1. Le framework demande à wpa_supplicant d'éviter les canaux non sécurisés à l'aide de la méthode HAL ISupplicantP2pIface::setDisallowedFrequencies() .
  2. S'il existe des chaînes non sécurisées sans restrictions.

    1. Le pilote/micrologiciel du fournisseur applique le plafond de puissance si un canal non sécurisé sans restriction Wi-Fi Direct (P2P) est utilisé.

Compatible Wi-Fi (NAN)

Le framework n'est pas impliqué dans la sélection des canaux pour Wi-Fi Aware (NAN) et aucune action du framework n'est prise. Le pilote/micrologiciel du fournisseur est responsable de l’évitement des canaux Wi-Fi Aware (NAN).

Désactiver l'algorithme

Si vous souhaitez désactiver l'implémentation de l'algorithme par défaut et transmettre votre propre liste de canaux dangereux à éviter, configurez la superposition config_wifiDefaultCoexAlgorithmEnabled . Si la superposition est définie sur false, l'algorithme par défaut est désactivé. Vous pouvez ensuite utiliser votre propre algorithme propriétaire hors bande pour générer une liste de canaux dangereux à relier au framework à l'aide de l'API système suivante.

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

Valider la mise en œuvre

Pour valider votre implémentation de la fonctionnalité d’évitement des canaux coex Wi-Fi/cellulaire, utilisez les tests suivants.

Essais CTS

  • WifiManagerTest.java

    • testCoexMethodsShouldFailNoPermission()
    • testListenOnCoexUnsafeChannels()

Tests ACTES

  • WifiManagerTest.py

    • test_set_get_coex_unsafe_channels()

Essais VTS

  • Si AIDL est implémenté : wifi_chip_aidl_test.cpp

    • TEST_P(WifiChipAidlTest, SetCoexUnsafeChannels)
  • Si HIDL est implémenté : wifi_chip_hidl_test.cpp

    • TEST_P(WifiChipHidlTest, setCoexUnsafeChannels)