DE10332558B4

DE10332558B4 - Verfahren zum Erkennen von Abrechnungsdatensätzen

Info

Publication number: DE10332558B4
Application number: DE10332558A
Authority: DE
Inventors: Jens Lehmann; Jens Schendel
Original assignee: Siemens AG
Current assignee: Nokia Solutions and Networks GmbH and Co KG
Priority date: 2003-07-11
Filing date: 2003-07-11
Publication date: 2006-06-01
Anticipated expiration: 2023-07-12
Also published as: DE10332558A1; US20050030908A1

Abstract

Verfahren zum Erkennen von eine Dienstnutzung (IP2) betreffenden Abrechnungsdatensätzen, die von verschiedenen Netzelementen mindestens eines Telekommunikationsnetzes erzeugt werden,
wobei eine der Dienstnutzung zugeordnete Datenpaketfolge (IP2) über das mindestens eine Telekommunikationsnetz unter Nutzung eines Dienstrechnerzugangsgateways (SSG) zwischen einem dienstnutzenden Kommunikationsendgerät (KEG) und einem dienstanbietenden Dienstrechner (DR2) übertragen wird, wobei bei dem Verfahren
– von einem ersten Netzelement (GGSN) ein erster Abrechnungsdatensatz (GGSN-CDR1) erzeugt wird, der die Datenpaketfolge (IP2) betreffende Abrechnungsinformationen enthält,
– von dem ersten Netzelement dem ersten Abrechnungsdatensatz eine erste eindeutige Kennung (K1) zugeordnet wird,
dadurch gekennzeichnet, dass
– diese erste eindeutige Kennung (K1) beschreibende erste Kennungsinformationen über das Dienstrechnerzugangsgateway (SSG) an ein Authorisierungsnetzelement (AAA) übertragen werden,
– von dem Authorisierungsnetzelement ein Datenelement (CL) des Datenübertragungsprotokolls "RADIUS" erzeugt wird, welches diese Kennungsinformationen enthält und welches nach dessen Erzeugung unveränderlich ist,
– dieses Datenelement (CL) einem zweiten Abrechnungsdatensatz (IP-flow-CDR21, IP-flow-CDR22) beigefügt wird, welcher aufgrund...

Description

Die Erfindung betrifft ein Verfahren zum Erkennen von eine Dienstnutzung betreffenden Abrechnungsdatensätzen, die von verschiedenen Netzelementen mindestens eines Telekommunikationsnetzes erzeugt werden.

Telekommunikationsteilnehmern moderner Telekommunikationsnetze wird zunehmend eine große Anzahl an Diensten zur Nutzung angeboten. Bei einer derartigen Dienstnutzung werden beispielsweise auf eine Anforderung eines Kommunikationsendgerätes (z. B. Handy, persönlicher digitaler Assistent (PDA) oder tragbare Computer mit Mobilfunkschnittstelle) hin von einem Dienstrechner (einem Dienstserver, beispielsweise einem Internetserver, der mit dem Telekommunikationsnetz verbunden ist) eine Menge an Daten zu dem Kommunikationsendgerät übermittelt (z.B. Filmdaten, Musikdaten, Nachrichtendaten, Börsenkurse, Unternehmensnachrichten etc.).

Bei solchen Dienstnutzungen werden also Daten in beiden Richtungen übertragen zwischen dem Kommunikationsendgerät und dem dienstanbietenden Dienstrechner. In modernen Telekommunikationsnetzen wird bei einer solchen Dienstnutzung zur Durchführung der Datenübertragungen eine Datenpaketfolge (IP-Flow) in beiden Richtungen zwischen dem Kommunikationsendgerät und dem Dienstrechner übertragen. Derartige paketorientierte Datenfolgen treten beispielsweise in Mobil-Telekommunikationsnetzen auf, welche nach dem GPRS-(General Packet Radio Service) oder UMTS-(Universal Mobile Telecommunication System) Standard arbeiten. Um dem dienstnutzenden Kommunikationsendgerät bzw. dessen Betreiber eine Dienstnutzung in Rechnung zu stellen, können von verschiedenen Netzelementen des Telekommunikationsnetzes (bzw. von verschiedenen Netzelementen meh rerer verbundener Telekommunikationsnetze, die an der Dienstnutzung beteiligt sind) Abrechnungsdatensätze (sog. Charging Data Records, CDR) erzeugt werden. Da diese Netzelemente solche Abrechnungsdatensätze unabhängig voneinander erzeugen, können diese Abrechnungsdatensätze jeweils Informationen enthalten, die schon in anderen Abrechnungsdatensätzen abgelegt sind. Daher besteht Bedarf nach einer Möglichkeit, solche Abrechnungsdatensätze zu identifizieren, welche eine einzige Dienstnutzung betreffende Informationen enthalten. Es sollen also solche Datensätze erkannt werden, die alle eine bestimmte Dienstnutzung betreffen.

Aus der internationalen Patentanmeldung WO 02/096025 A1 ist ein Verfahren bekannt, bei dem von einem Gateway GPRS Support Node (GGSN) und einem Serving GPRS Support Node (SGSN) jeweils sogenannte Call Detail Records erzeugt und an ein Abrechnungs-Gateway übermittelt werden. Das Abrechnungs-Gateway verarbeitet diese Call Detail Records und übermittelt Rechnungsinformationen an einen Rechnungsknoten.

Die oben genannte Aufgabe wird erfindungsgemäß gelöst durch ein Verfahren zum Erkennen von eine Dienstnutzung betreffenden Abrechnungsdatensätzen, die von verschiedenen Netzelementen mindestens eines Telekommunikationsnetzes erzeugt werden, wobei eine der Dienstnutzung zugeordnete Datenpaketfolge über das mindestens eine Telekommunikationsnetz unter Nutzung eines Dienstrechnerzugangsgateways zwischen einem dienstnutzenden Kommunikationsendgerät und einem dienstanbietenden Dienstrechner übertragen wird, bei dem von einem ersten Netzelement ein erster Abrechnungsdatensatz erzeugt wird, der die Datenpaketfolge betreffende Abrechnungsinformationen enthält, von dem ersten Netzelement dem ersten Abrechnungsdatensatz eine erste eindeutige Kennung zugeordnet wird, diese erste eindeutige Kennung beschreibende erste Kennungsinformationen über das Dienstrechnerzugangsgateway an ein Authorisierungsnetzelement übertragen werden, von dem Authorisierungsnetzelement ein Datenelement des Datenübertragungsprotokolls "RADIUS" erzeugt wird, welches diese Kennungsinformationen enthält und welches nach dessen Erzeugung unveränderlich ist, dieses Datenelement einem zweiten Abrechnungsdatensatz beige fügt wird, welcher aufgrund der Übermittlung der Datenpaketfolge über das Dienstrechnerzugangsgateway an den Dienstrechner erzeugt wird, der erste Abrechnungsdatensatz und der zweite Abrechnungsdatensatz zu einem Datensatzerkennungsknoten übertragen werden, von dem Datensatzerkennungsknoten die ersten Kennungsinformationen aus dem Datenelement des zweiten Abrechnungsdatensatzes ausgelesen werden, und anhand der ersten Kennungsinformationen des zweiten Abrechnungsdatensatzes und der ersten Kennung des ersten Abrechnungsdatensatzes erkannt wird, dass der erste Abrechnungsdatensatz und der zweite Abrechnungsdatensatz ein und derselben Dienstnutzung zugehörig sind. Hierbei ist insbesondere vorteilhaft, dass die Kennungsinformationen, welche die erste Kennung eindeutig beschreiben, in das unveränderliche Datenelement des Protokolls "RADIUS" verpackt werden. Dadurch ist es möglich, diese Kennungsinformationen vor einer unerwünschten Veränderung zu schützen und in den zweiten Abrechnungsdatensatz einzufügen. Anhand dieses Datenelementes und der ersten eindeutigen Kennung können daraufhin in eindeutiger Weise von dem Datensatzerkennungsknoten der erste Abrechnungsdatensatz und der zweite Abrechnungsdatensatz identifiziert werden; es wird erkannt, dass beide Abrechnungsdatensätze Abrechnungsinformationen über die eine Dienstnutzung enthalten.

