DE112006001117T5

DE112006001117T5 - Verfahren zum Unterstützen eines Multicast-Weiterleitens in drahtlosen Multihop-Netzen

Info

Publication number: DE112006001117T5
Application number: DE112006001117T
Authority: DE
Inventors: Surong Altamonte Springs Zeng; Heyun Altamonte Springs Zheng
Original assignee: MESH NETWORKS Inc; Mesh-Networks Inc Schaumburg; MeshNetworks Inc
Current assignee: MESH NETWORKS Inc; Mesh-Networks Inc Schaumburg; Arris Enterprises LLC
Priority date: 2005-05-05
Filing date: 2006-04-27
Publication date: 2008-05-15
Also published as: WO2006121630A3; KR20080005533A; WO2006121630A2; US7403492B2; KR100938513B1; US20060250999A1

Abstract

Verfahren zum Unterstützen eines Multicast in einem drahtlosen Multihop-Netz, mit folgenden Schritten:
Einrichten bestimmter Knoten in dem Netz als Kernquellenknoten;
Beteiligen an einem Multicast-Baum-Entdeckungs- oder -Auffrischverfahren durch Betreiben von mindestens einem der Kernquellenknoten, um eine Routenanfrage-(RREQ-) Nachricht zu übertragen; und
Aufbauen des Multicast-Baums oder Auffrischen des Multicast-Baums basierend auf der RREQ-Nachricht und mindestens einer Routenantwort (RREP)-Nachricht, die durch den mindestens einen Kernquellenknoten von einem anderen Knoten ansprechend auf die RREQ-Nachricht empfangen wird.

Description

HINTERGRUND DER ERFINDUNG
Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf ein System und Verfahren für einen Gruppenruf-Weiterleitungs- (engl.: multicast routing) Algorithmus für drahtlose Mehrsprung- (engl.: multi-hop) Netze, wie Ad-hoc-Netze.
Beschreibung der verwandten Technik
In den letzten Jahren wurde ein Typ eines mobilen Kommunikationsnetzes, der als ein „Ad-hoc-Netz" bekannt ist, entwickelt. Bei diesem Netztyp ist jeder mobile Knoten fähig, als eine Basisstation oder eine Weiterleitungsvorrichtung (engl.: Router) für die anderen mobilen Knoten in Betrieb zu sein, so dass die Notwendigkeit einer festen Infrastruktur von Basisstationen beseitigt wird. Wie für Fachleute erkennbar ist, senden und empfangen Netzknoten Datenpaketkommunikationen in einem gemultiplexten Format, wie einem Zeitvielfachzugriffs- (engl.: time-division multiple access; TDMA) Format, einem Codevielfachzugriffs- (engl.: code-division multiple access; CDMA) Format oder einem Frequenzvielfachzugriffs- (engl.: frequency-division multiple access; FDMA) Format, was einem einzelnen Sendeempfänger (engl.: transceiver) bei einem ersten Knoten ermöglicht, gleichzeitig mit mehreren anderen Knoten in dem Versorgungsbereich desselben zu kommunizieren.
Es werden außerdem ausgereiftere Ad-hoc-Netze entwickelt, die zusätzlich dazu, dass sie mobilen Knoten ermöglichen, wie in einem herkömmlichen Ad-hoc-Netz mit einander zu kommunizieren, den mobilen Knoten ferner ermöglichen, auf ein Festnetz zuzugreifen und so mit anderen mobilen Knoten, wie denjenigen in dem öffentlich vermittelten Fernsprechnetz (engl.: public switched telephone network; PSTN), und in anderen Netzen, wie dem Internet, zu kommunizieren. Details dieser fortschrittlichen Typen von Ad-hoc-Netzen sind in der am 29. Juni 2001 eingereichten US-Patentanmeldung Serien-Nr. 09/897,790 mit dem Titel „Ad Hoc Peer-to-Peer Mobile Radio Access System Interfaced to the PSTN and Cellular Networks", in der am 22. März 2001 eingereichten US-Patentanmeldung Serien-Nr. 09/815,157 mit dem Titel „Time Division Protocol für an Ad-Hoc, Peer-to-Peer Radio Network Having Coordinating Channel Access to Shared Parallel Data Channels with Separate Reservation Channel" und in der am 22. März 2001 eingereichten US-Patentanmeldung Serien-Nr. 09/815,164 mit dem Titel „Prioritized-Routing for an Ad-Hoc, Peer-to-Peer, Mobile Radio Access System" beschrieben, wobei der gesamte Inhalt derselben hierin durch Bezugnahme aufgenommen ist.
Multicasting ist ein effizienteres Verfahren zum Unterstützen einer Gruppenkommunikation als Punkt-zu-Punkt-Verbindungen (engl.: unicasting) oder ein Sammelruf (engl.: broadcasting), da dasselbe eine Sendung und ein Weiterleiten (engl.: routing) von Paketen zu mehreren Zielen unter Verwendung von weniger Netzressourcen erlaubt. Mit dem Aufkommen eines weit verbreiteten Einsatzes von drahtlosen Netzen, den sich schnell verbessernden Fähigkeiten mobiler Vorrichtungen und einer zunehmend ausgereifteren mobilen Arbeitskraft weltweit sind Inhalts- und Dienst-Anbieter zunehmend an einem Unterstützen von Multicast-Kommunikationen über drahtlose Netze interessiert. Indem immer mehr Anwendungen und Netzsteuerprotokolle eine Multicast-Unterstützung erfordern, sind Multicast-Weiterleitungs-Algorithmen in drahtlosen mobilen Multihop-Ad-hoc-Netzen notwendig, um eine hohe Effizienz bei einer Verkehrsverteilung für mehrere Benutzer in einem Netz zu unterstützen.
Keines der bestehenden Ad-hoc-Multicast-Weiterleitungen eignet sich für drahtlose Ad-hoc-Netze mit einer hohen Dynamik und einer einigermaßen guten Skalierbarkeit. Das vorgeschlagene Ad-hoc-Anforderungs-Entfernungsvektor-Gruppenruf-Wei terleitungs-Protokoll (engl.: Ad Hoc On-demand Distance Vector Multicast Routing Protocol; AODVMRP) befasst sich mit einer Multicast-Unterstützung in den drahtlosen Ad-hoc-Netzen ohne feste Infrastrukturknoten mit einer hohen Dynamik. Verglichen mit anderen bestehenden Multicast-Weiterleitungs-Algorithmen für drahtlose Netze kann der vorgeschlagene Algorithmus eine bessere Skalierbarkeit und Dynamik für drahtlose Ad-hoc-Netze unterstützen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Diese und andere Aufgaben, Vorteile und neue Merkmale der Erfindung werden aus der folgenden detaillierten Beschreibung in Verbindung mit den beigefügten Zeichnungen gelesen unmittelbarer erkennbar. Es zeigen:
1 ein Blockdiagramm eines beispielhaften drahtlosen Ad-hoc-Kommunikationsnetzes, das eine Mehrzahl von Knoten, die ein System und Verfahren gemäß einem Ausführungsbeispiel der vorliegenden Erfindung verwenden, umfasst; und
2 ein Blockdiagramm, das ein Beispiel eines mobilen Knotens, der bei dem Netz, das in 1 gezeigt ist, verwendet wird, darstellt.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE
1 ist ein Blockdiagramm, das ein Beispiel eines paketvermittelten drahtlosen Ad-hoc-Kommunikationsnetzes 100, das ein Ausführungsbeispiel der vorliegenden Erfindung verwendet, darstellt. Für Zwecke dieser Anmeldung bezieht sich der Ausdruck „Ad-hoc-Netz" auf ein Netz, bei dem die Topologie und das Verhalten der Knoten beliebig sind. Genauer gesagt, das Netz 100 umfasst eine Mehrzahl von mobilen drahtlosen Benutzerendgeräten 102-1 bis 102-n (auf die allgemein als Knoten 102 oder mobile Knoten 102 Bezug genommen ist) und kann, muss jedoch nicht, ein Festnetz 104 mit einer Mehrzahl von Zugriffspunkten 106-1, 106-2,...106-n (auf die allgemein als Knoten 106 oder Zugriffspunkte 106 Bezug genommen ist) zum Versehen der Knoten 102 mit einem Zugriff auf das Festnetz 104 umfassen. Das Festnetz 104 kann beispielsweise ein Kern-Lokalzugriffsnetz (engl.: local access network; LAN) und eine Mehrzahl von Servern und Netzübergangs-Weiterleitungsvorrichtungen (engl.: gateway routers), um Netzknoten einen Zugriff zu anderen Netzen, wie anderen Ad-hoc-Netzen, dem öffentlich vermittelten Fernsprechnetz (PSTN) und dem Internet, zu liefern, umfassen. Das Netz 100 kann ferner eine Mehrzahl von festen Router 107-1 bis 107-n (auf die allgemein als Knoten 107 oder feste Router 107 Bezug genommen ist) zum Weiterleiten von Datenpaketen zwischen anderen Knoten 102, 106 oder 107 umfassen. Es sei bemerkt, dass für Zwecke dieser Erörterung auf die im Vorhergehenden erörterten Knoten gemeinsam als „Knoten 102, 106 und 107" oder einfach „Knoten" Bezug genommen sein kann.
Wie für Fachleute erkennbar ist, sind die Knoten 102, 106 und 107 fähig, miteinander direkt oder über einen oder mehrere andere Knoten 102, 106 oder 107, die als ein Router oder als Router für Pakete, die zwischen Knoten gesendet werden, in Betrieb sind, zu kommunizieren, wie in dem US-Patent Nr. 5,943,322 für Mayor, das hierin durch Bezugnahme aufgenommen ist, und in den US-Patentanmeldungen Serien-Nrn. 09/897,790, 09/815,157 und 09/815,164, auf die im Vorhergehenden Bezug genommen ist, beschrieben ist.
Wie in 2 gezeigt ist, umfasst jeder Knoten 102, 106 und 107 einen Sendeempfänger oder ein Modem 108, der/das mit einer Antenne 110 gekoppelt ist und fähig ist, Signale, wie paketierte Signale, unter der Steuerung einer Steuerung 112 zu dem Knoten 102, 106 oder 107 zu senden bzw. von demselben zu empfangen. Die paketierten Datensignale können beispielsweise Sprach-, Daten- oder Multimedia-Informationen und paketierte Steuersignale einschließlich Knotenaktualisierungsinformationen umfassen.
Jeder Knoten 102, 106 und 107 umfasst ferner einen Speicher 114, wie einen Direktzugriffsspeicher (engl.: random access memory; RAM), der fähig ist, unter anderem Weiterleitungsinformationen, die denselben und andere Knoten in dem Netz 100 betreffen, zu speichern. Wie in 2 ferner gezeigt ist, können bestimmte Knoten, insbesondere mobile Knoten 102, einen Host 116 umfassen, der aus einer Zahl von Vorrichtungen, wie einem Notebook-Computer-Endgerät, einer mobilen Telefoneinheit, einer mobilen Dateneinheit oder einer anderen passenden Vorrichtung, bestehen kann. Jeder Knoten 102, 106 und 107 umfasst ferner die geeignete Hardware und Software, um ein Internet-Protokoll (IP) und ein Adressauflösungsprotokoll (engl.: Address Resolution Protocol; ARP) durchzuführen, deren Zwecke für Fachleute ohne Weiteres erkennbar sind. Die geeignete Hardware und Software, um ein Übertragungssteuerprotokoll (engl.: transmission control protocol; TCP) und ein Benutzerdatagramm-Protokoll (engl.: user datagram protocol; UDP) durchzuführen, können ebenfalls umfasst sein.
Weiterleitungstabellen
Jeder Knoten in dem Netz führt eine Unicast-Weiterleitungstabelle (engl.: unicast routing table). Jeder Eintrag in der Unicast-Weiterleitungstabelle zeichnet Informationen auf, die Folgendes umfassen:

