DE102014201202A1

DE102014201202A1 - Verfahren zur Realisierung einer Multicast-Übertragung in einem paketbasierten Kommunikationssystem

Info

Publication number: DE102014201202A1
Application number: DE102014201202.3A
Authority: DE
Inventors: Timo Lothspeich; Tobias Gruber; Andreas Mueller
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2014-01-23
Filing date: 2014-01-23
Publication date: 2015-07-23

Abstract

Die Erfindung betrifft ein Verfahren zur Realisierung von Multicast-Übertragungen in einem paketbasierten Kommunikationssystem mit einer zentralen Steuerungseinheit (100), mit folgenden Schritten: Bekanntmachung an die zentrale Steuerungseinheit (100), welcher oder welche Netzwerkknoten (101, 102, ...) an einer ersten Multicast-Gruppe interessiert ist bzw. sind, wobei die erste Multicast-Gruppe durch eine Multicast-Adresse eines ersten Typs spezifiziert wird und Zuweisung einer Multicast-Adresse eines zweiten Typs an die betreffenden Netzwerkknoten (101, 102, ...), die die zentrale Steuerungsinstanz anschließend für Multicast-Übertragungen an die betreffende Multicast-Gruppe verwenden kann, und Durchführung von Multicast-Übertragungen von der zentralen Steuerungseinheit (100) an die erste Multicast-Gruppe unter Ausnutzung der Kenntnis der daran interessierten Netzwerkknoten (101, 102, ...).

Description

