Cette page a été traduite par l'API Cloud Translation.

Évitement des canaux coex Wi-Fi/cellulaires

La fonctionnalité d'évitement des canaux de coex Wi-Fi/mobile, introduite dans Android 12, identifie et évite d'utiliser des canaux Wi-Fi non sécurisés en cas d'interférences provenant ou vers des canaux mobiles. Cela inclut les interfaces telles que STA, SoftAp, Wi-Fi Direct (P2P) et Wi-Fi Aware (NAN).

Cette page aborde les sujets suivants:

Informations que le modem cellulaire doit transmettre au framework Android
Algorithmes utilisés par le framework Wi-Fi pour calculer les canaux Wi-Fi à éviter
Tables de configuration que les fabricants d'appareils doivent fournir pour le framework Wi-Fi
API système, configurations et API HAL liées à la fonctionnalité d'évitement de canaux
Comportement du framework pour gérer l'évitement de canaux
Comportement des fournisseurs de chips pour gérer l'évitement de canaux
Détails d'implémentation de l'évitement de canaux
Tests de validation du comportement d'évitement des canaux

Arrière-plan

Pour les appareils équipés de technologies mobiles telles que la connectivité LTE, la connectivité 5G NR et l'accès assisté sous licence (LAA), les canaux cellulaires utilisés peuvent interférer avec le canal Wi-Fi en cours d'utilisation. Cela se produit lorsque les canaux mobiles et Wi-Fi se trouvent dans une courte plage de fréquences (canaux voisins) ou en cas d'interférences harmoniques et d'intermodulation.

Ce type d'interférence devient un problème lorsqu'une antenne transmet et qu'une autre reçoit en même temps. Dans ce cas, l'antenne de transmission inonde l'antenne de réception, ce qui affecte sa qualité de réception.

Dans ce document, l'émetteur générant des interférences est appelé agresseur, et le récepteur qui en souffre est appelé victime. Le canal Wi-Fi qui est à la fois l'agresseur et la victime est appelé canal non sécurisé.

La fonctionnalité d'évitement des canaux coex Wi-Fi/cellulaires offre une approche cohérente qui réduit le besoin de code propriétaire qui diffère du framework Wi-Fi. De plus, cette fonctionnalité permet aux fabricants d'appareils de la configurer, de l'activer, de la désactiver et de l'ignorer.

Cette fonctionnalité é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:

Le modem signale un changement de fréquence cellulaire
L'algorithme d'évitement de la coexistence calcule les canaux Wi-Fi non sécurisés
L'algorithme d'évitement de la coexistence informe le service Wi-Fi
Le framework ou le pilote effectue l'action Wi-Fi appropriée

Système d'évitement de chaîne

Figure 1 : Méthode d'évitement des canaux

Signaler une modification de la fréquence mobile

Le service de téléphonie indique les canaux mobiles actuellement utilisés. Lorsque la fréquence de fonctionnement de la téléphonie mobile change, le modem transmet ces informations au service de téléphonie via IRadio::PhysicalChannelConfig. Ces informations incluent des indications concernant l'accès assisté sous licence (LAA) et l'agrégation par opérateur.

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

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

Calculer les canaux Wi-Fi non sécurisés

Lorsque le modem signale un changement de fréquence cellulaire, l'algorithme de canal de coexistence calcule les interférences entre les canaux de téléphonie mobile et les canaux Wi-Fi, et détermine l'ensemble de canaux Wi-Fi non sécurisés.

Il existe plusieurs types d'interférences qui nécessitent des formules différentes : interférences de voisinage et interférences harmoniques/intermodulation. En raison des différences physiques de l'antenne et de la mise en page entre les appareils, les schémas d'interférences voisines et harmoniques/d'intermodulation pour chaque appareil sont différents. Pour tenir compte de cela, les fabricants d'appareils doivent fournir un tableau de conversion permettant de brancher les paramètres dans des formules génériques pour les deux types d'interférences. Ces paramètres sont définis par bande de cellules et sont référencés par les bandes des canaux de cellules actifs.

Vous pouvez définir une limite de puissance maximale dans la table de recherche. Si un plafond de puissance maximal est défini, un canal non sécurisé transmet avec le plafond de puissance fourni. S'il n'y a pas de plafond de puissance, le canal transmet à pleine puissance.