• Zieladresse
• Zielknoten-Laufnummer
• Weiterleitungs-Metrik zum Ziel
• Nächster Sprung
• Lebensdauer

Wie nun im Detail erörtert wird, schafft die vorliegende Erfindung ein System und Verfahren zum Unterstützen eines Gruppenrufs (engl.: Multicast) in hoch dynamischen Ad-hoc-Netzen mit einer guten Skalierbarkeit, was durch einen Multicast-Weiterleitungsalgorithmus für einen Einsatz in drahtlosen Ad-hoc-Netzen, ohne dass feste Infrastrukturknoten vorhanden sind, erreicht werden kann. Die vorliegende Erfindung schafft ferner ein System und Verfahren zum Aufbauen eines quellenspezifischen Multicast-Baums auf Anforderung durch Verwenden eines Kernquellenknotens, um einen Weiterleitungs-Mehraufwand zu begrenzen, und ein Reparaturverfahren zum Reduzieren der Latenz einer Entdeckung einer Topologieänderung. Das System und Verfahren verwendet ferner eine Knotenlaufnummer-Einrichtung, um zwischen stromaufwärts angeordneten bzw. vorgeschalteten Knoten und stromabwärts angeordneten bzw. nachgeschalteten Knoten an dem Multicast-Baum zu differenzieren und veraltete Routeninformationen bei dem Reparaturverfahren zu vermeiden. Das System und Verfahren schaffen ferner ein aktives Anschließverfahren, um die Latenz einer Entdeckung einer Mitgliedschaftsänderung zu reduzieren.
In den letzten Jahrzehnten wurde eine Zahl von Multicast-Algorithmen für verdrahtete Netze entworfen. Der protokollunabhängige Multicast im dünnen Modus (engl.: protocol independent multicast – sparse mode; PIM-SM), wie in „PIM-SM: Protocol Specification", RFC 2362, von D. Estrin et al. beschrieben, und der kernbasierte Baum (engl.: core based tree; CBT), wie in „Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, von T. Ballardie beschrieben, bauen beide gemeinsam verwendete Bäume unter Gruppenmitgliedern auf, um den Multicast in großen statischen Netzen zu unterstützen. Der protokollunabhängige Multicast im dichten Modus (engl.: protocol independent multicast – dense mode; PIM-DM), wie in „PIM v2 DM Specification", Internet Draft, von S. Deering beschrieben, das Distance-Vector-Multicast-Routing-Protokoll (DVMRP), wie in „Distance Vector Multicast Routing Protocol", RFC 1075, von D. Waitzman et al. beschrieben, und Öffnen des kürzesten Mulicast-Wegs zuerst (engl.: multicast open shortest path first; MOSPF), wie in „Multicast Extensions to OSPF", RFC 1584, von J. Moy beschrieben, bauen alle quellenspezifische Bäume zwischen Quellen und Gruppenmitgliedern auf, um den Multicast in kleinen statischen Netzen zu unterstützen. Keines derselben zieht die hohe Dynamik mobiler Netze in Betracht. Dieselben sind für mobile drahtlose Ad-hoc-Netze, ohne dass Infrastrukturknoten eingesetzt werden, nicht passend.
In den letzten paar Jahren wurde eine Zahl von Multicast-Algorithmen für drahtlose Ad-hoc-Netze vorgeschlagen. Der baumbasierte Multicast-Algorithmus für drahtlose Ad-hoc-Netze umfasst das Multicast-Ad-Hoc-On-Demand-Distance-Vector-(MAODV-) Protokoll, das in „Multicast Operation of the Ad-Hoc On-Demand Distance Vector Routing Protocol", MobiCom '99, August 1999, von E. M. Royer und C. E. Perkins beschrieben ist. Das MAODV baut dynamisch einen Baum auf, der bei dem Multicast-Gruppenführer verwurzelt ist. Dasselbe baut proaktiv den gemeinsam verwendeten Multicast-Baum auf, der bei dem ausgewählten Multicast-Gruppenführer verwurzelt ist. Aufgrund der hohen Dynamik in drahtlosen Ad-hoc-Netzen ist dieser Algorithmus sehr auffällig hinsichtlich eines Aufrechterhaltens des Baums und hat Schwierigkeiten, sich mit dem Aufspalten und Zusammenführen von Multicast-Bäumen zu befassen.
Die maschenbasierten Multicast-Algorithmen umfassen das On-Demand-Multicast-Routing-Protokoll (ODMRP), das in „On-Demand Multicast Routing Protocol in Multihop Wireless Mobile Networks", Mobile Networks and Applications, Band 7, Ausgabe 6, Dez. 2002 von S. Lee, W. Su und M. Gerla beschrieben ist. Das ODMRP richtet auf Anforderung dynamisch eine Masche durch die Quelle ein und hält dieselbe aufrecht. Dasselbe kann die hohe Dynamik für drahtlose Ad-hoc-Netze unterstützen. Der Mehraufwand desselben zum Aufrechterhalten der Multicast-Masche ist jedoch relativ hoch, was die Skalierbarkeit desselben begrenzt.
Der auf einem vermaschten Baum basierende Multicast-Algorithmus Core Assisted Mesh Protocol (CAMP), der in der US-Patentanmeldung US2001/0034793 A1, 25. Okt. 2001, beschrieben ist, verwendet mehrere Kerne, um den gemeinsam verwendeten Baum zu verwenden, um alle Gruppenmitglieder zu verbinden. Die Kerne desselben werden dynamisch gewählt, daher kann derselbe den vermaschten Baum nicht in einer sehr kurzen Zeit aufbauen, um eine rasche Topologieänderung zu unterstützen. Zusätzlich sind die Kerne durch die mobilen Knoten in dem drahtlosen Netz miteinander vermascht, daher ist das Vermaschen unter Kernen gegenüber einer Mobilität anfällig. Derselbe hat ferner einen ähnlichen Nachteil wie der MAODV, da dieselben beide den Multicast-Baum und/oder die Masche proaktiv aufbauen und aufrechterhalten, ungeachtet dessen, ob ein Multicast-Verkehr existiert oder nicht.
Wie in dem vorhergehenden „Hintergrund"-Abschnitt erörtert ist, ist keine der existierenden Ad-hoc-Multicast-Weiterleitungen für drahtlose Ad-hoc-Netze mit einer hohen Dynamik und einer einigermaßen guten Skalierbarkeit passend. Wie nun beschrieben wird, liefert daher das Ad-Hoc-On-Demand-Distance-Vector-Multicast-Routing-Protokoll (AODVMRP) gemäß der vorliegenden Erfindung eine Multicast-Unterstützung in den drahtlosen Ad-hoc-Netzen ohne feste Infrastrukturknoten mit einer hohen Dynamik. Verglichen mit anderen existierenden Multicast-Weiterleitungsalgorithmen für drahtlose Netze kann der vorgeschlagene Algorithmus eine bessere Skalierbarkeit und Dynamik für drahtlose Ad-hoc-Netze unterstützen.
Bei dem System und Verfahren gemäß der vorliegenden Erfindung werden für jede Multicast-Gruppe quellenspezifische Kernbäume dynamisch aufgebaut und aufrechterhalten. Wenn ein Quellenknoten einen Verkehr zu einer Multicast-Gruppe senden möchte und keinen quellenspezifischen Baum hat, um alle beabsichtigten Gruppenmitglieder zu erreichen, kann derselbe ein Multicast-Baum-Entdeckungsverfahren einleiten. Um den quellenspezifischen Multicast-Baum aufzubauen, überträgt der Quellenknoten eine Weiterleitungs-Steuerpaket-Routenanfrage (engl.: route request; RREQ) mit der beabsichtigten Multicast-Gruppe als Ziel. Alle Multicast-Gruppenmitgliedsknoten, die die RREQ empfangen, antworten entlang den Rückrouten mit Routenantworten (engl.: route replies; RREPs) zu dem Quellenknoten. Alle Knoten, die die RREQ empfangen, geben dieselbe ferner durch Neuübertragen derselben zu der Nachbarschaft weiter, wenn die Lebenszeit (engl.: time-to-live; TTL) für diese RREQ nicht abläuft. Schließlich erreicht die RREQ alle Multicast-Gruppenmitglieder in dem Netz, und der Quellenknoten empfängt von denselben RREPs zurück. Durch Austauschen der RREQs und RREPs wird der quellenspezifische Baum dynamisch aufgebaut.
Der Quellenknoten überträgt periodisch die RREQ, um neue Gruppenmitglieder und neue Topologieänderungen zu entdecken und um den quellenspezifischen Multi cast-Baum desselben aufzufrischen. Um die RREQ-Überflutungswirkung zu begrenzen, fluten lediglich begrenzte Quellen periodisch die RREQ in dem Netz. Diese Quellen werden Kernquellenknoten genannt. Jeder Knoten bestimmt gemäß einigen Kriterien, die die Entfernung zu der nächsten Kernquelle, die Zahl von Kernquellen in dem Netz und die eigene MAC-Adresse sowie die MAC-Adresse der nächsten Kernquelle etc. sein können, auf eine verteilte Art und Weise, ob derselbe eine Kernquelle ist. Durch Begrenzen der Zahl von Kernquellen kann das vorgeschlagene Protokoll die Überflutungswirkung in dem Netz reduzieren und die Bandbreitennutzungs-Effizienz verbessern. Durch Beibehalten einer angemessen großen Zahl von Kernquellen kann dasselbe eine gute Verbindbarkeit unter den Multicast-Gruppenmitgliedern aufrechterhalten, wobei die Routensentfernungen nahe zu den optimalen Routenentfernungen sind.
In einem Netz, das den Multicast unterstützt, ist ein Knoten ein Multicast-Router, wenn derselbe ein Mitglied des Multicast-Baums ist. Der Multicast-Router führt zusätzlich zu der Unicast-Weiterleitungstabelle eine Multicast-Weiterleitungstabelle. Jeder Eintrag in der Multicast-Weiterleitungstabelle zeichnet Informationen auf, die Folgendes umfassen:

• Multicast-Gruppenadresse
• Nächste Sprünge (zu unterschiedlichen Zweigen an dem Multicast-Baum)
• Kernquellen-Liste
• Weitergabeknoten-Flag

Das Feld „Nächste Sprünge" ist eine verbundene Liste von Strukturen, von denen jede die folgenden Felder enthält:

• Adresse des nächsten Sprungs
• Lebensdauer für diesen nächsten Sprung
• Aktiviert-Flag

Die Lebensdauer wird durch einen periodischen Auffrischvorgang von dem Kernquellenknoten zu dem Gruppenmitglied verlängert. Wenn die Lebenszeit abläuft, sollte der zugeordnete „Nächster-Sprung"-Eintrag gelöscht werden. Lediglich ein nächster Sprung mit dem eingestellten Aktiviert-Flag kann verwendet werden, um den Multicast-Verkehr weiterzugeben.
Das Feld „Kernquellen-Liste" zeichnet die Kernquellenknoten auf. Dasselbe ist eine verbundene Liste von Strukturen, von denen jede die folgenden Felder enthält:

• Kernquellen-Adresse
• Sprunganzahl zu der Kernquelle
• Weiterleitungs-Metrik zu der Kernquelle
• Aktiviert-Flag
• Lebensdauer für diese Kernquelle

