-
Hintergrund
der Erfindung
-
Die
Erfindung betrifft eine Portabilität von Teilnehmerkennungen,
wenn ein Teilnehmer Betreiber ändert.
-
Um
ein konkretes Beispiel zu geben wird die Erfindung in einer Situation
dargestellt, in der eine Telefonnummer eines Teilnehmers in der
Form E.164 ist.
-
Eine
weitere mögliche
Form ist E.212. Sogenannte ENUM-DNS-Namenserver sind auf dem Gebiet bekannt,
wobei "ENUM" eine Abkürzung ist,
die eine Nummer in der Form E.164 oder E.212 bezeichnet, und DNS
ein Domänennamenserver
ist. Die wichtigsten Abkürzungen
sind an dem Ende der Beschreibung aufgelistet.
-
Enum-DNS-Namenserver
werden verwendet, um E.164/212-Nummern auf Namen in der Form SIP oder
FQDN abzubilden. Behörden,
die Telekommunikationsnetze überwachen,
können
eine Portabilität
von Teilnehmerkennungen (Nummern usw.) fordern, um einen Wettbewerb
zwischen Betreibern auf eine derartige Weise zu ermöglichen,
daß Teilnehmer
ihre festgelegten Telefonnummern behalten können. Wichtige Umgebungen,
in denen die Erfindung verwendet werden könnte, beinhalten die MMS-(Multimedia
Messaging)-Umgebung des 3GPP, einen anderen Betrieb, der sich auf
ein Leiten einer Teilnehmerkennung innerhalb der 3GPP-Architektur
und einem Kernnetz zwischen mobilen Teilnehmern. d.h. einem Verbindungsnetz,
zum Beispiel GRX (GPRS Roaming eXchange), bezieht.
-
Die
Druckschrift EP-A-0 915 626 offenbart ein Verfahren und eine Vorrichtung
zum Abbilden einer Benutzerkennung und einer IP-Adresse zum Vorsehen
eines Dienstes in einem Datennetz. Jedoch betrifft diese Druckschrift
nicht das Problem einer Portabilität einer Kennung.
-
Das
Problem hinter der Erfindung ist wie folgt. Es wird angenommen,
daß, der
Teilnehmer X ursprünglich
ein Kunde des Betreibers A gewesen ist und seine Telefonnummer (MSISDN)
aus dem Nummernraum des Betreibers A erhalten hat. Später wechselt
der Teilnehmer X die Betreiber und wird Kunde des Betreibers B, wünscht jedoch
die ursprüngliche
Telefonnummer zu behalten. Nun leitet jedoch die Enum-DNS DNS-Abfragen
von X in Übereinstimmung
mit dem Präfix
der E.164-Nummer zu dem Namenserver des Betreibers A (unter der
Annahme, daß irgendeine
Art von Hierarchie in dem DNS verwendet wird, obgleich X der Kunde
des Betreibers B ist. Der Betreiber A sollte imstande sein, den
Namenserver, der das Endgerät
von X bedient, anzuweisen, mit dem Enum-DNS-Server des Betreibers
B zu kommunizieren.
-
Anders
ausgedrückt
ist das Problem hinter der Erfindung, wie die Enum-DNS-Abfragen zu dem
richtigen Betreiber zu leiten sind, obgleich der Teilnehmer Betreiber
gewechselt hat und seine Telefonnummer unverändert geblieben ist.
-
Kurze Beschreibung
der Erfindung
-
Eine
Aufgabe der Erfindung besteht daher darin, ein Verfahren zum Abbilden
der Teilnehmerkennung, die sich auf einen Teilnehmer bezieht, von
einer ersten Form (z.B. E.164/212) auf eine zweite Form (SIP, HTTP, E-Mail,
URL, NAI, FQDN usw.) zu schaffen, wenn die Teilnehmerkennung in
der ersten Form von dem Kennungsraum eines ersten Netzes zugewiesen
worden ist, der Teilnehmer ein Teilnehmer eines zweiten Netzes ist
und in einem dritten Netz wandert. Jedes Netz weist mindestens einen
Namenserver auf und die Netze der Betreiber sind durch ein Kernnetz
verbunden, das einen Rootserver aufweist.
-
Die
Aufgabe der Erfindung wird mit einem Verfahren und einem System
gelöst,
die dadurch gekennzeichnet sind, was in den unabhängigen Ansprüchen angegeben
ist. Bevorzugte Ausführungsbeispiele
sind in den abhängigen
Ansprüchen
beschrieben.
-
Die
Erfindung kann zum Beispiel auf die folgende Weise realisiert werden.
Der Namenserver des dritten Netzes, d.h. des besuchten Netzes, empfängt eine
Anfrage, die eine zweite Form einer Teilnehmerkennung betrifft,
die die erste Form der Teilnehmerkennung enthält oder diese ausdrückt. Der
Namenserver des dritten Netzes sendet die Anfrage, die die zweite
Form der Teilnehmerkennung betrifft, zu dem Rootserver. Der Rootserver
leitet den Namenserver des ersten Netzes aus der ersten Form der
Teilnehmerkennung ab und startet ein Verfahren, welches dazu führt, daß die Abfrage,
die die zweite Form der Teilnehmerkennung betrifft, zu dem Namenserver
des ersten Netzes gesendet wird. Der Namenserver des ersten Netzes
startet ein Verfahren, welches dazu führt, daß mindestens die Domänenadresse
des zweiten Netzes zu dem Namenserver des dritten Netzes gesendet
wird. Der Namenserver des dritten Netzes sendet eine Abfrage zu
dem Namenserver des zweiten Netzes auf der Grundlage der Domänenadresse
des zweiten Netzes und empfängt
eine Teilnehmeridentität
der zweiten Form von dem Namenserver des zweiten Netzes.
-
In
dem vorhergehenden Beispiel ist die Abfrage von dem Namenserver
des Netzes gestartet worden, das besucht worden ist, jedoch kann
sie ebenso von einer anderen Art eines Servers in dem besuchten
Netz gesendet werden.
-
Der
Ausdruck "Y startet
ein Verfahren, welches dazu führt,
daß – zu W gesendet
wird", der zuvor
zweimal verwendet worden ist, kann am einfachsten bedeuten, "Y sendet – zu W", jedoch können die
zu sendenden Daten ebenso indirekt zum Beispiel durch das Kernnetz
oder als ein Ergebnis einer rekursiven Anfrage gesendet werden,
wodurch Y eine Anfrage zu dem ersten Namenserver sendet, welcher
die Anfrage zu dem nächsten
Namenserver sendet, und der Namenserver, der auf die Anfrage antworten
kann, antwortet zu Y.
-
Die
Erfindung ermöglicht
ein Enum-DNS-basiertes Auflösen
von Teilnehmerkennungen, wie zum Beispiel E.164-Nummern, ohne zentralisierte
Datenlager oder Änderungen
der DNS-Daten sonstwo. Es gibt keine Notwendigkeit, irgendwelche Änderungen
in dem Kernnetz zwischen den Betreibern oder in dem Rootserver durchzuführen. Funktionale Änderungen
beschränken
sich auf die eigenen Namenserver der Betreiber, die imstande sein
müssen,
die Funktionalität
gemäß der Erfindung
in einer Situation zu unterstützen,
in der der Teilnehmer die Betreiber gewechselt hat. Die Teilnehmerdaten
müssen
natürlich
in den Datenbanken des neuen und alten Betreibers des Teilnehmers
aktualisiert werden. Allgemein gesprochen ermöglicht die Erfindung eine Nummernportabilität in den
MMS- und UMTS-Umgebungen, die einen Namendienst des Enum-DNS-Typs
verwenden.
-
KURZE BESCHREIBUNG
DER FIGUREN
-
Die
Erfindung wird nun detaillierter in Verbindung mit bevorzugten Ausführungsbeispielen
unter Bezugnahme auf die beiliegende Zeichnung beschreiben, in welcher
-
1 eine
System- und Signalisierungsdarstellung zeigt, das ein Ausführungsbeispiel
der vorliegenden Erfindung darstellt; und
-
2 eine
Signalisierungsdarstellung zeigt, das zusätzlich zu den Namenservern
ebenso zwei SIP-Server aufweist.
-
DETAILLIERTE
BESCHREIBUNG DER ERFINDUNG
-
Im
Folgenden werden Ausführungsbeispiele
der Erfindung unter Bezugnahme auf Protokolle und Verfahren erläutert, die
als Beispiele in den folgenden Druckschriften beschrieben sind:
- – Enum-DNS
(RFC2916)
- – NAPTR
DNS Resource Code (RR) (RFC2915)
- – SRV
Resource Code (RFC2782)
-
Gemäß einem
bevorzugten Ausführungsbeispiel
der Erfindung sind zwei neue Spezifikationssymbole "Dienstspezifikationen" und eine Spezifikation "Protokoll" für den NAPTR
definiert worden. Es ist anzumerken, daß die NAPTR-Beispiele, die
nachstehend dargestellt werden, lediglich veranschaulichend, anders
ausgedrückt
keine beschränkenden
Beispiele sind, da die Namen der Spezifikationssymbole und Spezifikationen
geändert
werden können,
wenn sich die Standardisierung ändert.
-
NAPTR-Protokoll (Naming
Authority Pointer)
-
- – ns:
Namenserver-DNS gibt einen eindeutigen Domänennamen zurück, welcher über Namenserver
abgefragt werden sollte, die für
die besondere Domäne
verantwortlich sind.
-
NAPTR-Dienstspezifikationen
-
- – E2R:
E.164 to Resource-DNS gibt einen Namen in der SRV-Form zurück, wobei
dieser Name über
Namenserver abgefragt werden kann, die für die E.164-Nummer verantwortlich sind.
- – E2D:
E.164 to Domain-DNS gibt einen eindeutigen Domänennamen zurück, welcher über Namenserver abgefragt
werden kann, die für
die E.164-Nummer verantwortlich sind.
-
NAPTR-Beispiele
-
Das
erste Beispiel ist aus der APTR-RR, welche E2R verwendet:
-
-
Wenn
er über
Daten für
die Nummer +358401234567 abgefragt wird, gibt der DNS einen Namen
der Form SRV RR zurück,
mittels welchem der abfragende Namenserver eine neue DNS-Abfrage
der SRV-Form zu dem richtigen (derzeitigen) Betreiber des Benutzers
und eine Abfrage über
die Namenserver des besonderen Betreibers durchführen kann. Es wird hier angenommen,
daß das
SRV RR des DNS ebenso das "ns"-Protokollspezifikationssymbol
versteht.
-
Das
zweite Beispiel ist aus der NAPTR RR, welche den Dienst E2D verwendet.
-
-
Wenn
er über
Daten für
die Nummer +358401234567 abgefragt wird, gibt der DNS einen Namen
zurück,
mittels welchem der abfragende Namenserver eine neue DNS-Abfrage
zu dem richtigen (derzeitigen) Betreiber des Benutzers und eine
Abfrage über
die Namenserver des besonderen Betreibers durchführen kann. Es wird hier angenommen,
daß das "ns"-Protokollspezifikationssymbol
bekannt ist und von dem DNS verwendet werden kann.
-
Ebenso
können
andere Mittel als DNS-Abfragen zwischen Betrieben für lokale
Nummerübertragungen verwendet
werden. Das Folgende ist ein Beispiel eines Verwendens des LDAP.
Verglichen mit einer DNS-Abfrage ist der LDAP eine niedrigere Wertigkeit
gegeben worden, jedoch kann ein lokaler Namenserver an gewiesen werden,
eine Wertigkeit zu dem LDAP und nicht zu dem DNS zu geben. Zum Beispiel:
-
-
Der
DNS gibt die LDAP-Adresse zurück
und eine neue Abfrage kann zu der Adresse durchgeführt werden,
um die Nummer aufzulösen.
-
1 zeigt
ein konkretes Beispiel eines Auflösens der E.164-Nummer und der
Portabilität
der Nummer in Verbindung mit einem Wandern (Roaming). 1 zeigt
eine Reihe von Ereignissen, bei welchen der Teilnehmer X (dessen
MSISDN-Nummer) +358401234567 ist) ursprünglich ein Kunde des Betreibers
A (Domäne
= a.com) ist, so daß X
eine Telefonnummer hat, die von dem Nummernraum des Betreibers A
zugewiesen worden ist. Der Teilnehmer X ist ein Kunde des Betreibers
B (Domäne
= b.com) geworden, jedoch ist die Telefonnummer immer noch aus dem
Nummernraum, der dem Betreiber A gehört. In dem Fall in 1 wandert
der Teilnehmer X in dem Netz des Betreibers C (Domäne = c.com).
-
In
einem Schritt 1-1 versucht der Namenserver DNS-C des Betreibers
C, die SIP-URL des Teilnehmers X mit einer Enum-Abfrage aufzulösen, wobei
die SIP-URL als
eine E.164-Nummer ausgedrückt
wird. Da der DNS-C die Nummer des Teilnehmers C nicht kennt, leitet
er die Abfrage zu dem Rootserver DNS-R des Verbindungsnetzes GRX.
(Technisch findet dies auf die gleiche Weise wie das Leiten der
Abfrage zu einem herkömmlichen
Namenserver statt.) Der Rootserver DNS-R erkennt, daß die Nummer
von X zu dem Betreiber A gehört,
auf der Grundlage des Präfix
der E.164-Nummer. Anders ausgedrückt
ist die Nummer von dem Nummernraum des Betreibers A zugewiesen worden. 1 ist
in dem Sinn vereinfacht, daß es
in der Realität
kontinentspezifische, länderspezifische
und betreiberspezifische Hierarchiestufen zwischen dem Rootserver
und dem Server des Betreibers geben kann, wobei aufgrund dessen
die Hierarchie der Namenserver komplizierter sein kann als das,
was in 1 gezeigt ist. 1 ist jedoch
ausreichend, um die grundlegende Funktionsweise der Erfindung darzustellen.
-
In
einem Schritt 1-2 leitet der Rootserver DNS-R die DNS-Abfrage
zu dem ursprünglichen
Betreiber A des Teilnehmers X, da die Telefonnummer von X zu dem
Nummernraum des Betreibers A gehört.
In einem Schritt 1-3 stellt der Namenserver DNS-A des Betreibers
A aus der NAPTR RR (siehe die vorhergehenden Beispiele der NAPTR)
fest, daß X
nicht länger
Kunde von A ist, sondern der Namensdienst von X von einem anderen
Betreiber erledigt wird. Der NAPTR gibt entweder
- a._ns.b.com,
wodurch als nächstes
eine SRV-Namenabfrage zu b.com (flag == "s")
durchgeführt
wird, oder
- b. b.com zurück,
wodurch als nächstes
eine Namensabfrage über
Namenserver zu b.com (flag == "p") durchgeführt wird.
-
In
einem Schritt 1-4 gibt der Rootserver DNS-R, wenn in Verbindung
mit der DNS-Abfrage keine Rekursion zugelassen wird, die Anfragen,
die in Schritt 3 empfangen werden, zu dem Namenserver DNS-C
von C zurück.
-
Die
Schritte 1-4A und 1-4B werden lediglich durchgeführt, wenn
eine Rekursion zugelassen wird. In dem Schritt 1-4A fragt
der Rootserver DNS-R den (Haupt)-Namenserver (hier DNS-B1) von B
ab, der dem Rootserver DNS-R bekannt ist. In dem Schritt 1-4B gibt
der Namenserver DNS-B1 eine Liste der Namenserver des Betreibers
B zu dem Rootserver zurück.
Danach gibt der Rootserver DNS-R in dem Schritt 1-4 eine
Antwort zu dem Namenserver DNS-C von C zurück, jedoch ist die DNS-Abfrage
in einer geringfügig
unterschiedlichen Form.
-
In
einem Schritt 1-5 sendet der DNS-C, wenn der DNS-C die
Namenserveradressen (DNS-B1 usw.) kennt, die für die E.164-Nummer des Teilnehmers
X verantwortlich sind, eine Abfrage zu einem der Namenserver von
B und empfängt
von ihm die SIP-URL, die er angefordert hat.
-
In
einem Schritt 1-5A muß der
Namenserver DNS-C von C, wenn keine Rekursion zugelassen wird, immer
noch die Namenserver von b.com auflösen. Anders ausgedrückt fragt
der DNS-C über
die Namenserver von b.com nach. Die DNS-Abfragen können erneut
durch den Rootserver DNS-R des Verbindungsnetzes GRX gesendet werden.
-
In
einem Schritt 1-5B gibt einer der Namenserver von b.com
(oder ein anderer Namenserver auf dem Pfad von C zu B, welcher den
Namenserver von B kennt) eine Liste der Namenserver von b.com zu
dem Namenserver DNS-C von C zurück.
Danach fährt
die Funktionsweise gemäß den Schritten 1-5 und 1-6 fort.
-
In
dem Schritt 1-6 löst
der Namenserver DNS-B von B die E.164-Nummer des Teilnehmers X auf
und gibt die SIP-URL oder dergleichen zurück. Danach schreiten allen
Namensabfragen direkt von C zu B ohne ein Gehen durch A fort, bis
die Namensdaten enden, die von B gespeichert werden.
-
2 zeigt
eine zweite Kette von Ereignissen, welche nicht nur Namenserver,
sondern ebenso zwei SIP-Server, das heißt einen SIPS-C in dem besuchten
Netz und einen SIPS-B in dem derzeitigen Heimatnetz des Teilnehmers,
enthalten. In einem Schritt 2-1 sendet der SIPS-C eine
Abfrage über
die SIP-URL zu dem DNS-C. In einem Schritt 2-2 gibt der
DNS-C die ns-Nachricht aus, die vorhergehend in Verbindung mit Erweiterungen
des NAPTR-Protokolls dargestellt worden ist, wobei auf der Grundlage
dieser ns-Nachricht der SIPS-C die Abfrage in einem Schritt 2-3 zu
dem Rootserver DNS-R richten kann. In einem Schritt 2-4 gibt
der DNS-R die ns-Nachricht zurück,
wobei auf der Grundlage von dieser die Abfrage in einem Schritt 2-5 zu
dem Namenserver DNS-A der ursprünglichen
Netzes A gerichtet wird. In einem Schritt 2-6 stellt der
DNS-A fest, daß der
Teilnehmer nun Kunde des Betreibers B ist, und er gibt in einem
Schritt 2-7 die Erweiterung SRV RR oder NS des NAPTR-Protokolls
zurück,
die zuvor dargestellt worden sind, wobei auf der Grundlage von diesen der
SIPS-C die Domänenadresse
des derzeitigen Betreibers des Teilnehmers kennt. Auf der Grundlage
dieser Information fragt der SIPS-C den DNS-B1 in einem Schritt 2-8 über den
entsprechenden SIPS-Server SIPS-B in dem Netz des Betreibers B ab.
In dem Schritt 2-9 gibt der DNS-B1 die IP-Adresse (oder
die SRV- oder NS-Nachricht) des SIPS-B zurück. Auf der Grundlage dieser
Information kann in einem Schritt 2-10 ein Verkehr der
Form TCP oder UDP zwischen den SIP-Servern SIPS-C und SIPS-B gestartet
werden.
-
Eine
wesentliche Idee der Erfindung besteht darin, daß der Namenserver des Betreibers,
dem die ursprüngliche
Nummer gehört
(in 1 Betreiber A), die Namensabfragen zu den Namenservern
des neuen Betreibers weitersenden kann. Es gibt keine Notwendigkeit,
irgendwelche Änderungen
in der DNS-Hierarchie selbst durchzuführen, und die Namensabfragen
finden immer ihren Weg zu dem neuen Betreiber des Teilnehmers.
-
In
der Praxis halten die Namenserver die Abfragen und ihre Ergebnisse
in dem Cache, so daß eine komplette
Abfrage, die in 1 gezeigt ist, lediglich einmal
durchgeführt
wird, worauf die nächsten
Abfragen, die die nächste
E.164-Nummer betreffen,
durch den nächsten
Namenserver beantwortet werden, bis die Namensdaten, die in dem
Cache gespeichert sind, enden (d.h. die Lebensdauer der Namensdaten
in dem Cache abläuft).
Der Ablauf der Namensdaten wird von dem Namenserver bestimmt, in
welchem die ursprünglichen Daten
gespeichert worden sind.
-
Obgleich
die Verbindungen in 2 direkt zwischen den Servern
gezogen sind, geht in der Praxis der gesamte Verkehr durch das Kernnetz.
-
Abhängig davon,
ob die Rekursion zugelassen wird oder nicht, können die Antworten der Zwischenschritte
zu den DNS-Abfragen immer zu dem Namenserver zurückgebracht werden, der die
ursprüngliche
Abfrage durchgeführt
hat. Anders ausgedrückt
empfängt
der Namenserver DNS-C des Betreibers C in 1, wenn
keine Rekursion zugelassen wird, immer eine Antwort von jedem Zwischenschritt
und führt
daher so viele neue DNS-Abfragen durch, wie erforderlich sind, um
die Namenserver von B zu finden. Wenn andererseits eine Rekursion
zugelassen wird, führt
der Betreiber C eine DNS-Abfrage durch und empfängt direkt alle Namenserveradressen
des Betreibers B als eine Antwort.
-
Die
vorhergehende Beschreibung enthält
einige Ausführungsbeispiele
der Erfindung, jedoch ist die Erfindung nicht auf diese beschränkt. Zum
Beispiel kann die erste Form der Teilnehmerkennung E.212 anstatt E.164
sein. Entsprechend kann die zweite Form der Teilnehmerkennung SIP,
FDQN, E-Mail, URL, URI, NAI oder irgendein anderer eindeutiger Domänennamen
sein. Ansonsten ist es ebenso für
einen Fachmann offensichtlich, daß dann, wenn die Technologie
fortschreitet, die grundlegende Idee der Erfindung auf mehrere Weisen
realisiert werden kann. Die Erfindung und ihre Ausführungsbeispiele
sind nicht auf die vorhergehenden Beispiele beschränkt, sondern
können
sich innerhalb des Umfangs der Ansprüche ändern.
-
Abkürzungen:
- 3GPP
- = Third Generation
Partnership Project
- ARPA
- = Address and Routing
Parameters Area
- DNS
- = Domain Name Server/Service
- Enum
- = E.164 (E.212) Number
and DNS
- FQDN
- = Fully Qualified
Domain Name
- GRX
- = GPRS Roaming Exchange
- LDAP
- = Light Directory
Access Protocol
- NAPTR
- = Naming Authority
Pointer
- SIP
- = Session Initiation
Protocol
- SRV RR
- = Service Resource
Record
- URI, URL
- = Uniform Resource
Identifier/Locator
