DE102021109548A1

DE102021109548A1 - Systeme und verfahren zur priorisierung von bidirektionalen verkehrsflüssen

Info

Publication number: DE102021109548A1
Application number: DE102021109548.4A
Authority: DE
Inventors: Nitin A. Changlani; Qiang Zhou; Sachin Ganu; Hao Lu
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2020-10-28
Filing date: 2021-04-15
Publication date: 2022-04-28
Also published as: US20220132528A1; US20230209591A1; US11617187B2; CN114501659A

Abstract

Es werden Systeme und Verfahren zur Synchronisierung von Uplink- (UL) und Downlink-(DL) Verkehr bereitgestellt. Insbesondere werden Rahmen, die mit Quality of Service (QoS)-sensitiven Verkehrsflüssen verbunden sind, die in einer ersten Richtung übertragen werden sollen, entsprechend den Rahmen priorisiert, die in einer zweiten Richtung übertragen werden sollen, die sich von der ersten Richtung unterscheidet/entgegengesetzt ist. So können beispielsweise UL-Verkehrsströme auf der Grundlage von DL-Verkehrsströmen priorisiert werden, wenn die Verkehrsströme zum selben Anwendungsstrom gehören, und umgekehrt können DL-Verkehrsströme auf der Grundlage von UL-Verkehrsströmen für denselben Anwendungsstrom priorisiert werden. Auf diese Weise kann eine Ende-zu-Ende-QoS erreicht werden.

Description

Hintergrund
In den letzten Jahren haben sich die WLAN-Technologien (Wireless Local Area Network) zu einem schnell wachsenden Markt entwickelt. Ein Beispiel für die verschiedenen WLAN-Technologien ist der 802.11-Standard des Institute of Electrical and Electronics Engineers (IEEE). Client-Geräte oder Stationen (STAs) in WLANs kommunizieren mit Access Points (APs), um Zugang zu einer oder mehreren Netzwerkressourcen zu erhalten. APs können sich auf digitale Geräte beziehen, die kommunikativ mit einem oder mehreren Netzen (z. B. Internet, Intranet usw.) verbunden sind. APs können direkt oder über einen Controller mit einem oder mehreren Netzen verbunden sein. Ein AP, auf den hier Bezug genommen wird, kann einen drahtlosen Zugangspunkt (WAP) umfassen, der drahtlos mit Geräten kommuniziert, die Wi-Fi, Bluetooth oder verwandte Standards verwenden, und der mit einem kabelgebundenen Netz kommuniziert.
APs konfigurieren verschiedene Parameter für die Kommunikation mit anderen Geräten und für die Unterstützung von Echtzeitdiensten bei gleichzeitiger Erfüllung der Anforderungen an die Dienstgüte (QoS). Die spezifischen Werte, die für verschiedene Parameter konfiguriert werden, bestimmen die Leistung eines Zugangspunkts wie Geschwindigkeit und Zuverlässigkeit.
Figurenliste
Die vorliegende Offenbarung wird in Übereinstimmung mit einer oder mehreren verschiedenen Ausführungsformen unter Bezugnahme auf die folgenden Figuren im Detail beschrieben. Die Figuren dienen lediglich der Veranschaulichung und stellen lediglich typische oder beispielhafte Ausführungsformen dar.

1 zeigt ein Beispiel für den Einsatz eines drahtlosen Netzwerks, in dem priorisierte bidirektionale Verkehrsflüsse in Übereinstimmung mit verschiedenen Ausführungsformen implementiert werden können.
2A zeigt einen Beispielzugangspunkt (AP) in Übereinstimmung mit verschiedenen Ausführungsformen, bei dem der Uplink-Verkehr (UL) auf einem Kanal nicht priorisiert ist und der Downlink-Verkehr (DL) auf demselben Kanal priorisiert ist.
2B zeigt eine Beispielrechnerkomponente zur Durchführung eines priorisierten Uplink (UL)-Verkehrsflusses auf der Grundlage des Downlink (DL)-Verkehrsflusses im AP von 2A in Übereinstimmung mit einer Ausführungsform.
2C zeigt ein Beispiel für einen Zugangspunkt (AP) in Übereinstimmung mit verschiedenen Ausführungsformen.
2D zeigt eine Beispielrechnerkomponente zur Durchführung eines priorisierten Downlink (DL)-Verkehrsflusses auf der Grundlage des Uplink (UL)-Verkehrsflusses im AP von 2A in Übereinstimmung mit einer Ausführungsform.
3 zeigt ein Beispiel für eine Computerkomponente, in der verschiedene hier beschriebene Ausführungsformen implementiert werden können.

