Diese Seite wurde von der Cloud Translation API übersetzt.

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

Mit der in Android 12 eingeführten Funktion zur Vermeidung von WLAN-/Mobilfunk-Coex-Kanälen wird die Verwendung unsicherer WLAN-Kanäle in Fällen, in denen es Störungen von oder zu Mobilfunkkanälen gibt, erkannt und vermieden. Dazu gehören Schnittstellen wie STA, SoftAp, Wi-Fi Direct (P2P) und Wi-Fi Aware (NAN).

Auf dieser Seite werden die folgenden Themen behandelt:

Informationen, die das Mobilfunkmodem an das Android-Framework melden muss
Algorithmen, mit denen das WLAN-Framework zu vermeidende WLAN-Kanäle berechnet
Konfigurationstabellen, die die Gerätehersteller für das WLAN-Framework bereitstellen müssen
System-APIs, Konfigurationen und HAL-APIs im Zusammenhang mit der Kanalavoidance-Funktion
Framework-Verhalten bei Kanalumgehung
Verhalten des Chip-Anbieters zur Handhabung der Kanalvermeidung
Implementierungsdetails für die Kanalumgehung
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 beeinträchtigen. Dies tritt auf, wenn der Mobilfunk- und der WLAN-Kanal innerhalb einer kurzen Frequenztrennung (benachbarte Kanäle) liegen oder es zu harmonischen und Intermodulationsstörungen kommt.

Diese Art von Störung wird zu einem Problem, wenn eine Antenne gleichzeitig sendet und eine andere empfängt. In diesem Fall wird die Empfangsantenne von der Sendeantenne geflutet, was ihre Empfangsqualität beeinträchtigt.

In diesem Dokument wird der Sender, der die Funkstörung verursacht, als Angreifer und der Empfänger, der die Störung erleidet, als Opfer bezeichnet. Der WLAN-Kanal, der entweder der Angreifer oder das Opfer ist, wird als unsicherer Kanal bezeichnet.

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

Die Funktion führt eine Kanalumgehung durch, indem die WLAN-Kanäle gesteuert werden. Das Verfahren zur Vermeidung von WLAN-Kanälen kann als eine Reihe von vier abstrakten Schritten beschrieben werden:

Änderung der Mobilfunkfrequenz in Modemberichten
Coex-Avoidance-Algorithmus berechnet unsichere WLAN-Kanäle
Coex-Vermeidungsalgorithmus informiert den WLAN-Dienst
Framework oder Treiber führt die entsprechende WLAN-Aktion aus

Kanalvermeidungsschema

Abbildung 1. Kanalvermeidungsschema

Änderung der Mobilfunkfrequenz melden

Der Telefoniedienst meldet die derzeit genutzten Mobilfunkkanäle. Wenn sich die verwendete Mobilfunkfrequenz ändert, meldet das Modem diese Informationen über IRadio::PhysicalChannelConfig an den Telefondienst. Zu diesen Informationen gehören auch Angaben 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 Coex-Formeln, die vom Modem ausgefüllt werden müssen.

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 mehrere Arten von Interferenzen, die unterschiedliche Formeln erfordern: benachbarte und harmonische/intermodulation. Aufgrund der physischen Unterschiede bei Antenne und Layout zwischen den Geräten unterscheiden sich die Muster der benachbarten und harmonischen/Intermodulationsstörungen für jedes Gerät. Um dies zu berücksichtigen, müssen Gerätehersteller eine Suchtabelle bereitstellen, in die Parameter für die beiden Arten von Funkstörungen eingesetzt werden können. Diese Parameter werden pro Zellenband definiert und auf die Bänder der aktiven Zellenkanäle verwiesen.

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

Im Allgemeinen werden bei der Funktion zur Kanalvermeidung nach dem Best-Effort-Prinzip unsichere WLAN-Kanäle vermieden, um die Leistung zu optimieren. In bestimmten Fällen (z. B. aufgrund von Anforderungen des Mobilfunkanbieters) ist es jedoch für bestimmte Schnittstellen obligatorisch, unsichere Kanäle für bestimmte Mobilfunkbänder zu vermeiden. In solchen Fällen werden erforderliche 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 Kanal ist eine Empfehlung, diesen Kanal für alle Anwendungsfälle nicht zu verwenden. Bei obligatorischen Einschränkungen sind bestimmte Anwendungsfälle für die obligatorische Vermeidung gekennzeichnet.

