DE602004013293T2

DE602004013293T2 - Priorisierung des zugangs durch einem zugangspunkt und implementierung einer einfachen 802.11e hcf (hybrid coordination function)

Info

Publication number: DE602004013293T2
Application number: DE602004013293T
Authority: DE
Inventors: Robert Cuyahoga Falls MEIER
Original assignee: Cisco Technology Inc
Current assignee: Cisco Technology Inc
Priority date: 2003-03-21
Filing date: 2004-03-18
Publication date: 2009-07-16
Anticipated expiration: 2024-03-19
Also published as: EP1606908A2; WO2004086689A2; CN1784867B; US20100265907A1; WO2004086689A3; EP1971079B1; EP1971079A3; CA2519648A1; CN1784867A; ATE393515T1; EP1606908B1; AU2004223363B2; EP1971079A2; DE602004013293D1; US20040184475A1; US8270381B2; AU2004223363A1; CA2519648C; US7801092B2

Description

HINTERGRUND DER ERFINDUNG
Die vorliegende Erfindung betrifft allgemein eine Dienstgüte (QoS; Quality of Service) für ein drahtloses Netzwerk und insbesondere eine vereinfachte Implementierung einer Hybridkoordinierungsfunktion (Hybrid Coordination Function) für ein 802.11 Netzwerk.
Falls hier keine anderweitige Definition erfolgt, sollen die Begriffe in dieser Patentschrift so interpretiert werden, wie sie in den 802.11- und 802.11e-Spezifikationen des Institute of Electrical and Electronics Engineers (IEEE) definiert sind oder üblicherweise verwendet werden. Der aktuelle Entwurfsstandard bezieht sich auf die aktuelle Entwurfsergänzung für die 802.11e-Spezifikation.
Der aktuelle 802.11e-Entwurfsstandard für QoS definiert zwei Zugriffsverfahren – ein auf Carrier Sense Multiple Access (CSMA) (Mehrfachzugriff mit Übertragungsprüfung) basierendes Zugriffsverfahren, das EDCF (Enhanced Distributed Coordination Function/verbesserte verteilte Koordinierungsfunktion) genannt wird, und ein Hybridzugriffsverfahren, das Hybrid Coordination Function (HCF) genannt wird. In dem HCF-Zugriffsverfahren sendet ein Hybridkoordinator (HC; Hybrid Coordinator) eine zyklische Abfrage (Poll) zu einer Client-Station (Station), um der Station eine gepollte Übertragungsgelegenheit bzw. Übertragungsmöglichkeit (TXOP; Transmission Opportunity) zu gewähren.
Man ist sich allgemein darüber einig, dass EDCF für eine QoS für eine interaktive Sprache in einer Unternehmensumgebung mit "versteckten" Stationen nicht ausreichend ist. Aber die HCF, wie sie ursprünglich in dem 802.11e-Entwurf definiert wurde, erfordert eine sehr komplexe AP-Implementierung. Deshalb wollen die meisten Anbieter von APs (einschließlich Cisco) diese nicht unterstützen, zumindest nicht in einer anfänglichen 802.11e-konformen Freigabe. Somit existiert ein Bedarf an einer AP-HCF-Implementierung, die in hohem Grade vereinfacht und viel "Client-freundlicher" ist.
Zusätzlich zu dem oben erwähnten Bedarf ist der Fehlerkorrekturmechanismus, der im Augenblick in dem 802.11e-Entwurf spezifiziert ist, für den HCF-gepollten Zugriff kompliziert und unbestimmt. Wenn dem HC eine erwartete Antwort auf eine Abfrage fehlt, dann initiieren sowohl der HC als auch die Station die Fehlerkorrektur. In einigen Fällen kann der 802.11e-Fehlerkorrekturmechanismus zu mehrfachen Kollisionen führen. Infolgedessen besteht ein Bedarf an einem einfachen Verfahren zur Handhabung der Polling-Fehlerkorrektur.
Zusätzlich zu den oben erwähnten Bedürfnissen beschreibt der aktuelle 802.11e-Entwurf zwei völlig verschiedene QoS-Energiesparverfahren. In einem "Automatic Power-Save Delivery"-Verfahren (APSD) (automatische stromsparende Lieferung) erstellen Stationen "Wecksignale" (Wakeup Beacons), und der AP liefert zwischengespeicherte Downlink-Frames sofort im Anschluss an die Wecksignale. Ein AP zeigt an, dass er Frames aufweist, die für eine Station zwischengespeichert sind, indem er das Stations Bit (Stationsbit) in dem TIM in Signalen (Beacons) und Probe-Antwort-Frames setzt. In einem HCF-"Dienstperioden"-Verfahren werden Dienstperioden für eine Station durch eine minimale Zwischendienstperiode getrennt. Der AP kann zu einer Energiesparstation nur an dem Beginn einer Dienstperiode der Station senden, so dass die Station zwischen Dienstperioden "schlafen" kann. Das Dienstperiodenverfahren weist einen bekannten Mangel auf, da Dienstperioden-Startzeiten in dem AP und der Station außer Synchronisation geraten können.
Das APSD-Verfahren ist viel einfacher als das HCF-"Dienstperioden"-Energiespar-Verfahren, das in dem aktuellen 802.11e-Entwurf beschrieben ist. APSD weist auch den Vorteil auf, dass es anders als das Dienstperiodenverfahren mit EDCF oder HCF gleich arbeitet.
Aber das APSD-Verfahren in dem aktuellen 802.11e-Entwurf weist im Vergleich zu dem "Dienstperioden"-Verfahren einige Nachteile auf: a) APSD benötigt eine schnelle Signalrate, um VoIP-Stationen zu unterstützen; b) APSD gruppiert Energiesparverkehr um Signalübertragungen (beacon transmissions) herum; und c) APSD erfordert es, dass Stationen wach bleiben, um Energiesparverkehr von anderen Stationen zu empfangen. Infolgedessen besteht der Bedarf an einem einzelnen, passenden, einfachen Energiesparverfahren für VoIP-Stationen, das keine schnelle Signalrate benötigt, das Energiesparübertragungen nicht um Signalübertragungen herum gruppiert und das es nicht erfor dert, dass Stationen wach bleiben, um Energiesparverkehr von anderen Stationen zu empfangen.
Das Dokument mit dem Titel "IEEE 802.11e wireless LAN for quality of service" von Mangold et al. stellt einen umfassenden Überblick über den IEEE 802.11e Standard bereit, um die Dienstgüte in drahtlosen lokalen Netzwerken zu unterstützen. Dieses Dokument beschreibt das oben beschriebene System noch ausführlicher.
KURZE ZUSAMMENFASSUNG DER ERFINDUNG
Gemäß einer Ausführungsform stellt die vorliegende Erfindung ein Verfahren zum Steuern von Kanalzugriff durch einen 802.11 Zugriffspunkt bereit, wobei das Verfahren gekennzeichnet ist durch: Erzeugen einer Hybrid Coordination Function-, HCF-Schlange mit strenger Priorität, wobei die HCF-Schlange mit strenger Priorität verwendet wird, um wenigstens eine einer Contention Free-(wettbewerbsfreien), CF-Poll- und einer Downlink-Daten-Übertragung in die Schlange einzureihen; Einfügen wenigstens einer von einer CF-Poll- und einer Downlink-Daten-Übertragung in die HCF-Schlange mit strenger Priorität; und Bedienen der HCF-Schlange mit strenger Priorität vor dem Bedienen einer Enhanced Distributed Coordination Function-, EDCF-Übertragungsschlange. Andere Ausführungsformen der Erfindung ziehen ein computerlesbares Medium von Befehlen zum Durchführen jedes Verfahrens und einen Zugriffspunkt, der betätigbar ist, um jedes der oben erwähnten Verfahren durchzuführen, in Betracht. Typischerweise ist die Schlange (Warteschlange) mit strenger Priorität eine First-In-First-Out-Schlange. Eine große festgelegte Größe kann allen Übertragungsmöglichkeiten zugeordnet werden. Außerdem kann der Schritt des Erzeugens mehrere Schlangen mit strenger Priorität erzeugen, wobei jede Schlange auf eine spezifische Verkehrsklasse abgebildet wird. Die Verkehrsklasse ist wenigstens eine ausgewählt aus der Gruppe bestehend aus einer Sprachmanagement-Schlange und einer Netzwerkmanagement-Schlange. Wenigstens eine Übertragungsschlange mit strenger Priorität wird nur für Frames verwendet, die der Zugangskontrolle unterliegen, wobei der Satz zugelassener Frames, die der Zugangskontrolle unterliegen, in dem Zugriffspunkt über QoS-Klassifizierungsparameter bestimmt wird.
In einer anderen Ausführungsform des oben genannten Verfahrens zieht das Verfahren das Binden eines Ausgangs-Dienstgüte-Klassifizierers durch den Zugriffspunkt an eine Ziel-MAC-Adresse einer 802.11-Station mit einem zugelassenen Verkehrsstrom und das Identifizieren von Downlink-Frames für den zugelassenen Verkehrsstrom durch den Zugriffspunkt in Betracht. Der Ausgangs-Dienstgüte-Klassifizierer umfasst wenigstens einen aus der Gruppe bestehend aus einem Internetprotokolladresse-, einem Internetprotokolltyp- und einem UDP-/TCP-Protokoll-Port-Identifizierer, die einen Anwendungsverkehrsstrom eindeutig identifizieren. Die Parameter für den Ausgangs-Dienstgüte-Klassifizierer werden durch ein Dienstgüte-Signalisierungsprotokoll erhalten, oder die Parameter werden automatisch durch den Zugriffspunkt abgeleitet, indem die Datenpakete beschnüffelt (snooping) werden. Eine Verkehrsklasse für einen Verkehrsstrom kann durch ein Dienstgüte-Signalisierungsprotokoll bestimmt werden. Ein übertragener Frame wird der Schlange mit strenger Priorität für die Verkehrsklasse zugewiesen, wenn Felder in dem Frame mit den entsprechenden Werten in dem QoS-Klassifizierer für die Ziel-MAC-Adresse übereinstimmen. Es sei angemerkt, dass es nur notwendig ist, einen solchen Ausgangs-Dienstgüte-Klassifizierer an diejenigen übertragenen Frames anzulegen, bei denen die Ziel-MAC-Adresse mit der Adresse übereinstimmt, an die der Klassifizierer gebunden ist.
Eine weitere Ausführungsform des oben genannten Verfahrens zieht es in Betracht, dass das Verfahren des Weiteren das Erstellen eines periodischen Abfrageplans (polling schedule) für eine Station und das Platzieren einer Poll bzw. Abfrage in einer Übertragungsschlange mit strenger Priorität zu jeder geplanten Abfragezeit umfasst.
In noch einer anderen Ausführungsform des oben genannten Verfahrens erstellt das Verfahren einen Weckplan für eine Energiesparstation, wobei der Weckplan mit dem Abfrageplan der Energiestation übereinstimmt und aktive, für die Station zwischengespeicherte Frames an eine aktive Übertragungsschlange nach einer geplanten Weckzeit überträgt und der Energiesparstation anzeigt, wenn eine Datenübertragung abgeschlossen ist. Das Verfahren kann des Weiteren das Senden eines Poll-Frames an die Energiesparstation nach einer geplanten Weckzeit umfassen, wobei der Poll-Frame ein Feld aufweist, um die Energiesparstation zu informieren, wenn zwischengespeicherte Frames auf die Übertragung warten, oder der Zugriffspunkt kann einen Datenframe an die Energiesparstation mit einem Feld senden, das anzeigt, wenn mehr Frames in der Schlange vorhanden sind. Abfragezeiten werden festgesetzt, um wenigstens eines von Latenzzeit und Wettbewerb zu minimieren. Abfragezeiten können unterschiedlich von Signalübertragungen festgesetzt werden. Abfragezeiten werden so festgesetzt, dass eine Zeitdauer minimiert wird, während der die Station wach sein muß.
Noch eine weitere Ausführungsform des Verfahrens ist das Synchronisieren des Abfrageplans mit einer Standard 802.11 Timersynchronisierungsfunktion (TSF). Der Abfrageplan umfasst eine Startzeit und eine Zwischenabfrageperiode, wobei die Startzeit ein TSF-Timerwert ist und die Zwischenabfrageperiode ein ganzzahliges Vielfaches (mehrfaches Integral) von TSF-Zeiteinheiten ist. Der Weckplan für die Energiesparstation wird auf einen Standard 802.11 Timersynchronisierungsfunktions-Timer synchronisiert. In ähnlicher Weise kann ein Dienstplan durch eine Startzeit und eine Zwischendienstperiode definiert werden, wobei die Startzeit ein TSF-Timerwert ist und die Zwischendienstperiode ein ganzzahliges Vielfaches von TSF-Zeiteinheiten ist.
Eine andere Ausführungsform des oben erwähnten Verfahrens umfasst das Erstellen eines Dienstplans basierend auf einem Timer-Rad (Timer Wheel), wobei das Timer-Rad Takt-Ticks (auch Taktzyklen genannt; hier auch Taktticken) (clock ticks) aufweist, die ein Integral einer TSF-Zeiteinheit sind, wobei jedes Taktticken bzw. jeder Takt-Tick einen Eimer (Bucket) aufweist, wobei der Eimer eine verbundene Liste mit einem Eintrag für jede Station aufweist, die zu dem entsprechenden Taktticken zu bedienen ist, wobei eine Station wie folgt bedient wird: Jegliche Energiespar-Datenframes werden zu den aktiven Übertragungsschlangen übertragen und eine Abfrage wird an dem hinteren Ende einer Übertragungsschlange mit strenger Priorität eingereiht, wenn die Station für das Abfragen festgesetzt ist. Ein solcher Scheduler ist wesentlich anders als der Referenz-Scheduler, der in dem 802.11e-Entwurf beschrieben ist, bei dem Abfragen zu festgesetzten Zeiten übertragen werden anstatt dass diese einfach für die Übertragung in eine FIFO-Schlange eingereiht werden.
Noch eine weitere Ausführungsform des oben genannten Verfahrens umfasst das Senden einer in der Übertragungsschlange eingereihten Downlink- Datenübertragung, wobei die Downlink-Datenübertragung einen kombinierten zwischengespeicherten Frame und eine "huckepack genommene" Abfrage aufweist. Noch eine andere Ausführungsform des oben genannten Verfahrens zieht in Betracht, dass die Schlange mit strenger Priorität nur für Daten- und Poll-Frames für einen zugelassenen interaktiven Sprachstrom- und Netzwerkmanangement-Verkehr verwendet wird.
Noch weitere Gegenstände der vorliegenden Erfindung werden den Fachleuten auf diesem Gebiet ohne weiteres aus der nachfolgenden Beschreibung ersichtlich, in der ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung lediglich beispielshalber durch eine Veranschaulichung von einem der besten Modi gezeigt und beschrieben wird, die am besten für das Ausführen der Erfindung geeignet sind. Wie realisiert werden wird, ist die Erfindung zu anderen unterschiedlichen Ausführungsbeispielen in der Lage und ihre unterschiedlichen Einzelheiten sind zu Modifikationen in verschiedenen offensichtlichen Ausführungsformen in der Lage, ohne dass dabei von der Erfindung, wie sie in den angehängten Ansprüchen definiert ist, abgewichen wird. Folglich werden die Zeichnung und Beschreibungen als von veranschaulichender Natur und nicht als beschränkend betrachtet werden.
KURZE BESCHREIBUNG DER MEHREREN ANSICHTEN DER ZEICHNUNG
Die beigefügten Zeichnungen, die in die Patentschrift eingegliedert sind und einen Teil davon bilden, veranschaulichen mehrere Ausführungsformen der vorliegenden Erfindung, und zusammen mit der Beschreibung dienen sie dazu, die Prinzipien der Erfindung zu erläutern, wobei in den Zeichnungen:
1 ein Beispiel für einen Austausch zwischen einem Zugriffspunkt (AP) und einer drahtlosen Nicht-802.11e-Station für ein freilaufendes CTS-Signal ist;
2 ein Beispiel für einen Austausch zwischen einem Zugriffspunkt und einer 802.11e-Station ist, wenn der Zugriffspunkt eine 802.11e-Abfrage sendet;
3 ein Beispiel für einen Austausch zwischen einem Zugriffspunkt und einer drahtlosen 802.11e-Station ist, wenn der Zugriffspunkt eine huckepack genommene 802.11e-Abfrage sendet; und
4 ein Beispiel für einen Austausch zwischen einem Zugriffspunkt und einer drahtlosen 802.11e-Station ist, wenn der Zugriffspunkt eine huckepack genommene 802.11e-Abfrage sendet und die drahtlose Station keine Daten für den Zugriffspunkt besitzt;
5 eine beispielhafte Frame-Austauschsequenz für eine drahtlose Energiesparstation ist;
6 eine beispielhafte Frame-Austauschsequenz zeigt, in der ein AP eine Abfrage bei jeder geplanten Weckperiode für eine drahtlose Energiesparstation erzeugt;
7 eine beispielhafte Frame-Austauschsequenz zeigt, in der eine drahtlose Station einen NULL-Frame erzeugt, um einen AP nach zwischengespeicherten Energiespar-Frames abzufragen bzw. zu Pollen,
8 eine beispielhafte Frame-Austauschsequenz ist, die zeigt, wie Downlink- und Uplink-Datenübertragungen ineinander verschachtelt werden können;
9 ein Blockdiagramm eines beispielhaften Prozessablaufs für ein Zugangskontrollverfahren ist; und
10 ein Blockdiagramm eines Timer-Rads ist.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Durch die vorliegende gesamte Beschreibung hindurch sollen das gezeigte bevorzugte Ausführungsbeispiel und die gezeigten bevorzugten Beispiele als Musterbeispiele für die vorliegende Erfindung und nicht als Beschränkungen davon betrachtet werden.
Der aktuelle 802.11e Entwurfsstandard für QoS definiert zwei Zugriffsverfahren- ein CSMA-basiertes Zugriffsverfahren, das EDCF genannt wird, und ein Hybridzugriffsverfahren, das die Hybrid Coordination Function genannt wird. In dem HCF-Zugriffsverfahren sendet ein Hybridkoordinator (HC) eine Abfrage zu einer Client-Station, um der Station eine gepollte Übertragungsgelegenheit (TXOP; Transmission Opportunity) zu gewähren.
Man ist sich allgemein darüber einig, dass die EDCF für die QoS für interaktive Sprache in einer Unternehmensumgebung mit "versteckten" Stationen nicht ausreichend ist. Aber die HCF, wie sie ursprünglich in dem 802.11e Ent wurf definiert ist, erfordert eine sehr komplexe AP-Implementierung. Deshalb wollen die meisten AP-Anbieter (einschließlich Cisco) diese nicht unterstützen, wenigstens nicht in einer anfänglichen 802.11e-konformen Freigabe. Das vorliegende Dokument schlägt eine AP HCF Implementierung vor, die in hohem Grad vereinfacht und viel "Client-freundlicher" ist.
Die einfache AP HCF Implementierung der vorliegenden Erfindung, die unten beschrieben wird, ist eine Alternative zu einer komplexeren HCF-Implementierung, in der:

