EP1809001A1 - Verfahren und Vorrichtung zur Registrierung in einem IMS mit einer GRUU - Google Patents

Verfahren und Vorrichtung zur Registrierung in einem IMS mit einer GRUU Download PDF

Info

Publication number
EP1809001A1
EP1809001A1 EP06000639A EP06000639A EP1809001A1 EP 1809001 A1 EP1809001 A1 EP 1809001A1 EP 06000639 A EP06000639 A EP 06000639A EP 06000639 A EP06000639 A EP 06000639A EP 1809001 A1 EP1809001 A1 EP 1809001A1
Authority
EP
European Patent Office
Prior art keywords
register
contact
subscriber
cscf
terminal
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.)
Withdrawn
Application number
EP06000639A
Other languages
English (en)
French (fr)
Inventor
Peter Leis
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.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Siemens AG
Nokia Siemens Networks GmbH and Co KG
Siemens Corp
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 Siemens AG, Nokia Siemens Networks GmbH and Co KG, Siemens Corp filed Critical Siemens AG
Priority to EP06000639A priority Critical patent/EP1809001A1/de
Priority to PCT/EP2006/069196 priority patent/WO2007087917A1/de
Publication of EP1809001A1 publication Critical patent/EP1809001A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]

Definitions

  • the invention relates to a method for registering a subscriber in a cellular mobile radio network.
  • IM Intelligent Multimedia Core Network Subsystem
  • SIP REGISTER Session Initiation Protocol
  • IMS Intelligent Multimedia Core Network Subsystem
  • S-CSCF Serving Call Session Control Function
  • S-CSCF Serving Call Session Control Function
  • the registration information of the subscriber present in the S-CSCF is also required by other nodes in the network in order to be able to offer corresponding services.
  • Examples include application servers connected to the S-CSCF.
  • One way of sending this registration information from the S-CSCF to the application server in the SIP-based IMS is the so-called "3 rd party REGISTER" method described in the 3GPP TS 24.229.
  • the S-CSCF upon receipt of a REGISTER message, the S-CSCF sends the subscriber a REGISTER message derived therefrom to the corresponding application server (see also FIG. 1).
  • the S-CSCF is always specified as the contact for a public user ID, ie the application server has no information about the true contact, ie an address that describes the terminal.
  • the object of the present invention is to allow a possible registration of a subscriber from several terminals in a cellular mobile network using a CSCF server as efficient and reliable as possible discrimination for registrations by the multiple terminals of this subscriber in an application server ,
  • the object is achieved in each case by the subject matters of the independent patent claims.
  • an application server can subscribe to the so-called reg-event package (RFC 3680) as described in 3GPP TS 24.229.
  • ROC 3680 the so-called reg-event package
  • the application server receives the exact registration state of the subscriber, i. He knows how many registrations there are for a public user ID.
  • terminal contact information for example, address information such as GRUU globally routable user URI
  • SIP registration message for example, SIP registration message
  • S-CSCF server for example, S-CSCF server of a telecommunications network
  • transfer (also) of this terminal contact information from the CSCF server to an application server allows easy and efficient differentiation of multiple devices of a subscriber based on the application server notified (GRUU) contact information.
  • the S-CSCF can use a so-called GRUU ("globally routable user URI", see draft-ietf-sipgruu) in the contact header as contact information when sending the 3 rd party REGISTER message to the application server.
  • GRUU global routable user URI
  • terminals support the GRUU mechanism according to draft-ietf-sipgruu.
  • the new information in the contact header (ie the GRUU) clearly allows the application server to "bind" between the GRUU and the registered public user ID, he can also assign a unique contact to this registration.
  • the application server can also uniquely address terminals. For this he can use the GRUU as a request URI in a SIP message and set up a session e.g. to enable a service.
  • FIG. 1 a possible registration of two terminals UE_1, UE_2 of a subscriber with an S-CSCF server of a mobile radio network and registration of the subscriber with an application server,
  • Figure 2 shows an inventive registration of two terminals of a subscriber in an S-CSCF server and registration of the two terminals by their contact information at an application server.
  • FIG. 1 shows two terminals UE_1, UE_2 of a subscriber, the terminal UE_1 representing a subscriber identity representing the identity of the subscriber (in the terminals UE_1, UE_2) "Public ID X” and a contact information "contact_1" (for example a Terminal identity).
  • the subscriber identity indication "Public ID X” and the terminal UE_1 concerning terminal contact information "contact_1” are sent in a message "REGISTER-1" , For this purpose, an acknowledgment "200 OK" is sent back to the terminal UE_1 by the S-CSCF server.
  • the S-CSCF server can use a message "REGISTER_1_S_CSCF” to send to an application server the subscriber identity information "Public ID X" and the SIP URI address of the S-CSCF.
  • the application server can not distinguish whether the registration is from the same terminal or from different terminals and therefore asks Hereafter "3 rd party REGISTER" message to the S-CSCF regarding the terminal identities.
  • FIG. 2 (“3rd party REGISTER" in the IMS with GRUU), it is illustrated how a "public user ID X" is first registered by the terminal UE_1 in the IMS (Register_1, Register_1_GRUU1); Subsequently, this public user ID is also registered by a second terminal UE_2.
  • the REGISTER messages indicate support for the GRUU mechanism.
  • the IMS core IMS core network
  • the generation of a GRUU for the respective registration is initiated and the unique GRUUs thus generated are communicated to the two terminals in the 200 OK messages (2000K_GRUU1, 2000K_GRUU2).
  • GRUU_1 and GRUU_2 are sent in the 3 rd party REGISTER messages (REGISTER_1_GRUU1, REGISTER_2_GRUU2) sent to the application server as contact information in the contact header of the messages, respectively.
  • the application server now has sufficient information to distinguish between the two registrations and, if required, can also address (and in particular also address) either UE_1 or UE_2 in a clearly targeted manner.
  • the invention enables an efficient discrimination of a plurality of terminals of a subscriber who is registered by the several terminals in each case via an S-CSCF in an application server.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Eine einfache und effiziente Teilnehmer- Registrierung von mehreren Endgeräten eines Teilnehmers aus, die eine Unterscheidung der Endgeräte des Teilnehmers in einem von einem S-CSCF-Server informierten Applikations-Server erlaubt wird ermöglicht durch ein Verfahren zur Registrierung (Register_1, Register_1_GRUU_1, Register_2, Register 2 GRW 2) in einem zellularen Mobilfunknetz (S-CSCF, Applikations-Server), dadurch gekennzeichnet, dass von einem Endgerät (UE_1) eines Teilnehmers ("Public ID X") an einen S-CSCF-Server (S-CSCF) eine die Teilnehmeridentität des Teilnehmers betreffende Teilnehmeridentitätsinformation ("public ID-X") und eine dieses Endgerät (UE_1) betreffende Endgerät-Kontaktinformation enthaltende SIP-Registrierungsnachricht (Register_1) gesendet wird,
worauf der S-CSCF-Server an einen Applikations-Server eine Nachricht (Register_1_GRUU_1) sendet, welche die Endgerätkontaktinformation (contact_1, repräsentiert durch eine GRUU) betreffend das Endgerät (UE_1) und eine die Teilnehmeridentität des Teilnehmers betreffende Teilnehmeridentitätsinformation(public_ID_X) enthält.

Description

  • Die Erfindung betrifft ein Verfahren zur Registrierung eines Teilnehmers in einem zellularen Mobilfunknetz.
  • Im aus 3GPP bekannten (www.3gpp.org), SIP- basierten (SIP = Session Initiation Protocol) IM (IM = Intelligent Multimedia) Core Network Subsystem (IMS) meldet sich ein Teilnehmer mit einer so genannten "SIP REGISTER" Nachricht im Netzwerk an und signalisiert so seine Bereitschaft zur Kommunikation. Diese SIP REGISTER Nachricht wird im Netzwerk in einer S-CSCF ("Serving Call Session Control Function") bearbeitet und terminiert. Die S-CSCF implementiert hierfür die Rolle eines so genannten SIP Registrar (siehe RFC 3261). Beginnend mit dem Rel-6 kann ein Teilnehmer die gleiche öffentliche Adresse, im IMS Public User Identity (Public ID X) genannt, von mehreren Endgeräten aus im Mobilfunknetz registrieren. Dieses feature wird als shared public user ID bezeichnet.
  • Die in der S-CSCF vorhandene Registrierungs-Information des Teilnehmers wird auch von anderen Knoten im Netz benötigt um entsprechende Dienste anbieten zu können. Beispiel hierfür sind Applikations-Server die an die S-CSCF angeschlossen sind.
  • Eine Möglichkeit, im SIP- basierten IMS diese Registrierungs-information von der S-CSCF an den Applikations-Server zu senden, ist das so genannte "3rd party REGISTER" Verfahren, das in der 3GPP TS 24.229 beschrieben ist. Hierbei sendet die S-CSCF bei Erhalt einer REGISTER Nachricht vom Teilnehmer eine daraus abgeleitete REGISTER Nachricht an die entsprechenden Applikations-Server (s. a. Fig. 1).
  • Die 3rd party REGISTER Nachricht ist in 3GPP TS 24.229 wie folgt beschrieben
    • To header: public user identity wie in der REGISTER Nachricht vom UE erhalten
    • Contact header: gesetzt auf die SIP URI der S-CSCF's
    • Expires header: enthält den Wert, wie er von der S-CSCF in der 200 (OK) response Nachricht an das Endgerät UE zurückgesendet wird.
  • Das heißt, in einer 3rd party REGISTER Nachricht ist immer die S-CSCF als Kontakt für eine public user ID angegeben, d.h. der Applikations-Server hat keine Information über den wahren Kontakt, d.h. eine Adresse die das Endgerät beschreibt.
  • Daraus ergeben sich folgende Probleme:
    1. A) Beim feature "shared public user ID" hat der Teilnehmer die Möglichkeit, eine public user ID von verschiedenen Endgeräten gleichzeitig im IMS zu registrieren. Aber ein Applikations-Server kann anhand der 3rd party REGISTER nicht erkennen, dass die 3rd party REGISTER von der Registrierung der gleichen public user ID durch unterschiedliche Endgeräte getriggert wurde, da dafür kein Parameter vorgesehen ist. Anstatt dessen enthalten die 3rd party REGISTER immer die S-CSCF Adresse als Kontakt- Information und die public user ID im To header als public user ID für die diese Registrierung gültig ist. Die IP Adresse des Teilnehmers kann als Kontakt nicht an den Applikations-Server gegeben werden, da diese Adresse von einem IMS Operator nicht an Betreiber von Applikations-Servern weitergegeben wird (wegen erforderlicher privacy, IP adress hiding, und/oder auch um zu verhindern, dass der AS direkt ohne IMS das Endgerät ansprechen kann). Wenn ein Teilnehmer die gleiche public user ID von mehreren Endgeräten aus registriert, dann ist die Registrierungsinformation für den Applikations-Server (AS) nicht mehr eindeutig, für den AS sehen diese 3rd party REGISTER immer gleich aus, mit public user ID als request URI und contact auf S-CSCF gesetzt. Wenn der Teilnehmer z.B. eine public user ID von 2 Endgeräten registriert hat und nun ein Endgerät deregistriert ,dann hat die daraus resultierende 3rd party REGISTER Nachricht einen expires header mit Wert "0". Dadurch ist die gesamte Registrierung der public user ID im Applikations-Server gelöscht, da der Applikations-Server nicht weiß, ob noch weitere Registrierungen bestehen.
    2. B) Der Applikations-Server kann kein spezielles Endgerät, d.h. keine spezielle Instanz der public user ID ansprechen, da er anhand des 3rd party REGISTER nicht erkennen kann, dass eine public user ID von mehreren Endgeräten benutzt wird. Dies bedeutet, der Applikations-Server kann nicht erkennen von welchem Endgerät die public user ID angemeldet wird.
  • Aufgabe der der vorliegenden Erfindung ist es, bei einer möglichen Registrierung eines Teilnehmers von mehreren Endgeräten aus in einem zellularen Mobilfunknetz unter Verwendung eines CSCF-Servers möglichst effizient und zuverlässig eine Unterscheidungsmöglichkeit für die Registrierungen durch die mehreren Endgeräte dieses Teilnehmers in einem Applikations-Server zu ermöglichen. Die Aufgabe wird jeweils durch die Gegenstände der unabhängigen Patentansprüche gelöst.
  • Um detaillierte Daten bezüglich des Registrierungsstatus zu erhalten, kann ein Applikations-Server sich auf das so genannte reg-event package (RFC 3680) wie in 3GPP TS 24.229 beschrieben, subskribieren. In den daraus resultierenden NOTIFY Nachrichten erhält der Applikations-Server den genauen Registrierungszustand des Teilnehmers, d.h. er weiß, wie viele Registrierungen für eine public user ID vorliegen.
  • Eine Möglichkeit, die einzelnen Endgeräte, die sich eine public user ID teilen, d.h. eine Instanz Endgerät/public user ID, vom Applikations-Server aus anzusprechen ist bisher im 3GPP Standard nicht möglich.
  • Die Übersendung von Endgerätkontaktinformationen (beispielsweise Adressinformationen wie GRUU-Globally Routable User URI) in einer SIP-Registrierungsnachricht eines Teilnehmers an einen S-CSCF-Server eines Telekommunikationsnetzes und Übergabe (auch) dieser Endgeräte-Kontaktinformation vom CSCF-Server an einen Applikations-Server ermöglicht einfach und effizient eine Unterscheidung mehrerer Endgeräte eines Teilnehmers anhand deren dem Applikations-Server mitgeteilten (GRUU) Kontaktinformation.
  • Erfindungsgemäß kann die S-CSCF beim Senden der 3rd party REGISTER Nachricht an den Applikations-Server eine so genannte GRUU ("globally routable user URI", siehe draft-ietf-sipgruu) im contact header als Kontakt- Information nutzen. Dadurch erhält der Applikations-Server eine Möglichkeit mehrere 3 rd party REGISTER für eine public user ID eindeutig zu unterscheiden.
  • Für das Verfahren zur Erzeugung der GRUU bzw. dafür in welcher funktionalen Einheit die GRUU generiert wird gibt es eine Vielzahl von vorstellbaren Möglichkeiten.
  • Wichtig für das hier beschriebene Verfahren ist, dass die Endgeräte den GRUU Mechanismus entsprechend draft-ietf-sipgruu unterstützen.
  • Wenn jetzt ein Endgerät eine public user ID im IMS anmeldet und den support von GRUU anzeigt, dann würde die S-CSCF, die diese REGISTER Nachricht erhält eine 3rd party REGISTER mit neuer Information an die entsprechenden Applikations-Server senden. Eine entsprechende 3rd party REGISTER Nachricht von der S-CSCF zu einem Applikations-Server würde folgende Information in den header's enthalten:
    • "Request URI": auf SIP Adresse des Applikations-Server
    • "To": public user ID des Teilnehmer
    • "From": auf SIP Adresse der S-CSCF setz
    • "Contact": GRUU, die für diese Instanz erzeugt wurde
  • Durch die neue Information im Contact header (d.h. die GRUU) kann der Applikations-Server eindeutig ein "binding" (Verknüpfung) zwischen der GRUU und der angemeldeten public user ID herstellen, er kann dieser Registrierung auch einen eindeutigen Kontakt zuordnen.
  • Meldet jetzt der Teilnehmer ein anderes Endgerät mit der gleichen public user ID an, dann resultiert daraus eine 3rd party REGISTER mit einer neuen GRUU. Dadurch kann der Applikations-Server die Endgeräte, die mit der gleichen public u-ser ID angesprochen werden können, eindeutig unterscheiden. D.h. er kann die zu den unterschiedlichen Endgeräten/Kontakten gehörenden Datensätze eindeutig zuweisen.
  • Mittels der GRUU kann der Applikations-Server Endgeräte auch eindeutig adressieren. Hierfür kann er die GRUU als request URI in einer SIP Nachricht benutzen und eine Session aufbauen z.B. um einen Service zu ermöglichen.
  • Aus der erfindungsgemäßen Implementierung können sich folgende Vorteile ergeben:
    1. 1. Ein Applikations-Server erhält die Möglichkeit, bei ihm ankommende 3rd party REGISTER's mit der gleichen public user ID eindeutig zu unterscheiden, d.h. die public user ID wird von verschiedenen Endgeräten registriert. Die Implementierung des Applikations-Servers vereinfacht sich, da er jetzt auf Subskribierung auf das reg-event package verzichten kann um herauszufinden, ob für die vorliegende public user ID mehrere Kontakte/Endgeräte angemeldet sind.
    2. 2. Der Applikations-Server erhält die Möglichkeit eine spezielle Instanz einer Registrierung anzusprechen. D.h. er kann für den Fall, dass eine public user ID von mehreren Endgeräten angemeldet wird, dediziert ein Endgerät ansprechen. Da die Endgeräte unterschiedliche Service- Eigenschaften besitzen können (z.B. support von Video), ist diese Möglichkeit für den Applikations-Server sehr wichtig, wenn er bestimmte Services für den Teilnehmer realisieren will.
  • Weitere Merkmale und Vorteile ergeben sich aus den Patentansprüchen und der nachfolgenden Beschreibung eines Ausführungsbeispiels anhand der Zeichnung. Dabei zeigt
  • Figur 1 eine heute mögliche Registrierung von zwei Endgeräten UE_1, UE_2 eines Teilnehmers mit einem S-CSCF-Server eines Mobilfunknetzes und Registrierung des Teilnehmers bei einem Applikations-Server,
  • Figur 2 eine erfindungsgemäße Registrierung zweier Endgeräte eines Teilnehmers bei einem S-CSCF-Server und Registrierung der beiden Endgeräte durch ihre Kontaktinformationen bei einem Applikations-Server.
  • Figur 1 zeigt zwei Endgeräte UE_1, UE_2 eines Teilnehmers, wobei das Endgerät UE_1 eine die Identität des Teilnehmers (in die Endgeräte UE_1, UE_2 gehören) repräsentierende Teilnehmeridentität "Public ID X" repräsentierende Angabe und eine das Endgerät betreffende Kontaktinformation "contact_1" (beispielsweise eine Endgeräts-Identität) gespeichert hat. Bei einer Registrierung des Endgerätes UE_1 mit einer Nachricht "REGISTER_1" bei einem S-CSCF-Server eines Telekommunikationsnetzes werden die Teilnehmeridentitäts-Angabe "Public ID X" und eine das Endgerät UE_1 betreffende Endgerätkontaktinformation "contact_1" in einer Nachricht "REGISTER-1" gesendet. Vom S-CSCF-Server wird hierzu eine Bestätigung "200 OK" an das Endgerät UE_1 zurückgesendet.
  • Der S-CSCF-Server kann mit einer Nachricht "REGISTER_1_S_CSCF" an einen Applikations-Server diesem die Teilnehmeridentitätsangabe "Public ID X" und die SIP-URI-Adresse des S-CSCF senden. Entsprechendes gilt für eine Registrierung des Endgerätes UE_1 bei dem S-CSCF-Server. Der Applikations-Server kann bei einer derartigen Registrierung zweier Endgeräte desselben Nutzers (Public ID X) nicht unterscheiden, ob die Registrierung vom gleichen Endgerät oder von unterschiedlichen Endgeräten erfolgt und fragt deshalb mit "3rd party REGISTER"-Nachricht hiernach beim S-CSCF bezüglich der Endgerätidentitäten an.
  • Im erfindungsgemäßen Ausführungsbeispiel in Figur 2 ("3rd party REGISTER" im IMS mit GRUU) wird dargestellt, wie eine "Public user ID X" zunächst vom Endgerät UE_1 im IMS registriert wird (Register_1, Register_1_GRUU1); anschließend wird diese public user ID auch von einem zweiten Endgerät UE_2 angemeldet. Die REGISTER Nachrichten zeigen den support für den GRUU Mechanismus an. Dadurch wird im IMS core (IMS Kernnetz) die Generierung einer GRUU für die jeweilige Registrierung angestoßen und die so erzeugten eindeutigen GRUUs werden den beiden Endgeräten in den 200 OK Nachrichten (2000K_GRUU1, 2000K_GRUU2) mitgeteilt. Zusätzlich werden GRUU_1 und GRUU_2 in den 3rd party REGISTER Nachrichten (REGISTER_1_GRUU1, REGISTER_2_GRUU2), die zum Applikations-Server gesendet werden jeweils als Kontaktinformation im Contact header der Nachrichten gesendet. Der Applikations-Server hat nun ausreichende Informationen, um die beiden Registrierungen zu unterscheiden und kann bei Bedarf auch entweder UE_1 oder auch UE_2 eindeutig gezielt ansprechen (und insbesondere auch adressieren).
  • Somit ermöglicht die Erfindung eine effiziente Unterscheidung von mehreren Endgeräten eines Teilnehmers der von den mehreren Endgeräten aus jeweils über eine S-CSCF in einem Applikations-Server registriert wird.

