-
TECHNISCHES
GEBIET DER ERFINDUNG
-
Die
vorliegende Erfindung betrifft ein Verfahren, einen Router, einen
Zwischenknoten, einen Host und ein System zum Durchführen von
Multicast in einem Telekommunikationsnetz.
-
Multicast
(Gruppenruf) ist ein Dienst, welcher Quellen ermöglicht, ein einziges Exemplar
derselben Daten an eine Adresse zu senden, welche veranlasst, dass
die Daten an mehrere Empfänger
weitergesendet werden. Bei Multicast durchläuft jeweils nur ein Exemplar
einer Nachricht eine beliebige Übertragungsstrecke
in einem Netz, und Kopien der Nachricht werden erst dort hergestellt,
wo sich Wege verzweigen. Vom Standpunkt des Netzes aus bewirkt Multicast
eine deutliche Verringerung des Gesamtverbrauchs an Bandbreite,
da die Daten in dem Netz an geeigneten Punkten vervielfältigt werden
und nicht in den Endsystemen. Ferner braucht ein Server, welcher
eine Multicast-Nachricht sendet, nur eine Sitzung zu verwalten.
-
Lokale
Netze unterstützen
Multicast seit vielen Jahren. Bei Netzen, in denen Knoten ein gemeinsames
Kommunikationsmedium nutzen, kann Multicast leicht unterstützt werden.
Ein speziell adressiertes Paket kann durch mehrere Hosts von dem
Kommunikationsmedium abgelesen werden.
-
Das
Erweitern von Multicast-Fähigkeiten
auf Verbindungsnetze führte
jedoch zur Einführung
eines Routers an der Grenze eines Netzes, um dynamisch herauszufinden,
wie die ankommenden Datenpakete weiterzuleiten sind. Der Weg der
Weiterleitung ergibt sich zum Beispiel aus der Adresse, die im Header des
Datenpaketes enthalten ist, und aus der Routingtabelle, welche im
Router verwaltet wird. Es gibt einige Möglichkeiten, die Multicast-Adressierung
durchzuführen;
zum Beispiel kann die Adresse verwendet werden, welche die Multicastgruppe
angibt.
-
In
dem Falle, wenn Multicast in einem Internet-Protocol-(IP-)Netz verwendet wird, wird
es IP-Multicast
genannt. Bei IP-Multicast ist die Mitgliedschaft in einer Multicast
Session Group dynamisch; das bedeutet, dass die Hosts jederzeit
Gruppen beitreten und Gruppen verlassen können. Um Hosts in Netzen zu
ermöglichen
anzugeben, ob sie einer bestimmten Multicastgruppe beitreten oder
eine solche verlassen möchten,
gibt es ein Protokoll, welches Internet Group Message Protocol (IGMP)
genannt wird. Dieses Protokoll lässt
somit das System wissen, welche Hosts gegenwärtig zu welcher Multicastgruppe
gehören.
Diese Information wird von den Multicast-Routern benötigt, damit
sie wissen, welches Multicast-Datenpaket
zu welcher Schnittstelle weitergeleitet werden muss.
-
Das
IGMP ist ein Teil der IP-Schicht, und die IGMP-Nachrichten werden in IP-Datenpaketen übertragen.
Die Version 1 von IGMP wird in RFC 1112 "Host extensions for IP multicasting", S.E. Deering, 01.
Aug. 1989, beschrieben. In RFC 2236 "Internet Group Management Protocol,
Version 2", W. Fenner, November
1997, wird die Version 2 beschrieben. Das IGMP wurde für die IP
Version 4 entwickelt. Bei der Internet Protocol IP Version 6 gibt
es ein ähnliches Protokoll,
das Multicast Listener Discovery (MLD) heißt und für denselben Zweck verwendet
wird wie das IGMP. Die Beschreibung der ersten Version von MLD ist
in RFC 2710" Multicast
Listener Discovery (MLD) for IPv6", S. Deering, W. Fenner, B. Haberman,
Oktober 1999, zu finden. Die Nachrichten, die in MLD verwendet werden,
entsprechen jedoch den Nachrichten von IGMP. Im Folgenden wird das
IGMP als ein Beispiel verwendet. Dies sollte jedoch nicht auf das
IGMP eingeschränkt
werden; die Funktionalität
der Erfindung ist auch durch die Verwendung von MLD gegeben.
-
Das
IGMP verwendet Nachrichten, um seine Aufgaben zu erfüllen, zum
Beispiel die Nachricht Membership Report (Mitgliedschaftsbericht)
und die Nachricht Membership Query (Mitgliedschaftsabfrage), und
es kommen die folgenden Regeln zur Anwendung. Die verschiedenen
Versionen von IGMP enthalten außerdem
zusätzliche
Nachrichten.
-
Ein
Multicast-Router sendet in regelmäßigen Zeitabständen eine
Membership Query (Mitgliedschaftsabfrage), um festzustellen, ob
irgendein Host noch zu irgendeiner Gruppe gehört. Der Router muss an jede
Schnittstelle eine Abfrage aussenden. Die Gruppenadresse in der
Abfrage ist 0, da der Router eine Antwort von einem Host für jede Gruppe
erwartet, welche ein oder mehrere Mitglieder an jedem Host enthält. Es ist
auch möglich,
eine Membership Query für
eine bestimmte Gruppe anstatt für
alle Gruppen zu senden. Ein Host antwortet auf eine IGMP-Abfrage, indem er
einen IGMP-Bericht für
jede Gruppe sendet, welche noch wenigstens einen Benutzer enthält. Ein
Host tritt einer Gruppe auch bei, indem er den Membership Report
sendet.
-
Unter
Verwendung der Informationen, die durch Anwenden des Berichtes und
der Abfrage-Nachrichten empfangen wurden, wird eine Tabelle mit
den Schnittstellen erstellt, die wenigstens einen Host in einer
Multicastgruppe aufweisen. Nach dem Empfangen der Multicastdaten
leitet der Router die Daten an der Schnittstelle weiter, welche
wenigstens ein Mitglied hat.
-
Bei
IP-Multicast müssen
Empfänger
nicht wissen, wer oder wo die Absender sind, um Verkehr von ihnen
zu empfangen, und die Absender müssen nicht
wissen, wer die Empfänger
sind. Weder Absender noch Empfänger
müssen
sich um die Netztopologie kümmern,
da das Netz die Zustellung optimiert. Die Verteilung der Informationen über das
IP-Multicast wird auf der Basis einer hierarchischen Verbindung
der Hosts durchgeführt,
wie zum Beispiel eines Multicast-Zustellungsbaumes. Es wurden verschiedene
Algorithmen für
das Aufbauen von Multicast-Verteilungsbäumen vorgeschlagen, wie zum Beispiel
Spannbäume
(Spanning Trees), Auslieferungsbäume
(Shared Trees), Source-based Trees und Core-based Trees. Die Beschreibungen
der entsprechenden Algorithmen sind in "IP telephony: Packet-based multimedia
communications systems",
O. Hersent, D. Gurle, D. Petit, Addison-Wesley, Harlow, 2000 zu
finden. Nach der Erstellung des Multicast-Zustellungsbaumes erfolgt die Verteilung
der Informationen durch die IP-Multicast Routingprotokolle. Die
ausführliche
Beschreibung der entsprechenden IP-Multicast Routingprotokolle ist ebenfalls
in dem oben erwähnten
Dokument zu finden.
-
Multicast
verursacht Probleme beim Internetworking zwischen einem Festnetz
und einem Mobilnetz wie dem General Packet Radio System (GPRS) oder
dem Universal Mobile Communication System (UMTS). Die Probleme ergeben
sich zum Beispiel aus der Mobilität der Endbenutzer und der geringen Übertragungsbandbreite
des Mobilnetzes an der Luftschnittstelle. Ferner ist die Kommunikation
in einem Mobilkommunikationsnetz wie zum Beispiel in UMTS eine Unicast-Kommunikation.
Die Unicast-Kommunikation wird auch Punkt-zu-Punkt-Kommunikation genannt,
weil eine Nachricht von einem einzigen Absender zu einem einzigen
Empfänger
gesendet wird. Bei Netzen dieser Art, insbesondere im Kernnetz,
ist es nicht vorgesehen, eine Multicast-Kommunikation durchzuführen. Die
Gruppenkommunikation ist mittels einer Punkt-zu-Punkt-Kommunikation
implementiert, bei der ein Absender separat Pakete an die einzelnen
Mitglieder der Gruppe sendet. Für
eine Gruppe mit n Mitgliedern werden n Pakete auf dem gesamten Weg
zwischen dem Absender und den Empfängern benötigt, anstelle eines Paketes,
wenn Multicast verwendet wird.
-
Um
das Problem zu erläutern,
das in einem Punkt-zu-Punkt
orientierten Telekommunikationssystem auftritt, wird im Folgenden
ein Überblick über die Architektur
des General Packet Radio System (GPRS) Netzes gegeben.
-
Das
GPRS ist die paketvermittelte Erweiterung des Global System for
Mobile Communication (GSM), welches ein leitungsvermitteltes Netz
ist. Das bedeutet, dass der Benutzer ständig online sein kann, jedoch
nur für
den tatsächlichen
Datentransfer bezahlen muss. Um die neuen Anforderungen zu erfüllen, müssen beim
GSM einige Änderungen
eingeführt
werden. Unter anderem müssen
neue logische Knoten eingeführt
werden, der Serving GPRS Support Node (SGSN) und der Gateway GPRS
Support Node (GGSN). Die Hauptfunktionen des GGSN beinhalten die
Interaktion mit externen IP-Paketnetzen, welche Verbindungen zu
Internetdiensteanbietern (Internet Service Providers, ISPs) ermöglicht.
Vom Standpunkt eines externen IP-Netzes aus betrachtet fungiert
der GGSN als ein Router für
die IP-Adressen aller Teilnehmer, die von den GPRS-Netzen versorgt werden.
Der GGSN tauscht außerdem
Routing-Informationen mit dem externen Netz aus. Der SGSN bedient
alle GPRS-Teilnehmer,
welche sich physisch innerhalb des geographischen Versorgungsbereiches des
SGSN befinden. Er leitet ankommende und abgehende IP-Pakete weiter,
die an eine Mobilstation adressiert sind oder von einer solchen
gesendet werden. Zusätzlich
zu den neuen logischen Knoten müssen
auch neue Schnittstellen zwischen den Knoten definiert werden. Für die Erfindung
sind insbesondere die Schnittstellen Gn, Gi, Gp und IU-PS relevant. Die
Gp-Schnittstelle ist zwischen GGSN-Knoten definiert, die zu verschiedenen
Betreibern gehören.
Die Gn-Schnittstelle definiert das IP-basierte Backbone zwischen
den SGSN und GGSN. Die Gi ist die Schnittstelle zwischen GGSN und
einem weiteren Netz wie etwa dem Internet. Die Einschränkung von GPRS
ist, dass GGSN und SGSN auf eine solche Weise verbunden werden müssen, dass
IP zusätzlich zu
der gewählten
Technologie ausgeführt
wird, was bedeutet, dass SGSN und GGSN über IP-Adressen kommunizieren.
Die Iu-PS-Schnittstelle definiert die Kommunikation zwischen dem
SGSN und einer Funknetzsteuerung (Radio Network Controller, RNC).
Die RNC verwaltet Radio Access Bearers (Funkzugangskanäle) für Benutzerdaten,
das Funknetz und Mobilität.
Die Funkbasisstation, oft auch Basisstation BS oder in 3GPP Knoten
B genannt, stellt die Funkressourcen bereit und kommuniziert mit
dem Teilnehmergerät über die
Uu-Schnittstelle.
-
Eine
ausführliche
Beschreibung der Architektur ist zu finden in 3GPP TS 03.60 V7.5.0 (2001-01)
3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects, Digital cellular
Telecommunications System (Phase 2+), General Packet Radio Service
(GPRS), Service Description, Stage 2 (Ausgabe 1998) und 3GPP TR
25.925 3rd Generation Partnership Project; Technical
Specification Group Radio Access Network; Radio Interface for Broadcast/Multicast
Services (Ausgabe 1999), 3GPP TS 29.060 V4.1.9 (2001-06) 3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects, General Packet
Radio Service (GPRS), GPRS Tunnelling Protocol (GTP) (Ausgabe 4)
und 3GPP TS 25.413 V4.0.0 (2001-03) 3rd Generation Partnership
Project; Technical Specification Group Radio Access Network; UTRAN
Iu interface RANAP signalling (Ausgabe 4) und Internet Protocol
RFC 791.
-
Ähnliche
Knoten und Schnittstellen werden auch bei der nächsten Generation der drahtlosen Netze
verwendet, im UMTS, wie in 3GPP TS 23.060 V3.6.0 (2001-01) 3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects, General Packet
Radio Service (GPRS), Service Description, Stage 2 (Ausgabe 1999)
beschrieben. Um zwischen den Funktionalitäten dieser Knoten in UMTS zu
unterscheiden, werden oft erweiterte Namen verwendet, 3G-SGSN und
3G-GGSN. In der nachfolgenden Beschreibung wird nicht zwischen den
GPRS- und den UMTS-Knoten unterschieden.
-
Im
Folgenden wird unter Bezugnahme auf 1 ein Überblick über ein
UMTS-Netz gegeben, so wie es in den oben erwähnten 3GPP Spezifikationen,
UMTS Standard 23.060, spezifiziert ist.
-
1 zeigt
das Kernnetz mit einer Domain mit Paketvermittlung, die in der Abbildung
mit "Paket" bezeichnet ist.
Das Kernnetz ist mit einem Funknetz verbunden, das in der Abbildung
mit "Funknetz" bezeichnet ist. Über der
Paketvermittlungs-Domain des Kernnetzes befindet sich das IP-Multimedia-Subsystem
IP Multimedia für
konversationale Multimediadienste. Jedes der Subsysteme enthält die entsprechenden
Knoten. Relevant für
die vorliegende Erfindung sind die Knoten des Kernnetzes, die RNC,
der Knoten SGSN und der Knoten GGSN mit der beteiligten Schnittstelle
Gn. Gi und Iu-PS werden weiter unten ausführlicher beschrieben. IMS als
ein Beispiel verwendet die Paketvermittlungs-Domain, um Träger für konversationale
Multimediadienste zur Verfügung zu
stellen. Streaming-Multimediadienste sind auch ohne IMS möglich, indem
zum Beispiel ein Streaming-Server im Internet zusätzlich zu
einem entsprechenden paketvermittelten Träger verwendet wird.
-
Mit
der Einführung
der Streaming- und der konversationalen Multimediadienste werden
sich viele neue Punkt-zu-Mehrpunkt-Dienste entwickeln. Diese werden
hohe Anforderungen an die Netzinfrastruktur stellen und beträchtliche
Mengen an Bandbreite verbrauchen. Einige Beispiel solcher Dienste sind
Videoconferencing, Whiteboarding, Echtzeit-Mehrbenutzerspiele, Multimedia-Nachrichten, virtuelle
Welten.
-
Gemäß 1 ist
ein externes IP-Netz wie etwa das Internet als "Multimedia/IP-Netz" dargestellt, die Mobilstation als "TE" und das Kernnetz
als "Paket". Gegenwärtig werden
die IP-Multicast-Nachrichten im UMTS von einem Router, der sich
in einem externen IP-Netz befindet, zu der Mobilstation transparent
durch das Kernnetz hindurch über
eine Unicast-Verbindung gesendet. Danach wird, wie bereits erwähnt, das
Multicast auf der IP-Schicht durchgeführt, und vom Standpunkt der
Mobilstation TE aus gesehen ist der Router im Internet der erste
Knoten, in welchem die IP-Verbindung
endet, und daher der erste Knoten, der für Multicast geeignet ist. Das heißt, die
IP-Schicht im GGSN, welche die Kommunikation mit den externen Netzen
ermöglicht,
wird gegenwärtig
nicht als zur Durchführung
von Multicast in der Lage angesehen. Der Router leitet Multicast-Nachrichten
zum SGSN weiter, ohne zwischen einer Multicast-Nachricht und einer
Unicast-Nachricht zu unterscheiden. Die Trennung der Multicast-Datenströme erfolgt
bereits im Router im Internet, und dieselben Datenpakete werden
in Abhängigkeit
von der Anzahl der Empfänger
mehrfach über das
drahtlose Netz gesendet.
-
EP 1071296 stellt ein Verfahren
für das
Multicast innerhalb des Kernnetzes auf der Anwendungsschicht bereit.
Um jedoch die Multicastdaten zu übertragen,
muss wahrscheinlich ein neues Signalisierungsprotokoll definiert
werden, welches das Tunneling des Punkt-zu-Punkt-Protokolls vermeidet, das sich
unter der besagten Anwendungsschicht befindet. Andernfalls müssen auch
die Punkt-zu-Punkt-Verbindungen zu jedem Teilnehmer aufgebaut werden,
um Daten zu übertragen.
-
Das
heißt,
die existierende UMTS-Technik sieht nicht die Verwendung von effizientem
Multicast in dem Teil des Netzes vor, der in 1 durch
die Gn- und die Iu-PS-Schnittstelle bezeichnet ist. Ein beliebiger
Dienst, der für
mehrere Clients gleichzeitig erbracht wird, wird am Rand des drahtlosen
Netzes vervielfältigt,
und es werden mehrere Unicast-Verbindungen
zu den Clients verwendet. Insbesondere mit der Entwicklung von hochanspruchsvollen
Streaming- oder konversationalen Multimediadiensten, zum Beispiel
im Hinblick auf die Bandbreite, hat dies zur Folge, dass Ressourcen
im Netz sehr ineffizient genutzt werden.
-
Ferner
sind die existierenden Knoten nicht auf die Durchführung eines
Multicasts vorbereitet.
-
Ferner
sind die existierenden Lösungen
auf Teile der Netzübertragung
beschränkt,
zum Beispiel nur auf den Teil zwischen GGSN und SGSNs. Es ist erforderlich,
eine Lösung
zu finden, welche auf den gesamten Pfad im Kernnetz angewendet werden könnte, das
heißt,
zwischen den Randknoten. Zum Beispiel sind im Falle von UMTS die
Randknoten des Kernnetzes der GGSN und die einer Basisstation ähnliche
RNC.
-
Im
Allgemeinen verursacht die Einführung und
Durchführung
von Multicast in einem Netz, welches im Wesentlichen Punkt-zu-Punkt
orientiert ist, Probleme, wenn in Netzen dieser Art ein Unicast-Kanal
eingerichtet ist, um eine Kommunikation zwischen zwei Knoten durchzuführen. Das
heißt,
das Problem tritt nicht nur in einem drahtlosen Netz wie UMTS auf.
-
Weitere
Beispiele von Protokollen, die für Multicast
geeignet sind, sind das SIP (Session Initiation Protocol) oder das
RTSP (Real-time Streaming Protocol). Das SIP-Protokoll ist in Multiparty
Multimedia Session Control (MMUSIC) WG in IETF beschrieben, und
das RTSP wird in RFC 2326 Real Time Streaming Protocol (RTSP) H.
Schulzrinne, A. Rao, R. Lanphier, April 1998, abgehandelt. Diese
Protokolle gehören
ebenfalls zu den Punkt-zu-Punkt orientierten Protokollstapeln, und
die folgende Erfindung ist auch für sie anwendbar.
-
KURZDARSTELLUNG
UND BESCHREIBUNG DER ERFINDUNG
-
Eine
Aufgabe der vorliegenden Erfindung ist es, eine Lösung für eine effiziente
Durchführung
der Multicastübertragung
für Multicastgruppen
innerhalb eines drahtlosen Telekommunikationsnetzes bereitzustellen.
Insbesondere ist es eine Aufgabe der Erfindung, eine Vervielfältigung
der Multicast-Datenpakete
nahe bei den Endbenutzern des besagten Netzes durchzuführen.
-
Die
Erfindung wird durch ein Verfahren, einen Router, einen Serving
Node und ein System verkörpert,
die in den Ansprüchen
1, 17, 18, 19 und 20 offenbart sind. Vorteilhafte Ausführungsformen
werden in den abhängigen
Ansprüchen
beschrieben.
-
Die
Grundidee besteht darin, mindestens einen Transportebenen-Multicastgruppen-Tunnel
zwischen einem Router und einem Host bereitzustellen, welche die
Randknoten eines drahtlosen Telekommunikationsnetzes sind und wobei
sich der Host möglichst
nahe am Benutzer befindet. Zum Beispiel ist im Falle von UMTS der
Router der GGSN, und der Host ist die RNC. Diese Erfindung schränkt jedoch das
Multicast nicht dahingehend ein, dass es im Falle von UMTS nicht
sogar noch weiter bis zur Uu-Schnittstelle erweitert werden kann.
Der Transportebenen-Multicastgruppen-Tunnel kann entweder direkt zwischen
dem Router und dem Host eingerichtet werden, oder, falls weitere
Zwischenknoten wie zum Beispiel die SGSNs an der Übertragung
beteiligt sind, kann ein oder können
mehrere weitere Transportebenen-Multicastgruppen-Tunnel
zum Host eingerichtet werden. Ein Transportebenen-Multicastgruppen-Tunnel
kann zwischen dem GGSN und dem SGSN eingerichtet werden, und ein
weiterer zwischen dem SGSN und der RNC. In diesem Falle ist die
Beziehung zwischen den Transportebenen-Multicastgruppen-Tunneln in dem Zwischenknoten
zu garantieren, der die besagten Tunnel verbindet. Der Transportebenen-Multicastgruppen-Tunnel
wird mittels eines Transportschicht-Signalisierungsprotokolls für Tunneling
eingerichtet. In Abhängigkeit
von der Schnittstelle gibt es verschiedene Möglichkeiten. Zum Beispiel ist
an der Gn-Schnittstelle das GTP-C-Protokoll zu verwenden, und an der Iu-PS-Schnittstelle
das RANAP-Protokoll. Diese Protokolle werden einerseits als Mittel
für die
Einrichtung des Transportebenen-Multicastgruppen-Tunnels
verwendet, und andererseits als Mittel zum Bereitstellen der Multicast-Datenpakete
für die Übertragung.
-
Gemäß Anspruch
1 fordert ein Benutzer eine Multicastübertragung einer Multicastgruppe
an. Die Registrierung wird von dem Router empfangen, welcher den
Host über
den Benutzer informiert, der von dem Host bedient wird und sich
bei der Multicastgruppe registriert. Die Multicastübertragung
zwischen dem Router und dem Host mittels wenigstens eines Transportebenen-Multicastgruppen-Tunnels durchgeführt, welcher
der Multicastgruppe zugewiesen ist und welcher mittels eines Transportschichtprotokolls
für Tunneling
eingerichtet wird. Das Routing zu dem Benutzer wird entweder mittels
einer Punkt-zu-Punkt-Verbindung oder mittels einer Multicastübertragung
mit Punkt-zu-Punkt Mehrfach-Funkträger (Multi Radio Bearer). Wenn
im Falle der Punkt-zu-Punkt-Verbindung mehrere Benutzer an einen
Host angeschlossen sind, führt
der Host die Vervielfältigung
der Multicast-Datenpakete durch. In jedem Falle werden dei Multicastdaten
zu dem wenigstens einen Benutzer mittels eines Funkträgers geroutet.
-
Der
Transportebenen-Multicastgruppen-Tunnel weist die Struktur eines
Multicast-Zustellungsbaumes auf. Mittels dieser Struktur sind die Knoten
hierarchisch mit dem Router, dem GGSN, als eine Wurzel des Baumes,
verbunden. Die Knoten sind mit Hilfe von Transportebenen-Multicastgruppen-Tunneln
verbunden, die zwischen den Knoten eingerichtet sind.
-
Bei
einer Ausführungsform
der vorliegenden Erfindung wird die Multicastübertragung mittels eines Transportebenen-Multicastgruppen-Tunnels
zwischen dem Router und dem Host durchgeführt. Das heißt, der
Router ist die Wurzel des Multicast-Zustellungsbaumes, der mittels
des Transportebenen-Multicastgruppen-Tunnels eingerichtet ist, und
die Hosts sind Blätter
des Baumes.
-
Bei
einer anderen Ausführungsform
wird die Multicastübertragung
mittels eines Transportebenen-Multicastgruppen-Tunnels
durchgeführt,
der zwischen dem Zwischenknoten und dem Host eingerichtet ist. In
diesem Falle kann die Multicast-Zustellung zwischen dem Router und
dem Zwischenknoten mittels einer Multicastübertragung durchgeführt werden, die
auf einer höheren
Schicht als auf der Transportschicht durchgeführt wird, wie dies durch den
Transportebenen-Multicastgruppen-Tunnel
der Fall ist. Als ein Beispiel der Multicastübertragung auf einer höheren Schicht
dient im Falle von UMTS das GTP-U-Protokoll mit der TEID als der
Multicast-Kennung, wie weiter unten beschrieben wird.
-
Bei
einer anderen Ausführungsform
der vorliegenden Erfindung werden mindestens zwei Transportebenen-Multicastgruppen-Tunnel
zwischen dem Router und dem Host eingerichtet, was mindestens einen
Zwischenknoten zur Folge hat. Die Funktion des Zwischenknotens besteht
entweder darin, die zwischen dem Router und dem Host ausgetauschten Informationen
weiterzusenden, oder der Zwischenknoten ist die Wurzel des Transportebenen-Multicastgruppen-Tunnels,
der von dem Zwischenknoten zum Host führt.
-
Um
sicherzustellen, dass der Zwischenknoten in die Multicastübertragung
einbezogen ist, ist der Multicast-Zustellungsbaum ein quellenbasierter
Multicast-Zustellungsbaum.
-
Um
die Registrierung eines Benutzers für eine Multicastgruppe oder
seine Abmeldung von ihr durchzuführen,
informiert bei einer möglichen
Ausführungsform
der Benutzer den Router. Dies kann entweder durch eine direkte Kontaktaufnahme
mit dem Router geschehen, oder durch Informieren des Zwischenknotens,
welcher anschließend
das Informieren des Routers übernimmt.
Der Router informiert die Zwischenknoten und/oder die Hosts, um
für den Transportebenen-Multicastgruppen-Tunnel
zu registrieren oder abzumelden, und es wird eine Aktualisierung
der entsprechenden Einträge
im Netz durchgeführt.
Dieses Verfahren ist eine Ausführungsform
der Erfindung und darf nicht als eine Einschränkung für die Durchführung der
Registrierungsprozedur angesehen werden.
-
Die
Erfindung erfordert eine Form einer Kennzeichnung der Multicast-Datenpakete,
um diese Daten zu den entsprechenden Empfängern weiterzuleiten. Die Multicast-Datenpakete
werden mittels einer Multicast-Datenstrom-Kennung
gekennzeichnet, welche eine Kennung des Transportebenen-Multicastgruppen-Tunnels
sein kann, oder eine Adresse der Multicastgruppe, für welche
sich der Benutzer registriert, oder eine GTP Tunnelling ID TEID.
Die Wahl der Multicast-Datenstrom-Kennung hängt von dem gewählten Verfahren
für die
Multicast-Zustellung
ab, wie dem Transportebenen-Multicastgruppen-Tunnel oder
der Multicastübertragung
auf der höheren Schicht.
-
Vorzugsweise
sieht die Erfindung eine Verwaltung der Einträge in den entsprechenden Knoten des
Netzes vor. Der Router verwaltet eine Beziehung zwischen der Kennung
der Multicastgruppe, für
welche sich der Benutzer registriert, und der Kennung der gewählten Multicast-Datenstrom-Kennungen
im Kernnetz. Der Host verwaltet eine Beziehung zwischen der Multicast-Datenstrom-Kennung
und einer Kennung des Benutzers, welche zum Beispiel die internationale
Mobilfunkteilnehmerkennung (International Mobile Subscriber Identifier)
IMSI oder die Kennung des Funkträgers
sein kann.
-
Falls
der Zwischenknoten an der Multicast-Zustellung beteiligt ist, so
verwaltet der besagte Knoten die Beziehung der Multicast-Datenstrom-Kennung,
welche die ankommenden Multicastdaten vom Router kennzeichnet, und
der zu den Hosts abgehenden Multicastdaten.
-
Bei
einer Ausführungsform
der Erfindung ist der Transportebenen-Multicastgruppen-Tunnel ein dynamischer
Transportebenen-Multicastgruppen-Tunnel. Das heißt, falls ein Benutzer der
Erste ist, der sich für
eine Multicastgruppe registriert, wird der Transportebenen-Multicastgruppen-Tunnel
eingerichtet. Falls der Transportebenen-Multicastgruppen-Tunnel
bereits eingerichtet ist, wird der sich registrierende Benutzer
an den besagten Tunnel angeschlossen.
-
Bei
einer anderen Ausführungsform
der vorliegenden Erfindung wird der Transportebenen-Multicastgruppen-Tunnel voreingerichtet
und vorkonfiguriert, und es wird ein voreingerichteter Multicast-Zustellungsbaum
erzeugt. Das heißt,
der Netzbetreiber sorgt für
die Einrichtung des Transportebenen-Multicastgruppen-Tunnels, und die
sich registrierenden Benutzer werden an den geeigneten Tunnel angeschlossen.
Der Betreiber kann zum Beispiel verschiedene Dienstgüten oder
verschiedene geographische Anforderungen als die Parameter für die Vorkonfiguration
des Tunnels betrachten.
-
Es
ist außerdem
vorteilhaft, im Falle des voreingerichteten und vorkonfigurierten
Transportebenen-Multicastgruppen-Tunnels ein Multiplexieren der mehreren
Multicastgruppen auf demselben vorkonfigurierten Transportebenen-Multicastgruppen-Tunnel vorzusehen.
In diesem Falle ist eine zusätzliche
Verwaltung erforderlich, um das Multiplexieren und das Demultiplexieren
in den betrachteten Knoten durchzuführen.
-
Die
Erfindung offenbart außerdem
einen Router, einen Host, einen Zwischenknoten und ein System.
-
Der
Router ist in der Lage, eine Multicastübertragung für eine Multicastgruppe
innerhalb eines Telekommunikationsnetzes mit dem Router und wenigstens
einem Host, der Benutzer bedient, durchzuführen, wobei sich zwischen dem
Router und dem Host wenigstens ein Zwischenknoten befindet. Der Router
weist Mittel zum Abwickeln einer Benutzeranforderung nach Registrierung
für eine
Multicastgruppe auf. Dies kann zum Beispiel das Empfangen einer IGMP-Nachricht,
das Prüfen
der Multicast-Adresse beinhalten. Falls in dem Kernnetz keine Multicastgruppe
vorhanden ist, richtet der Router einen Transportebenen-Multicastgruppen-Tunnel
ein. Dies erfolgt durch Mittel zum Bereitstellen eines Transportebenen-Multicastgruppen-Tunnels,
der mittels eines Transportschichtprotokolls für Tunneling eingerichtet wird.
Ferner weist der Router Mittel zum Verwalten einer Beziehung zwischen
der Multicastgruppe und dem Transportebenen-Multicastgruppen-Tunnel
auf, um die Multicastdaten auf eine geeignete Weise zu sortieren
und weiterzuleiten.
-
Der
Zwischenknoten ist in der Lage, eine Multicastübertragung für eine Multicastgruppe
innerhalb eines Telekommunikationsnetzes mit einem Router und wenigstens
einem Host, der Benutzer bedient, durchzuführen, wobei sich zwischen dem
Router und dem Host wenigstens ein solcher Zwischenknoten befindet.
Der Zwischenknoten weist Mittel zum Abwickeln einer Benutzeranforderung
nach Registrierung für
eine Multicastgruppe auf. Der Benutzer kann sich entweder bei dem
Zwischenknoten oder bei dem Router registrieren. Die Funktion der Mittel
kann auch in einem Weiterleiten dieser Nachricht zu dem Router bestehen.
Bei einer Ausführungsform
der Erfindung ist ein Multicast-Zustellungsbaum, der mittels eines
Transportebenen-Multicastgruppen-Tunnels eingerichtet wurde, zwischen dem
Zwischenknoten und den Hosts aufgebaut. In diesem Falle muss der
Zwischenknoten eine ähnliche
Funktionalität
zur Verfügung
stellen wie der Router. Dies wird durch Mittel zum Bereitstellen
eines Transportebenen-Multicastgruppen-Tunnels erreicht, der mittels
eines Transportschichtprotokolls für Tunneling eingerichtet wird.
Ferner weist der Zwischenknoten Mittel zum Verwalten einer Beziehung
zwischen ankommenden und abgehenden Multicastdaten der Multicastübertragung
auf. Die ankommenden Daten kommen vom Router an, und die abgehenden Daten
werden zum Host gesendet.
-
Der
Host ist in der Lage, eine Multicastübertragung für eine Multicastgruppe
innerhalb eines Telekommunikationsnetzes mit einem Router und wenigstens
einem solchen Host, der Benutzer bedient, durchzuführen, wobei
sich zwischen dem Router und dem Host wenigstens ein Zwischenknoten
befindet. Der Host weist Mittel zum Empfangen einer Multicastübertragung
auf, die entweder von dem Router oder von dem Zwischenknoten gesendet
wird. Ferner weist der Host Mittel zur Verwaltung einer Beziehung zwischen
der empfangenen Multicastübertragung und
dem Benutzer auf, um die Multicastübertragung mittels eines Funkträgers zum
Benutzer weiterzuleiten. Falls mehr als ein Benutzer für die Multicastgruppe,
für welche
die Multicastübertragung
vorgesehen ist, registriert ist, wird eine Vervielfältigung
der Daten durchgeführt.
Die Anwendung garantiert, dass die Vervielfältigung möglichst nahe am Benutzer durchgeführt wird
und der Host ein Knoten ist, der die Benutzer bedient.
-
Ferner
offenbart die Erfindung ein System, das in der Lage ist, eine Multicastübertragung
für eine Multicastgruppe
innerhalb eines Telekommunikationsnetzes durchzuführen, das
einen Router und wenigstens einen Host, der Benutzer bedient, aufweist,
wobei sich zwischen dem Router und dem Host wenigstens ein Zwischenknoten
befindet. Das System enthält
wenigstens einen der Router nach Anspruch 17, wenigstens einen der
Zwischenknoten nach Anspruch 18 und wenigstens einen der Hosts nach
Anspruch 19, wobei in dem System das Verfahren nach Anspruch 1 durchgeführt wird.
-
Im
Folgenden wird die Transportebenen-Multicastgruppe, welche einem
Transportebenen-Multicastgruppen-Tunnel zugewiesen ist, mit TLMG
bezeichnet.
-
Im
Folgenden wird eine ausführliche
Beschreibung der Erfindung gegeben.
-
1:
UMTS-Architektur,
-
2:
Protokollorientierte Architektur von UMTS-Knoten,
-
3:
Beispiel eines Multicast-Zustellungsbaumes,
-
4:
Syntax des Source-Routing-basierten Paketes,
-
5:
Datenverwaltung in der RNC,
-
6:
Datenverwaltung im SGSN,
-
7:
Registrierungsprozedur und eine Prozedur zur Einrichtung einer TLMG
als eine Ausführungsform
der Erfindung.
-
Die
grundlegende Vorgehensweise gemäß der Erfindung
ist in der folgenden 2 offenbart, durch Anwendung
des TLMG-Verfahrens auf die Gn- und auf die Iu-PS-Schnittstelle.
-
Eine
protokollbezogene Darstellung ist in 2 angegeben. 2 zeigt
die Architektur eines Netzes, die in 3GPP standardisiert ist. Dies
darf jedoch nicht als eine Einschränkung für die Erfindung betrachtet
werden. 2 zeigt eine Mobilstation MS, welche
mit einem Zugangsnetz UTRAN kommuniziert. Die Iu-PS-Schnittstelle verbindet
UTRAN mit 3G-SGSN, welcher über
die Gn-Schnittstelle mit dem 3G-GGSN kommuniziert. 2 gibt
einen Überblick über die
verschiedenen Protokollstapel in den verschiedenen Knoten. Sie zeigt
eine Mobilstation MS mit einer Anwendungsschicht, Appl., am oberen Ende
des Protokollstapels, mit dem Internetprotokoll IP oder dem Punkt-zu-Punkt-Protokoll
PPP auf der Netzschicht. Die unteren Schichten sind als Schichten
L1 und L2 bezeichnet, da sie sich in den entsprechenden Knoten unterscheiden
können,
in Abhängigkeit
vom zugrunde liegenden physikalischen Netz. Die logische IP- oder
PPP-Verbindung von der Mobilstation wird im 3G-GGSN beendet. Zwischen
dem UTRAN, dem 3G-SGSN und dem 3G-GGSN wird das GTP-U-Protokoll zum Aufbauen
eines Tunnels zwischen diesen Knoten verwendet. Unter dem GTP-U
befindet sich eine IP-Schicht mit UDP als Protokoll für den Transport
der Nutzinformation.
-
Die
folgende Beschreibung konzentriert sich nur auf zwei IP-Schichten
in der paketvermittelten Domain, die mit IP PPP und UDP IP bezeichnet
sind. Infolge der Funktion des GGSN als ein Router und als eine
Schnittstelle zu den externen Netzen wurde die IP-Schicht unter der
Anwendungsschicht Appl. eingeführt.
Ferner wird aufgrund der Einschränkung, dass
ein IP-Netz zwischen
dem GGSN und dem SGSN und der RNC vorhanden ist, eine IP logische Verbindung
als ein Transportmittel eingeführt,
unter der GTP-U-Schicht.
-
Daher
sind in Bezug auf 2 zwei IP-Schichten vorhanden,
die im Folgenden als Anwendungs-IP- und Transport-IP-Schicht bezeichnet werden.
Die Anwendungs-IP-Schicht
befindet sich im Protokollstapel unmittelbar unter den Anwendungsprotokollen
und verbindet die Mobilstation und den 3G-GGSN. Die zweite IP-Schicht
ist die Transport-IP-Schicht, die für die Übertragung zwischen dem SGSN,
GGSN und UTRAN verwendet wird. Der Nutzlastverkehr wird über die
Gn und Iu-PS transportiert, eingekapselt in ein anwendungsspezifisches Tunneling-Protokoll,
das GPRS Tunnelling Protocol GTP. Es ist zu unterscheiden zwischen
dem GTP-C, welches ein Beispiel eines Transportschichtprotokolls
für Tunneling
ist, und dem GTP-U, welches ein Protokoll für den Transport von Benutzerdaten
auf einer höheren
Schicht als der Transportschicht ist. In GSM oder GPRS wird das
GTP-Protokoll nur
zwischen den SGSN und GGSN verwendet. GTP-Pakete verwenden UDP als
Transportprotokoll. Es gibt jedoch verschiedene Tunneling-Protokolle,
welche für den
Aufbau eines Tunnels verantwortlich sind. Das GTP ist lediglich
ein Beispiel und schränkt
die Erfindung nicht ein.
-
Die
Einführung
des Multicasts auf der Transportschicht in einem Punkt-zu-Punkt
orientierten Netz wird unter Bezugnahme auf 2 dargelegt.
-
Die
Idee besteht darin, die Multicast-Funktionalität von der Anwendungs-IP-Schicht
zur Transport-IP-Schicht einzuführen.
In 2 veranschaulicht die Ellipse über der Gi-Schnittstelle die
Multicast-Funktionalität
in einem weiteren Netz. Diese Funktionalität ist im Kernnetz zu der Transport-IP-Schicht
auf der Gn-Schnittstelle
und auch zu der Transportschicht auf der Iu-PS-Schnittstelle vorhanden.
Der Pfeil, der von der Multicast-Ellipse auf der Gi-Schnittstelle
zu der Multicast-Ellipse auf der GN- und der Iu-PS-Schnittstelle führt, zeigt
die Umleitung des Multicasts, der auf der Anwendungs-IP-Schicht
ausgeführt
wird, zur Transport-IP-Schicht. Die Verbindung zur Mobilstation kann
Unicast bleiben, oder es kann ein Multicast auf der Funkverbindung
durchgeführt
werden. Auch die logische Punkt-zu-Punkt-Verbindung auf der Anwendungs-IP-Schicht
bleibt bestehen.
-
Auf
der Iu-PS- und auf der Gn-Schnittstelle werden unterschiedliche
Signalisierungsprotokolle für
das Gruppen-Management verwendet. Auf der Iu-PS-Schnittstelle wird das erweiterte RRNAP-Protokoll,
das in 3GPP TS 25.413 V4.0.0 (2001-03) 3rd Generation
Partnership Project; Technical Specification Group Radio Access
Network; UTRAN Iu interface RANAP signalling (Ausgabe 4) beschrieben
ist, und auf der Gn-Schnittstelle
ein neues oder ein erweitertes GTP-C verwendet. Diese Protokolle
verwenden unterschiedliche Nachrichten, die Funktionalität bleibt
jedoch dieselbe. Es ist auch möglich,
ein neues Protokoll für
beide Schnittstellen zu spezifizieren.
-
Ein
Beispiel eines Multicast-Zustellungsbaumes ist in 3 abgebildet. 3 zeigt
einen Spannbaum zwischen dem GGSN und den entsprechenden RNCs. Der
Multicast-Zustellungsbaum zwischen den Randknoten besteht aus zwei
Spannbäumen,
einem zwischen dem GGSN und den SGSNs und einem zweiten zwischen
den SGSNs und den RNCs. Das heißt,
auf dem gesamten Weg zwischen den Randknoten ist Multicast vorgesehen.
Nur auf dem letzten Teil, das heißt, zwischen einem Host und
dem Benutzer auf der Funkschnittstelle, kann Unicast angewendet
werden.
-
Im
Folgenden wird die erweiterte Funktionalität des GGSN beschrieben. Diese
neue Funktionalität
des GGSN wird benötigt,
um die Erfindung auszuführen.
-
Um
di neuen Aufgaben zu erfüllen,
muss der GGSN als ein lokaler Multicast-Router agieren, welcher
in der Lage ist, von den Teilnehmern ankommende IGMP-Nachrichten
abzuwickeln. Die Teilnehmer registrieren sich für bestimmte Multicastgruppen in
dem GGSN, und der GGSN verfolgt die aktiven Multicastgruppen in
dem paketvermittelten Netz. Der GGSN beendet die IGMP- oder MLD-Nachrichten und
verbreitet die relevanten Informationen über IGMP oder MLD zu den benachbarten
Routern. Der GGSN handhabt auch die Multicast-Routing-Protokolle. Insofern
agiert der GGSN sehr ähnlich
wie ein standardmäßiger lokaler
Multicast-Router. Im Allgemeinen kann ein externer lokaler Multicast-Router
eines öffentlichen
landgestützten
Mobilfunknetzes (Public Land Mobile Network) PLMN anstelle des GGSN selbst
verwendet werden.
-
Außerdem ist
der GGSN für
die Schaffung einer Multicastgruppe im Rahmen des Kernnetzes verantwortlich,
das heißt,
zwischen den GGSN und SGSN und einem großen Teil des Funkzugangsnetzes,
das heißt,
zwischen den SGSNs und RNCs. Der GGSN informiert dann die entsprechenden
SGSNs und/oder RNCs, dass diese Mobilstationen haben, die für Multicastgruppen
registriert sind.
-
Auch
die SGSNs und RNCs müssen
durch eine neue Funktionalität
erweitert werden, um den Multicast-Datenstrom vom GGSN zu der Iu-PS-Schnittstelle
weiterzuleiten. Das heißt,
die Knoten verwalten die Beziehung zwischen den Adressen der ankommenden
und der abgehenden Multicastdaten. Zu diesem Zweck müssen die
Knoten Verknüpfungsmittel
zum Abbilden und Weiterleiten der ankommenden Multicastdaten zu
der abgehenden Schnittstelle aufweisen. Die Verknüpfungsmittel
können
mittels einer Tabelle realisiert werden, wie weiter unten beschrieben
ist. Ferner kann die Funktionalität des SGSN um Funktionen erweitert werden,
die benötigt
werden, um die Registrierung des Benutzers durchzuführen, falls
sich der Benutzer mittels einer IGMP-Nachricht bei dem SGSN und nicht
bei dem GGSN registriert.
-
Im
Folgenden wird eine Registrierungsprozedur eines Benutzers für eine Multicastgruppe
beschrieben.
-
Eine
Mobilstation, welche Multicast-Nachrichten empfangen möchte, muss
den entsprechenden GGSN über
ihren Wunsch informieren. Beim Empfang einer Multicastgruppen-Registrierungsnachricht
von einer Mobilstation informiert der GGSN die entsprechenden SGSNs
und/oder RNCs, dass diese Mobilstationen haben, die für Multicastgruppen registriert
sind. Der GGSN bestimmt die Entsprechung zwischen dem Multicastgruppen,
die durch eine Multicastgruppen-ID gekennzeichnet sind, und einer
TLMG-Adresse. Die TLMG-Adresse
ist in der Nachricht enthalten, die an die SGSNs und/oder an die
RNCs gesendet wird.
-
Bei
einer ersten Alternative, Alternative A, sendet der SGSN die TLMG-Registrierungsanforderung
von dem GGSN zu der entsprechenden RNC weiter. Bei der zweiten Alternative,
Alternative B, registriert der SGSN sich selbst für die TLMG
nur für die
erste Mobilstation, welche sich für die Multicastgruppe registriert,
und richtet an die RNC die Anforderung, sich für die TLMG zu registrieren.
In diesem Falle ist der SGSN die Wurzel des Multicast-Zustellungsbaumes,
der zwischen dem SGSN und den RNCs mittels der eingerichteten TLMGs
aufgebaut wird. Bei der dritten Alternative, Alternative C, wird der
SGSN auf Anforderung des Betreibers umgangen. Das heißt, der
Zwischenknoten, der SGSN, ist nicht an der Multicast-Übertragung
beteiligt. In Wirklichkeit wird bei allen drei Alternativen ein Multicastdaten-Zustellungsbaum
erzeugt. Dies kann entweder ein Multicast-Zustellungsbaum zwischen
dem GGSN und der RNC sein, oder zwei Multicast-Zustellungsbäume zwischen dem GGSN und den
SGSNs und dem SGSN und den RNCs. Natürlich kann eine RNC einen oder
mehrere Teilnehmer für
die Multicastgruppe haben. Vorzugsweise wird IP-Multicast verwendet,
um die Daten der RNC zuzustellen, woraufhin die RNC die Pakete vervielfältigt und
diese zu den betreffenden Mobilstationen weiterleitet, falls mehr als
ein Benutzer vorhanden ist. In der weiteren Beschreibung werden
die drei Alternativen ausführlicher beschrieben.
-
Im
Folgenden wird das quellenbasierte Multicast-Routing ausführlicher
beschrieben.
-
Das
Source-Routing-Multicast ist ein Mechanismus, um die Prozeduren
zur Einrichtung von Multicast-Bäumen
zu zwingen, bestimmten Knoten/Router zu berücksichtigen. Es ist ein allgemeiner
Mechanismus, welcher auch auf andere Szenarien angewendet werden
kann.
-
Mit
Source-Routing-Multicast können
Netzbetreiber erzwingen, dass der Multicast-Zustellungsbaum gewisse
Router und Knoten zum Beispiel für Zwecke
der Vergebührung
oder des Netzmanagements enthält,
welche ohne die Verwendung von Source-Routing-Multicast ausgeschlossen
sein können.
Für das
Iu-PS Multicast wird Source-Routing-Multicast verwendet, um zu erzwingen,
dass der SGSN in den Multicast-Zustellungspfad
zwischen der RNC und dem GGSN einbezogen wird. Dies zwingt den Multicast-Verkehr
für Mobilfunkteilnehmer,
den entsprechenden SGSN zu durchlaufen.
-
Source-Routing
ist eine der IP-Optionen sowohl in IPv4 als auch in IPv6. Es sind
zwei Source-Routing-Optionen definiert, das strikte Source-Routing
(Strict Source Routing) und das lose Source-Routing (Loose Source
Routing).
-
Das
strikte Source-Routing legt den kompletten Pfad von der Quelle bis
zum Ziel als eine Folge von IP-Adressen fest. Ein Datenpaket folgt
dieser exakten Route. Das lose Source-Routing erfordert, dass das
Paket die Liste festgelegter Router durchläuft, und in der festgelegten
Reihenfolge, doch es ist zulässig,
unterwegs noch andere Router zu durchlaufen.
-
Die
Syntax der Source-Routing-Optionen wird unter Bezugnahme auf 4 beschrieben.
Beide Source-Routing-Optionen
haben dieselbe Syntax.
-
Die
Routendaten enthalten eine Liste von IP-Zieladressen, durch welche das Paket
geleitet werden muss. In der Liste ist ein IP-Header-Ziel-Feld enthalten,
welches immer die nächste
Adresse angibt, zu welcher das Paket geroutet werden muss. Wenn
das betreffende Ziel erreicht ist, wird die Option geprüft. Die
lose Quelle- und Routenaufzeichnungs-Option sieht ein Mittel vor,
damit eine Quelle eines Datenpaketes Routing-Informationen liefert, die
von den Routern beim Weiterleiten des Datenpaketes zum Ziel zu verwenden
sind, und um die Routeninformationen aufzuzeichnen. Das Zeiger-Feld "Ptr" enthält einen
Index oder einen Oktett-Zähler, der
am Beginn der Option startet. Falls er größer als die Länge der
Option "Länge" ist, hat das Paket
sein Endziel erreicht. Andernfalls, wenn die Adresse in dem IP-Zieladressen-Feld
erreicht worden ist und der Zeiger nicht größer als die Länge ist,
ersetzt die nächste
Zieladresse in der Source-Route die Adresse in dem IP-Zieladressen-Feld,
und die aufgezeichnete Routen-Adresse ersetzt die soeben verwendete Routen-Adresse, und der
Zeiger wird erhöht.
Diese Option ist eine lose Source-Route, da der Router oder Host
eine beliebige Route mit einer beliebigen Anzahl anderer Zwischenrouter
verwenden darf, um die nächste
Adresse in der Route zu erreichen. Im Falle von striktem Source-Routing
muss dies die Adresse eines benachbarten Routers sein; im Falle von
losem Source-Routing gibt es keine Einschränkung. Die lokalen Router müssen dann
die Adresse in der Liste ersetzen, und der Zeiger Ptr wird inkrementiert.
Das Feld "Typ" enthält die Information,
ob es sich um striktes oder loses quellenbasiertes Routing handelt.
Striktes Source-Routing ist losem Source-Routing sehr ähnlich.
Anstatt dass Routern oder Hosts gestattet wird, eine beliebige Route
mit einer beliebigen Anzahl von Zwischenroutern zu verwenden, um
die nächste
Adresse in der Route zu erreichen, müssen diese das Datenpaket direkt
zu der nächsten
Adresse in der Source-Route senden, und zwar nur über das
direkt verbundene Netz, das in der nächsten Adresse angegeben ist,
um den nächsten Router
oder Host zu erreichen, der in der Route angegeben ist.
-
Das
lose Source-Routing und das strikte Source-Routing können angewendet
werden, um zu garantieren, dass ein Knoten wie etwa ein SGSN Teil eines
Multicast-Zustellungsbaumes
ist. Der GGSN verwendet die Adresse des SGSN als die Ziel-IP-Adresse
und setzt die Adresse der RNC in das Source-Routing-Optionsfeld
ein. Der SGSN ersetzt dann die IP-Ziel-Adresse durch die RNC-IP-Adresse, welche im
Source-Routing-Optionsfeld enthalten ist. Optional entfernt der
SGSN das Source-Routing-Optionsfeld
aus dem IP-Paket-Header und aktualisiert andere Felder in dem Paket-Header
entsprechend.
-
Um
die Alternative A durchzuführen,
meldet die RNC ihre TLMG-Mitgliedschaft an den GGSN. Dies wird nur
für den
ersten sich registrierenden Benutzer durchgeführt. Um sicherzustellen, dass
der SGSN Teil des Baumes ist, muss die Mitgliedschaftsbericht-Nachricht
den SGSN auf ihrem Weg von der RNC zum GGSN durchlaufen. Dies kann
mittels Konfiguration des Netzes erreicht werden, oder indem man
die Multicast-Routing-Protokolle den Extension-Header des losen
Source-Routing betrachten lässt,
wenn die Mitgliedschaftsbericht-Nachrichten wie oben beschrieben
zwischen den Multicast-Routern weitergesendet werden. Der SGSN routet
die Informationen, entweder die Signalisierungsinformationen, die
zwischen dem GGSN und der RNC ausgetauscht werden, oder die Multicastdaten,
die von dem GGSN ankommen. Der SGSN agiert als ein Nachbarschafts-Router
für die
RNC, mit der zusätzlichen Verarbeitung,
die für
die Erfindung erforderlich ist. Sowohl SGSN als auch RNC können von
dem GGSN aufgefordert werden, der Multicastgruppe beizutreten. Durch
Source-Routing wird sichergestellt, dass alle Pakete zuerst die
SGSNs durchlaufen.
-
Bei
der Alternative B meldet der SGSN seine TLMG-Mitgliedschaft an den GGSN und übermittelt an
die RNC die Anforderung, ihre Mitgliedschaft an den SGSN zu melden.
Logisch kann der SGSN sowohl als ein Blatt einer TLMG als auch als
die Wurzel einer anderen TLMG angesehen werden, falls zwischen dem
GGSN und den RNCs zwei TLMGs eingerichtet sind. Daher ist automatisch
sichergestellt, dass der Multicast-Verkehr zu den RNCs den SGSN durchläuft.
-
Bei
der Alternative C kann der SGSN als eine Funktion im Netz umgangen
werden, wenn der Betreiber sich hierfür entscheidet. In diesem Falle
ist der GGSN die Wurzel des Multicast-Baumes, und die RNCs sind
die Blätter.
In Abhängigkeit
von der Implementierung ist es möglich,
dass der Multicast-Verkehr noch immer den SGSN durchläuft, dort
jedoch nicht weiter verarbeitet wird. Dies erfordert eine Management-Schnittstelle,
durch welche der Betreiber steuern kann, ob diese Alternative gewählt wird
oder nicht. Diese Schnittstelle könnte eine zentrale Multicast-Datenbank
sein, in der alle Multicastgruppen klassifiziert sind.
-
In
Abhängigkeit
von der Alternative speichert der SGSN Informationen darüber, wie
der von dem GGSN kommende Multicast-Datenstrom zu verarbeiten ist.
Das IP-Multicast
wird verwendet, um die Daten den RNCs zuzustellen, eventuell über die SGSNs,
woraufhin die RNC die Pakete vervielfältigt und diese zu den betreffenden
Benutzern weiterleitet, oder die RNC verwendet den Multicast-Funkträger, um
die Daten zu einer Gruppe von Benutzern weiterzuleiten.
-
Im
Folgenden wird eine bevorzugte Ausführungsform für eine Multicast-Zustellungsprozedur
beschrieben.
-
Für die Multicast-Datenzustellung
werden die Multicast-Pakete
der Anwendung mit einer Multicast-Kennung adressiert, welche innerhalb
der Kernnetz-Domain gültig
ist, der so genannten Multicast-Datenstrom-Kennung oder MC-ID. Es
gibt mehrere Alternativen für
die Zuweisung de MC-ID. Die MC-ID kann zum Beispiel die TLMG-Adresse
sein. Dies kann angewendet werden, wenn eine eineindeutige Beziehung
zwischen der Multicastgruppe, für welche
der Benutzer sich registriert, und der TLMG in dem betrachteten
Punkt-zu-Punkt orientierten Telekommunikationsnetz definiert ist
und wenn kein zusätzliches
Encapsulation-Protokoll verwendet wird, welches zu Schwierigkeiten
bei der Paketidentifizierung führen
kann. Ferner kann die MC-ID die tatsächliche Multicast-Adresse der
Multicastgruppe sein, welche dieselbe sein kann wie die, die im
weiteren Netz verwendet wird und aus der IGMP-Nachricht empfangen
wird, die von dem Teilnehmer während der
Registrierung gesendet wird. Falls das GTP-U verwendet wird, um
die Multicast-Pakete einzukapseln und über die Iu-PS-Schnittstelle weiterzuleiten, kann
die Kennung dieses Protokolls, die Tunneling-Kennung TID oder die
TEID als die Multicast-Datenstrom-Kennung verwendet werden. Die
empfangende Seite des GTP-U-Tunnels weist die TEID zu. Im Falle
der Iu-PS-Schnittstelle ist es die RNC. Die Multicast-Zustellung
wird auf einer höheren
Ebene durchgeführt
als im Falle von TLMGs. Die Protokollschichten werden unter Bezugnahme
auf 2 beschrieben. Mit den GTP-U-Tunneln als ein Beispiel eines
Transportebenen-Multicastgruppen-Tunnels werden Zustellungstunnel
zwischen den Knoten eingerichtet, und auf jedem Tunnel wird eine
Multicast-Nachricht übermittelt.
Bei einer Ausführungsform
der Erfindung ist vorgesehen, dass der GTP-U-Tunnel für Multicastübertragung
auf der Gn-Schnittstelle und ein TLMG Multicast-Zustellungsbaum
auf der Iu-PS-Schnittstelle
vorhanden ist, wobei gemäß dem Standard-Protokollstapel natürlich ein
GTP-U-Protokoll auch über
der TLMG verfügbar ist,
es wird nicht für
Multicastübertragung
verwendet.
-
Auf
der Verbindung zwischen GGSN und SGSN und auch zwischen SGSN und
RNC können verschiedene
Typen vom TLMGs verwendet werden. Zum Beispiel kann eine TLMG nach
Bedarf eingerichtet werden, die so genannte dynamische TLMG. Das
heißt,
wenn ein Benutzer sich für
eine Multicastgruppe registriert, so wird eine dynamische TLMG eingerichtet,
falls der Benutzer der Erste ist, der sich für die betreffende Multicastgruppe
registriert. Falls eine TLMG für
eine bestimmte Multicastgruppe, für welche sich ein Benutzer
registrieren möchte,
bereits existiert, so wird der Benutzer nur zu der entsprechenden
TLMG hinzugefügt.
-
Bei
einer anderen Lösung
werden die TLMGs voreingerichtet. Um die Einrichtungszeit zu sparen, werden
die TLMGs entsprechend den bekannten Multicastgruppen und den bekannten
Konfigurationsparametern voreingerichtet. Die Konfigurationsparameter
können
zum Beispiel geographische Regionen oder Dienstgüteanforderungen sein. Ein Multicast-Datenstrom
wird im Hinblick auf die Erfüllung
der Konfigurationsparameter geprüft.
Entsprechend dem Ergebnis wird der Multicast-Datenstrom der entsprechenden
TLMG zugewiesen.
-
Aufgrund
der verschiedenen Alternativen beim Adressieren und Kennzeichnen
von Multicast-Datenströmen
müssen
die Tabellen in den SGSN und RNC in Abhängigkeit von der verwendeten
Multicast-Datenstrom-Kennung strukturiert werden. Dies wird unter
Bezugnahme auf die 5 und 6 beschrieben.
-
Die
verschiedenen Alternativen in Abhängigkeit von der Multicast-Datenstrom-Kennung
und dem Verfahren für
die Multicastübertragung
auf der Iu-Schnittstelle werden im Folgenden unter Bezugnahme auf 5 beschrieben.
Es ist anzumerken, dass 5 eine Ausführungsform der vorliegenden Erfindung
offenbart, so dass das Vorhandensein der Multicast-Datenstrom-Kennung
in der Tabelle optional und von der Implementierung abhängig ist.
Ferner werden nicht alle möglichen
Abbildungen durch die 5 erfasst.
-
Innerhalb
jeder RNC muss eine Verknüpfung mit
der Abbildung für
ankommenden Multicast-Verkehr von der Iu-PS-Schnittstelle, welcher die Multicast-Datenstrom-Kennung hat, auf
den tatsächlich verwendeten
Funkträger-
oder Radio Access Bearer Kontext (RAB-Kontext) aufrechterhalten werden. Für diesen
Zweck wird eine neue Multicastgruppen-Kennung, welche alle Mitglieder
derselben Multicastgruppe eindeutig kennzeichnet, oder nur ein Multicast-Flag
zu dem RAB- Kontext
hinzugefügt.
Die Nummer des RAB-Kontextes wird in dem RNC-Kontext gespeichert,
und es wird ein RNC-Kontext
pro mobiles Endgerät
unterhalten.
-
5 enthält vier
Alternativen, die als Option 1 bis Option 4 bezeichnet sind. Option
1 verwaltet Multicast-Datenströme, die
mittels TLMG gesendet werden. Bei Option 1 ist dies in der ersten
Spalte dargestellt, die mit TLMG bezeichnet ist und zwei TLMGs enthält, tlmg1
und tlmg2. Die tlmg1 verwaltet zwei Mobilstationen, welche mittels
der internationalen Mobilfunkteilnehmerkennung IMSI gekennzeichnet
sind, imsi-1 und imsi-2. Diese ist in der dritten Spalte enthalten,
die mit MS ID bezeichnet ist. Diese Spalte ist jedoch optional,
da jedes Teilnehmergerät mittels
des zugewiesenen Funkträgers
identifiziert werden kann. Die Funkträger-Kennungen rab-ids sind
in der zweiten Spalte RAB ID aufgelistet. Zum Beispiel steht die
zweite TLMG, tlmg2, zu drei Funkträgern in Beziehung, rab-id1,
rab-id4 und rab-id5.
-
Bei
Option 2 ist die Möglichkeit
des Multiplexierens mehrerer Multicast-Sitzungen auf einer TLMG
dargestellt. Zwei Multicastgruppen, mc1 und mc2, werden auf einer
TLMG multiplexiert. Die MC-Addr wird verwendet, um die Multicast-Datenströme zu kennzeichnen,
die über
eine TLMG übertragen
werden. Die verwendete TLMG kann entweder dynamisch oder vorkonfiguriert
sein, wie weiter unten beschrieben wird.
-
Der
Unterschied zwischen den Optionen 2 und 3 ist die Kennung des Multicast-Datenstroms
im Kernnetz. Bei Option 2 ist dies die Kennung der Multicastgruppe,
für welche
ein Benutzer sich registriert, MC-Addr. Bei Option 3 ist dies die
Kennung des GTP-Tunnels GTP-ID, welche während der PDP-Kontext-Aktivierung
empfangen wird.
-
Die
PDP-Kontext-Aktivierung ist wie das Wählen zu dem externen IP-Netz.
Zu diesem Zweck wird eine Mobilfunkteilnehmerkennung mit einer IP-Adresse
verknüpft.
Während
der PDP-Kontext-Aktivierung wird ein Tunnel mit einer Kennung, im
Folgenden mit TEID bezeichnet, zwischen dem SGSN und GGSN für den PDP-Kontext erzeugt.
Falls das GTP während
der PDP-Kontext-Aktivierung
verwendet wird, wird ein GTP-Tunnel eingerichtet. Während dieser
Prozedur findet auch eine Dienstgüte-(QoS-)Verhandlung zwischen
der MS und dem SGSN/GGSN statt.
-
Die
Option 4 offenbart eine Verknüpfung, welche
die GTP-ID und eine nachfolgende Multicast Radio Bearer (Multicast-Funkträger) MC
RAB ID zueinander in Beziehung setzt. Ein Multicast Radio Access
Bearer ist ein nachfolgender Punkt-zu-Mehrpunkt Funkträger. Eine
Liste der Mobilstationen, welche von dem Multicast Radio Bearer
versorgt werden, kann separat geführt werden.
-
Je
nach der gewählten
Option vervielfältigt die
RNC entweder die empfangenen Multicast-Pakete von der Iu-PS-Schnittstelle
(bei den Optionen 1 bis 3), oder die Daten werden mittels des Multicast
Radio Bearers per Multicast übertragen
(bei Option 4).
-
Im
Folgenden wird die Datenverwaltung, die im SGSN erfolgt, unter Bezugnahme
auf 6 beschrieben.
-
Innerhalb
des SGSN wird eine Tabelle, die einer Routing-Tabelle ähnlich ist,
unterhalten. Die Multicast-Datenstrom-Kennung von den Gn-Schnittstellen
muss auf die Kennung an der Iu-PS-Schnittstelle abgebildet werden.
Da ein SGSN mehrere RNCs bedienen kann, kann die Tabelle mehrere
Multicast-Datenstrom-Kennungen
für die
Iu-PS-Schnittstelle enthalten. Im Allgemeinen ist es die Aufgabe des
SGSN, die Kennung, die an der Gn- und an der Iu-PS-Schnittstelle
verwendet wird, und die Beziehung zwischen den Kennungen zu verwalten.
Außerdem
kann der SGSN weitere Parameter verwalten, welche von der gewählten Kennung,
der Alternative der Multicast-Zustellung und der Art der TLMG abhängen.
-
6 zeigt
vier Beispiele für
die Einträge
in dem SGSN.
-
In
der ersten Tabelle, SGSN Tabelle 1, wird eine tlmg-gn1, welche die auf
der Gn-Schnittstelle verwendete TLMG ist, auf zwei TLMGs auf der Iu-PS-Schnittstelle,
tlmg-iu1 und tlmg-iu2, abgebildet. Der Eintrag tlmg-iu bezieht sich
auf den zu verwendenden Transportträger. Da bei manchen Alternativen
der SGSN die Wurzel des Multicast-Baumes für die Iu-PS-Schnittstelle ist,
kann eine Vervielfältigung
von Paketen von der TLMG auf der Gn zu mehreren TLMG-Iu erfolgen.
Eine andere Option ist, dass verschiedene tlmg-iu Gruppen für verschiedene
Multicastgruppen existieren, wobei die besagten Gruppen unterschiedliche
QoS-Anforderungen aufweisen. Dies ist insbesondere im Falle von
voreingerichteten und vorkonfigurierten TLMGs in Betracht zu ziehen. In
der zweiten und in der dritten Tabelle, SGSN Tabelle 2 und 3, wird
zusätzlich
die Multicast-Datenstrom-Kennung für die Iu-PS-Schnittstelle in
der Spalte MC-ID-iu verwaltet, um zwischen den verschiedenen Multicastgruppen
zu unterscheiden. Dies kann zum Beispiel die Multicast-Adresse mc-addr oder
die Tunnelkennung teid sein, wie oben beschrieben. Die zusätzliche
Multicast-Datenstrom-Kennung kann verwendet werden, um zwischen
den verschiedenen QoS-Klassen zu unterscheiden, falls solche Klassen
definiert sind und die Vorkonfiguration in Bezug auf die definierten
Klassen vorgesehen ist. In der vierten Tabelle, SGSN Tabelle 4,
ist der Fall dargestellt, in welchem keine TLMGs auf der Gn-Schnittstelle
verfügbar
sind. Die Multicastübertragung
auf der Gn-Schnittstelle wird auf der GTP-U Protokollschicht durchgeführt. Daher
ist die Multicast-Datenstrom-Kennung die teid-gn auf der Gn-Schnittstelle. In
diesem Falle sind zwei Tunnel vorhanden, teid-gn1 und teid-gn2.
Der teid-gn1 leitet den Verkehr einer Multicastgruppe weiter. In
dem SGSN wird der Verkehr vervielfältigt und auf drei bestehenden
GTP-U Tunneln weitergeleitet, die in der zweiten Spalte mit teid1
bis teid3 bezeichnet sind. Auf der Iu-Schnittstelle wird die Multicastübertragung
mittels der TLMGs durchgeführt,
die in der dritten Spalte TLMG-iu angegeben sind. Bei dieser Ausführungsform
werden fünf verschiedene
TLMGs verwendet, von denen jede mit anderen QoS-Eigenschaften konfiguriert
ist.
-
Im
Falle der Alternative, in welcher dieselben TLMGs auf der Gn-Schnittstelle
und auf der Iu-PS-Schnittstelle
verwendet werden, kann der Eintrag von TLMG-iu optional werden.
-
Im
Folgenden wird eine Ausführungsform
einer Signalisierungssequenz der vorliegenden Erfindung für die Registrierung
von Multicastgruppen und die Einrichtung von TLMG für die Alternativen
A, B und C beschrieben. Das heißt,
es wird ein TLMG Multicast-Zustellungsbaum
zwischen dem GGSN und den SGSNs eingerichtet und ein zweiter zwischen den
SGSN und den RNCs. Die Beschreibung stützt sich auf 7. 7 zeigt
einen zeitlichen Ablauf der gesendeten Nachrichten zwischen einer
Mobilstation MS, einem SGSN und einem GGSN. Ein Pfeil bezeichnet
die gesendete Nachricht. Über
einem Pfeil ist der Name der Nachricht angegeben, und unter dem
Pfeil sind die Hauptparameter der entsprechenden Nachricht aufgelistet.
Die Felder auf der rechten Seite geben die Aktionen an, welche in
einem Knoten nach dem Empfang einer Nachricht ausgeführt werden.
-
Im
ersten Schritt wird der PDP-Kontext wie oben beschrieben eingerichtet.
Um sich für
eine Multicastgruppe zu registrieren, ist es die Aufgabe der Mobilstation
MS, ihn einzuleiten. Im Unterschied zu lokalen Multicast-Routern,
die in IGMP spezifiziert sind, sendet der GGSN keine Mitgliedschaftsabfragen
(Membership Queries) an alle Mobilstationen mit einem aktiven PDP-Kontext
aus. Dies würde
nur die knappen Funkressourcen verschwenden. Stattdessen leiten
die Mobilstationen MSs das Beitreten zu einer Multicastgruppe selbst
ein. Ohne dass sie durch eine Mitgliedschaftsabfrage-Nachricht,
zum Beispiel eine IGMP-Abfragenachricht, dazu aufgefordert werden,
melden die MSs ihre Mitgliedschaft mittels einer Nachricht IGMP
Membership Report (IGMP Mitgliedschaftsbericht) mit der Multicastgruppen-Adresse MC
Addr als Parameter. In diesem Falle beendet der GGSN das IGMP-Protokoll
und speichert Informationen über
die Multicastgruppen-Mitgliedschaft
der MS. Im nächsten
Schritt wird die MC Group Membership Verification (Multicastgruppen-Mitgliedschafts-Überprüfung) im
GGSN durchgeführt,
um zu bestimmen, ob der Mobilstation gestattet ist, sich für die Multicastgruppe
zu registrieren. Es ist zum Beispiel möglich, dass Sicherheitsprüfungen der
Mobilstation nicht erlauben, der Multicastgruppe beizutreten, oder
dass der Betreiber die Registrierung der Multicastgruppe aufgrund
der Merkmale der Gruppe nicht gestattet, oder dass die maximal zulässige Anzahl
von Mitgliedern der Multicastgruppe erreicht worden ist. Es können auch
verschiedene weitere Prüfungen
im GGSN durchgeführt
werden.
-
Falls
die Multicastgruppe, die im IGMP Membership Report (IGMP Mitgliedschaftsbericht)
angegeben ist, in dem GGSN noch nicht existiert, kann der GGSN für diese
im Falle einer dynamischen TLMG einen neuen Eintrag erzeugen. In
diesem Falle erzeugt der GGSN eine TLMG auf der Transport-IP-Schicht
für die
auf der Anwendungs-IP-Ebene ankommenden Multicastdaten. Zu diesem
Zweck weist der GGSN eine Multicast-Adresse aus dem Adressraum des
Kernnetzes zu. Im Folgenden wird sie die Multicast-TP-Adresse der
TLMG oder auch TLMG-MC-Adresse
oder einfach TLMG-Adresse genannt. Um die richtige TLMG zu erzeugen,
kann der GGSN die verhandelten Dienstgüte- (QoS-) Anforderungen aus
dem PDP-Kontext berücksichtigen.
Es ist auch möglich,
nur die TLMG-Adresse dem SGSN zur Verfügung zu stellen, wie unten
beschrieben, und die logische TLMG in dem GGSN erst bei Empfang
eines positiven Ergebnisses von dem SGSN zu erzeugen.
-
Der
GGSN informiert in diesem Falle den entsprechenden SGSN, dass er
Mobilstationen hat, die für
eine Multicastgruppe registriert sind, mittels zum Beispiel des
erweiterten GTP-Protokolls. Es kann eine neue GTP-Nachricht, SGSN Membership Report
Request (SGSN Mitgliedschaftsbericht-Anforderung) verwendet werden.
Es ist auch möglich,
für diesen
Zweck eine vorhandene Nachricht zu verwenden, zum Beispiel eine
erweiterte Packet Data Unit PDU Benachrichtigung auf der UDP-Verbindung. Es ist
auch möglich,
dass der SGSN auf dem Weg von der Mobilstation zum GGSN durchlaufen
wird, oder dass die IGMP-Nachricht im SGSN endet und es daher nicht
erforderlich ist, diese Nachricht zu senden.
-
Für den Multicastgruppen-Verkehr
ignoriert der GGSN den Tunnel, welcher bereits für die betreffende MS von dem
SGSN während
der PDP-Kontert-Aktivierung eingerichtet worden ist, und verwendet
stattdessen TLMGs, welche einen Multirast-Zustellungsbaum bilden.
Diese Art von Multirast-Zustellungsbaum wird in der weiteren Beschreibung
ein TLMG-Zustellungsbaum genannt.
-
Nachdem
der SGSN die Nachricht SGSN Membership Report Request empfangen
hat, führt
er die Multicast Group MC Membership Verification (Multicastgruppen-Mitgliedschafts-Überprüfung) durch.
Insbesondere bedeutet das, dass der SGSN eine Anmeldungsprüfung oder
Gebührenkontenprüfung durchführen kann,
um zu bestimmen, ob es der Mobilstation gestattet ist, sich für irgendeine
oder für diese
spezielle Multicastgruppe zu registrieren.
-
In
Abhängigkeit
von der gewählten
Alternative sendet der SGSN entweder die Nachrichten transparent
zwischen dem GGSN und der RNC weiter, oder er beendet Nachrichten
von dem einen Knoten und sendet ähnliche
neue Nachrichten zu dem anderen Knoten. Das heißt, beim Empfang einer Nachricht IGMP
Membership Report (IGMP Mitgliedschaftsbericht) von einem mobilen
Client sendet der GGSN entweder einen SGSN Membership Report (SGSN Mitgliedschaftsbericht)
an den SGSN, wie in 7 dargestellt, woraufhin der
SGSN die Nachricht weitersendet, indem er zum Beispiel eine dedizierte Nachricht
RNC Membership Report (RNC Mitgliedschaftsbericht), erster Pfeil
in Schritt 1, mit verschiedenen Mobil-Client-Kennungsparametern
an die RNC sendet, oder der GGSN sendet einen RNC Membership Report
direkt an die entsprechende RNC. Der RNC Membership Report ist nur
ein fiktiver Name für
eine Nachricht, welcher eingeführt
wird, um die Klarheit der Beschreibung zu garantieren. Diese Nachricht
ist in einem entsprechenden Signalisierungsprotokoll zu übersetzen.
Zum Beispiel ist dies auf der Iu-PS-Schnittstelle das RANAP-Protokoll, dessen
Signalisierungsnachrichten weiter unten beschrieben werden.
-
Optional
fügt der
GGSN die Adresse des SGSN ein, zum Beispiel die IP-Adresse, damit
sie für das
quellenbasierte Multicast-Routing verwendet werden kann, wenn der
Multicast-Zustellungsbaum eingerichtet wird. Der SGSN fordert den
Mitgliedschaftsbericht von der RNC erst an, wenn sämtliche Analysen
in dem SGSN erfolgreich durchlaufen worden sind. Optional kann die
RNC einige Prüfungen beim
Empfang des Membership Report Requests von dem SGSN oder dem GGSN
durchführen,
wie etwa die Verfügbarkeit
eines Multicast-Funkträgers, von
Vervielfältigungs-Ressourcen
usw. Dies kann eine Nachricht RNC Membership Report Result (RNC
Mitgliedschaftsbericht-Ergebnis) zur Folge haben, die zum SGSN oder
GGSN zurückgesendet wird.
-
Das
Ergebnis der in der RNC durchgeführten Überprüfung kann
zu dem SGSN oder dem GGSN in einer Nachricht RNC Membership Report
Result zurückgesendet
werden, zweiter Pfeil in Schritt 2. Das Ergebnis der im SGSN durchgeführten Überprüfung ist
in der Nachricht SGSN Membership Report Result (SGSN RNC Mitgliedschaftsbericht-Ergebnis)
enthalten.
-
Ferner
speichernder SGSN und die RNC dann die Beziehung zwischen den TLMG
auf den verschiedenen Schnittstellen, Gn, Iu-PS und Funkschnittstelle.
-
Bei
Empfang der Nachricht SGSN Membership Report Result sendet der GGSN
eine Nachricht IGMP Membership Report Accept (Mitgliedschaftsbericht-Annahme)
oder Membership Report Reject (Mitgliedschaftsbericht-Zurückweisung) zurück, die möglicherweise
eine Angabe des Grundes enthält,
in Abhängigkeit
vom Ergebnis der Überprüfung. Dies
ist eine neue Nachricht, welche in IGMP nicht spezifiziert ist.
Es ist auch realisierbar, eine existierende Fehlernachricht nur
im Falle eines negativen Ergebnisses zu senden. Andernfalls, wenn
das Ergebnis des Mitgliedschaftsberichtes positiv ist, wird keine
Informationsnachricht zurückgesendet.
-
Jedes
Mal, wenn sich eine erste MS für
eine Multicastgruppe registriert, muss in Abhängigkeit von der gewählten Alternative
der SGSN selbst sich für die
TLMG registrieren und zu dem TLMG Multicast-Zustellungsbaum hinzugefügt werden.
In diesem Falle sendet der SGSN eine Nachricht IGMP Membership Report
an den GGSN. Falls die RNC zu einem Multicast-Zustellungsbaum hinzugefügt werden
muss, der sich zwischen dem SGSN und der RNC aufspannt, sendet die
RNC eine Nachricht IGMP Membership Report an den SGSN, Schritt 2.
-
Das
heißt,
die RNC kann sich für
die TLMG mit dem SGSN oder mit dem GGSN als Wurzel registrieren.
Die TLMG besteht entweder aus einem einzigen Multicast-Zustellungsbaum zwischen
dem GGSN und der RNC, oder es wird eine TLMG erzeugt, die aus einem
Teilbaum zwischen der RNC und dem SGSN, das heißt, mit dem SGSN als Wurzel und
der RNC als einem Blatt, und einem Teilbaum zwischen dem SGSN und
GGSN mit dem GGSN als Wurzel und der RNC als Blatt besteht. Optional
können
im Falle von zwei Teilbäumen
verschiedene Typen von TLMGs verwendet werden, zum Beispiel ist die
TLMG zwischen dem SGSN und dem GGSN vorkonfiguriert, während die
TLMG zwischen der RNC und dem GGSN auf Anforderung eingerichtet
wird. Es ist auch möglich,
einen Multicast-Zustellungsbaum zu haben, der mittels TLMGs entweder
zwischen dem GGSN und den SGSNs oder zwischen den SGSNs und den
RNCs zustellt. In diesem Fall verwendet der andere Teil des Übertragungspfades das
GTP-U mit der TEID zur Durchführung
des Multicasts auf der höheren
Schicht ohne das Multicast auf der Transportschicht. Der Nachteil
dieser Lösung
ist, dass die Vervielfältigung
der Multicast-Datenpakete in dem Wurzelknoten durchgeführt wird
und nicht in einem Router, der sich so nahe wie möglich am
Empfänger
des Multicast-Datenpaketes
befindet.
-
Für die Signalisierung
zwischen dem SGSN und der RNC kann das RANAP-Protokoll als ein Beispiel
für die
Durchführung
der Übertragung
des RNC Membership Reports und des RNC Membership Report Results
verwendet werden. Diese Nachrichten werden in die so genannten RAB-Nachrichten übersetzt,
welche Nachrichten für
die Einrichtung der Radio Access Bearers (Funkzugangskanäle) sind,
die so genannten "RAB
Zuweisungsprozeduren".
Das heißt,
der RNC Membership Report und das RNC Membership Report Result werden
mittels der Nachrichten RAB Assignment Request (RAB Zuweisungsanforderung),
RAB Assignment Response (RAB Zuweisungsantwort) ausgeführt.
-
Um
Multicast zu unterstützen,
muss das RANAP-Protokoll erweitert werden. Zum Beispiel müssen die
Nachrichten RAB Assignment Request, RAB Assignment Response und
eine Freigabenachricht um neue Parameter erweitert werden, wie zum
Beispiel ein Flag zum Anzeigen eines Multicast-Verkehrs, die TLMG-Adresse
oder die TEID.
-
Um
einen neuen Radio Access Bearer einzurichten, sendet der SGSN die
Nachricht RAB Assignment Request an die RNC. Die Antwort auf diese Nachricht
ist die Nachricht RAB Assignment Response. Entweder wird diese Nachricht
um die benötigten
Multicast-Parameter erweitert, oder es muss eine neue Nachricht
spezifiziert werden. Die Nachricht muss jedoch einen Verkehrstyp-Indikator
für Multicast
enthalten. Dies kann entweder mit einem Flag erfolgen, oder durch
Erweitern eines existierenden Enumerators um das Multicast, zum
Beispiel des Verkehrsklassen-Enumerators, welcher bereits die Klassen
Conversational, Interactive, Streaming und Background enthält.
-
In
Abhängigkeit
von der Multicast-Datenstrom-Kennung, welche auf der Iu-PS-Schnittstelle verwendet
wird, werden die folgenden Mechanismen unter Verwendung des RANAP-Protokolls
angewendet.
-
Falls
dynamische TLMG auf der Iu-PS-Schnittstelle verwendet werden, kann
entweder der SGSN oder die RNC die TLMG-Adresse zuweisen. Falls
der SGSN eine TLMG-Adresse
aus dem Adressraum des Kernnetzes zuweist, ist die TLMG-Adresse
in der erweiterten Nachricht RAB Assignment Request unbedingt als
Parameter erforderlich. Falls die RNC eine TLMG-Adresse zuweist,
ist sie Teil einer erweiterten Nachricht RAB Assignment Response.
-
In
beiden Fällen
aktualisieren die RNC und der SGSN ihre Tabellen dementsprechend.
-
Falls
vorkonfigurierte TLMGs auf der Iu-PS-Schnittstelle verwendet werden, treten
alle RNCs den vorkonfigurierten TLMGs bei. Falls vorkonfigurierte
TLMGs verwendet werden, wählt
entweder der SGSN die TLMG im Hinblick auf das geforderte Dienstgüte-Level,
oder die RNC wählt
die TLMG im Hinblick auf das geforderte Dienstgüte-Level und die Funkbedingungen.
Falls die TLMG von dem SGSN gewählt
wird, ist die TLMG-Adresse
Teil der Nachricht RAB Assignment Request. Falls die TLMG von der
RNC gewählt
wird, ist die gewählte TLMG
Teil der Nachricht RAB Assignment Response. Die Abbildungstabelle
in dem SGSN wird dementsprechend aktualisiert.
-
Bei
einer bevorzugten Ausführungsform
werden Multicast-Datenströme auf den
TLMGs multiplexiert.
-
Die
TLMGs können
auf verschiedenen Dienstklassen basiert sein, wie zum Beispiel auf
verschiedenen Dienstgüte-
(QoS-) Parametern, und optional kann Multiplexieren mehrerer Multicast-Datenströme im GGSN
in dem Konzept vorkonfigurierter TLMGs angewendet werden. Auf jeder
TLMG können
mehrere Multicastgruppen multiplexiert werden. Das heißt, mehrere
Multicastgruppen werden auf derselben TLMG transportiert, solange
sie dieselben QoS-Anforderungen aufweisen, welche von der TLMG erfüllt werden.
Bei dieser Lösung
ist es erforderlich, dass die Multicast-Datenströme eindeutig gekennzeichnet
werden. Dies kann erreicht werden, indem zusätzlich zu der TLMG-Adresse
die Multicast-Adressen, MC-Address, der Multicastgruppen verwendet
werden, die in dem weiteren Netz existieren.
-
Auf
der Gn-Schnittstelle ist das GTP-Protokoll zu verwenden, um die
beteiligten Entitäten über die
Beziehung zwischen den Entitäten
zu informieren. Im Falle der Iu-PS-Schnittstelle kann das RANAP
verwendet werden. Zu diesem Zweck muss die Nachricht RAB Assignment
erweitert werden. Falls zum Beispiel die Multicast-Adressen der
Multicastgruppen MC-Address als Multiplexierungs-Kennung verwendet
werden, so wird die MC-Address in der Nachricht RAB Assignment Request
an die RNC übergeben.
-
Es
ist auch möglich,
die Datenpakete zusätzlich
einzukapseln, um eine Multicast-Adresse einzuführen. Ein spezielles Protokoll,
das Generic Routing Encapsulation GRE Protokoll, das in RFC 1701
beschrieben ist, kann verwendet werden, um die Multicast-IP-Pakete
einzukapseln, um ein zusätzliches Feld
hinzuzufügen,
das die Multicast-Adresse transportiert.
-
Falls
das GTP auf der Iu-PS-Schnittstelle verwendet wird, kann eine andere
Multiplexing-Datenstrom-Kennung verwendet werden, die TEID. Gemäß der UMTS-Spezifikation weist
die empfangende Seite des GTP-U-Tunnels
die TEID zu. Falls GTP auf der Iu-PS-Schnittstelle verwendet wird, um den
Multicast-Datenstrom
einzukapseln, wird die TEID einem Multicast-Datenstrom zugewiesen, und daher kann sie
als eine Multiplexing-Datenstrom-Kennung verwendet werden.
-
Oben
wurde eine Prozedur der Einrichtung und Registrierung einer TLMG
beschrieben. Eine entsprechende Prozedur, bei der entsprechende Nachrichten
verwendet werden, wird als Abmeldungsprozedur verwendet. Um zum
Beispiel eine Multicastgruppe zu verlassen, sendet die RNC eine Nachricht
IGMP Leave (IGMP Verlassen).
-
Es
ist auch möglich,
dass ein Szenario vorliegt, in welchem TLMGs auf der Gn-Schnittstelle
verwendet werden und keine TLMGs auf der Iu-PS-Schnittstelle eingerichtet
sind. In diesem Falle wird die TEID verwendet, um den Multicast-Datenstrom
auf der Iu-PS-Schnittstelle
zu kennzeichnen. Die TEID wird durch die RNC zugewiesen und in der Nachricht
RAB Assignment Response zurück
an den SGSN übergeben.
Jedoch die Nachricht RAB Assignment Request enthält noch immer einen Verkehrsklassen-Multicast-Parameter.
Entweder die RNC oder der SGSN kann eine RAB-ID für den Multicast-Datenstrom erzeugen.
Falls der SGSN die RAB-ID erzeugt, wird sie mit der erweiterten
Nachricht RAB Assignment Request an die RNC übergeben. Beim Empfang der
erweiterten Nachricht RAB Assignment Request sendet die RNC entweder
eine Nachricht IGMP Report über
die Iu-PS-Schnittstelle zu
dem SGSN, um der Multicastgruppe beizutreten. Dies geschieht nur
für die
allererste Nachricht RAB Assignment Request für diese Multicastgruppe. In diesem
Szenario wird die Vervielfältigung
der Datenpakete zwischen den registrierten RNCs in dem SGSN durchgeführt, das
heißt,
zu einer registrierten RNC wird jeweils ein Datenpaket übertragen.