Das Verfahren kann vorteilhafterweise so ausgestaltet sein, dass das von dem Authorisierungsnetzelement erzeugte Datenelement an das Dienstrechnerzugangsgateway übertragen wird. Vorteilhafterweise liegt dann das Datenelement bei dem Dienstrechnerzugangsgateway vor, wenn aufgrund der Übermittlung der Datenpaketfolge über das Dienstrechnerzugangsgateway an den Dienstrechner der zweite Abrechnungsdatensatz erzeugt wird.

Das Verfahren kann so ablaufen, dass als erster Abrechnungsdatensatz ein solcher erster Abrechnungsdatensatz erzeugt wird, der die Abrechnungsinformationen über die eine Datenpaketfolge und Abrechnungsinformationen über weitere das erste Netzelement passierende und das Kommunikationsendgerät betreffende Datenpaketfolgen in aufsummierter Form enthält. Bei dieser Ausgestaltung können vorteilhafterweise auch solche ersten Netzelemente bei dem Verfahren verwendet werden, welche nicht in der Lage sind, Abrechnungsinformationen jeweils datenpaketfolgen-individuell (d. h. dienstindividuell) zu ermitteln, sondern die lediglich in der Lage sind, Abrechnungsinformationen über mehrere Datenpaketfolgen in aufsummierter bzw. zusammengefasster Form zu ermitteln und in einen ersten Abrechnungsdatensatz einzuschreiben.

Dabei kann der erste Abrechnungsdatensatz die Abrechnungsinformation als aufsummierte Übertragungszeitinformationen und/oder aufsummierte Datenvolumeninformationen enthalten.

Das Verfahren kann auch so ausgestaltet sein, dass als zweiter Abrechnungsdatensatz ein solcher zweiter Abrechnungsdatensatz erzeugt wird, der Abrechnungsinformationen über genau die eine zwischen dem Kommunikationsendgerät und dem Dienstrechner übertragene Datenpaketfolge enthält. Damit kann vorteilhafterweise das erfindungsgemäße Verfahren auch gemeinsam mit solchen Netzelementen angewendet werden, welche in der Lage sind, einzelne einem Dienst zugeordnete Datenpaketfolgen zu unterscheiden und Abrechnungsinformationen über genau eine Datenpaketfolge, welche genau einen Dienst betrifft, bereitzustellen und in Abrechungsdatensätze einzuschreiben.

Das Verfahren kann erfindungsgemäß so ablaufen, dass der zweite Abrechnungsdatensatz erzeugt wird, indem aufgrund der Übermittlung der Datenpaketfolge über das Dienstrechnerzugangsgateway an den Dienstrechner von dem Dienstrechnerzugangsgateway das Datenelement an ein Abrechnungssystem übermittelt wird, von welchem der zweite Abrechnungsdatensatz erzeugt und diesem zweiten Abrechnungsdatensatz das Datenelement beifügt wird.

Dabei kann von dem Dienstrechnerzugangsgateway bei Beginn und/oder Ende der Übertragung der Datenpaketfolge gemeinsam mit dem Datenelement die Datenpaketfolge betreffende Übertragungszeitinformationen und/oder Datenvolumeninformationen zu dem Abrechnungssystem übermittelt werden, und anhand dieser Übertragungszeitinformationen und/oder Datenvolumeninformationen von dem Abrechnungssystem der zweite Abrechnungsdatensatz erzeugt werden. Mittels der beiden zuletzt genannten Ausführungsformen des erfindungsgemäßen Verfahrens können in vorteilhafter und sehr einfacher Weise von dem Abrechnungssystem zweite Abrechnungsdatensätze erzeugt werden, sobald das Dienstrechnerzugangsgateway eine einzelne Datenpaketfolge identifiziert und diese Datenpaketfolge betreffende Daten Abrechnungsinformationen (Übertragungszeitinformationen und/oder Datenvolumeninformationen) ermittelt hat.

Das erfindungsgemäße Verfahren kann auch so ablaufen, dass der zweite Abrechnungsdatensatz erzeugt wird, indem aufgrund der Übermittlung der Datenpaketfolge über das Dienstrechnerzugangsgateway an den Dienstrechner von dem Dienstrechnerzugangsgateway das Datenelement an das Authorisierungsnetzelement übermittelt wird, von welchem der zweite Abrechnungsdatensatz erzeugt und diesem zweiten Abrechnungsdatensatz das Datenelement beifügt wird.

Dabei kann von dem Dienstrechnerzugangsgateway bei Beginn und/oder Ende der Übertragung der Datenpaketfolge gemeinsam mit dem Datenelement die Datenpaketfolge betreffende Übertragungszeitinformationen und/oder Datenvolumeninformationen zu dem Authorisierungsnetzelement übermittelt werden, und anhand dieser Übertragungszeitinformationen und/oder Datenvolumeninformationen von dem Authorisierungsnetzelement der zweite Abrechnungsdatensatz erzeugt werden. Bei den beiden letztgenannten Ausgestaltungsmöglichkeiten des erfindungsgemäßen Verfahrens ist vorteilhafterweise kein eigenes Abrechnungssystem notwendig, um den zweiten Abrechnungsdatensatz zu erzeugen, sondern dieser zweite Abrechnungsdatensatz kann von dem in Kommunikationsnetzen üblicherweise sowieso vorhandenen Authorisierungsnetzelement (beispielsweise einem AAA-Server) erzeugt werden.

Das erfindungsgemäße Verfahren kann auch so ablaufen, dass bei Aufbau und/oder Abbau eines Datentunnels zur Übertragung der einen Datenpaketfolge von dem ersten Netzelement gemeinsam mit der Kennung den Datentunnel betreffende Übertragungszeitinformationen und/oder den Datentunnel betreffende Datenvolumeninformationen zu dem Authorisierungsnetzelement übermittelt werden, und anhand dieser Übertragungszeitinformationen und/oder Datenvolumeninformationen von dem Authorisierungsnetzelement ein dritter Abrechnungsdatensatz erzeugt wird und diesem dritten Abrechnungsdatensatz die Kennung zugeordnet wird. Bei dieser Ausgestaltungsform wird das Authorisierungsnetzelement vorteilhafterweise auch dazu benutzt, einen dritten Abrechnungsdatensatz zu erzeugen, welcher den Datentunnel betreffende Übertragungszeitinformationen und/oder den Datentunnel betreffende Datenvolumeninformationen enthält. Auch dieser dritte Abrechnungsdatensatz wird erfindungsgemäß mit der Kennung versehen, damit dieser später von dem Erkennungsknoten als zu der Dienstnutzung gehörig erkannt werden kann.

Das Verfahren kann so ausgestaltet sein, dass der dritte Abrechnungsdatensatz zu einem Datensatzerkennungsknoten übertragen wird, von dem Datensatzerkennungsknoten die Kennung aus dem dritten Abrechnungsdatensatz ausgelesen wird, und anhand der Kennung erkannt wird, dass der dritte Abrechnungsdatensatz, der zweite Abrechnungsdatensatz und der erste Abrechnungsdatensatz ein und derselben Dienstnutzung zugehörig sind.

