-
Technisches Gebiet
-
Die
vorliegende Erfindung bezieht sich auf IP-Fluss-Gebührenerhebungstechniken,
spezieller ausgedrückt
auf ein Verfahren zum Behandeln eines Fluss-basierten Gebührenerhebungs-Trigger-Ereignisses
und -Neu-Autorisierungsereignisses.
-
Hintergrund der Erfindung
-
Mit
der immer größeren Verbreitung
von IP-Flussdiensten bzw. IP-Datenflussdiensten, hat es allgemein
die Aufmerksamkeit von Service Providern erweckt, wie IP-Datenflussdienste
akkurat und vernünftig
zu berechnen sind.
-
1 zeigt
ein Ablaufdiagramm einer Packet Data Protocol- bzw. Paketdatenprotokoll-(PDP-)Kontext-Aktivierung,
Datenübertragung und
PDP-Kontext-Deaktivierung. Wie in 1 gezeigt
wird, weisen bei dem General Packet Radio Service bzw. Allgemeinen
Paketfunkdienst (GPRS) der Vorgang einer PDP-Kontext-Aktivierung,
der Dateninteraktion mit einem externen Paketdatennetzwerk (PDN)
und das PDP-Kontext-Deaktivieren die folgenden Schritte auf:
-
Schritt 101:
Ein Mobiltelefon (MS) sendet eine Aktivierungs-PDP-Kontext-Anforderung
zu einem Dienst-GPRS-Unterstützungsknoten
(SGSN). Die Aktivierungs-PDP-Kontext-Anforderung trägt eine
Information, wie z. B. einen Network Layer Service Access Point
Identifier bzw. eine Netzwerkschicht-Dienst-Zugriffspunkt-Kennung
(NSAPI), einen PDP-Typ, einen Access Point Name bzw. Zugriffspunktnamen
(APN), einen erforderlichen Quality of Service bzw. Service-Qualitäts-(QoS-)Parameter, einen
Transaction Identifier bzw. eine Transaktionskennung (TI) und etc.,
wobei die NSAPI, welche eine Komponente des Tunnel Identifier bzw.
der Tunnelkennung (TID) zwischen dem SGSN und einem Gateway-GPRS-Support-Node
bzw. -Stützknoten (GGSN)
ist, zum Identifizieren eines PDP-Kontextes benutzt wird; der Typ
bzw. die Art des PDP bezieht sich auf den Typ des Peer-Peer-Protokolls
(PPP) oder den Typ des Internet-Protokolls
(IP) oder dergleichen; der APN kann über ein MS zu dem SGSN geliefert
werden, um einen geeigneten GGSN zu adressieren, und der GGSN kann
das externe Netzwerk bestimmen, auf welches das MS entsprechend dem
APN zuzugreifen wünscht,
während
das MS keinen APN zu dem SGSN liefert, wobei der SGSN einen fehlerhaften
APN entsprechend der Anmeldeinformation des MS auswählen wird;
der QoS-Parameter bezieht sich auf die Anforderung der Paketdatendienstqualität, welche
durch das MS angezeigt wird; und die TI wird an das MS zum Identifizieren
eines PDP-Kontextes geliefert.
-
Schritt 102:
Beim Empfangen der Aktivierungs-PDP-Kontext-Anforderung führt der
SGSN einen Sicherheitscheck und einen Verschlüsselungsprozess für das MS
aus, wobei dieser Schritt optional ist.
-
Schritt 103:
Der SGSN, welcher die Adressinformation des GGSN entsprechend dem
APN auflöst,
falls der SGSN die Adresse des GGSN entsprechend dem APN auflösen kann,
wird eine TEID für den
PDP-Kontext erstellen. Die TEID kann eine Kombination einer internationalen
mobilen Teilnehmeridentität
(IMSI) und einer NSAPI sein. Dann wird der SGSN an den GGSN eine
Create-PDP-Kontext Request bzw. eine Erstellungs-PDP-Kontext-Anforderung
schicken. Die Anforderung trägt
eine derartige Information, wie z. B. den PDP-Typ, die PDP-Adresse,
den APN, QoS-Parameter, die TEID und den Modus der Auswahl, wobei
die PDP-Adresse die IP-Adresse
das MS sein darf, welche optional ist und nicht notwendigerweise
durch die Erstellungs-PDP-Kontext-Anforderung
getragen wird. Wenn die PDP-Adresse nicht durch die Anforderung getragen
wird, sollte in dem nachfolgenden Prozess die IP-Adresse des MS
durch den GGSN oder durch den PDN zugewiesen sein, welcher schließlich eine Verbindung
mit dem MS erstellt. Der Modus der Auswahl bezieht sich auf den
Auswahlmodus des APN, d. h. der APN wird durch das MS oder durch
den SGSN ausgewählt.
Falls der SGSN die Adresse des GGSN nicht auflösen kann, wird der SSGN die
Aktivierungs-PDP-Kontext-Anforderung, welche durch das MS gesendet
wurde, zurückweisen.
-
Schritt 104:
Beim Empfangen der Erstellungs-PDP-Kontext-Anforderung bestimmt
der GGSN einen externen PDN entsprechend dem APN und ordnet eine
Gebührenerhebungs-ID
zu, wobei das Gebührenerheben
gestattet wird, und verhandelt über
den QoS-Parameter. Wenn der GGSN die Anforderungen der Service-Qualität, welche
durch den QoS-Parameter definiert ist, erfüllen kann, wird zu dem SGSN
eine Erstellungs-PDP-Kontext-Rückantwort
zurückgeschickt,
welche eine derartige Information wie eine TEID, eine PDP-Adresse,
ein Haupttrassenträgerprotokoll,
einen verhandelten QoS-Parameter und eine Gebührenerhebungs-ID trägt. Falls der
GGSN die Anforderungen der Service-Qualität, welche durch den QoS-Parameter
definiert ist, nicht erfüllen
kann, wird die Erstellungs-PDP-Kontext-Anforderung, welche durch
den SGSN gesandt wurde, zurückgewiesen,
und dann weist der SGSN die Aktivierungs-PDP-Kontext-Anforderung,
welche durch das MS gesendet wurde, zurück.
-
Schritt 105:
Beim Empfangen der Erstellunungs-PDP-Kontext-Rückantwort fügt der SGSN in den PDP-Kontext
eine NSAPI zum Identifizieren des PDP-Kontexts und der Adresse des
GGSN ein, und die Funkpriorität
entsprechend zu dem verhandelten QoS-Parameter wird ausgewählt und
dann zu dem MS eine Aktivierungs-PDP-Kontext-Annahme zurückgeschickt,
welche eine derartige Information, wie z. B. den PDP-Typ, die PDP-Adresse,
die TI, den verhandelten QoS-Parameter,
die Funkpriorität
und Konfigurationsoptionen des PDP trägt. In der Zwischenzeit wird
der SGSN den Gebührenerhebungsprozess
starten. Beim Empfangen der Aktivierungs-PDP-Kontext-Annahme weiß das MS,
dass die direkte Route zwischen dem MS und dem GGSN erstellt wurde
und die Übertragung
der Paketdaten ausgeführt
werden kann.
-
Schritt 106:
Das MS betreibt die Wechselwirkung zwischen den Paketdaten und dem
PDN über den
SGSN und den GGSN.
-
Schritt 107:
Nach dem Vollenden der Wechselwirkung der Paketdaten sendet der
MS zu dem SGSN eine Deaktivierungs-PDP-Kontext-Anforderung, welche
die TI trägt.
-
Schritt 108:
Beim Empfangen der Deaktivierungs-PDP-Kontext-Anforderung führt der
SGSN einen Sicherheitscheck und einen Verschlüsselungsprozess zu dem MS aus,
welcher optional ist.
-
Schritt 109 bis
Schritt 111: Der SGSN sendet an den GGSN eine Löschungs-PDP-Kontext-Anforderung, welche
die TEID trägt.
Beim Empfangen der Löschungs-PDP-Kontext-Anforderung beendet
der GGSN den Gebührenerhebungsvorgang
für das
MS, löscht
den PDP-Kontext
entsprechend der TEID und sendet dann an den SGSN eine Löschungs-PDP-Kontext-Rückantwort, welche die TEID
trägt.
Beim Empfangen der Löschungs-PDP-Kontext-Rückantwort beendet der SGSN
den Gebührenerhebungsvorgang
für das
MS, löscht
den PDP- Kontext
entsprechend der TEID und sendet dann an das MS eine Deaktivierungs-PDP-Kontext-Annahme, welche die
TI trägt. Beim
Empfangen der Deaktivierungs-PDP-Kontext-Annahme löscht das
MS den PDP-Kontext entsprechend der TI.
-
Es
kann aus dem Prozess, welcher in 1 gezeigt
wird, ersehen werden, dass in dem aktuellen GPRS-Gebührenerhebungssystem
der Startpunkt des Gebührenerhebens
auf einen Zeitpunkt gesetzt wird, wenn der PDP-Kontext aktiviert
ist, während
der Endpunkt derselben auf einen Zeitpunkt gesetzt wird, wenn der
PDP-Kontext gelöscht
ist, so dass demnach das Gebührenerheben
nur entsprechend dem Volumen des Datenflusses, welcher in einem PDP-Kontext übertragen
wird, oder entsprechend der Zeitdauer des Aktivierens eines PDP-Kontextes ausgeführt werden
kann. In einem aktuellen Netzwerk jedoch ist es nach der Datenwechselwirkung zwischen
dem MS und dem PDN möglich,
dass das MS verschiedene Dienste basierend auf einem aktivierten
PDP-Kontext ausführen
kann, d. h. falls der PDN in der Lage ist, verschiedene Dienste
zu liefern, wie z. B. E-Mail, WAP-basiertes Browsen und FTP-basierte
File-Übertragung
etc., wobei diese verschiedenen Dienste, welche durch diesen PDN
geliefert werden, in einem aktivierten PDP-Kontext getragen werden
können,
nachdem das MS einen Übertragungskanal
mit dem PDN erstellt hat. Jedoch kann der Dienst unterschiedliche
Gebührenerhebungsregelungen
bzw. Gebührenregelungen
für unterschiedliche
Dienste liefern, z. B. sollte der E-Mail-Dienst entsprechend der
Anzahl der Sendeereignisse und der getriggerten Empfangsereignisse
abgerechnet werden, der WAP-Browser-Dienst sollte entsprechend dem
Volumen des Datenflusses abgerechnet werden und der File-Übertragungsdienst
sollte auch entsprechend dem Volumen des Datenflusses abgerechnet
werden, während
die Gebührenerhebung
für den
WAP-Browser-Dienst nicht exakt die gleiche sein sollte wie die für den File-Übertragungsdienst.
Jedoch kann das aktuelle GPRS-Gebührenerhebungssystem nicht unterschiedlich
differenzierte Gebührenregelungen
für unterschiedliche
Dienste ausführen,
welche in einem PDP-Kontext getragen werden.
-
Auf
das Obige zielend, diskutiert das 3. Generations-Partnership-Project
3GPP (TS 23.125 V6.0.0, März
2004, S. 1–29),
wie man das IP-Fluss-basierte Gebührenerheben (FBC) implementieren
kann. In Bezug auf einen Paketdatendienst kann hier ein Paketfluss
ein IP-Fluss sein, wobei alle IP-Flüsse, welche gesendet und empfangen werden,
wenn das MS den Dienst benutzt, als Dienstdatenfluss bezeichnet
werden, d. h. der Dienstdatenfluss ist ein Satz aus einer Menge
von IP-Datenflüssen,
so dass demnach die IP-Fluss-basierte Gebührenerhebung wahrhaft den Betrag an
besetzten Ressourcen durch einen bestimmten Dienstdatenfluss reflektieren
kann. IP-Flussbasiertes Gebührenerheben
kann als das Filtern von IP-Flüssen
von verschiedenen Diensten in einem PDP Kontextträger mit
unterschiedlichen Filtern betrachtet werden und dann die IP-Flüsse, herausgepickt
durch unterschiedliche Filter, könnten
jeweils für
eine unterschiedliche Gebührenregelung
angewendet werden. Deshalb ist die Gebührenerhebungsgranularität des IP-Fluss-basierten Gebührenerhebens
weitaus kleiner als die Gebührenerhebungsgranularität einer
PDP-Kontext-basierten Gebührenerhebung.
Die Granularität kann
auf die Größe eines
Loches eines Siebes bezogen werden, die Gebührenerhebungsgranularität einer
PDP-Kontext-basierten Gebührenerhebungseinrichtung
bedeutet, dass ein PDP-Kontext als eine Lochgröße des Siebes benutzt wird,
während
die Gebührenerhebungsgranularität der IP-Fluss-basierten Gebührenerhebung
bedeutet, dass jeder IP-Dienstdatenfluss als eine Lochgröße des Siebes
benutzt wird, d. h. eine Vielzahl von Sieblöchern wird im Zusammenhang
mit einem PDP-Kontext benutzt. Wenn man demnach dies mit einer PDP-Kontext-basierten Gebührenerhebung
vergleicht, liefert eine IP-Fluss-basierte Gebührenerhebung dem Operator oder
Dienst-Provider flexiblere Vorgehensweisen der Gebührenerhebung.
-
Die
Systemarchitektur, funktionelle Spezifikationen und Nachrichten-Interaktionsprozesse
der FBC wurden in dem 3GPP beschrieben. 2A zeigt
die Architektur eines FBC-Systems, welches eine Online-Gebührenerhebung
unterstützt,
wobei der Service Control Point bzw. Dienststeuerpunkt (SCP) 201 einer
Customized Application for Mobile Network Enhanced Logic bzw. einer
kundenorientierten Anwendung für
mobile netzwerkverstärkte
Logik (CAMEL) und die Service Data Flow Based Credit Control Function
bzw. Dienstdatenfluss-basierte Kreditsteuerfunktion (CCF) 202 ein
Online-Gebührenerhebungssystem
(OCS) 206 darstellen. Das CCF 202 wirkt mit der
Service Data Flow Based Charging Rule Function bzw. der Dienstdatenfluss-basierten
Gebührenerhebungsregelfunktion
(CRF) 203 über
eine Schnittstelle Rx zusammen, die CRF 203 wirkt mit der
Application Function bzw. Anwendungsfunktion (AF) 204 über eine
Schnittstelle Rx zusammen, die CRF 203 wirkt mit der Traffic
Plane Function bzw. Verkehrsebenenfunktion (TPF) 205 über eine Schnittstelle
Gx zusammen und die CCF 202 wirkt mit der TPF 205 über eine
Schnittstelle Gy zusammen.
-
Die
Architektur eines FBC-Systems, welche eine Off-line-Gebührenerhebung
unterstützt,
wird in 2B gezeigt, wobei die CRF 203 mit
einer AF 204 über
die Schnittstelle Rx zusammenwirkt, die CRF 203 mit der
TPF 205 über
die Schnittstelle Tx zusammenwirkt und die TPF 205 über eine
Schnittstelle Gz mit der Charging Gateway Function bzw. Gebührenerhebungs-Gateway-Funktion (CGF) 207 und
der Charging Collection Function bzw. Gebührenerhebungssammelfunktion
(CCF) 208 jeweils zusammenwirkt.
-
Die
TPF 205 trägt
einen IP-Fluss. Wenn ein Träger
des IP-Flusses erstellt wird, wird die TPF 205 eine Anforderung
für eine
Gebührenregelung
an die CRF 203 über
die Schnittstelle Gx senden. Die Gebührenregelungs-Anforderung trägt die Information, welche
sich auf den Benutzer und das MS, die Trägercharakteristika ebenso wie
eine netzwerkbezogene Information bezieht, wobei die Information,
welche sich auf den Nutzer und das MS bezieht, die internationale
Nummer des Mobile Station Integrated Service Data Network bzw. Mobiltelefon-integrierten Dienstdatennetzwerkes
(MSISDN) oder die International Mobile Subscriber Identity bzw.
die internationale Mobilteilnehmeridentität (IMSI) etc. sein kann und die
auf das Netzwerk bezogene Information der Mobile Network Code bzw.
mobile Netzwerkcode (MNC) oder der Mobile Country Code bzw. mobile
Ländercode
(MCC) oder etc. sein kann. Zusätzlich
können während des Übertragungsvorgangs
des IP-Flusses Modifikationen an dem Träger durchgeführt werden, z.
B. eine Neuverhandlung des QoS-Parameters, so dass die Gebührenregelung
bei unterschiedlichen QoS-Parametern des gleichen Dienstes, welchen
der Benutzer benutzt, geändert
werden kann, z. B. die Höhe
der Gebührenerhebung
kann mit dem Abnehmen des QoS-Parameters niedriger werden. In diesem
Fall, wenn eine Modifikation an dem Träger durchgeführt wird,
kann die TPF 205 eine Gebührenregelungs-Anforderung an
die CRF 203 senden, um wieder eine neue Gebührenregelung
anzufordern; die CRF 203 wählt eine geeignete Gebührenregelung
basierend auf der oben eingegebenen Information, welche durch die
TPF 205 geliefert wird, aus und schickt dann die ausgewählte Gebührenregelung
an die TPF 205 zurück.
Die Gebührenregelung
weist Informationen, wie z. B. den Gebührenerhebungsmechanismus, den
Gebührenerhebungstyp,
den Gebührenerhebungsschlüssel, das
Filter des Dienstdatenflusses und die Priorität der Gebührenregelungen auf, wobei der
Gebührenerhebungsmechanismus der
Modus der Gebührenerhebung
ist, welcher eine Online-Gebührenerhebung
oder eine Offline-Gebührenerhebung
sein kann; der Gebührenerhebungstyp kann
zeitbasiertes Gebührenerheben
oder volumenbasiertes Gebührenerheben
oder Zeit-Volumen-basiertes Gebührenerheben
sein; der Gebührenerhebungsschlüssel ist
ein Parameter, welcher zu der Höhe
der Gebührenerhebung
gehört,
d. h. die CRF 203 kann der TPF 205 die Gebührenerhebungshöhe nicht
direkt liefern, stattdessen kann sie die TPF 205 mit nur
einem Parameter beliefern, welcher zu der Gebührenerhebungshöhe gehört. Das
Filter des Dienstdatenflusses wird zum Instruieren der TPF 205 benutzt,
welcher IP-Fluss zu filtern ist, und dann wird die TPF 205 die
gefilterten IP-Flüsse
entsprechend der Gebührenregelung
aufzeichnen. Das Filter der Dienstdaten, basierend auf dem IP-5-Tupel,
welcher eine derartige Information, wie z. B. die Quell/Ziel-IP-Adresse,
die Quell/Ziel-Anschlussnummer und die Protokoll-ID beinhaltet.
Beispielsweise kann die CRF 203 die TPF 205 instruieren,
einen IP-Fluss mit
der Quelladresse 10.0.0.1, die Zieladresse 10.0.0.2, die Quell/Ziel-Anschlussnummer 20 und
den Protokolltyp TCP zu filtern und den gefilterten IP-Fluss entsprechend
der Gebührenregelung abzurechnen.
-
Die
CRF 203 kann die TPF 205 mit Ereignis-Triggern
beliefern, um so die TPF 205 in die Lage zu versetzen,
von der CRF 203 neue Gebührenregelungen anzufordern,
wenn ein spezielles Ereignis auftritt, beispielsweise kann die CRF 203 die
TPF 205 dazu bringen, von der CRF 203 neue Gebührenregelungen
anzufordern, wenn eine Trägermodifikation
auftritt. Ereignis-Trigger können
als Ereignisse bezogen auf Gebührenregelungen
betrachtet werden.
-
Neben
dem Auswählen
einer geeigneten Gebührenregelung
basierend auf der Eingabeinformation, welche durch die TPF 205 geliefert
wird, kann auch die CRF 203 geeignete Gebührenregelungen
basierend auf der Eingabeinformation auswählen, welche durch die AF 204 oder
das OCS 206 geliefert wird, beispielsweise kann die AF 204 die
CRF 203 über
den Diensttyp informieren, den der Benutzer gerade benutzt, dann
wird die CRF 03 eine geeignete Gebührenregelung basierend auf
dem Diensttyp auswählen.
-
Das
OCS 206 besteht aus zwei funktionellen Entitäten, dem
SCP 201 und der Service Data Flow Based Credit Control
Function bzw. Dienstdatenfluss-basierten Kreditsteuerfunktion (CCF) 202,
wobei die CCF 202 die funktionelle Entität für die Kreditsteuerung
ist und nur in einem Online-Gebührenerhebungs-system
benutzt wird, welches durch Hinzufügen neuer Funktionen an das
existierende OCS 206 realisiert werden kann. Bei dem Vorgang
des Online-Gebührenerhebens
managt die CCF 202 die Kredite der Benutzer und steuert
sie, wenn der Benutzer den Dienst benutzt, die CCF 202 autorisiert die
Kredite in dem Kreditpool des Benutzers und sendet an die TPF 205 über die
Schnittstelle Gy die verfügbaren
Kredite an den Benutzer.
-
Zusätzlich kann
es für
das OCS 206 erforderlich sein, dass die TPF 205 die
Neu-Autorisierung des Kredits anfordert, wenn Neu-Autorisierungs-Trigger
auftreten. Danach wird das OCS 206 den Benutzer basierend
auf den entsprechenden Neu-Autorisierungs-Triggern, welche durch
die TPF 205 berichtet werden, neu autorisieren und kann
möglicherweise
die Kredite des Benutzers neu berechnen. Wenn beispielsweise die
Kredite des Benutzers, welche an die TPF durch das OCS 206 geliefert
werden, ausgelaufen sind, muss die TPF entsprechend dem Detektieren
des Auslaufens der Kreditautorisierungsgültigkeitszeit, welche mit den
Neu-Autorisierungstriggern übereinstimmt,
dem OCS 206 das Auslaufen der Kreditautorisierungsgültigkeitszeit
berichten, wenn dieses Ereignis auftritt; und dann berechnet das
OCS 206 die verfügbaren
Kredite für
den Benutzer entsprechend dem Stand des Benutzerkontos neu. Als ein
anderes Beispiel, wenn die flächenbasierte
Gebührenerhebungspolitik
bzw. -regelungsweise angewendet wird, bestimmt das OCS 206 die
Gebührenerhebungshöhe entsprechend
dem aktuellen Ort des Benutzers und berechnet die Kredite des Benutzers
basierend auf der Gebührenerhebungshöhe; wenn
der Benutzer sich zu einem anderen Ort bewegt, wenn sich der SGSN
verändert,
berichtet die TPF 205, entsprechend dem Detektieren des SGSN-Veränderns,
welcher zu den Neu-Autorisierungs-Triggern passt, dem OCS 206,
dass das SGSN-Veränderungsereignis
aufgetreten ist, und das OCS bestimmt die Gebührenerhebungshöhe basierend
auf dem aktualisierten gegenwärtigen
Ort des Benutzers neu und berechnet die Kredite des Benutzers neu.
Als noch ein weiteres Beispiel bestimmt das OCS die Gebührenerhebungshöhe basierend auf
dem aktuellen QoS-Parameter des Dienstes, welcher von dem Benutzer
benutzt wird, wenn der QoS-Parameter modifiziert ist, muss die TPF
entsprechend der Trägermodifikation,
welche mit den Neu-Autori-sierungs-Triggern übereinstimmt, dem OCS 206 das
Trägermodifikationsereignis,
welches aufgetreten ist, berichten, und das OCS 206 bestimmt
dann die Gebührenerhebungshöhe basierend auf
dem modifizierten QoS-Parameter und berechnet die Kredite des Benutzers
neu.
-
In
einem GPRS-Netzwerk bezieht sich die TPF 205 auf den GGSN,
die AF bezieht sich auf ein Dienst-Gateway oder einen Dienst-Server
in dem PDN und die CRF 203 bezieht sich auf eine neu hinzugefügte Logik-Entität. Die TPF 205 ist
der Ausführungspunkt
der Gebührenregelungen,
während
die CRF 203 der Steuerpunkt der Gebührenregelungen ist.
-
Bis
hierher hat der 3GPP den Vorgang des Durchführens einer Gebührenregelungsanforderung durch
das Auftreten eines Ereignis-Triggers während des Online-Gebührenerhebens
definiert, wenn der Träger
modifiziert ist, d. h. den Vorgang des TPF-Anforderns einer Gebührenregelung
von der CRF beim Auftreten eines Ereignis-Triggers, wie dies in 3 gezeigt
wird:
-
Schritt 301:
Ein Benutzergerät
(UE) sendet eine Modify Bearer Service Request bzw. eine Modifizierungsträger-Dienstanforderung
an eine TPF. In einem GPRS-Netzwerk entspricht dies dem, dass ein GGSN
eine Aktualisierungs-PDP-Kontext-Anforderung empfängt.
-
Schritt 302:
Beim Empfangen der Modify Bearer Service Request bzw. Modifizierungsträger-Dienstanforderung
vergleicht die TPF das Modifizierträgerereignis mit den vorher
gespeicherten Ereignis-Triggern, falls diese zwei übereinstimmen, wird
zum Schritt 303 weitergegangen; anderenfalls wird fortgefahren,
das Auftreten von Ereignis-Triggern zu überwachen.
-
Schritt 303:
Die TPF sendet an die CRF eine Request Charging Rules bzw. eine
Anforderung für Gebührenregelungen,
welche die relevante Eingabeinformation für die Auswahl einer Gebührenregelung trägt.
-
Schritt 304 bis
Schritt 305: Beim Empfangen der Anforderung der Gebührenregelungen
wählt die CRF
eine geeignete Gebührenregelung,
welche auf der verfügbaren
Information basiert, für
die CRF aus (z. B. Information kann von der AF verfügbar sein
und die Information, welche von der TPF empfangen wurde), und schickt
dann an die TPF eine Provision Charging Rules bzw. ein Vorsehen
von Gebührenregelungen,
welches die ausgewählte
Gebührenregelung
und die Aktionen derselben trägt.
-
Schritt 306:
Beim Empfangen der Provision Charging Rules führt die TPF die diesbezüglichen Gebührenregelungsaktionen
an der Gebührenregelung,
welche durch die CRF ausgewählt
ist, durch, d. h. es kann notwendig sein, dass die Gebührenregelungen
installiert und/oder entfernt und/oder modifiziert werden.
-
Schritt 307:
Die TPF schickt an das UE eine Modify Bearer Service Accept bzw.
eine Modifizierungsträger-Dienstannahme
zurück
und fährt
mit dem nachfolgenden Vorgang der Trägermodifikation fort.
-
Während des
Online-Gebührenerhebens werden
die Trägermodifikationen
einen Neu-Autorisierungsvorgang
tiggern, d. h. die TPF wird das OCS fragen, den Kredit des Benutzers
neu zu autorisieren, wobei die spezifische Implementierung desselben
in 4 gezeigt wird:
-
Schritt 401:
ein UE sendet eine Modifizierungsträger-Dienstanforderung an die
TPF. In einem GPRS-Netzwerk entspricht dies dem, dass der GGSN eine
Aktualisierungs-PDP-Kontext-Anforderung
empfängt.
-
Schritt 402:
Beim Empfangen der Modifizierungsträger-Dienstanforderung vergleicht
die TPF das Modifizierungsträgerereignis
mit den vorher gespeicherten Neu-Autorisierungs-Triggern, wenn diese
beiden übereinstimmen,
fahre mit dem Schritt 403 fort; anderenfalls fahre mit
dem Überwachen
des Auftretens von Neu-Autorisierungs-Triggern fort.
-
Schritt 403:
Die TPF sendet an das OCS eine Kreditsteueranforderung, welche die
Ausgeglichenheit der Kredite des Benutzers und Information trägt, welche
sich auf die Gebührenregelung
bezieht, und fordert das OCS auf, die Kredite des Benutzers neu zu
berechnen. Die Information, welche sich auf die Gebührenregelung
bezieht, welche durch die TPF für das
OCS geliefert wird, kann von der CRF kommen.
-
Schritt 404:
Beim Empfangen der Kreditsteueranforderung berechnet das OCS die
Kredite des Benutzers neu und schickt dann an die TPF eine Kreditsteuerantwort.
Wenn das OCS durch das Berechnen die Kredite des Benutzers empfängt, wird
die Kreditsteuerantwort die Kredite des Benutzers tragen, welche
durch das OCS neu berechnet wurden; wenn das OCS nicht in der Lage
ist, die Kredite des Benutzers zu berechnen, kann die Kreditsteuerantwort
den Wert der Fehlerursache tragen.
-
Schritt 405:
Beim Empfangen der Kreditsteuerantwort schickt die TPF an das UE
eine Modifizierungsträger-Dienstannahme.
Falls die Kreditsteuerantwort die Kredite des Benutzers trägt, wird
die TPF die Modifizierungsträger-Dienstanforderung,
welche durch das UE gesandt wurde, annehmen und mit dem nachfolgenden
Prozess der Trägermodifikation fortfahren;
falls die Kreditsteuerantwort keine Kredite des Benutzers trägt, wird
die TPF die Modifizierungsträger-Dienstaufforderung,
welche durch das UE gesandt wurde, zurückweisen.
-
Gegenwärtig werden
Beschreibungen an dem Gebührenerhebungsmodus
durchgeführt,
in welchem die CRF das Trägerereignis
steuert, welches in der TPF mit Hilfe des Lieferns des Ereignis-Triggerns
an die TPF in den Spezifikationen auftrat, d. h. die TPF berichtet
an die CRF nach dem Detektieren des Auftretens eines Ereignis-Triggers,
die CRF lernt, dass der Träger
durch den Ereignis-Trigger, welcher durch die TPF berichtet wurde,
modifiziert wurde, und wählt
dann eine geeignete Gebührenregelung
aus und sendet die Gebührenregelung an
die TPF. Die Ereignis-Trigger, welche in den Spezifikationen definiert
sind, können
ein PLMN-Veränderungsereignis,
ein QoS-Veränderungsereignis,
ein Änderungsereignis
des RAT-(Radio Access Technique bzw. Radiozugriffstechnik-)Typs
und ein Änderungsereignis
des TFT (Transmission Flow Template bzw. der (Übertragungsflussmaske) beinhalten.
-
Zusätzlich gibt
es Beschreibungen darüber, wie
das OCS den Kredit steuert, welcher in der TPF mit Hilfe des Lieferns
der Neu-Autorisierungs-Trigger an die TPF in den Spezifikationen
verbraucht wurde, d. h. die TPF berichtet an das OCS nach dem Detektieren
des Auftretens von neu autorisierten Trigger, wobei das OCS von
dem verbrauchten Kredit des Benutzers und der Modifikation des Trägers entsprechend
dem neu autorisierten Trigger, welcher durch die TPF berichtet wird,
erfährt
und die Kredite des Benutzers neu kalkuliert und die Kredite an
die TPF sendet. Die Trigger des Neu-Autorisierens, welche in den
Spezifikationen definiert sind, können das Ereignis des Auslaufens
der Kreditautorisierungsgültigkeit, das
Ereignis des Auslaufens des Leerlaufs, das Ereignis des Veränderns der
Gebührenregelung
sowie GPRS-Ereignisse, wie z. B. das Ereignis der SGSN-Veränderung,
das Ereignis der QoS-Änderung
und das Ereignis des Veränderns
des RAT Typs beinhalten.
-
Aus
den obigen Beschreibungen kann ersehen werden, dass sowohl Ereignis-Trigger
als auch Neu-Autorisierungs-Trigger Trägerereignisse beinhalten, wie
z. B. eine Veränderung
des SGSN, eine Veränderung
des QoS-Parameters und eine Änderung
des RAT-Typs. Demnach wird, wenn ein bestimmter Trägerereignis-Trigger
auftritt, die TPF dieses Trägerereignis
sowohl auf die Ereignis-Trigger als auch auf die Neu-Autorisierungs-Trigger
anpassen, entsprechend ist es notwendig, dieses Trägerereignis
jeweils an die CRF und das OCS zu berichten.
-
Im
Falle, dass die TPF als Erstes einen Neu-Autorisierungs-Trigger
an das OCS berichtet und dann einen Ereignis-Trigger an die CRF
berichtet, da es für
die CRF möglich
ist, eine neue Gebührenregelung
entsprechend dem empfangenen Ereignis-Trigger auszuwählen und
die neu ausgewählte Gebührenregelung
an die TPF zu senden, wird die neu ausgewählte Gebührenregelung, welche an die TPF
durch die CRF ausgegeben ist, in ähnlicher Weise mit dem Gebührenregelungsereignis
in den Neu-Autorisierungs-Triggern übereinstimmen, welche einen
Neu-Autorisierungsprozess
neu triggern, wobei der erste Neu-Autorisierungsprozess redundant
gemacht wird und die Schnittstellenressourcen zwischen der TPF und
dem OCS in einem FBC-System
verbraucht werden.
-
Zusammenfassung der Erfindung
-
In
Anbetracht des Obigen liefert die vorliegende Erfindung ein Verfahren
zum Behandeln von Ereignis-Triggern und zum Neu-Autorisieren von Triggern
in Fluss-basierter Gebührenerhebung,
um so den Neu-Autorisierungsprozess in Fluss-basierter Gebührenerhebung
zu verbessern.
-
Um
die obige Aufgabe zu lösen,
liefert die vorliegende Erfindung ein Verfahren zum Handhaben von
Ereignis-Triggern und dem Neu-Autorisieren von Triggern in Fluss-basierter
Gebührenerhebung,
wobei das Verfahren die folgenden Schritte aufweist:
- (A) Bestimmen der TPF, ob das Trägerereignis für einen
Ereignis-Trigger passt, falls es passt, Fortfahren mit dem Schritt
B, und anderenfalls Fortfahren zum Schritt C;
- (B) Durchführen
der TPF eines Vorgangs der Anforderung einer Gebührenregelung;
- (C) Bestimmen der TPF, ob das Trägerereignis zu einem Trigger
des Neu-Autorisierens passt, falls dieser passt, Durchführen der
TPF eines Vorgangs des Neu-Autorisierens, und anderenfalls Beenden
des aktuellen Vorgangs.
-
Der
Schritt B weist auf: Anfordern der TPF einer CRF für eine Gebührenregelung
und Rücksenden
der CRF einer ausgewählten
Gebührenregelung an
die TPF.
-
Der
Schritt B weist ferner auf: Liefern der TPF des Trägerereignisses
an die CRF, welches aktuell aufgetreten ist,
wobei der Schritt
B ferner aufweist: Bestimmen der TPF, ob die Gebührenregelung, welche durch
die CRF geliefert ist, verändert
ist, wenn sie dies ist, Durchführen
der TPF eines Neu-Autorisierungsvorgangs,
und anderenfalls Fortfahren zum Schritt C.
-
In
dem Schritt B, falls die TPF bestimmt, dass sich die Gebührenregelung,
welche durch die CRF geliefert wurde, geändert hat, bevor die TPF einen
Neu-Autorisierungsvorgang durchführt,
ferner aufweisend: Bestimmen der TPF, ob ein Neu-Autorisieren aufgrund
der geänderten
Gebührenregelung notwendig
ist, falls dies der Fall ist, Durchführen der TPF eines Neu-Autorisierungsvorgangs,
und anderenfalls Fortfahren mit dem Schritt C.
-
In
dem Schritt B, falls die TPF bestimmt, dass eine Neu-Autorisierung
aufgrund der geänderten
Gebührenregelung
notwendig ist, bevor die TPF einen Neu-Autorisierungsvorgang durchführt, ferner aufweisend:
Bestimmen der TPF, ob das Trägerereignis,
welches aktuell aufgetreten ist, zu einem Neu-Autorisierungs-Trigger
passt, falls es passt, Durchführen
der TPF eines Neu-Autorisierungsvorgangs
und Liefern des Trägerereignisses,
welches aktuell auftrat, an das OCS, und anderenfalls, dass die
TPF nur einen Neu-Autorisierungsvorgang durchführt.
-
Das
Durchführen
eines Neu-Autorisierungsvorgangs weist ferner auf: Liefern der TPF
der geänderten
Gebührenregelung
an das OCS.
-
Das
Durchführen
eines Neu-Autorisierungsvorgangs weist ferner auf: Liefern der TPF
des Trägerereignisses,
welches aktuell auftrat, an das OCS.
-
Das
Durchführen
eines Neu-Autorisierungsvorgangs weist auf: Anfordern der TPF der
Neu-Autorisierung
des Kredites in dem OCS und ferner das Zurücksenden des OCS des autorisierten
Kredites an die TPF.
-
Die
Ereignis-Trigger werden an die TPF durch die CRF geliefert.
-
Die
Neu-Autorisierungs-Trigger werden an die TPF durch das OCS oder über die
CRF durch das OCS geliefert.
-
In Übereinstimmung
mit dem Verfahren, welches durch die vorliegende Erfindung veröffentlicht wird,
wenn ein Trägerereignis
auftritt, schätzt
die TPF zuerst ab, ob das aufgetretene Trägerereignis zu einem Ereignis-Trigger
passt, falls es passt, berichtet sie den aufgetretenen Ereignis-Trigger an die CRF; dann
schätzt
sie ab, ob das aufgetretene Trägerereignis
zu einem Neu-Autorisierungs-Trigger
passt, falls es passt, berichtet sie den Neu-Autorisierungs-Trigger
an das OCS und fährt
mit dem nachfolgenden Neu-Autorisierungsprozess fort. Auf diese Weise
wird nur eine Interaktion zum Neu-Autorisieren zwischen der TPF
und dem OCS benötigt,
was den Neu-Autorisierungsvorgang optimiert, wenn es eine Überlappung
zwischen den Ereignis-Triggern
und den Neu-Autorisierungs-Triggern gibt, und es verbessert den
Neu-Autorisierungsvorgang
beim Fluss-basierten Gebührenerheben.
-
Kurze Beschreibung der Zeichnungen
-
1 zeigt
ein Ablaufdiagramm einer PDP-Kontext-Aktivierung, einer Dateninteraktion
und den PDP-Kontext-Deaktivierungsvorgang;
-
2A zeigt
die Architektur eines FBC-Systems, welches das Online-Gebührenerheben
unterstützt;
-
2B zeigt
die Architektur eines FBC-Systems, welches das Offline-Gebührenerheben
unterstützt;
-
3 zeigt
das Ablaufdiagramm für
das Triggern der TPF, welche entsprechend dem Stand der Technik
eine Anforderung an die CRF für
eine Gebührenregelung
durch einen Ereignistrigger sendet;
-
4 zeigt
das Ablaufdiagramm des Triggerns der TPF, welche entsprechend dem
Stand der Technik eine Anforderung an das OCS für das Neu-Autorisieren durch
einen Neu-Autorisierungs-Trigger
sendet;
-
5 zeigt
das Ablaufdiagramm für
das Behandeln von Ereignis-Triggern und Neu-Autorisierungs-Triggern entsprechend
der vorliegenden Erfindung;
-
6 ist
ein schematisches Diagramm, welches die Nachricht-Interaktion in
dem Vorgang des Behandelns von Ereignis-Triggern und Neu-Autorisierungs-Triggern
entsprechend der vorliegenden Erfindung darstellt.
-
Detaillierte Beschreibung
der Erfindung
-
Um
die Aufgabe, die Lösung
und die Verdienste der vorliegenden Erfindung klarer zu machen,
werden hier nachfolgend bevorzugte Ausführungsformen der vorliegenden
Erfindung detaillierter mit Bezug auf die beigefügten Zeichnungen beschrieben.
-
In Übereinstimmung
mit der vorliegenden Erfindung, wenn ein Trägerereignis auftritt, bestimmt die
TPF zuerst, ob das aufgetretene Trägerereignis zu einem Ereignis-Trigger
passt, falls es passt, werden Gebührenregelungen von der CRF
gefordert; dann entscheidet die TPF, ob das aufgetretene Trägerereignis
zu einem Neu-Autorisierungsträger passt,
falls es passt, führt
die TPF einen Neu-Autorisierungsprozess durch. Auf diese Weise ist
nur eine Interaktion für
das Neu-Autorisieren zwischen der TPF und dem OCS notwendig, was
den Neu-Autorisierungsvorgang
optimiert, wenn es eine Überlappung
zwischen Ereignis-Triggern und Neu-Autorisierungs-Triggern gibt.
-
5 zeigt
das Ablaufdiagramm in Übereinstimmung
mit der vorliegenden Erfindung für
das Behandeln von Ereignis-Triggern und Neu-Autorisierungs-Triggern.
Wie in 5 gezeigt wird, weist der Vorgang des Behandelns
von Ereignis-Triggern und Neu-Autorisierungs-Triggern die folgenden
Schritte auf:
-
Schritte 501 bis 502:
Die TPF detektiert das Auftreten eines Trägerereignisses und bestimmt,
ob das Trägerereignis
zu einem Ereignis-Trigger passt, falls es passt, fahre mit Schritt 503 fort;
anderenfalls fahre mit Schritt 507 fort.
-
Schritt 503:
Die TPF fordert die Gebührenregelungen
von der CRF an, d. h. die TPF liefert der CRF die Eingabeinformation
für das
Auswählen
einer Gebührenregelung
und beliefert ferner die CRF mit dem Trägerereignis, welches aktuell
aufgetreten ist, um so die CRF von dem Ereignisträger, welcher
aktuell den Anforderungsvorgang der Gebührenregelung getriggert hat,
zu informieren und um die CRF aufzufordern, eine Gebührenregelung
zu liefern; beim Empfangen der Anforderung für die Gebührenregelung wählt die
CRF eine Gebührenregelung
entsprechend der Eingabeinformation und dem gelieferten Trägerereignis
aus und liefert der TPF die ausgewählte Gebührenregelung und die Aktionen
hierfür. Nach
dem Empfangen der gelieferten Gebührenregelung führt die
TPF die diesbezüglichen
Gebührenregelungsaktionen
an der Gebührenregelung,
welche durch die CRF ausgewählt
ist, durch.
-
Schritt 504:
Die TPF bestimmt, ob sich die Gebührenregelung, welche durch
die CRF geliefert wird, verändert,
wenn sie dies tut, fahre mit Schritt 505 fort; anderenfalls
fahre mit Schritt 507 fort.
-
Schritt 505:
Die TPF bestimmt, ob eine Neu-Autorisierung aufgrund der veränderten
Gebührenregelung
benötigt
wird, falls dies der Fall ist, fahre mit Schritt 506 fort;
anderenfalls fahre mit Schritt 507 fort.
-
Schritt 506:
Die TPF bestimmt, ob das Trägerereignis,
welches aktuell aufgetreten ist, zu einem Neu-Autorisierungs-Trigger
passt, falls es passt, fahre mit Schritt 508 fort; anderenfalls
fahre mit Schritt 509 fort.
-
Schritt 507:
Die TPF bestimmt, ob das Trägerereignis,
welches aktuell aufgetreten ist, zu einem Neu-Autorisierungs-Trigger
passt, falls es passt, fahre mit Schritt 508 fort; anderenfalls
beende den aktuellen Vorgang.
-
Schritt 508:
Die TPF führt
einen Neu-Autorisierungsprozess durch, d. h. die TPF liefert dem
OCS die Information über
den Saldo der Kredite des Benutzers und die diesbezügliche Gebührenregelung, fordert
das OCS auf, die Kredite des Benutzers neu zu berechnen, und liefert
dem OCS ferner das Trägerereignis,
welches aktuell aufgetreten ist, um das OCS von dem Neu-Autorisierungs-Trigger
zu informieren, welcher den Neu-Autorisierungsvorgang triggert;
und dann liefert das OCS der TPF die neu berechneten Kredite des
Benutzers und beendet dann den aktuellen Vorgang.
-
Schritt 509:
Die TPF führt
einen Neu-Autorisierungsvorgang durch, d. h. die TPF liefert dem OCS
die Information über
den Saldo der Kredite des Benutzers und die diesbezügliche Gebührenregelung
und fordert von dem OCS, die Kredite des Benutzers neu zu berechnen,
und dann liefert das OCS der TPF die neu berechneten Kredite des
Benutzers.
-
Der
Schritt 506 kann zu jeder beliebigen Zeit zwischen Schritt 501 bis
Schritt 505 durchgeführt werden,
solange die TPF bestimmt, dass das aktuell aufgetretene Trägerereignis
zu einem Neu-Autorisierungs-Trigger
passt, wird die TPF, wenn sie einen Neu-Autorisierungsvorgang in
dem nachfolgenden Schritt 508 durchführt, ferner dem OCS das aktuell aufgetretene
Ereignis liefern, um das OCS von dem detektierten Neu-Autorisierungs-Trigger
zu informieren.
-
6 ist
ein schematisches Diagramm, welches die Nachrichten-Interaktion
in dem Vorgang des Behandelns von Trigger-Ereignissen und Neu-Autorisierungs-Triggern
in Übereinstimmung
mit der vorliegenden Erfindung darstellt. Wie in 6 gezeigt wird,
weist die Nachrichten-Interaktion
in dem Vorgang des Behandelns von Ereignis-Triggern und Neu-Autorisierungs-Triggern die folgenden
Schritte auf:
-
Schritt 601 ist
der gleich wie Schritt 301.
-
Schritt 602:
Beim Empfangen des Modify Bearer Service Request bzw. der Modifizierungsträger-Dienstanforderung
vergleicht die TPF das Trägermodifikationsereignis,
welches aktuell aufgetreten ist, mit den im Voraus gespeicherten
Ereignis-Triggern, falls diese passen, fahre mit Schritt 603 fort;
anderenfalls gehe direkt zu Schritt 608.
-
Wenn
ein Träger
aufgestellt wird, ist der spezifische Vorgang des Implementierens
wie folgt: Während
des Online-Gebührenerhebens,
wenn ein Träger
aufgestellt wird, sendet die TPF an die CRF eine Gebührenregelungsanforderung,
welche die Eingabeinformation über
die Gebührenregelung trägt, wie
z. B. die Information des UE, die Trägercharakteristika, die Information
des Netzwerks etc; die CRF wählt
eine geeignete Gebührenregelung
entsprechend der empfangenen Eingabeinformation aus, und außerdem bestimmt
sie, basierend auf der Eingabeinformation, welche durch die TPF
geliefert wird, die Ereignis-Trigger, welche durch die TPF überwacht
werden müssen,
und sendet dann die Gebührenregelung
und die Ereignis-Trigger an die TPF.
-
Zusätzlich kann,
wenn ein Träger
modifiziert ist, die CRF auch der TPF die Ereignis-Trigger liefern, welche
durch die TPF zu überwachen
sind, d. h. wenn ein Ereignis-Trigger auftritt, wird die TPF der CRF
den aufgetretenen Ereignis-Trigger berichten. Beim Empfangen des
Ereignis-Triggers,
welcher durch die TPF berichtet wird, kann die CRF fortfahren, neue
Ereignis-Trigger auszugeben. Wenn die CRF die Eingabeinformation
empfängt,
welche durch externe Entitäten
geliefert werden, wie z. B. die AF und das OCS, kann die CRF der
TPF ebenso die Ereignis-Trigger
liefern, welche durch die TPF zu überwachen sind, d. h. die CRF
kann unaufgefordert Ereignis-Trigger an die TPF liefern.
-
Beim
Empfangen der Gebührenregelung und
der Ereignis-Trigger, welche durch die CRF geliefert werden, überwacht
die TPF das Auftreten von Ereignis-Triggern, filtert die geeigneten
IP-Flüsse entsprechend
dem Filter der Gebührenregelung
und belastet dann die gefilterten IP-Flüsse,
wobei sie die geeignete Gebührenregelung
benutzt.
-
Das
OCS kann der TPF die Neu-Autorisierungs-Trigger direkt liefern,
welche zu überwachen von
dem TPF erfordert wird. Beispielsweise sendet die TPF in dem Autorisierungsvorgang
an die CRF eine Kreditanforderung; beim Empfangen der Kreditanforderung
berechnet das OCS die Anforderung des Benutzers und schickt an die
TPF eine Kreditantwort zurück,
welche ferner die Neu-Autorisierungs-Trigger zusätzlich zu den Krediten des
Benutzers tragen kann, und die TPF wird aufgefordert, die Neu-Autorisierungs-Trigger
zu überwachen,
d. h. wenn der Neu-Autorisierungs-Trigger auftritt, wird die TPF
den aktuell aufgetretenen Neu-Autorisierungs-Trigger an das OCS
berichten; das OCS kann auch die Neu-Autorisierungs-Trigger an die
TPF über die
CRF liefern.
-
Zusätzlich wird,
wenn ein Neu-Autorisierungs-Trigger auftritt, die TPF dem OCS den
aktuell aufgetretenen Neu-Autorisierungs-Trigger berichten; nach
Empfangen des Neu-Autorisierungs-Triggers, welcher
von der TPF berichtet wird, kann das OCS wieder die Neu-Autorisierungs-Trigger an die TPF
liefern.
-
Schritt 603:
Die TPF sendet an die CRF eine Gebührenregelungsanforderung, welche
die Eingabeinformation trägt,
welche für
die CRF geliefert wird, um die Gebührenregelung zu bestimmen,
und welche ferner das diesbezügliche
Trägerereignis,
welches aktuell aufgetreten ist, tragen kann, um die CRF über den
Ereignis-Trigger zu informieren, welcher den aktuellen Gebührenregelungs-Anforderungsvorgang
triggert.
-
Schritte 604 bis 606 sind
die gleichen wie die Schritte 304 bis 306.
-
Schritt 607:
Die TPF bestimmt, ob sich die Gebührenregelung, welche durch
die CRF geliefert wird, verändert
hat, falls sich die Regelung verändert hat,
bestimmt sie außerdem,
ob eine Neu-Autorisierung
aufgrund der veränderten
Gebührenregelung notwendig
ist, falls dies der Fall ist, fahre mit Schritt 608 fort;
falls die Gebührenregelung
nicht verändert wurde
oder das Neu-Autorisieren
aufgrund der veränderten
Gebührenregelung
nicht notwendig ist, fahre mit Schritt 608 fort.
-
Schritt 608:
Die TPF vergleicht das Trägermodifikationsereignis,
welches aktuell aufgetreten ist, mit den vorher gespeicherten Neu-Autorisierungs-Triggern,
falls diese passen, fahre mit Schritt 609 fort; anderenfalls
fährt die
TPF fort, zu bestimmen, ob es eine Notwendigkeit für das Durchführen eines
Neu-Autorisierungsvorgangs gibt, welcher im Schritt 607 bestimmt
ist, falls es eine Notwendigkeit gibt, fahre mit Schritt 609 fort,
falls es keine Notwendigkeit gibt, gehe direkt zu Schritt 611.
-
Schritt 609:
Die TPF sendet an das OCS eine Kreditanforderung, welche die Information
des Saldos der Kredite des Benutzers und die relevante Gebührenregelung
trägt,
wobei sie das OCS auffordert, die Kredite des Benutzers neu zu berechnen.
Wenn im Schritt 607 entschieden wird, dass es die Notwendigkeit
für das
Durchführen
eines Neu-Autorisierungsvorgangs gibt, kann die Kreditanforderung,
welche durch die TPF an das OCS gesendet wurde, ferner die Information über die
modifizierte Gebührenregelung
tragen. Zusätzlich
kann, falls im Schritt 608 entschieden wurde, dass es eine
Notwendigkeit für das
Durchführen
eines Neu-Autorisierungsvorganges gibt, die Kreditanforderung, welche
durch die TPF an das OCS gesendet wurde, ferner die modifizierte
Trägerinformation über das
Trägermodifikationsereignis
liefern.
-
Schritt 610:
Beim Empfangen der Kreditanforderung berechnet das OCS die Kredite
des Benutzers neu und schickt dann an die TPF eine Kreditantwort
zurück,
falls das OCS durch die Berechnung die Kredite des Benutzers erhält, die
wird Kreditantwort die Kredite des Benutzers, welche durch das OCS neu
berechnet wurden, tragen; falls das OCS nicht in der Lage ist, die
Kredite des Benutzers zu berechnen, wird die Kreditantwort den Fehlerursachenwert tragen.
-
Schritt 611:
Die TPF schickt an das UE eine Modifizierungsträger-Dienstantwort und bestimmt entsprechend
dem Ergebnis des obigen Vorgehens, ob sie die Modifizierungsträger-Dienstanforderung akzeptiert,
wenn bestimmt wird, dass sie die Anforderung akzeptiert, fahre mit
dem nachfolgenden Trägermodifikationsvorgang
fort; anderenfalls weise die Trägermodifikationsanforderung
zurück.
Beispielsweise wird, wenn die Kreditantwort die Kredite des Benutzers
trägt,
die TPF die Modifizierungsträger-Dienstanforderung,
welche von dem Nutzer gesendet wird, akzeptieren und mit dem nachfolgenden Trägermodifikationsprozess
fortfahren; falls die Kreditantwort keine Kredite des Benutzers
trägt,
wird die TPF die Modifizierungsträger-Dienstanforderung, welche durch den
Benutzer gesendet wurde, zurückweisen.
-
In
dem obigen Vorgang, im Schritt 607, wenn die TPF bestimmt,
dass es eine Veränderung
in der Gebührenregelung
gibt, und das Ereignis der Gebührenregelungsänderung
das Durchführen
eines Neu-Autorisierungsvorgangs erfordert, gehe direkt zu Schritt 609,
ohne den Schritt 608 auszuführen.
-
Zusammenfassend
ist die vorausgegangene Beschreibung nur eine bevorzugte Ausführungsform der
gegenwärtigen
Erfindung und ist nicht erstellt, um den Umfang derselben zu begrenzen.