ES2564423T3 - Técnica para proporcionar interoperabilidad entre diferentes dominios de protocolo - Google Patents

Técnica para proporcionar interoperabilidad entre diferentes dominios de protocolo Download PDF

Info

Publication number
ES2564423T3
ES2564423T3 ES05820039.5T ES05820039T ES2564423T3 ES 2564423 T3 ES2564423 T3 ES 2564423T3 ES 05820039 T ES05820039 T ES 05820039T ES 2564423 T3 ES2564423 T3 ES 2564423T3
Authority
ES
Spain
Prior art keywords
ims
session
service
message
domain
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
Application number
ES05820039.5T
Other languages
English (en)
Inventor
Roman Levenshteyn
Ioannis Fikouras
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2564423T3 publication Critical patent/ES2564423T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • 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/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un método de provisión de interoperabilidad entre un dominio de subsistema multimedia de protocolo de Internet (IMS) (10) y un domino no IMS (20), que comprende los pasos de: recibir (S1) en una capa de servicio un mensaje de invocación de servicio (101) desde el dominio no IMS; analizar (S2) el mensaje para identificar (S3) el mensaje (101) como una solicitud para invocar un servicio dentro del dominio IMS; convertir (S4) en una capa de control de sesión elementos de protocolo de control de sesión no IMS relacionados con el mensaje (101) en elementos de protocolo relacionados con control de sesión IMS; enviar (S5) uno o más mensajes (107) hacia el dominio IMS para proporcionar una sesión de control IMS en el dominio IMS en base a los elementos de protocolo relacionados con control de sesión IMS; y reenviar en la capa de servicio el mensaje de invocación de servicio (107) usando la sesión de control IMS; caracterizado por que además comprende los pasos de: analizar el mensaje (101, 107) recibido desde el dominio no IMS y/o desde el dominio IMS; determinar un estado de la sesión con el servicio en el dominio IMS en base al mensaje analizado; y almacenar el estado de la sesión.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Tecnica para proporcionar interoperabilidad entre diferentes dominios de protocolo Campo de la Invencion
La invencion se refiere a una tecnica para proporcionar interoperabilidad entre diferentes dominios de protocolo. La tecnica se adapta particularmente para uso en conexion con el dominio de subsistema multimedia de protocolo de Internet (IMS). A este respecto, la presente invencion se disena para proporcionar interoperabilidad con un protocolo de control de sesion IMS.
Antecedentes de la Invencion
El IMS es una arquitectura de red de proxima generation (NGN) estandarizada para operadores de red que proporciona servicios multimedia moviles y fijos. Usa una implementation estandarizada del Proyecto de Cooperation de 3a Generacion (3GPP) de SIP y se ejecuta sobre el protocolo de Internet (IP) estandar. Tambien se soportan los sistemas telefonicos existentes (tanto de paquetes conmutados como de circuitos conmutados). IMS usa protocolos IP estandar abiertos como se define por el Grupo de Trabajo de Ingenierla de Internet (IETF). De este modo, se puede establecer una sesion multimedia por ejemplo entre dos usuarios IMS, entre un usuario IMS y un usuario en Internet o entre dos usuarios en Internet usando exactamente los mismos protocolos. IMS funde los mundos de Internet y celular usando tecnologlas celulares para proporcionar acceso ubicuo y tecnologlas de Internet para proporcionar servicios atractivos.
El IMS comprende tres componentes principales: la funcion de control de sesion de llamada de servicio (S-CSCF) en una capa de control y el servidor local de abonado (HSS) as! como un servidor de aplicaciones (AS) del protocolo de inicio de sesiones (SIP) en una capa de aplicaciones.
El protocolo SIP es una tecnologla de control central de IMS. Se usa para controlar sesiones multimedia combinando por ejemplo flujos de voz y datos. Esencialmente, SIP es un protocolo basado en texto para sesiones de comunicacion entre las partes. En particular, SIP se usa para el establecimiento, control y finalization de sesiones de comunicacion entre aplicaciones basadas en red y tambien para el control de canales de medios entre esas aplicaciones. Despues de que se establece una sesion, se pueden usar otros protocolos para comunicacion entre aplicaciones. De esta manera, las funciones principales de SIP son control de sesion, direccionamiento y gestion de movilidad en el nivel de servicio.
IMS proporciona un monton de funciones comunes usadas por redes moviles, tales como AAA (autenticacion, autorizacion y contabilidad), tarificacion, control de acceso y HSS (es decir, bases de datos de perfil de usuario). Estas funciones de IMS se entienden que se usan por aplicaciones convergentes de una forma uniforme, de manera que no hay necesidad de tener mecanismos separados aplicados por ejemplo a comunicaciones de voz y de datos.
En paralelo al dominio IMS, se ha desarrollado el concepto de Servicios Web (WS) de Lenguaje de Marcas Extensible (XML). WS de XML son una tecnologla relativamente nueva para la creation de sistemas distribuidos, altamente interoperables. WS de XML se basan en estandares basados en XML, como Protocolo de Acceso de Objetos Simple (SOAP), Lenguaje de Definition de Servicios Web (WSDL) y Description, Descubrimiento e Integration Universal (UDDI). Los Servicios Web son una plataforma transversal interoperable e independiente del lenguaje de programacion. Han llegado a ser un medio popular de desarrollo e integracion de sistemas de sistemas de empresa y aplicaciones de red. Debido a su flexibilidad y un diseno que esta mas alineado con redes IT, las arquitecturas basadas en Servicios Web, por ejemplo, Arquitecturas Orientadas a Servicios (SOA), estan emergiendo rapidamente y es probable que sean adoptadas en diseno de red de comunicacion movil.
La mayorla de Servicios Web no tienen estado, lo cual significa que cada invocation del Servicio Web deberla contener toda la information que necesita procesar una solicitud, dado que el procesamiento depende solamente de estos datos. Este diseno simplifica extremadamente la implementacion de WS. Recientemente, no obstante, muchos investigadores y profesionales en el area de WS se han dado cuenta de que tambien hay una necesidad de Servicios Web con estado. Tales servicios con estado son particularmente importantes para transacciones que implican varias invocaciones de servicio. Son igualmente importantes donde se requiera una correlation entre mensajes, por ejemplo, banca electronica y reserva de billetes. Varias especificaciones de WS que abordan estos asuntos, por ejemplo, Contexto de WS, Direccionamiento de WS y Estructura de Recursos de WS, se han presentado a estandarizacion, pero la mayorla de estas simplemente complementan cabeceras de SOAP de WS a traves de cabeceras de informacion de sesion.
La arquitectura de IMS define que todas las invocaciones de servicio entrantes sean llevadas a cabo sobre sesiones SIP. Los nodos de IMS, por ejemplo, CSCF-I y la CSCF-P, son servidores SIP que manejan mensajes SIP entrantes. No obstante, incluso hoy en dla existen muchos servicios basados en no SIP en el dominio de operador y estos servicios a menudo usan protocolos y tecnologlas no SIP (por ejemplo, Servicios Web, pero tambien J2EE, .NET, etc.).
5
10
15
20
25
30
35
40
45
50
55
60
65
Proporcionar acceso para usuarios externos a servicios, en particular servicios no SIP, en el dominio IMS no es posible generalmente debido a que las aplicaciones de consumidor de servicio no SIP de terceras partes externas tlpicamente no son conscientes del hecho de que el servicio invocado esta situado dentro del dominio IMS y tales aplicaciones de consumidor externas tlpicamente no soportan SIP. Por lo tanto, un consumidor de servicio no SIP es incapaz de acceder al servicio en cuestion dentro del dominio IMS, lo que reduce extremadamente la disponibilidad y por lo tanto el valor del servicio.
SIP y WS abordan problemas similares, pero cada uno tiene sus propias soluciones para gestion de sesion. En otras palabras, los planteamientos usados para gestion de sesion por SIP y WS son independientes uno de otro. Como resultado, los Servicios Web desplegados dentro del dominio IMS requieren su propia infraestructura de WS incompatible con IMS, incluyendo autenticacion, contabilidad, tarificacion y otra funcionalidad IMS. Ademas, las invocaciones de WS se ejecutan en base a URL (localizadores de recursos unicos) que requieren un conocimiento preciso de la direccion de red actual del servicio (por ejemplo, el numero de IP, nombre de DNS, etc.). Esto significa que los usuarios no pueden invocar servicios alojados en plataformas moviles (por ejemplo, terminales moviles y nodos de red que cambian regularmente su URL) hasta que se conoce su URL actual.
No obstante, las cabeceras de invocacion SOAP de Servicios Web se complementan a traves de cabeceras de information de sesion. Esto puede conducir a mensajes SOAP grandes comparados con el tamano de la carga util. Tales cabeceras se envlan con cada mensaje SOAP y de esta manera consumen mas ancho de banda que los Servicios Web sin sesion. El aumento de trafico puede ser un problema especial en los entornos moviles por el aire, donde podrla introducir una carga de red mayor y conducir a latencias mayores. Aunque se pueden emplear esquemas de compresion para comprimir y descomprimir mensajes SOAP para abordar este problema, estos se han mostrado que son muy intensivos en recursos y consumen tiempo, incluso con terminales moviles de alta gama.
Por consiguiente, hay una necesidad de una tecnica para proporcionar un aumento de interoperabilidad entre servicios situados dentro del dominio IMS y componentes de cliente situados fuera del dominio IMS.
La publication del IEEE titulada “THE IMS PLAYGROUND @ FOKUS - AN OPEN TESTBED FOR NEXT GENERATION NETWORK MULTIMEDIA SERVICES” de Magedanz, T. et al., introduce el estandar IMS y proporciona una vision general del Campo de juego de IMS Abierto a FOKUS. Otro documento titulado “The Convergence of Circuit and Packet Core Networks” de Ejzak et al., describe una arquitectura que unifica los dominios de circuito e IMS proporcionando un unico plano de control para ambos.
Sumario de la Invention
Segun un aspecto, la presente invencion proporciona un metodo segun la revindication del metodo independiente 1 de provision de interoperabilidad entre un dominio de subsistema multimedia de protocolo Internet (IMS) y un dominio no IMS. El metodo comprende, entre otros, los pasos de recibir en una capa de servicio un mensaje de invocacion de servicio desde un dominio no IMS, analizando el mensaje para identificar el mensaje como una solicitud para invocar un servicio dentro del dominio IMS, convirtiendo en una capa de control de sesion elementos de protocolo de control de sesion no IMS relacionados con el mensaje en elementos de protocolo relacionados con control de sesion IMS y enviando uno o mas mensajes hacia el dominio IMS para proporcionar una sesion de control IMS en el dominio IMS en base a los elementos de protocolo relacionados con control de sesion IMS.
En un ejemplo, el paso de conversion se puede basar en un esquema de correspondencia que asocia elementos de protocolo de control de sesion no IMS individuales con elementos de protocolo relacionados con control de sesion IMS individuales. Los elementos de protocolo incluyen tipos de mensajes especlficos de protocolo (tales como mensajes de invocacion de servicio), partes de mensajes (tales como cabeceras) y campos de mensaje (tales como campos de cabecera que especifican direcciones particulares).
El metodo tambien puede incluir el paso de reenviar en la capa de servicio el mensaje de invocacion de servicio usando la sesion de control IMS. El metodo ademas puede incluir los pasos de recibir al menos un mensaje adicional desde el dominio no IMS relacionado con el servicio invocado dentro del dominio IMS y reenviar en la capa de servicio el mensaje de servicio usando la sesion de control IMS. Tambien se puede usar aqul un esquema de correspondencia para asociar un solicitante de servicio particular (por ejemplo, una aplicacion o un componente de red fuera del dominio IMS) con una o mas sesiones solicitadas (y/o en marcha) dentro del dominio IMS.
El metodo de la invencion puede incluir ademas los pasos de recibir un mensaje desde el dominio IMS durante la sesion, convirtiendo los elementos de protocolo relacionados con control de sesion IMS relacionados con el mensaje del dominio IMS en elementos de protocolo de control de sesion no IMS, generando un mensaje no IMS en base a los elementos de protocolo de control de sesion no IMS y enviando el mensaje no IMS durante la sesion hacia el dominio no IMS.
En una variante de la invencion, el servicio dentro del dominio IMS es un servicio basado en protocolo IMS. Por ejemplo, el servicio en el dominio IMS podrla ser una funcion de soporte de IMS que puede incluir una o mas de las siguientes funciones: autenticacion, autorizacion, contabilidad (por ejemplo, AAA), tarificacion, control de acceso y HSS. Aqul, el protocolo de control de sesion IMS puede ser el protocolo DIAMETER que proporciona por ejemplo
5
10
15
20
25
30
35
40
45
50
55
60
65
information de contabilidad para el servicio. El servicio en si mismo se puede proporcionar desde dentro o desde fuera del dominio IMS.
En otra variante, el servicio en el dominio IMS es una aplicacion basada en protocolo no IMS (por ejemplo, un servicio accesible mediante programacion tal como una aplicacion basada en Servicios Web operada desde dentro del dominio IMS). Aqul, el protocolo de control de sesion IMS puede ser SIP que controla la provision (por ejemplo, establecimiento y/o gestion general) de la sesion de servicio IMS.
Los elementos de protocolo de control de sesion no IMS preferiblemente comprenden cabeceras de un protocolo de control de sesion no IMS y los elementos de protocolo relacionados con control de sesion IMS preferiblemente comprende cabeceras tales como cabeceras SIP. A modo de ejemplo, el servicio basado en protocolo no IMS puede emplear un protocolo de mensajerla basado en Lenguaje de Marcas (ML), tal como Servicios Web de XML.
El metodo ademas incluye los pasos de analizar el mensaje recibido desde el dominio no IMS y/o desde el dominio IMS, determinando un estado de la sesion con el servicio en el dominio IMS en base al mensaje analizado y almacenar el estado de la sesion. Almacenar el estado de una sesion particular facilita la correspondencia entre servicios individuales dentro del dominio IMS y las sesiones individuales (que se extienden potencialmente en el dominio no IMS).
Segun un aspecto adicional, se puede comprobar (por ejemplo, en respuesta a la reception de un mensaje desde el dominio no IMS) si esta en marcha una sesion con un servicio en el dominio IMS y, si no hay ninguna sesion en marcha, se puede establecer una nueva sesion bajo un protocolo de control de sesion IMS tal como SIP. Preferiblemente, los mensajes no IMS se autentican anterior a establecer la sesion de control en el dominio IMS. La autenticacion se puede realizar analizando una direction especificada en un mensaje no IMS.
En una variante, el metodo incluye ademas los pasos de emplear un esquema de direccionamiento uniforme usando direccionamiento SIP para la invocation de servicios fijos y/o moviles. De este modo, cuando el servicio a ser invocado reside en una plataforma movil dentro del dominio IMS, el metodo ademas puede comprender el paso de definir un identificador de recursos unico (URI) de SIP para invocation dinamica del servicio en el dominio IMS, con independencia de un localizador de recursos unico (URL) actual para la plataforma movil.
De esta manera, un concepto adicional que puede operar independientemente de la conversion de elementos de protocolo descrita anteriormente es un metodo de direccionamiento e invocation de servicios fijos y moviles que usa un esquema de direccionamiento uniforme por medio de direccionamiento SIP, que comprende los pasos de definir el uso de un URI de SIP para invocation dinamica de servicios moviles con independencia de su URL actual (por ejemplo, definiendo una extension para Direccionamiento de WS) y/o definiendo el direccionamiento fijo de servicios usando un URL de SIP. En lugar de SIP, se podrlan usar tambien otros protocolos de control de sesion IMS para propositos de direccionamiento e identification.
Segun otro aspecto, la presente invention proporciona un producto de programa de ordenador que comprende partes de codigo de programa para realizar los pasos del metodo cuando el producto de programa de ordenador se ejecuta en uno o mas ordenadores o sistemas informaticos. El producto de programa de ordenador se puede almacenar en un medio de grabacion legible por ordenador.
Segun un aspecto adicional, la presente invention proporciona un procesador de ordenador y una memoria acoplada al procesador, en donde la memoria se codifica con uno o mas programas que pueden realizar pasos para proporcionar interoperabilidad entre un dominio IMS y un dominio no IMS segun el metodo de la invention descrito anteriormente.
Aun segun un aspecto adicional de la invention, se proporciona un dispositivo de correspondencia segun la revindication del aparato independiente adjunta a la misma para proporcionar interoperabilidad entre un dominio de subsistema multimedia de protocolo de Internet (IMS) y un dominio no IMS. El dispositivo de correspondencia comprende, entre otras cosas, una unidad de analisis para analizar mensajes de invocation de servicio entrantes recibidos en una capa de servicio desde el dominio no IMS, para identificar si uno de los mensajes de invocation de servicio es una invocation de un servicio dentro del dominio IMS, una unidad de conversion para convertir en una capa de control de sesion elementos de protocolo de control de sesion no IMS relacionados con uno de los mensajes en los elementos de protocolo relacionados con control de sesion IMS y una unidad de mensajerla para generar uno o mas mensajes para proporcionar una sesion de control IMS en el dominio IMS en base a los elementos de protocolo relacionados con control de sesion IMS.
El dispositivo de correspondencia de la invencion se puede implementar como una pasarela entre el dominio IMS y el dominio no IMS. Alternativamente, el dispositivo de correspondencia se puede integrar en una pila de protocolo de un componente de red en el dominio no IMS. Tambien se pueden usar otras implementaciones.
5
10
15
20
25
30
35
40
45
50
55
60
65
Breve descripcion de los dibujos
Las realizaciones particulares de la presente invencion se describiran ahora con referencia a los dibujos anexos, en los que numeros de referencia iguales identifican rasgos iguales y en los cuales:
la Figura 1 es un diagrama de flujo esquematico que ilustra una realization del metodo segun la presente invencion;
la Figura 2 es una ilustracion esquematica de una realizacion del dispositivo de correspondencia segun la
presente invencion que opera para convertir mensajes recibidos desde el dominio no IMS;
la Figura 3 es una ilustracion esquematica de una realizacion del dispositivo de correspondencia segun la
presente invencion que opera para convertir mensajes recibidos desde el dominio IMS;
la Figura 4 ilustra una realizacion segun la presente invencion incorporada como una pasarela SOAP sobre
SIP para acceder a Servicios Web en el dominio IMS;
la Figura 5 ilustra una realizacion segun la presente invencion incorporada como un tiempo de diseno de
correspondencia de sesion SOAP a SIP para acceder a Servicios Web en el dominio IMS;
la Figura 6 ilustra una realizacion segun la presente invencion incorporada como una correspondencia SOAP
sobre SIP para acceder transparentemente a facilidades IMS para gestion de usuario/servicio; y
la Figura 7 ilustra una realizacion segun la invencion que usa URI de SIP para implementar direccionamiento
de servicios moviles.
Descripcion detallada de la Invencion
En la siguiente descripcion, con propositos de explication y no de limitation, se exponen detalles especlficos, tales como secuencias de pasos particulares, estandares de protocolo y diversas configuraciones de dispositivos a fin de proporcionar una comprension minuciosa de la presente invencion. Se entendera que la presente invencion se puede poner en practica en otras realizaciones que se apartan de estos detalles especlficos.
Ademas, los expertos en la tecnica apreciaran que las funciones explicadas en la presente memoria mas adelante se pueden implementar usando software que funciona en conjunto con un microprocesador u ordenador de proposito general programado y/o usando un circuito integrado de aplicaciones especlficas (ASIC).
La tecnica para proporcionar interoperabilidad entre diferentes dominios de protocolo segun la presente invencion se describira en primer lugar con referencia a las Figuras 1 y 2. La Figura 1 ilustra esquematicamente una realizacion del metodo para proporcionar interoperabilidad entre un dominio IMS y un dominio no IMS. De la misma manera, la Figura 2 ilustra esquematicamente una realizacion de un dispositivo de correspondencia 100, que opera para proporcionar esta interoperabilidad entre el dominio IMS y el dominio no IMS.
Con referencia a ambas de las Figura 1 y 2, el primer paso S1 del metodo implica recibir en una capa de servicio (o aplicacion) un mensaje de invocation de servicio 101 desde el dominio no iMs. Este mensaje 101 se recibe por el dispositivo de correspondencia 100. El segundo paso S2 del metodo implica analizar el mensaje recibido desde el dominio no IMS. En otras palabras, el mensaje 101 recibido por el dispositivo de correspondencia 100 se somete a analisis en una unidad de analisis 102 del dispositivo de correspondencia. El tercer paso S3 implica identificar el mensaje de invocacion de servicio recibido desde el dominio no IMS como una solicitud para invocar un servicio dentro del dominio IMS (comparado, por ejemplo, con un servicio que va a ser proporcionado desde fuera del dominio IMS). Este servicio puede ser, por ejemplo, una funcion de soporte IMS, tal como AAA o HSS o un servicio no IMS proporcionado desde dentro del dominio IMS. El paso de identificar la naturaleza del mensaje 101 recibido por el dispositivo de correspondencia 100 se lleva a cabo tlpicamente por la unidad de analisis 102.
Despues de que el mensaje 101 recibido desde el dominio no IMS se ha identificado como una invocacion de un servicio dentro del dominio IMS, el metodo incluye el paso adicional S4 de conversion de elementos de protocolo de control de sesion no IMS relacionados con el mensaje de invocacion de servicio en elementos de protocolo relacionados con control de sesion IMS. A este respecto, el metodo de la invencion proporciona una conversion o correspondencia de, por ejemplo, cabeceras de protocolo de control de sesion no IMS en cabeceras de protocolo de un protocolo de control de sesion IMS, tal como SIP. Para este fin, el dispositivo de correspondencia 100 incluye una unidad de conversion 104 para emprender esta conversion de elementos de protocolo no IMS en elementos de protocolo IMS.
La conversion se puede soportar a traves de information contenida en campos de mensajes de invocacion entrantes. Tal informacion se puede recopilar desde: la direction IP del remitente, posiblemente tambien su direction DNS, campos especlficos de servicio tales como los mensajes de Servicios Web (por ejemplo, SOAP, Contexto de WS) e informacion de autenticacion en forma de credenciales incluidas en el mensaje.
Por ejemplo en el caso de CORBA, los campos de request_id y service_contexts se pueden usar para derivar informacion relacionada con la transaction o sesion, mientras que campos tales como requesting_principal y operation se pueden usar para derivar informacion relacionada con los campos Desde y A de SIP. En general este tipo de informacion se puede convertir por una correspondencia a campos de establecimiento de sesion SIP tales como Desde, A, Permitir, Soportado y Contacto.
5
10
15
20
25
30
35
40
45
50
55
60
65
El metodo entonces incluye el paso adicional S5 de generacion de un mensaje saliente 107 en contexto con proporcionar una sesion de control IMS (por ejemplo, establecer una sesion de control o controlar una sesion de control establecida) en el dominio IMS en base a los elementos de protocolo relacionados con control de sesion IMS. El establecimiento de la sesion puede implicar el intercambio de varios mensajes entre el dispositivo de correspondencia 100 y el servicio. Por consiguiente, el dispositivo de correspondencia puede asumir el papel de un socio de comunicacion durante el establecimiento de sesion en el dominio IMS.
Naturalmente, ademas de, por ejemplo, un mensaje inicial desde el dominio no IMS invocando el servicio dentro del dominio IMS, se pueden recibir adicionalmente uno o mas mensajes adicionales 101 desde el dominio no IMS. A este respecto, la unidad de mensajerla 106 del dispositivo de correspondencia 100 esta adaptada para generar un mensaje IMS saliente correspondiente para controlar la sesion una vez que se ha establecido.
De manera similar, con referencia ahora a la Figura 3, tambien puede ser el caso de que se reciba un mensaje 107 desde el dominio IMS durante la sesion que se ha establecido para el servicio invocado. Un mensaje 107 recibido desde el dominio IMS se maneja por el dispositivo de correspondencia 100 de una manera reclproca. Especlficamente, los elementos de protocolo relacionados con control de sesion IMS, tales como cabeceras SIP, contenidas en ese mensaje se pueden convertir por la unidad de conversion 104 en elementos de protocolo de control de sesion no IMS y se puede generar un mensaje no IMS correspondiente por la unidad de mensajerla 106. El dispositivo de correspondencia 100 entonces envla este mensaje no IMS 101 al dominio no IMS en el curso de la sesion establecida o a partir de entonces. Se apreciara que, en las Figura 2 y 3, el numero de referencia 101 identifica un mensaje no IMS y el numero de referencia 107 identifica uno IMS.
Las siguientes realizaciones proporcionan planteamientos genericos para permitir interoperabilidad entre servicios no SIP y SIP orientados a sesion. Ademas, las realizaciones tambien permiten la provision de funcionalidad de sesion a tecnologlas de servicio no orientadas a sesion (por ejemplo, Servicios Web).
La correspondencia entre servicios no SIP y sesiones SIP se consigue por una entidad (por ejemplo, el dispositivo de correspondencia 100 mostrado en las Figura 2 y 3 o un dispositivo diferente) que almacena el estado de la sesion particular analizando sintacticamente mensajes entrantes (posiblemente en un numero de diferentes protocolos). Este conocimiento se usa entonces para generar mensajes salientes adecuados (de nuevo posiblemente en un numero de diferentes protocolos posibles).
Las aplicaciones no SIP (desde fuera el dominio IMS) que son servicios no basados en sesion e invocados desplegados dentro del dominio IMS no son conscientes de SIP y, por lo tanto, no son capaces de establecer y mantener sesiones como se requiere por IMS. Por esta razon, la implementacion del dispositivo de correspondencia de sesion se ocupa de la iniciacion y gestion de sesiones para las aplicaciones en cuestion, como se requiere por la parte consciente de sesion de la transaction. Esto puede requerir que todos los mensajes entre el servicio invocador y el invocado sean encaminados a traves del dispositivo de correspondencia.
Para lograr esto, el operador puede encaminar todo el trafico entrante relacionado con servicios IMS disponibles publicamente a traves del dispositivo de correspondencia (por ejemplo, en IP o niveles mas altos). Por ejemplo, los servicios en el dominio IMS se podrlan exponer a traves de un URL o cualquier otro mecanismo de direccionamiento alojado en el dispositivo de correspondencia. El operador puede publicar este URL a partes externas para propositos de direccionamiento.
Por el bien de la claridad, las realizaciones usadas para ilustrar el planteamiento tecnico suponen que el servidor de aplicaciones que aloja servicios no SIP ejemplares dentro del dominio IMS contiene tanto pilas SIP como no SIP (por ejemplo, WS, J2EE, CORBA, etc.) adecuadas al servicio que se invoca. Incluso aunque otras configuraciones posibles puedan implicar diferentes pilas de protocolo desplegadas en diferentes configuraciones de nodos, el planteamiento tecnico general sigue siendo el mismo.
A continuation, se describira una realization de un mecanismo de correspondencia de sesion con referencia a una aplicacion no SIP A (que se ejecuta por ejemplo sobre un terminal de usuario capaz de WS situado fuera del dominio IMS) que invoca un servicio B dentro del dominio IMS. La aplicacion no SIP actua de esta manera como un cliente con respecto al servicio IMS B.
La correspondencia de sesion se puede conseguir con los siguientes pasos:
1. Las solicitudes entrantes desde aplicaciones no SIP se pueden autenticar en base a un numero de mecanismos que se describen mas adelante en mas detalle.
2. En base a la autenticacion de la aplicacion no SIP A que invoca el servicio IMS B, el dispositivo de correspondencia 100 comprueba si ya tiene conocimiento de una transaccion de capa de servicio en marcha (que corresponde a una sesion particular en la capa de control de sesion en el dominio IMS) entre la aplicacion no SIP A y el servicio IMS B. Para este fin, se puede consultar una tabla de correspondencia que puede enumerar una pluralidad de sesiones establecidas previamente para la aplicacion no SIP A y/o cualquier otra aplicacion no SIP A'.
5
10
15
20
3. Si no hay ninguna transaccion en marcha entre la aplicacion no SIP A y el servicio IMS B, se inicializa una nueva sesion SIP. Aqui, el dispositivo de correspondencia 100 juega el papel del socio de comunicacion en la sesion SIP establecida con el servicio IMS B.
a. En caso de que la aplicacion no SIP A no sea consciente de la sesion, el dispositivo 100 establece una nueva sesion sin tener en consideracion adicional las capacidades de la aplicacion no SIP A.
b. En caso de que la aplicacion no SIP A sea consciente de la sesion, el dispositivo 100 establecera la nueva sesion segun las capacidades de sesion de la aplicacion no SIP A (por ejemplo, Contexto de WS, Direccionamiento de WS, Cabeceras, etc.). El primer ejemplo siguiente ilustra la invocacion de servicio creada por el cliente de WS A usando la especificacion de Contexto de WS para gestion de sesion de WS. El segundo ejemplo ilustra como el dispositivo de correspondencia 100 establece una nueva sesion SIP con el servicio IMS B, usando la information de sesion recopilada a partir de la correspondencia del mensaje SOAP interceptado por el dispositivo de correspondencia 100. Esta configuration implica que el servicio B contiene tanto pilas SIP como WS. Otras configuraciones posibles podrian implicar diferentes pilas de protocolo desplegadas en diferentes nodos.
Un ejemplo de un mensaje de invocacion de servicio basado en XML que especifica una sesion de Contexto de WS se da mas adelante:
<soap: Envelope xm Ins :soap="http: /,/vwvw.w3.oj,g/2002/06/soctp-enveiope">
<soap:Header>
<context xmlns="
http://dDC5.oa&]s-apen,org/w5caf/20Q4/09/w5Cfc<" timeout ^"lOO* xm I ns: wsdl *='"httpV/schemas.xml&™p,.org/1wsdl/'r xin Ins: soa pbi n d=http ;//sc hemas .xmlsoap. org/wsdi/ soa p/ soap; m u stUndersta nd1" >
<Ooolsxt-id entifier >
http [//services .operator,comAwscaf/Z0D4/09'/wsd3{/abcdef;012345 </context-fdent]fier>
<type>

http://services.oj>sratDr.com/w5caf/2004/09/wsctx/oontffi(t/mirhsetvlce
</type>
</context>
</soap:Header>
<soap:Bcdy>
<!-- Application Payload —>
<^soap:Body>
</soap:Envdope>
El dispositivo de correspondencia 100 convierte los elementos no SIP incluidos en el mensaje de invocacion de servicio anterior en un mensaje de establecimiento de sesion SIP que especifica la informacion de sesion a partir de la sesion de Contexto de WS como sigue:
INVITE sipiiservice
l@operator.com SIP/2.0
Via: SIP/2.0 ATS server.operator.com: 5051 ;branch<=z9hG4l&K741tf9
Max-Forwards: 70
FVom: SESSION 1 <5ips:apsoapgw@operat)0r.com>; tag=1234567 To: SIPAS <slps:
servicel@operator.com>
Call-ID:
l2345601@operatOr.com
5
10
CSeq: 1 INVITE
Contact: <s1ps:
sipsoapgw@operator.com>
Allow: INVITE, ACK, CAM CEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
v=0
o=servtcebroker 2890344526 2890842807 IN IP4 asb, operator .com s-Ccmference Service t^0 0
m-audio 5004 RTP/AVP O c=IN IP4 131.150.1.112 a=rtpmap:0 FCMU/8C0Q
m=message 49172 IMTP/TCP appllcatlon/soap+xml c=IN IP4 asb.operator,cone .
a-dlnection:both
a=wsdl: http: //schemas-Operator. oam/tonferencecoritroLwsd i
a=wscafcontexbdentiffer: http: //servteEs-Operatar. comA\^caf/20O4/t)9/wsctx/abed af:012345
a=wscaftype:
http://services,operator.com/vyEcal:/2004/09/wsctK/conte)(t/mmservice
4. En el caso de una transaccion existente, su estado se actualiza en base al(a los) mensaje(s) procesados.
5. Los elementos SOAP usados para transportar informacion de sesion se convierten a cabeceras SIP y viceversa.
Las transacciones ya asignadas a sesiones SIP pueden evitar volver a enviar informacion relacionada con la sesion de WS en los mensajes SOAP que ya se negocio durante el inicio de sesion SIP. Los ejemplos siguientes ilustran como en base a una sesion SIP establecida (como se describio en el paso 3b) la informacion relacionada con la sesion de Contexto de WS para invocacion de servicio WS se puede optimizar a traves de evitar la repeticion de la informacion relacionada con el Contexto de WS en la cabecera SOAP.
a) Un ejemplo de invocacion de servicio que especifica una sesion de Contexto de WS:
<soap: Envelope
xmlns: soap="
http://wwww3.org/3002/06/soap-en(ve[ope">
<soap:Header>
< context xmlns=,|
http://docs.oaas-open.ong/wscaf/2004/09/wscb(,r timeout=nTQ0n xmlns :wsdl="http: //schemas.xmisoap.org/wstf I/" xmlns: soapblnd=http ://schemas,xmlsoap .org/wsd |/soa p/ soap: must Understand=
< context-identifier;*