Die Figuren sind nicht erschöpfend und beschränken die vorliegende Offenbarung nicht auf die genaue Form, die offenbart wird.
Detaillierte Beschreibung
Für Verkehrsströme, die auf die Dienstqualität (QoS) angewiesen sind, werden in drahtlosen lokalen Netzen (WLANs) im Allgemeinen Multicast-Übertragungen verwendet, die in jedem DTIM-Zeitraum oder -Intervall stattfinden. Um die Zuverlässigkeit zu gewährleisten, können solche Multicast-Übertragungen Basisraten verwenden. Dies geht jedoch auf Kosten einer ineffizienten Nutzung der Sendezeit. Die Übertragungseigenschaften solcher Multicast-Übertragungen können sich ändern. So kann eine Multicast-Übertragung z. B. Burst-Verkehr beinhalten, z. B. progressives Herunterladen beim Video-Streaming. Darüber hinaus können QoS-sensitive Übertragungen, wie 4K-Video, Virtual-Reality-Verkehr und ähnliches, auch durchsatzintensiv sein. Daher wurden viele herkömmliche Anwendungen und Stack-Implementierungen dahingehend geändert, dass Unicast- anstelle von Multicast-Übertragungen für solche (stoßartigen, durchsatzintensiven usw.) Arten von Verkehrsströmen verwendet werden.
Einige konventionelle Systeme können für die oben genannten Verkehrsströme auch TCP oder UDP verwenden. Man geht davon aus, dass solche konventionellen Anwendungen und Netze sicherstellen, dass diese Unicast-Verkehrsströme (Transmission Control Protocol (TCP)/User Datagram Protocol (UDP)) für die Übertragung über Zugangskategorien (AC), die die QoS verbessern, in eine Warteschlange gestellt werden. Doch selbst wenn die Einreihung des Verkehrsflusses in eine Warteschlange, die der gewünschten QoS entspricht, gewährleistet werden kann, gibt es keine Garantie, dass die QoS über die gesamte Übertragungsstrecke auf der Datenübertragungsschicht/Schicht 2 aufrechterhalten wird. Eine 4K-Videostreaming-Anwendung kann beispielsweise ihre Datenframes unter Verwendung von TCP in Übereinstimmung mit einer Reihe von Parameterwerten senden, die einem AC mit hoher Priorität entsprechen, z. B. einem Video-AC (VI). Eine empfangende STA kann jedoch immer noch TCP-Bestätigungen (ACKs) generieren, die mit einem AC niedrigerer Priorität gekennzeichnet sind, z. B. einem Best-Effort-AC (BE). In ähnlicher Weise kann eine bidirektionale Anwendung (eine Anwendung, bei der die zugehörigen Verkehrsströme sowohl Uplink (UL) als auch Downlink (DL) umfassen) unter einer reduzierten QoS leiden, da die umgekehrte Verbindung von ihrem Sender nicht gleich priorisiert wird.
Darüber hinaus kann es vorkommen, dass Rahmen bestimmter Verkehrsströme in Abhängigkeit von einer Vielzahl von Faktoren nicht gemäß einem AC gesendet werden, der die QoS verbessert. Beispiele für solche Faktoren sind u. a. die Art und Weise, wie Frames von einer Anwendung getaggt werden, wie Netzwerke mit dem Type-of-Service-Tag (ToS) in einem IP-Header der Frames umgehen, wie der ToS in einen AC umgewandelt wird, der für die Übertragung über ein WLAN-Netzwerk verwendet wird, usw. So kann eine Videoanwendung Frames gemäß dem BE AC und nicht gemäß dem VI AC in eine Warteschlange stellen. Obwohl verschiedene Systeme und Methoden die Priorisierung des Vorwärtsverkehrs (z. B. TCP-Datensegmente) durch priorisierte Warteschlangenbildung und Zeitplanung für bestimmte Anwendungen berücksichtigt haben, wird der Rückwärtsverkehr (z. B. TCP ACKs oder anderer Rückwärtsverkehr) in herkömmlichen Systemen nicht priorisiert.
Daher werden in Übereinstimmung mit verschiedenen Ausführungsformen Rahmen, die mit QoS-sensitiven Verkehrsflüssen verbunden sind, die in einer ersten Richtung übertragen werden sollen, entsprechend den Rahmen priorisiert, die in einer zweiten Richtung übertragen werden sollen, die sich von der ersten Richtung unterscheidet bzw. ihr entgegengesetzt ist. Beispielsweise können UL-Verkehrsströme auf der Grundlage von DL-Verkehrsströmen priorisiert werden, wenn die Verkehrsströme zum selben Anwendungsstrom gehören, und umgekehrt, wenn DL-Verkehrsströme auf der Grundlage von UL-Verkehrsströmen für denselben Anwendungsstrom priorisiert werden können. Bei einer Videokonferenz können beispielsweise Datenpakete mit Sprache auf der DL von einem AP zum Laptop eines Benutzers übertragen werden. Da der Verkehrsfluss in DL-Richtung erfolgt, hat der AP die Möglichkeit, die von ihm übertragenen Datenpakete zu priorisieren. In der umgekehrten Richtung (in diesem Fall in UL-Richtung) hat ein AP jedoch keine Kontrolle darüber, welcher AC für die Übertragung von Datenpaketen vom Laptop des Benutzers zum AP verwendet wird und/oder wie der Kanal vom Laptop des Benutzers genutzt wird, um die Übertragung der Datenpakete zu bewirken. Da der Verkehr sowohl UL- als auch DL-Komponenten oder -Anteile haben kann, wäre eine Symmetrie oder Synchronisation der QoS zwischen den UL- und DL-Komponenten/-Anteilen des Verkehrs vorzuziehen. Auf diese Weise kann eine Ende-zu-Ende-QoS erreicht werden.
Um den UL-Verkehr zu priorisieren, kann der UL-Verkehr für einen bestimmten QoS-sensiblen Anwendungsfluss häufiger eingeplant werden. Der UL-Pufferstatus kann an jeder STA abgefragt werden, um die UL-Warteschlangentiefe an jeder STA abzuschätzen. Die STAs werden nach der Priorität der Anwendungsströme und dem Pufferstatus sortiert. Der AC, mit dem jede UL-Übertragung übertragen werden soll (während der Auslösung), kann bestimmt werden. Der Modus der UL-Übertragung wird ebenfalls bestimmt (z. B. ob die UL-Übertragung mit voller oder teilweiser Bandbreite unter Verwendung von Multi-User Multiple Input Multiple Output (MU-MIMO), MU-Orthogonal Frequency Division Multiple Access (OFDMA) oder einer hybriden Kombination davon durchgeführt wird).
Um den Verkehr in der DL-Richtung auf der Grundlage der UL-Verkehrsströme zu priorisieren, werden alle UL-Verkehrsströme identifiziert, die mit einem QoS-sensitiven Anwendungsstrom verbunden sind. Der geeignete AC für die identifizierten UL-Verkehrsströme kann bestimmt werden. Der den DL-Verkehrsströmen zugeordnete AC kann so eingestellt werden, dass er mindestens dem der UL-Verkehrsströme entspricht, oder in einigen Ausführungsformen kann der ausgewählte AC eine höhere Priorität haben als der der UL-Verkehrsströme.
Bevor Ausführungsformen der offengelegten Systeme und Verfahren im Detail beschrieben werden, ist es sinnvoll, ein Beispiel für eine Netzwerkinstallation zu beschreiben, mit der diese Systeme und Verfahren in verschiedenen Anwendungen implementiert werden könnten. 1A zeigt ein Beispiel für eine Netzwerkkonfiguration 100, die für eine Organisation, wie z. B. ein Unternehmen, eine Bildungseinrichtung, eine Regierungsbehörde, eine Gesundheitseinrichtung oder eine andere Organisation, implementiert werden kann. Dieses Diagramm veranschaulicht ein Beispiel für eine Konfiguration, die in einer Organisation mit mehreren Benutzern (oder zumindest mehreren Client-Geräten 110) und möglicherweise mehreren physischen oder geografischen Standorten 102, 132, 142 implementiert ist. Die Netzwerkkonfiguration 100 kann einen Hauptstandort 102 umfassen, der mit einem Netzwerk 120 kommuniziert. Die Netzwerkkonfiguration 100 kann auch einen oder mehrere entfernte Standorte 132, 142 umfassen, die mit dem Netzwerk 120 in Verbindung stehen.
Der primäre Standort 102 kann ein primäres Netzwerk umfassen, das beispielsweise ein Büronetzwerk, ein Heimnetzwerk oder eine andere Netzwerkinstallation sein kann. Das primäre Netzwerk 102 kann ein privates Netzwerk sein, z. B. ein Netzwerk, das Sicherheits- und Zugangskontrollen enthalten kann, um den Zugang auf autorisierte Benutzer des privaten Netzwerks zu beschränken. Zu den autorisierten Benutzern können beispielsweise Mitarbeiter eines Unternehmens am Hauptstandort 102, Bewohner eines Hauses, Kunden eines Unternehmens usw. gehören.
Im gezeigten Beispiel enthält der Hauptstandort 102 ein Steuergerät 104, das mit dem Netz 120 kommuniziert. Das Steuergerät 104 kann die Kommunikation mit dem Netzwerk 120 für den primären Standort 102 bereitstellen, obwohl es nicht der einzige Punkt der Kommunikation mit dem Netzwerk 120 für den primären Standort 102 sein muss. Es wird ein einzelnes Steuergerät 104 dargestellt, obwohl der primäre Standort mehrere Steuergeräte und/oder mehrere Kommunikationspunkte mit dem Netzwerk 120 umfassen kann. In einigen Ausführungsformen kommuniziert das Steuergerät 104 mit dem Netzwerk 120 über einen Router (nicht abgebildet). In anderen Ausführungsformen stellt das Steuergerät 104 den Geräten am primären Standort 102 Routerfunktionen zur Verfügung.
Ein Controller 104 kann Netzwerkgeräte konfigurieren und verwalten, z. B. am Hauptstandort 102, und kann auch Netzwerkgeräte an den entfernten Standorten 132, 134 verwalten. Der Controller 104 kann Switches, Router, Zugangspunkte und/oder Client-Geräte, die mit einem Netzwerk verbunden sind, konfigurieren und/oder verwalten. Das Steuergerät 104 kann selbst ein Zugangspunkt sein oder die Funktionalität eines solchen bereitstellen.
Der Controller 104 kann mit einem oder mehreren Switches 108 und/oder drahtlosen Access Points (APs) 106a-c kommunizieren. Die Switches 108 und die drahtlosen APs 106a-c bieten Netzwerkkonnektivität für verschiedene Client-Geräte/STAs 110a-j. Über eine Verbindung zu einem Switch 108 oder AP 106a-c kann ein STA 110a-j auf Netzwerkressourcen zugreifen, einschließlich anderer Geräte im (primären Standort 102) Netzwerk und im Netzwerk 120.
Wie hierin verwendet, bezieht sich ein Client-Gerät oder STA auf ein Gerät mit einem Prozessor, Speicher und E/A-Schnittstellen für drahtgebundene und/oder drahtlose Kommunikation. Beispiele für STAs können sein: Desktop-Computer, Laptop-Computer, Server, Webserver, Authentifizierungsserver, Authentifizierungs-Autorisierungs-Accounting (AAA)-Server, Domain Name System (DNS)-Server, Dynamic Host Configuration Protocol (DHCP)-Server, Internet Protocol (IP)-Server, Virtual Private Network (VPN)-Server, Netzwerkrichtlinienserver, Großrechner, Tablet-Computer, E-Reader, Netbook-Computer, Fernsehgeräte und ähnliche Monitore (z. B., Smart-TVs), Inhaltsempfänger, Set-Top-Boxen, persönliche digitale Assistenten (PDAs), Mobiltelefone, Smart-Phones, intelligente Terminals, stumme Terminals, virtuelle Terminals, Videospielkonsolen, virtuelle Assistenten, Geräte des Internets der Dinge (IOT) und dergleichen.
Innerhalb des primären Standorts 102 ist ein Switch 108 als ein Beispiel für einen Zugangspunkt zu dem am primären Standort 102 eingerichteten Netzwerk für kabelgebundene STA 110i-j enthalten. STAs 110i-j können sich mit dem Switch 108 verbinden und über den Switch 108 auf andere Geräte innerhalb der Netzwerkkonfiguration 100 zugreifen. Die STAs 110i-j können über den Switch 108 auch auf das Netzwerk 120 zugreifen. Die STAs 110i-j können mit dem Switch 108 über eine drahtgebundene Verbindung 112 kommunizieren. Im dargestellten Beispiel kommuniziert der Switch 108 mit dem Steuergerät 104 über eine drahtgebundene Verbindung 112, obwohl diese Verbindung auch drahtlos sein kann.
Die drahtlosen APs 106a-c sind ein weiteres Beispiel für einen Zugangspunkt zu dem Netzwerk, das am Hauptstandort 102 für die STAs 110a-h eingerichtet wurde. Jeder der APs 106a-c kann eine Kombination aus Hardware, Software und/oder Firmware sein, die so konfiguriert ist, dass sie drahtlose Netzwerkkonnektivität für drahtlose STAs 110a-h bereitstellt.
Im dargestellten Beispiel können die APs 106a-c vom Controller 104 verwaltet und konfiguriert werden. Die APs 106a-c kommunizieren mit dem Steuergerät 104 und dem Netzwerk über Verbindungen 112, die entweder verdrahtete oder drahtlose Schnittstellen sein können.
Bei dem Netzwerk 120 kann es sich um ein öffentliches oder privates Netzwerk handeln, wie z. B. das Internet oder ein anderes Kommunikationsnetzwerk, das die Verbindung zwischen den verschiedenen Standorten 102, 130 bis 142 sowie den Zugriff auf die Server 160ab ermöglicht. Das Netzwerk 120 kann Telekommunikationsleitungen von Drittanbietern umfassen, wie z. B. Telefonleitungen, Rundfunk-Koaxialkabel, Glasfaserkabel, Satellitenkommunikation, zellulare Kommunikation und Ähnliches. Das Netzwerk 120 kann eine beliebige Anzahl von zwischengeschalteten Netzwerkgeräten enthalten, wie Switches, Router, Gateways, Server und/oder Controller, die nicht direkt Teil der Netzwerkkonfiguration 100 sind, aber die Kommunikation zwischen den verschiedenen Teilen der Netzwerkkonfiguration 100 und zwischen der Netzwerkkonfiguration 100 und anderen mit dem Netzwerk verbundenen Einheiten erleichtern.
Ein AP bezieht sich im Allgemeinen auf ein Netzwerkgerät, das es einem Client-Gerät oder einer STA ermöglicht, sich mit einem drahtgebundenen oder drahtlosen Netzwerk zu verbinden, in diesem Fall mit dem drahtlosen Netzwerk 100. Ein AP kann einen Prozessor, einen Speicher und E/A-Schnittstellen umfassen, einschließlich drahtgebundener Netzwerkschnittstellen wie IEEE 802.3 Ethernet-Schnittstellen sowie drahtloser Netzwerkschnittstellen wie IEEE 802.11 WiFi-Schnittstellen, obwohl die Beispiele der Offenlegung nicht auf solche Schnittstellen beschränkt sind. Ein AP kann einen Speicher enthalten, einschließlich eines Schreib-Lese-Speichers und einer Hierarchie von persistenten Speichern wie ROM, EPROM und Flash-Speicher. Darüber hinaus kann sich ein AP, wie hier verwendet, auf Empfangspunkte für jede bekannte oder geeignete drahtlose Zugangstechnologie beziehen, die später bekannt werden kann. Insbesondere soll der Begriff AP nicht auf IEEE 802.11-basierte APs beschränkt sein.
Es ist zu beachten, dass APs wie AP 130, AP 132 und AP 134 in der Lage sind, VAPs zu implementieren, d. h. Unterstützung für einen oder mehrere unterschiedliche SSID-Werte über ein einziges AP-Funkgerät mit eindeutigen MAC-Adressen pro SSID (d. h. BSSID). Wie bekannt, ist eine SSID ein Feld zwischen 0 und 32 Oktetten, das als Informationselement (IE) in Management-Frames enthalten sein kann. Im Zusammenhang mit dem 802.11-Standard gehören zu den Management-Frames, die die SSID-IE unterstützen, die Beacon-, Probe-Request/Response- und Association/Reassociation-Request-Frames. In einer Ausführungsform unterstützt ein AP VAPs mit mehreren BSSIDs. Jede Bake- oder Probe-Antwort kann eine einzelne SSID-IE enthalten. Der AP sendet Beacons für jeden VAP, den er unterstützt, in einem Beacon-Intervall (z. B. 100 ms) und verwendet eine eindeutige BSSID für jeden VAP. Der Zugangspunkt antwortet auf Prüfanforderungen für unterstützte SSIDs (einschließlich einer Anforderung für die Broadcast-SSID) mit einer Prüfantwort, die die jeder BSSID entsprechenden Fähigkeiten enthält. In einer Ausführungsform kann ein AP bis zu einer bestimmten Anzahl (z. B. 16) von Baken ankündigen, jede mit einer anderen BSSID, um die VAP-Unterstützung bereitzustellen. Jeder VAP kann eine eindeutige MAC-Adresse haben, und jedes Beacon kann einen Netzwerknamen haben.
Es sollte klar sein, dass die hier betrachtete drahtlose Kommunikation die Konfiguration eines oder mehrerer Parameter beinhalten kann, die eine QoS für die Kommunikation durch oder mit WLAN-Geräten, wie z. B. APs, bestimmen. Die Parameterwerte bestimmen, wie häufig WLAN-Geräte den Zugang zu einem Funkfrequenzkanal anfordern und/oder einen Funkfrequenzkanal nutzen. Parameterwerte für ein bestimmtes WLAN-Gerät, die dazu führen, dass ein Funkfrequenzkanal (oder ein überlappender Teil zweier Funkfrequenzkanäle) von diesem bestimmten WLAN-Gerät im Vergleich zu anderen WLAN-Geräten häufiger genutzt wird, können hier als aggressive Parameterwerte bezeichnet werden. Darüber hinaus können Parameterwerte, die im Vergleich zu Standard- oder Industriestandard-Parameterwerten für den Kanalzugriff aggressiver sind, hier auch als aggressive Parameterwerte bezeichnet werden. Beispiele für Parameter sind EDCA-Parameter (Enhanced Distributed Channel Access) und HCCA-Parameter (Hybrid Coordination Function Controlled Channel Access).
Zu den EDCA-Parametern gehören unter anderem die folgenden:

