Vermeidung von WLAN-/Mobilfunk-Coex-Kanälen

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

Auf dieser Seite wird Folgendes behandelt:

  • Informationen, die das Mobilfunkmodem an das Android-Framework melden muss
  • Algorithmen, die vom WLAN-Framework verwendet werden, um WLAN-Kanäle zu berechnen, die vermieden werden sollen
  • Konfigurationstabellen, die Gerätehersteller für das WLAN-Framework bereitstellen müssen
  • System-APIs, Konfigurationen und HAL-APIs im Zusammenhang mit der Funktion zur Kanalvermeidung
  • Framework-Verhalten bei der Verarbeitung von Channel-Vermeidung
  • Verhalten des Chipherstellers bei der Verarbeitung von Channel-Vermeidung
  • Details zur Implementierung der Channel-Vermeidung
  • Tests zur Validierung des Verhaltens bei der Kanalvermeidung

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. Das passiert, wenn die Mobilfunk- und WLAN-Kanäle nur einen geringen Frequenzabstand haben (benachbarte Kanäle) oder wenn es zu harmonischen und Intermodulationsstörungen kommt.

Diese Art von Störung wird zu einem Problem, wenn eine Antenne sendet und eine andere gleichzeitig empfängt. In diesem Fall überflutet die Sendeantenne die Empfangsantenne, was sich auf die Empfangsqualität auswirkt.

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

Die Funktion zur Vermeidung von Coex-Kanälen für WLAN und Mobilfunk bietet einen einheitlichen Ansatz zur Kanalvermeidung. Dadurch ist weniger proprietärer Code erforderlich, der vom WLAN-Framework abweicht. Außerdem können Gerätehersteller die Funktion konfigurieren, aktivieren, deaktivieren und überschreiben.

Die Funktion vermeidet Kanäle, indem sie die WLAN-Kanäle steuert. Das Schema zur Vermeidung von WLAN-Kanälen kann als eine Reihe von vier abstrakten Schritten beschrieben werden:

  1. Modem-Berichte zur Änderung der Mobilfunkfrequenz
  2. Der Algorithmus zur Vermeidung von Koexistenz berechnet unsichere WLAN-Kanäle
  3. Algorithmus zur Vermeidung von Koexistenzproblemen informiert WLAN-Dienst
  4. Framework oder Treiber führt entsprechende WLAN-Aktion aus

Schema zur Kanalvermeidung

Abbildung 1: Schema zur Kanalvermeidung

Änderung der Mobilfunkfrequenz melden

Der Telefondienst meldet die derzeit verwendeten Mobilfunkkanäle. Wenn sich die Betriebsfrequenz des Mobilfunknetzes ändert, meldet das Modem diese Informationen über IRadio::PhysicalChannelConfig an den Telefondienst. Diese Informationen enthalten Hinweise zu Licensed Assisted Access (LAA) und Carrier Aggregation (CA).

Ab Android 12 enthalten die folgenden Felder in 1.6 IRadio::PhysicalChannelConfig die erforderlichen Informationen für die Koexistenzformeln, 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;
}

Unsichere WLAN-Kanäle berechnen

Wenn das Modem eine Änderung der Mobilfunkfrequenz meldet, berechnet der Coex-Kanalalgorithmus die Störungen zwischen Mobilfunk- und WLAN-Kanälen und ermittelt, welche WLAN-Kanäle nicht sicher sind.

Es gibt verschiedene Arten von Störungen, für die unterschiedliche Formeln erforderlich sind: benachbart und harmonisch/Intermodulation. Aufgrund der physischen Unterschiede bei Antenne und Layout zwischen den Geräten sind die Muster von benachbarten und harmonischen/Intermodulationsstörungen 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 Zellenband definiert und von den Bändern der aktiven Zellkanäle referenziert.

In der Nachschlagetabelle kann eine maximale Leistungsbegrenzung definiert werden. Wenn eine maximale Leistungsbegrenzung definiert ist, wird über einen unsicheren Kanal mit der angegebenen Leistungsbegrenzung gesendet. Wenn keine Leistungsbegrenzung vorhanden ist, wird über den Kanal mit voller Leistung gesendet.

Im Allgemeinen wird bei der Funktion zur Kanalvermeidung versucht, unsichere WLAN-Kanäle zu vermeiden, um die Leistung zu optimieren. In bestimmten Fällen (z. B. aufgrund von Anforderungen des Mobilfunkanbieters) ist es jedoch erforderlich, dass bestimmte Schnittstellen unsichere Kanäle für bestimmte Mobilfunkbänder 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. Ein unsicherer Channel ist eine Empfehlung, diesen Channel nicht für alle Anwendungsfälle zu verwenden. Bei obligatorischen Einschränkungen werden bestimmte Anwendungsfälle markiert, die unbedingt vermieden werden müssen.

