DE102021127235B4

DE102021127235B4 - Systeme und verfahren zur uplink (ul)-scheduler optimierung mit einem selbstanpassenden pufferstatusabrufschema (bsrp)

Info

Publication number: DE102021127235B4
Application number: DE102021127235.1A
Authority: DE
Inventors: Qiang Zhou; Nitin A. Changlani; Sachin Ganu; Hao Lu
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2020-12-18
Filing date: 2021-10-20
Publication date: 2024-07-25
Anticipated expiration: 2041-10-21
Also published as: US20220201718A1; CN114650607B; CN114650607A; US11546931B2; DE102021127235A1

Abstract

Ein Verfahren zum Planen von Uplink-(UL)-Verkehr zu einer drahtlosen lokalen Netzwerk-(WLAN)-Vorrichtung (106a-c; 200; 300; 400), umfassend:Bestimmen eines Status eines UL-Puffers jeder Station (STA) (110a-j; 210-1; 210-2), wobei der Status des UL-Puffers jeder STA (110a-j; 210-1; 210-2) eine Menge anstehender Daten im UL-Puffer jeder STA (110a-j; 210-1; 210-2) umfasst; undErzeugen und Übertragen einer Pufferzustandsabfrage (BSRP) durch einen UL-Scheduler der WLAN-Vorrichtung (106a-c; 200; 300; 400) gemäß einer BSRP-Häufigkeit, wobei die BSRP-Häufigkeit auf dem UL-Pufferstatus jeder STA (110a-j; 210-1; 210-2) basiert.

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 APs, wie Geschwindigkeit und Zuverlässigkeit.
US 2017 / 0 273 140 A1 beschreibt ein Verfahren und eine Vorrichtung zum Auslösen von Uplink-Daten in einem drahtlosen LAN. Ein Verfahren zum Empfangen von Uplink-Daten in einem drahtlosen LAN kann Folgendes umfassen: einen Schritt, in dem ein Zugangspunkt (AP) einen Triggerrahmen für eine zufällige Verbindung sendet; und einen Schritt, in dem der AP mindestens einen Pufferstatusberichtsrahmen von mindestens einer STA bei einer zufälligen Verbindungsübertragungsmöglichkeit (TXOP) empfängt, die auf der Grundlage des Triggerrahmens für eine zufällige Verbindung festgelegt wird, wobei der zufällige Verbindungs-TXOP zugewiesen wird für einen Kanalzugriffsversuch zum Übertragen des Pufferstatusberichtsrahmens jeder einer Vielzahl unspezifischer STAs, und jede der mindestens einen STA kann eine STA sein, der der Kanalzugriff unter der Vielzahl unspezifischer STAs gelingt.
US 2016 / 0 374 093 A1 beschreibt ein Verfahren zum Zuweisen von Mehrbenutzer-Kommunikationsressourcen zu einer oder mehreren Stationen für Uplink-Datenübertragungen. Das Verfahren umfasst das Erzeugen eines Anforderungsrahmens, der einen Uplink-Pufferbericht von jeder der einen oder mehreren Stationen anfordert, wobei der Anforderungsrahmen selektiv anfordert, dass der Uplink-Pufferbericht entweder eine Datenmenge in einem Uplink-Puffer oder eine angeforderte Zeitdauer für die Übertragung der Daten im Uplink-Puffer angibt. Das Verfahren umfasst das Übertragen des Anforderungsrahmens an jede der einen oder mehreren Stationen. Das Verfahren umfasst den Empfang des Uplink-Pufferberichts in einem Berichtsrahmen von jeder der einen oder mehreren Stationen.
Kurzbeschreibung
Es wird ein Verfahren gemäß Ansprüchen 1 bis 15 und eine drahtlose lokale Netzwerk-(WLAN)-Vorrichtung gemäß Ansprüchen 16 bis 20 offenbart.
Kurzbeschreibung der Zeichnungen
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 der Uplink (UL)-Scheduler mit einem selbstanpassenden Pufferstatusabrufschema (BSRP) in Übereinstimmung mit verschiedenen Ausführungsformen optimiert ist.
2A zeigt ein Beispiel für einen Zugangspunkt (AP) gemäß verschiedenen Ausführungsformen, bei dem der UL-Scheduler mit einem selbstanpassenden BSRP-Schema gemäß verschiedenen Ausführungsformen optimiert ist.
2B zeigt einen beispielhaften Nachrichtenfluss, der unaufgeforderte Pufferstatusberichte (BSR) und durch BSRP-Frames angeforderte BSR in Übereinstimmung mit verschiedenen Ausführungsformen umfasst.
2C zeigt Beispiele für Schwellenwerte für anstehende Frames für das BSRP-Schema mit Selbstanpassung in Übereinstimmung mit verschiedenen Ausführungsformen.
3A zeigt eine Beispielrechnerkomponente zur Optimierung des UL-Schedulers mit selbstanpassendem BSRP-Schema in Übereinstimmung mit verschiedenen Ausführungsformen.
3B zeigt eine Beispielrechnerkomponente, in der der UL-Scheduler mit einem selbstanpassenden BSRP-Schema in Übereinstimmung mit verschiedenen Ausführungsformen optimiert ist.
4 zeigt ein Beispiel einer 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 offengelegt wird.
Detaillierte Beschreibung
Vor dem 802.11ax-Standard war der AP nicht in der Lage, eine Dienstgütevereinbarung (Service Level Agreement, SLA) für bidirektionalen Datenverkehr zu garantieren, da er keine Möglichkeit hatte, die UL-Übertragung von bestimmten STAs zu planen. Um dem AP mehr Kontrolle über den UL-Verkehr zu geben, wurden mit 802.11ax hocheffiziente (HE) Schemata wie Multi-User (MU)-Uplink (UL)-Schemata eingeführt, bei denen auf den Kanal gleichzeitig zugegriffen wird (d. h. zur oder um die gleiche Zeit, z. B. durch Multi-User Multiple Input Multiple Output (MU-MIMO) mit voller oder teilweiser Bandbreite, MU-Orthogonal Frequency Division Multiple Access (OFDMA) oder eine hybride Kombination davon).
Um den AP bei der Planung der UL-Übertragung und der Zuweisung von UL-Multi-User (MU)-Ressourcen zu unterstützen, können APs Informationen über den STA-Pufferstatus anfordern, indem sie Trigger-Frames generieren und übertragen, z. B. BSRP-Trigger-Frames (allgemein BSRP-Trigger oder BSRP hier). Ein BSRP-Trigger-Frame kann sich auf eine Art von Trigger-Frame beziehen, der eine oder mehrere Übertragungen von HE-Trigger-basierten (TB) Physical Layer (PHY) Protocol Data Units (PPDU) anfordert.
Jede STA liefert explizit Pufferstatusberichte (BSRs) als Antwort auf einen BSRP-Trigger-Frame. Die BSR können Planungsinformationen enthalten, z. B. Informationen darüber, wie viele Daten sich im Puffer der STA befinden (d. h. Daten, die gesendet werden sollen). Somit können die BSR Informationen über den Pufferstatus enthalten. Der BSR kann in jedem an den AP gesendeten Frame enthalten sein. Das heißt, ein BSR kann im QoS-Kontrollfeld und/oder in der BSR-Variante des HT-Kontrollfelds des 802.11-MAC-Headers für ein oder mehrere Pakete, die von den STAs übertragen werden, enthalten sein. Der BSR kann auch in einem QoS-Null-Frame enthalten sein, einem 802.11-QoS-Datenframe, der keine Daten enthält. In der Welt vor 802.11ax wurde der QoS-Null-Frame häufig verwendet, um den aktuellen Energiesparstatus eines Nicht-AP-StAs zu übertragen. In der802.11ax-Spezifikation wurden die QoS-Null- und QoS-Daten-Frames jedoch so erweitert, dass sie Uplink-(UL)-Planungsinformationen im QoS-Kontrollfeld und die HE-Variante des HT-Kontrollfelds (High Throughput) des MAC-Headers (Media Access Control) enthalten.
Das QoS-Kontrollfeld gibt insbesondere die Daten an, die für eine bestimmte Verkehrskennung (TID) an einer übertragenden STA gepuffert werden. Das heißt, ein QoS-Kontrollfeld kann aus fünf Unterfeldern bestehen, darunter TID-Informationen, Informationen über das Ende der Dienstperiode (EOSP), Informationen über die Bestätigungspolitik (ACK), Informationen über die Übertragungsgelegenheit (TXOP) oder die Größe der UL-Warteschlange und die vorhandene A-MSDU. Die HE-Variante des HT-Kontrollfelds, die optional im QoS Data/QoS Null-Frame vorhanden sein kann, enthält die Fähigkeit eines STA, UL-Multi-User (MU)-Übertragungen durchzuführen, oder Pufferstatusinformationen, die für den UL-MU-Betrieb verwendet werden, usw.
Das 802.11ax-Protokoll definiert nicht die Kriterien, nach denen der AP den BSRP-Trigger-Frame senden muss. In einigen Implementierungen kann es ein festes Intervall (oder eine feste Frequenz) für das Senden von BSRP-Triggern an alle STAs geben, um angeforderte BSR auszulösen. Das feste Intervall oder die Häufigkeit kann unabhängig von den STA-Typen, dem Pufferstatus und den Aktivitäten der STAs gleich sein. Die Bereitstellung von BSRP-Trigger-Frames in demselben Intervall für alle STAs kann jedoch einige Probleme mit sich bringen. Zunächst können die von den STAs empfangenen BSR den Pufferstatus der STAs mit aktivem und hochprioritärem UL-Verkehr nicht rechtzeitig widerspiegeln. Dies kann zu einem Fehlverhalten des UL-Schedulers führen. Zweitens kann dies die Effizienz sowohl der Luftressourcen (z. B. durch erhöhten Overhead) als auch den Stromverbrauch der STA verringern, da häufige BSRP an Clients mit niedriger Priorität und inaktivem UL-Verkehr ausgelöst werden.
Dementsprechend sind verschiedene Ausführungsformen darauf ausgerichtet, ein Intervall oder eine Häufigkeit, mit der BSRP-Trigger gesendet werden können, dynamisch anzupassen und somit die Anforderung von UL-Planungsinformationen (z. B. gepufferte Daten, STA-Fähigkeitsinformationen), die mittels BSR-Frames (z. B. als Teil von QoS-Null/QoS-Daten-Frames und MAC-Headern), die von einer STA übertragen werden, erhalten werden, dynamisch anzupassen. Der BSRP-Trigger-Frame kann sich von anderen, vom AP gesendeten Trigger-Frames unterscheiden und getrennt sein. In manchen Fällen kann der BSRP mit anderen vom AP gesendeten Trigger-Frames kombiniert oder aggregiert werden. Andere Trigger-Frames können verwendet werden, um STAs für die Datenübertragung einzuplanen. In Ausführungsformen können Trigger-Frames, die die Übertragung von Daten durch ein oder mehrere STAs planen, auf dem STA-Pufferstatus und/oder der Priorität für den Verkehr basieren, wobei alle Informationen als Teil des BSR enthalten sein können. Es kann mehrere Formate von Trigger-Frames und von BSRP-Trigger-Frames („Trigger-Typ“) geben. Dies kann dem AP eine bessere Einschätzung des jeweiligen Pufferstatus der jeweiligen STAs ermöglichen (z. B. für eine effiziente Planung des UL-Verkehrs mit hoher Priorität), während der Overhead (z. B. in der DL und/oder der UL durch die BSRP-Trigger-Frames und/oder die BSR) reduziert wird. Dieser Overhead kann sich auf UL-Verkehr mit hoher Priorität konzentrieren, bei dem der Empfang von BSRs für die effiziente Planung des UL-Verkehrs durch den AP nützlich wäre. Diese UL-Planungsinformationen können zur Verbesserung der Netzleistung verwendet werden. Das heißt, AP im gleichen erweiterten Dienstsatz (ESS) können die Informationen empfangen und analysieren. Zum Beispiel kann ein AP solche UL-Planungsinformationen (von STAs, die mit Co-Channel-APs im selben ESS verbunden sind) verwenden, um die Latenz für UL-Latenz-empfindlichen Verkehr in diesem ESS zu minimieren. Es sollte klar sein, dass Verkehr wie Sprache und Video (unten im Zusammenhang mit Zugangskategorien (ACs) beschrieben) als latenzempfindlich angesehen werden kann, während Best-Effort- und Hintergrundverkehr/verkehrstypische ACs nicht als latenzempfindlich angesehen werden. Somit kann die oben erwähnte Minimierung der Latenz auf latenzempfindlichen UL-Verkehr wie Sprach- oder Videoverkehr angewendet werden. Darüber hinaus kann ein AP solche UL-Planungsinformationen verwenden, um Konflikte zwischen STAs, die mit verschiedenen APs auf demselben Kanal im selben ESS verbunden sind, zu minimieren und so die Systemkapazität zu verbessern.
Es versteht sich, dass der AP gültige Frames von Interesse erfassen und analysieren kann, um nützliche Planungsinformationen zu erhalten. Es sollte klar sein, dass Frames von der STA von einem AP als gültig angesehen werden können, wenn sie von einer STA übertragen werden und eine zyklische Redundanzprüfung (CRC) bestehen. Da die interessierenden Informationen, nämlich die QOS-Kontrollfelder und die HE-Variante der HT-Kontrollfelder, Teil des MAC-Headers und somit unverschlüsselt sind, kann die CRC-Prüfung als ausreichend angesehen werden, um den in diesem Frame enthaltenen Informationen zu vertrauen.
Die vorgenannten BSR können in den folgenden Frames enthalten sein: UL-QoS-Null-Frames für Einzelbenutzer (SU), QoS-Null-Frames, die als Teil von UL-Übertragungen mit orthogonalem Frequenzmultiplex (OFDMA) empfangen werden, Basic-Trigger-Frames und nachfolgende QoS-Daten- oder QoS-Null-Frames, die als Teil von UL-OFDMA-Übertragungen empfangen werden, und UL-SU-QoS-Daten-Frames. Diese OBSS-Frames können von STAs, die einem AP zugeordnet sind, oder von STAs, die einem oder mehreren anderen APs zugeordnet sind, die zum selben ESS gehören, übertragen werden (d. h. sie können Teil von Co-Channel-OBSS im ESS sein).
Es sei darauf hingewiesen, dass nach dem 802.11-Standard ein Service-Set oder ESS sich auf eine Gruppe von drahtlosen Netzwerkgeräten beziehen kann, die durch denselben Service-Set-Identifikator (SSID) oder „Netzwerknamen“ gekennzeichnet sind. Ein ESS oder Service-Set bildet ein logisches Netzwerk, das mit denselben Netzwerkparametern der Ebene 2 arbeitet, d. h. sie befinden sich im selben logischen Netzwerksegment, z. B. einem Internetprotokoll (IP)-Subnetz oder einem virtuellen LAN (VLAN). Andererseits kann sich ein Basis-Service-Set (BSS) auf eine Untergruppe von Geräten mit einem Service-Set beziehen, die (zusätzlich zum Betrieb mit denselben Netzwerkparametern der Ebene 2 zur Bildung eines logischen Netzwerks) mit denselben Medienzugangsmerkmalen der physikalischen Schicht arbeiten, z. B. RF, Modulationsschema, Sicherheitseinstellungen usw., so dass sie drahtlos vernetzt sind. So können in einem WLAN-Netz eines Unternehmens mehrere BSS so gesteuert werden, dass Netzwerkgeräte in verschiedenen BSS-Netzen zusammengefasst werden können.
Es sollte auch beachtet werden, dass die 802.11ax-Spezifikation AP-initiierte, trigger-basierte UL-MU-Übertragungen einführt. Um UL-Übertragungen zu planen, benötigt ein AP möglicherweise Informationen über die bei einem Client oder STA zwischengespeicherten Daten, die auf die Übertragung warten. So kann ein AP beispielsweise BSRP-Trigger-Frames senden, um diese Informationen zu beschaffen, indem er Ressourceneinheiten (RUs) für die UL-Antwort (d. h. die BSR) zuweist. Die vom AP angefragten STAs antworten auf die BSRP-Trigger-Frames mit QoS-Null-Frames (oder anderen Frames), die die BSR in den vorgeschlagenen RUs enthalten. Die STAs können auch unaufgeforderte BSRs in QOS-Null- oder QOS-Daten-Frames senden. Diese QoS-Null-Frames können Teil von SU- oder MU-Übertragungen sein. Während diese Frames von einem STA zur Analyse bei dem AP empfangen werden, dem der STA zugeordnet ist, können die QoS-Null-Frames, wie oben erwähnt, auch von einigen benachbarten Co-Channel-APs „mitgehört“ werden.
Bevor Ausführungsformen der offengelegten Systeme und Methoden im Detail beschrieben werden, ist es sinnvoll, eine beispielhafte Netzwerkinstallation zu beschreiben, mit der diese Systeme und Methoden in verschiedenen Anwendungen implementiert werden können. 1 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 über einen Router (nicht abgebildet) mit dem Netzwerk 120. 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 Netzwerkverbindungen zu verschiedenen Client-Geräten/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 Netzwerk (Primärstandort 102) 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 sollte beachtet werden, 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 einzelnes 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 Beacons 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). MU-EDCA-Parameter können einen oder mehrere der hier genannten EDCA-Parameter enthalten, die auf MU-Kanalzugangsverfahren zugeschnitten sein können.
Zu den EDCA-Parametern gehören unter anderem die folgenden:

a. Zugangskategorie (AC) - Ein AC-Parameter bezieht sich auf eine Sprach-AC (VO), eine Video-AC (VI), eine Best-Effort-AC (BE) oder eine Hintergrund-AC (BK). Wie in der 802.11-Norm beschrieben, kann es mehrere ACs geben, und jede AC kann mit einer anderen Prioritätsstufe verbunden sein.
b. Arbitration Inter-Frame Spacing (AIFS) - Ein Zeitintervall zwischen Frames, die nach dem IEEE 802.11-Standard übertragen werden.
c. Minimum Contention Window (CWmin) - Eingabe in einen Algorithmus, der die anfängliche zufällige Backoff-Wartezeit für den erneuten Versuch einer Übertragung als Reaktion auf einen fehlgeschlagenen Versuch (z. B. aufgrund der Nichtverfügbarkeit eines HF-Kanals) bestimmt. Die zufällige Backoff-Wartezeit kann erhöht werden, wenn die Übertragung eines Frames fehlschlägt, weil der Kanal für die Übertragung nicht verfügbar ist.
d. Maximum Contention Window (CWmax) - Die maximale Wartezeit für zufällige Backoffs.
f. Transmission Opportunity (TXOP) Limit - Ein Zeitintervall, in dem ein STA das Recht hat, Übertragungen zu einem AP zu initiieren und umgekehrt, und so viele Frames wie möglich zu senden. Diese Frames können SIFS-getrennt sein und dieser Austausch wird als „Burst“ bezeichnet.

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 Frames, 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 (die oben erwähnt und weiter unten genauer beschrieben werden), die verschiedenen Arten von Anwendungen zugewiesen werden können, wobei jede ihre eigenen besonderen QoS-Anforderungen/Parameter hat. Sobald ein AC einem Anwendungstyp zugewiesen ist, kann außerdem die Art und Weise konfiguriert werden, in der Verkehr/Daten in eine Warteschlange gestellt werden, sowie die Art und Weise, in der Verkehr/Daten aus der Warteschlange genommen werden. Es versteht sich, dass eine bestimmte AC mit einer oder mehreren Warteschlangen/Unterwarteschlangen verbunden sein kann. Vier Beispiele für ACs sind Background (BK), Best Effort (BE), Video (VI) und Voice (VO), wobei VI und VO typischerweise mit niedriger Latenz oder höherer Priorität als BK und BE verbunden sind.
2A zeigt 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) sowie eine Überwachungs- und Planungslogik 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. Der Speicher 204 kann einen oder mehrere der verschiedenen hier beschriebenen Parameter (und deren Werte) speichern. 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. Bei dem Prozessor 202 kann es sich um eine beliebige Verarbeitungsvorrichtung handeln, 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 Logikfeld.
Das Funkgerät 206 kann ein 5-GHz-Funkgerät, ein 2,4-GHz-Funkgerät, ein 6-GHz-Funkgerät oder eine andere geeignete drahtlose Kommunikationskomponente zur Durchführung drahtloser Kommunikation sein. Da die 802.11ax-Erweiterungen ausgenutzt werden, können die hier beschriebenen Ausführungsformen besser für 802.11ax-Einsätze oder APs mit 802.11ax-Funkgeräten geeignet sein, insbesondere im Wi-Fi 6/6GHz-Kontext. Das Funkgerät 206 kann so konfiguriert sein, dass es sowohl Daten sendet als auch empfängt. 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 einigen Ausführungsformen kann die Überwachungs- und Planungslogik 208 eine oder mehrere funktionale Einheiten umfassen, die unter Verwendung von Firmware, Hardware, Software oder einer Kombination davon implementiert sind, um Parameter zu konfigurieren, die mit AP 200 und/oder STA 210-1 für die Übertragung von Daten/Frames zu und von AP 200 verbunden sind. Obwohl die Überwachungs- und Planungslogik 208 so dargestellt ist, dass sie auf dem AP 200 implementiert ist, können eine oder mehrere physische oder funktionale Komponenten der Überwachungs- und Planungslogik 208 auf einem separaten Gerät implementiert sein, wie z. B. einem AP-Controller, bei dem es sich beispielsweise um den Controller 104 von 1A handeln kann. Die Überwachungs- und Planungslogik 208 kann eine oder mehrere funktionale Einheiten umfassen, die mit Firmware, Hardware, Software oder einer Kombination davon implementiert sind, um ein oder mehrere empfangene Daten/Frames zu überwachen und ein oder mehrere Daten/Frames zu planen, die an und/oder von AP 200 übertragen werden sollen. So kann die Überwachungs- und Planungslogik einen Verkehrsmonitor, einen UL-Scheduler und/oder einen DL-Scheduler umfassen, die jeweils mit den vorgenannten Funktionseinheiten implementiert werden können.
In verschiedenen Ausführungsformen kann die Überwachungs- und Planungslogik 208 eine Logik zur Priorisierung enthalten. In verschiedenen Ausführungsformen können die in UL- und/oder DL-Richtung gesendeten Frames priorisiert werden. In verschiedenen Ausführungsformen können Frames priorisiert werden, indem Werte für einen oder mehrere hierin beschriebene Parameter, wie MU-EDCA-Parameter und/oder EDCA-Parameter, angepasst werden, zum Beispiel durch Anpassung von AC. Zum Beispiel können alle UL-Verkehrsströme, die mit einem QoS-sensitiven Anwendungsstrom verbunden sind, identifiziert werden (z. B. durch Überwachungslogik). Der geeignete AC, der mit den identifizierten UL-Verkehrsströmen verbunden ist, kann bestimmt werden. In einigen Ausführungsformen kann der ausgewählte AC eine höhere Priorität als die der UL-Verkehrsströme haben. In einigen Ausführungsformen kann die Priorität aller Verkehrsströme festgelegt werden. In einigen Ausführungsformen kann die Überwachungs- und Planungslogik 208 eine oder mehrere Daten oder Frames von einer bestimmten STA planen, z. B. durch Erzeugen eines oder mehrerer Trigger-Frames. In einigen Ausführungsformen kann die Überwachungs- und Planungslogik 208 eine oder mehrere Daten oder Frames von einer bestimmten STA auf der Grundlage des Verkehrsflusses mit der höchsten Priorität für diese bestimmte STA planen. So können in verschiedenen Ausführungsformen ein oder mehrere Frames in einem Anwendungsfluss priorisiert werden.
Wenn die STA x y UL-Verkehrsströme hat, kann die Priorität für die STA x die maximale Priorität der y Verkehrsströme sein. Wenn der DL-Verkehr für einen bidirektionalen Fluss priorisiert wird, kann der AP den UL-Verkehr von der STA für denselben Fluss priorisieren. Wenn z. B. der DL-Verkehr zu einer bestimmten STA für einen bidirektionalen Fluss vom AP priorisiert wird, kann der UL-Verkehr von dieser bestimmten STA priorisiert werden (d. h. durch Zuweisung einer hohen Priorität). Die Ziel-StAs für den DL-Verkehr der priorisierten bidirektionalen Flüsse können bei der Planung von UL-Übertragungen eine höhere Priorität erhalten. Dadurch kann sichergestellt werden, dass die Ströme besseren Kanalzugang erhalten als der gesamte andere Verkehr für andere STAs im drahtlosen Netzwerk.
Verschiedene Ausführungsformen können diese Frames planen, die in der UL- und/oder DL-Richtung gesendet werden. Die Überwachungs- und Planungslogik 208 kann einen oder mehrere Trigger-Frames erzeugen, die vom AP 200 gesendet werden. Trigger-Frames können BSRP-Trigger-Frames, aber auch andere, separate Trigger-Frames umfassen, die für die Planung des Verkehrs (z. B. in der UL) konfiguriert sind. Verschiedene Ausführungsformen können diese Frames, die in der UL- und/oder DL-Richtung gesendet werden, basierend auf einer oder mehreren Informationen in BSR, die von STAs empfangen werden, planen. Verschiedene Ausführungsformen können die in UL- und/oder DL-Richtung gesendeten Frames planen, z. B. auf der Grundlage von Informationen aus früheren, von den STAs empfangenen Frames. Verschiedene Ausführungsformen können diese Frames, die vom Client-Gerät/STA 210-1 und/oder Client-Gerät/STA 210-2 gesendet werden, dynamisch planen, zum Beispiel durch Anpassen einer oder mehrerer Ressourceneinheiten (RUs) und/oder durch dynamisches Anpassen eines oder mehrerer hier besprochener Parameter (wie MU EDCA und/oder EDCA-Parameter). Verschiedene Ausführungsformen können die von dem Client-Gerät/STA 210-1 und/oder dem Client-Gerät/STA 210-2 gesendeten Frames (z. B. Frames, die Daten oder Verkehr enthalten, aber auch Frames, die BSR enthalten) dynamisch anpassen.
Wie in 2A dargestellt, kann der AP 200 Frames von STA 210-1, STA-2 (und/oder anderen STAs, nicht dargestellt) über den Kommunikationskanal 201 in der UL-Richtung empfangen, während er Frames an Client-Gerät/STA 210-1, Client-Gerät/STA 210-2 (und andere STAs, nicht dargestellt) in der DL-Richtung sendet. Wie im Folgenden näher erläutert wird, passt eine Ausführungsform das BSRP-Trigger-Intervall oder die BSRP-Trigger-Frequenz für das Senden von BSRP-Triggern an WLAN-Geräte (z. B. STA 210-1, STA 210-2 oder ein anderes WLAN-Gerät, nicht dargestellt) dynamisch an. Die Logik zum dynamischen Anpassen des BSRP-Trigger-Intervalls oder der BSRP-Trigger-Frequenz kann in der Überwachungs- und Planungslogik 208 enthalten sein.
Es versteht sich, dass die Überwachungs- und Planungslogik 208 (z. B. durch den DL-Scheduler) BSRP-Trigger so planen kann, dass sie gemäß einem bestimmten BSRP-Trigger-Intervall oder einer bestimmten BSRP-Trigger-Häufigkeit übertragen werden. Es versteht sich, dass das BSRP-Trigger-Intervall mit der BSRP-Trigger-Häufigkeit in Beziehung stehen kann, indem die BSRP-Trigger-Häufigkeit einer Anzahl von BSRP-Triggern entsprechen kann, die innerhalb eines begrenzten Zeitraums, der dem BSRP-Trigger-Intervall entsprechen kann, übertragen werden sollen oder übertragen werden. Der Scheduler kann einen Timer starten, der dem BSRP-Trigger-Intervall entspricht. Der Zeitgeber kann bei der Übertragung oder Erzeugung eines BSRP-Triggers gestartet oder zurückgesetzt werden. Der Timer kann auf einen Wert zurückgesetzt werden, der dem BSRP-Tigger-Intervall entspricht, wie es im Scheduler aktualisiert wurde. Das BSRP-Trigger-Intervall kann ein Beacon-Intervall oder ein anderes, z. B. benutzer/systemdefiniertes Intervall sein. Das BSRP-Trigger-Intervall kann einen Standardwert haben, der einem Beacon-Intervall oder einem anderen, z. B. benutzer-/systemdefinierten Intervall entspricht. Verschiedene hier beschriebene Ausführungsformen sind in der Lage, eine dynamische Anpassung des BSRP-Trigger-Intervalls oder der BSRP-Trigger-Häufigkeit zu bewirken. Ein Fachmann würde verstehen, wie die BSRP-Trigger-Häufigkeit entsprechend den Änderungen des BSRP-Intervalls (und umgekehrt) modifiziert werden kann.
In einigen Ausführungsformen können bestimmte Netzmerkmale genutzt werden, darunter die folgenden:

Es versteht sich, dass verschiedene Ausführungsformen auf jeder AP-Plattform mit Echtzeitvorteilen implementierbar sind. Ein AP kann jederzeit den Umfang des UL-Verkehrs in der Warteschlange ermitteln, indem er BSR-Informationen (z. B. in empfangenen QoS-Frames) verarbeitet. Der AP kann zu jedem Zeitpunkt den Umfang des UL-Verkehrs in der Warteschlange einer bestimmten TID/AC an einer STA ermitteln.

802.11ax-konforme STAs sind in der Lage, UL-MU-Übertragungen durchzuführen. Daher können UL-Daten entweder über SU- oder MU-Übertragungen zu einem AP gelangen. Es gibt eine Kategorie von STAs, die die UL MU-Datenübertragung nicht unterstützen, und daher können solche STAs nur auf UL SU-Übertragungen zurückgreifen. STAs, die UL MU-Übertragungen unterstützen, können von einem AP in der UL-Richtung als Teil von Trigger-basierten MU-Übertragungen eingeplant werden. Dementsprechend benötigen solche STAs möglicherweise keine Gelegenheit zum Medium-/Kanalzugriff, um ihre Daten in der Warteschlange für die UL-Übertragung zu übertragen.
Es sollte klar sein, dass jeder AP, z. B. durch den UL-Scheduler, eine oder mehrere STAs für die Übertragung im ULeinplanen kann (z. B. durch MU-Mittel). Jeder AP kann MU-EDCA-Parameter und SU-EDCA-Parameter ankündigen, die von STAs für UL verwendet werden sollen, z. B. durch die Übertragung von einem oder mehreren Beacons oder Trigger-Frames. Die STAs, die in den hier diskutierten Schemata bewertet werden, sind nicht auf das AP BSS beschränkt. Verschiedene Ausführungsformen sind darauf ausgerichtet, BSR-Informationen von STA zu nutzen, die der AP hören kann.
Es versteht sich von selbst, dass verschiedene Ausführungsformen in der Lage sind, eine dynamische Anpassung der BSRP-Trigger-Intervalle oder der BSRP-Trigger-Häufigkeit unter einer Vielzahl von Szenarien zu bewirken. Zum Beispiel kann es in einigen Kommunikationsszenarien zahlreiche STA-Geräte geben, die versuchen, auf den Kanal 201 zuzugreifen (nicht dargestellt), während es in anderen Szenarien eine geringere Anzahl sein kann. In einigen Kommunikationsszenarien kann es beispielsweise gemischte Clients geben (d. h. eine Vielzahl von Kanalzugriffsschemata, wie z. B. hocheffiziente oder MU-Schemata, oder SU-Schemata).
Es versteht sich, dass die hier offengelegte dynamische Anpassung der BSRP-Trigger-Intervalle oder der BSRP-Trigger-Frequenz nicht auf die Verwendung mit APs/AP-Controllern beschränkt sein muss, sondern auch mit 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 den konventionellen Kanalzugang (d. h. drahtgebunden und/oder drahtlos) in zwei Richtungen (UL und DL) in Bezug auf ein bestimmtes Gerät (d. h. nicht unbedingt ein WLAN-Gerät) zu verbessern. Die dynamische Anpassung der BSRP-Trigger-Intervalle oder der BSRP-Trigger-Häufigkeit kann auch anwendungsspezifisch angewendet oder genutzt werden. Das heißt, wenn ein Netz, z. B. das Netz 100 (1A) oder einige Teile davon überlastet werden, kann bestimmten Anwendungen eine höhere Priorität als anderen eingeräumt werden.
Der hier verwendete Begriff „Verkehrsfluss“ kann sich auf einen Strom von Datenpaketen, z. B. Segmenten, Frames oder Datagrammen, beziehen, die sich denselben Kanal teilen. Der hier verwendete Begriff „Verkehrsfluss“ kann sich auf einen Strom von Datenpaketen, z. B. Segmenten, Frames oder Datagrammen, beziehen, die dasselbe 5-Tupel haben. Das oben genannte 5-Tupel kann sich auf einen Satz von fünf verschiedenen Werten beziehen, die eine TCP/IP-Verbindung umfassen, und beinhaltet: eine Quell-IP-Adresse, eine Ziel-IP-Adresse, eine Quell-Port-Adresse, eine Ziel-Port-Adresse und das verwendete Protokoll (TCP/UDP).
Die Art und Weise, in der die Daten charakterisiert werden, kann z. B. von einem Entwickler oder einer anderen Instanz 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 (oder einem anderen EDCA- oder MU-EDCA-Parameter) zugeordnet und schließlich, wie hierin beschrieben, priorisiert werden kann.
Es ist anzumerken, dass eine Deep Packet Inspection für Verkehrsströme durchgeführt werden kann, um festzustellen, ob die Segmente/Datagramme für einen bestimmten Verkehr einer angekündigten Priorität entsprechen sollten. Außerdem kann die Deep Packet Inspection als Teil einer oder mehrerer Verhandlungen zwischen dem AP und den Client-Geräten durchgeführt werden. Dementsprechend müssen die Segmente/Datagramme für einen bestimmten Verkehr nicht unbedingt der angekündigten Priorität entsprechen (z. B. wie von den STAs angekündigt).
2B zeigt einen beispielhaften Nachrichtenfluss, der unaufgeforderte BSR (z. B. QoS-Null-Daten oder als Teil des MAC-Headers) und angeforderte BSR (z. B. angefordert durch BSRP-Trigger-Frames) umfasst. Wie in 2B dargestellt, kann ein AP, d.h. AP 200, mit einem oder mehreren STAs verbunden sein (z.B. 2010-1 und 210-2 - dargestellt). So kann AP 200 BSR-Daten-Frames (z. B. als Teil des MAC-Headers oder QoS-Null/Daten-Frames) von einem oder mehreren STAs (z. B. 206a-1) empfangen und analysieren. Die BSR-Daten-Frames können die Frame-Größe für die Warteschlange im UL-Puffer jeder STA enthalten. Dementsprechend kann der AP 200 die in diesen BSR-Frames (z. B. QoS-Null-/Daten-Frames) enthaltenen UL-Scheduling-Informationen (die für die Übertragung gepufferten UL-Daten) zur Kenntnis nehmen.
Beispielsweise kann STA 210-1 unaufgeforderte BSRs gegenüber QoS Null/Data-Frames an AP 200 senden. Im Fall von angeforderten BSRs kann AP 200a einen BSRP (d. h. einen Trigger-Frame, der eine Anforderung von BSR-Informationen anzeigt) an STA 210-1 senden. STA 210-1 kann dann an AP 200 antworten, indem sie einen QoS-Null-Frame mit BSR-Informationen, z. B. der Größe des Warteschlangen-Frames, an AP 206a sendet, damit AP 206a UL-Verkehr planen kann. Es ist zu beachten, dass AP 200 bei der Übertragung des BSRP RUs zuweist und STA 210-1 die BSR-Informationen (z. B. als Teil des/der QoS-Null-Frames mit den BSR-Informationen) in den zugewiesenen RUs überträgt. Ebenso können andere STAs (z. B. STA 210-2), die dem AP zugeordnet sind, unaufgeforderte BSRs zusammen mit QoS-Null-/Daten-Frames an den AP 20 senden0. Darüber hinaus kann der AP 200 einen BSRP an andere STAs (z. B. STA 210-2) senden (in einem angeforderten Szenario können diese anderen STAs dann an den AP 200 antworten, indem sie BSR-Informationen (z. B. als Teil eines QoS-Null-Frames), z. B. die Größe ihres Warteschlangen-Frames, an den AP 200 senden, damit der AP 200 UL-Verkehr planen kann).
Das BSRP-Intervall oder die BSRP-Häufigkeit kann der Zeit zwischen aufeinander folgenden BSRP-Triggers entsprechen. In den hier beschriebenen Ausführungsformen kann das BSRP-Intervall oder die BSRP-Häufigkeit dynamisch angepasst werden, auch auf der Grundlage des Pufferstatus der einzelnen STA. In einigen Ausführungsformen kann die BSRP-Häufigkeit darauf basieren, wie viele Bytes sich im Puffer befinden, wie von jeder STA bekannt gegeben (d. h. die Größe der gemeldeten Frames), abzüglich der Bytes, die vom Client (vor dem nächsten BSRP-Trigger) gesendet wurden. Der Scheduler kann z. B. so konfiguriert werden, dass er die anstehenden Frames jeder STA extrahiert.
Die von den STAs gesendeten Bytes oder Frames können durch Überwachung der am AP empfangenen Frames bestimmt werden, z. B. durch die Überwachungs- und Planungslogik 208. Der UL-Pufferstatus kann auch durch die Überwachung von am AP empfangenen Frames ermittelt werden. Anstehende Bytes können die in den BSR angekündigten Bytes sein (d. h. als im Puffer befindlich angekündigt), abzüglich der von der STA mit beliebigen Mitteln (z. B. SU- und/oder MU-Schemata) gesendeten Bytes. Anstehende Bytes können die in den BSR angekündigten Bytes sein (d. h. wie im Puffer angekündigt), abzüglich der Bytes, die von der STA auf beliebige Weise (z. B. SU- und/oder MU-Mittel) seit dem Empfang der BSR gesendet wurden. Die Bestimmung der anstehenden Bytes kann einer Bestimmung entsprechen, wie viele Bytes im Puffer verbleiben, um von jeder STA gesendet zu werden. In Ausführungsformen kann der UL-Scheduler die anstehenden Frames der STAx zum Zeitpunkt t als Reported frames (x,t) extrahieren. Zum Zeitpunkt t1, wenn der nächste BSRP generiert oder ausgelöst wird, können die von STA x auf beliebige Weise (SU/MU) gesendeten UL-Bytes als Sent frames(x,t,t1) erfasst werden. Der Scheduler kann feststellen, dass Pending frames(x,t,t1)= Reported frames (x,t) - Sent frames(x,t,t1).
2C zeigt Beispiele für Schwellenwerte für anstehende Frames für das BSRP-Schema zur Selbstanpassung in Übereinstimmung mit verschiedenen Ausführungsformen. Die hier beschriebenen Ausführungsformen können einen oder mehrere Schwellenwerte für den Vergleich anstehender Frames 253 (z. B. anstehende UL-Frames) aufweisen. 2C zeigt drei Diagramme 250a, 250b, 250c von anstehenden Frames 253 in einer Zeitreihe und definierten Schwellenwerten. Die Zeitreihe der anstehenden Frames 253 kann jedes Mal, wenn sie bestimmt oder berechnet wird, auf der Grundlage der anstehenden Frames erstellt werden. Beispielsweise können anstehende Frames jedes Mal ermittelt oder berechnet werden, wenn neue Frames empfangen werden (z. B. Daten-Frames und/oder Frames, die BSR-Informationen umfassen). Die Zeitreihe kann bei oder zwischen der Auslösung von nachfolgenden BSRP-Trigger-Frames und/oder beim oder zwischen dem Empfang von BSR-Informationen erstellt werden.
Wie noch näher erläutert wird, können die Schwellenwerte dynamisch angepasst werden und auf einer bestimmten Priorität für den Verkehr (z. B. Verkehrsfluss) basieren. Die Anzahl, die Art und/oder der Wert der Schwellenwerte kann auf den Anforderungen der Dienstgütevereinbarung für verschiedene Verkehrsarten (z. B. Sprache, Video usw.) basieren. Es können also ein oder mehrere Schwellenwerte verwendet werden. Es wird hier auf einen höheren und einen niedrigeren Schwellenwert verwiesen. Da die Werte für den höheren und den niedrigeren Schwellenwert angepasst werden können, muss der höhere Schwellenwert nicht unbedingt über dem niedrigeren Schwellenwert liegen. Ebenso muss ein Wert für den unteren Schwellenwert nicht niedriger sein als der obere Schwellenwert. Der untere Schwellenwert kann eine Anpassung der BSRP-Häufigkeit oder des BSRP-Intervalls bedeuten, wenn die ausstehenden Byes (oder Frames) bei oder unter dem unteren Schwellenwert liegen. Der höhere Schwellenwert kann eine Anpassung der BSRP-Häufigkeit oder des BSRP-Intervalls bedeuten, wenn die anstehenden Byes (oder Frames) den höheren Schwellenwert erreichen oder überschreiten.
Diagramm 250a zeigt die anstehenden Frames 253 und den höheren Schwellenwert 255a. Diagramm 250b zeigt die anstehenden Frames 253 und den unteren Schwellenwert 25b6. Diagramm 250c zeigt die anstehenden Frames 253, den höheren Schwellenwert 255c und den niedrigeren Schwellenwert 256c.
Der untere Schwellenwert und/oder der höhere Schwellenwert können definiert und verwendet werden (d.h. nur der untere Schwellenwert 256b, wie in Grafik 250b dargestellt, nur der höhere Schwellenwert 255a, wie in Grafik 250a dargestellt, oder sowohl der untere Schwellenwert 256c als auch der höhere Schwellenwert 255c, wie in Grafik 250c dargestellt). Die Schwellenwerte und die Lage der anstehenden Bytes oder Frames im Verhältnis zu diesem Schwellenwert können zur Aktualisierung des Schedulers verwendet werden, um die BSRP-Häufigkeit und/oder das BSRP-Intervall anzupassen (z. B. zu verringern, zu erhöhen oder auf einen Standardwert zurückzusetzen).
In bestimmten Fällen können die Werte für den unteren Schwellenwert von einer bestimmten Priorität (z. B. für die Frames und/oder den Verkehrsfluss) abhängen. So kann die Erhöhung der Häufigkeit von BSRP-Trigger-Frames dazu führen, dass mehr Verkehr mit hoher Priorität (z. B. mit geringer Latenz) übertragen werden kann. So könnte für jede Priorität ein anderer unterer Schwellenwert festgelegt werden. Mit anderen Worten: Der Wert des unteren Schwellenwerts kann von der Priorität abhängen. Der untere Schwellenwert kann dazu verwendet werden, den Scheduler zu aktualisieren, um einen häufigeren BSRP zu planen (und damit auszulösen). Bei der Auslösung von BSRP kann der untere Schwellenwert eine positive Korrelation mit der Priorität des Verkehrs von einer STA aufweisen. Für dieselbe Verkehrsart (z. B. denselben AC) kann eine STA mit höherer Priorität für die Auslösung von BSRP einen höheren unteren Schwellenwert haben als eine STA mit niedrigerer Priorität für die Auslösung von BSRP. Ein weiteres Beispiel: Wenn eine erste STA eine höhere Priorität hat als eine zweite STA, ist der untere Schwellenwert der STA mit höherer Priorität höher als der untere Schwellenwert der STA mit niedrigerer Priorität. Wenn also Priority of Client (x) >_ Priority of Client (y), dann Threshold_lower of Client(x) ≥ Threshold_lowe of Client (y).
Der höhere Schwellenwert kann eine positive Korrelation mit der STA-Priorität haben. Für dieselbe Verkehrsart (z. B. für dieselbe TID oder denselben AC) kann eine STA mit höherer Priorität für die Auslösung von BSRP einen höheren Wert für den höheren Schwellenwert haben. Wenn also Priority of Client (x) ≥ Priority of Client (y), dann Threshold_higher of Client(x) ≥ Threshold_higher of Client (y).
In einigen Ausführungsformen können die anstehenden Bytes oder Frames mit einem unteren Schwellenwert verglichen werden. Die BSRP-Häufigkeit kann sich erhöhen (und damit das BSRP-Intervall verringern), wenn die anstehenden Bytes unter dem unteren Schwellenwert liegen. In einigen Ausführungsformen wird ein BSRP sofort (oder nahezu sofort) ausgelöst (d. h. mit einem kleinen BSRP-Intervall), wenn die anstehenden Bytes unter einem Schwellenwert liegen.
In bestimmten Fällen können die anstehenden Frames (oder anstehenden Bytes) unter dem unteren Schwellenwert (256b, 256c) liegen, z. B. wenn die STA zwischen zwei aufeinanderfolgenden BSRP-Triggern mehr Frames durch SU-Übertragungen (im Vergleich zu MU-Übertragungen) sendet. In bestimmten Ausführungsformen können die anstehenden Frames (oder anstehenden Bytes) geringer sein als der untere Schwellenwert, wenn die STA nicht mit mehr Daten in die Warteschlange gestellt wurde, während ein oder mehrere Frames gesendet wurden - und infolgedessen kann die Anzahl der anstehenden Frames auf dem Client sinken.
In bestimmten Fällen kann die BSRP-Häufigkeit oder das BSRP-Intervall von einer Trendlinie oder Steigung für die anstehenden Frames abhängen. Beispielsweise kann die BSRP-Häufigkeit oder das BSRP-Intervall davon abhängen, ob die Größe oder die Anzahl der anstehenden Frames zunimmt oder abnimmt (d. h. in einer Zeitreihe anstehender Frames). Wenn beispielsweise Pending frames(x,t,t1) zunimmt (d. h. eine positive Steigung aufweist) und den unteren Schwellenwert nach oben überschreitet (d. h. von unterhalb des unteren Schwellenwerts oder am Schwellenwert bis zum unteren Schwellenwert oder oberhalb des unteren Schwellenwerts), könnte der Scheduler entweder die Häufigkeit der BSRP auf den Standardwert zurücksetzen oder die Häufigkeit der BSRP auf einen geeigneten Wert verringern. Mit Bezug auf das in 2C gezeigte Diagramm 250b können die anstehenden Frames 257 in der Zeitreihe der anstehenden Frames 253 das Kriterium erfüllen, dass ein Betrags von Pending frames(x,t,t1)ansteigt (d. h. eine positive Steigung) und den unteren Schwellwert 256b in Aufwärtsrichtung überschreitet.
Ein höherer Schwellenwert könnte verwendet werden, um den Scheduler so zu aktualisieren, dass er weniger häufig BSRP einplant (und damit auslöst) (d. h., dass die BSRP-Häufigkeit abnimmt). Die BSRP-Häufigkeit kann abnehmen, wenn die anstehenden Bytes einen höheren Schwellenwert überschreiten. Wenn also Pending frames(x,t,t1) größer ist als der hohe Schwellenwert, dann könnte der Scheduler die Häufigkeit der Auslösung des BSRP verringern. Dies könnte der Fall sein, wenn die STA zwischen zwei aufeinanderfolgenden BSRP-Ereignissen keine oder viele Frames durch SU-Übertragungen gesendet hat, oder wenn die STA mit mehr Daten als zuvor in der Warteschlange steht - und infolgedessen die Anzahl der anstehenden Frames auf dem Client ansteigt. Wenn Pending frames(x,t,t1) annehmend ist (z. B. mit negativer Steigung oder abnehmender Trendlinie) und den höheren Schwellenwert nach unten überschreitet, könnte der Scheduler entweder die Häufigkeit der BSRP auf einen Standardwert zurücksetzen oder die Häufigkeit der BSRP auf einen geeigneten Wert erhöhen. Mit Bezug auf das in 2C gezeigte Diagramm 250a können die anstehenden Frames 258 in der Zeitreihe der anstehenden Frames 253 das Kriterium erfüllen, dass der Betrag von Pending frames(x,t,t1) abnimmt (d. h. eine negative Steigung) und den höheren Schwellenwert 255a in Abwärtsrichtung überschreitet.
3A und 3B zeigen Blockdiagramme einer beispielhaften Rechnerkomponente oder eines Geräts 300 zur Optimierung des UL-Schedulers mit selbstanpassendem BSRP-Schema in Übereinstimmung mit verschiedenen Ausführungsformen.
Bei der Rechnerkomponente kann es sich beispielsweise um einen Servercomputer, ein Steuergerät oder eine andere ähnliche Rechnerkomponente 300 handeln, die in der Lage ist, Daten zu verarbeiten. In der Beispielimplementierung von 3A umfasst die Rechnerkomponente 300 einen Hardwareprozessor 302 und ein maschinenlesbares Speichermedium 304. In einigen Ausführungsformen kann die Rechnerkomponente 300 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 302 kann es sich um eine oder mehrere Zentraleinheiten (CPUs), Mikroprozessoren auf Halbleiterbasis und/oder andere Hardwarevorrichtungen handeln, die zum Abrufen und Ausführen von Befehlen geeignet sind, die in einem maschinenlesbaren Speichermedium 304 gespeichert sind. Der Hardware-Prozessor 302 kann Befehle, wie die Befehle 306-316, abrufen, dekodieren und ausführen, um Prozesse oder Vorgänge zur Priorisierung bidirektionaler Verkehrsflüsse zu steuern. Alternativ oder zusätzlich zum Abrufen und Ausführen von Befehlen kann der Hardware-Prozessor 302 einen oder mehrere elektronische Schaltkreise umfassen, die elektronische Komponenten zur Ausführung der Funktionalität eines oder mehrerer Befehle enthalten, z. B. ein Field Programmable Gate Array (FPGA), einen anwendungsspezifischen integrierten Schaltkreis (ASIC) oder andere elektronische Schaltkreise.
Ein maschinenlesbares Speichermedium, wie z. B. ein maschinenlesbares Speichermedium 304, kann ein beliebiges elektronisches, magnetisches, optisches oder sonstiges physikalisches Speichergerät sein, das ausführbare Anweisungen enthält oder speichert. Bei einem maschinenlesbaren Speichermedium 304 kann es sich beispielsweise um einen Direktzugriffsspeicher (RAM), einen nichtflüchtigen Arbeitsspeicher (NVRAM), einen elektrisch löschbaren, programmierbaren Festspeicher (EEPROM), ein Speichergerät, eine optische Platte oder Ähnliches handeln. In einigen Ausführungsformen kann das maschinenlesbare Speichermedium 304 ein nicht-transitorisches Speichermedium sein, wobei der Begriff „nichttransitorisch“ nicht die transitorischen Übertragungssignale umfasst. Wie nachstehend im Detail beschrieben, kann das maschinenlesbare Speichermedium 304 mit ausführbaren Anweisungen kodiert sein, z. B. mit den in 3A dargestellten Anweisungen306-316. Die in 3A gezeigten Befehle 306-316 und die in 3B gezeigten Befehle 330-367 können in der in 2A gezeigten Überwachungs- und Planungslogik 208 enthalten sein oder enthalten werden.
Der Hardware-Prozessor 302 kann den Befehl 308 ausführen, um empfangene Frames zu überwachen. Die Frames können von STAs empfangen werden. Die Überwachung der empfangenen Frames kann die Extraktion von Informationen aus den Frames beinhalten. Diese Frames könnten unaufgeforderte oder angeforderte Frames sein (z. B. wie in 2B gezeigt). Diese empfangenen Frames können in der UL-Richtung sein. Empfangene Frames können von SU und/oder MU-Mitteln empfangen werden. Wie bereits erwähnt, können die empfangenen Frames BSR-Informationen enthalten, zum Beispiel die (gemeldete) Größe eines UL-Puffers. Empfangene Frames können die folgenden Frames enthalten: SU UL QoS-Null-Frames, nachfolgende QoS-Daten- oder QoS-Null-Frames, die als Teil von UL-OFDMA-Übertragungen empfangen werden, und UL SU QoS-Daten-Frames. Wie bereits erwähnt, können die BSR-Informationen als Teil des QoS-Kontrollfelds des 802.11 MAC-Headers aufgenommen werden. Wie bereits beschrieben, kann der AP (z. B. AP 200 durch die Überwachungs- und Planungslogik 208) empfangene Frames überwachen, um die gemeldeten Frames (z. B. Bytes davon) im UL-Puffer und/oder gesendete Frames (z. B. gesendete Bytes) zu bestimmen. So kann die Anweisung 308 zur Überwachung empfangener Frames die Bestimmung der anstehenden Frames oder Bytes im Puffer jeder STA beinhalten (d. h. gemeldete Frames oder Bytes abzüglich der Frames oder Bytes, die tatsächlich übertragen wurden).
Es versteht sich, dass die Ausführung der Anweisung 308 die Initialisierung eines oder mehrerer Parameter umfassen kann, um mit der Überwachung des Verkehrs von STAs zu beginnen. Es versteht sich, dass empfangene Frames überwacht werden können, um festzustellen, ob in der Warteschlange stehende UL-Daten/Frames in bestimmte ACs (z. B. die BE- und/oder BK-ACs) fallen.
Der Hardware-Prozessor 302 kann den Befehl 310 ausführen, um festzustellen, ob ein Fluss (z. B. ein neuer Fluss) erkannt (z. B. gestartet) wurde. Der Hardware-Prozessor 302 kann die Anweisung 310 ausführen, um festzustellen, ob ein neuer STA erkannt wurde. Die Anweisung 310 kann ausgeführt werden, um festzustellen, ob ein Fluss beendet wurde (d. h. im Verhältnis zu einem Fluss, der bereits begonnen hat). Wird festgestellt, dass der Fluss beendet ist, kann der Hardware-Prozessor 302 zur Ausführung von Anweisung 308 zurückkehren, um die Überwachung der empfangenen Frames fortzusetzen.
Es versteht sich, dass die Anweisungen 308-316 mit der Anweisung 306 zur Überwachung empfangener Frames „beginnen“ können. Es kann jedoch auch verstanden werden, dass die Anweisung 310 jederzeit ausgeführt werden kann (z. B. kann der Verkehrsüberwacher feststellen, wann Datenflüsse beginnen oder enden usw.) Es versteht sich also, dass die Anweisungen 308-316 auch mit der Anweisung 310 zur Erkennung eines Datenflusses „beginnen“ können.
Der Hardware-Prozessor 302 kann den Befehl 312 ausführen, um die STA-Priorität zu bestimmen. Die STA-Priorität kann für einen Fluss bestimmt werden (z. B. wenn ein neuer Fluss gestartet wurde, wie durch die Ausführung von Befehl 310 festgestellt). Die STA-Priorität kann mit den Mitteln bestimmt werden, die in Bezug auf 2A-2B diskutiert wurden. Es versteht sich von selbst, dass die Priorisierung des Datenverkehrs von internen Software-/Hardware-Implementierungsaspekten/Merkmalen abhängen kann, die sich auf die Planung des Datenverkehrs auswirken oder diese verändern können. Das heißt, dass AP-Implementierungen durch Analyse der Metadaten diejenigen Verkehrsflüsse bestimmen können, die einer hohen Priorität entsprechen (z. B. Kanalzugriff mit höherer Priorität). Die STA-Priorität kann für jede STA ermittelt werden, die einen Datenfluss gestartet hat. Wie bereits erwähnt, entspricht die Priorität nicht unbedingt einer angekündigten Priorität. Die Priorität kann z. B. auf der höchsten Priorität für alle Ströme einer STA basieren. Dementsprechend kann der Hardware-Prozessor 302 die Anweisung 312 ausführen, um festzustellen, ob ein latenzempfindlicher oder hochprioritärer Datenfluss erkannt wird. In Beispielimplementierungen kann die Priorität einer STA neu berechnet werden, wenn entweder ein Ende oder ein Anfang des latenzempfindlichen oder hochprioritären Stroms einer STA erkannt wird (z. B. bei der Ausführung von Befehl 310 und/oder Befehl 312), z. B. bei der Ausführung von Befehl 312.
Der Hardware-Prozessor 302 kann die Anweisung 314 ausführen, um einen oder mehrere Schwellenwerte zu definieren. Schwellenwerte (z. B. Werte, Anzahl oder Arten von Schwellenwerten) können auf der Grundlage der ermittelten STA-Priorität definiert werden (z. B. bei der Ausführung von Anweisung 312). Die mit Bezug auf 2C diskutierten Schwellenwerte, wie niedrige und/oder höhere Schwellenwerte, können Beispielschwellenwerte sein, die für diese Anweisung repräsentativ sind. Es versteht sich, dass die Schwellenwerte (z. B. unterer Schwellenwert und/oder höherer Schwellenwert) für den Vergleich anstehender Frames für jede STA auf der Grundlage dieser letzten Priorität für die STA aktualisiert werden können (z. B. bei der Ausführung der Anweisung 316). Es sollte klar sein, dass durch die Anpassung eines oder mehrerer Schwellenwerte für den Vergleich anstehender Frames auf der Grundlage der Priorität den Flüssen mit niedriger Latenz (d. h. dem Verkehr, der zu den VO/VI ACs gehört/entspricht) mehr Gelegenheit gegeben werden kann, Daten in der Warteschlange zu übertragen. Beispielsweise kann die Erhöhung des unteren Schwellenwerts für den Vergleich anstehender Frames (z. B. wie in 2C gezeigt) es dem Scheduler ermöglichen, die BSRP für mehr anstehende Bytes anzupassen (z. B. für Bytes unterhalb dieses erhöhten unteren Schwellenwerts).
In einigen Ausführungsformen sind die Anweisungen 308-316 mit dem überwachten Verkehr (z. B. Daten/Frames) verbunden und können daher von der Verkehrsüberwachungskomponente der Überwachungs- und Planungslogik 208 ausgeführt werden. Es versteht sich, dass die Befehle 308-316 nach der Übertragung eines BSRP-Triggers ausgeführt werden können. Es versteht sich, dass die Ausführung der Anweisungen 308-316 es einem AP ermöglichen kann, die BSRP-Häufigkeit und/oder das BSRP-Intervall dynamisch anzupassen. Der Hardware-Prozessor 302 kann die Anweisung 316 ausführen, um den Scheduler (z. B. UL-Scheduler) zu aktualisieren. Wie bereits erwähnt, kann der Scheduler Bestandteil der Überwachungs- und Planungslogik 208 sein. Der UL-Scheduler kann einen oder mehrere Verkehre von STAs planen und/oder zugewiesene Kanalressourcen für STAs ändern. Der Scheduler kann BSRP-Trigger planen und/oder übertragen (z. B. durch den DL-Scheduler für Trigger in der DL). So kann die Ausführungsanweisung 316 dem Scheduler eine oder mehrere Informationen aus überwachten Frames zur Verfügung stellen. Dies kann beispielsweise die Bereitstellung eines überwachten Frames oder anderer Informationen an den Scheduler umfassen, die aus dem überwachten Frame (z. B. bei der Ausführung von Anweisung 308), dem erkannten Fluss (z. B. bei der Ausführung von Anweisung 310), der ermittelten STA-Priorität (z. B. wie bei der Ausführung von Anweisung 312) und/oder den definierten Schwellenwerten (z. B. wie bei der Ausführung von Anweisung 316) ermittelt wurden. Die Ausführung von Anweisung 316 kann auch die Bereitstellung von Werten für einen oder mehrere zu aktualisierende Parameter an den Scheduler beinhalten, beispielsweise EDCA- oder MU-EDCA-Parameter. Die Ausführung der Anweisung 316 zur Aktualisierung des Schedulers kann die Bereitstellung von Werten für das BSRP-Intervall oder die BSRP-Häufigkeit, z. B. den Standardwert, und/oder auf der Grundlage eines überwachten Frames (z. B. bei der Ausführung der Anweisung 308), des erkannten Flusses (z. B. bei der Ausführung der Anweisung 310), der bestimmten STA-Priorität (z. B. wie bei der Ausführung der Anweisung 312 bestimmt) und/oder der definierten Schwellenwerte (z. B. bei der Ausführung der Anweisung 316) umfassen.
Die Aktualisierung des Schedulers auf der Grundlage der ermittelten STA-Priorität, des erkannten Flusses und der überwachten empfangenen Frames kann es ermöglichen, Ressourcen, z. B. Kanalressourcen für BSRP-Trigger, auf STAs mit hoher Priorität zu konzentrieren. In Ausführungsformen kann die Aktualisierung des Schedulers die dynamische Aktualisierung einer BSRP-Häufigkeit oder eines BSRP-Intervalls beinhalten. In Ausführungsformen können STAs durch die Aktualisierung des Schedulers (d. h. bei Anweisung 316) und durch die Planung oder Erzeugung von BSR-Trigger-Frames auf der Grundlage des aktualisierten Schedulers und schließlich durch deren Übertragung auf der Grundlage der aktualisierten Planung oder Erzeugung mit BSR-Informationen reagieren (z. B. als Teil der QoS-Steuerung oder der BSR-Steuerframes). Wenn der Scheduler aktualisiert wird, kann die Anweisung 308 erneut ausgeführt werden. Die Anweisung 308 kann erneut ausgeführt werden, um neue empfangene Frames nach der Aktualisierung des Schedulers bei der Ausführung der Anweisung 316.
3B zeigt eine Beispielrechnerkomponente, in der der UL-Scheduler mit einem selbstanpassenden BSRP-Schema gemäß verschiedenen Ausführungsformen optimiert ist. So zeigt 3B ein Beispiel für ein selbstanpassendes BSRP-Schema, bei dem die BSRP-Häufigkeit oder das BSRP-Intervall dynamisch angepasst werden kann. Die dynamische Anpassung der BSRP-Häufigkeit durch ein selbstanpassendes BSRP-Schema kann es dem AP ermöglichen, Kanalressourcen genauer zuzuweisen oder Verkehrsflüsse mit niedriger Latenz anderweitig zu planen, was zu einer robusteren/genaueren Bewertung von Flüssen und Anpassung führen kann. Der Prozessor 302 kann die Anweisungen 330-367 ausführen, um zumindest die in 3A gezeigte Anweisung 316 auszuführen. Der Prozessor 302 kann die Anweisung 330 ausführen, um empfangene Frames (d.h. deren Anzahl und/oder Bytes) und anstehende Frames (d.h. deren Anzahl und/oder Bytes) zu berechnen. Die empfangenen und anstehenden Frames können von und anstehenden STAs empfangen werden. Empfangene Frames können berechnet werden, indem empfangene Frames überwacht und beispielsweise ein oder mehrere Zähler, die empfangenen Frames von bestimmten STAs entsprechen, inkrementiert werden. Die anstehenden Frames können berechnet werden, indem empfangene Frames überwacht werden, angekündigte oder gemeldete anstehende Frames bestimmt werden (z. B. durch empfangene BSR-Informationen) und die empfangenen Frames, die seit dem Empfang oder der Übertragung der BSR-Informationen empfangen wurden, abgezogen werden. Die Anweisung 330 kann z. B. bei oder nach der Übertragung eines BSRP-Triggers ausgeführt werden, der den Empfang von Frames mit BSR-Informationen ausgelöst haben könnte. Ein BSRP-Trigger kann z. B. mit Standardwerten für die BSRP-Häufigkeit oder das BSRP-Intervall übertragen werden.
Wie bereits erwähnt, kann der Umfang des übertragenen Datenverkehrs mit dem anstehenden Datenverkehr und/oder der angekündigten Puffergröße (d. h. wie in den BSR-Informationen angegeben) verglichen werden. In Ausführungsformen kann die Menge des übertragenen Datenverkehrs mit der Menge der für diese STA geplanten Ressourcen verglichen werden. Der Prozessor 302 kann die Anweisung 335 ausführen, um festzustellen, ob die anstehenden Frames (z. B. wie bei der Ausführung der Anweisung 330 ermittelt) kleiner oder gleich dem unteren Schwellenwert sind. Es versteht sich, dass der untere Schwellenwert definiert oder aktualisiert worden sein könnte, beispielsweise wie unter Bezugnahme auf die in 3A und/oder 2C dargestellte Anweisung 314 beschrieben.
Die Anweisung 337 kann ausgeführt werden, wenn der Prozessor 302 bei der Ausführung der Anweisung 335 feststellt, dass die Anzahl der anstehenden Frames kleiner oder gleich dem unteren Schwellenwert ist. Der Prozessor 302 kann die Anweisung 337 ausführen, um einen BSRP-Trigger-Frame zu erzeugen und/oder zu planen, der übertragen werden soll (d. h. sofort oder fast sofort). Der Prozessor kann die Anweisung 337 ausführen, um die BSRP-Häufigkeit zu erhöhen (oder das BSRP-Intervall zu verringern). Die BSRP-Häufigkeit kann durch eine Erhöhung um einen bestimmten Betrag erhöht werden (z. B. um einen oder zwei BSRP-Trigger(s) in einem bestimmten Zeitraum). Die BSRP-Häufigkeit kann auf ein Niveau oberhalb eines Standardniveaus erhöht werden. Die BSRP-Häufigkeit kann durch Verringern des BSPR-Intervalls um einen bestimmten Betrag (z. B. um 0.1-200 ms) erhöht werden.
Der Hardware-Prozessor 302 kann die Anweisung 340 ausführen, um festzustellen, ob die Anzahl der anstehender Frames größer oder gleich einem höheren Schwellenwert ist. Der höhere Schwellenwert könnte z. B. bestimmt oder aktualisiert worden sein, wie unter Bezugnahme auf die in 3B gezeigte Anweisung 314 beschrieben und/oder wie in 2C dargestellt.
Der Hardware-Prozessor 302 kann die Anweisung 343 ausführen, wenn bei der Ausführung der Anweisung 340 festgestellt wird, dass die Anzahl der anstehenden Frames höher als oder gleich dem höheren Schwellenwert ist. Die Ausführung des Befehls 343 kann die Verringerung der BSRP-Häufigkeit (oder die Erhöhung des BSRP-Intervalls) beinhalten. Die Ausführung der Anweisung 343 kann beinhalten, dass ein BSRP-Trigger für ein bestimmtes Intervall nicht übertragen wird. Die Verringerung der BSRP-Häufigkeit (oder die Vergrößerung des BSRP-Intervalls) kann die Verringerung der BSRP-Häufigkeit um einen bestimmten Betrag beinhalten (z. B. um einen oder zwei BSRP-Trigger in einem bestimmten Zeitraum). Die BSRP-Häufigkeit kann auf ein Niveau unterhalb eines Standardniveaus verringert werden. Die BSRP-Häufigkeit kann verringert werden, indem das BSPR-Intervall um einen bestimmten Betrag (z. B. um 0,1-200 ms) erhöht wird.
Wie bereits unter Bezugnahme auf 2C erläutert, kann die BSRP-Häufigkeit oder das BSRP-Intervall in Ausführungsformen von einer Trendlinie oder Steigung in einer Zeitreihe anstehender Frames abhängen. Dementsprechend kann der Hardware-Prozessor 302 die Anweisung 355 ausführen, um festzustellen, ob die anstehenden Frames einen unteren Schwellenwert überschreiten. Die Ausführung der Anweisung 355 kann die Feststellung beinhalten, dass die anstehenden Frames den unteren Schwellenwert in Aufwärts- oder Abwärtsrichtung überschreiten.
Wenn bei der Ausführung der Anweisung 355 festgestellt wird, dass die anstehenden Frames den unteren Schwellenwert überschreiten, kann der Hardware-Prozessor die Anweisung 357 ausführen, um die BSRP-Häufigkeit wiederherzustellen (z. B. auf eine frühere Frequenz oder auf eine Standardfrequenz) oder die BSRP-Häufigkeit zu verringern.
Wenn zum Beispiel Pending frames(x,t,t1) ansteigt (d.h. eine positive Steigung aufweist) und den unteren Schwellenwert nach oben überschreitet (d.h. von unter dem unteren Schwellenwert oder am Schwellenwert auf den unteren Schwellenwert oder über den unteren Schwellenwert), könnte der Scheduler entweder die BSRP-Häufigkeit auf einen Standardwert zurücksetzen, die BSRP-Häufigkeit auf einen Wert zurücksetzen, den sie hatte, bevor die anstehenden Bytes am oder unter dem unteren Schwellenwert lagen, oder die BSRP-Häufigkeit verringern.
In ähnlicher Weise kann der Hardware-Prozessor die Anweisung 360 ausführen, um festzustellen, dass die anstehenden Frames den höheren Schwellenwert überschreiten. So kann beispielsweise die Anweisung 260 ausgeführt werden, um festzustellen, dass die anstehenden Frames den höheren Schwellenwert überschreiten, während sie abnehmen (d. h. mit einer negativen Steigung). Der Hardware-Prozessor kann die Anweisung 363 ausführen, wenn bei der Ausführung der Anweisung 360 festgestellt wird, dass die anstehenden Frames den höheren Schwellenwert überschreiten.
Der Hardware-Prozessor 302 kann den Befehl 363 zur Wiederherstellung der BSRP-Häufigkeit oder zur Erhöhung der BSRP-Häufigkeit ausführen. Die BSRP-Häufigkeit kann auf einen Standardwert oder auf einen anderen Wert zurückgesetzt werden, den sie zuvor hatte (z. B. für diesen Fluss bei einem früheren Zeitpunkt in einer Zeitreihe).
In einigen Ausführungsformen kann die Menge des übertragenen Datenverkehrs geringer sein als die berechneten anstehenden Bytes oder geringer als die der STA zugewiesenen Ressourcen. So könnten beispielsweise häufige BSRP-Trigger übertragen werden (d. h. häufiger als ein Standardwert, z. B. wenn die anstehenden Bytes unter einem niedrigeren Schwellenwert liegen), aber die STAs senden möglicherweise nicht genug Datenverkehr. Diese STAs können im Allgemeinen als abnormale STAs bezeichnet werden. Bei diesen abnormalen STAs könnte der STA veraltete Informationen in den BSR geliefert haben (so dass die Berechnung der anstehenden Bytes nicht korrekt ist) und/oder der STA hat sich (z. B. absichtlich) falsch verhalten.
Dementsprechend kann der Hardware-Prozessor, um den Verkehr für diese abnormalen STAs zu behandeln und zu planen, die Anweisung 365 zur Erkennung abnormaler STAs ausführen. Abnormale STAs können erkannt werden, indem festgestellt wird, dass die Anzahl der empfangenen Frames (z. B. seit Empfang der letzten BSR-Informationen) geringer ist als die Anzahl der anstehenden Frames. Abnormale STAs können erkannt werden, indem festgestellt wird, dass die empfangenen Frames (z. B. seit dem Empfang der letzten BSR-Informationen) kleiner sind als die vorherigen anstehenden Frames (d. h. die anstehenden Frames, die vor der Übertragung des vorherigen BSRP-Triggers oder vor dem Empfang der zuletzt empfangenen BSR-Informationen berechnet wurden). Wie bereits erwähnt, können die empfangenen Frames bei der Ausführung der Anweisung 330 bestimmt werden.
Um Daten für abnormale STAs zu planen, kann der Scheduler die Häufigkeit, mit der die abnormale STA geplant wird, oder die Menge der Kanalressourcen, die der STA für die Übertragung zugewiesen werden, mindestens einmal anpassen.
Diese abnormalen STAs können durch Änderung der Häufigkeit, mit der die STAs eingeplant werden, behandelt werden. Diese abnormalen STAs können behandelt werden, indem die abnormalen STAs nicht so häufig für die Datenübertragung eingeplant werden. D.h. die BSRP-Häufigkeit kann gleich bleiben, aber die STA können so eingeplant werden, dass sie Datenframes mit geringerer Frequenz übertragen. Alternativ kann die abnormale STA mit der gleichen Frequenz eingeplant werden, aber sie kann so eingeplant werden, dass sie mit einer minimalen Kanalressource sendet (d. h. mit einer geringeren Kanalressource, als sie sonst für eine nicht-abnormale STA zugewiesen worden wäre).
Es versteht sich, dass, wenn die BSRP-Häufigkeit dynamisch angepasst wird oder wenn ein BSRP dynamisch ausgelöst wird (z. B. bei der Ausführung der Befehle 337, 343, 357, 363, 367), andere Befehle (wie die in 3B gezeigten Befehle 330, 335, 340, 355, 360, 365 oder die in 3A gezeigten Befehle 308 oder 316) anschließend ausgeführt werden können. Dementsprechend kann der Hardware-Prozessor 302 zur Ausführung des Befehls 308 zurückkehren. Es versteht sich auch, dass BSRP-Trigger entsprechend der eingestellten BSRP-Häufigkeit erzeugt, geplant und/oder übertragen werden können.
4 zeigt ein Blockdiagramm eines beispielhaften Computersystems 400, in dem verschiedene der hier beschriebenen Ausführungsformen implementiert werden können. Das Computersystem 400 umfasst einen Bus 402 oder einen anderen Kommunikationsmechanismus zur Übermittlung von Informationen sowie einen oder mehrere Hardware-Prozessoren 404, die zur Verarbeitungvon Informationen mit dem Bus 402 verbunden sind. Bei dem/den Hardware-Prozessor(en) 404 kann es sich zum Beispiel um einen oder mehrere Allzweck-Mikroprozessoren handeln. Das Computersystem 400 kann eine Ausführungsform eines AP-Controllers oder AP oder eines ähnlichen Geräts sein.
Das Computersystem 400 umfasst auch einen Hauptspeicher 406, wie z. B. einen Speicher mit wahlfreiem Zugriff (RAM), einen Cache und/oder andere dynamische Speichervorrichtungen, der mit dem Bus 402 verbunden ist, um Informationen und Anweisungen zu speichern, die vom Prozessor 404 ausgeführt werden sollen. Der Hauptspeicher 406 kann auch zum Speichern temporärer Variablen oder anderer Zwischeninformationen während der Ausführung von Anweisungen verwendet werden, die vom Prozessor 404 ausgeführt werden sollen. Solche Anweisungen, wenn sie in Speichermedien gespeichert sind, auf die der Prozessor 404 zugreifen kann, machen das Computersystem 400 zu einer Spezialmaschine, die so angepasst ist, dass sie die in den Anweisungen angegebenen Operationen ausführt.
Das Computersystem 400 umfasst ferner einen Festwertspeicher (ROM) 408 oder eine andere statische Speichervorrichtung, die mit dem Bus 402 verbunden ist, um statische Informationen und Anweisungen für den Prozessor 404 zu speichern. Eine Speichergerät 410, wie z. B. eine Magnetplatte, eine optische Platte oder ein USB-Stick (Flash-Laufwerk) usw., ist vorgesehen und mit dem Bus 402 verbunden, um Informationen und Anweisungen zu speichern.
Das Computersystem 400 kann ferner mindestens eine Netzwerkschnittstelle 412, wie z. B. einen Netzwerkschnittstellen-Controller (NIC), einen Netzwerkadapter oder Ähnliches oder eine Kombination davon, enthalten, die mit dem Bus 402 verbunden ist, um das Computersystem 400 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 400 kann die hierin 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 bewirkt oder programmiert, dass das Computersystem 400 eine Spezialmaschine ist. Gemäß einer Ausführungsform werden die hierin beschriebenen Techniken vom Computersystem 400 als Reaktion auf den/die Prozessor(en) 404 ausgeführt, der/die eine oder mehrere Sequenzen von einem oder mehreren Befehlen ausführt/ausführen, die im Hauptspeicher 406 enthalten sind. Solche Befehle können aus einem anderen Speichermedium, wie z. B. einem Speichergerät 410, in den Hauptspeicher 406 eingelesen werden. In alternativen Ausführungsformen können festverdrahtete Schaltungen anstelle von oder in Kombination mit Softwarebefehlen 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 z. B. optische oder magnetische Platten, wie z. B. Speichergeräte 410. Zu den flüchtigen Medien gehören dynamische Speicher, wie z. B. Hauptspeicher 406. Zu den gängigen Formen nichtflüchtiger Medien gehören z. B. Disketten, flexible Platten, Festplatten, Solid-State-Laufwerke, Magnetbänder oder andere magnetische Datenspeichermedien, CD-ROMs, andere optische Datenspeichermedien, physische Medien mit Lochmustern, RAMs, PROMs und EPROMs, FLASH-EPROMs, NVRAMs, andere Speicherchips oder -kassetten und vernetzte Versionen derselben.
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-übertragenden Medien beteiligt. Zu den Übertragungsmedien gehören z. B. Koaxialkabel, Kupferdraht und Glasfaserkabel, einschließlich der Drähte, aus denen ein Bus 402 besteht. Übertragungsmedien können auch die Form von Schall- oder Lichtwellen annehmen, wie sie beispielsweise während der Funkwellen- und Infrarot-Datenübertragung 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 Uplink-(UL)-Verkehr zu einer drahtlosen lokalen Netzwerk-(WLAN)-Vorrichtung (106a-c; 200; 300; 400), umfassend: Bestimmen eines Status eines UL-Puffers jeder Station (STA) (110a-j; 210-1; 210-2), wobei der Status des UL-Puffers jeder STA (110a-j; 210-1; 210-2) eine Menge anstehender Daten im UL-Puffer jeder STA (110a-j; 210-1; 210-2) umfasst; und Erzeugen und Übertragen einer Pufferzustandsabfrage (BSRP) durch einen UL-Scheduler der WLAN-Vorrichtung (106a-c; 200; 300; 400) gemäß einer BSRP-Häufigkeit, wobei die BSRP-Häufigkeit auf dem UL-Pufferstatus jeder STA (110a-j; 210-1; 210-2) basiert.
Verfahren nach Anspruch 1, wobei die BSRP-Häufigkeit auf einer Anzahl von anstehenden Frames (257, 258, 253) im UL-Puffer basiert.
Verfahren nach Anspruch 1, wobei das Bestimmen des Status des UL-Puffers jeder STA (110a-j; 210-1; 210-2) Bestimmen einer Priorität des Verkehrs im UL-Puffer jeder STA (110a-j; 210-1; 210-2) umfasst.
Verfahren nach Anspruch 3, wobei das Bestimmen einer Priorität für den UL-Puffer jeder STA (110a-j; 210-1; 210-2) Bestimmen des Verkehrs mit der höchsten Priorität im UL-Puffer jeder STA (110a-j; 210-1; 210-2) umfasst.
Verfahren nach Anspruch 3, wobei die BSRP-Häufigkeit auf dem Vergleich der Menge der anstehenden Daten im UL-Puffer mit einem ersten Schwellenwert basiert.
Verfahren nach Anspruch 5, wobei ein Wert des ersten Schwellenwert auf der Priorität des Verkehrs im UL-Puffer jeder STA (110a-j; 210-1; 210-2) basiert.
Verfahren nach Anspruch 6, wobei die Priorität des Verkehrs im UL-Puffer jeder STA (110a-j; 210-1; 210-2) der höchsten Priorität des Verkehrs im UL-Puffer jeder STA (110a-j; 210-1; 210-2) entspricht.
Verfahren nach Anspruch 6, wobei der Wert des ersten Schwellenwerts eine positive Korrelation mit der Priorität des Verkehrs im UL-Puffer jeder STA (110a-j; 210-1; 210-2) aufweist.
Verfahren nach Anspruch 5, wobei ein Wert für die BSRP-Häufigkeit erhöht wird, wenn die Menge anstehender Daten im UL-Puffer jeder STA (110a-j; 210-1; 210-2) niedriger ist als der Wert des ersten Schwellenwerts.
Verfahren nach Anspruch 9, wobei, wenn bestimmt wird, dass die Menge der Daten im UL-Puffer den ersten Schwellenwert in zunehmender Richtung überschreitet, die BSRP-Häufigkeit auf einen Standardwert zurückgesetzt oder verringert wird.
Verfahren nach Anspruch 5, wobei die BSRP-Häufigkeit auf dem Vergleich der Menge anstehender Daten im UL-Puffer mit einem zweiten Schwellenwert basiert; wobei die BSRP-Häufigkeit verringert wird, wenn die Menge anstehender Daten im UL-Puffer jeder STA (110a-j; 210-1; 210-2) höher ist als ein Wert des zweiten Schwellenwerts.
Verfahren nach Anspruch 11, wobei, wenn bestimmt wird, dass die Menge der Daten im UL-Puffer den zweiten Schwellenwert in abnehmender Richtung überschreitet, die BSRP-Häufigkeit auf einen Standardwert zurückgesetzt oder erhöht wird.
Verfahren nach Anspruch 5, wobei, wenn die Menge anstehender Daten im UL-Puffer jeder STA (110a-j; 210-1; 210-2) niedriger ist als der Wert des ersten Schwellenwerts, sofort ein BSRP erzeugt und übertragen wird.
Verfahren nach Anspruch 1, wobei die Menge anstehender Daten im UL-Puffer jeder STA (110a-j; 210-1; 210-2) bestimmt wird, indem die Menge der von der STA (110a-j; 210-1; 210-2) empfangenen Daten seit dem Empfang einer BSR von der STA von einer gemeldeten Puffergröße subtrahiert wird, wobei die empfangene BSR von der STA (110a-j; 210-1; 210-2) die gemeldete Puffergröße umfasst.
Verfahren nach Anspruch 13, wobei, wenn eine abnormale STA erkannt wird, eine STA-Planungshäufigkeit für die abnormale STA (110a-j; 210-1; 210-2) reduziert wird oder zugewiesene Kanalressourcen für die abnormale STA reduziert werden.
Eine drahtlose lokale Netzwerk-(WLAN)-Vorrichtung (106a-c; 200; 300; 400), die auf einem Kanal im WLAN betrieben wird und Folgendes umfasst: einen Prozessor (202; 302; 404); und einen Speicher (204; 304; 406), der operativ mit dem Prozessor (202; 302; 404) verbunden ist, wobei der Speicher (204; 304; 406) einen Computercode umfasst, der, wenn er ausgeführt wird, den Prozessor (202; 302; 404) dazu veranlasst: Frames, die von einer oder mehreren Stationen (STAs) (110a-j; 210-1; 210-2) empfangen werden, die der WLAN-Vorrichtung (106a-c; 200; 300; 400) zugeordnet sind, zu überwachen; eine Menge anstehender Daten im UL-Puffer jeder STA (110a-j; 210-1; 210-2) basierend auf den überwachten empfangenen Frames zu bestimmen; eine Priorität jedes Verkehrsflusses basierend auf den überwachten empfangenen Frames zu bestimmen; die Menge anstehender Daten im UL-Puffer jeder STA (110a-j; 210-1; 210-2) mit einem jeweiligen ersten Schwellenwert zu vergleichen; wobei ein Wert des jeweiligen ersten Schwellenwerts auf der bestimmten Priorität für jeden Verkehrsfluss basiert; und eine Übertragung einer Pufferzustandsberichtsabfrage (BSRP) gemäß einer BSRP-Häufigkeit zu planen; wobei die BSRP-Häufigkeit auf dem Vergleich basiert.
WLAN-Vorrichtung (106a-c; 200; 300; 400) nach Anspruch 16, wobei der Computercode, der, wenn er ausgeführt wird, den Prozessor (202; 302; 404) veranlasst, die Übertragung des BSRP zu planen, den Prozessor (202; 302; 404) veranlasst, den BSRP für die Übertragung mit einer höheren BSRP-Häufigkeit zu planen, wenn bestimmt wird, dass die Menge der anstehenden Daten im UL-Puffer niedriger als der Wert des ersten Schwellenwerts ist, als wenn bestimmt wird, dass die Menge der anstehenden Daten im UL-Puffer größer als der erste Schwellenwert ist.
WLAN-Vorrichtung (106a-c; 200; 300; 400) nach Anspruch 17, wobei der Computercode, der, wenn er ausgeführt wird, den Prozessor (202; 302; 404) veranlasst, die Menge der anstehenden Daten im UL-Puffer jeder STA (110a-j; 210-1; 210-2) mit einem jeweiligen ersten Schwellenwert zu vergleichen, den Prozessor (202; 302; 404) veranlasst, eine Steigung für die Menge der anstehenden Daten in einer Zeitreihe anstehender Daten zu bestimmen; und der Computercode, der, wenn er ausgeführt wird, den Prozessor (202; 302; 404) veranlasst, die Übertragung des BSRP zu planen, den Prozessor (202; 302; 404) veranlasst, den BSRP für die Übertragung mit einer niedrigeren BSRP-Häufigkeit zu planen, wenn die Menge anstehender Daten am UL-Puffer den ersten Schwellenwert mit einer positiven Steigung überschreitet, als die BSRP-Häufigkeit, wenn die Menge anstehender Daten am UL-Puffer als niedriger als der Wert des ersten Schwellenwertes bestimmt wird.
WLAN-Vorrichtung (106a-c; 200; 300; 400) nach Anspruch 16, wobei der Computercode, der, wenn er ausgeführt wird, den Prozessor (202; 302; 404) veranlasst, die Menge anstehender Daten im UL-Puffer jeder STA (110a-j; 210-1; 210-2) mit einem jeweiligen ersten Schwellenwert zu vergleichen, den Prozessor (202; 302; 404) veranlasst, ferner die Menge anstehender Daten im UL-Puffer jeder STA mit einem jeweiligen zweiten Schwellenwert zu vergleichen; wobei ein Wert des jeweiligen zweiten Schwellenwerts auf der bestimmten Priorität für jeden Verkehrsfluss basiert; und der Computercode, der, wenn er ausgeführt wird, den Prozessor (202; 302; 404) veranlasst, die Übertragung des BSRP zu planen, den Prozessor (202; 302; 404) veranlasst, den BSRP für die Übertragung mit einer niedrigeren BSRP-Häufigkeit zu planen, wenn bestimmt wird, dass die Menge der anstehenden Daten höher als der zweite Schwellenwert ist, als die BSRP-Häufigkeit, wenn bestimmt wird, dass die Menge der anstehenden Daten im UL-Puffer niedriger als der Wert des zweiten Schwellenwerts ist.
WLAN-Vorrichtung (106a-c; 200; 300; 400) nach Anspruch 19, wobei der Computercode, der, wenn er ausgeführt wird, den Prozessor (202; 302; 404) veranlasst, die Menge der anstehenden Daten im UL-Puffer jeder STA (110a-j; 210-1; 210-2) mit einem jeweiligen ersten Schwellenwert zu vergleichen, den Prozessor (202; 302; 404) veranlasst, eine Steigung für die Menge der anstehenden Daten in einer Zeitreihe anstehender Daten zu bestimmen; und der Computercode, der, wenn er ausgeführt wird, den Prozessor (202; 302; 404) veranlasst, die Übertragung des BSRP zu planen, den Prozessor (202; 302; 404) veranlasst, den BSRP für die Übertragung mit einer höheren BSRP-Häufigkeit zu planen, wenn die Menge der anstehenden Daten im UL-Puffer den ersten Schwellenwert mit einer negativen Steigung überschreitet, als die BSRP-Häufigkeit, wenn die Menge der anstehenden Daten im UL-Puffer als höher als der Wert des zweiten Schwellenwerts bestimmt wird.