-
Die
Erfindung betrifft das technologische Gebiet des Verwaltens der
PDP-Kontexte und ähnlicher Kommunikationsverbindungen
auf Grundlage von paketvermittelten Bearer-Diensten zwischen einer Mobilstation
und einem festen, paketvermittelten Datennetz. Die Erfindung betrifft
insbesondere die Aufgabe des Anzeigens des besonderen Gebrauchs
von PDP-Kontexten
mit demselben PDP-Typ beispielsweise für Gebührenbelastungszwecke.
-
1 stellt
einige Systemaspekte eines bekannten Ansatzes zum Anordnen der Kommunikationsverbindungen
zwischen einer Mobilstation 101 oder 102 und einem
festen, paketvermittelten Netz dar. In 1 arbeitet
jede Mobilstation oder MS (oder Teilnehmergerät oder UE, wie in den UMTS-Spezifizierungen)
in ihrem eigenen zellularen Telefonsystem: UE 101 ist ein
UMTS-Endgerät,
das in einem UMTS-Netz 103 arbeitet, und MS 102 ist
ein Enhanced-GSM-Endgerät,
das in einem Enhanced-GSM-Netz 104 arbeitet. Von beiden
Netzen verläuft
eine Verbindung zu einem GPRS-Netz 105. Das UMTS-Netz 103 umfasst
ein UTRAN- oder
UMTS Terrestrial Radio Access Network 106 sowie ein CN oder
Kernnetz 107. In dem Enhanced-GSM-Netz 104 ist
ein BSS oder Basisstationssystem 108 und eine MSC oder
Mobilfunkvermittlungsstelle 109 gezeigt. Die detaillierte
Struktur der Netzelemente ist für
die Erfindung unwesentlich, wobei jedoch bekannt ist, dass beispielsweise
ein UTRAN eine Anzahl Radio Network Subsystems umfasst, die wiederum
jeweils einen Radio Network Controller und eine Anzahl NodeBs umfassen,
welche im Groben Basisstationen entsprechen. Ein BSS wiederum umfasst
eine Basisstationssteuerung und eine Anzahl Basisfunkstationen,
die darunter arbeiten. Es sind verschiedene zellulare Telefonsysteme
mit gemischtem Modus möglich;
beispielsweise könnte
das BSS 108 unter demselben CN wie das UTRAN 106 arbeiten.
Die Mobilstationen, die in 1 gezeigt
sind, könnten
außerdem
exakt gleiche Endgeräte
sein, die eng aneinander in einer einzelnen Zelle arbeiten.
-
In 1 besteht
eine Verbindung sowohl von dem UTRAN 106 als auch von dem
BSS 108 zu einem entsprechenden SGSN oder Serving GPRS Support
Node 110 und 111. Es ist bekannt, dass eine bestimmte
Paketsteuerungseinheit oder PCU in dem Basisstationssystem und/oder
dem UTRAN als Gateway zum und vom SGSN dient. Beide SGSN 110 und 111 sind
wiederum über
die GPRS-Hauptleitungen mit einem GGSN oder Gateway GPRS Support
Node 112 gekoppelt, der außerdem andere Funktionen aufweisen
kann; in 1 ist er als Beispiel zum Betrieb
als MMSC oder MMS-Zentrale gezeigt. Die MS können an verschiedene GGSN gekoppelt
sein, oder sie können über denselben
SGSN an denselben GGSN gekoppelt sein; wie dem Fachmann bekannt, sind
verschiedene Kommunikationskonfigurationen verfügbar.
-
Das
Aufbauen einer aktiven Kommunikationsverbindung zwischen einem Endgerät und dem festen,
paketvermittelten Netz, z. B. unter Benutzung einer Mobilstation
zum Zugreifen auf die paketvermittelten Dienste, die über das
feste, paketvermittelte Netz angeboten sind, bedeutet, dass ein
so genannter PDP-Kontext zwischen der Mobilstation und einem GGSN
aktiviert werden muss. Das Aktivieren von PDP-Kontexten ist an sich
bekannt und erfolgt über
einen bekannten und dokumentierten Austausch von Nachrichten zwischen
der Mobilstation und dem GGSN. Insbesondere überträgt die Mobilstation auf eine
im Grunde an sich bekannte Art und Weise eine Activate PDP Context
Request-Nachricht. Das BSS oder UTRAN erkennt die Activate PDP Context
Request-Nachricht als paketvermittelte Dienste betreffend und leitet
sie auf eine bekannte Art und Weise, z. B. über eine PCU, an den derzeitigen
SGSN. Wenn der SGSN die Anfrage empfangen hat, kann ein Sicherheitsfunktionensatz
zwischen der Mobilstation und dem SGSN ausgeführt werden. Der SGSN bestätigt die
Aktivierungsanfrage und wählt auf
Grundlage der HLR- (Heimatregister-) Datensätze, die der Mobilstation zugeordnet
sind, und/oder einer von der MS bereitgestellten APN- (Access Point Name-)
Zeichenfolge einen GGSN aus. Der SGSN überträgt eine Create PDP Context
Request-Nachricht an den ausgewählten
GGSN.
-
Wenn
der GGSN die Nachricht empfängt, überprüft er unter
anderem den Kontexttyp, den die Mobilstation angefordert hat. Bekannte
PDP-Typen zum Prioritätsdatum
dieser Patentanmeldung sind IP zur Benutzung von Diensten auf Grundlage
des Internet Protocol, X.25 zur Benutzung von Diensten auf Grundlage
des X.25-Protokolls und OSP (Octet Stream Protocol) zur Benutzung
unstrukturierter Oktettströme
als Träger
für einige
ansonsten nicht spezifizierte Dienste. Der GGSN kann ein externes
Netzelement als den tatsächlichen
Anbieter des angeforderten Dienstes auswählen, auf Grundlage des APN und/oder
des PDP Configuration Options-Felds in der Kontextaktivierungsanfrage.
Für einige
Dienste, die auch im Dienstanbieter eingegliedert sind, kann der
GGSN als Dienstanbieter wirken. Der GGSN schafft eine Zuordnung
zu den Dienstattributen und dem gebildeten „Tunnel" oder PDP-Kontext zwischen ihm und der
Mobilstation.
-
Nachdem
der Dienst aktiviert und möglicherweise
einige dienstbezogene Parameter konfiguriert wurden (z. B. gemäß der in
dem Protocol Configuration Options-Informationselement, das in der Aktivierungsanfragenachricht
auf bekannte Art und Weise beinhaltet ist, bereitgestellten Information),
sendet der GGSN eine Create PDP Context Response-Nachricht an den
SGSN, der diese empfängt und
eine entsprechende Activate PDP Context Accept-Nachricht an die
MS überträgt. Der
Empfang dieser Nachricht an der MS beendet die Kontext-Aktivierung. Danach
ist ein logischer Tunnel zwischen der MS und dem GGSN eingerichtet.
-
Die
Aktivierung des PDP-Kontexts kann außerdem auf Initiative eines
Dienstanbieters oder anderen, festen Netzelements stattfinden. Ein
derartiger Prozess beginnt mit dem Empfang einer PDU- oder Protokolldateneinheit
durch den GGSN, bei der bekannt ist, dass sie die Aktivierung eines
PDP-Kontexts erfordert. Der GGSN kann ein HLR oder Heimatregister
zum Vorsehen gültiger
Routing-Information für
die betreffende Mobilstation abfragen, wobei das HLR diese Anfrage
mit einer Bestätigungsnachricht
beantwortet, die die angeforderte Information, insbesondere die
Kennungen (Adresse) des derzeit gültigen SGSN enthält. Der
GGSN benutzt die empfangene Adresse zum Senden einer PDU Notification Request-Nachricht
an den SGSN, der mit einer PDU Notification Response-Nachricht antwortet,
um zu bestätigen,
dass er die Mobilstation zum Aktivieren des PDP-Kontexts, der mit
einer PDP-Adresse angezeigt ist, welche innerhalb der PDU Notification
Request-Nachricht empfangen wird, auffordert. Danach überträgt der SGSN
einen Request PDP Context Activation-Befehl über das geeignete Funkzugangsnetz an
die Mobilstation. Die Mobilstation sollte dem Befehl durch Einleiten
des oben erläuterten
Prozesses als mobil veranlasste PDP-Kontextaktivierung folgen.
-
Es
ist bekannt, dass eine Mobilstation jederzeit mehrere aktive PDP-Kontexte
aufweisen kann. Die Type-Attribute dieser Kontexte sind nicht eingeschränkt, sodass
sogar mehrere simultane, aktive PDP-Kontexte desselben Typs bestehen
können.
-
Die
SGSN und GGSN sammeln Gebührenbelastungsinformation
für jeden
PDP-Kontext separat. Das Problem der bekannten Verfahren und Anordnungen
zum Verwalten von PDP-Kontexten ist, dass es keine effektiven Weisen
zum Zuordnen eines bestimmten PDP-Kontexts zu einem bestimmten Dienst
oder einer bestimmten Dienstart gibt, damit der Netzbetreiber die
Gebührenbelastung
gemäß der tatsächlichen
Nutzung von Diensten einrichten kann.
-
Es
gibt natürlich
das bekannte PDP Context Type-Attribut, das jedem aktiven PDP-Kontext
separat zugeordnet ist, sowie das QoS- oder Dienstgüteprofil,
das aus bestimmten Dienstattributen besteht und indirekt zum Anzeigen
des Diensts benutzt werden könnte.
Der bekannte Wertplatz für
PDP Context Type-Attribute ist jedoch sehr beschränkt, und
es ist nicht machbar, ihn zu erweitern, um eine breite Auswahl von
sich möglicherweise
dynamisch ändernden Dienstalternativen
abzudecken. Die Benutzung eines QoS-Profils zum Kennzeichnen einer
Dienstart ist nicht zuverlässig,
da keine Garantie dafür
besteht, dass ein derartiges „QoS-Profil
-> Dienstart"-Mapping eindeutig
wäre: mehrere
verschiedene Dienst oder Dienstarten könnten genau dieselben QoS-Profile
erfordern, obwohl sie sich vom Gesichtspunkt der Gebührenbelastung
her klar voneinander unterscheiden. Die Lösung der Benutzung von PDP-Adressen zum
Identifizieren von Diensten ist nicht machbar, da z. B. IP-basierte
Dienste häufig
dynamisch zugeteilten IP-Adressen zugeordnet sind: es wäre sehr schwierig,
eine aktuelle Mapping-Tabelle zwischen dynamisch zugeteilten IP-Adressen und bestimmten Diensten
zu unterhalten.
-
Statische
IP-Adressen sind aufgrund des beschränkten Adressenplatzes ebenfalls
nicht machbar. Zudem könnten
einige Mobilstationen nicht imstande sein, mehrere IP-Adressen gleichzeitig
abzuwickeln.
-
Das
Dokument WO 99/16266 des Stands der Technik stellt eine Lösung vor,
bei der ein optimaler Bearer-Typ zum Übertragen des Anwendungsflusses durch
das Mobilkommunikationsnetz von der angeforderten Dienstgüte bestimmt
ist.
-
Es
ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren und eine
Anordnung zum eindeutigen Anzeigen der spezifischen Benutzung eines bestimmten
PDP-Kontextes oder einer ähnlichen Kommunikationsverbindung
auf Grundlage paketvermittelter Bearer-Dienste zwischen einer Mobilstation und
einem festen, paketvermittelten Netz bereitzustellen. Es ist eine
zusätzliche
Aufgabe der Erfindung, dass sie keine umfangreiche Neufassung der zum
Prioritätsdatum
dieser Patentanmeldung bestehenden Standards erfordert, insbesondere
bezüglich der
GPRS- und UMTS-Standards. Es ist eine weitere Aufgabe der Erfindung,
dienstspezifische Gebührenbelastungsschemata
zu ermöglichen,
bei denen Netzelemente Information über die tatsächlich benutzten Dienste
sammeln, sodass eine Nachbehandlungs- und Abrechnungseinheit die
Dienste detaillierter als nur über
PDP-Typen identifizieren kann.
-
Die
Aufgaben der Erfindung werden durch Übertragen der Anzeige der spezifischen
Benutzung innerhalb einer der Kontextaktivierungsnachrichten gelöst, vorzugsweise
als untergeordneter Wert, der einem bestehenden PDP Context Type-Wert
zugeordnet ist, oder als eine der PDP Configuration Options.
-
Das
Verfahren der Erfindung ist dadurch gekennzeichnet, dass es den
Schritt des Übertragens eines
Anzeigewerts innerhalb einer Aktivierungsanfragenachricht umfasst,
der die spezifische Benutzung der paketvermittelten Kommunikationsverbindung,
deren Aktivierung mit der Aktivierungsanfragenachricht angefordert
wird, detaillierter als ein Satz vordefinierter Dienstartanzeigewerte
anzeigt.
-
Die
Erfindung betrifft außerdem
eine Anordnung mit dem kennzeichnenden Mittel zum Übertragen
eines Anzeigewerts innerhalb einer Aktivierungsanfragenachricht,
der die spezifische Benutzung der paketvermittelten Kommunikationsverbindung,
deren Aktivierung mit der Aktivierungsanfragenachricht angefordert
wird, detaillierter als ein Satz vordefinierter Dienstartanzeigewerte
anzeigt.
-
Die
Erfindung gründet
auf der Erkenntnis, dass bereits bestimmte Mechanismen zum Austauschen
von Information zwischen den Geräten
spezifiziert wurden, die an einem PDP-Kontext teilnehmen müssen, welcher
aktiviert ist. Unter Benutzung dieser Mechanismen und durch neuartige
und erfinderische Ergänzungen
derselben ist es sogar ziemlich einfach, eine spezifische Benutzung
für jeden
aktiven PDP-Kontext eindeutig anzuzeigen.
-
Insbesondere
wurde die PDP Context Type-Anzeige in der Activate PDP Context Request-Nachricht,
die von der Mobilstation übertragen wird,
bereits definiert. Statt völlig
neue Werte zu definieren, wird darauf hingewiesen, dass es erlaubt
ist, dass die bestehenden Werte optionale Erweiterungen aufweisen,
die die spezifische Benutzung des Diensts identifizieren, Der bekannte
IP-Typ für PDP-Kontexte beispielsweise
kann derart definiert werden, dass er untergeordnete Typen wie IP:MMS für Multimedia
Messaging Services, IP:WAP für
auf dem Wireless Application Protocol basierende Dienste usw. umfasst.
Es ist vorteilhaft, die Anzeige der untergeordneten Typen derart
zu definieren, dass ein älteres
oder einfacheres Netzelement, das nur imstande ist, die Grundtypen
(IP, X.25, OSP) zu erkennen, die Erweiterung, die den untergeordneten
Typ definiert, einfach ignorieren kann.
-
Mit
der Benutzung von untergeordneten Typen, die derart definiert sind,
dass sie in Kategorien fallen, die durch die bestehenden Typen definiert sind,
ist eine erhebliche Belastung der Standardneufassung vermieden,
da die Abwicklung der bekannten Typen bleiben kann, wie sie ist.
Es ist geradlinig, die in dieser Patentanmeldung vorgesehenen Anleitungen
anzuwenden, um die Programme, die einen integrierten Teil der Netzelemente
bilden und deren Betrieb steuern, derart zu verbessern, dass sie neben
dem Erkennen der „Haupttypen" und Abwickeln des
PDP-Kontexts gemäß einer
bekannten Weise außerdem
den untergeordneten Typ lesen und ihn beispielsweise als ein Teil
der Gebührenbelastungsinformation
speichern.
-
Eine
alternative Art und weise zum Anzeigen der spezifischen Benutzung
eines bestimmten PDP-Kontexts ist, einen entsprechenden Konfigurationsparameter
zu definieren, der innerhalb des geeigneten Felds der Activate PDP
Context Request-Nachricht zusammen mit bekannten Konfigurationsparametern übertragen
wird. Dieser Ansatz kann bewirken, dass die Activate PDP Context
Request-Nachricht länger
als die besonders bevorzugte, oben beschriebene „Untertypen"-Alternative ist, da
das Hinzufügen
eines neuen Konfigurationsparameters mehr Nebeninformation wie Parameterzählung, Parameterlänge, Parameter-ID
usw. erfordern kann, die der Nachricht hinzuzufügen ist.
-
Die
neuartigen Merkmale, die als kennzeichnend für die Erfindung angesehen werden,
sind insbesondere in den beiliegenden Ansprüchen angeführt. Die Erfindung selbst,
sowohl bezüglich
ihres Baus als auch ihres Betriebsverfahrens, zusammen mit zusätzlichen
Aufgaben und Vorteilen davon geht am besten aus der folgenden Beschreibung
spezifischer Ausführungsformen
in Verbindung mit den beiliegenden Zeichnungen hervor.
-
1 stellt
eine bekannte Netzanordnung dar,
-
2a stellt
einen Nachrichtenaustausch gemäß einer
vorteilhaften Ausführungsform
der Erfindung dar,
-
3a stellt
eine Aktivierungsanfragenachricht gemäß der Erfindung dar,
-
3b stellt
eine Erstellungsanfragenachricht gemäß der Erfindung dar,
-
3c stellt
eine Meldungsnachricht gemäß der Erfindung
dar,
-
3d stellt
eine Aktivierungsbefehlnachricht gemäß der Erfindung dar und
-
4 stellt
eine Anordnung gemäß der Erfindung
dar.
-
1 wurde
oben in der Beschreibung des Stands der Technik besprochen, weswegen
wir uns im Folgenden hauptsächlich
auf 2a bis 4 konzentrieren.
-
2a stellt
einen beispielhaften Austausch von Nachrichten zwischen einer MS,
einem SGSN und einem GGSN über
ein BSS dar. Bei Schritt 201 überträgt die MS eine Activate PDP
Context Request-Nachricht, die in 3a detaillierter
dargestellt ist und vorzugsweise zumindest die folgende Information
enthält:
- * Die Netzdienstzugangskennung oder NSAPI 301 wird
von der MS ausgewählt.
Die NSAPI identifiziert den PDP-Kontext,
der innerhalb des GPRS/UMTS-Netzes aktiviert werden soll. Zur Identifizierung
des Benutzers umfasst die Nachricht außerdem die TLLI- (Temporary
Logical Link Identity) und IMSI- (International Mobile Subscriber
Identity) Informationselemente (in 3a nicht
gezeigt).
- * Der PDP-Typ 302 soll einen zweiteiligen Wert aufweisen.
Der erste Teil 302a ist ein Hauptwert, der das Protokoll
identifizieren soll; typische Hauptwerte sind die vordefinierten
Kennungen der IP-, X.25- und OSP-Protokolle.
Der zweite Teil 302b soll den benutzten Dienst gemäß der insbesondere
bevorzugten Ausführungsform
der Erfindung identifizieren. Der zweite Teil kann als Führung zu
dem Gebührenbelastungsschema
benutzt werden, das für
den Dienst Anwendung finden soll. Der SGSN kann ihn zum Auswählen eines
geeigneten GGSN benutzen (beispielsweise einen mit MMSC-Fähigkeiten,
wenn der betreffende Dienst MMS ist), der den Dienst bereitstellen kann.
Der zweiteilige Wert des PDP Type-Felds kann beispielsweise durch
XX:YYY ausgedrückt sein,
wobei XX der Hauptwert und YYY die Erweiterung gemäß dieser
Ausführungsform
der Erfindung ist.
- * Das PDP Address-Feld 303 ist besonders vorteilhafterweise
leer. Das Eingeben einer Adresse in dieses Feld bedeutet, dass die
MS die Benutzung einer statischen PDP-Adresse erfordert, und das
Leerlassen des Felds bedeutet, dass die MS eine dynamische PDP-Adresse
erfordert.
- * Der Access Point Name oder APN 304 wird von der MS
ausgewählt.
Ein APN ist ein logischer Name, der sich auf das externe Paketdatennetz
bezieht, mit dem sich der Teilnehmer zu verbinden wünscht. Der
ausgewählte
APN identifiziert den GGSN und mögliche
andere Dienstanbieter, die die MS für diesen Kontext benutzen möchte. Der eigentliche
APN, der benutzt werden soll (d.h. der GGSN und mögliche zusätzliche
Dienstanbieter, die benutzt werden sollen), kann vom Betreiber durch
Abonnement eingeschränkt
sein. Wenn dies der Fall ist, beinhaltet der HLR- (Home Location
Register-) Datensatz jeden Benutzers die APN-Information, die die
GGSN und Dienstanbieter identifiziert, welche stets benutzt werden
sollten; sie können
natürlich
für verschiedene
Dienste oder Dienstklassen verschieden sein. Die MS kann den APN
aus der Activate PDP Context Request-Nachricht auslassen, wenn der
APN im HLR konfiguriert ist. Ansonsten kann der Benutzer einen APN
in die Nachricht einbeziehen. Wenn kein APN in der Nachricht ist
und kein APN im HLR konfiguriert ist, steht es dem SGSN frei, jeglichen
GGSN und andere Dienstanbieter, die benutzt werden sollen, auszuwählen (wenn
der HLR-Datensatz dynamische Zuteilung in dem besuchten Netz gestattet).
- * QoS Requested 305 (wobei QoS für Dienstgüte steht) wird von der MS ausgewählt. Die
angeforderte Dienstgüte
umfasst mehrere Faktoren, und ihre Auswahl hängt von den gewünschten
Kennzeichen des Dienstes ab. Darunter ist der eventuelle Bedarf
an RLC&LLC-Neuübertragungen,
die Benutzung von UDP (User Datagram Protocol) am GPRS- Backbone-Netz, Bitraten,
Verzögerungsklasse
und Dienstvorrang in Betracht zu ziehen.
- * Das PDP Configuration Options-Feld 306 kann beispielsweise
zum Informieren des GGSN und/oder Dienstanbieters über bestimmte
Fähigkeiten
der MS, wie etwa unterstützte
Inhaltstypen usw., benutzt werden. Allgemeine Konfigurationsinformation
kann in diesem Informationselement beinhaltet sein, wenn diese nicht
in dem angewendeten Protokoll selbst implementiert ist. Wenn zahlreiche
Protokolle zur Anwendung zur Auswahl stehen (entweder völlig separate
Protokolle oder verschiedene Versionen desselben Protokolls), kann
PDP Configuration Options zum Informieren des GGSN und/oder des
Dienstanbieters darüber
benutzt werden, welche (s) Protokoll (e) die MS unterstützt. Eine
alternative Ausführungsform
der Erfindung ist, die spezifische Dienstartanzeige als Teil dieses
Felds bereitzustellen, statt den zweiteiligen Wert für das PDP
Type-Feld 302 zu benutzen. Eine derartige Bereitstellung
einer spezifischen Dienstartanzeige könnte beispielsweise die Eingabe
von „Service=YYY" in das PDP Configuration
Options-Feld 306 bedeuten, wobei YYY wiederum eine Anzeige
eines spezifischen Dienstes ist.
-
Bei
Schritt 202 erkennt das BSS die Activate PDP Context Request-Nachricht
als paketvermittelte Dienste betreffend und leitet sie infolgedessen
auf bekannte Art und Weise an den derzeitigen SGSN weiter. Bei Schritt 203 empfängt der
SGSN die Activate PDP Context Request-Nachricht. Schritt 204 bezeichnet
die optionale Ausführung
bekannter Sicherheitsfunktionen zwischen der MS und dem SGSN. Bei
Schritt 205 wählt
der SGSN auf Grundlage der HLR-Datensätze und/oder
der von der MS vorgesehenen APN-Zeichenfolge
den GGSN auf eine bekannte Weise aus und überträgt eine Create PDP Context
Request-Nachricht. Eine vorteilhafte Beispielform dieser Nachricht
ist in 3b mit den folgenden Feldern
gezeigt:
- * Das PDP Type-Feld 312 ist
eine Kopie von Feld 302 in der Activate PDP Context Request-Nachricht,
soll also gemäß der bevorzugten
Ausführungsform
einen zweiteiligen Wert aufweisen: einen Hauptwert 312a,
der das Protokoll identifizieren soll, und einen zweiten Teil 312b,
der den benutzten Dienst identifizieren soll. Der zweiteilige Wert
des PDP Type-Felds kann wiederum beispielsweise als XX:YYY ausgedrückt sein,
wobei XX der Hauptwert ist und YYY die Erweiterung gemäß dieser
Ausführungsform
der Erfindung.
- * Das PDP Address-Feld 313 ist besonders vorteilhafterweise
leer, was bedeutet, dass eine dynamische PDP-Adresse angefordert
ist.
- * Das Access Point Name- oder APN-Feld 314 enthält eine
APN-Netzkennung des APN, der vom SGSN gemäß bekannter GPRS-Verfahren
ausgewählt
wird.
- * Das QoS Negotiated-Feld 315 zeigt das Ergebnis einer
Dienstgüteverhandlung
zwischen der MS und dem SGSN an. Sie ist nicht abwärts für den GGSN
verbindlich, was bedeutet, dass es dem GGSN gestattet ist, die Dienstgüte angesichts
seiner Fähigkeiten
und der laufenden Belastung weiter einzuschränken.
- * Der TID oder Temporary Identifier 317 wird vom SGSN
für den
angeforderten PDP-Kontext durch Kombinieren der IMSI (International
Mobile Subscriber Identifier), die im MM-Kontext (Mobility Management-Kontext)
der MS gespeichert ist, und der NSAPI gebildet, die in Feld 301 der
Activate PDP Context Request-Nachricht empfangen ist.
- * Das Selection Mode-Feld 318 zeigt an, ob ein abonnierter
APN ausgewählt
wurde, oder ob ein nicht abonnierter, von der MS gesendeter APN oder
ein nicht abonnierter, vom SGSN gewählter APN ausgewählt wurde.
Der GGSN kann den Inhalt dieses Felds beim Bestimmen nutzen, ob
er die PDP-Kontextaktivierung akzeptiert oder zurückweist.
- * Das PDP Configuartion Options-Feld 316 ist eine exakte
Kopie von Feld 306 in der Activate PDP Context Request-Nachricht, d.h. die
Konfigurationsoptionen werden transparent durch den SGSN übertragen.
Gemäß der alternativen
Ausführungsform
der Erfindung umfasst ein Teil dieses Felds die Dienstartanzeige
beispielsweise in der Form „Service=YYY", wobei YYY eine
Anzeige eines spezifischen Diensts ist.
-
Bei
Schritt 206 empfängt
der GGSN die Nachricht und erkennt aus der Anzeige gemäß der Erfindung,
welche spezifische Dienstart damit verbunden ist. Der GGSN bestimmt,
den Dienst selbst bereitzustellen oder auf Grundlage des APN- und/oder
PDP Configuration Options-Felds
in der Kontextaktivierungsanfrage einen externen Dienstanbieter
auszuwählen.
Der GGSN erstellt eine Zuordnung mit den Dienstattributen und dem
hergestellten Tunnel (durch TID identifiziert, der aus der IMSI
des Benutzers und dem NSAPI-Wert des PDP-Kontexts besteht).
-
Nachdem
der Dienst aktiviert und möglicherweise
einige dienstbezogene Parameter konfiguriert wurden (z. B. gemäß der in
dem Protocol Configuration Options-Informationselement bereitgestellten
Information), sendet der GGSN bei Schritt 207 eine Create
PDP Context Response-Nachricht an den SGSN, der diese bei Schritt 208 empfängt. Struktur und
Inhalte der Nachricht können
dieselbe wie bei den Create PDP Context Response-Nachrichten des Stands der Technik sein:
die Zielsetzung, sowohl den SGSN als auch den GGSN die spezifische
Dienstartanzeige wissen zu lassen, wurde durch die oben erläuterte Benutzung
der Activate PDP Context Request- und
Create PDP Context Request-Nachrichten erfüllt. Bei Schritt 209 überträgt der SGSN
eine Activate PDP Context Accept-Nachricht an die MS. Der Empfang 210 dieser
Nachricht an der MS beendet die Kontextaktivierung. Es muss keine PDP-Adresse
für den
Kontext zugeteilt werden, obwohl eine derartige Zuteilung nicht
aus der Erfindung ausgeschlossen ist. Nach Schritt 210 ist
ein logischer Tunnel zwischen der MS und dem GGSN eingerichtet,
wobei der spezifische Dienst unter Benutzung des aktivierten PDP-Kontexts
wie durch Block 211 dargestellt benutzt werden kann.
-
Die
Anzeige der spezifischen Dienstart ist zumindest im GGSN und im
SGSN gespeichert. Diese Geräte
können
sie beispielsweise für
Gebührenbelastungszwecke
benutzen, was schematisch durch Block 212 und 213 dargestellt
ist. Dies bedeutet, dass der SGSN und der GGSN, wenn sie Gebührenbelastungsinformation
(Verbindungsdauer, Anfangs- und
Endzeiten, Peer-Kennungen usw.) auf eine ansonsten an sich bekannte
Art und Weise speichern, außerdem
die Anzeige der spezifischen Dienstart separat für jeden PDP-Kontext speichern. Danach ist es einfach,
einen Rechner die gespeicherten Datensätze durchsuchen zu lassen und
den für
das Endgerät zuständigen Teilnehmer
für alle
benutzten Dienste gemäß einer
vordefinierten Gebührungsbelastungsaufstellung
mit Gebühren
zu belasten.
-
2b stellt
ein vom Netz angefordertes PDP-Kontextaktivierungsverfahren
gemäß einer
vorteilhaften Ausführungsform
der Erfindung dar. Bei Schritt 251 erhält der GGSN Kenntnis von einem
Erfordernis zum Aktivieren eines neuen PDP-Kontexts mit einer bestimmten
MS. Bei Schritt 252 kann er das HLR (nicht gezeigt) der
MS nach der derzeit gültigen Routing-Information
zu der MS abfragen. Bei Schritt 253 nutzt der GGSN die
derzeit gültige
Routing-Information durch Übertragen
einer PDP Notification Request-Nachricht an den derzeit gültigen SGSN,
die schematisch in 3c dargestellt ist und vorteilhafterweise
zumindest die folgenden Felder umfasst:
- * Die
IMSI 321 ist der International Mobile Subscriber Identifier
der Mobilstation, mit der der PDP-Kontext aktiviert werden soll.
- * Der PDP Type 322 soll wiederum einen zweiteiligen
Wert gemäß der bevorzugten
Ausführungsform
der Erfindung aufweisen. Der erste Teil 322a ist ein Hauptwert,
der das Protokoll identifizieren soll; typische Hauptwerte sind
die vordefinierten Kennungen der IP-, X.25- und OSP-Protokolle. Der zweite
Teil 322b soll den benutzten Dienst gemäß der insbesondere bevorzugten
Ausführungsform
der Erfindung identifizieren. Der zweiteilige Wert des PDP Type-Felds
kann beispielsweise durch XX:YYY ausgedrückt sein, wobei XX der Hauptwert
und YYY die Erweiterung gemäß dieser
Ausführungsform
der Erfindung ist.
- * Das PDP Address-Feld 323 umfasst eine dynamische
oder statische PDP-Adresse, die für den PDP-Kontext benutzt werden
soll, der aktiviert werden soll.
-
Nach
dem Empfangen der PDU-Meldungsanfrage bei Schritt 254 überträgt der SGSN
bei Schritt 256 eine einfache Bestätigungsnachricht mit einem „cause"-Parameter auf bekannte
Art und Weise zurück
an den GGSN; der Empfang der Bestätigung am GGSN ist bei Schritt 256 gezeigt.
Bei Schritt 257 überträgt der SGSN
einen Request PDP Context Activation-Befehl an die Mobilstation.
Eine beispielhafte Befehlsnachricht ist schematisch in 3d gezeigt
und umfasst die folgenden Felder:
- * Das TI
oder Temporay Identifier-Feld 331 enthält den TI, unter der die MS
innerhalb ihres derzeitigen BSS oder Funkzugangsnetzes bekannt ist.
- * Das PDP Type-Feld 332 ist eine Kopie von Feld 322 in
der PDP Notification Request-Nachricht, soll also gemäß der bevorzugten
Ausführungsform
einen zweiteiligen Wert aufweisen: einen Hauptwert 332a,
der das Protokoll identifizieren soll, und einen zweiten Teil 332b,
der den benutzten Dienst identifizieren soll. Der zweiteilige Wert des
PDP Type-Felds kann wiederum beispielsweise als XX:YYY ausgedrückt sein,
wobei XX der Hauptwert ist und YYY die Erweiterung gemäß dieser
Ausführungsform
der Erfindung.
- * Das PDP Address-Feld 333 umfasst eine dynamische
oder statische PDP-Adresse, die für den PDP-Kontext benutzt werden
soll, der aktiviert werden soll. Das Feld ist eine Kopie von Feld 323 in
der PDP Notification Request-Nachricht.
-
Schritt 258 stellt
das bekannte Weiterleiten des Request PDP Context Activation-Befehls
durch das BSS zur MS dar, und Schritt 259 stellt den Empfang
der Nachricht durch die MS dar. Danach folgt ein PDP- Kontextaktivierungsverfahren,
das ansonsten dasselbe wie oben in Verbindung mit 2a erläutert ist,
wobei jedoch bei Nachrichten in der Uplink-Richtung, in denen ein
PDP Type-Feld erscheint, der PDP-Typ erscheint, den die MS aus dem
Request PDP Context Activation-Befehl erfahren hat, statt jeglicher
PDP-Typ-Anzeige, die von der MS frei wählbar ist. Gleicherweise umfassen
die Uplink-Nachrichten, die ein PDP Address-Feld umfassen, die vorher
in der Downlink-Richtung übertragene
PDP-Adresse. Die
betroffenen Nachrichten und Zustände
sind mit einem Bezugszeichen mit Strichindex markiert.
-
Eigentlich
wäre es
keineswegs wesentlich, die spezifische Dienstartanzeige überhaupt
in die Uplink-Nachrichten zu kopieren, die ein Teil des vom Netz
angeforderten PDP-Kontextaktivierungsverfahrens
sind, da der SGSN und der GGSN die spezifische Dienstartanzeige
bereits kennen. Es ist jedoch vorteilhaft, sie einzufügen, damit
die mobil und durch das Netz eingeleiteten Verfahren möglichst
viel gemeinsam haben.
-
4 stellt
eine Anordnung gemäß der Erfindung
dar, die ein Endgerät
oder MS (oder UE) 401, ein BSS oder UTRAN 402,
einen SGSN 403 und einen GGSN 404 umfasst. Die
Hardware des Endgeräts
umfasst einen Funktransceiverblock 412, einen Decodier-/Demultiplexblock 413,
einen Codier-/Multiplexblock 414,
einen Steuerblock 415 und ein Benutzerdatenteil 416.
Der Decodier-/Demultiplexblock 413 ist zum Trennen empfangener
Signalinformation von empfangenen Benutzerdaten und zum Weiterleiten
der letzteren in den Steuerblock 415 angeordnet; gleichermaßen ist
der Codier-/Multiplexblock 414 zum Aufnehmen von Signalinformation
aus dem Steuerblock 415 und Multiplexen derselben zur Übertragung
mit Benutzerdaten angeordnet, die vom Benutzerdatenteil 416 kommen.
Alle anderen Blöcke
arbeiten unter der Überwachung
des Steuerblocks. Die Steuerverbindungen sind mit dünneren Linien
als die Benutzerdaten- und Signalinformationsverbindungen gezeigt.
Die vorliegende Erfindung ist derart im Endgerät implementiert, dass der Steuerblock 415 angewiesen
ist, die spezifische Dienstartanzeige allen Activate PDP Context
Request-Nachrichten
hinzuzufügen,
die er erzeugt; dies ist durch Programmieren der entsprechenden
Operationen in einen Speicher in Form von maschinenlesbaren Verarbeitungsbefehlen ausgeführt. Wenn
das Endgerät
eine Anzahl separater Funktionseinheiten umfasst, kann man unter
dem Steuerblock die auf die physischen Steuereinheiten der separaten
Geräte
verteilten Steuerfunktionen verstehen.
-
Der
SGSN ist im Grunde ein Datenspeicher 421 mit hoher Kapazität, wobei
eine Übertragungseinheit 422 angeordnet
ist, um ihn mit den Hauptleitungen des GPRS-Netzes (oder eines entsprechenden
Paketdatennetzes) sowie einer Steuereinheit 423 zum Steuern
der Herstellung, Unterhaltung und des Abbruchs von Verbindungen
zu koppeln. Der Steuerblock 423 kann zum Erkennen spezifischer Dienstartanzeigen
aus einer Activate PDP Context Request-Nachricht durch Programmieren
der entsprechenden Operationen in einen Speicher in Form von maschinenlesbaren
Verarbeitungsbefehlen hergestellt sein. Der Datenspeicher 421 kann
zum Speichern der spezifischen Dienstartanzeigen in Verbindung mit
beispielsweise Gebührenbelastungsinformation
benutzt sein.
-
Der
GGSN ist ein Datenverarbeitungsgerät, das ebenfalls einen Datenspeicher 431 umfasst,
wobei eine Übertragungseinheit 432 angeordnet
ist, um ihn mit den Hauptleitungen des GPRS-Netzes (oder eines entsprechenden Paketdatennetzes)
sowie einer Steuereinheit 433 zum Steuern der Herstellung, Unterhaltung
und des Abbruchs von Verbindungen zu koppeln. Der Steuerblock 433 kann
zum Erkennen spezifischer Dienstartanzeigen aus einer Create PDP
Context Request-Nachricht durch Programmieren der entsprechenden
Operationen in einen Speicher in Form von maschinenlesbaren Verarbeitungsbefehlen
hergestellt sein. Der Datenspeicher 431 kann zum Speichern
der spezifischen Dienstartanzeigen in Verbindung mit beispielsweise
Gebührenbelastungsinformation
benutzt sein.
-
Die
Erfindung wurde oben ausschließlich
unter Bezugnahme auf GPRS- und UMTS-Technologie beschrieben. Die
Erfindung ist jedoch gleicherweise auf alle jene Systeme anwendbar,
bei denen die Aktivierungsanfragenachricht nach einer neuen paketvermittelten
Kommunikationsverbindung ein Typ-Feld
umfasst, für
das ein begrenzter Satz Hauptwerte definiert wurde. Die Erfindung
wurde außerdem
nur unter Bezugnahme auf Activate PDP Context Request-/Create PDP
Context Request-Nachrichten beschrieben, die als Anzeige für das Erfordernis
eines völlig
neuen PDP-Kontexts übertragen
werden; es kann jedoch eine ähnliche
Nachricht übertragen
werden, wenn eine der Kommunikationsseiten feststellt, dass die
Kennzeichen des bestehenden PDP-Kontexts
nicht optimal für
die derzeitige Benutzung des PDP-Kontexts sind, sodass die „Aktivierungsnachricht" eigentlich bedeutet,
dass die Kennzeichen eines bestehenden PDP-Kontexts neu definiert
werden müssen.