DE102004021385A1 - Datenkommunikationsnetzwerk mit dezentralem Kommunikationsmanagement - Google Patents

Datenkommunikationsnetzwerk mit dezentralem Kommunikationsmanagement Download PDF

Info

Publication number
DE102004021385A1
DE102004021385A1 DE102004021385A DE102004021385A DE102004021385A1 DE 102004021385 A1 DE102004021385 A1 DE 102004021385A1 DE 102004021385 A DE102004021385 A DE 102004021385A DE 102004021385 A DE102004021385 A DE 102004021385A DE 102004021385 A1 DE102004021385 A1 DE 102004021385A1
Authority
DE
Germany
Prior art keywords
node
packet
network
network node
connection
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102004021385A
Other languages
English (en)
Inventor
Stephan Dipl.-Ing. Hemberger (FH)
Ingo Dipl.-Ing. Kreuz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mercedes Benz Group AG
Original Assignee
DaimlerChrysler AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by DaimlerChrysler AG filed Critical DaimlerChrysler AG
Priority to DE102004021385A priority Critical patent/DE102004021385A1/de
Priority to US11/587,823 priority patent/US20080075020A1/en
Priority to PCT/EP2005/003811 priority patent/WO2005107179A1/de
Publication of DE102004021385A1 publication Critical patent/DE102004021385A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/26Route discovery packet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/005Discovery of network devices, e.g. terminals

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Die Erfindung bezieht sich auf ein Datenkommunikationsnetzwerk mit einer Mehrzahl von Netzknoten, die jeweils einen oder mehrere Kommunikations-Ports und eine identifizierende Knoten-ID aufweisen und darauf ausgelegt sind, Verbindungen dezentral zu verwalten und Datenpakete eines ungerichteten Typs und eines gerichteten Typs zu übertragen, wobei die Datenpakete eine Header-Information wenigstens über Pakettyp und Knoten-ID des paketerzeugenden Netzknotens enthalten. DOLLAR A Erfindungsgemäß ist in jedem vollimplementierten Netzknoten des Netzwerks eine spezielle Nachbarüberwachungs-Funktionalität, eine spezielle Broadcast-Funktionalität und/oder eine spezielle Verbindungsaufbau-Funktionalität derart implementiert, dass sich ein selbstorganisierendes Kommunikationsmanagement allein mittels dezentraler, lokaler Maßnahmen ergibt, so dass sich das Netzwerk als verteiltes System realisieren lässt, das keine zentralen Instanzen benötigt und dabei Forderungen hinsichtlich Robustheit, Topologieflexibilität, Erweiterbarkeit und Skalierbarkeit, Gleichteileverwendbarkeit, Universalität und Echtzeitfähigkeit erfüllt. DOLLAR A Verwendung z. B. für Datenkommunikationsnetzwerke in Kraftfahrzeugen.