Vorteilhafterweise kann als erstes Netzelement ein "Serving GPRS Support Node" oder ein "Gateway GPRS Support Node" verwendet werden. Dadurch wird vorteilhafterweise ermöglicht, das erfindungsgemäße Verfahren bei einem nach GPRS-Vorgaben ausgestalteten Telekommunikationsnetz zu nutzen (GPRS = General Packet Radio Service).

Als Authorisierungsnetzelement kann ein "Authentication, Authorisation and Accounting Server" verwendet werden. Hierbei ist von Vorteil, dass der „Authentication, Authorisation and Accounting Server" (AAA Server), welcher in einer Vielzahl von Kommunikationsnetzen bereits vorhanden ist, als Authorisierungsnetzelement eingesetzt werden kann.

Erfindungsgemäß können die ersten Kennungsinformationen eine das erste Netzelement identifizierende Adresse und ein den Datentunnel identifizierendes Kennzeichen umfassen. Dadurch wird ein eindeutiges Erkennen der jeweiligen Abrechnungsdatensätze ermöglicht.

Das Verfahren kann erfindungsgemäß so ausgestaltet sein, dass als Datenelement, welches die Kennungsinformationen enthält, von dem Authorisierungsnetzelement ein nach dem Datenübertragungsprotokolls "RADIUS" aufgebautes Datenelement "class" erzeugt wird. Eine derartige Ausgestaltung des Datenelementes ermöglicht es, das erfindungsgemäße Verfahren in existierenden Telekommunikationsnetzen einzusetzen, ohne dass die dort üblichen und zum Teil standardisierten Nachrichtenübertragungsschritte beeinträchtigt werden. Daher lässt sich das erfindungsgemäße Verfahren sehr einfach, schnell und kostengünstig realisieren.

