Vermeidung von Wi-Fi/Mobilfunk-Coex-Kanälen

Die in Android 12 eingeführte Funktion zur Vermeidung von Wi-Fi-/Mobilfunk-Coex-Kanälen identifiziert und vermeidet die Verwendung unsicherer Wi-Fi-Kanäle in Fällen, in denen es zu Störungen von/zu Mobilfunkkanälen kommen könnte. Dazu gehören Schnittstellen wie STA, SoftAp, Wi-Fi Direct (P2P), Wi-Fi Aware (NAN).

Auf dieser Seite wird Folgendes besprochen:

  • Informationen, die das Mobilfunkmodem an das Android-Framework melden muss
  • Algorithmen, die das Wi-Fi-Framework verwendet, um zu vermeidende Wi-Fi-Kanäle zu berechnen
  • Konfigurationstabellen, die Gerätehersteller für das Wi-Fi-Framework bereitstellen müssen
  • System-APIs, Konfigurationen und HAL-APIs im Zusammenhang mit der Kanalvermeidungsfunktion
  • Framework-Verhalten zur Handhabung der Kanalvermeidung
  • Verhalten des Chipanbieters zur Handhabung der Kanalvermeidung
  • Implementierungsdetails für die Kanalvermeidung
  • Tests zur Validierung des Kanalvermeidungsverhaltens

Hintergrund

Bei Geräten mit Mobilfunktechnologien wie LTE, 5G NR und Licensed Assisted Access (LAA) können die verwendeten Mobilfunkkanäle den verwendeten WLAN-Kanal stören. Dies tritt auf, wenn die Mobilfunk- und Wi-Fi-Kanäle einen kurzen Frequenzabstand haben (benachbarte Kanäle) oder wenn Oberwellen- und Intermodulationsstörungen auftreten.

Diese Art von Interferenz wird zum Problem, wenn eine Antenne gleichzeitig sendet und eine andere empfängt. In diesem Fall überflutet die Sendeantenne die Empfangsantenne und beeinträchtigt deren Empfangsqualität.

In diesem Dokument wird der störende Sender als Aggressor und der von der Störung betroffene Empfänger als Opfer bezeichnet. Der WLAN-Kanal, der entweder der Angreifer oder das Opfer ist, wird als unsicherer Kanal bezeichnet.

Die Funktion zur Vermeidung von Wi-Fi-/Mobilfunk-Coex-Kanälen bietet einen konsistenten Ansatz zur Kanalvermeidung und reduziert den Bedarf an proprietärem Code, der vom Wi-Fi-Framework abweicht. Darüber hinaus ermöglicht die Funktion Geräteherstellern, die Funktion zu konfigurieren, zu aktivieren, zu deaktivieren und zu überschreiben.

Die Funktion führt eine Kanalvermeidung durch, indem sie die Wi-Fi-Kanäle steuert. Das Schema zur Vermeidung von Wi-Fi-Kanälen kann als eine Reihe von vier abstrakten Schritten beschrieben werden:

  1. Das Modem meldet eine Änderung der Mobilfunkfrequenz
  2. Der Coex-Vermeidungsalgorithmus berechnet unsichere WLAN-Kanäle
  3. Der Coex-Vermeidungsalgorithmus informiert den Wi-Fi-Dienst
  4. Das Framework oder der Treiber führt die entsprechende Wi-Fi-Aktion aus

Kanalvermeidungsschema

Abbildung 1. Kanalvermeidungsschema

Meldet eine Änderung der Mobilfunkfrequenz

Der Telefondienst meldet die aktuell genutzten Mobilfunkkanäle. Wenn sich die Betriebsfrequenz des Mobilfunknetzes ändert, meldet das Modem diese Informationen über IRadio::PhysicalChannelConfig an den Telefondienst. Zu diesen Informationen gehören Hinweise auf Licensed Assisted Access (LAA) und Carrier Aggregation (CA).

Ab Android 12 stellen die folgenden Felder in 1.6 IRadio::PhysicalChannelConfig erforderliche Informationen für die Coex-Formeln bereit, die das Modem ausfüllen muss.

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

