DE60317267T2

DE60317267T2 - Aufteilung von Netzwerkinformationen

Info

Publication number: DE60317267T2
Application number: DE60317267T
Authority: DE
Inventors: Pasi Jaaskela; Keij Hasa
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2002-06-28
Filing date: 2003-06-20
Publication date: 2008-02-28
Anticipated expiration: 2023-06-21
Also published as: EP1377083B1; ES2295519T3; US20040133685A1; DE60317267D1; GB0215038D0; US7590678B2; ATE377914T1; EP1377083A1

Description

Diese Erfindung betrifft Mittel zum Teilen von Information über den Betreiber, welchem ein Kommunikationsteilnehmer zugeordnet ist. Derartige Information kann, zum Beispiel, verwendet werden, um ein Festsetzen des Tarifs für Verbindungen mit dem Endgerät des Teilnehmers zu unterstützen.
In zahlreichen Kommunikationssystemen, zum Beispiel Fernsprechsystemen, bieten eine Anzahl an Betreibern Teilnehmern Kommunikationsdienste an. Wenn ein Teilnehmer (der A-Teilnehmer) eine Kommunikationssitzung mit einem anderen Teilnehmer (dem B-Teilnehmer), initiiert, ist der Tarif für diese Kommunikationssitzung abhängig davon, welchen Betreibern jeder der Teilnehmer zugeordnet ist. Normalerweise ist der Tarif für Kommunikation zwischen Teilnehmern unterschiedlicher Betreiber höher als für Kommunikation zwischen Teilnehmern desselben Betreibers.
Jeder Teilnehmer ist normalerweise durch einen Kennungscode identifiziert, wie etwa eine Telefonnummer. Wenn Kommunikationssysteme aufgebaut werden, werden jedem Betreiber normalerweise ein oder mehrere Blöcke von Kennungscodes zugeteilt, und danach kann die Zuteilung von Codes innerhalb jedes Blocks an den jeweiligen Betreiber delegiert werden. Der Einfachheit halber weist jeder Block normalerweise eine gemeinsame Vorwahl auf, und der Betreiber teilt die Zeichen zu, die der Vorwahl folgen. Zum Beispiel kann einem Betreiber die Vorwahl 0777 zugeteilt werden, und er kann dann die Nummern 0777 111 111, 0777 111 112 usw. zuteilen. In einem System dieser Art ist es möglich, mittels der Vorwahl den Betreiber zu identifizieren, welchem ein Teilnehmerkennungscode zugeordnet ist. Das macht es einfach, den Tarif für eine Kommunikationssitzung zu bestimmen. Wenn ein A-Teilnehmer eine Kommunikationssitzung mit einem B-Teilnehmer initiiert, kann der Betreiber, welchem der B-Teilnehmer zugeordnet ist, aus dem Teilnehmerkennungscode des B-Teilnehmers bestimmt werden. Der A-Teilnehmer kann ebenfalls als der rufende Teilnehmer bekannt sein. Der B-Teilnehmer kann ebenfalls als der gerufene Teilnehmer bekannt sein. Der Teilnehmerkennungscode des B-Teilnehmers ist oft bekannt als die B-Nummer oder die Called Party Number/Rufnummer des gerufenen Teilnehmers (CdPN).
1 zeigt einige Komponenten eines Mobiltelefonsystems. In dem System in 1 gibt es zwei Mobilstationen (MSs) 1, 2, welche über Funk mit einem Netz 3 kommunizieren können. Jede Mobilstation weist ein Subscriber Identity Module/Teilnehmerkennungsmodul (SIM) auf, welches einen Code speichert, welcher den Teilnehmerkennungscode identifiziert, den die Mobilstation verwendet. Zum Beispiel hat im GSM-System jeder Teilnehmer zwei Kennungscodes:

1. IMSI (International Mobile Subscriber Identity/Internationale Mobilkommunikationsteilnehmerkennung) oder E.212. Diese Nummer ist auf der SIM-Karte des Teilnehmers gespeichert, sie ist jedoch nicht portierbar, wenn der Teilnehmer zu einem anderen Betreiber wechselt. Im Allgemeinen braucht niemand, mit Ausnahme des Betreibers, normalerweise diese Nummer zu kennen.
2. MSISDN (Mobile Subscriber International ISDN Number/Mobile Internationale Teilnehmer-ISDN-Nummer) oder E.164 oder Teilnehmerrufnummer oder Fernsprechnummer. Ein A-Teilnehmer muss diese Nummer kennen, wenn er einen B-Teilnehmer ruft. Diese Nummer ist nicht auf der SIM-Karte gespeichert, jedoch ist diese Nummer portierbar, wenn Rufnummernportabilität genutzt wird. Sie entspricht der Kennung, welche in dieser Schrift als ein Kennungscode bezeichnet ist.

