-
TECHNISCHES
GEBIET DER ERFINDUNG
-
Die
Erfindung betrifft ein Verfahren, einen Netzknoten, einen Router,
einen Serving Node und ein System zum Durchführen von Multicast in einem Punkt-zu-Punkt-Telekommunikationsnetz.
-
Die
vorliegende Erfindung ist insbesondere in einem Punkt-zu-Punkt orientierten
paketvermittelten Telekommunikationsnetz anwendbar.
-
ALLGEMEINER
STAND DER TECHNIK
-
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.
-
In
dem Falle, wenn Multicast in einem Internet-Protocol-(IP-)Netz verwendet
wird, wird es IP-Multicast genannt. Bei Internet Protocol (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 Baumes. 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 Verteilungsbaumes realisieren die
IP-Multicast Routingprotokolle die Verteilung der Informationen.
Die ausführliche Beschreibung
der entsprechenden IP-Multicast Routingprotokolle ist ebenfalls
in dem oben erwähnten Dokument
zu finden.
-
Multicast
ist ein empfängerbasiertes
Konzept; es bedeutet, dass Empfänger
einer bestimmten Multicast Session Gruppe beitreten, indem sie einen entsprechenden
Multicast-Router informieren, und Verkehr wird mittels der Netzinfrastruktur
an alle Mitgliedern der betreffenden Gruppe weitergesendet. Daher
ist bei IP-Multicast die Mitgliedschaft in einer Multicast Session
Group dynamisch; das heißt,
die Hosts können
jederzeit Gruppen beitreten und Gruppen verlassen. 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, welche
wissen müssen,
welche Multicast-Datagramme zu welcher Schnittstelle weitergeleitet
werden müssen.
-
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.
-
Im
Prinzip verwendet das IGMP zwei grundlegende Nachrichten, um seine
Aufgaben zu erfüllen, 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 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 jeder Schnittstelle weiter, welche
wenigstens ein Mitglied hat.
-
Multicast
in öffentlichen
landgestützten
Mobilfunknetzen (Public Land Mobile Networks, PLMNs) wie General
Packet Radio System (GPRS) oder Universal Mobile Communication System
(UMTS) erfordert eine gewisse Weiterentwicklung, zum Beispiel hinsichtlich
der Mobilität
der Benutzer und der Eigenschaften 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. Punkt-zu-Punkt-Kommunikation bedeutet das Senden einer
Nachricht von einem einzigen Absender zu einem einzigen Empfänger. 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.
-
Im
Folgenden wird 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, werden
beim GSM einige Änderungen
eingeführt;
unter anderem werden neue logische Knoten eingeführt, 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
zum Beispiel 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. Jeder GGSN bedient
eine Anzahl von SGSNs, welche als ein Baum angeordnet sein können, mit
dem GGSN als eine Wurzel des Baumes. 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.
-
Eine
ausführliche
Beschreibung der Architektur ist 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) zu finden.
-
Ähnliche
Knoten mit zwischen ihnen befindlichen 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.
-
Mit
der Einführung
der Streaming- und der konversationalen Multimediadienste werden
sich viele neue Punkt-zu-Mehrpunkt-Dienste
entwickeln. Einige Beispiel solcher Dienste sind Videoconferencing,
Whiteboarding, Echtzeit-Mehrbenutzerspiele, Multimedia-Nachrichten,
virtuelle Welten. Insbesondere wird der Netzbetreiber eine große Anzahl
von verschiedenen Multicast-Anwendungen innerhalb des Mobilnetzes
zur Verfügung
stellen.
-
Die
Einführung
der Multicast-Anwendung auf der Benutzerschicht erfordert eine Koordination
auf der Transportschicht, insbesondere zwischen den Knoten in Bezug
auf die Zustellung von Multicastdaten. In PLMNs mit mehreren GGSNs
gibt es gegenwärtig
keine Koordinations- und Synchronisationsmechanismen für Multicastgruppen
zwischen den GGSNs. Es kann somit geschehen, dass mehrere GGSNs
in einem PLMN sich mit derselben Multicastgruppe befassen, was mehrfache
Multicastgruppen und Multicast-Verbindungen zur Folge hat. Dies
kann geschehen, wenn ein Betreiber mehrere Zugriffspunktnamen (Access
Point Names, APNs) zur Verfügung
stellt, welche den mobilen Endgeräten bekannt sein müssen, um
sich bei dem Dienst des Netzes anzumelden. Der Betreiber kann verschiedene
APNs für
verschiedene Benutzergruppen oder Dienste festlegen, zum Beispiel
kann für
den MMS ein spezieller APN zugewiesen werden. In vielen Netztopologien ist
dies eine recht ineffiziente Nutzung von Ressourcen und Übertragungskapazität. Ferner
verfügt, wenn
die Multicastgruppen-Information im PLMN verteilt ist, der Betreiber
des PLMN über
keine Mittel, um sich bei irgendeiner Analyse auf die Gruppenmitgliedschaft
in dem PLMN zu stützen.
Das bedeutet, dass der Betreiber keine Einschränkungen betreffs zusätzlicher
Mitglieder vornehmen kann oder sich bei irgendeiner Gebührenentscheidung
auf die gesamte Mitgliedschaft der Gruppe in dem PLMN stützen kann.
-
In
Brown K et al.: "ReIM:
reliable multicast for mobile networks", Computer Communications, ELSEVIER
SCIENCE PUBLISHERS BV, Amsterdam, NL, Bd. 21, Nr. 16, 15. Oktober
1998, Seiten 1379–1400,
wird eine Multicast-Lösung
mit zusätzlichen
Knoten offenbart, die eine Host-Gruppe aufbauen, welche einer Multicastgruppe
entspricht, die in der Multicast-Quelle verwaltet wird. Falls ein
Benutzer einer Multicastgruppe beitreten möchte, wird ein Joining Request
(Beitrittsanforderung) an einen Router gesendet, der dem Benutzer
zugewiesen ist. Falls der Router, zu dem die Anforderung gesendet
wurde, die Multicastgruppe nicht versorgt, fragt dieser Router andere
Router ab, zum Ermitteln eines Routers, der bereits zu der Host-Gruppe
gehört.
Anschließend wird
mittels des ermittelten Routers ein Multicast-Baum von dem Router,
zu dem die Anforderung gesendet wurde, bis zum Benutzer erstellt.
Der Nachteil der Lösung
ist, dass infolge der starren Struktur fest zugewiesene Router eine
fest zugewiesene Gruppe von Benutzern versorgen und daher ein Benutzer
nur von dem zugewiesenen Router bedient werden kann. Somit muss
für einen
einzigen Benutzer, der einer Multicastgruppe beitreten möchte, eine separate
Verbindung von einem Quellknoten zu einem zusätzlichen Knoten und von dem
zusätzlichen Knoten
zum Benutzer hergestellt werden. Daher muss sogar dann ein separater
Baum hergestellt werden, wenn ein Router nur einen Benutzer versorgen
soll. Dies führt
zu einer ineffizienten Nutzung von Netzressourcen.
-
Im
Folgenden wird unter Bezugnahme auf 1 das Problem
bei den existierenden Technologien beschrieben. In 1 hat
das UMTS-Netz zwei GGSNs, GGSN1 und GGSN2. Der GGSN2 unterstützt die
Multicastgruppe A. Das heißt,
die Multicastdaten für
die Multicastgruppe A werden zum GGSN2 übermittelt, und der GGSN2 verteilt
die Daten innerhalb des UMTS-Netzes unter Verwendung des festgelegten
Multicast-Zustellungsbaumes.
Falls ein Mobilfunkteilnehmer, der vom GGSN1 versorgt wird, die IGMP-Nachricht "Join Request for
Multicast Group A" (Beitrittsanforderung
für Multicastgruppe
A) sendet, muss ein neuer Zustellungsbaum für die Multicastgruppe A mit
dem GGSN1 als eine Wurzel des Baumes eingerichtet werden. Wie bereits
erwähnt,
findet bei den existierenden Technologien keine Prüfung statt,
ob der Multicast-Datenstrom bereits innerhalb des Mobilnetzes in
Verwendung ist. Daher kann es geschehen, dass zwei verschiedene
Multicast-Bäume
für dieselbe
Multicastgruppe innerhalb desselben Netzes eingerichtet werden.
-
KURZDARSTELLUNG
UND BESCHREIBUNG DER ERFINDUNG
-
Eine
Aufgabe der vorliegenden Erfindung ist es, eine Lösung für eine effiziente
Realisierung der Zustellung von Multicastdaten innerhalb eines Mobilkommunikationsnetzes
bereitzustellen.
-
Die
Erfindung wird durch ein Verfahren, einen Router, einen Serving
Node und ein System verkörpert,
die in den Ansprüchen
1, 14, 18 und 21 offenbart sind. Vorteilhafte Ausführungsformen
werden in den abhängigen
Ansprüchen
beschrieben.
-
Die
Grundidee besteht darin, ein Management der Multicastgruppen innerhalb
eines Mobilkommunikationsnetzes bereitzustellen. Das Mobilkommunikationsnetz
sieht Multicastgruppen vor, und das Netz weist Router auf, welche
Multicastdaten empfangen und die Daten zu Benutzern weiterleiten. Die
Zustellung von Multicastdaten einer Multicastgruppe wird mittels
eines Multicast-Zustellungsbaumes
mit einem Router als eine Wurzel und mit den Benutzern als Blätter des
Baumes durchgeführt.
Das Management der Multicastgruppe innerhalb des Mobilkommunikationsnetzes
wird mit den folgenden Schritten durchgeführt. Im ersten Schritt tritt
ein Benutzer einer Multicastgruppe bei, indem er zum Router eine
Registrierungsnachricht mit einer Anforderung für das Beitreten zu einer Multicastgruppe
sendet. Der Router, zu dem die Anforderung gesendet wurde, prüft beim
Empfang der Registrierungsnachricht, ob der Router die Multicastgruppe
unterstützt. Falls
er sie unterstützt,
führt der
Router, zu dem die Anforderung gesendet wurde, die Registrierung
des Benutzers für
die Multicastgruppe durch, und die Daten werden zum Benutzer weitergeleitet.
Es kann vorkommen, dass die angeforderte Multicastgruppe im Netz
nicht existiert. In diesem Falle richtet der Router, zu dem die
Anforderung gesendet wurde, einen Multicastdaten-Zustellungsbaum
ein. Vor dem Einrichten eines neuen Baumes werden die anderen Router
abgefragt, zum Ermitteln eines Routers, der die Multicastgruppe
unterstützt.
Das Abfragen der anderen Router kann entweder durch das Senden einer
Multicast-Nachricht
zu den anderen Routern durchgeführt werden.
Diese Ausführungsform
ist möglich,
wenn die Router eine Multicastgruppe bilden. Eine andere Möglichkeit
ist, die Router sequentiell mittels Punkt-zu-Punkt-Verbindungen
abzufragen. Das Ermitteln des unterstützenden Routers kann auch durch
Abfragen einer Multicast-Datenbank erfolgen, die in dem Netz vorgesehen
ist. Im Falle des Ermittelns eines Routers wird eine Prozedur zum
Anschließen des Benutzers an den Multicast-Zustellungsbaum
gestartet, welcher den unterstützenden
Router als eine Wurzel des Baumes hat.
-
Im
Folgenden wird die Erfindung ausführlicher im Hinblick auf das
Beispiel von UMTS beschrieben, wo der GGSN ein Router ist, die Registrierungsnachricht
mittels einer IGMP-Nachricht
gesendet wird und der Multicastdaten-Zustellungsbaum mittels einer TLMG eingerichtet
wird.
-
Ein
Vorteil der Erfindung ist, dass die Informationen über die
Mitgliedschaft in Multicastgruppen zwischen den Routern wie zum
Beispiel den GGSNs synchronisiert werden. Dadurch wird eine mehrfache Zuweisung
von Multicastdaten-Zustellungsbäumen für dieselbe
Multicastgruppe vermieden.
-
Durch
das Verbinden der Router über
Multicast-Zustellungsbäume oder
Punkt-zu-Punkt-Verbindungen optimiert die Effizienz der Übertragung
und des Routings im Netz. Mittels einer zusätzlichen Multicast-Datenbank
wird die zentrale Verwaltung und Analyse der Informationen über die
Mitgliedschaft in Multicastgruppen erreicht. Diese zentralisierte
Verwaltung kann zum Beispiel für
Vergebührungs-
und Einschränkungsmechanismen
verwendet werden, welche im Falle von verteilten Multicastgruppen
im Netz nicht möglich
sind.
-
Ferner
ermöglicht
die vorliegende Erfindung die Konfiguration von Multicastgruppen
während
der Inbetriebnahme von Netzknoten und während der Registrierung eines
Teilnehmers.
-
Ferner
wird ein Router bereitgestellt, der in der Lage ist, eine Multicast-Datenzustellung
innerhalb eines Mobilkommunikationsnetzes durchzuführen, das
Multicastgruppen vorsieht und wobei das Netz Router aufweist und
der besagte Router einer der Router ist, welche Multicastdaten empfangen
und die Daten zu Benutzern weiterleiten und die Multicast-Datenzustellung
einer Multicastgruppe mittels eines Multicast-Zustellungsbaumes
mit einem Router als eine Wurzel und mit den Benutzern als Blättern des
Baumes durchgeführt
wird. Dieser Router weist Mittel zum Empfangen einer Registrierungsnachricht mit
einer Anforderung für
das Beitreten eines Benutzers zu einer Multicastgruppe auf. Diese
Nachricht kann entweder direkt von dem Benutzer empfangen werden,
oder von dem Serving Node, falls dieser Knoten für den Benutzer agiert. Mittel
zum Prüfen,
ob der Router die Multicastgruppe unterstützt, werden verwendet, um die
Verfügbarkeit
der angeforderten Multicastgruppe in der Liste der Multicastgruppen, die
von dem Router gehandhabt werden, zu prüfen. Ferner weist der Router
Mittel auf, um die Registrierung des Benutzers für die Multicastgruppe durchzuführen. Falls
der Router die angeforderte Multicastgruppe nicht unterstützt, wird
eine Abfragenachricht an die anderen Router im Mobilkommunikationsnetz gesendet.
Dies wird mit Mitteln zum Abfragen anderer Router zum Ermitteln
eines Routers, der die Multicastgruppe unterstützt, durchgeführt, um
den Benutzer bei der angeforderten Multicastgruppe zu registrieren.
Mittel zum Anschließen
des Benutzers an den Multicast-Zustellungsbaum, der den unterstützenden
Router als eine Wurzel des Baumes hat, werden verwendet, um den
Benutzer in genau dem Serving Node, der den Benutzer bedient, an
den ermittelten Multicast-Zustellungsbaum anzugliedern. Ferner weist
der Router Mittel zum Empfangen einer Abmeldungsnachricht mit einer
Anforderung für
die Abmeldung eines Benutzers von der Multicastgruppe und zum Durchführen der
Abmeldung des Benutzers von einer Multicastgruppe auf.
-
Die
vorliegende Erfindung offenbart außerdem einen Serving Node,
der in der Lage ist, eine Multicast-Datenzustellung innerhalb eines
Mobilkommunikationsnetzes durchzuführen, das Multicastgruppen
vorsieht und wobei das Netz Router aufweist, welche Multicastdaten
empfangen und die Daten zu Benutzern weiterleiten und die Multicast-Datenzustellung
einer Multicastgruppe mittels eines Multicast-Zustellungsbaumes mit einem Router als eine
Wurzel und mit den Benutzern als Blättern des Baumes durchgeführt wird.
Der Serving Node weist Mittel zum Empfangen einer Liste mit den
Multicastgruppen, die für
den Benutzer zugänglich
sind, auf. Diese Liste kann von einer Multicast-Datenbank oder von
einer beliebigen Datenbank, welche die Multicast-Einträge des Benutzers unterstützt, empfangen werden.
Ein solcher Serving Node Mittel auf, um die Registrierung des Benutzers
für die
Multicastgruppe durchzuführen.
Der Serving Node kann entweder die Registrierungsprozedur durchführen, oder
der Knoten fordert den Benutzer auf, welcher die Registrierungsprozedur
einleitet. Der Serving Node empfängt von
dem Router die Adresse des Multicast-Zustellungsbaumes, an welchen der Benutzer
angegliedert werden soll. Mit Mitteln zum Angliedern des Benutzers
an den Multicast-Zustellungsbaum wird der Benutzer an den Router
als eine Wurzel des Baumes angegliedert, der die Multicastgruppe
unterstützt.
-
Ferner
offenbart die Erfindung ein System innerhalb eines Telekommunikationsnetzes,
das in der Lage ist, ein Multicast mit mindestens einem Router und
mindestens einem Serving Node, der Benutzer handhabt, durchzuführen. Die
Funktionalität
des Routers und des Serving Nodes soll durch die im Weiteren beschriebenen
Merkmale erweitert werden. Ein Management der Multicastgruppen wird
gemäß dem Verfahren
von Anspruch 1 durchgeführt.
Ferner weist das System eine Multicast-Datenbank auf, die Einträge der Teilnehmer
verwaltet, die bei den Multicastgruppen angemeldet sind. Diese Datenbank kann
entweder zentral oder dezentral organisiert sein. Es muss sichergestellt
werden, dass Kommunikationsmittel zu den Routern und/oder zu den
Serving Nodes vorgesehen sind, um zu garantieren, dass die Einträge aktuell
sind. Ferner ist es möglich, dass
ein Kommunikationsmittel zum Benutzer vorhanden ist, falls der Benutzer
die Möglichkeit
hat, die Einträge
in der Multicast-Datenbank zu ändern.
-
Weitere
vorteilhafte Ausführungsformen
sind in den abhängigen
Ansprüchen
beschrieben.
-
Im
Folgenden wird eine ausführliche
Beschreibung der Erfindung gegeben.
-
1:
Gegenwärtige
Lösung
für die
Bereitstellung von Multicast innerhalb des UMTS-Netzes,
-
2:
UMTS-Protokollarchitektur,
-
3:
Verfahrensschritte innerhalb des UMTS gemäß einer Ausführungsform
der vorliegenden Erfindung,
-
4:
schematische Darstellung des Nachrichtenaustausches zwischen den
GGSNs gemäß der Erfindung,
-
5:
ein zeitlicher Ablauf eines Signalisierungsflusses zwischen den
UMTS-Knoten gemäß der Erfindung.
-
Im
Folgenden wird unter Bezugnahme auf 2 die Architektur
des UMTS-Netzes beschrieben. 2 zeigt
eine Mobilstation MS, welche über die
Uu-Schnittstelle 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, die in
UMTS verwendet werden. Die folgende Beschreibung konzentriert sich
nur auf zwei IP-Schichten,
die mit IP/PPP und UDP/IP bezeichnet sind. In der 2 sind
die anderen Protokolle aus Gründen
der Vollständigkeit erwähnt. Infolge
der Funktion des GGSN als ein Router und als eine Schnittstelle
zu den externen Netzen wurde die IP-Schicht unter der Anwendungsschicht eingeführt. Aufgrund
der Einschränkung,
dass ein IP-Netz zwischen dem GGSN und dem SGSN vorhanden ist, wird
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 eine Anwendungs-IP- und eine Transport-IP-Schicht
bezeichnet werden. Die Anwendungs-IP-Schicht befindet sich im Protokollstapel
unmittelbar unter den Anwendungsprotokollen, Applicat., und verbindet
die Mobilstation und den 3G-GGSN. Diese IP-Schicht ist für das paketvermittelte Netz
transparent; dies ist durch eine direkte Linie dargestellt, die
von der Mobilstation MS zum 3G-GGSN führt. 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 transportiert, eingekapselt in ein anwendungsspezifisches Tunneling-Protokoll, das GPRS Tunnelling
Protocol GTP, welches ein Beispiel eines Transportschichtprotokolls
für Tunneling ist.
GTP-Pakete verwenden UDP als ein Transportprotokoll. Es gibt jedoch
verschiedene Tunneling-Protokolle, welche für den Aufbau eines Tunnels
verantwortlich sind. Das GTP ist lediglich ein Beispiel.
-
Ferner
sind in 2 nicht das Heimatregister (Home
Location Register, HLR) und/oder der Home Subscriber Server HSS
enthalten, welche ebenfalls für
die Erfindung relevant sind. Das HLR/der HSS ist eine zentralisierte
Netzdatenbank, welche alle Mobilfunkanmeldungen speichert und verwaltet,
die zu einem bestimmten Betreiber gehören. Das HLR ist in die GSM-Netze
integriert. Der HSS wird zum Beispiel in WCDMA Netzen wie dem UMTS
verwendet. Im Folgenden wird der Begriff HLR verwendet. Die Erfindung
ist jedoch nicht nur auf das HLR beschränkt.
-
Um
das Verfahren der vorliegenden Erfindung zu verbessern, wird vorgeschlagen,
Multicastgruppen mit den Netzknoten als Mitglieder dieser Gruppen
zu bilden. Die Einrichtung und die Konfiguration von vordefinierten
Multicastgruppen könnte während der
Inbetriebnahme von Knoten durchgeführt werden. Das heißt, der
Betreiber des Netzes kann zum Beispiel definieren, dass alle GGSNs
eine Multicastgruppe bilden. Mit dieser Lösung wird die Abfrageprozedur
zwischen den GGSNs vereinfacht, da nur eine Nachricht ausgesendet
werden muss, um alle Mitglieder der GGSN-Multicastgruppe zu erreichen.
Optional informiert ein GGSN, wenn er ein erstes Mitglied einer
Multicastgruppe registriert oder ein letztes Mitglied abgemeldet
hat, alle anderen GGSNs darüber.
Stattdessen oder außerdem
kann der GGSN die MC-Gruppen-Datenbank
aktualisieren. Zwischen den GGSNs kann eine beliebige Art von Pull-
oder Push-basierter Synchronisation angewendet werden.
-
Anstelle
eines Multicasts der Informationen zwischen verbundenen GGSNs mittels
der TLMG können
auch dedizierte Punkt-zu-Punkt-Verbindungen zwischen den GGSNs verwendet werden,
um die Multicast-Informationen nur mittels jeweils einer Kopie pro Übertragungsstrecke
zu übertragen.
-
Im
Folgenden wird die Erfindung unter Bezugnahme auf 3 beschrieben,
welche die Konfigurationsschritte für Multicastgruppen in Mobilnetzen wie
UMTS zeigt.
-
In 3 sind
die UMTS-Knoten dargestellt, welche für die Erfindung relevant sind.
Diese Knoten sind die Mobilstation MS, der SGSN, zwei GGSNs, ein
HLR und eine Datenbank MC-Datenbank.
Die Pfeile zwischen den Knoten zeigen die Informationsflüsse zwischen
den jeweiligen Knoten, wobei die Pfeile mit zwei Ziffern x·y beschriftet
sind und die Pfeile mit demselben x und verschiedenem y Alternativen
bezeichnen.
-
Im
ersten Schritt 0.1 konfiguriert ein Managementsystem die
Teilnehmerdatensätze,
welche sich zum Beispiel im HLR oder in einer dedizierten Datenbank
befinden können.
Falls eine Mobilfunkanmeldung die Voranmeldung bei bestimmten Multicastgruppen
enthält,
sind die Adressen der Multicastgruppen in dem Teilnehmerdatensatz
enthalten. Ferner sieht das Netz eine Multicast-Datenbank vor, MC-Datenbank. Die MC-Datenbank
befindet sich zum Beispiel in einem zentralen Knoten oder optional standortgleich
im HLR und enthält
eine Liste aller Multicastgruppen, welche von dem Mobilnetz unterstützt werden
und welche Teil des Datensatzes eines Teilnehmers sein können. Die
MC-Datenbank kann auch eine Liste aller Teilnehmer jeder Multicastgruppe
enthalten. Dies kann auch eine Liste derjenigen Teilnehmer sein,
welche bei einer Multicastgruppe vorangemeldet sind. Bei einer fortgeschritteneren
Implementierung kann die MC-Datenbank
weitere die Multicastgruppen betreffenden Informationen enthalten.
Zum Beispiel können
für eine
Multicastgruppe die Anforderungen an die Dienstgüte QoS definiert sein, um für jede Multicastgruppe
die dedizierte QoS zu erhalten. Andere Informationen können die Informationen
sein, welche die Sicherheit betreffen, wie zum Beispiel das Verfahren
für die
Schlüsselbeschreibung,
oder die Informationen, welche die Vergebührung/den Tarif betreffen.
Die Gebühren
für die Übertragung
von Multicastdaten können
sich in Abhängigkeit
von der Anzahl der Multicast-Benutzer unterscheiden; das heißt, die
Gebühren
sind verschieden, wenn mindestens 10 Mitglieder vorhanden sind oder
wenn wenigstens 20 Mitglieder vorhanden sind. Ferner kann die Priorität für die Multicastgruppen
definiert sein. Zum Beispiel erhält
im Falle einer Knappheit von Ressourcen eine Service-Multicastgruppe eine
höhere
Priorität
als eine kommerzielle Multicastgruppe. Die zusätzlichen Informationen werden ebenfalls
in der Multicast-Datenbank gespeichert.
-
Der
Schritt 0.1 kann entweder von der Multicast-Datenbank oder
vom HLR ausgelöst
werden. Zwischen der Multicast MC-Datenbank und dem HLR können Verhandlungs-
oder Verifizierungs-Signalisierungsnachrichten irgendeiner Art ausgetauscht werden,
um die Daten in beiden Datenbanken konsistent zu halten. Die MC-Datenbank
kann die Multicastgruppen speichern, die von dem PLMN oder von dem
Betreiber unterstützt
werden. Die Unterschiede können
entstehen, wenn ein PLMN zeitweilig eine Multicastgruppe unterstützt, welche
im Allgemeinen nicht zu den vorangemeldeten Multicastgruppen des Betreibers
gehört.
Dies muss in Bezug auf die verschiedenen Roaming-Fälle betrachtet
werden. Bei einer fortgeschrittenen Implementierung müssen sämtliche
vorangemeldeten Multicastgruppen nach der Durchführung des Roamings verfügbar gemacht
werden.
-
Der
Teilnehmer meldet sich beim Netz mittels der gewöhnlich angewendeten Registrierungsprozedur
an. Im GSM-Netz beinhaltet diese Prozedur die so genannte IMSI-Anmeldungsprozedur,
welche zur Aktivierung des Teilnehmers im Netz führt, insbesondere in den Datensätzen des Teilnehmers
im HLR. Das heißt,
der Teilnehmerserver wie das HLR erhält die Registrierungsinformationen,
so dass während der
Registrierung eines Teilnehmers die Liste angemeldeter Multicastgruppen,
welche in der MC-Datenbank gespeichert ist, zum SGSN gesendet wird.
Dies ist in 3 in Schritt 1.1 dargestellt.
Neben der Liste angemeldeter Multicastgruppen könnten auch die Priorität betreffende
Informationen für
die einzelnen Multicastgruppen übertragen
werden. Falls sich ein Teilnehmer für mehrere Multicastgruppen
angemeldet hat, kann das Netz entscheiden, nur die Registrierung
für die
Multicastgruppen mit hoher Priorität zu aktivieren, in Abhängigkeit
von der Situation bei den Netzressourcen, wie zum Beispiel von der
Tageszeit. Als Alternative zu Schritt 1.1 kann der SGSN
nach der normalen Registrierung eines Teilnehmers die Liste angemeldeter
Multicastgruppen für
einen Teilnehmer aus dem HLR abfragen. Dies ist durch Schritt 1.2 dargestellt.
-
Falls
der SGSN die Liste empfängt,
die aus den möglichen
Multicastgruppen besteht, wird diese Liste an den Benutzer gesendet,
damit er sich bei bestimmten Multicastgruppen anmelden kann.
-
Der
Schritt des Sendens der Liste an den Benutzer ist in 3 in
Schritt 2.1 dargestellt. Der SGSN sendet die Liste angemeldeter
Multicastgruppen an die MS des Benutzers, und die MS des Benutzers
tritt den aufgelisteten Multicastgruppen bei. Dies erfordert neben
der Übertragung
der Liste angemeldeter Multicastgruppen auch Funktionalität in der
Mobilstation, um diese Liste zu verarbeiten. Bei einer Ausführungsform
tritt der Benutzer jeder der aufgelisteten Multicastgruppen bei.
Bei einer anderen Ausführungsform
der vorliegenden Erfindung aktiviert der Teilnehmer nicht alle diese
Multicastgruppen in allen Fällen
in der entsprechenden Datenbank. Dafür kann ein Verhandlungsprozess
zwischen dem Teilnehmer und der Mobilstation verwendet werden, um zeitweilig
Anmeldungen bei Multicastgruppen zu aktivieren oder zu deaktivieren.
Die besagte Verhandlung kann insbesondere im Falle von Roaming sehr nützlich sein,
das heißt
in Fällen,
wenn der Benutzer das PLMN wechselt. Das Ergebnis der Verhandlung wird
anschließend
an die entsprechende Datenbank gesendet, wobei die Mobilstation
das Ergebnis an den SGSN sendet, welcher für das Weiterleiten der Nachricht
zu der entsprechenden Datenbank, entweder dem HLR oder de MC-Datenbank, verantwortlich ist.
-
Bei
einer weiteren Ausführungsform
ist vorgesehen, die Teilnehmerdatensätze zu ändern. Zu diesem Zweck existiert
eine zusätzliche
Registrierungs-/Abmeldungs- und Aktivierungs-/Deaktivierungs-Prozedur
zwischen dem Teilnehmer und dem Teilnehmerserver, wie dem HLR, um
den direkten Zugriff auf die im HLR verfügbaren MC-Gruppen-Informationen von
der Mobilstation aus zu ermöglichen. Dies
ist in Schritt 2.3 dargestellt. Mit diesem Verfahren ist
es für
den Benutzer möglich,
sein im HLR gespeichertes Profil zu ändern, so dass der Benutzer die
Einträge
in der Liste der Multicastgruppen, die für den Benutzer verfügbar sind,
beeinflusst. Das bedeutet, dass die Liste individuell von dem Benutzer
erstellt wird und nicht von dem PLMN bereitgestellt wird, wie es
in Schritt 2.1 der Fall ist. Zum Durchführen dieser Prozedur können die
an der Signalisierungsschnittstelle implementierten ergänzenden Dienste
(Supplementary Services) von GSM/UMTS, wie zum Beispiel das MAP
(Mobile Application Protocol) oder das internetgestützte Anmeldungsmanagement
auf einem Datenkanal, angewendet werden, um das Editieren der Datensätze der
angemeldeten Multicastgruppen über
das Mobiltelefon möglich
zu machen. Der Benutzer kann zum Beispiel die Registrierung bei
oder die Abmeldung von einer Multicastgruppe durchführen.
-
Bei
einer anderen Ausführungsform
ist vorgesehen, den direkten Zugang zu den in der Multicast-Datenbank verfügbaren Multicastgruppen-Informationen
von der Mobilstation aus zu ermöglichen. Dadurch
kann das HLR umgangen werden, und Änderungen können direkt in der MC-Datenbank vorgenommen
werden. Dies könnte
vorteilhaft sein, um eine zusätzliche
Belastung am HLR zu vermeiden. Dies wird zum Beispiel mittels eines
Direktzugriffs erreicht, wie in Schritt 2.4 dargestellt
ist.
-
Als
Alternative, welche in Schritt 2.2 dargestellt ist, schließt der SGSN
die MS des Benutzers an jede der Gruppen in der Liste angemeldeter
Multicastgruppen an und informiert die MS darüber. Der Vorteil dieser Alternative
ist, dass die Ressourcen an der Luftschnittstelle eingespart werden.
Die Pfeile, die in beide Richtungen gerichtet sind, zeigen die Interaktion
zwischen dem SGSN und der MS. Mittels der Schritte 3.1, 4.1 und 5.1 kann
die Liste angemeldeter Multicastgruppen geändert werden.
-
Die
Schritte 0.1 bis 2.3 werden nicht ausgeführt, falls
ein Benutzer bereits in dem Netz registriert ist und der Benutzer
sich nach der Registrierung entschließt, einer Multicastgruppe beizutreten.
Das heißt,
ein Benutzer kann entweder eine Voranmeldung bei Multicastgruppen
haben, welche zum Beispiel durch den Kauf einer SIM-Karte erfolgt,
oder der Benutzer kann sich bei einer Multicastgruppe dynamisch
anmelden und abmelden.
-
In
diesem Falle müssen
nur die folgenden Schritte ausgeführt werden. Ferner kann dies
zur Folge haben, dass die Einträge
in der MC-Datenbank nicht aktualisiert werden und keine Interaktionen
mit der MC-Datenbank durchgeführt
werden.
-
Nach
der Beendigung der Anmeldungsprozedur bei den bestimmten Multicastgruppen
wird im nächsten
Schritt, 3.1, das Beitreten zu den gewählten Multicastgruppen durchgeführt. Zu
diesem Zweck sendet der SGSN die IGMP- Beitrittsnachricht, welche entweder
von der Mobilstation MS oder vom SGSN generiert werden kann, an
den GGSN, Schritt 3.1.
-
Zusätzlich kann
der SGSN bei der MC-Datenbank prüfen,
ob die Multicastgruppen, die in der Liste angemeldeter Multicastgruppen
des Teilnehmers enthalten sind, noch gültig sind. Dies ist in 3 in
Schritt 5.1 dargestellt. Mögliche Ergebnisse dieser Abfrage
sind zum Beispiel, dass die Multicastgruppe vom PLMN unterstützt wird,
oder dass die Multicastgruppe im PLMN gegenwärtig nicht verfügbar ist,
oder dass die Multicastgruppe nicht gültig ist, einfach um das Problem
zu vermeiden, das auftritt, wenn die Daten im HLR nicht rechtzeitig
aktualisiert werden oder die Multicastgruppe gesperrt ist, weil zum
Beispiel der Inhalt, welcher über
diese MC-Gruppe übertragen
wird, aus rechtlichen, sozialen oder anderen Gründen nicht über das Netz des Betreibers übertragen
werden soll. Diese Prüfung
ist nicht obligatorisch, und sie muss nicht jedes Mal durchgeführt werden,
wenn eine Liste angemeldeter MC-Gruppen am SGSN empfangen wird,
falls der SGSN über
alle früher
geprüften
MC-Gruppen Buch führt.
-
Mit
dem Empfang der Beitrittsnachricht beginnt der GGSN, einige Prüfungen und
Verifizierungen durchzuführen.
Der GGSN kann in der MC-Datenbank prüfen, ob die MC-Gruppe, welche
eingerichtet werden soll, noch gültig
ist, Schritt 5.2. Die möglichen
Ergebnisse dieser Abfrage sind dieselben, wie im Schritt 5.1 erwähnt wurde.
-
Ferner
kann der GGSN nach der Inbetriebnahme prüfen, welche Multicastgruppen
direkt eingerichtet werden müssen.
Optional enthält
der Schritt 5.2 den Abruf der Liste von Knoten, welche
obligatorische Mitglieder jeder Multicastgruppe sind, und der GGSN
muss den Beitritt dieser Knoten erzwingen. Eine Alternative ist,
dass jeder Knoten, welcher Teil einer Multicastgruppe in UMTS sein
kann, Schritt 5.1 ausführen
muss, um die Liste der Multicastgruppen abzurufen, denen er beitreten
muss. Ferner prüft
der GGSN in Schritt 4.1, ob die angeforderte Multicastgruppe
bereits von einem anderen GGSN bedient wird. Daher sendet er eine
Multicast-Abfrage an die anderen GGSNs, vorzugsweise über eine
Multicastgruppe, welche alle GGSNs enthält. Es können irgendwelche Auswahlkriterien
wie etwa Durchlaufzeit, Entfernung oder Bandbreite verwendet werden,
um nur eine Teilmenge aller GGSNs in dem PLMN abzufragen. Es ist
auch möglich,
dass ein GGSN, welcher abgefragt wird, wobei dieser GGSN im Folgenden Anker-GGSN
genannt wird, mit der MC-Datenbank Kontakt aufnimmt, um den GGSN
zu bestimmen, der die angeforderte Multicastgruppe bedient. Diese Ausführungsform
funktioniert in dem Falle, wenn jeder GGSN, welcher eine Multicastgruppe
innerhalb des PLMN eingerichtet hat, die MC-Datenbank informiert,
welche den entsprechenden Eintrag in den Datensätzen ändert. Das bedeutet, dass eine
Verwaltungsschnittstelle in der MC-Datenbank implementiert werden muss.
Falls die angeforderte Multicastgruppe nicht von irgendeinem GGSN
unterstützt wird,
fragt der Anker-GGSN die anderen GGSNs ab oder richtet direkt eine
neue Multicastgruppe innerhalb des Netzes ein und informiert die
MC-Datenbank, um die entsprechenden Einträge zu aktualisieren.
-
Die Übertragung
der Daten zwischen den GGSN und zum Teilnehmer erfolgt mittels einer
so genannten TLMG. Innerhalb dieser Lösung wird ein Transportebenen-Multicastgruppen-(Transport
Level Multicast Group, TLMG)Tunnel auf der Transportschicht vom
GGSN zum SGSN aufgebaut, um die Multicastdaten über den besagten Tunnel zu
Benutzern zu übermitteln,
die für
eine Multicastgruppe registriert sind. Der TMLG Tunnel wird mittels
eines Transportschichtprotokolls für das Tunnelling wie des GPRS
Tunnelling Protocol GTP eingerichtet, und der besagte Tunnel wird
der Multicastgruppe zugewiesen, bei welcher sich der Benutzer registriert.
Das heißt,
dass ankommende Multicastdaten, die auf der Anwendungs-IP-Schicht
gesendet werden, zur Transport-IP-Schicht umgeleitet und über den
TMLG Tunnel transportiert werden. Die Einrichtung des GTP Tunnels
wird in einem späteren
Teil der Beschreibung beschrieben. In einer Mobilfunkumgebung wie
dem UMTS können
die TLMGs auf der Transportschicht implementiert werden, indem IP-Multicast
für eine
effiziente Übertragung
im IP-Netz zwischen
dem SGSN und GGSN verwendet wird, mit der Option, es zum RNC/BSC
oder sogar noch weiter bis zur MS zu erweitern. Stattdessen kann
auch eine vorkonfigurierte Multicastübertragung für Teile
eines Netzes, welches hauptsächlich Punkt-zu-Punkt
orientiert ist, verwendet werden. Das bedeutet, dass eine TLMG nicht
jedes Mal eingerichtet wird, wenn ein Benutzer sich bei einer neuen
Multicastgruppe registriert, sondern dass die TLMG für bestimmte
Multicastgruppen oder mit bestimmten Parametern, wie zum Beispiel
bestimmten QoS-Parametern, voreingerichtet werden. Im letzteren
Falle kann es vorteilhaft sein, auf einer TLMG die Datenflüsse verschiedener
Multicastgruppen zu multiplexieren, welche die Anforderungen der
Parameter der voreingerichteten TLMG erfüllen.
-
Im
Folgenden wird die in Schritt 4.1 ausgeführte Prozedur unter Bezugnahme
auf 4 ausführlicher
beschrieben. Die Struktur von 4 ist der Struktur
von 1 ähnlich.
Die Unterschiede sind die Schnittstellen zwischen den GGSNs, an
welchen der Informationsaustausch durchgeführt wird.
-
Zuerst
empfängt
der GGSN1 eine IGMP-Nachricht von der MS, wie sie oben mit Bezug auf
Schritt 3.1 beschrieben wurde. Der Empfang der IGMP-Nachricht
ist in 4 mittels eines Pfeils dargestellt, der auf den
GGSN1 gerichtet ist. Im Falle des Empfangs einer IGMP-Beitrittsnachricht
prüft der GGSN
zuerst, ob eine neue TLMG für
die angeforderte Multicastgruppe benötigt wird. Die Kennung der angeforderten
Multicastgruppe ist Teil der IGMP- Beitrittsnachricht. Zu diesem Zweck
durchsucht der GGSN seine eigene lokale Datenbank nach der Multicastgruppe,
und falls die besagte Multicastgruppe nicht unterstützt wird,
wird die unterstützende
GGSN bestimmt. Dies kann geschehen, indem die MC-Datenbank abgefragt
wird oder indem eine Abfragenachricht an die anderen GGSNs des PLMN
gesendet wird. Die Abfragenachricht kann mittels der Multicastübertragung
oder mittels der Punkt-zu-Punkt-Übertragung
gesendet werden. Die vorteilhafteste Art und Weise, die Abfragenachricht zu
senden, besteht darin, sie mittels der Multicastübertragung zu senden. Dies
wird im Folgenden Multicastgruppen-Abfrage oder MC-Abfrage genannt. Dies
ist in 4 durch senden der MC-Abfrage zu GGSN2 und GGSN3
dargestellt. Die MC-Abfrage kann auf einer TLMG gesendet werden,
welche für die
Kommunikation zwischen GGSNs dediziert ist und welche im Voraus
während
oder nach der Konfiguration der GGSNs eingerichtet worden ist, und
entweder alle GGSNs oder eine Teilmenge von ihnen sind Mitglieder
dieser Multicastgruppe. Diese voreingerichtete und vorkonfigurierte
TLMG wird im Weiteren mit Config-TLMG bezeichnet. Da die TLMG voreingerichtet
ist, ist es nicht erforderlich, die Signalisierungsinformationen
auszutauschen, zum Beispiel mittels des GTP-Protokolls, wie es weiter
unten in Bezug auf die Registrierungsprozedur eines Benutzers beschrieben
ist. Ein GGSN schließt
sich der Config-TLMG an, indem er direkt eine IGMP-Beitrittsnachricht
sendet. Die Abfragenachricht, welche mittels der Config-TLMG gesendet
wird, verwendet beispielsweise das UDP Protokoll als das Übertragungsprotokoll.
Im Falle einer Punkt-zu-Punkt-Verbindung
zwischen den GGSNs kann das TCP-Protokoll verwendet werden. Das
TCP ist ein transaktionsorientiertes Protokoll, anders ausgedrückt, ein
Protokoll, welches die Anforderungs- und Antwortnachrichten zum
Durchführen
einer Übertragung
verwendet. In der oben beschriebenen Ausführungsform bilden die GGSNs
eine GGSN Multicastgruppe. Es ist natürlich möglich, dass von irgendwelchen
Netzknoten des Mobilkommunikationssystems eine Router-Multicastgruppe
gebildet wird.
-
Falls
der GGSN die Nachricht empfängt, dass
keiner der GGSNs die Multicastgruppe unterstützt, wird eine neue dedizierte
TLMG von dem angeforderten GGSN zu den Benutzern gebildet. Falls ein
GGSN bereits eine TLMG für
die Multicastgruppe erzeugt hat, sendet er eine Antwort an den anfordernden
GGSN. In 4 ist dies durch das Senden
einer Antwortnachricht vom GGSN2 zum GGSN1 dargestellt. Die besagte
Antwortnachricht enthält
die TLMG-Adresse, welche zu verwenden ist, um die Multicastdaten
zum Benutzer und optional die Adresse des GGSN weiterzuleiten. Zusätzlich setzt
der antwortende GGSN ein Flag im Datenbankeintrag, welches angibt,
dass andere GGSNs Mitglieder dieser Gruppe versorgen. Dies ist für den Abmeldungsprozess
notwendig, falls nicht alle Mitglieder der Multicastgruppe in einer
zentralen Datenbank gespeichert sind, das heißt, wenn die Datenbank dezentralisiert ist
und die anderen GGSNs im Falle einer Abmeldung ebenfalls informiert
werden müssen.
Falls alle Mitglieder der Multicastgruppe in einer Datenbank gespeichert
sind, so muss diese Datenbank aktualisiert werden Die anfordernde
GGSN speichert die TLMG und optional die Adresse der antwortenden GGSN
in ihrer lokalen Datenbank. Die GGSN-Adresse kann notwendig werden,
um dem Anker-GGSN anzuzeigen, dass alle Mitglieder abgemeldet sind.
In 4 ist ein Beispiel dargestellt, in welchem der GGSN2
die Multicastgruppe A unterstützt.
Das heißt, die
Daten der Multicastgruppe A werden mittels der TLMG T(A) für die Multicastgruppe
A dem GGSN2 zugestellt und an alle Benutzer weitergeleitet, wobei die
TLMG eine Struktur eines Multicast-Zustellungsbaumes aufweist. Es
muss jedoch sichergestellt werden, dass der SGSN, welcher den Benutzer
bedient, der den Beitritt zur Multicastgruppe A anfordert und von
dem GGSN1 gehandhabt wird, Teil des besagten Multicast-Zustellungsbaumes
wird. Diese Prozedur wird im Folgenden unter Bezugnahme auf 5 beschrieben.
-
5 zeigt
einen zeitlichen Ablauf der gesendeten Nachrichten zwischen einer
Mobilstation MS, einem SGSN, einem GGSN1 und einem GGSN2. Ein Pfeil
bezeichnet eine gesendete Nachricht. Über einem Pfeil ist der Name
der Nachricht angegeben, und unter dem Pfeil sind die Hauptparameter
der entsprechenden Nachricht aufgelistet.
-
Zuerst
wird ein GTP Tunnel eingerichtet. Dies geschieht während der
so genannten PDP-Kontext-Aktivierung. Die PDP-Kontext-Aktivierung ist mit dem Anmelden
bei dem externen IP-Netz vergleichbar. Zu diesem Zweck wird eine
Mobilteilnehmerkennung mit einer IP-Adresse verknüpft. Während der PDP-Kontext-Aktivierung
wird ein Tunnel mit einer Kennung, der so genannten TID, zwischen
dem SGSN und GGSN für
den PDP-Kontext erzeugt. Während
dieser Prozedur findet außerdem
eine Dienstgüte-(Quality
of Service, QoS)Verhandlung zwischen der MS und dem SGSN/GGSN statt. Über den
GTP-Tunnel wird die IGMP-Nachricht an den GGSN1 mit der MCAddr.
gesendet, was die Multicast-Adresse der Multicastgruppe ist, welcher
der Benutzer beitreten möchte.
Falls die Multicastgruppe nicht von dem GGSN1 unterstützt wird,
wird eine Abfrage an die anderen GGSNs gesendet. Das Format der
Nachricht hängt
vom Zustellungsverfahren ab, zum Beispiel Config-TLMG oder eine Punkt-zu-Punkt-Verbindung.
Zum Beispiel muss im Falle von TLMG die Multicast-Adresse eingesetzt werden,
und das verwendete Protokoll kann das UDP sein. Im Falle der Punkt-zu-Punkt-Verbindung
ist die Adresse der abgefragten GGSN in der Nachricht enthalten
und wird zum Beispiel mittels des TCP-Protokolls transportiert.
Der GGSN1 empfängt
als Antwort die Antwortnachricht vom GGSN2 mit der TLMG-Adresse
und optional mit der Adresse des GGSN2. Das Format der Nachricht
hängt auch
in diesem Fall vom Zustellungsverfahren ab. Der GGSN1 sendet eine
Antwort an den SGSN, New GTP: SGSN Membership Report Request (Neue
GTP-Nachricht: SGSN Mitgliedschaftsbericht-Anforderung), mit TLMG-MCAddr.,
was die Adresse der TLMG ist, und mit MS- HostID, was die Kennung des Benutzers
ist, der darum ersucht, der Multicastgruppe beizutreten. Der SGSN
muss diese Kennung des Benutzers haben, um die empfangenen Daten
an den zutreffenden Empfänger
zu senden. Diese Nachricht kann auch die Adresse des GGSN2 enthalten.
Der SGSN muss die Adresse des GGSN2 haben, um mit diesem Knoten
in Kontakt zu kommen. Diese Adresse kann jedoch auch zum Beispiel
mittels eines Resolutionsprotokolls bestimmt werden, welches in
einem Baum verwendet wird, um eine Wurzel des Baumes zu finden.
Das heißt,
der SGSN kann die Adresse des GGSN2 ermitteln, indem er das Resolutionsprotokoll und
die Adresse des TLMG verwendet, um den GGSN zu finden, der die Wurzel
des Baumes ist. Sobald der SGSN die Adresse des GGSN2 hat, sendet er
eine IGMP-Mitgliedschafts-Adresse
an den GGSN2. Der GGSN2 sendet eine New GTP: SGSN Membership Report
Request (Neue GTP-Nachricht: SGSN
Mitgliedschaftsbericht-Anforderung) mit TLMG-MCAddr. an den SGSN.
Es könnte
sein, dass der SGSN irgendeine Überprüfung durchführt. Im
Ergebnis wird die Nachricht New GTP: SGSN Membership Report Result
(Neue GTP-Nachricht:
SGSN Mitgliedschaftsbericht-Ergebnis) mit TLMG-MCAddr. an den GGSN2 gesendet. Mit diesem
Schritt wird der SGSN Teil des Baumes mit GGSN2 als Wurzel für die besagte
MC-Gruppe. Ferner sendet der SGSN eine Nachricht New GTP: SGSN Membership
Report Result mit TLMG-MCAddr. an den GGSN1, so dass im Falle einer
Registrierung eines neuen Benutzers bei derselben Multicastgruppe
eine Abfragenachricht an den GGSN2 vermieden wird und es außerdem nicht erforderlich
ist, den Schritt auszuführen,
der notwendig ist, um den SGSN an die TLMG anzuschließen. In diesem
Falle sendet der SGSN direkt die Adresse der TLMG und die MS-HostID
des Benutzers an den GGSN2.
-
Falls
die Abfragenachricht an die GGSNs eine negative Antwort zur Folge
hat, das heißt,
wenn keiner der GGSNs die Multicastgruppe unterstützt, wird
eine neue dedizierte TLMG auf der Transport-IP-Schicht für das Multicast,
das auf der Anwendungs-IP-Ebene eintrifft, von dem GGSN1 eingerichtet,
mit dem SGSN als ein Mitglied des TLMG-Baumes. Diese Prozedur wird
im Folgenden ohne eine Figur beschrieben. Zuerst weist der GGSN1
eine Multicast-Adresse aus dem Adressraum des Kernnetzes zu. Im
Folgenden wird diese die Multicast-IP-Adresse der TLMG oder auch TLMG-MC-Adresse
oder einfach TLMG-Adresse genannt. Um die eigentliche TLMG zu erzeugen,
kann der GGSN1 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 im GGSN1 erst bei Erhalt eines
positiven Ergebnisses von dem SGSN zu erzeugen.
-
Der
GGSN1 informiert den entsprechenden SGSN, dass er Mobilstationen
für eine
Multicastgruppe registriert hat, zum Beispiel mittels 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 existierende Nachricht zu verwenden, zum Beispiel eine
erweiterte Packet Data Unit (PDU) Benachrichtigung auf der UDP-Verbindung.
-
Die
Nachricht SGSN Membership Report Request enthält Informationen, die für die Vervielfältigung
des Multicast-Datenstromes
zu mehreren Unicast-Datenströmen
im SGSN benötigt
werden, wie zum Beispiel die TLMG-MCAddress und die MS-HostID, welche
die Host-Kennung der MS ist, welche für die Multicastgruppe registriert
wird. Somit ignoriert der GGSN für
den Verkehr der Multicastgruppe den Tunnel, welcher bereits für diese
MS von dem SGSN während
der PDP-Kontext-Aktivierung
eingerichtet worden ist, und verwendet stattdessen TLMGs, welche
einen Multicast-Zustellungsbaum bilden. Diese Art von Multicast-Zustellungsbaum
wird in der weiteren Beschreibung ein TLMG-Zustellungsbaum genannt.
-
Nach
dem Empfang der Nachricht SGSN Membership Report Request führt der
SGSN eine Multicast Group MC Membership Verification (Überprüfung der
Mitgliedschaft der Multicastgruppe) durch. Insbesondere bedeutet
das, dass der SGSN eine Anmeldungsprüfung oder eine Prüfung von
Gebührenknoten
durchführen
kann, um zu bestimmen, ob es der Mobilstation gestattet ist, sich
für irgendeine
oder für
diese spezielle Multicastgruppe zu registrieren. Das Ergebnis der Überprüfung ist
in der Nachricht SGSN Membership Report Result (SGSN Mitgliedschaftsbericht-Ergebnis) enthalten.
Im Falle eines negativen Ergebnisses der Überprüfung sendet der SGSN eine Nachricht
SGSN Membership Report Result, welche im Falle eines negativen Ergebnisses
von einer Angabe des Grundes begleitet sein kann, an den GGSN zurück, die
angibt, dass die Multicastüberprüfung nicht
erfolgreich war und dass die Mobilstation nicht der Multicastgruppe
der Anwendungsebene beitreten sollte. Im Falle eines positiven Überprüfungsergebnisses
zeigt diese Nachricht dem GGSN einen erfolgreichen Ausgang an. Ferner
speichert der SGSN dann den Zusammenhang zwischen der TLMG-MCAddress
und der MS-HostID, zum Beispiel durch einfaches Hinzufügen der TLMG-MCAddress
zu den existierenden PDP-Kontext-Informationen
für die
betreffende MS, um in der Lage zu sein, bei Empfang des Multicast-Datenstroms
die Daten zu vervielfältigen
und diese zu den entsprechenden Hosts weiterzuleiten.
-
Bei
Empfang der Nachricht SGSN Membership Report Result sendet der GGSN
eine Nachricht 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.
-
Im
Falle eines erfolgreichen SGSN Membership Report Result wird der
Zähler
für die
Anzahl der Benutzer für
die Multicastgruppe und demzufolge für die TLMG inkrementiert, und/oder
die MS-HostID wird zu der Multicastgruppe hinzugefügt.
-
Jedes
Mal, wenn ein SGSN eine erste MS hat, die sich für eine Multicastgruppe registriert,
und der SGSN selbst für
die TLMG registriert und zum TLMG Multicast-Zustellungsbaum hinzugefügt wird, sendet
der SGSN eine Nachricht IGMP Membership Report (IGMP Mitgliedschaftsbericht)
an den GGSN. Ferner verwendet die Nachricht IGMP Membership Report
die verhandelte Dienstgüte
QoS, die während der
PDP-Kontext-Aktivierung
empfangen wurde, zum Auswählen
des richtigen QoS Pfades von dem SGSN zum GGSN. Für diesen
Zweck können
existierende Multicast-Routingbaum-Protokolle verwendet werden.
-
Der
GGSN sorgt für
die Ausbreitung der Multicast-Mitgliedschaft über das
Backbone-Netz über die
Gi-Schnittstelle
durch senden des IGMP Membership Reports. Die Ausbreitung der Mitgliedschaft auf
benachbarte Router ist nur erforderlich, um anzuzeigen, dass wenigstens
ein Mitglied der entsprechenden Multicastgruppe in dem lokalen Netz,
zum Beispiel PLMN, vorhanden ist, welches Multicastdaten empfangen
möchte.
Daher ist diese Ausbreitung nur für das erste Mitglied einer
Multicastgruppe innerhalb des PLMN erforderlich.
-
Es
wurde bereit erwähnt,
dass die GGSNs eine Multicastgruppe bilden, welche mittels der TLMG
verbunden ist. Das heißt,
dass der Betreiber eine Multicastgruppe mit allen GGSNs als Mitgliedern
dieser Multicastgruppe einrichten kann, um alle GGSNs zur Ermittlung
des GGSN, welcher die angeforderte Multicastgruppe unterstützt, abzufragen.
-
Bei
einer anderen Ausführungsform
der Erfindung betrachtet der GGSN, welcher die spezielle Multicastgruppe
bedient, die anderen GGSNs als SGSNs mit Gruppenmitgliedern. Anders
ausgedrückt,
jeder der besagten anderen GGSNs wird zu einem Blatt eines Multicast-Zustellungsbaumes,
und er befindet sich logisch auf derselben Schicht innerhalb des
Baums wie die SGSNs. In diesem Falle muss dieser GGSN in der Schleife
verbleiben, bis keine Gruppenmitglieder mehr in dem PLMN aktiv sind,
auch wenn dieser GGSN selbst keine aktiven Gruppenmitglieder mehr
hat.
-
Falls
der Anker-GGSN keine Gruppenmitglieder mehr hat, kann er an die
anderen GGSNs eine Anforderung richten, einen neuen Anker zu wählen, und
er selbst kann nach der Bestätigung,
dass ein neuer Anker-GGSN gewählt
worden ist, die MC-Gruppe verlassen.
-
Zur
Fehlerbehebung prüfen
alle empfangenden GGSNs ihre eigenen Tabellen für die Multicastgruppe und die
TLMG. Falls mehrere GGSNs dieselbe Multicastgruppe bedienen, können alle
GGSNs, welche nicht Anker-GGSN für
diese Multicastgruppe sind, die TLMG freigeben oder "stummschalten" (kein Weiterleiten
von Paketen aus dem Internet).
-
Ein
GGSN kann in Abhängigkeit
vom Ergebnis der Abfrage auch entscheiden, eine neue TLMG zu erzeugen.
Dies ist insbesondere der Fall, wenn er als neuer Anker-GGSN gewählt wird.
Einige Regeln können
die Wahl des Betreibers widerspiegeln, welcher GGSN welche MS-Gruppe
bedienen soll.