1) Ein komplexer HCF-Scheduler in dem AP Abfrageübertragungen (d. h., CF-Poll-Frames) in festgelegten Zeitschlitzen erzeugt.
2) Jede CF-Poll eine kleine TXOP-Größe zuordnet, die größenmäßig so bemessen ist, dass sie gerade eine "Uplink"-Übertragung von einer Client-Station unterbringt.
3) Eine Station "Schlangengrößen"-Informationen zu dem HC kommuniziert, so dass der HC konstant die TXOP-Größe so anpassen kann, dass die Uplink-Übertragungen der Station untergebracht werden.
4) Der AP zwei unterschiedliche Energiesparmechanismen unterstützen muß.

Die Komponenten der einfachen AP-Implementierung werden unten zusammengefasst. Eine ausführliche Beschreibung der AP-Implementierung folgt. Die Komponenten der einfachen AP-Implementierung umfassen:

1) Einen sehr einfachen AP HCF Übertragungs-Scheduler. Abfragen werden nicht in festgelegten Zeitschlitzen übertragen; statt dessen werden Abfragen in einer HCF FIFO-Übertragungsschlange mit strenger Priorität eingereiht.
2) Der HC gewährt immer große gepollte TXOPs mit einer festgelegten Größe. Der HC muß niemals TXOP-Größen oder Timer-Perioden neu berechnen.
3) Eine einfache "Token Bucket"-Überwachung wird als eine Alternative zu "kleinen TXOPs" verwendet. Die Überwachung (Policing) findet bei der Anwendungsdatenübertragungsrate statt, so dass die Anwendung von dem 802.11 Rate-Shifting (Übertragungsratenverschiebung) und den wiederholten Übertragungen (retransmissions) isoliert ist.
4) Die Station ist im Allgemeinen verantwortlich für die Fehlerkorrektur, wenn der HC keine erwartete Antwort auf eine Abfrage erhalten hat; deshalb ist eine Abfrage eher wie ein "freilaufendes CTS". Eine Fehlerkorrektur in einer gepollten TXOP erfordert eine weitere Definition in dem 802.11e Entwurf; aber eine andere Ausführungsform der vorliegenden Erfindung ist auf ein einfaches Polling-Fehlerkorrekturverfahren ausgerichtet.
5) Ein Mechanismus für die Zurückgewinnung des unbenutzten Abschnitts einer großen TXOP ist bereitgestellt.
6) Der HCF Scheduler unterstützt einen einzigen, vereinheitlichten Energiesparmechanismus, bei dem die geplanten Weckzeiten mit geplanten Abfragezeiten übereinstimmen können und geplante Weckzeiten mit Signalübertragungen übereinstimmen bzw. zusammenfallen können oder nicht.
7) Der HCF Kanalzugriff steht in Einklang mit dem EDCF Kanalzugriff. "HCF" kann als die höchste EDCF-Priorität betrachtet werden.

