-
Die
Erfindung betrifft ein Verfahren zum Übertragen von Daten in Telekommunikationsnetzen.
-
Es
ist allgemein bekannt, dass zum Übertragen
von Sprachdienste (Voice-Services) betreffenden Daten in Telekommunikationsnetzen
das Signalisierungssystem Nr. 7 (SS7) verwendet wird. In modernen
Telekommunikationsnetzen werden zunehmend neben den Sprachdiensten
auch Datendienste etabliert. Für
derartige Dienste ist das Signalisierungssystem Nr. 7 nicht optimal
einsetzbar, da dieses für
die Benutzung der Sprachdienste entwickelt und spezifiziert wurde.
-
Der
Erfindung liegt die Aufgabe zugrunde, ein Verfahren und eine Anordnung
anzugeben, mit denen in einfacher und kostengünstiger Weise Daten in Telekommunikationsnetzen übertragen
werden können.
-
Diese
Aufgabe wird erfindungsgemäß gelöst durch
ein Verfahren zum Übertragen
von Daten in Telekommunikationsnetzen, bei dem die Daten von einem
ersten Netzelement eines ersten Telekommunikationsnetzes in nach
RADIUS-Vorgaben aufgebaute Nachrichten eingeschrieben werden, und
diese Nachrichten mit den eingeschriebenen Daten zu einem zweiten
Netzelement eines zweiten Telekommunikationsnetzes über eine
Ro-Schnittstelle übertragen
werden, die die beiden Telekommunikationsnetze miteinander verbindet.
Hierbei ist insbesondere vorteilhaft, dass nach RADIUS-Vorgaben
aufgebaute Nachrichten (RADIUS-Nachrichten)
mit den zu übertragenden
Daten über
die Ro- Schnittstelle über Telekommunikationsnetzgrenzen
hinweg übertragen werden
können.
Damit können
die Nachrichten bzw. die Daten über
die Ro-Schnittstelle zwischen Netzbetreibern hin- und zurückübermittelt werden, wobei die Nachrichten
bzw. Daten sowohl Zahlungsvorgänge (Online
Charging, Accounting) als auch Authentifizierungs- und Autorisierungsvorgänge (Authentication, Authorisation)
betreffen können.
-
Erfindungsgemäß kann bei
dem Verfahren eine Ro-Schnittstelle verwendet werden, die an die Übertragung
von nach RADIUS-Vorgaben
aufgebauten Nachrichten angepaßt
ist, indem die Schnittstellenattribute (AVP) so in ihrer Länge beschränkt werden,
dass sie der RADIUS-Spezifikation für Schnittstellenattribute entsprechen.
-
Bei
dem erfindungsgemäßen Verfahren
können
die Daten Kommunikationsgebühren-Abrechnungsanforderungen
(Accounting Requests) sein, denen jeweils eine Nachrichtentypkennung
beigefügt ist.
Die Kommunikationsgebühren-Abrechnungsanforderungen
werden von einem Anforderungsempfänger aufgrund der Nachrichtentypkennung
als Bezahlungs-Anforderungen (Charging Requests) behandelt. Diese
Ausgestaltungsform des erfindungsgemäßen Verfahrens ermöglicht es,
mit der Übertragung
nur eines Datentyps (Kommunikationsgebühren-Abrechungsanforderungen)
und der Nachrichtentypkennung dem Anforderungsempfänger Informationen über verschiedene
Anforderungstypen mitzuteilen.
-
Vorteilhafterweise
können
die Daten von einem dienstanbietenden Rechner (Application Server) des
ersten Telekommunikationsnetzes zu einem Zahlungssystem des zweiten
Telekommunikationsnetzes übertragen
werden. Dadurch wird das Durchführen
von Zahlungsvorgängen
zwischen verschiedenen Telekommunikationsnetzen verschiedener Netzbetreiber
ermöglicht.
-
Bei
dem erfindungsgemäßen Verfahren
können
die nach RADIUS-Vorgaben
aufgebauten Nachrichten als Transportmittel für die zu übertragenden Daten verwendet
werden.
-
Das
erfindungsgemäße Verfahren
kann so ablaufen, dass bei Auftreten einer Dienstanforderung von
einer in dem ersten Netzelement installierten ersten Zustandsmaschine
eine die Dienstanforderung betreffende erste Nachricht über die
Ro-Schnittstelle an
das zweite Netzelement abgesendet wird, von der ersten Zustandsmaschine
auf ein Eintreffen einer zweiten Nachricht des zweiten Netzelementes
gewartet wird, und von dem ersten Netzelement eine Erbringung des
Dienstes veranlaßt
wird, wenn die zweite Nachricht die Information enthält, dass
eine Abrechnung des zu erbringenden Dienstes durchgeführt werden
kann, oder anderenfalls von dem ersten Netzelement die Dienstanforderung
zurückgewiesen wird.
-
Erfindungsgemäß kann von
einer in dem zweiten Netzelement installierten zweiten Zustandsmaschine
die erste Nachricht empfangen werden, und nach Auswertung von in
dem zweiten Telekommunikationsnetz abgespeicherten Abrechnungsdaten
kann von der zweiten Zustandsmaschine die o.g. Information enthaltende
zweite Nachricht an das erste Netzelement gesendet werden, wenn
die Durchführung
der Abrechnung möglich
ist.
-
Die
obengenannte Aufgabe wird erfindungsgemäß ebenfalls gelöst durch
eine Anordnung zum Übertragen
von Daten in Telekommunikationsnetzen mit einer zwischen einem ersten
Netzelement eines ersten Telekommunikationsnetzes und einem zweiten
Netzelement eines zweiten Telekommunikationsnetzes angeordneten
Ro-Schnittstelle, welche zum Übertragen
von nach RADIUS-Vorgaben
aufgebauten Nachrichten ausgestaltet ist.
-
Hierbei
kann das erste Netzelement eine AAA-Einheit (AAA-Einheit = Authentification, Authorization
and Accounting-Einheit)
oder ein dienstanbietender Rechner (Application Server) und das
zweite Netzelement ein Zahlungssystem sein.
-
Bei
der erfindungsgemäßen Anordnung kann
die Ro-Schnittstelle an die Übertragung
von nach RADIUS-Vorgaben aufgebauten Nachrichten angepasst sein,
indem die Schnittstellenattribute (AVP) so in ihrer Länge beschränkt sind,
dass sie der RADIUS-Spezifikation
für Schnittstellenattribute
entsprechen.
-
Zur
weiteren Erläuterung
der Erfindung ist in
-
1 ein Ausführungsbeispiel
einer Anordnung zur Durchführung
des erfindungsgemäßen Verfahrens,
in
-
2 Beispiele für mittels
des erfindungsgemäßen Verfahrens übertragene
Nachrichten und in
-
3 weitere Beispiele für mittels
des erfindungsgemäßen Verfahrens übertragene
Nachrichten dargestellt.
-
In 1 sind die die Erfindung
betreffenden Elemente eines ersten Telekommunikationsnetzes TKN1
und eines zweiten Telekommunikationsnetzes TKN2 dargestellt. Bei
dem ersten und dem zweiten Telekommunikationsnetz kann es sich beispielsweise jeweils
um ein Mobilfunknetz der zweiten oder dritten Generation (GSM-,
GPRS- oder UMTS-Mobilfunknetz) handeln. Die beiden Telekommunikationsnetze werden
erfindungsgemäß durch
eine an das Nachrichtenübertragungsprotokoll
RADIUS angepasste Ro-Schnittstelle
Ro1 verbunden; dieses wird unten näher erläutert.
-
In
dem ersten Telekommunikationsnetz TKN1 ist ein dienstanbietender
Rechner AS (Application Server) angeordnet. Dabei handelt es sich
um ein Netzelement des ersten Telekommunikationsnetzes, das einen
Dienst (Service) erbringt oder zumindest vermittelt. Im Falle der
Vermittlung eines Dienstes kann es sich bei dem dienstanbietenden
Rechner um einen Proxy-Server
handeln. Der dienstanbietende Rechner AS ist mit einem Authentifizierungsrechner
AAA (AAA-Server = Authentification, Authorization and Accounting-Server)
verbunden. Die Verbindung wird durch eine zweite Ro-Schnittstelle
Ro2 realisiert, die erfindungsgemäß an das Nachrichtenübertragungsprotokoll
RADIUS angepasst ist. Der Authentifizierungsrechner AAA des ersten
Kommunikationsnetzes TKN1 ist über
die Ro-Schnittstelle
Ro1, die an das Nachrichtenübertragungsprotokoll
RADIUS angepasst ist, mit einem Zahlungssystem ZS des zweiten Telekommunikationsnetzes
TKN2 verbunden.
-
Weiterhin
ist der Authentifizierungsrechner AAA mit einem Heimatnetz-Authentifizierungsrechner
HAAA (HAAA-Server = Home Authentification Authorization and Accounting-Server)
verbunden. An das Zahlungssystem ZS des zweiten Telekommunikationsnetzes
TKN2 ist ein Dienstesteuerungspunkt SCP angeschlossen; das zweite
Telekommunikationsnetz TKN2 weist eine Struktur eines Intelligenten Netzes
(IN = Intelligent Network) auf. Der Dienstesteuerungspunkt SCP ist
mit einem Speicher SP verbunden, in dem zur Führung von Guthabenkonten GK
erforderliche Daten von Telekommunikationsteilnehmern abgespeichert
sind. weiterhin ist das Zahlungssystem ZS mit einer Gebührennacherhebungseinrichtung
PP (PP = Postprocessing unit) verbunden, mittels der ein Telekommunikations-Dienstnutzer
bzw. -Dienstteilnehmer nach Diensterbringung beispielsweise mittels
einer schriftlichen Rechnung mit Gebühren oder Kosten für den Dienst
belastet werden kann.
-
Das
erste Telekommunikationsnetz TKN1 wird von einem ersten Mobilfunknetzbetreiber
MNO1 (MNO = Mobile Network Operator) verwaltet und betrieben; das
zweite Telekommunikationsnetz TKN2 wird von einem zweiten Netzwerkbetreiber
MNO2 verwaltet und betrieben. Die Ro-Schnittstelle Ro1 stellt also
eine Ro-Interoperator-Schnittstelle
dar.
-
Für einen
in der 1 nicht dargestellten Nutzer
mit seinem Mobiltelefon stellt das zweite Telekommunikationsnetz
TKN2 das Heimatnetz dar, d. h. der Nutzer ist bei dem zweiten Telekommunikationsnetz
TKN2 registriert und persönliche
Daten des Nutzers (z.B. Nutzerprofil und Abrechnungsdaten) sind in
dem zweiten Telekommunikationsnetz TKN2 beispielsweise in dem Heimat-Authentifizierungsrechner
HAAA und in dem Zahlungssystem ZS gespeichert. Dieser Nutzer befindet
sich nun mit seinem Mobiltelefon im Bereich des ersten Telekommunikationsnetzes
TKN1, er "roamt" also in einem Besucher-Mobilfunknetz
(visited network) TKN1. Will nun dieser Nutzer in dem ersten Telekommunikationsnetz TKN1
einen Dienst in Anspruch nehmen, so sendet er eine entsprechende
Nachricht z. B. über
eine WLAN-Verbindung (WLAN = Wireless Local Area Network) an einen
Zugangsknoten des ersten Telekommunikationsnetzes TKN1, beispielsweise
an ein sog. Access Gateway (in der Figur nicht dargestellt).
-
Von
Seiten des Access Gateways soll nun eine Authentifizierung des Dienstnutzers
vorgenommen werden, daher sendet das Access Gateway eine nach Vorgaben
des Kommunikationsprotokolls RADIUS aufgebaute Anforderungsnachricht
(RADIUS-Request)
an den Authentifizierungsrechner AAA. Die Authentifizierung mittels
RADIUS-Nachrichten als solche ist beispielsweise aus dem Dokument
RFC 2865 bekannt.
-
Anhand
der in dem "RADIUS
request" enthaltenen
Daten erkennt der Authentifizierungsrechner AAA, dass der Nutzer
mit seinem Telekommunikationsendgerät dem zweiten Telekommunikationsnetz
TKN2 zugehörig
ist, dass das zweite Telekommunikationsnetz TKN2 also das Heimatnetz
des Nutzers darstellt. Daraufhin sendet der Authentifizierungsrechner
AAA eine Authentifizierungsanforderung an den Heimat-Authentifizierungsrechner
HAAA des zweiten Telekommunikationsnetzes TKN2. Der Vorgang der
Authentifizierung als solcher kann mittels Schutzmaßnahmen
(beispielsweise mittels des an sich bekannten Verfahrens EAP, EAP
= Extensible Authentication Protocol, siehe RFC 2284) geschützt werden.
-
Wenn
der Nutzer mittels des Heimat-Authentifizierungsrechners HAAA erfolgreich
authentifiziert wurde, dann wird von dem dienstanbietenden Rechner
AS der gewünschte
Dienst für
den Nutzer erbracht. Um eine Abrechnung der Diensterbringung zu
ermöglichen,
teilt der dienstanbietende Rechner AS den Beginn der Diensterbringung
(start of session) mittels der nach RADIUS-Vorgaben aufgebauten Nachricht "RADIUS accounting" dem Zahlungssystem
ZS des zweiten Telekommunikationsnetzes TKN2 mit. Dazu schreibt
der dienstanbietende Rechner AS Startzeit-Daten ("22.08.2003 16:14:23 Uhr") des Dienstes sowie
ggf. weitere den Dienst oder den Dienstnutzer beschreibende Daten
in die nach RADIUS-Vorgaben aufgebaute Nachricht "RADIUS accounting" ein. Diese Nachricht "RADIUS accounting" mit den eingeschriebenen
Daten wird dann über
die zweite Ro-Schnittstelle
Ro1 zu dem Authentifizierungsrechner AAA und von diesem über die Ro-Schnittstelle
Ro1 zu dem Zahlungssystem ZS des zweiten Telekommunikationsnetzes
TKN2 übertragen.
Die Nachricht "RADIUS
accounting" stellt also
ein Transportmittel für
die zu übertragenden Startzeit-Daten
dar.
-
Am
Ende der Diensterbringung (d. h. am Ende der Kommunikations-Session)
schreibt der dienstanbietende Rechner AS Endzeit-Daten ("22.08.2003 16:19:43
Uhr") des Dienstes
sowie ggf. weitere den Dienst oder den Dienstnutzer beschreibende
Daten in die nach RADIUS-Vorgaben aufgebaute Nachricht "Accounting Stop" ein. Diese Nachricht "Accounting Stop" mit den eingeschriebenen Daten
wird dann über
die zweite Ro-Schnittstelle
Ro2 zu dem Authentifizierungsrechner AAA und von diesem über die
Ro-Schnittstelle Ro1 zu dem Zahlungssystem ZS des zweiten Telekommunikationsnetzes TKN2 übertragen.
Dadurch wird dem Zahlungssystem ZS das Ende der Diensterbringung
mitgeteilt.
-
Die
Nachrichten bzw. Funktionen "RADIUS accounting" und "Accounting Stop" als solche sind aus
dem Dokument RFC 2866 bekannt. Diese Nachrichten stellen Kommunikationsgebühren-Abrechnungsanforderungen
(Accounting-Requests) dar, welche über den Authentifizierungsrechner
AAA und über
die Ro-Schnittstelle
Ro1 an das Zahlungssystem ZS des zweiten Telekommunikationsnetzes TKN2 übermittelt
werden. Dieses Zahlungssystem ZS kann auf diese Nachrichten hin
beispielsweise die an sich bekannten "Abrechnungstickets" (z.B. für die Gebührennacherhebungseinrichtung
PP) erstellen oder mittels des Dienstesteuerungspunktes SCP der Dienstnutzung
zugeordnete Kostenbeträge
von einem in dem Speicher SP geführten
Guthabenkonto des Dienstnutzers abbuchen.
-
Bei
der zweiten Ro-Schnittstelle Ro2 zwischen dem dienstanbietenden
Rechner AS und dem Authentifizierungsrechner AAA und bei der Ro-Schnittstelle
Ro1 zwischen dem Authentifizierungsrechner AAA und dem Zahlungssystem
ZS handelt es sich um eine Ro-Schnittstelle, die erfindungsgemäß an das
Nachrichtenübertragungsprotokoll
RADIUS angepasst ist. Eine (nicht an das Nachrichtenübertragungsprotokoll
RADIUS angepasste) Ro-Schnittstelle
als solche ist beispielsweise aus den Standard 3GPPP TS 32.225 "3rd Generation
Partnership Project; Technical Specification Group Service and System
Aspects; Telecommunication management; Charging management; Charging
data description for the IP Multimedia Subsystem (IMS) (Release
5), insbesondere aus Kapitel 6 bekannt. Diese bekannte Ro-Schnittstelle basiert
auf dem Nachrichtenübertragungsprotokoll
Diameter (vgl. Kapitel 6.1 des genannten Standards). Eine Ro-Schnittstelle kann
im Rahmen dieser Erfindung auch als eine Schnittstelle bezeichnet
werden, die den bekannten Ro-Referenzpunkt
nutzt, der aus dem Standard 3GPPP TS 32.225 insbesondere aus Kap.
6 bekannt ist. Erfindungsgemäß wird die
bekannte Ro-Schnittstelle (Ro-Interface) so verändert, dass über sie
nach RADIUS-Vorgaben aufgebaute Nachrichten (RADIUS-Nachrichten) übertragen
werden können;
die Ro-Schnittstelle wird also auf das Protokoll RADIUS abgebildet.
-
Auf
dem Authentifizierungsrechner AAA, welcher einen "Anschlussknoten" der Ro-Schnittstelle
Ro1 bildet (d.h. welcher einen Knoten des Telekommunikationsnetzes
bildet, der mit der Schnittstelle verbunden ist), wird eine Zustandsmaschine
installiert. Diese Zustandsmaschine kann diejenigen sog. Ro-Zustände einnehmen,
die zum Absenden und Empfangen von RADIUS-Nachrichten benötigt werden.
Diese Ro-Zustände
als solche sind beispielsweise aus der Druckschrift TS 32.225 bekannt.
Eine solche Zustandsmaschine kann die Form einer elektronischen
Schaltung oder die Form eines auf einem Rechner des Netzelementes
ablaufenden Programms aufweisen. Die Realisation von Zustandsmaschinen
als solche sind z.B. aus der Standard TS 32.225 bekannt.
-
Eine
zweite derartige Zustandsmaschine wird in dem Zahlungssystem ZS
installiert; das Zahlungssystem ZS bildet einen zweiten "Anschlussknoten" der Ro-Schnittstelle
Ro1. Die aus dem Kapitel 7 des oben genannten Standards TS 32.225
bekannten Schnittstellenattribute (AVP) werden so in ihrer Länge beschränkt, dass
sie der RADIUS-Spezifikation der Schnittstellenattribute entsprechen.
Dies kann beispielsweise dadurch geschehen, dass die Datenfelder
der Schnittstellenattribute entsprechend eingegrenzt genutzt werden
oder die Daten auf mehrere Attribute und ergänzende Attribute verteilt werden. Optional
können
vorteilhafterweise über
die Ro-Schnittstelle
Ro1 lediglich Anforderungen (sog. Requests) des Typs "Kommunikationsgebühren-Abrechnungsanforderung" (Accounting Request) übertragen
werden. Dies vereinfacht die Implementierung des erfindungsgemäßen Verfahrens,
da andere Requests (z.B. Authentication- und Accounting Requests)
in bestimmten Netzkonfigurationen über verschiedene Wege zu ihrem
jeweiligen Ziel geroutet werden. Durch Verwendung lediglich von
Kommunikationsgebühren-Abrechnungsanforderungen
(Accounting Requests) braucht das mögliche Auftreten von verschiedenen
Routingwegen nicht berücksichtigt
werden, wodurch sich ein besonders einfach zu realisierendes Verfahren
ergibt.
-
Um
dennoch verschiedene Typen von Requests über die Ro-Schnittstelle Ro1 übertragen zu können, wird
den Kommunikationsgebühren-Abrechnungsanforderungen
eine Nachrichtentypkennung beigefügt und mit Hilfe dieser Nachrichtentypkennung
wird dem Empfänger
der Kommunikationsgebühren-Abrechnungsanforderung
mitgeteilt, dass er diese Kommunikationsgebühren-Abrechnungsanforderung
als einen anderen Typ von Anforderungen behandeln muss, beispielsweise
als eine Bezahlungs-Anforderung (Charging Request). Mit diesen Nachrichtentypkennungen
kann also individuell der Typ der Anforderungs nachricht festgelegt
werden, obwohl immer der Typ "Kommunikationsgebühren-Abrechnungsanforderung" (Accounting Request) übertragen
wird.
-
Die
an das RADIUS-Protokoll angepaßte bzw.
auf dem RADIUS-Protokoll
basierende Schnittstelle Ro1 ist online-fähig. Die Online-Fähigkeit
entsteht durch einen geeigneten Message Flow und Absprachen zwischen
den Interface-Anschlußknoten hinsichtlich
der Reaktionszeit. Der prinzipiellen Ablauf der Kommunikation (
1. Request, 2. Response usw.) bleibt unverändert. Daher ist es problemlos möglich, mittels
der online-fähigen Ro1/Radius-Schnittstelle
Nachrichten über
eine Kette von AAA-Proxies zu übertragen.
Als Empfänger
kann hierbei ein online-fähiges
Zahlungs-System ("online Charging") fungieren, das
die Ro-Zustandsmaschine (den Message Flow) abbildet. Das Ro-Interface
Ro1 ermöglicht
es aufgrund seiner Online-Fähigkeit,
beim online-Charging ein vorhandenes Kreditlimit vor der Diensterbringung
bestätigen
zu lassen.
-
Mittels
der in der 1 dargestellten
Anordnung ist es also möglich,
z.B. "Authentication
Requests", "Accounting Requests" und "Online Charging Requests" zu übertragen.
Die Ro-Schnittstelle Ro1
eignet sich hierbei insbesondere für ein Interoperator Charging
(zwischen verschiedenen MNOs bzw. deren Partnern). Auch für einen
Nicht-Roaming-Fall ist die in der Figur dargestellte Anordnung einsetzbar,
wobei die Netzelemente dann einem einzigen Telekommunikationsnetz
angehören
(in diesem Fall wäre
dann nur ein Authentifizierungsrechner notwendig). Daher eignet
sich die beschriebene Ro-Schnittstelle
Ro1 (Ro/Radius-Interface) zum Einsatz mit diversen Application-Server-
und Zahlungs-Systemen, unabhängig
davon, ob ein Roaming-Fall vorliegt oder nicht.
-
Die
Verwendung des Protokolls RADIUS ermöglicht es, Daten zur Nutzer-Authentifizierung
und zum Accounting zu übertragen.
Daten für
das Accounting sind dabei z.B. die Zeitpunkte von Dienstbeginn und
Dienstende.
-
In 2 ist ein Nachrichtenfluß zwischen dem
dienstanbietenden Rechner AS und dem Zahlungssystem ZS im Fall eines
sog. "Event Chargings" (mittels Geld oder
mittels Service-Identifikation)
dargestellt. Unter einem "Event
Charging" versteht
man die Übermittlung
einer Zahlungsanforderung für
eine einmalige zeitlich oder vom Volumen her von vornherein begrenzte
Serviceleistung, wobei entweder die Serviceleistung bereits bepreist
ist ("monetäres Event
charging") oder
aber die Serviceleistug durch eine eindeutige Servicenummer identifiziert
wird. Dabei findet ein Interoperator Charging mittels der Ro-Schnittstelle
Ro1 statt. Dazu werden die Nachrichten Accounting Start und Accounting
Stop durch geeignete Attribute ergänzt, die die Bedeutung der Nachricht
genauer fassen (Debit, Reserve, Capture).
-
Event
charging kann auf einer Servicekennung beruhen (Rating beim Home
Operator) oder kann bereits eine Geldmenge enthalten (Rating im
visited Network, "Kaufszenario").
-
Wenn
z.B. ein in dem ersten Telekommunikationsnetz TKN1 roamender Nutzer
eine kostenpflichtige Film-Datei von dem dienstanbietenden Rechner
AS herunterladen will, so sendet er mittels seines Mobiltelefons
eine entsprechende Dienstanforderungs-Nachricht an den dienstanbietenden Rechner
AS. Von der in dem dienstanbietenden Rechner AS (der das erste Netzelement
darstellt) installierten ersten Zustandsmaschine wird eine die Dienstanforderung
betreffende erste Radius-Nachricht N1 über die Ro-Schnittstellen Ro2
und Ro1 an das zweite Netzelement in Form des Zahlungssystems ZS
abgesendet. Als eine solche erste Nachricht (Request) wird eine
Reservierungsnachricht "reservation
(user, service,...)" abgesendet;
in diese Nachricht wurden von dem Rechner AS Informationen über den
Dienstnutzer und den gewünschten
Dienst eingeschrieben. Von der in dem Zahlungssystem ZS (welches
das zweite Netzelement darstellt) installierten zweiten Zustandsmaschine
wird die erste Nachricht empfangen. Daraufhin wertet das Zahlungssystem
ZS die in dem zweiten Telekommunikationsnetz abgespeicherten Abrechnungsdaten
(z.B. die in dem Speicher SP gespeicherten Daten über das
Guthabenkonto (Prepaid-Konto) des Dienstnutzers) aus und erkennt,
dass eine Abrechnung des zu erbringenden Dienstes durchgeführt werden
kann (weil auf dem Guthabenkonto ein ausreichender Guthabenbetrag
verbucht ist). Das Zahlungssystem reserviert einen dem gewünschten
Dienst entsprechenden Teil des Guthabens. Danach wird von der zweiten
Zustandsmaschine eine zweite RADIUS-Nachricht N2 in Form der Nachricht "response (ok,rated
price)" an den Rechner
AS zurückgesendet.
Diese zweite Nachricht enthält
also die Information, dass die Abrechnung des zu erbringenden Dienstes
durchgeführt
werden kann.
-
Die
erste Zustandsmaschine (die seit dem Absenden der ersten Nachricht
auf ein Eintreffen der zweiten Nachricht gewartet hat) empfängt nun
die zweite Nachricht N2 von dem zweiten Netzelement ZS und liest
die mitübertragene
Information aus der zweiten Nachricht aus. Da die Reservierung erfolgreich
verlaufen ist, veranlaßt
der Rechner AS die Erbringung des Dienstes, indem er die gewünschte kostenpflichtige
Film-Datei an den Dienstnutzer übermittelt.
Hätte die
zweite Nachricht dagegen die Information enthalten, dass die Reservierung
nicht erfolgreich verlaufen ist (d.h. dass keine Abrechnung des zu
erbringenden Dienstes durchgeführt
werden kann), dann würde
das erste Netzelement in Form des dienstanbietenden Rechners AS
die Dienstanforderung zurückweisen
und die gewünschte
Film-Datei nicht an den Dienstnutzer übertragen.
-
Nach
der Diensterbringung (d.h. nach der Übertragung der Film-Datei)
sendet der dienstanbietende Rechner AS eine Abbuchungsnachricht
N3 "capture (user,
service)" an das
Zahlungssystem ZS, welches daraufhin den für die Diensterbringung fälligen Betrag
von den reservierten Beträgen
des Guthabenkontos abbucht. Die erfolgreiche Abbuchung wird dem
dienstanbietenden Rechner AS mittels einer Bestätigungsnachricht N4 "response:(ok)" mitgeteilt.
-
In 3 ist ein Nachrichtenfluß zwischen dem
dienstanbietenden Rechner AS und dem Zahlungssystem ZS im Fall eines
kontinuierlichen "Session
Chargings" dargestellt.
Darunter versteht man eine zeitlich wiederholte Zahlungsanforderung
für jeweils
einen Zeit- oder Volumenabschnitt innerhalb einer nicht von vornherein
begrenzten Serviceleistung.
-
Dazu
werden die RADIUS-Accounting-Nachrichten "Accounting Start", "Accounting
Interim" und "Accounting Stop" durch geeignete
Attribute ergänzt, die
den Typ der Nachricht genauer eingrenzt (Reserve, Capture).
-
Session
Charging ist ein kontinuierliches Charging, daß in bestimmten Zeit- oder
Volumenintervallen ein neues Guthaben anfordert. Es basiert auf
einer Service Kennung. Session charging läßt einen Tarifwechsel während der
Erbringung des Dienstes zu (z.B. Standort- oder Tageszeitabhängig).
-
Das
beschriebene Verfahren und die beschriebene Anordnung mit dem Ro-Online-Charging-Interface
kann für
verschiedenste Dienste und Nutzer eingesetzt werden. Das beschriebene
Onli ne-Charging-Interface Ro1 erlaubt ein Rating sowohl auf Seite
des "Visited Operators" als auch im Heimatnetz.
Mittels der beschriebenen Schnittstelle kann ein Netzwerk zwischen
Betreibern gebildet werden, über das
global Charging-Nachrichten
ausgetauscht werden können.
-
Für die Netzwerkoperatoren
ergibt sich bei dem erfindungsgemäßen Verfahren und der erfindungsgemäßen Anordnung
der Vorteil, dass sie nicht die SS7-Signalisierung verwenden brauchen,
die für Voice-Services
optimiert ist, und dass trotzdem ein Roaming möglich ist. Insbesondere für Dienste,
die eine Datenübertragung
mittels IP-Paketen verwenden, wird dadurch eine Altenative zu dem
Signalisierungssystem Nr. 7 (SS7) geschaffen. In IP-Netzen ist das
Signalisierungssystem Nr. 7 nämlich
nur wenig verbreitet. Zudem stehen das erfindungsgemäße Verfahren
und die erfindungsgemäße Anordnung nicht
im Widerspruch zu den gängigen
Telekommunikationsstandards.
-
Die
Nutzung des Protokolls RADIUS als Transportmittel auch für z.B. Accounting-
und Online-Charging-Daten erlaubt es, eine innerhalb von Telekommunikationsnetzen
ursprünglich
zur Übertragung
von für
eine einzige Art von RADIUS-Nachrichten (nämlich für Authentifizierungszwecke
genutzte RADIUS-Nachrichten)
vorgesehene und damit gelegentlich bereits vorhandene Infrastruktur
zu nutzen. Diese Infrastruktur kann vorteilhafterweise bei dem erfindungsgemäßen Verfahren
mitbenutzt werden, um die RADIUS-Nachrichten zu transportieren.
Dadurch wird eine einfache und kostengünstige Realisierung des Verfahrens
möglich
und es kann eine einheitliche Schnittstelle für z.B. Interoperator-Charging
eingerichtet werden.
-
Ein
Vorteil des erfindungsgemäßen Verfahrens
und der erfindungsgemäßen Anordnung
für den Operator
liegt darin, daß über eine
einheitliche und zu einem großen
Teil bereits vorhandene Architektur z.B. die Charging-Daten aller
Subscriber übermittelt werden
können.
Dabei können
verschiedene Subskriptions-Modelle
(Prepaid-Nutzer, Postpaid-Nutzer) der einzelnen Teilnehmer berücksichtigt
werden, wenn alle Charging-Daten an ein Online-Charging-System gesendet
werden. Dieses System kann (aufgrund der Kenntnis über die
Nutzerdaten) automatisch z.B. für
Postpaid-Nutzer ohne Kreditlimit eine Bestätigung vornehmen.
-
Dieses
Verfahren und diese Anordnung sind einfach zu realisieren, da nur
ein einheitlicher Weg von einem Datenerfassungspunkt bis zu dem
Zahlungssystem realisiert werden muß. Das Rating eines Requests
kann daher beim Netzwerkbetreiber des Heimat-Mobilfunknetzes auf
Basis der übermittelten Daten
in gleicher Weise für
alle Subscriber erfolgen, unabhängig
davon, ob ein Roaming vorliegt oder nicht.
-
Ein
Vorteil für
den Betreiber besteht darin, dass – wie oben bereits erwähnt – eine bereits
für die Authentifizierung
innerhalb von Telekommunikationsnetzen oftmals vorhandene RADIUS-Infrastruktur auch
für das Übertragen
von Daten (z.B. von elektronische Zahlungen betreffenden Daten – "Charging-Data") über Telekommunikationsnetzgrenzen hinweg
mitgenutzt werden kann. Dadurch wird der Investitions- und Managementaufwand
reduziert bei gleichzeitiger Erweiterung der möglichen Dienst-Features. Durch
die Nutzung einheitlicher Infrastruktur-Einrichtungen der Telekommunikationsnetze
vereinfachen sich auch die Abläufe.
Es wird also ein universell anwendbares Datentransportverfahren
und eine entsprechende Anordnung angegeben, wodurch sich Kosten
für projektspezifische
Lösungen minimieren
lassen.