À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

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

Évitement des canaux de coexistence Wi-Fi/mobile

La fonctionnalité d'évitement des canaux de coexistence Wi-Fi/réseau mobile, introduite dans Android 12, identifie et évite d'utiliser des canaux Wi-Fi non sécurisés dans les cas où il pourrait y avoir des interférences avec ou depuis les canaux mobiles. Cela inclut les interfaces telles que STA, SoftAp, Wi-Fi Direct (P2P) et Wi-Fi Aware (NAN).

Cette page aborde les points 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 des chaînes
Comportement du framework pour la gestion de l'évitement de canaux
Comportement du fournisseur de puces pour la gestion de l'évitement de canaux
Détails d'implémentation pour l'évitement de canaux
Tests pour valider le comportement d'évitement des chaînes

Arrière-plan

Pour les appareils dotés de technologies cellulaires telles que LTE, 5G NR et LAA (Licensed Assisted Access), les canaux cellulaires utilisés peuvent interférer avec le canal Wi-Fi utilisé. Cela se produit lorsque les canaux cellulaires et Wi-Fi sont très proches en termes de fréquence (canaux voisins) ou en cas d'interférences harmoniques et d'intermodulation.

Ce type d'interférence devient problématique 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, ce qui a un impact sur la qualité de la réception.

Dans ce document, l'émetteur qui provoque des interférences est appelé agresseur et le récepteur qui subit les interférences est appelé victime. Le canal Wi-Fi qui est l'agresseur ou la victime est appelé canal non sécurisé.

La fonctionnalité d'évitement des canaux de coexistence Wi-Fi/réseau mobile fournit une approche cohérente pour l'évitement des canaux, ce qui réduit le besoin de code propriétaire qui s'écarte 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 la remplacer.

Cette fonctionnalité permet d'éviter 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 :

Les rapports du modem indiquent 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 des interférences informe le service Wi-Fi
Le framework ou le pilote effectue l'action Wi-Fi appropriée.

Mécanisme d'évitement des canaux

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

Signaler une modification de la fréquence cellulaire

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

À partir d'Android 12, les champs suivants dans 1.6 IRadio::PhysicalChannelConfig fournissent les informations requises pour les formules de coexistence 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;
}

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

Lorsque le modem signale un changement de fréquence cellulaire, l'algorithme du canal de coexistence calcule les interférences entre les canaux cellulaires et Wi-Fi, et détermine l'ensemble des canaux Wi-Fi qui ne sont pas sûrs.

Il existe plusieurs types d'interférences qui nécessitent des formules différentes : voisines et harmoniques/d'intermodulation. En raison des différences physiques d'antenne et de disposition entre les appareils, les schémas d'interférences harmoniques/d'intermodulation et de canaux adjacents sont différents pour chaque appareil. Pour tenir compte de cela, les fabricants d'appareils doivent fournir une table de consultation permettant d'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 cellules et sont référencés par les bandes des canaux de cellules actifs.

Un plafond de puissance maximal peut être défini dans la table de référence. Si une limite de puissance maximale est définie, un canal non sécurisé transmet avec la limite de puissance fournie. S'il n'y a pas de limite de puissance, le canal transmet à pleine puissance.

En général, la fonctionnalité d'évitement des canaux utilise une approche au mieux pour éviter les canaux Wi-Fi non sécurisés afin d'optimiser les performances. Toutefois, dans certains cas (par exemple, en raison des exigences des opérateurs), il est obligatoire pour certaines interfaces d'éviter les canaux non sécurisés pour certaines bandes cellulaires. Dans ce 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é 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 pour l'évitement obligatoire.

Si tous les canaux de la bande de fréquences 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 par défaut ou un canal 5 GHz par défaut par bande de fréquences de cellule interférente comme étant le choix le plus sûr. Ces chaînes par défaut ne sont pas signalées comme non sécurisées lorsque le reste du groupe est signalé comme non sécurisé.

Liste des remplacements

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 où, par conséquent, les canaux à bande passante plus large peuvent être dangereux, mais pas ceux à bande passante plus étroite). Dans certains cas, comme avec LAA, il est préférable d'ignorer les calculs et d'utiliser une liste spécifique de canaux non sécurisés.

Pour ce faire, vous pouvez spécifier une liste de remplacement des chaînes non fiables dans la table de recherche pour certaines entrées. Une liste de remplacement dans une entrée de tableau signifie que le calcul du canal de cellule spécifique est ignoré et que les canaux Wi-Fi non sécurisés pour le canal de cellule 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écifique.

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 de la 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érences de canaux voisins

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

Interférences de canal

Figure 2. Distance entre la chaîne de l'agresseur et celle de la victime

