Évitement des canaux Wi-Fi/Cellular Coex

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

La fonction d'évitement des canaux coex Wi-Fi/cellulaires, 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 éléments suivants :

  • Informations que le modem cellulaire doit rapporter 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 fonction d'évitement de canal
  • Comportement du cadre pour la gestion de l'évitement de canal
  • Comportement du fournisseur de puces pour gérer l'évitement de canal
  • Détails de mise en œuvre pour l'évitement des canaux
  • 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 d'émission inonde l'antenne de réception, impactant sa qualité de réception.

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

La fonction d'évitement de canal coex Wi-Fi/cellulaire fournit une approche cohérente pour l'évitement de canal réduisant le besoin d'un code propriétaire qui diverge du cadre Wi-Fi. De plus, la fonctionnalité permet aux fabricants d'appareils de configurer, d'activer et 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 de canal 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 de canal

Figure 1. Schéma d'évitement de canal

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 cette information 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 porteuses (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 non sécurisés

Lorsque le modem signale un changement de fréquence cellulaire, l'algorithme de canal coex calcule l'interférence 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 : voisinage et harmonique/intermodulation . En raison des différences physiques d'antenne et de disposition entre les appareils, les schémas d'interférence de voisinage et d'harmonique/d'intermodulation pour chaque appareil sont différents. Pour tenir compte de cela, les fabricants d'appareils doivent fournir une table de correspondance pour insérer des paramètres dans des formules génériques pour les deux types d'interférences. Ces paramètres sont définis par bande de cellule et sont référencés par les bandes des canaux de cellule actifs.

Un plafond de puissance maximum 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 plafond de puissance, le canal transmet à pleine puissance.

En général, la fonction d'évitement de canal utilise une approche optimale 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 contre l'utilisation de ce canal pour tous les cas d'utilisation, les restrictions obligatoires marquent des cas d'utilisation spécifiques pour un évitement obligatoire.

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 2,4 GHz par défaut ou un canal 5 GHz par défaut par bande de cellules interférentes comme le choix le plus sûr. Ces canaux par défaut ne sont pas signalés comme des canaux non sécurisés lorsque le reste de la bande est signalé comme non sécurisé.

Remplacer la liste

Une approche basée sur des formules est limitée dans les cas où les interférences dépendent fortement de la bande passante (et donc les canaux avec une plus grande bande passante peuvent être dangereux mais pas les canaux avec une plus petite bande passante). Dans certains cas, comme avec 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 prioritaire 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 non sécurisés pour le canal cellulaire 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 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 l'interférence du canal voisin, l'algorithme d'évitement de coex 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érence de canal

Figure 2. Distance entre un agresseur et un canal 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 consultation par bande interférente. Les bandes considérées comme non interférentes n'ont pas d'entrée de table et les canaux non sûrs n'ont pas besoin d'être calculés (c'est la plupart du temps).

Paramètres d'interférence voisins

  • wifiVictimMhz : Seuil de distance en MHz pour une victime Wi-Fi (liaison montante cellulaire)
  • cellVictimMhz : Seuil de distance en MHz pour une cellule victime (cell downlink)

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

  1. Pour la bande du canal, essaie de trouver une entrée de table de recherche. Si aucune entrée de table n'est trouvée, renvoie sans aucun canal non sécurisé pour ce canal de cellule.
  2. Basé sur 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 2,4 GHz inférieurs, canaux 2,4 GHz supérieurs, canaux 5 GHz inférieurs).
  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 à risque

      1. Trouve la limite supérieure des canaux non sécurisés en ajoutant wifiVictimMhz à la fréquence la plus élevée de la liaison montante cellulaire.
      2. Trouve le premier canal Wi-Fi 20Mhz dont le bord inférieur chevauche la limite.
      3. Marque le canal Wi-Fi, chaque canal à large 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 à risque

      1. Trouve la limite inférieure des canaux non sécurisés en soustrayant wifiVictimMhz à la fréquence la plus basse de la liaison montante cellulaire.
      2. Trouve 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 Mhz, 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 avec 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 du canal non sécurisé

Figure 3. Calcul du canal non sécurisé pour les interférences du 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 a 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 considère la distorsion harmonique d'un canal de liaison montante cellulaire victimisant les canaux Wi-Fi. Il remplace ensuite la distorsion haute et la distorsion basse 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 non sécurisé

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

Dans le cas de l'intermodulation, l'algorithme considère la distorsion d'intermodulation de la liaison montante de la cellule et du canal Wi-Fi qui victimise le canal de liaison descendante de la cellule. Il remplace ensuite la distorsion haute et la distorsion basse 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 du 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 de voisinage, 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 cellulaire actif :

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

    1. Trouve 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. Trouve le premier canal Wi-Fi de 20 MHz qui se trouve 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. Trouve le premier canal Wi-Fi de 20 MHz qui se trouve 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 entre les canaux comme un canal non sécurisé.
  3. Trouve les canaux 5 GHz dangereux à partir des harmoniques si des paramètres sont définis.

    1. Trouve le degré harmonique N pour 5GHz. 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. Trouve les canaux 20Mhz dangereux.

      1. Trouve le premier canal Wi-Fi de 20 MHz qui se trouve 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. Trouve le premier canal Wi-Fi de 20 MHz qui se trouve 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 entre les canaux comme un canal non sécurisé avec le plafond de puissance spécifié.
    4. Détecte les canaux dangereux de 40 MHz, 80 MHz et 160 MHz

      1. Répétez l'étape 3a mais avec 40MHz, 80MHz, 160MHz.
      2. Au lieu de calculer les chevauchements des canaux sur le bord harmonique, réutilise les chevauchements calculés 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 40Mhz).
  4. Trouve les canaux 2,4 GHz non sécurisés à partir de l'intermodulation si des 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 des cellules et marque le canal comme dangereux si le chevauchement dépasse le seuil de chevauchement des cellules de 2,4 GHz.
  5. Trouve les canaux 5 GHz non sécurisés à partir de l'intermodulation si des paramètres sont définis.

    1. Répétez l'étape 4 en utilisant les canaux Wi-Fi 5 GHz et le seuil de chevauchement des cellules 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 non sécurisés contre les 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 s'il y a des collisions) et en supprimant les canaux par défaut de l'ensemble s'il y en a. aucune restriction obligatoire 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 le dernier ensemble 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 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/d'intermodulation 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 plage harmonique/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/SCELL et les traite comme égaux.

