DE60027281T2

DE60027281T2 - Asynchroner reservierungs-orientierter Mehrfachzugriff für drahtlose Netze

Info

Publication number: DE60027281T2
Application number: DE60027281T
Authority: DE
Inventors: Subramanian Concord RAMANATHAN
Original assignee: Verizon Corporate Services Group Inc
Current assignee: Verizon Corporate Services Group Inc
Priority date: 1999-03-02
Filing date: 2000-02-24
Publication date: 2007-01-11
Anticipated expiration: 2020-02-25
Also published as: DE60027281D1; PT1163817E; DK1163817T3; ES2263461T3; EP1163817A1; WO2000052950A1; AU3705700A; ATE323386T1; EP1163817A4; CA2371892C; EP1163817B1; CA2371892A1; US6577613B1

Description

Technisches Gebiet
Die vorliegende Erfindung betrifft ein Verfahren und Vorrichtungen zum Reservieren von Zugriff auf Bandbreite in einem Übertragungskanal in einem Netzwerk. Insbesondere betrifft die Erfindung Verfahren und Vorrichtungen zum Reservieren von Zugriff auf Bandbreite in einem Übertragungskanal in einem drahtlosen Netz unter Anwendung asynchroner Nachrichtenaustauschvorgänge.
Hintergrundtechnik
Da größere Anforderungen an die Netzwerktechnologie gestellt werden, werden Netzwerkanwendungen bald die Reservierung von Bandbreite für nahtlose Übertragungsvorgänge über einen Übertragungskanal erfordern. Jede Art von Netzwerkanwendung, die große Mengen an Bandbreite erfordert, ist ein Kandidat für die Reservierung von Bandbreite. Natürlich sind der wahrscheinlichste Typ von Netzwerkanwendungen, die reservierte Bandbreite erfordern, Multimediaanwendungen. Beispiele von Multimediaanwendungen umfassen Paketsprachübertragung und Videokonferenzen. Außerdem kann jede Netzwerkanwendung, die Echtzeit-Nachrichtenübertragungsvorgänge enthält, reservierte Bandbreite erfordern.
Um eine Reservierung von Bandbreite für Multimedia- oder andere Bandbreiten-abhängige Netzwerkanwendungen bereitzustellen, ist eine bestimmte Vorgehensweise zur Reservierung von Zugriff auf einem Übertragungskanal erforderlich, wobei die Reservierung der Betriebsphase verändert werden kann. Diese Fähigkeit während der Betriebsphase Änderungen zu akzeptieren ist als "Bedarfs-, Wunsch"-Zuteilung ("on-demand, as-desired" allocation) bekannt. Ohne diese Fähigkeit würde die Bearbeitung einer Reservierung von Zugriff während Kommunikationen mit hoher Bandbreite/geringer Verzögerung durch anderen Verkehr, wie z.B. die Übertragung einer großen Datei behindert werden. Insbesondere wird für drahtlose lokale Netze, zellulare Netzwerke und Ad-hoc-Netzwerke der Bedarf für einen reservierten Zugriff auf Bandbreite in Übertragungskanälen auf einer Bedarfs- oder Wunschbasis besonders wichtig.
Herkömmliche Mechanismen zum Erzeugen von Zugriff auf einen Übertragungskanal beruhten tendenziell auf dem Rahmen fester oder Bedarfszuweisungen unter Verwendung eines Zeitmultiplexzugriffs (TDMA). Einige von den üblicheren TDMA-basierenden Verfahren zur Reservierung von Zugriff beinhalten eine prioritätsorientierte Bedarfszuweisung (PODA – priority-oriented demand assignment) Teilkanalreservierungs-Mehrfachzugriff (SRMA – split channel reservation multiple access), welche komplexe, synchrone Techniken verwenden. Jedoch erlauben die TDMA-basierenden Verfahren keine Reservierung von Zugriff auf Bandbreite über einen Übertragungskanal in einer asynchronen Weise.
Ein weiterer herkömmlicher Mechanismus ist der Codemultiplexzugriff (CDMA – code multiplex multiple access), welcher eine digitale Spreizspektrum-Modulationstechnik verwendet. Jedoch sehen CDMA-basierende Verfahren nicht ohne weiteres eine Veränderung der zugeordneten Codemenge vor, welche für reservierten Zugriff erforderlich ist.
Auch ein weiterer herkömmlicher Mechanismus ist Frequenzmultiplex-Mehrfachzugriff (FDMA – frequency division multiple access), welcher die Zuordnung eines Frequenzbandes für einen Benutzer bereitstellt. Jedoch erlauben FDMA-basierende Verfahren keine Bedarfs- oder Wunschzuweisung.
Aus den oben angegebenen Gründen sind CDMA-basierende Verfahren und FDMA-basierende Verfahren nicht für reservierten Zugriff geeignet. Ferner gibt es auch Probleme mit den TDMA-basierenden Verfahren. Da jedoch die TDMA-basierenden Verfahren die am häufigsten angewendeten Mechanismen zur Erzeugung von Zugriff auf einen Übertragungskanal sind, sollte angemerkt werden, dass TDMA-basierende Verfahren ebenfalls für reservierten Zugriff auf der Basis mehrerer bestimmter Nachteile und Unzulänglichkeiten unerwünscht sind.
Erstens sind TDMA-basierende Verfahren für einen Bündel-Netzwerkverkehr ungeeignet, da die späte Ankunft eines Datenpaketes zu dem Verlust des zugeordneten Zeitschlitzes, einer Situation, die sehr häufig im Bündel-Netzwerkverkehr auftritt, führt.
Demzufolge führt diese Aktion zur Unmöglichkeit, einen Zugriff zu garantieren oder zu reservieren.
Zweitens sind die TDMA-basierenden Verfahren ebenfalls aufgrund einer ineffizienten Zuweisung von Ressourcen unzureichend. Um die Möglichkeit eines Systemausfalls zu bewältigen, hält ein TDMA-basierendes Verfahren häufig übermäßig viele verfügbare Ressourcen bereit, um Ausfälle aufgrund eines Bündel-Netzwerkverkehrs zu meiden. Diese Ausfallmöglichkeit erhöht die Komplexität, die Kosten und den Zusatzaufwand für Systeme unter Verwendung TDMA-basierender Verfahren. Ferner beruht einer der Hauptgründe, dass TDMA-Verfahren so ineffizient sind, darauf, dass die Synchronisation zwischen den Knoten erheblich zusätzliche Zeit erfordert.
Drittens sind die TDMA-basierenden Verfahren insbesondere ungeeignet, da sie derzeit nicht mit dem IEEE E 802.11 Standard kompatibel sind. Der IEEE E 802.11 Standard ist der üblichste Standard für drahtlose lokale Netze (drahtlose LANs) erstellt von dem Institute of Electrical and Electronic Engineers (IEEE E) werden. Der IEEE E 802.11 Standard spezifiziert für drahtlose LANs eine "Luft"-Schnittstelle zwischen einem drahtlosen Client und einer Basisstation, sowie zwischen drahtlosen Clients. Nach dem ersten Konzept in 1990 wurde der IEEE 802.11 Standard sechs Bearbeitungen unterzogen, und die letzte Überarbeitung wurde am 26. Juni 1997 genehmigt. Nachdem nun der IEEE 802.11 Standard abgeschlossen worden ist, wird die Inkompatibilität der TDMA-basierenden Verfahren mit diesem Standard noch deutlicher.
Viertens sind die TDMA-basierenden Verfahren ebenfalls besonders ungeeignet, da sie schwierig mit Ad-hoc-Netzwerken zu implementieren sind. Ein Ad-hoc-Netzwerk besitzt keine Basisstation, und diese Besonderheit addiert sich zu der Schwierigkeit der Verwendung von TDMA-Verfahren mit diesen Netzwerken. Dieses beruht darauf, weil TDMA-basierende Verfahren eine Synchronisation erfordern, und ohne eine Basisstation eine Synchronisation extrem schwierig ist. Dieses ist einer der wichtigsten Nachteile der TDMA-Verfahren, wenn sie mit Ad-hoc-Netzwerken verwendet werden.
EP-A-0 658 999 offenbart ein Bandbreitenreservierungs- und Rufzulassungsverfahren auf der Basis einer RTS/CTS-Verständigung (RTS/CTS-Handshake) vor der Übertragung eines Datenpaketes an einen Server.
Aus den vorgenannten Gründen reflektieren die derzeitigen Systeme und Vorgehensweise eine nicht zufriedenstellende Entwicklung von Systemen und Vorgehensweisen zur Erzeugung von Zugriff auf einen Übertragungskanal in einem Netzwerk. Demzufolge besteht ein Bedarf für ein Verfahren, die tatsächliche Reservierung von Zugriff auf Bandbreite in einem Übertragungskanal in einem Netzwerk in einer Bedarfs- oder Wunschweise bereitzustellen. Zusätzlich besteht auch ein Bedarf zur Reservierung von Zugriff auf Bandbreite in einem Übertragungskanal über asynchrone Verfahren.
Diese Aufgabe wird durch den Gegenstand der unabhängigen Ansprüche gelöst. Bevorzugte Ausführungsformen sind Gegenstand der abhängigen Ansprüche.
Zusätzliche Aspekte der Erfindung werden durch die beigefügten Ansprüche offenbart und definiert. Es dürfte sich verstehen, dass die vorstehende allgemeine Beschreibung und die nachfolgende detaillierte Beschreibung exemplarisch und erläuternd sind und eine weitere Erläuterung der beanspruchten Erfindung bereitstellen sollen.
Kurzbeschreibung der Zeichnungen
In den Zeichnungen ist bzw. sind:
1 eine Darstellung eines exemplarischen drahtlosen Netzwerkes zum Implementieren einer mit der vorliegenden Erfindung konsistenten Ausführungsform;
2 eine Darstellung eines Server- und Client-Endgerätes zum Implementieren einer mit der vorliegenden Erfindung konsistenten Ausführungsform;
3A ein Zeitdiagramm, das eine Übertragung zum Reservieren von Zugriff auf Bandbreite in einem Übertragungskanal in einem drahtlosen Netzwerk darstellt;
3B eine Darstellung einer Reservierungsanforderung zum Senden eines Signals, das mit einer Ausführungsform der Erfindung konsistent ist;
3C eine Darstellung einer Reservierungsanforderung zum Senden eines Signals, das mit einer weiteren Ausführungsform der Erfindung konsistent ist;
3D eine Darstellung einer modifizierten Anforderung zum Senden eines Signals, das mit einer Ausführungsform der Erfindung konsistent ist;
4A–4B Flussdiagramme, welche die Reservierung eines Zugriffs auf einen Übertragungskanal in einem drahtlosen Netzwerk darstellen;
5 ein Zustandsdiagramm, das darstellt, wie ein Client einen Zugriff auf Bandbreite in einem Übertragungskanal in einem drahtlosen Netzwerk reserviert;
6 ein Zustandsdiagramm, das darstellt, wie ein Server eine Reservierungsanforderung für Zugriff auf Bandbreite in einem Übertragungskanal in einem drahtlosen Netzwerk verarbeitet; und
7 ein Zustandsdiagramm, das darstellt, wie ein Server eine Genehmigungsanforderung zum Reservieren von Zugriff auf Bandbreite in einem Übertragungskanal in einem drahtlosen Netzwerk verarbeitet.
Beste Ausführungsart der Erfindung
Einführung
Eine Ausführungsform der Erfindung gemäß Offenbarung hierin stellt einen garantierten Zugriff auf Bandbreite in einem Übertragungskanal in einem drahtlosen Netzwerk unter Anwendung einer asynchronen Vorgehensweise in einer Bedarfs-, Wunschweise bereit. Demzufolge vermeidet die Ausführungsform die Ineffizienzen und Unzulänglichkeiten der derzeitigen Systeme und Verfahren, welche hauptsächlich TDMA-basierende Verfahren verwenden und auf einer Zeitsynchronisation und/oder Code- oder Frequenzaufteilung beruhen. Das durch die offenbarte Ausführungsform verwendete asynchrone Verfahren basiert auf dem Mehrfachzugriff-Kollisionsvermeidungs-(MACA – multiple access collision avoidance)-Protokoll, welches die Basis für den IEEE 802.11 Standard für drahtlose Netzwerke ist.
In einer herkömmlichen Implementation eines drahtlosen Netzwerkes unter Verwendung des asynchronen MACA-Protokolls sendet die sendende Station bevor eine Station Da ten sendet eine "Anforderung zum Senden"-(RTS – request to send)-Signal an einen empfangende Station. Die empfangende Station sendet dann ein "Klar zum Senden"-(CTS – clear to send)-Signal an die sendende Station, und zu diesem Zeitpunkt beginnt die sendende Station mit dem Senden von Daten. Wenn eine zweite Station in dem drahtlosen Netzwerk ebenfalls Daten senden möchte und ein RTS sendet, wartet, wenn ein anhängige RTS aus einer ersten Station vorliegt, die zweite Station auf das Stattfinden des ersteren Sendevorgangs bevor eine weitere Übertragung versucht wird. Diese Verzögerung vermeidet Datenkollisionen in dem drahtlosen Netzwerk. Trotz Anwendung der herkömmlichen Systeme und Vorgehensweisen stellt das existierende MACA-Protokoll keine Reservierung von Zugriff auf eine Sendebandbreite in einem Übertragungskanal bereit. Jedoch implementieren die mit den Prinzipien der vorliegenden Erfindung konsistenten Ausführungsformen diese Fähigkeit unter Anwendung des MACA-Protokolls.
System
1 ist eine Darstellung eines exemplarischen drahtlosen Netzwerkes zum Implementieren einer mit der vorliegenden Erfindung konsistenten Ausführungsform. Das Netzwerk 100 umfasst ein Ad-hoc-Netzwerk 102, ein drahtloses lokales Netz (LAN) 103 und ein zellulares Netz 104. Alle Netzwerke 102–104 sind miteinander über ein Netzwerk, wie z.B. das Internet 101, verbunden. Zusätzlich enthält jedes Netzwerk einen Server und mehrere zugeordnete Endgeräte. Das Ad-hoc-Netzwerk 102 enthält einen Server 108 und zugeordnete Endgeräte 105, 106 und 107. Das drahtlose LAN 103 enthält einen Server 109 und zugeordnete Endgeräte 110, 111 und 112. Typischerweise ist in einem drahtlosen LAN, wie z.B. dem drahtlosen LAN 103, der Server 109 eine Basisstation und zugeordnete Endgeräte 110, 111 und 112 sind Client-Endgeräte. Das zellulare Netzwerk 104 enthält einen Server 113 und zugeordnete Endgeräte 114, 115 und 116. Typischerweise ist in einem zellularen Netzwerk, wie z.B. dem zellularen Netzwerk 104, der Server 113 eine Basisstation und zugeordnete Endgeräte 114, 115 und 116 sind Client-Endgeräte. Jedes von den Netzwerken 102–104 kann eine nachstehend beschriebene Verarbeitung implementieren, um einen Zugriff auf Bandbreite in Kommunikationskanälen innerhalb des Netzwerkes zu reservieren. Wie es deutlich zu sehen ist, sind diese drei Netzwerke lediglich Beispiele von Netzwerken zum Implementieren einer Reservierung eines Zugriffs auf Bandbreite in einem Übertragungskanal, und andere oder unterschiedliche Netzwerke können verwendet werden.
2 ist eine Darstellung eines exemplarischen Servers und eines exemplarischen zugeordneten Client-Endgerätes. Im Netzwerk 200 ist ein Server 201 einem Client-Endgerät 204 zugeordnet. Der Server 201 kann Servern 108, 109 oder 113 entsprechen. Das Client-Endgerät 204 kann einem der Endgeräte und den Netzwerken 102–104 entsprechen. Gemäß Darstellung enthält der Server 201 einen Prozessor 202, der mit einem zugeordneten Speicher 203 verbunden ist. Der Client 204 enthält einen mit einem zugeordneten Speicher 206 verbundenen Prozessor 205. Die Speicher 203 und 206 können Netzwerkanwendungen zum Steuern der Prozessoren 202 und 205 speichern, um ein Verfahren zum Reservieren von Zugriff auf einen Übertragungskanal in dem entsprechenden Netzwerk zu implementieren.
3A ist ein exemplarisches Zeittaktdiagramm, das die Reservierung von Zugriff auf Bandbreite in einem Übertragungskanal in einem der Netzwerke 102–104 darstellt und eine Übertragungssitzung 300 repräsentiert. In der Sitzung 300 wird ein Beispiel eines eine Reservierung von Zugriff auf Bandbreite in einem Übertragungskanal anfordernden Client gegeben, das mit einer Ausführungsform der Erfindung konsistent ist. In dem Beispiel sendet ein Client eine Reservierungs-RTS (R-RTS)-Signal 301 an einen Server. Das R-RTS-Signal 301 ist eine spezielle Art eines RTS und wird dazu verwendet, eine Reservierung von Zugriff auf Bandbreite in einem Übertragungskanal anzufordern. In einer herkömmlichen Implementation steht nur ein RTS-Signal zur Verfügung, welches keinen Zugriff auf Bandbreite in einem Übertragungskanal reservieren kann. Jedoch sind mit der Erfindung konsistente Systeme mit der herkömmlichen Implementation kompatibel, obwohl sie auch eine R-RTS enthalten und bereitstellen, wie z.B. das R-RTS-Signal 301.
Nach dem Empfang des R-RTS-Signals 301 ermittelt der Server, ob die angeforderte Kanalkapazität durch die "Reservierungsfunktionalität" gemäß nachstehender Beschreibung untergebracht werden kann. Wenn der Server gemäß der Reservierungsfunktionalität die Reservierung akzeptiert, sendet der Server ein CTS-Signal 302, das die Reservierung des angeforderten Zugriffs bestätigt. Der Client sendet anschließend ein modifiziertes RTS-(M-RTS)-Signal 303 an den Server. Das M-RTS-Signal 303 ist eine weitere spezielle Art einer RTS und wird dazu verwendet, Genehmigung für die Übertragung von Daten anzufordern. Wiederum sind, obwohl sie dieses M-RTS-Signal 303 bereitstellen, mit der Erfindung konsistente Systeme noch mit der herkömmlichen Implementation kompatibel, welche nur das RTS-Signal enthält. Nach dem Empfang des M-RTS-Signals 303 ermittelt der Server, ob der reservierte Sendevorgang durch die "Zulassungsfunktionalität" gemäß nachstehender Beschreibung zu genehmigen ist. Das M-RTS-Signal 303 enthält eine Kanalreservierungs-Kennung, so dass der Server identifizieren kann, ob eine spezielle M-RTS einer früheren R-RTS entspricht. Wenn der Server das Senden der durch das M-RTS-Signal 303 identifizierten Daten unterbringen kann, antwortet der Server mit einem CTS-Signal 304, nach welchem der Client Daten 305 sendet. Der Server kann optional ein Quittierungs-(ACK – acknowledgment)-Signal 306 auf den Empfang von Daten 305 senden. Der Client und Server senden anschließend M-RTS und CTS-Signale für die restlichen Datensendevorgänge in der Sitzung 300. Erkennbar stellt auch der Server nach dem Empfang einer regulären RTS fest, ob der nicht reservierte Sendevorgang durch die "Zulassungsfunktionalität" zu genehmigen ist. Die "Reservierungsfunktionalität" und "Zulassungsfunktionalität" werden nachstehend beschrieben.
3B ist eine Darstellung eines exemplarischen R-RTS-Signals 301. Gemäß Darstellung in 3B umfasst das R-RTS-Signal 301 eine Reservierung 320 und ein typisches RTS-Signal 325. In einer Implementation enthält die Reservierung 320 eine Kanalpegel-Reservierungskennung 330 und ein Kanalkapazitätsschema 340. Kanalpegel-Reservierungskennung 330 wird eindeutig durch eine Quellenkennung 350 und eine eindeutige Kennung aus der Quelle 355 identifiziert. Die Quellen-Kennung 350 ist einfach eine Identifikation der Quelle der R-RTS. Die eindeutige Kennung aus der Quelle 355 wird durch den Client unter Verwendung eines Zählers erzeugt, so dass jede eindeutige Kennung aus der Quelle 355 sich von allen anderen Quellen einer eindeutigen Kennung aus der Quelle 355 unterscheidet. Das Kanalkapazitätsschema 340 wird durch B, I identifiziert, welche Bits 360 und ein Intervall 365 repräsentieren. Das Kanalkapazitätsschema 340 enthält somit zwei Parameter, B, die maximale Anzahl von Bits, die in einem spezifizierten Intervall gesendet werden können, und I, das spezifizierte Intervall in Sekunden. In diesem Zusammenhang ist B, I das Verkehrsbeschreibungsverfahren zum Aufbauen einer als eine "Moving Window Descriptor" bekannte Kanalkapazität.
3C ist eine Darstellung eines weiteren exemplarischen R-RTS-Signals 301. Ähnlich zu 3B umfasst gemäß Darstellung in 3C das R-RTS-Signal 301 eine Reservierung 320 und ein typisches RTS-Signal 325. Die Reservierung 320 enthält ebenfalls eine Kanalpegel-Reservierungskennung 330 und ein Kanalkapazität 340, welche eindeutig durch die Quellenkennung 350 und die eindeutige Kennung aus der Quelle 355 identifiziert wird. In 3C wird jedoch das Kanalkapazitätsschema 340 durch R, Bu und nicht durch B, I identifiziert. R, Bu repräsentieren die Rate 362 und das Bündel 367. Das Kanalkapazitätsschema 340 enthält somit zwei Parameter R, die durchschnittliche Rate der Quelle, und Bu, den maximal zulässigen Verkehr (oder das "Bündel"). In diesem Zusammenhang ist R, Bu das Verkehrsbeschreibungsverfahren zum Aufbau einer als "linear bounded arrival Prozess" (LBAP) bekannten Kanalkapazität, die auch als "leaky bucket descriptor" bekannt ist. Somit überschreitet die maximale Anzahl von Bits, die in einem spezifizierten Zeitintervall T gesendet werden können, nicht die Berechnung R·T + Bu.
3D ist eine Darstellung eines exemplarischen M-RTS-Signals 303. Gemäß Darstellung in 3D umfasst das M-RTS-Signal 303 eine Modifikation 370 und ein reguläres RTS-Signal 325. In einer Implementation enthält das M-RTS-Signal 303 eine Kanalreservierungskennung 375. Gemäß vorstehender Feststellung ermöglicht die Kanalreservierungskennung 375 dem Server zu identifizieren, ob ein M-RTS-Signal 375 einem früheren R-RTS-Signal 301 entspricht. In einer derartigen Implementation enthält jedes M-RTS-Signal 325 für ein spezielles R-RTS-Signal 301 diese Kanalreservierungskennung 375.
Ablauf
4A und 4B sind ein Flussdiagramm eines exemplarischen Ablaufes 400 für die Reservierung von Zugriff auf Bandbreite in einem Übertragungskanal in einem Netzwerk. Der Prozess kann durch eine im Speicher 203 und 206 für die Steuerprozessoren 202 und 205 für die Übertragung zwischen dem Server 201 und dem Client-Endgerät 204 gespeicherte Anwendung implementiert werden. In dem Prozess sendet ein Client-Endgerät ein R-RTS-Signal, das die Reservierung von Zugriff auf Bandbreite in einem Übertragungskanal anfordert (Schritt 401). Ein Server empfängt das R-RTS-Signal und stellt die Reservierungsfunktionalität fest (Schritt 420). In der Reservierungsfunktionali tät, welche nachstehend detaillierter beschrieben wird, stellt der Server fest, ob die angeforderte Bandbreite zur Verfügung steht (Schritt 403), und sendet diesbezüglich ein CTS-Signal an das Client-Endgerät (Schritt 405). Wenn die angeforderte Bandbreite nicht zur Verfügung steht, sendet der Server keine Antwort an das Client-Endgerät (Schritt 404). Wenn der Server keine Antwort sendet, endet das R-RTS zeitlich und das Client-Endgerät bricht den Versuch zum Reservieren von Bandbreite ab (Schritt 405).
Wenn das Client-Endgerät eine Reservierung von dem Server erhält (d.h., wenn das Client-Endgerät eine CTS empfängt), sendet der Client ein M-RTS-Signal an den Server, um mit dem Senden von Daten auf der reservierten Bandbreite zu beginnen (Schritt 406). Der Server empfängt das M-RTS-Signal und stellt die Zulassungsfunktionalität fest (Schritt 407). In der Zulassungsfunktionalität, welche nachstehend im Detail beschrieben wird, stellt der Server fest, ob die angeforderte Bandbreite zu diesem Zeitpunkt zur Verfügung steht (Schritt 408), und sendet diesbezüglich ein CTS-Signal an den Client (Schritt 410). Wenn die angeforderte Bandbreite nicht zur Verfügung steht, sendet der Server keine Antwort an das Client-Endgerät (Schritt 409). Wenn der Server keine Antwort sendet, endet das M-RTS-Signal zeitlich, und das Client-Endgerät bricht den Versuch ab, das Paket zu senden (Schritt 414). Wenn dieses geschieht, wird dann festgestellt, ob noch mehr Datenpakete zu senden sind.
Wenn das Client-Endgerät die Genehmigung erhält, mit dem Senden von Daten zu beginnen, (d.h., wenn das Client-Endgerät ein CTS-Signal empfängt), sendet das Client-Endgerät ein Datenpaket auf der speziellen Bandbreite (Schritt 411) an den Server. Der Server sendet nach dem Empfang des Datenpaketes optional ein Quittierungssignal (Schritt 412). Anschließend wird ermittelt, ob mehrere Datenpakete zu senden sind (Schritt 413). Falls ja, sendet der Client ein weiteres M-RTS-Signal an den Server und der Vorgang wiederholt sich. Falls nicht, endet der Ablauf hier.
Zustandsdiagramme
5 ist ein Zustandsdiagramm 500 für das Client-Endgerät 204, das die verschiedenen Zustände des Client-Endgerätes während der Reservierungs- und Genehmigungsfunktionalität darstellt. In einer Implementation weist ein Client-Endgerät vier Zustände in der Reservierungs- und Genehmigungsfunktionalität auf: Initialisierungszustand 501, Reservierungswartezustand 502, reservierter Flusszustand 503 und Paketwartezustand 504. Ein Client-Endgerät wechselt von dem Initialisierungszustand 501 zu dem Reservierungswartezustand 502 als Reaktion auf das Senden einer Reservierungsanforderung oder eines R-RTS-Signals. Der Client wechselt aus einem Reservierungswartezustand 502 in einen reservierten Flusszustand 503 als Reaktion auf den Empfang eines CTS-Signals und wechselt dann zu einem Initialisierungszustand 501 als Reaktion auf einen Zeitablauf des Servers. Das Client-Endgerät wechselt aus einem reservierten Flusszustand 503 in einen Paketwartezustand 504 als Reaktion auf ein Sendebereitschafts- (d.h., ready for admission) oder ein M-RTS-Signal und wechselt zu einem Initialisierungszustand 501 als Reaktion auf einen Sitzungsaktivitätsablauf. Das Client-Endgerät wechselt aus dem Paketwartezustand 504 in einen Flusszustand 503 als Antwort auf den Empfang eines CTS-Signals und das Senden eines Datenpaketes.
Tabelle 1 stellt einen exemplarischen Pseudocode für die Implementation dieser Client-Endgerätefunktionen dar.
Tabelle 1 Client-Endgerätreservierungs- und Genehmigungsfunktionalität
Gemäß Darstellung durch den Pseudocode in Tabelle 1 gibt es zwei Alternativen für ein Client-Endgerät, das ein Datenpaket senden möchte: Erstens kann ein Client-Endgerät wünschen, Daten ohne Reservierung zu senden; und zweitens kann ein Client-Endgerät wünschen, Bandbreite für einen Sendevorgang zu reservieren. In der ersten Ausführungsform, wenn das Client-Endgerät keine Bandbreite für einen Sendevorgang reservieren möchte, sendet das Client-Endgerät dann einfach eine RTS. Diese Vorgabe-RTS enthält eine Vorgabereservierungskennung aus der Quelle (z.B. 0). Die Vorgabe-RTS zeigt an, dass die RTS keine R-RTS ist. In der zweiten Alternative erzeugt, wenn das Client-Endgerät Bandbreite für einen Sendevorgang reservieren möchte, dann das Client-Endgerät eine eindeutige Kennung aus der Quelle und sendet eine diese Kennung enthaltende RTS, d.h., das Client-Endgerät sendet eine R-RTS. Insbesondere fügt, wie es vorstehend beschrieben wurde, das R-RTS auch ein bestimmtes Kanalkapazitätsschema hinzu. Nach dem Empfang verarbeitet der Server dann die R-RTS unter Verwendung der Reservierungsfunktionalität. Gemäß Darstellung durch den Pseudocode in Tabelle 1 gibt es auch eine Alternative RTS oder M-RTS. Sobald der Server eine R-RTS genehmigt und eine Kanalreservierungskennung zugewiesen hat, sendet das Client-Endgerät eine M-RTS an den Server, wenn das Client-Endgerät zum Senden von Daten bereit ist. Der Server verarbeitet die M-RTS unter Verwendung der Servergenehmigungsfunktionalität. Zum Schluss ist, wie es ebenfalls durch den Pseudocode in Tabelle 1 dargestellt ist, auch eine Paket-RTS vorhanden. Die Paket-RTS zeigt einfach dem Server an, dass ein weiteres Datenpaket zum Senden bereitsteht.
6 ist ein Zustandsdiagramm 600 für den Server 201, das die verschiedenen Zustände eines Servers während der Reservierungsfunktionalität darstellt. In einer Implementation weist der Server drei Zustände in der Reservierungsfunktionalität auf: Realisierungszustand 601, Reservierungswartezustand 602, und reservierter Flusszustand 603. Der Server wechselt aus dem Initialisierungszustand 601 in den Reservierungswartezustand 602 als Reaktion auf den Empfang eines R-RTS-Signals. Der Server wechselt aus einem Reservierungswartezustand 602 in den Reservierungsflusszustand 603 als Reaktion auf eine erfolgreiche Reservierung und das Senden eines entsprechenden CTS-Signals, und wechselt aus dem Reservierungswartezustand 602 in den Initialisierungszustand 601 als Reaktion auf einen Ausfall einer Reservierung. Der Server wechselt aus dem Reservierungsflusszustand 603 in den Initialisierungszustand 601 als Reaktion auf einen Sitzungsaktivitätszeitablauf.
Tabelle 2 stellt einen exemplarischen Pseudocode zur Implementation von Reservierungsfunktionen dar.
Tabelle 2 Server-Reservierungsfukionalität
Wie es durch den Pseudocode in Tabelle 2 dargestellt wird, beachte man in einer bevorzugten Implementation, dass der Server eine Gesamtkapazität TC aufrechterhält, welche die Gesamtanzahl der Bits repräsentiert, die der Server in einer Sekunde empfangen kann. In dieser Implementation besteht eine Möglichkeit zur Berechnung der TC darin, die maximal durch den Server mögliche Rate zu nehmen und sie mit einem Wirkungsgradfaktor k zu multiplizieren, wobei 0 < k < 1 ist. Der Wert von k ist anwendungsabhängig. Zusätzlich beachte man in dieser Implementation ferner, dass der Server eine Reservierungsliste führt, die Information über alle aktiven Reservierungen enthält. Gemäß Darstellung in den 3B und 3C enthält jede Instanz einer Reservierung in dieser Reservierungsliste einen Quellenkennung, welche die Quelle der Reservierung über eine eindeutige Kennung aus der Quelle identifiziert, was eine Kennung für jede Reservierung bereitstellt, und ein Kanalkapazitätsschema, welches aus wenigstens zwei möglichen Schemata besteht (d.h., dem Moving Window Descriptor oder Leaky Bucket Descriptor). Der Server führt somit eine Kapazitätsausnutzung UC, welche die Summe aller Reservierungen in der Reservierungsliste ist. Die Berechnung der UC basiert auf der effektiven Kapazität EC, d.h., der effektiven Kapazität jeder Reservierung. Die Berechnung der EC hängt von dem Kanalkapazitätsschema ab. Wenn der Moving Window Descriptor verwendet wird, ist EC = B/I, und wenn der Leaky Bucket Descriptor verwendet wird, ist EC = R. Natürlich sind diese nur zwei mögliche Implementationen eines Kanalkapazitätsschemas und andere Implementationen sind möglich, welche dasselbe System verwenden. Ein Fachmann auf diesem Gebiet würde leicht weitere mögliche Alternativen unter Verwendung des offenbarten Systems verstehen.
In einer Implementation des Pseudocodes aus Tabelle 2 ist nach einer Aktivierung oder einem Rücksetzen des Servers die genutzte Kapazität UC leer und die Reservierungsliste ist leer. Wenn eine neue Reservierungsanforderung in der Form einer R-RTS ankommt, prüft der Server, ob die angeforderte Kapazität, RC, in der R-RTS plus der genutzten Kapazität UC die Gesamtkapazität TC überschreitet oder nicht. Wie die Berechnung der UC gemäß vorstehender Beschreibung hängt die Berechnung der RC ebenfalls von dem Kanalkapazitätsschema ab. Somit wird, sobald die Berechnung durchgeführt wird, wenn die RC die TC nicht überschreitet, dann die R-RTS der Reservierungsliste hinzugefügt, und eine CTS an das Client-Endgerät gesendet. Die CTS zeigt an, dass die Reservierung durch den Server akzeptiert worden ist. In einer bevorzugten Implementation enthält die CTS auch eine Kanalreservierungskennung.
7 ist ein Zustandsdiagramm 700 für den Server 201, das die verschiedenen Zustände für den Server während der Genehmigungsfunktionalität darstellt. In einer Implementation besitzt einen Server zwei Zustände in der Genehmigungsfunktionalität: einen Wartezustand 701 und einen Genehmigungswartezustand 702. Der Server wechselt aus dem Wartezustand 701 in den Genehmigungswartezustand 702 als Reaktion auf den Empfang eines M-RTS. Der Server wechselt aus einem Genehmigungswartezustand 702 in den Wartezustand 701 als Reaktion auf das Ergebnis der Genehmigungsfunktionalität. Wenn die Genehmigungsfunktionalität die M-RTS anerkennt, sendet dann der Server ein CTS-Signal. Wenn die Genehmigungsfunktionalität die M-RTS zurückweist, weist dann der Server die M-RTS zurück.
Die Tabelle 3 stellt einen exemplarischen Pseudocode für die Implementation dieser Servergenehmigungsfunktionen bereit.
Tabelle 3 Server-Genehmigungsfunktionalität
Gemäß Darstellung durch 7 sendet, wenn ein Client-Endgerät bereit ist, ein Datenpaket nach einer erfolgreichen Reservierung zu senden, dieses ein M-RTS-Signal an den Server. Gemäß vorstehender Beschreibung weist eine derartige "modifizierte" RTS (oder M-RTS) ein Feld auf, das die Kanalreservierungskennung enthält, welche anzeigt, dass dem Datenpaket eine Reservierung zugeordnet ist. In einer Implementation gibt es, wenn das Paket keine Kanalreservierungskennung enthält, einen speziellen Wert für dieses Feld (z.B. 0). Nach der Überprüfung der Kanalreservierungskennung in der M-RTS entscheidet der Server dann, ob er eine CTS als Antwort auf die M-RTS sendet. Dieses ist die Servergenehmigungsfunktionalität. Insbesondere führt, wie es vorstehend erläutert wurde, der Server einen Gesamtkapazitätswert TC und einen Nutzungskapazi tätswert UC, wobei UC die aktiven Reservierungen zeigt. Somit führt der Server nach dem Empfang einer M-RTS die Genehmigungsfunktionalität aus und reagiert mit einer CTS nur, wenn die Genehmigungsfunktionalität dieses genehmigt.
Gemäß Darstellung durch den Pseudocode in Tabelle 3 führt der Server nach der Ankunft einer M-RTS die Servergenehmigungsfunktion durch. Zu Beginn berechnet der Server die maximale Anzahl von Bits, die gesendet werden können oder die verfügbare Kapazität AC. Das Verfahren der Berechnung der AC hängt von dem durch die Servergenehmigungsfunktionalität implementierten Kanalkapazitätsschema ab. In Tabelle 3 wird ein Beispiel eines Leaky Bucket Descriptor verwendet, wobei R, Bu die Kanal-Descriptoren sind. Somit berechnet der Server mit diesem Verfahren zur Berechnung der AC das Bündel Bu und die Summe der mindestens verfügbaren Kapazität LAC und der zusätzlichen Kapazität, die während der verstrichenen Zeit verfügbar wurde, welche das Produkt der verstrichenen Zeit ET und der Rate R ist. Somit kann der Server mittels der AC die Genehmigung für die M-RTS ermitteln. Wenn die Anzahl der in der M-RTS zu sendenden angeforderten Bits nicht größer als die maximale Anzahl der Bits ist, die gesendet werden dürfen (d.h., AC), genehmigt der Server dann die M-RTS und sendet eine CTS an den Client. Umgekehrt verweigert, wenn die durch die M-RTS angeforderte zu sendende Anzahl mehr als die AC ist, der Server die Genehmigung für die M-RTS und sendet keine CTS.
Gemäß vorstehender Beschreibung hängt das Verfahren der Berechnung der AC von dem durch die Servergenehmigungsfunktionalität implementierten Kanalkapazitätsschema ab. Obwohl es in Tabelle 3 nicht dargestellt ist, ist ein weiteres Kanalkapazitätsschema, das durch die Servergenehmigungsfunktionalität verwendet werden kann, der Moving Window Descriptor. Diese Implementation würde den Pseudocode in der Tabelle 3 mit der Ausnahme wiederholen, dass Bu = 0 und R den Wert von Bi zugeordnet würde. Ein Fachmann auf diesem Gebiet würde diese und weitere mögliche alternative Implementationen unter Verwendung des offenbarten Systems erkennen.
Schlussfolgerung
Mit der vorliegenden Erfindung konsistente Systeme überwinden die Nachteile der herkömmlichen Mechanismen, indem sie einen reservierten Zugriff auf Bandbreite in einem Übertragungskanal in einem Netzwerk in einer asynchronen Bedarfs/Wunsch-Weise bereitstellen. Durch die Bereitstellung der Reservierung von Bandbreite unterstützen derartige Systeme vollständig einen Bündelverkehr. Zusätzlich stellen sie diese Vorteile ohne die Komplexität und den Zusatzaufwand von TDMA-basierenden Verfahren bereit. Zusätzlich unterstützen sie, vorausgesetzt, dass Kapazität verfügbar ist, Verkehr, der keinen reservierten Zugriff aufweist. Demzufolge ermöglichen die Systeme einen verfügbaren Bitraten-(ABR – available bit rate)-Dienst, etwas, was in den meisten TDMA-basierenden Schemas nicht verfügbar ist. Ferner sind, da die Systeme das MACA-Protokoll nur leicht (d.h. durch die Hinzufügung der R-RTS und M-MTS) verändern, nur kleinere Änderungen an dem MACA-Protokoll zur Kompatibilität erforderlich. Demzufolge bleiben selbst in diesen Modifikationen die mit der vorliegenden Erfindung konsistenten Systeme zu dem IEEE 802.11 Standard rückwärtskompatibel. Schließlich funktionieren derartige Systeme drahtlos mit Ad-hoc-Netzwerken.