Claims (9)

  1. Verfahren zur Teilnehmer-Registrierung (Register_1, Register_1_GRUU_1, Register_2, Register_2_GRUU_2) in einem zellularen Mobilfunknetz (S-CSCF, Applikations-Server), dadurch gekennzeichnet, dass von einem Endgerät (UE_1) eines Teilnehmers (Public ID X) an einen S-CSCF-Server (S-CSCF) jeweils eine die Teilnehmeridentität des Teilnehmers betreffende Teilnehmeridentitätsinformation (Public ID X) und eine dieses Endgerät (UE_1) betreffende Endgerät-Kontaktinformation (GRUU_1) enthaltende SIP-Registrierungsnachricht (Register_1) gesendet wird, worauf der S-CSCF-Server an einen Applikations-Server eine Nachricht (Register_1_GRUU_1) sendet, welche die Endgerätkontaktinformation (contact_1) betreffend das Endgerät (UE_1) und die Teilnehmeridentitätsinformation(Public ID X) enthält.
  2. Verfahren nach Anspruch 1, dadurch gekennze ichnet, dass die Endgerät-Kontaktinformation ("contact_1") eine "globally routable user URI" ist.
  3. Verfahren nach einem der vorhergehenden Patentansprüche, d adurch gekennzeichnet, dass die die Teilnehmeridentität angebende Teilnehmeridentitätsinformation eine "public user ID" des Teilnehmers ist.
  4. Verfahren nach einem der vorhergehenden Ansprüche, dadu rch gekennzeichnet, dass der S-CSCF-Server ein "serving call session control function" Server ist.
  5. Verfahren nach einem der vorhergehenden Ansprüche, dadu rch gekennzeichnet, dass mehrere Endgeräte (UE_1, UE_2) eines Teilnehmers mit unterschiedlicher Endgerätkontaktinformationen (contact _1, contact_2) und gleichen Teilnehmeridentitätsinformationen (Public ID X) im Telekommunikationsnetz registriert werden.
  6. Verfahren nach einem der vorhergehenden Patentansprüche, d adurch gekennzeichnet, dass der Applikations-Server mehrere Endgeräte (UE_1, UE_2) eines Teilnehmers, die die gleiche Teilnehmeridentifikationsinformation (Public ID X) verwenden, anhand ihrer zueinander unterschiedlichen Endgerätekontaktinformation (contact_1, contact_2) unterscheidet.
  7. Verfahren nach Anspruch 6, dadurch gekennze ichnet, dass der Applikations-Server die Endgeräte (UE_1, UE_2) unterscheidet unter Verzicht auf eine Rückfrage mit einer "reg-event"-Nachricht bei einem S-CSCF-Server.
  8. Verfahren nach einem der vorhergehenden Ansprüche, dadu rch gekennzeichnet, dass der S-CSCF-Server mit einer Einrichtung zum Empfangen von Nachrichten (REGISTER-1, REGISTER-2) von Endgeräten (UE_1, UE_2) mit gleichen Teilnehmeridentitätsangaben (Public ID X) und unterschiedlichen die Identität der Endgeräte (UE_1, UE_2) repräsentierenden Endgerät-Kontaktinformationen (contact_l, contact_2) und mit einer Einrichtung zum Senden von die Teilnehmeridentitäts-Angaben (Public ID X) und Endgerät-Kontaktinformations-Angaben (contact_1, contact_2) an einen Applikations-Server aufweist.
  9. Applikations-Server mit einer Einrichtung zum Empfangen von Nachrichten (REGISTER_1_GRUU1, REGISTER_2_GRUU2) eines S-CSCF-Servers und einer Einrichtung zum Unterscheiden von unterschiedlichen Endgeräten (UE_1, UE_2) mit gleicher Teilnehmer-Identitätsangabe (Public ID X) anhand von in den Nachrichten (REGISTER_1_GRUU1, REGISTER_2_GRUU2) enthaltenen die Endgeräte betreffenden Endgerät-Kontaktinformationen (contact_1, contact_2).