a. Zugangskategorie - Ein Zugangskategorie-Parameter bezieht sich auf einen Sprach-AC, einen Video-AC, einen Best-Effort-AC oder einen Hintergrund-AC. Wie in der 802.11-Norm beschrieben, kann es mehrere ACs geben, und jeder AC kann mit einer anderen Prioritätsstufe verbunden sein.
b. Arbitration Inter-Frame Spacing (AIFS) - ein Zeitintervall zwischen Rahmen, die nach dem IEEE 802.11-Standard übertragen werden.
c. Minimum Contention Window (CWmin)-Eingabe für einen Algorithmus, der die anfängliche zufällige Backoff-Wartezeit für die Wiederholung einer Übertragung als Reaktion auf einen fehlgeschlagenen Versuch (z. B. aufgrund der Nichtverfügbarkeit eines Funkfrequenzkanals) bestimmt. Die zufällige Backoff-Wartezeit kann erhöht werden, wenn eine Rahmenübertragung aufgrund der Nichtverfügbarkeit des Kanals für die Übertragung fehlgeschlagen ist.
d. Maximum Contention Window (CWmax) - Die maximale Wartezeit für zufällige Backoffs.
e. Maximum Burst - Die maximale Burst-Länge, die für Paket-Bursts (Sammlung von mehreren Rahmen, die ohne Header-Informationen übertragen werden) im drahtlosen Netzwerk zulässig ist.
f. Transmission Opportunity (TXOP) Limit - Ein Zeitintervall, in dem ein Client-Gerät das Recht hat, Übertragungen in Richtung eines Access Points zu initiieren und so viele Frames wie möglich zu senden.
g. Beacon-Intervall - Zeitintervall zwischen den Übertragungen von Beacon-Frames. Ein Beacon-Frame ist einer der Management-Frames in IEEE 802.11-basierten WLANs und enthält Informationen über das Netzwerk. Ein von einem Access Point gesendeter Beacon-Frame kann Werte für Parameter enthalten, die mit diesem Access Point verbunden sind.
h. DTIM-Periode - Eine Zahl, die bestimmt, wie oft ein Bakenrahmen eine DTIM enthält. Ein Wert der DTIM ist in jedem Beacon-Frame enthalten. Ein DTIM ist in Beacon-Frames enthalten, um den Client-Geräten anzuzeigen, ob der Zugangspunkt Broadcast- und/oder Multicast-Daten gepuffert hat, die auf die Client-Geräte warten.

In einigen Ausführungsformen werden, wie oben angedeutet, ACs zur Klassifizierung des Netzverkehrs definiert. Jeder AC (konfiguriert für einen AP) ist mit einem entsprechenden Satz von Parameterwerten verbunden. Die Übertragung von Rahmen, die unter einem bestimmten AC klassifiziert sind, kann gemäß dem Satz von Parameterwerten, die diesem bestimmten AC entsprechen, übertragen werden. Das heißt, ACs können mit Warteschlangen verglichen werden, die ein AP mit Daten füllen kann und von denen aus diese Daten übertragen werden können. In der Regel gibt es vier Arten von ACs (siehe unten), die verschiedenen Arten von Anwendungen zugewiesen werden können, wobei jede ihre eigenen QoS-Anforderungen/Parameter hat. Sobald ein AC einem Anwendungstyp zugewiesen ist, kann außerdem konfiguriert werden, wie der Verkehr/die Daten in eine Warteschlange gestellt werden und wie der Verkehr/die Daten aus der Warteschlange genommen werden. Es versteht sich, dass eine bestimmte AC mit einer oder mehreren Warteschlangen/Unterwarteschlangen verbunden sein kann.
Tabelle 1 zeigt ein Beispiel für vier ACs (Background (BK), Best Effort (BE), Video (VI) und Voice (VO)) und die entsprechenden Parameterwerte, wie sie für einen ersten AP konfiguriert sind. Tabelle 1

AC CWmin CWmax AIFS Max. TXOP

Hintergrund (BK) 15 1023 7 0

Bestes Bemühen 15 1023 3 0

(BE)

Video (VI) 7 15 2 3,008 ms

Stimme (VO) 3 7 2 1,5404 ms
Im obigen Beispiel werden die unter die Kategorie Video fallenden Bilder vom ersten AP mit dem Wert 7 für CWmin, dem Wert 15 für CWmax und dem Wert 2 für AIFS übertragen. Ein zweiter AP kann anders konfiguriert werden als der erste AP, indem andere Parameterwerte verwendet werden.
Tabelle 2 zeigt ein Beispiel für vier ACs und zugehörige Parameterwerte, wie sie für einen zweiten AP konfiguriert sind, der sich vom ersten AP unterscheidet. Tabelle 2

AC CWmin CWmax AIFS Max. TXOP

Hintergrund (BK) 15 1023 7 0

Bestes Bemühen 15 1023 3 0

(BE)

Video (VI) 5 10 1 3,008 ms

