ES2341386T3 - Resolucion de una direccion de red de un terminal. - Google Patents
Resolucion de una direccion de red de un terminal. Download PDFInfo
- Publication number
- ES2341386T3 ES2341386T3 ES07823124T ES07823124T ES2341386T3 ES 2341386 T3 ES2341386 T3 ES 2341386T3 ES 07823124 T ES07823124 T ES 07823124T ES 07823124 T ES07823124 T ES 07823124T ES 2341386 T3 ES2341386 T3 ES 2341386T3
- Authority
- ES
- Spain
- Prior art keywords
- address
- network
- resolution
- terminal
- servers
- 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.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
- H04M7/0075—Details of addressing, directories or routing tables
-
- 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/4535—Network directories; Name-to-address mapping using an address exchange platform which sets up a session between two nodes, e.g. rendezvous servers, session initiation protocols [SIP] registrars or H.323 gatekeepers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- 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/4552—Lookup mechanisms between a plurality of directories; Synchronisation of directories, e.g. metadirectories
-
- 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/4557—Directories for hybrid networks, e.g. including telephone numbers
-
- 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]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
- Mobile Radio Communication Systems (AREA)
- Small-Scale Networks (AREA)
- Communication Control (AREA)
Abstract
Un procedimiento de resolución de una dirección de red de un terminal, estando asignado dicho terminal una dirección SIP, comprendiendo el procedimiento: recibir una solicitud de resolución de una dirección relacionada con dicho terminal en una unidad (200) de encaminamiento de una red de telecomunicaciones, estando asociada dicha solicitud de resolución de dirección con la dirección SIP; caracterizado por remitir (202) la solicitud de resolución de dirección a una unidad (204) de resolución, comprendiendo la unidad (204) de resolución una lista priorizada de servidores de direcciones y/o bases de datos, determinando la lista priorizada el orden en el que la unidad de resolución envía las consultas (208) de direcciones a uno o más servidores de direcciones y/o bases de datos; enviar consultas (208) de direcciones a uno o más de dichos servidores de direcciones y/o bases (206, 210, 212, 214, 216) de datos en el orden determinado por dicha lista priorizada procedentes de dicha unidad de resolución; recibir, de cada uno de dichos uno o más servidores de direcciones y/o bases (206, 210, 212, 214, 216) de datos, la dirección de red del terminal o un mensaje de error que indica que no se encontró la dirección de red del terminal; y enviar una respuesta (218) a la solicitud de resolución de dirección de dicha unidad (204) de resolución a la unidad (200) de encaminamiento de la red de telecomunicaciones, incluyendo la respuesta bien la dirección de red del terminal o bien el mensaje de error.
Description
Resolución de una dirección de red de un
terminal.
La presente invención versa acerca de redes
basadas en IP, y más en particular acerca de una disposición de
resolución de una dirección de red de un terminal.
El subsistema multimedia IP (IMS) es una
arquitectura normalizada de trabajo en red para redes móviles de 3ª
generación (3GPP) y generaciones ulteriores, que proporcionan a los
usuarios servicios multimedia móviles y fijos. El IMS funciona con
el Protocolo de Internet (IP) estándar, utilizando una
implementación de voz sobre IP (VoIP) basada en una implementación
normalizada de 3GPP de Protocolo de inicio de sesión (SIP). A su
vez, el SIP es un protocolo desarrollado para iniciar, modificar y
terminar una sesión interactiva de usuario que implica elementos
multimedia tales como vídeo, voz, transmisión instantánea de
mensajes, juegos en línea, y realidad virtual.
La idea básica de la arquitectura IMS es
permitir a un usuario conectarse a una red IMS, con independencia
de la red de acceso (que soporta el Protocolo de Internet
(IP) estándar) que esté utilizando. En consecuencia, se puede
acceder a una red IMS prácticamente por medio de cualquier red
(fija, móvil o inalámbrica) con funciones de conmutación por
paquetes, tal como GPRS, UMTS, CDMA2000, WLAN, WiMAX, DSL, cable,
etc. También se soportan los sistemas telefónicos conmutados por
circuitos, como PSTN y GSM por medio de pasarelas. Los terminales
de IMS directo (tal como teléfonos móviles, PDA, ordenadores) se
pueden registrar directamente en una red IMS, incluso cuando hay
itinerancia; el único requerimiento es que soporten Agentes de
usuario de SIP.
Un aspecto importante del IMS es la mayor
movilidad del usuario; el IMS permite a los operadores y a los
proveedores de servicios utilizar arquitecturas subyacentes de red,
por lo que la red móvil proporciona una movilidad del terminal
(itinerancia), pero la movilidad del usuario es proporcionada por el
IMS y el SIP. En una red 3GPP convencional, el usuario y su
terminal móvil están identificados con las siguientes identidades:
Identidad internacional de abonado móvil (IMSI), una identidad
única de usuario almacenada en el (U)SIM; Identidad temporal
de abonado móvil (TMSI), una identidad única de usuario generada por
ubicación geográfica; Identidad internacional de equipo móvil
(IMEI), una identidad única del dispositivo; y Número ISDN de
abonado móvil (MSISDN), es decir, el número real del teléfono del
usuario. Ahora, la arquitectura IMS incluye algunas identidades
adicionales: Identidad privada de multimedia IP (IMPI), e Identidad
pública de multimedia IP (IMPU). En vez de números de teléfono,
estas identidades son URI (Identificador uniforme de recursos), que
pueden ser dígitos (lo que se denomina tel-uri,
como tel: +358-40-1234567) o
identificadores alfanuméricos (lo que se denomina
sip-uri, como sip: pekka.peloton@sonera.com). La
IMPI es única para el dispositivo terminal, y un usuario puede tener
múltiples IMPU por IMPI (a menudo un tel-uri y un
sip-uri). La IMPU compartida con otro dispositivo
terminal, por lo que se puede localizar a ambos con la misma
identidad (por ejemplo, un único número de teléfono para una
familia entera).
La base de datos de usuarios del IMS (Servidor
local de abonado, HSS) contiene al menos la IMPU, la IMPI, la IMSI
y el MSISDN. Por lo tanto, se puede notificar a un usuario móvil
conforme a su MSISDN como se hace tradicionalmente, pero también
conforme a su IMPU, por ejemplo una dirección SIP. Esto plantea
nuevos retos para resolver la ubicación actual del usuario y la
dirección de encaminamiento, a las que se debería enviar la
solicitud de notificación.
Una razón para estos retos es el hecho de que no
hay ninguna base de datos común de donde se podrían resolver las
direcciones SIP; un único operador puede tener varios dominios de
dirección SIP, que pueden estar recogidos en varias bases de datos
no conectadas y que no son conocidas necesariamente por los otros
operadores. Además, distintos tipos de operadores pueden acceder a
la arquitectura IMS de distintas formas: el operador A puede estar
conectado únicamente por medio de un GPX/IPX (Intercambio de
paquetes entre redes) privado, el operador B únicamente por medio
de Internet, y el operador C únicamente por medio de una
PSTN, por ejemplo. Cada una de estas redes está caracterizada por
sus propios protocolos y estructuras de base de datos, requiriendo
todas un enfoque específico.
Una razón adicional para dichos retos es la
falta de una base de datos ENUM DNS global (Sistema de Nombres de
Dominio de Correlación de Números Telefónicos (también denominado
Numeración Electrónica y Correlación de Números E. 164)); existen
bases de datos ENUM específicas para cada operador, que resuelven
los números MSISDN en direcciones SIP utilizando DNS, pero no todos
los operadores soportan la resolución ENUM DNS. El documento
US2002/0027915 da a conocer un mecanismo de resolución de
direcciones.
Se inventa ahora un procedimiento mejorado y un
equipo técnico que implementa el procedimiento, mediante los cuales
se alivian de forma significativa los problemas de resolver la
dirección de encaminamiento y la ubicación del usuario. Diversos
aspectos de la invención incluyen un procedimiento, un dispositivo
electrónico y un programa de ordenador, que están caracterizados
por lo que se indica en las reivindicaciones independientes. En las
reivindicaciones dependientes se dan a conocer diversas
realizaciones de la invención.
Conforme a un primer aspecto, un procedimiento
conforme a la invención está basado en la idea de resolución de una
dirección de red de un terminal, estando asignada a dicho terminal
una dirección SIP, comprendiendo el procedimiento las siguientes
etapas: recibir una solicitud de resolución de dirección relacionada
con dicho terminal en una unidad de encaminamiento de una red de
telecomunicaciones, comprendiendo la unidad de resolución una lista
priorizada que determina el orden en el que la unidad de resolución
envía las consultas de dirección a uno o más servidores de
direcciones y/o bases de datos; enviar consultas de dirección a uno
o más de dichos servidores de direcciones y/o bases de datos en el
orden determinado por dicha lista priorizada desde dicha unidad de
resolución; recibir, de cada uno de dichos uno o más servidores de
direcciones y/o bases de datos, la dirección de red del terminal o
un mensaje de error que indica que no se encontró la dirección de
red del terminal; y enviar una respuesta a la solicitud de
resolución de dirección desde dicha unidad de resolución a la
unidad de encaminamiento de la red de telecomunicaciones, incluyendo
la respuesta bien la dirección de red del terminal o bien el
mensaje de error.
Conforme a una realización, la lista priorizada
comprende uno o más de los siguientes servidores de direcciones y/o
bases de datos: una base de datos DNS/ENUM GRX/IPX; una base de
datos de portabilidad del número móvil (MNP); una base de datos
IR.21; una base de datos de dominios de la red de
telecomunicaciones; una base de datos DNS/ENUM pública.
Conforme a una realización, la base de datos
DNS/ENUM GRX/IPX está colocada en primer lugar en la lista
priorizada.
Conforme a una realización, la solicitud de
resolución de dirección es una solicitud de INVITACIÓN SIP.
Conforme a una realización, el procedimiento
comprende una etapa adicional de enviar, antes de enviar las
consultas de dirección a uno o más servidores de direcciones y/o
bases de datos conforme a la lista priorizada, una consulta de
dirección a una base de datos federada de la red de
telecomunicaciones, incluyendo la base de datos federada
información de nivel global del dominio de Internet incluido
en la solicitud de resolución de dirección.
Conforme a una realización, la red de
telecomunicaciones está basada en una arquitectura de IMS; y la
unidad de encaminamiento es un S-CSCF.
La disposición conforme a la invención
proporciona ventajas significativas. La unidad de resolución permite
una disposición de uso genérico para resolver una dirección de un
terminal cliente remoto, con independencia de a qué tipo de red de
acceso está conectado el terminal. La disposición es igualmente
aplicable a los servicios de redes móviles y de redes fijas, al
igual que a servicios basados puramente en Internet.
Desde el punto de vista del operador, una
ventaja adicional es que la implementación de la unidad de
resolución no está relacionada con estándares; es decir, el
S-CSCF (o cualquier otro solicitante original) envía
una solicitud ENUM/DNS estándar a la unidad de resolución y recibe
una respuesta ENUM/DNS estándar, por lo que el
S-CSCF no necesita estar al tanto de la operación de
la unidad de resolución entre los mismos. Además, una ventaja es
que el operador puede, al menos hasta cierto punto, controlar el
tráfico y dirigirlo a ciertas redes (por ejemplo, debido a los
costes) al ajustar la lista priorizada de forma apropiada. Los
operadores de red no necesita esperar a que se implemente, por
ejemplo, una base de datos ENUM/DNS global, pero pueden ofrecer
nuevos servicios basados en IP inmediatamente.
Este y otros aspectos de la invención y de las
realizaciones relacionadas con la misma serán evidentes en vista de
la revelación detallada de las realizaciones dadas a
continuación.
\vskip1.000000\baselineskip
A continuación, se describirán diversas
realizaciones de la invención con más detalle con referencia a los
dibujos adjuntos, en los que
La Fig. 1 muestra una estructura simplificada de
red, en la que se implementa la red de IMS en conexión con una red
3GPP
la Fig. 2 muestra un ejemplo de arquitectura de
red adecuada para implementar la disposición conforme a la
invención; y
la Fig. 3 muestra un servidor conforme a una
realización de la invención en un gráfico reducido de bloques.
\vskip1.000000\baselineskip
La Fig. 1 muestra una estructura simplificada de
red, en la que la red de IMS está implementada en conexión con una
red 3GPP, e incluso aunque está muy simplificada, se menciona que
ilustra la complejidad de la futura red de telecomunicaciones y,
por ejemplo, las dificultades al resolver la dirección de un
terminal móvil como se ha expuesto anteriormente. Un experto
apreciará que además de los elementos mostrados en la Fig. 1,
diversas implementaciones de la red de IMS también comprenden un
gran número de otros elementos de red, pero la comprensión de la
invención no requiere que se den a conocer estos elementos con la
misma.
Ha habido un cambio significativo de paradigma
en el diseño de las redes móviles desde dominios conmutados por
circuitos hacia dominios conmutados por paquetes. La razón de esto
es el objetivo de permitir una comunicación completa basada en IP,
explotando los beneficios del IP para todos los tipos de tráfico, y
proporcionando una operación sin fisuras entre distintos sistemas.
En consecuencia, los principales elementos de red de la red 3G son
los nodos pasarela GGSN (Nodo de soporte pasarela de GPRS) y los
nodos servidores SGSN (Nodo de soporte servidor de GPRS) ubicados
en una red de dominios de paquetes (dominio PS), tal como una red de
paquetes 3G o una red de paquetes GPRS. Normalmente, hay conectados
varios nodos servidores SGSN a un nodo pasarela GGSN por medio de
una red principal a una red, que utiliza el protocolo IP,
preferentemente IPv6 y aplica una encapsulación conforme a un
protocolo de tunelado de pasarela GTP a todos los datos 3G. El nodo
servidor SGSN están en contacto con los terminales de usuario UT1,
UT2 a través de las redes de acceso de radio UTRAN y GERAN. Una
tarea del nodo servidor SGSN es detectar las estaciones móviles que
tienen capacidad de conexiones de radio por paquetes en su área de
servicio, para transmitir y recibir paquetes de datos de dichas
estaciones móviles y para seguir la ubicación de las estaciones
móviles en su área de servicio. También se almacenan los registros
relacionados con los servicios de radio por paquetes, incluyendo
contenidos de protocolo de datos de paquetes específicos para el
abonado en el servidor local de abonado HSS.
El nodo pasarela GGSN actúa como una pasarela
entre la red de comunicaciones móviles y la red externa de datos
PDN (Red de datos de paquetes). Merece la pena señalar que, a
diferencia del diseño tradicional, se ha reducido el papel del MSC
(Centro de conmutación móvil) a un elemento que solo señaliza,
mientras que se procesa en el tráfico conmutado por circuitos
(acceso CS) y se encamina por medio de una pasarela dedicada de
medios (IMS-MGW). Un Procesador de funciones de
recursos multimedia (MRFP) es otra pasarela del sistema IMS, que se
ocupa de encaminar tráfico basado en IP desde distintas redes de
acceso.
El Subsistema multimedia IP (IMS) comprende en
principio todos los elementos de la red central para la provisión
de servicios multimedia por medio de cualquier comunicación basada
en IP. Utilizando el Protocolo de inicio de sesión (SIP), el IMS
permite a los operadores móviles ofrecer a sus abonados servicios
multimedia basados y construidos sobre aplicaciones, servicios y
protocolos de Internet. Los servidores o proxis SIP del IMS
son denominados colectivamente CSCF (Función de control de la sesión
de llamada), y existen distintos papeles para los servidores SIP
para el procesamiento de paquetes SIP de señalización.
Un P-CSCF
(Proxi-CSCF) es un proxi SIP que es el primer punto
de contacto para el terminal IMS. Hay asignado un terminal IMS a un
P-CSCF particular al registrarse para toda la
duración del registro. Por lo tanto, el P-CSCF está
ubicado en la trayectoria de todos los mensajes de señalización, y
puede inspeccionar cada mensaje. Normalmente, hay un
P-CSCF conectado a las redes de acceso a través de
un PDF (Función de decisión de política), que autoriza los recursos
del plano de medios, por ejemplo, calidad del servicio (QoS),
implementa el control de política, la gestión del ancho de banda,
etc.
Un I-CSCF
(Interrogación-CSCF) es un proxi SIP, cuya dirección
IP está publicada en el DNS del dominio, permitiendo de esta manera
que la encuentren los servidores remotos (por ejemplo, un
S-CSCF en un dominio foráneo), y la utilicen como
un punto de entrada para todos los paquetes SIP a este dominio. El
I-CSCF consulta el HSS para recuperar la ubicación
del usuario, y luego encamina la solicitud SIP a su
S-CSCF asignado.
Un S-CSCF
(Servidor-CSCF) es un servidor SIP que opera como el
nodo central del plano de señalización, y también lleva a cabo un
control de la sesión. El S-CSCF descarga y carga
perfiles de usuario al HSS, y desde el mismo, y gestiona registros
SIP, lo que permite ligar la ubicación del usuario (por ejemplo, la
dirección IP del terminal) y la dirección SIP. Al igual que el
P-CSCF, el S-CSCF está ubicado en la
trayectoria de todos los mensajes de señalización, y puede
inspeccionar cada mensaje. También es la función que proporciona
servicios de encaminamiento, utilizando consultas ENUM/DNS.
En la Fig. 1 también se muestran dos redes
adicionales de acceso, es decir, una red de acceso WLAN que
comprende una pasarela de acceso inalámbrico (WAG) y una pasarela
de datos de paquetes I-WLAN 3 GPP (WLAN PDG) para
terminales con capacidad WLAN (WLAN UE), y una red de acceso xDSL a
través de un DSLAM (Multiplexor de acceso a la línea digital de
abonado) y un BAS (Servidor de acceso de banda ancha) para cualquier
terminal UE que comprenda un módem xDSL, por ejemplo un PC de
sobremesa/portátil. Se encamina su tráfico IP por medio del MRFP y
el tráfico de señalización por medio de la PDF/SPDF.
En consecuencia, es evidente que gestionar, por
ejemplo, los datos de ubicación del usuario y encaminar solicitudes
de notificación en un entorno de red tan versátil es una tarea que
supone un reto. Esto se subraya más aún por el hecho de que no hay
ninguna base de datos común a partir de la cual las direcciones SIP
puedan ser resueltas ni una base de datos ENUM DNS global. Por lo
tanto, si se recibe una solicitud de sesión de llamada en la red
IMS, el S-CSCF, que es el elemento de la red
responsable para resolver la información de dirección del cliente
solicitado, depende principalmente de los datos del perfil del
usuario en el HSS. Sin embargo, como se ha mencionado
anteriormente, el HSS contiene datos de direcciones de únicamente un
número limitado de dominios de red, y existe inevitablemente un
gran número de dominios de red, que son invisibles a un HSS de una
red IMS particular. Si el S-CSCF no puede resolver
la información de dirección del HSS, el S-CSCF envía
normalmente una solicitud ENUM a una base de datos ENUM específica
para el operador, que puede estar operada en común por un número de
operadores de red, pero de nuevo, tampoco se llega a todos los
dominios de red por medio de este procedimiento.
La Fig. 2 muestra un ejemplo de arquitectura de
red adecuada para implementar la disposición conforme a la
invención. Un punto de inicio de este ejemplo es que la red IMS
recibe una invitación SIP para que un cliente participe en una
sesión de llamada, es decir, una solicitud de INVIACIÓN SIP para un
cliente que tiene la dirección juan.nadie@operador.net. En
consecuencia, la red IMS, más en particular el
S-CSCF de la misma, debe resolver el operador real
utilizando el dominio operador.net, el elemento correcto de red al
que está conectado el cliente, y la red, que debe ser utilizada al
encaminar la invitación.
Conforme a la invención, en vez de que el
S-CSCF envíe solicitudes de encaminamiento a
diversas redes, se implementa una unidad lógica suplementaria para
resolver la información requerida de dirección. Esta unidad
suplementaria, que se denomina en el presente documento como "un
dispositivo de resolución" o "una unidad de resolución",
puede ser un elemento aparte de red o únicamente una unidad lógica
aparte implementada en conexión con otro elemento de red, por
ejemplo, con un S-CSCF. Sin embargo, el dispositivo
de resolución está dedicado a resolver la información requerida de
dirección: el S-CSCF envía una solicitud al
dispositivo de resolución, el dispositivo de resolución lleva a
cabo las consultas de dirección y entonces envía una respuesta de
vuelta al S-CSCF. Siempre que se encuentra la
dirección, el S-CSCF puede proceder enviando la
invitación a la dirección correcta conforme a los procedimientos de
la técnica anterior.
Se ilustra adicionalmente ahora la operación del
dispositivo de resolución al hacer referencia al ejemplo de la Fig.
2. El dispositivo 204 de resolución recibe una solicitud 202 de
resolución de dirección del elemento de red IMS responsable para
resolver la información de dirección, por ejemplo del
S-CSCF 200. Preferentemente, el dispositivo de
resolución incluye una lista priorizada de servidores de direcciones
y de bases de datos en el orden de su importancia, conforme a la
que el dispositivo de resolución comienza a resolver la dirección.
Preferentemente, la lista priorizada incluye todos los servidores de
direcciones y bases de datos, en los que se podría encontrar más
probablemente la dirección. Además, la lista priorizada está
redactada, preferentemente, de forma que el servidor de
direcciones/base de datos, en los que con mayor probabilidad se
encuentra la dirección, está colocada en primer lugar en la lista,
intentando minimizar el número de consultas y de esta manera los
costes del operador de la red.
Conforme a una realización, con independencia de
la lista priorizada y de su orden de servidores y de bases de
datos, siempre se puede dirigir la primera solicitud a una base de
datos DNS general que comprende información de nivel global acerca
de la "comunidad" o la "federación" que utiliza el dominio
operador.net. De esta forma se podría resolver el operador real y
se podría dirigir una solicitud más específica a una base de datos
ENUM/DNS correspondiente a dicho operador para resolver más
información específica de dirección del cliente.
Sin embargo, si no se recibe ningún indicio del
dominio a través de esta consulta de base de datos "federada",
entonces un paso lógico para iniciar las consultas reales sería una
base 206 de datos DNS/ENUM GRX/IPX (Intercambio de itinerancia
GPRS/Intercambio de paquetes entre redes), que es una base de datos
DNS/ENUM privada, separada de Internet, operada mutuamente
por diversos operadores GSM, que están conectados entre sí en puntos
de contacto. Las redes GRX trabajan de forma eficaz como una red
principal privada para operadores GSM. En tal base de datos ENUM,
es obligatorio que los operadores participen en la base de datos
para almacenar una dirección E.164 de cada cliente, a diferencia de
la práctica ENUM pública, en el que solo es obligatorio el
almacenamiento de direcciones E.164. En consecuencia, la base de
datos DNS/ENUM GPX/IPX sería el lugar más probable donde encontrar
la dirección de un cliente móvil, y por lo tanto es lógico colocarlo
en primer lugar en la lista priorizada.
La consulta en sí puede estar basada en el
sip-uri, como sip:juan.nadie@operador.net,
por lo que se dirige una consulta DNS estándar a la base de datos
DNS/ENUM IPS. La consulta también puede estar basada en el
tel-uri, como tel:
+358-40-1234567, por lo que el
tel-uri utilizado como una dirección en el
establecimiento de la sesión debe ser resuelto en primer lugar al
dominio ENUM de dirección utilizando una función ENUM estándar, es
decir, se resuelve dicho tel-uri a
7.6.5.4.3.2.1.0.4.8.5.3.e164enum.net.
Para aclarar tanto el procedimiento ENUM como el
DNS, se ilustra a continuación el procedimiento basado en ENUM, que
es conocido como tal. Como se ha explicado anteriormente, al
comienzo el dispositivo 204 de resolución recibe una solicitud 202
de resolución de dirección del S-CSCF 200. En otras
palabras, el S-CSCF 200 de origen envía la consulta
DNS 202 para 7.6.5.4.3.2.1.0.4.8.5.3.e164enum.net al dispositivo 204
de resolución solicitando el NAPTR RR (Registro de recursos de
puntero de autoridad de nombres). El dispositivo 204 de resolución
envía la consulta DNS para 7.6.5.4.3.2.1.0.4.8.5.3.e164enum.net a
un servidor raíz DNS solicitando el NAPTR RR, y el servidor raíz da
acuse de recibo de la consulta con el NS (Servidor de nombres) y RR
A (definiendo la bandera "A" la siguiente etapa de búsqueda
para remitir información en particular, no a cualquier otro tipo de
registro disponible en los sistemas DNS) para e164enum.net, es
decir, el servidor de nombres y dirección para un nivel inferior
(es decir, capa) de la estructura ENUM jerárquica.
En consecuencia, se lleva a cabo la consulta
ENUM como una serie de consultas repetidas, estando dirigida cada
consulta adicional a una capa inferior, es decir, un subdominio
definido más específicamente del espacio de nombres DNS, hasta que
se encuentra el NAPTR RR real para el cliente. Por lo tanto, el
dispositivo de resolución envía la consulta DNS para
7.6.5.4.3.2.1.0.4.8.5.3.e164enum.net al servidor ENUM Capa 0/1
solicitando el NAPTR RR, por lo que el servidor ENUM Capa 0/1
devuelve los NS RR de los servidores ENUM Capa 2 para
7.6.5.4.3.2.1.0.4.8.5.3.e164enum.net al dispositivo de resolución.
Entonces, el dispositivo de resolución escoge el NS RR con un nombre
de anfitrión, tal como enums1.abc.gprs, y envía la consulta DNS
para enum1.abc.gprs al servidor raíz solicitando el RR A. El
servidor raíz devuelve el NS y los RR A asociados para abc.gprs al
dispositivo de resolución.
Entonces, el dispositivo de resolución
selecciona de nuevo el NS RR con un nombre de anfitrión, tal como
dns1.abc.gprs, y envía la consulta DNS para enum1.abc.gprs al
servidor DNS solicitando el RR A, por lo que el servidor DNS
devuelve el RR A al dispositivo de resolución. Finalmente, el
dispositivo de resolución envía la consulta DNS para
7.6.5.4.3.2.1.0.4.8.5.3.e164enum.net al servidor ENUM Capa 2
solicitando el NAPTR RR, el servidor ENUM Capa 2 devuelve los NAPTR
RR al dispositivo de resolución, que entonces devuelve los NAPTR RR
al S-CSCF. Para una revelación más detallada de los
procedimientos ENUM, se hace referencia al documento IETF
RFC2916.
Después de que el S-CSCF ha
recibido los NAPTR RR, la sesión se establecerá de forma normal. El
IMS de origen ubica los servidores SIP en base a NAPTR RR recibidos
utilizando DNS y envía una INVITACIÓN SIP hacia el IMS de
terminación por medio de un Proxi-O IPX y
Proxi-T IPX y se establecerá una conexión del plano
de usuario.
Sin embargo, la portabilidad de número móvil, es
decir, la posibilidad de que el usuario mantenga su número MSISDN
cuando cambia de abono de un operador a otro operador, puede causar
confusión en el anterior procedimiento, si la consulta está basada
en el número MSISDN. Por lo tanto, si no se puedo resolver la
dirección del cliente del GPX/IPX, un siguiente lugar lógico al que
dirigir la consulta sería una MNP DB (base de datos de portabilidad
de números móviles), que incluye información de varios operadores
acerca de números MSISDN transferidos a otro operador.
En este caso, la consulta se lleva a cabo de
forma similar a una llamada GSM conmutada por circuitos estándar o
un mensaje de texto (SMS). En consecuencia, el dispositivo 204 de
resolución envía una solicitud MAP 208 estándar incluyendo el
número MSISDN del cliente al registro de ubicación local HLR, que
realiza una consulta a su propio MNP DB 210 para comprobar si el
número está transferido a otro operador. Si se encuentra el número
MSISDN en el MNP DB, entonces el HLR responde a la consulta y envía
el número actual del cliente al dispositivo 204 de resolución,
indicando el número el operador real al que enviar la solicitud de
establecimiento de sesión.
La implementación de la consulta de la MNP DB
puede llevarse a cabo de diversas formas, dependiendo de cómo se
lleve a cabo la portabilidad del número entre los operadores en cada
país. Por ejemplo, en algunos casos se puede enviar la solicitud
directamente desde el dispositivo 204 de resolución al MNP DB
incluyendo los datos de portabilidad del número en formato XML, por
lo que no es necesario encaminar las consultas a través del HLR.
Sin embargo, en cualquier caso el resultado es el mismo: se recibe
bien una indicación del operador real del cliente o bien un mensaje
de error.
Si no se encuentra ninguna información de
dirección del cliente en el MNP DB, entonces una siguiente etapa
podría ser una consulta a la base 212 de datos IR.21. La base de
datos IR.21 está operada por la GSMA (Asociación GSM, una
asociación de comercio global para operadores móviles), que incluye
información y direcciones IP acerca de elementos de red utilizados
en conexiones entre operadores. Normalmente, la información se
utiliza para gestionar situaciones de itinerancia y de
interconexión. En consecuencia, para resolver la ubicación de un
cliente de un operador particular de red, el dispositivo 204 de
resolución puede, por ejemplo, solicitar una dirección IP de un
MMSC (Centro de servicio de mensajería multimedia) para el cliente
en dicha red. Si se recibe, el dispositivo de resolución puede
utilizar la dirección IP como una dirección para un mensaje de
INVITACIÓN SIP.
Si no se encuentra aun así ninguna información
de la dirección del cliente, entonces el operador de red solicitante
puede comprobar su base 214 de datos interna de dominios, que puede
incluir información acerca de todos los dominios que están
utilizando en la actualidad los socios con los que trabaja el
operador. Como un ejemplo simplificado, dicha base de datos de
dominios puede incluir la siguiente información: operador1.nz:
222.111.123.123. Ahora bien, si se conoce que el cliente cuya
dirección se busca es un cliente del Operador1 en Nueva Zelanda, el
operador es correspondido por un servidor u otro colega que tiene
una dirección IP 222.111.123.123.
Si aun así no se resuelve la información de
dirección del cliente, se puede realizar una consulta a una base
216 de datos DNS/ENUM pública. El procedimiento se parece mucho al
del caso con la base de datos DNS/ENUM GPX/IPX descrito
anteriormente.
Es muy probable que la información de dirección
del cliente se resuelva desde una de las anteriores bases de datos,
y el dispositivo 204 de resolución devuelva la dirección al
S-CSCF 200 con un mensaje 218. Sin embargo, si
ninguno de las anteriores consultas da una dirección resuelta del
cliente, entonces el dispositivo 204 de resolución da acuse de
recibo de la solicitud 202 de resolución de dirección al
S-CSCF 200 con un mensaje 218 de error "no
encontrada".
Conforme a la realización, el
S-CSCF tiene entonces dos opciones fundamentalmente
para proseguir con la búsqueda. Una primera opción es enviar la
solicitud de INVITACIÓN SIP a un Proxi IPX 220 ubicado en la red IPX
descrita anteriormente. Tal proxi IPX puede comprender una base de
datos interna, gestionada por el operador del proxi IPX, que puede
almacenar algo de información propia relacionada con los terminales
cliente y sus ubicaciones. El operador del proxi IPX puede, por
ejemplo, ofrecer un servicio de valor añadido relacionado con la
información del terminal cliente, que puede incluir tal
información, que no está disponible en ningún otro lugar. Si existe
tal base de datos interna, entonces se lleva a cabo una consulta
similar al descrito anteriormente; en este caso, el proxi IPX opera
como el dispositivo de resolución y envía una consulta a la base de
datos interna.
Una segunda opción es llevar a cabo lo que se
denomina desconexión PSTN, es decir, una solicitud MAP estándar al
HLR, que intenta resolver el homólogo mediante consultas básicas de
PSTN 222. Si se encuentra el cliente, entonces se puede establecer
una llamada convencional conmutada por circuitos. Aunque esta opción
no utiliza las propiedades IP del sistema IMS, puede proporcionar
una posibilidad adicional para ubicar el cliente deseado. Un
experto apreciará que dependiendo de la estructura de la red y de la
base de datos de direcciones disponible, pueden existir aún más
opciones, además de las mencionadas anteriormente, para llevar a
cabo una búsqueda adicional.
Un experto apreciará que cualquiera de las
realizaciones descritas anteriormente puede estar implementada como
una combinación con una o más de las otras realizaciones, a no ser
que se indique de forma explícita o implícita que ciertas
realizaciones son únicamente mutuamente alternativas. En particular,
el orden de la lista priorizada, es decir, los servidores de
direcciones y las bases de datos, en los que se busca la dirección
del cliente, pueden variar dependiendo del operador y de la
estructura de red. Por lo tanto, una lista priorizada puede incluir
únicamente un subgrupo de los servidores de direcciones y de las
bases de datos descritos anteriormente en un orden distinto.
Además, merece la pena señalar hacer notar que aunque los anteriores
ejemplos están relacionados con un IMS, las realizaciones no están
limitadas únicamente a una red IMS, sino que pueden estar
implementadas, por ejemplo, en conexión con un servidor SIP
sencillo.
La invención y sus realizaciones proporcionan
ventajas significativas. El dispositivo de resolución descrito
anteriormente permite una disposición de uso genérico para resolver
una dirección de un terminal cliente remoto, con independencia del
tipo de red de acceso a la que está conectado el terminal. La
disposición es igual de aplicable para los servicios de redes
móviles como de redes fijas, al igual que para servicios basados
puramente en Internet. Los operadores de red no necesitan
esperar, por ejemplo, que se implemente una base de datos ENUM/DNS
global, pero pueden ofrecer nuevos servicios basados en IP
inmediatamente.
Desde el punto de vista del operador, una
ventaja adicional es que la implementación del dispositivo de
resolución no está relacionada con estándares; es decir, el
S-CSCF (o cualquier otro solicitante original) envía
una consulta ENUM/DNS estándar al dispositivo de resolución y
recibe una respuesta ENUM/DNS estándar, por lo que el
S-CSCF no necesita estar al tanto de la operación
del dispositivo de resolución entre los mismos. Además, una ventaja
es que el operador puede, al menos en algún grado, controlar el
tráfico y dirigirlo a ciertas redes (por ejemplo, debido a los
costes) al ajustar la lista priorizada de forma apropiada.
Preferentemente, el dispositivo de resolución
real puede ser un servidor aparte conectado al
S-CSCF. En consecuencia, el servidor comprende,
como se ilustra en la Fig. 3, memoria MEM, una interfaz de usuario
UI, medios de entrada/salida I/O para disponer la transmisión de
datos con otros dispositivos, y una o más unidades centrales de
procesamiento CPU que comprenden al menos un procesador. La memoria
MEM incluye una porción no volátil para almacenar las aplicaciones
que controlan la unidad central de procesamiento CPU y otros datos
que van a ser almacenados y una porción volátil para ser utilizada
para un procesamiento temporal de datos. De forma alternativa, se
pueden implementar las funcionalidades del dispositivo de resolución
como una parte del S-CSCF.
En cualquier caso, las funcionalidades de la
invención están implementadas, preferentemente, en el servidor como
un programa información que, cuando se ejecutar en una unidad
central de procesamiento CPU, hace que el servidor implemente
procedimientos de la invención. Las funciones del programa de
ordenador SW pueden estar distribuidas a varios componentes aparte
de programa que se comunican entre sí. El software
informático puede estar almacenado en cualquier medio de memoria,
tal como el disco duro de un PC o en un disco
CD-ROM, del que se puede cargar en la memoria del
servidor. El software informático también puede cargarse a
través de una red, utilizando por ejemplo una pila de protocolos
TCP/IP.
Es evidente que la presente invención no está
limitada únicamente a las realizaciones presentadas anteriormente,
pero puede ser modificada dentro del alcance de las reivindicaciones
adjuntas.
Claims (15)
1. Un procedimiento de resolución de una
dirección de red de un terminal, estando asignado dicho terminal una
dirección SIP, comprendiendo el procedimiento:
- recibir una solicitud de resolución de una dirección relacionada con dicho terminal en una unidad (200) de encaminamiento de una red de telecomunicaciones, estando asociada dicha solicitud de resolución de dirección con la dirección SIP; caracterizado por
- remitir (202) la solicitud de resolución de dirección a una unidad (204) de resolución, comprendiendo la unidad (204) de resolución una lista priorizada de servidores de direcciones y/o bases de datos, determinando la lista priorizada el orden en el que la unidad de resolución envía las consultas (208) de direcciones a uno o más servidores de direcciones y/o bases de datos;
- enviar consultas (208) de direcciones a uno o más de dichos servidores de direcciones y/o bases (206, 210, 212, 214, 216) de datos en el orden determinado por dicha lista priorizada procedentes de dicha unidad de reso- lución;
- recibir, de cada uno de dichos uno o más servidores de direcciones y/o bases (206, 210, 212, 214, 216) de datos, la dirección de red del terminal o un mensaje de error que indica que no se encontró la dirección de red del terminal; y
- enviar una respuesta (218) a la solicitud de resolución de dirección de dicha unidad (204) de resolución a la unidad (200) de encaminamiento de la red de telecomunicaciones, incluyendo la respuesta bien la dirección de red del terminal o bien el mensaje de error.
\vskip1.000000\baselineskip
2. El procedimiento conforme a la reivindicación
1, caracterizado porque la lista priorizada comprende uno o
más de los siguientes servidores de direcciones y/o bases de
datos:
- -
- una base (206) de datos DNS/ENUM GRX/IPX;
- -
- una base (210) de datos de portabilidad de números móviles (MNP);
- -
- una base (212) de datos IR.21;
- -
- una base de datos de dominios de la red (214) de telecomunicaciones;
- -
- una base (216) de datos DNS/ENUM pública.
\vskip1.000000\baselineskip
3. El procedimiento conforme a la reivindicación
2, caracterizado porque
la base de datos DNS/ENUM GRX/IPX está colocada
en primer lugar en la lista priorizada.
\vskip1.000000\baselineskip
4. El procedimiento conforme a cualquiera de las
reivindicaciones precedentes, caracterizado porque
la solicitud de resolución de dirección es una
solicitud de INVITACIÓN SIP.
\vskip1.000000\baselineskip
5. El procedimiento conforme a cualquiera de las
reivindicaciones precedentes, caracterizado por
enviar, antes de enviar consultas de direcciones
a uno o más servidores de direcciones y/o bases de datos conforme a
la lista priorizada, una consulta de dirección a una base de datos
federada de la red de telecomunicaciones, incluyendo la base de
datos federada información de nivel global del dominio de
Internet incluida en la solicitud de resolución de
dirección.
6. El procedimiento conforme a cualquiera de las
reivindicaciones precedentes, caracterizado porque
como respuesta a la circunstancia de que ninguna
dirección de red del terminal se pudo solucionar por medio de
consultas de direcciones a dicho uno o más servidores de direcciones
y/o bases de datos,
enviar la consulta de dirección a un proxi IPX
(220) ubicado en una red IPX.
\newpage
7. El procedimiento conforme a cualquiera de las
reivindicaciones precedentes, caracterizado porque
como respuesta a la circunstancia de que ninguna
dirección de red del terminal se pudo solucionar por medio de
consultas de direcciones a dicho uno o más servidores de direcciones
y/o bases de datos,
enviar una solicitud MAP estándar a una red PSTN
(222).
\vskip1.000000\baselineskip
8. El procedimiento conforme a cualquiera de las
reivindicaciones precedentes, caracterizado porque
la red de telecomunicaciones está basada en una
arquitectura IMS; y
la unidad de encaminamiento es un
S-CSCF.
\vskip1.000000\baselineskip
9. Un servidor (204) de resolución de una
dirección de red de un terminal, estando asignada a dicho terminal
una dirección SIP, caracterizado porque
el servidor incluye una unidad (204) de
resolución que comprende una lista priorizada de servidores de
direcciones y/o bases de datos, determinando la lista priorizada el
orden en el que la unidad de resolución envía las consultas de
direcciones a uno o más servidores de direcciones y/o bases de
datos; estando dispuesto el servidor para
recibir una solicitud (202) de resolución de
dirección relacionada con dicho terminal desde una unidad (200) de
encaminamiento de una red de telecomunicaciones, estando asociada
dicha solicitud de resolución de dirección con la dirección
SIP;
enviar consultas (208) de direcciones a uno o
más de dichos servidores de direcciones y/o bases (206, 210, 212,
214, 216) de datos en el orden determinado por dicha lista
priorizada;
recibir, de cada uno de dichos uno o más
servidores de direcciones y/o bases (206, 210, 212, 214, 216) de
datos, la dirección de red del terminal o un mensaje de error que
indica que no se encontró la dirección de red del terminal; y
enviar una respuesta (218) a la solicitud de
resolución de dirección a la unidad (200) de encaminamiento de la
red de telecomunicaciones, incluyendo la respuesta bien la dirección
de red del terminal o bien el mensaje de error.
10. El servidor conforme a la reivindicación 9,
caracterizado porque
la lista priorizada comprende uno o más de los
siguientes servidores de direcciones y/o bases de datos:
- -
- una base (206) de datos DNS/ENUM GRX/IPX;
- -
- una base (210) de datos de portabilidad de números móviles (MNP);
- -
- una base (212) de datos IR.21;
- -
- una base de datos de dominios de la red (214) de telecomunicaciones;
- -
- una base (216) de datos DNS/ENUM pública.
\vskip1.000000\baselineskip
11. El servidor conforme a la reivindicación 10,
caracterizado porque
la base de datos DNS/ENUM GRX/IPX está colocada
en primer lugar en la lista priorizada.
\vskip1.000000\baselineskip
12. El servidor conforme a cualquiera de las
reivindicaciones 9 - 11, caracterizado porque
la solicitud de resolución de dirección es una
solicitud de INVITACIÓN SIP.
\vskip1.000000\baselineskip
13. El servidor conforme a cualquiera de las
reivindicaciones 9 - 12, caracterizado porque
el servidor está dispuesto para enviar, antes de
enviar las consultas de direcciones a uno o más servidores de
direcciones y/o bases de datos conforme a la lista priorizada, una
consulta de dirección a una base de datos federada de la red de
telecomunicaciones, incluyendo la base de datos federada información
de nivel global del dominio de Internet incluida en la
solicitud de resolución de dirección.
14. El servidor conforme a cualquiera de las
reivindicaciones 9 - 13, caracterizado porque
el servidor está conectado de forma funcional al
S-CSCF de una red de telecomunicaciones basada en
una arquitectura IMS.
15. Un producto de programa de ordenador,
almacenado en un medio legible por ordenador y ejecutable en un
dispositivo de procesamiento de datos, para resolución de una
dirección de red de un terminal, estando asignada a dicho terminal
una dirección SIP, caracterizado porque el producto de
programa de ordenador comprende:
- una sección de código de programa de ordenador para definir una lista priorizada de servidores de direcciones y/o bases de datos, determinando la lista priorizada el orden en el que la unidad de resolución envía las consultas de direcciones a uno o más servidores de direcciones y/o bases de datos;
- una sección de código de programa de ordenador para recibir una solicitud de resolución de dirección relacionada con dicho terminal desde una unidad de encaminamiento de una red de telecomunicaciones, estando asociada dicha solicitud de resolución de dirección con la dirección SIP;
- una sección de código de programa de ordenador para enviar consultas de direcciones a uno o más servidores de direcciones y/o bases de datos en el orden determinado por dicha lista priorizada;
- una sección de código de programa de ordenador para recibir, de cada uno de dichos uno o más servidores de direcciones y/o bases de datos, la dirección de red del terminal o un mensaje de error que indica que no se encontró la dirección de red del terminal; y
- una sección de código de programa de ordenador para enviar una respuesta a la solicitud de resolución de dirección a la unidad de encaminamiento de la red de telecomunicaciones, incluyendo la respuesta bien la dirección de red del terminal o bien el mensaje de error.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FI20060821 | 2006-09-14 | ||
| FI20060821A FI120227B (fi) | 2006-09-14 | 2006-09-14 | Päätelaitteen verkko-osoitteen selvittäminen |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2341386T3 true ES2341386T3 (es) | 2010-06-18 |
Family
ID=37067148
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES07823124T Active ES2341386T3 (es) | 2006-09-14 | 2007-09-13 | Resolucion de una direccion de red de un terminal. |
Country Status (7)
| Country | Link |
|---|---|
| EP (1) | EP2062416B1 (es) |
| AT (1) | ATE461582T1 (es) |
| DE (1) | DE602007005384D1 (es) |
| DK (1) | DK2062416T3 (es) |
| ES (1) | ES2341386T3 (es) |
| FI (1) | FI120227B (es) |
| WO (1) | WO2008031927A1 (es) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7885253B2 (en) * | 2008-09-30 | 2011-02-08 | Avaya Inc. | Synchronization of session-initiation-protocol proxy databases |
| US8300644B2 (en) | 2008-09-30 | 2012-10-30 | Avaya Inc. | Coordination of user information across session initiation protocol-based proxy servers |
| EP2461617B1 (en) * | 2010-12-02 | 2018-04-25 | Telia Company AB | Method, system and apparatus for communication |
| US10033723B2 (en) | 2013-12-18 | 2018-07-24 | At&T Intellectual Property I, L.P. | Methods, devices, and computer readable storage devices for authenticating devices having non-SIM based clients |
| US10979462B2 (en) * | 2015-01-16 | 2021-04-13 | Ibasis, Inc. | Identifying voice over LTE users |
| US10404864B2 (en) | 2016-06-15 | 2019-09-03 | At&T Intellectual Property I, L.P. | Method and apparatus for inter-carrier communications |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6917612B2 (en) * | 2000-09-01 | 2005-07-12 | Telefonaktiebolaged L M Ericsson | System and method for address resolution in internet protocol (IP)-based networks |
| US6931453B2 (en) * | 2003-01-03 | 2005-08-16 | Nokia Corporation | Method and apparatus for resolving protocol-agnostic schemes in an internet protocol multimedia subsystem |
-
2006
- 2006-09-14 FI FI20060821A patent/FI120227B/fi not_active IP Right Cessation
-
2007
- 2007-09-13 DE DE602007005384T patent/DE602007005384D1/de active Active
- 2007-09-13 AT AT07823124T patent/ATE461582T1/de not_active IP Right Cessation
- 2007-09-13 ES ES07823124T patent/ES2341386T3/es active Active
- 2007-09-13 WO PCT/FI2007/050487 patent/WO2008031927A1/en active Application Filing
- 2007-09-13 DK DK07823124.8T patent/DK2062416T3/da active
- 2007-09-13 EP EP07823124A patent/EP2062416B1/en not_active Not-in-force
Also Published As
| Publication number | Publication date |
|---|---|
| FI20060821A0 (fi) | 2006-09-14 |
| EP2062416A1 (en) | 2009-05-27 |
| FI20060821A (fi) | 2008-03-15 |
| EP2062416B1 (en) | 2010-03-17 |
| DE602007005384D1 (es) | 2010-04-29 |
| DK2062416T3 (da) | 2010-06-21 |
| WO2008031927A1 (en) | 2008-03-20 |
| FI120227B (fi) | 2009-07-31 |
| ATE461582T1 (de) | 2010-04-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9021014B2 (en) | Methods, systems, and computer readable media for providing home subscriber server (HSS) proxy | |
| US9860737B2 (en) | Communication system and method | |
| US8015293B2 (en) | Methods, systems, and computer program products for clustering and communicating between internet protocol multimedia subsystem (IMS) entities | |
| ES2360036T3 (es) | Presencia con información de localización espacial. | |
| US7796578B2 (en) | Resolution of IP addresses associated with a telephone number utilizing query flags | |
| ES2330994T3 (es) | Equipo de usuario, procedimiento y sistema de comunicacion para establecer una conexion con un elemento servicor de red. | |
| AU2007204558B2 (en) | System and method for routing an incoming call to a proper domain in a network environment including IMS | |
| EP3054644B1 (en) | Voice session termination for messaging clients in IMS | |
| ES2765676T3 (es) | Encaminamiento basado en localización de llamadas de emergencia VoIP | |
| US20140355520A1 (en) | System and method for visiting subscriber server in ims core networks | |
| US7054615B2 (en) | System and method for providing enhanced user privacy in a mobile communications network | |
| US20110195710A1 (en) | Methods, systems, and computer readable media for dynamic subscriber profile adaptation | |
| ES2341386T3 (es) | Resolucion de una direccion de red de un terminal. | |
| ES2269830T3 (es) | Sistema de comunicacion. | |
| EP2461617B1 (en) | Method, system and apparatus for communication | |
| ES2518994T3 (es) | Tratamiento de identidades de usuario en el Subsistema Multimedia IP | |
| US20090098853A1 (en) | Method, apparatus and computer program product for provision of grouped identity information | |
| US8520664B2 (en) | Multi-vendor IMS architecture | |
| RU2473184C2 (ru) | Способ и устройство для абонентской базы данных | |
| KR20100036048A (ko) | 이종 망간의 로밍 서비스를 제공 방법 및 이를 위한 시스템 | |
| EP1994708B1 (en) | Message routing in the ip multimedia subsystem | |
| ES2409457B1 (es) | Método y sistema para la mejora del enrutamiento en operadores de comunicaciones proveedores de servicios multimedia sobre redes ims | |
| ES2374058T3 (es) | Subsistema multimedia ip (ims) y método para enviar un mensaje http a través de un ims. | |
| ES2624232T3 (es) | Método, aparato, sistema y producto de programa informático relacionado para gestión de traspaso | |
| US8811282B2 (en) | Call delivery to an IMS network for a mobile directory number homed in a 2G wireless network |