ES2334690T3 - Metodo y aparato para asignar servidores de aplicacion en un ims. - Google Patents
Metodo y aparato para asignar servidores de aplicacion en un ims. Download PDFInfo
- Publication number
- ES2334690T3 ES2334690T3 ES05775830T ES05775830T ES2334690T3 ES 2334690 T3 ES2334690 T3 ES 2334690T3 ES 05775830 T ES05775830 T ES 05775830T ES 05775830 T ES05775830 T ES 05775830T ES 2334690 T3 ES2334690 T3 ES 2334690T3
- Authority
- ES
- Spain
- Prior art keywords
- server
- subscriber
- application
- application server
- addresses
- 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
Links
Classifications
-
- 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
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- 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
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Telephonic Communication Services (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Hardware Redundancy (AREA)
- Small-Scale Networks (AREA)
Abstract
Un método para asignar un Servidor de Aplicación con Protocolo de Iniciación de Sesión a un abonado dentro de un Subsistema Multimedia IP, comprendiendo el método: identificar en un Servidor de Abonado Local un conjunto de criterios de filtrado inicial aprovisionados para el citado abonado, conteniendo el citado conjunto de criterios de filtrado inicial al menos una identidad de Servidor de Aplicación con Protocolo de Iniciación de Sesión; enviar el citado conjunto de criterios de filtrado inicial del Servidor de Abonado Local a una Función de Control de Llamada/Sesión de Servicio; recibir el citado conjunto de criterios de filtrado inicial en la citada Función de Control de Llamada/Sesión de Servicio y resolver la citada identidad de Servidor de Aplicación con Protocolo de Iniciación de Sesión en una pluralidad de direcciones de Servidor de Aplicación; asignar una de las citadas direcciones al citado abonado para su uso en proporcionar un servicio al citado abonado; almacenar temporalmente la dirección asignada en la Función de Control de Llamada/Sesión de Servicio para el citado abonado para un uso subsiguiente; y enviar un mensaje de SIP desde la Función de Control de Llamada/Sesión de Servicio al servidor de aplicación y la citada dirección asignada, caracterizado porque Cuando se recibe el citado mensaje de SIP en el servidor de aplicación, la dirección del servidor de aplicación es almacenada como datos no transparentes en el Servidor de Abonado Local, sobre la interfaz Sh.
Description
Método y aparato asignar servidores de
aplicación en un IMS.
La presente invención se refiere a un método y
un aparato para asignar servidores de aplicación en un Subsistema
Multimedia IP.
Los servicios Multimedia IP proporcionan una
combinación dinámica de voz, vídeo, mensajería, datos, etc. dentro
de la misma sesión. Incrementando el número de aplicaciones básicas
y los medios de comunicación que es posible combinar, el número de
servicios ofrecidos a los usuarios finales aumentará, y la
experiencia de comunicación inter-personal se
enriquecerá. Esto llevará a una nueva generación de servicios de
comunicación multimedia ricos, personalizados, que incluyen los
llamados servicios de "Multimedia IP combinacionales".
El IP Multimedia Subsystem (IMS - Subsistema
Multimedia IP) es la tecnología definida por el Third Generation
Partnership Project (3GPP - Proyecto de Colaboración de Tercera
Generación) para proporcionar servicios Multimedia IP sobre redes
de comunicación de telefonía móvil (3GPP, TS 22.228, TS 23.228, TS
24.229, TS 29.228, TS 29.229, TS 29.328 y TS 29.329 Versiones 5 a
7). El IMS proporciona funciones clave para enriquecer la
experiencia de comunicación de
persona-a-persona entre usuarios
finales mediante el uso de IMS Service Enablers - Facilitadores de
Servicios de IMS, que facilitan nuevos servicios de comunicación de
persona-a-persona
(cliente-a-cliente) ricos así como
servicios sobre redes basadas en IP de
persona-a-contenido
(cliente-a-servidor). El IMS hace
uso del Session Initiation Protocol (SIP - Protocolo de Iniciación
de Sesión) para establecer y controlar llamadas o sesiones entre
terminales de usuario (o terminales de usuario y servidores de
aplicación). El Session Description Protocol (SDP - Protocolo de
Descripción de Sesión), llevado a cabo por la señalización de SIP,
se usa para describir y negociar los componentes de medios de
comunicación de la sesión. Mientras que el SIP fue creado como un
protocolo de usuario-a-usuario, el
IMS permite a los operadores y proveedores de servicios controlar
el acceso del usuario a servicios y facturar a los usuarios de
acuerdo con ello.
A modo de ejemplo, la Figura 1 ilustra
esquemáticamente cómo encaja el IMS en la arquitectura de red de
telefonía móvil en el caso de una red de acceso GPRS/PS (el IMS
puede por supuesto operar sobre otras redes de acceso). Las
Call/Session Control Functions (CSCFs - Funciones de Control de
Llamada/Sesión) operan como proxies de SIP dentro del IMS. La
arquitectura de 3GPP define tres tipos de CSCFs: la Proxy CSCF
(P-CSCF) que es el primer punto de contacto dentro
del IMS para un terminal de SIP; la Serving CSCF
(S-CSCF - CSCF de Servicio) que proporciona
servicios al usuario a los cuales está suscrito el usuario; y la
Interrogating CSCF (I-CSCF - CSCF de Interrogación)
cuya función es identificar la S-CSCF correcta y
para enviar a esa S-CSCF una petición recibida desde
un terminal de SIP por medio de una P-CSCF.
Un usuario se registra con el IMS usando el
método de SIP REGISTER especificado. Éste es un mecanismo para
conectarse al IMS y anunciar al IMS la dirección en la cual puede
alcanzarse una identidad de usuario de SIP. En 3GPP, cuando un
terminal de SIP lleva a cabo un registro, el IMS valida al usuario,
y asigna una S-CSCF a ese usuario del conjunto de
S-CSCFs disponibles. Mientras que los criterios para
asignar S-CSCFs no están especificados por 3GPP,
estos pueden incluir compartir la carga y los requisitos de
servicio. Se observa que la asignación de una
S-CSCF es clave para controlar (y facturar) los
accesos del usuario a servicios basados en IMS. Los operadores
pueden proporcionar un mecanismo para evitar sesiones de SIP de
usuario-a-usuario directas que de
otro modo rodearían a la S-CSCF.
Durante el proceso de registro, es
responsabilidad de la I-CSCF seleccionar una
S-CSCF si una S-CSCF no ha sido ya
seleccionada. La I-CSCF recibe las capacidades de la
S-CSCF requeridas del Home Subscriber Server (HSS -
Servidor de Abonado Local) de la red local y selecciona una
S-CSCF apropiada basada en las capacidades
recibidas. [Se observa que la asignación de S-CSCF
es llevada a cabo también para un usuario mediante la
I-CSCF en el caso en el que el usuario sea llamado
por otro participante, y de que el usuario no esté actualmente
situado en una S-CSCF]. Cuando un usuario registrado
envía a continuación una petición de sesión al IMS, la
P-CSCF es capaz de enviar la asignación a la
S-CSCF seleccionada basándose en la información
recibida desde la S-CSCF durante el proceso de
registro.
Dentro de la red de servicio de IMS, se
proporcionan Application Servers (ASs - Servidores de Aplicación)
para implementar una funcionalidad de servicio de IMS. Los
Servidores de Aplicación proporcionan servicios a
usuarios-finales en un sistema de IMS, y pueden
estar conectados bien como puntos finales sobre la interfaz Mr
definida en 3GPP, o estar "conectados" por una
S-CSCF sobre la interfaz de ISC definida para 3GPP.
En el último caso, una S-CSCF usa Initial Filter
Criteria (IFC - Criterios de Filtrado Inicial) para determinar qué
Servidores de Aplicación deben estar "conectados" durante el
establecimiento de una sesión de SIP (o incluso para el propósito
de cualquier método de SIP, relacionado o no con la sesión). Los
IFCs son recibidos por la S-CSCF desde un HSS
durante el procedimiento de registro de IMS como parte de un Perfil
de Usuario de los usuarios.
\global\parskip0.900000\baselineskip
La Figura 2 ilustra la interfaz de IMS Service
Control (ISC - Control de Servicio de IMS) entre un AS y una
S-CSCF, así como otras interfaces dentro del IMS.
Aunque el AS de la Figura 2 se muestra con una sola interfaz a una
S-CSCF, se apreciará que en la práctica la interfaz
de ISC se extenderá a través de la red de comunicación a la cual
muchos (o todos) de los servidores de CSCF de la red de un operador
dado están conectados, permitiendo a un AS comunicar con todas
estas CSCFs. [Otras entidades ilustradas en la Figura 1 serán bien
conocidas por los expertos].
Existe otra interfaz (Ut) entre el AS y un
terminal de usuario (TS23.002) aunque esto no se muestra en la
Figura. La interfaz Ut permite al usuario gestionar la información
relativa a sus servicios, por ejemplo la creación y la asignación
de Identidades de Servicio Públicas, políticas de gestión o
autorización que son usadas por ejemplo por servicios de
"presencia", gestión de política de conferencia, etc.
En el IMS como está definido en 3GPP, mientras
que los abonados son estadísticamente asignados a un HSS, son los
ASs los que proporcionan un valor específico en el caso de servicios
proporcionados por la red. Una lectura de la especificación 3GPP en
las versiones 5 y 6 sugiere que los abonados son asignados a ASs de
SIP particulares de una manera fija. El concepto básico es que un
abonado está preparado para ser soportado por un servidor de
aplicación de AS de SIP específico para un servicio o servicios
dados. Con el fin de permitir a la S-CSCF asignada
alcanzar al AS asignado sobre la interfaz de ISC, los criterios de
filtrado (contenidos dentro del IFC enviado a la
S-CSCF desde el HSS) para ese abonado para ese
servicio contienen un Fully Qualified Domain Name (FQDN - Nombre de
Dominio Calificado Completamente) o una dirección IP como la
dirección de destino (codificada como una SIP-URI).
Esto implica, por ejemplo, que cuando la S-CSCF
identifica que una INVITE particular debe ser encaminada a un AS, a
la S-CSCF se le proporciona la dirección de un AS
específico por medio de la interfaz Cx. Con el fin de identificar
el AS correcto para otras interfaces, por ejemplo como la interfaz
Ut entre los terminales de usuario y los SIP-AS, a
los proxies de encaminamiento se les proporciona la dirección del
AS para el usuario particular. Donde los abonados están asignados a
ASs específicos, entonces bien el terminal está configurado para
esa interfaz y servicio, o la interfaz envía la petición a una
entidad que conoce cómo obtener la dirección del AS para ese
interfaz. Un "extremo frontal" podría hacerlo y, en tal caso,
la funcionalidad de encaminamiento estaría configurada en el extremo
frontal.
El documento WO2005/064896 describe un mecanismo
para la asignación dinámica de Servidores de Aplicación del interior
de un conjunto de servidores. Existen direcciones de Servidor de
Aplicación dentro del HSS y son proporcionadas a la
S-CSCF cuando el usuario se registra.
Como quedará claro a partir de la explicación
anterior, la propuesta existente para la asignación de ASs a
abonados requiere proporcionar un usuario a un servidor de
aplicación de SIP específico para un servicio dado o conjunto de
servicios dados. Esto requiere un elevado nivel de disponibilidad y
almacenamiento de datos persistente en los ASs como, si un único AS
resulta temporalmente no disponible o no guarda la información
apropiada, el servicio o los servicios proporcionado o
proporcionados no resultará disponible para los abonados a los
cuales se les ha asignado el AS. Adoptar este planteamiento puede
requerir la construcción de redundancia a cada AS.
De acuerdo con un primer aspecto de la presente
invención se proporciona un método de asignar un Servidor de
Aplicación con Protocolo de Iniciación de Sesión a un abonado dentro
de un Subsistema Multimedia IP, comprendiendo el método:
- identificar en un Servidor de Abonados Local un conjunto de criterios de filtrado inicial existente para el citado abonado, conteniendo el citado conjunto de criterios de filtrado inicial al menos una identidad de Servidor de Aplicación con Protocolo de Iniciación de Sesión;
- enviar el citado conjunto de criterios de filtrado inicial desde el Servidor de Abonados Local hasta una Función de Control de Llamada/Sesión de Servicio asignada al citado abonado;
- recibir el citado conjunto de criterios de filtrado inicial en la citada Función de Control de Llamada/Sesión de Servicio y resolver la citada identidad de Servidor de Aplicación con Protocolo de Iniciación de Sesión en una pluralidad de direcciones de Servidor de Aplicación;
- asignar una de las citadas direcciones al citado abonado para su uso en proporcionar un servicio al citado abonado;
- guardar temporalmente la dirección asignada a la Función de Control de Llamada/Sesión de Servicio para el citado abonado para su uso subsiguiente; y
- enviar un mensaje de SIP desde la Función de Control de Llamada/Sesión de Servicio al servidor de aplicación en la citada dirección asignada,
- caracterizado porque
- cuando se recibe el citado mensaje de SIP en el servidor de aplicación, la dirección del servidor de aplicación es almacenada como datos no transparentes en el Servidor de Abonado Local, sobre la interfaz Sh.
\global\parskip1.000000\baselineskip
Las realizaciones de la presente invención
introducen un considerable grado de flexibilidad a un abonado. En el
caso de que un Servidor de Aplicación de SIP dado resulte no
disponible o no sea capaz de proporcionar el servicio deseado, la
S-CSCF puede simplemente asignar un nuevo Servidor
de Aplicación al abonado.
Preferiblemente, la citada identidad de Servidor
de Aplicación con Protocolo de Iniciación de Sesión es una
SIP-URI.
Preferiblemente, la citada pluralidad de
direcciones de Servidor de Aplicación son Nombres de Dominio
Calificados Completamente o direcciones IP.
Preferiblemente, la citada etapa de resolver la
citada identidad de Servidor de Aplicación con Protocolo de
Iniciación de Sesión en una pluralidad de direcciones de Servidor de
Aplicación comprende enviar una petición que contiene la citada
identidad de Servidor de Aplicación con Protocolo de Iniciación de
Sesión a un Servidor de Nombre de Dominio, respondiendo del
Servidor de Nombre de Dominio identificando una pluralidad de
direcciones de Servidor de Aplicación correspondientes a la citada
identidad de Servidor de Aplicación con Protocolo de Iniciación de
Sesión, y enviando a la Función de Control de Llamada/Sesión de
Servicio la citada pluralidad de direcciones.
En una realización de la invención, la citada
etapa de asignar una de las citadas direcciones al citado abonado
para su uso en proporcionar un servicio al citado abonado comprende
seleccionar una dirección basada en una priorización de direcciones
proporcionadas por el Servidor de Nombre de Servicio. La selección
puede basarse en una selección de round-robin,
ponderado de acuerdo con la prioridad.
Preferiblemente, el método comprende, a
continuación de la asignación de una dirección de Servidor de
Aplicación a un abonado, guardar temporalmente en la Función de
Control de Llamada/Sesión de Servicio la asociación entre el abonado
y la dirección.
El método del primer aspecto de la invención
anterior es llevado a cabo en el registro del Protocolo de
Indicación de Sesión del abonado. El método puede ser llevado a cabo
también cuando el abonado no está registrado pero está en el extremo
de finalización de una llamada con Protocolo de Iniciación de
Sesión.
En una realización del primer aspecto de la
invención el método comprende enviar, desde el servidor de
aplicación correspondiente a la dirección asignada a un almacén
central, una o más direcciones de interfaz del servidor de
aplicación. Preferiblemente, el citado almacén central es el citado
Servidor de Abonado Local. Esto se hace tras la recepción de una
petición de SIP para un usuario del cual el servidor de aplicación
no tiene conocimiento.
De acuerdo con un segundo aspecto de la presente
invención se proporciona un método de identificar un servidor de
aplicación de SIP asignado a un abonado en un Subsistema Multimedia
IP, comprendiendo el método:
- cuando se asigna un servidor de aplicación de SIP a un abonado, enviar desde el servidor de aplicación a un Servidor de Abonado Local sobre la interfaz Sh, una o más direcciones de interfaz del servidor de aplicación,
- caracterizado por las etapas de
- almacenar la dirección o las direcciones recibidas como datos no-transparentes en el Servidor de Abonado Local en asociación con la identidad del abonado;
- subsiguientemente recibir una petición desde un abonado en un servidor de aplicación del Subsistema Multimedia IP, y en respuesta enviar una pregunta al citado Servidor de Abonado Local;
- cuando se recibe la citada pregunta en el Servidor de Abonado Local, identificar una dirección (o direcciones) para el servidor de aplicación asignado al abonado, y enviar la dirección o las direcciones identificada o identificadas al servidor de aplicación que hace la pregunta.
\vskip1.000000\baselineskip
El término "servidor de aplicación" como se
usa aquí abarca al servidor de aplicación de SIP convencional así
como otros servidores que tienen una interfaz de SIP.
Preferiblemente, el citado almacén central es un
Servidor de Abonado Local, utilizándose la interfaz Sh para
transferir la citada o citadas dirección o direcciones al Servidor
de Abonado Local. Pueden utilizarse protocolos tales como
Lightweight Directory Access Protocol (LDAP - Protocolo de Acceso a
Directorio Ligero) y Structured Query Language (Lenguaje para
Preguntas Estructurado) para transferir la dirección o direcciones a
los otros almacenes centrales.
Se apreciará que el servidor de aplicación que
recibe la petición puede ser el servidor de aplicación asignado o
no. En el caso de que no sea el servidor de aplicación asignado, la
petición se envía al servidor de aplicación asignado usando una
dirección identificada.
La petición puede ser recibida en el servidor de
aplicación mediante un distribuidor de extremo frontal, por ejemplo
un extremo frontal de un XDMS.
La petición puede ser enviada al servidor de
aplicación desde un terminal de abonado sobre la interfaz Ut.
Los aspectos primero y segundo de la presente
invención se emplean de manera útil en combinación, en cuyo caso la
etapa de enviar desde el servidor de aplicación a un almacén
central, una o más direcciones de interfaz del servidor de
aplicación, es llevada a cabo después de enviar un "método" de
SIP, por ejemplo una petición o un mensaje de registro de SIP, desde
la Función de Control de Llamada/Sesión de Servicio al servidor de
aplicación para un abonado del cual el servidor de aplicación no
contiene actualmente conocimiento.
De acuerdo con un tercer aspecto de la invención
se proporciona un servidor de aplicación para su uso en un
Subsistema Multimedia IP, comprendiendo el servidor de
aplicación:
- una entrada para recibir un método de SIP desde una Función de Control de Llamada/Sesión de Servicio para un abonado, que identifica al servidor de aplicación como un servidor asignado al abonado;
- caracterizado por
- medios para enviar su o sus dirección o direcciones a un Servidor de Abonado Local para su almacenamiento como datos no-transparentes en asociación con la identidad del abonado.
\vskip1.000000\baselineskip
De acuerdo con un cuarto aspecto de la invención
se proporciona un servidor de aplicación para su uso en un
Subsistema Multimedia IP, comprendiendo el servidor de
aplicación:
- una entrada para recibir una petición relativa a un abonado;
- medios para enviar una pregunta a un Servidor de Abonado Local, identificando la pregunta al abonado;
- caracterizado por
- medios para recibir una respuesta del Servidor de Abonado Local que contiene una dirección de un servidor de aplicación ya asignado al abonado; y medios para enviar la petición a la dirección del servidor asignado si el servidor de aplicación asignado no es la aplicación que recibe la petición.
\vskip1.000000\baselineskip
La Figura 1 ilustra esquemáticamente la
integración de un Subsistema Multimedia IP en un sistema de
comunicación de telefonía móvil de 3G;
la Figura 2 ilustra esquemáticamente ciertas
entidades de un Subsistema Multimedia IP que incluyen un Servidor de
Aplicación y una Función de Control de Llamada/Sesión de
Servicio;
la Figura 3 ilustra esquemáticamente un proceso
para asignar un SIP-AS a un abonado durante el
registro de IMS;
la Figura 4 ilustra esquemáticamente un proceso
para manejar una petición de llamada de origen o de finalización
para un abonado registrado;
la Figura 5 ilustra esquemáticamente un proceso
para manejar una petición de llamada de finalización para un abonado
no registrado;
la Figura 6 ilustra esquemáticamente un proceso
para manejar una petición recibida desde un abonado sobre una
interfaz no ISC donde el abonado está registrado con IMS; y
la Figura 7 ilustra esquemáticamente un proceso
para manejar una proceso recibida desde un abonado sobre una
interfaz no ISC donde el abonado no está registrado con el IMS.
Los 3GPP Technical Standards referenciados
anteriormente describen el uso de initial filter criteria (IFC -
Criterios de Filtrado Inicial), que están almacenados en el HSS, y
que son enviados a un nodo de Serving Call/Session Control Function
(S-CSCF - Función de Control de Llamada/Sesión de
Servicio) bien mediante el registro de un abonado o bien cuando se
hace una llamada de finalización a un abonado no registrado.
Convencionalmente, un IFC para un abonado contiene una dirección de
Application Server (AS - Servidor de Aplicación) de SIP, por
ejemplo como un Fully Qualified Domain Name (FQDN - Nombre de
Dominio Completamente Calificado). Esto identifica al AS que está
asignado a ese abonado para un servicio dado. [Es posible para que
un IFC contenga dos o más direcciones de AS correspondientes a
servicios de IMS respectivos]. Si la dirección del AS en el IFC es
un SIP-URL, se usa un DNS para resolver el
SIP-URL a una dirección IP. La
S-CSCF puede almacenar temporalmente la asociación
entre la dirección de SIP-AS específica y la
dirección IP por razones de eficiencia. Este almacenamiento temporal
está típicamente en el cliente de DNS (dentro de la
S-CSCF) y es almacenado por nodo y no por
usuario.
Se propone aquí reemplazar la dirección del
Servidor de Aplicación específica con una identidad de AS genérica,
por ejemplo SIP-AS.operator.com. Esto identifica a
un grupo predefinido de ASs, siendo todos ellos capaces de
proporcionar un servicio de IMS dado. En particular, los initial
filter criteria (IFC), que están almacenados en el HSS, están
provistos de un nombre genérico de un servidor de aplicación (por
ejemplo SIP-AS.operator.com). Durante el registro
de un abonado (o durante una llamada de finalización para un abonado
no registrado), los IFC son descargados a la S-CSCF
a través de la interfaz Cx de acuerdo con los procedimientos
descritos en 3GPP TS 23.228; 3GPP TS 29.228 y 3GPP TS 29.229. La
identidad genérica del SIP-AS es resuelta a un
nombre específico (por ejemplo SIP-AS.operator.com)
que se resuelve también a una dirección IP, o la identidad genérica
se resuelve directamente a un número de direcciones IP. Los métodos
de DNS se usan para el proceso de resolución. [En el caso en el que
se resuelva también a una dirección IP, se necesitan dos recorridos
de ida y vuelta entre la S-CSCF y el DNS]. Los IFC
activan la provisión de un mensaje de registro de tercer
participante (es decir un mensaje de SIP REGISTER) mediante la
S-CSCF para el SIP-AS seleccionado.
La S-CSCF recuerda la asociación entre el abonado y
la dirección del AS seleccionado y envía todos los mensajes
subsiguientes para ese conjunto de filtros a la dirección de
SIP-AS específica.
Para facilitar este proceso, el DNS es
aprovisionado con un nombre de dominio genérico que puede ser
resuelto a un número de nombres de dominio completamente calificado
o a direcciones IP. El nombre de dominio genérico (por ejemplo
SIP-as.operator.com, que corresponde a un servicio
de IMS específico) puede representar un gran número de servidores
de aplicación. El nombre de dominio completamente calificado o la
dirección IP representan a un servidor de aplicación específico
(por ejemplo SIP-AS32.operator.com en el caso de un
FQDN). Con el fin de permitir que las peticiones de usuario sean
recibidas sobre una interfaz que no implique a la
S-CSCF en la asignación de SIP-AS
flexible descrita aquí, es ventajoso permitir que un
SIP-AS asignado almacene temporalmente su dirección
o sus direcciones de contacto en un almacén central, típicamente el
HSS, en asociación con un perfil de abonado. Esto permite que una
petición posterior, recibida sobre tal interfaz, sea enviada al
SIP-AS asignado.
Con referencia a la Figura 3, el procedimiento
de asignación de SIP-AS se describirá ahora en el
contexto de un registro de SIP para un abonado particular. Las
etapas de este procedimiento son como sigue, correspondiendo la
numeración de las etapas con la numeración usada en la Figura:
1a. El terminal de abonado inicia un proceso de
REGISTRO enviando un mensaje de REGISTRO de SIP a la
S-CSCF (por medio de una
P-CSCF).
1b. Durante el proceso de registro, se descarga
un perfil de servicio para el abonado a la S-CSCF
desde el HSS. Este perfil de servicio contiene los criterios de
filtrado inicial que incluyen una identidad de servidor de
aplicación genérica.
2a. Tras completar el proceso de registro, la
S-CSCF aprende de los IFC que debe enviar una
petición de REGISTRO de un tercer participante a un servidor de
aplicación. La S-CSCF debe primero, no obstante,
solicitar las direcciones IP de un servidor de DNS enviándole la
identidad genérica. El servidor de DNS devuelve una respuesta con un
número de direcciones IP correspondientes a respectivos ASs
disponibles. Las direcciones están acompañadas con sus respectivas
ponderaciones de prioridad.
2b. La S-CSCF selecciona una de
las direcciones IP devueltas para enviarle el mensaje de REGISTRO.
La selección se basa en una selección round-robin,
ponderada de acuerdo con la prioridad asignada por el DNS. La
S-CSCF almacena temporalmente un mapeo entre el
abonado y la dirección IP del AS seleccionado.
2c. Un mensaje de registro del tercer
participante es enviado al AS seleccionado por la
S-CSCF.
3. Cuando se recibe el registro del tercer
participante, el AS lleva a cabo las siguientes acciones:
- -
- almacena su propia dirección en el HSS. Esta dirección debe realmente comprender una matriz de direcciones para diferentes interfaces, por ejemplo puede haber una dirección diferente para la recepción de mensajes de SIP, tráfico de HTTP, etc. [La dirección (una de las direcciones) puede ser la dirección de SIP-AS proporcionada a la S-CSCF durante la etapa de resolución de identidad, aunque este no es necesariamente el caso].
- -
- obtiene los datos de abonado específicos de aplicación del HSS.
- -
- el AS indica al HSS que desea ser informado de cambios subsiguientes en los datos del abonado.
\vskip1.000000\baselineskip
A corto plazo, el SIP-AS puede
almacenar su dirección en el HSS usando "datos transparentes"
sobre la interfaz Sh. A largo plazo, la dirección de
SIP-AS puede ser añadida a los datos no
transparentes en el HSS.
Se observa que, mientras que en este ejemplo el
HSS es el depósito central para la dirección del AS (y datos del
abonado), en su lugar pueden usarse algunos otros depósitos
centrales. Éste podría ser una base de datos acoplada
(directamente) a un conjunto de ASs que implemente un servicio de
IMS o que sea genérica para todos los ASs en un dominio de
operador/proveedor de servicios).
Cuando se completa este proceso, se ha
seleccionado un SIP-AS para el abonado. El
SIP-AS ha obtenido una copia de los datos del
abonado del HSS, y la S-CSCF ha almacenado
temporalmente la dirección del SIP-AS asignado para
ese usuario. El SIP-AS ha almacenado también sus
direcciones en el HSS en asociación con la identidad del abonado.
Durante la eliminación del registro, el SIP-AS
elimina la dirección de AS seleccionada del HSS.
Con referencia ahora a la Figura 4, se
describirá un procedimiento para manejar llamadas de origen o de
finalización para un abonado ya registrado. El flujo para llamadas
de origen o de finalización es como sigue:
1. Una petición de SIP para el abonado es
recibida por la S-CSCF.
2. La S-CSCF analiza la petición
de SIP. La S-CSCF identifica la dirección IP del AS
previamente almacenada temporalmente para este abonado.
3. La petición de SIP es enviada al
SIP-AS. El SIP-AS tiene una copia de
los datos específicos de aplicación para el abonado descargados
durante el proceso de registro previo, y procede a tratar la
petición de SIP.
\vskip1.000000\baselineskip
Con referencia ahora a la Figura 5, se
describirá un procedimiento para manejar llamadas de finalización
para un abonado no registrado. Como el abonado ya no está
registrado, la S-CSCF no tiene una dirección IP de
SIP-AS almacenada temporalmente para este abonado,
y tampoco tiene el SIP-AS los datos de abonado
específicos de aplicación del HSS. El flujo del proceso es como
sigue:
1. La S-CSCF recibe una petición
de SIP de finalización.
2. La S-CSCF descarga el perfil
de servicio del HSS. Éste contiene los criterios de filtrado inicial
que concluyen una identidad genérica para el
SIP-AS.
3a. La S-CSCF analiza la
petición de SIP. Si uno de los IFCs coincide, la
S-CSCF entiende que debe enviar la petición de SIP
de finalización a un servidor de aplicación. La identidad del
servidor de aplicación contenida en el IFC es un nombre genérico. La
S-CSCF por lo tanto solicita la dirección IP del
servidor de DNS. El servidor de DNS devuelve una respuesta con un
número de direcciones IP.
3b. La S-CSCF selecciona una de
las direcciones IP devueltas para enviarles el mensaje de REGISTRO.
La S-CSCF almacena temporalmente un mapeo entre el
abonado y la dirección IP del AS seleccionado.
4. La petición de SIP de finalización es enviada
al SIP-AS seleccionado.
5. Cuando se recibe la petición de SIP de
finalización, el AS lleva a cabo las siguientes acciones:
- -
- almacena su propia dirección o direcciones para el usuario en el HSS.
- -
- obtiene los datos de abonado específicos de aplicación del HSS.
- -
- el AS indica al HSS que desea ser informado de cambios subsiguientes en los datos del abonado.
\vskip1.000000\baselineskip
Durante la eliminación del registro, el
SIP-AS elimina la dirección del AS almacenada del
HSS. Opcionalmente, el SIP-AS y la
S-CSCF pueden tener un temporizador que indica que
los datos pueden ser guardados durante un cierto periodo de tiempo
tras su eliminación del registro. En este caso, el
SIP-AS eliminará la dirección del AS almacenada
cuando expira el temporizador.
Se observa que, en algunos casos, por ejemplo,
en los que el SIP-AS envía una petición (recibida de
la S-CSCF) a otro SIP-AS, las
direcciones que están almacenadas en el HSS por el primer AS
mencionado pueden ser direcciones para el otro AS. Esto puede
ocurrir cuando el AS tiene funcionalidad de distribución de extremo
frontal, o cuando no ha habido ninguna respuesta del AS
seleccionado originariamente. Puede ocurrir también cuando hay un
desacuerdo entre la dirección almacenada por la
S-CSCF y el AS que sirve al usuario. En este caso.
El AS que recibe inicialmente la petición debe comprobar si el
abonado está asignado a otro AS buscando la asociación de
usuario-AS en el HSS. Si ésta existe, la petición
debe ser enviada al AS correcto. Si el usuario no está asignado a
un AS (no existe asociación usuario-AS en el HSS),
el AS debe escribir su dirección en el HSS. Esto permite que el
tráfico del FE sea encaminado al AS correcto.
\newpage
A continuación del registro de un abonado al
IMS, es posible que un abonado inicie alguna acción, por ejemplo un
cambio de datos y características de un servicio de IMS particular,
enviando una petición a un AS sobre la interfaz Ut. La entidad
funcional que maneja tráfico Ut se denomina XDMS, un XML Document
Management Server (XDMS - Servidor para Gestión de Documentos de
XML que está típicamente situado conjuntamente con un AS particular.
La dirección de ese AS podría estar almacenada previamente en el
terminal como una dirección por defecto para la interfaz Ut. De una
manera similar a la forma en la cual es manejado el tráfico de ISC,
en la que la S-CSCF encamina la señalización al AS
que sirve a un usuario particular, se requiere una entidad funcional
de extremo frontal para asegurar que el tráfico Ut es encaminado al
XDMS situado conjuntamente con el AS que proporciona servicio al
usuario.
Una petición de un terminal de abonado enviada
sobre la interfaz Ut es recibida por un extremo frontal de XDMS. El
Extremo frontal de XDMS busca la dirección del AS que se refiere a
la funcionalidad de XDMS, sobre la interfaz Sh. (Nota: Ésta es una
de las direcciones de AS que fue almacenada en los procedimientos
descritos anteriormente). En el caso de que no haya ninguna
dirección de SIP-AS almacenada, el propio extremo
frontal seleccionará una dirección de SIP-AS y
enviará la petición a ese SIP-AS. El
SIP-AS al cual es enviada la petición almacenará
entonces su dirección en el HSS, obtendrá los datos del abonado del
HSS (o de otro lugar de almacenamiento central) y procederá a tratar
la petición.
Con referencia a la Figura 5, se describirá
ahora un proceso genérico para el manejo de peticiones de otras
interfaces (incluyendo la interfaz Ut), cuando un AS ha sido ya
asignado a un abonado.
1. Una petición es recibida sobre la interfaz
desde un terminal de abonado. La petición es terminada en un
"Distribuidor de extremo frontal" para el servicio representado
por ese extremo frontal.
2. El FE-DIST solicita la
dirección de AS para la aplicación del HSS (u otro sitio
central).
3. La dirección de AS es devuelta al
FE-DIST.
4. La petición es enviada por el
FE-DIST al XDMS.
\vskip1.000000\baselineskip
Con referencia a la Figura 6, se describirá
ahora un proceso genérico para el manejo de peticiones de otras
interfaces (incluyendo la interfaz Ut), cuando un AS todavía no ha
sido asignado a un abonado.
1. Una petición es recibida desde el terminal de
abonado sobre la interfaz particular. La petición es terminada en un
"Distribuidor de externo frontal" para el servicio representado
por ese extremo frontal.
2. El FE-DIST solicita la
dirección de AS para el servicio del HSS.
3. Una indicación de que ningún AS ha sido
asignado es devuelta al FE-DIST.
4. El FE-DIST selecciona un AS
(puede utilizar otras bases de datos para obtener los nombres de ASs
válidos).
5. La petición es enviada al AS
seleccionado.
6. El AS seleccionado lleva a cabo lo
siguiente:
- -
- El SIP-AS puede almacenar su nombre en el HSS.
- (Nota: Esto puede no ser requerido si la transacción va a ocurrir sólo una vez y no se espera que haya subsiguientes peticiones).
- -
- Lee los datos del abonado del HSS.
- -
- Trata o procesa la petición.
\vskip1.000000\baselineskip
En el caso de que se reciba subsiguientemente
una petición de SIP en la S-CSCF, ésta puede ser
manejada por la S-CSCF que selecciona un nuevo
SIP-AS que usa una identidad de AS genérica de
acuerdo con el planteamiento descrito anteriormente. El HSS es
informado de la selección, y a su vez informa al AS asignado
previamente de que ya no está asignado y de que puede liberar datos
almacenados y olvidar al usuario (como resultado de que el AS se
haya "suscrito" a cambios en el elemento de datos en el
HSS).
El experto apreciará que pueden hacerse varias
modificaciones a las realizaciones descritas anteriormente sin
separarse del ámbito de la presente invención.
Claims (11)
1. Un método para asignar un Servidor de
Aplicación con Protocolo de Iniciación de Sesión a un abonado dentro
de un Subsistema Multimedia IP, comprendiendo el método:
- identificar en un Servidor de Abonado Local un conjunto de criterios de filtrado inicial aprovisionados para el citado abonado, conteniendo el citado conjunto de criterios de filtrado inicial al menos una identidad de Servidor de Aplicación con Protocolo de Iniciación de Sesión;
- enviar el citado conjunto de criterios de filtrado inicial del Servidor de Abonado Local a una Función de Control de Llamada/Sesión de Servicio;
- recibir el citado conjunto de criterios de filtrado inicial en la citada Función de Control de Llamada/Sesión de Servicio y resolver la citada identidad de Servidor de Aplicación con Protocolo de Iniciación de Sesión en una pluralidad de direcciones de Servidor de Aplicación;
- asignar una de las citadas direcciones al citado abonado para su uso en proporcionar un servicio al citado abonado;
- almacenar temporalmente la dirección asignada en la Función de Control de Llamada/Sesión de Servicio para el citado abonado para un uso subsiguiente; y
- enviar un mensaje de SIP desde la Función de Control de Llamada/Sesión de Servicio al servidor de aplicación y la citada dirección asignada,
- caracterizado porque
- Cuando se recibe el citado mensaje de SIP en el servidor de aplicación, la dirección del servidor de aplicación es almacenada como datos no transparentes en el Servidor de Abonado Local, sobre la interfaz Sh.
\vskip1.000000\baselineskip
2. Un método de acuerdo con la reivindicación 1,
en el que la citada identidad de Servidor de Aplicación con
Protocolo de Iniciación de Sesión es una
SIP-URI.
3. Un método de acuerdo con la reivindicación 1
ó 2, en el que la citada pluralidad de direcciones de Servidor de
Aplicación son Nombre de Dominio Completamente Calificado o
direcciones IP.
4. Un método de acuerdo con cualquiera de las
reivindicaciones precedentes, en el que la citada etapa de resolver
la citada identidad del Servidor de Aplicación con Protocolo de
Iniciación de Sesión en una pluralidad de direcciones de Servidor de
Aplicación comprende enviar una petición que contiene la citada
identidad de Servidor de Aplicación con Protocolo de Iniciación de
Sesión a un Servidor de Nombre de Dominio, respondiendo el Servidor
de Nombre de Dominio identificando una pluralidad de direcciones de
Servidor de Aplicación correspondientes a la citada identidad de
Servidor de Aplicación con Protocolo de Iniciación de Sesión, y
enviando a la Función de Control de Llamada/Sesión de Servicio la
citada pluralidad de direcciones.
5. Un método de acuerdo con cualquiera de las
reivindicaciones precedentes, siendo el método llevado a cabo
durante el registro del abonado mediante el Protocolo de Iniciación
de Sesión.
6. Un método de acuerdo con una de las
reivindicaciones 1 a 4, siendo el método llevado a cabo cuando el
abonado es eliminado del registro pero está en el extremo de
finalización de una llamada con Protocolo de Iniciación de
Sesión.
7. Un método de identificar un servidor de
aplicación de SIP asignado a un abonado en un Subsistema Multimedia
IP, comprendiendo el método:
- cuando se asigna un servidor de aplicación de SIP a un abonado, enviar desde el servidor de aplicación a un Servidor de Abonado Local sobre la interfaz Sh, una o más direcciones de interfaz del servidor de aplicación,
- caracterizado por las etapas de
- almacenar la dirección o las direcciones recibidas como datos no transparentes en el Servidor de Abonado Local en asociación con la identidad del abonado;
- subsiguientemente recibir una petición de un abonado en un servidor de aplicación del Subsistema Multimedia IP, y en respuesta enviar una pregunta al citado almacén central;
- cuando se recibe la citada pregunta en el Servidor de Abonado Local, identificar una dirección (o direcciones) para el servidor de aplicación asignado al abonado, y
- enviar la direcciones o direcciones identificadas al servidor de aplicación que está preguntando.
\vskip1.000000\baselineskip
8. Un método de acuerdo con la reivindicación 7,
en el que, en el caso de que el servidor de aplicación que recibe la
citada petición no sea el servidor de aplicación asignado, la
petición es enviada al servidor de aplicación asignado usando una
dirección identificada, y, si el abonado no está asignado a un
servidor de aplicación, el servidor de aplicación de recepción envía
su dirección al citado Servidor de Abonado Local.
9. Un método que usa el método de acuerdo con la
reivindicación 1 y el método de acuerdo con la reivindicación 7, en
el que la etapa de enviar desde el servidor de aplicación al
Servidor de Abonado Local, una o más direcciones del servidor de
aplicación, es llevada a cabo a continuación del envío de un método
de SIP desde la Función de Control de Llamada/Sesión de Servicio al
servidor de aplicación.
10. Un servidor de aplicación para su uso en un
Subsistema Multimedia IP, comprendiendo el servidor de
aplicación:
- una entrada para recibir un método de SIP de una Función de Control de Llamada/Sesión de Servicio para un abonado, identificando el servidor de aplicación como un servidor asignado para el abonado;
- caracterizado por
- medios para enviar su dirección o direcciones de interfaz al Servidor de Abonado Local para su almacenamiento como datos no transparentes en asociación con la identidad del abonado.
\vskip1.000000\baselineskip
11. Un servidor de aplicación para su uso en un
Subsistema Multimedia IP, comprendiendo el servidor de
aplicación:
- una entrada para recibir una petición relativa a un abonado;
- medios para enviar una pregunta a un Servidor de Abonado Local, identificando la pregunta al abonado;
- caracterizado por
- medios para recibir una respuesta desde el Servidor de Abonado Local que contiene una dirección de un servidor de aplicación ya asignado al abonado; y
- medios para enviar la petición a la dirección del servidor asignado si el servidor de aplicación asignado no es la aplicación que recibe la petición.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US70068305P | 2005-07-19 | 2005-07-19 | |
| US700683P | 2005-07-19 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2334690T3 true ES2334690T3 (es) | 2010-03-15 |
Family
ID=35911072
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES05775830T Expired - Lifetime ES2334690T3 (es) | 2005-07-19 | 2005-08-15 | Metodo y aparato para asignar servidores de aplicacion en un ims. |
Country Status (11)
| Country | Link |
|---|---|
| US (2) | US7761600B2 (es) |
| EP (1) | EP1905208B1 (es) |
| JP (2) | JP4856179B2 (es) |
| CN (3) | CN101223754A (es) |
| AT (2) | ATE445283T1 (es) |
| BR (2) | BRPI0520429B1 (es) |
| DE (2) | DE602005017081D1 (es) |
| ES (1) | ES2334690T3 (es) |
| MX (2) | MX2008000757A (es) |
| RU (2) | RU2404539C2 (es) |
| WO (2) | WO2007009499A1 (es) |
Families Citing this family (66)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE602005017081D1 (de) * | 2005-07-19 | 2009-11-19 | Ericsson Telefon Ab L M | Verfahren und vorrichtung zum zuteilen von anwendungsservern in einem ims |
| ES2402773T3 (es) * | 2005-09-02 | 2013-05-08 | Swisscom Ag | Procedimiento y sistema para proporcionar contenido de medios a un usuario |
| EP1879337B1 (en) * | 2005-10-21 | 2012-08-29 | Huawei Technologies Co., Ltd. | A method for processing the register message in the ims network according to the initial filtering rules |
| WO2007071276A1 (en) * | 2005-12-22 | 2007-06-28 | Telecom Italia S.P.A. | Multi-vendor ims architecture |
| MX2008013704A (es) * | 2006-04-28 | 2008-11-04 | Nokia Corp | Seleccion s-cscf para peticiones originadas de servidor de aplicacion. |
| JP4804244B2 (ja) * | 2006-07-03 | 2011-11-02 | 株式会社日立製作所 | アプリケーションをフィルタリングする装置、システム及び方法 |
| US8849986B2 (en) * | 2006-08-14 | 2014-09-30 | Samsung Electronics Co., Ltd | System and method for presence notification based on presence attribute |
| US9986414B1 (en) * | 2006-09-29 | 2018-05-29 | Sprint Communications Company L.P. | Dynamic CSCF assignment |
| CN101166129A (zh) * | 2006-10-20 | 2008-04-23 | 华为技术有限公司 | 获取应用服务器标识信息的方法、终端、设备和系统 |
| CN101170540A (zh) * | 2006-10-24 | 2008-04-30 | 华为技术有限公司 | 一种xml文档管理方法和客户端、服务器 |
| CN100446516C (zh) * | 2006-12-01 | 2008-12-24 | 华为技术有限公司 | 一种实现视频共享业务的方法、系统及装置 |
| CN101563903B (zh) * | 2006-12-11 | 2013-03-06 | 艾利森电话股份有限公司 | 用于向用户提供ip多媒体子系统通信服务的方法和设备 |
| EP2119177B1 (en) * | 2006-12-19 | 2012-07-25 | Telefonaktiebolaget LM Ericsson (publ) | Technique for providing services in an IMS network |
| US20080175225A1 (en) * | 2007-01-18 | 2008-07-24 | Lon-Chan Chu | Just-in-time call registration for mobile call to voip device |
| US20110060771A1 (en) * | 2007-02-21 | 2011-03-10 | Miguel Angel Monjas Llorente | Method And Apparatuses For Handling Storage Of User Data In 3G Digital Cellular Telecommunication Systems |
| JP5249952B2 (ja) * | 2007-02-22 | 2013-07-31 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | Ｉｐマルチメディアサブシステムサービスへのグループアクセス |
| JP2008236183A (ja) | 2007-03-19 | 2008-10-02 | Nec Corp | 呼セッション制御サーバ割り当て方法および呼セッション制御サーバ割り当てシステム |
| US7979523B2 (en) * | 2007-05-08 | 2011-07-12 | Cisco Technology, Inc. | Deferred invocation of communication services |
| WO2008151545A1 (en) * | 2007-06-14 | 2008-12-18 | Huawei Technologies Co., Ltd. | A method, device and system for triggering service |
| WO2009002143A1 (en) * | 2007-06-22 | 2008-12-31 | Telefonaktiebolaget Lm Ericsson (Publ) | Method of providing a service through a user equipment unit in an ip multimedia subsystem telecommunications network, including a user database server, service policy server and application server for use with said method |
| JP5066608B2 (ja) * | 2007-07-10 | 2012-11-07 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | Ｉｍｓを用いたオペレータ提供ネットワークサービスの発見方法 |
| CN101345748B (zh) | 2007-07-13 | 2010-08-04 | 华为技术有限公司 | 将用户状态通知应用服务器的方法、系统及装置 |
| WO2009028096A1 (ja) * | 2007-08-31 | 2009-03-05 | Fujitsu Limited | セッション状態の通知に係る通信方法、サーバ、およびプログラム |
| EP2204035B1 (en) * | 2007-10-15 | 2015-07-08 | Telefonaktiebolaget LM Ericsson (publ) | IP multimedia subsystem service configuration |
| US20090113077A1 (en) * | 2007-10-26 | 2009-04-30 | Torbjorn Dahlen | Service discovery associated with real time composition of services |
| JP2011505084A (ja) * | 2007-11-02 | 2011-02-17 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | 通信ネットワークにおいて使用するための方法および装置 |
| JP4882966B2 (ja) * | 2007-11-12 | 2012-02-22 | 沖電気工業株式会社 | プロキシサーバ、通信プログラム及び通信システム |
| US8654949B2 (en) * | 2008-01-07 | 2014-02-18 | At&T Intellectual Property I, L.P. | Methods, systems and computer program products for providing access to personal profiles in communications systems |
| CA2713999C (en) | 2008-01-28 | 2016-03-22 | Research In Motion Limited | Providing session initiation protocol request contents method and system |
| JP5078661B2 (ja) * | 2008-02-22 | 2012-11-21 | 株式会社エヌ・ティ・ティ・ドコモ | 呼制御システム、通信制御装置及び呼制御方法 |
| US8306507B2 (en) * | 2008-04-11 | 2012-11-06 | Research In Motion Limited | Differentiated message delivery notification |
| US8750132B2 (en) * | 2008-12-16 | 2014-06-10 | At&T Intellectual Property I, L.P. | Method and apparatus for completing a call in a network with ENUM failure |
| US8868686B1 (en) * | 2009-03-31 | 2014-10-21 | Microsoft Corporation | Sharing of repository data for non-alias identities |
| FR2943881A1 (fr) * | 2009-03-31 | 2010-10-01 | France Telecom | Procede et dispositif de gestion d'une authentification d'un utilisateur. |
| JP5313395B2 (ja) * | 2009-04-13 | 2013-10-09 | リサーチ イン モーション リミテッド | Ｓｉｐメッセージに対する信用を決定するシステムおよび方法 |
| US8737271B2 (en) | 2009-06-01 | 2014-05-27 | Telefonaktiebolaget L M Ericsson (Publ) | Graphical user-interface for terminals with visual call progress indicator |
| WO2010142349A1 (en) * | 2009-06-12 | 2010-12-16 | Telefonaktiebolaget L M Ericsson (Publ) | Method and server entity for forwarding a message containing a host name or domain name in an internet based communications 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. |
| US9385938B2 (en) * | 2010-06-22 | 2016-07-05 | Blackberry Limited | Information distribution in a wireless communication system |
| US8468258B2 (en) * | 2010-07-26 | 2013-06-18 | Alcatel Lucent | IPv6 generation to trigger a virtual leased line service |
| US8619547B2 (en) * | 2010-11-10 | 2013-12-31 | At&T Intellectual Property I, L.P. | Communication system with failover communication services |
| US8547966B2 (en) * | 2010-12-06 | 2013-10-01 | At&T Intellectual Property I, L.P. | Method and apparatus for configuring IP multimedia subsystem network elements |
| US9794776B2 (en) * | 2011-05-04 | 2017-10-17 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and network entity for S-CSCF server allocation in an IMS based multimedia over IP network |
| JP5411203B2 (ja) * | 2011-05-25 | 2014-02-12 | 株式会社Ｎｔｔドコモ | サービス選択制御装置及びサービス選択制御システム |
| US8712409B2 (en) | 2012-03-05 | 2014-04-29 | T-Mobile Usa, Inc. | System and method for terminating communication sessions with roaming mobile devices |
| EP2645672A1 (en) * | 2012-03-30 | 2013-10-02 | Vodafone IP Licensing Limited | Method for discovering capabilities of offline users |
| US20130279373A1 (en) * | 2012-04-18 | 2013-10-24 | Interdigital Patent Holdings, Inc. | Method and apparatus for providing an internet protocol multimedia subsystem triggering service |
| US20140341085A1 (en) * | 2013-05-14 | 2014-11-20 | Qualcomm Incorporated | Selecting an application server at which to register one or more user equipments for an internet protocol multimedia subsystem (ims) session |
| US9351203B2 (en) | 2013-09-13 | 2016-05-24 | Microsoft Technology Licensing, Llc | Voice call continuity in hybrid networks |
| US9935787B2 (en) | 2013-12-26 | 2018-04-03 | Microsoft Technology Licensing, Llc | Tunneling VoIP call control on cellular networks |
| US9510251B2 (en) | 2013-12-31 | 2016-11-29 | Microsoft Technology Licensing, Llc | Call handoff initiation in hybrid networks |
| US9560185B2 (en) | 2014-03-19 | 2017-01-31 | Microsoft Technology Licensing, Llc | Hybrid telecommunications network connection indicator |
| US9363711B2 (en) | 2014-04-07 | 2016-06-07 | Microsoft Technology Licensing, Llc | User experiences during call handovers on a hybrid telecommunications network |
| CN103974334B (zh) * | 2014-05-22 | 2018-03-30 | 无锡爱维特信息技术有限公司 | 基于手机号码的服务器负载平衡方法 |
| TWI581601B (zh) * | 2014-05-28 | 2017-05-01 | Chunghwa Telecom Co Ltd | Integration of IMS and intelligent terminal technology to support the wisdom of the guidance system and methods |
| CN104010290A (zh) * | 2014-06-16 | 2014-08-27 | 武汉博睿达信息技术有限公司 | 基于用户信息的ims应用服务器选择系统及选择方法 |
| US9456333B2 (en) | 2014-07-09 | 2016-09-27 | Microsoft Technology Licensing, Llc | Centralized routing in hybrid networks |
| US9819703B2 (en) * | 2015-09-23 | 2017-11-14 | T-Mobile Usa, Inc. | SIP server with multiple identifiers |
| US10791496B2 (en) * | 2016-06-30 | 2020-09-29 | T-Mobile Usa, Inc. | Restoration of serving call session control and application server function |
| EP3556062B1 (en) * | 2016-12-19 | 2023-09-06 | Nokia Technologies Oy | Data storage function selection |
| CN109673004B (zh) * | 2017-10-13 | 2021-10-22 | 成都鼎桥通信技术有限公司 | 终端获取集群业务服务器地址的方法及设备 |
| WO2020222036A1 (en) * | 2019-05-02 | 2020-11-05 | Telefonaktiebolaget Lm Ericsson (Publ) | Dynamic initial filter criteria (ifc) in internet protocol multimedia subsystem (ims) in 5th generation networks |
| CN114629881B (zh) * | 2020-12-14 | 2024-09-24 | 中兴通讯股份有限公司 | 一种sip网元多地址学习方法及装置、信令监测系统 |
| CN114827978B (zh) * | 2022-04-06 | 2022-11-18 | 广州爱浦路网络技术有限公司 | 应用服务器选择方法、装置及存储介质 |
| US12407739B2 (en) | 2022-10-07 | 2025-09-02 | T-Mobile Usa, Inc. | Interconnection border control function and home subscriber server interface for managing voice calls |
| WO2024129098A1 (en) | 2022-12-16 | 2024-06-20 | Robin Systems, Inc | Implementing an infrastructure management service |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10116547A1 (de) * | 2001-04-03 | 2002-10-10 | Nokia Corp | Registrierung eines Endgeräts in einem Datennetz |
| US6757722B2 (en) | 2002-07-16 | 2004-06-29 | Nokia Corporation | System and method for providing partial presence notifications |
| US8001233B2 (en) * | 2003-03-25 | 2011-08-16 | Nokia Corporation | Communication system, network element, and method for configuring a network element using routing subscription information |
| JP4280284B2 (ja) * | 2003-03-25 | 2009-06-17 | ノキア コーポレイション | 通信システムにおけるサービスの提供 |
| WO2005015870A1 (en) * | 2003-08-01 | 2005-02-17 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for routing a service request |
| US20050155036A1 (en) * | 2003-12-19 | 2005-07-14 | Nokia Corporation | Application server addressing |
| EP1551144A1 (en) * | 2003-12-31 | 2005-07-06 | France Telecom | System, method and apparatus for providing multimedia communications services |
| US8064951B2 (en) * | 2004-07-29 | 2011-11-22 | Sprint Spectrum L.P. | Method and system for selective application of cellular-PBX integration service |
| US7643626B2 (en) * | 2004-12-27 | 2010-01-05 | Alcatel-Lucent Usa Inc. | Method for deploying, provisioning and storing initial filter criteria |
| US20060153353A1 (en) * | 2005-01-07 | 2006-07-13 | O'neil Douglas | Intelligent secondary call treatment for advanced calling scenarios |
| DE602005017081D1 (de) * | 2005-07-19 | 2009-11-19 | Ericsson Telefon Ab L M | Verfahren und vorrichtung zum zuteilen von anwendungsservern in einem ims |
-
2005
- 2005-08-15 DE DE602005017081T patent/DE602005017081D1/de not_active Expired - Lifetime
- 2005-08-15 CN CNA2005800510925A patent/CN101223754A/zh active Pending
- 2005-08-15 RU RU2008106226/09A patent/RU2404539C2/ru active
- 2005-08-15 US US11/995,879 patent/US7761600B2/en not_active Expired - Lifetime
- 2005-08-15 WO PCT/EP2005/054010 patent/WO2007009499A1/en not_active Ceased
- 2005-08-15 JP JP2008521810A patent/JP4856179B2/ja not_active Expired - Fee Related
- 2005-08-15 BR BRPI0520429-1A patent/BRPI0520429B1/pt active IP Right Grant
- 2005-08-15 AT AT05775830T patent/ATE445283T1/de not_active IP Right Cessation
- 2005-08-15 ES ES05775830T patent/ES2334690T3/es not_active Expired - Lifetime
- 2005-08-15 CN CN200580051100.6A patent/CN101223755B/zh not_active Expired - Lifetime
- 2005-08-15 MX MX2008000757A patent/MX2008000757A/es active IP Right Grant
- 2005-08-15 US US11/995,871 patent/US8331354B2/en active Active
- 2005-08-15 EP EP05775830A patent/EP1905208B1/en not_active Expired - Lifetime
- 2005-08-15 WO PCT/EP2005/054009 patent/WO2007009498A1/en not_active Ceased
-
2006
- 2006-07-19 RU RU2008106229/09A patent/RU2008106229A/ru unknown
- 2006-07-19 MX MX2008000799A patent/MX2008000799A/es not_active Application Discontinuation
- 2006-07-19 CN CNA2006800260445A patent/CN101223758A/zh active Pending
- 2006-07-19 JP JP2008521969A patent/JP2009502071A/ja not_active Withdrawn
- 2006-07-19 AT AT06764226T patent/ATE470305T1/de not_active IP Right Cessation
- 2006-07-19 BR BRPI0613424A patent/BRPI0613424A2/pt not_active IP Right Cessation
- 2006-07-19 DE DE602006014686T patent/DE602006014686D1/de active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN101223758A (zh) | 2008-07-16 |
| US20080232352A1 (en) | 2008-09-25 |
| BRPI0520429A2 (pt) | 2009-09-29 |
| US8331354B2 (en) | 2012-12-11 |
| DE602005017081D1 (de) | 2009-11-19 |
| CN101223755A (zh) | 2008-07-16 |
| CN101223755B (zh) | 2014-11-05 |
| JP2009502071A (ja) | 2009-01-22 |
| EP1905208A1 (en) | 2008-04-02 |
| RU2008106229A (ru) | 2009-08-27 |
| EP1905208B1 (en) | 2009-10-07 |
| RU2008106226A (ru) | 2009-08-27 |
| CN101223754A (zh) | 2008-07-16 |
| DE602006014686D1 (de) | 2010-07-15 |
| WO2007009498A1 (en) | 2007-01-25 |
| JP4856179B2 (ja) | 2012-01-18 |
| ATE470305T1 (de) | 2010-06-15 |
| MX2008000799A (es) | 2008-03-18 |
| ATE445283T1 (de) | 2009-10-15 |
| US20080212569A1 (en) | 2008-09-04 |
| BRPI0613424A2 (pt) | 2017-05-02 |
| BRPI0520429B1 (pt) | 2019-03-19 |
| JP2009502063A (ja) | 2009-01-22 |
| WO2007009499A1 (en) | 2007-01-25 |
| RU2404539C2 (ru) | 2010-11-20 |
| MX2008000757A (es) | 2008-03-13 |
| US7761600B2 (en) | 2010-07-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2334690T3 (es) | Metodo y aparato para asignar servidores de aplicacion en un ims. | |
| ES2607328T3 (es) | Manejo de Perfiles de servicio en el IMS | |
| ES2687988T3 (es) | Método y elemento para control de servicio | |
| ES2346563T3 (es) | Gestion de interfases de multiples usuarios en un subsistema de multimedios ip. | |
| ES2393952T3 (es) | Proporcionar servicios de empresa en una red de abastecimiento de servicios | |
| ES2379964T3 (es) | Método para inciar comunicaciones basadas en IMSI | |
| ES2390988T3 (es) | Gestión 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 | |
| ES2399004T3 (es) | Tratamiento de identidades de usuario en subsistema multimedia IP | |
| ES2518994T3 (es) | Tratamiento de identidades de usuario en el Subsistema Multimedia IP | |
| US20040246965A1 (en) | System and method for routing messages | |
| US20060018272A1 (en) | Instance identification | |
| US8463264B2 (en) | Early IMS security | |
| US20100232368A1 (en) | Method for multiple registration of a multimodal communication terminal | |
| WO2002032050A2 (en) | Techniques for hiding network element names and addresses | |
| CN101313606A (zh) | 通信系统中感知服务配置下的公共用户标识的方法及装置 | |
| CN102948124B (zh) | 处置因特网协议多媒体子系统网络中公共身份的方法和设备 | |
| ES2327274T3 (es) | Tratamiento o gestion de mensajes en un subsistema multimedia ip. | |
| EP2569998B1 (en) | Enabling set up of a connection from a non-registered UE in IMS | |
| ES2374058T3 (es) | Subsistema multimedia ip (ims) y método para enviar un mensaje http a través de un ims. | |
| EP2119178B1 (en) | Method and apparatuses for the provision of network services offered through a set of servers in an ims network |