Die „Kernquellen-Adresse" zeichnet die Adresse für den Kernquellenknoten auf, der für das Aufbauen und Aufrechterhalten des quellenspezifischen Multicast-Baums für diese Multicast-Gruppe verantwortlich ist. Die Felder „Sprunganzahl zu der Kernquelle" und „Weiterleitungs-Metrik zu der Kernquelle" zeichnen die Sprunganzahl bzw. Weiterleitungs-Metrik zu der Kernquelle auf. Diese Kernquellen-Liste wird nach der Sprunganzahl oder der Weiterleitungs-Metrik, oder der Kombination von anderen Kriterien, zu der Kernquelle sortiert. Das Aktiviert-Flag zeigt an, ob diese Kernquelle durch den Multicast-Verkehr von diesem Quellenknoten aktiviert wurde. Das Aktiviert-Flag ist nicht eingestellt, wenn der Kernquelleneintrag neu erzeugt wird, und dasselbe wird durch das erste Multicast-Paket von dieser Kernquelle eingestellt. Das Feld „Lebensdauer für diese Kernquelle" zeichnet die Ablaufzeit für diese Kernquelle auf. Dieselbe wird durch zugehörige Weiterleitungs-Steuerpakete periodisch verlängert. Wenn dieser Zeitgeber abläuft, sollte dieser Kernquelleneintrag aus der Kernquellen-Liste gelöscht werden. Die Lebensdauer für diesen Multicast-Eintrag zeichnet die Ablaufzeit für diesen Eintrag auf. Wenn derselbe fällig ist, sollte dieser Eintrag aus der Tabelle gelöscht werden.
Das Weitergabeknoten-Flag zeigt an, ob dieser Knoten ein Weitergabemitglieds-Knoten für diese Multicast-Gruppe ist.
Multicast-Kernquellen-Wahl
Die Entscheidung für eine Kernquellen-Wahl wird auf eine verteilte Art und Weise durch jeden Quellenknoten in der Multicast-Gruppe getroffen. Wenn die Gesamtzahl von aktivierten Kernquellen kleiner als MULTICAST_KERN_QUELLE_ZAHL_SCHWELLE (engl.: MULTICAST_CORE_SRC_NUM_THRESHOLD) ist, sollte der Quellenknoten eine Kernquelle sein. Wenn die Gesamtzahl von aktivierten Kernquellen größer als MULTICAST_ KERN_ QUELLE_ZAHL_SCHWELLE (engl.: MULTICAST_CORE_SRC_NUM_THRESHOLD) ist, dann sollte derselbe aktivierte Kernquellen prüfen, um zu bestimmen, ob derselbe gemäß den Kernquellen-Auswahlkriterien, die die Entfernung zu der nächsten Kernquelle, die Zahl von Kernquellen in dem Netz und die eigene Adresse sowie die Adresse der nächsten Kernquelle etc. sein können, eine Kernquelle werden kann. Ein Beispiel ist hier beschrieben: Wenn die Zahl von Sprunganzahlen von diesem Knoten zu einem der aktivierten Kernquellenknoten kleiner als MULTICAST_KERN_QUELLE_ENTFERNUNG_SCHWELLE (engl.: MULTICAST_CORE_SRC_DISTANCE_THRESHOLD) ist und die Adresse dieses Knotens größer als die Adresse der Kernquelle ist, dann sollte dieser Knoten keine Kernquelle sein. Sonst kann derselbe eine Kernquelle sein. Die Entscheidung, eine Kernquelle zu sein, sollte getroffen werden, wenn ein Knoten anfangs ein Quellenknoten wird und wenn der periodische Auffrischzeitgeber für einen Kernquellenknoten abläuft. Die Kernquellenknoten-Bestimmungskriterien können mehr als diejenigen sein, die im Vorhergehenden beschrieben sind, um sich an die speziellen Multicast-Weiterleitungs-Bedürfnisse in unterschiedlichen Netzen anzupassen.
Multicast-Baum-Bildung
Der Multicast-Baum wird auf Anforderung gebildet, um Multicast-Gruppenmitglieder zu verbinden. Jeder Knoten kann einen Multicast-Verkehr zu der Gruppe senden. Wenn ein Knoten ein aktiver Quellenknoten für eine Multicast-Gruppe wird, sollte derselbe bestimmen, ob er gemäß der in dem letzten Abschnitt beschriebenen Regel eine Kernquelle sein sollte. Wenn derselbe ein Kernquellenknoten ist, sollte er durch Übertragen einer RREQ mit einer Lebenszeit (TTL), die als NETZ_DURCHMESSER (engl.: NET_DIAMETER) eingestellt ist, ein Multicast-Baum-Entdeckungsverfahren zu der Multicast-Gruppe einleiten. Das Paket trägt Informationen, die Folgendes umfassen:

• Quellenadresse (Ursprungsknotenadresse)
• Quellenknoten-Laufnummer
• Gewünschte Multicast-Gruppenadresse
• Sprunganzahl zu dem Quellenknoten
• Weiterleitungs-Metrik zu dem Quellenknoten
• TTL

Wenn die RREQ das Netz durchquert, werden auf dem Weg derselben Rückrouten erzeugt. Die Knotenlaufnummer-Einrichtung wird verwendet, um die Unicast-Routenschleife zu vermeiden. Dieselbe wird in dem Ad-Hoc-On-Demand-Distance-Vector-(AODV-) Protokoll vorgeschlagen, wie durch C. E. Perkins, E. M. Belding-Royer und S. R. Das in „Ad Hoc On-Demand Distance Vector (AODV) Routing", RFC, 2003, das wegen seiner Erläuterung des AODV-Protokolls hierin durch Bezugnahme aufgenommen ist, beschrieben. Das beschriebene System und Verfahren modifiziert die Verwendung der Knotenlaufnummer weiter, um zwischen stromaufwärts angeordneten Knoten und stromabwärts angeordneten Knoten an dem Multicast-Baum zu differenzieren. Der vorgeschaltete Knoten sollte eine frischere Knotenlaufnummer für den Kernquellenknoten haben.
Wenn ein Knoten in dem Netz die RREQ empfängt, bestimmt derselbe, ob er auf diese RREQ antworten sollte. Wenn der Knoten ein Multicast-Gruppenmitglied ist, sollte derselbe auf die RREQ mit einer RREP antworten. Die RREP trägt Informationen, die Folgendes umfassen:

• Quellenadresse
• Gewünschte Multicast-Gruppenadresse

Der Gruppenmitgliedsknoten sendet die RREP per Unicast bzw. Punkt-zu-Punkt-Verbindung entlang der Rückroute, die durch die RREQ erzeugt wurde, zu dem Kernquellenknoten zurück. Auf dem Weg zurück zu dem Kernquellenknoten wird jeder Knoten auf der Rückroute ein Weitergabeknoten der Multicast-Gruppe. Ein Zwischenknoten erzeugt den Multicast-Eintrag für diese Gruppe durch Aufzeichnen der Multicast-Gruppenadresse und Kernquellenknoten-Adresse, Hinzufügen des Knotens, von dem die RREP empfangen wird, zu der „Nächster-Sprung"-Liste und Einstellen des Aktiviert-Flags. Wenn der Knoten nicht das endgültige Ziel der RREP ist, sollte derselbe ferner den Knoten, zu dem die RREP weitergegeben werden soll, um den Kernquellenknoten zu erreichen, zu der „Nächster-Sprung"-Liste hinzufügen, das Aktiviert-Flag einstellen und die RREP zu dem einleitenden Kernquellenknoten zurück weitergeben. Wenn ein Knoten ein Weitergabeknoten wird oder ein Mitgliedsknoten mit dem Kernquellenknoten verbunden wird, kann derselbe eine Hallo-Nachricht (engl.: hello message) übertragen, um seine Nachbarschaft zu informieren, dass die Multicast-Gruppe aktiv ist. Die Hello-Nachricht trägt Informationen, die Folgendes umfassen:

• Quellenadresse (die aktuelle Knotenadresse)
• Multicast-Gruppenadresse

Wenn sich ein Knoten an mehreren Multicast-Gruppenbäumen für unterschiedliche Gruppen befindet, kann derselbe Multicast-Gruppenadressen in einer einzelnen Hello-Nachricht tragen oder alternativ unterschiedliche Gruppenadressen in unterschiedlichen Hello-Nachrichten tragen.
Ein Knoten, der die RREQ empfangt, verringert den TTL-Wert um 1. Wenn der aktualisierte TTL-Wert größer als null ist, d. h. derselbe nicht durch Fallen auf einen Ablaufschwellenwert abgelaufen ist, überträgt der Knoten die aktualisierte RREQ erneut, ungeachtet dessen, ob derselbe ein Multicast-Gruppenmitglied ist oder nicht.
Wenn die RREQ das gesamte Netz durchquert, alle Multicast-Gruppenmitglieder in dem Netz erreicht und die RREPs von allen Mitgliedern zu dem einleitenden Kernquellenknoten zurückerhält, wird der quellenspezifische Baum, der bei dem Kernquellenknoten verwurzelt ist, aufgebaut und kann verwendet werden, um den Multicast-Verkehr von dem Kernquellenknoten und dem Nicht-Kernquellenknoten nahe dem Kernquellenknoten zu verteilen.
Multicast-Baum-Aufrechterhaltung
Auffrischen
Ein Quellenknoten kann periodisch eine RREQ zu dem gesamten Netz übertragen, um Topologieänderungen und Mitgliedschaftsänderungen in dem Netz zu entdecken. Bevor eine Quelle das periodische Auffrischverfahren einleitet, sollte dieselbe bestimmen, ob sie ein Kernquellenknoten gemäß der in dem vorhergehenden Abschnitt beschriebenen Regel ist. Wenn der Knoten keine Kernquelle sein sollte, sollte derselbe nicht das gesamte Netz mit der RREQ überfluten. Wenn sonst der Knoten tatsächlich eine Kernquelle sein sollte, sollte derselbe die RREQ zu dem gesamten Netz übertragen, um einen neuen quellenspezifischen Baum zu entdecken, so dass die neuen Topologieänderungen und Mitgliedschaftsänderungen entdeckt werden können. Das Verfahren zum Auffrischen des quellenspezifischen Multicast-Baums ist ähnlich zu der Form des anfänglichen quellenspezifischen Multicast-Baums. Die Lebenszeiten für den „Nächster-Sprung"-Eintrag und den Kernquelleneintrag werden demgemäß verlängert.
Streichen und Reparatur
Jeder Knoten in dem Netz überwacht die Verbindungsqualität auf jeder Verbindung zwischen dem Knoten selbst und den Nachbarknoten desselben. Wenn ein Verbindungsabbruch erfasst wird, streicht der Knoten den Multicast-Zweig, der durch diese Verbindung verbunden wird, macht die Unicast-Routen, die diese Verbindung verwenden, ungültig und inkrementiert die Laufnummer für alle verlorenen Ziele. Wenn der Knoten kein Multicast-Mitgliedsknoten ist, sendet derselbe den Routenfehler (engl.: route error; RERR) zu den Knoten, die diesen Knoten verwenden, um diese verlorenen Ziele zu erreichen, um die Route zu dem verlorenen Kernquellenknoten ungültig zu machen, und RERR wird als „Reparatur wird benötigt" markiert. Wenn der Knoten tatsächlich ein Multicast-Gruppenmitgliedsknoten ist, prüft der Knoten durch Prüfen der Unicast-Routentabelle, ob diese Verbindung mit dem Knoten, der der nächste Sprung ist, verbunden ist, um den/die Kernquellenknoten zu erreichen. Wenn die Verbindung mit dem nächsten Sprung verbunden ist, kann der Knoten abhängig von der Verkehrsaktivität der Kernquelle ein Reparaturverfahren ohne Senden einer RERR-Nachricht einleiten. Wenn der letzte gesehene Multicast-Verkehr von dieser Kernquelle kürzer als das QUELLEN_AKTIVITÄTS_INTERVALL (engl.: SOURCE_ACTIVITY_INTERVAL) ist, dann kann derselbe annehmen, dass die Kernquelle noch aktiv ist und die Reparatur notwendig ist. Der Mitgliedsknoten überträgt eine RREQ, um eine neue Route zu der Kernquelle zu suchen. Die RREQ trägt Informationen, die Folgendes umfassen:

