DE602004003684T2

DE602004003684T2 - Gerät und verfahren zum optimieren der leistungsverwaltung in einem ibss eines wlan

Info

Publication number: DE602004003684T2
Application number: DE602004003684T
Authority: DE
Inventors: Zhun Briarcliff Manor ZHONG; Sunghyun Briarcliff Manor CHOI
Original assignee: Koninklijke Philips Electronics NV
Current assignee: Pendragon Wireless LLC
Priority date: 2003-02-27
Filing date: 2004-02-23
Publication date: 2007-10-04
Anticipated expiration: 2024-02-24
Also published as: ATE348467T1; KR20050105259A; WO2004077718A2; DE602004003684D1; JP2006520136A; WO2004077718A3; EP1599974A2; EP1599974B1; US20140161012A1; US20060193296A1

Description

Die vorliegende Erfindung bezieht sich auf die Leistungsverwaltung in einem IBSS (Independent Basic Service Set)-WLAN (Wireless Local Area Network). Genauer genommen bezieht sich die vorliegende Erfindung auf die Leistungsverwaltung in einem IBSS-WLAN gemäß IEEE 802.11. Speziell bezieht sich die vorliegende Erfindung auf die Bereitstellung eines höheren Durchsatzes, um so die Leistungsausnutzung in einem IBBS-WLAN für eine gegebene ATIM (Ad-hoc Traffic Indication Message)-Fenstergröße zu optimieren.
Das drahtlose lokale Netzwerk (WLAN) wird zur beherrschenden Netzwerktechnologie. Grund für diesen Popularitätsanstieg ist die explosiv wachsende Nachfrage nach tragbaren kabellosen Vorrichtungen und Kommunikationsnetzwerken, um diese Vorrichtungen zu bedienen.
Das WLAN unterstützt zwei Arten von Netzwerken: das Infrastructure BSS und das Independent BSS (IBSS). Das Basic Service Set (BSS) ist der grundlegende Baustein eines WLAN. Jedes BSS besteht aus mindestens zwei Stationen (STAs).
Bezug nehmend auf 1a wird ein Infrastructure BSS gezeigt, in dem STAs 100 über einen zentralen Zugangspunkt (Access Point; AP) 130 kommunizieren, der den Datenverkehr 120 von der Quellen-STA 100 erhält und an die Ziel-STA 100 weiterleitet. Bezug nehmend auf 1b wird ein Independent BSS oder IBSS gezeigt (auch als Ad-hoc-Netzwerk bezeichnet), in dem jede STA 100 direkt, ohne Unterstützung eines AP, mit anderen STAs 100 kommuniziert 110. Das heißt, jede STA 100 in einem Ad-hoc-Netzwerk kann mit einer anderen STA 100 kommunizieren, wenn sie sich in gegenseitiger Funkreichweite befinden, weil in einem IBSS der gesamte Verkehr gleichberechtigt abläuft.
Zahlreiche Anwendungen eines WLAN sind für mobile, akkubetriebene Vorrichtungen gedacht. Deshalb ist die Leistungsaufnahme einer WLAN-Karte ein kritischer Faktor in der Gesamtleistungsverwaltung eines IBSS-WLAN. Beispielsweise verwendet ein WLAN gemäß der Norm IEEE 802.11 als Zugangsverfahren einen trägerüberwachten mehrfachen Zugang mit Kollisionsvermeidung (CSMA/CA; Carrier Sense Multiple Access/Collision Avoidance), bei dem das Übertragungsmedium in Ruhephasen kontinu ierlich von Stationen überwacht werden muss. Infolgedessen ist die Leistungsaufnahme in Ruhephasen nicht viel geringer als die Leistungsaufnahme im Sende- oder Empfangsbetrieb.
Gemäß der Norm IEEE 802.11, erste Ausgabe 1999, Kapitel 11.2, wird eine Leistungseinsparung in einem WLAN dadurch erzielt, dass STAs bei jeder passenden Gelegenheit in einen Energiesparbetrieb, d.h. Schlafbetrieb, wechseln können, während dem die WLAN-Karte das Medium nicht überwacht. Zu beachten ist, dass sich der Wechsel in den Energiesparbetrieb vom Ausschalten der WLAN-Karte unterscheidet, da es viel länger dauert, die ausgeschaltete WLAN-Karte wieder einzuschalten als sie aus dem Schlafbetrieb zu reaktivieren.
Hinsichtlich der Leistungsaufnahme verbraucht eine typische WLAN-Karte 1,5 W im Sendebetrieb, 1,25 W im Empfangsbetrieb, etwa 1,12 W im Leerlaufbetrieb und lediglich 0,045 W im Schlafbetrieb. Der Schlafbetrieb sorgt für wesentliche Energieeinsparungen. Obwohl im Schlafbetrieb Energie eingespart wird, sind die STAs im Schlafbetrieb jedoch völlig von vom Rest des Netzwerks isoliert. Im Schlafbetrieb können STAs Pakete weder senden noch empfangen. Dadurch entsteht ein Problem: wenn eine STA Pakete zu senden hat und sich die Ziel-STA im Schlafbetrieb befindet, „wie kann dann die Ziel-STA geweckt werden, so dass sie die Pakete empfangen kann?". Das heißt, die Herausforderung besteht darin, die Zielstation zur richtigen Zeit aufzuwecken, wenn die Quellstation Pakete senden will.
Um dieses Problem zu lösen, verwendet ein IBSS-WLAN eine Data_Alert-Nachricht sowie ein Data_Window, um die Leistungsverwaltung für das IBSS vorzunehmen. 3 veranschaulicht den Betrieb eines IBSS-WLAN. In einem vorgegebenen Intervall, bekannt als Target Beacon Transmission Time (TBTT) 330, werden alle STAs des IBSS reaktiviert und konkurrieren um das Aussenden ihres Bakensignals (Beacon) 310, weil die Beacon-Erzeugung in einem IBSS-WLAN verteilt ist. Jede STA im IBSS hat ein zum Senden zur TBTT 330 bereites Beacon 310 und konkurriert mit allen anderen STAs im IBSS darum, mit einer willkürlichen Verzögerung auf das Medium zuzugreifen. Die STA, die die Konkurrenzsituation für sich entscheidet, hebt alle anderen anstehenden Beacon-Übertragungen auf. Außer im Fall eines Beacon-Fehlers wird daher ein Beacon 310 pro Beacon-Intervall 300 gesendet.
Ein direkt nach dem Beacon auftretendes Fenster vorgegebener Länge wird als ein Data_Alert-Fenster 340 reserviert, in dem nur Data_Alert-Rahmen 350 und Quittie rungen 360 gesendet werden können. Data_Alert-Rahmen 350 sind Verkehrsankündigungen, die von Quellen-STAs verwendet werden, um Ziel-STAs darüber zu informieren, dass Datenrahmen an der Quelle zwischengespeichert sind, die darauf warten, an das Ziel gesendet zu werden. Die Data_Alert-Rahmen 350 (und ihre Quittierungen 380) lösen die Konkurrenzsituation auf, indem sie dieselben Regeln einer verteilten Koordinationsfunktion (Distributed Coordination Funktion; DCF) wie normale Datenrahmen befolgen. Data_Alert-Rahmen 350, die nicht gesendet werden können, bevor das Data_Alert-Fenster 340 endet, werden während des nächsten Beacon-Intervalls gesendet, das auf die nächste TBTT 330 folgt.
Falls eine STA, nachdem das Data_Alert-Fenster 340 vorüber ist, keine Data_Alert-Rahmen 350 375 erfolgreich sendet oder empfängt, kann sie davon ausgehen, dass es für sie während des aktuellen Beacon-Intervalls 340 keinen Verkehr gibt, und kann daher bis zur nächsten TBTT 330 wieder zurück in den Schlafmodus (Energiesparbetrieb) wechseln. Andernfalls kann eine STA mit dem Senden von Datenrahmen 365 und dem Empfangen von Quittierungen 370 beginnen oder während des gesamten Beacon-Intervalls 340 im Empfangsbetrieb bleiben, um einen Datenrahmen 385 zu empfangen und eine Quittierung 390 zu senden. Zu beachten ist, dass gemäß IEEE 802.11, Kapitel 11.2.2.1, nur die während des Data_Alert-Fensters 340 angekündigten Daten nach dem Data_Alert-Fenster 340 gesendet werden (allerdings wird in IEEE 802.11, Kapitel 11.2.2.4j, eine Ausnahme erwähnt). Aktuelle Ansätze zur Leistungsverwaltung erfordern es, dass die Größe des Data_Alert-Fensters 340 für die gesamte Dauer eines IBSS festgelegt sein muss.
Das Leistungsverwaltungsmodell bei IBSS-WLANs nach dem Stand der Technik lässt sich wie folgt zusammenfassen. Eine STA wird periodisch für eine gewisse Zeitspanne reaktiviert, während der bekanntermaßen auch alle anderen aktiviert sind. Innerhalb dieser Zeitspanne versuchen STAs ihre Ziel-STAs für das zwischengespeicherte Paket zu „buchen". Am Ende dieser Zeitspanne wechselt eine STA standardmäßig wieder in den Schlafbetrieb, es sei denn, sie hat eine Ziel-STA gebucht oder wurde während der Zeitspanne als eine Ziel-STA gebucht.
Das Leistungsverwaltungsmodell nach dem Stand der Technik hat die beiden folgenden Nachteile:

1) Nur die STAs, die explizit ihre Ziel-STAs gebucht haben, können in der Restzeit 345 des Beacon-Intervalls 300 Datenrahmen senden; und
2) eine STA muss während des gesamten Beacon-Intervalls aktiviert bleiben, sofern sie entweder eine Ziel-STA gebucht hat oder als eine Ziel-STA gebucht wurde.

Folglich besteht folgender Bedarf:

1) Von einer STA mitgehörte Informationen (Kenntnisse) dürfen verwendet werden, und
2) STAs dürfen wieder in den Schlafbetrieb wechseln, sofern sie den angekündigten Verkehr beenden.

Da STAs, wenn sie aktiviert sind, das Medium kontinuierlich überwachen, hören sie Konversationen mit, in denen Quellen-STAs Ziel-STAs „buchen". Diese mitgehören Informationen können als eine Grundlage verwendet werden, auf der eine STA aktiviert bleibt, um zwischengespeicherte Datenrahmen an eine Ziel-STA zu senden, die eine andere STA gebucht hat, weit nach dem Stand der Technik STAs, die gebucht wurden, für das gesamte Beacon-Intervall 300 aktiviert bleiben. Um jedoch den Energieverbrauch zu minimieren, sollte eine STA in den Schlafbetrieb wechseln können, wenn der gesamte angekündigte Verkehr von der STA entweder empfangen oder gesendet wurde.
Somit betrifft das Wesentliche der IBSS-WLAN-Leistungsverwaltung in dem System und Verfahren der vorliegenden Erfindung „Kenntnisse" – Kenntnisse darüber, ob die Ziel-STA aktiviert sein wird. Der von dem System und Verfahren der vorliegenden Erfindung verwendete Schlüssel zur Optimierung der IBSS-WLAN-Leistungsverwaltung liegt in der maximalen Nutzung dieser Kenntnisse. Das heißt, in dem System und Verfahren der vorliegenden Erfindung nutzen STAs diese Kenntnisse, ungeachtet dessen, wie diese Kenntnisse erlangt wurden (d.h. explizit oder implizit). Wenn in einer bevorzugten Ausführungsform eine STA daher sicher ist, dass ihre Ziel-STA aktiviert ist, sendet sie Datenrahmen an die Ziel-STA, obwohl sie die Ziel-STA nicht explizit gebucht hat.
Gemäß dem Leistungsverwaltungsmodell für ein IBSS-WLAN nach dem Stand der Technik weiß jede gebuchte STA genau, welche STAs während eines Beacon-Intervalls 300 Pakete sendet. Nachdem alle STAs, von denen die STA B Datenrahmen erwartet, ihre Datenrahmen an die STA B gesendet haben, ist es Energievergeudung, die STA B im Beacon-Intervall 300 weiterhin aktiviert zu lassen.
Gemäß der Erfindung werden ein in Anspruch 1 definiertes Verfahren zur Leistungsverwaltung und ein in Anspruch 16 definiertes Gerät zur Leistungsverwaltung geschaffen.
Das System und Verfahren der vorliegenden Erfindung mildert die beiden Nachteile der oben erwähnten IBSS-WLAN-Leistungsverwaltungsmodelle nach dem Stand der Technik, indem:

1) sie STAs erlauben, mitgehörte Informationen (Kenntnisse) zu verwenden, und
2) sie STAs erlauben, wieder in den Schlafbetrieb (Energiesparbetrieb) zu wechseln, sofern sie den angekündigten Verkehr beenden.