Berechnung unsicherer WLAN-Kanäle

Wenn das Modem eine Änderung der Mobilfunkfrequenz meldet, berechnet der Coex-Kanal-Algorithmus die Interferenz zwischen Mobilfunk- und WLAN-Kanälen und bestimmt, welche WLAN-Kanäle unsicher sind.

Es gibt mehrere Arten von Interferenzen, die unterschiedliche Formeln erfordern: benachbarte und harmonische/Intermodulation . Aufgrund der physikalischen Unterschiede in der Antenne und Anordnung zwischen den Geräten sind die Muster benachbarter und harmonischer/Intermodulationsinterferenzen für jedes Gerät unterschiedlich. Um dies zu berücksichtigen, müssen Gerätehersteller eine Nachschlagetabelle bereitstellen, um Parameter in generische Formeln für die beiden Arten von Störungen einzufügen. Diese Parameter werden pro Zellband definiert und werden durch die Bänder der aktiven Zellkanäle referenziert.

In der Nachschlagetabelle kann eine maximale Leistungsobergrenze definiert werden. Wenn eine maximale Leistungsobergrenze definiert ist, sendet ein unsicherer Kanal mit der angegebenen Leistungsobergrenze. Wenn keine Leistungsobergrenze besteht, sendet der Kanal mit voller Leistung.

Im Allgemeinen verwendet die Kanalvermeidungsfunktion einen Best-Effort-Ansatz, um unsichere Wi-Fi-Kanäle zu vermeiden und so die Leistung zu optimieren. In bestimmten Fällen (z. B. aufgrund von Netzbetreiberanforderungen) ist es jedoch für bestimmte Schnittstellen obligatorisch, unsichere Kanäle für bestimmte Mobilfunkbänder zu vermeiden. In solchen Fällen werden obligatorische Einschränkungen als Bitmaske dargestellt, die Werte dafür enthält, ob bestimmte Kanäle wie Wi-Fi Direct (P2P), SoftAp und Wi-Fi Aware (NAN) verboten werden sollen. Während ein unsicherer Kanal als Empfehlung gegen die Verwendung dieses Kanals für alle Anwendungsfälle fungiert, kennzeichnen verbindliche Einschränkungen bestimmte Anwendungsfälle, die unbedingt vermieden werden müssen.

Wenn jeder Kanal des 2,4-GHz- oder 5-GHz-Bands als unsicher markiert ist, kann die Nachschlagetabelle einen Standard-2,4-GHz-Kanal oder einen Standard-5-GHz-Kanal pro störendem Zellband als sicherste Wahl definieren. Diese Standardkanäle werden nicht als unsichere Kanäle gemeldet, wenn der Rest des Bandes als unsicher gemeldet wird.

Override-Liste

Ein formelhafter Ansatz ist in Fällen begrenzt, in denen Interferenzen stark von der Bandbreite abhängig sind (und daher Kanäle mit größerer Bandbreite möglicherweise unsicher sind, Kanäle mit kleinerer Bandbreite jedoch nicht). In Fällen wie LAA ist es vorteilhaft, die Berechnungen zu überspringen und eine bestimmte Liste unsicherer Kanäle zu verwenden.

Dazu können Sie in der Nachschlagetabelle für bestimmte Einträge eine Override-Liste unsicherer Kanäle angeben. Eine Override-Liste in einem Tabelleneintrag bedeutet, dass die Berechnung für diesen bestimmten Mobilfunkkanal übersprungen wird und dass die unsicheren WLAN-Kanäle für den passenden Mobilfunkkanal durch die Override-Liste angegeben werden.

In bandbreitensensitiven Fällen können Sie bestimmte Bandbreiten gezielt vermeiden, indem Sie in der Override-Liste bestimmte Kanäle mit bestimmten Bandbreiten angeben. Dies liegt daran, dass jede WLAN-Kanalnummer einer bestimmten Bandbreite entspricht.