Wenn jeder Kanal des 2,4‑GHz- oder 5‑GHz-Bands als unsicher gekennzeichnet ist, kann in der Suchtabelle ein Standard-2,4‑GHz- oder 5‑GHz-Kanal pro störendes Zellenband als sicherste Option definiert werden. Diese Standardkanäle werden nicht als unsichere Kanäle gemeldet, wenn der Rest des Bandes als unsicher gemeldet wird.

Überschreibungsliste

Ein formularischer Ansatz ist in Fällen mit stark bandbreitenabhängigen Störungen begrenzt. Daher sind Kanäle mit größerer Bandbreite möglicherweise nicht sicher, Kanäle mit kleinerer Bandbreite aber schon. In Fällen wie bei der datengetriebenen Anzeigenbereitstellung ist es sinnvoll, die Berechnungen zu überspringen und eine bestimmte Liste unsicherer Channels zu verwenden.

Dazu können Sie in der Suchtabelle für bestimmte Einträge eine Überschreibungsliste mit unsicheren Kanälen angeben. Eine Überschreibungsliste in einem Tabelleneintrag bedeutet, dass die Berechnung für diesen bestimmten Zellenkanal übersprungen wird und dass die unsicheren WLAN-Kanäle für den übereinstimmenden Zellenkanal in der Überschreibungsliste angegeben sind.

Bei bandbreitenempfindlichen Fällen kannst du bestimmte Bandbreiten selektiv vermeiden, indem du bestimmte Kanäle mit bestimmten Bandbreiten in der Überschreibungsliste angibst. Das liegt daran, dass jeder WLAN-Kanal einer bestimmten Bandbreite entspricht.

Die Überschreibungsliste besteht aus einer Liste von Kanalnummern oder vordefinierten Kategorie-Keywords für jedes WLAN-Band:

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, 80 MHz-Kanäle)
160mhz (5 GHz, 160 MHz-Kanäle)

Störungen durch benachbarte Kanäle

Um Störungen durch benachbarte Kanäle zu bestimmen, sorgt der Coex-Vermeidungsalgorithmus dafür, dass der Abstand ΔF zwischen einem Aggressor- und einem Opferkanal unter einen bestimmten Grenzwert fällt.

Kanalstörungen

Abbildung 2. Abstand zwischen einem Angreifer- und einem Opferkanal

Der Grenzwert wird durch die physische Konfiguration des Geräts und den Grenzwert bestimmt, der im Eintrag der Suchtabelle pro störendes Band angegeben ist. Bänder, die als nicht störend eingestuft werden, haben keinen Tabelleneintrag und unsichere Kanäle müssen in den meisten Fällen nicht berechnet werden.

Parameter für benachbarte Interferenzen

wifiVictimMhz: Grenzwert für die Entfernung in MHz für ein WLAN-Opfer (Mobilfunk-Uplink)
cellVictimMhz: MHz-Abstandsgrenzwert für ein Mobilfunk-Opfer (Mobilfunk-Downlink)

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

Es wird versucht, für das Band des Kanals einen Eintrag in der Suchtabelle zu finden. Wenn kein tabelleneitrag gefunden wird, werden keine unsicheren Kanäle für diesen Zellenkanal zurückgegeben.
Anhand des Mobilfunkbands wird ermittelt, welches WLAN-Band gefährdet ist und von welcher Seite des Bands die Störungen stammen (z.B.niedrigere 2,4‑GHz-Kanäle, höhere 2,4‑GHz-Kanäle, niedrigere 5‑GHz-Kanäle).
Wenn wifiVictimMhz vorhanden ist und der Zellenkanal einen Uplink und
1. Wenn der untere Teil des WLAN-Frequenzbands gefährdet ist
  1. Die Obergrenze für unsichere Kanäle wird ermittelt, indem der höchsten Frequenz des Mobilfunk-Uplinks wifiVictimMhz hinzugefügt wird.
  2. Der erste 20‑MHz-WLAN-Kanal wird gefunden, dessen untere Grenze die Grenze überschneidet.
  3. Kennzeichnet den WLAN-Kanal, jeden größeren Bandbreitenkanal, der ihn enthält (z. B. 40 MHz, 80 MHz) und jeden unteren Kanal desselben Bandes als unsicherer Kanal.
