DE10246680A1

DE10246680A1 - Multicasting-Verwaltungsmechanismus für Mobilnetze

Info

Publication number: DE10246680A1
Application number: DE10246680A
Authority: DE
Inventors: Yi-Bing Lin; Ai-Chun Pang; Chun-Shiow Chen; Vincent Feng
Original assignee: Industrial Technology Research Institute ITRI
Current assignee: Industrial Technology Research Institute ITRI
Priority date: 2002-03-15
Filing date: 2002-10-07
Publication date: 2003-10-09
Anticipated expiration: 2022-10-08
Also published as: US20040203756A1; US7058413B2; DE10246680B4; TW589907B

Abstract

Es wird ein Multicasting-Verwaltungsmechanismus für Mobilnetze angegeben. Gemäß diesem Mechanismus wird eine Vorgehensweise mit einer Multicastingtabelle vorgeschlagen, um die Anzahl von Kurzmeldungen und Multimediameldungen beträchtlich zu verringern, wie sie an ein Dienstgebiet gesendet werden, um dadurch die Funkrufkosten zu senken. Zum Multicasting-Verwaltungsmechanismus für Mobilnetze gehören die folgenden Schritte: Erstellen einer VLR-Datensatztabelle in einem Heimatortsregister (HLR) zum Aufzeichnen von für Multicastingbenutzer lokalisierten VLR-Adressen sowie der Gesamtanzahl von Multicastingbenutzern in jedem VLR und Erstellen von LA-Tabellen zum Aufzeichnen von LA-Adressen in jedem VLR und der Gesamtanzahl von Multicastingbenutzern in jedem LA.

Description

HINTERGRUND DER ERFINDUNG

Gebiet der Erfindung

Die Erfindung betrifft das Gebiet der Mobilnetzverwaltung, insbesondere einen Multicasting (gleichzeitige Benachrichtigung mehrerer - jedoch nicht aller - Netzteilnehmer)-Verwaltungsmechanismus für Mobilnetze, wobei eine Vorgehensweise mit einer Multicastingtabelle vorgeschlagen wird, um Multicasting mit minimierten Funkrufkosten zu unterstützen.

Beschreibung der einschlägigen Technik

Gemäß der Spezifikation 3GPP 43.068 sorgt das Global System für Mobile Communications oder das Universal Mobile Telecommunications System (GSM/UMTS) für einen Sprach-Gruppenanrufdienst mittels eines Rundübertragungsnechanismus. Genauer gesagt, erfolgt ein Funkruf für alle Dienstgebiete, wenn ein Sprachanruf bedient wird. Gemäß der Fig. 1 ist ein GSM/UMTS-Dienstgebiet in mehrere lokale Gebiete (LAs), wie LA1-LA3, LA4-LA6 oder LA7-LA8, unterteilt, und es kommuniziert mit einer Mobilvermittlungszentrale (MSC = Mobile- Switching Center), wie 40, 60 oder 80, mit einem jeweiligen Besucherortsregister (VLR = Visitor Location Register), wie 50, 70 oder 90. Die restlichen Nummern in der Fig. 1 werden später beschrieben. Wie es in der Fig. 1 dargestellt ist, wird bei einem typischen GSM/UMTS (wie im Kapitel 8 der spezifikation 3GPP TS 09.02 angegeben) ein Funkruf für alle Dienstgebiete selbst dann ausgeführt (Schritt S), wenn die Standortgebiete LA2, LA4, LA5, LA7 und LA8 keinerlei Multicastingbenutzer, wie 100-103, enthalten. Außerdem erfolgt, wie es in der Fig. 2 dargestellt ist, Multicasting bei iSMS (angegeben in "iSMS: An Integration Platform for Short Message Service and IP Networks", IEEE Network, März/April 2001, Herman Chung-Hwa Rao, Di-Fa Chang und Yi-Bing Lin) durch Senden jeder Meldung an individuelle Benutzer in einer Multicastingliste. Dadurch kann vermieden werden, dass Meldungen an ein Standortgebiet ohne Multicastingbenutzer, wie in der Fig. 1 dargestellt, geliefert werden. Wenn sich jedoch n Benutzer in einem Dienstgebiet befinden, wird dieselbe Meldung n Mal an dieses Dienstgebiet gesendet. Zum Beispiel wird dieselbe Meldung zwei Mal an das Standortgebiet LA1 für die Benutzer 100 und 101 gesendet. Die restlichen Nummern werden später beschrieben. Es ist deutlich erkennbar, dass die zwei obigen Vorgehensweisen nicht effektiv sind. Weder existierende 2G-Systeme mit Sprachfunktionen noch existierende 3G-Systeme mit Multimediafunktion können effizientes Multicasting unterstützen.

ZUSAMMENFASSUNG DER ERFINDUNG