http://servioes.operator.eom/wscaf/2004/09/w5ctx/abcdef:012345
</context-identffier>
<type>

http://services. operator.eom/wscaf/2004/09/wscWt:oritExt/ni m service </type>
</context>
</soap:Header>
5
10
15
20
25
30
35
40
45
<soap:Body>
<!- Application Payload
MMServioe specific payload —>
^/soap:Body>
</soap:Enve1ope>
b) Un ejemplo de invocacion de servicio optimizada sin especificacion explicita de una sesion de Contexto de WS:
< soap:Envelope xmlns:soap=“Iittp;//www*w3 .ong/2002/06/soap-erivelope" >
<soap:Header>
</soap: Headers
<soap;Body>
<!- Application Payload
MMService specific payload -->
</soap:Body>
</soap: Envelope >
6. Los mensajes SIP generados de esta manera se reenvian al servicio IMS B.
Antes de que se pueda aplicar una autenticacion basada en un sobre SOAP como se describe en el paso 3 del algoritmo anterior, ha de ser alcanzado un acuerdo entre el consumidor del servicio y el proveedor de servicios sobre como proporcionar las credenciales requeridas. Tales credenciales se pueden intercambiar usando el siguiente protocolo:
1. El operador, como proveedor de servicios, define un formato para el intercambio de credenciales incluyendo diversos tipos de datos que describen la aplicacion y que autentican al usuario (por ejemplo, nombre de inicio de sesion, contrasena, nombre de aplicacion, etc.). Tal formato se puede implementar por varios medios, por ejemplo, extendiendo la descripcion WSDL del servicio dado para incluir los parametros adecuados o para extender la cabecera de los mensajes SOAP de nuevo con parametros de cabecera adecuados.
2. Las aplicaciones que buscan autenticacion necesitan implementar un esquema de autenticacion en base al esquema proporcionado por el operador como se describio en el paso 1.
a. Las credenciales para autenticar abonados del operador se generan en base a secretos comunes conocidos tanto por el operador como por la aplicacion (por ejemplo, la id del sistema del usuario, datos de terminal, etc.).
b. Las credenciales para autenticar no abonados necesitan ser acordadas por adelantado. Esto puede ocurrir a traves de registro en sitios adecuados proporcionados por el operador.
A continuacion, se describira una realizacion de un mecanismo de autenticacion que se puede usar en combinacion con el mecanismo de correspondencia de sesion anterior. Como entrada, el mecanismo recibe mensajes de solicitud de invocacion entrantes desde las aplicaciones no SIP que se ejecutan por ejemplo, en terminales fuera del dominio IMS. La salida sera el estado de autenticacion de las aplicaciones no SlP.
1. Analizar la direccion IP de la solicitud entrante
a. Las solicitudes que se originan desde direcciones dentro del dominio de confianza (desde el operador en si mismo o desde otras redes de confianza) se procesan ademas en el paso 2.
b. Las solicitudes que se originan desde fuera del dominio de confianza se procesan ademas en el paso 4.
2. SI la direccion IP es la direccion de un nodo conocido y de confianza que anade credenciales de autenticacion a la solicitud (por ejemplo, una pasarela WAP)
a. ENTONCES SI las credenciales incorporadas estan disponibles (por ejemplo, en el caso de una comprobacion de pasarela WAP para cabecera HTTP especial insertada por la pasarela WAP)
i ENTONCES Analizar las credenciales (por ejemplo, extraer el numero MSISDN)
5
10
15
20
25
30
35
40
ii DE OTRO MODO ir al paso 3 b. DE OTRO MODO ir al paso 3
3. Analizar la solicitud (por ejemplo, sobre SOAP) y comprobar la disponibilidad de credenciales de autenticacion (por ejemplo, dentro de la cabecera/cuerpo SOAP)
a. SI las credenciales estan disponibles entonces quitar los datos de autenticacion requeridos por el dispositivo de correspondencia a partir de la solicitud a fin de cumplir con la API de servicio original. Proceder con una autenticacion adicional en base a estos datos en el paso 5.
Los siguientes ejemplos ilustran como se extraen las credenciales requeridas para establecer la sesion IMS a partir del mensaje SOAP extendido entrante produciendo por ello un mensaje SOAP no extendido.
Un ejemplo de solicitud SOAP extendida con credenciales de autenticacion se da mas adelante:
<Soap: Envelope xmJrt5:5oap=
http://www.w3.ora/2002/nfifenao^nv&looe xmlns:auth -'‘
http://libertv.org''>
<soap: Headers-
caudrcredentiall name^userl "j>
<auth:aredentjal2 ^password="secrie!t7> ■
</5oap:Header>
^soap:Body>
<1— Application Payload
MMServIce specific payload —>
</soap:Body>
</soap: Enveloped
Un ejemplo de solicitud SOAP sin credenciales de autenticacion se da mas adelante:
< soa p: Erwelc pc xmlns: soap='iittp ://
www.w3. org/20O2/Q6/soap-ebVd0pe''>
<soap:Header>
</soap:header>
<soap:Body>
<!— Application Payload MMService specific payload -->
</$oap:Bcdy>
</soap:Envelope>
b. DE OTRO MODO ir al paso 4
4. Usar las propiedades de direccion del paquete entrante (por ejemplo, direccion IP, direccion DNS, direction MAC, etc.) para determinar impllcitamente la id del sistema del usuario y crear las credenciales temporales adecuadas. Se deberla senalar que esta identification no es tan precisa y segura como la identification permitida a traves de los pasos previos. La falta de precision se puede atribuir por ejemplo a la falta de correspondencia unica entre las direcciones IP y las aplicaciones.
5. Convertir las credenciales a formato IMS, usarlas para autenticar la aplicacion
A continuation, se trataran en mas detalle algunas realizaciones de dispositivos de correspondencia 100.
Segun una realizacion mostrada en la Figura 4, el dispositivo de correspondencia 100 se implementa como un nodo pasarela situado entre el dominio IMS 10 y clientes 20 situados en el dominio no IMS (por ejemplo, clientes SOAP 20 que usan Servicios Web). La Figura 4 ilustra una correspondencia de sesion de tiempo de ejecucion no SIP a SIP para acceder a servicios controlados por operador no SIP desplegados dentro del dominio IMS 10.
El Protocolo de Descripcion de Servicio (SDP) se puede usar para describir diferentes tipos de servicios SIP. Cada inicio de sesion SIP puede contener una descripcion SDP. Una posibilidad por lo tanto serla definir descripciones SDP para establecer sesiones de un tipo especlfico que corresponden a invocaciones de servicio no IMS especlficas
5
10
15
20
25
30
35
40
45
50
55
60
65
y tecnologla de establecimiento/gestion de sesion. La correspondencia/conversion de sesion tambien se puede permitir de esta manera asignando ciertos campos de invocaciones de servicio entrantes a sus campos correspondientes en la descripcion SDP. En este caso se asignarlan tipos especlficos de invocaciones de servicio no IMS (por ejemplo, servicios CORBA, servicios J2EE, servicios RMI de Java, servicios .NET y naturalmente servicios SOAP puros) a descripciones SDP predefinidas especlficas para estas tecnologlas.
La correspondencia de sesion se puede implementar usando una tabla que enumera las sesiones en marcha actualmente. En la tabla, cada sesion en marcha se puede asociar con parametros particulares que permiten al dispositivo de correspondencia 100, tras una recepcion de un mensaje de capa de servicio desde los clientes 20, identificar si el mensaje se refiere o no a una sesion en marcha dentro del dominio IMS 10. En principio, un cliente individual 20 se puede asociar con la pluralidad de sesiones individuales que implican uno y el mismo servicio o diferentes servicios dentro del dominio IMS 10.
Como se muestra en la Figura 4, se recibe un mensaje de invocacion de servicio por el dispositivo de correspondencia 100 en una capa de servicio (SOAP sobre HTTP) y reconoce como que invoca un servicio dentro del dominio IMS 10. Entonces, en una capa de control de sesion (“capa SIP”), tiene lugar una conversion de elemento de protocolo dentro del dispositivo de correspondencia 100 en contexto con proporcionar una sesion de control IMS (“sesion controlada por SIP”) para el servicio a ser invocado. La sesion de control IMS se usa entonces como vehlculo para comunicacion entre el cliente 20 y el servicio solicitado dentro del dominio IMS 20.
En el escenario de la Figura 4, el dispositivo de correspondencia 100 es completamente transparente a los clientes SOAP 20 que invocan (es decir, los clientes 20 no necesitan tener ningun conocimiento de la presencia y funcion del dispositivo de correspondencia 100). Esto es ventajoso debido a que permite el uso por clientes 20 estandar (no modificados) en un dominio no IMS.
El dispositivo de correspondencia 100 tambien se puede implementar en el lado del dominio no IMS, por ejemplo, dentro del cliente 20 modificando las pilas de protocolo de cliente (es decir, J2EE, pila SOAP de WS, etc.). Esto se representa en la Figura 5 usando Servicios Web como ejemplo.
La Figura 5 ilustra una correspondencia de sesion de tiempo de ejecucion no SIP o SIP para acceder a servicios controlados por operador no SIP desplegados dentro del dominio IMS 10. En este escenario, el dispositivo de correspondencia 100 se integra en la pila de protocolo de cliente del cliente 20 en el dominio no IMS. Esta solucion es particularmente ventajosa debido a que no requiere el despliegue de nodos de red adicionales (por ejemplo, de pasarelas como en la realizacion mostrada en la Figura 4).
Dada la falta de clientes habilitados IMS extendidos (por ejemplo, terminales de usuario tales como telefonos moviles) en el mercado, tal pila modificada se podrla implementar directamente en la primera generacion de tales clientes. Esto es una ventaja en la medida que elimina costes relacionados con actualizacion comparado con escenarios de despliegue tlpicos que requieren que clientes existentes sean actualizados con una funcionalidad adicional.
La implementacion del dispositivo de correspondencia 100 como una pasarela se usa normalmente para acceso transparente a los servicios controlados por operador dentro del dominio IMS 10.Un caso de uso especial para la solucion basada en pasarela podrla ser la situation donde dos componentes no IMS 20, 30 comunican uno con otro a traves de tal pasarela 100 para ser capaces de utilizar servicios IMS en forma de funciones de soporte proporcionadas por el dominio iMs 10 (tales como AAA, HSS, etc., usando el protocolo DIAMETER). Este escenario se muestra en la Figura 6 y es particularmente interesante para proveedores de servicios de terceras partes, ya que consideran que el operador es un mediador fiable y digno de confianza. El operador, a su vez, tambien puede beneficiarse ya que puede tarificar por proporcionar esta funcionalidad.
El escenario mostrado en la Figura 6 puede requerir que un proveedor de servicios 30 en un dominio no IMS tenga un acuerdo de negocio adecuado con el operador IMS y haya desplegado su servicio de un modo que se registre y sea accesible a traves de la pasarela del dispositivo de correspondencia 100. Alternativamente, un cliente 20 en un dominio no IMS tambien se puede registrar con el operador. Esto permite al cliente 20 beneficiarse de los mecanismos de autenticacion y autorizacion SIP proporcionados por el operador para identificarse por si mismo hacia el proveedor de servicios de terceras partes 30.
Con referencia a la Figura 7, se describira una realizacion de un esquema de invocacion de direccionamiento y servicio uniforme basado en SIP que se puede usar en combination con las realizaciones anteriores.
En lugar de usar el URL de HTTP (Protocolo de Transferencia de Hipertexto), los URI de SIP logicos (y eventualmente los URL de SIP) se usan para el esquema de direccionamiento uniforme y para invocaciones de servicio movil. El acceso al servicio a traves de uRl permite movilidad de servicio proporcionando un acceso transparente al servicio con independencia de su URL actual. Esto permite el direccionamiento de servicios IMS desplegados en dispositivos moviles que no tienen un acoplamiento fijo a la red y consecuentemente que no tiene un URL fijo.
5
10
15
20
25
30
35
40
45
El escenario mostrado en la Figura 7 implica dos pasos principales, esto es
a. definir el uso de un URI de SIP para invocacion dinamica de servicios IMS moviles con independencia de su URL actual. (Posiblemente definiendo una extension para Direccionamiento de WS.)
b. definir el direccionamiento fijo de servicios que usan un URL de SIP
Como se ha mostrado en las realizaciones anteriores, la interoperabilidad entre el IMS y cualquier otro dominio se puede aumentar estableciendo una correspondencia entre una sesion/servicio de WS y (una o multiples) sesiones SIP. En este contexto, los elementos SOAP usados para transportar la informacion de sesion se pueden convertir en cabeceras SIP y viceversa. Se puede evitar el reenvlo de la informacion relacionada con la sesion de WS en los mensajes SOAP dentro de redes IMS/SIP si la sesion SIP ya se ha dotado con ella.
Las tecnicas se pueden realizar por una pasarela SIP a no SIP (por ejemplo, SIP-SOAP) que asigna transparentemente entre por ejemplo servicios no SIP y sesiones SIP y se puede usar sin adaptacion de la aplicacion cliente. Alternativamente, las tecnicas se realizan en las realizaciones anteriores extendiendo la pila WS/pila SIP para mejorar las aplicaciones permitiendolas asignar transparentemente entre sesiones WS y sesiones SIP sin componentes de infraestructura adicionales en la red.
De esta manera, las realizaciones proporcionan invocacion de WS dentro de un dominio o red IMS. Permiten el uso de mecanismos existentes de gestion de sesion basada en SIP mas eficientes para gestion de sesion WS y proporcionan una mejor interoperabilidad e integracion entre el sistema IMS y la infraestructura y los Servicios Web desplegados dentro del dominio IMS. Ademas, las realizaciones hacen posible usar mecanismos IMS estandar para AAA, tarificacion, etc. tambien para invocaciones y control de servicios tales como Servicios Web fuera del dominio IMS. Haciendolo asl, las realizaciones permiten una integracion sin discontinuidad de Servicios Web en sistemas IMS. Los desarrolladores no necesitan soportar expllcitamente los protocolos IMS/SIP y las API. Todo esto se puede hacer transparentemente o por las extensiones de pilas WS y/o SIP.
Ademas, las realizaciones permiten una reduccion en la cantidad de trafico requerido para transmision de informacion de sesion por ejemplo, mediante Servicios Web dentro de redes IMS. Las realizaciones tambien proporcionan Servicios Web con movilidad permitiendo invocacion que usa su URI que puede ser diferente de su URL. Esto permite al servicio cambiar su plataforma de ejecucion (y por lo tanto su URL) mientras que aun se puede direccionar bajo el mismo URI. A este respecto, el encaminamiento de llamadas de invocacion de servicio se puede manejar por un registro SIP (es decir, un nodo CSCF en el dominio IMS) que es consciente de la posicion actual de cada usuario y redirige llamadas de invocacion de servicio usando el URI de SIP al URL de SIP correcto actualmente.
Se deberla senalar que los planteamientos expuestos anteriormente se pueden usar no solamente para correspondencia de sesiones de Servicios Web a sesiones SIP. En principio, la invencion se puede usar para correspondencia de cualquier protocolo de Llamada de Procedimiento Remoto (RPC) que tiene el concepto de sesiones a cualquier protocolo interno IMS adecuado para las necesidades requeridas. Estos pueden incluir, por ejemplo, CORBA, RMI de Java y otros protocolos propietarios.
Aunque la presente invencion se ha descrito con respecto a realizaciones particulares, los expertos en la tecnica reconoceran que la presente invencion no esta limitada a las realizaciones especlficas descritas e ilustradas en la presente memoria. Por lo tanto, aunque la presente invencion se ha descrito en relacion a sus realizaciones preferidas, se tiene que entender que esta descripcion es solamente ilustrativa. Por consiguiente, se pretende que la invencion este limitada solamente por el alcance de las reivindicaciones adjuntas a la misma.