Die Überschreibungsliste wird durch eine Liste von Kanalnummern oder vordefinierten Kategorieschlüsselwörtern für jedes WLAN-Band dargestellt:

2g-Kategorien:

  • all (gesamtes 2,4-GHz-Band)

5g-Kategorien:

  • all (gesamtes 5-GHz-Band)
  • 20mhz (5 GHz 20 MHz-Kanäle)
  • 40mhz (5 GHz 40 MHz-Kanäle)
  • 80mhz (5 GHz 80 MHz-Kanäle)
  • 160mhz (5 GHz 160 MHz-Kanäle)

Nachbarkanalstörungen

Um Nachbarkanalinterferenzen zu ermitteln, stellt der Coex-Vermeidungsalgorithmus sicher, dass der Abstand ΔF zwischen einem Angreifer- und einem Opferkanal einen bestimmten Schwellenwert nicht unterschreitet.

Kanalinterferenz

Abbildung 2. Abstand zwischen einem Angreifer- und einem Opferkanal

Der Schwellenwert wird durch die physische Konfiguration des Geräts und den im Lookup-Tabelleneintrag pro Störband angegebenen Schwellenwert bestimmt. Bänder, die als nicht störend gelten, haben keinen Tabelleneintrag und unsichere Kanäle müssen nicht berechnet werden (dies ist in den meisten Fällen der Fall).

Benachbarte Interferenzparameter

  • wifiVictimMhz : MHz-Entfernungsschwellenwert für ein Wi-Fi-Opfer (Zellen-Uplink)
  • cellVictimMhz : MHz-Entfernungsschwelle für ein Zellenopfer (Zellen-Downlink)

Der Algorithmus verhält sich für jeden aktiven Zellkanal wie folgt:

  1. Versucht, für das Band des Kanals einen Eintrag in der Nachschlagetabelle zu finden. Wenn kein Tabelleneintrag gefunden wird, werden keine unsicheren Kanäle für diesen Zellenkanal zurückgegeben.
  2. Identifiziert anhand des Mobilfunkbandes, welches WLAN-Band gefährdet ist und von welcher Seite des Bandes die Störung kommt (z. B. niedrigere 2,4-GHz-Kanäle, höhere 2,4-GHz-Kanäle, niedrigere 5-GHz-Kanäle).
  3. Wenn wifiVictimMhz vorhanden ist und der Mobilfunkkanal über Uplink und verfügt

    1. Wenn der untere Teil des WLAN-Bandes gefährdet ist

      1. Ermittelt die Obergrenze unsicherer Kanäle durch Hinzufügen von wifiVictimMhz zur höchsten Frequenz des Mobilfunk-Uplinks.
      2. Findet den ersten 20-MHz-WLAN-Kanal, dessen unterer Rand den Grenzwert überlappt.
      3. Markiert den Wi-Fi-Kanal, jeden Kanal mit größerer Bandbreite, der ihn enthält (z. B. 40 MHz, 80 MHz), und jeden niedrigeren Kanal im gleichen Band wie der unsichere Kanal.
    2. Wenn der obere Teil des WLAN-Bandes gefährdet ist

      1. Ermittelt die Untergrenze unsicherer Kanäle durch Subtrahieren von wifiVictimMhz von der niedrigsten Frequenz des Mobilfunk-Uplinks.
      2. Findet den ersten WLAN-Kanal, dessen Oberkante den Grenzwert überlappt.
      3. Markiert den WLAN-Kanal, jeden größeren Kanal, der ihn enthält (z. B. 40 MHz, 80 MHz), und jeden höheren Kanal im gleichen Band wie der unsichere Kanal.
  4. Wenn cellVictimMhz vorhanden ist und der Zellkanal über Downlink verfügt.

    1. Führt Schritt 3 mit cellVictimMhz als Schwellenwert durch und vergleicht ihn mit dem Zellen-Downlink statt mit dem Zellen-Uplink.
  5. Wendet die Leistungsobergrenze des Tabelleneintrags auf die berechneten unsicheren Kanäle an.