Zur weiteren Erläuterung des erfindungsgemäßen Verfahrens ist in der einzigen Figur ein Ausführungsbeispiel eines Telekommunikationsnetzes zusammen mit beispielhaften Schritten des erfindungsgemäßen Verfahrens dargestellt.
In der Figur ist schematisch ein Telekommunikationsnetz in Form eines Mobilfunknetzes dargestellt, welches mit einem dienstnutzenden Kommunikationsendgerät KEG (in diesem Ausführungsbeispiel in Form eines Mobiltelefons) verbunden ist. Mittels dieses Kommunikationsendgerätes KEG kann eine Dienstnutzung vorgenommen werden, indem ein von einem Dienstrechner DR2 angebotener Dienst in Anspruch genommen wird. Ein derartiger Dienst kann beispielsweise in der Lieferung von Video- oder Audio-Dateien von dem Dienstrechner DR2 zu dem Kommunikationsendgerät KEG bestehen. Zur Nutzung beispielsweise des Video-Daten-Lieferungsdienstes wird eine Datenpaketfolge IP2 zwischen dem Dienstrechner DR2 und dem Kommunikationsendgerät KEG übertragen. Dabei können die einzelnen Datenpakete der einen Datenpaketfolge bidirektional sowohl vom Kommunikationsendgerät KEG zum Dienstrechner DR2 als auch in umgekehrter Richtung übertragen werden. Weiterhin kann mittels des Kommunikationsendgerätes KEG auch ein weiterer Dienst des Dienstrechners DR1 genutzt werden. Dazu wird eine Datenpaketfolge IP1 zwischen dem Kommunikationsendgerät KEG und dem Dienstrechner DR1 übertragen. In ähnlicher Weise kann von dem Kommunikationsendgerät KEG auch ein dritter Dienst eines weiteren Dienstrechners DR3 genutzt werden; die Dienstnutzung erfolgt mittels einer Datenpaketfolge IP3, welche zwischen dem Kommunikationsendgerät KEG und dem Dienstrechner DR3 übertragen wird.
Die drei Datenpaketfolgen IP1, IP2 und IP3 werden über weite Strecken des Telekommunikationsnetzes in Form eines Datentunnels PDP (eines sog. PDP-Kontextes, Packet-Data-Protocol-Context) übertragen. Der Datentunnel PDP ist in der Figur symbolisch als eine Röhre dargestellt, welche die drei Datenpaketfolgen IP1, IP2 und IP3 umfasst.
Im Folgenden soll beispielhaft die Datenpaketfolge IP2 betrachtet werden. Datenpakete dieser Datenpaketfolge gelangen vom Kommunikationsendgerät KEG in bekannter Weise über eine nicht dargestellte Luftschnittstelle, Basisstation etc. zu einem ersten Netzelement in Form einer Vermittlungsstelle SGSN für Datenpakete (SGSN = Serving GPRS Support Node). Diese Vermittlungsstelle SGSN leitet (routet) die Datenpakete zu einem Netzübergangsknoten GGSN (GGSN = Gateway GPRS Support Node). Der Netzübergangsknoten befindet sich im Vermittlungsnetz (Core Network) und hat als ein Gateway in GPRS- und UMTS-Netzen die Aufgabe, den Datenverkehr zwischen dem Vermittlungsnetz (Core Network) und externen paketvermittelten Übertragungsnetzen (Packet Data Network, PDN) des Mobilfunknetzes zu koordinieren. Sowohl die Vermittlungsstelle SGSN als auch der Netzübergangsknoten GGSN oder beide können im vorliegenden Ausführungsbeispiel die Funktion des ersten Netzelementes übernehmen. Wenn die Vermittlungsstelle SGSN oder der Netzübergangsknoten GGSN später in dem dargestellten Verfahrensablauf einen ersten Abrechnungsdatensatz SGSN-CDR1 oder GGSN-CDR1 erzeugen, dann fügt die Vermittlungsstelle SGSN bzw. der Netzübergangsknoten GGSN diesem ersten Abrechnungsdatensatz eine erste eindeutige Kennung K1 zu; sie ordnet diese Kennung dem Abrechnungsdatensatz zu. Die Kennung K1 enthält GGSN-spezifische Informationen, nämlich die weltweit eindeutige Adresse („GGSN-Adresse") des Netzübergangsknotens GGSN im Format IPv4 oder IPv6. Weiterhin enthält die Kennung K1 eine datenpaketfolgenindividuelle Abrechnungs-ID (Charging-ID). Die GGSN-Adresse zusammen mit der Abrechnungs-ID ergeben einen weltweit einzigartigen und eindeutigen Identifikator für den Datentunnel PDP. Dieser Identifikator wird als Kennung K1 dem ersten Abrechnungsdatensatz zugeordnet.
Vom Netzübergangsknoten GGSN gelangen die Datenpakete zu einem Dienstrechnerzugangsgateway SSG (SSG = Service Selection Gateway). Die Vermittlungsstelle SGSN und der Netzübergangsknoten GGSN können allerdings die Datenpaketfolge IP2 nicht als solche erkennen, sondern sie übermitteln die Datenpaketfolge IP2 lediglich zusammengefasst mit den beiden anderen Datenpaketfolgen IP1 und IP3 innerhalb des Datentunnels PDP. Der Netzübergangsknoten GGSN leitet die Datenpaketfolgen IP1, IP2 und IP3 zu dem Dienstrechnerzugangsgateway SSG, ohne die Datenpaketfolgen IP1, IP2 und IP3 zu unterscheiden oder gesondert zu behandeln. Dabei liegt aus Sicht des Netzübergangsknotens GGSN das Dienstrechnerzugangsgateway SSG in einem externen Paketvermittlungsdatennetz. Erst das Dienstrechnerzugangsgateway SSG ist in der Lage, die einzelnen Datenpaketfolgen IP1, IP2 und IP3 den einzelnen Diensten zuzuordnen. Über das Dienstrechnerzugangsgateway SSG wird die Datenpaketfolge IP2 zu dem entsprechenden Dienstrechner DR2 weitervermittelt.
Das Dienstrechnerzugangsgateway SSG ist über eine RADIUS-Schnittstelle mit einem Abrechnungssystem CS verbunden. Mit Hilfe dieses Abrechnungssystems CS wird ein Abrechnungsdatensatz IP-flow-CDR21 erzeugt, welcher genau eine einzelne Datenpaketfolge (im Beispiel die Datenpaketfolge IP2) betrifft. Über eine weitere RADIUS-Schnittstelle ist das Dienstrechnerzugangsgateway SSG mit einem Authorisierungsnetzelement AAA (AAA Server) verbunden. Von dem Authorisierungsnetzelement AAA wird ein Abrechnungsdatensatz IP-flow-CDR22 erzeugt, welcher auch genau die Datenfolge IP2 betrifft.
Sowohl der Datensatz IP-Flow-CDR21 als auch der Abrechnungsdatensatz IP-Flow-CDR22 stellen im Rahmen der vorliegenden Erfindung zweite Abrechnungsdatensätze dar, die alternativ oder auch beide gemeinsam bei dem erfindungsgemäßen Verfahren erzeugt werden.
Von der Vermittlungsstelle SGSN wird ein Abrechnungsdatensatz SGSN-CDR1 erzeugt, welcher Abrechnungsinformationen über die drei Datenpaketfolgen IP1, IP2 und IP3 in aufsummierter Form enthält. Derartige Abrechnungsinformationen stellen „Umfangsinformationen" dar, welche Informationen über einen Gesamtumfang der übertragenen Daten des Datentunnels enthalten. Derartige Umfangsinformationen sind beispielsweise die Datenmenge, welche während einer bestimmten Zeitdauer insgesamt über den Datentunnel übertragen wird oder die Gesamtzeit, wie lange ein derartiger Datentunnel aufgebaut ist.
Von dem Netzübergangsknoten GGSN werden Abrechnungsdatensätze GGSN-CDR1 erzeugt, welche ähnlich dem Abrechnungsdatensatz SGSN-CDR1 aufgebaut ist. Sowohl die Abrechnungsdatensätze SGSN-CDR1 als auch die Abrechnungsdatensätze GGSN-CDR1 stellen im Rahmen der Erfindung erste Abrechnungsdatensätze dar. Insbesondere können die Vermittlungsstelle SGSN und der Netzübergangsknoten GGSN zeitlich parallel zueinander die Abrechnungsdatensätze erzeugen.
Als weitere Möglichkeit kann von dem Authorisierungsnetzelement AAA ein weiterer Abrechnungsdatensatz IP-PDP-CDR3 erzeugt werden, welcher Abrechnungsinformationen in aufsummierter Form über den Datentunnel PDP enthält.
Nach ihrer Erzeugung werden die Abrechnungsdatensätze SGSN-CDR1, GGSN-CDR1, IP-Flow-CDR21, IP-Flow-CDR22 und IP-PDP-CDR3 zu einem Erkennungsknoten MD (Mediation Device) übertragen. Dieser Erkennungsknoten erkennt, dass sämtliche genannten Abrechnungsdatensätze zu der einen Dienstnutzung des Dienstrechners DR2 zugehörig sind und damit auch der Übertragung der Datenpaketfolge IP2 zugehörig sind. Daraufhin kann der Erkennungsknoten MD die Abrechnungsinformationen der einzelnen Abrechnungsdatensätze zusammenfassen und weiter verarbeiten und ein Ergebnis dieser Zusammenfassung und Weiterverarbeitung an ein Rechnungszentrum BC (Billing Center) übermitteln. In einem solchen Rechnungszentrum BC können beispielsweise Guthabenkonten des Kommunikationsendgerätes KEG verwaltet werden, welche mit dem entsprechenden Abrechnungsbetrag belastet werden. Bei dem Rechnungszentrum BC kann es sich aber beispielsweise auch um einen Rechner eines externen Bankinstituts handeln, bei welchem für das Kommunikationsendgerät KEG bzw. für dessen Halter ein Konto geführt wird.
Im folgenden wird die Erzeugung der Abrechnungsdatensätze und die Erkennung der die jeweils eine Dienstnutzung betreffenden Abrechnungsdatensätze im Erkennungsknoten MD genauer erläutert.
Nachdem ein Nutzer des Kommunikationsendgerätes KEG beispielsweise aus einem an dem Endgerät angezeigten Menü einen Dienst ausgewählt und eine Anforderung für eine Nutzung dieses Dienstes an das Telekommunikationsnetz gesendet hat (Pfeil 0), sendet die Vermittlungsstelle SGSN eine Aufforderung zum Aktivieren des Datentunnels PDP an den Netzübergangsknoten GGSN (Pfeil 1: PDP Context Activation Request). Der Netzübergangsknoten GGSN sendet daraufhin eine Aufforderung zur Authentifizierung des Datentunnels PDP über das Dienstrechnerzugangsgateway SSG an das Authorisierungsnetzelement AAA. Mit dieser Nachricht wird eine Kennungsinformation „Acct-Session-ID (PDP)" mit an das Authorisierungsnetzelement AAA übermittelt. Die Kennungsinformation "Acct-Session-ID (PDP)" enthält die GGSN-Adresse und die Charging-ID oder Informationen über die GGSN-Adresse und die Charging-ID (Nachricht 2: RADIUS: Access Request (Acct-Session-ID(PDP))).
Das Authorisierungsnetzelement AAA erhält die die erste eindeutige Kennung K1 beschreibenden ersten Kennungsinformationen in Form der „Act-Session-ID (PDP)" und verpackt diese Kennungsinformationen in ein Datenelement CL des Datenübertragungsprotokolls „RADIUS", welches die Form des an sich bekannten Datenelementes „Class" des RADIUS-Protokolls aufweist. Dieses Datenelement CL darf laut RADIUS-Spezifikation nach dessen Erzeugung nicht mehr verändert werden. Es ist damit nach seiner Erzeugung unveränderlich und daher vor einer versehentlichen oder mutwilligen Veränderung bzw. Verfälschung geschützt.
Daraufhin sendet das Authorisierungsnetzelement AAA eine Genehmigungsnachricht „Access Accept" an das Dienstrechnerzugangsgateway SSG zurück. Diese Genehmigungsnachricht enthält neben einer Bezeichnung des jeweiligen Dienstes das Datenelement CL (Nachricht 3: RADIUS: Access Accept (IP2, Class)). Somit liegt das Datenelement CL nun bei dem Dienstrechnerzugangsgateway SSG vor.
Daraufhin werden dienstspezifische Daten von dem Authorisierungsnetzelement AAA an das Dienstrechnerzugangsgateway SSG übermittelt, beispielsweise eine Bezeichnung des Dienstes und eine Internetadresse des Dienstrechners (Nachricht 4: Service Profile Retrieval (IP2, Destination IP Address, [optionally containing an alternativ AAA-Server respectively Charging Server]).
Als nächster Schritt wird von dem Dienstrechnerzugangsgateway 5SG die Genehmigungsnachricht 3 (welche auch das Datenelement CL enthält) an den Netzübergangsknoten GGSN übermittelt. Der Netzübergangsknoten GGSN speichert das Datenelement CL ab (Nachricht 5: RADIUS: Access Accept (forward of message #3 containing class attribute)).
Jetzt öffnet der Netzübergangsknoten GGSN den Datentunnel PDP für die Datenübertragung (Nachricht 6: Open GPRS Tunnel). Diesen Datentunnel PDP betreffend sendet der Netzübergangsknoten GGSN als nächstes eine Aufforderungsnachricht zum Erfassen von Abrechnungsinformationen betreffend den Datentunnel PDP an das Authorisierungsnetzelement AAA, diese Aufforderungsnachricht enthält neben den Kennungsinformationen "Acct-Session-ID (PDP)" auch das Datenelement CL (Nachricht 7: RADIUS: Accounting Start Request (Acct-Session-ID(PDP), class)). Das Authorisierungsnetzelement AAA ist nun „scharf geschaltet" und bereit, den Datentunnel PDP betreffende Abrechnungsinformationen zu erfassen. Dies wird dem Netzübergangsknoten GGSN mittels einer Quittungsnachricht (Nachricht 8: RADIUS: Accounting Start Response) mitgeteilt.
Daraufhin wird vom Netzübergangsknoten GGSN gesteuert eine Verbindung aufgebaut, um die Datenpaketfolge IP2 zwischen dem Dienstrechner DR2 und dem Kommunikationsendgerät KEG zu übertragen (Nachricht 12: Connection Set-up (IP-traffic)). Nun werden die entsprechenden Dienstdaten (im Beispiel also die bei der Diensterbringung zu übertragenden Videodaten) von dem Dienstrechner DR2 über das Dienstrechnerzugangsgateway SSG, den Netzübergangsknoten GGSN und die Vermittlungsstelle SGSN an das Kommunikationsendgerät KEG übertragen. Bei dieser Datenübertragung erfasst das Dienstrechnerzugangsgateway SSG Abrechungsinformationen in Form von Informationen über genau die zwischen dem Dienstrechner 2 und dem Kommunikationsendgerät KEG übertragene Datenpaketfolge IP2. Solche Abrechungsinformationen sind beispielsweise Übertragungszeitinformationen („die Übertragung der Videodaten IP2 hat 200 sec in Anspruch genommen") und/oder Datenvolumeninformationen („die Übertragung der Videodaten IP2 hat eine Datenmenge an 65 MB umfasst"). Diese Abrechnungsinformationen werden gemeinsam mit dem Datenelement CL zu dem Abrechnungssystem CS übertragen. Dabei kann die Übertragung der Abrechnungsinformationen zu Beginn, während oder am Ende der Übertragung der Datenpaketfolge IP2 stattfinden, ggf. berechnet das Abrechnungssystem CS die relevanten Abrechnungsdaten durch Differenzbildung der erfassten Werte am Ende und der erfassten Werte am Beginn der Übertragung.
Das Abrechnungssystem CS wird die die Datenpaketfolge IP2 betreffenden Abrechnungsinformationen aus den Übertragungs zeitinformationen und Datenvolumeninformationen ermitteln und zu einem späteren Zeitpunkt (siehe unten) den zweiten Abrechnungsdatensatz IP2-Flow-CDR21 erzeugen und mit diesen Abrechnungsinformationen versehen. Zusätzlich wird das Datenelement CL dem zweiten Abrechnungsdatensatz IP-Flow-CDR21 beigefügt.
In analoger Weise sendet das Dienstrechnerzugangsgateway SSG alternativ oder zusätzlich die die Datenpaketfolge IP2 betreffenden Abrechnungsinformationen an das Authorisierungsnetzelement AAA, woraufhin dieses (ähnlich wie das Abrechnungssystem CS) zu einem späteren Zeitpunkt (siehe unten) den zweiten Datensatz IP-Flow-CDR22 erzeugt und diesem Datensatz die Abrechnungsinformationen und das Datenelement CL beifügt.
Sobald die Datenpaketfolge IP2 innerhalb des Datentunnels PDP über den Netzübergangsknoten GGSN übertragen wird, ermittelt dieser Netzübergangsknoten GGSN Abrechnungsinformationen über den Datentunnel PDP, mittels dem die Datenpaketfolge IP2 übertragen wird. Diese Abrechnungsinformationen enthalten also in aufsummierter Form zusammengefasste Informationen (oben Umfangsinformationen genannt) über den Datentunnel, der die eine Datenpaketfolge IP2 und die anderen Datenpaketfolgen IP1 und IP3 überträgt. Der Netzübergangsknoten GGSN kann die verschiedenen Datenpaketfolgen IP1, IP2 und IP3 nicht unterscheiden. Der Netzübergangsknoten GGSN wird zu einem späteren Zeitpunkt (siehe unten) den ersten Abrechnungsdatensatz GGSN-CDR1 erzeugen, in diesen ersten Datensatz die Abrechnungsinformationen einschreiben und diesem ersten Abrechnungsdatensatz die erste eindeutige Kennung K1 zuordnen.
In ähnlicher Weise ermittelt auch die Vermittlungsstelle SGSN bei der Datenübertragung Abrechnungsinformationen, welche den Datentunnel IP betreffen, in zusammengefasster und aufsum mierter Form. Die Vermittlungsstelle SGSN kann zu einem späteren Zeitpunkt (siehe unten) einen Abrechnungsdatensatz SGSN-CDR1 erzeugen, welcher den Charakter eines ersten Abrechnungsdatensatzes aufweist. Auch dieser erste Abrechnungsdatensatz SGSN-CDR1 wird mit der ersten eindeutigen Kennung K1 versehen.
Sobald die Dienstnutzung IP2 und ggf. auch die weiteren Dienstnutzungen IP1 und IP3 der Dienstrechner DR1 und DR3 beendet sind (insbesondere wenn der Nutzer des Kommunikationsendgerätes KEG die Beendigung des von ihm genutzten Dienstes wünscht, diese Beendigung des Dienstes durch den Abbau des Datentunnels PDP realisiert werden soll und eine solche Aufforderung zum Abbau des Datentunnels PDP zur Vermittlungsstelle SGSN geleitet wird), dann sendet die Vermittlungsstelle SGSN eine Aufforderung zum Abbau des Datentunnels PDP an den Netzübergangsknoten GGSN (Nachricht 13: PDP Context disconnect request). Nun erzeugt die Vermittlungsstelle SGSN (wie bereits oben erläutert) den ersten Abrechnungsdatensatz SGSN-CDR1. Weiterhin erzeugt der Netzübergangsknoten GGSN (wie bereits oben erläutert) den Abrechnungsdatensatz GGSN-CDR1. Diese Abrechnungsdatensätze können aber auch zu einem späteren Zeitpunkt erzeugt werden, in diesem Fall werden bis dahin die relevanten Abrechnungsinformationen bei der Vermittlungsstelle SGSN bzw. bei dem Netzübergangsknoten GGSN gespeichert.
Daraufhin sendet der Netzübergangsknoten GGSN eine Aufforderungsnachricht 14 über das Dienstrechnerzugangsgateway SSG an das Authorisierungsnetzelement AAA. Mit dieser Aufforderungsnachricht wird die Information übertragen, dass das Authorisierungsnetzelement AAA keine weiteren Abrechnungsinformationen für den Datentunnel mehr erfassen soll. Diese Aufforde rungsnachricht enthält neben der eingangs erwähnten Kennungsinformation "Acct-Session-ID (PDP)" auch das Datenelement CL (Nachricht 14: RADIUS: Accounting Stop Request (Acct-Session-ID(PDP), class)).
Das Authorisierungsnetzelement AAA quittiert diese Aufforderungsnachricht 14 mit einer Quittungsnachricht 15 (Nachricht 15: RADIUS: Accounting Stop Response). Daraufhin – und das ist optional – erzeugt das Authorisierungsnetzelement AAA den dritten Abrechnungsdatensatz IP-PDP-CDR3, in welchen das Authorisierungsnetzelement AAA Abrechnungsinformationen einschreibt, welche den Datentunnel PDP betreffen und welche das Authorisierungsnetzelement AAA von dem Netzübergangsknoten GGSN erhalten hat. Das Authorisierungsnetzelement AAA ordnet diesem dritten Abrechnungsdatensatz IP-PDP-CDR3 die eindeutige Kennung K1 zu.
Aufgrund des Abbaus des Datentunnels PDP sendet das Dienstrechnerzugangsgateway SSG eine Nachricht 16 an das Abrechnungssystem CS, mit dem es dieses auffordert, die laufende Abrechnung der Dienstnutzung zu beenden. Diese Nachricht „Accounting Stop Request" enthält neben einer Bezeichnung der aktuellen Dienstnutzung und einer die Datenpaketfolge IP2 betreffenden „Acct-Session-ID (IP2)" auch das Datenelement CL. Das Abrechnungssystem CS quittiert den Erhalt der Nachricht 16 mit einer Quittungsnachricht 17 (Nachricht 17: RADIUS: Accounting Stop Response). Danach erzeugt das Abrechnungssystem (wie oben bereits beschrieben) den zweiten Abrechnungsdatensatz IP-Flow-CDR21. Das Abrechnungssystem kann diesen Abrechnungsdatensatz IP-Flow-CDR21 jedoch auch zu einem späteren Zeitpunkt erzeugen.
Das Authorisierungsnetzelement AAA erzeugt jetzt (wie oben bereits beschrieben) den Abrechnungsdatensatz IP-Flow-CDR22.
Das Authorisierungsnetzelement AAA kann diesen Abrechnungsdatensatz IP-Flow-CDR22 jedoch auch zu einem späteren Zeitpunkt erzeugen.
Beispielsweise können die Abrechnungsdatensätze folgende Informationen beinhalten:
SGSN-CDR1: PDP-Context: Übertragungszeit 200s, Datenvolumen 300 MB
GGSN-CDR1: PDP-Context: Übertragungszeit 200s, Datenvolumen 300 MB
IP-flow-CDR21: Datenpaketfolge IP2: Übertragungszeit 200s, Datenvolumen 65 MB
IP-flow-CDR22: Datenpaketfolge IP2: Übertragungszeit 200s, Datenvolumen 65 MB
IP-PDP-CDR3: PDP-Context: Übertragungszeit 200s, Datenvolumen 300 MB
In einem nächsten Schritt werden sämtliche erzeugten Abrechnungsdatensätze SGSN-CDR1, GGSN-CDR1, IP-Flow-CDR21, IP-Flow-CDR22, IP-PDP-CDR3 zu dem Erkennungsknoten MD übertragen bzw. von diesem abgerufen (Nachricht 18: CDR retrieval from network elements NE). Bei dem Erkennungsknoten MD liegen nun diese genannten (und ggf. noch weitere, nicht die Dienstnutzung IP2 betreffende) Abrechnungsdatensätze vor. Der Erkennungsknoten liest nun aus den Abrechnungsdatensätzen SGSN-CDR1, GGSN-CDR1 und IP-PDP-CDR3 jeweils die erste eindeutige Kennung K1 aus. Aus den Abrechnungsdatensätzen IP-Flow-CDR21 und IP-Flow-CDR22 liest der Erkennungsknoten jeweils das Datenelement CL aus und ermittelt aus dem Datenelement CL die in diesem Datenelement „eingepackten" ersten Kennungsinformationen (welche die erste eindeutige Kennung K1 beschreiben, Acct-Session-ID (PDP)). Anhand der ersten Kennungsinformationen und der ersten Kennung kann das Erkennungssystem MD fest stellen, dass die genannten fünf Abrechnungsdatensätze alle der Dienstnutzung IP2 zugehörig sind (d. h. neben eventuell noch anderen Informationen auch Abrechnungsinformationen enthalten, die die Datenübertragung mittels der Datenpaketfolge IP2 betreffen). Nun kann der Erkennungsknoten MD diese Abrechnungsinformationen zusammenfassen, redundante Informationen entfernen, Statistiken anfertigen oder anderweitig geeignet aufbereiten. Die aufbereiteten Abrechnungsinformationen werden dann in einer Nachricht 19 an das Rechnungszentrum BC übermittelt. In diesem Rechnungszentrum BC werden dann die tatsächlichen Belastungen des Kontos des z. B. Besitzer des Kommunikationsendgerätes KEG vorgenommen (Nachricht 19: Data retrieval from Mediation Device MD). Damit ist das erfindungsgemäße Verfahren beendet.
Im folgenden sollen – teilweise zusammenfassend – weitere das erfindungsgemäße Verfahren betreffende Merkmale oder Alternativen aufgezeigt werden:
Der Datentunnel PDP (PDP-Context) kann eine oder mehrere einzelne Datenpaketfolgen (IP-Flows) enthalten. Von der Vermittlungsstelle SGSN und dem Netzübergangsknoten GGSN (welche beide dem sog. GPRS-Access-Network angehören) können nur Messungen und Ermittlungen von Abrechnungsinformationen bezüglich des gesamten Datentunnels PDP vorgenommen werden.
Die Messungen und Bestimmungen von Abrechnungsinformationen bezüglich einzelner Datenpaketfolgen (z. B. der Datenpaketfolge IP2) finden im IP-Core-Network auf sogenanntem „IP-Flow-Level" statt. Die Differenzierung zwischen den einzelnen Datenpaketfolgen (IP-Flows: IP1, IP2 und IP3) wird von dem Dienstrechnerzugangsgateway SSG vorgenommen. Dieses Dienstrechnerzugangsgateway sendet seine Abrechnungsinformationen an den Authorisierungsserver AAA oder zusätzlich oder alternativ an das Abrechnungssystem CS (Charging Server). Bei diesem Abrechnungssystem CS kann es sich um ein „offline" arbeitendes Abrechnungssystem handeln (also um ein Abrechnungssystem, welches zeitversetzt mit der eigentlichen Dienstnutzung die Abrechnungsdatensätze erstellt); es kann sich aber auch um ein in Realzeit online arbeitendes Abrechnungssystem handeln oder um ein kombiniertes offline-online-Abrechnungssystem. Das Authorisierungsnetzelement AAA oder das Abrechnungssystem CS erzeugen die Abrechnungsdatensätze auf Dienstebene. Als derartige Abrechnungsdatensätze können auch Log-Dateien („log files") mit den entsprechenden Abrechnungsinformationen verwendet werden.
Abrechnungsdatensätze (IP-PDP-CDR3) oder "log files", die von der Authorisierungseinheit AAA erzeugt werden und dem Datentunnel PDP zugeordnet sind, können identifiziert werden durch das RADIUS-Attribut „Acct-Session-ID". Dieses besteht aus der GGSN-Adresse und der Zahlungs-ID (Charging ID), welche verbunden sind in einem UTF-8-codierten Hexadezimal-Datensatz.
Die Datenübertragung über das RADIUS Interface (insbesondere zwischen dem Dienstrechnerzugangsgateway SSG und dem Abrechnungssystem CS bzw. dem Authorisierungsnetzelement AAA) ist bezüglich der Benutzung des Attributs „Acct-Session-ID" standardkonform. Erfindungsgemäß identifiziert die hier übertragene „Acct-Session-ID (IP flow)" eine einzelne Datenpaketfolge (IP-Flow, z.B. IP2). Dies geschieht innerhalb der gesamten „User Session", welche durch ihre eigene „Act-Session-ID (PDP)" identifiziert wird, die letztgenannte ID ist Datentunnel-PDP-bezogen. Erfindungsgemäß werden für die datentunnelbezogene ID und die datenpaketfolgenbezogene ID unterschiedliche Ausprägungen verwendet.
Bei dem ersten Kontakt zwischen dem Netzübergangsknoten GGSN und dem Authorisierungsnetzelement AAA werden die Kennungsinformationen oder auch die erste eindeutige Kennung K1 zu dem Authorisierungsnetzelement AAA übertragen. Dies wird realisiert in einer Art und Weise, die nicht gegen einschlägige Standards verstößt.
Der Authorisierungsserver AAA erzeugt das standardkonforme Attribut „Class". Dieses Attribut gilt für die gesamte „Session", d. h. für die gesamte Lebensdauer des Datentunnels PDP.
Das Attribut „Class", welches das in den Radius-Spezifikationen beschriebene Verhalten aufweist, wird beim Netzübergangsknoten GGSN gespeichert und sämtlichen folgenden Abrechnungsnachrichten beigefügt.
Das Dienstrechnerzugangsgateway SSG erzeugt für jede einzelne Datenpaketfolge IP1, IP2 und IP3 eine unterschiedliche „Accounting-Session-ID (IP1)", „Accounting-Session-ID (IP2)" usw. Mit den Nachrichten 10 und 16 wird jeweils diese unterschiedliche Accounting-Session-ID und zusätzlich das Datenelement CL zu dem Abrechnungssystem übertragen. Ähnliches findet statt bei den Datenübertragungen von den Dienstrechnerzugangsgateway SSG zu dem Authorisierungsnetzelement AAA. Aufgrund dieser dienstindividuellen Accounting-Session-IDs (die auch mit in die Abrechnungsdatensätze eingeschrieben werden), kann von dem Erkennungsknoten MD die jeweilige Abrechnungsinformation des Abrechnungsdatensatzes genau einem IP-Flow und damit einem konkreten Dienst zugeordnet werden.
Bei dem erfindungsgemäßen Verfahren können folgende Alternativen und Änderungen vorgenommen werden:

a. Die Nachrichtenpaare 10/11 und 16/17 können vom Dienstrechnerzugangsgateway SSG an den AAA-Server gesendet werden; der Erkennungsknoten MD fragt dann keine Abrechnungsdatensätze von dem Abrechnungssystem ab.
b. Die Nachrichtenpaare 10/11 und 16/17 können an einen zusätzlichen AAA-Server gesendet werden bzw. von diesem stammen. Dieser zusätzliche AAA-Server übernimmt die Rolle des Abrechnungssystems CS.
c. Der Dienstrechnerzugangsgateway SSG kann in einer solchen Art und Weise konfiguriert sein, dass zu Beginn der Dienstnutzung vom Abrechnungssystems CS jede unterschiedene Datenpaketfolge (die zu dem entsprechenden Dienstrechner übertragen werden soll) autorisiert werden muss. Diese Konfigurationseinstellung kann vorzugsweise dann verwendet werden, wenn es sich beim Abrechnungssystems CS um ein in Realzeit online arbeitendes Abrechnungssystem handelt oder um ein kombiniertes offline-online-Abrechnungssystem. In diesem Fall wird dem Nachrichtenpaar 10/11 ein weiteres Nachrichtenpaar vorangestellt, das die Möglichkeit einer vorangehenden Autorisierung der entsprechenden Datenpaketfolge gewährleistet. Die Autorisierung wird vorzugsweise mittels RADIUS-Nachrichten "Access Request" und "Access Accept" (im Erfolgsfall) bzw. "Access Reject" (im Fall einer Ablehnung durch das Abrechnungssystems CS) realisiert.
d. Die Vermittlungsstelle SGSN oder der Netzübergangsknoten GGSN erzeugen einen ersten Abrechnungsdatensatz bzw. nur einer der beiden Abrechnungsdatensätze SGSN-CDR1 und GGSN-CDR1 wird zum Erkennungsknoten MD übertragen.
e. Die Abrechnungsdatensätze werden direkt zum Rechnungszentrum BC übertragen. Dieses Rechnungszentrum führt die Funktion des Erkennungsknotens MD aus.
f. Das Abrechnungssystem CS ruft die Abrechnungsdatensätze von der Vermittlungsstelle SGSN und/oder von dem Netzübergangsknoten GGSN ab.

Das erfindungsgemäße Verfahren weist insbesondere folgende Vorteile auf: Von verschiedenen Netzelementen des Kommunikationsnetzes unabhängig generierte Abrechnungsdatensätze (Charging Data Records, welche einander überlappende bzw. redundante Informationen enthalten können), die eine einzige Dienstnutzung betreffen, können als zu dieser Dienstnutzung zugehörig erkannt werden. Dies ist insbesondere dann von Vorteil, wenn sich bei verschiedenen Netzwerkelementen die Erzeugung von Abrechnungsdatensätzen nicht unterdrücken lässt, sondern vielmehr diese Abrechnungsdatensätze standardmäßig immer erzeugt werden. Das Verfahren kollidiert nicht mit den einschlägigen Standards. Daher ist die Implementierung einfach und verursacht nur ein Minimum an Kosten und Implementierungsaufwand. Insbesondere die Core-Network-Elemente (GGSN, SGSN) und das Authorisierungsnetzelement (AAA) führen keine Schritte aus, die nicht standardkonform sind.
Abschließend seien in zusammengefasster Form noch einmal die bei dem erfindungsgemäßen Verfahren übertragene Nachrichten dargestellt. Dabei gehören die Nachrichten 2 bis 5, 7, 8, 10, 11 und 14 bis 17 zu den Authorisierungsnachrichten (AAA & policy data flow). Die Nachrichten 1, 6, 9, 12 und 13 gehören zu den Trägernachrichten (bearer traffic). Die Nachrichten 10, 11, 16 und 17 sind Abrechnungsnachrichten (charging flow). Die Nachrichten 18 und 19 dienen zum Abrufen der Abrechnungsdatensätze (CDR retrieval).

1: PDP Context activation request
2: RADIUS: Access Request (Acct-Session-ID(PDP)) via the SSG
: to the AAA server
3: RADIUS: Access Accept (Service List, class (contains Acct-
: Session-ID(PDP)))
4: Service Profile Retrieval (Service Name (from Service
: List (IP1, IP2, IP3)), Destination IP Address, [optionally
: containing an alternative AAA-server respectively Charging
: Server))
5: RADIUS: Access Accept (forward of message #3 containing
: class attribute)
6: Open GPRS Tunnel
7: RADIUS: Accounting Start Request (Acct-Session-ID(PDP),
: class)
8: RADIUS: Accounting Start Response
9: Forward IP Request
10: RADIUS: Accounting Start Request (Service Name, Acct-Ses
: sion-ID(IP flow), class)
11: RADIUS: Accounting Start Response
12: Connection Set-up (IP-traffic)
13: PDP Context disconnect request
13a: Write SGSN-CDR1, GGSN-CDR1
14: RADIUS: Accounting Stop Request (Acct-Session-ID(PDP),
: class) via the SSG to the AAA server
15: RADIUS: Accounting Stop Response
15a: Write IP-PDP-CDR3
16: RADIUS: Accounting Stop Request (Service Name(IP2), Acct-
: Session-ID(IP flow), class)
17: RADIUS: Accounting Stop Response
17a: Write IP-flow-CDR21, IP-flow-CDR22
18: CDR retrieval from network elements NE
19: CDR retrieval from Mediation Device

Verwendete Abkürzungen:

AAA: Authentication, Authorisation and Accounting
IP-PDP-CDR: CDR oder log file, die von einem AAA-Server erzeugt werden und Informationen über einen PDP-Context enthalten
CDR: Charging Data Record
CS: Charging System
GGSN-CDR: GGSN generated CDR
GGSN: Gateway GPRS Support Node
GPRS: General Packet Radio Service
IP: Internet Protocol
IP-Flow-CDR: CDR, das Informationen über eine bestimmte Datenpaketfolge enthält
MD: Mediation Device
PDP: Packet Data Protocol, z.B. IP
SGSN-CDR: SGSN generated CDR
SGSN: Serving GPRS Support Node
SSG: Service Selection Gateway
UMTS: Universal Mobile Telecommunication System

Claims

Verfahren zum Erkennen von eine Dienstnutzung (IP2) betreffenden Abrechnungsdatensätzen, die von verschiedenen Netzelementen mindestens eines Telekommunikationsnetzes erzeugt werden, wobei eine der Dienstnutzung zugeordnete Datenpaketfolge (IP2) über das mindestens eine Telekommunikationsnetz unter Nutzung eines Dienstrechnerzugangsgateways (SSG) zwischen einem dienstnutzenden Kommunikationsendgerät (KEG) und einem dienstanbietenden Dienstrechner (DR2) übertragen wird, wobei bei dem Verfahren – von einem ersten Netzelement (GGSN) ein erster Abrechnungsdatensatz (GGSN-CDR1) erzeugt wird, der die Datenpaketfolge (IP2) betreffende Abrechnungsinformationen enthält, – von dem ersten Netzelement dem ersten Abrechnungsdatensatz eine erste eindeutige Kennung (K1) zugeordnet wird, dadurch gekennzeichnet, dass – diese erste eindeutige Kennung (K1) beschreibende erste Kennungsinformationen über das Dienstrechnerzugangsgateway (SSG) an ein Authorisierungsnetzelement (AAA) übertragen werden, – von dem Authorisierungsnetzelement ein Datenelement (CL) des Datenübertragungsprotokolls "RADIUS" erzeugt wird, welches diese Kennungsinformationen enthält und welches nach dessen Erzeugung unveränderlich ist, – dieses Datenelement (CL) einem zweiten Abrechnungsdatensatz (IP-flow-CDR21, IP-flow-CDR22) beigefügt wird, welcher aufgrund der Übermittlung der Datenpaketfolge (IP2) über das Dienstrechnerzugangsgateway (SSG) erzeugt wird, – der erste Abrechnungsdatensatz und der zweite Abrechnungsdatensatz zu einem Datensatzerkennungsknoten (MD) übertragen werden, – von dem Datensatzerkennungsknoten (MD) die ersten Kennungsinformationen aus dem Datenelement (CL) des zweiten Abrechnungsdatensatzes ausgelesen werden, und – anhand der ersten Kennungsinformationen des zweiten Abrechnungsdatensatzes und der ersten Kennung (K1) des ersten Abrechnungsdatensatzes erkannt wird, dass der erste Abrechnungsdatensatz und der zweite Abrechnungsdatensatz ein und derselben Dienstnutzung zugehörig sind.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass – das von dem Authorisierungsnetzelement (AAA) erzeugte Datenelement (CL) an das Dienstrechnerzugangsgateway (SSG) übertragen wird.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass – als erster Abrechnungsdatensatz (GGSN-CDR1) ein solcher erster Abrechnungsdatensatz erzeugt wird, der die Abrechnungsinformationen über die eine Datenpaketfolge (IP2) und Abrechnungsinformationen über weitere das erste Netzelement passierende und das Kommunikationsendgerät betreffende Datenpaketfolgen (IP1, IP3) in aufsummierter Form enthält.
Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass der erste Abrechnungsdatensatz (GGSN-CDR1) die Abrechnungsinformation als aufsummierte Übertragungszeitinformationen und/oder aufsummierte Datenvolumeninformationen enthält.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass – als zweiter Abrechnungsdatensatz (IP-flow-CDR21, IP-flow-CDR22) ein solcher zweiter Abrechnungsdatensatz erzeugt wird, der Abrechnungsinformationen über genau die eine zwischen dem Kommunikationsendgerät und dem Dienstrechner übertragene Datenpaketfolge (IP2) enthält.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass – der zweite Abrechnungsdatensatz (IP-flow-CDR21) erzeugt wird, indem aufgrund der Übermittlung der Datenpaketfolge (IP2) über das Dienstrechnerzugangsgateway (SSG) von dem Dienstrechnerzugangsgateway das Datenelement (CL) an ein Abrechnungssystem (CS) übermittelt wird, von welchem der zweite Abrechnungsdatensatz (IP-flow-CDR21) erzeugt und diesem zweiten Abrechnungsdatensatz das Datenelement (CL) beifügt wird.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass – von dem Dienstrechnerzugangsgateway (SSG) bei Beginn und/oder Ende der Übertragung der Datenpaketfolge (IP2) gemeinsam mit dem Datenelement (CL) die Datenpaketfolge betreffende Übertragungszeitinformationen und/oder Datenvolumeninformationen zu dem Abrechnungssystem (CS) übermittelt werden, und – anhand dieser Übertragungszeitinformationen und/oder Datenvolumeninformationen von dem Abrechnungssystem (CS) der zweite Abrechnungsdatensatz (IP-flow-CDR21) erzeugt wird.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass – der zweite Abrechnungsdatensatz (IP-flow-CDR22) erzeugt wird, indem aufgrund der Übermittlung der Datenpaketfolge (IP2) über das Dienstrechnerzugangsgateway (SSG) von dem Dienstrechnerzugangsgateway das Datenelement (CL) an das Authorisierungsnetzelement (AAA) übermittelt wird, von welchem der zweite Abrechnungsdatensatz (IP-flow-CDR22) erzeugt und diesem zweiten Abrechnungsdatensatz das Datenelement (CL) beifügt wird.
Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass – von dem Dienstrechnerzugangsgateway (SSG) bei Beginn und/oder Ende der Übertragung der Datenpaketfolge (IP2) gemeinsam mit dem Datenelement (CL) die Datenpaketfolge betreffende Übertragungszeitinformationen und/oder Datenvolumeninformationen zu dem Authorisierungsnetzelement (AAA) übermittelt werden, und – anhand dieser Übertragungszeitinformationen und/oder Datenvolumeninformationen von dem Authorisierungsnetzelement (AAA) der zweite Abrechnungsdatensatz (IP-flow-CDR22) erzeugt wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass – bei Aufbau und/oder Abbau eines Datentunnels (PDP) zur Übertragung der einen Datenpaketfolge (IP2) von dem ersten Netzelement (GGSN) gemeinsam mit der Kennung (K1) den Datentunnel (PDP) betreffende Übertragungszeitinformationen und/oder den Datentunnel betreffende Datenvolumeninformationen zu dem Authorisierungsnetzelement (AAA) übermittelt werden, und – anhand dieser Übertragungszeitinformationen und/oder Datenvolumeninformationen von dem Authorisierungsnetzelement ein dritter Abrechnungsdatensatz (IP-PDP-CDR3) erzeugt wird und diesem dritten Abrechnungsdatensatz die Kennung (K1) zugeordnet wird.
Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass – der dritte Abrechnungsdatensatz (IP-PDP-CDR3) zu dem Datensatzerkennungsknoten (MD) übertragen wird, – von dem Datensatzerkennungsknoten die Kennung (K1) aus dem dritten Abrechnungsdatensatz ausgelesen wird, und – anhand der Kennung (K1) erkannt wird, dass der dritte Abrechnungsdatensatz (IP-PDP-CDR3), der zweite Abrechnungsdatensatz (IP-flow-CDR21) und der erste Abrechnungsdatensatz (GGSN-CDR1) ein und derselben Dienstnutzung (IP2) zugehörig sind.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass – als erstes Netzelement ein "Serving GPRS Support Node" verwendet wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass – als erstes Netzelement ein "Gateway GPRS Support Node" verwendet wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass – als Authorisierungsnetzelement ein "Authentication, Authorisation and Accounting Server" verwendet wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass – die ersten Kennungsinformationen eine das erste Netzelement (GGSN) identifizierende Adresse und ein den Datentunnel identifizierendes Kennzeichen umfassen.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass – als Datenelement (CL), welches die Kennungsinformationen enthält, von dem Authorisierungsnetzelement (AAA) ein nach dem Datenübertragungsprotokolls "RADIUS" aufgebautes Datenelement "class" erzeugt wird.