-
GEBIET DER
ERFINDUNG
-
Die
vorliegende Erfindung betrifft ein Verfahren zur Implementierung
von MBMS (Multimedia Broadcast Multicast Service bzw. Multimedienrundfunk-Multicast-Dienst)
in drahtlosen Kommunikationssystemen, insbesondere ein Verfahren
zur Implementierung von Iu-Flex-gestütztem MBMS.
-
HINTERGRUND
DER ERFINDUNG
-
Multicast
ist ein Verfahren zum Senden von Daten von einer Quelle an viele
Bestimmungsorte. Mit Multicast können
die gleichen Daten durch lediglich einmaliges Senden an viele Teilnehmer
gesendet werden, wodurch Netzwerkressourcen gespart werden können. Gemäß dem 3GPP-Standard
kann ein Knoten in einem drahtlosen Zugangsnetzwerk mit Iu-Flex-Technologie
mit einer Vielzahl von zentralen Netzwerkknoten verbunden sein.
Zum Beispiel kann ein Funknetzwerk-Controller (RNC) des Allgemeinen Paketfunkdienstes
(GPRS) oder ein Basisstationscontroller (BSC) des Universellen Mobilen
Telekommunikationssystems (UMTS) mit einer Vielzahl von Serving-GPRS-Unterstützungsknoten
(SGSN) verbunden sein. Auf diese Weise kann es sein, wenn MBMS in
einer Iu-Flex-gestützten
Umgebung implementiert wird, daß MBMS-Verkehr
von einer Vielzahl von SGSN an den gleichen RNC gesendet wird, was zu
einer Verschwendung von Netzwerkbandbreiten-Ressourcen führt. Um
dieses Problem zu lösen, sind
viele Verfahren zur Implementierung von MBMS in Iu-Flex-gestützte Netzwerkumgebungen
vorgeschlagen worden.
-
Das
erste Verfahren nutzt einen vorgegebenen SGSN, das heißt, während des
Vorgangs der Aktivierung oder Umadressierung bzw. Vermittlung eines
Multicast-Verkehrs bestimmt der RNC, ob ein Multicast-Verkehr eingerichtet
werden soll oder ob der Multicast-Verkehr in einen bestehenden Multicast-Verkehr eingefügt werden
soll. Um sicherzustellen, daß der
RNC Multicast-Verkehr von lediglich einem SGSN empfängt, bestimmt
der RNC einen "vorgegebenen
SGSN", der verwendet
wird, um einen Kanal für
Multicast-Verkehrsströme
im voraus einzurichten. Gleichzeitig richtet der RNC eine RAB-Verbindung
zu den SGSN ein, bei denen die Teilnehmer registriert sind, um die
Signalverbindungen aufrecht zu erhalten. Jedoch kann das Verfahren
zu Schwierigkeiten bei der verkehrsbezogenen Abrechnung führen, weil
die SGSN, bei denen die Teilnehmer registriert sind, das über den "vorgegebenen SGSN" gesendeten Datenvolumen
nicht "kennen".
-
Das
zweite Verfahren besteht darin, die SGSN zu umgehen. Bei diesem
Verfahren nehmen die SGSN am Wechsel der Multicast-Signale teil, aber
die GGSN senden Multicast-Verkehr ohne Beteiligung der SGSN direkt
an den RNC. Weil RNC Verbindungen zu GGSN herstellen können, wird
die interne Struktur des Netzwerks offengelegt, wenn Teilnehmer
einen Verkehrsbereichswechsel zwischen GGSN und SGSN durchführen, was
zu Netzwerksicherheitsproblemen führt. Gleichzeitig kann das
Verfahren auch zu Schwierigkeiten bei der verkehrsbezogenen Abrechnung
führen,
weil die SGSN, bei denen die Teilnehmer registriert sind, das über den "vorgegebenen SGSN" gesendeten Datenvolumen
nicht "kennen".
-
Das
dritte Verfahren besteht darin, den RNC einen aus den Multicast-Verkehren
auszuwählen.
Bei diesem Verfahren empfängt
der RNC weiterhin Datenströme
von SGSN, aber er wählt
einen von ihnen aus und leitet ihn an Multicast-Teilnehmer weiter.
Der Nachteil dieses Verfahrens besteht darin, daß Netzwerkressourcen nicht
effektiv genutzt werden können.
-
Das
vierte Verfahren besteht darin, den RNC eine einzige Verbindung
zu einem der SGSN verwenden zu lassen. Bei diesem Verfahren stellt
der RNC, wenn die MBMS-Datenübertragung
beginnt und der RNC Sendeanforderungen von vielen SGSN detektiert,
Verbindungen zu individuellen SGSN her, richtet aber nur einen Multicast-RAB
zu einem der SGSN ein, und es wird kein TAB zwischen dem RNC und anderen
SGSN eingerichtet, aber andere SGSN können Multicast-Verkehr von
GGSN empfangen und verkehrsbezogene Abrechnungsinformation für spezifische
Teilnehmer erzeugen. Auch wenn in einer Iu-Flex-gestützten Umgebung
eine Vielzahl von Teilnehmern in der gleichen Multicast-Teilnehmergruppe mit
dem gleichen RNC verbunden ist, können sie gleichzeitig durch
eine Vielzahl von SGSN versorgt werden. In diesem Fall sollten die
MBMS-Nachrichtenparameter an den SGSN identisch sein. Jedoch erhöhen die
Synchronisation zwischen den SGSN und die Parameterkonsistenz die
Komplexität
der Steuerung und verschlechtern die Verarbeitungseffizienz.
-
Die
oben genannten vier Lösungen
sind in "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; Multimedia Broadcast/Multicast
Service; Architecture and Functional Description (Release 5) 3GPPTR
23.846 0.3.0 (2002-04-02)" ausführlich beschrieben.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Die
vorliegende Erfindung stellt ein einfaches und zuverlässiges Verfahren
zur Implementierung von Iu-Flex-gestütztem MBMS bereit, das den Verbrauch
von Netzwerkressourcen verringert und zur Netzwerksicherheit und
Abrechnungsverwaltung beiträgt.
-
Um
diese Aufgabe zu lösen,
stellt die Erfindung ein Verfahren zur Implementierung von Iu-Flex-gestütztem MBMS
bereit, wie in Anspruch 1 dargelegt. Bevorzugte Merkmale sind in
den Ansprüchen
2 bis 8 dargelegt.
-
In
der vorliegenden Erfindung wählt
der RNC einen der SGSN als einen primären SGSN aus und nimmt den
RAB zwischen dem primären
SGSN und sich selbst als einen primären Weg zum Empfang von Multicast-Verkehr
und wählt
andere SGSN als sekundäre
SGSN und erhält
die RAB-Verbindungen zu den sekundären SGSN aufrecht. Im Vergleich
zum herkömmlichen
Verfahren 1 führt
das Verfahren nicht zu Schwierigkeiten bei der Abrechnungsverwaltung, weil
der RNC andere SGSN als sekundäre
SGSN nimmt und die RAB-Verbindungen zu den sekundären SGSN
aufrecht erhält;
im Vergleich zum Verfahren 2 führt
das Verfahren nicht zu Netzwerksicherheitsproblemen und erleichtert
die Abrechnungsverwaltung, weil es keine Notwendigkeit gibt, die
interne Struktur des Netzwerks offenzulegen, wenn Multicast-Verkehr übertragen
wird; im Vergleich zum Verfahren 3 verringert das Verfahren die
Verschwendung von Übertragungsressourcen,
weil es vor allem den primären
SGSN nutzt, um Multicast-Verkehr zu verteilen; im Vergleich zum
Verfahren 4 führt
das Verfahren zu keiner Inkonsistenz von Multicast-Parametern zwischen
den SGSN, und somit kann das System einfach und zuverlässig implementiert
werden. Folglich verringert das Verfahren nicht nur den Verbrauch
von Netzwerkressourcen, sondern macht auch den Multicast-Dienst
einfach und zuverlässig sowie
verbessert die Netzwerksicherheit und die Abrechnungsverwaltung.
-
KURZBESCHREIBUNG
DER ZEICHNUNGEN
-
1 ist
der Ablaufplan einer Ausführungsform
eines Verfahrens gemäß der vorliegenden
Erfindung.
-
2 ist
die Strukturdarstellung des Universellen Mobilen Telekommunikationssystems
in der vorliegenden Erfindung.
-
3 ist
die schematische Darstellung der RNC-Verbindung in der vorliegenden
Erfindung.
-
4 ist
der Ablaufplan der Einrichtung eines Multicast-RAB; und
-
5 ist
der Ablaufplan des Wechsels eines Multicast-RAB.
-
AUSFÜHRLICHE BESCHREIBUNG DER ZEICHNUNGEN
-
Die
vorliegende Erfindung wird anhand der Zeichnungen und der folgenden
Ausführungsform ausführlicher
beschrieben.
-
2 ist
die Strukturdarstellung des Universellen Mobilen Telekommunikationssystems
in der vorliegenden Erfindung. Gemäß 2 ist Benutzereinrichtung
(UE) ein Oberbegriff für
mobile Endgeräte im
UMTS-Netzwerk. Mobilstation (MS) ist ein Oberbegriff für mobile
Endgeräte
im GPRS-Netzwerk; ebenso sind Funknetzwerksystem (RNS) und Basisstationssystem
(BSS) Teil der drahtlosen Zugangsnetzwerke von UMTS- bzw. GPRS-Netzwerken. SGSN
(Serving-GPRS-Unterstützungsknoten)
führen
verschiedene Dienststeuerungs- und Mobilitätsverwaltungsfunktionen für Multicast-Verkehr
durch und leiten Multicast-Verkehr von GGSN (Gateway-GPRS-Unterstützungsknoten)
an relevante RNS oder BSS weiter. GGSN sind dafür zuständig, Kontakt zu internen bzw.
externen Multicast-Verkehrsquellen herzustellen und leiten Daten
von Multicast-Verkehrsquellen weiter. Das Multicast-Verkehrszentrum
ist ebenfalls eine Multicast-Verkehrsquelle. Anders als andere Multicast-Verkehrsquellen kann
das Multicast-Dienstzentrum
Multicast-Verkehr von Inhaltsanbietern ordnen und verwalten sowie
Authentifizierungs- und Abrechnungsdienste für Inhaltsanbieter bereitstellen.
Das Grenz-Gateway steuert die Datenübertragung von externen Netzwerken. Zum
Beispiel regelt das Grenz-Gateway, daß nur den Daten von bestimmten
spezifischen Adressen oder gewissen spezifischen Ports gestattet
wird, in das Mobilfunk-Netzwerk einzutreten. Das Abrechnungs-Gateway
ist dafür
zuständig,
Multicast-Abrechnungsdatensätze
zu sammeln, sie zu verarbeiten und dann die verarbeiteten Datensätze an das Abrechnungszentrum
zu senden. Heimatdateien (HLR) speichern Registrierungsinformation
und Routeninformation für
registrierte Multicast-Teilnehmer. Inhaltsanbieter senden Multicast-Verkehr
zur Rundsendung von Multicast-Verkehr an das Multicast-Verkehrszentrum,
das den Multicast-Verkehr an individuelle GGSN verteilt. GGSN senden
den Multicast-Verkehr an SGSN über
eingerichtete Multicast-Verbindungen. SGSN senden den Multicast-Verkehr
an Multicast-Teilnehmer über
geeignete drahtlose Verbindungen (zum Beispiel Punkt-zu-Punkt-Verbindung oder
Punkt-zu-Mehrpunkt-Verbindung) in den drahtlosen Zugangsnetzwerken.
-
Für den ausführlichen
Implementierungsvorgang der vorliegenden Erfindung in einem Iu-Flex-gestützten Netzwerk
wird auf 1 Bezug genommen. Gemäß 1 sendet
ein SGSN, wenn er den Multicast-Dienst implementiert, in Schritt 1 eine
Anforderung zur Einrichtung einer RAB-Verbindung für Multicast-Dienst
an den RNC, und der RNC richtet einen entsprechenden Multicast-RAB
zwischen dem RNC und dem SGSN gemäß der Anforderung ein und empfängt einen
Multicast-Verkehrsstrom von diesem SGSN. Während des Empfangsvorgangs
detektiert der RNC in Schritt 2 Multicast-Verkehrsströme von unterschiedlichen
mit ihm verbundenen SGSN. Dann bestimmt der RNC in Schritt 3,
ob viele Multicast-Verkehrsströme dem gleichen
Multicast-Dienst entsprechen. Wenn der RNC herausfindet, daß das Phänomen, daß viele
Multicast-Verkehrsströme
dem gleichen Multicast-Dienst entsprechen, nicht existiert, erfolgt
ein Übergang
zu Schritt 5, um die Übertragung
des Multicast-Verkehrs fortzusetzen; wenn der RNC herausfindet,
daß viele Multicast-Verkehrsströme dem gleichen
Multicast-Dienst entsprechen, geht die Verarbeitung weiter zu Schritt 4.
In Schritt 4 wählt
der RNC einen der SGSN als einen primären SGSN aus und nimmt den RAB
zwischen dem primären
SGSN und sich selbst als einen primären Weg; gleichzeitig wählt er andere SGSN
als sekundäre
SGSN und erhält
die RAB-Verbindungen zu ihnen aufrecht, wobei nur ein minimales
Datenvolumen oder ein Null-Datenvolumen von den sekundären SGSN
gesendet wird, um die Verbindungen zwischen dem RNC und den sekundären SGSN
aufrecht zu erhalten. Für
das Prinzip von Multicastverkehr-Übertragungswegen siehe 3,
worin die dünnen
durchgezogenen Linien Befehls-Übertragungsstrecken
darstellen, die dicken durchgezogenen Linien die primären RAB-Übertragungsstrecken und Multicast-Datenströme darstellen
und die punktierten Linien sekundäre RAB-Übertragungsstrecken
darstellen.
-
Um
die Menge der Datenpakete zu verringern, die von SGSN an den RNC
gesendet werden, können
die folgenden Betriebsarten für
die sekundären
SGSN verwendet werden:
- 1) Der RNC stimmt mit
den sekundären
SGSN ein Begrenzungskriterium ab. Innerhalb der Begrenzung beenden
die sekundären
SGSN die Weiterleitung von Multicast-Datenpaketen an den RNC. Wenn
die Begrenzung überschritten
wird, senden die sekundären
SGSN wieder aktuelle Multicast-Datenpakete
am den RNC. Danach können der
RNC und die sekundären
SGSN sich erneut abstimmen, um ein neues Begrenzungskriterium zu
bestimmen, das ein Zeitbedarf, eine Begrenzung des Datenvolumens
oder Forderung nach Dienstumgebungsbedingungen (zum Beispiel Dienstgüte) und
so weiter sein kann. Zum Beispiel umfassen die Datenpakete weniger
als 10.000 IP-Pakete innerhalb einer Stunde. Wenn es keine Begrenzung
von Zeit und Datenvolumen gibt, leiten die SGSN keine Multicast-Datenpakete
an den RNC weiter.
- 2) Wenn die sekundären
SGSN Multicast-Verkehr an den RNC senden, senden sie nur komprimierte Nachrichten.
Nach dem Empfang der komprimierten Nachrichten kann der RNC die
Kontinuität,
Integrität
und Korrektheit des Multicast-Datenstroms bestimmen.
- 3) In Kombination mit dem Verfahren 1) und dem Verfahren 2)
stimmt der RNC mit den sekundären SGSN
ein Begrenzungskriterium ab. Innerhalb der Begrenzung senden die
sekundären
SGSN komprimierte Nachrichten in bezog auf Multicast-Datenpakete.
Wenn die Begrenzung überschritten
wird, senden die sekundären
SGSN wieder aktuelle Multicast-Datenpakete an den RNC. Danach können der
RNC und die sekundären SGSN
sich erneut abstimmen, um ein neues Begrenzungskriterium zu bestimmen,
das ein Zeitbedarf, eine Begrenzung des Datenvolumens oder eine
Forderung nach Dienstumgebungsbedingungen (zum Beispiel Dienstgüte) und
so weiter sein kann.
- 4) Der RNC stimmt sich mit den sekundären SGSN ab, um eine spezifische
Zeit oder die Menge der Datenpakete als die Handshake-Periodizität zu bestimmen,
die aber auch durch den Bediener konfiguriert werden kann. Normalerweise
senden die sekundären
SGSN keinen Multicast-Verkehr an den RNC. Sie senden jedoch in bestimmten
Zeitabständen
oder nach jeder bestimmten Menge von Datenpaketen wenige Multicast-Datenpakete
oder komprimierte Multicast-Datenpakete oder RAB-Statusmeldungen an den RNC, um die RAB-Verbindungen
zum RNC aufrecht zu erhalten.
-
Man
beachte, daß die
Betriebsarten von 1) bis 4) abwechselnd oder in Kombination verwendet werden
können.
-
Während des
Multicast-Verkehrsübertragungsvorgangs
in Schritt 5 bestimmt der RNC auch, ob der primäre SGSN
gewechselt werden soll, und wenn ja, wählt er einen der sekundären SGSN
als einen primären
SGSN aus, und dann empfängt
der RNC Multicast-Verkehr über
den RAB zwischen dem neuen primären
SGSN und sich selbst und erhält gleichzeitig
die Verbindungen zu den sekundären SGSN
aufrecht.
-
Dieser
Wechsel des primären
SGSN durch den RNC kann durchgeführt
werden, wenn der primäre
RAB zwischen dem RNC und dem primären SGSN aus bestimmten Gründen freigegeben
werden muß (zum
Beispiel melden sich Multicast-Teilnehmer ab oder Vermittlungsstellen
oder Übertragungsstrecken
fallen aus), das heißt,
der RNC wählt
einen Weg von den sekundären
SGSN als den neuen Empfangsweg aus, informiert den neuen primären SGSN, daß er Multicast-Verkehr
senden soll, und erhält gleichzeitig
die Verbindungen zu anderen sekundären SGSN aufrecht.
-
Dieser
Wechsel des primären
SGSN durch den RNC kann auch durchgeführt werden, wenn der SGSN,
der keine RAB-Verbindung zum RNC eingerichtet hat, eine RAB-Anforderung
an den RNC auslöst.
Wenn ein neuer SGSN eine RAB-Anforderung an den RNC auslöst, kann
sich der Betriebszustand des Netzwerks ändern, zum Beispiel kann es
sein, daß die
Last auf der ursprünglichen
RAB-Verbindungsstrecke
nicht mehr optimal ist. In diesem Fall sollten der primäre SGSN
und der primäre
RAB gewechselt werden. Somit kann der RNC dem primären RAB
seine Einstufung entziehen und einen sekundären RAB zum primären RAB
befördern,
und der RNC empfängt
Multicast-Verkehr vom neuen primären RAB.
-
Die
Grundlage für
die Wahl eines Empfangsweges durch den RNC kann eine zufällige Auswahl oder
eine wohlüberlegte
Auswahl aus den sekundären
SGSN durch den RNC hinsichtlich der Rangfolge der Empfangswege,
der Qualität
der Übertragungsstrecken,
der Last auf den Übertragungsstrecken, der
Rangfolge der Einrichtung von RAB, der Forderungen von SGSN nach
Multicast-Dienstgüte
und so weiter sein.
-
Bevor
der RNC den primären
Empfangsweg bestimmt, sollte er die Dienstgüte-Forderungen an einen Multicast-RAB
mit den individuellen SGSN abstimmen oder erneut abstimmen, um sicherzustellen, daß der Multicast-RAB
auf dem primären
Empfangsweg alle Forderungen des primären SGSN und der sekundären SGSN
erfüllt.
-
Während des Übertragungsvorgangs
des Multicast-Verkehrs leiten die sekundären SGSN Datenpakete nicht
weiter oder leiten nur komprimierte Nachrichten weiter, wenn die
Menge der vom GGSN durch den SGSN empfangenen Datenpakete das Begrenzungskriterium
nicht überschreitet
und eingeschätzt
wird, daß der
RNC den Multicast-Verkehr bereits empfangen hat. Auf dieser Grundlage
berechnet der SGSN die Multicast-Verkehrsströme, die an Multicast-Teilnehmer
weitergeleitet werden. Die komprimierten Nachrichten sind sehr kurze
Nachrichten, wie etwa Zusammenfassung von Multicast-Datenpaketen, IP-Paketköpfe, Paketnummern
von Multicast-Datenpaketen oder eine Paketnummernliste und so weiter.
Die Aufgabe des kontinuierlichen Sendens von komprimierten Nachrichten
von den sekundären
SGSN an den RNC besteht darin, die Verbindungen zwischen ihnen aufrecht
zu erhalten sowie das Gesamt-Datenvolumen zu verringern. Wenn die sekundären SGSN
keine Multicast-Datenpakete senden oder nur komprimierte Nachrichten
an den RNC senden, kann der RNC eine statistische Meldung über die
vom primären
SGSN empfangenen Multicast-Datenpakete an die sekundären SGSN
senden, zum Beispiel das vom primären SGSN empfangene Multicast-Verkehrsvolumen
und das über
die Luftschnittstelle gesendete Multicast-Verkehrsvolumen und so
weiter.
-
Die
vorliegende Erfindung wird nachstehend ausführlicher anhand des Vorgangs
der Einrichtung eines Multicast-RAB und des Vorgangs des Wechsels
eines Multicast-RAB beschrieben.
-
4 ist
der Ablaufplan zur Einrichtung eines Multicast-RAB. In 4 hat
der RNC eine RAB-Verbindung
für den
Multicast-Dienst A zum SGSN1 eingerichtet. Zu diesem Zeitpunkt fordert
der SGSN2 die Einrichtung einer neuen RAB-Verbindung für den Multicast-Dienst
A zum RNC an. Die Schritte werden wie folgt beschrieben:
In
Schritt 11 löst
der SGSN2 eine Anforderung zur Einrichtung einer neuen RAB-Verbindung
zum RNC aus, und die Anforderung weist die Dienstgüte-Forderungen
an den Multicast-Dienst A, eine Kennung zur Identifizierung des
Multicast-Dienstes A für
das Zugangsnetzwerk und Iu-Schnittstellenparameter und so weiter
auf;
in Schritt 12 empfängt der RNC die Anforderung
zur Einrichtung einer RAB-Verbindung und richtet eine Iu-Schnittstellen-Übertragungsstrecke
zum SGSN2 ein;
in Schritt 13 prüft der RNC die RAB-Verbindung
für den
Multicast-Dienst A zum SGSN1 entsprechend der Kennung des Multicast-Dienstes
A und bestimmt dann, ob der primäre
SGSN gewechselt werden soll; angenommen, daß bestimmt wird, den primären SGSN
nicht zu wechseln, geht der RNC zu Schritt 14 weiter;
in
Schritt 14 sendet der RNC eine Antwort auf die Anforderung
zur Einrichtung einer RAB-Verbindung
an den SGSN2, um mitzuteilen, daß der Multicast-RAB eingerichtet
worden ist, und um mitzuteilen, daß es nicht nötig ist,
den Multicast-Verkehr über
die Iu-Verbindung weiterzuleiten. Die Antwortnachricht umfaßt die Konfiguration
der Dienstgüte-Parameter
für den Multicast-Dienst
A, die Iu-Schnittstellenparameter, die
Parameter für
die Weiterleitung des Multicast-Verkehrs (zum Beispiel Handshake-Zeitintervall Δt, das Format
der komprimierten Nachrichten und so weiter);
in Schritt 15 sendet
der SGSN2 einmal pro Δt
eine Statusnachricht an den RNC. Die Statusnachricht umfaßt: die
Menge der nicht durch den SGSN an den RNC weitergeleiteten Multicast-Datenpakete, die
Seriennummer des aktuellen Datenpakets, das darauf wartet, an den
RNC gesendet zu werden, und so weiter;
in Schritt 16 prüft der RNC,
ob die durch den SGSN2 gesendete Statusnachricht mit der Nachricht
des Multicast-Dienstes A übereinstimmt.
Wenn nicht, meldet der RNC seinen aktuellen Status an den SGSN2;
wenn ja, sendet der RNC eine Statusanweisung und informiert den
SGSN2, daß er
den aktuellen Status beibehält;
in
Schritt 17 sendet der RNC in spezifischen Zeitabständen eine
statistische Nachricht an den SGSN1 und den SGSN2, um das Volumen
des vom SGSN1 bzw. vom SGSN2 empfangenen Multicast-Verkehrs und das
Volumen des über
die Luftschnittstelle gesendeten Multicast-Verkehrs zu melden;
in
Schritt 18 führen
der SGSN1 und der SGSN2 die Abrechnung für Multicast-Teilnehmer entsprechend dem
Volumen des Multicast-Verkehrs, der Dienstgüte und anderer Information
durch.
-
5 ist
der Ablaufplan zum Wechsel des Multicast-RAB, wobei der RNC eine
RAB-Verbindung für
den Multicast-Dienst A zum SGSN1 eingerichtet hat. Zu diesem Zeitpunkt
fordert der SGSN2 die Einrichtung einer neuen RAB-Verbindung für den Multicast-Dienst
A zum RNC an. Die Schritte werden wie folgt beschrieben:
In
Schritt 21 löst
der SGSN2 eine Anforderung zur Einrichtung einer neuen RAB-Verbindung
zum RNC aus, und die Anforderung weist die Dienstgüte-Erfordernisse
für den
Multicast-Dienst A, eine Kennung zur Identifizierung des Multicast-Dienstes
A für das Zugangsnetzwerk
und In-Schnittstellenparameter und so weiter auf;
in Schritt 22 empfängt der
RNC die Anforderung zur Einrichtung einer RAB-Verbindung und richtet
eine Iu-Schnittstellen-Übertragungsstrecke
zum SGSN2 ein;
in Schritt 23 sendet der RNC eine Antwort
auf die Anforderung zur Einrichtung einer RAB-Verbindung an den SGSN2, um mitzuteilen,
daß der
Multicast-RAB eingerichtet worden ist. Die Antwortnachricht umfaßt die Konfiguration
der Dienstgüte-Parameter
für den Multicast-Dienst
A, die Iu-Schnittstellenparameter und
so weiter;
in Schritt 24 prüft der RNC die RAB-Verbindung
für den
Multicast-Dienst A zum SGSN1 entsprechend der Kennung des Multicast-Dienstes
A und bestimmt dann, ob der primäre
SGSN gewechselt werden soll; angenommen, daß bestimmt wird, den primären SGSN
zu wechseln, wählt
der RNC den SGSN2 als den primären
SGSN und den RAB zum SGSN2 als den primären Empfangsweg aus, dann schreitet
er zu Schritt 25 fort;
in Schritt 25 empfängt der
RNC Multicast-Verkehr vom SGSN2 und teilt dem SGSN1 mit, keinen
Multicast-Verkehr weiterzuleiten. Die Anweisungsnachricht umfaßt die Parameter
für die
Weiterleitung des Multicast-Verkehrs (zum Beispiel Handshake-Zeitintervall Δt, das Format
der komprimierten Nachrichten und so weiter);
in Schritt 26 sendet
der SGSN1 einmal pro Δt
eine komprimierte Nachricht für
das aktuelle Multicast-Datenpaket an den RNC. Die komprimierte Nachricht umfaßt: IP-Paketköpfe und
Seriennummern der aktuellen IP-Multicast-Datenpakete und so weiter;
in
Schritt 27 prüft
der RNC, ob die durch den SGSN1 gesendete Statusnachricht mit der
Nachricht des Multicast-Dienstes A übereinstimmt. Wenn nicht, meldet
der RNC seinen aktuellen Status an den SGSN2; wenn ja, sendet der
RNC eine Statusanweisung und informiert den SGSN2, daß er den
aktuellen Status beibehält;
in
Schritt 28 sendet der RNC in spezifischen Zeitabständen eine
statistische Nachricht an den SGSN1 und den SGSN2, um das Volumen
des vom SGSN1 bzw. vom SGSN2 empfangenen Multicast-Verkehrs und das
Volumen des über
die Luftschnittstelle gesendeten Multicast-Verkehrs zu melden;
in
Schritt 29 führen
der SGSN1 und der SGSN2 die Abrechnung für Multicast-Teilnehmer entsprechend dem
Volumen des Multicast-Verkehrs, der Dienstgüte und anderer Information
durch.