Stimme (VO) 3 7 2 1,5404 ms
Im obigen Beispiel werden die unter VI AC klassifizierten Frames vom zweiten AP mit dem Wert 5 für CWmin, dem Wert 10 für CWmax und dem Wert 1 für AIFS übertragen. Der zweite AP kann aggressiver konfiguriert werden als der erste AP, da der zweite AP niedrigere Werte für CWmin, CWmax und AIFS hat. Dies kann zu häufigeren Versuchen führen, einen Kanalzugang zu erhalten und zu einer häufigeren Übertragung von Frames.
Der erste AP und der zweite AP konkurrieren um den Zugang zum gemeinsamen Funkfrequenzkanal. In einem Beispiel versucht der erste AP, Pakete für einen bestimmten Videostream zu übertragen, während der zweite AP gleichzeitig einen ersten Satz von Paketen für einen anderen Videostream sendet. Da der Funkfrequenzkanal für den ersten AP nicht verfügbar ist (der Funkfrequenzkanal wird vom zweiten AP verwendet, um den ersten Satz von Paketen zu senden), versucht der erste AP erneut, nach einer zufälligen Zeitspanne zu senden, die zumindest auf der Grundlage von CWmin und CWmax berechnet wird. Die zufällige Zeitspanne kann hier als zufällige Backoff-Zeit bezeichnet werden. Der zweite Zugangspunkt kann jedoch einen zweiten Satz von Paketen übertragen, wenn der erste Zugangspunkt es erneut versucht, weil die vom zweiten Zugangspunkt verwendeten niedrigeren Werte für CWmin und CWmax dazu führen, dass der zweite Zugangspunkt häufiger als der erste Zugangspunkt den Kanalzugang anfordert. Außerdem sendet der zweite AP mehr Frames pro Zeitperiode als der erste AP, weil der AIFS-Parameterwert für den zweiten AP niedriger ist. Der Unterschied in den Parameterwerten führt dazu, dass der zweite AP einen mit dem ersten AP gemeinsam genutzten Kanal für einen größeren Prozentsatz der Zeit zur Übertragung von Videodaten nutzt als der erste AP.
2A ist eine schematische Darstellung eines Beispiels eines AP 200 gemäß einer Ausführungsform. AP 200 kann ein Netzwerkgerät sein, das z. B. Folgendes umfassen kann: einen Prozessor 202, einen Speicher/Datenspeicher 204, ein Funkgerät 206 (und die entsprechende Antenne 206A) und eine Priorisierungslogik 208.
Der Speicher 204 kann einen schnellen Schreib-Lese-Speicher zum Speichern von Programmen und Daten während des Betriebs von AP 200 und eine Hierarchie von dauerhaften Speichern wie ROM, EPROM und Flash-Speicher zum Speichern von Anweisungen und Daten umfassen, die für die Inbetriebnahme und/oder den Betrieb von AP 200 benötigt werden. Im Speicher 204 können Daten gespeichert werden, die von AP 200 übertragen werden sollen, oder Daten, die von AP 200 empfangen werden. In einigen Ausführungsformen ist der Speicher 204 ein verteilter Satz von Datenspeicherkomponenten. Obwohl nicht dargestellt, sollte man sich darüber im Klaren sein, dass AP 200 weiterhin Eingabe-/Ausgabeschnittstellen enthalten kann, einschließlich drahtgebundener Netzwerkschnittstellen wie IEEE 802.3 Ethernet-Schnittstellen sowie drahtloser Netzwerkschnittstellen wie IEEE 802.11 Wi-Fi-Schnittstellen, obwohl die Beispiele der Offenlegung nicht auf solche Schnittstellen beschränkt sind.
Der Prozessor 202 ist mit mindestens einem Speicher 204 verbunden. Der Prozessor 202 kann eine beliebige Verarbeitungsvorrichtung sein, einschließlich, aber nicht beschränkt auf einen Prozessor der MIPS-Klasse, einen Mikroprozessor, einen digitalen Signalprozessor, eine anwendungsspezifische integrierte Schaltung, einen Mikrocontroller, eine Zustandsmaschine oder eine beliebige Art von programmierbarem Logik-Array.
Das Funkgerät 206 kann ein 5-GHz-Funkgerät, ein 2,4-GHz-Funkgerät oder eine andere geeignete drahtlose Kommunikationskomponente für die drahtlose Kommunikation sein. Das Funkgerät 206 kann so konfiguriert sein, dass es sowohl Daten senden als auch empfangen kann. Das Funkgerät 206 kann einem Kommunikationskanal 201 zugeordnet sein. In einigen Beispielen arbeitet der Kommunikationskanal 201 auf einem Kommunikationsband (z. B. 5,0-GHz-UNII-Band) und arbeitet in Übereinstimmung mit einer bestimmten drahtlosen Spezifikation (z. B. 802.11ax). Durch den Betrieb gemäß einer bestimmten Spezifikation, wie z. B. IEEE 802.11ax, kann der Kommunikationskanal 201 beispielsweise OFDMA, räumliche Wiederverwendung, MU-MIMO und/oder Kombinationen davon verwenden. Im weiteren Sinne kann ein drahtloses Client-Gerät/STA mit einer Kapazität, die der jeweiligen drahtlosen Spezifikation entspricht, in solchen Beispielen die Kapazität haben, OFDMA, räumliche Wiederverwendung, UL MU-MIMO und/oder Kombinationen davon zu verwenden. Es sollte verstanden werden, dass AP 200 eine Vielzahl von Funkgeräten (physisch und/oder logisch) haben kann und für jedes Funkgerät oder jede Gruppe von Funkgeräten dedizierte oder gemeinsam genutzte Kanäle haben kann.
In einer Ausführungsform kann die Priorisierungslogik 208 eine oder mehrere funktionale Einheiten umfassen, die mit Hilfe von Firmware, Hardware, Software oder einer Kombination davon implementiert sind, um Parameter zu konfigurieren, die mit dem AP 200 für die Übertragung von Daten/Frames zum und vom AP 200 verbunden sind. Obwohl die Priorisierungslogik 208 als auf dem AP 200 implementiert dargestellt ist, können eine oder mehrere physische oder funktionale Komponenten der Priorisierungslogik 208 auf einem separaten Gerät implementiert sein, wie z. B. einem AP-Controller, bei dem es sich beispielsweise um den Controller 104 von 1 handeln kann.
Für Verkehrsflüsse, die als prioritär gekennzeichnet sind, priorisieren verschiedene Ausführungsformen die in umgekehrter Richtung gesendeten Rahmen (z. B. UL-Richtung, während der Vorwärtsverkehr in DL-Richtung verläuft) auf der Grundlage der Prioritätseinstellung für die in Vorwärtsrichtung gesendeten Rahmen (z. B. DL-Richtung, während der Rückwärtsverkehr in UL-Richtung verläuft) und umgekehrt. Wie in 2A dargestellt, kann AP 200 Frames von STA 210-1 über den Kommunikationskanal 201 in der UL-Richtung empfangen, während er Frames an STA 210-1 in der DL-Richtung sendet. Wie oben erwähnt und entsprechend diesem Beispielszenario werden Rahmen oder Datenpakete, die in UL-Richtung von STA 210-1 an AP 200 gesendet werden (z. B. wie im Fall von Videokonferenzrahmen, die von einem Laptop an den Heim-AP gesendet werden), nicht priorisiert, während Rahmen oder Datenpakete, die in DL-Richtung von AP an STA 210-1 gesendet werden, priorisiert werden können. Wie weiter unten in Bezug auf 2B näher erläutert wird, synchronisiert eine Ausführungsform die UL/DL-Kommunikation oder schafft eine Symmetrie dazwischen.
Es sollte klar sein, dass verschiedene Ausführungsformen in der Lage sind, eine bidirektionale Priorisierung in einer Vielzahl von Szenarien zu bewirken. Zum Beispiel kann in einigen Kommunikationsszenarien der Datenfluss in einer bestimmten Richtung stark verzerrt sein. Das heißt, der Datenfluss kann in einer Richtung, d. h. der Sende- oder Empfangsrichtung, im Vergleich zu einer anderen Richtung, d. h. der Empfangs- oder Senderichtung, stärker ausgeprägt sein. Bei einem AP, wie z. B. AP 200, kann ein stark verzerrter Verkehrsfluss beispielsweise DL-TCP-Verkehr umfassen, während der entsprechende UL-Verkehr aus TCP ACKs besteht. Ein anderes Beispiel ist der UL-TCP-Verkehr, bei dem der entsprechende DL-Verkehr wiederum aus TCP ACKs besteht. Darüber hinaus können bidirektionale Verkehrsströme, wie z. B. UDP-Verkehrsströme, in eine bestimmte Richtung verzerrt sein.
In anderen Kommunikationsszenarien kann der Datenfluss bidirektional sein. Beispielsweise kann ein AP, wie AP 200, bidirektionale Verkehrsflüsse gegenüber einem bidirektionalen Satz von TCP- und/oder UDP-Verkehrsflüssen mit vergleichbaren/ähnlichen Verkehrsmengen sowohl in der UL- als auch in der DL-Richtung bewirken.
Es sollte klar sein, dass die hier offengelegte bidirektionale Priorisierung von Verkehrsflüssen/Datenübertragungen nicht auf die Verwendung mit APs/AP-Controllern beschränkt sein muss, sondern zur Priorisierung von bidirektionalem Verkehr in Nicht-AP-Geräten verwendet werden kann, die z. B. in Peer-to-Peer- oder Mesh-Netzwerktopologien arbeiten. Daher können verschiedene hier offengelegte und/oder in Betracht gezogene Ausführungsformen verwendet werden, um die herkömmliche Warteschlangenbildung und/oder Planung von Daten, Rahmen usw. in zwei Richtungen (UL und DL) relativ zu einem bestimmten Gerät zu verbessern. Die verbesserte Warteschlangenbildung/Planung von Daten kann auch pro Anwendung angewendet oder genutzt werden, wodurch ein Mechanismus (Mechanismen) zur Unterscheidung zwischen Anwendungen in umgekehrter Richtung bereitgestellt wird. Das heißt, wenn ein Netz, z. B. das Netz 100 (1) oder ein Teil davon, überlastet ist, kann bestimmten Anwendungen eine höhere Priorität eingeräumt werden als anderen.
Wie hier verwendet, kann sich der Begriff „Verkehrsfluss“ auf einen Strom von Datenpaketen, z. B. Segmenten oder Datagrammen, beziehen, die dasselbe 5-Tupel haben. Das oben erwähnte 5-Tupel kann sich auf einen Satz von fünf verschiedenen Werten beziehen, die eine TCP/IP-Verbindung umfassen, und beinhaltet: Quell-IP-Adresse, Ziel-IP-Adresse, Quell-Port-Adresse, Ziel-Port-Adresse und das verwendete Protokoll (TCP/UDP).
Wie hier verwendet, kann sich der Begriff „Anwendungsfluss“ auf eine Gruppe von Verkehrsflüssen (5-Tupel) beziehen, die eine Anwendung zur Kommunikation verwenden kann. Das heißt, ein Anwendungsfluss kann mehrere Verkehrsflüsse umfassen, die jeweils unterschiedliche Übertragungsprioritäten haben können. Bei einer Videokonferenzschaltung kann beispielsweise ein erster Verkehrsfluss, der zum Anwendungsfluss der Videokonferenzschaltung gehört, ein Sprachverkehrsfluss sein, ein zweiter Verkehrsfluss kann ein Verkehrsfluss für die Bildschirmfreigabe sein, ein dritter Verkehrsfluss kann ein Chat-Verkehrsfluss sein, ein vierter Verkehrsfluss kann ein Video-Verkehrsfluss sein, usw. Die Art und Weise, in der die (von/in einer Anwendung übertragenen) Daten charakterisiert werden, kann z. B. von einem Entwickler oder einer anderen Einheit, die die Anwendung steuert, die Anwendung bereitstellt usw., festgelegt werden, so dass die Deep Packet Inspection (siehe unten) verwendet werden kann, um diesen Datenverkehr zu identifizieren und zu klassifizieren, so dass er einem geeigneten AC zugewiesen und schließlich, wie hierin beschrieben, priorisiert werden kann.
Es sei darauf hingewiesen, dass eine Deep Packet Inspection für Verkehrsflüsse durchgeführt werden kann, um festzustellen, ob die Segmente/Datagramme für einen bestimmten Verkehrsfluss zu einem bestimmten Anwendungsfluss gehören oder nicht. Beispielsweise können die einem bestimmten Anwendungsfluss zugeordneten Metadaten den Satz von Verkehrsflüssen (jeder Verkehrsfluss hat ein zugehöriges 5-Tupel, einen Satz von fünf verschiedenen Parameterwerten, der eine UDP/TCP-Sitzung identifiziert) enthalten, den der bestimmte Anwendungsfluss zu einem bestimmten Zeitpunkt während der Übertragung/des Empfangs von Daten vom/am AP verwendet, zusätzlich zu den Richtungsmerkmalen der Verkehrsflüsse. Es versteht sich, dass die Deep Packet Inspection feststellen kann, welche(r) Verkehrsfluss(e) mit demselben Anwendungsfluss verbunden ist/sind, und dass sie, wie oben erwähnt, durchgeführt werden kann, um festzustellen, ob ein bestimmter Verkehrsfluss (eines Anwendungsflusses) streng unidirektional ist (z. B. ein UDP-Verkehrsfluss in nur einer Richtung). Eine tiefe Paketprüfung kann durchgeführt werden, um festzustellen, ob ein Verkehrsfluss bidirektional ist, bei dem die Daten nur in eine Richtung fließen (z. B. ein TCP-Verkehrsfluss, bei dem Daten in eine Richtung übertragen und ACKs in die entgegengesetzte Richtung empfangen werden, oder ein Paar von UDP-Verkehrsflüssen, bei dem ein erster Verkehrsfluss schwerer ist als ein zweiter Verkehrsfluss). Deep Packet Inspection kann durchgeführt werden, um festzustellen, ob ein Verkehrsfluss bidirektional ist, bei dem Daten in beide Richtungen fließen (z. B. ein bidirektionalerTCP-Fluss mit Daten und Huckepack-ACKs in beide Richtungen oder ein Paar von UDP-Verkehrsflüssen, bei denen jeder der UDP-Verkehrsflüsse gleich oder ähnlich schwer ist (aus Sicht des Durchsatzes und/oder aus Sicht der Latenztoleranz). In Bezug auf den Durchsatz sind schwere Verkehrsflüsse solche, die einer Dateiübertragung ähneln (z. B. bei Dateigrößen in der Größenordnung von einigen MB/einem langen Strom von PPDUs mit möglicherweise großen PPDU-Größen). Unter dem Gesichtspunkt der Latenztoleranz können sich schwere Verkehrsströme auf Verkehr beziehen, der weniger latenztolerant ist, z. B. Sprachverkehr, bei dem ein Paket z. B. einmal alle 20 ms erzeugt werden kann und nach der Erzeugung innerhalb eines strengen Zeitrahmens übertragen und erfolgreich empfangen werden muss.
Es sollte klar sein, dass die Priorisierung des Verkehrs in einem unidirektionalen Fall, insbesondere im Fall von DL-Verkehr, von internen Software-/Hardware-Implementierungsaspekten/Merkmalen abhängen kann, die die Planung des Verkehrs beeinflussen oder verändern können. Durch die Analyse der Metadaten eines Anwendungsflusses stellen AP-Implementierungen sicher, dass diejenigen Verkehrsflüsse, die zu einem Anwendungsfluss mit hoher Priorität gehören, mit einer entsprechend höheren Priorität über die Luft eingeplant werden. Dies kann z. B. dadurch erreicht werden, dass die Planungshäufigkeit für die Verkehrsströme eines Anwendungsstroms erhöht wird und/oder dass sichergestellt wird, dass der AC, gemäß dem die Datenpakete in einem Verkehrsstrom übertragen werden (und gemäß einer oder mehreren QoS-Anforderungen einer Anwendung), mindestens gleich ist, selbst wenn die Anwendung die Datenpakete, aus denen ihre Verkehrsströme bestehen, nicht gemäß ihren QoS-Anforderungen gekennzeichnet hat.
Auf diese Weise kann der DL-Verkehr eines bestimmten Anwendungsflusses priorisiert werden, und die Prioritätsstufe, die dem UL-Verkehr desselben Anwendungsflusses zugewiesen werden sollte, kann zumindest die gleiche sein. In ähnlicher Weise kann ein Anwendungsfluss, der von einer STA in/für die UL-Richtung unabhängig priorisiert wird, als Hinweis auf die Prioritätsstufe verwendet werden, die dem DL-Verkehr für denselben Anwendungsfluss zugewiesen werden sollte.
2B ist ein Blockdiagramm einer beispielhaften Rechnerkomponente oder Vorrichtung 220 zur Priorisierung des UL-Verkehrsflusses auf der Grundlage des DL-Verkehrsflusses für einen bestimmten Anwendungsfluss gemäß einer Ausführungsform. Bei der Rechnerkomponente 220 kann es sich beispielsweise um einen Servercomputer, einen Controller oder eine andere ähnliche Rechnerkomponente handeln, die in der Lage ist, Daten zu verarbeiten. In der Beispielimplementierung von 2B umfasst die Rechnerkomponente 220 einen Hardwareprozessor 222 und ein maschinenlesbares Speichermedium 224. In einigen Ausführungsformen kann die Rechnerkomponente 220 eine Ausführungsform eines Controllers sein, z. B. ein Controller wie Controller 104 (1) oder eine andere Komponente des drahtlosen Netzwerks 100, z. B. ein AP wie AP 106a (1), zum Beispiel.
Bei dem Hardware-Prozessor 222 kann es sich um eine oder mehrere Zentraleinheiten (CPUs), halbleiterbasierte Mikroprozessoren und/oder andere Hardwarevorrichtungen handeln, die zum Abrufen und Ausführen von Anweisungen geeignet sind, die in einem maschinenlesbaren Speichermedium 224 gespeichert sind. Der Hardware-Prozessor 222 kann Befehle, wie die Befehle 226-238, abrufen, dekodieren und ausführen, um Prozesse oder Operationen zur Priorisierung bidirektionaler Verkehrsflüsse zu steuern. Alternativ oder zusätzlich zum Abrufen und Ausführen von Befehlen kann der Hardware-Prozessor 222 einen oder mehrere elektronische Schaltkreise enthalten, die elektronische Komponenten zur Ausführung der Funktionalität eines oder mehrerer Befehle umfassen, wie z. B. ein Field Programmable Gate Array (FPGA), anwendungsspezifische integrierte Schaltkreise (ASIC) oder andere elektronische Schaltkreise.
Ein maschinenlesbares Speichermedium, wie das maschinenlesbare Speichermedium 224, kann ein beliebiges elektronisches, magnetisches, optisches oder anderes physikalisches Speichergerät sein, das ausführbare Anweisungen enthält oder speichert. So kann das maschinenlesbare Speichermedium 224 beispielsweise ein Direktzugriffsspeicher (RAM), ein nichtflüchtiger Arbeitsspeicher (NVRAM), ein elektrisch löschbarer, programmierbarer Festspeicher (EEPROM), ein Speichergerät, eine optische Platte und dergleichen sein. In einigen Ausführungsformen kann das maschinenlesbare Speichermedium 224 ein nicht-transitorisches Speichermedium sein, wobei der Begriff „nicht-transitorisch“ nicht die transitorischen Übertragungssignale umfasst. Wie unten im Detail beschrieben, kann das maschinenlesbare Speichermedium 224 mit ausführbaren Befehlen kodiert sein, zum Beispiel mit den Befehlen 226-238.
Der Hardware-Prozessor 222 kann den Befehl 226 ausführen, um alle DL-Verkehrsströme für jeden Anwendungsstrom hoher Priorität zu identifizieren. Wie bereits erwähnt, kann eine Deep Packet Inspection für Verkehrsflüsse durchgeführt werden, um festzustellen, ob die Segmente/Datagramme für einen bestimmten Verkehrsfluss zu einem bestimmten Anwendungsfluss gehören oder nicht.
Der Hardware-Prozessor 222 kann den Befehl 228 ausführen, um den UL-Pufferstatus von Clients zu bestimmen, die mit jedem der Anwendungsflüsse hoher Priorität verbunden sind. Um die Bestimmung/Einstellung der UL-Planungshäufigkeit und eines Übertragungsmodus für priorisierten Verkehr zu unterstützen, kann eine Schätzung der UL-Verkehrsanforderungen von einem Zielgerät für den Anwendungsfluss ermittelt werden. Da sich die UL-Warteschlangentiefe auf einer Ziel-StA aufgrund verschiedener Faktoren (z. B. Verhalten der Anwendung, Datenverbrauchsrate auf der STA usw.) ändern kann, kann die Schätzung der UL-Warteschlangentiefe in Echtzeit in häufigen Intervallen durchgeführt werden. Der 802.11ax-Standard bietet die Möglichkeit, den Pufferstatus eines STA mithilfe eines BSRP-Trigger-Frames (Buffer Status Report Poll) abzufragen, mit dem ein AP die UL-Warteschlangentiefe des STA zu jedem beliebigen Zeitpunkt abschätzen kann. Für Anwendungsströme mit hoher Priorität kann der BSRP-Trigger an das Ende eines WLAN-Rahmens (PPDU) angehängt werden, der auf der DL gesendet wird. Dieses Anhängen des BSRP-Triggers kann für alle Rahmen oder mit einer bestimmten Periodizität erfolgen, so dass die Antwort (QoS Control-Frames oder BSR-Frames) auf den BSRP-Trigger von der STA mit einer Rate empfangen werden kann, die die aktuelle Warteschlangentiefe auf der STA mit ausreichend besserem Vertrauen beschreibt als andere Clients mit nicht hochpriorem Verkehr.
Der Hardware-Prozessor 222 kann die Anweisung 230 ausführen, um die STAs auf der Grundlage der Priorität der aktiven/aktuellen Anwendungsströme zu sortieren. In Anbetracht des UL-Pufferstatus aller STAs (sowohl derjenigen mit priorisierten Anwendungsströmen als auch derjenigen ohne) können die STAs auf der Grundlage der Priorität der derzeit aktiven Anwendungsströme sortiert werden (d. h. es gibt Verkehr in der UL-Warteschlange, der übertragen werden muss). Diese priorisierte Liste von STAs erhält Kanalzugriff in einer Weise, die derjenigen entspricht, die der AP für DL-Übertragungen verwendet, wodurch UL- und DL-Übertragungen synchronisiert werden bzw. Symmetrie zwischen UL- und DL-Verkehrsströmen hergestellt wird, die zum selben Anwendungsstrom gehören. Die STAs mit Anwendungsflüssen höherer Priorität werden häufiger für UL-Übertragungen eingeplant als die anderen STAs. Solchen STAs werden auch mehr Kanalressourcen für ihre Übertragungen zur Verfügung gestellt. Diese Erhöhung der Kanalressourcen führt zu größeren Ressourceneinheiten (RUs) im Falle von planmäßigem UL OFDMA oder zu einer größeren Anzahl von räumlichen Streams im Falle von planmäßigem UL MU-MIMO.
Der Hardware-Prozessor 222 kann den Befehl 232 ausführen, um die AC der entsprechenden UL-Übertragungen zu bestimmen. Der Inhalt der Antwort auf einen BSRP liefert dem AP die Anzahl der Bytes, die in jeder AC einer STA in der Warteschlange stehen. Der AP kann dann einen Trigger-Frame verwenden, um die STA für die Übertragung von Frames in der UL-Richtung unter Verwendung von OFDMA, MU-MIMO oder einer Kombination davon einzuplanen. In einigen Ausführungsformen kann der Trigger-Frame ein Feld „Bevorzugter AC“ enthalten, das den niedrigsten AC angibt, von dem die STA Pakete zur Übertragung in UL-Richtung abrufen kann. Die Bestimmung des bevorzugten AC, der sich im Feld „Preferred AC“ widerspiegelt, wird im Folgenden beschrieben.
Anhand des 5-Tupels der Verkehrsströme für einen bestimmten Anwendungsstrom kann der AC bestimmt werden, der von der STA für den gegebenen Anwendungsstrom verwendet wird. Dieser AC wird als bevorzugter AC in Trigger-Frames programmiert, die vom AP an einen STA übertragen werden. Mit anderen Worten: Der „niedrigste“ AC, von dem der STA Pakete zur Übertragung freigeben kann, entspricht dem AC mit hoher Priorität, der mit dem Anwendungsfluss mit hoher Priorität verbunden ist. Die Bestimmung des AC auf diese Weise stellt sicher, dass der Verkehr mit niedriger Priorität, der sich auf anderen ACs (niedriger als der AC, der vom Anwendungsfluss mit hoher Priorität verwendet wird) in der Warteschlange befindet, nicht auf den Kanal zugreift, der vom AP für den STA geplant ist. Dies kann einen STA daran hindern, die Priorität (bevorzugte AC), die für den Verkehrsfluss (die Verkehrsflüsse) im Zusammenhang mit dem Anwendungsfluss mit hoher Priorität „reserviert“ wurde, für seinen anderen Verkehr zu nutzen. Sobald jedoch ein Anwendungsfluss als hochprior eingestuft wird, werden alle Verkehrsflüsse, die zu diesem Anwendungsfluss mit hoher Priorität gehören, als Verkehrsflüsse mit hoher Priorität behandelt.
Es sollte klar sein, dass Trigger-Frames verwendet werden können, um Informationen (von einem AP) über den Zeitpunkt weiterzugeben, zu dem eine STA mit der Übertragung ihrer in der Warteschlange befindlichen Daten/Pakete/Frames an den AP beginnen kann, zusammen mit Informationen über die Übertragungsrate, die Sendeleistung, die RU-Größe (siehe oben) und die räumlichen Ströme/Unterkanäle, die der empfangenden STA zugewiesen sind. Durch die Verwendung solcher Trigger-Frame-Informationen in Verbindung mit den Informationen des Feldes „Bevorzugter AC“ kann ein STA veranlasst/angeleitet werden, seine in der Warteschlange befindlichen Frames entsprechend der gewünschten Priorität zu übertragen (wird weiter unten ausführlicher erläutert).
Der Hardware-Prozessor 222 kann den Befehl 234 ausführen, um die RU-Größe für die UL-Übertragung zu optimieren. Wie oben beschrieben, kann der gesamte DL-Verkehr für jeden Anwendungsfluss mit hoher Priorität identifiziert werden, der UL-Pufferstatus der STAs, die mit dem identifizierten DL-Verkehr verbunden sind, kann ermittelt werden, und die STAs können sortiert werden, z. B. in eine Liste, die verschiedene Anwendungsflussprioritäten widerspiegelt. Die STA der sortierten/aufgelisteten STAs mit der höchsten Priorität ist diejenige, für die die RU-Größe maximiert wird. Die RU-Zuweisung an andere STAs kann gegenüber anderen STAs priorisiert werden, und zwar sowohl in Bezug darauf, wie oft ihnen die RUs zugewiesen werden (ausgewählt für OFDMA-Übertragungen), als auch in Bezug auf die Größe der RUs. In einigen Ausführungsformen wird die RU-Größe, die STAs mit der geringeren UL-Warteschlangentiefe zugewiesen wird, proportional zur Sendezeit sein, die durch die Anzahl der Bytes in der Warteschlange der STA bestimmt wird. Für STAs mit größerer UL-Warteschlangentiefe kann die gesamte Kanalbreite für das EVU zugewiesen werden. Es versteht sich, dass die UL-Warteschlangentiefe implementierungsabhängig sein kann. Daher kann in einigen Ausführungsformen ein anwendbarer Schwellenwert für die Warteschlangentiefe angegeben werden, mit dem die STA-Warteschlangentiefe verglichen werden kann, um festzustellen, ob die Warteschlangentiefe „kleiner“ als der Schwellenwert oder „größer“ als der Schwellenwert ist.
Der Hardware-Prozessor 222 kann den Befehl 236 ausführen, um den UL-Übertragungsmodus für jede STA zu bestimmen. In einigen Ausführungsformen kann UL MU-MIMO für die Datenübertragung innerhalb von RUs für STAs mit Anwendungsflüssen hoher Priorität verwendet werden, um Rahmen von diesen STAs an den AP zu übertragen. STAs mit geringerer UL-Warteschlangentiefe (gemessen in Bytes) können so konfiguriert werden, dass sie UL MU OFDMA verwenden. Für Clients mit einer begrenzten Anzahl von Antennen kann wiederum UL MU-MIMO mit Teilbandbreite innerhalb der RU verwendet werden, wobei diese effektiv zwischen den STAs mit hoher Priorität geteilt wird, während gleichzeitig sichergestellt wird, dass die Latenzzeit zwischen den STAs mit hoher Priorität minimiert wird. Für STAs mit größerer UL-Warteschlangentiefe, denen, wie oben erwähnt, eine ganze Kanalbreite für das EVU zugewiesen werden kann, kann UL MU-MIMO mit voller Bandbreite über STAs hinweg verwendet werden. Es ist zu beachten, dass auch in diesem Fall solche STAs in Bezug auf die Anzahl der Gruppierungen für MU-MIMO-Übertragungen und die Anzahl der ihnen zugewiesenen räumlichen Streams priorisiert werden.
Der Hardware-Prozessor 222 kann den Befehl 238 ausführen, um STAs mit Anwendungsflüssen höherer Priorität häufiger für die UL-Übertragung einzuplanen als STAs, die mit Anwendungsflüssen ohne hohe Priorität verbunden sind. Wenn der Verkehr für einen bidirektionalen Anwendungsfluss priorisiert wird, ermöglichen verschiedene Ausführungsformen, dass eine Entität oder ein Netzwerkgerät, wie z. B. ein AP, auch den UL-Verkehr von einer STA (oder mehreren STA) für denselben Anwendungsfluss priorisiert. Gemäß dem 802.11ax-Standard kann ein AP UL-Übertragungen an STAs mit Hilfe von Trigger-Frames planen, ohne dass die Stationen um den Kanal konkurrieren müssen. Somit muss die hier beschriebene Priorisierung des Datenverkehrs nicht auf Kosten eines Wettstreits erfolgen. Ziel-StAs für den DL-Verkehr von priorisierten bidirektionalen Anwendungsströmen können eine höhere Priorität erhalten, um auch für UL-Übertragungen eingeplant zu werden. Dadurch wird sichergestellt, dass die Anwendungsströme einen besseren Kanalzugang erhalten als dergesamte andere Verkehr für andere Clients in einem drahtlosen Netzwerk. Es ist zu beachten, dass aus der Sicht einer bestimmten STA, die einen priorisierten UL-Zeitplan erhält, auch andere Verkehrsflüsse vorhanden sein können, die nicht zu dem priorisierten Anwendungsfluss gehören. Nichtsdestotrotz können auch diese anderen Verkehrsströme eine bessere Leistung aufweisen (ein Nebeneffekt der Art und Weise, wie der 802.11ax-Standard die UL-Planung ermöglicht). Es ist anzumerken, dass verschiedene Ausführungsformen einen Ansatz verbessern, der sich auf Mechanismen zur Verkehrsspezifikation (TSpec) stützen kann, da TSpec von einem STA initiiert werden muss, und wie bereits oben erörtert, hat ein AP nicht notwendigerweise dieses Maß an Kontrolle über einen STA, der in UL-Richtung sendet, und darüber hinaus ist es sitzungsbasiert. Andererseits sind geplante UL-Übertragungen, die von einem AP initiiert werden, granularer, da sie auf einer PPDU-Basis (Physical Layer Protocol Data Unit) durchgeführt werden können. Außerdem würde die Verwendung von TSpec in Fällen, in denen der Client nicht den höchsten AC für die Verkehrsströme mit hoher Priorität verwendet, nicht helfen.
Es ist anzumerken, dass die oben beschriebene Methode zur Priorisierung des Verkehrs alle Fälle von bidirektionalem Verkehr berücksichtigen kann, bei denen der UL-Verkehr auf der Grundlage des DL-Verkehrs priorisiert wird. Betrachten wir also ein Szenario, in dem ein Anwendungsfluss mit hoher Priorität einen DL-Verkehr hat, der den entsprechenden UL-Verkehr übersteigt. In diesem Fall wird der Verkehr in der UL-Richtung mit ULOFDMA-Rahmen priorisiert. Wie bereits erwähnt, kann für STAs mit einer geringeren UL-Warteschlangentiefe (was der Fall wäre, wenn der Verkehr in DL-Richtung stark verzerrt ist) UL OFDMA als UL-Übertragungsmodus der Wahl gewählt werden. In einem Szenario, in dem der Verkehr in der UL- und DL-Richtung gleich oder ähnlich ist (basierend auf einem implementierungsabhängigen Schwellenwert), werden die Rahmen in der UL-(Rückwärts-)Richtung durch die Verwendung von UL OFDMA und/oder UL MIMO-Rahmen mit voller/teilweiser Bandbreite priorisiert. In einem Szenario, in dem der Verkehr in der DL-Richtung geringer ist als der in der UL-Richtung, kann der Verkehr in der UL-Richtung mit UL MIMO-Frames priorisiert werden. Anwendungsflüsse, die in diese Kategorie fallen, können Fälle umfassen, in denen eine Anwendung einen oder mehrere kleine Rahmen sendet, um Verkehr von der STA-Seite in UL-Richtung auszulösen.
2C zeigt ein weiteres Szenario, bei dem der UL-Verkehr priorisiert ist und der DL-Verkehr nicht. Das heißt, AP 200 kann Frames von STA 210-1 über den Kommunikationskanal 201 in der UL-Richtung empfangen, während er Frames an STA 210-1 in der DL-Richtung sendet. In einigen Szenarien kann die Priorität für den Verkehr von einer STA initiiert werden und wird so durch den AC angezeigt, den die STA für ihre UL-Übertragungen verwendet. In der DL-Richtung wird diese Priorität jedoch nicht unbedingt berücksichtigt. Das heißt, dass der DL-Verkehr in diesem Szenario z. B. TCP ACK-Nachrichten umfassen kann, die von der Anwendung/dem Stack nicht als mit einer bestimmten Übertragungspriorität übereinstimmend gekennzeichnet sind. Selbst wenn solche TCP ACKs in einem ToS-Feld mit dem richtigen Diensttyp (Type of Service, ToS) gekennzeichnet wurden, können Netzwerkgeräte im Übertragungspfad den mit den TCP ACK-Nachrichten verbundenen ToS ändern. Generell ist zu verstehen, dass in anderen bidirektionalen Übertragungsszenarien ein STA selbst einen AC mit höherer Priorität für UL-Verkehr verwenden kann, während der AP, an den der STA angeschlossen ist, keine Grundlage für die Priorisierung der DL-Komponente/des DL-Anteils des Verkehrsflusses hat.
2D ist ein Blockdiagramm der Beispiel-Rechenkomponente oder des Geräts 220, das auch DL-Verkehrsströme auf der Grundlage von UL-Verkehrsströmen eines bestimmten Anwendungsstroms gemäß einer Ausführungsform priorisieren kann. Wie oben beschrieben, umfasst die Computerkomponente 220 einen Hardwareprozessor 222 und ein maschinenlesbares Speichermedium 224. Wie unten im Detail beschrieben, kann das maschinenlesbare Speichermedium 224 mit ausführbaren Befehlen kodiert sein, zum Beispiel mit den Befehlen 240-246.
Der Hardware-Prozessor 222 kann die Anweisung 240 ausführen, um alle UL-Verkehrsströme für jeden Anwendungsstrom hoher Priorität, der einen AP durchläuft, zu identifizieren. Ähnlich wie bei Anweisung 226 (2A) kann zur Durchführung dieser Identifizierungsoperation eine Deep Packet Inspection durchgeführt werden.
Der Hardware-Prozessor 222 kann die Anweisung 242 ausführen, um den AC der entsprechenden UL-Übertragungen zu bestimmen, d. h. derjenigen UL-Übertragungen, die den UL-Teil des Anwendungsflusses mit hoher Priorität ausmachen, zu dem auch die identifizierten DL-Verkehrsflüsse gehören. Durch die Bindung der DL-Verkehrsströme für einen bestimmten Anwendungsstrom an die UL-Verkehrsströme auf der Grundlage des im UL-Verkehr verwendeten 5-Tupels wird sichergestellt, dass der AC für den DL-Verkehr mindestens gleich dem des UL-Verkehrs ist. In einigen Ausführungsformen kann eine bevorzugte Planung für den DL-Verkehr (wie unten beschrieben) durchgeführt werden, unabhängig davon, auf welchem AC der DL-Verkehr übertragen wird, um symmetrische/synchronisierte DL/UL-Verkehrsströme zu erreichen.
So kann der Hardware-Prozessor 222 die Anweisung 244 ausführen, um die DL-Verkehrsströme für jeden identifizierten Anwendungsstrom mit hoher Priorität zu priorisieren, indem er sicherstellt, dass der AC, nach dem der DL-Verkehr gesendet wird, mindestens der gleiche ist wie der, der für die UL-Verkehrsströme desselben Anwendungsstroms verwendet wird. In einigen Szenarien wird derselbe AC für die DL- und UL-Verkehrsströme desselben Anwendungsstroms verwendet. In einigen Szenarien kann für die DL-Verkehrsströme ein AC mit höherer Priorität verwendet werden als der AC für die UL-Verkehrsströme. Beispielsweise können andere Verkehrsströme auf der DL geplant werden (die mit anderen STAs verbunden sind), die den DL-Verkehr behindern können, selbst wenn der DL-AC und UL-AC gleichwertig sind.
In Übereinstimmung mit einigen Ausführungsformen kann die Priorisierung des DL-Verkehrsflusses auf der Grundlage des UL-Verkehrsflusses für einen bestimmten Anwendungsfluss in Verbindung mit einem AP-Upgrade durchgeführt werden. Dementsprechend kann der Hardware-Prozessor 222 die Anweisung 246 ausführen, um eine bevorzugte DL-Planung vorzunehmen. Es versteht sich, dass die oben beschriebene Priorisierung des DL-Verkehrsflusses unabhängig oder zusätzlich bzw. in Verbindung mit jeder anderen Form der Priorisierung des DL-Verkehrs durchgeführt oder verwendet werden kann, wobei eine gewisse „Netto“-Priorisierung mit Hilfe mehrerer Mechanismen erreicht werden kann (d. h. mit dem hier beschriebenen und einem oder mehreren anderen Priorisierungsmechanismen).
3 zeigt ein Blockdiagramm eines beispielhaften Computersystems 300, in dem verschiedene der hier beschriebenen Ausführungsformen implementiert werden können. Das Computersystem 300 umfasst einen Bus 302 oder einen anderen Kommunikationsmechanismus zur Übermittlung von Informationen, einen oder mehrere Hardware-Prozessoren 304, die mit dem Bus 302 verbunden sind, um Informationen zu verarbeiten. Bei dem/den Hardware-Prozessor(en) 304 kann es sich zum Beispiel um einen oder mehrere Allzweck-Mikroprozessoren handeln.
Das Computersystem 300 umfasst auch einen Hauptspeicher 306, z. B. einen Speicher mit wahlfreiem Zugriff (RAM), einen Cache und/oder andere dynamische Speichergeräte, die mit dem Bus 302 verbunden sind, um Informationen und Anweisungen zu speichern, die vom Prozessor 304 ausgeführt werden sollen. Der Hauptspeicher 306 kann auch zum Speichern temporärer Variablen oder anderer Zwischeninformationen während der Ausführung von Befehlen verwendet werden, die vom Prozessor 304 ausgeführt werden sollen. Wenn solche Anweisungen in Speichermedien gespeichert werden, auf die der Prozessor 304 zugreifen kann, wird das Computersystem 300 zu einer Spezialmaschine, die so angepasst ist, dass sie die in den Anweisungen angegebenen Operationen ausführen kann.
Das Computersystem 300 umfasst außerdem einen Festwertspeicher (ROM) 308 oder ein anderes statisches Speichergerät, das mit dem Bus 302 verbunden ist, um statische Informationen und Anweisungen für den Prozessor 304 zu speichern. Ein Speichergerät 310, z. B. eine Magnetplatte, eine optische Platte oder ein USB-Stick (Flash-Laufwerk) usw., ist vorgesehen und mit dem Bus 302 verbunden, um Informationen und Anweisungen zu speichern.
Das Computersystem 300 kann ferner mindestens eine Netzwerkschnittstelle 312, wie z. B. einen Netzwerkschnittstellen-Controller (NIC), einen Netzwerkadapter oder Ähnliches oder eine Kombination davon, enthalten, die mit dem Bus 302 verbunden ist, um das Computersystem 300 mit mindestens einem Netzwerk zu verbinden.
Im Allgemeinen kann sich das Wort „Komponente“, „System“, „Datenbank“ und dergleichen, wie es hier verwendet wird, auf eine in Hardware oder Firmware verkörperte Logik oder auf eine Sammlung von Softwareanweisungen beziehen, die möglicherweise Einstiegs- und Ausstiegspunkte haben und in einer Programmiersprache wie z. B. Java, C oder C++ geschrieben sind. Eine Softwarekomponente kann kompiliert und zu einem ausführbaren Programm verknüpft werden, in einer dynamischen Link-Bibliothek installiert werden oder in einer interpretierten Programmiersprache wie BASIC, Perl oder Python geschrieben sein. Es ist klar, dass Softwarekomponenten von anderen Komponenten oder von sich selbst aus aufgerufen werden können und/oder als Reaktion auf erkannte Ereignisse oder Unterbrechungen aufgerufen werden können. Softwarekomponenten, die für die Ausführung auf Computergeräten konfiguriert sind, können auf einem computerlesbaren Medium, wie z. B. einer Compact Disc, einer digitalen Videodisc, einem Flash-Laufwerk, einer Magnetplatte oder einem anderen greifbaren Medium, oder als digitaler Download bereitgestellt werden (und können ursprünglich in einem komprimierten oder installierbaren Format gespeichert sein, das vor der Ausführung eine Installation, Dekomprimierung oder Entschlüsselung erfordert). Ein solcher Softwarecode kann teilweise oder vollständig in einem Speicher des ausführenden Computergeräts zur Ausführung durch das Computergerät gespeichert werden. Softwareanweisungen können in Firmware, wie z. B. einem EPROM, eingebettet sein. Darüber hinaus können die Hardwarekomponenten aus verbundenen Logikeinheiten wie Gattern und Flipflops und/oder aus programmierbaren Einheiten wie programmierbaren Gatteranordnungen oder Prozessoren bestehen.
Das Computersystem 300 kann die hier beschriebenen Techniken unter Verwendung von kundenspezifischer festverdrahteter Logik, einem oder mehreren ASICs oder FPGAs, Firmware und/oder Programmlogik implementieren, die in Kombination mit dem Computersystem das Computersystem 300 zu einer Spezialmaschine macht oder programmiert. Gemäß einer Ausführungsform werden die hierin beschriebenen Techniken vom Computersystem 300 als Reaktion auf den/die Prozessor(en) 304 ausgeführt, der/die eine oder mehrere Sequenzen von einem oder mehreren im Hauptspeicher 306 enthaltenen Befehlen ausführt/ausführen. Solche Anweisungen können in den Hauptspeicher 306 von einem anderen Speichermedium, wie z. B. einem Speichergerät 310, eingelesen werden. Die Ausführung der im Hauptspeicher 306 enthaltenen Befehlssequenzen veranlasst den/die Prozessor(en) 304, die hier beschriebenen Verfahrensschritte durchzuführen. In alternativen Ausführungsformen können fest verdrahtete Schaltungen anstelle von oder in Kombination mit Softwareanweisungen verwendet werden.
Der Begriff „nichtflüchtige Medien“ und ähnliche Begriffe, wie sie hier verwendet werden, beziehen sich auf alle Medien, die Daten und/oder Befehle speichern, die eine Maschine in einer bestimmten Weise arbeiten lassen. Solche nichtflüchtigen Medien können nichtflüchtige Medien und/oder flüchtige Medien umfassen. Zu den nichtflüchtigen Medien gehören beispielsweise optische oder magnetische Festplatten, wie die Speichervorrichtung 310. Zu den flüchtigen Medien gehören dynamische Speicher, wie der Hauptspeicher 306. Zu den gängigen Formen nichtflüchtiger Medien gehören beispielsweise Disketten, flexible Platten, Festplatten, Solid-State-Laufwerke, Magnetbänder oder andere magnetische Datenspeichermedien, CD-ROMs, andere optische Datenspeichermedien, physische Medien mit Lochmustern, RAM, PROM, EPROM, FLASH-EPROM, NVRAM, andere Speicherchips oder -kassetten sowie deren vernetzte Versionen.
Nicht-transitorische Medien unterscheiden sich von Übertragungsmedien, können aber in Verbindung mit ihnen verwendet werden. Übertragungsmedien sind an der Übertragung von Informationen zwischen nicht-transitorischen Medien beteiligt. Zu den Übertragungsmedien gehören z. B. Koaxialkabel, Kupfer- und Glasfaserkabel, einschließlich der Drähte, aus denen der Bus 302 besteht. Übertragungsmedien können auch in Form von Schall- oder Lichtwellen auftreten, wie sie bei der Datenkommunikation über Funk und Infrarot erzeugt werden.
Wie hierin verwendet, kann der Begriff „oder“ sowohl im einschließenden als auch im ausschließenden Sinne verstanden werden. Darüber hinaus ist die Beschreibung von Ressourcen, Vorgängen oder Strukturen im Singular nicht so zu verstehen, dass der Plural ausgeschlossen wird. Bedingte Ausdrücke, wie z. B. „kann“, „könnte“, „könnte“ oder „darf“, sollen im Allgemeinen vermitteln, dass bestimmte Ausführungsformen bestimmte Merkmale, Elemente und/oder Schritte einschließen, während andere Ausführungsformen diese nicht einschließen, es sei denn, es ist ausdrücklich etwas anderes angegeben oder im Zusammenhang mit der Verwendung anders zu verstehen.
Die in diesem Dokument verwendeten Begriffe und Ausdrücke sowie deren Abwandlungen sind, sofern nicht ausdrücklich anders angegeben, nicht einschränkend, sondern offen zu verstehen. Als Beispiele für das Vorstehende ist der Begriff „einschließlich“ im Sinne von „einschließlich, ohne Einschränkung“ oder dergleichen zu verstehen. Der Begriff „Beispiel“ wird verwendet, um exemplarische Beispiele für den Gegenstand der Diskussion zu geben, nicht um eine erschöpfende oder einschränkende Liste zu erstellen. Die Begriffe „ein“ oder „ein“ sind im Sinne von „mindestens ein“, „ein oder mehrere“ oder ähnlich zu verstehen. Das Vorhandensein von erweiternden Wörtern und Ausdrücken wie „einer oder mehrere“, „mindestens“, „aber nicht beschränkt auf“ oder ähnlichen Ausdrücken in einigen Fällen ist nicht so zu verstehen, dass der engere Fall beabsichtigt oder erforderlich ist, wenn solche erweiternden Ausdrücke nicht vorhanden sind.

Claims

Ein Verfahren zum Planen von Aufwärtsverbindungs-(UL)-Verkehr zu einer drahtlosen lokalen Netzwerk-(WLAN)-Vorrichtung, umfassend: Identifizierung von Verkehrsflüssen auf der Abwärtsstrecke (DL), die mit jedem Anwendungsfluss hoher Priorität des WLAN-Geräts verbunden sind; Bestimmung eines Status eines UL-Puffers jeder Station (STA), die mit jedem der Anwendungsströme hoher Priorität verbunden ist; Sortieren jeder STA auf der Grundlage der Prioritäten jedes der Anwendungsströme mit hoher Priorität; und Bereitstellung des Kanalzugangs in der UL für jede sortierte STA in einer Weise, die mindestens gleichwertig mit dem Kanalzugang ist, der für die identifizierten DL-Verkehrsströme bereitgestellt wird.
Verfahren nach Anspruch 1, wobei das WLAN-Gerät ein Gerät umfasst, das in der Lage ist, UL-Verkehr zu planen.
Verfahren nach Anspruch 1, wobei das WLAN-Gerät einen Zugangspunkt umfasst.
Verfahren nach Anspruch 1, wobei auf dem WLAN-Gerät eine Deep Packet Inspection durchgeführt wird, um die DL-Verkehrsströme zu identifizieren.
Verfahren nach Anspruch 1, wobei die Bestimmung des UL-Pufferstatus der STAs die Durchführung einer Pufferabfrage bei jeder der STAs in Echtzeit in bestimmten Intervallen umfasst, um die UL-Warteschlangentiefe zu schätzen.
Verfahren nach Anspruch 5, wobei die Durchführung der Pufferabfrage das Anhängen eines Pufferstatusabfrage-(BSRP)-Triggerrahmens an eine WLAN Physical Layer Protocol Data Unit (PPDU) umfasst, die auf einem Kanal in der DL-Richtung gesendet wird.
Verfahren nach Anspruch 6, wobei die Durchführung der Pufferabfrage mit einer bestimmten Periodizität erfolgt, die von jedem der Anwendungsströme hoher Priorität abhängt, die mit jeder der STAs verbunden sind.
Das Verfahren nach Anspruch 1 umfasst ferner die Bestimmung einer Zugriffskategorie (AC) von UL-Übertragungen, die jedem UL-Puffer entsprechen.
Verfahren nach Anspruch 8, ferner umfassend das Spezifizieren eines bevorzugten AC-Feldes in einem Trigger-Frame, der an jede sortierte STA übertragen wird, das einen AC oder einen Satz von ACs angibt, aus dem jede sortierte STA Pakete für die UL-Übertragung aus der Warteschlange nehmen kann.
Verfahren nach Anspruch 9, wobei der AC oder der Satz von ACs einem AC oder einem Satz von ACs entspricht, der mit jedem der Anwendungsflüsse hoher Priorität verbunden ist.
Verfahren nach Anspruch 9, das ferner die Optimierung der Größe der jeder UL-Übertragung zugewiesenen Ressourceneinheit (RU) umfasst.
Verfahren nach Anspruch 11, bei dem die RU-Größe, die einem sortierten STA mit der höchsten Priorität zugeordnet ist, maximiert wird.
Das Verfahren nach Anspruch 9 umfasst ferner die Bestimmung eines UL-Übertragungsmodus, nach dem jede UL-Übertragung übertragen wird.
Verfahren nach Anspruch 13, wobei der UL-Übertragungsmodus einen von UL Multi-User, Multiple Input, Multiple Output (MU-MIMO) oder UL Orthogonal Frequency Division Multiple Access (OFDMA) umfasst, abhängig von einer Größe einer UL-Warteschlangentiefe, die dem UL-Puffer jeder sortierten STA entspricht.
Verfahren nach Anspruch 1, wobei der Kanalzugang in der UL häufiger für diejenigen der sortierten STAs bereitgestellt wird, die Anwendungsflüsse mit höherer Priorität haben.
Verfahren zum Planen von Verkehr, umfassend: Identifizierung von Verkehrsflüssen in einer ersten Richtung, die mit einem oder mehreren priorisierten Anwendungsflüssen verbunden sind, an einem WLAN-Gerät (Wireless Local Area Network); Bestimmen einer Zugangskategorie, die mit den identifizierten Verkehrsströmen in der ersten Richtung verbunden ist, durch die WLAN-Vorrichtung; und Priorisieren von Verkehrsflüssen des einen oder der mehreren priorisierten Anwendungsflüsse in einer zweiten Richtung, die sich von der ersten Richtung unterscheidet, durch das WLAN-Gerät, indem die Zugangskategorie (AC), die den identifizierten Verkehrsflüssen in der zweiten Richtung zugeordnet ist, so angepasst wird, dass sie mindestens gleich einer AC ist, die den identifizierten Verkehrsflüssen in der ersten Richtung zugeordnet ist.
Verfahren nach Anspruch 16, wobei die erste Richtung eine Uplink-(UL)-Richtung von einem WLAN-Gerät (Wireless Local Area Network) zu Stationen (STAs) umfasst, die dem WLAN-Gerät zugeordnet sind, und wobei die zweite Richtung eine Downlink-(DL)-Richtung umfasst.
Verfahren nach Anspruch 16, das ferner die Durchführung einer bevorzugten DL-Planung für die Übertragung der Verkehrsströme in der zweiten Richtung umfasst.
Verfahren nach Anspruch 16, wobei das Anpassen des AC das Zuweisen eines AC, der mit den identifizierten Verkehrsströmen in der zweiten Richtung verbunden ist, als größer als der AC, der mit den identifizierten Verkehrsströmen in der ersten Richtung verbunden ist, umfasst.
Verfahren nach Anspruch 16, wobei das WLAN-Gerät einen Zugangspunkt (AP) umfasst.