Wenn jeder Kanal des 2,4‑GHz- oder 5‑GHz-Bands als unsicher markiert ist, kann in der Nachschlagetabelle ein standardmäßiger 2,4‑GHz-Kanal oder ein standardmäßiger 5‑GHz-Kanal pro störendem Zellband als sicherste Option definiert werden. Diese Standardchannels werden nicht als unsichere Channels gemeldet, wenn der Rest des Bands als unsicher gemeldet wird.

Überschreibungsliste

Ein formelhafter Ansatz ist in Fällen eingeschränkt, in denen Störungen stark bandbreitenabhängig sind. Das bedeutet, dass Kanäle mit größerer Bandbreite möglicherweise unsicher sind, Kanäle mit kleinerer Bandbreite jedoch nicht. In einigen Fällen, z. B. bei LAA, ist es sinnvoll, die Berechnungen zu überspringen und eine bestimmte Liste unsicherer Channels zu verwenden.

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

In bandbreitenkritischen Fällen können Sie bestimmte Bandbreiten selektiv vermeiden, indem Sie bestimmte Channels mit bestimmten Bandbreiten in der Überschreibungsliste angeben. Das liegt daran, dass jede WLAN-Kanalnummer einer bestimmten Bandbreite entspricht.

Die Überschreibungsliste wird durch eine Liste von Channelnummern oder vordefinierten Kategorie-Keywords 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-Kanäle mit 40 MHz)
  • 80mhz (5‑GHz-Kanäle mit 80 MHz)
  • 160mhz (5‑GHz-Kanäle mit 160 MHz)

Störungen durch benachbarte Kanäle

Um Störungen durch benachbarte Kanäle zu ermitteln, sorgt der Algorithmus zur Vermeidung von Koexistenz dafür, dass der Abstand ΔF zwischen einem Aggressor- und einem Opferkanal nicht unter einen angegebenen Grenzwert fällt.

Kanalstörungen

Abbildung 2: Abstand zwischen dem Kanal des Aggressors und dem Kanal des Opfers

Der Schwellenwert wird durch die physische Konfiguration des Geräts und den Schwellenwert bestimmt, der im Suchtabelleneintrag für jedes störende Band angegeben ist. Für Bänder, die als nicht störend gelten, gibt es keinen Tabelleneintrag. Unsichere Kanäle müssen nicht berechnet werden (das ist in den meisten Fällen so).

