DE602004010936T2

DE602004010936T2 - Gebührenberechnungsmechanismen für IP-Multimediadienste

Info

Publication number: DE602004010936T2
Application number: DE602004010936T
Authority: DE
Inventors: Mauro Bellora; Chiara Dotti; Santiago Munoz; Stephen Terrill; Patrik Wiss
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2004-06-03
Filing date: 2004-06-03
Publication date: 2009-01-02
Anticipated expiration: 2024-06-04
Also published as: PL1751966T3; CN1961567A; DE602004010936D1; ES2297427T3; JP2008502035A; CN1961567B; EP1751966B1; ATE382238T1; JP4648388B2; US8150369B2; EP1751966A1; RU2369981C2; US20080311883A1; WO2005120039A1; RU2006147312A

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft Gebührenberechnungsmechanismen für IP-Multimediadienste, die insbesondere, wenn auch nicht notwendigerweise, auf einen Drücken-zum-Sprechen bzw. Push-to-talk über zellulare Dienste anwendbar sind.
Hintergrund der Erfindung
IP-Multimediadienste stellen eine dynamische Kombination aus Sprache, Video, Mitteilungsübermittlung, Daten, etc. innerhalb derselben Session zur Verfügung. Durch ein Anwachsen der Anzahlen von Grundanwendungen und der Medien, für die es möglich ist, sich zu kombinieren, wird die Anzahl von Diensten, die den Endanwendern angeboten werden, exponentiell anwachsen und wird die Kommunikationserfahrung zwischen Personen angereichert werden. Dies wird zu einer neuen Generation personalisierter, reicherer Multimedia-Kommunikationsdienste führen.
Ein IP-Multimedia-Untersystem (IMS) ist die Technologie, die durch das Partnerschaftsprojekt der dritten Generation (3GPP) definiert ist, um IP-Multimediadienste über mobile 3G-Kommunikationsnetzwerke zur Verfügung zu stellen. IMS stellt Schlüsselmerkmale zum Anreichern der Kommunikationserfahrung von Person zu Person für Endanwender durch die Integration und die Interaktion von Diensten zur Verfügung. IMS lässt neue reiche Kommunikationen von Person zu Person (Client-zu-Client) sowie von Person zu einem Inhalt (Client-zu-Server) über ein auf IP basierendes Netzwerk zu. Das IMS verwendet das Session-Initiierungsprotokoll (SIP) und das Dienstlieferungsprotokoll (SDP) zum Aufbauen und Steuern von Anrufen oder Sessions zwischen Anwenderendgeräten (oder Anwenderendgeräten und Web-Servern). 1 stellt schematisch dar, wie das IMS in die mobile Netzwerkarchitektur passt.
Existierende Netzwerkbetreiber für zellulares Telefon haben in letzter Zeit ein fürchterliches Wachstum bezüglich der Anzahlen von Teilnehmern erfahren, die auswählen, so genannte "Prepaid"- bzw. "im Voraus bezahlte" Teilnahmen zu verwenden; dies bedeutet, wo Teilnehmer einen Betrag an (Bar-)Geld (das Guthaben) bei ihren Betreibern hinterlegen, welcher durch die darauf folgende Nutzung von Diensten durch die Teilnehmer verbraucht wird. Es wird erwartet, dass die Option einer im Voraus bezahlten Teilnahme sich als gleich populär wie die Anwender von IPMM-Diensten erweisen wird. Tatsächlich ist es wahrscheinlich, dass das Bereitstellen von im Voraus bezahlten Diensten ein Muss für eine weit verbreitete Annahme von IPMM-Diensten ist.
Wenn Online/Echtzeit-Gebührenberechnungsmechanismen verwendet werden (wie für im Voraus bezahlte Anwender), würde die allgemeine Regel für das IPMM-Bedienungselement (SE), das einen Zugang zu dem angefragten Dienst zur Verfügung stellt, darin bestehen, vor einem Gewähren eines Zugangs für einen mobilen Knoten zu dem angeforderten Dienst eine Kreditautorisierung anzufordern. Dies würde jedoch unvermeidbar die Session-Aufbauzeit für im Voraus bezahlte Teilnehmer erhöhen, da das IPMM-SE eine Kreditautorisierungstransaktion mit einem Gebührenberechnungs-Steuerknoten durchführen muss, der auch im Voraus bezahltes System bzw. Prepaid-System (PPS) oder Online-Gebührenberechnungssystem bzw. Online Charging System (OCS) genannt wird.
Für einige auf IPMM/IMS basierende Dienste ist die Session-Aufbauzeit kritisch. Dies gilt beispielsweise für ein so genanntes Push-to-talk über zellulare (PoC)-Dienste, wie beispielsweise ein sofortiges persönliches Gespräch und ein sofortiges ad hoc-Gruppengespräch, wo die Entstehungspartei die PoC-Taste auf seinem/ihrem Endgerät drückt, um einen oder mehrere Benutzer zu einer Session vom Walkie-Talkie-Typ einzuladen, und erwartet, sofort in Kontakt mit der eingeladenen Partei/den eingeladenen Parteien zu sein (was gegensätzlich zu den traditionellen Telefondiensten ist, die auf einem Anrufen, einem Klingeln, einer Antwort basieren). Die Einführung des Mechanismus einer Bezahlung im Voraus, wie er gegenwärtig vorgeschlagen ist, resultiert wahrscheinlich in einer Verschlechterung der PoC-Session-Aufbauzeit zu einem nicht akzeptierbaren Ausmaß oder kann zu einer suboptimalen Benutzererfahrung aufgrund der zusätzlichen Verzögerung führen, die durch die Kreditautorisierungsphase erzeugt wird.
3PGG TR 23.979 V0.6.0 (2004-05) offenbart ein Verfahren zum Aufbauen einer PoC-Session. In 3GPP TS 32.272 V0.0.2 (2004-03) ist eine Gebührenberechnung für PoC-Sessions spezifiziert.
Zusammenfassung der Erfindung
Es ist eine Aufgabe der Erfindung, die Effekte von Mechanismen für eine im Voraus bezahlte Bezahlung auf aktuelle und wahrgenommene Teilnehmerdienstebenen zu vermeiden.
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Reservieren eines Kredits für einen mobilen Teilnehmer in Bezug auf einen IP-Multimediadienst zur Verfügung gestellt, wobei das Verfahren Folgendes aufweist:
nach einer Anfangsregistrierung des Teilnehmers zu dem IP-Multimediadienst, aber vor einem Aufrufen eines IP-Multimediadienstes,
Anwenden der Prozedur für eine Einrichtung einer frühen Session zum Reservieren eines Kreditbetrags bei einem Gebührenberechnungs-Steuerknoten und zum Benachrichtigen eines IP-Multimedia-Bedienungselements über die Kreditreservierung,
woraufhin bei einem Aufrufen des IP-Multimediadienstes das IP-Multimedia-Bedienungselement sofort mit der Sessionverbindung fortfahren kann.
Es wird erkannt werden, dass die Prozedur für eine Bildung einer frühen Session einen Austausch von geeigneten Meldungen zwischen dem IP-Multimedia-Bedienungselement und dem Gebührenberechnungs-Steuerknoten aufweisen wird. Die Meldungen können die Anforderungen des DIAMETER-Protokolls erfüllen.
Die Prozedur für eine Bildung einer frühen Session wird auch typischerweise für Dienstverhandlungszwecke (z. B. einen Austausch einer Medienadresse und von Codec-Typen) zwischen dem Teilnehmerendgerät (UE) und dem IMS-Server verwendet werden.
Die Prozedur für eine Bildung einer frühen Session kann automatisch nach einer Registrierung des Teilnehmers zu dem IP-Multimediadienst ausgelöst werden oder kann beispielsweise dadurch ausgelöst werden, dass der Teilnehmer/Endbenutzer bzw. Endanwender einen bestimmten IP-Multimediadienst an seinem Endgerät aktiviert.
Die Erfindung ist insbesondere, wenn auch nicht notwendigerweise, auf Push-to-talk bzw. Drücken-zum-Sprechen über zellulare (PoC-)IP-Multimediadienste anwendbar.
Das Verfahren kann bei einem des IP-Multimedia-Bedienungselements und des Gebührenberechnungs-Steuerknotens ein Schätzen eines Kreditbetrags, der für den IP-Multimediadienst geeignet ist, aufweisen. Vorzugsweise wird diese Schätzung bei dem Gebührenberechnungs-Steuerknoten ausgeführt.
In dem Fall eines Teilnehmers, der im Voraus bezahlt hat, bzw. eines Prepaid-Teilnehmers wird der Gebührenberechnungs-Steuerknoten ein Prepaid-System-(PPS-)Server sein, der im Heimnetzwerk eines Teilnehmers angeordnet ist.
Vorzugsweise weist das Verfahren bei einem Aufrufen des IP-Multimediadienstes ein Durchführen einer Kreditautorisierungsprozedur zwischen dem IP-Multimedia-Dienstelement und dem Gebührenberechnungs-Steuerknoten basierend auf dem aktuellen Dienst auf, der angefragt/aufgerufen worden ist, einen überarbeiteten Kreditbetrag zu bilden. Der geschätzte Kreditbetrag wird durch den überarbeiteten Kreditbetrag ersetzt.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Betätigen eines IP-Multimedia-Bedienungselements zur Verfügung gestellt, das angeordnet und eingerichtet ist, um einen Zugang zu einem IP-Multimediadienst durch mobile Teilnehmer zu erleichtern, wobei das Verfahren Folgendes aufweist:
nach einer Anfangsregistrierung eines Teilnehmers zu dem IP-Multimediadienst, aber vor einer Initiierung der IP-Multimediasession, Initiieren einer Prozedur eines Bildens einer frühen Session mit einem Gebührenberechnungs-Steuerknoten, um einen Kreditbetrag bei dem Gebührenberechnungs-Steuerknoten zu reservieren.
Gemäß einem dritten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Betätigen eines Gebührenberechnungs- Steuerknoten zur Verfügung gestellt, der angeordnet und eingerichtet ist, einen Teilnehmerzugang zu IP-Multimediadiensten zu steuern, wobei das Verfahren Folgendes aufweist:
Partizipieren bzw. Teilnehmen an einer Prozedur für eine Bildung einer frühen Session nach einer Anfangsregistrierung eines Teilnehmers zu dem IP-Multimediadienst, aber vor einem Aufruf des IP-Multimediadienstes, wobei der Gebührenberechnungs-Steuerknoten einen geeigneten Kreditbetrag schätzt, um für eine zukünftige Session reserviert zu werden.
Kurze Beschreibung der Zeichnungen
1 stellt schematisch eine mobile Netzwerkarchitektur dar, die ein IP-Multimedia-Untersystem enthält;
2 stellt eine vereinfachte logische Online-Ladearchitektur für IPMM-Dienste dar;
3 zeigt die Architektur von PoC der Version 2;
4 zeigt eine Signalgabe, die zu der Prozedur für eine Bildung einer frühen Session gehört, für ein sofortiges persönliches PoC-Sprechen; und
5 und 6 zeigen eine Signalgabe, die zu der Sessionverbindungsprozedur gehört, nach einer Bildung einer frühen Session, wenn der Dienst tatsächlich aufgerufen wird.
Detaillierte Beschreibung bestimmter Ausführungsbeispiele der Erfindung
In einer IP-Multimedia-Untersystem-(IMS-)Session kann es eine Anzahl von Benutzern bzw. Anwendern geben, die Teilnehmer von mehreren unterschiedlichen IMS-Betreibern sind. In irgendeiner allgemein anwendbaren Gebührenberechnungsprozedur sollte jeder der IMS-Betreiber bei seinen eigenen Teilnehmern gemäß seiner eigenen Abrechnungspolitik unabhängig abrechnen können. Das soll heißen, dass unterschiedliche Gebührenberechnungs- bzw. Abrechnungsmodelle in unterschiedlichen Netzwerken für dieselbe IMS-Session angewendet werden können. Darüber hinaus können unterschiedliche Abrechnungsmodelle auf unterschiedliche Gruppen von Teilnehmern für den/dasselbe IPMM-Dienst/Merkmal innerhalb eines Netzwerks eines gegebenen Betreibers angewendet werden können.
Gemäß 3GPP R5 TS 32.225 und TS 32.200 und IETF DCC (Internetdraft "Diameter Credit-Control Application") werden zwei Szenarien für eine IMS-Online-Abrechnung unterschieden:

1) "Einmaliges Ereignis mit direkter Rechnungslegung"-Szenario. "Sofortige Ereignisabrechnung"-Modell in 3GPP. "Kreditautorisierung mit direkter Rechnungslegung"-Modell in IETF FCC.
2) "Auf einer Session basierte Kreditkontrolle"-Szenario. "Ereignisabrechnung mit Einheitsreservierung"-Modell in 3GPP. "Kreditautorisierung mit Geldreservierung"-Modell in IETF DCC.

In beiden Modellen fragen die IPMM-Bedienungselemente (IPMM SE), d. h. ein Kreditkontroll-Client, nach einer Kreditautorisierung von dem Online-Abrechnungssystem (OCS), Prepaidsystem (PPS), d. h. dem Kreditkontroll-Server vor einem Zulassen, dass irgendein Dienst zu dem Endbenutzer geliefert wird. Das Szenario einer auf einer Session basierenden Kreditkontrolle wird als geeigneter für die meisten IPMM-Dienste angesehen, und es ist das Szenario, das hier betrachtet wird.
Eine auf einer Session basierende Kreditkontrolle ist ein Prozess, bei welchem das PPS eine Anforderung von einem IPMM-SE bewertet, einen geeigneten Geldbetrag von dem Konto eines Benutzers reserviert und dem IPMM-SE den entsprechenden Betrag von Kreditressourcen mitteilt. Natürlich kann "Kreditressource" keinen aktuellen monetären Kredit implizieren: Kreditressourcen können in der Form von Einheiten (z. B. Datenvolumen oder Zeit) gewährt werden, um gemessen zu werden. Auf einen Empfang einer erfolgreichen Kreditautorisierungsantwort innerhalb eines bestimmten Ausmaßes an Kreditressource lässt das IPMM-SE eine Dienstlieferung zu dem Endbenutzer zu und beginnt eine Überwachung der Nutzung der gewährten Ressourcen. Wenn die dem Endbenutzer gewährten Kreditressourcen verbraucht worden sind oder der Dienst erfolgreich geliefert oder beendet worden ist, berichtet das IPMM-SE zu dem PPS den verwendeten Betrag zurück und leitet bzw. zieht das PPS den verwendeten Betrag von dem Konto des Benutzers ab (das PPS kann eine Schätzung durchführen und eine neue Kreditreservierung durchführen, wenn die Dienstlieferung andauert). Dieser Prozess enthält eine erste Abfrage, mögliche Zwischenabfragen und eine Endabfrage. Für sowohl das IMPP-SE als auch das PPS ist es erforderlich, dass sie eine Kreditkontroll-Sesssionzustandsinformation unterhalten.
Das obere Diagramm der 2 stellt eine allgemeine Online-Abrechnungsarchitektur für IPMM dar, während das untere Diagramm eine vereinfachte Architektur für PoC darstellt. Das Online-Abrechnungssystem (OCS)/Prepaidsystem (PPS) stellt die Abrechnungssteuerfunktion für einen Echtzeit-Abrechnungsmechanismus zur Verfügung. Das Prepaidsystem enthält den Kontenausgleichsmanager und die Benutzerkonten, die Schätzmaschine und die Tarifinformation. Die Schätzmaschine stellt Schätzwerte für Sessions/Dienste oder Ereignisse zur Verfügung, für die es bei einer Quelle keinen Preis gibt, d. h. für welche Bedienungselemente keinen Preis haben. Für eine Online-Abrechnung sind die IPMM-SE, die eine zu dem PPS eingegebene Abrechnung zur Verfügung stellen können, die Bedienungsanruf-Sessionsteuerfunktion (S-CSCF = Serving-Call Session Control Function), die Multimediaressourcenfunktionskontrolle (MRFC = Multimedia Resource Function Control) und der Anwendungsserver (AS = Application Server). Für Push-to-talk über ein Zellularsystem (PoC) ist das SE, das eine zu dem PPS eingegebene Abrechnung zur Verfügung stellt, der PoC-Server (der eine MRF- und eine AS-Funktionalität umfasst). Die Schnittstelle zwischen dem IMPP-SEs und dem PPS basiert auf dem Diameter-Basisprotokoll (DBP) und der Diameter-Kreditkontrollanwendung (DCC), wie sie durch 3GPP in den Versionen 5 und 6 definiert sind.
3 zeigt die PoC-Architektur der Version 2, wo die PoC-Funktionseinheiten mit durchgezogenen Linien gezeichnet sind. Die folgenden Schnittstellen sind in 3 gezeigt:

lt:: Bodenkontrolle und Medien
ltn:: Bodenkontrolle und Medien
ls:: PoC-Client-zu-Proxies-Sessionsignalgabe
lf:: Proxy-zu-PoC-Server-Sessionsignalgabe
ln:: Proxy-zu-Proxy-Sessionsignalgabe
lm:: Gruppenmanagementserver-zu-PoC-Client
lk:: Gruppenmanagementserver-zu-PoC-Server
lo:: OTAP-Server-zu-PoC-Client.

Die PoC-Architektur hat zwei PoC-Serverfunktionen, nämlich eine Steuerungs-PoC-Serverfunktion/Logikeinheit und eine Teilnahme-PoC-Serverfunktion/Logikeinheit. In jeder PoC-Gesprächssession gibt es nur einen Steuerungs-PoC-Server, während es einen oder mehrere Teilnahme-PoC-Server geben kann. Der Steuerungs-PoC-Server handhabt die zentralisierten Aufgaben, die nicht durch mehr als einen PoC-Server in der PoC-Gesprächssession gehandhabt werden sollten. Ein PoC-Server benimmt sich entweder als Steuerungs-PoC-Server oder als Teilnahme-PoC-Server, wie es auf einer Basis pro PoC-Gesprächssession ausgewählt wird.
Eine PoC-Server-Realisierung (d. h. eine physikalische Einheit/ein Knoten) kann sich als sowohl ein Steuerungs-PoC-Server als auch ein Teilnahme-PoC-Server zur gleichen Zeit und für dieselbe PoC-Gesprächssession verhalten. In dem Fall eines momentanen bzw. sofortigen persönlichen Gesprächs und eines sofortigen ad hoc-Gruppengesprächs ist der PoC-Server des einladenden Benutzers der Steuerungs-PoC-Server. In einem Fall eines Chat-Gruppengesprächs und eines sofortigen bzw. momentanen Gruppengesprächs ist der Steuerungs-PoC-Server der PoC-Server, der der Besitzer/Host der Gruppenidentität (der globalen Gruppenidentität) ist. Weitere Details dieser PoC-Dienste sind in dem nachfolgenden Anhang angegeben.
Wie es oben aufgezeigt worden ist, resultiert der herkömmliche Ansatz für eine Kreditreservierung für PoC-Sessions wahrscheinlich in signifikanten Sessionaufbauverzögerungen. Ein alternatives Verfahren zum Reservieren eines Kredits für PoC-verzögerungsempfindliche Dienste/Merkmale (d. h. ein sofortiges persönliches Gespräch und ein sofortiges ad hoc-Gruppengespräch) wird hier vorgeschlagen, welches alle Charakteristiken für ein Zahlen im Voraus beibehält (d. h. eine Betreiber-Kreditsteuerung, eine Endbenutzer-Echtzeit-Ausgabensteuerung). Dieses Verfahren verwendet die so genannte Prozedur für eine Bildung einer "frühen" Session, um einen Kredit für PoC-Merkmale mit einer kritischen Sessionaufbauzeit zu reservieren, bevor der Endbenutzer eine Gesprächssession initiiert, d. h. bevor das tatsächliche PoC-Merkmal aufgerufen wird. Die Prozedur zur Bildung einer frühen Session wird für Dienstverhandlungszwecke (z. B. eine Kommunikation von IP-Adresse/Anschlussnummer für RTP/RTCP und Codectypen) zwischen dem UE und seinem/ihrem Heim-PoC-Server verwendet. Die frühe Session kann sofort nach einer IMS-Registrierung oder zu irgendeinem späteren Zeitpunkt gebildet werden. Die Prozedur zur Bildung einer frühen Session ist in der PoC-Architektur der Version 2.0 definiert.
Bei einer Bildung einer frühen Session führt der PoC-Server eine Kreditreservierung in Richtung zu dem PPS (durch Senden einer Diameter-Kontierungsanfrage (ACR) mit Kontierungsaufzeichnungstyp = START) durch, bevor mit der Verarbeitung der Anfrage zur Bildung einer frühen Session fortgefahren wird. Das PPS schätzt versuchsweise den Dienst (bei dieser Stufe ist es unbekannt, welches PoC-Merkmal durch den Benutzer zu einer späteren Zeit aufgerufen werden wird), und dann, wenn das Benutzer-Guthaben ausreichend ist, reserviert das PPS einen geeigneten Geldbetrag von dem Benutzerkonto und bringt die entsprechende Menge an Krediteinheiten zu dem PoC-Server (in einer Diameter-ACA-Nachricht mit Kontierungsaufzeichnungstyp = START) zurück. Auf eine erfolgreiche Kreditreservierung hin setzt der PoC-Server eine Verarbeitung der Anfrage zur Bildung einer frühen Session fort. Dieses Kreditautorisierungsphase ist nicht besonders zeitempfindliche, da das PoC-Merkmal noch nicht aufgerufen worden ist.
In dem Fall, dass die Kreditreservierung nicht erfolgreich ist (z. B. das Benutzerguthaben erschöpft ist) initiiert das PPS die Prozedur für eine sofortige Dienstbeendigung durch Zurückbringen einer Fehleranzeige zu dem PoC-Server (in einer Diameter-ACA-Nachricht bzw. -Meldung, mit:
Ergebniscode = DIAMETER_END_USER_SERVICE_DENIED).
Der PoC-Server bringt eine SIP-Fehleranzeige zu dem Bedienungs-IMS-Kern zurück. Eine Fehleranzeige wird zu dem UE und dem Endbenutzer zurückgebracht.
Wie es bereits angegeben ist, ist dann, wenn ein Kredit bei einer Bildung einer frühen Session reserviert wird, der PoC-Server sich noch nicht diesbezüglich bewusst, welches PoC-Merkmal zu einer späteren Zeit aufgerufen werden wird, oder tatsächlich, ob das UE, das die Prozedur zur Bildung einer frühen Session durchführt, durch den Ursprung (Sessionbesitzer) oder einen abschließenden (teilnehmenden) Endbenutzer verwendet werden wird. Somit kann der PoC-Server bei einer Bildung einer frühen Session nur eine begrenzte Eingabe zum Schätzen zu dem System für eine Bezahlung im Voraus liefern. Bei einer Sessionverbindung (d. h. der tatsächlichen PoC-Merkmalsaufruf/Aufbaustufe) verarbeitet der PoC-Server die Dienstanfrage sofort durch Beruhen auf dem zuvor reservierten Kredit. Der PoC-Server kann nun eine präzise Eingabe zum Schätzen zu dem PPS liefern (in einer Diameter-ACR-Meldung mit Kontierungsaufzeichnungstyp = INTERIM). Diese Kreditautorisierungsphase ist wieder nicht besonders zeitempfindlich, weil ein geschätzter Kreditbetrag bereits reserviert worden ist, was das Risiko für den Dienstlieferer reduziert. Der Dienstaufruf kann sofort verarbeitet werden, während parallel eine zweite Kreditautorisierung ausgeführt wird, um die Schätzung zu verfeinern.
4 stellt die Signalgabe dar, die zu der Prozedur für eine Bildung einer frühen Session gehört, wenn sie für eine fortentwickelte Kreditreservierung mit dem Merkmal eines sofortigen persönlichen Gesprächs verwendet wird. Dieses Szenario sorgt für eine Prozedur für eine Bildung einer frühen Session bei beiden Seiten. (NB. der Signalgabefluss zeigt nicht den Entstehungs- und den Beendigungs-IMS-Kern). Die verschiedenen Signalgabeschritte sind wie folgt:
Bildung einer frühen Session des Netzwerks A