Wenn eine der Mobilstationen (MS, sei es 1) eine Kommunikationssitzung (z.B. einen Telefonanruf) mit der anderen initiieren will, wird eine Nachricht an eine Vergebührungssteuereinheit 4 gesendet, welche den Tarif für die Kommunikationssitzung bestimmen soll. Der Tarif hängt vom Betreiber ab, welchem die von der MS 2 (dem B-Teilnehmer) verwendete Teilnehmerkennung zugeordnet ist. Die Nachricht, welche an die Vergebührungssteuereinheit 4 gesendet wird, enthält die Teilnehmerkennung des B-Teilnehmers. Die Vergebührungssteuereinheit speichert eine Nachschlagetabelle, welche Teilnehmerkennungscode-Vorwahlen in Gegenüberstellung zu ihren jeweiligen Betreibern auflistet. Um den Betreiber zu bestimmen, welchem der B-Teilnehmer zugeordnet ist, führt die Vergebührungssteuereinheit ein Nachschlagen in der Tabelle aus, unter Verwendung der Vorwahl der Teilnehmerkennung des B-Teilnehmers. Das ergibt die Kennung des relevanten Betreibers, und auf Basis dieser Information kann die Vergebührungssteuereinheit einen Tarif für die Kommunikationssitzung bestimmen.
Die Vergebührungssteuereinheit 4 könnte ein Service Control Point/Dienststeuerknoten (SCP) eines Intelligenten Netzes (IN) in einem Netz der dritten Generation (3G) oder einem UMTS-(Universal Mobile Telecommunications System-)Netz sein, oder eine Service Control Function/Dienststeuerfunktion (SCF) in einem GSM-(Global System for Mobile Telecommunications-)Netz. 2 illustriert das Signalisieren, das stattfindet, wenn eine Verbindung aufgebaut wird. Das/die MSC (Mobile Switching Centre/Mobilkommunikationsvermittlungsstelle 5) des Netzes gibt an den/die SCP/SCF 4 eine IDP-(Initial DP(Detection Point) Operation-)Nachricht, welche die Rufnummer des A-Teilnehmers (die A-Nummer), die Rufnummer des B-Teilnehmers (die B-Nummer) und den Service Key enthält. Der/die SCP/SCF analysiert danach die B-Nummer, um den Tarif zu bestimmen, welcher auf die Verbindung anzuwenden ist, und gibt das an das MSC, in FCI-(Furnish Charging Information-) und CUE-(Continue-)Nachrichten. Unter Verwendung der Information in den FCI- und CUE-Nachrichten kann das MSC bewirken, dass die Verbindung entsprechend dem geeigneten Tarif verrechnet wird.
Es gibt Bestrebungen, Rufnummernportabilität für Teilnehmer von Mobiltelefonnetzen einzuführen. Bei Rufnummernportabilität werden Teilnehmer in der Lage sein, ihre Anmeldung von einem Betreiber zu einem anderen zu übertragen, während sie denselben Teilnehmeridentifikationscode behalten. Das wird die einmehrdeutige Relation zwischen Betreibern und Teilnehmeridentifikationscodes aufbrechen. Bei Rufnummernportabilität wird der Teilnehmeridentifikationscode eines Teilnehmers, der die Betreiber gewechselt und ihren Teilnehmeridentifikationscod^e behalten hat, eine Vorwahl aufweisen, die dem Betreiber entspricht, von welchem der Teilnehmer weggegangen ist, nicht dem Betreiber, welchem der Teilnehmer nun zugeordnet ist.
Das wird Probleme verursachen beim Bestimmen des Tarifs, welcher auf eine Kommunikationssitzung anzuwenden ist, da eine Verrechnungssteuereinheit nicht länger in der Lage sein wird, eine Nachschlagetabelle mit Betreibervorwahlen zu verwenden, um den Betreiber zu bestimmen, welchem ein B-Teilnehmer zugeordnet ist.
Zwei Lösungen für dieses Problem sind gegenwärtig verfügbar. Zum einen könnte die Vergebührungssteuereinheit eine ausführlichere ergänzende Nachschlagetabelle aller Teilnehmerkennungscodes speichern, oder jener Codes, die Ausnahmen darstellen zu den üblichen Korrelationen zwischen Vorwahlen und Betreibern. Allerdings wäre eine derartige Nachschlagetabelle sehr umfangreich, und die Tabellen aller Vergebührungssteuereinheiten in einem System würden ständiges Aktualisieren erfordern, um Teilnehmern zu folgen, sowie sie ihre Netze ändern. Alternativ könnte die Vergebührungssteuereinheit angeordnet sein, eine externe Datenbank abzufragen, um die Betreiberinformation selbst zu holen.
Zum Beispiel beschreibt die Europäische Patentanmeldung Nr. 0 767 572 ein Verfahren zum Erhalten einer Verrechnungsvalidierung von Teilnehmerkonten durch Abfragen einer Nummernportabilitätsdatenbank, um Routinginformation zu beziehen, welche die geeignete Vermittlungsstelle für eine Verbindung in einem Telekommunikationsnetz identifiziert.
Die veröffentlichte Europäische Patentanmeldung EP-A-1 510 065 beschreibt ein System und ein Verfahren zum Bestimmen eines Tarifs für Echtzeit-Funkdienste, wie etwa Prepaid-Dienste für eine Funktelefonverbindung. Ein lokaler Rufnummernportabilitätsknoten bietet eine Schnittstelle zwischen Service Scripts, in einem Service Control Point oder Applikationsserver, und einer lokalen Nummernportabilitätsdatenbank. Wenn eine Initial Detection Point-Nachricht von dem Service Script empfangen wird, wird eine Abfrage durch den lokalen Rufnummernportabilitätsknoten an die lokale Rufnummernportabilitätsdatenbank gesendet, um zu bestimmen, ob der Ruf von oder zu einer portierten Telefonnummer getätigt wird.
Beide der obigen Optionen würden erfordern, dass die Vergebührungssteuereinheit im Wesentlichen neu zu konfigurieren wäre. Bei großen Anzahlen an SCFs, welche bereits in Verwendung sind, wäre das sehr teuer. Daher besteht ein Bedarf an einem verbesserten Mittel, den Fragen, wie etwa jenen, die sich auf Grund von Rufnummernportabilität stellen, zu begegnen.
Gemäß der vorliegenden Erfindung ist ein Verfahren vorgesehen, zum Bestimmen eines Tarifs, anzuwenden auf eine Verbindung in einem Kommunikationssystem, mittels dessen Verbindungen hergestellt werden können, zu Endgeräten, welche einem beliebigen von mehreren Betreibern zugeordnet sind, wobei jedes Endgerät mittels einer Teilnehmerkennung adressierbar ist, welche formatiert ist, ein erstes Feld und ein zweites Feld zu enthalten, wobei das erste Feld, für wenigstens einige der Teilnehmerkennungen, den Betreiber angibt, welchem eine jeweilige Teilnehmerkennung zugeordnet ist, wobei das Verfahren umfasst: Senden, an eine Betreiberbestimmungsfunktion des Netzes, einer ersten Nachricht, welche einen Tarif für eine Verbindung anfordert und ein Teilnehmerkennungsfeld enthält, welches eine Angabe der Teilnehmerkennung des zu rufenden Endgeräts der Verbindung umfasst; Empfangen der ersten Nachricht in der Betreiberbestimmungsfunktion; Bestimmen, mittels der Betreiberbestimmungsfunktion, des Betreibers, welchem die Teilnehmerkennung des zu rufenden Endgeräts der Verbindung zugewiesen ist, und von Inhalt des ersten Felds, der diesem Betreiber zugeordnet ist; Bilden, in der Betreiberbestimmungsfunktion, einer modifizierten Teilnehmerkennung, welche, als ihr zweites Feld, wenigstens den Inhalt des zweiten Felds der Teilnehmerkennung des zu rufenden Endgeräts der Verbindung aufweist, und welche, als ihr erstes Feld, den Inhalt des ersten Felds, welcher diesem Betreiber zugeordnet ist, aufweist; Bilden, in der Betreiberbestimmungsfunktion, einer zweiten Nachricht, welche einen Tarif für eine Verbindung anfordert und ein Teilnehmerkennungsfeld enthält, welches die modifizierte Teilnehmerkennung umfasst; und Senden der zweiten Nachricht an eine Tarifbestimmungsfunktion, welche angeordnet ist, eine Teilnehmerkennung zu analysieren, welche in einer Nachricht empfangen wird, welche einen Tarif für eine Verbindung anfordert, um einen Tarif zu bestimmen, auf Basis des ersten Felds der empfangenen Teilnehmerkennung.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung ist eine Betreiberbestimmungsfunktion vorgesehen, zur Verwendung beim Bestimmen eines Tarifs, anzuwenden auf eine Verbindung in einem Kommunikationssystem, mittels dessen Verbindungen hergestellt werden können, zu Endgeräten, welche einem beliebigen von mehreren Betreibern zugeordnet sind, wobei jedes Endgerät mittels einer Teilnehmerkennung adressierbar ist, welche formatiert ist, ein erstes Feld und ein zweites Feld zu enthalten, wobei das erste Feld, für wenigstens einige der Teilnehmerkennungen, den Betreiber angibt, welchem eine jeweilige Teilnehmerkennung zugeordnet ist, wobei die Betreiberbestimmungsfunktion umfasst: eine Betreiberbestimmungseinheit, welche anspricht auf Empfangen einer ersten Nachricht, welche eine Angabe der Teilnehmerkennung des zu rufenden Endgeräts der Verbindung enthält, um den Betreiber zu bestimmen, welchem die Teilnehmerkennung des zu rufenden Endgeräts der Verbindung zugewiesen ist, und Inhalt des ersten Felds, der diesem Betreiber zugeordnet ist; eine Kennungsmodifizierung, angeordnet, den Inhalt zu empfangen und eine modifizierte Teilnehmerkennung zu bilden, welche, als ihr zweites Feld, wenigstens den Inhalt des zweiten Felds der Teilnehmerkennung des zu rufenden Endgeräts der Verbindung aufweist, und welche, als ihr erstes Feld, den Inhalt des ersten Felds, der diesem Betreiber zugeordnet ist, aufweist; eine Nachrichtenbildung, angeordnet, die modifizierte Teilnehmerkennung zu empfangen und eine zweite Nachricht zu bilden, welche einen Tarif für eine Verbindung anfordert und ein Teilnehmerkennungsfeld enthält, welches die modifizierte Teilnehmerkennung umfasst; und eine Nachrichtenübertragung zum Senden der zweiten Nachricht an eine Tarifbestimmungsfunktion, welche angeordnet ist, eine Teilnehmerkennung zu analysieren, welche in einer Nachricht empfangen wird, welche einen Tarif für eine Verbindung anfordert, um einen Tarif zu bestimmen, auf Basis des ersten Felds der empfangenen Teilnehmerkennung.
Geeigneterweise umfasst das Verfahren: Senden, gemeinsam mit der Angabe der Teilnehmerkennung des zu rufenden Endgeräts der Verbindung, einer Angabe der Art der Verbindung; Bilden der zweiten Nachricht derart, dass sie die Angabe der Art der Verbindung enthält; wobei die Tarifbestimmungsfunktion angeordnet ist, den Tarif, auf Basis des ersten Felds der empfangenen Teilnehmerkennung und der Angabe der Art der Verbindung, zu bestimmen.
In einer Ausführungsform hat die Betreiberbestimmungsfunktion Zugriff auf eine erste Datenbank, die eine Liste von Teilnehmerkennungen speichert, und für jede einzelne eine Angabe des Betreibers, welchem die jeweilige Teilnehmerkennung zugeordnet ist, und der Schritt des Bestimmens umfasst Nachschlagen der Teilnehmerkennung des zu rufenden Endgeräts der Verbindung in der ersten Datenbank und Beziehen einer beliebigen Angabe eines Betreibers, welcher derselben in der ersten Datenbank zugeordnet ist. Das Fehlen einer Teilnehmerkennung aus der Datenbank kann angeben, dass der Inhalt des ersten Felds dieser Teilnehmerkennung dem Betreiber zugeordnet ist, welchem diese Teilnehmerkennung zugewiesen ist. Die Angabe eines Betreibers kann der Inhalt des ersten Felds sein, der diesem Betreiber zugeordnet ist. Alternativ kann die Betreiberbestimmungsfunktion Zugriff haben auf eine zweite Datenbank, die eine Liste von Indikatoren für Betreiber und für jeden einzelnen Inhalt des ersten Felds, der diesem Betreiber zugeordnet ist, speichert, und der Schritt des Bestimmens kann Nachschlagen der Angabe eines Betreibers in der zweiten Datenbank umfassen, und Beziehen von Inhalt aus dem ersten Feld, welcher demselben zugeordnet ist.
Das Teilnehmerkennungsfeld der Nachricht, welche einen Tarif für eine Verbindung anfordert, enthält das erste Feld der Teilnehmerkennung des zu rufenden Endgeräts der Verbindung vorzugsweise nicht. Im bevorzugtesten Fall besteht es aus der Teilnehmerkennung des zu rufenden Endgeräts der Verbindung.
Vorzugsweise wird, wenn, in dem Schritt des Bestimmens, bestimmt wird, dass der Inhalt des ersten Felds der Teilnehmerkennung des Endgeräts dem Betreiber zugeordnet ist, welchem diese Teilnehmerkennung zugewiesen ist, die zweite Nachricht, welche einen Tarif für eine Verbindung anfordert, gebildet, wobei ihr Teilnehmerkennungsfeld die Teilnehmerkennung unmodifiziert umfasst.
Die Nachrichten können, zum Beispiel, IDP-Nachrichten oder SIP-INVITE-Nachrichten sein.
Vorzugsweise ist jede Teilnehmerkennung eine Telefonnummer. Vorzugsweise ist jede Teilnehmerkennung eine Teilnehmerrufnummer, mit welcher die Mobilstation zu erreichen ist, z.B. eine MSISDN. Vorzugsweise ist jedes erste Feld eine Betreibervorwahl.
Vorzugsweise umfasst die Tarifbestimmungsfunktion einen oder mehrere Service Control Points (SCP) eines Intelligenten Netzes (IN) und eine Service Control Function (SCF).
Jede Nachricht, welche einen Tarif für eine Verbindung anfordert, umfasst vorzugsweise ein Quellenfeld, zum Angeben der Quelle der Nachricht. Vorzugsweise umfassen die Quellenfelder sowohl der ersten als auch der zweiten Nachricht eine Angabe der Quelle der ersten Nachricht, und, im bevorzugtesten Fall, nicht jener der Quelle der zweiten Nachricht.
Vorzugsweise umfasst das Verfahren: die Tarifbestimmungsfunktion, welche einen Tarif für die Verbindung bestimmt; und Anwenden des Tarifs auf die Verbindung.
Die Verbindung ist vorzugsweise eine Verbindung für Transfer von Daten, welche Sprachdaten umfassen könnten.
Die vorliegende Erfindung ist nun, mit Beispielcharakter, zu beschreiben, mit Bezug auf die begleitenden Zeichnungen.
In den Zeichnungen zeigen:
1 ein schematisches Diagramm eines Telekommunikationsnetzes;
2 das Signalisieren während eines Rufaufbaus;
3 ein schematisches Diagramm eines Telekommunikationsnetzes, welches eine Rufnummernportabilitätsdatenbank vor Vergebührung enthält;
4 das Signalisieren in dem System in 3;
5 und 6 alternative Ausführungsformen des Systems in 3; und
7 GT-Transformationsausführungsformen.
3 ist ein schematisches Diagramm eines Telekommunikationsnetzes, welches eine Rufnummernportabilitätsformatierung 10 vor Vergebührung enthält. Dieses Beispiel ist mit Bezug auf ein 3G-Netz gezeigt, doch das Prinzip könnte auf Netze anderer Art angewendet werden. Wenn eine Verbindung aufgebaut wird, signalisiert der Service Switching Point/Dienstvermittlungsknoten (SSP) 11 nicht direkt an den SCP 12 die Rufnummer des B-Teilnehmers, wie das in einem konventionellen System der Fall wäre. Stattdessen signalisiert er an den SSP über die Formatierung 10. Die Formatierung 10 bestimmt den Betreiber, welchem die B-Nummer zugeordnet ist und gibt das an den SCP. In diesem Beispiel signalisiert die Formatierung die Kennung des Betreibers an den SCP in der Form einer Teilnehmerkennungsvorwahl, welche diesem Betreiber zugeordnet ist. Das bedeutet, dass der SCP funktionieren kann, wie er das normalerweise tut, um den Betreiber zu identifizieren: z.B. mittels einer Vorwahl, welche diesem Betreiber zugeordnet ist.
Das Funktionieren des Systems in 3 ist nun ausführlicher zu beschreiben. 3 zeigt die relevanten Teile eines 3G-Telekommunikationsnetzes. Das Netz umfasst eine Vergebührungssteuereinheit 12, welche, in diesem Beispiel, eine erste Verarbeitungseinheit 12a enthält, welche als ein SCP oder eine SCF für Prepaid-Teilnehmer wirkt, und eine zweite Verarbeitungseinheit 12b, welche als ein SCP für Account-Teilnehmer wirkt. Die beiden Verarbeitungseinheiten wirken zusammen, um eine integrierte SCP-Funktion vorzusehen. Das Netz enthält wenigstens einen SSP 11, welcher auf ähnliche Weise wirkt wie ein MSC in einem GSM-Netz: d.h. zum Überwachen der Vermittlungs- und Rufsteuerung (einschließlich Vergebührung), wenn eine Verbindung aufgebaut wird, besteht und beendet wird. Zur Illustration die Mobilstationen 13, 14, welche über Funk mit dem Netz 15 kommunizieren können, in welchem die Einheiten 10 bis 12 funktionieren.
Das Signalisieren, welches während des Verbindungsaufbaus stattfindet, um die Tarifinformation an den SSP 11 zu geben, ist durch Schritte 21 bis 24 in 3 illustriert. In Schritt 21 sendet der SSP 11 eine IDP-Nachricht an die Formatierung 10. Diese IDP-Nachricht enthält den Kennungscode des A-Teilnehmers (die A-Nummer), den Kennungscode des B-Teilnehmers (die B-Nummer) und den Service Key. Bei Empfangen der Nachricht führt die Formatierung Nachschlagesuchläufe aus, um den Betreiber zu bestimmen, welchem die B-Nummer zugeordnet ist (die Details dieser Nachschlagesuchläufe sind später zu beschreiben) und danach eine Teilnehmerkennungscode- Vorwahl zu bestimmen, welcher dieser Betreiber zugeordnet ist. Diese wird als die Betreibervorwahl bezeichnet. Danach, in Schritt 22, sendet die Formatierung 10 eine IDP-Nachricht an die Vergebührungssteuereinheit 12. Diese IDP-Nachricht umfasst die A-Nummer, die Betreibervorwahl, die B-Nummer und den Service Key. Bei Empfangen dieser Nachricht analysiert die Vergebührungssteuereinheit 12 die Nachricht und bestimmt einen Tarif für die Verbindung auf Basis von Information, welche die Betreibervorwahl enthält. Das ist im Folgenden ausführlicher zu beschreiben. Bei Bestimmen des Tarifs sendet die Vergebührungssteuereinheit Information, welche den Tarif identifiziert, an den SSP, in einer FCI-Tarifinformationsnachricht. (Schritt 23). Sie sendet auch eine Continue-Nachricht (Schritt 24) an den SSP, um ihn zu autorisieren, mit dem Aufbau der Verbindung fortzufahren. Vergebührung der Verbindung wird entsprechend dem Tarif durchgeführt, welcher in der in Schritt 23 gesendeten Nachricht angegeben ist.
Um diesen Mechanismus mit jenem zu kontrastieren, welcher in 2 gezeigt ist, stellt 4 ein Blockdiagramm dar, welches die Einheiten 10, 11 und 12 zeigt, sowie Signalisierungsschritte 21, 22, 23 und 24. Es ist zu sehen, dass die Formatierung 10 als eine vermittelnde Stelle zwischen dem SSP oder dem MSC 11 und dem SCP oder der SCF 12 wirkt.
In dieser Ausführungsform führt die Formatierung 10 ein Nachschlagen aus, um die Betreibervorwahl zu bestimmen. Sie greift auf eine Datenbank zu, um den Betreiber zu bestimmen, welchem die B-Nummer zugeordnet ist. In einem System wie etwa GSM oder UMTS ist das der Betreiber des Heimatnetzes des B-Teilnehmers. Die Datenbank könnte die eines SSRi des Netzes sein, oder eine äquivalente Funktion. Ausführen eines Nachschlagens der B-Nummer unter Verwendung des SSRi kann die Direction Specific Data/richtungsspezifischen Daten (DIRE) ergeben, welche der B-Nummer zugeordnet sind. Die DIRE umfassen eine(n) Subscription Network Identifier/Anmeldungsnetzidentifikation (SNID), welche(r) als die Betreibervorwahl verwendet werden kann. Es versteht sich, dass die Formatierung andere Mechanismen verwenden könnte, um die Betreibervorwahl herzuleiten. Zum Beispiel könnte die Formatierung ihre eigene Datenbank von Teilnehmerrufnummern und von jeder einzelnen zugeordneten Betreibern speichern, und eine Datenbank von jedem Betreiber zugeordneten Teilnehmervorwahlen. Alternativ könnte sie eine Datenbank von Nummern speichern, welche von einem Betreiber zu einem anderen übertragen worden sind, mit einer Angabe des Betreibers für jede einzelne, zu welchem sie übertragen worden sind, und eine Datenbank, welche eine jedem Betreiber zugeordnete Teilnehmervorwahl angibt. Im letzteren Fall würde die Datenbank von Nummern, die übertragen worden sind, analog sein zu einer Rufnummernportabilitätsdatenbank (NPDB) einiger leitungsvermittelter (CS-)Netze.
Die Vergebührungssteuereinheit bestimmt den für die Verbindung zu verwendenden Tarif auf Basis von Information, welche den Betreiber enthält, welchem der Teilnehmer, welcher den B-Teilnehmer darstellt, zugeordnet ist. Im Normalfall würde die Vergebührungssteuereinheit die Vorwahl der B-Nummer analysieren, wie empfangen in einer Nachricht, welche einen Tarif für eine Verbindung anfordert. Auf Basis dieser Vorwahl würde sie den Betreiber bestimmen, auf welchen sich diese Vorwahl bezieht. Danach würde sie einen Tarif für die Verbindung bestimmen. Weitere Informationen, die ebenfalls in das Bestimmen des Tarifs einbezogen werden könnten, umfassen die Tageszeit, den Wochentag, die Dienstart und die Verbindung. Wenn die Betreibervorwahl der B-Nummer vorgestellt ist, kann exakt dieselbe Verarbeitung ausgeführt werden, um dasselbe Resultat zu ergeben. Eine Illustration dessen folgt.
In dieser Illustration ist davon auszugehen, dass das Format der B-Nummer konventionell so ist, dass die ersten fünf Ziffern der B-Nummer den Betreiber darstellen, welchem sie zugeordnet ist. So weist, in diesem Beispiel, die B-Nummer zwei Felder auf. Eines ist durch die ersten fünf Ziffern der Rufnummer dargestellt. Es gibt konventionell den Betreiber an, welchem die Rufnummer zugewiesen ist, wenngleich es das nicht tut, wenn die Rufnummer von einem Betreiber zu einem anderen portiert worden ist. Das andere Feld ist durch den Rest der Nummer dargestellt. Es versteht sich, dass die beiden Felder andere Formen annehmen können als eine Vorwahl und eine Nachwahl.
Die Vergebührungssteuereinheit speichert eine Tabelle (Tabelle 1), welche Tarife für Verbindungen unterschiedlicher Arten zu unterschiedlichen Betreibern angibt. Der Einfachheit halber verwendet die Tabelle in diesem Beispiel nur zwei Variablen, jedoch könnten in einem praktischen Beispiel mehr verwendet werden.