EP06000639A 2006-01-12 2006-01-12 Verfahren und Vorrichtung zur Registrierung in einem IMS mit einer GRUU Withdrawn EP1809001A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP06000639A EP1809001A1 (de) 2006-01-12 2006-01-12 Verfahren und Vorrichtung zur Registrierung in einem IMS mit einer GRUU
PCT/EP2006/069196 WO2007087917A1 (de) 2006-01-12 2006-12-01 Verfahren und vorrichtung zur registrierung in einem ims mit einer gruu

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP06000639A EP1809001A1 (de) 2006-01-12 2006-01-12 Verfahren und Vorrichtung zur Registrierung in einem IMS mit einer GRUU

Publications (1)

Publication Number Publication Date
EP1809001A1 true EP1809001A1 (de) 2007-07-18

Family

ID=36603534

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06000639A Withdrawn EP1809001A1 (de) 2006-01-12 2006-01-12 Verfahren und Vorrichtung zur Registrierung in einem IMS mit einer GRUU

Country Status (2)

Country Link
EP (1) EP1809001A1 (de)
WO (1) WO2007087917A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015026930A1 (en) * 2013-08-21 2015-02-26 Qualcomm Incorporated Updating contact information for client devices registered to the same user for an internet protocol multimedia subsystem service

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102025695A (zh) * 2009-09-11 2011-04-20 中兴通讯股份有限公司 一种识别pui类型的方法、设备及系统
CN104270493A (zh) * 2014-09-15 2015-01-07 倪敏俊 一种单位通讯录安全管理方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005055549A1 (en) * 2003-12-01 2005-06-16 France Telecom System for providing services in response to a communications session message

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005055549A1 (en) * 2003-12-01 2005-06-16 France Telecom System for providing services in response to a communications session message

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
3GPP: "Supporting Globally Routable User Agent URI in IMS", TR23.8DE V0.1.0, November 2005 (2005-11-01), 3GPP, 3rd Generation Partnership Project, XP002388320 *
KYZIVAT CISCO SYSTEMS P ET AL: "Reg Event Package Extension for GRUUs; draft-kyzivat-sipping-gruu-reg event-03.txt", IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, no. 3, 15 July 2005 (2005-07-15), XP015040492, ISSN: 0000-0004 *
RESEARCH IN MOTION: "GRUU impacts on core entities", SA-052503, 7 November 2005 (2005-11-07), 3GPP TSG SA WG2, XP002388321 *
ROSENBERG CISCO SYSTEMS J: "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP); draft-ietf-sip-gruu-06.txt", IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, vol. sip, no. 6, 20 October 2005 (2005-10-20), XP015042701, ISSN: 0000-0004 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015026930A1 (en) * 2013-08-21 2015-02-26 Qualcomm Incorporated Updating contact information for client devices registered to the same user for an internet protocol multimedia subsystem service
US9215256B2 (en) 2013-08-21 2015-12-15 Qualcomm Incorporated Updating contact information for client devices registered to the same user for an internet protocol multimedia subsystem service