Die vorliegende Erfindung betrifft ein Verfahren zur Realisierung einer Multicast-Übertragung in einem paketbasierten Kommunikationssystem, insbesondere zur effizienten Realisierung von Layer-2 Multicast-Übertragungen in einem Kommunikationssystem mit zentraler Steuerungseinheit.
Stand der Technik
Die Erfindung bezieht sich auf ein Verfahren für ein paketbasiertes Kommunikationssystem, bei dem mehrere Knoten über ein gemeinsam genutztes Übertragungsmedium ("Shared Medium") miteinander kommunizieren. Das gemeinsam genutzte Übertragungsmedium kann dabei beispielsweise ein linearer, drahtgebundener Bus oder ein drahtloser Übertragungskanal sein. Konkrete Beispiele für solche Systeme mit gemeinsam genutztem Übertragungsmedium sind Ethernet gemäß dem Standard IEEE 802.3 oder Wireless LANs (Local Area Networks) gemäß dem Standard IEEE 802.11.
Die Übertragung von (Unicast-)Nachrichten auf der Sicherungsschicht des ISO/OSI-Referenzmodells ("Layer-2") erfolgt in solchen Systemen üblicherweise in der Art und Weise, dass der Sender der Nachricht in einem speziellen Feld des zu übertragenden Rahmens die Layer-2-Adresse des jeweiligen Empfängers angibt ("Zieladresse"). Die verschiedenen Knoten des Systems prüfen dann bei jedem empfangenen Rahmen, ob die darin enthaltene Zieladresse ihrer eigenen Adresse entspricht und nur in diesem Fall erfolgt dann eine weitere Verarbeitung und Auswertung des entsprechenden Rahmens.
Darüber hinaus sind üblicherweise auch Multicast- sowie Broadcast-Übertragungen auf Layer-2 möglich, bei denen ein bestimmter Rahmen an potenziell mehrere Knoten gleichzeitig übertragen wird. Dafür werden normalerweise spezielle Multicast-Adressen verwendet, die jeweils einer bestimmten Multicast-Gruppe zugeordnet sind. Möchte ein Knoten eine Nachricht an eine bestimmte Multicast-Gruppe übermitteln, so sendet er (unter Berücksichtigung des jeweiligen Medienzugriffsverfahrens, wie z.B. CSMA/CD (Abkürzung für engl. Carrier Sense Multiple Access with Collision Detection) bei Ethernet) analog zu den oben beschriebenen Unicast-Übertragungen einen entsprechenden Rahmen an die der jeweiligen Multicast-Gruppe zugeordnete Multicast-Adresse. Es sei darauf hingewiesen, dass je nach Kommunikationssystem bzw. Medienzugriffsprotokoll in dem Rahmen ggf. zusätzlich kenntlich gemacht werden muss, dass es sich um eine Multicast-Übertragung handelt. Dies kann beispielsweise durch das Setzen eines speziell dafür vorgesehenen Flags erfolgen. In Ethernet oder Wireless LANs gemäß IEEE 802.11 ist dies allerdings nicht notwendig, da man anhand der Adresse selbst erkennen kann, ob es sich um eine Unicast- oder eine Multicast-Übertragung handelt. Alle Knoten, die diesen Rahmen empfangen, prüfen dann, ob sie an der zugeordneten Multicast-Gruppe interessiert sind und nur falls dies der Fall ist, erfolgt eine weitere Verarbeitung und Auswertung des Rahmens. Nachrichten, die an eine spezielle Broadcast-Adresse gerichtet sind, werden üblicherweise von allen Knoten verarbeitet und ausgewertet.
Die Zuordnung von Multicast-Adressen zu Multicast-Gruppen erfolgt oftmals in Abhängigkeit der Multicast-Adressen, die auf der darüberliegenden Netzwerkschicht (Layer-3 des ISO/OSI-Referenzmodells) verwendet werden. In modernen Kommunikationssystemen kommt auf der Netzwerkschicht dabei oftmals das Internet-Protokoll (IP) zum Einsatz (entweder IPv4 oder IPv6). In diesem Fall müssen folglich IP-Multicast-Adressen auf entsprechende Layer-2 Multicast-Adressen abgebildet werden. Die Abbildung von Layer-3 Multicast-Adressen auf Layer-2 Multicast-Adressen muss dabei nicht notwendigerweise eineindeutig sein, d.h. oftmals werden mehrere Layer-3 Multicast-Adressen auf dieselbe Layer-2 Multicast-Adresse abgebildet, insbesondere da der Multicast-Adressraum auf Layer-3 häufig größer ist als auf Layer-2. Bei der Verwendung von IPv4 über Ethernet werden 32-Bit IPv4-Multicast-Adressen beispielsweise in der Art und Weise auf 48-Bit Ethernet-Multicast-Adressen abgebildet, dass die ersten 25 Bit der Ethernetadresse auf einen speziellen Wert gesetzt werden (dadurch ist dann klar, dass es sich um eine Multicast-Adresse handelt) und die letzten 23 Bit entsprechen direkt den letzten 23 Bit der IPv4-Multicast-Adresse. Ein ähnliches Mapping existiert auch bei der Verwendung von IPv6 über Ethernet sowie bei anderen Kommunikationssystemen. Somit können alle Knoten eines Kommunikationssystems selbstständig ermitteln, welche Layer-2 Multicast-Adressen für welche Layer-3 Multicast-Übertragungen verwendet werden sollen und infolgedessen insbesondere auch auf Layer-2 entsprechende Filter setzen. Solche Filter, die festlegen, welche Multicast Nachrichten ein bestimmter Knoten auf Layer-2 auswerten und verarbeiten soll, werden üblicherweise von Layer-3 geeignet gesetzt, beispielsweise wenn höhere Schichten entsprechende Filter auf Layer-3 setzen.
Die beschriebene übliche Realisierung von Multicast-Übertragungen auf Layer-2 ist allerdings mit verschiedenen Nachteilen verbunden:
Der Layer-2 Multicast-Adressraum ist beispielsweise in der Regel deutlich größer als eigentlich notwendig, d.h. auf einem bestimmten Link bzw. in einem bestimmten System wird normalerweise nur ein Bruchteil der vorgesehenen Multicast-Adressen tatsächlich benötigt. Dies geht zu Lasten der Systemperformance und Energieeffizienz, da bei jeder Multicast-Übertragung immer unnötig lange Adressen mit übermittelt (und empfangsseitig ausgewertet) werden müssen.
Ferner weiß der Sender einer Multicast-Nachricht zunächst einmal nicht ohne Weiteres, ob überhaupt ein Knoten an dieser Nachricht interessiert ist, was ggf. zu unnötigen Multicast-Übertragungen führt. Zwar können auf der Netzwerkschicht (Layer-3)-Protokolle wie das Internet Group Management Protocol (IGMP) eingesetzt werden, um dem ein Stück weit entgegenzuwirken und zumindest bei Routern zu verhindern, dass Multicast-Verkehr an Teilnetze weitergeleitet wird, in denen niemand Interesse an bestimmten Multicast-Nachrichten hat. Dadurch wird das Problem potenziell überflüssiger Multicast-Übertragungen allerdings nicht behoben, sondern ggf. nur etwas verringert. Gängige Medienzugriffsprotokolle auf Layer-2 unterstützen in der Regel selbst keine Mechanismen, um solche überflüssigen Multicast-Übertragungen zu vermeiden.
Bei der Verwendung von adaptiven Übertragungsverfahren, d.h. falls ein oder mehrere Übertragungsparameter der physikalischen Schicht, wie z.B. die zu verwendende Coderate oder das zu verwendende Modulationsverfahren, dynamisch und knotenspezifisch angepasst wird, ist darüber hinaus mit den üblichen Verfahren zur Realisierung von Multicast-Übertragungen keine optimale Wahl entsprechender Übertragungsparameter möglich, da der Sender einer Multicast-Nachricht nicht weiß, welche Knoten daran interessiert sind. Aus diesem Grund muss in diesen Fällen ggf. ein sehr konservativer (d.h. ein beispielsweise auf den schlechtesten Fall ausgelegter) Übertragungsmodus verwendet werden.
Schließlich sei erwähnt, dass die üblicherweise verwendeten (und oben beschriebenen) statischen Abbildungen zwischen Layer-3-Multicast-Adressen und Layer-2-Multicast-Adressen sehr unflexibel sind und ggf. optimiert werden könnten, insbesondere wenn der Multicast-Adressraum auf Layer-3 größer ist als auf Layer-2. In einem nachteiligen Fall könnten beispielsweise alle tatsächlich verwendeten Layer-3 Multicast-Adressen auf dieselbe Layer-2-Multicast-Adresse abgebildet werden wohingegen alle anderen Layer-2-Multicast-Adressen ungenutzt blieben.
Im Folgenden wird speziell (aber nicht ausschließlich) ein Kommunikationssystem wie oben dargestellt betrachtet, bei dem es darüber hinaus eine zentrale Steuerungsinstanz ("Coordinator") gibt, die verschiedene Dinge bzw. Gegebenheiten innerhalb des Netzwerkes koordiniert. Dies beinhaltet unter anderem die weiter unten beschriebenen Mechanismen zur Realisierung von Layer-2-Multicast-Übertragungen in diesem Netzwerk. Die zentrale Steuerungsinstanz könnte in einer vorteilhaften Ausprägung aber zusätzlich auch noch weitere Funktionen mit übernehmen, wie beispielsweise die Steuerung des Zugriffes auf das gemeinsam genutzte Übertragungsmedium.
Die prinzipielle Anordnung eines solchen Systems ist in 1 für den allgemeinen Fall eines sogenannten Shared-Mediums (gemeinsames Übertragungsmedium) 120 und in 2 für den Fall eines linearen Busses 120' als Shared-Medium dargestellt. In den Figuren ist die zentrale Steuerungsinstanz mit 100 bezeichnet, einzelne Knoten sind mit 101, 102, ... bezeichnet. Ein konkretes Beispiel für ein solches Kommunikationssystem ist das in DE 10 2011 090 110 beschriebene System mit einem Polling-basierten Medienzugriffsverfahren.
Im Folgenden werden schwerpunktmäßig Layer-2-Multicast-Übertragungen von der zentralen Steuerungsinstanz zu einem oder mehreren Knoten betrachtet, aber es wird immer auch kurz erläutert, wie entsprechende Layer-2-Multicast-Übertragungen von einem Knoten an eine bestimmte Multicast-Gruppe realisiert werden können.
Prinzipiell könnten diese Multicast-Übertragungen analog zu dem oben geschilderten Ansatz realisiert werden, d.h. die zentrale Steuerungsinstanz könnte einfach eine Nachricht an die aus der Layer-3-Multicast-Adresse abgeleitete Layer-2 Multicast-Adresse schicken, was dann aber mit den ebenfalls geschilderten Problemen einhergehen würde.Insbesondere zusammen mit dem in DE 10 2011 090 110 beschriebenen Medienzugriffsverfahren würde dies die Leistungsfähigkeit und Energieeffizienz des Systems ggf. auch noch zusätzlich verschlechtern. Bei dem in DE 10 2011 090 110 beschriebenen Verfahren stehen generell nämlich zwei verschiedene Übertragungsmodi (Modus I, Modus II) zur Übertragung von Layer-2-Rahmen zur Verfügung: Ein erster Modus (Modus I), der eine vergleichsweise geringe Komplexität aufweist, aber mit dem auch nur eine relativ geringe Datenrate realisiert werden kann, sowie ein zweiter Modus (Modus II), der entsprechend eine vergleichsweise hohe Komplexität aufweist, aber mit dem dafür auch eine höhere Datenrate möglich ist. Je nach konkreter Ausprägung des Systems kann es dabei vorkommen, dass nur ein oder nur sehr wenige Knoten gleichzeitig im zweiten Übertragungsmodus Daten empfangen können. Dies ist insbesondere dann der Fall, wenn die Knoten über das gemeinsam genutzte Übertragungsmedium (also z.B. ein linearer Bus) selbst mit Energie versorgt werden.
Überträgt die zentrale Steuerungsinstanz 100 eine Multicast-Nachricht wie oben beschrieben im Modus II ohne zu wissen, wie viele Knoten diese Nachricht anschließend auswerten wollen, kann es folglich passieren, dass zu viele Knoten an dieser Nachricht Interesse haben und somit nicht genügend Leistung zur Verfügung steht, was letzten Endes ggf. zu einem Zusammenbruch des Systems oder zumindest eines Teils davon führen könnte ("Brown-Out"). Würde die zentrale Steuerungsinstanz 100 jede Multicast-Nachricht hingegen immer im Modus I übertragen, bestünde dieses Problem meistens zwar nicht mehr, aber dafür könnte evtl. nur eine sehr geringe Datenrate für Multicast-Verkehr realisiert werden. Dies wiederum würde sich nachteilig auf die Energieeffizienz und Leistungsfähigkeit des Gesamtsystems auswirken, insbesondere in Hinblick auf den Gesamtsystemdurchsatz sowie erreichbare Latenzzeiten.
Im Weiteren wird daher speziell (aber nicht ausschließlich) für solche Systeme mit einer zentralen Steuerungsinstanz ein neuartiger Ansatz zur effizienten Realisierung von Layer-2-Multicast-Übertragungen vorgeschlagen.
Aufgabe der Erfindung
Die Erfindung strebt ein Verfahren zur effizienteren Realisierung von Layer-2-Multicast-Übertragungen in paketbasierten Kommunikationssystemen mit einer zentralen Steuerungseinheit (Coordinator) an. Dies schließt auch Broadcast-Übertragungen mit ein, die weitestgehend als Sonderfall solcher Multicast-Übertragungen betrachtet werden können.
Offenbarung der Erfindung
Die Erfindung schlägt ein Verfahren mit den Schritten des Patentanspruchs 1 vor. Vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche.
Das vorgeschlagene Verfahren ist insbesondere für drahtgebundene Bussysteme vorteilhaft, bei denen alle oder zumindest ein Teil der angeschlossenen Knoten über den Bus selbst mit Energie versorgt werden. Darüber hinaus kann es aber auch in anderen drahtgebundenen, drahtlosen oder optischen Kommunikationssystemen eingesetzt werden, um beispielsweise die Leistungsfähigkeit in Hinblick auf den Gesamtsystemdurchsatz sowie Übertragungslatenzen zu verbessern.
Im Rahmen der Ansprüche ist von Multicast-Adressen eines ersten Typs bzw. Multicast-Adressen eines zweiten Typs die Rede. Diese Adressen werden auch als "Typ-1-Multicast-Adressen" bzw. "Typ-2-Multicast-Adressen" bezeichnet.
Die Erfindung ist besonders vorteilhaft einsetzbar, wenn sich ein Netzwerkknoten, der an einer bestimmten (Layer-2) Multicast-Gruppe interessiert ist (die durch eine so genannte Typ-1-Multicast-Adresse beschrieben wird), zunächst bei der zentralen Steuerungsinstanz für diese Multicast-Gruppe mit Hilfe geeigneter Layer-2 Protokollmechanismen registrieren muss. Die zentrale Steuerungsinstanz teilt dem betreffenden Netzwerkknoten dabei dann mit, welche so genannte Typ-2-Multicast-Adresse sie für die Übertragung entsprechender Nachrichten verwenden wird. Auf diese Weise hat die zentrale Steuerungsinstanz immer den Überblick, welche Knoten gerade an welcher Multicast-Gruppe Interesse haben und sie kann verschiedene Optimierungen vornehmen.
Die Erfindung ist im Zusammenhang mit einer dynamischen Registrierung ausführbar. Es kann aber auch eine Vorkonfiguration der Knoten und der Steuerungseinheit bzw. des Koordinators vorgesehen sein.
Es ist insbesondere möglich, dass die Steuerungseinheit buchführt über Interessenten an verschiedenen Multicast-Gruppen und den jeweils zugewiesenen Typ-2-Multicast-Adressen. Das erfindungsgemäße Verfahren ist mit verschiedenen Medienzugriffsverfahren zusammen anwendbar, wobei hier beispielsweise auf die Medienzugriffsverfahren der DE 10 2011 090 110 verwiesen wird.
Das erfindungsgemäße Verfahren ist auch nicht nur für die Realisierung von Multicast-, sondern auch für die Realisierung von Broadcast-Übertragungen in vorteilhafter Weise einsetzbar.
Vorteile der Erfindung
Da die zentrale Steuerungsinstanz und ggf. andere Knoten bei dem beschriebenen Verfahren stets weiß bzw. wissen, ob und ggf. welche Knoten an einer bestimmten (Layer-2) Multicast-Gruppe interessiert sind, können unnötige Übertragungen vermieden werden (wenn z.B. gar kein Knoten Interesse an einer bestimmten Multicast-Gruppe/-Nachricht hat).
Die zentrale Steuerungsinstanz kann abhängig von den Netzwerkknoten, die an einer bestimmten Multicast-Gruppe interessiert sind, dynamisch den optimalen Übertragungsmodus für eine entsprechende Nachricht auswählen. Mögliche Optionen sind beispielsweise die Realisierung der Multicast-Übertragung als Sequenz von aufeinanderfolgenden Unicast-Übertragungen oder als "echte" Multicast-Übertragung mit einem geeignet gewählten Übertragungsverfahren. Bei der Kombination der Erfindung mit dem in DE 10 2011 090 110 vorgeschlagenen Medienzugriffsverfahren könnte beispielsweise abhängig von den Mitgliedern einer bestimmten Multicast-Gruppe entweder der erste oder der zweite Übertragungsmodus ausgewählt werden.
Falls in einem Kommunikationssystem verschiedene Übertragungsparameter der physikalischen Schicht, wie die Coderate, das verwendete Modulationsverfahren, o.ä., nutzerspezifisch angepasst werden (beispielsweise auf der Grundlage der jeweiligen Übertragungskanäle), kann diese Adaption mit der vorliegenden Erfindung auch bei Multicast-Übertragungen optimal erfolgen, d.h. in der Art und Weise, dass gewisse Kriterien, wie z.B. die Einhaltung einer bestimmten Rahmenfehlerrate, für alle an der entsprechenden Multicast-Übertragung interessierten Netzwerkknoten eingehalten werden. Dies ist mit der vorliegenden Erfindung wiederum nur deshalb möglich, weil die zentrale Steuerungsinstanz alle an einer bestimmten Multicast-Übertragung interessierten Knoten kennt.
Durch die dynamische Vergabe spezieller Typ-2-Multicast-Adressen bei der Registrierung eines Netzwerkknotens für eine durch eine Typ-1-Multicast-Adresse spezifizierte Multicast-Gruppe kann die zentrale Steuerungseinheit intelligent geeignete (Unter-)Gruppierungen der jeweiligen Netzwerkknoten vornehmen. Insbesondere ist es dabei möglich, verschiedenen Knoten, die sich derselben Multicast-Gruppe anschließen wollen, verschiedene Typ-2-Multicast-Adressen zuzuweisen sowie für mehrere verschiedene Multicast-Gruppen dieselbe Typ-2-Multicast-Adresse zu verwenden. Diese Gruppierungen können dabei unter Berücksichtigung verschiedener Parameter optimiert werden, beispielsweise abhängig davon, ob ein Netzwerkknoten über eine eigene Energieversorgung verfügt oder nicht oder abhängig von der Qualität des Übertragungskanals zwischen einem Netzwerkknoten und der zentralen Steuerungseinheit. Eine weitere Rolle könnte bei solchen intelligenten Gruppierungen beispielsweise die erwartete Häufigkeit von Übertragungen an eine bestimmte Multicast-Gruppe sowie die erwarteten Nachrichtengrößen sein (falls bekannt).
Sofern die Typ-2-Multicast-Adressen kürzer sind als die verwendeten Typ-1-Multicast-Adressen (typischerweise EUI-48- oder EUI-64-Adressen), kann die Leistungsfähigkeit des Systems verbessert werden, da weniger Zeit für die Übertragung der Adressen selbst benötigt wird.
Gemäß einer besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens ist vorgesehen, dass von einer Multicast-Übertragung abgesehen wird, falls festgestellt wird, dass kein Interessent an einer entsprechenden Multicast-Gruppe interessiert ist.
Gemäß einer besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens ist vorgesehen, dass eine Option besteht, verschiedene Knoten für dieselbe Typ-1-Multicast-Adresse verschiedenen Typ-2-Multicast-Adressen zuzuweisen und umgekehrt.
Gemäß einer besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens ist vorgesehen, dass die Multicast-Übertragungen im Uplink, d.h. von einem Knoten an eine Multicast-Gruppe, realisiert werden.
Gemäß einer besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens ist vorgesehen, dass eine Registrierung wenigstens eines Netzwerkknotens nach einer voreinstellbaren Zeit automatisch abläuft.
Besonders bevorzugt besteht die Möglichkeit einer zeitlichen Befristung einer Registrierung sowie der Möglichkeit einer Verlängerung der Registrierung nach Ablauf einer zeitlichen Befristung.
Besonders bevorzugt besteht die Möglichkeit eines Abmeldens eines Netzwerkknotens von einer Multicast-Gruppe, wobei der Netzwerkknoten eine entsprechende Abmeldungs- bzw. Leave-Nachricht an die Steuerungseinheit sendet.
Gemäß einer besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens ist vorgesehen, dass die Steuerungseinheit den Empfang der Abmeldungsnachricht bestätigt.
Gemäß einer besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens ist eine gleichzeitige Abmeldung für alle Multicast-Gruppen durch einen Netzwerkknoten vorgesehen.
Als besonders zweckmäßig erweist sich die Bereitstellung eines oder mehrerer computerlesbarer Medien, auf denen Instruktionen gespeichert sind, die, wenn sie auf einem Computer ausgeführt werden, eines der in den Ansprüchen oder der Beschreibung beschriebenem Verfahren durchführen.
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
Es versteht sich, dass die vorstehend genannten und die nachfolgend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
Die Erfindung ist anhand von Ausführungsbeispielen in den Zeichnungen schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnungen ausführlich beschrieben.
Figurenbeschreibung
In dieser zeigt
1 eine Anordnung mit einer zentralen Steuerungseinheit und mehreren Knoten, welche über ein "Shared Medium" miteinander kommunizieren können, wobei die vorliegende Erfindung bei einer derartigen Anordnung vorteilhaft einsetzbar ist,
2 eine spezielle Anordnung gemäß 1 für den Fall, dass das "Shared Medium" einem linearen Bus entspricht,
3 ein Schaubild zur Erläuterung einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens,
4 ein Schaubild zur Erläuterung einer weiteren bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens,
5 ein Schaubild zur Darstellung eines bevorzugten weiteren Aspektes des erfindungsgemäßen Verfahrens,
6 ein Schaubild zur Darstellung eines weiteren bevorzugten Aspektes des erfindungsgemäßen Verfahrens,
7 ein bevorzugtes Rahmenformat für eine Nachricht, welche im Rahmen des erfindungsgemäßen Verfahrens versendet wird,
8 ein bevorzugtes Rahmenformat für eine weitere Nachricht, welche im Rahmen des erfindungsgemäßen Verfahrens versendet wird, und
9 ein weiteres bevorzugtes Rahmenformat für eine dritte Nachricht, welche im Rahmen des vorliegenden Verfahren übertragen werden kann.
Das vorgeschlagene Verfahren zur effizienten Realisierung von Layer-2-Multicast-Übertragungen kann in drei verschiedene Phasen eingeteilt werden:

1. Registrierung eines Knotens für eine bestimmte Multicast-Gruppe
2. Durchführung von Multicast-Übertragungen
3. Abmeldung eines Knotens von einer bestimmten Multicast-Gruppe

Jede dieser Phasen wird im Folgenden separat beschrieben. Dabei wird generell zwischen zwei verschiedenen Arten von Multicast-Adressen unterschieden: Einerseits als Typ-1-Multicast-Adressen bezeichnete Adressen sowie andererseits als Typ-2-Multicast-Adressen bezeichnete Adressen. Eine bestimmte (Layer-2) Multicast-Gruppe ist dabei eineindeutig durch eine zugeordnete Typ-1-Multicast-Adresse bestimmt. In einer vorteilhaften Ausprägung der Erfindung könnten solche Typ-1-Multicast-Adressen beispielsweise vom Typ EUI-48 (wie in Ethernet) oder EUI-64 sein. Diese Adressen werden unter anderem an der Schnittstelle zwischen Layer-2 und Layer-3 verwendet und/oder sind für bestimmte Layer-2 Mechanismen fest vorgegeben (z.B. eine fest definierte Broadcast-Adresse). Mit so einer Typ-1-Multicast-Adresse wird dem Layer-2 insbesondere mitgeteilt, welche Multicast-Gruppen für den betreffenden Knoten von Interesse sind. In einer vorteilhaften Ausprägung der Erfindung kann eine Typ-1-Multicast-Adresse dabei - wie beim Stand der Technik bereits beschrieben - von einer entsprechenden Layer-3-Multicast-Adresse (also z.B. einer IP-Multicast-Adresse) abgeleitet werden. Es wäre prinzipiell aber auch denkbar, dass eine Typ-1-Multicast-Adresse immer direkt einer Layer-3-Multicast-Adresse entspricht bzw. dass eine Layer-3-Multicast-Adresse auch als Typ-1-Multicast-Adresse verwendet wird. Typ-1-Multicast-Adressen sind für ein bestimmtes System (also z.B. Ethernet oder IEEE 802.11) typischerweise unabhängig vom betrachteten Netzwerk bzw. Link, d.h. die Art und Weise, wie aus einer Layer-3-Multicast-Adresse eine entsprechende Layer-2-Multicast-Adresse abgeleitet wird oder welche Layer-2-Multicast-Adressen fest vordefiniert sind, ist unabhängig vom jeweiligen Netzwerk/Link.
Typ-2-Multicast-Adressen werden in der Regel von der zentralen Steuerungseinheit dynamisch vergeben. Daher sind diese Adressen nicht unbedingt statisch bestimmten Multicast-Gruppen zugeordnet und auf verschiedenen Links bzw. in verschiedenen Netzwerken können unterschiedliche Typ-2-Multicast-Adressen für dieselben Multicast-Gruppen (definiert durch eine entsprechende Typ-1-Multicast-Adresse) verwendet werden. Die Länge einer Typ-2-Multicast-Adresse kann sich von der Länge einer Typ-1-Multicast-Adresse unterscheiden oder dieselbe Länge besitzen. In einer vorteilhaften Ausprägung der Erfindung sind Typ-2-Multicast-Adressen ggf. deutlich kürzer als entsprechende Typ-1-Multicast-Adressen, da auf einem bestimmten Link in der Regel ohnehin nur eine relativ geringe Anzahl von Multicast-Gruppen verwendet wird. Mit der Verwendung kürzerer Typ-2-Multicast-Adressen kann dann die Leistungsfähigkeit eines Netzwerkes in Hinblick auf Durchsatz und Latenzen ggf. verbessert werden. Nichtsdestotrotz ist es aber auch denkbar, dass Typ-2-Multicast-Adressen identisch sind mit Typ-1-Multicast-Adressen und keine dynamische Zuweisung durch die zentrale Steuerungseinheit erfolgt. In diesem Fall wären allerdings nicht mehr alle oben beschriebenen Vorteile der Erfindung gegeben. Im Detail wird darauf später weiter eingegangen.
Für die Übertragung von Multicast-Nachrichten auf Layer-2 werden vorzugsweise ausschließlich Typ-2-Multicast-Adressen verwendet. Typ-1-Multicast-Adressen werden vorzugweise nur zur Registrierung bzw. zum Abmelden eines Knotens von einer bestimmten Multicast-Gruppe eingesetzt. Es ist prinzipiell aber auch denkbar, dass Typ-1-Multicast-Adressen ebenfalls alternativ für die Übertragung von Multicast-Nachrichten auf Layer-2 verwendet werden können und mit Hilfe eines speziellen Feldes oder Wertes in so einer Nachricht angezeigt wird, welcher Multicast-Adresstyp (Typ 1 oder Typ 2) enthalten ist.
Phase 1: Registrierung eines Knotens für eine bestimmte Multicast-Gruppe
Jeder Knoten, der an einer bestimmten Multicast-Gruppe interessiert ist und an diese Multicast-Gruppe gerichtete Nachrichten empfangen möchte, muss sich zunächst bei der zentralen Steuerungseinheit 100 für diese Multicast-Gruppe registrieren. Der prinzipielle Ablauf dieser Prozedur ist in 3 dargestellt.
Der betreffende Knoten 101 sendet dazu zunächst eine spezielle Nachricht 350 (im Folgenden immer als ‚Multicast Group Management (Join)'-Nachricht bezeichnet) unter Berücksichtigung des jeweiligen Medienzugriffsverfahrens an die zentrale Steuerungsinstanz 100. Diese Nachricht beinhaltet vorzugsweise unter anderem die Typ-1-Multicast-Adresse derjenigen Multicast-Gruppe, an der der Knoten interessiert ist. Die zentrale Steuerungsinstanz 100 sendet daraufhin, ebenfalls unter Berücksichtigung des jeweiligen Medienzugriffsverfahrens, eine Bestätigungsnachricht 360 (im Folgenden immer als ,Join Multicast Group Acknowledgement'-Nachricht bezeichnet) an den betreffenden Knoten 101 zurück, mit der dem Knoten 101 unter anderem mitgeteilt wird, unter welcher Typ-2-Multicast-Adresse er an die gewünschte und durch die zuvor übermittelte Typ-1-Multicast-Adresse spezifizierte Multicast-Gruppe gerichtete Nachrichten auf Layer-2 empfangen kann. Folglich wertet der betreffende Knoten 101 fortan alle Multicast-Nachrichten aus, die an die zugewiesene Typ-2-Multicast-Adresse gerichtet sind.
Ist ein bestimmter Knoten 101, ... generell an allen Multicast-Nachrichten interessiert (weil er zum Beispiel als Multicast-Router auf Layer-3 agiert), so sind hierfür verschiedene Ausprägungen möglich, wie sich dieser Knoten für alle Multicast-Gruppen registrieren kann:

a) Der betreffende Knoten registriert sich wie oben beschrieben für jede Multicast-Gruppe einzeln.
b) Es gibt eine spezielle Typ-1-Multicast-Adresse, die speziell für diesen Fall reserviert ist, d.h. wenn ein bestimmter Knoten eine ,Multicast Group Management (Join)'-Nachricht mit dieser Typ-1-Multicast-Adresse an die zentrale Steuerungsinstanz sendet, erfolgt automatisch eine Registrierung für alle möglichen Multicast-Gruppen.
c) Die zentrale Steuerungsinstanz 100 erfährt durch andere Maßnahmen, welche Knoten an allen Multicast-Gruppen interessiert sind. So könnte beispielsweise während einer speziellen lnitialisierungsphase entsprechende Informationen an die Steuerungsinstanz übertragen werden (z.B. ob ein bestimmter Knoten als Multicast-Router agiert oder nicht).
d) Es gibt einen speziellen Nachrichtentyp (zusätzlich zu den bereits erwähnten ,Multicast Group Management (Join)'-Nachrichten), mit dem sich ein Knoten für alle Multicast-Gruppen registrieren kann.
e) Eine ,Multicast Group Management (Join)'-Nachricht enthält ein spezielles Feld, mit Hilfe dessen angezeigt werden kann, ob eine Registrierung für alle Multicast-Gruppen erfolgen soll.