• Quellenadresse (die Adresse des einleitenden Knotens)
• Zieladresse (die Adresse des verlorenen Kernquellenknotens)
• Zielknoten-Laufnummer (die Laufnummer des verlorenen Kernquellenknotens, die diesem einleitenden Knoten bekannt ist)
• Multicast-Gruppenadresse

Bei diesem Reparaturverfahren kann lediglich der Kernquellenknoten selbst oder ein Knoten mit einer frischen Unicast-Route zu dem verlorenen Kernquellenknoten mit einer RREP auf die Reparatur-RREQ antworten. Der Knoten bestimmt durch Vergleichen der Zielknoten-Laufnummer, die dem Unicast-Routeneintrag für den Kernquellenknoten zugeordnet ist, und der Zielknoten-Laufnummer, die in der RREQ getragen wird, ob es sich um eine frische Unicast-Route handelt. Diese Einrichtung kann verhindern, dass die Knoten in der Stromabwärtsrichtung der abgebrochenen Verbindung mit veralteten Weiterleitungs-Informationen antworten. Wenn der Knoten, der die RREQ empfängt, eine aktive Route zu dem Kernquellenknoten mit einer Zielknoten-Laufnummer größer oder gleich derselben hat, die in der RREQ getragen wird, wird der Knoten als derjenige mit einer frischen Unicast-Route zu dem verlorenen Kernquellenknoten betrachtet und kann die RREP zu dem RREQ-einleitenden Knoten erzeugen. Die Reparatur-RREP-Nachricht trägt Informationen, die Folgendes umfassen:

• Quellenadresse (die Adresse des verlorenen Kernquellenknotens)
• Quellenknoten-Laufnummer (die Laufnummer des verlorenen Kernquellenknotens)
• Multicast-Gruppenadresse
• Sprunganzahl zu dem Quellenknoten (die Sprunganzahl zu dem Kernquellenknoten)
• Weiterleitungs-Metrik zu dem Quellenknoten

Nach dem Empfangen der Reparatur-RREP sollte jeder Knoten die Unicast-Route von dem einleitenden Knoten zu dem verlorenen Kernquellenknoten erzeugen/aktualisieren und den Multicast-Eintrag für die Multicast-Gruppe, die durch die Multicast-Gruppenadresse angezeigt wird, erzeugen/aktualisieren.
Wenn in der voreingestellten Wartezeit keine RREP empfangen wird, sollte der Mitgliedsknoten, der das Reparaturverfahren einleitet, einen RERR erzeugen, um den Verlust des Kernquellenknotens zu berichten, und der RERR wird als „Reparatur wird nicht benötigt" markiert.
Wenn ein Gruppenmitgliedsknoten einen RERR mit „Reparatur wird benötigt" empfängt, kann derselbe das Reparaturverfahren wie im Vorhergehenden beschrieben einleiten, ohne den RERR weiterzugeben. Wenn ein Nicht-Mitgliedsknoten einen RERR empfängt, gibt derselbe den RERR lediglich zu seinen Vorgängerknoten weiter.
Das Reparaturverfahren kann die Latenz der Wiederanschließens des Knotens mit dem quellenspezifischen Baum, der bei dem verlorenen Kernquellenknoten verwurzelt ist, reduzieren. Ohne das Reparaturverfahren muss der Knoten auf das nächste Auffrischverfahren von der Kernquelle warten.
Anschließen eines neuen Mitglieds
Wenn ein neuer Nicht-Quellen-Mitgliedsknoten in dem Netz vorhanden ist, kann derselbe auf das nächste Auffrischverfahren von dem Kernquellenknoten warten, um sich dem quellenspezifischen Baum anzuschließen. In diesem Fall gäbe es bei dem Anschließen bei dem Baum eine Latenz. Alternativ kann sich der Knoten aktiv der Multicast-Gruppe anschließen. Dies kann er tun, indem er zuerst seiner Nachbarschaft lauscht. Wenn der Knoten eine Hello-Nachricht mit seiner beabsichtigten Multicast-Gruppenadresse erfasst, kann derselbe eine Anschließen-RREQ übertragen, um sich dem Multicast-Baum anzuschließen, ohne auf das Auffrischverfahren zu warten. Jeder Knoten an dem Baum kann auf die RREQ mit einer Anschließen-RREP antworten. Die Anschließen-RREP trägt Informationen, die Folgendes umfassen:

• Quellenadresse (die Adresse des antwortenden Knotens)
• Kernquellenadresse (der Kernquellenknoten, mit dem sich der antwortende Knoten verbindet)
• Kernquellenknoten-Laufnummer (die Laufnummer für den Kernquellenknoten, der dem antwortenden Knoten bekannt ist)
• Sprunganzahl zu der Kernquelle (Sprunganzahl zu dem Kernquellenknoten, mit dem sich der antwortende Knoten verbindet)
• Weiterleitungs-Metrik zu der Kernquelle
• Zieladresse (Adresse des sich anschließenden Knotens)
• Gewünschte Multicast-Gruppe

