-
GEBIET DER
ERFINDUNG
-
Die
vorliegende Erfindung bezieht sich auf ein Verfahren und eine Vorrichtung
zur Leitwegeermittlung einer Dienstanforderung in einem Telekommunikationssystem
an einen Zielbenutzer.
-
HINTERGRUND
-
Benutzer
von Telekommunikationssystemen müssen
einer oder mehreren Kennungen zugewiesen sein. Solche Kennungen
sind dazu vorgesehen, durch weitere Benutzer verwendet zu werden,
um Kommunikationen anzufordern, und können verschiedene Formate gemäß der spezifischen
Telekommunikationstechnologie, für
welche sie festgelegt sind, annehmen.
-
Beispielsweise
werden E.164 Nummern (ITU Recommendation E.164, Mai 1997) (allgemein
bekannt als "Telefonnummern") für gewöhnlich als
Kennungen in Legacy Telekommunikationssystemen, wie beispielsweise:
PSTN (Public Switched Telephone Network), ISDN (Integrated Services
Digital Network) oder 2G (zweite Generation) Mobilsysteme, verwendet.
E.164 Nummern sind ursprünglich
dafür bestimmt,
um eine Leitwegeermittlung von Telefonrufen basierend auf ihrer
numerischen Struktur zu erlauben. So kann beispielsweise eine E.164
Nummer, wie beispielsweise "+34
91 555 XXXX", einen
Benutzer in Spanien innerhalb des Lokalbereichs von Madrid identifizieren.
-
Kennungen,
welche in modernen Telekommunikationssystemen verwendet werden,
welche beispielsweise Multimediadienste (wie beispielsweise: Videokonferenz,
Datenübertragung,
Multimedia-Meldung,
usw., als auch herkömmliche
Nursprach-Rufe) bereitstellen, müssen
mit dem URI (Uniform Resource Identifier) Format einhergehen. Für gewöhnlich unterstützen diese
modernen Systeme ebenfalls Legacy Kennungen, wie beispielsweise
E.164 Nummern, und zwar aus Gründen
der Zusammenarbeit mit Legacy Systemen, als auch um dem gleichen
Benutzer eine alte (Legacy) Kennung zugehören zu lassen. URIs sind bekannte
Kennungen, welche weit verbreitet durch eine Internet-Anwendung
und Dienste zum Identifizieren von Ressourcen (beiderseits: Abstrakt
von physikalischen Einheiten) verwendet werden. URIs sind ferner
als "Lokatoren" (Uniform Resource
Locators, URLs) oder "Namen" (Uniform Resource
Names, URNs) eingeteilt. Im Gegensatz zu URNs, welche dazu gedacht
sind, lediglich eine Ressource zu benennen (sogar wenn die Ressource
selber eingestellt ist oder unerreichbar wird), kennzeichnen URLs
eine Ressource durch ihren Ort in einem Netzwerk (d.h.: sie identifizieren
und lokalisieren diese). Aus Gründen
einer größeren Vereinfachung,
und vorausgesetzt, dass die abstrakten, konzeptionellen Differenzen
zwischen URIs und URLs winzig genug sind um sie als äquivalent zu
betrachten, wenn auf eine Folge von Zeichen Bezug genommen wird,
welche Ressourcen "identifizieren", wird im folgenden
hier der Ausdruck URL verwendet.
-
Heutzutage
sind URLs als Kennungen an eine Mehrzahl von heterogenen Ressourcen
zugewiesen, für
welche Dienstanforderungen empfangen werden können. Beispielsweise kann eine
URL dazu verwendet werden, eine Web-Seite, ein elektronisches Mail-Konto,
eine Datei herunterladbare Datei, usw., zu identifizieren. Kennungen,
welche Benutzern zugeordnet sind, welchen ein bestimmter Dienst
in einer spezifischen Netzwerk-Domäne angeboten werden, müssen URLs
sein, welche ein Format haben, welches enthält: einen Benutzernamenabschnitt
und einen Domänennamenabschnitt,
welche durch das Trennungs-Zeichen "@" getrennt
sind. Der Domänenabschnitt
identifiziert die Netzwerkdomäne,
welche einem vorgegebenen Benutzer dient, welcher benannt (und identifiziert)
ist, wie im Inhalt des Benutzernamenabschnittes in der Domäne spezifiziert.
-
Telekommunikationssysteme,
welche Multimediaprotokolle verwenden, wie beispielsweise ein H.323 Protokoll
(ITU-T Recommendation H.323, November 2000) oder ein SIP Protokoll (IETF
RFC2543 "Session Initiation
Protocol", März 1999),
verwenden URLs um ihre Benutzer zu identifizieren (unter einem weiteren
Typ von Kennungen). Somit muss ein Benutzer, welcher eine Subskription
mit einem Telekommunikationsbetreiber hat, welcher ein Telekommunikationssystem
besitzt, welches ein Multimediaprotokoll, wie beispielsweise SIP, unterstützt, einer
Kennung zugewiesen werden, welche ein URL Format hat (bekannt als
SIP-URL), welches den Benutzer in der Netzwerkdomäne des Betreibers
identifiziert, beispielsweise "sip:John.Doe@OperatorA.se". Ähnlich können für weitere
Kommunikationsdienste, wie beispielsweise die herkömmliche
Telefonie, Fax, elektronische Mail, Modembasierte Datenrufe, usw.,
eine Mehrzahl von URLs derart bestimmt werden, dass sie den Zielbenutzer
im entsprechenden Dienstpunkt gemäß dem angeforderten Dienst
erreichen (beispielsweise ein reines Telefon, der Eingangskasten
eines Mail-Kontos, ein Faxgerät
oder ein Modem); beispielsweise: "tel:+98-7-6543210", „mailto:John.Doe@OperatorA.se", "fax:+98-7-6543210", "modem:+98-7-6543210;
type=v110".
-
Ein
vorgegebener Benutzer, welcher eine Subskription mit einem Telekommunikationsbetreiber
hat, kann, in Abhängigkeit
von den Fähigkeiten
des Telekommunikationssystems des Betreibers und ebenfalls abhängig von
seinem/ihren Subskriptions-Eigenschaften,
eine Mehrzahl von Telekommunikationsdiensten oder lediglich einen
Typ von Diensten empfangen, wobei er weitere Dienste mit einem weiteren
Betreiber subskribiert hat. Beispielsweise kann ein Benutzer eine
Subskription mit Betreiber-A für
einen grundlegenden Telefondienst, Multimedia-Kommunikationsdienst und elektronischen
Mail-Dienst haben. Ebenfalls kann ein Benutzer beispielsweise eine
grundlegende Telefonie und Multimediadienste mit einem Betreiber-A
subskribiert haben, während
er eine Subskription mit einem Betreiber-B, lediglich für einen
Multimedia-Dienst, hält.
Ein Beispiel eines Telekommunikationssystems, welches dazu in der
Lage ist, eine Vielzahl von Telekommunikationsdiensten bereitzustellen
und eine verschiedenartige Art von Kennungen für Benutzer handhabt (inklusive E.164
Kennungen und URLs), ist ein 3G (dritte Generation) Mobilsystem,
welches das sogenannte IMS (Internet Protocol Multimedia Subsystem)
hat, um Multimediadienste bereitzustellen.
-
Die
E.164 Kennungen wurden weit verbreitet zur Identifizierung von Benutzern
von Telekommunikationssystemen, welche Telefoniedienste bereitstellen,
verwendet, und, wie oben erwähnt,
verwenden viele Systeme immer noch E.164 Kennungen als den einzigen
Typ von Kennung, welche ein Benutzer (anrufender Benutzer) benutzen
kann, um einen Kommunikationsdienst an einen weiteren Benutzer (Zielbenutzer)
anzufordern. Das Auftreten von neuen Telekommunikationsdiensten
sorgt dafür,
dass herkömmliche
Telefoniebetreiber einige dieser neuen Dienste ihren Benutzern anbieten.
Unter Gründen,
wie beispielsweise: um eine sanfte Migration zu einem neuen Telekommunikationsdienst
zu erlauben, welcher einen äquivalenten
alten Dienst ersetzt (beispielsweise ein Multimediadienst als Ersatz
eines herkömmlichen
sprachbasierten Telefondienstes), und um eine Unannehmlichkeit eines
Benutzers zu vermeiden, seine/ihre neue Kennung, beziehungsweise Kennungen,
für den
subskribierten neuen Dienst, beziehungsweise Dienste, zu veröffentlichen,
subskribiert ein vorgegebener Benutzer einen neuen Dienst mit seinem/ihrem
Betreiber, wobei er versucht, seine/ihre alte E.164 Kennung ebenfalls
mit dieser neuen Subskription in Zusammenhang stehen zu lassen.
Somit erlaubt es beispielsweise ein vorgegebener Betreiber, welcher
ein 2G System und ein 3G System mit IMS beisitzt, seinen Benutzern,
welche mit seinem 2G System subskribiert sind, ihre Subskription
auf sein 3G System zu migrieren, während sie ihre alten E.164
Kennungen beibehalten. Dies erlaubt es, dass diese Benutzer Dienste
von weiteren Legacy Telekommunikationssystemen empfangen, wie beispielsweise
Rufe oder SMS (Short Messages), welche ursprünglich unter Verwendung von
E.164 Kennungen adressiert sind.
-
Wenn
eine Dienstanforderung an ihren Zielbenutzer geleitet wird, welcher
ein E.164 als Kennung für diesen
Benutzer enthält,
kann bei einigen Telekommunikationssystemen (oder bei einigen Teilen
des Systems, durch welche ein bestimmtes Protokoll zur Signalisierung
des Dienstes verwendet wird) die E.164 Kennung zur Leitwegermittlung
und/oder zu Identifikationszwecken als ungeeignet herausgestellt
werden. Ebenfalls kann es bei einem vorgegebenen Punkt der Ausführung von
einer Dienstanforderung wünschenswert
sein, einen Dienstpunkt (beispielsweise ein vorgegebenes Endgerät des Zielbenutzers)
auszuwählen,
an welchen letztendlich der Dienst zugeführt wird, wobei er der Benutzer
ist, welcher in dem Endgerät
mit einer Kennung identifiziert ist, welche nicht die gleiche ist
wie jene, welche bei der Dienstanforderung empfangen wird.
-
LÖSUNGEN AUS
DEM STAND DER TECHNIK
-
Das
oben genannte Szenario wurde dargelegt, um Lösungen festzulegen, um die
Sammlung von Kennungen zu erlangen, welche sich auf eine vorgegebene
Kennung beziehen, welche einem Benutzer zugewiesen ist, und genauer
gesagt (die weit verbreitete Verwendung von E.164 Kennungen vorausgesetzt),
um die Sammlung von Kennungen zu erlangen, welche sich auf eine
E.164 Kennung beziehen.
-
Beispielsweise
offenbart IETF's
RFC2916 ("E.164
Nummer und DNS",
September 2000) (wobei der Ausdruck DNS für "Domänennamen
System" steht) einen
DNS basierten Dienst um eine Information zu erlangen, welche sich
auf die verschiedenen Kennungen und Servicetypen bezieht, welche
sich auf eine vorgegebenen E.164 Kennung beziehen. Der Dienst stellt
die Mehrzahl von URLs bereit, welche sich auf eine vorgegebene E.164
Kennung beziehen, und kann beispielsweise verwendet werden, wenn
eine Dienstanforderung, welche eine E.164 Kennung enthält, empfangen
wird (beispielsweise: ein Telefonruf, eine SMS, eine Multimediasitzung,
usw.).
-
Im
Folgenden wird der Ausdruck "ENUM-DNS" über die vorliegende Erfindung
hinweg dazu verwendet, um sich auf das Übersetzungsverfahren und Übersetzungssystem
zu beziehen ("Anfrageübersetzungs-Mechanismus,
DNS Datenbankstruktur, spezifische Datenstrukturen, um eine Übersetzung
von E.164 Kennungen auf URLs zu unterstützen, usw.), welche in RFC2916
und im Folgenden zusammengefasst offenbart sind (der gleiche Ausdruck
wird ebenfalls in einer weiteren Standardspezifikation verwendet,
welche über die
detaillierte Beschreibung hinweg ferner zitiert werden wird).
-
Gemäß RFC2916,
wird eine Mehrzahl von Kennungen in einer Datenbank gespeichert.
Die Datenbank ist strukturiert und zugreifbar (abfragbar) unter
Verwendung der bekannten DNS Technologie. Zu diesem Zweck, ist die
empfangene E.164 Kennung dazu angeordnet (wie im folgenden beschrieben),
um eine DNS basierte Datenbank auf eine ähnliche Weise abzufragen, wie
weitere DNS basierte Abfragen vorgenommen werden. Da die Domäne "e164.arpa" derart bestückt ist,
um die Infrastruktur in DNS Systemen zur Speicherung von E.164 Nummern
bereitzustellen, ist diese Domänen-Kennung
in der Abfrage enthalten. Beispielsweise sollte bei einer empfangenen
E.164 Kennung, wie beispielsweise:
9876543210
die nächste Abfrage,
welche an einer DNS gemacht wird, sein wie:
0.1.2.3.4.5.6.7.8.9.e164.arpa
wobei
die empfangenen Digits in der E.164 Kennung invertiert worden sind,
um eine bestehende DNS strukturierte Analysis zu erfüllen (hierarchisch
strukturiert von rechts nach links). Daraus folgend, wird eine Mehrzahl
von URLs, welche im DNS in Beziehung zu der E.164 Kennung gespeichert
sind, als ein Ergebnis der Abfrage empfangen. Jede dieser URLs kann
sich auf einen spezifischen Dienst beziehen, obwohl sich mehr als
eine auf den gleichen Dienst beziehen kann. Beispielsweise kann
die Abfrage einen Satz von Kennungen erzielen, wie beispielsweise:
| sip:John.Doe@OperatorA.se | (eine
SIP-URL) |
| tel:+98-7-6543210 | (eine
TEL-URL) |
| fax:+98-7-6543210 | (eine
FAX-URL) |
| mailto:John.Doe@OperatorA.se | (eine
MAILTO-URL) |
| sip:JohnnyDoe@OperatorB.fr | (eine
SIP-URL) |
welche im DNS als NAPTR RRs (Naming Authority
Pointer DNS Resource Records) gespeichert werden, und welche als
gültige,
weiterleitbare Kennungen zur weiteren Leitwegermittlung der Dienstanforderung,
welche die E.164 Kennung enthält,
verwendet werden können.
-
Unter
den Kennungen kann die Abfrageeinheit (beispielsweise ein Knoten
im Telekommunikationsdienst) eine aus ihnen auswählen und ferner die Dienstanforderung
gemäß derer
weiterleiten. Beispielsweise kann die geeigneteste URL zur Zuführung des
angeforderten Dienstes gemäß den angeforderten
Fähigkeiten ausgewählt werden;
so beispielsweise, wenn der angeforderte Dienst ein Sprachruf ist,
dann kann jegliche SIP-URL
zur Zuführung
dessen in ein SIP-fähiges
Endgerät
des bezüglichen
Zielbenutzers ausgewählt
werden. Alternativ kann die zweite URL (Tel:+98-7-6543210) ausgewählt werden,
wenn es gewünscht
ist, den Ruf beispielsweise an ein reines Telefon zuzuführen, welches
in einem Legacy Telefonsystem eingestellt ist. Die weitere Leitwegermittlung
des Dienstes wird von der Natur der ausgewählten URL abhängen. Somit,
beispielsweise wenn die ausgewählte
URL einen Benutzernamenabschnitt und einen Domänennamenabschnitt hat, wird
der Dienst dann primär
an die Domäne
weitergeleitet, welche durch den Domänennamenabschnitt spezifiziert
ist. Beispielsweise, wenn die ausgewählte URL die erste ist, wird
der Dienst dann an die Netzwerkdomäne des "OperatorA" in Schweden weitergeleitet.
-
Wenn
jedoch die fünfte
URL ausgewählt
wird, dann sollte der Dienst an die Netzwerkdomäne des "OperatorB" in Frankreich weitergeleitet werden.
-
Jedoch
offenbart die oben angegebene RFC2916 nicht was zu tun ist, wenn
mehr als eine Kennung empfangen wird, welche sich auf den gleichen
Diensttyp für
einen ENUM-DNS Abfrageübersetzungs-Mechanismus
bezieht (beispielsweise, wenn mehr als eine SIP-URL als Antwort
auf eine Abfrage empfangen werden, welche mit einer E.164 Kennung
vorgenommen wird), und sogar die gleichen "Order-" und "Präferenz-" Felder hat.
-
Um
diese nicht wünschenswerten
Situationen zu vermeiden, kann ein Bestimmen einer einzelnen URL pro
Dienst, welche sich auf eine E.164 Kennung bezieht, nicht durchführbar sein.
Tatsächlich
können
die Kennungen, welche innerhalb von NAPTR-RRs in DNS bezüglich von E.164 Kennungen zu
speichern sind (wie bei weiteren ähnlichen Angelegenheiten, welche
sich mit Kennungen von Telekommunikationsbenutzern beschäftigen,
wie beispielsweise eine Nummern-Übertragbarkeit),
eine nationale Regulierungs-Angelegenheit sein, welche sich von
Land zu Land unterscheidet. Somit wird beispielsweise bei einigen
Situationen der Inhalt der Ressourcen-Aufzeichnungen auf ein großes Ausmaß davon
abhängen,
was der Benutzer, welcher den E.164 Kennungen zugewiesen ist, entscheidet,
während
bei weiteren Situationen der letztendliche Inhalt durch den Betreiber
bestimmt werden soll, welcher (ursprünglich) die Subskription besitzt,
zu welcher die E.164 Kennung gehört
(d.h.: der "Heimat-Betreiber" für diese
Kennung). Dann würde
dies zu Situationen führen,
bei welchen es mehr als eine URL pro Dienst geben kann, welche sich
auf eine vorgegebene E.164 Kennung bezieht, welche in einem ENUM-DNS
gespeichert ist. Andererseits, während
die globalen Adressierungsmöglichkeiten der
E.164 Kennung, welche größtenteils
durch einen "zugewiesenen" vorgegebenen Benutzer
verwendet wird, beibehalten werden, wäre es wünschenswert, die Anzahl von
Subskriptionen zu beschränken,
welche der Benutzer auf einen vorgegebenen (neuen) Dienst (wie beispielsweise
ein Multimediadienst, welcher auf SIP basiert) mit mehr als einem
Telekommunikationsbetreiber haben kann.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Die
vorliegende Erfindung stellt ein Verfahren, eine Vorrichtung und
ein System zur Leitwegeermittlung einer Dienstanforderung in einem
Telekommunikationssystem bereit, wenn eine Mehrzahl von weiterleitbaren Kennungen,
welche sich auf eine Kennung beziehen, welche in der Dienstanforderung
empfangen wird, zur Leitwegeermittlung des Dienstes erlangt werden.
-
Gemäß einem
Aspekt der vorliegenden Erfindung ist ein Verfahren zur Leitwegeermittlung
einer Dienstanforderung bereitgestellt, welche eine spezifische
Kennung enthält,
welche mit dem Benutzer in Zusammenhang steht, welcher das Ziel
des Dienstes ist. Das Verfahren enthält einen ersten Schritt, bei
welchem eine Mehrzahl von Kennungen in Beziehung zu der spezifischen
Kennung gespeichert werden, wobei jegliche aus der Mehrzahl von
Kennungen dazu geeignet ist, um ferner Dienstanforderungen weiterzuleiten,
welche für den
Zielbenutzer empfangen werden, und welche die spezifische Kennung
enthalten, wobei zumindest eine Kennung aus der Mehrzahl von Kennungen
ein Format hat, welches einen Benutzernamenabschnitt und einen Domänennamenabschnitt
enthält,
wobei sie die spezifische Kennung ist, welche innerhalb des Benutzernamenabschnittes
enthalten ist. Bei einem weiteren Schritt werden, wenn eine Dienstanforderung
empfangen wird, welche die spezifische Kennung enthält, alle
oder ein Teil der Mehrzahl von Kennungen, welche sich auf die empfangene
spezifische Kennung beziehen, erlangt, dann, wenn eine Kennung unter
der Mehrzahl von Kennungen ein wie oben beschriebenes Format hat,
und ihr Benutzernamenabschnitt die empfangene spezifischen Kennung
enthält,
wird sie zur weiteren Leitwegeermittlung des Dienstes ausgewählt.
-
Gemäß eines
weiteren Aspektes der Erfindung ist eine Vorrichtung zur Leitwegeermittlung
einer Dienstanfrage in einem Telekommunikationssystem bereitgestellt.
Die Vorrichtung enthält:
ein Kommunikationsmittel, welches dazu angeordnet ist, eine Dienstanforderung
zu empfangen, welche eine spezifische Kennung enthält, welche
dem Benutzer zugewiesen ist, welcher das Ziel des Dienstes ist;
ein Verarbeitungsmittel, welches dazu angeordnet ist, um die Mehrzahl
von Kennungen zu erlangen, die mit der empfangen spezifischen Kennung
in Beziehung stehen, welche dazu geeignet sind, eine Dienstanforderung
weiterzuleiten, welche die spezifische Kennung enthält, und
ferner dazu angeordnet sind, eine Kennung unter der Mehrzahl von Kennungen
auszuwählen,
welche ein Format hat, welche einen Benutzernamenabschnitt und einen
Domänennamenabschnitt
enthält,
wobei der Benutzernamenabschnitt die Kennung enthält, welche
bei der Dienstanforderung empfangen wird; und ein Mittel zur Leitwegeermittlung,
welches dazu angeordnet ist, ferner die empfangene Dienstanforderung
gemäß der ausgewählten Kennung
weiterzuleiten.
-
Gemäß eines
weiteren Aspektes der Erfindung ist ein System zur Leitwegeermittlung
einer Dienstanforderung in einem Telekommunikationssystem bereitgestellt.
Das System enthält:
eine Datenbank und einen Dienstvermittlungsknoten im Telekommunikationsnetzwerk,
welcher die Aufgabe hat, eine Dienstanforderung an einen Zielbenutzer
zu empfangen, und die Dienstanforderung weiterzuleiten. Die Datenbank
speichert eine Mehrzahl von Kennungen, die mit einer spezifischen
Kennung in Beziehung stehen, die mit einem Benutzer assoziiert sind,
und sie ist ferner dazu angeordnet, eine Anfrage zu beantworten,
welche den Inhalt der spezifischen Kennung mit allen oder einem
Teil der Mehrzahl von Kennungen enthält. Der Dienstvermittlungsknoten ist
dazu angeordnet, eine Anfrage an die Datenbank zu senden, wenn er
eine Dienstanforderung empfängt, welche
die spezifische Kennung enthält,
wobei die Anfrage den Inhalt der Kennung enthält, welche in der Dienstanforderung
empfangen ist. Wenn die Antwort auf die Anfrage im Dienstvermittlungsknoten
empfangen ist, ist er dazu angeordnet, eine Kennung unter der Mehrzahl
von Kennungen, welche in der Anfrage empfangen sind, auszuwählen, welche
ein Format hat, welches einen Benutzernamenabschnitt und einen Domänennamenabschnitt
enthält,
wenn der Benutzernamenabschnitt die Kennung enthält, welche in der Dienstanforderung
empfangen ist.
-
Bei
Situationen, bei welchen zwei oder mehrere Kennungen zur Weiterleitung
einer Dienstanforderung erlangt werden, und im speziellen, wenn
sich diese Kennungen auf unterschiedliche Diensttypen und/oder unterschiedliche
Netzwerkdomänen
beziehen, erlauben es die in dieser Erfindung offenbarten Aspekte,
eine bestimmte Netzwerkdomäne
zu identifizieren, welche eine Kennung hält, welche jene enthält, welche
bei der Dienstanforderung empfangen ist, und um den Dienst daran
weiterzuleiten. Dies erlaubt weitere Entscheidungen zur Zuführung des
Dienstes, wie beispielsweise eine Änderung eines Diensttyps, eine
Auswahl des Zielendgeräts,
usw., welche in der identifizierten Netzwerkdomäne vorzunehmen sind.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
1 zeigt
eine schematische Ansicht von zwei Dienstvermittlungsknoten eines
Telekommunikationssystems und einen Signalisierungsfluss von einer
Dienstanforderung und ihre Weiterleitung gemäß der Erfindung.
-
GENAUE BESCHREIBUNG
-
Die
Erfindung wird nun detailliert mit Bezug auf 1 gemäß einer
bevorzugten Ausführungsform
beschrieben. Diese bevorzugte Ausführungsform betrachtet ein 3G
Mobilsystem, welches das sogenannte IMS (Internet Protocol Multimedia
Subsystem) und dessen standardisiertes Protokoll für Signalisierungsdienste
implementiert, als ein Beispiel eines Telekommunikationssystems,
bei welchem die Aufgaben, Merkmale und Vorteile dieser Erfindung
angewendet werden können.
3G Systeme sind durch das Standardisierungsforum 3GPP (3rd Generation Partnership Project) standardisiert,
welches das bekannte Protokoll SIP (Session Initiation Protocol)
ist, welches durch 3GPP zu Signalisierungsdiensten innerhalb des
IMS eines 3G Systems ausgewählt
ist. Wie zuvor erwähnt,
sind diese Arten von Telekommunikationssystemen (3G Systeme, welche
das Subsystem IMS haben) dazu in der Lage, eine Vielzahl von Telekommunikationsdiensten
bereitzustellen, wie beispielsweise Sprachrufe über eine schaltungsvermittelte
Technologie, Sprache oder Multimedia-Sitzungen durch eine paketvermittelte
Technologie, usw., und behandeln eine Vielzahl von Arten von Kennungen
zur Identifizierung von Benutzern, welche E.164 und URLs enthalten.
Somit, wenn Dienstanforderungen behandelt werden, können sie
der Notwendigkeit begegnen, eine vorgegebene Kennung, wie beispielsweise
eine E.164 Telefonnummer, auf eine geeignetere Kennung, wie beispielsweise
ein SIP-URL, zur Weiterleitung des Dienstes an sein letztendliches
Ziel zu übersetzen.
-
Jedoch
ist es zu verstehen, dass der Umfang der vorliegenden Erfindung
nicht auf die 3G Systeme noch auf ein spezifisches Signalisierungsprotokoll
begrenzt ist, und dass ein Fachmann sie vollständig auf irgendein Telekommunikationssystem
anwenden kann, welches eine Dienstanforderung empfängt, welche
eine vorgegebene Kennung enthält,
welche mit dem Ziel des Dienstes in Zusammenhang steht, wenn die
Kennung: nicht geeignet oder zur Weiterleitung des Dienstes nicht
gewünscht
ist, und zumindest eine aus einer Mehrzahl von weiterleitbaren Kennungen,
welche sich auf die vorgegebene Kennung beziehen, zu diesem Zwecke
zu verwenden ist.
-
Für das IMS
Subsystem eines 3G Mobilsystems hat das 3GPP Forum einen Satz von
funktionellen Servereinheiten bestimmt, welche verschiedene spezialisierte
Funktionen betreuen. Unter ihnen sind die sogenannten CSCFs (Call
State Control Functions), welche eine Dienststeuerung für Dienste
betreuen. Eine CSCF ist eine funktionale Einheit, welche einen Satz
von Funktionen durchführt,
wie beispielsweise: Kommunikationsfunktionen um mit weiteren Einheiten
zu kommunizieren, Verarbeitungsfunktionen um eine verschiedenartige
Dienstlogik durchzuführen,
welche sich auf einen Dienst bezieht, welcher darauf behandelt wird,
und Leitwegefunktionen zur Weiterleitung von Kommunikationen an
weitere Einheiten. In Abhängigkeit
von Implementierungsaspekten (nicht durch 3GPP standardisiert noch
relevant für
das Verständnis
und den Umfang der vorliegenden Erfindung), kann sich eine CSCF
innerhalb einer physikalischen Maschine (d.h. ein physikalischer
Telekommunikationsknoten) befinden oder über eine Mehrzahl von physikalischen
Maschinen verteilt sein, welche zur Durchführung ihrer Funktionen zusammenarbeiten.
Zusammengefasst, kann angenommen werden, dass eine CSCF ein Dienstvermittlungsknoten
in einem Telekommunikationssystem, wie beispielsweise eine Telefonvermittlung
in einem PSTN oder ein MSC (Mobile Switching Center) in einem 2G
Mobilsystem, ist, welche Steuerungsfunktionen für die Dienste, welche sie betreut
(d.h., Empfänge,
Weiterleitungen oder Prozesse), betreut.
-
Gemäß der 3GPP
Terminologie für
IMS Einheiten, wird eine CSCF ferner als eine P-CSCF (Proxy-CSCF),
I-CSCF (Abfrage-CSCF) oder S-CSCF (Dienst-CSCF) gemäß ihrer
Rolle benannt, während
sie eine Dienstanforderung behandelt. Somit wird eine CSCF eine
P-CSCF, wenn sie mit einem Endbenutzer-Endgerät kommuniziert, eine I-CSCF,
wenn sie der erste Dienstvermittlungsknoten innerhalb eines Betreibernetzwerkes
ist, welches Dienstanforderungen für einen Zielbenutzer empfängt, welcher
beim Betreiber angemeldet ist, und eine S-CSCF benannt, wenn sie eine Dienststeuerung
für einen
Dienst betreut, und zwar entweder: aufgebaut durch einen Benutzer
oder abgeschlossen bei einem Benutzer, welchem sie zu bedienen zugewiesen
ist.
-
Es
wird nun Bezug auf 1 genommen, um die Merkmale
der vorliegenden Erfindung in einem 3G Telekommunikationssystem
aus dem Stand der Technik, welches IMS hat und dazu angeordnet ist,
eine ENUM-DNS Datenbank abzufragen, um Kennungen zu erlangen, welche
sich auf eine vorgegebene E.164 Kennung beziehen, darzustellen.
In 1 sind zwei CSCFs gezeigt (S-CSCF, I-CSCF), wobei jede ihren eigenen
Namen (cscf.OperatorX.fr, cscf.OperatorA.se) hat, welcher dazu dient,
eine CSCF in der Netzwerkdomäne eines
vorgegebenen Betreibers ("OperatorX") in einem vorgegebenen
Land (Frankreich) darzustellen, welche als eine Dienst-CSCF für den Benutzer
(oder für
die Einheit) wirkt, welcher den Dienst aufbaut, und eine weitere
gehört
zu einem weiteren Betreiber ("OperatorA") in einem weiteren
Land (Schweden), welcher als eine Abfrage-CSCF für das Ziel des Dienstes wirkt.
Jedoch können
beide in 1 dargestellten CSCFs zum gleichen
Betreiber gehören,
was bei eindeutigen Betreibern der Fall ist, welches stärker dazu
geeignet ist, um die Vorteile der Erfindung hervorzuheben. An diesem
Punkt wird erwähnt,
dass gemäß der 3GPP
Spezifikationen für
IMS, die CSCFs mit ihren eigenen Namen angegeben sind, wie dies
beispielsweise in der 3GPP Spezifikation 24.228 (Version V5.0.0,
März 2002)
gezeigt ist, welche detaillierte Signalisierungsflüsse für Dienste
im IMS zeigt. Da die individuellen Namen (URLs) in die entsprechenden
individuellen Adressen zu zerlegen sind, welche für Adressierungsmeldungen
gemäß dem unterliegenden
Netzwerkprotokoll (beispielsweise eine Internetprotokolladresse
oder IP-Adresse) geeignet sind, indem beispielsweise DNS oder eine ähnliche
Technik verwendet wird, sollten sie für gewöhnlich einen Domänenabschnitt
enthalten, welcher den Netzwerkbereich des 3G Systembetreibers,
zu welchem sie gehören,
identifiziert. 1 zeigt ebenfalls eine ENUM-DSN
Datenbank. Sie kann einen Datenbank oder einen Satz von hierarchisch
bezogenen Datenbanken enthalten. Auf jedem Fall sind bestimmte Implementierungsdetails,
welche sich auf die Datenbank beziehen, sogar wenn sie auf DNS Technologie
basiert oder nicht, für
den Umfang der vorliegenden Erfindung nicht relevant, wobei die einzigen
relevanten Aspekte für
ihr Verständnis
darin liegen: dass die Datenbank ein Speichern von einer Sammlung
von Kennungen betreut, welche sich auf eine vorgegebene Kennung
beziehen; und dass die Datenbank dazu angeordnet ist, eine Abfrage
zu empfangen, welche die vorgegebene Kennung enthält, und
die Abfrage mit einer oder mehreren unter der Mehrzahl von Kennungen
beantwortet.
-
Schritt 1 in 1 stellt
den Empfang einer Dienstanfrage in einer CSCF (S-CSCF) dar. Der
Dienst kann beispielsweise eine Sitzung (d.h., ein Ruf, eine Multimediasitzung),
welche zu einem Zielbenutzer hin angefragt ist, welcher sich innerhalb
der Netzwerkdomäne
des Betreibers, zu welchem die CSCF gehört, befinden kann, oder innerhalb
der Netzwerkdomäne
eines weiteren Betreibers befinden kann, sein. Wie oben erwähnt, werden
Dienste innerhalb des IMS eines 3G Systems unter Verwendung eines
SIP Protokolls signalisiert. Somit kann in diesem beispielhaften
Fall eine SIP Meldung INVITE durch das Kommunikationsmittel der CSCF
empfangen werden. Das in Schritt 1 empfangene INVITE sollte
eine gültige
Kennung für
den Benutzer enthalten, welcher das Ziel dieses Dienstes ist. Gemäß dem SIP
Protokoll, nimmt die Kennung die Form einer URL an. Somit würde es,
vom Blickpunkt des SIP Protokolls aus betrachtet, keinerlei Probleme
geben, die empfange Dienstanforderung (INVITE) gemäß der URL
weiterzuleiten, welche als Ziel angezeigt ist. Die URL kann beispielsweise
eine TEL-URL (URL zur Telefonie, wie in RFC2806 "URLs für Telefonrufe", April 2000 offenbart)
oder eine SIP-URL (URL für
SIP, wie in dem zuvor genannten RFC2543 "Session Initiation Protocol" offenbart) sein.
Dies würde
es dann nicht ausschließen,
das empfangene INVITE gemäß der empfangenen URL
weiterzuleiten, welche mit dem Ziel in Zusammenhang steht, und ohne
die URL zu modifizieren. Bei einigen Fällen kann es jedoch gewünscht sein,
das Ziel der INVITE zu ändern.
Beispielsweise hat sich der Zielbenutzer in ein SIP basiertes System
von zwei Endgeräten
aus registriert und hat ein bestimmtes Zuführkriterium zum Empfangen von
Diensten spezifiziert. In diesem Fall kann beispielsweise ein spezialisierter
SIP Server die geeigneten Kennungen bereitstellen, um das INVITE
an jegliche (oder beide) dieser zwei Endgeräte weiterzuleiten.
-
Jedoch,
wie beispielsweise in der 3GPP Spezifikation 23.228 (Version V5.3.0,
Januar 2002) (als auch bei älteren
Versionen der gleichen Spezifikation) spezifiziert, sollten nicht-SIP-URLs (wie beispielsweise TEL-URLs)
nicht dazu verwendet werden, um Dienste innerhalb des IMS eines
3G Systems weiterzuleiten, und sie sind in weiterleitbare SIP-URLs
unter Verwendung von ENUM-DNS umzuwandeln. Somit, wenn beispielsweise
die URL für
das Ziel, welche im Invite von Schritt 3 empfangen ist,
eine TEL-URL ist, wie beispielsweise:
tel:+98-7-6543210
muss
sie unter Verwendung von ENUM-DNS oder jeglichem weiteren geeigneten
Mechanismus in eine weiterleitbare SIP-URL übersetzt werden. Zu diesem
Zweck würde
ein Dienstvermittlungsknoten eines Telekommunikationssystems aus
dem Stand der Technik, wie beispielsweise die CSCF (S-CSCF) des
beispielhaften Falls, in Schritt 2 eine ENUM-DNS Datenbank
abfragen. Die Abfrage würde
(wie zuvor in Verbindung mit dem Stand der Technik erwähnt) die
empfangene E.164 Kennung enthalten, welche korrekt angeordnet ist,
um eine DNS basierte Datenbank abzufragen. Gemäß dessen würde die in Schritt 3 gesendete
Abfrage enthalten:
0.1.2.3.4.5.6.7.8.9.e164.arpa
-
Die
abgefragte Datenbank kann eine Mehrzahl von Kennungen haben, welche
sich auf die Kennung "9876543210" beziehen, jedoch,
zum Zwecke der ENUM-DNS Durchsicht, sind bei dieser Art der Abfrage (E.164
auf URL) lediglich die Kennungen relevant, welche URL Format haben.
Daher würde
die ENUM-DSN Datenbank mit jenen URLs zurück antworten, welche sich in
der Datenbank auf die E.164 Kennung beziehen, welche bei der Abfrage
verwendet wird. Unter Verwendung des in 1 angezeigten
beispielhaften Falls, würde
die CSCF (S-CSCF) in Schritt 3 die nächsten URLs empfangen:
Sip:JohnnyDoe@OperatorB.fr
mailto:John.Doe@OperatorA.se
sip:9876543210@OperatorA.se
tel:+98-7-6543210
-
Bei
diesem beispielhaften Fall wird, da mehrere URLs empfangen werden,
ein Verarbeitungsmittel in der CSCF (S-CSCF), bis Gabelungsverfahren
für eine
mehrfache Dienstzuführung
implementiert werden (welches teuer und manchmal nicht wirksam ist),
in Schritt 4 eine dieser URLs auswählen und den Dienst gemäß dessen
weiterleiten. Wenn die TEL-URL (tel:+98-7-6543210) ausgewählt wird, sollte ein Telefonruf
dann an die E.164 Kennung, welche in dieser TEL-URL enthalten ist,
aufgebaut werden. Wenn diese E.164 Kennung nicht zur OperatorX Domäne gehört, dann
kann sie beispielsweise an die PSTN durch die Signalisierungs- und
Media-Gateways geleitet werden, welche das Telekommunikationssystem
von OperatorX mit einem PSTN Operator verbinden, welcher in der
Netzwerkdomäne
des Operators enden wird, welcher eine Telefon-Subskription behandelt,
welche durch diese E.164 Kennung adressiert ist. Ebenfalls kann
es den praktischen Fall geben, bei welchen alle der empfangenen
Kennungen zum gleichen Operator gehören, wie die CSCF, welche das
INVITE (OperatorX) empfangen hat. In diesem Fall kann die CSCF (S-CSCF)
mit jeglichen der Kennungen zur Heimat-Server Einheit (welche als
HSS oder HLR bekannt ist) des OperatorX abfragen, welches wiederum
die Adresse der CSCF bereitstellt, welche den entsprechenden Benutzer
bedient, welcher durch die Kennungen adressiert ist. Der Dienst
wird mit jeglichen der empfangenen SIP-URLs zu dieser CSCF weitergeleitet,
welches wiederum ein weiteres Weiterleitungs-Kriterium gemäß dessen anwenden könnte, beispielsweise
Benutzerpräferenzen
oder ein Benutzerprofil. Somit würde
es bei diesem letzten Fall die CSCF sein, welche den Benutzer bedient,
welcher entscheidet, wohin der Dienst weiterzuleiten ist.
-
Wenn
jedoch die in Schritt 3 empfangenen Kennungen nicht zum
Operator der CSCF (S-CSCF) gehören,
welche zum (OperatorX) gehört,
sind Benutzer-Präferenzdaten
und/oder Benutzerprofil-Daten
eines Zielnutzers, welcher zu einem weiteren Operator (beispielsweise
OperatorA oder OperatorB) gehört,
und welche es dieser CSCF (S-CSCF) erlaubt, eine Auswahl mit einer
bestimmten Basis durchzuführen,
weit davon entfernt, dieser CSCF von OperatorX bekannt (oder zugreifbar)
zu sein. Tatsächlich,
sogar wenn die in Schritt 3 empfangenen Kennungen zum gleichen
Operator gehören,
zu welchem die CSCF (S-CSCF) gehört,
schließen
IMS Standardisierungsprozesse in dieser Situation eine CSCF aus,
welche als eine aufbauende S-CSCF wirkt, um den HSS zu diesem Zwecke
abzufragen, und ebenfalls, wie zuvor erwähnt, schließen IMS Standardisierungsprozesse
die Weiterleitung des Dienstes mit einer weiteren Kennung als die
SIP-URL aus.
-
Darüber hinaus,
sogar in dem Fall, dass eine oder mehrere SIP-URLs von der Datenbank empfangen werden,
welche zur Domäne
von OperatorX gehört,
kann es, wenn es zumindest eine SIP-URL unter denjenigen gibt, welche
von der Datenbank empfangen werden, welche zu einem weiteren Operator
gehört,
zweifelhaft sein, die Entscheidung zu treffen, diese SIP-URL zur
Weiterleitung des Dienstes zu verwerfen. Beispielsweise werden zwei
URL als eine Antwort auf die Abfrage empfangen, welche an die Datenbank
gesendet wird, während
eine URL zum OperatorX gehört,
während
die andere zum OperatorA gehört.
Wenn der Zielteilnehmer, welchem die E.164 zugewiesen ist, ursprünglich und
immer noch eine Basis (Legacy) Telefon-Subskription mit OperatorA
hat, welcher mit der E.164 Kennung in Zusammenhang steht (beispielsweise
die Nummernfolge der E.164 Kennung, welche ursprünglich zum OperatorA gehört), und
nun ebenfalls eine Multimedia-Subskription mit dem OperatorA hat,
dann kann ein Weiterleiten des Dienstes zum OperatorA möglicherweise
die geeigneteste Entscheidung sein, insbesondere, wenn die E.164
Kennung einer Nummern-Wahrscheinlichkeit unterworfen werden kann,
und Abfragen zur Übertragbarkeit
im Nummernbereichhalter-Netzwerk vorgenommen werden. Somit sollten,
sobald der Dienst in die OperatorA Domäne eintritt, Benutzerpräferenzen
und ein Benutzerprofil, welche sich auf die Subskription des Zielbenutzers
in der Domäne
beziehen, weiterhin überprüft werden,
um die Ziel-Weiterleitung und Zuführkriterien für diesen
Dienst zu bestimmen. Jedoch können
diese (möglichen)
Tatsachen ebenfalls weit davon entfernt sein, von dieser CSCF (S-CSCF)
bekannt (oder zugreifbar) zu sein.
-
Um
die obigen Probleme zu lösen,
hat, als ein Teil des administrativen Prozesses zum Bestücken von Daten
durch ein DNS System (wie beispielsweise beim Bestücken von
Daten, welche sich auf eine Nummern-Beweglichkeit beziehen), ein
Operator, welcher beispielsweise eine Situation hat, welche ähnlich zu
der ist, welche oben für
OperatorA beschrieben, bei welcher sie eine Basis (Legacy) Telefon-Subskription
hat, welche mit einer Legacy-Kennung adressiert ist (wie beispielsweise
eine E.164 Kennung), welche zur Weiterleitung gemäß eines
neuen Diensttyps nicht geeignet ist oder nicht wünschenswert ist, und eine neue
Subskription für
einen neuen Diensttyp (wie beispielsweise Multimediadienste über SIP),
oder die gleiche Subskription beide Dienste umfasst, sollte eine
URL bestückt
werden, welche in der DNS-ENUM zu speichern ist, welches eine eindeutige
Identifizierung der Operator Domäne
erlaubt, und zwar als jene, welche primär die Legacy-Kennung hält (beispielsweise
eine E.164 Kennung).
-
In
Fällen,
bei welchen der neue Diensttyp URL Kennungen verwendet, kann dies
durchgeführt
werden, indem eine URL bestimmt wird, welche im Benutzernamen-Abschnitt
den Inhalt der Legacy Kennung hat, während der Domänennamenabschnitt
die geeignete Domänenkennung
enthält,
um somit einen weiterleitbaren FQDN (Full Qualified Domain Name)
auszubilden. Eine solche URL würde,
sobald sie gespeichert ist, beispielsweise im ENUM-DNS, zusammen
mit dem Rest der Kennungen, welche sich auf die Legacy-Kennung beziehen,
erlauben, sie von den weiteren zu unterscheiden und den Dienst gemäß dessen
weiterzuleiten. In dem bestimmten Fall einer Übersetzung von E.164 auf URL,
und genauer gesagt, im Falle einer Übersetzung von E.164 auf SIP-URL,
sollte das Format der zu bestückenden
URL die E.164 Kennung in einem unterscheidbaren Format enthalten.
Beispielsweise kann bei einer E.164, wie beispielsweise 9876543210,
welche Operator OperatorA in Schweden "besitzt", die SIP-URL ein Format haben, wie
beispielsweise:
Sip:9876543210@OperatorA.se.
-
Optional
kann der Benutzernamenabschnitt eine zusätzliche Information für verschiedene
Zwecke enthalten, wie beispielsweise eine Bekräftigung der Verwendung dieser
URL, welches ein Kennungs-Subjekt der Nummern-Beweglichkeit, usw.
anzeigt. Für
den gleichen Fall, als Beispiel verwendet, könnten vollständig unterscheidbare
Formate ebenfalls sein:
sip:9876543210.E164@OperatorA.se,
sip:non_ported_indication.9876543210@OperatorA.se,
sip:ported_indication.9876543210.ported_identifier@
OperatorC.it.
-
Gemäß der Erfindung,
wählt ein
Verarbeitungsmittel in der CSCF (S-CSCF) in Schritt 4 eine
unterscheidbare URL aus, wie oben beschrieben, welche die E.164
Kennung enthält,
welche bei der Abfrage von Schritt 2 verwendet wird, und
leitet ferner den Dienst gemäß dieser
URL weiter. Dieser Prozess kann eine weitere Abfrage (in 1 nicht
gezeigt) zu einem Übersetzungsdienst
(wie beispielsweise DNS) einbeziehen, um eine Namens- und/oder Netzwerkadresse
der entsprechenden CSCF zu erlangen, an welchen das INVITE in Schritt 5 zu
senden ist. Zusätzlich,
wenn eine Anzeige einer "nicht
unterstützten" Kennung ebenfalls
in der ausgewählten
URL empfangen wurde, kann eine weitere Abfrage, welche andererseits
durch diese CSCF (S-CSCF) oder durch einen weiteren Dienstvermittlungsknoten
angefordert werden würde,
um eine Nummern-Beweglichkeits-Information zu erlangen, vermieden
werden, indem diese Anzeige betrachtet wird. Ähnlich, wenn eine Anzeige einer "unterstützten" Kennung ebenfalls
in der ausgewählten
URL empfange wurde, kann eine weitere Abfrage, welche andererseits
durch diese CSCF (S-CSCF) oder durch einen weiteren Dienstvermittlungsknoten
angefordert worden wäre,
um eine Nummern-Beweglichkeits-Information zu erlangen, vermieden
werden, indem diese Anzeige zusammen mit der empfangen (neuen) unterstützten Kennung betrachtet
wird, welche in diesem Fall vorzugsweise den Domänennamen des (letztendlichen) Zielnetzwerkes enthalten
kann, welches die unterstützte
Kennung behandelt.
-
Nach
einem Empfang in Schritt 5 des INVITE in der CSCF, welche
zuerst Dienstanforderungen für
einen Zielbenutzer (I-CSCF) empfängt,
nämlich
eine I-CSCF von OperatorA in dem in 1 dargestellten
Beispiel, können
weitere Schritte aus dem Stand der Technik vorgenommen werden. Dies
bezieht beispielsweise eine Abfrage der Heimat-Server Einheit, HSS,
von OperatorA ein, welche die Adresse von einer CSCF bereitstellen
wird, welche als S-CSCF wirkt, welche ein Bedienen des Benutzers
leitet, welchem die Kennung zugewiesen war, welche in dem INVITE
empfangen ist (d.h., der Zielbenutzer). Diese CSCF kann weitere
Weiterleitungs-Kriterien anwenden, welche für diesen Zielbenutzer bei dieser
CSCF in der Zieldomäne
des OperatorA zur Verfügung
stehen. Die Weiterleitungs-Kriterien können beispielsweise auf Benutzerpräferenzen,
ein Benutzerprofil, einen Benutzerort, usw. basieren, und können beispielsweise
eine nachfolgende Änderung
der empfangenen Kennung und/oder des Diensttyps enthalten (beispielsweise
von SIP-Sitzung zum schaltungsvermittelten Telefonruf), wie dies
beispielsweise stattfinden kann, wenn der Zielbenutzer beispielsweise
eine Rufweiterleitung zu einem anderen Ziel programmiert hat.