-
Die
Erfindung betrifft ad-hoc-aufgebaute Geräte-Netzwerke, die einen Zentralcontroller
und mehrere Terminals aufweisen. Die Erfindung betrifft insbesondere
ein Verfahren zur Optimierung von Datenverkehr in einem ad-hoc-aufgebauten
Geräte-Netzwerk,
einen Zentralcontroller zum Steuern mehrerer Terminals in einem
ad-hoc-aufgebauten Geräte-Netzwerk,
und ein Gateway zum Verbinden des Geräte-Netzwerks mit einem externen
Netzwerk.
-
Für eine Vielzahl
von Multimedia-Heimanwendungen sowie Business-Anwendungen spielt das
Aufbauen von Netzwerken, insbesondere das Aufbauen von drahtlose
Netzwerken, um Daten und Nachrichten zwischen unterschiedlichen
Geräten (die
Teile des Netzwerks sind) auszutauschen, eine besondere Rolle. In
einem typischen Businessapplikations-Szenario bezieht ein mobiles
Terminal Dienste über
eine bestimmte Firmen-Infrastruktur oder eine öffentliche Infrastruktur. In
einem typischen Heimapplikations-Szenario werden günstige Netzwerke
sowie flexible Netzwerke unterstützt,
um drahtlose digitale Endverbraucher-Geräte miteinander zu verbinden.
-
Der
Standard HIPERLAN (High Performance Radio Local Area Network = High-Performance-Radio-Lokal-Netzwerk),
der Hochgeschwindigkeits-Multimedia-Kommunikation zwischen verschiedenen Breitband-Kern-Netzwerken
und mobilen Terminals bereitstellt, ist im Rahmen des ETSI-Projekts
BRAN (Broadband Radio Access Networks = Breitband-Radio-Zugangs-Netzwerke),
entstanden. Der HIPER-LAN/2-Standard
stellt eine flexible Plattform für eine
Vielzahl für
Business- und Heim-Applikationen bereit, die mehrere Bitraten bis
zu 54 Mbit/s unterstützen.
Der HIPERLAN/2-Standard ist ein Beispiel dafür, wie Daten zwischen unterschiedlichen
Geräten in
einem drahtlosen Netzwerk übertragen
werden können.
Die Erfindung ist nicht auf drahtlose Netzwerke gemäß dem HIPERLAN/2-Standard
beschränkt.
Ferner ist die Erfindung nicht auf drahtlose Netzwerke beschränkt, sondern
kann auch auf verdrahtete Netzwerke angewandt werden.
-
Ein
typisches Geräte-Netzwerk
weist mehrere Geräte
auf, wobei eines der Geräte
als Zentralcontroller agiert, der die anderen Geräte, die
als Terminals agieren. steuert. Wenn unterschiedliche Geräte in Reichweite
zueinander gebracht werden, beginnen diese, Nachrichten miteinander
auszutauschen und ein sogenanntes ad-hoc-Netzwerk aufzubauen. Das erste Gerät des ad-hoc-Netzwerks übernimmt
die Steuer-Funktionalität
des Netzwerks. Für
den Fall, dass mehr als ein Controllerfähiges Gerät in dem Netzwerk existiert,
kann jedes dieser Geräte
das erste Gerät
des Netzwerks werden und damit zum Zentralcontroller des Netzwerks
avancieren.
-
In
dem so genannten zentralen Modus muss ein Datenpaket, das von einem
ersten Terminal zu einem zweiten Terminal gesandt wird, über den
Zentralcontroller geleitet werden. Der Datenstrom von dem ersten
Terminal zu dem zweiten Terminal wird durch den Zentralcontroller "reflektiert". Die reflektierten
Datenströme
verursachen viel zusätzlichen
Datenverkehr. Sie erhöhen
die Netzwerklast signifikant.
-
Die
meisten Geräte-Netzwerke
weisen ein Gateway auf, das eine Verbindung zwischen dem ad-hoc-aufgebauten
Geräte-Netzwerk
und externen Netzwerken, beispielsweise dem Internet, herstellt. Nach
außen
gehender Datenverkehr, der von einem Terminal zum Gateway geschickt
wird, muss über den
Zentralcontroller geleitet werden, womit ein reflektierter Datenstrom
erzeugt wird. Eintreffender Datenverkehr, der das Gateway erreicht,
muss ebenfalls über
den Zentralcontroller geleitet werden, bevor dieser an jeweilige
Terminals verteilt werden kann. Auch in diesem Fall werden reflektierte
Datenströme
erzeugt.
-
In
diesem Zusammenhang sind die folgenden Dokumente zu erwähnen:
- 1: "Broadband
Radio Access Networks (BRAN); HIPERLAN Type 2: "System Overview" ETSI TR 683 V1.1.1., 8. Februar 2000
(2000-02-08), S. 1 bis 20, XP002176358.
- 2. ROYER E M ET AL: "A
REVIEW OF CURRENT ROUTING PROTOCOLS FOR AD HOC MOBILE WIRELESS NETWORKS" IEEE PERSONAL COMMUNICATIONS,
IEEE COMMUNICATIONS SOCIETY, US, Band 6, Nr. 2, April 1999 (1999-04),
S. 46 bis 55, XP000823968 ISSN: 1070–9916.
-
Diese
Dokumente geben einen Überblick über den
technischen Hintergrund, was Hiperlan-Typ-2-Netzwerke sowie Routing-Protokolle
für ad-hoc-Netzwerke
betrifft.
-
Die
der Erfindung zugrunde liegende Aufgabe ist, ein Verfahren und eine
Einrich tung zum Optimieren von Datenverkehr in einem ad-hoc-aufgebauten
Geräte-Netzwerk
bereitzustellen, um die Bandbreite des Geräte-Netzwerks effektiver nutzen
zu können.
-
Zur
Lösung
dieser Aufgabe stellt die Erfindung ein Verfahren zur Aufnahme eines
neuen Geräts
in ein ad-hoc-aufgebautes Geräte-Netzwerk
gemäß Patentanspruch
1, einen Zentralcontroller zum Steuern mehrerer Terminals gemäß Patentanspruch 14
sowie ein Computerprogrammprodukt gemäß Patentanspruch 21 bereit.
-
Das
Verfahren zum Optimieren von Datenverkehr in einem ad-hoc aufgebauten
Geräte-Netzwerk,
das einen Zentralcontroller und mehreren Terminals aufweist, und
bei dem alle Daten, die von einem ersten Terminal zu einem zweiten
Terminal zu übertragen
sind, über
den Zentralcontroller geleitet werden, weist die folgenden Schritte
auf:
- – Überwachen
des Datenverkehrs, um bezüglich eines
bestimmten Terminals festzustellen, welche Datenverkehrs-Menge von
dem bestimmten Terminal und/oder zu dem bestimmten Terminal über den
Zentralcontroller geleitet wird;
- – Überprüfen, ob
das bestimmte Terminal dazu im Stande ist, als Controller zu agieren,
wenn zumindest eine bestimmte Datenverkehrs-Menge von dem bestimmten
Terminal und/oder zu dem bestimmten Terminal über den Zentralcontroller geleitet
wird;
- – Ausführen eines
Handover-Prozesses bezüglich
der Steuerfunktionalität,
wenn das bestimmte Terminal als Controller agieren kann, um das
bestimmte Terminal zum neuen Zentralcontroller zu machen.
-
Immer,
wenn ein bestimmtes Gerät
des ad-hoc-Netzwerks – entweder
als Quelle oder als Ziel – in
einem Datenverkehr involviert ist, der über den Zentralcontroller geleitet
wird, und der einen reflektierten Datenstrom verursacht, wird geprüft, ob die Steuerfunktionalität auf das
bestimmte Gerät übertragen
werden kann. Eine Übertragung
der Steuerfunktionalität
auf das bestimmte Gerät
wird nur dann in Betracht gezogen, wenn die Menge des reflektierten Datenverkehrs
einen bestimmten Grenzwert überschreitet.
Ein Handover-Prozess bezüglich
der Steuerfunktionalität
wird nur dann initiiert, wenn das bestimmte Gerät ein Controller-fähiges Gerät ist. Wenn das
bestimmte Gerät
nicht Controller-fähig
ist, steuert der Zentralcontroller auch weiterhin das Netzwerk.
-
Indem
das bestimmte Gerät
als neuer Zentralcontroller des Netzwerks agiert, wird der Datenverkehr
in dem Netzwerk signifikant reduziert. Datenpakete, die direkt zwischen
dem bestimmten Gerät und
einem Terminal ausgetauscht werden, sowie reflektierte Datenströme werden
nicht länger
benötigt. Das
erfindungsgemäße Verfahren
trägt dazu
bei, den Datenverkehr in einem Geräte-Netzwerk zu reduzieren. Überflüssiger reflektierter
Datenverkehr kann verhindert werden, womit auch die Last des Netzwerks
reduziert wird. Dies bedeutet, dass die Bandbreite des Netzwerks
effizienter genutzt werden kann.
-
Vorzugsweise
wird der ehemalige Zentralcontroller als Terminal des neuen Zentralcontrollers aufgefasst.
Nach dem Handover-Prozess ist der ehemalige Zentralcontroller immer
noch Teil des Netzwerks.
-
Vorzugsweise
verfolgt der Zentralcontroller die Sourceadressen von Datenpaketen,
um festzustellen, welche Datenverkehrs-Menge von dem bestimmten
Terminal über
den Zentralcontroller geleitet wird. Jedes Datenpaket weist einen
Kopf (Header) auf, der die Quelladresse und die Zieladresse des Datenpakets
enthält.
Wenn die Datenströme
von einer bestimmten Quelle häufig
reflektierte Datenströme
verursachen, sollte in Erwägung
gezogen werden, die Steuerfunktionalität an die Quelle zu übertragen.
-
Alternativ
oder zusätzlich
kann der Zentralcontroller die Zieladressen der Datenpakete verfolgen,
um festzustellen, welche Menge an Datenverkehr zu dem bestimmten
Terminal über
den Zentralcontroller geleitet wird. Wenn ein bestimmtes Ziel-Gerät häufig in
Datenverkehr involviert ist, der reflektierte Datenströme verursacht,
ist es vorteilhaft, wenn dieses Zielgerät die Steuerung des Netzwerks übernimmt.
-
Gemäß einer
bevorzugten Ausführungsform der
Erfindung ist dieses bestimmte Gerät ein Gateway, das das Geräte-Netzwerk
mit einem externen Netzwerk verbindet. Datenpakete werden über das Gateway
mit externen Netzwerken ausgetauscht. Für diese Datenpakete ist der
zentralisierte Modus aktiv. Damit muss ausgehender Datenverkehr über den Zentralcontroller
zum Gateway geleitet werden. Eintreffender Datenverkehr muss ebenfalls über den Zentralcontroller
geleitet werden, bevor dieser an unterschiedliche Terminals weitergeleitet
wird. Wenn der Zentralcontroller und das Gateway zwei verschiedene
Geräte
sind, werden reflektierte Datenströme erzeugt. In diesem Fall
können
die reflektierten Daten ströme
vermieden werden, wenn das Gateway der Zentralcontroller des Netzwerks
wird. In diesem Fall ist es deshalb die beste Lösung, das Gateway zum Zentralcontroller
zu machen, da dies erlaubt, vielen überflüssigen reflektierten Datenverkehr
zu vermeiden. Wenn das Gateway als Zentralcontroller agiert, wird
bezüglich
des Übertragungskanals
die beste Performance erreicht, und der Datendurchsatz signifikant
erhöht.
-
Vorzugsweise überwacht
der Zentralcontroller den durch das Gateway des externen Netzwerks empfangenen
Datenverkehr, der über
den Zentralcontroller zu einem Zielgerät geleitet wird. Zusätzlich oder
alternativ überwacht
der Zentralcontroller ausgehenden Datenverkehr, der von einem Quellgerät zu dem
Gateway über
den Zentralcontroller gesandt wird, und der mittels des Gateways
zu dem externen Netzwerk gesandt wird. Um zu entscheiden, ob ein Handover-Prozess
von Steuerfunktionalität
gerechtfertigt ist oder nicht, ist es möglich, lediglich die Menge
des eintreffenden Datenverkehrs in Betracht zu ziehen. Alternativ
ist es möglich,
lediglich die Menge des ausgehenden Datenverkehrs oder sowohl eintreffenden
als auch ausgehenden Datenverkehr in Betracht zu ziehen.
-
Vorzugsweise
wird die Prüfung,
ob ein bestimmtes Terminal dazu im Stande ist, als Controller zu
agieren, mittels einer Datenbank durchgeführt, die Teil des Zentralcontrollers
ist. Wenn ein neues Gerät in
das Netzwerk aufgenommen wird, wird der Zentralcontroller darüber informiert,
ob das neue Gerät
Controller-fähig
ist oder nicht. Deshalb kann der Zentralcontroller die Datenbank
leicht verwalten bzw. auf den neuesten Stand bringen.
-
Gemäß einer
bevorzugten Ausführungsform der
Erfindung wird jedes Netzwerk-Gerät darüber informiert,
dass es nicht länger
durch den früheren Zentralcontroller
gesteuert wird, und das es in Zukunft durch den neuen Zentralcontroller
gesteuert wird, immer dann, wenn ein Handover-Prozess der Steuerfunktionalität ausgeführt wird.
Jede Interferenz zwischen dem ehemaligen Zentralcontroller und dem neuen
Zentralcontroller kann auf diese Art und Weise vermieden werden.
-
Vorzugsweise
ist das Netzwerk ein drahtloses Netzwerk und insbesondere ein Netzwerk
gemäß dem HIPERLAN/2-Standard.
-
Das
erfindungsgemäße Gateway
wird in einem ad-hoc-aufgebauten Geräte-Netzwerk eingesetzt, dass
einen Zentralcontroller und mehrere Terminals umfasst, wo bei das
Gateway das Geräte-Netzwerk
mit einem externen Netzwerk verbindet. Das Gateway ist dazu im Stande,
als Zentralcontroller des Geräte-Netzwerks
zu agieren. Um den Datenverkehr innerhalb des Netzwerks zu optimieren,
ist es wichtig, dass das Gateway als Controller agieren kann. Wen
der Datenverkehr mit externen Netzwerken, insbesondere dem Internet,
eine gewisse Schwelle überschreitet,
sollte die Steuerfunktionalität dem
Gateway übertragen
werden.
-
Die
Erfindung wird im Folgenden unter Bezugnahme auf die Figuren in
beispielsweiser Ausführungsform
näher erläutert. Es
zeigen:
-
1A die
Struktur des Geräte-Netzwerks, bevor
die Steuerfunktionalität
auf das Gateway übergegangen
ist.
-
1B die
Struktur des Geräte-Netzwerks, nachdem
die Steuerfunktionalität
auf das Gateway übergegangen
ist.
-
2 die
Nachrichten, die zwischen den Netzwerk-Geräten ausgetauscht werden, um
das Gateway zum neuen Zentralcontroller des Netzwerks zu machen.
-
3 ein
Flussdiagramm zur Realisierung des Verkehrs-basierenden Handover-Prozesses
der Steuerfunktionalität
gemäß der Erfindung.
-
In 1A ist
die Struktur eines ad-hoc-aufgebauten Geräte-Netzwerks gezeigt, dass
zwei drahtlose Terminals, das drahtlose Terminal 1 und das
Gateway 2 sowie einen Zentralcontroller 3, aufweist.
Gemäß dem HIPERLAN/2-Standard
besitzt das erste Gerät
des ad-hoc-Netzwerks die Steuerfunktionalität über das Netzwerk. Der Zentralcontroller 3 war
das erste Gerät
des ad-hoc-Netzwerks, und aus diesem Grund steuert dieses die drahtlosen
Terminals 1 und 2.
-
Das
Gateway 2 stellt eine Verbindung 4 zwischen dem
Geräte-Netzwerk
und dem externen Netzwerk 5 her. Der Datenverkehr von dem
Geräte-Netzwerk
zu dem externen Netzwerk (ausgehender Verkehr) und der Datenverkehr
von dem externen Netzwerk zu dem Geräte-Netzwerk (eintreffender Verkehr)
werden beide über
das Gateway 2 und die Verbindung 4 geleitet.
-
Die
Verbindung 4 basiert auf dem Ethernet-Protokoll. Eintreffender
Datenverkehr von dem externen Netzwerk 5 wird auf Basis
des HIPERLAN/2-Protokolls transportiert. Für die Datenpakete des eintreffenden
Datenverkehrs ist der zentrale Modus aktiv. Deshalb werden Datenpakete,
deren Zieladresse das drahtlose Terminal 1 ist, zuerst
an den Zentralcontroller 3 übertragen. Dort wird der Datenverkehr
von dem Gateway 2 reflektiert, und die Datenpakete werden
an das drahtlose Terminal 1 übertragen (7), was
deren Zieladresse darstellt.
-
Ausgehender
Datenverkehr wird, ausgehend von deren Quelle, dem drahtlosen Terminal 1 über das
Gateway 2 an das externe Netzwerk 5 übertragen.
Die Zieladresse des Datenpakets, das Teil des ausgehenden Datenverkehrs
ist, ist die so genannte Default-Route, die jegliche Zieladresse
außerhalb des
Geräte-Netzwerks
anzeigt. Auch für
den ausgehenden Datenverkehr ist der Zentralmodus aktiv. Datenpakete,
die durch das drahtlose Terminal 1 geschickt werden, werden
deshalb an den Zentralcontroller 3 übertragen (8). Der
Zentralcontroller 3 reflektiert (9) eintreffende
Datenpakete zum Gateway 2. Dort wird nach außen gehender
Datenverkehr über die
Verbindung 4 zum externen Netzwerk 5 übertragen.
-
Wenn
das Gateway 2 dazu im Stande ist, als Controller für das Geräte-Netzwerk
zu agieren, kann die Steuerfunktionalität von dem Zentralcontroller 3 zum
Gateway 2 übertragen
werden.
-
1B zeigt
die Struktur des Netzwerks, nachdem der Handover-Prozess ausgeführt wurde. Die
Steuerfunktionalität
wurde zu dem ehemaligen Gateway 2 übertragen, der nun der neue
Zentralcontroller 10 ist. Der ehemalige Zentralcontroller 3 steuert
das Geräte-Netzwerk
nicht mehr länger.
Dieser ist ein drahtloses Terminal 11 geworden, das Teil
des Netzwerks ist und durch den neuen Zentralcontroller 10 gesteuert
wird.
-
Der
eintreffende Datenverkehr wird von dem externen Netzwerk 5 über die
Verbindung 4 an den neuen Zentralcontroller 10 übertragen,
der das Gateway des Netzwerks ist. Dort werden die Pakete in das Protokoll
des internen Netzwerks umgewandelt, und an deren Zieladresse geschickt,
beispielsweise an das drahtlose Terminal 1.
-
Der
ausgehende Datenverkehr, der alle Datenpakete mit der Default-Route
als Zieladresse aufweist, wird von dessen Source-(Quell-)Adresse,
beispielsweise von dem drahtlosen Terminal 1, zu dem neuen
Zentralcontroller 10 übertragen.
Dort werden die Datenpakete in das Protokoll des externen Netzwerks
konvertiert und über
die Verbindung 4 an das externe Netzwerk 5 übertragen.
-
1B kann
entnommen werden, dass durch das Ausführen eines Handover-Prozesses der Steuerfunktionalität der Datenverkehr
innerhalb des Geräte-Netzwerks
signifikant reduziert werden kann. Anstelle der vier Datenströme 6, 7, 8, 9,
wie in 1A gezeigt, sind in 1B nur
zwei Datenströme 12 und 13 notwendig.
Die reflektierten Datenströme 7 und 9 in 1A,
die dazu notwendig sind, den ehemaligen Zentralcontroller 3 mit
dem Gateway 2 zu verbinden, werden nicht länger benötigt, da
in 1B der neue Zentralcontroller 10 gleichzeitig
das Gateway des Netzwerks darstellt. Durch Übertragen der Steuerfunktionalität an das
Gateway kann die Netzwerklast signifikant reduziert werden.
-
In 2 werden
die Nachrichten und Datenverkehrsströme gezeigt, die zwischen dem
drahtlosen Terminal 14, dem Zentralcontroller 15 und
dem Controller-fähigen
Gateway 16 ausgetauscht werden. Zu Anfang ist das Geräte-Netzwerk
von der Struktur, die in 1A gezeigt
ist, und das Gateway 16 steuert das Geräte-Netzwerk nicht. Ausgehender Verkehr
wird von dessen Quelle, dem drahtlosen Terminal 14, zu
dem Zentralcontroller 15 geleitet. Der Zentralcontroller 15 reflektiert
(18) den ausgehenden Datenverkehr zu dem Controller-fähigen Gateway 16,
das als Gateway zu externen Netzwerken agiert. Umgekehrt kommt eingehender
Verkehr von dem externen Netzwerk bei dem Controller-fähigen Gateway 16 an.
Für Datenpakete
von einem externen Netzwerk ist der Zentralmodus aktiv, und deshalb
wird der eintreffende Datenverkehr zum Controller 15 weitergeleitet
(19). Dort wird ein reflektierter Eingangs-Datenstrom erzeugt.
Gemäß der Zieladresse
der Datenpakete werden die Datenpakete beispielsweise zum drahtlosen
Terminal 14 übertragen
(20).
-
Um
den Datenverkehr in dem Geräte-Netzwerk
zu optimieren, überwacht
der Zentralcontroller, von woher die Datenpakete stammen und wohin
diese gesandt werden. In dem Header jedes Datenpakets sind sowohl
die Sourceadresse (Quelladresse) als auch die Zieladresse spezifiziert.
Ausgehender Datenverkehr ist dadurch gekennzeichnet, dass die Sourceadresse
jede drahtlose Terminaladresse, und dass die Zieladresse die Default-Route
ist. Eintreffender Datenverkehr ist dadurch gekennzeichnet, dass die
Sourceadresse die Default-Route, und die Zieladresse eine beliebige
Adresse eines drahtlosen Terminals ist.
-
Der
Zentralcontroller überwacht
laufend, wie häufig
unterschiedliche Sourceadressen und/oder Zieladressen auftreten.
Dies kann dadurch geschehen, dass die Anzahl der Pakete mit einer
bestimmten Sourceadresse und/oder mit einer bestimmten Zieladresse
für eine
große
Anzahl von Datenpaketen gezählt
werden, und die gezählten
Werte mit bestimmten Schwellenwerten verglichen werden. Damit ist
es möglich,
herauszufinden, welche Sourceadressen oder Zieladressen häufiger als
andere auftreten.
-
Wenn
die Default-Route häufiger
auftritt als eine Zieladresse, gibt es umfangreichen ausgehenden
Datenverkehr. Wenn der Zentralcontroller nicht identisch mit dem
Gateway ist, wird viel reflektierter Datenverkehr erzeugt. In diesem
Fall schlägt
der Zentralcontroller vor, einen Handover-Prozess von Steuerfunktionalität auf das
Gateway 16 durchzuführen,
um reflektierten Datenverkehr zu vermeiden.
-
Wenn
die Default-Route häufiger
als eine Sourceadresse auftritt, gibt es sehr viel eintreffenden Datenverkehr.
Auch in diesem Fall wird viel überflüssiger reflektierter
Datenverkehr erzeugt, wenn der Zentralcontroller nicht dem Gateway
entspricht. Auch in diesem Fall wird der Zentralcontroller einen
Handover-Prozess von Steuerfunktionalität auf das Gateway 16 vorschlagen,
um das Ausmaß des
reflektierten Datenverkehrs zu reduzieren.
-
Der
Schutzbereich der Erfindung ist nicht auf das Übertragen der Steuerfunktionalität auf das Gateway
beschränkt.
Durch das Überwachen
der Häufigkeit
des Auftretens der Sourceadressen und/oder der Zieladressen der
Datenpakete kann jede Geräteadresse,
die häufig
auftritt, ermittelt werden. Wenn die Adresse eines bestimmten Geräts öfter als
eine Quellen- oder Zieladresse auftritt, kann es nützlich sein,
die Steuerfunktionalität
auf dieses Gerät
zu übertragen,
da dies das Ausmaß des
reflektierten Datenverkehrs reduziert.
-
Bevor
der Handover-Prozess der Steuerfunktionalität ausgeführt wird, muss geprüft werden, ob
das Gateway, oder, allgemeiner, das bestimmte Gerät, dessen
Adresse häufig
auftritt, dazu im Stande ist, als Controller des Netzwerks zu agieren.
Diese Überprüfung wird
in Schritt 21 durchgeführt.
Der Handover-Prozess wird nur dann initiiert, wenn das Gateway ein
Controller-fähiges
Gerät ist.
Um die Controller-Fähigkeiten
der verschiedenen Netzwerkgeräte zu
verfolgen, unterhält
der Zentralcontroller eine lokale Datenbank. Die lokale Datenbank
enthält einen Eintrag
für jedes
Gerät des
Netzwerks, der anzeigt, ob das jeweilige Gerät Controller-fähig ist
oder nicht. Immer dann, wenn ein neues Gerät in das Geräte-Netzwerk aufgenommen
wird, wird der Datenbank ein Eintrag zugefügt.
-
Um
den Handover-Prozess der Steuerfunktionalität zu initiieren, wird ein Controller-Handover-Antrag 22 von
dem vorangehenden Zentralcontroller 15 an das Controller-fähige Gateway 16 gesandt.
Das Controller-fähige
Gateway 16 akzeptiert den Handover-Antrag durch Rücksenden
einer Controller-Handover-Nachricht 23 an den ehemaligen Zentralcontroller 15.
Der ehemalige Zentralcontroller 15 benachrichtigt alle
Geräte,
die Teil des Netzwerks sind, das dieser nicht länger als Controller agiert,
und dass die Steuerfunktionalität
an das Controller-fähige Gateway 16 übergeben
wird. Zusätzlich
informiert der ehemalige Zentralcontroller 15 dessen eigene Konvergenzschicht,
dass dieser nicht mehr als Controller fungiert.
-
Bis
zu diesem Zeitpunkt war der ehemalige Zentralcontroller 15 für das Updaten
und Pflegen der Datenbank zuständig,
die Information über
die Controller-Fähigkeiten
verschiedener Geräte
enthält.
Die Datenbank muss an das Controller-fähige Gateway 16 übergeben
werden, wenn die Steuerfunktionalität dem Controllerfähigen Gateway 16 zu übertragen
ist. Dann beendet der ehemalige Zentralcontroller 15 (Schritt 24)
seine Arbeit als Controller des Netzwerks.
-
In
Schritt 25 wird das Controller-fähige Gateway 16 der
neue Zentralcontroller des Netzwerks. Von nun an ist das Gateway 16 als
neuer Zentralcontroller für
das Abdaten bzw. Erhalten der Datenbank zuständig. Der ehemalige Zentralcontroller 15 wird als
drahtloses Terminal, das durch das Gateway 16 gesteuert
wird, als Teil des Netzwerks aufgenommen. Alle Geräte, die
Teil des Netzwerks sind, werden darüber benachrichtigt, dass das
Gateway 16 die Steuerfunktionalität übernommen hat, und dass diese
in Zukunft durch das Gateway 16 gesteuert werden.
-
Jetzt
wird ausgehender Verkehr 26, der durch das drahtlose Terminal 14 gesendet
wurde, direkt an das Gateway 16 übertragen, dass der Zentralcontroller
des Netzwerks ist. Von dort wird der ausgehende Verkehr an die externen
Netzwerke verteilt. Ein reflektierter Datenstrom innerhalb des Geräte-Netzwerks
tritt nicht mehr auf. Eintreffender Datenverkehr 27, der
bei dem Gateway 16 ankommt, wird direkt zu dessen jeweiligem
Ziel, d. h. zu dem drahtlosen Terminal 14, weitergeleitet.
Auch hier treten reflektierte Datenströme nicht mehr auf.
-
In 3 ist
ein Flussdiagramm zur Implementierung der Erfindung gezeigt. Das
Programm, das durch dieses Flussdiagramm repräsentiert wird, kann entweder
in Form von Hardware oder in Form von Software realisiert sein.
Das Programm wird von dem Gerät,
das als Zentralcontroller des Netzwerks agiert, ausgeführt.
-
Wenn
das Programm gestartet wird (28), geht dieses in den wait_for_data-Modus 29.
In diesem Modus wartet der Zentralcontroller auf Datenpakete von
anderen Terminals des Netzwerks. Im Schritt 30, Receive_Data,
empfängt
der Zentralcontroller Datenpakete, die von einem anderen Gerät des Netzwerks
ausgesandt wurden. Jedes Datenpaket weist einen Header auf, der
die Source-Adresse und die Zieladresse des Datenpakets enthält. In Schritt 311,
Am_I_Destination prüft
der Zentralcontroller, ob die Zieladresse der Datenpakete die Adresse
des Zentralcontrollers ist (32, Am_I_Destination = RICHTIG),
oder ob die Datenpakete an ein weiteres Gerät (35, Am_I_Destination
= FALSCH) weitergeleitet werden müssen. Wenn das Ziel der Datenpakete
der Zentralcontroller selbst ist, schickt der Controller die Datenpakete
zu dessen eigener Konvergenzschicht weiter. Dies wird in Schritt 33,
Send_Data_to_higher layer, getan. Dann geht der Controller in den wait_for_data-Modus 34 über.
-
Wenn
das Ziel der Pakete nicht der Zentralcontroller selbst ist (35,
Am_I_Destination = FALSCH), reflektiert der Zentralcontroller die
Datenpakete in Schritt 36, Reflect_data_on_network, zu der
Zieladresse der Datenpakete. In Schritt 37, Is_destination_default_route,
prüft der
Controller, ob das Ziel der Datenpakete ein externes Netzwerk ist oder
nicht. Die so genannte Default-Route ist die Adresse externer Geräte. Der
gesamte Datenverkehr zu und von diesen Geräten wird über das Gateway des Netzwerks
geleitet. In dem Fall, in dem das Ziel der Datenpakete ein Gerät des ad-hoc-Netzwerks
ist (38, Is_destination_default_route = FALSCH), geht der
Controller in den wait_for_data-Modus 39 über.
-
Wenn
das Ziel der Datenpakete die Default-Route ist (40, Is_destination_default_route
= RICHTIG), wäre
es vorteilhaft, die Steuerfunktionalität dem Gateway zu übertragen.
Bevor der Handover-Prozess initiiert wird, überprüft der Zentralcontroller in
Schritt 41, Is_gateway_controller_capable, ob das Gateway
ein Controller-fähiges
Gerät ist
oder nicht. Diese Information wird aus der lokalen Datenbank ermittelt,
die durch den Zentralcontroller unterhalten wird. Wenn das Gateway
nicht Controller-fähig ist
(42, Is_gateway_controller_capable = FALSCH), ist es nicht
möglich,
einen Handover-Prozess
durchzuführen,
und der Zentralcontroller geht in den wait_for_data_Modus 39 über.
-
Wenn
das Gateway Controller-fähig
ist (43, Is_gateway_controller_capable = RICHTIG), wird
ein Handover-Prozess der Steuerfunktionalität von dem Zentralcontroller
auf das Controller-fähige
Gateway initiiert. In Schritt 44 wird ein Controller-Handover-Antrag
Send_Controller_Handover_Req von dem Zentralcontroller zu dem Gateway
gesandt. Dann geht der Zentralcontroller in den wait_for_Handover-Modus 45 über. Bevor
der Handover-Prozess der Steuerfunktionalität durchgeführt wird, muss das Gateway bestätigen, dass
dieses der neue Zentralcontroller ist, indem eine Controller-Handover-Bestätigung an den
Zentralcontroller gesandt wird. In Schritt 46, Receive_Controller_Handover_Ack,
empfängt
der Zentralcontroller die Bestätigung
des Controller-fähigen
Gateways.
-
In
Schritt 47, Execute_Handover, wird die Steuerfunktionalität von dem
Zentralcontroller an das Gateway übertragen, das der neue Zentralcontroller wird.
Zusätzlich
wird die Datenbank von dem älteren Zentralcontroller
an den neuen Zentralcontroller übertragen.
Sobald das Controller-fähige
Gateway als neuer Zentralcontroller agiert, übernimmt dieses auch Verantwortung
für das
Erhalten und das Updaten der Datenbank.
-
In
Schritt 48, Disable_Controller_Functions, beendet der vorherige
Zentralcontroller seine Arbeit als Controller des Netzwerks. Der
ehemalige Zentralcontroller sendet eine Nachricht an alle Geräte des Netzwerks,
um diese darüber
zu informieren, dass diese nicht mehr durch den ehemaligen Zentralcontroller
gesteuert werden. Der ehemalige Zentralcontroller wird zu einem
Terminal, das Teil des Netzwerks ist, und das durch den neuen Zentralcontroller
gesteuert wird. In Schritt 49 wir die Routine beendet.
-
In
der in 3 gezeigten Ausführungsform ist es nur möglich, die
Steuerfunktionalität
des Netzwerks an ein Gateway zu übertragen.
Die Erfindung ist nicht auf diese Ausführungsform beschränkt. Um reflektierte
Datenströme
zu vermeiden, kann die Steuerfunktionalität jedem beliebigen Terminal übertragen
werden, wenn dieses Terminal in viel reflektierten Datenverkehr
involviert ist.