DE60202527T2 - Verfahren und system zur behandlung von mehrfachanmeldungen - Google Patents

Verfahren und system zur behandlung von mehrfachanmeldungen Download PDF

Info

Publication number
DE60202527T2
DE60202527T2 DE60202527T DE60202527T DE60202527T2 DE 60202527 T2 DE60202527 T2 DE 60202527T2 DE 60202527 T DE60202527 T DE 60202527T DE 60202527 T DE60202527 T DE 60202527T DE 60202527 T2 DE60202527 T2 DE 60202527T2
Authority
DE
Germany
Prior art keywords
user
cscf
received
session
registration
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60202527T
Other languages
English (en)
Other versions
DE60202527D1 (de
Inventor
Antonio Juan SANCHEZ HERRERO
Michael John WALKER
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of DE60202527D1 publication Critical patent/DE60202527D1/de
Application granted granted Critical
Publication of DE60202527T2 publication Critical patent/DE60202527T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4588—Network directories; Name-to-address mapping containing mobile subscriber information, e.g. home subscriber server [HSS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/147—Signalling methods or messages providing extensions to protocols defined by standardisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/148—Migration or transfer of sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration

Description

  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft Telekommunikationssysteme, die die Verwaltung von Informationen bezogen auf den Aufenthaltsort ihrer Benutzer erfordern sowie von Informationen bezogen auf die Kennung, die jeden dieser Benutzer in den Systemen adressiert und identifiziert. Insbesondere betrifft sie die Unterstützung mehrfacher Registrierungen von mindestens einem Benutzer eines der Telekommunikationssysteme, wobei die mehrfachen Registrierungen von einer Mehrzahl von Endgeräten angefordert werden, sowie die weitere Abwicklung eines mehrfachen Sitzungsaufbaus gegenüber der Mehrzahl von Endgeräten.
  • HINTERGRUND
  • Den Benutzern, die an Diensten teilnehmen, welche von einem Telekommunikationssystem bereitgestellt werden, wird gewöhnlich eine Kennung zugeordnet (Teilnehmeridentifikationen, Teilnehmerkennungen oder Teilnehmer-IDs). Im Fall einer gegebenen Teilnahme eines Benutzers in einem gegebenen Telekommunikationssystem wird mindestens eine Teilnehmer-ID zum Zuordnen verwendet. Diese Teilnehmer-ID(s) identifiziert diese Teilnahme eindeutig und wird in dem System zu Adressier- und Identifizierungszwecken verwendet. Der Typ, der Inhalt und selbst die Anzahl der Teilnehmer-ID(s) pro Benutzer hängt grundsätzlich von den Charakteristika des Telekommunikationssystems ab.
  • In einem Telekommunikationssystem wie einem öffentlichen Fernsprechwählnetz (Public Switched Telephone Netzwork – PSTN) oder einem diensteintegrierenden digitalen Fernmeldenetz (Integrated Services Digital Network – ISDN) werden die Benutzer beispielsweise einer Telefonnummer als Teilnehmer-ID zugeordnet (obgleich mehr als eine Telefonnummer pro Benutzer in diesen Systemen zugeordnet werden kann). Diese Telefonnummern entsprechen dem in der ITU-T-Empfehlung E.164 (Mai 1997) spezifizierten Format und sind pro Benutzer gemäß einem speziellen Numerierungsplan zugeordnet. Sobald eine E.164-Nummer einem Benutzer eines PSTN zugeordnet ist, wird diese Nummer sowohl für das Adressieren (Routing) von Anrufen an diesen Benutzer als auch für die Identifizierung dieses Benutzers innerhalb des Netzes verwendet.
  • Da bei dieser Art von drahtgebundenen Systemen der Punkt in dem Telekommunikationssystem, an dem der Benutzer auf den von dem System bereitgestellten Dienst zugreift (Zugangspunkt), feststeht, wird vorausgesetzt, dass der Benutzer über das mit diesem Zugangspunkt verknüpfte Endgerät erreichbar ist, so dass sich deshalb der Benutzer für gewöhnlich zuvor nicht registrieren (anmelden) muß, um Zugriff auf die von dem Telekommunikationssystem bereitgestellten Dienste zu erhalten.
  • In anderen Telekommunikationssystemen wie beispielsweise in einem 2G-(zweite Generation)-Mobilsystem (wie einem Global System for Mobile Communications oder GSM) oder in einem 3G-(dritte Generation)-Mobilsystem (auch bekannt als universelles mobiles Telekommunikationssystem oder UMTS) ist diese Teilnehmer-ID pro Benutzer nicht eindeutig. Einem gegebenen Benutzer, der in einem der 2G- oder 3G-Systeme teilnimmt, wird eine eindeutige private Kennung (private Kennung oder private ID) zugeordnet, sowie mindestens eine öffentliche Kennung (öffentliche Kennung oder öffentliche ID).
  • Im Gegensatz zu traditionellen Telekommunikationssystemen, die feste (drahtgebundene) Zugriffstechnologien verwenden (z.B. PSTN), kann in mobilen Systemen derselbe Benutzer auf das System von unterschiedlichen Zugangspunkten aus zugreifen, d.h. von unterschiedlichen Aufenthaltsorten. Deshalb registriert dieser Benutzer zu einem gegebenen Zeitpunkt (z.B. jedes Mal vom selben oder einem unterschiedlichen Endgerät aus durch denselben oder einen unterschiedlichen Funkzugriffsserver) seine/ihre Präsenz von einem unterschiedlichen Zugangspunkt aus, so daß der Benutzer seine/ihre Präsenz in einem gegebenen Zugangspunkt von einem gegebenen Endgerät aus registriert (anmeldet), bevor er auf andere Dienste zugreift, z.B. dem Durchführen oder Empfangen von Anrufen. Innerhalb dieses Prozesses (im folgenden als Registrierung bezeichnet) identifiziert das Endgerät des Benutzers die von ihm/ihr gehaltene Anmeldung, deren Aktivierung er/sie wünscht, und dies geschieht durch Senden (u.a. Authentifizierungs- und Identifikationsdaten) der privaten ID, die dieser Teilnahmeberechtigung zugeordnet ist.
  • Sobald die Registrierung eines 2G- oder 3G-Benutzers erfolgreich läuft, kann dieser Benutzer eingehende Sitzungen (z.B. Fernsprechrufe) auf seinem/ihren Endgerät von anderen Benutzern empfangen, die die öffentliche ID (oder eine der öffentlichen IDs) „gewählt" haben, die der Teilnahmeberechtigung des Benutzers zugeordnet ist. Mit anderen Worten wird die öffentliche ID von anderen Benutzern als eine obengenannte „Telefonnummer" benutzt.
  • An diesem Punkt sei darauf hingewiesen, daß der Begriff „Sitzung", wann immer dieser innerhalb dieser Erfindung verwendet wird, verschiedene Arten von Kommunikationen umfaßt, die – gemäß Telekommunikationssystemen und Telekommunikationsprotokollen nach dem Stand der Technik – zwischen Kommunikationspartnern aufgebaut werden können. Hierdurch besteht keine Beschränkung auf traditionelle „Fernsprechrufe", die von bekannten schaltungsvermittlung-basierten Systemen und Protokollen zur Verfügung gestellt werden, sondern es sind auch Kommunikationen umfaßt, die von paketvermittlung-basierten (oder zellenvermittlung-basierten) Systemen und Protokollen bereitgestellt werden, die Kommunikationen mit mehrfachen Medienfähigkeiten zur Verfügung stellen, z.B. Audio, Video und Daten, selbst gleichzeitig innerhalb derselben Kommunikation. Beispiele für diese Kommunikationen, die als „Multimedia-Kommunikationen" bekannt sind (auch als Multimedia-Sitzungen oder Multimedia-Verbindungen), werden beispielsweise in der ITU-T-Empfehlung H.323 (November 2000) oder in RFC-2543 „Session Initiation Protocol", SIP (März 1999) der IETF beschrieben.
  • Bei einer gegebenen Teilnahmeberechtigung eines gegebenen Benutzers in einem 2G- oder 3G-System führt ein gegebener Heimatserver in dem System (bekannt als Heimatdatei (Home Location Register) oder HLR oder Heimat-Teilnehmerserver (Home Subscriber Server) oder HSS) u.a. Daten, und als ein Teil der Teilnehmerdaten (Subscriber Date – SD) bezogen auf diese Teilnahmeberechtigung das Verhältnis zwischen der Teilnahmeberechtigung des Benutzers und dieser zugeordneten private ID und öffentlichen ID(s). Diese Heimatserver (z.B. HLR oder HSS) befassen sich hauptsächlich mit Anfragen von anderen Knoten und Servern in dem System, wann immer eine Registrierungsanfrage eines gegebenen Benutzers bereitgestellt (d.h. gewährt oder abgewiesen) werden muß, oder wann immer Aufenthaltsortinformationen eines gegebenen Benutzers erforderlich sind (z.B. bei einem Anruf an diesen Benutzer).
  • In 2G- oder 3G-Systemen ist die private ID eines gegebenen Benutzers pro Benutzer-Teilnahmeberechtigung eindeutig und wird innerhalb des 2G- oder 3G-Systems zu internen Identifizierungszwecken bei der Anmeldung, Autorisierung, Verwaltung etc. benutzt.
  • Bei einer gegebenen Teilnahmeberechtigung ist diese private ID auch in einem Teilnehmerkennungsmodul gespeichert, das beispielsweise als SIM oder USIM für 3G bekannt ist, welches in der Teilnehmerkarte, beispielsweise einer Teilnehmerkennungsmodulkarte oder einer SIM-Karte oder einer UMTS-integrierten Schaltungskarte oder einer UICC, enthalten ist, die dem Benutzer zur Verfügung gestellt wird, zusammen mit anderen Sicherheitsinformationen bezogen auf diese Teilnahmeberechtigung, wie z.B. Geheimschlüssel, die zur Authentifizierung verwendet werden. Diese Teilnehmerkarte (SIM-Karte, UICC) soll entweder fest oder herausnehmbar im Endgerät des Benutzers, das zum Zugriff auf diese Systeme verwendet wird, anbringbar sein.
  • Im Gegensatz zu öffentlichen IDs müssen private IDs weder den Benutzern dieser Systeme noch anderen Benutzern anderer Telekommunikationssysteme bekannt sein, da sie nicht zur Verwendung (d.h. zum „Wählen") von einem gegebenen Benutzer bestimmt sind, um eine Kommunikation mit einem anderen Benutzer aufzubauen. Mit anderen Worten sind diese privaten IDs nicht zur Verwendung als „Rufnummer" oder zum Identifizieren der anrufenden oder verbundenen Partei im Display des Endgerätes des Benutzers bestimmt.
  • In 2G-Systemen besitzt eine private ID das IMSI-Format (International Mobile Subscriber Identity), während in 3G-Systemen eine private ID das NAI-Format (Network Access Identifier) hat, welches in RFC-2486 „The Network Access Identifier" (Januar 1999) definiert ist, wobei das IMSI im NAI enthalten sein kann.
  • In diesen 2G- oder 3G-Systemen soll(en) die öffentliche ID(s) eines gegebenen Benutzers jedoch zum Adressieren (Routing) von Anrufen an den Benutzer verwendet werden, so daß sie deshalb zur Verwendung als „Telefonnummer" in anderen Telekommunikationssystemen, z.B. dem PSTN (öffentliches Fernsprechwählnetz), dem ISDN (diensteintegrierendes digitales Fernmeldenetz) bestimmt ist, einschließlich zu Zwecken der Identifizierung der anrufenden und verbundenen Partei. Somit werden öffentliche IDs zum Aufbau von Kommunikationen zwischen Benutzern verwendet und sollen deshalb nicht nur den Benutzern der Mobilsysteme (2G oder 3G), sondern auch den Benutzern anderer Telekommunikationssysteme, die mit den 2G- oder 3G-Systemen zusammenwirken können, bekannt sein. Auf diese Weise muß ein Benutzer (Benutzer A), der einen Kommunikationsaufbau mit einem anderen Benutzer (Benutzer B) wünscht, die öffentliche ID des Benutzers B (oder eine der öffentlichen IDs des Benutzers B) in der Verbindungsanforderung, die dieser Benutzer A durchführt, anwenden (d.h. „wählen"). Der Benutzer B wiederum kann (sofern dieser Dienst erlaubt ist) die anrufende Partei aufgrund der öffentlichen ID des Benutzers A, die der Benutzer B empfängt, identifizieren.
  • Das Format der öffentlichen ID(s) eines Benutzers kann in Abhängigkeit der Besonderheiten des Telekommunikationssystems, in dem der Benutzer angemeldet ist, variieren. In 2G- und 3G-Systemen haben öffentliche IDs das Format von E.164-Nummern (bekannt als MSISDN-Nummern) (d.h. es sind typische Telefonnummern wie im PSTN). In 3G-Systemen, die das sogenannte IM-Subsystem (oder IMS) (Internet Protocol Multimedia Subsystem) implementieren, können öffentliche IDs auch andere Formate haben, z.B. als SIP-URL (Uniform Resource Locator for Session Initiation Protocol), TEL-URL (Uniform Resource Locator for Telephony), etc.
  • Angesichts dessen, daß derzeitige Mobilsysteme (2G oder 3G) lediglich eine private ID pro Benutzeranmeldung zur Verfügung stellen, und angesichts dessen, daß diese eindeutige private ID im Registrierungsprozeß verwendet wird, erlaubt es das System einem gegebenen Benutzer nicht, sich in einem Mobilsystem zu registrieren, das auf dieselbe Teilnahmeberechtigung von mehr als einem Endgerät verweist (d.h. durch Identifizieren derselben privaten ID bei jeder Registrierungsanforderung), da dies die Existenz einer SIM-klonenden Situation implizieren würde, d.h. die Existenz von zwei Teilnehmerkarten mit den darauf befindlichen selben Daten. Wenn deshalb (und unter Außerachtlassung verschiedener komplexer Techniken zur Feststellung des SIM-Klonens) ein Teilnehmer versucht, sich zu registrieren, während er bereits eine für seine/ihre Teilnahmeberechtigung aktive Registrierung hat, so wird diese neue Registrierung als Wiederregistrierung aufgefaßt, und sämtliche Daten bezogen auf die alte Registrierung werden mit den Daten bezogen auf die neue Registrierung überschrieben.
  • In dieser Situation, in der ein gegebener Benutzer nur eine Teilnahmeberechtigung hat, kann nur eine Registrierung für diesen Benutzer und diese einzige Teilnahmeberechtigung aktiv sein, und es sind keine gleichzeitigen Aufenthaltsorte für diese einzige Teilnahmeberechtigung erlaubt. Möchte deshalb ein gegebener Benutzer mehr als ein Endgerät registrieren, muß er über mehr als eine Teilnahmeberechtigung verfügen und eine unterschiedliche Teilnahmeberechtigung zum Registrieren jedes seiner Endgeräte verwenden.
  • Moderne Telekommunikationssysteme (wie 3G-Mobilsysteme) sind jedoch dazu bestimmt, eine große Vielfalt an Diensten anzubieten. In Abhängigkeit der Eigenschaft dieser Dienste würden einige davon Fähigkeiten im Endgerät des Benutzers erfordern (z.B. ein auf Multimedia-Fähigkeiten basierender Dienst oder Dateien-/Datenübertragungsfähigkeiten), die für andere Dienste nicht notwendig sind (z.B. ein auf reinen Sprachfähigkeiten basierender Dienst).
  • Dies würde es für einen gegebenen Benutzer, der über eine Teilnahmeberechtigung in einem dieser Systeme verfügt, wünschenswert machen, gleichzeitig für eine Mehrzahl von Endgeräten registriert zu sein (z.B. mit jeweils unterschiedlichen Fähigkeiten), und all dies, ohne die Sicherheitsaspekte zu schädigen, die sich auf die Identifizierung der Teilnahmeberechtigung dieses Benutzers verlassen, und ohne den Benutzer zu zwingen, mehr als eine Teilnahmeberechtigung zu besitzen.
  • Die 1 wurde der technischen Spezifikation TS 23.228 (V5.0.0, April 2001) entnommen, herausgegeben vom 3GPP (3rd Generation Partnership Project), bei dem es sich um das Forum handelt, welches mit der Entwicklung von Standards zur Führung der 3G-Systeme betraut ist. Obgleich diese Figur das Verhältnis zwischen der privaten ID und (einer) öffentlichen ID(s) einer gegebenen Teilnahmeberechtigung (Internet Multimedia Subscription oder IM-Subscription) eines gegebenen Benutzers (IM-Benutzer) des IMS (Internet Protocol Multimedia Subsystem) eines 3G-Systems zeigt, stellte es eigentlich das eindeutige Verhältnis nach dem Stand der Technik dar, welches in mobilen Systemen – unabhängig von deren Generation (2G oder 3G) – zwischen einer Teilnahmeberechtigung und der dieser Teilnahmeberechtigung zugeordneten privaten ID existiert. Aus dieser Figur ist ersichtlich, daß, obwohl ein gegebener Benutzer, der über eine einzige Teilnahmeberechtigung verfügt, mittels unterschiedlicher öffentlicher IDs erreichbar ist (d.h. angerufen werden kann), die Teilnahmeberechtigung dieses Benutzers von einer einzigen (und nur) privaten ID identifiziert wird.
  • Das in der 1 gezeigte Verhältnis wird überwiegend im Heimatserver des Benutzers (HSS, HLR) aufrechterhalten und gehalten, obgleich Kopien dieser Daten und Verhältnisse auch in anderen Knoten (oder Servern) innerhalb des Telekommunikationssystems gehalten und verwendet werden kann. Allerdings entfaltet sich die dem obengenannten eindeutigen Verhältnis innewohnende Logik über jeden Server innerhalb des Telekommunikationssystems und verhindert sowohl mehrfache aktive Registrierungen eines gegebenen Benutzers mit nur einer Teilnahmeberechtigung aus einer Mehrzahl von Zugangspunkten als auch an den Benutzer adressierte nachfolgende Anrufe, die an einen oder mehr dieser Zugangspunkte, bei denen sich der Benutzer aufhalten kann, übermittelt werden sollen.
  • Bei bekannten Standards für 3G-Systeme wurde die Möglichkeit von UMTS-Teilnehmerkarten in Betracht gezogen, die mehr als eine Teilnahmeberechtigung halten (d.h. mehr als eine USIM innerhalb derselben UICC) (z.B.: 3GPP TS 22.101, v4.0.0, Juni 2001), wodurch es demselben Endgerät möglich ist, alternativ für unterschiedliche Teilnahmeberechtigungen registriert zu werden. Allerdings kann nur eine dieser Teilnahmeberechtigungen zu einem gegebenen Zeitpunkt in diesem Endgerät aktiv sein, und es kann die diesen Endgeräten innewohnenden Fähigkeiten bezogen auf die Art der Sitzungen auf jeden Fall handhaben, unabhängig von der aktiven Teilnahmeberechtigung.
  • Das SIP (Session Initiation Protocol) wurde vom 3GPP als das Protokol zum Handhaben von Benutzerregistrierungen und zur Sitzungssteuerung für Benutzer, die IM-Teilnahmeberechtigungen halten, ausgewählt. Die Spezifikation des SIP (RFC-2543) ermöglicht es bereits einem gegebenen Benutzer, in einer Registrierungsnachricht REGISTER mehrfache Kontaktpunkte anzugeben, an denen der Benutzer für weitere eingehende Sitzungen, die an die in dem „FROM"-Kopffeld oder der REGISTER-Nachricht enthaltene Kennung (d.h. öffentliche ID) adressiert werden, kontaktiert (d.h. erreicht) werden kann. Diese Kontaktpunkte sind in nachfolgenden „Kontakt"-Kopffeldern innerhalb einer oder nachfolgender REGISTER-Nachrichten enthalten, wobei jedes „Kontakt"-Kopffeld eine Adresse eines gegebenen SIP-Endpunktes enthält (d.h. ein SIP-freigegebenes Endgerät). Demzufolge würde eine SIP-REGISTER-Nachricht von einem gegebenen Benutzer, wie
    REGISTER sip:server2.wcom.com
    Via: ...
    From: <sip.UserB@there.com>
    to: ...
    Call-ID: ...
    Cseq: 1 REGISTER
    Contact: <sip:UserB@110.111.112.113>
    Contact: tel: +1-972-555-2222
    Content-Length: ...
    bei Annahme durch den Registrierungsserver "server2.wcom.com" veranlassen, daß weitere Sitzungen, die an diesen Benutzer adressiert sind (d.h. weitere INVITE-Nachrichten, die im „To"-Kopffeld die Kennung „UserB@there.com" angeben), gleichzeitig an beide Kontaktpunkte, die in der REGISTER-Nachricht spezifiziert wurden, übermittelt werden: zu der SIP-Anwendung im Host mit der IP-Addr (Internet protokolladresse) 110.111.112.113, bei der sich der Benutzer als „UserB" eingeloggt hat, und zu der Telefonnummer „+1-972-555-2222".
  • Allerdings hat die Anpassung und Anwendung des SIP-Protokolls an die spezielle Architektur des IMS in 3G-Systemen diese Möglichkeit blockiert, wie aus der 3GPP-Spezifikation ersichtlich ist, in der die Signalisierungsabläufe für IM-Benutzer (TS 24.228, V1.0.0, Juni 2001) aufgeführt sind. In dieser Spezifikation wird festgelegt, daß der Inhalt des „Kontakt"-Kopffeldes die IP-Addr sein muß, die das Endgerät benutzt, um Zugriff zu dem 3G-System zu haben (d.h. die IP-Adresse, die das Endgerät während des Vorgangs erhielt, den es zum Erhalt eines funkträgerpaket-basierten, bekannt als PDP (Paketdatenprotokoll), Context Establishment Process durchlief, mit anderen Worten die Adresse, die es zum Austausch von Paketen mit dem Server verwendet, der für dessen Zugriff auf das System sorgt.
  • Mit dieser Einschränkung kann ein gegebener Benutzer, der eine einzige IM-Teilnahmeberechtigung in einem 3G-System hält, gleichzeitig nur eine aktive Registrierung haben, wobei diese Registrierung bezogen ist auf nur einen Zugangspunkt zu dem System und auf nur ein Endgerät, das mit diesem Zugangspunkt verknüpft ist und von einer einzigen Adresse (IP-Addr) identifiziert wird.
  • Gemäß dem Stand der Technik wäre demnach ein Benutzer, der den Wunsch nach mehrfachen aktiven Registrierungen in einem dieser Mobilsysteme (2G, 3G) hat, welche eine Informationsverwaltung bezogen auf den Aufenthaltsort des Benutzers für eine dieser Registrierungen sowie eine Informationsverwaltung bezogen auf die Identifikationen, die den Benutzer in diesem System adressieren und identifizieren, erforderlich machen, gezwungen, mehrere Teilnahmeberechtigungen zu halten. Da jedoch jede individuelle Teilnahmeberechtigung in diesen Systemen separat gehalten wird, was eine separate Verarbeitung und Verwaltung impliziert (d.h. separate Abrechnungsdatensätze, separate Teilnahmedatensätze, separate Aufenthaltsortdatensätze etc.), würde dies Schwierigkeiten für den Betreiber des mobilen Systems dahingehend bedeuten, dieselben öffentliche(n) ID(s) bezogen auf denselben Benutzer mehr als einer Teilnahmeberechtigung zuzuordnen, ganz zu schweigen von der Unannehmlichkeit für den Benutzer, der sich mit mehreren Rechnungen für denselben Dienst befassen muß.
  • Es wäre dann eine Situation wünschenswert, in der, ohne auf eine Lösung zurückgreifen zu müssen, die auf mehrfachen Teilnahmeberechtigungen pro Benutzer basiert, es einem Benutzer, der eine einzige Teilnahmeberechtigung in einem Telekommunikationssystem (z.B. ein Mobilsystem oder ein anderes Telekommunikationssystem mit ähnlichen Charakteristika, was die Benutzerkennungen und die Aufenthaltsortinformationen betrifft) hat, möglich ist, sich in diesem System von verschiedenen Endgeräten aus gleichzeitig anzumelden, so daß mehrfache Registrierungen gleichzeitig aktiv sind, und in der dieser Benutzer Anrufe von anderen Parteien, die eine dieser einzigen Teilnahmeberechtigung zugeordnete öffentliche ID „gewählt" haben, in einem dieser registrierten Endgeräte empfangen kann.
  • Die US-A-5943620 offenbart ein Verfahren zur Handhabung mehrfacher Registrierungen eines Benutzers in einem Telekommunikationssystem. Bei diesem Verfahren wird jede öffentliche Kennung des Benutzers automatisch durch eine Registrierungsanforderung registriert, die eine private Kennung des Benutzers enthält, so daß jede weitere Kommunikationsanforderung an eine dieser öffentlichen Kennungen an eines der registrierten Endgeräte adressiert wird. Allerdings kann es vorkommen, daß ein Benutzer ein Endgerät für eine einzige seiner öffentlichen Kennungen registrieren möchte.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die vorliegende Erfindung stellt ein Verfahren zur Unterstützung mehrfacher aktiver Registrierungen mindestens eines Benutzers in einem Telekommunikationssystem bereit, wobei diese Registrierungen auf eine einzige Teilnahmeberechtigung des Benutzers in diesem System bezogen sind und wobei jede aus einer Mehrzahl von Endgeräten (Benutzergeräte oder UE) angefordert wird. Die Erfindung betrifft ferner ein System, das zur Implementierung dieses Verfahrens angeordnet ist.
  • Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verfahren zum Handhaben mehrfacher Registrierungen eines Benutzers gemäß Anspruch 1 bereitgestellt.
  • Gemäß einem weiteren Aspekt der Erfindung wird ein Telekommunikationssystem zum Handhaben mehrfacher Registrierungen einer einzigen Teilnahmeberechtigung in diesem System gemäß Anspruch 15 bereitgestellt.
  • Gemäß einer bevorzugten Ausführungsform dieser Erfindung umfaßt das Telekommunikationssystem ein oder mehrere funktionelle Servereinrichtungen, die für verschiedene Funktionen verantwortlich sind, z.B.:
    • – Speichern der Teilnehmerdaten der Benutzer des Systems (auch bezeichnet als Heimatservereinrichtung oder HSS, HLR),
    • – Bereitstellten des Zugriffs auf das System zu den Endgeräten (UEs), die von dessen Benutzern benutzt werden (auch bezeichnet als Erstkontaktpunkt-Server-Einrichtung oder Proxy Call State Control Function, P-CSCF),
    • – Bereitstellen der Erstabwicklung von Transaktionen, die Benutzer des Systems involvieren (auch bezeichnet als Anfrage-Server-Einrichtung oder Interrogating Call State Control Function, I-CSCF), und
    • – Bereitstellen von Sitzungssteuerungsdiensten für Sitzungen, die Benutzer des Systems involvieren (auch bezeichnet als Sitzungssteuerung-Server-Einrichtung oder Proxy Call State Control Function, Serving Call State Control Function, S-CSCF).
  • Werden diese Funktionen von einer einzigen Servereinrichtung oder von mehreren verteilten oder von funktionellen Server-Hostings durchgeführt, so wird der Umfang der vorliegenden Erfindung hiervon nicht berührt.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Merkmale, Ziele und Vorteile der Erfindung werden durch das Lesen dieser Beschreibung in Verbindung mit den beiliegenden Zeichnungen deutlich.
  • 1 zeigt das 1:N-Verhältnis zwischen privaten und öffentlichen Kennungen gemäß dem Stand der Technik zeigt, und das 1:1-Verhältnis zwischen einer IM-Benutzerteilnahmeberechtigung und deren privater Kennung, wie sie durch den obengenannten 3GPP-Standard TS 23.228 definiert ist.
  • 2 zeigt einen Registrierungsablauf und einen weiteren Sitzungsaufbauablauf einer eingehenden Sitzung, wie sie derzeit durch 3GPP-Standards definiert ist.
  • 3 zeigt eine vereinfachte Ansicht der Teilnehmerdatenregister in einem Heimatserver gemäß dem Stand der Technik, der sämtliche Teilnehmerdaten eines gegebenen Benutzers speichert, wobei der Inhalt eines dieser Register detaillierter gezeigt ist.
  • 4 zeigt ein N:N-Verhältnis zwischen öffentlichen und privaten Kennungen und ein 1:M-Verhältnis zwischen einer IM-Benutzerteilnahmeberechtigung und den privaten Kennungen für diese Benutzerteilnahmeberechtigung gemäß der vorliegenden Erfindung.
  • 5 zeigt einen mehrfachen Registrierungsablauf gemäß der vorliegenden Erfindung.
  • 6 zeigt dieselbe Ansicht wie 3 gemäß der vorliegenden Erfindung.
  • 7 zeigt die Datenspeicherung in verschiedenen Servern gemäß einem fakultativen Merkmal dieser Erfindung.
  • 8 zeigt einen mehrfachen Sitzungsaufbauablauf gemäß dieser Erfindung.
  • AUFÜHRLICHE BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
  • Die Erfindung soll nun ausführlich anhand der 1 bis 8 gemäß einer bevorzugten Ausführungsform beschrieben werden. Diese bevorzugte Ausführungsform zieht als Beispiel eines Telekommunikationssystems, bei dem die Verfahren gemäß dieser Erfindung Anwendung finden können, ein 3G-Mobilsystem in Betracht, das das sogenannte (IMS) (Internet Protocol Multimedia Subsystem) implementiert, in welchem (als Standard von 3GPP) das bekannte SIP-Protokol (Session Initiation Protocol) das Protokoll ist, das zur Abwicklung von Benutzerregistrierungen sowie zur Sitzungssteuerung von Benutzern mit IM-Teilnahmeberechtigungen verwendet wird.
  • Es versteht sich, daß der Umfang der vorliegenden Erfindung weder auf diese 3G-Systeme noch auf ein spezifisches Signalisierungsprotokoll beschränkt ist, und daß sie von einem Fachmann in jedem Telekommunikationssystem angewendet werden kann, welches Daten (im folgenden als Teilnehmerdaten oder SD (Subscriber Data) bezeichnet) zu verwalten hat, die mindestens auf einen Benutzer bezogen sind, der eine Teilnahmeberechtigung in diesem System hält, wobei die SD (Teilnehmerdaten) mindestens Informationen umfassen, die sich auf die Identifikationen beziehen, welche in diesem System zur Identifizierung und Lokalisierung dieses Benutzers (private ID, öffentliche ID) verwendet werden, und welches Daten zu verwalten hat, die auf den Aufenthaltsort des Benutzers bezogen sind.
  • Dieses Telekommunikationssystem kann (ist hierauf nicht beschränkt bzw. muß nicht) beispielsweise ein oder mehr funktionelle Servereinrichtungen umfassen, die für verschiedenartige spezialisierte Funktionen verantwortlich sind, z.B. das Speichern der Teilnehmerdaten der Benutzer in diesem System, das Bereitstellen des Zugriffs auf das System zu den Endgeräten (UEs), die von den Benutzern benutzt werden, das Bereitstellen der Erstabwicklung von Transaktionen, die Benutzer des Systems involvieren und das Bereitstellen von Sitzungssteuerungsdiensten für Sitzungen, die die Benutzer des Systems involvieren, wobei der Umfang der vorliegenden Erfindung nicht berührt wird, wenn diese Funktionen von einer einzigen Servereinrichtung oder von mehreren verteilten oder von funktionellen Server-Hostings durchgeführt werden. Insbesondere wird der Umfang der vorliegenden Erfindung nicht durch Aspekte berührt, gemäß denen diese funktionellen Servereinrichtungen in separaten physikalischen Einrichtungen (d.h. Geräte, Knoten, Server) implementiert sind, oder aber lediglich als funktionelle Einrichtungen implementiert sind, nämlich entweder als Server-Hostings oder aber auf unterschiedliche physikalische Einrichtungen verteilt, oder durch Aspekte betreffend Details des Interconnection-Netzes (bzw. der Interconnection-Netze), welches diese Servereinrichtungen (sofern diese in separaten physikalischen Einrichtungen implementiert sind) verknüpft, oder durch Aspekte betreffend Details der von den Benutzerendgeräten UE(s) verwendeten Zugriffstechnologie zum Zugriff auf das System.
  • Das Telekommunikationssystem gemäß der im folgenden beschriebenen bevorzugten Ausführungsform ist zur Verwaltung von Teilnehmerdaten (SD) angeordnet, die zumindest auf einen Benutzer bezogen sind, der eine Teilnahmeberechtigung in diesem System hält. Diese Teilnehmerdaten (SD) umfassen mindestens Informationen bezogen auf die in diesem System verwendeten Identifikationen zur Identifizierung und Lokalisierung des Benutzers (private ID, öffentliche ID) sowie Informationen bezogen auf den Aufenthaltsort des Benutzers (LOCATION DATA). Das Telekommunikationssystem umfaßt ferner die folgenden funktionellen Servereinrichtungen:
    eine Heimatservereinrichtung (HSS/HLR) verantwortlich für das Speichern der Teilnehmerdaten der Benutzers in dem System;
    eine Erstkontaktpunkt-Server-Einrichtung (im Rahmen dieser Erfindung als Proxy-Call State Control Function oder P-CSCF bezeichnet) verantwortlich für das Bereitstellen von Zugriff auf das System zu den von dessen Benutzern benutzten Endgeräten (UEs);
    eine Anfrage-Server-Einrichtung (im Rahmen dieser Erfindung als Interrogating-Call State Control Function oder I-CSCF bezeichnet) verantwortlich für die Erstabwicklung von Transaktionen, die Benutzer des Systems involvieren; und
    eine Sitzungssteuerung-Server-Einrichtung (im Rahmen dieser Erfindung als Serving-Call State Control Function oder S-CSCF bezeichnet) verantwortlich für Sitzungssteuerungsdienste für Sitzungen, die Benutzer des Systems involvieren.
  • Die 3GPP-Spezifikation TS 23.002 (V5.2.0, April 2001) definiert die allgemeine Netzarchitektur eines 3G-Systems, umfassend die grundlegenden Einrichtungen sowie die spezifischen Einrichtungen, die Teil des oben definierten IMS bilden (P-CSCF, I-CSCF, S-CSCF, HSS/HLR), während allgemeine und detaillierte Signalisierungsabläufe jeweils in den oben angegebenen Spezifikationen TS 23.228 und TS 24.228 beschrieben sind. Der ausführliche Inhalt der Nachrichten (Anfragen, Antworten, Mitteilungen etc.), die durch den sogenannten „CX-Referenzpunkt" zwischen den sogenannten Verbindungszustand-Steuerfunktionen (Call State Control Functions oder CSCF) und der HSS ausgetauscht werden, ist in der 3GPP-Spezifikation TS 29.228 (V0.1.0, Juni 2001) ausführlicher beschrieben. Gemäß den in den 3GPP-Spezifikationen für IMS (über dessen derzeitige Versionen) offenbarten Informationen wird das SIP-Protokoll zur Abwicklung von Benutzerregistrierungen verwendet sowie zur Sitzungssteuerung für Benutzer, die IM-Teilnahmeberechtigungen halten, und das DIAMETER-Protokoll (IETF-Draft) wird als der „CX-Referenzpunkt" verwendet.
  • An diesem Punkt sei angemerkt, daß – gemäß den 3GPP-Spezifikationen für IMS – auf die unterschiedlichen Verbindungszustand-Steuerfunktionen, (oder CSCF) unabhängig von ihrer Funktion (ob P-CSCF, I-CSCF oder S-CSCF), mit deren individuellen Namen verwiesen wird (wie beispielsweise ersichtlich ist aus den Signalisierungsabläufen, die in der obengenannten 3GPP-Spezifikation ausführlich dargestellt sind). Da diese individuellen Namen (z.B. ein SIP-URL) (beispielsweise durch Verwendung eines Domänennamensystems, DNS, oder einer ähnlichen Technik) in entsprechende individuelle Adressen (z.B. eine Internetprotokoladresse) aufgelöst werden müssen, enthalten sie für gewöhnlich einen Domänenteil zum Identifizieren des Netzbereiches des 3G-Systembetreibers, zu dem sie gehören. Ein Name wie „X-CSCF1.ZZZ.NET" beispielsweise, wobei das „X" für eine Funktion aus Proxy (P), Anfrage (I) oder Bereitstellen (S) steht, steht innerhalb der Domäne „ZZZ.NET" für X-CSCF mit dem Namen „X-CSCF1" (d.h. er wird so von anderen CSCFs mit gleichen Namen unterschieden, gehört aber zu anderen Domänen). Wo immer in dieser Erfindung ein gegebener CSCF-Name (z.B. „P-CSCF2", „S-CSCF1" etc.) angegeben ist, versteht es sich demgemäß, daß diese Namen auch einen Domänenteil in ihrem Namen enthalten können, obgleich sie bei einigen Beispielen im Rahmen dieser Erfindung nicht gezeigt sind. Es ist ein relevanter Aspekt, daß diese Namen eine gegebene CSCF innerhalb eines gegebenen Netzbereiches eindeutig idendifizieren.
  • Zum besseren Verständnis der im Rahmen dieser Erfindung beschriebenen neuartigen Verfahren und Systemanordnungen wird nunmehr auf die 1 bis 3 Bezug genommen, um die Abwicklung einer Registrierungsprozedur gemäß dem Stand der Technik in einem 3G-System eines gegebenen Benutzers (IM-Benutzer) zu zeigen, der eine einzige Teilnahmeberechtigung (IM-Teilnahmeberechtigung) in diesem System hält, sowie die Abwicklung weiterer eingehender Sitzungen, die an den Benutzer adressiert sind.
  • 1, Schritte 1 bis 10 zeigt insbesondere einen vereinfachten Signalisierungsablauf eines Registrierungsprozesses, der von einem gegebenen IM-Benutzer von einem gegebenen Endgerät UE aus in einem 3G-System als Ergebnis des Bearbeitens einer Registrierungsanforderung REGISTER durch die Bearbeitungsmittel in den in dieser Figur gezeigten Einrichtungen angefordert wird: P-CSCF, I-CSCF, HSS, S-CSCF. Details betreffend den kompletten Ablauf können den obengenannten 3GPP-Spezifikationen TS 23.228 und 24.228 entnommen werden, wobei Aspekte, die den Umfang dieser Erfindung nicht berühren, ausführlicher dargestellt sind, z.B. den Prozess, den das registrierende UE zum Erhalt eines funkträgerpaketbasierten (PDP-Kontextaufbau) P-CSCF-Discovery durchläuft, Details, ob sich der Benutzer aus einem 3G-System (besuchtes System) registriert, welches nicht das 3G-System ist, für welches der Benutzer die Teilnahmeberechtigung (Heimatsystem) hat, etc.. Diesbezüglich, und der Einfachheit halber, sei angemerkt, daß – in der 2 – Authentifizierungsunterabläufe (die in dieser Phase ablaufen könnten) ebenfalls weggelassen wurden. Diese Authentifizierungsunterabläufe könnten beispielsweise in einem Frage-Anwortmechanismus (oder einem anderen bekannten Authentifizierungsmechanismus) bestehen, und könnten aus einer „Authentifizierungsfrage" und der nachfolgenden „Antwort" auf diese Frage bestehen, die zwischen den bedienenden Einrichtungen in dem 3G und dem registrierenden Endgerät ausgetauscht werden. Auf jeden Fall wird das Verständnis des in dieser Figur gezeigten Ablaufes gemäß dem Stand der Technik durch die Anwendbarkeit oder Nicht-Anwendbarkeit dieses Authentifizierungsteilablaufes in bezug auf die Abwandlungen, die von der vorliegenden Erfindung eingeführt und später erläutert werden, nicht berührt.
  • In Schritt 1 gemäß der 2 sendet der Benutzer eine Registrierungsanforderung REGISTER vom Endgerät UE an die Erstkontaktpunkt-Server-Einrichtung P-CSCF, die den Zugriff des Endgerätes auf dieses System bereitstellt. Die Prozedur ermöglicht sowohl dem UE als auch der P-CSCF, die gegenseitigen Adressen (IP-Addr) kennenzulernen, was dem Stand der Technik entspricht.
  • Die von dem UE gesendete REGISTER enthält neben anderen Daten einige Identifikationsdaten, die (wie in dem in der 1 gezeigten Verhältnis angegeben) von dem System verwendet werden, um die Identifikationsdaten, die zu der individuellen Teilnahmeberechtigung gehören, zu identifizieren und authentifizieren, und somit den Benutzer, der die Teilnahmeberechtigung besitzt, zu identifizieren und authentifizieren. Insbesondere muß diese Registrierungsanforderung REGISTER (neben anderen Daten) die private ID enthalten, die der Teilnahmeberechtigung zugeordnet ist, und eine öffentliche ID aus einer Mehrzahl von öffentlichen IDs, die der Teilnahmeberechtigung zugeordnet sind, da diese Informationen zur Identifizierung der Teilnahmeberechtigung des Benutzers erforderlich sind, um damit das entsprechende der einzigen Teilnahmeberechtigung des Benutzers zugehörige SD-Register aus der Mehrzahl von SD-Registern, die zu in der HSS gespeicherten anderen Teilnahmeberechtigungen gehören (wie in 3 gezeigt) auf diese Heimatservereinrichtung (HSS) abzustimmen. Es gilt zu beachten, daß der Einschluß dieser privaten ID (und selbst der Einschluß dieser öffentlichen ID) in der REGISTER – gemäß einigen UEs nach dem Stand der Technik – ein automatischer Prozeß sein kann, der von der in dem UE laufenden Anwendung durchgeführt wird, wobei diese Daten aus der in besagtem UE enthaltenen USIM extrahiert werden.
  • Wenn die Registrierungsanforderung REGISTER bei der Erstkontaktpunkt-Server-Einrichtung P-CSCF ankommt, verknüpft die P-CSCF dann die Adresse des registrierenden UEs mit der öffentlichen ID, die in der REGISTER empfangen wird, und, in Schritt 2 gemäß 2, sendet sodann die REGISTER an eine Anfrageservereinrichtung I-CSCF, wobei von der P-CSCF Informationen hinzugefügt wurden, die auf sie selbst als die Erstkontaktpunkt-Server-Einrichtung P-CSCF, die den Zugriff des UEs bereitstellt, bezogen sind. Vor dem Weiterleiten führt die P-CSCF eine Anfrage bei dem DNS (Domänennamesystem) durch, um die korrekte Anfrageservereinrichtung I-CSCF zu bestimmen, an die die REGISTER weiterzuleiten ist.
  • Sobald die Registrierungsanfrage REGISTER bei der I-CSCF ankommt, wird in Schritt 3 eine Anfrage bei der HSS gemacht, um den Benutzerregistrierungsstatus CX-Query zu bestimmen. Diese Anfrage umfaßt beiden Daten, nämlich sowohl die öffentliche ID als auch die private ID, die in der REGISTER empfangen werden und die von der HSS dazu benutzt werden, um das entsprechende SD-Register des Benutzers herauszufinden. Es sei an diesem Punkt angemerkt, daß Implementierungsdetails betreffend das SD-Register (z.B. ob es sich um ein einziges Register handelt, oder um mehrere verwandte/verknüpfte Register pro Benutzerteilnahmeberechtigung, oder sogar ob diese Register in der HSS zu finden sind oder in einer anderen Datenbank) für das Verständnis des Standes der Technik oder für den Umfang der vorliegenden Erfindung nicht relevant sind. Bei diesem Aspekt ist es relevant, daß die Teilnehmerdaten (SD) einer gegebenen Teilnahmeberechtigung bezogen auf einen gegebenen Benutzer unterschieden werden zwischen anderen SDs, die zu anderen Teilnahmeberechtigungen anderer Benutzer gehören. Diesbezüglich zeigt die 3 eine vereinfachte schematische Ansicht der Speichermittel, die SD von einer Mehrzahl von Benutzern enthalten. Insbesondere zeigt die 3 ausführlicher den Inhalt eines gegebenen SD-Registers, das zu der Teilnahmeberechtigung eines gegebenen Benutzers (in der Figur als USER-N dargestellt) in einem 3G-System gehört, wobei die in diesem Register gespeicherten Daten gemäß ihrer Eigenschaften und ihrer Funktionalität logisch in verschiedene Datenklassen gruppiert worden sind.
  • Allerdings können diese Daten in einer anderen Weise geordnet und/oder gruppiert vorliegen. Gemäß 3 umfassen unter „IDENTIFIKATIONSDATEN" gespeicherte Daten statistische Informationen bezogen auf Benutzerkennungen. Neben anderen Daten umfassen diese Identifikationsdaten die öffentliche ID (bzw. die Mehrzahl von öffentlichen IDs), die einer einzigen Teilnahmeberechtigung eines gegebenen Benutzers zugeordnet sind (in der Figur als „User-N_PUBLIC1", „User-N_PUBLIC2", ..., dargestellt), sowie die einzige (eindeutige) private ID, die dieser einzigen Teilnahmeberechtigung zugeordnet ist (in der Figur als „User-N_PRIVATE" dargestellt). Gemäß 3 speichern die Daten unter „Aufenthaltsortdaten" Informationen bezogen auf den Server, der eine aktive Registrierung des Benutzers bereitstellt (falls vorhanden), die voll dynamische Eigenschaften aufweisen, im Gegensatz zur statischen Eigenschaft der unter Identifikationsdaten angegebenen Informationen. Als Teil derselben SD können andere Daten gespeichert sein (z.B. Daten bezogen auf das Profil bzw. die Profile des Benutzers dieser Teilnahmeberechtigung, Zusatzdienste für den Aktivierungsstatus, Zusatzdienste für zusätzliche Daten, etc.), die in der 3 nicht näher gezeigt sind, da sie außerhalb des Umfangs der vorliegenden Erfindung liegen.
  • Nach der in Schritt 3 gemäß 2 empfangenen Anfrage, und sobald das entsprechende SD-Register aufgefunden wurde, führt die HSS eine Überprüfung in den Aufenthaltsortdaten des SD-Registers durch, um zu prüfen, ob bereits eine aktive Registrierung für die empfangene private ID „User-N_PRIVATE" vorliegt. Wenn in diesem Schritt gemäß dem Stand der Technik in der HSS erkannt wird, daß eine aktive Registrierung vorliegt (d.h., daß die Aufenthaltsdatenbank nicht leer ist), wird eine Wiederregistrierung in Betracht gezogen, und die HSS antwortet dann in Schritt 4 mit einer Registrierungsstatus-Anfrage-Antwort CX-Query Resp zurück, die Informationen enthält, bezogen auf den Sitzungssteuerungsserver S-CSCF, der für das Bereitstellen von Sitzungssteuerungsdiensten für den Benutzer verantwortlich ist (z.B. „S-CSCF1.HOME1.NET"), zusammen mit einer Registrierungsstatusanzeige, die angibt, daß der Benutzer bereits registriert ist. Ansonsten (d.h. die Aufenthaltsortdatenbank ist leer) umfaßt die in Schritt 4 gesendete Registrierungsstatus-Anfrage-Antwort (CX-Query Resp) eine Registrierungsstatusanzeige, die angibt, daß der Benutzer nicht registriert ist, zusammen (optional) mit den Fähigkeiten zur Aus wahl einer gegebenen S-CSCF, die zugeordnet werden soll, um die Sitzungssteuerungsdienste für den Benutzer bereitzustellen.
  • Ist der Benutzer bereits registriert (z.B. Wiederregistrierung), so leitet die I-CSCF in Schritt 5 die REGISTER an die S-CSCF weiter, die von der HSS angegeben wurde. Ansonsten, wenn der Benutzer nicht registriert ist, wählt sie dann eine S-CSCF aus und leitet in Schritt 5 die REGISTER an diese S-CSCF weiter.
  • Wenn die S-CSCF die REGISTER empfängt, speichert sie die darin enthaltenen Informationen ab. Insbesondere speichert sie die empfangene private ID und die öffentliche ID des sich registrierenden Benutzers sowie Informationen bezogen auf die P-CSCF, die den Zugriff des UE, von dem aus die Registrierung angefordert wurde, bereitstellt. In Schritt 6 teilt die S-CSCF dann der HSS mit, daß der Benutzer in der S-CSCF (CX-Put) registriert worden ist, wobei diese Mitteilung die in der REGISTER empfangene private ID und die öffentliche ID sowie Informationen bezogen auf die S-CSCF und ein „Server-Zuordnungstyp"-Feld mit der Angabe „Registrierung" umfaßt.
  • Nach Empfang dieser Mitteilung findet die HSS das entsprechende SD-Register für den Benutzer (z.B. mittels Durchführung einer Suche aufgrund der privaten und/oder öffentlichen ID) und speichert in den Aufenthaltsdaten dieses SD-Registers Informationen, die angeben, daß die S-CSCF Sitzungssteuerungsdienste für den Benutzer bereitstellt (z.B. „S-CSCF1.HOME1.NET"). Es gilt hier zu beachten, daß – wie aus dem in der 3 dargestellten Stand der Technik ersichtlich – nur eine Registrierung zu einem gegebenen Zeitpunkt für eine gegebene Benutzerteilnahmeberechtigung aktiv sein kann. Deshalb kann zu einem gegebenen Zeitpunkt nur ein Eintrag innerhalb der Aufenthaltsortdaten eines gegebenen SD-Registers existieren (z.B. ein Eintrag wie der Eintrag „S-CSCF1.HOME1.NET {User-N_PUBLIC2, User-N_PRIVATE}", der in der 3 für USER-N gezeigt ist). Hieraus ergibt sich, daß jeder in den Aufenthaltsdaten zuvor gespeicherte Eintrag bei Empfang einer Registermitteilung in der HSS überschrieben wird (CX-Put).
  • Als nächstes gibt die HSS in Schritt 7 das Ergebnis der Registrierung in der HSS (angenommen oder zurückgewiesen) zusammen mit den Daten bezogen auf das Benutzerprofil des sich registrierenden Benutzers (CX-Put Resp.) der S-CSCF zurück. War das Ergebnis der Registrierung erfolgreich, wird eine Registrierungsantwort (200 OK) in den Schritten 8, 9 und 10 an das UE, von dem aus die Registrierung angefordert wurde, zurückgesendet.
  • Sobald sich ein gegebener Benutzer erfolgreich im 3G-System registriert hat, werden weitere eingehende Sitzungen (d.h. Fernsprechrufe, Multimedia-Verbindungen etc.), die an die öffentliche ID des Benutzers adressiert sind, die in der Registrierungsanforderung REGISTER angegeben sind, an das UE weitergeleitet, welches über die gewährte Registrierung verfügt. Diese Weiterleitung erfolgt über die S-CSCF, die in dieser Registrierung zugeordnet wurde, sowie über die P-CSCF, die den Zugrang auf das Endgerät in dem 3G-System bereitgestellt hat und die die Registrierung bereitgestellt hat.
  • Die Abwicklung eines Sitzungsaufbaus zu einem gegebenen registrierten Benutzer gemäß dem Stand der Technik, als Ergebnis der Bearbeitung einer Sitzungsanforderung (INVITE) durch die Verarbeitungsmittel in den in dieser Figur dargestellten Einrichtungen (P-CSCF, I-CSCF, HSS, S-CSCF) wird nun anhand der 2 in den Schritten 11 bis 16 beschrieben. Gleichzeitig soll mit der 3 ein konkreterer Fall dargestellt werden, in dem ein gegebener Benutzer (USER-N), der sich durch Verwendung seiner/ihrer privaten ID (User-N_PRIVATE) sowie einer seiner/ihrer öffentlichen IDs (User-N_PUBLIC2) erfolgreich registriert hat, eine eingehende Sitzung empfängt.
  • In Schritt 11 kommt eine an den USER-N adressierte Sitzungsanforderung (INVITE) in einer I-CSCF an. Von wo aus diese INVITE in der I-CSCF empfangen wird, hängt vom Standort des Sitzungsabsenders ab. Hat beispielsweise jemand im PSTN eine Verbindung durch Wählen von „User-N_PUBLIC2" erzeugt (wobei angenommen wird, daß dieses „User-N_PUBLIC2" im Format einer E.164-Nummer vorliegt), so kommt diese INVITE in der I-CSCF von einer Medien-Gateway-Steuerfunktion (Media Gateway Control Function – MGCF) aus an, die – neben anderen Aufgaben – für das Übersetzen von Signalisierungsprotokollen, die in anderen Telekommunikationssystemen verwendet werden (z.B. die Signalisierungssystem nummer 7) in das Signalisierungsprotokoll verantwortlich ist, das in 3G-Systemen für Multimedia-Sitzungen verwendet wird, in denen IM-Benutzer involviert sind. Der Sitzungsabsender könnte sich z.B. innerhalb eines 3G-Systems befinden. In diesem Fall hat ein anderer Benutzer von seinem/ihrem Endgerät aus eine INVITE gesendet, die im „To"-Kopffeld die Kennung „User-N_PUBLIC2" angibt. In diesem Fall kann die INVITE in der I-CSCF von der S-CSCF aus ankommen, die dem Sitzungsabsender zugeordnet ist.
  • In jedem Fall sind der Aufenthaltsort des Sitzungsabsenders sowie die Signalisierungsabläufe oder Details vor dem Ankommen dieser INVITE in der I-CSCF nicht für das Verständnis des Standes der Technik gemäß 2 noch für die Abwandlungen relevant, die von der vorliegenden Erfindung in diesen Stand der Technik eingeführt werden und die weiter unten erläutert werden.
  • Die I-CSCF sendet dann gemäß Schritt 12 eine Aufenthaltsortanfrage (CX-Location Query) an die HSS, um die S-CSCF herauszufinden, die zur Bereitstellung der Sitzungssteuerungsdienste für den angerufenen Benutzer zugeordnet ist, wobei diese Anfrage die in der INVITE empfangene öffentliche ID (z.B. User-N_PUBLIC2) zum Identifizieren des angerufenen Benutzers in der HSS umfaßt. Die HSS lokalisiert dann das entsprechende SD-Register des angerufenen Benutzers (USER-N), welches zu der öffentlichen ID paßt, und findet heraus, daß eine diesem Benutzer zugeordnete S-CSCF existiert (z.B. „S-CSCF1.HOME1.NET"). In einem Schritt 13 sendet die HSS eine Aufenthaltsort-Anfrage-Antwort (CX-Location Query Resp) zurück, die Informationen bezogen auf die S-CSCF enthält.
  • Nach Empfang der Aufenthaltsort-Anfrage-Antwort, leitet die I-CSCF in Schritt 14 die INVITE weiter an die von der HSS angegebene S-CSCF. Die S-CSCF such dann in den gespeicherten Informationen bezogen auf P-CSCFs nach der bestimmten P-CSCF, mittels derer eine Registrierung angefordert (REGISTER) und gewährt wurde (200 OK), die die in der INVITE angegebene öffentliche ID enthielt, und leitet die INVITE in Schritt 15 dorthin. Nach Empfang der INVITE in der P-CSCF wird eine ähnliche Prozedur durchgeführt, um in der P-CSCF die Adresse (IP-Addr) des Endgerätes (UE) herauszufinden, dem eine Registrierung unter Angabe der öf fentlichen ID gewährt wurde, und in Schritt 16 leitet sie die empfangene INVITE an das UE.
  • Ein in einem 3G-System registrierter gegebener Benutzer kann aus diesem System deregistriert werden, entweder auf Anforderung des Benutzers von dem registrierten Endgerät aus (benutzerinitiierte Deregistrierung) oder aufgrund einer Entscheidung des 3G-Systems (netzinitiierte Deregistrierung). Deregistrierungsprozeduren gemäß dem Stand der Technik, entweder benutzerinitiierte oder netzinitiierte Deregistrierungen, bewirken ein Löschen der Aufenthaltsortdaten, die im SD-Register gespeichert und dem Benutzer zugeordnet sind, d.h. die in der 3 gezeigten „LOCATION DATA" des USER-N werden geleert, da – wie oben erwähnt – nur ein Eintrag in den Aufenthaltsortdaten existiert. Eine benutzerinitiierte oder netzinitiierte Deregistrierung bewirkt ebenso die Löschung von Daten, die zuvor in der die Registrierung bereitstellenden S-CSCF und in der P-CSCF eingebunden waren. Somit wird in der S-CSCF die zuvor gespeicherte Information gelöscht, die die öffentlichen und die privaten IDs verbunden hatte, die bei der Registrierung in der P-CSCF verwendet wurden, die den Zugriff auf die Registrierung bereitstellte. Ähnlich werden die zuvor in der P-CSCF gespeicherten Informationen gelöscht, die öffentliche und private IDs verbanden, welche bei der Registrierung der Adresse des UE, das die Registrierung anforderte, verwendet wurden.
  • Ein benutzerinitiiertes Deregistrierungsverfahren (in der 2 nicht dargestellt) läuft in ähnlicher Weise ab, wie die Registrierungsprozedur: Eine REGISTER wird von einem bereits registrierten UE empfangen und gibt einen Ablaufwert („Expires"-Kopffeld) von Null (0) an. Ein ähnlicher Ablauf wie der in der 2 gemäß den Schritten 1 bis 4 gezeigte wird ausgeführt, um die S-CSCF zu bestimmen, die derzeit die aktive Registrierung des Benutzers bereitstellt. Diese S-CSCF sendet dann eine Mitteilung an die HSS, mit der Angabe, daß der Benutzer aus der S-CSCF (CX-Put) deregistriert worden ist, wobei diese Mitteilung dieses Mal ein „Server-Zuordungstyp"-Feld mit der Angabe „Deregistrierung" umfaßt, zusammen mit den obengenannte Identifikationsdaten bezogen auf den deregistrierenden Benutzer and die S-CSCF.
  • Es wird nunmehr Bezug genommen auf die 4 bis 6, um ein neuartiges Verfahren und Systemanordnungen gemäß der vorliegenden Erfindung anzugeben, zum Abwickeln mehrfacher Registrierungen in einem 3G-System eines gegebenen Benutzers (IM-Benutzer), der eine einzige Teilnahmeberechtigung (IM-Teilnahmeberechtigung) in diesem System hält.
  • Für diese einzige Teilnahmeberechtigung des Benutzers werden eine Mehrzahl von privaten IDs definiert und in dem Speichermittel der HSS gespeichert, die zum Speichern der Teilnehmerdaten (SD) des Benutzers der Teilnahmeberechtigung zugeordnet ist, um es so – wie schematisch in der 4 gezeigt – der Teilnahmeberechtigung zu ermöglichen, mittels einer aus der Mehrzahl von ihr zugeordneten Kennungen berücksichtigt (d.h. registriert, angerufen) zu werden. Gemäß 4, die mit der 1 verglichen werden sollte, welche den entsprechenden Stand der Technik für denselben Sachverhalt zeigt, können mehrfache Registrierungen derselben gegebenen Teilnahmeberechtigung des Benutzers gehalten werden, vorausgesetzt, daß jede Registrierung eine unterschiedliche private ID aus der Mehrzahl von privaten IDs, die dieser zugeordnet sind, angibt („Private Benutzerkennung 1", „Private Benutzerkennung 2", „Private Benutzerkennung 3"). Dementsprechend, wie noch ausführlicher erläutert werden wird, werden weitere Sitzungen, adressiert an die öffentliche ID dieses Benutzers oder (als Implementierungsoption) an eine der öffentlichen IDs dieses Benutzers („Öffentliche Benutzerkennung 1", „Öffentliche Benutzerkennung 2") gehalten, unter In-Betracht-Ziehen der mehrfachen Registrierungen. Wie durch die in der 4 gezeigten Punkte angegeben, kann beispielsweise eine an die „Öffentliche Benutzerkennung 1" adressierte Sitzung gemäß des Registrierungsstatus der „Privaten Benutzerkennung 1" und der „Privaten Benutzerkennung 2" abgewickelt werden, während an die „Öffentliche Benutzerkennung 2" adressierte Sitzungen gemäß des Registrierungsstatus „Private Benutzerkennung 3" abgewickelt werden kann. Allerdings kann (als Implementierungsoption) jede dieser Sitzungen auch gemäß des Registrierungsstatus jeder oder sämtlicher der privaten IDs, die der Teilnahmeberechtigung zugeordnet sind, abgewickelt werden.
  • Das Mehrfach-Registrierungsverfahren in einem 3G-System eines gegebenen Benutzers, der eine einzige Teilnahmeberechtigung in diesem System hält, soll nun anhand des in der 5 dargestellten vereinfachten Signalisierungsablaufs beschrieben werden. Bezug genommen wird ebenfalls auf die 6, um einen spezifischen Fall eines gegebenen Benutzers (USER-N) als Beispiel zu verwenden. 5 zeigt insbesondere einen vereinfachten Signalisierungsablauf eines Registrierungsprozesses, der von einem gegebenen IM-Benutzer von einer Mehrzahl von Endgeräten (UE1, UE2, UE3) in einem 3G-System angefordert wird, als Ergebnis der Bearbeitung einer späteren Registrierungsanforderung (REGISTER) durch das Verarbeitungsmittel in den in der Figur dargestellten Einrichtungen (P-CSCFs, I-CSCF, HSS, S-CSCFs).
  • Wie beim zum äquivalenten Stand der Technik gemäß 2, sowie der besseren Klarheit halber, die helfen soll, die hierin beschriebenen neuartigen Aspekte hervorzuheben, zeigt die 5 keinen Authentifizierungsteilablauf. Allerdings wird der Fachmann, der beispielsweise mit den in der 3GPP-Spezifikation TS 24.228 beschriebenen detaillierten Registrierungsabläufen vertraut ist, ohne weiteres verstehen, wie die im Rahmen der Erfindung beschriebenen Verfahren gleichfalls Anwendung finden können, wenn diese Authentifizierungsprozeduren stattfinden. Beispielsweise kann bei jeder Registrierung dieser Authentifizierungsteilablauf aus zusätzlichen Nachrichten bestehen, die zwischen den in der 5 gezeigten bereitstellenden Einrichtungen und dem (den) registrierenden Endgerät(en) (z.B. ein Frage-Antwortmechanismus) ausgetauscht werden, die in der Registrierung verwendete private oder öffentliche Kennungen übermitteln könnten. In diesem Fall könnte eine „Anfrage-Antwort", die von einem registrierenden Endgerät als Ergebnis einer empfangenen „Authentifizierungsfrage" gesendet wurde, in eine neue Registrierungsanforderung REGISTER integriert werden, die – wie oben erläutert – eine private Kennung und (mindestens) eine öffentliche Kennung zum Identifizieren der bestimmten Teilnahmeberechtigung, zu der die Kennungen gehören, übermitteln müßte, obgleich hier ein anderes Verfahren verwendet werden könnte. Vorausgesetzt, daß ein Authentifizierungsvorgang (falls angewendet) stets mit einer Registrierungsanforderung assoziiert wäre, haben die Kennungen, die auf eine gegebene Teilnahmeberechtigung bezogen sind, welche in dieser Registrierungsanforderung stets angegeben sind, egal, ob der Authentifizierungsvorgang stattfindet oder nicht, keinen Einfluß auf die grundlegende Verarbeitung einer Registrierungsanforderung auf der Grundlage privater und öffentlicher Kennungen, die in dieser angegeben sind, welches ein Ziel der vorliegenden Erfindung darstellt.
  • In 6 (auf die in Verbindung mit der ausführlichen Beschreibung weiterer Aspekte dieser Erfindung Bezug genommen werden wird) zeigt eine vereinfachte schematische Ansicht des Speichermittels enthaltend SD einer Mehrzahl von Benutzern. Insbesondere zeigt 6 in größerem Detail den Inhalt des SD-Registers eines gegebenen Benutzers (USER-N), wobei, gemäß der vorliegenden Erfindung, eine Mehrzahl von privaten IDs (User-N_PRIVATE1, ... User-N_PRIVATE2, ... User-N_PRIVATE3) diesem Benutzer in bezug auf die Identifikationsdaten seiner/ihrer Teilnahmeberechtigung zugeordnet sind. Es sei darauf hingewiesen, daß, obgleich drei private IDs in diesem Beispiel dargestellt sind, eine höhere oder niedrigere Anzahl von pro Teilnahmeberechtigung zugeordneten privaten IDs einen Aspekt darstellt, der den Umfang der vorliegenden Erfindung nicht berührt. Die Identifikationsdaten dieser Teilnahmeberechtigung umfassen ebenfalls eine Mehrzahl von öffentlichen IDs (User-N_PUBLIC1, User-N_PUBLIC2), obgleich es – für den wesentlichen Umfang und das Verständnis der vorliegenden Erfindung – irrelevant ist, ob einem gegebenen Benutzer mehr als eine öffentliche ID zugeordnet ist.
  • 6 zeigt ebenfalls (im Gegensatz zur 3) daß, gemäß der vorliegenden Erfindung, die Aufenthaltsortdaten eines gegebenen SD-Registers eine Mehrzahl von Einträgen umfassen kann. Konkreter können sie Informationen bezogen auf eine Mehrzahl von S-CSCFs und eine Mehrzahl von Kennungen (private IDs, öffentliche IDs) umfassen, wobei – wie noch erläutert wird – jede in den Aufenthaltsortsdaten des SD-Registers gespeicherte S-CSCF zugeordnet wurde, um der Sitzungssteuerung in nachfolgenden Registrierungen desselben Benutzers zu dienen (der Benutzer, zu dem das SD-Register gehört), wobei diese nachfolgenden Registrierungen jeweils eine den Teilnehmerdaten des Benutzers zugeordnete unterschiedliche private ID aus der Mehrzahl von privaten IDs angeben, die den Teilnehmerdaten des Benutzers zugeordnet wurden.
  • Wie in den Schritten 1, 7 und 13 gemäß 5 gezeigt, sendet der Benutzer (USER-N) nachfolgende Registrierungsanforderungen (REGISTER) von nachfolgenden Endgeräten (UE1, UE2, UE3) über unterschiedliche P-CSCFs (P-CSCF1, P-CSCF2, P-CSCF3) mit der Angabe von mindestens einer öffentlichen ID und einer privaten ID aus der Mehrzahl von diesem Benutzer zugeordneten öffentlichen IDs und privaten IDs in jeder dieser Registrierungen. Der gemäß dieser Figur gezeigte spezielle Fall, bei dem drei Registrierungsabläufe als Beispiel abgebildet sind, soll nicht als Beschränkung des Umfangs der vorliegenden Erfindung angesehen werden, da – wie später gezeigt – die im folgenden offenbarten Verfahren Anwendung finden, wann immer mehr als eine Registrierungsanforderung für denselben Benutzer empfangen wird.
  • Es gilt zu beachten, daß es für jede in der 5 gezeigte erfolgreiche Registrierungsanforderung einen (nicht dargestellten) Registrierungsbestätigungsablauf gibt, der dem in den Schritten 7 bis 10 gemäß 2 gezeigten ähnlich ist, wobei jeder dieser Bestätigungsabläufe auf das Endgerät zurückgeht, welches die gewährte Registrierung (UE1 oder UE2 oder UE3) über die CSCFs erhält, die bei dieser gewährten Registrierung mitwirken. Aspekte, z.B. wenn dieselbe P-CSCF den Zugriff auf mehr als eines dieser UEs bereitstellt, oder sogar auf sämtliche, oder wenn eine unterschiedliche P-CSCF den Zugriff auf jedes dieser UEs bereitstellt, sind von der vorliegenden Erfindung in Betracht gezogen, wie sich aus dem folgenden ergibt.
  • Zum besseren Verständnis des Prozesses kann davon ausgegangen werden, daß der Benutzer vor dem Signalisierungsablauf gemäß 5 noch über keine aktive Registrierung verfügt, d.h. er ist noch mit keiner der diesem Benutzer zugeordneten privaten IDs registriert, so daß die Aufenthaltsortsdaten in dem SD-Register, das dem Benutzer entspricht, noch leer sind (z.B. Aufenthaltsortsdaten des USER-N gemäß 6 enthält noch keinerlei Daten).
  • Die Schritte 1 bis 3 gemäß 5 sind den äquivalenten Schritten 1 bis 3 der zuvor mit Blick auf 2 erläuterten Registrierungsanforderung ähnlich. In dem in der 3 gezeigten speziellen Fall sendet ein Endgerät (UE1) eine Registrierungsanforderung (REGISTER) über eine gegebene P-CSCF (P-CSCF1). Wie oben mit Bezug auf den Ablauf gemäß dem Stand der Technik nach 2 erwähnt, verknüpft die eine REGISTER empfangende P-CSCF die Adresse des Endgeräte mit der öffentlichen ID, die in der empfangenen REGISTER angegeben ist.
  • Nach Empfang der Registrierungsanfrage durch die I-CSCF in Schritt 3 (CX-Query) lokalisiert die HSS sodann das SD-Register des Benutzers, welches in der mit dieser Anfrage empfangenen privaten ID und der öffentlichen ID angegeben ist. Betrachtet man den obenerwähnten speziellen Fall zur Darstellung des Ablaufs, und geht man davon aus, daß die empfangene private ID eine „User-N_PRIVATE1" und die empfangene öffentliche ID eine „User-N_PUBLIC2" sind, so wird das SD-Register des USER-N aus der Mehrzahl von den Teilnahmeberechtigungen anderer Benutzer zugehörigen SD-Registern von der HSS ausgewählt. Um dieses SD-Register herauszufinden, muß die HSS keine neue Technik anwenden. Jede Recherchetechnik gemäß dem Stand der Technik basierend auf der empfangenen privaten ID und/oder der empfangenen öffentlichen ID kann zu diesem Zweck verwendet werden.
  • Sobald das SD-Register aufgefunden worden ist, wird in den Aufenthaltsortsdaten dieser SD überprüft, ob der Benutzer bereits mit der empfangenen privaten ID (User-N_PRIVATE1) registriert ist, d.h. ob bereits eine S-CSCF zugeordnet worden ist, um die Sitzungssteuerungsdienste für die empfangene private ID User-N_PRIVATE1 (d.h. einen Eintrag in den Aufenthaltsortsdaten, der die empfangene private ID enthält) bereitzustellen. Betrachtet man die oben gemachte Annahme, so sind die Aufenthaltsortsdaten in dem Register in diesem Stadium noch leer. Deshalb wird in Schritt 4 eine Registrierungsanfrage-Antwort (CX-Query Resp) an die I-CSCF gesendet, die eine Registrierungsstatusanzeige enthält, die angibt, daß der USER-N nicht mit der empfangenen privaten ID registriert ist, sowie (optional) die Fähigkeiten, die erforderlich sind zum Auswählen einer S-CSCF aus der I-CSCF, welche letztendlich die Registrierungssitzungssteuerung für weitere Sitzungen unterstützt, die den Benutzer der empfangenen privaten ID (User-N_PRIVATE1) und der öffentlichen ID (User-N_PUBLIC2) involvieren.
  • Da die Registrierungsstatusanzeige angibt, daß der sich registrierende Benutzer nicht mit der empfangenen privaten ID registriert ist, und da von der HSS in der Registrierungsanfrage-Antwort keine S-CSCF angegeben ist, wählt die I-CSCF, die Techniken zum Auswählen einer S-CSCF gemäß dem Stand der Technik verwendet, wenn von der HSS keine S-CSCF bereitgestellt wird (z.B. aufgrund der von der HSS empfangenen Fähigkeiten), eine S-CSCF aus und leitet in Schritt 5 die REGISTER weiter an die ausgewählte S-CSCF. In dem in der 5 dargestellten Beispiel ist die ausgewählte S-CSCF eine „S-CSCF1".
  • Die ausgewählte S-CSCF (S-CSCF1) speichert sodann Informationen bezogen auf die P-CSCF, die die Registrierung (P-CSCF1) bereitstellt, sowie die darin angegebenen privaten und öffentlichen IDs (User-N_PRIVATE1, User-N_PUBLIC2) und teilt in Schritt 6 der HSS mit (CX-Put), daß die S-CSCF1 Sitzungen bereitstellt, die die private ID (User-N_PRIVATE1) und die öffentliche ID (User-N_PUBLIC2) involvieren. Diese Mitteilung (CX-Put) sowie die anderen im in der 5 dargestellten Ablauf „CX-Put"-Mitteilungen umfassen die private ID und die öffentliche ID, die in der bearbeiteten REGISTER empfangen wurden, sowie Informationen bezogen auf die S-CSCF, die die „CX-Put" sendet, sowie ein „Serverzuordnungstyp"-Feld mit der Angabe „Registrierung".
  • Die HSS findet dann das entsprechende SD-Register heraus und speichert in den Aufenthaltsortsdaten dieses Registers einen neuen Eintrag, der angibt, daß diese „S-CSCF1" (in der 6 als „S-CSCF1.HOME1.NET" dargestellt) die Sitzungssteuerung für den Benutzer (USER-N) bereitstellt, und die Kennungen „User-N_PUBLIC2" und User-N_PRIVATE1" angibt (in der 6 als Aufenthaltsortsdateneintrag umfassend „S-CSCF1.HOME1.NET {User-N_PUBLIC2, User-N_PRIVATE1"} gezeigt). Als Implementierungsoption kann die HSS dafür sorgen, daß diese S-CSCF an den Benutzer adressierte Sitzungen an jede der dem Benutzer zugeordneten öffentlichen IDs bereitstellt, was weiter unten erläutert wird. Als nächstes wird die Registrierung des Benutzers (USER-N) dieses Endgerätes (UE1) gewährt („200 OK", nicht dargestellt).
  • Die Schritte 7, 8 und 9 entsprechen den oben erläuterten äquivalenten Schritten 1 bis 3. In diesem Fall wird die Registrierungsanforderung (REGISTER) von einem nachfolgenden Endgerät (UE2) über eine gegebene P-CSCF (P-CSCF2) gesendet, die sich in dem Beispiel gemäß der Figur von der vorherigen (P-CSCF1) zu unterscheiden scheint, die die Registrierungsanforderung bearbeitet hat. Dieser Un terschied kann auf mehreren Faktoren basieren, die den Umfang der vorliegenden Erfindung nicht berühren (z.B. UE1 und UE2 greifen auf dasselbe Heimat-3G-System aus unterschiedlichen besuchten 3G-Systemen zu, oder UE1 und UE2 befinden sich innerhalb desselben Systems in unterschiedlichen Aufenthaltsbereichen, von denen jeder einer unterschiedlichen P-CSCF zugeordnet ist). Da jedoch eine P-CSCF beim Weiterleiten einer Registrierungsanforderung an eine I-CSCF Informationen bezogen auf sich selbst hinzufügt (wie zuvor mit Bezug auf Schritt 2 gemäß 2 erläutert wurde), und diese Informationen von der für die Registrierung ausgewählten S-CSCF (zusammen mit den in dieser Registrierung angegebenen öffentlichen und privaten IDs) empfangen und behalten werden – im Falle mehrfacher Registrierungen für denselben Benutzer –, ist es irrelevant, ob die P-CSCF, die den Zugriff in einer nachfolgenden Registrierung bereitstellt, dieselbe oder eine unterschiedliche P-CSCF ist, im Vergleich zu der (denen), die für (eine) zuvor aktive Registrierung(en) verwendet wurden, vorausgesetzt, daß die P-CSCF eindeutig in der entsprechenden S-CSCF (die für diese nachfolgende Registrierung ausgewählte S-CSCF) als eine aktive Registrierung für eine bestimmte private ID und eine bestimmte öffentliche ID bereitstellende identifiziert wird.
  • Dem als Beispiel verwendeten vorgenannten speziellen Fall folgend kann nun davon ausgegangen werden, daß die REGISTER „User-N_PRIVATE2" als private ID und „User-N_PUBLIC1" als öffentliche ID enthält. Wenn die Registrierungsanfrage (CX-Query) gemäß Schritt 9 in der HSS empfangen wird, so wird, wie oben erläutert, das SD-Register des USER-N durch Verwendung existierender Techniken auf der Grundlage der empfangenen Kennungen identifiziert.
  • Sobald das SD-Register aufgefunden wurde, überprüft die HSS, ob die empfangene private ID („User-N_PRIVATE2") bereits in den Aufenthaltsortsdaten dieser SD enthalten ist. Ist dies der Fall, dann würde, wie oben mit Bezug auf Schritt 3 gemäß 2 erwähnt (Wiederregistrierung) die HSS in Schritt 10 mit einer Registrierungsstatusanfrage-Antwort (CX-Query Resp) umfassend Informationen bezogen auf die S-CSCF, die für das Bereitstellen von Sitzungssteuerungsdiensten für den Benutzer verantwortlich ist, zusammen mit einer Registrierungsstatusangabe, die angibt, daß der Benutzer bereits registriert ist, zurückantworten. Geht man jedoch von dem in diesem Beispiel gezeigten speziellen Fall aus, so ist die private ID („User-N_PRIVATE2") noch nicht in den Aufenthaltsortsdaten der SD enthalten. Deshalb wird in Schritt 10 eine Registrierungsanfrage-Antwort (CX-Query Resp) an die I-CSCF gesendet, welche eine Registrierungsstatusangabe enthält, die angibt, daß der USER-N nicht mit der empfangenen privaten ID registriert ist, sowie (optional) die Fähigkeiten, die erforderlich sind zum Auswählen einer S-CSCF aus der I-CSCF, welche letztendlich die Registrierungssitzungssteuerung für weitere Sitzungen unterstützt, die den Benutzer der empfangenen privaten ID (User-N_PRIVATE2) und der öffentlichen ID (User-N_PUBLIC1) involvieren.
  • Da bei dem mit Bezug auf die 5 gezeigten speziellen Fall die Aufenthaltsortsdaten des SD-Registers des USER-N in diesem Stadium nicht leer sind, kann die HSS auch der I-CSCF eine Liste zur Verfügung stellen, welche Informationen bezogen auf eine oder mehr der S-CSCF(s), die in den Aufenthaltsortsdaten angegeben sind, umfaßt. Dies kann beispielsweise nützlich sein, wann immer eine Vorgehensweise zum Zuordnen stets derselben S-CSCF an denselben Benutzer für sämtliche seiner/ihrer Registrierungen angewendet wird. In dem als Beispiel genannten speziellen Fall würde diese Liste Informationen bezogen nur auf „S-CSCF1" enthalten.
  • Da die Registrierungsstatusangabe angibt, daß der sich registrierende Benutzer nicht mit der empfangenen privaten ID registriert ist, wählt die I-CSCF sodann eine S-CSCF aus und leitet die empfangene REGISTER in Schritt 11 an diese weiter. Zum Auswählen einer S-CSCF kann die I-CSCF entweder Techniken zum Auswählen einer S-CSCF, wenn von der HSS keine S-CSCF bereitgestellt wurde (z.B. aufgrund den von der HSS empfangenen Fähigkeiten) gemäß dem Stand der Technik verwenden, oder, wenn Informationen bezogen auf eine oder mehr S-CSCFs von der HSS empfangen wurden, eine unter diesen wählen. Es versteht sich, daß der letztere Fall nützlich wäre beim Implementieren der obengenannten Vorgehensweise zum Zuordnen stets derselben S-CSCF an denselben Benutzer.
  • Bei dem in diesem Ablauf gezeigten Beispiel wurde davon ausgegangen, daß die I-CSCF beispielsweise eine S-CSCF auf der Grundlage der von der HSS empfangenen Fähigkeiten ausgewählt hat, d.h. eine von der oben angewandten sich unter scheidende Vorgehensweise wird angewendet. In dem Beispiel resultierte die Auswahl darin, daß letztendlich die „S-CSCF2" ausgewählt wurde. Es versteht sich jedoch, daß eine andere S-CSCF ausgewählt hätte werden können, die im Vergleich zu der, die dem Benutzer die vorherige Registrierung (S-CSCF1) bereitgestellt hat, dieselbe oder eine andere sein könnte, ohne den Umfang der mehrfachen Registrierungen des USER-1 und das Abwickeln der weiteren an diesen Benutzer adressierten Verbindungen für eine dieser mehrfachen Registrierungen zu berühren.
  • Die für diese Registrierung (S-CSCF2) ausgewählte S-CSCF agiert ähnlich wie die oben für die vorherige Registrierung beschriebene. Sie speichert zunächst Informationen bezogen auf die P-CSCF, die diese Registrierung bereitstellt (welche in dem als Beispiel verwendeten Fall für diese Registrierung die „P-CSCF2" ist), sowie die darin angegebenen privaten und öffentlichen IDs (User-N_PRIVATE2, User-N_PUBLIC1) und benachrichtigt (CX-Put) in Schritt 12 die HSS, daß die S-CSCF2 Sitzungen bereitstellen wird, die die private ID (User-N_PRIVATE2) und die öffentliche ID (User-N_PUBLIC1) involviert.
  • Die HSS findet das entsprechende SD-Register heraus und erstellt einen neuen Aufenthaltsortsdateneintrag in diesem SD-Register, wobei dieser neue Eintrag Informationen speichert, die angeben, daß die „S-CSCF2" (in der 6 als „S-CSCF2.HOME1.NET" dargestellt) die Sitzungssteuerung für den Benutzer (USER-N) bereitstellt, sowie die Kennungen „User-N_PUBLIC1" und User-N_PRIVATE2" angibt (in der 6 als Aufenthaltsortsdateneintrag umfassend „S-CSCF2.HOME1.NET {User-N_PUBLIC1, User-N_PRIVATE2}" gezeigt). Wie in der 6 gezeigt, und im Gegensatz zu den obengenannten Techniken gemäß dem Stand der Technik, kann beobachtet werden, daß jede für jede der privaten IDs desselben Benutzer gemachte Registrierung für die Erstellung eines neuen Aufenthaltsortdateneintrages sorgt, wobei diese Eintrag Informationen über die S-CSCF speichert, die für die Sitzungssteuerung von weiteren Sitzungen bezogen auf die Registrierung zugeordnet ist, sowie Informationen über die Kennungen (öffentliche ID, private ID), die in dieser Registrierung angegeben sind. Als obengenannte Implementierungsoption kann die HSS zu einem späteren Zeitpunkt dafür sorgen, daß eine dieser S-CSCFs Sitzungen bereitstellt, die an eine der dem Benutzer zugeordneten öffentlichen IDs adressiert sind, wie weiter unten erläutert. Als nächstes wird die Registrierung des Benutzers (USER-N) des Endgerätes (UE2) gewährt („200 OK", nicht dargestellt).
  • Für den in dem Beispiel gemäß 5 gezeigten dritten Registrierungsablauf wird die Registrierungsanforderung (REGISTER) von einem nachfolgenden Endgerät (UE3) über eine gegebene P-CSCF (P-CSCF3) gesendet, wobei, ähnlich der vorherigen Registrierung (Schritte 7 bis 12), ersichtlich ist, daß die Anforderung über eine P-CSCF erfolgt, die sich von denen unterscheidet, die in den vorangegangen Registrierungen verwendet wurden. In diesem Fall kann angenommen werden, daß die in dieser REGISTER angegebene private ID „User-N_PRIVATE3" ist und die öffentliche ID „User-N_PUBLIC2".
  • Die Schritte 13, 14 und 15 sind ähnlich den äquivalenten Schritten der vorangegangenen Registrierungen, wobei nur der Inhalt der REGISTER variiert.
  • In diesem Fall, sowie bei sämtlichen Registrierung eines Benutzers und unabhängig davon, ob der Benutzer bereits mit einer privaten ID registriert ist oder nicht, wird die HSS nach Empfang einer Registrierungsanfrage (CX-Query) in Schritt 15 zunächst das SD-Register lokalisieren, welches den in der Registrierungsanforderung empfangenen Kennungen entspricht, und dann in diesem SD-Register überprüfen, ob die in dieser Registrierungsanforderung empfangene private ID („User-N_PRIVATE3") bereits in einem der Einträge vorliegt, die in den Aufenthaltsortsdaten der SD gespeichert sind. Bei dieser nachfolgenden (dritten) Registrierung sowie bei der mit Bezug auf die Schritte 7 bis 12 beschriebenen vorangegangenen nachfolgenden (zweiten) Registrierung sind die Aufenthaltsortsdaten des SD-Registers des USER-N nicht leer, sondern enthalten in diesem speziellen Fall zwei Einträge („S-CSCF1.HOME1.NET {User-N_PUBLIC2, User-N_PRIVATE1}" sowie „S-CSCF2.HOME1.NET {User-N_PUBLIC1, User-N_PRIVATE2}"), wobei jeder Eintrag in diesen Aufenthaltsortsdaten eine aktive Registrierung angibt.
  • Die HSS sendet dann in Schritt 16 eine Registrierungsanfrage-Antwort (CX-Query Resp) an die I-CSCF umfassend eine Registrierungsstatusangabe, die angibt, daß der USER-N nicht mit der empfangenen privaten ID (User-N_PRIVATE3) registriert ist, sowie (optional) die Fähigkeiten, die erforderlich sind zum Auswählen einer S-CSCF aus der I-CSCF, welche letztendlich die Registrierungssitzungssteuerung für weitere Sitzungen unterstützt, die den Benutzer der empfangenen privaten ID (User-N_PRIVATE3) und der öffentlichen ID (User-N_PUBLIC2) involvieren.
  • Da auch in diesem Fall die Aufenthaltsortsdaten des SD-Registers des USER-N nicht leer sind, kann die HSS in der Frage-Antwort auch der I-CSCF eine Liste zur Verfügung stellen, welche Informationen bezogen auf eine oder mehr der S-CSCF(s), die in den Aufenthaltsortsdaten angegeben sind, umfaßt. In diesem Fall kann deshalb diese Liste Informationen bezogen nur auf „S-CSCF1", nur auf „S-CSCF2" oder auf beide umfassen.
  • Wird eine Vorgehensweise gewünscht, bei der sämtliche der Registrierungen eines gegebenen Benutzers, welche dieselbe öffentliche ID angeben, derselben S-CSCF zugeordnet sind, so enthält die Liste Informationen bezogen auf die S-CSCF, die bereits zur Bereitstellung einer Sitzungssteuerung bezogen auf eine vorherige Registrierung, in der die öffentliche ID (falls vorhanden) angegeben war, zugeordnet ist. In diesem speziellen beispielhaften Fall würde diese Liste Informationen bezogen nur auf „S-CSCF1" enthalten, da zum Zeitpunkt der Abwicklung dieser dritten Registrierungsanforderung bereits eine S-CSCF (S-CSCF1) für eine vorherige Registrierung, die dieselbe öffentliche ID (User-N_PUBLIC2) wie die derzeitige enthielt, zugeordnet war.
  • Im Beispiel gemäß 5 leitet die I-CSCF in Schritt 17 die Registrierungsanforderung an die S-CSCF1 weiter. Dieses Verhalten gibt eine Vorgehensweise zur Auswahl einer S-CSCF an, wenn sowohl die S-CSCF-Fähigkeiten als auch die Informationen bezogen auf die S-CSCF(s) in der „CX-Query Resp" vorliegen, im Unterschied zu der beschriebenen vorangegangenen (zweiten) Registrierung mit Bezug auf den äquivalenten Schritt 11 (d.h. keine S-CSCF wird aufgrund empfangener S-CSCF-Fähigkeiten ausgewählt, wenn die S-CSCF(s) nicht von der HSS angegeben wird (werden)). Im vorliegenden Fall resultiert diese Vorgehensweise darin, daß sämtliche Registrierungen eines gegebenen Benutzers angeben, daß dieselbe öffentliche ID derselben S-CSCF zugeordnet ist.
  • Die für diese Registrierung ausgewählte S-CSCF (S-CSCF1) speichert zunächst Informationen bezogen auf die P-CSCF, die diese Registrierung bereitstellt, (welche in dem als Beispiel verwendeten Fall für diese Registrierung die „P-CSCF3" ist), sowie die darin angegebenen privaten und öffentlichen IDs (User-N_PRIVATE3, User-N_PUBLIC2) und benachrichtigt (CX-Put) in Schritt 18 die HSS, daß die S-CSCF1 Sitzungen bereitstellen wird, die die private ID (User-N_PRIVATE3) und die öffentliche ID (User-N_PUBLIC2) involviert.
  • Dann, sobald die HSS das entsprechende SD-Register herausgefunden hat, erstellt sie einen neuen Aufenthaltsortsdateneintrag in diesem SD-Register, wobei dieser neue Eintrag Informationen speichert, die angeben, daß die „S-CSCF1" (in der 6 als „S-CSCF1.HOME1.NET" dargestellt) die Sitzungssteuerung für den Benutzer (USER-N) bereitstellt, sowie die Kennungen „User-N_PUBLIC2" und User-N_PRIVATE3" angibt (in der 6 als Aufenthaltsortsdateneintrag umfassend „S-CSCF1.HOME1.NET {User-N_PUBLIC2, User-N_PRIVATE3}" gezeigt). Als obengenannte Implementierungsoption kann die HSS zu einem späteren Zeitpunkt dafür sorgen, daß eine dieser S-CSCFs Sitzungen bereitstellt, die an eine der dem Benutzer zugeordneten öffentlichen IDs adressiert sind, wie weiter unten erläutert.
  • Als nächstes wird die Registrierung des Benutzers (USER-N) des Endgerätes (UE2) gewährt („200 OK", nicht dargestellt).
  • Als ein weiteres optionales Merkmal, welches beispielsweise bei weiteren Sitzungen Nachschlagesuchvorgänge, die für eine der öffentlichen IDs eines gegebenen Benutzers angefordert werden, der über mehrfache Registrierungen (multi-registrierter Benutzer) verfügt, vereinfachen kann, kann die HSS eine Nachschlagetabelle erstellen, die jede öffentliche ID des Benutzers mit einer Liste verknüpft, die Informationen bezogen auf jede S-CSCF enthält, welche in der HSS als zur Bereitstellung einer Sitzungssteuerung für weitere an den Benutzer dieser öffentlichen ID (falls vorhanden) adressierte Sitzungen gespeichert sind. Diese Liste kann beispielsweise nach nachfolgenden Registrierungsmitteilungen (CX-Put), die von S-CSCF(s) empfangen wurden, erstellt/aktualisiert werden. Ein Beispiel für einen Eintrag in dieser Tabelle in der HSS ist in der 7[A] gezeigt, wobei die Liste der S- CSCFs (S-CSCF1, S-CSCF2, ..., etc.) dargestellt ist, die derzeit eine gegebene öffentliche ID (User-N_PUBLIC2) bereitstellen.
  • In ähnlicher Weise, und mit demselben Zweck, können ähnliche Tabellen in S-CSCFs und P-CSCFs für jede gewährte Registrierung verwaltet werden. Eine S-CSCF würde dann eine gegebene öffentliche ID mit einer Liste verknüpfen, die Information über jede P-CSCF enthält, über die eine Registrierung enthaltend diese öffentliche ID von dieser S-CSCF gewährt wurde. Diese Liste kann beispielsweise zu dem Zeitpunkt erstellt/aktualisiert werden, zu dem die Registrierung gewährt wird („200 OK" gesendet). Ein Beispiel für einen Eintrag in dieser Tabelle ist einer gegebenen S-CSCF ist in 7[B] gezeigt, wobei die Liste der P-CSCFs (P-CSCF1, P-CSCF2, ..., etc.) dargestellt ist, die derzeit eine gegebene öffentliche ID (User-N_PUBLIC2) bereitstellen.
  • Andererseits würde eine P-CSCF dann eine gegebene öffentliche ID mit einer Liste verknüpfen, welche die individuelle IP-Addr jedes Endgerätes (UE) enthält, die über die erstere eine gewährte Registrierung erhalten und diese öffentliche ID in der gewährten Registrierung verwendet haben. Diese Liste kann beispielsweise zu dem Zeitpunkt erstellt/aktualisiert werden, zu dem die Registrierung gewährt wird („200 OK" empfangen oder „200 OK" gesendet). Ein Beispiel für einen Eintrag in dieser Tabelle in einer gegebenen P-CSCF ist in 7[C] gezeigt, wobei die Liste der Adressen (P-ADDR UE1, IP-ADDR UE2, ..., etc.) der UEs dargestellt ist, die über die erstere eine gewährte Registrierung erhalten haben und z.B. „User-N_PUBLIC2" als öffentliche ID angaben.
  • Es wird nunmehr Bezug genommen auf die 8, um, gemäß der vorliegenden Erfindung, die Abwicklung eines mehrfachen Sitzungsaufbaus für einen gegebenen Benutzer zu zeigen, der über mehrfache Registrierungen (multi-registrierter Benutzer) verfügt, im Gegensatz zum Aufbau einer einzigen Sitzung gemäß dem Stand der Technik, für einen Benutzer, der über eine einzige Registrierung verfügt, wie oben im Zusammenhang mit der 2, Schritte 11 bis 16 beschrieben wurde. Insbesondere ist in der 8 ein vereinfachter Signalisierungsablauf eines Sitzungsaufbauprozesses gezeigt, der von einem gegebenen IM-Benutzer von einer Mehrzahl von Endgeräten (UE1, UE2, UE3) in einem 3G-System angefordert wird, als Ergebnis der Verarbeitung einer Sitzungsanforderung (INVITE) durch die Verarbeitungsmittel in den in dieser Figur dargestellten Einrichtungen (P-CSCFs, I-CSCF, HSS, S-CSCF). Zum besseren Verständnis soll der obengenannte beispielhafte Fall eines bereits multi-registrierten Benutzers (wie oben im Zusammenhang mit dem USER-N beschrieben) verwendet werden, um einen speziellen Fall anhand eines Beispiels zu erläutern.
  • Wie oben mit Bezug auf den in der 2 gezeigten Stand der Technik erwähnt, bleibt der Umfang der vorliegenden Erfindung vom Aufenthaltsort des Sitzungsabsenders (d.h. die anrufende Partei) sowie von den Signalisierungsabläufen oder Details vor dem Ankommen der Sitzungsanforderung (INVITE) bei einer I-CSCF unberührt.
  • Die Schritte 1 und 2 gemäß 8 sind ähnlich den äquivalenten Schritten 11 und 12 gemäß 2. So sendet die I-CSCF in Schritt 2 gemäß 8 eine Aufenthaltsortsanfrage (CX-Location Query) an die HSS, wobei die Anfrage die in der INVITE empfangene öffentliche ID enthält (z.B. User-N_PUBLIC2). Unter Verwendung der Techniken gemäß dem Stand der Technik findet die HSS zunächst das entsprechende SD-Register heraus (SD-Register des USER-N), d.h. das SD-Register, welches in seinen Identifikationsdaten die in der Anfrage empfangene öffentliche ID enthält, und wirft dann einen Blick in die Aufenthaltsortsdaten dieses Registers, um zu bestimmen, welche S-CSCF (bzw. Mehrzahl von S-CSCFs) bereits festgelegt ist (sind), um die Sitzungssteuerung für den Benutzer und die empfangene öffentliche ID bereitzustellen. Nimmt man beispielsweise an, daß die empfangene öffentliche ID „User-N_PUBLIC2" (zugehörig zum USER-N) ist, und ebenfalls, daß dieser USER-N über mehrfache Registrierungen verfügt, wie oben im Zusammenhang mit der 5 beschrieben, so müßte sich herausstellen, daß die S-CSCF2 (S-CSCF2.HOME1.NET) derzeit für die Bereitstellung der Sitzungssteuerungen sorgt, die den Benutzer der beiden Registrierungen, die unter Angabe der öffentlichen ID gemacht wurden, involvieren (Einträge: „S-CSCF1.HOME1.NET {User-N_PUBLIC2, User-N_PRIVATE1}" und „S-CSCF1.Home1.NET {User-N_PUBLIC2, User-N_PRIVATE3}" gezeigt in den Aufenthaltsortsdaten des USER-N in 6).
  • Zum Zwecke des raschen Herausfindens in der HSS, welche S-CSCF(s) derzeit festgelegt ist (sind,) um die Sitzungssteuerung für einen gegebenen Benutzer und eine gegebene öffentliche ID, die den Identifikationsdaten dieses Benutzers zugeordnet ist, bereitzustellen, kann die HSS alternativ die Aufenthaltsortsinformationen verwenden, die in der obengenannten Nachschlagetabelle (7[A], in welcher ein Bezug der öffentlichen IDs zu der (den) entsprechenden festgelegten S-CSCF(s) hergestellt wird, gespeichert sind.
  • Obgleich in dem als Beispiel verwendeten speziellen Fall nur eine S-CSCF (S-CSCF1) für den Benutzer (USER-N) und die empfangene öffentliche ID (User-N_PUBLIC2) aufgefunden wird, könnte der Fall auftreten, in dem mehr als eine S-CSCF gefunden wird, die dieselbe öffentliche ID für diesen Benutzer (z.B. S-CSCF1 und S-CSCF2) bereitstellt. In diesem Fall, und gemäß einer Ausführungsform dieser Erfindung, würde die HSS in Schritt 3 eine Aufenthaltsort-Anfrage-Antwort (CX-Location Query Resp) an die I-CSCF zurücksenden, die Informationen bezogen auf nur eine S-CSCF aus der Mehrzahl von S-CSCFs enthält, welche für das Bereitstellen der Sitzungssteuerung für den Benutzer und die öffentliche ID verantwortlich sind. Gemäß dieser Ausführungsform, und in diesem als Beispiel verwendeten speziellen Fall, würde die HSS deshalb in Schritt 3 eine Aufenthaltsort-Anfrage-Antwort (CX-Location Query Resp) an die I-CSCF zurücksenden, mit Informationen (nur) bezogen auf S-CSCF1.
  • Gemäß einer alternativen Ausführungsform dieser Erfindung, kann jedoch die HSS in Schritt 3 eine Aufenthaltsort-Anfrage-Antwort (CX-Location Query Resp) an die I-CSCF mit einer Liste an Informationen zurücksenden, die bezogen sind auf mehr als eine S-CSCF aus der Mehrzahl von S-CSCFs, die eine Sitzungssteuerung für den Benutzer und die öffentliche ID bereitstellen, oder aber mit Informationen, die auf sämtliche der S-CSCFs bezogen sind. Bedingungen für die Ausführung oder Nicht-Ausführung dieser alternativen Ausführungsform können auf einer Pro-Benutzer-Basis (z.B. aufgrund der von der HSS abgewickelten Benutzerprofildaten) oder als generelle Implementierung für sämtliche Benutzer festgelegt werden. In jedem Fall ist dies hilfreich, wenn beispielsweise (entweder vom Benutzer oder vom Netzbetrei ber) ein hoher Grad an Verfügbarkeit zur Beantwortung ankommender Sitzungen gewünscht wird.
  • Gemäß einer weiteren alternativen Ausführungsform kann die in Schritt 3 von der HSS an die I-CSCF gesendete Aufenthaltsort-Anfrage-Antwort (CX-Location Query Resp) Informationen enthalten, die bezogen sind auf eine oder mehr als eine S-CSCF(s), welche für das Bereitstellen einer Sitzungssteuerung für eine der dem Benutzer zugeordneten öffentlichen IDs verantwortlich ist (sind). Da in diesem Fall (wie zuvor im Zusammenhang mit der Registrierungsprozedur erwähnt) für jede aktive Registrierung in einer gegebenen S-CSCF eine Verknüpfung zwischen einer in einer erfolgreichen Registrierung angegebenen gegebenen öffentlichen ID und der in dieser Registrierung involvierten P-CSCF besteht, und in einer gegebenen P-CSCF eine Verknüpfung zwischen einer in einer erfolgreichen Registrierung angegebenen gegebenen öffentlichen ID und der Adresse des UE besteht, welches in diese Registrierung involviert ist, wird die HSS, wann immer diese Informationen bezogen auf eine S-CSCF sendet, die den Benutzer bedient, jedoch auf eine öffentliche ID, die sich von derjenigen unterscheidet, die in der Aufenthaltsortanfrage empfangen wurde, die öffentliche ID der den Benutzer bedienenden S-CSCF den Informationen bezogen auf diese S-CSCF hinzufügen. Sollte beispielsweise im obengenannten speziellen Fall, und unter Berücksichtigung der in der 6 gezeigten Aufenthaltsortdaten für den multi-registrierten USER-N, die HSS eine Aufenthaltsort-Anfrage-Antwort (CX-Location Query Resp) enthaltend Informationen bezogen auf die S-CSCF2 senden, so sollte es die öffentliche ID „User-N_PUBLIC1" als Zusatz zu den Informationen bezogen auf die S-CSCF2 enthalten.
  • Abläufe in der I-CSCF bei Empfang der Aufenthaltsort-Anfrage-Antwort (CX-Location Query Resp) hängen von den Informationen bezogen auf die S-CSCF(s) ab, die in dieser Antwort empfangen wird/werden.
  • Enthält die Aufenthaltsort-Anfrage-Antwort (CX-Location Query Resp) Informationen bezogen auf nur eine S-CSCF, so leitet die I-CSCF die empfangene Sitzungsanforderung (INVITE) and die S-CSCF weiter, die von der HSS in dieser Anfrage-Antwort angegeben wurde. Enthält diese Antwort jedoch Informationen bezogen auf eine Mehrzahl von S-CSCFs, so kann die I-CSCF unterschiedliche Optionen implementieren, die (wie obenerwähnt) angewendet werden können, z.B. gemäß des obengenannten hohen oder niedrigen Grades an Verfügbarkeit, die zum Beantworten der ankommenden Sitzungen erwünscht ist.
  • Gemäß einer Ausführungsform dieser Erfindung wählt die I-CSCF eine S-CSCF aus einer Mehrzahl von S-CSCFs aus, die von der HSS angegeben wurden, und übermittelt dieser die empfangene INVITE.
  • Gemäß einer weiteren alternativen Ausführungsform übermittelt die I-CSCF die INVITE gleichzeitig an mehr als eine aus der Mehrzahl von S-CSCFs. In diesem Fall kann die I-CSCF, sobald die Sitzung vergeben (d.h. beantwortet oder akzeptiert) ist (z.B. Empfang des SIP-Antwortcodes „200 OK" von einer der S-CSCFs), die von ihr an die anderen S-CSCFs gesendeten Sitzungsanforderungen abbrechen (z.B. Senden einer SIP-Abbruchsanforderung „CANCEL" an die S-CSCFs).
  • Gemäß einer weiteren alternativen Ausführungsform übermittelt die I-CSCF die INVITE aufeinanderfolgend an mehr als eine aus der Mehrzahl von S-CSCFs, bis die INVITE an eine von diesen vergeben wird, z.B. bis ein positiver Antwortcode (wie „200 OK") empfangen wird. Zu diesem Zweck kann die I-CSCF beispielsweise einen Zeitgeber eines vorbestimmten Wertes setzen, wenn es die INVITE an eine erste S-CSCF sendet. Sobald ein gegebener Zeitraum abgelaufen ist, ohne daß die positive Antwort (Zeitablauf) bzw. eine negative Antwort empfangen wurde (z.B. ein SIP-Antwortcode „4XX"), sendet sie deshalb die INVITE an eine zweite S-CSCF etc. und verfährt entsprechend mit den folgenden S-CSCFs. Wahlweise kann die I-SCSF die Sitzungsanforderung, die sie an eine gegebene S-CSCF gesendet hat, zum Zeitablauf abbrechen (z.B. Senden einer SIP-Abbruchanforderung „CANCEL" an diese S-CSCF).
  • Wann immer in einem der obengenannten Fälle (INVITE wird an eine S-CSCF weitergeleitet oder gleichzeitig oder aufeinanderfolgend an mehr als eine S-CSCF) die I-CSCF die Sitzungsanforderung (INVITE) an eine S-CSCF weiterleitet, die von der HSS mit einer öffentlichen ID angegeben wurde, welche sich von der in der INVITE empfangenen öffentlichen ID unterscheidet (d.h. die S-CSCF bedient denselben Benutzer, aber mit einer unterschiedlichen öffentlichen ID), dann enthält die INVITE, die die I-CSCF an die S-CSCF weiterleitet, die von der HSS empfangene öffentliche ID als Ersatz für die öffentliche ID, die ursprünglich in der INVITE empfangen wurde.
  • Da, mit Bezug auf den in der 8 gezeigten speziellen Fall, davon ausgegangen wurde, daß die Aufenthaltsort-Anfrage-Antwort (CX-Location Query Resp) zuvor Informationen bezogen nur auf die S-CSCF1 enthielt (d.h., daß gemäß dem Beispiel keine weitere öffentliche ID den Informationen hinzugefügt wurde), übermittelt die I-CSCF in Schritt 4 die empfangene INVITE an die S-CSCF1.
  • Wenn die Sitzungsanforderung (INVITE) bei der S-CSCF eingeht, so findet sie aufgrund der gespeicherten Informationen heraus, daß diese bezogen waren auf die P-CSCFs, die P-CSCF (oder Mehrzahl der P-CSCFs), über die eine Registrierung angefordert (REGISTER) und gewährt (200 OK) wurde, die die in der INVITE empfangene öffentliche ID enthielt. Geht man beispielsweise davon aus, daß die in der INVITE empfangene öffentliche ID „User-N_PUBLIC2" ist, dann würde die S-CSCF1 zwei P-CSCFs vorfinden, die den obigen Bedingungen entsprechen: P-CSCF1 und P-CSCF3.
  • Zum Zwecke des Herausfindens in der S-CSCF, welche P-CSCF(s) derzeit Zugang für einen gegebenen Benutzer und eine gegebene öffentliche ID bereitstellt(en), kann die S-CSCF alternativ die in der obenerwähnten Nachschlagetabelle (7[B] gespeicherten Informationen verwenden, die einen Bezug zwischen öffentlichen IDs und den entsprechenden P-CSCF(s) herstellt.
  • Gemäß einer Ausführungsform der vorliegenden Erfindung leitet die S-CSCF die INVITE nur an eine P-CSCF aus der Mehrzahl von P-CSCFs weiter, über welche eine Registrierungsanforderung enthaltend die öffentliche ID von der S-CSCF gewährt wurde. Somit würde in dem als Beispiel angeführten speziellen Fall die S-CSCF1 eine P-CSCF aus P-CSCF1 und P-CSCF2 auswählen und die INVITE an die ausgewählte P-CSCF weiterleiten.
  • Gemäß einer weiteren alternativen Ausführungsform, nämlich wenn Informationen bezogen auf eine Mehrzahl von P-CSCFs aufgefunden wird, über die eine Registrierungsanforderung enthaltend die öffentliche ID von der S-CSCF gewährt worden ist, wird die Sitzungsanforderung (INVITE) von der S-CSCF entweder gleichzeitig oder aufeinanderfolgend an mehr als eine P-CSCF aus der Mehrzahl von P-CSCFs weitergeleitet. Dies ist der in den Schritten 5 und 7 gemäß 8 dargestellte Fall, in welchem die INVITE (gleichzeitig oder aufeinanderfolgend) an P-CSCF1 und P-CSCF3 übermittelt wird, da (wie im zuvor angeführten Registrierungsbeispiel angenommen) eine Registrierungsanforderung von den P-CSCFs angefordert wurde (Schritte 5 und 17 gemäß 5), unter Angabe derselben öffentlichen ID, wie die in der INVITE empfangenen (User-N_PUBLIC2).
  • Wird gemäß einer alternativen Ausführungsform die INVITE von der S-CSCF gleichzeitig an mehr als eine aus der Mehrzahl von P-CSCFs weitergeleitet, sobald die Sitzung vergeben ist (z.B. Empfangen des SIP-Antwortcodes „200 OK" von einer der P-CSCFs), kann die S-CSCF die Sitzungsanforderung, die sie an die anderen P-CSCFs gesendet hatte, abbrechen (z.B. Senden einer SIP-Abbruchanforderung „CANCEL" an die P-CSCFs).
  • Für das aufeinanderfolgende Senden der INVITE von der S-CSCF an mehr als eine aus der Mehrzahl von P-CSCFs kann, gemäß einer weiteren alternativen Ausführungsform, ein Verfahren ähnlich dem oben in Zusammenhang mit dem aufeinanderfolgenden Senden von der I-CSCF aus beschriebenen Anwendung finden, bis ein positiver Antwortcode (wie „200 OK") empfangen wird. Mit anderen Worten, die S-CSCF sendet die INVITE an eine erste P-CSCF aus der Mehrzahl von P-CSCFs und startet einen diesem Senden zugeordneten Zeitgeber. Beim Zeitablauf des Zeitgebers bzw. nach Empfang einer negativen Antwort (z.B. ein SIP-Antwortcode „4XX") übermittelt sie die INVITE an eine zweite P-CSCF etc. und verfährt entsprechend mit den folgenden P-CSCFs. Wahlweise kann die S-CSCF die Sitzungsanforderung, die sie an eine gegebene P-CSCF gesendet hat, zum Zeitablauf abbrechen (z.B. Senden einer SIP-Abbruchanforderung „CANCEL" an diese P-CSCF).
  • Nach Empfang einer Sitzungsanforderung (INVITE) in einer P-CSCF (z.B. in den Schritten 5 oder 7 gemäß 8) findet die P-CSCF in der Adresseninformation (z.B. IP-Addr), die sie bezogen auf die Endgeräte (UEs) hält, deren Zugang sie bereitstellt, das Endgerät (bzw. die Mehrzahl von Endgeräten) heraus, von dem aus eine Registrierung angefordert wurde (REGISTER) und über die P-CSCF, welche die in der INVITE empfangene öffentliche ID enthielt, gewährt wurde. Zum Zwecke des Herausfindens in der P-CSCF, welchem Endgerät bzw. welchen Endgeräten Zugang von dieser P-CSCF bereitgestellt wird, das (die) über eine gewährte Registrierung unter Angabe der öffentlichen ID verfügt (verfügen), kann die P-CSCF die in der obengenannten Nachschlagetabelle (7[C]) gespeicherten Informationen verwenden, die einen Bezug zwischen den öffentlichen IDs und den entsprechenden Adressen der UEs herstellt.
  • Gemäß einer Ausführungsform der vorliegenden Erfindung leitet die P-CSCF dann die empfange INVITE an ein UE aus der Mehrzahl von UEs weiter, deren Zugang sie bereitstellt, denen unter Verwendung derselben öffentlichen ID wie die in der INVITE empfangenen eine Registrierung gewährt wurde.
  • Fortfahrend mit dem als Beispiel genannten speziellen Fall, in welchem „User-N_PUBLIC2" als öffentliche ID in der INVITE empfangen wird, würde die P-CSCF1 dann die Adresse des UE1 (IP-ADDR UE1) finden, während die P-CSCF3 die Adresse des UE3 (IP-ADDR UE3) herausfinden würde.
  • Als nächstes würde in Schritt 6 die P-CSCF1 die INVITE an das UE1 weiterleiten, und die P-CSCF würde die INVITE in Schritt 8 an das UE3 weiterleiten. Ohne Berücksichtigung des in diesem Beispiel angeführten speziellen Falls könnte bei Empfang einer INVITE in einer gegebenen P-CSCF jedoch eine Mehrzahl von UEs gefunden werden, die der obengenannten Bedingung entsprechen (z.B. wenn UE1 und UE3 eine Registrierung über dieselbe P-CSCCF erhalten haben, welche dieselbe öffentliche ID in der REGISTER angeben). In diesem Fall, und gemäß weiteren alternativen Ausführungsformen der vorliegenden Erfindung, würde die P-CSCF diese INVITE entweder gleichzeitig oder aufeinanderfolgend an mehr als ein UE aus der Mehrzahl der UEs weiterleiten.
  • Gemäß einer alternativen Ausführungsform wird die INVITE von der P-CSCF gleichzeitig an mehr als eine aus der Mehrzahl von UEs weitergeleitet. Sobald in diesem Fall die Sitzung vergeben ist (z.B. Empfangen des SIP-Antwortcodes „200 OK" von einem der UEs), kann die P-CSCF die Sitzungsanforderung, die sie an die anderen UEs gesendet hatte, abbrechen (z.B. Senden einer SIP-Abbruchanforderung „CANCEL" an die UEs).
  • Wird, gemäß einer weiteren alternativen Ausführungsform die INVITE von der P-CSCF aufeinanderfolgend an mehr als eines aus der Mehrzahl von UEs weitergeleitet, kann ebenfalls ein Verfahren ähnlich dem oben in Zusammenhang mit dem aufeinanderfolgenden Senden der INVITE von einer I-CSCF oder von einer S-CSCF beschriebenen in der P-CSCF Anwendung finden, bis ein positiver Antwortcode (wie „200 OK") empfangen wird. Wahlweise kann die P-CSCF die Sitzungsanforderung, die sie an ein gegebenes UE gesendet hat, zum Zeitablauf abbrechen (z.B. Senden einer SIP-Abbruchanforderung „CANCEL" an dieses UE).
  • Ein gegebener Benutzer, der über eine Mehrzahl von aktiven Registrierungen (multi-registrierter Benutzer) verfügt, kann in ähnlicher Weise, wie oben im Zusammenhang mit den Deregistrierungsverfahren gemäß dem Stand der Technik beschrieben, deregistriert werden. Geht man jedoch davon aus, daß für einen multi-registrierten Benutzer gemäß dieser Erfindung ein unabhängiger Eintrag pro aktive Registrierung in den Aufenthaltsortdaten des SD-Registers vorliegt, der diesem Benutzer entspricht, so wird nur der korrekte Eintrag in diesen Aufenthaltsortdaten in einem Deregistrierungsverfahren gelöscht, während alle anderen Registrierungen des Benutzers (falls vorhanden) aktiv bleiben.
  • Nimmt man beispielsweise als Referenzaufenthaltsortdaten die in der 6 für den Benutzer USER-N gezeigten sowie die öffentlichen und privaten IDs, welche in der spezifischen Mehrfachregistrierung gemäß dem Beispiel in 5 verwendet werden, so würde im Fall einer vom UE1 aus angeforderten benutzerinitiierten Deregistrierung nur der erste Eintrag, welcher in den Aufenthaltsortdaten gemäß 6 gezeigt ist, gelöscht werden („S-CSCF1.HOME1.NET {User-N_PUBLIC2, User-N_PRIVATE1}"), da dieser Eintrag der einzige ist, welcher zur in der Deregistrierung sanforderung angegebenen öffentlichen ID und privaten ID paßt (d.h. wie oben erwähnt, eine Nachricht REGISTER, die der bei der Registrierung verwendeten ähnlich ist, welche dieselben privaten und öffentlichen IDs enthält, jedoch nunmehr ein „Ablauf"-Kopffeld von „Null" angibt). Allerdings würden die anderen Registrierungen (S-CSCF2.HOME1.NET {User-N_PUBLIC1, User-N_PRIVATE2}" und CSCF1.HOME1.NET {User-N_PUBLIC2, User-N_PRIVATE3}") aktiv bleiben und es so dem Benutzer (USER-N) erlauben, eingehende Sitzungen von anderen Parteien zu empfangen. In ähnlicher Weise werden nur die in der S-CSCF und der P-CSCF gespeicherten Daten bezogen auf die Registrierung, die nun deregistriert wird, gelöscht. Im Falle der oben beispielhaft genannten Deregistrierung (d.h. UE1 fordert eine Deregistrierung an) löscht die P-CSCF1 die zuvor gespeicherten Informationen, welche die in der Registrierung (User-N_PUBLIC2, User-N_PRIVATE1) verwendeten öffentlichen und privaten IDs mit der Adresse des UE verknüpft hat, das die Registrierung anforderte (IP-ADDR UE1), und die S-CSCF1 löscht die zuvor gespeicherten Informationen, welche die in der Registrierung (User-N_PUBLIC1, User-N_PRIVATE1) verwendeten öffentlichen und privaten IDs mit der P-CSCF verknüpft hat, die den Zugang zu dieser Registrierung (P-CSCF1) bereitstellte. Allerdings würde eine S-CSCF die Daten beibehalten, die auf die andere Registrierung bezogen sind, welche sie – gemäß dem Beispiel – demselben Benutzer bereitstellt (User-N_PUBLIC2 und User-N_PRIVATE3 verknüpft mit P-CSCF3), wodurch sie weiterhin in der Lage ist, eine Sitzungssteuerung für weitere eingehende Sitzungen, die von anderen Parteien angefordert werden und an die öffentliche ID „User-N_PUBLIC2" adressiert sind, bereitzustellen.

Claims (28)

  1. Verfahren zum Handhaben einer Mehrzahl von Registrierungen eines Benutzers in einem Telekommunikationssystem das Aufenthaltsortinformationen und Identifikationsinformationen verwaltet bezogen auf dessen Benutzer, wobei jede dieser Registrierungen auf eine Teilnahmeberechtigung des Benutzers in diesem System bezogen ist, wobei das Verfahren die folgenden Schritte umfaßt: a) Speichern einer Mehrzahl von privaten Kennungen bezogen auf diese Teilnahmeberechtigung; b) Empfangen von Registrierungsanforderungen (REGISTER), wobei jede Registrierungsanforderung den Anschluß eines Endgerätes (UE1, UE2, UE3) an dieses System für diese Teilnahmeberechtigung anfordert, und c) Bearbeiten jeder empfangenen Registrierungsanforderung gemäß der in der Anforderung empfangenen privaten Kennung aus der Mehrzahl von privaten Kennungen, dadurch gekennzeichnet, daß Schritt c den Schritt das Bearbeitens einer Registrierungsanforderung gemäß der empfangenen privaten Kennung und einer in der Anforderung empfangenen öffentlichen Kennung umfasst.
  2. Verfahren nach Anspruch 1, wobei der Schritt des Bearbeitens einer empfangenen Registrierungsanforderung gemäß den empfangenen privaten und öffentlichen Kennungen folgende Schritte umfaßt: Empfangen einer Registrierungsanfrage (CX-QUERY) in einer Heimat-Server-Einrichtung (HSS), die Daten (SD) der Teilnahmeberechtigung speichert, wobei die Registrierungsanfrage wenigstens die empfangenen privaten und öffentlichen Kennungen enthält, Verifizieren in dem Heimat-Server (HSS), ob der Benutzer bereits mit der privaten Kennung registriert ist, Beantworten (CX-QUERY RESP) der Registrierungsanfrage mit Informationen zum weiteren Handhaben der Registrierungsanforderung, wobei die Informationen eines der folgenden bzw. Kombinationen hiervon umfassen: eine Registrierungsstatusanzeige die anzeigt, ob der Benutzer nicht mit der empfangenen privaten Kennung registriert ist, die für eine Sitzungssteuerungs-Server-Einrichtung (S-CSCF) erforderlichen Fähigkeiten zur Unterstützung der Sitzungssteuerung für weitere Sitzungen, die den Benutzer mit der öffentlichen Kennung und der privaten Kennung involvieren, Informationen bezogen auf einen Sitzungssteuerungs-Server (S-CSCF1, S-CSCF2, S-CSCF3), der bereits festgelegt ist, um die Sitzungssteuerung gegenüber dem Benutzer für die empfangene öffentlichen Kennung und irgendeine der privaten Kennungen, die der Teilnahmeberechtigung des Benutzers zugeordnet sind, bereitzustellen, eine Liste mit Informationen bezogen auf einen oder mehrere der Mehrzahl von Sitzungssteuerungs-Servern (S-CSCF1, S-CSCF2, S-CSCF3), die bereits festgelegt sind, um die Sitzungssteuerung gegenüber dem Benutzer für irgendeine der öffentlichen und der privaten Kennungen bereitzustellen, die der Teilnahmeberechtigung des Benutzers zugeordnet sind.
  3. Verfahren nach Anspruch 2, weiterhin umfassend die folgenden Schritte: Auswählen, gemäß den Informationen zum Handhaben der Registrierungsanforderung, einer Sitzungssteuerungs-Server-Einrichtung (S-CSCF) zur Sitzungssteuerung für weitere Sitzungen, die den Benutzer der öffentlichen Kennung und der privaten Kennung involvieren, und Gewähren (200 OK) der Registrierung des Benutzers des Endgerätes (UE) in dem System.
  4. Verfahren nach Anspruch 3, wobei der Schritt des Gewährens den Schritt des Gewährens (200 OK) der Registrierung an das Endgerät (UE) von dem ausgewählten Sitzungssteuerungs-Server (S-CSCF) durch die Erstkontaktpunkt-Server-Einrichtung (P-CSCF), die den Zugriff des Endgerätes auf das System bereitstellt, umfaßt.
  5. Verfahren nach Anspruch 4, wobei der Schritt des Gewährens der Registrierung durch den ausgewählten Sitzungssteuerungs-Server (S-CSCF) weiterhin den Schritt des Verbindens der empfangenen öffentlichen Kennung mit einer Liste mit Informationen über jeden ersten Kontaktpunk-Server (P-CSCF1, P-CSCF2, P-CSCF3) umfaßt, durch den eine Registrierung enthaltend die öffentliche Kennung vom Sitzungssteuerungs-Server gewährt wurde (200 OK).
  6. Verfahren nach Anspruch 4, wobei der Schritt des Gewährens der Registrierung durch die Erstkontaktpunkt-Server-Einrichtung (P-CSCF) weiterhin den Schritt des Verbindens der empfangenen öffentlichen Kennung mit einer Liste umfaßt, die die individuelle Adresse (IP-ADDR) jedes Endgerätes (UE1, UE2, UE3) enthält, welches durch sie eine gewährte Registrierung erhalten (200 OK) und die öffentliche Kennung in der freigegebenen Registrierung verwendet hat.
  7. Verfahren nach Anspruch 3, weiterhin umfassend die folgenden Schritte: Senden (CX-PUT) von Informationen bezogen auf den ausgewählten Sitzungssteuerungs-Server (S-CSCF1, S-CSCF2, S-CSCF3), der empfangenen öffentlichen Kennung und der empfangenen privaten Kennung von dem ausgewählten Sitzungssteuerungs-Server (S-CSCF) an den Heimat-Server (HSS), Speichern im Heimat-Server (HSS) von Informationen, die angeben, daß der ausgewählte Sitzungssteuerungs-Server (S-CSCF1, S-CSCF2, S-CSCF3) der Bereitstellung der Sitzungssteuerung für weitere Sitzungen zugeordnet ist, die bezogen sind auf den Benutzer mit der empfangenen öffentlichen Kennung und der empfangenen privaten Kennung, wobei die Informationen zusätzlich zu möglichen zuvor gespeicherten Informationen gespeichert werden, die einen anderen Sitzungssteuerungs-Server (S-CSCF1, S-CSCF2, S-CSCF3) betreffen, der der Bereitstellung der Sitzungssteuerung für weitere Sitzungen bereits zugeordnet ist, die bezogen sind auf den Benutzer mit einer der Teilnahmeberechtigung des Benutzers zugeordneten empfangenen öffentlichen Kennung und einer empfangenen privaten Kennung.
  8. Verfahren nach Anspruch 7, weiterhin umfassend den Schritt des Einbindens im Heimat-Server (HSS) der empfangenen öffentlichen Kennung mit einer Liste enthaltend Informationen bezogen auf jeden Sitzungssteuerungs-Server (S-CSCF, S-CSCF2, S-CSCF3), der eine Benachrichtigung (CX-PUT) vorgenommen hat, daß er der Bereitstellung der Sitzungssteuerung für weitere Sitzungen bezogen auf den Benutzer mit der öffentlichen Kennung zugeordnet ist.
  9. Verfahren nach einem der Ansprüche 1 bis 8, wobei die Abwicklung eines an den Benutzer adressierten Sitzungsaufbaus folgende Schritte umfaßt: Empfangen einer Sitzungsanforderung (INVITE) enthaltend eine öffentliche Kennung bezogen auf die Teilnahmeberechtigung des Benutzers in dem Telekommunikationssystem, und Bearbeiten der Sitzungsanforderung gemäß dem Registrierungsstatus der öffentlichen Kennungen und der privaten Kennungen des Benutzers.
  10. Verfahren nach Anspruch 9, wobei der Schritt des Bearbeitens der Sitzungsanforderung (INVITE) einen der folgenden Schritte umfaßt: Weiterleiten der Sitzungsanforderung an ein Endgerät (UE) aus einer Mehrzahl von Endgeräten (UE1, UE2, UE3) mit einer für die Teilnahmeberechtigung gewährten Registrierung (200 OK), aufeinanderfolgendes Weiterleiten der Sitzungsanforderung an mehr als ein Endgerät aus der Mehrzahl von Endgeräten (UE1, UE2, UE3), bis die Sitzung einem davon zugeteilt wird, gleichzeitiges Weiterleiten der Sitzungsanforderung an mehr als ein Endgerät aus der Mehrzahl von Endgeräten (UE1, UE2, UE3).
  11. Verfahren nach Anspruch 9, wobei der Schritt des Bearbeitens der Sitzungsanforderung gemäß dem Registrierungsstatus der öffentlichen Kennungen und der privaten Kennungen des Benutzers die folgenden Schritte umfaßt: Empfangen einer Aufenthaltsortanforderungsanfrage (CX-LOCATION-QUERY) enthaltend die empfangene öffentliche Kennung in der Heimat-Server-Einrichtung (HSS), Beantworten (CX-LOCATION-QUERY RESP) der Aufenthaltsortanforderungsanfrage mit Informationen zur weiteren Handhabung der Sitzungsanforderung, wobei die Informationen jeweils eines der folgenden bzw. Kombinationen hiervon umfassen: eine Liste enthaltend Informationen bezogen auf eine oder mehrere Sitzungssteuerungs-Server-Einrichtungen (S-CSCF1, S-CSCF2, S-CSCF3), die zur Bereitstellung der Sitzungssteuerung für den Benutzer mit der empfangenen öffentlichen Kennung zugeordnet sind, eine Liste enthaltend Informationen bezogen auf eine oder mehrere Sitzungssteuerungs-Server-Einrichtungen (S-CSCF1, S-CSCF2, S-CSCF3), die zur Bereitstellung der Sitzungssteuerung für den Benutzer mit einer der öffentlichen Kennungen zugeordnet sind, wobei die Informationen eines Sitzungssteuerungs-Servers (S-CSCF) weiterhin begleitet werden von einer öffentlichen Kennung zum Ersetzen, als emp fangene öffentliche Kennung, der ursprünglich empfangenen öffentlichen Kennung wann immer der Sitzungssteuerungs-Server (S-CSCF) dem Benutzer die Sitzungssteuerung mit einer sich von der ursprünglich empfangenen öffentlich Kennung unterscheidenden öffentlichen Kennung bereitstellt.
  12. Verfahren nach Anspruch 11, umfassend einen der folgenden Schritte: Weiterleiten der Sitzungsanforderung an einen Sitzungssteuerungs-Server (S-CSCF), der in der Information zur weiteren Abwicklung der Sitzungsanforderung empfangen wurde, aufeinanderfolgendes Weiterleiten der Sitzungsanforderung an mehr als einen Sitzungssteuerungs-Server (S-CSCF1, S-CSCF2, S-CSCF3), die in der Information zur weiteren Abwicklung der Sitzungsanforderung empfangen wurden, bis die Sitzung von einem davon zugeteilt wird, gleichzeitiges Weiterleiten der Sitzungsanforderung an mehr als einen Sitzungssteuerungs-Server (S-CSCF1, S-CSCF2, S-CSCF3), die in der Information zur weiteren Abwicklung der Sitzungsanforderung empfangen wurde.
  13. Verfahren nach Anspruch 12, umfassend einen der folgenden Schritte: Weiterleiten einer empfangenen Sitzungsanforderung von einem Sitzungssteuerungs-Server (S-CSCF) an eine Erstkontaktpunkt-Server-Einrichtung (P-CSCF) aus einer Mehrzahl von Erstkontaktpunkt-Server-Einrichtungen (P-CSCF1, P-CSCF2, P-CSCF3), durch die eine Registrierung enthaltend die empfangene öffentliche Kennung von dem Sitzungssteuerungs-Server (S-CSCF) gewährt wurde (200 OK), aufeinanderfolgendes Weiterleiten einer empfangenen Sitzungsanforderung von einem Sitzungssteuerungs-Server (S-CSCF) an mehr als einen Erstkon taktpunkt-Server (P-CSCF) aus der Mehrzahl von Erstkontaktpunkt-Servern (P-CSCF1, P-CSCf2, P-CSCF3), bis die Sitzung von einem davon zugeteilt wird, gleichzeitiges Weiterleiten einer empfangenen Sitzungsanforderung von einem Sitzungssteuerungs-Server (S-CSCF) an mehr als einen Erstkontaktpunkt-Server (P-CSCF) aus der Mehrzahl von Erstkontaktpunkt-Servern (P-CSCF1, P-CSCF2, P-CSCF3).
  14. Verfahren nach Anspruch 13, umfassend einen Schritt aus den folgenden: Weiterleiten einer empfangenen Sitzungsanforderung von einer Erstkontaktpunkt-Server-Einrichtung (P-CSCF) an ein Endgerät (UE) aus einer Mehrzahl von Endgeräten (UE1, UE2, UE3), wobei der Erstkontaktpunkt-Server einen Zugriff mit einer gewährten Registrierung (200 OK) unter Verwendung der öffentlichen Kennung bereitstellt, aufeinanderfolgendes Weiterleiten einer empfangenen Sitzungsanforderung von einer Erstkontaktpunkt-Server-Einrichtung (P-CSCF) an mehr als ein Endgerät (UE) aus einer Mehrzahl von Endgeräten (UE1, UE2, UE3), bis die Sitzung einem davon zugeteilt wird, gleichzeitiges Weiterleiten einer empfangenen Sitzungsanforderung von einer Erstkontaktpunkt-Server-Einrichtung (P-CSCF) an ein Endgerät (UE) aus einer Mehrzahl von Endgeräten (UE1, UE2, UE3).
  15. System zum Handhaben einer Mehrzahl von Registrierungen eines Benutzers in einem Telekommunikationssystem für die Verwaltung von Aufenthaltsortinformationen und Identifikationsinformationen bezogen auf dessen Benutzer, bei dem jede dieser Registrierungen auf eine Teilnahmeberechtigung des Benutzers in diesem System bezogen ist, wobei das System folgendes umfaßt: Speichermittel zum Speichern einer Mehrzahl von privaten Kennungen bezogen auf diese Teilnahmeberechtigung, und Bearbeitungsmittel zum Bearbeiten empfangener Registrierungsanforderungen (REGISTER) gemäß der privaten Kennung aus der Mehrzahl von privaten Kennungen, die auf jede dieser Anforderungen empfangen wurde, wobei jede der Registrierungsanforderungen den Anschluß eines Endgeräts (UE1, UE2, UE3) an das System für die Teilnahmeberechtigung anfordert, dadurch gekennzeichnet, daß die Bearbeitungsmittel weiterhin der Bearbeitung jeder der empfangenen Registrierungsanforderungen gemäß der empfangenen privaten Kennung und der öffentlichen Kennung, die in der Anforderung empfangen wurden, dienen.
  16. System nach Anspruch 15, wobei die Bearbeitungsmittel folgendes umfassen: Mittel zum Empfangen einer Registrierungsanfrage (CX-QUERY) in einer Heimat-Server-Einrichtung (HSS), die Daten (SD) der Teilnahmeberechtigung speichert, wobei die Registrierungsanfrage wenigstens die empfangenen privaten und öffentlichen Kennungen enthält, Mittel in dem Heimat-Server zum Verifizieren, ob der Benutzer bereits mit der privaten Kennung registriert ist, Mittel in dem Heimat-Server zum Beantworten (CX-QUERY RESP) der Registrierungsanfrage mit Informationen zum weiteren Handhaben der Registrierungsanforderung, wobei die Informationen eines bzw. Kombinationen des folgenden umfassen: eine Registrierungsstatusanzeige zum Anzeigen, ob der Benutzer nicht mit der empfangenen privaten Kennung registriert ist, die für eine Sitzungssteuerungs-Server-Einrichtung (S-CSCF) erforderlichen Fähigkeiten zur Unterstützung der Sitzungssteuerung für weitere Sitzungen, die den Benutzer mit der öffentlichen Kennung und der privaten Kennung involvieren, Informationen bezogen auf einen Sitzungssteuerungs-Server (S-CSCF1, S-CSCF2, S-CSCF3), der bereits festgelegt ist zur Bereitstellung der Sitzungssteuerung gegenüber dem Benutzer mit der empfangenen öffentlichen Kennung und einer der privaten Kennungen, die der Teilnahmeberechtigung des Benutzers zugeordnet sind, eine Liste mit Informationen bezogen auf einen oder mehrere der Mehrzahl von Sitzungssteuerungs-Servern (S-CSCF1, S-CSCF2, S-CSCF3), die bereits festgelegt sind, zur Bereitstellung der Sitzungssteuerung gegenüber dem Benutzer mit einer der empfangenen öffentlichen und privaten Kennungen, die der Teilnahmeberechtigung des Benutzers zugeordnet sind.
  17. System nach Anspruch 16, wobei die Bearbeitungsmittel weiterhin umfassen: Mittel zum Auswählen einer Sitzungssteuerungs-Server-Einrichtung (S-CSCF) gemäß den Informationen zum Handhaben der Registrierungsanforderung, die der Sitzungssteuerung für weitere Sitzungen dient, welche den Benutzer der öffentlichen Kennung und der privaten Kennung involvieren, und Mittel zum Gewähren (200 OK) der Registrierung des Benutzers des Endgerätes (UE) in dem System.
  18. System nach Anspruch 17, wobei die Mittel zum Gewähren Mittel zum Gewähren (200 OK) der Registrierung von dem ausgewählten Sitzungssteuerungs-Server (S-CSCF) an das Endgerät (UE) durch die Erstkontaktpunkt-Server-Einrichtung (P-CSCF), die den Zugriff des Endgerätes auf das System dient, umfassen.
  19. System nach Anspruch 18, wobei der ausgewählte Sitzungssteuerungs-Server (S-CSCF) zur Einbindung einer gegebenen öffentlichen Kennung in eine Liste mit Informationen über jeden ersten Kontaktpunk-Server (P-CSCF1, P-CSCF2, P-CSCF3) dient, durch den eine Registrierung enthaltend die öffentliche Kennung vom Sitzungssteuerungs-Server freigegeben wurde (200 OK).
  20. System nach Anspruch 18, wobei die Erstkontaktpunkt-Einrichtung (P-CSCF) zur Einbindung einer gegebenen öffentlichen Kennung in eine Liste dient, die die individuelle Adresse (IP-ADDR) jedes Endgerätes (UE1, UE2, UE3) enthält, welches durch sie eine freigegebene Registrierung erhalten (200 OK) und die öffentliche Kennung in der freigegebenen Registrierung verwendet hat.
  21. System nach Anspruch 17, bei dem der Heimat-Server (HSS) weiterhin) ausgestaltet ist zur Speicherung von Informationen eines Sitzungssteuerungs-Servers (S-CSCF1, S-CSCF2, S-CSCF3, der mitteilt (CX-PUT), daß er der Bereitstellung der Sitzungssteuerung für weitere Sitzungen zugeordnet ist, die bezogen sind auf den Benutzer mit der empfangenen öffentlichen Kennung und der empfangenen privaten Kennung, wobei die Informationen zusätzlich zu möglichen zuvor gespeicherten Informationen gespeichert werden, die irgendeinen anderen Sitzungssteuerungs-Server (S-CSCF1, S-CSCF2, S-CSCF3) betreffen, der bereits der Bereitstellung der Sitzungssteuerung für weitere Sitzungen zugeordnet ist, die bezogen sind auf den Benutzer mit einer der Teilnahmeberechtigung des Benutzers zugeordneten empfangenen öffentlichen Kennung und einer empfangenen privaten Kennung.
  22. System nach Anspruch 21, wobei der Heimat-Server (HSS) weiterhin ausgestaltet ist zur Einbindung einer gegebenen öffentlichen Kennung in eine Liste enthaltend Informationen bezogen auf die Sitzungssteuerungs-Server (S-CSCF, S-CSCF2, S-CSCF3), die eine Benachrichtigung (CX-PUT) vorgenommen haben, daß sie der Bereitstellung der Sitzungssteuerung für weitere Sitzungen bezogen auf den Benutzer mit der öffentlichen Kennung zugeordnet sind.
  23. System nach einem der Ansprüche 15 bis 22, wobei die Bearbeitungsmittel für die Abwicklung eines an den Benutzer adressierten Sitzungsaufbaus weiterhin ausgestaltet sind zur Bearbeitung einer Sitzungsanforderung (INVITE) enthaltend eine öffentliche Kennung bezogen auf die Teilnahmeberechtigung des Benutzers gemäß dem Registrierungsstatus der öffentlichen Kennungen und der privaten Kennungen des Benutzers dienen.
  24. System nach Anspruch 23, wobei die Bearbeitungsmittel ausgestaltet sind zum Weiterleiten der Sitzungsanforderung an ein Endgerät (UE) aus einer Mehrzahl von Endgeräten (UE1, UE2, UE3) mit einer für die Teilnahmeberechtigung gewährten Registrierung (200 OK), oder aufeinanderfolgenden Weiterleiten der Sitzungsanforderung an mehr als ein Endgerät aus der Mehrzahl von Endgeräten (UE1, UE2, UE3), bis die Sitzung einem davon zugeteilt wird, oder dem gleichzeitigen Weiterleiten der Sitzungsanforderung an mehr als ein Endgerät aus der Mehrzahl von Endgeräten (UE1, UE2, UE3).
  25. System nach Anspruch 23, wobei die Bearbeitungsmittel umfassen: Mittel zum Empfangen einer Aufenthaltsortanforderungsanfrage (CX-LOCATION-QUERY) enthaltend die empfangene öffentliche Kennung in der Heimat-Server-Einrichtung (HSS), Mittel zum Beantworten (CX-LOCATION-QUERY RESP) der Aufenthaltsortanforderungsanfrage mit Informationen zur weiteren Abwicklung der Sitzungsanforderung, wobei die Informationen jeweils eines des folgenden bzw. eine beliebige Kombination davon umfassen: eine Liste enthaltend Informationen bezogen auf eine oder mehrere Sitzungssteuerungs-Server-Einrichtungen (S-CSCF1, S-CSCF2, S- CSCF3), die zur Bereitstellung der Sitzungssteuerung für den Benutzer mit der empfangenen öffentlichen Kennung zugeordnet sind, eine Liste enthaltend Informationen bezogen auf eine oder mehrere Sitzungssteuerungs-Server-Einrichtungen (S-CSCF1, S-CSCF2, S-CSCF3), die zur Bereitstellung der Sitzungssteuerung für den Benutzer mit einer der öffentlichen Kennungen zugeordnet sind, wobei die Informationen eines Sitzungssteuerungs-Servers (S-CSCF) weiterhin begleitet werden von einer öffentlichen Kennung zum Ersetzen, als empfangene öffentliche Kennung, der ursprünglich empfangenen öffentlichen Kennung wann immer der Sitzungssteuerungs-Server (S-CSCF) dem Benutzer die Sitzungssteuerung mit einer sich von der ursprünglich empfangenen öffentlich Kennung unterscheidenden öffentlichen Kennung bereitstellt.
  26. System nach Anspruch 25, wobei die Bearbeitungsmittel weiterhin ausgestaltet sind zum Weiterleiten der Sitzungsanforderung an einen Sitzungssteuerungs-Server (S-CSCF), der in der Information zur weiteren Abwicklung der Sitzungsanforderung empfangen wurde, oder aufeinanderfolgenden Weiterleiten der Sitzungsanforderung an mehr als einen Sitzungssteuerungs-Server (S-CSCF1, S-CSCF2, S-CSCF3), die in der Information zur weiteren Abwicklung der Sitzungsanforderung empfangen wurden, bis die Sitzung von einem davon zugeteilt wird, oder gleichzeitigen Weiterleiten der Sitzungsanforderung an mehr als einen Sitzungssteuerungs-Server (S-CSCF1, S-CSCF2, S-CSCF3), die in der Information zur weiteren Abwicklung der Sitzungsanforderung empfangen wurden.
  27. System nach Anspruch 26, wobei ein eine Sitzungsanforderung empfangender Sitzungssteuerungs-Server (S-CSCF) ausgestaltet ist zum Weiterleiten der Sitzungsanforderung an eine Erstkontaktpunkt-Server-Einrichtung (P-CSCF) aus einer Mehrzahl von Erstkontaktpunkt-Server-Einrichtungen (P-CSCF1, P-CSCF2, P-CSCF3), durch die eine Registrierung enthaltend die empfangene öffentliche Kennung von dem Sitzungssteuerungs-Server (S-CSCF) gewährt wurde (200 OK), oder aufeinanderfolgendes Weiterleiten der Sitzungsanforderung an mehr als einen Erstkontaktpunkt-Server (P-CSCF) aus einer Mehrzahl von Erstkontaktpunkt-Servern (P-CSCF1, P-CSCF2, P-CSCF3), bis die Sitzung von einem davon zugeteilt wird, oder gleichzeitiges Weiterleiten der Sitzungsanforderung an mehr als einen Erstkontaktpunkt-Server (P-CSCF) aus einer Mehrzahl von Erstkontaktpunkt-Servern (P-CSCF1, P-CSCF2, P-CSCF3).
  28. System nach Anspruch 27, wobei eine eine Sitzungsanforderung empfangende Kontaktpunkt-Server-Einrichtung (P-CSCF) ausgestaltet ist zur Weiterleitung der Sitzungsanforderung an ein Endgerät (UE) aus einer Mehrzahl von Endgeräten (UE1, UE2, UE3), wobei der Erstkontaktpunkt-Server einen Zugriff mit einer gewährten Registrierung (200 OK) unter Verwendung der öffentlichen Kennung bereitstellt, oder aufeinanderfolgenden Weiterleitung der Sitzungsanforderung an ein Endgerät (UE) aus einer Mehrzahl von Endgeräten (UE1, UE2, UE3), bis die Sitzung einem davon zugeteilt wird, oder gleichzeitiges Weiterleiten der Sitzungsanforderung an mehr als ein Endgerät (UE) aus einer Mehrzahl von Endgeräten (UE1, UE2, UE3).
DE60202527T 2001-07-03 2002-06-14 Verfahren und system zur behandlung von mehrfachanmeldungen Expired - Lifetime DE60202527T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP01116146 2001-07-03
EP01116146 2001-07-03
PCT/EP2002/006557 WO2003005669A1 (en) 2001-07-03 2002-06-14 Method and system for handling multiple registration

Publications (2)

Publication Number Publication Date
DE60202527D1 DE60202527D1 (de) 2005-02-10
DE60202527T2 true DE60202527T2 (de) 2006-03-30

Family

ID=8177929

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60202527T Expired - Lifetime DE60202527T2 (de) 2001-07-03 2002-06-14 Verfahren und system zur behandlung von mehrfachanmeldungen

Country Status (6)

Country Link
US (1) US7177642B2 (de)
EP (1) EP1402705B1 (de)
AT (1) ATE286641T1 (de)
DE (1) DE60202527T2 (de)
ES (1) ES2235065T3 (de)
WO (1) WO2003005669A1 (de)

Families Citing this family (176)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60141522D1 (de) * 2000-08-08 2010-04-22 Convergin Israel Ltd Schnittstelle für intelligente netzwerkdienste
US7239861B2 (en) * 2002-08-26 2007-07-03 Cisco Technology, Inc. System and method for communication service portability
KR100513022B1 (ko) * 2002-09-10 2005-09-05 삼성전자주식회사 무선 고속 데이터 시스템에서 공중망과 사설망의 데이터위치 저장기 공통 사용 방법 및 시스템
KR100477670B1 (ko) * 2002-09-26 2005-03-18 삼성전자주식회사 스마트 카드를 이용한 모니터 보안 장치 및 그 방법
CN1275419C (zh) * 2002-10-18 2006-09-13 华为技术有限公司 一种网络安全认证方法
JP4022131B2 (ja) * 2002-11-21 2007-12-12 富士通株式会社 端末装置の位置登録方法、プログラム及び装置
US9369498B2 (en) * 2003-01-30 2016-06-14 Nokia Technologies Oy Message-based conveyance of load control information
EP2276219A1 (de) 2003-02-19 2011-01-19 Nokia Corporation Routing von Nachrichten über ein IMS System
US7412521B2 (en) 2003-03-12 2008-08-12 Microsoft Corporation End-point identifiers in SIP
US7535878B2 (en) 2003-03-28 2009-05-19 Intel Corporation Method, apparatus and system for ensuring reliable access to a roaming mobile node
US20040205212A1 (en) * 2003-03-31 2004-10-14 Nokia Corporation Method and system for forwarding a service-related information to a network user
GB0307853D0 (en) * 2003-04-04 2003-05-14 Nokia Corp Registrations in a communication system
GB0311006D0 (en) 2003-05-13 2003-06-18 Nokia Corp Registrations in a communication system
US20040242241A1 (en) * 2003-05-30 2004-12-02 Strom Thomas Dale Method for providing calling party location information
FI20030961A (fi) * 2003-06-27 2004-12-28 Nokia Corp Menetelmä päätelaitteiden välisen ryhmäpuhelun muodostamisen tehostamiseksi ja päätelaite
JP2005073236A (ja) * 2003-08-06 2005-03-17 Matsushita Electric Ind Co Ltd 中継サーバ、中継サーバのサービス管理方法、サービス提供システム、およびプログラム
US7280533B2 (en) 2003-10-15 2007-10-09 Nokia Corporation System and method for presence-based routing of communication requests over a network
GB0324597D0 (en) * 2003-10-21 2003-11-26 Nokia Corp A communication system
US7580396B2 (en) 2003-11-05 2009-08-25 Intel Corporation Method, apparatus and system for obtaining and retaining a mobile node home address
US20050111380A1 (en) * 2003-11-25 2005-05-26 Farid Adrangi Method, apparatus and system for mobile nodes to dynamically discover configuration information
US20050113109A1 (en) * 2003-11-25 2005-05-26 Farid Adrangi Method, apparatus and system for context-based registrations based on intelligent location detection
US20050111454A1 (en) * 2003-11-25 2005-05-26 Narjala Ranjit S. Method, apparatus and system for intelligently and dynamically routing mobile internet protocol packets
US20050136924A1 (en) * 2003-12-04 2005-06-23 Farid Adrangi Method, apparatus and system for enabling roaming mobile nodes to utilize private home IP addresses
FI20031784A0 (fi) * 2003-12-05 2003-12-05 Nokia Corp Rekisteröinnin kontrollointi viestintäjärjestelmässä
GB0329857D0 (en) * 2003-12-23 2004-01-28 Nokia Corp User registration in a communication system
EP1703746B1 (de) * 2004-01-07 2012-10-03 Huawei Technologies Co., Ltd. Verfahren zur verringerung der schnittstellenlast eines heim-teilnehmer-servers
GB0409496D0 (en) 2004-04-28 2004-06-02 Nokia Corp Subscriber identities
GB0409704D0 (en) * 2004-04-30 2004-06-02 Nokia Corp A method for verifying a first identity and a second identity of an entity
US8868772B2 (en) 2004-04-30 2014-10-21 Echostar Technologies L.L.C. Apparatus, system, and method for adaptive-rate shifting of streaming content
US20050286487A1 (en) * 2004-06-29 2005-12-29 Interdigital Technology Corporation Distributed routing of data flow
US20070294336A1 (en) * 2004-07-02 2007-12-20 Greg Pounds Proxy-based communications architecture
US20060018272A1 (en) 2004-07-20 2006-01-26 Nokia Corporation Instance identification
US20060067244A1 (en) * 2004-09-30 2006-03-30 Microsoft Corporation Registration identifier reuse
US7453876B2 (en) * 2004-09-30 2008-11-18 Lucent Technologies Inc. Method and apparatus for providing distributed SLF routing capability in an internet multimedia subsystem (IMS) network
ATE545997T1 (de) 2004-12-17 2012-03-15 Tekelec Us Verfahren, systeme und computerprogrammprodukte zur unterstützung des datenbankzugriffs in einer netzwerkumgebung des internet-protokoll- multimedia-subsystems (ims)
CA2595077C (en) * 2005-01-19 2015-08-25 Telefonaktiebolaget Lm Ericsson (Publ) A method and apparatus for handling emergency calls
US7865188B2 (en) * 2005-01-21 2011-01-04 Oracle Israel Ltd. Convergence of ancillary call services across multiple communication domains
WO2006077587A2 (en) * 2005-01-21 2006-07-27 Convergin Israel Ltd. Service convergence across multiple communication domains
US20080311899A1 (en) * 2005-01-26 2008-12-18 Sharp Kabushiki Kaisha Mobile Communication Network Subscriber Information Management System, Subscriber Information Management Method, Communication Control Device, Communication Terminal Device, and Communication Control Method
GB0502383D0 (en) * 2005-02-04 2005-03-16 Nokia Corp User identities
BRPI0520180B1 (pt) * 2005-04-01 2018-08-14 Telefonaktiebolaget Lm Ericsson Método para iniciar uma comunicação de subsistema multimídia ip para um usuário.
DE102005015111A1 (de) * 2005-04-01 2006-10-05 Siemens Ag Aufrechthaltung von Daten-Verbindungen beim Wechsel des Kommunikationsnetzes
EP1875767B1 (de) * 2005-04-29 2016-09-14 Telefonaktiebolaget LM Ericsson (publ) Dienstprofilverwaltung in ims
GB2425685B8 (en) * 2005-04-29 2015-07-29 Ericsson Telefon Ab L M Method and apparatus for handling IP multimedia core network subsystems public user identities
KR100910801B1 (ko) * 2005-05-02 2009-08-04 엘지전자 주식회사 Ｓｉｐ 기반의 세션 셋업 방법 및 장치
FI20050494A0 (fi) * 2005-05-10 2005-05-10 Nokia Corp Palvelun tarjoaminen tietoliikennejärjestelmässä
GB2427098B (en) * 2005-05-27 2009-10-28 Orange Personal Comm Serv Ltd Apparatus for service delivery to communications devices
US7594020B2 (en) * 2005-05-31 2009-09-22 Microsoft Corporation Re-establishing a connection for an application layer via a service layer
US8087069B2 (en) * 2005-06-13 2011-12-27 Nokia Corporation Method, apparatus and computer program product providing bootstrapping mechanism selection in generic bootstrapping architecture (GBA)
US8353011B2 (en) * 2005-06-13 2013-01-08 Nokia Corporation Apparatus, method and computer program product providing mobile node identities in conjunction with authentication preferences in generic bootstrapping architecture (GBA)
CN100382503C (zh) * 2005-06-20 2008-04-16 华为技术有限公司 一种在用户注册过程中注册异常的处理方法
FR2887721B1 (fr) * 2005-06-27 2007-08-03 Alcatel Sa Enregistrement d'informations ims multiples relatives a un terminal multimodes d'un client d'un reseau de communication connecte a des reseaux d'acces de types differents
CN100379316C (zh) * 2005-07-05 2008-04-02 华为技术有限公司 传统终端用户接入ims域的实现方法及系统
CN1327681C (zh) * 2005-08-08 2007-07-18 华为技术有限公司 一种实现初始因特网协议多媒体子系统注册的方法
CN100388685C (zh) * 2005-08-30 2008-05-14 华为技术有限公司 Ip多媒体子系统中ims注册触发实现方法
DE602006011182D1 (de) 2005-08-31 2010-01-28 Huawei Tech Co Ltd Verfahren zur sitzungsverarbeitung in einem ims und einer anrufstatus-abfrage-kontrollfunktion
FR2892254B1 (fr) * 2005-10-19 2008-02-22 Alcatel Sa Procede de telecommunication pour un reseau du type ims, serveur et terminal implementant un tel procede
DE102005052262B4 (de) * 2005-11-02 2007-10-25 Siemens Ag Verfahren zur Auswahl einer S-CSCF-Einheit innerhalb eines IMS basierten Dienstekommunikationssystems
US8634425B2 (en) * 2005-11-04 2014-01-21 At&T Intellectual Property I, L.P. Profile sharing across persona
US8553679B2 (en) 2005-11-04 2013-10-08 At&T Intellectual Property I, L.P. Enabling multiple service profiles on a single device
JP4648214B2 (ja) * 2006-02-14 2011-03-09 富士通株式会社 呼制御装置および呼制御方法
US7675854B2 (en) 2006-02-21 2010-03-09 A10 Networks, Inc. System and method for an adaptive TCP SYN cookie with time validation
EP2066091B1 (de) * 2006-03-01 2010-08-25 Nokia Siemens Networks GmbH & Co. KG Verfahren zur eigenständigen Bereitstellung von Teilnehmerdaten im IP-Multimedia-Subsystem (IMS)
CN101052054B (zh) * 2006-04-04 2010-09-08 中兴通讯股份有限公司 保持ps域和ims域ip地址注销一致性的方法
GB2437344B (en) * 2006-04-21 2008-06-18 Motorola Inc A subscriber server system for a cellular communication system
US8243715B2 (en) * 2006-05-15 2012-08-14 Oracle Israel Ltd. Delivering sip-based call services to circuit-switched terminals
US8151322B2 (en) 2006-05-16 2012-04-03 A10 Networks, Inc. Systems and methods for user access authentication based on network access point
DE102006026929B4 (de) * 2006-06-09 2008-03-06 Siemens Ag Verfahren zur mehrfachen Registrierung eines multimodalen Kommunikationsendgerätes
US20080014961A1 (en) * 2006-07-12 2008-01-17 Tekelec Methods, systems, and computer program products for providing geographically diverse IP multimedia subsystem (IMS) instances
US8149725B2 (en) * 2006-07-31 2012-04-03 Tekelec Methods, systems, and computer program products for a hierarchical, redundant OAM&P architecture for use in an IP multimedia subsystem (IMS) network
CN101507227B (zh) * 2006-08-23 2013-09-04 艾利森电话股份有限公司 用于在ims域中登记非ims用户设备的方法
US8543118B1 (en) 2006-09-29 2013-09-24 Sprint Communications Company L.P. Multidomain, intercarrier network-to-network interface
US20080090569A1 (en) * 2006-10-13 2008-04-17 At&T Knowledge Ventures, L.P. Method and apparatus for performing signal processing in an ip multimedia subsystem network
US8312507B2 (en) * 2006-10-17 2012-11-13 A10 Networks, Inc. System and method to apply network traffic policy to an application session
US8584199B1 (en) * 2006-10-17 2013-11-12 A10 Networks, Inc. System and method to apply a packet routing policy to an application session
US7716378B2 (en) 2006-10-17 2010-05-11 A10 Networks, Inc. System and method to associate a private user identity with a public user identity
US20080115125A1 (en) * 2006-11-13 2008-05-15 Cingular Wireless Ii, Llc Optimizing static dictionary usage for signal compression and for hypertext transfer protocol compression in a wireless network
US8929360B2 (en) * 2006-12-07 2015-01-06 Cisco Technology, Inc. Systems, methods, media, and means for hiding network topology
US10389762B2 (en) * 2006-12-19 2019-08-20 Bce Inc. Method, system and apparatus for causing a communication client to join a media-over-packet communication session
CN101569218B (zh) * 2006-12-21 2012-07-18 Lm爱立信电话有限公司 在多媒体网络中处理服务请求的方法和设备
EP2099156B1 (de) * 2006-12-29 2014-05-07 Huawei Technologies Co., Ltd. Verfahren und system und netzwerkelement zur dienstverarbeitung nach netzwerkelement-dateninvalidierung und auftritt von fehler
KR100946900B1 (ko) * 2007-01-11 2010-03-09 삼성전자주식회사 Ｉｍｓ 재등록 방법 및 이를 위한 시스템
CN100551146C (zh) * 2007-01-22 2009-10-14 华为技术有限公司 一种实现用户身份关联的方法、系统及装置
US8068469B2 (en) * 2007-02-14 2011-11-29 Alcatel Lucent Surrogate registration in internet protocol multimedia subsystem for users indirectly coupled via an end point
EP1990968A1 (de) * 2007-05-07 2008-11-12 Nokia Siemens Networks Oy Verfahren für den Betrieb eines Telekommunikationssystems
KR101398908B1 (ko) * 2007-05-22 2014-05-26 삼성전자주식회사 모바일 아이피를 사용하는 이동 통신 시스템에서 단말의이동성 관리 방법 및 시스템
CA2687664A1 (en) * 2007-07-27 2009-02-05 Nec Corporation Communication system, user equipment registration method, switching device and user equipment registration system
EP2028910A1 (de) 2007-08-21 2009-02-25 NEC Corporation Verfahren zur Zulassung eines UICC zur Verwaltung von PDP-Kontextparametern
CN101378327A (zh) * 2007-08-29 2009-03-04 中国移动通信集团公司 通信网络系统和通信网络业务处理方法
CN101141691B (zh) * 2007-10-11 2011-06-22 中兴通讯股份有限公司 P-cscf识别禁止呼叫用户的方法及系统
US9538360B2 (en) * 2007-12-27 2017-01-03 Nokia Technologies Oy Apparatus, method and computer-readable storage medium for registering user identities
WO2009086938A1 (en) * 2008-01-11 2009-07-16 Telefonaktiebolaget Lm Ericsson (Publ) Securing contact information
ES2390988T3 (es) * 2008-01-11 2012-11-20 Telefonaktiebolaget L M Ericsson (Publ) Gestión de mensajes en un subsistema multimedia IP
US8134956B2 (en) * 2008-01-24 2012-03-13 At&T Intellectual Property I, L.P. System and method of providing registration alert in an IMS system
US9246951B2 (en) * 2008-01-24 2016-01-26 At&T Intellectual Property I, L.P. System and method of remotely de-registering devices in IMS system
US20090191873A1 (en) * 2008-01-24 2009-07-30 At&T Labs System and method of registering users at devices in an ip multimedia subsystem (ims) using a network-based device
US9246950B2 (en) * 2008-01-24 2016-01-26 At&T Intellectual Property I, L.P. System and method of providing registration macros in an IMS network-based device
US9241253B2 (en) * 2008-01-24 2016-01-19 At&T Intellectual Property I, L.P. System and method of providing a user with a registration review in IMS system
WO2009124938A2 (en) 2008-04-08 2009-10-15 Nokia Siemens Networks Oy Correlating communication sessions
EP2272242B1 (de) * 2008-04-08 2014-03-05 Nokia Solutions and Networks Oy Korrelierende kommunikationssitzungen
US8325800B2 (en) 2008-05-07 2012-12-04 Microsoft Corporation Encoding streaming media as a high bit rate layer, a low bit rate layer, and one or more intermediate bit rate layers
US8379851B2 (en) 2008-05-12 2013-02-19 Microsoft Corporation Optimized client side rate control and indexed file layout for streaming media
US8370887B2 (en) * 2008-05-30 2013-02-05 Microsoft Corporation Media streaming with enhanced seek operation
ES2624232T3 (es) * 2008-06-11 2017-07-13 Nokia Solutions And Networks Oy Método, aparato, sistema y producto de programa informático relacionado para gestión de traspaso
US7836185B2 (en) * 2008-06-27 2010-11-16 International Business Machines Corporation Common resource management in a server cluster
US8422488B2 (en) * 2008-06-27 2013-04-16 Telefonaktiebolaget L M Ericsson (Publ) Registration of private user identities and contact addresses in an IMS network
US9219733B2 (en) * 2008-06-30 2015-12-22 Microsoft Technology Licensing, Llc Software-based aliasing for accessing multiple shared resources on a single remote host
CN102077544B (zh) * 2008-06-30 2014-03-26 爱立信电话股份有限公司 在ip多媒体子系统网络中提供位置信息
US8880067B2 (en) * 2008-08-08 2014-11-04 Qualcomm Incorporated Correlating registrations originating from a device
US8971884B2 (en) 2008-09-30 2015-03-03 At&T Mobility Ii Llc Rejection notification to a universal integrated circuit card
US8265140B2 (en) * 2008-09-30 2012-09-11 Microsoft Corporation Fine-grained client-side control of scalable media delivery
KR101006318B1 (ko) 2008-10-10 2011-01-06 주식회사 케이티 인터넷 기반의 호 처리 방법 및 시스템
WO2010090426A2 (en) 2009-02-03 2010-08-12 Samsung Electronics Co., Ltd. Supplementary service provision method and system for ims-based network
US8493933B2 (en) * 2009-05-27 2013-07-23 Oracle International Corporation Providing session-based services to event-based networks using partial information
CN102474502B (zh) * 2009-08-11 2015-11-25 瑞典爱立信有限公司 用于针对本地网络中的设备实现多媒体服务的方法和装置
US20120173736A1 (en) * 2009-09-18 2012-07-05 Deutsche Telekom Ag Method for supporting a user equipment lacking globally routable user agent uri - gruu support in an internet protocol multimedia subsystem - ims
US9960967B2 (en) * 2009-10-21 2018-05-01 A10 Networks, Inc. Determining an application delivery server based on geo-location information
US8611344B2 (en) * 2009-12-28 2013-12-17 At&T Intellectual Property I, L.P. Method and apparatus for providing multi-homing to an aggregate endpoint device
US9055546B2 (en) * 2010-05-03 2015-06-09 Telefonaktiebolaget L M Ericsson (Publ) Handling a registration timer to provide service continuity in IMS
US9019954B2 (en) * 2010-06-18 2015-04-28 Telefonaktiebolaget L M Ericsson (Publ) Methods and apparatuses for handling public identities in an internet protocol multimedia subsystem network
KR101666594B1 (ko) * 2010-07-19 2016-10-14 에스케이텔레콤 주식회사 Ｓｉｐ 서비스 시스템 및 그 제어방법
US9806965B2 (en) * 2010-09-29 2017-10-31 Avaya Inc. Automatic user redundancy determination
US9215275B2 (en) 2010-09-30 2015-12-15 A10 Networks, Inc. System and method to balance servers based on server load status
US8780797B2 (en) * 2010-10-29 2014-07-15 Cellco Partnership Universal integrated circuit card activation in a hybrid network
US9609052B2 (en) 2010-12-02 2017-03-28 A10 Networks, Inc. Distributing application traffic to servers based on dynamic service response time
US9253178B2 (en) * 2011-01-17 2016-02-02 Telefonaktiebolaget L M Ericsson Method and apparatus for authenticating a communication device
EP2671396B1 (de) 2011-02-04 2019-07-24 Tekelec, Inc. Verfahren, systeme und computerlesbare medien zur bereitstellung eines durchmesserbindenden depots
WO2012116235A2 (en) * 2011-02-23 2012-08-30 T-Mobile Usa, Inc. System and method for subscribing for internet protocol multimedia subsystems (ims) services registration status
US8918469B2 (en) 2011-03-01 2014-12-23 Tekelec, Inc. Methods, systems, and computer readable media for sharing diameter binding data
CN103477661B (zh) 2011-03-01 2016-10-05 泰科来股份有限公司 用于基于混合会话的Diameter路由的方法、系统和计算机可读介质
CN103535080B (zh) 2011-05-06 2017-07-18 泰科来股份有限公司 用于在接入网络之间转换用户的方法、系统和计算机可读媒体
US8897154B2 (en) 2011-10-24 2014-11-25 A10 Networks, Inc. Combining stateless and stateful server load balancing
US8571564B2 (en) * 2011-11-14 2013-10-29 Movirtu Limited Method and system for enabling usage of mobile telephone services on a donor device
US9386088B2 (en) 2011-11-29 2016-07-05 A10 Networks, Inc. Accelerating service processing using fast path TCP
US9094364B2 (en) 2011-12-23 2015-07-28 A10 Networks, Inc. Methods to manage services over a service gateway
US10044582B2 (en) 2012-01-28 2018-08-07 A10 Networks, Inc. Generating secure name records
US9118618B2 (en) 2012-03-29 2015-08-25 A10 Networks, Inc. Hardware-based packet editor
US8782221B2 (en) 2012-07-05 2014-07-15 A10 Networks, Inc. Method to allocate buffer for TCP proxy session based on dynamic network conditions
US9372963B2 (en) * 2012-08-30 2016-06-21 Verizon Patent And Licensing Inc. User device selection
US9106561B2 (en) 2012-12-06 2015-08-11 A10 Networks, Inc. Configuration of a virtual service network
US10021174B2 (en) 2012-09-25 2018-07-10 A10 Networks, Inc. Distributing service sessions
US9843484B2 (en) 2012-09-25 2017-12-12 A10 Networks, Inc. Graceful scaling in software driven networks
US9705800B2 (en) 2012-09-25 2017-07-11 A10 Networks, Inc. Load distribution in data networks
US10002141B2 (en) 2012-09-25 2018-06-19 A10 Networks, Inc. Distributed database in software driven networks
US20140095653A1 (en) * 2012-09-28 2014-04-03 Suzann Hua Optimization Of SH Traffic By A Cache-And-Try-First Mechanism
US9338225B2 (en) 2012-12-06 2016-05-10 A10 Networks, Inc. Forwarding policies on a virtual service network
US9576007B1 (en) 2012-12-21 2017-02-21 Google Inc. Index and query serving for low latency search of large graphs
US9531846B2 (en) 2013-01-23 2016-12-27 A10 Networks, Inc. Reducing buffer usage for TCP proxy session based on delayed acknowledgement
US9319378B2 (en) 2013-01-23 2016-04-19 Tekelec, Inc. Methods, systems, and computer readable media for using a diameter routing agent (DRA) to obtain mappings between mobile subscriber identification information and dynamically assigned internet protocol (IP) addresses and for making the mappings accessible to applications
US9900252B2 (en) 2013-03-08 2018-02-20 A10 Networks, Inc. Application delivery controller and global server load balancer
WO2014144837A1 (en) 2013-03-15 2014-09-18 A10 Networks, Inc. Processing data packets using a policy based network path
US10038693B2 (en) 2013-05-03 2018-07-31 A10 Networks, Inc. Facilitating secure network traffic by an application delivery controller
US10027761B2 (en) 2013-05-03 2018-07-17 A10 Networks, Inc. Facilitating a secure 3 party network session by a network device
US9122853B2 (en) 2013-06-24 2015-09-01 A10 Networks, Inc. Location determination for user authentication
CN103607411B (zh) * 2013-12-02 2017-06-16 中国联合网络通信集团有限公司 一种ims用户标识的处理方法及装置
US10230770B2 (en) 2013-12-02 2019-03-12 A10 Networks, Inc. Network proxy layer for policy-based application proxies
US11165770B1 (en) 2013-12-06 2021-11-02 A10 Networks, Inc. Biometric verification of a human internet user
US9942152B2 (en) 2014-03-25 2018-04-10 A10 Networks, Inc. Forwarding data packets using a service-based forwarding policy
US9942162B2 (en) 2014-03-31 2018-04-10 A10 Networks, Inc. Active application response delay time
US9906422B2 (en) 2014-05-16 2018-02-27 A10 Networks, Inc. Distributed system to determine a server's health
US9992229B2 (en) 2014-06-03 2018-06-05 A10 Networks, Inc. Programming a data network device using user defined scripts with licenses
US9986061B2 (en) 2014-06-03 2018-05-29 A10 Networks, Inc. Programming a data network device using user defined scripts
US10129122B2 (en) 2014-06-03 2018-11-13 A10 Networks, Inc. User defined objects for network devices
US10268467B2 (en) 2014-11-11 2019-04-23 A10 Networks, Inc. Policy-driven management of application traffic for providing services to cloud-based applications
JP6260568B2 (ja) * 2015-03-26 2018-01-17 コニカミノルタ株式会社 画像処理システム、携帯端末装置の一時使用許可方法、画像処理装置及びプログラム
US10951519B2 (en) 2015-06-17 2021-03-16 Oracle International Corporation Methods, systems, and computer readable media for multi-protocol stateful routing
US10581976B2 (en) 2015-08-12 2020-03-03 A10 Networks, Inc. Transmission control of protocol state exchange for dynamic stateful service insertion
US10243791B2 (en) 2015-08-13 2019-03-26 A10 Networks, Inc. Automated adjustment of subscriber policies
US9923984B2 (en) 2015-10-30 2018-03-20 Oracle International Corporation Methods, systems, and computer readable media for remote authentication dial in user service (RADIUS) message loop detection and mitigation
US10554661B2 (en) 2015-08-14 2020-02-04 Oracle International Corporation Methods, systems, and computer readable media for providing access network session correlation for policy control
US10084755B2 (en) 2015-08-14 2018-09-25 Oracle International Corporation Methods, systems, and computer readable media for remote authentication dial in user service (RADIUS) proxy and diameter agent address resolution
US9668134B2 (en) 2015-08-14 2017-05-30 Oracle International Corporation Methods, systems, and computer readable media for providing access network protocol interworking and authentication proxying
US9668135B2 (en) 2015-08-14 2017-05-30 Oracle International Corporation Methods, systems, and computer readable media for providing access network signaling protocol interworking for user authentication
EP3545660B1 (de) * 2016-11-25 2022-09-28 Extreme Networks, Inc. Korrelation und lastausgleich von ims-verkehr in einem sichtbarkeitsnetzwerk
US10708780B2 (en) * 2018-01-29 2020-07-07 Silicon Laboratories Inc. Registration of an internet of things (IoT) device using a physically uncloneable function
US11283883B1 (en) 2020-11-09 2022-03-22 Oracle International Corporation Methods, systems, and computer readable media for providing optimized binding support function (BSF) packet data unit (PDU) session binding discovery responses

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5764730A (en) * 1994-10-05 1998-06-09 Motorola Radiotelephone having a plurality of subscriber identities and method for operating the same
FI104139B (fi) * 1996-11-27 1999-11-15 Nokia Telecommunications Oy Kahden SIM-kortin käyttäminen samalla MSISDN-numerolla
US5943620A (en) * 1996-12-09 1999-08-24 Ericsson Inc. Method for associating one directory number with two mobile stations within a mobile telecommunications network
US6311063B1 (en) * 1997-12-10 2001-10-30 Mci Communications Corporation Method of and system for emulation of multiple subscriber profiles on a single mobile phone in a wireless telecommunications network
CN1113577C (zh) * 1998-04-17 2003-07-02 瑞士电信流动电话公司 漫游方法和所属装置
US6778828B1 (en) * 1999-04-12 2004-08-17 Lucent Technologies Inc. Personal mobility registration system for registration of a user's identity in a telecommunications terminal
US6904035B2 (en) * 2000-11-29 2005-06-07 Nokia Corporation Mobile system, terminal and interface, as well as methods for providing backward compatibility to first and second generation mobile systems
US20020131395A1 (en) * 2001-03-19 2002-09-19 Chenghui Wang Session initiation protocol (SIP) user agent in a serving GPRS support node (SGSN)

Also Published As

Publication number Publication date
EP1402705B1 (de) 2005-01-05
ES2235065T3 (es) 2005-07-01
DE60202527D1 (de) 2005-02-10
US20050009520A1 (en) 2005-01-13
ATE286641T1 (de) 2005-01-15
EP1402705A1 (de) 2004-03-31
WO2003005669A1 (en) 2003-01-16
US7177642B2 (en) 2007-02-13

Similar Documents

Publication Publication Date Title
DE60202527T2 (de) Verfahren und system zur behandlung von mehrfachanmeldungen
DE60303004T2 (de) Kommunikationsknoten-architektur
DE60309592T2 (de) Verfahren zum Routing von Dienstanforderungen in einem Netz, mittels E.164-Nummern und DNS
DE102006026929B4 (de) Verfahren zur mehrfachen Registrierung eines multimodalen Kommunikationsendgerätes
DE60206525T2 (de) Zugangsbereitstellungverfahren und -system zu teilnehmerdiensten
DE60117713T2 (de) Verfahren zum transferieren von teilnehmerdaten zwischen verschiedenen servern eines telekommunikationsnetzes
DE60209007T2 (de) Vergebührung in kommunikationssystemen
DE602004008974T2 (de) Server und verfahren zur steuerung der verwaltung von gruppen
EP1536661A2 (de) Verfahren zum Registrieren eines Kommunikationsgeräts, zugehöriges Kommunikationsgerät sowie Registrierungseinheit
DE60315361T2 (de) Verfahren und vorrichtung zum routen einer dienstanforderung
DE60114163T2 (de) Ip kommunikation in einem zellularen kommunkationssystem
DE602004008741T2 (de) Nachrichten-basierte verteilung von last kontrollinformationen
DE60222874T2 (de) Trassierungsverfahren und -system
DE10116547A1 (de) Registrierung eines Endgeräts in einem Datennetz
DE10223248A1 (de) Verfahren zum Registrieren eines Kommunikationsendgeräts
DE60213484T2 (de) Kommunikationssystem
DE102010043878A1 (de) Teilnehmeridentifikationseinrichtung und Verfahren zur Teilnehmerauthentisierung
CN101621500A (zh) 通信系统、通信终端设备及会议控制单元
US20100048195A1 (en) Method and saving entity for setting service
DE60032070T2 (de) Architektur zur Bereitstellung von Leistungsmerkmalen für drahtlose Anrufe in einem drahtlosen Telekommunikationssystem
EP2031885B1 (de) Verfahren zur Portierung und Vermittlung von Nummern in IMS-Domänen
DE102005014480A1 (de) Verfahren und System zur Durchsetzung geeigneter Richtlinien für Datenverkehr in einem Funk-Kommunikationssystem
DE60306234T2 (de) Verarbeitung einer Dienstanfrage eines umherstreifenden Endgeräts
DE60201657T2 (de) Portabilität einer teilnehmer-id
WO2008058841A2 (de) Bootstrapping-verfahren

Legal Events

Date Code Title Description
8364 No opposition during term of opposition