1a. UE-A beginnt eine Bildung einer frühen Session (sofort nach einer anfänglichen IMS-Registrierung oder zu einem späteren Zeitpunkt, z. B. dann, wenn der Benutzer den Dienst für ein sofortiges Gespräch von dem UE aktiviert), und zwar durch Senden von SIP INVITE in Richtung zu dem PoC-Server A über den IMS-Kern A (d. h. UE sendet SIP INVITE zu IMS-Kern A). Der IMS-Kern A bringt SIP 100 "Trying bzw. Versuchend" zu UE A zurück. Der IMS-Kern A detektiert einen Entstehungsauslöser und sendet als Ergebnis SIP INVITE zu dem PoC-Server A. SIP INVITE enthält Folgendes: Anfrage-URI-Benutzerteil eingestellt auf vorkonfigurierte Kette "Ad-hocGroupRequest" (die Kette ist in dem UE konfiguriert) Akzeptieren des Kontakts einschließlich des Merkmals-Tags "+g.poc.talkburt=TRUE" Zu = URI-Benutzerteil eingestellt auf vorkonfigurierte Kette "Ad-hocGroupRequest" Von = öffentliche Anwenderidentität des einladenden Benutzers Nachrichtenkörper mit Inhaltstyp "application/sdp", der ein SDP-Angebot 1 enthält.
2a. Der PGC-Server A prüft, dass eine frühe Session unterstützt wird. Zum Zwecke dieses Szenarios wird angenommen, dass eine frühe Session unterstütz wird. Der PoC-Server A kann SIP 100 Trying zu IMS-Kern A senden.

Gebührenberechnung im Netzwerk-A, erste Abfrage

3a. Der Steuerungs-PoC-Server startet eine Kredit- bzw. Guthabenkontrollsession in Richtung zu einem Heim-Prepaid-System A des Benutzers A, während eine Verarbeitung der empfangenen Sessionaufbauanfrage/SIP INVITE fortgesetzt wird. Das Prepaid-System A wird durch die ECF-Adresse identifiziert, die als Teil eines Profils des Benutzers A von einem Heim-Teilnehmersystem (HSS) zu dem S-CSCF in dem IMS-Kern A zu einer IMS-Benutzer-A-Registrierungszeit heruntergeladen ist, und in SIP INVITE von S-CSCF in dem IMS-Kern A zu dem PoC-Server A transferiert ist.
4a. Der Steuerungs-PoC-Server sendet Diameter-ACR zu dem Prepaid-System A. Diameter-ACR enthält Folgendes:

BEACHTE: Bei diesem Beispiel sind drei M-S-C-C AVPs enthalten/gezeigt. Im Allgemeinen können mehrere M-S-C-C AVPs enthalten sein, und zwar einer für jedes Messverfahren, das durch IPMM SE für die in Frage stehende Kombination aus Diensttyp und Parteienrolle unterstützt wird.

5a. Prepaid-System-A schätzt versuchsweise den Dienst (es ist bei dieser Stufe unbekannt, ob irgendein zukünftiger angefragter Dienst ein sofortiges persönliches Gespräch oder ein sofortiges ad-hoc-Gruppengespräch sein wird), basierend auf den Inhalten der empfangenen Dienstparameterinfo, führt eine Kredit- bzw. Guthabenreservierung von dem Endbenutzerkonto (das die vorhergesehenen Kosten des Dienstes abdeckt) durch und bringt eine Diameter-ACA-Meldung zu dem PoC-Server zurück. Zum Zwecke dieses Szenarios wird angenommen, dass das Guthaben des Benutzers ausreichend ist. Diameter-ACA enthält Folgendes:

Der Steuerungs-PoC-Server A beginnt ein Überwachen der Nutzung der Einheiten für einen gewährten Dienst.
Bildung einer frühen Session geht weiter

6a. Der PoC-Server A sendet SIP 202 Accepted zu UE A über den IMS-Kern A. SIP 202 Accepted enthält Folgendes: Kontakt, der den Übergangs-ad-hoc-Gruppenidentifizierer enthält, der durch den Steuerungs-PoC-Server erzeugt ist Nachrichtenkörper mit Inhaltstyp "application/sdp", der eine SDP-Antwort 1 enthält
7a. UE A sendet SIP ACK zu dem PoC-Server A über den IMS-Kern A.

Bildung einer frühen Session des Netzwerks B und Abrechnen einer ersten Abfrage
Parallel zu den Schritten 1a bis 7a im Netzwerk A finden die Schritte 1b bis 7b im Netzwerk B statt (das den Benutzer B, UE B, den IMS-Kern B, den PoC-Server B, das Prepaid-System B enthält).
Verbindung einer frühen Session
Nach einer Beendigung der Prozedur zur Bildung einer frühen Session, die in 4 dargestellt ist, wird die Verbindungsprozedur durch einen Teilnehmer (in diesem Fall UE-A) initiiert. Die 5 und 6 stellen eine Signalgabe dar, die zu einer Bildung eines sofortigen persönlichen Gesprächs (d. h. einen Verbindungsaufbau) gehört. Wiederum zeigt der Signalgabefluss nicht den Entstehungs- und den Beendigungs-IMS-Kern. Die Signalgabeschritte sind wie folgt.
Verbindungsaufbau mit früher Session

1. Der Endbenutzer bei UE A, der Teilnehmer des Netzwerks A, Drückt die PoC-Taste zum Initiieren einer Session für ein sofortiges persönliches Gespräch mit einem Endbenutzer bei UE B, dem Teilnehmer des Netzwerks B.
2. UE-A sendet SIP REFER zu dem PoC-Server A über den IMS-Kern A. SIP REFER enthält Folgendes: Bezugnahme zu: öffentliche Anwenderidentität des eingeladenen Anwenders (d. h. SIP URI oder E.164-Zahl)
3. Der Entstehungs-Teilnahme-PoC-Server A erkennt den Sessiontyp als sofortiges persönliches Gespräch basierend auf der Information in SIP REFER (d. h. eine öffentliche Anwenderidentität).

Der Entstehungs-Teilnahme-PoC-Server A nimmt die Funktion eines Steuerungs-PoC-Servers an. Die Entstehungs-Teilnahme-PoC-Serverfunktion ist logisch zusammen mit der Steuerungs-PoC-Serverfunktion angeordnet. Das bedeutet, dass für ein sofortiges persönliches Gespräch der PoC-Server, der zu dem einladenden Anwender bzw. Benutzer zugeordnet ist, der Steuerungs-PoC-Server ist.
Der Steuerungs-PoC-Server soll Folgendes:
den einladenden Anwender zu der Gesprächssession autorisieren;
SIP REFER als die implizite Teilnahmeanfrage zu einem Bezugsereignispaket für jedes abgehende SIP INVITE/REFER interpretieren (d. h. das einladende UE soll Information über eine schließliche SIP-Antwort in SIP NOTIFY eines eingeladenen Anwenders empfangen); und
SIP REFER als implizite "Bodenanfrage" interpretieren
Gebührenberechnung im Netzwerk-A, Zwischenabfrage

4. Der Steuerungs-PoC-Server führt eine Zwischenabfrage durch, um eine neue/zusätzliche Schätzeingabe zu dem Gebührenberechnungssystem A zu liefern, d. h. der Steuerungs-PoC-Server hat nun die Kenntnis darüber, dass die Session vom Typ eines sofortigen persönlichen Gesprächs ist.
5. Der Steuerungs-PoC-Server sendet Diameter-ACR zu dem Prepaid-System A. Diameter-ACR enthält Folgendes:
6. Das Prepaid-System A leitet die verwendete Menge von dem Endbenutzerkonto ab, schätzt den Dienst basierend auf den Inhalten der empfangenen Dienstparameterinfo, führt eine neue Kreditreservierung von dem Endbenutzerkonto durch (das die Kosten des Dienstes abdeckt) und bringt Diameter-ACA zurück. Zum Zwecke dieses Szenarios ist das Geldguthaben des Benutzers ausreichend. Diameter-ACA enthält Folgendes:

7. Der Steuerungs-PoC-Server A setzt eine Überwachung der Nutzung der Einheiten für einen gewährten Dienst fort.
8. Der Steuerungs-PoC-Server A sendet SIP 202 akzeptiert zu UE A über den IMS-Kern A.

Der Steuerungs-PoC-Server A sendet SIP INVITE (SDP-Angebot 2) zu dem teilnehmenden PoC-Server B. Es wird erkannt werden, dass diese Meldung direkt durch den PoC-Server A nach einem Empfang der SIP REFER-Meldung von UE A gesendet werden kann, d. h. diese Meldung kann vor oder während des Austauschs von DIAMETER-Meldungen gesendet werden (5 und 6).

10. Der teilnehmende PoC-Server B bekommt (von der GLMS-Funktionalität) das Nicht-Stören-Flag, die Zugangs(Annahme/Zurückweisungs-)Listen und den Antwortmode des eingeladenen Anwenders. Der teilnehmende PoC-Server B autorisiert die Anfrage basierend auf dem Nicht-Stören-Flag und den Zugangs-(Annahme/Zurückweisungs-)Listen des eingeladenen Anwenders bzw. Benutzers. Zum Zwecke dieses Szenarios bestimmt der teilnehmende PoC-Server B, dass das DnD-Flag nicht gesetzt ist, der einladende Benutzer nicht auf der Zurückweisungsliste ist und der Antwortmode des eingeladenen Benutzers auf "automatische Antwort" eingestellt ist.