Berechnung unsicherer Kanäle

Abbildung 3. Berechnung unsicherer Kanäle für Nachbarkanalstörungen

Harmonische/Intermodulationsverzerrung

Bei harmonischer/Intermodulationsverzerrung berechnet die Coex-Engine den Bereich des harmonischen/Intermodulationssignals und bewertet die prozentuale Überlappung mit einem potenziellen Opferkanal. Wenn die Überlappung einen Überlappungsschwellenwert überschreitet, betrachtet der Algorithmus dies als unsichere Situation. Die Berechnung der prozentualen Überlappung der harmonischen/Intermodulationsverzerrung auf einem Opferkanal erfolgt mit der folgenden Gleichung:

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

Im Fall der harmonischen Verzerrung berücksichtigt der Algorithmus die harmonische Verzerrung eines Mobilfunk-Uplink-Kanals, der Wi-Fi-Kanäle beeinträchtigt. Anschließend werden die hohe und die niedrige Verzerrung durch die harmonischen Werte ersetzt, die auf den Uplink-Frequenzen der Zelle und einem harmonischen Grad $ N $ basieren.

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

Harmonische Verzerrung zur Berechnung unsicherer Kanäle

Abbildung 4. Berechnung unsicherer Kanäle für harmonische Verzerrungen

Im Fall der Intermodulation berücksichtigt der Algorithmus die Intermodulationsverzerrung des Zell-Uplink und des Wi-Fi-Kanals, der den Zell-Downlink-Kanal beeinträchtigt. Anschließend ersetzt es die Verzerrung hoch und die Verzerrung niedrig durch die Intermodulationswerte basierend auf den Zell-Uplink-Frequenzen, Wi-Fi-Frequenzen und den beiden Intermodulationskoeffizienten $ M $, $ N $.

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

Intermodulationsverzerrung bei unsicherer Kanalberechnung

Abbildung 5. Berechnung unsicherer Kanäle für Intermodulationsverzerrungen

Sie können $ M $, $ N $ und Überlappungswerte in der Nachschlagetabelle pro interferierendem Zellband angeben. Wenn für ein Band keine Interferenz vorliegt, werden die Werte für diesen Bandeintrag in der Tabelle weggelassen. Zwei Sätze dieser Werte für die WLAN-Bänder 2,4 GHz und 5 GHz können unabhängig voneinander definiert werden.

Ähnlich wie der Nachbarinterferenzalgorithmus verwendet der Algorithmus denselben Leistungsobergrenzenwert, der pro interferierendem Zellband definiert ist.