Eine ausführliche Erläuterung der AP HCF Implementierung, die von der vorliegenden Erfindung in Betracht gezogen wird, wird nun gegeben.
Die existierenden (E)DCF-Übertragungsschlangen des AP werden um eine oder mehrere HCF-Übertragungsschlangen mit strenger Priorität vergrößert. Die HCF-Schlangen werden nur benutzt, um Downlink-Daten- und CF-Poll-Übertragungen für "zugelassene" Downlink- und Uplink-Flüsse zu planen. Der 802.1D Benutzerprioritätswert wird verwendet, um die HCF-Schlange für einen zugelassenen Fluss auszuwählen. Zugelassene Downlink- und Uplink-Flüsse werden typischerweise zwischen dem AP und einer Station ausgehandelt, wenn ein neuer Verkehrsfluss initiiert wird und wenn sich die Station mit einem neuen AP verbindet. Die TCLAS- und TSPEC-Felder, die in dem aktuellen 880.11e Entwurf spezifiziert sind, können verwendet werden, um die Flüsse zu identifizieren.
Standardmäßig wird ein HCF-Zugriff nur für zugelassene interaktive Sprachflüsse verwendet (d. h., der HC akzeptiert nur TSPECs für eine Benutzerpriorität 6), und EDCF wird für den anderen QoS-Verkehr verwendet. Aber der Benutzer kann den HCF-Zugriff für andere Benutzerprioritäten aktivieren.
Eie QoS Policy liegt nicht in dem Bereich der 802.11e, außer dass es einem AP-Anbieter möglich sein sollte, den Satz von zugelassenen HCF-Benutzerprioritäten für eine Client-Station bestimmen zu können. Es sollte angemerkt werden, dass der verteilte First-Come-First-Serve (Abfragegerechtigkeits)-"Zugangskontroll"-Mechanismus des 802.11e die Policy-bezogene QoS-Differenzierung nicht unterstützt.
Die HCF-Übertragungsschlangen mit strenger Priorität werden in der Prioritätsordnung immer zuerst bedient, also vor anderen (E)DCF-Übertragungsschlangen. Der Kanal wird im Hinblick auf EDCF als "belegt" betrachtet, während eine Schlange mit strenger Priorität bedient wird. Die "Zugangskontrolle", von der ein Verfahren hier weiter unten beschrieben werden wird, hindert den Verkehr mit strenger Priorität daran, priorisierten (E)DCF-Verkehr verhungern zu lassen.
Die vorliegende Erfindung zieht in Betracht, dass ein Dienst-Timer in dem AP für jeden zugelassenen Fluss (oder zusammengefasste Flüsse, wenn eine Station mehr als einen Fluss aufweist) gestartet wird. Die Zeitdauer des Timers wird von dem AP basierend auf Parametern erstellt, die von der Station signalisiert werden. Eine CF-Poll-Übertragung wird in der Schlange mit strenger Priorität eingereiht, wenn der Dienst-Timer abläuft. Als eine Optimierung kann ein AP einen einzigen Timer für mehrere Stationen mit ähnlichen Dienstperioden verwenden.
Eine (+)CF-Poll ordnet eine "gepollte TXOP" in der Wettbewerbsperiode zu. Die Station ist im Allgemeinen verantwortlich für die Fehlerkorrektur, wenn eine Abfrage oder die Antwort auf eine Abfrage verloren geht. In der einfachen Implementierung des bevorzugten Ausführungsbeispiels wird eine HCF-Abfrage tatsächlich mehr wie eine "freilaufende CTS" behandelt. Deshalb ist das HCF-Polling viel einfacher als das Legacy-PCF-Polling.
Als eine Option kann der HC Abfragen wiederholen, wenn eine Station auf eine Abfrage nicht innerhalb einer PIFS-Zeit antwortet – aber Rücken-an-Rücken-Abfragen sollten nicht wiederholt zu der gleichen Station gesendet werden. Die räumliche Wiederverwendung kann gesteigert werden, wenn Ab fragen in einer gewissen Round-Robin-Reihenfolge erneut versucht werden. In einer einfachen Implementierung kann eine nicht erfolgreiche CF-Poll erneut in eine HCF-Wiederholungsschlange eingereiht werden, wenn ein erwarteter Uplink-Frame nicht empfangen wird.
Als eine Option kann eine Station einen EDCF-Kanalzugriff verwenden, um einen Uplink Frame nach einer gewissen Backoff-Periode zu senden, nach der eine erwartete Abfrage nicht empfangen worden ist; deshalb muß der HC Abfragen nicht wiederholen.
Die Fehlerkorrektur kann, falls eine Abfrage oder die Antwort auf die Abfrage verloren gegangen ist, stark vereinfacht und robuster werden, wenn eine Station exakt einen Frame in Reaktion auf eine Abfrage senden kann. [In dem aktuellen Entwurf können sowohl der AP als auch die Station eine Fehlerkorrektur initiieren, wenn die Antwort auf eine Abfrage verloren geht, was zu mehrfachen Kollisionen führt.]
Wettbewerbsfreie Perioden (CFPs; Contention-free Periods) werden für CF-Poll-Übertragungen nicht verwendet. Aber eine CFP kann (optional) verwendet werden, um Energiespar-Multicast-Frames im Anschluss an eine DTIM-Signalübertragung zu übertragen.
Eine Ausführungsform der vorliegenden Erfindung ist, dass eine CF-Poll immer eine konstante, große TXOP (z. B. die maximale TXOP-Größe für die Zugriffsklasse) zuordnet. Dann braucht der HC niemals TXOP-Größen (oder Dienst-Timer-Perioden) neu zu berechnen. Eine Station kann immer mit dem Frame an der Spitze der Schlange antworten, und die Station kann optional in der TXOP erneut übertragen, wenn ein Uplink Frame nicht bestätigt wird. Der AP muß "Schlangengrößen"-Informationen in Uplink Frames nicht verarbeiten.
Jeder unbenutzte Abschnitt einer (d. h., großen) gepollten TXOP wird wie folgt zurückgewonnen: a) Die Station gibt den Kanal explizit dem HC zurück, indem sie den letzten Frame in der TXOP anzeigt, oder b) der HC kann den Kanal zurückfordern, wenn nach einer PIFS-Zeit nach einer Abfrageübertragung CCA immer noch aktiviert ist (d. h., wenn die Station nicht antwortet). Der HC kann den zurückgewonnenen Abschnitt der TXOP verwenden oder er kann einen Frame senden, der die Kanalreservierung in anderen Stationen reduziert (d. h., der die NAV zurücksetzt).
Frames für zugelassene Downlink-parameterisierte Flüsse werden ebenfalls in eine HCF-Schlange mit strenger Priorität eingereiht (wobei eine Energiesparlogik ignoriert wird). Der AP verwendet einen 802.11 Ausgangs-QoS-Klassifizierer, der an die Ziel-MAC-Adresse gebunden ist, um solche Downlink Frames zu klassifizieren. Die Klassifiziererparameter werden aus dem TCLAS-Element erhalten, das von der Station für den Downlink-Fluss gesendet wurde, oder werden automatisch durch das "Beschnüffeln" (Snooping) von Paketen abgeleitet. Der Klassifizierer weist die Schlange (d. h., die HCF-Schlange mit strenger Priorität), die Priorität und (optional) die maximale Verzögerung für den jeweiligen Frame zu. Der AP muß die Ziel-MAC-Adresse für alle QoS- und Nicht-QOS-Downlink-Übertragungen nachschlagen. Deshalb ist der einzige QoS-Klassifikations-Overhead für den anderen, nicht zugelassenen Downlink-Verkehr die Überprüfung eines NULL-Klassifizierer-Zeigers.
Als eine Optimierung kann ein HC eine in der Schlange vorhandene Downlink-Übertragung und eine in der Schlange vorhandene CF-Poll für die gleiche Station kombinieren, so dass eine Abfrage auf einer Downlink-Übertragung huckepack genommen wird. Es sei angemerkt, dass es keinen zusätzlichen Overhead für das Huckepacknehmen einer Abfrage auf jeder Downlink-Übertragung gibt, da eine Station, die keine Daten zum Senden aufweist, einfach mit einer QoS Ack antworten kann, bei der die "Schlangengröße" auf '0' gesetzt ist.
Uplink- und Downlink-Flüsse werden bei der Anwendungsdatenübertragungsrate "kontrolliert", so dass die Anwendung nicht für erneute Übertragungen und Rate-Shifting bestraft wird. Das Policing (das Kontrollieren, die Überwachung) wird als eine Alternative zu der Zuordnung von kleinen TXOPs verwendet, die gerade die zugelassene Datenübertragungsrate unterstützen. Das Zuordnen von kleinen gepollten TXOPs kontrolliert effektiv die Station bei der PHY-Rate. Das Policing bei der Anwendungsdatenübertragungsrate ist viel benutzerfreundlicher. Der HC verwendet einen "Token Gucket" (Token-Eimer), um zugelassene Uplink- und Downlink-Flüsse zu kontrollieren. Der Token Bucket bzw. Token-Eimer wird mit einer voreingestellten Anzahl von Tokens (Sendeberechtigungsmarken) initialisiert, und Tokens werden dem Eimer bei der mittleren Datenübertragungsrate (plus einem gewissen Mogelfaktor) jedes mal dann hinzugefügt, wenn der Dienst-Timer abläuft. Wenn der Station die Tokens ausgehen, dann werden die Downlink-Übertragungen oder das Polling unterbrochen.
Die Station kann wählen, ob sie in einem aktiven Modus oder in einem Energiesparmodus arbeiten will. Wenn die Station in dem Energiesparmodus arbeitet, dann werden CF-Poll- und Downlink-Daten-Übertragungen für einen zugelassenen HCF-Fluss in der Energiesparschlange der Station eingereiht, bis die Station wach ist. In dem Energiesparmodus muß die Station ein Signalisierungsprotokoll verwenden, um geplante "Weckzeiten" zu erstellen, wobei die geplanten Weckzeiten mit Signalübertragungen zusammenfallen können oder auch nicht. Frames werden bei jeder geplanten Weckzeit automatisch von der Energiesparschlange zu den aktiven Übertragungsschlangen transferiert.
APSD ist einfacher als das HCF-basierte "Dienstperioden"-Energiesparverfahren, das in dem aktuellen 802.11e Entwurf definiert ist; aber das aktuelle APSD-Verfahren weist im Vergleich zu dem Dienstperiodenverfahren mehrere Nachteile auf. Eine weitere Ausführungsform der vorliegenden Erfindung zieht ein einfaches Energiesparverfahren für VoIP-Stationen in Betracht (das hier weiter unten noch beschrieben werden wird), das ein "verbessertes APSD"-Verfahren beschreibt, das diese Nachteile angeht.
Die Zugangskontrolle basiert auf einem gewissen konfigurierbaren Prozentsatz der erwarteten gesamten effektiven Bandbreite. Wenn sich Kanalbedingungen verschlechtern, wird der Prozentsatz an Bandbreite, der für den HCF-Verkehr (z. B. Sprache) verwendet wird, ansteigen, und der Prozentsatz an Bandbreite, der für (E)DCF-Verkehr verwendet wird, wird kleiner werden. Aber der AP wird weiterhin zugelassene Flüsse unterstützen, wenn der konfigurierte Prozentsatz an Bandbreite nicht zu hoch ist.
Eine weitere Ausführungsform der vorliegenden Erfindung ist eine einfache Stations-HCF-Implementierung. Diese Ausführungsform vermeidet die Probleme, die auftreten, wenn der HC kleine gepollte TXOPs zuordnet. Wenn der HC kleine gepollte TXOPs zuordnet, dann muß die Station zuerst einmal bestimmen, ob ein Frame in eine gepollte TXOP passt, bevor sie antwortet. Wenn der Frame nicht passt, dann muß die Station einen QoS-Null-Frame mit Schlangengrößeninformationen senden – und zwar alles innerhalb einer SIFS-Zeit. Der AP verarbeitet die Schlangengrößeninformationen und sendet vermutlich eine Abfrage mit einer größeren TXOP zurück. Aber mit der einfachen Stations-HCF-Implementierung kann eine Station eine einzelne HCF-Schlange mit höchster Priorität implementieren, die für gepollte Uplink-Übertragungen verwendet wird. Eine Station kann eine "Minimum-TXOP-Größe" in einer TSPEC-Hinzufüge-Anforderung spezifizieren; deshalb kann eine Station so implementiert werden, dass sie immer auf eine Abfrage antwortet, indem sie einen Datenframe an der Spitze der HCF-Schlange (oder einen anderen Frame, möglicherweise einen Null-Frame, wenn die Schlange leer ist) überträgt.
Eine weitere Ausführungsform der vorliegenden Erfindung ist für eine einfache HCF VoIP Implementierung gedacht. Diese Ausführungsform ist für eine HCF- oder HCF-ähnliche VoIP-Implementierung, die keine Polling-Timer in einem AP benötigt. Im Allgemeinen steuern AP-Downlink-Übertragungen effektiv Uplink-Stations-Übertragungen an. Eine Station kann anzeigen, dass sie Uplink-Daten für eine Übertragung in einer Schlange besitzt, indem sie ein Feld in einem übertragenen ACK-Frame setzt, und ein AP kann optional eine Abfrage auf einem Downlink-Framehuckepackmäßig platzieren.
Es gibt mehrere Methoden, die mit dieser Ausführungsform der vorliegenden Erfindung verwendet werden können. Typischerweise werden wenigstens zwei Verfahren verwendet, nämlich ein Verfahren für Nicht-802.11e-Stationen und ein Verfahren für 802.11e-Stationen. Es sollte angemerkt werden, dass eine Station, die 802.11e unterstützt, auch als eine Nicht-802.11e-Station fungieren kann. Das Verfahren für die 802.11-Station kann eine 802.11e-Abfrage oder eine huckepack genommene 802.11e-Abfrage verwenden, wie dies hier weiter unten beschrieben wird.
Diese Ausführungsform zieht in Betracht, dass VoIP-Stationen eine explizite TSPEC-Signalisierung für die Zugangskontrolle verwenden. Ein AP verwendet eine Warteschlangeneinreihung mit strenger Priorität und einen HCF-Kanalzugriff mit hoher Priorität für Downlink-Sprachflüsse, wie dies hier oben beschrieben worden ist. Der HCF-Kanalzugriff wird als die "EDCF- Zugriffskategorie mit der höchsten Priorität" implementiert; deshalb fügt die Unterstützung für die Downlink-HCF wenig Komplexität hinzu. Ein kombiniertes Zugriffsverfahren, welches sowohl EDCF als auch das einfache Polling ohne Fehlerkorrektur verwendet, wird als das Zugriffsverfahren für Uplink-Sprachflüsse über die TSPEC-Signalisierung ausgehandelt.
Eine Nicht-802.11e-Station kann ihrem Vater-AP anzeigen, dass sie einen Frame für einen zugelassenen Uplink-Sprachfluss in einer Schlange besitzt, indem das "More Data" Bit (Mehr-Daten-Bit) in einem übertragenen ACK-Frame oder Datenframe auf EIN gesetzt wird. Wenn der AP einen ACK-Frame empfängt, bei dem das More Data Bit auf EIN gesetzt ist, sollte er ein "freilaufendes CTS" erzeugen, bei dem das "Dauer"-Feld so gesetzt ist, dass es den Kanal für die jeweilige Uplink-Sprachübertragung reserviert.
Eine 802.11e-Station kann ihrem Vater-AP anzeigen, dass sie einen Frame für einen zugelassenen Uplink-Sprachfluss in einer Schlange besitzt, indem eine Nicht-Null-"Schlangengröße" (oder das More Data Bit) in einem übertragenen QoS CF-ACK Frame gesetzt wird. Wenn der AP einen QoS CF-ACK- oder Datenframe mit einem Nicht-Null-Schlangengrößen-Feld empfängt, sollte er einen Poll-Frame mit einer Dauer erzeugen, die den Kanal für die jeweilige Uplink-Sprachübertragung reserviert.
Der AP kann den Kanal zurückfordern, wenn CCA für eine PIFS-Zeit, nachdem er einen freilaufenden CTS-Frame oder Poll-Frame überträgt, immer noch aktiviert ist. Der AP muß den CTS- oder Poll-Frame nicht wiederholen.
Der AP kann optional eine Abfrage auf einem Downlink-QoS-Datenframe, der zu einer 802.11e-Station gesendet wird, huckepack platzieren, um (einen) Uplink-Frame(s) zu veranlassen. Die 802.11e-Station muß auf die Abfrage mit a) einem QoS Daten- + Ack-Frame (Data + Ack frame) oder b) einem QoS Ack Frame mit einem Schlangengrößenwert von 0 antworten. Es sei angemerkt, dass es die zweite Option dem AP ermöglicht, Abfragen auf jedem Downlink-Frame huckepack zu platzieren, ohne den Overhead einer QoS-Null-Datenübertragung während Perioden von Geräuschunterdrückung hinzuzufügen. Ein AP kann optional "lernen", dass er Abfragen automatisch auf Downlink-Übertragungen huckepack platzieren soll, indem er Uplink- Übertragungen überwacht, oder das Huckepack-Polling kann explizit über eine TSPEC-Signalisierung ausgehandelt werden.
Im Falle des Nichtvorhandenseins der Geräuschunterdrückung durch die Peer-Sprachstation ermöglicht es die einfache HCF-ähnliche VoIP-Implementierung, dass Downlink-Sprachübertragungen Uplink-Sprachübertragungen in einer ziemlichen ähnlichen Art und Weise wie das Timer-basierte HCF-Polling veranlassen; deshalb weist sie viele der Vorteile der HCF auf. Aber sie ist einfacher als HCF, weil der AP keine Poll-Timer verwalten muß oder irgendwelche Polling-Zustandsinformationen bewahren muß. Ein "freilaufendes CTS-Verfahren", das unten beschrieben wird, benötigt KEINE 802.11e-Frame-Formate; deshalb kann es verwendet werden, um Nicht-802.11e-Stationen zu unterstützen.
Die Frame-Austauschsequenzen, die in den 1–4 veranschaulicht sind, erläutern beispielhaft die einfache HCF für VoIP. Es sei angemerkt, dass ein "QoS Data"-(Dienstgütedaten-), "QoS ACK"-(Dienstgüte-Bestätigungs-) oder "QoS Poll"-(Dienstgüteabfrage-)Frame ein 802.11e-QoS-Steuerdatenfeld enthält. Eine ACK und eine Poll können in einem einzigen 802.11e ACK + Poll-Frame kombiniert werden. Jede der Figuren veranschaulicht einen bidirektionalen Burst von Frames, die mit dem minimalen "kurzen Zwischenrahmenabstand" (SIFS; short interframe spacing) im Anschluss an eine einzelne Ausführung des HCF-Kanalzugriffs-Algorithmus durch den AP gesendet werden.
Unter Bezugnahme auf 1 ist der Austausch 100 gezeigt, der zwischen einem AP 10 und einer Station 20 stattfindet und der typischerweise für Nicht-802.11e-Stationen erfolgen würde. Im Schritt 102 führt der AP 10 den Kanalzugriffs-Algorithmus aus und überträgt Daten (Data) zu der Station 20. Die Station 20 sendet dann eine ACK 104, bei der das More Data Bit auf Ein gesetzt ist, um anzuzeigen, dass sie Daten zur Übertragung in einer Schlange aufweist. Dies veranlasst den AP 106, ein CTS zu senden, wie dies im Schritt 106 gezeigt ist, um den Kanal zu der Station zu liefern. Dann sendet die Station 20, wie im Schritt 108 gezeigt ist, Daten, und wie gezeigt ist, ist das More Data Bit in diesem Beispiel auf Ein gesetzt. Der AP 10 sendet dann nach dem Empfangen der Daten beim Schritt 110 eine ACK. Da das More Data Bit auf Ein gesetzt ist, überträgt der AP 10 dann ein weiteres CTS, wie dies im Schritt 112 gezeigt ist. Die Station 20 antwortet dann mit mehr Daten, wie dies im Schritt 114 gezeigt ist. In diesem Beispiel wird das More Data Bit dann, wenn die Daten beim Schritt 114 gesendet sind, auf Aus gesetzt. Dies veranlasst den AP 10, dann eine ACK zu senden, wie dies im Schritt 116 gezeigt ist, aber der AP 10 sendet kein weiteres CTS nach der ACK. Wenn das More Data Bit im Schritt 114 auf Ein gesetzt ist, dann würde der AP 10 ein weiteres CTS senden.
Nun wird Bezug auf 2 genommen. Darin ist ein Austausch 200 gezeigt, wenn der AP 10 eine 802.11e Poll (Abfrage) sendet. Beim Schritt 202 sendet der AP 10 dann QoS-Daten (QoS Data) zu der Station 20. Die Station 20 antwortet beim Schritt 204 mit einer QoS CF-ACK, wobei die Schlangengröße größer als null ist. Da die Schlangengröße größer als null bzw. nicht null ist, veranlasst dies den AP 10 im Schritt 206, eine weitere QoS Poll zu senden. Im Schritt 208 antwortet die Station 20 mit QoS-Daten (QoS Data), und wiederum ist, wie in diesem Beispiel gezeigt ist, die Schlangengröße (S-Größe) größer als null. Dies veranlasst den AP 10, im Schritt 210 mit einer QoS Ack und einer Poll bzw. Abfrage (QoS Ack + Poll) zu antworten. Nach dem Empfangen der QoS Ack + Poll sendet die Station 20 mehr QoS-Daten (QoS Data), wie dies im Schritt 212 gezeigt ist. Wie in diesem Beispiel gezeigt ist, ist die Schlangengröße gleich null. Aber wenn eine Schlangengröße ungleich null gesetzt ist, dann würde der Prozess zum Schritt 210 zurückkehren.
Nun wird Bezug auf 3 genommen. Darin ist ein Austausch 300 gezeigt, der zwischen einem AP 10 und einer Station 20 unter Verwendung einer huckepack genommenen 802.11e Abfrage stattfindet. Beim Schritt 302 sendet der AP 10 QoS-Daten (Data) und eine Abfrage (Poll) (QoS Data + Poll) zu der Station 20. Die Station 20 antwortet mit QoS-Daten und einer Ack (QoS Data + Ack) beim Schritt 304. In diesem Beispiel wird die Schlangengröße (S-Größe) im Schritt 304 auf null gesetzt, so dass der AP 10 beim Schritt 306 nur mit einer Ack antwortet; ansonsten würde der AP 10 unter der Voraussetzung. dass die Station 20 ihre Zugangskontrolle nicht überschritten hat, beim Schritt 306 eine weitere Abfrage senden, und der Prozess würde fortgesetzt werden, bis die Station 20 eine QoS Data + Ack sendet, bei der die Schlangengröße gleich null ist, oder bis die Station 20 ihre Zugangskontrolle überschritten hat.
Nun wird Bezug auf 4 genommen. Darin ist ein Austausch 400 gezeigt, der stattfindet, wenn der AP 10 eine huckepack genommene 802.11e Abfrage sendet und bei der Station 20 keine wartenden Daten vorhanden sind. Im Schritt 402 sendet der AP QoS-Daten (QoS Data) und eine Abfrage bzw. Poll (QoS Data + Poll), was die Station 20 veranlasst, beim Schritt 404 mit einer Ack zu antworten, und wobei die Schlangengröße auf null gesetzt ist.
Es sei angemerkt, dass es fast keinen hinzugefügte Overhead für das Huckepacknehmen einer Abfrage auf jedem Downlink-Frame, der zu einer Station 20 gesendet wird, gibt, selbst wenn die Station 20 keine Daten zum Senden aufweist (d. h., selbst wenn eine Geräuschunterdrückung verwendet wird). Wenn die Station 20 keine Daten zum Senden besitzt, dann kann sie auf eine Data + Poll mit einer QoS ACK antworten (d. h., die "Schlangengröße" ist auf 0 gesetzt), und der Austausch ist vorbei, wie dies oben gezeigt ist.
Eine weitere Ausführungsform der vorliegenden Erfindung ist ein einfaches Polling-Fehlerkorrekturverfahren. Der Fehlerkorrekturmechanismus, der im Augenblick in dem 802.11e Entwurf für einen HCF-gepollten Zugriff spezifiziert ist, ist kompliziert und unbestimmt. Wenn dem HC eine erwartete Antwort auf eine Abfrage fehlt, dann initiieren sowohl der HC als auch die Station eine Fehlerkorrektur. In einigen Fällen kann der 802.11e-Fehlerkorrekturmechanismus zu mehrfachen Kollisionen führen. In einem Ausführungsbeispiel der vorliegenden Erfindung wird ein Polling-Fehlerkorrekturmechanismus für Stationen in Betracht gezogen, die vor allem EDCF verwenden, um Uplink-Frames zu senden, aber immer noch auf HC-Abfragen reagieren. Der vorgeschlagene Fehlerkorrekturmechanismus wird durch die folgenden Regeln definiert:

1) Eine Station verwendet EDCF, um Uplink-Frames zu senden.
2) Sowohl der AP als auch die Station verwenden die normalen HCF- und EDCF-Backoff-Regeln immer dann, wenn eine erwartete Antwort nicht empfangen wird.
3) Eine Station, die EDCF für einen Uplink-Strom verwendet, kann exakt 1 Rahmen in Reaktion auf eine Abfrage von dem HC senden (d. h., entweder einen Data + Ack Frame oder einen Ack Frame).
4) Wenn der AP einen Data + Ack Frame (d. h., einen Datenframe mit einer huckepack genommenen Ack) von einer Station empfängt, wobei die Schlangengröße nicht null ist, dann kann er optional (d. h., erneut) die Station Pollen. Deshalb kann eine Station mehrere Frames in einer einzigen Polling-Sequenz senden.
5) Der normale EDCF-Zugriff ist das Wiederherstellungsverfahren, das verwendet wird, um einen Rahmen erneut zu übertragen, wenn eine Abfrage verloren gegangen ist oder wenn eine Ack im Anschluss an eine gepollte Uplink-Übertragung verloren gegangen ist. Deshalb braucht ein AP eine Abfrage nicht erneut zu senden, wenn eine Antwort nicht empfangen wird. Es sei angemerkt, dass der AP einen Data + Poll Frame neu senden muß, wenn eine Ack nicht empfangen wird.

