ES2235065T3 - Metodo y sistema para gestionar multiples registros. - Google Patents

Metodo y sistema para gestionar multiples registros.

Info

Publication number
ES2235065T3
ES2235065T3 ES02748776T ES02748776T ES2235065T3 ES 2235065 T3 ES2235065 T3 ES 2235065T3 ES 02748776 T ES02748776 T ES 02748776T ES 02748776 T ES02748776 T ES 02748776T ES 2235065 T3 ES2235065 T3 ES 2235065T3
Authority
ES
Spain
Prior art keywords
user
session
cscf
public
received
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
ES02748776T
Other languages
English (en)
Inventor
Juan Antonio Sanchez Herrero
John Michael 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
Application granted granted Critical
Publication of ES2235065T3 publication Critical patent/ES2235065T3/es
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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Hardware Redundancy (AREA)

Abstract

Un método para manejar múltiples registros de un usuario en un sistema de telecomunicaciones que gestiona o administra información de localización o situación o información de identificación relacionada con sus usuarios, estando relacionado cada uno de dichos registros a una suscripción de dicho usuario en dicho sistema, comprendiendo el método las operaciones de: a) almacenar, relacionada con dicha suscripción, una pluralidad de identidades privadas; b) recibir solicitudes de registro (REGISTRO), solicitando cada solicitud de registro para unir un terminal (UE1, UE2, UE3) a dicho sistema para dicha suscripción, y c) tratar cada solicitud de registro recibida de acuerdo con la identidad privada, entre dicha pluralidad de identidades privadas, recibidas en dicha solicitud; caracterizado porque la operación c comprende la operación de tratar una solicitud de registro de acuerdo con dicha identidad privada recibida y una identidad pública recibida en dicha solicitud.

Description