Der Algorithmus verhält sich für jeden aktiven Zellkanal wie folgt:

  1. Für das Band des Mobilfunkkanals wird versucht, einen Eintrag in der Nachschlagetabelle zu finden. Wenn kein Tabelleneintrag gefunden wird, wird zurückgegeben, dass für diesen Kanal keine unsicheren Kanäle vorhanden sind.
  2. Findet die unsicheren 2,4-GHz-Kanäle anhand von Oberwellen, wenn Parameter definiert sind.

    1. Ermittelt den harmonischen Grad N für 2,4 GHz.
    2. Berechnet die harmonische Hochfrequenz und die harmonische Niederfrequenz basierend auf N und dem Zell-Uplink.
    3. Findet den ersten 20-MHz-WLAN-Kanal, der innerhalb der unteren Grenze der von unten kommenden Harmonischen liegt.
    4. Berechnet die Überlappung der Harmonischen über den Wi-Fi-Kanal und markiert den Kanal als unsicher, wenn die Überlappung den 2,4-GHz-Wi-Fi-Überlappungsschwellenwert überschreitet.
    5. Findet den ersten 20-MHz-WLAN-Kanal, der innerhalb der Obergrenze der von oben kommenden Harmonischen liegt.
    6. Berechnet die Überlappung der Harmonischen über den Wi-Fi-Kanal und markiert den Kanal als unsicher, wenn die Überlappung den 2,4-GHz-Wi-Fi-Überlappungsschwellenwert überschreitet.
    7. Markiert jeden 20-MHz-Kanal dazwischen als unsicheren Kanal.
  3. Findet die unsicheren 5-GHz-Kanäle anhand von Oberwellen, wenn Parameter definiert sind.

    1. Ermittelt den harmonischen Grad N für 5 GHz. Wenn N 0 ist, wird mit Schritt 5 fortgefahren.
    2. Berechnet die harmonische Hochfrequenz und die harmonische Niederfrequenz basierend auf N und dem Zell-Uplink.
    3. Findet unsichere 20-MHz-Kanäle.

      1. Findet den ersten 20-MHz-WLAN-Kanal, der innerhalb der unteren Grenze der von unten kommenden Harmonischen liegt.
      2. Berechnet die Überlappung der Harmonischen über den Wi-Fi-Kanal und markiert den Kanal als unsicher, wenn die Überlappung den 2,4-GHz-Wi-Fi-Überlappungsschwellenwert überschreitet.
      3. Findet den ersten 20-MHz-WLAN-Kanal, der innerhalb der Obergrenze der von oben kommenden Harmonischen liegt.
      4. Berechnet die Überlappung der Harmonischen über den Wi-Fi-Kanal und markiert den Kanal als unsicher, wenn die Überlappung den 2,4-GHz-Wi-Fi-Überlappungsschwellenwert überschreitet.
      5. Markiert jeden 20-MHz-Kanal dazwischen als unsicheren Kanal mit der angegebenen Leistungsobergrenze.
    4. Findet unsichere 40-MHz-, 80-MHz- und 160-MHz-Kanäle

      1. Wiederholt Schritt 3a, jedoch mit 40 MHz, 80 MHz, 160 MHz.
      2. Anstatt die Überlappungen der Kanäle am harmonischen Rand zu berechnen, werden die berechneten Überlappungen der kleineren Teilkanäle erneut verwendet (wenn beispielsweise zwei 20-MHz-Kanäle einen 40-MHz-Kanal ergeben und 30 % und 90 % Überlappung aufweisen, beträgt der Durchschnitt 60). % Überlappung für den 40-MHz-Kanal).
  4. Findet die durch Intermodulation unsicheren 2,4-GHz-Kanäle, wenn Parameter definiert sind.

    1. Ermittelt die Intermodulationskoeffizienten N, M für 2,4 GHz.
    2. Für jeden 2,4-GHz-WLAN-Kanal:

      1. Berechnet die Intermodulations-Niederfrequenz und die Intermodulations-Hochfrequenz basierend auf N, M, Mobilfunk-Uplink und Wi-Fi-Kanal.
      2. Berechnet die Überlappung der Intermodulation über den Zellen-Downlink und markiert den Kanal als unsicher, wenn die Überlappung den 2,4-GHz-Zellenüberlappungsschwellenwert überschreitet.
  5. Findet die unsicheren 5-GHz-Kanäle vor Intermodulation, wenn Parameter definiert sind.

    1. Wiederholt Schritt 4 mit den 5-GHz-WLAN-Kanälen und dem 5-GHz-Zellenüberlappungsschwellenwert.
  6. Wendet die Leistungsobergrenze des Tabelleneintrags auf die berechneten unsicheren Kanäle an.

Endergebnis

Nachdem beide Sätze unsicherer Kanäle aufgrund benachbarter und harmonischer Interferenzen berechnet wurden, wird der endgültige Satz berechnet, indem die Vereinigung beider Sätze vorgenommen wird (und bei Kollisionen die niedrigere Leistungsobergrenze ausgewählt wird) und die Standardkanäle aus dem Satz entfernt werden, falls vorhanden Es wurden keine zwingenden Einschränkungen angewendet.

Der Algorithmus verhält sich wie folgt:

  1. Wenn jeder 2,4-GHz-WLAN-Kanal als unsicherer Kanal markiert ist, wird der standardmäßige 2,4-GHz-WLAN-Kanal aus dem Satz entfernt.
  2. Wenn jeder 5-GHz-WLAN-Kanal als unsicherer Kanal markiert ist, wird der standardmäßige 5-GHz-WLAN-Kanal aus dem Satz entfernt.
  3. Gibt den letzten Satz unsicherer Kanäle zurück.