Noch eine weitere Ausführungsform der vorliegenden Erfindung zieht einen sehr einfachen AP-Polling-/Weck-Scheduler basierend auf einem "Timer-Rad" (Timer Wheel) in Betracht, der verwendet werden kann, um periodische Polling- und/oder Weckpläne zu unterstützen, die für Stationen erstellt werden. Der gleiche Scheduler kann verwendet werden, um a) APSD, b) geplante Weckzeiten, die nicht auf Signale (Beacons) ausgerichtet sind, und c) Abfragepläne zu unterstützen.
Eine weitere Ausführungsform der vorliegenden Erfindung ist ein einfaches Energiesparverfahren für VoIP-Stationen. Der aktuelle 802.11e Entwurf beschreibt ein automatisches stromsparendes Lieferungsverfahren (APSD; Automatic Power-Save Delivery Method), bei dem Stationen "Wecksignale" erstellen und der AP zwischengespeicherte Downlink-Frames sofort nach den Wecksignalen liefert. Ein AP zeigt an, der er zwischengespeicherte Frames für eine Station hat, indem der das Stations Bit in dem TIM in Signalen und Probe-Antwort-Frames setzt.
Das APSD-Verfahren ist viel einfacher als das HCF-"Dienstperiode"-Energiesparverfahren, das in dem aktuellen 802.11e Entwurfbeschrieben ist. APSD weist auch anders als das Dienstperiodeverfahren den Vorteil auf, dass es mit EDCF oder HCF gleich arbeitet. Aber das APSD-Verfahren in dem aktuellen 802.11e Entwurf weist im Vergleich zu dem "Dienstperiode"-Verfahren einige Nachteile auf: a) APSD erfordert eine schnelle Signalrate, um VoIP-Stationen unterstützen zu können; b) APSD gruppiert Energiesparverkehr um Signalübertragungen herum; und c) APSD erfordert es, dass Stationen wach bleiben, um Energiesparverkehr von anderen Stationen zu empfangen.
Die APSD-Nachteile können zum großen Teil gelöst werden, wenn APSD wie folgt weiterentwickelt wird:

1) Der HC und eine Station können einen Weckzeitplan aushandeln, wobei die geplanten Weckzeiten mit Signalübertragungen übereinstimmen können oder auch nicht.
2) Das HC-Polling ist mit dem Weckzeitplan vereinigt, so dass eine Abfrage zu einer Energiesparstation zu jeder geplanten Weckzeit gesendet wird.
3) Ein AP kann das "More Data" Bit in einem ACK Frame, der zu einer Station gesendet wird, die in dem APSD-Modus arbeitet, auf EIN setzen, um anzuzeigen, dass er zwischengespeicherte Frames für die Station hat.
4) Wenn eine APSD-Station eine ACK empfängt, bei der das More Data Bit auf Ein gesetzt ist, muß sie exakt so arbeiten, als ob sie einen TIM (d. h. in einem Signal) empfangen hat, bei dem sein Bit auf EIN gesetzt ist: Sie muß wach bleiben, bis sie einen Datenframe, bei dem das More Data Bit auf AUS gesetzt ist, oder einen TIM empfängt, bei dem sein Bit auf AUS gesetzt ist.