Verbindungsart

X Y Z

Betreiber A Tarif 2 Tarif 1 Tarif 1

B Tarif 3 Tarif 3 Tarif 2

C Tarif 5 Tarif 4 Tarif 5

TABELLE 1
Die Vergebührungssteuereinheit speichert ebenfalls eine Tabelle (Tabelle 2), welche den Betreiber angibt, welcher konventionell jeder von einer Anzahl von B-Nummernvorwahlen zugeordnet ist.

Vorwahl Betreiber

07114 A

07115 C

07198 B

07457 B

07777 A

TABELLE 2
Die Vergebührungssteuereinheit ist konfiguriert, die folgenden Schritte auszuführen, wenn sie eine Anforderung nach einem Tarif für eine Verbindung einer gewissen Art mit einer gewissen B-Nummer empfängt.

1. Nachschlagen der ersten fünf Ziffern der B-Nummer in Tabelle 2, um den entsprechenden Betreiber zu bestimmen.
2. Nachschlagen des bestimmten Betreibers und der Verbindungsart in Tabelle 1, um den Tarif zu bestimmen.
3. Ausgeben des Tarifs an die Einheit, die ihn angefordert hat.

Wenn also die Vergebührungssteuereinheit eine Anforderung nach einem Tarif für eine Verbindung von der Art X mit B-Nummer 07198 154786 empfangen hätte, würde sie ausführen:

1. Nachschlagen der Ziffern 07198 in Tabelle 2 und dadurch Bestimmen, dass sie Betreiber B betreffen.
2. Nachschlagen von Betreiber B und Art X in Tabelle 1, und dadurch Bestimmen, dass Tarif 3 der Tarif sein sollte.
3. Ausgeben einer Angabe von Tarif 3 an die anfordernde Einheit.

Nun wird, in dem oben beschriebenen System, die B-Nummer, sowie sie an die Vergebührungssteuereinheit gesendet wird, modifiziert durch das Vorstellen einer Betreibervorwahl. Zum Beispiel könnte die Nummer 07198 154786 übertragen worden sein, um Betreiber C zugeordnet zu werden. In diesem Fall könnte die Betreibervorwahl 07115 von der Formatierung vorgestellt werden, sodass die B-Nummer, wenn empfangen von der Vergebührungssteuereinheit, nun 0711507198 154786 ist. In diesem Fall sind die ersten fünf Ziffern der B-Nummer, wie empfangen von der Vergebührungssteuereinheit, 07115, sodass die ausgeführten Schritte sind:

1. Nachschlagen der Ziffern 07115 in Tabelle 2 und dadurch Bestimmen, dass sie Betreiber C betreffen.
2. Nachschlagen von Betreiber C und Art X in Tabelle 1, und dadurch Bestimmen, dass Tarif 5 der Tarif sein sollte.
3. Ausgeben einer Angabe von Tarif 5 an die anfordernde Einheit.