Le seuil est déterminé par la configuration physique de l'appareil et par la valeur de seuil fournie dans l'entrée de la table de recherche pour chaque bande d'interférence. Les bandes considérées comme non interférentes ne comportent 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érence voisine

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

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

Pour la bande du canal, tente de trouver une entrée dans la table de recherche. Si aucune entrée de tableau n'est trouvée, la fonction renvoie une réponse sans canaux non sécurisés pour le canal de cellule.
En fonction de la bande cellulaire, identifie la bande Wi-Fi à risque et le côté de la bande d'où proviennent les interférences (par exemple, les canaux 2,4 GHz inférieurs, les canaux 2,4 GHz supérieurs, les canaux 5 GHz inférieurs).
Si wifiVictimMhz est présent et que le canal cellulaire dispose d'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 de la cellule.
  2. Recherche le premier canal Wi-Fi de 20 MHz dont la limite inférieure chevauche la limite.
  3. Marque le canal Wi-Fi, tous les canaux de bande passante plus importants qui le contiennent (par exemple, 40 MHz, 80 MHz) et tous les canaux inférieurs 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 de la cellule.
  2. Recherche le premier canal Wi-Fi dont la limite supérieure chevauche la limite.
  3. Marque le canal Wi-Fi, tous les canaux plus larges qui le contiennent (par exemple, 40 MHz, 80 MHz) et tous les canaux supérieurs de la même bande que le canal non sécurisé.
Si cellVictimMhz est présent et que le canal cellulaire dispose d'une liaison descendante.
1. Effectue l'étape 3 en utilisant cellVictimMhz comme seuil et en comparant au downlink cellulaire au lieu de l'uplink cellulaire.
Applique la limite de puissance de l'entrée de tableau aux canaux dangereux calculés.

Calcul des chaînes non sécurisées

Figure 3. Calcul des canaux non sécurisés pour les interférences entre canaux voisins

Distorsion harmonique ou d'intermodulation

Pour la distorsion harmonique ou d'intermodulation, le moteur de coexistence calcule la plage du signal harmonique ou d'intermodulation et évalue le pourcentage de chevauchement avec un canal victime potentiel. Si le chevauchement dépasse un seuil, l'algorithme considère qu'il s'agit d'une situation dangereuse. Le calcul du pourcentage de chevauchement de la distorsion harmonique ou d'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 tient compte de la distorsion harmonique d'un canal de liaison montante de cellule qui perturbe les canaux Wi-Fi. Il substitue ensuite les valeurs de distorsion haute et 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 de calcul de canal non sécurisée

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

Dans le cas de l'intermodulation, l'algorithme tient compte de la distorsion d'intermodulation de la liaison montante de la cellule et du canal Wi-Fi qui perturbe le canal de liaison descendante de la cellule. Il remplace ensuite les valeurs de distorsion haute et basse par les valeurs d'intermodulation en fonction des fréquences de liaison montante des cellules, des fréquences Wi-Fi et des deux coefficients d'intermodulation $ M $ et $ N $.

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

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

Calcul de la distorsion d'intermodulation des canaux non sécurisés

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

Vous pouvez spécifier les valeurs de $ M $, $ N $ et de chevauchement dans la table de recherche par bande de cellule d'interférence. Si aucune interférence n'est détectée 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.

Comme l'algorithme d'interférence voisine, l'algorithme réutilise la même valeur de limite de puissance définie par bande de cellule interférente.

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

Pour la bande du canal cellulaire, il tente de trouver une entrée dans la table de recherche. Si aucune entrée de table n'est trouvée, la fonction renvoie une réponse sans chaîne non sécurisée 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. Trouve le degré harmonique N pour 2,4 GHz.
2. Calcule la fréquence harmonique élevée et la fréquence harmonique basse 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 provenant du dessous.
4. Calcule le chevauchement de l'harmonique sur le canal Wi-Fi et marque le canal comme non sécurisé si le chevauchement dépasse le seuil de chevauchement Wi-Fi 2,4 GHz.
5. Recherche le premier canal Wi-Fi de 20 MHz qui se trouve dans la limite supérieure de l'harmonique provenant du dessus.
6. Calcule le chevauchement de l'harmonique sur le canal Wi-Fi et marque le canal comme non sécurisé si le chevauchement dépasse le seuil de chevauchement Wi-Fi 2,4 GHz.
7. Marque tous les canaux de 20 MHz intermédiaires comme canaux non sécurisés.
Recherche les canaux 5 GHz non sécurisés à partir des harmoniques si des paramètres sont définis.
1. Trouve le degré harmonique N pour 5 GHz. Si N est égal à 0, passez à l'étape 5.
2. Calcule la fréquence harmonique élevée et la fréquence harmonique basse en fonction de N et de la liaison montante de la cellule.
3. Détecte les canaux de 20 MHz non sécurisés.
  1. Trouve le premier canal Wi-Fi de 20 MHz qui se trouve dans la limite inférieure de l'harmonique provenant d'en dessous.
  2. Calcule le chevauchement de l'harmonique sur le canal Wi-Fi et marque le canal comme non sécurisé si le chevauchement dépasse le seuil de chevauchement Wi-Fi 2,4 GHz.
  3. Recherche le premier canal Wi-Fi de 20 MHz qui se trouve dans la limite supérieure de l'harmonique provenant du dessus.
  4. Calcule le chevauchement de l'harmonique sur le canal Wi-Fi et marque le canal comme non sécurisé si le chevauchement dépasse le seuil de chevauchement Wi-Fi 2,4 GHz.
  5. Marque chaque canal de 20 MHz intermédiaire comme 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étez 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 à 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 de 90 %, la moyenne est de 60 % de chevauchement pour le canal de 40 MHz).