Description

  • Die Erfindung bezieht sich auf ein Datenkommunikationsnetzwerk mit einer Mehrzahl von Netzknoten, die jeweils einen oder mehrere Kommunikations-Ports und eine identifizierende Knoten-ID aufweisen und darauf ausgelegt sind, Verbindungen untereinander dezentral zu verwalten und Datenpakete eines ungerichteten Typs und eines gerichteten Typs zu übertragen, wobei die Datenpakete eine Header-Information wenigstens über die Knoten-ID des paketerzeugenden Netzknotens enthalten.
  • Datenkommunikationsnetzwerke dieser Art, die sogenannte verteilte Systeme bilden, sind in verschiedenen Ausprägungen bekannt. Mit dem Begriff Datenkommunikationsnetzwerk wird vorliegend, wie auf dem Fachgebiet der elektronischen Datenverarbeitung üblich, ein Netzwerk, d.h. im graphentheoretischen Sprachgebrauch ein Graph aus beliebigen Netzknoten und Netzkanten, verstanden, bei dem die Netzknoten von physikalischen Einheiten mit Datenkommunikations- bzw. Datenverarbeitungsfähigkeit gebildet sind, üblicherweise aus diesem Grund auch als Zellen oder Recheneinheiten bezeichnet, und die Netzkanten von drahtgebundenen oder drahtlosen Datenübertragungsstrecken gebildet sind. Häufig sind komplexe eingebettete Datenkommunikationssysteme als derartige Netzwerke realisiert. Ein Beispiel sind Netzwerke, wie sie in modernen Kraftfahrzeugen zur Anwendung kommen, bei denen eine Vielzahl von Steuergeräten und andere Einheiten mit Datenkommunikations- bzw. Datenverarbeitungsfähigkeit als Netzknoten fungieren, die über Datenbusleitungen vernetzt sind.
  • Über die Verbindungen zwischen Netzknoten werden Datenpakete unterschiedlichen Typs übertragen, einschließlich eines ungerichteten und eines gerichteten Typs. Datenpakete vom ungerichteten Typ, auch als „Broadcast-Typ" bezeichnet, sind solche, die vom jeweiligen Netzknoten ungerichtet auf allen seinen aktivierten Ports abgegeben werden, mit Ausnahme desjenigen Ports, auf dem das Datenpaket empfangen worden ist, wenn es sich nicht um den das Datenpaket erzeugenden Netzknoten handelt. Datenpakete vom gerichteten Typ, auch als verbindungsorientierter bzw. "Connection-Oriented"-Typ bezeichnet, sind solche, die gezielt an einen vorgebbaren Ziel-Netzknoten gesendet werden.
  • Gegenüber Netzwerken mit zentralem Kommunikationsmanagement haben die vorliegend betrachteten dezentralen Netzwerke den Vorteil, dass sie keine zentralen Einheiten, wie zentrale Router-Einheiten oder Name-Server-Einheiten benötigen. Dies erhöht im allgemeinen die Robustheit des Systems, da eine Störung in einer zentralen Einheit häufig zu einem Ausfall des gesamten Netzwerks führt. Die Robustheit, d.h. Unanfälligkeit gegenüber Störungen, ist insbesondere bei sicherheitskritischen Systemen, wie Fahrzeugen, ein wichtiges Kriterium. Zur Erfüllung der Forderung nach Robustheit für das System sollte auch die Kommunikation zwischen den Netzknoten robust ausgelegt sein. Dazu ist es wünschenswert, die Kommunikationswege bei Bedarf beliebig redundant auslegen zu können, Störungen zuverlässig erkennen und im restlichen Netzwerk bekannt machen zu können und die Auswirkungen von Störungen lokal halten zu können, so dass eine Störung in einem Kommunikationspfad oder Kommunikationsabschnitt nicht die gesamte Netzwerkkommunikation beeinträchtigt.
  • Des weiteren ist es zur Erzielung einer maximalen Entwurfsfreiheit und damit einer maximalen Flexibilität zur Anpassung an eine jeweils gegebene Aufgabenstellung wünschenswert, dass das Kommunikationsmanagement beliebige Netzwerktopologien unterstützt, wie die bekannten Bus-, Stern-, Ring- oder Baumtopologien oder Mischformen hiervon. Das Kommunikationsmanagement sollte zudem bestmöglich die Forderung nach Erweiterbarkeit und Skalierbarkeit erfüllen, d.h. es sollten mit möglichst geringem Aufwand Netzwerkvarianten realisiert werden können, die sich nur in ihrer Leistungsfähigkeit unterscheiden, indem mehr oder weniger Ressourcen des gleichen Typs eingesetzt werden, bzw. sollte das Netzwerk durch Erweiterung um spezifische Komponenten auf ein bestimmtes Einsatzgebiet spezialisiert werden können.
  • Zur Einsparung von Entwicklungs- und Produktionskosten ist es vorteilhaft, wenn möglichst nur gleichartige Komponenten im Netzwerk zum Einsatz kommen, was für die Kommunikation die Verwendung möglichst nur eines skalierbaren Verbindungstyps bedeutet. Des weiteren besteht die Forderung nach Universalität des Kommunikationsmanagements, so dass z.B. sichergestellt werden kann, dass die Kommunikation unabhängig vom eingesetzten Medium benutzt werden kann und auf physikalischer Ebene Standards eingesetzt werden können.
  • In vielen Fällen besteht zudem die Forderung nach Echtzeitfähigkeit. Dies gilt z.B. für eingebettete Systeme mit Steuerungsfunktionalitäten, wie dies bei den erwähnten Netzwerken in Kraftfahrzeugen der Fall ist, die ein wichtiges Anwendungsbeispiel der Erfindung darstellen. Für die Kommunikation bedeutet dies den Wunsch, eine sogenannte Dienstqualität ("Quality of Service", QoS) einhalten zu können, d.h. eine gewisse Bandbreite und maximale Übertragungsverzögerung beim Verbindungsaufbau vorgeben zu können, die danach vom Netzwerk eingehalten werden.
  • Die Forderungen hinsichtlich Fehlens zentraler Einheiten, Erweiterbarkeit, Skalierbarkeit und Verwendung gleichartiger Komponenten lassen sich unter dem Gesichtspunkt der Hardware-Topologie durch Verwenden von Netzknoten erfüllen, die zumindest in ihren Kommunikationsfähigkeiten, wie Protokolle, Routing und Schnittstellen, identisch sind. Zur Erfüllung der Forderung, dass Störungen nur lokale Auswirkungen haben, ist es zweckmäßig, dass an jeder Kommunikationsschnittstelle nur wenige Kommunikationspartner angeschlossen sind, im Idealfall nur einen Partner, was Punkt-zu-Punkt-Verbindungen bedeutet. Zur Kommunikation zwischen indirekt verbundenen Netzknoten sind in jedem Netzknoten Routing-Funktionalitäten implementiert. Wenn beliebige Redundanzen und Netztopologien realiesierbar sein sollen, muss jeder voll implementierte Netzknoten mindestens mit drei Partnern direkt kommunizieren können, d.h. drei Ports besitzen. Denn mit einer Kommunikationsschnittstelle sind auf Hardware-Ebene nur Busverdrahtungen möglich und mit zwei Schnittstellen zusätzlich Ring-Topologien, während erst drei Schnittstellen Verzweigungen und damit beliebige Netztopologien ermöglichen.
  • Der Erfindung liegt als technisches Problem die Bereitstellung eines Datenkommunikationsnetzwerks der eingangs genannten Art zugrunde, das je nach Systemauslegung in der Lage ist, alle oder jedenfalls einen großen Teil der oben genannten Systemanforderungen mit relativ geringem Aufwand zu erfüllen.
  • Die Erfindung löst dieses Problem durch die Bereitstellung eines Datenkommunikationsnetzwerks mit den Merkmalen des Anspruchs 1, 4 oder 6. Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
  • Beim Datenkommunikationsnetzwerk nach Anspruch 1 ist in jedem vollimplementierten Netzknoten eine spezielle Nachbarüberwachungs-Funktionalität implementiert. Mit dem Begriff "voll-implementiert" sind vorliegend diejenigen Netzknoten gemeint, in denen die betreffende Funktionalität in vollem Umfang implementiert ist. Dies sind typischerweise alle Netzknoten des Netzwerks oder wenigstens die meisten, wobei je nach Anwendungsfall eventuell einige, insbesondere periphere, Netzknoten nicht voll implementiert sind, d.h. die betreffende Funktionalität nicht oder nicht in vollem Umfang aufweisen.
  • Die erfindungsgemäße Nachbarüberwachungs-Funktionalität umfasst das periodische Versenden eines speziellen nachbarüberwachenden Datenpakets, vorliegend als Ping-Datenpaket bezeichnet. Dieses wird vom jeweiligen Netzknoten periodisch auf allen seinen Ports gesendet und besitzt in seinem Kopfteil, d.h. als Header-Information, die Information über die Knoten-ID des Netzknotens und vorzugsweise auch die Information, dass es sich um einen entsprechenden Ping-Pakettyp handelt. Darüber hinaus braucht das Ping-Datenpaket keine Nutzdateninformation enthalten, d.h. es handelt sich dann um einen besonders einfachen Datenpakettyp.
  • Ein Netzknoten, der an einem seiner Ports ein Ping-Datenpaket empfängt, aktiviert diesen Port, wobei das Ping-Datenpaket nicht weitergeleitet wird. Mit dem Begriff "Aktivieren" ist vorliegend gemeint, dass der Netzknoten den entsprechenden Port zur Übertragung von Datenpaketen vom ungerichteten oder gerichteten Typ bereit macht, d.h. der Netzknoten kann über diesen Port entsprechende Datenpakete zu dem erkannten Nachbarknoten senden und von diesem empfangen.
  • Der Netzknoten führt eine zugehörige Liste von erkannten, über je einen seiner Ports mit ihm direkt verbundenen Nachbarknoten. Wenn er an einem zuvor auf diese Weise verbindungsaktiven Port innerhalb einer vorgegebenen Meldezeit kein Ping-Datenpaket und auch kein anderes Datenpaket mehr empfängt, erkennt er daran den Verlust des bisherigen dortigen Nachbarknotens. Er aktualisiert seine Nachbarknoten-Liste entsprechend und sendet ein zugehöriges Cell-Lost-Datenpaket vom ungerichteten Typ mit der Knoten-ID des verlorenen Nachbarknotens. Wenn ein Netzknoten an einem Port anhand der in einem empfangenen Ping-Datenpaket enthaltenen Knoten-ID das Vorhandensein eines neuen Nachbarknotens erkennt, aktualisiert er seine Nachbarknoten-Liste entsprechend und sendet ein zugehöriges Cell-Found-Datenpaket vom ungerichteten Typ. Diese Erkennung eines neuen Nachbarknotens umfasst die Fälle, dass am betreffenden Port zuvor kein oder ein anderer Nachbarknoten vorhanden war.
  • Es zeigt sich, dass mit dieser Nachbarüberwachungs-Funktionalität bei relativ geringem Aufwand ein flexibles, dezentrales, selbstorganisierendes Kommunikationsmanagement des Netzwerks ermöglicht wird, welches die Netzwerktopologie selbsttätig und dezentral, d.h. allein durch lokale Maßnahmen zwischen benachbarten Netzknoten, überwacht und Topologieänderungen erkennt und meldet.
  • Da das Ping-Datenpaket kurz gehalten werden kann und nicht weitergeleitet werden braucht, verursacht diese Nachbarüberwachung nur eine sehr kleine Übertragungs-Grundlast für das Netzwerk. Das Ping-Datenpaket ist der einzige Nachrichtentyp, der periodisch, d.h. zyklisch, übertragen werden muss. Alle anderen Informationen können ereignisgesteuert gesendet werden, ohne Zuverlässigkeitsprobleme zu erzeugen. Dies hat eine sehr geringe mittlere Netzwerklast zur Folge. Während in herkömmlichen sicherheitskritischen Netzwerken unter anderem auch sensible Aktivierungssignale typischerweise zyklisch übertragen werden, um bei Kommunikationsstörungen automatisch in den Deaktivierungszustand zurückzufallen, genügt beim erfindungsgemäßen Netzwerk eine einmalige "Ein"- bzw. "Aus"-Nachricht, da Störungen auf einer Kommunikationsstrecke im Netzwerk durch das "Cell-Lost"-Paket signalisiert werden, auf das geeignet reagiert werden kann.
  • In einer Weiterbildung der Erfindung nach Anspruch 2 wird die Meldezeit auf eine vorgebbare Anzahl von Ping-Übertragungstakten festgelegt, z.B. auf zwei Ping-Übertragungstakte. Wenn somit zwei bzw. die vorgegebene Anzahl von Ping-Datenpaketen ausbleiben und während dieser Zeit auch keine anderen Datenpakete empfangen werden, wird dies als Verlust eines bisherigen Nachbarknotens am betreffenden Port interpretiert.
  • Bei einem nach Anspruch 3 weitergebildeten Netzwerk ist eine Reregister- bzw. Neuregistrierungs-Funktionalität implementiert, die das Senden eines entsprechenden Reregister-Datenpakets vom ungerichteten Typ durch einen Netzknoten beinhaltet, wenn dieser ein Cell-Found- oder Cell-Lost-Datenpaket empfängt. Diese Neuregistrierungs-Funktionalität ermöglicht es dem Netzwerk bei lokal erkannten Topologieänderungen die in den einzelnen Netzknoten benötigten Topologie-Informationen geeignet zu aktualisieren, so dass insbesondere auch der spezielle Fall einer Verbindung von Netzwerkinseln durch einen oder mehrere hinzukommende Netzknoten selbstorganisierend ohne zentrale Instanzen bewältigt werden kann.
  • Beim Datenkommunikationsnetzwerk nach Anspruch 4 ist in jedem vollimplementierten Netzknoten eine spezielle Broadcast-Funktionalität implementiert, die so konzipiert ist, dass die Kommunikationslast des Netzwerks gering gehalten werden kann, ohne die Übertragungszuverlässigkeit zu beeinträchtigen. Im Kern besteht die Maßnahme darin, dass der jeweilige Netzknoten beim Empfang eines Broadcast-Datenpakets prüft, ob er selbiges schon einmal früher empfangen hat, und es nur dann weiterleitet, wenn dies nicht der Fall ist, während er es ansonsten verwirft. Dazu besitzt jedes Broadcast-Datenpaket eine identifizierende Broadcast-Paket-ID, und die Netzknoten führen jeweils eine Liste der IDs bereits empfangener Broadcast-Datenpakete, z.B. unter Verwendung eines Ringpuffers ausreichender Kapazität, d.h. die Länge des Ringpuffers ist so ausgelegt, dass bei maximalem Broadcast-Datenverkehr die IDs aller Broadcast-Datenpakete gespeichert werden können, die während der Zeitdauer auftreten, die ein Broadcast-Datenpaket maximal, d.h. im längsten Zyklus des Netzwerks, unterwegs sein kann. Mit dieser Broadcast-Funktionalität wird das unnötige, redundante Weiterleiten von Broadcast-Datenpaketen in hohem Maß vermieden.
  • In einer Weiterbildung der Erfindung nach Anspruch 5 wird auf jedem Port der Netzknoten eine Grundbandbreite für die Broadcast-Datenpakete reserviert. Dies bedeutet noch keine Vorgabe einer bestimmten QoS. Daher kommen alle Broadcast-Datenpakete sicher an, jedoch ist kein bestimmter Ankunftszeitpunkt garantiert.
  • Beim Datenkommunikationsnetzwerk nach Anspruch 6 ist in jedem vollimplementierten Netzknoten eine spezielle Verbindungsaufbau-Funktionalität implementiert, durch die es wiederum ohne Zuhilfenahme zentraler Instanzen ermöglicht wird, optimale Verbindungspfade für die Übertragung von Datenpaketen des ge richteten Typs aufzubauen. Dazu sendet ein initiierender Quellen-Netzknoten zunächst ein Verbindungsanforderungs-Datenpaket („Connection-Request-Packet, CRP) als ungerichtete Broadcast-Nachricht mit einer Dateninformation, anhand derer sich der Ziel-Netzknoten als ein solcher erkennt. Jeder Netzknoten, der das CRP empfängt, markiert, wenn er das CRP zum ersten Mal empfängt, den betreffenden Port als einen ersten Routing-Port mittels eines Eintrags in eine gespeicherte Liste mit Routing-Information. Der Ziel-Netzknoten sendet nach Empfang des CRP ein Bestätigungspaket („Connection-Acknowledge-Packet", CAP) nur auf dem Port, auf dem er das CRP zuerst empfangen hat. Jeder Zwischen-Netzknoten, der das Bestätigungs-Paket empfängt, leitet es auf seinem markierten ersten Routing-Port weiter und markiert den empfangenden Port als seinen zweiten Routing-Port.
  • Der Quellen-Netzknoten erkennt am Empfang des Bestätigungs-Pakets, dass der Verbindungspfad zum Ziel-Netzknoten aufgebaut ist, und kommuniziert dann verbindungsorientiert über den Port, an welchem er das Bestätigungs-Paket empfangen hat. Auf diese Weise ist das Netzwerk wiederum selbstorganisierend und ohne zentrale Instanzen in der Lage, einen optimalen Verbindungspfad für gerichtete Nachrichten aufzubauen.
  • In einer Weiterbildung der Erfindung nach Anspruch 7 sendet der Quellen-Netzknoten nach Empfang des Bestätigungs-Pakets ein Verbindungsaufbau-beendet-Paket vom Broadcast-Typ. Alle Netzknoten, die dieses vor dem Bestätigungs-Paket empfangen, sind nicht im aufgebauten Verbindungspfad und löschen ihre Markierung des ersten Routing-Ports. Damit sind alle unbeteiligten Netzknoten zurückgesetzt.
  • In einer Weiterbildung der Erfindung nach Anspruch 8 ist für die Datenpakete vom gerichteten Typ eine gewünschte QoS vorgegeben.
  • In einer Weiterbildung der Erfindung nach Anspruch 9 ist eine spezielle Verbindungsabbau-Funktionalität implementiert, gemäß der ein zuvor aufgebauter Verbindungspfad für gerichtete Nachrichten wieder abgebaut wird. Dies kann vom Quellen- oder Ziel-Netzknoten oder einem Zwischen-Netzknoten initiiert werden, jeweils durch Senden eines geeigneten Verbindungsende-Datenpakets vom gerichteten Typ, das zur Folge hat, dass alle Netzknoten entlang des Verbindungspfades ihre Routing-Markierungen wieder löschen.
  • In einer Ausgestaltung der Erfindung nach Anspruch 10 ist eine Funktionalität zur Meldung von Unterbrechungen einer aufgebauten Verbindung vorgesehen, die das Senden eines Verbindungsunterbrechungs-Datenpakets als Verbindungsende-Paket durch einen jeweiligen Netzknoten beinhaltet, wenn dieser den Verlust eines Nachbarknotens feststellt, zu dem er einen markierten Routing-Port hat.
  • In einer weiteren Ausgestaltung ist nach Anspruch 11 das Netzwerk so ausgelegt, dass der Quellen-Netzknoten in Reaktion auf den Empfang eines Verbindungsunterbrechungs-Pakets einen erneuten Verbindungsaufbauversuch unternimmt, indem er ein neues Verbindungsanforderungs-Paket erzeugt und sendet.
  • Vorteilhafte Ausführungsformen der Erfindung sind in den Zeichnungen dargestellt und werden nachfolgend beschrieben. Hierbei zeigen:
  • 1 ein schematisches Blockdiagramm von Netzknoten eines dezentralen, selbstorganisierenden Datenkommunikati onsnetzwerks zur Veranschaulichung einer Nachbarüberwachungs-Funktionalität,
  • 2 bis 10 schematische Blockdiagramme von Netzknoten eines dezentralen, selbstorganisierenden Datenkommunikationsnetzwerks zur Veranschaulichung einer Broadcast-Funktionalität in aufeinanderfolgenden Betriebszyklen,
  • 11 bis 29 schematische Blockdiagramme der Netzknoten gemäß den 1 bis 10 zur Veranschaulichung einer Verbindungsaufbau-Funktionalität in aufeinanderfolgenden Betriebszyklen,
  • 30 bis 35 schematische Blockdiagramme der Netzknoten gemäß den 2 bis 10 zur Veranschaulichung einer Verbindungsabbau-Funktionalität in aufeinanderfolgenden Betriebszyklen,
  • 36 bis 50 schematische Blockdiagramme der Netzknoten gemäß den 2 bis 10 zur Veranschaulichung eines Verbindungsaufbaus bei einem Zellenausfall,
  • 51 bis 63 schematische Blockdiagramme von Netzknoten eines dezentralen, selbstorganisierenden Datenkommunikationsnetzwerks zur Veranschaulichung einer Inselverbindung durch einen hinzukommenden Netzknoten,
  • 64 bis 70 schematische Blockdiagramme eines Verbunds aus drei Netzknoten eines selbstorganisierenden, dezentralen Datenkommunikationsnetzwerks zur Veranschaulichung eines Einschaltvorgangs,
  • 71 bis 78 schematische Blockdiagramme eines Netzwerkbeispiels zur Veranschaulichung des Entfernens eines Netzknotens ohne Inselbildung,
  • 79 bis 82 schematische Blockdiagramme eines Netzwerkbeispiels zur Veranschaulichung des Entfernens eines Netzknotens mit Inselbildung,
  • 83 bis 87 schematische Blockdiagramme eines Netzwerkbeispiels zur Veranschaulichung eines vorzeitigen Verbindungsabbruchs und
  • 88 bis 99 schematische Blockdiagramme eines Netzwerkbeispiels zur Veranschaulichung einer Situation mit sich überholenden Broadcast-Nachrichten.
  • Die Erfindung wird nachfolgend anhand von Netzwerkbeispielen näher erläutert, die sich auf mögliche Realisierungen eines verteilten Datenkommunikationsnetzwerks mit selbstorganisierendem Kommunikationsmanagement beziehen, wie sie sich beispielsweise für moderne Kraftfahrzeuge eignen, bei denen Steuergeräte, Aktoren, Sensoren und andere Elektronikkomponenten miteinander entsprechend vernetzt sind. Die verschiedenen, nachfolgend beschriebenen Funktionalitäten können in einer jeweiligen Netzwerkrealisierung jeweils einzeln oder in beliebiger Kombination vorgesehen sein. In der höchsten Ausbaustufe weist das erfindungsgemäße Datenkommunikationsnetzwerk alle beschriebenen Funktionalitäten auf. Durch die nachfolgend näher beschriebenen Funktionalitäten erfüllt das erfindungsgemäße Netzwerk die verschiedenen, eingangs genannten Anforderungen, wie Robustheit, Topologieflexibilität, Erweiterbarkeit und Skalierbarkeit, Verwendung gleichartiger Komponenten, Universalität und Echtzeitfähigkeit.
  • Alle Netzknoten des erfindungsgemäßen Netzwerks haben eine eindeutige Kennung, d.h. Knoten-ID, in den Figuren durch einfache Nummerierung der Netzknoten symbolisiert. Die Informationsübertragung erfolgt in Form von Datenpaketen, die als Metainformation, d.h. Header- bzw. Kopfinformation, den Paket-Typ und die Senderadresse enthalten. Die Netzknoten implementieren Routing-Funktionalitäten, die mit lokalen Informationen über den eigenen Zustand und über direkte Nachbarknoten auskommen. Die Netzknoten enthalten sogenannte Router, die in üblicher Weise z.B. als Hardware implementiert sein können, z.B. unter Verwendung programmierbarer Logikbausteine (PLD) oder im Feld programmierbarer Gatteranordnungen (FPGA). Dadurch bleiben die Knotenfunktionen unbeeinflusst, solange der Netzknoten nur Übermittler, d.h. Gateway, und nicht Empfänger ist, was echte Parallelität ermöglicht.
  • An Kommunikationsarten sind insbesondere eine verbindungslose Kommunikation in Form von Datenpaketen eines ungerichteten Typs, d.h. Broadcast-Typs, und eine verbindungsorientierte Kommunikation in Form von Datenpaketen eines gerichteten Typs, d.h. verbindungsorientierten Typs, implementiert. Beim Broadcast-Typ empfangen alle Knoten außer dem Sender die Nachricht, wobei jedoch die Möglichkeit besteht, die Nachricht zu verwerfen. Für die Broadcast-Nachrichten wird auf jeder Leitung eine Grundbandbreite reserviert. Broadcast-Nachrichten, die nicht sofort von einem Netzknoten weitervermittelt werden können, werden lokal gepuffert. Auf diese Weise ist sichergestellt, dass irgendwann alle Broadcast-Nachrichten unabhängig von der Netzwerkbelastung übermittelt werden können. Datenpakete vom Broadcast-Typ haben keine garantierte Übertragungszeit.
  • Zur verbindungsorientierten Kommunikation wird beim Verbindungsaufbau eine Servicequalität (QoS) in Form einer maxima len Übertragungszeit und einer reservierten Bandbreite vorgegeben. Der erfindungsgemäße Algorithmus zum Verbindungsaufbau etabliert nur solche Kommunikationspfade, die der geforderten QoS genügen. Beim verbindungsorientierten Kommunikationstyp werden je zwei Netzknoten als benachbarte, direkte Kommunikationspartner logisch verbunden. Die logische Verbindung bleibt bestehen, bis sie vom Sender abgebaut, vom Empfänger abgebrochen oder fehlerbedingt unterbrochen wird. Änderungen in der Netzwerktopologie während des Betriebs werden als Broadcast-Nachricht allen Knoten im Netzwerk signalisiert.
  • Als ein spezieller zusätzlicher Datenpakettyp ist zwecks Bereitstellung einer Nachbarüberwachungs-Funktionalität ein als Ping-Datenpaket bezeichneter Pakettyp vorgesehen, der lediglich aus Header-Information mit der eigenen Knoten-ID als Absenderadresse und der Pakettypinformation "Ping" besteht und vom jeweils empfangenen Netzknoten nicht weitergeleitet wird. Jeder Netzknoten aktiviert den jeweiligen Port, wenn und sobald er auf diesem ein Ping-Datenpaket empfangen hat, und führt intern eine Tabelle mit den Knoten-ID der solchermaßen erkannten, direkten Nachbarknoten. Wenn ein neuer Nachbarknoten erkannt wurde, sei es dass für den betreffenden Port zuvor keine oder eine andere Nachbarknoten-ID in der Knoten-ID-Tabelle enthalten war, meldet der Knoten diese erkannte Topologieänderung durch ein Cell-Found-Datenpaket vom Broadcast-Typ an alle anderen Knoten im Netzwerk.
  • Der Ping-Pakettyp ist der einzige Nachrichtentyp, der periodisch übertragen wird. Die Zykluszeit zwischen zwei Ping-Datenpaketen ist auf allen Netzknoten gleich. Sobald für eine vorgebbare Anzahl an Zyklen, z.B. zwei Zyklen, kein Ping-Datenpaket und keine andere Nachricht an einem Port empfangen wurde, wertet dies der jeweilige Netzknoten dahingehend, dass ein dort zuvor angekoppelter Nachbarknoten verlorengegangen ist, z.B. wegen Entfernen des Knotens, wegen eines Defekts desselben oder wegen eines Fehlers auf der Übertragungsstrecke zu diesem Nachbarknoten. Nach Erkennen des Verlusts eines Nachbarknotens sendet der jeweilige Netzknoten ein Cell-Lost-Datenpaket vom Broadcast-Typ, das als Dateninhalt die Knoten-Idee des verlorenen Nachbarknotens enthält. Fällt ein Netzknoten aus, der zwei Subnetze miteinander verbindet, wird die Cell-Lost-Nachricht in beiden Subnetzen generiert, da die Nachbarn des ausgefallenen Knotens aus beiden Subnetzen das Ausbleiben von dessen Ping-Datenpaketen bemerken.
  • Auf Hardware-Ebene sind bis auf etwaige periphere Netzknoten alle Knoten mit identischen Kommunikationsfähigkeiten und mindestens drei Kommunikations-Ports ausgestattet, wobei letzteres beliebige Netzwerktopologien unter alleiniger Verwendung robuster Punkt-zu-Punkt-Verbindungen ermöglicht. Je nach Situation kann das Netzwerk zusätzliche periphere Netzknoten enthalten, die vereinfacht, aber kompatibel sind, indem sie z.B. nur einen Port, ein vereinfachtes Protokoll und keine Routing-Fähigkeit besitzen. Als Datenprotokolle können solche herkömmlichen Typs verwendet werden, soweit sie sich für die Bereitstellung der implementierten Funktionalitäten eignen, wie dies dem Fachmann durch die vorliegenden Informationen deutlich wird. Insbesondere eignet sich z.B. ein Datenprotokoll auf der Basis des herkömmlichen TCP/IP-Protokolls, das gemäß den vorliegenden, speziellen Funktionalitäten modifiziert ist. So benötigt das Datenprotokoll vorliegend keine hierarchischen Strukturen und keinen Domain-Name-Server.
  • 1 veranschaulicht in einem einfachen Beispiel eines Netzwerks mit neun durchnummerierten Netzknoten den Ping-Mechanismus. Hier und in allen anderen Figuren ist jeder Netzknoten durch ein Sechseck repräsentiert, wobei jede Sechseckseite einen Port repräsentiert, d.h. jeder Netzknoten besitzt sechs Ports. Längs einer Sechseckseite aneinandergrenzende Netzknoten stellen direkte Nachbarn dar, die über ihren jeweils zugehörigen Port miteinander gekoppelt sind. Jeder Knoten meldet sich periodisch durch ein Ping-Datenpaket auf allen Ports. 1 zeigt einen Zeitpunkt, in welchem gerade der Netzknoten 7 ein solches Ping-Datenpaket sendet, wobei hier und in allen übrigen Figuren ein Pfeil symbolisiert, dass ein Datenpaket über den betreffenden Port gesendet wird.
  • Die 2 bis 10 veranschaulichen in aufeinanderfolgenden Taktzyklen t=0,1,2,... das Verbreiten eines Broadcast-Datenpakets in einem gezeigten Netzwerkbeispiel mit fünfundzwanzig Netzknoten. Im ersten, in 2 gezeigten Zyklus sendet der Netzknoten 7 ein Broadcast-Paket, entsprechend diesem Pakettyp über alle Ports. Jeder Netzknoten, der das Broadcast-Datenpaket erstmals empfängt, leitet es über alle seine anderen Ports weiter. Dies gilt auch für den Fall, dass das Paket im gleichen Zyklus an mehreren Ports empfangen wird, wie z.B. im zweiten Zyklus von 3 vom Netzknoten 6 oder 16.
  • Um die Netzwerkbelastung durch Broadcast-Übertragungen niedrig zu halten, ist in vorteilhafter Weise eine Zyklenauflösung implementiert, die beinhaltet, dass ein Netzknoten, der ein Broadcast-Paket schon einmal empfangen hat, selbiges verwirft und nicht weiterleitet, wenn er es erneut empfängt. Dazu ist jedes Broadcast-Paket mit einer identifizierenden Paket-ID versehen, und jeder Netzknoten führt eine interne Liste der IDs von bereits empfangenen Broadcast-Paketen. Dazu eignet sich beispielsweise ein Ringpuffer geeigneter Kapazität, so dass alle maximal zu registrierenden Broadcast-IDs gespeichert werden können, die innerhalb der maximalen Ausbreitungszeit eines Broadcast-Pakets auftreten können. Danach kann der Ringpuffer wieder überschrieben werden. Diese Zyk lenauflösungsfunktion hält den Broadcast-Datenverkehr minimal, ohne dass Broadcast-Nachrichten verloren gehen. Eine eindeutige Broadcast-Paket-ID kann ohne zentrale Instanz z.B. dadurch erzeugt werden, dass der erzeugende Netzknoten einen knoteninternen Zählwert an seine eindeutige Knoten-ID anhängt.
  • Unter Zugrundelegung dieser Broadcast-Übertragungseigenschaften ist der weitere Verlauf der Broadcast-Datenausbreitung gemäß den 3 bis 10 selbsterklärend. So verwerfen beispielsweise im zweiten Zyklus von 3 die dem initiierenden Knoten 7 benachbarten Knoten 1, 3, 4, 9, 10 und 13 das in diesem Zyklus erneut empfangene Broadcast-Paket, da sie es bereits im ersten Zyklus von 2 vom Netzknoten 7 empfangen haben. Im fünften Zyklus der 6 verwerfen die beiden Knoten 8 und 15 ihre gegenseitig übertragenen Broadcast-Pakete, da sie selbiges schon im vorigen Zyklus der 5 vom Netzknoten 11 empfangen haben. So breitet sich das Broadcast-Paket in der Abfolge der 2 bis 9 aus, wie durch die Übertragungspfeile symbolisiert, wobei im achten Zyklus von 9 das letzte, noch wandernde Paket vom Knoten 24 zum Knoten 25 übertragen, von diesem aber verworfen wird, da er es zuvor schon im sechsten Zyklus der 7 vom Knoten 23 empfangen hatte. Im Zustand von 10 haben dann alle fünfundzwanzig Netzknoten das Broadcast-Paket vom Knoten 7 erhalten.
  • Die 11 bis 29 veranschaulichen in aufeinanderfolgenden Taktzyklen eine erfindungsgemäß implementierte Verbindungsaufbau-Funktionalität, um eine gewünschte Verbindung zwischen einem sendenden Quellen-Netzknoten und einem Zielnetzknoten zwecks verbindungsorientierter Kommunikation, d.h. Übertragung von Datenpaketen des gerichteten, verbindungsorientierten Typs, aufzubauen. Der hierzu verwendete Algorithmus ba siert auf einer Modifikation der an sich bekannten Reverse-Path-Forwarding-Technik, wobei sich das in den 11 bis 29 gezeigte Beispiel auf den Aufbau einer unidirektionalen Verbindung zwischen dem Netzknoten 7 als nachrichtenerzeugendem Knoten und dem Netzknoten 15 als nachrichtenempfangendem Netzknoten in der Netzwerktopologie der 2 bis 10 bezieht. Außerdem illustrieren die 11 bis 29 einen Fall, bei der die direkte Verbindung zwischen den Netzknoten 10 und 14 für gerichtete Datenpakete wegen einer Störung oder nicht ausreichender Bandbreite nicht benutzbar ist, wie in 11 angegeben. Der nachrichtenerzeugende Knoten 7 startet den Verbindungsaufbau damit, dass er ein Verbindungsanforderungspaket (CRP) als Broadcast-Datenpaket auf allen Ports abgibt, siehe 12. Somit läuft dieses CRP als Broadcast-Nachricht in der oben zu den 2 bis 10 beschriebenen Weise durch das Netz.
  • Das CRP hat die zusätzliche Eigenschaft, dass jeder empfangende Netzknoten denjenigen Port, an welchem er das CRP erstmals empfängt, mit einem ersten Routing-Tabelleneintrag markiert, in den 13 bis 27 jeweils mit einem runden Kreis symbolisiert. Diese Entscheidung wird zeitaufgelöst auch für den Fall eines Mehrfachempfangs im gleichen Zyklus getroffen, wie z.B. bei den Zellen 6 und 16 im zweiten Zyklus gemäß 13. Das im zweiten Zyklus von 13 vom Knoten 10 auf den für gerichtete Verbindungen gestörten Port zum Knoten 14 gegebene CRP wird vom Knoten 14 ignoriert.
  • Im fünften Zyklus der 16 empfängt der Zielknoten 15 erstmals das CRP. Er leitet es nicht mehr weiter. Wie in 17 veranschaulicht, erzeugt und sendet er daraufhin im nächsten Zyklus ein Bestätigungs-Paket (CAP) auf dem mit dem ersten Routing-Eintrag markierten Port zurück. Jeder Zwischen-Netzknoten, der das CAP empfängt, markiert den Port, auf dem er das CAP empfängt, mit einem zweiten Routing-Tabelleneintrag und leitet das CAP über seinen Port mit dem ersten Routing-Eintrag weiter. Das CAP läuft auf diese Weise, wie durch eine dicke Verbindungslinie in den 17 bis 22 veranschaulicht, zum Quellen-Netzknoten 7.
  • Durch den Empfang des CAP erkennt der Quellen-Netzknoten 7, dass die gewünschte Verbindung zum Ziel-Netzknoten 15 steht, d.h. ein optimaler Verbindungspfad für gerichtete Nachrichten aufgebaut worden ist, wie er in 23 mit der dicken Verbindungslinie repräsentiert wird. Der optimale Verbindungspfad ist durch den sendenden Port des Quellen-Netzknotens 7, durch den ersten und zweiten Routing-Eintrag für die beiden beteiligten Ports jedes Zwischen-Netzknotens und durch den empfangenden Port des Ziel-Netzknotens 15 vollständig und lokal, d.h. ohne zentrale Instanz, definiert.
  • Nach Empfang des CAP generiert und sendet der Quellen-Netzknoten 7 ein Verbindungsaufbau-beendet-Paket (Connection Established-Packet, CEP) vom Broadcast-Typ. Dies dient dazu, dass alle am optimalen Verbindungspfad nicht beteiligten Netzknoten ihre ersten Routing-Einträge wieder löschen können. Mit anderen Worten löscht jeder Netzknoten, der das CEP vor dem Empfang des CAP empfängt, seine erste Routing-Markierung wieder. Dies ist in der Zyklenabfolge der 22 bis 28 illustriert. Zuletzt löscht der nicht beteiligte Knoten 24 seinen ersten Routing-Eintrag im siebzehnten Zyklus der 28, wonach im Zustand von 29 alle nicht am optimalen Verbindungspfad beteiligten Knoten wieder zurückgesetzt sind. Über den aufgebauten optimalen Verbindungspfad kommuniziert der Knoten 7 mit dem Knoten 15 mittels Datenpaketen vom gerichteten Typ.
  • Eine aufgebaute Verbindung für gerichtete Nachrichten kann initiiert vom Quellen- oder Ziel-Netzknoten wieder abgebaut werden. Die 30 bis 35 zeigen ein Beispiel für einen vom Quellen-Netzknoten 7 initiierten Verbindungsabbau. Dazu sendet der Quellen-Netzknoten 7 entlang der aufgebauten Verbindung ein Verbindungsabbau-Paket (Connection-Terminate Packet, CTP). Das CTP hat die Wirkung, dass jeder empfangende Knoten das CTP auf dem aufgebauten Pfad weiterleitet und die Verbindung lokal löst, d.h. seine beiden Routing-Einträge löscht und die reservierten Ressourcen wieder freigibt. Auf diese Weise ist die Verbindung nach Empfang des CTP durch den Ziel-Netzknoten 15 im Taktzyklus der 34 wieder vollständig abgebaut und das Netzwerk befindet sich anschließend im Ausgangszustand gemäß 35. Alternativ zum gezeigten Beispiel kann der Verbindungsabbau vom Ziel-Netzknoten 15 dadurch initiiert werden, dass dieser ein Verbindungsabbruch-Paket (Connection-Broken-Packet, CBP) über die aufgebaute Verbindung zum Quellen-Netzknoten 7 schickt, welches die gleiche Wirkung in jedem empfangenden Netzknoten hat wie das CTP.
  • Das Beispiel der 30 bis 35 macht deutlich, dass es die erfindungsgemäße Vorgehensweise ermöglicht, eine optimale Verbindung für gerichtete Nachrichten allein durch lokale Maßnahmen ohne Zuhilfenahme einer zentralen Instanz aufzubauen und auch wieder abzubauen. Auch Störungen können adäquat behandelt werden. So illustrieren die 36 bis 50 eine Situation, bei der während des Verbindungsaufbaus ein Knoten ausfällt, wobei von der Netztopologie ähnlich derjenigen des obigen Verbindungsaufbaubeispiels ausgegangen wird. Dabei wird angenommen, dass der an sich auf dem optimalen Pfad liegende Knoten 14 komplett ausfällt, nachdem er das CAP des Quellen-Netzknotens 7 noch weitergeleitet hat, siehe 37. Als weitere Modifikation ist angenommen, dass der am Verbindungspfad zwischen dem Knoten 7 und 15 nicht beteiligte Kno ten 23 fehlt. Bis zum vierten Taktzyklus entspricht der Verbindungsaufbau dem zuvor erläuterten Beispiel, d.h. die 36 entspricht bis auf den fehlenden Knoten 23 der Situation von 15, wobei nun zusätzlich in den symbolischen Kreisen und Pfeilen die Nummer des initiierenden Knotens angegeben ist.
  • Die benachbarten Netzknoten 10, 11 und 16 warten, wie weiter oben erläutert, zwei Ping-Taktzyklen ab, bis sie wegen Ausbleibens entsprechender Ping-Datenpakete feststellen, dass der Knoten 14 ausgefallen ist, siehe 38. Das vom Knoten 11 noch zum Knoten 14 weitergeleitete CAP geht dort verloren, siehe 39. Im Taktzyklus von 40 beginnen die benachbarten Knoten 10, 11 und 16 mit dem Absenden eines entsprechenden Cell-Lost-Pakets vom Broadcast-Typ, wie weiter oben erläutert. Der Knoten 11 sendet zusätzlich ein Verbindungsabbruch-Paket (CBP), da bei ihm lokal die Verbindung bereits bestand, nachdem er die Störung festgestellt hat. Das Cell-Lost-Broadcastpaket (CLB) hat die Wirkung, dass der empfangende Knoten jeweils alle Routing-Markierungen löscht. Das CBP hat die Wirkung, dass der empfangende Knoten die zur betreffenden Verbindung gehörige Routing-Markierung löscht.
  • Beim gewählten Netztopologiebeispiel hat der Ausfall des Knotens 14 zur Folge, dass zwei Inseln entstehen, eine mit dem Ziel-Netzknoten 15 und eine mit dem Quellen-Netzknoten 7. In der Insel mit dem Ziel-Netzknoten 15 werden die Routing-Einträge nun sukzessive gelöscht, wie aus der Abfolge der 40 bis 46 zu erkennen. In der anderen Insel wird gemäß 41 zusätzlich angenommen, dass im betreffenden Taktzyklus der Netzknoten 2 einen Verbindungswunsch zum Knoten 9 initiiert und ein dementsprechendes CRP abgibt. Sobald gemäß 42 der Quellen-Netzknoten 7 das CLB erstmals vom Knoten 10 empfangen hat, bricht er den Verbindungsaufbauwunsch ab, wobei er ein CEP als Broadcast-Nachricht abgibt, die empfangende Netzknoten zum Löschen entsprechender Routing-Markierungen veranlasst. Im gezeigten Beispiel ist das CEP redundant, da die Markierungen bereits aufgrund des CLB gelöscht werden.
  • Im Taktzyklus von 42 empfängt zudem der Knoten 9 als Ziel-Netzknoten den Verbindungswunsch vom Quellen-Netzknoten 2 und sendet im Taktzyklus von 43 das entsprechende CAP zurück. Zwischenzeitlich hat jedoch der Zwischen-Netzknoten 6 bereits seinen ersten Routing-Eintrag wegen Empfang des CLB des Knotens 10 bzw. des CEP des Knotens 7 gelöscht und ignoriert folglich das vom Knoten 9 gesendete CAP. Der Knoten 6 sendet daher ein CBP zum Knoten 9 zurück, der daraufhin seinen Routing-Eintrag löscht. Nach Empfang des CLB bricht auch der Quellen-Netzknoten 2 seinen Verbindungswunsch ab und sendet ein entsprechendes CBP, das als Broadcast-Paket in den weiteren Taktzyklen alle Knoten der zugehörigen Insel durchläuft und dazu führt, dass schließlich alle Routing-Einträge wieder gelöscht werden, zuletzt gemäß 49 im Knoten 22. Danach befindet sich das Netz mit der neuen Inseltopologie wieder in einem Ausgangszustand gemäß 50, in welchem alle Spuren der beiden verworfenen Aufbauversuche beseitigt sind, so dass keine offenen Anforderungen übrig bleiben.
  • Umgekehrt veranschaulichen die 51 bis 63 einen Fall, bei dem zwei Netzwerkinseln durch einen hinzukommenden Netzknoten 14 miteinander verbunden werden, wobei sich das Netz selbstorganisierend allein durch lokale Maßnahmen wieder neu in seinen Kommunikationseigenschaften konfiguriert. Dazu wird von einem Reregister-Konzept Gebrauch gemacht, bei welchem sich alle Netzknoten erneut zurückmelden, nachdem ein neuer Netzknoten von seinen neuen Nachbarknoten erkannt und im Netz bekannt gemacht worden ist.
  • Zunächst wird nach Hinzutreten des Knotens 14, wie in 51 veranschaulicht, der hinzugekommene Knoten 14 erkannt, wobei z.B. gemäß 52 zufällig zuerst der Nachbarknoten 16 ein Ping-Datenpaket sendet. Der Knoten 14 aktiviert daraufhin seinen Port zum Knoten 16 und sendet auf diesem, da nur dieser bislang aktiv ist, ein Cell-Found-Broadcastpaket über das Auffinden des Nachbarknotens 16. Die Cell-Found-Nachricht vom Knoten 14 läuft daher sukzessive nur zu den anderen, mit dem Knoten 16 gekoppelten Knoten, hier den Knoten 18, 20 und 22. Gemäß dem Reregister-Konzept sendet jeder Knoten bei Empfang einer Cell-Found-Nachricht ein Reregister-Broadcastpaket. Vom Knoten 16 wird dieses aber noch nicht zum Knoten 14 weitergeleitet, da der betreffende Port des Knotens 16 noch nicht aktiviert ist. Im Zyklus der 55 sendet der Knoten 14 erstmals ein Ping-Datenpaket. Daraufhin aktivieren die Nachbarknoten 11 und 16 jeweils ihren zugehörigen Port und senden ein Cell-Found-Broadcastpaket über das Auffinden des neuen Nachbarknotens 14. Da der Knoten 14 jedoch vom Nachbarknoten 11 noch kein Ping-Datenpaket empfangen hat, hat er seinen zugehörigen Port noch nicht aktiviert und leitet keine Pakete zum Knoten 11 weiter.
  • Zur Illustration sind in den 55 bis 63 diejenigen Sechseckseiten, bei denen die beiden zugehörigen Ports noch nicht aktiviert sind und die daher noch keine bidirektionale Verbindung darstellen, mit dicken Linien symbolisiert. Dementsprechend werden Reregister-Broadcastpakete im Netzzustand der 57 bereits vom Knoten 11 und den angekoppelten Knoten 8, 15, 17 und 19 zum Knoten 14 weitergeleitet, jedoch noch keine Reregister-Broadcastpakete vom Knoten 14 und den angekoppelten Knoten 16, 18, 20 und 22 zum Knoten 11 und den an diesen angekoppelten Knoten 8, 15, 17 und 19. Auf diese Weise hat z.B. im Zustand von 58 der Knoten 18 erstmals eine Reregister-Nachricht vom Knoten 11 empfangen, er kann aber noch nicht z.B. zum Knoten 17 senden.
  • 59 zeigt dann den Zeitpunkt, zu dem auch der letzte, vom Einbau des neuen Knotens 14 betroffene Netzknoten 11 ein Ping-Datenpaket sendet. Dies führt dazu, dass der Knoten 14 seinen zugehörigen Port aktiviert und das Cell-Found-Broadcastpaket über das Finden des neuen Nachbarknotens 11 abgibt, in den 60 bis 63 durch die Nummer 14' im kreisrunden Reregister-Nachrichtensymbol angegeben. Erst dann erreichen alle gesendeten Reregister-Nachrichten alle Netzknoten, und sobald auch die letzte Reregister-Broadcastnachricht alle Knoten erreicht hat, ist die neue Netztopologie in allen Knoten lokal bekannt, so dass beliebige Kommunikationsvorgänge ablaufen können.
  • Im ungünstigsten, d.h. am längsten dauernden Inselverbindungsfall wird ein Knoten so eingefügt, dass er mit jedem Port an eine eigene Insel ankoppelt, wodurch die doppelte Anzahl an Cell-Found-Broadcastpaketen entstehen und jeder Knoten mit genauso vielen Reregister-Broadcastpaketen antwortet. Kurzzeitig ist nicht garantiert, dass ein Knoten erreichbar ist, nur weil von ihm ein Reregister-Paket empfangen wurde. Bei der zweiten Reregister-Meldung eines Knotens ist dieser aber sicher erreichbar.
  • Eine weitere Situation stellt das Einschalten eines Netzknotenverbunds dar. Ohne eine Sonderbehandlung würden sich alle Knoten per Ping-Datenpaket bei allen Nachbarknoten melden und jeder von diesen ein Cell-Found-Broadcastpaket generieren, die wiederum von allen Knoten mit einem Reregister-Paket beantwortet würden. Diese Nachrichten würden fast gleichzeitig stattfinden und somit zu einer hohen Netzbelastung selbst bei paralleler Übertragung führen. Als Abhilfe ist eine besondere Einschaltbehandlung vorgesehen. Bei dieser wird zunächst sichergestellt, dass alle Ports aktiviert sind, indem ausreichend viele Ping-Zyklen gewartet wird. Erst dann senden die Knoten ihre Cell-Found-Broadcastnachrichten. Auf diese Weise wächst die maximale Anzahl von derartigen Nachrichten nur linear statt quadratisch mit der Anzahl an Netzknoten.
  • Die 64 bis 70 veranschaulichen dies an einem einfachen Beispiel dreier Netzknoten 8, 11 und 15, wobei noch nicht bidirektional aktivierte Verbindungen wiederum mit dicken Linien symbolisiert sind. Nach dem Einschalten des Zellen-Verbunds von 64 sind zunächst gemäß 65 alle Ports inaktiv und alle Knoten warten zwei Taktzyklen ab. Dann sendet z.B. der Knoten 15 gemäß 66 zuerst ein Ping-Datenpaket, wodurch die benachbarten Zellen 8 und 11 ihren jeweils zugehörigen Port aktivieren, aber noch kein Cell-Found-Paket senden. Im gleichen Ping-Zyklus senden dann auch die Knoten 8 und 11 jeweils ein Ping-Datenpaket, siehe 67, so dass spätestens nach zwei weiteren Taktzyklen alle benötigten Ports aktiviert sind, siehe 68. Erst jetzt senden alle Knoten nacheinander die Cell-Found-Broadcastpakete, siehe 69, und spätestens nach einer Zeitdauer, die linear mit der Anzahl n an Netzknoten ansteigt, sind alle Cell-Found-Broadcastmeldungen empfangen worden, siehe 70. Reregister-Nachrichten werden daher erst nach dieser linear von der Anzahl n an Netzknoten abhängigen Zeitdauer zugelassen, so dass ein korrekter Reregister-Ablauf gewährleistet ist, auch für den Fall des Verbindens zweier Inseln.
  • Die 71 bis 78 veranschaulichen die Behandlung eines Falles, bei dem ein Knoten 12 in einer dort gezeigten Netztopologie entfernt wird, ohne dass dadurch eine Insel entsteht. Nach zwei Ping-Zyklen bemerken, ausgehend vom Anfangszustand der 71, die Knoten 8, 15 und 17 den Verlust des Nachbar knotens 12 und senden ein entsprechendes Cell-Lost-Paket als Broadcast-Nachricht, siehe 72. Der Empfang des Cell-Lost-Datenpakets initiiert in jedem empfangenden Knoten eine Reregister-Broadcastnachricht zum Neuanmelden, in den 73 bis 78 jeweils wieder mit einem nummerierten Kreis symbolisiert. Die Cell-Lost- und Reregister-Pakete propagieren dann in der gezeigten Weise über den Netzknotenverbund, siehe die 73 bis 77. Im Endzustand der 78 sind alle Cell-Lost-Broadcastmeldungen verteilt und jeder Knoten hat in diesem Beispiel drei Mal vom Verlust des Knotens 12 erfahren. Es dauert dann noch neun Taktzyklen, bis die letzten Reregister-Broadcastmeldungen verteilt sind. Im längstdauernden Fall entstehen somit durch einen Knotenausfall eine Anzahl von Broadcast-Meldungen, die mit dem Produkt der Anzahl an Ports pro Knoten mit der Anzahl an Knoten im Netzwerk anwachsen.
  • Die 79 bis 82 veranschaulichen eine Situation, bei der ein Knoten 14 entfernt wird und dadurch Inseln entstehen, in Umkehrung zum Inselverbindungsfall der 51 bis 63. Nach dem Entfernen des Knotens 14 gemäß 79 bemerken die benachbarten Knoten 11 und 16 nach zwei Ping-Zyklen den Verlust des Nachbarknotens 14 und senden eine entsprechende Cell-Lost-Broadcastnachricht, die über die jeweilige Insel läuft, siehe die 80 bis 82. Nach Empfang der Cell-Lost-Nachricht sendet der jeweilige Knoten wieder eine Reregister-Broadcastnachricht. Es werden aber wegen der Inselbildung keine Reregister-Nachrichten mehr von den Knoten der jeweils anderen Insel empfangen. Über eine geeignet gewählte Time-out-Anwendung wird dann festgestellt, dass keine Reregister-Nachricht von den Knoten der anderen Insel mehr empfangen wird. Verbindungsorientierte Kommunikationsstrecken werden, sofern vorhanden, gezielt abgebaut. Ein Wiederaufbau erfolgt nur nach einem Time-Out-Warten auf Reregister-Meldungen.
  • Die 83 bis 87 veranschaulichen eine Situation, bei der eine aufgebaute Verbindung zwischen einem Quellen-Netzknoten 7 und einem Ziel-Netzknoten 15 in dem Netzwerk, anhand dem die Beispiele des Aufbaus und Abbaus einer Verbindung für gerichtete Nachrichten gemäß den 11 bis 35 erläutert wurden. 83 zeigt den Zeitpunkt, zu dem die Verbindung besteht und ein beteiligter Zwischen-Netzknoten 14 ausfällt. Die dem ausgefallenen Knoten 14 benachbarten, an der Verbindung beteiligten Knoten 11 und 16 schicken entlang des Verbindungspfades jeweils ein CBP zum Quellen-Netzknoten 7 bzw. Ziel-Netzknoten 15, wodurch der Verbindungspfad sukzessive gelöscht wird, siehe die 84 und 85.
  • Als optionale Funktionalität ist vorgesehen, dass der Quellen-Netzknoten 7 nach Empfang des CBP einen neuen Verbindungsaufbau versucht und dazu wiederum ein entsprechendes Verbindungsanforderungs-Paket als Broadcast-Nachricht abgibt, siehe 86. Der weitere Verbindungsaufbauablauf erfolgt dann wie oben beschrieben, bis schließlich ein neuer optimaler Verbindungspfad vom Quellen-Netzknoten 7 zum Ziel-Netzknoten 15 aufgebaut ist, wie in 87 gezeigt.
  • Die 88 bis 99 veranschaulichen einen Fall, bei dem sich Broadcast-Nachrichten überholen. Wenn sich die Netztopologie ändert, solange Broadcast-Nachrichten unterwegs sind, kann deren Empfangsreihenfolge nicht garantiert werden, da die neue Topologie eventuell kürzere Pfade bereitstellt, die von einer Broadcast-Nachricht sofort verwendet werden können.
  • Im Anfangszustand von 88 sendet ein Knoten 22 eine Broadcast-Nachricht, wobei der Empfang in den 89 bis 99 jeweils durch ein Kreissymbol markiert wird. Im Taktzyklus der 90 wird ein neuer Knoten 23 in das Netz eingefügt. Zwei Taktzyklen später sendet gemäß 92 der Knoten 22 ei ne zweite Broadcast-Nachricht, die nun auch über den neu eingefügten Nachbarknoten 23 läuft. Dies hat zur Folge, dass der Knoten 23 und die anschließenden Knoten 25 und 24 die zweite Broadcast-Nachricht vom Knoten 22 vor der ersten Broadcast-Nachricht empfangen, siehe die 93 bis 95. Im Taktzyklus der 98 empfängt der Knoten 22 seine eigene erste Broadcast-Nachricht. Da er sie zuvor nicht empfangen hatte, würde er sie nach den sonstigen Broadcast-Übertragungsregeln unnötigerweise weiterleiten. Um dies zu verhindern, wird vorgesehen, dass im Quellen-Netzknoten die Broadcast-Paket-ID beim Erzeugen des Broadcast-Pakets in die Liste empfangener Broadcast-Pakete aufgenommen wird, so dass der Knoten 22 im Zyklus der 98 seine empfangene Broadcast-Nachricht nicht mehr weiterleitet. Im Endzustand der 99 haben dann alle Knoten beide Broadcast-Nachrichten empfangen, wenngleich nicht alle Knoten zeitrichtig.
  • Die gezeigten und oben erläuterten Ausführungsbeispiele machen deutlich, dass die Erfindung ein verteiltes Datenkommunikationsnetzwerk mit selbstorganisierendem Kommunikationsmanagement zur Verfügung stellt, das ohne zentrale Instanzen auskommt und sich auch für sicherheitskritische Anwendungen mit Echtzeitanforderungen eignet, z.B. zur Realisierung von Datenkommunikationsnetzwerken in Kraftfahrzeugen. Die diversen beschriebenen Funktionalitäten, wie spezielle Nachbarüberwachung und Broadcast-Übermittlung sowie spezieller Verbindungsaufbau und Reregister-Konzept, können je nach Netzwerkauslegung einzeln oder in beliebiger Kombination implementiert sein und ermöglichen den Verzicht auf zentrale Instanzen, wie solche mit höherer Intelligenz oder Kommunikationsfähigkeit als andere Netzknoten. Vielmehr können durchgehend Netzknoten mit identischer Kommunikationsfähigkeit zum Aufbau des Netzwerks benutzt werden, abgesehen von etwaigen einfacheren Peripherie-Netzknoten.
  • In den Netzknoten sind die zur Durchführung der beschriebenen Funktionalitäten benötigten Hardware- und Software-Einheiten implementiert, wie sie sich für den Fachmann nach Kenntnis dieser geforderten Funktionalitäten ohne weiteres ergeben. Dazu gehört insbesondere ein geeigneter Datenpaket-Router, der u.a. die verbindungsorientierte Kommunikation mittels einer Routing-Tabelle verwaltet. Wegen der dezentralen Organisation des Verbindungsaufbaus kennt der Router eines Netzknotens immer nur den optimalen Ausgangsport für ein eingehendes gerichtetes Datenpaket, der Verbindungspfad insgesamt ergibt sich aus den Routing-Einträgen in den einzelnen Netzknoten.
  • Bei einer vorteilhaften Ausführungsform sind die Netzknoten gleichartig aufgebaut mit mehr als 2 Ports, wobei eine Untermenge der Kommunikations-Ports dynamisch, während der Laufzeit des Datenkommunikationsnetzwerks aktivierbar und deaktivierbar ist.

Claims (11)

  1. Datenkommunikationsnetzwerk mit – einer Mehrzahl von Netzknoten, die jeweils einen oder mehrere Kommunikations-Ports und eine identifizierende Knoten-ID aufweisen und darauf ausgelegt sind, Verbindungen dezentral zu verwalten und Datenpakete eines ungerichteten Typs und/oder eines gerichteten Typs zu übertragen, wobei die Datenpakete eine Header-Information wenigstens über Pakettyp und Knoten-ID des paketerzeugenden Netzknotens enthalten, dadurch gekennzeichnet, dass – in jedem Netzknoten eine Überwachung der Funktionalität eines benachbarten Netzknoten mit folgenden Eigenschaften implementiert ist: der Netzknoten sendet periodisch auf jedem zu überwachenden Port ein nicht weiterzuleitendes Ping-Datenpaket mit einer Header-Information; der Netzknoten aktiviert den oder die Ports, auf dem oder denen er innerhalb einer vorgebbaren Meldezeit ein Ping-Datenpaket von einem dortigen Nachbarknoten empfangen hat, und führt eine zugehörige Liste direkt verbundener Nachbarknoten; wenn der Netzknoten an einem Port aufgrund eines zugehörig empfangenen Ping-Datenpaketes einen neuen Nachbarknoten erkennt, aktualisiert er seine Nachbarknoten-Liste entsprechend und sendet ein zugehöriges Cell-Found-Datenpaket vom ungerichteten Typ; und wenn der Nachbarknoten an einem bislang aktivierten Port innerhalb der Meldezeit kein Ping-Datenpaket und keine anderen Datenpakete mehr empfängt, wertet er dies als Verlust des bisherigen dortigen Nachbarknotens, aktualisiert seine Nachbarknoten-Liste entsprechend und sendet ein zugehöriges Cell-Lost-Datenpaket vom ungerichteten Typ.
  2. Datenkommunikationsnetzwerk nach Anspruch 1, weiter dadurch gekennzeichnet, dass als Meldezeit eine vorgebbare Anzahl von Zyklen der periodisch gesendeten Ping-Datenpakete gewählt wird.
  3. Datenkommunikationsnetzwerk nach Anspruch 1 oder 2, weiter dadurch gekennzeichnet, dass ein jeweiliger Netzknoten in Reaktion auf den Empfang eines Cell-Found-Datenpakets oder Cell-Lost-Datenpakets ein Reregister-Datenpaket vom ungerichteten Typ sendet.
  4. Datenkommunikationsnetzwerk, insbesondere nach einem der Ansprüche 1 bis 3, mit – einer Mehrzahl von Netzknoten, die jeweils einen oder mehrere Kommunikations-Ports und eine identifizierende Knoten-ID aufweisen und darauf ausgelegt sind, Verbindungen dezentral zu verwalten und Datenpakete eines ungerichteten Typs und/oder eines gerichteten Typs zu übertragen, wobei die Datenpakete eine Header-Information wenigstens über Pakettyp und Knoten-ID des paketerzeugenden Netzknotens enthalten, dadurch gekennzeichnet, dass – die Datenpakete vom ungerichteten Typ mit einer identifizierenden Paket-ID versehen sind und in mehreren Netzknoten eine Broadcast-Funktionalität mit folgenden Eigenschaften implementiert ist: der Netzknoten führt eine Liste der Paket-Ids bereits empfangener Datenpakete vom ungerichteten Typ und prüft anhand der Liste, ob ein momentan empfangenes Datenpaket vom ungerichteten Typ schon einmal früher empfangen worden ist; wenn der Netzknoten hierbei feststellt, dass das momentan empfangene Datenpaket vom ungerichteten Typ schon einmal früher empfangen worden ist, verwirft er es, andernfalls gibt er es an alle direkt verbundenen Nachbarknoten weiter.
  5. Datenkommunikationsnetzwerk nach Anspruch 4, dadurch gekennzeichnet, dass eine Paket-Id durch Verknüpfung einer einen Netzknoten kennzeichnenden Knoten-Id mit einer lokal im Netzknoten erzeugten eindeutigen Id gebildet ist.
  6. Datenkommunikationsnetzwerk, insbesondere nach einem der Ansprüche 1 bis 5, mit – einer Mehrzahl von Netzknoten, die jeweils einen oder mehrere Kommunikations-Ports und eine identifizierende Knoten-ID aufweisen und darauf ausgelegt sind, Verbindungen dezentral zu verwalten und Datenpakete eines ungerichteten Typs und/oder eines gerichteten Typs zu übertragen, wobei die Datenpakete eine Header-Information wenigstens über Pakettyp und Knoten-ID des paketerzeugenden Netzknotens enthalten, dadurch gekennzeichnet, dass – in mehreren Netzknoten eine Verbindungsaufbau-Funktionalität mit folgenden Eigenschaften zum Aufbau von Verbindungspfaden für die Übertragung von Datenpaketen des gerichteten Typs implementiert ist: ein initiierender Quellen-Netzknoten sendet ein Verbindungsanforderungs-Paket (CRP), das als Datenpaket vom un gerichteten Typ übertragen wird und eine Information über einen Ziel-Netzknoten enthält; jeder Netzknoten speichert die Port-ID eines Ports, auf dem er das Verbindungsanforderungs-Paket zuerst empfangen hat, als ersten Routing-Port einer Routing-Information; der Ziel-Netzknoten sendet nach Empfang des Verbindungsanforderungs-Pakets ein Bestätigungs-Paket (CAP) nur auf dem Port, auf dem er das Verbindungsanforderungs-Paket zuerst empfangen hat; jeder Zwischen-Netzknoten, der das Bestätigungs-Paket empfängt, leitet es auf seinem gespeicherten ersten Routing-Port weiter und speichert die Port-ID des empfangenden Ports als zweiten Routing-Port in der Routing-Information und der Quellen-Netzknoten erkennt am Empfang des Bestätigungs-Pakets, dass die Verbindung aufgebaut ist, und kommuniziert mit dem Ziel-Netzknoten durch Datenpakete vom gerichteten Typ über den das Bestätigungs-Paket empfangenden Port.
  7. Datenkommunikationsnetzwerk nach Anspruch 6, weiter dadurch gekennzeichnet, dass der Quellen-Netzknoten in Reaktion auf den Empfang des Bestätigungs-Pakets ein Verbindungsaufbau-beendet-Paket vom ungerichteten Typ sendet und alle Netzknoten, die das Verbindungsaufbau-beendet-Paket vor dem Bestätigungs-Paket empfangen, nicht im aufgebauten Verbindungspfad sind und ihre Markierung des ersten Routing-Ports löschen.
  8. Datenkommunikationsnetzwerk nach Anspruch 6 oder 7, weiter dadurch gekennzeichnet, dass für die Datenpakete vom gerichteten Typ eine Servicequalität durch Vorgabe einer geforderten Bandbreite und maximalen Übertragungszeit festgelegt ist.
  9. Datenkommunikationsnetzwerk nach einem der Ansprüche 6 bis 8, dadurch gekennzeichnet, dass eine Verbindungsabbau-Funktionalität zum Abbau einer aufgebauten Verbindung für die Übertragung von Datenpaketen des gerichteten Typs implementiert ist, gemäß der ein Verbindungsende-Paket des gerichteten Typs vom Quellenzum Ziel-Netzknoten oder vom Ziel-Netzknoten zum Quellen-Netzknoten oder von einem Zwischen-Netzknoten zum Quellen- oder zum Ziel-Netzknoten gesendet wird, auf dessen Empfang hin der oder die an der Verbindung beteiligten Zwischen-Netzknoten ihre Routing-Port-Information wieder löschen.
  10. Datenkommunikationsnetzwerk nach Anspruch 9, weiter dadurch gekennzeichnet, dass eine Verbindungsunterbrechungs-Funktionalität implementiert ist, gemäß der ein an einer aufgebauten Verbindung beteiligter Zwischen-Netzknoten ein Verbindungsunterbrechungs-Paket vom gerichteten Typ als Verbindungsende-Paket zum verbliebenen Verbindungs-Nachbarknoten sendet, wenn er den Verlust des anderen Verbindungs-Nachbarknotens erkennt.
  11. Datenkommunikationsnetzwerk nach Anspruch 10, weiter dadurch gekennzeichnet, dass der Quellen-Netzknoten in Reaktion auf den Empfang eines Verbindungsunterbrechungs-Pakets einen erneuten Verbindungsaufbauversuch durch Senden eines neuen Verbindungsanforderungs-Pakets unternimmt.
DE102004021385A 2004-04-30 2004-04-30 Datenkommunikationsnetzwerk mit dezentralem Kommunikationsmanagement Withdrawn DE102004021385A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE102004021385A DE102004021385A1 (de) 2004-04-30 2004-04-30 Datenkommunikationsnetzwerk mit dezentralem Kommunikationsmanagement
US11/587,823 US20080075020A1 (en) 2004-04-30 2005-04-12 Data Communications Network with a Decentralized Communications Management
PCT/EP2005/003811 WO2005107179A1 (de) 2004-04-30 2005-04-12 Datenkommunikationsnetzwerk mit dezentralem kommunikationsmanagement

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102004021385A DE102004021385A1 (de) 2004-04-30 2004-04-30 Datenkommunikationsnetzwerk mit dezentralem Kommunikationsmanagement

Publications (1)

Publication Number Publication Date
DE102004021385A1 true DE102004021385A1 (de) 2005-11-17

Family

ID=34970792

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102004021385A Withdrawn DE102004021385A1 (de) 2004-04-30 2004-04-30 Datenkommunikationsnetzwerk mit dezentralem Kommunikationsmanagement

Country Status (3)

Country Link
US (1) US20080075020A1 (de)
DE (1) DE102004021385A1 (de)
WO (1) WO2005107179A1 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100694105B1 (ko) * 2005-04-25 2007-03-12 삼성전자주식회사 무선 메시 망에서 이동 스테이션 정보를 배포하는 방법 및장치
US20070014230A1 (en) * 2005-07-14 2007-01-18 Fujitsu Limited Automatically provisioning a network element
CN101051865B (zh) * 2007-03-26 2011-10-26 中兴通讯股份有限公司 在基带资源池与远端射频单元组成的网络上广播的方法
US9419860B2 (en) * 2011-03-31 2016-08-16 Tejas Networks Limited Method for managing a logical topology change in a network
EP3318938A4 (de) * 2015-06-30 2019-02-20 Lynkros Technology (Beijing) Co. Ltd. Verteiltes rechnernetzwerksystem und rechenknoten dafür
CN106331037B (zh) * 2015-06-30 2023-09-19 邻元科技(北京)有限公司 用于分布式计算网络的计算节点
KR102300791B1 (ko) * 2017-03-20 2021-09-09 엘지전자 주식회사 공기조화기 및 그 제어방법
EP3759878A1 (de) * 2018-02-28 2021-01-06 Nokia Technologies Oy Transparente integration eines 3gpp-netzwerks in einem tsn-basierten industriellen netzwerk

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5884036A (en) * 1996-11-08 1999-03-16 Haley; Andrew Paul Method for determining the topology of an ATM network having decreased looping of topology information cells
WO1999017201A1 (en) * 1997-09-30 1999-04-08 Tandem Computers Incorporated A fault tolerant method of maintaining and distributing configuration information in a distributed processing system
WO1999055031A1 (en) * 1998-04-20 1999-10-28 Sarnoff Corporation Traffic routing in small wireless data networks
US20020044533A1 (en) * 2000-08-07 2002-04-18 Paramvir Bahl Distributed topology control for wireless multi-hop sensor networks

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000003516A1 (en) * 1998-07-08 2000-01-20 Broadcom Corporation Network switching architecture with multiple table synchronization, and forwarding of both ip and ipx packets
US6366561B1 (en) * 1999-11-03 2002-04-02 Qualcomm Inc. Method and apparatus for providing mobility within a network
US20020145978A1 (en) * 2001-04-05 2002-10-10 Batsell Stephen G. Mrp-based hybrid routing for mobile ad hoc networks
WO2002084956A1 (en) * 2001-04-16 2002-10-24 Kent Ridge Digital Labs A routing protocol for general mobile ad hoc networks
US20030151513A1 (en) * 2002-01-10 2003-08-14 Falk Herrmann Self-organizing hierarchical wireless network for surveillance and control
DE10234939A1 (de) * 2002-07-31 2004-02-19 Siemens Ag Verfahren, Kommunikationsanordnung und Kommunikationseinrichtung zum Übermitteln von Rundsende-Informationen über ein Kommunikationsnetz
US7808939B2 (en) * 2003-03-28 2010-10-05 Lenovo (Singapore) Pte Ltd. Routing in wireless ad-hoc networks

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5884036A (en) * 1996-11-08 1999-03-16 Haley; Andrew Paul Method for determining the topology of an ATM network having decreased looping of topology information cells
WO1999017201A1 (en) * 1997-09-30 1999-04-08 Tandem Computers Incorporated A fault tolerant method of maintaining and distributing configuration information in a distributed processing system
WO1999055031A1 (en) * 1998-04-20 1999-10-28 Sarnoff Corporation Traffic routing in small wireless data networks
US20020044533A1 (en) * 2000-08-07 2002-04-18 Paramvir Bahl Distributed topology control for wireless multi-hop sensor networks

Also Published As

Publication number Publication date
US20080075020A1 (en) 2008-03-27
WO2005107179A1 (de) 2005-11-10

Similar Documents

Publication Publication Date Title
DE112016007055B4 (de) Querverbindung von Switches auf der Basis eines hierarchischen Overlay-tunneling
DE602004011579T2 (de) Adress-Selbstkonfiguration in Ad-hoc Netzen
EP2343857B1 (de) Netzwerkknoten für ein Kommunikationsnetzwerk
WO2005107179A1 (de) Datenkommunikationsnetzwerk mit dezentralem kommunikationsmanagement
DE102008010145B4 (de) Peer-to-Peer-Kommunikationssystem und -verfahren
DE60103942T2 (de) Lastausgleich in einem Telekommunikationssystem das Mobil IP unterstützt
EP2070256B1 (de) Verfahren zum rekonfigurieren eines kommunikationsnetzwerks
DE69727447T2 (de) Übertragungstrennung und Ebene-3-Netzwerk-Vermittlung
DE69530543T2 (de) Brücke zwischen einem drahtlosen und einem drahtgebundenen lokalen Netz
DE60014138T2 (de) System um etikettierte wegelenkungsbäume zu kommunizieren
EP2160874B1 (de) Verfahren zum betreiben eines drahtlosen, vermaschten datennetzes mit einer mehrzahl an netzknoten
DE102007003159B4 (de) Mobilkommunikationssystem, Funkbasisstation, mobiles Endgerät und Übertragungsverfahren
EP3879761B1 (de) Kommunikationsmodul und beleuchtungs-bussystem mit netzwerkschnittstelle
DE60300299T2 (de) System zur Auswahl von Quell-Adressen geeignet für eine Umgebung mit mehreren Heimatnetzen
EP2127329B1 (de) Filterung von redundanten frames in einem netzwerkknoten
WO2004021641A1 (de) Testverfahren für nachrichtenpfade in kommunikationsnetzen sowie netzelement
DE102009043403A1 (de) Verfahren zum Aufbau eines bidirektionalen Kommunikationspfads in einem drahtlosen Netzwerk
DE102010056369A1 (de) Routed Split Multilink Trunking für IPv6
DE60026006T2 (de) System zum Empfang von Mehrfachdaten
WO2018162071A1 (de) Verfahren und vorrichtung zur modularen lenkung eines avb-streams
WO2020125987A1 (de) Verfahren zur datenkommunikation mit vorgegebener anforderung an die ausfallsicherheit, kommunikationsgerät, computerprogramm und computerlesbares medium
DE10147755A1 (de) Verfahren und Vorrichtungen zur Header-Kompression in paketorientierten Netzwerken
EP2127241B1 (de) Zielportsuche in netzwerken aus gekoppelten teilnetzen
DE60024575T2 (de) Verfahren und Vorrichtung zur Handhabung von selbst-anpassenden Ereignisströmen
EP1649644A1 (de) Verfahren und netzknoten zur meldung mindestens eines ausgefallenen verbindungsweges innerhalb eines kommunikationsnetzes

Legal Events

Date Code Title Description
OM8 Search report available as to paragraph 43 lit. 1 sentence 1 patent law
8127 New person/name/address of the applicant

Owner name: DAIMLERCHRYSLER AG, 70327 STUTTGART, DE

8127 New person/name/address of the applicant

Owner name: DAIMLER AG, 70327 STUTTGART, DE

8130 Withdrawal