Innerhalb einer ,Multicast Group Management (Join)'-Nachricht können darüber hinaus mehrere Typ-1-Multicast-Adressen angegeben werden, für die sich ein bestimmter Knoten registrieren möchte. Auf diese Weise wäre es dann auch möglich, dass sich ein bestimmter Knoten nicht unbedingt für alle Multicast-Gruppen registriert, aber für mehrere Multicast-Gruppen gleichzeitig. Die zentrale Steuerungsinstanz könnte dann entweder mit einer einzigen ,Join Multicast Group Acknowledgment'-Nachricht antworten, in der dem betreffenden Knoten für jede zuvor übermittelte Typ-1-Multicast-Adresse eine entsprechende Typ-2-Multicast-Adresse zugewiesen wird, oder mit mehreren einzelnen ,Join Multicast Group Acknowledgment'-Nachrichten, mit jeweils einer bestimmten (ggf. beschränkten) Anzahl solcher Zuordnungen.
Darüber hinaus ist es auch denkbar, dass ein Knoten 101, ... standardmäßig Mitglied aller Multicastgruppen ist und erst sobald sich der betreffende Knoten – wie zuvor bereits beschrieben – explizit für eine (oder mehrere) Multicast-Gruppen(n) registriert die standardmäßigen Registrierungen für alle anderen Multicast-Gruppen automatisch zurückgenommen werden.
Mögliche Strukturen für eine Multicast Group Management (Join)'-Nachricht 350 für den oben zuerst erläuterten Fall mit einer einzigen Typ-1-Multicast-Adresse sowie die ,Join Multicast Group Acknowledgement'-Nachricht 360 sind in 7 bzw. 8 dargestellt. Beide Nachrichten beinhalten dabei vorzugsweise eine geeignete Präambel 701, 801 zur Synchronisation und ggf. zur Kanalschätzung, einen Cyclic Redundancy Check (CRC) Code 710, 810 zur Fehlererkennung, sowie einen Nachrichtenheader 703, 803 mit geeigneten Kontroll- bzw. Metainformationen. Diese Kontroll- bzw. Metainformationen könnten dabei beispielsweise die Layer-2 (Unicast-)-Adresse des jeweiligen Empfängers beinhalten, den Typ und/oder die Länge der Nachricht spezifizieren, etc. Die ,Multicast Group Management (Join)'-Nachricht beinhaltet darüber hinaus ggf. noch ein Feld, das geeignet gesetzt sein muss, um die gewünschte Registrierung anzuzeigen (Feld 709 ,Join/Leave' in 7). Auf diese Weise kann genau dieselbe Nachricht auch zur Abmeldung eines Knotens 101, ... von einer bestimmten Multicast-Gruppe verwendet werden, indem nämlich nur der Wert dieses Feldes entsprechend anders gesetzt wird. Es ist aber auch denkbar, dass zwei komplett eigene Nachrichtentypen für diese Aufgaben verwendet werden, die jeweils einen unterschiedlichen Nachrichtentyp besitzen. Wie zuvor bereits erläutert enthält die ,Multicast Group Management (Join)'-Nachricht darüber hinaus insbesondere auch die Typ-1-Multicast-Adresse 705 derjenigen Multicast-Gruppe, für die der betreffende Knoten sich registrieren möchte.
In der Join ,Multicast Group Acknowledgement'-Nachricht 360 werden vorzugsweise zusätzlich zu den bereits beschriebenen Feldern noch die von der zentralen Steuerungsinstanz zugewiesene Typ-2-Multicast-Adresse (Feld 807) übermittelt sowie ggf. nochmals die in der ursprünglichen ,Multicast Group Management (Join)'-Nachricht enthaltene Typ-1-Multicast-Adresse 805. Diese muss nicht unbedingt enthalten sein, wenn beispielsweise aufgrund der konkreten Ausgestaltung der entsprechenden Prozedur oder aufgrund anderer Maßnahmen klar ist, auf welche Typ-1-Multicast-Adresse sich die zugewiesene Typ-2-Multicast-Adresse bezieht, aber auch in so einem Fall hätte man dadurch eine zusätzliche Absicherung gegen mögliche Fehlerfälle.
Die zentrale Steuerungsinstanz 100 speichert vorzugsweise ab, welche Knoten 101, ... sich für welche durch eine bestimmte Typ-1-Multicast-Adresse spezifizierte Multicast-Gruppe registriert haben und welche Typ-2-Multicast-Adressen sie den verschiedenen Knoten dabei zugewiesen hat. Dies ist dann unter anderem bei der tatsächlichen Durchführung von Multicast-Übertragungen von der zentralen Steuerungsinstanz an eine bestimmte Multicast-Gruppe von Bedeutung. Je nach Ausprägung der Erfindung können die anderen im System befindlichen Knoten die während der zuvor beschriebenen Registrierung eines Knotens für eine bestimmte Multicast-Gruppe zwischen diesem Knoten und der zentralen Steuerungsinstanz 100 ausgetauschten Nachrichten mithören und somit ebenfalls immer entsprechend abspeichern, welche Knoten 101, ... sich für welche Multicast-Gruppen registriert haben und welche Typ-2-Multicast-Adressen dabei von der zentralen Steuerungsinstanz zugewiesen worden sind. Dies ist ggf. vorteilhaft, sofern ein bestimmter Knoten 101, ... auch direkt auf Layer-2 eigene Multicast-Nachrichten an eine bestimmte Multicast-Gruppe senden kann bzw. darf.
Wie zuvor bereits erläutert sollte das Versenden der in 3 dargestellten Nachrichten 350, 360 unter Berücksichtigung des jeweils verwendeten Medienzugriffsverfahrens erfolgen. Basiert dieses beispielsweise wie in Ethernet auf CSMA/CD, so könnte der betreffende Knoten 101 einfach von sich aus eine entsprechende ,Multicast Group Management (Join)'-Nachricht 350 senden und die zentrale Steuerungsinstanz 100 analog nach einer nicht unbedingt festen Zeit mit der ,Join Multicast Group Acknowledgment'-Nachricht 360 antworten. Je nach Ausprägung der Erfindung könnten dabei zwischen diesen beiden Nachrichten auch andere Nachrichten derselben oder anderer Knoten versendet werden. Bei Realisierung des Medienzugriffes mit Hilfe des in DE 10 2011 090 110 beschriebenen Pollingverfahrens dürfte ein bestimmter Knoten eine ,Multicast Group Management (Join)'-Nachricht 350 nur nach dem Erhalt einer so genannten ,GrantTX'-Nachricht 370 von der zentralen Steuerungsinstanz 100 übertragen (siehe 4). In einer vorteilhaften Ausprägung würde die zentrale Steuerungsinstanz 100 dabei dann vor dem Versenden anderer Nachrichten bzw. innerhalb eines vordefinierten Zeitintervalls nach dem Empfang einer ,Multicast Group Management (Join)'-Nachricht 360 die zugehörige ,Join Multicast Group Acknowledgment'-Nachricht 360 an den betroffenen Knoten 101 senden. Dieser vorteilhafte Ablauf ist in 4 dargestellt.
Je nach Ausprägung der Erfindung kann die zentrale Steuerungsinstanz ggf. verschiedenen Knoten, die sich für dieselbe, durch eine bestimmte Typ-1-Multicast-Adresse spezifizierte Multicast-Gruppe registrieren, verschiedene Typ-2-Multicast-Adressen zuweisen. Dies kann beispielsweise dazu dienen, um die Anzahl der Knoten 101, ..., die bei einer Multicast-Übertragung (an eine Typ-2-Multicast-Adresse) angesprochen werden, zu begrenzen, oder um verschiedene andere Optimierungen vorzunehmen. Falls eine Nachricht an eine bestimmte, durch eine Typ1-Multicast-Adresse spezifizierte Multicast-Gruppe übertragen werden soll, müsste dies dann mehrere Übertragungen an die entsprechenden Typ-2-Multicast-Adressen zur Folge haben. Entsprechend kann die zentrale Steuerungsinstanz 100 ein- und dieselbe Typ-2-Multicast-Adresse für die Übertragung an mehrere, durch verschiedene Typ-1-Multicast-Adressen spezifizierte Multicast-Gruppen verwenden. Dies ist beispielsweise zwingend erforderlich, falls die Anzahl der Multicast-Gruppen, für die sich die verschiedenen Knoten registriert haben, die Anzahl der verfügbaren Typ-2-Multicast-Adressen übersteigt.
Für den Sonderfall, dass die Typ-2-Multicast-Adressen identisch zu den Typ-1-Multicast-Adressen sind und somit nicht dynamisch von der zentralen Steuerungsinstanz vergeben werden, ist die oben beschriebene Registrierung eines Knotens für eine bestimmte Multicast-Gruppe trotzdem sinnvoll (und ein wesentlicher Aspekt dieser Erfindung), da auf diese Weise die zentrale Steuerungsinstanz 100 (bzw. ggf. andere Knoten 101, ..., die die im Zuge der Registrierung ausgetauschten Nachrichten mitgehört haben) zumindest Kenntnis davon erlangen kann, welche Knoten an weIchen Multicast-Gruppen interessiert sind. Eine Übertragung einer von der zentralen Steuerungsinstanz zugewiesenen Typ-2-Multicast-Adresse wie in 8 dargestellt ist dann allerdings nicht mehr unbedingt erforderlich. In einer vorteilhaften Ausprägung würde die zentrale Steuerungsinstanz 100 aber auch in diesem Fall zumindest eine Bestätigungsnachricht 360 an den betreffenden Knoten 101, ... senden, damit mögliche Übertragungsfehler bei der initialen ,Multicast Group Management (Join)'-Nachricht 350 erkannt werden können und eine gewünschte Registrierung nicht aus Versehen verloren geht.
Je nach Ausprägung der Erfindung wäre es auch denkbar, dass die zentrale Steuerungsinstanz 100 die Registrierung eines bestimmten Knotens 101, ... für eine bestimmte Multicast-Gruppe mit Hilfe einer geeigneten Nachricht ablehnen kann. Diese Nachricht würde dann anstelle einer ,Join Multicast Group Acknowledgment'-Nachricht 360 gesendet werden bzw. in einem separaten Feld einer solchen ,Join Multicast Group Acknowledgment'-Nachricht 360 angezeigt werden.
In einer speziellen Ausprägung der Erfindung könnten alle oder zumindest einzelne Knoten 101, ... auch mit Hilfe von anderen Mechanismen mitgeteilt bekommen, welche Typ-2-Multicast-Adressen welchen Typ-1-Multicast-Adressen zugeordnet sind (beispielsweise durch eine statische Konfiguration bzw. durch die Übermittlung dieser Information mit Hilfe einer oder mehrerer Broadcast-Übertragungen). In diesem Fall wäre es dann ggf. ausreichend, wenn sich so ein Knoten 101, ... direkt mit Hilfe der entsprechenden Typ-2-Multicast-Adresse bei der zentralen Steuerungsinstanz 100 registriert. Sofern diese Typ-2-Multicast-Adresse für mehrere Multicast-Gruppen verwendet wird, kann die zentrale Steuerungsinstanz 100 dann allerdings nicht mehr wissen, an welchen dieser Multicast-Gruppen der betreffende Knoten 101, ... tatsächlich interessiert ist.
Phase 2: Durchführung von Multicast-Übertragungen
Aufgrund der notwendigen Registrierung eines Knotens 101, ..., der Nachrichten empfangen möchte, die für ein oder mehrere Multicast-Gruppen bestimmt sind, weiß die zentrale Steuerungsinstanz 100 (zumindest im fehlerfreien Fall) immer, ob und ggf. welche Knoten 101, ... an einer bestimmten Multicast-Nachricht interessiert sind. Dasselbe gilt ggf. für andere Knoten des Systems, die die im Zuge der Registrierung ausgetauschten Nachrichten mitgehört haben. Je nach Ausprägung der Erfindung sind dadurch verschiedene Optimierungen hinsichtlich der Übertragung von Multicast-Nachrichten möglich:
Falls sich überhaupt kein Knoten 101, ... für eine bestimmte Multicast-Gruppe registriert hat, an die eine bestimmte Nachricht gesendet werden soll, ist die Übertragung überflüssig und es kann daher auf diese Übertragung verzichtet werden.
Eine Multicast-Nachricht kann alternativ zu einer klassischen Multicast-Übertragung an eine entsprechende Multicast-Adresse auch an alle (oder einen Teil der) Mitglieder der jeweiligen Multicast-Gruppe in Form von einer Folge von Unicast-Übertragungen übermittelt werden. Dies kann beispielsweise vorteilhaft sein, wenn die Anzahl der Knoten 101, ..., die gleichzeitig aktiv sein können, begrenzt ist (z.B. falls die Knoten 101, ... über eine gemeinsame Energiequelle gespeist werden) oder wenn mit Unicast-Übertragungen deutlich höhere Übertragungsraten realisiert werden können als mit einer Multicast-Übertragung.
Wenn adaptive Übertragungsverfahren eingesetzt werden im Sinne, dass ein oder mehrere Übertragungsparameter (z.B. Coderate oder Modulationsverfahren) dynamisch an die vorherrschenden Kanalbedingungen angepasst werden, kann mit dem vorgeschlagenen Verfahren eine optimale Wahl dieser Übertragungsparameter erfolgen, da der Sender alle interessierten Empfänger kennt und somit deren Übertragungskanäle alle entsprechend bei der Wahl der Parameter mit berücksichtigen kann. Hat der Sender diese Kenntnis nicht, würde er üblicherweise einen nicht-adaptiven und sehr robusten Übertragungsmodus für eine solche Multicast-Übertragung verwenden, mit der nur eine vergleichsweise geringe Datenrate realisiert werden kann.
Sofern verschiedene Übertragungsmodi zur Verfügung stehen (wie beispielsweise bei dem in der DE 10 2011 090 110 vorgeschlagenen Pollingverfahren) kann abhängig von den an einer bestimmten Multicast-Gruppe interessierten Knoten 101, ... sowie ggf. abhängig von weiteren Parametern, wie die Größe einer zu übertragenden Nachricht oder die damit verbundenen Anforderungen an die Dienstgüte dynamisch ein geeigneter Übertragungsmodus ausgewählt werden, um die Leistungsfähigkeit des Systems zu optimieren.
Die zentrale Steuerungsinstanz 100 würde folglich bei einer Multicast-Übertragung die entsprechende Nachricht entweder an eine Typ-2-Multicast-Adresse schicken oder als eine Folge von ein oder mehreren Unicast-Übertragungen realisieren. Dabei sind natürlich auch Kombinationen dieser beiden Alternativen möglich. Sofern zum Beispiel verschiedenen Knoten, die sich für dieselbe, durch eine bestimmte Typ-1-Multicast-Adresse spezifizierte Multicast-Gruppe registriert haben, unterschiedliche Typ-2-Multicast-Adressen zugewiesen wurden, d.h. falls sozusagen unterschiedliche ,Untergruppen' gebildet wurden, könnte eine anstehende Multicast-Übertragung an diese Multicast-Gruppe für ein oder mehrere Untergruppen mit Hilfe einer ,echten' Multicast-Übertragung an die entsprechende Typ-2-Multicast-Adresse(n) realisiert werden, wohingegen die Übertragung zu den Knoten 101, ... der verbleibenden Untergruppe(n) als Folge von Unicast-Übertragungen realisiert werden könnte.
Die Übertragung von Multicast-Nachrichten von einem bestimmten Knoten 101, ... aus kann prinzipiell genauso realisiert werden wie oben für die Übertragung von Multicast-Nachrichten von der zentralen Steuerungsinstanz 100 aus beschrieben, sofern dies in Einklang mit dem jeweiligen Medienzugriffsverfahren steht und der betreffende Knoten 100, ... alle bei der Registrierung bzw. Abmeldung anderer Knoten 101, ... zwischen diesen Knoten und der zentralen Steuerungsinstanz 100 ausgetauschten Nachrichten mithören kann und somit ebenfalls weiß, welche Knoten 101, ... Mitglieder welcher Multicast-Gruppen sind und welche Typ-2-Multicast-Adressen ihnen dabei von der zentralen Steuerungsinstanz 100 zugewiesen worden sind.
Alternativ dazu ist aber auch denkbar, dass ein Knoten 101, ..., der eine Multicast-Nachricht übertragen möchte, diese immer zunächst an die zentrale Steuerungsinstanz 100 sendet. Je nach Ausprägung des Systems könnte diese Nachricht dann entweder die Typ-1-Multicast-Adresse der betreffenden Multicast-Gruppe enthalten, für die die Nachricht bestimmt ist, oder der Knoten könnte sich vorher erst selbst für die betreffende Multicast-Gruppe bei der zentralen Steuerungsinstanz registrieren müssen, um auf diese Weise die zugeordnete Typ-2-Multicast-Adresse zu bekommen und diese dann mit übertragen zu können. Der letztgenannte Ansatz ist ggf. aber nur dann sinnvoll, wenn die zentrale Steuerungsinstanz 100 verschiedenen Knoten 101, ... bei der Registrierung für eine bestimmte, durch eine Typ-1-Multicast-Adresse spezifizierte Multicast-Gruppe immer dieselbe Typ-2-Multicast-Adresse zuweist, da andernfalls nicht sichergestellt ist, dass der betreffende Knoten 101, ... bei der Übertragung einer Nachricht an die entsprechende Typ2-Multicast-Adresse alle Mitglieder der eigentlich angesprochenen Multicast-Gruppe erreicht.
Phase 3: Abmeldung eines Knotens von einer bestimmten Multicast-Gruppe
Sofern ein bestimmter Knoten 101, ... an einer bestimmten Multicast-Gruppe, für die er sich zuvor erfolgreich registriert hat, kein Interesse mehr hat, d.h. sofern der betreffende Knoten 101, ... zukünftig keine an diese Gruppe gerichteten Nachrichten mehr empfangen möchte, kann er sich explizit von dieser Multicast-Gruppe wieder abmelden. Eine solche Abmeldung kann ggf. wichtig für die Optimierung der Leistungsfähigkeit eines Systems sein, da andernfalls die Informationen über die Mitglieder einer Multicast-Gruppe und die zugewiesenen Typ-2-Multicast-Adressen, die die zentrale Steuerungsinstanz und ggf. andere Knoten gespeichert haben, nicht mehr aktuell sind.
Ein möglicher Ablauf zur Realisierung einer solchen Abmeldung ist in 5 dargestellt. Der betreffende Knoten 101, ... sendet dabei unter Berücksichtigung des jeweiligen Medienzugriffsverfahrens eine spezielle Nachricht 380 (im Folgenden immer als Multicast Group Management (Leave)'-Nachricht bezeichnet) an die zentrale Steuerungsinstanz 100. Je nach Ausprägung der Erfindung bestätigt die zentrale Steuerungsinstanz 100 dann den Empfang dieser Nachricht und die erfolgreiche Abmeldung von der betreffenden Multicast-Gruppe (wiederum unter Berücksichtigung des jeweiligen Medienzugriffsverfahrens) mit Hilfe einer weiteren Nachricht 390, die im Folgenden immer als Leave Multicast Group Acknowledgment'-Nachricht bezeichnet wird. Gegebenenfalls kann auf die Übertragung einer solchen Bestätigungsnachricht 390 aber auch verzichtet werden.
Mögliche Strukturen für die Multicast Group Managment (Leave)'-Nachricht 380 sowie die ,Leave Multicast Group Acknowledgement'-Nachricht 390 sind wiederum in 7 bzw. 8 dargestellt. Wie zuvor bereits erläutert hat die Multicast Group Management (Leave)'-Nachricht 380 ggf. dieselbe Struktur wie eine ,Multicast Group Management (Join)-'Nachricht 350, wobei lediglich ein spezielles Feld in beiden Fällen unterschiedlich gesetzt ist. Insbesondere enthält sie vorzugsweise eine Typ-1-Multicast-Adresse 705 der Multicast-Gruppe, von der sich der betreffende Knoten abmelden möchte. Alternativ wäre auch denkbar, dass der Knoten 101, ... der zentralen Steuerungsinstanz in der Nachricht die Typ-2-Multicast-Adresse angibt, die ihm zuvor von der zentralen Steuerungsinstanz für die betreffende Gruppe zugewiesen worden ist. Dies könnte allerdings Schwierigkeiten bereiten bzw. zu einem suboptimalen Verhalten führen, falls die zentrale Steuerungsinstanz dem betreffenden Knoten für unterschiedliche Multicast-Gruppen dieselbe Typ-2-Multicast-Adresse zugewiesen hat. Sofern der Knoten sich nämlich nur von einer dieser Multicast-Gruppen abmelden möchte, wäre dies nicht mehr unabhängig von den anderen möglich.
Die ,Leave Multicast Group Acknowledgment'-Nachricht 390 kann analog zur bereits beschriebenen Nachricht 360 aufgebaut sein und umfasst vorzugsweise ebenfalls eine Präambel 801 zur Synchronisation und Kanalschätzung, einen CRC Code 810 zur Fehlererkennung, sowie einen Nachrichtenheader 803 mit geeigneten Kontroll- bzw. Metainformationen, z.B. über den Typ und/oder die Länge der Nachricht. Darüber hinaus kann diese Nachricht, wie in 9 dargestellt, ggf. ein spezielles Feld zur Unterscheidung positiver und negativer Quittierungen enthalten. Die Leave Multicast Group-Acknowledgement Nachricht 390 gemäß 9 umfasst eine Präambel 901, einen Nachrichtenheader 903, ein Feld 904 mit positiver oder negativer Quittierung sowie einen CRC Code 910. Prinzipiell wären hierfür aber auch einfach zwei unterschiedliche Nachrichtentypen denkbar.
Bei Realisierung des Medienzugriffes mit Hilfe des in DE 10 2011 090 110 beschriebenen Pollingverfahrens dürfte ein bestimmter Knoten 101, ... eine Multicast Group Management (Leave)'-Nachricht nur nach dem Erhalt einer so genannten ,GrantTX'-Nachricht 370 von der zentralen Steuerungsinstanz 100 übertragen. In einer vorteilhaften Ausprägung würde die zentrale Steuerungsinstanz 100 dabei dann vor dem Versenden anderer Nachrichten bzw. innerhalb eines vordefinierten Zeitintervalls die Leave Multicast Group Acknowledgment'-Nachricht 390 an den betroffenen Knoten 101, ... senden. Dieser vorteilhafte Ablauf ist in 6 dargestellt.
Nach der Abmeldung eines bestimmten Knotens 101, ... von einer bestimmten Multicast-Gruppe aktualisiert die zentrale Steuerungsinstanz 100 ihre Übersicht, welche Knoten 101, ... Mitglied welcher Multicast-Gruppe sind und welche Typ-2-Multicast-Adressen den einzelnen Knoten von der zentralen Steuerungsinstanz dabei zugewiesen worden sind. Je nach Ausprägung der Erfindung gilt dasselbe auch für andere Knoten 101, ... die die im Zuge der Abmeldung ausgetauschten Nachrichten ggf. mitgehört haben und selbst eine solche Übersicht lokal halten.
Darüber hinaus ist auch denkbar, dass die Registrierung eines Knotens 101, ... für eine bestimmte Multicast-Gruppe immer nur für eine bestimmte Zeitdauer gültig ist. Diese Zeitdauer könnte dabei entweder fest vorgegeben sein, der Knoten 101, ... könnte diese Zeitdauer bei der Registrierung der zentralen Steuerungsinstanz 100 mitteilen, oder die zentrale Steuerungsinstanz 100 könnte die Zeitdauer dem jeweiligen Knoten 101, ... beispielsweise mit der ,Join Multicast Group Acknowledgment'-Nachricht 350 übermitteln. Dabei sind auch Kombinationen dieser Möglichkeiten denkbar, beispielsweise dass es eine vordefinierte (Maximal-)Zeit gibt, die (falls erforderlich) ggf. aber von einem Knoten 101,... bzw. der zentralen Steuerungsinstanz entsprechend angepasst werden kann. Bei so einer zeitbeschränkten Registrierung wäre ein Knoten 101, ... nach dem Ablauf der jeweiligen Zeitdauer nicht mehr Mitglied der jeweiligen Multicast-Gruppe, ohne dass dafür eine explizite Abmeldung notwendig ist. Die zentrale Steuerungsinstanz 100 (sowie ggf. andere Knoten 101, ...) würden dann nach dem Ablauf der Zeitdauer ihre Übersicht über die verschiedenen Multicast-Gruppen und die jeweils zugewiesenen Typ-2-Multicast-Adressen immer selbstständig entsprechend aktualisieren. Um eine Registrierung vor Ablauf der standardmäßig vorgesehenen Zeit zu verlängern könnte ein Knoten 101, ... beispielsweise einfach eine erneute Multicast Group Management (Join)'-Nachricht an die zentrale Steuerungsinstanz 100 senden.
In einer speziellen Ausprägung der Erfindung wäre es zudem denkbar, dass eine (zeitlich befristete) Registrierung immer automatisch verlängert wird, sobald die zentrale Steuerungsinstanz 100 eine Aktivität des betreffenden Knotens wahrnimmt, wie beispielsweise das Versenden einer Nachricht. Damit könnten dann zumindest unnötige Registrierungen gar nicht mehr vorhandener Knoten 101, ... automatisch gelöscht werden.
Je nach Ausprägung der Erfindung könnte es auch eine spezielle Nachricht geben, mit dem sich ein Knoten 101, ... von allen Multicast-Gruppen, für die er sich zuvor registriert hat, gleichzeitig abmelden kann. Hierbei sind verschiedene Möglichkeiten denkbar:
Es ist z.B. ein spezieller Nachrichtentyp dafür vorsehbar. Es ist auch denkbar, eine spezielle Typ-1-Multicast-Adresse vorzusehen, die hierfür reserviert ist (Analog zu der zuvor beschriebenen möglichen Registrierung für alle Multicast-Gruppen durch Angabe einer speziellen Typ-1-Multicast-Adresse in einer Multicast Group Management (Join)'-Nachricht. Hierfür könnte auch dieselbe Typ-1-Multicast-Adresse verwendet werden.) Wenn ein bestimmter Knoten 101, ... eine Multicast Group Management (Leave)'Nachricht 380 mit dieser speziellen Typ-1-Multicast-Adresse an die zentrale Steuerungsinstanz 100 sendet, würde dann eine Abmeldung von allen Multicast-Gruppen gleichzeitig erfolgen.
Man kann ein spezielles Feld in einer Multicast Group Management (Leave)'-Nachricht 380 vorsehen, mit Hilfe dessen die gewünschte Abmeldung von allen Multicast-Gruppen angezeigt werden kann.
Innerhalb einer Multicast Group Management (Leave)'-Nachricht 380 können mehrere Typ-1-Multicast-Adressen angegeben werden, von deren zugeordneten Multicast-Gruppen sich ein bestimmter Knoten abmelden möchte. Damit wäre es dann auch möglich, dass sich der Knoten 101, ... nicht unbedingt von allen Multicast-Gruppen abmeldet, aber von mehreren gleichzeitig, d.h. mit Hilfe einer einzigen Nachricht.
Es sei angemerkt, dass je nach Ausprägung der Erfindung Broadcast-Übertragungen an alle Knoten 101, ... eines Netzwerkes prinzipiell genauso behandelt werden können wie Multicast-Übertragungen. Hierbei ist allerdings eine Registrierung (bzw. Abmeldung) in der Regel nicht unbedingt erforderlich, insbesondere falls die zentrale Steuerungsinstanz 100 durch andere Maßnahmen weiß, welche Knoten 101, ... im Netzwerk vorhanden sind und welche Unicast-Adressen diese haben. Nichtsdestotrotz ist es je nach Ausprägung der Erfindung bzw. Ausgestaltung des Kommunikationssystems aber auch denkbar, dass sich Knoten 101, ... zunächst wie zuvor beschrieben für eine spezielle Broadcast-Gruppe' registrieren müssen und ihnen dann dynamisch eine entsprechende Typ-2-Multicast-Adresse dafür zugewiesen wird. Dies hätte den Vorteil, dass folglich auch im Broadcast-Fall eine flexible Einführung von Untergruppen möglich ist und somit ggf. verschiedene Optimierungen realisiert werden können und die zentrale Steuerungsinstanz (sowie ggf. andere Knoten) auf jeden Fall weiß, welche Knoten überhaupt im System vorhanden sind.
Es ist auch denkbar, dass die zentrale Steuerungsinstanz 100 einem (oder mehreren) bestimmten Knoten 101, ... die sich zuvor für eine bestimmte Multicast-Gruppe registriert haben und infolgedessen von der zentralen Steuerungsinstanz 100 eine entsprechende Typ-2-Multicast-Adresse zugewiesen bekommen haben, von sich aus eine neue Typ-2-Multicast-Adresse für die betreffende Multicast-Gruppe zuweist. Dies könnte zum Beispiel dazu verwendet werden, um abhängig von neuen Registrierungen für bestimmte Multicast-Gruppen die Zuweisung entsprechender Typ-2-Multicast-Adressen immer adaptiv optimieren zu können. Eine entsprechende Update Multicast Group'-Nachricht sollte dabei vorzugsweise die Typ-1-Multicast-Adresse der betreffenden Multicast-Gruppe und die neu zugewiesene Typ2-Multicast-Adresse beinhalten. Die Nachricht sollte vorzugsweise per Unicast an einen bestimmten Knoten 101, ... gesendet und von diesem dann entsprechend bestätigt werden.
Es versteht sich, dass die in den 7 bis 9 dargestellten Rahmenformate nur mögliche Beispiele darstellen. Insbesondere können die enthaltenen Felder auch anders angeordnet sein und es können weitere Felder vorhanden oder einzelne Felder nicht vorhanden sein.
Die hier beschriebene Erfindung kann bei einer Vielzahl von drahtgebundenen, drahtlosen und optischen Kommunikationssystemen mit einer zentralen Steuerungsinstanz (Coordinator) eingesetzt werden. Insbesondere ist ein Einsatz bei einem Feldbus für die Gebäudeautomatisierung denkbar.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 102011090110 [0011, 0013, 0013, 0022, 0025, 0063, 0071, 0079]

Zitierte Nicht-Patentliteratur

Standard IEEE 802.3 [0002]
Standard IEEE 802.11 [0002]
IEEE 802.11 [0004]
IEEE 802.11 [0052]

Claims

Verfahren zur Realisierung von Multicast-Übertragungen in einem paketbasierten Kommunikationssystem mit einer zentralen Steuerungseinheit (100), mit folgenden Schritten: Bekanntmachung an die zentrale Steuerungseinheit (100), welcher oder welche Netzwerkknoten (101, 102, ...) an einer ersten Multicast-Gruppe interessiert ist bzw. sind, wobei die erste Multicast-Gruppe durch eine Multicast-Adresse eines ersten Typs spezifiziert wird Zuweisung einer Multicast-Adresse eines zweiten Typs an die betreffenden Netzwerkknoten (101, 102, ...), die die zentrale Steuerungsinstanz anschließend für Multicast-Übertragungen an die betreffende Multicast-Gruppe verwenden kann, und Durchführung von Multicast-Übertragungen von der zentralen Steuerungseinheit (100) an die erste Multicast-Gruppe unter Ausnutzung der Kenntnis der daran interessierten Netzwerkknoten (101, 102, ...).
Verfahren nach Anspruch 1, gekennzeichnet durch die Möglichkeit eines Verlassens der ersten Multicast-Gruppe durch einen oder mehrere Netzwerkknoten (101, 102,...).
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass es sich bei den Multicast-Übertragungen um Übertragungen auf der Sicherungsschicht bzw. auf dem Layer-2 eines Netzwerks handelt.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die zentrale Steuerungseinheit (100) sowie die Netzwerkknoten (101, 102, ...) über ein gemeinsam genutztes Medium (z.B. ein linearer Bus) miteinander kommunizieren.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die -Multicast-Adressen des ersten Typs länger als die Multicast-Adressen des zweiten Typs sind.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Multicast-Adressen des ersten Typs vom Typ MAC-48, EUI-48 oder EUI-64 sind.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Bekanntmachung an die zentrale Steuerungsinstanz (100), welcher oder welche Netzwerkknoten (101, 102, ...) an einer ersten Multicast-Gruppe interessiert ist bzw. sind, mit Hilfe einer statischen Konfiguration erfolgt.
Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass zusätzlich die Zuweisung einer Multicast-Adresse des zweiten Typs an die betreffenden Netzwerkknoten (101, 102, ...) sowie die zentrale Steuerungsinstanz (100), die die zentrale Steuerungsinstanz (100) anschließend für Multicast-Übertragungen an die erste Multicast-Gruppe verwenden kann, ebenfalls mit Hilfe einer statischen Konfiguration erfolgt,
Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Bekanntmachung an die zentrale Steuerungsinstanz (100), dass ein bestimmter Netzwerkknoten (101, 102, ...) an einer ersten Multicast-Gruppe interessiert ist, sowie die Zuweisung einer Multicast-Adresse eines zweiten Typs an den betreffenden Netzwerkknoten (101, 102, ...), die die zentrale Steuerungsinstanz (100) anschließend für Multicast-Übertragungen an die betreffende Multicast-Gruppe verwenden kann, durch eine dynamischen Registrierung mit Hilfe geeigneter Protokollmechanismen erfolgt.
Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die dynamische Registrierung eines Netzwerkknotens (101, 102, ...) bei der zentralen Steuerungsinstanz (100) für eine erste Multicast-Gruppe folgende Schritte umfasst: – Senden einer ersten Nachricht (350) an die zentrale Steuerungsinstanz (100), wobei die erste Nachricht insbesondere die erste Multicast-Gruppe spezifiziert, für die sich der Netzwerkknoten (101, 102, ...) registrieren möchte, beispielsweise durch Angabe der zugehörigen Multicast-Adresse vom ersten Typ, – Assoziation einer ersten Multicast-Adresse vom zweiten Typ mit der entsprechenden ersten Multicast-Gruppe durch die zentrale Steuerungsinstanz (100), die die zentrale Steuerungsinstanz (100) zukünftig für Multicast-Übertragungen an die erste Multicast-Gruppe verwenden kann, und – Senden einer zweiten Nachricht (360) von der zentralen Steuerungsinstanz (100) an den betroffenen Netzwerkknoten (101, 102, ...), die die Registrierung bestätigt und insbesondere die von der zentralen Steuerungsinstanz (100) im vorherigen Schritt zugewiesene erste Multicast-Adresse vom zweiten Typ spezifiziert.
Verfahren nach einem der vorstehenden Ansprüche 2 bis 10, dadurch gekennzeichnet, dass für die Übertragung von Multicast-Nachrichten auf Layer 2 ausschließlich Multicast-Adressen vom zweiten Typ verwendet werden, wobei Multicast-Adressen vom ersten Typ zur Registrierung und/oder zum Abmelden eines Knotens (101, ...) von einer bestimmten Multicast-Gruppe eingesetzt werden.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Multicast-Übertragungen wenigstens teilweise als Folge von Unicast-Übertragungen realisiert sind.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Multicast-Übertragungen an eine Multicast-Adresse vom ersten Typ als Kombination aus Unicast-Übertragungen und echten Multicast-Übertragungen an Multicast-Adressen vom zweiten Typ realisiert sind.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Registrierung für eine Multicast-Gruppe angestoßen wird durch das Setzen eines entsprechenden Filters oder Wertes von Layer-3.
Verfahren nach einem der vorstehenden Ansprüche, gekennzeichnet durch eine Kombination und/oder Vermischung von Multicast-Adressen des ersten Typs und Multicast-Adressen des zweiten Typs bei der Multicast-Übertragung, wobei insbesondere eine Indikation erfolgt, welcher Adresstyp verwendet werden soll durch Setzung eines geeigneten Flags.