Claims (23)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    REIVINDICACIONES
    1. Un metodo de provision de interoperabilidad entre un dominio de subsistema multimedia de protocolo de Internet (IMS) (10) y un domino no IMS (20), que comprende los pasos de:
    recibir (S1) en una capa de servicio un mensaje de invocacion de servicio (101) desde el dominio no IMS; analizar (S2) el mensaje para identificar (S3) el mensaje (101) como una solicitud para invocar un servicio dentro del dominio IMS;
    convertir (S4) en una capa de control de sesion elementos de protocolo de control de sesion no IMS relacionados con el mensaje (101) en elementos de protocolo relacionados con control de sesion IMS; enviar (S5) uno o mas mensajes (107) hacia el dominio IMS para proporcionar una sesion de control IMS en el dominio IMS en base a los elementos de protocolo relacionados con control de sesion IMS; y reenviar en la capa de servicio el mensaje de invocacion de servicio (107) usando la sesion de control IMS; caracterizado por que ademas comprende los pasos de:
    analizar el mensaje (101, 107) recibido desde el dominio no IMS y/o desde el dominio IMS; determinar un estado de la sesion con el servicio en el dominio iMs en base al mensaje analizado; y almacenar el estado de la sesion.
  2. 2. El metodo de la reivindicacion 1, que ademas comprende el paso de:
    recibir un mensaje adicional (101) desde el dominio no IMS relacionado con el servicio invocado dentro del dominio IMS; y
    reenviar en la capa de servicio el mensaje de servicio (107) usando la sesion de control IMS.
  3. 3. El metodo de cualquier reivindicacion precedente, que ademas comprende los pasos de:
    recibir un mensaje (107) desde el dominio IMS durante la sesion;
    convertir elementos de protocolo de control de sesion IMS relacionados con el mensaje (107) del dominio IMS en elementos de protocolo de control de sesion no IMS;
    generar un mensaje no IMS (101) en base a los elementos de protocolo de control de sesion no IMS; y enviar el mensaje no IMS (101) al dominio no IMS.
  4. 4. El metodo de la reivindicacion 3, en donde el mensaje no IMS se envla al dominio no IMS durante la sesion.
  5. 5. El metodo de cualquier reivindicacion precedente, en donde el servicio en el dominio IMS es una funcion de soporte IMS, tal como autenticacion, autorizacion y contabilidad, tarificacion, control de acceso o HSS.
  6. 6. El metodo de cualquier reivindicacion precedente, en donde el servicio en el dominio IMS es una aplicacion basada en protocolo no IMS.
  7. 7. El metodo de cualquier reivindicacion precedente, en donde los elementos de protocolo de control de sesion IMS comprenden cabeceras de protocolo de inicio de sesiones (SIP) y los elementos de protocolo de control de sesion no IMS comprenden cabeceras no SIP.
  8. 8. El metodo de cualquier reivindicacion precedente, en donde el dominio no IMS emplea un protocolo para intercambiar mensajes basados en Leguaje de Marcas (ML).
  9. 9. El metodo de cualquier reivindicacion precedente, que comprende los pasos de:
    comprobar si una sesion con el servicio en el dominio IMS esta en marcha; y
    si no hay ninguna sesion en marcha, iniciar una nueva sesion bajo el protocolo de control de sesion IMS.
  10. 10. El metodo de cualquier reivindicacion precedente, que ademas comprende el paso de asociar un solicitante de servicio con una o mas sesiones solicitadas y/o en marcha dentro del dominio IMS.
  11. 11. El metodo de la reivindicacion 10, en donde el solicitante de servicio es una aplicacion o un componente de red fuera del dominio IMS.
  12. 12. El metodo de cualquier reivindicacion precedente, que comprende el paso de:
    autenticar el mensaje no IMS anterior a establecer la sesion de control en el dominio IMS.
  13. 13. El metodo de la reivindicacion 12, en donde el paso de autenticacion del mensaje no IMS comprende analizar una direccion especificada en el mensaje.
    5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
  14. 14. El metodo de cualquier reivindicacion precedente, que comprende el paso de:
    emplear un esquema de direccionamiento uniforme usando direccionamiento SIP para la invocacion de servicios fijos y/o moviles.
  15. 15. El metodo de cualquier reivindicacion precedente, en donde el servicio a ser invocado reside en una plataforma movil dentro del dominio IMS, el metodo que comprende el paso de:
    definir un identificador de recursos unico (URI) de SIP para invocacion dinamica del servicio en el dominio IMS, con independencia de un localizador de recursos unico (URL) actual para la plataforma movil.
  16. 16. El metodo de cualquier reivindicacion precedente, que comprende el paso de:
    definir un localizador de recursos unico (URL) de SIP para direccionamiento fijo del servicio en el dominio IMS.
  17. 17. Un producto de programa de ordenador que comprende partes de codigo de programa para realizar los pasos de cualquiera de las reivindicaciones precedentes cuando el producto de programa de ordenador se ejecuta en uno o mas ordenadores o sistemas informaticos.
  18. 18. El producto de programa de ordenador de la reivindicacion 17, en donde el producto de programa de ordenador se almacena en un medio de grabacion legible por ordenador.
  19. 19. Un sistema que comprende un procesador de ordenador y una memoria acoplada al procesador, en donde la memoria se codifica con uno o mas programas que pueden realizar pasos para proporcionar interoperabilidad entre un protocolo de inicio de sesiones y un no protocolo de inicio de sesiones segun cualquiera de los metodos de las reivindicaciones 1 a 16.
  20. 20. Un dispositivo de correspondencia (100) para proporcionar interoperabilidad entre un dominio de protocolo de inicio de sesiones (IMS) y un dominio no IMS (20), que comprende:
    una unidad de analisis (102) para analizar mensajes de invocacion de servicio entrantes (101) recibidos en una capa de servicio desde el dominio no IMS (20), para identificar si uno de los mensajes de invocacion de servicio (101) es una invocacion de un servicio dentro del dominio IMS (10);
    una unidad de conversion (104) para convertir en una capa de control de sesion elementos de protocolo de control de sesion no IMS relacionados con uno de los mensajes (101) en elementos de protocolo relacionados con control de sesion IMS; y
    una unidad de mensajerla (106) para generar uno o mas mensajes (107) para proporcionar una sesion de control IMS en el dominio IMS (10) en base a los elementos de protocolo relacionados con control de sesion IMS;
    en donde el dispositivo (100) esta adaptado para reenviar en la capa de servicio el mensaje de invocacion de servicio usando la sesion de control IMS;
    caracterizado por que el dispositivo (100) esta adaptado ademas para analizar el mensaje (101, 107) recibido desde el dominio no IMS y/o desde el dominio IMS; determinar un estado de la sesion con el servicio en el dominio iMs en base al mensaje analizado; y almacenar el estado de la sesion.
  21. 21. El dispositivo de correspondencia (100) de la reivindicacion 20, en donde el dispositivo se implementa como una pasarela entre el dominio IMS y el dominio no IMS.
  22. 22. El dispositivo de correspondencia (100) de la reivindicacion 20, en donde el dispositivo esta integrado en una pila de protocolo de un componente de red en el dominio no IMS.
  23. 23. Un terminal de usuario que comprende el dispositivo de correspondencia (100) de cualquiera de las reivindicaciones 20 a 22.