2. Wenn der obere Teil des WLAN-Bands gefährdet ist
  1. Hier wird die Untergrenze der unsicheren Kanäle ermittelt, indem wifiVictimMhz von der niedrigsten Frequenz des Mobilfunk-Uplinks abgezogen wird.
  2. Findet den ersten WLAN-Kanal, dessen Oberkante den Grenzwert überschneidet.
  3. Der WLAN-Kanal, alle größeren Kanäle, die ihn enthalten (z. B. 40 MHz, 80 MHz), und alle höheren Kanäle desselben Bandes wie der unsichere Kanal werden markiert.
Wenn cellVictimMhz vorhanden ist und der Zellenkanal einen Downlink hat.
1. Führt Schritt 3 mit cellVictimMhz als Grenzwert aus und vergleicht ihn mit dem Zellen-Downlink statt mit dem Zellen-Uplink.
Wendet die Power Cap des Tabelleneintrags auf die berechneten unsicheren Kanäle an.

Berechnung von unsicheren Kanälen

Abbildung 3 Berechnung eines nicht sicheren Kanals bei Überschneidungen mit benachbarten Kanälen

Harmonische oder Intermodulationsverzerrung

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

$$ 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 WLAN-Kanäle beeinträchtigt. Die Verzerrung „hoch“ und „niedrig“ werden dann durch die harmonischen Werte ersetzt, die auf den Uplinkfrequenzen der Zelle und einem harmonischen Grad N basieren.

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

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

Harmonische Verzerrung bei der Berechnung eines unsicheren Kanals

Abbildung 4 Unsicherer Kanal bei harmonischer Verzerrung

Im Fall der Intermodulation berücksichtigt der Algorithmus die Intermodulationsverzerrung des Mobilfunk-Uplinks und des WLAN-Kanals, die den Mobilfunk-Downlinkkanal beeinträchtigt. Die Verzerrung „hoch“ und „niedrig“ werden dann durch die Intermodulationswerte ersetzt, die auf den Uplinkfrequenzen der Mobilfunkzellen, 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}| $$

Intermodulationsverzerrung bei unsicherer Kanalberechnung

Abbildung 5. Berechnung des unsicheren Kanals für Intermodulationsverzerrung

Sie können in der Suchtabelle pro störendes Zellenband Werte für $ M $, $ N $ und Überschneidung angeben. Wenn für ein Band keine Funkstörungen auftreten, werden die Werte für diesen Bandeintrag aus der Tabelle weggelassen. Für die 2,4‑GHz- und 5‑GHz-Wi‑Fi-Bänder können zwei dieser Werte unabhängig voneinander definiert werden.

Ähnlich wie beim Algorithmus für benachbarte Interferenzen verwendet der Algorithmus den gleichen Leistungsobergrenze, der pro störendem Zellband definiert ist.

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

Für das Band des Zellenkanals wird versucht, einen Eintrag in der Suchtabelle zu finden. Wenn kein Tabelleneintrag gefunden wird, wird für diesen Kanal eine Rückgabe ohne unsichere Kanäle durchgeführt.
Sucht nach unsicheren 2,4‑GHz-Kanälen aus Harmonischen, wenn Parameter definiert sind.
1. Bestimmt den Oberschwingungsgrad N für 2,4 GHz.
2. Die harmonische Hochfrequenz und die harmonische Niederfrequenz werden anhand von N und dem Zelluplink berechnet.
3. Sucht den ersten 20‑MHz-WLAN-Kanal, der innerhalb der Untergrenze der von unten kommenden Harmonischen liegt.
4. Berechnet die Überschneidung der Harmonischen über den WLAN-Kanal und kennzeichnet den Kanal als unsicher, wenn die Überschneidung den Grenzwert für die WLAN-Überschneidung bei 2,4 GHz überschreitet.
5. Ermittelt den ersten 20 MHz-WLAN-Kanal, der sich innerhalb der Obergrenze der von oben kommenden Oberschwingung befindet.
6. Berechnet die Überschneidung der Harmonischen über den WLAN-Kanal und kennzeichnet den Kanal als unsicher, wenn die Überschneidung den Grenzwert für die WLAN-Überschneidung bei 2,4 GHz überschreitet.
7. Markiert alle 20‑MHz-Kanäle dazwischen als unsichere Kanäle.
Sucht nach unsicheren 5‑GHz-Kanälen anhand von Harmonischen, wenn Parameter definiert sind.
1. Ermittelt den harmonischen Grad N für 5 GHz. Wenn N 0 ist, geht es mit Schritt 5 weiter.
2. Die harmonische Hochfrequenz und die harmonische Niederfrequenz werden anhand von N und dem Zelluplink berechnet.
3. Sucht nach unsicheren 20-MHz-Kanälen.
  1. Es wird der erste 20‑MHz-WLAN-Kanal gefunden, der innerhalb der unteren Grenze der von unten kommenden Harmonischen liegt.
  2. Berechnet die Überschneidung der Harmonischen über den WLAN-Kanal und kennzeichnet den Kanal als unsicher, wenn die Überschneidung den Grenzwert für die WLAN-Überschneidung bei 2,4 GHz überschreitet.
  3. Es wird der erste 20‑MHz-WLAN-Kanal gefunden, der innerhalb der Obergrenze der Oberwelle liegt, die von oben kommt.
  4. Berechnet die Überschneidung der Harmonischen über den WLAN-Kanal und kennzeichnet den Kanal als unsicher, wenn die Überschneidung den Grenzwert für die WLAN-Überschneidung bei 2,4 GHz überschreitet.
  5. Alle dazwischen liegenden 20‑MHz-Kanäle werden als unsichere Kanäle mit der angegebenen Leistungsobergrenze gekennzeichnet.