In der Norm IEEE 802.11 nach dem Stand der Technik ist ein Data_Alert-Fenster 340 ein Ad-hoc-Verkehrshinweismeldung (ATIM)-Fenster, und Data_Alert-Rahmen 350 sind ATIM-Rahmen. Ferner wird nur im Infratstructure-BSS ein „Weitere Daten"-Bit im Rahmenkontrollfeld des MAC-Kopfteils verwendet. Um das Problem anzugehen, dass eine STA nach dem gesamten angekündigten Verkehr in den Schlafbetrieb wechselt, verwendet eine bevorzugte Ausführungsform des Systems und Verfahrens der vorliegenden Erfindung das „Weitere Daten"-Bit im IBSS zu Leistungsverwaltungszwecken.
Folglich stellt das Gerät und Verfahren der vorliegenden Erfindung ein „Weitere Daten"-Bit bereit, das den STAs eines IBSS-WLAN gestattet, die von einer STA mitgehörten Informationen bezüglich STAs zu nutzen, die als Ziel-STAs gebucht wurden. Ein Wert 1 für das „Weitere Daten"-Bit gibt an, dass es mindestens einen weiteren Rahmen bei der Quellen-STA für dieselbe Ziel-STA gibt, während ein Wert 0 angibt, das es keine weiteren Rahmen für diese Ziel-STA von dieser Quellen-STA gibt. Wenn also mindestens ein Datenrahmen von einer nicht gebuchten STA durchkommt, bleibt die Ziel-STA aktiviert, sofern das „Weitere Daten"-Bit auf 1 gesetzt ist.
Die vorgenannten und weitere Merkmale und Vorteile der vorliegenden Erfindung werden aus den folgenden, detaillierten Beschreibungen bevorzugter Ausführungsformen deutlich, die in den begleitenden Zeichnungen dargestellt sind.
1a ein Infrastructure BSS-WLAN;
1b ein Independent BSS- oder IBSS-WLAN;
2 ein vereinfachtes Blockschaltbild jeder STA in einem bestimmten IBSS gemäß einer Ausführungsform der vorliegenden Erfindung;
3 den Leistungsverwaltungsbetrieb im IBSS gemäß einer Ausführungsform der vorliegenden Erfindung;
4 eine leere Zielliste am Anfang eines Data_Alert-Fensters;
5 die Zielliste aus 4, nachdem die Quellen-STA einen Data_Alert-Rahmen an die STA₁ gesendet und eine erfolgreiche Buchungskonversation zwischen STA₂ und STA₅ mitgehört hat;
6 die Zielliste aus 5, nachdem die Quellen-STA einen Data_Alert-Rahmen an die STA₃ gesendet hat;
7 die Zielliste aus 6, nachdem die Quellen-STA der STA₂ einen Datenrahmen mit einem auf 1 gesetzten „Weitere Daten"-Indikator gesendet hat;
8 die Zielliste aus 7, nachdem die Quellen-STA einen zur/von der STA₄ gesendeten Datenrahmen mitgehört hat;
9 eine leere Quellenliste am Anfang eines Data_Alert-Fensters;
10 die Quellenliste aus 9, nachdem die Quellen-STA eine Data_Alert-Nachricht von der STA₁₀ und STA₁₄ empfangen hat;
11 die Quellenliste aus 10, nachdem die Quellen-STA einen Datenrahmen von der STA₁₁ und STA₁₃ jeweils mit einem auf 1 gesetzten „Weitere Daten"-Indikator empfangen hat;
12 die Quellenliste aus 11, nachdem die Quellen-STA einen Datenrahmen von der STA₁₀ mit einem auf 0 gesetzten „Weitere Daten"-Indikator empfangen hat.
In der folgenden Beschreibung werden bestimmte Details wie die spezielle Architektur, Leistungsverwaltungsverfahren usw. anhand von Beispielen und nicht einschränkend beschrieben, um ein grundlegendes Verständnis von der vorliegenden Erfindung zu schaffen. Für den Fachkundigen wird es jedoch offensichtlich sein, dass die vorliegende Erfindung in anderen Ausführungsformen angewendet werden kann, die von den speziellen dargelegten Details abweichen.
In der Norm 802.11 nach dem Stand der Technik, die in der Internationalen Norm ISO/IED 8802-11, „Information Technology-Telecommunications and information exchange area networks", Ausgabe 1999, definiert ist, wird das „Weitere Daten"-Bit im Rahmenkontrollfeld des MAC-Kopfteils nur im Infrastructure BSS verwendet. In einer bevorzugten Ausführungsform verwendet das System und Verfahren der vorliegenden Erfindung das „Weitere Daten"-Bit im IBSS zur Leistungsverwaltung.
In einer bevorzugten Ausführungsform schafft die vorliegende Erfindung einen Energiesparbetrieb, in dem das „Weitere Daten"-Bit in gerichteten Rahmen vom Daten- oder Verwaltungstyp gültig ist, die von STAs eines IBSS-WLAN gesendet werden. Ein Wert 1 gibt an, dass es bei der Quellen-STA mindestens einen zusätzlich zwischengespeicherten Daten- oder Verwaltungsrahmen für dieselbe Ziel-STA gibt. Ein Wert 0 gibt an, dass es bei der Quellen-STA keinen weiteren Daten- oder Verwaltungsrahmen für dieselbe Ziel-STA gibt.
1b veranschaulicht ein repräsentatives Netzwerk, auf das Ausführungen der vorliegenden Erfindung anzuwenden sind. Wie in 1b gezeigt, kommuniziert eine Vielzahl von STAs 100 über eine drahtlose Verbindung und eine Vielzahl drahtloser Kanäle 110 miteinander, so dass der gesamte Verkehr gleichberechtigt ist. Ein Schlüsselprinzip der vorliegenden Erfindung ist es, einen Mechanismus zu schaffen, um den Energieverbrauch durch jede drahtlose STA 100 so zu optimieren, dass in jedem Beacon-Intervall 300 die maximale Anzahl von Datenrahmen 365 zwischen den STAs 100 übertragen wird, während gleichzeitig eine STA 100 entweder für das gesamte Beacon-Intervall aktiviert bleibt oder alternativ nur dann, wenn sie Rahmen zu senden und/oder zu empfangen hat, und andernfalls in einen Schlafbetrieb oder einen Energiesparbetrieb wechselt, um Energie zu sparen. Zu beachten ist, dass wenn die verbleibende Zeit 350 in einem Beacon-Intervall 300 gering ist, eine STA 100 nicht in den Schlafbetrieb wechseln darf, weil zum Reaktivieren bei der nächsten TBTT 330 mehr Energie verbraucht wird als bei einem Wechsel in den Schlafbetrieb für eine so kurze Zeit eingespart wird. Ferner ist zu beachten, dass das in 1b gezeigte IBSS-Netzwerk zu Veranschaulichungszwecken klein ist. In der Praxis umfassen die meisten Netzwerke eine größere Anzahl mobiler STAs 100.
Bezug nehmend auf die 1b und 2 kann jede STA 100 eines IBSS in einem WLAN aus 1b ein System mit einer Architektur enthalten, die im Blockschaltbild von 2 dargestellt wird. Jede STA 100 kann einen Empfänger 200, einen Demodulator 210, einen Speicher 220, eine Energiesparschaltung 230, einen Steuerungsprozessor 240, einen Zeitgeber 250, einen Modulator 260 und einen Sender 270 enthalten. Das Beispielsystem 280 aus 2 dient nur zur Beschreibung. Obwohl sich die Beschreibung auf Begriffe beziehen kann, die allgemein zur Beschreibung bestimmter mobiler STAs verwendet werden, gelten die Beschreibung und die Konzepte gleichermaßen für andere Verarbeitungssysteme, einschließlich Systeme mit einer Architektur, die der in 2 gezeigten unähnlich ist.
Im Betrieb sind der Empfänger 200 und der Sender 270 mit einer Antenne (nicht gezeigt) gekoppelt, um empfangene Signale und gewünschte Sendedaten über den Demodulator 210 bzw. den Modulator 260 umzuwandeln. Die Energiesparschaltung 230 arbeitet unter der Steuerung des Prozessors 240, um zu bestimmen, ob die STA 100 für die verbleibende Zeit 345 eines gegebenen Beacon-Intervalls 300 aktiviert bleiben oder deaktiviert (Energiesparbetrieb) werden sollte, indem festgestellt wird, ob zu sendende/empfangende Datenrahmen (1) explizit „gebucht", (2) mitgehört und implizit gebucht und (3) wie durch ein „Weitere Daten"-Bit in einer empfangenen Nachricht angekündigt wurden. Sobald ferner die STA die Entscheidung getroffen hat, in den Schlafbetrieb (Energiesparbetrieb) zu wechseln, muss die verbleibende Zeit 340 für das betreffende Beacon-Intervall 300 größer als ein vorgegebener Schwellenwert sein, oder die STA bleibt für die Dauer des Beacon-Intervalls 300 aktiviert. Die errechnete Restdauer im Beacon-Intervall 300 wird bestimmt, indem die aktuelle Zeit von der Zeit der nächsten TBTT abgezogen wird, wobei der letztere Wert im Speicher 230 gespeichert wird. Der Zeitgeber 250 dient dazu, eine deaktivierte STA zu vorgegebenen TBTTs 330 zu reaktivieren und den Steuerungsprozessor zeitlich so zu planen, dass er ein Beacon sendet, weil zur TBTT alle STAs konkurrieren, um ihre Beacons zu senden.
In einer bevorzugten Ausführungsform führt jede STA 100 eine Liste von Quellen-STA-Identifizierern, von denen sie während eines gegebenen Beacon-Intervalls 300 Pakete zu empfangen erwartet. Am Ende des Data_Alert-Fensters 340 besteht die Liste aus Identifizierern von STAs, die diese STA während des Data_Alert-Fensters 340 explizit gebucht haben. Nach dem Data_Alert-Fenster 340 fügt die STA 100 eine STA zur Liste hinzu, sofern sie nicht bereits auf der Liste ist, von der sie einen Daten- oder Verwaltungsrahmen mit dem auf 1 gesetzten „Weitere Daten"-Bit empfängt. Andererseits löscht die STA 100 eine STA aus der Liste, sofern sie sich bereits auf der Liste befindet, von der sie einen Daten- oder Verwaltungsrahmen mit dem auf 0 gesetzten „Weitere Daten"-Bit empfängt. Wenn die Liste leer ist, sieht sich die STA 100 nicht verpflichtet, für andere STAs aktiviert zu bleiben. Wenn die STA 100 selbst keine Pakete an andere STAs zu senden hat, kann sie in den Schlafbetrieb wechseln, um bei der nächsten TBTT 330 reaktiviert zu werden, vorausgesetzt, die verbleibende Zeitdauer 345 des Beacon-Intervalls 300 ist größer als ein vorgegebener Schwellenwert, weil die mit dem Betriebsartwechsel verbundene Leistungsaufnahme unter Umständen keine Energie einspart, wenn die Schlafphase zu kurz ist. Daher wechselt eine hierzu berechtigte STA nur dann in den Schlafbetrieb, wenn die erwartete Schlafzeit größer als der vorgegebene Schwellenwert ist.
Da ein drahtloses Medium ein Rundfunkmedium ist, kann jede STA 100 innerhalb eines bestimmten Bereichs den Verkehr über das Medium mithören. Daher kann STA A₁ mithören, dass STA A₂ STA A₃ während des Data_Alert-Fensters 340 gebucht hat. Solche Informationen werden in einer bevorzugten Ausführungsform verwendet, um die Leistung des gesamten IBSS zu verbessern. Je nachdem, wie sich die STAs nach dem Data_Alert-Fensters 340 verhalten, nutzt eine der beiden folgenden Ausführungsformen der Erfindung diese mitgehörten Informationen, um die Leistungsverwaltung und IBSS-Gesamtleistung zu verbessern.
1. STAs die nach dem Data_Alert-Fenster 340 aktiviert bleiben bleiben es während des gesamten Beacon-Intervalls 300, wie in der aktuellen Norm definiert. In einer bevorzugten Ausführungsform hat STA A₁, sofern STA A₁ mithört, dass STA A₂ STA A₃ im ATIM-Fenster gebucht hat, davon Kenntnis, dass sowohl STA A₂ als auch STA A₃ für das gesamte Beacon-Intervall 300 aktiviert bleiben. Daher kann STA A₁ nach dem Data_Alert-Fenster 340 für die verbleibende Zeit des Beacon-Intervalls 345 Rahmen entweder an STA A₂ oder STA A₃ senden, ohne eine von ihnen im Data_Alert-Fenster 340 explizit zu buchen, und sicher sein, dass die Ziel-STA so verfügbar ist, als wäre sie explizit gebucht worden.
Wann immer daher eine STA eine erfolgreiche Data_Alert-Konversation (ein Data_Alert-Rahmen 350 gefolgt von der entsprechenden Quittierung 360) mithört, sollte die STA ihre an einen Teilnehmer der mitgehörten Data_Alert-Konversation gerichteten, anstehenden Data_Alert-Rahmen 350, falls vorhanden, abbrechen. Dies reduziert den Verkehr von Data_Alert-Rahmen 350 und spart Energie.
Wenn eine STA lediglich die Data_Alert-Quittierung 380 mithört, sollte die STA ihren an den Absender der mitgehörten Data_Alert-Quittierung 380 gerichteten, anstehenden Data_Alert-Rahmen 350, falls vorhanden, abbrechen.
Wenn eine STA 100 lediglich einen Data_Alert-Rahmen 350 mithört, sollte die STA 100 keine Annahme hinsichtlich der Verfügbarkeit entweder der mitgehörten Quelle oder ihres vorgesehenen, während der Restdauer des Beacon-Intervalls 345 aktivierten Ziels treffen.
Im Idealfall sollte jede Ziel-STA 100 ungeachtet der Anzahl von Quellen-STAs nur einmal pro Beacon-Intervall 300 gebucht werden. Dies reduziert den Data_Alert 350-Verkehr im Data_Alert-Fenster 340 und somit die erforderliche Größe des Data_Alert-Fensters 340. Da auch das Senden der Data_Alert-Rahmen 350 Energie verbraucht, bedeutet eine Verringerung des Data_Alert 350-Verkehrs eine geringere Gesamtleistungsauf nahme. Auf der anderen Seite lässt ein kleineres Data_Alert-Fenster 340 mehr Zeit für die Datenübertragung und kann so den Durchsatz verbessern.
2. STAs die nach dem ATIM-Fenster aktiviert bleiben können nach Beendigung des gesamten angekündigten Verkehrs wieder in den Schlafbetrieb wechseln. Wenn in einer alternativen bevorzugten Ausführungsform STA A₁ mithört, dass STA A₂ STA A₃ gebucht hat, weiß STA A₁, dass sowohl STA A₂ als auch STA A₃ nach dem Data_Alert-Fenster 340 aktiviert bleiben, STA A₁ weiß jedoch nicht, wie lange STA A₂ und STA A₃ aktiviert bleiben. Ohne STA A₂ oder STA A₃ selbst explizit zu buchen, kann STA A₁ nicht garantieren, dass STA A₂ oder STA A₃ aktiviert sind, wenn sie ihnen Rahmen schickt.
Trotz der Ungewissheit ist die mitgehörte Information in dieser Ausführungsform weiterhin von Wert. Obwohl STA A₁ weiterhin sämtliche Ziel-STAs buchen möchte, mit denen sie Verkehr hat, gibt sie den Ziel-STAs Vorzug, über die sie nichts weiß, d.h. keine sie betreffende Konversation mitgehört hat, indem sie sie zuerst bucht. Sollte das Data_Alert-Fenster 340 nicht lang genug sein, lässt STA A₁, statt der bisher noch von niemandem gebuchten STA A₄, die bereits von einem anderen gebuchte STA A₃ aus. Schließlich erhält STA A₁, nachdem das Data_Alert-Fenster 340 vorüber ist, eine weitere Gelegenheit STA A₃ zu „buchen", indem sie STA A₃ einen Rahmen mit dem auf 1 gesetzten „Weitere Daten"-Bit früh genug sendet, bevor STA A₂ aufhört, alle ihre an STA A₃ gerichteten Rahmen zu senden.
Der Grundgedanke dieser Ausführungsform besteht darin, innerhalb eines begrenzten Data_Alert-Fensters 340 so viele verschiedene Ziel-STAs wie möglich zu buchen.
Nach dem Data_Alert-Fenster 340 versucht jede STA zunächst, einen Rahmen, sofern vorhanden, an jede der STAs zu senden, die von anderen gebucht wurden, aber nicht von ihr selbst. Mit dem auf 1 gesetzten „Weitere Daten"-Bit bieten diese Rahmen eine weitere Gelegenheit, die Ziele zu buchen, die die STA während des Data_Alert-Fensters 340 nicht buchen konnte. Das mindeste, worum sich eine STA kümmern muss, sind die STAs, die sie bereits während des Data_Alert-Fensters 340 gebucht hat, weil diese STAs sich verpflichtet haben und aktiviert bleiben werden, um auf jeden Fall Rahmen zu empfangen. Aus einer anderen Perspektive bietet das Zurückhalten von Verkehr zu gebuchten STAs tatsächlich eine größere Möglichkeit für andere STAs, nach dem Data_Alert-Fenster 340 mit Hilfe des „Weitere Daten"-Bits zu „buchen".
Das Senden von Rahmen an eine nicht gebuchte Ziel-STA bedeutet weiterhin, eine Gelegenheit wahrzunehmen. Eine STA sollte eine fehlgeschlagene Übertragung (oder eine bestimmte Anzahl fehlgeschlagener Übertragungen) als Hinweis darauf werten, dass die Ziel-STA nicht mehr aktiviert ist und zu ihrer nächsten Ziel-STA weitergehen.
Implementierung unter Verwendung von Listen von Quellen- und Ziel-STAs
Eine bevorzugte Ausführungsform einer Implementierung der vorliegenden Erfindung verwendet zwei Listen: eine Quellen-STA-Liste und eine Ziel-STA-Liste.
1. Von einer gegebenen STA geführte Zielliste mit STAs
Zu Beginn des Data_Alert-Fensters 340 legt eine gegebene STA eine Liste derjenigen Ziel-STAs fest, für die sie während des Beacon-Intervalls zu sendende Rahmen zwischenspeichert. Angenommen, die fünf in 4 gezeigten STAs bilden die anfängliche, von einer gegebenen STA geführte Zielliste von STAs. Die gegebene STA möchte möglichst jede der STAs auf der Zielliste buchen. Zu beachten ist, dass in diesem Moment (zu Beginn des Data_Alert-Fensters 340) nichts passiert ist, d.h. jeder den STAs in der Zielliste entsprechende Eintrag ist leer, wie in 4 veranschaulicht. Wann immer die gegebene STA anschließend einen Data_Alert-Rahmen erfolgreich an eine STA auf der Zielliste sendet, markiert sie die Ziel-STA in der Zielliste als „gebucht".
Wann immer die gegebene STA in der Zwischenzeit eine Data_Alert-Konversation zwischen zwei anderen STAs mithört, markiert die gegebene STA die entsprechenden STAs in der Zielliste als „Von anderen gebucht". Innerhalb des Data_Alert-Fensters 340 wählt die gegebene STA immer eine nicht markierte Ziel-STA aus der Zielliste, um ein Data_Alert an sie zu schicken, so lange sich eine solche Ziel-STA in der Zielliste befindet. Erst nachdem alle Ziel-STAs in der Zielliste entweder als „Gebucht" oder „Von anderen gebucht" markiert sind, kann die STA wählen, einen Data_Alert-Rahmen an Ziel-STAs zu senden, die als „Von anderen gebucht" markiert sind.
Angenommen, die gegebene STA schickt einen Data_Alert-Rahmen an die Ziel-STA₁, um STA₁ für mindestens einen von der gegebenen STA zwischengespeicherten Rahmen als eine Ziel-STA zu „buchen", und hört eine Konversation zwischen STA₂ und STA₅ mit. Die daraus resultierende Zielliste ist in 5 dargestellt. Dann schickt die gegebene STA einen Data_Alert-Rahmen an STA₃, um STA₃ als eine Ziel-STA zu „buchen", und markiert STA₃ in der Zielliste als „gebucht", wie in 6 dargestellt.
Nun sei angenommen, dass das Data_Alert-Fenster 340 endet, wenn die Zielliste wie in 6 dargestellt aussieht. Diese Zielliste wird nun von der gegebenen STA benutzt, um zu entscheiden, an welche Ziel-STAs Datenrahmen zu senden sind und in welcher Reihenfolge. Zuerst sendet die gegebene STA Datenrahmen an die in der Zielliste als „Von anderen gebucht" markierten Ziel-STAs. Falls es mehr als einen für eine Ziel-STA zwischengespeicherten Rahmen gibt, wird das „Weitere Daten"-Bit des Datenrahmens auf 1 gesetzt; siehe 7. Nachdem der Datenrahmen erfolgreich gesendet wurde, ändert die gegebene STA den Eintrag in der Zielliste von „Von anderen gebucht" in „Gebucht", weil die Ziel-STA auf das „Weitere Daten"-Bit geschaut hat, welches auf 1 gesetzt war, und aktiviert bleibt, um weitere Datenrahmen von der gegebenen STA zu empfangen. Die gegebene STA fährt auf diese Weise für alle mit „Von anderen gebucht" markieren Ziel-STAs in der Zielliste fort, bevor sie irgendwelche Datenrahmen an die mit „Gebucht" markierten STAs in der Zielliste sendet. Diese Reihenfolge beim Senden von Datenrahmen soll der gegebenen STA eine weitere Gelegenheit geben, Ziel-STAs zu „buchen" und die Erfolgswahrscheinlichkeit verbessern.
Falls die gegebene STA zwischenzeitlich Datenrahmen zu/von einer nicht markierten STA mithört, d.h. STA₄ in der Zielliste, muss die gegebene STA STA₄ als „Von anderen gebucht" markieren; siehe 8. Andernfalls darf die gegebene STA nicht versuchen, einen DATEN-Rahmen an nicht markierte STAs in der Zielliste zu senden, da sich die nicht markierten STAs sehr wahrscheinlich im Schlafbetrieb befinden, weil die nicht markierten STAs vermutlich keine Data_Alert-Rahmen empfangen haben.
Sobald alle STAs in ihrer Zielliste „gebucht" sind, kann die gegebene STA Datenrahmen in beliebiger Reihenfolge senden.
2. Von einer gegebenen STA geführte Quellenliste mit STAs
Diese Quellenliste enthält STAs, von denen die gegebene STA eine Nachricht erhalten hat, d.h. „den Buchungsauftrag". Im folgenden Beispiel dienen STA₁₀ bis STA₁₅ zur Vereinfachung der Darstellung, wobei die beiden Listen jedoch einander definitiv nicht ausschließen.
Anders als die Zielliste ist die Quellenliste zu Beginn eines Data_Alert-Fensters 340 leer, um damit anzufangen, siehe 9, und es ist keine Markierung für die Quellenliste erforderlich. Innerhalb des Data_Alert-Fensters 340 fügt die gegebene STA eine Quellen-STA als Quellen-STA zur Quellenliste hinzu, wenn sie einen Data_Alert-Rahmen von der Quellen-STA erhält; siehe 10.
Nach dem Ende des Data_Alert-Fensters 340 fügt die gegebene STA eine Quellen-STA zur Quellenliste hinzu, wenn sie von der Quellen-STA einen Datenrahmen mit einem auf 1 gesetzten „Weitere Daten"-Bit erhält und sich die Quellen-STA nicht bereits auf der Quellenliste befindet; siehe 11. Die gegebene STA löscht eine Quellen-STA aus ihrer Quellenliste, wenn die gegebene STA von der Quellen-STA einen Datenrahmen mit einem auf 0 gesetzten „Weitere Daten"-Bit erhält; siehe 12.
Sobald die Quellenliste leer ist, kann die gegebene STA davon ausgehen, dass keine weitere STA während des aktuellen Beacon-Intervalls 300 Rahmen an die gegebene STA senden wird. Wenn die gegebene STA anschließend keine weiteren Datenrahmen an andere STAs zu senden hat, kann die gegebene STA wieder in den Schlafbetrieb wechseln, falls die verbleibende Zeit 350 im Beacon-Intervall größer als ein vorgegebener Schwellenwert ist.
Nun Bezug nehmend auf 3 ist eine ATIM des IEEE 802.11 IBSS-WLAN im Allgemeinen ein Data_Alert-Fenster 340 von einer bekannten und festen Länge, so dass während des Data_Alert/ATIM-Fensters 340 jede STA 100 eine andere STA 100 des IBSS alarmieren kann, dass sie Daten für sie hat, indem sie dieser STA einen Data_Alert/ATIM-Rahmen 350 sendet. Das System und Verfahren der vorliegenden Erfindung gilt für IEEE 802.11 IBSS-WLANs zum Zwecke der Leistungsverwaltung und eines erhöhten Durchsatzes.
Wie aus dem Vorhergehenden ersichtlich ist, können STAs eines IBSS-WLANs eine nahezu optimale Leistungsnutzung bei einem gleichzeitig erhöhten Durchsatz für eine vorgegebene, feste Größe des Data_Alert-Fensters erzielen, indem sie mitgehörte Informationen gemäß dem System und Verfahren der vorliegenden Erfindung nutzen, das auf IEEE 802.11 IBSS-WLANs anwendbar ist.
Obwohl die vorliegende Erfindung in Verbindung damit beschrieben wurde, was derzeit als bestes Verfahren für die Leistungsverwaltung in einem IBSS-WLAN betrachtet wird, indem man in Konversationen zwischen anderen STAs mitgehörte Informationen nutzt, nämlich diese mitgehörten Informationen verwendet, um während des Beacon-Intervalls Datenrahmen von einer Quellen-STA an Ziel-STAs zu senden, ohne die Ziel-STAs explizit zu buchen, um dadurch die Bandbreitennutzung zu reduzieren, indem keine Data_Alerts und deren Quittierungen gesendet werden müssen, versteht es sich, dass die Erfindung nicht auf die dargelegten Ausführungsformen beschränkt ist. Text in der Zeichnung Figur 3