ES05820039.5T 2005-12-19 2005-12-19 Técnica para proporcionar interoperabilidad entre diferentes dominios de protocolo Active ES2564423T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2005/013674 WO2007071269A1 (en) 2005-12-19 2005-12-19 Technique for providing interoperability between different protocol domains

Publications (1)

Publication Number Publication Date
ES2564423T3 true ES2564423T3 (es) 2016-03-22

Family

ID=36888613

Family Applications (1)

Application Number Title Priority Date Filing Date
ES05820039.5T Active ES2564423T3 (es) 2005-12-19 2005-12-19 Técnica para proporcionar interoperabilidad entre diferentes dominios de protocolo

Country Status (7)

Country Link
US (1) US9531817B2 (es)
EP (1) EP1964349B1 (es)
JP (1) JP5179372B2 (es)
CN (1) CN101379791B (es)
DK (1) DK1964349T3 (es)
ES (1) ES2564423T3 (es)
WO (1) WO2007071269A1 (es)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070223462A1 (en) * 2006-03-27 2007-09-27 Steven Hite Enhanced service delivery platform that provides a common framework for use by IMS and Web applications in delivering services
EP2011346B1 (en) 2006-04-13 2016-12-28 Tekelec, Inc. Methods, systems, and computer program products for providing internet protocol multimedia subsystem (ims) services in response to advanced intelligent network (ain) triggers
US20100246444A1 (en) * 2006-08-23 2010-09-30 Andreas Witzel Method for registering in an ims domain a non-ims user device
US8914433B2 (en) * 2006-09-20 2014-12-16 At&T Intellectual Property I, L.P. Publish-subscription platforms for alert messages and related methods and computer program products
US7940748B2 (en) * 2006-11-17 2011-05-10 At&T Intellectual Property I, Lp Systems, methods and computer program products supporting provision of web services using IMS
CN101874385B (zh) * 2007-09-06 2013-11-06 泰克莱克股份有限公司 用于使用互通规范/会话发起协议(ios/sip)适配器在电信网络中提供服务的方法和系统
US20090168758A1 (en) * 2007-12-31 2009-07-02 Sony Ericsson Mobile Communications Ab Methods for facilitating communication between internet protocol multimedia subsystem (ims) devices and non-ims devices and between ims devices on different ims networks and related electronic devices and computer program products
US8831032B2 (en) * 2008-03-05 2014-09-09 Telefonaktiebolaget L M Ericsson (Publ) SIP-HTTP application correlator
CN101911664A (zh) * 2008-03-06 2010-12-08 株式会社日立制作所 服务控制装置、服务控制系统及方法
WO2009128769A1 (en) * 2008-04-16 2009-10-22 Telefonaktiebolaget L M Ericsson (Publ) Systems and methods for dynamically adaptive multi-way message conversion
US8850069B2 (en) 2008-04-16 2014-09-30 Telefonaktiebolaget Lm Ericsson (Publ) Systems and methods for dynamically adaptive multi-way message conversion
US8060604B1 (en) * 2008-10-10 2011-11-15 Sprint Spectrum L.P. Method and system enabling internet protocol multimedia subsystem access for non internet protocol multimedia subsystem applications
JP5184330B2 (ja) * 2008-12-24 2013-04-17 Ｋｄｄｉ株式会社 基地局装置および無線通信システム。
UA101880C2 (ru) 2009-02-04 2013-05-13 Нокиа Корпорэйшн Смена доступа для ремаршрутизации соединения
US9357384B2 (en) 2009-02-09 2016-05-31 International Business Machines Corporation System and method to support identity theft protection as part of a distributed service oriented ecosystem
JP5313395B2 (ja) * 2009-04-13 2013-10-09 リサーチ イン モーション リミテッド Ｓｉｐメッセージに対する信用を決定するシステムおよび方法
TWI531195B (zh) * 2009-04-20 2016-04-21 內數位專利控股公司 多網域及網域所有權系統
US8918516B2 (en) * 2009-05-01 2014-12-23 Galixsys Networks Llc Symbiotic client and server for embedded network system
JP5378606B2 (ja) * 2009-11-26 2013-12-25 中国移▲動▼通信集▲団▼公司 認証システム、方法および設備
US8583811B2 (en) 2010-04-23 2013-11-12 Qualcomm Incorporated Gateway device for multimedia content
US8412836B2 (en) * 2010-07-07 2013-04-02 Microsoft Corporation User authentication across multiple network stacks
US8555332B2 (en) * 2010-08-20 2013-10-08 At&T Intellectual Property I, L.P. System for establishing communications with a mobile device server
US8438285B2 (en) 2010-09-15 2013-05-07 At&T Intellectual Property I, L.P. System for managing resources accessible to a mobile device server
US8989055B2 (en) 2011-07-17 2015-03-24 At&T Intellectual Property I, L.P. Processing messages with a device server operating in a telephone
US8478905B2 (en) 2010-10-01 2013-07-02 At&T Intellectual Property I, Lp System for synchronizing to a mobile device server
US8610546B2 (en) 2010-10-01 2013-12-17 At&T Intellectual Property I, L.P. System for selecting resources accessible to a mobile device server
US8443420B2 (en) 2010-10-01 2013-05-14 At&T Intellectual Property I, L.P. System for communicating with a mobile device server
US8516039B2 (en) 2010-10-01 2013-08-20 At&T Intellectual Property I, L.P. Apparatus and method for managing mobile device servers
US8504449B2 (en) 2010-10-01 2013-08-06 At&T Intellectual Property I, L.P. Apparatus and method for managing software applications of a mobile device server
US9392316B2 (en) 2010-10-28 2016-07-12 At&T Intellectual Property I, L.P. Messaging abstraction in a mobile device server
US9066123B2 (en) 2010-11-30 2015-06-23 At&T Intellectual Property I, L.P. System for monetizing resources accessible to a mobile device server
US8291432B2 (en) 2010-12-01 2012-10-16 International Business Machines Corporation Providing invocation context to IMS service provider applications
CA2849260A1 (en) * 2011-09-20 2013-03-28 Aetherworks, Llc Systems and methods for the demand-driven deployment of location-neutral software
CN102347950B (zh) * 2011-09-29 2018-02-06 中兴通讯股份有限公司 电信网络向互联网提供会话服务的方法及系统
US8762559B2 (en) * 2011-12-16 2014-06-24 Robert L. Engelhart System and method for non-IMS application service access over IP multimedia subsystem
CN102739804A (zh) * 2012-07-12 2012-10-17 白玉琪 基于设备自定义的设备互操作方法
US9462332B2 (en) 2012-12-05 2016-10-04 At&T Intellectual Property I, L.P. Method and apparatus for controlling a media device
WO2014175919A1 (en) 2013-04-26 2014-10-30 Intel IP Corporation Shared spectrum reassignment in a spectrum sharing context
US9769646B2 (en) * 2015-02-26 2017-09-19 T-Mobile Usa, Inc. Realm translation in an IMS network

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6377993B1 (en) * 1997-09-26 2002-04-23 Mci Worldcom, Inc. Integrated proxy interface for web based data management reports
US7124413B1 (en) * 1999-11-03 2006-10-17 Accenture Llp Framework for integrating existing and new information technology applications and systems
EP1137236A1 (en) * 2000-03-24 2001-09-26 BRITISH TELECOMMUNICATIONS public limited company Processing network address identifiers
DE60222874T2 (de) * 2001-04-04 2008-07-24 Nokia Corp. Trassierungsverfahren und -system
US20040148416A1 (en) * 2003-01-29 2004-07-29 Jryki Aarnos Method and apparatus for messaging between a client of an sip-based network and a client of a wireless village network
JP4273899B2 (ja) * 2003-09-25 2009-06-03 日本電気株式会社 ネットワークシステム、プロトコル変換装置及び方法
JP4710244B2 (ja) * 2004-04-30 2011-06-29 沖電気工業株式会社 サービス提供システムおよびその提供方法
DE602005012817D1 (de) * 2004-09-30 2009-04-02 Huawei Tech Co Ltd Verfahren system zur realisierung von kommunikation
CN103763446B (zh) * 2005-03-10 2016-01-20 朗迅科技公司 使用既有设备的ims网络接入
FI20050494A0 (fi) * 2005-05-10 2005-05-10 Nokia Corp Palvelun tarjoaminen tietoliikennejärjestelmässä
US20060291489A1 (en) * 2005-06-24 2006-12-28 Aylus Networks, Inc. System and method to mediate delivery of legacy, non-IMS services into an IMS network
US7983240B2 (en) * 2006-10-16 2011-07-19 Telefonaktiebolaget Lm Ericsson (Publ) System and method for communication session correlation
FR2924557B1 (fr) * 2007-12-04 2016-08-19 Thales Sa Procede d'acheminement de messages sur un reseau et systeme de mise en oeuvre du procede

