El Subsistema IP Multimedia (IMS)

El objetivo general de la Tesis es contribuir al soporte de las aplicaciones HIMMA como las mencionadas anteriormente, centrándose en entornos de Red de Próxima Generación (Next Generation Network o NGN) y, más concretamente, en uno de sus principales exponentes: el Subsistema IP Multimedia o IMS [4] (IP Multimedia Subsystem).

El IMS es la propuesta de 3GPP [20] (Third Generation Partnership Project) para la creación de una red multimedia Todo IP capaz de prestar tanto los servicios tradicionales (telefonía, principalmente) como nuevos servicios multimedia de valor añadido (videoconferencia, televisión bajo demanda, mensajería instantánea, etc.). Dado que está basado en estándares de Internet como SIP [21] (Session Initiation Protocol) o RTP [22] (Real Time Protocol), la implementación del IMS se ve favorecida por la madurez del conocimiento de tecnologías de Internet. Cabe destacar que el IMS constituye un estándar ampliamente aceptado en la industria (especialmente por los operadores móviles), si bien su disponibilidad comercial para el público es todavía escasa.

El IMS fue introducido por el 3rd Generation Partnership Project (3GPP) en las especificaciones de la Release 5 de UMTS (Universal Mobile Telecommunication System), como componente clave para la provisión de servicios multimedia en redes móviles 3G evolucionadas. No obstante, la arquitectura IMS es independiente de la red de acceso y existen diversos esfuerzos de estandarización, no sólo por parte de 3GPP, para garantizar la convergencia de redes manteniendo IMS como núcleo de gestión de servicios. Así, las siguientes revisiones de la especificación de IMS definen la integración con redes fijas, gracias al trabajo de ETSI TISPAN (Telecoms and Internet converged Services and Protocols for Advanced Networks), y nuevas tecnologías inalámbricas como Wimax y LTE (Long Term Evolution).

2.2.1

Arquitectura general de IMS

Los operadores que desplieguen una arquitectura IMS deben contar al menos con el denominado “núcleo IMS” (IMS core) formado por el Home Subscriber Server (HSS) y los intermediarios de señalización, que reciben el nombre de Call State Control Function

(CSCF). El HSS es la base de datos de perfiles de usuario, credenciales de autenticación y condiciones de servicio, accesible mediante interfaces basados en el protocolo DIAMETER. Por su parte, los CSCF son servidores de señalización SIP (Session Initiation Protocol) que soportan las funciones de registro, localización y

encaminamiento definidas en el estándar. El estándar define tres tipos de CSCF, especializados en distintas tareas:

 P-CSCF (Proxy-CSCF): Servidor proxy especializado en el diálogo directo con los terminales, constituyendo la puerta de entrada de los usuarios al IMS. La dirección del P-CSCF la obtiene el terminal de usuario al solicitar el acceso al IMS.

 I-CSCF (Interrogating-CSCF): Proporciona funciones de localización en el IMS mediante su capacidad para realizar consultas a la base de datos central (HSS). Constituye el punto de contacto para alcanzar a los usuarios (propios o roamers) de una red IMS. El I-CSCF puede, opcionalmente, facilitar la ocultación de detalles en sesiones IMS entre operadores.

 S-CSCF (Serving-CSCF): Especializado en cursar las peticiones de registro y mantener el estado de las sesiones SIP de los usuarios del IMS. Así mismo, es el elemento donde se identifican los servicios a ejecutar, sea en el propio S- CSCF o en un servidor de aplicaciones externo. Cada usuario registrado en el IMS tiene asignado un S-CSCF.

Existen otros elementos que proporcionan funcionalidad adicional, como el servidor de gestión de documentos XML (XDMS, clave para las funciones de presencia y gestión de grupos), el servidor de tratamiento de medios (Media Resource Function o MRF), el servidor de aplicaciones (para funciones específicas de cierto servicio) y diversas pasarelas para interconexión con otras redes, todos ellos mostrados en la Fig. 8 y que pueden ordenarse lógicamente en capas como ilustra la Fig. 9.