Also Published As

Publication number Publication date
WO2007087917A1 (de) 2007-08-09

Similar Documents

Publication Publication Date Title
EP1536661B1 (de) Verfahren zum Registrieren eines Kommunikationsgeräts, zugehöriges Kommunikationsgerät sowie Registrierungseinheit
EP2005697B1 (de) Netzwerk-initiierte ims registrierung in einem kommunikationssystem
EP2826224B1 (de) Zugriff von clients auf einen serverdienst mittels einer opc-ua
DE10116547A1 (de) Registrierung eines Endgeräts in einem Datennetz
DE102004026785B4 (de) Kommunikationssystem, Kommunikationsendgerät, Konferenzsteuereinheit, Verfahren zum Steuern eines Kommunikationssystems, Verfahren zum Steuern eines Kommunikationsendgeräts und Verfahren zum Steuern einer Konferenzsteuereinheit
DE60031817T2 (de) Verfahren zum Kommunikationssitzungsaufbau zwischen einem Endgerät eines paketbasierten Netzwerks und einem Endgerät verbunden mit einem Fernzugriffsserver
DE10059175A1 (de) Verfahren und Vorrichtung zur Anrufumleitung mittels eines Stellvertreters in einem Kommunikationssystem
WO2007141159A1 (de) Verfahren zur mehrfachen registrierung eines multimodalen kommunikationsendgerätes
EP1869928B1 (de) Aufrechterhaltung von daten-verbindungen beim wechsel des kommunikationszugangsnetzes
EP1555786A1 (de) Verfahren zum Aufbauen einer Datenverbindung zwischen einem ersten und einem zweiten mobilen Kommunikationsendgerät
EP1809001A1 (de) Verfahren und Vorrichtung zur Registrierung in einem IMS mit einer GRUU
DE602004006171T2 (de) Sitzungseinleitungsprotokollsignalisierung (sip)
DE102022121503A1 (de) Verfahren und IP-Multimedia-Subsystem zum Durchführen einer Datenübertragung, Computerprogrammprodukt und Speichermedium
DE10322539A1 (de) Verfahren zum Aufbau einer Kommunikationsverbindung und Kommunikationssystem
EP1771993B1 (de) Verfahren zur überwachung eines nachrichtenverkehrs, sowie eine erste und zweite netzwerkeinheit zu dessen durchführung
DE10234920B4 (de) Verfahren und eine Vorrichtung in einem Kommunikationsnetz, zum Abruf von Eigenschaften mindestens einer Netzwerkeinheit von anderen Netzwerkeinheiten und zum Informieren dieser anderen Netzwerkeinheiten darüber, dass sich bestimmte Eigenschaften einer Netzwerkeinheit geändert haben
EP1309146B1 (de) Verfahren zur Kommunikation zweier Netzeinrichtungen auf Basis einer Ende-zu-Ende-Verbindung und Netzeinrichtung dafür
DE102022121507B4 (de) Verfahren und IP-Multimedia-Subsystem zum Durchführen einer Datenübertragung, Computerprogrammprodukt und Speichermedium
DE102004032923B4 (de) Verfahren zum Registrieren eines Kommunikationsendgeräts, Kommunikationssystem, Verfahren zum Steuern eines Kommunikationsendgeräts und Kommunikationsendgerät
WO2008022613A2 (de) Verfahren zum erzeugen einer kommunikationssitzung - steuernachricht unter verwendung von sip
DE102008045790B4 (de) Verfahren und Kommunikationsnetz zum mehrfachen Umleiten einer Kommunikationsverbindung
DE102004043533B4 (de) Überlaststeuerung in einem IP-Kommunikationsnetz
WO2004086717A1 (de) Verfahren zur übertragung von daten in einem datennetz mit einer mehrzahl von rechnern
DE102005046927A1 (de) Verfahren zur Ermittlung der in zumindest einem Kommunikationsendgerät verfügbaren Kommunikationsdienste
WO2006042800A1 (de) Aufbau einer dienste-verbindung zwischen einem endgerät und einem ersteren netzelement mit unterschiedlichen ip-protokoll-versionen

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS S.P.A.

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

17P Request for examination filed

Effective date: 20080118

17Q First examination report despatched

Effective date: 20010221

AKX Designation fees paid

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20090801