Nachschlagetabellenformat

Die Nachschlagetabellen werden in einer XML-Datei dargestellt, die sich in der überlagerbaren Konfigurationszeichenfolge config_wifiCoexTableFilepath befindet und durch die folgende XSD definiert wird.


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

Beispiel einer XML-Tabelle

Das Folgende ist ein Beispiel für eine XML-Nachschlagetabelle:


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

Carrier-Aggregation

Bei der Trägeraggregation (Carrier Aggregation, CA) erzeugen die Harmonischen-/Intermodulationsbereiche für jeden Uplink/Downlink möglicherweise nicht genügend Überlappung, um unabhängig voneinander Störungen zu verursachen, können aber in Kombination zu ausreichender Überlappung führen. Der Algorithmus berücksichtigt jeden Harmonischen-/Intermodulationsbereich unabhängig und nimmt die Vereinigung der zurückgegebenen unsicheren Kanäle. Für den Intermodulationsfall bedeutet dies, dass der Intermodulationsbereich jedes UL auf jedem DL bewertet wird.

Der Algorithmus macht keinen Unterschied zwischen PCELL/PSCELL/SCELLs und behandelt sie als gleich.

Lizenzunterstützter Zugriff

License Assisted Access (LAA) wird als Band Nr. 46 identifiziert. Der Algorithmus behandelt dieses Band ähnlich wie andere Bänder. In diesem Fall können die vollständigen 5-GHz-Kanäle als Override-Liste in der Nachschlagetabelle festgelegt werden.

Abhängig von den Anforderungen des Netzbetreibers legt der Kanalvermeidungsalgorithmus verbindliche Beschränkungen für SoftAP und Wi-Fi Direct (P2P) für das gesamte 5-GHz-Wi-Fi-Band fest. Damit der Algorithmus diesen Anwendungsfall verarbeiten kann, muss der Netzbetreiberkonfigurationswert restrict_5g_softap_wifi_direct_for_laa definiert werden. Wenn sich der Mobilfunkkanal auf LAA befindet und restrict_5g_softap_wifi_direct_for_laa true ist, gibt der Algorithmus den Satz unsicherer Kanäle mit dem gesamten 5-GHz-Band zurück und setzt die obligatorischen Einschränkungsflags für SoftAP und Wi-Fi Direct (P2P).

Wi-Fi-Dienst informieren

Nachdem der Coex-Kanalalgorithmus die unsicheren Kanäle berechnet hat, verwenden Sie die folgende im Android-Framework definierte @SystemApi-Datenstruktur, um Ihren System-Apps die unsicheren Kanäle und deren Einschränkungen bereitzustellen.

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

Verwenden Sie die folgenden @SystemApi-Methoden und Rückrufe WifiManager , um den Apps zu ermöglichen, aktualisierte Werte zu erhalten, wenn sich die unsicheren Kanäle ändern.

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

Durchführen einer Wi-Fi-Aktion

Wenn der Wi-Fi-Dienst Informationen über die Gruppe unsicherer Kanäle erhält, führt er die entsprechende Aktion aus, um sicherzustellen, dass diese Kanäle vermieden werden. In diesem Abschnitt wird das Verhalten des Wi-Fi-Dienstes in verschiedenen Szenarien beschrieben.

Den Fahrer informieren

Da der Treiber eine wichtige Rolle bei der Kanalvermeidung spielt, ist es wichtig, die unsicheren Kanäle an den Treiber und die Firmware zu übermitteln. Verwenden Sie dazu die folgende IWifiChip HAL API.

Für AIDL:

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

Für HIDL (1,5 oder höher):

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

SoftAP