En général, la fonctionnalité d'évitement de canaux s'efforce d'éviter les canaux Wi-Fi non sécurisés afin d'optimiser les performances. Toutefois, dans certains cas (par exemple, en raison des exigences de l'opérateur), il est obligatoire pour certaines interfaces d'éviter les canaux non sécurisés pour certaines bandes de téléphonie mobile. Dans ce cas, les restrictions obligatoires sont représentées sous la forme d'un masque de bits contenant des valeurs indiquant si certaines canaux doivent être interdits, comme Wi-Fi Direct (P2P), SoftAp et Wi-Fi Aware (NAN). Alors qu'un canal non sécurisé sert de recommandation contre l'utilisation de ce canal pour tous les cas d'utilisation, les restrictions obligatoires marquent des cas d'utilisation spécifiques à éviter.

Si tous les canaux de la bande 2,4 GHz ou 5 GHz sont marqués comme non sécurisés, la table de recherche peut définir un canal 2,4 GHz ou 5 GHz par défaut par bande de cellule interférente comme étant le choix le plus sûr. Ces canaux par défaut ne sont pas signalés comme non sécurisés lorsque le reste de la bande est signalé comme non sécurisé.

Liste de forçages

Une approche formulée est limitée dans les cas où les interférences dépendent fortement de la bande passante (et donc que les canaux à bande passante plus élevée peuvent être dangereux, mais pas les canaux à bande passante plus faible). Dans certains cas, comme avec LAA, il est préférable 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 forçage de canaux non sécurisés dans le tableau de recherche pour certaines entrées. Une liste de remplacement dans une entrée de table signifie que le calcul pour ce canal de cellule spécifique est ignoré et que les canaux Wi-Fi non sécurisés du canal de cellule correspondant sont spécifiés par la liste de remplacement.

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

La liste de forçage 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 de 2 g:

all (bande 2,4 GHz complète)

Catégories 5G:

all (bande 5 GHz complète)
20mhz (canaux 20 MHz 5 GHz)
40mhz (canaux 40 MHz 5 GHz)
80mhz (canaux 80 MHz 5 GHz)
160mhz (canaux 160 MHz 5 GHz)

Interférences sur les canaux voisins

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

Interférences sur le canal

Figure 2. Distance entre le canal de l'agresseur et celui de la victime

Le seuil est déterminé par la configuration physique de l'appareil 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 le cas la plupart du temps).

Paramètres d'interférences entre canaux voisins

wifiVictimMhz: seuil de distance en MHz pour une victime Wi-Fi (liaison montante cellulaire)
cellVictimMhz: seuil de distance en MHz pour une victime de cellule (liaison descendante de la cellule)

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

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, la fonction renvoie un résultat sans canal non sécurisé pour ce canal de cellule.
En fonction de la bande de téléphonie mobile, identifie la bande Wi-Fi à risque et le côté de la bande d'où proviennent les interférences (par exemple, canaux 2,4 GHz inférieurs, canaux 2,4 GHz supérieurs, canaux 5 GHz inférieurs).
Si wifiVictimMhz est présent et que le canal de la cellule dispose d'une liaison montante et
1. Si la partie inférieure de la bande Wi-Fi est à risque
  1. Détermine la limite supérieure des canaux non sécurisés en ajoutant wifiVictimMhz à la fréquence la plus élevée de l'encapsulation montante de la cellule.
  2. Recherche le premier canal Wi-Fi 20 MHz dont le bord inférieur chevauche la limite.
  3. Marquez le canal Wi-Fi, chaque canal à bande passante plus élevée 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 à risque
  1. Trouve la limite inférieure des canaux non sécurisés en soustrayant wifiVictimMhz à la fréquence la plus basse de l'accès cellulaire.
  2. Recherche le premier canal Wi-Fi dont le bord supérieur chevauche la limite.
  3. Marquez le canal Wi-Fi, chaque canal plus élevé qui le contient (par exemple, 40 MHz, 80 MHz) et chaque canal supérieur de la même bande que le canal non sécurisé.
Si cellVictimMhz est présent et que le canal cellulaire comporte une liaison descendante.
1. Effectue l'étape 3 en utilisant cellVictimMhz comme seuil et effectue une comparaison avec la liaison descendante de cellule au lieu de la liaison montante de cellule.
Applique la limite de puissance de l'entrée de la table aux canaux non sécurisés calculés.

Calcul du canal non sécurisé

Figure 3. Calcul de canaux non sécurisés en cas d'interférences avec les canaux voisins

Distorsion harmonique ou intermodulation

Pour la distorsion harmonique ou l'intermodulation, le moteur de coex calcule la plage du signal harmonique ou de l'intermodulation, puis évalue le pourcentage de chevauchement avec un canal victime potentiel. Si le chevauchement dépasse un seuil, l'algorithme considère la situation comme dangereuse. Le calcul du pourcentage de chevauchement de la distorsion harmonique ou de l'intermodulation sur un canal victime est effectué à l'aide de 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 qui affecte les canaux Wi-Fi. Il remplace ensuite la distorsion haute et la distorsion basse par les valeurs harmoniques en fonction des fréquences de liaison montante de la cellule et d'un degré harmonique $ N $.

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

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

Distorsion harmonique du calcul des canaux à risque

Figure 4. Calcul des canaux 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 du canal Wi-Fi victime du canal de liaison descendante cellulaire. Il remplace ensuite la distorsion élevée et la distorsion basse par des 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 de l'intermodulation due au calcul de canaux non sécurisés

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

Vous pouvez spécifier $ M $, $ N $ et des valeurs de chevauchement dans la table de conversion par bande de cellule interférante. S'il n'y a pas d'interférence pour une bande, les valeurs sont omises de la table 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.

Comme pour l'algorithme d'interférences entre cellules voisines, l'algorithme réutilise la même valeur de limite de puissance définie par bande de cellules interférentes.

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

Pour la bande du canal de la cellule, il tente de trouver une entrée de table de recherche. Si aucune entrée de table n'est trouvée, aucun canal dangereux n'est renvoyé pour cette chaîne.
Recherche les canaux 2,4 GHz non sécurisés à partir des harmoniques si des paramètres sont définis.
1. Détermine le degré harmonique N pour 2,4 GHz.
2. Calcule la haute fréquence harmonique et la basse fréquence harmonique basée sur N et la liaison montante des cellules.
3. Recherche le premier canal Wi-Fi 20 MHz qui se trouve dans la limite inférieure de l'harmonique provenant d'en dessous.
4. Calcule la superposition de l'harmonique sur le canal Wi-Fi et marque le canal comme non sécurisé si la superposition dépasse le seuil de superposition du Wi-Fi 2,4 GHz.
5. Recherche le premier canal Wi-Fi 20 MHz qui se trouve dans la limite supérieure de l'harmonique provenant d'en haut.
6. Calcule la superposition de l'harmonique sur le canal Wi-Fi et marque le canal comme non sécurisé si la superposition dépasse le seuil de superposition du Wi-Fi 2,4 GHz.
7. Marque chaque canal de 20 MHz entre les deux comme canal non sécurisé.
Détecte les canaux 5 GHz non sécurisés à partir des harmoniques si des paramètres sont définis.
1. Détermine le degré harmonique N pour 5 GHz. Si N est 0, passe à l'étape 5.
2. Calcule la fréquence haute harmonique et la fréquence basse harmonique en fonction de N et de l'enlacement ascendant de la cellule.
3. Recherche les canaux 20 MHz non sécurisés.
  1. Recherche le premier canal Wi-Fi 20 MHz qui se trouve dans la limite inférieure de l'harmonique provenant d'en dessous.
  2. Calcule la superposition de l'harmonique sur le canal Wi-Fi et marque le canal comme non sécurisé si la superposition dépasse le seuil de superposition du Wi-Fi 2,4 GHz.
  3. Recherche le premier canal Wi-Fi 20 MHz qui se trouve dans la limite supérieure de l'harmonique venant d'en haut.
  4. Calcule la superposition de l'harmonique sur le canal Wi-Fi et marque le canal comme non sécurisé si la superposition dépasse le seuil de superposition du Wi-Fi 2,4 GHz.
  5. Marque chaque canal de 20 MHz entre les deux comme un canal non sécurisé avec la limite de puissance spécifiée.
4. Détecte les canaux 40 MHz, 80 MHz et 160 MHz non sécurisés
  1. Répète l'étape 3a, mais avec 40 MHz, 80 MHz et 160 MHz.
  2. Au lieu de calculer les chevauchements des canaux sur le bord harmonique, réutilise les chevauchements calculés des canaux constituants plus petits (par exemple, si deux canaux 20 MHz constituent un canal 40 MHz et ont un chevauchement de 30% et 90 %, la moyenne est de 60% de chevauchement pour le canal 40 MHz).
Recherche les canaux 2,4 GHz non sécurisés à partir de l'intermodulation si des paramètres sont définis.
1. Détermine les coefficients d'intermodulation N et M pour la bande 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 l'uplink cellulaire et du canal Wi-Fi.
  2. Calcule le chevauchement de l'intermodulation sur la liaison descendante de la cellule et marque le canal comme non sécurisé si le chevauchement dépasse le seuil de chevauchement de cellule 2,4 GHz.
Détecte les canaux 5 GHz non sécurisés en raison de l'intermodulation si des paramètres sont définis.
1. Répéte l'étape 4 à l'aide des canaux Wi-Fi 5 GHz et du seuil de chevauchement de cellules 5 GHz.
Applique la limite de puissance de l'entrée de la table aux canaux non sécurisés calculés.

Résultat final

Une fois les deux ensembles de canaux non sécurisés en raison des interférences des canaux voisins et des harmoniques calculés, l'ensemble final est calculé en prenant l'union des deux ensembles (et en sélectionnant la limite de puissance inférieure en cas de collision), puis en supprimant les canaux par défaut de l'ensemble si aucune restriction obligatoire n'est appliquée.

L'algorithme se comporte comme suit:

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

Format du tableau de conversion

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 fichier 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 tableau de conversion 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 plusieurs opérateurs

Pour l'agrégation de porteuses (CA), les plages d'harmoniques ou d'intermodulation pour chaque liaison montante ou 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 plage harmonique ou d'intermodulation indépendamment et prend l'union des canaux non sécurisés renvoyés. Dans 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 PCELL, PSCELL ou SCELL et les traite comme des éléments égaux.

Licence d'accès assisté

L'accès assisté par licence (LAA) est identifié comme la bande 46. L'algorithme traite cette bande de manière similaire aux autres bandes. Dans ce cas, les canaux 5 GHz complets peuvent être définis en tant que liste de forçage dans le tableau 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 du transporteur restrict_5g_softap_wifi_direct_for_laa doit être définie. Si le canal de la cellule est sur LAA et que restrict_5g_softap_wifi_direct_for_laa est true, l'algorithme renvoie l'ensemble des canaux non sécurisés avec l'ensemble de 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 de coexistence a calculé les canaux non sécurisés, utilisez la structure de données @SystemApi suivante définie dans le framework Android pour fournir à vos applications système les canaux non sécurisés et leurs restrictions.

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 et le rappel WifiManager @SystemApi 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 de canaux non sécurisés, il effectue l'action appropriée pour s'assurer 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 non sécurisés au pilote et au micrologiciel. Pour ce faire, utilisez l'API HAL IWifiChip suivante.

Pour AIDL:

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

Pour HIDL (1.5 ou version ultérieure):

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

SoftAP

Le SoftAP est le principal cas d'utilisation de l'évitement des canaux non sécurisés. La section suivante décrit les principaux scénarios SoftAp où l'évitement de canaux 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émarrer SoftAP avec ACS activé (aucun SoftAP n'est encore activé)