Wenn sich der antwortende Knoten an mehreren Multicast-Quellenbäumen, die bei unterschiedlichen Kernquellenknoten verwurzelt sind, befindet, kann derselbe alle Kernquellenadressen in derselben RREP tragen. Derselbe kann ferner wahlweise mehrere RREPs senden, wobei jede derselben die Routeninformationen für einen Kernquellenknoten trägt.
Der neue Mitgliedsknoten kann mehrere RREPs von unterschiedlichen Knoten an dem Baum empfangen. Derselbe kann denjenigen mit der besten Weiterleitungs-Metrik wählen und eine Multicast-Aktivierungs- (engl.: multicast activation; MACT) Nachricht zurück zu dem antwortenden Knoten senden, um den Zweig zu aktivieren.
Wenn der Zwischenknoten die Anschließen-RREPs empfängt, verarbeitet derselbe die Nachricht auf die gleiche Art und Weise, auf die er die normale RREP-Nachricht verarbeitet. Derselbe sollte jedoch das Aktiviert-Flag für den nächsten Sprung in dem Multicast-Eintrag uneingestellt lassen, und der Eintrag wird durch die MACT-Nachricht aktiviert. Der Knoten kann den „Nächster-Sprung"-Eintrag erst dann zum Weitergeben des Multicast-Verkehrs verwenden, wenn derselbe aktiviert ist. Die Lebensdauer für den nicht aktivierten nächsten Sprung wird in dem Feld „Lebensdauer für diesen nächsten Sprung" angezeigt. Wenn die Lebensdauer abläuft und der „Nächster-Sprung"-Eintrag immer noch nicht aktiviert ist, wird dieser Eintrag aus der „Nächster-Sprung"-Liste gelöscht.
Durch Einführen des lokalen Reparaturverfahrens und des aktiven Anschließverfahrens für ein neues Mitglied kann der periodische Auffrischzeitgeber erhöht werden, um den Weiterleitungs-Mehraufwand weiter zu reduzieren.
Multicast-Verkehr-Weitergeben und Duplikat-Erfassung
Jeder Kernquellenknoten kann erst dann beginnen, den Multicast-Baum zu verwenden, um einen Multicast-Verkehr zu verteilen, wenn das anfängliche Multicast-Baum-Entdeckungsverfahren beendet ist. Nicht-Kernquellenknoten können den Multi cast-Verkehr ohne das Multicast-Baum-Entdeckungsverfahren sofort an dem Multicast-Baum verteilen.
Alle Knoten an dem Multicast-Baum akzeptieren Nicht-Duplikat-Pakete und geben dieselben zu allen nächsten Sprüngen für diese Multicast-Gruppe außer demjenigen, von dem die Pakete empfangen werden, weiter.
Jedes Paket trägt in seinem Paketkopf eine Laufnummer für eine Erfassung von Multicast/Broadcast-Verkehr-Duplikaten. Jedes Multicast-Baum-Mitglied führt eine Liste, um die Laufnummern von Paketen, die dasselbe für jede Quelle empfängt, aufzuzeichnen. Jede Laufnummer wird während einer Periode, die gleich NETZ_DURCHQUERUNGS_ZEIT (engl.: NET_TRAVERSAL_TIME) ist, in der Liste aufgezeichnet. Wenn ein Knoten ein Paket mit einer Laufnummer, die nicht innerhalb der NET_TRAVERSAL_TIME gesehen wird, empfängt, akzeptiert derselbe das Paket als ein neues Paket, sonst löscht derselbe das Paket als ein Duplikat.
Obwohl im Vorhergehenden lediglich einige exemplarische Ausführungsbeispiele der vorliegenden Erfindung detailliert beschrieben wurden, ist für Fachleute ohne Weiteres zu erkennen, dass bei den exemplarischen Ausführungsbeispielen viele Modifikationen möglich sind, ohne von den neuartigen Lehren und Vorteilen dieser Erfindung wesentlich abzuweichen. Demgemäß ist beabsichtigt, dass alle solchen Modifikationen in dem in den folgenden Ansprüchen definierten Schutzbereich dieser Erfindung umfasst sind.
Zusammenfassung
Verfahren zum Unterstützen eines Multicast-Weiterleiten in drahtlosen Multihop-Netzen
System und Verfahren zum Unterstützen eines Multicast in hoch dynamischen drahtlosen Multihop-Netzen, wie Ad-hoc-Netzen, mit einer guten Skalierbarkeit. Das System und Verfahren liefern einen Multicast-Weiterleitungs-Algorithmus zum Einsatz in drahtlosen Ad-hoc-Netzen ohne Vorhandensein fester Infrastrukturknoten. Dabei liefern das System und Verfahren ein Verfahren zum Aufbauen eines quellenspezifischen Multicast-Baums auf Anforderung, während ein Kernquellenknoten verwendet wird, um einen Weiterleitungs-Mehraufwand zu begrenzen. Das System und Verfahren liefern ferner ein Reparaturverfahren, um die Latenz einer Entdeckung einer Topologieänderung zu reduzieren, verwenden eine Knotenlaufnummer-Einrichtung, um bei dem Reparaturverfahren zwischen stromaufwärts angeordneten Knoten und stromabwärts angeordneten Knoten an dem Multicast-Baum zu differenzieren, und liefern ein aktives Anschließverfahren, um die Latenz einer Entdeckung einer Mitgliedschaftsänderung zu reduzieren.

Claims