SoftAP ist der Hauptanwendungsfall für die Vermeidung unsicherer Kanäle. Im folgenden Abschnitt werden die wichtigsten SoftAp-Szenarien beschrieben, in denen Kanalvermeidung mit ACS angewendet werden kann. Die Szenarien beschreiben das Verhalten des Kanalvermeidungsalgorithmus und des Treibers bzw. der Firmware.

SoftAP mit aktiviertem ACS starten (es ist noch kein SoftAP aktiv)

  1. Wenn Kanäle unsicher sind und eine SoftAP-Einschränkung besteht

    1. Das Framework entfernt unsichere Kanäle aus der ACS-Liste.
    2. Wenn die Liste leer ist, stoppt das Framework SoftAP.
  2. Wenn Kanäle unsicher sind und keine Einschränkungen bestehen

    1. Der Treiber/die Firmware des Anbieters gibt den sicheren Kanälen Vorrang vor den unsicheren Kanälen.

SoftAP ist mit aktiviertem ACS aktiv und unsichere Kanäle werden aktualisiert

  1. Wenn der SoftAP-Kanal unsicher ist und eine SoftAP-Einschränkung besteht

    1. Das Framework aktualisiert die ACS-Liste, indem es die unsicheren Kanäle entfernt.
    2. Wenn die Liste leer ist, schließt das Framework SoftAP.
  2. Wenn der SoftAP-Kanal unsicher ist und keine Einschränkungen bestehen

    1. Das Framework ergreift keine Maßnahmen. Der Treiber bzw. die Firmware des Anbieters übernimmt die Vermeidung unsicherer Kanäle oder die Anwendung der Stromobergrenze, wenn eine Vermeidung nicht möglich ist.

Wi-Fi Direct (P2P)

  1. Wenn es unsichere Kanäle mit Wi-Fi Direct (P2P)-Einschränkungen gibt.

    1. Das Framework fordert wpa_supplicant auf, die unsicheren Kanäle mithilfe der HAL-Methode ISupplicantP2pIface::setDisallowedFrequencies() zu vermeiden.
  2. Bei unsicheren Kanälen ohne Einschränkungen.

    1. Der Herstellertreiber/die Firmware wendet die Stromobergrenze an, wenn ein unsicherer Kanal ohne Wi-Fi Direct (P2P)-Einschränkung verwendet wird.

Wi-Fi-fähig (NAN)

Das Framework ist nicht an der Kanalauswahl für Wi-Fi Aware (NAN) beteiligt und es werden keine Framework-Aktionen ergriffen. Der Treiber bzw. die Firmware des Anbieters ist für die Vermeidung von Wi-Fi Aware (NAN)-Kanälen verantwortlich.

Deaktivieren des Algorithmus

Wenn Sie die Standardalgorithmusimplementierung deaktivieren und Ihre eigene Liste unsicherer Kanäle zur Vermeidung übergeben möchten, konfigurieren Sie das Overlay config_wifiDefaultCoexAlgorithmEnabled . Wenn das Overlay auf „false“ gesetzt ist, ist der Standardalgorithmus deaktiviert. Anschließend können Sie mithilfe der folgenden System-API Ihren eigenen proprietären Out-of-Band-Algorithmus verwenden, um eine Liste unsicherer Kanäle zu erstellen und diese an das Framework anzuschließen.

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

Validierung der Implementierung

Um Ihre Implementierung der Funktion zur Vermeidung von WLAN-/Mobilfunk-Coex-Kanälen zu validieren, verwenden Sie die folgenden Tests.

CTS-Tests

  • WifiManagerTest.java

    • testCoexMethodsShouldFailNoPermission()
    • testListenOnCoexUnsafeChannels()

ACTS-Tests

  • WifiManagerTest.py

    • test_set_get_coex_unsafe_channels()

VTS-Tests

  • Wenn AIDL implementiert ist: wifi_chip_aidl_test.cpp

    • TEST_P(WifiChipAidlTest, SetCoexUnsafeChannels)
  • Wenn HIDL implementiert ist: wifi_chip_hidl_test.cpp

    • TEST_P(WifiChipHidlTest, setCoexUnsafeChannels)