4. Sucht nach unsicheren 40‑, 80‑ und 160‑MHz-Kanälen
  1. Wiederholen Sie Schritt 3a, aber mit 40 MHz, 80 MHz und 160 MHz.
  2. Anstatt die Überschneidungen der Kanäle an der harmonischen Kante zu berechnen, werden die berechneten Überschneidungen der kleineren zusammengesetzten Kanäle wiederverwendet. Wenn beispielsweise zwei 20‑MHz-Kanäle einen 40‑MHz-Kanal bilden und eine Überschneidung von 30% und 90% haben, beträgt die durchschnittliche Überschneidung für den 40‑MHz-Kanal 60 %.
Findet unsichere 2,4-GHz-Kanäle in Intermodulation, wenn Parameter definiert sind.
1. Bestimmt die Intermodulationskoeffizienten N und M für 2, 4 GHz.
2. Für jeden 2,4‑GHz-WLAN-Kanal:
  1. Berechnet die Intermodulationsfrequenz (niedrig) und die Intermodulationsfrequenz (hoch) basierend auf N, M, dem Uplink der Zelle und dem WLAN-Kanal.
  2. Berechnet die Überschneidung der Intermodulation über den Zellendownlink und kennzeichnet den Kanal als unsicher, wenn die Überschneidung den Grenzwert für die 2,4‑GHz-Zellenüberschneidung überschreitet.
Sucht nach unsicheren 5‑GHz-Kanälen aufgrund von Intermodulation, wenn Parameter definiert sind.
1. Wiederholen Sie Schritt 4 mit den 5‑GHz-WLAN-Kanälen und dem Grenzwert für die Überlappung von 5‑GHz-Zellen.
Die Leistungsobergrenze des Tabelleneintrags wird auf die berechneten unsicheren Kanäle angewendet.

Endergebnis

Nachdem beide Gruppen von unsicheren Kanälen aufgrund von benachbarten und harmonischen Störungen berechnet wurden, wird die endgültige Gruppe berechnet, indem die Vereinigung beider Gruppen gebildet wird (und bei Kollisionen die niedrigere Leistungsobergrenze ausgewählt wird). Die Standardkanäle werden aus der Gruppe entfernt, wenn keine obligatorischen Einschränkungen gelten.

Der Algorithmus verhält sich so:

Wenn alle 2,4‑GHz-WLAN-Kanäle als unsicher gekennzeichnet sind, wird der Standard-2,4‑GHz-WLAN-Kanal aus dem Set entfernt.
Wenn jeder 5‑GHz-WLAN-Kanal als unsicher gekennzeichnet ist, wird der Standard-5‑GHz-WLAN-Kanal aus der Gruppe entfernt.
Gibt die endgültige Liste der unsicheren Kanäle zurück.

Format der Suchtabelle

Die Suchtabellen sind in einer XML-Datei im überlagerbaren Konfigurationsstring config_wifiCoexTableFilepath enthalten und werden durch die folgende XSD definiert.


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

Hier sehen Sie ein Beispiel für eine XML-Suchtabelle:


<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 (CA) erzeugen die harmonischen oder Intermodulationsbereiche für jeden Uplink oder Downlink möglicherweise nicht genug Überschneidung, um unabhängig voneinander zu Störungen zu führen, aber in Kombination möglicherweise. Der Algorithmus betrachtet jeden harmonischen oder Intermodulationsbereich unabhängig und nimmt die Vereinigung der zurückgegebenen unsicheren Kanäle vor. Im Fall der Intermodulation bedeutet dies, den Intermodulationsbereich jedes UL auf jedes DL zu bewerten.

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

Lizenzunterstützungter Zugriff

Der Lizenzgestützte Zugriff (License Assisted Access, LAA) wird als Band 46 gekennzeichnet. Der Algorithmus behandelt diese Band ähnlich wie andere Bänder. In diesem Fall können alle 5‑GHz-Kanäle in der Suchtabelle als Überschreibungsliste festgelegt werden.

Je nach Anforderungen des Mobilfunkanbieters legt der Kanalavoidance-Algorithmus 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“ für die Anbieterkonfiguration definiert sein. Wenn der Zellenkanal LAA verwendet und restrict_5g_softap_wifi_direct_for_laa true ist, gibt der Algorithmus die Liste der unsicheren Kanäle mit dem gesamten 5‑GHz-Band zurück und setzt die obligatorischen Flags für die Einschränkung für SoftAP und Wi‑Fi Direct (P2P).

WLAN-Dienst informieren

Nachdem der Coex-Kanalalgorithmus die unsicheren Kanäle berechnet hat, können Sie Ihre System-Apps mit den unsicheren Kanälen und ihren Einschränkungen versorgen. Verwenden Sie dazu die folgende im Android-Framework definierte Datenstruktur @SystemApi.

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 ‑Callbacks, damit die Apps aktualisierte Werte abrufen können, 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 Kanalumgehung spielt, ist es wichtig, die unsicheren Kanäle an den Treiber und die Firmware weiterzuleiten. 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 Kanalumgehung mit ACS angewendet werden kann. Die Szenarien beschreiben das Verhalten des Algorithmus zur Kanalvermeidung und des Treibers oder der Firmware.

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

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.
Wenn Kanäle unsicher sind und keine Einschränkungen gelten
1. Der Treiber oder die Firmware des Anbieters priorisiert die sicheren Kanäle gegenüber den unsicheren Kanälen.

SoftAP ist mit aktiviertem ACS verfügbar und unsichere Kanäle werden aktualisiert

Wenn der SoftAP-Kanal unsicher ist und es eine SoftAP-Einschränkung gibt
1. Das Framework aktualisiert die ACS-Liste, indem die unsicheren Kanäle entfernt werden.
2. Wenn die Liste leer ist, schließt das Framework SoftAP.
Wenn der SoftAP-Kanal unsicher ist und es keine Einschränkungen gibt
1. Das Framework ergreift keine Maßnahmen. Der Treiber oder die Firmware des Anbieters kümmert sich darum, die unsicheren Kanäle zu vermeiden oder die Leistungsobergrenze anzuwenden, wenn eine Vermeidung nicht möglich ist.

Wi‑Fi Direct (P2P)

Ob es unsichere Kanäle mit Wi-Fi Direct-Einschränkungen (P2P) gibt
1. Das Framework fordert wpa_supplicant auf, die unsicheren Kanäle mithilfe der HAL-Methode ISupplicantP2pIface::setDisallowedFrequencies() zu vermeiden.
Wenn es unsichere Kanäle ohne Einschränkungen gibt.
1. Der Treiber oder die Firmware des Anbieters wendet die Leistungsobergrenze 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 Treiber oder die Firmware des Anbieters ist für die Kanalumgehung von Wi‑Fi Aware (NAN) verantwortlich.

Algorithmus deaktivieren

Wenn Sie die Standardimplementierung des Algorithmus deaktivieren und Ihre eigene Liste mit unsicheren Kanälen zur Vermeidung übergeben möchten, konfigurieren Sie das Overlay config_wifiDefaultCoexAlgorithmEnabled. Wenn das Overlay auf „false“ gesetzt ist, wird der Standardalgorithmus deaktiviert. Sie können dann mit Ihrem eigenen proprietären Out-of-Band-Algorithmus eine Liste der unsicheren Kanäle generieren, die über die folgende System-API an das Framework weitergeleitet werden sollen.

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

Implementierung validieren

Verwenden Sie die folgenden Tests, um die Implementierung der Funktion zur Vermeidung von WLAN-/Mobilfunk-Coex-Kanä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)