Gebührenberechnung im Netzwerk-B, Zwischenabfrage

11. Der teilnehmende PoC-Server führt eine Zwischenabfrage durch, um eine neue/zusätzliche Schätzeingabe zu dem Abrechnungssystem A zu liefern, d. h. der teilnehmende PoC-Server hat nun Kenntnis über eine Beendigungs-PoC-Session.
12. Der teilnehmende PoC-Server sendet Diameter-ACR zu dem Prepaid-System B. Diameter-ACR enthält Folgendes:
13. Das Prepaid-System B leitet die verwendete Menge von dem Endbenutzerkonto ab, schätzt den Dienst basierend auf den Inhalten der empfangenen Dienstparameterinfo, führt eine neue Kreditreservierung von dem Endbenutzerkonto durch (das die Kosten des Dienstes abdeckt) und bringt Diameter-ACA zurück. Zum Zwecke dieses Szenarios ist das Geldguthaben eines Benutzers ausreichend. Diameter-ACA enthält Folgendes:
14. Der teilnehmende PoC-Server beginnt eine Überwachung der Nutzung der Einheiten für einen gewährten Dienst.

Verbindungsaufbau bei früher Session geht weiter

15. UE-B hat eine eingerichtete frühe Session und hat einen automatischen Antwortmode eingestellt; somit wählt der teilnehmende PoC-Server B einen frühen Medienmode aus.
16. Der teilnehmende PoC-Server B sendet SIP 200 OK (SDP-Antwort 2) zu dem Steuerungs-PoC-Server.
17. SIP ACK wird von dem Steuerungs-PoC-Server A zu dem teilnehmenden PoC-Server B gesendet. Es wird angemerkt, dass, wie bei der SIP INVITE-Meldung (9), das Senden von SIP ACK- und SIP 200-OK-Meldungen unabhängig vom Austausch von DIAMETER-Meldungen (5, 6, 12, 13) ist.
18. Der Steuerungs-PoC-Server sendet RTCP "Boden genommen" zu UE B über den teilnehmenden PoC-Server B.
19. Eine "Höranzeige" wird dem Benutzer B zugeteilt.
20. Der Steuerungs-PoC-Server sendet RTCP "Boden gewährt" zu UE A. Es wird angemerkt, dass, wie bei der SIP INVITE-Meldung (9), das Senden der Meldungen RTCP "Boden genommen" (18) und RTCP "Boden gewährt" (20) unabhängig von dem Austausch von DIAMETER-Meldungen (5, 6, 12, 13) ist.
21. Eine "Gesprächsanzeige" wird zu dem Benutzer A zugeteilt (sowohl "SIP 202 akzeptiert", was die SDP-Antwort trägt, als auch "RTCP Boden gewährt", was anzeigt, dass der PoC-Server zum Handhaben von Medien bereit ist, sind für Benutzerinteraktionszwecke nötig).

Benutzer A beginnt ein Sprechen

22. Der Benutzer A beginnt zu sprechen.
23. "RTP Gesprächsburst" (Medien) wird von UE A zu UE B über den Steuerungs-PoC-Server und den teilnehmenden PoC-Server B gesendet.
24. Der Benutzer A hört auf die Sprechphrase des Benutzers B.
25. Aufgrund einer vorherigen "impliziten Teilnahme an einem Status eines eingeladenen Benutzers" auf einen Empfang von SIP 200 OK hin sendet der Steuerungs-PoC-Server eine SIP NOTIFY-Anfrage zu dem IMS-Kern A. Der IMS-Kern A sendet SIP NOTIFY zu UE A. SIP NOTIFY enthält Folgendes: Ereignis = Bezugnahme Nachrichtenkörper bzw. Meldungskörper mit Inhaltstyp "Meldung/sipfrag", enthaltend: Die Statuszeile der SIP-Antwort, die der PoC-Server von dem eingeladenen Benutzer empfing, und zwar "SIP/2.0 200 OK" für dieses Szenario; und Die öffentliche Anwenderidentität des eingeladenen Benutzers (SIP URI oder MSISDN).
26. UE A sendet eine SIP 200 OK-Antwort auf SIP NOTIFY zu dem IMS-Kern A. Der IMS-Kern A sendet SIP 200 OK zu dem Steuerungs-PoC-Server.

Benutzer A beendet ein Sprechen

27. Der Benutzer A gibt die PoC-Taste frei.
28. UE A sendet "RTCP Bodenfreigabe" zu dem Steuerungs-PoC-Server.
29. Der Steuerungs-PoC-Server sendet "RTCP Boden leer" zu UE A.
30. Der Steuerungs-PoC-Server sendet "RTCP Boden leer" zu dem teilnehmenden PoC-Server B, der es zu UE B weiterleitet.
31. Eine "Anzeige für Boden leer" wird dem Benutzer B zugeteilt.

Mehr Gesprächsbursts können durch den Benutzer-A und den Benutzer-B gesendet/empfangen werden
Andere Gesprächsbursts können durch den Benutzer-A und den Benutzer-B gesendet/empfangen werden.
Eine andere Kreditkontroll-Zwischenabfrage kann auftreten.
Der Benutzer-A trennt sich von der Gesprächssession

32. Der Anwender-A fragt an, sich von der Gesprächssession zu trennen.
33. UE-A sendet "RTCP BYE" zu dem Steuerungs-PoC-Server.
34. Der Steuerungs-PoC-Server detektiert einen Inaktivitätszeitgeberablauf. Gemäß der Sessionbeendigungspolitik fragt der Steuerungs-PoC-Server nach einer Gesprächssessionfreigabe.
35. Der Steuerungs-PoC-Server sendet "RTCP BYE" zu dem teilnehmenden PoC-Server B, der dies zu UE-B weiterleitet.
36. Eine Anzeige für eine getrennte Session wird zu dem Anwender-B zugeteilt.
37. Der Steuerungs-PoC-Server sendet SIP BYE zu dem teilnehmenden PoC-Server B.
38. Der teilnehmende PoC-Server B antwortet mit SIP 200 OK (für SIP BYE).

Gebührenberechnung im Netzwer-A, Endabfrage

39. Der Steuerungs-PoC-Server sendet Diameter-ACR zu dem Prepaid-System A. Diameter-ACR enthält Folgendes:
40. Das Prepaid-System-A bringt Diameter-ACA zurück. Zum Zwecke dieses Szenarios ist das Geldguthaben des Anwenders ausreichend. Diameter-ACA enthält Folgendes:

Gebührenberechnung im Netzwerk-B, Endabfrage

41. Der teilnehmende PoC-Server sendet Diameter-ACR zu dem Prepaid-System B. Diameter-ACR enthält Folgendes:
42. Das Prepaid-System-B bringt Diameter-ACA zurück. Zum Zwecke dieses Szenarios ist das Geldguthaben eines Anwenders ausreichend. Diameter-ACA enthält Folgendes:

Es wird aus der obigen Diskussion erkannt werden, dass die Einführung des Prepaid-Merkmals (ein Muss für eine weite Marktakzeptanz von bestimmten PoC-Merkmalen) auf eine derartige Weise durchgeführt wird, dass die Kreditautorisierungsphase die PoC-Gesprächssessionaufbauzeit nicht beeinflusst. Das IPMM-Bedienungselement (z. B. der PoC-Server) führt eine Kreditautorisierung in Richtung zu dem Prepaid-System durch, um einen Kredit zu irgendeiner Zeit nach einer anfänglichen IMS-Anwenderregistrierung als Teil der "Prozedur für eine frühe PoC-Session" zu reservieren; das bedeutet, bevor das tatsächliche aufbauzeitkritische PoC-Dienstmerkmal (d. h. sofortiges persönliches Gespräch, sofortiges ad-hoc-Gruppengespräch), durch den Endbenutzer aufgerufen wird. Wenn der Endbenutzer das PoC-Dienstmerkmal aufruft, kann das IPMM-Bedienungselement die Dienstanfrage sofort verarbeiten, indem es sich auf den zuvor reservierten Kredit beruft; gleichzeitig führt das IPMM-Bedienungselement eine zweite Kreditautorisierung durch, um das Prepaid-System mit einer verfeinerten Schätzeingabe zu versorgen (z. B. dem tatsächlichen aufgerufenen PoC-Merkmal, der Rolle der Sessionentstehungspartei). Als Ergebnis beeinflusst die Kreditautorisierungsphase die PoC-Gesprächssessionaufbauzeit nicht.
Es wird von Fachleuten auf dem Gebiet erkannt werden, dass verschiedene Modifikationen an den oben beschriebenen Ausführungsbeispielen durchgeführt werden können, ohne von dem Schutzumfang der vorliegenden Erfindung abzuweichen.
Anhang
Drücken-zum-Sprechen bzw. Push-to-Talk über ein zellulares Netzwerk (PoC) ist ein "Walky-Talky"-Typ eines Dienstes, der auf einer IMS-Technologie basiert. Der PoC-Dienst enthält die folgenden Merkmale:
Sofortiges persönliches Gespräch
Dies ist eine (1-zu-1)-Sprachkommunikation mit einem andern Anwender, wobei die Anwender jeweils einzeln zu einer Zeit sprechen. Ein Anwender lädt den anderen Anwender ein, eine Session für ein sofortiges persönliches Gespräch aufzubauen. Ein teilnehmender Anwender des Dienstes für ein sofortiges 1-zu-1-Personengespräch kann einen neuen Anwender oder Anwender zu der Session hinzufügen, um dadurch eine 1-zu-N-Kommunikation (d. h. ein sofortiges ad-hoc-Gruppengespräch) aufzubauen.
Chat-Gruppengespräch
Dies ist eine 1-zu-N-Sprachkommunikation, wobei die Anwender einzeln zu einer Zeit sprechen. Ein Anwender schließt sich der Gruppe an, um an dem Chat-Gruppengespräch teilzunehmen (d. h. jeder Teilnehmer schließt sich der Session individuell an. Es gibt zwei Typen von Chat-Gruppen:

1. Eine offene Chatgruppe ist eine Gruppe, der sich irgendein Anwender anschließen kann.
2. Eine beschränkte Chatgruppe ist eine Gruppe mit einer Teilnehmerliste; nur der Anwender, der Besitzer der Gruppe ist, kann Gruppenteilnehmer hinzufügen und entfernen; nur die Gruppenteilnehmer können sich der Chat-Gruppengesprächssession anschließen.

Eine Gruppe muss erzeugt werden und die Teilnehmer müssen definiert werden, bevor ein Gespräch einer beschränkten Chat-Gruppe gebildet werden kann. Eine Gruppe muss erzeugt werden, bevor ein Gespräch einer offenen Chat-Gruppe gebildet werden kann. Ein Teilnehmer bei einer Gesprächssession einer laufenden offenen oder beschränkten Chat-Gruppe kann andere Anwender zu der Session hinzufügen/einladen; wenn die Gruppe beschränkt ist, kann ein Teilnehmer nur Anwender einladen, die Teilnehmer der Gruppe sind.
Sofortiges Gruppengespräch
Dies ist eine 1-zu-N-Sprachkommunikation wobei die Anwender einzeln zu einer Zeit sprechen. Einer der Teilnehmer der Gruppe lädt alle anderen Gruppenteilnehmer zu der sofortigen Gruppengesprächssession ein. Eine Gruppe muss erzeugt werden und die Teilnehmer müssen definiert werden, bevor ein sofortiges Gruppengespräch gebildet werden kann. Ein Teilnehmer der Gruppe, der die Gruppe verlassen hat oder die Einladung anfangs zurückgewiesen hat, kann sich einer laufenden sofortigen Gruppengesprächssession anschließen/neu anschließen. Ein Teilnehmer an einer laufenden sofortigen Gruppengesprächssession kann andere Teilnehmer der Gruppe zu der Session hinzufügen/einladen.
Sofortiges ad-hoc-Gruppengespräch
Dies ist eine 1-zu-N-Sprachkommunikation, wobei die Anwender einzeln zu einer Zeit sprechen. Ein Anwender lädt ausgewählte Anwender zu der sofortigen ad-hoc-Gruppengesprächssession ein. Ein Teilnehmer bei einer laufenden sofortigen ad-hoc-Gruppengesprächssession kann andere Anwender zu derselben Session hinzufügen/einladen. Ein Anwender, der die Gruppe verlassen hat oder die Einladung anfangs zurückgewiesen hat, kann sich einer laufenden sofortigen ad-hoc-Gruppengesprächssession anschließen/erneut anschließen.
Sofortiger persönlicher Alarm
Ein Anwender kann einen anderen Anwender alarmieren. Der Alarm drückt den Wunsch des Anwenders aus, zu kommunizieren, und es ist eine Art zum höflichen Anfragen des anderen Anwenders, zurückzurufen, indem beispielsweise das Merkmal eines sofortigen persönlichen Gesprächs verwendet wird. Ein sofortiger persönlicher Alarm kann eine Textmeldung tragen.
Zusätzlich werden die folgenden Fähigkeiten in Zusammenhang mit den oben beschriebenen PoC-Merkmalen verwendet.
Gruppen- und Listenmanagement
Dies lässt zu, dass PoC-Endbenutzer (und Betreiber) eine Gruppe, Listen und andere Information managen, wie es nachfolgend beschrieben ist. Die Information wird in dem Netzwerk in der Logikeinheit des Gruppen- und Listen-Managementservers (GLMS) gespeichert und über die UE-GLMS-Schnittstelle gemanagt.
Kontaktlisten
Diese werden zum Speichern von Kontakteinträgen (Individuen und Gruppe) im UE und im Netzwerk verwendet. Solche Listen sind durch UE zu verwenden, um Anwender und Gruppen zu adressieren bzw. anzusprechen, wenn eine PoC-Kommunikation initiiert wird. Kontaktlisten gelten für Sessiontypen eines sofortigen persönlichen Gesprächs und eines sofortigen ad-hoc-Gruppengesprächs.
Zugangs-(Annahme/Empfangs-)Listen
Sie werden dazu verwendet, Zugangsregeln zu definieren; das heißt, wem erlaubt oder nicht erlaubt wird, einen spezifischen Anwender über PoC-Dienste zu erreichen (d. h. ein angehobener/eingeladener Anwender kann Annahme- und Zurückweisungslisten verwenden, um ankommende Gesprächssessionanfragen von anderen Anwendern anzunehmen oder zurückzuweisen). Zugangslisten gelten für alle Gesprächssessiontypen und werden durch den PoC-Server verwendet. Dies ist ein Merkmal für eine angerufene/beendende Partei.
Gruppenlisten
Gruppenlisten werden dazu verwendet, PoC-spezifische Gruppen zu definieren und gelten für ein Gespräch einer offenen/beschränkten Chat-Gruppe und ein sofortiges Gruppengespräch. Sie werden durch den PoC-Server und UE verwendet.
Nicht Stören (DnD)
Der angerufene/eingeladene Anwender kann das "Nicht Stören"-Merkmal verwendet, das alle ankommenden Gesprächssession (außer einem sofortigen persönlichen Alarm) blockiert. DnD nimmt eine Priorität gegenüber den Zugangslisten an. Es wird durch den PoC-Server verwendet. Dies ist ein Merkmal einer angerufenen/beendenden Partei.
Antwortmode
Der angerufene/eingeladene Anwender kann automatische oder manuelle Antwortmoden auswählen, und sie werden durch den PoC-Server und UE verwendet. Es ist ein Merkmal einer angerufenen/beendenden Partei. Der PoC-Server, der den eingeladenen Anwender bedient, kann den Antwortmode dazu verwenden, den Medienmode (frühe oder späte Medien) für die Session auszuwählen.
Vorhandensein bzw. Präsenz
Dieses Merkmal wird dazu verwendet, Parteien über die Zugangsfähigkeit von anderen Parteien zu raten.

Claims

Verfahren zum Reservieren eines Kredits für einen mobilen Teilnehmer in Bezug auf einen IP-Multimediadienst, wobei das Verfahren Folgendes aufweist: nach einer anfänglichen Registrierung des Teilnehmers bei dem IP-Multimediadienst, aber vor einem Aufruf eines IP-Multimediadienstes, Verwenden der Prozedur für eine Bildung einer frühen Session, um einen Kreditbetrag bei einem Gebührenberechnungs-Steuerknoten zu reservieren und um ein IP-Multimedia-Bedienungselement über die Kreditreservierung zu benachrichtigen, woraufhin bei einem Aufruf des IP-Multimediadienstes das IP-Multimedia-Bedienungselement sofort mit der Sessionbildung fortfahren kann.
Verfahren nach Anspruch 1, wobei die Prozedur zur Bildung einer frühen Session einen Austausch von Nachrichten zwischen dem IP-Multimedia-Bedienungselement und dem Gebührenberechnungs-Steuerknoten unter Verwendung eines auf DIAMETER basierenden Protokolls aufweist.
Verfahren nach Anspruch 1 oder 2, wobei die Prozedur zur Bildung einer frühen Session nach einer Registrierung des Teilnehmers zu dem IP-Multimediadienst automatisch ausgelöst wird.
Verfahren nach Anspruch 1 oder 2, wobei die Prozedur zur Bildung einer frühen Session durch den Teilnehmer ausgelöst wird, der einen IP-Multimediadienst aktiviert.
Verfahren nach einem der vorangehenden Ansprüche, wobei der IP-Multimediadienst ein IP-Multimediadienst eines Push-to-talk über ein zellulares System ist.
Verfahren nach einem der vorangehenden Ansprüche, das an einem des IP-Multimedia-Bedienungselements und des Gebührenberechnungs-Steuerknotens ein Schätzen eines Kreditbetrags aufweist, der für den IP-Multimediadienst geeignet ist.
Verfahren nach einem der vorangehenden Ansprüche, wobei der Teilnehmer ein Prepaid-Teilnehmer ist und der Gebührenberechnungs-Steuerknoten ein Prepaid-Systemserver ist, der in dem Heimnetzwerk des Teilnehmers angeordnet ist.
Verfahren nach einem der vorangehenden Ansprüche, das bei einer Initiierung der IP-Multimediasession ein Durchführen einer Kreditautorisierungsprozedur zwischen dem IP-Multimedia-Dienstelement und dem Gebührenberechnungs-Steuerknoten basierend auf aktuellen Sessionzuständen aufweist, um einen überarbeiteten Kreditbetrag zu bilden, und ein Ersetzen oder Ergänzen des geschätzten Kreditbetrags mit dem überarbeiteten Kreditbetrag.
Verfahren zum Betreiben eines IP-Multimedia-Bedienungselements, das angeordnet und eingerichtet ist, um einen Zugang zu einem IP-Multimediadienst durch mobile Teilnehmer zu ermöglichen bzw. zu erleichtern, wobei das Verfahren Folgendes aufweist: nach einer anfänglichen Registrierung eines Teilnehmers zu dem IP-Multimediadienst als Teil einer Prozedur zur Bildung einer frühen Session Initiieren einer Transaktion mit einem Gebührenberechnungs- Steuerknoten, um einen Kreditbetrag bei dem Gebührenberechnungs-Steuerknoten zu reservieren.
Verfahren zum Betreiben eines Gebührenberechnungs-Steuerknotens, der angeordnet und eingerichtet ist, um einen Teilnehmerzugang zu IP-Multimediadiensten zu steuern, wobei das Verfahren Folgendes aufweist: Teilnehmen an einer Prozedur zur Bildung einer frühen Session nach einer anfänglichen Registrierung eines Teilnehmers zu dem IP-Multimediadienst, aber vor einem Aufruf des IP-Multimediadienstes, wobei der Gebührenberechnungs-Steuerknoten einen geeigneten Kreditbetrag schätzt, um für eine zukünftige Session reserviert zu werden.