Claims

Verfahren zum Reservieren von Zugriff auf eine Sendebandbreite in einem Datenübertragungskanal an einem Endgerät in einem Drahtlos-Netzwerk, wobei das Netzwerk ein herkömmliches Verfahren mit RTS (Request To Send) und CTS (Clear To Send) verwendet, um auf einen Datenübertragungskanal zuzugreifen, und das Verfahren die folgenden Schritte umfasst: Senden einer RTS zu einem Server, die modifiziert ist, um die Reservierung von Sendebandbreite in einem Datenübertragungskanal in dem Drahtlos-Netzwerk anzufordern (301); wenn festgestellt wird, dass die Reservierungsanforderung angenommen werden kann, Senden einer CTS von dem Server zu dem Endgerät (302); beim Empfang der CTS Senden einer RTS zu dem Server, die modifiziert ist, um Genehmigung zum Senden von Daten über reservierte Bandbreite eines Datenübertragungskanals in dem Drahtlos-Netzwerk anzufordern (303); wenn festgestellt wird, dass das Datensenden ermöglicht werden kann, Senden einer CTS von dem Server zu dem Endgerät (304); und beim Empfang der CTS Senden eines Datenpaktes zu dem Server.
Verfahren nach Anspruch 1, das des Weiteren umfasst: Empfangen eines Quittierungssignals von dem Server nach dem Senden des Datenpaketes zu dem Server.
Verfahren nach Anspruch 1, wobei das Reservierungs-RTS-Signal eine Kanalpegel-Reservierungskennung und eine Anzeige erforderlicher Kanalkapazität enthält.
Verfahren nach Anspruch 3, wobei die Kanalpegel-Reservierungskennung eine Quellenkennung und eine eindeutige Kennung von der Quelle enthält.
Verfahren nach Anspruch 3, wobei die Anzeige der erforderlichen Kanalkapazität B/1 enthält und dies die in einem Intervall (I) zu sendende Anzahl von Bits (B) darstellt.
Verfahren nach Anspruch 3, wobei die Anzeige erforderlicher Kanalkapazität Verwendung eines LBAP (linear bounded arrival process)-Verfahrens einschließt.
Verfahren nach Anspruch 1, wobei das erste CTS-Signal eine Kanalreservierungskennung enthält.
Verfahren nach Anspruch 1, wobei das modifizierte RTS-Signal eine Kanalreservierungskennung enthält.
Verfahren nach Anspruch 1, wobei der dritte Sendeschritt unter Verwendung einer durch das erste CTS-Signal bestätigen Bandbreite stattfindet.
System zum Reservieren von Zugriff auf eine Sendebandbreite in einem Datenübertragungskanal an einem Endgerät in einem Drahtlos-Netzwerk, wobei das Netzwerk ein herkömmliches Verfahren mit RTS und CTS verwendet, um auf einen Datenübertragungskanal zuzugreifen, und das System umfasst: eine Reservierungs-Sende-Komponente, die so konfiguriert ist, dass sie eine RTS zu einem Server sendet, die modifiziert ist, um Reservierung von Sendebandbreite in einem Datenübertragungskanal in dem Drahtlos-Netzwerk anzufordern (301); eine erste Bestätigungs-Komponente, die eine CTS von dem Server zu dem Endgerät sendet (302), wenn festgestellt wird, dass die Reservierungsanforderung angenommen werden kann; eine Genehmigungs-Komponente, die beim Empfang der CTS von dem Endgerät zu dem Server eine RTS sendet, die modifiziert ist, um Genehmigung zum Senden von Daten über reservierte Bandbreite eines Datenübertragungskanals in dem Drahtlos-Netzwerk anzufordern (303); eine zweite Bestätigungs-Komponente, die eine CTS von dem Server zu dem Endgerät (304) sendet, wenn festgestellt wird, dass das Senden von Daten ermöglicht werden kann; und eine Sende-Komponente, die beim Empfang der CTS ein Datenpaket von dem Endgerät zu dem Server sendet (305).
System nach Anspruch 10, das des Weiteren umfasst: eine Empfangs-Komponente, die so konfiguriert ist, dass sie ein Quittierungssignal von dem Server nach dem Senden des Datenpaketes zu dem Server empfängt.
System nach Anspruch 10, wobei das Reservierungs-RTS-Signal eine Kanalpegel-Reservierungskennung und eine Anzeige erforderlicher Kanalkapazität enthält.
System nach Anspruch 12, wobei die Kanalpegel-Reservierungskennung eine Quellenkennung und eine eindeutige Kennung von der Quelle enthält.
System nach Anspruch 12, wobei die Anzeige erforderlicher Kanalkapazität B/1 enthält und dies die in einem Intervall (I) zu sendende Anzahl von Bits (B) darstellt.
System nach Anspruch 12, wobei die Anzeige erforderlicher Kanalkapazität Verwendung eines LBAP-Verfahrens einschließt.
System nach Anspruch 10, wobei das erste CTS-Signal eine Kanalreservierungskennung enthält.
System nach Anspruch 10, wobei das modifizierte RTS-Signal eine Kanalreservierungskennung enthält.
System nach Anspruch 10, wobei die Sende-Komponente unter Verwendung einer durch das erste CTS-Signal bestätigten Bandbreite stattfindet.
Computerprogramm, das Codemittel umfasst, die zum Durchführen aller Schritte des Verfahrens nach einem der Ansprüche 1 bis 9 eingerichtet sind, wenn das Programm auf einem Datenverarbeitungssystem ausgeführt wird.