Im Falle des Nichtvorhandenseins einer Geräuschunterdrückung muß eine Energiespar-VOIP-Station zu jeder Sprachabtastperiode aufwachen, um eine Uplink-Übertragung zu senden. Deshalb ermöglicht es das verbesserte APSD-Verfahren dem AP, zwischengespeicherte Frames zu einer APSD-Station bei der VoIP-Abtastrate ohne die Nachteile in dem aktuellen 802.11e-APSD-Verfahren zu liefern.
Eine beispielhafte Frame-Austauschsequenz 500 ist in 5 gezeigt. Die Sequenz beginnt beim Schritt 502, bei dem die Station 20 Daten (Data) zu dem AP 10 sendet. Beim Schritt 504 sendet der AP 10 eine ACK, bei der das More Data Bit auf Ein gesetzt ist, gefolgt von den Energiespardaten (PS Data), wie dies im Schritt 506 gezeigt ist. Beim Schritt 508 antwortet die Station 20 mit einer ACK.
Das Verfahren, das oben für 5 beschrieben ist, ist nicht ausreichend für ein Energiemanagement bei VoIP-Stationen, die eine Geräuschunterdrückung verwenden. In diesem Fall können der HC und die Station das verbesserte APSD-Energiesparverfahren verwenden, wobei der HC eine Abfrage zu jeder geplanten Weckperiode erzeugt. Die Abfrage ermöglicht es der Station, in der Abwesenheit von weiterem Uplink- oder Downlink-Verkehr schnell zu dem Stromsparschlaf-Zustand zurückzukehren, wie dies durch die Frame-Austauschsequenz 600 in 6 gezeigt ist. Der AP 10 wartet bis zu einer geplanten Weckzeit, wie dies beim Schritt 602 gezeigt ist. Beim Schritt 604 sendet der AP 10 eine Abfrage/Poll, bei der das More Data Bit auf Aus gesetzt ist. Beim Schritt 606 sendet die Station 20 eine ACK, bei der das More Data Bit auf Aus gesetzt ist, und dann kehrt die Station 20, wie dies bei Schritt 608 gezeigt ist, zu einem Energiesparzustand zurück.
In ähnlicher Weise kann eine VoIP EDCF Station QoS-Null-Frames während Perioden der Geräuschunterdrückung erzeugen, um den AP nach zwischengespeicherten Energiespar-Frames zu "pollen", wie dies in 7 gezeigt ist. Die Frame-Austauschsequenz 700 startet beim Schritt 702, wenn die Station 20 eine QoS Null sendet, bei der das More Data Bit auf Aus gesetzt ist. In Reaktion darauf sendet der AP 10 eine ACK, bei der das More Data Bit auf Aus gesetzt ist, wie dies in Schritt 704 gezeigt ist, außer natürlich es gibt zwischengespeicherte Daten. Beim Schritt 706 kehrt die Station zu einem Energiesparzustand zurück.
Nun wird Bezug auf 8 genommen. Darin ist eine beispielhafte Frame-Austauschsequenz 800 gezeigt, die zeigt, wie Downlink- und Uplink-Datenübertragungen ineinander verschachtelt werden können. Wie beim Schritt 802 gezeigt ist, sendet der AP 10 eine Data + Poll, bei der das More Data Bit gesetzt ist, was anzeigt, dass der AP 10 weitere Daten zum Senden zu der Station 20 besitzt.
Beim Schritt 804 antwortet die Station 20 mit Data + Ack, wobei das More Data Bit auf Ein gesetzt ist, was anzeigt, dass die Station 20 auch mehr Daten zum Senden zu dem AP 10 besitzt. Die Ack dient dazu, die Daten zu bestätigen, die beim Schritt 802 gesendet wurden.
Beim Schritt 806 antwortet der AP mit Data + Poll + Ack. Die Station 20 erwartet die Daten, weil das More Data Bit im Schritt 802 gesetzt war. Die Abfrage wird in Reaktion darauf, dass das More Data Bit von der Station 20 im Schritt 804 auf Ein gesetzt war, gesendet, und natürlich wird die ACK in Antwort auf die Daten, die beim Schritt 804 gesendet wurden, gesendet. Beim Schritt 808 sendet die Station 20 Data + Ack. Da bei dem AP 10 das More Data Bit nicht auf Ein gesetzt war, als er seine letzte Übertragung beim Schritt 806 gesendet hat, und bei der Station 20 das More Data Bit nicht auf Ein gesetzt war, als sie ihre letzte Übertragung beim Schritt 808 gesendet hat, schließt dieses die Frame-Austauschsequenz 800 ab.
Nun wird Bezug auf 9 genommen. Darin ist ein Zugangskontroll-Prozessablauf 900 gezeigt. Der Prozess beginnt beim Schritt 902, bei dem der Token Gucket bzw. Token-Eimer mit einer Anzahl von Tokens "X" initialisiert wird. Ein Timer wird dann beim Schritt 904 gestartet. Beim Schritt 906 prüft der AP (nicht gezeigt), ob Verkehr für die Station (nicht gezeigt) vorhanden ist. Wenn Verkehr für die Station vorhanden ist, dann geht der Prozess weiter zu Schritt 908, bei dem ermittelt wird, ob irgendwelche Tokens übrig sind (X > 0). Wenn Tokens übrig sind, dann wird der Fluss, der ein Uplink- oder ein Downlink-Fluss sein kann, bedient, wie dies durch Schritt 910 gezeigt ist. Beim Schritt 912 wird die Anzahl an Tokens X nach einem erfolgreichen Uplink oder Downlink dekrementiert. Die Anzahl an Tokens kann um eins, um die Anzahl an Frames, die in dem Uplink oder dem Downlink verarbeitet werden, oder durch jedes andere Verfahren dekrementiert werden, um zu gewährleisten, dass die Station nicht mehr Verkehr verwendet, als der AP es der Station erlaubt, zu verwenden. Für Prozesse, die es gestatten, dass mehrere Frames auf einmal gesendet werden können, kann der Schritt 908 modifiziert werden, um zu bestimmen, ob X – # an Frames größer oder gleich null ist. Nach dem Anpassen der Anzahl an Tokens im Schritt 921 geht der Prozess weiter zu Schritt 914, bei dem der Timer überprüft wird, um festzustellen, ob er abgelaufen ist. Wie dies durch Schritt 916 gezeigt ist, wird jedes mal dann, wenn der Timer abläuft, eine gewisse Anzahl an Tokens Y, wobei X <= Y, zu dem Token Gucket addiert; aber die gesamte Anzahl an Tokens in dem Token Gucket wird auf einen gewissen maximalen Wert begrenzt. Wenn der Timer abgelaufen ist, dann werden die Tokens wieder aufgefüllt, wie dies bei Schritt 916 gezeigt ist, und die Verarbeitung kehrt zum Schritt 904 zurück und der Timer wird neu gestar tet. Wenn der Timer noch nicht abgelaufen ist, dann kehrt der Prozess zu dem Schritt 906 zurück, um zu überprüfen, ob noch mehr Verkehr für die Station vorhanden ist.
Wenn bei dem Schritt 906 kein weiterer Verkehr für die Station vorhanden ist, dann geht der Prozess zum Schritt 912, um festzustellen, ob der Timer abgelaufen ist.
Wenn beim Schritt 908 festgestellt wird, dass die Station keine weiteren Tokens besitzt, dann wird kein weiterer Verkehr für die Station gehandhabt, bis der Timer bei Schritt 912 abläuft.
Eine weitere Ausführungsform der vorliegenden Erfindung ist ein einfacher Polling-/Weck-Scheduler. Diese Ausführungsform ist ein sehr einfacher AP-Polling-/Weck-Scheduler basierend auf einem "Timer-Rad", der verwendet werden kann, um periodische Polling- und/oder Weckpläne zu unterstützen, die für Stationen erstellt werden. Der gleiche Scheduler kann verwendet werden, um a) APSD, b) geplante Weckzeiten, die nicht auf Signale ausgerichtet sind, und c) Polling-Pläne zu unterstützen.
Ein "Timer-Rad" (Timer Wheel) ist eine kreisförmige Liste von "Buckets" (Eimern) (oder eine kreisförmige Warteschlange), bei der jeder Eimer einem "Takt-Tick" bzw. "Taktticken" entspricht und jeder Eimer eine möglicherweise leere verbundene Liste von "Timer-Strukturen" enthält. Ein "aktueller Zeiger" wird bei jedem Taktticken zu dem nächsten Eimer vorgerückt. Ein Eimer wird bedient, wenn er der "aktuelle Eimer" ist. Ein Timer wird gestartet, indem er in den Eimer in dem Timer-Rad eingefügt wird, wobei der Abstand von dem aktuellen Zeiger gleich der Timer-Periode in Einheiten von Taktticken (Takt-Ticks) ist.
Für den AP-Polling-/Weck-Scheduler ist ein Timer-Rad-"Takt-Tick" irgendein ganzzahliges Vielfaches von TSF-Timer-Ticks, und eine "Timer-Struktur" zeigt zu einer Station mit einem Polling- und/oder Weckplan. Der AP kann den Weck-, Polling- oder einen kombinierten Weck-/Pollingplan für eine Station erstellen. Deshalb kann er eine Dienstplanstartzeit für eine Station erstellen, die auf einen Timer-Rad-Eimer und eine Dienstperiode ausgerichtet ist, die ein Vielfaches von Timer-Rad-Takt-Ticks ist.
Bei jedem Takt-Tick bedient der Scheduler alle Stationen in dem jeweiligen Eimer. Der AP bedient eine Station mit einer geplanten Weckzeit durch das Bewegen von Energiespar-Frames der Station zu den aktiven 802.11-Übertragungsschlangen. Der AP platziert eine möglicherweise huckepack genommene Abfrage in der Übertragungsschlange mit strenger Priorität für eine Station, die für das Polling geplant ist (d. h., eine Station mit einem zugelassenen Uplink-Sprachfluss).
Die Zeit zum Starten/Anhalten eines Timer-Rad-Timers ist von der Ordnung (1), ungeachtet der Anzahl von Stationen (wenn Eimer als eine doppelt verbundene Liste implementiert sind). Ein Algorithmus ist von der Ordnung (1), wenn die Laufzeit ungeachtet der Anzahl an Knoten konstant ist. Ein Algorithmus ist von der Ordnung (N), wenn die Laufzeit proportional zu der Anzahl von Knoten ansteigt. In vielen Timer-Ordnung(N)-Timer-Algorithmen wird ein Timer zu einer sortierten Liste von Timern hinzugefügt. Die Laufzeit zum Starten eines Timers ist proportional zu der Anzahl an Timern, weil die Liste durchsucht werden muß, um die korrekte Position zu finden.
10 ist ein Beispiel der Operation des Timer-Rads 1000. Das Timer-Rad 1000 umfasst vier Eimer, nämlich den Eimer 1 1002, den Eimer 2 1004, den Eimer 3 1006 und den Eimer 4 1008. Ein aktueller Zeiger 1010 bestimmt, welcher Eimer bedient wird. Nachdem der aktuelle Zeiger 1010 den letzten Eimer erreicht hat, wie dies durch 1022 gezeigt ist, wird der aktuelle Zeiger zurückgesetzt und startet wieder beim Eimer 1 1002.
Der Eimer 1 1002, der Eimer 2 1004 und der Eimer 4 1008 weisen Aufgaben oder Flüsse auf, die ihnen zugewiesen sind. Der Eimer 3 1006 besitzt im Augenblick keine Aufgaben, aber Aufgaben oder Flüsse können je nach Notwendigkeit zugewiesen werden. In ähnlicher Weise können Aufgaben, die im Augenblick von den anderen Eimern bedient werden, gelöscht werden, wenn sich die Station zu einem anderen AP bewegt. Dem Eimer 1 1002 sind zwei Aufgaben zugewiesen, nämlich er soll erstens bei 1014 für die Station 5 (nicht gezeigt) eine Abfrage (Poll) durchführen, und dann soll er, wie durch 1016 ge zeigt ist, eine Abfrage und ein Wecken (poll + wakeup) bei der Station 23 (nicht gezeigt) durchführen. Der Eimer 2 1004 besitzt eine Aufgabe, wie bei 1012 gezeigt ist, und das ist die Aufgabe, eine Station 18 (nicht gezeigt) zu Pollen und zu wecken (poll + wakeup). Dem Eimer 4 1008 sind zwei Aufgaben zugewiesen, nämlich erstens, wie durch 1018 gezeigt ist, eine Abfrage (poll) und ein Wecken (wakeup) für die Station 9 (nicht gezeigt), und dann, wie durch 1020 gezeigt ist, eine Abfrage (poll) für die Station 12 (nicht gezeigt).
Wie in 10 gezeigt ist, befindet sich der aktuelle Zeiger 1010 bei dem Eimer 2 1004, und somit wird eine Abfrage (poll) und ein Wecken (wakeup) zu der Station 18 gesendet. Bei dem nächsten Taktticken wird sich der aktuelle Zeiger 1010 zu dem Eimer 3 1006 bewegen, und da keine Aufgaben oder Flüsse vorhanden sind, werden keine Polls oder Wakeups gesendet. Nach einem weiteren Taktticken wird sich der aktuelle Zeiger 1010 zu dem Eimer 4 1008 bewegen, welcher dann veranlassen wird, dass eine Abfrage (poll) und ein Wecken (wakeup) zu der Station 9 und eine Abfrage (poll) zu der Station 12 gesendet werden. Nach dem Erreichen des Endes der Liste wird der aktuelle Zeiger beim Eimer 1 2002 neu starten, woraufhin eine Abfrage (poll) zu der Station 5 und eine Abfrage (poll) und ein Wecken (wakeup) zu der Station 23 gesendet werden.
Wie die Fachleute auf dem Gebiet ohne weiteres erkennen werden, unterscheiden sich die hier beschriebenen Verfahren wesentlich von den Verfahren, die im Augenblick in dem 802.11e Entwurf beschrieben sind, und zwar aus den unten aufgelisteten Gründen:

1) Der 802.11e Entwurf weist einen "Referenz-Scheduler" auf, bei dem Abfragen zu geplanten Zeitperioden übertragen werden. In dem einfachen HCF-Scheduler, der hier beschrieben ist, werden (möglicherweise huckepack genommene) Abfragen einfach zu dem hinteren Ende einer FIFO-Schlange mit strenger Priorität hinzugefügt (d. h., wenn ein Abfrage-Timer abläuft). Der "Übertragungs-Scheduler" arbeitet einfach in einer Schleife, die die Schlange mit strenger Priorität immer dann bedient, wenn sie nicht leer ist. Mehrere Dienstperioden können zu einem einzigen Eimer gruppiert werden, da Abfragen einfach für die Übertragung wie jeder andere Downlink-Frame in die Schlange gestellt werden. Es ist eine direktere Vorgehensweise, Daten und Abfragen zu einem einzigen Frame zu vereinigen (z. B. kann eine Abfrage auf jeder Downlink-Übertragung "mit strenger Priorität" huckepack genommen werden, ohne dass es einen zusätzlichen Overhead gibt).
2) Ein einzelner, einfacher (d. h., Timer-Rad-)Scheduler unterstützt sowohl Polling- als auch geplante Weckperioden mit einem einzigen zugrunde liegenden TSF-basierten Timer.
3) Das einzige Energiesparverfahren, das in dem vorliegenden Dokument beschrieben ist, unterstützt sowohl das aktuelle 802.11e APSD Verfahren als auch Dienstperioden pro Strom. [Im Augenblick stimmt ein APSD-Weckplan mit Signalübertragungen überein. Da Signalübertragungen mit dem TSF-Timer synchronisiert sind, ist es trivial, einen APSD-Plan auf eine TSF-Startzeit und -Zwischenzeitperiode zu übertragen.]
4) Das Synchronisieren von Abfrage-/Weckzeiten mit dem TSF-Timer beseitigt das Synchronisierungsproblem bei dem aktuellen 802.11e-Dienstperiodenmechanismus, ohne dass irgendwelche neuen "verteilten" Timer benötigt werden. (Der aktuelle 802.11e Dienstperiodenmechanismus erfordert zusätzliche Timer.)

Das kombinierte gepollte + EDFC-Zugriffsverfahren beseitigt die Notwendigkeit für die Polling-Fehlerkorrektur. Es kann auch verwendet werden, um die Zugriffslatenzzeit zu reduzieren. [EDCF reduziert die Latenzzeit in leicht belasteten Kanälen, da die Stationen nicht darauf warten müssen, dass eine Abfrage übertragen wird; aber unter schweren Belastungen ist sie nicht deterministisch.] Die obige Beschreibung eines bevorzugten Ausführungsbeispiels der Erfindung ist zu Zwecken der Veranschaulichung und der Beschreibung präsentiert worden. Sie soll nicht erschöpfend sein oder die Erfindung auf die genaue offenbarte Form beschränken. Offensichtliche Modifikationen oder Variationen sind im Hinblick auf die obigen Lehren möglich. Das Ausführungsbeispiel wurde ausgewählt und beschrieben, um die beste Veranschaulichung der Prinzipien der Erfindung und ihrer praktische Anwendung bereitzustellen, um dadurch einen Durchschnittsfachmann auf dem Fachgebiet in die Lage zu versetzen, die Erfindung in verschiedenen Ausführungsbeispielen und mit verschiedenen Modifikationen, wie sie für den speziellen, in Betracht gezogenen Gebrauch geeignet sind, verwenden zu können. Alle solchen Modifi kationen und Variationen liegen innerhalb des Schutzumfangs der Erfindung, wie sie durch die angehängten Ansprüche bestimmt ist.

Claims

