-
Die
hierin offenbarte und beanspruchte Erfindung betrifft im allgemeinen
große
Kommunikationsnetze, die mehrere Server zum Bereitstellen von Diensten
an deren Benutzer oder Teilnehmer verwenden, wobei diese Benutzer
oder Teilnehmer mittels einer Anzahl verschiedener Benutzerkennungen identifiziert
werden bzw. mittels dieser auf diese zugegriffen wird. Insbesondere
betrifft die Erfindung Mittel, ein System sowie ein Verfahren für Netze
des oben bezeichneten Typs, die ein Auffinden des zuständigen Servers
ermöglichen,
damit dieser einem bestimmten Benutzer einen bestimmten Server zur Verfügung stellen
kann, ohne dass die Kennungstypen beschränkt werden, die sowohl für den Benutzer als
auch für
den Server, der den Dienst anbietet, verwendet werden.
-
Große Telekommunikationssysteme
tendieren heutzutage dazu, sich über
mehrere Betreibernetzwerke zu erstrecken, wobei die jeweiligen Netze eine
große
Bandbreite an unterschiedlichen Diensten anbieten und häufig auf
verschiedenen und unabhängigen
Technologien basieren. Eine wichtige Folge dieser Entwicklung ist
die Zusammenschaltung neu herauskommender Internet-basierter Netze,
entweder in einer Fest- oder Mobilumgebung, mit herkömmlichen
drahtgebundenen oder drahtlosen Telefonsystemen. Die Integration
unterschiedlicher Betreibernetzwerke, die unterschiedlicher Natur
sind und den Netzteilnehmern unterschiedliche Dienstarten anbieten,
erfordert häufig
eine Vielzahl unterschiedlicher Server innerhalb eines Telekommunikationsnetzes,
um Teilnahmeberechtigungen zu verwalten und ihren Benutzern Dienste
bereitzustellen.
-
Andererseits
kann die Implementierung und Unterstützung neuer innovativer Dienste
durch die Verwendung bestehender Netzressourcen, die in geeigneter
Weise modifiziert sind, ein wesentliches Hindernis darstellen, wenn
diese neuen Dienste effektiv auf den Markt gebracht werden sollen,
nämlich
zeitgerecht und ohne dabei die Nutzleistung oder andere Merkmale
in den bestehenden Netzressourcen zu riskieren. Ein allgemein üblich verwendeter
Lösungsweg
bestand in der Einführung
neuer zugeordneter Server zum Einführen von Diensten, die lediglich
zur Verwendung im Zusammenhang mit bestimmten Technologien zur Verfügung stehen
bzw. für
diese ge dacht sind. Eines der Hauptprobleme bei der Einführung von
mehreren dienstzugeordneten Servern sowie von mehreren teilnahmezugeordneten
Servern besteht im Finden des geeigneten Servers, um bestimmte Benutzer
zu bedienen, ohne Beschränkung bezüglich der
Identifizierung sowohl des Benutzers als auch des den Dienst erbringenden
Servers. Eine Lösung
dieses Problems muss sich an Benutzer- und Serverkennungen anpassen können, die
momentan nicht verfügbar
oder bekannt sind.
-
Im
allgemeinen wird ein Benutzer oder Teilnehmer in einem großen Telekommunikationsnetz mittels
bestimmter Benutzerkennungen identifiziert, die sich in Abhängigkeit
der bestimmten Systemtechnologien gewöhnlich unterscheiden. In einigen
Fällen unterstützt oder
verwendet ein bestimmtes Netz aus unterschiedlichen Gründen mehr
als eine Kennung für
denselben Benutzer. Es gibt Netze wie das GSM und ANSI-41, die sich
im Hinblick auf ihr Konzept in vielerlei Hinsicht ähnlich sind,
und die unterschiedliche Benutzerkennungen verwenden.
-
Die
GSM-Netze haben beispielsweise bestimmte Benutzerkennungen, wie
die IMSI, für
interne Identifizierungszwecke, während sowohl die GSM- als auch
das PSTN-Netze E.164-Kennungen für externe
Identifizierungszwecke verwenden. Die E.164-Kennungen können Benutzern oder Netzknoten
zugeordnet und für
Adressierungszwecke verwendet werden. Im UMTS-Netz, ähnlich wie
beim GSM-Netz, koexistieren numerische Schemen mit nicht numerischen
Schemen. Als weiteres Beispiel verwenden Internet-Protokoll-(IP)-Multimediasysteme
unterschiedliche Kennungen, die normalerweise auf nicht numerischen
Schemen basieren, z.B. SIP url, e-mail-Namen oder anderen Aliasen.
Diese Kennungen werden zum Identifizieren von Teilnehmern in einer
bestimmten Dienstumgebung verwendet, d.h. Teilnehmer, die bereit
sind, einen bestimmten Dienst oder Dienstgruppen zu erhalten. Diese
Kennungen werden auch zum Identifizieren von Servern für einen
bestimmten Dienst verwendet. Andererseits verwenden diese IP-Multimediasysteme
auch die E.164-Kennungen für
die Zusammenschaltung mit PSTN-Netzen, während typische IP-Mechanismen für Adressierungszwecke
verwendet werden.
-
Die
wachsende Verwendung unterschiedlicher Kennungen für jeden
Benutzer sowie das Vorliegen mehrerer Server, denen unterschiedliche
Dienste oder Dienstumgebungen in einem großen Telekommunikationsnetz
zugeordnet sind, erfordert einen verbesserten Mechanismus zum Auffinden
des geeigneten Servers, damit dieser bestimmten Benutzern Dienste
bereitstellt. Der verbesserte Mechanismus muss extrem flexibel sein,
d.h. er darf die Verwendung mehrerer Kennungen für Benutzer oder Server, die
die oben beschriebenen Dienste erbringen, nicht be- oder einschränken. Der
Mechanismus muss ebenfalls ernstzunehmende Echtzeit-Constraints
in dem Bestimmungsvorgang, welcher Server der aktuelle oder richtige
zum Bedienen des Endbenutzers ist, in Betracht ziehen. Ferner muss
die bereitgestellte Lösung
die Komplexität
der Implementierung und Konfigurierung minimieren sowie Betriebskosten
einschränken,
nämlich
unabhängig
von der großen
Anzahl der Benutzer, die jeweils mehrere, einem Kommunikationsnetz
zugeordnete Benutzerkennungen haben.
-
Auf
den obengenannten Bedarf an einer effizienteren Verteilung von Benutzerkennungen
wurde während
der Entwicklung des IP-Multimedia-Subsystems im Standardisierungsforum „ 3rd Generation Partnership
Project" (im folgenden
3GPP) hingewiesen. Der interessierte Leser wird insbesondere auf die „Subscription
Location Functionality" aufmerksam gemacht,
die in der Anlage F (Informativ) beschrieben ist: „User Identity
to HSS resolution" in
der Technischen Spezifikation (TS) 23.228. Hierin wurde erkannt,
dass während
des Registrierungs- und Sitzungsaufbaus ein Bedarf für das Lokalisieren
des eigentlichen Teilnehmerheimatservers (Home Subscriber Server – HSS),
der momentan die speziellen Teilnehmerdaten wie Aufenthaltsbereich-
oder Authentifizierungsparameter verwaltet, besteht, da sich mit hoher
Wahrscheinlichkeit mehr als ein HSS in diesem bestimmten Betreibernetz
befinden.
-
Folglich
besteht eine erste Aufgabe der vorliegenden Erfindung darin, Mittel
und Verfahren anzugeben, die eine flexible Verteilung von Benutzern unter
einer Vielzahl von verschiedenen und zugeordneten Anmeldungs- und
Dienstservern ermöglichen. Diese
flexible Verteilung ist wünschenswerterweise unabhängig von
Benutzerkennungsschemata, -strukturen und anwendbaren Diensten.
-
Eine
weiter Aufgabe der vorliegenden Erfindung besteht in der Bereitstellung
einer Lösung,
die Auswirkungen auf die derzeit vorgeschlagene Architektur für Telekommunikationssysteme
der 3. Generation minimiert und mit den existierenden herkömmlichen
Telekommunikationssystemen so kompatibel wie möglich ist.
-
Eine
weitere Aufgabe der vorliegenden Erfindung besteht darin, Mittel
und Verfahren anzugeben, die die obengenannte flexible Verteilung
der Benutzer ermöglicht,
ohne dabei die erforderlichen Bedienungs- und Wartungsaufgaben (Operation
and Maintenance – O&M) sowie die damit
verbundenen Kosten zu erhöhen.
In diesem Zusammenhang stellen automatisierte Vorgänge zum
Austausch erforderlicher Daten zwischen Datenbanken ein wesentliches Merkmal
dar, das von der vorliegenden Erfindung begehrt wird.
-
STAND DER
TECHNIK
-
Interessante
Ausgangspunkte sind in den typischen drahtlosen Systemen der 2.
Generation zu finden, z.B. den GSM- und ANSI-41-Netzen. Da diese
drahtlosen Systeme mehr und mehr Teilnehmer aufzunehmen hatten,
verlangten die Betreiber nach hochdimensionierten Teilnehmer-Datenbanken
wie der Heimatdatei (Home Location Register – HLR), um eine enorme Menge
von Anmeldungen verwalten zu können,
die O&M-Aktivitäten zu minimieren
und die Routing-Tabellen im Signalisierungssystemnetz Nr. 7 (SS7)
zu optimieren. Später
tendierten die Betreiber zur Einführung redundanter HLRs, durch
Aufspalten der existierenden, so dass jede HLR Reihen eigener Teilnehmer
und Reihen von Teilnehmern, die der redundanten HLR angehörten, enthielten.
Diese anfängliche
Aufteilung von Teilnehmern für
unterstützende
Redundanz wurde von der Einführung
mehr und mehr komplexer Routing-Tabellen im SS7-Netz begleitet.
Die möglichen
Bedürfnisse
für einen
Datenbankverteiler zum Auffinden der geeigneten HLR, die die Teilnahmeberechtigung
für bestimmte
Teilnehmer verwaltet, waren noch kein Muss, da, mit dem Verschieben
kompletter Teilnehmerreihen von einer HLR zu einer anderen, die
Verteilung gelöst werden
konnte, indem mehr Routing-Tabellen im SS7-Netz hinzugefügt wurden.
Die vor kurzem aufgetretenen Erfordernisse bezüglich Nummernportabilität, die in
einigen Fällen
gesetzlich geregelt ist, bei der individuelle Teilnehmer von einer
HLR, die zu einem Betreiber gehörte,
zu einer anderen HLR, die zu einem anderen Betreiber gehörte, machten
die Bedürfnisse
für einen
Datenbankverteiler definitiv zu einem Muss.
-
Eine
beispielhafte Beschreibung eines derartigen Datenbankverteilers
ist in der internationalen Anmeldung WO 99/23838 beschrieben, wobei
dieser Datenbankverteiler in einem bestimmten Netz als flexibles
Nummernregister (Flexible Number Register-FNR) bezeichnet wird. Dieses FNR stellt
die natürliche
Einsprungstelle in einem drahtlosen Netz der 2. Generation für Anfragen
dar, die auf diejenigen Teilnehmer bezogen sind, deren Teilnehmernummernreihen
zu diesem Netz gehören,
unabhängig davon,
welches Netz die Teilnahmeberechtigung des Teilnehmers momentan
verwaltet. Dies bedeutet, dass das FNR sämtliche Teilnehmernummernreihen, die
ein derartiges Netz adressieren, umfasst, sowie auch individuelle
Teilnehmernummern für
Teilnehmer, die von einem anderen Netz in dieses Netz portiert werden.
Ferner sind individuelle Teilnehmernummern von Heimatteilnehmern,
die in ein anderes Netz portiert wurden, speziell gekennzeichnet
und haben eine besondere Netzkennung, um zu einem Eintrittsknoten
in dem Netz zu gelangen, in dem der Teilnehmer momentan seine oder
ihre Teilnahmeberechtigung hält.
-
Teilnehmerbezogene
Anfragen basierend auf Teilnehmernummern wie IMSI- oder E.164-Formate
werden an das FNR in einem Netz adressiert, welches von diesem IMSI-
oder E.164-Format adressiert wird. Das FNR bestimmt dann, ob die
Anfrage lediglich an die zugehörige
HLR innerhalb ihres eigenen Netzes übertragen werden soll, für Teilnehmer, die
nie portiert oder von anderen Netzen importiert wurden, oder ob
die Anfrage an das zugehörige
Netz umgeleitet werden soll, in das der Teilnehmer exportiert wurde.
Sämtliche
der erforderlichen Routing- und Adressiermechanismen werden auf
unteren Signalisierungsschichten ausgeführt, wie dem Signalisierverbindungssteuerteil
(Signalling Connection Control Part – SCCP) im SS7.
-
Obgleich
diese Lösung
als der nächstliegende
Stand der Technik angesehen wird, so stellt er doch gravierende
Einschränkungen
für eine
direkte Anwendbarkeit auf neuere Szenarien zum Zusammenschalten
traditioneller fester und drahtloser Telefonnetze mit dem Internet
und Multimediadienstnetzen in großen Telekommunikationsnetzen
dar. Beispielsweise berücksichtigt
dieses FNR gemäß dem Stand
der Technik lediglich die Signalisierung, das Routing und die Adressierung
gemäß SS7-Prinzipien, wonach
Teilnehmer- oder Benutzerkennungen nur auf strukturierten Nummern
basieren. Ferner muss mindestens eine der einem Teilnehmer zugeordneten
Kennungen derart strukturiert sein, dass die Analyse einer derartige
Nummer die zugehörige
HLR eindeutig identifiziert. Eine weitere Einschränkung dieser
vorhergehenden Lösung
ist, dass weder andere neuere Kennungsbereiche noch eine andere
Protokollunterstützung
als SS7-bezogene obere Schichten während der Entwicklung dieser
drahtlosen Netze der 2. Generation berücksichtigt wurden. Ein weiterer
Nachteil hinter dieser Lösung,
und dessen Lösung
eine Aufgabe der vorliegenden Erfindung darstellt, besteht in der
kostenaufwendigen Bedienung und Wartung dieser Datenbankstrukturen,
wobei Betreiber manuell bei diesen eingreifen müssen, um eine übereinstimmende
Wechselbeziehung der Daten zu gewährleisten. Ferner wird gemäß diesem Stand
der Technik nichts vorweggenommen, was dienstzugeordnete Server
betrifft, wie diejenigen zum Unterstützen Multimediabezogener Dienste,
die als Antwort auf Anfragen aufgrund entsprechender Benutzerkennungen
adressiert werden können.
-
Die
veröffentlichte
U.S.-Patentanmeldung 2001/049676 (Kepler et al.) beschreibt Verfahren
und ein System zum Suchen von Inhalten durch Verwendung von Datenbankhierarchien,
die in Primärdatenbanken
mit eigenen bestimmten Daten und Sekundärdatenbanken strukturiert sind,
mit Untermengen dieser Daten zusammen mit einem Feld zum Anzeigen
der Primärdatenbanken,
die diese Daten besitzen. Diese Anmeldung führt die Bedürfnisse nach einer Front-End-Routing-Datenbank
ein, wobei große Datenmengen
unter mehreren Back-End-Datenbanken verteilt sind, was bei sequentiellen
Anfragen nicht geeignet ist, und noch weniger, wenn es darum geht,
sämtliche
dieser Back-End-Datenbanken bzw. die darin enthaltenen Datenarten
zu kennen. Abgesehen davon, wie der Fachmann weiß, können einige zusätzliche
Vorteile bestehen bezüglich
des Empfangens derartiger Anfragen in einer Front-End-Datenbank, wie
die Validierung von Anfragesuchfeldern, die weitere Überprüfungen ausschließen, wenn
sie die Anfrage an die betroffenen Back-End-Datenbanken übertragen. Wird in einer Front-End-Datenbank eine
Datenbanksuche empfangen, so wird eine modifizierte Suche aufgrund
der Überlappung
zwischen dem Informationstyp, der in der Suchanforderung enthalten
ist, und dem Informati onstyp, der in dem Datenfeld der Front-End-Datenbank
enthalten ist, erzeugt. Diese modifizierte Suchanforderung wird
zum Abrufen einer Liste von Datenbankkandidaten verwendet, die Ergebnisse
zur ursprünglichen
Suchanforderung produzieren könnten.
Die ursprüngliche Suchanforderung
wird dann an diese Datenbankkandidaten geleitet, und die Ergebnisse
werden an den Benutzer zurückgesendet.
-
Wie
der Fachmann weiß,
ist die Lehre der obengenannten Anmeldung darauf abgestellt, Suchen
nach bestimmten Inhalten auszuführen,
wobei eine Liste von Kandidatenergebnissen dem Benutzer präsentiert
wird, um das attraktivere mit Bezug auf die Ziele aus der ursprünglichen
Suche auszuwählen.
Diese Anmeldung scheint insbesondere die Art der Aufgaben zu beschreiben,
die von den Suchenden durchgeführt
werden. Dieser Lösungsweg
ist jedoch nicht für
die Anwendung geeignet, bei der Benutzer eines drahtlosen 3G-Netzes
versuchen, einen bestimmten Dienst aufzurufen, z.B. das Einleiten
einer Videokonferenz. Ein rufender Benutzer tätigt einen Anruf oder ruft
einen Dienst auf, und von dem Netz wird ein transparentes Verhalten
erwartet, so dass für
den Benutzer kein Handlungsbedarf für die Auswahl des geeignetsten
Servers besteht, der wiederum im Normalfall den Benutzern völlig unbekannt ist.
Diesbezüglich
können
weder die Suche noch die Routing-Lösungswege gemäß dieser
Anmeldung zum Erhalt einer flexibleren Verteilung von Benutzern in
einer Vielzahl von unterschiedlichen Servern in einem Telekommunikationssystem
angewendet werden.
-
In
der WO-A1-00/69140 wird dargelegt, dass sich die meisten der existierenden
Systeme auf eine zentralisierte Architektur stützen, eine Verteilung einer
Benutzerdatenbank und den Verkehr unter vielen Dienstanbietern erschweren
kann, und deutet auf das Problem hin, wie Benutzern eine einzige
Adresse zur Verfügung
gestellt werden kann, die für
sämtliche Kommunikationen
zu verwenden ist. Um dieses und weitere Probleme zu lösen, gibt
diese Anmeldung eine Vielzahl von Clustern oder Servern in einem konföderierten
Netz an, wobei jeder Cluster mit anderen Clustern verknüpft werden
kann, um Benutzerdienstanfragen durch eine Kettenstruktur weiterzuleiten.
In diesem konföderierten
Netz ist jeder Benutzer in einem bestimmten Cluster registriert
und erhält eine
global eindeutige Benutzer-ID, die aus einer eindeutigen Benutzer-ID
zusammen mit der Cluster-ID des Clusters besteht, in dem der Benutzer
re gistriert ist. Dementsprechend sind keine unterschiedlichen Benennungsschemata
für Benutzerkennungen
offenbart. Da ferner die Benutzerkennungen in einer Kettenstruktur
des Clusters verteilt werden, trifft ein Netzbetreiber, der ein
derartiges Netz an Clustern besitzt, auf Schwierigkeiten beim freien
Zuordnen und Verschieben von Benutzern unter den existierenden Clustern,
die sich um dessen eigene Bedürfnisse
und Voraussetzungen kümmern,
ohne dass der Benutzer davon Kenntnis hat und ohne wesentliche Betriebskosten.
Wann immer ein Benutzer von einem ersten zu einem zweiten Cluster
verschoben wird, muss dem Benutzer eine neue Netzadresse gegeben
werden, um Kontakt für
die Registrierung in dem neuen Netz-Cluster aufzunehmen, und seine
Benutzerkennung, die für
andere Benutzer, die diesen Benutzer erreichen, verwendet wird,
und die Benutzer-ID zusammen mit der Cluster-ID enthält, dort
wo der Benutzer registriert ist, ändert sich dementsprechend auch.
Jede Änderung
der Zuordnung von Benutzern, jede neue Verteilung von Benutzern
unter den existierenden Netz-Clustern erzeugt einen Anstieg der Bedienungs-
und Wartungskosten auf der Betreiberseite sowie eine erheblich Störung gegenüber den verschobenen
Benutzern. Somit stellt diese Anmeldung keine Lösung des obengenannten Problems dar,
Benutzerkennungen unter einer Vielzahl von Netzwerkservern in einer
flexiblen Art und Weise zu verteilen, um Betreibern eine Änderung
der Zuordnung für
eine Reihe von Benutzern von einem Netzwerk-Server zu einem anderen
zu ermöglichen
und die Komplexität
bei der Implementierung sowie die Bedienungskosten zu minimieren.
-
In
der internationalen Anmeldung WO-A1-01/03402 wird ein System und
ein Verfahren zum Authentifizieren angegeben, und somit zum Identifizieren
eines Teilnehmers eines ersten Netzes in einem zweiten Netz, wobei
der Teilnehmer mindestens eine Teilnehmerkennung in dem ersten Netz
hat, welches die Teilnahmeberechtigung des Benutzers verwaltet.
Aus diesem Grund wird dem Teilnehmer eine Adresse des zweiten Netzes
zugeordnet, und es wird eine Abbildung zwischen der Adresse des
zweiten Netzes und der Teilnehmerkennung durch einen Authentifizierungs-Client
durchgeführt
und an das zweite Netz über
eine Gateway-Vorrichtung übertragen,
die das erste mit dem zweiten Netz verbindet. Der Teilnehmer kann
somit in dem zweiten Netz dank dieser zur Verfügung gestellten Adresse des
zweiten Netzes authentifiziert werden. Hat der Teilnehmer eine Teilnahmeberechtigung
in dem ersten Netz, so ist dieses erste Netz für sämtliche Teilnehmerkennungen
für diesen
und für
andere Teilnehmer sowie für
deren Verteilung zwischen Teilnehmerdatenbanken wie der Heimatdatei
(Home Location Register – HLR)
unter Befolgung bestimmter Kriterien, die in diesem eigenen ersten
Netz erstellt wurden, verantwortlich. Allerdings erwähnt diese
Anmeldung nichts über
eine Verteilung eigener Teilnehmer.
-
Die
Veröffentlichung
WO 00/39981 betrifft Techniken zum Bereitstellen einer Nummernportabilität an Internet-Dienstanbieter.
Dieses Dokument gibt ein Verfahren und ein System zum Routen von
Verbindungen über
ein Telekommunikationsnetz an, mit einer Nummernportabilitätsdatenbank
zum Empfangen von Anfragen von einer verbindungsabsendenden Domäne zum Lokalisieren
eines Netzknotenparameters, der einem angerufenen Teilnehmer in
einer Datenkommunikationsdomäne
zugeordnet ist, wobei die Nummernportabilitätsdatenbank diesen Netzknotenparameter
an die anfragende Einrichtung zurücksendet. Es wird eine zentralisierte
Datenbank angegeben, mit einer Benutzerkennung für einen Teilnehmer, der in
ein anderes Netz portiert wird, wobei die Benutzerkennung mit einem
Netzknotenparameter assoziiert ist, der ein anderes Netz adressiert,
an das der Anruf umgeleitet werden soll. Allerdings findet sich
keine Unterstützung
für eine
Vielzahl von Benutzerkennungen unter verschiedenen Dienstumgebungen
für jeden
Benutzer, in denen jede Benutzerkennung mit unterschiedlichen Netzwerk-Servern
assoziiert sein kann, was nicht nur von der Benutzerkennung, sondern
auch von dem anwendbaren Dienst abhängig ist. Ferner wird in diesem
Dokument kein alternativer Mechanismus zum Aktualisieren von Inhalten
in den Nummernportabilitätsdatenbanken
vorgeschlagen, wenn ein Benutzer einem unterschiedlichen Server
zugeordnet wird, im Unterschied zu dem konventionellimplementierten
Verfahren, bei dem Betreiber manuell in die Datenbanken eingreifen
müssen,
um Benutzerdaten zu aktualisieren, wann immer eine Änderung
die Verteilung der Benutzer betrifft. Weiterhin lehrt das Dokument
nichts über
einen Mechanismus, bei dem die Datenbank über einen lokalen Benutzer
unter einer gegebenen Dienstumgebung konsultiert werden kann, wobei
der lokale Benutzer eine Vielzahl von Benutzerkennungen hat, und
unterschiedliche Benutzerkennungen, die demselben oder unterschiedlichen
Dienstkennungen zugeordnet sind, in einem gleichen oder unterschiedlichen
Netz-Servern gehandhabt werden. Das Dokument weist dabei die meisten
der oben kommentierten Nachteile in bezug auf die Nummernpor tabilitätsdatenbank
auf, wie beispielsweise die kostenaufwendige Bedienung und Wartung,
wobei Betreiber manuell eingreifen müssen, um übereinstimmende Daten und das
Vorkommen von Diensten und dienstzugeordneten Servern zu gewährleisten.
-
Somit
scheinen die obengenannten Aufgaben der vorliegenden Erfindung durch
die Lehren der oben beschriebenen Anmeldungen weder gelöst noch
vorweggenommen zu sein. In dieser Hinsicht ist die Bereitstellung
von Mitteln und Verfahren zum Ermöglichen einer flexiblen Verteilung
von Benutzern unter einer Vielzahl von Servern, unabhängig von
Benutzerkennungsschemata, -strukturen und anwendbaren Diensten,
eine Aufgabe der vorliegenden Erfindung. Diese Mittel und Verfahren
minimieren die Auswirkungen auf die Zusammenschaltung neuer und herkömmlicher
Telekommunikationssysteme sowie die O&M-Aufgaben und die Kosten, was ebenfalls Aufgaben
der vorliegenden Erfindung sind.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Zur
Lösung
dieser Aufgaben stellt die vorliegende Erfindung einen Benutzerkennungsverteiler
in eine auflösende
Netzdomäne,
der von einer Einrichtung, die Benutzerinformationen anfordern möchte, zugreifbar
ist. Der Verteiler, oder Benutzer-Verteilerserver (User Distribution Server-UDS)
umfasst eine Vielzahl von Benutzerkennungen pro Teilnehmerbasis,
die zum Identifizieren eines Benutzers unter unterschiedlichen Dienstumgebungen
gedacht sind.
-
Dieser
UDS implementiert eine Sekundärdatenbank
mit Kennungen von Benutzern und Servern, die aus den Primärdatenbanken
erhalten wurden, und ist zum Bestimmen eines spezifischen Netzwerk-Servers,
der für
einen gegebenen Benutzer unter einer bestimmten Dienstumgebung zuständig ist, eingerichtet.
Diese speziellen Netzwerk-Server werden als Primärdatenbanken angesehen, wobei
Teilnehmer oder insbesondere Benutzerdaten unter einer bestimmten
Dienstumgebung verteilt werden.
-
Der
UDS fungiert somit als eine Sekundärdatenbank, die Mittel zum
Wiederherstellen von Benutzerkennungen und notwendigen Dienstedaten
von den spezifischen als Primärdatenbanken
fungierenden Netzwerk-Servern sowie von anderen UDS in der auflösenden Netzdomäne umfasst.
Dieser UDS umfasst ferner einen Speicher für Benutzerkennungen und gegebenenfalls
notwendige Dienstedaten pro spezifischem Netzwerk-Server.
-
Der
UDS, der in der Lage ist, den spezifischen Netzwerk-Server, der
für einen
gegebenen Benutzer zuständig
ist, der mittels einer bestimmten Benutzerkennung unter einer bestimmten
Dienstumgebung identifiziert wird, umfasst ferner Mittel zum Empfangen
und Verarbeiten von Dienstanforderungen von einem Dienstanforderungsknoten
oder von einem anderen UDS in der auflösenden Domäne. Ferner umfasst der UDS
Mittel zum Antworten auf die vorhergehende Anforderung an den Dienstanforderungsknoten
oder einen anderen UDS. Insbesondere kann die Antwort den spezifischen
Netzwerk-Server umfassen, der für
den Benutzer unter einer bestimmten Dienstumgebung zuständig ist,
oder eine Liste möglicher
Netzwerk-Server, wenn eine redundante Konfiguration besteht, oder
eine neue Benutzerkennung mit der Angabe, dass eine andere Abfrage über eine
gegebene neue Kennung in einem anderen Server erforderlich ist,
und wahlweise mit Angabe des Grundes hierfür.
-
Der
UDS ist zur Kommunikation mit Primärdatenbanken, anderen externen
Datenbanken und Dienstanforderungsknoten ausgestaltet, mit denselben
oder mit unterschiedlichen Protokollen. Deshalb umfasst der UDS
ferner mindestens eines aus einer Vielzahl von Protokollbehandlungsmodulen
und in einigen Beispielen ein Protokolldiskriminatormodul.
-
Somit
stellt die Erfindung ein System bereit, das mindestens einen UDS – wie oben
beschrieben – umfasst,
obgleich mehr als einer enthalten sein können. Beispielsweise können unterschiedliche UDS
für unterschiedliche
Netzdomänesektoren
zuständig
sein, wenn Abstandskriterien bezüglich
des Aufenthaltsbereiches der existierenden Dienstanforderungsknoten
berücksichtigt
werden. In diesem System können
mehrere Primärdatenbanken
unterschiedliche UDS mit verschiedenen Inhalten aktualisieren, oder
aber mit denselben Inhalten für
Redundanzzwecke.
-
Gemäß einer
Ausführungsform
kann der UDS als eine Teilnahmelokalisierfunktion (Subscription
Locator Function – SLF)
fungieren. Der UDS gemäß dieser
Ausführungsform
ist in der Lage, den Heimatteilnahmeserver (Home Subscription Server – HSS),
der für
einen gegebenen Teilnehmer zuständig ist,
zu bestimmen. Diese HSS fungieren als Primärdatenbanken des UDS. Der Dienstanforderungsknoten
in diesem System fungiert beispielsweise als eine I-CSCF-Funktion
(Interrogating Call Status Control Function) oder als eine S-CSCF-Funktion
(Serving Call Status Control Function).
-
Eine
weitere Ausführungsform
gemäß der Erfindung
richtet sich auf ein Telekommunikationssystem, wobei relevante Benutzerkennungen
in mindestens einer aus einer Vielzahl von Primärdatenbanken zum Aktualisieren
an einen spezifischen UDS, an eine Gruppe von UDS oder an sämtliche UDS,
die in der mindestens einen Primärdatenbank bekannt
sind, gesendet werden können.
Ferner ist mindestens eine einer Vielzahl von Primärdatenbanken
zum Empfangen von UDS-Wiederherstellungspräferenzen von einem spezifischen
UDS, von einer Gruppe von UDS oder von sämtlichen UDS, die in der mindestens
einen Primärdatenbank
bekannt sind, eingerichtet. Das System ist ferner zum entsprechenden
Aktualisieren jedes UDS mit jeder Wiederherstellungspräferenz eingerichtet.
-
Die
Erfindung sieht auch ein Verfahren in einer auflösenden Netzdomäne vor,
wobei eine Vielzahl von Benutzerkennungen pro Teilnehmerbasis zum
Identifizieren eines Benutzers unter unterschiedlichen Dienstumgebungen
verwendet werden. Das Verfahren umfasst den Schritt des Bestimmens eines
spezifischen Netzwerk-Servers, der für jeden Benutzer unter einer
bestimmten Dienstumgebung in einem Benutzer-Verteilerserver zuständig (UDS). Das Verfahren umfasst
auch den Schritt des Wiederherstellens im UDS von Benutzerkennungen
und notwendigen Dienstedaten von spezifischen als Primärdatenbanken
fungierenden Netzwerk-Servern sowie von anderen UDS in der auflösenden Netzdomäne, sowie
den Schritt des Speicherns im UDS der Benutzerkennungen und notwendigen
Dienstedaten pro Teilnehmerbasis, gegebenenfalls pro spezifischem Netzwerk-Server.
Das Verfahren umfasst ferner den Schritt des Empfangens und Verarbeitens
von Dienstanforderungen von einem Dienstanforderungsknoten oder
von einem anderen UDS in der auflösenden Domä ne, und den Schritt des Antwortens einer
erwarteten Antwort an den Dienstanforderungsknoten oder einen anderen
UDS. Diese erwartete Antwort kann der spezifischen Netzwerk-Server,
der für
den Benutzer unter einer bestimmten Dienstumgebung zuständig ist,
sein, oder eine Liste möglicher Netzwerk-Server,
wenn eine redundante Konfiguration besteht, oder eine neue Benutzerkennung
mit der Angabe, dass eine andere Abfrage über die neue Kennung in einem
anderen Server erforderlich ist, und wahlweise mit Angabe des Grundes
hierfür.
-
Aufgrund
der speziellen Flexibilität,
die von einem UDS gemäß der Erfindung
bereitgestellt wird, kann der Dienstanforderungsknoten ebenfalls
eine Mobilfunkvermittlungsstelle oder ein Signalisierungs-Gateway
oder ein GPRS-Support-Knoten oder ein Anwendungsserver für Multimedia-bezogene Verwendung
sein. Diese Liste wird beispielhaft in nicht einschränkender
Weise angegeben und soll unter keinen Umständen den Umfang der Erfindung schmälern.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
Merkmale, Aufgaben und Vorteile der Erfindung gehen beim Lesen dieser
Beschreibung in Verbindung mit den beiliegenden Zeichnungen hervor.
-
1 zeigt
eine gattungsgemäße Netzarchitektur
mit Primär-
und Sekundärdatenbankstrukturen gemäß einer
Ausführungsform
der Erfindung.
-
2 zeigt
grundsätzlich
den Inhalt eines individuellen Datensatzes pro Teilnehmer in einer
Sekundärdatenbank
gemäß mindestens
einer Ausführungsform
der Erfindung.
-
3a beschreibt
schematisch eine Ausführungsform
der internen Architektur eines Benutzer-Verteilerservers gemäß der Erfindung.
-
3b beschreibt
schematisch eine weitere Ausführungsform
der internen Architektur eines Benutzer-Verteilerservers, wobei
mehrere Protokolle in einer externen Protokollanpassungseinheit
gehandhabt werden.
-
4 zeigt
grundsätzlich
eine beispielhafte Sequenz von Flüssen, die ausgeführt werden
sollen, um Sekundärdatenbanken
mit Inhalten von Primärdatenbanken
gemäß der Ausführungsform
in 1 zu aktualisieren.
-
AUSFÜHRLICHE
BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
-
Im
folgenden werden derzeit bevorzugte Ausführungsformen von Mitteln, einem
Verfahren und einem System beschrieben, die eine flexible Verteilung
von Benutzern unter einer Vielzahl von Servern ermöglichen,
unabhängig
von den Benutzerkennungsschemata, -strukturen und anwendbaren Diensten.
-
Gemäß einem
Aspekt der vorliegenden Erfindung ist ein Benutzer-Verteilerserver
(im folgenden UDS) in einer auflösenden
Netzdomäne
bereitgestellt, um dienstanforderungsbezogene Anfragen für bestimmte
Benutzer in bestimmten Dienstumgebungen zu empfangen. Der UDS ist
zum Fungieren als eine Sekundärdatenbank
eingerichtet, die eine Vielzahl von Benutzerkennungen auf einer
pro-Teilnehmerbasis enthält,
wobei jede Benutzerkennung in einer bestimmten Dienstumgebung anwendbar
ist und mit einer Serverkennung assoziiert ist, die den bestimmten
Server, der momentan für
die entsprechenden Benutzerdaten zuständig ist, adressiert. Diese bestimmten
Server sind zum Fungieren als Primärdatenbanken eingerichtet,
von denen Benutzerkennungen und notwendige Dienstedaten in den UDS
heruntergeladen werden, der als Sekundärdatenbank fungiert. Der UDS
beantwortet eine dienstanforderungsbezogene Anfrage für einen
bestimmten Benutzer an einen Dienstanforderungsknoten, indem er
die Serverkennung bereitstellt, um weiter den bestimmten Server
zu adressieren, der momentan den Benutzer in der anwendbaren Dienstumgebung
bedient.
-
Die
beispielhafte Architektur gemäß 1, die
eine flexible Verteilung von Benutzern ermöglicht, zeigt, wie dedizierte
Benutzer-Verteilerserver für
bestimmte geographische Aufenthaltsbereiche in einer bestimmten
Netzwerkdomäne
zuständig
sein können.
Beispielsweise können
UDS-1 und UDS-2 jeweils für
den geographischen Sektor-1 und den geographischen Sektor-2 in einer
Netzwerkdomäne-2 zuständig sein.
Benutzerkennungen können
unter verschiedenen Kriterien unter einer Vielzahl von Servern in
dieser Netwerkdomäne-2
verteilt werden, wobei zum besseren Verständnis lediglich die Server-1- Server-2,
Server-3 und Server-n gezeigt sind. Diese Server werden jeweils
mit 14–20 bezeichnet.
Die Server-1- Server-2, Server-3 und Server-n fungieren als Primärdatenbanken,
von denen Benutzerdaten in den UDS-1 und wahrscheinlich in den UDS-2 über jeweilige
Schnittstellen (P-11, P-12) von dem Server-1, (P-21, P22), von dem
Server-2, (P-31, P32) von dem Server-3 und (P-n1, P-n2) von dem Server-n
heruntergeladen werden.
-
Die
Klassifizierung zwischen Primär-
und Sekundärdatenbanken
vereinfacht die Handhabung von Daten, erlaubt die einfache Handhabung
von Änderungen
in Primärdatenbanken
und die weitere Aktualisierung dieser Änderungen in Sekundärdatenbanken.
Eine beispielhafte Ausführungsform,
wie diese Aktualisierung stattfindet, ist in der 4 dargestellt, wobei
zunächst
davon ausgegangen wird, dass der UDS-1 bereits in dem Netz existiert und
dass ein Bedienungs- und Wartungssystem (22) einen neuen Server
(Server-1) gestartet hat. Unter dieser Voraussetzung zeigt der Server-1
seine Präsenz
gegenüber dem
UDS-i mittels einer anwendbaren Protokollfunktion wie REGISTER an
und umfasst dabei seine eigene Server-1-Kennung. Der UDS-1 fordert
eine Aktualisierung für
sämtliche
relevanten Benutzer bei einer derartigen Serveranzeige in einer
anwendbaren Protokollfunktion wie UPDATE_Req. an. Nach Empfang der
Anforderung beim Server-1 werden geeignete Benutzerdaten mit anwendbaren
Protokollmitteln übermittelt,
die in der 4 durch eine Funktion UP-DATE_Ind. dargestellt
ist. Diese Funktion kann in der Praxis einen bestimmten Signalisierungsfluss darstellen,
zum Übermitteln
von Benutzerdaten für sämtliche
Teilnehmer im Server-1. Nach der Aktualisierung des UDS-1 erzeugt
jede neue Aktualisierung durch das O&M-System (22) in der Primärdatenbank wie
dem Server-1, wie ein neuer Benutzer, eine automatische Aktualisierung
vom Server-1 zum UDS-1. Ähnliche
Protokollmittel wie für
sämtliche
Benutzer und insbesondere andere, die jeweils die neuen Benutzerkennungen
enthalten, können
beispielsweise diese Funktion UPDATE_Ind. verwenden.
-
In
der 4 ist auch dargestellt, wie ein anderer UDS (UDS-2)
in das Netz eingeführt
werden kann, unter der Voraussetzung, dass die oben beschriebene
Situation erreicht worden ist. Der UDS-2 wird von dem O&M-System (24)
oder von einem ande ren typischen Mittel gestartet und ist bereits
so konfiguriert, dass er die momentan existierenden Server kennt,
mit denen er sich befassen soll. Unter der oben beschriebenen Voraussetzung
fordert der UDS-2 die Aktualisierung für sämtliche relevanten Benutzer
mit einer ähnlichen
Anzeige und Protokollfunktion an, wie oben beschrieben und durch
die Funktion UPDATE_Req in der 4 dargestellt. Nach
Empfang der Anforderung am Server-1 findet ein der Aktualisierung
des UDS-1 ähnlicher
Vorgang statt, mit notwendigen Aktualisierungsanzeigen (UPDATE_Ind),
bis zum Herunterladen der Kennungen für sämtliche Benutzer. Vorausgesetzt,
dass jede neue Aktualisierung von dem O&M-System (22) im Server-1
durchgeführt
wird, wie ein neuer Benutzer, wird eine automatische Aktualisierung
von dem Server-1 sowohl zum UDS-1 als auch zum UDS-2 ausgelöst.
-
Ein
weiterer beispielhafter Schritt gemäß 4 berücksichtigt
die Einführung
noch eines weiteren Servers (Server-2) in dem obigen Szenario. Der Server-2
wird von dem O&M-System
(24) oder einem anderen typischen Mittel gestartet und
ist bereits so konfiguriert, dass er den momentan existierenden UDS
kennt, der aktualisiert werden muss. Dann zeigt der Server-2 seine
Präsenz
gegenüber
dem UDS-1 und dem UDS-2 an, indem er die anwendbare Protokollfunktion,
wie die obenerwähnte
REGISTER-Funktion, überträgt, wobei
er seine eigene Server-2-Kennung enthält. Nach Empfang der entsprechenden
Anforderung für
die Aktualisierung sämtlicher
benutzerbezogenen Informationen vom UDS löst der Server-2 die entsprechenden
Anzeigen (UPDATE_Ind) an den anfordernden UDS aus.
-
Als
ein Ergebnis der oben beschriebenen Aktualisierungsprozeduren enthält ein UDS
Informationen bezogen auf sämtliche
der Server, die spezifische Dienste im Netz oder im Netzsektor unter
ihrer eigenen Kontrolle bereitstellen, einschließlich der relevanten bedienten
Benutzerkennungen auf einer pro-Teilnehmerbasis. Deshalb aktualisieren
Primärdatenbanken
den UDS, wenn sich relevante Benutzerdaten ändern. In einer auflösenden Netzdomäne, in der
eine Vielzahl von UDS existieren, kann ferner jeder UDS redundante
Informationen verwalten, die entweder direkt von der Primärdatenbank
oder von einem anderen UDS oder unter bestimmten Kriterien von beiden
aktualisiert werden. Wie beispielsweise in 1 gezeigt,
können
Benutzer-Verteilerserver,
die verschiedene geographische Sektoren versorgen, sich mittels einer
Verbindungsstrecke (P-00) gegenseitig die angeforderten Informationen
zur Verfügung stellen.
Vorzugsweise kann der UDS eigenständig einige spezifische Server
kontaktieren, um mehr dynamische Informationen über die Versorgungseinrichtung
bereitzustellen, wenn erforderlich.
-
Zu
diesem Zweck melden sich die Server (Server-1- Server-2, Server-3
und Server-n) in
einer Netzwerkdomäne
(P-11, P-21, P-31, P-n1) von sich aus bei mindestens einem (UDS-1)
aus einer Vielzahl von UDS in der Netzwerkdomäne-2 an. Existiert ein weiterer
UDS (UDS-2), können
zusätzlich
beide UDS miteinander kommunizieren (P-00), um Daten gegenzuprüfen, oder
aber aus Gründen
der Zuverlässigkeit,
oder einfach weil sie für
verschiedene geographische Bereiche zuständig sind.
-
Wie
in der 1 gezeigt, tritt ein typischer Fluss auf, wenn
ein externer Client (26) in einer auflösenden Netzdomäne, z.B.
die Netzdomäne-1,
eine Nachricht (S-10) an einen Dienstanforderungsknoten sendet,
d.h. in einer anderen auflösenden
Netzdomäne
wie der Netzdomäne-2.
Diese Nachricht könnte beispielsweise
Teil eines Anrufe oder Teil eines Registrierungsflusses sein, und
nach Empfang initiiert der Dienstanforderungsknoten eine Abfrage
(S-20) an einen bestimmten UDS (UDS-1). Dieser UDS kann dem Dienstanforderungsknoten
zugeordnet sein zum Handhaben der dienstanforderungsbezogenen Abfragen
durch gegebene Mittel, wie sie z.B. während einer Entdeckungsphase,
der Startphase oder mittels Konfiguration ausgeführt werden.
-
Der
die Abfrage empfangende UDS (UDS-1) überprüft die empfangenen Parameter,
nämlich
die benutzer- und/oder dienstbezogenen Daten und, mittels Durchsicht
seiner Datenbanksätze,
trifft auf den geeigneten Server, der für den spezifischen Benutzer unter
der anwendbaren Dienstumgebung zuständig ist. In diesem Zusammenhang
zeigt 2 ein erklärendes
und nicht einschränkendes
Beispiel von internen Datenbankinhalten in einem UDS gemäß einem Aspekt
der vorliegenden Erfindung. Die 2 zeigt, dass
ein spezifischer Benutzer verschiedene Kennungen haben könnte.
-
Ein
UDS wird von den Einrichtungen abgefragt, die die Verbindung mit
einem spezifischen Server anfordern, welcher einen Dienst an den
spezifischen Benutzer bereitstellt. Deshalb zeigt die anfordernde
Einrichtung die Benutzerkennung und wahlweise weitere Daten an,
z.B. die Angabe des angeforderten Dienstes. Im allgemeinen kann
das Datenbankverhalten des UDS durch benutzerdefinierte Verhaltensweisen
optimiert werden, z.B. wie die Tatsache des Akzeptierens von Abfragen
ohne eine explizite Angabe des involvierten Dienstes, in welchem Fall
sämtliche
der gespeicherten Benutzerdaten für einen andere Knoten zum Interpretieren
dieses Ergebnisses zurückgesendet
werden. Dadurch, dass sich diese benutzer- und dienstbezogenen Informationen
sehr rasch ändern
können,
werden Parameter angezeigt, die deren Gültigkeit, z.B. den „Time-to-Live"-Wert (im folgenden
als TTL bezeichnet) angeben. Für
den Fall, dass mehr als ein Server den Dienst an einen spezifischen
Benutzer bereitstellen kann, z.B. im Falle redundanter Konfigurationen, kann
die Liste möglicher
Server angezeigt werden. Für
den Fall, dass die Benutzerkennung derart strukturiert ist, dass
sämtliche
in einer bestimmten Ebene der Struktur enthaltenen Benutzer von
dem spezifischen Server bedient wurden, kann die Antwort der Abfrage
weiterhin diese Ebene der Struktur anzeigen.
-
Steht
jedoch der angezeigte Benutzer oder Dienst in der auflösenden Netzdomäne nicht
zur Verfügung,
so sendet der UDS den entsprechenden Fehler. Ein wesentlicher Aspekt
in dieser Hinsicht ist die Fähigkeit
des UDS, eine Abfrage bei einer externen Datenbank (S-25) wie in 1 dargestellt
zu machen, um weitere Informationen über bestimmte Einträge anzufordern,
wie z.B. für
eine Nummernportabilitätsauflösung. Diese
externe Datenbank (im folgenden mit Ex-Db abgekürzt) kann gemäß einem
Aspekt der vorliegenden Erfindung eine ähnliche Struktur und ähnliche
Inhalte aufweisen, wie der UDS, oder aber sie kann eine unterschiedliche
Struktur oder Inhalte aufweisen. Die Schnittstelle zum Konsultieren dieser
externen Datenbank kann eine derjenigen sein, die zwischen Primär- und Sekundärdatenbanken
verwendet werden, oder kann eine unterschiedliche sein.
-
Sobald
die Abfrage intern oder extern aufgelöst worden ist, sendet der UDS-1
eine entsprechende Antwort an den Dienstanforderungsknoten zurück (S-30),
die die geeignete Serverkennung enthält, um den geeigneten Server
zu adressieren. Geht man davon aus, dass diese Antworten von dem
Dienstanforderungsknoten gecacht werden können, wird eine Gültigkeitszeit – der vorgenannte
TTL-Wert – in
der Antwort übermittelt,
um ein derartiges Caching zu optimieren.
-
Ferner
kann der Dienstanforderungsknoten entweder den geeigneten Server
adressieren (S-40) oder entsprechend die erwartete Antwort an den
externen Clienten senden (S-45), damit der Client den geeigneten
Server in Abhängigkeit
von verschiedenen Verbindungsvoraussetzungen adressieren kann (S-50).
-
Die 1 zeigt
weiterhin, dass der UDS-1 erste Mittel (40) und zweite
Mittel (42) zum jeweiligen Empfangen einer Abfrage (S-20)
sowie zum Bereitstellen einer Antwort (S-30) umfasst. Der UDS-1 umfasst weiterhin
dritte Mittel (44) zum Übertragen
oder Wiederherstellen von Benutzerkennungen und Dienstedaten aus
den Primärdatenbanken
des Servers.
-
Wie
bereits oben erwähnt
wurde, ist der UDS zum Handhaben verschiedener Protokolle zur Kommunikation
mit den verschiedenen bestimmten Servern eingerichtet, die als Primärdatenbanken
fungieren, nämlich
zur Kommunikation mit möglichen
externen Datenbanken sowie zur Kommunikation mit mindestens einem
aus einer Vielzahl von Dienstanforderungsknoten. Der UDS ist dabei
mit mindestens einem Protokollbehandlungsmodul (im folgenden als PHM
bezeichnet) ausgestattet, welches in der Lage ist, mindestens eines
dieser verschiedenen Kommunikationsprotokolle zu handhaben. Vorausgesetzt, dass
es mehr als eines dieser PHM gibt, wird eine Art von Protokolldiskriminierungsfunktion
erforderlich, um zu bestimmen, welches bestimmte PHM sich mit einer
empfangenen Abfrage, Antwort oder anderen Nachricht unter bestimmen
Protokollvoraussetzungen befassen sollte. Diese Protokolldiskriminierungsfunktion
wird von einem zusätzlichen
Protokolldiskriminatormodul (im folgenden als PDM bezeichnet) ausgeführt, wie
es in den 3a und 3b gezeigt ist,
und welches nur in dem Fall benötigt
wird, dass mehr als ein PHM existiert. Der UDS (z.B. der UDS-1 oder
UDS-2) kann beispielsweise in der Lage sein, Abfragen zu interpretieren
und Antworten mit Unterstützung
von Telekommunikationsprotokollen zu übermitteln, welche vorzugsweise
gemäß mindestens
einem des „Domänennamen-Server-Protokolls" (DNS), „Light-Weight
Directory Access-Protokolls" (LDAP),
Radi usprotokolls oder Diameterprotokolls arbeitet. Auf diese Protokolle
wird in nicht beschränkender
Weise Bezug genommen, nämlich
lediglich um den deutlichen Vorteil der Einrichtung eines UDS zur
Unterstützung
mehrerer Protokolle herauszustellen, die durch Ersetzen oder Hinzufügen individueller Protokollbehandlungsmodule,
begleitet von lediglich in dem Protokolldiskriminatormodul ausgeführten Änderungen
geändert
werden können.
-
In
der 3a wird eine bevorzugte Ausführungsform des UDS (10)
gezeigt, umfassend mehrere PHM (29) (weiterhin als 1–3, m bezeichnet)
sowie eines eindeutigen PDM (30). Einem Fachmann ist klar,
dass ähnliche
Ausführungsformen
durch das Teilen einer Anzahl von PHM (29) und PDM (30) möglich sind,
die in einer sogenannten Protokollanpassungseinheit (32)
(im folgenden PAE) integriert sind. Wie in 3b gezeigt,
konnte ein dediziertes PHM in der PAE zur internen Kommunikation
mit dem UDS (10) reserviert werden, wobei auch hier ein
eindeutiges dediziertes PHM (34) vorliegt. Die 3b zeigt
auch, dass der UDS eine interne Datenbank (36) umfasst.
-
Zusätzliche
Vorteile können
erreicht werden, wenn Sekundärdatenbanken,
nämlich
der UDS, dem die Informationen Anfordernden – dem sogenannten Dienstanforderungsknoten
(28) – geographisch
näher sind,
um so den Auflösungsvorgang
zu beschleunigen, obgleich dieser Vorteil kein wesentliches Merkmal
darstellt.
-
Unabhängig von
dem geographischen Aufenthaltsbereich werden erste Abfragen von
Sekundärdatenbanken
wie dem UDS angefordert, während Primärdatenbanken
weiterhin nur dann abgefragt werden, wenn eine erste Abfrage erfolgreich
beantwortet wurde. Diese Prozedur kann zur Vermeidung der Überlastung
von Primärdatenbanken
aufgrund von Abfragen für
nicht existierende Benutzer nützlich sein,
die allgemein bekannt sind als „DoS-Angriffe" (Denial of Service
Attacks). Diese Lösung
bedarf keines speziellen Sicherheitsschutzes, der sich von jedem
anderen Standardknoten im Betreibernetz unterscheidet, weil ihr
Einsatz intern vom Netzbetreiber Netzbetreiber oder in einer „Trust-Relationship-Umgebung" erfolgt, wie die
von Partnern, die unter Wiederverwendung einer bestimmten Infrastruktur
in verschiedenen Ländern
operieren.
-
Die
in der 1 gezeigte Architektur sowie die wesentlichen
Merkmale und Vorteile, die oben im Zusammenhang mit dem UDS beschrieben
sind, sind zur Verwendung in einem Telekommunikationssystem geeignet,
welches gemäß des 3rd Generation Partnership Project (3GPP)
arbeitet. Insbesondere ist der UDS als eine Dienstlokalisierfunktion,
(Service Locator Function – SLF)
betriebsfähig,
wie sie im Anhang F zur Technischen Spezifikation (TS) 23.228 des
3GPP beschrieben ist.
-
Wie
in dieser TS beschrieben, muss der Heimatteilnehmerserver (Home
Subscriber Server- HSS), der momentan die teilnehmerspezifischen
Daten, wie z.B. den Aufenthaltsbereich des Benutzers oder die Authentifizierungsparameter,
verwaltet, während
der Registrierung und der Sitzungs- oder Verbindungsherstellung
identifiziert werden, da mit großer Wahrscheinlichkeit mehr
als ein HSS in dem Betreibernetz vorliegen. Die Identifizierung
eines bestimmten HSS ist für
einen I-CSCF-Funktionsknoten (Interrogating
Call Status Control Function) sowie für einen S-CSCF-Funktionsknoten (Serving Call Status Control
Function) notwendig, um den aktuellen Namen und/oder die Adresse
des HSS zu erfahren, der für
einen gegebenen Teilnehmer zuständig
ist. Insbesondere benötigt
der I-CSCF-Knoten die HSS-Kennung
sowohl während
der Registrierung als auch während
der Sitzungs- oder Verbindungsherstellung, während der S-CSCF-Knoten eine
derartige HSS-Kennung nur während
der Registrierung benötigt.
Zum leichteren Verständnis
bezieht sich diese Beschreibung lediglich auf einen CSCF-Knoten
(Call Status Control Function), wobei sich die Erläuterung auch
auf den I-CSCF oder den S-CSCF anwenden lässt.
-
In
diesem Szenario sind die verschiedenen HSS, in denen die Teilnehmer
verteilt werden, eingerichtet, um als Primärdatenbanken, wie diejenigen, die
oben mit Bezug auf die 1 gezeigt wurden, zu fungieren
und die in dieser Anmeldung als Server-i (wobei i = von 1 bis n)
bezeichnet werden, während der
CSCF-Knoten eingerichtet ist, um als der obenerwähnte Dienstanforderungsknoten
(28) zu fungieren. Gemäß der Erfindung
ist der obenerwähnte
UDS (10) dann als besagte Dienstlokalisierfunktion (Service Locator
Function – SLF)
betriebsfähig,
die als eine Sekundärdatenbank
für das
Empfangen von Abfragen von der CSCF fungiert, auf den HSS trifft,
welcher für
einen gegebenen Teilnehmer zuständig
ist und das Ergebnis der CSCF mitteilt.
-
Ein
UDS, der zum Fungieren als eine SLF eingerichtet ist, umfasst deshalb
mindestens ein Protokollbehandlungsmodul zum Behandeln der empfangenen
und beantworteten Abfragen vom sowie an den CSCF-Knoten. Vorausgesetzt,
dass das für
eine Kommunikation zwischen der SLF und dem HSS geeignete Protokoll
sich von demjenigen zwischen der SLF und der CSCF unterscheidet,
umfasst der zum Fungieren als eine SLF eingerichtete UDS ferner
ein weiteres Protokollbehandlungsmodul (Protocol Handler Module – PHM) zum
Behandeln von Aktualisierungen oder Downloads bei dem HSS. Wie bereits erwähnt, ist
ein Protokolldiskriminatormodul (PDM) in einem UDS enthalten, wenn
mehr als ein PHM verwendet wird.
-
Beispielsweise
enthält
die Schnittstelle zwischen einer CSCF und einem UDS, wobei der letztere
zum Fungieren als eine SLF eingerichtet ist, eine Funktion zur Abfrage
des Teilnahmelokalisierers von der CSCF sowie eine Antwort zum Bereitstellen
der HSS-Adresse an die CSCF. Insbesondere durch Senden einer Funktion
wie SLF_QUERY gibt die CSCF die Teilnehmerkennung (die während der
Registrierung oder der Sitzungs- oder Verbindungsherstellung empfangen
wurde) an, für
die ein HSS gesucht wird. Durch Zurücksenden der Funktion SLF_RESP
antwortet der UDS, der als eine SLF fungiert, dann mit dem Namen
und/oder der Adresse des HSS, damit die CSCF weiterhin den gegebenen HSS
abfragen kann. Alternativ kann die Funktion SLF RESP eine neue Benutzerkennung
angeben, mit einer Anzeige, dass eine weitere Abfrage vorgenommen
werden muss. Diese Anzeige kann entweder die Adresse für die neue
Abfrage mit einer Angabe des Grundes enthalten, oder lediglich einen
Grund für eine
neue Abfrage darstellen. Der erstere Anzeigetyp wird beispielsweise
für die
Nummernportabilität
verwendet, während
der letztere impliziert, dass die Adresse des neuen Servers von
der Abfrageeinrichtung herausgefunden werden muss. Vorausgesetzt, dass
das obige beispielhafte DNS-Protokoll zwischen einer CSCF und einer
SLF auch zwischen der SLF und dem HSS verwendet wird, kann die Funktion SLF_UPDATE_REQUEST
zum Anfordern von Benutzerdaten aus jedem bestimmten HSS verwendet werden.
Die Funktion SLF UPDATE wird dann von einem HSS zum Aktualisieren
des UDS verwendet, der als eine SLF fungiert, und zwar immer, wenn
eine Änderung
in diesem HSS auftritt.
-
Während des
Registrierungsflusses kann die I-CSCF wahlweise die HSS-Adresse
an die S-CSCF weiterleiten, um das Verhalten der S-CSCF auf der Suche
nach dem HSS zu vereinfachen. Für
den Fall, dass die empfangene Benutzerkennung nicht mit einem bekannten
Benutzer übereinstimmt,
wird der entsprechende Fehler zurückgesendet.
-
Bei
der beispielhaften Verwendung eines DNS-Protokolls – obgleich
dieses auch unter anderen Protokollen wie beispielsweise dem DIAMETER- oder
RADIUS-Protokoll
anwendbar ist – umfasst
die Aktualisierung einer Sekundärdatenbank
wie der UDS, der als SLF fungiert, von einer Primärdatenbank
aus, wie dem HSS, zugeordnete Mittel, die in der 4 vorweggenommen
sind.
-
Die
Funktion SLF_UPDATE_REQUEST, nämlich
UPDATE_Req gemäß 4,
stellt das Mittel für
die abfragenden Einrichtungen zur Angabe spezifischer Funktionen
bereit, die auf sämtliche
oder eine Gruppe von Kennungsleerzeichen angefordert werden. Diese
Funktion umfasst Mittel zum Anfordern „sämtlicher Benutzerdaten" oder „spezifischer
Benutzerdaten" für einen
Benutzer oder eine Gruppe von Benutzern, z.B. nur Daten bezogen
auf leitungsvermittelten Zugriff (circuit switching – im folgenden
als CS bezeichnet), oder nur Daten bezogen auf paketvermittelten
Zugriff (packet switching – im
folgenden als PS bezeichnet), oder nur Daten bezogen auf Internetprotokoll-Multimedia
(Internet Protocol Multimedia – im
folgenden als IM bezeichnet). Diese Funktion umfasst ferner Mittel
zum Anfordern einer „Gruppe
von spezifischen Daten" bezogen
auf das Dienstnetz (service network – im folgenden als SN bezeichnet),
was tatsächlich
eine Gruppe von Diensten für
einen oder eine Gruppe von Benutzern beinhalten kann. Ferner umfasst
diese Funktion auch Mittel zum Anfordern nur eines spezifischen
Typs von Kennungen, wie beispielsweise – und in nicht beschränkender
Weise – E.164-Nummern
oder SIP urls. Weiterhin kann diese Funktion Mittel zum Anfordern
nur solcher Kennungen umfassen, die einem spezifischen Kennungsleerzeichen
angehören,
wie beispielsweise nur Kennungen in der acme.land-Domäne.
-
Entsprechend
stellt die Antwortfunktion SLF_UPDATE, nämlich UPDATE_Ind gemäß 4, das
Mittel zum Anzeigen gegenüber
den abfragenden Einheiten bereit, dass „sämtliche Benutzerdaten" oder nur „spezifische
Benutzerdaten" für eine spezifischen
Benutzer oder für
eine Gruppe von Benutzern aktualisiert werden.
-
Andererseits
findet der Umfang der Einrichtungen, von denen eine Aktualisierung
angefordert werden soll, sowie der Umfang der Einrichtungen, die tatsächlich mit
Blick auf eine eindeutigen Dienst aktualisiert werden, eine Gruppe
von Diensten, oder sämtliche
Dienste für
einen Teilnehmer, eine Gruppe von Teilnehmern oder sämtliche
Teilnehmer, wie oben im Zusammenhang mit 4 beschrieben, auch
in diesem Fall Anwendung.
-
Zusammengefasst
stellt die Funktion SLF_UPDATE_REQUEST, nämlich UPDATE_Req gemäß 4,
Mittel bereit zum Anzeigen:
- – des Benutzerumfangs,
im Sinne eines Benutzers, einer Benutzergruppe unter einer Gruppierungsbedingung
oder sämtlicher
Benutzer;
- – des
Diensteumfangs, im Sinne eines spezifischen Dienstes, einer Gruppe
von Diensten oder sämtliche
Dienste;
- – des
Umfanges der abzufragenden Einrichtungen, im Sinne einer Einrichtung,
einer Gruppe von Einrichtungen unter bestimmten Bedingungen, d.h.
Multicast, oder sämtlicher
Einrichtungen, nämlich
Broadcast.
-
Entsprechend
stellt die Antwortfunktion SLF UPDATE, nämlich UPDATE_Ind gemäß 4,
Mittel bereit zum Anzeigen:
- – des Benutzerumfangs,
im Sinne eines Benutzers, einer Benutzergruppe unter einer Gruppierungsbedingung
oder sämtlicher
Benutzer;
- – des
Diensteumfangs, im Sinne eines spezifischen Dienstes, einer Gruppe
von Diensten oder sämtliche
Dienste;
- – des
Umfangs der zu aktualisierenden Einrichtungen, im Sinne einer Einrichtung,
einer Gruppe von Einrichtungen unter bestimmten Bedingungen, d.h.
Multicast, oder sämtlicher
Einrichtungen, nämlich
Broadcast.
-
Wird
ein neuer UDS, der als eine SLF fungiert, in das Netz eingeführt, wie
oben mit Blick auf 4 vorweggenommen, so wird eine
Abfrage an sämtliche
Knoten, die einen Dienst bereitstellen, d.h. an sämtliche
der Primärdatenbanken,
gestartet, nämlich
durch ein Broadcasting an Primärdatenbanken
wie den HSS. Andererseits kann dem Entfernen einer abfragenden Einrichtung,
z.B. der UDS, aus dem Netz eine Warnmeldung OUT_OF_SERVICE_like
an sämtliche
kooperierenden Primärdatenbanken
vorausgehen, oder es werden – alternativ – präsenzbezogene
Mechanismen ACTIVITY_TEST_like in den Primärdatenbanken vorgesehen, die
periodisch aufgerufen werden. Ein ähnlicher Lösungsweg gemäß der Erfindung
wird verwendet, wenn eine Primärdatenbank
wie der HSS aus dem Netz entfernt wird, entweder der obengenannte
Mechanismus OUT_OF_SERVICE_like oder der jeweilige Mechanismus bezogen
auf ACTIViTY_TEST_like. Was die Einführung, das Entfernen oder die
Modifizierung von Benutzerdaten betrifft, so enthält die obengenannte
UPDATE_Ind geeignete Anzeigenwerte, um so den Aktualisierungstyp
eindeutig zu interpretieren.
-
Obgleich
die Anforderung zum Aktualisieren sowie die Aktualisierung selbst
absichtlich und vorzugsweise auf Primär- und Sekundärdatenbanken ausgeführt werden,
kann es auch vorkommen, dass die Sekundärdatenbank UDS keine Kenntnis
von spezifischen, vor kurzem angeforderten Benutzerdaten hat. In
einer derartigen Situation, und insofern als der UDS weiß, wie eine
weitere Primär-
oder Sekundärdatenbank,
die derartige Daten verwaltet, lokalisiert wird, wird eine neue
Abfrage von dem Empfänger-UDS
an einen weiteren UDS oder an eine andere externe Datenbank abgegeben.
Dies ist insbesondere für
die Unterstützung
der Nummernportabilität nützlich,
für die
ebenfalls ein zusätzlicher
erklärender Verwendungsfall
in dieser Beschreibung gegeben ist.
-
Ein
Aspekt von besonderem Interesse betrifft das optimale Verhalten
eines UDS gemäß der Erfindung,
der als eine SLF fungiert und somit mit der CSCF während der
Registrierungsphase zusammenarbeitet. Die folgenden Erläuterungen
richten sich auf die Schnittstellen und Einrichtungen gemäß 1. Zunächst empfängt der
CSCF (Dienstanforderungsknoten) eine REGISTER-Anforderung (S-10)
und muss eine Abfrage nach dem Aufenthaltsbereich der Teilnehmerdaten
initiieren. Als zweites sendet die CSCF eine Funktion SLF QUERY
like (S-20) an die SLF (UDS-1) und schließt die in der REGISTER-Anforderung
angegebene Teilnehmerkennung mit ein. Das zu verwendende Protokoll
ist hier nicht wesentlich, da der erfindungsgemäße UDS mit einer Vielzahl von
Protokollbehandlungsmodulen (Protocol Handler Modules – PHM) ausgestattet
sein kann, wie dies in der 3a gezeigt
ist, und zwar in einer für die
Kommunikation mit DNS, DIAMETER, RADIUS oder einem anderen geeigneten
Protokoll passenden Art und Weise. Ferner kann die obenerwähnte Protokollanpassungseinrichtung
(32) gemäß 3b zwischen
der CSCF und dem UDS zu diesem Zweck zwischengeschaltet sein. Drittens,
noch immer mit Bezug auf die 1, durchsucht
die SLF (UDS-1) ihre eigenen Datenbankinhalte, wie beispielhaft
für die
abgefragte Teilnehmerkennung in 2 gezeigt. Viertens,
und wiederum mit Bezug auf die 1, antwortet
(S-30) die SLF (UDS-1) mit dem Namen des HSS, in welchem die Teilnehmerdaten
gefunden werden können.
Fünftens
startet die CSCF vorzugsweise eine Abfrage direkt beim dem HSS (Server-3) (S-40).
Alternativ zu obigem Schritt 5 sowie unter bestimmten Verbindungsvoraussetzungen
kann der CSCF (Dienstanforderungsknoten) (28) fortfahren, indem
er das Abfrageergebnis (S-45) an den externen Clienten (26),
der die Registrierungsanforderung vorgenommen hat, zurücksendet,
damit dieser externe Client eine Abfrage (S-50) bei dem geeigneten HSS
(Server-3) macht.
-
Neben
der obigen Aussage bezogen auf den Fall des Empfangs einer Registrierungsanforderung in
einer CSCF-Einrichtung wird ein ähnlicher
Lösungsweg
bzw. ein ähnliches
Verhalten von einem erfindungsgemäßen UDS in dem Fall erwartet,
dass ein I-CSCF-Knoten bei einer Sitzungs- oder Verbindungsherstellung
teilnimmt.
-
Ein
weiterer Vorteil bei der Verwendung eines UDS gemäß der Erfindung
als eine SLF besteht in der Einfachheit der Durchführung spezifischer
Abfragen bei externen Datenbanken (38) und somit in der
Unterstützung
von Nummernportabilitätsabfragen
in beiden Szenarien: in einem Donator-Netz und in einem Ursprungsnetz.
-
In
einem Donator-Netz kann das UDS-Konzept zur Handhabung der Nummern-
und Namenportabilität
unter einigen Voraussetzungen verwendet werden. Es kann vorkommen,
wie derzeit in einigen Szenarien geregelt, dass einige Flüsse zu einer I-CSCF eines Netzes
gelangen, das momentan die Teilnahmeberechtigung des Be nutzers nicht
verwaltet. Macht eine derartige I-CSCF eine Abfrage bei der SLF,
so muss in diesem Schritt eine Diskriminierung angewendet werden,
um zu vermeiden, dass derartige Abfragen von einem portierten Benutzer
in einen HSS dieses Netzes gefangen. Mit Bezug auf die 1 empfängt die
I-CSCF (Dienstanforderungsknoten) eine INVITE-Anforderung (S-10)
und muss eine Abfrage nach dem Aufenthaltsbereich der Teilnehmerdaten
durchführen.
Die I-CSCF sendet eine SLF_QUERY (S-20) an die SLF (UDS-1) und schließt als einen
Parameter die zuvor in der INVITE-Anforderung empfangene Teilnehmerkennung
mit ein. Die SLF (DS-1) sucht in ihrer eigenen lokalen Datenbank nach
der abgefragten Teilnehmerkennung. Ein beispielhafter Eintrag für die Kennung „2.2.3.4.9.e164.arpa" gemäß 2 offenbart,
dass dieser Benutzer mit einer Anzeige des Typs „Forward_query to_Ex_Db" als Serverkennung
portiert ist. Die SLF (UDS-1) macht dann eine Abfrage bei der Portabilitätsdatenbank
(externe Datenbank) (38), wie in der 1 gezeigt über die
Schnittstelle S-25, und erhält
von dieser Portabilitätsdatenbank die
für das
Kontaktieren des Benutzers zu verwendende Kennung. Als nächstes antwortet
(S-30) die SLF (UDS-1) der I-CSCF (Dienstanforderungsknoten) mit
einer Adresse oder URL zum Erreichen des Teilnehmers. Die I-CSCF
kann nun eine Anweisung zur Umleitung der INVITE-Nachricht an das Netz geben, in das
der Benutzer portiert wurde.
-
Andererseits
kann der UDS auch von Vorteil für
das Lösen
der Nummernportabilität
in Ursprungsnetzen sein, wo die Abfrage von einer S-CSCF-Einheit
(Serving Call Status Control Function) ausgeführt wird. In diesem Zusammenhang
finden dieselben Prinzipien für
die Abfrage einer S-CSCF bei einem UDS, der als eine SLF fungiert,
Anwendung, wie bei der Abfrage durch die oben angegebene I-CSCF.
-
Viele
weitere Szenarien können
von dem erfindungsgemäßen UDS
in vorteilhafter Weise Gebrauch machen. Beispielsweise kann dieser
UDS eine wesentliche Unterstützung
eines Betreibers eines virtuellen Netzes darstellen, der seinen
eigenen HSS besitzt, wobei dieser eigene HSS durch einen UDS identifiziert
wird, der als eine SLF in einem nicht virtuellen Netz fungiert,
das als eine entsprechende auflösende
Netzdomäne
adressiert wird.
-
Ein
weiteres Beispiel für
die Anwendbarkeit eines erfindungsgemäßen UDS ist die Registrierung von
Benutzern in externen Internetprotokoll-Multimedia-Dienstanbietern (Internet
Protocol Multimedia Service Providers – im folgenden als IMSP bezeichnet).
Das UDS-Konzept kann unter Befolgung derselben Prinzipien wie oben
verwendet werden, allerdings kann in diesem Fall der vom Benutzer
angegebene Kontaktname zum Identifizieren der Domäne angewendet
werden, wo der IMSP den Dienst bereitstellt. Mit anderen Worten
fungiert der Heimatbetreiber als eine Art Broker, nämlich als
Diensteanbieter, der Kontaktadressen für den Benutzer auf der Basis von
dessen Präferenzen
bereitstellt, oder aber einen Umleitungsdienst bereitstellt, wie
im Falle der Nummern- oder Namensportabilität.
-
Ein
weiterhin vorteilhafter Verwendungsfall findet sich im Zusammenhang
mit Abfragen und Antworten über
die sogenannte Sh-Schnittstelle zwischen einem HSS und einem Anwendungsserver (Application
Server – im
folgenden als AS bezeichnet) in einer IP-Mobilitätsmanagement-(IPMM)-Architektur.
Diese Anwendungsserver müssen
Zugriff auf in dem HSS gespeicherte Benutzerdaten haben, jedoch
ist es nicht möglich,
dass sie die Adressen sämtlicher
HSS für
sämtliche
Benutzer kennen, wie dies der Fall im Zusammenhang mit der I-CSCF
oder S-CSCF war. Deshalb erscheint derselbe erfindungsgemäße UDS anwendbar
auch in diesem Fall, in dem eine Einrichtung wie dieser UDS zwischen
dem HSS und dem AS zum Zwecke der Umleitung der Abfragen vom AS
zur korrekten HSS pro Benutzer und/oder angefordertem Dienst vorgesehen
sein kann.
-
Vorteile
und unterschiedliche Szenarien für die
Verwendung sind oben angegeben worden, wobei sich die meisten auf
die neueren Generationen drahtloser Systeme bezogen und insbesondere
deren Konnektivität
mit neueren Multimedia- und internetbezogenen Diensten betreffen.
Jedoch existiert noch eine weitere vorteilhafte Anwendung des UDS auf
klassische GSM- oder UMTS-Kennungen. Das UDS-Konzept kann mit denselben Prinzipien
angewendet werden, jedoch kann der von dem Benutzer angegebene Kontaktname
in diesem Fall die IMSI oder MSISDN sein, je nach dem speziellen
Nachrichtenfluss. Dies kann auf der Grundlage der Abbildung dieser
Nummern auf weiterleitbare Namen geschehen, wie bereits im ENUM-Protokoll vorgeschlagen, wonach
E.164-Nummern auf weiterleitbare Namen abgebil det werden. In diesem
speziellen Fall, und mit Bezug auf die 1, sind
die von den Dienstanforderungsknoten dargestellten Abfrageeinrichtungen
der Mobilfunkvermittlungsstellenserver (Mobile Switching Center – MSC),
der Gateway-MSC-Server (GMSC), der SGSN-Knoten (Serving GSM Server Node)
oder der GGSN-Knoten (Gateway GSM Server Node). Diese Einrichtungen
werden beispielhaft und in nicht beschränkender Weise genannt. Ferner sind
in dieser klassischen GSM- oder UMTS-Umgebung die HLR und der HSS
die Primärdatenbanken, die
von dem Server-1 bis zum Server-n repräsentiert werden. Der Dienstanforderungsknoten
könnte ebenso
ein Signalisierungs-Gateway, ein GPRS-Support-Knoten, ein Open-Service-Architecture-Service-Capability-Server,
ein Multimedia-Messaging-Server oder ein CAMEL-Gateway-Server sein.
-
Obwohl
in den beigefügten
Zeichnungen vorteilhafte Ausführungsformen
der vorliegenden Erfindung dargestellt und in der vorangehenden
ausführlichen
Beschreibung bevorzugte Ausführungsformen beschrieben
wurden, versteht es sich, dass die Erfindung nicht auf die offenbarten
Ausführungsformen beschränkt ist,
sondern dass eine Vielzahl von Umstellungen, Modifizierungen und
Substitutionen möglich
sind, ohne dass dabei vom Umfang der Erfindung, wie in den folgenden
Ansprüchen
vorgebracht und definiert, abgewichen wird.