Parameter für benachbarte Störungen

  • wifiVictimMhz: MHz-Abstandsschwelle für ein WLAN-Opfer (Mobilfunk-Uplink)
  • cellVictimMhz: MHz-Abstandsschwelle für ein Zellopfer (Zell-Downlink)

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

  1. Sucht für das Band des Kanals nach einem Eintrag in der Nachschlagetabelle. Wenn kein Tabelleneintrag gefunden wird, wird eine Antwort ohne unsichere Channels für diesen Zellchannel zurückgegeben.
  2. Anhand des Mobilfunkbands wird ermittelt, welches WLAN-Band gefährdet ist und von welcher Seite des Bands die Störungen kommen (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 Zellkanal Uplink- und

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

      1. Ermittelt die Obergrenze unsicherer Kanäle, indem wifiVictimMhz zur höchsten Frequenz des Zell-Uplinks addiert wird.
      2. Sucht den ersten 20‑MHz-WLAN-Kanal, dessen untere Kante die Grenze überschneidet.
      3. Kennzeichnet den WLAN-Kanal, alle Kanäle mit größerer Bandbreite, die ihn enthalten (z. B. 40 MHz, 80 MHz), und alle niedrigeren Kanäle desselben Bands wie der unsichere Kanal.

    2. Wenn der obere Teil des WLAN-Bands gefährdet ist

      1. Ermittelt die Untergrenze unsicherer Kanäle, indem die niedrigste Frequenz des Mobilfunk-Uplinks von „wifiVictimMhz“ subtrahiert wird.
      2. Sucht den ersten WLAN-Kanal, dessen obere Kante das Limit überschreitet.
      3. Markiert den WLAN-Kanal, jeden größeren Kanal, der ihn enthält (z. B. 40 MHz, 80 MHz), und jeden höheren Kanal desselben Bands wie der unsichere Kanal.

  4. Wenn cellVictimMhz vorhanden ist und der Zellkanal einen Downlink hat.

    1. Führt Schritt 3 mit cellVictimMhz als Grenzwert aus und vergleicht mit dem Downlink der Zelle anstelle des Uplinks der Zelle.

  5. Wendet die Obergrenze für die Leistung des Tabelleneintrags auf die berechneten unsicheren Kanäle an.

Berechnung von unsicheren Kanälen

Abbildung 3: Berechnung von unsicheren Kanälen für benachbarte Kanalstörungen

Harmonische oder Intermodulationsverzerrung

Bei harmonischen oder Intermodulationsverzerrungen berechnet die Coex-Engine den Bereich des harmonischen oder Intermodulationssignals und bewertet die prozentuale Überschneidung mit einem potenziellen Opferkanal. Wenn die Überschneidung einen bestimmten Schwellenwert überschreitet, stuft der Algorithmus dies als unsichere Situation ein. Die Berechnung der prozentualen Überschneidung der harmonischen oder 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 von harmonischer Verzerrung berücksichtigt der Algorithmus die harmonische Verzerrung eines Mobilfunk-Uplink-Kanals, der WLAN-Kanäle beeinträchtigt. Anschließend werden die Werte für „Distortion High“ und „Distortion Low“ 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 bei der Berechnung unsicherer Kanäle

Abbildung 4: Unsichere Kanalberechnung für harmonische Verzerrung

Im Fall von Intermodulation berücksichtigt der Algorithmus die Intermodulationsverzerrung des Mobilfunk-Uplinks und des WLAN-Kanals, der den Mobilfunk-Downlink-Kanal beeinträchtigt. Anschließend werden die Werte für „Distortion High“ und „Distortion Low“ durch die Intermodulationswerte ersetzt, die auf den Uplink-Frequenzen der Zelle, den WLAN-Frequenzen und den beiden Intermodulationskoeffizienten $ M$ und $N$ basieren.

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

Berechnung der Intermodulationsverzerrung für unsichere Kanäle

Abbildung 5: Berechnung des unsicheren Kanals für Intermodulationsverzerrung

Sie können die Werte für $ M $, $ N $ und die Überschneidung in der Nachschlagetabelle für jedes störende Zellenband angeben. Wenn es für ein Band keine Störungen gibt, werden die Werte für diesen Bandeintrag aus der Tabelle entfernt. Zwei Sätze dieser Werte für die WLAN-Bänder mit 2,4 GHz und 5 GHz können unabhängig voneinander definiert werden.

Ähnlich wie beim Algorithmus für benachbarte Störungen wird derselbe Grenzwert für die Leistung verwendet, der für jedes störende Zellband definiert ist.

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

  1. Für das Band des Zellkanals wird versucht, einen Eintrag in der Nachschlagetabelle zu finden. Wenn kein Tabelleneintrag gefunden wird, wird eine Antwort ohne unsichere Kanäle für diesen Kanal zurückgegeben.

  2. Sucht nach unsicheren 2,4‑GHz-Kanälen anhand von Oberwellen, wenn Parameter definiert sind.

    1. Ermittelt den harmonischen Grad N für 2,4 GHz.
    2. Berechnet die harmonische hohe und niedrige Frequenz basierend auf N und dem Zell-Uplink.
    3. Sucht den ersten 20‑MHz-WLAN-Kanal, der unterhalb der unteren Grenze der Harmonischen liegt, die von unten kommt.
    4. Berechnet die Überschneidung des Obertons mit dem WLAN-Kanal und kennzeichnet den Kanal als unsicher, wenn die Überschneidung den Grenzwert für die 2,4‑GHz-WLAN-Überschneidung überschreitet.
    5. Sucht den ersten 20‑MHz-WLAN-Kanal, der innerhalb der Obergrenze des Obertons liegt, der von oben kommt.
    6. Berechnet die Überschneidung des Obertons mit dem WLAN-Kanal und kennzeichnet den Kanal als unsicher, wenn die Überschneidung den Grenzwert für die 2,4‑GHz-WLAN-Überschneidung überschreitet.
    7. Markiert jeden 20‑MHz-Kanal dazwischen als unsicheren Kanal.

  3. Sucht nach unsicheren 5‑GHz-Kanälen anhand von Oberwellen, wenn Parameter definiert sind.

    1. Ermittelt den harmonischen Grad N für 5 GHz. Wenn N = 0, wird mit Schritt 5 fortgefahren.
    2. Berechnet die harmonische hohe und niedrige Frequenz basierend auf N und dem Zell-Uplink.

    3. Sucht nach unsicheren 20‑MHz-Kanälen.

      1. Sucht den ersten 20‑MHz-WLAN-Kanal, der innerhalb der Untergrenze des von unten kommenden Obertons liegt.
      2. Berechnet die Überschneidung des harmonischen Signals mit dem WLAN-Channel und kennzeichnet den Channel als unsicher, wenn die Überschneidung den Grenzwert für die Überschneidung von 2,4‑GHz-WLAN überschreitet.
      3. Sucht den ersten 20‑MHz-WLAN-Kanal, der innerhalb der Obergrenze des Obertons liegt, der von oben kommt.
      4. Berechnet die Überschneidung des harmonischen Signals mit dem WLAN-Channel und kennzeichnet den Channel als unsicher, wenn die Überschneidung den Grenzwert für die Überschneidung von 2,4‑GHz-WLAN überschreitet.
      5. Kennzeichnet jeden 20‑MHz-Kanal dazwischen als unsicheren Kanal mit der angegebenen Obergrenze für die Leistung.

    4. Sucht nach unsicheren 40‑MHz-, 80‑MHz- und 160‑MHz-Kanälen

      1. Wiederholt Schritt 3a, aber mit 40 MHz, 80 MHz und 160 MHz.
      2. Anstatt die Überschneidungen der Kanäle am harmonischen Rand zu berechnen, werden die berechneten Überschneidungen der kleineren Bestandteile der Kanäle wiederverwendet. Wenn beispielsweise zwei 20-MHz-Kanäle einen 40-MHz-Kanal bilden und eine Überschneidung von 30% bzw. 90% haben, beträgt die durchschnittliche Überschneidung für den 40-MHz-Kanal 60 %.

  4. Sucht die unsicheren 2,4‑GHz-Kanäle aus der Intermodulation, wenn Parameter definiert sind.

    1. Ermittelt die Intermodulationskoeffizienten N und 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, dem Mobilfunk-Uplink und dem WLAN-Kanal.
      2. Berechnet die Überschneidung der Intermodulation über den Downlink der Zelle und kennzeichnet den Kanal als unsicher, wenn die Überschneidung den Grenzwert für die Überschneidung von 2,4‑GHz-Zellen überschreitet.

  5. Sucht die unsicheren 5‑GHz-Kanäle aus der Intermodulation, wenn Parameter definiert sind.

    1. Wiederholt Schritt 4 mit den 5‑GHz-WLAN-Kanälen und dem Grenzwert für die 5‑GHz-Zellenüberlappung.

  6. Wendet die Obergrenze für die Leistung des Tabelleneintrags auf die berechneten unsicheren Kanäle an.

Endergebnis

Nachdem beide Gruppen unsicherer Kanäle aus benachbarten und harmonischen Störungen berechnet wurden, wird die endgültige Gruppe berechnet, indem die Vereinigung beider Gruppen gebildet wird (und die untere Leistungsbegrenzung ausgewählt wird, wenn es zu Kollisionen kommt) und die Standardkanäle aus der Gruppe entfernt werden, wenn keine obligatorischen Einschränkungen angewendet werden.

Der Algorithmus verhält sich so:

  1. Wenn jeder 2,4‑GHz-WLAN-Kanal als unsicher gekennzeichnet ist, wird der Standard-2,4‑GHz-WLAN-Kanal aus dem Set entfernt.
  2. Wenn jeder 5‑GHz-WLAN-Kanal als unsicher gekennzeichnet ist, wird der Standard-5‑GHz-WLAN-Kanal aus dem Set entfernt.
  3. Gibt die endgültige Gruppe unsicherer Channels zurück.

Format der Suchtabelle

Die Nachschlagetabellen werden in einer XML-Datei dargestellt, die sich im überschreibbaren Konfigurationsstring config_wifiCoexTableFilepath befindet und durch das 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 für eine XML-Tabelle

Im Folgenden sehen Sie 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 Carrier Aggregation (CA) erzeugen die harmonischen oder Intermodulationsbereiche für jeden Uplink oder Downlink möglicherweise nicht genügend Überschneidungen, um unabhängig voneinander Störungen zu verursachen, aber in Kombination möglicherweise schon. Der Algorithmus berücksichtigt jeden harmonischen oder Intermodulationsbereich unabhängig voneinander und berücksichtigt die Vereinigung der zurückgegebenen unsicheren Kanäle. Im Fall der Intermodulation bedeutet dies, dass der Intermodulationsbereich jeder UL auf jede DL bewertet wird.

Der Algorithmus unterscheidet nicht zwischen PCELL, PSCELL oder SCELL und behandelt sie gleich.

Lizenzierter unterstützter Zugriff

License Assisted Access (LAA) wird als Band 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 Überschreibungsliste in der Nachschlagetabelle festgelegt werden.

Je nach den Anforderungen des Mobilfunkanbieters legt der Algorithmus zur Kanalvermeidung obligatorische Einschränkungen für SoftAP und Wi‑Fi Direct (P2P) für das gesamte 5‑GHz-WLAN-Band fest. Damit der Algorithmus diesen Anwendungsfall verarbeiten kann, muss der Wert restrict_5g_softap_wifi_direct_for_laa in der Netzbetreiberkonfiguration definiert sein. Wenn sich der Zellkanal auf LAA befindet und restrict_5g_softap_wifi_direct_for_laa gleich true ist, gibt der Algorithmus die Gruppe der unsicheren Kanäle mit dem gesamten 5‑GHz-Band zurück und legt die obligatorischen Einschränkungsflags für SoftAP und Wi‑Fi Direct (P2P) fest.

WLAN-Dienst informieren

Nachdem der Algorithmus für die Koexistenz von Kanälen die unsicheren Kanäle berechnet hat, verwenden Sie die folgende im Android-Framework definierte @SystemApi-Datenstruktur, um Ihre System-Apps mit den unsicheren Kanälen und ihren Einschränkungen zu versorgen.

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 WifiManager @SystemApi-Methoden und den Callback, damit die Apps aktualisierte Werte 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);
}