Verfahren zum Steuern von Kanalzugriff durch einen 802.11 Zugriffspunkt (10), wobei das Verfahren gekennzeichnet ist durch: Erzeugen einer einer Hybrid Coordination Function-, HCF-Schlange mit strenger Priorität, wobei die HCF-Schlange mit strenger Priorität verwendet wird, um wenigstens eine einer Contention Free-, CF-, Poll- und Downlink-Daten-Übertragung in die Schlange einzureihen; Einfügen wenigstens einer einer CF-, Poll- und Downlink-Daten-Übertragung in die HCF-Schlange mit strenger Priorität; und Bedienen der HCF-Schlange mit strenger Priorität vor dem Bedienen einer Enhanced Distributed Coordination Function-, EDCF-Übertragungsschlange.
Verfahren nach Anspruch 1, wobei die HCF-Schlange mit strenger Priorität nur für Daten- und Poll-Frames für einen zugelassenen interaktiven Sprachstrom- und Netzwerkmanagement-Verkehr verwendet wird.
Verfahren nach Anspruch 1, wobei die HCF-Schlange mit strenger Priorität eine First-In-First-Out-Schlange ist.
Verfahren nach Anspruch 1, das des Weiteren das Zuordnen einer festgelegten Größe zu allen Übertragungsmöglichkeiten umfasst.
Verfahren nach Anspruch 1, wobei der Schritt des Erzeugens mehrere HCF-Schlangen mit strenger Priorität erzeugt, wobei jede HCF-Schlange auf eine spezifische Verkehrsklasse abgebildet wird.
Verfahren nach Anspruch 5, wobei die Verkehrsklasse wenigstens eine ausgewählt aus der Gruppe bestehend aus einer Sprachmanagement-Schlange und einer Netzwerkmanagement-Schlange ist.
Verfahren nach Anspruch 5, wobei wenigstens eine HCF-Schlange mit strenger Priorität nur einen Satz zugelassener Frames empfängt, die der Zugangskontrolle unterliegen, wobei der Satz zugelassener Frames, die der Zugangskontrolle unterliegen, in dem 802.11 Zugriffspunkt (10) über ein Signalisierungsprotokoll erstellt wird.
Verfahren nach Anspruch 1, das des Weiteren das Binden eines Ausgangs-Dienstgüte-Klassifizierers durch den 802.11 Zugriffspunkt (10) an eine Ziel-Medium Access Control-, MAC-Adresse einer 802.11 Station (20) mit einem zugelassenen Verkehrsstrom umfasst, und das Identifizieren von Downlink-Frames für den zugelassenen Verkehrsstrom durch den 802.11 Zugriffspunkt (10).
Verfahren nach Anspruch 8, wobei der Ausgangs-Dienstgüte-Klassifizierer wenigstens einen aus der Gruppe bestehend aus Internetprotokolladresse-, Internetprotokolltyp- und User Datagram Protocol-, UDP-, Transmission Control Protocol-, TCP-, Port-Identifizierer aufweist, der einen Anwendungsverkehrsstrom eindeutig identifiziert.
Verfahren nach Anspruch 9, wobei die Parameter für den Ausgangs-Dienstgüte-Klassifizierer durch ein Dienstgüte-Signalisierungsprotokoll erhalten werden.
Verfahren nach Anspruch 9, wobei die Parameter für den Ausgangs-Dienstgüte-Klassifizierer automatisch durch den 802.11 Zugriffspunkt (10) abgeleitet werden.
Verfahren nach Anspruch 11, das des Weiteren das Schnüffeln (snooping) der Datenpakete durch den 802.11 Zugriffspunkt (10) umfasst, um die Parameter für den Ausgangs-Dienstgüte-Klassifizierer abzuleiten.
Verfahren nach Anspruch 6, das des Weiteren das Bestimmen einer Verkehrsklasse für einen Verkehrstrom durch ein Dienstgüte-Signalisierungsprotokoll umfasst.
Verfahren nach Anspruch 1, das des Weiteren das Erstellen eines periodischen Abfrageplans für eine Station (20) umfasst, und das Platzieren einer CF-Poll in einer HCF-Übertragungsschlange mit strenger Priorität zu jeder geplanten Abfragezeit.
Verfahren nach Anspruch 1, das des Weiteren umfasst: Erstellen eines Weckplans für eine Energiesparstation, wobei der Weckplan mit dem Abfrageplan der Energiestation übereinstimmt; Übertragen aktiver für die Station (20) zwischengespeicherter Frames an eine aktive Übertragungsschlange nach einer geplanten Weckzeit; und Anzeige an die Energiesparstation, wenn eine Datenübertragung abgeschlossen ist.
Verfahren nach Anspruch 15, das des Weiteren das Senden eines Poll-Frames an die Energiesparstation nach einer geplanten Weckzeit umfasst, wobei der Poll-Frame ein Feld aufweist, um die Energiesparstation zu informieren, wenn zwischengespeicherte Frames auf die Übertragung warten.
Verfahren nach Anspruch 15, das des Weiteren das Senden eines Datenframes (802) an die Energiesparstation umfasst, mit einem Feld, das anzeigt, wenn mehr Frames in der Schlange vorhanden sind.
Verfahren nach Anspruch 14, wobei Abfragezeiten festgesetzt werden, um wenigstens eines von Latenzzeit und Wettbewerb zu minimieren.
Verfahren nach Anspruch 18, wobei die Abfragezeiten unterschiedlich von Signalübertragungen sind.
Verfahren nach Anspruch 18, wobei Abfragezeiten festgesetzt werden, um die Zeitdauer zu minimieren, während der die Station (20) wach sein muss.
Verfahren nach Anspruch 14, wobei der Schritt des Erstellens des Weiteren das Synchronisieren des Abfrageplans mit einer Standard 802.11 Timersynchronisierungsfunktion umfasst.
Verfahren nach Anspruch 14, wobei der Abfrageplan eine Startzeit und eine Zwischenabfrageperiode aufweist, wobei die Startzeit ein Timersynchronisierungsfunktions-Timerwert ist und die Zwischenabfrageperiode ein mehrfaches Integral von Timersynchronisierungsfunktions-Zeiteinheiten ist.
Verfahren nach Anspruch 15, wobei der Schritt des Erstellens des Weiteren das Synchronisieren des Weckplans für die Energiesparstation mit einem Standard 802.11 Timersynchronisierungsfunktions-Timer umfasst.
Verfahren nach Anspruch 23, das des Weiteren das Definieren eines Dienstplans durch eine Startzeit und eine Zwischendienstperiode umfasst, wobei die Startzeit ein Timersynchronisierungsfunktions-Timerwert ist und die Zwischenabfrageperiode ein mehrfaches Integral von Timersynchronisierungsfunktions-Zeiteinheiten ist.
Verfahren nach Anspruch 15, wobei der Schritt des Erstellens des Weiteren das Empfangen von Abfrageerfordernissen über ein Signalisierungsprotokoll umfasst.
Verfahren nach Anspruch 25, wobei der Schritt des Erstellens des Weiteren das Erstellen eines Dienstplans basierend auf einem Timer-Rad (1000) umfasst, wobei das Timer-Rad (1000) Taktticken aufweist, die ein Integral einer Timersynchronisierungsfunktions-Zeiteinheit sind, wobei jedes Taktticken einen Eimer (1002, 1004, 1006, 1008) aufweist, wobei der Eimer eine verbundene Liste mit einem Eintrag für jede Station (20) aufweist, die zu dem entsprechenden Taktticken zu bedienen ist.
Verfahren nach Anspruch 14, wobei der Schritt des Erstellens des Weiteren das Empfangen von Abfrageerfordernissen über ein Signalisierungsprotokoll umfasst.
Verfahren nach Anspruch 27, wobei der Schritt des Erstellens des Weiteren das Erstellen eines Dienstplans basierend auf einem Timer-Rad (1000) umfasst, wobei das Timer-Rad Taktticken aufweist, die ein Integral einer Timersynchronisierungsfunktions-Zeiteinheit sind, wobei jedes Taktticken einen Eimer (1002, 1004, 1006, 1008) aufweist, wobei der Eimer eine verbundene Liste mit einem Eintrag für jede Station aufweist, die zu dem entsprechenden Taktticken zu bedienen ist.
Verfahren nach Anspruch 15, das des Weiteren das Senden einer in der Übertragungsschlange eingereihten Downlink-Datenübertragung umfasst, wobei die Downlink-Datenübertragung einen zwischengespeicherten Frame und eine Abfrage aufweist.
Verfahren nach Anspruch 29, wobei die Station (20) eine interaktive Sprachstation ist.
Verfahren nach Anspruch 14, das des Weiteren das Senden einer in der HCF-Übertragungsschlange mit strenger Priorität eingereihten Downlink-Datenübertragung umfasst, wobei die Downlink-Datenübertragung einen zwischengespeicherten Frame und eine Abfrage aufweist.
Verfahren nach Anspruch 31, wobei die Station (20) eine interaktive Sprachstation ist.
Computerimplementierbares Befehlserzeugnis mit computerimplementierbaren Befehlen, die, wenn sie in einer programmierbaren Computervorrichtung ausgeführt werden, die programmierbare Computervorrichtung veranlassen, die Schritte des Verfahrens nach einem der Ansprüche 1 bis 32 durchzuführen.
802.11 Zugriffspunkt (10) mit: einer Einrichtung zum Erzeugen einer Hybrid Coordination Function-, HCF-Schlange mit strikter Priorität, wobei die HCF-Schlange mit strikter Priorität verwendet wird, um wenigstens eine einer Contention Free-, CF-, Poll- und Downlink-Daten-Übertragung in die Schlange einzureihen; einer Einrichtung zum Einfügen wenigstens einer einer CF-, Poll- und Downlink-Daten-Übertragung in die HCF-Schlange mit strenger Priorität; und eine Einrichtung zum Bedienen der HCF-Schlange mit strenger Priorität vor dem Bedienen einer Enhanced Distributed Coordination Function-, EDCF-Übertragungsschlange.
Zugriffspunkt (10) nach Anspruch 34, wobei die HCF-Schlange mit strenger Priorität nur für Daten- und Poll-Frames für einen zugelassenen interaktiven Sprachstrom- und Netzwerkmanagement-Verkehr verwendet wird.
Zugriffspunkt (10) nach Anspruch 34, der des Weiteren eine Einrichtung zum Zuordnen einer festgelegten Größe zu allen Übertragungsmöglichkeiten aufweist.
Zugriffspunkt (10) nach Anspruch 34, wobei die Erzeugungseinrichtung so betreibbar ist, dass sie mehrere HCF-Schlangen mit strenger Priorität erzeugt, wobei jede auf eine spezifische Verkehrsklasse abgebildet wird.
Zugriffspunkt (10) nach Anspruch 37, wobei wenigstens eine HCF-Schlange mit strenger Priorität so betreibbar ist, dass sie nur einen Satz zugelassener Frames empfängt, die der über ein Signalisierungsprotokoll erstellten Zulassungskontrolle unterliegen.
Zugriffspunkt (10) nach Anspruch 34, der des Weiteren eine Einrichtung zum Binden eines Ausgangs-Dienstgüte-Klassifizierers an eine Ziel-Medium Access Control-, MAC-Adresse einer 802.11 Station (20) mit einem zugelassenen Verkehrsstrom umfasst, und eine Einrichtung zum Identifizieren von Downlink-Frames für den zugelassenen Verkehrsstrom.
Zugriffspunkt (10) nach Anspruch 39, wobei der Ausgangs-Dienstgüte-Klassifizierer wenigstens einen aus der Gruppe bestehend aus Internetprotokolladresse-, Internetprotokolltyp- und User Datagram Protocol-, UDP-, Transmission Control Protocol-, TCP-, Port- Identifizierer aufweist, der einen Anwendungsverkehrsstrom eindeutig identifiziert.
Zugriffspunkt (10) nach Anspruch 34, der des Weiteren eine Einrichtung zum Erstellen eines periodischen Abfrageplans für eine Station (20) umfasst, und eine Einrichtung für das Platzieren einer CF-Poll in einer HCF-Übertragungsschlange mit strenger Priorität zu jeder geplanten Abfragezeit.
Zugriffspunkt (10) nach Anspruch 34, der des Weiteren eine Einrichtung zum Erstellen eines Weckplans für eine Energiesparstation umfasst, wobei der Weckplan mit dem Abfrageplan der Energiestation übereinstimmt; eine Einrichtung zum Übertragen aktiver für die Station (20) zwischengespeicherter Frames an eine aktive Übertragungsschlange nach einer geplanten Weckzeit; und eine Einrichtung zur Anzeige an die Energiesparstation, wenn eine Datenübertragung abgeschlossen ist.
Zugriffspunkt (10) nach Anspruch 42, der des Weiteren eine Einrichtung zum Senden eines Poll-Frames an die Energiesparstation nach einer geplanten Weckzeit umfasst, wobei der Poll-Frame ein Feld aufweist, um die Energiesparstation zu informieren, wenn zwischengespeicherte Frames auf die Übertragung warten.
Zugriffspunkt (10) nach Anspruch 41, wobei die Einrichtung zum Erstellen des Weiteren eine Einrichtung zum Synchronisieren des Abfrageplans mit einer Standard 802.11 Timersynchronisierungsfunktion umfasst.
Zugriffspunkt (10) nach Anspruch 41, wobei der Abfrageplan eine Startzeit und eine Zwischenabfrageperiode aufweist, wobei die Startzeit ein Timersynchronisierungsfunktions-Timerwert ist und die Zwischenabfrageperiode ein mehrfaches Integral von Timersynchronisierungsfunktions-Zeiteinheiten ist.
Zugriffspunkt (10) nach Anspruch 41 oder 42, wobei die Einrichtung zum Erstellen des Weiteren eine Einrichtung zum Empfangen von Abfrageerfordernissen über ein Signalisierungsprotokoll umfasst.
Zugriffspunkt (10) nach Anspruch 46, wobei die Einrichtung zum Erstellen des Weiteren eine Einrichtung zum Erstellen eines Dienstplans basierend auf einem Timer-Rad (1000) umfasst, wobei das Timer-Rad (1000) Taktticken aufweist, die ein Integral einer Timersynchronisierungsfunktions-Zeiteinheit sind, wobei jedes Taktticken einen Eimer (1002, 1004, 1006, 1008) aufweist, wobei der Eimer eine verbundene Liste mit einem Eintrag für jede Station (20) aufweist, die zu dem entsprechenden Taktticken zu bedienen ist.