So kann die Vergebührungssteuereinheit ganz einfach so funktionieren, wie sie das zuvor getan hat, jedoch wird das System im Ganzen, bei Rufnummernportabilität, konsistent funktionieren.
In dem System in 3 werden die IDP-Dienstanforderungen vor dem Hintergrund des Systems des Intelligenten Netzes bedient. Signalisierung entsprechend Core INAP (Intelligent Network Application Protocol) und CAP (CAMEL (Customised Applications for Mobile Networks Enhanced Logic) Applicaption Part) kann verwendet werden.
5 und 6 zeigen zwei alternative Ausführungsformen des Systems. In 5 und 6 sind gleiche Komponenten mit Bezugszeichen wie in 3 versehen.
5 zeigt eine Ausführungsform, konsistent mit einer Implementierung in einem Netz eines IP Multimedia Subsystems (IMS) (wie spezifiziert in 3GPP TS 23.228 v.5.3.0), unter Verwendung von CAP/INAP. Eine CAMEL/INAP SSF 30 tritt an die Stelle des SSP 11 in 3. Die SSF 30 ist verbunden mit einem CPS 31 über eine ISC(SIP)-Schnittstelle 32. Das CPS enthält eine S-CSCF, wie in einem normalen IMS-Netz. Diese Ausführungsform ist nützlich, wenn die IMS-Teilnehmer über E.164-Adressen verfügen (zusätzlich zu logischen IMS-Adressen).

In dieser Ausführungsform werden die Nachrichten gesendet wie folgt:

Schritt 21:	IDP-Nachricht, welche A-Nummer, B-Nummer
	und Service Key spezifiziert
Schritt 22:	IDP-Nachricht, welche A-Nummer, B-Nummer
	mit der bestimmten Betreibervorwahl,
	vorgestellt als Vorwahl, und Service Key
	spezifiziert
Schritt 23:	FCI-Tarifinformationsnachricht
Schritt 24:	CONTINUE-Nachricht

In weiterer Folge setzt der SCP oder die SCF 12 einen Dialog mit der SSF 30 zum Austauschen von Tarifinformation während des Bestehens der Verbindung fort.
6 zeigt eine Ausführungsform, konsistent mit einer Implementierung in einem Netz eines IP Multimedia Subsystems (IMS), unter Verwendung von ISC/SIP-Signalisierung. Ein CPS 40 tritt an die Stelle des SSP 11 in 3. Das CPS ist verbunden mit der Formatierung 10 und dem SCP oder der SCF 12, über ISC(SIP)-Schnittstellen 41, 42. Eine weiter gefasste Benennung, Applikationsserver (APSE), für die Einheit, welche die Funktionalität des SCP oder der SCF bietet, wird in IMS-Netzen häufig verwendet.

In dieser Ausführungsform werden die Nachrichten, welche in Schritten 21, 22 und 23 gesendet werden, als SIP-INVITE-Nachrichten gesendet. Die Parameter der Nachrichten sind wie folgt:

Schritt 21:	To: B-Nummer
	From: A-Nummer
	P-Header-1: Service Key
	Route: Formatierung 10, CPS 40

Schritt 22:	To: B-Nummer
	From: A-Nummer
	P-Header-1: Service Key
	P-Header-2: Betreibervorwahl
	("Ursprungsnetz-ID")
	Route: SCP 12, CPS 40