ACK Quittierung

frame Rahmen

Claims

Verfahren zur Leistungsverwaltung durch eine drahtlose Station [STA] (100) eines Netzwerks mit einer Vielzahl von STAs, wobei jede aus der genannten Vielzahl von STAs mindestens entweder eine Quellen-STA oder eine Ziel-STA sein kann, wobei die Quellen-STA und die Ziel-STA direkt kommunizieren, und das Verfahren folgende Schritte umfasst: (a) Buchen einer ersten Ziel-STA durch eine erste Quellen-STA, wenn es mindestens einen von der ersten Quellen-STA zwischengespeicherten Datenrahmen für die Lieferung an die erste Ziel-STA gibt; dadurch gekennzeichnet, dass das Verfahren, nachdem die Buchung beendet ist, die Ausführung folgender Schritte umfasst: (b) Senden eines von der ersten Quellen-STA zwischengespeicherten Datenrahmens (365) an eine zweite Ziel-STA, die durch eine zweite Quellen-STA aus der genannten Vielzahl von STAs gebucht wurde. (c) falls nur zwischengespeicherte Datenrahmen (365) für gebuchte Ziel-STAs von der ersten Quellen-STA zu senden bleiben, Senden eines von der ersten Quellen-STA zwischengespeicherten Datenrahmens an die gebuchten Ziel-STAs, (d) Empfangen eines von einer anderen STA aus der genannten Vielzahl von STAs gesendeten Datenrahmens, der von der genannten anderen STA zwischengespeichert war, (e) Der ersten Quellen-STA gestatten, im Niedrigenergiebetrieb zu schlafen, wenn die erste Quellen-STA keinen Datenrahmen zu senden oder zu empfangen hat.
Verfahren nach Anspruch 1, wobei der genannte Buchungsschritt weiterhin folgende Schritte umfasst: (a.1) explizites Buchen der ersten Ziel-STA als „gebucht", wenn die genannte Ziel-STA noch von keiner Quellen-STA gebucht wurde; (a.2) implizites Buchen einer nicht gebuchten Ziel-STA als „Von anderen gebucht", falls in einer aus der Gruppe ausgewählten Konversation bestehend aus einer Bu chungsquittierung durch eine Ziel-STA oder einer erfolgreichen Buchungskonversation zwischen einer Quellen-STA und einer Ziel-STA mitgehört wurde; und (a.3) implizites Buchen einer nicht gebuchten Quellen-STA als „Von anderen gebucht", falls in einer erfolgreichen Buchungskonversation zwischen einer Quellen-STA und Ziel-STA mitgehört.
Verfahren nach Anspruch 2, wobei der genannte Buchungsschritt weiterhin folgende Schritte umfasst: (a.4) explizites Buchen jeglicher implizit gebuchten STA, falls alle Ziel-STAs von einer Quellen-STA gebucht wurden, für die die Quellen-STA mindestens einen Datenrahmen (365) zwischengespeichert hat.
Verfahren nach Anspruch 3, das weiterhin folgende Schritte umfasst: (f) implizites Buchen einer noch nicht von einer Quellen-STA gebuchten Ziel-STA als „Von anderen gebucht" bei einer mitgehörten Datenrahmenübertragung zwischen einer Quellen-STA und einer Ziel-STA.
Verfahren nach Anspruch 4, wobei: der genannte Sendeschritt (b) weiterhin folgende Schritte umfasst: (b.1) Setzen eines „Weitere Daten"-Bits in dem Datenrahmen auf 1 oder 0, jeweils darauf basierend, ob mehr als ein Datenrahmen (365) für die Ziel-STA zwischengespeichert ist oder nicht, und (b.2) explizites Buchen der Ziel-STA als „gebucht", falls mehr als ein Datenrahmen für die Ziel-STA zwischengespeichert ist; und der genannte Empfangsschritt (d) weiterhin folgende Schritte umfasst: (d.1) Aktiviert-bleiben, bis alle Datenrahmen für jede der genannten expliziten und impliziten Buchungen von STAs als eine Ziel-STA empfangen worden sind.
Verfahren nach Anspruch 5, das weiterhin folgende Schritte umfasst: (g) Aktivieren aller STAs aus der genannten Vielzahl von STAs zu einer periodischen, vorgegebenen Zielbakenübertragungszeit (Target Beacon Transmission Time, [TBTT] (330)); (h) Ausführen des genannten Verfahrens in einer Zeitperiode fester Länge nach der genannten periodischen TBTT, genannt Beacon-Intervall (330), umfassend ein Data_Alert-Fenster (340) fester Länge, unmittelbar gefolgt von einer Restperiode (345) fester Länge: (i) Ausführen des genannten Buchungsschritts (a) während des genannten Data_Alert-Fensters, wobei der genannte explizite Buchungsschritt (a.1) weiterhin den Schritt (a1.1) des Sendens eines Data_Alert-Rahmens (350) durch die Quellen-STA zur Ziel-STA umfasst; und (j) Ausführen der Schritte (b)–(f) während der genannten Restperiode.
Verfahren nach Anspruch 6, wobei der genannte Schlafschritt (e) weiterhin den Schritt umfasst, zunächst folgende Schritte auszuführen: (e.1) Ermitteln, ob eine Zeitdauer bis zur nächsten TBTT (330) größer als ein Schwellenwert ist; und (e.2) Aktiviert-bleiben bis zur nächsten TBTT, falls die genannte Zeitdauer nicht größer als der genannte Schwellenwert ist.
Verfahren nach Anspruch 2, das weiterhin folgende Schritte umfasst: (g) Konkurrieren aller STAs aus der genannten Vielzahl von STAs, um zu einer periodischen, vorgegebenen Zielbakenübertragungszeit [TBTT] (330) ein Beacon (310) zu senden; (h) Ausführen des genannten Verfahrens in einer Zeitperiode fester Länge nach der genannten periodischen TBTT, genannt ein Beacon-Intervall (300), umfassend ein Data_Alert-Fenster (340) fester Länge gefolgt von einer Restperiode (345) fester Länge; (i) Ausführen des genannten Buchungsschritts (a) während des genannten Data_Alert-Fensters, wobei der genannte explizite Buchungsschritt (a.1) weiterhin den Schritt (a.1.1) des Sendens eines Data_Alert-Rahmens (350) durch die Quellen-STA zur Ziel-STA umfasst; und (j) Ausführen der Schritte (a)–(d) während der genannten Restperiode.
Verfahren nach Anspruch 2, das weiterhin folgende Schritte umfasst: (g) Aktivieren aller STAs aus der genannten Vielzahl von STAs zu einer periodischen, vorgegebenen Zielbakenübertragungszeit [TBTT] (330); (h) Ausführen des genannten Verfahrens in einer Zeitperiode fester Länge nach der genannten periodischen TBTT, genannt ein Beacon-Intervall (300), umfassend ein Data_Alert-Fenster (340) fester Länge gefolgt von einer Restperiode (345) fester Länge; (i) Ausführen des genannten Buchungsschritts (a) während des genannten Data_Alert-Fensters, wobei der genannte explizite Buchungsschritt (a.1) weiterhin den Schritt (a.1.1) des Sendens eines Data_Alert-Rahmens (350) durch die Quellen-STA zur Ziel-STA umfasst; und (j) Ausführen der Schritte (a)–(e) während der genannten Restperiode.
Verfahren nach Anspruch 9, wobei der genannte Schlafschritt (e) weiterhin den Schritt umfasst, zunächst folgende Schritte auszuführen: (e.1) Ermitteln, ob eine Zeitdauer bis zur nächsten TBTT (330) größer als ein Schwellenwert ist; und (e.2) Aktiviert-bleiben bis zur nächsten TBTT, falls die genannte Zeitdauer nicht größer als der genannte Schwellenwert ist.
Verfahren nach Anspruch 1, wobei das genannte Netzwerk ein Independent Basic Service Set [IBSS] Wireless Local Network [WLAN] ist.
Verfahren nach Anspruch 11, wobei das genannte Netzwerk ein Beacon-Intervall bestehend aus einem Ad-hoc-Verkehrshinweismeldung (ATIM)-Fenster gefolgt von einem Datenrahmenübertragungsfenster hat, wobei: Schritt (a) aus Anspruch 1 im genannten ATIM-Fenster ausgeführt wird; und die Schritte (b)–(d) aus Anspruch 1 im genannten Datenrahmenübertragungsfenster ausgeführt werden.
Verfahren nach Anspruch 5, wobei: der Buchungsschritt (a) weiterhin folgende Schritte umfasst: (a.5) Eingeben der Ziel-STA in eine Zielliste (400) durch die Quellen-STA, und (a.6) Eingeben der Quellen-STA in eine Quellenliste (900) durch die Ziel-STA; der explizite Buchungsschritt (a.1) weiterhin folgenden Schritt umfasst: (a.1.1) Eingeben von „gebucht" für die Ziel-STA in die Zielliste; der implizite Buchungsschritt (a.2) weiterhin folgenden Schritt umfasst: (a.2.1) Eingeben von „Von anderen gebucht" für die Ziel-STA in die Zielliste; der Empfangsschritt (d) weiterhin folgende Schritte umfasst: (d.2) Löschen einer Quellen-STA aus der Quellenliste, falls das genannte „Weitere Daten"-Bit des empfangenen Datenrahmens (365) Null ist, und der genannte Aktiviert-bleiben-Schritt (d.1) weiterhin umfasst: (d.1.1) den Schritt des Aktiviert-bleibens, falls die genannte Quellenliste nicht leer ist.
Verfahren nach Anspruch 13, das weiterhin folgende Schritte umfasst: (g) Aktivieren aller STAs aus der genannten Vielzahl von STAs zu einer periodischen, vorgegebenen Zielbakenübertragungszeit (Target Beacon Transmission Time, [TBTT] (330)); (h) Ausführen des genannten Verfahrens in einer Zeitperiode fester Länger nach der genannten periodischen TBTT, genannt Beacon-Intervall (330), umfassend ein Data_Alert-Fenster (340) fester Länge, unmittelbar gefolgt von einer Restperiode (345) fester Länge: (i) Ausführen des genannten Buchungsschritts (a) während des genannten Data_Alert-Fensters, wobei der genannte explizite Buchungsschritt (a.1) weiterhin den Schritt (a1.1) des Sendens eines Data_Alert-Rahmens (350) durch die Quellen-STA zur Ziel-STA umfasst; und (j) Ausführen der Schritte (b)–(f) während der genannten Restperiode.
Verfahren nach Anspruch 14, wobei der genannte Schlafschritt (e) weiterhin den Schritt umfasst, zunächst folgende Schritte auszuführen: (e.1) Ermitteln, ob eine Zeitdauer bis zur nächsten TBTT (330) größer als ein Schwellenwert ist; und (e.2) Aktiviert-bleiben bis zur nächsten TBTT, falls die genannte Zeitdauer nicht größer als der genannte Schwellenwert ist.
Gerät zur Leistungsverwaltung in einem Netzwerk mit einer Vielzahl von drahtlosen Stationen [STAs] (100), von denen jede mindestens entweder eine Quellen-STA oder eine Ziel-STA sein kann, umfassend: eine Steuerungskomponente (280) einer STA aus der genannten Vielzahl von STAs, wobei die genannte Steuerungskomponente für die direkte Kommunikation zwischen der Quellen-STA und der Ziel-STA konfiguriert ist, um: (a) die STA periodisch zu einer vorgegebenen Zielbakenübertragungszeit [TBTT] (330) zu aktivieren; wenn die STA aktiviert ist und nach der vorgegebenen TBTT: (b) Identifizieren der STA als eine erste Quellen-STA und Buchen einer ersten Ziel-STA, die nicht als von einer zweiten Quellen-STA aus der Vielzahl von STAs gebucht bekannt ist, wenn es mindestens einen von der ersten Quellen-STA zwischengespeicherten Datenrahmen (365) für die Lieferung zur ersten Ziel-STA gibt; dadurch gekennzeichnet, dass die Steuerungskomponente weiterhin dafür konfiguriert ist, (c) wenn eine vorgegebene Buchungszeit beendet ist und während eines unmittelbar folgenden Übertragungsfensters (345), (i) einen von der ersten Quellen-STA zwischengespeicherten Datenrahmen an eine zweite Ziel-STA zu senden, die von einer anderen STA aus der Vielzahl von STAs gebucht wurde; (ii) einen von der ersten Quellen-STA zwischengespeicherten Datenrahmen an die gebuchte Ziel-STA zu senden, wenn nur zwischengespeicherte Datenrahmen für die gebuchten Ziel-STAs durch die erste Quellen-STA zu senden verbleiben: (iii) einen von einer anderen Quellen-STA aus der genannten Vielzahl von STAs gesendeten Datenrahmen zu empfangen, der der genannten anderen STA zwischengespeichert war; und (iv) die erste Quellen-STA in den Schlafbetrieb zu versetzen, wenn die erste Quellen-STA keine zu sendenden oder zu empfangenden Datenrahmen hat.
Gerät nach Anspruch 16, wobei: die Steuerungskomponente (280) dafür konfiguriert ist, beim Senden eines Datenrahmens (365) einen „Weitere Daten"-Indikator auf 1 zu setzen, falls mehr als ein Datenrahmen durch die erste Quellen-STA für eine Ziel-STA zwischengespeichert wird, oder auf 0, falls es nur einen gibt; und die Steuerungskomponente dafür konfiguriert ist, die Ziel-STA aktiviert zu halten, um mehr als einen Datenrahmen zu empfangen, als wenn die Quellen-STA die Ziel-STA für mehr als einen Datenrahmen gebucht hatte.
Gerät nach Anspruch 17, wobei die genannte Steuerungskomponente (280) weiterhin dafür konfiguriert ist: eine Quellenliste (900) und eine Zielliste (400) mit Quellen-STAs und Ziel-STAs zu führen, wobei die genannte Zielliste entsprechend den Vermerk „gebucht" und „Von anderen gebucht" hat, wenn die STA eine Ziel-STA in der genannten Zielliste gebucht hat oder eine andere STA die aufgeführte STA als eine Ziel-STA gebucht hat; eine Quellen-STA aus der Quellenliste zu löschen, wenn das genannte „Weitere Daten"-Bit 0 ist; und die STA aktiviert zu halten, wenn die genannte Quellenliste nicht leer ist.
Gerät nach Anspruch 18, weiterhin umfassend einen Speicher (220), wobei die genannte Quellenliste (900) und Zielliste (400) von der genannten Steuerungskomponente (280) geführt werden.
Gerät nach Anspruch 18, wobei: bei einer mitgehörten Buchungskonversation zwischen einer Quellen-STA und einer Ziel-STA die Steuerungskomponente (280) dafür konfiguriert ist, mindestens entweder die Quellen-STA oder die Ziel-STA in der Zielliste (400) mit dem Vermerk „Von anderen gebucht" zu versehen; bei einer mitgehörten Datenrahmenübertragung (365) zwischen einer Quellen-STA und einer Ziel-STA die Steuerungskomponente (280) dafür konfiguriert ist, mindestens entweder die Quellen-STA oder die Ziel-STA in der Zielliste (400) mit dem Vermerk „Von anderen gebucht" zu versehen.
Gerät nach Anspruch 16, wobei: das genannte Netzwerk ein Independent Basic Service Set [IBSS] Wireless Local Network [WLAN] ist; das genannte vorgegebene Buchungsintervall Intervall ein Ad-hoc-Verkehrshinweismeldung (ATIM)-Fenster (340) ist; das genannte vorgegebene Buchungsintervall und das genannte unmittelbar folgende Übertragungsfenster ein Beacon-Intervall (300) sind; und eine Ziel-STA von einer Quellen-STA gebucht wird, die der Ziel-STA einen ATIM-Rahmen (350) sendet.