Fig. 8. Esquema general de la arquitectura IMS

Conforme avance la exposición iremos profundizando en los aspectos específicos de la arquitectura que sean relevantes en la solución propuesta en esta Tesis, indicando en todo momento si los componentes y mecanismos de interacción forman parte del estándar (siendo susceptibles de estar disponibles en cualquier entorno IMS), si son componentes específicos de la solución añadidos a la arquitectura o si son propuestas de modificación o ampliación de la señalización estándar para soportar servicios de valor añadido. Ro Rf Ga Bx Bx ISC ISC Mp Mw ISC Ut Ut ISC Dh Sh Gm Gm ISC Mr Dx Cx Cx Mi Dx Mw Mw S-CSCF P-CSCF I-CSCF AS MRFC BGCF HSS SLF XDMS SCIM Other networks User UE User UE DIAMETER SIP XCAP MRFP Presence Server Billing System CDF CGF OCS Online charging Offline charging

Fig. 9. Arquitectura de IMS por capas

2.2.2

Servicio de conferencias audiovisuales multimedia

El servicio de conferencias multimedia IMS permite comunicaciones de voz, vídeo o texto full-duplex entre varios usuarios. Este servicio se presta de forma estándar de manera centralizada acorde a la especificación de 3GPP [23]. El nodo central es el MRF (Media Resource Function) que incluye tanto funciones de señalización SIP (MRF Controller) como de tratamiento de medios audiovisuales (MRF Processor). El controlador es un foco (focus) de señalización SIP, mientras que el procesador realiza las mezclas del audio y vídeo empaquetado en los flujos RTP de los participantes con el fin de crear y distribuir el mosaico de vídeos típicos de una videoconferencia con múltiples usuarios.

En un escenario típico, el usuario que quiera crear una conferencia envía un INVITE a la dirección de la factoría de conferencias (una URI conocida), la cual responderá con una URI única que identifique a la conferencia creada. El resto de usuarios deben establecer sesión de audio o vídeo con esa URI única para ser incluidos en la conferencia.

2.2.3

Servicio Pulsar para Hablar (Push to Talk)

El servicio de pulsar para hablar, Push To Talk Over Cellular, también conocido por sus acrónimos PTT o PoC, es un servicio de tipo walkie-talkie que permite comunicaciones de voz half-duplex uno a uno o uno a varios. Está estandarizado por la Open Mobile Alliance (OMA) y sigue una arquitectura cliente/servidor. Los servidores

Transporte y control de acceso AS XDMS HSS CSCFs MRF RACS BGCF NASS SLF Capa de control Habilitadores básicos estándar (presencia, grupos, mensajería) Habilitadores diferenciadores ... ...

App 1 App 2 ... Aplicaciones (lado servidor)

SIP / HTTP / RTP / ...

SIP UA

XDM

Client Equipo de usuario

distribución de audio. Los clientes deben soportar la especificación de PoC, incluyendo los siguientes protocolos: SIP para el establecimiento de sesión, TBCP (Talk Burst Control Protocol, específico de PoC) para el control de sala y RTP para el transporte de medios. Además, para crear y gestionar grupos de usuarios de PoC es necesario el protocolo XCAP.

Para establecer una comunicación PoC uno a uno, el usuario que inicia la sesión invita directamente al otro usuario. El intermediario S-CSCF, que inspecciona las cabeceras de los mensajes SIP para aplicar las reglas de encaminamiento definidas, enviará el mensaje a través del servidor PoC. En comunicaciones uno a varios, el primer paso es crear un grupo PoC en el servidor XDM especificando el conjunto de participantes y/o los criterios para permitir participar a usuarios que no estén en la lista. La comunicación puede ser iniciada de forma automática por el servidor PoC, que enviará las peticiones de inicio de sesión pertinentes a todos los usuarios del grupo. Los usuarios que conozcan la URI de servicio de esa comunicación PoC también pueden añadirse iniciando sesión con ella siempre y cuando sean aceptados por cumplir las políticas de acceso del grupo.