Schritt 23:	To: B-Nummer
	From: A-Nummer
	P-Header-2: Betreibervorwahl
	("Ursprungsnetz-ID")
	P-Header-3: Tarifidentifikation
	Route: CPS 40

So kann in dieser Ausführungsform das grundsätzliche SIP-Protokoll verwendet werden.
Es ist anzumerken, dass selbst wenn die in Schritt 22 gesendete Nachricht von der Formatierung 10 kommt, die Quelle der Nachricht in der Nachricht angegeben ist, als sei sie das CPS 40. Das bedeutet, dass die Antwort in Schritt 23 an das CPS 40 zurückgesendet werden kann, welches der Ursprung der Anforderung nach einem Tarif in Schritt 21 war. (Siehe ISC-Spezifikationen 3GPP TS 23.218 und RFC 3261). Die Formatierung 10 inkludiert kein Nennen ihrer selbst im Record-Route-Feld der in Schritt 22 gesendeten SIP-Nachricht, sodass sie nicht inkludiert ist im Routing nachfolgender SIP-Nachrichten in derselben Sitzung. Derartige Nachrichten könnten gesendet werden, um mit dem Verbindungsaufbau fortzufahren (z.B. PRACK, UPDATE), oder um eine aktive Verbindung zu beenden (BYE).
Dieselbe Funktionalität kann ebenfalls bei IDP-Nachrichten vorgesehen sein. (Siehe 3.) Die Formatierung 10 inkludiert kein Nennen ihrer selbst, wenn sie die Nachricht an den SCP 12 sendet. Die Quelle der Nachricht ist in der Nachricht angegeben, als sei sie der SSP 11. Das bedeutet, dass die Antwort in Schritten 23 und 24 an den SSP 11 zurückgesendet werden kann, welcher der Ursprung der Anforderung nach einem Tarif in Schritt 21 war.
Um ein System zu implementieren, von der Art, wie es in 6 illustriert ist, könnte das Dienstprofil des A-Teilnehmers die Adresse der Formatierung 10 enthalten, jedoch nicht jene des SCP 12. Die Formatierung 10 könnte dann Verarbeitungslogik enthalten, die eine Dienstschnittstelle oder eine normale SIP-Schnittstelle zu dem geeigneten SCP/APSE aufrufen kann, auf Basis von (zum Beispiel) der Dienstidentifikation, welche in dem P-Header-1 der Nachricht in Schritt 21 empfangen wird.
Der SCP/APSE könnte die Betreibervorwahl oder "Ursprungsnetz-ID" aus der Nachricht weglassen, welche in Schritt 23 gesendet wird, da die Tarifinformation, welche (in diesem Beispiel) in P-Header-3 getragen ist, von anderen Diensten verwendet werden könnte, welche von dem CPS aufgerufen werden, nachdem APSE-Dienste fertiggestellt sind.
Die oben im Zusammenhang mit 6 beschriebenen Nachrichten verwenden das P-Header-Konzept, spezifiziert in IETF. Ein weiterer Mechanismus zum Liefern der zusätzlichen Information, welche in diesem Beispiel von den P-Headern getragen wird, ist die Verwendung eines speziellen Body-Teils in der SIP-Nachricht.
Vorsehen einer Formatierung 10, um der Vergebührungssteuereinheit 12 eine Angabe des Netzes des B-Teilnehmers bereitzustellen, weist eine Anzahl von Vorteilen gegenüber anderen Lösungen auf. So erfordert es geringe, oder keine, Modifikation an bestehenden Vergebührungssteuereinheiten – besonders wenn die Angabe des Betreibernetzes in einer Form gegeben wird, ähnlich jener, in welcher die Vergebührungssteuereinheit normalerweise arbeiten würde. Wenn, zum Beispiel, die Angabe des Betreibernetzes normalerweise eine Vorwahl der B-Nummer ist, dann kann die Angabe des Betreibernetzes die B-Nummer mit Vorwahl versehen, wenn sie durch die Formatierung an die Vergebührungssteuereinheit gesendet wird. Andere Formate einer Teilnehmer-ID sind geeignet zur Verwendung auf eine ähnliche Weise. Wenn zum Beispiel die Angabe des Betreibernetzes normalerweise eine Nachwahl der B-Nummer ist, dann kann die Angabe des Betreibernetzes die B-Nummer mit Nachwahl versehen, wenn sie durch die Formatierung an die Vergebührungssteuereinheit gesendet wird. Oder, wenn die Angabe des Betreibernetzes normalerweise durch ein Flag in der B-Nummer angegeben wird, dann kann die Angabe des Betreibernetzes durch ein Flag in der B-Nummer angegeben werden, wenn sie durch die Formatierung an die Vergebührungssteuereinheit gesendet wird.
Da geringe, oder keine, Modifikation an bestehenden SCFs/SCPs notwendig ist, um die vorliegende Erfindung zu implementieren, ist sie besonders geeignet für ein Funktionieren in einer Multi-Vendor-Umgebung.
Die Formatierung 10 kann als eine Rufnummernportabilitätsdatenbank (NPDB) bezeichnet werden, insbesondere eine pre-SCP NPDB oder eine pre-gsmSCF NPDB.
Die Formatierung muss wissen, auf welche Vergebührungssteuereinheit sie zugreifen sollte, um den Tarif zu bestimmen. Eine gegebene Formatierung könnte immer auf dieselbe Vergebührungssteuereinheit zugreifen. Alternativ besteht eine Art für sie, zu bestimmen, welche Vergebührungssteuereinheit zu verwenden ist, in Analyse des Service Keys: Das MSC (oder Ähnliches), welches die Nachricht in Schritt 21 an die Formatierung sendet, könnte den Service Key auf solche Weise ändern, dass er die Vergebührungssteuereinheit anzeigt, welche zu verwenden ist. Alternativ könnte sie aus dem Service Key unter Verwendung von GT-Translationen gebildet werden. 7 zeigt das Signalisieren zwischen einem MSC 60 (welches an die Stelle des SSP in 3 treten könnte), einer Formatierung 61 (welche integriert sein könnte in oder eng verbunden mit einem SRRi) und einer Vergebührungssteuerfunktion 62 (welche ein SCP oder eine SCF sein könnte), um GT-Translationen auf diese Weise zu verwenden.

Das Signalisieren in 7A ist wie folgt.

Schritt 63:	GT-Analyse an dem VMSC/GMSC bestimmt die
	Adresse des SRRi.
Schritt 64:	Das VMSC/GMSC sendet an das SSRi eine IDP-
	Nachricht, welche die A-Nummer, die B-
	Nummer und einen Service Key umfasst, unter
	Angabe eines Tarifs in einem Intelligenten
	Netz. Die Signalisierungsparameter sind:
	CgPA: RI = GT, SSN, GT = MSC_GT
	CdPA: RI = GT, SSN, GT = SCP_GT
	OPC = MSC PC, DPC = SRRi
Schritt 65:	Das SCCP führt eine GT-Analyse aus, und das
	Ergebnis ist das Subsystem der Applikation
	des SRRi. Die Applikation des SRRi ändert
	den Translationstyp (TT) für die
	Signalisierungssitzung. Das SCCP führt eine
	weitere GT-Analyse aus, und das Ergebnis
	ist der SCP. Das SCCP ändert den Wert des
	TT wieder auf seinen ursprünglichen Wert,
	bevor die IDP-Nachricht an den SCP
	weitergeleitet wird.
