DE60110064T2

DE60110064T2 - Optimierung des Datenverkehrs in einem feststehenden ad-hoc Netz

Info

Publication number: DE60110064T2
Application number: DE60110064T
Authority: DE
Inventors: Frank Dawidowsky; Lothar Stadelmeier
Original assignee: Sony International Europe GmbH
Current assignee: Sony Deutschland GmbH
Priority date: 2001-09-03
Filing date: 2001-09-03
Publication date: 2006-03-02
Anticipated expiration: 2021-09-04
Also published as: EP1289199A1; US20030058819A1; EP1289199B1; US7499429B2; DE60110064D1

Description

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.

Claims

Verfahren zur Optimierung von Datenverkehr in einem ad-hoc aufgebauten Geräte-Netzwerk mit einem Zentralcontroller (3) und mehreren Terminals (1, 2), wobei alle Daten, die von einem ersten Terminal (1) zu einem zweiten Terminal (2) zu übertragen sind, über den Zentralcontroller geleitet werden, gekennzeichnet durch – Ü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 (3) geleitet wird; – Überprüfen (21), 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 (3) geleitet wird; – Ausführen eines Handover-Prozesses (22, 23) bezüglich der Steuerfunktionalität, wenn das bestimmte Terminal als Controller agieren kann, um das bestimmte Terminal zum neuen Zentralcontroller (10) zu machen.
Verfahren nach Anspruch 1, gekennzeichnet durch Assoziieren des früheren Zentralcontrollers (3) als Terminal (11) mit dem neuen Zentralcontroller (10).
Verfahren nach Anspruch 1 oder dem Anspruch 2, gekennzeichnet durch Verfolgen der Sourceadressen von Datenpaketen durch den Zentralcontroller (3), um festzustellen, welche Datenverkehrs-Menge von dem bestimmten Terminal über den Zentralcontroller (3) geleitet wird.
Verfahren nach Anspruch 3, gekennzeichnet durch Zählen des Auftretens der Adresse des bestimmten Terminals durch den Zentralcontroller (3) immer dann, wenn die Adresse als Sourceadresse eines Datenpakets benutzt wird.
Verfahren nach einen der vorstehenen Ansprüche, gekennzeichnet durch Verfolgen der Zieladressen von Datenpaketen durch den Zentralcontroller (3), um festzustellen, welche Datenverkehrs-Menge zu dem bestimmten Terminal über den Zentralcontroller (3) geleitet wird.
Verfahren nach Anspruch 5, gekennzeichnet durch Zählen des Auftretens der Adresse des bestimmten Terminals durch den Zentralcontroller (3) immer dann, wenn die Adresse als Zieladresse eines Datenpakets eingesetzt wird.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das bestimmte Terminal ein Gateway (2) ist, das das Geräte-Netzwerk mit einem externen Netzwerk (5) verbindet.
Verfahren nach Anspruch 7, gekennzeichnet durch Überwachen des eintreffenden Datenverkehrs (6, 7) durch den Zentralcontroller (3), der durch das Gateway (2) von dem externen Netzwerk (5) empfangen wird und über den Zentralcontroller (3) zu einem Zielgerät (1) geleitet wird.
Verfahren nach Anspruch 7 oder 8, gekennzeichnet durch Überwachen des ausgehenden Datenverkehrs (8, 9) durch den Zentralcontroller (3), der über den Zentralcontroller (3) von einem Ausgangsgerät zu dem Gateway (2) geleitet wird und durch das Gateway (2) zum externen Netzwerk (5) gesandt wird.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass geprüft wird (21), ob das bestimmte Terminal dazu im Stande ist, als Controller zu agieren, indem eine Datenbank zu Hilfe genommen wird, die durch den Zentralcontroller (3) verwaltet wird.
Verfahren nach Anspruch 10, gekennzeichnet durch Hinzufügen eines neuen Eintrags in die Datenbank, wenn ein neues Terminal an das Geräte-Netzwerk angeschlossen wird.
Verfahren nach einem der vorstehenden Ansprüche, gekennzeichnet durch Informieren jedes Geräts des Netzwerks, dass dieses nicht länger durch den alten Zentralcontroller (3) kontrolliert/gesteuert wird, und dass dieses in Zukunft durch den neuen Zentralcontroller (10) gesteuert wird, immer dann, wenn ein Handover-Prozess bezüglich der Steuerfunktionalität ausgeführt wird.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Netzwerk ein drahtloses Netzwerk ist.
Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass das Netzwerk ein drahtloses Netzwerk gemäß dem HIPERLAN/2-Standard ist.
Zentralconroller zum Steuern mehrerer Terminals (1, 2) in einem ad-hoc aufgebauten Geräte-Netzwerk, in dem alle von einem ersten Terminal (1) zu einem zweiten Terminal (2) zu übertragenden Daten über den Zentralcontroller geleitet werden, gekennzeichnet durch – eine Einrichtung zum Überwachen des Datenverkehrs, um hinsichtlich eines bestimmten Terminals festzustellen, welche Datenverkehrs-Menge von dem bestimmten Terminal und/oder zu dem bestimmten Terminal über den Zentralcontroller (3) geleitet wird; – eine Prüfungseinheit zum Prüfen (21), ob das bestimmte Terminal dazu im Stande ist, als Controller zu fungieren; – eine Handover-Einheit zur Ausführung eines Handover-Prozesses bezüglich der Steuerfunktionalität an das bestimmte Terminal, wenn zumindest eine bestimmte Datenverkehrs-Menge von den bestimmtem Terminal und/oder zu dem bestimmten Terminal über den Zentralcontroller (3) geleitet wird.
Zentralcontroller nach Anspruch 15, gekennzeichnet durch eine Einrichtung zum Verfolgen der Sourceadresse von Datenpaketen, um festzustellen, welche Datenverkehrs-Menge von dem bestimmten Terminal über den Zentralcontroller (3) geleitet wird.
Zentralcontroller nach Anspruch 15 oder 16, gekennzeichnet durch eine Einrichtung zum Verfolgen der Zieladresse von Datenpaketen, um festzustellen, welche Datenverkehrs-Menge zu dem bestimmten Terminal über den Zentralcontroller (3) geleitet wird.
Zentralcontroller nach einem der Ansprüche 15 bis 17, dadurch gekennzeichnet, dass das bestimmte Terminal ein Gateway (2) ist, das das Geräte-Netzwerk mit einem externen Netzwerk (5) verbindet.
Zentralcontroller nach einem der Ansprüche 15 bis 18, gekennzeichnet durch eine Datenbank zum Speichern von Information bezüglich der Controller-Fähigkeit der Terminals.
Zentralcontroller nach Anspruch 19, gekennzeichnet durch eine Einrichtung zum Hinzufügen eines neuen Eintrags in die Datenbank, was immer dann erfolgt, wenn ein neues Terminal in das Netzwerk eingebracht wird.
Computerprogrammprodukt mit Programmcode zur Ausführung der Schritte des Verfahrens in einem der Ansprüche 1 bis 14, wenn der Code auf einem Computer und/oder einem Zentralcontroller ausgeführt wird.
Computerprogrammprodukt mit Programmcode gemäß Anspruch 21, das auf einem für einen Computer und/oder Zentralcontroller zugänglichen Speichermedium gespeichert ist.