Método y sistema para gestionar múltiples registros.
Campo del invento
El presente invento se refiere a sistemas de telecomunicaciones que requieren gestionar o administrar información relacionada con la localización o situación de sus usuarios así como información relacionada con los identificadores que acceden e identifican a cada uno de esos usuarios en dichos sistemas. Más precisamente, se relaciona con el soporte de múltiples registros de, al menos, un usuario de uno de dicho sistema de telecomunicaciones, dichos registros múltiples solicitados desde una pluralidad de terminales, y con el manejo adicional de establecimiento de sesión múltiple hacia dicha pluralidad de terminales.
Antecedentes
Los usuarios abonados o suscritos a los servicios provistos por un sistema de telecomunicaciones son usualmente asignados a identificadores (identificadores de abonado, identidades de abonado, o ID de abonado). Para una suscripción dada de un usuario en un sistema de telecomunicación dado, al menos un ID de abonado es usado para ser asignado. Dicho ID de abonado identifica de manera única dicha suscripción y es usado en dicho sistema con propósitos de acceso e identificación. El tipo, contenido, e incluso el número de ID de abonado por usuario, depende básicamente de las características del sistema de telecomunicaciones.
Por ejemplo, en un sistema de telecomunicaciones tal como una Red de Telefonía Conmutada Pública (PSTN) o Red Digital de Servicios Integrados (ISDN), los usuarios son asignados a un número de teléfono como ID de abonado (aunque puede ser asignado más de un número de teléfono por usuario en dichos sistemas). Estos números de teléfono están de acuerdo con el formato especificado en la recomendación ITU-T E.164 (Mayo de 1997) y, son asignados por usuario de acuerdo con un plan de numeración específico. Una vez que se ha asignado un número E.164 a un usuario de una PSTN, dicho número es usado tanto: para direccionar (encaminar) llamadas a dicho usuario, como también para identificar a dicho usuario dentro de la red.
Como en esta clase de sistemas con cable el punto en el sistema de telecomunicaciones en el que el usuario accede al servicio que dicho sistema proporciona (el punto de acceso) es fijo, el usuario se supone que puede ser alcanzable en el terminal conectado a dicho punto de acceso y, por ello, el usuario no es usualmente forzado a registrar (unir) antes de tener acceso a los servicios proporcionados por el sistema de telecomunicaciones.
En otro sistema de telecomunicaciones, tal como por ejemplo en un sistema móvil de 2G (segunda generación) (tal como un Sistema Global para comunicaciones Móviles, o GSM), o en un sistema móvil de 3G (tercera generación) (también conocido como Sistema Universal de Telecomunicaciones Móviles, o UMTS), dicho ID de abonado no es único por usuario. Un usuario dado abonado a uno de dichos sistemas de 2G o de 3G es asignado a un identificador privado único (identidad privada o ID privado) y, al menos, a un identificador público (identidad pública o ID público).
También, en oposición a sistemas de telecomunicaciones tradicionales que usan tecnologías de acceso fijo (cableado) (por ejemplo: PSTN), en sistemas móviles el mismo usuario puede acceder a dicho sistema desde diferentes puntos de acceso; es decir: desde diferentes localizaciones. Debido a esto, dicho usuario registra su presencia desde un punto de acceso diferente en un momento dado (por ejemplo: cada vez desde el mismo o diferente terminal a través del mismo o diferente servidor de acceso por radio); por ello, el usuario registrada (une) su presencia en un punto de acceso dado desde un terminal dado antes de acceder a otros servicios, tales como hacer o recibir llamadas. Dentro de dicho proceso (denominado a continuación como registro), el terminal de usuario identifica la suscripción que mantiene y quiere activar, y esto es conseguido enviando (entre otros datos de autentificación e identificación) el ID privado ha asociado a dicha suscripción.
Una vez que el registro de un usuario de 2G o 3G ha funcionado satisfactoriamente, dicho usuario puede recibir sesiones entrantes (por ejemplo: llamadas de voz) en su terminal desde otros usuarios que han "marcado" el ID publico (uno de los ID públicos) asociado a dicha suscripción de dicho usuario. Es decir: el ID público es utilizado por otros usuarios como un "número de teléfono" antes mencionado.
En este punto, será observado que el término "sesión", siempre que se cita dentro de este invento, abarca distintas clases de comunicaciones que, de acuerdo con los sistemas de telecomunicaciones y protocolos de telecomunicación del estado de la técnica, pueden ser establecidos entre pares de comunicación; así, no estando limitado a "llamadas de voz" tradicionales proporcionadas por sistemas y protocolos basados en circuitos conmutados bien conocidos, sino también comprendiendo comunicaciones proporcionadas por sistemas y protocolos basados en paquetes conmutados (o células conmutadas), que proporcionan comunicaciones con capacidades de múltiples medios, tales como audio, vídeo y datos, incluso simultáneamente dentro de la misma comunicación. Ejemplos de dichas comunicaciones, conocidos como "comunicaciones multimedia" (también como "sesiones multimedia" o "llamadas multimedia"), están descritos, por ejemplo, en la recomendación ITU-T H.323 (noviembre de 2000), o en el RFC-2543 "Protocolo de Inicio de Sesión", del IETF, SIP (Marzo de 1999).
Para una suscripción dada de un usuario dado en un sistema de 2G o 3G, un servidor de hogar dado en el sistema (conocido como Registrador de Localización Local o Doméstico o HLR, o Servidor de Abonado Local o Doméstico o HSS) conserva, entre otros datos, y como una parte de los SD (datos de abonado) relacionados a dicha suscripción, la relación entre dicha suscripción de dicho usuario y el ID privado y los ID públicos asociados a él. Dichos servidores locales o domésticos (por ejemplo HLR O HSS) están principalmente encargados de atender la solicitud desde otros nodos o servidores dentro del sistema siempre que una solicitud de registro de un usuario dado necesita ser atendida (es decir: concedida o rechazada), o siempre que la información de localización de un usuario dado es necesaria (por ejemplo: al llamar a dicho usuario).
En sistemas de 2G o 3G, el ID privado de un usuario dado es único por suscripción de usuario y es usado dentro del sistema de 2G o 3G con propósitos de identificación interna en el registro, autorización, administración, etc.
Para una suscripción dada, dicho ID privado es almacenado también en un módulo de identidad de abonado conocido por ejemplo como SIM, o USIM para 3G, que está incluido en la tarjeta de abonado por ejemplo una tarjeta de Módulo de Identidad de Abonado o tarjeta SIM, o tarjeta de Circuito Integrado de UMTS o UICC, proporcionada a dicho usuario, junto con otra información de seguridad relacionada con dicha suscripción tal como claves secretas usadas para la autentificación. Dicha tarjeta de abonado (tarjeta SIM, UICC) está destinada a ser acomodada, bien: fija o retirable, en terminales de usuario usados para acceder a dichos sistemas.
De modo contrario los ID públicos, ID privados no necesitan ser conocidos por los usuarios de dichos sistemas, ni conocidos por otros usuarios de otros sistemas de telecomunicaciones, ya que no están destinados a ser suministrados (es decir: "marcados") por un usuario dado para establecer una comunicación con otro usuario; es decir: dichos ID privados no están destinados a ser usados como "número llamado", ni destinados a identificar la llamada o parte conectada en la presentación del terminal del usuario final.
En sistemas de 2G, un ID privado toma el formato de IMSI (Identidad de Abonado Móvil Internacional); mientras que en sistemas de 3G, un ID privado toma la forma de un NAI (Identificador de Acceso a Red) como se ha definido en RFC-2486 "El identificador de Acceso a Red" (Enero de 1999), en el que el IMSI puede estar contenido dentro del NAI.
En dichos sistemas de 2G O 3G, los ID públicos de un usuario dado están, sin embargo, destinados a direccionar (encaminar) llamadas a dicho usuario, y, por ello, destinados a ser usados como "números de teléfono" son en otros sistemas de telecomunicación por ejemplo PSTN (Red de Telefonía Conmutada Pública), ISDN (Red Digital de Servicios Integrados), incluyendo propósitos de llamadas e identificación de partes conectadas. Así, los ID públicos son usados para establecer comunicaciones entre usuarios, y, por ello, destinados a ser conocidos por los usuarios, no solamente de dichos sistemas móviles (2G o 3G), sino también por usuarios de otros sistemas de telecomunicaciones que pueden interactuar con dichos sistemas de 2G o 3G. De esta manera un usuario (usuario A) que quiere establecer una comunicación con otro usuario (usuario B) necesita suministrar (es decir: "marcar") el ID público de dicho usuario B (o uno de los ID públicos de dicho usuario B) en la solicitud de llamada que dicho usuario A hace. El usuario B, a su vez, puede (si dichos servicio está permitido) identificar la parte que llama a partir del ID público del usuario A que dicho usuario B recibe.
El formato de los ID públicos de un usuario dado puede variar dependiendo de las particularidades del sistema de telecomunicaciones al que dicho usuario está abonado. En sistemas de 2G o 3G, los ID públicos están en el formato de números E.164 (conocidos como números MSISDN) (es decir: son números de teléfono típicos tales como en PSTN). En sistemas de 3G que usan el subsistema así llamado IM (o IMS) (Subsistema Multimedia de Protocolo de Internet), dichos ID públicos pueden también tomar otros formatos, tales como SIP-URL (Localizador de Recursos Uniforme para Protocolo de Inicio de Sesión), TEL-URL (Localizador de Recursos Uniforme para Telefonía), etc.
Dado que los sistemas móviles actuales (2G o 3G) sólo proporcionan un ID privado por suscripción de usuario, y dado que dicho ID privado único es usado en el proceso de registro, dichos sistemas no permiten que un usuario dado se registre en un sistema móvil con referencia a la misma suscripción (es decir: identificando el mismo ID privado en cada solicitud de registro) desde más de un terminal, ya que implicaría la existencia de una localización de clonación de SIM, que significa la existencia de dos tarjetas de suscripción con los mismos datos en ellas. Por ello (e independientemente de distintas técnicas complejas para detección de clonación de SIM), si un usuario dado intenta registrarse y ya tiene un registro activo para su suscripción, dicho nuevo registro es considerado un registro doble y todos los datos relacionados con el viejo registro son sobre-escritos con los datos relacionados al nuevo.
Con esta situación, para un usuario dado que tiene una sola suscripción, solo un registro puede estar activo para dicho usuario y dicha suscripción única, y no están permitidas localizaciones simultáneas para dicha suscripción única. De esta manera, un usuario dado que quiere tener más de un terminal registrado, tiene que mantener más de una suscripción y usar una suscripción diferente para registrar cada uno de dichos terminales.
Sistemas de telecomunicación modernos (tales como sistemas móviles de 3G) están, sin embargo, destinados a ofrecer una gran variedad de servicios. Dependiendo de la naturaleza de dichos servicios, algunos de ellos requerirían algunas capacidades dentro del terminal de usuario final (por ejemplo: un servicio basado en capacidades multimedia o capacidades para transferir ficheros/datos) no necesarias para otros servicios (por ejemplo: un servicio basado en capacidades sólo de voz).
Esto, haría deseable que un usuario dado que tiene una suscripción en uno de dichos sistemas sea registrado desde una pluralidad de terminales simultáneamente (por ejemplo: teniendo cada uno capacidades diferentes); y todo esto, sin perjudicar a aspectos de seguridad que se basan en la identificación de la suscripción de dicho usuario, no forzando a dicho usuario a mantener más de una suscripción.
La fig. 1 ha sido tomada de la especificación técnica TS 23.228 (V5.0.0, Abril de 2001) distribuida por el 3GPP (Proyecto de Asociación de 3ª generación), que es el foro encargado de desarrollar la normas que regulan los sistemas de 3G. Aunque esta figura muestra la relación entre el ID privado y el ID publico de una suscripción dada (suscripción Multimedia de Internet, o suscripción IM) de uno usuario dado (usuario IM) del IMS (Subsistema Multimedia del Protocolo de Internet) de un sistema 3G; realmente muestra la relación unívoca del estado de la técnica existente en sistemas móviles independientemente de su generación (2G o 3G) entre una suscripción y el ID privado asociado a dicha suscripción. Dentro de dicha figura, puede observarse que, incluso aunque un usuario dado que soporta una única suscripción puede ser alcanzado (es decir: llamado) por medio de diferentes ID públicos, la suscripción de dicho usuario es identificada por un único ID privado (y solamente uno).
La relación mostrada en la fig. 1 es mantenida y retenida principalmente en el servidor local de dicho usuario (HSS, HLR), aunque copias y relaciones de dichos datos pueden ser también conservadas y utilizadas en otros nodos (o servidores) dentro del sistema de telecomunicaciones. Sin embargo la lógica inherente a la relación unívoca antes mencionada es desplegada a través de cualquier servidor dentro del sistema de telecomunicación, deshabilitando así tanto: tener múltiples registros activos de un usuario dado que mantiene una única suscripción desde una pluralidad de puntos de acceso, como tener llamadas subsiguientes dirigidas a dicho usuario para ser entregadas a uno o más de dichos puntos de acceso en los que dicho usuario puede estar situado.
Las normas conocidas para sistemas de 3G han considerado la posibilidad de tener tarjetas de abonado UMTS que contienen más de una suscripción (es decir: más de una USIM dentro del mismo UICC) (por ejemplo: 3GPP TS 22.101, v4.0.0, Junio de 2001), permitiendo así que el mismo terminal sea registrado alternativamente para diferentes suscripciones de usuario. Sin embargo, sólo una de estas suscripciones puede estar activa en un momento dado en dicho terminal, y, en cualquier caso, las capacidades inherentes a dichos terminales relacionadas con la clase de sesiones pueden permanecer las mismas independientemente de la suscripción activa.
El SIP (Protocolo de Inicio de Sesión) fue seleccionado por el 3GPP como el protocolo para manejar registros de usuario y control de sesión para usuarios que contienen suscripciones de IM. La especificación de SIP (RFC-2543) permite ya que un usuario dado indique en un mensaje de registro REGISTRO múltiples puntos de contacto en los que dicho usuario puede ser contactado (es decir: alcanzado) para otras sesiones entrantes dirigidas a la identidad (es decir: ID público) contenida en el encabezamiento "desde" o dicho mensaje de REGISTRO. Estos puntos de contacto son incluidos en los subsiguientes encabezamientos "Contacto" dentro de un mensaje o de subsiguientes mensajes de REGISTRO, en los que cada encabezamiento de "Contacto" contiene una dirección de un punto final de SIP dado (es decir: un terminal de SIP habilitado). De acuerdo con esto, un mensaje de REGISTRO SIP desde un usuario dado tal como:
REGISTRO sip:server2.wcom.com
Via:....
Desde:<sip:User@there.com>
A:....
ID de llamada:....
Cseq: 1 REGISTRO
Contacto: <sip:UserB@110.111.112.113>
Contacto: tel:+1-972-555-2222
Longitud del contenido:....
si es aceptado por el servidor de registro "server2.wcom.com", haría que otras sesiones dirigidas a dicho usuario (es decir: otros mensajes de INVITACIÓN que indican en el encabezamiento "A" la entidad "UserB@there.com") son reenviadas simultáneamente a ambos puntos de contacto que fueron especificados en el mensaje REGISTRO: la aplicación SIP en el anfitrión con IP-Addr (Dirección del Protocolo de Internet) 110.111.112.113 en el que dicho usuario ha abierto la sesión como "UserB", y al Número de teléfono "+1-972-555-2222".
Sin embargo, la adaptación y uso del protocolo SIP a la arquitectura específica de IMS en sistemas de 3G ha bloqueado dicha posibilidad, como puede verse en la especificación 3GPP que establece los flujos de señalización para usuarios IM (TS 24.228, V1.0.0, Junio de 2001). En dicha especificación se ha establecido que el contenido del encabezamiento "Contacto" debe ser el IP-Addr que dicho terminal está usando para acceder al sistema de 3G (es decir la dirección IP que dicho terminal tuvo durante el proceso funcionó para tener un proceso de Establecimiento de Contexto a base de paquete portador de radio, conocido como PDP (Protocolo de Datos de Paquete); es decir, la dirección que usa para intercambiar paquetes con el servidor que está sirviendo su acceso al sistema.
Con esta limitación, un usuario dado que contiene una única suscripción de IM en un sistema de 3G, puede tener solo un registro activo al mismo tiempo, estando relacionado dicho registro solo a un punto de acceso al sistema y solo a un terminal unido a dicho punto de acceso e identificado por una dirección única (dirección IP).
Por ello, de acuerdo con el estado de la técnica, un usuario dado al que le gustaría tener múltiples registros activos en cualquiera de dichos sistemas móviles (2G, 3G) que requieren gestionar información relacionada con la localización de dicho usuario para cualquiera de estos registros, así como gestionar información relacionada con los identificadores que acceden e identifican a dicho usuario en dichos sistema, sería forzado para contener diferentes suscripciones. Sin embargo, como cada suscripción individual está contenida separadamente en dichos sistemas, implicando así el tratamiento y administración separados (es decir: registros de cómputo separados, registros de suscripción separados, datos de localización separados, etc.) implicaría dificultades para que el operador del sistema móvil permitiera que los mismos ID públicos, relacionados con el mismo usuario, fueran asignados a más de una suscripción; sin mencionar el inconveniente de que el usuario, tuviera que relacionarse con múltiples facturas para el mismo servicio.
Debe ser entonces deseable una situación en la que, sin tener que apelar a una solución basada en múltiples suscripciones por usuario, un usuario dado que tiene una única suscripción en un sistema de telecomunicaciones (tal como un sistema móvil, u otro sistema de telecomunicaciones de características similares con respecto a identidades del usuario e información de localización), es permitido registrar en dicho sistema desde diferentes terminales simultáneamente, teniendo así múltiple registros activos simultáneamente; y en el que dicho usuario puede recibir llamadas en cualquiera de estos terminales registrados desde otras partes o grupos que han "marcado" un ID publico que está asociado a dicha suscripción única.
El documento US-A-5943620 describe un método para manejar registros múltiples de un usuario en un sistema de telecomunicaciones. En este método, cualquier identidad pública de dicho usuario quedará automáticamente registrada por cualquier solicitud de registro que contenga una identidad privada del usuario, de manera que cualquier otra solicitud de comunicaciones a cualquiera de dichas identidades públicas serán dirigidas a cualquiera de los terminales registrados. Sin embargo, un usuario puede querer registrar un terminal para una sola de sus identidades
públicas.
Resumen del invento
El presente invento proporciona un método para soportar múltiples registros activos de, al menos, un usuario en un sistema de telecomunicaciones, estando dichos registros relacionados a una única suscripción de dicho usuario en dichos sistema y siendo solicitado cada uno desde una pluralidad de terminales (equipo de usuario, o UE). El invento se refiere además a un sistema previsto para poner en práctica dicho método.
De acuerdo con un aspecto del presente invento, se ha creado un método para manejar múltiple registros de un usuario como se ha definido por la reivindicación 1ª.
De acuerdo con otro aspecto del invento, se ha creado un sistema de telecomunicaciones para manejar múltiple registros de una única suscripción en dicho sistema según se ha definido por la reivindicación 15ª.
De acuerdo a una realización preferida de este invento, el sistema de telecomunicaciones comprende una o un conjunto de entidades servidoras funcionales encargadas de distintas funciones, tales como:
- almacenar los datos de abonado de los usuarios de dicho sistema (denominado también como entidad de servidor local, o HSS, HLR),
- dar servicio al acceso a dicho sistema a los terminales (UE) usados por sus usuarios (denominado también como entidad servidora de primer punto de contacto, o Función de Control de Estado de Llamada Proxy o Alterna, P-CSCF),
- dar servicio al manejo inicial de transacciones que implican a usuarios de dicho sistema (denominado también como entidad servidora de interrogación, o Función de Control de Estado de Llamada de Interrogación, I-CSCF), y
- dar servicio a servicios de control de sesión para sesiones que implican usuarios de dichos sistema (denominado también como entidad servidora de control de sesión, o Función de Control de Estado de Llamada Proxy o Alterna, S-CSCF).
Si dichas funciones son realizadas por una única entidad servidora, o por un conjunto de entidades servidoras funcionales distribuidas o situadas en la misma posición, no afecta al marco del presente invento.
Breve descripción de los dibujos
Las características, objetos y ventajas del invento resultarán evidentes leyendo esta descripción en unión con los dibujos adjuntos, en los que:
La fig. 1 muestra la relación 1:N de la técnica anterior entre identidades pública y privada, y la relación 1:1 entre una suscripción de usuario de IM y su correspondiente identidad privada como se ha definido por la norma TS 23.228 de 3GPP antes mencionada.
La fig. 2 muestra un flujo de registro y otro flujo de establecimiento de sesión de una sesión entrante, como se ha definido actualmente por las normas 3GPP.
La fig. 3 muestra una vista simplificada de la técnica anterior de los registros de datos de abonado en un servidor local que almacena cada uno de los datos de suscripción de un usuario dado, en el que el contenido de uno de estos registros es además detallado.
La fig. 4 muestra una relación N:N entre las identidades pública y privada y una relación 1:M entre una suscripción de usuario IM y las identidades privadas para dicha suscripción de usuario de acuerdo con el presente invento.
La fig. 5 muestra un flujo de múltiples registros de acuerdo con el presente invento.
La fig. 6 muestra la misma vista que la fig. 3 de acuerdo con el presente invento.
La fig. 7 muestra el almacenamiento de datos en distintos servidores de acuerdo con una característica opcional de este invento.
La fig. 8 muestra un flujo de establecimiento de sesión múltiple de acuerdo con este invento.
Descripción detallada de las realizaciones preferidas
El invento será descrito ahora en detalle con referencia a las figs. 1 a 8 de acuerdo con una realización preferida. Dicha realización preferida considera, como un ejemplo de un sistema de telecomunicaciones en el que los métodos de este invento pueden aplicarse, un sistema móvil de 3G que emplea el así llamado (IMS) (Subsistema Multimedia de Protocolo de Internet), en que (como se ha estandarizado por el 3GPP) el protocolo bien conocido SIP (Protocolo de Inicio de Sesión) es el protocolo utilizado para manejar registros de usuario y control de sesión para usuarios que contienen suscripciones de IM.
Se comprenderá que el marco del presente invento no está limitado a dichos sistemas de 3G ni a un protocolo de señalización específico; y, una persona experta puede aplicarle fácilmente a cualquier sistema de telecomunicaciones que tiene que gestionar o administrar datos (de aquí en adelante: datos de abonado, o SD) relacionados con, al menos, un usuario que soporta una suscripción en dicho sistema; comprendiendo dicho SD (datos de abonado), al menos, información relacionada a los identificadores utilizados en dicho sistema para identificar y localizar a dicho usuario (ID privado, ID público), y que tiene que gestionar información relacionada con la localización de dicho usuario.
Dicho sistema de telecomunicaciones puede, por ejemplo (pero no limitado ni forzado a), comprender una o un conjunto de entidades de servidor funcionales encargadas de distintas funciones especializadas, tales como: almacenar los datos de abonado de los usuarios de dicho sistema, dar servicio al acceso a dicho sistema para los terminales (UE) usados por sus usuarios, dar servicio al manejo inicial de transacciones que implican a los usuarios de dicho sistema, y dar servicios de control de sesión para sesiones que implican usuarios de dicho sistema. En los que, si dichas funciones son realizadas por una entidad servidora única, o por un conjunto de entidades de servidor funcionales distribuidas o localizadas, no afecta al marco del presente invento. En particular, aspectos a los que se hace referencia si dichas entidades de servidor funcionales son puestos en práctica en entidades física separadas (es decir: máquinas, nodos, servidores) o son puestos en práctica justo como entidades funcionales o bien: colocadas en el mismo sitio o distribuidas entre entidades físicas diferentes, así como aspectos relativos a detalles de la red (o redes) de interconexión que enlazan dichas entidades de servidores (en caso de que sean puestos en práctica en entidades físicas separadas) y aspectos relativos a detalles de la tecnología de acceso utilizada por los terminales de usuario UE para acceder a dicho sistema, no afectan al marco del presente invento.
El sistema de telecomunicaciones, de acuerdo con la realización preferida descrita de aquí en adelante, está previsto para gestionar datos de abonado (SD) relacionados con, al menos, un usuario que contiene una suscripción en dicho sistema. Dichos datos de abonado (SD) comprenden, al menos, información relacionada con los identificadores usados en dicho sistema para identificar y localizar dicho usuario (ID privado, ID público), e información relacionada con la localización de dicho usuario (DATOS DE LOCALIZACIÓN). El sistema de telecomunicación comprende también las entidades de servidor funcionales siguientes:
una entidad de servidor local (HSS/HLR), encargada de almacenar los datos de abonado de los usuarios de dicho sistema;
una entidad de servidor de primer punto de contacto (denominada dentro de este invento como Función de Control de Estado de Llamada Proxy o Alterna o P-CSCF), encargada de dar servicio al acceso a dicho sistema a los terminales (UE) usados por sus usuarios;
una entidad de servidor de interrogación (denominada dentro de este invento como Función de Control de Estado de Llamada de Interrogación o I-CSCF), encargado del manejo inicial de transacciones que implican usuarios de dicho sistema; y
una entidad de servidor de control de sesión (denominado dentro de este invento como Función de Control de Estado de Llamada de Servicio o S-CSCF), encargada de servicios de control de sesión para sesiones que implican usuarios de dicho sistema.
La especificación 3GPP TS 23.002 (V5.2.0, Abril de 2001) define la arquitectura de red general de un sistema de 3G, que comprende las entidades básicas, así como las entidades específicas que pertenecen a los IMS antes definidos (P-CSCF, I-CSCF, S-CSCF, HSS/LR), mientras los flujos de señalización general y detallados están descritos respectivamente en las especificaciones antes mencionadas TS 23.228 y TS 24.228. El contenido detallado de los mensajes (interrogaciones o preguntas, respuestas, notificaciones, etc.) intercambiados a través del así llamado "punto de referencia CX" entre cualquiera de las así llamadas Funciones de Control de Estado de Llamada (o CSCF) y el HSS son además detallados en la especificación 3GPP TS 29.228 (V.0.1.0, Junio de 2001). De acuerdo a la información descrita en las especificaciones 3GPP para IMS (en sus versiones actuales), el protocolo SIP es usado para manejar registros de usuario, y control de sesión para usuarios que contienen suscripciones IM, y el protocolo DIÁMETRO (borrador IETF) es utilizado en el "punto de referencia CX".
En este punto, se observará que, de acuerdo con las especificaciones 3GPP para IMS, las distintas Funciones de Control de Estado de Llamada (o CSCF) independientemente de su función (si P-CSCF, I-CSCF o S-CSCF) son denominadas con sus nombres individuales (como puede verse, por ejemplo, en los flujos de señalización detallados en la especificación 3GPP antes mencionada). Como dichos nombres individuales (por ejemplo: una URL-SIP) han de ser resueltos (utilizando, por ejemplo, Sistema de Nombre de Dominio, DNS, o técnica similar) en las direcciones individuales correspondientes (por ejemplo: una dirección de Protocolo de Internet), usualmente contendrán una parte de dominio que identifica el ámbito de la red del operador de sistema de 3G al que pertenece. Por ejemplo, un nombre tal como "X-CSCF1.ZZZ.NET", en que la "X" existe para cualquier función de entre: proxy (P), interrogación (I) o servicio (S), existe para un X-CSCF llamado "X-CSCF1" dentro del dominio "ZZZ.NET" (es decir: así distinguido de otros CSCF con igual nombre pero que pertenecen a diferentes dominios). De acuerdo con esto, siempre que en este invento es citado un nombre CSCF dado (tal como por ejemplo "P-CSCF2", "S-CSCF1", etc.), se comprenderá que dichos nombres pueden contener también una parte de dominio dentro de su nombre, incluso aunque en algunos ejemplos dentro de este invento no están mostrados; siendo el aspecto relevante que dichos nombres identifican únicamente un CSCF dado dentro de un ámbito de red dado.
Para una mejor comprensión de las nueva disposiciones de métodos y sistemas descritas dentro de este invento, se hará referencia a continuación a las figs. 1 a 3 con el fin de ilustrar el manejo del estado de la técnica de un procedimiento de registro en un sistema de 3G de un usuario dado (usuario IM) que contiene una suscripción única (suscripción IM) en dicho sistema, así como el manejo de otras sesiones entrantes dirigidas a dicho usuario.
En particular, en la fig. 2, las operaciones 1 a 10, muestran un flujo de señalización simplificado de un proceso de registro requerido por un usuario IM dado desde un terminal dado, UE, en un sistema de 3G como resultado del tratamiento de una solicitud de registro REGISTRO, por los medios de tratamiento en las entidades representadas en dicha figura: P-CSCF, I-CSCF, HSS, S-CSCF. Detalles relativos al flujo completo, pueden ser encontrados en las especificaciones de 3GPP antes mencionadas TS 23.228 y 24.228; en las que aspectos que no afectan al marco de este invento, tales como el proceso que el registro UE funciona para dar un descubrimiento P-CSCF a base de paquete portador de radio (establecimiento de contexto PDP), detalles relativos a si el usuario se está registrando desde un sistema 3G (sistema visitado) que no es el sistema 3G en que dicho usuario tiene la suscripción (sistema local), etc., son detallados adicionalmente. Con respecto a esto, y con objeto de una mayor simplicidad, se observará que, en la fig. 2, se han omitido los subflujos de autentificación (que podrían funcionar en esta fase). Dichos subflujos de autentificación podrían estar basados, por ejemplo, en mecanismo de desafío/respuesta (o cualquier otro mecanismo de autentificación conocido); y podría consistir en un "desafío de autentificación" y la "respuesta" subsiguiente a dicho desafío intercambiado entre las entidades de servicio en el 3G y el terminal de registro. En cualquier caso, la posibilidad o no de aplicación de dichos subflujos de autentificación no afectan a la comprensión del flujo de la técnica anterior mostrado en dicha figura con respecto a las modificaciones introducidas por el presente invento que serán explicadas adicionalmente.
En la operación 1 de la fig. 2 dicho usuario envía una solicitud de registro REGISTRO, desde el terminal UE a la entidad de servidor del primer punto de contacto P-CSCF que está dando servicio al acceso de dicho UE a dicho sistema. El procedimiento permite: que tanto el UE como el P-CSCF aprendan la dirección de cada uno de ellos (IP- Addr) pertenece también a la técnica conocida.
El REGISTRO que el UE envía contiene, entre otros datos, algunos datos de identificación que (como se ha esquematizado en las relaciones mostradas en la fig. 1) será usado por el sistema para identificar y autentificar a la suscripción individual a la que dichos datos de identificación pertenecen, y, así, a identificar y autentificar al usuario al que pertenece dicha suscripción. En particular dicha solicitud de registro REGISTRO debe contener (entre otros datos) el ID privado asociado a dicha suscripción, y un ID público entre la pluralidad de ID públicos que están asociados a dicha suscripción; ya que dicha información es necesaria para identificar la suscripción de dicho usuario, y así, hacer coincidir en la entidad de servidor local HSS el registro SD correspondiente que pertenecen a dicha suscripción única de dicho usuario, entre la pluralidad de registros SD que pertenecen a otras suscripciones que son almacenadas en dicho HSS (como se ha mostrado en la fig. 3). Ha de observarse que la inclusión de dicho ID privado (e incluso la inclusión de dicho ID público) en el REGISTRO puede ser, de acuerdo con algunos UE del estado de la técnica, un proceso automático realizado por la aplicación que funciona en el UE, en la que dichos datos son extraídos del USIM contenido en dicho UE.
Cuando la solicitud de registro REGISTRO llega a la entidad de servidor del primer punto de contacto P-CSCF, dicho P-CSCF liga a continuación la dirección del registro UE con el ID público recibido en el REGISTRO y, en la operación 2 de la fig. 2, luego reenvía el REGISTRO a una entidad de servidor de interrogación I-CSCF, en que el P-CSCF ha añadido información relacionada a sí misma como siendo la entidad de servidor del primer punto de contacto P-CSCF que da servicio al acceso de dicho UE. Antes de dicho reenvío, el P-CSCF realiza una interrogación al DNS (Sistema de Nombre de Dominio) con el fin de determinar la entidad de servidor de interrogación correcta I-CSCF a la que reenviar dicho REGISTRO.
Una vez que dicha solicitud de registro REGISTRO llega al I-CSCF, en la operación 3 es realizada una interrogación al HSS a para determinar el estado de registro de usuario CX-Query. Dicha interrogación comprende datos: tanto del ID público y el ID privado recibidos en el REGISTRO, como sobre el modo en que se usarán por el HSS para encontrar el registro SD correspondiente de dicho usuario. Se observará aquí que detalles de puestas en práctica con respecto a dicho registro SD (por ejemplo: si hay un registrador único o hay un conjunto de registros relacionados/enlazados por suscripción de usuario, o incluso si dichos registros residen en el HSS o en otra base de datos) no son relevantes para la comprensión de la técnica anterior ni para el marco del presente invento; siendo el problema relevante para este aspecto que los datos de abonado (SD) de una suscripción dada relacionada con un usuario dado son distinguidos entre otros SD que pertenecen a otras suscripciones de otros usuarios. Con respecto a esto, la fig. 3 vuestra una vista esquemática simplificada de los medios de almacenamiento que contienen SD de una pluralidad de usuarios. En particular la fig. 3 muestra más detallado el contenido de un registro SD dado que pertenece a la suscripción de un usuario dado (representado como USER-N en la figura) en un sistema de 3G, en que los datos almacenados en dicho registro han sido agrupados lógicamente en diferentes clases de datos de acuerdo a su naturaleza y funcionalidad; sin embargo, estos datos pueden existir ordenados y/o a agrupados de otros modos. En la fig. 3, datos almacenados en "DATOS DE IDENTIFICACIÓN" comprenden información estática relacionada con identidades de usuario; entre otros datos, dichos datos de identificación comprenden el ID público (o la pluralidad de ID públicos) asociados a una suscripción única de un usuario dado (representado como "User-N_PUBLIC1", "User-N_PUBLIC2",..., en la figura), así como el solo ID privado (único) asociado a dicha suscripción única (representado como "User-N_PRIVATE" en la figura). En la fig. 3, los datos en "DATOS DE LOCALIZACIÓN" almacenan información relacionada con el servidor que está dando servicio a un registro activo de dicho usuario (si lo hay); siendo su naturaleza completamente dinámica, en oposición a la naturaleza estática de la información en los datos de identificación. Perteneciendo al mismo SD puede haber otros datos almacenados (por ejemplo: datos relacionados con el perfil o perfiles de dicho usuario para dicha suscripción, estado de activación de servicios suplementarios, datos adicionales de servicios suplementarios, etc.) que no están mostrados en detalle dentro de la fig. 3, ya que están más allá del marco del presente invento.
El HSS, al recibir la interrogación en la operación 3 de la fig. 2, y una vez que el registro SD correspondiente ha sido encontrado, realiza una comprobación en los datos de localización de dicho registro SD para verificar si hay ya un registro activo para el ID privado recibido "User-N_PRIVATE". De acuerdo con el estado de la técnica, si en esta operación es detectado en el HSS que hay un registro activo (es decir: los datos de localización no están vacíos), es considerado un nuevo registro, y entonces, el HSS responde de nuevo en la operación 4, con una respuesta a la interrogación sobre el estado de registro CX-Query Resp que comprende información relacionada con el servidor de control de sesión S-CSCF encargado de los servicios de control de sesión para dicho usuario (por ejemplo: "S-CSCF1.HOME1.NET"), junto con una indicación de estado de registro que establece que dicho usuario está ya registrado. De otro modo (es decir: los datos de localización están vacíos), la respuesta a la interrogación de estado de registro (CX-Query Resp) enviada en la operación 4 comprende una indicación de estado de registro que indica que dicho usuario no está registrado, junto (opcionalmente) con las capacidades para seleccionar un S-CSCF dado que ha de ser asignado para dar servicio al control de sesión para dicho usuario.
Si el usuario está ya registrado (por ejemplo: doble registro) entonces el I-CSCF reenvía en la operación 5 el REGISTRO al S-CSCF que fue indicado por el HSS. De otro modo, el usuario no está registrado, entonces selecciona un S-CSCF, y en la operación 5 reenvía dicho REGISTRO a dicho S-CSCF.
Cuando el S-CSCF recibe el REGISTRO, almacena La información incluida en él. En particular almacena el ID privado e ID público recibidos del usuario que se está registrando, e información relacionada al P-CSCF que está dando servicio al acceso del UE desde el que se ha solicitado dicho registro. Entonces el S-CSCF en la operación 6 notifica al HSS que dicho usuario ha sido registrado en dicho S-CSCF (CX-Put); comprendiendo dicha notificación el ID privado e ID público recibidos en el REGISTRO, así como información relacionada con dicho S-CSCF, y un campo "tipo de asignación de servidor" que establece "registro".
A la recepción de dicha notificación, el HSS encuentra el registro SD correspondiente para dicho usuario (por ejemplo: realiza una búsqueda basada en el ID privado y/o público), y almacena en los datos de localización de dicho registro SD información que establece que dicho S-CSCF está prestando servicios de control de sesión para dicho usuario (por ejemplo: "S-CSCF1.HOME1.NET"). Se observará ahora que, como se ha mostrado en el estado de la técnica representado en la fig. 3, sólo un registro puede estar activo en un momento dado para una suscripción de usuario dada; por ello, en un momento dado sólo puede existir una entrada dentro de los datos de localización de un registro SD dados (por ejemplo: una entrada tal como la entrada: "S-CSCF1.HOME1.NET {User-N_PUBLIC2, User-N_PRIVATE"}, mostrado en la fig. 3 para el USER-N). Esto provoca que cualquier entrada almacenada previamente en dichos datos de localización sea sobreescrita a la recepción de una notificación de registro (CX-Put) en el HSS.
A continuación, en la operación 7, el HSS da de nuevo al S-CSCF el resultado del registro en dicho HSS (aceptado o rechazado) junto con datos relacionados con el perfil de usuario del usuario de registro (CX-Put Resp). Si el resultado del registro ha sido satisfactorio, una respuesta de registro (200 OK) es enviada de nuevo a las operaciones 8, 9 y 10 al UE desde el que fue solicitado dicho registro.
Una vez que un usuario dado se ha registrado satisfactoriamente en el sistema de 3G, otras sesiones entrantes (es decir: llamadas de voz, llamadas multimedia, etc.) que son dirigidas al ID público de dicho usuario indicado en la solicitud de registro (REGISTRO) serán entregadas al UE que tiene el registro concedido. Dicha entrega será hecha a través del S-CSCF que fue asignado en dicho registro, y a través del P-CSCF que está dando servicio al acceso a dicho UE en dicho sistema de 3G y que ha servido a dicho registro.
El manejo del estado de la técnica de un establecimiento de sesión hacia un usuario registrado dado, como resultado del tratamiento de una solicitud de sesión (INVITACIÓN) por los medios de tratamiento en las entidades representadas en dicha figura (P-CSCF, I-CSCF, S-CSCF), será ahora descrito con referencia a la fig. 2, operaciones 11 a 16. También la fig. 3 será usada para ilustrar un caso más concreto en el que uno usuario dado (USER-N), que se ha registrado satisfactoriamente usando su ID privado (User-N_PRIVATE) y uno de sus ID públicos (User-N_PUBLIC2), recibe una sesión entrante.
En la operación 11, una solicitud de sesión (INVITACIÓN), dirigida a dicho USER-N, llega a un I-CSCF. Desde donde dicha INVITACIÓN es recibida en dicho I-CSCF depende de la localización del iniciador de la sesión. Por ejemplo, si alguien en el PSTN hace una llamada marcando "User-N_PUBLIC2" (suponiendo que dicho "User-N_PUBLIC2" está en el formato de un número E.164), entonces la INVITACIÓN llega al I-CSCF desde una Función de Control de Pasarela del Medio (MGCF) que, entre otras funciones, está encargada o trasladando los protocolos de señalización usados en otros sistemas de telecomunicaciones (tales como Número de Sistema de Señalización 7) al protocolo de señalización usado en el sistema de 3G para sesiones multimedia donde los usuarios IM están implicados. El iniciador de sesión podría, por ejemplo, estar dentro de un sistema de 3G; en ese caso, otro usuario ha enviado desde su terminal una INVITACIÓN que indica en la cabecera "A" la identidad "User-N_PUBLIC2"; en ese caso, dicha INVITACIÓN puede llegar a dicho I-CSCF desde el S-CSCF que es asignado a dicho iniciador de sesión.
En cualquier caso, la localización del iniciador de sesión, así como los flujos o detalles de señalización previos a la llegada de dicha INVITACIÓN al I-CSCF, no son importantes para la comprensión de la técnica anterior mostrada en la fig. 2 ni para las modificaciones introducidas por el presente invento en dicha técnica anterior que será explicada más adelante.
A continuación, en la operación 12, el I-CSCF envía una interrogación de localización (CX-Location Query) al HSS para encontrar el S-CSCF que es asignado para dar servicio al control de sesión para el usuario llamado, en que dicha interrogación comprende el ID público recibido en la INVITACIÓN (por ejemplo: User-N_PUBLIC2) para identificar a dicho usuario llamado en el HSS. El HSS localiza entonces el registro SD correspondiente de dicho usuario llamado (USER-N) que corresponde con dicho ID público y encuentra que hay un S-CSCF asignado a dicho usuario (por ejemplo: "S-CSCF1.HOME1.NET"), y en la operación 13 el HSS envía de nuevo una respuesta de interrogación de localización (CX-Location Query Resp) que comprende información relacionada con dicho S-CSCF.
A la recepción de la respuesta a la interrogación de localización, el I-CSCF en la operación 14 reenvía la INVITACIÓN al S-CSCF indicado por el HSS. Luego dicho S-CSCF busca en la información almacenada relacionada con los P-CSCF que tiene, el P-CSCF particular a través del cual un registro fue solicitado (REGISTRO) y concedido (200 OK) que contenía el ID público referenciado en la INVITACIÓN, y reenvía en la operación 15 la INVITACIÓN a él. A la recepción de la INVITACIÓN en el P-CSCF, se realiza un procedimiento similar para encontrar en dicho P-CSCF la dirección (IP- Addr) del terminal (UE) que tiene concedido un registro que indica dicho ID público, y en la operación 16 reenvía la INVITACIÓN recibida a dicho UE.
Un usuario dado registrado en un sistema de 3G puede resultar no registrado de dicho sistema o bien: a solicitud de usuario, hecha desde el terminal registrado (eliminación de registro iniciado por el usuario); o por decisión del sistema de 3G (eliminación de registro iniciado por red). O bien: eliminación de registro iniciado por usuario o iniciado por red, los procedimientos de eliminación de registro del estado de la técnica causan un borrado de los datos de localización almacenados en el registro de SD asociado a dicho usuario; es decir: "DATOS DE LOCALIZACIÓN" de USER-N mostrado en la fig. 3 resultan vacíos, ya que, como se ha mencionado antes, sólo existe una entrada en dichos datos de localización. También, la eliminación del registro iniciado por el usuario o iniciado por red provoca el borrado de los datos limitados previamente en el S-CSCF y en el P-CSCF que fueron servidos en dicho registro. Así, en el S-CSCF es borrada la información previamente almacenada que limita los ID público y privado usados en el registro con el P-CSCF que sirven al acceso a dicho registro. Similarmente en el P-CSCF es borrada la información previamente almacenada que limita los ID público y privado usados en el registro con la dirección del UE que ha solicitado dicho registro.
Un procedimiento de eliminación de registro iniciado por el usuario (no mostrado en la fig. 2) funciona de una manera similar a como lo hace el procedimiento de registro: un REGISTRO es recibido desde un UE ya registrado que indica un valor de expiración (encabezamiento "Expires") de cero (0). Un flujo similar al representado en la fig. 2, operaciones 1 a 4 es ejecutado que determina el S-CSCF que está dando servicio al registro activo de dicho usuario. Dicho S-CSCF envía entonces una notificación al HSS que indica que dicho usuario ha sido eliminado del registro desde dicho S-CSCF (CX-Put), en el que dicha notificación esta vez comprende un campo "tipo de asignación de servidor" que establece la "eliminación de registro", junto con los datos de identificación antes mencionados relacionados con la eliminación del registro del usuario y al S-CSCF.
Se hace referencia ahora a las figs. 4 a 6 para ilustrar nuevas disposiciones de método y sistema de acuerdo con el presente invento para manejar múltiples registros en un sistema de 3G para un usuario dado (usuario de IM) que contiene una única suscripción (suscripción de IM) en dicho sistema.
Para dicha única suscripción de dicho usuario, una pluralidad de ID privados son definidos y almacenados en los medios de almacenamiento del HSS que es asignado para almacenar los datos de abonado (SD) de dicho usuario para dicha suscripción; permitiendo así, como se ha mostrado esquemáticamente en la fig. 4, que dicha suscripción sea referenciada (es decir, registrada, llamada) por medio de cualquiera de la pluralidad de identificadores asociados a ella. Dentro de dicha fig. 4, que debe ser comparada con la fig. 1 que muestra la correspondiente técnica anterior para la misma abstracción, múltiples registros de la misma suscripción dada de dicho usuario pueden ser mantenidos, dado que cada registro hace referencia un ID privado diferente entre la pluralidad de IL privados que están asociados a él ("Identidad 1 de usuario privado", "Identidad 2 de usuario privado", "Identidad 3 de usuario privado"). De modo correspondiente, y como se detallará adicionalmente, otras sesiones dirigidas al ID público de este usuario, o (como una opción de puesta en práctica) a cualquiera de los ID públicos de este usuario ("Identidad 1 de usuario público", "Identidad 2 de usuario público") serán contenidas teniendo en cuenta dichos registros múltiples. Por ejemplo, y como se ha indicado por los puntos mostrados dentro de la fig. 4, una sesión dirigida a la "Identidad 1 de usuario público", puede ser manejada de acuerdo con el estado de registro de "Identidad 1 de usuario privado" e "Identidad 2 de usuario privado", mientras que la sesión dirigida a "Identidad 2 de usuario público" puede ser manejada de acuerdo con el estado de registro de "Identidad 3 de usuario privado"; aunque (como una opción de puesta en práctica) cualquiera de esas sesiones puede también ser manejada de acuerdo con el estado de registro de cualquiera o la totalidad de los ID privados asociados con dicha suscripción.
El proceso de registro múltiple en un sistema de 3G de un usuario dado que contiene una única suscripción en dicho sistema será descrito a continuación con referencia al flujo de señalización simplificado mostrado en la figura 5. Se harán también referencias a la fig. 6 para ejemplificar un caso específico de un usuario dado (USER-N). En particular, la fig. 5 muestra un flujo de señalización simplificado de un proceso de registro solicitado por un usuario de IM dado desde una pluralidad de terminales (UE1, UE2, UE3) en un sistema de 3G como resultado del tratamiento de solicitudes de registro subsiguientes (REGISTRO) por los medios de tratamiento sobre las entidades representadas en dicha figura (P-CSCF, I-CSCF, HSS, S-CDCF).
Como se ha hecho previamente para el estado de la técnica equivalente fig. 2, y también con el propósito de una mayor claridad que ayude a resaltar los nuevos aspectos descritos a continuación, la fig. 5 no muestra ningún sub-flujo de autentificación. Sin embargo, los expertos en la técnica que están familiarizados, por ejemplo, con los flujos de registro detallados descritos en la especificación TS 24.228 de 3GPP, comprenderán fácilmente como los métodos descritos dentro de este invento pueden aplicarse igualmente si tienen lugar dichos procedimientos de autentificación. Por ejemplo, para cada registro, dichos subflujos de autentificación puede consistir en mensajes adicionales intercambiados entre las entidades de servicio mostradas en la fig. 5 y el terminal o terminales de registro (por ejemplo: un mecanismo de desafío/respuesta) que podría transportar identidades privadas o públicas usadas en el registro. En ese caso, una "respuesta de desafío", enviada desde un terminal de registro como resultado de un "desafío de autentificación" recibido podría ser embebida dentro de una nueva solicitud de registro REGISTRO que, como se ha explicado previamente, tendría que transportar una identidad privada y (al menos) una identidad pública para identificar la suscripción particular a la que pertenecen dichas identidades; aunque podría usarse otro método. En cualquier caso, dado que un procedimiento de autentificación (si se usara) estaría siempre asociado a una solicitud de registro, siendo identidades relacionadas con una suscripción dada siempre referenciadas en dicha solicitud de registro; si dicho procedimiento de autentificación tiene lugar o uno, no afecta al tratamiento básico de una solicitud de registro basada en identidades privada y pública referenciadas en ella, que es uno de los objetos del presente invento.
Dentro de la fig. 6 (que será además referenciada adicionalmente en relación a descripciones detalladas de otros aspectos de este invento) se ha mostrado una vista esquemática simplificada de los medios de almacenamiento contienen SD de una pluralidad de usuarios. Particular la fig. 6 muestra de modo más detallado el contenido del registro de SD de un usuario dado (USER-N), en el que, de acuerdo con el presente invento, se ha asignado una pluralidad de ID privados (User-N_PRIVATE1, User-N_PRIVATE2, User-N_PRIVATE3) para dicho usuario en relación a los datos de identificación de su suscripción. Se observará que, aunque se han mostrado tres ID privados en este ejemplo, un mayor o menor número de ID privados asignados por suscripción es un aspecto que no afecta al marco del presente invento. Los datos de identificación de dicha suscripción también comprenden una pluralidad de ID públicos (User-N_PUBLIC1, User-N_PUBLIC2); aunque, para el marco fundamental y comprensión del presente invento, no es importante que haya más de un ID publico asociado a un usuario dado.
La fig. 6 (en oposición a la fig. 3) también muestra que, de acuerdo con el presente invento, los datos de localización de un registro de SD dado pueden comprender una pluralidad de entradas; más precisamente, puede comprender información relacionada con una pluralidad de S-CSCF y una pluralidad de identidades (ID privados, ID públicos); en que, como se explicará adicionalmente, cada S-CSCF almacenado en los datos de localización de dicho registro de SD ha sido asignado para servir al control de sesión en registros subsiguientes del mismo usuario (el usuario ha dicho qué registros de SD le pertenecen), indicando dichos registros subsiguientes cada uno un ID privado diferente asignado a los datos de abonado de dicho usuario, entre la pluralidad de ID privados asignados a los datos de abonado de dicho usuario.
Como se ha mostrado en la fig. 5, operaciones 1, 7 y 13, dicho usuario (USER-N) envía solicitudes de registros subsiguientes (REGISTRO) desde terminales subsiguientes (UE1, UE2, UE3) a través de P-CSCF diferentes (P-CSCF1, P-CSCF2, P-CSCF3), que indican en cada uno de dichos registros, al menos, un ID público y un ID privado, entre la pluralidad de ID públicos e ID privados asociados a dicho usuario. El caso específico mostrado dentro de esta figura, en el que están representados tres flujos de registro como ejemplo, no será considerado como limitativo del marco del presente invento, ya que, como se comprenderá adicionalmente, los métodos descritos a continuación se aplican siempre que más de una solicitud de registro es recibida para el mismo usuario.
Ha de observarse que, para cada solicitud de registro satisfactoria mostrada en la fig. 5, hay un flujo de confirmación de registro (no mostrado) similar al mostrado en la fig. 2 operaciones 7 a 10, yendo de nuevo cada uno de dichos flujos de confirmación al terminal que tiene el registro concedido (UE1, o UE2, o UE3) a través de los CSCF que intervienen en dicho registro concedido. Aspectos tales como: si el mismo P-CSCF está sirviendo al acceso de más de uno de estos UE, o incluso a la totalidad de ellos, o si hay un P-CSCF que da servicio al acceso a cada uno de estos UE; son considerados por el presente invento, como se comprenderá a continuación.
Para una mejor comprensión del proceso, puede suponerse que, antes del flujo de señalización de la fig. 5, dicho usuario no tiene ningún registro activo todavía; es decir: no está registrado aún con ninguno de los ID privados asociados a dicho usuario, y así, los datos de localización en el registro de SD correspondiente a dicho usuario están aún vacíos (por ejemplo: los datos de localización de USER-N mostrados en la fig. 6 no contienen ningún dato todavía).
Las operaciones 1 a 3 de la fig. 5 son similares a las operaciones 1 a 3 equivalentes de la solicitud de registro explicado previamente con referencia a la fig. 2. En el caso específico mostrado en la fig. 3, un terminal (UE1) envía una solicitud de registro (REGISTRO) a través de un P-CSCF dado (P-CSCF1). Como se ha mencionado antes con referencia al flujo de la técnica anterior en la fig. 2, el P-CSCF que recibe un REGISTRO une la dirección del terminal con el ID público indicado en el REGISTRO recibido.
El HSS, a la recepción de la interrogación de registro hecha por el I-CSCF en la operación 3 (CX-Query), sitúa entonces el registro SD del usuario referenciado por el ID privado e ID público recibido en dicha interrogación. Considerando el caso específico mencionado antes para ilustrar el flujo, y suponiendo que el ID privado recibido es "User-N_PRIVATE1" y el ID público recibido es "User-N_PUBLIC2", entonces el registro SD del USER-N será luego encontrado por el HSS entre la pluralidad de registros SD que pertenecen a las suscripciones de otros usuarios. Para encontrar dicho registro SD, el HSS no necesita usar ninguna técnica nueva; cualquier técnica de búsqueda del estado de la técnica basada en el ID privado recibido y/o el ID público recibido puede ser usada para dicho propósito.
Una vez que se ha encontrado dicho registro de SD, es comprobado en los datos de localización de dicho SD si dicho usuario está ya registrado con el ID privado recibido (User-N_PRIVATE1); es decir, si hay ya un S-CSCF asignado para dar servicios de control de sesión para el ID privado User-N_PRIVATE1 (es decir: cualquier entrada en los datos de localización que contiene dicho ID privado recibido). Considerando la suposición hecha antes, en esta fase, los datos de localización en dicho registro están aún vacíos; por ello, en la operación 4, una respuesta de interrogación de registro (CX-Query Resp) es enviada al I-CSCF que comprende: una indicación de estado de registro, que establece que el USER-N no está registrado con dicho ID privado recibido, y (opcionalmente) las capacidades requeridas para seleccionar desde dicho I-CSCF un S-CSCF que soportará finalmente dicho control de sesión de registro para otras sesiones que implican a dicho usuario para dicho ID privado recibido (User-N_PRIVATE1) e ID público (User-N_PUBLIC2).
Como la indicación del estado registro establece que el usuario que se registra no está registrado con dicho ID privado recibido y no se ha indicado un S-CSCF por el HSS y sobre la respuesta de interrogación de registro, el I-CSCF, usando técnicas del estado de la técnica para seleccionar un S-CSCF cuando no hay previsto S-CSCF por el HSS (por ejemplo: basado en las capacidades recibidas desde el HSS), selecciona un S-CSCF y reenvía el REGISTRO a dicho S-CSCF en la operación 5. En el ejemplo mostrado en la fig. 5 dicho S-CSCF seleccionado es "S-CSCF1".
A continuación el S-CSCF seleccionado (S-CSCF1) almacena información relacionada con el P-CSCF que sirve a dicho registro (P-CSCF1) así como a los ID privado y público indicados en él (User-N_PRIVATE1, User-N_PUBLIC2) y, en la operación 6, notifica (Cx-Put) al HSS que dicho S-CSCF1 y servirá a las sesiones que impliquen a dicho ID privado (User-N_PRIVATE1) y a dicho ID público (User-N_PUBLIC2). Dicha notificación (CX-Put), así como las otras notificaciones "Cx-put" mostradas en el flujo representado en la fig. 5 comprenden: el ID privado y el ID público recibido en el REGISTRO que está siendo tratado, así como información relacionada con el S-CSCF que envía dicho "CX-Put", y un campo de "tipo de asignación de servidor" que establece el "registro".
El HSS encuentra entonces el registro de SD correspondiente y almacena en los datos de localización de dicho registro una nueva entrada que establece que dicho "S-CSCF1" (mostrado en la fig. 6 como "S-CSCF1.HOME1.NET") está sirviendo al control de sesión para dicho usuario (USER-N), y dichos identificadores: "User-N_PUBLIC2" y "User-N_PRIVATE1" (mostrados en la fig. 6 como entrada de datos de localización que comprende "S-CSCF1. HOME1.NET {User-N_PUBLIC2, User-N_PRIVATE1"}). Como una opción de puesta en práctica, el HSS puede hacer que dicho S-CSCF sirva para sesiones dirigidas a dicho usuario a cualquiera de los ID públicos asociados a dicho usuario, como se explicará adicionalmente. A continuación, el registro de dicho usuario (USER-N) desde dicho terminal (UE1) es concedido ("200 OK", no mostrado).
La operaciones 7, 8 y 9 son equivalentes a las operaciones 1 a 3 equivalentes detalladas anteriormente. En este caso, la solicitud de registro (REGISTRO) es enviada desde un terminal subsiguiente (UE2) a través de un P-CSCF dado (P-CSCF2) que, en el ejemplo mostrado en la figura, aparece como diferente de la solicitud de registro previa que se hizo (P-CSCF1). Dicha diferencia puede ser debida a varios factores que no afectan al marco del presente invento (por ejemplo: UE1 y UE2 están accediendo al mismo sistema local de 3G desde diferentes sistemas de 3G visitados; o UE1 y UE2 están en diferentes áreas de localización dentro del mismo sistema, asignadas cada una a un P-CSCF diferente. Sin embargo, como un P-CSCF añade información relacionada a sí mismo cuando reenvía una solicitud de registro a un I-CSCF (como se ha explicado previamente con referencia a la operación 2 de la fig. 2), y este información será recibida y conservada por el S-CSCF seleccionado para dicho registro (junto con los ID público y privado indicados en dicho registro); en caso de múltiples registros para el mismo usuario, no es importante si el P-CSCF que da acceso a un registro subsiguiente es el mismo o un P-CSCF diferente al usado para registros activos previos, dado que dicho P-CSCF y será únicamente identificado en el S-CSCF correspondiente (el S-CSCF seleccionado para dicho registro subsiguiente) como sirviendo a un registro activo para un cierto ID privado y un cierto ID
público.
Siguiendo con el caso específico antes mencionado usado como ejemplo, puede suponerse ahora que el REGISTRO contiene "User-N_PRIVATE2" como ID privado y "User-N_PUBLIC1" como ID público. Cuando la interrogación de registro (CX-Query) de la operación 9 es recibida en el HSS, entonces el registro de SD de USER-N es identificado usando técnicas existentes basadas en las identidades recibidas, como se ha mencionado antes.
Una vez que se ha encontrado dicho registro de SD, el HSS comprueba si el ID privado recibido ("User- N_PRIVATE2") está ya contenido dentro de los datos de localización de dicho SD. Si este es el caso, entonces, como se ha mencionado previamente con referencia a la operación 3 de la fig. 2 (caso de un nuevo registro), el HSS respondería de nuevo en la operación 10, con una respuesta de interrogación de estado de registro (CX-Query Resp) que comprende información relacionada con el S-CSCF encargado de dar servicios al control de sesión para dicho usuario, junto con una indicación de estado de registro y que establece que dicho usuario está ya registrado. Sin embargo, suponiendo el caso específico mostrado dentro de este ejemplo, dicho ID privado ("User-N_PRIVATE2") no está aún contenido dentro de los datos de localización de dicho SD; por ello, en la operación 10 una respuesta de interrogación de registro (CX-Query Resp) es enviada al I-CSCF que comprende: una indicación de estado de registro, que establece que el USER-N no está registrado con dicho ID privado recibido, y (opcionalmente) las capacidades requeridas para seleccionar a partir de dicho I-CSCF un S-CSCF que finalmente soportará dicho control de sesión de registro para otras sesiones que implican a dicho usuario para dicho ID privado recibido (User-N_PRIVATE2) e ID público (User-N_PUBLIC1).
En el caso particular mostrado con referencia a la fig. 5, como los datos de localización de dicho registro de SD de dicho USER-N no están vacíos en esta fase, el HSS puede también proporcionar al I-CSCF una lista que comprende información relacionada con uno o más de los S-CSCF que están referenciados en dichos datos de localización. Esto puede ser útil, por ejemplo, siempre que una política para asignar siempre el mismo S-CSCF al mismo usuario para todos los registros es desplegada. En este caso particular citado como ejemplo, dicha lista comprendería información relacionada solamente con "S-CSCF1".
El I-CSCF entonces, como la indicación de estado de registro establece que el usuario que registra no está registrado con dicho ID privado recibido, selecciona un S-CSCF y en la operación 11 reenvía el REGISTRO recibido a él. Para seleccionar un S-CSCF, el I-CSCF puede o bien: usar técnicas del estado anterior de la técnica para seleccionar un S-CSCF cuando no se ha proporcionado un S-CSCF por el HSS (por ejemplo: basado en las capacidades recibidas desde el HSS); o bien, en caso de que información relacionada con uno o más S-CSCF es recibida desde el HSS, elegir una de ellas. Como puede comprenderse, el último caso sería útil para poner en práctica la política antes mencionada de asignar siempre el mismo S-CSCF al mismo usuario.
En el ejemplo mostrado dentro de este flujo, no era supuesto que el I-CSCF tiene, por ejemplo, seleccionado un S-CSCF basado en las capacidades recibidas desde el HSS. Es decir: es aplicada otra política, diferente de la planteada anteriormente. En el ejemplo, dicha selección ha dado como resultado que se ha elegido finalmente el "S-CSCF2"; sin embargo, como se comprenderá posteriormente, podría haber sido seleccionado otro S-CSCF, que podría ser el mismo o diferente del que sirve a dicho usuario para el registro previo (S-CSCF1), sin afectar a la totalidad del marco de los registros múltiples de USER-1 y al manejo de otra llamadas dirigidas a dicho usuario para cualquiera de dichos registros múltiples.
El S-CSCF seleccionado para este registro (S-CSCF2) actúa similarmente como se ha descrito antes para el registro previo. En primer lugar almacena información relacionada con el P-CSCF que está sirviendo a este registro (que en el caso usado como ejemplo es "P-CSCF2" para este registro), así como a los ID privado y público indicados en él (User-N_PRIVATE2, User-N_PUBLIC1) y, en la operación 12, notifica (CX-Put) al HSS que dicho S-CSCF2 servirá a las sesiones que implican a dicho ID privado (User-N_PRIVATE2) y a dicho ID público (User-N_PUBLIC1).
El HSS encuentra el registro SD correspondiente y crea una nueva entrada de datos de localización en dicho registro SD, estableciendo dicha nueva entrada que almacena información que dicho "S-CSCF2" (mostrado como "S-CSCF2.HOME1.NET" en la fig. 6) está sirviendo al control de sesión para dicho usuario (USER-N), y dichos identificadores: "User-N_PUBLIC1" y "User-N_PRIVATE2" (mostrados en la fig. 6 como entrada de datos de localización que comprende "S-CSCF2.HOME1.NET {User-N_PUBLIC1, User-N_PRIVATE2}"). Como se ha mostrado en la fig. 6, y en oposición a las técnicas anteriores ya mencionadas, puede observarse que, cada registro hecho para cada uno de los ID privados del mismo usuario provoca la creación de una nueva entrada de datos de localización, almacenando dicha entrada información acerca del S-CSCF asignado para servir al control de sesión para otras sesiones relacionadas con dicho registro, así como información acerca de las identidades (ID público, ID privado) indicadas en dicho registro. Como una opción de puesta en práctica mencionada antes, el HSS puede posteriormente hacer que cualquiera de dichos S-CSCF sirva a sesiones dirigidas a cualquiera de los ID públicos asociados a dicho usuario, como se explicará adicionalmente.
A continuación, el registro de dicho usuario (USER-N) desde dicho terminal (UE2) es concedido ("200 OK", no mostrado).
Para el tercer flujo de registro mostrado en el ejemplo de la fig. 5, la solicitud de registro (REGISTRO) es enviada desde un terminal subsiguiente (UE3) a través de un P-CSCF dado (P-CSCF3) en el que, similarmente al registro previo (operaciones 7 a 12), ha sido representado y solicitado a través de un P-CSCF diferente de los usados en los registros previos. En este caso podemos suponer que el ID privado indicado en dicho REGISTRO es "User-N_PRIVATE3" y el ID publico es "User-N_PUBLIC2".
Las operaciones 13, 14 y 15 son similares a las operaciones equivalentes de los registros previos, en los que solamente varía el contenido del REGISTRO.
En este caso, así como para todos los registros de cualquier usuario, independientemente de si dicho usuario está ya registrado con cualquier ID privado o no, a la recepción de una solicitud de registro (CX-Query) en la operación 15, el HSS situará en primer lugar el registro SD que corresponde a las identidades recibidas en la solicitud de registro, y a continuación comprobará en dicho registro SD si el ID privado recibido en dicha solicitud de registro ("User-N_PRIVATE3") está ya dentro de cualesquiera de las entradas almacenadas en los datos de localización de dicho SD. Para este (tercer) registro subsiguiente, así como para el registro subsiguiente previo explicado con referencia a las operaciones 7 a 12 (segundo), los datos de localización de dicho registro de SD de dicho USER-N no están vacíos, conteniendo en este caso particular, dos entradas ("S-CSCF amén1.HOME1.NET {User-N_PUBLIC2, User-N_PRIVATE1}", y "S-CSCF2.HOME1.NET {User-N_PUBLIC1, User-N_PRIVATE2}2"), haciendo referencia cada entrada en dichos datos de localización a un registro activo.
El HSS entonces en la operación 16 envía una respuesta de interrogación de registro (CX-Query Resp) al I-CSCF que comprende: una indicación de estado de registro, que establece que el USER-N no está registrado con dicho ID privado recibido (User-N_PRIVATE3), y (opcionalmente) las capacidades requeridas para seleccionar a partir de dicho I-CSCF un S-CSCF que finalmente soportará dicho control de sesión de registro para otras sesiones que implican a dicho usuario para dicho ID privado recibido (User-N_PRIVATE3) e ID público (User-N_PUBLIC2).
Como los datos de localización de dicho registro de SD de dicho USER-N no están tampoco vacíos en este caso, en la respuesta de interrogación el HSS puede también proporcionar al I-CSCF una lista que comprende información relacionada con uno o más de los S-CSCF que están referenciados en dichos datos de localización. Así, en este caso dicha lista puede comprender información relacionada solamente con "S-CSCF1", solamente con "S-CSCF2" o con ambos de ellos.
En caso de que se quiera una política en la que todos los registros de un usuario dado que indican el mismo ID público son asignados al mismo S-CSCF, entonces dicha lista contendrá información relacionada al S-CSCF que está ya asignado para servir al control de sesión relacionado con un registro previo que ha indicado dicho ID público (si lo hay). En este caso de ejemplo específico, dicha lista contendría información relacionada sólo con "S-CSCF1", ya que, en el momento en que se ha manejado esta tercera solicitud de registro, se ha asignado ya un S-CSCF (S-CSCF1) para un registro previo que contenía el mismo ID público (User-N_PUBLIC2) que el actual.
En el ejemplo mostrado en la fig. 5, en la operación 17, el I-CSCF reenvía la solicitud de registro a S-CSCF1. Este comportamiento muestra una política para seleccionar un S-CSCF cuando tanto: las capacidades de S-CSCF, como la información relacionada con los S-CSCF están presentes en la "CX-Query Resp", diferente de la descrita para el registro previo (segundo) con referencia a la operación 11 equivalente (es decir: no hay S-CSCF seleccionado basado en las capacidades de S-CSCF recibidas si los S-CSCF están indicados a partir del HSS); siendo en este caso el resultado de dicha política que todos los registros de un usuario dado indican que el mismo ID público está asignado al mismo S-CSCF.
El S-CSCF seleccionado para este registro (S-CSCF1), almacena en primer lugar información relacionada con el P-CSCF que está sirviendo a este registro (que en el caso usado como ejemplo es "P-CSCF3" para este registro), así como los ID privado y público indicados en el (User-N_PRIVATE3, User-N_PUBLIC2) y, en la operación 18, notifica (CX-Put) al HSS que dicho S-CSCF1 servirá a las sesiones que implican dicho ID privado (User-N_PRIVATE3) y dicho ID público (User-N_PUBLIC2).
A continuación, una vez que el HSS encuentra el registro de SD correspondiente, crea una nueva entrada de datos de localización en dicho registro de SD, almacenando dicha nueva entrada información que establece que dicho "S-CSCF1" (mostrado como "S-CSCF1.HOME1.NET" en la fig. 6) está sirviendo al control de sesión para dicho usuario (USER-N), y dicho identificadores: "User-N_PUBLIC2" y "User-N_PRIVATE3" (mostrados en la fig. 6 como entrada de datos de localización que comprende ("S-CSCF1.HOME1.NET {User-N_PUBLIC2, User-N_PRIVATE3}"). Como una opción de puesta en práctica mencionada anteriormente, el HSS puede hacer que cualquiera de dichos S-CSCF sirva a la sesiones dirigidas a cualquiera de los ID públicos asociados a dicho usuario, como se explicará adicionalmente.
A continuación, el registro de dicho usuario (USER-N) desde dicho terminal (UE2) es concedido ("200 OK", no mostrado).
Como otra característica opcional que puede, por ejemplo, facilitar búsquedas en otras sesiones solicitadas hacia cualquiera de los ID públicos de un usuario dado que ha tenido múltiples registros (usuario múltiplemente registrado), el HSS puede construir una tabla de búsqueda que une cada ID público de dicho usuario con una lista que contiene información relacionada con cada S-CSCF que ha sido almacenado en dicho HSS como asignado para servir al control de sesión para otras sesiones dirigidas a dicho usuario para dicho ID público (si lo hay). Dicha lista puede, por ejemplo, ser construida/actualizada sobre notificaciones de registro subsiguientes (CX-Put) recibidas desde los S-CSCF. Un ejemplo de una entrada en dicha tabla en el HSS está mostrado en la fig. 7 [A], en el que está presentada la lista de los S-CSCF (S-CSCF1, S-CSCF2, ...etc.,) que sirven corrientemente a un ID publico (User-N_PUBLIC2).
Similarmente, y con el mismo propósito, pueden mantenerse tablas similares en los S-CSCF y P-CSCF para cada registro concedido. Un S-CSCF uniría entonces un ID público dado con una lista que contiene información de cada P-CSCF a través de la cual se ha concedido un registro que contiene dicho ID público desde dicho S-CSCF. Dicha lista puede, por ejemplo, ser construida/actualizada en el momento en que se ha concedido un registro ("200 OK" enviado). Un ejemplo de una entrada en dicha tabla en un S-CSCF dado está mostrado en la fig. 7 [B], en el que está presentada la lista de los P-CSCF (P-CSCF1, P-CSCF2, ...etc.,) que sirven corrientemente a un ID público dado (User-N_PUBLIC2).
Por otro lado, un P-CSCF uniría entonces un ID público dado con una lista que contiene los de IP- Addr de cada terminal (UE) que han tenido un registro concedido a través de ella y han usado dicho ID público en el registro concedido. Dicha lista puede, por ejemplo, ser construida/actualizada en el momento que se ha concedido un registro ("200 OK" recibido, o "200 OK" enviado). Un ejemplo de una entrada en dicha tabla en un P-CSCF dado está mostrado en la fig. 7 [C], en el que se ha presentado la lista de direcciones (P-ADDR UE1, IP-ADDR UE2,...etc.,) de los UE que han tenido un registro concedido a través de él e indicado, por ejemplo, "User-N_PUBLIC2" como ID público.
Se ha hecho ahora referencia a la fig. 8 para ilustrar, de acuerdo con el presente invento, el manejo de establecimiento de sesión múltiple hacia un usuario dado que tiene múltiples registros (usuario múltiplemente registrado); en oposición al establecimiento de sesión única del estado de la técnica hacia un usuario que tiene un único registro previamente descrito con referencia a la fig. 2, operaciones 11 a 16. En particular, la fig. 8, muestra un flujo de señalización simplificado de un proceso de establecimiento de sesión solicitado hacía un usuario de IM dado desde una pluralidad de terminales (UE1, UE2, UE3) en un sistema de 3G como resultado del tratamiento de una solicitud de sesión (INVITACIÓN) por los medios de tratamiento sobre las entidades representadas en dicha figura (P-CSCF, I-CSCF, HSS, S-CSCF). Con objeto de una mejor comprensión, el caso del ejemplo anterior de un usuario ya múltiplemente registrado (como se ha descrito previamente para el USER-N) será usado para ejemplificar un caso específico.
Como se ha citado previamente con referencia a la técnica anterior representada en la fig. 2, la localización del iniciador de sesión (es decir: de la parte que llama), así como los flujos o detalles de señalización previos a la llegada de la solicitud de sesión (INVITACIÓN) a un I-CSCF, no afecta al marco del presente invento.
Las operaciones 1 y 2 en la fig. 8, son similares a las operaciones equivalentes 11 y 12 en la fig. 2; así, en la operación 2 de la fig. 8, el I-CSCF envía una interrogación de localización (CS-Location Query) al HSS, comprendiendo dicha interrogación el ID público recibido en la INVITACIÓN (por ejemplo: User-N_PUBLIC2). El HSS, utilizando técnicas del estado anterior de la técnica, encuentra en primer lugar el registro de SD correspondiente (registro SD de USER-N) es decir: el registro SD que contiene en sus datos de identificación el ID público recibido en la solicitud; y a continuación, busca en los datos de localización de dicho registro para determinar qué S-CSCF (o pluralidad de S-CSCF) está (si lo hay) ya asignado para servir al control de sesión para dicho usuario y para dicho ID público recibido. Suponiendo, como ejemplo, que el ID público recibido es "User-N_PUBLIC2" (que pertenece a USER-N), a continuación, suponiendo también que dicho USER-N ha tenido múltiples registros como se ha descrito previamente con referencia a la fig. 5, debe encontrarse que S-CSCF2 (S-CSCF2.HOME1.NET) está actualmente encargado de servir a los controles de sesión que implican a dicho usuario para dos registros que fueron hechos indicando dicho ID público (entradas: "S-CSCF1.HOME1.NET {User-N_PUBLIC2, User-N_PRIVATE1}" y "S-CSCF1.HOME1.NET {User-N_PUBLIC2, User-N_PRIVATE3}" mostrados en los datos de localización de USER-N en la fig. 6).
Alternativamente, con el propósito de encontrar rápidamente en el HSS qué S-CSCF están asignados actualmente para servir al control de sesión para un usuario dado y un ID público dado asociado a los datos de identificación de dicho usuario, el HSS puede usar la información de localización almacenada en la tabla de búsqueda antes mencionada (fig. 7 [A]) que relaciona los ID públicos con los S-CSCF asignados correspondientes.
Incluso aunque en el caso específico usado como ejemplo solamente se ha encontrado un S-CSCF (S-CSCF1) para dicho usuario (USER-N) y dicho ID público recibido (User-N_PUBLIC2); podría suceder que se hubiera encontrado más de un S-CSCF sirviendo al mismo ID público para dicho usuario (por ejemplo, S-CSCF1 y S-CSCF2). En este caso, y de acuerdo con una realización de este invento, el HSS enviaría de nuevo en la operación 3 una respuesta de interrogación de localización (CX-Location Query Resp) al I-CSCF que comprende información relacionada con un solo S-CSCF entre la pluralidad de S-CSCF encargados de servir al control de sesión para dicho usuario y dicho ID público. Por ello, de acuerdo con esta realización, y en el caso específico usado como ejemplo, el HSS enviaría de nuevo a la operación 3 una respuesta de interrogación de localización (CX-Location Query Resp) al I-CSCF que comprende información relacionada (solamente) con S-CSCF1.
Sin embargo, y de acuerdo con una realización alternativa de este invento, el HSS puede enviar de nuevo a la operación 31 respuesta de interrogación de localización (CX-Location Query Resp) al I-CSCF que comprende una lista con información relacionada con más de un S-CSCF entre la pluralidad de S-CSCF que sirve al control de sesión para dicho usuario y dicho ID público, o incluso que comprende información relacionada con la totalidad de dichos S-CSCF. Condiciones para la ejecución o no de esta realización alternativa pueden ser asentadas sobre una base por usuario (por ejemplo: basado en los datos de perfil de usuario manejados por el HSS) o como una puesta en práctica general para todos los usuarios; siendo en cualquier caso útil incluso cuando, por ejemplo, se desea (o bien: por el usuario o bien por el operador de red) un elevado grado de disponibilidad para responder a las sesiones que terminan.
De acuerdo con otra realización alternativa la respuesta de interrogación de localización (CX-Location Query Resp) enviada desde el HSS al I-CSCF en la operación 3, puede comprender información relacionada con uno, o más de un, S-CSCF que está o están encargados de servir al control de sesión para cualquiera de los ID públicos asignados a dicho usuario. En este caso, como (como se ha mencionado anteriormente para el procedimiento de registro) para cada registro activo: en un S-CSCF dado, hay una unión entre un ID público dado indicado en un registro satisfactorio y el P-CSCF implicado en dicho registro; y, en un P-CSCF dado, hay una unión entre un ID público dado indicado en un registro satisfactorio y la dirección del UE implicado en dicho registro; siempre que el HSS envía información relacionada con un S-CSCF que está sirviendo a dicho usuario, pero para un ID público diferente del recibido en la interrogación de localización, el HSS acompañará la información relacionada con dicho S-CSCF con el ID público a que dicho S-CSCF está sirviendo para dicho usuario. Por ejemplo, en el caso específico antes citado, y considerando los datos de localización mostrados en la fig. 6 para el USER-N múltiplemente registrado, el HSS debe enviar una respuesta de interrogación de localización (CX-Location Query Resp) que comprende información relacionada con S-CSCF2, debe incluir el ID público "User-N_PUBLIC1" que acompaña a la información relacionada con dicho S-CSCF2.
Procedimientos en el I-CSCF a recepción de la respuesta de interrogación de localización (CX-Location Query Resp) dependen de la información relacionada con los S-CSCF recibidos en dicha respuesta.
Cuando la respuesta de interrogación de localización (CX-Location Query Resp) contiene información relacionada solamente con un S-CSCF, el I-CSCF reenvía la solicitud de sesión recibida (INVITACIÓN) al S-CSCF indicado por el HSS en dicha respuesta de interrogación. Si, sin embargo, dicha respuesta contiene información relacionada con una pluralidad de S-CSCF, el I-CSCF puede emplear diferentes opciones que (como se ha mencionado antes) pueden ser desplegadas, por ejemplo, de acuerdo con el elevado o bajo grado antes mencionado de disponibilidad deseada para responder a las sesiones que terminan.
De acuerdo con una realización de este invento, el I-CSCF selecciona un S-CSCF entre dicha pluralidad de S-CSCF indicados por el HSS, y reenvía la INVITACIÓN recibida a él.
De acuerdo con otra realización alternativa, el I-CSCF reenvía la INVITACIÓN simultáneamente a más de uno de dicha pluralidad de S-CSCF. En este caso, tan pronto como se ha reconocido la sesión (es decir: respondido o aceptado) (por ejemplo: recepción de código de respuesta SIP "200 OK" desde uno de dichos S-CSCF), el I-CSCF puede eliminar las solicitudes de sesión que ha enviado a los otros S-CSCF (por ejemplo: enviando una solicitud de cancelación SIP "CANCEL" a dichos S-CSCF).
De acuerdo con otra realización alternativa, el I-CSCF reenvía la INVITACIÓN secuencialmente a más de uno de dicha pluralidad de S-CSCF hasta que la INVITACIÓN es reconocida por uno de ellos; por ejemplo: hasta que se ha recibido un código de respuesta positivo (tal como "200 OK"). Con este propósito, el I-CSCF puede, por ejemplo, ajustar un temporizador de un valor predefinido cuando envía la INVITACIÓN a un primer S-CSCF; así, una vez que ha transcurrido un período de tiempo dado sin recibir dicha respuesta positiva (temporización), o se ha recibido una respuesta negativa (por ejemplo: un código de respuesta SIP "4XX"), reenviará la INVITACIÓN a un segundo S-CSCF, etc.); procediendo así correspondientemente con los S-CSCF subsiguientes. Opcionalmente, el I-CSCF puede eliminar la solicitud de sesión reenviándola a un S-CSCF dado en temporización (por ejemplo: enviando una solicitud de cancelación SIP "CANCEL" a dicho S-CSCF).
En cualquiera de los casos antes mencionados (INVITACIÓN reenviada a un S-CSCF, o reenviada simultánea o secuencialmente a más de un S-CSCF), siempre que el I-CSCF reenvía la solicitud de sesión (INVITACIÓN) a un S-CSCF que ha sido indicado por el HSS con un ID público diferente del ID público recibido en dicha INVITACIÓN (es decir: dicho S-CSCF está sirviendo al mismo usuario pero para un ID público diferente); entonces, la INVITACIÓN que dicho I-CSCF reenvía a dicho S-CSCF contendrá el ID público recibido desde el HSS en sustitución del ID público originalmente recibido en la INVITACIÓN.
Con referencia ahora al caso específico representado en la fig. 8, como la respuesta de interrogación de localización (CX-Location Query Resp) se ha supuesto previamente que contiene información relacionada solamente con S-CSCF1 (no habiendo, de acuerdo con el ejemplo ningún otro ID público acompañando a dicha información), el I-CSCF reenvía en la operación 4 la INVITACIÓN recibida a dicho S-CSCF1).
Cuando la solicitud de sesión (INVITACIÓN) llega al S-CSCF, encuentra en la información almacenada que ha sido relacionada a los P-CSCF, el P-CSCF (o pluralidad de P-CSCF) a través de los cuales se ha solicitado un registro (REGISTRO) y concedido (200 OK) que contenía el ID público recibido en dicha INVITACIÓN. Suponiendo, como ejemplo, que el ID público recibido en la INVITACIÓN es "User-N_PUBLIC2", entonces el S-CSCF1 encontraría dos P-CSCF que satisfarían la condición anterior: P-CSCF1 y P-CSCF3.
Alternativamente, con el propósito de encontrar en el S-CSCF qué P-CSCF hay actualmente dando servicio a un acceso a un usuario dado y a un ID público dado, el S-CSCF puede usar la información almacenada en la tabla de búsqueda antes mencionada (fig. 7 [B]) que relaciona los ID públicos con los P-CSCF correspondientes.
De acuerdo con una realización del presente invento, El S-CSCF reenviará la INVITACIÓN solamente a un P-CSCF de entre la pluralidad de P-CSCF a través de los cuales una solicitud de registro que contiene dicho ID público ha sido concedida desde dicho S-CSCF. Así, en el caso específico citado como ejemplo, el S-CSCF1, seleccionaría un P-CSCF de entre P-CSCF1 y P-CSCF2 y reenviaría la INVITACIÓN al P-CSCF seleccionado.
De acuerdo con otro realizaciones alternativas, en caso de que la información relacionada con una pluralidad de P-CSCF se ha encontrado a través de la cual una solicitud de registro que contiene dicho ID público ha sido concedida desde dicho S-CSCF, la solicitud de sesión (INVITACIÓN) reenviada desde dicho S-CSCF bien: simultánea o secuencialmente a más de un P-CSCF de entre la pluralidad de P-CSCF. Este es el caso representado en las operaciones 5 y 7 de la fig. 8, en que la INVITACIÓN es reenviada (simultánea o secuencialmente) a P-CSCF1 o P-CSCF3, ya que (como se ha supuesto por el ejemplo de registro citado previamente) se ha solicitado una solicitud de registro (operaciones 5 y 17 en la fig. 5) desde dichos P-CSCF que indican el mismo ID público que el recibido en la INVITACIÓN (User-N_PUBLIC2).
Cuando, de acuerdo con una realización alternativa, la INVITACIÓN es reenviada desde el S-CSCF simultáneamente a más de una de dicha pluralidad de P-CSCF, tan pronto como la sesión es reconocida (por ejemplo: recepción de código de respuesta SIP "200 OK" desde uno de dichos P-CSCF), el S-CSCF puede eliminar las solicitudes de sesión que ha enviado a los otros P-CSCF (por ejemplo: enviando una solicitud de cancelación SIP "CANCEL" a dichos P-CSCF).
Para el envío secuencial de la invitación desde el S-CSCF a más de uno de dicha pluralidad de P-CSCF, de acuerdo con otra realización alternativa, un método similar al descrito antes para el envío secuencial desde el I-CSCF puede aplicarse hasta que es recibido un código de respuesta positiva (tal como "200 OK"). Es decir: el S-CSCF envía la invitación a un primer P-CSCF entre dicha pluralidad de P-CSCF e inicia un temporizador asociado con dicho envío. En la temporización de dicho temporizador, o a la recepción de la respuesta negativa (por ejemplo: un código de respuesta SIP "4XX"), reenviará la invitación a un segundo P-CSCF, etc; procediendo así correspondientemente con los P-CSCF subsiguientes. Opcionalmente, el S-CSCF puede eliminar la solicitud de sesión reenviada a un P-CSCF dado en temporización (por ejemplo: enviando una solicitud de cancelación SIP "CANCEL" a dicho
P-CSCF).
Al recibir una solicitud de sesión (INVITACIÓN) en un P-CSCF (por ejemplo: en las operaciones 5 o 7 de la fig. 8), dicho P-CSCF encuentra en la información de dirección (por ejemplo: IPP-ADDR) conserva relacionada con los terminales (UE) a los que está dando acceso, el UE (o pluralidad de UE) desde los que se ha solicitado un registro (REGISTRO) y concedido (200 OK) a través de dicho P-CSCF que contenía el ID público recibido en dicha INVITACIÓN. Alternativamente, con el propósito de encontrar en el P-CSCF a qué UE está dando acceso dicho P-CSCF que tenían un registro concedido que indica dicho ID público, el P-CSCF puede usar la información almacenada en la tabla de búsqueda antes mencionada (fig. 7) que relaciona los ID públicos con las direcciones de UE correspondientes.
A continuación, de acuerdo con una realización del presente invento, dicho P-CSCF reenvía la INVITACIÓN recibida a un UE, entre la pluralidad de UE que está sirviendo acceso que ha tenido un registro concedido utilizando el mismo ID público que el recibido en la INVITACIÓN.
Yendo con el caso específico citado como ejemplo, en el que "User-N_PUBLIC2" es recibido como ID público en la INVITACIÓN, entonces el P-CSCF1 encontraría la dirección de UE1 (IP-ADDR UE1), mientras que P-CSCF3 encontraría la dirección de UE3 (IP-ADDR UE3). Subsiguientemente, en la operación 6 P-CSCF1 reenviaría la INVITACIÓN a UE1, y P-CSCF reenviaría la INVITACIÓN a UE3 en la operación 8. Sin embargo, independientemente del caso específico citado como ejemplo, y a la recepción de una INVITACIÓN en un P-CSCF dado, una pluralidad de UE podría será encontrada que satisfaría la condición anterior (por ejemplo: si UE1 y UE3 tienen un registro a través del mismo P-CSCF que indica el mismo ID público en el registro). En este caso, de acuerdo con otra realizaciones alternativas del presente invento, dicho P-CSCF reenviaría dicha INVITACIÓN, o bien: simultánea o secuencialmente, a más de un UE de entre dicha pluralidad de UE.
De acuerdo con una realización alternativa, la INVITACIÓN es reenviada desde el P-CSCF simultáneamente a más de uno de dicha pluralidad de UE. En este caso, tan pronto como la sesión es reconocida (por ejemplo: recepción de código de respuesta SIP "200 OK" desde uno de dichos UE), el P-CSCF puede eliminar las solicitudes de sesión que ha enviado a los otros UE (por ejemplo: enviando una solicitud de cancelación SIP "CANCEL" a dichos UE).
Así, de acuerdo con otra realización alternativa, la INVITACIÓN es reenviada desde el P-CSCF secuencialmente a más de uno de dicha pluralidad de UE, un método similar al descrito antes para el envío secuencial de INVITACIÓN desde un I-CSCF o desde un S-CSCF puede también aplicarse en el P-CSCF hasta que se ha recibido un código de respuesta positiva (tal como "200 OK"). Opcionalmente, el P-CSCF puede eliminar la solicitud de sesión reenviándola a un UE en temporización (por ejemplo: enviando una solicitud de cancelación SIP "CANCEL" a dicho UE).
Un usuario dado que ha tenido múltiple registros activos (usuario múltiplemente registrado) puede resultar eliminado del registro de una manera similar a la descrita previamente con referencia a los procedimientos de eliminación de registro del estado de la técnica. Sin embargo, dado que para un usuario múltiplemente registrado de acuerdo con este invento habrá una entrada independiente por registro activo en los datos de localización del registro de SD que corresponde a dicho usuario, solamente la entrada correcta en dichos datos de localización será borrada en un procedimiento de eliminación de registro; permaneciendo activos todos los otros registro de dicho usuario (si existe algún otro).
Por ejemplo, usando como un dato de localización de referencia mostrado en la fig. 6 para USER-N, así como los ID público y privado usados en el registro múltiple específico ejemplificado en la fig. 5; en caso de un solicitud de eliminación de registro iniciada por el usuario desde UE1, sólamente la primera entrada representado en los datos de localización de la fig. 6 sería borrada ("S-CSCF1.HOME1.NET {User-N_PUBLIC2, User-N_PRIVATE1}") ya que dicha entrada solamente será la que corresponda con el ID público y el ID privado indicados en la solicitud de eliminación de registro (es decir: como se ha citado previamente, un mensaje de REGISTRO similar al usado en el registro, que comprende los mismos ID público y privado, pero indicando ahora un encabezamiento "Expire" de "cero"); sin embargo los otros registros ("S-CSCF2.HOME1.NET {User-N_PUBLIC1, User-N_PRIVATE2}"; y ("S-CSCF1.HOME1.NET {User-N_PUBLIC2, User-N_PRIVATE3}")permanecerían activos, permitiendo así aún que dicho usuario (USER-N) reciba sesiones entrantes desde otras partes. Similarmente sólo los datos almacenados en S-CSCF y P-CSCF relacionados con el registro que está ahora siendo eliminado de registro serán borrados. Así, para el caso de eliminación de registro citado antes como ejemplo (es decir: UE1 solicita una eliminación de registro), P-CSCF1 borrará la información almacenada previamente que limita los ID público y privado usados en el registro (User-N_PUBLIC2, User-N_PRIVATE1) con la dirección del UE que ha solicitado dicho registro(IP-ADDR UE1); y el S-CSCF1 borrará la información previamente almacenada que limita los ID público y privado usados en el registro (User-N_PUBLIC1, User-N_PRIVATE1) con el P-CSCF sirviendo el acceso a dicho registro (P-CSCF1); sin embargo, el S-CSCF conservaría los datos relacionados con el otro registro que, de acuerdo con el ejemplo, está sirviendo para el mismo usuario (User-N_PUBLIC2, User-N_PRIVATE3, limitado con P-CSCF3), siendo así aún capaz de servir al control de sesión para otras sesiones entrantes solicitadas desde otras partes que son dirigidas al ID público "User-N_PUBLIC2".

Claims (28)

1. Un método para manejar múltiples registros de un usuario en un sistema de telecomunicaciones que gestiona o administra información de localización o situación o información de identificación relacionada con sus usuarios, estando relacionado cada uno de dichos registros a una suscripción de dicho usuario en dicho sistema, comprendiendo el método las operaciones de: a) almacenar, relacionada con dicha suscripción, una pluralidad de identidades privadas; b) recibir solicitudes de registro (REGISTRO), solicitando cada solicitud de registro para unir un terminal (UE1, UE2, UE3) a dicho sistema para dicha suscripción, y c) tratar cada solicitud de registro recibida de acuerdo con la identidad privada, entre dicha pluralidad de identidades privadas, recibidas en dicha solicitud; caracterizado porque la operación c comprende la operación de tratar una solicitud de registro de acuerdo con dicha identidad privada recibida y una identidad pública recibida en dicha solicitud.
2. El método de la reivindicación 1ª, en el que la operación de tratar una solicitud de registro recibida de acuerdo con dichas identidades privada y pública recibidas comprende las operaciones de: recibir una interrogación de registro (CX-QUERY) en una entidad de servidor local (HSS) que almacena datos (SD) de dicha suscripción, conteniendo dicha interrogación de registro, al menos, dichas identidades privada y pública recibidas, verificar en dicho servidor local (HSS) si dicho usuario está ya registrado con dicha identidad privada, responder (CX-QUERY RESP) a dicha interrogación de registro con información para manejar adicionalmente dicha solicitud de registro; comprendiendo dicha información una o cualquier combinación de ellas entre: una indicación de estado registro que establece si dicho usuario no está registrado con dicha identidad privada recibida, las capacidades requeridas para una entidad de servidor de control de sesión (S-CSCF) a fin de soportar el control de sesión para otras sesiones que implican a dicho usuario para dicha identidad pública y dicha identidad privada, información relacionada con un servidor de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) que está ya asignado para servir al control de sesión a dicho usuario para dicha identidad pública recibida y cualquiera de las identidades privadas asociadas a la suscripción de dicho usuario, una lista que contiene información relacionada con una o más de la pluralidad de servidores de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) que están ya asignados para servir al control de sesión a dicho usuario para cualquiera de las identidades pública y privada asociadas a la suscripción de dicho usuario.
3. El método de la reivindicación 2ª, que comprende además las operaciones de: seleccionar de acuerdo con dicha información para manejar dicha solicitud de registro, una entidad de servidor de control de sesión (S-CSCF) para servir al control de sesión para otras sesiones que implican a dicho usuario para dicha identidad pública y dicha identidad privada, y conceder (200 OK) el registro de dicho usuario desde dicho terminal (UE) en dicho sistema.
4. El método de la reivindicación 3ª, en el que la operación de conceder comprende la operación de conceder (200 OK) dicho registro a dicho terminal (UE) desde dicho servidor de control de sesión seleccionado (S-CSCF) mediante la entidad de servidor de primer punto de contacto (P-CSCF) que sirve al acceso de dicho terminal a dicho sistema.
5. El método de la reivindicación 4ª, en el que la operación de conceder dicho registro desde dicho servidor de control de sesión seleccionado (S-CSCF) comprende además la operación de unir dicha identidad pública recibida con una lista que contiene información de cada servidor de primer punto de contacto (P-CSCF1, P-CSCF2, P-CSCF3) a través del cual un registro que contiene dicha identidad pública ha sido concedido (200 OK) desde dicho servidor de control de sesión.
6. El método de la reivindicación 4ª, en el que la operación de conceder dicho registro a través de dicha entidad de servidor de primer punto de contacto (P-CSCF) comprende además la operación de unir dicha identidad pública recibida con una lista que contiene la dirección individual (IP-ADDR) de cada terminal (UE1, UE2, UE3) que ha tenido un registro concedido a través de él (200 OK) y ha usado dicha identidad pública en el registro concedido.
7. El método de la reivindicación 3ª, que comprende además las operaciones de: enviar (CX-PUT) desde dicho servidor de control de sesión seleccionado (S-CSCF) a dicho servidor local (HSS) información relacionada con dicho servidor de control de sesión seleccionado (S-CSCF1, S-CSCF2, S-CSCF3), dicha identidad pública recibida y dicha identidad privada recibida; almacenar en dicho servidor local (HSS) información que establece que dicho servidor de control de sesión seleccionado (S-CSCF1, S-CSCF2, S-CSCF3) está asignado para servir al control de sesión para otras sesiones relacionadas con dicho usuario para dicha identidad pública recibida y dicha identidad privada recibida; siendo almacenada dicha información además de cualquier información almacenada previamente eventual relativa a cualquier otro servidor de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) ya asignado para servir al control de sesión para otras sesiones relacionadas con dicho usuario para cualquier identidad pública y cualquier identidad privada asignada a la suscripción de dicho usuario.
8. El método de la reivindicación 7ª, que comprende además la operación de unir en dicho servidor local (HSS) dicha identidad pública recibida con una lista que contiene información relacionada con cada servidor de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) que ha notificado (CX-PUT) que está asignado para servir al control de sesión para otras sesiones relacionadas con dicho usuario para dicha identidad pública.
9. El método de cualquiera de la reivindicaciones 1ª a 8ª, en el que la manipulación de un establecimiento de sesión dirigido a dicho usuario comprende las operaciones de: recibir una solicitud de sesión (INVITACIÓN) que contiene una identidad pública relacionada con la suscripción de dicho usuario en dicho sistema de telecomunicación, y tratar dicha solicitud de sesión de acuerdo con el estado de registro de las identidades públicas e identidades privadas de dicho usuario.
10. El método de la reivindicación 9ª, en el que la operación de tratar dicha solicitud de sesión (INVITACIÓN) comprende una operación de entre las de: reenviar dicha solicitud de sesión a un terminal (UE) entre una pluralidad de terminales (UE1, UE2, UE3) que tiene un registro concedido (200 OK) para dicha suscripción; reenviar dicha solicitud de sesión secuencialmente a más de uno de dicha pluralidad de terminales (UE1, UE2, UE3), hasta que dicha sesión es reconocida por uno de ellos; reenviar dicha solicitud de sesión simultáneamente a más de uno de dicha pluralidad de terminales (UE1, UE2, UE3).
11. El método de la reivindicación 9ª, en el que la operación de tratar dicha solicitud de sesión de acuerdo con el estado de registro de las identidades públicas e identidades privadas de dicho usuario comprende las operaciones de: recibir una interrogación de solicitud de localización (CX-LOCATION-QUERY) que contiene dicha identidad pública recibida en dicha entidad de servidor local (HSS), responder (CX-LOCATION-QUERY RESP) a dicha interrogación de solicitud de localización con información para otra manipulación de dicha solicitud de sesión; comprendiendo dicha información una o una combinación de entre las siguientes: una lista que contiene información relacionada con una o más entidades de servidor de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) que están asignadas para servir al control de sesión a dicho usuario para dicha identidad pública recibida; una lista que contiene información relacionada con una o más entidades de servidor de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) que están asignadas para servir al control de sesión a dicho usuario y para cualquiera de sus identidades públicas; en el que la información de un servidor de control de sesión (S-CSCF) está además acompañada de una identidad pública para reemplazar, como identidad pública recibida, la identidad pública recibida originalmente siempre que dicho servidor de control de sesión (S-CSCF) está sirviendo al control de sesión a dicho usuario para una identidad pública diferente de la identidad pública recibida originalmente.
12. El método de la reivindicación 11ª, que comprende además una operación de entre la de: reenviar la solicitud de sesión a un servidor de control de sesión (S-CSCF) recibida en dicha información para otro manejo de dicha solicitud de sesión; reenviar la solicitud de sesión secuencialmente a más de un servidor de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) recibido en dicha información para otro manejo de dicha solicitud de sesión, hasta que la sesión es reconocida por uno de ellos; reenviar la solicitud de sesión simultáneamente a más de un servidor de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) recibido en dicha información para otro manejo de dicha solicitud de sesión.
13. El método de la reivindicación 12ª, que comprende además una operación de entre las de: reenviar una solicitud de sesión recibida desde un servidor de control de sesión (S-CSCF) a una entidad de servidor de primer punto de contacto (P-CSCF) entre una pluralidad de servidores de primer punto de contacto (P-CSCF1, P-CSCF2, P-CSCF3) a través de los cuales ha sido concedido (200 OK) un registro que contiene la identidad pública recibida desde dicho servidor de control de sesión (S-CSCF); reenviar una solicitud de sesión recibida desde un servidor de control de sesión (S-CSCF) secuencialmente a más de un servidor de primer punto de contacto (P-CSCF) de entre dicha pluralidad de servidores de primer punto de contacto (P-CSCF1, P-CSCF2, P-CSCF3) hasta que dicha sesión es reconocida por uno de ellos; reenviar una solicitud de sesión recibida desde un servidor de control de sesión (S-CSCF) simultáneamente a más de un servidor de primer punto de contacto (P-CSCF) de entre dicha pluralidad de servidores de primer punto de contacto (P-CSCF1, P-CSCF2, P-CSCF3).
14. El método de la reivindicación 13ª, que comprende además una operación de entre la de: reenviar una solicitud de sesión recibida desde una entidad de servidor de primer punto de contacto (P-CSCF) a un terminal (UE), entre una pluralidad de terminales (UE1, UE2, UE3) dicho servidor de primer punto de contacto está sirviendo acceso que ha tenido un registro concedido (200 OK) usando dicha identidad pública; reenviar una solicitud de sesión recibida desde una entidad de servidor de primer punto de contacto (P-CSCF) secuencialmente a más de un terminal (UE) de entre dicha pluralidad de terminales (UE1, UE2, UE3), hasta que dicha solicitud de sesión es reconocida por uno de ellos; reenviar una solicitud de sesión recibida desde una entidad de servidor de primer punto de contacto (P-CSCF) simultáneamente a más de uno de dicha pluralidad de terminales (UE1, UE2, UE3).
15. Un sistema para manejar múltiple registros de un usuario en un sistema de telecomunicaciones que gestiona o administra información de localización e información de identificación relacionadas con sus usuarios, estando relacionado cada uno de dichos registros con una suscripción de dicho usuario en dichos sistema, comprendiendo el sistema: medios de almacenamiento previstos para almacenar, con relación a dicha suscripción, una pluralidad de identidades privadas, y medios de tratamiento previstos para tratar solicitudes de registro recibidas (REGISTRO) de acuerdo con la identidad privada entre dicha pluralidad de identidades privadas recibidas en cada una de dichas solicitudes, en el que cada una de dichas solicitudes de registro solicita unir un terminal (UE1, UE2, UE3) a dicho sistema para dicha suscripción; caracterizado porque dichos medios de tratamiento están además previstos para tratar cada una de dichas solicitudes de registro recibidas de acuerdo con dicha identidad privada recibida y una identidad pública recibida en dicha solicitud.
16. El sistema de la reivindicación 15ª, en el que dichos medios de tratamiento comprenden: medios para recibir en una entidad de servidor local (HSS) que almacena datos (SD) de dicha suscripción una interrogación de registro (CX-QUERY) que contiene, al menos dichas identidades privada y pública recibidas, medios en dichos servidor local para verificar si dicho usuario está ya registrado con dicha identidad privada, medios en dicho servidor de hogar para responder (CX-QUERY RESP) a dicha interrogación de registro con información para manejar además dicha solicitud de registro; comprendiendo dicha información una o cualquier combinación de ellas de entre: una indicación de estado de registro que establece si dicho usuario no está registrado con dicha identidad privada recibida, las capacidades requeridas para una entidad de servidor de control de sesión (S-CSCF) a fin de soportar el control de sesión para otras sesiones que implican a dicho usuario para dicha identidad pública y dicha identidad privada, información relacionada con un servidor de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) que está ya asignado para servir al control de sesión a dicho usuario para dicha identidad pública recibida y cualquiera de las identidades privadas asociadas con la suscripción de dicho usuario, una lista que contiene información relacionada con una o más de la pluralidad de servidores de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) que están ya asignados para servidor control de sesión a dicho usuario para cualquiera de las identidades pública y privada asociadas con la suscripción de dicho usuario.
17. El sistema de la reivindicación 16ª, en el que dichos medios de tratamiento comprenden además: medios para seleccionar, de acuerdo con dicha información para manejar dicha solicitud de registro, una entidad de servidor de control de sesión (S-CSCF) para servir al control de sesión para otras sesiones que implican a dicho usuario para dicha identidad pública y dicha identidad privada, y medios para conceder (200 OK) el registro de dicho usuario desde dicho terminal (UE) en dicho sistema.
18. El sistema de la reivindicación 17ª, en el que dichos medios para conceder comprenden medios para conceder dicho registro desde dicho servidor de control de sesión seleccionado (S-CSCF) a dicho terminal (UE) a través de la entidad de servidor de primer punto de contacto (P-CSCF) que sirve al acceso de dicho terminal a dicho sistema.
19. El sistema de la reivindicación 18ª, en el que dicho servidor de control de sesión seleccionado (S-CSCF) está previsto para unir una identidad pública dada con una lista que contiene información de cada servidor de primer punto de contacto (P-CSCF1, P-CSCF2, P-CSCF3) a través del cual ha sido concedido (200 OK) un registro que contiene dicha identidad pública desde dicho servidor de control de sesión.
20. El sistema de la reivindicación 18ª, en el que dicha entidad de servidor de primer punto de contacto (P-CSCF) está prevista para unir una identidad pública dada con una lista que contiene la dirección individual (IP-ADDR) de cada terminal (UE1, UE2, UE3) que ha tenido un registro concedido a través de él (200 OK) y ha usado dicha identidad pública en el registro concedido.
21. El sistema de la reivindicación 17ª, en el que dicho servidor local (HSS) está además previsto para almacenar información de un servidor de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) que notifica (CX-PUT) ha sido asignado para servir el control de sesión para otras sesiones relacionadas con dicho usuario para dicha entidad pública recibida y dicha identidad privada recibida; siendo almacenada dicha información además de cualquier información almacenada previamente eventual relativa a cualquier otro servidor de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) ya asignado para servir al control de sesión para otras sesiones relacionadas con dicho usuario para cualquier identidad pública y cualquier identidad privada asignada a la suscripción de dicho usuario.
22. El sistema de la reivindicación 21ª, en el que dicho servidor local (HSS) está además previsto para unir una identidad pública dada con una lista que contiene información relacionada con los servidores de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) que han notificado (CX-PUT) que están asignados para servir al control de sesión para otras sesiones relacionadas con dicho usuario para dicha identidad pública.
23. El sistema de cualquiera de las reivindicaciones 15ª a 22ª, en el que para la manipulación de un establecimiento de sesión dirigido a un usuario, dichos medios de tratamiento están además previstos para tratar una solicitud de sesión (INVITACIÓN) que contiene una identidad pública relacionada con la suscripción de dicho usuario y de acuerdo con el estado de registro de las identidades públicas y privadas de dicho usuario.
24. El sistema de la reivindicación 23ª, en el que dichos medios de tratamiento están previstos para: reenviar dicha solicitud de sesión a un terminal (UE) entre una pluralidad de terminales (UE1, UE2, UE3) que tiene un registro concedido (200 OK) para dicha suscripción, o reenviar dicha solicitud de sesión secuencialmente a más de uno de dicha pluralidad de terminales (UE1, UE2, UE3), hasta que dicha sesión es reconocida por uno de ellos, o reenviar dicha solicitud de sesión simultáneamente a más de uno de dicha pluralidad de terminales (UE1, UE2, UE3).
25. El sistema de la verificación 23ª, en el que dichos medios de tratamiento comprenden: medios para recibir una interrogación de solicitud de localización (CX-LOCATION-QUERY) que contiene dicha identidad pública recibida en dicha entidad de servidor local (HSS), medios para responder (CX-LOCATION-QUERY RESP) a dicha interrogación de solicitud de localización con información para otra manipulación de dicha solicitud de sesión; comprendiendo dicha información una o cualquier combinación de entre: una lista que contiene información relacionada con una o más entidades de servidor de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) que están asignadas para servir al control de sesión a dicho usuario para dicha identidad pública recibida, una lista que contiene información relacionada con una o más entidades de servidor de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) que están asignadas para servir al control de sesión a dicho usuario para cualquiera de sus identidades públicas; en el que la información de un servidor de control de sesión (S-CSCF) está además acompañada de una identidad pública para reemplazar, como identidad pública recibida, la identidad pública recibida originalmente siempre que dicho servidor de control de sesión (S-CSCF) está sirviendo el control de sesión a dicho usuario para una identidad pública diferente de la identidad pública recibida originalmente.
26. El sistema de la reivindicación 25ª, en el que dichos medios de tratamiento están además previstos para: reenviar la solicitud de sesión a un servidor de control de sesión (S-CSCF) recibido en dicha información para un manejo adicional de dicha solicitud de sesión, o reenviar la solicitud de sesión secuencialmente a más de un servidor de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) recibido en dicha información para otra manipulación de dicha solicitud de sesión, hasta que la sesión es reconocida por uno de ellos, reenviar la solicitud de sesión secuencialmente a más de un servidor de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) recibida en dicha información para otra manipulación de dicha solicitud de sesión, hasta que la sesión es reconocida por uno de ellos, o reenviar la solicitud de sesión simultáneamente a más de un servidor de control de sesión (S-CSCF1, S-CSCF2, S-CSCF3) recibido en dicha información para otra manipulación de dicha solicitud de sesión.
27. El método de la reivindicación 26ª, en el que un servidor de control de sesión (S-CSCF) que recibe una solicitud de sesión está previsto para: reenviar una solicitud de sesión recibida a una entidad de servidor de primer punto de contacto (P-CSCF) entre una pluralidad de servidores de primer punto de contacto (P-CSCF1, P-CSCF2, P-CSCF3) a través de los cuales ha sido concedido (200 OK) un registro que contiene la identidad pública recibida desde dicho servidor de control de sesión (S-CSCF), o reenviar dicha solicitud de sesión secuencialmente a más de un servidor de primer punto de contacto (P-CSCF) de entre dicha pluralidad de servidores de primer punto de contacto (P-CSCF1, P-CSCF2, P-CSCF3) hasta que dicha sesión es reconocida por uno de ellos, reenviar dicha solicitud de sesión simultáneamente a más de un servidor de primer punto de contacto (P-CSCF) de entre dicha pluralidad de servidores de primer punto de contacto (P-CSCF1, P-CSCF2, P-CSCF3).
28. El sistema de la reivindicación 27ª, en el que una entidad de servidor de punto de contacto (P-CSCF) que recibe una solicitud de sesión está prevista para: reenviar dicha solicitud de sesión a un terminal (UE), entre una pluralidad de terminales (UE1, UE2, UE3) dicho servidor de primer punto de contacto está sirviendo acceso que ha tenido un registro concedido (200 OK) usando dicha identidad pública, o reenviar dicha solicitud de sesión secuencialmente a más de un terminal (UER) de entre una pluralidad de terminales (UE1, UE2, UE3), hasta que dicha solicitud de sesión es reconocida por uno de ellos, o reenviar dicha solicitud de sesión simultáneamente a más de un terminal (UE) de entre dicha pluralidad de terminales (UE1, UE2, UE3).
ES02748776T 2001-07-03 2002-06-14 Metodo y sistema para gestionar multiples registros. Expired - Lifetime ES2235065T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP01116146 2001-07-03
EP01116146 2001-07-03