Demgemäß ist es eine Aufgabe der Erfindung, einen Multicasting-Verwaltungsmechanismus für Mobilnetze zu schaffen, der für effizienten Multicastingdienst bei GSM/UMTS sorgt, ohne dass die standardmäßigen Ortsaktualisierungsmeldungen zu modifizieren wären.
Eine andere Aufgabe der Erfindung ist es, einen Multicasting-Mechanismus für Mobilnetze zu schaffen, der eine Vorgehensweise mit einer Multicastingtabelle vorschlägt, um eine bestimmte Anzahl von Kurzmeldungen und Multimediameldungen, die an ein Dienstgebiet gesendet werden, zu verringern.
Durch die Erfindung ist ein Multicasting-Verwaltungsmechanismus für Mobilnetze vorgeschlagen, zu dem Folgendes gehört: Erstellen einer VLR-Aufzeichnungstabelle in einem Heimatortsregister (HLR = Home Location Register), um für Multicastingbenutzer lokalisierte VLR-Adressen an die Gesamtanzahl von Multicastingbenutzern in jedem VLR aufzuzeichnen; und Erstellen von LA-Tabellen in VLRs, um die LA-Adressen in jedem VLR und die Gesamtanzahl von Multicastingbenutzern in jedem LA aufzuzeichnen.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 ist ein schematisches Diagramm eines typischen Multicastingverfahrens für eine GSM/UMTS-Konfiguration;
Fig. 2 ist ein schematisches Diagramm eines anderen typischen Multicastingverfahrens für die GSM/UMTS-Konfiguration der Fig. 1;
Fig. 3 ist ein schematisches Diagramm eines erfindungsgemäßen Multicastingverfahrens für die GSM/UMTS-Konfiguration der Fig. 1;
Fig. 4 ist ein Flussdiagramm einer Registrierung, wie sie für einen Multicastingbenutzer aus einem Dienstgebiet in ein anderes gemäß der Erfindung ausgeführt wird;
Fig. 5a ist ein Vergleichsdiagramm für die Multicastingverfahren gemäß den Fig. 1 und 3;
Fig. 5b ist ein Vergleichsdiagramm für die Multicastingverfahren gemäß den Fig. 2 und 3; und
Fig. 6 ist ein Flussdiagramm eines Multicasting-Verwaltungsmechanismus gemäß der Erfindung.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG

Die folgenden Zahlen bezeichnen in der ganzen Beschreibung und allen Zeichnungen dieselben Elemente.
Der erfindungsgemäße Multicasting-Verwaltungsmechanismus kann dazu verwendet werden, Kurzmeldungen oder Multimediameldungen zuzustellen. Bei UMTS werden Kurzmeldungen über die Steuerebene der leitungsvermittelten Domäne zugestellt, während die Mediameldungen über die Benutzerebene der paketvermittelten Domäne zugestellt werden. Gemäß den GSM-Erfordernissen ist die Anwendung der Erfindung im Wesentlichen dieselbe wie beim folgenden Erläuterungsbeispiel für die Zustellung einer Kurzmeldung über die leitungsvermittelte Domäne gemäß den UMTS-Erfordernissen.
Ein UMTS-Netz verfolgt die Standorte von Mobilstationen (MSs), so dass eintreffende Anrufe an die Teilnehmer zugestellt werden können. Um eine Standortverfolgung auszuführen, ist ein UMTS-Dienstgebiet in mehrere LAs unterteilt.
Jedes LA besteht aus einer Gruppe von Basisstationen (nicht dargestellt), die über eine Funkstrecke mit den MSs (wie 100-103 in den Fig. 1 und 2) kommunizieren. Die Hauptaufgabe der Mobilitätsverwaltung besteht darin, den Standort einer MS zu aktualisieren, wenn sie sich aus einem LA in ein anderes bewegt. Die Standortinformation wird in der UMTS- Mobilitätsdatenbank, wie im HLR (wie 30 in den Fig. 1 und 2) und in VLR(s) (wie 50, 70 und 90 in den Fig. 1 und 2) gespeichert. Jedes VLR hält die Information für eine Gruppe von LAs aufrecht.
Die Fig. 3 ist ein schematisches Diagramm eines erfindungsgemäßen Multicastingverfahrens. Gemäß der Fig. 3 nutzt das Multicastingverfahren die existierende GSM/UMTS-Kurzmeldungsarchitektur gemäß der Fig. 1. Zu die ser Architektur gehören eine Kurzmeldungs-Dienstzentrale (SM-SC = Short Message-Service Center) 10, die auf einem Host (nicht dargestellt) realisiert ist, eine Kurzmeldungsdienst-Knotenmobilvermittlungszentrale (SMS GMSC = Short Message Service Gateway Mobile Switching Center) 20, die auf dem Host oder einem anderen Computer (nicht dargestellt) realisiert ist, ein Heimatortsregister (HLR) 30, das auf dem Host oder einem anderen Computer (nicht dargestellt) realisiert ist, mehrere Mobilvermittlungszentralen (MSCs = Mobile Switching Centers) 40, 60 und 80, die auf dem Host oder einem anderen Computer (nicht dargestellt) realisiert sind, mehrere Besucherortsregister (VLRs = Visitor Location Registers) 50, 70 und 90, die auf dem Host oder einem anderen Computer (nicht dargestellt) realisiert sind, sowie mehrere Standortgebiete (LAs) LA1-LA8.
Wie es in der Fig. 3 dargestellt ist, überdeckt das VLR 50 die LAs LA1-LA3. Das VLR 70 überdeckt die LAs LA4-LA6. Das VLR 90 überdeckt die LAs LA7-LA8. Bevor durch die SM- SC 10 Multicastingmeldungen ausgegeben werden, erstellt der erfindungsgemäße Multicasting-Verwaltungsmechanismus Multicastingtabellen im HLR und in jedem VLR. Die Multicastingtabelle wird dadurch realisiert, dass in einem Heimatortsregister (HLR) eine VLR-Datensatztabelle (die als Aufzeichnungs-MC_H) bezeichnet wird, erstellt wird, um für Multicastingbenutzer lokalisierte VLR-Adressen und die Gesamtanzahl der Multicastingbenutzer in jeder VLR-Adresse aufzuzeichnen; und dass in jedem VLR eine LA-Datensatztabelle (die als Aufzeichnungs-MC_V bezeichnet wird) erstellt wird, um LA-Adressen in jedem VLR und die Gesamtanzahl von Multicastingbenutzern unter jeder LA-Adresse aufzuzeichnen. So existieren, wie es in der Fig. 3 dargestellt ist, zwei MSs im LA1, eine MS im LA3 sowie eine MS im LA6.
In der MC_H-Tabelle im HLR 30 ist folgendes aufgezeichnet:

MC_H[VLR1] = 3, MC_H[VLR2] = 1 und MC_H(VLR3] = 0 (1)
In der MC_V-Tabelle im VLR 50 ist Folgendes aufgezeichnet:

MC_V[LA1] = 2, MC_V[LA2] = 0 und (MC_V[LA3] = 1 (2)
In der MC_V-Tabelle im VLR 70 ist Folgendes aufgezeichnet:

MC_V[LA4] = 0, MC_V[LAs] = 0 und (MC_V[LA6] = 1 (3)
In der MC_V-Tabelle im VLR 90 ist Folgendes aufgezeichnet:

MC_V[LA7] = 0 und (MC_V[LA8] = 0 (4)
Demgemäß wird, wenn die Multicastingmeldungen von der SM-SC 10 ausgegeben werden, der SMS GMSC 20 gemäß den standardmäßigen GSM/UMTS-Prozeduren eine Multicastinggruppe zugewiesen. Die SM-SC 10 liefert immer Meldungen an die SMS GMSC 20 der Multicastinggruppe weiter (Schritt 1). Die SMS GMSC 20 nimmt als Erstes auf die MC_H-Tabelle Bezug, um Standortinformation zu den im HLR 30 gespeicherten Multicastingbenutzern zu erlangen (Schritt 2). Dann leitet die SMS GMSC 20 die Information an die jeweiligen MSCs 40, 60 und 80 der Multicastingbenutzer 100-103 weiter (Schritt 3). Diese MSCs 40, 60 und 80 nehmen auf die jeweils entsprechenden MC_V -Tabellen Bezug, um in den VLRs 50, 70 und 90 gespeicherte Standortinformation zu den Multicastingbenutzern zu erlangen (Schritt 4) und um einen Funkruf für die LAs der Multicastingbenutzer auszuführen. Der Logikpfad für das Meldungsmulticasting ist ((1)) ((3)) ((5)) ((6)).
Jedoch verbleibt ein Multicastingbenutzer nicht an einem festen Standort. Wenn sich der Multicastingbenutzer von einem LA in ein anderes bewegt, wird eine Registrierung für ihn ausgeführt, um die jüngsten Tabellen betreffend MC_H und MC_V zu erhalten. Die Registrierung wird anhand der Fig. 4 beschrieben.
Es werden zwei Bewegungstypen in Betracht gezogen: Inter- Standortgebiet(Intra-VLR)-Bewegung und Inter-VLR-Bewegung. Die Fig. 4 ist ein Flussdiagramm zur Registrierung, wie sie auszuführen ist, wenn ein Multicastingbenutzer eine Inter- VLR-Bewegung ausführt. Es ist erkennbar, wie die Tabellen MC_H und MC_V durch diese Registrierung aktuell gehalten werden. In der Fig. 4 ist davon ausgegangen, dass genau eine MSC mit einem VLR verbunden ist. Diese Konfiguration mit einer MSC pro VLR ist für die Realisierung existierender GSM/UMTS-Systeme typisch. Bei einer Inter-VLR-Bewegung werden das alte und das neue LA mit verschiedenen MSCs und damit verschiedenen VLRs verbunden. Wenn sich die MS 100 (Fig. 3) vom LA1 in das LA4 bewegt, sind die Einzelheiten die folgenden.
Schritt 1: die MS 100 empfängt ein anderes Standortsignal als das ihrer MSC 40.
Schritt 2: entsprechend dem Standortsignal sendet die MS 100 eine Standortaktualisierungs-Anforderuncrsmeldung an ihre neue MSC 60. Die MSC 60 empfängt die Standortaktualisierungs-Anforderungsmeldung und sendet eine Standortgebiet- Aktualisierungsmeldung (MAP_UPDATE_LOCATION_AREA) an ein mit der MSC 60 verbundenes VLR 70.
Schritt 3: da die MS 100 einen neuen Besucher für das VLR 70 darstellt, verfügt dieses über keinen VLR-Datensatz für die MS 100. Entsprechend der von der MSC 60 im Schritt empfangenen Standortgebiet-Aktualisierungsmeldung (MAP_UPDATE_LOCA- TION_AREA) identifiziert das VLR 70 die Adresse des vorigen VLR (d. h. der Vorrichtung 50 in der Fig. 4) und liefert eine Benutzerkennungsmeldung (MAP_SEND_IDENTIFICATION) an das VLR 50. Die Meldung liefert Information für das VLR 50, damit dieses die International Mobile Subscriber Identity (IMSI) der MS 100 in der Datenbank auffinden kann. IMSI ist die eindeutige Teilnehmerkennung, die die MS 100 in ihrem entsprechenden HLR 30 kennzeichnet.
Schritt 4: das VLR 50 liefert eine Benutzerkennungs-Bestätigungsmeldung (MAP_SEND_IDENTIFICATION_ack) zurück und liefert die IMSI an das VLR 70 zurück. Das VLR 70 erzeugt einen VLR-Datensatz zum Abspeichern von Information für die MS 100 in seiner Datenbank, es aktualisiert die LA-Kennung und die MSC-Felder des VLR-Datensatzes.
Schritt 5: das VLR 70 leitet die Adresse des HLR 30 für das MS 100 aus der TMSI-Empfangsinformation zur MS vom VLR 50 her und sendet eine Standortaktualisierungsoperations-Meldung (MAP_UPDATE_LOCATION) an das HLR 30. Das HLR 50 identidiziert den Datensatz für die MS unter Verwendung der empfangenen IMSI und aktualisiert die MSC- und die VLR-Adresse im Datensatz für das MS 100.
Schritt 6: das HLR 30 dekrementiert die Tabelle MC_V[VLR1] um 1 und inkrementiert die Tabelle MC_H[VLR2] um 1.
Schritt 7: die HLR 30 liefert eine Standortaktualisierungsoperation-Bestätigungsmeldung (MAP_UPDATE_LOCATION_ack) zurück, um die MS 100 über den abgeschlossenen Aktualisierungsvorgang zu unterrichten,
Schritt 8: das VLR 70 empfängt di.e Standortaktualisierungsoperation-Bestätigungsmeldung (MAP UPDATE LOCATION ack) und inkrementiert die Tabelle MC_V[LA4] um 1.
Schritt 9: das VLR 70 liefert die Standortaktualisierungsoperation-Bestätigungsmeldung (MAP_UPDATE_LOCATION_ack) zurück, um die MS 100 über den abgeschlossenen Aktualisierungsvorgang zu unterrichten.
Schritt 10: das HLR 30 sendet eine Standort-Löschmeldung (MAP_CANCEL_LOCATION) an das VLR 50, damit dieses den überholten Datensatz für die MS 100 lcischt.
Schritt 11: das VLR 50 empfängt die Standort-Löschmeldung und dekrementiert die Tabelle MC_V(LA1] um 1.
Schritt 12: das VLR 50 bestätigt eine Standortlöschungs-Bestätigungsmeldung (MAP_CANCEL_LOCATION), und es schließt die Registrierung ab.
Bei dieser Prozedur sind die Schritte 1-5, 7, 9, 10 und 12 in den standardmäßigen UMTS/GSM-Spezifikationen spezifiziert. Die Schritte 6, 8 und 11 werden ausgeführt, wenn die MS einem Multicastingbenutzer entspricht. Vor der Registrierung sind die in den Multicastingtabellen gespeicherten Werte durch die Gleichungen (1), (2), (3) und (4) gegeben. Nach der Registrierung verbleibt die Tabelle MC_V für das VLR 90 in der Fig. 3 dieselbe. Die Tabelle MC_H wird zu MC_H[VLR1] = 2, MC_H[VLR2] = 2 und MC_H[VLR3] = 0. Die Tabelle MC_V für das VLR 50 wird zu MC_V[LA1] = 1, MC_V[LA2] = 0 und MC_V[LA3] = 1. Die Tabelle MC_V für das VLR 70 wird zu MC_V[LA4] = 1, MC_V[LAs] = 0 und MC_V[LAG] = 1.
Bei einer Inter-LA(Intra-VLR)-Bewegung werden nur die Schritte 1, 2, 8 und 9 in der Fig. 4 ausgeführt. Wenn sich die MS 100 in der Fig. 3 vom LA1 in das LA2 bewegt, wird die Inter-LA-Registrierung wie folgt ausgeführt.
Schritt 1: die MS 100 empfängt ein anderes Standortsignal als dasjenige ihrer ursprünglichen Basisstation (BS) (in diesem Fall wechselt das Standortgebiet von LA1 auf LA2).
Schritt 2: entsprechend dem Standortsignal liefert die MS 100 eine Standortaktualisierungs-Anforderungsmeldung an ihre MSC 40. Die MSC 40 empfängt diese Standortaktualisierungs- Anforderungsmeldung und liefert eine Standortgebiet-Aktualisierungsmeldung (MAP_UPDATE_LOCATION_AREA) an ein mit der MSC 40 verbundenes VLR 50.
Schritt 3: Nachdem das VLR 50 die Standortgebiet-Aktualisierungsmeldung (MAP_UPDATE_LOCATION_AREA) empfangen hat, erkennt sie, dass sich die MS 100 im selber Dienstgebiet wie sie selbst befindet, und so inkrementiert sie die Tabelle MC_V[LA2] um 1 und dekrementiert die Tabelle MC_V[LA1] um 1.
Schritt 4: das VLR 50 liefert eine Standortgebiet-Aktualisierungsbestätigungsmeldung (MAP_UPDATE_LOCATION_AREA_ack) zurück, um die MS 100 über den abgeschlossenen Aktualisierungsvorgang zu unterrichten.
Vor der Inter-LA(Intra-VLR)-Registrierung sind die Inhalte der Multicastingtabellen durch (1), (2), (3) und (4) gegeben. Nach der Registrierung sind die Tabellen MC_H für das HLR 30, MC_V für das VLR 90 dieselben verblieben, und die Tabelle MC_V für das VLR 50 ist zu MC_V[LA1] = 1, MC_V[LA2] = 1 und MC_V[LA3] = 1 geworden. Aus der Beschreibung der obigen Prozedur ist es erkennbar, dass die Tabellen MC_H und MC_V Multicastingbenutzer genau registrieren können, die in den LAs eines UMTS-Netzes verteilt sind.
Dieser Abschnitt beschreibt, wie eine Kurzmeldung oder Mul- timediameldungen unter Verwendung der Multicastingtabellen durch Multicasting gesendet werden. Für ein Kurzmeldungsbeispiel wird die Prozedur durch die folgenden Schritte beschrieben (unter Bezugnahme auf die Fig. 3):
Schritt 1: Die SM-SC 10 sendet eine Multicastingmeldung an die SMS GMSC 20.
Schritt 2: Durch eine Kurzmeldungs-Weiterleitungsanforderung (MAP_SEND_ROUTING_INFO_FOR_SM) fordert die SMS GMSC 20 die Weiterleitungsinformation vom HLR 30 an. Das HLR 30 durchsucht die Multicastingtabelle MC_H. Wenn MC_H[VLR_i] > 0 gilt (d. h., wenn sich mehr als ein Multicastingbenutzer im Kontrollbereich des VLR_i befindet), wird vom HLR 30 mittels einer Kurzmeldungs-Weiterleitungsanforderungs-Bestätigung (MAP_SEND_ROUTING_INFO_FOR_SM_ack) die Gastteilnehmernummer der Mobilstation (MSRN = Mobile Station Roaming Number) für die MSC des VLR_i an die SMS GMSC 20 rückgeliefert. Die MSRN wird dazu verwendet, die Ziel-MSCi für die Meldung zu kennzeichnen.
Schritt 3: Die SMS GMSC 20 liefert die Multicastingmeldung dadurch an die Ziel-MSCi (auf Grundlage der vom HLR 30 empfangenen MSRNs), dass sie eine Kurzmeldungs-Weiterleitungsmeldung (MAP_FORWARD_SHORT_MESSAGE) sendet. Zum Beispiel wird in der Fig. 3 die Multicastingmeldung an die MSCi und die MSC2 gesendet.
Schritt 4: Jede Ziel-MSCi sendet eine Kurzmeldungsweiterleitungs-Standortgebiet-Anforderung (MAP_SIND_INFO_FOR_MT_SMS) an das ihr entsprechende VLR, um teilnehmerbezogene Information zu erhalten. Wenn das VLR diese Meldung empfängt, durchsucht sie die Multicastingtabelle MC_V, um die LAs zu erkennen, in denen sich die Multicastingteilnehmer befinden. Diese Standortgebiete LAj erfüllen die Bedingung MC_V[LAj] > 0. Wie in der Fig. 3 sind die LAs im VLR1 das LA1 und das LA3. Das LA im VLR2 ist das LA6. Eine Kennungsprüfung wird dadurch ausgeführt, dass eine als Check Indication bezeichnete Mikroprozedur im VLR aufgerufen wird, um den Datenwert der Meldung zu verifizieren. Wenn die Tests bestanden sind, fordern die VLRs die entsprechenden MSCs dazu auf, Funkrufvorgänge für die LA1-LA3 und LA6 auszuführen.
Schritt 5: Die entsprechenden MSCs führen eine Rundübertragung der Meldung an die Multicastingbenutzer in den LAs entsprechend den standortmäßigen GSM/UNITS-Funkrufprozeduren aus.
Schritt 6: Die Multicastingbenutzer erkennen und empfangen die in ihrem jeweiligen LA im Rundruf gesendete Meldung. Die Multicastingbenutzer beginnen damit, die Meldung zu empfangen.
Aus der obigen Meldungszustellprozedur ist es deutlich, dass nur die LAs mit Multicastingbenutzern für Multicasting im Funkruf benachrichtigt werden. Die LAs ohne Multicastingmitglieder werden nicht im Funkruf angesprochen.
Nachfolgend wird ein analytisches Modell zum Untersuchen dreier Multicastingvorgehensweisen beschrieben.
Die Vorgehensweise A_I wird beim UMTS-Sprachanrufdienst verwendet (wo die Sprachanrufe durch Kurzmeldungen ersetzt sind). Bei dieser Vorgehensweise wird ein Funkruf für alle LAs ausgeführt, wenn eine Multicastingmeldung eintrifft.
Die Vorgehensweise A_II wird bei iSMS verwendet, wo Multicasting dadurch bewerkstelligt wird, dass eine Multicastingmeldung an jedes individuelle Mitglied in der Multicastingliste gesendet wird.
Die Vorgehensweise A_III ist die Vorgehensweise auf Grundlage von Multicastingtabellen. Bei dieser Vorgehensweise wird ein Funkruf für diejenigen LAs ausgeführt, in denen sich die Multicastingmitglieder befinden. LAs ohne Multicastingmitglieder erhalten keinen Funkruf.
Die Multicastingkosten gemäß den obigen Vorgehensweisen werden durch die Anzahl von Funkrufmeldungen gemessen, die bei der Zustellung einer Multicastingmeldung an die LAs gesendet werden.
Ein Beispiel wird für die spezielle Multicastingmeldungs-Zustellung gemäß den Fig. 1-3 angegeben. Die Multicastingkosten für A_I, wie in der Fig. 1 verwendet, betragen 8, da bei dieser Vorgehensweise Funkrufe an alle Standortgebiete erforderlich sind. Die Multicastingkosten für A_II, wie in der Fig. 2 verwendet, betragen 4, da bei dieser Vorgehensweise ein Funkruf für alle Multicastingbenutzer ausgeführt werden muss. Die Multicastingkosten bei A_III, wie in der Fig. 3 verwendet, betragen 3, da bei dieser Vorgehensweise ein Funkruf für alle Standortgebiete ausgeführt werden muss, in denen sich Multicastingbenutzer befinden.
Vor einer analytischen Modellbildung und einer Performancebewertung seien zwei LA-Klassen betrachtet. In der Klasse 1 verfügt das LA über Multicastingbenutzer-Verkehr ρ₁= 1/δ. In der Klasse 2 verfügt das LA über Multicastingbenutzer- Verkehr ρ₂ = δ. Wenn δ » 1 ist, weist das LA in der Klasse 1 eine kleine Multicastingbenutzer-Population auf, und das LA in der Klasse 2 weist eine große Multicastingbenutzer- Population auf.
Wenn M Standortgebiete im System vorhanden sind, existieren αM Standortgebiete in der Klasse 1 und (1 - α)M in der Klasse 2, wobei α eine Gewichtung ist. Außerdem ist bei den folgenden Gleichungen die erstere die Vergleichsperformance von A_III zu A_I, während die letztere die Vergleichsperformance von A_III zu A_II ist:

Θ_I = Kosten von A_I/Kosten von A_III

Θ_II = Kosten von A_II/Kosten von A_III
Ferner sind in den Fig. 5a und 5b Θ_I bzw. Θ_II für verschiedene δ über α aufgetragen. Wie es in den Fig. 5a und 5b dargestellt ist, nimmt Θ_Izu und Θ_II nimmt ab, wenn α und δ zunehmen. Wenn α = 0 gilt, weisen A_I und A_II ähnliche Performance auf (d. h. Θ_I ≍ 1). Wenn α = 1 gilt; , zeigen A_III und A_II ähnliche Performance (d. h. Θ_II ≍ 1). A_III zeigt deutlich bessere Performance als A_I, wenn α > 0,3 gilt (d. h., wenn mehr als 30% der LAs wenige Multicastingbenutzer enthalten). Auch zeigt A_III eine deutlich bessere Performance als A_II, wenn α < 0,9 gilt (d. h., wenn weniger als 90% der LAs viele Multicastingbenutzer enthalten). Daraus ergibt sich, dass A_III immer bessere Performance als A_I und A_II zeigt und dass das analytische Modell quantitativ die Szenarien zeigt, bei denen die Vorgehensweise eine deutlich bessere Performance als die bisher vorgeschlagenen Vorgehensweisen zeigt.
Demgemäß ist durch die Erfindung ein Multicasting-Verwaltungsmechanismus für Mobilnetze geschaffen. Der Multicasting-Verwaltungsmechanismus für Mobilnetze beinhaltet die folgenden Schritte: Empfangen eines Standortsignals, das nicht dem Ursprung eines Multicastingbenutzers entspricht (S1); Ausführen, entsprechend dem Standortsignal, einer Registrierung für den Multicastingbenutzer, um das jüngste Standortgebiet für diesen zu registrieren (S2); Erstellen, entsprechend dem jüngsten Standortgebiet, einer Multicastingtabelle (S3) mit einer VLR-Datensatztabelle in einem Heimatortsregister (HLR), um für alle Multicastingbenutzer lokalisierte VLR-Adressen und die Gesamtanzahl von Multicastingbenutzern in jedem VLR und eine LA-Datensatztabelle in einem Besucherortsregister (VLR) aufzuzeichnen, um LA-Adressen in jedem VLR um die Gesamtanzahl von Multicastingbenutzern in jedem LA aufzuzeichnen; und Ausführen, entsprechend der Multicastingtabelle, einer Multicasting-Weiterleitungsprozedur, wenn eine Meldung im Rundruf übertragen wird, um die Meldungsweiterleitung abzuschließen.
Schließlich sei angemerkt, dass die Realisierung und die Ausführung der Multicastingtabellen sehr effizient sind. Die Kosten zum Aktualisieren dieser Tabellen können im Vergleich mit den standardmäßigen Aktualisierungsschritten für den Standort ignoriert werden (Senden einer Standort-Aktualisierungsmeldung und Modifizierungen der VLR/HLR-Datensätze). Außerdem kann der Mechanismus innerhalb des VLR und des HLR realisiert werden, ohne dass die standardmäßigen Standort- Aktualisierungsmeldungen zu modifizieren wären.
Obwohl die Erfindung hinsichtlich ihrer bevorzugten Ausführungsform beschrieben wurde, soll sie nicht auf die hier offenbarte genaue Ausführungsform beschränkt sein. Der Fachmann betreffend diese Technik kann immer noch verschiedene Änderungen und Modifizierungen vornehmen, ohne vom Schutzumfang und Grundgedanken der Erfindung abzuweichen. Daher soll der Schutzumfang der Erfindung durch die folgenden Ansprüche und deren Äquivalente definiert und geschützt sein.

Claims

1. Multicasting-Verwaltungsmechanismus für Mobilnetze, mit den folgenden Schritten: Erstellen einer Datensatztabelle für ein Besucherortsregister (VLR) in einem Heimatortsregister (HLR) zum Aufzeichnen von für alle Multicastingbenutzer lokalisierten VLR-Adressen sowie der Gesamtanzahl von Multicastingbenutzern in jedem VLR; und Erstellen einer Standortgebiet(LA)-Datensatztabelle in jedem VLR, um LA-Adressen in jedem VLR und die Gesamtanzahl von Multicastingbenutzern in jedem LA aufzuzeichnen.

2. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 1, bei dem das HLR in einem Host realisiert ist.

3. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 1, bei dem das HLR in einem Server realisiert ist.

4. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 1, bei dem alle VLR in verschiedenen Servern realisiert sind.

5. Multicasting-Verwaltungsmechanismus für Mobilnetze, wobei jedes Mobilnetz über eine mobile Vorrichtung, eine Kurzmeldungs-Dienstzentrale (SM-SC), eine Kurzmeldungsdienst- Knotenmobilvermittlungszentrale (S. MS GMSC), ein HLR, eine erste Mobilvermittlungszentrale (MSC), eine zweite Mobilvermittlungszentrale, ein erstes Besucherortsregister (VLR) und ein zweites Besucherortsregister verfügt, wobei der Multicasting-Verwaltungsmechanismus die folgenden Schritte umfasst, wenn sich die mobile Vorrichtung von einem ersten Standortgebiet (LA) der ersten MSC in ein zweites LA der zweiten MSC bewegt:

- Empfangen eines Standortsignals von der zweiten SMC durch die mobile Vorrichtung;

- Ausführen, entsprechend dem Ortssignal, einer Multicastingbenutzer-Registrierung, um das jüngste LA des Multicastingbenutzers der mobilen Vorrichtung zu registrieren;

- Erstellen, entsprechend dem jüngsten Standortgebiet, einer Multicastingtabelle mit einer VLR-Datensatztabelle in einem Heimatortsregister (HLR) sowie von LA-Datensatztabellen, wobei in einer VLR-Datensatztabelle für alle Multicastingbenutzer lokalisierte VLR-Adressen und die: Gesamtanzahl der Multicastingbenutzer in jedem VLR aufgezeichnet sind, und wobei in LA-Datensatztabellen LA-Adressen in jedem VLR und die Gesamtanzahl von Multicastingbenutzern in jedem LA aufgezeichnet sind; und

- Ausführen, entsprechend der Multicastingtabelle, einer Multicasting-Weiterleitungsprozedur, wenn sich eine Meldung im Rundruf befindet, um die Weiterleitung der Multicastingmeldung abzuschließen.

6. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 5, bei dem die mobile Vorrichtung ein Zellentelefon . ist.

7. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 5, bei dem die mobile Vorrichtung ein persönlicher digitaler Assistent (PDA) ist.

8. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 5, bei dem das HLR in einem Host realisiert ist.

9. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 5, bei dem das HLR in einem Server realisiert ist.

10. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 5, bei dem das erste und das zweite VLR in verschiedenen Servern realisiert sind.

11. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 5, bei dem das erste und das zweite VLR verschieden sind und die Multicastingbenutzer-Registrierung die folgenden Schritte beinhaltet:
Schritt 1: die mobile Vorrichtung sendet eine Standort-Aktualisierungsanforderung an die zweite MSC;
Schritt 2: die zweite MSC sendet, entsprechend der Standort- Aktualisierungsanforderung, eine Standortgebiet-Aktualisierungsmeldung (MAP_UPDATE_LOCATION_AREA) an das zweite VLR, um das LA des Multicastingbenutzers der mobilen Vorrichtung vom ersten LA auf das zweite LA zu ändern;
Schritt 3: das zweite VLR erkennt, entsprechend der Standortgebiet-Aktualisierungsmeldung (MAP_UPDATE_LOCATION_AREA) die Adresse des ersten VLR;
Schritt 4: das zweite VLR sendet, entsprechend der erkannten ersten VLR-Adresse, eine Benutzerkennungsmeldung (MAP SEND IDENTIFICATION) an das erste VLR, um die IMSI (International Mobile Subscriber Identity) der mobilen Vorrichtung zu erfragen, um die Kennung der mobilen Vorrichtung zu erhalten;
Schritt 5: Abspeichern der Kennung und Ermitteln, entsprechend der Kennung, der HLR-Adresse;
Schritt 6: entsprechend der ermittelten HLR-Adresse sendet das zweite VLR eine die Kennung enthaltende Standortaktualisierungsoperation-Meldung (MAP_UPDATE_LOCATION) an das HLR;
Schritt 7: das HLR zeichnet, entsprechend der Kennung, die Adressen der zweiten MSCC und des zweiten VLR auf;
Schritt 8: das HLR liefert eine Standortaktualisierungsoperation-Bestätigungsmeldung (MAP UPDATE LOCATION ack) zurück, um das zweite VLR über den abgeschlossenen Aktualisierungsvorgang zu unterrichten;
Schritt 9: das zweite VLR sendet, entsprechend der Standortaktualisierungsoperation-Bestätigungsmeldung eine Standortgebietsaktualisierungs-Bestätigungsmeldung (MAP_UPDATE_LOCA- TION_AREA_ack), um die mobile Vorrichtung über den abgeschlossenen Aktualisierungsvorgang zu unterrichten;
Schritt 10: das HLR sendet eine Standort-Löschmeldung (MAP_CANCEL_LOCATION) an das erste VLR, um dessen überholten Datensatz für die mobile Vorrichtung zu löschen; und
Schritt 11: das erste VLR löscht, entsprechend der Standortgebiet-Löschmeldung, den Datensatz zum Ort der mobilen Vorrichtung, und es informiert das HLR über die Löschung des Standorts, um die Registrierung abzuschließen.

12. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 11, bei dem es zum Schritt 8 ferner gehört, dass das HLR jeweils die Anzahl der ersten und zweiten VLRs zählt und das Zählergebnis in der VLR-Datensatztabelle aufzeichnet.

13. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 11, bei dem es zum Schritt 9 ferner gehört, dass das zweite VLR den Multicastingbenutzer, dem die mobile Vorrichtung gehört, im zweiten LA um 1 inkrementiert und das Ergebnis in der zugehörigen LA-Tabelle aufzeichnet.

14. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 11, bei dem es zum Schritt 11 ferner gehört, dass das erste VLR den Multicastingbenutzer, dem die mobile Vorrichtung gehört, im ersten LA um 1 dekrementiert und das Ergebnis in der zugehörigen LA-Tabelle aufzeichnet.

15. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 11, bei dem die MSCs in einem Computer für Zugriff auf die VLRs realisiert sind.

16. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 5, bei dem, wenn das erste und das zweite VLR gleich sind, die Multicastingbenutzer-Registrierung die folgenden Schritte beinhaltet:
Schritt 1: die mobile Vorrichtung sendet eine Standort-Aktualisierungsanforderung an die zweite MSC;
Schritt 2: die zweite MSC sendet, entsprechend der Standort- Aktualisierungsanforderung, eine Standortgebiet-Aktualisierungsmeldung (MAP_UPDATE_LOCATION_AREA) an das zweite VLR, um das LA des Multicastingbenutzers, dem die mobile Vorrichtung gehört, vom ersten LA auf das zweite LA zu ändern;
Schritt 3: das zweite VLR ändert, entsprechend der Standortgebiet-Aktualisierungsmeldung (MAP_UPDATE_LOCATION_AREA) die LA-Adresse des Multicastingbenutzers und die Gesamtanzahl der Multicastingbenutzer in jedem LA; und
Schritt 4: das zweite VLR sendet eine Standortgebiet-Aktualisierungs-Bestätigungsmeldung (MAP_UPDATE_LOCATION_AREA ack), um die mobile Vorrichtung über die abgeschlossene Registrierung zu informieren.

17. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 16, bei dem es im Schritt 3 zur Änderung der Gesamtanzahl gehört, die Anzahl der Multicastingbenutzer im ersten LA um 1 zu dekrementieren, die Anzahl der Multicastingbenutzer im zweiten LA um 1 zu inkrementieren und das Ergebnis in den entsprechenden LA-Datensatztabellen aufzuzeichnen.

18. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 5, bei dem zur Weiterleitung einer Multicastingmeldung ferner Folgendes gehört:
Schritt 1: die SM-SC sendet eine Multicastingmeldung an die SMS GMSC;
Schritt 2: die SMS GMSC fordert mittels einer Kurzmeldungs- Weiterleitungsanforderung (MAP_SEND_ROUTING_INFO_FOR_SM) Weiterleitungsinformation für die mobile Vorrichtung vom HLR 30 an, damit dieses die VLR-Datensatztabelle entsprechend der Weiterleitungsinformation durchsucht;
Schritt 3: wenn der Inhalt der VLR-Datensatztabelle größer als Null ist, sendet das HLR mittels einer Kurzmeldungs-Weiterleitungsanforderungs-Bestätigung (MAP_SEND_ROUTING_INFO_FOR_SM_ack) eine Gastteilnehmernummer für die Mobilstation (MSRN) an die SMS GMSC;
Schritt 4: Zustellen der Multicastingmeldung, entsprechend der MSRN, durch die SMS GMSC durch Senden von Kurzmeldungs- Weiterleitungsmeldungen (MAP_FORWARD_SHORT_MESSAGE) an jeweilige MSCs der Multicastingbenutzer, denen die mobile Vorrichtung gehört;
Schritt 5: die jeweiligen MSCs senden eine Kurzmeldungsweiterleitung-Standortgebietsanforderung (MAP_SEND_INFO_FOR_MT_SMS) an ihr entsprechendes VLR, um die zugehörige Information zu den Multicastingbenutzern zu erhalten und um die LA- Datensatztabellen entsprechend der Kurzmeldungsweiterleitungs-Standortgebietsanforderung zu durchsuchen, um die LAs zu erkennen, in denen sich die Multicastingbenutzer befinden;
Schritt 6: Ausführen, nachdem in den LA-Datensatztabellen die Multicastingbenutzer aufgezeichnet wurden, einer Funkrufanforderung an LAs mit einem Inhalt der LA-Datensatztabelle größer als Null;
Schritt 7: Verwenden einer standardmäßigen GSM/UMTS-Funkrufprozedur, entsprechend der Funkrufanforderung, um die Multicastingmeldung im Rundruf an Multicastingbenutzer in denjenigen LAs zu senden, für die der Inhalt der LA-Datensatztabelle größer als Null ist; und
Schritt 8: die Multicastingbenutzer einschließlich desjenigen, dem die mobile Vorrichtung gehört, beginnen damit, die Multicastingmeldung zu empfangen.

19. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 18, bei dem die MSRN im Schritt 3 die Kennung der jeweiligen MSCs derjenigen Multicastingbenutzer liefert, denen eine mobile Vorrichtung gehört.

20. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 18, bei dem die jeweiligen MSCs in einem Host realisiert sind.

21. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 18, bei dem die SMS GMSC in einem Host für Zugriff auf im HLR gespeicherte Information realisiert ist.

22. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 21, bei dem das HLR in einem Hast realisiert ist.

23. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 21, bei dem das HLR in einem Server realisiert ist.

24. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 18, bei dem die SMS GMSC in einem Server für Zugriff auf im HLR gespeicherte Information realisiert ist.

25. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 24, bei dem das HLR in einem Server realisiert ist.

26. Multicasting-Verwaltungsmechanismus für Mobilnetze nach Anspruch 18, bei dem die standardmäßige GSM/UMTS-Funkrufprozedur diejenige gemäß dem Dokument 3GPP TS 09.02 ist.