IMS (Ok)

Proyecto Fin de Carrera
IP Multimedia Subsystem: el impulsor

de la convergencia de redes y la
integración de servicios
Autor José María Rivera Rubio
Tutor Dr. Alejandro Carballar Rincón
Sevilla, junio de 2009

Resumen
La sociedad de hoy en día se encuentra inmersa en el proceso de convergencia de
los mundos de Internet y de las Comunicaciones Móviles o inalámbricas. Con la
aparición de la banda ancha en entornos de movilidad de la mano de tecnologías
como UMTS,WiFi,WiMax y los ya existentes como el cable, la fibra, las líneas
eléctricas, ... aumentan las expectativas de los consumidores y se mejoran los
servicios y aplicaciones.
En la jerga empresarial siempre se citó aquello de que “el consumidor es el rey”. Esta
célebre frase significa, en el lenguaje tecnológico de hoy en día, que los consumidores
son los catalizadores de los avances tecnológicos. Son ellos quienes llevan a los
proveedores de servicios a proporcionar paquetes de servicios, con la calidad de
servicio Quality of Service (QoS) adecuada al precio idóneo y con características
atractivas a la vez que novedosas ligadas a la movilidad y los contenidos multimedia.
Son estas expectativas los verdaderos promotores del desarrollo de la arquitectura
de servicios del IP Multimedia Subsystem (IMS).
Este proyecto pretende dar una profunda visión de IMS, así como de su entorno de
desarrollo más extendido, el Service Development Studio (SDS) de c Ericsson.
Este Proyecto Fin de Carrera parte de la necesidad de elaborar un documento
que desmenuce la escasa y compleja bibliografía del estándar sin dejar de lado los
numerosos documentos e informes que viene elaborando la industria sobre multitud
de servicios, aplicaciones y nuevas tecnologías sobre IMS. Con todo, la memoria de
este Proyecto Fin de Carrera persigue recoger en un mismo documento la descripción
detallada de cinco grandes aspectos:
IMS como estándar teórico del 3GPP.
SDS como entorno de implementación y plugin de Eclipse que simula la
arquitectura de IMS.
Comparación entre la especificación y la arquitectura simulada desde el punto
de vista de los servicios.
Descripción del estado actual de la tecnología mediante el análisis de servicios y
aplicaciones novedosas que recojan los grandes principios de IMS: convergencia
de redes, integración de servicios, QoS y revolución en la tarificación. Con esta
descripción se elabora una propuesta de despliegue comercial de un servicio
por parte de una hipotética operadora.
El modelo de explotación en IMS.
Abstract
Nowadays’ society is immerse in the merging process of the Internet and the Cellular
worlds. Since the broadband technologies like UMTS, WiFi and WiMax arose in
the wireless environments, consumers’expectations and operators’ prospects grew
dramatically due to the new capabilities that might be available for more innovative,
new and better services.
It has always been said that the customer is the king. This famous sentence means
customers are really the drivers of technology developments. Consumers make the
service providers offer new service bundles with more economic prizes, better and
ensured Quality of Service (QoS) and with richer and innovative mobility and
multimedia solutions.
These expectations are the actual engine for the development of the IP
Multimedia Subsystem (IMS) service architecture.
This project intends to provide a deep insight of the IMS and best known
development framework, the
c Ericsson’s SDS.
The present end-of-degree project emerges from the idea of gathering the scarce
and complex bibliography of the standard and the huge amount of documents, white
papers and reports from the industry. As a result, this document contains a detailed
description of the five following issues:
IMS: the 3GPP standard.
SDS: the development framework and IMS architecture simulation plugin for
Eclipse.
Comparison of the actual and the simulated architecture, from the services’
creation perspective.
Description of the today’s technology state: analysis of new services and
applications based on IMS principles (network convergence, service integration,
QoS and new charging architecture). Proposal of a commercial deployment.
The IMS business model.
Descriptores/Keywords
IMS, IP Multimedia Subsystem, Service Development Studio, SDS, All-Ip, 4G,
3GPP R5, 3GPP R6, 3GPP R7
iv
Índice general
1. Introducción 1
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Organización de la memoria . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introducción teórica al IP Multimedia Subsystem, IMS 5

2.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Justificación: ¿Por qué IMS? . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Tendencias Todo-IP (All-IP) en 3G e IMS y convergencia del IETF
con 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1. Tendencias hacia la convergencia: el All-IP . . . . . . . . . . . 10
2.3.2. Sinergias entre grupos de estandarización: el IETF con el 3GPP 11
2.3.3. El 3GPP Release 5 y la génesis de los servicios IP Multimedia 12
2.4. Protocolos utilizados en IMS . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1. Sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5. Arquitectura de IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6. Funcionamiento de IMS . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6.1. Fases previas al funcionamiento en IMS . . . . . . . . . . . . . 27
2.6.2. Procedimiento de registro en IMS . . . . . . . . . . . . . . . . 28
2.6.3. Establecimiento de sesión . . . . . . . . . . . . . . . . . . . . 29
2.6.4. Establecimiento de sesión con provisión de servicios añadidos . 37
2.6.5. El mapeo de servicios: los Filter Criteria . . . . . . . . . . . . 42
2.6.6. Establecimiento de sesión desde y hacia una red de circuitos
PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.7. Servicios IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.7.1. El servicio de presencia . . . . . . . . . . . . . . . . . . . . . . 49
2.7.2. Servicio de mensajería . . . . . . . . . . . . . . . . . . . . . . 50
2.7.3. PoC, Push to talk Over Cellular . . . . . . . . . . . . . . . . . 50
3. Un entorno de desarrollo: el SDS de c Ericsson 53

3.1. Herramientas de desarrollo de aplicaciones y servicios IMS: ¿Por qué
el SDS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.1.1. RADVISION IMS Developer Suite . . . . . . . . . . . . . . . 53
3.1.2. Nokia Siemens Networks IMS Developer Program . . . . . . . 54
3.1.3. Ericsson Service Development Studio (SDS) y comparativa . . 55
3.2. ¿Qué es el SDS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2.1. Beneficios del SDS . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2.2. Subsistemas del SDS y características esenciales . . . . . . . . 59
3.3. Futuras versiones y roadmap . . . . . . . . . . . . . . . . . . . . . . . 59
v
3.4. Subsistemas del SDS y su modo de uso . . . . . . . . . . . . . . . . . 60
3.4.1. Entorno de diseño (Design Environment) . . . . . . . . . . . . 60
3.4.2. Framework del cliente IMS: plataforma (ICP/IJCU) y aplica-
ciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.4.3. La plataforma de clientes IMS, la IMS Client Platform (ICP) 82
3.4.4. La solución para terminales limitados en recursos: IMS JME
Client Utility (IJCU) . . . . . . . . . . . . . . . . . . . . . . . 94
3.4.5. Emulador del núcleo de red IMS . . . . . . . . . . . . . . . . . 96
3.5. Emuladores de terminales móviles . . . . . . . . . . . . . . . . . . . . 106
3.6. Ejemplo de desarrollo de una aplicación IMS con el SDS . . . . . . . 107
3.6.1. Modelo y actores del servicio . . . . . . . . . . . . . . . . . . . 108
3.6.2. Implementación en Java . . . . . . . . . . . . . . . . . . . . . 109
3.6.3. Creación de valor añadido: capacidades IMS y mejoras . . . . 111
4. Creación de un servicio IMS con el SDS 113

4.1. Visión general de la creación de un servicio IMS . . . . . . . . . . . . 113
4.2. Creación de un servicio con el SDS, paso a paso . . . . . . . . . . . . 117
4.2.1. Primera fase: programar, testar, y simular extremo a extremo
en PCs con emuladores IMS SDS . . . . . . . . . . . . . . . . 117
4.2.2. Segunda fase: test y pruebas de usuario extremo a extremo
con dispositivos y redes reales . . . . . . . . . . . . . . . . . . 120
4.2.3. Tercera fase: despliegue en servidores comerciales . . . . . . . 123
4.3. Diferencias entre el estándar y el SDS: Limitaciones y problemas . . . 129
4.3.1. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.3.2. Principales problemas . . . . . . . . . . . . . . . . . . . . . . 130
5. Propuesta de despliegue comercial de un servicio y plan de explotación133

5.1. Propuesta de despliegue comercial de un servicio IMS . . . . . . . . . 133
5.1.1. Introducción al problema . . . . . . . . . . . . . . . . . . . . . 133
5.1.2. Los Web Services . . . . . . . . . . . . . . . . . . . . . . . . . 133
5.1.3. Alternativas de despliegue comercial de un servicio IMS . . . . 134
5.1.4. Propuesta de despliegue para Parlay X Web Services . . . . . 137
5.2. El modelo de explotación de IMS . . . . . . . . . . . . . . . . . . . . 140
5.2.1. Estado actual del despliegue de IMS y diferentes planes de
explotación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.2.2. Visión estratégica del IP Multimedia Subsystem (IMS) . . . . 142
5.2.3. Nueva cadena de valor de los servicios de telecomunicaciones . 144
5.2.4. Solución: el proveedor integral de servicios . . . . . . . . . . . 145
6. Conclusiones y retos futuros 147

6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
6.2. Retos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
A. Acrónimos 151
B. Ericsson IMS Common System 4.1 157

C. Códigos del servicio de ejemplo 163
C.1. Servlet de la aplicación: Servlet.java . . . . . . . . . . . . . . . . . . . 163
C.2. Cliente de la aplicación: Cliente.java . . . . . . . . . . . . . . . . . . 165
C.3. Cuadros de diálogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
C.3.1. Diálogo principal: Dialogo.java . . . . . . . . . . . . . . . . . . 172
C.3.2. DialogoMensajes.java . . . . . . . . . . . . . . . . . . . . . . . 173
C.4. Adaptadores de la ICP . . . . . . . . . . . . . . . . . . . . . . . . . . 175
C.4.1. PlatformAdapter.java . . . . . . . . . . . . . . . . . . . . . . . 175
C.4.2. ProfileAdapter.java . . . . . . . . . . . . . . . . . . . . . . . . 175
C.4.3. ServiceAdapter.java . . . . . . . . . . . . . . . . . . . . . . . . 176
C.4.4. SessionAdapter.java . . . . . . . . . . . . . . . . . . . . . . . . 178
Bibliografía 183
D. Agradecimientos 187
Índice de figuras
2.1. IMS hacia la convergencia de redes All-IP . . . . . . . . . . . . . . . 7

2.2. Separación funcional de IMS . . . . . . . . . . . . . . . . . . . . . . . 15
2.3. Ejemplo de un mensaje SDP como descripción de una sesión multimedia. 18
2.4. Arquitectura del 3GPP Release 5 donde se introduce por primera vez
el subsistema IMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5. Elementos de la arquitectura de IMS agrupados en cinco grandes
funcionalidades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6. Requerimientos para el funcionamiento en IMS . . . . . . . . . . . . . 27
2.7. Procedimiento de registro de un terminal IMS en la red. . . . . . . . 30
2.8. Diagrama de establecimiento de sesión en un roaming total. . . . . . 31
2.9. Paso de mensajes en el establecimiento de sesión. . . . . . . . . . . . 35
2.10. Tipos de ASs y sus interfaces . . . . . . . . . . . . . . . . . . . . . . 38
2.11. AS actuando como un SIP UA y proveyendo servicios al usuario (Alice). 39
2.12. AS actuando como un servidor SIP Proxy añadiendo lógica de servicio
y reencaminando las peticiones con el correspondiente valor añadido. 40
2.13. El AS B2BUA como dos UAs conectadas bajo una lógica de servicio. 40
2.14. Diagrama de establecimiento de sesión en un roaming total y provisión
de servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.15. Estructura simplificada de un perfil de usuario almacenado en el HSS. 43
2.16. Estructura de los initial Filter Criteria. . . . . . . . . . . . . . . . . . 44
2.17. Fichero XML que describe el perfil del usuario sip:[email protected]. 46
2.18. Establecimiento de sesión hacia una red PSTN. . . . . . . . . . . . . 47
2.19. Establecimiento de sesión desde una red PSTN hacia IMS. . . . . . . 48
2.20. Servicios IMS organizados según necesidad y movilidad . . . . . . . . 49
3.1. Esquema general de los bloques que componen el IMS Developer

Suite. Fuente: RADVISION . . . . . . . . . . . . . . . . . . . . . . . 54
3.2. Ventana del workbench del SDS . . . . . . . . . . . . . . . . . . . . . 58
3.3. Planificación de las distintas versiones del SDS junto con sus
capacidades y estado de release. Fuente: Ericsson. . . . . . . . . . . . 60
3.4. Ventana del Dynamic SIP/Web Project Wizard . . . . . . . . . . . . 63
3.5. Ventana de facets del proyecto . . . . . . . . . . . . . . . . . . . . . . 64
3.6. Definición del SIP Servlet . . . . . . . . . . . . . . . . . . . . . . . . 65
3.7. Definición del SIP Listener . . . . . . . . . . . . . . . . . . . . . . . . 65
3.8. Definición del fichero de despliegue SIP en su design window . . . . . 66
3.9. Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.10. Ventana del debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.11. Ventana del conversor de aplicaciones heredadas de otras versiones . . 68
ix
3.12. Launcher de los elementos de la red para inicializarlos o detenerlos
en el entorno de simulación. . . . . . . . . . . . . . . . . . . . . . . . 69
3.13. Visual Network con todos sus nodos tanto de red como de cliente (el
emulador de Symbian) y el menú de interacción gráfica. . . . . . . . . 69
3.14. Visual Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.15. Menú cliente del SDS, con el acceso al SIP Test Agent y el ATF. . . . 71
3.16. SIP Test Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.17. El Automated Testing Framework (ATF) . . . . . . . . . . . . . . . . 72
3.18. El asistente o wizard para aplicaciones cliente sobre ICP . . . . . . . 73
3.19. El entorno de desarrollo del SDS con el S60 C++ Carbide integrado. 75
3.20. Asistente para la instalación de la aplicación cliente en Windows. . . 76
3.21. Un ejemplo de Javadoc: La API para clientes IMS sobre IJCU basados
en Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.22. Visión del programador, con la complejidad de la arquitectura de red
“oculta” bajo el esquema de desarrollo de servicios. . . . . . . . . . . 81
3.23. Esquema de la implementación de la ICP en la arquitectura de capas
de IMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.24. Esquema general de la arquitectura de la ICP versión 4.1. Fuente:
Ericsson. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.25. Componentes detallados de la capa de abstracción o abstraction layer. 85
3.26. Esquema simplificado de la arquitectura horizontal de la IMS Client
Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.27. SDS posibilita IMS en teléfonos basados en JME MIDP/CLDC.
Fuente: Ericsson. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.28. Características de la API JSR 281 soportadas por la IJCU. Fuente:
Ericsson. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.29. Principales parámetros configurables (“preferencias”) del CSCF
simulado del SDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.30. Interfaz gráfica del BGCF simulado . . . . . . . . . . . . . . . . . . . 103
3.31. Vista general de la estructura del SDS desde el punto de vista de las
APIs y la plataforma ICP. . . . . . . . . . . . . . . . . . . . . . . . . 106
3.32. Pantallas de los correspondientes emuladores de teléfonos Symbian
UIQ, Symbian S60 y teléfonos JavaME. . . . . . . . . . . . . . . . . . 107
4.1. Beneficios para el usuario de las aplicaciones IMS. . . . . . . . . . . . 113

4.2. IMS Communication Services: El uso de APIs en los extremos de la
comunicación. Fuente: Ericsson. . . . . . . . . . . . . . . . . . . . . . 114
4.3. Visión general de los CoSe y sus mecanismos de soporte, servicios y
estandarización de las interfaces. Fuente: Ericsson. . . . . . . . . . . . 115
4.4. Ciclo de vida completo de una aplicación. . . . . . . . . . . . . . . . . 117
4.5. Primera fase: programar, testar, y simular extremo a extremo en PCs
con simuladores de IMS SDS. Fuente: Ericsson. . . . . . . . . . . . . 118
4.6. Primera fase (variante con terminales reales): programar, testar, y
simular extremo a extremo en PCs con simuladores de IMS SDS pero
haciendo uso de dispositivos y redes de acceso reales para acceder al
núcleo IMS simulado. Fuente: Ericsson. . . . . . . . . . . . . . . . . . 119
4.7. Segunda fase: test y pruebas de usuario extremo a extremo con
dispositivos y redes reales. Fuente: Ericsson. . . . . . . . . . . . . . . 120
4.8. Terminal de pruebas Sony Ericsson M600 utilizado en el proyecto. . . 121
4.9. Terminal de pruebas Sony Ericsson P1i utilizado en el proyecto. . . . 121
4.10. Arquitectura de la solución de Octopus para el testeo remoto de
aplicaciones y servicios IMS. Fuente: Octopus Network. . . . . . . . . 123
4.11. Tercera fase: despliegue en servidores comerciales. Fuente: Ericsson. . 124
4.12. Esquema de las soluciones comerciales del área Ericsson IMS,
estructuradas en soluciones, productos y servicios. Fuente: Ericsson. . 125
4.13. El bastidor BYB 501 que aloja los elementos del core real de Ericsson
para testeos y pruebas. . . . . . . . . . . . . . . . . . . . . . . . . . . 126
4.14. Arquitectura del entorno real de Ericsson. Fuente: Ericsson. . . . . . 127
5.1. Arquitectura de IMS donde se aprecia el papel de los servidores Parlay

X de servicios Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.2. El OSA Application Server en la arquitectura del IMS. . . . . . . . . 136
5.3. IMS se concibe como una arquitectura de control de servicios
horizontal, con cabida para distintas filosofías de creación de servicios
y distintos escenarios de interacción con el núcleo de la red. . . . . . . 137
5.4. Despliegue de aplicaciones IMS sobre un servidor Websphere de IBM.
Fuente: IBM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.5. Nueva cadena de valor de los servicios de telecomunicaciones. Fuente:
gaptel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
PROYECTO FIN DE CARRERA
1. INTRODUCCIÓN
1.1 Motivación
Hoy en día la sociedad es testigo de una evolución hacia una nueva cultura de
comunicación. De la mano de Internet nacen novedosos servicios que frecuentemente
marcan tendencias y revolucionan el mercado y los hábitos de la llamada Sociedad
de la Información. Claros ejemplos de estos servicios han sido, y son hoy por
hoy, la mensajería instantánea [1], el intercambio de vídeos, y datos en general,
chat y videoconferencia con servicios de presencia o las redes sociales [2]. Las
comunicaciones giran cada vez más hacia el intercambio de las experiencias del día
a día: en cualquier lugar, en cualquier momento y a través de cualquier dispositivo.
Al mismo tiempo, uno de los pilares básicos en el desarrollo de las telecomunica-
ciones ha sido el alcanzar acuerdos comunes y globales para servicios como el de
la telefonía o los mensajes cortos, Short Message Service (SMS). Es por ello que
la interoperabilidad entre operadores, redes y dispositivos es necesaria para que se
produzca una gran acogida de un nuevo servicio.
Las redes de tercera generación (3G) persiguen la unión de los dos actores que
revolucionaron el mundo de las comunicaciones: las redes de Comunicaciones Móviles
e Internet. Los operadores de telecomunicación fueron conscientes de que había
que seguir apostando por este modelo de evolución: creando alianzas en el plano
de estandarización de las redes y aprovechando las enormes oportunidades que
presentaban los servicios derivados de la nueva cultura de comunicación. El IP
Multimedia Subsystem, IMS es el factor clave dentro de la arquitectura de
las redes 3G que hace posible proporcionar acceso móvil a todos los servicios que
Internet pone a disposición de los usuarios.
IMS nació para sacar partido a lo mejor de estos dos mundos — la calidad e
interoperabilidad de las redes de telecomunicación con el rápido, y en constante
innovación, desarrollo de Internet —. IMS lo consigue permitiendo que las
comunidades de desarrollo de aplicaciones aprovechen las capacidades de la
industria de las telecomunicaciones. Todo ello sin dejar de proveer los servicios que
tradicionalmente han venido reportando beneficios a los operadores, como son la
telefonía y la mensajería.
IMS ofrece una solución estándar para proporcionar servicios al consumidor y a
la empresa, basados en la tecnología IP, y posibilitando el acceso a estos servicios
desde cualquier dispositivo conectado a cualquier red fija o móvil.
Todo ello convierte a IMS en el punto de partida de la evolución de las redes
actuales hacia una única, basada en el principio de all-IP, donde todos los servicios
(mensajería, telefonía, etc.) y medios (voz, vídeo, imágenes, texto, etc.) se integren
1
1.2. OBJETIVOS
en una misma experiencia de usuario.

Para el consumidor, IMS da paso a las comunicaciones que, de una manera
transparente combinan sesiones de voz en curso con otros elementos multimedia
(compartir vídeo o algún documento mientras se habla, por ejemplo). O, por
otro lado, IMS permite enriquecer aplicaciones compartidas con comunicación por
voz (por ejemplo el poder hablar mientras se desarrolla una partida de un juego
multijugador). Asimismo, será posible cambiar el modo de comunicación de una
sesión en curso de una manera dinámica, sencilla y sin provocar interrupción alguna;
en contraste con los modos de comunicación más o menos fijos existentes en la
actualidad donde por ejemplo para pasar de una llamada de voz a una videollamada
es preciso colgar y volver a entablar una nueva comunicación, esta vez con vídeo y
voz.
1.2 Objetivos
Este Proyecto Fin de Carrera nace de la necesidad de aglutinar en un mismo
documento distintas visiones sobre una tecnología tan prometedora como es el
IP Multimedia Subsystem (IMS) de forma que se proporcione un conocimiento
global acerca de por qué surge, en qué consiste, cómo es posible crear y desplegar
servicios IMS y qué consecuencias atañe para todos los agentes situados en torno a
esta tecnología, desde las operadoras de telecomunicaciones hasta el usuario final,
pasando por proveedores de servicios y contenidos.
Por ello, el objetivo principal de este proyecto es llevar a cabo un estado del arte
del IP Multimedia Subsystem (IMS) desde tres perspectivas: el punto de vista del
IMS como estándar teórico, la implementación de la infraestructura y los
servicios IMS y la perspectiva comercial de la tecnología.
El estudio de la especificación técnica de IMS es necesario para entender todos sus
beneficios y requerimientos, así como para abordar con garantías las alternativas de
implementación y planes comerciales y de marketing. Es por tanto que se comienza
con este estudio, tratando de sintetizar de una manera elocuente y completa el
complejo estándar de IMS; descrito por más de cien [3] especificaciones técnicas
(Technical Specification (TS)) pero con pocas referencias básicas por el momento
(principalmente [4], [5], y [6]).
Posteriormente, es preciso explorar diferentes alternativas de desarrollo de
aplicaciones y servicios IMS que saquen partido a esta versátil y potente arquitectura
de red. Del mismo modo, se hace necesario estudiar con mayor profusión una de las
alternativas evaluadas, tratando de proporcionar un enfoque práctico a este análisis.
La alternativa elegida, tiene que estar refrendada por su fidelidad al estándar descrito
por el 3GPP. Para ilustrar este mayor o menor compromiso entre la implementación
real y la descripción teórica es ineludible presentar la nueva metodología de creación
de servicios IMS, ejemplificada con la opción elegida.
Finalmente un análisis comercial cubre la tercera perspectiva de la tecnología. Este
análisis requiere a su vez dos puntos de vista: Por un lado, una valoración de las
2
alternativas de despliegue comercial de un servicio, seleccionando y definiendo el

modelo de implementación óptimo. Y, por otra parte, es preciso que una tecnología
con perspectivas tan comerciales como IMS dé origen a nuevos modelos de negocio
cuyo estudio es otro de los objetivos principales de este proyecto. Y, en concreto, el
estatus actual y futuro del operador en esta nueva situación de convergencia entre
múltiples actores y tecnologías.
1.3 Organización de la memoria

El documento que describe este Proyecto Fin de Carrera está organizado de una
forma similar a la de la propia tecnología que aborda. Se van presentando modelos
de abstracción ganando en perspectiva y yendo desde el nivel más técnico hasta
el punto de vista comercial. Por ello, el proyecto se estructura en seis capítulos,
incluyendo el presente, que se presentan a continuación de manera que se pueda
tener brevemente una visión general de este.
1. Introducción. La memoria del proyecto comienza con la motivación, a modo

de descripción breve de lo que supone el IMS dentro de la Sociedad de la
Información. Se describen los objetivos principales que se persiguen en su
realización y se incluye, además la presente organización de la memoria.
2. Introducción teórica al IP Multimedia Subsystem, IMS. En este
capítulo se describe el estándar del IMS, desde sus antecedentes y justificación
hasta los servicios que traerá consigo, pasando por un profundo — pero
tratando ser lo más intuitivo posible — análisis de los protocolos utilizados y
la arquitectura de red.
3. Un entorno de desarrollo: el SDS de c Ericsson. El documento
recoge en este capítulo gran parte de su contenido práctico al describir
con profusión la herramienta de desarrollo de aplicaciones y servicios IMS
más completa. Se hace un repaso de su estructura en distintos “entornos”
y perspectivas: entornos de diseño, ejecución, simulación (describiendo los
diferentes emuladores disponibles) y testeo. Asimismo se incluye un estudio
de las APIs desarrolladas para IMS, y guías para la creación de aplicaciones y
servicios IMS en el SDS.
4. Creación de un servicio IMS con el SDS. El entorno de implementación
del capítulo anterior no está exento de limitaciones. Por ello, en este capítulo se
analizan las ventajas e inconvenientes de este software, así como las principales
divergencias entre el modelo teórico del estándar del Third Generation
Partnership Project (3GPP) y la herramienta de Ericsson: las carencias de
ésta y sus posibles mejoras. Además, este capítulo describe paso a paso la
creación de un servicio IMS en sus distintas fases, tratando siempre cada etapa
con perspectiva, incluyendo varias posibilidades y análisis de éstas.
5. Propuesta de despliegue comercial de un servicio y plan de
explotación. En este punto se tiene ya el conocimiento teórico y práctico
suficiente, por lo que se pasa a un nivel de abstracción superior y se
3
1.3. ORGANIZACIÓN DE LA MEMORIA
describe una propuesta del despliegue comercial de un servicio IMS desde

diferentes puntos de vista: del operador, del usuario, de las industrias de
las Telecomunicaciones (“las telco”) e Internet (“las punto com”); siempre
tratando de hallar la solución óptima y más productiva desde el conocimiento
de la tecnología y el estado del arte del mercado. Además, se ofrece una
perspectiva sobre el modelo de explotación en IMS que trata la necesidad
de que los operadores cambien el modelo de explotación de sus redes para
adaptarse a los nuevos modelos de negocio y a la evolución de los mercados; y
se realiza una propuesta para la adopción del nuevo modelo de cara a que los
operadores no pierdan el control de la nueva cadena de valor instaurada.
6. Conclusiones y retos futuros. Se ha desarrollado este capítulo para
concentrar las conclusiones más importantes a raíz del estudio y las pruebas
realizadas durante la elaboración del proyecto. Y para concluir con la memoria
se indican las líneas de trabajo por donde podrán continuar los estudios
posteriores, así como la mención de otras propuestas que no tuvieron un estudio
pormenorizado dentro del alcance de este proyecto.
4
2. INTRODUCCIÓN TEÓRICA AL
IP MULTIMEDIA SUBSYSTEM,
IMS
2.1 Antecedentes
En las Comunicaciones Móviles, Global System for Mobile communication (GSM) el
actual sistema de Segunda Generación (2G)1 está en una fase madura, la tecnología
es robusta, bien conocida y probada, las redes están desplegadas al máximo de
su cobertura y prácticamente se ha logrado una penetración total en el público.
Los circuitos en los que se basa GSM están optimizados para transportar voz y
eventualmente datos a una velocidad limitada a decenas de Kbps. Sin embargo, la
demanda de cada vez más ancho de banda para la implementación de nuevos servicios
saturan la capacidad de red de GSM. Para ello, se desarrollaron General Packet
Radio Service (GPRS) y Universal Mobile Telecommunications System (UMTS),
estándares que denominados 2.5G y 3G han ido añadiéndole cada vez más capacidad
a la red móvil. En estos sistemas se introduce el concepto de dominio, con lo que el
núcleo de su arquitectura queda dividida en dos de ellos: el dominio de conmutación
de circuitos, Circuit Switched (CS) y el dominio de conmutación de paquetes, Packet
Switched (PS).
El dominio CS de conmutación de circuitos presente en GPRS y UMTS es
una evolución de la tecnología usada en las redes de segunda generación (2G).
Los circuitos en este dominio, como ya se mencionó con anterioridad, fueron
diseñados para transportar casi exclusivamente voz, aunque pueden ser usados
para transportar mensajes instantáneos y otros pequeños datos. La tendencia
actual, y las redes celulares la siguen, es sustituir este dominio por tecnología
de conmutación de paquetes.
El dominio PS de conmutación de paquetes proporciona acceso IP a Internet.
Mientras los terminales 2G pueden actuar como un módem para transmitir
paquetes IP sobre circuitos, los terminales 2.5G y 3G usan tecnología nativa
de conmutación de paquetes para interpretar comunicaciones de datos. De
esta forma, las transmisiones de datos son mucho más rápidas y se multiplica
el ancho de banda disponible para el acceso a Internet. Los usuarios pueden
acceder al Web, consultar el correo electrónico, descargar videos, y realizar
muchas otras tareas de una manera similar a lo que pueden hacer sobre
1
Se especifica GSM como sistema de Segunda Generación (2G) por estar siempre centrados en
las Comunicaciones Móviles en Europa, sin embargo, el alcance de los fenómenos descritos es,
y ha sido siempre global.
5
2.2. JUSTIFICACIÓN: ¿POR QUÉ IMS?
cualquier otra conexión, como Asymmetric Digital Subscriber Loop (ADSL) o

cable.
No obstante, el estándar 3G que más capacidad ofrecía, UMTS, ha tenido una lenta
y tardía introducción. Por ejemplo, desde que en España se adjudicaran las cuatro
licencias allá por el año 2000, han tenido que pasar cuatro años (en los grandes
núcleos de población, ya que en las zonas más despobladas y rurales el retraso
ha sido aún mayor) para poder ver una infraestructura que ofreciera capacidades
de ancho de banda y condiciones aceptables en relación con lo establecido por la
especificación.
Hoy en día es posible calificar el estado del despliegue de la tecnología UMTS como
avanzado. Sin embargo, fueron tales las expectativas que despertó, que analizando
la evolución desde su fase de especificación hasta la actualidad, no se observa más
que una desaceleración en el despliegue de esta tecnología tan prometedora. Quizás
fuera la incompletitud o ambigüedad de las especificaciones del Third Generation
Partnership Project (3GPP). O bien la desorbitada inversión que hicieron las
compañías en los concursos de adjudicación de las bandas del espectro. Inversión
desproporcionada frente a la falta de amortización por la ausencia del despligue
tecnológico por un lado y de servicios (es obvio que sin tecnología de acceso no hay
oferta de servicios) por otro. Fuera cual fuera la razón predominante del retraso de
UMTS se intuye — sin realizar un análisis estratégico detallado — que al fin y al
cabo, la razón del éxito de una tecnología es la demanda por parte del usuario.
Pero la aparición de IMS no se queda ahí. IMS es el gran catalizador de la
convergencia de redes en torno al All-IP. En primer lugar, recoge en su especificación
multitud de pasarelas hacia usuarios situados en otras redes de acceso, con la
particularidad de que el plano de transporte se lleva a cabo mediante redes de
tránsito IP2 . Y, en segundo lugar, estas otras redes de acceso (cada vez con una
mayor capacidad y un menor coste) necesitan de los servicios IMS para atraer a los
usuarios y así encontrar un modelo de negocio. Es posible establecer, como se ilustra
en la figura 2.1 un círculo All-IP - Servicios IMS
2.2 Justificación: ¿Por qué IMS?

En el repaso a la motivación del proyecto y los antecedentes de IMS se han dado
vueltas sobre la idea de IMS como proveedor de los servicios de Internet en movilidad
y en todo momento haciendo uso de tecnologías de las redes móviles. Por otro lado,
los operadores actualmente ya proveen un gran rango de servicios, así como un acceso
a Internet haciendo uso del dominio de paquetes de GPRS y UMTS. Es en este punto
donde se hace uso de lo explicado en secciones anteriores sobre la convergencia de
redes. El contar con un dominio de paquetes en las redes 3G significaba que cualquier
usuario, por ejemplo, podía instalar un cliente VoIP en su terminal 3G y establecer
2
Cuando se habla de plano de transporte no se refiere a la capa de transporte del modelo TCP/IP,
implementada por los protocolos TCP o UDP. Se refiere al modelo de separación funcional en
redes telemáticas de nueva generación, NGN: plano de servicios, plano de control y plano de
transporte.
6
' $
Figura 2.1.: IMS hacia la conver-

gencia de redes All-
IP
& %
conversaciones VoIP sobre el dominio conmutación de paquetes. Entonces, al tener

ya un acceso a los servicios de Internet a través del dominio de paquetes de las redes
móviles actuales, surge la pregunta: ¿por qué IMS? ¿Para qué se necesita?
La respuesta a la pregunta se levanta sobre tres pilares: QoS (Quality of Service,
calidad de servicio), tarificación, e integración de servicios. A continuación se
desarrollan los tres factores de manera que la adopción de IMS quede elocuentemente
justificada:
1. Calidad de servicio (QoS). En el dominio de conmutación de paquetes

presente en las redes UMTS se lleva a cabo una provisión de servicios
multimedia en tiempo real del tipo best effort 3 sin garantías de QoS. Un
ejemplo de las desventajas de la falta de contratos de QoS puede ser el de la
llamada VoIP desde un cliente instalado en un terminal de tercera generación
que haga uso de la red UMTS. En un momento de la conversación es posible
escuchar la voz de la otra persona perfectamente clara y justo después resultar
ininteligible, causando una mala experiencia de usuario.
Es por ello que una de las razones para lanzar IMS fue la de proporcionar la
QoS necesaria para poder disfrutar con garantías de una sesión multimedia en
3
Un servicio best effort es precisamente lo opuesto a un servicio con calidad de servicio, QoS.
En los servicios best effort la red no ofrece garantías de ancho de banda ni de retrasos en la
conexión que realiza el usuario para disfrutar del servicio determinado. La QoS es justamente
lo contrario, ya que para un servicio con QoS, la red garantiza ciertas características en la
conexión de un usuario.
7
2.2. JUSTIFICACIÓN: ¿POR QUÉ IMS?
tiempo real. En el momento de establecer la sesión es IMS quien se encarga de

proveer una QoS a la sesión de tal modo que los usuarios saben de antemano
las condiciones en las que se llevará a cabo la comunicación.
2. Tarificación. Hasta ahora, la tarificación de servicios de datos se venía
realizando por número de bytes transferidos durante la sesión. Así, por ejemplo,
una videollamada podía generar grandes gastos para el usuario. De la misma
manera, esos bytes podían haber sido de un correo electrónico o de una página
web, que el operador no hubiera podido distinguirlo. Por tanto, de ahí que el
operador no pueda crear una oferta según servicios.
Es éste un aspecto básico en el desarrollo de los distintos modelos de
negocio que puede traer consigo IMS, ya que se crea la posibilidad de
establecer esquemas de tarificación más versátiles. Por ejemplo: tarifa plana
de navegación web, precio fijo por cada mensaje instantáneo, precio único
de videollamada, etc. Todos ellos son independientes del número de bytes
que circulen por la red. De este modo se logran ventajas para el usuario,
al poder disponer de tarifas más beneficiosas, y para el operador, dado que
esta versatilidad en la tarificación repercute en el éxito de la oferta comercial
de sus servicios.
3. Integración de servicios. La tercera razón esgrimida para llevar a cabo IMS
fue la de proporcionar interfaces estándar a los desarrolladores de servicios.
De este modo, los operadores se aprovechan de la poderosa industria de
creación de servicios, permitiendo que toda la comunidad de desarrolladores
conozca qué requiere IMS de ellos para que estos desarrollen los servicios
IMS. De este modo, los operadores pueden usar servicios de terceros,
combinarlos, integrarlos con servicios ya disponibles y proporcionar al usuario
uno completamente nuevo y mejor adaptado. El ejemplo clásico en la literatura
es el del operador que dispone de un servicio de mensajería escrita como el
SMS. Por otro lado, un desarrollador independiente conoce las interfaces que
IMS le ofrece y desarrolla un conversor texto a voz text-to-speech. El operador
puede combinar estos dos servicios e integrarlos en una aplicación para la
lectura de mensajes escritos para invidentes.
La integración de redes puede traducirse como el paso de la concepción de un
servicio, una red a N servicios, una red. Siguiendo con el anterior ejemplo, el
servicio de mensajes cortos, SMS, precisaba de elementos propios en la red en
la arquitectura de red de segunda generación. Sin embargo, en IMS, es IMS la
propia red y son N los servicios que se acomodan sin variar los elementos de
la arquitectura.
Hay que añadir que algunos autores incluyen un cuarto pilar: el del uso de URIs
(Uniform Resource Identifier) en vez de números de teléfono [7] para identificar
a usuarios, servicios y nodos. Manejar nombres al estilo de direcciones de correo
electrónico supone una asociación directa con el usuario mientras que los números
de teléfono son prácticamente imposibles de recordar.
En conclusión, el objetivo de IMS no es sólo proporcionar nuevos e innovadores
servicios basados en el éxito de Internet y disponibles en un terminal móvil. El
8
objetivo real es el de proporcionar todos los servicios que se pueden encontrar en

Internet, disponibles en movilidad, y con capacidad de roaming 4 entre operadores.
De este modo, no existirá diferencia entre una sesión VoIP entre dos usuarios IMS,
entre un usuario IMS y un usuario conectado a Internet ni entre dos usuarios en
Internet. Todas estas sesiones estarán haciendo uso del mismo protocolo.
Asimismo, las interfaces disponibles para desarrolladores antes citadas están
basadas también en protocolos de Internet. Ésta es la auténtica razón por la que
se puede afirmar que IMS es el elemento clave para la convergencia entre el mundo
de las Comunicaciones Móviles e Internet: emplea tecnologías celulares para así
disfrutar de acceso ubicuo a tecnologías de Internet donde se puedan encontrar
servicios atractivos.
A pesar de todas estas características de los servicios que IMS hace posible,
IMS no define las aplicaciones o servicios que pueden ofertarse el usuario final,
sino la infraestructura y capacidades del servicio que los operadores o proveedores
de servicio pueden emplear para construir sus propias aplicaciones y producir su
oferta de servicios. El operador IMS puede elegir orquestar los servicios de forma
independiente, combinada o en multitud de variantes. Como ejemplo se pueden poner
los dos grupos siguientes de servicios finales:
Los denominados servicios heredados (las llamadas básicas de voz, la

mensajería textual, la mensajería multimedia, el correo electrónico, etc.), en
los cuales el usuario percibirá la misma calidad que cuando se prestan a través
de los sistemas tradicionales.
Los servicios multimedia avanzados. En este tipo de servicios se incluyen
la videoconferencia; la audioconferencia con audio mono o estéreo; la
videoconferencia para personas sordas, vídeo más texto en tiempo real; la
multiconferencia en vídeo, audio o texto; la difusión de contenidos de televisión
o radio; el vídeo bajo demanda conocido como Video on Demand (VoD);
la mensajería instantánea y el chat multimedia con servicios de presencia y
grupos Presence and Group Management (PGM) integrados; los videojuegos
interactivos multiusuario; el servicio Push-To-Talk over Cellular (PoC), un
símil al walkie-talkie actual; etc.
En este sentido, IMS no impone límites, son la capacidad de la red de acceso y las
características de los terminales las que fijan las restricciones.
4
El roaming consiste en ingresar en una red de un operador distinto al propio y seguir disfrutando
de la misma experiencia de usuario de una manera totalmente transparente. En el roaming
surgen dos conceptos: Home network, red doméstica o red de servicio local, donde el usuario
contrató sus servicios y opera habitualmente. Y la visited network o red visitada, donde el
usuario se encuentra en itinerancia o roaming. Popularmente se recurren a los términos en inglés
y en este proyecto se usarán conjuntamente con la denominación en español.
9
2.3. TENDENCIAS TODO-IP (ALL-IP) EN 3G E IMS Y CONVERGENCIA DEL IETF CON 3GPP
2.3 Tendencias Todo-IP (All-IP) en 3G e IMS y

convergencia del IETF con 3GPP
2.3.1 Tendencias hacia la convergencia: el All-IP
Si se analiza la trayectoria de los servicios de datos sobre las redes GPRS y
UMTS [8] se extraen resultados decepcionantes si se comparan el boom que se
produjo con servicios tan básicos e incluso denostados en un principio como el
SMS [9], o el crecimiento vertiginoso en las ventas de teléfonos móviles con cámara
integrada. Son por tanto, estos ejemplos de éxito los que dan la certeza sobre el
dinamismo y rentabilidad del mercado de las Comunicaciones Móviles, pero que
hacen replantearse aún más los casos como los de GPRS y UMTS que no han
cumplido sus expectativas: Excelentes tecnologías sin la salida comercial ni las
aplicaciones atractivas para los usuarios vaticinadas en un principio. Estas razones
hacen mirar a la industria de las Comunicaciones Móviles hacia el éxito de Internet,
creando una senda de convergencia entre ambos mundos.
Por ello se introduce en el seno del 3GPP el concepto de All-IP. El All-IP es
una visión de la industria sobre la arquitectura de las redes de comunicaciones
futuras, que ofrece diversos modos de acceso – denominado en la bibliografía como
multiacceso, agnosticismo en el acceso o IMS Multi-Access (IMA) en inglés [10] –
que se integran de forma transparente en una capa de red basada en el protocolo
de Internet, IP. Estas futuras redes de comunicaciones futuras giran en torno al
concepto de Red de Nueva (o Siguiente) Generación, que en la literatura anglosajona
se encuentra como New Generation Networking o NGN, siglas que se usarán en
adelante. El modelo de NGN se plantea como la solución que permitirá llevar a cabo
las propuestas del modelo All-IP de forma adecuada. Se presenta, por tanto, como
una solución para la convergencia de las redes con interfaces de alta velocidad, con
seguridad y calidad garantizadas y que facilita el despliegue de los servicios, tanto
actuales como futuros. El objetivo fundamental para los operadores será optimizar
las inversiones y asegurar unos rápidos retornos de éstas.
No obstante, lograr una convergencia tecnológica en torno a la opción Todo IP no
garantiza que esa evolución se cristalice en un aumento del tráfico de datos en las
redes móviles. De hecho, para el operador supone una reducción en los costes de
infraestructura, una mejor escalabilidad y capilaridad de la red y una simplificación
de la operación y mantenimiento. El modelo Todo IP no garantiza unos mayores
beneficios económicos porque no aumenta por sí mismo el uso de los servicios de
datos.
Es por todo ello que el 3GPP decidió evolucionar desde su versión o release 99
hacia la 3GPP Release 5 o R5 . En la llamada 3GPP Release 99, se dispone un
acceso IP en movilidad, sin embargo en la realidad los servicios más empleados por
los usuarios móviles siguen siendo los tradicionales (voz y SMS), los servicios de datos
ganan en uso y adeptos, pero sin reportar los beneficios esperados a los operadores
ni impulsando la creación de un gran número de servicios. Son estas carencias las
que la 3GPP R5 pretende subsanar mediante la inclusión de IMS al núcleo de la red
móvil. Como se puede resumir de la especificación, IMS es un sistema de control
10
de sesión diseñado con tecnologías de Internet adaptadas al mundo móvil

que permite proporcionar aplicaciones móviles multimedia sobre conmutación de
paquetes. Además, el papel de IMS como proveedor de capacidades para nuevos
servicios que resumía el gráfico de la figura 2.1 hace posible el aprovechamiento de las
ventajas que ofrece All-IP a los operadores y permitiendo ofrecer servicios atractivos
que atrapen a los abonados móviles en esta nueva cultura de la comunicación a través
de los datos.
2.3.2 Sinergias entre grupos de estandarización: el IETF con el

3GPP
Como se ha mencionado con anterioridad, IMS tiene como objetivo el uso de los
protocolos de Internet. Sin embargo, estos protocolos no estaban a priori preparados
para funcionar en la arquitectura de IMS, no estaban adaptados al entorno de
redes móviles. Existían incluso situaciones que el 3GPP5 planteaba para dar más
funcionalidades a IMS, pero ningún estándar del Internet Engineering Task Force
(IETF) cubría. Sin embargo la intención del 3GPP era la de aprovechar todas las
ventajas de los servicios que se creaban para Internet para portarlos de una manera
cómoda al entorno móvil. Establecer una colaboración con el IETF era mucho más
sensato que modificar los protocolos de Internet por sí mismos, por lo que sellaron
una colaboración [11]. La meta parecía clara: encontrar soluciones que cumplieran
los requisitos de IMS y que al mismo tiempo fueran lo suficientemente generales
como para adaptarse a otros entornos. Hoy por hoy es posible ver el fruto de
esta colaboración reflejado en RFCs que en muchos casos ni mencionan a IMS,
cumpliendo así el objetivo de portabilidad y aplicabilidad general. No son normas
específicas para IMS, son extensiones que hacen que algunos protocolos de Internet
existentes tengan una mayor proyección en el futuro, adaptándose de este modo a
las tendencias de hoy en día.
Las sinergias producidas de esta colaboración se resumen en tres áreas:
Internet
Dentro de los protocolos de Internet se encuentran trabajos conjuntos en la
especificación de IPv6 y DNS:
El grupo de trabajo encargado de desarrollar Internet Protocol version 6
(IPv6) incluyó unas pautas de cómo implementar este protocolo en un terminal
o host 6 móvil. Cuando se detecta que el terminal hace uso de un acceso
GPRS/UMTS el sistema sigue las pautas especificadas por el protocolo. Sin
5
No hay que olvidar que el 3GPP nació para evolucionar las especificaciones de GSM hacia
un sistema celular de tercera generación, mientras que el 3GPP2 tenía el mismo cometido,
pero partiendo de los sistemas norteamericanos y asiáticos de segunda generación (2G). Ya
que las especificaciones del IMS del 3GPP2 se basan en las del 3GPP, cuando se hable de
IMS en realidad se está haciendo referencia al 3GPP IMS, aunque a veces las diferencias sean
insignificantes.
6
Se hace referencia a host en el sentido de un equipo, máquina o terminal conectado a una red.
11
embargo, si el terminal accede desde una red móvil pero del tipo Wireless Local
Area Network (WLAN) — como se contempla en futuras releases del 3GPP
—, el protocolo trata al terminal como un host de Internet tradicional, como
si se tratara de un PC.
Respecto al Domain Name Server (DNS) existieron dudas de cómo se
llevaría a cabo el descubrimiento de los servidores de DNS en IMS. Se decidió
no usar Dynamic Host Configuration Protocol (DHCP), sino usar mecanismos
específicos para las redes de acceso 3G.
Área de Gestión y Operaciones (Operations and Management)

La mayoría de los esfuerzos en este área se concentraron en los protocolos Common
Open Policy Service (COPS) y Diameter. Se desarrollaron estándares y
borradores para cubrir las necesidades de las distintas interfaces relacionadas con
las políticas de tráfico (en el caso de COPS) y sobre las interfaces encargadas del
Authentication, Authorization and Accounting (AAA).
Área de transporte
Una vez se eligió Session Initiation Protocol (SIP) como protocolo de control
de sesión para IMS se construyó un equipo de trabajo para desarrollar el entonces
inmaduro protocolo de sesión para cumplir los requerimientos del 3GPP. Se llegó a
una RFC [12] que sin embargo no cubría aún los vastos objetivos de convergencia con
la red móvil. Para ello, el IETF construyó un grupo para encontrar los requerimientos
que aún le faltaban a SIP, priorizarlos y mandarlos al grupo de trabajo del protocolo,
que era y es el encargado de desarrollar las numerosas extensiones para hacer de SIP
un protocolo más completo y adaptado a las necesidades del 3GPP.
2.3.3 El 3GPP Release 5 y la génesis de los servicios IP Multimedia

IMS fue diseñado inicialmente en 3GPP Release 5 para su uso sobre el subsistema de
transporte la red móvil de tercera generación. El modelo teórico de las redes móviles
divide el sistema en diferentes dominios y planos. Así, IMS implementa el plano de
control de los servicios IP multimedia, mientras que GPRS/UMTS proporciona las
funciones de plano de transporte, tal como se puede ver en la figura 2.2. De esta
forma, la función de IMS en los servicios IP multimedia incorpora el procesado y
actuación sobre la señalización y el control de los recursos del plano transporte.
GPRS/UMTS se encarga de proporcionar conectividad IP dentro del dominio de la
red móvil, tanto para la señalización como para los datos multimedia de usuario.
Siguiendo la filosofía establecida en la separación funcional típica de UMTS y de
las redes IP, el flujo de datos correspondiente a la señalización viaja de forma
separada a los flujos de datos multimedia de usuario, proporcionando en ambos casos
GPRS/UMTS el servicio de transporte. Sin embargo, el flujo de señalización, que
tiene su origen y fin en los terminales de usuario participantes en el servicio, es
transferido vía IMS, al contrario de lo que ocurre con los datos de usuario
12
que se transfieren directamente entre los terminales sin atravesar el subsistema

IMS. Este concepto establecido en la arquitectura permite, fundamentalmente,
emplear tecnologías de Internet, y origina el atractivo de disponer de los servicios
IP multimedia. Por otro lado, como IMS fue diseñado para una red evolucionada de
GSM hereda ciertas cualidades intrínsecas del mundo móvil, como son:
Las sesiones interoperador. Los abonados de un operador IMS tienen la
posibilidad de cursar sesiones IP multimedia con abonados localizados en la red
3G IMS de otro operador. La arquitectura de IMS, las entidades funcionales
y sus protocolos, están diseñados para la interconexión con otros sistemas
IMS de otros operadores. En este caso, los flujos de datos de una sesión se
transportan por el sistema GPRS/UMTS en la red origen, por una red, o
redes, IP de tránsito interoperador y por la red GPRS/UMTS destino. En el
caso de las sesiones interoperador, los flujos de señalización siempre recorrerán
ambos sistemas IMS.
La itinerancia. IMS soporta la itinerancia de tipo nativo, lo que se define
como la capacidad del sistema de admitir y dar servicio a abonados de otros
operadores que emplean la misma tecnología, y con los que se tiene el acuerdo
de negocio pertinente. Cuando un abonado está en itinerancia, el subsistema
IMS visitado encamina la señalización del abonado itinerante hasta el IMS
nativo del abonado, desde donde se reencamina la sesión hacia su destino.
La interconexión con redes y servicios heredados. IMS contempla la
interconexión con las redes de circuitos Signaling System 7 (SS7) para
servicios de llamadas de voz. Por tanto, existen elementos IMS para el
interfuncionamiento entre las sesiones multimedia con los componentes de
audio y las redes Public Switched Telephone Network (PSTN), GSM o
el dominio de conmutación de circuitos de la propia red 3G. De esta
forma, los abonados con la innovadora tecnología IMS siempre podrán
seguir comunicándose con otros abonados no IMS. Asimismo, el sistema
esta diseñado para proporcionar interoperación con redes de circuitos que
admiten teleconferencias multimedia (por ejemplo, videollamadas), como
aquellas basadas en 3G-324M o H.324. La interconexión con las redes IP
multimedia externas e Internet. La futura Internet albergará servicios IP
multimedia avanzados, especialmente para el caso de comunicaciones en
tiempo real o con altos requisitos de QoS. IMS incorpora componentes para
el interfuncionamiento con las redes IP multimedia externas, de forma que los
abonados IMS podrán mantener comunicaciones con los usuarios de la Internet
multimedia.
La seguridad integrada. Uno de los factores clave del éxito de GSM fue
que incorporaba intrínsecamente mecanismos de seguridad, soportados por
la tarjeta SIM. IMS requiere autenticación de abonado y especifica sus
propios mecanismos y arquitectura de seguridad, que son independientes de
los propios de UMTS. De este modo, la suscripción IMS está soportada por
una aplicación lógica llamada ISIM (IMS SIM) que ejecuta funciones de
autenticación de abonado durante su registro en IMS, además de contener
datos de la suscripción de abonado, de igual forma que la SIM en GSM y la
13
USIM (UMTS SIM) en 3G. La ISIM reside, junto con la aplicación USIM,
en la tarjeta inteligente física. Por tanto, un abonado que desee acceder a
IMS, en primer lugar deberá autenticarse y registrarse con el núcleo de red
UMTS empleando la USIM, y posteriormente autenticarse y registrarse con
IMS utilizando la ISIM.
La Calidad de Servicio (QoS). El subsistema 3G hace uso de la arquitectura
de QoS de GPRS/UMTS, que define una jerarquía de portadoras adecuadas
para servicios con diferentes requisitos de QoS. Por todo ello, se han definido
nuevas funciones e interfaces opcionales en la 3GPP Release 5 que permiten
que IMS controle y autorice el uso de recursos del subsistema de transporte
GPRS/UMTS. Estas funciones son opcionales, y, en caso de no estar presentes,
la asignación de recursos a las sesiones IMS se controlaría mediante los
mecanismos ordinarios propios de GPRS/UMTS y la suscripción de abonado
GPRS/UMTS.
La provisión de servicios. IMS posibilita un desarrollo rápido y simplificado
de servicios siguiendo el modelo Internet. La arquitectura IMS cuenta con
interfaces o pasarelas hacia servidores de aplicaciones. En lo que respecta a las
aplicaciones, éstas pueden modificar el transcurso de una sesión multimedia de
una forma muy similar a como lo hacen las aplicaciones de red inteligente, que
pueden actuar y modificar una llamada de voz, con la ventaja de la simplicidad
y facilidad del desarrollo de las aplicaciones web. De este modo se pueden
establecer una serie de criterios en la suscripción de usuario IMS, de forma que
el control de una sesión se traspase a un servidor de aplicaciones. Esto posibilita
la implementación de todos los servicios suplementarios tradicionales, así como
nuevos servicios avanzados. Por otro lado, IMS define componentes de pasarela
que interactúan con las plataformas del plano de servicios tradicional de la red
3G, como OSA y CAMEL7 . De esta forma, las aplicaciones heredadas OSA y
CAMEL pueden también actuar sobre las sesiones IP multimedia, permitiendo
la provisión de servicios IMS desarrollados por terceras partes.
La tarificación y facturación. En la tarificación de servicios IP multimedia
intervienen el sistema de facturación de GPRS/UMTS y el sistema de
facturación de IMS. Este último registra los datos relacionados con la
sesión IMS, tales como los usuarios implicados, la duración, los componentes
multimedia empleados y la QoS autorizada, y los asocia a los correspondientes
registros de tarificación de GPRS/UMTS que se originaron como consecuencia
del transporte de los flujos multimedia y la señalización de IMS en el plano
de transporte. De esta forma, es posible facturar los servicios según su
duración, contenidos, volumen de datos, destino de la sesión o las diferentes
combinaciones de los anteriores. Por otro lado, el sistema soporta tanto
tarificación online como offline, lo que se traduce en la facturación pospago
y prepago, necesaria para atender a todo el mercado de clientes potenciales.
7
Se verá el significado de estas siglas más adelante, en una descripción más detallada de la
arquitectura de red de IMS.
14
' $
Figura 2.2.: Separación funcional de IMS

& %
2.4 Protocolos utilizados en IMS

Hasta la inclusión de IMS en la arquitectura de la Release 5 del 3GPP, no existía
la reutilización de protocolos que se fomenta hoy día. Por aquel entonces, los
organismos hoy integrantes del 3GPP, desarrollaban los protocolos prácticamente
desde cero, como por ejemplo fue el caso de la ETSI con el GSM en Europa.
Con la decisión de basar IMS en protocolos IP desarrollados por el IETF, se dio
un paso de gigante en dos direcciones:
1. La reutilización de protocolos. El 3GPP, con el desarrollo de IMS aprovecha
la experiencia de organismos como el IETF o la ITU-T en el desarrollo
de protocolos robustos, reduciendo así tiempo y costes en el desarrollo y
estandarización.
2. La evolución y el desarrollo comercial de los protocolos del IETF.
2.4.1 Sesión
IMS es un subsistema fundamentado en sesiones8 multimedia y por ende requiere
de protocolos que describan y controlen dichas sesiones.
Control de sesión
Para el control de sesión se barajaron, en el seno del 3GPP tres protocolos,
obviamente basados en IP: el Bearer Independent Call Control (BICC) una
8
Aunque se haya mencionado el término de sesión en múltiples ocasiones, se refiere a aquellas
comunicaciones que van desde simples llamadas de voz, hasta complicados intercambios de
audio, vídeo y datos entre varias partes o incluso un intercambio de un mensaje instantáneo.
15
2.4. PROTOCOLOS UTILIZADOS EN IMS
evolución del ISDN User Part (ISUP) de la ITU-T; el H.323 también de la ITU-T;
o SIP, mencionado con anterioridad en la sección 1.4.2) del IETF. Finalmente se
eligió SIP como protocolo de control de sesión por la facilidad que aportaba en la
creación de nuevos servicios y su gran capacidad de extensión.
SIP es un protocolo para el establecimiento y gestión de sesiones multimedia sobre
redes IP. Basado en los dos protocolos de Internet más importantes – Simple Mail
Transfer Protocol (SMTP) (protocolo para el envío de correos electrónicos) y,
en mayor medida, HyperText Transfer Protocol (HTTP) (protocolo Web) – SIP
establece y gestiona sesiones extremo a extremo (e-2-e, end to end) sin diferenciar
la naturaleza de cada uno de los extremos (usuario o red). Para ello se nutre, además,
de toda la herencia que dejan los protocolos de Internet. En concreto, dado que SIP
tiene una estructura similar a la de HTTP (hasta el punto de compartir los códigos
de respuesta) SIP aprovecha la vasta comunidad de desarrolladores de aplicaciones
web para crear aplicaciones SIP, así como adopta todos los frameworks de servicios,
como por ejemplo los Java Servlets para HTTP9 .
SIP es el protocolo de señalización de IMS que aporta las funciones y capacidades
necesarias para el registro, establecimiento, mantenimiento y liberación de las
sesiones multimedia. Para IMS, SIP precisa ciertos requerimientos que adapten su
uso a las redes celulares de paquetes del 3GPP. Es aquí donde se habla del perfil
3GPP de SIP [13], que ha obligado a SIP a añadir un número de extensiones,
cabeceras privadas y opciones para los nodos y terminales de IMS.
Métodos SIP Mediante un modelo de cliente servidor, SIP soporta un número de

métodos que pueden usarse para implementar servicios. Los principales, aunque se
irá viendo a lo largo del documento, son:
REGISTER: Crea una asociación entre una SIP URI10 y una dirección de
contacto. Es necesario para enrutar sesiones entrantes hacia ese usuario.
INVITE: Crea una sesión.
BYE: Termina una sesión.
SUBSCRIBE: Subscripción a un recurso.
NOTIFY: Notifica cambios sobre el estado de un recurso.
ACK: Asentimiento final a una petición de INVITE.
PRACK: Asentimiento provisional para una petición de INVITE.
Asimismo, las respuestas del protocolo SIP – heredadas de HTTP – se engloban en

las siguientes seis categorías:
9
Se verá más adelante que la comunidad de desarrollo software crea para SIP los SIP Servlets,
aplicaciones alojadas en un servidor que en este caso establece comunicaciones basadas en el
protocolo SIP.
10
El protocolo SIP toma el esquema de direccionamiento de internet, mediante el uso de Uniform
Resource Identifiers (URIs) para identificar usuarios, servidores, proxies, etc. Utiliza direcciones
con el formato: sip:usuario@equipo donde el equipo puede estar descrito como un dominio
o una dirección IP [12]. Ejemplo: sip:[email protected]
16
1xx: Respuestas informativas.

2xx: Respuestas de éxito.
3xx: Respuestas de redirección (Redirection Responses).
4xx: Respuestas de fallo del cliente.
5xx: Respuestas de fallo del servidor.
6xx: Respuestas de fallo global.
Se verán detalles de este protocolo a lo largo de todo el documento. De este modo se
completarán aspectos que no quedan explicados en este apartado o no lo hacen con
total completitud. No obstante, para tener una primera referencia de los métodos
SIP se ilustra un mensaje SIP típico con un ejemplo de REGISTER:
REGISTER sip:registrar.biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Bob <sip:[email protected]>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact:<sip:[email protected]>
Expires: 7200
Content-Length: 0
Características de la sesión
SIP es un protocolo de sesión estructurado en forma de mensajes de texto. Sin
embargo es un protocolo independiente del formato o características que describen la
sesión. Es aquí donde entra en juego el protocolo Session Description Protocol
(SDP). Aunque SDP no pasa de ser un breve texto que recoge las características
de la sesión que describe, es este formato textual el que permite incluirlo como
contenido Multipurpose Internet Mail Extension (MIME) dentro de un mensaje del
propio protocolo SIP.
Mediante SDP, los extremos de una sesión pueden indicar sus capacidades
multimedia y definir el tipo de sesión que se desea mantener. Además, con SDP
los extremos deciden qué flujos multimedia compondrán la sesión, de manera que
17
' $
Figura 2.3.: Ejemplo de

un mensaje
SDP como
descripción
de una sesión
multimedia.
& %
establecerán a qué tipos de medios multimedia corresponden dichos flujos (audio,

video, etc.) y qué codecs soportan y desean emplear para cada flujo, así como
la configuración específica de los codecs anunciados. Mediante este intercambio
de señalización se negocia la QoS, tanto en el establecimiento como durante la
sesión en curso, si es necesario. Este dinamismo es una novedad en el sector de
las telecomunicaciones, donde la QoS es estática y viene impuesta por las redes
y el servicio final solicitado. Por otro lado, en las redes 3GPP el operador puede
configurar IMS para elegir qué tipos de medios y codecs desea soportar en su red,
incluso puede personalizar cada perfil de usuario IMS para que éste pueda realizar un
determinado tipo de sesiones IP multimedia, rechazando cualquier otra comunicación
IMS que difiera de sus políticas.
En la figura 2.3 se aprecia que una descripción de sesión SDP contiene una parte
correspondiente a la sesión (hasta la línea t=) y otra correspondiente a los medios
implicados (desde el primer m= hasta el final). Todas las líneas SDP tienen el
formato tipo=valor, estando el tipo identificado por una sola letra.
En este ejemplo, se observan campos relativos a la sesión como el asunto de la
sesión (línea s=), la versión, el identificador y la dirección IP del usuario(campos
v=, o= y c=), etc.
Referentes al formato de los medios utilizados en el ejemplo quedan descritas
las características del flujo de datos multimedia (indicado por m=), como por
ejemplo los codecs de audio y video. Y el campo a=, que indica que los flujos son
bidireccionales.
Es aquí donde se ha de volver a resaltar, como ya se apuntó al comenzar a tratar
SDP, que SIP es un protocolo independiente del formato de descripción de la sesión.
Y aunque la popularidad de SDP haya situado a este protocolo como protagonista en
18
las descripciones de sesión de IMS, no quiere decir que no fuera posible usar otro. SIP
es un protocolo textual, y como tal puede albergar contenido MIME adjunto. Si por
ejemplo, la intención fuera establecer unas reglas para describir sesiones dentro de
una empresa se podría imponer un convenio y utilizar cualquier descripción de sesión
siempre y cuando ambos extremos pudieran entenderla. Es la libertad y versatilidad
de los protocolos textuales.
Protocolo de AAA (Authentication, Authorization, and Accounting)

En la literatura en español se hace uso de estas siglas derivadas del inglés para tratar
de la seguridad informática en una red. En IMS, la AAA (en español Autenticación,
Autorización y Contabilidad o triple A) se lleva a cabo con el protocolo Diameter.
Diameter es una evolución de RADIUS, un protocolo encargado de la seguridad
ampliamente usado en Internet y un viejo conocido del 3GPP (RADIUS es el
protocolo de AAA en GSM).
Diameter, como otros protocolos encargados del AAA, se implementa sobre las
interfaces entre los nodos que requieran alguno de estos servicios. Dentro de Diameter
existen aplicaciones concretas y algoritmos que se aplican según qué servicio de AAA
se precise. Por ejemplo, IMS define una aplicación de Diameter para interactuar con
SIP durante el establecimiento de sesión y otra para llevar a cabo contabilizaciones
de control de crédito.
Otros protocolos
SIP/SDP y Diameter son los dos protocolos más importantes dentro de IMS. Sin
embargo, en la provisión de los servicios IP multimedia intervienen una serie de
protocolos que se describen a continuación:
Políticas de tráfico y QoS: El protocolo COPS es un protocolo que funciona
con un simple modelo de cliente y servidor que intercambian peticiones y
respuestas. El servidor de COPS se denomina Policy Decision Point (PDP)
e intercambia información de políticas de tráfico con su cliente o Policy
Enforcement Point (PEP). El servidor COPS o PDP se coloca en el núcleo
del subsistema IMS y se denomina Policy Decision Function (PDF),
mientras que el papel de PEP lo hace el nodo Gateway GPRS Support Node
(GGSN) de la arquitectura de la red de acceso GPRS/UMTS11 . De este modo
se lleva a cabo el control de acceso al nivel de medios y políticas de QoS,
mecanismos que deciden si un usuario está autorizado para mandar y recibir
datos multimedia, y en el caso de estar autorizado, establecer con qué calidad
de servicio.
IMS soporta varios modelos para acomodar una QoS entre dos usuarios
extremo a extremo. No obstante, en el núcleo de red IMS, como en Internet –
11
No interés del proyecto describir con profundidad la arquitectura de la red de acceso 3G (GPRS
en su fase temprana y UMTS en las versiones más maduras). Sin embargo, es crucial conocer
qué nodos la componen y cuál es su funcionalidad básica para entender el acceso a IMS en la
convergencia de los servicios multimedia de Internet y las redes celulares.
19
he aquí otro signo de la convergencia de redes – son dos los principales modelos
para proporcionar QoS: el modelo de servicios integrados o Integrated
Services y el modelo de servicios diferenciados o Differentiated Services
(Diffserv). Para el modelo de servicios integrados, IMS hace uso del protocolo
Resource ReSerVation Protocol (RSVP), mientras que mediante mensajes
COPS entre el PDF y el GGSN se indican códigos Diffserv hacia las redes
de paquetes que los soporten y así aplicar este modelo de diferenciación de
tráfico según parámetros de calidad de servicio.
Otra función del protocolo COPS dentro de esta interfaz es la de intercambiar
datos de tarificación, un IMS Charging IDentifier (ICID) hacia el plano de
usuario. De la misma manera, la red de acceso es capaz de enviar identificadores
de tarificación hacia IMS. Con este procedimiento se hace posible la unificación
de la información de tarificación de IMS y de la red de acceso en un mismo
sistema de facturación.
Transporte de datos multimedia: La elección del protocolo de transporte
siempre depende del tipo de datos que se acomoda en niveles superiores.
Tradicionalmente, en el modelo TCP/IP, han dominado la capa de transporte
dos protocolos: Transmission Control Protocol (TCP) y User
Datagram Protocol (UDP) (User Datagram Protocol). Mientras que TCP
se usa para transportar datos de manera fiable (retransmitiendo los datos que
se hubieran perdido y por ende permitiendo retardos y ecos) y UDP para
el transporte no fiable (sin retransmitir los datos que no hubieran llegado al
destino) pero asegurando un retardo y eliminando posibles latencias y ecos.
He aquí una gran ventaja de UDP para la comunicaciones en tiempo real.
Un ejemplo es la conversación telefónica donde la pérdida de una palabra
reporta una mejor experiencia de usuario que soportar continuos retardos
o ecos que hagan imposible la fluidez de la conversación. Sin embargo,
UDP no es adecuado para transportar grandes cantidades de datos, ya que
carece de mecanismos de control de congestión. Es por ello que el IETF
se encuentra desarrollando el protocolo Datagram Congestion Control
Protocol (DCCP).
IMS hace uso de de Real-time Transport Protocol (RTP) sobre UDP y
su correspondiente protocolo de control RTP Control Protocol (RTCP).
RTP permite transportar datos multimedia en tiempo real como audio y vídeo
y RTCP aporta estadísticas de QoS e información de sincronización. DCCP
puede usarse en el futuro para transportar RTP pero hoy en día no es un
protocolo lo suficientemente maduro para que IMS lo adopte.
Control de pasarelas de medios: IMS adopta el protocolo H.248 del
IETF y la ITU-T, más y mejor conocido como MEdia GAteway COntrol
(MEGACO) para el control de las pasarelas o gateways de medios, situadas
en el plano de usuario, también llamado de transporte o de medios12 .
12
En la siguiente sección se verá ampliamente la arquitectura de IMS, poniendo gran atención a
la división de ésta en diferentes capas.
20
2.5 Arquitectura de IMS

En la figura 2.4 se representa la arquitectura del IP Multimedia Subsystem tal
y como se establece en el estándar del 3GPP [14]. Se muestran las funciones13 e
interfaces más importantes.
Figura 2.4.: Arquitectura del 3GPP Release 5 donde se introduce por primera vez el
subsistema IMS.
En la figura, se observan varios dominios representados por nubes. El acceso a

la red, en verde, está pensado, para las primeras releases, desde redes celulares
3G, las antiguas PSTN y desde cualquier red con conectividad IP, cumpliendo así
con la prometida convergencia. Así, es posible observar tanto un terminal móvil en
comunicación con una red de acceso GSM o GPRS/UMTS, como equipos conectados
mediante xDSL (en red cableada o inalámbrica) a redes IPv4/IPv6. Y es que es el
dominio de transporte IP, en azul, el que proporciona esta versatilidad en el acceso.
Si a esta interoperabilidad en el acceso se le añade la posibilidad de disfrutar de
cualquier servicio que se pueda encontrar en Internet en el día de hoy, o de mañana,
se estará describiendo, en realidad, la red IMS.
Por el momento, sin atender aún a la división en las capas funcionales, el estudio
se centra en la descripción del nuevo subsistema introducido en la arquitectura de
13
En IMS se estandarizan funciones y no necesariamente nodos. Sin embargo, la mayoría de
los proveedores asocian una función a un nodo, aunque podrían perfectamente agruparlas,
separarlas, etc.
21
2.5. ARQUITECTURA DE IMS
' $
Figura 2.5.: Elementos de la arquitectura de IMS agrupados en cinco grandes

funcionalidades.
& %
esta nueva release del 3GPP. Como en otras secciones, se está haciendo referencia a
IMS, cuyos elementos se sitúan sobre la nube roja, a veces en su interior, otras en
el borde, dando una idea global del ámbito de acción de cada una de las funciones
o nodos.
En el núcleo de IMS se agrupan los diferentes nodos en cinco importantes entidades,
recuadradas en la figura 2.5:
CSCF (Call Session Control Function): El CSCF es el nodo más importante
del IMS, ya que desarrolla la función de servidor SIP y proxy, procesando y
enrutando toda la señalización SIP de IMS. El CSCF puede escenificar tres
papeles dentro del plano de control de IMS:
• P-CSCF (Proxy-CSCF): El P-CSCF es el primer punto de contacto
del usuario con el IMS. Es la entrada de la señalización SIP que parte
del terminal y va dirigida a la red — bien para ser encaminada hacia
otro terminal IMS o hacia los servidores de aplicación que se verán
más adelante —. Entre las funciones del P-CSCF se encuentran las de
autenticar al usuario de cara a la red IMS, revisión de mensajes SIP y su
compresión/descompresión14 , y de seguridad.
El P-CSCF puede llevar incluído el PDF que se vio en la sección 2.4.1.
Como ya se apuntó, el PDF autoriza recursos y gestiona la QoS sobre el
plano de transporte.
• I-CSCF (Interrogating-CSCF): El I-CSCF es un nodo intermedio que da
soporte a la operación IMS. El I-CSCF ayuda a otros nodos a determinar
el siguiente salto de los mensajes SIP y a encaminar la señalización —
14
La compresión de los mensajes SIP entre el terminal y el P-CSCF tiene como objetivo reducir
los tiempos de transmisión de la señalización SIP en la interfaz radio.
22
para ello obtiene información de localización mediante una interfaz con

el HSS/SLF basada en Diameter —. Durante el registro, el P-CSCF se
apoya en el I-CSCF para determinar el S-CSCF que ha de servir a cada
usuario. En situaciones de roaming y en sesiones interred, el I-CSCF es
el punto de entrada conocido por la red IMS externa e indica el siguiente
salto a realizar para la señalización. Opcionalmente, el I-CSCF efectúa
funciones de ocultación de la topología de la red IMS ante redes externas,
encriptando información sensible como puede ser el número de servidores,
sus nombres DNS, sus capacidades, etc.
• S-CSCF (Serving-CSCF): El S-CSCF es la pieza clave en el plano de
control. Tiene tres funciones principales: Servidor SIP, control de
sesión y actuar como un SIP registrar 15 .
El S-CSCF mantiene, como se ve en la figura 2.4, una comunicación
constante con el Home Subscriber Server (HSS) a través de una interfaz
Diameter con el fin de realizar tareas de autenticación, descarga de perfiles
de usuario y para informar al HSS de la asignación del S-CSCF a un
usuario durante el registro.
Es de especial importancia la descarga de los perfiles de usuario, ya que
estos incluirán los perfiles de servicio. Con estos, los S-CSCF16 sabrán
encaminar la señalización SIP hacia los servidores de aplicación.
Por último, el S-CSCF aplica las políticas del operador de red impidiendo
a los usuarios ejecutar servicios u operaciones para los que no está
autorizado. Además de generar los registros de tarificación.
Base de datos: En el HSS (Home Subscriber Server) se almacena la
información relativa a los usuarios. Heredando la funcionalidad del Home
Location Register (HLR) de GSM contiene todos los datos de suscripción
y contratos del usuario necesarios para llevar a cabo sesiones de datos
multimedia. Estos datos incluyen información de localización, seguridad
(conteniendo información de AAA) y perfiles de usuario 17 . Asimismo, el HSS
también registra qué S-CSCF tiene asignado cada usuario.
Cuando la red soporta a muchos usuarios son necesarias varias bases de datos
o HSSs. A su vez, el hecho de disponer de más de un HSS requiere la colocación
del Subscription Locator Function (SLF) que asigna a cada usuario uno de los
HSS que se encuentran en la red.
Tanto el HSS como el SLF implementan el protocolo Diameter en sus
comunicaciones.
15
Al no existir prácticamente textos sobre IMS en castellano se mantiene la denominación
anglosajona de esta funcionalidad del S-CSCF. No obstante, hay que aclarar que un registrar
no es más que un registrador o gestor de registros de los usuarios en la red IMS. De esta manera
se lleva a cabo una asociación entre la dirección IP del usuario y su dirección SIP o Public User
Identity
16
Los nodos CSCF podrán variar en cada red por razones de escalabilidad y redundancia
17
Se verá más adelante que este nuevo concepto de perfil de usuario permite la integración de los
servicios y aumenta la versatilidad en la suscripción y personalización de servicios, así como
una tarificación más ajustada a la realidad.
23
2.5. ARQUITECTURA DE IMS
Servidores de aplicación, AS (Application Server) y las pasarelas con destino

al plano de servicios: Los servidores de aplicación (en adelante también será
posible encontrarlos como ASs) son una entidad SIP destinada a albergar
y ejecutar servicios IMS. Según el modo de funcionamiento de los servicios
alojados en los servidores de aplicación, estos podrán actuar como un proxy
SIP, como un agente de usuario (UA o User Agent popularmente) SIP o como
un Back-To-Back-User Agent (B2B-UA) o agente de usuario back-to-back.
El 3GPP define interfaces IMS entre el S-CSCF y el plano de servicios, de esta
manera la señalización puede desviarse hacia el plano de servicio en base a
una serie de criterios que se recogen en el perfil de abonado, que el HSS aloja
y que el S-CSCF descarga durante el registro de cada abonado.
El S-CSCF puede transferir la señalización SIP de un registro o sesión hacia
un servidor de aplicaciones:
• SIP: El SIP Aplication Server (SIP AS) es el servidor de aplicaciones que
alberga y ejecuta servicios IP Multimedia basados en SIP. Sus interfaces
serán nativas en SIP por lo que no precisan de ninguna pasarela a modo
de “traductor” como las que se tratarán a continuación. El SIP AS puede
estar tanto en la home network como en una red de algún tercero.
• OSA-SCS (Open Service Access-Service Capability Server): Este servi-
dor de aplicaciones (AS) proporciona soporte para aplicaciones desarrol-
ladas por terceras partes alojadas en el OSA Application Server. Esta
interfaz permite acceder a IMS de manera segura desde redes externas.
Desde el plano de control IMS se verá este nodo como un AS comunicado
via SIP con el S-CSCF. Desde el plano de servicios, se verá como una in-
terfaz con el OSA-AS y las Application Programming Interfaces (APIs)
que permiten a terceros crear servicios para IMS. El servidor de capaci-
dades OSA (OSA-SCS) se coloca en la red doméstica o home network,
mientras que los servidores de aplicación OSA pueden estarlo tanto en la
red doméstica como en redes de terceras partes o third party networks.
• IM-SSF (IP Multimedia Service Switching Function). Customized
Applications for Mobile network Enhanced Logic (CAMEL) era la
plataforma desarrollada para habilitar servicios GSM. Mediante un
funcionamiento similar al de redes inteligentes, las peticiones de servicios
eran atendidas mediante un reencaminamiento al servidor CAMEL. GSM
y también GPRS hicieron uso de CAMEL para solucionar problemas
complicados de tarificación y roaming por ejemplo la marcación y la
contabilidad de uso en un roaming en el extranjero.
El IM-SSF traduce SIP al protocolo de comunicaciones de CAMEL, el
CAMEL Application Part (CAP). De esta forma, es posible reutilizar
los servicios CAMEL de GSM en IMS; permitiendo por ejemplo, que el
GSMSCF pueda controlar una sesión IMS. El IM-SSF se encuentra en la
red del operador o home network.
Se ha de remarcar aquí que estos tres tipos de servidores de aplicación se
comportan como SIP ASs hacia el núcleo IMS – bien con funcionalidad
24
de SIP proxy, agente de usuario SIP (como un usuario más) o como un

agente de usuario back-to-back —. Además, los OSA-SCS e IMS-SSF tienen
otros cometidos cuando se comunican con las aplicaciones OSA o CAMEL
respectivamente.
Pasarelas hacia otras redes:
Básicamente, IMS precisa de una interconexión con redes de conmutación de
circuitos (CS) como son las redes PSTN, RDSI, GSM, etc. Por tanto, el 3GPP
define una serie de elementos que representan la arquitectura de interconexión
o interworking.
• Pasarelas hacia redes PSTN/CS del plano de usuario:
Los elementos que componen la arquitectura de interconexión de
IMS proporcionan interfaces de datos y señalización hacia redes de
conmutación de circuitos. Permitiendo así a los terminales IMS realizar y
recibir llamadas entre IMS y las redes de circuitos. Estos elementos son:
◦ MGCF (Media Gateway Control Function): El MGCF es un
controlador de pasarelas que traduce SIP en ISUP18 (ISDN User
Part), un protocolo de aplicación para el Sistema de Señalización
número 7 o SS7, el encargado de establecer las llamadas en las
redes PSTN. Asimismo, controla la pasarela de medios19 Media
GateWay (MGW) mediante el protocolo MeGaCo o H.248.
◦ MGW: La pasarela de medios MGW traduce el protocolo de datos
multimedia en tiempo real RTP a las distintas codificaciones usadas
en las transmisiones sobre redes de circuitos. La pasarela MGW es
capaz de enviar y recibir datos sobre RTP para sesiones IMS y a la
vez hace uso de varios time slots del esquema de modulación Pulse
Code Modulation (PCM) de cara a transmitir por la interfaz CS.
Además, es posible realizar una transcodificación cuando los codecs
en una misma sesión son distintos. Un ejemplo común es la
transcodificación entre el codec AMR del terminal IMS y el G.711
del terminal PSTN.
◦ SGW (Signaling GateWay): La pasarela SGW es el elemento
que interconecta el subsistema IMS con las redes de conmutación
de circuitos PSTN. Entre sus funciones, está la de realizar una
traducción entre los sistemas de señalización. Es el caso de
transformar ISUP sobre IP en ISUP sobre MTP, como parte de la
torre de protocolos del SS7, sistema de control de las redes PSTN.
Para ello, recurre a la conversión de protocolos de las capas más
bajas.
18
El controlador de pasarelas de medios MGCF está situado en el core de IMS, sobre un transporte
IP. Por lo tanto, empaquetará ISUP sobre IP. Se verá que la pasarela SGW (Signaling GateWay)
desempaquetará ISUP de IP y lo colocará de nuevo en la pila de SS7, inteligible para las redes
PSTN.
19
Se ha venido denominando indistintamente medios y datos al mismo concepto de datos
multimedia.
25
2.6. FUNCIONAMIENTO DE IMS
• Encaminamiento basados en números de teléfono: El 3GPP

incluyó en su especificación para IMS un elemento que añadía la
funcionalidad de encaminar sesiones basadas en números de teléfonos
tradicionales: el Breakout Gateway Control Function (BGCF).
El BGCF es un servidor SIP que permite atender sesiones originadas en
un terminal IMS y dirigirlas hacia un usuario en una red de conmutación
de circuitos (CS), como pueden ser la PSTN o PLMN. Para ello, el BGCF
basándose en el número de teléfono del destinatario:
◦ Selecciona la red apropiada cuando se establece una sesión interred
con el dominio de conmutación de circuitos (CS).
◦ Seleccionar la pasarela PSTN/PLMN adecuada cuando se establece
una sesión dentro de la misma red donde se encuentra el BGCF.
Funciones de recursos multimedia MRF (Media Resource Function): Pro-

porcionan recursos multimedia en la home network tales como conferencing,
Interactive Voice Response (IVR), el sistema telefónico que atiende al usuario
mediante respuestas de voz grabada, etc. Los Media Resources pueden descom-
ponerse en:
• MRFC (Multimedia Resource Function Controller), un nodo del plano

de señalización o control que actúa como un agente de usuario conectado
al S-CSCF a través de una interfaz SIP y controla los recursos multimedia
en el Media Resource Function Processor (MRFP) mediante mensajes
MeGaCo o H.248.
• MRFP (Media Resource Function Processor) es un nodo del plano
de usuario que implementa procesamiento, mezclado y otras funciones
relacionadas con los datos multimedia.
2.6 Funcionamiento de IMS

En este apartado se estudiará el funcionamiento de IMS, tratando de ver, mediante
el análisis de los procedimientos más comunes, el papel que tiene cada elemento de
la arquitectura.
En primer lugar se repasan los requisitos para acceder a IMS. En segundo lugar,
se estudia el registro en la red como proceso necesario para que el abonado pueda
acceder a los servicios IP multimedia. Tras esto, se lleva a cabo un análisis del
establecimiento de sesión como funcionalidad que permite iniciar las comunicaciones
con otros abonados y con los servicios multimedia. Posteriormente, se incluye el
estudio de la provisión de servicios por parte de los servidores de aplicación. Y
finalmente se ve la interconexión de IMS a otras redes, básicamente, tal y como se
ha venido tratando en la sección 2.5, redes de conmutación de circuitos.
26
' $
Figura 2.6.: Requerimientos para el fun-

cionamiento en IMS
& %
2.6.1 Fases previas al funcionamiento en IMS

Debido a la concepción de IMS como una red de control de servicios superpuesta
al plano de acceso basado en IP; el terminal IMS ha de cumplir ciertos requisitos
para atravesar los elementos necesarios de la arquitectura y así llegar a su destino,
el núcleo IMS. En la figura 2.6 se muestran los pasos que el terminal de IMS tiene
que dar para obtener funcionalidad dentro del núcleo de red.
Como se observa, los pasos a dar son:
1. Establecer un contrato con el operador. Al igual que con la subscripción a otros

servicios como el de telefonía móvil o acceso a internet, es necesario establecer
unas condiciones con el operador para acceder a los servicios IP Multimedia
que ofrezca en su red IMS.
2. Adquirir conectividad IP. Es preciso obtener acceso a una red de acceso con
conectividad IP – en la bibliografía en inglés IP Connectivity Access Network
(IP-CAN) – como GPRS/UMTS, o en futuras releases del 3GPP, ADSL,
o WLAN. Este acceso IP es necesario debido a la propia naturaleza de IMS,
sustentado por un plano de transporte IP. Como parte de la obtención de esta
conectividad, el terminal IMS ha de adquirir una dirección IP. Normalmente, si
el acceso es vía GPRS/UMTS, el operador asignará una dirección IP pública20
y dinámica vía protocolos de asignación dinámica como DHCP.
20
Es necesario contactar con el terminal desde el exterior, por ejemplo desde Internet. Para ello, la
solución más factible para el operador es la de proveer una dirección pública temporal (puesto
que las direcciones IPv4 son un recurso escaso) durante la sesión IMS.
27
3. Una vez estos dos primeros requisitos se han cumplido, el terminal IMS necesita
“localizar” al P-CSCF. Es decir, necesita conocer su dirección IP. Una vez
descubierta esta IP, el terminal podrá enviar y recibir señalización SIP a
través del P-CSCF21 . Este proceso puede estar ligado al acceso a una red
de conectividad IP.
4. Cumplidos estos requisitos previos, el terminal IMS realiza un registro a
nivel SIP en la red IMS. Este registro se lleva a cabo mediante un registro
SIP normal22 . Si el registro SIP en la red IMS se lleva a cabo con éxito, el
terminal IMS puede intercambiar más mensajes de señalización SIP.
2.6.2 Procedimiento de registro en IMS

Una vez el terminal ha adquirido una dirección IP23 y descubierto la dirección IP
del P-CSCF, puede pasar a registrarse en el plano de control de IMS.
Durante este proceso, representado en la figura 2.7, el usuario IMS pide autorización
a la red IMS para acceder a los servicios IP multimedia. El registro IMS consta de
las siguientes fases:
(1/2) El terminal (móvil) de usuario (UE, User Equipment) envía un petición
de registro SIP, REGISTER, hacia el P-CSCF.
• EL P-CSCF realiza una petición DNS para encontrar un I-CSCF en la
red home del usuario.
• Le añade un campo para indicar la red visitada en la que se encuentra y
reenvía el REGISTER hacia el I-CSCF.
(3/4) El I-CSCF recibe la petición REGISTER y envía la petición Diameter UAR
(User Authorization Request) al HSS. El HSS comprueba que el identificador
de usuario es correcto y que existen acuerdos de roaming para ese usuario en
la red visitada en la que se encuentra, y envía un UAA (User Authorization
Answer) de vuelta al I-CSCF.
(5) El I-CSCF recibe el UAA que contiene el S-CSCF asignado al usuario o el
criterio para seleccionar uno24 . En este último caso, el I-CSCF seleccionaría un
S-CSCF apropiado y reenviaría la petición de registro REGISTER a ese S-CSCF.
(6/7) El S-SCSF envía una petición MAR (Multimedia Authorization Request)
al HSS para descargar los vectores de autenticación25 para desafiar al terminal.
21
El descubrimiento de la IP del P-CSCF normalmente se realiza cuando el terminal se enciende
o se apaga, así como los recursos de un P-CSCF quedan asignados a un terminal durante el
tiempo que éste mantenga una sesión.
22
Se verá más adelante que este registro se lleva a cabo con el intercambio de ciertos mensajes SIP.
23
En el caso de IPv6 el terminal recibiría 64 bits de la dirección y construiría los otros 64 para
formar la dirección completa de 128 bits del protocolo IPv6
24
El I-CSCF tiene una tabla configurable de los S-CSCF que operan en la home network y las
capacidades que soporta cada uno. Esto permite al I-CSCF escoger el S-CSCF adecuado para
cada usuario.
25
Sólo la petición SIP de registro SIP se autentica en IMS. Otras peticiones SIP, como INVITE,
nunca se autorizan, pues van precedidas siempre de un REGISTER.
28
Esta petición incluye la dirección del S-CSCF para que el HSS sepa cuál
está asignado al usuario. El HSS envía la respuesta MAA (Multimedia
Authorization Answer) con los vectores de autenticación.
(8) El S-CSCF responde al REGISTER con un mensaje 401 Unauthorized
(no autorizado) que contiene la información para llevar a cabo el desafío de
seguridad.
(9/10) La respuesta viaja a través del I-CSCF y P-CSCF hasta que alcanza el
usuario.
(11) El usuario construye un nuevo REGISTER incluyendo la respuesta al desafío
de seguridad y lo reenvía hacia el P-CSCF.
(12/13/14/15) La nueva petición alcanza el I-CSCF que envía un nuevo UAR
al HSS para encontrar el S-CSCF, a quien reenvía el REGISTER.
(16/17) El S-CSCF autentica al usuario y envía una petición SAR (Server
Assignment Request) al HSS para informar que el usuario está registrado
y requerir la descarga del perfil de usuario. Esta descarga se incluye en la
respuesta SAA (Server Assignment Answer) del HSS.
(18/19/20) El S-CSCF confirma que el usuario está registrado mediante el
envío de un SIP 200 OK que atraviesa el I-CSCF y el P-CSCF hasta llegar al
usuario.
2.6.3 Establecimiento de sesión

Una vez el usuario se ha registrado en el subsistema IMS puede acceder a los
servicios IP multimedia que proporciona IMS. De este modo, un usuario IMS podría
establecer una sesión de videoconferencia con otro usuario IMS de otra red y llevarla
a cabo en movilidad. Para ello, utilizará el subsistema IMS para intercambiar
información de control mediante los protocolos SIP y SDP con el usuario con
el que se quiere comunicar. El objetivo de este intercambio de señalización es el
establecimiento de una sesión, mediante la cual se conectará con el nodo destino,
se negociarán los parámetros de sesión y se activarán los recursos de la red de
acceso para soportar la sesión multimedia (en el caso de esta release los recursos de
GPRS/UMTS como red celular de acceso).
El funcionamiento de IMS en el establecimiento de sesión se muestra en la figuras 2.8
y 2.9 donde se presentan los dos actores que intervienen en la sesión: Alice y Bob.
Lo primero que llama la atención es la completa separación del plano de señalización
y de medios. La señalización SIP atraviesa un conjunto de CSCFs, mientras que los
datos multimedia se envían de extremo a extremo, de un terminal IMS al otro, sólo
atravesando routers IP (o GGSNs si se da el caso, en cualquier caso, un backbone
IP).
Otra cuestión que se ha de sacar a colación es el hecho de que toda la señalización
SIP pasa por el P-CSCF y S-CSCF de las redes de origen: la red donde se efectúa la
llamada (en este caso la red que visita Alice en su viaje al Reino Unido, visited.uk)
29
Figura 2.7.: Procedimiento de registro de un terminal IMS en la red.
30
' $
Figura 2.8.: Diagrama de establecimiento de sesión en un roaming total.

& %
y la red base del usuario (en este caso la española home.es). Se observa claramente
este hecho viendo que ningún mensaje de control de la figura 2.9 “pasa por encima”
de estos nodos. La justificación de este hecho se basa en dos razones:
El P-CSCF es la puerta de entrada de la señalización SIP y el encargado de
comprimirla y descomprimirla en la interfaz con el terminal.
El S-CSCF es atravesado en todas las peticiones para permitir el lanzamiento
de servicios de valor añadido que el usuario haya requerido mediante la
petición. El S-CSCF juega un papel sumamente importante en la provisión
de servicios que envuelvan a uno o más servidores de aplicación. Al colocar el
S-CSCF en la red base o home network los servicios siempre están disponibles
para los usuarios, estén donde estén.
Para comprender mejor el proceso de establecimiento de sesión, se analiza en detalle
la señalización presente desde el momento en que dos usuarios registrados desean
entablar una comunicación multimedia hasta que el transporte de medios se pone
de manifiesto.
El ejemplo partirá de la situación de partida ilustrada en la figura 2.8:
Dos usuarios con terminales IMS: Alice y Bob. Alice tiene su contrato con la
operadora que le oferta servicios IP multimedia en España, pero se encuentra de
viaje en el Reino Unido. Una situación idéntica de itinerancia o roaming es la de
Bob. Bob, irlandés, está de turismo en París.
Alice y Bob saben que ambos están haciendo turismo por lo que Alice, situada ante
31
el Big Ben en Londres, desea entablar una videoconferencia con Bob para que su
amigo vea dónde se encuentra y así también saber qué es de él y por dónde anda en
su visita a París.
Dentro de la descripción tecnológica, se suponen ambos terminales IMS con
idénticas capacidades, la ausencia de provisión de servicios – la comunicación será
de cliente a cliente de videoconferencia – y que los terminales están registrados en
IMS.
A continuación se describen las fases de las que consta el procedimiento de
establecimiento de sesión:
Alice quiere establecer la videoconferencia IMS con Bob, por lo que su terminal,
lanzado por la aplicación cliente instalada, envía (1) la petición INVITE al
P-CSCF haciendo uso de la asociación de seguridad establecida durante el
registro. La petición puede ir comprimida, y tendría la siguiente estructura:
• Mensaje SIP INVITE
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP [1080::8:800:200C:417A]:5059;

comp=sigcomp;branch=z9hG4bK9h9ab Max-Forwards: 70
Route: <sip:pcscf1.visitada.uk:5058;lr;comp=sigcomp>,
<sip:[email protected];lr>
Preferred-Identity: "Alice Smith" <sip:[email protected]>
Privacy: none
P-Access-Network-Info: 3GPP-UTRAN-TDD;
utran-cell-id-3gpp=C359A3913B20E
From: <sip:[email protected]>;tag=ty20s
To: <sip:[email protected]>
Call-ID: 3sO9csO3
Cseq: 127 INVITE
Require: precondition, sec-agree
Proxy-Require: sec-agree
Supported: lOOrel Security-Verify: ipsec-3gpp; q=0.1;

alg=hmac-sha-l-96; spi-c=98765432; spi-s=909767; port-c=5057;
32
port-s=5058
Contact: <sip:[1080::8:800:200C:417A]:5059;comp=sigcomp>
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: 569
• Seguido del mensaje SDP como adjunto MIME dentro del mismo SIP
INVITE
v=0
o=- 1073055600 1073055600 IN IP6 1080::8:800:200C:417A
s=- c=IN IP6 1080::8:800:200C:417A
t=0 0
m=video 8382 RTP/AVP 98 99
b=AS:75
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
a=rtpmap:99 MP4V-ES
m=audio 8283 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local none
33
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
Es posible identificar fácilmente las cabeceras del mensaje SIP y deducir su

significado. Asimismo, se extrae del mensaje SDP la descripción del audio y
vídeo que compondrán la videollamada: las líneas m= del mensaje indican el
puerto por donde se recibirá el flujo de medios y la lista de codecs que el
terminal soporta para la sesión y el flujo actual. Por último, notar que el
mensaje SDP indica el uso de extensiones de prerrequisitos con la presencia
de algunas líneas a=curr:qos y a=des:qos indicando la QoS actual y deseada
para los portadores de servicios en el caso concreto de este flujo de medios.
Normalmente en el mensaje INVITE aún no se ha producido una asignación
de recursos de transporte, por lo que estos parámetros aparecen con el valor
none.
Los mensajes de 100 Trying son respuestas provisionales para hacer saber
al nodo anterior que las peticiones han llegado correctamente. Por tanto, se
obviará la descripción de estos mensajes (2/4/...).
(3) El P-CSCF descifra y descomprime la petición y analiza si la descripción
SDP de los datos multimedia es válida y que la ruta para el mensaje
corresponde con la especificada en el registro. Esta petición es entonces
reenviada hacia el I-CSCF.
(4) El I-CSCF recibe la petición y la reenvía al siguiente salto, en este caso, el
S-CSCF asignado a Alice.
(5) El S-CSCF recibe la petición y basándose en el perfil de usuario descargado
del HSS durante el registro analiza la descripción de la sesión SDP y aplica los
triggers o “disparadores” de los filtros (initial Filter Criteria, iFC)26 definidos
en el perfil de usuario para determinar si la petición ha de ser reencaminada
hacia un servidor de aplicación o AS.
(6) El S-CSCF, ya que es un caso donde no entran en juego los servidores
de aplicación, hace uso de DNS para encontrar el I-CSCF en la red base de
destino. Para ello se sirve de la URI de destino: [email protected].
26
Habrá tiempo de ver los initial Filter Criteria o iFC en futuras secciones donde se tratará la
provisión de servicio por parte de los ASs con más detalle.
34
Figura 2.9.: Paso de mensajes en el establecimiento de sesión.
35
(8) Cuando el I-CSCF recibe la petición envía un Location Info Request (LIR)
al HSS para localizar el S-CSCF asignado a ese usuario (Bob).
(9/10) Con la respuesta del HSS (Location Info Answer, LIA), el I-CSCF
reenvía la petición al S-CSCF que a su vez aplica el perfil de usuario para
determinar si el SDP es el adecuado para Bob y si la petición ha de ser
reenviada a algún AS.
(12) El S-CSCF, ya que no hay ningún servicio provisto encamina la petición
INVITE al P-CSCF asignado a Bob (y almacenado desde el registro).
(14) El P-CSCF comprime y encripta la petición y la envía al terminal IMS de
Bob haciendo uso de la asociación de seguridad establecida durante el registro
del usuario.
(16) El terminal de usuario de Bob procesa la descripción de medios SDP
incluída en la petición INVITE y construye una respuesta SIP 183 Session
in Progress que incluye una respuesta SDP a la propuesta del terminal de
Alice y la envía hacia el P-CSCF con los mismos mecanismos de seguridad
usados hasta entonces.
(17/.../22) El mensaje de progreso de sesión sigue el camino de vuelta hacia
el terminal de origen (usuario Alice).
(23) El terminal de Alice analiza la descripción SDP en el mensaje
183 Session in Progress y construye un mensaje PRACK (PRovisional
ACKnowledgement, asentimiento provisional) con la respuesta SDP final. En
este punto el terminal de origen (el de Alice) puede comenzar con la reserva
de recursos de transporte para esta sesión.
(24/.../27) El mensaje PRACK viaja hacia el destino por los nodos pertinentes.
(28) El PRACK llega y el terminal destino puede empezar entonces a reservar
recursos en base a la descripción SDP. Asimismo, manda un mensaje 200 OK
de vuelta al terminal origen. Este OK corresponde al PRACK, no al INVITE.
(29/.../32) El 200 OK llega al origen atravesando el camino o path.
(33) Cuando el terminal de origen de Alice completa la reserva de recursos
envía un mensaje de UPDATE al terminal de destino de Bob.
(34/.../37) El UPDATE atraviesa el path hacia el destino.
(38/.../42) Se genera una respuesta OK y se envía de vuelta hacia el origen (el
terminal de Alice).
En este punto si el terminal de Bob ha completado su reserva de recursos
del plano de usuario se puede avisar al usuario de que existe una llamada de
sesión entrante. Esto se transmite al origen mediante el envío de un mensaje
180 Ringing (43/.../48).
(49) Cuando el terminal de Alice recibe el mensaje 180 Ringing empieza a
dar tonos y envía el PRACK (50/.../54) de vuelta hacia el destinatario, Bob.
Este PRACK es respondido con un 200 OK (55/.../59).
En algún momento, Bob, el destinatario de la llamada la acepta y su terminal
36
envía un 200 OK de vuelta al terminal de Alice (60/.../66), completando así

el establecimiento de la llamada. Esto es así porque es realmente este OK la
respuesta que completa la transacción del INVITE.
(67/.../71) Finalmente, el terminal de Alice manda un ACK final hacia el
terminal de Bob y la transmisión en el plano de medios puede comenzar. Los
terminales IMS de Alice y Bob generan flujos de audio y vídeo que se envían
extremo a extremo vía routers IP.
2.6.4 Establecimiento de sesión con provisión de servicios añadidos

El estudio del ejemplo de la sección anterior ilustraba acerca del establecimiento
de una sesión multimedia entre dos usuarios IMS. No obstante, ninguno de estos
usuarios ejecutaba ningún servicio añadido a la sesión multimedia. Esta sesión, por
tanto, chocaba con la filosofía de IMS, donde la idea básica es la de proporcionar el
entorno común para ofrecer servicios innovadores.
Alejándose del ejemplo pedagógico anterior y acercándose a los verdaderos fines
de IMS, es posible elaborar un ejemplo del establecimiento de una sesión real en
la que se ofrezca un servicio para la entidad origen de la llamada (Alice), para el
destinatario (Bob) o para ambos. Para ello, en este apartado se describen los modos
de operación de los ASs — descritos con anterioridad en la sección 2.5 — dentro de
su funcionamiento en las sesiones IP multimedia.
Los servidores de aplicación, ASs, como se trató en la sección de arquitectura,
pertenecen a la capa de aplicación o plano de servicios de IMS. Normalmente, en una
red, coexisten más de un AS. Típicamente, existirán varios, cada uno proveyendo
un servicio en particular. Algunos estarán especializados en implementar alguna
tecnología, como la tecnología Java, SIP servlets, o SIP CGI (Common Gateway
Interface). Todos ellos, sin embargo, tienen en común la tarea de presentar una
interfaz SIP hacia el S-CSCF27 .
En la figura 2.10 se ilustran los diferentes tipos y combinaciones de ASs y sus
interfaces. Como se observa, es siempre la interfaz con el S-CSCF el vínculo SIP con
el core IMS de la red doméstica. Es por ello que el S-CSCF es el nodo que involucra
a los servidores de aplicación en el establecimiento de sesión.
Además, cualquier AS puede implementar otros protocolos de aplicación como son
HTTP o Wireless Application Protocol (WAP). Un ejemplo de la ambivalencia de
los ASs es el de implementar una interfaz gráfica basada en web (HTTP) o WAP
para la configuración de parámetros del AS. Sin embargo, a fecha de hoy no se
encuentran descritas en las especificaciones de IMS.
27
En muchos rincones de la bibliografía, esta interfaz entre los ASs y el S-CSCF se denomina
IMS Service Control (ISC), el nombre genérico que tomaba previo a la elección de SIP como
protocolo de sesión por parte del 3GPP.
37
' $
Figura 2.10.: Tipos de ASs y sus interfaces

& %
Los diferentes roles de los servidores de aplicación

En este apartado se estudia cómo los diferentes ASs (el estudio es válido para
cualquier tipo de AS) se comportan de una u otra manera dependiendo del servicio
que ofrezcan.
Desde el punto de vista de un protocolo de sesión como SIP, un AS puede tomar
los siguientes papeles:
Agente de usuario (User Agent, UA) origen o destino SIP. Es decir, de emisor
o receptor de mensajes de señalización SIP.
Servidor proxy SIP.
Servidor de redirección SIP.
Agente de usuario Back-to-Back (B2BUA).
Si en un caso concreto, el servidor de aplicación decide no proporcionar el servicio
por cualquier razón, actúa como un proxy SIP, asegurándose que los mensajes SIP
vuelven al S-CSCF y continúan su camino.
En las siguientes descripciones se realizan peticiones INVITE. Esto es así por
tratarse de un ejemplo, sin embargo es posible hacer uso de cualquier otra petición
(SUBSCRIBE, PUBLISH,...) sujeta a los iFC ya mencionados en la sección 2.6.3. Toda la
señalización está descrita a alto nivel, simplificando el paso de mensajes y ocultando
la complejidad de otras transacciones.
AS como SIP UA:
En la figura 2.11 se muestra cómo el AS se comporta como un agente de
usuario SIP (SIP UA) respondiendo con un 200 OK al mensaje de INVITE. En
este caso el P-CSCF y el AS están en la red home o doméstica pero podrían
estarlo en la visitada o en una red de terceras partes (en el caso del AS).
El ejemplo de la figura 2.11 puede tener dos variantes: cuando el AS provee
servicios a la otra parte de la llamada con efecto en el origen (por ejemplo
actualizaciones de estado en servicios de presencia) o el caso del AS siendo
38
' $
Figura 2.11.: AS actuando como un SIP UA y proveyendo servicios al usuario (Alice).

& %
el agente de usuario origen para proporcionar servicios (un ejemplo sería el

servicio de despertador).
AS como servidor proxy SIP
En esta configuración ilustrada en la figura 2.12 el servidor de aplicación, AS
actúa de proxy SIP para proporcionar la lógica del servicio. En este ejemplo,
el S-CSCF involucra a un AS reencaminando el INVITE hacia el AS28 .
AS como servidor de redirección SIP
En este caso, el AS implementa un nuevo campo Contact en la respuesta SIP
con la nueva URI a la que se han de encaminar las nuevas peticiones. Esta
nueva URI será entonces la nueva Request-URI de las peticiones, y puede
dirigir a otras redes IMS.
Un ejemplo típico es el de desvío de llamada. También puede utilizarse para dar
servicio de portabilidad de número. En general, estos servidores de redirección
se usan cuando se desvían sesiones y el operador no desea formar parte de ellas
tras realizar el reencaminado.
AS como B2BUA:
Ésta es la última configuración que puede adoptar un servidor de aplicación en
la ruta de señalización SIP, la de Back To Back User Agent. Esta configuración
está basada en la aplicación de una lógica de servicio común a dos agentes
28
Además de reencaminar el INVITE; el S-CSCF inserta la cabecera Route en el mensaje
INVITE que apunta hacia el AS en primer lugar y al S-CSCF en segundo lugar. Esto
permite que el AS reencamine la petición hacia el mismo S-CSCF en el camino de vuelta.
Además se incluye una información de estado para comprobar que la petición ya ha pasado
por el AS. El mensaje Route tendría la siguiente forma: Route: <sip:as.home.es;lr>,
<sip:[email protected];lr>.
39
' $
Figura 2.12.: AS actuando como un servidor SIP Proxy añadiendo lógica de servicio
y reencaminando las peticiones con el correspondiente valor añadido.
& %
' $
Figura 2.13.: El AS B2BUA como dos UAs conectadas bajo una lógica de servicio.
& %
de usuario conectados entre sí. Si se atiende a la figura 2.13 se observa

una funcionalidad similar a la del servidor SIP proxy, ya que los UAs
reciben peticiones y las reencaminan, reciben respuestas y las entregan al UA
correspondiente.
En esta misma figura 2.13 la petición A que llega al primer UA se transforma
en la petición B debido a que durante el paso por la lógica de servicio específica
de la aplicación pueden cambiar las cabeceras, incluyendo algunas que el SIP
proxy no puede cambiar como son las From, To, Call-ID, etc. Asimismo, la
lógica de servicio puede cambiar la descripción SDP.
Por otra parte, los AS B2BUA pueden incluso generar peticiones SIP para un
trayecto de la sesión independientemente de que no exista petición desde la
otra parte (por ejemplo, en el ejemplo de la figura, generar la petición B sin
40
existir la petición A). Incluso puede generar, también, múltiples trayectos de

sesión, como un controlador de “llamada a tres”.
Como los B2BUA son en definitiva varios SIP UAs conectados, estos han de
entender todos los métodos y extensiones SIP de la otra parte.
La lógica de servicio superpuesta a los UAs dicta cómo las peticiones y
respuestas se mapean. Este aspecto abre numerosas posibilidades dependientes
del servicio proporcionado por el usuario.
Un ejemplo sería el de un servidor de aplicación de prepago: El AS primero
verifica que el usuario tiene crédito suficiente en su cuenta para pagar el coste
de la sesión. Si no lo tiene, el AS simplemente rechaza la llamada, si lo tiene,
la sesión continúa. Una vez se establece la sesión, si el usuario se queda sin
crédito, el B2BUA AS envía una petición de BYE para ambas partes para que
cierren la sesión.
Finalmente se pone de manifiesto la provisión de servicios en el establecimiento de

la sesión con el diagrama de la figura 2.14 en el que se añade el reencaminamiento
de las peticiones a los servidores de aplicación para proporcionar valor añadido a las
sesiones IMS.
' $
Figura 2.14.: Diagrama de establecimiento de sesión en un roaming total y provisión

de servicios
& %
41
2.6.5 El mapeo de servicios: los Filter Criteria

Los Filter Criteria (“criterios de filtrado”) son unas de las piezas más importantes
si se habla de la información del usuario que almacena la red. Su importancia
reside en que determinan los servicios que se proporcionarán a cada usuario. Los
Filter Criteria son información del usuario que ayuda al S-CSCF a decidir en qué
momento involucrar a un AS particular para que proporcione el servicio. Aunque
se especificaron dos tipos de Filter Criteria , han prevalecido el initial Filter
Criteria, iFC.
El S-CSCF evalúa los iFC cuando recibe una petición como INVITE, SUBSCRIBE,
OPTIONS, etc. siempre que creen un diálogo o se envíen independientemente de
cualquier diálogo. Es decir, los iFC no se evaluarán en peticiones que estén dentro
de un diálogo ya establecido (PRACK, NOTIFY, UPDATE o BYE).
Los iFC se almacenan en el HSS – junto a más información de usuario – en una
estructura de datos denominada perfil de usuario o user profile (se observa la
estructura del perfil de usuario en la figura 2.15). A grandes rasgos, el perfil de
usuario incluye la identidad de usuario privada (Private User Identity) a la cual se
aplica dicho perfil de usuario y uno o más perfiles de servicio o service profiles.
Cada perfil de servicio contiene una o más identidades de usuario públicas (Public
User Identities) sobre la cual se aplican los perfiles de servicio. Por último, los perfiles
de servicio incluyen cero o más iFC.
Cuando el usuario se registra con el S-CSCF, éste contacta con el HSS y descarga
el perfil de usuario que incluye los iFC. De este modo, los iFC están disponibles
en el S-CSCF a partir del momento en el que se registra el usuario. Los iFC, cuya
estructura se ilustra en la figura 2.16, determinan los servicios que se aplican a la
colección de identidades públicas listadas en el perfil de servicio.
En capítulos posteriores se verá un ejemplo clarificador de la provisión de servicios
en base a perfiles de usuario. Sin embargo, es necesario describir en este punto
la estructura y las funciones de los iFC, de cara a comprender la versatilidad y
ventajas del lanzamiento de servicios a partir de los datos de preferencias (el perfil)
del usuario.
Los iFC determinan qué servicios se aplican a qué identidad pública de las que se
encuentran listadas en el perfil de servicio. Observando la figura 2.16 se distinguen
los siguientes campos:
Prioridad o priority: determina el orden de evaluación de un iFC concreto
frente a los restantes definidos para un mismo perfil de servicio. El S-CSCF
por tanto evaluará primero el iFC con más prioridad, y así sucesivamente.
Trigger Point: Para un iFC puede haber uno o ningún Trigger Point. Un
Trigger Point es una expresión cuya evaluación determina si las peticiones
SIP se han de encaminar hacia un AS. Si no existe ningún Trigger Point
las peticiones se encaminarán siempre hacia el AS. Un Trigger Point es una
colección de filtros o “disparadores” denominados Service Point Triggers, que
permiten acceder a la información de los campos de una petición SIP, como:
• El valor del campo Request-URI.
42
Figura 2.15.: Estructura simplificada de un perfil de usuario almacenado en el HSS.
43
Figura 2.16.: Estructura de los initial Filter Criteria.
44
• El método de la petición SIP: INVITE, OPTIONS, SUBSCRIBE, etc.

• La existencia o ausencia de una determinada cabecera SIP.
• La correspondencia parcial o total entre el contenido de varias cabeceras
SIP (ej.: una relación determinada entre ellas).
• El tipo de sesión, o sea, si la petición SIP está originada por el usuario
objeto del servicio, destinada a un usuario registrado o destinada a un
usuario no registrado.
• Descripción de la sesión, es decir, el cumplimiento parcial o total de una
condición por parte de una línea determinada del mensaje SDP.
Un ejemplo de un Trigger Point sería la siguiente expresión:
(Method=INVITE) AND (Request-URI = sip:[email protected]),
donde (Method=INVITE) y (Request-URI = sip:[email protected])
son los Service Point Triggers.
Application Server: en este campo se recoge la información concerniente a los
servidores de aplicación a los que se reencaminarán las peticiones SIP tras
la evaluación de los iFC. Esta información viene detallada en los siguientes
campos:
• AS IP URI: Es la dirección del AS que recibirá la petición SIP siempre y
cuando se cumplan las condiciones establecidas por los Trigger Points.
• Default Handling: Este campo indica la acción que se tomará (continuar
o abortar el proceso) si el S-CSCF, por la razón que fuere, o pudiera
contactar con el AS indicado en el campo AS SIP URI.
• Service Information: Este campo almacena algunos datos transparentes
para el S-CSCF y el HSS, pero que el AS necesita para procesar las
peticiones. Este campo está restringido para peticiones para las cuales el
S-CSCF actúa como un cliente SIP UA, como por ejemplo es la petición
SIP REGISTER.
Finalmente, el perfil de usuario se codifica haciendo uso de eXtensible Markup

Language (XML). El 3GPP especifica [15] un esquema XML determinado para
definir los initial Filter Criteria. Estos iFC se transportan desde el HSS hasta el S-
CSCF a través de mensajes del protocolo Diameter explicado en la sección 1.5.1.
Un ejemplo de ejecución de servicio podría ser la provisión de un servicio de restric-
ción de llamadas en base a una “lista negra”. Es posible imaginar que un usuario
(sip:[email protected]) contrata un servicio que desvía las llamadas entrantes
procedentes de usuarios de la “lista negra” (por ejemplo sip:[email protected])
hacia un contestador (proporcionado por el MRF) que responde a ese usuario con un
mensaje preestablecido. Como se ha comentado anteriormente, el servicio se modela
aplicando un perfil de servicio a sip:[email protected] que contenta un Trig-
ger Point que filtre todas las sesiones INVITE destinadas a este usuario cuyo origen
sea alguien de la “lista negra”.
El Trigger Point se representa como
45
(method = INVITE) AND (P-Asserted-Identity = sip:[email protected])

AND (Session Case = Terminating)
Y se evalúa tras la descarga del XML de la figura 2.1729 que lo contiene.
Figura 2.17.: Fichero XML que describe el perfil del usuario sip:[email protected].
Cuando se cumplen las condiciones, el S-CSCF envía la petición al AS correspon-

diente. Este AS contiene la lógica necesaria para proporcionar el desvío hacia el
MRFC, indicándole la reproducción del mensaje con la información de la restric-
ción. En concreto, la aplicación del servicio consiste en que el AS reenvíe la petición
al MRFC30
El MRFC identifica el mensaje a emitir a partir del nombre de usuario de la SIP
URI. Posteriormente envía órdenes H.248 al MRFP para que reproduzca el mensaje
acorde al usuario.
2.6.6 Establecimiento de sesión desde y hacia una red de circuitos

PSTN
Tanto en el capítulo 1 como en este presente se ha argumentado que IMS
propiciaba la cohesión de redes proporcionando pasarelas de interconexión en el
seno de su arquitectura. Estas pasarelas facilitan la interconexión y traducción
entre protocolos, permitiendo una compatibilidad hacia atrás entre tecnologías y
una mayor versatilidad en el acceso.
29
Se ha supuesto que el usuario sip:[email protected] solo tiene suscrito este servicio.
30
En este caso el AS actúa como SIP proxy y reemplaza la Request-URI del INVITE por la del
MRFC: sip:[email protected].
46
' $
Figura 2.18.: Establecimiento de sesión hacia una red PSTN.

& %
Para ilustrar esta convergencia, se presentan a continuación dos ejemplos de sesiones

entre una red IMS y otras redes heredadas, en este caso la red PSTN de conmutación
de circuitos. En este caso el Breakout Gateway Control Function (BGCF) entra en
juego ya que elige el MGCF remoto a través de la conexión del BGCF de la red
doméstica con el BGCF de la red de interconexión.
En la figura 2.18 se puede ver la secuencia de mensajes de protocolos que se suceden
en el establecimiento de una sesión originada desde un terminal IMS y terminada
en un terminal PSTN.
Por otro lado, cuando la sesión se origina en el terminal PSTN hacia el terminal IMS
el BGCF no interviene ya que la selección del MGCF se lleva a cabo en el dominio de
conmutación de circuitos (dominio CS). Tal y como queda ilustrado en la figura 2.19
el MGCF envía el INVITE inicial hacia un I-CSCF ya que el MGCF desconoce qué
S-CSCF se ha asignado al usuario destino en su correspondiente registro.
2.7 Servicios IMS

En las Comunicaciones Móviles previas a la aparición de IMS, cada servicio se
soportaba con uno o varios nodos lógicos, llevando a cabo funciones específicas para
ese servicio. Es decir, un servicio precisaba de una arquitectura de red propia con
sus nodos específicos. La única manera para interactuar entre ellos — por ejemplo
para integración de servicios — era a través de protocolos. Por tanto, en la ausencia
de un entorno común de desarrollo de servicios, cada servicio tenía que desarrollarse
47
2.7. SERVICIOS IMS
' $
Figura 2.19.: Establecimiento de sesión desde una red PSTN hacia IMS.
& %
desde cero.
Con la aparición de la arquitectura de IMS; muchas funciones pueden ser
reutilizadas para la creación y despliegue rápido y eficaz de servicios. Como se ha
venido comentando con anterioridad, los servicios IMS se alojan en los Application
Servers, situados en la capa de aplicación de IMS y controlados desde la capa de
control. Por ejemplo, IMS define cómo las peticiones de servicio se encaminan, qué
protocolos soportan, cómo se realiza la tarificación y cómo se produce la integración
de servicios. Un solo AS puede albergar múltiples servicios — por ejemplo telefonía
y mensajería —. La colocación de múltiples servicios tiene ventajas significativas, la
primera de ellas la reducción de nodos de la red IMS. Además, al colocar los servicios
en un AS, disminuye la carga del CSCF en el plano de control.
Se observan en la parte baja de la figura 2.20 los servicios “básicos”, los que la
mayoría de la sociedad estaría de acuerdo en desplegar (servicios sociales, seguridad
pública, etc.). Estos servicios tendrían un atractivo de mercado enorme. Sin embargo,
estos servicios pasan por tener unos bajos ingresos, ya que no soportan un gran
volumen de carga.
En la parte alta de la figura 2.20 se muestran los servicios (de ocio). Pueden tener
un mercado menos atractivo, pero pueden aportar mayores beneficios – de hecho
pueden ser el tipo de servicios que den beneficios a corto plazo –.
48
Figura 2.20.: Servicios IMS organizados según necesidad y movilidad
Por otro lado, queda patente que muchos servicios además atraen tanto a usuarios
fijos y móviles, por lo que crean la necesidad que persigue cubrir IMS: independencia
en el acceso a la hora de proveer servicios.
IMS ofrece los elementos necesarios para el desarrollo de servicios de valor añadido
como: servicio de presencia, mensajería, conferencias y Push-To-Talk over
Cellular (PoC).
En siguientes secciones se pormenorizarán diferentes aspectos sobre cómo IMS
implementa estos servicios o cómo se desarrollan desde el punto de vista de los
entornos de implementación. Sin embargo, es preciso mostrar, aunque sea con
carácter introductorio, aquellas características más importantes de estos servicios
y las conclusiones más relevantes derivadas de su estudio.
2.7.1 El servicio de presencia

En el momento de elaboración de este proyecto existen muchas líneas de
investigación centradas en el servicio de presencia (por ejemplo [16], [17] y [18]).
Todas ellas apuntan a que el servicio de presencia es una característica clave para
cualquier servicio móvil, ya que proporciona información acerca de la disponibilidad
del usuario.
La información de presencia incluye:
Disponibilidad del usuario y del terminal.
Preferencias de comunicación del usuario.
Capacidades del terminal.
Información sobre el estado de las actividades que el usuario mantiene activas.
Para dar soporte a estas nuevas características de presencia, el protocolo SIP define
dos entidades:
49
2.7. SERVICIOS IMS
1. Presence Agent (PA): El Agente de Presencia almacena la información de

la suscripción y genera las diferentes notificaciones como por ejemplo las de
cambios de estado.
2. Presence User Agent (PUA): El Agente de Usuario de Presencia es el
encargado de procesar la información de presencia y publicarla.
2.7.2 Servicio de mensajería

Existen tres tipos de mensajería en IMS:
1. Mensajería instantánea, Instant Messaging o IM: basada en el uso del mensaje
SIP MESSAGE, proporciona un servicio de mensajes prácticamente en tiempo
real. Son universalmente conocidos gracias a Internet los servicios IM como
MSN Messenger, AOL IM (AIM), Yahoo o Google Talk.
2. Mensajería basada en sesión. En esta modalidad, se debe iniciar una sesión
previa al envío de mensajes. Una vez iniciada una sesión, los mensajes se
intercambian y la sesión termina. Este servicio es similar al de Internet Relay
Chat (IRC), descrito en la RFC 2810.
3. Mensajería offline, similar al servicio de Multimedia Messaging System de
mensajería multimedia.
2.7.3 PoC, Push to talk Over Cellular

El PoC es un servicio bidireccional que permite la comunicación instantánea con
uno o más usuarios.
Desde el punto de vista del usuario, el sistema PoC funciona de un modo parecido
a los tradicionales walkie-talkie: los usuarios que pertenecen a un mismo grupo PoC
pueden siempre escuchar al usuario que aprieta el botón y habla. No es necesario
nada más.
El servicio PoC fue estandarizado por la Open Mobile Alliance (OMA) con la
perspectiva de ser el primer servicio basado en IMS en ser provisto por los operadores,
ya que no requiere ningún despliegue adicional en la interfaz radio. Por ser un servicio
walkie-talkie, soporta una comunicación half-duplex en la que solo un usuario puede
hablar cada vez. Puede parecer contradictorio, teniendo en cuenta la excelencia
presente en las llamadas de voz. Sin embargo, la gran ventaja de PoC es que este
servicio puede funcionar sobre enlaces de poco ancho de banda y con grandes retrasos
sin mermar la experiencia de los usuarios. Estos enlaces serían inviables para soportar
llamadas de voz.
Este servicio tan simple desde el punto de vista del usuario afecta al plano de
transporte y al de señalización SIP. La arquitectura IMS soporta los siguientes
aspectos del servicio PoC:
Autenticación y autorización del cliente PoC para la unión del usuario a un
grupo PoC en base a su perfil de usuario.
50
Encaminamiento de los mensajes de señalización entre un cliente y un servidor

PoC.
Descubrimiento del servicio y traducción de direcciones.
Mantenimiento del estado del usuario.
Tareas comunes a todos los servicios como son la compresión de los mensajes
SIP para reducir la señalización en la interfaz radio y la tarificación.
Asimismo, el servidor PoC forma parte del grupo de SIP ASs dentro del core
SIP de servicios.
51
3. UN ENTORNO DE
DESARROLLO: EL SDS DE
c
ERICSSON
3.1 Herramientas de desarrollo de aplicaciones y servi-

cios IMS: ¿Por qué el SDS?
Como se verá en el capítulo 5, existen soluciones IMS concretas que ofrecen algunos
proveedores y operadores de telecomunicaciones como Ericsson, Nokia, Vodafone
o Telefónica Móviles. Sin embargo, la mayoría de estas iniciativas consisten en
actuaciones dedicadas y a medida del cliente, o a medida de un operador concreto.
Sin embargo, IMS pretende aportar más servicios de los que puede aportar el propio
core, su objetivo es proporcionar un marco estándar para que la amplia comunidad
de desarrolladores existente en Internet pueda adaptarse rápidamente a IMS y
aprovechar sus ventajas proponiendo servicios novedosos cada vez más centrados
en el usuario. Para lograr este objetivo, es preciso disponer de las herramientas
de desarrollo que faciliten la programación de servicios y aplicaciones IMS. Los
principales entornos — más escasos en número que las soluciones IMS a medida
— se describen brevemente a continuación aportando los datos suficientes para un
estudio comparativo posterior que proporcione una idea justificada de la elección de
una herramienta frente a otras.
3.1.1 RADVISION IMS Developer Suite

RADVISION es una compañía dedicada durante más de una década a soluciones
de voz y vídeo sobre IP y experta en mercados 3G. Para IMS, RADVISION ofrece
una herramienta de desarrollo de aplicaciones formada por bloques constituyentes
que son a su vez herramientas de desarrollo para los protocolos de señalización y de
medios de IMS. En la figura 3.1 se observa mejor la heterogeneidad de la solución
de RADVISION.
Esta herramienta se compone pues de cuatro entornos de desarrollo para protocolos,
a saber: SIP (IMS SIP Toolkit), MeGaCo (IMS MEGACO/H.248 Toolkit),
DIAMETER (IMS DIAMETER Toolkit), RTP/RTCP (IMS Advanced-RTP/RTCP
Toolkit). Además, para el soporte de estos desarrollos, la suite de RADVISION
aporta plataformas de servidor, cliente y testeo: las plataformas IMS SIP Server
Platform, IMS Client Suite y ProLab IMS Test Solution.
Los toolkits de desarrollo facilitan la programación sobre los protocolos de
53
3.1. HERRAMIENTAS DE DESARROLLO DE APLICACIONES Y SERVICIOS IMS: ¿POR QUÉ EL SDS?
' $
Figura 3.1.: Esquema general de los bloques que componen el IMS

Developer Suite. Fuente: RADVISION
& %
IMS, asistiendo la creación de mensajes de protocolo y estableciendo modelos de

comunicación de cliente-servidor. Contienen documentación, aplicaciones de muestra
y guías tutoradas. Además, la programación está basada en el cumplimiento de los
protocolos uno a uno, por lo que permite cubrir prácticamente todas las interfaces
de IMS. El desarrollador ha de aprender los asistentes para la creación de mensajes
de protocolo, inserción de cabeceras, etc.
Tanto la plataforma cliente como la del servidor ofrecen soporte a las aplicaciones
creadas con los toolkits e incorporan los bloques necesarios para el despliegue de
aplicaciones cliente y servidor. La plataforma servidora proporciona los servidores
SIP de IMS, así como funcionalidades de los servidores de aplicaciones (B2BUA,
Redirect,...). La plataforma cliente es un framework independiente del sistema
operativo — por lo que es multiplataforma — y mapea las capacidades IMS del
lado del cliente a través de APIs de alto nivel propietarias.
Por último, la suite de testeo está diseñada para perfeccionar los servicios creados
y completar el ciclo de desarrollo. Consiste en un paquete de scripts embebidos en
la herramienta y plug-and-play, archivos de medios de pruebas, simulación avanzada
del User Equipment (UE), señalización online y análisis de los medios y su calidad.
Todo ello integrado en una plataforma de testeo del equipo de usuario (UE).
3.1.2 Nokia Siemens Networks IMS Developer Program

La solución de la multinacional formada por los gigantes Nokia y Siemens cambia
la visión de los desarrollos con respecto a la solución nativa en el protocolo
de RADVISION. Nokia Siemens apuesta por el desarrollo de APIs en lenguajes
archiconocidos como Java o .NET y por la integración en un entorno de desarrollo o
Integrated Development Environment (IDE) que agrupe de forma homogénea todas
las funcionalidades que aporta. Así, dentro de Nokia Siemens Networks se ha
aprovechado su experiencia en desarrollos IMS a medida [19, 20] para desarrollar
una herramienta para la creación de servicios IMS integrable con las herramientas
de desarrollo, IDEs, emuladores y sistemas operativos favoritos del desarrollador.
54
Para el desarrollo del servidor la solución de la herramienta de Nokia Siemens es

el IMS Network Emulator, un simulador del núcleo de la red de IMS (CSCF,
HSS) y simulador del servicio de presencia de la Open Mobile Alliance (OMA)
y un servidor XML Data Management. El IMS Network Emulator es en sí una
aplicación Java, por tanto multiplataforma. Incluye una interfaz gráfica Graphical
User Interface (GUI) para las configuraciones locales, y una interfaz Web para las
remotas.
Del lado cliente un desarrollador puede hacer uso del Java ME IMS SDK si
elige programar para teléfonos con soporte Java, o bien .NET IMS SDK para el
desarrollo de clientes Windows o Windows Mobile.
El Java ME IMS SDK proporciona el entorno de desarrollo para los terminales
con soporte Java ME. Este entorno incluye APIs de alto nivel para servicios SIP
e IMS. Este hecho reduce el tiempo de desarrollo, al ahorrar la implementación
de una pila SIP en el dispositivo y la elaboración de todos los mensajes de este
protocolo de cara a cubrir las necesidades del servicio que se desee desarrollar. Este
Software Development Kit (SDK) hace uso del borrador de la especificación JSR-
281 (pre-JSR-281), la API de servicios IMS. En este sentido es preciso apuntar que
existen dos versiones de la librería Java ME IMS SDK: la versión para dispositivos
más limitados (dispositivos con soporte MIDP 2.0/CLDC 1.1) que incluye una pila
SIP y compatibilidad con aplicaciones Java ME ligeras (CLDC). Asimismo, existe
otra versión del SDK dirigida a dispositivos con más capacidades como aquellos
con sistema operativo Symbian S60 3rd edition, que ofrecen un soporte mucho más
potente al protocolo SIP a través de la API JSR-180 para Java ME.
3.1.3 Ericsson Service Development Studio (SDS) y comparativa

En este apartado se argumenta la elección de esta herramienta de desarrollo de
Ericsson AB apoyados por una breve descripción como elemento comparativo con
respecto a las dos plataformas antes descritas. En secciones posteriores se estudia con
profusión la solución elegida y la metodología de creación y despliegue de servicios
IMS.
La compañía sueca Ericsson ha liderado durante los últimos años el desarrollo tanto
de hardware IMS como de soluciones software. El Service Development Studio (SDS)
es la herramienta de desarrollo de aplicaciones y servicios IMS y es parte del conjunto
de productos IMS de Ericsson. Por otro lado, Ericsson ha copado la tarea de la
especificación de las APIs para IMS como son la API de servicios IMS JSR-281 y la
API de enablers de la comunicación, la API JSR-325; y participado activamente en
los desarrollos para el servidor (especificaciones JSR-116 y JSR-289) y APIs para
el control de medios (JSR-309). Esta experiencia en el desarrollo de las librerías
para IMS queda patente en el SDS, que al igual que la solución de Nokia Siemens
proporciona APIs de alto nivel para ocultar la complejidad de la red y del dipositivo
para el desarrollador. Asimismo, incluye una mayor cantidad de plantillas, tutoriales,
códigos de ejemplo y asistentes para disminuir el tiempo de desarrollo.
El SDS está completamente integrado en el IDE Eclipse, siendo este factor una
55
3.2. ¿QUÉ ES EL SDS?
ventaja considerable al ofrecer un entorno conocido para los desarrolladores, pero

también una restricción al ligar el entorno de desarrollo a un IDE o plataforma
concreta. Tanto la solución de RADVISION como la de Nokia Siemens eran
multiplataforma. En contra del SDS juega su compatibilidad única con Windows en
la actualidad. No obstante, están contempladas más plataformas en su planificación
o roadmap.
Ofrecer APIs a los programadores en un lenguaje ampliamente extendido es un
factor clave para la proliferación de aplicaciones, por lo que este factor juega en
contra de la solución de RADVISION, que además implica una curva de aprendizaje
mucho más lenta.
A grandes rasgos, el SDS consiste en una plataforma que permite la creación de
aplicaciones y servicios tanto cliente como servidor extremo a extremo haciendo
uso de un simulador del core de IMS, soporte para la mayoría de enablers de
servicios estandarizados por la OMA (presencia, gestión de grupos, Push-To-Talk
over Cellular (PoC), mensajería IMS), APIs y plataformas del cliente (dispositivos
Symbian UIQ/S60 y CLDC), emuladores de dispositivos y servidores SIP. Con esta
breve enumeración ya es posible apreciar la mayor completitud de la solución de
Ericsson, dado que cuenta con un mayor soporte para dispositivos y para los enablers.
Y, sobre todo, la inclusión de un servidor de aplicaciones SIP potente, conforme al
estándar del 3GPP y a la API JSR-116 (y en un futuro la JSR-289) y basado en
tecnologías Java y centradas en Internet.
Sin embargo, la mayor ventaja es quizás la versatilidad para configurar la
herramienta como un simulador del core IMS en redes locales, remotas, con
componentes distribuidos, etc. Así como la capacidad de conexión con entornos
reales y servicios remotos de Ericsson1 como el Ericsson’s Remote IMS (RIMS) o el
IMS Expert Centre.
Con el estudio de las diferentes herramientas de desarrollo de aplicacione IMS ha
sido posible realizar una breve comparativa. Sin embargo, las ventajas del SDS,
así como su problemática o sus limitaciones, se perciben con un análisis más
pormenorizado a lo largo del presente capítulo y el capítulo 4.
3.2 ¿Qué es el SDS?

El Service Development Studio (SDS) es un conjunto de herramientas
software que permiten el desarrollo y testeo de aplicaciones que proporcionan
servicios extremo a extremo o end-to-end (e-2-e) basados en IP Multimedia
Subsystem (IMS). El SDS permite el desarrollo, simulación y testeo tanto del lado
cliente como servidor de las aplicaciones IMS2 .
1
En realidad de cualquier otra compañía, puesto que IMS es un estándar, pero se indica Ericsson
ya que sus productos están desarrollados y son conocidos.
2
Una vez se está tratando el entorno de desarrollo software, el concepto de aplicación va ligado al
de servicio ya que los programas o aplicaciones desarrollados con el SDS tienen la máxima de
proporcionar servicios IMS al usuario. No obstante, el concepto de servicio es aún más amplio,
dado que un servicio puede ser una combinación de aplicaciones que proporcionen servicios de
56
El SDS proporciona APIs del servidor basadas en el estándar, así como una
arquitectura emulada del core IMS y APIs de alto nivel para la parte cliente y
para los servicios de comunicaciones.
Con la combinación de un “contenedor” SIP (o SIP container) real y sus
herramientas de desarrollo, el SDS permite a los operadores de red fijos y móviles y a
los proveedores de servicios desarrollar de una manera más sencilla y rápida servicios
de valor añadido y de gran calidad. Estos servicios han de ser los que catapulten
IMS para poder satisfacer todas las posibilidades que presentan las redes de nueva
generación.
El Service Development Studio (SDS) es un producto de Ericsson
c perteneciente al
Ericsson IMS Solution, el conjunto de soluciones tecnológicas tanto hardware como
software para IMS en las que Ericsson es líder mundial [21]. Por lo tanto, Ericsson
ha diseñado todas sus herramientas de acuerdo al estándar y compatibles entre sí,
con la idea de estar presente en todo el proceso ligado a una aplicación, desde la idea
y requerimientos iniciales, hasta el despliegue en una red real. Las primeras fases
se completarían con el SDS, y a partir de ahí, el software del servicio desarrollado
podría desplegarse de forma transparente en el entorno real IMS Common System
de Ericsson. En concreto en los servidores de aplicación – como por ejemplo es
el Oracle (BEA3 ) Web Logic SIP Server (BEA WLSS) [22] o el polivalente Oracle
Communications Converged Application Server (OCCAS) –. De esta manera, el SDS
puede configurarse para simular el núcleo IMS completo e incluso funcionar como un
efectivo (y prácticamente gratuito) servidor JEE/SIP4 como banco de pruebas real
de un servicio. Asimismo, es posible interconectar el SDS con entornos reales para
verificar eficientemente los servicios y realizar las pruebas pertinentes sin repercutir
gravemente en el coste.
La herramienta de desarrollo SDS viene integrada como un conjunto de plugins
del framework Eclipse Integrated Development Environment (IDE)5 . Es
decir, las capacidades del SDS se presentan como un conjunto de plugins dentro de
la interfaz de usuario del Eclipse IDE. En la figura 3.28 se muestra el entorno de
trabajo de Eclipse, con la herramienta de desarrollo de aplicaciones y servicios de
IMS, SDS, completamente integrada como parte del workbench.
poco valor añadido por sí mismos pero que combinados ofrezcan una solución más atractiva.
3
Oracle adquirió BEA Systems en 2008, así como BEA Systems adquirió Weblogic, Inc. en 1998.
4
El SDS está completamente integrado, a partir de su versión 4.0 con el Sailfin JEE/SIP
Application Server.
5
Eclipse, o Eclipse Platform formalmente, es en sí una amalgama de plugins. A pesar de
tener muchas funcionalidades nativas, son a veces muy genéricas. Se necesitan herramientas
adicionales para extender la plataforma para trabajar con nuevos tipos de contenidos, llevar a
cabo nuevas capacidades o “especializar” la herramienta en un ámbito específico. La plataforma
Eclipse trae un mecanismo de descubrimiento, integración y ejecución de módulos llamados
plugins. Un proveedor de una herramientas las desarrolla como un módulo por separado pero
para que opere con los archivos del workspace y superponga sus elementos de interfaz de usuario
en este mismo espacio de trabajo o workspace. Cuando Eclipse se arranca, el usuario percibe
un entorno de desarrollo integrado (IDE) compuesto de un conjunto de plugins disponibles.
57
3.2. ¿QUÉ ES EL SDS?
Figura 3.2.: Ventana del workbench del SDS
3.2.1 Beneficios del SDS

El SDS se ejecuta en un PC con entorno Windows y soporta, como ya se ha
introducido, la creación aplicaciones IMS cliente y servidor y permite su testeo y
validación extremo a extremo (end-to-end). Para ello, simula6 el core de la red IMS,
los enablers de servicios, el dispositivo móvil y los servidores JEE/SIP. Todo ello
ofreciendo una solución intuitiva y orientada a los estándares para el desarrollo de
nuevos servicios y aplicaciones.
El SDS proporciona APIs para ocultar la complejidad de la red y del dispositivo
al programador, e incluye multitud de plantillas y asistentes (wizards) para agilizar
las primeras fases de los desarrollos.
Con el SDS, los desarrolladores pueden emplear estas APIs para controlar y acceder
a capacidades avanzadas como el PGM, VoIP, o el PoC (o PTT) descritas en el
capítulo 2 e incluso en su versión 4.1 ya incorpora un simulador de Internet Protocol
Television (IPTV) y en entregas posteriores se añadirá soporte para servicios
adicionales como la telefonía IMS (IP Multimedia Telephony). Además, se verá en
la sección 3.3 la hoja de ruta o roadmap que plantea Ericsson para su herramienta
SDS. En esta planificación vienen detalladas las funcionalidades que incorpora a
cada versión, vislumbrándose soporte para la gestión del Business and Operations
Support Systems (BSS/OSS) por parte del operador: configuración de dispositivos,
6
Aunque en este documento se utiliza a menudo el término de “emulador” se considera que,
en rigor, el SDS simula núcleo de la red IMS. Si fuera un emulador, trataría de imitar
el funcionamiento del core igualando su comportamiento e incluso mejorando aspectos del
propio entorno real. Esto no es así, porque como se verá más adelante, la herramienta presenta
limitaciones y en ningún caso iguala las funcionalidades de una red IMS real, en cualquier caso
las simplifica.
58
gestión de clientes, provisión, tarificación y operación y mantenimiento (Operations

and Maintenance (O&M)).
De igual manera, es posible configurar el SDS — aparte de como un emulador del
núcleo de red IMS — como un entorno de ejecución de un servidor JEE/SIP rentable
para ensayos y pruebas de servicios IMS.
3.2.2 Subsistemas del SDS y características esenciales

El SDS 4.1 FD1, su última versión aparecida durante la redacción de este proyecto,
consta de los siguientes subsistemas, indicando entre paréntesis su denominación en
la interfaz de la herramienta:
Entorno de diseño (Design Environment)

Entorno visual (Visual Network)
Framework de cliente IMS (ICP y IJCU) (IMS Client Framework)
Plataforma de cliente IMS (ICP) (IMS Client Platform)
Utilidad de cliente IMS JME (IJCU) (IMS JME Client Utility)
Emulador de dispositivo móvil (Handheld Device Emulator)
Emulador de servidor (Server Emulator)
Emulador del núcleo IMS (IMS Core Network Emulator)
Emulador de presencia y gestión de grupos (PGM) (Presence and Group
Management Enabler Emulator)
Emulador de push-to-talk (PoC) (Push-to-Talk Enabler Emulator)
Emulador de mensajería IMS (IMS Messaging Enabler Emulator)
Emulador de televisión IP (Internet Protocol Television (IPTV) Emulator)
API de servicios para el cliente y el servidor (Service APIs (Server and Client))
Entorno de testeo o pruebas (Test Environment)
3.3 Futuras versiones y roadmap

El objeto de estudio es el Service Development Studio (SDS) 4.1, aunque no hay
que olvidar que fue concebido con la planificación o roadmap que se muestra en la
figura 3.3. Aunque con retrasos y modificaciones en su cronograma (la versión 4.1
FD1 ha salido cuando en el roadmap está planificada la 5.0), Ericsson ha sido fiel a
las capacidades que incluirá en sus versiones y que se ilustran en la figura 3.3.
59
3.4. SUBSISTEMAS DEL SDS Y SU MODO DE USO
Figura 3.3.: Planificación de las distintas versiones del SDS junto con sus capacidades y estado
de release. Fuente: Ericsson.
3.4 Subsistemas del SDS y su modo de uso

3.4.1 Entorno de diseño (Design Environment)
El entorno de diseño del SDS se ha diseñado para reutilizar prácticas comunes y
estándares de la comunidad de desarrollo de Java. Por consiguiente, el entorno de
diseño está basado en el IDE gráfico de la plataforma de desarrollo Eclipse [23].
Este entorno para desarrolladores en Java 2 Platform Enterprise Edition (J2EE)
está constituido por Eclipse 3.4 y la plataforma de herramientas web Web Tools
Platform (WTP) 3.0, que incluye numerosas mejoras respecto a versiones anteriores.
Prácticamente, este IDE contiene todo lo que un programador de Java necesita para
desarrollar aplicaciones Java y J2EE. Ericsson escogió Eclipse y las Web Tools para
su SDS auspiciada por su éxito y por ser considerada por muchos la mejor plataforma
de desarrollo en Java.
Algunas de las características más importantes proporcionadas por el IDE
Eclipse se encuentran en los asistentes de proyectos o wizards, asistente de
codificación, edición Java con compilación incremental, soporte Java EE, editor
gráfico de lenguajes web HTML, JSP y JSF, herramientas de gestión de bases de
datos, soporte para servidores de aplicación, depuración, testeo, etc. son El SDS
ofrece un conjunto de herramientas de última generación que se integran en Eclipse
y lo extienden con las siguientes características:
60
Asistentes de proyectos SIP/Web dinámicos (Dynamic SIP/Web Project

Wizard)
Asistente de creación de Servlets SIP (SIP Servlet Wizard)
Asistente de listeners SIP (SIP Listener Wizard)
Editor del descriptor de despliegue SIP (SIP Deployment Descriptor Editor)
Editor del descriptor de despliegue HTTP (Web Deployment Descriptor
Editor) (web.xml) (Característica Eclipse )
Debugger o depurador (Característica Eclipse)
La construcción y el despliegue (deploying) o repliegue (undeploying) del
proyecto (Característica WTP)
Launcher del conversor de aplicaciones SIP heredadas (Converting a Legacy
SIP Application Simulation Environment Launcher)
Visor del flujo de tráfico (Visual Traffic Flow)
Vista de red (Visual Network)
Entorno de testeos automatizados (Automated Testing Framework)
Agente SIP de testeo (SIP Test Agent)
Vista de cliente IPTV (IPTV Client View)
Asistente de creación de cliente sobre ICP (ICP Client Application Wizard)
Plugin para Nokia Carbide C++ para desarrollo de clientes sobre ICP (ICP
Client Development Plug-in for Nokia Carbide.c++ Express)
Creación de clientes sobre ICP en Microsoft Visual C++ 2008 Express Edition
(ICP Client Development on Microsoft Visual C++ 2008 Express Edition)
Instalación de ICP sobre emulador Symbian (Install ICP in Symbian
Emulator)
Instalación del fichero instalador (SIS) (ICP o aplicación cliente) en un
dispositivo Symbian (Install SIS file in Symbian Device (ICP or Client
Application))
Lanzar emulador Symbian (Start Symbian Emulator)
Instalar cliente en Windows (Install Client in Windows)
Herramienta de depuración para Windows (Windows OS Client Debugger)
Instalar o desinstalar (Install (Uninstall) Client in Symbian Emulator)
Crear un fichero SIS (Create SIS File)
Herramienta de creación de proyectos IJCU (IJCU Project Creator)
Despliegue de aplicaciones IJCU en el emulador (IJCU Application Deployment
on Emulator)
Despliegue de aplicaciones IJCU en teléfonos concretos (IJCU Application
Deployment on Feature Phones)
61
Javadoc de la API de la ICP (ICP API Javadoc)

Javadoc de la API para el IJCU (IJCU API Javadoc)
Cppdoc para la API de la ICP (ICP API Cppdoc)
El SDS diferencia entre el entorno de diseño (Design Environment) y el entorno
de ejecución (Execution Environment). El entorno de diseño es la herramienta
gráfica con la que el usuario interactúa, mientras que el entorno de ejecución es el
conjunto de procesos que, en segundo plano, simulan la red IMS, los servidores de
aplicación y los servicios que se alojan en estos. Cuando el entorno de ejecución se
instala en un PC con Windows, éste se controla con el entorno de diseño del SDS.
El entorno de diseño se divide en diferentes perspectivas o vistas acordes a los
procesos del usuario y sus actividades de diseño:
Development Perspective (un conjunto de perspectivas Java y JavaEE)
Provisioning Perspective
Visual Network Perspective
Automated Testing Framework (ATF) Perspective
Visual Traffic Flow (VTF) Perspective
Debugging Perspective
El usuario puede cambiar de perspectiva fácilmente desde la ventana de Eclipse.
En el SDS, las aplicaciones IMS de la parte servidora – comúnmente denominado
el “servidor” de una aplicación– se crean:
1. Abriendo un Dynamic SIP/Web Project
2. Creando un SIP Servlet 7
3. Añadiendo un SIP Listener si es preciso
4. Editando el Deployment Descriptor si es preciso
5. Desplegando la aplicación en el servidor de aplicaciones8 .
Es posible desarrollar aplicaciones en el SDS acordes a las especificaciones Java
Specification Request (JSR) 116 [24] y/o JSR 289 [25] definidas por el Java
Community Process (JCP). La especificación JSR 116 define la API del SIP Servlet,
mientras que la JSR 289 actualiza las especificaciones de la JSR 116 y define un
modelo estándar para la programación de aplicaciones para aunar SIP Servlets y
componentes Java EE. Para ello, la JSR 289 extiende las funcionalidades de la
JSR 116 e introduce nuevos mecanismos de “disparo” o triggering basados en un
Application Router [26] (frente al uso único de las reglas de asociación de los Servlets,
las Servlet Mapping Rules).
7
Recordar que un Servlet es, grosso modo un programa o aplicación que se ejecuta en un servidor
(se entiende un servidor de aplicaciones, o AS).
8
El Application Server (AS) del SDS 4.1 de estudio es el servidor de aplicaciones SailFin,
integrado con el AS Java EE de código abierto Glassfish. Es decir, SailFin extiende el servidor
de aplicaciones Java Glassfish para que soporte funcionalidades del protocolo SIP. SailFin se
basa en un código abierto donado por Sun, Oracle y Ericsson.
62
Figura 3.4.: Ventana del Dynamic SIP/Web Project Wizard
Las reglas para el triggering de aplicaciones descritas en la JSR 289 se encuentran en

el router de aplicaciones, de tal forma que quedan externas a la aplicación SIP. Con
el router de aplicaciones, las mapping rules pierden peso en la JSR 289. Además, no
hay que olvidar que la JSR 289 hace uso de annotations, que son tipos de metadatos
recogidos en tiempo real.
El asistente o wizard para un proyecto SIP/Web dinámico: Dynamic

SIP/Web Project Wizard
En el SDS, las aplicaciones se crean por medio de asistentes que integran la
plataforma WTP. De este modo, haciendo click en el icono de Dynamic SIP/Web
Project Wizard de la barra de herramientas del SDS, aparecería la ventana de la
figura 3.4 del asistente para la creación de un proyecto SIP/Web dinámico.
Como se observa en la figura 3.4, en el asistente es posible seleccionar la API para
seguir las especificaciones de la JSR 116 (opción SIPServlet API v1.0 Converged
Project) o la JSR 289 (opciones SIPServlet API v1.1 y Default Configuration for
SailFin v1).
El campo de target runtime contiene la selección del servidor de ejecución donde
las aplicaciones se ejecutarán, en este caso, como se ha comentado previamente, el
AS por defecto es el SailFin v 1.0.
A través del botón modify se puede seleccionar las facets de la Web Tools Platform
(WTP). Estas facets son extensiones de la plataforma de herramientas web WTP
63
Figura 3.5.: Ventana de facets del proyecto
para añadir o restar funcionalidades al proyecto. Existen facets para J2EE, web y
algunos otros tipos de aplicación. El SDS define, además, una facet adicional para
SIP. La ventana Project Facets window muestra la configuración actual y las facets
disponibles para el proyecto. Para proyectos SIP como los de IMS, las facets The
Dynamic Web Module, Java, y SIP Servlet API son obligatorias, y como se ilustra
en la figura 3.5 están seleccionadas por defecto.
Finalmente, los proyectos se empaquetan automáticamente en ficheros SIP ARchive
.sar, pero es posible compilarlos en ficheros Enterprise ARchive .ear para ejecutarlos
como aplicaciones (empresariales) Java.
El asistente o wizard para crear un SIP Servlet

Para crear un SIP Servlet es necesario haber creado previamente un proyecto
SIP/Web dinámico, tal y como se describe en el paso anterior. A partir de ahí,
se selecciona el proyecto y haciendo click en el icono del wizard se pasa al asistente
para crear un SIP Servlet
Este asistente genera un esqueleto de un SIP Servlet basado en las necesidades del
usuario. A partir de este esqueleto, el usuario añade la lógica asociada al servicio
que desee implementar. El servlet generado se añade automáticamente al proyecto
que se creó previamente.
El usuario hará uso de la página de métodos (methods) y recursos (resources) para
seleccionar los métodos que desee incluir en el servlet y los recursos estándar que
utilizará el servlet. Además, el usuario podrá definir las condiciones bajo las cuales
se ejecutará el servlet haciendo uso de las SIP Servlet Mapping Rules.
El asistente o wizard para crear un SIP Listener

El wizard para la creación de SIP Listeners permite, al igual que en el caso de
los servlets, generar una clase esqueleto para manejar los eventos que sucedan
64
Figura 3.6.: Definición del SIP Servlet
durante la ejecución de las aplicaciones, como por ejemplo eventos de sesión,

errores o temporizadores. Para lanzar este wizard hay que tener seleccionado el
proyecto concreto y hacer click en el icono de la barra de herramientas del SDS
correspondiente a este wizard para listeners, ilustrado en la figura 3.7.
Figura 3.7.: Definición del SIP Listener
65
Figura 3.8.: Definición del fichero de despliegue SIP en su design window
Figura 3.9.: Source Window
Editor del descriptor de despliegue (sip.xml) (Deployment Descriptor

Editor )
El editor del deployment descriptor permite al programador editar o actualizar el
descriptor de despliegue9 (fichero sip.xml) accediendo a éste directamente como
fichero de texto. El fichero puede visualizarse bajo la vista de diseño del SDS, donde
los elementos del fichero XML se introducen en una estructura que asegura su validez
XML (ver figura 3.8). O bien bajo la vista de fuente o source view, que permite editar
el fichero con total libertad (ver figura 3.9).
9
La principal función de un contenedor de servlets es llevar a cabo el enrutado de las peticiones
hacia las aplicaciones. Para permitir esto, hay una serie de reglas asociadas a cada aplicación
y especificadas en un fichero XML llamado el descriptor de despliegue de la aplicación.
Contiene detalles del: nombre del servlet, mapeo del servlet, parámetros iniciales, condiciones
de seguridad y detalles de login. Se usan para servlets SIP (sip.xml) y HTTP (web.xml).
66
Figura 3.10.: Ventana del debugger
Editor del descriptor web (web.xml) (Web Deployment Descriptor Editor )

Este editor es análogo al anterior, pero referente al despliegue web descrito en el
fichero web.xml.
Depurador (Debugger )
El debugger permite al desarrollador establecer puntos de ruptura o breakpoints en
el código fuente de las aplicaciones Java o SIP. La ejecución se detiene al llegar a
estos puntos y en ese momento se puede examinar la estructura interna de los datos
así como controlar la ejecución de la lógica de servicio paso a paso. El debugger es
común a todos los IDEs y viene integrado con Eclipse (ver figura 3.10).
La construcción y el despliegue (deploying) o repliegue (undeploying) del

proyecto
Para desplegar y ejecutar un proyecto en el servidor de aplicaciones (AS) del SDS
(por defecto SailFin) es preciso seleccionar el proyecto con el botón secundario y en
el menú desplegado, seleccionar Run As >Run on Server10 . Se verá más adelante las
implicaciones de este hecho en la arquitectura de IMS.
También es posible replegar el proyecto desplegado a través de la interfaz gráfica
de servers view.
Convertir aplicaciones SIP heredadas de otras versiones

Debido a que esta versión de estudio, la 4.1 FD1 y más reciente hasta la fecha utiliza
WTP como sustrato del entorno de diseño, las aplicaciones SIP creadas con versiones
previas del SDS (SDS 4.0 o SDS 4.0 FD1) pueden ser convertidas para su manejo
10
Es necesario anotar en este punto que es posible lanzar otro servidor JEE/SIP de terceros
haciendo uso de la pestaña WTP’s Server.
67
Figura 3.11.: Ventana del conversor de aplicaciones heredadas de otras versiones
en la versión 4.1. Esta conversión se lleva a cabo con el Legacy SIP Application
Converter Wizard o asistente para la conversión de aplicaciones SIP heredadas11 .
Una vez realizada la conversión, el proyecto no es compatible hacia atrás, de forma
que no se puede volver a utilizar en la versión previa donde fue creado12 . Este wizard
de conversión está completamente integrado en el IDE con un botón propio en la
barra de herramientas que da acceso a la ventana del asistente 3.11.
Launcher del entorno de simulación y visualización de red (Visual Network)

El entorno de simulación (de la red IMS) consiste en el CSCF (integrando el P-
CSCF, I-CSCF y S-CSCF, e incluyendo el HSS y el BGCF), un DNS y un servidor
de Push-To-Talk over Cellular (PoC). Cada uno de estos elementos de la red IMS
simulada pueden inicializarse o detenerse individualmente desde el menú “SDS”,
como ilustra la figura 3.12.
En el modo de visualización de red, Visual Network o Network View también
es posible iniciar o detener la actividad de estas funciones de la red simulada
haciendo click con el botón secundario y seleccionando Start. Esta perspectiva
de visualización consiste en una representación gráfica del entorno de simulación
(CSCF, DNS y PoC), así como del emulador de Symbian. Está basada en una
Graphical User Interface (GUI) que permite seleccionar qué nodos simulados
representar, e interactuar con los elementos de manera que es posible cambiar su
estado de ejecución y acceder a sus paneles de configuración simplemente haciendo
doble click y seleccionando la opción deseada.
11
La conversión de aplicaciones IMS desarrolladas con la versión 3.1 del SDS no es inmediata
ni existe ningún asistente para ello. Para poder reutilizarlas y añadir las funcionalidades de
versiones más modernas es preciso reeditar el código teniendo en cuenta la nueva arquitectura
de clases del cliente que se verá más adelante.
12
Para evitar posibles pérdidas a la hora de convertir un proyecto, existe la opción de hacer una
copia de seguridad o backup antes de completar el proceso de conversión.
68
Figura 3.12.: Launcher de los elementos de la red para inicializarlos o detenerlos en el entorno
de simulación.
Figura 3.13.: Visual Network con todos sus nodos tanto de red como de cliente (el emulador
de Symbian) y el menú de interacción gráfica.
69
Figura 3.14.: Visual Traffic Flow
Visualización del flujo de tráfico: diagramas de paso de mensajes

El Visual Traffic Flow (VTF) es una herramienta que genera diagramas de
secuencias de mensajes SIP a partir de datos almacenados en un archivo de log o
bien a partir del tratamiento de datos en tiempo real obtenidos del CSCF simulado
del SDS. A día de hoy, el VTF sólo procesa tráfico SIP sobre UDP a través del
CSCF, por lo que no se soporta aún señalización SIP sobre TCP. Cuando los logs se
analizan los elementos, mensajes y entradas se muestran como usuarios, diagramas
de paso de mensajes y descripciones, tal y como se muestra en el ejemplo de la
figura 3.14.
El entorno de testeo
En el SDS, desde sus orígenes, venían incorporadas dos entornos para el testeo de
las aplicaciones IMS: el SIP Test Agent y el Automated Testing Framework (ATF).
El primero consiste, grosso modo, en una interfaz para probar el comportamiento
de las aplicaciones ante mensajes SIP concretos elaborados por el programador. El
segundo es un entorno que permite simular escenarios concretos de funcionamiento
en la red IMS, facilitando la realización de baterías de pruebas. Ambos frameworks
de testeo se lanzan desde el menú cliente del SDS, ilustrado en la figura 3.15.
El SIP Test Agent El SIP Test Agent permite testar el comportamiento de una
aplicación ante cualquier tipo de mensaje. Proporciona un mecanismo para crear
cualquier tipo de mensaje real. Este hecho da lugar a la posibilidad de que el
desarrollador teste las aplicaciones y analice sus respuestas a mensajes específicos,
ya sean válidos o no válidos. Esta herramienta es flexible para numerosos escenarios.
Es posible crear uno o más clientes (test clients) que envíen, reciban o respondan a
determinadas peticiones SIP. Para crear mensajes SIP correctos, es posible utilizar
70
Figura 3.15.: Menú cliente del SDS, con el acceso al SIP Test Agent y el ATF.
un generador de mensajes, consistente en un asistente para facilitar la tarea de la

creación del mensaje inicial y subsecuentes. Este asistente se encuentra en el botón
“New Request” de la parte izquierda del Test Agent de la figura 3.16.
Figura 3.16.: SIP Test Agent
El Automated Testing Framework (ATF) El ATF se utiliza para crear, editar

y ejecutar escenarios de testeo descritos en scripts para automatizar la fase de
pruebas de las aplicaciones desarrolladas. Simula el comportamiento del cliente, sin
la necesidad de programar una aplicación cliente. Queda ilustrado en la figura 3.17.
71
Figura 3.17.: El Automated Testing Framework (ATF)
Cliente de Internet Protocol Television (IPTV)

El SDS, a partir de su versión 4.1 FD1 pone a disposición de los desarrolladores
de IPTV el IPTV Simulator, un middleware que hace efectiva la interacción de
aplicaciones de IPTV con la red IMS.
El asistente o wizard para aplicaciones cliente sobre ICP

El ICP Client Application Wizard genera un proyecto marco (framework para una
aplicación cliente). Para crear la aplicación cliente sobre ICP, es preciso disponer
y seleccionar un proyecto sobre el que se quieren añadir capacidades de la ICP en
el Package Explorer. Posteriormente, se ejecuta el wizard 3.18, que proporciona un
asistente paso a paso para que el desarrollador seleccione las propiedades que estime
oportuno para el cliente IMS que desarrolla.
A lo largo de cada paso del asistente es posible configurar los siguientes atributos:
Tipo de servicio IMS (esto es, PGM, VoIP, PoC, IMS Messaging, servicios
integrados o “combinacionales”)
Dispositivo al que está orientada la aplicación (basado en Symbian o Windows)
Nombre del cliente y su ubicación
Otros atributos
El asistente de creación de aplicaciones cliente IMS genera la estructura de una
aplicación cliente IMS. Los pasos para la creación de un cliente IMS pueden
resumirse en:
Crear un proyecto ICP y añadir las capacidades de la plataforma ICP
Codificar, compilar y depurar
72
Figura 3.18.: El asistente o wizard para aplicaciones cliente sobre ICP
Instalar la ICP y la interfaz gráfica (UIQ o S60) que mostrará el dispositivo

cliente en el entorno objetivo (emulador o dispositivo real)
Inicializar el entorno de Ejecución: core, Application Server, Enablers de
servicio
Configurar el perfil de usuario (como se vio en el capítulo 2 en lo referente a
los inital Filter Criteria) de la ICP
Ejecutar la aplicación
Llevar a cabo pruebas o testeos extremo a extremo haciendo uso de los nodos
IMS del SDS, el servidor y los simuladores de servicios
Solucionar problemas (troubleshooting)
Plugin para el desarrollo de aplicaciones cliente ICP para Nokia Carbide

C++ Express
El SDS proporciona una extensión (un ICP plugin) que permite desarrollar
aplicaciones IMS sobre la herramienta de desarrollo Nokia Carbide C++ (Express
v1.3). Carbide C++ es una herramienta de desarrollo basada en Eclipse para la
interfaz gráfica para móviles de Nokia, la plataforma Nokia S60. Esta extensión
puede añadirse seleccionando SDS >Client >Install SDS Extensions in Carbide.
Esto instalará el ICP plugin sobre Carbide y permitirá la creación de aplicaciones
IMS para móviles basados en la plataforma S60. Los pasos para crear estos clientes
73
IMS usando SDS/ICP sobre Nokia Carbide C++ para móviles basados en S60 son
los siguientes:
Tener instalado el SDS
Registrarse en la web del Forum Nokia y descargar e instalar Carbide.c++
Express v1.3
Descargar e instalar el SDK S60 para Symbian: S60 3rd edition, FP1 (2006-
10-11)
Ejecutar el SDS, y del menú seleccionar SDS >Client >Install SDS Extensions
in Carbide. Esto permite proporcionar la ruta del Carbide instalado, e instala
el ICP plugin sobre éste.
Iniciar Carbide integrado en el entorno de desarrollo del SDS (ver figura 3.19).
Esta integración añade características como: icono para iniciar un proyecto
ICP, un menú para desplegar aplicaciones (build/deploy), etc.
Codificar, compilar y depurar
Inicializar el entorno de Ejecución: core, Application Server, Enablers de
servicio
Configurar el perfil de usuario (como se vio en el capítulo 2 en lo referente a
los inital Filter Criteria) de la ICP
Ejecutar la aplicación
Llevar a cabo pruebas o testeos extremo a extremo haciendo uso de los nodos
IMS del SDS, el servidor y los simuladores de servicios
Solucionar problemas (troubleshooting)
Instalar ICP en el emulador de Symbian

Antes de instalar ninguna aplicación cliente es necesario tener instalado y en
ejecución la plataforma para clientes IMS (ICP) en el dispositivo de destino. Este
entorno de ejecución puede instalarse en el emulador Symbian integrado en el
paquete del SDS13 . Para ello, en el Eclipse IDE hay que seleccionar SDS >Client
>Install ICP in Symbian Emulator en el menú que proporciona el SDS dentro del
IDE.
Instalar un fichero de instalación SIS en un dispositivo Symbian

Los ficheros .sis son ficheros de instalación para dispositivos Symbian, por lo que
tanto la ICP como las aplicaciones cliente deberán estar empaquetadas en un paquete
de instalación. Las aplicaciones creadas con el entorno de diseño de clientes del SDS
pueden desplegarse fácilmente en dispositivos Symbian. Para ello, es preciso generar
el fichero .sis para que lance el paquete de instalación, y así posibilitar la instalación
en el dispositivo. Esta opción se encuentra en el menú SDS: SDS >Client >Install SIS
13
La ICP se instala en el sistema operativo Windows con la propia instalación del SDS en el PC.
74
Figura 3.19.: El entorno de desarrollo del SDS con el S60 C++ Carbide integrado.
file in Symbian Device. El despliegue de las aplicaciones en los terminales requiere

las suites de escritorio propias del terminal. En estas suites se presentan una serie de
menús, interfaces, asistentes y aplicaciones integradas para facilitar la comunicación
con el terminal a través del ordenador para todo tipo de propósitos. En conclusión,
el programador ha de instalar la suite de comunicación con el terminal, instalar el
fichero .sis de la ICP en el dispositivo, para luego instalar el .sis correspondiente a
la aplicación cliente.
Inicializar el emulador de Symbian

Esta función proporciona un acceso directo incluido en el menú de Eclipse a la
opción de inicialización del emulador de Symbian: SDS >Client >Start Symbian
Emulator.
El programador puede lanzar el emlador de Symbian para acceder al proyecto
cliente que esté desarrollando en ese momento. El emulador escogido es el Symbian
UIQ, y se usa para ejecutar y testear las aplicaciones IMS clientes antes de pasar a
desplegarlas en un terminal real. Alternativamente, puede accederse al emulador de
Symbian desde la Visual Network, con doble click en el menú emergente disponible
en su icono (ver figura 3.13).
75
Figura 3.20.: Asistente para la instalación de la aplicación cliente en Windows.
Instalar el cliente IMS en Windows

Los desarrolladores de aplicaciones IMS pueden hacer uso de esta opción para
ejecutar clientes sobre el sistema operativo Windows. Desde el menú: SDS >Client
>Install Client in Windows. En la ejecución del cliente, se puede seleccionar la
opción de no ejecutarlo en modo de depuración (modo non-debug), para ahorrar
recursos del sistema, ya que la opción de depuración puede ralentizar los PCs con
menos prestaciones. En la figura 3.20 se ilustra el asistente para la instalación de la
aplicación cliente en Windows.
Debugger para clientes sobre Windows

El “depurador” o debugger está habilitado durante toda la fase de desarrollo para
los clientes IMS para Windows. Los programadores pueden establecer puntos de
ruptura (breakpoints), hacerle seguimiento a una determinada variable, etc. Esto
proporciona una gran flexibilidad y ahorro de tiempo a los desarrolladores, ya que
pueden atacar los problemas y arreglar determinados problemas como software bugs
de una manera rápida y directa. La aplicación Java que se ejecuta en el emulador de
Symbian está completamente aislada del sistema operativo Windows; de ahí que la
depuración se soporte en los clientes para Symbian, pero requiere una configuración
especial, y no tan directa como la de los clientes en Windows.
Instalación o desinstalación de clientes en el emulador Symbian

La opción en el menú para proceder a la instalación o desinstalación de los clientes es
SDS >Client >Install or Uninstall Client in Symbian Emulator. El Client launcher
lanza las aplicaciones IMS al emulador, siempre y cuando la ICP esté activa. El
76
mismo proceso se lleva a cabo para la desinstalación en el emulador.
Creación de proyectos IJCU

El asistente para la creación de proyectos IMS JME Client Utility (IJCU) permite
crear aplicaciones IJCU haciendo uso de Eclipse Micro Edition (Eclipse ME).
En la barra de herramientas del SDS, es posible seleccionar el botón de IJCU para
lanzar el wizard de nuevo proyecto Java 2 Micro Edition (J2ME) IJCU.
Una vez lanzado el asistente, los siguientes pasos para la creación de una aplicación
IJCU son:
1. Decidir en qué dispositivo J2ME emulado se va a desplegar la aplicación;
configurarlo y cargarle los parámetros Java.
2. Crear un nuevo J2ME Midlet para el proyecto. Se genera un esqueleto para
un proyecto IJCU, y se le añaden las utilidades IJCU a la ruta de las clases
Java. Existen dos tipos de ficheros .jar disponibles para proyectos IJCU:
ijcu-core-4.1.1-me.jar: este paquete core implementa la APIs JSR 180
y JSR 281. Es especialmente compacto (500KB) para permitir a
dispositivos limitados en recursos enviar y recibir mensajes SIP.
ijcu-presence-4.1.1-me.jar: este paquete (700KB) incluye el paquete core,
así como el soporte para una funcionalidad avanzada de presencia.
3. Una vez generado el proyecto IJCU, pero antes de implementarlo, es
preciso usar la clase IjcuUserManagement para configurar parámetros como
domainURI, outboundProxyURI, publicUserId, “reino” de claves (realm),
privateUserId, contraseña (password y plataforma (platform) [27].
4. Codificar el midlet IJCU haciendo uso de los documentos de la API descrita
en el IJCU Javadoc.
Despliegue de aplicaciones IJCU

Existen dos opciones para desplegar aplicaciones IJCU:
Despliegue de aplicaciones IJCU en emuladores de dispositivos JavaME: Si
se elige esta opción, el despliegue se lleva a cabo haciendo click con el botón
derecho sobre la clase del midlet IJCU, y del menú contextual seleccionar Run
AS >Emulated J2ME Midlet.
De este modo, se lanzará el emulador por defecto con la aplicación ejecutándose
sobre éste.
Despliegue de aplicaciones IJCU en terminales: El despliegue del midlet IJCU
varía según qué terminal se esté usando. Un modelo de teléfono específico
tendrá que incluir la información necesaria. Como prerrequisito, la red de
paquetes que se utilice tendrá que configurarse. Entonces, se seguirán los
siguientes pasos para el despliegue de la aplicación:
77
Figura 3.21.: Un ejemplo de Javadoc: La API para clientes IMS sobre IJCU basados en Java.
1. “Subir” el midlet (ficheros JAD y JAR) al teléfono, por ejemplo mediante

USB o Bluetooth.
2. Instalar el midlet seleccionando el fichero JAD o JAR.
3. Ejecutar el midlet en el teléfono.
Es posible que haya que firmar la aplicación, dependiendo del modelo de
terminal.
ICP/IJCU API Javadoc y Cppdoc

Desde el menú del SDS puede accederse a la documentación (SDS >Documentation
menu) de las APIs para el desarrollo de aplicaciones cliente sobre ICP o IJCU
tanto en Java (el documento se denomina Javadoc) como en C++ (Cppdoc). La
documentación consiste en en un manual basado en HTML (ver ejemplo de la
figura 3.21) donde se describen todas las interfaces y métodos disponibles para la
creación de clientes IMS.
3.4.2 Framework del cliente IMS: plataforma (ICP/IJCU) y

aplicaciones
Origen
El éxito de IMS, como el de otras tecnologías, depende de la disposición de nuevas
aplicaciones en el dispositivo final. En el caso de IMS la importancia de los terminales
y dispositivos es aún mayor por las siguientes razones:
Al pasar del tradicional dominio de conmutación de circuitos CS al de
78
conmutación de paquetes PS, cada aplicación define qué parte se establece

en el terminal de usuario, y qué parte en la infraestructura de red. Un cliente
siempre será necesario.
Con la evolución tecnológica, los dispositivos son cada vez más potentes y son
capaces de ejecutar una multitud de aplicaciones avanzadas. Esto es debido
a que cada vez se disponen de procesadores más pequeños, con un menor
consumo y una mayor potencia, baterías más compactas y de mayor duración,
y una enorme integración de accesorios (cámara, radio, GPS,...) y plataformas
de acceso (WCDMA, WLAN, HSPA, Bluetooth, etc.)
En términos empresariales, se requiere una solución madura para asegurar

rápidamente unos Time To Market (TTM) y InterOperability Testing (IOT) (si
la aplicación pretende desplegarse en distintos dispositivos), así como, en términos
tecnológicos, una implementación en la red y en definitiva generar una aplicación
IMS e2e atractiva y competitiva.
Por otro lado, el desarrollo y la implementación de aplicaciones IMS en los
dispositivos finales no es una tarea fácil. El desarrollador tiene que afrontar la
creación de aplicaciones desde dos perspectivas:
Perspectiva tecnológica, con requerimientos en:

• El número de protocolos de comunicaciones a implementar, incluyendo:
SIP, SDP, RTP, RTCP, MSRP, XML, XCAP, HTTP
• Los estándares IMS del 3GPP, IETF y OMA
• Ejecución en tiempo real
• Gestión de tareas de bajo nivel
• Gestión de los recursos del dispositivo (consumo de baterías, tarifi-
cación, ...)
• La propia coexistencia y competencia entre aplicaciones
El punto de vista del usuario o experiencia de usuario, con una demanda,
en general, en:
• Interfaz (GUI) atractiva, competitiva e intuitiva para el usuario
• Interacción con el usuario simple y atractiva
Con respecto a estas dos perspectivas, existen a su vez dos problemas básicos:
La ausencia de desarrolladores que dominen ambas perspectivas

La interoperabilidad requiere una cantidad considerable de tiempo y recursos,
debido a que cada aplicación IMS ya desarrollada incluye su implementación
propia de la tecnología IMS
Sin embargo, la interoperabilidad de las aplicaciones IMS es clave para el éxito de

IMS, por lo que estas cuestiones han de ser planteadas y resueltas. En este proyecto
se ha llegado a la conclusión de que Ericsson es una compañía que ha sabido afrontar
estos problemas con la división de las aplicaciones en dos capas:
79
Plataforma14 de aplicaciones cliente (ICP/IJCU): dominio de los

proveedores de plataformas de dispositivos.
Aplicaciones cliente IMS, los clientes IMS15 : dominio de los desarrolladores
de aplicaciones.
El objetivo para esta división fue ocultar todos los detalles tecnológicos de
IMS detrás de la plataforma del cliente, y presentar APIs de alto nivel a los
desarrolladores de aplicaciones. En este sentido, los desarrolladores de aplicación
han de concentrarse sólo en el proceso de innovación, mientras que la tecnología
IMS se encapsula en el framework y queda oculta a los programadores. Estas dos
capas, juntas, crean el dominio software del cliente IMS en el terminal o dispositivo.
Visión general del framework del cliente IMS

En general, la estrategia que ha seguido Ericsson, como líder de las herramientas
para el desarrollo de aplicaciones IMS, es la de soportar la estandarización de APIs
de alto nivel en la comunidad Java, de tal forma que todos los terminales con
soporte Java lo tengan también en IMS, independientemente del tipo de acceso.
Esa es la razón por la que Ericsson tomó el liderazgo en la estandarización de
la Java Specification Request (JSR) 281 y 325 como parte del Java Community
Process (JCP).
En la figura 3.22 se ilustra la visión del desarrollador de servicios de la arquitectura
IMS, siendo el SDS el elemento que ofrece las herramientas para completar el
ciclo de desarrollo y testeo extremo a extremo sin necesidad de conexión a
una infraestructura real. Y se ha remarcado el carácter de extremo a extremo
por soportar soluciones tanto de la parte cliente como del lado del servidor: La
especificación JSR-116 presenta la SIP Servlet API para el desarrollo de la parte
servidora del servicio; de la misma manera la pre-JSR-281 ICP API presenta la
funcionalidad IMS para el desarrollo de aplicaciones cliente.
Ericsson soporta la versión embebida o para descarga del IMS Client Framework
Versión para descarga: IMS Client Platform (ICP) es la implementación

de Ericsson para descarga en entornos como Symbian, Windows, y en un
futuro otros sistemas operativos. La ICP junto con el SDS presenta a los
desarrolladores una capa API de alto nivel de las especificaciones pre-JSR 281
y pre-JSR 325. La IMS JME Client Utility (IJCU) es la implementación de
Ericsson para descarga enfocada a aquellos clientes que a día de hoy soportan
el estándar Java Micro Edition pero no soportan capacidades IMS o SIP. Las
utilidades IJCU a través de la herramienta SDS ponen a disposición de los
14
En la bibliografía lo han denominado IMS Client Framework. Sin embargo, se ha creído más
inteligible la denominación de “plataforma” por su misma definición de sustrato sobre el que
se “levantan” aplicaciones.
15
En este capítulo, donde se habla de un entorno software de implementación, hablar de un cliente
y aplicación cliente tiene el mismo valor, puesto que se está frente a un paradigma donde dos
partes constituyen un modelo software cliente-servidor. Por tanto cuando se habla de clientes
IMS se estará haciendo referencia a aplicaciones cliente IMS.
80
' $
Figura 3.22.: Visión del programador, con la complejidad de la

arquitectura de red “oculta” bajo el esquema de
desarrollo de servicios.
& %
desarrolladores una API de alto nivel de la versión definitiva de la JSR 281

release 1.0.
Versión embebida: Ericsson proporciona el framework para clientes IMS de
la Ericsson Mobile Platforms (EMP). La API de IMS se integra dentro
de la Open Platform Architecture (OPA) presente en los dispositivos EMP.
La EMP proporciona chipsets y firmware para fabricantes de terminales –
aproximadamente un 40 por ciento de los teléfonos 3G con tecnología WCDMA
se construyen sobre plataformas EMP, con ejemplos como Sony Ericsson, Sharp
o LG.
Ericsson ha definido el framework del cliente IMS para soportar:
El desarrollo rápido y sencillo de aplicaciones cliente

La descarga de nuevos clientes IMS
La coexistencia de múltiples clientes
La integración versátil con las capacidades del dispositivos
La integración con los enablers Communication Services (CoSe) de la red
IMS: Presencia y grupos, PTT, mensajería, etc.
81
' $
Figura 3.23.: Esquema de la implementación de la ICP en la

arquitectura de capas de IMS.
& %
3.4.3 La plataforma de clientes IMS, la IMS Client Platform (ICP)

Visión general de la IMS Client Platform (ICP)
El SDS también dispone de un conjunto de herramientas para el desarrollo y testeo
de clientes IMS: la IMS Client Platform (ICP). La ICP es una implementación del
framework del cliente IMS, y permite a los desarrolladores de aplicaciones pueden
crear proyectos de clientes IMS de tal forma que sólo necesiten concentrar sus
esfuerzos en el propio negocio de la aplicación cliente. El programador no necesitará
conocer los detalles de implementación de los protocolos, la interacción con el
servicio, etc. Los programadores podrán ejecutar y testear las aplicaciones cliente
sobre la ICP.
El diseño de la IMS Client Platform (ICP) se ha realizado desde una perspectiva
extremo a extremo. Los servicios IMS requieren un cliente presentado a través de
una GUI; así como es necesario que incluya la lógica de servicio, y funcionalidad
para el descubrimiento del User Equipment (UE) en la red y enrutado a través de
ésta — en un sentido, trasladar la lógica de servicio a la red —. Los servicios IMS se
distribuyen a través de la infraestructura de red IMS y requieren un acercamiento
extremo a extremo consistente en lo referente al lado del dispositivo. La ICP refleja
la arquitectura de la parte de infraestructura IMS mediante la creación de una
arquitectura horizontal donde donde se incluyen el core y los enablers de servicios.
Las aplicaciones end-to-end se ejecutan sobre estas dos partes. La ICP se ha creado
en esta perspectiva con una filosofía de capas, como se ve en la figura 3.23.
La ICP convierte el despliegue de nuevos servicios en una tarea más sencilla, debido
a que el núcleo de funciones ya se encuentra accesible para el cliente, como por
82
ejemplo la interactividad de la aplicación cliente con la infraestructura de red IMS.

La ICP está estructurada de tal forma que numerosas aplicaciones cliente pueden
convivir en el mismo dispositivo y hacer uso de dicho núcleo de funciones: La ICP
proporciona el entorno de ejecución necesario para que múltiples clientes simultáneos
reutilicen funcionalidades comunes de IMS.
El diseño de la ICP está orientado a conseguir el acceso y la colocación del cliente
en la red. En la práctica, esto se consigue a través de la API de la ICP, que permite
el acceso a los recursos multimedia y de comunicaciones. Las aplicaciones cliente
realizan peticiones de recursos de manera independiente unas de otras, incluso en el
mismo dispositivo, donde no tienen conocimiento de las peticiones de otros clientes
anejos.
La ICP asigna flujos de medios, puertos de comunicaciones; negocia con otros
servicios y establece sesiones. Cada cliente “posee” los recursos en uso, siempre
y cuando la sesión permanezca activa. Cuando la aplicación cliente o alguna
de sus sesiones se termina, la ICP libera automáticamente todos los recursos
comprometidos durante la sesión. Esta funcionalidad “de acceso” la proporcionan
los managers de la capa de control de la ICP, que se encargan de distribuir mensajes
a las diferentes funciones de IMS y clientes.
La implementación de la ICP asegura un comportamiento acorde a las especifi-
caciones de IMS: inclusión de funcionalidad SIP, negociación de medios y pilas de
protocolos, abstracción de los detalles de la red IMS – como por ejemplo la apertura
y gestión de conexiones – mediante el acceso a la API de alto nivel pre-JSR 28116
del core. Asimismo, la utilización de la ICP obedece las directrices del ni vel de
aplicación, ya que encapsula todos los mecanismos e interacciones necesarias para
la implementación de los enablers de servicios, y de una manera similar permite
expone a los desarrolladores la API pre-JSR 325 de servicios. Este conjunto de APIs
predefinidas, la del núcleo o core (pre-JSR 281) y la de servicios (pre-JSR 325),
está disponible para los desarrolladores de aplicaciones cliente. Con el uso de la
ICP, estos clientes pueden crear y controlar conexiones multimedia conforme a las
especificaciones del IETF y 3GPP del estándar de IMS.
En la figura 3.24 se puede observar las dos partes en las que se divide la IMS Client
Platform (ICP):
Una API para el core basada en los estándares del IETF y 3GPP
Una API específica para los servicios IMS, basada en los estándares OMA:
OMA PoC, OMA Presence and GLM (PAG), OMA XDM, y OMA IM
16
La ICP expone a los desarrolladores dos APIs: la ICP C++ API y la ICP Java (JME/CDC)
API. La Java API es una variante temprana de la especificación JSR 281, por ello el nombre
de pre-JSR 281.
83
' $
Figura 3.24.: Esquema general de la arquitectura de la ICP versión

4.1. Fuente: Ericsson.
& %
La ICP deja expuestos tanto el core como los enablers de servicios a través de una
API de alto nivel en C++ y Java. La ICP estaba en gran parte basada en el estándar
JSR 281 y pretende, en futuras versiones, ser totalmente compatible con el mismo.
El desarrollador de clientes solo tiene que implementar la nueva lógica de servicio,
así como la nueva interfaz de usuario basándoe en las APIs disponibles. Todos los
clientes que hagan uso de la API de la ICP, se ejecutan obligatoriamente sobre el
core entorno de ejecución de la ICP.
La ICP 4.1 está actualmente disponible para dispositivos móviles y de sobremesa.
No existen diferencias de funcionalidad entre la ICP instalada en uno u otro
equipo, de hecho, el mismo código base se ofrece tanto para los terminales móviles
Symbian (SEMC y Nokia N95) como para los equipos de sobremesa con Windows
(XP o Vista). Esta solución versátil asegura la interoperabilidad entre diferentes
dispositivos, sin necesidad de efectuar modificación alguna en la implementación
funcional. El componente de la arquitectura que permite que la ICP se ejecute en
diferentes sistemas operativos es la capa de abstracción o abstraction layer (ver
figura 3.25) específica para cada dispositivo. Esta capa de abstracción encapsula
todos los componentes que son específicos de la plataforma del dispositivo y asegura
que la ICP en sí es la misma e independiente de sobre qué dispositivo — smartphone,
PC o PDA — se está ejecutando o accediendo.
En la figura 3.26 se observa una versión simplificada de la arquitectura horizontal
completa de la ICP 3.26 .
84
Figura 3.25.: Componentes detallados de la capa de abstracción o abstraction layer.
' $
Figura 3.26.: Esquema simplificado

de la arquitectura hori-
zontal de la IMS Client
Platform
& %
85
Características de la IMS Client Platform (ICP)

El objetivo de la ICP es proporcionar las características necesarias para simplificar
el desarrollo y ejecución de aplicaciones IMS sobre todos los dispositivos (de
plataformas abiertas) haciendo uso de la tecnología IMS disponible en la actualidad
y continuar simplificándola de cara a futuras aplicaciones. El diseño de la ICP se
centra en:
Desarrollo sencillo de aplicaciones
Interoperabilidad de las aplicaciones
Disponer de enablers comunes para los servicios estandarizados
Soporte multicliente
Soporte multidispositivo
Soporte multidominio
Respecto a la funcionalidad, esta nueva versión de la ICP (la 4.1) ofrece
funcionalidad en dos segmentos: core o núcleo de red y enablers de servicios:
Funcionalidad de core IMS para la creación de servicios IMS propietarios,
incluyendo:
• Gestión de la sesión (session management)
• PacketMedia basado en Message Session Relay Protocol (MSRP)
• StreamMedia basado en Real-time Transport Protocol (RTP)/RTP
Control Protocol (RTCP)
• Reproductores/grabadores de audio
• Reproductores/grabadores de video
Enablers de servicios, entre los que se incluyen:
1. Servicio de presencia del estándar de Open Mobile Alliance (OMA)
2. Servicio de grupos y gestión de listas, también de OMA
3. Agenda/guía telefónica con servicio de presencia añadido (Presence
Enhanced Phonebook (PeP)). Sobre este servicio de presencia se
colocarían los servicios de gestión de grupos y listas
4. Mensajería instantánea (OMA IM)
5. GSM Association (GSMA) Combinational Services
6. VoIP (peer-to-peer sobre PCs, y dispositivos SEMC P1 y Nokia N95)
7. Push-To-Talk over Cellular (PoC) de OMA
Los enablers de la ICP extienden el desarrollo sencillo de aplicaciones y la
interoperabilidad. Además, se encapsulan todas las primitivas referentes a los
servicios estandarizados y se expone la funcionalidad de los servicios a través de
la abstracción de las APIs de alto nivel. En este sentido, las aplicaciones cliente no
incluyen ninguna implementación de las interacciones del servicio,por lo que pueden
interoperar fácilmente en el contexto del servicio.
86
Al contrario que la implementación del core de la ICP, que tenía que incluirse en
cualquier configuración posible de la ICP, los enablers de servicio son opcionales y
permiten mucha flexibilidad en la configuración.
Ejemplo de implementación de un enabler : Agenda/guía telefónica con

servicio de presencia añadido La aplicación por defecto de la aplicación Policy
Enforcement Point (PEP) corre paralela a la guía de contactos del dispositivo.
El implementar por defecto esta aplicación puede servir como punto de partida
para el lanzamiento de servicios basados en IMS desarrollados por el operador. Por
ejemplo, al disponer de la presencia de tus contactos se ahorraría en señalización
de llamadas no descolgadas, o se dejaría al usuario la opción de seleccionar el tipo
de llamada (videollamada, llamada de voz, mensajería instantánea...) logrando una
segmentación y capilaridad mucho mayores con las que obtener más Average Revenue
Per User (ARPU)17 .
Otras características
Adicionalmente, la ICP 4.1 soporta más capacidades IMS (básicas y avanzadas):
Autenticación IMS
Registro
Autorización
Señalización y compresión (SigComp 2.0)
Calidad de servicio, Quality of Service (QoS). Control del acceso radio
Componentes de la ICP
En la figura 3.24 se muestra la filosofía modular de la arquitectura de la ICP.
Componentes internos de la ICP (ICP Package) El ICP Package incluye todos

los componentes necesarios para soportar aplicaciones cliente IMS desarrolladas
sobre la API de la ICP (ICP API) e instaladas en los dispositivos que soportan
la ICP. Este “paquete” de componentes internos incluye:
Entorno de ejecución de la ICP (ICP Run-time)
ICP Monitor
ICP Client Library
El entorno de ejecución El entorno de ejecución de la ICP está actualmente

disponible para Symbian 9.1/UIQ3.0 y Symbian 9.2/S60, ambos para entorno real y
emulado; y para equipos con Windows XP o Vista. La ICP se ejecuta en el dispositivo
como un servicio en segundo plano (en background) sirviendo como una plataforma
17
Ingresos medios por usuario.
87
común para todos los clientes IMS instalados y desarrollados con la ICP API. La ICP
se encarga de gestionar todas las interacciones con la infraestructura del núcleo de
red IMS y los servidores de aplicación (en el caso de que intervengan). Este entorno
de ejecución se ha testado tanto a pequeña escala y en simulación con el Service
Development Studio (SDS) como a gran escala y en los nodos e infraestructura
reales desplegados por Ericsson. En ambos casos se ha demostrado la compatibilidad
con los estándares del 3GPP, IETF y OMA.
Todos los clientes ejecutados en el mismo dispositivo comparten una instancia del
núcleo del entorno ejecución de la ICP18 . La ICP contiene las pilas de protocolo
básicas, así como los enablers de core y servicios, responsables de tratar todos las
peticiones y eventos que se produzcan en la interacción con los clientes IMS y toda
la señalización y tráfico de datos entre la red IMS y el dispositivo.
El ICP monitor El ICP monitor es la interfaz gráfica, la Graphical User Interface

(GUI) que interactúa entre el usuario del dispositivo y la ICP. Ésta ofrece las
siguientes funcionalidades al usuario final:
Información acerca el estado del servicio de la ICP en segundo plano
Arrancar/parar la ICP
Configuración de los parámetros relacionados con la ICP
Chequeo de información general de la instalación actual. Por ejemplo, la
versión.
La librería de clientes ICP o ICP client library es un conjunto de DLLs que

se carga en el espacio de procesos que la aplicación cliente tiene en la memoria.
Estas DLLs encapsulan los mecanismos de comunicación entre la aplicación cliente
y la plataforma ICP. Los objetos que se implementan en la ICP quedan de este
modo accesibles por las aplicaciones clientes a través de los objetos correspondientes
implementados en la librería.
La librería de clientes utiliza un mecanismo cliente-servidor en la comunicación
entre las aplicaciones ejecutadas como procesos independientes y el proceso de la
ICP. En este sentido, todas las aplicaciones clientes que se ejecutan en el mismo
dispositivo comparten el mismo proceso en background correspondiente a la ICP.
Componentes externos Los componentes externos de la ICP son:

Symbian 9.1 / UIQ 3.0 SDK:
El Symbian 9.1 es, como se ha comentado con anterioridad, el sistema
operativo para terminales móviles, y la interfaz gráfica basada en este sistema
operativo por defecto en el SDS es la UIQ 3.0. La combinación del sistema
operativo y esta interfaz conforman el Software Development Kit (SDK)
que proporciona a los desarrolladores un conjunto de APIs genéricas con
18
En un dispositivo, sólo se puede lanzar una ejecución de la ICP simultánea.
88
las capacidades del Symbian OS/UIQ. Este SDK incluye el emulador de un

terminal con la interfaz UIQ para el testeo de los desarrollos. Este SDK es
abierto, sin control de licencia y se encuentra integrado con el SDS como parte
del paquete SEMC P1 CDC. Se instala durante el proceso de instalación del
SDS y permite a los desarrolladores crear aplicaciones cliente IMS para el
entorno Symbian/UIQ, ejecutables tanto en el entorno real como emulado.
Symbian 9.2 / Series 60 3rd Edition FP1 SDK:
Siguiendo con el entorno del sistema operativo del terminal, se estudia el
conjunto Symbian 9.2/S60, siendo Nokia Series 60 (S60) la plataforma que
proporciona la interfaz gráfica. La combinación de Symbian 9.2 con la interfaz
S6019 . El SDK pone a disposición del programador todas las herramientas
necesarias para construir aplicaciones Symbian C++, pero es necesario el uso
del Nokia Carbide.c++ IDE para hacer más sencillo y accesible el desarrollo
con el SDK. El SDK contiene un emulador de un dispositivo con la interfaz
S60 para el testeo de las aplicaciones desarrolladas sin necesidad de certificado.
Por tanto, el paquete Carbide IDE, junto con el plugin para implementar la
ICP, permiten el desarrollo sencillo de aplicaciones cliente IMS para el entorno
Symbian/S60, ejecutables tanto en el entorno real como emulado.
JDK 1.6:
El Java Development Kit (JDK) 1.6 es el SDK para el lenguaje de
programación Java proporcionado por Sun Microsystems para, en este caso,
desarrollar aplicaciones cliente IMS en entorno de Java en Windows (es decir,
con la máquina virtual (JVM) sobre Windows20 .
Nokia Carbide C++ v1.3:
Como se ha anticipado, el Nokia Carbide.C++ v1.3 (Express Edition) es un
IDE para el sistema operativo Symbian OS. Carbide, con el SDK pertinente
es un novedoso conjunto de herramientas de desarrollo de Nokia para la nueva
generación de terminales, y extrapolando, de las Comunicaciones Móviles.
Carbide aúna las herramientas de desarrollo de Nokia en un framework común
con nuevas características añadidas. En concreto, Carbide.c++ es una potente
familia de herramientas construida sobre Eclipse. Existen cuatro ediciones:
OEM, Professional, Developer y Express. La edición Express se usa con
el conjunto SDS/ICP, ya que es una versión óptima para la introducción
al entorno. El desarrollador sólo tiene que instalar el plugin de la ICP
proporcionado con el SDS sobre Carbide.c++ v1.321 . A partir de ahí, será
capaz de desarrollar aplicaciones IMS.
Otros componentes externos:
• Microsoft Visual C++ 2008 (Express Edition)
19
Con la instauración de la fundación Symbian (Symbian Foundation), la UIQ dejó de existir,
siendo la S60 la opción elegida por la fundación Symbian para la interfaz gráfica de su sistema
operativo. UIQ contribuirá a la fundación. [28]
20
Para ejecutar las aplicaciones IMS en Symbian la versión del JDK que soporta es la 1.3.
21
Cualquier edición: OEM, Professional, developer y Express.
89
• Herramientas de compilación: ARM RealView Compilation

Tools (RVCT) y GNU C Compiler Embedded (GCCE)
• PC Desktop suite para terminales móviles: El PC Desktop suite
para terminales móviles se usa para instalar los clientes desarrollados
en los terminales móviles. Esta suite viene incluída en el paquete comercial
del terminal. Adicionalmente, pueden descargarse desde el sitio web del
fabricante.
Visión general de la ICP API

Como se ha mencionado en apartados anteriores, la Application Programming
Interface (API) de la ICP (la ICP API), oculta la complejidad de IMS exponiendo
únicamente primitivas de alto nivel a las aplicaciones.
Los desarrolladores tienen por tanto a su disposición un conjunto de herramientas
para llevar a cabo todas las tareas de bajo nivel “en nombre” de las aplicaciones.
Estas tareas técnicas de bajo nivel se ejecutan bien por medio de llamadas de alto
nivel o automáticamente, sin necesidad de ninguna aplicación involucrada — por
ejemplo, al registrar una aplicación IMS instalada en el terminal —. La ICP también
gestiona los recursos del terminal y ofrece a los desarrolladores de aplicaciones
objetos de comunicación y conexiones de medios para intercambiar distintos tipos de
contenido entre aplicaciones y terminales. Asimismo, se permite a los programadores
requerir una determinada Quality of Service (QoS) de una manera fácil e intuitiva.
La ICP API está dividida en una API del núcleo IMS (core API) y API de servicios
estandarizados (service API). Este diseño constituye un método claro para crear
nuevos servicios, motivando el desarrollo de nuevos servicios al mismo tiempo que
se facilitan medios de comunicación comunes y ampliamente extendidos, como la
mensajería.
En esta sección se tratarán las dos APIs que expone la ICP al desarrollador: la
C++ API y la Java API (JME/CDC) analizando sus principales funcionalidades
y paquetes.
La ICP C++ API En la versión 4.1 de la ICP, se soporta la C++ API para
permitir el desarrollo de aplicaciones nativas, especialmente para dipositivos con
el entorno Symbian v9.2/S60 3rd edition FP1. En el framework S60, la API C++
de la ICP es la única opción que tienen los desarrolladores, debido a la ausencia
de soporte Java CDC22 . Las aplicaciones nativas normalmente consumen menos
potencia y proporcionan un mayor rendimiento comparadas con los clientes en Java.
Estos beneficios hacen de estos desarrollos nativos una opción comercialmente más
adecuada para el desarrollo de los clientes.
22
Recordar que Connected Device Configuration (CDC) y Connected Limited Device Configuration
(CLDC) son las especificaciones para la máquina virtual básica que un dispositivo J2ME debe
soportar. CDC es para dispositivos algo mayores, con más prestaciones (smartphones, PDAs,...),
y CLDC es la implementación más básica y para dispositivos limitados en recursos (teléfonos
móviles, “buscas”, etc.).
90
La API C++ del core IMS contiene las funcionalidades básicas para
desarrollar servicios IMS a medida. Los desarrolladores IMS en C++ tienen a
su disposición las siguientes interfaces:
• IMS Profile
• IMS Service
• IMS Session
• PacketMedia
• StreamMedia
• ...
La API C++ de los IMS service enablers provista por la ICP encapsula
la implementación de los siguientes mecanismos del nivel de aplicación:
• OMA Presence
• OMA Group List Management (GLM)
• OMA Instant Messaging (IM)
• GSMA Combinational Service (CSI)
• P2P Voice over IP (VoIP)
• OMA Push-to-Talk over Cellular (PoC)
• Presence Enhanced Phonebook (PEP)
La ICP Java API En la implementación de la ICP, la API en Java (Java API o

API Java) es la capa que envuelve la API nativa en C++. La sintaxis de la Java
API refleja la sintaxis de las interfaces de la API en C++ y por tanto programar
aplicaciones basadas en la ICP tanto en C++ como en Java sigue la misma filosofía.
Por supuesto, existen diferencias entre estos dos conjuntos de interfaces:
Todas las interfaces C++ están localizadas en un mismo espacio de nombres

namespace, mientras que en Java se proporcionan multitud de paquetes.
Las interfaces C++ se basan en valores de retorno (HResult) para invocar
métodos. La API en Java, por su parte, hace uso de excepciones.
Diferencias de lenguaje: C++ usa punteros y referencias mientras que Java
utiliza instancias
La API Java para el core IMS incluye los siguientes paquetes:

• com.ericsson.icp
• com.ericsson.icp.media
• com.ericsson.icp.multimedia
• com.ericsson.icp.util
La API Java para los IMS service enablers se encapsula en multitud
de paquetes de clases que siguen el patrón com.ericsson.icp.services.xxx,
91
cubriendo así cada servicio estandarizado para IMS:

• com.ericsson.icp.services.PGM
• com.ericsson.icp.services.imsm
• com.ericsson.icp.services.combination
• com.ericsson.icp.services.telephony
• com.ericsson.icp.services.telephony.Voip
• com.ericsson.icp.services.telephony.PoC
• com.ericsson.icp.services.pep.model
Interoperabilidad
La ICP puede interoperar con redes IMS que cumplan con los estándares, y se ha
comprobado con el core simulado del IMS y el del entorno real IMS Common System
4.1 de Ericsson.
Algunas características de la ICP requieren un nodo o AS específico para
interconectarse, como el servidor de presencia, PTT-AS, etc.
La versión 4.1 de la ICP sigue minuciosamente los estándares IMS referentes a la
release 6 del 3GPP, incluso en algún momento sigue la 3GPP R7. Esta fidelidad
con la norma asegura la interoperabilidad a nivel de protocolos. La ICP incluye una
implementación de estos protocolos necesarios para los servicios IMS.
En segundo lugar, la ICP toma medidas para la autenticación y autorización del
propietario del dispositivo junto con el registro de los servicios IMS disponibles en
el terminal.
En el nivel de aplicación, la ICP asegura el establecimiento de la sesión de
comunicación incluyendo la negociación de la calidad de servicio en la red mientras
establece el canal de comunicación en el plano de datos (contexto PDP en el caso
de terminales móviles) y negociación de las conexiones de medios.
Los enablers de servicio en la ICP son módulos que implementan un determinado
número de servicios estandarizados asegurando interoperabilidad.
Soporte multidispositivo (Multi-Device Support)

Una de las principales fortalezas del concepto de ICP para dispositivos de
plataformas abiertas es el soporte multidispositivo. A través de una capa de
abstracción dedicada, la ICP es capaz de ignorar toda dependencia con el sistema
operativo (SO). Hoy en día se soportan los siguientes SOs:
Windows XP/Vista
Symbian v9.1/UIQ 3.08 (solo Java)
Symbian v9.2/S60 3rd Edition FP19 (solo C++)
92
De acuerdo con la planificación comercial o roadmap que se vio en la sección 3.3, el

soporte multiplataforma se extenderá en futuras versiones del SDS con los siguientes
SOs:
Linux
vxWorks
Windows Mobile y Mobile Linux (ej.: Android)
Soporte multicliente (Multi-Client Support)

IMS proporciona un marco ideal para servicios multimedia enriquecidos. Como
se describió anteriormente, el SDS con la ICP proporciona un conjunto de
herramientas para el desarrollo sencillo de aplicaciones cliente. Este hecho crea
grandes expectativas de cara al crecimiento de las aplicaciones IMS, enriqueciendo la
experiencia de usuario y acelerando la implantación de IMS en los mercados. Estas
esperanzas suponen unos requerimientos sobre la ICP para soportar la coexistencia
de diferentes aplicaciones cliente en el mismo dispositivo. Esta convivencia de
clientes fue una de las principales preocupaciones en la concepción de de la ICP,
donde se tuvo en cuenta la necesidad del usuario de ejecutar diferentes servicios de
comunicaciones simultáneos. Este caso de servicios de comunicaciones en paralelo
es especialmente aplicable en los dispositivos que despliegan una interfaz de usuario
“pesada”, como dispositivos Windows o Linux.
Hay que aclarar que el soporte multicliente es un concepto desligado de la ejecución
de aplicaciones multitarea. Este área ha de ser cubierta por el sistema operativo
subyacente. El soporte multicliente de la ICP concierne los siguientes aspectos:
Registro de todos los clientes instalados
Lanzamiento de las aplicaciones cliente apropiadas y enrutamiento de los
mensajes SIP desde y hacia estas aplicaciones
Gestión y coordinación de los recursos de IMS y locales (recursos del
dispositivo)
Soporte multidominio (Multi-Domain Support)

En el capítulo 2 se habló sobre el perfil IMS, creado para cubrir la necesidad
de que un terminal determinado intentara acceder a diferentes servidores IMS
situados en dominios distintos. Cada perfil IMS mantiene su propio estado en un
contexto independiente, permitiendo que una o más aplicaciones cliente acceder a
un dominio IMS específico. Los perfiles IMS están aislados los unos de los otros, sin
interferencia o dependencia alguna, siendo posible la activación de múltiples perfiles
IMS simultáneamente. De la implementación de la ICP, un perfil IMS incluiría los
siguientes contextos:
Estado de ejecución
Identidad de usuario y credencial
93
Localización del servidor

Acceso a la red
Preferencia de lanzamiento
Otras configuraciones y parámetros
Asimismo, todos los enablers de servicio pueden adjuntarse en cualquier perfil
IMS activo por medio de requerimientos del cliente. Esto da una gran flexibilidad
a los desarrolladores de clientes y a los usuarios finales, permitiendo una gran
personalización en las interacciones con los servidores IMS.
3.4.4 La solución para terminales limitados en recursos: IMS JME

Client Utility (IJCU)
Para aquellos terminales que por capacidades y recursos no podrían soportar la
IMS Client Platform (ICP), Ericsson diseñó la IP Multimedia Subsystem (IMS) o
utilidad JME para clientes IMS. A continuación se describe su origen y principales
características.
Visión general de la solución

La JSR 281 –API que mejora la ICP API– se lanzó finalmente en junio de 2008 en
su versión 1.0. Sin embargo, aún habrá de pasar un tiempo hasta que la mayoría de
los terminales estén adaptados para IMS y puedan soportar esta API. No obstante,
en el medio plazo es necesario proporcionar implementaciones de esta release de cara
a cubrir las necesidades de algunos servicios en terminales aún no completamente
preparados para IMS. Esta implementación “temprana” es parte del SDS como una
solución conceptual mediante la introducción de una utilidad para el lado cliente, la
IMS JME Client Utility (IJCU). Esta componente es parte de la herramienta del
SDS para el desarrollo de aplicaciones JME y posterior despliegue en un entorno
real.
En la figura 3.27 se observa la ubicación de la IJCU en el ecosistema de desarrollo.
El SDS incorpora esta utilidad para incluirla en los clientes Java.
El objetivo general final es conseguir que todos los teléfonos y terminales accedan a
la arquitectura de las redes IMS y en definitiva estar preparados para IMS. Hoy en
día esto no es posible debido a limitaciones técnicas de capacidad (los dispositivos
actuales no “hablan” ni “entienden” SIP/IMS). Inicialmente, el SDS proporciona
una implementación pre-comercial de la API JSR-281 para probar el uso de la API.
Esto permite a los usuarios tener una primera imagen de lo que está por venir para
los dispositivos móviles en el futuro. Existe un límite de 100 usuarios IJCU para
pruebas y demos.
La implementación de la IJCU reside en teléfonos con capacidad MIDP 2.0/CLDC
1.1 y con requerimientos de memoria pequeños. La IJCU ocupa alrededor de 300-
350KB de la memoria de los terminales de destino, y es capaz de comunicarse con
la red mediante SIP.
94
Figura 3.27.: SDS posibilita IMS en teléfonos basados en JME MIDP/CLDC. Fuente:
Ericsson.
Los casos soportados de uso, con sus correspondientes métodos SIP, son los
siguientes:
Registro: SIP REGISTER
Presencia: PUBLISH, SUBSCRIBE, recepción de NOTIFY
Grupos
Aplicaciones IP: juegos, localización
Chat: sesión uno a uno basada en SIP INVITE
Transferencia de ficheros: envío y recepción de archivos mediante Message
Session Relay Protocol (MSRP) y JSR 75
Combinaciones de estos servicios, siguiendo la filosofía de IMS de integración
de servicios
Entorno de diseño IJCU (IJCU Design Environment)

La versión 1.7.9 de EclipseME se encuentra integrada en el SDS para simplificar y
dar soporte al desarrollo de J2ME Midlets. EclipseME proporciona un conjunto
de características de cara a facilitar la creación de midlets, entre las que se incluyen:
Crear un nuevo proyecto JME Midlet
Crear un nuevo JME Midlet
Ejecutar/depurar un JME Midlet
Editor Java Application Descriptor (JAD)
Verificación previa de los ficheros de clases
Soporte para el lanzamiento de midlets en ejecución dentro de emuladores
JME.
Ofuscamiento mediante el software Proguard
95
Figura 3.28.: Características de la API JSR 281 soportadas por la IJCU. Fuente: Ericsson.
Terminales IJCU
La solución IJCU soporta terminales basados en MIDP 2.0/CLDC 1.1 que permiten
la descarga de midlets Java. Ericsson ha testado algunos teléfonos y otros los testeará
en el futuro. Otros smartphones pueden también soportar IJCU, siempre y cuando
soporten MIDP 2.0/CLDC 1.1 y permitan la descarga de midlets. Los terminales
basados en Symbian UIQ también se testearon (M600, P990, P1). La IJCU tendría
que funcionar con los terminales Symbian con S60, pero esta configuración no se ha
testado aún.
3.4.5 Emulador del núcleo de red IMS

El SDS proporciona un entorno simulado (SDS Simulated Environment) donde se
simulan los nodos del core de la red IMS. Esto permite al SDS actuar como una
red IMS virtual desde la perspectiva del desarrollador. IMS, como es conocido, está
basado en un protocolo de señalización estandarizado como SIP. Las entidades en
el dominio simulado de IMS actúan como el núcleo de red y enrutan la señalización
SIP hacia el entorno de ejecución (SDS Execution Environment) o bien hacia los
servidores de aplicación destino (en su caso) y “disparan” la lógica de servicio
requerida.
El entorno de simulación del núcleo de red IMS es, básicamente, un conjunto de
funciones lógicas que facilitan al desarrollador de servicios la tarea de testeo funcional
de los servicios durante la fase de desarrollo. Determina si se cumplen los objetivos
96
de negocio tales como usabilidad o facilidad de manejo y la idoneidad del producto.

Una gran cantidad de características del servicio pueden probarse sin necesidad
de un entorno real o un acceso real a la red IMS. El núcleo de red simulado
del SDS 4.1 soporta un subconjunto de funcionalidades de las especificaciones
del 3GPP — (TS 24.229/23.228) donde se describen con completitud el estándar
del IMS — y del entorno real de Ericsson, el IMS Common System (ICS).
Esta funcionalidad soportada incluye el registro, autenticación, normalización en
la numeración, traducción de ENUM, triggers de servicio, enrutado, etc. Estas
capacidades se encapsulan en un único componente que lógicamente representa
distintos nodos IMS. Este componente está optimizado para un fácil despliegue,
configuración y utilización.
El entorno del núcleo de red simulado del SDS comprende:
Home Subscriber Server (HSS)
Call Session Control Function (CSCF), incluyendo sus tres funciones:
• S-CSCF
• I-CSCF
• P-CSCF
Breakout Gateway Control Function (BGCF)
Domain Name Server (DNS), que en el SDS asigna un módulo de nombres
de dominio virtuales.
La base de datos de usuario: el Home Subscriber Server (HSS) del SDS

El HSS es la principal base de datos donde se almacenan todos los clientes y los
datos de los servicios del entorno de simulación. La información almacenada en el
HSS incluye entidades de usuario, parámetros de acceso e información de “disparo”
de servicios (service-triggering). Las identidades de usuario describen los perfiles de
usuario, tal y como se vio en el capítulo 2. Los parámetros de acceso se usan para
establecer sesiones e incluyen la identidad privada de usuario y su contraseña para
autenticar al usuario. La información de service-triggering posibilita la ejecución de
los servicios SIP, e incluye información que define unas condiciones que determinan
si las peticiones las cumplen y proporciona información de encaminamiento cuando
los criterios se cumplen.
Las funciones que implementa el HSS en el SDS son las siguientes:
Soportar el procedimiento de autenticación mediante el almacenamiento de
información de autenticación y proporcionando estos datos al S-CSCF
Proporcionar acceso a los datos del perfil de servicio para su uso dentro del
entorno simulado
La información que almacena el HSS comprende tanto datos de usuario perma-
nentes como temporales. Los datos temporales del usuario contienen el estado del
registro correspondiente a una identidad pública de usuario. La información perma-
97
nente se crea, modifica y elimina a través de la interfaz gráfica de usuario (GUI)

provisioning del SDS. La vista de provisioning soporta:
Dos identidades públicas de usuario: una con forma de SIP Uniform Resource
Identifier (URI) y otra con formato de TEL URI. En el registro de una de las
identidades públicas de usuario la otra queda registrada implícitamente. En el
SDS, la SIP URI es obligatoria, mientras que la TEL URI es opcional.
Una identidad privada de usuario toma forma de un Network Access Identifier
(NAI)23 y se asigna permanentemente a una subscripción de usuario. Una
identidad privada de usuario comparte un perfil de usuario entre las dos
identidades públicas de usuario (representadas por la SIP URI y la TEL URI).
Password de usuario asociada a la identidad de usuario.
initial Filter Criteria (iFC) almacenados para cada aplicación o servicio que
las peticiones de los usuarios puedan invocar.
Perfiles.
initial Filter Criteria (iFC) Dentro del SDS 4.1, los iFC se incorporan de acuerdo
a la especificación del 3GPP TS 29.228 R6, que ya se estudió en el capítulo 2. Estos
criterios de filtrado se componen de ninguno o un Trigger Point y un objeto para
el servidor de aplicaciones (AS). El Trigger Point está compuesto de uno o varios
Service Point Triggers (SPTs). Para esta versión del SDS; un SPT puede ser:
Tipo de sesión session case: originada, terminada, o terminada sin registro.
Método SIP: cualquier método SIP.
Contenido de la Request-URI.
Cabeceras SIP:
• Nombre de la cabecera SIP: nombre de la cabecera SIP que ha de estar
presente en una petición.
• Contenido de la cabecera SIP: una expresión que defina el valor de la
cabecera con el nombre especificado con anterioridad.
El Call Session Control Function (CSCF)

La función de IMS Call Session Control Function (CSCF) lleva a cabo el control
de la sesión entre extremos registrados de la red. Se comporta como un proxy SIP sin
estado, y su comportamiento particular depende de los mensajes SIP que se traten,
de su contexto y de las capacidades que se requieran del CSCF para soportar los
servicios. Asimismo, el CSCF se comporta como un SIP registrar; acepta peticiones
de registro y lleva a cabo la autenticación pertinente. El CSCF del SDS es un proxy
que se comporta como proxy sin estado durante la llamada. El SDS presenta una GUI
de configuración en la que se pueden configurar los diferentes modos de operación
del SDS (ver figura 3.29).
23
De la forma usuario@reino. Ejemplo: [email protected]
98
Figura 3.29.: Principales parámetros configurables (“preferencias”) del CSCF simulado del
SDS.
Cuando el CSCF acepta una solicitud de registro del usuario, los servicios no
se “disparan” hasta que no se proporciona un perfil de usuario. El CSCF, por
tanto, recupera la información relevante del usuario (el perfil de usuario) del HSS,
para llevar a cabo la autenticación entre el usuario final y la red, así como para
proporcionar servicios al usuario. El CSCF accede en todo momento a la información
del usuario, así como a los datos relacionados con los servicios. Internamente, el
CSCF hace uso de habilitadores/deshabilitadores internos para analizar y enrutar
las peticiones.
El CSCF incluye un módulo para resolver direcciones DNS para enrutar las
peticiones. En particular, este módulo permite al CSCF traducir las SIP URIs
asociadas con un número E.164 (número de teléfono internacional). El CSCF aplica
el mecanismo DNS/ENUM de acuerdo con la RFC 2761.
En el SDS, el CSCF es un único nodo del entorno de simulación, pero lleva a
cabo las funcionalidades descritas en el capítulo 2 y en las especificaciones del
3GPP: funcionalidades Serving-Call Session Control Function (S-CSCF), Proxy-Call
Session Control Function (P-CSCF), Interrogating-Call Session Control Function (I-
CSCF). Asimismo, incluye la funcionalidad de pasarela hacia redes Public Switched
Telephone Network (PSTN) de otras redes, la funcionalidad Breakout Gateway
Control Function (BGCF).
99
Funcionalidad Serving-CSCF El S-CSCF simulado está basado en un protocolo

SIP estructurado en capas y soporta un proxy SIP bien definido y un registrar con
autenticación. El S-CSCF se compone de las siguienets funciones:
Nivel de transporte: Soporta el envío y recepción de mensajes SIP mediante
TCP y UDP y hace uso de mecanismos multi-puerto
Capa de transacción: Gestiona el tratamiento de las transacciones del
servidor y el cliente para un INVITE o non-INVITE de acuerdo a la RFC
3261. La transacción del servidor filtra cualquier petición de retransmisión por
parte de la red. Éste recibe las peticiones y las reenvía a los Application Servers
o directamente al otro extremo de la llamada, dependiendo de los triggers
Autenticación: aplicable a todos los métodos. La identidad de usuario
privada es la que se usa para autenticar al abonado. Se emplea el esquema
digest y el algoritmo es MD5.
Proxy: Esta función incluye:
• Validación de las peticiones: comprobaciones en el esquema de Request-
URI y valor de las cabecera Max-Forwards
• Mecanismos para la localización de los servidores SIP, según la RFC 3263
• Record-Routing: encamina las direcciones SIP y entiende una TEL URI
en el campo Request-URI de una petición
• Soporta forking 24 SIP según la RFC 3261
Registrar: Soporta las siguientes características:
• Validación de la petición REGISTER: comprobaciones del dominio de
Request-URI y el valor de la cabecera
• Unión o binding entre una dirección de contacto con la identidad pública
de usuario
• Gestión de los temporizadores de registro (desregistrar al usuario cuando
los temporizadores expiran)
• Adición de una cabecera de Service-Route en la respuesta 200 OK del
REGISTER
• Adición de una cabecera P-Associated-URI en la respuesta 200 OK del
REGISTER
• Adición de la identidad pública de usuario implícitamente registrada
(TEL URI) tal y como se establece en el perfil de usuario
Service Triggering: Gestiona el tratamiento de redirección de la petición
inicial hacia el AS si los iFC se cumplen. Esta funcionalidad soporta:
• Determinación del tipo de sesión, con base a la cabecera Route
• Tratamiento de las peticiones iniciadas por el usuario “servido”: uti-
lización del perfil de servicio del llamante
24
Procedimiento por el cual se generan nuevos procesos “hijos” a partir de un proceso de orden
superior o “padre”.
100
• Tratamiento de las peticiones terminadas en el usuario “servido”:

utilización del perfil de servicio del llamado
• Adición de la TEL URI
• Envío de peticiones a la dirección del AS incluída en los iFC
• Incluir una entrada propia en la cabecera Route con el identificador
original del diálogo SIP
• Ejecución de los siguientes filter criteria de menor prioridad (si las
condiciones se cumplen)
• Tratamiento del registro de terceras partes
• Tratamiento de la respuesta
Capacidades del llamante: Mecanismos por los cuales un agente de usuario
SIP (SIP UA) puede trasladar sus capacidades y características a otros agenets
de usuario y al registrar. Esta información es transportada como parámetros
de la cabecera Contact en el REGISTER. El User Agent Client (UAC) puede
pedir las capacidades del usuario llamado mediante el envío de OPTION. Se
soportan las siguientes capacidades:
• Registro de las capacidades del llamado indicadas por parámetros en la
cabecera Contact de la petición REGISTER
• La respuesta incluye todos los parámetros de características relacionados
con la URI registrada
• Los parámetros básicos (base tags) soportados son: audio, automata,
methods, schemes, application, video, language, type, isfocus, actor, text,
extension. Otros parámetros no mencionados pueden ser añadidos con un
signo más (“+”). La definición de los parámetros queda recogida en la
RFC 3840
• No existe validación de sintaxis en los base tags o su contenido. El S-CSCF
ignora lo que no reconoce.
Preferencias del llamante: Estas preferencias son los mecanismos que
permiten al usuario llamante determinar preferencias sobre el tratamiento de
las peticiones en los servidores. Esto se lleva a cabo a través de tres cabeceras
de petición: Accept-Contact, Reject-Contact, y Request-Disposition25 .
El S-CSCF hace uso de enablers internos para analizar sintácticamente los mensajes
SIP y llevar a cabo operaciones sobre el flujo de la llamada. Utiliza el enabler de
normalización numérica para normalizar un número de teléfono cuando llega en su
forma abreviada. Asimismo se basa en el enabler DNS para buscar direcciones para
encaminar las peticiones. El DNS convierte una URI en un registro DNS compuesto
por una dirección IP, un puerto y un protocolo de transporte.
25
Este es un ejemplo claro del porqué de la elección de SIP en detrimento de otros protocolos como
el H.323: SIP presenta una clara facilidad de extensión mediante la inclusión de cabeceras y
parámetros.
101
Funcionalidad Interrogating-CSCF El núcleo IMS del SDS está integrado con

la función I-CSCF simulada, que actúa como un proxy SIP en el borde del
dominio administrativo (del operador). Esta función simulada ofrece un conjunto
de procedimientos descritos en el capítulo 2, basado a su vez en la sección 5.3 de la
especificación TS 24.229 v8.2 del 3GPP.
El I-CSCF del SDS se compone de las siguientes funciones:
Registro: Esta función soporta el registro, re-registro y desregistro tanto en
la red doméstica como en la red visitada
Encaminamiento de peticiones: Las peticiones enrutadas hacia el I-CSCF
se gestionan de la siguiente manera:
• Se permite a las peticiones REGISTER de usuarios en itineracia ser
encaminadas hacia el I-CSCF de la red doméstica. El Proxy-CSCF de
la red visitada envía el REGISTER al I-CSCF de la red doméstica
• Se permite el encaminamiento de peticiones terminadas en un dominio
perteneciente a otro operador (I-CSCF del dominio destino). El S-SCSF
de la red origen envía la petición al I-CSCF de la red destino.
Encaminamiento hacia Public Service Identity (PSI) destino: El
enrutado hacia el AS donde se encuentra alojado la PSI26 contenido en la
Request-URI. Las peticiones hacia la PSI de destino van directamente hacia
el AS que aloja este servicio PSI.
Peticiones seguras (trusted requests): todas las peticiones entrantes se
consideran seguras. El procedimiento para que el I-CSCF sepa si la petición
viene de un dominio seguro está descrito en la TS 33.210 del 3GPP, pero esta
versión del SDS no la soporta.
Configuración de IP y puerto: El I-CSCF simulado tiene su propia
configuración de dirección IP y puerto, configurables a través de las
preferencias del SDS.
Funcionalidad Proxy-CSCF La funcionalidad del P-CSCF simulado del SDS

soporta las siguientes capacidades:
Sobre el registro:
• Almacenamiento de la identidad predeterminada del usuario con la
cabecera P-Asserted-Identity
• Almacenamiento de las identidades públicas de usuario que se encuentren
en el valor de la cabecera P-Associated-URI
26
Una identidad de servicios públicos, Public Service Identity (PSI); como su nombre indica es
un servicio público estandarizado que permite a un operador proporcionar servicios accesibles
desde cualquier red SIP. Esto significa que cualquier contenido identificado a través de un PSI
es potencialmente accesible por todos los usuarios IMS del mundo, de cualquier operador, e
independientemente de si su contrato es fijo, móvil, de cable o de un paquete de convergencia.
Esto también significa que cualquier servicio es accesible desde una red no-IMS con conectividad
SIP, como por ejemplo Internet.
102
Figura 3.30.: Interfaz gráfica del BGCF simulado
Sobre el desregistro:
• El desregistro iniciado por el usuario provoca la eliminación de la
identidad pública de usuario y de todas las otras identidades públicas
asociadas, incluyendo toda la información relacionada almacenada
Tratamiento general:
• Gestión y tratamiento de la cabecera P-Preferred-Identity (presente o no)
con la P-Asserted Identity
• Roaming
• Soporte para mecanismos de privacidad de acuerdo a la RFC 3325
• Soporte para la cabecera de registro de caminos: Path, de la RFC 3327
Funcionalidad Breakout Gateway Control Function (BGCF) El SDS de

Ericsson integró (como se observa en la figura 3.30), a partir de su versión 4.1
la funcionalidad de pasarela hacia abonados de conmutación de circuitos, basándose
en un encaminamiento a partir de números de teléfono.
Por tanto, el core de la arquitectura de IMS simulada está integrado con la
funcionalidad BGCF simulada, cumpliendo con los principales detalles de las
especificaciones TS 23.228 y 24.229 del 3GPP. El BGCF es, básicamente, un servidor
SIP que encamina peticiones SIP y TEL URI hacia redes externas. La función BGCF
del SDS se invoca cuando el núcleo IMS del SDS recibe una petición SIP dirigida a
un número de teléfono y fracasa al traducir el número de teléfono a una SIP URI
— cuando falla la consulta DNS pertinente — y es preciso “salir” hacia una red
de circuitos PSTN/PLMN a través de una pasarela de salida —bien eligiendo otra
red IMS a partir de la cual salir al dominio de conmutación de circuitos (Circuit
Switched (CS)); bien eligiendo la pasarela hacia el dominio PSTN/CS si el terminal
de destino también pertenece a la misma red donde se encuentra el BGCF—. El
BGCF del SDS soporta la siguiente funcionalidad:
Tipo de sesión (session case): Esta funcionalidad se invoca internamente
103
para la parte origen cuando la petición se dirige a un número de teléfono y no

existe entrada SDS ENUM en la base de datos para ese número de teléfono, y
por tanto no es posible asociarle una dirección IP
Petición (Request): Esta funcionalidad puede invocarse por cualquier
petición SIP
Direccionabilidad: Funcionalidad colocada junto al CSCF (P/I/S) del SDS y
no direccionable externamente
Encaminamiento: Gestiona el encaminamiento hacia cualquier nodo config-
urado (puede ser la función Media Gateway Control Function (MGCF) o no).
Encaminará llamadas desde un sistema IMS hacia una red externa, espeficiada
por la configuración del SDS para los siguientes casos de tráfico:
• Encaminar directamente hacia un BGCF externo, que en definitiva
gestiona la selección de red externa
• Seleccionar una red externa (pasarela de salida) para encaminar la
petición SIP hacia una PSTN/PLMN
Selección de red externa: Esta función consiste en una SIP URI para
pasarelas hacia redes externas (por ejemplo el Media Gateway Control
Function (MGCF)). Si es necesario, se llevará a cabo una consulta DNS para
obtener una dirección IP. La selección de una red externa depende del valor
de la cabecera P-Asserted-Identity, del Request URI y de otras cabeceras que
se utilizan para realizar consultas en las tablas de configuración del BGCF
simulado del SDS. El procedimiento que se sigue para seleccionar la red externa
está en consonancia con el nodo destino de Ericsson. Los tres tipos de tablas de
configuración de selección externa de red, External Network Selection (ENS)
son:
• Tabla de la parte llamante
• Tabla de la parte llamada
• Tabla de pools de redes externas.
El BGCF del SDS viene con una GUI (figura 3.30) para editar las tres tablas
de configuración de redes externas. Esto proporciona acceso a los parámetros de
configuración requeridos y relevantes para la selección externa de red.
Domain Name Server (DNS)

El Domain Name Server (DNS) mapea nombres textuales y numéricos en
direcciones de Internet. El servidor proxy SIP hace uso de procedimientos DNS
para resolver URIs SIP o TEL URIs que contengan números E.164 en una dirección
IP, puerto y protocolo de transporte del siguiente salto en la señalización SIP. La
URI puede ser SIP, SIPS o TEL URI. La lógica de conversión se define en la RFC
3263. El DNS es necesario para resolver dos aspectos del flujo de la llamada:
El proxy ha de descubrir el servidor SIP en otro dominio, de cara a reencaminar
la llamada para el usuario. Debe determinar la dirección IP, el puerto y el
104
protocolo de transporte de este servidor

El proxy resuelve la dirección de equipo de las entidades pertenecientes al
mismo dominio en dirección IP, puerto y protocolo de transporte en la red.
El SDS hace uso del DNS BIND server del 3GPP para dar funcionalidad DNS.
El emulador del servidor (server emulator )

El SDS, a partir de su versión 4.0 viene haciendo uso del servidor de aplicación (AS)
de fuentes abiertas SailFin, de Sun Microsystems. El Sailfin AS es un producto de
la colaboración entre Sun y Ericsson en la cual Ericsson contribuyó con parte de sus
desarrollos en servidores al proyecto opensource GlassFish/SailFin. Ericsson cedió su
SIP Servlet 1.0 AS, basado en los estándares, al proyecto GlassFish/SailFin bajo la
licencia Common Development and Distribution License (CDDL). Ericsson tomará
los resultados de este proyecto opensource que pretende desarrollar un SIP container
(SSA 1.1) que cumpla con la nueva JSR 289.
El SDS 4.1 integra la release SailFin 1.0 Alpha. Esta versión alpha es conforme a
la especificación JSR-116 y parcialmente a la JSR-289. SailFin trabaja sobre una
plataforma Windows que proporciona al desarrollador el acceso al JEE/SIP AS en
un entorno hardware de escritorio. En el futuro, SDS integrará un paquete con la
release SailFin 1.0 con soporte total de la JSR-289. El SDS con SailFin posibilita a
los desarrolladors de servicios programarlos haciendo uso de una API JavaEE/SIP
que opera sobre el core del protocolo SIP, así como ensamblar y empaquetar los
servicios en archivos JEE/SIP listos para su despliegue en entornos reales basados
en JEE/SIP Application Servers comerciales.
APIs de servicios (servidor y cliente)

Una Application Programming Interface (API) se emplea por las siguientes razones:
Proporcionar acceso a los recursos de la red
Posibilitar el desarrollo de un amplio abanico de servicios
Permitir que terceras partes, más allá de los proveedores de los equipos, puedan
desarrollar servicios de valor añadido
Proporcionar librerías funcionales de programación a los desarrolladores
APIs del SDS
La API del servidor La API del servlet SIP (SIP Servlet API (SSA)) especificada
en la JSR-116 (SSA 1.0) y en la JSR-289 (SSA 1.1) se usa para la creación de
aplicaciones para ejecutarse en servidores de aplicación (ASs) JEE/SIP. La API del
servidor del SDS está basada en la JSR-116 y parcialmente en la JSR-289. Esta API
es una API Java para desplegar servicios Java basados en SIP sobre el servidor de
aplicación de fuentes abiertas SailFin de Sun.
105
3.5. EMULADORES DE TERMINALES MÓVILES
' $
Figura 3.31.: Vista general

de la estruc-
tura del SDS
desde el punto
de vista de
las APIs y la
plataforma
ICP.
& %
La ICP API del cliente Como se ha tratado con profusión en la sección 3.4.3,
la IMS Client Platform (ICP) es el servicio de segundo plano instalado en los
dispositivos para todos los clientes IMS. Las aplicaciones clientes acceden al entorno
de la plataforma ICP mediante las versiones “tempranas” de dos JSRs, la pre-JSR-
281 y la pre-JSR-325 API, tal y como muestra la figura 3.31
Esta ICP API pretende cumplir con la especificación JSR-281 a corto plazo y con
la JSR-325 a plazo medio. Como ya es conocido, esta API es un conjunto de librerías
de alto nivel para el desarrollo de aplicaciones cliente IMS.
La ICP IJCU del cliente La IMS JME Client Utility (IJCU) se instala en
terminales JavaME como parte de su paquete de midlets (midlet package)27
3.5 Emuladores de terminales móviles

El SDS 4.1 trae integrado un emulador de terminales con sistema operativo Symbian
v9 con interfaz gráfica UIQ 3 o S60 para el desarrollo y despliegue de clientes en
27
La API de la plataforma IJCU está basada en la JSR-281. Los paquetes y clases de esta API
vienen especificados en su correspondiente Javadoc [27]. Están contempladas las actualizaciones
de la IJCU hacia nuevas versiones de la JSR-281 y adoptar la JSR-325.
106
terminales (en concreto denominados smartphones) SonyEricsson P1 y Nokia N95.

Para los teléfonos más convencionales, es posible añadir al entorno de diseño del
SDS/Eclipse varios plugins del Wireless ToolKit (WTK) de Sun Java. Estos plugins
permiten a los desarrolladores el acceso a emuladores de teléfonos JavaME.
El emulador de los terminales presenta en la pantalla del PC una interfaz clickable
correspondiente a las respectivas pantallas/interfaces de los terminales, como se
ilustra en la figura 3.32.
En este apartado se ha de aclarar que el sistema operativo Windows puede albergar
clientes IMS, siendo el PC con el SDS el propio entorno de ejecución del dispositivo.
Un nuevo cliente desarrollado en el seno del entorno de diseño del SDS pasa a la
siguiente fase de testeo con el modo de emulación de dispositivo del SDS, con el
emulador Symbian UIQ/S60, o los emuladores JavaME Wireless Toolkit o bien el
mismo PC para los clientes Windows.
Además, la aplicación cliente puede testarse antes de su despliegue en dispositivos
reales en su emulador correspondiente, pero contra el core IMS simulado del SDS y
los enablers de servicios de comunicaciones, así como beneficiándose de los servlets
alojados en el servidor simulado JavaEE/SIP del SDS
Figura 3.32.: Pantallas de los correspondientes emuladores de teléfonos Symbian UIQ,

Symbian S60 y teléfonos JavaME.
3.6 Ejemplo de desarrollo de una aplicación IMS con el

SDS
A lo largo de este capítulo se ha descrito la herramienta elegida para el desarrollo
de aplicaciones y servicios IMS. Mediante una descripción a modo de tutorial del
funcionamiento del SDS se han ubicado sus subsistemas más importantes, se han
presentado todos los wizards, los asistentes de código, y detallado los parámetros
107
3.6. EJEMPLO DE DESARROLLO DE UNA APLICACIÓN IMS CON EL SDS
de configuración necesarios para “provisionar” cada elemento tanto de la red como

de los dispositivos cliente. Sin embargo, esta guía no queda cerrada ni completa si
no se acompaña de un ejemplo que ponga de manifiesto la necesidad del modelo
cliente-servidor y su desarrollo independiente, la utilidad de Java y sus APIs, y, por
último las ventajas y beneficios del SDS como entorno de desarrollo que añade las
capacidades de IMS como valor añadido de los servicios.
Por todo ello, se presenta un ejemplo sencillo pero que pretende clarificar el
modelo de comunicación en un servicio, subrayar dónde interviene el lenguaje de
programación y describir posibles capacidades y mejoras basadas en IMS.
3.6.1 Modelo y actores del servicio

Este ejemplo consiste en la interacción entre un cliente que bien puede ser un
dispositivo móvil — con Symbian para esta versión del SDS — o un cliente Windows;
y un servidor situado en la red IMS. La aplicación consiste en un juego muy sencillo:
“Adivine un número”. El jugador, el cliente, se registra en IMS, y accede al juego.
Una vez en la sesión del juego, el servidor le pide que adivine un número. El usuario
interactuará con el servidor enviando un número y éste le responderá si ha acertado,
o si el número que ha de adivinar es mayor o menor que el número insertado.
Con este ejemplo tan básico se pretende comprender la facilidad de implementar un
modelo cliente-servidor en IMS e ilustrar un paso de mensajes SIP básico. Asimismo,
el cliente dispone de una Graphical User Interface (GUI) sencilla que puede dar idea
del potencial de Java en este sentido, creando interfaces adaptadas a dispositivos
móviles de una manera intuitiva.
El modelo de comunicación que emplea el servicio puede describirse como el
siguiente intercambio de mensajes de señalización SIP:
1. En primer lugar, como en cualquier servicio IMS, es preciso un registro en la
red, de tal forma que el CSCF (via HSS) ya sepa qué servicios aplicar y en qué
servidores de aplicación. Por lo tanto la primera petición será un REGISTER.
El servidor responderá con un 200 OK.
2. El juego del ejemplo se lanza cuando el cliente envía un mensaje INVITE a una
dirección concreta como por ejemplo [email protected]. El servidor
responde con un 200 OK.
3. El cliente envía un mensaje ACK para establecer la sesión del juego. Cuando el
servidor recibe el mensaje ACK envía un MESSAGE para solicitar al usuario que
averigüe un número.
4. Si el cliente recibe correctamente el mensaje envía un 200 OK.
5. En este punto el cliente envía un MESSAGE con el número introducido por el
usuario. Se abren dos posibilidades:
Que el número sea cierto. En este caso, el servidor responde con un
MESSAGE con felicitaciones en su contenido y un BYE.
Si el número no es el correcto, el servidor envía un 200 OK y un nuevo
108
MESSAGE solicitando otro intento con un número mayor o menor.

6. El cliente asiente la recepción de este MESSAGE con un 200 OK.
7. Se repetirán los dos puntos anteriores hasta que el usuario acierte. Cuando lo
haga, el servidor lo felicitará con un MESSAGE y enviará un BYE.
8. El cliente responderá a este BYE con un 200 OK.
9. El cliente, a su vez, volverá a mandar un BYE para dar la sesión por terminada.
10. El servidor responde con un 200 OK.
3.6.2 Implementación en Java

Como se ha presentado en la sección anterior, el servicio consta de una aplicación
“servidor” y otra aplicación “cliente”. El servidor se encargará de aceptar peticiones
del cliente y aplicar la lógica del servicio. El cliente, a su vez, mostrará una interfaz
gráfica y ejecutará en el “lenguaje” de la comunicación cliente-servidor las peticiones
provenientes del usuario.
Como se argumentó en secciones anteriores, el servidor es un servlet SIP programa-
do en Java (Servlet.java). El cliente será una aplicación Java (Cliente.java) tras
una interfaz gráfica, dos cuadros de diálogo descritos por las clases Dialogo.java,
que muestra una petición de número al usuario, y DialogoMensajes.java, cuyo
cometido es mostrar el mensaje de felicitación cuando se acierta un número. Y por
último pero no menos importante, el cliente, por estar destinado a ejecutarse sobre
la plataforma del cliente IMS Client Platform (ICP) (ver sección 3.4.3) necesita los
adaptadores de la ICP para funcionar sobre el dispositivo cliente. Para el presente
ejemplo, es posible emplear los siguientes adaptadores incluidos en la herramienta
de Ericsson, cada uno descrito por una clase Java:
PlatformAdapter.java: Implementa la interfaz de la ICP IPlatformListener,
necesaria para crear un IProfile.
ProfileAdapter.java: Implementa la interfaz de la ICP IProfileListener,
necesaria para crear un IService.
ServiceAdapter.java: Implementa la interfaz de la ICP IServiceListener,
necesaria para crear un ISession. Los métodos de ISession son los encargados
de construir el mensaje SIP INVITE para iniciar el juego
SessionAdapter.java: Del mismo modo que los adaptadores anteriores,
implementa la interfaz de la ICP ISessionListener para capturar los eventos
que se incluyen en el cliente:
• processError
• processSessionStartFailed
• processSessionMessage
Todos los clientes montados sobre la ICP requieren uno o más listeners para
atender a los eventos que se producen en la lógica del servicio. Algunos listeners
tienen muchas funciones obligatorias. Para hacer uso de esas funciones, aunque
109
Método SIP Método Java que lo implementa

INVITE doInvite()
ACK doAck()
MESSAGE doMessage()
BYE doBye()
Tabla 3.1.: Métodos SIP y su mapeo en Java.
fuera una sola, se deben implementar todas las funciones de ese listener para
poder usarlas. Para facilitar el desarrollo, el SDS crea clases de adaptadores.
Estos adaptadores son simplemente una implementación “vacía” o “hueca” de los
listeners. Los adaptadores proporcionados con el SDS son un método conveniente
para implementar todas las funciones de los listeners de modo que la aplicación a
desarrollar tenga acceso a la función que necesite, y así no sea necesario implementar
funciones que nuestra aplicación no usará.
Es posible observar, cómo cada adaptador es necesario para implementar otro,
construyendo una estructura de capas sobre cuya superficie se sostiene la aplicación
cliente.
No es objetivo de este Proyecto Fin de Carrera analizar línea por línea el código
Java que implementa el servicio. Sin embargo, es de interés explicar cómo Java
implementa los mensajes SIP que entiende el núcleo IMS. Por ello, se hace una
división entre servidor y cliente a la hora de explicar cómo Java se involucra en el
desarrollo de aplicaciones y servicios IMS.
Métodos SIP en el servlet

En la tabla 3.1 se indica cómo el SDS mapea los métodos SIP en métodos Java.
En el SDS es posible elegir los métodos SIP que se necesitan implementar, y que
además, serán en sí mismos la invocación del servlet. Es decir, si por ejemplo se desea
invocar al servlet para lanzarlo con un INVITE desde el cliente, es preciso seleccionar
la inclusión del método doInvite() durante la creación del servlet. Al llevar a cabo
esta selección, se añade una mapping rule por defecto, que habrá que modificar de
acuerdo con las reglas de lanzamiento de servicios definida en el HSS.
En el apéndice C.4.4 se muestra el código del servlet del juego “Adivine un número”
que sirve de ejemplo para ilustrar un servicio IMS.
Métodos SIP en el cliente

En el lado cliente, ya se ha introducido que la aplicación se soporta sobre la ICP,
que desde la perspectiva Java, la componen “de arriba hacia abajo”, los adaptadores
de sesión, servicio, perfil y plataforma. Estos adaptadores, hacen de intermediarios
a la hora de crear las peticiones y respuestas SIP.
En el ejemplo, se puede ver que para inicializar el adaptador de sesión se crea un
110
ISession. ISession es un objeto que representa una sesión genérica y facilita la

tarea de implementar el comportamiento típico de una sesión. Es decir, de cara al
mapeo de métodos SIP, un ISession es el encargado de componer los mensajes SIP
INVITE.
IService, por ejemplo, es una interfaz para manipular sesiones con comportamien-
tos de “búsqueda”, incluyendo opciones de envío que descubran las capacidades del
otro extremo, subscripciones (método SUBSCRIBE) a eventos, publicaciones de un
estado (método PUBLISH), envío de peticiones REQUEST, envío de mensajes, etc. Tra-
ducido a Java, un cliente dispondrá de estas capacidades si se ha creado previamente
un objeto IService.
Del mismo modo, otros adaptadores siguen el mismo patrón, son capaces de
construir y analizar mensajes SIP dentro de su lógica a través de este tipo
de objetos: IService, ISession, e incluso algunos adaptadores específicos para
servicios definidos como PGM (IPresence), VoIP, PoC, IM,... En todos ellos, la
“I” indica “interfaz”.
Por otro lado IProfile es la interfaz principal con la ICP. Proporciona los métodos
para las operaciones con la ICP. Una aplicación cliente para la ICP precisa registrarse
en la ICP a través de esta interfaz, previa creación de cualquier sesión. No obstante,
el objeto IProfile no puede existir sin haber creado anteriormente el objeto
IPlatform sobre el que IProfile se soporta.
En el apéndice C.4.4 se muestran los códigos del cliente y de los adaptadores de la
ICP usados en el ejemplo.
3.6.3 Creación de valor añadido: capacidades IMS y mejoras

La aplicación de ejemplo es un caso simple de comunicación cliente servidor con
las capacidades básicas de registro, una lógica de servicio simple y una provisión
sencilla. Sin embargo, IMS ofrece un amplio abanico de capacidades que dotan de
valor añadido a muchas de las aplicaciones que se encuentran hoy día por ejemplo
en Internet.
De este modo, un simple juego como el “Adivine un número” podría convertirse en
un complejo sistema de lotería, como el del juego de la Primitiva en España, en el
que los jugadores tienen que elegir una combinación de números que se sortean. IMS
interviene en el servicio proporcionando valor añadido desde diferentes ángulos:
Creando un canal de comunicación seguro a partir de la identificación del
cliente en la red.
Ofreciendo un canal streaming del sorteo con la interactividad necesaria para
participar en directo.
Desarrollando una ampliación del ejemplo que permita la comunicación PoC
con los miembros de una peña en apuestas conjuntas.
Incluyendo precios más asequibles a ciertos clientes de la operadora, que a su
vez se vería beneficiada por un nuevo sistema de fidelización.
111
Queda patente pues, la gran versatilidad de IMS, al proporcionar un marco

con cabida para prácticamente cualquier proveedor relacionado con Internet y/o
las telecomunicaciones. A su vez, el SDS queda refrendado por ser un aceptable
simulador de la red, con la gran ventaja de la experiencia de Ericsson en el
desarrollo software de librerías Java y hardware de servidores y racks de equipos
de telecomunicaciones.
112
4. CREACIÓN DE UN SERVICIO
IMS CON EL SDS
En este capítulo se abordarán las diferencias más significativas entre el estándar IP

Multimedia Subsystem (IMS) y su entorno de desarrollo más completo, el Service
Development Studio (SDS). Para ello, el estudio se centrará en el núcleo de la
filosofía de IMS y de la Cuarta Generación (4G): los servicios. En un primer lugar
se estudiará el proceso de creación de un servicio desde la perspectiva del estándar
del Third Generation Partnership Project (3GPP) para más tarde acometer una
comparación en base al análisis de la creación de un servicio desde la perspectiva
del Service Development Studio (SDS).
' $
Figura 4.1.: Beneficios para el usuario de las aplicaciones IMS.

& %
4.1 Visión general de la creación de un servicio IMS

El IP Multimedia Subsystem (IMS) permite la introducción y libre integración
de los servicios que hoy en día se disponen en una “torre” de diferentes redes
independientes entre sí. En la figura 4.1 queda ilustrado esta transición, desde el
concepto de n servicios-n redes a la filosofía de n servicios-una red. IMS facilita
la integración y la convergencia en el acceso (soporte para múltiples dispositivos
y múltiples redes de acceso), basándose en capacidades y servicios estandarizados
113
4.1. VISIÓN GENERAL DE LA CREACIÓN DE UN SERVICIO IMS
como son la telefonía IP multimedia, la mensajería IMS, Push-to-Talk (ya bautizado

en castellano como “pulsa y habla”), presencia, gestión de grupos, etc. con nuevos y
diferenciados servicios tales como aplicaciones para la productividad empresarial,
aplicaciones para el consumidor, juegos multijugador, contenidos y aplicaciones
multimedia, y una infinidad de posibilidades que puedan surgir a partir de una
buena idea.
Los servicios de comunicaciones de IMS, o IMS Communication Services (CoSe)
(en adelante CoSe), proporcionan el soporte de red para aplicaciones universales
destinadas al gran público; así como permite la integración de aplicaciones
diferenciadas de nuevos operadores a través de capacidades bien definidas entre las
cuales se incluyen la gestión de medios, principios de encaminamiento, y servicios
suplementarios.
Estas capacidades fundamentales son exactamente idénticas en cualquier red o
dispositivo IMS y por tanto están optimizadas en rendimiento para su despliegue
masivo en los mercados. En consecuencia, los servicios CoSe son los cimientos
naturales para la interoperabilidad global. Asimismo, las capacidades CoSe están
expuestas a través de APIs en cada extremo de la comunicación para las comunidades
de desarrolladores tanto para dispositivos como servidores de aplicación (ASs). Los
servicios CoSe están basados en los estándares actuales y se actualizarán a medida
que avanza el proceso de estandarización.
' $
Figura 4.2.: IMS Communication Services: El uso de APIs en los

extremos de la comunicación. Fuente: Ericsson.
& %
Los CoSe de IMS se extienden cruzando las interfaces denominadas Network

to Network Interface (NNI) y User to Network Interface (UNI). Los servicios
multimedia terminan en el dispositivo o en los servidores en la frontera de una red
IMS. La red IP actúa como un túnel versátil y estandarizado para los servicios
multimedia. Las aplicaciones pueden conectarse a través de APIs tanto en el
dispositivo como en la red (en los servidores). Para los operadores, ésta es una
forma natural para establecer acuerdos de interconexión sobre “túneles” específicos,
114
así como para conectarse a Internet y a la industria multimedia.

En la creación de un servicio, la industria de las aplicaciones actuará principalmente
en los extremos de la red y sobre UNIs. La combinación de las capacidades CoSe
junto aplicaciones únicas y contenidos multimedia crea experiencias de usuario ricas
y atractivas. De aquí que la mayoría de las aplicaciones IMS se provean en los
extremos de IMS: dispositivos, servidores y sites de servicios. De esta manera se
conectan de una manera natural las industrias de los medios y de los contenidos.
La industria se encuentra actualmente estandarizando tres servicios de comuni-
caciones IMS y dos mecanismos de soporte (ver figura 4.3). El Java Community
Process (JCP) se encuentra de la misma manera normalizando APIs para el clien-
te/dispositivo, como las APIs de servicios IMS (JSR-281) y las APIs de enablers de
comunicación IMS (IMS Communication Enablers (ICE)) (JSR-325)
' $
Figura 4.3.: Visión general de los CoSe y sus mecanismos de

soporte, servicios y estandarización de las interfaces.
Fuente: Ericsson.
& %
MMTel CoSe: se basa en la aplicación de telefonía multimedia (MultiMedia

Telephony, MMTel), estandarizada de manera común entre el Telecoms and
Internet converged Services and Protocols for Advanced Networks (TISPAN)
y el Third Generation Partnership Project (3GPP). Está optimizado para el
suministro extremo a extremo de datos multimedia en tiempo real entre dos
partes conectadas. Además, contiene el control duplex en tiempo real de los
medios y de los servicios suplementarios definidos en el estándar.
PoC CoSe: basado en el servicio Push-To-Talk over Cellular (PoC)
estandarizado por la Open Mobile Alliance (OMA). El objetivo principal de
este servicio es la comunicación en grupos y por ello propone una solución con
datos multimedia half-duplex en tiempo real, pero con control de “suelo” para
la transmisión continua. Cada participante en la conversación está conectado
115
4.1. VISIÓN GENERAL DE LA CREACIÓN DE UN SERVICIO IMS
a un gestor de grupos central que administra el grupo y la distribución de

medios.
Mensajería IMS CoSe: Este servicio está basado en el estándar de
mensajería de OMA, el modo de búsqueda (page mode) y la mensajería
instantánea/chat (IM/Chat). En este servicio la principal misión es la de
garantizar la recepción de los mensajes, que ha de ser inmediata si el usuario
destino está disponible.
Presencia y Gestión de Grupos, Presence and Group Management
(PGM): también de OMA, son unos mecanismos de soporte para
proporcionar información de disponibilidad y gestión de grupos de usuario.
Servicios Combinados (Combinational Services), para la combinación
de voz y vídeo sobre conmutación de circuitos (Circuit Switched (CS)) y
aplicaciones IP móviles Peer-to-Peer (P2P), tal y como promueve la GSM
Association (GSMA), y empieza a estandarizar el 3GPP.
Servicios IPTV: Gestionados por el Open IPTV Forum, se está trabajando
hacia una especificación e-2-e que permita a cualquier usuario el acceso a
servicios Internet Protocol Television (IPTV) personalizados y enriquecidos,
y desde cualquier dispositivo; siguiendo las especificaciones del Open IPTV
Forum.
El éxito de IMS, como viene siendo tradicional en las Telecomunicaciones,
dependerá de la disponibilidad de dispositivos debidamente adaptados. El principal
escollo para el despliegue de nuevas tecnologías es normalmente la falta de
disponibilidad de terminales móviles que las soporten.
El 3GPP, como organismo de estandarización, no plantea soluciones a problemas
comerciales de la industria. Ericsson, la compañía que ha desarrollado el entorno
de desarrollo de aplicaciones IMS estudiado en este proyecto, tomó varias medidas
clave para liderar el crecimiento de IMS y sus servicios:
Liderar la estandarización de la API en Java para terminales (JSR-281 y JSR-
325) para que todos los terminales Java futuros posibiliten IMS.
Ofrecer un framework para las APIs IMS (basadas en la pre-JSR-281/325)
como una IMS Client Platform (ICP) descargable para terminales basados en
los sistemas operativos Symbian y Windows — extendiendo gradualmente el
soporte para otros SOs como Windows Mobile, Linux (Linux, Linux Mobile,
Android,...), etc.
Proporcionar capacidades IMS a aquellos terminales actuales con soporte Java
pero sin soporte SIP: la IMS JME Client Utility (IJCU).
Integrar la funcionalidad de la API IMS a los terminales con plataformas
Ericsson.
Además, Ericsson colabora de manera muy significativa en la especificación de la
API Java de servicios IMS (JSR-281) y la API de enablers de comunicaciones (JSR-
325), dentro del Java Community Process (JCP).
Todas estas razones son por lo tanto suficientes para estudiar la herramienta de
116
' $
Figura 4.4.: Ciclo de vida completo de una aplicación.

& %
desarrollo SDS en profusión, tal y como se hizo en el capítulo anterior. Sin embargo,
se analizará en la siguiente sección la peculiaridad existente en la creación de nuevos
servicios.
4.2 Creación de un servicio con el SDS, paso a paso

Los proveedores de servicios, así como empresas independientes de desarrollo
software pueden hacer uso del SDS para explorar la viabilidad y aspectos de
aceptación del usuario final acerca de los nuevos servicios IMS. Lo primero que
hay que tener claro es que las aplicaciones que se desarrollen y testen con el SDS
pueden desplegarse en un entorno IMS real y comercial, incluyendo dispositivos y
servidores.
El proceso de desarrollo de servicios no consiste solo en la creación de estos, no
se centra solo en la programación de una aplicación determinada en un entorno de
desarrollo concreto. El proceso de desarrollo de servicios consiste en la gestión de
todo el ciclo de vida de las aplicaciones, desde la idea hasta su despliegue y puesta
en funcionamiento. La figura 4.4 ilustra este proceso [29].
4.2.1 Primera fase: programar, testar, y simular extremo a

extremo en PCs con emuladores IMS SDS
La figura 4.5 ilustra una visión de alto nivel de la primera fase de la creación de un
servicio: el trabajo con el entorno de desarrollo. Sobre un PC con una instalación
del SDS, se procedería al desarrollo software de la aplicación que, en caso de éxito,
117
4.2. CREACIÓN DE UN SERVICIO CON EL SDS, PASO A PASO
proporcionaría un servicio en la red IMS real.
Figura 4.5.: Primera fase: programar, testar, y simular extremo a extremo en PCs con
simuladores de IMS SDS. Fuente: Ericsson.
Una aplicación en IMS puede ser cliente a cliente o cliente servidor. En cualquier
caso será necesario como mínimo cubrir una de las dos partes siguientes:
1. Lado servidor
a) Crear un proyecto SIP/Web dinámico
b) Crear un SIP servlet
c) Codificar
d) “Provisionar” el CSCF
e) Establecer el servidor de entorno de ejecución por defecto (Default
Runtime Server)
f ) Desplegar el proyecto sobre el servidor de aplicaciones SailFin
g) Testar la aplicaicón
h) Realizar baterías de pruebas con el ATF
i) Depuración y subsanación de errores
j) Ajustes necesarios para pasar a la siguiente fase de creación de un servicio
2. Lado cliente
a) Crear un proyecto de ICP
b) Añadir las capacidades ICP necesarias
118
c) Codificar
d) Instalar el cliente en Windows
e) Lanzar el entorno de ejecución
f ) Configurar el perfil de usuario en la ICP
g) Reiniciar la ICP
h) Desplegar y ejecutar la aplicación
i) Depuración y subsanación de errores
j) Ajustes necesarios para pasar a la siguiente fase de creación de un servicio
En esta primera fase donde el papel importante lo juega el simulador del núcleo
de IMS de Ericsson existe otra variante: emplear dispositivos reales que se conectan
vía la red móvil de paquetes a los PCs con el SDs donde se alojen los servidores de
aplicación. Esta variante, que queda ilustrada con la figura 4.6 precisa de unos pasos
de configuración en los dispositivos móviles que se describen en la sección 4.2.2,
con la salvedad de que habrá que configurar los PCs con el SDS dotándolas de
una dirección IP pública para ser accedidos en el core IP desde los Gateway GPRS
Support Node (GGSN) del operador móvil que da acceso IP en movilidad.
Figura 4.6.: Primera fase (variante con terminales reales): programar, testar, y simular
extremo a extremo en PCs con simuladores de IMS SDS pero haciendo uso
de dispositivos y redes de acceso reales para acceder al núcleo IMS simulado.
Fuente: Ericsson.
119
Figura 4.7.: Segunda fase: test y pruebas de usuario extremo a extremo con dispositivos y
redes reales. Fuente: Ericsson.
4.2.2 Segunda fase: test y pruebas de usuario extremo a extremo

con dispositivos y redes reales
La siguiente fase consiste en el testeo y pruebas extremo a extremo alojando los
servicios en los servidores de aplicación integrados en el IDE SDS/Eclipse pero
accediendo a ellos a través dispositivos reales y una red con funciones IMS reales
implementadas en equipos dedicados.
En este proyecto se han llevado a cabo pruebas sobre terminales Sony Ericsson
reales, en concreto los modelos M600 (figura 4.8) y P1i (figura 4.9) ambos,
obviamente con sistema operativo Symbian y plataforma UIQ. Los pasos previos
para testar los servicios son:
1. Instalar la IMS Client Platform (ICP) en los terminales a través de su
correspondiente suite de comunicación con el PC.
2. Instalar la aplicación cliente del servicio sobre la ICP tal y como se vio en el
capítulo 3 generando el fichero .sis y descargándolo en el terminal.
3. Configurar en los terminales la red de acceso a través de la cual se llevará a
cabo la conexión al entorno real de IMS.
Una vez realizados los pasos previos es preciso disponer de un entorno real de IMS
para llevar a cabo la señalización de los servicios que se quieren testar. En este
proyecto se han analizado las dos alternativas posibles: disponer de un entorno real
local o remoto. En este sentido, en la siguiente sección 4.2.3 y en el apéndice B se
trata con profusión la solución de Ericsson en materia de core real y local de IMS.
Por ello, esta sección se dedica a la solución de la compañía finlandesa Octopus
120
Figura 4.8.: Terminal de pruebas Sony Ericsson M600 utilizado en el proyecto.
Figura 4.9.: Terminal de pruebas Sony Ericsson P1i utilizado en el proyecto.
121
Network, que proporciona un entorno real remoto para pruebas y ensayos de

aplicaciones y servicios basados en IMS.
La solución de testeo remoto de Octopus Network

Esta plataforma pone a disposición de sus clientes conexiones a sus laboratorios
para el testeo en equipos reales y certificados de aplicaciones y servicios IMS.
Octopus juega con la baza de disminuir el Time To Market (TTM) y garantizar la
calidad avalada por
Un desarrollo y testeo eficiente en costes, ya que esta solución es más económica
que la de adquirir un entorno real.
Proporciona una perspectiva más realista que el entorno simulado.
Pone a disposición de sus clientes un gran elenco de expertos en la red IMS y
en el desarrollo de servicio.
Octopus agrupa a más de 60 compañías (partners), investigadores en el centro
finlandés de desarrollo en las Comunicaciones Móviles en Oulu, y clientes
de reconocida experiencia, lo que aumenta su prestigio y publicidad. Los
participantes más activos son Nokia, DNA, TeliaSonera, OAMK, Innovación
de Oulu y la Ciudad de Oulu. Los clientes de Octopus han creado decenas de
soluciones y servicios móviles bajo el entorno de Octopus [30].
Proporciona tutorías y training por lo que es una solución atractiva para
PyMEs.
Por otro lado, Octopus proporciona las siguientes soluciones:
Testeo interoperable en un entorno real de un operador con despliegue IMS a
través de acceso móvil e inalámbrico.
Plataforma de pruebas en varias tecnologías.
Inicio de sesión, autenticación y verificación
Interoperabilidad y handover entre diferentes redes.
Consultoría tecnológica.
Testeo de aplicaciones:
• Trazas del tráfico y distintos registros (logs).
• Enablers tecnológicos avanzados: Presencia, PTT,...
• Pruebas de “usabilidad”, grupos de usuarios reales, metodología Living
Lab.
• Multiacceso móvil e inalámbrico (3G, HSPA, WLAN, mWiMAX).
Arquitectura de la solución de Octopus Octopus es una plataforma avanzada

de movilidad, donde se investigan, desarrollan y testan tecnologías móviles
inalámbricas, así como aplicaciones y servicios. El núcleo del servicio que ofrece
Octopus es un entorno cerrado de un operador — concebido para el desarrollo y
122
Figura 4.10.: Arquitectura de la solución de Octopus para el testeo remoto de aplicaciones y

servicios IMS. Fuente: Octopus Network.
testeo de aplicaciones móviles — que funciona con un acceso internacional desde

distintas redes (GPRS, 3G, HSPA, B3G, WLAN). La plataforma de ensayos, testeo y
pruebas proporciona a los clientes de esta solución, como se observa en la figura 4.10,
un núcleo de red de IMS completo, accesible desde varias redes distintas. En este
sentido, el cliente puede elegir el medio de acceder a la plataforma, según las
necesidades de su aplicación o la planificación de sus proyectos. Un cliente podría
optar, por ejemplo, por hacer uso de WLAN, o por otro lado adquirir una tarjeta
SIM de TeliaSonera, con un contrato específico de 3G con la operadora para acceder
al core IMS de Octopus a través de roaming 3G.
Asimismo, el entorno es completamente interoperable, y garantiza la seguridad
por medio de cortafuegos y autenticación a través de servidores RADIUS (observar
la figura 4.10) y túneles Virtual Private Network (VPN) con IPsec desde los
laboratorios del cliente hasta los de Octopus.
4.2.3 Tercera fase: despliegue en servidores comerciales

Una vez codificado el servicio IMS, testado en un core real y abordada la
depuración sólo quedaría desplegar comercialmente el servicio. En este último punto,
la última capa de IMS, la de aplicación, se transportaría desde el PC donde
ha sido desarrollada y testada hasta servidores reales comerciales como el Oracle
Communications Converged Application Server (OCCAS) (BEA Weblogic Server),
con una mayor capacidad y escalabilidad, así como una mayor versatilidad de
123
configuración (figura 4.11).

En este apartado, y a caballo entre la segunda fase de creación de un servicio y
la presente; se tiene de nuevo una solución de Ericsson que integra en una sola
infraestructura hardware acceso “agnóstico” a IMS, núcleo IMS, y servidores de
aplicación comerciales IMS. La inclusión del IMS Common System de Ericsson,
así como su estudio pormenorizado en el apéndice B se debe a la falta de despliegue
de IMS que hoy en día padecen la mayoría de los cores de red de los operadores. Al
no existir una puerta abierta para que desarrolladores y otros terceros desplieguen
comercialmente nuevas aplicaciones y servicios de IMS, algunos laboratorios y
empresas de desarrollo software se decantan por adquirir un entorno real local
para el testeo y puesta a punto de nuevas aplicaciones y servicios, que quedarían
totalmente preparadas para su despliegue en tiempo mínimo cuando los núcleos de
los operadores soporten la arquitectura de IMS. O, incluso, lanzar estos servicios
sobre redes actuales beneficiándose de protocolos de IMS (SIP, DIAMETER,...)
pero soportando deficiencias de la red actual (best-effort frente a QoS, ausencia
de integración de servicios, pérdida de control de la cadena de valor por parte del
operador, etc.).
Figura 4.11.: Tercera fase: despliegue en servidores comerciales. Fuente: Ericsson.
Un entorno real local: El IMS Laboratory System de Ericsson

El IMS Laboratory System de Ericsson es la solución personalizada del IMS
Common System de la compañía sueca. Éste, a su vez, es parte de la unidad de
negocio Ericsson IMS, como bien es posible observar en la figura 4.12. En esta
se ubica el entorno de desarrollo Service Development Studio (SDS) estudiado en el
capítulo 3 como un producto de creación del nivel de aplicación dentro de Ericsson
124
IMS. En esta figura queda refrendado el papel de Ericsson en su compromiso con el

IMS, puesto que hasta la fecha ningún otro fabricante ha desarrollado una solución
tan completa ni compacta para IMS.
Figura 4.12.: Esquema de las soluciones comerciales del área Ericsson IMS, estructuradas
en soluciones, productos y servicios. Fuente: Ericsson.
El entorno real de IMS, IMS Laboratory System persigue instalar un core de

IMS que refleje la red de un operador comercial, de tal modo que se permita el acceso
al núcleo de IMS como si el operador la tuviera desplegada. Con esto se persigue:
Facilitar el testeo de nuevas aplicaciones IMS.
Catalizar y acelerar al cliente que contrate el IMS Laboratory System el
proceso de pruebas, demos y presentaciones de las aplicaciones IMS.
Asimismo, el IMS Laboratory System ha de incluir una integración con la red
de conmutación de circuitos del operador, para asegurar la convergencia. Este hecho
parte de la suposición de que el potencial cliente requiere una integración en el
acceso, y por tanto este supuesto conduce a la provisión de pasarelas (Media Gateway
Control Function (MGCF)/Media GateWay (MGW)) en la arquitectura del IMS
Laboratory System. Esta integración se completa con la adición de un módulo Session
Border Controller (SBC) (Acme 5.1) para ensayos y pruebas con la red de acceso
fijo.
125
Todo el hardware se monta sobre el bastidor Ericsson BYB 501 4.13 en tres
compartimentos distintos:
Armario para Telecom Server Platform/Network Server Platform (TSP/NSP)
con un rack o rejilla de 400 mm de profundidad para montar el hardware de
las plataformas TSP/NSP.
Armario para Integrated Site (IS): de 400 mm de profundidad para montar
los sub-racks de IS.
Cabina de datos en el BYB 501 de 800 mm de profundidad de cara a montar
los elementos de la red de SUN y HP, el Acme SBC así como la conectividad
entre la plataforma y en el exterior con el módulo switch/router
Figura 4.13.: El bastidor BYB 501 que aloja los elementos del core real de Ericsson para
testeos y pruebas.
Arquitectura del IMS Laboratory System de Ericsson En la figura 4.14 se ilustra

la arquitectura del entorno real de Ericsson, con el núcleo IMS, los enablers y las
pasarelas para movilidad y convergencia. El PLMN, realmente, puede ser cualquier
operador móvil que opere en el país donde se lleve a cabo la instalación de este
entorno real.
126
' $
Figura 4.14.: Arquitectura del entorno real de Ericsson. Fuente: Ericsson.

& %
Core
Un CSCF y un HSS:
1
• hardware: Un 4
OPTI TSP
• software: IMS Common System 4.1
◦ La colocación del core IMS (HSS+CSCF) está propuesta de este
modo bajo la suposición de una solución más económica y compacta.
◦ Es preciso tener en cuenta que de este modos el core es una “caja
negra” que limita la visibilidad y control de errores sobre algunas
interfaces del núcleo, como podría ser el control sobre Diameter.
Un DNS instalado en una máquina SUN NETRA 240, con software IPWorks
5.0.
Un Redback SE400 con 60 puertos Fast-Ethernet y 2 puertos Gigabit Ethernet.
Un armario para Telecom Server Platform/Network Server Platform (TSP/N-
SP) .
Un armario para datos.
Capa de aplicación
Un Presence and Group Management (PGM)
127
1
• hardware: Un 4
OPTI-4 TSP: un armario TSP/NSP
• software: PGM 4.1
Un Oracle Communications Converged Application Server (OCCAS) Oracle
(BEA) Web Logic Sip Server para instalar las aplicaciones desarrolladas, por
ejemplo con el Service Development Studio (SDS) de Ericsson.
• hardware:
◦ HP PROLIANT DL360 G4p , SCSI
◦ Procesador Xeon 3,6 GHz
◦ 2o Procesador Intel Xeon 3,6 GHz
• software:
◦ Linux Red Hat Enterprise ES 3.0
◦ BEA WebLogic SIP Server 2.2
◦ MySQL Databe 5.0.24a
Un Push-To-Talk (PTT)
1
• hardware: Un 4
OPTI-4 TSP: un armario TSP/NSP
• software: Servidor PTT 4.1
Puntos para la integración y convergencia de redes de acceso: IMS

Multi-Access (IMA)
Un punto para la integración GPRS/UMTS: interfaz Gi con el operador
de telefonía y datos en movilidad1 .
Integración Internet/Acceso fijo:
• Un A-SBC (Net Session Director 5.1) de ACME.
• La integración de los servicios entre el núcleo de red IMS y una red IP
externa se lleva a cabo a través de un Session Border Controller (SBC).
Integración PLMN SS7/TDM:
• software MGC 5.1 y MGW 1.2, ambos instalados en el mismo equipo
hardware: Integrated Site (IS) R1.2.
• Un armario Integrated Site (IS).
• La integración con el dominio de conmutación de circuitos móvil (PLMN)
en una red externa se lleva a cabo a través de un IS.
1
Se asume contrato de colaboración entre el cliente que instala la solución de Ericsson en materia
de núcleo de red y el operador que proporciona la red de acceso a susodicho núcleo.
128
4.3 Diferencias entre el estándar y el SDS: Limitaciones

y problemas
El Service Development Studio (SDS) es un entorno de desarrollo para aplicaciones
y servicios de IMS que simula el núcleo de red de IMS para que esta simulación baste
a la hora de asegurar el cumplimiento (al menos en unos mínimos) con el estándar.
Sin embargo, la complejidad de las especificaciones de IMS, hacen casi imposible un
soporte de las capacidades IMS total del lado del entorno software de desarrollo, al
menos en las primeras versiones de este Integrated Development Environment (IDE).
Durante la elaboración de este proyecto, se confeccionó un cuaderno de notas sobre
el que se iban anotando cualquier limitación y problema que se hallara con la
herramienta de Ericsson. Las principales conclusiones fueron:
4.3.1 Limitaciones
El CSCF está como un nodo único y sus tres funciones (P-CSCF, S-
CSCF, I-CSCF) están limitadas por este hecho. Su configuración se limita
prácticamente a dirección IP y puerto, no dejando opción a muchas otras de
las funcionalidades que se describen en el estándar.
• Posibles mejoras: Ampliación de los parámetros, desarrollo de una
interfaz gráfica web para la configuración de estos parámetros en remoto.
Ausencia de un nodo independiente para el HSS sobre el que implementar
interfaz DIAMETER. El hecho de que el HSS aparezca como una mera GUI
reflejando campos de una base de datos interna limita el despliegue real
con el paso de mensajes sobre la interfaz Sh (mensajes DIAMETER para
autenticación, descarga del perfil XML, etc.)
• Posibles mejoras: Independencia del HSS con dirección IP y puerto
propios y soporte para DIAMETER.
Falta absoluta de control sobre interfaces DIAMETER y COPS: El SDS no
soporta mensajes COPS sobre la interfaz Go para políticas de tráfico y QoS
ni mensajes DIAMETER con el HSS o el Policy Decision Function (PDF).
• Posibles mejoras: Al igual que con los servlets SIP, podría crearse
una estructura con wizards y asistentes de código que implementaran el
modelo cliente-servidor de DIAMETER y COPS con una interfaz sencilla,
pero soportando elementos importantes como seguridad y QoS.
Ausencia del MRFC/MRFP limitando los servicios que pudieran implemen-
tarse relativos a contestador, servicios originados en la red con inclusión de
medios, etc.
• Posibles mejoras: El SDS podría venir integrado con un reproductor/-
codificador de medios con su correspondiente soporte en clases de Java y
descripción SDP.
A día de hoy, el SDS sólo soporta el SIP AS, no teniendo soporte para CAMEL
129
4.3. DIFERENCIAS ENTRE EL ESTÁNDAR Y EL SDS: LIMITACIONES Y PROBLEMAS
ni OSA.
• Posibles mejoras: Aunque no sea uno de los objetivos del SDS, podrían
integrarse en el mismo IDE el IM-SSF y el OSA-SCS de terceros como
Rhino (IM-SSF) o Parlay (OSA).
Aparte de la implementación de los elementos del núcleo de red, el SDS
no recoge plataformas adicionales definidas por el 3GPP como el Voice Call
Continuity (VCC)2 que es un elemento esencial en el modelo de convergencia
fijo móvil.
• Posibles mejoras: Contactos con empresas como Huawei [31], compro-
metidas con el desarrollo de VCC y su inclusión en IMS.
4.3.2 Principales problemas

Problemas con el emulador del cliente: Mediante los distintos ensayos
durante el desarrollo del proyecto se vieron serias limitaciones referentes a la
inestabilidad del emulador, básicamente comprobando cómo una aplicación se
ejecuta perfectamente en Windows pero no es posible hacer lo mismo emulador.
Dos problemas concretos fueron:
• En el SDK de Symbian/UIQ aparece que se pueden emular distintos
terminales, entre los que se encuentra el M600i y el P990. El único
terminal que permite configurar correctamente los parámetros de IMS
Settings (permiten establecer la conexión con la red IMS) es el M600i.
• No permite simular varios clientes en la misma máquina. Esta problemáti-
ca se plantea porque en determinados servicios existen diversos posibles
usuarios que pueden usarlo tomando diferentes roles, y para comprobar el
correcto funcionamiento del servicio deben probarse dichos roles al mismo
tiempo. Para el caso de dos clientes se deben conectar dos ordenadores
con un cable de red cruzado y lanzar los elementos del core y ASs en
uno de ellos; y en el caso de que se deseara añadir algún cliente más a la
prueba se tendría que utilizar un switch.
Estado actual de desarrollo de las APIs. La tecnología IMS ofrece una gran
potencialidad que de momento no está al alcance de los desarrolladores que
utilizan esta herramienta debido a que estas características no se encuentran
implementadas en las APIs (en concreto las APIs de la IMS Client Platform
(ICP)): APIs de QoS, APIs de DIAMETER, streaming, (en este sentido, la
utilidad IPTV de la versión 4.1 FD1 del SDS no funciona), etc.
Soporte de IVideoPlayer, IVideoRecorder para lanzar aplicación de reproduc-
2
El Voice Call Continuity (VCC) (3GPP TS 23.206), en un futuro Multimedia Session Continuity
(MMSC) y IMS Service Continuity (IMScont) (3GPP TS 23.206) consiste, grosso modo en un
conjunto de especificaciones para describir cómo una llamada de voz (sesión multimedia a
partir de la release 8 ) se mantiene mientras un teléfono móvil se mueve entre un dominio de
conmutación de circuitos y un dominio de conmutación de paquetes. El ejemplo más claro es el
de una llamada originada en GSM que se mantiene continua, y con la misma calidad, al entrar
en una zona de cobertura WiFi.
130
ción de video en el terminal al tener un buffer de entrada de video en la versión

4.0 de la herramienta no estaban implementadas estas clases. En la versión 4.1
FD1 el paquete com.ericsson.icp.multimedia está bastante completo en lo
referente a audio, pero sigue sin soportar vídeo. Como solución se ha propuesto
utilizar otra aplicación programada sobre un tercer componente para manejar
el flujo de video en el terminal. Es decir, se estaría tratando por un lado la
parte de IMS, con su señalización, lógica de perfiles, etc, hasta que el buffer
llega al terminal; y a partir de ese momento se utilizaría otro aplicación total-
mente independiente de IMS para manejar dicho flujo y lanzar un reproductor
apropiado (en este caso el mismo VLC que sirve para IPTV). De todas formas,
por parte del soporte oficial de la herramienta se ofrece esta posibilidad como
alternativa al problema y haciendo usos de características de IPTV, pero no
como solución probada.
El SDS no es multiplataforma. Además de su falta de compatibilidad con
Linux, MAC y otras plataformas, el SDS es particularmente inestable con
Windows Vista, por lo que hay que recurrir a herramientas de máquinas
virtuales como VMWare o Virtual PC 2007 de Microsoft.
Problemas con la instalación de aplicaciones en dispositivo real: Existe una
opción en la herramienta para instalar aplicaciones en terminales reales
(Install in Symbian Device). Esta opción recomienda el soporte de Ericsson
no utilizarla porque no funciona correctamente. A la hora de instalar las
aplicaciones se ha de utilizar el PC Suite del dispositivo, o hacerlo tratando al
teléfono como una unidad externa, pero siempre al margen de la herramienta.
La compatibilidad entre versiones se ha mejorado con la introducción de
un traductor de versiones (legacy applications). Sin embargo, la tarea de
conversión desde versiones 3.1 a posteriores es especialmente ardua, ya que del
lado del cliente la ICP constaba de tres capas o adapters(Platform, Service
y Session) y ahora cuenta con cuatro (Platform, Profile, Service, Session).
131
5. PROPUESTA DE DESPLIEGUE
COMERCIAL DE UN SERVICIO Y
PLAN DE EXPLOTACIÓN
5.1 Propuesta de despliegue comercial de un servicio

IMS
5.1.1 Introducción al problema
Una vez llegado a este punto, en el cual se dispone de una aplicación o servicio
testado y probado, es natural formularse la pregunta: “¿y cómo se despliega este
servicio para que tenga un uso comercial por parte de los clientes de un operador?”
Esta pregunta podría resolverse mediante una simple conclusión a partir de
lo expuesto en capítulos anteriores: bastaría con desplegar la aplicación en los
servidores de aplicación del operador, y llegar a un acuerdo comercial con él, para
que éste también lo añadiera a su oferta comercial e incorporara el perfil del servicio
a su HSS.
Sin embargo, es de sobra conocido que los operadores son reacios a esta apertura
tan directa, por razones obvias: el núcleo de una red IMS de un operador es tan
sensible e importante que supondría demasiado riesgo que aplicaciones de terceros
intercambiaran mensajes directamente con elementos de este core como el S-CSCF
o el HSS. Si SIP se expone abiertamente al dominio de aplicación de terceros el
operador corre el riesgo de que terceras partes controlen y pongan en peligro la
integridad de la red o pierdan el control del spam.
Existen otras razones, como la tradición heredada de que en el dominio de
conmutación de circuitos, ni ISUP ni INAP estaban expuestos a terceras partes.
Y además, razones comerciales que se verá en la siguiente sección pero cuyo objetivo
final es evitar que los operadores se conviertan en meros bit-pipes (canalizadores de
bits) o “transportistas” de datos.
5.1.2 Los Web Services

Por ello, y siguiendo la tendencia más importante y con más éxito en la
actualidad [32]: la Web 2.0, se ha creado una solución intermedia que salvaguarda
la seguridad de los operadores aislando su núcleo de las aplicaciones de terceros.
Y, además, simplifica el modelo de interacción con la red de manera que hace aún
133
5.1. PROPUESTA DE DESPLIEGUE COMERCIAL DE UN SERVICIO IMS
más sencillo si cabe el desarrollo de servicios alcanzando un nivel superior en la

abstracción de la tecnología subyacente.
Los Web Services permiten la mejora de los servicios y el aumento de oportunidades
de beneficio posibilitando el acceso de terceras partes a grandes capacidades
tecnológicas como las que proporciona el IMS. Las grandes ventajas de los web
services basados en estándares pueden resumirse en:
Proporcionan un acceso controlado y flexible a los datos y las capacidades de
la red.
Facilitan la permanencia de los grandes clientes mediante la segmentación de
la oferta. Esto se consigue estableciendo acuerdos a niveles de servicio o a nivel
de cada abonado.
El servidor de los web services protege los recursos de la red de accesos no
autorizados o de sobrecargas de tráfico con un control estricto y efectivo del
acceso y gestión de capacidades de tráfico.
Facilitan el soporte y la creación de comunidades de desarrollo.
Permiten y aceleran el despliegue flexible de servicios IMS basados en interfaces
estandarizadas y el uso de Service Oriented Architecture (SOA).
Las implementaciones de los web services proporcionan interfaces estandarizadas,
de acuerdo a los estándares Parlay X1 de servicios web, para el acceso a las redes
de telecomunicaciones, así como a sus funciones; incluyendo éstas establecimiento
de llamada a tres, notificaciones de llamada, tarificación, estado del terminal y
capacidades de valor añadido como la presencia. Así como otras muchas capacidades
que están por llegar.
En la figura 5.1 se ilustra la separación entre la arquitectura de servicios web sobre
IMS basados en Parlay X/SOA y el núcleo de red IMS. El intermediario, en este caso,
es la pasarela Open Service Access/Architecture (OSA), que aísla al programador de
la complejidad de la red, y aísla al operador del peligro de la exposición a terceros.
5.1.3 Alternativas de despliegue comercial de un servicio IMS

Las alternativas de las que dispone un desarrollador cuando se enfrenta a la creación
de un servicio IMS en la parte del servidor son básicamente tres:
1. Desarrollo SIP nativo: Como se explicó en el capítulo 2, SIP comenzó
siendo un protocolo textual relativamente simple, sin demasiados métodos
1
Parlay, y más en concreto Parlay X es un conjunto de APIs de servicios web para redes
telefónicas fijas y móviles. Definido conjuntamente por la ETSI, el Parlay Group y el 3GPP,
Parlay X permite a los desarrolladores de software hacer uso de las capacidades de las redes
de telecomunicación subyacentes. Las APIs son abstracciones de alto nivel con un especial
énfasis en la sencillez de uso y aprendizaje. Un programador podría, por ejemplo, invocar
una petición sencilla de servicios web para obtener la localización de un móvil, o iniciar una
llamada telefónica. Las APIs de Parlay X están definidas con tecnologías web services: interfaces
definidas con el lenguaje Web Services Description Language (WSDL) a partir de su versión
1.1 y conforme a los perfiles de la Web Services Interoperability.
134
Figura 5.1.: Arquitectura de IMS donde se aprecia el papel de los servidores Parlay X de
servicios Web.
(REGISTER, INVITE, ACK, BYE, CANCEL, OPTIONS) pero gracias a su gran

capacidad de extensión el protocolo ha ganado en complejidad a la vez que
versatilidad, por lo que la programación directa de mensajes de protocolo ha
dejado de tener sentido. Y ésta era en un principio la filosofía de IMS con la
adopción de SIP: que surgieran métodos de desarrollo alternativos.
2. APIs Java2 para SIP Servlets: Esta alternativa simplifica enormemente el
desarrollo debido a su abstracción y a la vasta comunidad de desarrolladores de
Java, que facilita la proliferación de IDEs de desarrollo como el SDS de Ericsson
tratado en el capítulo 3. Sin embargo, como se ha comentado anteriormente,
esta opción no es tan adecuada de cara a la apertura del sistema hacia terceros,
así como por otros inconvenientes como la dependencia existente entre la
evolución de los servicios y la infraestructura de red.
3. Hacer uso del entorno Open Service Access/Architecture (OSA) en el
contexto de la arquitectura orientada a servicios Service Oriented Architecture
(SOA): Esta alternativa presenta las siguientes ventajas:
Gran perspectiva en cuanto a la funcionalidad del acceso: SIP, SS7,
VoXML, SMPP, características móviles, etc.
Portabilidad de la lógica de servicio:
2
También es posible utilizar scripts Common Gateway Interface (CGI) como programación SIP,
pero por diversas razones, como entrada en desuso, no entra dentro del alcance de este proyecto.
135
Figura 5.2.: El OSA Application Server en la arquitectura del IMS.
• SIP, Circuit Switched (CS), red inteligente, etc.

• Control de llamada, presencia, etc.
Los frameworks de OSA/Parlay y Parlay X/Web Services están diseñados
para permitir que terceras partes —proveedores de servicios— tengan
acceso de una manera segura y controlada a las capacidades de la red.
Soporte sólido por parte de los grupos de estandarización, desarrolladores
de aplicaciones, operadores de red y fabricantes de equipos a las APIs
(Parlay/OSA (APIs abiertas) y Parlay-X (APIs de Web Services)) con
independencia del fabricante.
Los servicios desarrollados en OSA/Parlay pueden llegar a expandirse por
los dominios de IMS y los tradicionales de conmutación de circuitos.
El OSA AS (representado en la figura 5.2 como Service Delivery Platform
(Application Server)) no compromete la independencia entre la evolución
de los servicios y la infraestructura de red.
Se ha llegado a la conclusión de que el SIP-AS está destinado a nuevos servicios
controlados por el operador o más cercanos al interés general, mientras que los
servicios OSA vía el servidor Open Service Access-Service Capability Server (OSA-
SCS) se adaptan mejor a la apertura y soporte al desarrollo de terceros y el Open
Service Access-Service Capability Server (OSA-SCS) proporciona el acceso y el
control de los recursos de la red del operador, así como garantiza su protección. En
la figura 5.3 se puede observar cómo IMS podría orquestar ambas opciones, junto
con otras alternativas de provisión de servicios como serían los Web Services HTTP
con capacidades IMS, los mashups o los widgets de la filosofía Web 2.0. Así como
un servidor de aplicación de Customized Applications for Mobile network Enhanced
Logic (CAMEL) para estos servicios heredados, o un AS local instalado en la misma
máquina del CSCF para servicios simples o de chequeo de la red.
A la hora de desplegar un servicio en el servidor de aplicaciones OSA se tienen
básicamente dos puntos de partida: un servicio desarrollado en el lenguaje nativo de
136
Figura 5.3.: IMS se concibe como una arquitectura de control de servicios horizontal, con
cabida para distintas filosofías de creación de servicios y distintos escenarios de
interacción con el núcleo de la red.
Parlay o Parlay X. O bien, partir de un servicio desarrollado en otro lenguaje, para

el cual, por la naturaleza del proyecto y de la tecnología se elegirá Java.
5.1.4 Propuesta de despliegue para Parlay X Web Services

Parlay X Web Services hace uso del protocolo Simple Object Access Protocol
(SOAP) sobre HTTP; así como de las siguientes tecnologías:
Web Services Description Language (WSDL) para la descripción de las
interfaces.
XML para los tipos de datos.
Seguridad Web services.
Cumplimiento del perfil básico de interoperabilidad Web services-Interoperability
(WS-I).
El servicio IMS que se desea desplegar en el servidor de aplicaciones Web services
puede estar desarrollado en principio en cualquier lenguaje de programación; siempre
y cuando soporte Web services, realice las invocaciones a métodos correctas, así como
maneje las respuestas correspondientes que reciba de la versión concreta de la API
de la pasarela Parlay. Por tanto, una aplicación puede ser un programa en Java, en
Visual Basic, o un script XML.
En general, la interacción entre la aplicación y la pasarela puede ser compleja y
explotar todas las capacidades de las APIs Parlay X.
Existen diversas herramientas para distintos lenguajes de programación; para la
creación, depuración, interacción y despliegue de Web services. Ejemplos de estas
herramientas son Telecom Web Services SDK 4.0, de Ericsson; así como otros
SDKs integrables en distintos IDEs como Eclipse (con el plugin de Apache Axis2
137
que traduce de WSDL a Java y viceversa), NetBeans de SUN (con wsimport) o

JDeveloper de Oracle.
Los pasos para crear un servicio web sobre IMS y desplegados sobre una
arquitectura OSA/Parlay X web services son:
1. Instalación/integración como plugin del SDK en el IDE habitual.

2. Importar los servicios a partir de un descriptor de servicios web (fichero WSDL
(.wsdl)) en el lenguaje que se vaya a programar la lógica de esta solución (.NET,
Java,...). Se elegirá Java por las razones ya comentadas. Estos servicios, según
la especificación de Parlay X 3.0 [33] se organizan en partes (parts):
Part 1 : Common. Definitions re-used across multiple Parlay X specifi-
cations: Definiciones comunes a lo largo de las múltiples especificaciones
de Parlay X.
Part 2 : Third Party Call. Creating and managing a call initiated by
an application: Creación y gestión de una llamada iniciada por una
aplicación.
Part 3 : Call Notification. Handling calls initiated by a subscriber in
the network. One variant (i.e. application interface) allows application to
direct the handling of the call and the other simply provides a notification:
Gestión de llamadas iniciadas por un abonado de la red. Una variante (o
sea, una interfaz de aplicación) permite a una aplicación dirigir la gestión
de una llamada y la otra simplemente proporciona una notificación.
Part 4 : Short Messaging. Receive and send SMS (including delivery
receipts): Envío y recepción de SMS (incluyendo acuses de recibo).
Part 5 : Multimedia Messaging. Receive and send Multimedia Messages:
Recepción y envío de MMSs.
Part 6 : Payment. Payment reservations, pre-paid payments, and post-
paid payments: Reservas de pago, prepagos y postpagos.
Part 7 : Account Management. Account querying, direct recharging and
recharging through vouchers: Consultas a la cuenta, recargas directas y
recargas a través de “vales” o cupones.
Part 8 : Terminal Status. Get the status of a terminal e.g. reachable,
unreachable or busy: Obtiene el estado de un terminal. Ej.: accesible, no
accesible u ocupado.
Part 9 : Terminal Location. Getting location information about a
terminal: Obtiene información acerca de la localización de un terminal.
Part 10 : Call Handling. Specify how calls are to be handled for a specific
number. There is no “per-call interaction” with the application unlike in
the Call Notification API.: Especifica cómo las llamadas se gestionan para
un número específico.
Part 11 : Audio Call. Provide multimedia message delivery and the
dynamic management of the media involved for the call participants:
138
Proporciona el envío de mensajes multimedia y la gestión dinámica de

los medios involucrados entre los participantes de la llamada.
Part 12 : Multimedia Conference. Create a multimedia conference and
the dynamic management of the participants involved: Crea una confer-
encia multimedia y la permite la gestión dinámica de los participantes
involucrados.
Part 13 : Address List Management. Manage groups (aliases) of
subscribers: Maneja grupos (alias) de los abonados.
Part 14 : Presence. Presence information to be obtained about or
registered for users used e.g. by Instance Messaging clients: Información
de presencia a obtener o a usar de la almacenada previamente por
otros usuarios. Por ejemplo: la información de estado de los clientes de
mensajería instantánea.
Part 15 : Message Broadcast. Send messages to all the fixed or mobile
terminals in a specified geographical area: Envía mensajes a todos los
terminales fijos o móviles en una área geográfica específica.
Part 16 : Geocoding. Get the location address of a subscriber e.g. country,
state, district, city, street, house number, additional information, and
zip/postal code: Obtiene la dirección de localización de un abonado.
Part 17 : Application-driven Quality of Service (QoS). Dynamically
change the quality of service (e.g. bandwidth) available on end user
network connection: Calidad de servicio asistida en la aplicación cambia
la calidad de servicio (por ejemplo el ancho de banda) disponible en la
conexión del usuario.
Part 18 : Device Capabilities and Configuration. Get information about
device capabilities and push device configuration to a device: Obtiene
la información sobre las capacidades del dispositivo y cambia las
configuraciones del dispositivo.
Part 19 : Multimedia Streaming Control. Control streaming of multime-
dia to a subscriber e.g. to transfer stream between a user’s terminals:
Controla el streaming multimedia hacia un abonado.
Part 20 : Multimedia Multicast Session Management. Control a multicast
session, its members and multimedia stream, and obtain channel presence
information: Controla una sesión de retransmisión multicast, sus miem-
bros y el flujo de medio, así como obtiene información de presencia sobre
el canal.
3. Una vez introducida la URL donde se aloja el descriptor de servicios se genera
el código Java que se guardará como una biblioteca Java en una carpeta
determinada.
4. Con las clases autogeneradas se dispone del esqueleto del servicio. A partir de
ahí se programará el resto de la lógica que se desee añadir para proporcionar
al servicio más valor añadido y un mayor atractivo.
139
5.2. EL MODELO DE EXPLOTACIÓN DE IMS
Figura 5.4.: Despliegue de aplicaciones IMS sobre un servidor Websphere de IBM. Fuente:
IBM.
5. Depuración, testeo y pruebas.

6. Finalmente se tendrá que desplegar el servicio3 . Por la naturaleza de OSA, un
servidor de aplicaciones podría ser la propia máquina del desarrollador, o bien
el de un proveedor de servicios que disponga de un servidor de web services
IMS como el Websphere de IBM de la figura 5.4.
5.2 El modelo de explotación de IMS

5.2.1 Estado actual del despliegue de IMS y diferentes planes de
explotación
En España, a día de hoy, existe poca información acerca del despliegue real
de la infraestructura de IMS o de los productos o servicios que podrían salir a
corto o medio plazo al mercado. Se han analizado dos alternativas de los dos
operadores de telefonía móvil con mayor cuota de mercado en España, Telefónica
Movistar y Vodafone. Estas dos iniciativas aportan soluciones IMS relacionadas con
3
Realmente, por la filosofía de OSA, se podrá testar el servicio con la red real, ya que de por sí
la red del operador no corre ningún peligro al existir la pasarela entre el servidor de aplicación
y el núcleo de la red.
140
la convergencia pero desde dos puntos de vista diferentes.
WIMS 2.0: El nombre de esta iniciativa promovida por Telefónica aglutina

dos conceptos fundamentales para la convergencia entre Internet y las
Telecomunicaciones: la Web 2.0 e IMS.
La concepción del usuario como “motor” de unos servicios de Internet
totalmente flexibles, interactivos, personalizables y abiertos dio lugar al origen
del término Web 2.0. Más que una mera denominación, la Web 2.0 es un
conglomerado de ideas que conducen la exitosa evolución de las tecnologías y
servicios de Internet.
Por otro lado, IMS es capaz de ofrecer capacidades provenientes del mundo de
las Comunicaciones Móviles y las “telcos” en general que aporten valor añadido
a estos servicios 2.0.
Tal y como recoge en su manifiesto [34], la iniciativa WIMS 2.0 pretende aunar
las mejores características de la Web 2.0 y de IMS creando una sinergia que
permita la convergencia de Internet y las Comunicaciones Móviles que traiga
consigo nuevos y más beneficiosos modelos de negocio. WIMS 2.0 aborda esta
convergencia desde dos frentes:
• Apertura de las capacidades de IMS del operador al mundo 2.0 mediante
mashups basados en widgets o basados en APIs. Asimismo, promover la
creación de servicios y generación de contenidos por parte del usuario.
• Inclusión de la filosofía Web 2.0 en la oferta de servicios de los operadores
móviles, creando así un catálogo más amplio y acorde con las tendencias
actuales de Internet — por otro lado más dinámicas y exitosas frente
al estancamiento de los servicios ofertados por los operadores móviles —.
WIMS 2.0 propone en este caso la introducción de los contenidos y eventos
Web 2.0 en los servicios del operador y la prestación de los servicios IMS
a través de interfaces Web creando aplicaciones online en lo que se ha
denominado “terminal virtual” [34].
Oficina Vodafone: Vodafone España ha denominado así a su solución de
convergencia fijo-móvil para empresas. Funcionando sobre IMS, la Oficina
Vodafone ofrece un sistema único de telecomunicaciones para todos los
empleados de una empresa. Este sistema agrupa sus funcionalidades en tres
servicios:
• Servicios básicos: numeración fija asociada al móvil y tarifas de fijo para
los móviles dentro de la oficina.
• Servicios avanzados de centralita VoIP en red sobre IMS: extensiones,
cola de llamada, gestión de agentes, desvíos, multiconferencias, etc.
• Servicios de gestión via Web: las funcionalidades de Oficina Vodafone
se gestionan a través de una interfaz web, lo que implica una mayor
flexibilidad, rapidez de implantación y capacidad de autogestión.
Asimismo, esta solución de convergencia añade la gran capacidad de
escalabilidad de las redes inalámbricas, ya que es posible la conexión de otros
141
usuarios sin cambios en la infraestructura ni inversiones adicionales.
5.2.2 Visión estratégica del IP Multimedia Subsystem (IMS)

En la actualidad, un operador pone a disposición de sus clientes un gran elenco de
servicios a través de diversos medios (servicios sobre llamadas, portales multimedia,
etc. Sin embargo, apenas el 5 % son utilizados por el 90 % de los clientes [35], lo que
significa que el operador, con sus servicios, no satisface a los usuarios. El usuario
busca esta satisfacción independientemente de la red suyacente, de la tecnología
empleada (siempre que funcione, y lo haga adecuadamente).
No obstante, esta independencia, para el operador no es tal, y ha de buscar en la
tecnología una solución que de alguna manera satisfaga las nuevas necesidades de
los usuarios: “segmentando el mercado, reduciendo el tiempo de comercialización
y aumentando la creatividad en la producción de nuevos servicios”; incorporando
a terceros — con un mejor conocimiento de los servicios y más cerca del usuario
final— en el modelo de explotación de los servicios IMS. La arquitectura de
IP Multimedia Subsystem (IMS) introducida por organismos de Comunicaciones
Móviles heredó este conocimiento estratégico y ha tenido en cuenta esta necesidad
de versatilidad, de centrar el objetivo en el usuario, de tratarlo de la manera más
personalizada posible, y de habilitar espacio para su creatividad.
Visión del operador

Las razones estratégicas para que los operadores desplieguen IMS en sus redes son,
básicamente: una significativa reducción de los costes de la red – que es sobre
IP y por lo tanto más económica – tanto en personal como en infraestructuras,
favoreciendo la escalabilidad y amortización más rápida de su red; la rápida
implantación y proliferación de nuevos servicios más adaptados al cliente,
ayudando a su captación y posterior fidelización; y un considerable incremento de
las ventas y beneficios procedentes de los mismos.
Como hemos repasado en otras secciones del documento, en la estructura de red
tradicional cada servicio tiene implementaciones separadas de funcionalidades co-
munes (facturación, presencia, gestión de grupos y listas de contactos, encami-
namiento, provisión, etc.), y la estructura está replicada a lo largo de toda la red
— un servicio, una red —. IMS proporciona una serie de funciones comunes y es-
tandarizadas que son genéricas en su estructura e implementación, y que pueden ser
reutilizadas por todos los servicios de la red. Por ejemplo, el sistema de facturación
IMS registra los datos relacionados con la sesión IMS, tales como los usuarios im-
plicados, la duración, los componentes multimedia empleados y la QoS autorizada;
y permite facturar cualquier tipo de servicio tanto en postpago como en prepago,
según su duración, contenidos, volumen de datos, destino de la sesión o las diferentes
combinaciones de los anteriores. Esto además facilita y acelera el proceso de creación
y suministro de servicios, la reutilización de infraestructura de transporte de red y
de servidores de aplicaciones, y minimiza el inmovilizado fijo y la necesidad de per-
sonal técnico en todas las áreas (provisión y despliegue, operación y mantenimiento,
142
tarificación y facturación, etc.).

La posibilidad de ofrecer paquetes de servicios es muy importante para las
operadoras de telecomunicación. Por ejemplo, la ventaja tradicional de las
operadoras de cable frente a los antiguos monopolios telefónicos, era la posibilidad
de ofrecer una oferta integrada de telefonía, Internet y televisión — el triple play—.
Ahora la amenaza se halla en los nuevos proveedores de servicios que son capaces
de ofrecer aplicaciones gratuitas o a bajo coste sobre su infraestructura de red.
De esta forma, empresas como Skype
c pueden ofrecer VoIP de bajo coste a sus
usuarios empleando una arquitectura Peer-to-Peer (P2P), sin tener que pagar al
proveedor de acceso a Internet por ofrecer dicho servicio y sin tener que asumir el
mantenimiento de ninguna infraestructura de red y siendo tan sólo necesario unos
pocos servidores. No obstante, estas empresas no son capaces de ofrecer el catálogo
de servicios que podría ofertar una operadora con IMS. Además, las operadoras
podrán gracias a IMS hacer converger el mundo de las telecomunicaciones con el
de la informática, permitiendo a sus clientes empresariales disfrutar de muchas de
sus aplicaciones actuales bajo el modelo de pago por uso, sin tener que realizar
constantes inversiones en hardware y software, ya que será más rentable y eficiente
distribuirlas en red.
Por estas razones, IMS se convertirá en la solución preferida para el negocio de las
operadoras multimedia fijas, móviles y convergentes, permitiendo ofrecer servicios
eficientes en términos de funcionalidad, precio y calidad, que les permitan hacer
frente a los nuevos y agresivos proveedores de servicios de Internet y entrar en
nuevas áreas de negocio.
Visión del usuario

¿Qué beneficios tiene IMS para los usuarios? La telefonía móvil e Internet han
demostrado que los usuarios están cada vez más interesados en servicios de
comunicación más allá de la voz, como demuestra el éxito de los SMS y de la
mensajería instantánea, respectivamente. Pero los usuarios de telecomunicación
actuales están cada vez más informados y son más exigentes, y se ha demostrado con
iniciativas como los servicios 3G, que no siempre se cumplen las expectativas creadas
por las operadoras y suministradores de infraestructura de telecomunicación. Para
que los servicios multimedia tengan éxito, no basta con que sean útiles, también
es necesario que sean innovadores, sencillos de utilizar, baratos y accesibles en
cualquier momento y lugar. Para los usuarios, los servicios basados en IMS permiten
la comunicación persona a persona y persona a contenido en gran variedad de modos
(incluyendo voz, texto, imágenes y vídeo, o una combinación de todas ellas) de
una forma altamente personalizada y mucho más sencilla, puesto que el servicio es
independiente del tipo de terminal o red de acceso que emplee en ese momento. Los
usuarios se verán así beneficiados por servicios más adaptados a sus necesidades y
fáciles de utilizar, precios más competitivos, factura unificada, y mayor sencillez en
las gestiones de incidencias.
143
5.2.3 Nueva cadena de valor de los servicios de telecomunica-

ciones
Según un estudio de 2008 de la prestigiosa firma ABI Research [36], IMS producirá
un aumento de 300 millones de dólares en los ingresos de las operadores que
lo desplieguen en los próximos cuatro años. Este hecho supondría una solución
al estancamiento de los ingresos de las operadoras. Pero, ¿de dónde viene ese
espectacular aumento en la caja de las operadoras?
En esta sección se presentan primero los hechos para luego tratar de contestar a
esa pregunta.
Aparición de nuevos agentes

Como se ve en la figura 5.5, han surgido nuevos agentes que proporcionan valor a
los servicios de telecomunicaciones. Estos nuevos actores han aparecido en la cadena
de valor gracias a la revolución en los nuevos servicios de Internet auspiciados a su
vez por la banda ancha y la convergencia de contenidos. IMS se situaría por debajo
de esta cadena de valor, dando cabida a todos los agentes implicados.
Figura 5.5.: Nueva cadena de valor de los servicios de telecomunicaciones. Fuente: gaptel
Nuevos agentes: oportunidad y amenaza

La incorporación de los proveedores de contenidos y agregadores debería suponer
una oportunidad para los operadores de telecomunicaciones, ya que poseen más
experiencia a la hora de detectar y satisfacer necesidades del usuario; por lo que
aportarían ese conocimiento en la generación de mayores ingresos por usuario
Average Revenue Per User (ARPU).
Un caso de gran éxito y que muestra la importancia de los nuevos agentes es la Web
2.0 [32]. Esta filosofía apuesta por un modelo de servicios con una gran participación
144
por parte del usuario final. En el mundo móvil, este nuevo paradigma ha venido de
la mano de los Internet Based Services (IBS), que no son más que las aplicaciones y
servicios que hoy se encuentran en cualquier equipo de sobremesa con una conexión
de internet; pero adaptados para el móvil. Así existen multitud de aplicaciones
desarrolladas por terceros y dispuestas en servidores auspiciados por los fabricantes
de terminales, que con una gran apuesta han dinamizado enormemente el sector con
portales como Apple Store para el iPod y iPhone; Android Market para los móviles
con este sistema operativo Linux con soporte de Google o el OVI de Nokia para el
sistema operativo Symbian. Estos repositorios almacenan miles de aplicaciones que
de una manera u otra están revolucionando el mercado.
Sin embargo, la amenaza de la incorporación de estos nuevos actores reside en
el hecho de que si los contenidos y servicios provienen de terceros agentes, los
operadores quedarían relegados a meros conductores de información y se alejarían
paulatinamente de los usuarios finales, sus clientes.
5.2.4 Solución: el proveedor integral de servicios

La solución a los riesgos para el operador con la aparición de la nueva cadena de
valor están en un nuevo modelo de operador, que facilitaría el acceso y crearía
sus propios servicios en colaboración con los nuevos agentes especializados que
dispondrían de su parte de negocio en el nuevo modelo, y tendrían incentivos para
crear nuevos servicios y evolucionar los ya existentes.
Con este modelo, el operador sí sería capaz de alcanzar las cifras presentadas en la
introducción; ya que no perdería el control sobre la cadena de valor y conformaría un
proveedor integral de servicios — en este caso servicios IMS — con características
fundamentales en los nuevos paradigmas de la Sociedad de la Información:
Se concede al operador su importancia como tractor de la I+D+i.
El modelo reconoce la necesidad de abrir el negocio de los servicios móviles a
terceros agentes expertos en sus respectivos sectores.
Se beneficia del multiacceso propiciado por el despliegue de IMS y lo considera
una oportunidad (roaming entre redes, sesiones continuas, etc.) no como una
amenaza.
Fomenta la interoperabilidad entre redes y la necesidad de estandarización en
todos los niveles.
El modelo estabiliza la cadena de valor convirtiéndola en un entorno de
competencia colaborativa bajo la máxima de ofrecer cada vez más contenidos,
aplicaciones y servicios atractivos para el usuario.
El modelo refuerza el papel del operador, asegurando su persistencia en la
cadena de valor; por lo que el regulador dispone de vías más cómodas para
supervisar y estimular los mercados de las telecomunicaciones.
145
6. CONCLUSIONES Y RETOS
FUTUROS
Para este capítulo se pretende reunir las conclusiones más importantes que se han
ido extrayendo a lo largo de todo el documento, así como apuntar las posibles líneas
de trabajo que emanan de aquellos aspectos que no se trataron con demasiada
profundidad.
6.1 Conclusiones
Las Comunicaciones Móviles actuales y las Telecomunicaciones en general, están
evolucionando en una dirección clara: la convergencia con otros agentes como son el
mundo de la informática, la industria tecnológica y los contenidos, dando origen
a una amalgama que hoy se conoce como Sociedad de la Información. Es
posible afirmar que hasta hace unos años todos estos actores avanzaban por caminos
paralelos e independientes, formando estratos heterogéneos donde se podía encontrar
la tecnología electrónica en la base y los contenidos en la superficie.
Sin embargo, la tendencia reciente persigue una evolución más homogénea y
sinérgica por parte de cada una de las partes implicadas. De este modo, se ha tratado
en este Proyecto Fin de Carrera de dar explicación a este fenómeno, justificar su
necesidad, determinar su repercusión en todos los niveles; y elaborar propuestas
para tratar de alcanzar el éxito de este nuevo modelo. Por todo ello, la tecnología
objeto de estudio es el IP Multimedia Subsystem (IMS), considerada como
el conjunto de estándares que proporciona una solución óptima al paradigma de la
nueva Sociedad de la Información. En consecuencia, se han dividido las conclusiones
más importantes según cada agente implicado para tener a la vez una perspectiva
global pero articulada con la que entender mejor la importancia de IMS.
Para las Telecomunicaciones, y en concreto para los operadores de
telecomunicaciones, IMS aporta calidad de servicio (QoS), permite la
tarificación versátil, promueve la integración de los servicios —
alcanzando el paradigma de “una red-N servicios” — y flexibiliza la
identificación del usuario mediante el uso de URIs, permitiendo la aparición
de identidades privadas y públicas más intuitivas y directas, tal y como
se vio en el capítulo 2. Fue en este capítulo donde ya se anunció el concepto
de Todo-IP, más conocido en inglés como All-IP, la nueva arquitectura de
redes global y convergente de la que IMS es su componente más desarrollado.
Para la industria tecnológica y los fabricantes de dispositivos, IMS trae
consigo soluciones y protocolos estándar, de modo que al existir estas normas
147
6.1. CONCLUSIONES
comunes libres de derechos (descritas en la sección 2.4) se facilita el intercambio

de ideas y experiencias, se mejoran las especificaciones gracias a una amplia
revisión, se comparten los costes de las pruebas de desarrollo, se ahorran
gastos de consultoría, se promueve el crecimiento gracias a la confianza del
mercado, ... Los estándares abiertos aumentan la innovación y la competencia,
y los clientes y usuarios, al final, depositan más confianza en la industria, pues
no están sujetos a soluciones propietarias.
El mundo de la informática y en concreto las tecnologías de Internet tienen
en IMS una puerta de entrada al mundo de las Comunicaciones Móviles,
donde pasan a ser protagonistas. IMS hace uso de protocolos oriundos del
mundo de Internet, como ejemplo IP, SIP y Diameter, lo que hace inmediata la
adaptación de las numerosas comunidades de desarrollo a estos nuevos entornos
móviles. Asimismo, el éxito de Internet y su increíble desarrollo toma asiento
en la evolución de las Comunicaciones Móviles con el fin de catalizar la creación
de nuevos servicios que expandan el universo de internet desde el equipo de
sobremesa con conexión fija a Internet, hasta prácticamente cualquier lugar,
y en cualquier momento.
Asimismo, la experiencia de los programadores con estos protocolos y lenguajes
origina la aparición de entornos de desarrollo (IDEs) y de simulación como el
Service Development Studio (SDS) del capítulo 3; facilita la aparición de
centros de testeo como el de Octopus Networks (sección 4.2.2) o soluciones
completas comerciales como el Ericsson IMS Laboratory System que se vio en
la sección 4.14 que favorezcan la extensión de las comunidades de desarrollo
y por ende los nuevos servicios y aplicaciones para explotar comercialmente el
subsistema.
La industria de los contenidos, hasta ahora fructífera y universal ha
entrado en una dinámica donde los proveedores tradicionales como pueden
ser las productoras, discográficas y medios de comunicación en general pasan
cada vez más a un segundo plano en detrimento de los contenidos que van
apareciendo con el auge de Internet. Fenómenos como YouTube, MySpace,
productoras y discográficas independientes que “cuelgan” sus contenidos en
Internet — provocando una revolución en la concepción de las licencias sobre
los contenidos que no es objeto principal de este proyecto —. IMS trata de
conciliar los dos nuevos modelos, el tradicional y el moderno basado en Internet
proporcionando mecanismos tecnológicos (como la QoS o la tarificación) y
empresariales (nuevos modelos de negocio), además de construir una nueva
cadena de valor (estudiada en la sección 5.2) donde la industria de los
contenidos tiene cabida. Con la aparición de nuevos modelos de beneficios
por publicidad, nuevas formas de retransmisión y difusión, así como una
expansión universal y una segmentación casi total que fomentan el atractivo
de plataformas como IMS para sectores tan afincados como pueden ser los
medios de comunicación.
Todas estas conclusiones, a priori beneficiosas para el desarrollo de la tecnología,
no explican la falta de despliegue de IMS presente en la actualidad. Por ello, en
los capítulos 4 y 5 se llevó a cabo un análisis más realista de la situación actual
148
de IMS y de su futuro más cercano. Mediante el análisis de las limitaciones de su

principal herramienta de desarrollo, el SDS, se han encontrado diversos motivos clave
para entender el estancamiento en la implantación de nuevos servicios basados en
IMS: la ausencia de características de IMS básicas para el aprovechamiento de sus
ventajas (gestión de QoS y tarificación, implementación de interfaces de AAA, etc.),
la falta de soporte, y la lentitud en la formación de una comunidad lo suficientemente
amplia para abordar desarrollos de envergadura. Todo esto, unido a la falta de
inversión por parte de los operadores, al no encontrar el modelo de explotación de
los servicios IMS. En este sentido, se ha elaborado una propuesta para el despliegue
comercial de un servicio desde la perspectiva tecnológica y comercial, atendiendo las
demandas de todos los actores presentes en la nueva cadena de valor de los servicios
de telecomunicaciones.
Se puede afirmar pues que este Proyecto Fin de Carrera ha cumplido sus objetivos
iniciales, puesto que ha ahondado en detalles técnicos de IMS y a la vez ha
cubierto los tres frentes o perspectivas desde las que se quería abordar la tecnología,
planteando cada cuestión desde un punto de vista cognitivo y a la vez tratando de
respaldar este conocimiento o estado del arte con un enfoque práctico de la mano
de ejemplos y diferentes propuestas.
6.2 Retos futuros

Este proyecto nació con la filosofía de aglutinar las escasas referencias básicas (los
libros [4], [5], y [6] fundamentalmente), junto con los numerosos whitepapers, análisis
y artículos producidos por la industria, los organismos regulatorios y los analistas de
mercados de telecomunicaciones. Con todo, se persiguió elaborar una referencia que
tratara todos estos puntos de vista de la forma más integrada y elocuente posible,
de forma que cualquiera que lo leyera supiera qué es IMS, qué beneficios aporta,
cómo es posible desarrollar un servicio, las limitaciones a las que se enfrenta y las
posibilidades de despliegue de servicio que se advienen en un futuro que se considera
cercano.
Con esta filosofía inicial se aprecia que el proyecto es intrínsecamente abierto, dando
lugar a numerosos puntos de partida para nuevas líneas de trabajo que se extienden
desde las investigaciones en la arquitectura y protocolos de IMS hasta el desarrollo
de nuevos modelos de negocio basados en IMS, pasando por la creación y despliegue
de aplicaciones y servicios para IMS. Algunos de los trabajos futuros que se han
creído más significativos se listan a continuación:
Análisis de los nuevos Communication Services (CoSe), realizando diversos

desarrollos sobre las nuevas versiones del SDS: IPTV, IMS Messaging,
streaming, etc.
Desarrollo de un servicio y exportarlo a las APIs de Parlay X para
posteriormente trasladarlo a un OSA AS real y probar la comunicación y
funcionalidad con el núcleo de red IMS a través del OSA-SCS.
Efectuar el desarrollo y pruebas de servicios de control de tarificación,
149
6.2. RETOS FUTUROS
seguridad y de AAA en general.

Realizar un piloto de control de QoS sobre un servicio existente. Para ello, se
proponen el estudio del protocolo COPS y la utilización de APIs de IMS para
el control y gestión de QoS. Posteriormente integrarlo en un entorno real o
simulado accediendo desde una red de acceso con particularidades de QoS.
Para concluir, se ha creído conveniente ofrecer una valoración más subjetiva sobre
el reto que representa dar una solución a la falta de madurez o estancamiento en el
despliegue de IMS.
En primer lugar, y brevemente, se aprecia que la principal causa de la lentitud en
la implantación de IMS es la ausencia de modelos de negocio claros que legitimen
las fuertes inversiones que requiere la infraestructura de IMS así como el desarrollo
de especificaciones software estándar (APIs, pasarelas, ASs, plataformas de cliente,
etc.).
En segundo lugar, y como colofón a este proyecto, se lanzan algunos retos que
las operadoras de telecomunicación han de afrontar para que IMS prospere y salga
adelante:
Las operadoras han pecado de exceso de confianza con respecto a Internet.
Sin embargo, el espectacular desarrollo de aplicaciones basadas en Web indica
que el mundo móvil ha de adoptar estos nuevos modelos de negocio basados
en publicidad, incentivos al desarrollador, mercados de aplicaciones, etc.
Las tarifas planas son un bien necesario. Con la llegada de terminales cada
vez más potentes, completos y dinámicos el usuario empieza a demandar en
su terminal móvil los mismos servicios que encuentra en Internet, y al mismo
precio. Sin embargo, tecnológica y económicamente, hoy en día las tarifas
planas móviles son inviables. La solución también la aporta IMS: una conexión
permanente y a un precio fijo es capaz de generar beneficios incluyendo valor
añadido. Por ejemplo: Supongamos que un usuario gasta 30 euros al mes por
servicios de voz y SMS. IMS ofrece la posibilidad de ofrecerle a ese usuario
una oferta con un paquete de tarifas planas de navegación web, VoIP nacional,
redes sociales integradas en su versión móvil y streaming de música y video
todo por 20 euros al mes. Pero, por otro lado, el operador, y los proveedores
de servicios y contenidos son capaces de recibir ingresos por el cobro de VoIP
internacional, publicidad en las redes sociales y en los contenidos multimedia,
adquisición de contenidos que se han escuchado o visualizado previamente, y
así un largo etcétera que de sobra rentabilice los 10 euros menos al mes que
de una forma directa dejaba de percibir el operador.
Las operadoras deben especificar la forma en la que se proporcionarán servicios
IMS de terceros en sus redes. A priori podrán alojar servicios en los SIP
ASs de sus dominios. No obstante, este acceso es de prever que se limite a la
propia operadora y a sus partners más fehacientes. Es obvio que esta limitación
condiciona el despegue de la tecnología y la expansión de los servicios. Por ello
se hace indispensable que las operadoras incluyan pasarelas hacia servidores
de terceros y adopten nuevas metodologías centradas en el usuario final como
los web services para ofrecer servicios integrados y de valor añadido al cliente.
150
A. ACRÓNIMOS
3GPP Third Generation Partnership Project

AAA Authentication, Authorization and Accounting
ADSL Asymmetric Digital Subscriber Loop
API Application Programming Interface
ARPU Average Revenue Per User
ARPU Average Revenue Per User
AS Application Server
ATF Automated Testing Framework
B2BUA Back-To-Back-User Agent
B2B-UA Back-To-Back-User Agent
BGCF Breakout Gateway Control Function
BICC Bearer Independent Call Control
BSS/OSS Business and Operations Support Systems
CAMEL Customized Applications for Mobile network Enhanced Logic
CAP CAMEL Application Part
CDC Connected Device Configuration
CGI Common Gateway Interface
CLDC Connected Limited Device Configuration
MIDP Mobile Information Device Profile
COPS Common Open Policy Service
CoSe Communication Services
CS Circuit Switched
CSCF Call Session Control Function
DCCP Datagram Congestion Control Protocol
DHCP Dynamic Host Configuration Protocol
DLL Dynamic Linking Library
DNS Domain Name Server
EMP Ericsson Mobile Platforms
ETSI European Telecommunications Standards Institute
151
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
GSM Global System for Mobile communication
GSMA GSM Association
GSMSCF GSM Service Control Function
GUI Graphical User Interface
HLR Home Location Register
HSPA High Speed Packet Access
HSS Home Subscriber Server
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IBS Internet Based Services
ICE IMS Communication Enablers
ICID IMS Charging IDentifier
ICP IMS Client Platform
IDE Integrated Development Environment
IETF Internet Engineering Task Force
iFC initial Filter Criteria
IJCU IMS JME Client Utility
IMA IMS Multi-Access
IMS IP Multimedia Subsystem
IMScont IMS Service Continuity
INAP Intelligent Network Application Part
IOT InterOperability Testing
IP-CAN IP Connectivity Access Network
IPTV Internet Protocol Television
IPv6 Internet Protocol version 6
IRC Internet Relay Chat
IS Integrated Site
ISC IMS Service Control
ISUP ISDN User Part
IVR Interactive Voice Response
J2EE Java 2 Platform Enterprise Edition
J2ME Java 2 Micro Edition
152
JCP Java Community Process

JDK Java Development Kit
JEE Java Enterprise Edition
JSF JavaServer Faces
JSP JavaScript Pages
JSR Java Specification Request
LIR Location Info Request
MEGACO MEdia GAteway COntrol
MGCF Media Gateway Control Function
MGW Media GateWay
MIME Multipurpose Internet Mail Extension
MMSC Multimedia Session Continuity
MRF Media Resource Function
MRFC Media Resource Function Controller
MRFP Media Resource Function Processor
MSRP Message Session Relay Protocol
MTP Message Transfer Part
NAI Network Access Identifier
NGN Next Generation Networking
NNI Network to Network Interface
OCCAS Oracle Communications Converged Application Server
OMA Open Mobile Alliance
OPA Open Platform Architecture
OSA Open Service Access/Architecture
OSA-SCS Open Service Access-Service Capability Server
P2P Peer-to-Peer
PCM Pulse Code Modulation
PDF Policy Decision Function
PDP Policy Decision Point
PEP Policy Enforcement Point
PeP Presence Enhanced Phonebook
PGM Presence and Group Management
PLMN Public Land Mobile Network
PoC Push-To-Talk over Cellular
153
PS Packet Switched
PSI Public Service Identity
PSTN Public Switched Telephone Network
PTT Push-To-Talk
PyME Pequeña y Mediana Empresa
QoS Quality of Service
RDSI Red Digital de Servicios Integrados
RFC Request For Comments
RSVP Resource ReSerVation Protocol
RTCP RTP Control Protocol
RTP Real-time Transport Protocol
SBC Session Border Controller
SDK Software Development Kit
SDP Session Description Protocol
SDS Service Development Studio
SEMC Sony Ericsson Mobile Communications
SIP Session Initiation Protocol
SLF Subscription Locator Function
SMS Short Message Service
SMTP Simple Mail Transfer Protocol
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SS7 Signaling System 7
SSA SIP Servlet API
TCP Transmission Control Protocol
TISPAN Telecoms and Internet converged Services and Protocols for Advanced
Networks
TS Technical Specification
TTM Time To Market
UAC User Agent Client
UDP User Datagram Protocol
UE User Equipment
UMTS Universal Mobile Telecommunications System
UNI User to Network Interface
URI Uniform Resource Identifier
154
VCC Voice Call Continuity

VoD Video on Demand
VoIP Voice over Internet Protocol
VPN Virtual Private Network
VTF Visual Traffic Flow
WAP Wireless Application Protocol
WCDMA Wideband Code Division Multiple Access
WLAN Wireless Local Area Network
WSDL Web Services Description Language
WTK Wireless ToolKit
WTP Web Tools Platform
XML eXtensible Markup Language
155
B. ERICSSON IMS COMMON

SYSTEM 4.1
ICS (IMS Common System) sirve como base para todas las ofertas que realiza
Ericsson en materia de núcleo de red de IMS. Además asegura la adopción
de un modelo de negocio que posibilite servicios horizontales ofrecido por IMS
incluyendo convergencia fijo-móvil y soporte para múltiples aplicaciones. ICS ha
sido diseñado para atender a aspectos de red de servicios coexistentes, servicios no
sólo desarrollados en la gama de Ericsson sino otras aplicaciones o funciones bajo
IMS (IP Multimedia Susbystem), integradas y unidas con ICS a través de interfaces
externas. De esta manera el ICS sirve como base sobre la cual varios servicios pueden
ser construidos. Ericsson IMS Push To Talk Permite a operadores lanzar “push to
talk” servicios sobre redes de móviles estándar como GSM/GPRS/EDGE/WCDMA
y CDMA2000. Cumple con la especificación Push To Talk over Cellular (PoC). La
solución está basada en una “siempre disponible” tipo de conexión de datos corriendo
sobre IP.
Nodos IMS en un contexto de red Un nodo lógico representa una o más funciones
relacionadas en una solución IMS. Un nodo lógico es implementado en uno, o más,
Elementos de Red. Un Elemento de Red puede implementar uno o más nodos lógicos.
La configuración actual para una solución IMS es determinada durante el proceso de
dimensionado teniendo en cuenta el número de aplicaciones, el volumen de tráfico,
y otro parámetros a tener en cuenta. En la versión 4.1 del IMS Common System
los nodos lógicos están realizados en los Elementos de Red mostrados en la tabla
siguiente (CSCF (Call Session Control Function) 4.1, HSS (Home Suscriber Server)
4.1, PGM (Presence Group and Management) 4.1, etc). Hay que tener en cuenta
que sólo hace referencia a la parte software de los Elementos de Red. El Hardware
y las plataformas no están cubiertos en la oferta de Ericsson. Descripción de los
nodos lógicos del ICS ICS está compuesto de varios nodos lógicos. Algunos de estos
son obligatorios, tienen que estar incluidos en cualquier despliegue del sistema ICS.
Otros nodos lógicos son opcionales y pueden estar incluidos dependiendo de las
necesidades del cliente y del entorno actual en el que el sistema ICS será desplegado.
Nodos obligatorios:
CSCF.
HSS.
EMA (Ericsson Multi Activation Server).
DNS / ENUM (Domain Name Service / E.164 Number Maping).
CSCF - Call Session Control Function Es un nodo esencial en IMS para el
procesamiento de la señalización, usando SIP (Session Initialization Protocol) como
157
protocolo de señalización. Proporciona soporte para protocolos de Internet en una
plataforma escalable. Analicemos la estructura lógica de CSCF:
El componente Application Support proporciona comunicación entre procesos
a través de tratamiento, configuración de mantenimiento, de red y soporte
de protocolo de transporte, y otras funciones “middleware” (software de
conectividad que ofrece un conjunto de servicios que hacen posible el
funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas.
El componente Operations and Management (OM) proporciona operaciones
y mantenimiento. Todos los componentes contenidos dentro de la actual
aplicación CSCF interactúan con el componente OM.
La pila SIP maneja mensajes SIP enviándolos y recibiéndolos, construyéndolos
y analizándolos, en las interfaces de red proporcionadas por el componente
Application Support.
La pila Diameter maneja mensajes Diameter enviándolos y rebiciéndolos,
construyéndolos y analizándolos, en las interfaces de red proporcionadas por
el componente Application Support. Diameter es también usado para enviar
datos de tarificación.
Event Manager ofrece informes sobre eventos de sesiones SIP específicas y usa
Diameter para comunicarse con el HSS.
Service Innvocation es responsable de invocar servicios que puedan ser
ejecutados en un servidor de aplicaciones SIP externo. La invocación está
basada en los filtros de los mensajes SIP específicos de usuarios finales.
ISC (IMS Service Control) es usado para comunicación con un servidor de
aplicaciones SIP externo. Este componente, que está basado en SIP, es usado
por Service Invocation cuando el soporte ISC esté configurado.
P-CSCF - Proxy Call Session Control Function Es el primer punto de contacto
(en el plano de señalización) entre el terminal de usuario y la red IMS, ya sea
directamente (redes móviles) o via SBC (Session Border Controller) (redes fijas).
Reenvía los mensajes SIP recibidos desde un UE (User Equipment) a un I-CSCF o
a un S-CSCF. Proporciona las siguientes funcionalidades:
Reenvía la petición de registro SIP recibida desde un UE a un I-CSCF
determinado usando el dominio proporcionado en el primer campo de la
cabecera Ruta o del Request-URI.
Almacena direcciones de contacto del equipo de usuario, como parte del
proceso de registro.
Todas las peticiones iniciadas en el terminal o destinadas a él atraviesan el
P-CSCF. Tanto las peticiones como las respuestas a estas son reenviadas por
esta funcionalidad en la dirección apropiada. La dirección de este nodo es
descubierta por el terminal durante la activación de un contexto PDP para el
cambio de mensajes de señalización. El nodo P-CSCF obtiene el nodo S-CSCF
adecuado durante el proceso de registro del terminal.
Oculta la topología de la red.
158
Actúa como manejador de Lawful Intercept (LI).

Supervisa sesiones en curso.
Realiza compresión de mensajes SIP (usando SigComp).
Hace cumplir una política de red determinada.
Carga normas para peticiones fuera de un diálogo.
Limita agentes de usuario - puede bloquear equipos de usuarios para un tipo
de uso del sistema ICS.
Lleva a cabo la autorización de medios durante el proceso de negociación SIP.
Lleva a cabo la priorización de llamadas de emergencia.
I-CSCF - Interrogating Call Session Control Function Es el punto de contacto dentro
de una red de un operador para todas las conexiones destinadas a un usuario de ese
operador de red. Oculta la topología interior de la red propia para otras redes y
localiza el S-CSCF donde un usuario está localizado a través de una interacción
con el HSS. Muchos I-CSCF pueden existir actualmente un la red de un operador.
Proporciona las siguientes habilidades:
Punto de entrada a la red para peticiones y respuestas de registro SIP.
Asignación dinámica de un S-CSCF a un usuario al llevar a cabo el registro
SIP.
Reenvío de respuesta a peticiones SIP realizadas por otra red a través del
S-CSCF.
Reenvío de peticiones SIP REGISTER al S-CSCF basándose en el resultado
de la cuestión de autorización al HSS.
Reenvío de la respuesta de una petición SIP REGISTER inicial a el P-CSCF
basado en el contenido de la cabecera “vía”.
Terminación del sub-dominio de asignación de ruta PSI (tabla interna a
consultar cuando no se obtiene respuesta del HSS).
S-CSCF -Serving Call Session Control Function Lleva a cabo el registro y el control
de sesión de los servicios hasta el punto final. Incluye la asignación de ruta de
peticiones originadas que terminan en la red y de peticiones terminales que van
hacia el P-CSCF. Soporta establecimiento, modificación y liberación de sesiones IP
multimedia usando la combinación de protocolos SIP/ SDP (Session Description
Protocol). S-CSCF también decide si un servidor de aplicaciones es necesario para
recibir información relacionada con una petición SIP entrante exterior a un diálogo
para asegurar un manejo adecuado del servicio. La decisión en este nodo está basada
en información de disparo recibida del HSS como initial filter criteria (criterios
iniciales de filtrado). La información de disparo puede proporcionar invocación a
servicios indirectos a través de interfaces ISC hacia la capa de aplicaciones. S-CSCF
proporciona las siguientes funcionalidades:
Registro de abonado. S-CSCF actúa como regitrador y acepta peticiones
REGISTER y hace la información de registro disponible a través de un servidor
localizado (en este caso HSS). La información estática es descargada desde el
159
perfil de usuario del HSS al S-CSCF y la almacena durante el tiempo de vida
del registro. El HSS notifica al S-CSCF si el perfil de usuario ha sido modificado
durante el registro.
Invocación de sesiones multimedia. Soporta mecanismos SIP para establec-
imiento de diálogos (para invocar una o más sesiones multimedia).
Lleva a cabo la internacionalización de números locales a globales (para
números E.164).
Resolución de asignación de rutas de peticiones en las cuales el destino es
definido con un número de teléfono.
Modificación y terminación de diálogos.
Bifurcación de sesiones multimedia.
Disparos a servicios de red basados en invocaciones de eventos de sesiones
multimedia (por ejemplo invocación de servicio de presencia).
Resolver la dirección del servidor I-CSCF del abonado destino a través de
búsqueda con DNS, entonces reenviar las peticiones o respuestas a dicho I-
CSCF.
Encaminamiento de sesiones. Reenviar mensajes SIP a servidores SIP o a
MGCF (Media Gateway Controller Function) para salidas a redes fijas o a
servidores SIP que interaccionen con redes de telefonía IP.
HSS - Home Subscription Server Es la base de datos maestra que contiene
información de usuarios y abonados, y mantiene el rastro después del registro con
el S-CSCF que es asignado a cada usuario. Contiene los datos de usuario que son
descargados al S-CSCF en el registro. Funcionalidades:
Identificación: mantiene la relación apropiada entre la identidad privada que
identifica al usuario y la identidad pública usada para establecer llamadas.
Autenticación.
Autorización de acceso: decide si al usuario le está permitido registrarse en la
red.
Localización del S-CSCF que tiene asignado un usuario.
Soporta información de servicio (initial filter criteria).
MGC - Media Gateway Controller Para entregar llamadas de voz a/desde redes
de conmutación de circuitos. Proporciona inter-funcionamiento entre la señalización
SIP de control de sesión y la señalización ISUP (ISDN User Part) de la red externa
a IMS. Es el responsable de la terminación de la señalización de control de llamada
ISUP y de controlar la pasarela de medios necesaria para establecer conexiones a
nivel de medios entre la red de conmutación de circuitos y los flujos de la red de
conmutación de paquetes.
MGW - Media Gateway Está localizada desde el punto de vista de la arquitectura
en la capa de conectividad y es responsable de manejar el flujo de medios recibido
de la red de conmutación de circuitos. Su tarea es adaptar el flujo transportado en
los circuitos a paquetes IP, apropiados para transportar sobre una red IP.
160
PGM - Presencia El producto PGM es un habilitador para aplicaciones y servicios

IMS. Proporciona la posibilidad de almacenar y mantener información relacionada
con la presencia en un servidor encargado de ello. Este producto incluye también la
funcionalidad de mantenimiento de grupo y datos (G and DM) acorde con el estándar
definido en OMA Presence and Availability Working Group (PAG). Un observador
puede suscribir o traer la información de presencia de uno o varios Presentities a un
servidor de presencia. La información de presencia puede cualquier ser actualizada
por el propio Presentities o por otra fuente de presencia de confianza en nombre de
dicho Presentity. Mantenimiento de grupos y datos proporciona la posibilidad a un
cliente XCAP (XML Configuration Access Protocol) de mantener documentos XML.
Compartidos en XDMS (XML Document Management Server) es esperado que sean
usados por diferentes aplicaciones. La opción de Presencia Básica proporciona los
componentes funcionales para la Presencia básica relacionada con los casos de uso
especificados en el estándar soportado.
DNS / ENUM DNS se utiliza para resolver los nombres de los nodos IMS en una
dirección IP proporcionando redundancia de nodos cuando sea necesaria, resolución
ENUM desde números E.164 a operadores. IPWorks es utilizado para peticiones a
DNS y ENUM por todos los nodos de la red y servidores de aplicaciones. Añade
características adicionales al servicio que proporciona DNS.
161
C. CÓDIGOS DEL SERVICIO DE

EJEMPLO
C.1 Servlet de la aplicación: Servlet.java

1 package com.ericsson;
2
3 import java.io.IOException;
4 import java.util.Random;
5
6 import javax.servlet.ServletException;
7 import javax.servlet.sip.SipServlet;
8 import javax.servlet.sip.SipServletRequest;
9 import javax.servlet.sip.SipServletResponse;
10 import javax.servlet.sip.SipSession;
11
12 public class Servlet extends SipServlet

13 {
14 /**
15 * Generador de un número aleatorio
16 */
17 private Random random = new Random();
18
19 /**
20 * Indica si se recibió el ACK de la sesión
21 */
22 private final String ACK_RECEIVED = "ackReceived";
23 /**
24 * Atributo de la sesión donde se almacena el número a adivinar
25 */
26 private final String NUMBER_TO_GUESS = "number";
27 /**
28 * La sesión se acepta - genera número a adivinar
29 */
30 protected void doAck(SipServletRequest req) throws ServletException,
IOException
31 {
32 SipSession session = req.getSession(true);
33 // Ensure we do not process the ACK twice for the dialog
34 Object ackAlreadyProcessed = session.getAttribute(ACK_RECEIVED);
35 if (ackAlreadyProcessed == null)
36 {
163
C.1. SERVLET DE LA APLICACIÓN: SERVLET.JAVA
37 session.setAttribute(ACK_RECEIVED, true);
38 // proporciona un valor entre 0 (inclusive) y 11 (exclusive)
por lo que [0, 10]
39 session.setAttribute(NUMBER_TO_GUESS, random.nextInt(11));
40 SipServletRequest message = session.createRequest("MESSAGE");
41 message.setContent("Adivine un número entre 0 y 10".getBytes(),
"guess/start");
42 message.send();
43 }
44 }
45
46 /**
47 * Termina la sesión
48 */
49 protected void doBye(SipServletRequest req) throws ServletException,
IOException
50 {
51 req.getSession().invalidate();
52 }
53
54 /**
55 * Invitación recibida - aceptarla
56 */
57 protected void doInvite(SipServletRequest req) throws ServletException
, IOException
58 {
59 // acepta la invitación - envía 200 OK
60 SipServletResponse response = req.createResponse(200);
61 response.send();
62 }
63
64 /**
65 * Número recibido. Comprueba si el número coincide con el generado
por el sistema
66 * y envía el mensaje apropiado
67 */
68 protected void doMessage(SipServletRequest req) throws
ServletException, IOException
69 {
70 SipSession session = req.getSession(true);
71 Object numberObject = session.getAttribute(NUMBER_TO_GUESS);
72 // Se asegura que todo va bien
73 if(numberObject == null)
74 {
75 req.createResponse(400, "Sesión no establecida").send();
76 }
77 else
78 {
79 // Responde 200 OK
164
80 req.createResponse(200).send();
81
82 // Obtiene el número adivinado

83 String content = new String(req.getRawContent());
84 int guess = Integer.parseInt(content);
85 int number = (Integer)numberObject;
86
87 // Crea el mensaje que mandaremos al cliente

88 SipServletRequest message = session.createRequest("MESSAGE");
89
90 // Si se acierta
91 boolean gameOver = false;
92 if(guess == number)
93 {
94 message.setContent("Ha acertado!".getBytes(), "guess/result
+good");
95 gameOver = true;
96 }
97 else
98 {
99 // De lo contrario el usuario tendrá que seguir adivinando
100 String smaller = "Incorrecto, el número es... " + (guess<
number?"mayor":"menor");
101 message.setContent(smaller.getBytes(), "guess/result+wrong"
);
102 }
103 // Envía el resultado
104 message.send();
105
106 // Cierra la sesión si el usuario no acierta

107 if(gameOver)
108 {
109 session.createRequest("BYE").send();
110 session.invalidate();
111 }
112 }
113 }
114 }
Listado C.1: Servlet de la aplicación.
C.2 Cliente de la aplicación: Cliente.java

1 package com.ericsson;
2
3 import java.awt.BorderLayout;
4 import java.awt.Button;
5 import java.awt.FlowLayout;
165
C.2. CLIENTE DE LA APLICACIÓN: CLIENTE.JAVA
6 import java.awt.Font;
7 import java.awt.Frame;
8 import java.awt.Panel;
9 import java.awt.TextArea;
10 import java.awt.event.ActionEvent;
11 import java.awt.event.ActionListener;
12 import java.awt.event.WindowAdapter;
13 import java.awt.event.WindowEvent;
14
15 import com.ericsson.icp.IBase;
16 import com.ericsson.icp.ICPFactory;
17 import com.ericsson.icp.IPlatform;
18 import com.ericsson.icp.IProfile;
19 import com.ericsson.icp.IService;
20 import com.ericsson.icp.ISession;
21 import com.ericsson.icp.util.ErrorReason;
22 import com.ericsson.icp.util.SdpFactory;
23
24 public class Cliente extends Frame

25 {
26
27 private IPlatform platform;

28 private IProfile profile;
29 /**
30 * Referencia al servicio ICP para manipular mensajes en modo búsqueda
31
32 */
33 private IService service;
34 /**
35 * La sesión del juego actual
36 */
37 private ISession session;
38
39 private Button startGameButton;

40
41 /**
42 * Main
43 */
44 public static void main(String[] args)
45 {
46 Cliente guess = new Cliente();
47 guess.setVisible(true);
48 }
49
50 public Cliente()
51 {
52 setFont(new Font("SansSerif", Font.PLAIN, 12));
53 // Crea la interfaz de usuario
54 createGui();
166
55 try
56 {
57 // Crea la plataforma y servicio ICP
58 platform = ICPFactory.createPlatform();
59 platform.registerClient("GuessClient");
60 platform.addListener(new PlatformAdapter());
61
62 // Conecta al perfil usado en la aplicación

63 profile = platform.createProfile("ImsSetting");
64 profile.addListener(new ProfileAdapter());
65
66 // Crea el servicio ICP. Se usará para crear una sesión en el

67 // método startGame()
68 service = profile.createService("+g.cliente.ericsson.com", "
cliente.ericsson.com");
69 service.addListener(new ServiceAdapter());
70 }
71 catch (Exception e)
72 {
73 showError("No se ha podido arrancar la ICP", e);
74 }
75 }
76
77 /**
78 * Crea la GUI
79 */
80 private void createGui()
81 {
82 // Set the application title and size
83 // Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize
();
84 // setSize(new Dimension(screenSize.width / 2, screenSize.height /
2));
85 setTitle("Cliente ¡Adivine un número!");
86 setLayout(new BorderLayout());
87
88 Panel buttonPanel = new Panel();

89 buttonPanel.setLayout(new FlowLayout());
90 // Botones
91 startGameButton = new Button("Nuevo Juego");
92 startGameButton.addActionListener(new ActionListener()
93 {
94
95 public void actionPerformed(ActionEvent event)

96 {
97 startGame();
98 }
99 });
100 buttonPanel.add(startGameButton);
167
101 Button quit = new Button("Salir");

102 quit.addActionListener(new ActionListener()
103 {
104 public void actionPerformed(ActionEvent event)
105 {
106 quit();
107 }
108 });
109
110 // Cierra la aplicación cuando se cierra la ventana

111 this.addWindowListener(new WindowAdapter()
112 {
113 public void windowClosing(WindowEvent event)
114 {
115 quit();
116 }
117 });
118 buttonPanel.add(quit);
119
120 // crea la etiqueta de explicación

121 TextArea explanationText = new TextArea();
122 explanationText.setEditable(false);
123 explanationText.setRows(8);
124 explanationText
125 .setText("El objetivo de este juego es adivinar \n un
número aleatorio generado \npor el servidor.\nPara
comenzar el juego,\npresione el botón.\nSi desea salir,
pulse ’Salir’");
126 add(explanationText, BorderLayout.SOUTH);
127 add(buttonPanel, BorderLayout.NORTH);
128
129 pack();
130 }
131
132 /**
133 * Libera el objeto ICP cuando se cierra la aplicación y para la
máquina virtual
134
135 */
136 private void quit()
137 {
138 release(session);
139 release(service);
140 release(platform);
141 setVisible(false);
142 dispose();
143 System.exit(0);
144 }
145
168
146 /**
147 * Libera un objeto ICP
148 *
149 * @param object El objeto a liberar
150 */
151 private void release(IBase object)
152 {
153 if(object != null)
154 {
155 try
156 {
157 object.release();
158 }
160 {
161
162 }
163 }
164 }
165
166 /**
167 * Finaliza el juego actual.
168 */
169 private void endGame()
170 {
171 try
172 {
173 session.end();
174 startGameButton.setEnabled(true);
175 }
177 {
178 showError("Imposible terminar la sesión", e);
179 }
180 }
181
182 /**
183 * Empieza un juego nuevo. esto creará una sesión ICP que se usará
para intercambiar mensajes entre el cliente ICP y el servlet SIP
184 */
185 private void startGame()
186 {
187 try
188 {
189 // Crea la sesión y añade su listener sobre ella
190 session = service.createSession();
191 session.addListener(new SessionAdapter()
192 {
169
193 public void processSessionStartFailed(ErrorReason aError,

long retryAfter)
194 {
195 GuessClient.this.showError("Could not start session",
new Exception(aError.getReasonString()));
196 }
197
198 public void processError(ErrorReason aError)

199 {
200 GuessClient.this.showError("Session Error", new
Exception(aError.getReasonString()));
201 }
202
203 public void processSessionMessage(String aContentType, byte

[] aMessage, int aLength)
204 {
205 // se recibió un MESSAGE, que se procesa...
206 super.processSessionMessage(aContentType, aMessage,
aLength);
207 String message = new String(aMessage);
208 // envía el nuevo intento si no acertó
209 if(aContentType.indexOf("result+good") == -1)
210 {
211 // Abre "Dialogo" para el número
212 GuessNumberDialog dialog = new GuessNumberDialog(
GuessClient.this);
213 dialog.setMessageLabel(message);
214 dialog.setVisible(true);
215
216 // Si no se escribe nada termina

217 String input = dialog.getContent();
218 if((input == null || input.trim().length() == 0))
219 {
220 endGame();
221 return;
222 }
223 // Envía lo que escribió el usuario como parte de un
mensaje MESSAGE
224 byte[] sendingContent = input.getBytes();
225 try
226 {
227 session.sendMessage("guess/try", sendingContent,
sendingContent.length);
228 }
230 {
231 showError("No se pudo enviar el mensaje", e);
232
233 }
170
234 }
235 else
236 {
237 // Número acertado, mostrar el "MensajeDialog" de
felicitiaciones
238 final MessageDialog winDialog = new MessageDialog(
GuessClient.this, "Has ganado!", "Acertaste el
número correcto!");
239 winDialog.setVisible(true);
240 startGameButton.setEnabled(true);
241 }
242 }
243 });
244
245 // Empieza el juego

246 session.start("sip:[email protected]", null, profile.
getIdentity(), SdpFactory.createMIMEContainer());
247 startGameButton.setEnabled(false);
248 }
250 {
251 showError("No se pudo crear la sesión", e);
252 }
253 }
254
255 /**
256 * Muestra diálogo de error.
257 *
258 * @param message
259 * @param e
260 */
261 private void showError(String message, Exception e)
262 {
263 String exceptionMessage = e.getMessage();
264 if(exceptionMessage.length() == 0)
265 {
266 exceptionMessage = e.toString();
267 }
268 MessageDialog errorDialog = new MessageDialog(this, "ICP Error",
message + "\r\n\r\n: " + exceptionMessage);
269 errorDialog.setVisible(true);
270 }
271 }
Listado C.2: El cliente de la aplicación.
171
C.3. CUADROS DE DIÁLOGO
C.3 Cuadros de diálogo

C.3.1 Diálogo principal: Dialogo.java
1 package com.ericsson.sds.samples.guess;
2
4 import java.awt.Dialog;
5 import java.awt.Dimension;
7 import java.awt.GridLayout;
8 import java.awt.Label;
9 import java.awt.TextField;
14
15 /**
16 * Dialog class to ask the user for a number
17 */
18 class GuessNumberDialog extends Dialog
19 {
20 /**
21 *
22 */
23 private static final long serialVersionUID = -7522292705252076615L;
24 private Label messageLabel;
25 private String content;
26
27 public GuessNumberDialog(Frame owner)

28 {
29 super(owner, "¡Adivine un número!", true);
30 init();
31 }
32 /**
33 * Initialize the dialog GUI. This GUI is pretty simple,
34 * it has a label and a text field to enter the number.
35 *
36 */
37 private void init()
38 {
39 setLayout(new GridLayout(3, 1));
40 messageLabel = new Label();
41 final TextField textField = new TextField();
42 ActionListener closeActionListrener = new ActionListener()
43 {
44 public void actionPerformed(ActionEvent e)
45 {
172
46 content = textField.getText();
47 setVisible(false);
48 }
49 };
50 textField.addActionListener(closeActionListrener);
51 Button okButton = new Button("OK");
52 okButton.addActionListener(closeActionListrener);
53 add(messageLabel);
54 add(textField);
55 add(okButton);
56 this.setSize(new Dimension(250, 100));
57 this.addWindowListener(new WindowAdapter()
58 {
59 public void windowClosing(WindowEvent arg0)
60 {
61 GuessNumberDialog.this.setVisible(false);
62 }
63 });
64 }
65
66 /**
67 * Get the content typed by the user
68 */
69 public String getContent()
70 {
71 return content;
72 }
73
74 /**
75 * Set the message to display
76 */
77 public void setMessageLabel(String message)
78 {
79 messageLabel.setText(message);
80 }
81 }
Listado C.3: El cuadro de diálogo principal.
C.3.2 DialogoMensajes.java
2
4 import java.awt.Dialog;
6 import java.awt.GridBagConstraints;
7 import java.awt.GridBagLayout;
173
C.3. CUADROS DE DIÁLOGO
8 import java.awt.Insets;
9 import java.awt.Label;
14
15 class MessageDialog extends Dialog

16 {
17 /**
18 *
19 */
20 private static final long serialVersionUID = 3331590581131014830L;
21
22 /**
23 * Dialog displayed when the use has guessed correctly
24 */
25 public MessageDialog(Frame parent, String title, String message)
26 {
27 super(parent, title, true);
28 setLayout(new GridBagLayout());
29 Button ok = new Button("OK");
30 ok.addActionListener(new ActionListener()
31 {
32 public void actionPerformed(ActionEvent e)
33 {
34 MessageDialog.this.setVisible(false);
35 }
36 });
37 Label messageLabel = new Label();
38 messageLabel.setText(message);
39 GridBagConstraints constrains = new GridBagConstraints();
40 constrains.gridx = 0;
41 constrains.gridy = 0;
42 constrains.weightx = 1;
43 constrains.insets = new Insets(5, 5, 5, 5);
44 constrains.fill = GridBagConstraints.HORIZONTAL;
45 add(messageLabel, constrains);
46 constrains = new GridBagConstraints();
47 constrains.gridx = 0;
48 constrains.gridy = 1;
49 constrains.anchor = GridBagConstraints.CENTER;
50 add(ok, constrains);
51 addWindowListener(new WindowAdapter()
52 {
53 public void windowClosing(WindowEvent e)
54 {
55 MessageDialog.this.setVisible(false);
56 }
174
57 });
58 pack();
59 }
60
61 }
Listado C.4: El cuadro de diálogo de mensaje de éxito.
C.4 Adaptadores de la ICP

C.4.1 PlatformAdapter.java
2
3 import com.ericsson.icp.IPlatformListener;
5
6 public class PlatformAdapter implements IPlatformListener

7 {
8 public void processPlatformTerminated(ErrorReason aReasonCode)
9 {
10 }
11

13 {
14 }
15
16 public void processApplicationData(String aApplication, byte[] aData,

int aLength)
17 {
18 }
19
20 public void processIncomingProfile(String aProfileName)

21 {
22 }
23 }
Listado C.5: Adaptador de la plataforma.
C.4.2 ProfileAdapter.java
2
3 import com.ericsson.icp.IProfileListener;
4 import com.ericsson.icp.IProfile.State;
175
C.4. ADAPTADORES DE LA ICP
7 public class ProfileAdapter implements IProfileListener

8 {
9
10 public void processApplicationData(String aApplication, byte[] aData,

int aLength)
11 {
12 }
13
14 public void processEvent(String aEvent, String aSource, ErrorReason

aReasonCode)
15 {
16 }
17
18 public void processStateChanged(State aState)

19 {
20 }
21

23 {
24 }
25 }
Listado C.6: Adaptador del perfil de la plataforma.
C.4.3 ServiceAdapter.java
2
3 import com.ericsson.icp.IServiceListener;
4 import com.ericsson.icp.ISession;
6
7 public class ServiceAdapter implements IServiceListener

8 {
9
10 public void processIncomingSession(ISession aSession)

11 {
12 }
13
14 public void processMessage(String arg0, String arg1, byte[] arg2, int

arg3, String arg4)
15 {
16 }
17
18 public void processMessage(String aRemote, String aMsgType, byte[]

aMessage, int aLength)
19 {
176
20 }
21
22 public void processOptions(String aPreferedContact, String aRemote,

String aType, byte[] aContent, int aLength)
23 {
24 }
25
26 public void processPublishResult(boolean aStatus, String aRemote,

String aEvent, long retryAfter)
27 {
28 }
29
30 public void processRefer(String aReferID, String aRemote, String

aThirdParty, String aContentType, byte[] aContent, int aLength)
31 {
32 }
33
34 public void processReferEnded(String aReferID)

35 {
36 }
37
38 public void processReferNotification(String aReferId, int aState)

39 {
40 }
41
42 public void processReferNotifyResult(boolean status, String aReferID,

long retryAfter)
43 {
44 }
45
46 public void processReferResult(boolean aStatus, String aReferId, long

retryAfter)
47 {
48 }
49
50 public void processSendMessageResult(boolean aStatus, long retryAfter)

51 {
52 }
53
54 public void processSendOptionsResult(boolean aStatus, String

aPreferedContact, String aRemote, String aType, byte[] aContent,
int aLength, long retryAfter)
55 {
56 }
57
58 public void processSubscribeEnded(String aPreferedContact, String

aRemote, String aEvent)
59 {
60 }
177
61
62 public void processSubscribeNotification(String aRemote, String

aContact, String aEvent, String aType, byte[] aContent, int aLength
)
63 {
64 }
65
66 public void processSubscribeResult(boolean aStatus, String aRemote,

67 {
68 }
69
70 public void processUnsubscribeResult(boolean aStatus, String aRemote,

71 {
72 }
73

75 {
76 }
77 }
Listado C.7: Adaptador de servicio.
C.4.4 SessionAdapter.java
2
3 import com.ericsson.icp.ISessionListener;
5 import com.ericsson.icp.util.ISessionDescription;
6 import com.ericsson.icp.util.MIMEContainer;
7
8 public class SessionAdapter implements ISessionListener

9 {
10
11 public void processSessionAlerting()

12 {
13 }
14
15 public void processSessionCancelled()

16 {
17 }
18
19 public void processSessionEnded()

20 {
21 }
22
178
23 public void processSessionInformation(String arg0, byte[] arg1, int

arg2)
24 {
25 }
26
27 public void processSessionInformationFailed(ErrorReason arg0, long

arg1)
28 {
29 }
30
31 public void processSessionInformationSuccessful(String arg0, byte[]

arg1, int arg2)
32 {
33 }
34
35 public void processSessionInvitation(String arg0, boolean arg1,

ISessionDescription arg2, MIMEContainer arg3)
36 {
37 }
38
39 public void processSessionMediaNegotiation(ISessionDescription arg0)

40 {
41 }
42
43 public void processSessionMessage(String arg0, byte[] arg1, int arg2)

44 {
45 }
46
47 public void processSessionMessage(String arg0, byte[] arg1, int arg2,

String arg3)
48 {
49 }
50
51 public void processSessionMessageFailed(ErrorReason arg0, long arg1)

52 {
53 }
54
55 public void processSessionMessageSuccessful(String arg0, byte[] arg1,

int arg2)
56 {
57 }
58
59 public void processSessionOptions(String arg0, ISessionDescription

arg1)
60 {
61 }
62
63 public void processSessionOptionsFailed(ErrorReason arg0, long arg1)

64 {
179
65 }
66
67 public void processSessionOptionsSuccessful(String arg0,

ISessionDescription arg1)
68 {
69 }
70
71 public void processSessionPublishFailed(String arg0, byte[] arg1, int

arg2, ErrorReason arg3, long arg4)
72 {
73 }
74
75 public void processSessionPublishSuccessful(String arg0, int arg1,

byte[] arg2, int arg3)
76 {
77 }
78
79 public void processSessionReceivedPRACK(ISessionDescription arg0)

80 {
81 }
82
83 public void processSessionReceivedPRACKResponse(ISessionDescription

arg0)
84 {
85 }
86
87 public void processSessionRefer(String arg0, String arg1, byte[] arg2,

int arg3)
88 {
89 }
90
91 public void processSessionReferEnded(String arg0)

92 {
93 }
94
95 public void processSessionReferFailed(String arg0, ErrorReason arg1,

long arg2)
96 {
97 }
98
99 public void processSessionReferNotify(String arg0, int arg1, String

arg2)
100 {
101 }
102
103 public void processSessionReferNotifyFailed(String arg0, ErrorReason

arg1, long arg2)
104 {
105 }
180
106
107 public void processSessionReferNotifySuccessful(String arg0)

108 {
109 }
110
111 public void processSessionReferSuccessful(String arg0)

112 {
113 }
114
115 public void processSessionStartFailed(ErrorReason arg0, long arg1)

116 {
117 }
118
119 public void processSessionStarted(ISessionDescription arg0)

120 {
121 }
122
123 public void processSessionSubscribeDeactived(String arg0, String arg1,

byte[] arg2, int arg3)
124 {
125 }
126
127 public void processSessionSubscribeFailed(String arg0, String arg1,

byte[] arg2, int arg3, ErrorReason arg4, long arg5)
128 {
129 }
130
131 public void processSessionSubscribeNotification(String arg0, String

arg1, byte[] arg2, int arg3)
132 {
133 }
134
135 public void processSessionSubscribeSuccessful(String arg0, String arg1

, byte[] arg2, int arg3)
136 {
137 }
138
139 public void processSessionUpdate(ISessionDescription arg0)

140 {
141 }
142
143 public void processSessionUpdateFailed(ErrorReason arg0, long arg1)

144 {
145 }
146
147 public void processSessionUpdateSuccessful(ISessionDescription arg0)

148 {
149 }
150
181
151 public void processError(ErrorReason arg0)

152 {
153 }
154
155 }
Listado C.8: Adaptador de sesión.
182
BIBLIOGRAFÍA
[1] Europe Surpasses North America In Instant Messenger Users, comScore Study
Reveals. Available from: http://www.comscore.com/press/release.asp?
press=800.
[2] Social Network User demographics [online]. Available
from: http://social-media-optimization.com/2008/05/
social-network-user-demographics/.
[3] 3GPP. IMS specifications [online]. Available from: http://www.3gpp.org/
article/ims.
[4] Gonzalo Camarillo and Miguel A. García Martín. The 3G IP Multimedia
Subsystem (IMS): Merging the Internet and the cellular worlds. John Wiley
and Sons Ltd. 2 ed., 2006.
[5] Hisham Khartabil Aki Niemi Miika Poikselka, George Mayer. The IMS, IP
Multimedia Concepts and Services in the Mobile Domain. John Wiley and
Sons Ltd. 2 ed., 2004.
[6] Travis Russell. The IP Multimedia Subsystem (IMS). Session Control and Other
Network Operations. McGraw-Hill Communications, 2008.
[7] Universidad Rey Juan Carlos Grupo de Señales y Comunicaciones. Evolución
de redes 3G: IMS. Transparencias de Transmisión de Datos, mayo 2007.
[8] Juan José Murillo Fuentes. Sistema GPRS. Transparencias del VII Curso
Vodafone Tecnologías y Aplicaciones Móviles: GPRS y UMRS, marzo 2009.
[9] Non-SMS data revenues exceed US $ 10 billion in 1Q07. Informa Telecoms
Media’s World Cellular Data Metrics. [online]. Available from: http://
telecoms.msgfocus.com/c/11pxcoTSBC6AZGiSqz.
[10] Ralf Keller Rogier Noldus and Bo Åström. Multi-access for the IMS network.
Ericsson Review, November 2008.
[11] S. Bradner J. Klensin K. Rosenbrock, R. Sanmugam. 3GPP-IETF
Standardization Collaborationk [online]. agosto 2005. Available
from: http://www.oreilly.com/pub/a/oreilly/tim/news/2005/09/30/
what-is-Web-20.html.
[12] G. Camarillo A. Johnston J. Peterson R. Sparks M. Handley E. Schooler
J. Rosenberg, H. Schulzrinne. SIP: Session Initiation Protocol. RFC 3261,
June 2002.
[13] SIP Profile. TS 24.229. Technical report, 3GPP.
[14] 3rd Generation Partnership Project. Technical Specification Group Services
183
BIBLIOGRAFÍA
and System Aspects. IP Multimedia Subsystem (IMS), Stage 2, V5.15.0. TS

23.228, 2006.
[15] XML User Profile Profile. TS 29.228. Technical report, 3GPP.
[16] C. Faure. Presence service in 3G networks. 3G Mobile Communication
Technologies, mayo 2002.
[17] Vaughan-Nichols and S.J. Presence technology: more than just instant
messaging. IEEE Computer, octubre 2003.
[18] Nokia in Messaging [online]. Available from: http://nds2.ir.nokia.com/
NOKIA_COM_1/About_Nokia/Press/White_Papers/pdf_files/NIM.pdf.
[19] Nokia Siemens Networks. Green Hom despliega el triple play con soporte IMS
de la mano de Nokia Siemens - Com Hem capitalizes on IMS ability to cut
costs, connect other operators, and launch new services [online]. Available
from: http://www.nokiasiemensnetworks.com/global/Solutioneering/
SuccessStories/SuccessStoriesPages/Com_Hem_Sweden_IMS_solution.
htm?languagecode=en.
[20] Nokia Siemens Networks. Making fixed-mobile convergence work for Chungh-
wa Telecom [online]. Available from: http://www.nokiasiemensnetworks.
com/NR/rdonlyres/056BC30A-2F7C-4C5B-868D-6A8AE60CAB2C/0/Chungwa_
Customer_SuccessStory_print.pdf.
[21] ABI report. Ericsson holds the top position in the delivery of core IMS
infrastructure and has a global presence in terms of IMS deployments. Technical
report, ABI Research, march 2008.
[22] Next-Generation Converged Services. BEA WebLogic Communications
TM
Platform and IP Multimedia Subsystem (IMS). BEA Systems White Paper,
June 2006.
[23] Eclipse IDE Platform [online]. Available from: http://www.eclipse.org.
[24] Java Community Process. JSR 116 SIP Servlet API v 1.0 (Final Release). Avail-
able from: http://jcp.org/aboutJava/communityprocess/final/jsr116/.
[25] Java Community Process. JSR 289 SIP Servlet v 1.1. Available from:
http://jcp.org/aboutJava/communityprocess/pr/jsr289/index.html.
[26] Application Router [online]. Available from: http://weblogs.java.net/blog/
yvobogers/archive/2008/03/application_rou.html.
[27] JCP. IJCU Javadoc. Technical report, JCP.
[28] Symbian Foundation continues to draw strong industry support. [online].
[29] Ericsson Training. IMS Service Development Studio(SDS) Application
Develpment, 2007-2009.
[30] Forum Nokia. Octopus competition winners competed in Hungary. Sitio Web de
Octopus Networks, junio 2007. Available from: http://www.octo.fi/index.
php?id=39&news_id=23.
[31] Gao Jing. VCC, a solution for FMC dual-mode handover, 2007.
184
[32] Tim O’Reilly. What is Web 2.0?, Design Patterns and Business Models for the
Next Generation of Software .
[33] 3GPP Parlay, ETSI. Especificaciones Parlay X versión 3.0 [online]. noviembre
2007. Available from: http://portal.etsi.org/docbox/TISPAN/Open/OSA/
ParlayX30.html.
[34] Telefónica I+D. Manifiesto WIMS 2.0. Technical report, Telefónica.
[35] David Lozano Llanos (Telefónica I+D); Luis Ángel Galindo Sanchez (Tele-
fónica España) David Moro Fernandez. WIMS 2.0: LA CONVERGEN-
CIA DEL MUNDO TELCO CON LA WEB 2.0. Boletín de la Sociedad
de la Información: Tecnología e Innovación, diciembre 2008. Available
from: http://sociedaddelainformacion.telefonica.es/jsp/articulos/
detalle.jsp?elem=7518.
[36] Christine Gallen. IP Multimedia Subsystem’s $ 300 Billion Opportunity. ABI
Research, march 2008. Available from: http://www.abiresearch.com/press/
1077-IP+Multimedia+Subsystems%92+$300+Billion+Opportunity.
[37] J.-C. Khlifi, H.; Gregoire. IMS Application Servers: Roles, Requirements, and
Implementation Technologies. IEEE Internet Computing, mayo-junio 2008.
185
D. AGRADECIMIENTOS
Este Proyecto Fin de Carrera significa el culmen a los estudios de Ingeniería de

Telecomunicación. Durante los cinco años de clases, exámenes, trabajos, experiencias
y cambios más o menos perceptibles; y, durante estos últimos meses en los que
he acometido la realización del Proyecto Fin de Carrera he aprendido a valorar
dos constantes que me han acompañado desde el principio. El trabajo duro y
el optimismo han sido el factor común que me ha rescatado en los momentos
más difíciles, y me ha proporcionado una seguridad y una fortaleza personal que
desconozco si las hubiera conocido de haber escogido otro camino distinto. Sin
embargo, a pesar de haber sido una singladura personal, han sido las personas que me
rodeaban y apoyaban quienes han forjado esa estructura que en ocasiones adolecía
de robustez. Con su dedicación y con su aliento, con sus críticas y felicitaciones, he
de corresponder a todos los que me han ayudado y lo siguen haciendo.
A mi familia y a Myriam, por haber estado siempre a mi lado, engrandeciendo
alegrías y suavizando los fracasos y las malas noticias. Fueron mis padres
quienes me apoyaron en las primeras decisiones y en las más difíciles. Mi
hermana quien me dio consejos con su propio ejemplo, y mi hermano por
hacerme sentir válido y admirado. Y porque el simple hecho de conocer a
Myriam me hizo darme cuenta que siempre había que buscar una motivación,
un sueño, inclusive cuando todo parezca adverso.
A mis amigos. No puedo hacer distinción entre ellos, ellos lo saben. Algunos
los he conocido en la carrera, otros son los de toda la vida. Unos están cerca y
otros lejos. Con algunos venía y volvía de la Escuela, con otros compartía clases
y trabajos. Otros trasnochaban conmigo en alguna biblioteca o me hacían reír
ante los nervios de un examen. Unos me acompañaron en Sevilla y otros me
acogieron con los brazos abiertos en Madrid. Todos se interesaron por mí, todos
me dieron grandes alegrías y me ayudaron a sacar todos los retos adelante.
A mis compañeros del Proyecto Minerva. Porque me proporcionó la finan-
ciación y la flexibilidad para realizar este Proyecto. A Dani Jiménez por en-
señarme a dar los primeros pasos en IMS y a redescubrir el interés por la
Telemática. A Ana Madera por haberme aportado siempre su consejo y su
valiosa opinión. Y a Alejandro Carballar, por tutorar este proyecto, por su
dedicación y por animarme a alcanzar y valorar el trabajo bien hecho.
A todos ellos, gracias.
José María Rivera Rubio
187

IMS (Ok)

Cargado por

Copyright:

Formatos disponibles

IMS (Ok)

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

IMS (Ok)

Cargado por

Copyright:

Formatos disponibles

Proyecto Fin de Carrera

IP Multimedia Subsystem: el impulsor

Autor José María Rivera Rubio

Tutor Dr. Alejandro Carballar Rincón

Sevilla, junio de 2009

2. Introducción teórica al IP Multimedia Subsystem, IMS 5

3. Un entorno de desarrollo: el SDS de c Ericsson 53

4. Creación de un servicio IMS con el SDS 113

5. Propuesta de despliegue comercial de un servicio y plan de explotación133

6. Conclusiones y retos futuros 147

B. Ericsson IMS Common System 4.1 157

2.1. IMS hacia la convergencia de redes All-IP . . . . . . . . . . . . . . . 7

3.1. Esquema general de los bloques que componen el IMS Developer

4.1. Beneﬁcios para el usuario de las aplicaciones IMS. . . . . . . . . . . . 113

5.1. Arquitectura de IMS donde se aprecia el papel de los servidores Parlay

en una misma experiencia de usuario.

alternativas de despliegue comercial de un servicio, seleccionando y deﬁniendo el

1.3 Organización de la memoria

1. Introducción. La memoria del proyecto comienza con la motivación, a modo

describe una propuesta del despliegue comercial de un servicio IMS desde

cualquier otra conexión, como Asymmetric Digital Subscriber Loop (ADSL) o

2.2 Justiﬁcación: ¿Por qué IMS?

Figura 2.1.: IMS hacia la conver-

conversaciones VoIP sobre el dominio conmutación de paquetes. Entonces, al tener

1. Calidad de servicio (QoS). En el dominio de conmutación de paquetes

tiempo real. En el momento de establecer la sesión es IMS quien se encarga de

objetivo real es el de proporcionar todos los servicios que se pueden encontrar en

Los denominados servicios heredados (las llamadas básicas de voz, la

2.3 Tendencias Todo-IP (All-IP) en 3G e IMS y

de sesión diseñado con tecnologías de Internet adaptadas al mundo móvil

2.3.2 Sinergias entre grupos de estandarización: el IETF con el

Área de Gestión y Operaciones (Operations and Management)

2.3.3 El 3GPP Release 5 y la génesis de los servicios IP Multimedia

que se transﬁeren directamente entre los terminales sin atravesar el subsistema

Figura 2.2.: Separación funcional de IMS

2.4 Protocolos utilizados en IMS

Métodos SIP Mediante un modelo de cliente servidor, SIP soporta un número de

Asimismo, las respuestas del protocolo SIP – heredadas de HTTP – se engloban en

1xx: Respuestas informativas.

REGISTER sip:registrar.biloxi.com SIP/2.0

Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7

To: Bob <sip:[email protected]>

From: Bob <sip:[email protected]>;tag=456248

CSeq: 1826 REGISTER

Figura 2.3.: Ejemplo de

establecerán a qué tipos de medios multimedia corresponden dichos ﬂujos (audio,

Protocolo de AAA (Authentication, Authorization, and Accounting)

2.5 Arquitectura de IMS

En la ﬁgura, se observan varios dominios representados por nubes. El acceso a

Figura 2.5.: Elementos de la arquitectura de IMS agrupados en cinco grandes

para ello obtiene información de localización mediante una interfaz con

Servidores de aplicación, AS (Application Server) y las pasarelas con destino

de SIP proxy, agente de usuario SIP (como un usuario más) o como un

• Encaminamiento basados en números de teléfono: El 3GPP

Funciones de recursos multimedia MRF (Media Resource Function): Pro-

• MRFC (Multimedia Resource Function Controller), un nodo del plano

2.6 Funcionamiento de IMS

Figura 2.6.: Requerimientos para el fun-

2.6.1 Fases previas al funcionamiento en IMS