Accès assisté par licence

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

Selon les 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 drapeaux 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 et le rappel WifiManager 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 exécute 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 dangereux au pilote et au micrologiciel. Pour ce faire, utilisez l'API HAL 1.5::IWifiChip .

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

SoftAP

SoftAP est le principal cas d'utilisation pour éviter les canaux non sécurisés. La section suivante décrit les principaux scénarios SoftAp où 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 activé)

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

    1. La structure 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 canaux ne sont pas sûrs et qu'il n'y a pas de restrictions

    1. Le pilote/micrologiciel du fournisseur donne la priorité aux canaux sûrs sur les canaux non sûrs.

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

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

    1. La structure 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ûr et qu'il n'y a pas de restrictions

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

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 canaux non sécurisés 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 cadre n'est pas impliqué dans la sélection des canaux pour Wi-Fi Aware (NAN) et aucune action de cadre n'est entreprise. Le pilote/micrologiciel du fournisseur est responsable de l'évitement des canaux Wi-Fi Aware (NAN).

Désactivation de 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 à é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 non sécurisés à connecter au framework à l'aide de l'API système suivante.

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

Validation de la mise en œuvre

Pour valider votre mise en œuvre de la fonctionnalité d'évitement de canal coex Wi-Fi/cellulaire, utilisez les tests suivants.

Essais CTS

  • WifiManagerTest.java

    • testCoexMethodsShouldFailNoPermission()
    • testListenOnCoexUnsafeChannels()

Essais ACTS

  • WifiManagerTest.py

    • test_set_get_coex_unsafe_channels()

Essais VTS

  • wifi_chip_hidl_test.cpp

    • TEST_P(WifiChipHidlTest, setCoexUnsafeChannels)