Si les canaux ne sont pas sécurisés et qu'une restriction SoftAP s'applique
1. Le framework supprime les chaînes non sécurisées de la liste ACS.
2. Si la liste est vide, le framework arrête le SoftAP.
Si les chaînes sont dangereuses et qu'aucune restriction ne s'applique
1. Le pilote ou le micrologiciel du fournisseur donne la priorité aux canaux sécurisés par rapport aux canaux non sécurisés.

Le point d'accès logiciel est activé avec l'ACS et les canaux non sécurisés sont mis à jour

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 le SoftAP.
Si le canal SoftAP est dangereux et qu'il n'y a pas de restrictions
1. Aucune action n'est effectuée par le framework. Le pilote ou le micrologiciel du fournisseur gère l'évitement des canaux dangereux ou l'application de la limite de puissance si l'évitement n'est pas possible.

Wi-Fi Direct (P2P)

Si des chaînes non sécurisées sont associées à 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().
Si des canaux dangereux ne sont pas soumis à des restrictions.
1. Le pilote ou le micrologiciel du fournisseur applique la limite de puissance si un canal non sécurisé sans restriction Wi-Fi Direct (P2P) est utilisé.

Wi-Fi Aware (NAN)

Le framework n'est pas impliqué dans la sélection de canaux pour Wi-Fi Aware (NAN), et aucune action de framework n'est effectuée. Le pilote ou le micrologiciel du fournisseur est responsable de l'évitement du canal 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 non sécurisés à des fins d'évitement, 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 non sécurisés à connecter au framework à l'aide de l'API système suivante.

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

Valider l'implémentation

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

Tests CTS

WifiManagerTest.java
- testCoexMethodsShouldFailNoPermission()
- testListenOnCoexUnsafeChannels()

Tests ACTS

WifiManagerTest.py
- test_set_get_coex_unsafe_channels()

Tests 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)