Recherche 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 et M pour 2, 4 GHz.
2. Pour chaque canal Wi-Fi 2,4 GHz :
  1. Calcule les basses et hautes fréquences d'intermodulation en fonction des canaux N, M, de liaison montante cellulaire et 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 la cellule de 2,4 GHz.
Recherche les canaux 5 GHz non sécurisés à partir de l'intermodulation si des paramètres sont définis.
1. Répète l'étape 4 en utilisant les canaux Wi-Fi 5 GHz et le seuil de chevauchement des cellules 5 GHz.
Applique la limite de puissance de l'entrée de tableau aux canaux dangereux calculés.

Résultat final

Une fois les deux ensembles de canaux non sécurisés calculés (interférences harmoniques et avec les canaux voisins), 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 collisions), et 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 non sécurisés, le canal Wi-Fi 2,4 GHz par défaut est supprimé de l'ensemble.
Si tous les canaux Wi-Fi 5 GHz sont marqués comme non sécurisés, le canal Wi-Fi 5 GHz par défaut est supprimé de l'ensemble.
Renvoie l'ensemble final des chaînes dangereuses.

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 correspondance 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 porteuses

Pour l'agrégation d'opérateurs (CA), les plages harmoniques ou d'intermodulation pour chaque liaison montante ou descendante peuvent ne pas produire suffisamment de chevauchement pour provoquer des interférences de manière indépendante, mais peuvent produire suffisamment de chevauchement lorsqu'elles sont combinées. L'algorithme examine chaque plage d'harmoniques ou d'intermodulation de manière indépendante et prend en compte 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 liaison montante sur chaque liaison descendante.

L'algorithme ne fait aucune distinction entre PCELL, PSCELL ou SCELL, et les traite de manière égale.

Accès assisté par licence

L'accès assisté par licence (LAA) est identifié comme la bande 46. L'algorithme traite cette bande de la même manière que les autres. 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 des canaux 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 puisse gérer 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 de 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 la bande 5 GHz entière et définit les indicateurs de restriction obligatoires pour SoftAP et Wi-Fi Direct (P2P).

Service Inform 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 des 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

Le conducteur jouant un rôle majeur dans l'évitement des canaux, il est essentiel de communiquer les canaux dangereux au conducteur 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

SoftAP est le principal cas d'utilisation pour l'évitement des canaux non sécurisés. 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 des canaux et du pilote ou du micrologiciel.

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

Si les canaux ne sont pas sécurisés et qu'une restriction SoftAP est en place
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 SoftAP.
Si des chaînes ne sont pas sécurisées et qu'aucune restriction n'est appliquée
1. Le pilote ou le 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

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.
Si le canal SoftAP n'est pas sécurisé et qu'aucune restriction n'est appliquée
1. Aucune action n'est effectuée par le framework. Le pilote ou le micrologiciel du fournisseur gèrent l'évitement des canaux non sécurisés ou l'application de la limite de puissance si l'évitement n'est pas possible.

Wi-Fi Direct (P2P)

Si des canaux non sécurisés sont soumis à des restrictions Wi-Fi Direct (P2P).
1. Le framework demande wpa_supplicant pour éviter les canaux non sécurisés à l'aide de la méthode HAL ISupplicantP2pIface::setDisallowedFrequencies().
Si des chaînes dangereuses ne sont pas soumises à 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 des canaux pour Wi-Fi Aware (NAN) et aucune action de framework n'est entreprise. Le pilote ou le 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 non sécurisés à éviter, configurez le config_wifiDefaultCoexAlgorithmEnabled de superposition. 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 chaînes non sécurisées à transmettre au framework à l'aide de l'API système suivante.

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

Valider l'implémentation

Pour valider l'implémentation de la fonctionnalité d'évitement des canaux de coexistence Wi-Fi/réseau 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)