Verfahren zum Unterstützen eines Multicast in einem drahtlosen Multihop-Netz, mit folgenden Schritten: Einrichten bestimmter Knoten in dem Netz als Kernquellenknoten; Beteiligen an einem Multicast-Baum-Entdeckungs- oder -Auffrischverfahren durch Betreiben von mindestens einem der Kernquellenknoten, um eine Routenanfrage-(RREQ-) Nachricht zu übertragen; und Aufbauen des Multicast-Baums oder Auffrischen des Multicast-Baums basierend auf der RREQ-Nachricht und mindestens einer Routenantwort (RREP)-Nachricht, die durch den mindestens einen Kernquellenknoten von einem anderen Knoten ansprechend auf die RREQ-Nachricht empfangen wird.
Verfahren nach Anspruch 1, bei dem die RREQ-Nachricht Informationen trägt, die mindestens entweder eine Quellenadresse, eine Quellenknoten-Laufnummer, eine gewünschte Multicast-Gruppenadresse, eine Sprunganzahl zu dem Quellenknoten, eine Weiterleitungs-Metrik zu dem Quellenknoten oder eine Lebenszeit (TTL) umfassen.
Verfahren nach Anspruch 1, bei dem der Schritt des Beteiligens an einem Multicast-Baum-Entdeckungsverfahren ferner ein Verwenden einer Knotenlaufnummer-Einrichtung aufweist, um zwischen stromaufwärts angeordneten Knoten und stromabwärts angeordneten Knoten an dem Multicast-Baum zu unterscheiden.
Verfahren nach Anspruch 1, bei dem der Schritt des Beteiligens an einem Multicast-Baum-Entdeckungsverfahren ferner den folgenden Schritt aufweist: Empfangen der RREP-Nachricht, die durch den anderen Knoten, der ein Multicast-Gruppenmitgliedsknoten ist, der die RREQ-Nachricht empfangen hat und ansprechend auf die RREQ-Nachricht eine Rückroute erzeugt hat, per Unicast entlang der Rückroute zu dem Kernquellenknoten gesendet wird, bei dem Kernquellenknoten.
Verfahren nach Anspruch 4, bei dem die Rückroute mindestens einen Knoten, der jeweils ein Weitergabeknoten einer Multicast-Gruppe wird, umfasst, derart, dass ein Weitergabeknoten angepasst ist, um eine Hello-Nachricht zu übertragen, um die Nachbarschaft desselben zu informieren, dass die Multicast-Gruppe aktiv ist, und die Hello-Nachricht Informationen trägt, die eine aktuelle Knotenadresse und eine Multicast-Gruppenadresse umfassen.
Verfahren nach Anspruch 1 , bei dem der Schritt des Einrichtens den folgenden Schritt aufweist: Bestimmen, ob ein Knoten ein Kernquellenknoten für eine Multicast-Gruppe sein sollte, basierend auf Kriterien, die eine Zahl von aktivierten Kernquellen in dem Netz, eine Kernquellen-Schwellenzahl, eine Entfernung zu einer nächsten aktivierten Kernquelle, eine Sprunganzahl-Schwellenzahl, eine Adresse des Knotens und eine Adresse der nächsten aktivierten Kernquelle aufweisen.
Verfahren nach Anspruch 1, ferner mit folgendem Schritt: Auffrischen des Multicast-Baums durch periodisches Übertragen einer RREQ-Nachricht von dem Kernquellenknoten.
Verfahren nach Anspruch 1, ferner mit folgendem Schritt: Überwachen einer Verbindungsqualität jeder Verbindung zwischen einem Knoten und dessen Nachbarknoten des Multicast-Baums; und Erfassen eines Verbindungsabbruchs zwischen den Knoten basierend auf der überwachten Verbindungsqualität.
Verfahren nach Anspruch 8, ferner mit folgenden Schritten: Streichen eines Multicast-Zweigs, der durch eine abgebrochene Verbindung verbunden ist, wenn ein Verbindungsabbruch erfasst wird; und Reparieren einer abgebrochenen Verbindung, wobei die Reparatur darin besteht, dass ein Knoten, der mit der abgebrochenen Verbindung verbunden ist, eine Reparatur-RREQ-Nachricht überträgt, ein verlorener Kernquellenknoten oder ein Knoten mit einer frischen Unicast-Route zu der verlorenen Kernquelle die Reparatur-RREQ-Nachricht empfängt, und ein empfangender Knoten eine Reparatur-RREP-Nachricht zu dem Knoten, der die Reparatur einleitet, sendet.
Verfahren nach Anspruch 1, das ferner ein Befähigen eines anderen Knotens aufweist, sich dem Multicast-Baum durch Durchführen der folgenden Schritte anzuschließen: Erfassen einer Hello-Nachricht, die eine Multicast-Gruppenadresse umfasst, bei dem Knoten, der versucht, sich dem Multicast-Baum anzuschließen; Übertragen einer Anschließen-RREQ-Nachricht von dem sich anschließenden Knoten, um sich dem Multicast-Baum anzuschließen; und Senden einer Anschließen-RREP-Nachricht von einem beliebigen Knoten an dem Multicast-Baum, um eine Latenz bei dem Anschließen eines neuen Mitglieds zu verkürzen.
Verfahren nach Anspruch 1, bei dem der Multicast-Baum eine Mehrzahl von Knoten umfasst, derart, dass Pakete, die durch die Knoten in dem Multicast-Baum gesendet werden, jeweils in einem Kopf eine Laufnummer tragen, um doppelte Pakete zu beseitigen.
Drahtloses Multihop-Kommunikationsnetz mit: einer Mehrzahl von Knoten, von denen einige Multicast-Quellenknoten sind; und einer Zahl von Kernquellenknoten, die kleiner als eine Gesamtzahl von Multicast-Quellenknoten in dem Netz ist, wobei die Kernquellenknoten angepasst sind, um sich durch Übertragen von Routenanfrage-(RREQ-) Nachrichten und Empfangen von Routenantwort-(RREP-) Nachrichten ansprechend auf die RREQ-Nachrichten und dann Aufbauen oder Auffrischen eines Multicast-Baums basierend auf einem Austausch der RREQ-Nachricht und von RREP-Nachrichten an einem Multicast-Baum-Entdeckungs- oder -Auffrischverfahren zu beteiligen.
Netz nach Anspruch 12, bei dem die RREQ-Nachricht Informationen trägt, die eine Quellenadresse, eine Quellenknoten-Laufnummer, eine gewünschte Multicast-Gruppenadresse, eine Sprunganzahl zu dem Quellenknoten, eine Weiterleitungs-Metrik zu dem Quellenknoten und eine Lebenszeit (TTL) umfassen.
Netz nach Anspruch 12, bei dem, wenn ein Multicast-Gruppenmitgliedsknoten die RREQ-Nachricht empfängt, der Mitgliedsknoten entlang einer Rückroute, die durch die RREQ-Nachricht erzeugt wurde, per Unicast eine RREP-Nachricht zu dem Kernquellenknoten sendet.
Netz nach Anspruch 12, bei dem einem der Knoten in dem Netz basierend auf Kriterien, die eine Zahl von aktivierten Kernquellen in dem Netz, eine Kernquellen-Schwellenzahl, eine Entfernung zu einer nächsten aktivierten Kernquelle, eine Sprunganzahl-Schwellenzahl, eine Adresse des Knotens und eine Adresse der nächsten aktivierten Kernquelle aufweisen, gestattet ist, ein Kernquellenknoten zu sein, derart, dass die Zahl von aktiven Kernquellenknoten kleiner als eine Kernquellen-Schwellenzahl ist; die Sprunganzahl von dem Knoten zu dem nächsten aktivierten Kernquellenknoten größer als eine Sprunganzahl-Schwellenzahl ist; oder die Sprunganzahl von dem Knoten zu einem aktivierten Kernquellenknoten kleiner als eine Sprunganzahl-Schwellenzahl ist und die Adresse des Knotens größer als die Adresse des Kernquellenknotens ist.
Netz nach Anspruch 12, bei dem jeder Knoten eine Verbindungsqualität jeder Verbindung zwischen einem Knoten und den Nachbarknoten desselben überwacht; und einen Verbindungsabbruch erfasst.
Netz nach Anspruch 12, bei dem jeder der Knoten angepasst ist, um die folgenden Operationen durchzuführen: Erfassen eines Verbindungsabbruchs zwischen demselben und einem anderen Knoten; Streichen eines Multicast-Zweigs, der durch eine abgebrochene Verbindung verbunden ist, wenn ein Verbindungsabbruch erfasst wird; und Reparieren einer abgebrochenen Verbindung durch Übertragen einer Reparatur-RREQ-Nachricht, die durch einen verlorenen Kernquellenknoten oder einen Knoten mit einer frischen Unicast-Route zu der verlorenen Kernquelle empfangen wird, und Senden einer Reparatur-RREP-Nachricht zu dem Knoten, der die Reparatur einleitet, durch den empfangenden Knoten.
Netz nach Anspruch 12, bei dem sich ein Knoten durch Erfassen einer Hello-Nachricht, Übertragen einer Anschließen-RREQ-Nachricht und Empfangen einer Anschließen-RREP-Nachricht, die durch einen Knoten an dem Multicast-Baum, der die Anschließen-RREQ-Nachricht empfängt, gesendet wird, einem Multicast-Baum anschließt.
Netz nach Anspruch 12, bei dem Pakete, die durch Knoten in einem Multicast-Baum gesendet werden, jeweils in einem Kopf eine Laufnummer tragen, um doppelte Pakete zu beseitigen.
Netz nach Anspruch 12, bei dem eine begrenzte Zahl von Kernquellenknoten, die die RREQ-Nachricht übertragen, einen Weiterleitungs-Mehraufwand begrenzt.