Schritt 66:	Das SSRi sendet an den SCP eine IDP-
	Nachricht, welche die A-Nummer, die B-
	Nummer, mit der vorgestellten
	Betreibervorwahl, und den Service Key
	umfasst, für den Tarif in einem

	Intelligenten Netz. Die
	Signalisierungsparameter sind:
	CgPA: RI = GT, SSN, GT = MSC_GT
	CdPA: RI = GT, SSN, GT = SCP_GT
	OPC = SRRi PC, DPC = SCP PC
Schritt 67:	Entweder ändert der SCP seine reale Adresse
	in die origGT-Adresse, oder der
	Routingindikator wird geändert in DPC +
	SSN.
Schritt 68:	Der SCP signalisiert die Tarifinformation
	an das VMSC/GMSC. Abhängig von der in
Schritt 67:	durchgeführten Aktion sind die
	Signalisierungsparameter entweder:
	Continue ()
	CgPA: RI = GT, SSN, GT = real_SCP_GT
	CdPA: RI = GT, SSN, GT = MSC_GT
	OPC = SCP PC, DPC = MSC PC
	oder:
	Continue()
	CgPA: RI = DPC + SSN, GT = SCP_GT
	CdPA: RI = GT, SSN, GT, = MSC_GT
	OPC = SCP PC, DPC = MSC PC
Schritt 69:	Der Dialog zwischen VMSC und SCP kann ohne
	die Intervention des SRRi angeordnet sein,
	wenn nötig.

7B zeigt ein alternatives Verfahren. Das Signalisieren in 7B ist wie folgt.

Schritt 70:	GT-Analyse an dem VMSC/GMSC bestimmt die
	Adresse des SRRi.

Schritt 71:	Das VMSC/GMSC sendet an das SSRi eine IDP-
	Nachricht, welche die A-Nummer, die B-
	Nummer und einen Service Key umfasst, unter
	Angabe eines Tarifs in einem Intelligenten
	Netz. Die Signalisierungsparameter sind:
	CgPA: RI = GT, SSN, GT = MSC_GT
	CdPA: RI = GT, SSN, GT = xx + SCP_GT
	OPC = MSC PC, DPC = SRRi
Schritt 72:	Das SCCP führt GT-Analyse aus, für xx +
	SCP, und das Ergebnis ist das Subsystem der
	Applikation des SRRi. In der Analyse wird
	die Vorwahl xx entfernt. Verarbeitung auf
	der Applikationsebene bestimmt die
	Betreibervorwahl auf der Basis der B-Nummer
	und fügt sie vor der B-Nummer an, für die
	Nachricht in Schritt 73. Das SCCP führt
	eine weitere GT-Analyse aus, und das
	Ergebnis ist danach: DOP = SCP_PC, GT =
	SCP GT. Danach wird die Nachricht in
	Schritt 73 an den SCP gesendet.
Schritt 73:	Das SSRi sendet an den SCP eine IDP-
	Nachricht, welche die A-Nummer, die B-
	Nummer, mit vorgestellter Betreibervorwahl,
	und den Service Key umfasst, für den Tarif
	in einem Intelligenten Netz. Die
	Signalisierungsparameter sind:
	CgPA: RI = GT, SSN, GT = MSC_GT
	CdPA: RI = GT, SSN, GT = SCP_GT
	OPC = SRRi PC, DPC = SCP PC
Schritt 74:	In diesem Fall braucht der SCP seine GT-
	Adresse nicht zu ändern. Nachfolgende
	Nachrichten können direkt zum SCP geroutet

	werden, mit GT = SCP_GT, ohne Intervention
	vonseiten des SRRi.
Schritt 75:	Der SCP signalisiert die Tarifinformation
	an das VMSC/GMSC. Die
	Signalisierungsparameter sind:
	Continue()
	CgPA: RI = GT, SSN, GT = SCP_GT
	CdPA: RI = GT, SSN, GT = MSC_GT
	OPC = SCP_PC, DPC = MSC_PC
Schritt 76:	Der Dialog zwischen VMSC und SCP kann ohne
	die Intervention des SRRi angeordnet sein,
	wenn nötig.

Zusätzlich zum Bestimmen von Tarifen, wie oben beschrieben, könnte die Funktionalität der Formatierung 10 anderen Zwecken dienen. Zum Beispiel könnte, mit Kenntnis des Netzes des B-Teilnehmers, in einer einfachen Form, mittels Betreibervorwahl, ein Netz Routings für eine Verbindung bestimmen, oder es könnte ein oder mehrere Dienstgüteziele setzen, zum Beispiel um Vereinbarungen zwischen Betreibern nachzukommen.
Der Anmelder offenbart hiermit, in isolierter Form, jedes einzelne Merkmal, welches in dieser Schrift beschrieben ist, sowie jegliche Kombination zweier oder mehrerer derartiger Merkmale, in einem Umfang, dass derartige Merkmale oder Kombinationen ausgeführt werden können, beruhend auf der vorliegenden Spezifikation im Ganzen, im Lichte der in Fachkreisen üblichen, allgemeinen Kenntnisse, ungeachtet dessen, ob derartige Merkmale oder Merkmalkombinationen wie auch immer geartete Probleme lösen, wie in dieser Schrift offenbart. Der Anmelder weist darauf hin, dass Aspekte der vorliegenden Erfindung aus jeglichem derartigen einzelnen Merkmal oder aus jeglicher derartigen Merkmalkombination bestehen können. Angesichts der vorstehenden Beschreibung wird es in Fachkreisen klar sein, dass verschiedene Modifikationen innerhalb des Schutzbereichs der Erfindung vorgenommen werden können.

Claims