WLAN-Aktion ausführen

Wenn der WLAN-Dienst Informationen zu den unsicheren Kanälen erhält, ergreift er die entsprechenden Maßnahmen, um diese Kanäle zu vermeiden. In diesem Abschnitt wird das Verhalten des WLAN-Dienstes in verschiedenen Szenarien beschrieben.

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 die Kanalauswahl mit ACS angewendet werden kann. In den Szenarien wird das Verhalten des Algorithmus zur Kanalvermeidung und des Treibers oder der Firmware beschrieben.

SoftAP mit aktiviertem ACS starten (noch kein SoftAP aktiv)

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

    1. Das Framework entfernt unsichere Kanäle aus der ACS-Liste.
    2. Wenn die Liste leer ist, beendet das Framework SoftAP.

  2. Wenn Kanäle unsicher sind und keine Einschränkungen bestehen

    1. Der Treiber oder die Firmware des Anbieters priorisiert die sicheren Kanäle gegenüber 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 vorliegt

    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. Es werden keine Maßnahmen ergriffen. Der Treiber oder die Firmware des Anbieters sorgt dafür, dass unsichere Kanäle vermieden werden oder die Leistungsbegrenzung angewendet wird, wenn dies nicht möglich ist.

Wi‑Fi Direct (P2P)

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

    1. Das Framework fordert wpa_supplicant an, um die unsicheren Kanäle mithilfe der HAL-Methode ISupplicantP2pIface::setDisallowedFrequencies() zu vermeiden.

  2. Wenn es unsichere Channels ohne Einschränkungen gibt.

    1. Der Treiber oder die Firmware des Anbieters wendet die Leistungsbegrenzung an, wenn ein unsicherer Kanal ohne Wi-Fi Direct-Einschränkung (P2P) verwendet wird.

Wi‑Fi Aware (NAN)

Das Framework ist nicht an der Kanalauswahl für Wi-Fi Aware (NAN) beteiligt und es wird keine Framework-Aktion ausgeführt. Der Anbieter-Treiber oder die Anbieter-Firmware ist für die Vermeidung von Wi-Fi Aware-Kanälen (NAN) verantwortlich.

Algorithmus deaktivieren

Wenn Sie die Standardimplementierung des Algorithmus deaktivieren und eine eigene Liste mit unsicheren Channels zur Vermeidung übergeben möchten, konfigurieren Sie das Overlay config_wifiDefaultCoexAlgorithmEnabled. Wenn das Overlay auf „false“ gesetzt ist, wird der Standardalgorithmus deaktiviert. Anschließend können Sie mit Ihrem eigenen proprietären Out-of-Band-Algorithmus eine Liste unsicherer Channels erstellen, die über die folgende System-API an das Framework übergeben werden.

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

Implementierung validieren

Verwenden Sie die folgenden Tests, um Ihre Implementierung der Funktion zur Vermeidung von Wi‑Fi-/Mobilfunk-Koexistenzkanälen zu validieren.

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)