Publications (1)

Publication Number Publication Date
ES2235065T3 true ES2235065T3 (es) 2005-07-01

Family

ID=8177929

Family Applications (1)

Application Number Title Priority Date Filing Date
ES02748776T Expired - Lifetime ES2235065T3 (es) 2001-07-03 2002-06-14 Metodo y sistema para gestionar multiples registros.

Country Status (6)

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

Families Citing this family (177)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7496111B2 (en) * 2000-08-08 2009-02-24 Convergin Israel Ltd. Interface for intelligent network services
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
EP2296343B1 (en) 2003-02-19 2015-04-15 Nokia Technologies OY Routing messages via an 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
US20050111454A1 (en) * 2003-11-25 2005-05-26 Narjala Ranjit S. Method, apparatus and system for intelligently and dynamically routing mobile internet protocol packets
US20050113109A1 (en) * 2003-11-25 2005-05-26 Farid Adrangi Method, apparatus and system for context-based registrations based on intelligent location detection
US20050111380A1 (en) * 2003-11-25 2005-05-26 Farid Adrangi Method, apparatus and system for mobile nodes to dynamically discover configuration information
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
KR100741152B1 (ko) * 2004-01-07 2007-07-20 후아웨이 테크놀러지 컴퍼니 리미티드 홈 가입자 서버의 인터페이스 부하를 감소시키는 방법
GB0409496D0 (en) 2004-04-28 2004-06-02 Nokia Corp Subscriber identities
US8868772B2 (en) 2004-04-30 2014-10-21 Echostar Technologies L.L.C. Apparatus, system, and method for adaptive-rate shifting of streaming content
US7818444B2 (en) 2004-04-30 2010-10-19 Move Networks, Inc. Apparatus, system, and method for multi-bitrate content streaming
GB0409704D0 (en) * 2004-04-30 2004-06-02 Nokia Corp A method for verifying a first identity and a second identity of an entity
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
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
US20060067244A1 (en) * 2004-09-30 2006-03-30 Microsoft Corporation Registration identifier reuse
WO2006066149A2 (en) * 2004-12-17 2006-06-22 Tekelec Methods, systems, and computer program products for clustering and communicating between internet protocol multimedia subsystem (ims) entities
JP4567752B2 (ja) * 2005-01-19 2010-10-20 テレフオンアクチーボラゲット エル エム エリクソン（パブル） エマージェンシーコールを処理するための方法及び装置
EP1842392B1 (en) * 2005-01-21 2014-01-01 Oracle Israel Ltd. Service convergence across multiple communication domains
US7865188B2 (en) * 2005-01-21 2011-01-04 Oracle Israel Ltd. Convergence of ancillary call services across multiple communication domains
EP2146531A3 (en) * 2005-01-26 2015-12-23 Sharp Kabushiki Kaisha Mobile communication network subscriber information management system, subscriber information management method, communication control device, communication terminal, and communication control method
GB0502383D0 (en) * 2005-02-04 2005-03-16 Nokia Corp User identities
WO2006102943A1 (en) * 2005-04-01 2006-10-05 Telefonaktiebolaget Lm Ericsson (Publ) Method for initiating ims based communications
DE102005015111A1 (de) * 2005-04-01 2006-10-05 Siemens Ag Aufrechthaltung von Daten-Verbindungen beim Wechsel des Kommunikationsnetzes
WO2006117323A1 (en) * 2005-04-29 2006-11-09 Telefonaktiebolaget Lm Ericsson (Publ) Service profile handling in the 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注册触发实现方法
EP1921796B1 (en) * 2005-08-31 2009-12-16 Huawei Technologies Co., Ltd. Method of session processing in an ims and interrogating-call state control function
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
ES2351102T3 (es) * 2006-03-01 2011-01-31 NOKIA SIEMENS NETWORKS GMBH &amp; CO. KG Procedimiento para el autoaprovisionamiento de datos de abonado en el subsistema multimedia ip (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
ATE463119T1 (de) * 2006-08-23 2010-04-15 Ericsson Telefon Ab L M Verfahren zum registrieren einer nicht-ims- benutzereinrichtung in einer ims-domäne
US9986414B1 (en) 2006-09-29 2018-05-29 Sprint Communications Company L.P. Dynamic CSCF assignment
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
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
US8584199B1 (en) * 2006-10-17 2013-11-12 A10 Networks, Inc. System and method to apply a packet routing policy to an application session
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
CA2612924C (en) * 2006-12-19 2016-04-26 Bce Inc. Method, system and apparatus for causing a communication client to join a media-over-packet communication session
EP2095593A4 (en) * 2006-12-21 2014-05-14 Ericsson Telefon Ab L M METHOD AND ARRANGEMENT FOR MANAGING SERVICE REQUEST IN A MULTIMEDIA NETWORK
EP2131557B1 (en) * 2006-12-29 2014-11-12 Huawei Technologies Co., Ltd. Method and system and network element for service processing after network element data invalidated and occuring fault
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 (en) * 2007-05-07 2008-11-12 Nokia Siemens Networks Oy Method for operating a telecommunication system
KR101398908B1 (ko) * 2007-05-22 2014-05-26 삼성전자주식회사 모바일 아이피를 사용하는 이동 통신 시스템에서 단말의이동성 관리 방법 및 시스템
CN101796872A (zh) * 2007-07-27 2010-08-04 日本电气株式会社 通信系统、用户设备注册方法、交换设备和用户设备注册系统
EP2028910A1 (en) 2007-08-21 2009-02-25 NEC Corporation Method for allowing a UICC to manage the PDP context parameters
CN101378327A (zh) * 2007-08-29 2009-03-04 中国移动通信集团公司 通信网络系统和通信网络业务处理方法
CN101141691B (zh) * 2007-10-11 2011-06-22 中兴通讯股份有限公司 P-cscf识别禁止呼叫用户的方法及系统
WO2009083888A2 (en) * 2007-12-27 2009-07-09 Nokia Corporation 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
JP5345154B2 (ja) 2008-01-11 2013-11-20 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Ｉｐマルチメディアサブシステムにおけるメッセージハンドリング
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
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
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
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
US9967132B2 (en) * 2008-04-08 2018-05-08 Nokia Solutions And Networks Oy Correlating communication sessions
WO2009124938A2 (en) 2008-04-08 2009-10-15 Nokia Siemens Networks Oy Correlating communication sessions
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
US7925774B2 (en) 2008-05-30 2011-04-12 Microsoft Corporation Media streaming using an index file
WO2009150092A1 (en) * 2008-06-11 2009-12-17 Nokia Siemens Networks Oy Method, apparatus, system and related computer program product for handover management
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
US7836185B2 (en) * 2008-06-27 2010-11-16 International Business Machines Corporation Common resource management in a server cluster
WO2010000295A1 (en) * 2008-06-30 2010-01-07 Telefonaktiebolaget Lm Ericsson (Publ) Providing location information in an ip multimedia subsystem 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
US8880067B2 (en) 2008-08-08 2014-11-04 Qualcomm Incorporated Correlating registrations originating from a device
US8265140B2 (en) * 2008-09-30 2012-09-11 Microsoft Corporation Fine-grained client-side control of scalable media delivery
US8971884B2 (en) * 2008-09-30 2015-03-03 At&T Mobility Ii Llc Rejection notification to a universal integrated circuit card
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
CN102449615B (zh) * 2009-05-27 2014-11-26 甲骨文以色列有限公司 为基于事件的网络提供基于会话的服务
US20120128006A1 (en) * 2009-08-11 2012-05-24 Telefonaktiebolaget L M Ericsson (Publ) Method and Arrangement for Enabling Multimedia Services for a Device in a Local Network
EP2478684B1 (en) * 2009-09-18 2018-11-07 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
WO2011137926A1 (en) 2010-05-03 2011-11-10 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
WO2012097883A1 (en) * 2011-01-17 2012-07-26 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for authenticating a communication device
EP2671396B1 (en) 2011-02-04 2019-07-24 Tekelec, Inc. Methods, systems, and computer readable media for provisioning a diameter binding repository
US8611890B2 (en) * 2011-02-23 2013-12-17 T-Mobile Usa, Inc. System and method for subscribing for internet protocol multimedia subsystems (IMS) services registration status
JP5885761B2 (ja) 2011-03-01 2016-03-15 テケレック・インコーポレイテッドＴｅｋｅｌｅｃ， Ｉｎｃ． ダイヤメータ結合データを共有するための方法、システム、およびコンピュータ読取可能媒体
US8737304B2 (en) 2011-03-01 2014-05-27 Tekelec, Inc. Methods, systems, and computer readable media for hybrid session based diameter routing
JP5759064B2 (ja) 2011-05-06 2015-08-05 テケレック・インコーポレイテッドＴｅｋｅｌｅｃ， Ｉｎｃ． 加入者をアクセスネットワーク間で誘導するための方法、システム、およびコンピュータ可読媒体
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
US10002141B2 (en) 2012-09-25 2018-06-19 A10 Networks, Inc. Distributed database in software driven networks
CN108027805B (zh) 2012-09-25 2021-12-21 A10网络股份有限公司 数据网络中的负载分发
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
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
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
US9531846B2 (en) 2013-01-23 2016-12-27 A10 Networks, Inc. Reducing buffer usage for TCP proxy session based on delayed acknowledgement
US9900252B2 (en) 2013-03-08 2018-02-20 A10 Networks, Inc. Application delivery controller and global server load balancer
US9992107B2 (en) 2013-03-15 2018-06-05 A10 Networks, Inc. Processing data packets using a policy based network path
WO2014179753A2 (en) 2013-05-03 2014-11-06 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
US10230770B2 (en) 2013-12-02 2019-03-12 A10 Networks, Inc. Network proxy layer for policy-based application proxies
CN103607411B (zh) * 2013-12-02 2017-06-16 中国联合网络通信集团有限公司 一种ims用户标识的处理方法及装置
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
US9986061B2 (en) 2014-06-03 2018-05-29 A10 Networks, Inc. Programming a data network device using user defined scripts
US9992229B2 (en) 2014-06-03 2018-06-05 A10 Networks, Inc. Programming a data network device using user defined scripts with licenses
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
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
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
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
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
US10965738B2 (en) * 2016-11-25 2021-03-30 Extreme Networks, Inc. Correlating and load balancing IMS traffic in a visibility network
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
FI104139B1 (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
EP0990364B1 (de) * 1998-04-17 2001-06-06 Swisscom Mobile AG Roaming-verfahren
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
DE60202527T2 (de) 2006-03-30
US7177642B2 (en) 2007-02-13
US20050009520A1 (en) 2005-01-13
WO2003005669A1 (en) 2003-01-16
EP1402705B1 (en) 2005-01-05
ATE286641T1 (de) 2005-01-15
DE60202527D1 (de) 2005-02-10
EP1402705A1 (en) 2004-03-31

Similar Documents

Publication Publication Date Title
ES2235065T3 (es) Metodo y sistema para gestionar multiples registros.
ES2607328T3 (es) Manejo de Perfiles de servicio en el IMS
CA2471640C (en) Communication node architecture
US8693312B2 (en) Method, system and device for processing registration exception in user registration procedure
US9860737B2 (en) Communication system and method
ES2687988T3 (es) Método y elemento para control de servicio
US8315258B2 (en) Routing messages
KR100731321B1 (ko) 통신 네트워크에서 특수 형태의 세션 처리 방법 및 시스템
US9037732B2 (en) Method of implementing UE capability exchange and route control for parallel IMS and CS services
ES2375871T3 (es) Acceso de grupo a un servicio del subsistema multimedia ip.
ES2384525T3 (es) Método para realizar la activación del registro de usuarios en un subsistema multimedia IP
KR100909533B1 (ko) 사용자 아이덴티티들
ES2371109T3 (es) Sistema y aparato para usuarios de cs móvil para acceder a la red de ims y el método de registro para el acceso.
ES2390988T3 (es) Gestión de mensajes en un subsistema multimedia IP
US9021014B2 (en) Methods, systems, and computer readable media for providing home subscriber server (HSS) proxy
US20040246965A1 (en) System and method for routing messages
ES2327274T3 (es) Tratamiento o gestion de mensajes en un subsistema multimedia ip.
ES2406065T3 (es) Métodos y aparatos para iniciar el aprovisionamiento de datos de abonado en un HSS de una red del subsistema de multimedia sobre IP
US20070055874A1 (en) Bundled subscriber authentication in next generation communication networks
US9692835B2 (en) Method and apparatuses for the provision of network services offered through a set of servers in an IMS network
BRPI0717609A2 (pt) Sistema e método para fornecer serviços combinacionais a chamadores anônimos
ES2396625T3 (es) Método, sistema y dispositivo para establecer relaciones de asociación-control
ES2452515T3 (es) Método para sustitución de tarjeta SIM
ES2385292T3 (es) Métodos, nodo de telecomunicaciones, y equipo de usuario para la transmisión de un identificador de usuario
ES2325093T3 (es) Transmision de datos en una red de telecomunicaciones.