Verfahren zum Bestimmen eines Tarifs, anzuwenden auf eine Verbindung in einem Kommunikationssystem, mittels dessen Verbindungen hergestellt werden können, zu Endgeräten, welche einem beliebigen von mehreren Betreibern zugeordnet sind, wobei jedes Endgerät mittels einer Teilnehmerkennung adressierbar ist, welche formatiert ist, ein erstes Feld und ein zweites Feld zu enthalten, wobei das erste Feld, für wenigstens einige der Teilnehmerkennungen, den Betreiber angibt, welchem eine jeweilige Teilnehmerkennung zugeordnet ist, wobei das Verfahren umfasst: Senden, an eine Betreiberbestimmungsfunktion des Netzes, einer ersten Nachricht, welche einen Tarif für eine Verbindung anfordert und ein Teilnehmerkennungsfeld enthält, welches eine Angabe der Teilnehmerkennung des zu rufenden Endgeräts der Verbindung umfasst; Empfangen der ersten Nachricht in der Betreiberbestimmungsfunktion; Bestimmen, mittels der Betreiberbestimmungsfunktion, des Betreibers, welchem die Teilnehmerkennung des zu rufenden Endgeräts der Verbindung zugewiesen ist, und von Inhalt des ersten Felds, der diesem Betreiber zugeordnet ist; gekennzeichnet durch die Schritte: Bilden, in der Betreiberbestimmungsfunktion, einer modifizierten Teilnehmerkennung, welche, als ihr zweites Feld, wenigstens den Inhalt des zweiten Felds der Teilnehmerkennung des zu rufenden Endgeräts der Verbindung aufweist, und welche, als ihr erstes Feld, den Inhalt des ersten Felds, welcher diesem Betreiber zugeordnet ist, aufweist; Bilden, in der Betreiberbestimmungsfunktion, einer zweiten Nachricht, welche einen Tarif für eine Verbindung anfordert und ein Teilnehmerkennungsfeld enthält, welches die modifizierte Teilnehmerkennung umfasst; und Senden der zweiten Nachricht an eine Tarifbestimmungsfunktion, welche angeordnet ist, eine Teilnehmerkennung zu analysieren, welche in einer Nachricht empfangen wird, welche einen Tarif für eine Verbindung anfordert, um einen Tarif zu bestimmen, auf Basis des ersten Felds der empfangenen Teilnehmerkennung.
Verfahren nach Anspruch 1, umfassend: Senden, gemeinsam mit der Angabe der Teilnehmerkennung des zu rufenden Endgeräts der Verbindung, einer Angabe der Art der Verbindung; Bilden der zweiten Nachricht derart, dass sie die Angabe der Art der Verbindung enthält; und wobei die Tarifbestimmungsfunktion angeordnet ist, den Tarif, auf Basis des ersten Felds der empfangenen Teilnehmerkennung und der Angabe der Art der Verbindung, zu bestimmen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Betreiberbestimmungsfunktion Zugriff hat auf eine erste Datenbank, die eine Liste von Teilnehmerkennungen speichert, und für jede einzelne eine Angabe des Betreibers, welchem die jeweilige Teilnehmerkennung zugeordnet ist, und wobei der Schritt des Bestimmens Nachschlagen der Teilnehmerkennung des zu rufenden Endgeräts der Verbindung in der ersten Datenbank umfasst, und Beziehen einer beliebigen Angabe eines Betreibers, welcher derselben in der ersten Datenbank zugeordnet ist.
Verfahren nach Anspruch 3, wobei die Angabe eines Betreibers der Inhalt des ersten Felds ist, der diesem Betreiber zugeordnet ist.
Verfahren nach Anspruch 3, wobei die Betreiberbestimmungsfunktion Zugriff hat auf eine zweite Datenbank, die eine Liste von Indikatoren für Betreiber und für jeden einzelnen Inhalt des ersten Felds, der diesem Betreiber zugeordnet ist, speichert, und der Schritt des Bestimmens Nachschlagen der Angabe eines Betreibers in der zweiten Datenbank umfasst, und Beziehen von Inhalt aus dem ersten Feld, welcher demselben zugeordnet ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Teilnehmerkennungsfeld der Nachricht, welche einen Tarif für eine Verbindung anfordert, das erste Feld der Teilnehmerkennung des zu rufenden Endgeräts der Verbindung nicht enthält.
Verfahren nach einem der vorhergehenden Ansprüche, wobei, wenn, in dem Schritt des Bestimmens, bestimmt wird, dass der Inhalt des ersten Felds der Teilnehmerkennung des Endgeräts dem Betreiber zugeordnet ist, welchem diese Teilnehmerkennung zugewiesen ist, die zweite Nachricht, welche einen Tarif für eine Verbindung anfordert, gebildet wird, wobei ihr Teilnehmerkennungsfeld die Teilnehmerkennung unmodifiziert umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Nachrichten Initial Detection Point-IDP-Nachrichten sind.
Verfahren nach einem der Ansprüche 1 bis 7, wobei die Nachrichten Session Initiation Protocol-SIP-INVITE-Nachrichten sind.
Verfahren nach einem der vorhergehenden Ansprüche, wobei jede Teilnehmerkennung eine Telefonnummer ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei jedes erste Feld eine Betreibervorwahl ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Tarifbestimmungsfunktion einen oder mehrere Service Control Points SCP eines Intelligenten Netzes IN und eine Service Control Function SCF umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei jede Nachricht, welche einen Tarif für eine Verbindung anfordert, ein Quellenfeld umfasst, zum Angeben der Quelle der Nachricht, das Quellenfeld der ersten Nachricht eine Angabe der Quelle der ersten Nachricht umfasst, und das Quellenfeld der zweiten Nachricht eine Angabe der Quelle der ersten Nachricht umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, umfassend: die Tarifbestimmungsfunktion, welche einen Tarif für die Verbindung bestimmt; und Anwenden des Tarifs auf die Verbindung.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Verbindung eine Verbindung für Datentransfer ist.
Betreiberbestimmungsfunktion zur Verwendung beim Bestimmen eines Tarifs, anzuwenden auf eine Verbindung in einem Kommunikationssystem, mittels dessen Verbindungen hergestellt werden können, zu Endgeräten, welche einem beliebigen von mehreren Betreibern zugeordnet sind, wobei jedes Endgerät mittels einer Teilnehmerkennung adressierbar ist, welche formatiert ist, ein erstes Feld und ein zweites Feld zu enthalten, wobei das erste Feld, für wenigstens einige der Teilnehmerkennungen, den Betreiber angibt, welchem eine jeweilige Teilnehmerkennung zugeordnet ist, wobei die Betreiberbestimmungsfunktion umfasst: eine Betreiberbestimmungseinheit, welche anspricht auf Empfangen einer ersten Nachricht, welche eine Angabe der Teilnehmerkennung des zu rufenden Endgeräts der Verbindung enthält, um den Betreiber zu bestimmen, welchem die Teilnehmerkennung des zu rufenden Endgeräts der Verbindung zugewiesen ist, und Inhalt des ersten Felds, der diesem Betreiber zugeordnet ist; dadurch gekennzeichnet, dass die Betreiberbestimmungsfunktion ferner umfasst: eine Kennungsmodifizierung, angeordnet, den Inhalt zu empfangen und eine modifizierte Teilnehmerkennung zu bilden, welche, als ihr zweites Feld, wenigstens den Inhalt des zweiten Felds der Teilnehmerkennung des zu rufenden Endgeräts der Verbindung aufweist, und welche, als ihr erstes Feld, den Inhalt des ersten Felds, der diesem Betreiber zugeordnet ist, aufweist; eine Nachrichtenbildung, angeordnet, die modifizierte Teilnehmerkennung zu empfangen und eine zweite Nachricht zu bilden, welche einen Tarif für eine Verbindung anfordert und ein Teilnehmerkennungsfeld enthält, welches die modifizierte Teilnehmerkennung umfasst; und eine Nachrichtenübertragung zum Senden der zweiten Nachricht an eine Tarifbestimmungsfunktion, welche angeordnet ist, eine Teilnehmerkennung zu analysieren, welche in einer Nachricht empfangen wird, welche einen Tarif für eine Verbindung anfordert, um einen Tarif zu bestimmen, auf Basis des ersten Felds der empfangenen Teilnehmerkennung.