Also Published As

Publication number Publication date
EP1964349A1 (en) 2008-09-03
US20090093237A1 (en) 2009-04-09
WO2007071269A1 (en) 2007-06-28
JP2009520390A (ja) 2009-05-21
DK1964349T3 (en) 2016-03-07
CN101379791A (zh) 2009-03-04
US9531817B2 (en) 2016-12-27
JP5179372B2 (ja) 2013-04-10
CN101379791B (zh) 2011-11-09
EP1964349B1 (en) 2015-12-16

Similar Documents

Publication Publication Date Title
ES2564423T3 (es) Técnica para proporcionar interoperabilidad entre diferentes dominios de protocolo
US9331967B2 (en) Browser/HTML friendly protocol for real-time communication signaling
US10476915B2 (en) Real-time communication signaling gateway
US8094648B2 (en) Method and system for mobile-to-mobile web service handling
US9473581B2 (en) Integrated web-enabled session border controller
US9307031B2 (en) Generic model for customizing protocol behavior through javascript
US9509745B2 (en) Java API for programming web real-time communication applications
JP5189104B2 (ja) プライベート・ネットワークとのマルチメディア通信を可能にするための方法および装置
EP3782351B1 (en) Services-based architecture for ims
DK2044747T3 (en) Technique for providing access to a media resource connected to a network detected devices
US20170142166A1 (en) System and method for real-time communication by using a client application communication protocol
US9648049B2 (en) System and method for extending IP multimedia subsystem to HTML5 environments
US8442031B2 (en) Method and apparatus for utilizing network services in a manner substantially transparent to service endpoints
US20070081519A1 (en) System and method for providing multimedia services utilizing a local proxy
JP5260746B2 (ja) エンド・ツー・エンドのアドレス転送
US7899058B2 (en) Using a hash value as a pointer to an application class in a communications device
Chou et al. WIP: Web service initiation protocol for multimedia and voice communication over IP
Handa System engineering for IMS networks
Chou et al. Web services methods for communication over IP
Nurmela Session initiation protocol
Fajandar Implementing an Authorization model in a SIP User Agent to secure SIP sessions
Lakay SIP-based content development for wireless mobile devices with delay constraints
Arif et al. Sovoip: middleware for universal voip connectivity
Dersingh et al. Session-based service discovery and access control in peer-to-peer communications
KR20070018888A (ko) 웹 서비스 처리용 방법 및 시스템