Subsistema

multimedia IP

(IMS)
Manual
Subsistema
multimedia IP

(IMS)
Manual
Editado por
Syed A. Ahson
Mohammad Ilyas

Boca Ratón Londres Nueva York

CRC Press es un sello de la

Taylor & Francis Group, una empresa informa
CRC Press
Grupo Taylor & Francis
6000 Broken Sound Parkway NW, Suite 300 Boca
Ratón, FL 33487-2742

© 2009 por Taylor & Francis Group, LLC

CRC Press es un sello de Taylor & Francis Group, una empresa de Informa.

No se reclaman obras originales del Gobierno de [Link].

Impreso en los Estados Unidos de América en papel sin ácido 10 9 8
7654321

International Standard Book Number-13: 978-1-4200-6459-9 (Tapa dura)

Este libro contiene información obtenida de fuentes auténticas y de gran prestigio. Se han realizado esfuerzos
razonables para publicar datos e información fiables, pero el autor y el editor no pueden asumir la
responsabilidad de la validez de todos los materiales ni de las consecuencias de su uso. Los autores y editores
han intentado localizar a los titulares de los derechos de autor de todo el material reproducido en esta
publicación y piden disculpas a los titulares de los derechos de autor si no ha obtenido el permiso para
publicarlo de esta forma. Si no se ha reconocido algún material protegido por derechos de autor, por favor
escríbanos e infórmenos para que podamos rectificar en cualquier reimpresión futura.

Salvo en los casos permitidos por la Ley de Propiedad Intelectual de los Estados Unidos, ninguna parte de este
libro puede ser reimpresa, reproducida, transmitida o utilizada en forma alguna por ningún medio electrónico,
mecánico o de otro tipo, conocido actualmente o inventado en el futuro, incluidos el fotocopiado, la
microfilmación y la grabación, ni en ningún sistema de almacenamiento o recuperación de información, sin el
permiso por escrito de los editores.

Para obtener permiso para fotocopiar o utilizar electrónicamente material de esta obra, acceda a [Link]-
[Link] ([Link] o póngase en contacto con el Copyright Clearance Center, Inc. (CCC),
222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. El CCC es una organización sin ánimo de lucro que
proporciona licencias y registros a diversos usuarios. Para las organizaciones a las que el CCC ha concedido una
licencia de fotocopias, se ha dispuesto un sistema de pago independiente.

Aviso sobre marcas comerciales: Los nombres de productos o empresas pueden ser marcas comerciales o
marcas registradas, y se utilizan únicamente para su identificación y explicación sin intención de infringirlas.

Biblioteca del Congreso Cataloging-in-Publication Data

Manual del subsistema multimedia IP (IMS) / editores, Syed A. Ahson, Mohammad Ilyas.
p. cm.
Incluye referencias bibliográficas e índice. ISBN 978-1-
4200-6459-9 (alk. paper)
1. Subsistema multimedia de protocolo de Internet. I. Ahson, Syed. II. Ilyas, Mohammad,
1936- III. Título.

TK5105.15.I64 2008
006.7--dc22 2008032888

Visite el sitio web de Taylor & Francis en

[Link]

y el sitio web de CRC Press en [Link]

Contenido

Prefacio ................................................................................................................................. ix
Los editores.......................................................................................................................... xi
Colaboradores ................................................................................................................... xiii

Sección 1 Conceptos

1 Servicio, modelos y conceptos IMS ............................................................................ 3

Emmanuel Bertin y Noël Crespi

2 IMS: una arquitectura segura para todas las redes IP ........................................ 27

Muhammad Sher y Thomas Magedanz

3 Funciones punto a punto en el subsistema multimedia IP .................................. 73

Adetola Oredope y Antonio Liotta

4 Sobre el soporte de las funciones de medios en el IMS ........................................ 87

Jean-Charles Grégoire y Admela Jukan

Sección 2 Tecnologías

5 El FOKUS Open IMS Core-Una Implementación Global de Referencia IMS

..................................................................................................................................113
Peter Weik, Dragos Vingarzan y Thomas Magedanz

6 Soporte de red de próxima generación en la plataforma SIP/IMS ................. 133

Vicente Olmedo, Antonio Cuevas, Víctor Villagrá y José I. Moreno

7 Control de QoS basado en políticas para una red de convergencia................. 157

Younghan Kim y Youngsuk Lee

8 Servidor de capacidad de servicio OSA-Parlay/Parlay X ................................. 169

Moo Wan Kim y Ryozo Ito

9 Interconexión de redes 3GPP, WLAN y Wimax ................................................ 191

Fangmin Xu, Luyong Zhang, Zheng Zhou y Wei Zhong

v
vi Contenido

10 Servidor de aplicaciones IM-SSF-Interfuncionamiento con CAMEL ........ 215

Moo Wan Kim y Ryozo Ito

11 IMS distribuido ..................................................................................................... 243

Marcin Matuszewski

Sección 3 Servicios

12 Plataformas de prestación de servicios y diseño de servicios multimedia ... 265

Christopher J. Pavlovski

13 Integración de IMS en las plataformas de prestación de servicios

Basado en Arquitecturas Orientadas a Servicios ............................................. 307
Niklas Blum, Peter Weik y Thomas Magedanz

14 Orquestación de servicios en IMS ...................................................................... 329

Anahita Gouya y Noël Crespi

15 Servicio de mensajería instantánea y presencia (IMPS) ................................. 345

Whai-En Chen

16 Servicios multipartitos en el subsistema multimedia IP .................................. 363

Iván Vidal, Ignacio Soto, Francisco Valera, Jaime García y Arturo Azcorra

17 Conferencias basadas en IMS Servicios: Un enfoque de ingeniería

................................................................................................................................. 383
Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero,
y Simon Pietro Romano

18 IPTV basada en IMS ............................................................................................. 411

Oliver Friedrich, Stefan Arbanowski, Adel Al-Hezmi y Robert Seeliger

19 Modelado y arquitectura de IPTV sobre IMS .................................................. 443

David López, Eugen Mikoczy, José Ignacio Moreno, Antonio Cuevas, y
Enrique Vázquez

20 Servidor de aplicaciones de prepago basado en SIP ........................................ 473

Mario Weber

21 Plataformas JAIN SLEE para servidores de aplicaciones IMS ..................... 493

Igor Vukomanović
Índice vii

22 El papel del OSS/BSS en el éxito del IMS ....................................................... 509

Jithesh Sathyan

Índice .................................................................................................................................. 531

Prefacio

La convergencia fijo-móvil y las redes de voz-datos han fusionado la próxima

generación, las aplicaciones de valor añadido y los servicios multimedia integrados,
combinando navegación web, mensajería instantánea, presencia, voz sobre IP,
videoconferencia, aplicaciones compartidas, telefonía, mensajería unificada, entrega
de contenidos multimedia, etc. sobre diferentes tecnologías de red. La convergencia
de las redes de comunicaciones está motivada por la necesidad de soportar
numerosas formas de tráfico digital, así como de amortizar los costes de
implantación y explotación de las redes subyacentes. Históricamente, el enfoque
para construir y desplegar servicios multimedia se ha centrado en soluciones de
punto único. Estas soluciones han funcionado bien para atender las necesidades
específicas del servicio previsto o de un conjunto de servicios relacionados; sin
embargo, presentan deficiencias de extensibilidad para atender los servicios
multimedia más recientes y emergentes. Un enfoque más pragmático consiste en
desarrollar una única plataforma consolidada que sea capaz de soportar una amplia
variedad de servicios multimedia a través de varias redes de comunicación.
El subsistema multimedia IP (IMS) es una arquitectura estandarizada de trabajo
en red de próxima generación concebida para operadores de telecomunicaciones que
deseen prestar servicios avanzados sobre redes móviles y fijas. El IMS es un marco
arquitectónico orientado a servicios cuyo objetivo es prestar servicios de Internet
actuales y futuros a usuarios finales fijos y móviles a través de una plataforma
multiacceso totalmente IP. El Proyecto de Asociación de Tercera Generación
(3GPP) y el 3GPP2 han desarrollado el IMS para proporcionar plataformas de
prestación de servicios para un paradigma de comunicación convergente. El IMS
permite integrar los servicios de Internet existentes con los futuros. Se trata de una
plataforma de servicios bien diseñada, que utiliza protocolos de Internet abiertos y
normalizados y respeta el paradigma de Internet de transporte de datos y separación
de aplicaciones con enlaces entre estas dos capas. El IMS ofrece a los operadores de
telecomunicaciones la posibilidad de construir una infraestructura de servicios
abierta y basada en IP que facilite el despliegue de nuevos y ricos servicios de
comunicación multimedia que combinen servicios de telecomunicaciones y datos.
El subsistema multimedia IP otorga al operador de red el papel de intermediario
de servicios. Las llamadas multimedia son un servicio inherente al IMS, pero se
están desarrollando muchos más servicios sobre la plataforma de servicios IMS para
construir un rico entorno de servicios que atraiga a los usuarios a emplearlo. El IMS
es una arquitectura basada en IP diseñada para proporcionar un conjunto de
funcionalidades esenciales que soporten la prestación de los servicios multimedia de
nueva generación que se prevén en el futuro de las redes de tercera generación.
La arquitectura IMS se ha definido para proporcionar al usuario acceso a una
amplia gama de servicios, que se implementan mediante servidores de aplicaciones.
El IMS ha dado lugar a un entorno que introduce nuevos ser- vicios con más rapidez
que nunca, así como nuevos e interesantes conceptos como

ix
x Prefacio

componentes de servicio reutilizables e integración en tiempo real. El IMS llena el

vacío existente entre la tecnología tradicional de telecomunicaciones y la tecnología
Inter- net, permitiendo a los operadores ofrecer servicios nuevos, innovadores y
atractivos; representa una plataforma estandarizada y reutilizable que proporciona
una mejor manera de implantar, desplegar, integrar y ampliar los servicios de voz y
datos para consumidores y empresas. El interés por el IMS es cada vez mayor debido
a su capacidad para revolucionar la experiencia del usuario final con servicios
nuevos e innovadores.
El Manual del Subsistema Multimedia IP IMS) proporciona información técnica sobre
todos los aspectos del IMS. Las áreas cubiertas en el manual abarcan desde
conceptos básicos hasta material de investigación, incluidas las direcciones futuras.
El manual recoge el estado actual de la tecnología IMS y sirve como fuente de
material de referencia exhaustivo sobre este tema. El manual consta de tres
secciones: Conceptos, Tecnologías y Servicios. Cuenta con un total de 22 capítulos
escritos por 50 expertos de todo el mundo. El manual está dirigido a profesionales
que diseñan o planifican sistemas IMS, investigadores (profesores y de posgrado) y
a quienes deseen aprender sobre este campo.
Este manual tiene las siguientes características específicas destacadas:
• para que sirva de fuente única y exhaustiva de información y como
material de referencia sobre la tecnología IMS;
• para tratar un tema importante y oportuno de la tecnología emergente de
hoy, mañana y más allá;
• presentar información precisa y actualizada sobre una amplia gama de
temas relacionados con la tecnología IMS;
• presentar material elaborado por expertos en la ; y
• presentar la información de forma organizada y bien estructurada.
Aunque el manual no es precisamente un libro de texto, sin duda puede utilizarse
como libro de texto para cursos de postgrado y cursos orientados a la investigación
que traten de la IMS. Agradeceremos cualquier comentario de los lectores.
Muchas personas contribuido a este manual a su manera. El primer grupo, y el
más importante, que merece una inmensa gratitud es el grupo de investigadores de
gran talento y cualificación que han contribuido con 22 capítulos a este manual.
Todos ellos se han mostrado extremadamente cooperativos y profesionales.
También ha sido un placer trabajar con Nora Konopka, Jessica Vakili y Judith
Simon, de CRC Press, y estamos muy agradecidos por su apoyo y profesionalidad.
Nuestras familias nos han brindado su amor incondicional y su firme apoyo a lo
largo de este proyecto, y todas ellas merecen un agradecimiento muy especial.
Syed Ahson
Plantation, Florida
Mohammad Ilyas
Boca Ratón, Florida
La
Redacción
Syed Ahson es ingeniero superior de software en Motorola, Inc. Ha desempeñado
un papel destacado y ha contribuido significativamente a la creación de varios
teléfonos móviles avanzados e interesantes en Motorola. Tiene una amplia
experiencia en protocolos de datos inalámbricos (TCP/IP, UDP, HTTP, VoIP, SIP,
H.323), aplicaciones de datos inalámbricas (navegación por Internet, mensajería
multimedia, correo electrónico por cable, actualización de firmware por aire) y
protocolos de telefonía móvil (GSM, CDMA, 3G, UMTS, HSDPA). Antes de
incorporarse a Motorola, fue ingeniero superior de diseño de software en NetSpeak
Corporation (ahora parte de Net2Phone), pionera en software de telefonía de voz
sobre IP.
Ahson es coeditor del manual en tres volúmenes WiMAX Handbook (CRC Press) y autor
de "Smartphones", un informe de investigación que reflexiona sobre el mercado y
las tecnologías de los teléfonos inteligentes para el Consorcio Internacional de
Ingeniería (IEC). Ha publicado varios artículos de investigación e imparte cursos de
ingeniería informática como profesor adjunto en la Florida Atlantic University de
Boca Ratón (Florida), donde introdujo un curso sobre tecnología y aplicaciones de
teléfonos inteligentes. Se licenció en Ingeniería Informática en 1998 en la Florida
Atlantic University y en Ingeniería Eléctrica en la Universidad de Aligarh (India) en
1995.

Mohammad Ilyas se licenció en ingeniería eléctrica por la Universidad de Ingeniería y

Tecnología de Lahore (Pakistán) en 1976. De marzo de 1977 a septiembre de 1978
trabajó para la Autoridad de Desarrollo de Agua y Energía de Pakistán. En 1978
obtuvo una beca para cursar estudios de postgrado y en junio de 1980 terminó un
máster en ingeniería eléctrica y electrónica en la Universidad de Shiraz (Irán). En
septiembre de 1980 ingresó en el programa de doctorado de la Queen's University de
Kingston, Ontario (Canadá). Terminó su doctorado en 1983. Su investigación
doctoral versó sobre técnicas de conmutación y control de flujo en redes de
comunicaciones informáticas. Desde septiembre de 1983 trabaja en la Facultad de
Ingeniería e Informática de la Florida Atlantic University, en Boca Ratón (Florida),
donde actualmente es Decano Adjunto de Investigación y Relaciones con la
Industria. De 1994 a 2000 fue director del Departamento de Ingeniería y Ciencias
Informáticas. De julio de 2004 a septiembre de 2005, fue vicepresidente adjunto
interino de investigación y estudios de postgrado. Durante el académico 1993-1994,
disfrutó de un permiso sabático en el Departamento de Ingeniería Informática de la
Universidad Rey Saud de Riad (Arabia Saudí).
El Dr. Ilyas ha investigado con éxito en diversos campos, como la gestión del
tráfico y el control de la congestión en redes de comunicaciones de banda ancha/alta
velocidad, la caracterización del tráfico, las redes de comunicaciones inalámbricas,
la modelización del rendimiento y la simulación. Ha publicado un libro, ocho
manuales y más de 150 artículos de investigación. Ha supervisado 11

xi
xii La
Redacción

tesis doctorales y más de 37 tesis de máster. Ha consultor de varias organizaciones

nacionales e internacionales. El Dr. Ilyas participa activamente en varios comités y
actividades técnicas del IEEE, es miembro sénior del IEEE y miembro de la ASEE.
Colaboradore
s
Adel Al-Hezmi Instituto de Investigación Fraunhofer FOKUS para Sistemas de
Comunicación Abiertos, Berlín, Alemania

Alessandro Amirante Universidad de Nápoles Federico II, Nápoles, Italia

Stefan Arbanowski Instituto de Investigación Fraunhofer FOKUS para

Sistemas de Comunicación Abiertos, Berlín, Alemania

Arturo Azcorra IMDEA Networks, Madrid, España Universidad Carlos III de

Madrid, Madrid, España

Emmanuel Bertin Orange Labs, France Telecom, Caen, Francia

Niklas Blum Instituto de Investigación Fraunhofer FOKUS para Sistemas de

Abiertos, Berlín, Alemania

Tobia Castaldi Università di Napoli Federico II, Nápoles, Italia

Whai-En Chen Universidad Nacional I-Lan, Taiwán, República de China

Noël Crespi GET-INT-Institut National des Télécommunications, Evry, Francia

Antonio Cuevas Universität Stuttgart, Stuttgart, Alemania

Oliver Friedrich Instituto de Investigación Fraunhofer FOKUS para Sistemas

de Comunicación Abiertos, Berlín, Alemania

Jaime García Universidad Carlos III de Madrid, Madrid, España

Anahita Gouya Institut National des Télécommunications, Evry, Francia Jean-

Charles Grégoire EMT-INRS Universidad de Quebec, Quebec, Canadá

Ryozo Ito Hewlett-Packard, Tokio, Japón

Admela Jukan EMT-INRS Universidad de Quebec, Quebec, Canadá

Moo Wan Kim Universidad de Ciencias de la Información de Tokio, Tokio, Japón

xiii
xiv Colaboradores

Younghan Kim Universidad Soongsil, Seúl, Corea del Sur

Youngsuk Lee Universidad Soongsil, Seúl, Corea del Sur

Antonio Liotta University of Essex, Colchester, Reino Unido David

López Universidad Carlos III de Madrid, Madrid, España Thomas

Magedanz Instituto Fraunhofer FOKUS, Berlín, Alemania Marcin

Matuszewski Nokia, Espoo, Finlandia

Eugen Mikoczy Universidad Eslovaca de Tecnología, Bratislava, Eslovaquia

Lorenzo Miniero Università di Napoli Federico II, Nápoles, Italia

José Ignacio Moreno Universidad Carlos III de Madrid, Madrid, España Vicente

Olmedo Universidad Politécnica de Madrid, Madrid, España Adetola Oredope

University of Essex, Colchester, Reino Unido Christopher J. Pavlovski IBM,

St. Leonards, New South Wales, Australia Simon Pietro Romano Università

di Napoli Federico II, Napoli, Italia Jithesh Sathyan Infosys Technologies

Limited, Bangalore, India

Robert Seeliger Fraunhofer FOKUS Instituto de Investigación de Sistemas de

Comunicación Abiertos, Berlín, Alemania

Muhammad Sher Universidad Técnica de Berlín, Berlín, Alemania

Ignacio Soto Universidad Carlos III de Madrid, Madrid, España Francisco

Valera Universidad Carlos III de Madrid, Madrid, España Enrique Vázquez

Universidad Carlos III de Madrid, Madrid, España Iván Vidal Universidad

Carlos III de Madrid, Madrid, España Victor Villagrá Universidad

Politécnica de Madrid, Madrid, España

Dragos Vingarzan Fraunhofer FOKUS Research Institute for Open Com-

munication Systems, Berlín, Alemania
Colaboradores xv

Igor VukomanoviĆ KATE-KOM, Zagreb, Croacia

Mario Weber KATE-KOM, Zagreb, Croacia

Peter Weik Universidad Técnica de Berlín, Berlín, Alemania

Fangmin Xu Universidad de Correos y Telecomunicaciones de Pekín, República de

China

Luyong Zhang Universidad de Correos y Telecomunicaciones de Pekín, República

de China

Wei Zhong Universidad de Duke, Chapel Hill, Carolina del Norte

Zheng Zhou Universidad de Correos y Telecomunicaciones de Pekín, República

de China
Sección 1

Conceptos
1
fM£ £ervicio, modelos y conceptos

Emmanuel Bertin y Noël Crespi

CONTENIDO
Introducción ........................................................................................................................... 3
Los fundamentos de los servicios IMS .............................................................................. 4
De IN a NGN ............................................................................................................... 4
De NGN a IMS ............................................................................................................ 7
Capacidades de servicio IMS y habilitadores OMA .................................................. 9
Modelo de servicio IMS ........................................................................................................ 12
IMS ofrece nuevos tipos de servicios .......................................................................... 12
El vínculo entre los servicios vistos por el usuario ...................................................... 13
Funciones técnicas ....................................................................................................... 14
Relación entre servicio y función técnica .............................................................. 16
Ejemplo de Push-to-Talk sobre celular ............................................................................. 17
El servicio PoC visto desde la perspectiva del usuario ............................................ 18
Servicio PoC y habilitadores de servicio................................................................... 19
Funciones técnicas para el servicio PoC ...................................................................... 19
Una visión completa de los servicios IMS ................................................................ 22
Conclusión ............................................................................................................................. 22
Glosario ................................................................................................................................. 24
Referencias ............................................................................................................................ 24

Introducción
NGN (red de próxima generación) es un concepto que se ha introducido para tener
en cuenta la nueva situación y los cambios en el campo de las telecomunicaciones.
Esta nueva situación se caracteriza por una serie de aspectos: la desregulación de los
mercados, la nueva demanda de los usuarios de servicios innovadores para satisfacer
sus necesidades y la explosión del tráfico digital (aumento del uso de Internet). La
introducción de las NGN comprende aspectos económicos y técnicos. Desde el
punto de vista económico, permite aumentar la productividad creando nuevos usos
[1] basados en las preferencias de los usuarios y relacionados con los servicios de
voz y datos (por ejemplo, voz sobre IP,

3
4 Manual del subsistema multimedia fP (fM£)

mensajería instantánea, presencia, streaming y push to talk). También permite

reducir los costes de mantenimiento de la infraestructura, con un solo tipo de red de
transporte en lugar de redes específicas para cada red de acceso. Técnicamente, las
NGN flexibilizan la arquitectura de red para definir e introducir nuevos servicios
con facilidad.
La piedra angular de la arquitectura de servicios de las redes de próxima
generación es la arquitectura IMS (subsistema multimedia IP), normalizada por el
3GPP (3rd Generation Partnership Project). El IMS ofrece a los operadores de
telecomunicaciones la posibilidad de construir una infraestructura de servicios
abierta basada en IP que permitirá desplegar fácilmente nuevos y ricos servicios de
comunicación multimedia que combinen servicios de telecomunicaciones y datos.
La concepción de servicios IMS es un reto clave para el mercado de las
telecomunicaciones. Los servicios IMS se adaptan fundamentalmente a las
preferencias del usuario, dependen en gran medida de múltiples redes de acceso y
agrupan múltiples funciones de servicio (por ejemplo, conectividad de voz/vídeo,
herramientas comunitarias, presencia, conferencias, juegos y emisión de TV).
La arquitectura y los aspectos técnicos de la arquitectura IMS están bien tratados
por los organismos de normalización. Sin embargo, estos organismos no proponen
un modelo claro de lo que es (y lo que no es) un servicio IMS. El objetivo de este
capítulo es detallar los conceptos que subyacen a los servicios IMS proponer una
forma de vincular el servicio IMS, los bloques de construcción de servicios y las
funciones técnicas.
Este capítulo se divide en tres secciones. En la primera, presentamos un estudio de
los servicios IMS, empezando por una breve introducción a la arquitectura de las
NGN y describiendo después la arquitectura de servicios IMS y los logros de la
OMA (Open Mobile Alliance). En la segunda , presentamos cómo los servicios IMS
pueden vincularse con bloques de construcción de servicios y con funciones
técnicas. En la tercera sección, ilustramos la sección anterior con el estudio de caso
del servicio push-to-talk sobre celular (PoC), especificado por la OMA.

Los cimientos de los servicios IMS

De IN a NGN
El concepto de redes inteligentes IN) desarrollado en los años 80 fue un precursor de
las NGN. El principio de las IN consiste en separar claramente las funciones de
conmutación de los datos y la lógica de servicio situados en una entidad externa: el
punto de control de servicio (SCP). Se añade una nueva entidad funcional al
conmutador TDM (Time Division Mutiplexing), el punto de conmutación de servicio (SSP),
que sirve de interfaz entre la lógica de servicio y el propio conmutador. Se introduce
una interfaz basada en la familia de protocolos INAP (intelligent network
application part) entre el SSP y el SCP. Los servicios ya no se desarrollan en el
conmutador TDM -como ocurre con el concepto de sistema global para
comunicaciones móviles-.
fM£ £ervicio, modelos y conceptos 5

(GSM) y los servicios suplementarios de la red digital de servicios integrados

(RDSI), sino que se implementan en el SCP. El INAP y los procedimientos
asociados permiten al SCP controlar y supervisar el conmutador.
La red inteligente introdujo el concepto de bloque de construcción independiente
del servicio SIB) para funciones de servicio reutilizables. Así, un servicio podía
considerarse una composición de varios SIB. Pero este objetivo no se alcanzó
plenamente por falta de independencia con el protocolo INAP, de reutilización del
software y de apertura por parte de fabricantes y operadores. Como consecuencia,
las IN desplegadas hoy se basan en una arquitectura monolítica y las plataformas de
servicios no ofrecen servicios flexibles. Además, como la lógica del servicio se
ejecuta en entidades externas, la activación de varios servicios para una exige
disponer de mecanismos de gestión de la interacción de servicios. Esta cuestión,
conocida como interacción de funciones, es uno de los problemas más complejos
que se plantean en la IN y se ha trabajado mucho en ello. Sin embargo, este trabajo
no puede aplicarse directamente a las NGN debido a las diferencias de servicio y
arquitectura entre la IN y las NGN.
La promesa de las NGN, tal y como se definieron a finales de los 90, era
compensar estas deficiencias pasando de un enfoque vertical (en el que el acceso, el
control y los servicios están estrechamente ligados) a un enfoque horizontal (en el
que cada capa proporciona elementos reutilizables a otras capas). En la Unión
Internacional de Telecomunicaciones (UIT)-T se está trabajando en la especificación
(como se describe en Knight- son, Morita y Towle [2]) para formalizar la separación
(por ejemplo, mediante protocolos estándar o interfaces de programación de
aplicaciones [API]) entre

• el estrato de transporte, que se compone de funciones de transferencia

desde diversas redes de acceso (red de acceso radioeléctrico terrestre
UMTS [UTRAN], red de área local inalámbrica [WLAN], xDSL) y desde las
redes centrales, funciones de control para estas funciones de transferencia
(por ejemplo, control de la conexión a la red o control de recursos y
admisión), los perfiles de usuario de transporte (por ejemplo, para
almacenar los datos vinculados a la conexión a la red) y las funciones de
tratamiento de medios (por ejemplo, para reproducir anuncios o para
transcodificar); y
• el estrato de servicios, compuesto por funciones de control de servicios
independientes del acceso (por ejemplo, control de establecimiento de
sesiones o control de activación de servicios), funciones de aplicación y
perfiles de usuario de servicios. Las funciones de aplicación deben ser
independientes de las funciones de control del servicio y ofrecer
flexibilidad (por ejemplo, utilizando mecanismos de software abierto) para
responder a las necesidades del usuario.

Esta arquitectura de NGN con dos estratos se define en el Sector de

Normalización de las Telecomunicaciones de la Unión Internacional de
Telecomunicaciones (UIT-T) (figura 1.1). La arquitectura NGN también puede
representarse con tres capas en lugar de dos estratos (este es, por ejemplo, el caso en
el Instituto Europeo de Normas de Telecomunicaciones [ETSI]). En este caso, las
funciones de control del servicio y las funciones de control del transporte se agrupan
en una capa de control. En
6 Manual del subsistema multimedia fP (fM£)

Estrato de Funciones de
servicio aplicación

Perfiles de
los usuarios Funciones de
control del
servicio

Funciones de control
Perfiles de del transporte
Funciones usuario de Funciones de
de usuario transporte manipulación
final de soportes
Funciones
de
Estrato de transporte transferenc
ia

Flujos de control Flujos de medios

FIGURA 1.1
Arquitectura técnica de las NGN [2].

Por tanto, la separación implica una capa de transferencia (con funciones de

transferencia), una capa de control (con funciones de control del transporte y
funciones de control del servicio) y una capa de aplicación (con funciones de
aplicación).
Podemos establecer un paralelismo entre las arquitecturas IN y NGN: La función
de control de servicio (normalmente implementada con un proxy de protocolo de
iniciación de sesión [SIP]) es la contrapartida NGN del conmutador TDM/SSF
(función de selección de servicio) y la función de aplicación (por ejemplo,
implementada con un servidor de aplicaciones SIP) es la contrapartida NGN de la
función de control de servicio (SCF). En ambas arquitecturas, los criterios de
activación se han definido para no invocar servicios sistemáticamente, sino sólo
cuando sea necesario. Sin embargo, existe una diferencia clave entre estas
arquitecturas en lo que respecta a los mecanismos de activación. En IN, el SCF
controla el SSF mediante INAP, que es independiente de los protocolos de control
de llamadas. En las arquitecturas NGN, la función de aplicación se inserta en la ruta
de señalización; por lo tanto, todas las peticiones y respuestas de señalización SIP
pueden ser interceptadas por la entidad que controla los servicios. De hecho, el
concepto IN de "punto de control" (es decir, una entidad que puede controlar el SSP
y modificar la señalización en cualquier momento) no existe en el contexto de las
NGN. Este concepto se sustituye por la noción de función de aplicación presente en
la ruta de señalización, que puede modificar los mensajes SIP para ejecutar una
lógica de servicio. La consecuencia de esta diferencia fundamental en señalización y
arquitectura es que los mecanismos definidos en IN para la interacción de funciones
no son aplicables en su mayoría a SIP.
fM£ £ervicio, modelos y conceptos 2

De NGN a IMS
La arquitectura IMS es una realización de los principios de las NGN, basada en el
protocolo SIP para el control de sesión. Las especificaciones IMS [3] definen toda la
arquitectura de control de sesiones multimedia sobre el dominio de conmutación de
paquetes del sistema de telecomunicaciones de modo universal (UMTS). Con IMS,
los operadores proporcionan tanto un control de sesión fiable como servicios mejor
integrados. Dado que IMS resuelve problemas de arquitectura para despliegues SIP
(como se detalla en Bertin, Bury y Lesieur [4]), ahora se considera una directriz para
todo despliegue SIP que utilice el paradigma cliente/servidor. Mientras que el IETF
(Internet Engineering Task Force) ha estandarizado el protocolo SIP pero no las
arquitecturas asociadas [5], el 3GPP ha definido con precisión las arquitecturas y los
procedimientos para garantizar la itinerancia, la escalabilidad, la seguridad y la
fiabilidad. Además, las especificaciones IMS no están intrínsecamente ligadas a las
redes móviles [6]. IMS se concibió, en su mayor parte, independientemente del
dominio de conmutación de paquetes UMTS y puede adaptarse a otros tipos de
redes de acceso. El 3GPP ha especificado la interfaz entre IMS y las redes de acceso
WLAN (IMS release 6) [7]. El proyecto ETSI TISPAN (Telecommunications and Internet
Con- verged Services and Protocols for Advanced Networking) especifica las
adaptaciones que controlan las redes de acceso xDSL con IMS [8]. Además de IMS,
TISPAN también define otros subsistemas, como la emulación de red telefónica
pública conmutada (RTPC)/RDSI para la sustitución de la RTPC (que será necesaria
en Europa entre 2008 y 2012).
Los principales elementos relacionados con la arquitectura de servicios son los
siguientes:

• Las S-CSCF (funciones de control del estado de la llamada) implementan

funciones de control de servicios (control de sesión y activación de
servicios).
• El HSS (Home Subscriber Server) es la base de datos central de servicios y
redes. Implementa los perfiles de usuario de servicio (así como los perfiles
de usuario de trans- porte).
• Los AS (servidores de aplicaciones) implementan las funciones de la
aplicación, proporcionando a los usuarios servicios relacionados con la
sesión. Los AS ofrecen API como OSA/Parlay o SIP servlet para la
ejecución de aplicaciones.

En cuanto a la identidad del usuario, éste está representado en IMS por varias
identidades. Las identidades públicas son direcciones enrutables que pueden
comunicarse a los contactos del usuario y que pueden utilizarse para localizarlo (por
ejemplo, sip:alice@pro- [Link] o [Link] Las identidades privadas
pertenecen al operador IMS y se almacenan en la tarjeta SIM (módulo de identidad
del abonado). Un mismo usuario puede tener varias identidades privadas y varias
identidades públicas, pero sólo se almacena una identidad privada por tarjeta SIM
(Figura 1.2).
En cuanto a la activación de servicios, IMS proporciona una arquitectura de
activación de aplicaciones basada en criterios de filtrado y activadores de puntos de
servicio (SPT) [9]. Los criterios de filtrado ini- tial (iFC) permiten a la S-CSCF
decidir qué servicios deben ser invocados durante una sesión o transacción SIP y en
qué orden deben aplicarse. Los SPTs son los puntos de la señalización SIP en los
que se aplican los criterios de filtrado.
8 Manual del subsistema multimedia fP (fM£)

Identidad
pública de
usuario Perfil del
servicio
IMS Identidad Identidad
Suscripción privada de pública de
usuario usuario

Identidad Perfil del

pública de servicio
usuario

FIGURA 1.2
Identidades de usuario IMS en la versión 5 de IMS [3].

Servidor de
aplicaciones
Lógica de servicio

Puntos de activación de la plataforma

de servicios

HSS Interfaz SIP

iFC SIP

S-CSCF

S
SIP P SIP
Criterios de filtrado
T

FIGURA 1.3
Arquitectura de activación del servidor de aplicaciones [9].

pueden establecerse. Los criterios de filtrado se distribuyen entre la S-CSCF, el HSS

y el servidor de aplicaciones IMS, como se muestra en la Figura 1.3.
Las iFC se almacenan en el HSS como parte del perfil de servicio. Se descargan
en la S-CSCF en el momento del registro del usuario o al finalizar la solicitud inicial
de un usuario no registrado. Están activos durante el tiempo de vida del registro o
hasta que se cambia el perfil de servicio. Los criterios de filtrado deben contener la
siguiente información, estructurada en formato XML:

• la dirección del SV con el que hay que ponerse en contacto;

• la prioridad de los criterios de filtrado que proporcionan la secuencia en la
que se aplicarán los criterios;
fM£ £ervicio, modelos y conceptos 9

• los SPT, que pueden contener la siguiente información Método SIP,

presencia o ausencia de alguna cabecera, contenido de alguna cabecera,
información de descripción de la sesión, etc.;
• tratamiento por defecto si el AS no es alcanzable; y
• información de servicio opcional, que se añade al cuerpo del mensaje antes
de enviarlo al AS.

Durante la fase de registro, se asigna una S-CSCF para controlar los servicios del
usuario. El perfil de servicio (que contiene iFC) del usuario se descarga del HSS a la
S-CSCF. Cuando la S-CSCF recibe una solicitud SIP que coincide con la iFC,
invoca el servicio asociado reenviando esta solicitud SIP al AS indicado en la iFC.
Las iFC sólo se aplican a las solicitudes SIP iniciales (es decir, las solicitudes que
inician una sesión o transacción SIP: INVITE, SUBSCRIBE, REGISTER, OPTION,
etc.); en consecuencia, la invocación del servicio sólo puede hacerse estáticamente en
la fase de inicio de sesión o transacción SIP.
Un usuario puede suscribirse a varios servicios y, en consecuencia, puede haber
varias iFC en el perfil de servicio. Cuando la S-CSCF recibe una petición SIP
inicial, comprueba si coincide con la iFC que tiene la prioridad más alta para este .
Si no coincide, la S-CSCF comprueba la siguiente iFC, en el orden de prioridad
predefinido. Si coincide, la S-CSCF reenvía la petición al AS indicado. Este AS
ejecuta la lógica de servicio, eventualmente modifica la solicitud, y la envía de
vuelta a la S-CSCF. La S-CSCF realiza el mismo procesamiento con la siguiente
iFC no ejecutada. La S-CSCF continúa este proceso hasta que se comprueban todas
las iFC. El AS también puede suprimir la información necesaria para activar la iFC
(por ejemplo, la sustitución de la identidad pública por un identificador uniforme de
recursos [URI] de agente de usuario [UA] enrutable globalmente) o finalizar
localmente la solicitud como parte de la lógica del servicio (por ejemplo, una cuenta
de prepago sin crédito restante). Estos mecanismos se utilizarán para construir
futuros servicios de comunicación con el IMS.
3GPP había especificado un SIP AS llamado service capability interaction
manager (SCIM) para gestionar las interacciones entre servidores de aplicaciones,
pero ni "las funcionalidades de invocación de servicios sobre ISC" ni "las
funcionalidades de gestión de interacciones de servicios de SCIM" están
especificadas en los estándares [14]. Estos puntos se detallan en el capítulo 14,
"Orquestación de servicios en IMS".

Capacidades de servicio IMS y habilitadores OMA

objetivo empresarial del IMS es permitir la creación de servicios innovadores de
forma flexible. Los servicios IMS incluirán múltiples características de servicio como chat,
mensajería instantánea, voz, vídeo, presencia, libreta de direcciones y difusión de
TV [10,11]. Si un proveedor de servicios todas estas funciones de forma
descoordinada, el usuario tendrá que gestionar la interacción entre los servicios (por
ejemplo, introduciendo varias veces las mismas preferencias personales). Además,
los servicios avanzados que combinan muchas características de servicio (como el
encaminamiento de llamadas de voz según la comunidad de origen y el estado de
disponibilidad)
10 Manual del subsistema multimedia fP (fM£)

no son posibles si no hay coordinación entre las funciones. La respuesta para

mejorar la experiencia del usuario es construir un entorno de servicios coherente
normalizando las funciones de las aplicaciones.
En la actualidad, la normalización de las funciones de aplicación corre a cargo
principalmente del UIT-T, el 3GPP y la OMA. Las empresas de telecomunicaciones
y TI se reagrupan en OMA para especificar servicios avanzados de movilidad
interoperables. OMA se creó en junio de 2002 como combinación del foro WAP, la
iniciativa SyncML, el grupo de interoperabilidad MMS, la iniciativa Wireless
Village, el foro Mobile Wireless Internet y el foro Mobile Games Interoperability.
El objetivo del UIT-T, el 3GPP y la OMA no es estandarizar servicios completos,
sino bloques funcionales de servicios reutilizables en tiempo de ejecución por varios
servicios, como se define en Bertin, Bury y Lesieur [13]. Este enfoque permite la
creación de servicios innovadores y evolutivos, en su mayor parte independientes de
las consideraciones de red. Estos bloques de construcción de servicios proporcionan
capacidades clave para garantizar la interoperabilidad de dispositivos, operadores y
proveedores de servicios. Como ya se ha visto, el UIT-T y el 3GPP están
normalizando los mecanismos que activan estos bloques de construcción, ya sea por
separado o de forma coordinada, incluida la gestión de las interacciones entre estas
capacidades, como se muestra en Gouya, Crespi y Bertin [14]. Estos bloques de
construcción de servicios se denominan capacidades de servicio en el 3GPP,
capacidades de soporte de servicios en el UIT-T y habilitadores de servicios en la
OMA. Las capacidades de soporte de servicios estudiadas en el UIT-T [15] suelen
incluir presencia, localización, gestión de grupos, gestión de mensajes,
difusión/multidifusión, push y gestión de sesiones, o gestión de dispositivos. Las
capacidades de soporte de servicios en OMA [16] incluyen, por ejemplo,
sincronización de datos, gestión de dispositivos, gestión de derechos digitales,
descarga, notificación por correo electrónico, mensajería instantánea, presencia y
localización móvil, o mensajería multimedia. Las capacidades de servicio definidas
en 3GPP suelen incluir presencia [17] y mensajería [18] o conferencias [19].
Las especificaciones de la OMA para los habilitadores de servicios son las más
avanzadas y completas. Según la OMA,

• "Un habilitador se define como] una tecnología destinada a ser utilizada en

el desarrollo, despliegue u operación de un servicio; definida en una
especificación, o grupo de especificaciones, publicadas como un paquete
por OMA" [20].
• "Un habilitador debe especificar una o más interfaces públicas. Algunos
ejemplos de habilitadores de OMA son la localización o la gestión de
dispositivos" [16].

Estas definiciones ponen de relieve el carácter normativo de un facilitador. Un

componente o una tecnología es un facilitador porque se ha definido como tal.
Además, cuando los individuales se definen de forma independiente, cada uno de
ellos tiene que definir todas las funciones necesarias para cumplir sus requisitos.
Esto implica varios problemas para el proveedor de servicios, sobre todo la
dificultad de prestar servicios centrados en el usuario: "La integración y el
despliegue de los servicios son complicados y costosos; los esfuerzos de
implantación son elevados para las aplicaciones que desean utilizar
fM£ £ervicio, modelos y conceptos 11

varias capacidades; no hay una integración común de los diferentes servicios desde
el punto de vista del usuario final (por ejemplo, no hay una gestión de grupos o un
perfil de usuario común a través de múltiples servicios)" [16]. Por lo tanto, un
habilitador de OMA debe contener sólo funciones intrínsecas que puedan interactuar
con otras funciones de la arquitectura de servicios o de la arquitectura de red
subyacente. Las funciones intrínsecas se definen como "aquellas funciones que son
esenciales para cumplir la tarea prevista del habilitador especificado. Por ejemplo, la
función de cálculo de posición es intrínseca a la localización segura del plano del
usuario; la autenticación es intrínseca al inicio de sesión único; el cifrado es una
función intrínseca de la gestión de derechos digitales" [16].
Esta separación en funciones intrínsecas y no intrínsecas es una forma de
garantizar que varios habilitadores no incluyan la misma función (por ejemplo,
función de autenticación en cada habilitador). Como se especifica en la referencia 16,
"cualquier requisito o función que no sea intrínseco a un habilitador no debe
especificarse en la especificación del habilitador. La especificación de un habilitador
sólo debe especificar la funcionalidad intrínseca necesaria para cumplir su función
real". Esta especificación de funciones de servicio con habilitadores responsables
únicamente de sus funciones intrínsecas mejora la capacidad de los proveedores de
servicios para ofrecer una experiencia de usuario coherente (es decir, reutilización
de la información del usuario, continuidad del servicio, etc.). Sin embargo, la
separación entre funciones intrínsecas y no intrínsecas no es obvia, sino que sigue
siendo subjetiva, como se reconoce en la referencia 16 ("la clasificación de
intrínsecas y no intrínsecas es subjetiva y debe hacerse para cada habilitador"). Esto
implica de nuevo que la definición de los habilitadores debe ser el resultado de un
proceso normativo.
La OMA ha especificado el entorno de servicios OMA (OSE) [16] que
proporciona una arquitectura común para la integración de habilitadores y la
creación de servicios. Como se muestra en la Figura 1.4, la arquitectura OSE consta
de habilitadores que se ejecutan en un entorno de ejecución y son accesibles a
aplicaciones y otros habilitadores a través de un ejecutor de políticas.
Los habilitadores están destinados a utilizarse en el desarrollo, despliegue u
operación de un servicio. Proporcionan su funcionalidad intrínseca a través de una o
más interfaces públicas denominadas interfaces I0 y pueden utilizar recursos de red
subyacentes a través de interfaces I2 (como las interfaces IMS). El entorno de
ejecución engloba lógicamente diversas funciones, como la supervisión de procesos,
la gestión del ciclo de vida del software, el soporte del sistema (por ejemplo, la
gestión de hilos, el equilibrio de carga y el almacenamiento en caché), la operación,
la gestión y la administración. La interfaz entre el entorno de ejecución y los
habilitadores se denomina interfaz I1. El ejecutor de políticas proporciona un
mecanismo de gestión basado en políticas para proteger los recursos de solicitudes
no autorizadas y para gestionar el uso de estas solicitudes, por ejemplo, mediante el
cobro, el registro y la aplicación de la privacidad o las preferencias del usuario. La
función de aplicación de políticas permite al propietario del dominio extraer y
separar las reglas políticas de los elementos arquitectónicos. Este elemento expone
interfaces I0 + P a aplicaciones y habilitadores, donde P son parámetros adicionales
que deben proporcionarse junto con una solicitud a la interfaz I0 de un habilitador,
cuando las políticas que deben aplicarse
12 Manual del subsistema multimedia fP (fM£)
Aplicaciones
Proveedor de
servicios

I0+P

Ejecutor de
políticas
Entorno de ejecución

I0 I0 I0

I1
Habilitad Habilitador Habilitad
or or
I2 I2 I2

FIGURA 1.4
La arquitectura del entorno de servicios OMA [16].

requieren parámetros adicionales. Las aplicaciones pueden estar ubicadas dentro o

fuera del entorno de prestación de servicios.

Modelo de servicio IMS

IMS ofrece nuevos tipos de servicios
Tradicionalmente, los servicios de telecomunicaciones se dividen en servicios
portadores, teleservicios y servicios suplementarios. "Un servicio portador es un tipo
de servicio de tele- comunicación que proporciona la capacidad para la transmisión
de señales entre la interfaz usuario-red" y "un teleservicio es un tipo de servicio que
proporciona la capacidad completa, incluidas las funciones del equipo terminal, para
la comunicación entre usuarios" y "un servicio suplementario modifica o
complementa un teleservicio básico" [26]. Ejemplos de teleservicio básico son la
telefonía, el fax o las llamadas de emergencia.
Estas nociones se siguen utilizando en algunas normas 3GPP o TISPAN, pero un
proveedor de servicios ya no puede utilizarlas para diseñar servicios. De hecho, el
valor añadido de IMS para los proveedores de servicios es la capacidad de crear
servicios centrados en el usuario que combinen de forma flexible varias funciones y
permitan compartir la información del usuario entre estas funciones para formar un
entorno de servicio coherente para el usuario [12]. Como se explica en la sección
anterior, el habilitador OMA o las capacidades de servicio 3GPP son los bloques de
construcción necesarios para tales servicios. Sin embargo, las normas no definen un
modelo de servicios IMS que vincule los servicios de los usuarios, los habilitadores
y las funciones técnicas.
fM£ £ervicio, modelos y conceptos 13

Las funciones de transferencia y control se abordan ampliamente en los estudios

sobre IMS y NGN. Las funciones de aplicación son abordadas parcialmente por la
OMA en relación con los aspectos de prestación de servicios (con el OSE). Los
servicios previstos para el IMS requerirán una integración coherente de múltiples
débilmente acopladas. La integración entre estas características debe considerarse no
sólo a nivel técnico (es decir, la integración dentro de un entorno de prestación de
servicios como el OSE), sino también a nivel de servicio (es decir, cómo la
composición de diversas funciones técnicas y habilitadores proporcionará una
experiencia de servicio coherente al usuario). Si la integración a nivel técnico está
bien abordada por los estudios de OMA y ETSI, la integración a nivel de servicio no
ha sido investigada.
Para responder a estas necesidades, debemos describir las relaciones entre un
servicio percibido por el usuario y las funciones técnicas y habilitadores utilizados
para implementarlo.
El enfoque de modelización se organiza del siguiente modo:

• modelar el vínculo entre servicios que es visto por los usuarios (por
ejemplo, un usuario es consciente de que su información personal se
comparte entre sus servicios);
• modelar las funciones técnicas que son la base del IMS; las funciones
técnicas son las que llevan a cabo los sistemas (por ejemplo, plataformas de
servicios, terminales) controlados por los proveedores de servicios; y
• modelización de la arquitectura de servicios IMS basada en habilitadores de
servicios. Los habilitadores de servicio están diseñados para la reutilización
de la información del usuario entre servicios y para la fácil integración de
nuevos servicios. Como ya se ha visto, los habilitadores de servicios
contienen y envuelven funciones técnicas (funciones intrínsecas).
Proponemos caracterizar un habilitador por la información que maneja y
por las funciones técnicas que envuelve. Por ejemplo, sólo un habilitador
de servicio puede producir la información de presencia y puede envolver
las funciones técnicas vinculadas a la presencia, o sólo un habilitador de
servicio puede producir la información de localización y puede envolver las
funciones técnicas vinculadas a la localización.

El vínculo entre los servicios vistos por el usuario

El primer paso es definir claramente qué es un servicio. Se ha investigado mucho
sobre la noción de servicio, no tanto en el ámbito de las TI como en el de las ciencias
económicas y empresariales, tal y como se recoge en Ben Yahia et al. [21]. De forma
genérica, un servicio puede definirse como cualquier acción o actividad empresarial
que tiene un resultado de valor añadido para un usuario (una persona o un sistema).
Esta acción o actividad es ofrecida por un proveedor de servicios (otra persona,
entidad o sistema), que se beneficia de la prestación de esta acción [22,23].
En el ámbito de las telecomunicaciones, el 3GPP define un servicio de
telecomunicaciones como "un componente de la cartera de opciones ofrecidas por
los proveedores de servicios a un , funcionalidad ofrecida a un usuario" [24].
Este estudio se centra en el uso de los servicios, por lo que nos centramos en el
usuario, mientras que el cliente queda fuera del ámbito de los servicios IMS. El
cliente es
14 Manual del subsistema multimedia fP (fM£)

persona u organización que adquiere productos y servicios [25]; el usuario es la

persona (o sistema) que utiliza el servicio y puede ser diferente del cliente. Por
ejemplo, en una familia, el cliente puede ser uno de los padres, y un hijo puede ser el
usuario del servicio adquirido. El cliente suele asignar derechos a los usuarios para
que utilicen los servicios que ha obtenido, y el cliente puede ser un usuario. Aunque
el usuario suele ser una persona, también puede ser otro actor (por ejemplo, otro
proveedor de servicios).
Basándonos en la definición de servicio anterior, proponemos la siguiente
definición para los servicios IMS:

Los servicios IMS son actividades que tienen lugar en interacciones entre un
usuario (es decir, un usuario IMS) y sistemas controlados por proveedores de
servicios (por ejemplo, equipos de usuario IMS, plataformas IMS). Estas
actividades tienen un resultado de valor añadido para el usuario; y los
proveedores de servicios se benefician de la prestación de estas actividades.

En esta definición destacamos dos partes: el usuario y los sistemas controlados por
los proveedores de servicios.
Desde la perspectiva del usuario, el propósito de los servicios IMS es establecer
una sesión de comunicación entre usuarios que se adapte a sus preferencias y
contexto. Las sesiones manipuladas por los servicios IMS pueden ser sesiones de
voz, pero también pueden ser sesiones de vídeo, sesiones de mensajería instantánea
o sesiones de colaboración. El término sesión se refiere aquí únicamente a un
intercambio interactivo entre dos o más personas para comunicarse. Desde la
perspectiva del usuario, un servicio IMS está vinculado a su identidad y no a su
dispositivo de acceso, ya que el usuario puede acceder a los mismos servicios desde
varios dispositivos IMS.
Al utilizar los servicios IMS, el usuario es consciente de que las aplicaciones de
su equipo de usuario o de las plataformas de servicios comparten y reutilizan su
información personal, como la información de presencia, las reglas de
disponibilidad, el perfil personal, la lista de contactos o la información de ubicación.
Un servicio determinado será responsable de la creación y la modificación de cada
tipo de información (por ejemplo, el servicio de presencia para la información de
presencia, el servicio de localización para la información de localización). Así, un
servicio IMS puede consultar la información personal de un usuario (de acuerdo con
las políticas de privacidad) y puede ser responsable de la información definida del
usuario.
La figura 1.5 propone las relaciones de un servicio IMS, una identidad pública de
usuario IMS y la información personal del usuario. Los términos de servicio IMS en
esta figura no nombran un servicio de forma general (por ejemplo, servicio de
presencia), sino que nombran la instancia de servicio de un usuario concreto (por
ejemplo, servicio de presencia de Bob).

Funciones técnicas
Desde la perspectiva técnica de un proveedor de servicios, un servicio se
implementa con funciones técnicas. Las funciones técnicas son las que llevan a cabo
los sistemas controlados por los proveedores de servicios (por ejemplo, plataformas
de servicios, terminales). Como se ha visto antes, la arquitectura de servicios IMS
puede dividirse en varias funciones técnicas. La primera división es entre funciones
de estrato de servicio,
fM£ £ervicio, modelos y conceptos 15

Servicio IMS
* 1

1 -está *
vinculada a * -es responsable de

-
consultar
Identidad pública de usuario IMS Información personal del
usuario
*
1
*

FIGURA 1.5
Enlaces vistos por el .

Función técnica

Estrato de transporte Función Estrato de servicio Función Función de usuario

final

Función de control de Función de aplicación Perfil del usuario

servicio

FIGURA 1.6
Funciones técnicas del IMS.

funciones del estrato de transporte y funciones de usuario final. Como aquí no

tratamos cuestiones de red, nos centraremos únicamente en el estrato de servicio.
Como se ha visto en la primera sección, este estrato de servicio se divide en
funciones de control de servicio, perfiles de usuario de servicio y funciones de
aplicación [2]. Además, hay que tener en cuenta las funciones de usuario final. No
forman parte del estrato de servicios, pero están estrechamente relacionadas para la
prestación de los servicios a través de la interfaz de usuario.
La figura 1.6 clasifica las funciones técnicas IMS (o NGN), de acuerdo con las
normas NGN presentadas en la primera sección. Las funciones de estrato de servicio
son un tipo particular de función técnica. Una función de estrato de servicio puede
ser:
16 Manual del subsistema multimedia fP (fM£)

-utiliza
Servicio IMS Función técnica
*
* *

-consultar
*
Información personal del usuario
*

-es responsable de

FIGURA 1.7
Servicio IMS.

• una función de control de servicios que se encarga de funciones de control

comunes como el control de establecimiento de sesión o el control de
activación de servicios;
• una función de aplicación que contiene la lógica de servicio y las reglas de
manipulación para el establecimiento de sesiones (por ejemplo,
transferencias, devolución de llamada, accesibilidad, registro de llamadas);
• un perfil de usuario del servicio que almacena la información sobre las
identidades de los usuarios y sobre la activación del servicio; y
• una función de usuario final que incluye no sólo la conexión al IMS
(mediante protocolos SIP y portador), sino también la parte de interfaz de
servicio que reside en el dispositivo cliente. Esta interfaz realiza la trans-
formación de los mensajes técnicos de las funciones de aplicación en algo
utilizable por el usuario (y viceversa) y proporciona así al usuario final la
capacidad de iniciar y participar en una sesión. Por ejemplo, una interfaz de
presencia transformará los mensajes de los protocolos de presencia en una
interfaz de usuario que muestre la presencia de los contactos del usuario.

Relación entre servicio y función técnica

Un servicio IMS es la unión entre la información personal del usuario y las
funciones técnicas. Para ilustrarlo en la figura 1.7, podemos considerar el ejemplo de
un servicio de presencia IMS. El servicio de presencia es visto por el usuario como
la notificación de información de presencia entre un consumidor de información de
presencia y fuentes de información de presencia, donde la información de presencia
es un conjunto de atributos que caracterizan las propiedades actuales de las fuentes
(como el estado o la dirección de comunicación) [17]. El servicio de presencia se
lleva a cabo con funciones técnicas tales como clientes de presencia de usuario final
(un cliente fuente de presencia y un cliente observador de presencia), mecanismos
de control de servicio para enrutar
fM£ £ervicio, modelos y conceptos 12

(los mensajes SIP SUBSCRIBE, PUBLISH y NOTIFY) y servidores de aplicaciones de

presencia (para procesar el estado de presencia de las fuentes de presencia y
almacenarlo y enviarlo a los observadores que se han suscrito a este evento de
presencia).
Los servicios son directamente responsables de la información personal del
usuario y utilizan directamente las funciones técnicas. Como ya se ha mencionado,
esto puede llevar a crear una arquitectura de silos, en la que cada servicio depende
de sus propias funciones técnicas. Los habilitadores de servicio (o capacidades de
soporte de servicio o capacidades de servicio) están diseñados para abordar este
problema centrándose únicamente en sus funciones intrínsecas. Esto significa que
no debe haber solapamiento entre los habilitadores de servicio, tanto desde la
perspectiva del usuario como desde la perspectiva de las funciones técnicas.
La ausencia de solapamiento desde la perspectiva del usuario implica que
distintos facilitadores de servicios no deben ser responsables del mismo tipo de
información personal del usuario. Por ejemplo, solo un habilitador de servicios
puede producir la de presencia y solo un habilitador de servicios puede producir la
información de localización.
La ausencia de solapamiento desde el punto de vista de las funciones técnicas
implica que los distintos habilitadores de servicios no deben utilizar las mismas
funciones IMS de forma incoherente. Por ejemplo, solo el habilitador del servicio de
presencia puede procesar los mensajes de presencia y almacenar el estado de
presencia, y solo el habilitador del servicio de localización puede procesar y agregar
la localización del usuario a partir de varias fuentes de localización.
En la arquitectura de servicios IMS, los servicios IMS tienen que depender en la
medida de lo posible de los habilitadores de servicios IMS. Estos habilitadores de
servicios IMS envuelven un conjunto de funciones técnicas y proporcionan una
interfaz de servicio coherente a los servicios IMS. Un servicio IMS también puede
utilizar directamente algunas funciones técnicas (por ejemplo, un servidor de
aplicaciones dedicado a un servicio específico). Además, sólo los habilitadores de
servicios IMS deben ser responsables de la información personal del usuario (figura
1.8).

Ejemplo de Push-to-Talk sobre celular

Para ilustrar este modelo, lo aplicamos aquí al servicio push-to-talk over cellular
(PoC) descrito en el programa de lanzamiento y especificaciones de la OMA [27].
El servicio PoC es un servicio de tipo walkie-talkie que permite comunicaciones
rápidas, cortas y espontáneas. Es un servicio de voz semidúplex que permite
comunicaciones de persona a persona y de persona a grupo. Este servicio se
considera un ejemplo temprano de aplicación de IMS en el mercado. Dado que la
PdC se especifica como servicio y como habilitador, mostramos la distinción entre
el servicio percibido por el usuario y los bloques funcionales de construcción del
servicio.
Esto ilustra la separación entre lo que ve el usuario, el habilitador del servicio y
las funciones técnicas que implementan estos habilitadores.
18 Manual del subsistema multimedia fP (fM£)

* -utiliza

* -
1 envuel Función técnica
-utiliza
Servicio IMS Habilitador de *
* * servicios IMS *
* *

-requiere
1 *
-consultar * -
consultar *
* Información personal del
usuario
-es responsable de

FIGURA 1.8
Servicios IMS y habilitadores de servicios.

Esta separación beneficiará a los proveedores de servicios en todo el ciclo de vida del
servicio, especialmente en su composición, interacción y gestión.

El servicio PoC visto desde la perspectiva del usuario

Desde la perspectiva del usuario, una sesión PoC típica es la siguiente:

El usuario PoC abre su lista de contactos, donde las características de presencia

indican si los contactos o grupos de contactos están disponibles o no. El usuario
selecciona uno o varios contactos de su lista de contactos, crea un grupo de PdC
con estos contactos, inicia el servicio de PdC y, a continuación, habla
simultáneamente con todos los contactos de su grupo de PdC.

Esta sesión básica muestra que el servicio PdC se basa en la identidad del usuario,
que es necesaria para acceder a la lista de contactos e invitar a otros usuarios PdC a
participar en una sesión. Además de la identidad, desde la perspectiva del usuario, el
servicio PdC utiliza:

• información de presencia para conocer la disponibilidad y localizabilidad

de los contactos;
• listas de contactos para crear grupos para las sesiones de PdC; y
• perfiles de usuario.

La figura 1.9 muestra el servicio PoC visto por el usuario "Bob Smith". Esta vista
contiene la información que posee el usuario y que se reutiliza en el servicio PoC.
Su información personal podría reutilizarse como en otro servicio IMS.
fM£ £ervicio, modelos y conceptos 19

Otro servicio de Bob : Servicio IMS PoC Servicio de Bob : Servicio IMS

Identidad Bob : Identidad pública de usuario

IMS

Perfil de Bob : Información personal del Lista de contactos de Bob : Información personal
usuario del usuario

Bob Presence Information : Información personal del usuario

FIGURA 1.9
El servicio PoC visto por "Bob Smith".

Servicio PoC y habilitadores de servicio

Como se describe en las especificaciones OMA, el servicio PoC requiere varios
habilitadores de servicio que realizan acciones específicas y son responsables de
información específica:

• habilitador push-to-talk sobre celular [27] que gestiona la lógica de servicio

del servicio PoC;
• XDM (XML document management) enabler [28] para gestionar los
grupos de con- tacto en particular;
• facilitador de la presencia [29];
• habilitador IMS [30] para apoyar el servicio; y
• habilitador de gestión de dispositivos [31].

Las dependencias entre el servicio PdC y los habilitadores de servicios, así como entre
los habilitadores de servicios, se describen en la figura 1.10 con flechas de puntos.
Cada facilitador de servicios es responsable de algún tipo de información personal.

Funciones técnicas para el servicio PoC

Como ya se ha mencionado, cada habilitador de servicio se implementa y lleva a
cabo a través de un conjunto de funciones técnicas que se muestran en la Figura
1.11. En esta sección dividimos cada habilitador en sus correspondientes funciones
técnicas.
El habilitador de gestión de documentos XML (XDM) se implementa con un
cliente XDM (XDMC), un servidor XDM compartido (XDMS compartido) y un proxy
de agregación. El XDMC es un cliente XCAP (protocolo de acceso a la configuración
XML).
 20
Perfil de Bob : Información personal del Lista de contactos de Bob : Información personal del
usuario usuario

PoC de OMA: Habilitador de servicios

IMS

OMA XDM : Habilitador de servicios IMS

IMS en OMA : Habilitador de servicios

PoC Servicio de Bob : Servicio IMS
IMS

Manual del subsistema multimedia fP (fM£)

Bob Presence Simple : Habilitador de servicios IMS

Gestión de dispositivos OMA: habilitador de servicios IMS

Bob Presence Information : Información personal del usuario

FIGURA 1.10
Habilitadores de servicio para el servicio PoC.
fM£ £ervicio, modelos y conceptos 21

Servidor DM

Cliente DM
Servidor
de
presenci XDMS
Presencia compar
a
Fuente tido

Proxy de

Núcleo SIP/IP
agregació
Observad n
or

XDMC PoC XDMs

PoC Abonado/Usuario
Servidor
Cliente PoC PoC

UE

FIGURA 1.11
Funciones técnicas del servicio PdC (simplificadas).

que da acceso a los documentos XML almacenados en la red (por ejemplo,

documentos específicos del PdC en el XDMS del PdC, listas de contactos en el XDMS
compartido). El proxy de agregación actúa como único punto de contacto para el
XDMC. Realiza la autenticación del XDMC y enruta las solicitudes XCAP individuales al
XDMS correcto. El XDMS compartido es un servidor XCAP que gestiona documentos
XML (por ejemplo, listas de contactos) que se comparten con otros habilitadores de
servicios (por ejemplo, presencia).
El habilitador PoC se implementa en una parte cliente, una parte servidor y un
servidor XDM específico PoC. El cliente PoC reside en el terminal y se utiliza para
acceder al servicio PoC. El servidor PoC implementa la lógica de aplicación para el
servicio PoC. El servidor XDM específico del PoC es un servidor XCAP, que gestiona
documentos XML específicos del servicio PoC (por ejemplo, grupos PoC).
El activador de presencia se implementa en un servidor de presencia, una fuente
de presencia y un observador. Un servidor de presencia es una entidad que acepta,
almacena y distribuye información de presencia sobre clientes PoC. Una fuente de
presencia es una entidad que proporciona (publica) información de presencia, y un
observador es una entidad que recibe notificaciones de la información de presencia.
El habilitador IMS incluye una serie de proxies SIP y registradores SIP. Realiza
funciones como la autenticación, la autorización del usuario PoC o el mantenimiento
del estado de registro.
El habilitador de gestión de dispositivos se implementa con un cliente de gestión
de dispositivos que recibe los parámetros iniciales que necesita el proveedor de
servicios para el cliente PoC y un servidor de gestión de dispositivos que inicializa
toda la configuración y las actualizaciones necesarias para el cliente PoC.
22 Manual del subsistema multimedia fP (fM£)

Todas las funciones técnicas aquí descritas pertenecen al estrato de los servicios.
Son, por tanto, funciones de usuario final, funciones de control de servicios o
funciones de aplicación. El cliente PoC, el cliente de gestión de documentos XML,
la fuente de presencia, el observador y el cliente de gestión de dispositivos son
funciones de usuario final. El núcleo IMS es una función de control de servicios. El
servidor PoC, el servidor PoC de gestión de documentos XML, el proxy de
agregación, el servidor de documentos XML compartidos, el servidor de presencia y
el servidor de gestión de dispositivos son funciones de aplicación.

Una visión completa de los servicios IMS

La figura 1.12 es un ejemplo de los tres habilitadores OMA XDM, IMS en OMA y SIMPLE
de presencia OMA. Define las dependencias adecuadas de estos tres habilitadores y
con los servicios que hacen uso de estos habilitadores. Tomamos aquí los ejemplos
del servicio PoC y de un servicio de mensajería instantánea. No se representan todos
habilitadores utilizados por estos servicios para simplificar la figura.

Conclusión
Los servicios IMS no pueden considerarse independientemente de todo el entorno
de servicios del usuario [32]. Este entorno incluye al menos elementos como la
gestión de identidades, la gestión de comunidades, la gestión de la disponibilidad o
la gestión del contexto. Este entorno de servicio debe ser capaz de integrar
elementos de servicio de terceros. El valor del servicio residirá en la calidad de las
interacciones entre todos los elementos del servicio y en accesibilidad sin fisuras
centrada en el usuario. Por lo tanto, se necesita un marco de control de servicios que
gestione estas interacciones para las interacciones entre los servicios del operador y
para la intermediación con otros proveedores de servicios. Este marco debe basarse
en un modelado común de servicios, habilitadores de servicios y recursos.
El principal interés del enfoque propuesto reside en la identificación de las
dependencias entre los servicios y los habilitadores de servicios. Esto permite un
mejor diseño de los servicios IMS al definir claramente qué habilitador de servicio
está implicado en cada servicio y cómo un habilitador de servicio está vinculado a
las funciones técnicas. Este enfoque optimiza el tratamiento de la interacción de
servicios entre los habilitadores de servicios IMS rastreando el impacto en la
percepción del servicio por parte del usuario. También mejorará los aspectos de la
gestión de servicios al detectar cómo el fallo de una o varias funciones técnicas
puede afectar a los habilitadores de servicios y al uso del servicio IMS. Es una
herramienta para identificar la información personal del usuario que debe
compartirse entre servicios, definir qué habilitador de servicios es responsable de
qué información y, a continuación, diseñar servicios que reutilicen esta información
personal a través de estos habilitadores de servicios.
 fM£ £ervicio, modelos y conceptos
Servidor de gestión de documentos XML compartidos : Función de aplicación

Cliente de gestión de documentos XML : Función de usuario final

Servicio de mensajería instantánea de Bob : Servicio
IMS
OMA XDM : Habilitador de servicios Proxy de agregación : Función de aplicación
PoC Servicio de Bob : Servicio IMS IMS

IMS Core : Función de control del servicio

IMS en OMA : Habilitador de servicios IMS

Observador : Función de usuario

final
OMA Presence SIMPLE : Habilitador de servicios IMS

Presencia Fuente : Usuario final Función

Bob Presence Information : Información personal del usuario

Servidor de presencia : Función de

aplicación

FIGURA 1.12
Relación y dependencias de XDM, IMS y habilitadores de servicios simples de presencia.

23
24 Manual del subsistema multimedia fP (fM£)

Glosario
3GPP Proyecto de Asociación de 3ª Generación
API interfaz de programación de aplicaciones
AS servidor de aplicaciones
CSCF funciones de control del estado de la llamada
DSL línea de abonado digital
GSM sistema global para comunicaciones móviles
GUI interfaz gráfica de usuario
HSS servidor de abonado doméstico
IETF Grupo de Trabajo de Ingeniería de Internet
iFC criterios de filtrado iniciales
IMS Subsistema multimedia IP
EN red inteligente
INAP protocolo de aplicación de red inteligente
RDSI red digital de servicios integrados
ISUP Parte de usuario RDSI
TI tecnología de la información
UIT Unión Internacional de Telecomunicaciones
NGN Redes de próxima generación
OMA Alianza Móvil Abierta
OSE Entorno de servicio OMA
RTPC red telefónica pública conmutada S-
CSCF funciones de control del estado de la
llamada de servicio SIB bloque de construcción
independiente del servicio
SIP protocolo de inicio de sesión
SIM módulo de identidad del abonado
SPT desencadenante del punto de servicio
TISPAN servicios y protocolos convergentes de telecomunicaciones e
Internet para redes avanzadas
UMTS sistema universal de telecomunicaciones móviles
WLAN red de área local inalámbrica
XML lenguaje de marcado extensible
TMF Foro de telegestión

Referencias
1. Arbanowski, S. et al. 2004. I-centric communications: Personalización, conciencia
ambiental y adaptabilidad para futuros servicios móviles. IEEE Communications
Magazine 42(9):63-69.
fM£ £ervicio, modelos y conceptos 25

2. Knightson, K., N. Morita y T. Towle. 2005. Arquitectura de las NGN: Generic prin -
ciples, functional architecture, and implementation. IEEE Communications Mag- azine
43(10):49-56.
3. 3GPP. Subsistema multimedia IP (IMS), TS 23.228.
4. Bertin, E., E. Bury y P. Lesieur. 2003. Operator services deployment with SIP: Wireline
feedback and 3GPP perspectives. ICIN 2003, Burdeos, abril de 2003.
5. Schulzrinne, H., y J. Rosenberg. 1999. Telefonía por Internet: Architecture and protocols-An
IETF perspective. Redes informáticas y sistemas RDSI 31(3):237-255.
6. Tang, B. Y. C. 2005. Evolving to wireless and wireline convergence-An over- view of
IMS. Comunicaciones inalámbricas y ópticas, 2005. 14th Annual WOCC 2005, 27, 22-
23 de abril.
7. Márquez, F. G., M. G. Rodríguez, T. R. Valladares, T. de Miguel y L. A. Galindo. 2005.
Interworking of IP multimedia core networks between 3GPP and WLAN. IEEE Wireless
Communications 12(3):58-65.
8. Lin, F. J. 2005. A survey on wireless/wireline integration. Comunicaciones inalámbricas y
ópticas, 2005. 14th Annual WOCC 2005, 26, 22-23 de abril.
9. 3GPP. IP multimedia session handling; IM call model, TS 23.218.
10. Schilit, B. N., D. M. Hilbert y J. Trevor. 2002. Context-aware communication.
IEEE Wireless Communications 9(5):46-54.
11. Raento, M., A. Oulasvirta, R. Petit, y H. Toivonen, H. 2005. ContextPhone: A
prototyping platform for context-aware mobile applications. IEEE Pervasive Computing
4(2):51-59.
12. Bertin, E., E. Bury y P. Lesieur. 2002. Arquitecturas de nueva generación: ¿Qué
funciones debe desempeñar un operador tradicional? Actas de la Cumbre Eurescom
2002.
13. Bertin, E., E. Bury y P. Lesieur. 2004. Intelligence distribution in next-gen- eration
networks, an architectural framework for multimedia services. IEEE International
Conference on Communications, ICC 2004, París.
14. Gouya, A., N. Crespi y E. Bertin. 2006. SCIM (gestor de interacción de capacidad de
servicio). Implementation issues in IMS service architecture. IEEE International Conference
on Communications, Estambul.
15. Carugi, M., B. Hirschman y A. Narita. 2005. Introduction to the ITU-T NGN focus group
release 1: Target environment, services, and capabilities. IEEE Communications Magazine
43(10):42-48.
16. OMA. Entorno de servicio de OMA. Versión aprobada 1.0.4, 01 Feb 2007, OMA-AD-
Service-Environment-V1_0_4-20070201-A.
17. 3GPP. Servicio de presencia utilizando el subsistema de red central (CN) IP multimedia
(IM); TS 24.141.
18. 3GPP. Mensajería utilizando el subsistema de red central (CN) IP multimedia (IM); TS
24.247.
19. 3GPP. Conferencing using the IP multimedia (IM) core network (CN) subsys- tem; TS
24.147.
20. OMA. Diccionario para especificaciones OMA. Versión aprobada 2.6, junio de 2007, OMA-
ORG-Dictionary-V2_6-20070614-A.
21. Ben Yahia, I., E. Bertin, N. Crespi y J. P. Deschrevel. 2006. Service definition for next-
generation networks. Conferencia Internacional sobre Redes. ICN 2006, Mauricio.
22. Lovelock, C. 2001. Services marketing, people, technology, strategy, 4ª ed., Engle- wood Cliffs,
NJ: Prentice Hall. Engle- wood Cliffs, NJ: Prentice Hall.
26 Manual del subsistema multimedia fP (fM£)

23. Grönroos, C. 2000. Gestión de servicios y marketing: A customer relationship management

approach, 2ª ed., Madrid. Chichester, Reino Unido: John Wiley & Sons.
24. 3GPP. 2005. Definición 3GPP, TR 21.905, V6.7.0.
25. Foro TMF. Modelo de información y datos compartidos (SID). GB922 y addenda,
versión 7, enero de 2007.
26. Keck, D. O., y P. J. Kuehn. 1998. El problema de la interacción entre características y
servicios en los sistemas de telecomunicaciones: A survey. IEEE Transactions on Software
Engi- neering 24(10):779-796.
27. OMA. OMA push to talk over cellular (PoC). Habilitador aprobado versión 1.0.2,
septiembre de 2007.
28. OMA. Gestión de documentos XML de la OMA. Habilitador aprobado versión 1.0.1,
noviembre de 2006.
29. OMA. OMA presence simple. Habilitador aprobado versión 1.0.1, noviembre de 2006.
30. OMA. IMS en OMA. Habilitador aprobado versión 1.0, septiembre de 2005.
31. OMA. Gestión de dispositivos OMA. Habilitador aprobado versión 1.2, febrero de 2007.
32. Ryu, S. et al. 2005. Research activities on next-generation mobile communica- tions and
services in Korea. IEEE Communications Magazine 43(9):122-131.
2
fM£-Una arquitectura segura
para todas las redes fP

Muhammad Sher y Thomas Magedanz

CONTENIDO
Introducción .........................................................................................................................28
Visión general de la arquitectura IMS .................................................................................29
Retos y posibles ataques a la seguridad de IMS ............................................................. 32
Mecanismos de seguridad IMS y asociaciones de seguridad ........................................35
Autenticación IMS, gestión de claves y secreto ............................................................. 39
Autenticación IMS y gestión de claves .................................................................. 39
Cifrado y secreto ....................................................................................................... 41
Uso de IPsec ESP para la protección de la confidencialidad e integridad
de SIP........................................................................................... 43
Procedimiento de integridad y confidencialidad del SIP ....................... 44
Seguridad entre dominios ..................................................................................................45
Arquitectura de seguridad de dominio de red (NDS) ...........................................47
Uso de IPsec en un entorno NDS/IP ......................................................................50
Infraestructura de clave pública (PKI) ...................................................................53
Marco de autenticación NDS basado en PKI ...........................................................55
Gestión de seguridad para servicios basados en HTTP......................................................59
Arquitectura de arranque genérica (GBA).............................................................59
Procedimiento de autenticación de arranque ......................................................... 62
Procedimiento de uso de Bootstrapping ................................................................ 64
Uso del proxy de autenticación para servicios multimedia ................................ 64
Referencias ........................................................................................................................... 67

27
28 Manual del subsistema multimedia fP (fM£)

Introducción
La convergencia fijo-móvil (FMC) y las redes de voz-datos han fusionado
aplicaciones de valor añadido de nueva generación y servicios multimedia
integrados, combinando navegación web, mensajería instantánea, presencia, voz
sobre protocolo de Internet (VoIP), videoconferencia, aplicaciones compartidas,
telefonía, mensajería unificada, entrega de contenidos multimedia, etc. sobre
diferentes tecnologías de red. El 3GPP (3rd Generation Partnership Project) [1] y el
3GPP2 [2] han desarrollado el subsistema multimedia IP (IMS) [3] para
proporcionar una plataforma de prestación de servicios (SDP) para un paradigma de
comunicación convergente. Sin duda, la convergencia de las redes de voz y datos es
un gran logro para mantener una única plataforma de comunicación para todos, pero
el mayor reto es mantener un nivel adecuado de seguridad en el entorno de red
heterogéneo para proteger múltiples tecnologías y protocolos y proporcionar
confidencialidad y protección de los datos.
Otro avance importante en el paradigma de las redes convergentes es la
introducción del IP como capa de red en GPRS (servicio general de radio por
paquetes) y en el UMTS (sistema universal de telecomunicaciones móviles). La
arquitectura de red basada en IP ofrece interfaces abiertas y flexibles para desplegar
servicios innovadores. En términos de seguridad, esto implica una serie de nuevas
amenazas y riesgos heredados del mundo de Internet.
El IMS también es vulnerable a distintos ataques entre iguales porque los usuarios
están siempre conectados y en línea. Las posibles razones de los ataques pasivos y
activos en IMS son que un atacante podría acceder fácilmente a un enlace
inalámbrico, lanzar una estación falsamente basada y redirigir ataques para
interceptar y redirigir la información confidencial de un usuario a otro lugar.
IMS utiliza SIP (protocolo de iniciación de sesión) [4] para la señalización, que es de
arquitectura abierta y vulnerable a diferentes ataques, como se analiza en Calhoun et
al. [5]. Entre las principales amenazas de IMS se encuentran los ataques de
inundación, que en última instancia mantienen ocupados los recursos de la red y,
como resultado, estas fuentes no están disponibles para los usuarios legítimos. Los
servidores de aplicaciones IMS (AS) también son objetivos valiosos para los
intrusos porque proporcionan servicios de valor añadido. Debido a la naturaleza
basada en texto de SIP, el IMS y el AS son vulnerables a ataques como la
suplantación de identidad, el secuestro y la manipulación de mensajes. Además, el
AS puede sufrir amenazas basadas en HTTP. Por último, los intrusos pueden lanzar
ataques de denegación de servicio (DoS) contra las aplicaciones instaladas en el AS.
Para minimizar el riesgo de robo de información y datos por parte de piratas
informáticos, tenemos que centrarnos en un marco de seguridad independiente para
IMS. Según las especificaciones y normas técnicas del 3GPP, la seguridad IMS
ofrece dos soluciones con distintos niveles de protección:

1. La solución de seguridad IMS temprana estandarizada en la versión 5 de

3GPP proporciona una funcionalidad de seguridad limitada y tiene como
objetivo proteger el despliegue temprano de IMS y ofrece menos
seguridad. Proporciona autenticación de
fM£-Una arquitectura segura para todas las redes fP 29

abonados para el acceso a los servicios y la confidencialidad de la

identidad en la interfaz de radio. También proporciona cifrado de la
interfaz de radio.
2. La solución completa de seguridad IMS está estandarizada en la versión 6
de 3GPP con todas las funciones de seguridad y se basa en las primeras
soluciones de seguridad con el objetivo de mejorarlas. Ofrece nuevas
funciones de seguridad y asegura nuevos servicios para proteger redes y
terminales con protección de datos.

Este capítulo presenta una visión general de IMS y aborda los posibles ataques a
IMS. Presenta una visión general de la arquitectura de seguridad IMS y las
asociaciones de seguridad, así como la autenticación de claves, la generación de
claves y el uso de claves para proporcionar confidencialidad e integridad. Más
adelante, analiza la seguridad entre dominios y presenta la seguridad de los servicios
IMS basados en HTTP. Por último, presenta la ampliación de la seguridad para
nuevas amenazas.

Visión general de la arquitectura IMS

El IMS [3] proporciona SDP para la prestación de servicios multimedia móviles,
como VoIP, videotelefonía, conferencias multimedia, contenidos móviles y push-to-
talk. Se basa en protocolos de Internet Engineering Task Force (IETF) como SIP [4],
DIAMETER [8], SDP, protocolo de transporte en tiempo real (RTP) y protocolo de
control de transferencia (TCP)/pila de protocolos IP. El IMS se considera el marco
de la plataforma de prestación de servicios de próxima generación. Consiste en un
diseño modular con interfaces abiertas y permite la flexibilidad para proporcionar
servicios multimedia sobre tecnología IP. El IMS no estandariza servicios
específicos, sino que utiliza habilitadores de servicios estándar (por ejemplo,
presencia) y soporta intrínsecamente multimedia y VoIP.
En la arquitectura IMS, se utiliza el protocolo SIP [4] como protocolo de
señalización estándar que establece, controla, modifica y finaliza las sesiones de
voz, vídeo y mensajería entre dos o más participantes. Los servidores de
señalización relacionados en la arquitectura se denominan funciones de control del
estado de la llamada (CSCF) y se distinguen por sus funcionalidades específicas. La
funcionalidad relacionada con la autenticación, autorización y contabilidad (AAA)
dentro del IMS se basa en el protocolo DIAMETER del IETF [6] y se implementa
en el sistema de abonado de origen (HSS), las CSCF y otros componentes del IMS
para permitir la funcionalidad de tarificación dentro del IMS. En lugar de desarrollar
el protocolo desde cero, DIAMETER se basa en el Servicio de Autenticación
Remota de Marcado de Usuario (RADIUS) [7], que se ha utilizado previamente para
proporcionar servicios AAA para servidores de marcación y terminales en distintos
entornos.
El otro protocolo importante para los contenidos multimedia es el protocolo de
transporte en tiempo real (RTP) [8], que proporciona entrega de extremo a extremo para
datos en tiempo real. También contiene servicios de entrega de extremo a extremo
como el tipo de carga útil (códec)
30 Manual del subsistema multimedia fP (fM£)

Parlay X
SIP AS GW
XDMS Carga de presencia

Núcleo IMS Sh

HSS ISC
Cx Plataforma de aplicaciones
Cx IMS

Mw
I-CSCF S-CSCF Mw
Mw
Mw
Mw Señalización GW

P-CSCF
Media GW
Gm

Servidor
multimedia Legado
redes GSM,
RTPC

Clientes de
IMS

FIGURA 2.1
Arquitectura IMS.

RTP permite la identificación, numeración secuencial, sellado de tiempo y

monitorización de datos en tiempo real. El RTP proporciona monitorización de la
calidad de servicio (QoS) mediante el protocolo de control RTP (RTCP) [9], que
transmite información sobre los participantes en la sesión multimedia.
Las entidades y funcionalidades clave de IMS pueden clasificarse en seis catego-
rías [10]: familia de gestión de sesiones y enrutamiento (CSCF), bases de datos
(HSS, SLF), elementos de interfuncionamiento (BGCF, MGCF, etc.), servicios (servidor de
aplicaciones, MRCF, MRFP), entidades de soporte (THIG, pasarela de seguridad
[SEG], PDF) y tarificación. Los componentes y partes más importantes de la
arquitectura IMS (mostrada en la Figura 2.1) se describen a continuación:

La función proxy de control del estado de la llamada (P-CSCF) es el primer punto de

contacto dentro de la red central multimedia IP; todo el tráfico de
señalización SIP desde o hacia el equipo de usuario (UE) pasa por la P-
CSCF. Su dirección es des- cubierta por el UE tras la activación del contexto
del protocolo de paquetes de datos (PDP). La P-CSCF se comporta como un
proxy, aceptando y reenviando tráfico SIP.
fM£-Una arquitectura segura para todas las redes fP 31

de las solicitudes y respuestas. Realiza funciones como la autorización de

los recursos portadores para el nivel de calidad de servicio adecuado,
llamadas de emergencia, supervisión, (des)compresión de cabeceras e
identificación de I-CSCF.
La función de control del estado de la llamada de interrogación (I-CSCF) es el primer
punto de contacto dentro de la red de un operador. Se pone en contacto con el HSS
para obtener la dirección de la S-CSCF y atender al usuario para el registro.
Reenvía las solicitudes y respuestas SIP a la S-CSCF. También oculta la
topología de la red.
La función de control del estado de la llamada de servicio (S-CSCF) realiza los
servicios de control de sesión para el punto final y mantiene el estado de la
sesión según lo necesite el operador de red para dar soporte a los servicios.
Dentro de la red de un operador, diferentes S-CSCF pueden tener diferentes
funcionalidades. Entre las funciones importantes que realiza la S-CSCF se
incluyen el registro de usuarios/interacción con plataformas de servicios
para el soporte de servicios. La S-CSCF decide si es necesario que un AS
reciba información relacionada con una solicitud de sesión SIP entrante
para garantizar una gestión adecuada del servicio. La decisión de la S-
CSCF se basa en la información de filtrado recibida del HSS [10]. Esta
información de filtro se almacena y transmite por cada servidor de
aplicación para cada usuario.
Home subscriber server (HSS) es el equivalente del HLR (home location register) en
los sistemas 2G, pero ampliado con dos puntos de referencia basados en
DIAMETER. Es la base de datos maestra de un IMS que almacena los
perfiles de usuario IMS, incluida la información de filtrado individual, la
información de estado del usuario y los perfiles del servidor de
aplicaciones.
El servidor de aplicaciones (AS) proporciona plataformas de servicios en entornos
IMS. No se ocupa de cómo se programan las aplicaciones multimedia/de
valor añadido; sólo admite inter- faces de señalización y administración
bien definidas (control de servicios IMS [ISC] y Sh) y protocolos SIP y
DIAMETER. Esto permite a los desarrolladores utilizar casi cualquier
paradigma de programación dentro de un SIP AS, como servidores de red
inteligente heredados (es decir, entornos de soporte CAMEL);
servidores/gateways de acceso a servicios abiertos (OSA)/Parlay; o
cualquier paradigma de pro- gramación VoIP SIP probado como servlets
SIP, lenguaje de programación de llamadas (CPL) y scripts de interfaz de
pasarela común (CGI) [11]. El SIP AS es activado por la S-CSCF, que
redirige ciertas sesiones al SIP AS basándose en los criterios de filtrado
descargados o solicitando información de filtrado al HSS en un paradigma
basado en el usuario. El SIP AS comprende reglas de filtrado para decidir
cuál de las aplicaciones desplegadas en el servidor debe seleccionarse para
gestionar la sesión. Durante la ejecución de la lógica de servicio, también es
posible que el SIP AS se comunique con el HSS para obtener información
adicional sobre un o para ser notificado sobre cambios en el perfil del
abonado [12].
La función de recursos de medios (MRF) puede dividirse en controlador de función
de recursos de medios (MRFC) y procesador de función de recursos de
medios (MRFP).
32 Manual del subsistema multimedia fP (fM£)

Proporciona recursos de procesamiento de flujos de medios como mezcla

de medios, anuncios de medios, análisis de medios y transcodificación de
medios, así como voz [10]. Los otros tres componentes son la función de
control de pasarela fronteriza (BGCF), la función de control de pasarela de
medios (MGCF) y la pasarela de medios (MG), que realizan el
interfuncionamiento de portadores entre RTP/IP y los portadores utilizados
en las redes heredadas.
El sistema de usuario final IMS proporciona el soporte de protocolo IMS
necesario, en concreto SIP, y los códecs de medios relacionados con el
servicio para las aplicaciones multimedia, además del soporte de
conectividad básico (por ejemplo, GPRS, red de área local inalámbrica
[WLAN]).

Retos y posibles ataques a la seguridad de IMS

Los retos de seguridad a los que se enfrenta IMS son amenazas de diferentes proto-
colos de dominio, por ejemplo, ataques de señalización SIP, ataques de medios RTP
y ataques de dominio IP. Algunos de los posibles ataques IMS se identifican en la
referencia 13. Los retos de seguridad del IMS son los ataques DoS, las amenazas de
la infraestructura IP de base abierta y los ataques a la señalización SIP y al flujo de
medios, tal y como se muestra en la Figura 2.2. Estas amenazas se resumen de la
siguiente manera: ataques a los medios RTP, ataques a la señalización SIP y ataques
al flujo de medios RTP. Estas amenazas se resumen a continuación:

Ataque de denegación de servicio (DoS): Bloquea las señales de radio e

inunda con solicitudes de autenticación la P-CSCF y otros dispositivos. Por
ejemplo, en un ataque de inundación REGISTER, el atacante envía muchas
solicitudes REGIS- TER a la P-CSCF con direcciones de origen falsas o
suplantadas (por ejemplo, SIP URI [identificador uniforme de recursos]).
En el caso de la inundación distribuida de REGISTROS, el atacante genera
múltiples solicitudes de REGISTRO con diferentes direcciones de origen
falsas para sobrecargar los recursos IMS. Esto provoca la caída de los
recursos IMS y los usuarios legítimos no pueden obtener los servicios.
Ataque de suplantación de identidad: El nodo malicioso oculta su presencia
en la red e intercepta el tráfico, y los atacantes manipulan los mensajes.
Estos nodos se convierten en nodos de confianza en IMS.
Ataque Man-in-the-middle: Los piratas informáticos buscan las brechas y
rompen el proceso de autenticación y el proceso de protección de la
integridad con el fin de obtener servicios IMS de forma gratuita.
Suplantación de identidad: La suplantación de un servidor provoca el desvío
de mensajes. Los procesos de autenticación existentes son incapaces de
diferenciar entre el intruso y el usuario legítimo. De este modo, el atacante
tiene libre acceso a los servicios IMS y a la víctima se le cobra por el uso
que el atacante hace de los servicios.
fM£-Una arquitectura segura para todas las redes fP 33

Ataques SIP
Ataques RTP

Invitar Jitter Attack

Inundación Núcleo del subsistema Session Tear Down
Registrar multimedia IP abierto Modificación de la
Inundación (IMS) sesión
Respuesta I/R Secuestro de sesión
Inundación
Inyección SQL
Ataque de
cancelación Ataque
de referencia

Ataques a las capas de transporte

e IP Inundación TCP SYN
Inundación ACK
Ataque pitufo

FIGURA 2.2
Amenazas potenciales del IMS.

Espionaje: Los hackers obtienen información de la sesión si los mensajes se

envían en texto claro y pueden lanzar fácilmente diversos ataques de
secuestro a partir de la información de la sesión.
Ataque de adivinación de contraseña: Es como un ataque de secuestro de sesión con
el objetivo de obtener información de la sesión del usuario. Incluso si un
intruso no es capaz de romper el proceso de autenticación IMS, puede
lanzar ataque de adivinación de contraseña para hacer un uso indebido de
las cuentas legítimas de los usuarios. El intruso lanza este ataque enviando
muchas peticiones REG- ISTER a la P-CSCF y recibe mensajes 401-no
autorizado del núcleo IMS. El atacante podría obtener respuestas 200 OK
en un ataque con éxito.
Inyección SQL: Este es un tipo de ataque de manipulación de mensajes; la naturaleza
basada en texto de los mensajes SIP proporciona una oportunidad para
ataques de manipulación de mensajes en IMS. Este ataque no sólo se dirige
a la modificación de datos, sino que también causa DoS por colapso de los
servicios de base de datos. La utilización de una interfaz Web para la
prestación de servicios de valor añadido hace que IMS sea más vulnerable
a este tipo de ataque. La inyección SQL podría lanzarse simplemente
insertando una sentencia SQL cuando el UE y la P-CSCF inician los
procedimientos de autenticación. La petición inicial REGIS- TER del UE
utiliza la cabecera de autorización HTTP digest [14] para transportar las
identidades de los usuarios. Cuando un usuario malintencionado intenta
lanzar una inyección SQL en IMS, falsifica el mensaje SIP e inserta
34 Manual del subsistema multimedia fP (fM£)

el código SQL malicioso en su cabecera de autorización. Cuando la P-

CSCF recibe un mensaje SIP con una cabecera de autorización infectada,
genera y ejecuta la sentencia SQL ilegítima, que puede borrar datos de la
base de datos [15]. Las soluciones existentes no proporcionan mitigación
contra este ataque. El IMS también integra el contenedor HTTP servlet; por
lo tanto, un atacante también puede utilizar el mensaje HTTP para lanzar
ataques de inyección SQL.
Ataque de terminación de sesión multimedia: La petición BYE se utiliza para
terminar una sesión establecida. Un atacante podría utilizar la solicitud
BYE para romper una sesión. El atacante envía un mensaje BYE falso, que
es reenviado desde P-CSCF a UE1 y asume que es de UE2, que quiere
romper la conexión enviando el mensaje BYE. Como resultado, UE1
detiene el flujo RTP inmediatamente, mientras que UE2 continúa enviando
paquetes RTP a UE1 porque UE2 no tiene noción de que la conexión debe
ser terminada [16]. Para lanzar este tipo de ataque, el atacante necesita
conocer todos los parámetros de sesión necesarios. Esto puede lograrse
mediante el rastreo de la red o realizando un ataque de intermediario para
insertar una solicitud BYE en la sesión.
Ataque CANCEL: El método CANCEL termina una petición pendiente. El
atacante podría utilizar el método CANCEL para cancelar una petición
INVITE generada por un usuario legítimo. Antes de que se genere la
respuesta final para una petición INVITE, el atacante envía un mensaje
CANCEL falso a la P-CSCF, que asume que proviene de un usuario
legítimo. El núcleo IMS acusa recibo del mensaje CANCEL y deja de
procesar la solicitud INVITE. Una solicitud CANCEL sólo puede utilizarse
para cancelar una solicitud INVITE.
Ataque Re-INVITE: La solicitud INVITE establece una sesión o dia- log entre
dos dispositivos de usuario (UE). El objetivo del mensaje re-INVITE es
modificar la información real de la sesión, por ejemplo, cambiando las
direcciones o los puertos, añadiendo un flujo de medios o eliminando un
flujo de medios [10]. Por lo tanto, el atacante podría lanzar un ataque DoS
enviando un mensaje re-INVITE falsificado para modificar la sesión.
Repudio: El usuario o la red niegan las acciones que han tenido lugar. El
no repudio es un servicio de seguridad que contrarresta las amenazas
del repudio.
Enmascaramiento: Un intruso se hace pasar por un usuario autorizado para
obtener información confidencial y servicios del sistema.
Clonación del módulo de identidad de servicios multimedia IP (ISIM): Este proceso
cambia la identidad de una entidad por la de otra del mismo tipo. El ISIM
puede clonarse extrayendo la clave secreta (K) y la identidad internacional
de abonado móvil (IMSI) de un ISIM y trasladándolo a otro ISIM mediante
distintas técnicas de ataque.
fM£-Una arquitectura segura para todas las redes fP 35

Mecanismos de seguridad IMS y asociaciones de seguridad

El objetivo de las soluciones de seguridad IMS es desarrollar un marco de seguridad IMS
que garantice la privacidad del usuario y la protección de la red contra usos
indebidos. Estas soluciones ofrecen importantes funciones y servicios de seguridad:

La confidencialidad del usuario proporciona confidencialidad de la identidad

del usuario, confidencialidad de la ubicación del usuario e imposibilidad de
rastreo del usuario. Para lograr estas características, al usuario se le asigna
una identidad temporal, de modo que la identidad permanente del usuario a
la que se prestan los servicios no pueda ser escuchada a través del enlace
de acceso radioeléctrico. Además, los datos de usuario y la señalización
que podrían revelar la identidad del usuario se cifran en el enlace de acceso
de radio.
La autenticación de entidades se basa en la autenticación del usuario y la
autenticación de la red, y debe aplicarse al establecer la conexión entre el
usuario y la red. Implica un mecanismo de autenticación que utiliza un
vector de autenticación entregado por el entorno doméstico (HE) del
usuario a la red de servicio y un mecanismo de autenticación local que
utiliza el establecimiento de la clave de integridad entre el usuario y la red
de servicio.
La confidencialidad de los datos garantiza la confidencialidad de los datos de
usuario y de señalización. Se consigue utilizando algoritmos de cifrado y
acuerdos de claves.
La integridad de los datos proporciona la integridad de los datos y la
autenticación del origen de los datos de señalización. La integridad de los
datos se consigue mediante algoritmos de integridad y acuerdos de clave de
integridad.
La disponibilidad de la red y los servicios garantiza que los recursos y servicios de la
red estén disponibles en todo momento para los usuarios. Para garantizar la
disponibilidad de servicios y recursos, la red debe estar protegida frente a
ataques DoS y de denegación de servicio distribuida (DDoS).
El control del fraude protege los valiosos activos y servicios de valor añadido
de usuarios ilegítimos y piratas informáticos. En IMS, estos servicios
podrían protegerse asegurando los AS. El 3GPP y el 3GPP2 han
estandarizado la seguridad IMS en diferentes versiones y se basan en la
seguridad IMS temprana y la seguridad IMS completa:
• La solución de seguridad IMS temprana estandarizada en la versión 5
de 3GPP proporciona una funcionalidad de seguridad limitada y tiene
como objetivo proteger el despliegue temprano de IMS y ofrecer menos
seguridad. Proporciona autenticación de abonados para el acceso al
servicio y confidencialidad de identidad en la interfaz de radio.
También proporciona cifrado de la interfaz de radio.
• En la versión 6 de 3GPP se estandariza una solución de seguridad IMS
completa con todas las funciones de seguridad; se basa en las primeras
soluciones de seguridad con el objetivo de mejorarlas. Ofrece nuevas
funciones de seguridad y asegura nuevos servicios para proteger las
redes y los servicios.
36 Manual del subsistema multimedia fP (fM£)
UE Red
Autenticación y acuerdo de claves doméstica
IMS

Seguridad entre
dominios
Mecanismo de Red visitada IMS
seguridad

Protección de la

Red de acceso UMTS

Seguridad de acceso
UMTS

FIGURA 2.3
Mecanismos de seguridad IMS.

terminales con protección de datos. Consta de seguridad de dominio de

red y seguridad de acceso que definen la seguridad SIP salto en salto.
No se admite la seguridad de extremo a extremo. La seguridad global
para IMS consta de los siguientes mecanismos y representa en la
Figura 2.3:
– autenticación y acuerdo de claves entre un abonado de MI y la red
doméstica;
– acuerdo de mecanismo de seguridad entre el cliente de MI y la red
visitada;
– protección de la integridad y confidencialidad;
– seguridad de dominio de red entre diferentes dominios; y
– seguridad de acceso GPRS/UMTS existente.

Los mecanismos de seguridad IMS son implementados por las siguientes

asociaciones de seguridad:

La asociación de seguridad 1 (SA1) proporciona autenticación mutua de

usuario y red (Figura 2.4). El HSS es responsable de generar las claves y
los retos y, a continuación, delega la autenticación del abonado en la S-
CSCF.
fM£-Una arquitectura segura para todas las redes fP AS 32
UE SA6 SA6
AP

ISIM SA1 SA1 HSS

ALIAS

I-CSCF S-CSCF
SA5

UA Red
doméstica

SA2 P-CSCF
SA2

P-CSCF Red
Redes de acceso NGN Todo IP visitada
UMTS, GPRS SA7
Redes

FIGURA 2.4
Asociaciones de seguridad IMS.

La clave a largo plazo en ISIM y HSS está asociada a la identidad privada

multimedios IP (IMPI). El proceso detallado se explicará en una sección
posterior.
La asociación de seguridad 2 (SA2) proporciona un enlace seguro y una asociación
de seguridad entre el UE y la P-CSCF para proteger el punto de referencia
Gm (contacto aéreo). En IMS, la seguridad de dominio de red (NDS)/IP se
utiliza para proteger la señalización SIP, pero la comunicación SIP en la
interfaz Gm entre UE y P-CSCF está fuera del ámbito de la seguridad de
dominio de red/protocolo de Internet (NDS/IP) y necesita medidas
adicionales de seguridad. Se explicará en una sección posterior.
La asociación de seguridad 3 (SA3) proporciona seguridad dentro del dominio de red
internamente para una interfaz Cx. El HSS almacena datos de abonado y de
servicio de forma permanente. Estos datos centralizados son utilizados por
I-CSCF y S-CSCF cuando el usuario se registra o recibe sesiones a través
de la interfaz Cx y el protocolo de gestión seleccionado es DIAMETER.
Los mensajes DIAMETER a través de las interfaces Cx y Dx hacen uso del
protocolo de transmisión de control de flujo (SCTP) [17] con seguridad IP (IPsec)
para una comunicación segura.
38 Manual del subsistema multimedia fP (fM£)

La asociación de seguridad 4 (SA4) proporciona seguridad entre diferentes redes para

nodos con capacidad SIP y sólo es aplicable cuando la P-CSCF reside en la
red visitada (es decir, el usuario está en itinerancia). Cuando la P-CSCF
reside en una red visitada que no sea en virtud del protocolo de
autenticación y acuerdo de claves (AKA), el secreto compartido sólo es
accesible en la red de origen. Esto significa que, aunque la autenticación
deba tener lugar en una red visitada, es necesario asignar cierta delegación
de responsabilidad a la P-CSCF porque existen SA IPsec entre la P-CSCF
y el UE.
La asociación de seguridad 5 (SA5) proporciona seguridad dentro de la red
inter- nalmente entre nodos con capacidad SIP y también se aplica cuando
la P-CSCF reside en una red doméstica. El IMS protege todo el tráfico IP
en una red central utilizando NDS/IP [50], que proporciona
confidencialidad, integridad de datos, autenticación y protección anti-
replay para el tráfico utilizando una combinación de mecanismos de
seguridad criptográficos y mecanismos de seguridad de protocolo aplicados
es IPsec. El procedimiento de seguridad para SA4 y SA5 se explicará en
una sección posterior.
Asociación de seguridad 6 (SA6): Los protocolos que trabajan a través de la
interfaz Ut realizan funciones para gestionar el tráfico de datos para
aplicaciones basadas en HTTP. Por lo tanto, proteger una interfaz Ut
significa lograr la confidencialidad y la protección de la integridad de los
datos del tráfico basado en HTTP. La autenticación y el acuerdo de claves
para la interfaz Ut también se basan en AKA, que genera claves de sesión.
El IMS define una arquitectura de arranque genérica (GBA) [51], que utiliza
una arquitectura de autenticación genérica (GAA) [52] que realiza una
autenticación mutua antes de acceder a los servicios. La autenticación en la
interfaz Ut la realiza un proxy de autenticación. El tráfico en la interfaz Ut
pasa por el proxy de autenticación y se asegura utilizando la clave de
sesión de arranque. La interfaz Ut emplea la seguridad de capa de
transporte (TLS) tanto para la confidencialidad como para la protección de
la integridad. Discutiremos el procedimiento detallado en una sección
posterior.
La asociación de seguridad 7 (SA7) gestiona la protección del usuario y de la
información del usuario en las redes de acceso (por ejemplo, UMTS, sistema
global para comunicaciones móviles (GSM), GPRS, WLAN, DSL y VoIP). La
asociación de seguridad tiene lugar independientemente en un dominio de
servicio de conmutación de circuitos (CS) o de conmutación de paquetes
(PS). En las redes de acceso UMTS, la arquitectura de gestión de la
seguridad consta de un módulo de identidad de servicio de usuario (USIM),
un equipo móvil (ME), una red de acceso (AN), una red de servicio (SN) y
una HE [13]. La USIM es necesaria para acceder al dominio PS en GPRS e
identifica a un abonado concreto. La USIM contiene parámetros de seguridad
para acceder al dominio PS, IMSI, lista de puntos de acceso permitidos e
relacionada con el servicio de mensajes multimedia (MMS). En la red de
servicio, el nodo de soporte GPRS de servicio (SGSN) enlaza la red de
acceso radioeléctrico (RAN) con la red central de paquetes en el dominio
de servicio PS. Es responsable de realizar tanto
fM£-Una arquitectura segura para todas las redes fP 39

funciones de control y gestión del tráfico para el dominio PS. Las partes de
control se ocupan de la gestión de la movilidad y de la gestión de sesiones.
El SGSN también garantiza una calidad de servicio adecuada y genera
información de tarificación. En el dominio de servicio CS, la parte
relacionada es el registro de localización de visitantes (VLR). En el
procedimiento de autenticación y acuerdo de claves intervienen el centro de
autenticación (AUC) dentro de HE, SGSN o VLR y las entidades de red de
la estación móvil (MS) [7].

Autenticación, gestión de claves y secreto IMS

Esta sección se centra en la generación y gestión de claves de sesión para proteger la
señalización y los datos multimedia IP. Estas claves incluyen una clave de
confidencialidad y una clave de integridad, que se derivan de la clave secreta
almacenada en la SIM/USIM. Para obtener servicios multimedia IP, es necesario
registrar la identidad pública de un usuario, denominada identidad pública
multimedia IP (IMPU), y el IMS debe autenticar su identidad privada, denominada
identidad privada multimedia IP (IMPI). La autenticación para el acceso al IMS se
basa en el protocolo AKA. Los algoritmos K y AKA se almacenan en ISIM, que
normalmente está integrado en una tarjeta de circuito integrado universal (UICC)
como un dispositivo basado en tarjeta inteligente. La seguridad del IMS se basa en
un K a largo plazo compartido entre ISIM y el AUC de la red doméstica (HN). El
AKA realiza la autenticación mutua de ISIM y AUC y genera una clave de cifrado
(CK) y una clave de integridad (IK) [7]. En secciones posteriores se describe el
proceso de generación y distribución de claves durante el proceso de autenticación y
los procedimientos de protección de la confidencialidad y la integridad.

Autenticación IMS y gestión de claves

En esta sección explicaremos el procedimiento IMS AKA para un cliente
multimedia IP no registrado y la autenticación mutua exitosa sin error de
sincronización. la autenticación, el cliente envía peticiones SIP REGISTER a la S-
CSCF a través de la P-CSCF y la I-CSCF. Esta solicitud contiene el IMPI y el
IMPU del usuario. Tras recibir esta solicitud, la S-CSCF envía una solicitud de vector
de autenticación (AV-Req (IMPI, m)) al HSS para obtener un vector AV, y el HSS genera
y envía una matriz de AV ordenada en n a la S-CSCF y un número de secuencia en
AV-Req-Response. Cada AV consta de CK, IK, RAND, XRES y AUTHN, como se
indica en la siguiente ecuación:

AV= RAND⎢⎢ AUTN XRES CK IK⎢⎢⎢⎢⎢⎢ (2.1)

Cada AV es necesario para un proceso de autenticación y se selecciona por orden

de llegada. La S-CSCF envía un reto de autenticación SIP (Auth-Challenge) a la P-
CSCF a través de la I-CSCF, y la P-CSCF almacena las claves (IK,
40 Manual del subsistema multimedia fP (fM£)

CK) y reenvía el mensaje restante (Auth-Challenge (IMPI, RAND, AUTN)) al

cliente. La red inicia el procedimiento de autenticación mediante una solicitud de
autenticación que contiene un desafío aleatorio (RAND) y un token de autenticación
(AUTN). El AUTN se calcula como se indica a continuación:

AUTN= SQN+ AK⊕ AMF⊕ MAC (2.2)

donde SQN es el número de secuencia,⊕ es la suma XOR y AMF es un campo de

autenticación y gestión de claves. AK= F5K (RAND); F5 es una función de
generación de claves.
Al recibir un reto, el cliente toma AUTN, que incluye MAC y SQN. El cliente
calcula XMAC como se indica en la ecuación 2.3 y verifica que XMAC = MAC y
SQN en el intervalo correcto:

XMAC= F1K (SQN⊕ RAN⊕ AMF) (2.3)

Si ambos son correctos, el cliente calcula la Auth-Response, incluyendo RES y

algunos otros parámetros, y la envía de vuelta a la P-CSCF en un mensaje REG
(IMPI, Auth-Response). El cliente también calcula las claves CK e IK en esta fase,
como se indica en la siguiente ecuación:

CK= F3K(RAND) & IK= F4K (RAND) (2.4)

donde F3 y F4 son funciones generadoras de claves y RAND es un valor aleatorio.

La P-CSCF reenvía esta respuesta a la I-CSCF, que consulta al HSS para encontrar la
dirección de la S-CSCF; la I-CSCF reenvía esta respuesta a la S-CSCF. La S-CSCF
recupera RES de la respuesta y lo compara con XRES 0. Si la verificación es
satisfactoria, el cliente ha sido autenticado y la IMPU del usuario queda registrada en
la S-CSCF. El procedimiento completo se explica en
Figura 2.5.
El ISIM verifica el AUTN para la autenticidad de la red. El ISIM y el HSS hacen
un seguimiento de los números de secuencia SQNISIM y SQNHSS, respectivamente,
para cada ronda de procedimientos de autenticación. Si el ISIM detecta una
autenticación cuyo número de secuencia está fuera de rango, aborta la autenticación
e informa a la red con un mensaje de fallo de sincronización, que incluye el número
de secuencia correcto 0. Esta técnica se utiliza para proporcionar protección
antirreproducción. El ISIM produce una respuesta de autenticación (RES), como en
la Ecuación 2.5, a partir de una clave secreta y un reto aleatorio (RAND) en
respuesta la solicitud de autenticación de la red:

RES = F2K (RAND) (2.5)

donde F2 es una función de autenticación de mensajes.

Mediante este proceso, el equipo de usuario y la red doméstica se han autenticado
correctamente y han establecido un canal de comunicación seguro. El dispositivo en
el que reside el ISIM es a prueba de manipulaciones, y el acceso físico no basta para
fM£-Una arquitectura segura para todas las redes fP 41

UE P-CSCF I-CSCF HSS S-CSCF

REG(IMPI, IMPU)
REG(IMPI, IMPU) CX-Selección

M IMPU)
REG(I PI,

CX-PUT

AV-Req(IMPI, m)

AV-Req-Resp(IMPI, AV(1...n))

Auth-Challenge(IMPI, RAND, AUTN, IK, CK)

Auth-Challenge(IMPI,
RAND, AUTN, IK, CK)
Auth-Challenge(IMPI,
RAND, AUTN)

REG(IMPI, Auth-Resp)
REG(IMPI, Auth-Resp) CX-Query

REG(IMPI, Auth-Resp)

CX-PUT

CX-PULL

Auth OK

Auth OK

Auth OK

FIGURA 2.5
Proceso de autenticación IMS.

puede revelar la clave secreta. Además, el código PIN la protege de accesos no

autorizados. Así, la combinación de la propiedad del dispositivo físico USIM/ISIM
y el conocimiento del código PIN secreto hace que la arquitectura de seguridad de
IMS sea más robusta.

Cifrado y secreto
El punto de referencia Gm conecta al usuario con el núcleo del sistema multimedia
IP. Se utiliza para transportar todos los mensajes de señalización SIP [4] entre el UE y la P-
CSCF. La protección de esta interfaz es esencial y, por tanto, su seguridad se
considera muy importante. En IMS, NDS/IP se utiliza para proteger la señalización
SIP, pero la comunicación SIP en la interfaz Gm entre UE y P-CSCF está fuera del
alcance de NDS/IP y necesita medidas adicionales de seguridad. La dirección
42 Manual del subsistema multimedia fP (fM£)

Autenticación no segura Autenticación segura

UE P-CSCF
UE S-CSCF

Solicitud Regístrese en
de Sin protección
401 No autorizado
Regístre
se en

Puerto-PS
Registro, RES
Desafío de Protegido
Puerto-UC
autenticación por
OK Integridad

Regístrese en

Invitar a

180 timbres Puerto-PC

Puerto-US
Verificación protegido por
confidencialidad
200 OK

Auth OK

FIGURA 2.6
Escenarios de autenticación segura y no segura.

IMS en las versiones 5 y 6 de 3GPP hace uso de IPsec como mecanismo de

seguridad entre la P-CSCF y el UE. IPsec [55] es sólo uno de varios mecanismos de
seguridad posibles. El IMS fue diseñado para permitir también mecanismos de
seguridad alternativos sobre la interfaz Gm. Permitir tal apertura usualmente crea
problemas de compatibilidad hacia atrás porque, por ejemplo, un UE compatible con
la versión 6 no sería capaz de entender ningún mecanismo de seguridad alternativo,
aunque podría estar conectado a una P-CSCF de una versión superior que ya
soportara alternativas a IPsec [7]. Por lo tanto, el acuerdo de mecanismo de
seguridad SIP (Sip-Sec-Agree) [56] fue introducido para permitir a UE y P-CSCF
negociar un mecanismo de seguridad común para su uso entre ellos. Para las
versiones actuales, el único mecanismo de seguridad es IPsec; sin embargo, es
posible que algunas entidades ya soporten mecanismos alternativos de forma
propietaria (Figura 2.6).
Durante la autenticación del usuario, el UE y el IMS también negocian
mecanismos de seguridad para proteger el tráfico SIP posterior en la interfaz Gm. El
protocolo SIP se utiliza para este acuerdo de seguridad, y el equipo de usuario y la
P-CSCF intercambian sus respectivas listas de mecanismos de seguridad
compatibles; se selecciona el más compatible para proporcionar protección de la
integridad de los datos. Una vez que
fM£-Una arquitectura segura para todas las redes fP 43

se ha seleccionado el mecanismo de seguridad y se ha iniciado su uso, la lista

intercambiada previamente se reproduce en la red de forma segura. Esto ayuda a la
red a verificar que la selección del mecanismo de seguridad ha sido correcta y que el
acuerdo de seguridad no ha sido manipulado. Un ejemplo de ataque que sería
posible sin esta función es un ataque de puja, en el que un atacante fuerza a los pares
a seleccionar un mecanismo de seguridad débil conocido. La carga útil de seguridad
encapsulada IPsec (ESP) [57] proporciona confidencialidad, así como integridad y
autenticación de datos, que son obligatorias en la seguridad de acceso IMS. Las
claves de sesión AKA se utilizan como claves para las SA ESP (es decir, IK se
utiliza como clave de autenticación y CK como clave de cifrado). El protocolo AKA
no puede ejecutarse directamente sobre IP y requiere un vehículo para transportar
los mensajes de protocolo entre el equipo de usuario y la red doméstica. El SIP actúa
como vehículo para el protocolo AKA y se tuneliza dentro del SIP; por lo tanto, el
acceso IMS es obviamente para autenticarlo.

Uso de IPsec ESP para la protección de la confidencialidad e integridad de SIP

Para proporcionar la protección de integridad SIP entre el UE y la P-CSCF, el
protocolo recomendado es IPsec ESP [7], que protege todos los mensajes de señalización
SIP en la capa IP. El uso de ESP para la protección de la integridad se aplicará en
modo transporte. En este modo, la cabecera TCP, la carga útil y los campos de
relleno se cifran en el paquete IP; una nueva cabecera ESP, que contiene
información como el índice de parámetros de seguridad (SPI), se añade entre la
cabecera IP y los datos cifrados. Por último, el código de autenticación de mensajes
(MAC) se calcula sobre todos los datos excepto la cabecera IP. El receptor
comprueba la protección de la integridad calculando el MAC y comparándolo con el
MAC recibido. El algoritmo de integridad puede ser un código hash de autenticación
de mensaje (HMAC-MD5-96) [58] o un algoritmo hash seguro (HMAC-SHA-1-96) [59]. Si
el algoritmo seleccionado es HMAC-MD5-96, la clave de integridad (IKESP) se
calcula como sigue (128 bits):

IKESP= IKIM (2.6)

Para el otro algoritmo (HMAC-SHA-1-96), la clave de integridad (IKESP) se calcula como

sigue para crear una clave de 160 bits:

IKESP = IKIM⎢⎢ Cadena de ceros de 32 bits (2.7)

Para proporcionar confidencialidad a la señalización SIP en la interfaz aérea, el

UE y la P-CSCF acuerdan el algoritmo de encriptación específico, el mecanismo y
la clave de encriptación. El IPsec ESP [60] en el transporte es recomendado por
3GPP para proporcionar protección confidencial de la señalización SIP en la interfaz
Gm entre el núcleo IMS y el cliente IMS. El algoritmo de cifrado es el estándar de
cifrado de datos triple DES utilizado en código de bloque cifrado (DES-EDE3-CBC)
[61] o el estándar de cifrado avanzado en código de bloque cifrado (AES-CBC) [62]
con una clave de 128 bits. La clave de cifrado (CKESP) para DES-EDE3-CBC se
calcula como
44 Manual del subsistema multimedia fP (fM£)

CKESP= CKIM1⎢⎢ CKIM2⎢⎢ CKIM1 (2.8)

donde CKIM1 (64 bits) y CK(IM2) (64 bits) se derivan de CKIM (128 bits) como

CKIM= CKIM1⎢⎢ CKIM2 (2.9)

Si el algoritmo seleccionado es AES-CBC, la clave de cifrado (CKESP) es:

KESP = CKIM

Procedimiento de integridad y confidencialidad del SIP

Ahora discutiremos el procedimiento para establecer asociaciones de seguridad entre

el cliente (UE) y la P-CSCF para la protección de la interfaz Gm. El cliente envía un
mensaje de configuración de seguridad en el mensaje REG (Sec-Setup= SPI-U,
Port-U, UE I & E Algorithms List) como se muestra en la Figura 2.7, donde

SPI-U= (SPI-UC, SPI-US), un par de valores de índice de parámetros de seguridad

que selecciona el cliente;
Port-U= (Port-UC, Port-US), un par de números de puerto protegidos de clientes
y servidor; y
UE I & E Algorithms List = lista de identificadores de algoritmos de integridad y
cifrado que admite el cliente.

Al recibir este mensaje, la P-CSCF almacena los parámetros de seguridad junto

con el IMPI, el IMPU y la dirección IP del cliente y añade las claves IKIM y CKIM
recibidas de la S-CSCF. A continuación, la P-CSCF envía Auth-Challenge (Sec-Setup =
SPI-P, Port-P,P-CSCF I & E Algorithms List) al cliente, donde

SPI-P= (SPI-PC, SPI-PS), un par de valores SPI que P-CSCF selecciona;

Puerto-P= (Puerto-PC, Puerto-PS), un par de números de puerto protegidos de
clientes y servidor; y
P-CSCF I & E Algorithms List = lista de identificadores de algoritmos de
integridad y cifrado compatibles con la P-CSCF.

A continuación, el cliente envía un mensaje final de configuración de seguridad

como REG (Sec-Setup= SPI-U, Port-U, SPI-P, Port-P, P-CSCF I & E Algorithms List) a
la P-CSCF y comprueba si estos parámetros coinciden. Si coinciden, el registro se
realiza correctamente. Finalmente, la P-CSCF envía REG (Integrity-Protection=
Successful, Confidentiality-Protection= Successful, IMPI) a la S-CSCF para
informar que los mensajes del cliente están protegidos por integridad y
confidencialidad [54].
fM£-Una arquitectura segura para todas las redes fP 45

UE P-CSCF I-CSCF HSS S-CSCF

REG(IMPI, IMPU)
REG(IMPI, IMPU) CX-Selección

REG(Sec-Setup=SPI-U, M
Lista de algoritmos Port- REG(I PI, IMPU)
U, UE I y E)

CX-PUT

AV-Req(IMPI, m)

AV-Req-Resp(IMPI, AV(1...n))

Auth-Challenge(IMPI, RAND, AUTN, IK, CK)

Auth-Challenge(IMPI,
RAND, AUTN, IK, CK)
Auth-Challenge(IMPI,
RAND, AUTN)

Reto de autenticación (Sec-

Setup=
SPI-P, Puerto-P, P-CSCF I y E
Lista de algoritmos)

REG(IMPI, Auth-Resp) REG(IMPI, Auth-Resp) CX-Query

REG(Sec-Setup=SPI-U, REG(IMPI, Auth-Resp)

Puerto-U, SPI-P, Puerto-P, P-CSCP
Lista de algoritmos I & E)

REG(Protección-Integridad=Satisfactoria, Protección-Confidencialidad=Satisfactoria, IMP)

CX-PUT

CX-PULL

Auth OK
Auth OK

Auth OK

FIGURA 2.7
Autenticación con protección de la integridad y la confidencialidad.

Seguridad entre dominios

El IMS admite la comunicación entre la red doméstica y la red visitada, creando dos
escenarios: si el terminal IMS está en la red doméstica o en itinerancia. En el primer
escenario, el primer punto de contacto del UE con IMS, denominado P-CSCF, se
encuentra en la red doméstica, y en el segundo escenario, el P-CSCF se encuentra en
la red visitada (itinerancia), como se muestra en
46 Manual del subsistema multimedia fP (fM£)
Red visitada Red doméstica

ISC

S-CSCF AS

Mw
P-CSCF

Sh
Gm

Cx

HSS
I-CSCF

Cliente IMS

FIGURA 2.8
Escenario de itinerancia IMS.

Figura 2.8. El tráfico entre las redes visitada y doméstica se protege mediante
NDS/IP en la capa IP [63]. El NDS/IP sólo protege el tráfico entre elementos de red
en una capa IP.
Un dominio de seguridad es una red gestionada por una única autoridad
administrativa que aplica una política de seguridad uniforme dentro de ese dominio.
Como resultado, el nivel de seguridad será el mismo dentro de un dominio de
seguridad. En su mayor parte, el dominio de seguridad está relacionado directamente
con la central de un operador; sin embargo, es posible gestionar varios dominios de
seguridad que constituyan un subconjunto de toda la red central del operador. IMS
protege todo el tráfico IP en la red central utilizando NDS/IP, que proporciona
confidencialidad, integridad de datos, autenticación y protección contra réplicas para
el tráfico utilizando una combinación de mecanismos de seguridad criptográficos y
mecanismos de seguridad de protocolo aplicados en IPsec. En la plataforma
NDS/IP, las interfaces entre elementos dentro del dominio de seguridad se denotan
por Zb y las interfaces entre dominios de seguridad diferentes se denotan por Za,
como se muestra en la Figura 2.9. El uso de la interfaz Za es siempre obligatorio. El
uso de la interfaz Za es siempre obligatorio entre diferentes dominios de seguridad;
el uso de la interfaz Zb es opcional y depende del administrador del dominio de
seguridad. La autenticación y la integridad de los datos son obligatorias para ambas
interfaces, y se recomienda el uso de cifrado para Za y opcional para Zb.
El NDS/IP se utiliza para proteger también la red central IMS del operador
como el tráfico entre la red visitada y la red doméstica. La idea fundamental de la
arquitectura NDS/IP es proporcionar seguridad hop-by-hop, según los modelos de
funcionamiento chained-tunnels o hub-and-spoke. Utilizar la seguridad hop-by-hop
también facilita el mantenimiento de políticas de seguridad separadas internamente
y hacia otros dominios de seguridad externos. Las entidades de la red
fM£-Una arquitectura segura
Dominio C UE-A
para todas las redes fP
Dominio A UE-A Dominio B UE-B
42
Red visitada Red doméstica Red doméstica

Za Za

SEG-C Zb SEG-A Zb (Zb Zb

) SEG-B

Mw
Mw Mw
Zb

S-SCF I-CSCF S-CSCF

I-CSCF
ISC

Cx ISC Cx P-CSCF
Cx

Cx
P-CSCF

Gm
Gm

Sh Sh

HSS AS HSS
AS

UE-B
UE-A

FIGURA 2.9
Escenarios de redes visitadas y domésticas.

(NEs) establecen y mantienen SAs ESP según sea necesario hacia un SEG u otros
NEs dentro del mismo dominio de seguridad. Todo el tráfico NDS/IP desde un NE
en un dominio de seguridad hacia un NE en otro dominio de seguridad es enrutado
vía SEG y recibirá protección de seguridad hop-by-hop hacia el destino final [63].
Los operadores pueden decidir establecer sólo una SA ESP entre dos dominios de
seguridad comunicantes, lo que llevará a una granularidad de seguridad de grano
grueso. Esto tiene la ventaja de que cierta protección contra el análisis del flujo de
tráfico. Sin embargo, la desventaja es que no es posible diferenciar la protección de
seguridad proporcionada entre las entidades comunicantes. Esto no impide la
negociación de una granularidad de más fina a discreción de las entidades
comunicantes.

Arquitectura de seguridad de dominio de red (NDS)

Un dominio de red es una red controlada por un único operador o administrador con
autoridad para aplicar una política de seguridad uniforme dentro del dominio. Por lo
tanto, el nivel de seguridad y los servicios de seguridad disponibles serán los
mismos dentro de un dominio de seguridad. La seguridad de dominio se aplica en el
bor- der de la red de un y está protegida por SEGs [63], que son responsables de
hacer cumplir la política de seguridad del dominio de seguridad hacia otros SEGs de
dominios de seguridad.
El NDS/IP se utiliza para proteger la red central IMS del operador, así como el
tráfico entre las redes visitada y doméstica. La idea fundamental de la arquitectura
NDS/IP es proporcionar seguridad salto a salto, de acuerdo con la
48 Manual del subsistema multimedia fP (fM£)

túneles encadenados o modelos de hub-and-spoke. Utilizar seguridad hop-by-hop

ayuda a mantener políticas de seguridad separadas internamente y hacia otros
dominios de seguridad externos [64]. En NDS/IP, las pasarelas de seguridad
mantienen SAs ESP seguras IPsec en modo túnel entre dominios de seguridad. Todo
el tráfico NDS/IP de los NEs de un dominio de seguridad se enruta vía SEG a otro
dominio de seguridad usando protección de seguridad hop-by-hop hasta el destino
final.
A continuación se describen las distintas entidades e interfaces de la arquitectura
de seguridad del dominio de red.
Interfaces NDS. Como sabemos, la seguridad entre diferentes dominios se
implementa mediante el protocolo NDS/IP a través de SEGs. Las interfaces entre
dominios de seguridad se representan como Za y las interfaces dentro del
dominio de seguridad se representan como Zb. La interfaz Za cubre todo el
tráfico NDS/IP entre dominios de seguridad.
Para la interfaz Za, se requiere autenticación y protección de la integridad de los
datos, y se recomienda el cifrado de los mismos. Estas tres características de
seguridad se implementan utilizando el protocolo ESP [57], y los SEG utilizan IKE
para negociar, establecer y mantener un túnel ESP seguro entre ellos para reenviar
tráfico NDS/IP entre dominios de seguridad. La política de seguridad sobre la
interfaz Xa depende del acuerdo de itinerancia.
Para la interfaz Zb, la autenticación y la protección de la integridad de los datos
son necesarias y se implementan utilizando el protocolo ESP. El cifrado de datos es
opcional en esta interfaz y depende de la decisión del operador del dominio de
seguridad.
Las pasarelas de seguridad son entidades de red situadas en las fronteras de los dominios
de seguridad IP que proporcionan seguridad a los protocolos basados en IP y
establecen la comunicación a través de la interfaz Za. Todo el tráfico NDS/IP pasa
por un SEG antes de entrar o salir del dominio de seguridad. Un dominio de
seguridad puede tener más de un SEG, dependiendo del número de destinos,
evitando fallos de punto único, equilibrando la carga de tráfico, etc. Cada SEG se
define para gestionar el tráfico NDS/IP mediante reglas bien definidas para llegar al
dominio de seguridad IP.
Al proteger el tráfico IMS entre dominios, es obligatorio proporcionar
confidencialidad, integridad de datos y autenticación en el NDS/IP. Las pasarelas de
seguridad aplican las políticas de seguridad para el interfuncionamiento entre redes.
La seguridad puede incluir políticas de filtrado y funciones de cortafuegos. Los SEG
son responsables de operaciones sensibles desde el punto de vista de la seguridad y
deben estar físicamente protegidos.
Como hemos comentado, los SEG establecen y mantienen una SA ESP protegida
por IPsec en modo túnel entre dominios de seguridad. Normalmente, el SEG
proporcionará al menos un túnel IPsec en todo momento a un SEG par en particular.
Cada SEG es responsable de establecer y mantener SAs IPsec con sus SEGs pares.
Estas SA se negocian mediante el protocolo IKE [65], en el que la autenticación se
realiza mediante claves a largo plazo almacenadas en los SEG. Cada SEG mantiene
dos SA por conexión: una para el tráfico entrante y otra para el saliente. Además,
mantiene una única SA de asociación de seguridad de Internet y protocolo de
gestión de claves (ISAKMP) [66] para la gestión de claves. La dirección
fM£-Una arquitectura segura para todas las redes fP
Dominio A Dominio B
49

Za

Enlace

IKE

SEG-A SEG-B
Zb Zb Zb Zb
Zb Zb

ISC Mw
Mw Mw

P-CSCF S-CSCF I-CSCF P-CSCF S-CSCF I-CSCF

ISC IS C
Cx Cx
Gm

Gm

Sh
Sh

AS HSS AS HSS
UE-A UE-B

FIGURA 2.10
Arquitectura de pasarela de seguridad.

Un requisito previo para la SA ISAKMP es que los pares estén autenticados. En el

NDS/IP, la autenticación se basa en secretos precompartidos. La arquitectura de los
SEG se presenta en la Figura 2.10.
El SEG mantendrá una base de datos de asociaciones de seguridad y una base de datos
de políticas de seguridad lógicamente separadas para cada interfaz [63]. Sus
funcionalidades incluyen:

La base de datos de políticas de seguridad (SPD) contiene las políticas por las
que todo el tráfico entrante y saliente es categorizado por las pasarelas de
seguridad. En general, los paquetes se seleccionan para uno de los tres
modos de procesamiento basados en la información del encabezado IP y de
la capa de transporte comparada con las entradas de la base de datos (SPD).
A un paquete se le ofrecen servicios de seguridad IPsec, se descarta o se le
permite eludir IPsec, basándose en las políticas aplicables de la base de
datos identificadas por los selectores.
La base de datos de asociaciones de seguridad (SPD) es un contenedor para todas las
SA activas y los parámetros relacionados. El SPD utiliza un conjunto de
selectores -valores de campo de protocolo de la capa IP y de la capa superior
(por ejemplo, TCP y UDP)- para asignar el tráfico a una SA específica. Esta
relación está representada por un conjunto de información que puede
considerarse como un contrato entre los SEG. La información debe ser
acordada y compartida entre todos los SEG, y todos los SEG deben adherirse a
la SA para que las comunicaciones seguras sean posibles. Al acceder a los
atributos SA, los SEG utilizan un puntero o identificador denominado
índice de parámetros de seguridad (SPI) [63].
50 Manual del subsistema multimedia fP (fM£)

Uso de IPsec en un entorno NDS/IP

Esta sección proporciona una visión general de las características de IPsec que son
utilizadas por NDS/IP y define conjuntos mínimos de características que deben ser
soportadas. Los servicios de seguridad proporcionados por NDS/IP son la integridad
de los datos, la autenticación del origen de los datos, la protección anti-repetición y
la protección limitada contra el análisis del flujo de tráfico, y la confidencialidad.
IPsec proporciona servicios de seguridad en la capa IP permitiendo a un sistema
seleccionar los protocolos de seguridad requeridos, determinar los algoritmos que se
utilizarán para el servicio y proporcionar las claves criptográficas necesarias para los
servicios solicitados. Puede utilizarse para proteger uno o más enlaces entre un par
de SEG o entre un SEG y un host. El conjunto de servicios de seguridad que IPsec
puede proporcionar incluye el control de acceso, la integridad sin conexión, la
autenticación del origen de los datos, el rechazo de paquetes reproducidos y la
confidencialidad. Dado que estos servicios se proporcionan en la capa IP, pueden ser
utilizados por cualquier protocolo de capa superior. Los componentes de la
arquitectura de seguridad IPsec son los protocolos de seguridad, las asociaciones de
seguridad, la gestión de claves y los algoritmos de cifrado y autenticación.
Protocolos de seguridad. IPsec utiliza dos protocolos para proporcionar seguridad
de tráfico (es decir, cabecera de autenticación [AH] y ESP). Estos protocolos pueden
aplicarse solos o en combinación para proporcionar un conjunto deseado de
servicios de seguridad en Ipv4 e Ipv6. Cada protocolo admite dos modos de uso (es
decir, modo transporte y modo túnel). En modo transporte, los protocolos
proporcionan protección principalmente para protocolos de capa superior. El modo
túnel se utiliza normalmente para tunelizar el tráfico IP entre dos SEG. La diferencia
es que en el modo transporte IPsec ofrece una protección limitada a las cabeceras IP,
mientras que en el modo túnel se protege el datagrama IP completo.
El protocolo de seguridad utilizado en el NDS/IP para el cifrado, la protección de
la integridad de los datos y la autenticación es el IPsec ESP [57] en modo túnel (es
decir, el datagrama IP completo, incluida la cabecera IP, se encapsula en el paquete
ESP). El ESP proporciona confidencialidad, autenticación del origen de los datos,
integridad sin conexión, un servicio anti-repetición y confidencialidad limitada del
flujo de tráfico. El conjunto de servicios proporcionados depende de las opciones
seleccionadas en el momento de establecer la asociación de seguridad y de la
ubicación de la implementación. El servicio antirrepetición sólo puede seleccionarse
si se selecciona la autenticación del origen de los datos, y su selección queda
exclusivamente a discreción del receptor [57].
El ESP se utiliza para proporcionar servicios de seguridad en IPv4 e IPv6. Para
procesar el tráfico saliente, un host o pasarela de seguridad utiliza primero un
conjunto de selectores en el SPD para determinar el SA saliente utilizado. A
continuación, sigue una serie de pasos para procesar el paquete saliente:

• Todo el datagrama IP saliente original se encapsula en un campo de carga

útil ESP en modo túnel.
• Se añade el relleno adecuado a los datos de la carga útil.
• Los resultados se cifran mediante una clave de cifrado y un algoritmo.
• El número de secuencia se incrementa según corresponda.
fM£-Una arquitectura segura para todas las redes fP 51

• Si la autenticación está activada, se calcula el valor de comprobación de

integridad (ICV).
• Se realiza una posible fragmentación del datagrama IP.

Al recibir un datagrama IP, el destinatario sigue los siguientes pasos para procesar
el paquete:

• Se realiza un posible reensamblaje del datagrama IP.

• Utilizando el SPI, el protocolo de seguridad y la dirección IP de destino,
se busca un SA apropiado en el DUA.
• Si la protección antirrepetición está activada, se inspecciona el número de
secuencia.
• Si la autenticación está activada, se verifica el ICV.
• El paquete se descifra, se elimina el relleno y se reconstruye el datagrama
IP original.

La cabecera ESP está diseñada para proporcionar una mezcla de servicios de

seguridad en IPv4 e IPv6. La cabecera se inserta antes de una cabecera IP
encapsulada en modo túnel. Así, el formato de los paquetes ESP para una SA dada es
fijo durante la duración de la SA. Los SEG emplean el ESP en modo túnel para
proteger el tráfico transeúnte. La cabecera IP interna lleva las direcciones de origen
y destino finales, mientras que una cabecera IP externa puede contener distintas
direcciones IP, normalmente direcciones de pasarelas de seguridad. En el modo
túnel, el ESP protege todo el paquete IP interno, incluida toda la cabecera IP interna
[66].
Si se selecciona la autenticación, el cifrado se realiza primero, antes de la
autenticación, y el cifrado no abarca el campo de datos de autenticación. Este orden
de procesamiento facilita la rápida detección y rechazo de paquetes reproducidos o
falsificados por parte del receptor antes de descifrar el paquete, reduciendo
potencialmente el impacto de los ataques de denegación de servicio. También
permite la posibilidad de procesar los paquetes en paralelo en el receptor; así, el
descifrado puede tener lugar en paralelo con la autenticación.
La asociación de seguridad es un conjunto de políticas y claves utilizadas para
proteger la información y se define como la relación entre dos SEG que permite la
protección de la información comunicada entre ellos y que define cómo van a
utilizar los servicios de seguridad para proteger sus comunicaciones. Incluye
información sobre algoritmos de autenticación o cifrado, claves criptográficas y
longitud de las claves, así como los vectores de inicialización (IV) que comparten las
entidades. Una SA es unidireccional, por lo que normalmente se necesitan dos SA para un
flujo de tráfico bidireccional: una para el tráfico entrante (lectura) y otra para el
saliente (escritura). Los protocolos de seguridad utilizan SA porque proporcionan
servicios de seguridad. Esta relación incluye una clave simétrica compartida y
atributos de seguridad que describen la relación. Se identifica unívocamente
mediante SPI [57] y la dirección IP de destino.
52 Manual del subsistema multimedia fP (fM£)

Con respecto al uso de asociaciones de seguridad IPsec en el dominio de red de

las redes NDS/IP, el NDS/IP requiere soporte para SAs IPsec en modo túnel y
soporte para SAs ESP. La especificación de IPsec SAs está disponible en RFC-2401
[55].
Con respecto al uso de asociaciones de seguridad ISAKMP en el dominio de red
de las redes NDS/IP, el NDS/IP sólo requiere soporte para SAs ISAKMP con claves
precompartidas. La especificación de ISAKMP SAs está disponible en RFC-2408
[66].
Gestión de claves. El proceso de distribución de claves criptográficas para su uso
con los protocolos de seguridad (en concreto, el IKE) se denomina gestión de claves.
En la arquitectura de seguridad del dominio de red IMS/UMTS, la distribución de
claves entre SEGs es gestionada por el protocolo IKE [66]. El objetivo principal de
IKE es negociar, establecer y mantener SAs entre entidades de red que se utilizan
para establecer comunicaciones seguras. IKE negocia automáticamente SAs IPsec y
permite comunicaciones seguras IPsec [65].
Existen dos métodos básicos para establecer un intercambio de claves
autenticadas: el modo principal y el modo agresivo. Cada modo genera material de
clave autenticado a partir de un intercambio efímero Diffie-Hellman. Se debe
implementar el modo principal y el modo agresivo. Además, el modo rápido debe
ser implementado como un mecanismo para generar material de claves fresco y
negociar servicios de seguridad no-ISAKMP; el modo de grupo nuevo debe ser
implementado como un mecanismo para definir grupos privados para intercambios
Diffie-Hellman [60]. En concreto, IKE proporciona las siguientes ventajas:

• Elimina la necesidad de especificar manualmente todos los parámetros de

seguridad IPsec en los crypto maps en ambos peers.
• Permite especificar un tiempo de vida para la asociación de seguridad IPsec.
• Permite que las claves de cifrado cambien durante las sesiones IPsec.
• Permite a IPsec proporcionar servicios anti-repetición.
• Permite el soporte de autoridades de certificación (CA) para una
implementación IPsec gestionable y escalable.
• Permite la autenticación dinámica de los pares.

El protocolo IKE es utilizado para la negociación de SAs IPsec, con el siguiente

requerimiento adicional para las negociaciones de SAs entre dominios de seguridad
sobre la interfaz Za [67].

• IKE fase-1 (ISAKMP SA)

• Se apoyará el uso de secretos precompartidos para la autenticación
[68].
• Sólo se utilizará el modo principal ISAKMP.
• Para la identificación se admitirán direcciones IP y nombres de
dominio completos (FQDN).
fM£-Una arquitectura segura para todas las redes fP 53

• El soporte de 3DES en modo CBC [69] será obligatorio para la

confidencialidad.
• La compatibilidad con AES en modo CBC [62] será obligatoria para la
confidencialidad.
• La compatibilidad con SHA-1 [59] será obligatoria para la
autenticación de integridad y seguridad.
• El soporte del grupo 2 de Diffie-Hellman será obligatorio para el
intercambio Diffie-Hellman [70].

Las SAs IKE de Fase-1 serán persistentes con respecto a las SAs IPsec (es decir,
las SAs IKE tendrán un tiempo de vida de al menos la misma duración que las SAs
IPsec derivadas). Las SAs IPsec deben ser re-claveadas proactivamente (es decir,
una nueva SA debe ser establecida antes de que la SA anterior expire [68]).

• IKE fase-2 (IPsec SA)

• El secreto perfecto es opcional.
• Sólo las direcciones IP o los tipos de identidad de subred serán tipos
de dirección obligatorios.
• El apoyo a las notificaciones será obligatorio.
• La compatibilidad con el grupo 2 de Diffie-Hellman será obligatoria para
el intercambio Diffie-Hellman.

Algoritmos de cifrado y autenticación. Para implementar la seguridad entre dominios

IMS, 3GPP recomienda el cifrado y el algoritmo triple DES (3DES) [69] es
obligatorio, pero para la integridad de los datos y la autenticación se pueden utilizar
MD5 [71] y SHA-1 [59]. IPsec ofrece un conjunto de soportes de transformación de
confidencialidad que incluyen las transformaciones ESP_NULL y ESP_DES. Sin
embargo, el algoritmo DES ya no se considera suficientemente fuerte en términos de
fuerza criptográfica. El IESG menciona en el RFC 2407 [72] que es probable que la
transformación ESP_DES quede obsoleta en un futuro próximo. Por lo tanto, se
recomienda explícitamente en NDS/IP que el algoritmo ESP_3DES sea obligatorio
en lugar de ESP_DES. Además, el soporte para el algoritmo de cifrado AES-CBC
[62] es obligatorio con una longitud de clave de 128 bits.
IPsec ofrece transformaciones de integridad de datos que la implementación IPsec
compatible debe admitir, incluidas las transformaciones ESP_NULL,
ESP_HMAC_MD5 y ESP_HMAC_SHA-1. Para el tráfico NDS/IP, ESP siempre se
utilizará para proporcionar servicios de autenticación de origen de datos y
antirreproducción. Para el tráfico NDS/IP, ESP siempre se utilizará para
proporcionar integridad, autenticación del origen de los datos y servicios anti-
reproducción; por lo tanto, no se permite explícitamente el uso del algoritmo de
autenticación ESP_NULL. ESP soportará el algoritmo ESP_HMAC_SHA-1 en
NDS/IP.

Infraestructura de clave pública (PKI)

La criptografía de clave pública, también conocida como criptografía asimétrica,
utiliza un par de claves, una privada y otra pública, que son matemáticamente
iguales.
54 Manual del subsistema multimedia fP (fM£)

relacionados. La información se cifra con la clave pública y sólo puede descifrarse

con la clave privada correspondiente. En este sistema, las claves públicas de todos
los usuarios se publican en un directorio abierto, lo que facilita la comunicación
entre todas las partes. La clave privada no se comparte; sólo se hace la clave
pública. La criptografía de clave pública también puede utilizarse para crear y
verificar firmas digitales cambiando el orden de las claves mediante cifrado y
descifrado [70]. Éstas pueden adjuntarse a los mensajes para proporcionar una
prueba de autenticación, integridad y no repudio. El Foro PKI ha proporcionado una
perspectiva técnica PKI [73] para utilizar la tecnología PKI en entornos de
proveedores específicos, abordando las siguientes cuestiones [64]

• políticas de seguridad que definen las reglas bajo las que deben operar los
sistemas criptográficos;
• procedimientos para generar, almacenar y gestionar las ; y
• procedimientos sobre cómo se generan, distribuyen y utilizan las claves y
los certificados.

Una PKI es una combinación de políticas y procedimientos, hardware y software. La PKI

se basa en identificadores digitales conocidos como "certificados digitales" que vinculan
la firma digital del usuario a su clave pública. La PKI consta de los siguientes
componentes.
La política de seguridad establece y define la dirección de alto nivel en materia de
seguridad de la información, así como los procesos y principios para el uso de la
criptografía. Normalmente, incluirá declaraciones sobre cómo manejar las claves y la
información valiosa y establecerá el nivel de control necesario para ajustarse a los
niveles de riesgo.
La autoridad de certificación (CA) es la base de confianza de una PKI porque
gestiona los certificados de clave pública durante todo su ciclo de vida. El sistema
de CA realiza las siguientes tareas

• Emite certificados vinculando la identidad de un usuario o SEG a una clave

pública con una firma digital.
• Programa las fechas de caducidad de los certificados.
• Garantiza la publicación de listas de revocación de certificados (CRL) para
revocar certificados cuando sea necesario.

La PKI debe garantizar que la clave privada de la CA se guarda en un módulo de

seguridad a prueba de manipulaciones, y debe prever copias de seguridad la
recuperación en caso de desastre. El acceso a la CA y a la RA debe estar
estrictamente controlado. Todas las solicitudes de certificados deben estar firmadas
digitalmente para detectar y evitar que los piratas informáticos generen certificados
falsificados deliberadamente. Todos los eventos significativos realizados por el sistema
de CA deben registrarse en una pista de auditoría segura, en la que cada entrada esté
sellada con fecha y hora y firmada para garantizar que las entradas no puedan
falsificarse.
La relación de confianza entre dos autoridades se establece mediante la
certificación cruzada. Cuando la CA A se certifica de forma cruzada con la CA B,
significa que A ha decidido confiar en los certificados emitidos por B. El proceso de
certificación cruzada permite a los usuarios de ambas autoridades confiar en los
certificados de la otra .
fM£-Una arquitectura segura para todas las redes fP 55

cates. Confianza en este contexto equivale a poder autenticar. Existen dos tipos de
procesos de certificación cruzada:

Certificación cruzada manual. En la certificación cruzada manual, las

certificaciones cruzadas mutuas se establecen directamente entre las CA.
La autori- dad toma las decisiones sobre la confianza localmente. Cuando
la CA A decide confiar en la CA B, entonces A firma el certificado de la
autoridad B y distribuye el nuevo certificado (el certificado de B firmado por
A) localmente. El inconveniente de este enfoque es que a menudo da lugar a
situaciones en las que las entidades que toman las decisiones de confianza
deben disponer de un gran número de certificados: La CA local debe firmar
un certificado por cada dominio de seguridad en el que la autoridad local
desee confiar. Sin embargo, todos los certificados pueden configurarse
localmente y están firmados localmente, por lo que su gestión suele ser
flexible.
Certificación cruzada puente. La CA puente es un concepto que reduce el número
de certificados que deben configurarse para la entidad que realiza la
comprobación de certificados. Cuando dos autoridades se certifican
mutuamente con el puente, no necesitan . Las autoridades pueden seguir
confiando unas en otras porque la confianza en este modelo es transitiva (es
decir, A confía en bridge y bridge confía en B; por tanto, A confía en B y
viceversa). La CA puente actúa como un puente entre las autoridades y las dos
autoridades también confían en que la CA puente es de confianza y segura. Las
certificaciones cruzadas estilo CA puente son útiles en escenarios en los que
todas las entidades comunican una tercera parte de confianza común. Si una
autoridad necesita restringir la confianza o el control de acceso derivado de la
CA puente, necesita implementar adicionalmente esas restricciones [68].

Marco de autenticación NDS basado en PKI

Esta sección explica la implementación de un marco de seguridad/autenticación de
dominio de red basado en PKI que utiliza un método de control de acceso simple
(es decir, cada elemento que se autentica también proporciona un servicio). La
arquitectura utiliza certificaciones cruzadas directas entre los dominios de seguridad,
lo que permite configurar fácilmente las políticas en los SEG [68]. Cada dominio de
seguridad tiene al menos una autoridad de certificación local (LCA) y una autoridad
de certificación de dominio (DCA), como se muestra en la figura 2.11. Sus
funciones son las siguientes Su funcionalidad viene dada por:

• El LCA del dominio emite certificados a los SEG del dominio que tienen
interconexión con SEG de otros dominios.
• El DCA del dominio emite certificados a los LCA de otros dominios con
los que los SEG del operador tienen interconexión.
• Todos los certificados se basan en el programa de certificados X.509 de
Internet [74].
56 Manual del subsistema multimedia fP (fM£)

Certificado Certificado
Autoridad A Autoridad B

LCA-A DCA-A LCA-B DCA-B

REG-A2 REG-A1 CA-B CA-C REG-B2 REG-B1 CA-A CA-C

FIGURA 2.11
Arquitectura de las pasarelas de seguridad.

El LCA emite certificados para los SEG que implementan la interfaz Za. Cuando el SEG
del dominio de seguridad A establece una conexión segura con el SEG del dominio
B, pueden autenticarse mutuamente. La autenticación mutua se comprueba
utilizando los certificados que las LCA han emitido para los SEG. Cuando se
establece un acuerdo de itinerancia entre los dominios, el DCA certifica de forma
cruzada el LCA del operador homólogo. Los certificados cruzados creados sólo
tienen que configurarse localmente en cada dominio.
Los certificados cruzados emitidos por el DCA-A del dominio de seguridad A para el
LCA del dominio de seguridad B estarán disponibles para el SEG del dominio A, que
implementa la interfaz Za hacia el dominio B. Del mismo modo, los certificados
cruzados emitidos por el DCA-B del dominio de seguridad B para el LCA del dominio
de seguridad A estarán disponibles para el SEG del dominio B, que implementa la
interfaz Za hacia el dominio A. Tras la certificación cruzada, el SEG-A puede verificar
la siguiente ruta (figura 2.12):

SEG-B→ LCA-B→ DCA-A

Del mismo modo, el SEG-B es capaz de verificar el camino:

SEG-A→ LCA-A→ DCA-B

Si se cumple el proceso de verificación, los dominios A y B pueden confiar el uno

en el otro y utilizar los certificados mutuamente.
La clave pública del DCA se almacena de forma segura en cada SEG dentro del
dominio del operador. Esto permite al SEG verificar los certificados cruzados
emitidos por el DCA de su operador. Se supone que cada dominio de operador
podría incluir de 2 a 10 SEG. Un operador puede decidir configurar tanto el LCA
como el DCA como una única CA (es decir, no es necesaria la separación de CAs).
El NDS/AF se basa inicialmente en un modelo de confianza simple que evita la
introducción de confianza transitiva o
fM£-Una arquitectura segura para todas las redes fP 52

Dominio A Dominio B

DCA-A DCA-B

Local CRL-A CR-A local Local CRL-B CR-B local

LCA-A LCA-B

CRL-A público Público CRL-B

Enlace IKE
Za

Za
Enlace
ESP
SEG-A SEG-B

FIGURA 2.12
Distribución de certificados.

información de autorización adicional. El modelo de confianza simple implica la

certificación cruzada manual [68]. Ahora discutiremos el diseño de los casos de uso
de NDS/AF.
Creación/terminación de un acuerdo de itinerancia. Cuando requiere un acuerdo
de itinerancia, los SEG de dos dominios diferentes establecen el túnel seguro
utilizando certificados cruzados emitidos por DCA de dos dominios. La creación de
un acuerdo de itinerancia sólo implica el uso de las claves privadas de los DCA. No
es necesario que los operadores utilicen las claves privadas de sus respectivos LCA
para formar un acuerdo de itinerancia.
Al crear el nuevo certificado cruzado, el DCA establece la longitud de la ruta en
cero para iniciar el nuevo certificado cruzado que se utilizará en la firma de nuevos
certificados de CA. Cuando el nuevo certificado cruzado está disponible para el
SEG, su información se configura en el SEG. La autenticación puede realizarse
basándose en los certificados cruzados creados.
Cuando se termina un acuerdo de itinerancia o debido a una necesidad urgente de
ter- minación del servicio, todos los pares SEG afectados eliminarán los SAs IPsec
utilizando métodos de gestión específicos del dispositivo. Cada operador afectado
también listará el certificado cruzado creado para el DCA del operador finalizado en
su CRL local [68].
58 Manual del subsistema multimedia fP (fM£)

Creación de un túnel VPN. Tras establecer un acuerdo de itinerancia y finalizar

las operaciones de gestión de certificados necesarias, los operadores configuran sus
SEG para la conexión SEG-SEG y se establecen los SA especificados por NDS/IP. En cada
configuración de conexión, se especifica el nombre DNS o la dirección IP del SEG
remoto. Sólo el DCA y el LCA locales están configurados como CAs de confianza
[68]. Debido a la certificación cruzada, cualquier operador cuyo LCA haya sido
certificado de forma cruzada puede obtener acceso utilizando esta configuración de
conexión VPN.
Ahora discutiremos el flujo de negociación de la conexión, como se menciona en
Karn, Metzger y Simpson [69], desde el SEG-A, que es el iniciador. El SEG-B, que
es el respondedor, realizará la misma función. Durante el inicio de la conexión, el
SEG-A iniciador proporciona su propio certificado SEG y la firma digital corres-
pondiente en el mensaje 3 del modo principal de IKE:

• SEG-A recibe el certificado y la firma del SEG-B remoto.

• SEG-A valida la firma remota SEG-B.
• SEG-A verifica la validez del certificado SEG-B mediante una
comprobación CRL a las bases de datos CRL tanto del operador A como
del operador B. Si un SEG no puede realizar con éxito ambas
comprobaciones CRL, asume un error y aborta el establecimiento del túnel.
Si un SEG no puede realizar con éxito ambas comprobaciones CRL, asume
un error y aborta el establecimiento del túnel.
• SEG-A valida el certificado SEG-B utilizando el certificado cruzado para
LCA-B ejecutando las siguientes acciones:
1. SEG-A verifica la validez del certificado cruzado para LCA-B
mediante una comprobación CRL en la base de datos CRL de DCA-A.
Si un SEG no puede realizar con éxito la comprobación CRL, asumirá
que se ha producido un error y cancelará el establecimiento del túnel.
Si un SEG no puede realizar con éxito la comprobación CRL, asumirá
un error y abortará el establecimiento del túnel.
2. SEG-A valida el certificado cruzado para LCA-B utilizando su certificado
DCA si DCA no es una CA de nivel superior; de lo contrario, la clave
pública DCA es de confianza implícita.

De este , se establece la SA de fase 1 de IKE y la negociación de SA de fase 2

procede como se describe en NDS/IP con autenticación PSK.
Perfiles de certificado. Antes de atender cualquier solicitud de certificado de firma, el
LCA y el DCA se asegurarán de que la solicitud cumple los siguientes criterios de perfil
de certificado:

• Los certificados de la versión 3 están en uso según el RFC 3280 [75].

• El soporte de SHA-1 tiene un algoritmo.
• Para los certificados DCA y LCA, la longitud de la clave RSA será de al
menos 2.048 bits.
• Para el certificado SEG, la longitud de la clave RSA será de al menos 1.024 bits.

Validación del certificado SEG. Durante el establecimiento del túnel VPN, cada SEG
tiene que verificar la validez del certificado de su SEG par. SEG-A verifica la
validez del certificado cruzado de LCA-B y el certificado de SEG-B, y será
fM£-Una arquitectura segura para todas las redes fP 59

capaz de obtener el certificado cruzado del LCA-B. SEG-B realiza el mismo proceso
para la validez de los certificados de SEG-A. En este punto, el túnel VPN aún no está
disponible; por lo tanto, la CRL del LCA peering será accesible para SEG sin utilizar la
interfaz Za.

Gestión de la seguridad de los servicios basados en HTTP

La interfaz Ut es el punto de referencia entre el UE y el AS que permite a los
usuarios gestionar y configurar de forma segura la información relacionada con sus
servicios de red alojados en un AS. Los usuarios pueden utilizar un punto de
referencia Ut para crear identidades de servicio público, como una lista de recursos,
y gestionar las políticas de autorización que utiliza el servicio. Ejemplos de servicios
que utilizan el punto de referencia Ut son la presencia y las conferencias. Es posible
que el SV tenga que garantizar la seguridad del punto de referencia Ut. HTTP es el
protocolo de datos elegido para el punto de referencia Ut, que desempeña la función
de gestionar el tráfico de datos para aplicaciones basadas en HTTP. Así pues,
proteger la interfaz Ut significa proteger la confidencialidad y la integridad de los
datos del tráfico basado en HTTP.
La autenticación y el acuerdo de claves para la interfaz Ut también se basan en
AKA. El IMS define GBA [51] como una parte de GAA que realiza la autenticación
mutua entre los BSF y el UE. El AKA genera claves de sesión y habilita otras
aplicaciones proporcionadas por la función de aplicación de red (NAF) que emite
certificados de abonado utilizando un protocolo de aplicaciones asegurado por
claves de sesión bootstrapped. La autenticación en la interfaz Ut la realiza el proxy
de autenticación. En términos de GBA, el proxy de autenticación es otro tipo de
NAF. El tráfico en la interfaz Ut pasa por el proxy de autenticación y se asegura
mediante la clave de sesión bootstrapped.
La interfaz Ut emplea un TLS [52] para proteger tanto la confidencialidad como
la integridad. Utiliza GBA para garantizar que la solicitud procede de un abonado
autenticado del operador de red móvil. Cuando envía una solicitud HTTPS a AS a
través de un AP que realiza la autenticación de UE, el AP puede insertar la identidad
del usuario cuando reenvía la solicitud al servidor de aplicaciones.

Arquitectura genérica de arranque (GBA)

Diferentes servicios multimedia 3G, como videoconferencia, presencia, pulsar para
hablar y mensajería, pueden utilizar GBA para distribuir certificados de abonado.
Los operadores móviles utilizan estos certificados para autenticar al abonado antes
de acceder a los servicios y aplicaciones multimedia. A continuación se describen
los componentes, entidades e interfaces de GBA. La GBA consta de cuatro
entidades: UE, NAF, BSF y HSS, que se explican brevemente a continuación y se
muestran en la Figura 2.13:
60 BSFManual del subsistema HSS
multimedia fP (fM£)
ME Ub Zh

UE
A. Red doméstica GBA

UICC Ua
NAF

Zn
UE BSF HSS

ME Ub Zh

UICC Red doméstica

Zn1
Ua

B. Red visitada

Sin
Zn Zn1
confianza
Red
NAF D-Proxy
Red visitada

FIGURA 2.13
Entidades de red del GBA.

Un equipo de usuario (UE) es una UICC que contiene información relacionada con
USIM o ISIM compatible con los protocolos HTTP digest AKA y NAF
específicos. Una USIM es una aplicación de telefonía móvil UMTS que se
ejecuta en una tarjeta inteligente UICC insertada en un teléfono móvil 3G.
Almacena información sobre el abonado y la autenticación del usuario y
proporciona espacio de almacenamiento para mensajes de texto. Una ISIM
es una aplicación que se ejecuta en una tarjeta inteligente UICC en un
teléfono 3G en el IMS. Contiene parámetros para identificar y autenticar al
usuario en el IMS. La aplicación ISIM puede coexistir con la SIM y la
USIM en la misma UICC, lo que permite utilizar la misma tarjeta
inteligente tanto en redes GSM como en versiones anteriores de UMTS.
La función de autenticación de red (NAF) tiene la funcionalidad de localizar y
comunicarse de forma segura con la BSF del abonado. Debe ser capaz de
adquirir el material de clave compartida establecido entre el UE y el
durante la ejecución del protocolo específico de la aplicación.
La función de servidor de arranque (BSF) se aloja en un elemento de red bajo el
control de un operador de red móvil. Los BSF, los HSS y los UE
fM£-Una arquitectura segura para todas las redes fP 61

participar en la GBA, en la que se establece un secreto compartido entre la

red y un UE mediante la ejecución del procedimiento de bootstrapping. El
secreto compartido puede utilizarse entre los NAF y los UE, por ejemplo,
con fines de autenticación. Un BSF genérico y el UE se autenticarán
mutuamente utilizando el protocolo AKA y acordarán claves de sesión que
se aplicarán posteriormente entre el UE y un NAF. El BSF restringirá la
aplicabilidad del material de claves a un NAF específico utilizando el
procedimiento de derivación de claves. Este procedimiento podrá utilizarse
con múltiples NAF durante la vida útil del material de claves, que se
establecerá con arreglo a la política local del BSF. El BSF podrá adquirir la
configuración de seguridad de usuario (GUSS) de la GBA del HSS [51].
El servidor de abonado doméstico (HSS) almacena las GUSS. El GUSS se define de
tal manera que sea posible el interfuncionamiento de diferentes operadores
para perfiles de aplicación normalizados y también que se admitan perfiles
para aplicaciones específicas del operador y ampliaciones de los perfiles de
aplicación existentes sin necesidad de normalizar estos elementos. La
GUSS podrá contener USS específicos de la aplicación que contengan
parámetros relacionados con la indicación de selección de clave, la
identificación o la información de autorización de una o más aplicaciones
alojadas por uno o más NAF. Cualquier otro tipo de parámetros no está
permitido en las USS específicas de la aplicación [51].

Proxy DIÁMETRO. En el caso de que UE se haya puesto en contacto con un

NAF visitado/operado en una red distinta de la red doméstica, este NAF
visitado utilizará un proxy DIAMETER (proxy D) de la red del NAF para
comunicarse con el BSF del abonado (es decir, el BSF doméstico). Los
requisitos generales para la funcionalidad del D-proxy son:

• D-proxy podrá funcionar como proxy entre el NAF visitado y el BSF de

origen del abonado y podrá localizar el BSF de origen del abonado y
comunicarse con él a través de un canal seguro.
• El D-proxy podrá validar que el NAF visitado está autorizado a participar
en GBA y podrá confirmar al BSF de origen del suscriptor el nombre DNS
del NAF visitado.
• El D-proxy también podrá afirmar al BSF que el NAF visitado está
autorizado a solicitar los perfiles de usuario específicos de la GBA
contenidos en la solicitud del NAF [51].

Puntos de referencia GBA. El punto de referencia Ub se encuentra entre el UE y el BSF y

proporciona autenticación mutua entre ellos. Permite al UE arrancar las claves de
sesión basadas en la infraestructura 3GPP AKA. El protocolo HTTP digest AKA se
utiliza en el punto de referencia Ub. Se basa en el protocolo 3GPP AKA
Protocolo [13].
62 Manual del subsistema multimedia fP (fM£)

Ua: El punto de referencia Ua transporta el protocolo de aplicación, que se

asegura utilizando el material clave acordado entre UE y BSF como resultado
de la ejecución del resumen HTTP AKA sobre el punto de referencia Ub. Por
ejemplo, en el caso del soporte para certificados de abonado, se trata de un
protocolo que permite al usuario solicitar certificados al NAF. En este caso, el
NAF sería el portal PKI.
Zh: El punto de referencia Zh utilizado entre el BSF y el HSS permite al BSF obtener
del HSS la información de autenticación necesaria y todos los ajustes de
seguridad del usuario GBA. La interfaz con el AUC 3G es interna del HSS y
no es necesario normalizarla como parte de esta arquitectura.
Zn: El punto de referencia Zn es utilizado por el NAF para recuperar el
material clave acordado durante un protocolo HTTP digest AKA previo
ejecutado sobre el punto de referencia Ub desde el UE al BSF. También se
utiliza para obtener la configuración de seguridad del usuario específica de
la aplicación desde el BSF, si así lo solicita el NAF.

Procedimiento de autenticación de arranque

El UE y el NAF tienen que decidir si utilizan GBA antes de iniciar la comunicación
entre ellos. Cuando el UE quiere interactuar con el NAF, inicia la comunicación con
el NAF a través de la interfaz Ua sin parámetros GBA. Si el NAF requiere el uso de
claves compartidas obtenidas mediante la GBA, pero la petición del UE no incluye
parámetros relacionados con la GBA, el NAF responde con un mensaje de iniciación
de bootstrapping [51]. Cuando el UE quiera interactuar con un NAF y sepa que es
necesario el procedimiento de bootstrapping, realizará primero una autenticación de
bootstrapping, como se muestra en la Figura 2.14. De lo contrario, el UE realizará
una autenticación de bootstrapping. En caso contrario, el UE sólo realizará una
autenticación de bootstrapping cuando haya recibido un mensaje de inicio de
bootstrapping requerido o una indicación de negociación de bootstrapping del , o
cuando haya expirado el tiempo de vida de la clave en el UE. El UE envía una
petición HTTP al BSF y el BSF recupera el conjunto completo de ajustes de
seguridad de usuario GBA y un vector de autenticación (AV) [54], como se indica
en la ecuación 2.10 sobre el punto de referencia Zh del HSS.
A continuación, BSF envía el RAND y el AUTN al equipo de usuario en el
mensaje 401 sin CK, IK ni XRES. Esto se hace para exigir al equipo de usuario que
se autentique. El UE comprueba AUTN para verificar que el reto procede de una red
autorizada; el UE también calcula CK, IK y RES [54]. Esto dará como resultado las
claves de sesión IK y CK tanto en el BSF como en el UE. El UE envía otra petición
HTTP a la BSF que contiene la respuesta digest AKA, que se calcula utilizando
RES.
La BSF autentica el equipo de usuario verificando el resumen de la respuesta
AKA. La BSF genera el material de claves Ks concatenando CK e IK, y también genera el
B-TID (bootstrapping transaction identifier), que se utiliza para vincular la identidad
del abonado al material de claves en los puntos de referencia Ua, Ub y Zn. El BSF
enviará un mensaje 200 OK, incluyendo un B-TID, al UE para
fM£-Una arquitectura segura para todas las redes fP 63

Ub
UE NAF BSF HSS

Ua Zn Zh

Solicitar

Solicitud de inicio de arranque

Solicitud HTTP

Obtener vector de
autenticación

Mensaje 401 [AKA Challenge(RAND, AUTN etc.)].

Si AUTN es correcto, el
USIM calcula RES, IK y
CK. 1. Compara XRES con
la RES recibida
2. Ks = Ck || IK
Resumen AKA Respuesta

200 OK Mensaje [B-TID, TI]

Ks = Ck || IK

FIGURA 2.14
Procedimiento de autenticación de arranque.

indican el éxito de la autenticación y el tiempo de vida de la clave Ks. El material de

claves Ks se genera en el UE concatenando CK e IK. Tanto el UE como la BSF
utilizarán la Ks para obtener el material de claves Ks-NAF, que se utilizará para
proteger el punto de referencia Ua. El Ks-NAF se calcula como:

Ks-NAF= fKD(Ks, "gba-me," RAND, IMPI, NAF-ID) (2.10)

donde fKD es la función de derivación de claves y se implementará en el ME, y los

parámetros de derivación de claves consisten en el IMPI del usuario, el NAF-ID y
RAND. El NAF-ID consiste en el nombre DNS completo del NAF, concat-
64 Manual del subsistema multimedia fP (fM£)

enada con el identificador de protocolo de seguridad Ua. El UE y el BSF

almacenarán la clave Ks con el B-TID asociado para su uso posterior, hasta que el
tiempo de vida de Ks haya expirado o hasta que la clave Ks sea actualizada [51].

Procedimiento de uso de Bootstrapping

Antes de iniciar la comunicación entre el equipo de usuario y el NAF, el equipo de
usuario y el NAF deben acordar si van a utilizar claves compartidas obtenidas
mediante GBA. Si el UE no sabe si utilizar GBA con este utiliza el inicio del
procedimiento bootstrapping. Una vez que el equipo de usuario y el NAF deciden
que desean utilizar GBA, cada vez que el equipo de usuario desea interactuar con el
NAF, el equipo de usuario inicia la comunicación a través del punto de referencia
Ua con el NAF proporcionando el B-TID al NAF para permitir que el NAF recupere
las claves correspondientes del BSF. El NAF inicia la comunicación sobre el punto
de referencia Zn con el BSF. El NAF solicita material de claves correspondiente al
B-TID facilitado por el UE al NAF a través del punto de referencia Ua. Con la
solicitud de material clave, el NAF proporcionará al BSF el nombre de host público
del NAF que el UE ha utilizado para acceder al NAF, y el BSF podrá verificar que
el NAF está autorizado a utilizar dicho nombre de host. El NAF también puede
solicitar uno o más USS específicos de la aplicación para las aplicaciones a las que
puede acceder la solicitud recibida a través de Ua desde UE.
El BSF obtiene las claves necesarias para proteger el protocolo utilizado en el
punto de referencia Ua a partir de la clave Ks y los parámetros de derivación de
claves, y suministra al NAF la clave solicitada Ks-NAF. El BSF también suministra
el tiempo de arranque y la vida útil de dicha clave, así como los USS específicos de
la aplicación solicitados, y potencialmente específicos del grupo NAF, si están
disponibles en el GUSS del abonado y si el NAF está autorizado a recibir los USS
solicitados. Si la clave identificada por el B-TID suministrado por el NAF no está
disponible en el BSF, el BSF lo indicará en la respuesta al NAF. El NAF indicará
entonces una solicitud de renegociación de bootstrapping al UE. El BSF también
puede enviar la identidad privada del usuario (IMPI) y los USS solicitados al NAF
de acuerdo con la política del BSF. El NAF continúa con el protocolo utilizado
sobre el punto de referencia Ua con el UE. Una vez completada la ejecución del
protocolo utilizado sobre el punto de referencia Ua, se cumple el propósito del
bootstrapping porque ha permitido al UE y al NAF utilizar el punto de referencia Ua
de forma segura (Figura 2.15).

Uso del proxy de autenticación para servicios multimedia

El AP es como un NAF y realiza la función de proxy HTTP para el . Se encarga de
gestionar el TLS y de implementar el canal HTTP seguro entre el AP y el UE, como
se muestra en la figura 2.16. Utiliza el GBA para garantizar a los AS que la solicitud
procede de un abonado autorizado del operador de red móvil. Utiliza la GBA para
garantizar a los AS que la solicitud procede de un abonado autorizado del operador
de red móvil. Cuando la solicitud HTTPS se envía al AS a través del AP, éste realiza
la autenticación del UE. El AP puede insertar la identidad del usuario cuando
reenvía la solicitud al servidor de aplicaciones. La dirección
fM£-Una arquitectura segura para todas las redes fP 65

Ub
UE NAF BSF

Ua Zn

B-TID, Ks
B-TID, Ks
Perfil

Solicitar

Solicitud de inicio de arranque

Derivación de
claves Ks Ks-
NAF

App Req [B-TID, Msg]

Solicitud de autorización [B-TID,

NAF-Host].

Tiendas
Ks-NAF, Perfil, Tb,
Tk Auth Ans [Ks-NAF, Perfil, Tb, Tk]

App
Respuesta

FIGURA 2.15
Aplicación de arranque.

La segunda parte de la Figura 2.16 presenta la arquitectura de uso de AP para diferentes

servicios IMS SIP (por ejemplo, presencia, mensajería, conferencia).
El UE manipulará sus propios datos, como los grupos, a través del punto de
referencia Ua/Ut [52]. El punto de referencia Ut será aplicable a la manipulación de
datos de servicios SIP basados en IMS, como los servicios de presencia, mensajería
y con- ferenciación. Cuando el cliente HTTP inicia la comunicación a través del
punto de referencia Ua con el NAF, establecerá un túnel TLS con el NAF. El NAF
se autentica ante el cliente HTTP mediante un certificado de clave pública. El
cliente HTTP verificará que el certificado del servidor se corresponde con el FQDN
del AP con el que estableció el túnel.
Explicamos brevemente el procedimiento. El cliente HTTP envía una petición
HTTP a NAF dentro del túnel TLS. En respuesta a la solicitud HTTP a través de la
interfaz Ua, el AP invocará el resumen HTTP con el cliente HTTP para
66 Manual del subsistema multimedia fP (fM£)

AS1 AS2 AS3 ASn-1 ASn

BSF
HSS
Túnel TLS

Ua Zn Zh

UF AP/NAF

Presencia Mensajería Conferencias Otros servicios

Ut

Za/Zb

BSF
HSS

Zn Zh
FIGURA 2.16 Ua
Proxy de autenticación.
Túnel TLS
UF AP

para realizar la autenticación del cliente utilizando las claves compartidas. Al recibir
el resumen HTTP del AP, el cliente verificará que el FDQN corresponde al AP con
el que estableció la conexión TLS. Si no es así, el cliente terminará la conexión TLS
con el AP. De este , el equipo de usuario y el punto de acceso se autentican
mutuamente como extremos del túnel TLS.
Ahora discutiremos un ejemplo en el que la aplicación que reside en la UICC
puede utilizar TLS sobre HTTP en el mecanismo GAA para asegurar su
comunicación con el AP. La asociación de seguridad GBA entre una aplicación
basada en el UICC y el AP puede establecerse de la siguiente manera. El ME ejecuta
el procedimiento de bootstrapping con el BSF que soporta el punto de referencia Ub.
La UICC, que aloja el cliente HTTP, ejecuta el procedimiento de uso de
bootstrapping con el AP que soporta el punto de referencia Ua [76]. La Figura 2.17
muestra el uso de BIP (bearer independent protocol) para establecer la conexión
HTTPS entre el UICC y el AP. Cuando la UICC abre un canal con el
fM£-Una arquitectura segura para todas las redes fP 62

UICC AP/NAF

ME

Aplicación Aplicación

Solicitud HTTPS Digest

HTTP HTTPS Respuesta HTTP

HTTPS

Puntos finales del túnel TLS

TLS TLS

BIP Abrir canal OK

PIF [Canal nº] PIF

Enviar datos

Paquetes TCP/IP (envío de

datos)
TCP/IP TCP/IP

Paquetes TCP/IP (recepción de

datos)

FIGURA 2.17
Procedimientos HTTPS y BIP (bearer independent protocol).

AP, como se describe en la referencia 77, se establece una conexión TCP/IP activa
entre la UICC y el AP.

Referencias
1. 3rd Generation Partnership Project Technical Specification Group Servicesand Sys- tem
Aspects, 3GPP, TS 23.228 V6.7.0 (2004-09), IP multimedia subsystems (IMS).
2. Proyecto de Asociación de Tercera Generación (3GPP). [Link]
3. Proyecto de Asociación de 3ª Generación 2 (3GPP2). [Link]
4. Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks,
M. Handley, y E. Schooler. 2002. SIP: Session initiation protocol, IETF RFC 3261 (junio de
2002).
68 Manual del subsistema multimedia fP (fM£)

5. Calhoun, P., J. Loughney, E. Guttman, G. Zorn y J. Arkko. 2003. DIAMETER base protocol,
IETF RFC 3588 (Sep. 2003).
6. Morelli, A. 2006. El papel de una plataforma de prestación de servicios en la batalla por
los nuevos ingresos de la comunicación. Outlook Point of View.
7. Poikselkae, M., G. Mayer, H. Khartabil y A. Niemi. 2004. The IMS, IP mul- timedia
concepts and services in the mobile domain. West Sussex, Inglaterra: John Wiley & Sons
Ltd.
8. Sher, M., F. Gouveia y T. Magedanz. 2007. Subsistema multimedia IP (IMS) para redes all-
IP emergentes. Encyclopedia of Internet Technologies and Applica- tions. IGI Global,
anteriormente Idea Group Inc.
9. ETSI TISPAN (Telecommunications and Internet Converged Services and Pro- tocols
for Advanced Networking) WG. [Link]
10. Foro UMTS. [Link]
11. Foro DSL . [Link]
12. Alianza para la convergencia fijo-móvil (FMC). [Link]
13. Centro de Competencia Móvil del ETSI. 2003. Overview of 3GPP release 5, resumen de todas
las características de la versión 5. [Link]
[Link]#3GRelease5
14. Centro de Competencia Móvil del ETSI. 2006. Overview of 3GPP release 6, resumen de todas
las características de la versión 6. [Link]
[Link]#3GRelease6
15. Geneiatakis, D., T. Dagiuklas, G. Kambourakis, C. Lambbrinoudakis, S. Gri- tizalis, S.
Ehlert y D. Sisalem. 2006. Estudio de las vulnerabilidades de seguridad del protocolo SIP.
IEEE Communication Surveys 8(3):68-81.
16. Magedanz, T., K. Knüttel y D. Witszek. 2005. The IMS playground @ Fokus- An open
testbed for next-generation network multimedia services. 1st Interna- tional IFIP Conference
on Testbeds and Research Infrastructures for the Development of Networks and Communities
(Tridentcom), 2-11. Trento, Italia, 23-25 de febrero. Trento, Italia, 23-25 de febrero. IEEE
Computer Society Press, Los Alamitos, CA.
17. Schulzrinne, H., S. Casner, R. Frederick y V. Jacobson. 2003. RFC 3550 RTP. Un protocolo de
transporte para aplicaciones en tiempo real.
18. Rescorla, E. 2000. HTTP sobre TLS. IEFT RFC 2818.
19. Klensin, J., ed. 2001. Protocolo simple de transferencia de correo, IETF RFC 2821.
20. Grupo de Trabajo AAA del IETF. IETF Authentication, Authorization and Account- ing
(AAA) Working Group (consultado en 2007). [Link] [Link]
21. Rigney, C., S. Willens, A. Rubens y W. Simpson. 2000. Remote authentication dial-in user
service (RADIUS), IETF RFC 2865.
22. Loughney, J. 2003. DIAMETER command codes for 3rd Generation Partnership Project
(3GPP) release 5, RFC 3589.
23. Bellovin, S., J. Ioannidis, A. Keromytis y R. Stewart. 2003. On the use of stream control
transmission protocol (SCTP) with IPSec, IETF, RFC 3554.
24. Berners-Lee, T., R. Fielding y L. Masinter. 2005. Uniform resource identifier (URI):
Generic syntax, IETF RFC 3986.
25. Proyecto de Asociación de 3ª Generación. Especificación técnica, 3GPP, TS 29.208, flujos
de señalización de calidad de servicio (QoS) de extremo a extremo.
26. Camarillo, G., y M. A. García-Martín. 2006. The 3G IP multimedia subsystem (IMS)-
Merging the Internet and the cellular worlds (El subsistema multimedia IP 3G (IMS): fusión
de Internet y el mundo celular), 2.ª ed., Madrid. Chichester, Inglaterra: John Wiley & Sons
Ltd.
fM£-Una arquitectura segura para todas las redes fP 69

27. Magedanz, T., y M. Sher. 2006. IT-based open service delivery platforms for mobile
networks-From CAMEL to the IP multimedia system. En Mobile Mid- dleware, ed., P.
Bellavista y A. Corradi. P. Bellavista y A. Corradi. Boca Ratón, FL: Chapman & Hall/CRC
Press.
28. Arquitectura de servicio abierto OSA/parlay parlay. [Link]
[Link]
29. Magedanz, T., y R. Popescu-Zeletin. 1996. Intelligent networks-Basic technology, standards
and evolution. Londres: International Thomson Computer Press.
30. Alianza móvil abierta. OMA: El principal foro del sector para el desarrollo de
habilitadores de servicios móviles interoperables y orientados al mercado.
[Link] [Link]/
31. Proyecto de Asociación de 3ª Generación. Presence service, architecture and func- tional
description (release 6), 3GPP TR 23.841, V6.0.0. (2002-07).
32. Blum, N., y T. Magedanz. 2005. Push-to-video as a platform for NGN ser- vices. 11th
European Wireless 2005-Next Generation Wireless and Mobile Commu- nications and Services.
Nicosia, Chipre, 10-13 de abril.
33. Knuettel, K., T. Magedanz y L. Xie. 2006. SIP servlet execution environment (SIPSEE)-An
IMS/NGN SIP AS for converged applications. Conferencia ICIN07, Burdeos, Francia.
34. Magedanz, T. 2005. Tutorial IEEE ISCC. IEEE Symposium on Computer and Com- munications,
España, 27 de junio.
35. Jain, R., J.-L. Bakker y F. Anjum. 2005. Programming converged networks-Call control in Java,
XML, and Parlay/OSA. Hoboken, NJ: John Wiley & Sons, Inc.
36. Bonica, R., D. Gan, D. Tappan y C. Pignataro. 2007. Extended ICMP to sup- port multi-part
messages, IETF RFC 4884.
37. Wu, Y.-S., S. Bagchi, S. Garg, N. Singh y T. Tsai. 2004. SCIDIVE: A stateful and cross
protocol intrusion detection architecture for voice-over-IP environments.
38. Zhang, M., y Y. Fang. 2005. Security analysis and enhancement of 3GPP authentication and
key agreement protocol. IEEE Transactions on Wireless Com- munication 4(2):1276-1536.
39. Herramientas de bajo coste para servicios de comunicación VoIP seguros y de alta
disponibilidad (SNOCER). 2005. Proyecto de investigación financiado por el Sexto
Programa Marco de la Comisión Europea. [Link]
40. Niemi, A., J. Arkko y V. Torvinen. 2002. HTTP digest authentication using AKA, IETF
RFC 3310.
41. Chen, E.Y. 2006. Detección de ataques DoS en sistemas SIP. IEEE Workshop on VoIP
Management and Security, 53-58.
42. Sher, M., S. Wu y T. Magedanz. 2006. Security threats and solutions for applica- tion server of IP
multimedia subsystem (IMS-AS). IEEE/IST Workshop on Monitor- ing, Attack Detection and
Mitigation. MonAM06 Proc. IEEE/IST, ISBN: 3-937201-02-5, ISSN: 1862-7803, Diadem Firewall
Project (FP6 IST-2002-002154), 38-44, Tubinga, Alemania, 28-29 de septiembre.
[Link]
43. Sparks, R. 2004. The session initiation protocol (SIP) referred-by mechanism, IETF RFC
3892.
44. Proyecto de Asociación de 3ª Generación. 2004. Technical specification group ser- vices and
system aspects; 3G security; security architecture (release 6); 3GPP, TS 33.102 V6.
45. Gurbani, V., y A. Jeffrey. 2006. Draft-gurbani-sip-tls-use-00: The use of trans- port layer
security (TLS) in the session initiation protocol (SIP).
20 Manual del subsistema multimedia fP (fM£)

46. Kent, S., y R. Atkinson. 1998. Arquitectura de seguridad para el protocolo de Internet,
IETF RFC 2401.
47. Sher, M., y T. Magedanz. 2006. Development of IMS privacy and security management
framework for FOKUS open IMS testbed. Journal of Mobile Multi- media 2(3):225-258.
[Link]
48. Proyecto de Asociación de 3ª Generación. Technical specification group services and system
aspects, 3GPP, TS 33.210, network domain security (NDS); IP network layer security V6.5.0
(2004-06).
49. Proyecto de Asociación de 3ª Generación. 2005. Technical specification group ser- vices and
system aspects; generic authentication architecture (GAA); generic bootstrapping
architecture (GBA) (versión 7), 3GPP TS 33.220 V7.
50. Proyecto de Asociación de 3ª Generación. 2005. Technical specification group ser- vices
and system aspects; generic authentication architecture (GAA); access to network
application functions using hypertext transfer protocol over transport layer security
(HTTPS) (release 7), 3GPP TS 33.222 V7.
51. Giovanni, V. et al. 2003. A stateful intrusion detection system for World-Wide Web
servers (WEBSTAT).
52. SIPSEE (SIP servlet execution environment) es el desarrollo de FOKUS de un servidor de
aplicaciones SIP (SIP AS) basado en la tecnología SIP Servlet. 2006, [Link]
[Link]/bereichsseiten/testbeds/ims_playground/components/ [Link]
53. Jetty, un servidor Web de código abierto, basado en estándares y con todas las
funciones, [Link] [Link]/jetty/[Link]
54. Proyecto de Asociación de Tercera Generación. Technical specification group services and
system aspects, 3G security; access security for IP-based services (release 6), 3GPP, TS
33.203 V6.4.0 (2004-09).
55. Kent, S., y K. Seo. 2005. Arquitectura de seguridad para el protocolo de Internet, IETF
RFC 4301.
56. Arkko, J., V. Torvinen, G. Camarillo, A. Niemi y T. Haukka. 2003. Security mechanism
agreement for the session initiation protocol (SIP), IETF RFC 3329.
57. S. Kent, S. 2005. IP encapsulating security payload (ESP), IETF RFC 4303.
58. Madson, C., y R. Glenn. 1998. The use of HMAC-MD5-96 within ESP and AH, IETF RFC
2403.
59. Madson, C., y R. Glenn. 1998. The use of HMAC-SHA-1-96 within ESP and AH, IETF RFC
2404.
60. Niemi, V. y K. Nyberg. 2003. UMTS security. West Sussex, Inglaterra: John Wiley &
Sons Ltd.
61. Pereira, R., y R. Adams. 1998. The ESP CBC-mode cipher algorithms, IETF RFC 2451.
62. Frankel, S., R. Glenn, y S. Kelly. 2003. The AES-CBC cipher algorithm and its use with
IPSec, IETF RFC 3602.
63. Proyecto de Asociación de 3ª Generación. Technical specification group services and system
aspects, 3GPP, TS 33.210, network domain security (NDS); IP network layer security V6.5.0
(2004-06).
64. Sher, M., T. Magedanz y W. T. Walter. 2006. Interdomains security management (IDSM)
model for IP multimedia subsystem (IMS). IEEE 1st International Conference on
Availability, Reliability & Security, Viena, Austria, 20-22. 2006. IEEE/ ARES2006
Proceedings ISBN 978-0-7695-2567-9, pp. 502-509, abril de 2006.
65. Kaufman, C., ed. 2005. Internet key exchange (IKEv2) protocol, IETF, RFC 4306.
fM£-Una arquitectura segura para todas las redes fP 21

66. Maughan, D., M. Schertler, M. Schneider y J. Turner. 1992. ISAKMP: Internet security
associations and key management protocol, IETF, RFC 2408.
67. Sher, M., y T. Magedanz. 2006. Developing network domain security (NDS) model for IP
multimedia subsystem (IMS). Journal of Networks 1(6):10-17.
68. Proyecto de asociación de tercera generación. Technicalspecification, networkdomainsecu-
rity (NDS); authentication framework (AF) release 7 TS 33.310 V7.1.0 (2006-09).
69. Karn, P., P. Metzger y W. Simpson. 1995. The ESP triple DES (3DES) trans- form,
IETF, RFC 1851.
70. Stallings, W. 2005. Cryptography and network security, 4ª ed., Upper Saddle River, NJ:
Prentice Hall. Upper Saddle River, NJ: Prentice Hall.
71. Rivest, R. 1992. MD5: Algoritmo de compendio de mensajes, IETF RFC 1321.
72. Piper, D. 1998. The Internet IP security domain of interpretation for ISAKMP, IETF
RFC 2407.
73. Kiran, S., P. Lareau y S. Lloyad. 2002. PKI basics-A technical perspective.
[Link]
74. Santesson, S., y R. Housley. 2005. IETF RFC 4325, Internet X.509 public key
infrastructure authority information access certificate revocation list (CRL) extension
2005.
75. Housley, R., W. Polk, W. Ford y D. Solo. 2002. IETF RFC 3280, Certificado de
infraestructura de clave pública Internet X.509 y perfil de lista de revocación de certificados
(CRL).
76. Proyecto de Asociación de 3ª Generación. 2005. Technical specification, generic
authentication architecture (GAA); early implementation of HTTPS connection between
a universal integrated circuit card (UICC) and network application function (NAF)
(release 7), 3GPP TR 33.918 V7.
77. Proyecto de Asociación de 3ª Generación. 2005. Technical specification, universal subscriber
identity module (USIM) application toolkit (USAT) (release 7), 3GPP TS 31.111 V7.
78. Proyecto de Asociación de 3ª Generación. 2004. Especificación técnica, seguridad 3G;
especificación del conjunto de algoritmos MILENAGE: Un conjunto de algoritmos de
ejemplo para las funciones 3GPP de autenticación y generación de claves f1, f1*, f2, f3, f4,
f5 y f5*; documento 2: especificación de algoritmos, 3GPP TS 35.206 V 6.0.0.
79. Núcleo de subsistema multimedia IP (IMS) de código abierto. Lanzamiento oficial
en 2006. [Link]
80. Zona de juegos del subsistema multimedia IP abierto (IMS). 2003-2007, [Link]
[Link]/ims/[Link]?lang=en
81. Enrutador exprés SIP (SER). 2001-2007, [Link]
82. Utilización global de los recursos del sistema Linux. [Link]
83. Protección de cortafuegos mediante tablas IP. 1999-2007. El webmaster de Netfilter.
http:// [Link]/
84. Cliente IMS desarrollado por UCT/FOKUS. 2006. [Link]
85. Herramienta de prueba SIP de código abierto. [Link]
86. Especificación técnica del Proyecto de Asociación de Tercera Generación. Interfaz Sh
basada en el protocolo DIAMETER (versión 7), 3GPP TS 29.329 V 7.3.0. (2006-09).
87. Banco de pruebas 3Gb national host third generation and beyond. 2003. [Link]
[Link]/bereichsseiten/testbeds/national_host/testbed/testbed. php?lang=en
88. Knuttel, K., T. Magedanz y L. Xie. 2006. SIP servlet execution environment (SIPSEE)-An
IMS/NGN SIP AS for converged application. International Confer- ence on Intelligence in
Networks, ICIN, Burdeos, Francia.
22 Manual del subsistema multimedia fP (fM£)

89. Wu, Y.-S., S. Bagchi, S. Garg, N. Singh y T. Tsai. 2004. SCIDIVE: A stateful and cross
protocol intrusion detection architecture for voice-over-IP environments.
90. SIP forum test framework (SFTF), un software de pruebas para SIP. Enero de 2007.
[Link] [Link]
91. La seguridad 3GPP TSG SA WG3. 2003. Propuesta de confidencialidad para IMS, Sophia-
Antipolis, Francia.
92. [Link]
lis/Docs/PDF/[Link]
93. Universidad del Sur de California y VeriSign. Building a security frame- work for
delivery of next-generation network services. 2005. [Link]
[Link]/static/[Link]
94. Estado de Radu. 2007. Nueva frontera en la seguridad de VoIP y gestión de edificios y
soluciones de seguridad de la Internet del mañana. Proyecto de investigación Madynes, INRIA
Nancy Universités Centre de Recherché Grand Est., Francia. [Link]
95. Centro de Seguridad de la Información Tecnológica de Georgia (GTISC). 2007. Emerging cyber
threats report for 2008 USA, octubre de 2007. [Link]
pdf/GTISC%20Cyber%20Threats%[Link]
96. Informe técnico de seguridad de Sipera. 2007. Proteger las redes IMS de los ataques: Los
operadores necesitan algo más que cifrado y autenticación. [Link] com
97. Verizon y Cisco. 2006. Advances to IP multimedia subsystem (A- IMS) architecture,
libro blanco, junio de 2006. [Link] com/content/view/4212/
98. Juniper Networks. Solution brief-How juniper networks enable intelligent, secure, and
open IMS-FMC networks, septiembre de 2006, [Link]
net/solutions/literature/solutionbriefs/[Link]
99. Acme Packet. 2007. DoS/DDoS Protection for IMS Core Elements, junio de 2007.
[Link] 43D1-9847-
6253984B1671%7D
100. Fiedler, J., T. Kupka, S. Ehlert, T. Magedanz y D. Sisalem. 2007. VoIP defender: Highly
scalable SIP-based security architecture, IPTComm, Nueva York. [Link]
101. Fraunhofer FOKUS Open Research Communication Institute, Berlín, http://
[Link]/home/[Link]?lang=en
102. Nokia Siemens Networks. 2007. Descripción e información técnica de IMS, A50016-D3605-
X20-1-7618, Id: 0900d80580129f8e.
103. Sistema de detección de intrusos basado en IP y en red de código abierto. SNORT 2005-
2006. [Link]
3
Funciones P2P en el subsistema
multimedia fP

Adetola Oredope y Antonio Liotta

CONTENIDO
Introducción ......................................................................................................................... 73
Tecnología de igual a igual .................................................................................................. 75
Red estructurada p2p ................................................................................................ 75
Red superpuesta p2p no estructurada .....................................................................77
Asignación de aplicaciones p2p al IMS................................................................. 78
Casos prácticos: Implantación de p2p como servicio IMS ........................................... 80
Caso práctico I: superposiciones p2p sobre el IMS ............................................. 80
Estudio de caso II: p2p en el núcleo de IMS.......................................................... 81
Perspectivas y conclusión .................................................................................................. 83
Referencias ............................................................................................................................ 84

Introducción
El subsistema multimedia IP (IMS) es marco arquitectónico centrado en el servicio cuyo
objetivo es proporcionar servicios de Internet actuales y futuros a usuarios finales
fijos y móviles a través de una plataforma multiacceso totalmente IP [1]. Estos
servicios de Internet incluyen voz sobre IP (VoIP), mensajería instantánea, push-to-
talk, conferencias multimedia, aplicaciones peer-to-peer (p2p) y juegos en línea, por
mencionar algunos. El IMS permite integrar los servicios de Internet existentes con
los futuros. Soporta servicios ricos y personalizados para el usuario final,
independientemente de la red de acceso o las capacidades del terminal.
El principal habilitador del IMS es el protocolo de iniciación de sesión (SIP)
estandarizado por el Internet Engineering Task Force (IETF) [2], que es el núcleo del
marco arquitectónico del IMS, debido a su simplicidad y extensibilidad. El propósito
principal de SIP en el IMS es la creación, gestión y terminación de sesiones
multimedia, tanto dentro como fuera del IMS. SIP es actualmente el

73
24 Manual del subsistema multimedia fP (fM£)

plataforma principal para el desarrollo de servicios multimedia nuevos y dinámicos

a través de Internet [1].
Gracias a estas características de SIP, la mayoría de las aplicaciones de Internet
existentes pueden desplegarse fácilmente y sin problemas en el IMS con pocas o
ninguna modi- ficación. Sin embargo, desde el punto de vista del rendimiento y la
escalabilidad, no todas las aplicaciones podrán beneficiarse plenamente del IMS. En
este capítulo nos centraremos especialmente en las aplicaciones p2p, teniendo en
cuenta los aspectos arquitectónicos y de despliegue.
A diferencia de las aplicaciones cliente-servidor, los sistemas p2p no dependen de
ningún servidor específico y se caracterizan por flujos de señalización y datos que
no siempre pueden preverse de forma determinista [3,4]. Por ejemplo, las
aplicaciones de intercambio de archivos basadas en el paradigma p2p mantienen una
estructura de datos dinámica, que permite a cualquier terminal (o peer) actuar como
fuente (servidor) y receptor (cliente) de datos. Este modelo representa un choque
fundamental si se compara con la arquitectura IMS, que es intrínsecamente cliente-
servidor y pretende mantener la aplicación bajo control. Las aplicaciones p2p se
realizan como redes superpuestas que funcionan independientemente de la
infraestructura subyacente y no están controladas por el operador de la red, un
problema también conocido como "desintermediación del operador".
A pesar de no ser ideales desde el punto vista del operador, las aplicaciones p2p
no pueden ignorarse debido a su popularidad. Estudios recientes han demostrado
que las aplicaciones p2p, incluidos los servicios de intercambio de archivos y
streaming, son responsables de gran parte del tráfico de Internet [3]. Por tanto,
hemos llegado a un punto en el que es razonable suponer que las aplicaciones p2p
pronto tendrán que ser soportadas también por el IMS.
En el lado positivo, el operador puede utilizar los servicios p2p como una
oportunidad para crear una gran cantidad de nuevos servicios de telecomunicaciones
inspirados en las aplicaciones p2p existentes, pero que incorporen las ventajas de un
entorno seguro y de confianza. Para hacer realidad este potencial, el IMS debe
ofrecer funcionalidades p2p fundamentales y exponer capacidades de habilitación
p2p.
Prevemos dos enfoques principales para el desarrollo de servicios p2p a través del
IMS. Las aplicaciones p2p pueden realizarse como una red superpuesta construida
sobre la arquitectura IMS existente. Alternativamente, un enfoque más radical sería
embarcarse en la tarea de ampliar el núcleo IMS para proporcionar soporte p2p
intrínseco. Estos dos escenarios se presentan mediante casos prácticos que se han
evaluado en un banco de pruebas de laboratorio (sección "Casos prácticos"). Para el
lector no especializado, la siguiente sección ofrece una visión general del p2p desde
el punto de vista de los enfoques arquitectónicos y su relación con Internet y la
arquitectura IMS. En la última sección se ofrece una perspectiva de los desarrollos
futuros y se analizan cuestiones como la seguridad, la tarificación y la movilidad, y
cómo pueden afectar al despliegue del servicio p2p en el IMS.
Funciones P2P en el subsistema multimedia fP 25

Tecnología de igual a igual

La tecnología peer-to-peer puede definirse como una plataforma que permite a
nodos distribuidos con intereses o motivos similares comunicarse e intercambiar
información entre sí sin la intervención de un sistema centralizado [3,5]. Esto se
consigue construyendo conexiones lógicas entre los nodos participantes a nivel de
aplicación para formar una red superpuesta. Las tecnologías p2p se han utilizado en
servicios como VoIP, videoconferencia, gestión de redes e intercambio de archivos.
La arquitectura de Internet se diseñó inicialmente sobre la base de un enfoque
p2p, pero a medida que crecía, el uso de servidores y servicios centralizados
permitió a los proveedores de servicios de Inter- net ampliar sus redes para hacer
frente al creciente número de usuarios. Con el paso de los años, los enfoques p2p se
han desarrollado considerablemente, aportando características esenciales como la
escalabilidad y la redundancia. Estas características hacen del p2p la plataforma
ideal para el despliegue de servicios de alta disponibilidad a un coste menor que sus
homólogos cliente-servidor. En esta sección analizamos varios enfoques p2p bajo
dos grandes categorías: redes superpuestas p2p estructuradas y no estructuradas. A
continuación, analizamos los retos que plantea el despliegue de servicios p2p en el
IMS mediante la asignación de la red superpuesta p2p analizada a la arquitectura
IMS.

Red estructurada p2p

En este enfoque, la red superpuesta p2p se construye utilizando claves generadas a
partir de varios algoritmos hash. Los datos y los nodos suelen someterse a hash para
proporcionar claves únicas. Cada dato (por ejemplo, un archivo) del sistema se
asigna a una clave; la clave se asigna a un nodo. Diferentes implementaciones
utilizan diversas teorías de grafos para recuperar las claves de estos nodos [3]. La
principal limitación de este método es que, debido a su enfoque determinista, sólo se
pueden recuperar coincidencias exactas de búsquedas o consultas. Las consultas
complejas serán difíciles de conseguir, aunque se están dedicando importantes
esfuerzos de investigación al desarrollo de algoritmos que resuelvan consultas
complejas [6,7]. Muchas de las aplicaciones más populares adoptan el enfoque
estructurado. Algunos ejemplos son Chord [8], content addressable network (CAN)
[9], Kademlia [10], Tapestry [11] y Pastry [12].
Chord [8] utiliza hashing consistente basado en la función hash SHA-1 para
proporcionar sus claves únicas. Estas claves se basan en un identificador de m bits lo
suficientemente largo como para evitar la duplicación. También proporciona a cada
peer un número igual de claves para equilibrar la carga en el sistema y sólo permite
un pequeño movimiento de claves cuando los nodos se unen y abandonan la
superposición. Todos los identificadores se organizan en un círculo de
identificadores de módulo 2*m, que se conoce como anillo de acordes. Esto permite
que el coste de búsqueda en la superposición de N pares sea O(log N), lo que
convierte a Chord en una plataforma altamente escalable. Chord se ha utilizado en
26 Manual del subsistema multimedia fP (fM£)

diversas aplicaciones, como el mirroring cooperativo (sistema de archivos

cooperativo) [13], que permite distribuir datos entre varios proveedores de
contenidos para equilibrar la carga. También se utiliza en Chord-Domain Name
System (DNS) [14], que es similar al DNS basado en Internet para buscar nombres
de host a partir de direcciones IP.
Otro enfoque es el propuesto por las redes direccionables de contenido (CAN) [9],
diseñadas para ser altamente escalables, tolerantes a fallos y autoorganizadas. Se
basa en un espacio de coordenadas cartesianas virtual y multidimensional en un
mul- titoro en el que a cada par se le asigna una zona única e individual en el
espacio global. El punto P del peer en el espacio de coordenadas se compone de la
clave k y el valor v (es decir, el par {k,v}), por lo que k se mapea en P utilizando una
función hash uniforme. Cada peer también almacena la dirección IP y los valores de
coordenadas de sus vecinos y utiliza un algoritmo codicioso para dirigir los
mensajes hacia ellos. CAN tiene su propio servicio DNS [9] que permite a los pares
que se unen a la superposición localizar los nodos de arranque más cercanos a ellos.
Para implementar la redundancia y la tolerancia a fallos en CAN, cada peer se
asigna a diferentes coordi- nados únicos; esto se conoce como realidad [3]. CAN se
ha utilizado en la implementación de sistemas de gestión de almacenamiento a gran
escala como Oceanstore [15], Farsite [16] y Publius [17], que requieren la inserción
y recuperación eficiente de grandes volúmenes de datos.
Del mismo modo, Tapestry [11] es autoorganizativo y tolerante a fallos y utiliza el
enfoque de la aleatoriedad descentralizada para lograr la distribución de la carga y el
enrutamiento localizado. También proporciona alta disponibilidad, escalabilidad y
adaptabilidad ante fallos o ataques. Esto se consigue incluyendo mecanismos
adicionales a la técnica de búsqueda distribuida de Plaxton, conocida como Plaxton
mesh [11], que se basa en un único nodo raíz estático donde los mensajes se enrutan
en el overlay a través de los otros peers. En Tapestry, se utilizan múltiples nodos
raíz distribuidos para mejorar la disponibilidad. También se utiliza una técnica
conocida como enrutamiento sustituto para localizar los servidores raíz en caso de
fallos. La redundancia se consigue mediante la replicación de datos. Tapestry se ha
desplegado en aplicaciones como OceanStore [15], una aplicación de
almacenamiento global que encuentra la réplica de documentos más cercana
basándose en la métrica de distancia más cercana. Se utiliza en Bayeux
[18] para la multidifusión a nivel de aplicación y en SpamWatch [19] para
implementar un sistema descentralizado de filtrado de spam.
Pastry [12] es muy similar a Tapestry porque también está construido sobre la malla de
Plaxton, pero se basa en un identificador de pares de 128 bits. Los nodos se colocan
en un espacio nodeID cir- cular. Cada nodo mantiene un conjunto de hojas además
de los conjuntos de vecindad y enrutamiento que se mantienen en Tapestry. Pastry
se ha implementado en Scribe [20] (para multidifusión a nivel de aplicación),
SplitStream
[21] (para entornos cooperativos multidifusión), PAST [22] (para almacenamiento
distribuido) y Pastiches [37] (para copias de seguridad baratas y distribuidas).
La arquitectura de Kademlia [10] se basa en un espacio de claves de 160 bits en el
que utiliza su novedosa métrica XOR para calcular la distancia entre diferentes
puntos del espacio de claves. Los pares {clave, valor} se almacenan en pares que
tienen su ID de nodo cerca de la clave. Su principal implementación se encuentra en
Overnet [23], que
Funciones P2P en el subsistema multimedia fP 22

es el protocolo base de varias aplicaciones comerciales de intercambio de archivos,

como eMule [24].

Red superpuesta p2p no estructurada

En este enfoque, los pares se organizan en un grafo aleatorio utilizando un modelo
plano o jerárquico. En algunos casos, las consultas inundan toda la red superpuesta.
Alternativamente, las consultas pueden dirigirse a determinados nodos (de acuerdo
con algunos criterios) o incluso pueden dispararse a un conjunto aleatorio de pares.
Algunas implementaciones utilizan un anillo expansivo de paquetes de tiempo de
vida para evitar que las consultas den vueltas en bucle. El descubrimiento de recursos
en overlays no estructurados es ineficaz, especialmente si el contenido a localizar es
raro [3]. Además, cada peer visitado por el mesaje de consulta necesita evaluar las
consultas, incurriendo en una sobrecarga innecesaria. Aunque los mecanismos de
búsqueda de los overlays p2p no estructurados tienden a ser ineficientes, tienen la
ventaja de poder resolver consultas complejas.
Los enfoques de superposición p2p no estructurados más comunes son BitTorrent,
FastTrack, Freenet y Gnutella. BitTorrent [25] se diseñó principalmente para disuadir
a los "free riders" de la red superpuesta. Se basa en un enfoque de "ojo por ojo" que
permite a los pares con alta velocidad de carga acceder a altas velocidades de
descarga. Utiliza un rastreador, que es como un nodo centralizado, que gestiona las
descargas de los usuarios y hace un seguimiento de los pares que tienen un archivo
concreto. El rastreador también responde a las consultas de búsqueda que conectan a
los pares de la superposición. La principal ventaja de BitTorrent es que divide los
archivos grandes en trozos más pequeños, lo que permite a los usuarios descargar
diferentes partes de varios usuarios en paralelo, con lo que las descargas son más
rápidas.
FastTrack es utilizado por algunas de las aplicaciones de intercambio de archivos
p2p más populares, como Kazaa [26], Grokster [27] e iMesh [28]. También se ha
extendido a servicios VoiP como Skype [29] y servicios multimedia como Joost
[30]. La principal ventaja de FastTrack es que admite la búsqueda de metadatos y se
basa en un enfoque jerárquico, utilizando nodos con gran ancho de banda, espacio
en disco y capacidad de procesamiento como nodos raíz. Estos , conocidos como
supernodos, se organizan como una superposición estructurada. Los nodos
ordinarios publican metadatos relativos a sus propios archivos con los supernodos.
De este , cuando otros nodos ordinarios buscan archivos concretos, pueden
simplemente consultar a los supernodos. Si no hay resultados, la consulta se
extiende a la superposición estructurada.
Freenet[31] ofrece las ventajas del anonimato y la capacidad de adaptarse a
distintas condiciones de red. Cada uno de los pares de la superposición mantiene una
tabla de enrutamiento dinámica para la superposición y también utiliza paquetes hop-to-
live (HTL) para evitar cadenas infinitas. Freenet se utiliza sobre todo en aplicaciones
de intercambio de archivos.
Gnutella [32] se basa en una topología plana en la que los pares de la
superposición pueden asumir el papel de servidor o de cliente. Una vez que un nodo
está conectado, inunda la red con mensajes de difusión para conocer a sus vecinos.
Una vez conocidos sus vecinos, el nodo envía periódicamente mensajes PING para
descubrir otros nodos participantes. Las consultas también se realizan inundando la
red superpuesta. Aunque este enfoque no es escalable y genera
28 Manual del subsistema multimedia fP (fM£)

mucho tráfico, hace que la superposición sea altamente redundante porque sólo los
nodos disponibles participan en el proceso de localización de recursos. Este enfoque
hace que la red sea muy resistente, ya que las continuas "altas" y "bajas" de nodos
apenas afectan a los procedimientos de búsqueda. La última versión de Gnutella
utiliza la noción de super-peer y ultra-peer, que son sinónimos de los supernodos de
FastTrack, como ya se ha comentado. El uso de Gnutella es bastante común en
aplicaciones de intercambio de archivos como LimeWire [33]. Se utiliza como
plataforma básica para PeerCast [34], una aplicación de streaming multimedia p2p.

Asignación de aplicaciones p2p al IMS

El IMS es un marco arquitectónico estandarizado de red de próxima generación
(NGN) definido por el Proyecto de Asociación de Tercera Generación (3GPP) para
salvar la brecha tradicional entre las redes de conmutación de circuitos y las de
conmutación de paquetes y consolidar ambos lados en una única red totalmente IP
para todos los servicios. En esta sección, examinamos los efectos de la asignación
de una solución p2p genérica sobre el IMS, considerando cómo afecta a propiedades
p2p como la escalabilidad, la resistencia y la redundancia.
El IMS emplea SIP [2], definido por el IETF, como protocolo de control de llamadas. SIP
es el protocolo general de señalización de Internet para crear, modificar y finalizar
sesiones multimedia entre dos o más participantes. Como protocolo de extremo a
extremo, los mensajes SIP se enrutan a través de un proxy SIP desde las entidades
SIP originales a las entidades SIP de destino.
Como ya se ha comentado, el IMS proporciona una plataforma convergente para el
despliegue de los servicios de Internet actuales y futuros. Aunque la mayoría de
estos servicios de Internet deberían funcionar "nada más sacarlos de la caja" sobre
una plataforma IMS, algunos servicios, como las aplicaciones p2p, no siguen esta
norma. Esto se debe a diversas limitaciones, como la arquitectura de la plataforma
IMS, los efectos de la movilidad en las aplicaciones p2p y las variaciones en las
capacidades de los nodos de la plataforma IMS. El análisis de los problemas que
surgen cuando p2p interactúa con el IMS es, por tanto, importante en vista de la
prominencia de los servicios p2p.
El IMS se basa en una arquitectura muy centralizada en la que varios servidores
SIP se sitúan en distintos niveles. Estos servidores en el núcleo IMS también son
responsables de todas las formas de gestión de sesiones y datos en el IMS. Además,
los clientes IMS acceden a los servicios a través del núcleo IMS. Esto da al núcleo
IMS el control total de la plataforma. La principal ventaja de este enfoque es que la
plataforma es muy segura y puede ofrecer más fácilmente servicios personalizados
porque todos los servicios se despliegan a través de un sistema centralizado.
Aunque esto funciona bien para algunos servicios de Internet, supone un cuello de
botella para las aplicaciones p2p. Como se muestra en la figura 3.1, las aplicaciones p2p
realizan conexiones logísticas de los pares participantes a nivel de aplicación sin
tener en cuenta la arquitectura de red subyacente. El principal problema es que todas
las formas de señalización y datos p2p siguen teniendo que ir a través del núcleo
IMS, pasando por los servidores IMS. Esto genera mucho tráfico hacia el núcleo
IMS, consumiendo recursos importantes que podrían dedicarse a otros fines.
Funciones P2P en el subsistema multimedia fP 29

IMS
Red principal

Red superpuesta

FIGURA 3.1
Asignación de superposiciones p2p a la plataforma IMS.

servicios. Otra limitación de este enfoque surge si la aplicación p2p se extiende a

través de múltiples plataformas IMS. La construcción y mantenimiento de
superposiciones p2p en redes externas sería potencialmente costosa debido al
intercambio continuo de información de señalización p2p.
El IMS también se considera una plataforma multiacceso que despliega servicios
tanto en redes fijas como inalámbricas. Esta ventaja permite a una amplia gama de equipos
de usuario (UE) conectarse a la red de la plataforma IMS. Sin embargo, aplicaciones
p2p, especialmente las estructuradas, asumen que todos los pares participantes
tienen las mismas capacidades y contribuyen por igual a la construcción y
mantenimiento de la superposición p2p. Esta suposición limita el rendimiento de las
aplicaciones p2p en el IMS porque los terminales IMS suelen tener capacidades muy
variadas. Los terminales móviles tendrán una potencia de procesamiento limitada,
por lo que pueden no ser adecuados como repetidores p2p. Y lo que es peor, las
restricciones de batería y la capacidad limitada de la red de acceso chocan
directamente con el modelo p2p, que prevé que todos los terminales sean
prácticamente iguales. El uso de estos terminales móviles en una superposición con
nodos fijos degradará el rendimiento del sistema p2p en su conjunto.
Otro problema que no es muy evidente en el p2p convencional, pero que resulta
crítico en un sistema p2p móvil, está relacionado con la dinámica de los terminales
móviles. La movilidad y el traspaso de usuarios suelen generar una conectividad
intermitente, que se percibe desde la superposición p2p como continuas uniones y
desuniones de nodos, lo que provoca una grave inestabilidad de la superposición.
80 Manual del subsistema multimedia fP (fM£)

Dado que el IMS es una plataforma convergente que integra redes fijas y móviles,
este comportamiento inevitable de los nodos móviles aumenta el tráfico de
señalización generado por la superposición, ya que ésta nunca parece estabilizarse.
Esta limitación, a su vez, limita las propiedades de escalabilidad y redundancia de la
superposición p2p, con lo que se corre el riesgo de desafiar su propósito original:
soportar sistemas de escala masiva en los que cualquier terminal pueda compartir
recursos y comunicarse con cualquier sin problemas. En la siguiente sección
presentamos dos casos prácticos que intentan superar algunos de los problemas
descritos hasta ahora.

Casos prácticos: Implantación de p2p como servicio IMS

Caso práctico I: superposiciones p2p sobre el IMS
Ejecutar aplicaciones p2p ordinarias directamente sobre una red convergente (fija y
móvil) no es lo ideal. La red superpuesta no sólo se mapea de forma deficiente e
ineficaz en la red física, sino que el ciclo de desarrollo de aplicaciones también es
largo y costoso. Las aplicaciones p2p existentes se basan en soluciones propietarias.
Por lo tanto, cada aplicación tendrá que depender de su propio conjunto de
funciones de soporte p2p, será monolítica y no interoperará fácilmente con otras
similares. Un ejemplo es Skype [29], una popular aplicación de telefonia p2p que no
interopera con otras aplicaciones VoIP. Lo mismo ocurre con Kazaa [26], una
popular aplicación para compartir archivos.
Un primer paso hacia la interoperabilidad p2p es tratar este tipo de aplicaciones
como cualquier otra aplicación IMS. Siguiendo el principio IMS de redes centradas en el
servicio, las aplicaciones se construyen componiendo componentes de servicio
reutilizables que, a su vez, se apoyan en el marco y ocultan la heterogeneidad de la
red.
Este escenario se ha descrito en Liotta y Lin [35] y se representa en la figura 3.2.
La capa de servicio IMS necesita extenderse para proporcionar los bloques de
construcción esenciales de las aplicaciones p2p, como se muestra en la figura. De
este modo, el desarrollo de una aplicación p2p compatible con IMS será sencillo
porque los mecanismos críticos para la gestión de la superposición, la publicación de
recursos, el descubrimiento de datos, etc., estarán disponibles en la capa de servicio
IMS. Disponer de un conjunto común de componentes p2p reutilizables también
facilitará la interoperabilidad de las aplicaciones.
El concepto p2p-IMS se ha demostrado a través de una serie de aplicaciones
móviles p2, como videoconferencias, blogs móviles, mensajería instantánea y
streaming [38-40]. Una lección interesante de este trabajo es que las aplicaciones
p2p-sobre-IMS tienen un nuevo potencial en comparación con el p2p convencional.
Al estar en control de los pares, el IMS puede actuar como entidad de confianza;
puede realizar nuevos esquemas de cobro (adaptados al p2p, como modelos
económicos basados en incentivos) y proteger el contenido contra la distribución
ilegal [41]. Estos importantes aspectos aún se están estudiando, y es posible que
veamos avances significativos en un futuro próximo.
 Aplicaciones P2P-IMS IMS Appl.

Funciones P2P en el subsistema

Propiedad
multimedia fP 81
Vídeo Móvil Instantáne ... ... ... ...
Conferencia Vender Blog a
Mensajería

Semántica P2P P2P

Semántic publicar/busca DRM P2P recurso Capa de
a
r P2P Compartir la carga servicio IMS
DB
estándar
P2P
Polític
Gestión de Gestión de a de
grupos P2P superposicion grupo P2P AAA
es P2P
SIP Diámetro Diámetro

SIP
HSS HSS SIP
SIP
Diámetro Diámetro Diámetro Diámetro

SIP SIP SIP

I-CSCF S-CSCF I-CSCF S-CSCF

SIP SIP
SIP Operador 2 SIP
Operador 1

P-CSCF P-CSCF
Proveedor de ISP

SIP SIP
WiFi/802.11x
UMTS GPRS
Red
Red

P2P P2P P2P

grupo A P2P
grupo B grupo C grupo D
P2P
Superpos
ición

FIGURA 3.2
IMS p2p. (Ampliado a partir de Liotta, A. y L. Lin. IEEE Communications Magazine 45(7):76-83.)

Estudio de caso II: p2p en el núcleo IMS

En este estudio de caso, describimos un enfoque para soportar aplicaciones p2p-IMS
a nivel de núcleo IMS, mediante modificaciones de SIP. Las extensiones apropiadas
de SIP conocidas como SIP peer-to-peer (p2pSIP) se encuentran actualmente en
estado de borrador en el IETF. p2pSIP se basa en un enfoque que sustituye los
servidores SIP tradicionales y las funciones de enrutamiento de mensajes por una
red superpuesta p2p estructurada o por mecanismos distribuidos que tienen
propiedades externas [36]. En otras palabras, el enfoque p2pSIP propone
proporcionar una plataforma sin servidores para servicios SIP en la que los mensajes
SIP se dirigen a una superposición p2p formada por varios clientes SIP en lugar de
servidores SIP centralizados. En comparación con
82 Manual del subsistema multimedia fP (fM£)

Núcleo IMS
P2PSIP
P2PSIP Superpos
Superpo ición
sición

P2PSIP
PCSCF P2PSIP
P2PSIP
Superpos
Superpo
ición
sición

FIGURA 3.3
Núcleo IMS habilitado para p2pSIP.

frente a los enfoques SIP convencionales, p2pSIP presenta varias ventajas, como su
bajo coste de instalación y mantenimiento, sus prestaciones para servicios
localizados y, lo que es más importante, su capacidad para heredar las ventajas de
escalabilidad y redundancia de las redes superpuestas p2p.
En este estudio de caso se adopta el enfoque p2pSIP propuesto para el despliegue
de servicios p2p en el IMS. Esto se consigue ampliando la implementación SIP en el
núcleo IMS para que admita p2pSIP con el fin de permitir que los servicios p2p se
integren fácilmente con otros servicios en el núcleo IMS (Figura 3.3). Esta solución
también permite que el núcleo IMS funcione tanto en modo SIP convencional como
p2pSIP, proporcionando compatibilidad con los servicios IMS existentes. Se basa en
una función de control de sesión de llamada proxy (PCSCF) habilitada para p2pSIP
[1] que admite tanto mensajes SIP como enrutamiento de paquetes IP. Mientras
soporta el enrutamiento de mensajes SIP, la PCSCF p2pSIP funciona como un
proxy SIP y puede soportar clientes IMS que no deseen formar parte de la
superposición p2p. Cuando funciona como un enrutador IP, el PCSCF p2pSIP limita
la cantidad de tráfico que entra en el núcleo IMS y enruta la mayoría de los paquetes
localmente. La funcionalidad de enrutamiento IP del p2pSIP también permite que
los clientes de la superposición estén interconectados en la capa de red y no sólo en
la capa de aplicación.
El PCSCF habilitado para p2pSIP también se utiliza como nodo de arranque de la
red superpuesta p2pSIP debido a su responsabilidad de conectar nodos a la red IMS
central. La extensión p2pSIP propuesta anteriormente se puede conseguir fácilmente en el
PCSCF porque 3GPP estandariza funciones en lugar de interfaces; esto permite
desplegar fácilmente varias funciones en un único nodo. El PCSCF habilitado para
p2pSIP también es responsable de iniciar la superposición y proporcionar la
información de superposición a los miembros que deseen unirse a la red
superpuesta.
Una vez que los pares se unen a la red superpuesta, se les permite alojar varios
servicios IMS p2p, lo que permite que se conecten más nodos. Esto minimiza el
número de mensajes SIP que fluyen desde la red superpuesta hacia las redes IMS.
Funciones P2P en el subsistema multimedia fP 83

También permite crear e integrar servicios fácilmente. Todas las formas de

búsqueda (nodo, usuario o servicio) o resolución de direcciones se realizan
utilizando el enfoque p2p pre-ferido en la superposición. No recomendamos ningún
enfoque p2p en particular porque varias implementaciones de superposición p2p
ofrecen diferentes ventajas, y la latencia de búsqueda tiende a variar en función de
las diferentes condiciones.
Para operaciones como la búsqueda de usuarios, nodos o servicios en la
superposición, las claves necesarias deben calcularse localmente (y transmitirse a
los supernodos de la superposición, si están disponibles) mediante mecanismos hash.
A continuación, las claves calculadas se envían a la superposición p2p para realizar
las búsquedas; los resultados se devuelven a los nodos requeridos. Una vez conocida
la información de localización de un usuario, puede establecerse una sesión SIP
utilizando SIP en modo p2p.
El despliegue de este enfoque p2pSIP en el IMS ofrece varias ventajas, como
seguridad, autenticación y confianza. Además, este enfoque particular sigue
proporcionando al operador de red cierto grado de control sobre la red, lo que
permite la convergencia de la facturación, el suministro de servicios y la gestión de
la red, al tiempo que se obtienen las ventajas de un sistema totalmente distribuido.
Una de las principales ventajas de este enfoque es que el operador de red o los
usuarios finales pueden desarrollar fácilmente nuevos servicios, lo que permite que
el IMS sea realmente un dominio de servicios.

Perspectivas y conclusión
Este capítulo sitúa las aplicaciones p2p ordinarias en una nueva perspectiva,
iluminando el potencial que surgirá cuando p2p se realice como cualquier otro
servicio IMS. Las superposiciones p2p no se adaptan bien a las redes físicas porque
los sistemas p2p optimizan los recursos informáticos, pero descuidan la red. Existe
un choque fundamental entre las actuales arquitecturas p2p y de red. p2p está
diseñada para eludir al operador de red, lo que limita su capacidad de controlar e
influir en la superposición de aplicaciones p2p. Por otra parte, fundamentales como
la tarificación, la seguridad, el control de calidad y la gestión de la ubicación son
difíciles de realizar sin la colaboración del operador.
El p2p-IMS lleva el p2p al ámbito del operador, creando las condiciones previas
para un servicio p2p más rico. Si se sitúa en perspectiva, el p2p-IMS tiene el
potencial de abordar problemas que hasta ahora han quedado sin resolver. Los
sistemas p2p actuales se enfrentan cada vez más al problema de que no ofrecen una
solución sólida de gestión de derechos digitales. La legislación sobre privacidad y
conservación de datos también frenará el desarrollo de los actuales sistemas p2p.
También está la importante cuestión de cómo satisfacer los requisitos de seguridad
nacional, dado que actualmente no es posible interceptar legalmente las
comunicaciones y los flujos de datos p2p.
Los dos estudios de casos descritos en este capítulo indican una nueva vía para
abordar los problemas antes mencionados del p2p, creando al mismo tiempo una
84 Manual del subsistema multimedia fP (fM£)

p2p es ahora un servicio de gran demanda que requiere un rediseño inmediato y

fundamental. El IMS puede ser la próxima plataforma de aprovisionamiento p2p,
siempre que el propio IMS evolucione hacia una arquitectura más descentralizada.
En definitiva, facilitar los servicios p2p en el IMS permitirá el despliegue de nuevos
e interesantes servicios, logrando aquello para lo que el IMS se diseñó inicialmente:
una plataforma de servicios.

Referencias
1. Camarillo, G., y M. A. Garcâia-Martâin. 2006. The 3G IP multimedia subsystem (IMS):
Merging the Internet and the cellular worlds (El subsistema multimedia IP 3G (IMS): fusión
de Internet y el mundo celular), 2.ª ed., Madrid, España. Chichester: John Wiley & Sons,
xxvi; 427.
2. Rosenberg, J. et al. SIP: Session initiation protocol (IETF RFC 3261).
3. Eng Keong, L. et al. 2005. A survey and comparison of peer-to-peer overlay network
schemes. IEEE Communications Surveys & Tutorials 7(2):72-93.
4. Sen, S., y W. Jia. 2004. Analyzing peer-to-peer traffic across large networks.
IEEE/ACM Transactions on Networking 12(2):219-232.
5. Xiang, Z. et al. 2004. Servicio de distribución multimedia entre pares. IEEE Transactions on
Multimedia 6(2):343-355.
6. Triantafillou, P., y T. Pitoura. 2004. Towards a unifying framework for com- plex query
processing over structured peer-to-peer data networks. En Data- bases, information
systems, and peer-to-peer computing, Lecture Notes in Computer Systems. Springer
Berlin/Heidelberg. 169-183.
7. Bin, L., L. Wang-Chien y L. Dik Lun. 2005. Supporting complex multi- dimensional queries
in p2p systems. En Proceedings of the 25th IEEE International Conference on Distributed
Computing Systems (ICDCS'05)-Volume 00, IEEE Com- puter Society.
8. Stoica, I. y otros. 2003. Chord: A scalable peer-to-peer lookup protocol for Internet
applications. IEEE/ACM Transactions on Networking 11(1):17-32.
9. Sylvia, R. y otros. 2001. A scalable content-addressable network. En Proceedings of the 2001
Conference on Applications, Technologies, Architectures, and Protocols for Computer
Communications. San Diego, California.
10. Maymounkov, P., y D. Mazières. 2002. Kademlia: Un sistema de información entre iguales
basado en la métrica XOR. En Peer-to-Peer Systems: First International Work- shop, IPTPS
2002 Cambridge, MA, 7-8 de marzo de 2002. Documentos revisados, 53-65.
11. Zhao, B. Y. y otros. 2004. Tapestry: A resilient global-scale overlay for service deployment.
IEEE Journal on Selected Areas in Communications 22(1):41-53.
12. Antony, I. T. R., y D. Peter. 2001. Pastry: Scalable, decentralized object loca- tion, and
routing for large-scale peer-to-peer systems. En Proceedings of the IFIP/ACM
International Conference on Distributed Systems Platforms. Heidelberg: Springer-Verlag.
13. Frank, D. y otros. 2001. Almacenamiento cooperativo de área amplia con CFS. En Proceedings
of the Eighteenth ACM Symposium on Operating Systems Principles. Alberta, Canadá: ACM.

* Todos los enlaces a sitios web se comprobaron por última vez el 14 de enero de 2008.
Funciones P2P en el subsistema multimedia fP 85

14. Cox, R., A. Muthitacharoen, y R. T. Morris. 2002. Serving DNS using a peer- to-peer lookup
service. En Peer-to-peer systems: Primer taller internacional, IPTPS. Cambridge, MA, 7-8 de
marzo de 2002. Ponencias revisadas, 155-165.
15. John, K. et al. 2000. OceanStore: An architecture for global-scale persistent stor- age. ACM
SIGPLAN Notes 35(11):190-201.
16. William, J. B. et al. 2000. Feasibility of a serverless distributed file system deployed on an
existing set of desktop PCs. SIGMETRICS perform. Evaluation Reviews 28(1):34-43.
17. Marc, W., D. R. Aviel y C. Lorrie Faith. 2000. Publius: A robust, tamper-evident,
censorship-resistant web publishing system. En Proceedings of the 9th Conference on
USENIX Security Symposium-Volume 9. Denver, CO. Denver, CO: Asociación USENIX.
18. Shelley, Q. Z. y otros. 2001. Bayeux: An architecture for scalable and fault-tolerant wide-
area data dissemination. En Proceedings of the 11th International Workshop on Network and
Operating Systems Support for Digital Audio and Video. ACM: Port Jefferson, NY.
19. Zhou, F. et al. 2003. Localización aproximada de objetos y filtrado de spam en sistemas
peer-to-peer. En Middleware 2003, Lecture Notes in Computer Science. Springer
Berlín/Heidelberg. 997-998.
20. Castro, M. et al. 2002. Scribe: Una infraestructura de multidifusión a gran escala y
descentralizada a nivel de aplicación. IEEE Journal on Selected Areas in Communications
20(8): 1489-1499.
21. Miguel, C. et al. 2003. SplitStream: multidifusión de gran ancho de banda en entornos
cooperativos. En Proceedings of the Nineteenth ACM Symposium on Operating Sys- tems
Principles. Bolton Landing, NY: ACM.
22. Antony, R., y D. Peter. 2001. Storage management and caching in PAST, a large-scale,
persistent peer-to-peer storage utility. SIGOPS Operating System Review 35(5):188-201.
23. Kutzner, K., y T. Fuhrmann. 2005. Measuring large overlay networks-The overnet example.
En Kommunikation in Verteilten Systemen (KiVS), 193-204.
24. Emule, [Link]
25. Bittorrent, [Link]
26. Kazaa, [Link]
27. Grokster, [Link]
28. iMesh, [Link]
29. Skype, [Link]
30. Joost, [Link]
31. Ian, C. et al. 2001. Freenet: Un sistema distribuido de almacenamiento y recuperación de
información anónima. En International Workshop on Designing Privacy Enhanc- ing
Technologies: Design Issues in Anonymity and Unobservability. Nueva York: Springer-
Verlag.
32. Ripeanu, M. 2001. Estudio de caso de arquitectura entre iguales: La red Gnutella. En
Proceedings of the First International Conference on Peer-to-Peer Computing (p2p'01), IEEE
Computer Society.
33. Limewire. [Link]
34. PeerCast. [Link]
35. Liotta, A., y L. Lin. 2007. La respuesta del operador a la demanda de servicios p2p.
IEEE Communications Magazine, número especial sobre el subsistema multimedia IP
45(7):76-83.
36. Peer-to-Peer SIP (p2pSIP). [Link]
86 Manual del subsistema multimedia fP (fM£)

37. Cox, L. P. y otros. 2002. Pastiche: Making backup cheap and easy. En Proceedings of Fifth
USENIX Symposium on Operating Systems Design and Implementation, Bos- ton, MA.
38. Liotta, A., y L. Lin. 2007. Managing p2p services via the IMS. En Proceedings of the 10th
IFIP/IEEE International Symposium on Integrated Network Management. Munich, Alemania,
21-25 de mayo.
39. Lin, L., y A. Liotta. 2007. Presencia en el subsistema multimedia IP. Journal of Mobile
Information Systems, número especial sobre la mejora de la calidad del servicio en los
sistemas de información móviles 3(3):187-202.
40. Liotta, A., M. Ballette, L. Lin, M. Gasparoni, P. Brick y N. Papadoglou. 2005. Service-
driven group management for mobile p2p services. Proceedings of the IFIP International
Conference on Intelligence in Communication Systems (Intell- Comm'05), Montreal, Canadá,
Kluwer Academic Publishers, 17-19 de octubre.
41. Liotta, A., R. Motta y L. Lin. 2006. A file protection method for peer-to-peer systems.
Journal of Research in Computing Science 23:151-160.
4
Sobre el apoyo a las funciones de los
medios de comunicación en la fM£

Jean-Charles Grégoire y Admela Jukan

CONTENIDO
Introducción ......................................................................................................................... 87
Antecedentes y evolución .................................................................................................. 88
Funciones de medios en IMS ............................................................................................ 90
IMS Básico .................................................................................................................. 90
MRF ............................................................................................................................ 90
Pasarela de medios (MGW)..................................................................................... 93
Streaming ..................................................................................................................... 94
H.248 .......................................................................................................................... 94
Cuestiones de QoS ................................................................................................................. 96
Condiciones previas de calidad de servicio y modelos de política de medios .. 97
Un ejemplo .......................................................................................................................... 98
Funciones de QoS y medios en el establecimiento de llamada ............................ 98
Conferencias .............................................................................................................. 101
Funciones en cajas ............................................................................................................ 101
La función de los medios de comunicación ........................................................ 102
Algunos ejemplos....................................................................................................... 102
Entender el mercado ............................................................................................... 105
Otros asuntos ...................................................................................................................... 106
Centrado en la red frente a centrado en el terminal ............................................ 106
Protocolos de control para las funciones de medios ........................................... 107
Aprovisionamiento y configuración ..................................................................... 108
Resumen y observaciones finales .................................................................................... 109
Referencias .......................................................................................................................... 109

Introducción
Aunque los multimedios son fundamentales para el IMS (el subsistema multimedios
IP) y sus operaciones, gran parte del trabajo original del IMS se ha centrado en los
siguientes aspectos
87
88 Manual del subsistema multimedia fP (fM£)

se ha centrado en cuestiones de señalización más que en el procesamiento de

medios. La función de recursos de medios (MRF), parte de la arquitectura central
IMS, es una colección de funciones de naturaleza variada, todas ellas necesarias
para soportar diversos servicios de telefonía en los planos de señalización y medios.
Con el tiempo, sin embargo, esta función ha generado más interés a medida que los
fabricantes han ido posicionando productos para implementarla y han surgido
servicios que requieren el soporte de funciones de medios más sofisticadas que las
especificadas hasta ahora.
Sin embargo, los estudios sobre la naturaleza de las diversas funciones de medios
necesarias para las operaciones de los servicios IMS o sobre la forma en que pueden
integrarse en las operaciones IMS han sido escasos y poco frecuentes. En este
capítulo, revisamos y analizamos diferentes perspectivas sobre las funciones de
medios, incluida una revisión de las normas pertinentes del Proyecto de Asociación
de Tercera Generación (3GPP). Además, introducimos un punto de vista original
sobre la organización de la función de medios IMS para intentar facilitar su
integración en los servicios.
Este capítulo está estructurado de la siguiente manera. La siguiente sección
presenta los antecedentes del procesamiento de medios en el universo de la telefonía
heredada. La tercera sección presenta la perspectiva IMS de la función de medios.
La cuarta sección enriquece los conceptos anteriores con consideraciones de calidad
de servicio. La quinta sección ilustra los conceptos introducidos hasta ahora
mediante un ejemplo. La sexta sección analiza la descomposición de la función de
medios y presenta un ejemplo de visión de mercado. La séptima sección presenta
otros temas relacionados, como el aprovisionamiento y los protocolos de control. La
última sección ofrece un resumen y algunas observaciones finales.

Antecedentes y evolución
Las funciones de medios en el universo IP se remontan a la telefonía. Los primeros
trabajos sobre el protocolo de inicio de sesión (SIP) realizados en el Internet Engi-
neering Task Force (IETF) tenían como objetivo desarrollar un protocolo de
señalización más acorde con el modelo de extremo a extremo de Internet que con el
modelo basado en infraestructuras de las familias de normas H.320 de la Unión
Internacional de Telecomunicaciones (UIT). Con el tiempo, naturalmente, la
necesidad de interoperar con la telefonía tradicional, así como la necesidad de dar
soporte a los servicios de telefonía habituales, llevó a la creación de nuevos
protocolos asociados a nodos de red dedicados al procesamiento de medios
específicos. En esta sección cubrimos las diferentes formas de procesamiento
introducidas en telefonía; en la siguiente, presentamos cómo se tratan en IMS.
La telefonía actual, tal y como la entendemos, es la evolución de la oferta de un
servicio sencillo ("plain old telephony system" [POTS]) a un conjunto de servicios
de valor añadido respaldados por una combinación de sofisticada red de señalización
(SS7) y otras funciones. Comenzamos con un repaso de los lat- ter predominantes,
centrándonos en la dimensión mediática; empezamos con un repaso de las nociones
clave:
Sobre el apoyo a las funciones de los medios de comunicación en la fM£ 89

Servicio: Nuestra noción de servicio está tomada directamente de la telefonía

y denota una oferta comercial a un cliente. Dependiendo del contexto
(telefonía, IMS, etc.), los servicios pueden construirse a partir de
características (una forma de bloques de construcción) o basarse en
facilitadores (funciones de apoyo). De hecho, en algunos círculos (SIP) se
ha argumentado que no hay consenso sobre lo que es un servicio; aunque
esto puede ser cierto desde la perspectiva del protocolo, la perspectiva del
cliente es más clara en este punto.
Señalización: Recordemos que la señalización puede definirse como un
intercambio de protocolos para el establecimiento y control de una
conexión y la gestión de los recursos necesarios. La dualidad señalización
frente a medios (datos) impregna este trabajo porque algunos elementos
IMS están en los flujos de señalización, mientras que otros están en el flujo
de medios. Veremos que, en algunos casos, la naturaleza de la interacción
entre los elementos de uno y otro lado será borrosa.
Pasarela: Esta función tiene la responsabilidad de proporcionar soporte para la
transcodificación, es decir, convertir la representación de medios (es decir,
códecs) entre redes heterogéneas (por ejemplo, entre redes inalámbricas y
alámbricas). Una pasarela suele tener dimensiones de medios y de
señalización.
Conferencias: Esta función se construye tradicionalmente en torno a un
puente, un dispositivo que puede aceptar llamadas de o posiblemente
iniciar una llamada a un número de participantes. Las conferencias se crean
y controlan; los usuarios se unen a ellas y las abandonan. También hay
funciones de control para decidir quién será el orador principal (control de
sala).
Respuesta vocal interactiva: Los servicios IVR permiten al usuario interactuar
con un servicio sin intervención humana y, para bien o para mal, han tenido
bastante éxito. Se diferencian de los servicios anteriores en que requieren
una interacción entre el usuario y el servidor, con una interpretación de la
respuesta. La IVR también puede considerarse un habilitador, es decir, una
funcionalidad reutilizable en diferentes , como el buzón de voz o las
llamadas con tarjeta, aunque los centros de llamadas sean probablemente la
aplicación predominante. Hay que tener en cuenta que estos servicios
presentan el reto de mezclar medios y control y, posiblemente,
señalización. La información descodificada del flujo de medios se utiliza
para controlar el funcionamiento, pero también como medio, por ejemplo,
para grabar un mensaje. La dimensión de señalización se produce cuando
utilizamos el flujo de medios para establecer una llamada. Por último,
añadamos que a este servicio pueden asociarse distintas tecnologías, como
la decodificación DTMF (Dual-tone multi- frequency decoding), la síntesis
de texto a voz, el reconocimiento de voz y la captura de audio.
Streaming: Esta función puede considerarse una dimensión de IVR o un
servicio independiente. El streaming se utiliza para reproducir contenidos
multimedia, como un mensaje grabado por voz o mensajes generados por
texto a voz (TTS).
90 Manual del subsistema multimedia fP (fM£)

Funciones de medios en IMS

IMS es un sustrato para operaciones de medios en una red IP. Dado que se definió
como parte del 3GPP para redes de telefonía celular, traslada de la telefonía la
noción tradicional de servicios y el uso de medios en ese contexto. En esta sección
presentamos brevemente elementos de la arquitectura IMS relevantes para nuestra
exposición, asumiendo que el lector ya conoce el uso del protocolo de inicio de
sesión [1] como base para la señalización en IMS, así como los nodos clave en la
función de control de sesión de llamada.

Núcleo IMS
IMS requiere una serie de componentes, definidos en 3GPP TS23.228 [7], para
permitir a un usuario iniciar, modificar y finalizar sesiones multimedia. La figura
4.1 presenta una visión general de la arquitectura y sus elementos clave. También
destaca los puntos de referencia entre los cuadros de funciones, que son
esencialmente protocolos de soporte; por ejemplo, el enlace de control de servicio
IMS (ISC) entre la función de control de sesión de llamada (CSCF) y el servidor de
aplicaciones (AS) está basado en SIP.
El núcleo IMS tiene la funcionalidad necesaria para soportar llamadas multimedia
de usuario a usuario y todas las formas de servicios de telefonía. La CSCF se
encarga de la señalización, y el servidor de abonado doméstico (HSS) será el
repositorio de la información de autenticación y perfil de usuario; aquí nos
centraremos en los elementos de procesamiento de medios, concretamente el MRF y
la pasarela de medios (MGW).
Antes de investigar estas funciones con más detalle, probablemente merezca la
pena recordar que, en la arquitectura IMS, algunos nodos estarán directamente en el
flujo de señalización de la llamada o estarán en un flujo derivado generado a partir
de un nodo de la , como un AS. En el caso de los nodos relacionados con los
medios, veremos casos de ambos tipos.

MRF
En la arquitectura IMS actual*, la MRF se divide en dos partes: un pro- cesor
(MRFP) y un controlador (MRFC). Juntos, suministran los recursos que dan soporte
a los servicios relacionados con el portador, como las sesiones multipartitas, los
anuncios a un usuario o la transcodificación del portador.

MRFC: Como vemos en la Figura 4.2, el MRFC se encuentra en la ruta de

señalización; es decir, los mensajes de control de sesión se transmiten entre
el AS y el MRFC a través de la CSCF (servidora). Basándose en la
información contenida en los , dirigirá al MRFP para que actúe en
consecuencia. Para algunos

* Enel momento de redactar este documento, la versión 7 está congelada y es nuestra referencia; se está trabajando
en la versión 8.
 comunicación en la fM£
Sobre el apoyo a las funciones de los medios de
Redes IP multimedia

Redes de conmutación de Redes de señalización móvil heredadas

circuitos

Mb Mb CS Mb CS Mk Mm Mm

Interrogar a la
Función de control de la
pasarela de CSCF
(I-CSCF)
interconexión (BGCF) Servidores de
aplicaciones (AS)
Mk

Función de control de la
pasarela de
Mw
interconexión (BGCF)
Mi
Mj

Al Servidores de
Pasarela Función de abonado
servicio
multimedia IP controlador de doméstico
de CSCF
(IM-MGW) pasarela de medios (HSS)
(S-CSCF)
Mn Mg
(MGCF)

Mw Función de localización del

abonado (SLF)
Sr.

Proxy
Procesador de Controlador de la Gm
función de recursos CSCF Usuario
funciones de
(P-CSCF) Dispositiv
recursos multimedia
multimedia (MRFP) Mp o final (UE)
(MRFC)
Subsistema multimedia de Internet (IMS)
Mb Mb Mb

FIGURA 4.1

91
Arquitectura de referencia IMS. (Del Proyecto de Asociación de Tercera Generación, Subsistema multimedia IP (IMS); fase 2, 3GPP TS 23.228 V7.8.0, 2007-06.)
92 Manual del subsistema multimedia fP (fM£)

AS

ISC

Mr
S-CSCF MRFC

Mp

MRFP

FIGURA 4.2
Detalle del modelo de referencia para la MRF.

sin embargo, no es necesario un AS y la llamada se enrutará al MRFP

directamente desde la CSCF servidora (S-CSCF).
MRFP: Entre las tareas del MRFP figuran las siguientes:
• controlar el portador en el punto de referencia Mb;
• proporcionar recursos que serán controlados por el MRFC;
• mezclar flujos de medios entrantes (por ejemplo, para varias partes);
• flujos de medios de origen (para anuncios multimedia);
• procesamiento de flujos de medios (por ejemplo, transcodificación de
audio, análisis de medios);
• control del suelo (es decir, gestionar los derechos de acceso a los
recursos compartidos en un entorno de conferencia); y
• generación de registros de datos de llamada (CDR) para la tarificación
El punto de referencia Mp: Mp especifica la interfaz entre el controlador y el
procesador en la MRF. Se basa en el estándar H.248 [17], creado
originalmente como control de pasarela de medios (MEGACO).
[2]-o RFC 3015- dentro del IETF para dar soporte a la telefonía IP. Gracias
a su mecanismo de paquetes (véase la sección "H.248"), este protocolo es
extensible y puede perfilarse para usos específicos.
El punto de referencia Mr: Mr permite los intercambios entre la CSCF y el
controlador. Se basa en SIP, con las extensiones 3GPP.
La división MRF: Dividir la función MRF entre el controlador y el procesador
puede tener ventajas para el rendimiento y la escalabilidad, pero no es una
necesidad. Los fabricantes eligen si quieren o no separar las funciones, y
esta afirmación se aplica en realidad a la arquitectura IMS en su conjunto.
Más adelante profundizaremos en esta importante cuestión.
Sobre el apoyo a las funciones de los medios de 93
comunicación en la fM£

Pasarela de medios (MGW)

La función de pasarela de medios es necesaria para permitir la interoperabilidad con
redes fijas y heredadas. Suele estar dividida entre una función del lado IMS (IMS-
MGW) y otra equivalente, normalmente de conmutación de circuitos (CS-MGW).
Así, terminará un canal portador de una red de circuitos conmutados y flujos de
medios de una red de paquetes (IP). Como parte de estas operaciones, será necesario
soportar la conversión de medios (transcodificación), el control del portador y
posiblemente también otras formas de procesamiento, como la cancelación de eco.
Aunque el MGW puede estar muy relacionado con el MRF, sirve a un propósito
muy específico (interoperabilidad) y forma parte de las funciones básicas del IMS.
No necesita ser controlado desde un AS sino que, más bien, estará en el flujo de
señalización desde el CSCF.
Como se ve en la figura 4.1, la MGW también tiene una función de control, la
MGCF, que está en comunicación directa con la S-CSCF, pero también con otro
nodo, la función de control de pasarela de ruptura (BGCF). Estos nodos unen la
señalización IMS-PSTN.

MGCF: El MGCF se considera un punto final SIP, lo que significa que

termina el lado SIP de una llamada. Traduce los mensajes de señalización
del lado RTC a señalización SIP en el lado IMS y viceversa.
BGCF: La S-CSCF solicita los servicios de la BGCF cuando una llamada SIP
no puede enrutarse en el dominio de paquetes y necesita convertirse en una
llamada de conmutación de circuitos. Una BGCF reenviará la llamada a
otra BGCF en el dominio en el que pueda producirse la ruptura -de IP a CS-,
posiblemente su propio dominio. El BGCF de ruptura elegirá un MGCF en
su dominio para terminar la llamada.
El punto de referencia Mn: Dentro del IMS, el punto de referencia Mn describe las
interfaces entre la MGCF y el MGW. Se trata de interfaces de control
totalmente conformes con las funciones estándar H.248 para el
interfuncionamiento IMS y PSTN/PLMN (red pública de telefonía móvil
terrestre). También deben admitir un manejo flexible las conexiones para
permitir diferentes modelos de llamada y diferentes fines de procesamiento
de medios, que no se limiten al uso relacionado con H.323. El punto de
referencia Mn debe incluir una arquitectura abierta en la que las
definiciones de extensión/paquete puedan realizarse por interfaz. En los
puntos Mn, debe permitirse la compartición dinámica de los recursos del
nodo físico MGW. En otras palabras, un nodo MGW físico puede dividirse
en MGW/dominios virtuales lógicamente separados, cada uno de ellos
compuesto por un conjunto de terminaciones asignadas estáticamente. Por
último, el punto de referencia Mn es necesario para permitir la
compartición dinámica de recursos de trans- misión entre los distintos
dominios, ya que el controla los portadores y gestiona los recursos.
El punto de referencia Mg: El punto de referencia Mg permite a la MGCF reenviar la
señalización de sesión entrante (procedente de la PSTN) a la CSCF para
94 Manual del subsistema multimedia fP (fM£)

para el interfuncionamiento (de señalización) con redes de telefonía fija. El

punto de referencia Mg se basa en el protocolo SIP [1], junto con otras RFC
pertinentes y mejoras adicionales introducidas para satisfacer las
necesidades del 3GPP.
El punto de referencia Mi: Este punto de referencia permite a la Serving-CSCF
reenviar la señalización de sesión a la BGCF con el fin de interoperar con
las redes PSTN. El punto de referencia Mi se basa en SIP, con la misma
salvedad que para Mg.
El punto de referencia Mj: Este punto de referencia permite a la BGCF reenviar la
señalización de sesión a la MGCF a efectos de interfuncionamiento con las
redes RTPC. El punto de referencia Mj se basa en SIP, con la misma
salvedad que para Mg.

Tenga en cuenta que Mi y Mj gestionan las salientes, mientras que Mg se ocupa

de las entrantes.

Streaming
Un servicio de streaming (SS) tiene la capacidad de reproducir a través de una red
flujos continuos de flujos multimedia sincronizados, normalmente audio y vídeo,
pero también texto o imágenes fijas. Estos flujos se envían a uno o varios clientes,
aunque en el caso de IMS no se contempla la multidifusión. Cuando se trata de un
único cliente, es posible añadir funciones de control que permitan al usuario pausar,
reanudar, avanzar rápido o rebobinar.
Los servicios de streaming son un segmento creciente de Internet, aunque todavía
en una forma bastante primitiva (por ejemplo, con vídeo en línea o podcasts). Tienen
muchas aplicaciones, ya sea bajo demanda, como noticias o música, o en directo,
como retransmisiones deportivas o televisión en general. En la arquitectura IMS,
podemos ver en la Figura 4.3 que estos servicios no están integrados en el mismo
marco de sig- nalización. En su lugar, seguimos el modelo del IETF de enviar
solicitudes de a través del protocolo web (HTTP) y utilizamos un protocolo de
control. Debido a estas opciones, en el servicio de streaming de conmutación de
paquetes (PSS) de IMS, la complejidad del terminal puede ser más limitada que en
los servicios conversacionales, ya que no se requieren dispositivos de entrada ni
codificación.
Ya que mencionamos las emisiones, vale la pena señalar que las arquitecturas de
las SS incluirán algún tipo de tecnología para desplegar y gestionar los derechos
digitales, aunque, en el momento de escribir esto, este campo todavía está en estado
de cambio.

H.248
Como ya se ha mencionado, el protocolo MEGACO (RFC 3015) también ha sido
publicado por el UIT-T como H.248, y estos dos nombres son sinónimos a efectos
prácticos. Basado en un modelo maestro-esclavo, ha sido diseñado para permitir el
control de la pasarela de telefonía y los terminales (teléfonos IP). El maestro es un
controlador,
Sobre el apoyo a las funciones de los medios de 95
comunicación en la fM£

Caché de Servidor
conteni es de
dos contenid
Cliente de
os
streamin
GERAN
g

Red central 3GPP SGSN

Red IP
GGSN

Cliente de
UTRAN
streamin Perfiles
g de
usuario y
de Portales
terminal

FIGURA 4.3
Arquitectura de referencia de streaming en IMS. (Del 3rd Generation Partnership Project, Trans- parent end-
to-end packet-switched streaming service; 3GPP TS 22.233 V7.0.0, 2006-06, stage 1, release 7.) GERAN: red de
acceso radioeléctrico GSM EDGE; UTRAN: red de acceso radioeléctrico terrestre UMTS; SGSN, GGSN:
nodo de soporte GPRS de servicio/pasarela.

que actuará como punto central de interacción para la señalización de llamadas y

mantendrá la información de estado relevante de uno o varios esclavos/pasarelas
multimedia. Para cualquier operación, la pasarela depende de comandos -llamados
acciones- del controlador. Envía eventos al controlador como notificaciones.
Hay una diferencia fundamental entre SIP y H.323 y los protocolos de control de
pasarela de medios. SIP y H.323 son protocolos de señalización que establecen y
gestionan llamadas, mientras que un protocolo de control de pasarela de medios se
centra en el establecimiento de los propios flujos de medios.

(1) Un modelo de conexión: La arquitectura MEGACO se basa en tres

conceptos: terminación (punto), contexto y flujo. Juntos orquestan el
establecimiento y la manipulación de los flujos de medios.
(a) Terminación: Los flujos de medios se establecen entre puntos finales.
La terminación identificará dicho punto final, implementará señales y
generará eventos relacionados. Una terminación puede aparecer en un
contexto como máximo. Puede representar una entidad física, como
una tecnología (car- rier) (por ejemplo, Frame Relay, ATM o TDM) o
flujos efímeros basados en UDP o TCP.
(b) Contexto: Una comunicación establecida entre terminaciones es un
contexto. Cada contexto admite múltiples flujos y define una topología
sobre la que se producirán las comunicaciones, así como la
mezcla/transcodificación, si es necesario.
(c) Flujo: Un contexto puede tener múltiples flujos, cada uno normalmente
para un medio (por ejemplo, audio o vídeo) organizado según el con-
96 Manual del subsistema multimedia fP (fM£)

CUADRO 4.1
Comandos H.248
Valor de auditoría Determinar las características de un endpoint
Capacidades de auditoría Determinar las capacidades de un endpoint
Añadir Añadir una conexión
Modificar Modificar una característica de conexión
Restar Restar una conexión
Mover Mover un extremo de una conexión a otra
(llamada en espera)

topología del texto. El controlador especifica qué flujos admite una

determinada terminación.
(2) Comandos, paquetes y perfiles: La tabla 4.1 enumera los comandos que un
controlador puede enviar a una pasarela a través de MEGACO. En la otra ,
una pasarela enviará notificaciones de eventos. Dado que no era posible -o
prudente- diseñar un protocolo para cualquier tipo de pasarela de medios,
se tomó la decisión de tener un mecanismo general y conjuntos
especializados de parámetros, llamados paquetes, por aplicación. Un
paquete es, por tanto, un mecanismo de extensión que define propiedades,
eventos, señales y estadísticas necesarias para una operación específica
(por ejemplo, señalización DTMF). Cada paquete está estandarizado, con
un nombre y un ID distintos (Generic, g; Base Root, root, etc.). IANA
gestiona un repositorio global, y un perfil enumerará una serie de paquetes
que un estándar requiere para su uso de MEGACO.
(3) Algunas críticas: Aunque MEGACO ha cumplido bien su propósito, no
está exento de limitaciones. Por ejemplo, el modelo maestro-esclavo obliga
a dar muchos pasos de comunicación entre la pasarela y el controlador. El
modelo basado en señales/eventos también tiene una expresividad limitada.
En esencia, MEGACO se diseñó para puntos finales de sesión de medios
"tontos", que no pueden integrarse en la ruta de señalización. Como
veremos más adelante, se han hecho varios intentos de mejorar este modelo
para el control avanzado de medios.

Cuestiones de QoS
La norma IMS define el tipo de mensajes de señalización SIP intercambiados entre
los terminales de usuario y la infraestructura central IMS, su enrutamiento y
transferencia entre operadores, y también la función de medios define las
disposiciones y garantías necesarias en materia de calidad de servicio (QoS) para
Sobre el apoyo a las funciones de los medios de 92
comunicación en la fM£

intercambiarse dentro de ella. En otras palabras, los terminales que negocian los
parámetros de medios también determinan los parámetros de reserva de recursos de
red antes del evento de anillo de sesión y del flujo de medios. Dentro de la
configuración de la llamada SIP, debe tenerse en cuenta el proceso de
establecimiento de condiciones previas de calidad de servicio, que requieren que el
participante reserve recursos de red antes de iniciar el flujo de medios.

Condiciones previas de calidad de servicio y modelos de política de medios

Una precondición es un conjunto de parámetros sobre la sesión que son necesarios
para las reservas de red cuando se establece una sesión entre dos partes. Se
denominan "precondiciones" porque se intercambian antes del establecimiento real
de la sesión (a través de SIP). Sólo si se cumplen las "precondiciones" se procederá
al establecimiento de la sesión, y todas las precondiciones para un flujo de medios
deben cumplirse para completar el establecimiento de la sesión. Se expresan
convenientemente dentro de los cuerpos del protocolo de descripción de sesión
(SDP), con las propias definiciones de medios, y su estado se modifica durante las
etapas de negociación de la fase de establecimiento de la llamada.*
Muchas de las condiciones previas negociadas son específicas del operador y
propietarias. A día de hoy, no existen marcos normativos plenamente desarrollados
que especifiquen las condiciones previas específicas de cualquier medio (es decir, su
tratamiento y negociación). Aunque la mayoría de las normas abordan las
condiciones previas en términos generales (por ejemplo, medio=audio, estado de la
QoS actual local), se sabe poco sobre las condiciones en las que se pueden rechazar
los medios y sobre si se pueden renegociar las condiciones previas y cómo. Por
ejemplo, si las condiciones previas de una videoconferencia inalámbrica exigen que
se garanticen 30 kb/s en el portador de radio, el medio puede ser rechazado si se
dispone de menos ancho de banda, a pesar de que el audio de ese medio pueda ser
aceptable, aunque el vídeo no lo sería, debido la insuficiente capacidad del enlace
inalámbrico. Tampoco es posible expresar compensaciones, como un espacio de
implementación, que podrían explotar los repetidores para intentar satisfacer lo
mejor posible las limitaciones de los usuarios.
Las condiciones previas son sólo una parte de la historia. Aunque permiten
satisfacer los requisitos de los flujos de medios, su realización puede verse limitada
por algunas políticas, que recogen lo que un usuario puede o no puede hacer en
función de un perfil (por ejemplo, grado de servicio accesible), así como por el hecho
de que los recursos son limitados; de ahí que el lado de la red pueda no ser capaz de
satisfacer las demandas del o la solicitud supere su presupuesto. Así pues, la
aplicación de los mecanismos de condiciones previas puede requerir una interfaz
con un gestor de políticas, en la línea de la arquitectura del servicio común de
política abierta (COPS) del IETF [4], que se ha adoptado en el marco del 3GPP en
forma de una función de reglas de política y tarificación (PCRF), que gestiona las
reglas, y una función de aplicación de políticas y tarificación (PCEF), que las hace
cumplir,

* Tenga en cuenta que esto requiere acceso al cuerpo del SDP y tiene implicaciones en la seguridad.
T Nótese, sin embargo, que estas funciones se comunican a través de DIAMETRO, en lugar de utilizar el
protocolo COPS propiamente dicho.
98 Manual del subsistema multimedia fP (fM£)

estamos hablando de un mecanismo flexible y de propósito general y, aunque se han

propuesto algunas tablas de políticas, incluyendo seguridad y QoS, no existe un
consenso general sobre el uso adecuado de dicho mecanismo. Además, no se limita
a COPS como vehículo de implementación.
Un artículo de Camarillo et al. [16] aborda un marco basado en políticas en el que
las características de una sesión son inspeccionadas por la función basada en
políticas definida por el 3GPP R7. Por ejemplo, si la sesión contiene solicitudes de
vídeo en los intercambios de oferta/respuesta y sólo se admite voz, puede ser
rechazada. Normalmente, la PCRF del IMS informaría a la función de aplicación de
que la sesión en curso no es aceptable. El documento señala una cuestión importante
de la terminación de la sesión en curso debido a las características de la sesión y
revela que, en los sistemas actuales, la red no puede informar a los usuarios sobre las
razones específicas de las terminaciones de sesión (por ejemplo, la red no puede
indicar a los usuarios que "prueben otro códec" o "compren los créditos que faltan").
Reescribir el mensaje SDP, que actualmente se realiza tanto para usuarios fijos
como celulares de IMS, no ayudaría porque cada dominio de operador de red tendría
que ponerse de acuerdo sobre el conjunto de extensiones SDP, lo que claramente no
escalaría. En ese caso, la idea de utilizar políticas puede llevar la oferta de servicios IMS a
una fase más inno- vativa. Con las políticas, la red puede informar al terminal sobre
toda la lista de códecs admitidos.
Naturalmente, contactar con un servidor de políticas induce un retardo adicional
en el ya de por sí crítico rendimiento del establecimiento de sesiones SIP. Según
Camarillo et al. [16], deben añadirse unos 10 mensajes nuevos al flujo de mensajes
para este propósito. Mantener bajo el retardo de la señalización SIP es, por tanto, un
reto en IMS, debido no sólo a la naturaleza basada en texto de SIP, sino también a la
complejidad de la arquitectura del sistema requerida en las implementaciones IMS.
El exceso de mensajes agrava el problema.

Un ejemplo
Para ilustrar los conceptos anteriores, presentamos aquí los puntos más destacados
de la negociación de la QoS en el establecimiento de una llamada y analizamos más
a fondo su relación con una aplicación de con- ferencia.

Funciones de QoS y medios en el establecimiento de llamada

En la figura 4.4 se ilustra un caso en el que tres abonados IMS desean participar en
una conferencia a tres bandas. El ejemplo de arquitectura de red se basa vagamente
en 3GPP2 porque muestra la inclusión del nodo de conmutación de paquetes de
datos (PDSN); sustituyendo el PDSN por el nodo de soporte GPRS de pasarela
(GGSN), se puede considerar una arquitectura similar en el contexto 3GPP.
Suponemos que a todos los usuarios (nodos finales de usuario, UE) ya se les ha
comunicado el indicador uniforme de recursos (URI) de con- ferencia a través de
 comunicación en la fM£
Sobre el apoyo a las funciones de los medios de
Redes IP multimedia

Redes de conmutación de circuitos Redes de señalización móvil heredadas

Mb Mb CS Mb CS Mk Mm Mm
C, D,
Interrogar a la Gc, Gr
Puerta de enlace CSCF
Función de control
(I-CSCF)
(BGCF) Aplicación
Mk Servidores
(AS)
Puerta de enlace Mw Cx
Función de control Mw
(BGCF) Sh

Mi
Mj ISC

Al servicio de Cx Servidores de
Pasarela Pasarela multimedia CSCF abonado
multimedia IP Función de (S-CSCF) doméstico (HSS)
Mn controlador (BGCF) Mg
Dx

Mw Función de localización
del abonado (SLF)
Sr.

CSCF proxy
Medios de Medios de (P-CSCF) Gm Usuario Ut
comunicación comunicación
Dispositivo
Procesador de Mp Controlador de
final (UE)
funciones (MRFP) funciones (MRFC)
Mb Mb Mb Subsistema multimedia de Internet (IMS)

FIGURA 4.4
Ejemplo de configuración de multiconferencia con reserva de QoS y funciones multimedia.

99
100 Manual del subsistema multimedia fP (fM£)

correo electrónico, http, etc. UE 1 utiliza el mensaje SIP INVITE dirigido al URI de
conferencia. La S-CSCF del usuario reenvía el mensaje INVITE al MRFC para su
procesamiento. En el paso 2, el MRFC asigna el URI de conferencia comprobando
las configuraciones y políticas locales, así como otros elementos IMS (es decir, AS,
etc.) y, si tiene éxito, utiliza la señalización H.248/MEGACO para crear una nueva
conferencia en el MRFP (que actúa como mezclador de medios). De este , crea un
nuevo contexto MEGACO para la conferencia y asigna recursos para la solicitud. A
continuación, en el paso 3, se envía el mensaje de progreso de la sesión al UE 1,
pasando por la función de control del estado de la llamada proxy (P-CSCF). La P-
CSCF activa la autorización del servicio en este punto hacia la PCRF, que puede
consultar al AS, la S-CSCF, etc. el perfil de QoS del usuario para validar que el
usuario está suscrito al servicio de conferencia con el pro- fesio de QoS solicitado.
El resultado de esta señalización se comunica a la PDSN, que actúa como punto de
aplicación de la política en el plano de datos/medios. Una vez autorizado, el mensaje
de progreso de sesión se pasa al UE 1 en el paso 6.
El UE 1 inspecciona el mensaje de sesión en curso, comprueba los códecs (es
decir, la respuesta de oferta INVITE) y confirma el resultado en el mensaje PRACK
en el paso 7. El UE puede seleccionar un códec de entre los múltiples códecs
aceptados en el mensaje de sesión en curso; en este caso, lo incluye en el mensaje
PRACK. En el paso 8, se inicia el proceso de reserva de flujo QoS específico de
radio y los flujos están listos para su uso desde la perspectiva del radioenlace al final
de esta etapa; sin embargo, el tráfico IP no puede fluir todavía porque la PDSN lo
bloquea hasta que se complete el intercambio de señalización. En la etapa 9, la red
MEGACO/
El comando H.248 MODIFY puede utilizarse para cambiar la configuración del
códec de la conexión. En el paso 10, una vez completada la reserva de radio, el
equipo de usuario envía un mensaje UPDATE informando al MRFC de que la
reserva en el lado de radio se ha realizado correctamente. Cualquier cambio aquí
puede dar lugar a otra operación MODIFY al MRFP (no mostrada en la figura). Esto
desencadena que la MRFC ordene al MRFP que conecte los recursos de conexión
pasante para el UE 1 en el paso 11 (lo que puede hacerse mediante el comando ADD
en MEGACO). En el paso 12, la PCSCF ordena a la PDSN que permita el flujo IP
(es decir, que abra la puerta). Por último, en los pasos 13 y 14, el UE 1 envía el mensaje
ACK final e inicia la sesión multimedia.
Para UE 2 y UE 3, tenemos procesos similares que se ejecutan simultáneamente
con UE 1. Hay que tener en cuenta que la conferencia sólo se crea con la llegada del
primer usuario, y el resto de usuarios simplemente se añaden a ella. Esto se refleja
en el comando H.248/MEGACO ADD enviado al MRFP para añadir UE 2 y UE 3
al mismo contexto; de este modo, todos los usuarios pueden "oírse" entre sí.
También hay que señalar que pueden aplicarse mecanismos de QoS IP estándar al
tráfico de medios dirigido al MRFP en el plano de transporte IP. Dichos
mecanismos pueden incluir servicios diferenciados MPLS (DiffServ), IP DiffServ,
etc. Esto puede permitir una priorización eficiente de los paquetes de voz y vídeo
dirigidos a los respectivos servidores MRFP.
Sobre el apoyo a las funciones de los medios de 101
comunicación en la fM£

Conferencias
Los servicios básicos del IMS, definidos en 3GPP TS 24.229, permiten al usuario iniciar,
modificar y finalizar sesiones multimedia. Sin embargo, la infraestructura IMS puede
soportar servicios más sofisticados para múltiples partes (por ejemplo, conferencias).
El servicio de conferencias proporciona los medios para que un usuario cree,
gestione, finalice, se una y abandone conferencias. También proporciona a la red la
capacidad de dar información sobre estas conferencias a las partes implicadas. La
conferencia se aplica a cualquier tipo de flujo de medios por el que los usuarios
quieran comunicarse. Esto incluye flujos de medios de audio y vídeo, pero también
podría incluir conferencias basadas en mensajes instantáneos o juegos.
En cuanto a los medios, el servicio de conferencia debe ser capaz de puentear los
distintos flujos de medios y proporcionar otras funciones, como la descodificación
de tonos para la autenticación y la identificación de la conferencia. En la práctica,
esto significa que, si el puente está controlado por MEGACO, deberá admitir un
determinado número de paquetes. Sin embargo, en la mayoría de los , tendremos un
gran número de interacciones con el controlador para soportar las llamadas.
Tenga en cuenta, sin embargo, que todas estas funciones se ejecutarán en el
dominio IP, incluso si las llamadas se inician o terminan en POTS. El puente de
conferencia sólo ve llamadas IP, e IMS se encargará de enrutarlas al dominio de
telefonía si es necesario.
Aún así, el puente debe soportar otros protocolos que pueden estar relacionados
directamente con los flujos finales de medios; es decir, no siguen la ruta de
señalización. El control de planta, por ejemplo, utiliza un protocolo específico
llamado BFCP, que ayudará a controlar qué flujo se asignará a qué aplicaciones.
Más detalles sobre señalización y conferencias en las referencias 2, 13 y 15.

Funciones en casillas
Aunque IMS es una arquitectura formal -es decir, estandarizada-, podemos ganarnos
cómo puede traducirse en una aplicación práctica. De hecho, es habitual que un
fabricante "internalice" algunas interfaces en cajas híbridas, es decir, multifunción,
en lugar de implementarlas explícitamente. En otros casos, las interfaces se
ampliarán o enriquecerán más allá de la norma.
Este tema es demasiado amplio para tratarlo aquí en toda su generalidad. No
obstante, queremos analizar lo que estas consideraciones tienen que ver con la
implementación de la función de medios y las opciones que podemos encontrar en el
mercado. No obstante, debemos señalar que este tema no se ignora en las normas; en
TS
24.147 (versión 7), encontramos lo siguiente:

Como la división funcional entre el AS de conferencia y el MRFC está del

alcance del presente documento, los procedimientos se describen para un
102 Manual del subsistema multimedia fP (fM£)

AS y MRFC de conferencia combinados. El AS y el MRFC pueden estar coubicados o

interoperar utilizando un protocolo propietario y una división funcional
propietaria.

La función multimedia
Recordemos en primer lugar que las aplicaciones de red que pueden construirse
utilizando el MRF son muy variadas. Esta variedad se refleja en la oferta comercial.
Encontramos:

• transcodificadores;
• servidores/transmisores de mensajes;
• IVR;
• otros productos especializados, como el reconocimiento de voz;
• conferencia puente;
• juegos; y
• mensajería unificada.

Más allá de la simple descomposición funcional, otro elemento a considerar son

los medios utilizados para configurar o adaptar dichos servicios a las necesidades de
los usuarios. Profundizaremos en esta cuestión en la próxima sección.

Algunos ejemplos
Presentamos aquí algunos productos presentes en el mercado a principios de 2007.
Empezamos con los productos o fabricantes especializados en el procesamiento de
medios y terminamos con los productos de los principales fabricantes. Tenga en
cuenta que esto pretende ser un estudio de la diversidad de enfoques del mercado de
IMS más que una aprobación de los fabricantes.

Tecnología Cantata: Cantata nace de la fusión de Brooktrout Technologies y

Excel Switching. La línea de productos aborda las distintas necesidades de
medios del IMS, tanto la función MRF como la función break- away:
IMG 1010: Este dispositivo es una pasarela VoIP de medios y señalización.
Proporciona conectividad con redes de voz, lo que permite prestación
de servicios SIP en dominios de telefonía heredados, así como la
transcodificación de IP a IP (peering).
Servidor de medios IP SnowShore: Este dispositivo combina las funciones
de MRFC y MRFP. Ofrece, entre otras funciones, vídeo, anuncios,
mezcla e integración de contenidos dinámicos. Tenga en cuenta que no
está específicamente dirigido a IMS, sino que está pensado para
integrarse fácilmente en un entorno basado en SIP.
Excel MSP 1010: Esta plataforma admite simultáneamente el
procesamiento avanzado de medios y señalización, incluyendo:
Sobre el apoyo a las funciones de los medios de 103
comunicación en la fM£

– mensajería de voz y vídeo;

– tono de llamada personal;
– servicios de prepago;
– mensajería unificada; y
– servicio de mensajería corta.
Una familia: Observa cómo pueden utilizarse juntos estos productos. Por
ejemplo, el servidor de medios puede actuar como transcodificador
para un anuncio de mensaje proporcionado por la IMG 1010. Por
supuesto, se necesita un servidor de aplicaciones para realizar el
control general.
IPunity-Glenayre: el producto MRF de esta empresa se presenta en dos
componentes: un servidor multimedia y un servidor de aplicaciones. El MS
puede realizar una serie de funciones estándar, como streaming de vídeo,
tonos o anuncios, o bridging. La empresa ofrece una serie de servicios
preempaquetados sobre sus productos destinados al mercado empresarial o
de operadores, como la conferencia. También incluye soporte MEGACO.
Radisys: La familia de servidores de medios Convedia de Radisys integra todas las
funciones de los servidores de anuncios tradicionales (telefonía), actuando
como soporte para la telefonía IP: unidades de respuesta de voz interactiva
(IVR/VRU), puentes de audio y videoconferencia, mensajería, TTS y
reconocimiento de voz. Admite una interfaz SIP, así como una versión
anterior de MEGACO.
Alcatel-Lucent: Los productos de Alcatel-Lucent están en línea con la
arquitectura IMS y soportan explícitamente -y por separado- las funciones
MRFC, MRFP, MGW y SGW:
Pasarela de medios: La pasarela de medios Alcatel-Lucent 7510 es una pasarela
multiservicio en el plano de medios, en el sentido de que admite tanto
el MGW como el MGW troncalizado. En el plano de control (plano de
señalización)admite las funciones SGW e I-BGF (de nuevo, admite
medios VoIP troncales y locales). También se ha diseñado como
escalable ("soporte de pago por crecimiento").
Controlador de red: Esta línea de productos proporciona la función MGW y
promueve una migración sin problemas a los servicios multimedios de
próxima generación. También puede soportar opcionalmente la SGW,
o puede suministrarse de forma independiente. Alcatel-Lucent también
ofrece un servidor de funciones, que es esencialmente un producto
SGW que admite una amplia gama de servicios heredados, como
teléfono gratuito, números 800 y devolución de llamada, a través de su
interfaz IN/AIN. Este producto también admite servicios de
emergencia y funciones de interceptación legal. También dispone de
una interfaz SIP que puede utilizarse para soportar aplicaciones IP
Centrex.
Controlador de pasarela de medios: Este producto actúa como MGCF
controlando los productos de pasarela que utilizan MEGACO o SIP tanto para
el acceso como para la transmisión.
104 Manual del subsistema multimedia fP (fM£)

funciones de trunking. También permite el acceso a servidores de voz,

como los servidores Centrex, y puede controlar MRF IP para permitir
anuncios y conferencias, englobando así algunas funciones de MRFC.
de recursos de medios: Este producto es compatible con las funciones
MRFC y MRFP. Permite realizar audioconferencias y
videoconferencias con una multiplicidad de funcionalidades de apoyo a
la conferencia, como la interacción con los usuarios antes de la
conferencia, la inserción de texto en los flujos de vídeo y la mensajería
de voz y vídeo. Este producto se adapta sobre todo a entornos
convergentes (fijos y móviles). También permite compartir la
funcionalidad de procesamiento de medios para otros servicios como
los servicios de vídeo basados en contenidos y las aplicaciones
celulares push-over, lo que permite una utilización eficiente de la
funcionalidad de procesamiento de medios. El producto MRF de
Alcatel-Lucent también segrega las rutas de evolución para el MRFC y
el MRFP, lo que permite una mayor escalabilidad y redundancia.
Siemens: Siemens ofrece el producto denominado HiPath 8000, que soporta SGW,
MGW, conferencias y funciones de texto a voz. También admite
señalización SIP y MGCP en general, MGCP, etc. Este producto es
conocido por sus considerables características de interoperabilidad con
productos de otros proveedores, como Cisco, y su idoneidad para
despliegues a gran escala (es decir, miles de usuarios).
Ericsson: Los productos de Ericsson admiten las funcionalidades MGW, SGW
y MGCF dentro de los productos de:
Pasarela de medios: La pasarela de medios de Ericsson se basa en el
producto AXD 301 de Ericsson y realiza la de pasarela de medios,
controlada por el protocolo H.248. Está diseñada para ofrecer una alta
escalabilidad y disponibilidad. Está diseñado para ofrecer alta
escalabilidad y disponibilidad.
Pasarela de acceso: La pasarela de acceso de Ericsson ofrece la fun-
cionalidad SGW convirtiendo la señalización entre RTC y RDSI en IP
(es decir, protocolo de usuario RDSI [ISUP]).
Servidor de telefonía de Ericsson: Este producto actúa como MGCF y
proporciona señalización ISUP, SIP-T y H.323, lo que le permite
interactuar con una amplia gama de SGW y MGW. Al estar basado en las
plataformas AXE, también se espera que este producto ofrezca alta
disponibilidad y escalabilidad.
Cisco: La cartera de productos de Cisco incluye el soporte de las funciones
MGW, SGW y MGCF:
Control de pasarela de medios: El producto Softswitch Cisco PGW 2200
actúa como MGCF y soporta una amplia gama de funcionalidades,
como la redirección a mitad de llamada y la interceptación legal.
También soporta la función BGCF, que permite seleccionar la MGCF
que debe gestionar la llamada. Las funcionalidades avanzadas de
frontera de sesión están en la hoja de ruta de este producto. Este
producto se implementa en plataformas Sun.
Sobre el apoyo a las funciones de los medios de 105
comunicación en la fM£

Pasarela de medios: El MGX 8880 actúa como IMS-MGW y es el más

adecuado para grandes despliegues. Es compatible con una amplia
gama de protocolos de señalización (MGCP, TGCP, H.248, H.323 y
SIP), lo que facilita su despliegue tanto para aplicaciones IMS como no
IMS. Además, y en línea con las ofertas tradicionales de Cisco, este
producto admite la mayoría de los protocolos de enrutamiento (como RIP,
OSPF o BGP) y también admite QoS a través de su compatibilidad con
MPLS DiffServ.
Pasarela de señalización: Por último, el producto conocido como Cisco IP
Transfer Point (ITP) actúa como la función SGW para permitir la
interconectividad con las redes PSTN. Está implementado en el Cisco
2811 IP Transfer Point LinkExtender (ITP-L), Cisco 7204 y 7206, Cisco
7301 y Cisco 7600 Series.

Entender el mercado
Podemos resumir esta breve encuesta informal con una lista de cuestiones. Una vez
más, no se trata de comparar estos productos en términos de calidad, sino más bien
de subrayar las distintas estrategias elegidas por los fabricantes y exponer el estado
de fluctuación del mercado. Tampoco queremos dar a entender que otros fabricantes
importantes (por ejemplo, Huawei, Nortel) no tengan productos propios de calidad
relevante.

¿Están orientados al IMS? Vemos que muchos productos son esencialmente

de telefonía IP, ya sea como soporte de softswitch o para el
interfuncionamiento con la telefonía tradicional. Sin duda hay razones
obvias para ello, porque ese mercado es anterior a IMS. Por supuesto,
como las mismas funciones están presentes en IMS, cualquier distinción
con generaciones anteriores puede ser borrosa, excepto por un par de
cuestiones: qué interfaz de control se implementa y si hay un servidor de
aplicaciones en segundo plano para apoyar el desarrollo de servicios.
¿Distinguen los medios? La mayoría de los productos admiten la distinción
entre una función de medios de interfuncionamiento de telefonía y un
puerto de medios para el despliegue de servicios de telefonía IP. Además,
el streaming se limita principalmente al soporte de telefonía, posiblemente
ampliado a la videotelefonía.
¿Separan los medios y el control? Algunos productos integran ambas funciones en un
solo chasis y proporcionan ambas formas de acceso (señalización, control)
externamente.
¿Incluyen AS? Como ya se ha dicho, disponer de un AS en la base permite
desplegar nuevos servicios en el ámbito IMS. Muchos de los productos
presentados anteriormente ofrecen esencialmente servicios de telefonía
clásica -de inspiración POTS o PABX- de integrada. En la siguiente
sección, revisamos algunos mecanismos proporcionados para suministrar
tales servicios, así como medios alternativos para proporcionar nuevos
servicios.
106 Manual del subsistema multimedia fP (fM£)

¿Se dirige el mercado en una dirección concreta? Podemos observar los primeros
signos de consolidación en el mercado, ya que las pequeñas empresas se
fusionan para ofrecer una gama más amplia de productos de procesamiento
de medios/pasarela. Al mismo tiempo, el vínculo con la aplicación sigue
siendo débil porque se admiten un gran número de interfaces diferentes que
se solapan y los servicios suelen estar preempaquetados.

Otros asuntos
La arquitectura IMS se mueve a medida que crece el interés y los posibles dominios
de despliegue, al igual que el trabajo en el IETF, el W3C y otros foros sobre temas
relacionados. Presentamos aquí las tendencias en una serie de temas, empezando por
el debate sobre las visiones centradas en la red y en el terminal, sobre los protocolos
de control para las funciones de medios, hasta el aprovisionamiento.

Centrado en la red frente a centrado en el terminal

Hasta ahora hemos explorado la visión normalizada de IMS. El lector se habrá dado
cuenta de que esta visión está más bien centrada en la red o, mejor dicho, en el
operador. Los terminales podrían incluso considerarse una emanación de la red. El
inconveniente es que tendemos a considerar que los servicios requieren el apoyo de
la red (IMS), cuando no tiene por qué ser . Podemos distinguir tres casos diferentes:

1. llamadas de terminal a terminal;

2. llamadas de terminal a MRF (o de MRF a terminal), con variantes con
múltiples puntos finales (conferencia o devolución de llamada); y
3. terminal a terminal a través de la red.

El inconveniente del modelo centrado en la red sería considerar que todas las
llamadas requieren soporte de AS, lo que provocaría un aumento de la carga en el
plano de señalización. Aunque no cabe duda de que se trata de una necesidad para
las llamadas asistidas por MRF, debemos considerar cuándo las llamadas de
terminal a terminal (caso 1) deberían utilizar realmente un relé (caso 3).
La cuestión está esencialmente relacionada con el servicio que activa el usuario y
con el hecho de que el servicio le permita o no añadir -y eliminar- características a la
llamada. En la arquitectura IMS, mientras la señalización se enrute a través de un
AS, es posible insertar o eliminar un MRF en la llamada y notificar el a los
terminales. Obsérvese también que este problema no se limita al flujo de medios en
sí, ya que es posible establecer canales de control específicos de la aplicación, como
en el ejemplo de control de planta mencionado anteriormente.
Sobre el apoyo a las funciones de los medios de 102
comunicación en la fM£

En realidad, estos canales forman parte del problema. Si deben establecerse de

extremo a extremo, será obligación de la MRF retransmitirlos hasta su destino.
Como ejemplo, podríamos considerar una función de streaming basada en el
terminal, que podría requerir transcodificación. Si el control de medios se realiza a
través del protocolo de streaming en tiempo real (RTSP), sería necesario
retransmitirlo a través de la MRF o se correría el riesgo de perder la sincronización
de los flujos.
En realidad, éste es un ejemplo de los problemas que pueden surgir a medida que
desarrollemos más servicios basados en terminales que en redes, lo que parece una
tendencia natural porque la capacidad de cálculo de los terminales aumentará. La
transferencia de datos de extremo a extremo, el acompañamiento a un servicio de
mensajería instantánea e incluso el peer to peer son también candidatos probables.
Los servicios de terminal frente a los de red se convertirán probablemente en una
cuestión crítica en el futuro, si la evolución de Internet sirve de indicación. La
posibilidad de instalar cualquier aplicación en un terminal, posiblemente mediante
descarga, significa que, con el tiempo, los operadores no podrán controlar los
servicios que se desplegarán en los terminales y tendrán dificultades para integrar su
soporte en sus plataformas IMS. Estas consideraciones serán probablemente críticas
para la evolución del IMS.

Protocolos de control para las funciones de medios

Hemos presentado MEGACO y SIP y mencionado MGCP, un antepasado de
MEGACO que aún se encuentra en el mercado. Se discute si SIP por sí mismo no es
suficiente para cubrir estas diferentes formas de señalización y si MEGACO es
necesario en absoluto. Obsérvese que SIP puede utilizarse entre un controlador y un
procesador sin poner necesariamente al procesador en el flujo de llamada (es decir,
sin retransmitir el establecimiento de llamada), sino con una llamada lateral (IETF
RFC 4240). No obstante, hay otras alternativas a tener en cuenta:

MRCP: El protocolo de control de recursos de medios, estandarizado como

RFC 4463 bajo el impulso de Cisco y empresas de procesamiento de voz,
está pensado para controlar recursos como sintetizadores y reconocedores
de voz, generadores de señales, detectores de señales y servidores de fax.
Una versión más reciente del protocolo lo vincula mucho más a SIP para
reflejar las tendencias actuales de la telefonía IP.
MRCP no es un protocolo "autónomo"; depende de un protocolo de gestión de
sesiones -es decir, SIP o RTSP- para establecer una sesión de control entre el
cliente y el servidor, incluida la negociación de los parámetros de llamada.
También depende de SIP y SDP para establecer las sesiones de medios y
los parámetros asociados entre la fuente o sumidero de medios y el servidor
de medios. Una vez establecida la llamada, los intercambios MRCP se
ejecutan en paralelo con la sesión de medios y señalización, lo que permite
al cliente controlar los recursos de procesamiento de medios en el servidor
de recursos de voz. En la siguiente sección, veremos cómo puede este
protocolo junto con VoiceXML.
108 Manual del subsistema multimedia fP (fM£)

API: Hasta ahora hemos insistido mucho en los puntos de referencia y los
proto- colos, pero son sólo una perspectiva, digamos orientada a las
telecomunicaciones. La otra, más orientada a la programación, consiste en
definir una interfaz de programación de aplicaciones. Este modelo es
bastante popular con el lenguaje de programación Java porque permite a
todos los usuarios potenciales compartir una visión común de un servicio, o
conjunto de funciones, entre productos de distintos fabricantes.
Como parte del proceso de la comunidad Java, en 2007 se puso en marcha una
iniciativa para especificar una API de control de servidores multimedia,
denominada JSR 309. Esta API competiría directamente con MEGACO, pero
sólo se encuentra en las primeras fases de especificación. No obstante,
ayudaría a soportar modelos de implementación alternativos para
componentes IMS y facilitaría aún más la integración de funciones
multimedia en las aplicaciones.

Aprovisionamiento y configuración
Otra dimensión es la creación o prestación de servicios, especialmente en de scripts.
En la última década hemos asistido a una explosión del número de aplicaciones del
metalenguaje extendido (XML) con este fin. Presentamos aquí dos ejemplos
relacionados con las funciones multimedia:

VoiceXML: VoiceXML es un lenguaje de programación declarativo

estandarizado por el W3C para crear aplicaciones de telefonía basadas en
voz. VoiceXML admite diálogos con voz sintetizada, audio digitalizado,
reconocimiento de voz e introducción de teclas DTMF, grabación de audio,
control de llamadas de telefonía básica y conversaciones de iniciativa
mixta. Ahora podemos ver por qué MRCP, descrito anteriormente, es un
compañero perfecto para VoiceXML para controlar remotamente un motor
de procesamiento a través de scripts VoiceXML.
VoiceXML es principalmente un lenguaje de diálogo; está diseñado para
gestionar un diálogo de voz o vídeo entre un humano y un ordenador.
Aunque incluye algunas funciones básicas para la transferencia de
llamadas, éstas son redundantes con las funciones proporcionadas por SIP.
Fue diseñado originalmente por el W3C para ser descargado desde un
servidor a un cliente, en un modelo típico de desarrollo basado en la Web,
de forma que el cliente pudiera controlar directamente los recursos de
procesamiento de medios como si se tratara de una interfaz de usuario de
voz.
Lenguaje de marcado y protocolo de control del servidor de medios: Media server
control markup language (MSCML; también RFC 4722) es un lenguaje de
marcado utilizado junto con SIP para proporcionar funciones avanzadas de
conferencia e IVR. MSCML presenta un modelo de control a nivel de
aplicación, en contraposición a los modelos de control a nivel de
dispositivo. Uno de los usos de este protocolo es para las comunicaciones
entre un foco de conferencia y un mezclador en el marco de conferencias
SIP del IETF.
Sobre el apoyo a las funciones de los medios de 109
comunicación en la fM£

Resumen y observaciones finales

En este capítulo, hemos revisado y analizado diferentes perspectivas sobre las
funciones de los medios de comunicación en IMS, incluido un estudio de las normas
pertinentes. Nuestra exploración de las cuestiones relativas a los medios de
comunicación ha sido bastante amplia, y muchos puntos merecerían sin duda una
exploración más profunda. Nuestro objetivo ha sido exponer las distintas fuerzas
que actúan en este ámbito tan dinámico y aún tan agitado. Más allá de las
alternativas tecnológicas/técnicas, también hay fuerzas políticas en juego.
Presentamos una serie de cuestiones clave que probablemente se plantearán en un
futuro próximo:

Limitaciones de SIP: SIP ha reconocido [16] limitaciones en la identificación

y el control dinámico de los servicios. Esto requerirá una mayor evolución
que le permita soportar un amplio conjunto de servicios en un único
terminal de forma concurrente.
Control de SIP: a pesar del punto anterior, SIP es un proto- colo del IETF, pero el
3GPP es el principal usuario de SIP. Con Telecoms and Internet Con- verged
Services and Protocols for Advanced Networks (TISPAN) y PacketLabs ahora
muy interesados en IMS, hay tensiones para controlar la vía de evolución del
protocolo según los "intereses dominantes".
Infraestructura frente a servicios: Aunque IMS es una infraestructura, otros
organismos, como la Open Mobile Alliance, se preocupan más por los
servicios que por la propia infraestructura. Esta actitud es más
comprensible cuando nos damos cuenta de que los servicios -como IP/TV-
pueden crearse y desplegarse con bastante rapidez sobre una infraestructura
dedicada, pero el despliegue a gran escala de IMS aún no está previsto en
el horizonte a medio y largo plazo.
Medios y servicios: Más allá de la cuestión de cómo implementar la función
de medios, tenemos la de crear servicios en torno a ella. La mayor parte de
lo que vemos en este momento sigue siendo telefonía IP y utiliza un gran
número de lenguajes e interfaces especializados. Hay que seguir trabajando
en este sentido.
Modelo de calidad de servicio: Será necesario un modelo de QoS decente,
más centrado en el usuario, tanto en el plano de medios como en el de
señalización.
Otros: Por supuesto, tenemos los problemas habituales de seguimiento del
consumo de recursos (es decir, contabilidad y facturación), así como de
seguridad en muchos niveles de interacción.

Referencias
1. IETF. SIP: Protocolo de iniciación de sesión, RFC 3261.
2. IETF. 2002. Protocolo MEGACO versión 1.0, RFC 3015.
110 Manual del subsistema multimedia fP (fM£)

3. IETF. 2002. Integración de la gestión de recursos y el protocolo de inicio de sesión

(SIP), RFC 3312.
4. IETF. 2000. Protocolo COPS (common open policy service), RFC 2748.
5. Proyecto de Asociación de 3ª Generación. Servicio transparente de flujo continuo con
conmutación de paquetes de extremo a extremo. 3GPP TS 22.233 V7.0.0 (2006-06)
etapa 1 (versión 7).
6. Proyecto de Asociación de Tercera Generación. Arquitectura de red 3GPP TS 23.002 V7.2.0
(2007-06).
7. Proyecto de Asociación de 3ª Generación. Subsistema multimedia IP (IMS); fase 2, 3GPP
TS 23.228 V7.8.0 (2007-06).
8. Proyecto de asociación de 3ª generación. Interfaz Mp del procesador de funciones de
recursos (MRFP): Descripciones de procedimientos, 3GPP TS 23.333 V1.0.0 (2006-12).
9. Proyecto de Asociación de Tercera Generación. Architectural enhancements for end-to-
end quality of service (QoS), 3GPP TR 23.802 V7.0.0 (2005-09).
10. Proyecto de Asociación de 3ª Generación. Conferencing using the IP multimedia (IM)
core network (CN) subsystem; stage 3 3GPP TS 24.147.
11. Proyecto de Asociación de 3ª Generación. Protocolo de control de llamadas multimedia
del protocolo de Internet (IP) basado en el protocolo de inicio de sesión (SIP) y el
protocolo de descripción de sesión (SDP); fase 3 3GPP TS 24.449.
12. Proyecto de Asociación de 3ª Generación. Transparent end-to-end packet switched
streaming service (PSS); general description (release 7); 3GPP TS 26.233 V7.0.0 (2007-
06).
13. Proyecto de Asociación de 3ª Generación. Specification group core network and ter- minals;
interworking between the IP multimedia (IM) core network (CN) sub- system and circuit
switched (CS) networks (release 7) 3GPP TS 29.163, version 1.0, version date: May 2007.
14. Proyecto de Asociación de 3ª Generación. Función de control de pasarela de medios
(MGCF)? Pasarela de medios IM; 3GPP TS 29.332 V7.7.0 (2007-06); etapa 3 (versión 7).
15. 3GPP2 X.S0029-0. Conferencing using the IP multimedia (IM) core network (CN)
subsystem version 1.0, version date: May 2007.
16. Camarillo, G. et al. 2007. Hacia un SGI orientado a la innovación. IEEE Communi- cations
Magazine, 3, marzo de 2007, pp 130-136.
17. UIT-T. Protocolo de control de pasarelas: versión 3 H.248.1, 09/2005.
 Sección 2

Tecnologías
5
El FOKU£ Open fM£ Core-Una
fmplementación global fM£ de referencia

Peter Weik, Dragos Vingarzan y Thomas Magedanz

CONTENIDO
Antecedentes del proyecto ................................................................................................. 114
Los componentes ............................................................................................................... 115
Requisitos .................................................................................................................. 117
Funciones de control de la sesión de llamada ......................................................... 118
Extensiones SER IMS ................................................................................... 119
Proxy-CSCF .................................................................................................. 121
Interrogar a la CSCF ................................................................................... 122
Al servicio del CSCF ................................................................................... 123
Servidor de abonados a domicilio......................................................................... 124
Trabajar con el núcleo IMS abierto................................................................................. 125
¿Una aplicación de referencia real? ..................................................................................... 127
Perspectivas ....................................................................................................................... 129
Referencias .......................................................................................................................... 130

En 2003, cuando comenzamos nuestro trabajo de investigación sobre el subsistema

multimedia IP (IMS), teníamos el gran reto de encontrar una solución adecuada que
nos permitiera enrutar y procesar la señalización del protocolo de inicio de sesión
(SIP) de acuerdo con los estándares IMS (en aquel momento 3GPP versión 5 [1]) a
un coste asequible para una institución de investigación y desarrollo (I+D). Aunque
encontramos muchos proyectos de código abierto centrados en temas SIP de la
Internet Engi- neering Task Force (IETF), lamentablemente no encontramos
ninguno con un énfasis y dirección específicos en IMS. Si a esto añadimos el hecho
de que teníamos un largo legado en el desarrollo de prototipos SIP en Fraunhofer
FOKUS, empezamos a hacer nuestro propio desarrollo.
Este capítulo debería ofrecer al lector una perspectiva de los antecedentes del
proyecto, la motivación para desarrollar software de código abierto para el
enrutamiento de mensajes en una red central IMS, y cómo puede ayudar no sólo a
acelerar el enrutamiento de mensajes, sino también a mejorar la calidad del servicio.

113
114 Manual del subsistema multimedia fP (fM£)

también un diseño, desarrollo y pruebas eficientes, flexibles y potentes de los

componentes y servicios de las redes de próxima generación (NGN). Aunque sólo
podemos esbozar algunos de los detalles de implementación y las principales
características de los cuatro componentes del núcleo IMS abierto, intentaremos
indicando cómo obtener, trabajar y ampliar el software y dónde obtener más
información. Dado que el resultado del proyecto hasta ahora se ha utilizado
ampliamente como implementación de referencia en el ámbito de la I+D, así como
en industria, al final del capítulo resumiremos algunos proyectos y usuarios
destacados que hacen uso de él.

Antecedentes del proyecto

La base para iniciar este proyecto de código abierto surgió de las actividades del
Open IMS Playground [2], un banco de pruebas de NGN verdaderamente abierto y
multiproveedor alojado en el Instituto Fraunhofer FOKUS de Berlín (Alemania).
Inicialmente financiado por el gobierno alemán para sus actividades de
investigación con el fin de desarrollar prototipos de componentes IMS para habilitar
servicios a pequeñas y medianas empresas, el banco de pruebas pronto se convirtió
en autosuficiente gracias a su cooperación con socios industriales interesados en
arquitecturas y aplicaciones NGN.
Desde el principio de este entorno de pruebas, tuvimos la clara intención de no
limitarnos a etiquetar el tráfico SIP para que se ajustara a IMS, sino más bien
desarrollar una solución de enrutamiento extensiva que permitiera todas las
características centradas en el operador que aporta una red IMS. Especialmente para
generar el formato SIP correcto, esto nos resultó natural porque podíamos basar gran
parte de nuestro trabajo en el SIP Express Router (SER) [3], un enrutador SIP muy
respetado desarrollado también en FOKUS.
La gran madurez y estructura modular de SER nos permitió centrarnos en
construir la funcionalidad IMS como una extensión de la misma en lugar de empezar
desde cero. Otro factor importante a la hora de elegir SER como base fue el hecho
de que hoy en día SER se considera una referencia para los proxies SIP. Casi todos
los estudios de rendimiento lo incluyen en sus evaluaciones y, debido a su
flexibilidad, es uno de los proxies SIP más utilizados del mundo. De cara al futuro,
es concebible que una red central IMS basada en SER también pueda ser al menos
competitiva, si no representativa, del rendimiento y la flexibilidad de las redes IMS,
al igual que SER lo es hoy en día para el manejo de voz sobre IP (VoIP).
Las primeras pruebas de interoperabilidad de proveedores en el Open IMS
Playground comenzaron en 2003 y, a partir de los comentarios de estos socios
industriales e investigadores, el software evolucionó a lo largo de los años junto con
las especificaciones para IMS. Al trabajar para una organización no comercial,
podíamos centrarnos en implementar las funciones esencialmente necesarias para
permitir la creación de prototipos para el desarrollo de aplicaciones IMS en
plataformas de prestación de servicios, así como en el lado del cliente, en lugar de
atender a las de ruta de funciones definidas por la dirección. En 2005 empezamos a
trabajar en el grupo de normalización de IMS
El FOKU£ Open fM£ Core-Una fmplementación global fM£ de referencia 115

benchmarking [4], donde el Open IMS Core sirvió como implementación de

referencia para un sistema bajo prueba (SuT). Gracias a los excelentes comentarios
que recibimos de los participantes, conseguimos eliminar muchos cuellos de botella
en el rendimiento del software y adaptarlo a las últimas normas IMS (que también
incluían requisitos del Instituto Europeo de Normas de Telecomunicaciones (ETSI),
Servicios y Protocolos Con- vergentes de Telecomunicaciones e Internet para Redes
Avanzadas (TISPAN) y otros organismos). En noviembre de 2006, tras más de tres
años de desarrollo y pruebas internas, decidimos poner el software a disposición de
la comunidad de I+D bajo la licencia pública general GNU versión 2 [5].
Procedente del ámbito de la I+D, la idea del proyecto Open IMS Core es, por
tanto, llenar el vacío existente en el ámbito del código abierto para el software IMS
y proporcionar una implementación de referencia del núcleo IMS para las pruebas
de tecnología IMS y la creación de prototipos de aplicaciones IMS con fines de
investigación, que normalmente se realizan en bancos de pruebas IMS. A través de
este proyecto, todos los desarrolladores potenciales de servicios IMS
(independientemente de si desarrollan en servidores de aplicaciones SIP; en una
pasarela Open Service Architecture (OSA)/Parlay o Parlay X, con tecnología Java
APIs for integrated Networks [JAIN] service logic execution environment (SLEE) o
incluso en un servicio de red inteligente (IN) que esté conectado al IMS a través de
una función de conmutación de servicios IMS) deberían tener a mano una interfaz
de control de servicios IMS (ISC) conforme con el Proyecto de Asociación de
Tercera Generación (3GPP) que les permita hacer uso de las funciones de
enrutamiento IMS para construir sus servicios. Sin embargo, también hacia la capa
de la red de acceso, el Open IMS Core tiene como objetivo impulsar el desarrollo de
componentes y conceptos que conlleva la unión de varias redes de acceso a la
arquitectura superpuesta IMS. Creyendo en la poderosa innovación que el código
abierto ha traído al mundo de Internet, queríamos que las funciones de enrutamiento
del núcleo IMS estuvieran completa y libremente disponibles al público para
extenderlas y hacerlas ajustables a las diversas necesidades y requisitos que las
pequeñas y medianas empresas, las universidades o los departamentos de I+D de
operadores y vendedores por igual tendrán que construir, investigar y desarrollar.

Los componentes
Aunque buscamos que el desarrollo de los componentes del núcleo IMS abierto
estuviera siempre muy vinculado a la evolución de las especificaciones del 3GPP, a
menudo esto no fue suficiente porque otros organismos de normalización
plantearon requisitos hacia una red de núcleo IMS. Intentaremos esbozar cómo
influyó en nuestro trabajo esta convergencia de redes a nivel de estándares hacia
una NGN, cómo están estructurados los componentes del núcleo IMS abierto y
qué características principales tenían que soportar.
En el momento de redactar este capítulo, el 3GPP, creado originalmente en
diciembre de 1998 con el objetivo de definir un sistema de telefonía móvil 3G
aplicable a escala mundial, se encuentra en fase de desarrollo.
116 Manual del subsistema multimedia fP (fM£)

sigue liderando la especificación de los conceptos IMS como solución para una red
de telecomunicaciones univer- sal totalmente IP (actualmente trabaja en la versión 8).
Además, su organización asociada, 3GPP2, adoptó los conceptos IMS desde el
principio y adoptó amplias partes del 3GPP. Sin embargo, el 3GPP2 se centra en dar
soporte a las tecnologías CDMA2000, mientras que el 3GPP se concentró durante
mucho tiempo en la adaptación a un conjunto de tecnologías inalámbricas (como el
acceso múltiple por división de código de banda ancha (W-CDMA) o las redes de área
local inalámbricas (WLAN)). Además, el ETSI está reconociendo el valor de IMS
como tercera organización con su organismo, el TISPAN, que tiene por objeto la
convergencia de las redes de línea fija e Internet. Las normas TISPAN NGN tienen
como objetivo la convergencia de redes mediante la adopción y reutilización de
componentes IMS con los añadidos de soportar tecnologías xDSL, pero se basaban
en la versión 6 de 3GPP y la revisión A de 3GPP2. En el momento de redactar este
documento, se está trabajando en la versión NGN
2. Además, el sector de las redes de cable empezó a adoptar el IMS como
plataforma de referencia para la prestación de servicios multimedia en el
PacketCable.
2.0 que, de nuevo, se basan en las especificaciones del 3GPP, pero aportan sus
propios requisitos y deltas. Para evitar más divergencias, a partir de la versión 8, el
3GPP ha anunciado la fusión de todos estos "sabores" diferentes en un IMS común.
Además de estos organismos principales, muchos otros grupos y organizaciones ven
el valor de una red IMS para prestar servicios a través de una red de operador y
adoptan conceptos e interfaces de la misma (por ejemplo, la versión 3 del
MultiService Forum (MSF)).
Dado que los distintos organismos de normalización aceptan las mismas
tecnologías (y normas) básicas de , es seguro afirmar que las próximas NGN
compartirán también los mismos componentes básicos IMS, que a su vez pueden
tener que admitir algunas adiciones u opciones para redes de acceso específicas. La
figura 5.1 ilustra este hecho para las redes fijas y móviles.
Al fin y al cabo, el enfoque de las NGN significa para los operadores pasar de los
tubos de calefacción para la prestación de servicios a un modelo por capas, que
cuenta con un plano de capa de acceso compatible con IP, un plano de capa de
control de sesión y el plano de capa de servicios. En el plano de la capa de acceso,
los clientes exigen que las redes de comunicación converjan en una capa que
permita el uso sin fisuras de cualquier tecnología de red para acceder a los servicios
de forma similar: redes cableadas o inalámbricas que no tienen por qué ser
diferentes desde la perspectiva del usuario. En el plano de la capa de servicio, los
servicios (que van desde los puramente centrados en las telecomunicaciones, como
los buzones de correo o el reenvío de llamadas a través de IPTV, hasta los mash-ups
con servicios y habilitadores en Internet) se desacoplan de la red de acceso y tendrán
interfaces definidas para los dos planos inferiores y el usuario, del mismo modo que
los servicios habilitadores, como la presencia o el uso de un servidor de gestión de
documentos XML (XDMS). El IMS, con su núcleo, actúa como intermediario entre
las redes de acceso y la capa de servicios para satisfacer las necesidades específicas
del operador, como la gestión centralizada de usuarios, el soporte de tarificación
definida y funciones como el inicio de sesión único, la seguridad o la conexión con
el dominio PSTN (red telefónica pública conmutada) y otras redes. Este es también
el ángulo desde el que contemplamos las NGN durante el desarrollo del Open IMS
Core.
El FOKU£ Open fM£ Core-Una fmplementación global fM£ de referencia 112

Parlay X Presencia
XDMS Pasarela SIP AS Servidor
Señalizaci
ón
Medios de

Capa de aplicación

HSS

I-CSCF S-CSCF

P-CSCF Pasarela
de
señalizaci

NASS A-RACS (S)PDF RTPC

Capa de control de
sesión
Servid Pasarela
BAS/ or multime
DSLAM A=BFG multi dia

WAG PDG
Core I-BGF/ IPv4
GGSN Red TrGW Red
RAN IPv6
SGSN
Red
Capa de
transporte

FIGURA 5.1
Las tres capas de una arquitectura NGN.

Requisitos
Aunque el IMS se basa en especificaciones del IETF como el estándar SIP [6] o
Diameter [7], el protocolo SIP requiere ciertas extensiones obligatorias, también
especificadas en el IETF, para utilizarlo en una red IMS. Por tanto, el principal
requisito del proyecto Open IMS Core era proporcionar un conjunto de componentes
compatibles con IMS que permitieran el mejor desarrollo de las demás capas a su
alrededor. A lo largo de los años hubo algunas diferencias en los distintos
organismos que se basan en IMS como arquitectura de referencia, especialmente en
lo que se refiere a métodos de autenticación y seguridad hacia los clientes; por tanto,
no existe un estándar IMS común (al menos, no por ahora). Entonces, el objetivo
principal era obtener funciones de control de sesión de llamada (CSCF) y un
servidor de subcriba doméstica (HSS) que, idealmente, cumplieran todas las
especificaciones paralelas. Sin embargo, a menudo esto significaba que debían
implementarse al menos todas las funcionalidades requeridas según lo indicado por
3GPP en sus especificaciones de la versión 6 (a veces incluso de la versión 7).
118 Manual del subsistema multimedia fP (fM£)

Otro requisito específico de las CSCF era mantener, en la medida de lo posible, el

máximo de SER. Dado que SER obtuvo una amplia adopción en el mundo SIP,
convirtiéndose casi en un estándar de rendimiento, cabe suponer que las CSCF, que
compartían una base tan amplia con los routers SIP, tendrían unos estándares de
rendimiento similares. En las extensiones IMS se han utilizado estructuras de datos,
algoritmos y patrones similares, manteniendo el bajo consumo de recursos. Para
concluir, era importante para nosotros mantener este de alto rendimiento,
especialmente porque el Open IMS Core tenía que producir respuestas por primera
vez para las cuestiones de escalabilidad, distribución y rendimiento de IMS.
El 3GPP sigue siendo el principal organismo de especificación para IMS. Sin
embargo, hemos visto que muchas implementaciones anteriores a IMS tomaban
atajos para conseguir mejores condiciones de funcionamiento al tiempo que
intentaban cumplir las especificaciones, y el Open IMS Core tuvo que reaccionar
ante ello manteniendo las facilidades de scripting de usuario de SER, que permiten
una flexibilidad total en la explotación y una configuración sencilla. El requisito de
fácil configuración también es válido para el HSS, que tenía que facilitar al máximo
la configuración de los perfiles de servicio y usuario IMS.
Por supuesto, para alimentar muchas instalaciones de bancos de pruebas IMS
como implementación de referencia, a menudo también es necesario conseguir
características cercanas a las de las operadoras en cuanto a rendimiento, cierta
seguridad y disponibilidad. Sin embargo, estos no eran los objetivos principales, ya
que nuestro principal interés era crear una comunidad abierta en torno a la red
central IMS. Las implementaciones comerciales proporcionarán, sin duda, todas las
características que, por suerte, no hemos tenido que tener en cuenta (por ejemplo, la
integración con sistemas operativos o de soporte empresarial específicos del
operador). Además, el proyecto Open IMS Core no pretende competir con este tipo
de implementaciones, sino más bien ayudar a la industria en sus esfuerzos de I+D
para superar los retos que plantea la creación de redes IMS y permitir el desarrollo
de servicios que hagan uso del núcleo IMS.
Partiendo de simples routers SIP, la realización de una red central IMS a partir de
ellos resultó ser una tarea difícil [8]. El principal reto era que tenía que funcionar
muy bien en términos de velocidad y funcionalidad. Tenía que reducir el
procesamiento al mínimo y, al mismo tiempo, implementar todas las
funcionalidades requeridas en las diversas especificaciones IMS de los organismos
mencionados. El objetivo era llegar a una implementación de referencia siguiendo
de cerca las especificaciones y sin comprometer la conformidad por el rendimiento.
Así, el proyecto Open IMS Core es, en definitiva, una combinación de las tres CSCF
definidas para IMS que se complementan con un HSS (véase la figura 5.2).

Funciones de control de la sesión de llamada

En su núcleo funcional, las CSCF son proxies SIP. Esta funcionalidad principal se
complementa con las capacidades de registrador y agente de usuario back-to-back
(B2B-UA). Dado que las tres entidades comparten muchas funcionalidades, tenía
sentido que utilizaran un sistema base común configurado de forma diferente. Las
CSCF
El FOKU£ Open fM£ Core-Una fmplementación global fM£ de referencia 119

SIP
HS IS
Cx C

I-CSCF S-CSCF
M M

IETF
P-CSCF
SIP Gm

Cliente VoIP Cliente IMS

FIGURA 5.2
Los cuatro componentes del Open IMS Core Project.

se basan en el SER, que puede actuar como registrador SIP, proxy o servidor de
redireccionamiento y es capaz de gestionar muchos miles de llamadas por segundo.
Gracias a su estructura modular, ha sido posible realizar ampliaciones de
funcionalidad. Cada entidad CSCF del Open IMS Core se implementa como un
módulo principal SER cargable dinámicamente que añade las operaciones
necesarias al SER para que pueda actuar de acuerdo con las especificaciones técnicas
específicas de 3GPP u otras. También se utilizan varios módulos secundarios para
proporcionar funcionalidades comunes como capacidades Diameter o acceso a bases
de datos. Los módulos son capaces de procesar en paralelo y pueden mantener
información de estado complementaria. Se hace especial hincapié en la
escalabilidad, tanto para la distribución de la carga como para la ocupación de
memoria.

Extensiones SER IMS

SER fue diseñado para ser un potente proxy/servidor SIP y también logró un gran
despliegue en configuraciones VoIP comerciales, por lo que se calificó como el
primer candidato para habilitar la funcionalidad SIP. Dado que actúa como su propio
proyecto de código abierto, estamos siguiendo lo que la comunidad SER está
haciendo y estamos construyendo sobre la última versión del SER también. Sin
embargo, para que fuera utilizable en un entorno IMS, tenía que contar con
capacidades Diameter. Esto no fue tan fácil como integrar las funciones de cliente
RADIUS en SER porque
120 Manual del subsistema multimedia fP (fM£)

un nodo Diameter debe tener capacidades de cliente y servidor al mismo tiempo.

Con especial preocupación por la velocidad, el uso de una pila externa no habría
dado buenos resultados debido a los numerosos cambios de contexto e intercambios
de datos. Sin embargo, el objetivo era tener una latencia baja, de apenas unos
milisegundos para las transacciones SIP, por lo que las peticiones Diameter debían
procesarse con retardos aún menores.
La solución obvia era añadir Diameter como módulo SER. La integración de una
pila Diameter hecha a medida, el peer C Diameter (cdp), demostró ser la mejor
solución en cuanto a rendimiento, haciendo que las CSCF del núcleo IMS abierto
sean un SER mejorado con Diameter (Figura 5.3). Los procesos peer Diameter se
ejecutan junto con los procesos SIP, proporcionando acceso cruzado a las
capacidades de cada uno y ofreciendo al mismo tiempo el mejor rendimiento.
Debido a su alto grado de paralelismo, lo mejor es ejecutarlos en un entorno
multiprocesador.
El reto para una S-CSCF en comparación con un router SIP puro es hacer cumplir las
reglas de un perfil de usuario almacenado centralmente empleado en un entorno
IMS y almacenado en un HSS. Esto se hizo con el módulo ISC. Aunque ya existían
módulos SER de localización, registro y autenticación de usuarios, las estructuras de
datos empleadas en IMS son más elaboradas. Una vez más, optar por la solución
sencilla de introducirlas como añadidos genéricos a los módulos existentes no habría
permitido obtener el mejor rendimiento. El módulo de localización de usuarios
requería adiciones para mantener la información adicional del usuario empleada en
IMS, como las identidades privadas/públicas, la información de la ruta Proxy-CSCF
(P-CSCF), los perfiles de servicio y los criterios de filtro iniciales. Replicar los datos
en una base de datos no es necesariamente necesario porque los mecanismos para
mover ordenadamente a los usuarios de una CSCF a otra ya están especificados en
IMS. El registrador también debe implementar las suscripciones y notificaciones de
eventos "reg" [9]. La P-CSCF emplea un registrador invertido que debe
sincronizarse con los registradores de las S-CSCF. En cuanto a la autenticación,
aunque los mecanismos de autenticación y acuerdo de claves (AKA) [10] son
obligatorios para generar material de claves para los túneles de seguridad de
señalización (IPSec) hacia un usuario IMS con 3GPP, tuvimos que ofrecer soporte
para varios otros

pcscf Proxy-CSCF
mysql

TI
SER icscf cdp Interrogación-CSCF
TM

...
scscf isc Serving-CSCF

FIGURA 5.3
Los módulos SER añadidos para el núcleo abierto IMS.
El FOKU£ Open fM£ Core-Una fmplementación global fM£ de referencia 121

también métodos de autenticación (por ejemplo, la autenticación digest del estándar

Packet- Cable 2.0 [11]).
A medida que el Open IMS Core iba siendo adoptado por más y más personas y
organizaciones, muchas de ellas empezaron a utilizarlo junto con entornos de
explotación cotidianos para realizar pruebas y comparaciones. De ahí surgió la
necesidad de que las CSCF y los HSS fueran cada vez más estables y ofrecieran al
menos un conjunto limitado de funciones de nivel de operador en la explotación.
Como resultado, los nodos se han complementado con una función de "persistencia"
que permite la recuperación inmediata de fallos o la reconfiguración sobre la
marcha, ampliando prácticamente la fiabilidad del Open IMS Core en el uso diario.

Proxy-CSCF
En la implementación actual del Open IMS Core, el componente P-CSCF puede
configurarse para cortafuegos de la red central a nivel de aplicación de SBC: sólo
los terminales registrados pueden insertar mensajes dentro de la red IMS y la P-
CSCF asegura la identidad de los usuarios (Figura 5.4). Para ello, tras el registro, la
P-CSCF establece canales seguros indi- vidualmente para cada punto final de
usuario (UE) al que presta servicio. Se pueden negociar asociaciones de seguridad
IPSec y TLS con los UE. Además de la funcionalidad SBC, la P-CSCF protege no
sólo a la red, sino también a los clientes de la señalización maliciosa.
Para realizar un seguimiento de los usuarios registrados, mantiene un registro
interno revertido que se actualiza interceptando el proceso de registro y,
posteriormente, suscribiéndose en modo cliente agente de usuario (UAC) al paquete
de registro en la S (serving)-CSCF y recibiendo notificaciones. Los datos reales se
guardan en tablas hash para permitir una recuperación rápida. Para originar la
señalización de llamada, genera vectores de carga únicos e inserta identificadores de
red y de ruta que son necesarios para el correcto procesamiento posterior de los
mensajes SIP. Se elimina o corrige la información falsificada del equipo de usuario
que pudiera dar lugar a un ataque. Tras un proceso de registro satisfactorio en una
red de origen IMS, los mensajes de usuario posteriores se reenvían en función de la
información DNS (sistema de nombres de dominio) hacia la red de origen IMS
solicitada.
En cuanto a los problemas de traducción de direcciones de red (NAT) para la
señalización SIP, en la dirección saliente, hacia los puntos finales de usuario, puede
actuar como enrutador simplemente estando activo en ambas redes. Además, se
adaptaron módulos NAT traversal para los mecanismos específicos de
almacenamiento de la ubicación del usuario. Una vez eliminados los datos de
seguridad específicos del usuario (como las claves de cifrado), los mensajes SIP se
reenvían directamente a su destino. El filtrado en esta dirección es necesario porque
el material cifrado no debe enviarse a través de la conexión potencialmente no fiable
entre el UE y la P-CSCF.
La P-CSCF también implementa una interfaz Diameter para soportar el
intercambio de la información necesaria para realizar el control de políticas y
tarificación (PCC) [12] en las sesiones multimedia que se establecen en la red de
acceso, así como funciones de autenticación en entornos de subsistema de conexión
a red (NASS). Además, para la funcionalidad requerida por PCC, la P-CSCF sigue y
122 Manual del subsistema multimedia fP (fM£)

Red doméstica 1 Red doméstica 2

Red visitada

CSCF
proxy

IMS UE IMS UE IMS UE

Canal seguro
de señalización
SIP

FIGURA 5.4
La funcionalidad Proxy-CSCF.

mantiene todos los diálogos enrutados para que sean posibles las actualizaciones
administrativas y la terminación.

Interrogar a la CSCF
La CSCF interrogadora (I-CSCF) tiene el papel de un proxy sin estado que,
utilizando las identidades públicas indicadas del llamante, consulta al HSS y,
basándose en las respuestas, encamina el mensaje a la S-CSCF correcta (Figura 5.5).
Implementa la interfaz Cx [13] (resp. [14]) de una I-CSCF al HSS. Por lo tanto,
soporta los comandos Diameter necesarios para localizar la S-CSCF asignada al
usuario o para seleccionar, basándose en las capacidades, una nueva S-CSCF y
comprobar identidades y autorizaciones de itinerancia. Tras recibir una respuesta
satisfactoria a la consulta Diameter, la I-CSCF reenvía los mensajes SIP en modo
transaccional. Está optimizado para la velocidad y se mantiene una información de
estado mínima. Para proteger la red doméstica, dispone de un cortafuegos que sólo
permite mensajes de señalización procedentes de redes de confianza a través de la
seguridad de dominio de red (NDS). Además, puede utilizarse como pasarela de
ocultación de topología (THIG), que cifra y descifra las cabeceras SIP sensibles
como proxy para todos los mensajes entrantes y salientes intercambiados con redes
que no son de confianza.
El FOKU£ Open fM£ Core-Una fmplementación global fM£ de referencia 123

HSS

NDS
Red doméstica

S-CSCF

Red visitada 1 Red visitada 2

THIG

FIGURA 5.5
La funcionalidad CSCF interrogadora.

Al servicio de CSCF
La S-CSCF también se comunica con el HSS utilizando Diameter para recuperar
vectores de autenticación, actualizar la información de registro y descargar los
perfiles de usuario tal y como se especifica en las referencias 11, 13 o 14 (Figura
5.6). Para ser realmente convergente, implementa soporte para llevar a cabo el 3GPP
IMS Digest AKA versión 1 [10] y versión 2 [15], Digest MD5 en cuatro sabores
diferentes (3GPP AKA MD5 adaptado por FOKUS para MD5 solamente, CableLabs
PacketCable
2.0 SIP-Digest [11], ETSI/TISPAN NGN Rel. 1 HTTP-Digest [14], 3GPP Rel.8
SIP-Digest [13,16]), así como Early-IMS-Security [17] de 3GPP o la autenticación NASS-
bundled [14] de ETSI TIS- PAN.
En lugar de generar vectores de autenticación, la S-CSCF confía esta tarea al HSS
y compara estos valores con los calculados en el UE. Para obtener tiempos de respuesta
rápidos con un bloqueo mínimo, el registrador de la S-CSCF tiene una estructura
compleja basada en tablas hash. La información necesaria para relacionar una
identidad de usuario con un UE físico se almacena aquí y se utiliza posteriormente
para el enrutamiento de llamadas. También acepta suscripciones a eventos de estado
de registro y notifica a los abonados los cambios en el registrador. Se siguen
diálogos para que sea posible la terminación administrativa.
Para la funcionalidad de activación de servicios, la S-CSCF puede aplicar los
criterios de filtro inicial basados en el pro- archivo de usuario (iFC) para aplicar
reglas de enrutamiento SIP específicas por usuario. A continuación, los mensajes se
enrutan a través del servicio IMS con-
124 Manual del subsistema multimedia fP (fM£)

Servidores de
aplicaciones

HSS

I-CSCF Red S-CSCF

Red B Red C

Señalización
SIP
Diámetro

FIGURA 5.6
La funcionalidad CSCF Servidora.

(ISC) hacia los servidores de aplicaciones. Las interfaces adicionales con funciones
de recursos de medios (MRF), pasarelas de medios o break outs PSTN también se
pueden habilitar fácilmente modificando el script de enrutamiento SER para la S-
CSCF.

Servidor de abonados a domicilio

El Open IMS Core estaría incompleto sin un Home Subscriber Server (Figura 5.7).
FOKUS ha desarrollado su propio prototipo de HSS, el FOKUS HSS (FHoSS),
totalmente escrito en Java y basado también en software de código abierto. Los
datos de usuario se guardan en una base de datos MySQL externa. Su propósito en
el Open IMS Core es el de una base de datos, por lo que el FHoSS está orientado
principalmente a la conformidad, sin perder de vista el rendimiento. Se trata
principalmente de un pegamento entre un sistema de gestión de bases de datos y las
interfaces Diameter con las CSCF y la capa de aplicación IMS. Las comprobaciones
de protocolo y la lógica de comandos Diameter se implementan en el HSS. Además,
permite la generación de vectores de autenticación [13] y la notificación de IMS-
El FOKU£ Open fM£ Core-Una fmplementación global fM£ de referencia 125

Dominio de Servidores de
seguridad aplicaciones

Zh
BSF
HSS
NAF

Diámetro

FIGURA 5.7
La funcionalidad HSS.

a servidores de aplicaciones IMS suscritos a través del punto de referencia Sh [18],

y ofrece soporte para la interfaz Zh [19] en la autenticación de usuarios como parte
de una Arquitectura de Autenticación Genérica. Proporciona una interfaz de gestión
basada en web para gestionar fácilmente los perfiles de usuario, los esquemas de
autenticación, las iFC asociadas, etc.
Como descubrimos [20], uno de los principales cuellos de botella en el
rendimiento parece estar relacionado con el HSS y el acceso a la base de datos. Por
tanto, para evaluar el mero rendimiento de las CSCF, se necesitaba un HSS muy
rápido, ya que la implementación de métodos de replicación, distribución,
almacenamiento en caché u otros métodos de optimización en el HSS no es eficiente
porque el sistema de gestión de la base de datos ya los implementa. Por lo tanto, se
implementó en C un emulador ligero de HSS sin estado que permite operaciones
específicas sobre la interfaz Cx [13] para llevar a cabo algunas mediciones
relacionadas con el rendimiento. Se ejecuta en una arquitectura multihilo y es capaz
de manejar muchos clientes y procesar las peticiones a través de trabajadores
paralelos. No mantiene ningún estado de IMS en memoria, sino que utiliza la misma
base de datos MySQL para este fin.

Trabajar con el Open IMS Core

El sitio web del proyecto [21] contiene información detallada sobre los requisitos de
sistema operativo (Linux), hardware (PC de sobremesa normal) y software;
información sobre cómo obtener el software y, sobre todo, una guía paso a paso
sobre cómo instalarlo y actualizarlo. Por ello, en lugar de describir estos pasos,
remitimos al lector interesado a las instrucciones de la referencia 21. Como sabemos
por los informes de los usuarios que incluso los más inexpertos pueden hacerlo en
menos de 20
126 Manual del subsistema multimedia fP (fM£)

si (método==INVITE || método==SUBSCRIBE ||
method==MESSAGE) {
(1.1) if (!P_is_registered("[Link]")){
(1.2) sl_send_reply(403,Prohibido Debe registrarse primero); break;
}
P_add_P_Charging_Vector();
P_add_P_Visited_Network_ID("[Link]");
}

FIGURA 5.8
Extracto del archivo de configuración CSCF.

minutos, suponemos que hemos logrado el objetivo de ofrecer una solución sencilla
y fácil de configurar. Además, se ofrecen instalaciones completas listas para
funcionar como instalación de máquinas virtuales preconfiguradas, con lo que el
tiempo de instalación se reduce prácticamente a cero.
Los usuarios pueden personalizar los respectivos módulos de la CSCF a través de
un sencillo archivo de configuración, que está alineado con los archivos de configuración
de SER. Permite a los usuarios habilitar funciones (por ejemplo, para soportar clientes
IMS que utilizan trans- lación de direcciones de red con la configuración mod-
param("pcscf," "NAT_enable," 1) en el archivo de configuración de la P-CSCF) y el
comportamiento predeterminado de la CSCF en un sencillo lenguaje de scripts de
enrutamiento de mensajes (Figura 5.8). Debe tenerse en cuenta que estos scripts de
enrutamiento son meros ejemplos para ser utilizados como una puesta en marcha
para los administradores de red, y no se requiere experiencia en programación con el
fin de habilitar características o añadir interfaces y reglas de enrutamiento. Para
editar la información de suscripción IMS, la configuración del servidor de
aplicaciones y los perfiles de usuario, el HSS ofrece una consola web protegida
accesible con un navegador web normal (Figura 5.9). Además, se proporcionan
muchos scripts que permiten la manipulación automática de las bases de datos con
configuraciones y usuarios personalizados para entornos de prueba IMS distintos del
predeterminado.
Dado que somos un pequeño grupo de desarrolladores, no disponemos de los
recursos humanos necesarios para mantener diferentes versiones de paquetes de
software y una extensa documentación escrita. Por eso hemos optado por
mantenernos, de momento, en un estado de desarrollo continuo. Esto significa que
sólo consultamos la última revisión en un árbol SVN para posibles solicitudes de
errores y funciones recibidas en las distintas listas de correo del proyecto. La
comunidad de desarrolladores encontró una solución para automatizar este reto de
tener que mantenerse al día con los desarrollos al proporcionar la imagen de
máquina virtual mencionada anteriormente que permite una configuración y
actualizaciones automatizadas y el registro de las instalaciones en ejecución, lo que
facilita aún más a los principiantes el desarrollo en torno a ella. El mismo concepto
se aplica a la documentación. Aquí proporcionamos sitios web que reflejan el código
documentado y las directrices de uso.
El FOKU£ Open fM£ Core-Una fmplementación global fM£ de referencia 122

Archivo Editar Ver Historial Marcadores Herramientas

[Link]

FHoSS - El servidor de abonados FOKUS (Rel. 7)

IDENTIDADES DE USUARIOS PARTICULARES SERVICIOS

Servicios

Búsqueda
de perfiles
de servicio
Cree ID Introduzca los
Nom
Búsqueda de
servidores de
aplicaciones
Cree

Puntos
gatillo
Buscar
Crear

Esperando [Link]... Open Notebook

FIGURA 5.9
La interfaz de aprovisionamiento HSS.

Además, para los desarrolladores interesados en contribuir al Open IMS Core,

existe una política flexible y abierta; proporcionaremos una rama de desarrollo
pública a cualquier parte que pueda justificar que faltan actualmente características
específicas. También debido a esta naturaleza abierta y a pesar de ser un verdadero
software especializado para el ámbito de las telecomunicaciones, el proyecto
consiguió en su primer año de existencia pública crear una comunidad de
desarrolladores vital en todo el mundo y un foro de debate sobre temas específicos
de IMS. El equipo de Open IMS Core consiguió fusionar todos los esfuerzos de
código abierto IMS preexistentes; hoy en día, varios cientos de desarrolladores
siguen las discusiones en las listas de correo del proyecto, donde habitualmente se
pueden encontrar respuestas a cualquier pregunta relacionada con IMS para la
integración de servidores de aplicaciones, problemas de enrutamiento IMS o
similares en cuestión de horas o de un día.

¿Una aplicación de referencia real?

¿Qué hace que este software sea ahora una implementación de referencia? En primer
lugar, el hecho de que el Open IMS Core esté disponible gratuitamente bajo una
licencia de código abierto ha contribuido sin duda a atraer a muchos investigadores.
Además, a las empresas con orientación comercial les gusta complementar con él
sus demostraciones para escenarios NGN. Aunque este aspecto ha contribuido sin
duda a la
128 Manual del subsistema multimedia fP (fM£)

de la distribución del software, recibimos comentarios de que la madurez del

software con respecto al cumplimiento de los estándares y el rendimiento y el apoyo
continuo de un grupo central de desarrolladores permitían que varios cientos de
personas al día visitaran los sitios web y supervisaran las listas de correo. Un
segundo aspecto importante es que, basándose en los requisitos procedentes de los
distintos socios industriales del Open IMS Playground y de los usuarios del
software, el Open IMS Core satisface muchas de las lagunas actuales que ofrecen las
especificaciones para el enrutamiento del tráfico IMS (y especialmente con respecto
a la autenticación) en los dominios de redes fijas, móviles y de cable. Por ello, con
los últimos comentarios recibidos, parece que las organizaciones de normalización
también empiezan a considerar el proyecto como una referencia y como el mejor
campo de experimentación para funciones nuevas y convergentes.
El desarrollo del Open IMS Core [8,22,23] contó con el apoyo de proyectos de
I+D financiados con fondos públicos, así como de otros proyectos de la industria.
Así pues, en esta sección trataremos de esbozar los más destacados de los que
tenemos constancia, pero sin duda hay muchos más proyectos en laboratorios o en
ordenadores de estudiantes que merecerían ser mencionados:

• Estándar de evaluación comparativa de IMS de ETSI TISPAN. Dentro del grupo

de trabajo 6 de ETSI TISPAN, el núcleo IMS abierto, desde el principio de la
estandarización de [24], sirvió como implementación de referencia para un
SuT para la evaluación comparativa de los componentes del núcleo IMS.
La norma define por primera vez la metodología, las métricas, los informes
y el proceso para encontrar y certificar el rendimiento de las redes NGN.
• Uso en escenarios de interoperabilidad NGN. Existe una clara justificación para
utilizar el software en escenarios de interoperabilidad con varios
proveedores o socios de I+D. Cualquier socio puede utilizar el software
para pruebas internas antes de acudir a un evento de interoperabilidad.
Especialmente para los eventos de interoperabilidad IMS orientados
comercialmente, hemos recibido comentarios muy positivos del personal
de laboratorio del Laboratorio de Interoperabilidad de la Universidad de
New Hampshire [25], que acoge los eventos de prueba para, por ejemplo,
el Foro IMS o el MSF presentado anteriormente. El Open IMS Core forma
parte de su configuración por defecto para redes IMS. Asimismo, el grupo
de trabajo TISPAN WG6 del ETSI confía en el Open IMS Core como una de
las soluciones a utilizar en sus IMS Plug Tests.
• Uso como núcleo para habilitar bancos de pruebas IMS y otros proyectos de
código abierto. Aunque el Open IMS Core ha permitido durante mucho
tiempo la creación de servicios y el desarrollo de componentes como
núcleo central del Open IMS Playground, no hay bancos de pruebas
puramente relacionados con IMS que puedan beneficiarse de su existencia.
Por un lado, puede servir de base para la investigación de nuevas
plataformas de prestación de servicios que funcionen según los principios
de una arquitectura orientada a servicios; por otro, puede utilizarse
estrechamente integrado con escenarios específicos de play-out de IPTV y
El FOKU£ Open fM£ Core-Una fmplementación global fM£ de referencia 129

aplicaciones para investigar y apoyar la futura distribución de medios a través

de redes centrales IMS.*

Además de apoyar la investigación interna de FOKUS, hemos recibido

comentarios muy positivos de proyectos de I+D, universidades y proveedores de
componentes IMS. Sabemos que el Open IMS Core se utiliza en algunos de
proyectos FP6 de la Unión Europea y que habilita los laboratorios NGN de muchos
departamentos de I+D de operadores (por ejemplo, Portugal Telecom Inovacao,
Orange Labs y Slovak Telekom), así como los laboratorios de pruebas IMS conjuntos de la
industria [26]. Además, hemos recibido declaraciones positivas de universidades y
centros de I+D independientes que describen el uso del Open IMS Core como parte
de sus configuraciones de laboratorio cotidianas. Otros están trabajando con él como
parte de su trabajo doctoral, construyendo temas de tesis de máster en torno a él, o
utilizándolo como parte de conferencias para ilustrar conceptos IMS y enseñar a los
estudiantes sobre tecnologías NGN. Otro efecto secundario es que el Open IMS
Core también ha impulsado el desarrollo de proyectos de código abierto en el ámbito
de los clientes IMS [27,28].
Está claro que el Open IMS Core permite hoy a distintas partes de la comunidad
investigadora de las NGN crear prototipos, medir o desarrollar en torno a él, ya sean
servicios o componentes. Aunque la mitad de los visitantes del sitio web proceden
de Europa, el interés por este software especializado es global, ya que registramos
visitas de más de 120 países. Esperamos que nuestro trabajo futuro en el software,
junto con los comentarios de los usuarios, los parches y las correcciones de errores
procedentes de esta comunidad, estimulen aún más proyectos de los que ya ha
estimulado en sus primeros meses de existencia como implementación de referencia
para los elementos centrales de IMS.

Outlook
Cuando lanzamos el proyecto Open IMS Core en noviembre de 2006, objetivo
inicial era establecer una pequeña comunidad de desarrolladores y rebajar el
escepticismo al que aún se enfrenta IMS en algunas partes del sector de VoIP.
Queríamos demostrar que IMS no es necesariamente un jardín amurallado, sino que
es y puede ser igualmente un estándar abierto para prestar servicios en NGN.
Queríamos dotar a la comunidad de I+D de una solución fácil de usar para poner en
marcha sus propios desarrollos IMS, y lo hicimos proporcionando un software que
ya había sido validado en un laboratorio de pruebas IMS multiproveedor como
software de código abierto durante varios años.
Aunque mucha gente todavía no es consciente de que existe una solución como
Open IMS Core, podemos decir que hemos logrado este objetivo y que muchas de las
partes interesadas en IMS han empezado a hacer un buen uso del software. En este
capítulo, hemos intentado esbozar algunos de los casos de uso y por qué se puede
con-

* Ambos temas son actualmente objeto de investigación en FOKUS.

130 Manual del subsistema multimedia fP (fM£)

siderar el Open IMS Core como una implementación de referencia en este . Aunque
ya estamos experimentando un buen efecto de comunidad en las listas de correo del
proyecto, con desarrolladores que se ayudan mutuamente, en los próximos meses y
años esperamos ver crecer esa comunidad, sobre todo porque sigue habiendo
necesidad de prototipos IMS y soporte de bancos de pruebas en la fase de adopción
de IMS con muchos operadores y vendedores de todo el mundo.

Referencias
1. 3GPP TS 24.228. Flujos de señalización para el control de llamadas multimedia IP basado en el
protocolo de iniciación de sesión (SIP) y el protocolo de descripción de sesión (SDP)
(versión 5).
2. FOKUS Open IMS Playground. [Link]
3. El router exprés SIP. [Link]
4. IMS Benchmarking Special Interest Group. [Link]
de/IMSBenchmarking/?lang-en
5. Licencias públicas generales GNU. [Link]
6. Rosenberg, J., H. Schulzrinne et al. 2002. SIP: Protocolo de iniciación de sesión, RFC 3261.
7. Calhoun, P., J. Loughney, E. Guttman, G. Zorn y J. Arkko. 2003. Protocolo base Diameter,
RFC 3588.
8. Weik, P., D. Vingarzan y T. Magedanz. 2005. Design and implementation of an open IMS
core. Mobility Aware Technologies and Applications, Second Inter- national Workshop,
MATA 2005, LNCS 3744, ISBN-10 3-540-29410-4. Berlín. Berlín: Springer-Verlag.
9. Rosenberg, J., 2004. A session initiation protocol (SIP) event package for regis- trations,
RFC 3680.
10. Niemi, A., J. Arkko y V. Torvinen. 2002. Hypertext transfer protocol (HTTP) digest
authentication using authentication and key agreement (AKA), RFC 3310.
11. PacketCable 2.0 PKT-SP-29.228-I02-070925. IMS delta specifications IP multime- dia (IM)
subsystem Cx and Dx interfaces: Signaling flows and message con- tents specification,
3GPP 29.228.
12. 3GPP TS 23.203. Arquitectura de control de políticas y tarificación.
13. 3GPP TS 29.228. Interfaces Cx y Dx del subsistema IP multimedia (IM): Flujos de
señalización y contenido de los mensajes.
14. ETSI TS 183 033. Protocolo basado en IP multimedia-DIAMETER para las interfaces entre
la función de control de sesión de llamada y la función de servidor de perfil de
usuario/función de localizador de suscripciones: Flujos de señalización y detalles del
protocolo.
15. Torvinen, V., J. Arkko y M. Naslund. 2005. Hypertext transfer protocol (HTTP) digest
authentication using authentication and key agreement (AKA) version-2, RFC 4169.
16. García-Martín, M., M. Belinchón, M. Pallarés-López, C. Canales-Valenzuela y K. Tammi.
2006. Diameter session initiation protocol (SIP) application, RFC 4740.
17. 3GPP TR 33.178. Aspectos de seguridad del subsistema multimedia IP temprano (IMS).
18. 3GPP TS 29.328. Interfaz Sh del subsistema multimedia IP (IM): Flujos de señalización
y contenido de los mensajes.
El FOKU£ Open fM£ Core-Una fmplementación global fM£ de referencia 131

19. 3GPP TS 29.109. Arquitectura de autenticación genérica (GAA): Interfaces Zh y Zn

basadas en el protocolo Diameter.
20. Vingarzan, D., y P. Weik. 2006. End-to-end performance of the IP multimedia subsystem
over various wireless networks. IEEE Wireless Communications and Networking Conference
2006, Las Vegas, NV, abril.
21. El proyecto FOKUS Open IMS Core. [Link]
22. Weik, P., D. Vingarzan y T. Magedanz. 2006. Towards an open source IMS core system
enabling rapid prototyping of NGN services. NGNM06 3rd Inter- national Workshop on Next-
Generation Networking Middleware, Coimbra, Portugal, 19 de mayo de 2006, 23-29, ISBN
972-95988-7-8.
23. Vingarzan, D., P. Weik y T. Magedanz. 2007. Desarrollo de un núcleo IMS de código
abierto para bancos de pruebas IMS emergentes. Número especial sobre IMS. Journal on
Mobile Multimedia (JMM) 2(3), 131-149.
24. ETSI TS 186 008. Telecommunicationsand Internet Converged Servicesand Proto- cols for
Advanced Networking (TISPAN); IMS/NGN performance benchmark.
25. Universidad de New Hampshire. Laboratorio de Interoperabilidad. [Link]
[Link]
26. IMS Advanced Research Cluster for Services. [Link]
27. El cliente UCT IMS. [Link]
28. El comunicador IMS. [Link]
6
Next-Generation Grid £upport
sobre la plataforma £fP/fM£

Vicente Olmedo, Antonio Cuevas, Víctor Villagrá y José I. Moreno

CONTENIDO
Introducción ...................................................................................................................... 134
Ventajas de la interacción Grid-IMS ...................................................................... 135
Arquitectura de un nuevo entorno Grid: Orientación comercial
con servicios dinámicos y móviles ............................................................ 136
Organización Virtual de Base ..................................................................................137
Organización virtual operativa ............................................................................. 138
Proveedor de servicios ............................................................................................. 140
Proveedor de red ..................................................................................................... 140
Integración de la infraestructura SIP de IMS y Grids: Móviles y
Entorno de red dinámico .............................................................................. 141
Protocolos implicados: SIP y SOAP ....................................................................... 141
Integración de SIP y SOAP .....................................................................................142
Soporte SIP para servicios Grid basados en SOAP ................................................144
Inicialización................................................................................................144
Configuración de sesiones con servicios que se ejecutan en MT........144
Desconexión y reconexión de terminales y sus servicios; movilidad .. 147
Desconexión accidental............................................................................... 149
Cambios en los Servicios en las Terminales Mientras se Ejecuta la
Sesión ......................................................................................... 149
Desmontaje de la sesión .............................................................................. 149
Integración de servicios Grid y llamadas de audio y vídeo controladas por SIP
.................................................................................................................................. 149
Integración de la red con la infraestructura del operador de red
Reutilización de interfaces definidas por IMS .............................................. 151
Interfaz PDF/PCRF con el proveedor de servicios Grid .....................................152
Interfaces con el FSS y el FCD para el control del usuario .............................. 154
Conclusión ..........................................................................................................................155
Referencias .........................................................................................................................155

133
134 Manual del subsistema multimedia fP (fM£)

Introducción
En un futuro próximo, los operadores de red pueden perder su posición central en la
cadena de valor del negocio de las telecomunicaciones y convertirse en meros
"tubos de bits". Por eso cobran tanta importancia las plataformas de servicios
controladas por los operadores, como i-mode o el subsistema multimedia IP (IMS).
IMS es una plataforma de servicios bien diseñada, que utiliza protocolos de Internet
abiertos y estandarizados y respeta el paradigma de Internet de transporte de datos y
separación de aplicaciones, sin dejar por ello de crear vínculos entre estas dos capas
[1].
Las plataformas de servicios deben incitar a los usuarios a , ofreciéndoles un rico
entorno de servicios. IMS es una plataforma de servicios prometedora, pero sólo se
dirige a aplicaciones proxy de sesión de iniciación estandarizada (SIP), es decir,
aplicaciones que utilizan el protocolo SIP y proxies SIP para ayudar a controlar las
sesiones entre los participantes. Un ejemplo de estas aplicaciones son las
conferencias de audio y vídeo. Estas aplicaciones peer-to-peer permiten a los
usuarios, entre otras cosas, realizar las "llamadas telefónicas tradicionales" que son,
todavía hoy, el principal negocio de los operadores de red. Sin embargo, muchas de
las aplicaciones con gran aceptación entre los usuarios no utilizan el protocolo SIP
y, por tanto, quedan fuera del ámbito del IMS. Algunos ejemplos son las descargas
de tonos de llamada, los juegos en línea y las aplicaciones para compartir
contenidos. Estas aplicaciones tienen una gran aceptación comercial y representan
una fuente de ingresos cada vez mayor para los proveedores de redes. Se están
haciendo esfuerzos para ampliar la panoplia de servicios que pueden encajar en el
marco de control IMS. El consorcio Open Service Architecture (OSA)/Parlay [2]
desarrolló y desarrolla medios para que los proveedores de servicios interactúen con
los operadores de red; integrar OSA/Parlay con IMS es uno de los principales
esfuerzos realizados para ampliar el conjunto de servicios disponibles bajo la
plataforma IMS. La Open Mobile Alliance (OMA) [3] es el principal actor en el
enriquecimiento de los servicios ofrecidos a través de la plataforma IMS.
Paralelamente al IMS, la comunidad tradicional de computación distribuida (que
finalmente evolucionó hacia la comunidad de servicios Grid/Web) ideó soluciones y
conceptos que también podían utilizarse para agrupar servicios y, en última
instancia, crear plataformas de servicios y entornos de servicios enriquecidos. Un
concepto muy importante dentro del marco Grid es el de organización virtual OV).
Una OV es una coalición temporal o permanente de individuos, grupos, unidades
organizativas u organizaciones enteras dispersas geográficamente que ponen en
común recursos, capacidades e información para contribuir a la OV de acuerdo con
los contratos establecidos. Estos contratos suelen estar impulsados por uno o varios
procesos empresariales. Las organizaciones de servicios pueden prestar servicios y,
por tanto, participar como entidades individuales en la formación de otras
organizaciones de servicios. Esto permite la creación de estructuras recursivas con
múltiples capas de proveedores de servicios de valor añadido "virtuales".
Muchos entornos Grid se crean utilizando el nivel Web Services Resource
Framework (WSRF) [4] y las capas de servicios de la Open Grid Services
Architecture (OGSA) [5]. Todos los recursos Grid, tanto lógicos como físicos, se
modelan como servicios sobre la base de implementaciones de servicios Web. Para
Next-Generation Grid £upport sobre la plataforma £fP/fM£ 135

A efectos del modelado de recursos en la Grid, las interfaces de los servicios Web
deben permitir con frecuencia la manipulación del estado, es decir, los valores de los
datos que persisten y evolucionan como resultado de las interacciones de los
servicios Web. Uno de los principales objetivos del WSRF es lograr este control de
estado. El WSRF define una familia de especificaciones para acceder a recursos con
estado mediante servicios web. Obsérvese que los servicios de comunicación (por
ejemplo, las llamadas de voz) también se describen utilizando este marco. La capa
de servicios Web, junto con el WSRF, proporciona una infraestructura de base para
la capa de servicios OGSA que proporciona la funcionalidad general de gestión de
Grid. La motivación básica es proporcionar servicios específicos de OGSA
implementados a través del WSRF.

Ventajas de la interacción Grid-IMS

Los Grids ofrecen una composición y orquestación de servicios no tan centralizada
como en el IMS, y admiten una gama de dispositivos y servicios más heterogénea
que el IMS. En los entornos Grid podríamos incluso considerar como servicios las
capacidades de un usuario (como un trabajador de primeros auxilios médicos)
conectado a su dispositivo. Sin embargo, debemos tener en cuenta que este tipo de
servicios son muy dinámicos porque los usuarios (con sus dispositivos) pueden
desplazarse, cambiar el dispositivo que emplean o simplemente "desaparecer"
(apagar el dispositivo o perder la conectividad). Este tipo de dinamismo se soporta
mejor en entornos basados en IMS y SIP que en escenarios Grid. Dar movilidad y
dinamismo a las Grids [6] es una de las razones para integrar Grids e IMS.
IMS es una plataforma de servicios muy orientada al mundo comercial, mientras
que los Grids son más débiles en este punto. La integración de Grids e IMS
proporcionará los mecanismos necesarios para orientar el mundo Grid hacia un
entorno comercial, si es necesario.
IMS establece vínculos entre la capa de aplicación y el nivel de transporte para
lograr, entre otras cosas, una calidad de servicio (QoS) integrada que coordine estas
dos capas. Esto es especialmente importante para las aplicaciones "básicas" del IMS,
como las comunicaciones de audio/vídeo entre usuarios. Las aplicaciones Grid
pueden no tener exigencias de QoS tan estrictas; por tanto, al mundo Grid no le
importa mucho coordinar la QoS ofrecida por el operador de red para su servicio de
transporte de datos y la QoS en la capa de aplicación. Así, la integración de IMS y
Grids extenderá los mecanismos de control de QoS ricos en IMS a la Grid.
En el enfoque descrito en este , gracias a su interacción dentro de la plataforma de
servicios IMS, las aplicaciones Grid (que utilizan el marco de trabajo de los
servicios Web) podrán:

• establecer una sesión Grid con un servicio móvil/ubicuo sin

conocimiento previo de su ubicación actual;
• utilizar los mecanismos SIP para gestionar sesiones, como transferir una
sesión, o realizar el control de sesiones de Grid de terceros. Esto incluye la
integración de aplicaciones ajenas a la red, como las llamadas de voz
controladas por SIP;
136 Manual del subsistema multimedia fP (fM£)

• utilizar los mecanismos de gestión de presencia y contexto establecidos por

la infraestructura SIP for Instant Messaging and Presence Leveraging
Exten- sions (SIP SIMPLE); y
• utilizar mecanismos IMS para facturar el servicio y autenticar y autorizar a
los usuarios.

La figura 6.1 muestra la arquitectura general de un entorno de servicios

compuesto por la plataforma de servicios IMS y los servicios Grid. En secciones
posteriores se detalla cómo se consigue este entorno de servicio.
Al integrar Grids e IMS, la plataforma de servicios IMS se enriquece para
construir un entorno de servicios más completo y atractivo que atraiga a los usuarios.
La integración de Grids (y, más concretamente, de servicios Web) e IMS sigue siendo
de investigación. Se han presentado soluciones, como las de la referencia 7. En este
capítulo describimos la solución aportada en el marco del proyecto Akogrimo [8].
Las siguientes secciones explican cómo se consigue esta plataforma de servicios
mejorada en el proyecto Akogrimo.

Arquitectura de un nuevo entorno Grid: Orientación comercial

con servicios dinámicos y móviles
Las Grids son una colección de dispositivos heterogéneos con diferentes capacidades
y servicios ofrecidos; están interconectados y trabajan juntos hacia un

Control de
Proveedo sesión SIP
r de Control de
contenid usuarios y
os facturación

Agencia Proveedor de red

de Descubrim
viajes iento de
servicios

Capacidades
de primeros
Alemán- auxilios
español en línea
Traducción

FIGURA 6.1
Un entorno de servicios mejorado: elementos de control de la plataforma de servicios IMS y servicios Grid.
Next-Generation Grid £upport sobre la plataforma £fP/fM£ 132

objetivo común. Este conjunto de dispositivos suele denominarse Organización Virtual.

Muchos entornos Grid se crean utilizando el nivel WSRF y la capa de servicios
OGSA. Todos los recursos Grid, tanto lógicos como físicos, se modelan como
servicios sobre la base de implementaciones de servicios Web. Los servicios web
tienen estado, y uno de los objetivos del WSRF es tenerlo en . Los servicios de
comunicación (por ejemplo, llamadas de voz) también se describen utilizando este
marco.
Las Grids suelen estar descentralizadas y se "construyen" a sí mismas y ofrecen
servicios de forma bastante dinámica. Sin embargo, normalmente no tienen una
orientación comercial, no se centran en el usuario y no tienen en cuenta que los
usuarios (conectados a sus dispositivos) pueden ofrecer servicios, como primeros
auxilios médicos. Para integrar las organizaciones Grid en el negocio de las
telecomunicaciones y apoyar los servicios ofrecidos por los usuarios, se han
identificado los siguientes bloques de construcción (Figura 6.2).

Organización virtual de base

Uno de los principales componentes de las arquitecturas Grid es la Organización
Virtual Base BVO). Esencialmente, una BVO es un conjunto de proveedores de
servicios (SP)

Base VO Dominio del cliente

Gestión de la VO
Usuario
Usua
Contabilidad y
Descubrimiento Gestor de contextos Identida
Cargando
d

Contabilidad y
Identida
Cargando OpVO
d

OpVO
Composición
Gestión

Identida
d

Proveedor de servicios
Proveedor de red

Ejecución
Red
Gestión
Gestión Servicios Servicios

Datos
Descubrimi Descubrimi
Gestión
ento
ento

Contabilidad y Contabilidad y
Identida
Cargando Cargando
Identidad d

FIGURA 6.2
Bloques de construcción de Grid que hacen posible su integración en IMS.
138 Manual del subsistema multimedia fP (fM£)

vinculadas por un contrato; para prestar servicios específicos, trabajan juntas según
los términos de este contrato recogidos en los Acuerdos de Nivel de Servicio (SLA).
Este contrato se firma y se liquida sobre una base bastante estática. Para que el
entorno Grid cumpla el modelo de negocio de "jardín semicerrado" (seguido por el
IMS), los SP que forman la BVO también deben tener una relación contractual con
el Proveedor de Red (NP). En el modelo de negocio "semiwalled garden", este
contrato establece, entre otras , que la parte principal de relación con el cliente es
gestionada por el NP.
Los contratos que vinculan a las SP entre sí dentro de la BVO y con el PN se
establecen de estática. Sin embargo, el subconjunto de elementos de la BVO que
trabajan juntos y ofrecen un servicio (facturable) a los clientes se instancian
dinámicamente, formando la VO Operativa (OpVO) que estudiaremos más adelante.
A continuación detallamos las relaciones que se establecen entre la BVO y los
demás componentes:

• El PN suministra la infraestructura de red para acceder a la BVO. La BVO

se apoya en el NP de confianza (que es miembro de la BVO) para
autenticar la identidad de las solicitudes entrantes (esencialmente
procedentes de clientes o de SP que forman la BVO).
• El cliente podrá realizar dos acciones principales dentro de una BVO:
buscar servicios y crear OpVOs (detalladas a continuación).
• El SP podrá publicar sus servicios dentro de la BVO, y su uso será
adquirido por el cliente a través de la propia BVO (mediante la
instanciación de OpVOs).
• El bloque de construcción OpVO es un componente interno de la BVO. El
BVO interactúa con el OpVO, creándolo y configurando un subdominio
dedicado para su ejecución.

La figura 6.3 representa el concepto de BVO y lo compara con la figura 6.4, que
ilustra el concepto de OpVO que explicamos en la siguiente sección.

Organización virtual operativa

El OpVO es un bloque de construcción que asume un papel importante en el
momento de la ejecución, cuando la aplicación se entrega realmente al cliente. El
OpVO es el "entorno en tiempo de ejecución" de algunos de los proveedores que
ofrecen sus servicios dentro de la BVO. En cualquier caso, el OpVO vive dentro de
un BVO y varios OpVOs pueden ser instanciados en cada BVO. El SP será
contactado por el OpVO para negociar la instanciación de los servicios necesarios
para la ejecución del entorno Grid. El éxito de esta negociación conducirá al
establecimiento dinámico de un contrato. Dado que este proceso se realiza dentro de
una BVO que
Next-Generation Grid £upport sobre la plataforma £fP/fM£ 139

Rejilla SP Rejilla SP
Rejilla
SP
Rejilla Rejilla
SP SP

Base VO

Proveedor de red

FIGURA 6.3
Una OAV y su contrato con el proveedor de red; también, los contratos del proveedor de red con los usuarios.

Rejilla Rejilla
SP Rejilla
SP SP
Rejilla Rejilla
SP SP

Base VO

Proveedor de red

FIGURA 6.4
Dos OpVOs instanciados dinámicamente dentro de un BVO.

tiene un contrato "estático" con el PN (entre otros), éste puede participar en el control
de los servicios prestados a través de una OpVO.
El cliente podrá realizar algunas acciones administrativas en el OpVO (por
ejemplo, la suscripción de nuevos usuarios) porque es el propietario de
140 Manual del subsistema multimedia fP (fM£)

la OpVO. Además, el cliente (o cualquier otro usuario delegado por el cliente)

puede utilizar (pagando por ello) las aplicaciones instanciadas a través de un OpVO.
Y lo que es más importante, los usuarios conectados a sus dispositivos pueden
ofrecer servicios y cobrar por ellos. Estos servicios existen de forma muy dinámica
porque los usuarios (con sus dispositivos) pueden mudarse, cambiar el dispositivo
que emplean, apagarlo, etc.
Por otro lado, los servicios prestados por proveedores son mucho más estables. La
existencia de OpVO permite integrar estos dos tipos de escenarios de prestación de
servicios. Dado que la OpVO es una instancia dentro de la BVO y que la BVO
mantiene relaciones con el NP siguiendo el modelo de negocio de jardín
semicerrado, es posible una facturación integrada (controlada por el NP), a pesar de
las diferencias muy grandes entre los dos tipos de OpVO.
naturaleza de los servicios (Grid y no Grid) ofrecidos en la OpVO.

Proveedor de servicios
Los servicios que gestionan y suministran recursos y aplican políticas y SLA residen
en el dominio SP. El servicio ofrecido por el SP interactuará y cooperará dentro de
la , contribuyendo a la prestación global de servicios Grid. Así, los SP deben
exponer sus servicios a la orquestación llevada a cabo dentro de la OpVO. Esto
incluye anunciar los servicios ofrecidos, registrándolos en el índice de servicio
apropiado (este servidor será un registrador SIP, la S-CSCF del IMS, como
detallaremos más adelante). Este índice de servicios también puede ser consultado por los SP
para encontrar los servicios necesarios.
Como las Grids deben integrarse en un ambiente comercial (como el IMS), una
función que soporte la contabilización de los recursos que están siendo consumidos
durante la ejecución de un servicio se encuentra en cada SP que hospeda un servicio
para la venta. Emulando el comportamiento del IMS, el SP enviará datos contables,
como mínimo, a algunos nodos especializados del PN, agregando y correlacionando
datos contables procedentes de diferentes fuentes. Todos los servicios localizados en
el dominio del SP van acompañados de un conjunto de mecanismos dirigidos a
establecer la identidad y negociar la autenticación. Dependerán, entre otros, de los
servicios de autenticación ofrecidos por el operador de la red. Nótese que los
servicios ofrecidos por los SPs se ejecutan en las OpVOs y éstas son instancias de la
BVO, que tiene contratos con el PN. Estos permiten a los PS utilizar los servicios de
contabilidad, tarificación y autenticación ofrecidos por el PN.

Proveedor de red
Todas las funciones representadas relacionadas, necesarias para proporcionar
servicios de red de una manera compatible con Grid, residen en el dominio NP,
creando así un nuevo entorno en el que los Grids se encuentran con el modelo de
negocio de jardín semicerrado. Las actividades de contabilidad y tarificación
disponibles en este dominio también están preparadas para contabilizar y tarificar
los servicios Grid, lo que finalmente hace que el dominio de red esté básicamente
preparado para desplegar comercialmente servicios Grid en su infraestructura.
Además, los elementos NP gestionan la identidad de los usuarios, autenti-
Next-Generation Grid £upport sobre la plataforma £fP/fM£ 141

y proporcionar este servicio de autenticación a la BVO (y, por tanto, a las OpVO y
SP).

Integración de la infraestructura SIP de IMS y las

Grids: Entorno de Grid Móvil y Dinámico
Protocolos implicados: SIP y SOAP
El SIP [9] es un protocolo orientado al establecimiento, modificación y terminación
de sesiones. En el contexto de SIP, una sesión se entiende como una asociación
creada entre dos o más participantes para intercambiar algún tipo de datos. La
especificación de SIP sólo define los mensajes de señalización y el funcionamiento
del protocolo, desvinculándolo del tipo real de datos que se intercambiarán una vez
que se haya establecido con éxito una sesión. Además, los parámetros que
caracterizan la sesión a negociar por los participantes durante el establecimiento de
la sesión se describen mediante el Protocolo de Descripción de Sesión (SDP) [10],
que se transporta como carga útil en los mensajes SIP (Figura 6.5). A pesar de este
desacoplamiento, SIP se ha utilizado tradicionalmente para gestionar sesiones
multimedia, como las llamadas telefónicas de voz sobre IP (VoIP). Además, las
descripciones SDP disponibles se refieren principalmente a este tipo de sesiones
multimedia y describen, por ejemplo, los códecs multimedia que deben emplearse en
las sesiones.
Teniendo en cuenta que está concebido para soportar todo tipo de aplicaciones,
SIP ha sido diseñado por el IETF para ser utilizado como marco de señalización en
redes IP. Gracias a su inclusión en el IMS, SIP es actualmente la norma de facto
para la señalización en redes de próxima generación.
La funcionalidad SIP la hace especialmente útil en entornos móviles y ubicuos.
En estos entornos, los usuarios pueden desplazarse y cambiar el terminal que
utilizan para acceder a los servicios. La infraestructura SIP rastrea a cada usuario
para mantener actualizada la información sobre su ubicación (lógica).
El protocolo de señalización clave para Grids y organizaciones virtuales es el
SOAP [11]. SOAP es un protocolo ligero basado en mensajes para el intercambio de
información estructurada en un entorno descentralizado y distribuido a través de una
red.

GenericApplication GenericApplication

SIP_session_setup_negotiation
Application_typically_multimedia_(RTP/RTCP)_but_can_be_any
SIP_session_teardown

FIGURA 6.5
El SIP está desacoplado de la aplicación.
142 Manual del subsistema multimedia fP (fM£)

variedad de protocolos subyacentes. SOAP permite la vinculación y el uso de

servicios Web no cubiertos mediante la definición de una ruta de mensajes para el
enrutamiento de mensajes. En este consideramos los servicios Grid SOAP con
estado (habilitados por WSRF) y con sesión. Para la integración de SIP-IMS y
servicios Grid sin estado, el lector puede consultar la referencia 7.

Integración de SIP y SOAP

Como ya hemos comentado, hacer que las Grids sean móviles y dinámicas supone
una gran ventaja. Sin embargo, el protocolo SOAP utilizado por los servicios Web
(el marco utilizado por Grids) no está tan bien preparado para ello como lo está SIP.
Además, uno de los objetivos es implicar a los usuarios (conectados a sus
dispositivos) en la prestación de servicios (como la prestación de primeros auxilios
médicos durante una catástrofe) e integrar las comunicaciones de usuario a usuario
controladas por SIP. Por eso, lo mejor es mantener SIP e integrar . Gracias a la
interacción SIP-SOAP, la información SIP, como la ubicación actual, así como las
notificaciones sobre el estado de los servicios móviles que están ejecutando los
usuarios previamente registrados en el servidor SIP, se propagan a la capa Grid y
viceversa. De este , la capa Grid puede hacer un seguimiento de los usuarios móviles
y reajustarse a los cambios sobre la marcha. La interacción SIP-SOAP puede
implementarse de dos maneras:

• Las aplicaciones Grid pueden disponer una interfaz de programación de

aplicaciones API) SIP. Estas aplicaciones emitirán entonces mensajes de
señalización SIP directamente a las entidades SIP apropiadas; es decir, se
integra un agente de usuario SIP (SIP UA) en la aplicación Grid. Una vez
establecida la sesión mediante SIP, se utilizarán mensajes SOAP durante la
sesión. Esto es como funcionan otras aplicaciones (como VoIP) que
utilizan SIP. Este enfoque es el más limpio en términos de arquitectura,
pero implica la modificación de las aplicaciones Grid para que interactúen
directamente con la infraestructura SIP, en lugar de utilizar mensajes
SOAP.
• Se proporcionarán algunas entidades intermedias que serán invocadas,
mediante SOAP, por las aplicaciones Grid. Estas entidades emitirán los
métodos SIP necesarios (REGISTER, INVITE, BYE, ...) en nombre de las
aplicaciones Grid, e incluso establecerán sesiones Grid en nombre. Este
enfoque facilitará la implementación de las aplicaciones Grid porque
utilizarán mensajes SOAP normales (dirigidos a las entidades intermedias)
incluso para los métodos relacionados con SIP.

Dado que SIP se utiliza para negociar la configuración de sesiones Grid de

servicios Web, el lenguaje que describe los parámetros a negociar (SDP) debe
adaptarse a este tipo de aplicaciones. SDP (al igual que SIP) se diseñó para permitir
la definición de cualquier tipo de sesión (aunque el uso más común son las
comunicaciones multimedia) mediante mecanismos de extensión estandarizados, por
lo que no es necesario ningún esfuerzo de adaptación especial para describir
sesiones Grid utilizando SDP. Podemos llamar a esta , para facilitar su comprensión,
"sesiones Grid".
Next-Generation Grid £upport sobre la plataforma £fP/fM£ 143

sion description". Uno de los principales parámetros a negociar (descrito en la de la

sesión Grid) es el Lenguaje de Descripción de Servicios Web (WSDL)
[12] que describe cada servicio implicado. WSDL se utiliza para describir los
métodos que ofrece un servicio determinado. Los archivos WSDL también
contienen el End Point Reference (EPR) del servicio (es decir, dónde se puede
localizar el servicio para consumirlo). Tras la negociación del establecimiento de la
sesión, los participantes en la sesión Grid conocerán los métodos públicos y las EPR
de todos los demás servicios que utilicen en la sesión. Para permitir esta interacción,
se define un nuevo atributo SDP (el atributo "WSDL") [13]. Este atributo contiene la
URL donde se puede recuperar el archivo WSDL del servicio. Más adelante
detallaremos esta negociación.
Desde el punto de vista de la prestación de servicios, es necesario proporcionar
una interfaz a las aplicaciones Grid para los siguientes métodos:

• En la fase de arranque, los servicios móviles/ubicuos se asociarán a un

determinado Identificador Uniforme de Recursos SIP (SIP URI), que se
habrá registrado previamente en el registrador SIP (la S-CSCF) con el
método SIP REGISTER. Este SIP URI puede ser simplemente el URI del
usuario conectado al Terminal Móvil (MT) donde se están ejecutando los
servicios o un URI especial que represente los servicios. En cualquier caso,
en contexto de las sinergias SIP-SOAP, a partir de ahora nos referiremos a
ella como "URI de servicio".
• Las aplicaciones Grid, en lugar de utilizar EPRs, como se indica en el
direccionamiento de servicios Web [4] para identificar recursos, deben
utilizar en la fase de establecimiento URIs SIP para identificar servicios
móviles/ ubicuos (los EPRs no son adecuados para identificar recursos que
cambian frecuentemente en entornos ubicuos), de forma que enviarán un
SIP INVITE al URI del servicio. Este mensaje SIP INVITE contendrá
valores especiales en su carga útil SDP para que el destinatario del mensaje
INVITE lo identifique como una descripción de sesión Grid.
• En la respuesta SIP, de nuevo mediante una descripción de sesión Grid
basada en SDP, la aplicación Grid obtendrá la información de sesión Grid
necesaria para iniciar las invocaciones Grid (es decir, el archivo WSDL que
describe el servicio y su EPR).

Además, las aplicaciones Grid podrían incluir la lógica adecuada para

• utilizar otras funciones de gestión de sesiones proporcionadas por SIP,

como guardar/cargar/restaurar sesiones, útiles también para la transferencia
de sesiones. Ya existen algunas propuestas para esta función (continuidad
de servicios web), como el enfoque presentado en la referencia 14; y
• reaccionar a los cambios de contexto que se notifican con SIP.

La siguiente sección describe de forma general cómo funciona la solución. Esta

descripción puede aplicarse a cualquiera de las opciones enumeradas anteriormente
para conseguir
144 Manual del subsistema multimedia fP (fM£)

Interacción SIP-SOAP: parchear las aplicaciones Grid para que empleen una API
SIP o utilizar entidades intermediarias. Para mostrar ambas soluciones (que son
conceptualmente similares), suponemos que las aplicaciones Grid en las MT han
sido parcheadas para utilizar SIP y que las aplicaciones Grid en los proveedores de
servicios emplean una entidad intermediaria ubicada en un nodo independiente, el
broker SIP-SOAP. El broker SIP-SOAP puede considerarse como un AS IMS
(servidor de aplicaciones) que ofrece una interfaz WS-SOAP de servicios Web a las
aplicaciones Grid en el SP y una interfaz SIP a la infraestructura SIP IMS (la [S-
CSCF]). Por razones de legibilidad, consideramos que los MT envían/reciben sus
mensajes SIP directamente a/desde la S-CSCF; en realidad, en el IMS, estos
mensajes primero tra- ven la Función de Control del Estado de Llamada Proxy (P-CSCF),
que es el punto de contacto de los terminales para los mensajes SIP.

Soporte SIP para servicios Grid basados en SOAP

Inicialización
Durante la puesta en marcha de las MT, los servicios Grid y el SIP UA que actuarán
en nombre de los servicios Grid que se ejecutan en el terminal se inician siguiendo
la secuencia descrita (Figura 6.6; parte derecha de la imagen). El arranque de la UA
SIP implica un registro SIP y una publicación de presencia SIP, con el fin de hacer
visible la MT para otros servicios Grid que pudieran estar interesados en las
aplicaciones Grid que se ejecutan en ella. Una vez iniciada la UA SIP, la MT estará
lista para proporcionar información sobre los servicios Grid que se ejecuten en ella.
El URI de servicio que se utilizará será el URI SIP utilizado durante el registro SIP.
El SP también debe registrarse, pero hay que tener en cuenta que si bien los
servicios Grid ofrecidos por los usuarios conectados a sus dispositivos se encuentran
en un entorno extremadamente dinámico (los usuarios se mueven, cambian de
terminal, se desconectan, etc.), los servicios ofrecidos en los proveedores de
servicios Grid son mucho más estáticos.
Tras la inicialización, los servicios Grid estarán listos para recibir notificaciones
WSRF.

Configuración de sesiones con servicios que se ejecutan en MT

EPR es la forma en que Grid y SOAP hacen referencia a los servicios; en SIP se
hace mediante URI. Los servicios (Grid o no) ofrecidos dentro de la plataforma de
servicios IMS se indexan en el registrador SIP, un módulo de la S-CSCF de IMS.
El principal resultado de la negociación de establecimiento de sesión, realizada
mediante SIP y SDP, entre nodos Grid-SOAP es que los participantes en la sesión
conocerán los EPR de los servicios que están utilizando en esta sesión, así como sus
interfaces públicas. La figura 6.7 ilustra esta configuración de sesión.

• Cuando el Grid SP necesita conocer el EPR de un servicio que se ejecuta

en una MT, indica en qué servicio está interesado (ServiceID) y el SIP URI
que está utilizando la MT en la que se espera el servicio
 Next-Generation Grid £upport sobre la plataforma £fP/fM£
S-CSCF

GRID_SP SIP-SOAP_AS Agente de presencia SIP Registrador SIP Término SIP_UA GRID_Apli_Term

WS_SUBSCRIBE_SOAP()

REGISTRAR_SIP(URI)

PUBLISH_SIP(Estado)

WS_SUBSCRIBE_API()

REGISTRAR_SIP(URI)

PUBLISH_SIP(Estado)

FIGURA 6.6
Registro de servicios Grid en la S-CSCF.

145
 146
S-CSCF

GRID_SP Agente de presencia SIP SIP_Proxy Término SIP_UA GRID_Apli_Term

WS_getConnectionDetails_SOAP(ServiceID, URI)
INVITE_SIP()

INVITE_SIP()

WS_getConnectionDetails_API()

WS_getConnectionDetailsReturn_API(WSDL_URL)

200-OK_SIP()

200-OK_SIP()

ACK_SIP()

Manual del subsistema multimedia fP (fM£)

WS_getConnectionDetailsReturn_SOAP(WSDL_URL) ACK_SIP()

SUBSCRIBE_SIP(URI)

NOTIFY_SIP(Estado)

WS_invokeService_SOAP(EPR, método) WS_invokeServiceReturn_SOAP(Resultado)

FIGURA 6.7
Establecimiento de sesiones Grid basadas en SIP e invocación de servicios.
Next-Generation Grid £upport sobre la plataforma £fP/fM£ 142

en ejecución. El Grid SP también puede solicitar todos los servicios que se

ejecutan en un terminal determinado.
• El SIP-SOAP AS inicia una configuración de sesión de Grid con la MT
requerida. Finalmente, la información requerida (WSDL_URL) se
devuelve al Grid SP. Esta información es utilizada por el Grid SP para
recuperar el archivo WSDL que describe el servicio, utilizando HTTP o
cualquier otro mecanismo regular (esta interacción no se representa en la
figura).
• En este punto, el Grid SP conoce el EPR que debe utilizar para invocar el
servicio o servicios que le interesan.
• Adicionalmente, el SIP-SOAP AS realiza una suscripción a la información
de presencia SIP del servicio SIP URI; de esta forma, conocerá el estado de
disponibilidad de todo el terminal y podrá informar de los cambios al Grid
SP. Nótese que el terminal también puede estar interesado en conocer el
estado de los servicios ofrecidos en el Grid SP, pero el estado del Grid SP
es muy estático comparado con los servicios ofrecidos por el terminal. Por
ello, el Grid SP se suscribe al estado del terminal pero no ocurre lo
contrario.

Desconexión y reconexión de terminales y sus

servicios; movilidad
Dado que el SIP-SOAP AS conoce el estado del terminal, puede utilizar esta
información, por ejemplo, para informar al Grid SP si el usuario se desconecta de
una ubicación y luego se conecta desde otra distinta o con un terminal diferente (o si
el usuario simplemente se desconecta) [6]. Usando esta característica, el Grid SP
puede tomar una apropiada, como seleccionar diferentes servicios o refrescar la
información en la nueva localización del servicio. Este es el comportamiento
descrito en la Figura 6.8.
En primer lugar, se produce una desconexión controlada del terminal 1. Desde el
punto de vista de los servicios de soporte basados en SIP, los pasos más relevantes
son:

• El AS SIP-SOAP informa al SP de Grid sobre la finalización de la de Grid basada

en SIP mediante el mensaje SOAP WS_NOTIFY notification, indicando que
todos los servicios que se ejecutan en la MT dejan de estar disponibles.
• El agente de presencia informa de los cambios en el estado de presencia
mientras permanece activa la suscripción de presencia realizada por el AS
SIP-SOAP durante la fase de configuración de la sesión Grid.

A continuación, el URI de servicio se utiliza para conectarse de nuevo desde otra

ubicación. Gracias a la suscripción de presencia activa, el AS SIP-SOAP detecta que
el estado de presencia del URI de servicio asociado vuelve a estar en línea y puede
informar de ello al SP de Grid. Normalmente, el Grid SP volverá a solicitar los
detalles del servicio en la nueva , estableciendo una nueva sesión Grid como vimos
en la sección anterior.
 148
S-CSCF Terminal1 Terminal2

GRID_SP SIP-SOAP_AS Agente de presencia Registrador SIP_Proxy Término SIP_UA GRID_Apli_Term SIP_UA_Term2 GRID_Apli_Term2
SIP SIP

WS_NOTIFY_API(EstadoServicio)

BYE_SIP()

BYE_SIP()
WS_NOTIFY_SOAP(EstadoServicio)

200_OK

Manual del subsistema multimedia fP (fM£)

200_OK
UNPUBLISH_SIP()

NOTIFY_SIP(Estado) DESREGISTRAR_SIP(URI)

WS_SUBSCRIBE_API()
REGISTRAR_SIP(URI)
PUBLISH_SIP(Estado)

NOTIFY_SIP(Estado)
WS_NOTIFY_SOAP(EstadoServicio)

FIGURA 6.8
Desconexión y reconexión del usuario desde otro lugar.
Next-Generation Grid £upport sobre la plataforma £fP/fM£ 149

Desconexión accidental
En el caso de una desconexión accidental, el Grid SP será consciente de esta situación
porque el SIP-SOAP AS recibirá una notificación de presencia SIP indicando que el
estado de presencia del URI de servicio ha expirado. Este evento se interpretará
como una desconexión accidental y el Grid SP será informado de la indisponibilidad
de los servicios completos en el URI correspondiente.

Cambios en los servicios de los terminales mientras se ejecuta la sesión

La sesión SIP establecida se utilizará como mecanismo principal para informar al Grid SP
de los cambios en la disponibilidad de los servicios grid o EPR de la MT. Así, si
cambia la información relacionada con algún servicio, la UA SIP de la MT enviará
una reINVITE que contenga la nueva descripción de la sesión Grid. El Grid SP será
informado de ello a través de un mensaje WS_NOTIFY_SOAP, cuyo contenido
indica un cambio en los servicios. Esta secuencia se muestra en la Figura 6.9.

Desglose de la sesión
Cuando los servicios que se ejecutan en determinados MT ya no son necesarios, el Grid SP
puede finalizar una sesión SIP Grid existente. En este , también finaliza la suscripción
de presencia SIP del Grid SP para conocer el estado del terminal.

Integración de servicios Grid y llamadas de audio y vídeo controladas por SIP

Para que un tercero establezca una sesión SIP (normalmente una llamada de voz)
entre otras dos partes, existen dos opciones: control de llamada de terceros (3PCC;
descrito en la referencia 15) o utilizar el método SIP REFER. En esta sección nos
centraremos en este último método (Figura 6.10).

S-CSCF

GRID_SP SIP-SOAP_AS SIP_Proxy Término SIP_UA GRID_Apli_Term

WS_NOTIFY_API(EstadoServicio)

INVITE_SIP()
INVITE_SIP()
200-OK_SIP()

200-OK_SIP()
ACK_SIP()
ACK_SIP()
WS_NOTIFY_SOAP(EstadoServicio)

FIGURA 6.9
Cambio en los servicios.
 150
S-CSCF Terminal 1 Terminal 2

GRID_SP SIP-SOAP_AS SIP_Presence-Agent SIP_Registrar SIP_Proxy SIP_UA_Term 1 VoIP 1 SIP_UA_Término 2 VoIP_2

WS_getConnectionDetails_SOAP(URI_1, URI_2)
REFER(INVITA_2)

REFER(INVITA_2)
202-AC_SIP()

202-AC_SIP() INVITE_SIP()

Manual del subsistema multimedia fP (fM£)

200-OK_SIP() ACK_SIP()
NOTIFY_SIP(Estado) AudioVideo-flows_RTP/RTCP()

AudioVideo-flows_RTP/RTCP()
NOTIFY_SIP(Estado)

WS_getConnectionDetailsReturn_SOAP(Éxito)

FIGURA 6.10
Llamadas iniciadas por la red mediante REFER.
Next-Generation Grid £upport sobre la plataforma £fP/fM£ 151

Como parte de la ejecución orquestada de varios servicios dentro de un entorno

Grid, puede ser necesaria una llamada entre dos terminales. Sin embargo, esta
llamada de voz no es un servicio Grid Web sino, más bien, una aplicación
multimedia que utiliza el Protocolo de Transporte en Tiempo Real (RTP)/Protocolo
de Control de Transferencia en Tiempo Real (RTCP) y no el protocolo SOAP. La
solución para integrar esta llamada en el entorno de servicios Grid se describe a
continuación:

• Durante la ejecución de un servicio Grid, una aplicación Grid en el SP

puede recibir la consulta para poner en contacto a los usuarios 1 y 2.
• Tras solicitar los URI SIP de los usuarios implicados, envía un mensaje SIP
REFER al usuario 1 a través de la S-CSCF, indicando que debe iniciarse
una sesión con el usuario 2.
• La S-CSCF redirige la REFER a la MT o MTs donde el usuario 1 ha
iniciado sesión.
• Si el establecimiento de sesión es aceptado en la MT del usuario 1, ésta envía una
respuesta "202 Accepted" e inicia un proceso estándar de establecimiento de
sesión con la MT del usuario 2. Nótese que los mensajes SIP seguirán la
ruta "usuario 1→ P-CSCF S-CSCF P-CSCF→ →→ usuario 2"; para facilitar
la lectura, dibujamos los mensajes SIP como si fueran directamente del usuario
1 al usuario 2.
• El Grid SP es informado del progreso de la sesión a través de mensajes
NOTIFY porque el método REFER crea una subscripción implícita al
estado de los usuarios 1 y 2.
• Cuando el Grid SP es informado del éxito del establecimiento de la sesión,
el proceso finaliza.

Integración de Grid con la infraestructura del operador

de red Reutilización de interfaces definidas por IMS
grandes rasgos, las Funciones de Control de Estado de Llamada IMS (CSCF) son
proxies SIP avanzados que controlan las sesiones de aplicación entre diferentes
entidades. Dichas entidades utilizan SIP para establecer sus sesiones e implican a las
CSCF del IMS en esta configuración de sesión. Una de las características más
destacadas del IMS es que define interfaces entre las CSCF y algunos nodos de la
red del Sistema Uni- versal de Telecomunicaciones Móviles (UMTS).
La primera interfaz que consideramos está relacionada con el control de usuarios.
El sistema de abonado doméstico (HSS) de UMTS realiza el control y la
autenticación del usuario; IMS define una interfaz entre las CSCF y el HSS para que
las CSCF puedan delegar el control del usuario al HSS del operador. Del mismo
modo, la función de pasarela de cobro (CGF) es un nodo del operador de red que
realiza la contabilidad de los recursos de la red (por ejemplo, los bytes enviados por
el usuario). El IMS define otra interfaz entre las CSCF y la CGF. Las CSCF del IMS
enviarán al CGF
152 Manual del subsistema multimedia fP (fM£)

datos contables relacionados con las sesiones SIP que controlan las CSCF. Estos
datos pueden incluir, por ejemplo, el tipo de llamada entre los usuarios (audio o
audio/vídeo). Así, CGF recibe datos de contabilidad de diferentes fuentes y de
diferentes niveles (por ejemplo, bytes enviados/recibidos y tipo de llamada entre los
usuarios [audio o audio/video]). CGF es capaz de correlacionar estos dos niveles y
producir una facturación agregada. La última interfaz que consideramos es la
definida entre las CSCF, que saben, por ejemplo, que los usuarios emplearán un
códec que requiere 16 kbps para su llamada de voz, y los nodos de red que
transportarán esta llamada de voz. Gracias a esta interfaz, los nodos de la red se
adaptarán para dar cabida a esta llamada de voz.
Los Grid SPs dentro de la BVO (y por tanto con acuerdos con el PN) podrán
emplear estas tres interfaces mencionadas (con mínimas modifi- caciones); ver
Figura 6.11. Esto se hará cuando se instancie una OpVO dentro de la BVO y se
necesiten los servicios de un proveedor de servicios dentro de este entorno Grid (la
OpVO).
En las próximas secciones detallaremos las tres interfaces mencionadas. Debemos
subrayar que, dado que el soporte SIP está incluido en el entorno Grid y, como tal,
éste utiliza las CSCF IMS, dichas CSCF pueden abordar los tres aspectos antes
mencionados directamente, como en las soluciones IMS puras. El enfoque en el que
el propio entorno Grid se ocupa de estos aspectos utilizando las tres interfaces
mencionadas agilizará el proceso de prestación de servicios Grid.

Interfaz PDF/PCRF con el proveedor de servicios Grid

Las CSCF de IMS interactúan con la Policy and Charging Enforcement Function
(PCEF) de la red (routers o, en redes UMTS, el Gateway General Packet

Servicio
Sesiones SIP de los servicios
Proveedo IMS
r Controlar CSCFs

Reutilizar estos
protocolos Abierto, normalizado
para interactuar con los "Protocolos de
proveedores de "Internet

UMTS. Transporte de datos

HSS, Control. Control de usuarios
CGF, (autenticación, autorización,
... contabilidad)

Servicios a los
usuarios (p. ej,
Capacidades de

FIGURA 6.11
Reutilización de las interfaces CSCF de IMS con los nodos de red UMTS. Los SP acceden a los nodos de red.
Next-Generation Grid £upport sobre la plataforma £fP/fM£ 153

Radio Service [GPRS] Support Node [GGSN]) a través de la Policy and Charging
Rules Function (PCRF; Policy Decision Function [PDF] en versiones anteriores de IMS).
Planeamos reutilizar la interfaz CSCF a PCRF para la interacción entre los Grid SPs
y la PCRF. Los Grid SPs emplean el protocolo SOAP, y la interfaz mencionada se basa
en el protocolo DIAMETER. Al igual que la interacción SIP-SOAP explicada en
secciones anteriores, surgen dos posibilidades (ilustradas en la Figura 6.12) para
hacer que SOAP y DIAMETER cooperen:

• Se proporciona una API a los Grid SPs y su código se parchea para utilizar
esta API. Cuando se va a una sesión Grid, mediante una llamada a esta , se
envía un mensaje DIAMETER a la PCRF para permitir, posteriormente,
que el usuario realice reservas de recursos de transporte para acomodar los
flujos de la sesión Grid.
• Se desarrolla un módulo independiente con una interfaz SOAP para los
Grid SPs y una interfaz DIAMETER para el PDF del IMS. Este módulo
expone parte de la funcionalidad del PDF como un servicio Grid (un
servicio Web, en realidad), listo para ser utilizado por los Grid SPs.
Cuando necesiten autorizar el uso de recursos de red para un servicio Grid
posterior, emitirán una solicitud SOAP a este módulo independiente.

CSCFs
PDF/PCRF

DIÁMETRO
IMS Red

Proveedor de servicios de red

Parcheado con API para
interactuar con PDF PCEF
(Router/GGSN)

Módulo Exponer PDF

Funcionalidad como
servicio web CSCFs
PDF/PCRF

SOAP IMS Red

Servicio de DIÁMETRO
red
Proveedor
PCEF
(Router/GGSN)

FIGURA 6.12
Posibilidades de un servicio Grid Web para realizar reservas de recursos en IMS.
154 Manual del subsistema multimedia fP (fM£)

Este módulo traducirá esta petición a un mensaje DIAMETER enviado a

la PCRF del IMS.

Dado que se ha incluido soporte SIP en el entorno Grid, los proxies IMS SIP, en
particular la P-CSCF, pueden encargarse directamente de esta autorización de
recursos transfronterizos. Además, como la P-CSCF puede estar ubicada en el
dominio visitado, se resuelven los problemas de itinerancia. Sin embargo, el método
anterior agilizará el proceso de creación de sesiones Grid y, además, dejará más
control a los nodos Grid sobre los recursos de transporte necesarios. Teniendo en
cuenta que el entorno Grid es especialmente dinámico (debido a los terminales
móviles), esto es de gran importancia.

Interfaces con el FSS y el FCD para el control de usuarios

En esta sección detallamos los aspectos relacionados con el control de usuarios
(autenticación, auto- rización, contabilidad-AAA). Cada SP dispone de un servidor
de contabilidad que recoge los datos contables. Con estos datos, el servidor creará
registros contables; el protocolo más común para transmitir estos registros es
DIAMETER, que también se utiliza en IMS para estos fines. El Grid SP puede
enviar sus registros contables a la Charging Data Function (CDF) del IMS; como en
las sesiones IMS normales, la CDF enviará la información contable a la CGF del
operador, que agregará esta información contable (a nivel de aplicación) con la
información contable a nivel de red (por ejemplo, bytes enviados). Sin embargo,
para no sobrecargar el CDF con datos procedentes de todos los proveedores de
servicios, en cada BVO debe haber un nodo de contabilidad intermedio. Éste
recogerá la información contable de los proveedores de servicios de la Grid y la
enviará, agregada, al CDF, tal y como se ilustra en la Figura 6.13.
Debido a que los Grid SPs interactúan, usando SIP, con la S-CSCF (como vimos
en secciones anteriores), la S-CSCF también podría ser la encargada de enviar estos
datos contables a la CDF, como se hace en escenarios IMS regulares. Es más, si
utilizamos un AS para conseguir la interacción SOAP (protocolo utilizado por los
Grid SPs) con SIP, podría ser que este AS fuera el que enviara los datos contables a

Contabilidad
Módulo de recogida FCD CSCFs

DIÁMETRO
IMS Red
DIÁMETRO

Servicio de
red
Proveedor CGF

FIGURA 6.13
Contabilización de servicios Grid Web en IMS.
Next-Generation Grid £upport sobre la plataforma £fP/fM£ 155

el CDF. Aunque esto no requeriría más cambios, puede sobrecargar el SGI más que
el enfoque anterior.
Con respecto a la autenticación y autorización de usuarios, existen las mismas dos
posibilidades:

• Los SP de red contactan directamente con el HSS del operador de red.

• Dado que la Grid tiene soporte SIP, este contacto puede ser realizado por la S-
CSCF del IMS.

Conclusión
IMS es una plataforma de servicios bien diseñada que otorga al operador de red el
papel de intermediario de servicios. Las llamadas multimedia son un servicio
inherente al IMS, pero deberían desarrollarse muchos más servicios sobre la
plataforma de servicios IMS para construir un entorno de servicios rico que atraiga a
los usuarios. La integración del entorno de servicios Grid/Web en el IMS ampliará
las posibilidades de ofrecer una rica cartera de servicios en el IMS.
Sin embargo, esta integración no es trivial porque el protocolo de control de sesión
IMS es SIP, y los servicios Grid/Web emplean SOAP. Además, las Grids nunca se
han inclinado hacia un mundo comercial. En este capítulo presentamos cómo hacer
posible esta integración y las ventajas que aportará. Este es uno de los múltiples
pasos para construir un rico entorno de servicios basado en el IMS.

Referencias
1. Cuevas, A. et al. 2006. La plataforma de servicios IMS, clave para que los operadores de
redes de próxima generación sean algo más que tuberías de bits. IEEE Communications
Magazine 44(8), 75-81.
2. El Grupo Parlay. [Link]
3. Abierto Móvil Alianza. [Link]
4. Alianza Globus. El marco de recursos WS. [Link]
5. Alianza Globus. OGSA-The open grid services architecture. [Link]
[Link]/ogsa/
6. Waldburger, M. et al. 2006. Hacia la Grid móvil: Service provisioning in a mobile
dynamic virtual organization. 4th ACS/IEEE International Conference on Computer Systems and
Applications (AICCSA-06), Dubai, EAU, marzo.
7. Levenshteyn, R. et al. Mobile services interworking for IMS and XML Web ser- vices. 2006.
IEEE Communications Magazine 44(9), 80-87.
8. El proyecto Akogrimo. [Link]
9. Rosenberg, J. et al. 2002. SIP: Protocolo de iniciación de sesión, IETF RFC 3261.
10. Handley, M. et al. 2006. SDP: Protocolo de descripción de sesión, IETF RFC 4566.
156 Manual del subsistema multimedia fP (fM£)

11. Consorcio World Wide Web (W3C). Especificaciones SOAP. [Link]

[Link]/TR/soap/
12. Consorcio World Wide Web (W3C). Lenguaje de descripción de servicios web (WSDL).
[Link]
13. Olmedo, V. et al. 2007. Atributo WSDL del Protocolo de Descripción de Sesión (SDP).
Borrador de Internet del IETF (trabajo en curso).
14. Dorn, C., y S. Dustdar. 2006. Continuidad de los servicios web en redes móviles ubicuas:
The SRR-WS framework. 4th International Workshop on Ubiq- uitous Mobile Information
and Collaboration Systems (UMICS), co-located with CAiSE 2006, 5-6 de junio.
15. Rosenberg, J. et al. 2004. Best current practices for third-party call control (3pcc) in the
session initiation protocol (SIP), IETF RFC 3725.
7
Control de calidad basado en
políticas para una red de
convergencia

Younghan Kim y Youngsuk Lee

CONTENIDO
Introducción ....................................................................................................................... 157
Planteamiento de problemas ............................................................................................ 159
Régimen propuesto ............................................................................................................. 160
Cabecera IPFIX ......................................................................................................... 161
Funcionamiento de IPFIX .......................................................................................... 161
Aplicación y resultados de la demostración .................................................................. 163
Implantación de IMS y DiffServ Core Network................................................. 163
Demostración y resultados experimentales ......................................................... 166
Conclusión ........................................................................................................................... 167
Referencias .......................................................................................................................... 168

Introducción
La red celular e Internet han sido los paradigmas de red más exitosos de las últimas .
El subsistema multimedia IP (IMS) [1] es uno de los mayores esfuerzos por
combinar ambas redes. La red celular, por un lado, permite a los usuarios disponer
de ubicua gracias a su carácter inalámbrico y móvil. En Internet, por otro lado, ya
existen inmensos y útiles servicios o aplicaciones que impregnan la vida cotidiana
de un gran número de usuarios y que crecen rápidamente el del tiempo. En
particular, los servicios multimedia aceleran este fenómeno. En ambas redes, por
tanto, dar soporte a la calidad de servicio (QoS) es el requisito clave tanto del
usuario como del proveedor de servicios.
El soporte de la calidad de servicio para los servicios multimedia presenta varias
limitaciones. Entre ellas se encuentran las dificultades para controlar (o reservar)
recursos desde un origen a un destino, diseñar un aprovisionamiento de QoS
aceptable, identificar

157
158 Manual del subsistema multimedia fP (fM£)

sesiones (o clases) reservadas, y otros. Para resolver estas limitaciones, el Proyecto de

Asociación de Tercera Generación (3GPP) y el Instituto Europeo de Normas de
Telecomunicaciones (ETSI) han diseñado el IMS como plataforma de servicios [2].
En el IMS, las sesiones multimedia son gestionadas por un conjunto de elementos de
red diseñados originalmente para soportar servicios multimedia IP en la red
alámbrica del sistema universal de telecomunicaciones móviles (UMTS) [3]. Sin
embargo, la versión actual de la norma (es decir, la versión 7) amplía la capacidad
para soportar servicios multimedia tanto en redes cableadas como inalámbricas. En
concreto, la red de próxima generación (NGN) ha adoptado el IMS como función
central para el control de sesiones. Dos elementos clave del IMS considerados en
este capítulo son SIP (protocolo de iniciación de sesión) [4] y PDP (protocolo de
paquetes de datos) [5].
SIP establece una sesión y PDP se utiliza para la reserva de recursos con el fin de
apoyar la QoS después de que la PDF (función de decisión de políticas) tome la
decisión sobre el recurso necesario. Por lo tanto, un usuario de servicios multimedia
reside necesariamente en una red UMTS y los dos protocolos son necesarios. Sin
embargo, para satisfacer las futuras demandas de las NGN, es muy recomendable
que el IMS sea capaz de interoperar entre redes de acceso heterogéneas. Es decir, las
funcionalidades para soportar la QoS deben tener en cuenta no sólo la red
inalámbrica UMTS, sino también varias redes cableadas e inalámbricas. Suponemos
un escenario sencillo en el que el equipo de usuario (UE) en UMTS tiende a
establecer una sesión que requiere soporte de QoS a una entidad correspondiente
ubicada en la Internet convencional. En este caso, el UE en el UMTS es capaz de
reservar recursos de red entre el SGSN (nodo de soporte GPRS [servicio general de
radio por paquetes] servidor) y el GGSN (nodo de soporte GPRS pasarela)
suficientes para garantizar los requisitos de QoS. Sin embargo, la entidad corres-
pondiente no tiene forma de reservar ningún recurso. Como resultado, la sesión
multimedia puede satisfacer sus requisitos de QoS parcialmente (es decir, dentro de
la red UMTS). Cabe destacar que Internet se considera en la actualidad una red de
mejor esfuerzo, a pesar de que ya existen varios modelos de calidad de servicio,
como IntServ y DiffServ.
En este capítulo, analizamos cómo soportar la QoS en una red de convergencia
basada en IMS. Como solución eficaz, proponemos un esquema de control de QoS
denominado IPFIX (fijación de clase en la cabecera de opción CP), que admite
funcionalidades para identificar al usuario de QoS y reservar recursos de red. IPFIX
pretende especialmente satisfacer la necesidad de interoperabilidad entre una red
UMTS con QoS y una Internet convencional para las NGN. El sistema es mucho
más eficiente que los sistemas utilizados habitualmente, como el protocolo de
reserva de recursos (RSVP) o PDP, necesarios para soportar la QoS en UMTS. Esto
se debe principalmente a que IPFIX sólo utiliza el campo de opción de la cabecera
IP en ausencia del protocolo de reserva de recursos. Como resultado, IPFIX puede
reducir el número de pasos de procesamiento en el establecimiento de una sesión, lo
que se traduce en un menor tiempo de establecimiento de llamada.
Control de calidad basado en políticas para una red de 159
convergencia

Planteamiento de problemas
La figura 7.1 ilustra un modelo de red en el que consideramos tres escenarios
diferentes basados en la capacidad para soportar la QoS de las redes a las que
pertenecen las entidades de comunicación (es decir, A, B, C y D). Presentamos un
mecanismo sencillo para cada uno de los escenarios.

Escenario 1: Usuario UMTS A a usuario UMTS B. Este escenario muestra el caso de

utilización de funcionalidades de IMS para garantizar la QoS de una sesión
establecida entre A y B. Tanto A como B están controlados por la función
de decisión de política (PDF) especificada por 3GPP porque ambos UEs
residen en la red UMTS, donde asumimos que los dos peers de
comunicación son compatibles con las funcionalidades especificadas por
3GPP. Como resultado, la PDF reserva adecuadamente los recursos y
utiliza PDP para el control del enlace; de este modo, se puede prestar un
buen servicio a una sesión multimedia.
Escenario 2: Usuario A de UMTS a usuario C de IntServ. El UE A puede
reservar recursos de red como se ha explicado en el escenario 1. El usuario
C de la red habilitada para IntServ puede reservar recursos utilizando
RSVP [6]. Asimismo, el usuario C de la red habilitada para IntServ puede
reservar recursos utilizando RSVP [6]. Al igual que en el escenario 1, se
puede establecer una sesión QoS bajo el requisito de que debe haber un
router de borde para la interconexión entre la red IntServ y la red central
DiffServ [7].

HSS
Diámetro
IMS
I-CSCF S-CSCF
SIP
P-CSCF PDF D
MGCF PDF P-CSCF
Gm

COPS
COPS H.248 DSLAM Vaya Remoto
Vaya
Gm a
A a PEP Internet Anfitri
ón
IMS MGW
PEP

UE PEP

GGSN WLAN
SGSN Núcleo
DiffServ PEP Enrutador
UTRAN de borde Remoto
Anfitri
ón
Enrutador
de borde IntServ C
B

Remoto
UE Anfitrión

FIGURA 7.1
Modelo de red.
160 Manual del subsistema multimedia fP (fM£)

Escenario 3: usuario A de UMTS a usuario D de Internet convencional. En el

caso del usuario A de UMTS, la forma de reservar recursos es la misma
que en escenarios 1 y 2. El problema es para el usuario D porque reside en
Internet convencional, donde no se dispone de un mecanismo de reserva de
recursos como PDP o RSVP. El problema es para el usuario D porque
reside en la Internet convencional, donde no está disponible un mecanismo
de reserva de recursos como PDP o RSVP. Por lo tanto, no se puede
establecer una sesión necesaria para un requisito de QoS especificado.

A continuación, consideramos una arquitectura de QoS asimétrica de este tipo (es

decir, el tercer escenario). En Internet es muy difícil soportar la QoS como lo hace
UMTS, aunque el dispositivo de usuario esté equipado con RSVP o PDP. Por lo
tanto, debemos centrarnos en la identificación de usuarios IMS para la reserva de
recursos en una red central DiffServ en lugar de encontrar una solución para toda la
red. Esto se debe a que los paquetes se marcan y gestionan como una clase BE
(mejor esfuerzo) si no existe un mecanismo para la autorización de usuario
preformada o ninguna forma de identificar el paquete una vez que llega a la red
central DiffServ gestionada por el IMS. Los requisitos de QoS de los paquetes no
pueden garantizarse ni siquiera en la red UMTS. A continuación presentamos la
solución conceptual al problema.
La primera solución es utilizar PDP para la reserva de recursos. PDP es una
solución sencilla para soportar la identificación del usuario y el interfuncionamiento
con la red central DiffServ. Para ello, es necesario implementar PDP en el
dispositivo del usuario D que reside en la Internet convencional. La segunda
solución consiste en utilizar RSVP para la reserva de recursos. Esta forma es similar
a la primera solución. La principal limitación de la segunda solución es el requisito
de implementación de RSVP en el dispositivo del usuario D. Además de disponer de
RSVP, también se requiere que D esté equipado con SIP para el control de sesión.
La tercera solución es utilizar la extensión de SIP descrita en Mehdi [8] para
soportar QoS de extremo a extremo. La ventaja de esta solución sobre las anteriores
es que no es un protocolo de reserva adicional como PDP o RSVP. En su lugar, se
requiere L-PDF, que se utiliza para el control de recursos en una red de acceso, y la
función de decisión de política local (L-Proxy), que se utiliza para la identificación
del solicitante de QoS y la reserva de recursos. Esta solución también requiere la
implementación de la extensión SIP en el usuario D.
Como hemos descrito antes, todas las soluciones requieren una implementación
compleja para reservar recursos de red. En particular, tanto PDP como RSVP no se
diseñaron originalmente para un usuario de Internet convencional, sino que se
especificaron para redes UMTS e IntServ, respectivamente. Parece una mejor idea
utilizar la tercera solución (es decir, utilizar una extensión de SIP) que la primera o
la segunda. Sin embargo, sigue existiendo la limitación de instalar componentes de
red adicionales, como L-PDF y L-Proxy.

Régimen propuesto
En esta sección, proponemos el esquema IPFIX como un mecanismo eficiente
reservarecursos que permite a un usuario convencional de Internet establecer una red
de acceso a Internet.
Control de calidad basado en políticas para una red de 161
convergencia

sesión habilitada para QoS a través de una red central DiffServ. Además, como se ha
mencionado en la sección anterior, IPFIX no requiere una implementación compleja
para la reserva de recursos del usuario de Internet. En su lugar, utiliza el campo de
opción de la cabecera IP para intercambiar la información de QoS necesaria para la
reserva de recursos.

Cabecera IPFIX
La cabecera de opción IP para IPFIX consta de cuatro campos: Tipo, control de
admisión de llamadas (CAC), clase DiffServ y campos de token de autorización. La
sintaxis y la semántica de los campos son las siguientes:

Tipo (1 bit): Este campo permite al UE distinguir si el mensaje recibido es una

solicitud o una respuesta de QoS. Si este campo está ajustado a uno, se
utiliza para una solicitud de reserva de recursos. En caso contrario, el
mensaje se utiliza como respuesta a la solicitud de QoS.
CAC (1 bit): Este campo indica si se acepta o no la solicitud de QoS.
Si el campo se establece en uno, se aceptan los requisitos de QoS del UE.
Clase DiffServ (3 bits): El UE registra información de clase diferenciada en
este campo de acuerdo con los resultados de la investigación de los
parámetros contenidos en las extensiones del protocolo de descripción de
sesión (SDP). El 3GPP especifica cuatro clases diferentes.
Token de autorización (tamaño variable en bits): Este campo contiene el token
de autorización de medios. El contenido del campo se asigna directamente
a la información de la cabecera P-media-authorization en SIP. Por lo tanto,
sólo un mensaje de solicitud de reserva de recursos utiliza este campo (es
decir, no es para mensajes de respuesta).

Funcionamiento de IPFIX
La figura 7.2 muestra un procedimiento de establecimiento de sesión en el caso de
utilizar IPFIX. UE1 envía un mensaje de solicitud INVITE que contiene un SDP
inicial a la función de control de sesión de llamada proxy (P-CSCF). Al recibir la
solicitud INVITE, UE2 envía el mensaje de respuesta 183 (progreso de sesión) de
vuelta a UE1 a través la P-CSCF con el SDP aceptado. El UE1 que recibe el
mensaje 183 de progreso de sesión envía una solicitud PRACK (acuse de recibo de
respuesta provisional). Al mismo tiempo, el UE1 envía un mensaje de contexto PDP
activo al GGSN a través del SGSN. El UE1 asocia el contexto PDP a la sesión
incluyendo la información del token de autorización de medios y la información del
identificador de flujo. Al recibir la solicitud PRACK [9], el UE2 selecciona un
identificador de clase de acuerdo con los parámetros de las extensiones SDP, y el
UE2 envía la respuesta 200 OK de vuelta al UE1, recodificando el testigo de
autorización de medios y la información de clase seleccionada en el campo de
opción de la cabecera IP.
Al recibir el mensaje de respuesta 200 OK que contiene el campo de opción del
encabezado IP, el enrutador de borde genera un mensaje de solicitud de servicio de
política abierta común (COPS) de acuerdo con la información que contiene el token
de autenticación de medios, el tipo de clase de QoS y la dirección IP de origen y, a
continuación, lo envía a
162 Manual del subsistema multimedia fP (fM£)

Borde
UE1 GGSN P-CSCF S-SCSF P-CSCF DiffSer UE2
v
PDF PDF
Invitar(Oferta SDP
inicial)
Invitar(Oferta SDP inicial)

Control de servicios
Invitar(Oferta SDP
inicial) Invite(Oferta SDP inicial)
183 Progreso de la

183 Progreso de la sesión

sesión
183 Progreso de la sesión

Autorizar recursos QoS

183 Progreso de la sesión

PRACK
PRACK
PRACK
PDP activo Req
COPS Req
Autorizar recursos QoS
COPS DEC
Aplicación PRACK
de la política
200OK
COPS RPT 200OK
Activo PDP Acc IP TOS :
200OK 110xxx
200OK COPS Req Marcado

COPS DEC
ACTUALIZACIÓN Política
Ejecución COPS
ACTUALIZACI
ÓN ACTUALIZA RPT
CIÓN ACTUALIZACIÓN
IP TOS :
101xxx
Marcado
200OK
200OK
180 Timbre
200OK 200OK
180 Timbre
180 Timbre 180 Timbre

PRACK
PRACK
PRACK
PRACK

200OK
200OK
200OK
200OK

ACK
ACK
ACK
ACK

FIGURA 7.2
Procedimiento de establecimiento de llamada de extremo a extremo.
Control de calidad basado en políticas para una red de 163
convergencia

el PDF. A continuación, el enrutador de borde pone en marcha los procedimientos

de aplicación de políticas. Si la ruta de borde DiffServ recibe un paquete IP
(UPDATE [10]) destinado a UE2, la ruta de borde reenvía el paquete a UE2 después
de establecer el campo CAC del campo de opción del paquete en uno. UE2
descodifica el campo de opción de la cabecera IP para investigar si se ha aceptado o
no la solicitud. A continuación, UE2 envía un mensaje 200 OK de vuelta a UE1
como respuesta al mensaje UPDATE. Los últimos pasos los sigue el estándar IMS.
Los procedimientos de liberación de recursos se activan mediante un mensaje BYE
generado por UE2. El establecimiento de llamada se libera finalmente al recibir un
mensaje 200OK como respuesta al mensaje BYE. Para liberar recursos en la red central
Diffserv, la P-CSCF envía un mensaje COPS DEC al router de borde DiffServ.
IPFIX está pensado esencialmente para soportar QoS para un usuario que reside en la
Internet convencional. Puede hacerse enviando la información de autorización de
medios al router de borde DiffServ durante la fase de establecimiento de sesión.
Como hemos descrito anteriormente, IPFIX no obliga a un usuario en Internet a
estar equipado con ningún protocolo de reserva de recursos, como PDP o RSVP; en
su lugar, utiliza el campo de opción de la cabecera IP. En consecuencia, IPFIX es más
eficiente que PDP o RSVP en términos de sobrecarga de control y tiempo que se tarda
en realizar el establecimiento de llamada.

Aplicación y resultados de la demostración

Implantación de IMS y DiffServ Core Network
Hemos desarrollado el IMS en ordenadores Linux. Además, para demostrar el ,
hemos implementado la P-CSCF, la función de control de sesión de llamada de
servicio (S-CSCF), el enrutador de borde DiffServ (soporta IPFIX y contexto PDP),
UE (soporta IPFIX), PDF y PEP (punto de aplicación de políticas). La P-CSCF y la
S-CSCF se han implementado modificando el código fuente del enrutador exprés
SIP, desarrollado por IPTEL [11] (sin utilizar FOKUS).

• P-CSCF se ha desarrollado en ordenadores portátiles con la versión 2.6.3

del núcleo Linux (Red Hat Linux Fedora Core 1). P-CSCF ofrece SIGCOMP
(compresión de señalización), PDF basado en políticas y funcionalidades
para soportar la cabecera P-media-authorization y la cabecera P-extension.
• S-CSCF también se ha desarrollado en un ordenador portátil. La S-CSCF
funciona como intermediario de servicios e incluye funciones para
procedimiento IMS, la base de datos del servicio de abonado doméstico
(HSS) y el acuerdo de autenticación y clave (AKA)-MD5v1.
• El router de borde DiffServ se ha implementado modificando los módulos
del kernel de Linux, cuya versión 2.4.20-8 es la 9.0 de Red Hat Linux. El
enrutador de borde DiffServ soporta control de tráfico, marcado de campos
de punto de código de servicio diferenciado (DSCP), programación de
colas ponderadas justas en el peor de los casos (WF2Q), clasificación
multi-campo y la función PEP basada en políticas.
164 Manual del subsistema multimedia fP (fM£)

Teléfono IMS (UE) P-CSCF S-CSCF

Gestor de eventos Gestor de eventos Gestor de eventos

Módulo IMS Transaction

Gestor de transacciones Gestor de transacciones

VIO Manager
Módulo IMS Módulo IMS
Módulo
Parser SIP Módulo PDF Parser SIP Corredor de
SIP PDP/IPFIX CODEC servicios
Parser Módulo Módulo

Enrutador de borde DiffServ/PEP Enrutador central DiffServ

Módulo PEP Traffic Control Gestión

Traffic Control Gestión

Clasificador de campo único
PDP/IPFIX Clasificado Acondiciona
Módulo r dor Traffic
MultiCam
Programador
Marcador/escalador DSCP

FIGURA 7.3
Diagrama modular de aplicación.

• Hemos implementado una aplicación para sistemas Windows XP llamada

softphone que realiza IPFIX UE. El UE es capaz de soportar la cabecera de
extensión P, el método PRACK y el método UPDATE. Además, soporta
IPFIX y el contexto PDP para la reserva de recursos.

La figura 7.3 muestra diagramas genéricos de la implementación tanto para redes

IMS como para redes centrales DiffServ.
En la Figura 7.4 se muestra el flujo funcional del procesamiento de señalización
IMS. Un llamante envía el mensaje de respuesta 183 (progreso de la sesión) a un
llamante a través de la P-CSCF2 con el SDP aceptado. Al recibir la respuesta 183, la
P-CSCF2 ejecuta una función de análisis sintáctico SIP. A continuación, la P-
CSCF2 envía un mensaje de análisis sintáctico SDP basado en la solicitud
DIAMETER y crea la regla de política. La PDP crea un token de autorización
después del análisis sintáctico DIAMETER, y envía la respuesta DIAMETER a la
P-CSCF2 con un token de autorización. La P-CSCF2 almacena el token de
autorización con la información del usuario (perfil QoS), y la P-CSCF2 envía la
respuesta 183 a la S-CSCF.
La S-CSCF envía la respuesta 183 a la P-CSCF1. Al recibir la respuesta 183, la P-
CSCF1 ejecuta el mismo proceso que la P-CSCF1. Sin embargo, la P-CSCF1 no
almacena el token de autorización. En su lugar, la P-CSCF1 añade un testigo de
autorización en P-media-authorization y, a continuación, envía la respuesta de
sesión 183 al equipo de usuario. El equipo de usuario que recibe la respuesta 183
envía una solicitud PRACK. Al mismo tiempo, el UE envía un contexto PDP activo
 P-CSCF1 P-CSCF2

convergencia
Control de calidad basado en políticas para una red de
Análisis SDP

Activación del
servicio

diámetros diámetros
diámetro diámetro

S-CSCF
Diámetro PDF Diámetro
Respuesta diámetros Respuesta diámetros

autorizada autorizada

183 Progreso de la
sesión
PDF

UE(Llamant UE(Callee)
e) Análisis sintáctico COPS Solicitud COPS

FIGURA 7.4
Proceso de IMS.
GGSN/
Enrutador de borde
Diffserv

165
166 Manual del subsistema multimedia fP (fM£)
Internet IMS/DiffServ WCDMA

S-CSCF
P-CSCF P-CSCF

Congestión
UE
UE

SIP SIP SIP SIP

Cubo Cubo
10M 100M 100M 100M

(COPS)

(COPS)
Go

Go
Mecanismo IPFIX DiffServ Contexto del
DiffServ GGSN PDP
Núcleo
Borde

BG BG

Monitor Monitor

-Marcado QoS -Proxy SIP -PHP -Registrador

-Traffic Control -Autorización QoS -Colas prioritarias -Basado en
prioridades
-Cliente COPS Servidor -COPS Enrutamiento

FIGURA 7.5
Arquitectura del banco de pruebas.

con un token de autorización al GGSN. Al recibir el mensaje de contexto PDP

activo, el GGSN configura un filtro basado en el perfil QoS y envía el mensaje de
solicitud COPS con el testigo de autorización, la clase de servicio y el ID de flujo.
La PDF recibe el mensaje de solicitud COPS y compara el token de autorización del
mensaje de solicitud COPS con los del token de autorización guardado. Si los dos
tokens de autorización coinciden, la PDF envía el mensaje de decisión COPS al
GGSN con la clase de servicio aceptada.

Demostración y resultados experimentales

La figura 7.5 muestra una arquitectura simplificada de nuestro banco de pruebas
para demostrar IPFIX. En la demostración, utilizamos el siguiente escenario:

• El UE en la Internet convencional tiende a utilizar el servicio de streaming

multimedia.
• Se está produciendo una congestión en el router de borde DiffServ (hemos
utilizado tráfico de fondo para generar la congestión).
• El UE en Internet inicia el procedimiento de establecimiento de la sesión
SIP utilizando IMS.
• Durante el procedimiento de establecimiento de la sesión SIP, el equipo de
usuario utiliza IPFIX para la reserva de recursos.
• Una vez seguidos los procedimientos de establecimiento de sesión por el
estándar IMS, el router de borde DiffServ es capaz de proporcionar una
clase de QoS diferenciada con UE (véanse los resultados denotados por
"Streaming A" y "Streaming B" en la Figura 7.6).
Control de calidad basado en políticas para una red de convergencia 162

ip/otro 5000/udp
5001/udp
8 10000/udp (Streaming A)
10006/udp (Streaming B)
icmp/ip
Traffic (Mbps)

6
Sesión
Establecimient
4 o
por IMS
2

1780 1800 1820 1840 1860

Tiempo
(seg)

FIGURA 7.6
Resultado de la demostración mediante IPFIX.

Hemos evaluado el módulo IPFIX y el módulo central DiffServ. En la figura 7.6

se muestra un ejemplo. En esta figura, 5000/UDP (protocolo de datagramas de
usuario) indica el tráfico de fondo que provoca congestión en el router de borde;
10000/UDP y 10006/UDP indican los flujos A y B, respectivamente. Como se
muestra en el gráfico (parte superior de la Figura 7.6), ambos flujos se gestionan
como una clase BE antes de que se establezca la sesión IMS. Sin embargo, el
streaming A obtiene más ancho de banda que el streaming B después de 1.830
segundos, cuando lanzamos el software IMS, por lo que la calidad del streaming A
es mejor que la del streaming B (parte inferior de la figura 7.6).

Conclusión
En este capítulo hemos propuesto IPFIX, que proporciona una forma eficiente de
reservar recursos de red. La principal ventaja del esquema es que no
168 Manual del subsistema multimedia fP (fM£)

no requiere que los usuarios de Internet estén equipados con ningún protocolo de
reserva de recursos, como PDP o RSVP. En consecuencia, podemos evitar
implementaciones complejas para soportar la QoS y reducir la sobrecarga de control
y el tiempo que se tarda en realizar el establecimiento de llamada. En IPFIX, estos
procedimientos pueden realizarse registrando la información mínima de QoS en el
campo de opción de la cabecera IP. Los resultados de nuestra implementación
demuestran que IPFIX puede soportar bien los servicios diferenciados en un
escenario de red convergente.

Referencias
1. 3GPP TS 23.228, Subsistema multimedia IP (IMS), diciembre de 2006.
2. 3GPP TS 23.002, Arquitectura de red, marzo de 2006.
3. 3GPP TS 23.221, Requisitos de arquitectura, marzo de 2006.
4. Rosenberg, J. et al. 2002. SIP: Protocolo de iniciación de sesión, IETF RFC 3621.
5. 3GPP TS 29.060, General packet radio service (GPRS); GPRS tunneling protocol (GTP) across
the Gn and Gp interface, diciembre de 2006.
6. Braden, R., L. Zhang, S. Berson y S. Jamin. 1997. Resource reSerVation Proto- col (RSVP),
IETF RFC 2205.
7. Eunsook, K., y S.-G. Kang. 2004. QoS support based on IntServ/DiffServ for SIP-based
applications. NOMS 2004, IEEE/IFIP, 131-144.
8. Mehdi, M. 2005. New QoS control mechanism based on extension to SIP for access to
UMTS core network via different kinds of access networks. WiMob 2005, conferencia
internacional del IEEE, 150-157, agosto.
9. Rosenberg, J. et al. 2002. Reliability of provisional responses in the session ini- tiation
protocol (SIP), IETF RFC 3262.
10. Rosenberg, J. et al. 2002. The session initiation protocol (SIP) UPDATE method, IETF RFC
3311.
11. El sitio web de IPtel. [Link]
8
O£A £Capacidad de servicio
Servidor-Parlay/Parlay X

Moo Wan Kim y Ryozo Ito

CONTENIDO
Introducción ....................................................................................................................... 170
OSA (Acceso Abierto a los Servicios)................................................................................. 171
Configuración de Open Service Access .............................................................. 171
Mecanismos básicos en la AOS ............................................................................ 171
Marco ....................................................................................................................... 173
SCFs .................................................................................................................................... 174
Servicio web Parlay X ......................................................................................................... 176
Llamada de terceros ................................................................................................ 177
Llamada de terceros iniciada por la red ............................................................... 178
SMS ........................................................................................................................... 178
Mensaje multimedia ................................................................................................. 178
Pago .......................................................................................................................... 179
Gestión de cuentas .................................................................................................. 179
Estado del terminal.................................................................................................. 180
Ubicación de la terminal ........................................................................................... 180
Llamada de audio ....................................................................................................... 180
Gestión de llamadas ................................................................................................ 181
Conferencias multimedia ....................................................................................... 181
Gestión de listas de direcciones ............................................................................ 181
Presencia .................................................................................................................... 182
Difusión de mensajes .............................................................................................. 182
Geocodificación ......................................................................................................... 182
Servicio web ........................................................................................................................ 183
WSDL........................................................................................................................ 183
SOAP ......................................................................................................................... 187
Referencias .......................................................................................................................... 189

169
120 Manual del subsistema multimedia fP (fM£)

Introducción
Para implantar aplicaciones de forma eficiente, el 3GPP (3rd Generation Partnership
Project) ha estandarizado el OSA (acceso abierto a servicios) como marco flexible
para que los desarrolladores de aplicaciones puedan implantar diversas aplicaciones
haciendo uso de las funcionalidades de red en los dominios CS (conmutador de
circuitos), PS (conmutador de paquetes) e IMS. Los desarrolladores de aplicaciones
podrían acceder a las funcionalidades de red a través de la API (interfaz de
programación de aplicaciones) OSA estandarizada que ofrece el SCS (servidor de
capacidad de servicio) (Figura 8.1).
El 3GPP ha estandarizado la API Parlay como la API OSA, que se basa en la
arquitectura CORBA (Common Object Request Broker Architecture). La API
Parlay es independiente de las soluciones de proveedores específicos, lenguajes de
programación y sistemas operativos. El 3GPP también ha estandarizado la API
Parlay X. La API Parlay X es ofrecida por la pasarela de servicios Web, que permite
a los desarrolladores de aplicaciones interactuar con funcionalidades de red sin
necesidad de tener conocimientos detallados de telecomunicaciones. La pasarela de
servicios Web Parlay X interactúa con el servidor de capacidad de servicio OSA a
través de una API OSA. Las aplicaciones pueden invocar un servicio Web Parlay X
mediante una solicitud y respuesta SOAP (protocolo simple de acceso a objetos).

Servidor de aplicaciones

API de Parlay X

Servidor de aplicaciones OSA

Pasarela de servicios web

API OSA

Servidor de capacidad de servicio OSA

Dominio CS Dominio PS Dominio IMS

FIGURA 8.1
Servidor de capacidad de servicio OSA.
O£A £capacidad de servicio £servidor-Parlay/Parlay X 121

OSA (Acceso Abierto a los Servicios)

La OSA proporciona a los desarrolladores de aplicaciones un marco flexible que les
permite desarrollar nuevas aplicaciones y mejorar las existentes haciendo uso de las
funcionalidades de red. El SCF (service capability feature) del SCS proporciona la
funcionalidad de las capacidades de red a las que pueden acceder las aplicaciones a
través de las API estandarizadas de la OSA.

Configuración de Open Service Access

La OSA consta de un marco y un SCS. La autenticación, el registro y la detección

son ejemplos de funciones del marco. Las aplicaciones pueden acceder al SCF
después de que éste se haya registrado en el marco. La autenticación entre la
aplicación y el marco es necesaria cuando una aplicación debe utilizar el SCF. Una
vez completada la autenticación, la aplicación puede averiguar mediante la función
de descubrimiento del marco qué SCF están disponibles y puede acceder a los SCF a
través de los métodos definidos en las API OSA (Figura 8.2).
Algunos ejemplos de SCF ofrecidos por el SCS son el control de llamadas, la
localización de usuarios, la mensajería multimedia y la tarificación. Los SCS que
proporcionan las interfaces OSA son entidades funcionales que pueden estar
distribuidas en uno o más nodos físicos. Por ejemplo, las interfaces de localización
de usuarios y control de llamadas pueden implementarse en una única entidad física
o distribuirse en diferentes entidades físicas. Además, los SCS pueden
implementarse en el mismo nodo físico que una entidad funcional de red o en nodos
físicos separados. Los SCS ocultan información detallada sobre la implementación y
proporcionan al desarrollador de aplicaciones una especie de servicio abstracto de
red. Así, los desarrolladores de aplicaciones pueden crear aplicaciones de servicios
de red sin necesidad de tener conocimientos específicos y detallados sobre las redes
de telecomunicaciones (Figura 8.3).

Mecanismos básicos de la AOS

Los mecanismos básicos se ejecutan en la OSE antes de ofrecer y activar las
aplicaciones de la siguiente manera:

1. Mecanismos entre aplicación y marco:

• Autenticación. Una vez alcanzado un acuerdo de servicio offline, la
aplicación puede acceder a la función de autenticación. El modelo de
autenticación de OSA es un modelo de igual a igual. La aplicación
debe autenticar el marco y viceversa. La aplicación debe autenticarse
antes de que se le permita utilizar cualquier otra función de OSA.
122 Manual del subsistema multimedia fP (fM£)

Servidor de aplicaciones

Aplicación

OSA-API

Acceso
abierto
a los
servicio
s Marco Servidor de capacidad de servicio

HSS S-CSCF ... Ubicación

FIGURA 8.2
Configuración de OSA.

• Autorización. La autorización es la acción de determinar qué puede

hacer una aplicación previamente autenticada. Una vez autenticada, una
aplicación está autorizada a acceder a determinados SCF.
• Descubrimiento. Tras una autenticación correcta, las aplicaciones
pueden obtener las funciones marco disponibles y utilizar la función de
descubrimiento para obtener información sobre los SCF autorizados.
• Acuerdo de servicio. Antes de que cualquier aplicación pueda
interactuar con un SCF, debe establecerse un acuerdo de servicio. Un
acuerdo de servicio puede constar de una parte offline y otra online.
• Control de acceso. El marco proporciona funciones de control de
acceso para autorizar el acceso a la API desde una aplicación a los SCF
con el nivel de seguridad especificado.
2. Mecanismo entre el marco y el SCS:
• Registro. Los SCF ofrecidos por un SCS pueden registrarse en el
marco. Tras el registro, el marco puede informar a las aplicaciones que
lo soliciten sobre los SCF disponibles. Este mecanismo se aplica al
instalar o actualizar un SCS. Un SCF no registrado no está disponible
para una aplicación.
3. Mecanismos entre el servidor de aplicaciones y el SCS:
• Solicitud de notificación de eventos. Se aplica cuando un usuario se ha
suscrito a una aplicación y esa aplicación necesita ser invocada al
recibir eventos de la red relacionados con el usuario. Por ejemplo,
cuando un usuario se suscribe a una llamada entrante
O£A £capacidad de servicio £servidor-Parlay/Parlay X 123

OSA-API

Pasarela OSA
SCS

HSS SMS ...

Configuración SCS única

OSA-API

Pasarela OSA
SCS SCS SCS

HSS SMS ...

Configuración SCS distribuida

OSA-API

SCS SCS SCS

HSS SMSexistente
SCS en el nodo de red ...

FIGURA 8.3
Métodos para aplicar el SCS.

la aplicación debe ser invocada cuando el usuario recibe una llamada.

Marco
Antes de que la aplicación utilice los SCS, la aplicación es accesible a la función de
gestión de la seguridad mediante la API OSA proporcionada por el marco. La
autenticación mutua tiene lugar entre el servidor de aplicaciones OSA y el marco.
La API OSA soporta múltiples técnicas de autenticación; esto incluye procesos
criptográficos para proporcionar confidencialidad y firmas digitales para garantizar
la integridad.
Para utilizar los SCF OSA, la aplicación debe establecer un acuerdo de servicio
con la red. La aplicación utiliza el SCF de descubrimiento para recuperar el ID del
SCF. El acuerdo de servicio se firma digitalmente entre el operador y el proveedor
de servicios.
124 Manual del subsistema multimedia fP (fM£)

Una aplicación necesita conocer los SCS disponibles proporcionados por el SCS
para acceder a las funcionalidades de la red. Para , los SCS registrarse en el marco.

SCFs
Los SCS proporcionan los SCF a las aplicaciones para permitir el acceso a los recursos
de la red. El 3GPP define los 10 SCF siguientes.

1. SCF de control de llamadas. La SCF de control de llamadas proporciona

una aplicación control de llamadas de dominio CS, control de sesiones de
subsistema multimedia (IMS) de protocolo IP (Internet Protocol) y
tarificación de llamadas/sesiones. La SCF de control de llamada soporta las
siguientes funcionalidades:
• función de gestión de la llamada/sesión (por ejemplo, activar o
desactivar las notificaciones de eventos relacionados con la
llamada/sesión); y
• control de llamada/sesión (por ejemplo, enrutar o desconectar
llamada/sesión).
La API OSA se asigna a la parte de aplicación (CAP) del protocolo CAMEL
(aplicaciones personalizadas para lógica mejorada de red móvil) para controlar la
gsmSSF (véase el capítulo 10) o la parte de aplicación móvil (MAP) para acceder a las
funciones del registro de ubicación de origen (HLR) en el dominio CS. La API OSA
también se asigna a la interfaz de control de servicios IMS (ISC) para controlar la
función de control de sesión de llamada de servicio (S-CSCF) y el controlador de
función de recursos de medios (MRFC) en el dominio IMS:

2. SCF de control de sesión de datos. La SCF de control de sesión de datos

proporciona a una aplicación el control de sesión del dominio PS. El SCF
de control de sesión de datos soporta las siguientes funcionalidades:
• funciones de gestión de la sesión de datos (por ejemplo, activar o
desactivar las notificaciones de eventos relacionados con la sesión de
datos); y
• control de sesión (por ejemplo, enrutar o desconectar la sesión de datos).
3. SCF de movilidad. La SCF de movilidad proporciona información sobre la
ubicación del terminal y supervisión general del estado del terminal basada
en información relacionada con la red. La SCF de movilidad soporta las
siguientes funcionalidades:
• solicitudes de localización de usuarios;
• solicitudes para iniciar o detener la generación por la red de informes
periódicos de localización de usuarios;
• solicitudes para iniciar o detener la generación por parte de la red de
informes de localización de usuarios basados en cambios de
localización;
• informe de información de localización; y
• notificación de actualización de ubicación.
O£A £capacidad de servicio £servidor-Parlay/Parlay X 125

4. SCF de capacidad del terminal. El SCF de capacidad del terminal proporciona

información de aplicación sobre las capacidades del terminal del usuario.
Sólo los dispositivos WAP y MExE pueden proporcionar capacidades de
terminal en la versión 5 de 3GPP.
5. SCF de interacción con el usuario. El SCF de interacción con el usuario
proporciona una aplicación con interacción con el usuario para recuperar
información del usuario. Soporta las siguientes funcionalidades:
• interacción del usuario con el usuario del dominio IMS; y
• interacción del usuario con el usuario del dominio CS.
6. SCF de cobro. Este SCF proporciona una aplicación para acceder a las
cuentas de abonado mantenidas por la red y cobrar a los abonados por el
uso del servicio. Soporta las siguientes funcionalidades:
• comprobar que el cargo está cubierto por la cuenta o el límite de
crédito del abonado;
• reservando un cargo en la cuenta del abonado, que puede deducirse de
la misma tras la prestación del servicio;
• deduciendo un importe de la cuenta del abonado;
• liberar una reserva adquirida anteriormente;
• añadir unidades no monetarias a la cuenta de un abonado; y
• deducir unidades no monetarias de la cuenta de un abonado.
7. SCF de gestión de cuentas. El SCF de gestión de cuentas proporciona una
aplicación con las funciones necesarias para supervisar la cuenta de un
abonado. Soporta las siguientes funcionalidades:
• recuperación del historial de transacciones de la cuenta de un
determinado abonado;
• consulta del saldo de la cuenta de uno o varios abonados; y
• solicitud de notificaciones sobre determinados criterios para uno o
varios abonados.
8. SCF de presencia. El SCF de presencia proporciona a una aplicación acceso
a las capacidades de presencia dentro de la red. La información de
presencia es un conjunto de atributos que caracterizan las propiedades
actuales de una presen- tidad (una entidad descrita por la información de
presencia). El SCF de presencia soporta las siguientes funcionalidades:
• registrarse como observador para solicitar información de presencia de
una presen- cia y ser notificado de los cambios en la información de
presencia; y
• registrarse como presentista para publicar información de presencia.
9. SCF de mensajería multimedia. El SCF de mensajería multimedia
proporciona a una aplicación mensajería multimedia. Interactúa con el
servidor SMS-C, MMS-C, WAP PUSH y E-Mail para proporcionar
126 Manual del subsistema multimedia fP (fM£)

mensajería multimedia. En el caso de MMS-C, el SCF de mensajería

multimedia asigna una API OSA a la interfaz MM7. El SCF de mensajería
multimedia soporta las siguientes funcionalidades:
• envío y recepción de mensajes tanto en sesión como en un solo envío;
• poner mensajes en el buzón para su almacenamiento o para su envío
por el sistema de mensajería;
• cancelar un mensaje enviado previamente o consultar el estado de un
mensaje enviado previamente;
• manipular carpetas y mensajes en el buzón (por ejemplo, copiar,
mover, borrar); y
• listar los mensajes del buzón y recuperar mensajes completos,
cabeceras de mensajes, cuerpo del mensaje o partes del cuerpo del
mensaje.
10. SCF de gestión de políticas. El SCF de gestión de políticas proporciona a
una aplicación mecanismos de gestión y evaluación de políticas. Crea,
elimina, actualiza y visualiza las políticas específicas del operador,
incluyendo:
• publicación de actos políticos;
• suscribirse a eventos políticos;
• eventos generadores;
• obtener estadísticas asociadas al uso de las políticas; y
• evaluar las políticas.

Servicio web Parlay X

Las API de Parlay están diseñadas para desarrollar aplicaciones de telecomunicaciones y
aplicaciones de TI habilitadas para telecomunicaciones. Se requieren conocimientos
detallados de telecomunicaciones para desarrollar aplicaciones de TI habilitadas
para telecomunicaciones. Los servicios web de Parlay X están pensados para que los
desarrolladores de aplicaciones de TI desarrollen aplicaciones de TI habilitadas para
telecomunicaciones sin necesidad de dichos conocimientos. Las aplicaciones pueden
invocar los servicios Web Parlay X utilizando un protocolo de intercambio de
mensajes basado en XML (es decir, SOAP).
En la Figura 8.4 se ilustra una arquitectura de servicio Web Parlay X típica. Esta
arquitectura muestra la publicación de servicios web Parlay X a través de un registro
de servicios web, haciendo que esos servicios web estén disponibles para su
descubrimiento. Las aplicaciones utilizan los métodos de acceso a servicios Web
Parlay X para interactuar con la pasarela de servicios Web que accede a las
funcionalidades de red utilizando la API Parlay de OSA.
A continuación se describen los servicios web Parlay X soportados por 3GPP.
O£A £capacidad de servicio £servidor-Parlay/Parlay X 122

Servidor de
aplicaciones
Encu
Aplicación entre

Registro de servicios
web
Parlay X Definición del servicio web

Pasarela de servicios
web
Servicio web Parlay X
Publique

Parlay-API de la
OSE

Acceso abierto a los servicios

Interfaces de red
Marco SCS

Elemento Elemento Elemento

FIGURA 8.4
Arquitectura de servicios web Parlay X.

Llamada de terceros
El servicio web de llamada de terceros admite la funcionalidad de crear y gestionar
una llamada iniciada por una aplicación (llamada de terceros). La funcionalidad
proporcionada es:

• "Hacer una " establece una llamada entre dos direcciones (makeACall).
• "Obtener información de la llamada" proporciona información sobre el
desarrollo de la llamada en la red (getCallInformation).
• "Finalizar llamada" detendrá la llamada (endCall).
• "Cancelar llamada" permite a la red impedir el establecimiento de la
llamada antes de que comience (cancelCall).
128 Manual del subsistema multimedia fP (fM£)

Llamada de terceros iniciada por la red

La llamada de terceros iniciada por la red admite la notificación de eventos y el
manejo de llamadas iniciadas por un abonado en la red. Una aplicación de terceros
puede determinar cómo debe tratarse la llamada. Los servicios Web permiten a la
aplicación gestionar las siguientes condiciones que se producen en el
establecimiento de una llamada:

• destino ocupado (handleBusy);

• la dirección no es accesible (handleNotReachable);
• el destino no responde (handleNoAnswer);
• el abonado ha llamado a un número determinado (handleCalledNum- ber);
y
• notificación de eventos (NotifyBusy, NotifyNotReachable, NotifyNoAn-
swer, NotifyCalledNumber).

SMS
El servicio Web SMS permite enviar y recibir mensajes SMS. Para recibir un
mensaje SMS de la , la aplicación utiliza mecanismos de notificación. Para enviar
un mensaje a la , la aplicación invoca la API para enviarlo y, posteriormente,
consulta el estado de entrega. Se admiten las siguientes funciones:

• enviar cualquier SMS (sendSms);

• envío de un logotipo plasmado en un SMS (sendSmsLogo);
• envío de un tono de llamada incorporado a un SMS (sendSmsRingtone);
• recuperar el estado de entrega de un SMS (getSmsDeliveryStatus);
• solicitar que se le notifiquen los SMS recibidos (notifySmsReception);
• solicitar que se le notifique la recepción de un SMS enviado (notifySms-
DeliveryReport); y
• recuperar los mensajes SMS enviados a una dirección (getReceivedSms).

Mensaje multimedia
El servicio Web de mensajes multimedia ofrece funciones de mensajería genéricas
para enviar y recibir mensajes. Para recibir un mensaje multimedia de la red, la
aplicación utiliza mecanismos de notificación. Para enviar un mensaje a la red, la
aplicación invoca la API para enviarlo y, a continuación, consulta el estado de
entrega. Se admiten las siguientes funciones:

• enviar un mensaje a una dirección (sendMessage);

• recuperar el estado de entrega de un mensaje (getMessageDeliveryStatus);
O£A £capacidad de servicio £servidor-Parlay/Parlay X 129

• recuperación mediante sondeo de los mensajes recibidos (getReceivedMessage);

• recuperación de partes de mensajes mediante referencias identificadores
uniformes de recursos (URI) (getMessageURIs);
• recuperar mensajes completos como archivos adjuntos SOAP (getMessage);
• solicitar que se le notifique la recepción de un mensaje enviado (noti-
fyMessageReception); y
• notificar a la aplicación que se ha recibido un mensaje para una dirección
específica (NotifyMessageDeliveryReceipt).

Pago
El servicio Web de pago admite la reserva de pagos, los pagos prepagados y los
pagos pospagados. El servicio Web admite el cobro de importes tanto en volumen
como en divisa. Se admiten las siguientes funciones:

• cargar o reembolsar en una cuenta un importe monetario (cargarA-monto,

reembolsarA-monto);
• cobro o reembolso a una cuenta por volumen (chargeVolume,
refundVolume);
• calcular un importe en divisa a partir de un volumen (getAmount);
• reservar un importe de divisa en una cuenta (reserveAmount,
reserveAdditionalAmount);
• cargar una reserva previa en la cuenta (chargeReservation);
• liberar una reserva devolviendo a una cuenta el importe restante en una
reserva (liberarReserva); y
• reservar una cantidad de volumen de una cuenta (reserveVolume,
reserveAdditionalVolume).

Gestión de cuentas
El servicio web de gestión de cuentas admite la consulta de cuentas, la recarga
directa y la recarga mediante vales. Se admiten las siguientes funciones:

• devolver el saldo de divisas de una cuenta (getBalance);

• solicitar la fecha de vencimiento del crédito de una cuenta
(getCreditExpiryDate);
• actualización del saldo de una cuenta (balanceUpdate, voucherUpdate);
• devolver el historial de transacciones de una cuenta (getHistory);
180 Manual del subsistema multimedia fP (fM£)

• descubrir el conjunto de todos los tipos de saldo posibles (por ejemplo, voz,
SMS, juegos) que están permitidos para un usuario final especificado
(getBalanceType); y
• solicitar que se le notifiquen los cambios de estado de cuenta
(acountCharged, accountRecharged, accountLow).

Estado del terminal

El servicio Web de estado del terminal se utiliza para obtener información sobre el
estado del terminal o de un grupo de terminales. Se admiten las siguientes funciones:

• solicitar el estado del terminal de un abonado (getStatus);

• solicitar el estado del terminal de un grupo de abonados (getStatusFor-
Group); y
• solicitar que se le notifique el cambio de estado del terminal (statusNotification).

Ubicación de la terminal
El servicio web de localización de terminales se utiliza para obtener información de
localización con el fin de desarrollar aplicaciones que tengan en cuenta la ubicación.
La localización se expresa mediante la latitud, la longitud, la altitud y la precisión.
El uso del servicio Web sólo requiere conocer la longitud y la latitud. Se admiten las
siguientes funciones:

• solicitar la ubicación de un dispositivo terminal (getLocation);

• solicitar las ubicaciones de un conjunto de dispositivos terminales
(getLocationFor Group);
• solicitar la distancia de un terminal a una ubicación (getLocation Distance);
• solicitar que se le notifique el cambio de ubicación del terminal
(locationNoti- fication); y
• solicitar que se le notifique periódicamente la ubicación de un dispositivo
terminal (periodicNotification).

Llamada de audio
El servicio web de llamadas de audio Parlay X proporciona la entrega de mensajes
multimedia. El mensaje de texto se procesará utilizando texto a voz (TTS). El mensaje
de audio se reproducirá mediante un reproductor de audio. El script VoiceXML se
ren- derará utilizando un navegador VoiceXML. Se admiten las siguientes
funciones:

• reproducir contenidos de audio (playTextMessage, playAudioMessage,

play- VoiceXmlMessage, playVideoMessage);
• recuperar el estado (getMessageStatus); y
• finalizar la llamada (endMessage).
O£A £capacidad de servicio £servidor-Parlay/Parlay X 181

Gestión de llamadas

El servicio Web de gestión de llamadas permite el aprovisionamiento de reglas de

gestión de llamadas, lo que permite a las aplicaciones de terceros especificar cómo
gestionar las llamadas sin necesidad de que la aplicación las gestione. Se admiten las
siguientes funciones:

• reglas de aprovisionamiento para aceptar, bloquear, reenviar y responder

llamadas para una dirección (setRules);
• reglas de aprovisionamiento para aceptar, bloquear, reenviar y responder
llamadas para un grupo de direcciones (setRulesForGroup);
• consulta de reglas asociadas a una dirección (getRules); y
• eliminar las reglas de una dirección o grupo de direcciones (clearRules).

Conferencias multimedia

El servicio Web de conferencias multimedia permite crear una conferencia

multimedia y gestionar dinámicamente los participantes y los medios implicados. Se
admiten las siguientes funciones:

• crear una conferencia (createConference);

• consulta del estado de la conferencia o de los participantes (getConferenceInfo);
• añadir/eliminar un participante (invitarParticipante, desconectar-
Participante);
• añadir/eliminar medios para el participante (addMediaForPartici- pant,
deleteMediaForParticipant);
• consultar el estado actual del participante (getParticipantInfo);
• consulta del estado actual de cada participante (getParticipants); y
• finalizar la conferencia (endConference).

Gestión de listas de direcciones

Cuando un servicio tiene el requisito de admitir grupos de listas de direcciones, el

servicio web de gestión de listas de direcciones proporciona la gestión dinámica de
grupos y miembros de grupos. Un URI de grupo contiene un conjunto de URI de
miembros (lista de URI). Se admiten las dos funciones siguientes:

• gestión de grupos (createGroup, deleteGroup, queryGroups, setAc- cess y

queryAccess); y
• gestión de los miembros del grupo (addMember, addMembers, deleteMem-
ber, deleteMembers, queryMembers).
182 Manual del subsistema multimedia fP (fM£)

Presencia

El servicio web de presencia permite obtener información de presencia sobre uno o

varios usuarios. El servicio admite tres interfaces: una interfaz de observador para
solicitar y suscribir datos de presencia, una interfaz de notifica- ción de observador
para recibir eventos de presencia y una interfaz de presenciador para suministrar
datos de presencia y gestionar suscripciones:

• solicitudes utilizadas por el observador para obtener datos de presencia: el

observador puede seleccionar entre un modo de sondeo y un modo de
notificación para recibir los datos de presencia;
• solicitudes para recibir notificaciones de presencia; y
• solicitudes utilizadas por la presentidad para suministrar datos de presencia.

Difusión de mensajes

El servicio Web de difusión de mensajes permite difundir un mensaje basado en texto

a una zona designada. Se admiten las siguientes funciones:

• Emitir un mensaje a una zona designada con frecuencia e intervalo;

• recuperar el estado de entrega de una solicitud de difusión anterior;
• cancelar la solicitud de emisión anterior; y
• solicitando que se le notifique cuando la entrega se haya completado o sea
imposible.

Geocodificación

El servicio Web de geocodificación admite la funcionalidad de acceder a un nivel

adicional de las coordenadas geográficas, lo que permite al desarrollador del
servicio trabajar con la dirección de ubicación. Se admiten las siguientes funciones:

• solicitar la dirección de localización de un número de terminal (getAddress

OfTerminal);
• solicitar la dirección de localización de un grupo de terminales
(getAddress- OfTerminalForGroup); y
• solicitar los números de terminal conocidos en la dirección de ubicación
específica (getTerminalsAtAddress).
O£A £capacidad de servicio £servidor-Parlay/Parlay X 183

Servicio web
El servicio Web está diseñado para soportar la interacción interoperable de servicios
distribuidos mediante el intercambio de mensajes basados en XML entre clientes y
servidores a través de redes. Existen tres tecnologías básicas:

• SOAP: protocolo ligero para el intercambio de mensajes en formato XML;

• WSDL (Lenguaje de descripción de servicios Web): Lenguaje basado en XML
para la descripción de interfaces de servicios Web; y
• UDDI (descripción, descubrimiento e integración universales): publicación
y descubrimiento de metadatos del servicio Web.

WSDL
El WSDL es un lenguaje basado en XML que proporciona la capacidad de describir el
servicio Web de manera formal mediante conjuntos de puertos de red, operaciones
abstractas, mensajes y protocolo de transporte para transferir mensajes. Los
principales elementos del documento WSDL descritos por WSDL se enumeran en la
Tabla 8.1.
El siguiente ejemplo muestra la definición WSDL del servicio web de
localización termi- nal Parlay X especificado en 3GPP TS 29.199:

parlayx _ terminal _ tipos _ 2 _ [Link]

<xsd:schema targetNamespace="[Link]
org/schema/parlayx/terminal _ location/v2 _ 2"
:
xmlns:xsd="[Link]
<xsd:complexType name="LocationInfo">
<xsd:sequence>
<xsd:element name="latitud" type="xsd:float"/>
<xsd:element name="longitud" type="xsd:float"/>
<xsd:element name="altitud" type="xsd:float" minOc- curs="0"
maxOccurs="1"/>
<xsd:element name="precisión" type="xsd:int"/>
<xsd:element name="timestamp" type="xsd:dateTime"/>
</xsd:sequence>
</xsd:complexType>
:
</xsd:schema>

parlayx _ terminal _ ubicación _ 3 _ [Link]

<wsdl:definitions
name="terminal _ ubicación _ interfaz"
184 Manual del subsistema multimedia fP (fM£)

TABLA 8.1
Principales elementos de WSDL
Elementos WSDL Descripción
wsdl:definiciones Elemento raíz del documento WSDL
wsdl:tipos Definición de los tipos de datos utilizados
en los mensajes
wsdl:mensaje Definición abstracta del mensaje que se va a
transmitir
wsdl:tipo de puerto Conjunto abstracto de puertos que se utilizarán
para el servicio web
wsdl:operaciones Descripción abstracta de las operaciones
disponibles en los puertos
wsdl:vinculación Protocolo concreto que debe vincularse para
cada operación proporcionada por el
puerto
wsdl:servicio Definición de un servicio como conjunto de
puertos relacionados
wsdl:puerto Vinculación de la dirección de red a los puertos

targetNamespace="[Link]
org/wsdl/parlayx/terminal _ location/v3 _ 0/interface"
xmlns="[Link]
xmlns:wsdl="[Link]
xmlns:xsd="[Link]
xmlns:terminal _ location="[Link]
org/wsdl/parlayx/terminal _ location/v3 _ 0/interface"
xmlns:parlayx _ common _ faults="[Link]
org/wsdl/parlayx/common/v2 _ 0/faults" xmlns:terminal _
location _ xsd="[Link]
org/schema/parlayx/terminal _ location/v2 _ 2"
xmlns:parlayx _ common _ xsd="[Link]
org/schema/parlayx/common/v2 _ 1"
xmlns:terminal _ location _ local _ xsd="[Link]
org/schema/parlayx/terminal _ location/v3 _ 0/local">
<wsdl:types>
<xsd:schema>
<xsd:element name="getLocation" type="terminal _ loca- tion _
local _ xsd:getLocation"/>
<xsd:complexType name="getLocation">
<xsd:sequence>
<xsd:element name="solicitante" type="xsd:anyURI" minOc-
curs="0" maxOccurs="1"/>
<xsd:element name="dirección" type="xsd:anyURI"/>
<xsd:element name="exactitud solicitada" type="xsd:int"/>
O£A £capacidad de servicio £servidor-Parlay/Parlay X 185

<xsd:element name="exactitudaceptable" type="xsd:int"/>

<xsd:element name="maximumAge" type="parlayx _ com- mon _
xsd:TimeMetric" minOccurs="0" maxOccurs="1"/>
<xsd:element name="responseTime" type="parlayx _ com- mon
_ xsd:TimeMetric" minOccurs="0" maxOccurs="1"/>
<xsd:element name="tolerancia" type="terminal _ loca- ción
_ xsd:DelayTolerance"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="getLocationResponse" type="terminal _
localización _ local _ xsd:getLocationResponse"/>
<xsd:complexType name="getLocationResponse">
<xsd:sequence>
<xsd:element name="resultado" type="terminal _
localización _ xsd:LocationInfo"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
</wsdl:types>
<wsdl:message name="TerminalLocation _ getLocationRe- quest">
<wsdl:part name="parameters" element="terminal _ loca- tion
_ local _ xsd:getLocation"/>
</wsdl:message>
<wsdl:message name="TerminalLocation _ getLocationRe- sponse">
<wsdl:part name="result" element="terminal _ localización _
local _ xsd:getLocationResponse"/>
</wsdl:message>
<wsdl:portType name="TerminalLocation">
<wsdl:operation name="getLocation">
<wsdl:input message="terminal _ location: TerminalLocation _
getLocationRequest"/>
<wsdl:output message="terminal _ localización:
TerminalLocation _ getLocationResponse"/>
<wsdl:fault name="ServiceException" message="parlayx
_ common _ faults:ServiceException"/>
<wsdl:fault name="PolicyException" message="parlayx _ common
_ faults:PolicyException"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>

parlayx _ terminal _ servicio _ 3 _ [Link]

<wsdl:definitions name="terminal _ ubicación _ interfaz"
186 Manual del subsistema multimedia fP (fM£)

targetNamespace="[Link]
org/wsdl/parlayx/terminal _ location/v3 _ 0/service"
xmlns="[Link]
xmlns:wsdl="[Link]
xmlns:soap="[Link]
xmlns:xsd="[Link]
xmlns:tns="[Link] org/wsdl/parlayx/terminal _
location/v3 _ 0/service"
xmlns:interface="[Link]
org/wsdl/parlayx/terminal _ location/v3 _ 0/interface">
<wsdl:import namespace="[Link]
org/wsdl/parlayx/terminal _ location/v3 _ 0/interface"
location="parlayx _ terminal _ location _ interface _ 3 _
0. wsdl"/>
<wsdl:binding name="TerminalLocationBinding"
type="interface:TerminalLocation">
<soap:binding style="document" transport="[Link]
[Link]/soap/http"/>
<wsdl:operation name="getLocation">
<soap:operation soapAction="" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
<wsdl:fault name="ServiceException">
<soap:fault name="ServiceException" use="literal"/>
</wsdl:fault>
<wsdl:fault name="PolicyException">
<soap:fault name="PolicyException" use="literal"/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="TerminalLocationService">
<wsdl:port name="TerminalLocation" binding="tns:
TerminalLocationBinding">
<soap:address location="[Link]
LocationService/services/TerminalLocation"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

A continuación se explican los principales elementos del documento WSDL descrito

en el ejemplo:
O£A £capacidad de servicio £servidor-Parlay/Parlay X 182

1. Declaración del espacio de nombres. El nombre del servicio Web se define

mediante el atributo name de WSDL. El URI del documento WSDL se
indica mediante el atributo targetNamespace. Las declaraciones de espacio
de nombres para los elementos en el documento WSDL se describen como
la sintaxis específica (por ejemplo, xmlns: profix = "URL") para ser
identificados de forma única.
2. Definición del tipo. Debe definirse el tipo de datos utilizado en los
mensajes. Cualquier tipo de datos nuevo puede definirse utilizando la
combinación de los tipos básicos (por ejemplo, xsd:integer, xsd:datetime)
definidos en el esquema XML, que puede encontrarse en la URL
[Link] [Link]/2001/XMLSchema.
3. Definición del mensaje. El mensaje se define utilizando los datos. El
nombre del mensaje se indica mediante el atributo name.
4. Definición de operación. Operación en el WSDL significa un tipo de
método en el lenguaje de programación Java. Un tipo de puerto se define
como un conjunto de operaciones disponibles y los mensajes que se
utilizarán para cada una. Para el patrón de mensajes solicitud/respuesta, un
puerto tendrá una definición de operación que contiene un único mensaje
de entrada, un único mensaje de salida y cero o más mensajes de fallo.
WSDL tiene cuatro primitivas de transmisión que un puerto puede
soportar:
• Unidireccional: el puerto recibe un mensaje.
• Solicitud de respuesta: el puerto recibe un mensaje y envía un mensaje
correlativo.
• Respuesta solicitada: el puerto envía un mensaje y recibe un mensaje
correlativo.
• Notificación: el puerto envía un mensaje.
5. Protocolo de enlace. La vinculación define cómo se utilizan las
definiciones WSDL en la interacción con la red. La vinculación define los
protocolos y el estilo operativo, por ejemplo, SOAP sobre HTTP o SOAP
sobre SMTP para los protocolos, y documento o RPC (Remote Procedure
Call) para el estilo.
6. Definición del servicio. Los servicios definen un puerto, aunque la dirección del
puerto especificado en la definición suele sustituirse en tiempo de ejecución
cuando el paso de descubrimiento determina la ubicación real en la que se
aloja el servicio.

SOAP
SOAP es un protocolo ligero para intercambiar la solicitud y la respuesta en el
entorno distribuido. Es un protocolo basado en XML para transferir información
entre aplicaciones y servicios Web. SOAP consta de la cabecera de enlace del
protocolo, el sobre SOAP, la cabecera SOAP y el cuerpo SOAP:
188 Manual del subsistema multimedia fP (fM£)

1. Cabecera de enlace de protocolo. SOAP puede utilizarse con diversos

protocolos de transferencia (por ejemplo, HTTP y SMTP). Se describe una
cabecera de enlace de protocolo basada en el protocolo seleccionado para
transferir el mensaje SOAP. En el caso de , el mensaje SOAP se incluye en
el cuerpo del método POST.
2. Sobre SOAP. El mensaje SOAP consta de un sobre SOAP obligatorio, una
cabecera SOAP opcional y un cuerpo SOAP obligatorio. El sobre es el
elemento superior del mensaje SOAP y el nombre del ele- mento es
"envelope".
3. Cabecera SOAP. Los atributos incluidos en la cabecera SOAP se utilizan
para determinar cómo el destinatario de un mensaje SOAP debe procesar el
mensaje (por ejemplo, autenticación, gestión de transacciones, método de
pago).
4. Cuerpo SOAP. En este se expresan la petición y el mensaje de respuesta
SOAP. El mensaje de solicitud incluye el nombre de la operación y sus
parámetros e incluye el resultado del procesamiento.

A continuación se muestra un ejemplo de mensajes SOAP de solicitud (es decir,

getLocationRe- quest) y respuesta (es decir, getLocationResponse) que se utilizan
para acceder al servicio web de localización de terminales Parlay X para recuperar la
localización del terminal. SOAP getLocationRequest contiene el URI del terminal,
la precisión solicitada (por ejemplo, 25 m), la precisión aceptable (por ejemplo, 300
m) y la tolerancia (NoDe- lay). SOAP getLocationResponse contiene la información
de localización del terminal, es decir, la latitud, la longitud, la precisión y la fecha y
hora en que se ha obtenido esta información.

getLocationRequest
POST /ServicioTerminalLocation/servicios/TerminalLocation HTTP/1.1
Host: localhost
Content-Type: text/xml; charset="utf-8"
SOAPAction: ""
Content-Length: nnnn
SOAPAction: ""
<?xml version="1.0" encoding="UTF-8?>"
<SOAP-ENV:Sobre
xmlns:SOAP-ENV="[Link]
<SOAP-ENV:Cuerpo>
<ns1:getLocation
SOAP-ENV:encodingStyle=""
xmlns:ns1=[Link]
org/wsdl/parlayx/terminal _ location/v3 _ 0/service>
<ns1:address>[Link]
<ns1:requestedAccuracy>25</ns1:requestedAccuracy>
<ns1:acceptableAccuracy >300</ns1:acceptableAccuracy>
<ns1:tolerancia >SinRetraso</ns1:tolerancia>
O£A £capacidad de servicio £servidor-Parlay/Parlay X 189

<ns1:getLocation>
</SOAP-ENV :Body>
</SOAP-ENV :Sobre>

getLocationResponse
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<?xml version="1.0" encoding="UTF-8?>"
<SOAP-ENV:Sobre
xmlns:SOAP-ENV="[Link]
org/soap/envelope/"
<SOAP-ENV:Cuerpo>
<ns1:getLocationResponse
SOAP-ENV:encodingStyle=""
xmlns:ns1=[Link]
org/wsdl/parlayx/terminal _ location/v3 _ 0/service>
<ns1:latitud>-14.6976</ns1:latitud>
<ns1:longitud>-75.1265</ns1:longitud>
<ns1:precisión >15</ns1:precisión>
<ns1:timestamp>2007-01-01T[Link]+09:00</ns1:timestamp>
<ns1:getLocationResponse>
</SOAP-ENV :Body>
</SOAP-ENV :Sobre>

Referencias
3GPP TS 23.218 Tratamiento de sesiones multimedia IP (IM), modelo de llamada
IM. 3GPP TS 23.228 Subsistema multimedia IP (IMS).
3GPP TS 24.229 Protocolo de control de llamadas multimedia IP basado en SIP y SDP.
3GPP TS 23.333 Controlador de funciones de recursos multimedia (MRFC)-Procesador de
funciones de recursos multimedia (MRFP) Interfaz Mp: Descripción de procedimientos.
3GPP TS 29.328 IP multimedia (IM) subsystem Sh interface; signaling flows and mes- sage contents.
3GPP TS 29.329 Interfaz Sh basada en el protocolo DIAMETER.
3GPP TS 22.127 Requisitos de servicio para el acceso a servicio abierto (OSA). 3GPP
TS 23.198 Acceso al servicio abierto (OSA).
3GPP TS 29.198 Acceso a servicios abiertos (OSA); interfaz de programación de aplicaciones (API).
3GPP TS 29.199 Acceso a servicios abiertos (OSA); servicios web Parlay X.
3GPP TS 23.008 Organización de los datos de abonado.
RFC 3261 SIP: Protocolo de iniciación de sesión, junio de 2002.
RFC 3966 The tel URI for telephone , diciembre de 2004. RFC 4006
DIAMETER aplicación de control de crédito, agosto de 2005.
9
fnternetworking de redes 3GPP y
WLAN y Wimax

Fangmin Xu, Luyong Zhang, Zheng Zhou y Wei Zhong

CONTENIDO
Introducción ....................................................................................................................... 192
Conocimientos previos ..................................................................................................... 193
Arquitectura IMS para redes 3GPP ........................................................................... 193
Tecnología WLAN .................................................................................................... 194
Tecnología Wimax..................................................................................................... 195
Arquitectura de Internetworking y Niveles de Internetworking ................................. 197
Dos modos de interconexión ................................................................................. 197
Arquitectura central basada en IMS ..................................................................... 197
Niveles de Internetworking ................................................................................... 198
Extensiones de SIP relacionadas con Internetworking ..................................................... 200
Garantía de calidad de servicio .................................................................................. 200
Disposición AAA....................................................................................................... 204
Seguridad. .................................................................................................................. 205
Red inalámbrica cognitiva reconfigurable ........................................................................ 206
Arquitectura de interconexión de redes inalámbricas reconfigurables
Redes ........................................................................................................... 208
Problemas relacionados y soluciones ................................................................... 209
Intercambio de mensajes............................................................................... 209
Gestión de recursos ..................................................................................... 210
Seguridad ...................................................................................................... 211
Conclusión ........................................................................................................................... 212
Agradecimientos................................................................................................................ 212
Referencias .......................................................................................................................... 213

191
192 Manual del subsistema multimedia fP (fM£)

Introducción
La heterogeneidad en el acceso inalámbrico caracteriza el entorno radioeléctrico de
las redes inalámbricas de próxima generación. En ese entorno coexisten muchas
tecnologías de acceso inalámbrico. En un futuro próximo, las tecnologías más
utilizadas serán la tercera generación (3G) y las redes de área local inalámbricas
(WLAN), seguidas de tecnologías emergentes, como la interoperabilidad mundial
para el acceso por microondas (Wimax) o 4G. Se sugiere que estas redes de acceso
móvil estén integradas por una red central basada en el protocolo de Internet (IP) de
gran ancho de banda y una variedad de tecnologías heterogéneas de acceso
inalámbrico, como el sistema universal de telecomunicaciones móviles (UMTS),
WLAN o Wimax. Los terminales móviles podrán acceder a distintas aplicaciones
multimedia y servicios avanzados en itinerancia por zonas cubiertas por diferentes
tecnologías de acceso. El mundo de la investigación inalámbrica está estudiando
nuevas formas de facilitar la interconexión entre ellas. En la actualidad, el 3rd
Generation Partnership Project (3GPP) está desarrollando un estudio de viabilidad
para ofrecer una continuidad de servicio sin fisuras entre UMTS y WLAN [1].
El trabajo en red puede verse desde distintos puntos de vista. Sin embargo, quizá
el aspecto más importante sea el nivel de negociación de sesión, que proporciona
continuidad de servicio desde la perspectiva del usuario. En este nivel, el protocolo
utilizado por el 3GPP es el protocolo de iniciación de sesión (SIP) [2], que es la base
de la arquitectura del subsistema multimedia IP (IMS) definida para soportar
servicios multimedia en tiempo real en las futuras redes móviles. La interconexión
entre redes basadas en SIP puede presentar diferentes problemas causados por una
de las principales características de este protocolo: la extensibilidad; la mayoría de
estos problemas se presentarán en este capítulo. Los niveles de interconexión y
convergencia pueden clasificarse en convergencia de servicios, red y técnica. El
objetivo de la convergencia de servicios es compartir un sistema de servicios basado
en la interconexión. Cuando se proporciona una experiencia de servicio uniforme a
los usuarios a través de un sistema de servicio uniforme, los clientes pueden utilizar
diferentes dispositivos terminales para acceder a redes heterogéneas y acceder al
mismo servicio y lograr una facturación y gestión de sesiones comunes. La
convergencia de servicios es sólo el primer paso de la convergencia; la itinerancia
sin fisuras y el traspaso entre redes distintas son los problemas que debe resolver la
convergencia de redes. Existen grandes diferencias entre la técnica física (PHY) de
3GPP, WLAN y Wimax, que quedan fuera del ámbito de discusión de este manual.
El resto de este capítulo se organiza como sigue. Se describe brevemente la
arquitectura IMS definida por el 3GPP. A continuación, se presentan las principales
características de SIP, WLAN y Wimax, respectivamente. Por último, ofrecemos un
análisis de los problemas identificados en las secciones anteriores y aportamos
nuestras principales conclusiones y esquemas de solución.
fnternetworking de redes 3GPP y WLAN y Wimax 193

Conocimientos previos
Arquitectura IMS para redes 3GPP
UMTS está siendo estandarizado por el 3GPP en varias versiones (la versión 7
finalizó en 2006). Dentro de la red central UMTS, el 3GPP define el IMS a partir de
la versión 5 como el componente que proporciona soporte para servicios
multimodales (por ejemplo, voz o vídeo) basados en conmutación de paquetes con
calidad de servicio (QoS) y autenticación, autorización y contabilidad (AAA). La
parte izquierda de la Figura 9.1 muestra una vista general de la arquitectura IMS [3].
En esta arquitectura general podemos apreciar cómo la red central se organiza en
dos redes: una red de señalización o control y una red de datos o transporte.
La red de señalización está compuesta por un conjunto de nodos de función de
control de sesión de llamada (CSCF). En esencia, son proxies de señalización cuya
tarea consiste en establecer, modificar y liberar sesiones multimedia con garantía de
calidad de servicio y soporte de AAA y tarificación (AAAC). Proxy CSCF (P-CSCF) es
la entrada de IMS que actúa como agente de usuario en SIP. La CSCF servidora (S-
CSCF) es la entidad funcional clave en IMS que se encarga de la gestión de sesiones
y el registro de usuarios, y la CSCF interrogadora (I-CSCF) realiza funciones de
proxy y ocultación de topología entre operadores. Estos proxies se definen como
entidades funcionales

3GPP Wi PDG
Señalizaci
ón Centro de
carga y AAA Wn
Datos Wa
HSS
Diámetro Interfaz Cx

Diámetro Interfaz Cx
Diámetro Cx
IMS Wimax CSN
Interfaz Diámetro Cx
S-CSCF
Interfaz
MW
R3
Otros IMS I-CSCF
Redes Wu
P-CSCF COPS/Go SFM SFA
R6
Interfaz Wimax ASN

R4
GGSN Router IP
Wimax BS Otros Wimax
SGSN ASN

RNC R1

UTRAN
Tarjeta 3GPP Tarjeta Wimax

UE

FIGURA 9.1
Arquitectura de interconexión Wimax-3GPP.
194 Manual del subsistema multimedia fP (fM£)

para que las implementaciones IMS sean libres de combinar o dividir dichas
funcionalidades en diferentes equipos físicos.
Otras entidades son la función de control de la pasarela de medios (MGCF) y la
pasarela de medios IMS (IMS-MGW), que son responsables de la señalización de
control y del flujo de medios. El controlador de la función de recursos de medios
(MRFC) realiza el procesamiento de los flujos de medios a través del procesador de
la función de recursos de medios (MRFP) correspondiente. Un elemento clave de la
red UMTS es el servidor de abonado doméstico (HSS), similar al registro de
localización doméstico (HLR) de una red del sistema global de comunicaciones
móviles (GSM): una base de datos centralizada que almacena información sobre la
autorización y el perfil del usuario. Además, los servidores de aplicaciones (AS)
pueden conectarse al IMS para prestar servicios avanzados. Hay que tener en cuenta
que los equipos de usuario (UE) acceden al IMS a través de la red de acceso
radioeléctrico terrestre UMTS (UTRAN), que se encarga de proporcionar acceso a
las estaciones móviles y gestionar la movilidad de los terminales. Los principales
protocolos de esta arquitectura son SIP, COPS (Common Open Policy Service) y
DIAMETER [5].

Tecnología WLAN
La tecnología de radio WLAN proporciona un ancho de banda superior al de
cualquier tecnología celular. Los estándares LAN inalámbricos más avanzados (protocolos
IEEE 802.11 g/e/n e HiperLAN/2) ofrecen un rendimiento máximo de más de 100
Mb/s operando en una banda ISM libre de licencia. Existen dos tipos de arquitecturas
WLAN: ad hoc y basada en puntos de acceso. En la arquitectura ad hoc, la red se
basa en la comunicación de igual a igual entre nodos, sin utilizar ninguna
infraestructura adicional. Los mecanismos de enrutamiento permiten enviar paquetes
entre nodos sin necesidad de proporcionar conectividad directa. En la arquitectura
basada en puntos de acceso, más popular, hay un tipo especial de nodo (punto de
acceso) que proporciona conexión a los nodos dentro de su alcance. Los puntos de
acceso están interconectados, a veces mediante una infraestructura cableada
denominada red de retorno. La WLAN proporciona movilidad a los usuarios, en el
sentido de que pueden cambiar de ubicación (incluso durante una sesión de datos
establecida) sin romper la conexión ni cambiar la configuración de la capa IP. Se
pueden tener en cuenta varios niveles de movilidad: picomovilidad (dentro del
alcance del mismo punto de ), micromovilidad (cambio entre puntos de acceso, pero
dentro de la misma red inalámbrica) y macromovilidad (más allá del alcance de la
WLAN, lo que requiere mecanismos de movilidad en niveles superiores, como IP
móvil).
Sin embargo, el medio inalámbrico presenta algunas desventajas. En primer lugar,
aunque el rendimiento alcanzado por las WLAN es comparable al de una LAN
habitual (hasta decenas de megabits por segundo con los sistemas actuales), el nivel
de calidad de servicio proporcionado (en términos de pérdidas de paquetes y ancho
de banda) es inestable y depende en gran medida del entorno de transmisión. Es
necesario implementar mecanismos especiales de reserva de QoS que se adapten a
estos problemas. En segundo lugar, el uso de una difusión
fnternetworking de redes 3GPP y WLAN y Wimax 195

medio al que puede acceder cualquiera con un cómodo dispositivo WLAN implica
un riesgo de seguridad mayor que en otras tecnologías de radio (por ejemplo, 3GPP
UTRAN).
En IEEE 802.11e, la EDCF (función de coordinación distribuida mejorada)
admite ocho prioridades diferentes, que a su vez se asignan a cuatro AC (categorías
de acceso). Las prioridades 0-2 (AC 0) están diseñadas para el servicio de mejor
esfuerzo. La prioridad 3 (AC 1) está diseñada para aplicaciones de sondeo de vídeo,
las prioridades 4 y 5 (AC 2) están diseñadas para aplicaciones de vídeo, y las
prioridades más altas, 6 y 7 (AC 3), están diseñadas para aplicaciones de voz [11].

Tecnología Wimax
Wimax es el sistema de acceso inalámbrico de banda ancha (BWA) diseñado
principalmente para redes inalámbricas de área metropolitana (WMAN). En general,
se cree que Wimax y WLAN pueden utilizarse como un potente complemento de
3G/UMTS. 3G/UMTS ofrece las ventajas de una cobertura de área amplia,
movilidad total, seguridad integral, itinerancia e integración total con los sistemas de
carga. Por otro lado, Wimax combinado con 3G ofrecerá un servicio de datos a alta
velocidad además del servicio de voz original en zonas de gran afluencia y, a
continuación, suministrará banda ancha móvil para todo el mundo en cualquier
lugar, sea cual sea la tecnología y el modo de acceso. IEEE
802.16 especifica un protocolo WMAN que permite una alternativa inalámbrica
para el acceso de banda ancha de "última milla", así como proporcionar el backhaul
para los hotspots 802.11. La posterior norma 802.16d admite aplicaciones de baja
latencia, como voz y vídeo, y proporciona conectividad de banda ancha sin
necesidad de línea de visión directa entre el terminal y la estación base; 802.16e
añade movilidad nómada para mejorar el rendimiento. Sin embargo, no se espera la
plena comercialización de la tecnología Wimax antes de 2007.
La Fig. 9.2 muestra la relación entre Wimax y otras tecnologías inalámbricas. El
portador de red Wimax consta del portador inalámbrico y del portador de
transmisión IP. El primero proporciona un servicio de acceso inalámbrico mediante
el mecanismo IEEE 802.16; el portador IP despliega servicios diferenciados
(DiffServ), MPLS, etc. para garantizar la QoS. El modelo de red Wimax se
compone de las siguientes entidades de red: terminal de usuario móvil, ASN (red de
servicio de acceso), CSN (red de servicio de conectividad), terminal de usuario que
incluye agentes de aplicación y MSS (estación móvil de abonado). El agente de
estrategia de QoS se encuentra en la CSN, y la ASN sirve de servidor de estrategia.
La solicitud de QoS es inicializada por el CSN; posteriormente, el ASN implementa
la negociación de QoS de acuerdo con la información del usuario y la estrategia de
QoS predefinida. La ASN consta de dos entidades funcionales de QoS: SFM
(gestión de flujo de servicio) y SFA (autorización de flujo de servicio). SFM se
encarga de la gestión del flujo de servicios 802.16 y del control de acceso, mientras
que SFA responde de la negociación y autorización de la QoS. El CSN está
compuesto por el servidor de aplicaciones, el agente de estrategia y el servidor
AAA. El modelo de red de Wimax se muestra en la Figura 9.3.
196 Manual del subsistema multimedia fP (fM£)

Movilidad/Alcance

Alta velocidad
(vehículo) HSDPA/HS
3G/UMTS
UPA

Peatón (a pie) Wimax

GSM/GPRS

Fijo

UWB
IEEE 802.11
0.1 1 10 100 Velocidad de datos del usuario
Bluetooth
(Mbps)

FIGURA 9.2
Relación de Wimax y otras tecnologías inalámbricas.

CSN

Aplicación
Servid Servidor AAA
or

Agente de
estrategia

R3 R3

SFA

Servidor de
SFM
SFM ASN
estrategia
Acceda a
Acceda Recursos
Contorl
a
Controlar R6 Gestión

MSS
(Aplicación
Agente)

FIGURA 9.3
Modelo de red de Wimax.
fnternetworking de redes 3GPP y WLAN y Wimax 192

Arquitectura de Internetworking y niveles de Internetworking

Dos modos de interconexión
Existen dos métodos para que las redes WLAN/Wimax interactúen con otras redes
inalámbricas: "loose couple" y "tight couple". Hay pocos cambios entre el
acoplamiento débil y las redes existentes; WLAN/Wimax utiliza el servidor AAA de
la red 3GPP, y los flujos de datos no pasan por la red central de 3GPP. El método
garantiza la independencia de la red WLAN/Wimax; sin embargo, da lugar a una
elevada latencia de traspaso entre dos redes. (Xiao [11] investigó el traspaso entre
WLAN y UMTS; los resultados medios de latencia de traspaso para pareja suelta y
pareja estrecha son de 400 y 150 ms, respectivamente). Por tanto, no es adecuado
para servicios en tiempo real.
En el modo tight-couple, los flujos de datos de Wimax tienen que pasar por el
RNC (controlador de red radioeléctrica) y la red central de 3GPP, por lo que cada
una de las redes existentes debe modificar sus protocolos, interfaces y servicios para
cumplir los requisitos del internetworking. La BS de Wimax se conecta con el RNC
del nodo de soporte (SGSN) de WCDMA (acceso múltiple por división de código
de banda ancha) o del ser- vicio GPRS (servicio general de radio por paquetes)
directamente. La ventaja de este modo es que reduce la latencia del traspaso y
garantiza un traspaso sin interrupciones. Si las redes 3G y WLAN/Wimax
pertenecieran a operadores diferentes, la integración sería problemática para la
apertura de la interfaz de red. En la figura 9.4 se muestran las arquitecturas de los
dos modos de internetworking.

Arquitectura central basada en IMS

Como se ha descrito en la sección anterior, WLAN/Wimax se utiliza habitualmente
para transportar paquetes IP. Por tanto, la interconexión 3GPP-WLAN/Wimax debe
construirse sobre el protocolo IP y no limitarse a ninguna tecnología WLAN/Wimax
específica. Tomando Wimax como ejemplo de red, la Figura 9.1 presenta la
arquitectura de referencia de internetworking y los puntos de referencia apropiados
utilizados en este capítulo, mostrando las interfaces de señalización y datos entre
ambas redes. La figura también muestra el proxy I-CSCF como punto de entrada de
señalización en la interconexión entre IMS y Wimax, de acuerdo con la definición
del papel del CSCF 3GPP en la referencia 3.
El punto de referencia Wu sigue siendo el definido en la referencia 1 y se refiere al
establecimiento y desmantelamiento del túnel entre el SMS y la PDG (pasarela de
paquetes de datos) adecuada, así como a la transmisión de paquetes de datos de
usuario a través de este túnel. Las funcionalidades de la PDG se describen
detalladamente en la referencia 1.
El punto de referencia Wa está dedicado a transportar mensajes AAA procedentes
del SMS entre los clientes AAA ubicados en la red de acceso Wimax y el servidor
AAA 3GPP. Un proxy/servidor AAA debe estar ubicado en la CSN para
proporcionar claves para la operación IP móvil dentro de la red Wimax.
198 Manual del subsistema multimedia fP (fM£)

UE
RNC SGSN GGSN
Nodo B

UE

Servidor AAA UMTS

Wimax BS
SS
SS
Pareja Suelta
UE

RNC SGSN GGSN

Nodo B
UE

Servidor AAA UMTS

Wimax BS

SS
SS
Tight Couple

FIGURA 9.4
Pareja suelta y pareja apretada de internetworking.

Niveles de Internetworking
Los modos de interconexión indicados en la sección anterior proporcionan la
arquitectura de interconexión disponible. Además, es necesario definir diferentes
niveles de interconexión para representar diferentes capacidades operativas. Estos
niveles son adecuados para cualquiera de los modos de interconexión.
Se han tenido en cuenta seis niveles de interconexión entre la WLAN y el 3GPP,
así como las capacidades operativas de cada uno de ellos, basándose en los niveles
de interconexión descritos en la referencia 1. La interconexión no se limita a entre el
3GPP y la WLAN; la interconexión también se produce entre el 3GPP y otras
tecnologías de acceso inalámbrico basadas en IP. Para mantener la coherenciala
interconexión con redes Wimax se basará en el mismo modelo, que se muestra en la
Tabla 9.1.
El 3GPP ha incluido los tres primeros niveles en la versión 6, y los dos últimos se
desarrollarán en futuras versiones. El primer nivel es el más sencillo e incluye
facturación común (el cliente recibe una sola factura por el uso de los 3GPP y Wimax) y
atención al cliente común (el usuario no tendrá que preocuparse de qué plataforma
ha provocado la necesidad de consultar al servicio de atención al cliente) y no tiene
ningún impacto en la arquitectura 3GPP o Wimax. Al abonado se le cobrará en la
misma factura el uso de los servicios 3GPP y Wimax, y la atención al cliente se
garantizará independientemente de la plataforma de conexión.
fnternetworking de redes 3GPP y WLAN y Wimax 199

TABLA 9.1
3GPP-WLAN/Wimax Internetworking Escenariosa

Nivel Nombre Común 3GPP- Acceso a Acceso a Acceso a Acceda a

facturación basado en 3GPP PS 3GPP PS 3GPP PS al 3GPP
y acceda a servicios servicios sin costuras CS-
común control sin con servicios basado en
cliente y continuidad continuidad servicios
atención tarificació
n del acceso

1 Facturación *
común y
atención al
cliente
común

2 3GPP * *
control de
acceso y
tarificación
del acceso
basados en
sistemas

3 Acceso a * * *
3GPP IMS-
servicios
basados

4 Continuidad * * * *
del servicio

5 Servicios * * * * *
ininterrumpido
s
6 Acceso a * * * * * *
3GPP CS
servicios

a Basado en la Tabla 3 de TR 22.934.

El segundo nivel (control de acceso y tarificación basados en el sistema 3GPP)

incluye el uso de los procedimientos de acceso 3GPP (incluyendo autenticación y
autorización) para usuarios Wimax dentro del dominio 3GPP. Además, los nodos
Wimax utilizan los sistemas de tarificación UMTS para la generación de registros de
datos de tarificación (CDR). Un abonado puede utilizar la red de acceso Wimax para
acceder, por ejemplo, a Internet, pero las operaciones AAA son gestionadas por la
plataforma 3GPP. El tercer nivel extiende los servicios IMS al Wimax, aunque es
una cuestión de implementación si se proporcionan todos los servicios o sólo un
subconjunto de ellos. Este escenario carece de continuidad de servicio, por lo que el
usuario tiene que restablecer la sesión en la nueva red de acceso. La continuidad se
considera en este contexto como la capacidad de mantener una sesión de servicio
activa al pasar de una red de acceso a otra (por ejemplo, entre Wimax y 3GPP
200 Manual del subsistema multimedia fP (fM£)

UTRAN) a nivel de señalización, sin tener en cuenta un problema de continuidad

relacionado con el nivel de transporte, como el ancho de banda o la pérdida de
paquetes.
El tercer nivel permite al operador ampliar los servicios basados en PS del sistema
3GPP a la red Wimax. En este escenario, un abonado 3GPP autenticado puede
acceder a los servicios 3GPP PS a través de una red de acceso Wimax mediante la
interconexión con su PLMN 3GPP (caso de no itinerancia) o con una PLMN 3GPP
visitada (caso de itinerancia).
Los tres últimos niveles no están contemplados por el 3GPP en la versión 6 y
podrían desarrollarse en futuras versiones. El cuarto nivel introduce continuidad del
servicio, como se describe en el párrafo anterior, aunque el proceso de traspaso
puede ser perceptible para el usuario (debido a pérdidas de datos o retrasos). El
quinto escenario proporciona una continuidad sin fisuras, sin interrupción
perceptible del servicio mayor que la percibida en los traspasos intra-3GPP. La
necesidad de una prestación de servicios sin interrupciones podría incluir cuestiones
relacionadas con el nivel de transporte en este nivel, que queda fuera del ámbito de
este capítulo.

Extensiones de SIP relacionadas con Internetworking

En esta sección se analizarán las extensiones SIP contenidas en la especificación 3GPP. Nos
centraremos principalmente en las cuestiones de la garantía de calidad de servicio y
la provisión de AAA.

Garantía de calidad de servicio

Debido a las diferencias en el ancho de banda de la red, ofrecer a los usuarios un
nivel constante de servicios no es factible. El objetivo de una garantía de QoS es
ofrecer una calidad de servicio adecuada en la dada, de acuerdo con el perfil de QoS
del usuario y el requisito de la aplicación. La garantía de QoS implica la tarea de
asignar parámetros de QoS desde la P-CSCF, el nodo de soporte GPRS de pasarela
(GGSN), el PDF, la negociación de QoS y el mecanismo de reserva de recursos.
UMTS define cuatro clases de servicios QoS basados en diferentes requisitos de
aplicación: conversacional, streaming, interactivo y back-ground. Wimax también
define cuatro clases de QoS: UGS (unsolicited grant ser- vice), real-time polling
service (rt-PS), non-real-time polling service (nrt-PS), y BE (best effort). Según el
escenario de la aplicación, el mapeo de clases de QoS puede implementarse de
acuerdo con la Figura 9.5 [12]. La negociación de la QoS entre pares de sesión (para
determinar qué códec concreto se utiliza para cada medio) se lleva a cabo utilizando
el modelo de oferta/respuesta SIP [2], en el que cada par de sesión ofrece sus
capacidades de QoS utilizando descripciones del protocolo de descripción de sesión
(SDP) en el cuerpo del mensaje.
Tenga en cuenta que la señalización de sesión SIP y la asignación efectiva de
recursos QoS
(por ejemplo, el protocolo de datos de paquetes GPRS [PDP] o DiffServ) es
independiente. Son posibles mecanismos de filtrado basados en descripciones SDP,
ya sea en función de la política local (mediante el uso de COPS) o del perfil de usuario. El
protocolo COPS ha sido
fnternetworking de redes 3GPP y WLAN y Wimax 201

WLAN UMTS Wimax

AC3(Audio) Conversación UGS

AC2(Vídeo) Streaming Rt-PS

AC1(Sonda de vídeo) Interactivo Nrt-PS

AC0(BE) Fondo BE

FIGURA 9.5
Asignación QoS de UMTS y WLAN/Wimax.

definido en el contexto del grupo de trabajo RAP (protocolo de asignación de

recursos) del Grupo de Tareas de Ingeniería de Internet (IETF) como un medio para
soportar el control de políticas en un entorno IP QoS. El protocolo COPS ofrece la
oportunidad de combinar el control de políticas, la señalización QoS y el control de
recursos en un marco unificado. El 3GPP ha acordado provisionalmente el uso del
protocolo COPS-PR como protocolo de comunicación en la interfaz Go. El
protocolo COPS-PR es una versión ampliada del protocolo COPS básico para
apoyar la provisión de políticas. El modelo de arquitectura subyacente consiste en
servidores de políticas que administran la red y comunican las decisiones a los
clientes de políticas (por ejemplo, elementos de red) en los que se aplican las
decisiones de políticas (denominados puntos de aplicación de políticas [PEP]).
Mientras que un elemento lógicamente centralizado actúa como servidor de
políticas, se denomina punto de decisión de políticas (PDP). El PEP realiza
peticiones al PDP para el control de admisión relacionado con la política, y el PDP
proporciona las decisiones políticas.
En nuestra arquitectura de internetworking, la función de control de políticas
(PCF) desempeña el papel de la PDP [5]. La PCF puede ser un componente lógico de una P-
CSCF o una entidad independiente. Dado que el GGSN se encuentra en la ruta de
datos, es adecuado para actuar como PEP. El repositorio de políticas puede ser una
entidad externa al PCF. Es probable que para este fin se utilice un almacén de datos
compatible con el protocolo ligero de acceso a directorios (LDAP). La Figura 9.6
muestra la arquitectura de la interconexión de redes con QoS basada en COPS. El
PCF se comunica con el GGSN a través de la interfaz Go. Permite dos modos de
funcionamiento. En el push, la PCF inicia la comunicación con el PEP y envía la
decisión al GGSN. En el modo pull, el GGSN inicia la comunicación con el PCF
para solicitar una decisión para un flujo IP concreto. Durante el establecimiento de
una sesión SIP, una P-CSCF es el primer punto de contacto en el dominio IMS para
un UE. Por lo tanto, es el lugar natural para autorizar el uso de los recursos de red,
como el ancho de banda solicitado por el UE. Los requisitos de calidad de servicio
del equipo de usuario se incluyen en la descripción SDP de un mensaje SIP. Además
de los requisitos de QoS, el PCF también examina las direcciones IP de origen y
destino y los números de puerto en su toma de decisiones. El PCF que gestiona el
dominio local consulta las reglas de política almacenadas en LDAP. A continuación,
genera una autorización
202 Manual del subsistema multimedia fP (fM£)

(PDP)
Señalización Señalización
SIP P-CSCF SIP
PCF

LDAP

COPS/G o I nterfaz
Política de
almacenamient
UTRAN
o
Enlace de A otra red IMS
datos GGSN
Enlace de
datos
(PEP)

FIGURA 9.6
Arquitectura de internetworking con QoS basada en COPS.

token que identifica de forma única la sesión SIP a través de múltiples contextos
PDP terminados por un GGSN. El equipo de usuario obtiene un testigo de
autorización de la P-CSCF a través de un mensaje de señalización SIP durante la
configuración de la sesión, de modo que el equipo de usuario pueda utilizarlo para
identificar los flujos de sesión asociados al PEP en el GGSN en las transmisiones
posteriores de paquetes IP. Este token se utiliza para proporcionar el mecanismo de
enlace que asocia el portador de contexto PDP al flujo IP. Examinando este token
recibido del GGSN, el PCF puede dirigir al GGSN para que admita o abandone el
flujo. La función del PEP es garantizar que sólo los flujos IP autorizados puedan
utilizar los recursos de red que les han sido reservados y asignados, autorizando así
el establecimiento de una sesión a nivel de política. En el IMS, la señalización de
establecimiento de sesión está separada de la ruta de datos de la sesión.
El PCF reside en la ruta de señalización, mientras que el GGSN reside en la ruta
de datos. Para establecer la ruta de datos de la sesión, el GGSN debe reservar el
nivel adecuado de recursos QoS. Para vincular la autorización a nivel de política a la
correspondiente reserva de recursos de QoS, el PEP, el componente del GGSN debe
validar la solicitud de reserva con el PCF. La interfaz Go facilita la comunicación
necesaria entre el PCF y el PEP para realizar esta validación. En la arquitectura SIP,
las peticiones de QoS son gestionadas en la frontera de la red central por los routers
de borde (ERs) que implementan todos los mecanismos necesarios para realizar las
decisiones de control de admisión (posiblemente con la ayuda de un broker de ancho
de banda [BB]) y la función de policía. El protocolo COPS se utiliza para realizar
solicitudes de reserva de QoS a los puntos de acceso QoS (es decir, a los ER de la
red). En este escenario se supone que los clientes SIP utilizan un servidor proxy SIP
predeterminado en su dominio tanto para las llamadas salientes como para las
entrantes. Por tanto, los servidores SIP participan en el intercambio de mensajes
entre los clientes y pueden añadir (y leer) información relacionada con la calidad de
servicio en los mensajes SIP. Los servidores SIP negociarán los parámetros de QoS
entre ellos e interactuarán con los mecanismos de QoS de la red. Para la
configuración
fnternetworking de redes 3GPP y WLAN y Wimax 203

Corredor de ancho de banda (BB)

Usuario que llama Servidor Q-SIP Usuario que llama Servidor Q-SIP

Terminal SIP
Red Diffserv

Terminal SIP
Llamada Usuario
INVITE Llamada al usuario ER INVITE
INVITE ER
180 timbres 180 Ringing 180

200 OK
Policías REQ Policías REQ

Policías DEC Policías DEC

200 OK
Policías REQ Policías REQ
Policías
200 OK Policías DEC
DEC

ACK ACK ACK

Corriente Traffic

FIGURA.9.7
Flujo de señalización Q-SIP.

de una comunicación QoS bidireccional, hay que solicitar dos reservas diferentes
para la red QoS. El servidor SIP mejorado se denomina servidor Q- SIP (servidor
SIP habilitado para QoS). El flujo de señalización de Q-SIP se muestra en la Figura
9.7.
La reserva de recursos que proporciona QoS para aplicaciones IMS debe
manejarse con cuidado porque no hay control de políticas entre IMS y Wimax. Se
recomienda utilizar estas dos soluciones para la gestión de la QoS:

Recursos preconfigurados: Los recursos QoS necesarios para la aplicación

IMS proporcionada a un abonado Wimax deben preconfigurarse en la red.
Esto debería proporcionar la capacidad de priorizar (por ejemplo, el tráfico
de voz sobre IP [VoIP] frente a otro tráfico).
Reserva activada por el cliente: el UE (MS) es responsable de la reserva y
cancelación de recursos de QoS. La reserva podría ser activada por una
subcapa de convergencia de Wimax o por señalización de QoS en la capa
IP (p. ej., protocolo de reserva de recursos [RSVP]). El modelo de
tarificación debe tener en cuenta las reservas colgadas causadas por
llamadas colgadas y que no han podido ser liberadas por la red IMS. En el
peor de los casos, la cancelación de recursos sólo se produce por la
desconexión de la EM.
204 Manual del subsistema multimedia fP (fM£)

Inicio
HSS
Interfaz Cx basada en Diameter
Los proxies SIP obtienen información S-CSCF
de autorización y autenticación

I-CSCF

GGSN
SGSN
RAN

Servidores proxy
Visitado SIP
Interfaces basadas en
SIP
FIGURA 9.8
Arquitectura de red IMS con AAAC.

Disposición AAA
En el caso de la itinerancia de redes heterogéneas, las redes de origen deben poder
validar la existencia de acuerdos de itinerancia cuando un usuario accede desde una
red visitada, de modo que la identidad de la red visitante se conozca durante el
registro en la red de origen.
En la figura 9.8 se muestra la arquitectura de un IMS habilitado para AAAC.
Desde la perspectiva de la red 3GPP, Wimax también se considera actualmente
como una red no confiable, por lo que es entonces más necesario garantizar el
mismo nivel de seguridad a un usuario para el acceso Wimax a través de esta red de
internetworking que el de un usuario que accede a los servicios 3GPP. Es necesario
que existan relaciones adecuadas de seguridad y confianza entre el servidor AAA
3GPP y la red de acceso Wimax para soportar la transferencia adecuada de material
de seguridad, autorización y contabilidad. La solución técnica elegida por el 3GPP
para la seguridad del acceso 3GPP Wimax consiste en establecer un túnel entre el
equipo de usuario y la pasarela 3GPP situada en la frontera de la PS 3GPP. Aquí
sólo se consideró el caso 3GPP de no itinerancia (acceso a la PLMN 3GPP de origen a
través de la red de acceso Wimax), porque los cambios que implica el caso de
itinerancia (cuando la red de acceso Wimax se conecta con una PLMN 3GPP
visitante) no afectan a la red de acceso Wimax. Además, la notificación de eventos
SIP
[2] se utiliza para permitir a la red dar de baja a usuarios o forzar el nuevo registro
de terminales móviles.
En cuanto a la autorización, la cabecera SIP P-media-authorization se utiliza en el
establecimiento de sesión, junto con COPS entre la P-CSCF y el GGSN (como se
muestra en la Figura 9.1), para garantizar el control de recursos y evitar que usuarios
no autorizados utilicen recursos por los que no están pagando. El protocolo
DIAMETER [4,10] se utiliza para registrar CDRs en el subsistema de tarificación
UMTS. Además, las cabeceras SIP P-charging-vector y P-charging-func- tion-
address se utilizan para distribuir las direcciones IP de los sistemas de tarificación.
fnternetworking de redes 3GPP y WLAN y Wimax 205

Ubicación
AAAH
Base de
datos
Cx HSS (3GPP)

6. Solicitud AAA 7. AAA Resp 3. AAA Resp

4. AAA Resp
Punto central SIP
Proxy SIP de anclaje 5. SIP Registro de Contacto - SCPC
(S-CSCF) (I-CSCF)
9. 200 OK 2. Registro SIP
Punto SIP de
Contacto visitado - SPCV
(P-CSCF)
10. 200 OK 1 . Registro SIP

Cliente SIP

FIGURA 9.9
Flujo de señalización SIP de la red IMS habilitada para AAA.

elementos entre nodos IMS. Como se muestra en la Figura 9.8, el HSS contiene
perfiles de subcriba, servicio y seguridad relacionados con los proxies SIP. Cuando
el SCPC (punto central de contacto SIP; aquí, la I-CSCF actúa como SCPC) recibe
el mensaje SIP REGISTER, emitirá un mensaje AAA al servidor AAA de origen
(AAAH). El mensaje AAA puede incluir información del mensaje SIP. El flujo de
señalización correspondiente se muestra en la Figura 9.9. Además, la infraestructura
AAA debe ser capaz de distribuir (push o pull) perfiles de suscriptor, servicio y
seguridad a los servidores SIP relevantes basándose en políticas. La AAAH debe ser
capaz de actualizar la ubicación del servidor SIP asignado para el usuario que realiza
el registro SIP en la base de datos de ubicaciones, iniciar la baja del usuario y
distribuir la información relevante al SCPC para la selección del proxy SIP de
anclaje adecuado para el usuario.

Seguridad
El objetivo de seguridad de IMS es proporcionar integridad y confidencialidad a los
mensajes de señalización salto a salto entre nodos [6]. El mecanismo clave para
lograr este propósito es el protocolo de carga útil de seguridad encapsulada (ESP)
IPSec. No debería haber ningún impacto en la señalización SIP debido a su
naturaleza de protocolo de capa de aplicación. Un requisito de seguridad adicional
es la provisión de un mecanismo de ocultación de topología (THIG) para los
operadores de red que deseen implementarlo. La ocultación debe incluir la
estructura de la red y las direcciones IP de los nodos. Para ello, la I-CSCF actúa
como proxy de ocultación SIP, ofuscando la información sensible. La seguridad de
acceso de IMS incluye principalmente la autorización y la protección de los mensajes
SIP. La autorización de IMS adopta la autorización
206 Manual del subsistema multimedia fP (fM£)

mecanismo de autenticación IMS y acuerdo de claves (AKA). Además, la encriptación y la

protección de la integridad de los mensajes SIP se componen de las cinco asociaciones
de seguridad siguientes: (1) autorización mutua de UE y S-CSCF; (2) asociación de
seguridad de UE y P-CSCF, que se implementa mediante IPSec; (3) asociación de
seguridad de la interfaz Cx; (4) asociación de seguridad de nodos SIP de redes diferentes; y
(5) asociación de seguridad de nodos SIP cuando la P-CSCF se encuentra en la red
de origen.

Red inalámbrica cognitiva reconfigurable

La próxima generación de redes inalámbricas, prevista por los recientes avances en
tecnologías de radio cognitiva (RC), ajustará inteligentemente su configuración a los
cambios en el entorno de comunicación. La reconfigurabilidad está llamada a ser
una faceta importante en el cambiante mundo de las comunicaciones móviles e
inalámbricas, a través de la cual tecnologías como la radio cognitiva se ven
enormemente facilitadas. En la próxima generación de redes inalámbricas
reconfigurables, coexistirán en la misma banda de frecuencias varias redes de acceso
inalámbrico que utilizarán CR e internetworking mediante IMS.
La radio cognitiva ha surgido como una tecnología prometedora para resolver el
problema de la utilización injusta del espectro mediante el uso compartido dinámico
del mismo. Las redes de radiocomunicación cognitiva se están diseñando para
soportar redes eficientes desde el punto de vista del espectro, en las que los
dispositivos se adaptarán dinámicamente a sus entornos operativos ampliando las
tecnologías desarrolladas para radios definidas por software (SDR). La idea
principal de la radio cognitiva es detectar periódicamente el espectro radioeléctrico,
detectar de forma inteligente la ocupación y el uso del espectro y, por último, tomar
la decisión de ajustar sus parámetros radioeléctricos para comunicarse de forma
oportunista en los huecos de espectro del sistema primario. Los dos objetivos de la
RC son maximizar la transmisión del sistema secundario y garantizar la
interferencia con el sistema primario bajo restricciones [12].
Además, en las redes inalámbricas cognitivas, pueden funcionar en la misma
banda de frecuencias distintos tipos de sistemas de acceso inalámbrico, con un como
principal y otros como secundarios. La interconexión de estos sistemas y la
convergencia necesitan el soporte de IMS y la señalización correspondiente. Sin
embargo, cómo integrar las entidades IMS y las entidades funcionales cognitivas en
la arquitectura de internetworking es realmente una gran cuestión. Además, hay
muchos problemas en las arquitecturas por las diferencias de los distintos sistemas.
La reconfigurabilidad [13] se considera un factor clave más allá de la SDR y la
CR que reúne tecnologías para el acceso dinámico al espectro, encapsulando el
control de extremo a extremo y el apoyo a la gestión con el fin de adaptar o
actualizar el sistema, y se extiende desde el acceso y la conectividad hasta los
protocolos, aplicaciones, servicios y contenidos. El proyecto E2R (reconfigurabilidad
de extremo a extremo)
fnternetworking de redes 3GPP y WLAN y Wimax 202

Servidor de
contenidos en red

UE1

RAT1(UMTS)

UE3 UE4

RAT3(Wimax)

UE2 RAT2(WLAN)

UE5

FIGURA 9.10
Arquitectura de red de un sistema reconfigurable.

financiado por la Unión Europea, que se ocupa de todo el conjunto cuestiones

relacionadas con los sistemas de radio reconfigurables [14].
Las redes cognitivas son capaces de adaptarse continuamente a las condiciones
cambiantes del entorno y a las necesidades de los usuarios. La adaptación se realiza
principalmente mediante la autogestión o, en otras palabras, de acuerdo con los
principios de la informática autónoma y suele implicar el aprendizaje automático. La
reconfiguración de la propia infraestructura del sistema puede afectar a más de las
capas de red tradicionales de la pila de protocolos, es decir, las capas de middleware,
presentación y aplicación, además de las capas PHY, MAC (control de acceso al
medio), LLC (control de enlace lógico), red y transporte [15,16]. Por ejemplo, la
reconfiguración en las capas PHY/MAC incluye la selección de los parámetros PHY
de transmisión más apropiados (incluyendo modulación, codificación de canal,
velocidad de transmisión, etc.) y el espectro para la operación, mientras que la
reconfiguración en las capas de middleware y aplicación incluye la selección de las
políticas más apropiadas para controlar la reconfiguración del elemento de red y la
tecnología.
El 3GPP ha establecido los requisitos para la evolución a largo plazo de la red de
acceso radioeléctrico (RAN), incluido el soporte de múltiples tecnologías de acceso
radioeléctrico (RAT), una mayor eficiencia espectral, mayores velocidades de datos
con latencias reducidas y una división funcional flexible entre la RAN y la red
central [17]. Por otro lado, el IEEE ha estado desarrollando redes de acceso
inalámbricas personales (por ejemplo, 802.15.3a, 802.15.4), locales (por ejemplo,
802.11a/g/n), metropolitanas (por ejemplo, 802.16a/d/e (WiMAX), 802.20) y
regionales (por ejemplo, 802.22), con recientes innovaciones en la tecnología de
acceso radioeléctrico (RAN).
208 Manual del subsistema multimedia fP (fM£)

Servicio y
Aplicación

Usuario Cognitivo
Capa de red Plano de gestión
Ciclo
de
salida
Control
Capa MAC Ajustar
de
potencia
Gestión del Análisis de la
espectro escena Detección Mundo exterior
radiofónica
Capa PHY Ajustar Estimación
Interior
de canales
Ciclo
cognitivo

FIGURA 9.11
Arquitectura de capa básica y funciones para dispositivos cognitivos con dos ciclos cognitivos.

propuestas de normas orientadas a SDR (P1900) y consideraciones de

interoperabilidad para el traspaso entre redes heterogéneas. Tomando como ejemplo
las redes 3GPP, WLAN y Wimax, en la figura 9.10 se describe la arquitectura
general de red de un sistema reconfigurable de extremo a extremo.
En la zona de solapamiento de diferentes RAT, el UE puede elegir una de las
RAT y pasar de una RAT a otra sin problemas.
Además, añadimos un plano vertical cognitivo y de gestión del usuario al modelo
de capas tradicional, que se muestra en la Figura 9.11. En el plano de gestión
cognitiva, varias funciones clave, como la detección del espectro, el análisis de la
escena radioeléctrica, el control de potencia, la estimación del canal y el ajuste de
parámetros, se indican mediante entidades de función separadas. El ciclo cognitivo
interno combinado con el ciclo externo implementa la tarea cognitiva.

Arquitectura de interconexión de redes inalámbricas reconfigurables

A diferencia de la Figura 9.10, que muestra la arquitectura de capas del dispositivo,
la Figura 9.12 describe la arquitectura desde el punto de vista de la red global de
trabajo en Internet y los componentes funcionales. Hay cuatro entidades funcionales
definidas en la entidad de gestión cognitiva propuesta: entidad de gestión del
espectro, entidad de gestión de políticas, entidad de gestión de la movilidad y
entidad de configuración de radio. Como indican sus nombres, cada subentidad se
encarga de su propia tarea y operan juntas para implementar el acceso inalámbrico
reconfigurable y cognitivo:

La entidad de gestión del espectro (EME) se encarga de la detección del

espectro y la asignación de recursos espectrales.
fnternetworking de redes 3GPP y WLAN y Wimax 209

Señalizaci PDG
3GPP
ón Centro de
Datos carga y AAA
Aplicación HSS
Servidor
Wimax CSN
IMS
S-CSCF
Otros IMS I-CSCF
Redes
P-CSCF SFM SFA

Router IP Wimax ASN

Entidad de
BM-SC GGSN gestión
SGSN cognitiva Wimax BS
PME RCE

RNC
MME PYM
UTRAN E

UE

FIGURA 9.12
Arquitectura de interconexión Wimax-3GPP reconfigurable. GGSN: nodo de soporte GPRS de pasarela; SGSN:
nodo de soporte GPRS de servicio.

La entidad de configuración radioeléctrica (RCE) es responsable de la

configuración en segundo plano de los parámetros radioeléctricos de
acuerdo con las políticas predefinidas y los resultados de la detección del
espectro.
La entidad de gestión de políticas (PME) almacena y negocia con otros
dispositivos radioeléctricos las políticas y estrategias de uso del espectro y
programa el recurso.
La entidad de gestión de la movilidad (MME) se ocupa de las cuestiones
provocadas por la movilidad de los usuarios, especialmente el traspaso
entre redes heterogéneas, incluida la garantía de la calidad del servicio, la
provisión de seguridad, el traspaso sin costuras y la tarificación común, así
como el servicio común.

Problemas relacionados y soluciones

Intercambio de mensajes
La red inalámbrica reconfigurable de próxima generación es una red cooperativa.
Cuanta más información sobre el entorno inalámbrico se obtenga, mejor será su
capacidad para contrarrestar el desvanecimiento inalámbrico y compartir el espectro
[18].
La interferencia detectable de diferentes bandas espectrales en el nivel físico de
radiofrecuencia (RF) da lugar a la señalización de respuesta en la capa de protocolo
de control de transferencia (TCP)/IP, normalmente como mensajes de protocolo
simple de gestión de red (SNMP) entre entidades de procesamiento cognitivo. Este
mapeo de la información del nivel físico de RF a las respuestas de la capa SNMP es
digno de mención porque proporciona una vía de retroalimentación que permite a
los dispositivos de red de radio que tienen
210 Manual del subsistema multimedia fP (fM£)

IP para comunicarse entre sí e informarse mutuamente de su entorno común de

interferencia y de las condiciones de uso del espectro. Como paso hacia la
vinculación de los ciclos de detección y respuesta de las capas física y de red, uno
de los datos más útiles que puede incorporarse a la señal interferente es la dirección
IP de la radio causante de la interferencia. Si la interferencia puede identificarse
mediante una firma de identidad, como una dirección IP, la resolución de la
coexistencia puede ser precisa y eficaz.
El mensaje de información con formato uniforme contiene una cabecera que
indica el identificador único del usuario, y el contenido del mensaje contiene la
intensidad de la interferencia, la banda, la ubicación y las bandas del espectro que se
están ocupando.
Existen dos enfoques para transmitir los mensajes de control: el centralizado y el
distribuido, que corresponden respectivamente a los modos de interconexión
estrecha y flexible. Para el reparto centralizado de mensajes, existe un servidor
central de gestión. (En la arquitectura propuesta, la tarea la realizan conjuntamente
un servidor AAA, HSS y CSCF). El servidor AAA y el HSS actúan como
cortafuegos de seguridad utilizando la gestión de claves de cifrado públicas. El UE
accede a la base de datos de compartición que contiene información importante para
los presupuestos de enlace y la coexistencia por parte de las CSCF tras el proceso de
autenticación y registro. La información es útil para las entidades de gestión
cognitiva. Por ejemplo, algunas bandas del espectro están ocupadas por el sistema
primario, la información se comparte entre los dispositivos cognitivos, y la entidad
de configuración radioeléctrica cambiará dinámicamente a otra banda e informará de
ello a la red de conexión y a otros usuarios. Tras la autenticación y el registro en el
servidor de gestión, el UE utiliza un protocolo de coexistencia para comunicarse vía
IP con otras redes y usuarios. Pueden negociar conservar franjas horarias (acceso
múltiple por división de tiempo [TDMA]), subportadoras (OFDM) o canales lógicos
(acceso múltiple por división de código [CDMA]) como canales de señalización
comunes para transmitir mensajes.
La ventaja de compartir mensajes de forma centralizada es que la información puede
porque se conoce y se puede direccionar toda la extensión de la red.
Por otra parte, no existe un servidor central de gestión en un mecanismo de
compartición distribuida, que emplea el enfoque CSMA basado en la petición de
comunicación para transmitir y compartir la información del entorno inalámbrico.

Gestión de recursos
Los altos niveles de flexibilidad de las radiocomunicaciones fomentan la
introducción de sistemas de gestión inteligentes que gestionen el conjunto completo
de recursos: los escasos recursos radioeléctricos y la limitada capacidad informática
de los equipos móviles. Estos sistemas deben observar el entorno y reaccionar de
forma inteligente a sus cambios para optimizar el comportamiento del sistema
completo de acuerdo con las políticas establecidas [19].
Las entidades de gestión cognitiva se encargan de la gestión de los recursos. La
parte de detección del espectro de una PYME escanea continuamente los entornos
informático y radioeléctrico y proporciona la información de cualquier
fnternetworking de redes 3GPP y WLAN y Wimax 211

cambio a la parte de gestión de recursos de la PME, que es el cerebro de la función

de gestión de recursos. Inicia las acciones apropiadas al RCE en función del estado
actual del sistema y de la estrategia almacenada en el PME. Cada acción modifica
los entornos informático y radioeléctrico.
En redes heterogéneas (como la escena de internetworking de la red UMTS y
Wimax), el análisis de la escena radioeléctrica revela que los recursos
radioeléctricos de UMTS están sobreutilizados, mientras que los de Wimax no. En
otras palabras, UMTS se está quedando sin recursos radioeléctricos, mientras que
Wimax puede aceptar usuarios adicionales. El ciclo informático, en paralelo,
observa que muchos terminales móviles UMTS (terminales CR que actualmente
implementan UMTS) admiten Wimax. La red informa de la disponibilidad del
software necesario para acceder a Wimax. Tras procesar estas entradas, la PYME
probablemente iniciaría las descargas de software correspondientes y la
reconfiguración de algunos terminales UMTS para convertirlos en terminales
Wimax. Basándose en las entradas de los ciclos cognitivos y en el conocimiento
acumulado, puede solicitar la reconfiguración de equipos CR seleccionados.
Independientemente de la concreta, aprende constantemente de la observación de
sus efectos. Aunque a priori pueda disponer de algunos conocimientos, es el
mecanismo de aprendizaje lo que la convierte en una entidad inteligente.

Seguridad
Para proteger la privacidad de la información en una base de datos, la autenticación
es un proceso bastante importante. Sin embargo, los marcos de autenticación de
varias tecnologías de radio, como UMTS y 802.16, son bastante diferentes entre . Para
soportar la reconfiguración radioeléctrica, es necesario idear un marco de
autenticación independiente de la radio adecuado para los sistemas de RC [20].
En nuestro modelo de red, los dispositivos CR tienen componentes de base de
datos de gestión del espectro y un servidor de gestión del espectro situado en la red.
El dispositivo CR primero detecta radios y encuentra radios candidatas. El CR
reconfigura la MAC/PHY a la seleccionada e inicia la reautenticación siguiendo el
protocolo especificado para el sistema de radio seleccionado.
En el estado actual de la recomendación, los requisitos de autenticación dependen
de cada sistema de radio y el protocolo es diferente entre los distintos sistemas de
radio. Por lo tanto, la reautenticación sigue un nuevo procedimiento de
autenticación, implica consultar un nuevo servidor AAA en una nueva red y, por lo
tanto, no permite un traspaso rápido de una tecnología de radio a otra debido a los
diferentes protocolos de autenticación. Por tanto, no podemos esperar un rápido,
aunque un dispositivo CR pueda reconfigurarse rápidamente. También debe
mantener sin problemas la autenticación (o volver a autenticarse si es necesario) a
medida que el dispositivo pasa de una red de radio a otra.
Sin embargo, las redes CR no siempre pueden predecir el siguiente sistema
radioeléctrico que se utilizará, ya que el traspaso no sólo se activa por el movimiento
de terminales, sino también por la decisión de consultar a una PYME, que gestiona
la eficiencia del espectro en la zona. Por lo tanto, las futuras redes de RC podrán
soportar simultáneamente comunicaciones paralelas utilizando diferentes sistemas
de radio. La autenticación
212 Manual del subsistema multimedia fP (fM£)

de las redes de RC no debería depender del enfoque actual para manejar entornos
radioeléctricos heterogéneos.
En referencia a la idea de Kuroda, Nomura y Trappe [20], se propone un
protocolo de autenticación para CR independiente de los protocolos de radio
subyacentes y capaz de soportar el transporte EAP (protocolo de autenticación
extensible). El protocolo asume información específica del usuario, como la
información de localización, como semilla de clave. Las claves de autenticación y
cifrado se derivan del registro histórico de localización de un terminal móvil. Las
claves se actualizan con frecuencia a medida que los usuarios cambian de posición.
La propuesta es muy adecuada para la arquitectura de red reconfigurable propuesta
para el HSS/registro de localización de visitantes (VLR) en redes 3GPP que
almacenan la localización de registro.

Conclusión
En resumen, SIP es el protocolo de señalización clave de IMS. La interconexión
entre los elementos SIP de Wimax y las CSCF de IMS es una cuestión clave para
alcanzar un alto nivel de interconexión entre Wimax y las redes 3GPP. En este
capítulo, no sólo se representa la arquitectura general de internetwork- ing basada en
IMS, sino que también se requieren algunas consideraciones adicionales en estudios
posteriores:

• Detección y selección de la red: Una vez que la EM ha detectado los ASN

disponibles y el CSN de IWU correspondiente en un área determinada, la
selección del PLMN debe realizarse de acuerdo con TS 23.234.
• Wimax ofrece una gestión de la calidad del servicio potente y flexible, que
no puede aprovecharse plenamente en la actual especificación de red
interna 3GPP-WLAN.
• La capacidad de transferencia de la red 3GPP a la red Wimax suele
denominarse niveles 4 movilidad entre sistemas) y 5 (movilidad entre
sistemas sin costura). Estos niveles están fuera del alcance de la reciente
versión, pero se abordarán en futuras versiones. Los tres últimos niveles
representan la convergencia de la red.
• Realización de una arquitectura reconfigurable, experimentos sobre el
algoritmo de intercambio de mensajes y gestión de recursos, y además
integrar cuestiones orientadas a la aplicación o aspectos de seguridad.

Agradecimientos
Este trabajo ha sido financiado por el NSFC (60432040, 60772021), el Fondo de
Investigación para el Programa de Doctorado de la Enseñanza Superior
(20060013008), y el
fnternetworking de redes 3GPP y WLAN y Wimax 213

University IT Research Center Project (INHA UWB-ITRC) Corea y apoyado en

parte por el proyecto iCHIP financiado por el Ministerio de Asuntos Exteriores
italiano. El capítulo se ha redactado basándose principalmente en la bibliografía
[21,22].

Referencias
1. 3GPP TS 23.234. 2004. Sistema 3GPP para la interconexión de redes de área local
inalámbricas (WLAN); descripción del sistema, v.6.2.0.
2. Rosenberg, J. et al. 2002. SIP: Protocolo de iniciación de sesión, IETF RFC 3261.
3. 3GPP TS 23.228. 2004. Subsistema multimedia IP (IMS), v.6.5.0.
4. 3GPP TS 29.229. 2005. Interfaces Cx y Dx basadas en el proto- colo DIAMETER, v.5.10.0.
5. Salkintzis, A. K., C. Fors y R. Pazhyannur. 2002. WLAN-GPRS integra- tion for next-
generation mobile data networks. IEEE Wireless Communication 9(5):112-124.
6. Køien, G. M., y T. Haslestad. 2003. Security aspects of 3G-WLAN internet- working. IEEE
Communication Magazine 41(11):82-88.
7. Márquez, F. G., y M. G. Rodríguez. 2005. Internetworking of IP multime- dia core
networks between 3GPP and WLAN. IEEE Wireless Communications 58-65.
8. Salsano, S., y L. Veltri. 2002. QoS control by means of COPS to support SIP- based
applications. IEEE Network marzo/abril:27-33.
9. Zhuang, W., y Y. S. Gan. Arquitectura de QoS basada en políticas en el subsistema
multimedia IP de UMTS. IEEE Network mayo/junio:51-57.
10. 3GPP TS 29.228. 2005. Interfaces Cx y Dx del subsistema multimedia IP (IM), v.5.11.0.
11. Xiao, Y. 2004. IEEE 802.11E: QOS provisioning at the MAC layer. IEEE Wireless
Communications 11(3):72-79.
12. Haykin, S. 2005. Radio cognitiva: Comunicaciones inalámbricas potenciadas por el cerebro.
IEEE Journal on Selected Areas of Communication 23(2):201-220.
13. Boufidis, Z., N. Alonistioti y L. Merakos. 2006. RSS: The reconfiguration support subsystem
for next-generation mobile networks. IEEE International Conference on Communications
4:1825-1830.
14. IST-2005-027714. Proyecto E2R II (reconfigurabilidad de extremo a extremo, fase 2).
http:// [Link]/
15. Demestichas, P., G. Dimitrakopoulos, J. Strassner y D. Bourse. 2006. Intro- ducing
reconfigurability and cognitive networks concepts in the wireless world. IEEE Vehicular
Technology Magazine 1(2):32-39.
16. Boufidis, Z., N. Alonistioti, O. Holland, K. Moessner, R. Feuillette y J. Pan. 2007. End-to-
end architecture for cognitive reconfigurable wireless networks. 16ª Cumbre de
Comunicaciones Móviles e Inalámbricas del TSI, 2007. 1-5 de julio:1-5.
17. 3GPP TR 23.882. 2007. Evolución de la arquitectura del sistema 3GPP (SAE): Informe
sobre opciones técnicas y conclusiones (versión 7), Abr. 2007.
18. Sydor, J. 2006. Mensajería y uso compartido del espectro entre redes de radio ad-hoc
cognitivas. Simposio Internacional del IEEE sobre Circuitos y Sistemas, 2006. (ISCAS
2006). Actas 21-24 de mayo de 2006: 4 pp.
214 Manual del subsistema multimedia fP (fM£)

19. Marojevic, V., V. Nemanja, X. Reves y A. Gelonch. 2007. Gestión integrada de recursos en
la radio cognitiva. 16th IST Mobile and Wireless Communications Summit, 1-5 de julio:1-5.
20. Kuroda, M., R. Nomura y W. Trappe. 2007. A radio-independent authenti- cation protocol
(EAP-CRP) for networks of cognitive radios. 4th Annual IEEE Communications Society
Conference on Sensor, Mesh and Ad Hoc Communications and Networks, 2007. (SECON
'07). 18-21 de junio, pp. 70-79.
21. Xu, F., L. Zhang y Z. Zhou.2007. Internetworking of Wimax and 3GPP net- works based on
IMS. IEEE Communication Magazine 45(3):144-150.
22. Xu, F., L. Zhang y Z. Zhou. 2008. Architecture for next-generation reconfigu- rable
wireless networks using cognitive radio. Presentado a CROWNCOM 2008.
10
fM-££F Application £erver-
fnterworking with CAMEL

Moo Wan Kim y Ryozo Ito

CONTENIDO
Introducción ....................................................................................................................... 215
Red de conmutación de circuitos GSM y servicio CAMEL ......................................... 216
Arquitectura de servicios CAMEL para el usuario IMS .................................................. 217
CAMELLO BCSM .............................................................................................................. 218
Tipos de DP ............................................................................................................... 219
Mecanismos de armado/desarmado .................................................................... 219
O-IM-BCSM ........................................................................................................................ 220
T-IM-BCSM ........................................................................................................................ 223
Datos de suscripción CAMEL.............................................................................................. 223
Operación CAMEL .............................................................................................................. 227
Solicitud de control de servicios ................................................................................ 227
Solicitud de ruta ...................................................................................................... 227
Solicitud de notificación de actos ........................................................................... 227
Interfaz Si ............................................................................................................................ 229
Solicitud de información IM-CSI .............................................................................. 229
Actualización de la información IM-CSI ................................................................... 229
Comportamiento de control de la sesión originada por el UE en IM-SSF ........................... 229
Comportamiento de control de UE que finaliza sesión en IM-SSF................................. 235
Comportamiento para conectar MRF............................................................................. 237
Enviar anuncio ........................................................................................................ 237
Interacción con el interlocutor ............................................................................... 238
Referencias .......................................................................................................................... 242

Introducción
CAMEL (customized applications for mobile network enhanced logic) es un
conjunto de normas que operan en el sistema global de comunicaciones móviles

215
216 Manual del subsistema multimedia fP (fM£)

(GSM) y dominios de conmutación de circuitos de tercera generación utilizados para

implantar diversos servicios de valor añadido, como la transferencia de llamadas y
los servicios de contestador automático. CAMEL utiliza una arquitectura separada
entre las funciones de conmutación y control de servicios, al igual que la IN (red
inteligente) en la red fija de conmutación de circuitos, lo que permite un servicio
avanzado de 800 llamadas gratuitas y VPN (red privada virtual). El 3GPP (3rd
Generation Partnership Project) ha ampliado las especificaciones del servicio
CAMEL en fases, siendo la fase 4 la normalización de las especificaciones para
proporcionar el servicio CAMEL al usuario del subsistema multimedia IP (IMS).
En la arquitectura CAMEL, la SSF (función de conmutación de servicios) realiza
las funciones de conmutación que deben implementarse en el MSC (centro de
conmutación móvil); la SCF (función de control de servicios), que realiza las
funciones de control de servicios, se implementa en la gsmSCF. El MSC y la
gsmSCF proporcionan al usuario servicios de valor añadido mediante la
comunicación a través del protocolo CAP (CAMEL application part). Por
consiguiente, es necesario interconectar la gsmSCF con la función de control de
sesión de llamada de servicio (S-CSCF) para proporcionar los servicios CAMEL del
dominio de conmutación de circuitos con los usuarios IMS. Para ello, la IM-SSF se
ha estandarizado como uno de los servidores de aplicaciones del protocolo de
iniciación de sesión (SIP) que traduce los mensajes SIP al protocolo CAP. Además,
para proporcionar servicios basados en medios a los usuarios, la gsmSCF se ha
estandarizado para controlar la MRF (función de recursos de medios) a través de la
IM-SSF.
En este capítulo se describe el funcionamiento de IM-SSF, el método diseñado
para interconectarse con la gsmSCF, el control de sesión IMS por parte de la IM-
SSF y el enfoque adoptado para el control de medios.

Red de conmutación de circuitos GSM y servicio CAMEL

En la red de tercera generación, el servicio de voz con conmutación de circuitos ha
sido prestado por el MSC y el GMSC (gateway MSC). El HLR (home location
register) gestiona la información del usuario (por ejemplo, estado del abonado,
información de localización, información de servicio), y el control de la conexión se
realiza basándose en la información de localización. El VLR (registro de ubicación
de visitantes) gestiona la información del usuario que ha itinerado por la zona del
MSC (Figura 10.1).
La red de conmutación de circuitos está formada por la MS (estación móvil), la
RAN (red de acceso radioeléctrico), el MSC, el GMSC (para interconectar otras
redes como pasarela), el HLR y el VLR.
Cuando el MSC y el GMSC juzgan (es decir, detectan la activación) que el usuario solicita
el servicio CAMEL, la gsmSSF solicita a la gsmSCF que realice el control del
servicio. La gsmSSF se comunica con la gsmSCF mediante el protocolo CAP en el
SS7.
El GMSC VLR y el gsmSCF se comunican con el HLR mediante el MAP (parte
de aplicación móvil) en el SS7 para hacer uso de la información de ubicación, la
información de servicio y la información de usuario.
fM-££F Application £erver-fnterworking con CAMEL 212

MAPA
HLR gsmSCF

CAP
MAPA
CAP
MAPA

gsmSSF VLR gsmSSF

GMSC MSC MS
MAPA

CAP

gsmSRF
FIGURA 10.1
Entorno de servicio CAMEL.

Para proporcionar un servicio de medios (por ejemplo, servicio de contestador

automático, servicio de anuncios), es necesaria la gsmSRF (función de recursos
especializados). Es posible controlar la gsmSRF directamente desde la gsmSCF
mediante el protocolo CAP o controlarla indirectamente a través de la gsmSSF.

Arquitectura de servicios CAMEL para el usuario IMS

La figura 10.2 muestra la arquitectura funcional para conectar la S-CSCF con la
gsmSCF para proporcionar el servicio CAMEL al usuario IMS. En la red IMS, la
IM-SSF es uno de los servidores de aplicaciones SIP que soporta el protocolo ISC
(es decir, SIP). En el GSM, la gsmSCF está conectada con la gsmSSF que está
implementada en el MSC/GMSC a través del protocolo CAP. En la red IMS, la
gsmSCF está conectada con la gsmSSF implementada en la IM-SSF a través del protocolo
CAP. Por lo tanto, la gsmSCF puede proporcionar el servicio CAMEL al usuario
IMS y al usuario de conmutación de circuitos mediante el mismo protocolo y el
mismo método de control.
La IM-SSF traduce el protocolo CAP al protocolo SIP como pasarela. Además, para
proporcionar la función gsmSSF en la red de conmutación de circuitos con la
gsmSCF, la IM-SSF ha implementado el mismo BCSM (modelo básico de estado de
llamada) de la conmutación de circuitos. La IM-SSF mapea los estados de tramo
controlados por SIP en el BCSM.
218 Manual del subsistema multimedia fP (fM£)

MAPA
HSS gsmSCF gsmSCF

CAP CAP
Si

IM-SSF
gsmSSF
(gsmSSF)

Interfaz ISC

S-CSCF MSC/GMSC

Dominio IMS Dominio CS

FIGURA 10.2
Arquitectura de servicios CAMEL.

CAMEL BCSM
El BCSM para CAMEL proporciona un modelo de alto nivel de las actividades de la
CSCF para establecer y mantener las vías de comunicación para los usuarios.
Identifica un conjunto de actividades básicas de llamada en una CSCF y muestra
cómo estas actividades se unen para procesar una llamada básica. Consta de dos
partes: O-IM-BCSM (originando IP multimedia BCSM) como la mitad de origen y
T-IM-BCSM (terminando IP multimedia BCSM) como la mitad de terminación.
BCSM se utiliza para describir el estado de la llamada para la aplicación del servicio en la
gsmSCF para interoperar con la IM-SSF. La figura 10.3 ilustra cómo se producen las
transiciones entre estados. Los componentes DP (punto de detección) y PIC (puntos
en llamada) se muestran en el diagrama BCSM.
Los PIC son ciertos estados básicos de la llamada que pueden ser visibles desde la
gsmSCF; se describen como la combinación de eventos de entrada, acciones de
procesamiento y eventos de salida. Los DP son los puntos entre los PIC en los que
se interrumpe el procesamiento de llamadas de la IM-SSF y se envía el mensaje (es
decir, la operación CAMEL) a la gsmSCF. Tras recibir el mensaje de la gsmSCF, la IM-
SSF vuelve a iniciar el procesamiento de la llamada y pasa al siguiente PIC.
Cada DP tiene condiciones de activación como criterio para juzgar si debe
solicitar la . Ejemplos de condiciones de activación son un número terminado, un
código de motivo devuelto por la red o un UE (equipo de usuario) terminado, la
dirección de la gsmSCF y la información para distinguir el servicio procesado en la
gsmSCF.
fM-££F Application £erver-fnterworking con CAMEL 219

Evento

DPa

CFP 1
Evento

DP

PIC 2

FIGURA 10.3
DP y PIC.

Tipos de DP
Existen dos tipos de DP: el tipo solicitud para solicitar el control del servicio en la
gsmSCF y el tipo notificación para notificar los eventos detectados a la gsmSCF:

• TDP-R (solicitud de punto de detección de disparo): Este DP se arma

estáticamente en el perfil de usuario. La IM-SSF suspende el
procesamiento de la llamada, solicita el control del servicio CAMEL,
solicita a la gsmSCF y espera la respuesta de la gsmSCF.
• EDP-R (solicitud de punto de detección de eventos): Este tipo de DP es
armado dinámicamente por la lógica del servicio de aplicación. La IM-SSF
suspende el procesamiento de la llamada, solicita la solicitud de control de
servicio CAMEL a la gsmSCF y espera la respuesta de la gsmSCF.
• EDP-N (notificación de punto de detección de eventos): Este tipo de DP es
armado dinámicamente por la lógica de servicio de la aplicación. El
procesamiento de la llamada no se suspende cuando se encuentra con el
DP.

Mecanismos de armado/desarmado
Un DP puede armarse estática o dinámicamente. El TDP-R para el UE de origen y el
UE de destino se arma descargando CSI (información de servicio CAMEL) a la IM-
SSF. La IM-SSF descarga la CSI mientras el usuario se registra desde el servicio de
abonado de origen (HSS) a través de la interfaz Si. La CSI consta de tres tipos que se
aplican al servicio de origen, al servicio de marcación y al servicio de terminación:
220 Manual del subsistema multimedia fP (fM£)

• O-IM-CSI
• D-IM-CSI
• VT-IM-CSI

Un DP se arma dinámicamente cuando la lógica de servicio en la gsmSCF

necesita detectar eventos para el procesamiento del servicio. La gsmSCF solicita a la IM-
SSF que arme el DP mediante la operación de RequestReportBCSMEvent. La
información del DP previamente armado se actualiza cuando se recibe la operación
de RequestReportBCSMEvent. El DP se desarma cuando

• Los datos del ISC se retiran en el FSS;

• se cumple un PDE armado;
• se cumple un PDE que provoca la liberación del tramo relacionado
(entonces se desactivan todos los PDE relacionados con esa sesión de
llamada); y
• se libera una sesión de llamada (entonces se desactivan todos los EDP
relacionados con esa llamada).

O-IM-BCSM
El O-IM-BCSM es el modelo que describe el comportamiento de una IM-SSF para
una llamada originada por un UE. La figura 10.4 ilustra el O-IM-BCSM.
El PIC inicial es O_Nul&Authorize_Origination_Attempt_Collect_Info PIC; los
eventos de entrada son desconexión/abandono de llamada y eventos de excepción.
En el PIC O_Null&Authorize_Origination_Attempt_Collect_Info, se investigan las
condiciones de activación indicadas por la información O-IM-CSI tras obtener los
parámetros del mensaje INVITE recibido. Cuando es igual a las condiciones indicadas
(es decir, DP Collected_Info), la IM-SSF solicita el procesamiento del servicio a la
gsmSCF a través de la operación CAMEL InitialDP. La gsmSCF envía el resultado
del procesamiento a la IM-SSF. En Analyze_Information PIC, la dirección a enrutar
viene determinada por la información procedente de la gsmSCF (Tabla 10.1).
En el PIC de Enrutamiento y Alerta, el mensaje INVITE se envía al lado de ter-
minación y espera la respuesta del lado de terminación. Cuando se recibe el mensaje
CANCEL (es decir, abandono de llamada) del usuario de origen, el PIC pasa a
O_Null a través de O_Abandon. Cuando el establecimiento de sesión falla debido a
una respuesta de error del usuario terminado (por ejemplo, Route_Select_Failure) o
debido a la falta de respuesta o al estado ocupado del usuario terminado, el PIC
transita a O_Exception basado en el fallo de establecimiento de sesión y transita a
O_Null&Authorize_Origination_Attempt_Collect_Info PIC después de liberar todos
los recursos reservados para la sesión. Cuando se recibe una respuesta 200 OK del
lado de terminación (es decir, O-Answer), el PIC transita a O_Active PIC y
permanece en este PIC hasta que la comunicación termina.
fM-££F Application £erver-fnterworking con CAMEL 221

INVITE O_Null & Authorize_Origination O_Excepción

100 Attempt_Collect_Info
O_Abandon

Recoger_Información

Información_no_válida
Información_analizada

Información_analizada

4xx/5xx/6xx

Route_Select_Failure
CANCELAR
486/600
Enrutamiento y alerta
180 Timbre O_Busy
200 OK 603/408/480

O_No_Responde

O_Fallo_de_enrutamiento_y_Alerta
O_Respuesta
ACK 200

BYE
O_Activo
200 OK O_Active_Failure
O_Desconectar

FIGURA 10.4
O-IM-BCSM.

Cuando se recibe el mensaje BYE, PIC transita a O_Null a través de O_Dis- connect
(Tabla 10.2).
El método para juzgar los disparos del TDR-R utilizado en la O-IM-BCSM es el
siguiente:

• TDP de Collected_Info: Cuando se indica una condición de activación para el

número de la parte de terminación (por ejemplo, número RDSI), el número del
mensaje INVITE se compara con el número de la O-IM-CSI (máximo de 10
dígitos). Si estos números son iguales, la IM-SSF solicita el control del
servicio a la gsmSSF. Cuando no se indica la condición de activación del
número de ter- minación, la IM-SSF solicita el control del servicio a la
gsmSCF.
• Información_analizada TDP: Cuando el número de terminación es igual al
número indicado en la información de la D-IM-CSI, la IM- SSF solicita el
control del servicio a la gsmSCF.
• Route_Select_Failure TDP: Cuando el código de causa recibido de la red
de terminación (IMS o PSTN) coincide con el código de razón indicado
(máximo de cinco códigos), la IM-SSF solicita el control del servicio a la
gsmSCF (Tabla 10.3).
222 Manual del subsistema multimedia fP (fM£)

TABLA 10.1
Descripción de los puntos de detección O-IM-BCSM

CAMEL DP Tipo DP Descripción

DP Información_recogida TDP-R Indicación de que se analiza la O-

IM-CSI

DP Información_analizada TDP-R Disponibilidad de la dirección de

enrutamiento
DP Route_Select_Failure TDP-R, EDP-N, EDP-R Indicación de que ha fallado el
establecimiento de la sesión

DP O_Busy EDP-N, EDP-R Indicación de que se ha recibido una

indicación de ocupado de la parte de
terminaciónun evento no localizable se
determina sobre una respuesta de error
SIP

DP O_No_Respuesta EDP-N, EDP-R Indicación de que un temporizador de

aplicación asociado a la O_No_Answer
DP ha expirado y el evento de no
respuesta se determina a partir de una
respuesta de error SIP.
DP O_Respuesta EDP-N, EDP-R Indicación de que la sesión ha sido
aceptada y respondida por la parte que
finaliza.

DP O_Desconexión EDP-N, EDP-R Indicación de que se ha recibido una

desconexión de la parte de origen o de la
parte de destino.

DP O_Abandon EDP-N, EDP-R Indicación de que se ha recibido una

desconexión de la parte de origen durante
el establecimiento de la sesión.

TABLA 10.2
Acción de la O-IM-BCSM Puntos en llamada
CAMEL PIC Acciones

O-Null&Authorize_Origination Se recibe el mensaje de solicitud SIP INVITE que

Intentar_recoger_información contiene el número marcado y se analiza O-IM-CSI
Analizar_información Comparar el número de terminación con el
información sobre servicios de marcación
Enrutamiento y alerta Determinación de la dirección de enrutamiento; configuración de la
sesión SIP
se continúa el procesamiento; se espera la indicación de que
la llamada ha sido contestada por la parte que finaliza
O_Activo Sesión SIP establecida entre las partes de origen y
terminación; esperando liberación de sesión
O_Excepción Se proporciona el manejo por defecto de la condición de
excepción
fM-££F Application £erver-fnterworking con CAMEL 223

TABLA 10.3
Asignación de método/respuesta SIP a puntos de detección CAMEL O-IM-BCSM
CAMEL O-IM-BCSM DP Método/Respuesta SIP

DP Información_recogida INVITE
DP Información_analizada N/A
DP Route_Select_Failure 4xx (excepto 401, 407, 408, 480, 486), 5xx, y
6xx (excepto 600, 603)
DP O_Busy 486 Ocupado aquí600 Ocupado en todas partes
DP O_No_Respuesta 603 Rechazo408 Tiempo de espera de la
solicitud480 Temp no disponible
DP O_Respuesta 200 OK
DP O_Desconexión BYE
DP O_Abandonar CANCELAR

T-IM-BCSM
El T-IM-BCSM es el modelo que describe el comportamiento de una IM-SSF para
una llamada de terminación de UE. La figura 10.5 ilustra el T-IM-BCSM.
El PIC inicial es T_Null; los eventos de entrada son desconexión/abandono de una
llamada y evento de excepción. En T_Null, se recibe el mensaje SIP INVITE y
se analiza la información apropiada. En el PIC de gestión de llamadas de
terminación, se envía SIP INVITE a la parte de terminación y se espera la respuesta
180 ring- ing o la respuesta 200 OK. Cuando no se informa de ningún evento de
respuesta o se informa de una indicación de ocupado, el tránsito se realiza a
T_Exception PIC porque la solicitud de sesión no tiene éxito y el tránsito se
realiza a T_Null PIC después de que se liberen todos los recursos reservados para
establecer la sesión de llamada SIP. Cuando la respuesta 200 OK es recibida, el
tránsito es hecho a T_Active PIC y la sesión SIP es establecida. Luego, al recibir
la respuesta 200 OK en respuesta a la solicitud BYE, el tránsito se realiza a T_Null
PIC a través de T_Disconnect PIC (Tablas 10.4-10.6).

Datos de suscripción CAMEL

Los datos IM-CSI (información de suscripción IP multimedia CAMEL) se
proporcionan en el HSS para que los abonados IMS reciban los servicios CAMEL.
Los datos IM-CSI son enviados por el HSS a la IM-SSF a través de la interfaz Si durante el
registro del usuario. Los datos IM-CSI contienen O-IM-CSI (IM-CSI de origen), D-
IM-CSI (IM-CSI de servicios marcados) y VT-IM-CSI (IM-CSI de terminación),
que contienen la siguiente información:
224 Manual del subsistema multimedia fP (fM£)

INVITE
T_Null T_Exception
100
T_Abandon

Terminar_Intento_Autorizado

INVITE
100
180
4xx/5xx/6x
Finalización de la llamada
T_Busy

T_No_Responde

T_Call_Handling Fallo
200 OK

T_Desconectar T_Activo
ACK
T_Activo
T_Active_Failure
BYE
200 OK

FIGURA 10.5
T-IM-BCSM.

TABLA 10.4
Descripción de los puntos de detección T-IM-BCSM
CAMEL DP Tipo DP Descripción

DP Intento_de_terminación TDP-R Indicación de que se analiza la VT-

Autorizado IM-CSI
DP T_Busy TDP-R, EDP-N, EDP-R Indicación de que se ha recibido una
indicación de ocupado de la parte de
terminación - se determina un evento
de no alcanzable (por ejemplo, la
parte de terminación no está
registrada actualmente)
DP T_No_Respuesta TDP-R, EDP-N, EDP-R Indicación de que una solicitud
temporizador asociado a la T_No_ Answer
DP expirado
DP T_Respuesta EDP-N, EDP-R Indicación de que la sesión es
aceptada y contestada por la parte
que termina
DP Desconexión en T EDP-N, EDP-R Indicación de que se está produciendo una
desconexión
recibido de la parte de origen o de la
parte de destino
DP T_Abandono EDP-N, EDP-R Indicación de desconexión
recibido de la parte de origen
durante el establecimiento de la
sesión
fM-££F Application £erver-fnterworking con CAMEL 225

TABLA 10.5
Acción de los puntos T-IM-BCSM en llamada
CAMEL PIC Acciones

T_Null Se recibe el mensaje de solicitud SIP INVITE que contiene

el número marcadoSe analiza el T-IM-CSI
Tratamiento de la llamada de terminación Comparar el número del interlocutor final con la
información de los servicios marcados
T_Activo Determina la dirección de enrutamiento; continúa el
procesamiento de establecimiento de sesión SIP; espera la
indicación de que la llamada ha sido contestada por la parte que
termina.
T_Exception Sesión SIP establecida entre las partes de origen y
terminación; esperando liberación de sesión

TABLA 10.6
Asignación de método/respuesta SIP a puntos de detección T-IM-BCSM
CAMEL T-IM-BCSM DP Método/Respuesta SIP

DP Terminating_Attempt Autorizado INVITE

DP T_Busy 4xx (excepto 401, 407, 408, 480), 5xx y 6xx
(excepto 603)
DP T_No_Respuesta 603 Rechazo; 408 Tiempo de espera de la solicitud;
480 Temp no disponible
DP T_Respuesta 200 OK
DP T_Disconnect BYE
DP T_Abandon CANCELAR

• Lista TDP: La lista TDP indica la activación del punto de detección que se
debe tomar, y son posibles los siguientes puntos de detección de
activación:
• O-IM-CSI Collected_Info, Route_Select_ Failure
• D-IM-CSI
• VT-IM-CSI Terminating_Attempt_Authorized, T_Busy, T_No
Respuesta
• Clave de servicio: La clave de servicio identifica a la gsmSCF la lógica de
servicio que se aplicará.
• Dirección gsmSCF: Esta dirección se utiliza para acceder a la gsmSCF para
el abonado y es un número E.164 utilizado para el enrutamiento.
• Gestión de llamadas por defecto: La gestión de llamadas por defecto indica
si la sesión IMS se libera o continúa en caso de error en el diálogo IM-SSF
a la gsmSCF.
226 Manual del subsistema multimedia fP (fM£)

o-IM-CSI [18] SECUENCIA IMPLÍCITA {

o-BcsmCamelTDPDataList SEQUENCE (SIZE(1 .. 10)) OF SEQUENCE {
o-BcsmTriggerDetectionPoint ENUMERATED {
collectedInfo (2),
... ,
routeSelectFailure (4)},
serviceKey ENTERO (0 .. 2147483647),
Dirección gsmSCF [0] CADENA DE OCTETOS IMPLÍCITA (SIZE(1 .. 20)) (SIZE(1 .. 9))

defaultCallHandling [1] IMPLICIT ENUMERATED {

continueCall (0),
releaseCall (1),
... },
:
camelCapabilityHandling [0] IMPLICIT INTEGER (1 .. 16) OPCIONAL,
notificationToCSE [1] NULL IMPLÍCITO OPCIONAL,
csiActive [2] IMPLÍCITO NULL OPCIONAL} OPCIONAL,
o-IM-BcsmCamelTDP-CriteriaList [19] SECUENCIA IMPLÍCITA (TAMAÑO(1 .. 10)) DE

SECUENCIA {
o-BcsmTriggerDetectionPoint ENUMERATED {
collectedInfo (2),
... ,
routeSelectFailure (4)},
destinationNumberCriteria [0] SECUENCIA IMPLÍCITA {
matchType [0] ENUMERACIÓN IMPLÍCITA {
inhibiendo (0),
habilitando (1)},
destinationNumberList [1] SECUENCIA IMPLÍCITA (TAMAÑO(1 .. 10)) DE
CADENA DE OCTETOS (TAMAÑO(1 .. 20)) (TAMAÑO(1 .. 9)) OPCIONAL,
destinationNumberLengthList [2] IMPLICIT SEQUENCE (SIZE(1 .. 3)) OF

ENTERO (1 .. 15) OPCIONAL,

... } OPCIONAL,
:
o-CausaValorCriterio [3] SECUENCIA IMPLÍCITA (SIZE(1 .. 5)) DE
CADENA DE OCTETOS (SIZE(1)) OPCIONAL,

FIGURA 10.6
Información de la O-IM-CSI.

• CAMEL capability handling: Indica la fase de CAMEL y la fase 4 en el

caso de la IM-SSF.
• Indicador de notificación: El indicador de notificación indica si el cambio
de la IM-CSI en el HSS actualiza la IM-CSI en la IM-SSF. Este indicador se
establece en sí para actualizar la IM-SSF.
• Estado CSI: Indica si la IM-CSI está activa o no.
• Criterios DP: Indica si la IM-SSF solicita instrucciones a la gsmSCF.

La figura 10.6 muestra la definición de O-IM-CSI descrita mediante ASN.1 (notación

sintáctica abstracta uno), que se basa en 3GPP 29.002.
fM-££F Application £erver-fnterworking con CAMEL 222

Operación CAMEL
La tabla 10.7 enumera las operaciones CAMEL definidas para IMS. La IM-SSF proporciona
a los abonados IMS servicios CAMEL mediante el control de sesión SIP tras la
asignación de operaciones CAMEL al método/respuesta SIP. Además, la IM-SSF
interactúa con MRFC a través de SIP para controlar los servicios de medios.

Solicitud de control de servicio

Cuando la IM-SSF recibe la solicitud/respuesta SIP, primero se investigan los tipos
de solicitudes (por ejemplo, originación, marcación, terminación); si se detecta una
activación, tras investigar las condiciones de activación indicadas por la información
IM-CSI, la IM-SSF solicita a la gsmSCF que controle el servicio a través de la
operación Ini- tialDP.
La Tabla 10.8 muestra la descripción de los elementos de información utilizados
por la operación InitialDP. El valor de los elementos de información lo determina la
IM-SSF basándose en la información de cabecera de las solicitudes SIP INVITE
recibidas o basándose en la lógica de la IM-SSF. La Tabla 10.9 muestra los métodos
de determinación del valor de los principales elementos de información.

Solicitud de ruta
La gsmSCF solicita a la IM-SSF a través de la operación de conexión que realice las
acciones de procesamiento de llamadas para encaminar una llamada al destino que
se ha determinado basándose en el procesamiento lógico del servicio. La tabla 10.10
muestra la descripción de los elementos de información utilizados por la operación
InitialDP.
La IM-SSF determina la información de destino (es decir, la información de
cabecera de la solicitud INVITE) de la parte de origen y la información de
establecimiento de llamada existente, en función de la información proporcionada
por la gsmSCF a través de la operación connect. La tabla 10.11 muestra los métodos
de determinación de la información de cabecera principal en el mensaje INVITE.

Solicitud de notificación de actos

La gsmSCF solicita a la IM-SSF que envíe una notificación a la gsmSCF cuando se
detecta un evento relacionado con una llamada a través de la operación
RequestReportBCSMEvent. La tabla 10.12 enumera los elementos de información
de la RequestReport- BCSMEvent. La IM-SSF establece el nuevo EDP como la
condición de activación, que se indica en el elemento de información del tipo de
evento. El elemento de información Leg ID puede indicar el tramo en la parte de
origen o en la parte de destino. El elemento de información Monitor Mode puede
indicar el comportamiento de la IM-SSF tras recibir la notificación. En el caso del
EDP-R, se utiliza "interrupted", y en el caso del EDP-N, "noti- fyAndContinue".
Cuando la IM-SSF necesite detectar el estado de no respuesta de un usuario, el valor
del temporizador deberá establecerse en el elemento de información de los criterios
específicos del DP.
228 Manual del subsistema multimedia fP (fM£)

TABLA 10.7
Operación CAMEL para IMS
Operación Dirección Función

Prueba de actividad IM-SSF gsmSCF Comprobación de la existencia continuada de una

relación entre la gsmSCF y la IM-SSF
AplicarCarga gsmSCF IM-SSF Interacción de la gsmSCF con la IM-SSF
Mecanismos de cobro de las FSS
ApplyChargingReport IM-SSF gsmSCF Informar a la gsmSCF de la tarificación
información
CallGap IM-SSF gsmSCF Activar/modificar/eliminar un mecanismo de
interrupción de llamadas en la IM-SSF. El
mecanismo de interrupción de llamadas se
utiliza para reducir la velocidad a la que se
envían solicitudes de servicio específicas a una
gsmSCF.
Informe IM-SSF gsmSCF Enviar información de llamada específica según se
CallInformation solicite
por la anterior CallInformationRequest
Solicitud de
información de gsmSCF IM-SSF Solicitar a la IM-SSF que registre
llamada información sobre una única llamada
Cancelar gsmSCF IM-SSF Solicitud de cancelación de todos los EDP e informes
Conectar gsmSCF IM-SSF Solicitud de enrutamiento de una
llamada a un destino específico
ConnectToResource gsmSCF IM-SSF Conectar una llamada de la IM-SSF a MRFC a través de
S-CSCF
Continúe en gsmSCF IM-SSF Solicitud para continuar con el procesamiento de la
llamada
Argumento gsmSCF IM-SSF Solicitud para proceder con el procesamiento de la
ContinueWith llamada
con información modificada
DesconectarReenviar
conexión gsmSCF IM-SSF Desconexión de una conexión con una MRFC
previamente establecido con un
ConnectToResource
EventReportBCSM IM-SSF gsmSCF Notificar eventos solicitados por un
RequestReportBCSMEvent
FurnishInformación gsmSCF IM-SSF Solicitar a la IM-SSF que incluya información
de carga para cargar
InitialDP IM-SSF gsmSCF Solicitud de control de servicio cuando se
detecta una activación
PlayAnnouncemnet gsmSCF IM-SSF Solicitar al MRFC que reproduzca anuncios
o tonos
Preguntar y recoger gsmSCF IM-SSF Solicitud de interacción con un interlocutor para
información del usuario recopilar información
PromptAndCollectUser IM-SSF gsmSCF Enviar la información de usuario a la gsmSCF
InformationAck
Informe sobre recursos IM-SSF gsmSCF Enviar la indicación completa a la gsmSCF
especializados
ReleaseCall gsmSCF IM-SSF Deshacer una llamada existente
fM-££F Application £erver-fnterworking con CAMEL 229

CUADRO 10.7 (continuación)

Operación CAMEL para IMS
Operación Dirección Función

Evento gsmSCF IM-SSF Solicitud de supervisión de un evento relacionado con

RequestReportBCSM una llamada
y enviar una notificación cuando se detecte el evento
ResetTimer gsmSCF IM-SSF Solicitud de actualización de un temporizador de
aplicación

La IM-SSF notifica a la gsmSCF un evento relacionado con una llamada mediante la

operación EventReport- BCSM cuando detecta el evento solicitado por la gsmSCF en
un RequestReportBCSMEvent (Tabla 10.13).

Interfaz Si
La IM-SSF se comunica con el HSS a través de la interfaz Si basada en el protocolo
MAP para obtener la información de suscripción (es decir, la información IM-CSI)
con el fin de procesar el servicio y también para conocer el cambio en la
información IM-CSI. En la tabla 10.14 se enumeran las operaciones de la interfaz
Si.

Solicitar información IM-CSI

La IM-SSF solicita información IM-CSI al HSS enviando una solicitud de
"interrogación de suscripción en cualquier momento" tras recibir la solicitud de
registro de terceros de la S-CSCF. La Figura 10.7 muestra la secuencia de registro
para solicitar información IM-CSI (Tablas 10.15 y 10.16).

Actualización de la información IM-CSI

El HSS notifica a la IM-SSF a través de la operación NotifySubscriberDataChange
el cambio en los datos IM-CSI cada vez que se modifican los datos. La IM-SSF
responde a la notificación del HSS mediante la operación
NotifySubscriberDataChange ack (cuadros 10.17 y 10.18; figura 10.8).

Comportamiento de control de la sesión originada por el UE en IM-SSF

Al recibir un mensaje de solicitud INVITE, la S-CSCF comprueba los criterios de
filtrado iniciales (iFC) y reenvía la INVITE a la IM-SSF al detectar el activador de
puntos de servicio (SPT) correspondiente. La IM-SSF comprueba O-IM-CSI
230 Manual del subsistema multimedia fP (fM£)

TABLA 10.8
Elementos de información del punto de detección inicial

Nombre del elemento Orig Plazo Descripción

de información

Lista de información sobre M M Tipos de medios asociados con la sesión de llamada SIP
el tipo de soporte recibida de la S-CSCF

Número del interlocutor C C Dirección E.164 utilizada para identificar a la parte de

llamado terminación

URL del destinatario de la C C URL SIP utilizada para identificar la parte de

llamada terminación
Número del C C Dirección E.164 utilizada para identificar a la parte de
interlocutor que llama origen

URL de la parte llamante C C URL SIP utilizada para identificar la parte de origen

Categoría del C C Tipo de origen (por ejemplo, operador, teléfono público,

comunicante abonado ordinario)

Hueco de llamada C C Tipo de desfase al que se ha sometido la convocatoria

encontrado correspondiente

ID de llamada SIP M M Un identificador único global para la llamada SIP

recibido del mensaje de solicitud SIP de la S-
CSCF.

Causa C C La causa específica del evento DP BCSM armado (por

ejemplo, DP Route_Select_Failure_DP T_Busy).

Tipo de evento BCSM M M El evento armado BCSM DP, resultando en el DP

inicial

IMSI M M Identifica al abonado móvil recibido de la S-CSCF

durante la notificación de un registro SIP.

Capacidades IP SSP C C Indica qué recursos MRFC son compatibles con la IM-
SSF

Dirección IM-SSF M M Dirección E.164 de la IM-SSF desde la que se envía la

operación InitialDP

ID original de la parte C C Dirección E.164 utilizada para identificar el número

llamada de destino original si la llamada ha sido desviada

URL original del C C URL SIP utilizada para identificar el número de

destinatario de la destino original si la llamada ha sido desviada
llamada

ID de la parte que redirige C C Dirección E.164 utilizada para identificar el número de

directorio desde el que se redirigió la llamada

Redireccionamiento de C C URI SIP utilizado para identificar el número de

la URL PARTY directorio desde el que se redirigió la llamada

Información de C C Información relacionada con el reenvío (por ejemplo,

redireccionamiento motivo del reenvío)

Clave de servicio M M Dirección de la aplicación/SLP requerida dentro de

la gsmSCF
fM-££F Application £erver-fnterworking con CAMEL 231

TABLA 10.8 (continuación)

Elementos de información del punto de detección inicial
Nombre del Origen Término Descripción
elemento de
información

Estado del abonado - C El estado del abonado IMS es el siguiente:

CAMELBusy: durante una sesión de origen o
terminación NetworkDeterminedNotReachable: la red
determinó que el abonado IMS no estaba localizable
Hora y zona horaria M M Hora en que se activó la IM-SSF, y hora
zona en la que reside la IM-SSF

Notas: Orig: originación; Term: terminación; M: obligatorio; C: condicional; -: no aplicable.

TABLA 9.9
Métodos de determinación del valor de los elementos de información InitialDP
Nombre del elemento de información Método para determinar el valor

Número/URL de la parte llamada Utilizar el URI SIP indicado por el URI de solicitud en el mensaje
recibido
INVITE o número de teléfono descrito en la parte de
usuario
Número/URL de la parte llamante Utilizar SIP URI indicado por el encabezado P-Asserted-Identity
en la INVITE recibida o número de teléfono descrito en la
parte de usuario
Categoría del interlocutor llamante Determinar el valor en función de los parámetros cpc en P-
Cabecera Asserted-Identity de INVITE como sigue:
ordinary: ordinario; usertest: prueba; userpayphone:
teléfono público (Véase IETF draft-mahy-iptel-cpc-04. txt)
ID de llamada SIP Utilizar el contenido de Call-IDheader en INVITE
Tipo de evento BCSM Utilice Analyzed_Information cuando se origine
IMSI Utilizar la IMSI guardada durante el registro
Dirección IM-SSF Utilizar la dirección de la IM-SSF que envía el InitialDP
Clave de servicio Utilice la clave de servicio indicada en IM-CSI
Hora y zona horaria Utilice la hora y la zona horaria en que se activó la IM-SSF

información en el caso de una sesión originada por un UE y envía la operación

InitialDP con los parámetros contenidos en la INVITE si se indica el TDP
Collected_Info. La gsmSCF responde a la operación connect basándose en el
resultado del procesamiento de la lógica de servicio. La IM-SSF crea la petición
INVITE basándose en el destino y los parámetros contenidos en la operación connect
y la envía a la red de terminación a través de la S-CSCF (Figura 10.9).
232 Manual del subsistema multimedia fP (fM£)

TABLA 10.10
Elementos de información de la operación Connect
Elemento de información Nombre Estado Descripción

Categoría de interlocutor O Indica el tipo de origen Dirección de

enrutamiento de destino E1 Dirección E.164 de la parte que termina hacia
a la que debe dirigirse la llamada
Dirección de enrutamiento de E1 URL SIP de la parte de terminación hacia la que se
destino URL dirigirá la llamada
ID original de la parte llamada O, E2 Dirección E.164 utilizada para identificar al original
número de destino si se ha desviado la llamada
URL original del destinatario de la llamada O, E2 URL SIP utilizada para identificar la
llamada original
número de destino si se ha desviado la llamada
ID de la parte que redirige O, E3 Dirección E.164 utilizada para identificar el directorio
número desde el que se redirigió la llamada
Redireccionamiento de la URL del partido O, E3 URL SIP utilizada para identificar el
número de directorio
desde el que se redirigió la llamada

Notas: En: mutuamente excluyente; O: opcional.

TABLA 10.11
Métodos de determinación de la información de cabecera principal en el mensaje INVITE
Cabecera del mensaje INVITE Métodos

URI de solicitud Utilizar la dirección de enrutamiento de destino como parte

de usuario de SIP URI o dirección de enrutamiento de
destino URL
Identidad P-Asertada Utilice la cabecera P-Asserted-Identity en la INVITE
recibida o modifique el parámetro cpc cuando se indique
la categoría del autor de la llamada en la operación de
conexión.
Ruta Utilizar el resto de la cabecera de ruta en la INVITE
recibida tras eliminar la cabecera de IM-SSF
Póngase en contacto con Utilizar la dirección de la UAC en el IM-SSF
Otros Utilizar parámetros en la INVITE recibida
Cuerpo Utilizar el cuerpo en la INVITE recibida
fM-££F Application £erver-fnterworking con CAMEL 233

TABLA 10.12
Elementos de información de la operación RequestReportBCSMEvent

Nombre del elemento de Estado Descripción

información
Tipo de acontecimiento M Tipo de acontecimiento para el que se solicita el
informe
Identificación de la pierna C El participante en la convocatoria para la que se
comunica el suceso

Modo monitor M "interrumpido": informe solicitud (EDP-R);

"notifyAndContinue": informar como notificación
(EDP-N); "transparent": no se informa del suceso
Criterios específicos del PD O Temporizador de aplicación necesario para el armado No_
Respuesta EDP en la IM-SSF

Notas: M: obligatorio; C: condicional; O: opcional.

TABLA 10.13
Elementos de información de la operación EventReportBCSM
Elemento de información Nombre Estado Descripción

Tipo de evento BCSM M Tipo de suceso notificado

Información específica del C En caso de O_Answer, T_Answer: dirección de
evento BCSM terminación; En caso de Route_Select_Failure, O_
Called_Party_Busy, O_Disconnect, T_Busy, T_
Disconnect: motivo ocupado o motivo de desconexión;
En caso de O_No_Answer: ninguno
ID de pierna M Parte de la llamada de la que se notifica el
evento
Información diversa M Indica el tipo de DP

Notas: M: obligatorio; C: condicional.

TABLA 10.14
Funcionamiento de la interfaz Si

Remitente Receptor Operación Abreviatura

IM-SSF HSS Solicitud de interrogación de suscripción en ATSI

cualquier momento
HSS IM-SSF Interrogación de suscripción en cualquier momento ATSI
Ack
HSS IM-SSF Notificar cambio de datos de abonado NSDC
IM-SSF HSS Notificar cambio de datos de abonado Ack NSDC
234 Manual del subsistema multimedia fP (fM£)

UE P-CSCF S-CSCF IM-SSF gsmSCF HSS

REGÍSTRES REGÍSTRES
E E
Solicitud de autenticación
multimedia (MAR)
Respuesta de autenticación
401 401

REGÍSTRES REGÍSTRES
E E Solicitud de asignación de servidor
(SAR)

200 OK 200 OK Respuesta de asignación de

SUSCRIBETE SUSCRIBETE

200 200

NOTIFIC NOTIFIC
AR AR
200 OK(NOTIFY) 200 OK(NOTIFY)

SUSCRIBIRS

E 200

NOTIFICAR

200 OK(NOTIFY)

Comprobación
iFC

REGÍSTRES
E
Suscripción en cualquier momento Solicitud
de interrogatorio

Suscripción en cualquier momento

200 OK

FIGURA 10.7
Secuencia Si durante el registro.

TABLA 10.15
Suscripción en cualquier momento Solicitud de interrogatorio
Elemento de información Nombre Descripción

Dirección gsmSCF Indica la dirección E.164 de la IM-SSF interrogadora Información

solicitada Tipo de información de abonado que se solicita (por ejemplo, O-
IM-
CSI, VT-IM-CSI, D-IM-CSI)
Identidad del abonado Identifica al abonado sobre el que se comunica la información.
solicitada. La identidad es una IMSI.
fM-££F Application £erver-fnterworking con CAMEL 235

TABLA 10.16
Suscripción en cualquier momento Interrogación Ack
Elemento de información Nombre Descripción

Información sobre la suscripción a CAMEL Información sobre el abonado

como O-IM-CSI/VT-IM-CSI/D-IM-CSI

TABLA 10.17
Notificar cambio de datos de abonado
Elemento de información Nombre Descripción

IMSI Identifica la IMSI

MSISDN Indica el MSISDN del abonado. Si no hay MSISDN
disponible, el valor se establece en un MSISDN ficticio.
Información de suscripción CAMEL Indica la información CSI modificada o suprimida

TABLA 10.18
Información sobre la suscripción a CAMEL
Elemento de información Nombre Descripción

O-IM-CSI Datos de suscripción para el servicio de origen

D-IM-CSI Datos de abono para el servicio de marcación
VT-IM-CSI Datos de suscripción para el servicio de terminación
Lista específica CSI suprimida Indica la información de suscripción IMS CAMEL que se debe
suprimido (O-IM-CSI/VT-IM-CSI/D-IM-CSI)

Comportamiento de control de UE que finaliza sesión en IM-SSF

Al recibir un mensaje de solicitud INVITE, la S-CSCF comprueba la iFC y reenvía
la INVITE a la IM-SSF al detectar el SPT correspondiente. La IM-SSF comprueba la
información VT-IM-CSI en el caso de una sesión de de UE y envía la operación
InitialDP con los parámetros contenidos en el mensaje INVITE si se indica
Terminating_Attempt_Authorize. La gsmSCF responde la operación connect bse en
el resultado del procesamiento lógico del servicio. La IM-SSF crea la petición
INVITE basándose en el destino y los parámetros contenidos en la operación
connect y la reenvía a la red de terminación a través de la S-CSCF (Figura 10.10).
236 Manual del subsistema multimedia fP (fM£)

IM-SSF HSS

Actualización

Notificar cambio de datos de

abonado

Actualización de los datos

del CSI

Notificar al abonado Cambio de datos

ack

FIGURA 10.8
Secuencia de actualización de los datos IM-CSI.

UE P-CSCF S-CSCF IM-SSF gsmSCF Terminación UE

INVITE INVITE

Comprobación
iFC
INVITE

Comprobación O-IM-
CSI
InitialDP

Lógica de servicio CAMEL

Conectar
INVITE

INVITE
INVITE
INVITE
180 Timbre
180 Timbre
180 Timbre
180 Timbre

180 timbres 180 Ringing 180 Timbre

FIGURA 10.9
Secuencia de origen del UE.
fM-££F Application £erver-fnterworking con CAMEL 232

UE Origen S-CSCF IM-SSF gsmSCF P-CSCF UE

INVITE INVITE

Comprobación
iFC
INVITE

VT-IM-CSI
Comprobación
InitialDP

Lógica de servicio CAMEL

Conectar
INVITE

INVITE
INVITE

INVITE

180 Timbre 180 Timbre

180 Timbre
180 Timbre

180 timbres 180 Ringing 180 Timbre

FIGURA 10.10
Secuencia de terminación de UE.

Comportamiento para conectar MRF

Enviar anuncio
El MRF se utiliza para notificar a los usuarios el estado o la información del servicio
mediante anuncios o tonos. La lógica de servicio CAMEL utiliza la operación
Connect To Resource para conectar con la MRF y la operación Play Announcement
para especificar la información para reproducir anuncios o tonos en la MRF.
ConnectToResource se utiliza para conectar una llamada desde la IM-SSF y no
requiere elementos de información para el IMS. La Tabla 10.19 muestra los
elementos de información de la operación PlayAnnouncement.
Cuando la lógica de servicio CAMEL necesita saber cuándo se ha completado el
anuncio, utiliza el elemento de información de solicitud de anuncio completo, y la
IM-SSF responde con la operación de informe de recurso especializado cuando se
ha completado el anuncio. La operación de informe de recurso especializado no
contiene elementos de información (Tabla 10.20; Figura 10.11).
238 Manual del subsistema multimedia fP (fM£)

TABLA 10.19
Elemento de información de la operación PlayAnnouncement
Elemento de información Nombre Estado Descripción

Información a enviar M Indica un anuncio o un tono a enviar

enviado al usuario final por el MRFC
Desconexión de IP M Indica si el MRFC puede o no desconectarse del
prohibida usuario una vez enviada toda la información.
M Indica si se envía o no un
Anuncio de solicitud SpecializedResourceReport a la gsmSCF cuando
completo se ha enviado toda la información.

Nota: M: obligatorio.

TABLA 10.20
Información que debe contener la información a enviar
Elemento de información Nombre Estado Descripción

ID de mensaje M Indica el ID del mensaje que se va a enviar

Número de repeticiones M Indica el número máximo de veces que
se envía el mensaje
Duración O Indica el tiempo máximo de duración en
segundos. Cero indica repetición sin fin
Intervalo O Indica el intervalo de tiempo en segundos
entre repeticiones

Notas: M: obligatorio; O: opcional.

Interacción con el interlocutor

La MRF se utiliza para interactuar con el usuario y recopilar información. La IM-
SSF utiliza la operación ConnectToResource para controlar la conexión con la MRF
y utiliza la operación PromptAndCollectUserInformation para recopilar información.
El elemento de información de información a enviar en la operación
PromptAndCol- lectUserInformation se utiliza para indicar el anuncio o tono que se
enviará al usuario final como la operación PlayAnnouncement. Además, el elemento
de información recopilada indica el número de dígitos válidos que deben
recopilarse, el número de vencimientos del temporizador, los métodos de entrada,
etc. La IM-SSF envía el resultado de la operación PromptAndColUserInformation.
La IM-SSF envía el resultado mediante la operación PromptAnd
CollectUserInformation ack a la gsmSCF.
La Figura 10.12 muestra la secuencia de cómo la IM-SSF controla la interacción
entre el usuario y la MRF. El 3GPP aún no ha estandarizado el método de
transferencia entre la MRF y el AS. Así, en la Figura 10.12, el mensaje INFO se
utiliza para transferir la información recibida por DTMF a la IM-SSF (Tablas 10.21-
10.23).
fM-££F Application £erver-fnterworking con CAMEL 239

UE P-CSCF S-CSCF IM-SSF gsmSCF MRF

INVITE INVITE

Comprobación
iFC
INVITE

O-IM-CSICheck
InitialDP

Lógica de servicio CAMEL

ConectarseAlRecurso+ReproducirAnuncio
INVITE

INVITE

200 OK(INVITE)
200 OK(INVITE)
200 OK(INVITAR)
200 OK(INVITAR) 200 OK(INVITAR)

ACK ACK ACK

Enviar anuncio tras recibir ACK
ACK

ACK ACK ACK

Anuncio

BYE

BYE

200

200

BYE BYE BYE

200 200 200

FIGURA 10.11
Secuencia para conectar MRF por IM-SSF.
240 Manual del subsistema multimedia fP (fM£)

UE P-CSCF S-CSCF IM-SSF gsmSCF MRF

INVITE INVITE

Comprobación
iFC
INVITE

D-IM-CSICheck
InitialDP

Lógica de servicio CAMEL

Conectar a recurso+Información de usuario
INVITE INVITE

200 OK(INVITE)

200 OK(INVITE)

200 OK(INVITAR) 200 OK(INVITAR) 200 OK(INVITAR)

ACK ACK ACK

ACK

ACK ACK ACK

Anuncio

Tono DTMF

PromptAndCollectUserInformation Ack

INFO
INFO

Lógica de servicio CAMEL

BYE BYE BYE ReleaseCall

200 200 200

BYE

BYE

200

200

FIGURA 10.12
Secuencia de interacción entre el usuario y la MRF por IM-SSF.
fM-££F Application £erver-fnterworking con CAMEL 241

TABLA 10.21
Elemento de información de PromptAndCollectUserInformation
Elemento de información Nombre Estado Descripción

Información recopilada M Indica la información que se solicitará al usuario

Información a enviar O Indica un anuncio o un tono a enviar
al usuario final por el MRFC
Desconexión de IP prohibida M Indica si el MRFC puede desconectarse
del usuario una vez enviada toda la
información
Notas: M: obligatorio; O: opcional.

TABLA 10.22
Elementos de información

Nombre del elemento de Estado Descripción

información
Número mínimo de dígitos M Indica el número mínimo de dígitos válidos que
deben recogerse

Número máximo de dígitos M Indica el número máximo de dígitos válidos que

deben recogerse

Fin del dígito de respuesta O Indica el dígito utilizado para señalar el final de la
entrada

Cancelar dígito O Se puede introducir el dígito de cancelación

para solicitar un posible reintento

Dígito inicial O Indica el inicio de los dígitos válidos que deben

recogerse

Tiempo de espera del primer dígito O Indica el valor de tiempo del primer dígito del
temporizador
caducidad
Tiempo de espera entre dígitos O Indica el valor de tiempo del temporizador de dígito
posterior
caducidad

Tratamiento de errores O Indica la acción específica en caso que se

produzcan condiciones de error

Interrumpible ann ind O En caso de TRUE: el anuncio se interrumpe tras el

primer dígito recibido; en caso de FALSE: el
anuncio no se interrumpe tras el primer dígito
recibido.

Información vocal O En caso de TRUE: proporciona toda la información

por voz; en caso de FALSE: todos los dígitos se
introducen por DTMF

Voz de vuelta O En caso de TRUE: los dígitos introducidos se

anunciarán al usuario una vez se haya recibido el
final de la entrada; en caso de FALSE: no se
proporcionará ninguna información de voz.

Notas: M: obligatorio; O: opcional.

242 Manual del subsistema multimedia fP (fM£)

TABLA 10.23
Elemento de información de PromptAndCollectUserInformationAck

Nombre del elemento de Estado Descripción

información
Dígitos de respuesta C Indica la secuencia de dígitos recibida del usuario
final

Nota: C: condicional.

Referencias
3GPP TS 23.218 Tratamiento de sesiones multimedia IP (IM), modelo de llamada
IM. 3GPP TS 23.228 Subsistema multimedia IP (IMS).
3GPP TS 24.229 Protocolo de control de llamadas multimedia IP basado en SIP y SDP.
3GPP TS 23.333 Controlador de funciones de recursos multimedia (MRFC)-Procesador de
funciones de recursos multimedia (MRFP) Interfaz Mp: Descripción de procedimientos.
3GPP TS 29.328 IP multimedia (IM) subsystem Sh interface; signaling flows and mes- sage contents.
3GPP TS 29.329 Interfaz Sh basada en el protocolo DIAMETER.
3GPP TS 23.078 Aplicaciones personalizadas para lógica mejorada de red móvil (CAMEL) fase
4.
3GPP TS 29.278 Customized applications for mobile network enhanced logic (CAMEL) phase 4,
CAMEL application part (CAP) specification for IP multime- dia subsystems (IMS).
3GPP TS 23.278 Subsistemas multimedia IP (IMS), CAMEL fase 4, interfuncionamiento CN IM.
RFC 3261 SIP: Protocolo de iniciación de sesión, junio de 2002.
11
Distribuido fM£

Marcin Matuszewski

CONTENIDO
Introducción ....................................................................................................................... 243
Estructura de datos ............................................................................................................. 245
HSS distribuido (HSS DHT)................................................................................................ 247
Replicación de datos ............................................................................................... 250
Inscripción ................................................................................................................. 250
Funcionamiento de la red ....................................................................................... 251
Mejoras .................................................................................................................... 252
I/S-CSCF distribuida (I/S-CSCF DHT) .......................................................................... 252
Co-localización del Servidor de Presencia en el Nodo I/S-CSCF .................... 254
Uso de la DHT I/S-CSCF con la DHT HSS .................................................................. 255
Arquitectura IMS distribuida ........................................................................................... 256
Comparación...................................................................................................................... 260
Conclusiones ........................................................................................................................ 261
Referencias .......................................................................................................................... 262

Introducción
La arquitectura IMS (subsistema multimedia IP) [1] se diseñó en torno al año 2000 y
heredó algunos conceptos de la arquitectura de red central del sistema global de
comunicaciones móviles (GSM). En concreto, el IMS define el servidor de abonado
doméstico (HSS) como una evolución del registro de localización doméstica (HLR)
de GSM.
El HSS es un repositorio general de datos de usuario persistentes, como nombres
de usuario, identidades asignadas, claves compartidas, servicios asignados, políticas
y permisos. Es la base de datos central de la arquitectura IMS, como el HLR es la
base de datos central en GSM. Un concepto clave del HSS es que todos los datos
relativos a un abonado se almacenan en un único HSS. La redundancia se consigue
normalmente replicando los datos del HSS en un HSS secundario diferente (de
reserva).

243
244 Manual del subsistema multimedia fP (fM£)

El SMS es conocido por no escalar bien. Normalmente, los FSS comerciales son
nodos totalmente equipados (incluyendo grandes cantidades de memoria de
ejecución y persistente y grandes ciclos de CPU para gestionar las consultas a la
base de datos) que pueden gestionar y almacenar los datos correspondientes a un
número máximo determinado de abonados. Esta cifra suele estar limitada por la
memoria persistente disponible, los ciclos de CPU disponibles y la memoria de
ejecución disponible. Si el número de abonados supera el límite máximo, el
operador se ve obligado a desplegar nuevas unidades de SMS que puedan gestionar
los datos de los nuevos abonados.
Debido a las limitaciones de diseño, es difícil incorporar un complemento a un
SMS existente para ampliarlo y gestionar un mayor número de abonados cuando
este factor es de varios órdenes de magnitud. Lo contrario también es cierto: un FSS
grande suele ser costoso para las redes pequeñas.
Además, si una red grande necesita añadir más de un HSS para atender a todos sus
abonados, el operador se ve obligado a instalar una función de localización de
abonados (SLF). Se trata de un tipo de servidor de redirección DIAMETER que actúa
como único punto de contacto para los clientes DIAMETER (por ejemplo, función de
control de sesión de llamada de servicio [S-CSCF], función de control de sesión de
llamada de interrogación [I-CSCF], servidor de aplicaciones [AS]). El SLF contiene
el rango de espacios de direcciones que se asigna a cada HSS; por tanto, es capaz de
localizar el HSS que contiene los datos relacionados con el usuario. En
consecuencia, cuanto más crece la red, más configuración es necesaria. Además,
cada SLF crea un único punto de fallo en la red.
Debido a estas limitaciones, hemos evaluado la posibilidad de distribuir el HSS
entre distintos nodos configurados a modo de tabla hash distribuida (DHT). Se sabe
que las DHT escalan muy bien desde 1 hasta un número muy grande de nodos, y
permiten crear redes autoconfiguradas con capacidad de replicación automática.
Un segundo aspecto de este capítulo trata sobre la I-CSCF y la S-CSCF. Es cierto
que IMS proporciona algún tipo de distribución de I-CSCF y S-CSCF; sin embargo,
también es cierto que el sistema no es altamente escalable. Aportar más capacidad a
la red suele implicar poner en funcionamiento más nodos I-CSCF o , una operación
costosa debido al elevado número de operaciones de configuración necesarias.
En este capítulo se estudian varias combinaciones de DHT que sustituyen la red
central IMS por una red superpuesta autoorganizada. Dado que las propias DHT son
capaces de reaccionar ante los cambios (por ejemplo, la aparición o el fallo de un
nodo), no es necesaria la intervención del operador. La puesta en marcha de una
nueva S-CSCF o HSS no requiere prácticamente ninguna configuración. Esto
supone un importante ahorro en gastos de explotación (OPEX).
Este documento está organizado de la siguiente manera. La siguiente sección
estudia los requisitos relacionados con la variedad de datos altamente
interrelacionados pertenecientes a un usuario IMS. Propone una estructura de
datos adecuada para almacenar datos de usuario en la red superpuesta DHT. La
tercera sección presenta la arquitectura de una DHT HSS. En la cuarta sección se
describe una función distribuida de interrogación/control de sesión de llamada de
servicio (I/S- CSCF DHT). La quinta sección analiza cómo la DHT I/S-CSCF
puede funcionar junto con la DHT HSS. La dis-
Distribuido fM£ 245

En la sexta se presenta el IMS distribuido, compuesto por las DHT combinadas del
HSS y la I/S-CSCF, junto con nodos servidores de presencia distribuidos. La
séptima sección compara las tres soluciones presentadas. La última sección
concluye el capítulo.

Estructura de datos
Una DHT es una arquitectura distribuida que se construye en torno a un espacio de
claves abstracto. El espacio de claves se divide entre los nodos que forman la red
DHT. La operación de división se realiza según el esquema de partición del espacio
de claves utilizado. Los nodos que componen la red superpuesta también almacenan
valores (datos) pertenecientes a una clave determinada. Cada clave es un
identificador único de un dato dado. Una red superpuesta DHT proporciona una
localización eficiente de los datos, dada su clave entrada. La localización de datos
depende del algoritmo utilizado. Algunos ejemplos de algoritmos DHT son Chord
[2], Pastry [3] y Kademlia [4].
Esencial para cualquier tabla hash distribuida es el hecho de que los nodos que
componen la red superpuesta almacenan valores (datos) pertenecientes a una clave.
Esencialmente, cualquier red superpuesta DHT puede ofrecer dos operaciones
básicas: PUT y GET. La operación PUT (clave, valor) almacena el valor de una
clave determinada en la DHT. La operación GET devuelve el valor de una clave
dada que ya está almacenada en la DHT; valor= GET (clave). Los valores se
almacenan en el nodo de la DHT responsable de la clave. (Nótese que no se trata de
una asignación estática; en cuanto se incorporan más nodos a la DHT, el espacio de
claves se redistribuye y algunos de los nodos de la DHT distribuyen su
almacenamiento entre los nuevos nodos).
Un primer y fundamental principio de diseño en cualquier red superpuesta DHT
requiere decidir qué es una clave y cómo se calcula la clave. La decisión depende
del requisito que limite la operación GET. Por ejemplo, en IMS todos los datos
relativos a un usuario están muy interrelacionados.
En IMS, a cada usuario se le asignan una o varias identidades de usuario privadas
y una o varias identidades de usuario públicas. Las identidades privadas de usuario
se utilizan con fines de identificación y autenticación de abonados. Las identidades
privadas de usuario son identificadores de acceso a la red [5]. Por otro lado, las
identidades públicas de usuario son identificadores uniformes de recursos (URI) del
protocolo de inicio de sesión (SIP).
[6] o URL TEL [7]. A diferencia de las identidades de usuario privadas, las
identidades de usuario públicas son conocidas y visibles para los usuarios y se
utilizan para enrutar solicitudes SIP [6].
Cada identidad privada de usuario está vinculada a uno o varios perfiles de
servicio que dictan, entre otras cosas, las identidades públicas de usuario que pueden
utilizarse y el conjunto de criterios de filtrado iniciales y compartidos que deben
aplicarse. Los criterios de filtrado contienen una colección de desencadenantes que
determinan si una solicitud tiene que viajar por uno o varios AS que prestan
servicios a los usuarios.
En general, hay tres casos de uso para acceder a los datos:
246 Manual del subsistema multimedia fP (fM£)

1. Un operador o un nodo de la red, que conoce la identidad privada del

usuario, quiere acceder a los datos del usuario para . Por ejemplo, el
operador quiere cambiar uno de los criterios de filtro. Esto incluye enviar
los nuevos criterios de filtro a la S-CSCF asignada al usuario.
2. Durante un registro o cualquier intento de sesión entrante, un nodo de red
accede al HSS para obtener los datos asociados a una identidad de usuario
pública determinada. Los datos a devolver incluyen el estado del registro
(información que indica si la identidad de usuario pública está registrada o
no, la dirección de la S-CSCF asignada al usuario, el conjunto de
identidades de usuario privadas que pueden utilizarse junto con esa
identidad de usuario pública, etc.).
3. Un operador, que sólo conoce el nombre, apellidos o número de la
seguridad social del abonado, quiere acceder a todos sus datos. Este podría
ser el caso cuando un usuario llama al servicio de atención al cliente para
informar de un problema o solicitar ayuda para utilizar un nuevo servicio o
simplemente suscribirse a un nuevo servicio. En este , el operador conoce
inicialmente información parcial (quizá ni siquiera el nombre completo)
para iniciar la búsqueda en la base de datos.

Basándonos en estos tres casos de uso, hemos identificado los siguientes

requisitos de alto nivel relacionados con la operación GET en una DHT:

Debe ser posible para un operador o un nodo de la red (por ejemplo, durante el
tráfico en tiempo real) acceder a todos los datos relativos a una identidad
privada de usuario determinada (es decir, sus identidades públicas de
usuario asociadas, pro- archivos de servicio, etc.).
Debe ser posible obtener, en tiempo real, todos los datos relativos a una
determinada identidad pública de usuario (es decir, identidades privadas de
usuario, estado de registro, dirección de la S-CSCF asignada al usuario,
etc.).
Debe existir un mecanismo que permita a un operador encontrar los datos del
usuario, dada una información simple parcial como el nombre, los
apellidos o el número de la Seguridad Social.

Los requisitos primero y segundo afectan al tráfico en tiempo real. El tercer se utiliza
durante el funcionamiento y el mantenimiento, pero nunca durante el tráfico en
tiempo real. Este tercer requisito es un poco especial porque requiere un mecanismo
de búsqueda parcial. Las búsquedas parciales y las tablas hash distribuidas son
conocidas como malas amigas porque todo el concepto de una DHT se basa en
realizar búsquedas basadas en un valor exacto.
Los dos primeros requisitos conducen a las siguientes consideraciones de diseño:

Cada identidad privada de usuario (identidad privada multimedia IP [IMPI])

se somete a un hash para crear una clave. Los datos asociados a esta clave
se componen de las identidades públicas de usuario (agrupadas en torno a
un perfil de servicio) y otros datos como los vectores de autenticación.
Distribuido fM£ 242

Cada identidad pública de usuario (identidad pública multimedia IP [IMPU])

se somete a hash para crear una clave. Los datos asociados a esta clave
incluyen la identidad privada de usuario principal, el perfil de servicio
(incluidos los criterios de filtro inicial y compartido) y otros datos.

El tercer requisito afecta al funcionamiento y mantenimiento de la base de

subcriptores, pero hay que señalar que el tráfico en tiempo real no se ve afectado por
este requisito. Además, el tercer requisito se refiere a la realización de búsquedas
parciales en distintos campos. Por ejemplo, un operador puede querer traer una lista
de todos los abonados cuyo apellido es Brown o de los que residen en una
determinada zona de código postal. En general, las búsquedas parciales son difíciles
de implementar con un DHT. El arte actual sugiere dividir cada cadena de búsqueda
en tokens. Cada token se codifica y se convierte en una clave. Por ejemplo, un
cliente llamado John Eric Brown se divide en tres nombres, cada uno de los cuales
se convierte en una clave, junto con el nombre completo (una cuarta clave).
Además, el nombre puede no ser único, por lo que hay que añadir un token más que
añade distinción: el número de la Seguridad Social. Como el lector puede prever, el
número de pares clave-valor es elevado por usuario. Además, aunque este
mecanismo añade la capacidad de realizar búsquedas basadas en tokens, no añade
una capacidad de búsqueda parcial completa: no será posible buscar (por ejemplo,
en la lista de usuarios cuyo apellido empiece por "Bro") no habrá una entrada en el
DHT (un par clave-valor) en esas claves que se hayan formado exclusivamente con
esos caracteres.
La conclusión es que no nos parece aconsejable distribuir la lista de suscriptores
en la DHT. Creemos que es mejor seguir con la práctica actual de almacenar la base
de datos de abonados en un único nodo de base de datos (redundante). Los datos de
los abonados pueden contener el nombre del abonado, la fecha de nacimiento, la
identidad privada del usuario, la dirección de facturación, el número de la Seguridad
Social, etc. Como los datos contienen la identidad privada del usuario, pueden
utilizarse para consultar la DHT y recuperar el resto de los datos, si es necesario. El
software de operación y mantenimiento puede realizar todas estas operaciones en
segundo plano, ocultándolas al operador. Por lo tanto, a ojos del , no será posible
determinar qué datos se almacenan de forma centralizada y cuáles en el DHT.
La figura 11.1 muestra la estructura de las claves y valores almacenados en la red
superpuesta DHT y una base de datos redundante.

HSS distribuido (HSS DHT)

En esta sección describimos la arquitectura de un HSS distribuido. La figura 11.2
presenta una red central IMS con el HSS distribuido. En la arquitectura propuesta,
varios nodos HSS que ejecutan una instancia de un algoritmo DHT forman una red
DHT superpuesta.
248 Manual del subsistema multimedia fP (fM£)

Base de datos redundante Red superpuesta DHT

Abonado IMPI 'n IMPU 'n

1an 1an
Perfil del servicio n
IMPI 1 IMPI 1 Perfil de servicio 2
Puntero Puntero
Perfil de servicio
Abonado 1
Puntero
0Autorización
a1 de
Datos relacionados con los servicios de red
Vectores de autenticación básica
abonados 0an
Por ejemplo, Billing
Info.
Enriterios iniciales de
filtrado 1

Datos adicionales

IMPI Puntero

FIGURA 11.1
Estructura de datos en la superposición HSS distribuida.

HSS DHT nodo 4

IP-CAN
HSS DHT nodo 3 HSS DHT nodo 1

HSS DHT
S-CSCF P-CSCF

CSCF

HSS DHT nodo 2

I-CSCF

FIGURA 11.2
Red superpuesta HSS distribuida.

Una consecuencia inmediata del diseño presentado en la sección anterior es que,

para un usuario determinado, sus datos no se almacenan en un único nodo de FSS,
sino que se distribuyen entre distintos nodos de FSS. Supongamos que a un usuario
se le ha asignado una identidad privada (IMPI1) y dos identidades públicas (IMPI2).
Distribuido fM£ 249

Abonado IMPI 'n IMPU 'n

1an 1an
Perfil del servicio n
IMPI 1 IMPU 1 Perfil de servicio 2
Puntero Puntero
Perfil de servicio
Abonado 1
Puntero
0 a 1 Autorización de
Datos relacionados con el servicios de red básica
usuario
Por ejemplo, Billing 0an
Info. I ni tial Criterios de
filtrado 1

Estado del registro

Opcional
S-CSCF asignado

IMPI Puntero

FIGURA 11.3
Estructura de datos en nodos HSS distribuidos.

identidades de usuario (IMPU1 e IMPU2). Las tres identidades se convierten en

hash, dando como resultado las siguientes claves:

key1 = H(IMPI1)
key2= H(IMPU1)
key3 = H(IMPU2)

Sus datos se denominan aquí valor1, valor2 y valor3, respectivamente. El valor1

se almacena en el nodo 1 de la DHT de FSS, responsable de la clave1. Del mismo
modo, el valor2 y el valor3 se almacenan en el nodo 2 y el nodo 3 de HSS DHT,
respectivamente, que son responsables de almacenar la clave2 y la clave3,
respectivamente. Los detalles reales dependen del algoritmo DHT utilizado. Por
ejemplo, Chord
[2] asigna a cada nodo un conjunto de claves, y cada clave se almacena en el sucesor
más cercano responsable de esa clave.
Tenga en cuenta que, según los principios IMS, las identidades públicas de
usuario URI SIP o URL TEL; por lo tanto, empiezan por las cadenas "sip:" o "[Link]
Sin embargo, las identidades privadas de usuario son identificadores de acceso a la
red, por lo que no empiezan ni por "sip:" ni por "[Link] Con una alta probabilidad
podemos afirmar que los espacios de direcciones actuales de las identidades de
usuario públicas y privadas no se solapan. Esto nos permite compartir el mismo
espacio de direcciones para las identidades de usuario públicas y privadas. La figura
11.3 muestra la estructura de las claves y valores almacenados en la red DHT del
HSS.
Como podemos ver, hay diferentes valores pertenecientes a cada clave. Para
claves creadas a partir de identidades privadas de usuario, el valor contiene la lista
de identidades públicas de usuario y vectores de autenticación. Opcionalmente, el
valor puede contener los punteros al nodo DHT del HSS que está almacenando el
valor de la identidad pública de usuario, así como el puntero a los datos del
suscriptor almacenados en el redundante
250 Manual del subsistema multimedia fP (fM£)

base de datos. Por otro lado, para claves creadas a partir de identidades públicas de
usuario, los valores consisten en al menos perfiles de servicio, el estado de registro,
la dirección de una S-CSCF asignada, y una identidad privada de usuario.
Opcionalmente, el valor puede contener el puntero al nodo DHT del HSS que
almacena el valor de la identidad privada de usuario par- ticular.

Replicación de datos
Los datos almacenados en los nodos DHT pueden replicarse a través de una red
superpuesta para garantizar la disponibilidad ubicua. Un mecanismo de replicación
automática garantiza que los datos críticos estén disponibles en la red DHT, incluso
si fallan varios nodos HSS. Los datos pueden replicarse en n nodos de la red DHT.
El valor de n depende del algoritmo DHT utilizado, así como de un supuesto
mecanismo de protección y de la disponibilidad de los datos objetivo.
El mecanismo de replicación puede variar entre sistemas DHT. En un ejemplo de
sistema basado en Chord [2], el mecanismo de replicación puede requerir que cada
nodo mantenga una lista de sus n sucesores más cercanos en el anillo Chord y
replique automáticamente los datos de un a los n n nodos HSS DHT sucesores de la
clave. Cuando falla uno de los nodos HSS DHT, otro nodo asume automáticamente
la responsabilidad del conjunto de pares clave-valor del que era responsable el nodo
que ha fallado.

Inscripción
El IMS convencional utiliza DIAMETER [8] como protocolo para realizar las funciones de
autenticación, autorización y contabilidad (AAA). Durante el registro, los comandos
DIAMETER UAR (solicitud de autorización de usuario), MAR (solicitud de
asistencia de mantenimiento) y SAR (solicitud de autorización de servicio)
transportan la identidad pública del usuario registrado y, si se utiliza el acuerdo de
autenticación y clave (AKA), también la identidad privada del usuario. Durante las
peticiones SIP entrantes, el comando DIAMETER LIR solicita la dirección de la S-
CSCF que sirve la identidad de usuario pública.
Al igual que el HSS en IMS, el overlay HSS distribuido también utiliza el
protocolo DIAM- ETER. Cada uno de los comandos DIAMETER mencionados no
deja de ser un mensaje DIAMETER que el cliente DIAMETER envía a cualquiera
de los nodos DHT del HSS. Si el nodo HSS DHT receptor no es el responsable de
almacenar la clave, la busca en su tabla DHT y reenvía el mensaje DIAMETER al
siguiente nodo, que a su vez repite la , hasta llegar al nodo HSS DHT responsable de
la clave. Este nodo HSS DHT devuelve los datos asociados a la clave buscada.
La figura 11.4 muestra el flujo de registro cuando se pone funcionamiento la
DHT de HSS. Suponemos que el primer nodo HSS DHT que recibe la solicitud
DIAMETER UAR o MAR no es el responsable de almacenar el par clave-valor, por
lo que el nodo actúa como proxy DIAMETER y reenvía la solicitud a un segundo y
tercer nodo, donde finalmente se almacenan los datos.
Distribuido fM£ 251

HSS HSS HSS

IMS P-CSCF I-CSCF DHT DHT DHT S-CSCF
Terminal nodo 1 nodo 2 nodo 3
REGISTRO SIP
REGISTRO SIP Diámetro
UAR UAR
UAR
SAU
Diámetro SAU
UAR
REGISTRO SIP
Diámetro MAR
MAR
MAR

MAA
MAA
Diámetro MAA
401 401 No autorizado
401 Sin
Registro SIP autorización
HSS DISTRIBUIDO
no autorizado
Diámetro
REGISTRO SIP UAR UAR
UAR
SAU
Diámetro SAU
SAU
REGISTRO SIP
Diámetro SAR
SAR
SAR
SAA
SAA

Diámetro SAA
200 OK
200 OK
200 OK

FIGURA 11.4
Flujo de registro en la superposición HSS distribuida.

Funcionamiento de la red
Cuando un operador desea recuperar (operación GET) datos pertenecientes a una
determinada identidad privada de usuario (por ejemplo, de un centro operativo), el
software O&M realiza un hash de esa identidad privada de usuario, localiza (según
un algoritmo DHT bien conocido) el nodo HSS responsable de almacenar los datos
y recupera todos los datos almacenados asociados a esa identidad privada de
usuario. Estos datos constituyen al menos la lista de identidades públicas de usuario.
A continuación, si es necesario, en un segundo paso el software de operación y
mantenimiento realiza un hash de cada una de las identidades públicas de usuario,
descubre los nodos HSS que almacenan los datos y recupera (operaciones GET) los
datos asociados a cada identidad pública de usuario (por ejemplo, el registro de la
identidad pública de usuario).
252 Manual del subsistema multimedia fP (fM£)

estado de funcionamiento, perfil de servicio y criterios de filtro iniciales y

compartidos. Por lo tanto, el software de operación y mantenimiento se comporta
como un cliente de la red superpuesta DHT.

Mejoras
Un inconveniente del diseño propuesto radica en que, para recuperar todos los datos
relacionados con un usuario, el software de operación y mantenimiento necesita
realizar varias operaciones GET en la DHT (al menos una por identidad de usuario
privada y otra por identidad de usuario pública). Una DHT basada en acordes es
capaz de localizar una utilizando O(log n) mensajes; por lo tanto, en un sistema en el
que hay 1.000 nodos HSS en la red superpuesta HSS DHT, el número de mensajes
podría ser de tan sólo tres. Así, para un usuario al que se le haya asignado una
identidad de usuario privada y dos identidades de usuario públicas, pueden ser
necesarios hasta nueve mensajes en la DHT para localizar todos sus datos.
Esto puede mejorarse almacenando en cada valor no sólo las otras identidades,
sino también el puntero que contiene la dirección del nodo HSS que almacena los
datos asociados a esa identidad (véase la Figura 11.1). Aunque esto mejora el
rendimiento al eliminar múltiples búsquedas de la misma clave, añade un poco más
de complejidad para mantener los punteros actualizados, especialmente en los casos
en los que la red superpuesta se autoconfigura (por ejemplo, debido a la entrada en
funcionamiento de nuevos nodos o a fallos de los nodos existentes).

I/S-CSCF distribuido (I/S-CSCF DHT)

En esta sección presentaremos una red superpuesta DHT que se forma combinando
las funciones I-CSCF y S-CSCF y . Cada uno de estos nodos se denomina nodo DHT
I/S-CSCF. Varios nodos DHT I/S-CSCF forman una red superpuesta similar a la red
superpuesta HSS descrita anteriormente. La figura 11.5 presenta una red central IMS
con la superpuesta I/S-CSCF distribuida. Hay que tener en cuenta que en este
escenario asumimos una
Elementos funcionales del FSS.
Cada nodo DHT I/S-CSCF es responsable de almacenar datos (valores) para un
número de claves. Así, están disponibles las típicas operaciones PUT (clave, valor) y
valor= GET (clave). Las claves se crean de forma similar a la de la red superpuesta
HSS: una clave se crea mediante hash de una identidad de usuario privada o de una
identidad de usuario pública, y el valor se almacena en el nodo DHT responsable de
dichas claves. Para un usuario determinado, se crean varios pares clave-valor.
El valor asociado a cada clave es muy similar al valor almacenado en la red
superpuesta HSS. Para las claves creadas a partir de identidades de usuario privadas,
el valor contiene al menos la lista de identidades de usuario públicas y,
opcionalmente, los punteros al nodo DHT I/S-CSCF que almacena el valor de la
clave pública.
Distribuido fM£ 253

FSS 1 HSS 2 HSS N

I/S-CSCF DHT
nodo 4

IP-CAN

I/S-CSCF DHT
nodo 3
I/S-CSCF DHT
nodo 1
I/S-CSCF DHT P-CSCF

I/S-CSCF DHT
nodo 2

FIGURA 11.5
Red superpuesta I/S-CSCF distribuida.

identidad de usuario. Para las claves creadas a partir de identidades de usuario

públicas, los valores consisten, como mínimo, en perfiles de servicio, estado de
registro, dirección de contacto, URI de agente de usuario globalmente enrutable
(GRUU), dirección de la función de control de sesión de llamada proxy (P- CSCF) e
identidad de usuario privada matriz y, opcionalmente, los punteros al nodo DHT I/S-
CSCF que almacena el valor de la iden- tidad de usuario privada. Los datos
almacenados en la red DHT se replican entre nodos DHT, como se ha explicado
anteriormente. La figura 11.6 muestra la estructura de los datos almacenados en los
nodos DHT I/S-CSCF.
Una consecuencia inmediata de este diseño es que aquellos usuarios con más de
una identidad de usuario pública asignada tienen sus datos repartidos entre distintos
nodos DHT I/S-CSCF. En el caso de que se utilice un conjunto de identidades
públicas de usuario registradas implícitamente (IRS), el nodo DHT I/S-CSCF que
está autenticando realmente al usuario debe actualizar (por ejemplo, realizando un
registro autorizado por terceros) el registro de cada identidad pública de usuario
registrada implícitamente almacenada (generalmente) en otros nodos DHT I/S-
CSCF. Como se ha indicado, un registro de terceros que se ejecuta en segundo plano
(como traf- fic de mantenimiento) resuelve el problema.
Un segundo problema surge cuando un usuario registra una segunda identidad
(que no está registrada implícitamente). El problema es que esta segunda identidad
puede ser autenticada en un segundo nodo DHT I/S-CSCF distinto del que almacena
el primer registro. Debido a esto, ese segundo nodo descarga del HSS una serie de
vectores de autenticación para realizar la autenticación, invalidando los vectores de
autenticación ya descargados (pero aún no utilizados) almacenados en el primer
nodo DHT I/S-CSCF. Si el endpoint utiliza una autenticación
254 Manual del subsistema multimedia fP (fM£)

IMPI 'n IMPU 'n

1an
Perfil del servicio n
Criterios iniciales de
IMPUCriterios
1 filtradoiniciales
n
de Perfil de servicio 2
filtrado n Puntero
Perfil de servicio
0a1 1

Autorización de
servicios de red básica

0an

Criterios iniciales de
Criteriosiniciales
Criterios inicialesdede
filtrado n
filtrado1 n
filtrado

GRUU

Póngase en contacto con

Información de presencia.

IMPI
Puntero

FIGURA 11.6
Estructura de datos en nodos I/S-CSCF distribuidos.

hacia este segundo nodo DHT I/S-CSCF, estará desincronizado. Este es un

problema común encontrado durante las primeras etapas de diseño del IMS; debido
a este problema, el IMS estándar requiere que todas las identidades pertenecientes al
mismo usuario sean manejadas por la misma S-CSCF. Una primera solución
consiste en restringir los nodos I/S-CSCF a la descarga de un único vector de
autenticación en lugar de descargar varios vectores. Actualmente, la arquitectura de
autenticación genérica (GAA) [9] también resuelve el problema.
La arquitectura DHT I/S-CSCF presentada simplifica el flujo de llamada para el
intento de sesión entrante. Como se muestra en la Figura 11.7, el flujo de llamada no
requiere un par de mensajes DIAMETER LIR/LIA (que son necesarios en IMS tra-
dicional) porque la DHT es capaz de encontrar la S-CSCF que está sirviendo la
identidad pública del usuario por sí misma.

Co-localización del servidor de presencia en el nodo I/S-CSCF

Una mejora inmediata de la red superpuesta I/S-CSCF consiste en ubicar un servidor
de presencia junto al nodo DHT I/S-CSCF para almacenar los datos relacionados
con la presencia. Dado que los datos de presencia están bastante relacionados con
los datos de registro y ambos están indexados por la identidad pública del usuario, el
esfuerzo necesario para almacenar
Distribuido fM£ 255

I/S-CSCF I/S-CSCF I/S-CSCF

DHT DHT DHT
nodo 1 nodo 3 P-CSCF
nodo 2

ENTRAVITE
DA SIP
SIP INVITE

SIP INVITE

SIP INVITE
SIP INVITE
I/S-CSCF DISTRIBUIDOS

FIGURA 11.7
Intento de sesión entrante con la DHT I/S-CSCF.

los datos relacionados con la presencia consiste simplemente en ampliar la

capacidad de almacenamiento del nodo y proporcionar capacidad de CPU adicional
para entregar notificaciones a los observadores. La capacidad no debería ser un
problema porque la idea de una es distribuir la computación entre diferentes nodos
que, individualmente, tienen una capacidad de computación limitada pero que,
cuando se combinan en la DHT, alcanzan una capacidad mayor que los nodos
normales no DHT. Así, en nuestra opinión, tiene sentido combinar el nodo DHT I/S-
CSCF con el servidor de presencia para manejar todos los datos relacionados con
SIP en un único nodo.

Uso del DHT I/S-CSCF con el DHT HSS

Obviamente, la DHT I/S-CSCF puede funcionar conjuntamente con la DHT HSS.
En ese caso, terminamos con dos DHTs separadas, cada una almacenando parte de
los datos necesarios para operar la red. La figura 11.8 presenta una red central IMS
con dos redes DHT separadas: HSS DHT y I/S-CSCF DHT.
La figura 11.9 muestra el flujo de registro cuando ambas DHTs están en . La
petición SIP REGISTER entra en la DHT I/S-CSCF y recorre una serie de saltos
hasta llegar al nodo de la DHT I/S-CSCF responsable de almacenar los datos
asociados a la identidad pública del usuario que se está registrando. A continuación,
el nodo DHT I/S-CSCF debe ponerse en contacto con el HSS para descargar los
datos de autenticación, el perfil de servicio, etc. Esto se realiza con mensajes
DIAMETER MAR. El proceso se ejecuta dos veces hasta que se consigue el
registro. Como podemos ver, el número de mensajes DIAMETER se reduce porque
la DHT es capaz de encontrar por sí misma la S-CSCF que está sirviendo la
identidad pública del usuario.
El flujo de llamada para un intento de sesión entrante no requiere un par de
mensajes DIAM- ETER LIR/LIA (que son necesarios en el IMS tradicional) porque
la DHT es capaz de encontrar por sí misma la S-CSCF que está sirviendo la
identidad pública del usuario.
256 Manual del subsistema multimedia fP (fM£)

HSS DHT I/S-CSCF

nodo 4 Nodo DHT 4

HSS DHT HSS DHT I/S-CSCF I/S-CSCF

nodo 3 nodo 3 Nodo DHT 3 Nodo DHT 1

I/S-CSCF
HSS DHT
DHT

HSS DHT I/S-CSCF

nodo 2 Nodo DHT 2

P-CSCF
IP-CAN

FIGURA 11.8
Red central IMS con dos redes DHT separadas.

I/S-CSCF I/S-CSCF HSS

DHT HSS
IMS DHT DHT DHT
P-CSCF nodo 1
Terminal nodo 1 nodo 2 nodo 2

REGISTRO SIP
REGISTRO SIP
REGISTRO SIP Diámetro
MAR MAR

Diámetro MAA
401
401 MAA
Sin
401 Sin autorización
autorización
Sin
I/S-CSCF DISTRIBUIDOS HSS DISTRIBUIDO
autorización
REGISTRO SIP REGISTRO SIP
REGISTRO SIP Diámetro
SAR SAR

Diámetro SAR
200 OK SAA
200 OK
200 OK

FIGURA 11.9
Registro con dos DHT paralelos.

Arquitectura IMS distribuida

Como hemos visto en las secciones anteriores, las dos redes superpuestas (HSS e
I/S-CSCF) comparten bastantes datos; por lo tanto, en gran medida se superponen.
Distribuido fM£ 252

Base de datos Red superpuesta DHT IMS

redundante

Abonado IMPI 'n IMPU 'n

1an 1an
Perfil del servicio
n
IMPI 1 IMPU 1 Puntero Perfil de servicio 2
Puntero
Perfil de servicio 1
Abonado 0a1
Puntero
Autorización de
servicios de red básica
Datos relacionados con los Vectores de autenticación
abonados 0an
Por ejemplo, Billing
Info. Criterios iniciales de
filtrado 1

Estado de registro GRUU

Contacto
P-CSCF

Información de
presencia.

IMPI Puntero

FIGURA 11.10
Estructura de datos en nodos DHT de IMS.

vuelta. La consecuencia es que a veces las búsquedas tienen que realizarse dos
veces: una en la DHT de HSS y otra en la DHT de I/S-CSCF. Una mejora inmediata
consiste en fusionar ambas DHT; en efecto, fusionamos el nodo HSS DHT con el
nodo I/S-CSCF DHT, y denotamos la entidad resultante como nodo IMS DHT. Los
datos de la DHT IMS se organizan de forma similar a los de las DHT HSS e I/S-
CSCF. Utilizamos las identidades privada y pública de los usuarios como índice,
que es utilizado por la operación hash para generar las claves. La figura 11.10
representa los datos que pueden almacenarse en cualquiera de estos nodos IMS.
La figura 11.11 muestra la estructura de la red superpuesta IMS totalmente
distribuida (IMS DHT), que es bastante similar a la HSS DHT y a la I/S-CSCF
DHT. Esta figura también muestra el flujo de registro en la red superpuesta IMS
DHT. El terminal móvil envía una petición SIP REGISTER a la P-CSCF a través de
una red de acceso de conectividad de protocolo de Internet (IP-CAN) (1). La
petición SIP REG- ISTER comprende IMPU1 y puede comprender un IMPI1. La P-
CSCF determina que la petición SIP REGISTER debe ser enviada al IMS
distribuido, es decir, a uno de los nodos IMS DHT en la red IMS DHT overlay. La P-
CSCF envía una petición SIP REGISTER al nodo IMS DHT 1 (2). El nodo IMS DHT 1
calcula una clave hash utilizando IMPU1. Basándose en su caché, el nodo IMS DHT
1 determina que la clave hash pertenece al rango de claves asociado con el nodo
IMS DHT 2. En consecuencia, el nodo IMS DHT 1 envía una petición SIP
REGISTER a la P-CSCF. En consecuencia, el nodo IMS DHT 1 envía el mensaje
SIP REGISTER
al nodo DHT 2 de IMS (3).
Se puede suponer que en un IMS distribuido pequeño (como se muestra en la Figura
11.11), la dirección IP del nodo IMS de destino se puede encontrar directamente en el
vecino
258 IMPU2 Manual del subsistema multimedia fP (fM£)
P-CSCF
Datos

IP-CAN
IMS DHT nodo 4

26
SIP 912

IMS DHT nodo 3

IMS DHT

14. REGISTRO SIP

15. SIP 200 OK
IMS DHT nodo 1

4. GET(IMPI1) 3
Implementado 5
mediante SIP 10
IMPI1 REGISTER o P2PP 11
SIP
Datos

IMPU1 IMS DHT nodo 2

Datos

FIGURA 11.11
Registro en la superposición DHT de IMS.

caché del nodo IMS 1. Sin embargo, en un IMS distribuido más grande, pueden ser
necesarios varios pasos de enrutamiento para encontrar el nodo responsable del
rango de claves al que pertenece la IMPU1 que se va a registrar.
Debido al hecho de que la clave hash puede no ser transportada en las peticiones
SIP REGISTER, cada uno de los nodos IMS DHT en el camino hacia el nodo IMS
destino puede necesitar calcular la clave hash usando el IMPU1 en la petición SIP
REGISTER. Por este motivo, se recomienda incluir la clave hash en las solicitudes
SIP REGISTER.
En respuesta a la recepción de la solicitud SIP REGISTER, el nodo IMS DHT 2
obtiene los datos asociados a la IMPU1. El nodo IMS DHT 2 también almacena
información sobre los datos asociados a la IMPU obtenidos en la solicitud SIP
REGISTER, como el estado de registro, la dirección P-CSCF y la dirección de
contacto del dispositivo. La información de presencia también se actualiza en
consecuencia.
El nodo DHT IMS 2 acusa recibo del registro a través de los nodos IMS que
procesaron la solicitud SIP REGISTER o emite una solicitud de autenticación al
dispositivo. Esto depende de si el usuario ha sido autenticado previamente o no. La
autenticación es un paso opcional en el procedimiento de registro.
Una solicitud de autenticación requiere que el nodo DHT 2 de IMS descargue uno
o más vectores de autenticación vinculados con la identidad privada de usuario
IMPI1 que está asociada con la identidad pública de usuario IMPU1 que se está
registrando. En
Distribuido fM£ 259

Para solicitar vectores de autenticación, el nodo IMS DHT 1 debe calcular el hash de
IMPI1 y utilizarlo como clave hash para encontrar el nodo IMS DHT 3 en la caché.
El nodo IMS DHT 3 almacena los datos asociados a IMPI1 que constituyen la lista
de identidades públicas de usuario IMPU1 e IMPU2 y los vectores de autenticación
utilizados para autenticar al usuario.
Utilizando el hash calculado de IMPI1, el nodo DHT IMS 2 envía una petición
GET al nodo DHT IMS 3 (4). La descarga de los datos asociados con puede utilizar
cualquier protocolo, por ejemplo, SIP o el protocolo peer-to-peer (P2PP) [10].
La respuesta que contiene los datos asociados a IMPI1 se envía al nodo DHT 2 de
IMS. El nodo DHT IMS 2 extrae un vector de autenticación de los datos recibidos y
crea una respuesta SIP que contiene un desafío de autenticación. La respuesta al
registro se envía en sentido inverso a través de los nodos que participaron en el
reenvío de la petición SIP REGISTER (5-7). La solicitud de autenticación se
transporta en forma de respuesta SIP 401 no autorizada.
Cuando el dispositivo recibe la respuesta SIP 401 no autorizada, responde con una
nueva solicitud SIP REGISTER que contiene la respuesta de autenticación. La
nueva petición SIP REGISTER atraviesa la P-CSCF y los mismos nodos IMS DHT
que la petición SIP REGISTER original hasta llegar al nodo IMS DHT 2 (8-10).
Una vez verificadas correctamente las credenciales, el nodo DHT IMS 2 envía un
acuse de recibo en forma de respuesta SIP 200 OK.
En este ejemplo, el usuario del dispositivo tiene un conjunto registrado
implícitamente (IRS), al que pertenecen IMPU1 e IMPU2. Dado que IMPU1 e IMPU2
pertenecen al IRS, el registro debe realizarse también para IMPU2 siempre que se
registre IMPU1 y viceversa. La información sobre la existencia de un conjunto
registrado implícitamente para una IMPU se almacena dentro de los datos asociados
a una IMPI. El nodo DHT IMS 2 crea una petición SIP REGISTER de terceros para
cada una de las IMPUs obtenidas del nodo DHT IMS 3 que pertenece al IRS. En la
Figura 11.1, esto consiste sólo en IMPU2. La petición SIP REGISTER se dirige al nodo
IMS DHT 4 que es responsable de almacenar la clave hash para IMPU2
(14). El nodo IMS DHT 4 obtiene de la solicitud SIP REGISTER recibida la
información de contacto, la dirección de la P-CSCF, el estado de registro y los datos
de información de presencia, además de otra información relevante, y los almacena
con los datos asociados a la IMPU2.
La figura 11.12 muestra el flujo de llamada de una solicitud INVITE entrante que visita
varios nodos DHT IMS hasta que llega al nodo DHT IMS 1, que almacena los datos
relativos a la identidad del usuario público llamado. El nodo IMS DHT 1 sustituye
el contenido del campo de cabecera original request-URI por información más
precisa extraída de la cabecera de contacto durante el registro del usuario. El nodo
IMS DHT 1 reenvía la petición SIP INVITE a la P-CSCF, que finalmente reenvía la
petición al destinatario de la llamada.
260 Manual del subsistema multimedia fP (fM£)

P-CSCF

IMS DHT nodo 4

IP-CAN

IMS DHT IMS DHT nodo 1

I MS DHT IMPU1
nodo 3
Póngase en
contacto con
P-CSCF URI

IMS DHT nodo 2

FIGURA 11.12
Intento de sesión entrante en la superposición DHT de IMS.

Comparación
En esta sección se compara la sobrecarga de mensajes introducida por las tres
configuraciones propuestas. Nuestro análisis asume que un usuario ha sido asignado
con un IMPI y dos IMPUs y tiene un IRS predefinido consistente en ambos IMPUs.
La tabla 11.1 presenta el número de mensajes SIP y DIAMETER en el registro
básico y el intento de sesión entrante para la red central IMS convencional (según el
3rd Generation Partnership Project [3GPP] TS 23.228 [1]) y tres soluciones
propuestas. Además del número de mensajes presentados en la Tabla 11.1, existe
tráfico adicional debido al propio DHT. La sobrecarga depende del algoritmo DHT
utilizado. Tiene dos elementos: la carga creada cuando los nodos se unen o
abandonan la DHT y la carga creada por el mantenimiento de la propia DHT. Como
en muchos casos se tratará de una DHT controlada por un operador, el número de
nodos será bastante estable. Nuevos nodos se unirán a la DHT cuando se necesite
escalabilidad. Los nodos dejarán la DHT cuando se apaguen por mantenimiento o
debido a condiciones de fallo. Ninguna de estas situaciones debería crear un tráfico
de sobrecarga significativo. El mantenimiento de la DHT creará más tráfico.
Como vemos, el proceso de registro en el DHT IMS ofrece ventajas sobre la
configuración con dos anillos DHT: a saber, un anillo DHT HSS y un anillo DHT
I/S-CSCF. Además, hay que tener en cuenta que una vez que el IMS
Distribuido fM£ 261

TABLA 11.1
Sobrecarga de mensajes para distintas configuraciones de IMS

Configuración Sesión entrante Inscripción

Núcleo IMS convencional 42 20
HSS DHT 40 +2 ( Mensajes DHTa 20 +10 ( Mensajes DHTa
HSS DHT +I/S-CSCF DHT 38 +5 ( Mensajes DHTa 12 +12 ( Mensajes DHTa
IMS DHT 38 +5 ( Mensajes DHTa 8 +8 ( Mensajes DHTa
(a
) Número de mensajes necesarios para localizar un recurso en una superposición. El algoritmo Chord es
capaz de localizar un recurso en una superposición con una alta probabilidad utilizando O(log n)
mensajes.

DHT está en , ya que el HSS está coubicado con la I/S-CSCF, no hay necesidad de
un protocolo DIAMETER que permita a las CSCF descargar o consultar datos
almacenados en el HSS. Algunos otros AS pueden necesitar implementar la interfaz
Sh hacia el HSS distribuido (esto depende del servicio real y de la necesidad de la
interfaz Sh), pero dicha interfaz podría ser fácilmente reemplazada por una
suscripción/publicación mejorada al paquete de eventos SIP reg [10].
Si comparamos la solución propuesta con la red central IMS convencional,
observamos que la DHT IMS requiere un número similar de mensajes en redes
pequeñas y un número ligeramente superior de mensajes para redes DHT
razonablemente grandes. Este es el precio que hay que pagar por tener una red
superpuesta de servidores autoorganizada. Creemos que las propiedades de robustez
y autoorganización de las DHT son capaces de reducir el OPEX significativamente
para justificar el ligero aumento de mensajes.
Como se ha explicado anteriormente, el número de mensajes puede minimizarse
manteniendo punteros entre los objetos de datos de la red superpuesta.

Conclusiones
En este capítulo se han estudiado varias combinaciones de DHT que sustituyen
la red central IMS por redes superpuestas autoorganizadas. Comprendiendo
tanto los inconvenientes como las ventajas de las soluciones propuestas,
llegamos a la conclusión de que una DHT compuesta por el HSS mejorado
combinado con nodos I/S-CSCF y servidores de presencia es la mejor de las
posibles alternativas presentadas para el .
Dado que los propios DHT son capaces de reaccionar a los cambios (por ejemplo,
la aparición o el fallo de un nodo), no es necesaria la intervención del operador. Esto
supone un importante ahorro en el OPEX. Sin embargo, la autoconfiguración del
sistema conlleva el coste de una sobrecarga adicional para la realización de
mecanismos de autoorganización y replicación.
En conclusión, creemos que el sistema DHT de IMS es aplicable a los operadores
que buscan soluciones escalables que requieran un OPEX mínimo.
262 Manual del subsistema multimedia fP (fM£)

Referencias
1. 3GPP TS 23.228: Subsistema multimedia IP (IMS).
2. Stoica, I., R. Morris, D. Karger, M. F. Kaashoek y H. Balakrishnan. 2001. Chord: A
scalable peer-to-peer lookup service for Internet applications. ACM SIGCOMM 2001,
San Diego, CA, agosto: 149-160.
3. Rowstron, A., y P. Druschel. 2001. Pastry: Scalable, distributed object loca- tion and routing
for large-scale peer-to-peer systems. IFIP/ACM International Conference on Distributed
Systems Platforms (Middleware), Heidelberg, Alemania, noviembre: 329-350.
4. Maymounkov, P., y D. Mazières. 2002. Kademlia: A peer-to-peer information system based
on the XOR metric. 1st International Workshop on Peer-to-Peer Sys- tems (IPTPS'02),
Cambridge, MA, marzo.
5. Aboba, B., y M. Beadles. 1999. El identificador de acceso a la red, RFC 2486.
6. Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks,
M. Handley, y E. Schooler. 2002. SIP: Protocolo de iniciación de sesión, RFC 3261.
7. Vaha-Sipila, A. 2000. URL para llamadas telefónicas, RFC 2806.
8. Calhoun, P., J. Loughney, E. Guttman, G. Zorn y J. Arkko. 2003. Protocolo base
DIAMETER, RFC 3588.
9. 3GPP TS 33.220: Arquitectura de autenticación genérica (GAA). Arquitectura de autenticación
genérica (GAA).
10. Baset, S., H. Schulzrinne y M. Matuszweski. 2007. Peer-to-peer protocol (P2PP),
borrador de Internet, draft-baset-p2psip-p2pp-01 (trabajo en curso).
Sección 3

Servicios
12
£plataformas de prestación de
servicios y multimedia £diseño de
servicios

Christopher J. Pavlovski

CONTENIDO
Introducción y visión general .......................................................................................... 266
Requisitos del diseño de servicios multimedia ............................................................. 268
Servicio multimedia ............................................................................................... 268
El contexto del cliente en la demanda de servicios ............................................ 269
Motivación de los operadores para la plataforma de prestación de servicios . 270
Modelo de negocio para terceros proveedores de servicios multimedia ......... 273
Marcos de referencia y arquitecturas en la prestación de servicios ............................ 274
Subsistema multimedia IP IMS) ........................................................................... 275
Plataforma de prestación de servicios (SDP basada en TI) ........................................ 277
Parlay y Parlay X....................................................................................................... 278
Software como servicio (SaaS) ............................................................................... 280
Marco de Prestación de Servicios MPS) ................................................................ 282
Arquitectura de referencia de la plataforma de prestación de servicios .......................... 283
Marco de prestación de servicios multimedia y
Servicios de comunicaciones ................................................................... 284
Capa de función de transporte .................................................................. 286
Capa de control de acceso ............................................................................. 287
Capa de funciones básicas ........................................................................ 288
Capa de servicios de integración .............................................................. 289
Capa de servicio: Diseño de servicios multimedia ...................................... 290
Capa OSS y BSS .......................................................................................... 291
Interacción entre subsistemas................................................................................. 291
Interacción con servicios multimedia HTTP ............................................. 292
Interacción de servicios multimedia SIP .................................................... 294
Modelo físico operativo ......................................................................................... 296
Tendencias en el diseño de servicios multimedia ......................................................... 298
Difusión multimedia ............................................................................................... 299
Servicios entre iguales............................................................................................... 300
Interacción multimodal .......................................................................................... 300
Contenido tridimensional ........................................................................................ 301

265
266 Manual del subsistema multimedia fP (fM£)

Resumen y conclusiones ................................................................................................. 302

Referencias ........................................................................................................................ 304

Introducción y
La disponibilidad y la gama de servicios multimedia han aumentado
considerablemente en los últimos años. En particular, la aparición de dispositivos
móviles capaces de soportar vídeo, telefonía y entretenimiento de audio ha
estimulado un mayor crecimiento de la prestación de servicios multimedia. El
proveedor de redes de telecomunicaciones se ha basado tradicionalmente en varias
redes para el suministro de sus servicios de telecomunicaciones. Entre ellas se
encuentran las redes de telefonía para los servicios de voz de línea fija estándar, las
redes móviles para las comunicaciones celulares y las redes de banda ancha para el
tráfico de datos a los mercados de consumidores y empresas. Las innovaciones en
multimedia digital han repercutido en los servicios de red tradicionales, como la
voz, convirtiéndolos en aplicaciones multimedia mejoradas que ya no requieren
complejas redes de telefonía. Los avances en vídeo también están destinados a
transformar soluciones de red complejas, como las videoconferencias multipartitas,
en otras aplicaciones multimedia. Aunque se discute si es el proceso de
convergencia de las redes o el avance de los servicios multimedia lo que fomenta
este tipo de transformación, la tendencia parece exigir una plataforma convergente
de tecnologías de la información y la comunicación (TIC) capaz de soportar toda
una serie de servicios multimedia, como telefonía, música, vídeo, juegos,
entretenimiento y combinaciones de los mismos.
Está claro que el planteamiento de redes dedicadas a cada dominio multimedia
tiene un atractivo limitado debido a los costes que supone desplegar y mantener
estos sistemas de ingeniería. De ahí que la convergencia de las redes de
comunicaciones esté motivada no sólo por la necesidad de soportar múltiples formas
de tráfico digital, sino también por la de amortizar los costes de implantación y
explotación de las redes subyacentes. Esta noción de amortización de costes también
es relevante para las plataformas TIC necesarias para soportar una variedad de
servicios multimedia. En un esfuerzo por sacar provecho de las redes de banda
ancha convergentes e introducir nuevos servicios de valor añadido, otro reto al que
se enfrentan los operadores es el enfoque adoptado para diseñar soluciones de
entrega de contenidos y servicios multimedia. La demanda de contenidos
multimedia por parte de los consumidores, unida a la complejidad de la prestación
de servicios multimedia enriquecidos, plantea retos en cuanto al despliegue y la
velocidad de comercialización de las nuevas ofertas. Históricamente, el
planteamiento para crear y desplegar servicios multimedia se ha centrado en
soluciones de silo o de punto único. Estas soluciones han funcionado bien para
atender las necesidades específicas del servicio previsto o de un conjunto de
servicios relacionados; sin embargo, tienen carencias en cuanto a la extensibilidad
para atender a los servicios multimedia más nuevos y emergentes.
£plataformas de prestación de servicios y multimedia £diseño de 262
servicios

Un enfoque más pragmático consiste en desarrollar una única plataforma

consolidada que sea capaz de soportar una amplia variedad de servicios multimedia
a través de varias redes de comunicación. Estos sistemas se denominan plataformas
de prestación de servicios (SDP); varias iniciativas de normalización han adoptado
la capacidad de abordar estos requisitos, basando su marco en una arquitectura de
plataforma para la prestación de servicios. Una de las iniciativas más recientes para
el diseño de SDP es el subsistema multimedia (IMS) IP (protocolo de Internet) [1];
sin embargo, otras implementaciones basadas en Parlay [2], arquitectura orientada a
servicios (SOA) [3] y diseños basados en TI [4,5] también son arquitecturas
candidatas y se han desplegado.
Las arquitecturas descritas en la literatura fomentan el tema común de establecer
una plataforma compartida capaz de ofrecer una amplia gama de servicios
multimedios al cliente. La ventaja fundamental del enfoque de plataforma es la
inclusión de un conjunto de capacidades comunes dentro de la plataforma que
pueden ser aprovechadas y compartidas por muchos servicios multimedia. De este
modo, se reduce el esfuerzo de desarrollo de nuevos servicios y el coste de
construcción y desarrollo de la plataforma se amortiza en una serie de servicios
multimedia que se despliegan posteriormente para aprovechar esta . Los despliegues
comerciales de soluciones SDP basadas en TI han sido capaces de ofrecer
contenidos multimedia con éxito a una amplia gama de usuarios [6]. Sin embargo,
estas soluciones presentan algunas limitaciones. Es más probable que una
arquitectura basada en un SDP combinado basado en IMS e IT pueda satisfacer los
requisitos más amplios de la prestación de servicios multimedia. Esta noción de
oferta combinada de prestación de servicios ha sido adoptada recientemente por el
TM Forum como una nueva iniciativa de normalización y se denomina marco de
prestación de servicios [7]. Dada la diversidad de las aplicaciones multimedia, las
plataformas de prestación de servicios basadas en IMS tienen por sí solas un reto
importante a la hora de abordar la amplia gama de requisitos multimedia. Por ello,
merece la pena estudiar varias características que se basan en arquitecturas SDP
existentes y probadas para comprender su aplicabilidad en una solución combinada
de IMS y SDP.
En este capítulo se describen los requisitos básicos para el diseño de servicios
multimedia mediante el análisis de las implantaciones actuales en el tipo de
servicios multimedia prestados y las relaciones del operador, el cliente y el
proveedor de servicios multimedia externo. A continuación, se describen las
arquitecturas y normas candidatas para construir plataformas de prestación de
servicios. Estas arquitecturas se contrastan en términos de sus capacidades para
abordar las amplias necesidades identificadas para el cliente, el operador de
telecomunicaciones y el desarrollador de aplicaciones de terceros. A continuación,
se esboza una arquitectura consolidada que reúne las características de las
arquitecturas alternativas, combinando el marco IMS y las actuales SDP basadas en
TI. Por último, se exploran las tendencias en el diseño de servicios multimedia y
plataformas de prestación de servicios para el operador. Estas tendencias incluyen la
radiodifusión multimedia, la entrega de contenidos entre pares, los contenidos o
servicios tridimensionales y las tecnologías multimodales emergentes para mejorar
la interacción multimedia.
268 Manual del subsistema multimedia fP (fM£)

Requisitos del diseño del servicio multimedia

En esta sección se presentan algunos antecedentes para definir un servicio
multimedia y cómo está evolucionando para el mercado de las telecomunicaciones.
Un punto clave es que la demanda de un gran número de servicios multimedia
(como vídeo, voz, juegos y entretenimiento) hace que las implementaciones
discretas sean demasiado costosas, lo que impulsa la necesidad de un enfoque de
plataforma para el diseño de servicios. Los aspectos económicos de la creación de
una plataforma de prestación de servicios se exponen con ejemplos de la eficacia
obtenida en la práctica.
A la vista de las partes interesadas, el modelo de negocio a abordar justifica la
consideración de las necesidades, motivaciones y relaciones de tres entidades clave:

(1) cliente;
(2) operador de telecomunicaciones; y
(3) proveedor de servicios multimedia (también conocido como desarrollador
externo).

Antes de exponer las características de cada entidad, se esboza una definición más
formal del término servicio multimedia.

Multimedia Servicio
En la práctica, el servicio multimedia tiene dos facetas: el contenido multimedia,
que se suministra, y el acto de suministrar ese contenido. El contenido multimedia
suele incluir texto, datos, voz, imágenes y vídeo. La gama de contenidos va mucho
más allá e invariablemente incluirá combinaciones de dos o más formas de medios.
En algunos casos no se suministra ningún producto o contenido, sino que se presta
un servicio. Esto significa que no todos los servicios multimedia se traducen en la
entrega de contenidos al usuario. Por ejemplo, un servicio multimedia que permite a
varios usuarios acceder a videoconferencias no proporcionará contenidos explícitos.
En este caso, son los usuarios los que proporcionan el contenido, a través de su
interacción de vídeo y voz, y el proveedor de servicios multimedia proporciona la
infraestructura y la tecnología para llevar a cabo esta forma de interacción. Por lo
tanto, un servicio multimedia es un término que se utiliza cándidamente para
describir estos dos aspectos de la interacción multimedia. Más formalmente, un
servicio multimedia implica (1) el suministro de contenidos multimedia como bien y
(2) el suministro de servicios (equivalente no material de un bien) que permiten el
intercambio de contenidos multimedia entre las partes. En términos más sucintos, un
servicio multimedios se refiere al suministro de contenidos o servicios multimedia
[6].
Referirse a un servicio multimedia también tiene un contexto interesado. Como
consumidor del servicio, un usuario aplica este término para designar el contenido o
servicio multimedia que se le va a suministrar. Sin embargo, los tecnólogos suelen
referirse a la infraestructura subyacente que suministra el servicio. La capacidad de
responder a solicitudes multimedia requiere tecnología para suministrar el contenido
o ser-
£plataformas de prestación de servicios y multimedia £diseño de 269
servicios

vicio. Esto implica el uso de tecnologías de la información y la comunicación que se

manifiestan como aplicaciones informáticas o infraestructura de
telecomunicaciones. De este modo, el término servicio multimedia también puede
utilizarse para designar (1) la oferta de contenidos o servicios (perspectiva del
usuario) o (2) las tecnologías subyacentes que permiten la oferta de contenidos o
servicios (perspectiva del tecnólogo).
Este capítulo se centra en el modo en que un servicio multimedia y una plataforma
de prestación de servicios se relacionan durante la realización del servicio. En el
contexto de una plataforma de prestación de servicios, la plataforma representa la
tecnología de infraestructura que es un habilitador. Las aplicaciones informáticas y
la infraestructura de telecomunicaciones que acceden a las funciones de una
plataforma de prestación de servicios representan, por tanto, los servicios
multimedia desde la del tecnólogo. De ahí que el término servicio multimedia se
utilice a menudo para designar el contenido suministrado, el servicio prestado o la
aplicación y la tecnología que proporcionan el contenido o el servicio. En este
capítulo, el término servicio multimedia se utilizará principalmente para designar el
contenido y el servicio suministrados. Cuando se hace referencia a la tecnología o
aplicación subyacente, se dan otras aclaraciones, como aplicación o servicio de
terceros o externo.
Una última observación sobre los servicios multimedia es su descomposición en
servicios de comunicación (basados en la telefonía) y servicios basados en las TI. Se
trata de los servicios de comunicación, como los servicios de telefonía mejorados, y
los servicios basados en TI que incluyen contenidos multimedia generales.
Respectivamente, éstos suelen estar soportados por SDP basados en IMS e IT.

El contexto del cliente en el servicio Demanda

La demanda de servicios multimedia por parte de los clientes ha dictado muchas de
las tendencias observadas en su diseño y despliegue. De ahí la importancia de
comprender el comportamiento que influye en el acceso de los clientes. Las
propiedades clave del diseño de servicios que influyen en los clientes pueden verse
en los siguientes términos [8]:

• coste del servicio multimedia;

• facilidad de acceso y uso de los contenidos (calidad del servicio); y
• conveniencia del servicio multimedia.

La figura 12.1 ilustra la relación entre estas tres propiedades de un servicio

multimedia [8]. El aspecto de la deseabilidad puede examinarse de dos maneras. La
calidad del contenido determinará su atractivo para el usuario; la llamada killer app,
en la que todo usuario desea acceder al contenido o servicio, representa el más
deseable de los servicios. Cuanto más atractivo sea el contenido, mayor será su
potencial para atraer y retener clientes. En realidad, sin embargo, esta propiedad de
los servicios multimedia varía considerablemente, por lo que garantizar una cartera
amplia ayudará a atraer un amplio interés de los consumidores. Los estudios han
demostrado cuáles son los tipos de contenidos a los que se accede con más
frecuencia
220 Manual del subsistema multimedia fP (fM£)

Servicio
Deseabilidad

Coste de Facilida
Servicio d de
Acceda

FIGURA 12.1
Modelo de servicios multimedia.

Los más populares son los juegos, la música y los contenidos genéricos descargables,
como tonos de llamada, fondos de pantalla e imágenes [6].
La facilidad de acceso encarna el aspecto de usabilidad de los multimedia (es
decir, la calidad del servicio). En esta propiedad influyen la compatibilidad de los
dispositivos con los contenidos y el diseño general de la usabilidad. Una de las
sorpresas de Internet en sus inicios fue que los clientes estaban dispuestos a soportar
tiempos de respuesta deficientes para acceder a los contenidos y servicios
disponibles [8]. Una inspección más detallada de los primeros tiempos de Internet
pone de manifiesto que muchos de los servicios a los que se accedía eran gratuitos,
lo que pone de relieve la tercera asociación -el coste del servicio- en el
comportamiento de los clientes. De este modo, se puede ver que si una propiedad de
esta relación es deficiente, es posible alterar las otras dos propiedades para
garantizar el interés del cliente. Por ejemplo, si la calidad del servicio o la facilidad
de acceso se ven afectadas, habrá que modificar en consecuencia el aspecto del coste
del servicio multimedia. Este modelo es útil para representar esta relación, ya que
sirve de recordatorio para equilibrar estas características del diseño de servicios
multimedia [8,9]. Cuando se examinan más a fondo los modelos de negocio, se
presta mucha atención a la forma en que el operador puede facturar a los clientes los
servicios prestados, centrándose en los instrumentos de facturación de prepago y
pospago. Para apoyar el modelo de negocio, la capacidad de realizar pagos requiere
una instalación segura y de confianza. El operador de telecomunicaciones se
considera un medio de confianza. Los clientes son reticentes a utilizar tarjetas de
pago por Internet. A la inversa, parece que hay pocas reservas a la hora de facilitar
los datos de la tarjeta de pago por teléfono a un comerciante. De ello se deduce que
los clientes consideran seguros los cargos que aparecen en la factura del operador
[9]. Además, el proceso de facturación es familiar para los clientes y hay poca
necesidad de establecer y gestionar servicios adicionales.
de facturación.

Motivación del operador para la plataforma de prestación de servicios

Históricamente, el enfoque tradicional del desarrollo de servicios multimedia para
dispositivos móviles puede considerarse como soluciones puntuales [4]. Estas
también son
£plataformas de prestación de servicios y multimedia £diseño de 221
servicios

Lógica empresarial única

Servicios de presentación

Funciones de apoyo (infraestructura)

Integración de sistemas (redes e informática)

FIGURA 12.2
Solución a medida.

se denominan sistemas a medida, lo que significa que se trata de un servicio

adaptado o hecho a la medida de las necesidades individuales. El desarrollo de
soluciones tradicionales se ha centrado en la creación de las funciones y capacidades
necesarias para apoyar la prestación un servicio multimedia específico. Por ejemplo,
los operadores de telefonía móvil adoptaron rápidamente los servidores de descarga
de juegos, y las primeras soluciones incluían una serie de funciones de presentación
e infraestructura de apoyo, como la gestión de derechos, el registro de usuarios, la
suscripción, la facturación y las funciones de clasificación. El diagrama de la figura
12.2 ilustra esta noción, donde puede verse que, además de la lógica empresarial
exclusiva del servicio multimedia, la solución requiere una serie de funciones de
apoyo para lanzarlo comercialmente.
Los servicios de presentación incluyen funciones que permiten al usuario
registrarse en un servicio, lo que suele hacerse seleccionando el servicio deseado y
aceptando las condiciones anunciadas. La interacción con el usuario se realiza a
través de una interfaz basada en la web para navegar por el menú del catálogo de
servicios, en el que también se detalla información sobre precios. Las funciones de
apoyo incluyen el conjunto de servicios de infraestructura que no están directamente
relacionados con el servicio multimedia, pero que suelen ser comunes a una serie de
servicios. Esto incluye servicios de seguridad autenticación y autorización,
auditoría, gestión de errores y seguimiento del tráfico o del uso para facturar los
servicios prestados. Las capacidades de integración de sistemas implican el esfuerzo
asociado a la integración con los sistemas de TI, incluidos los sistemas de
facturación, liquidación y gestión de las relaciones con los clientes. Además, esta
capa representa la integración con los elementos y canales de red para prestar
servicios multimedia.
Al ver la amplitud de la capacidad necesaria para apoyar la de nuevos servicios
multimedia, es evidente que el servicio real que se presta representa una parte de la
lógica empresarial global necesaria para poner el servicio a disposición del usuario
final. Se ha analizado la distribución del esfuerzo en el desarrollo de servicios
multimedia, atribuyéndose aproximadamente el 30% del esfuerzo a la lógica
empresarial única del servicio multimedia [4]; se trataba de una descripción
generalizada de la distribución del esfuerzo. En un análisis más
222 Manual del subsistema multimedia fP (fM£)

31%
49%

10%
10%

Lógica empresarial Presentación

Infraestructura Integración

FIGURA 12.3
Distribución del esfuerzo para el servicio multimedia móvil.

En el análisis específico de la implementación de una solución puntual (análisis del

código fuente), queda claro que la mayor parte de la actividad de desarrollo se
atribuye al esfuerzo combinado de la presentación, la infraestructura y la lógica de
integración (véase la figura 12.3). La observación clave sobre el diseño del servicio
es que los servicios comunes (presentación, infraestructura e integración) se repiten
para cada nuevo servicio. Incluir esta capacidad en una única plataforma común de
prestación de servicios sugiere que dos tercios del esfuerzo pueden amortizarse a lo
largo de muchas aplicaciones multimedia. En la práctica, sin embargo, los
operadores dispondrán de una serie de sistemas ya existentes capaces de soportar
muchas de las funciones comunes descritas, aunque siga existiendo la necesidad de
integrarse con estos sistemas. Estas nociones constituyen una motivación
fundamental para que los operadores combinen un conjunto de funciones comunes
en una plataforma de prestación de servicios, que luego puede ser
aprovechado y utilizado por diversas aplicaciones multimedia [4].
El modelo SDP incluye la presentación, las funciones de apoyo y el esfuerzo de
integración de sistemas común a muchos servicios multimedia. Generalmente,
muchas de las aplicaciones multimedia son desarrolladas y desplegadas
internamente por el operador. Sin embargo, el SDP también puede ser utilizado por
proveedores externos de contenidos o servicios multimedia; éstos son los
desarrolladores terceros. Aquí radica otra motivación para que los operadores
adopten este arquetipo. Desvincular el esfuerzo de creación de servicios multimedia
de los servicios comunes introduce un modelo de negocio en el que los proveedores
externos pueden crear las aplicaciones que ofrecen contenidos y servicios a través
del SDP del operador móvil [10].
El operador móvil aloja el SDP y proporciona un conjunto de servicios comunes
al desarrollador externo de servicios multimedia (véase la figura 12.4). El operador
de telefonía móvil posee y mantiene la relación con los usuarios y puede llevar este
mercado de consumidores al proveedor externo de servicios. Una de las principales
ventajas de esta relación es que, una vez construida la plataforma, el operador puede
recurrir a terceros para financiar el desarrollo de nuevos servicios. Otra motivación
es la capacidad que ofrece esta plataforma para apoyar el rápido despliegue de
nuevos servicios [10].
£plataformas de prestación de servicios y multimedia £diseño de 223
servicios

Aplicaciones multimedia ...

(Lógica empresarial)

Plataforma de prestación de servicios

(Presentación, funciones de apoyo, TI e

integración de sistemas de red)

FIGURA 12.4
Modelo de plataforma de prestación de servicios.

Así pues, la motivación del operador puede resumirse en el abanico de eficiencias

que ofrece el enfoque SDP. A su vez, esto reduce los costes de despliegue tanto para
el operador como para el desarrollador externo.

Modelo de negocio para servicios multimedia de terceros Proveedor

Una de las principales motivaciones del proveedor externo de servicios
multimedia*, que también puede ser una empresa, es el acceso comercial a la gran
base de clientes que posee y gestiona el operador de telecomunicaciones [10]. Este
acceso es posible gracias al soporte SDP para aplicaciones multimedia de terceros
alojadas externamente. El cliente percibe ventajas en la facilidad de acceso a través
de una interfaz SDP consolidada y una mayor gama de servicios de contenidos
multimedia. Dado que debe existir una oportunidad de ingresos significativa para
llamar su atención [11], el desarrollador externo está motivado principalmente por el
beneficio de una mayor oportunidad de mercado.
Existen varias motivaciones adicionales para el proveedor de servicios externo. A
partir del análisis de la complejidad de la aplicación, el desarrollador externo puede
centrarse en la lógica empresarial del servicio que pretende prestaraprovechando así
las capacidades combinadas del SDP, incluidas las funciones de red, facturación,
liquidación, gestión de clientes, seguridad y gestión de servicios multimedia. Esto
reduce el coste y el esfuerzo de desarrollar nuevos servicios multimedia, lo que a su
vez reduce el tiempo necesario para lanzar nuevos productos al mercado. Un factor
adicional es que se reduce eficazmente la complejidad de los dispositivos. Además,
el proveedor de servicios externo se abstrae de los dispositivos, lo que facilita su
despliegue [8]. Esto es especialmente importante porque los contratos de telefonía
móvil convencionales se basan en planes de 12, 18 o 24 meses. Esta práctica
favorece una alta tasa de rotación de dispositivos. Además, las capacidades
mejoradas de los nuevos dispositivos exigen un mayor rigor en las pruebas para
garantizar la compatibilidad de los contenidos reproducidos.
* Sinónimo del término desarrollador externo.
224 Manual del subsistema multimedia fP (fM£)

140

120

100

80

60

40

20

0
Año 1 Año 2 Año 3 Año 4 Año 5

FIGURA 12.5
Dispositivos multimedia compatibles.

El gráfico de la Figura 12.5 muestra el soporte operativo necesario para los

dispositivos, desde 10 inicialmente hasta 120 en última instancia, durante un periodo
de 5 años para un operador móvil típico. Obsérvese que estos datos no ilustran toda
la complejidad del soporte de dispositivos necesario; por ejemplo, las variaciones de
dispositivos en las revisiones de firmware añaden dificultad. Es evidente que se
pueden obtener beneficios ocultando esta complejidad para un número creciente de
dispositivos.
Otra tendencia emergente entre los operadores móviles y los proveedores de
servicios externos es el estilo de de los operadores móviles virtuales (OMV). En
este caso, un operador virtual vende servicios de red sin poseer una red básica. En su
lugar, el MVNO aprovecha la infraestructura de red de un operador existente. En
esta relación comercial, el operador de red también proporciona los contenidos y
servicios multimedia, incluido el acceso a contenidos de terceros proveedores de
servicios. De este modo, el MVNO es también un proveedor de servicios de
terceros, que funciona a la vez como revendedor y como proveedor de servicios
multimedia adicionales. Este modelo de negocio complica aún más los acuerdos de
facturación que deben establecerse y es factible con el enfoque SDP para el diseño
de servicios multimedia.

Marcos y arquitecturas de referencia en la prestación de servicios

Aunque IMS está ganando una amplia aceptación como arquitectura de referencia
para las plataformas de prestación de servicios, varios marcos y adicionales cuentan
con una capacidad de prestación de servicios. En esta sección se describen los
distintos marcos y arquitecturas de referencia que pueden aplicarse al diseño de
soluciones SDP. Se incluyen IMS, Parlay-X, SDP basado en TI y el
£plataformas de prestación de servicios y multimedia £diseño de 225
servicios

marco de prestación de servicios (SDF) emergente del TM Forum. Cada norma o

marco tiende a centrarse en una competencia concreta dentro de la prestación
multimedia, y contribuyen colectivamente a una capacidad global de prestación de
servicios. En el contexto más amplio de las iniciativas de transformación de los
operadores, que suelen incluir la transformación de los sistemas de apoyo operativo
(OSS) y de los sistemas de apoyo empresarial (BSS), los subsistemas de prestación
de servicios multimedia también se denominan colectivamente sistemas de apoyo a
la prestación (DSS).
Una clasificación adicional de los marcos SDP es su orientación hacia la red de
telecomunicaciones o los aspectos de tecnología de la información del dominio del
problema de prestación de servicios. Esto también se conoce como diseño centrado
en la red o en las TI. Estos enfoques también se conocen como diseños SDP basados
en la red o en las TI [10,12]. Los arquetipos de plataforma han surgido reflejando la
herencia del organismo de normalización del que surgen. Las plataformas basadas en
los estándares y marcos Parlay-X o IMS pueden clasificarse como centradas en la
red; los estándares SDP y SOA tradicionales son iniciativas basadas en TI [10].

Subsistema multimedia IP (IMS)

El estándar IMS está especificado por el consorcio 3rd Generation Partnership
Project (3GPP), que se define más formalmente como la arquitectura de red de
próxima generación (NGN) para la prestación de servicios multimedia a través de
redes IP móviles y fijas [13]. La literatura sobre IMS es amplia y se centra en los
servicios multimedia habilitados para las telecomunicaciones, como las aplicaciones
peer-to-peer, el streaming de vídeo y otras aplicaciones relacionadas con el
protocolo de inicio de sesión (SIP). IMS como estándar para construir plataformas
de prestación de servicios está claro en la literatura [6,14,15]. Aunque en la práctica
los operadores se enfrentan a una serie de barreras a la hora de desplegar un modelo
de servicio completo basado únicamente en IMS, éstas giran principalmente en
torno a la justificación comercial de IMS para prestar únicamente servicios de
comunicaciones. Como tal, las implementaciones han sido limitadas, con sólo unos
pocos ensayos y despliegues en marcha [16]. A pesar de ello, los operadores se han
comprometido a realizar despliegues limitados para estar preparados para la próxima
aplicación revolucionaria.
Las normas IMS se centran en los aspectos de red de la prestación de servicios,
incluyendo tanto el control de red (tráfico de señalización) como la prestación de red
(tráfico de tienda de campaña) de servicios multimedia. Aunque la visión orientada a
la red es una perspectiva compartida del estándar IMS [7,17], las capacidades
disponibles son claramente compatibles con otros servicios basados en IP, con el
SIP adoptado como estándar para la comunicación de aplicaciones. Los
componentes clave de IMS se distribuyen entre planos de servicio que categorizan
las funciones proporcionadas. Hay varias capas (planos) funcionales de IMS que
consisten en las capas de usuario, red de acceso, transporte, control y
servicio/aplicación
Los dispositivos del plano de usuario establecen una conexión IP encapsulada SIP
con las aplicaciones situadas en el plano de servicio. La red de acceso soportada por
IMS incluye el sistema global para comunicaciones móviles (GSM), wide-

* Punto de vista expresado por operadores con operaciones globales de telecomunicaciones.

226 Manual del subsistema multimedia fP (fM£)

Plano de usuario Capa de acceso Plano de transporte Plano de control Aplicaciones

Radio
BCF HSS SIP
Red

SGSN/GGSN CSCF Parlay

Banda ancha

Media GW MGCF CAMELLO

WLAN
MRFP MRFC Otros

FIGURA 12.6
Visión general del subsistema multimedia IP.

banda CDMA (acceso múltiple por división de código), CDMA2000, redes de área
inalámbrica y tecnologías de banda ancha fija. Los planos de transporte y control
proporcionan funciones de prestación de servicios como la calidad de servicio, la
autenticación de dispositivos y la gestión de sesiones. El plano de servicio está
directamente relacionado con los servicios de aplicación basados en IP que se
despliegan, que suelen incluir mensajería, , presencia y contenidos multimedia
mejorados como IPTV y videotelefonía. El diagrama de la Figura 12.6 ilustra
brevemente los planos de IMS y describe algunos de los subsistemas funcionales
clave.
Examinando más detenidamente la Figura 12.6, el plano de transporte contiene los
elementos de red para interconectarse a varias redes de comunicación. Incluye nodos
como el nodo de soporte GPRS (servicio general de radio por paquetes) de pasarela
(GGSN) y el nodo de soporte GPRS de servicio (SGSN); servidores de medios,
incluido el procesador de funciones de recursos de medios (MRFP) para reproducir
anuncios; y pasarelas de medios (MGW) para interconectar el tráfico IP con otras
redes como la red telefónica pública conmutada (PSTN). Las funciones de control
de medios y de sesión residen en el plano de control. El establecimiento de la sesión
lo gestiona la función de control de sesión de llamada (CSCF), que conecta al
usuario con la aplicación correcta en el plano de servicio. El perfil de usuario y los
datos de autenticación se almacenan en el servidor de abonado de origen (HSS) y la
CSCF accede a ellos durante el establecimiento de la sesión SIP. El controlador de
función de recursos de medios (MRFC) actúa como intermediario entre el MRFP y
las aplicaciones de medios para conferencias, itinerancia y control de medios. Varios
nodos gestionan el MGW como parte de la función de control, como la
interconexión entre IP y SS7.
Los tipos de aplicaciones soportados por la capa de aplicación o servicio incluyen
aplicaciones SIP, CAMEL y OSA/Parlay. Esta capa también está pensada para atender a
otras aplicaciones Web basadas en IP. Aunque IMS atiende a varios tipos de
aplicaciones, no hay ningún detalle de estandarización explícito con respecto a la
integración y soporte de una mayor variedad de servicios multimedia, especialmente
de proveedores de servicios externos [10].
£plataformas de prestación de servicios y multimedia £diseño de 222
servicios

Dispositivos Pasarelas Capa de acceso Servicios

centrales

SG/GGSN Modelos

para terceros
Registr de carga

Aplicaciones
WSG
Radio o de
Parlay usuarios
Registrado
r de
WAP GW Master servicios
Banda ancha Auth. Server

Iteg. Autobús
SDP
Loc. Servidor Portales

Registro
WLAN Mensajería de Servidores
dispositi de
OSS/SSB
descarga
Sistemas
FIGURA 12.7
Visión general del PDE basado en TI.

Plataforma de prestación de servicios (basada en TI SDP)

La mayoría de los SDP desplegados actualmente se basan en una visión centrada en
TI del dominio del problema [6]. Hay muchos proveedores de TI y redes que
proporcionan marcos para desarrollar un SDP, y las soluciones se han centrado
principalmente en la integración con sistemas OSS/BSS y el soporte necesario para
aplicaciones multimedia alojadas tanto interna como externamente. Las aplicaciones
suelen ser creadas por desarrolladores externos o proveedores de
servicios/contenidos externos y requieren una serie de capacidades de SDP de apoyo
que mejoran las funciones básicas disponibles para el desarrollador de la aplicación.
Las capacidades adicionales son los servicios de telecomunicación y facturación
ofrecidos por el SDP, que permiten a terceros vendedores participar en el mercado
[18]. El tercero externo obtiene ingresos de sus aplicaciones multimedia. Por lo
tanto, lo ideal es que el SDP ofrezca funciones que permitan al desarrollador externo
apoyar y gestionar su cartera de aplicaciones. Es importante observar que una
característica vital de un SDP es la capacidad de integrarse con aplicaciones
externas e internas de forma coherente y abstracta. Para ello se utiliza una pasarela
de servicios Web (WSG) que proporciona un conjunto estandarizado de servicios
Web (véase la figura 12.7). Normalmente, estos mismos servicios Web también son
utilizados por aplicaciones multimedia externas e internas.
A la necesidad de soportar aplicaciones multimedia se añade la de integrarse con
los sistemas informáticos y las interfaces de red existentes. Dado que muchos de los
servicios multimedia requieren mecanismos de cobro alternativos, es necesario
integrarlos con sistemas de facturación de pospago para cargos recurrentes y con
sistemas de pago por uso para el cobro en tiempo real. Ambos aspectos del cobro
suelen estar disponibles como servicio web para aplicaciones externas, de modo que
los usuarios dispongan de varias opciones de pago por el uso del servicio
multimedia. Además, a medida que los clientes interactúan con un servicio
multimedia, la aplicación
228 Manual del subsistema multimedia fP (fM£)

interrogará al SDP a través de la WSG para cobrar al cliente. Generalmente se

accede a varios sistemas informáticos adicionales, como la gestión de las relaciones
con los clientes (CRM), la autenticación, autorización y contabilidad (AAA) y las
redes financieras para otras opciones de pago. La integración del SDP, los sistemas
de TI y las aplicaciones es crucial para ofrecer una experiencia coherente a los
clientes cuando acceden a los contenidos desde un dispositivo móvil o un dispositivo
fijo de escritorio.
Aunque el SDP basado en TI tiene una dependencia obvia de la red para la
entrega de contenidos, a menudo las soluciones se han centrado más en el tráfico de
contenidos y datos. En cambio, las normas IMS se han centrado en el aspecto de
señalización (control) de la prestación de servicios en las capas de red. El acceso a
los elementos de red suele especificarse en una capa IP; por lo tanto, un SDP basado
en TI suele reutilizar la infraestructura y la capacidad de conectividad de red
existentes. Esto incluye las pasarelas GGSN/SGSN, el acceso Parlay o Jain para
aplicaciones que requieren control de llamadas o de red, servidores de localización y
funciones de mensajería (servicio de mensajes multimedia [MMS], servicio de
mensajes cortos [SMS] y protocolo simple de gestión de red [SNMP]). Una vez
más, estas funciones de red elementales se abstraen y se ponen a disposición de
aplicaciones externas de terceros para que puedan desarrollarse servicios multimedia
enriquecidos.
Los componentes adicionales mostrados en la Figura 12.7 constan de varios por-
tales y servidores de descarga que proporcionan menús de contenidos y funciones de
gestión de usuarios; registros para gestionar servicios multimedia, dispositivos y
clientes; e instalaciones básicas de tarificación y cobro para aumentar los sistemas
de facturación existentes. Las capacidades de estos componentes se tratan con más
detalle en la sección "Arquitectura de referencia de la plataforma de prestación de
servicios", donde se presenta una arquitectura de referencia SDP combinada basada
en IMS e IT.

Parlay y Parlay X
Históricamente, se ha considerado que la red central se gestionaba como una red
segura sin acceso abierto al dominio de TI. La industria y las tendencias normativas
han ejercido una presión considerable sobre el operador para que abra sus redes a
partes externas para el uso de aplicaciones de TI. La iniciativa Parlay pretende
normalizar este acceso abierto a la red central. Esto, a su vez, favorece el desarrollo
de aplicaciones mejoradas basadas en la telefonía. Más concretamente, el grupo
Parlay ha definido interfaces de programación de aplicaciones (API) de red (API de
acceso abierto a servicios) para apoyar la creación de servicios de
telecomunicaciones [17].
El estándar Parlay también ha intentado ampliar el conjunto de servicios con
características adicionales que soporten la prestación de servicios multimedia
generales y aplicaciones cliente. Aunque la pasarela Parlay es el nodo que se integra
con la red central, el servidor Parlay-X es una abstracción más de la pasarela Parlay
como interfaz de servicio Web para la integración de aplicaciones cliente [19]. Puede
verse como un proxy de la pasarela Parlay y también puede ampliarse para
proporcionar capacidades adicionales más allá de las API especificadas por Parlay.
El sitio
£plataformas de prestación de servicios y multimedia £diseño de 229
servicios

Plano de usuario Capa de acceso Capa de red Capa de control Capa de servicio

SGSN/GGSN CSCF Aplica

Radio
ción
Red
Aplica

Servidor Parlay X
Otros... ción
Banda ancha Ubicación
Aplica
ción
Control de Servicios
WLAN llamadas

Mensajería Marco Aplica

ción

FIGURA 12.8
Prestación de servicios con pasarelas Parlay y Parlay-X.

El diagrama de la Figura 12.8 ilustra la posición de estos dos componentes en un

entorno típico de prestación de servicios.
Actualmente hay 15 servicios basados en la telefonía en el pliego de condiciones
[20] y un servicio marco adicional. Algunos de los servicios clave de Parlay son:

• control de llamadas: iniciación, terminación y conferencia de llamadas;

• interacción con el usuario: interacción con los usuarios finales, como el
envío de mensajes (SMS, USSD) o la recopilación de información de los
usuarios;
• movilidad: descubrimiento de la ubicación de un terminal y envío de
notificaciones cuando cambia de ubicación;
• capacidades del terminal: descubrimiento de las características del terminal;
• mensajería: interacción con sistemas de mensajería como la voz, la facsímil y el
correo electrónico;
• gestión de la conectividad: calidad de servicio y configuración de redes virtuales
privadas; y
• presencia y disponibilidad: determinación del estado en línea o fuera de línea
del usuario final.

Las especificaciones de Parlay establecen que el marco de trabajo de acceso

abierto a servicios (OSA) "define una arquitectura que permite a los desarrolladores
de aplicaciones de servicios hacer uso de la funcionalidad de la red a través de una
interfaz estandarizada abierta" [20]. La interfaz del marco define las funciones de
soporte para las aplicaciones cliente, el operador empresarial (empresa que
desarrolla y/o gestiona las aplicaciones cliente) y las funciones de soporte para los
servicios de telecomunicaciones Parlay. Esto incluye capacidades como
autenticación y autorización, gestión de contratos de servicio y registro de servicios
de red.
280 Manual del subsistema multimedia fP (fM£)

Aunque la pasarela Parlay accede a muchos recursos relacionados con la red que,
a su vez, se ponen a disposición de aplicaciones externas a través de la pasarela
Parlay X, deben desarrollarse varias funciones adicionales si se quiere proporcionar
soporte a una gama más amplia de servicios multimedia [19]. Utilizando los
elementos primitivos especificados en Parlay X (definiciones de datos, propiedades
de servicio e interfaces), se pueden añadir funciones adicionales para complementar
el conjunto de servicios Web disponibles. Esto puede incluir funciones como
interfaces de pago adicionales, API de prueba de aplicaciones y funciones de
atención al cliente. Este es un enfoque que algunos operadores han adoptado en un
intento de unificar el acceso y la integración con aplicaciones externas. En términos
de capacidad de prestación de servicios, se puede considerar que las funciones
combinadas de Parlay y la pasarela Parlay X abordan un subconjunto de los
requisitos para la prestación de servicios multimedia.
Aunque Parlay es completo por naturaleza, aspectos como la gestión de las
relaciones de servicio (por ejemplo, la gestión de comisiones), los portales basados
en Web para la interacción y la gestión combinada de registros para usuario y
dispositivo suelen requerir un mayor desarrollo para soportar un potencial de
servicio multimedia más amplio. Estas características suelen abordarse en un SDP
basado en TI. Además, existe el requisito de integrar SIP, aunque se han propuesto
extensiones basadas en SOA para solucionarlo [3]. Otro problema identificado por
los operadores es el rendimiento de las transacciones encapsuladas en el protocolo
de acceso a objetos simples (SOAP). Para contrarrestar los posibles problemas de
rendimiento, algunos de los servicios web pueden desarrollarse como servicios web
estáticos, servicios XML definidos por WSDL sobre HTTP, sin búsqueda UDDI ni
sobrecarga de paquetes SOAP. En este enfoque, se puede desplegar una pasarela de
servicios Web independiente para complementar la pasarela de servicios Web Parlay
X existente. La importancia de Parlay es evidente en la prestación de servicios y
puede aplicarse mejor como una extensión de una solución SDP existente basada en
IMS o IT para aumentar el potencial de prestación de servicios del operador.

Software como servicio (SaaS)

El paradigma del software como servicio (SaaS) es similar al modelo de proveedor
de servicios de aplicaciones (ASP). En un modelo ASP, las aplicaciones y la
plataforma de soporte son gestionadas y alojadas por una organización externa que
comercializa esta capacidad a los clientes. En este escenario, generalmente se ofrece
como servicio gestionado un conjunto de servicios asociados a un producto, como el
correo electrónico. Por lo tanto, el servicio se alquila o se accede a él mediante pago
por servicio. Los clientes sólo pagan por el uso cuando lo necesitan, lo que también
se conoce como una visión centrada en la demanda [21]. La aplicabilidad del SaaS en las
telecomunicaciones también se considera una tendencia reciente del sector, y estas
implantaciones se han asemejado al estilo de despliegue de la plataforma de
prestación de servicios.
El software como servicio en la prestación de servicios multimedia amplía el
modelo ASP, en el que la plataforma suele ser desarrollada y propiedad del
operador. El operador de telecomunicaciones asume la responsabilidad de vender
£plataformas de prestación de servicios y multimedia £diseño de 281
servicios

Plano de usuario Facilitadores de Plataforma Capa BSS/OSS

servicios SaaS
Radio
Aplica

Presentación y renderización
Red
ción
Presencia/Loca Facturació

Función de apoyo común

lidad Aplica n
Banda ancha ción
SGSN/GGSN CRM
Aplica
ción
Servidor HTTP : Liquidación
WLAN

Capa de acceso MMS/SMS Aplica OA & M

ción

FIGURA 12.9
Modelo de entrega de software servicio (SaaS).

a los clientes. Ejemplos de estas funciones son los servicios de correo electrónico,
virus y alojamiento web. Como plataforma de prestación de servicios, las
características y ventajas son las mismas: costes operativos, de implantación y de
gestión amortizados, rapidez de comercialización de nuevos servicios de software y
mayor presencia en el mercado.
A pesar de las características compartidas, existen varias diferencias entre un SDP
basado en SaaS y otros enfoques de SDP. Por ejemplo, el SDP tradicional se centra
en la prestación de servicios multimedia a consumidores minoristas, mientras que el
cliente del SDP SaaS suele ser una empresa que, a su vez, puede prestar el servicio a
sus empleados o clientes. Esto también puede considerarse un estilo de
funcionamiento MVNO. Un SDP basado en TI admite desarrolladores externos de
terceros, mientras que el SDP SaaS se ha centrado en aplicaciones alojadas
internamente. Además del alojamiento de la plataforma, la principal diferencia entre
el SaaS y el SDP tradicional es que los servicios ofrecidos suelen estar disponibles
en productos comerciales listos para usar, a diferencia de los servicios multimedia a
medida disponibles en un SDP. El alojamiento de aplicaciones multimedia
diseñadas específicamente para integrarse con un SDP a través de una pasarela de
servicios Web es un problema diferente de la integración de productos comerciales
con interfaces predefinidas. El dia- grama de la Figura 12.9 ilustra un ejemplo
industrial de despliegue de SaaS que encarna las características aquí comentadas.
Aunque las plataformas SaaS son similares a sus homólogas SDP tradicionales,
carecen de varias características clave identificadas en los despliegues SDP basados
en IMS e IT. En la práctica, los requisitos de SaaS contribuyen aún más a necesidad
de una plataforma combinada de prestación de servicios, lo que añade más
complejidad al desarrollo de estas plataformas. Por ello, la comprensión de las
características comunes y un enfoque más claro de la normalización de la
integración de estos aspectos de la prestación de servicios ayudarán a los operadores
a gestionar la cartera de servicios multimedia. Esto incluirá invariablemente
paquetes comerciales listos para usar y servicios a medida mejorados por
desarrolladores externos.
282 Manual del subsistema multimedia fP (fM£)

Servicios a clientes, proveedores y socios

Recursos gestionados por la FDS

SDF
Gestión Apoyo a la
explotación del Habilitadores de
servicios y
ciclo de vida del
BSS Y OSS aplicaciones
servicio

Red y recursos informáticos

Integración
Infraestructura
Servicios al usuario
final
FIGURA 12.10
Modelo de referencia SDF del TM Forum.

Marco de prestación de servicios (SDF)

Existen diversas variantes para implantar una plataforma de prestación de servicios,
y cada enfoque aborda un ámbito específico del entorno de prestación de servicios.
Una iniciativa reciente es el desarrollo de marco estándar destinado a aprovechar las
cualidades combinadas de IMS, Parlay y la tradicional SDP basada en TI. El Tele
Management Forum (TMF) ha establecido recientemente un grupo de proyecto de
trabajo para desarrollar dicho estándar; se denomina marco de prestación de servicios
(SDF) [7,22]. Se trata de una nueva iniciativa, y las normas aplicables del TMF están
actualmente en fase de desarrollo. Un principio rector es reutilizar los artefactos
existentes del TM Forum, junto con las aportaciones de equipos internos y externos,
para desarrollar especificaciones [7].
El ámbito del SDF incluye la gestión de la creación de servicios de extremo a
extremo, la entrega multimedia, el pago de servicios convergentes y la prestación de
apoyo a la cadena de valor compleja para los proveedores de servicios. Además de
reutilizar las arquitecturas de referencia existentes en la prestación de servicios, este
ámbito incluye los puntos de integración con los sistemas de apoyo operativo y los
sistemas de apoyo empresarial, y aplica estándares de integración como el New
Generation Oper- ations Software and Systems (NGOSS) y otros marcos B2B de la
industria. Un ejemplo industrial de marco preliminar que intenta combinar estos
aspectos de la prestación de servicios se describe en Pavlovski [6]. Sin embargo,
sólo se describe un modelo de arquitectura de alto nivel, por lo que aún queda
mucho por hacer para definir un marco consolidado.
El diagrama de la Figura 12.10 ilustra los dominios definidos por el modelo de
referencia TM Forum SDF [23]. Estos dominios pretenden representar el marco
empresarial y operativo que permite la prestación y gestión de servicios:

• Habilitadores de servicios y aplicaciones SDF: Esta tecnología se utiliza para

el despliegue y funcionamiento de un servicio y funciones de aplicación
£plataformas de prestación de servicios y multimedia £diseño de 283
servicios

que prestan todos los servicios. Algunos ejemplos son la presencia, la

localización, las tarifas (cargos), la personalización, la política y los
sistemas BSS/OSS.
• Soporte a las operaciones del ciclo de vida de los servicios SDF: Está compuesto
por el entorno de creación de servicios y las herramientas que dan soporte a
la creación, ensamblaje, despliegue, pruebas y retirada de servicios.
• Gestión del SDF: Comprende el aspecto de apoyo a las operaciones y el
mantenimiento de la prestación de servicios. Es necesario que las funciones
de gestión respondan a las necesidades de todas las partes interesadas en el
SDP.
• Infraestructura de integración. Este dominio engloba el conjunto de
servicios comunes utilizados por los tres dominios anteriores.

El SDF es una norma emergente y su alcance es ambicioso. Sin embargo, la

necesidad de un marco combinado de prestación de servicios es evidente, y las
normas que pueda aplicar el sector respaldarán la capacidad de los operadores para
desplegar y gestionar los servicios multimedia actuales y emergentes.

Plataforma de prestación de servicios de referencia Architecture

En esta sección se esbozan un marco de referencia y una arquitectura para
desarrollar la plataforma de prestación de servicios. Aunque la arquitectura incluye
los puntos clave de diseño de cada uno de los marcos analizados en la sección
anterior, puede considerarse fundamentalmente una mezcla de las arquitecturas SDP
basadas en IMS e IT. El marco propuesto se basa en el trabajo esbozado en
Pavlovski [6], donde se presentó un proyecto combinado de IMS y SDP. La noción
de plataforma IMS híbrida también se ha aplicado para combinar HTTP, RTSP
(protocolo de transmisión en tiempo real) y aplicaciones IMS basadas en SIP [14].
La reciente iniciativa del TM Forum para desarrollar un SDF también se basa en la
observación de que tanto las soluciones IMS como SDP requieren una fusión como
arquitectura consolidada [24].
Además de describir los subsistemas de la solución, se utilizan diagramas
detallados de interacción del sistema (secuencia) para explicar cómo interactúan los
distintos componentes para prestar servicios a los usuarios móviles y fijos. Los
modelos físicos operativos que representan los nodos de hardware proporcionan
algunas orientaciones sobre los requisitos de la infraestructura y cómo se despliegan
los componentes en un entorno comercial.
Por sí solos, los argumentos comerciales para el despliegue de IMS, y de hecho de
Parlay, son difíciles de justificar. Los comentarios de los operadores de
telecomunicaciones que operan en todo el mundo ofrecen perspectivas adicionales
sobre los retos a los que se enfrenta el despliegue de IMS. Aunque se sugiere que es
difícil justificar una plataforma de prestación de servicios IMS, las principales
observaciones se exponen a continuación.

* Comentarios de los operadores móviles de tercera generación sobre el enfoque de despliegue del IMS.
284 Manual del subsistema multimedia fP (fM£)

Los operadores están desplegando estas plataformas de forma limitada como de

precaución comercial, en general como infraestructura para compartir vídeo (como
se ha sugerido anteriormente, listas para la próxima aplicación revolucionaria).
También está la cuestión de la preparación de los dispositivos, ya que muchos
operadores consideran que la compatibilidad JSR 281 (terminales con SIP) es un
hito clave en el despliegue de IMS. Algunos operadores sugieren que IMS se
justifica por soportar una gama más amplia de comunicaciones y servicios
multimedia. Sin embargo, no pueden esperar a una oferta SDP combinada y están
realizando despliegues IMS limitados en preparación, a la espera de los terminales y
las extensiones para aplicaciones multimedia.
Cuando el IMS se combina con las capacidades más amplias que ofrece un SDP
basado en TI, se puede desarrollar una plataforma SDP flexible y de amplio alcance.
Además, puede desarrollarse una arquitectura híbrida que ofrezca servicios de
telecomunicaciones y multimedia tanto desde aplicaciones internas como desde
aplicaciones externas de terceros. Por tanto, la plataforma pretende ser un punto de
convergencia en la oferta de servicios de telecomunicaciones y multimedia.
Además, el marco representa una fusión de las plataformas de ingeniería e informática
implicadas en la prestación de servicios. Por consiguiente, representa una
convergencia en los servicios de contenidos y entrega, además de la infraestructura
de ingeniería informática y de redes.
La motivación de una arquitectura combinada de prestación de servicios puede
resumirse como sigue:

• Los despliegues de IMS y Parlay se enfrentan por sí solos a obstáculos en la

justificación de los casos empresariales.
• Los actuales despliegues de SDP basados en TI tienen la necesidad de
integrarse con los nuevos estándares IMS para la conectividad de red y
actualmente carecen de claridad para lograrlo.
• Pueden eliminarse los procesos y tecnologías duplicados que intervienen en
el despliegue y las operaciones de prestación de servicios, con lo que
pueden reducirse aún más los costes y los plazos de comercialización de las
aplicaciones multimedia y los servicios de telecomunicaciones mejorados.

Marco de prestación de servicios multimedia y de

comunicaciones
Para especificar un marco combinado, los componentes individuales de IMS, SDP y
Parlay se evalúan de forma discreta para identificar la capa (o plano) rel- evante en
la que residen. La duplicación de componentes puede fusionarse con otros
componentes y las funciones pueden compartirse. Esto ofrece nuevas oportunidades
para desarrollar nuevas aplicaciones que aprovechen el conjunto combinado de
funciones. Además, como plataforma unificada, el operador está bien posicionado
para implantar y desplegar futuras tendencias en servicios multimedia, incluidos
contenidos de difusión, aplicaciones multimodales, contenidos multimedia
tridimensionales para entornos virtuales y servicios entre pares (véase la sección
"Tendencias en el diseño de servicios multimedia").
£plataformas de prestación de servicios y multimedia £diseño de 285
servicios

Tienda de Aplicaciones SIP

contenidos

Catálogo de Gestión de Aplicaciones IN

Pasarela WAP Autenticación
Autorización productos descargas

Proxy HTTP Aplicaciones J2EE

Servidor de
Autorización Portal SRM de
pasarela SIP
maestra terceros
Pasarela MMS Contenido de
Gestión de
PIM: Internet
identidades y Gestión de
perfiles de Información
Pasarela SMS derechos personal Mgmt
usuario Publicidad
digitales
Gestión de
Pasarela Parlay dispositivos Portal de Uso y
autoservicio clasificación Capa de servicio
del cliente
Habla/IVR Control de
Portal del Instrumento de Pasarela de pagos
pasarela de
administrad pago
medios (MGC)
Servidor de or
ubicación Pasarela de Facturación
Control de la Servicios IMS anticipada
SGSN/GGSN servicios web
función de
CSCF
recursos
(Servidor SIP) Suscripción e Pasarela Facturación
MRFP multimedia inscripción OSA/Parlay-X posterior al pago
Servidor de
Pasarela abonado Registro de Almacenamiento
multimedia doméstico solicitudes Servicios de
Función de Función de integración
CRM
decisión colector de Informes
política carga
Funciones de transporte de la capa de Liquidación
Funciones
dispositivos de usuario básicas
Capa OSS/BSS
Plataforma de prestación de

FIGURA 12.11
Marco para el diseño de plataformas de prestación de servicios y multimedia. (Copyright 2007 IEEE; figura
reimpresa con permiso de la fuente original, con revisiones menores. Pavlovski, C. J. 2007. IEEE
Communications Magazine 45(3):114-121.)

El diagrama de la Figura 12.11 ilustra la arquitectura general de una plataforma

combinada que aprovecha las capacidades ofrecidas por IMS, SDP basado en TI,
Parlay y SOA. La arquitectura está alineada con los objetivos de la iniciativa TM
Forum SDF al articular un entorno unificado de prestación de servicios. Este
diagrama es una vista funcional de los subsistemas y componentes; los detalles de
cómo interactúan estos componentes del sistema se describen en la sección
"Interacción entre subsistemas".
Los componentes funcionales se distribuyen esencialmente entre las capas que
corresponden a los planos y capas de las plataformas basadas en IMS e IT,
respectivamente. Las capas de usuario, transporte, control de acceso y servicio
corresponden a los planos IMS de los mismos nombres. Las capas adicionales de
función central y servicios de integración se corresponden con las capas que suelen
encontrarse en los despliegues basados en TI; la capa OSS y BSS se corresponde
con la capa de gestión SDF.
La capa de dispositivo de usuario denota los dispositivos y equipos de las
instalaciones del cliente utilizados para acceder a los servicios multimedia a través
de las redes de acceso fijas y de radio. Las redes de acceso están implícitas en el
diagrama, y la conectividad se obtiene a través de los nodos de elementos de red y
las pasarelas que residen en la capa de función de transporte. Gracias a la
abstracción de varias capas del marco, los componentes de la solución pueden
cambiar sin alterar toda la solución. Este es un principio arquitectónico fundamental
del enfoque por capas. Por ejemplo, a medida que surgen nuevos tipos de redes, sólo
las pasarelas y los componentes de soporte pueden ser modificados.
286 Manual del subsistema multimedia fP (fM£)

dispositivos se ven afectados. De ahí que el resto de componentes y capas

permanezcan prácticamente inalterados.
El transporte y las capas y componentes restantes se describen ahora en las
subsecciones siguientes.

Función de transporte Capa

Los componentes alojados en la capa de transporte proporcionan la conectividad con
las redes de acceso. Esto incluye las pasarelas que traducen el tráfico entre IP y otras
redes. La capa incluye los nodos de elementos de red tanto de señalización como de
tráfico de datos. En el caso del tráfico relacionado con IP, a menudo la señalización
y el tráfico son una función del mismo nodo. Sin embargo, las redes de
telecomunicaciones tradicionales se consideran lógicamente como dos redes
separadas para la señalización y el tráfico; por lo tanto, nodos separados pueden ser
responsables de estas funciones. Nótese también que el término tráfico de datos
denota colectivamente los datos, la voz y otros tráficos IP que se originan en una
aplicación multimedia dentro de la capa de servicio.
La pasarela del protocolo de aplicaciones inalámbricas (WAP) es un componente
tradicional que se utiliza para comunicar contenidos en lenguaje de marcado
inalámbrico (WML) o HTML a dispositivos compatibles con el protocolo WAP.
Los dispositivos más nuevos centran su compatibilidad en el contenido HTML y sus
variaciones, como el HTML extensible (xHTML), aunque a menudo es necesario
seguir ofreciendo compatibilidad con dispositivos WAP. La pasarela WAP se
comunica a través de la GGSN, que es el punto de acceso a las redes de paquetes de
datos de las redes móviles e IP. El SGSN está dedicado a una subred específica de la
red de radio, por lo que un único GGSN da servicio a varios SGSN. La pasarela
HTTP interactúa con el GGSN del mismo modo que la pasarela WAP es una
interfaz para el acceso de usuarios móviles. Sirve de pasarela proxy hacia el servidor
maestro de autenticación al que se conectan los dispositivos.
En la capa de transporte se sitúan varias pasarelas de mensajería. Estas
incluyen el SMS, el MMS y el EMS (servicio multimedia mejorado). Estas pasarelas
suelen transformar las solicitudes de mensajería orientadas a servicios web (HTTP)
en los protocolos (es decir, SMPP, UCP/EMI) de los centros de mensajería
correspondientes, el MMSc y el SMS-C, para su entrega a dispositivos móviles y
fijos.
El servidor de voz y las pasarelas de medios transforman el tráfico de voz y audio
respectivo de la red IP a las redes de conmutación de circuitos, radio o fijas. Aunque
la pasarela de medios se encarga de comunicar el tráfico de voz entre los usuarios de
telefonía, el servidor de voz proporciona una interfaz de dia- logía dirigida (es decir, un
menú) para interactuar con otras aplicaciones. Esto se utiliza a menudo para la atención al
cliente; sin embargo, cada vez se utiliza más para acceder a aplicaciones
multimedia. La pasarela multimedia también puede desplegarse con una capacidad
de voz sobre IP (VoIP). El MRFP se encarga de reproducir anuncios y tonos de
audio (a través de la interfaz H.248) a través de la pasarela multimedia.
A través de la pasarela Parlay se accede al control de llamadas y a los servicios
básicos de telecomunicaciones. El servidor de localización proporciona información
posicional sobre la ubicación actual del dispositivo del abonado. Estos servicios son
servicios de comunicación rudimentarios que se ponen a disposición de los
desarrolladores de aplicaciones informáticas para que construyan aplicaciones
mejoradas.
£plataformas de prestación de servicios y multimedia £diseño de 282
servicios

servicios multimedia. Por lo tanto, suelen manifestarse como servicios en la pasarela

Parlay X o en la pasarela de servicios Web dentro de la capa de servicios de
integración.
Las decisiones sobre calidad de servicio las toma la función de decisión de políticas (PDF)
para servicios basados en SIP. Se trata de un elemento de control de red que
garantiza el nivel de servicio mediante la gestión del ancho de banda (por ejemplo,
controlando la sesión GGSN asignada para una conexión SIP) para los servicios
multimedia basados en SIP que se suministran. Este componente también puede residir
normalmente en la CSCF de la capa de control de acceso.

Control de acceso Layer

La capa de control de acceso contiene los componentes que controlan los elementos
de la capa de transporte con fines de señalización o son los nodos de acceso para los
servicios relacionados con IP, incluidos SIP, HTTP y otros servicios basados en IP. Esta
capa se corresponde con el plano de control IMS.
El controlador de pasarela de medios (MGC), el MRFC y el CSCF son componentes de
señalización IMS. El MGC proporciona funciones de control de llamadas y
señalización a través de la pasarela de medios. Por lo tanto, también lleva a cabo la
conversión de protocolos entre la interfaz SIP y la ISUP (a través de una pasarela de
señalización adicional) soportada por la red de conmutación de circuitos. La CSCF
puede considerarse un nodo central en el IMS, que actúa como servidor SIP con el
que los dispositivos habilitados para SIP establecen una conexión. Este componente
se compone generalmente de varios subcomponentes que procesan la señalización
SIP y controlan el tráfico para autenticar a los usuarios, gestionando las conexiones
SIP locales y la interconexión con otros servidores SIP. El MRFC controla el MRFP
y se comporta como un proxy de cliente SIP para el CSCF. Otras fuentes de tráfico
que pretenden establecer una sesión SIP, como la pasarela de medios, requieren un
componente proxy que actúe como cliente SIP para establecer una conexión con la .
Además de controlar la pasarela de medios, el MRFC proporciona esta función de
proxy de cliente SIP (es decir, agente de usuario SIP).
Para otro tipo de tráfico no basado en SIP, el servidor maestro de autenticación
(MAS) es el nodo al que los dispositivos cliente (es decir, los navegadores) se
conectan y establecen una sesión. Esto es válido tanto para el acceso a contenidos
multimedia en redes fijas como móviles. En la práctica, se desplegarán varios
servidores para gestionar el rendimiento del tráfico. El control de acceso se realiza
en esta capa a través del motor de autenticación y autorización. Sin embargo, cuando
el tráfico procede de una red de confianza, como la red móvil, suele configurarse en
modo de confianza. Esto significa que una vez que el dispositivo móvil es
autenticado por la red móvil, el tráfico que llega a través de la pasarela WAP o la
pasarela proxy HTTP en la capa de control se considera una fuente de confianza.
Así, se establece automáticamente una sesión con el servidor de autenticación
maestro y no es necesaria la reautenticación. Por el contrario, el tráfico procedente
Internet abierto normalmente requeriría autenticación. Los componentes de gestión
de identidades y gestión de dispositivos soportan el proceso de autenticación y
autorización para el acceso a contenidos y aplicaciones. Aunque las sesiones
basadas en IP desde el MAS son autenticadas por estos , la
288 Manual del subsistema multimedia fP (fM£)

El HSS es la base de datos central de identidades de usuario para los componentes

IMS y la CSCF accede a ella cuando se realiza la autenticación y la autorización.
La función de recaudación de cargos recibe registros de uso basados en SIP. En el
caso de la tarificación de pospago, estos registros de cargos pueden enviarse al
motor de uso y tarificación situado en la capa de integración. Alternativamente, el
cobro en tiempo real se realiza interrogando al sistema de prepago directamente a
través de la red inteligente (IN) o a través de una interfaz de servicio web anunciada
que abstrae el sistema de prepago.

Función principal Capa

Las funciones básicas, o servicios comunes, incluyen las capacidades de la SDP que
permiten gestionar el ciclo de vida de los usuarios, las aplicaciones multimedia y los
desarrolladores externos. Los usuarios de la plataforma se registran en ella y se
suscriben a los servicios multimedia a través del portal de autoservicio del cliente.*
Este portal también ofrece funciones de gestión de perfiles a los usuarios para
gestionar aspectos de sus cuentas. Una vez registrados en la plataforma, los usuarios
pueden navegar por la variedad servicios multimedia que se ofrecen a través del
menú de servicios dentro del catálogo de productos que se muestra. Un usuario
puede suscribirse o inscribirse en un servicio concreto y aceptar una de las diversas
opciones de pago asociadas, que generalmente incluyen el prepago (en tiempo real)
o el pospago (recurrente). Estas funciones son soportadas por el motor de
suscripción e inscripción.
En realidad, las aplicaciones multimedia residen en la capa de servicios. Sin
embargo, cada servicio se registra en el registro de la aplicación y es accesible desde
el catálogo de productos. Este contendrá detalles sobre las opciones de compra y
pago, periodos de descuento y más detalles sobre el propietario de la aplicación (es
decir, el desarrollador externo) y los acuerdos comerciales pertinentes. La gestión de
derechos digitales también puede utilizarse para proteger servicios en los que la
distribución de contenidos debe gestionarse de más estricta. Los servicios IMS
comunes, como la mensajería instantánea, la presencia y la gestión de listas de
grupo, forman parte de la capacidad básica disponible para crear aplicaciones
multimedia.
El portal de gestión de relaciones de servicio (SRM) proporciona las interfaces de
soporte necesarias a desarrolladores externos que les permiten desplegar
aplicaciones y gestionar sus servicios. Más concretamente, incluye el entorno de
creación de servicios de apoyo que permite a los desarrolladores crear, probar y
desplegar nuevas aplicaciones. Además, se dispone de funciones de elaboración de
informes que permiten a terceros ver y analizar los patrones de uso de sus
aplicaciones multimedia. Dado que la plataforma de prestación de servicios se
convierte esencialmente en el escaparate para el desarrollador externo, se necesitan
servicios completos de creación y gestión de servicios para gestionar su negocio de
contenidos y servicios multimedia.
El portal de administración es la interfaz de usuario que el personal de atención al
cliente utiliza para gestionar los dos conjuntos de comunidades de usuarios de SDP:
los usuarios móviles y

* Tenga en cuenta que el término portal se utiliza aquí para denotar una interfaz de usuario Web que puede o no
ser
incluyen portlets.
£plataformas de prestación de servicios y multimedia £diseño de 289
servicios

desarrolladores de terceros. Por ejemplo, se utiliza para gestionar litigios financieros

con terceros, resolver problemas de despliegue de aplicaciones multimedia y
administrar cuentas de desarrolladores. A la inversa, existen funciones similares
para ayudar al usuario móvil durante el registro y la suscripción, para resolver
problemas de acceso multimedia y para resolver disputas sobre pagos.

Servicio de integración Layer

La capa de integración alberga los componentes que se integran con las aplicaciones
multimedia, los sistemas de apoyo empresarial y los sistemas de apoyo operativo.
Proporciona la interfaz externa de la plataforma de prestación de servicios a las
aplicaciones y soporta la distribución de contenidos multimedia a los usuarios
finales. Esto incluye almacenes de contenido que actúan como depósitos en caché de
contenido multimedia para un acceso eficiente, gestores de descarga que
redistribuyen el contenido de las aplicaciones a dispositivos como juegos y
aplicaciones cliente de dispositivo utilizadas para el acceso a la tienda, y servicios
de gestión de información personal que gestionan las notificaciones de eventos
relacionados con los servicios multimedia.
Aunque el uso y la tarificación se realizan en los sistemas de facturación prepago
y pospago existentes, en la práctica es necesario proporcionar una capacidad mínima
de tarificación dentro de la plataforma. De ello se encarga un motor de uso y
tarificación, que también convierte los registros de cargos a un formato adecuado
para los sistemas de facturación de back-end. Las pasarelas de instrumentos de pago
proporcionan conectividad en tiempo real con el sistema de prepago y las redes
financieras para las transacciones con tarjetas de pago (es decir, crédito, débito y
autorización).
Varios componentes proporcionan soporte para aplicaciones multime- dia
externas de terceros. Entre ellos se encuentran el WSG, el servidor Parlay X y el
servidor de pasarela SIP. La pasarela de servicios Web es la interfaz de servicios
Web basada en SOA para entidades externas. Alberga las API que abstraen muchos
de los servicios y capacidades proporcionados por la red central, los sistemas OSS y
BSS y el SDP. La pasarela Parlay X es también una pasarela de servicios Web con
servicios estandarizados para las API Parlay. Los desarrolladores de aplicaciones
utilizan las API anunciadas por las pasarelas de servicios Parlay X y Web para crear
servicios multimodal mejorados. Por ejemplo, una API que proporciona un servicio
de localización puede ser utilizada por un desarrollador externo para añadir contexto
de posición a un servicio de mapas (por ejemplo, mostrando la posición del usuario
móvil con respecto a un sitio de interés concreto). Aunque las aplicaciones SIP
alojadas internamente pueden integrarse directamente con la CSCF, un servidor de
pasarela SIP adicional (que proporciona servicios web) actúa como interfaz para
soportar aplicaciones SIP externas de terceros, actuando como proxy para
interconectarse con la CSCF. Este componente abstrae los protocolos de conexión
SIP de bajo nivel, permitiendo solicitudes sencillas de servicios web para acceder a
servicios IMS como mensajería instantánea, presencia y gestión de listas de amigos.
Además, se pueden admitir aplicaciones SIP interactivas más complejas (véase la
sección "Interacción de servicios SIP multimedia").
El modelo financiero convencional consiste en cobrar a los clientes por
uso del servicio. Sin embargo, el uso de las WSG por terceros también puede dar
lugar a cargos. Por lo tanto, muchos modelos de negocio para la tarificación y el uso
pueden ser
290 Manual del subsistema multimedia fP (fM£)

aplicados. Por ejemplo, se puede incurrir en cargos a terceros por el uso de las
instalaciones de SDP para pruebas o implicar cargos por el uso de servicios web
durante prestación de servicios multimedia a los clientes.
La integración con los sistemas BSS y OSS existentes no es trivial y justifica un
tratamiento específico del diseño. Sin embargo, en el contexto de la prestación de
servicios, existen varias normas aplicables a la integración. Los enfoques de
integración que pueden adoptarse incluyen middleware orientado a mensajes,
arquitecturas de bus y diseño de servicios Web. Asumiendo una tecnología basada
en servicios web, un enfoque es adoptar los principios de NGOSS, proporcionando
acceso uni- forme a los sistemas OSS y BSS. Esto también puede implicar un
paradigma de servicio web. Aunque se muestra como un único componente, en la
práctica la WSG puede estar formada por varios subsistemas. Estos pueden incluir
nodos para soportar las interfaces con aplicaciones externas de terceros e instancias
alternativas para aplicaciones multimedia internas y otros nodos para soportar la
integración con los sistemas OSS y BSS IT existentes.

Capa de servicio: Servicio multimedia Diseño

Los servicios multimedia residen en la capa de servicios; son las aplicaciones
desplegadas. Los servicios pueden ser desarrollados y alojados internamente por el
operador o desarrollados por terceros y alojados externamente. La gama de
aplicaciones multimedia puede incluir noticias, contenidos de Internet, mensajería,
juegos, servicios financieros, aplicaciones basadas en la localización y otras
aplicaciones mejoradas de telecomunicaciones. Algunas aplicaciones combinarán
aspectos de los servicios de red con otras capacidades, como la banca, las compras o
los juegos. En concreto, un análisis de los actuales despliegues de SDP sugiere que
algunos de los que más ingresos aportan son los juegos, la música y los servicios
basados en la localización [6].
La forma en que las soluciones SDP actuales integran los servicios multimedia
tiende a variar considerablemente. Algunos operadores optan por alojar las
aplicaciones internamente en centros de datos informáticos, mientras que otros
deciden abrir los servicios SDP a desarrolladores externos. El enfoque más lucrativo
parece ser el de los servicios abiertos, en el que el número de aplicaciones de
terceros puede aumentar considerablemente. Los estudios muestran que un
despliegue de SDP con éxito dará soporte a unas 2.000 aplicaciones de servicios
multimedia y a varios cientos de desarrolladores de terceros [6]. El volumen de
solicitudes de servicios Web generadas por este número de aplicaciones multimedia
es de aproximadamente medio millón al año; en la Figura 12.12 se observa un ritmo
creciente a lo largo de un periodo de 3 años.
Teniendo en cuenta que muchas de estas solicitudes incluyen contenidos, para
soportar el tráfico generado por este volumen de solicitudes de pasarela de servicios
web, el diseño de la aplicación multimedia es crucial. Además, la aplicación se
centra en la lógica empresarial de los servicios previstos, como se indica en la
sección "Requisitos del diseño de servicios multimedia", al tiempo que aprovecha
las capacidades comunes del SDP invocando las API anunciadas por las WSG. Una
idea tradicional sobre el uso de los servicios web es que el usuario final o el
dispositivo móvil es el principal consumidor de servicios web. Aunque el
£plataformas de prestación de servicios y multimedia £diseño de 291
servicios

Solicitudes del
WSG

500,000

400,000

300,000

200,000

100,000

0
Año 1 Año 2 Año 3
Solicitudes del
WSG 190,000 245,600 450,000

FIGURA 12.12
Peticiones de servicios web de aplicaciones de terceros al día.

WSG puede utilizarse de este , en la práctica el principal objetivo de las WSG es

anunciar los servicios comunes del SDP para aplicaciones multimedia. Se trata de un
principio de diseño clave para los servicios multimedia. Como la aplicación
multimedia invoca servicios, debe aplicarse un mecanismo de autenticación. Por
ejemplo, puede emplearse el lenguaje de marcado de acceso seguro (SAML). En la
siguiente sección sobre la interacción entre subsistemas se muestra una ilustración
más completa de esta interacción.

OSS y BSS Capa

Los sistemas OSS y BSS requieren integración para apoyar las funciones de
prestación de servicios y también son necesarios en el contexto más amplio de las
operaciones empresariales de telecomunicaciones. Esta capa se corresponde con las
funciones de la capa de gestión SDF de TM Forum. Los sistemas BSS suelen incluir
la gestión de las relaciones con los clientes, los sistemas de liquidación para
distribuir los pagos a terceros proveedores de servicios, los sistemas de facturación,
las pasarelas de pago a redes financieras y los sistemas de almacenamiento de datos.
Aunque no se muestran explícitamente en la Figura 12.11, los sistemas OSS
incluyen los sistemas de operaciones, administración y gestión (OA&M), los
sistemas de provisión de servicios y los sistemas de resolución de problemas. Estos
parecen ser los sistemas más comunes que se integran, aunque en la práctica puede
ser necesario interconectar una gama más amplia de sistemas.

Subsistema Interacción
En la sección anterior se esbozaron los componentes funcionales que conforman un
SDP combinado basado en IMS e IT. Esto también incorpora Parlay y encarna los
principios del TM Forum SDF. Con el fin de aclarar cómo estos com-
292 Manual del subsistema multimedia fP (fM£)

ponentes operan en la prestación de un servicio multimedia, se esbozan las

interacciones de los componentes (o subsistemas). Se ilustran dos escenarios de
interacción. El primero es un servicio de descarga multimedia. El segundo se refiere
a la mensajería instantánea y la presencia mediante capacidades IMS. En ambos
casos, se supone que una aplicación alojada externamente coexiste con la plataforma
de prestación de servicios. El despliegue de aplicaciones alojadas internamente es el
caso más sencillo de tratar; de ahí que los dos ejemplos ilustren cómo se simplifican
las complejas interacciones externas utilizando la arquitectura de referencia SDP.
Estas interacciones también sirven para demostrar cómo pueden diseñarse los
servicios multimedia para hacer uso de la plataforma de forma que se apoye la
máxima reutilización de la funcionalidad común dentro de la SDP.

Servicio multimedia HTTP Interacción

Para ilustrar cómo la interacción de una aplicación multimedia y una plataforma de
prestación de servicios suministra contenidos, el siguiente escenario representa a un
cliente de telefonía móvil de prepago que solicita contenidos a un proveedor de
servicios externo. Aunque lógicamente accede a la SDP para seleccionar el servicio
deseado, el usuario no es consciente de la ubicación física de la aplicación. En este
escenario, el uso del cliente se carga a la cuenta de prepago en el punto de acceso al
servicio (véase la figura 12.13).
Cuando el cliente enciende inicialmente el teléfono móvil, el dispositivo es
autenticado por la red móvil. El cliente navega por el sitio del portal, utilizando una
conexión de datos, y es autenticado automáticamente por el GGSN y el servidor de
autenticación radius asociado (no se muestra en el diagrama). La solicitud SDP de acceso
al portal se reenvía entonces a la pasarela WAP y se convierte en una solicitud HTTP
con el MSISDN insertado para identificar al cliente. La "solicitud HTTP" se reenvía
al servidor de autenticación maestro, que puede configurarse para operar con la
pasarela WAP (e implícitamente con el GGSN) en modo de confianza. Esto
significa que no se solicita al usuario un nombre de usuario y una contraseña
después de que el dispositivo haya sido autenticado inicialmente por la red móvil. El
servidor de autenticación maestro comprueba si el usuario tiene una sesión abierta y
crea una si es necesario. El MSISDN se utiliza para buscar los datos del cliente
almacenados por el módulo de gestión de identidades y perfiles de usuario y rellena
la entrada de la sesión de usuario. El servidor de autenticación maestro mantiene una
cookie en nombre del terminal y reenvía la solicitud al portal SDP. Una vez
establecida la sesión, el usuario puede interactuar con el SDP, realizando funciones
de autocuidado y otras actividades según sea necesario. En un momento dado, el
usuario decide seleccionar un servicio concreto; para ello, navega por el menú de
servicios que ofrecen las aplicaciones multimedia. Se devuelve al cliente una
respuesta de menú de catálogo, una lista de servicios multimedia.
Cuando el cliente móvil se decide por un servicio concreto y lo selecciona en el
menú, se envía una solicitud de selección de servicio al servidor maestro de
autenticación. Este servidor confirma si el usuario está autorizado (registrado
previamente) a acceder al servicio y, a continuación, resuelve la URL específica de
£plataformas de prestación de servicios y multimedia £diseño de 293
servicios
WAP Master SDP Aplicación Pasarela de Instrumen Sistema de
Dispositiv MMSc de terceros
Pasarela Auth. Server Portal servicios to de pago facturación
o
web de prepago

Acceso al portal Inserte

SDP
MSISDN

HTTP El usuario navega por el

Solicitar portal, ve
(Compr
y selecciona el servicio
obar
) multimedia.
MSISDN

Menú Catálogo

Asignar la selección de
Seleccionar servicios a
servicio URL de aplicación
externa y redirigir al

El usuario navega
Redirección de contenidos
URL multimedia de
terceros
Servicio de
acceso

Descripción del servicio multimedia y

Selección de servicios y precio
precios Comprobar cuenta de
prepago
Comprar contenido saldo por fondos
Comprobación suficientes.
de saldo

Fondos
OK
Confirmación de
compra Envia
Cumplimiento del servicio: Envío r Adeudo en cuenta de
Contenido MMS prepago
y enviar una
Multimedia
Usuario de notificación de
Contenido
pago

Pago
Aceptado

FIGURA 12.13
Interacción de servicios multimedia HTTP.

la aplicación externa de terceros. Esto se consigue con una búsqueda en el registro

de aplicaciones y, a continuación, el servidor devuelve al dispositivo móvil una
solicitud de redirección de URL basada en SAML. La cadena de redirección de
URL incluye una sustitución de la identidad del cliente por una identidad temporal o
alias; esto facilita el anonimato del cliente.
El cliente es redirigido sin problemas a la aplicación del proveedor de servicios
externo con la solicitud del servicio de acceso y no es consciente de la redirección
automática. Es decir, desde la perspectiva del cliente, tras seleccionar un servicio del
menú, la siguiente interacción es con el contenido y los servicios disponibles en el
sitio (aplicación) de terceros redirigido. La aplicación de terceros puede decidir
opcionalmente autenticar/autorizar al cliente invocando un servicio web habilitado
para SAML contra la WSG. El cliente navega por
294 Manual del subsistema multimedia fP (fM£)

catálogo de contenidos y servicios y selecciona el servicio deseado. La aplicación

multimedia de terceros devuelve cliente una descripción del artículo seleccionado,
junto con el precio asociado. Además, la aplicación de terceros puede recuperar el
precio de la plataforma SDP a través de una llamada al servicio web. La respuesta de
selección de servicio y precio se presenta al cliente. Cuando el cliente decide comprar el
servicio (en este ejemplo, una imagen deportiva suministrada a través de MMS), se
envía una solicitud de contenido de compra a la aplicación externa de terceros. Para
realizar este servicio, la aplicación de terceros prepara una solicitud de servicio web
de comprobación de saldo utilizando el identificador temporal del cliente, el
identificador de contenido y el precio de servicio indicado. El servicio web
correspondiente se invoca contra la pasarela de servicios web y la solicitud se
reenvía al sistema de facturación de prepago a través del instrumento de pago para
comprobar si hay fondos suficientes en la cuenta. El sistema de prepago devuelve el
resultado indicando si quedan fondos suficientes para el importe solicitado. En este
ejemplo, se devuelve una respuesta de fondos ok. La aprobación se devuelve a la
aplicación multimedia externa, que, a su vez, avisa al
cliente de la confirmación de compra.
La aplicación externa de terceros completa el servicio invocando un servicio web
para enviar contenido a través del MMSc; el contenido real que debe entregarse se
incluye en la solicitud del servicio web. La pasarela de servicios web puede generar
opcionalmente un registro de cargos para su uso por parte de la aplicación de
terceros y, a continuación, envía las solicitudes de envío al MMSc para su entrega
en red. Esto puede ocurrir de forma asíncrona. El MMSc también genera
normalmente un registro de entrega al finalizar.
Por último, la aplicación externa capta los fondos con una solicitud de cobro del
usuario. Se devuelve un acuse de recibo del pago aceptado a la aplicación externa a
través de la pasarela de servicios web.
El enfoque fundamental esbozado ilustra cómo interactúan la aplicación de
terceros, el SDP y el dispositivo durante la entrega de contenidos multimedia a un
cliente. Este modelo es aplicable a otros servicios multimedia, como juegos,
transmisión de vídeo y servicios basados en la localización. Además, el cliente es
redirigido de forma segura a la aplicación de terceros correspondiente para que
seleccione el servicio. La aplicación de terceros, a su vez, realiza cualquier solicitud
de servicio web relevante para utilizar las capacidades comunes del SDP, que
pueden incluir control de llamadas, servicios de localización, descargas y
facturación. Además, el SDP facilita la entrega de contenidos por parte de la
aplicación externa.

Servicio multimedia SIP Interacción

El segundo escenario ilustra la interacción de un servicio multimedia habilitado para
SIP. En este , se supone que los usuarios móviles se han registrado previamente en
la aplicación multimedia de terceros. En este caso, la aplicación ofrece un servicio
interactivo de juegos multijugador, y los jugadores pueden "batirse en duelo" con
otros jugadores registrados. Durante el proceso de registro, se descarga en el
dispositivo móvil un juego habilitado para SIP. El mecanismo de pago se basa en la
facturación de pospago, con un cargo cada vez que el usuario juega.
£plataformas de prestación de servicios y multimedia £diseño de 295
servicios
SGSN CSCF SDP Aplicación Pasarela Pasarela de IMS Instrument
Dispositiv SIP de
GGSN Servidor Portal proxy servicios Servicios o de pago
o terceros
SIP SIP web
Acceso al portal
SDP El usuario navega por el
Portal, consulta
y selecciona el servicio
Menú Catálogo multimedia.

Asignar la selección de
Seleccionar servicio servicios a Servicio de presencia
de juego URL de aplicación IMS
externa y redirigir a SIP para determinar si
Buddy tiene el
Redirección de URL teléfono encendido
pero no ha iniciado
sesión en el servidor
Redirigir al vestíbulo del
de juego.
juego
Encontrar
compañeros de

Finaliza
r Lista de
Lista jugadores
Lista de oponentes
disponibles

Establecer
Seleccionar oponente jugador
como ocupado.

Invocar juego con el

adversario

Invitación Establecer conexión

SIP con otro dispositivo
SIP.

SIP ACK Generar lote diario

expediente de Procesar y mediar
acusación. archivo por lotes,
reenviar al sistema
de facturación.
Intercambiar datos de Archivo
juego por lotes

Cierre del Intercambiar datos Acuse recibo

SIP de juego
entre dispositivos

FIGURA 12.14
Interacción del servicio multimedia SIP.

el juego interactivo. El diagrama de la Figura 12.14 ilustra los componentes

interactivos clave de la aplicación de terceros, los componentes del sistema SDP y el
dispositivo habilitado para SIP.
Las interacciones iniciales son similares al escenario HTTP descrito en la sección
anterior. El usuario enciende el teléfono móvil y es autenticado por la red móvil, y a
continuación se le concede el acceso al portal SDP. A efectos de este ejemplo, la
pasarela WAP se omite y está implícita al acceder al portal SDP. Se devuelve al
usuario un menú de catálogo que enumera los servicios multimedia disponibles. A
continuación, el usuario selecciona un servicio de juegos suministrado por una
aplicación externa de terceros habilitada para SIP. Una vez realizada la selección, se
envía la solicitud al portal SDP y se confirma la autorización del usuario. Se
resuelve la URL del servicio de juego externo y se devuelve una solicitud de
redirección al dispositivo móvil. El dispositivo carga automáticamente la redirección
de URL y accede al servicio de juego externo.
296 Manual del subsistema multimedia fP (fM£)

servidor. Esto, en efecto, es una petición de redirección al vestíbulo del juego de la

aplicación de terceros.
El usuario, con las credenciales adecuadas proporcionadas en la solicitud de
redirección, inicia sesión en el servicio de juego. Una vez iniciada la sesión en el , la
aplicación de terceros envía una solicitud de búsqueda de jugadores amigos al SDP
para descubrir el estado de otros jugadores que están en la lista de amigos (favoritos)
del jugador. Esta solicitud se reenvía al componente de servicios IMS a través de la
pasarela proxy SIP. El componente de servicios IMS interroga al servidor de
presencia y devuelve una lista de dispositivos que satisfacen los criterios de
búsqueda suministrados en la solicitud de búsqueda de amigos. Aunque se utiliza el
servicio de presencia IMS para ilustrar este ejemplo, también puede aplicarse
igualmente una solicitud de estado de terminal Parlay. Cuando la aplicación de
terceros recibe la respuesta, se devuelve a la solicitud inicial de juego una lista final
de oponentes disponibles para batirse en duelo.
El usuario selecciona un oponente de la lista devuelta y emite otra petición HTTP
-seleccionar oponentes- a la aplicación de juegos de terceros. La aplicación de
terceros cambia el estado de los jugadores como ocupado y obtiene la dirección SIP
del oponente elegido, lo que puede implicar más invocaciones contra la pasarela
proxy SDP SIP para resolver las direcciones. Finalmente, la aplicación de terceros
devuelve al usuario la respuesta invocar juego con oponente, que activará la aplicación de
juego habilitada para SIP en el dispositivo del usuario. Aunque se asume que el
cliente de juego en el dispositivo ha sido precargado durante algún proceso de
registro, esto puede ser alternativamente proporcionado en una página de respuesta
HTTP que contiene un applet que se carga automáticamente.
Los pasos finales necesarios para iniciar el juego entre los dos dispositivos
implican el establecimiento de una sesión SIP por parte de los clientes de juego
remotos en los dispositivos. El juego es en realidad una aplicación cliente habilitada
para SIP que inicia una sesión con el mensaje de invitación SIP enviado al CSCF. El
CSCF localiza (resuelve cualquier otra dirección) y reenvía la solicitud de invitación
SIP a la parte llamada. Si se acepta la sesión, se devuelve el mensaje SIP ACK a la
parte llamante. En este punto se establece una sesión SIP entre dos dispositivos -el
jugador y su pponente- y se intercambian datos de juego dentro de la sesión SIP.
Cuando los duelistas han terminado, cualquiera de las partes finaliza la sesión con el
mensaje SIP close.
En algún momento posterior, la aplicación de terceros preparará y enviará un
archivo por lotes diario de cargos a la plataforma SDP. Éste contendrá un registro de
cargos para cada evento de juego y aparecerá en la factura periódica del al cliente.
El escenario ilustra cómo una aplicación externa de terceros puede aprovechar las
capacidades de la plataforma SDP que incluyen IMS y otros servicios comunes. De
este , pueden desarrollarse otras aplicaciones externas que utilicen estas
características para otros servicios.

Modelo físico operativo

La Figura 12.11 ilustra los componentes de un SDP desde un punto de vista
funcional. En esta sección se ilustra una representación física de la arquitectura
(véase la Figura 12.15). En este apartado se ilustra una representación física de la
arquitectura (véase la figura 12.15).
£plataformas
Usuari
de prestación
Acceda a
de servicios y multimedia
Transporte Control de acceso
£diseño de
Funciones Integración
292
Servicio
o
servicios Red Funciones básicas Servicios Capa
Disposi IMS Pasarela proxy SIP
MMS/SMS Servicios
HSS
Móvil MRFC
Red Aplicacio
Parlay-X nes SIP
MRFP

A WSG
CSCF Pasarela J2EE
SGSN PDF Aplic
A MMS/SMS Servicio web Aplicacio
WiFi DRM Pasarela nes IN
GGSN
MGCF App.
Descargar
Registrad
Catálogo Director
MGW BGCF or
RTPC Medios de
comunicación
Control de
Parlay Admin Utiliza
AA/Dispos Portal Suscripción
Pasarela itivo ción
Otros WAP Gestión Tienda de
Redes GW clasificación de BSS/OSS
IVR SDP PIM Capa
Portal
Integración
Proxy HTTP Autobús
Internet Cliente Pago
Master Auth.
Servidor Portal
Portal SRM
Instrument

FIGURA 12.15
Modelo físico operativo de los componentes del SDP.

y complementa las interacciones secuenciales descritas en el apartado anterior.

Aunque se utilizan nodos individuales para representar el despliegue de
componentes, en la práctica varios de los componentes funcionales mostrados en la
Figura 12.11 pueden residir en un único nodo. A medida que aumentan los requisitos
de rendimiento operativo, puede resultar más eficiente implementar soluciones de
gama media o mainframe con servidores virtuales configurados que representen los
nodos independientes.
Se mantiene la coherencia en la distribución de los nodos dentro de las capas de la
arquitectura de referencia SDP. Los nodos de mayor tamaño se utilizan para
representar la necesidad de asignar capacidad de hardware adicional debido al
tráfico de mayor caudal o a los requisitos sensibles al rendimiento que suelen ir
asociados. Entre ellos se incluyen el servidor maestro de autenticación, el GGSN, el
portal SDP, la CSCF y la pasarela de servicios web. Se muestra un nodo adicional
para la integración entre el SDP y los sistemas OSS/BSS. Idealmente, este
componente no contendrá ninguna lógica de negocio compleja, sino que
proporcionará un medio transparente de integración con los sistemas OSS y BSS
existentes. En la práctica, el sistema se diseñará sin puntos únicos de fallo y con
diversidad física y redundancia incorporadas en el diseño. Esto implicará
normalmente el despliegue de despachadores de red, configuraciones en clúster e
instancias duplicadas (redundantes) de hardware y software.
En la capa de dispositivos de usuario, una serie de dispositivos interactúan con el SDP,
entre ellos
móvil, telefonía fija tradicional y dispositivos con acceso a Internet. Las redes de
acceso incluyen redes móviles de segunda y tercera generación, redes WiFi y redes
fijas como la RTPC y las variantes de banda ancha. Una vez más, un aspecto clave
de la arquitectura global es que, a medida que los nuevos
298 Manual del subsistema multimedia fP (fM£)

dispositivos y redes emergentes, el SDP permanece fundamentalmente inalterado.

Por ejemplo, para admitir redes adicionales, ya sean existentes o , se despliega la
interfaz de elemento de red adecuada en la capa de función de transporte. En el caso
de los dispositivos más nuevos, será necesario añadir detalles del dispositivo al nodo
de gestión de dispositivos, aunque la arquitectura permanece relativamente
inalterada para admitir estas ampliaciones.
Una ruta de rastreo típica de los nodos interconectados muestra que el tráfico de
Internet y móvil (HTTP y WAP) viaja a través del servidor de autenticación maestro
para acceder a uno de los portales SDP. Puede tratarse del portal de gestión de
relaciones de servicio, autoservicio, administración o SDP central. Una vez que el
usuario selecciona el servicio multimedia que desea (como se describe en la sección
anterior), se le redirige a la aplicación multimedia adecuada que reside en la capa de
servicio. A las aplicaciones convencionales basadas en HTTP se accede mediante el
navegador del dispositivo o la aplicación cliente Java desplegada localmente. El
tráfico SIP basado en IMS establecerá la conectividad con la CSCF tras la
interacción con la aplicación multimedia. Además, las aplicaciones externas de
terceros accederán a las pasarelas SDP (WSG, Parlay-X y proxy SIP) a través de
Internet. Cuando sea necesario, este acceso podrá realizarse a través de una red
controlada o segura.
La pasarela de servicios web es un nodo central para interconectar servicios de
terceros.
ofreciendo las capacidades del SDP como servicios web y también como medio de
integrar la funcionalidad internamente en el SDP. Por ejemplo, un desarrollador
externo puede conectarse al portal SRM para ver y gestionar su cartera de
aplicaciones multimedia, y el desarrollador puede decidir registrar una nueva
aplicación. En esta interacción intervendrá la pasarela de servicios web, con un
servicio web anunciado para cargar los datos de la nueva aplicación. El nuevo
registro se deposita en el registrador de aplicaciones. Normalmente, las nuevas
aplicaciones se desplegarán primero en un entorno de ensayo para que el
desarrollador externo pueda probar el producto. A continuación, el nuevo servicio
estará disponible en producción y los clientes podrán acceder a él a través de la
interfaz de menús. Siguiendo con el debate anterior, este y otros ejemplos de
aplicaciones seguirán una secuencia de interacciones similar a la descrita en la
sección anterior.

Tendencias en el diseño de servicios multimedia

Muchas facetas de la prestación de servicios siguen surgiendo y ocupando su lugar
entre las tecnologías disruptivas. Aunque la plataforma de prestación de servicios,
como tecnología habilitadora, es una tecnología disruptiva en sí misma, la demanda
comercial para soportar nuevas formas de contenidos y servicios supone un punto de
cambio adicional en los despliegues de SDP. Aunque las tecnologías y los
dispositivos de la red de acceso puedan transformarse, quizá sea la aparición de
nuevos tipos de servicios multimedia la que, en general, implique un mayor grado de
cambio con el fin de
£plataformas de prestación de servicios y multimedia £diseño de 299
servicios

acomodarlos dentro del entorno de prestación de servicios. En esta sección,

analizamos brevemente varias tendencias en el avance de los servicios multimedia y
revisamos el impacto del diseño en la prestación de servicios. Se trata de los
servicios de difusión, los servicios entre iguales, los contenidos tridimensionales y
las interacciones multimodales.

Multimedia Difusión
Los modelos de negocio existentes en los servicios multimedia giran en torno a la
difusión de contenidos a través de varios canales a uno o varios usuarios. Se trata en
gran medida de un paradigma de solicitud-respuesta o publicación-suscripción. En
estos el SDP actúa para suministrar contenidos a un cliente identificado. Para ciertos
tipos de contenido, este es un mecanismo caro e ineficiente para la entrega. Por
ejemplo, el vídeo a la carta es esencialmente un modelo unidifusión de entrega y
tiene restricciones en el número máximo de espectadores por célula de red debido a
las conexiones punto a punto establecidas. El modo de difusión implica la
publicación de contenidos a través de un canal compartido al que los clientes pueden
elegir acceder. Teóricamente, no existe límite en el número de usuarios que pueden
acceder al contenido. Los usuarios también acceden al contenido en el punto de
emisión actual y no pueden repetirlo ni seleccionar el punto de inicio deseado. Por
supuesto, la televisión y la radio son las formas más comunes de medios de
comunicación suministrados de esta manera, y la posible aplicación de la televisión
móvil ha sido objeto de atención recientemente [25].
Se han realizado varios ensayos y aplicaciones comerciales para móviles.
TV con una serie de normas de apoyo en evolución. La radiodifusión digital
multimedia DMB) se basa en la norma de radio de radiodifusión sonora digital
(DAB). El Instituto Europeo de Normas de Telecomunicación (ETSI) ha adoptado la
difusión de vídeo digital para dispositivos portátiles (DVB-H), que es el principal
competidor de la DMB, y el enlace multimedia exclusivo (Media- FLO) se basa en
la tecnología CDMA. Todas estas normas están diseñadas para funcionar en bandas
específicas del espectro UHF/VHF. Un enfoque alternativo se basa en la utilización
de las redes celulares existentes. El servicio de multidifusión de difusión multimedia
(MBMS), extensión de la red de tercera generación, es uno de estos enfoques y
también competirá para proporcionar contenidos de difusión dentro de las redes de
tercera generación existentes [26]. Esto puede tener la ventaja de simplificar el
soporte del espectro radioeléctrico de los dispositivos.
Aunque las aplicaciones históricas de la radiodifusión se refieren a la televisión, la
radio,
y el teletexto, este modo de entrega también puede aplicarse de forma novedosa a
los multimedios. Por ejemplo, puede haber nuevas aplicaciones para juegos
multiusuario que requieran el intercambio en tiempo real de datos de juego
comunes, como escenarios de vídeo entre un grupo de usuarios más amplio.
Evidentemente, el uso de una única transmisión amplia de contenidos de gran ancho
de banda proporcionará beneficios económicos en la transmisión de datos. Esto
también puede proporcionar una experiencia más consistente a los usuarios.
Desde el punto de vista de la prestación de servicios, el apoyo a la difusión
implicará la necesidad de capacidades SDP adicionales. La capacidad de crear,
actualizar y gestionar listas de distribución y transmisión de contenidos de
radiodifusión será fundamental.
300 Manual del subsistema multimedia fP (fM£)

necesarios. La gestión de grupos cerrados de usuarios puede aplicarse a una

aplicación multimedia concreta que suministre contenidos a través de un medio de
difusión o multidifusión. La evolución en la red de acceso para identificar un canal
común para la señalización de difusión implicará cambios en la capa de función de
transporte. Alternativamente, la introducción de la pasarela de acceso a la
radiodifusión para acceder al espectro radioeléctrico UHF/VHF está reservada a la
radiodifusión multimedia. Los dispositivos capaces de soportar varias interfaces
aéreas y aplicaciones podrán acceder al canal de radiodifusión y a los métodos de
facturación en tiempo real para utilizar el con- tent de radiodifusión. Está claro que
estos tipos de multimedia tendrán un cierto grado de impacto en varias capas dentro
de un SDP. Sin embargo, muchos de los cambios pueden ser localizados y
gestionados con estricto apego a las normas y marcos definidos para la prestación de
servicios.

Servicios P2P
Los servicios entre iguales ya se utilizan ampliamente en productos como VoIP y
protocolos de intercambio de archivos. En el contexto de la prestación de servicios,
una forma novedosa de aplicar los servicios entre iguales es que el cliente actúe
como proveedor de contenidos. Actualmente, la aplicación multimedia, ya sea
interna o externa, entrega contenidos a los usuarios finales. En otro escenario, la
plataforma SDP puede ofrecer un servicio de igual a igual que permita a los clientes
compartir contenidos con otros usuarios en tiempo real. Un ejemplo sugerido
consiste en que los miembros de una familia conecten un reproductor de vídeo
digital a una pantalla de vídeo o televisión para ver una grabación personal de algún
acontecimiento familiar [4]. Utilizando el servicio peer-to-peer ofrecido por un SDP,
deciden invitar a otros miembros de la familia a compartir la experiencia de
visionado, viendo la misma grabación digital en sus dispositivos móviles o fijos. Un
medio convencional para lograr una experiencia similar es que el usuario suba el
contenido a un servidor central, poniéndolo a disposición de los demás. Sin
embargo, esto no ofrece la experiencia de compartir en tiempo real que permite un
servicio entre iguales.
El proxy SIP y las pasarelas de servicios Web del SDP pueden aplicarse para sup-
La extensión requeriría que una aplicación cliente peer-to-peer fuera reconocida
como una aplicación externa de terceros. La extensión requeriría que una aplicación
cliente peer-to-peer fuera reconocida como una aplicación externa de terceros.
Además, la aplicación cliente se implementaría como un cliente SIP que establece
una conexión, a través de la CSCF, con otros pares para distribuir contenido a través
del SDP. Además del ejemplo de compartición directa, los servicios pueden
combinarse con otras características del SDP que creen aplicaciones más novedosas.
A partir de esta capacidad básica peer-to-peer, se pueden introducir una serie de
servicios adicionales no contemplados anteriormente.

Interacción multimodal
La interacción convencional del usuario con una aplicación informática suele
producirse a través de un único modo de interfaz de usuario. Puede ser de voz, datos
o vídeo. El usuario suele introducir datos a través de un comando de voz o de datos
y puede recibir información de varias formas. El usuario se limita básicamente a una
única forma de entrada.
£plataformas de prestación de servicios y multimedia £diseño de 301
servicios

o comunicación de salida con la aplicación. En un escenario multimodal, la

interacción con el usuario se amplía para admitir varios modos de interacción
simultáneamente. Un ejemplo sencillo es que el usuario utilice un dispositivo
señalador mientras visualiza un mapa. Por ejemplo, puede emitir el comando de voz
"Me gustaría ir aquí" y, al mismo tiempo, señalar una ubicación en el mapa que
aparece en su dispositivo móvil. Los dos conjuntos de datos de entrada -el comando
de voz junto con las coordenadas (x, y)- se suministran a la aplicación, que
interpreta las dos partes del comando y devuelve el resultado apropiado. El resultado
puede ser una combinación de mapa, texto y voz para describir cómo llegar al lugar
deseado.
El estándar de interacción multimodal del W3C [27] identifica tres tipos
principales de interacción multimodal: secuencial, simultánea y compuesta. En el
modelo secuencial, dos o más modalidades están disponibles para la entrada, pero
sólo una puede utilizarse en un momento dado. "Simultáneo" significa que se
aceptan entradas de dos o más modalidades a la vez, pero que se actúa sobre cada
entrada individualmente. El modelo compuesto significa que las entradas de varios
modos se integran en una única solicitud. Este es el ejemplo que se ha dado antes.
Incorporar una capacidad multimodal a un SDP permitirá a las aplicaciones de
terceros hacer uso de otras características de interacción con el usuario, como la
entrada táctil o la respuesta háptica para complementar las interacciones de audio y
vídeo. Hay otros ejemplos de cómo emplear la interacción multimodal que implican
el uso de pedidos y publicidad. Por ejemplo, imaginemos una aplicación de pedidos
de comida con interacción multimodal. Cuando el cliente realiza una llamada de voz
a una aplicación de terceros que acepta pedidos, el usuario puede recibir
simultáneamente un menú en forma de página HTTP que enumera las opciones
disponibles. A continuación, el usuario puede hacer la selección final con la voz o
con el menú. Además, ambos modos de interacción pueden utilizarse
simultáneamente: el usuario puede decir "quiero pedir dos de estos" mientras señala
el elemento deseado en el menú.
El apoyo a la interacción multimodal se consigue normalmente con el uso de un
aplicación cliente en el dispositivo capaz de multiplexar las interacciones de entrada
y salida. Otra posibilidad es utilizar tecnologías de navegación convencionales,
junto con el servicio complementario de llamada múltiple de tercera generación
[28], que permite establecer varias conexiones simultáneas con un dispositivo móvil.
Una norma propuesta para el marcado multimodal es XHTML + voice (X+V), que
ofrece soporte XML para etiquetas de voz y datos. El SDP también necesitaría
componentes adicionales, como un gestor de servicios de llamadas múltiples y un
gestor de integración y generación multimodal para gestionar las solicitudes
compuestas de entrada y salida, así como la gestión de sesiones de diálogo [29].

Contenido tridimensional
Las implantaciones actuales de SDP se centran en la entrega de contenidos visuales
bidimensionales. Aunque esto se complementa con otras formas de medios como
texto, vídeo y audio, el contenido de salida proporciona una imagen bidimensional.
302 Manual del subsistema multimedia fP (fM£)

experiencia. Desde hace algún tiempo, el mundo de los juegos en línea ofrece los
usuarios un entorno tridimensional rico en experiencias y contenidos. Más
recientemente, el concepto de entorno virtual tridimensional ha ido ganando un
amplio interés, ejemplificado sobre todo por entornos como los mundos virtuales.
En el mundo tridimensional, los usuarios se definen a sí mismos como avatares y se
mueven por un entorno tridimensional interactuando con otras personas y objetos.
En muchos sentidos, el entorno virtual tridimensional puede representar la
próxima generación del entorno de Internet. Además de alojar un servidor HTTP, las
instituciones tendrían que alojar un servidor HTTP tridimensional que acepte
conexiones de los usuarios y entregue a cambio contenidos tridimensionales. Los
usuarios interactuarían con un navegador tridimensional, que es en realidad la
aplicación cliente del mundo virtual. Se moverían entre los sitios de la misma
manera que se accede a los sitios web convencionales a través de un navegador
HTTP e hipervínculos. Sin embargo, en la Internet virtual tridimensional, la
experiencia sería similar a la de encontrarse en otro lugar tridimensional, como
cuando los usuarios cambian de isla en un mundo virtual.
Existen implementaciones comerciales patentadas de mundos virtuales
tridimensionales; sin embargo, hay varios estándares abiertos disponibles. El
lenguaje original de modelado de realidad virtual (VRML) [30] ha evolucionado y
se ha estandarizado como parte de las especificaciones tridimensionales extensibles
(X3D) definidas por el consorcio Web3D [31]. Esta norma esboza un mecanismo de
entrega de contenidos y aplicaciones tridimensionales en tiempo real que permite la
manipulación interactiva, la comunicación y la visualización de escenas
tridimensionales codificadas en XML.
Independientemente de cómo se manifiesten los protocolos subyacentes, la
posible aparición del entorno virtual tridimensional de Internet puede ofrecer nuevas
oportunidades en la entrega de contenidos y servicios multimedia. Desde la
perspectiva del SDP, esto puede incorporarse al diseño con el despliegue de un
servidor HTTP tridimensional que devuelva contenido X3D VRML junto con
repositorios adicionales para almacenar y gestionar imágenes de escenas
tridimensionales. Se pueden admitir nuevas aplicaciones multimedia
tridimensionales que también devuelvan contenidos tridimensionales en el formato
codificado adecuado. Puede ser prudente suponer que el próximo paso evolutivo de
los contenidos puede ser tridimensional. Por lo tanto, las plataformas de distribución
que puedan ampliarse para dar cabida a contenidos para estos entornos virtuales
estarán bien posicionadas para captar los mercados emergentes.

Resumen y conclusiones
La plataforma de prestación de servicios es una combinación de TIC que permite al
operador ofrecer una amplia gama de servicios multimedia a través de numerosos
canales de red.
£plataformas de prestación de servicios y multimedia £diseño de 303
servicios

y tipos de dispositivos. Existen varios marcos que definen cómo construir una
plataforma de soporte de servicios multimedia. Entre ellos figuran el IMS, el SDP
basado en TI, Parlay y Parlay-X, el software como servicio y el marco de prestación
de servicios del TM Forum. Aunque el IMS se ha erigido en norma clave para
definir una plataforma de prestación de servicios, son necesarias una serie de
ampliaciones para garantizar que el marco IMS subyacente sea capaz de abordar la
gama más amplia de servicios multimedia disponibles. Las plataformas de
prestación de servicios basadas en tecnologías de la información llevan varios años
comercializándose y superando muchos de los problemas de integración e
implantación. Son capaces de soportar una amplia gama de servicios multimedia
alojados interna o externamente y cuentan con enfoques de integración
estandarizados para OSS, BSS y sistemas de comunicación de red. La combinación
de las plataformas SDP existentes y el IMS parece responder lógicamente a las
necesidades de los servicios de telecomunicaciones y multimedia, y actualmente se
está unificando un enfoque combinado en la iniciativa de estándares TM Forum
SDF.
En este capítulo se ha esbozado cómo las distintas arquitecturas marco pueden
La plataforma de prestación de servicios constituye la base de los sistemas de apoyo
a la prestación de los operadores. La plataforma de prestación de servicios
constituye la base de los sistemas de apoyo a la prestación de servicios de los
operadores, y la arquitectura de referencia esbozada en este capítulo se basa en las
normas actuales y emergentes, junto con las experiencias de despliegue en SDP
basadas en TI. Además, se han utilizado varios escenarios para ilustrar cómo los
diversos componentes IMS y SDP proporcionan un conjunto consolidado de
funciones con aplicaciones externas de terceros. Se han evaluado las tendencias en
el diseño multimedia y se ha examinado su impacto en el futuro del SDP. Mediante
la adopción clara de una plataforma estratégica, los servicios emergentes podrán
adoptarse de forma coherente. Aunque los despliegues tradicionales del SDP
parecen centrarse en la red o en las TI [6], en la práctica la combinación perfecta de
estos dos paradigmas tecnológicos puede producir los resultados más satisfactorios
en la prestación de los servicios actuales y futuros.
Si analizamos más a fondo el impacto de la convergencia multimedia, parece
todas las formas de contenidos y servicios pueden acabar prestándose en formato
digital. Esto incluye las ofertas tradicionales de telecomunicaciones, como la
videotelefonía, la radiodifusión interactiva y las teleconferencias. Estos y otros
servicios de comunicación parecen encaminados a convertirse inevitablemente en
una aplicación multimedia (TI) más, lo que cambiará la naturaleza de la prestación
de todas las formas de contenido por parte del operador. Esta realidad sugiere que la
plataforma de prestación de servicios ganará en importancia para el operador. El
establecimiento de una arquitectura consolidada para la prestación de servicios
ayudará a abordar la fusión de oportunidades multimedia, aumentando las
capacidades que estas soluciones pueden ofrecer. Los operadores más capaces de
aprovechar esta convergente estarán estratégicamente situados para ofrecer la gama
más amplia de servicios multimedia a los consumidores. La arquitectura esbozada,
basada en SDP de IMS e IT, intenta dar respuesta a estas necesidades convergentes
de prestación de servicios multimedia, proporcionando un modelo para los
operadores que deseen desarrollar plataformas extensibles en la prestación de
servicios.
304 Manual del subsistema multimedia fP (fM£)

Referencias
1. Bushnell, W. 2004. IMS based converged wireline-wireless services. Proceeds of the 9th
International Conference on Intelligence in Service Delivery Networks, Burdeos, Francia,
octubre de 2004:18-21.
2. Pailer, R., J. Stadler e I. Miladinovic. 2003. Using PARLAY APIs over a SIP system in a
distributed service platform for carrier grade multimedia services. Redes inalámbricas
9(4):353-363.
3. Baravaglio, A. C., A. Licciardi y C. Venezia. 2005. Web service applicabil- ity in
telecommunication service platforms. International Journal of Web Services Practices 1(1-
2):167-172.
4. Pavlovski, C. J., y Q. Staes-Polet. 2005. Digital media and entertainment ser- vice delivery
platform. Proceedings of the 1st ACM International Workshop on Mul- timedia Service
Composition, Singapur, 2005:47-54.
5. Lee, I., H. Park, K. Park y S. Kim. 2006. A study on architecture and perfor- mance of
service delivery platform in home networks. Asociación Internacional de Ciencia y
Tecnología para el . Proceedings of the 24th IASTED International Conference on Parallel
and Distributed Computing and Networks, 2006:244-249.
6. Pavlovski, C. J. 2007. Plataformas de prestación de servicios en la práctica. IEEE Communica-
tions Magazine 45(3):114-121.
7. Especificación TMF, marco de prestación de servicios: Charter, release 1.0, version 1.3,
agosto de 2007, Tele Management Forum. Disponible en [Link]
[Link]?catID=4665&linkID=33599&docID=6868
8. Pavlovski, C. 2002. Arquitectura de referencia para una plataforma de servicios de Internet
móvil. Actas de la 2ª Conferencia Internacional Asiática sobre Informática Móvil (AMOC
2002). Langkawi Island, Malasia, 2002:114-123.
9. Devine, A. 2001. Los proveedores de contenidos de Internet móvil y sus modelos de negocio.
Tesis de máster, Departamento de Ingeniería Eléctrica y Gestión. The Royal Institute of
Technology, Estocolmo.
10. Pavlovski, C. J., y L. Plant. 2007. Service delivery platforms in mobile con- vergence.
Encyclopedia of mobile computing and commerce, Vol. II (EMCC Vol. 2). Hershey, PA: IDEA
Group.
11. Jonason, A. y Eliasson, G., 2001. Ingresos de Internet móvil: An empirical study of the I-
mode portal. Internet Research: Electronic Networking Applications and Policy, 11(4): 341-
348.
12. Magedanz, T., y M. Sher. 2006. Plataformas abiertas de prestación de servicios basadas en
TI para redes móviles: De CAMEL al sistema multimedia IP. En The handbook of mobile
middleware, ed., P. Bellavista y A. Corradi. P. Bellavista y A. Corradi. Boca Ratón, FL:
Chapman & Hall/CRC Press.
13. Proyecto de Asociación de Tercera Generación (3GPP). 2005. Technical specification group
services and system aspects; IP multimedia subsystem (IMS), stage 2 (release 7),
especificación técnica TS 23.228 v7.0.0 (2005-06), Valbonne, Francia.
14. Khan, S. Q., R. Gaglianello y M. Luna. 2007. Experiencias con la combinación de HTTP,
RTSP e IMS. IEEE Communications Magazine 45(3):122-128.
£plataformas de prestación de servicios y multimedia £diseño de 305
servicios
15. Magedanz, T., D. Witaszek y K. Knuttel. 2004. Service delivery platform options for next-
generation networks within the national German 3G beyond testbed. Proceedings of South
African Telecommunication Networks Architectures Conference, Stellenbosch, Sudáfrica.
16. Buono, A., S. Loreto y L. Miniero. 2007. A distributed IMS enabled conferencing
architecture on top of a standard centralized conferencing framework. IEEE
Communications Magazine 45(3)152-159.
17. Lozinski, Z. 2003. Parlay/OSA: una nueva forma de crear servicios inalámbricos. Actas de
Mobile Wireless Data, Consorcio Internacional de Ingeniería.
18. Hwang, T., H. Park y J. W. Jung. 2004. The architecture of the digital home services delivery
with OSGi. Conferencia IASTED sobre sistemas y aplicaciones de comunicación (CSA
2004). Banff, Canadá.
19. Grupo Parlay. Acceso a servicios abiertos (OSA). 2007. Servicios web Parlay X. Part 1:
Common Parlay X 3. Instituto Europeo de Normas de Telecomunicación (ETSI) Norma
ETSI 202 504-1, V0.0.3, Francia, junio de 2007.
20. Grupo Parlay. Acceso a servicios abiertos (OSA). 2007. Interfaz de programación de
aplicaciones (API): Descripción general (Parlay 6), Instituto Europeo de Normas de
Telecomunicación (ETSI) Norma ETSI 204 915-1, V0.0.1, Francia.
21. Bennett, K., P. Layzell, D. Budgen, P. Brereton, L. Macaulay y M. Munro. 2000. Software
basado en servicios: The future for flexible software. Proceedings of 7th Asia-Pacific
Software Engineering Conference (APSEC), diciembre: 214-221.
22. Lancaster,B.,[Link]:[Link]
4(5) artículo 4. Disponible en htp://[Link]/1007/pdf/Article_4.pdf
23. Especificación TMF. 2007. Service delivery framework overview, TR139, versión 0.9.3,
Tele Management Forum, octubre.
24. Greene, W., y B. Lancaster. 2007. El mundo de la telegestión desde dentro. Pipeline 3(8)
artículo 4. Disponible en [Link]
[Link]
25. Kuma, A. 2007. Televisión móvil: DVB-H, DMB, sistemas 3G y aplicaciones multimedia
enriquecidas.
Louis, MO: Focal Press.
26. Proyecto de Asociación de 3ª Generación. 2007. Technical specification group services and
system aspects; multimedia broadcast/multicast service (MBMS); architec- ture and
functional description (release 8), 3GPP TS 23.246 V8.0.0.
27. Consorcio World Wide Web (W3Ca). 2003. Requisitos de interacción multimodal. Nota
del W3C de 8 de enero de 2003. Disponible en [Link] reqs
28. Proyecto de Asociación de 3ª Generación. 2000. Descripción del servicio multillamada:
Stage 1 (release 1999), 3GPP TS 22.135, v3.2.0.
29. Pavlovski, C. J., y S. Mitchell. 2007. Movilidad e interfaces de usuario multimodales.
Encyclopedia of mobile computing and commerce, Vol. I. Hershey, PA: IDEA Group.
30. Consorcio Extensible 3D (X3D). 2003. Lenguaje de modelado de realidad virtual
(VRML97), norma internacional X3D ISO/IEC 19775-1:2004.
31. Consorcio Extensible 3D (X3D). 2005. Information technology-Computer graphics and
image processing-Extensible 3D (X3D). Norma internacional X3D ISO/IEC 19775-
1:2004.
13
La fntegración de la fM£ en plataformas de
prestación de servicios basadas en £.
Arquitecturas orientadas a los servicios

Niklas Blum, Peter Weik y Thomas Magedanz

CONTENIDO
Introducción ....................................................................................................................... 307
Plano de un SDP basado en SOA sobre IMS ................................................................... 308
Componentes y normas de un SDP basado en SOA para las NGN ........................... 311
El subsistema multimedia IP 3GPP ...................................................................... 311
Gestor de Interacción de Capacidades de Servicio (SCIM) ................. 313
Habilitador IMS ......................................................................................................... 313
Habilitador de aplicaciones ....................................................................... 314
Facilitador de la identidad ......................................................................... 315
Abstracción de redes............................................................................................... 316
API basadas en servicios web ...................................................................... 317
Evaluación del Entorno y la Política de Servicios de OMA, Ejecución,
y Gestión ..................................................................................................... 318
Corredor de servicios ................................................................................................. 320
Integración de operaciones y sistemas de apoyo a la empresa .......................... 322
Exposición de servicios para mash-ups basados en web ........................................ 323
Web 2.0 para las telecomunicaciones ........................................................... 324
Habilitador de identidad ............................................................................ 325
Conclusiones ........................................................................................................................ 326
Referencias .......................................................................................................................... 327

Introducción
La convergencia de redes y aplicaciones de telecomunicaciones fijas y móviles,
redes de cable e Internet desemboca en una red global de próxima generación
(NGN) basada exclusivamente en IP. Plataformas de servicios flexibles y potentes,

307
308 Manual del subsistema multimedia fP (fM£)

Las denominadas plataformas de prestación de servicios (SDP) se encargan de

apoyar el diseño, la creación, el despliegue, el aprovisionamiento y la gestión
eficientes de servicios integrados a través de diferentes redes de acceso que soportan
diversos modelos de negocio. La reutilización de un conjunto extensible de
componentes de servicio existentes para crear rápidamente nuevas aplicaciones
orientadas al mercado ha sido un aspecto clave de las plataformas de
telecomunicaciones durante muchos años. En la actualidad, las arquitecturas
orientadas a servicios (SOA) se consideran el estado del arte de las plataformas de
prestación de servicios.
En este contexto, una plataforma flexible de prestación de servicios de
telecomunicaciones puede servir para múltiples propósitos. Para los operadores que
no disponen de una infraestructura heredada (por ejemplo, proveedores de servicios
de Internet u operadores de cable), la SDP les permite reutilizar sus habilitadores de
servicios, exponer capacidades y servicios de red a terceros e integrar sin fisuras
funciones del sistema de soporte operativo (OSS) y del sistema de soporte
empresarial (BSS), como el aprovisionamiento, la supervisión y la gestión de las
relaciones con los clientes.
No obstante, la mayoría de los operadores de telecomunicaciones se encuentran en
una situación de transición entre las infraestructuras heredadas y las basadas en las
NGN. Aquí es donde un SDP de NGN puede añadir más valor; el SDP puede servir
tanto para redes heredadas como para redes centrales basadas en NGN y, por lo
tanto, puede actuar como elemento puente durante el periodo de transición. Las
aplicaciones que utilizan estos SDP se abstraen totalmente de los nodos de red, los
protocolos específicos y las interfaces de programación de aplicaciones (API).
Además, un SDP de este tipo puede servir de pasarela de acceso o exposición para
aplicaciones de terceros y servicios mash-up basados en la Web.
Este capítulo describe la funcionalidad de una plataforma de prestación de
servicios agnóstica de red basada en los principios de la arquitectura orientada a
servicios y nombra sus componentes principales y la funcionalidad requerida tal y
como se prototipa actualmente como parte del Open SOA Telco Playground en
Fraunhofer FOKUS para redes centrales basadas en IMS.

Plano de un SDP basado en SOA sobre IMS

Una arquitectura orientada a servicios es un estilo arquitectónico que guía todos los
aspectos de la creación y el uso de procesos empresariales empaquetados como
servicios a lo largo de sus ciclos de vida. También define y aprovisiona la
infraestructura informática que permite a las distintas aplicaciones intercambiar
datos y participar en procesos empresariales libremente acoplados a los sistemas
operativos y lenguajes de programación subyacentes a dichas aplicaciones [1]. La
SOA representa un modelo en el que la funcionalidad se descompone en distintas
unidades (servicios) que pueden distribuirse a través de una red y combinarse y
reutilizarse para crear aplicaciones empresariales. Estos servicios se comunican
entre sí pasando datos de un servicio a otro o coordinando una actividad entre dos o
más servicios.
La integración de la gestión financiera en las plataformas de 309
prestación de servicios

Los servicios web pueden utilizarse para implantar una arquitectura orientada a
servicios. Uno de los principales objetivos de los servicios Web es hacer accesibles
los bloques funcionales a través de protocolos estándar de Internet, independientes
de plataformas y lenguajes de programación. Estos servicios pueden ser nuevas
aplicaciones o simplemente envolver sistemas heredados existentes para habilitarlos
para la red.
Cada bloque de construcción SOA puede desempeñar una o más de tres funciones:

• El proveedor de servicios crea un servicio web y, en su caso, publica su

interfaz e información de acceso en el registro de servicios.
• El corredor de servicios es responsable de poner a disposición de cualquier
solicitante potencial de servicios la información de acceso a la interfaz y a
la implementación de los servicios Web. Además, el broker puede
utilizarse como instancia de control central que orquesta los componentes
de la arquitectura global.
• El solicitante de servicios o cliente de servicios Web localiza las entradas
en el registro del broker y se vincula al proveedor de servicios para invocar
uno de sus servicios Web.

La SOA también puede considerarse un estilo de arquitectura de sistemas de información

que permite crear aplicaciones mediante la combinación de servicios interoperables
y poco acoplados [2]. Estos servicios interoperan basándose en una definición formal
(o contrato, por ejemplo, lenguaje de descripción de servicios web [WSDL] [3] o
política de uso) que es independiente de la plataforma subyacente y del lenguaje de
programación. La definición de la interfaz oculta la implementación del servicio
específico del lenguaje. Por tanto, los sistemas basados en SOA pueden ser
independientes de las tecnologías y plataformas de desarrollo. Los lenguajes de alto
nivel, como el lenguaje de ejecución de procesos de negocio (BPEL), amplían el
concepto de servicio proporcionando un método para definir y soportar la
orquestación de servicios de grano fino en servicios de negocio de grano grueso, que
a su vez pueden incorporarse a flujos de trabajo y procesos de negocio
implementados en aplicaciones compuestas o portales [4].
El concepto de SOA descrito anteriormente tiene una larga historia en el sector de
las telecomunicaciones. Su origen se remonta al desarrollo de la red inteligente (IN)
en los años ochenta. El principal objetivo era desarrollar un entorno de red
programable para la prestación de nuevos servicios de valor añadido (SVA)
ampliaran el "sistema telefónico convencional" (POTS) y generaran nuevos
ingresos. La idea era definir una arquitectura de servicios superpuesta sobre una red
física y extraer la inteligencia de servicio de los conmutadores de red heredados en
puntos centrales de control de servicio (SCP) dedicados. La independencia de
servicio de la arquitectura IN debería haberse conseguido mediante la definición de
componentes de servicio reutilizables, que pudieran encadenarse ade- cuadamente
para la realización de nuevos servicios.
La figura 13.1 muestra nuestro proyecto de plataforma de prestación de servicios
basada en SOA, adecuada tanto para redes de próxima generación como para redes
heredadas.
 310
Proveedores de servicios de
terceros/ Web 2.0 Mash-ups

Entorno de Evaluación, aplicación y gestión Web 2.0 Telco Habilita

Inventari Registr Servicio Corredor
creación de de políticas Enabler dor de
o de o de
servicios identida
recursos servicios
d

Bus de servicios empresariales

OSS SRS
API de exposición de habilitadores

Motor de Monitor Carga en

aprovisiona de red línea

Manual del subsistema multimedia fP (fM£)

miento
SCIM
Gestor de
Facturaci
Administrad fallos
ón
or de
dispositivos

Directo Activado Servidor de Presenci Gestión de Ubicación Mensajería Autenticación

CRM
r de r de aplicacio a direcciones/gr
pruebas servicio nes upos

Núcleo basado en NGN Núcleo

heredado

HSS

I-CSCF S-CSCF

P-CSCF
FIGURA 13.1
Arquitectura FOKUS Open SOA Telco Playground.
La integración de la gestión financiera en las plataformas de 311
prestación de servicios

Los principales componentes de esta arquitectura son:

• una capa de abstracción de red que proporciona interfaces bien definidas a

determinados habilitadores de aplicaciones como parte del IMS
subyacente;
• un autobús de mensajería para conectar otros servicios (en dirección norte);
• una entidad intermediaria de servicios;
• una función de evaluación, aplicación y gestión de las políticas;
• directorios de recursos y servicios;
• interfaces con los OSS y los SRS;
• posibles habilitadores específicos de telecomunicaciones y API para mash-
ups basados en la web;
• un habilitador de autenticación; y
• para entornos de creación de servicios.

En las secciones siguientes se describe con más detalle cada uno de estos
componentes y se ofrece un breve resumen del estado actual de la normalización.

Componentes y normas de un SDP basado en SOA para las NGN

Los componentes anteriormente mencionados tienen su origen en distintos campos
de las tecnologías de la comunicación, no sólo en las telecomunicaciones, sino
también en las tecnologías de la información (TI). Por lo tanto, también hay que
tener en cuenta los distintos organismos de normalización asociados, especialmente
en lo que respecta a las tecnologías de la World Wide Web (WWW), en rápida evolución.
Las llamadas normas de facto han sido creadas por diferentes empresas y particulares.

El subsistema multimedia IP 3GPP

Aunque el IMS no forme parte del SDP, proporciona las interfaces para la interacción
y la infraestructura subyacente de control de las comunicaciones. El subsistema
multimedia IP (IMS) [5-7] se define a partir de las especificaciones de la versión 5 del
3rd Generation Partnership Project (3GPP) como una arquitectura superpuesta sobre la
red central de conmutación de paquetes (PS) del 3GPP para la prestación de
servicios multimedia en tiempo real. La figura 13.2 muestra la arquitectura IMS
simplificada.
Debido a que la arquitectura superpuesta IMS se abstrae ampliamente de las
interfaces aéreas, el IMS puede utilizarse para cualquier tecnología de red de acceso
móvil, así como para la tecnología de acceso de línea fija, tal como promueve
actualmente el Instituto Europeo de Normas de Telecomunicaciones (ETSI)
Servicios y Protocolos Convergentes de Telecomunicaciones e Internet para Redes
Avanzadas (TIS- PAN) dentro de la definición de la arquitectura de referencia de la
red de próxima generación.
312 Manual del subsistema multimedia fP (fM£)

Parlay X
Pasarela
Presencia
SIP AS
XDMS Servidor

HSS

I-CSCF S-CSCF
Redes heredadas
GSM, RTC

P-CSCF

Medios Señalizació
de n
SIP comuni Pasarela
Flujo de medios
en diámetro Medios
de
comunic

FIGURA 13.2
Arquitectura IMS básica.

Cuatro funcionalidades clave adicionales marcan el IMS como la tecnología del

futuro en una red integral orientada a servicios y aplicaciones:

1. El IMS ofrece formas fáciles y eficaces de integrar diferentes servicios,

incluso de terceros. Se prevén interacciones entre distintos servicios de
valor añadido.
2. El IMS permite una integración perfecta de los servicios heredados y está
diseñado para interacciones coherentes con los dominios de conmutación
de circuitos.
3. El IMS admite mecanismos para negociar la calidad del servicio (QoS).
Dentro de una sesión, un usuario puede solicitar QoS para determinados
contextos del protocolo de datos por paquetes (PDP) en la interfaz aérea
crítica de tercera generación.
4. El IMS proporciona mecanismos de tarificación apropiados, por lo que es
posible realizar diferentes modelos de negocio y cobrar por eventos
específicos utilizando un esquema apropiado, como el basado en la
duración, los datos transferidos o la calidad del servicio.
La integración de la gestión financiera en las plataformas de 313
prestación de servicios

Las técnicas y metodologías concretas que se requieren para obtener estas

funcionalidades clave no son nuevas, pero el IMS proporciona la primera
integración importante y la interacción de todas las funcionalidades clave.
El IMS se basa en los principios y protocolos de Internet definidos por el IETF
(Internet Engineering Task Force) y que han sido adaptados para su uso en un
entorno seguro, escalable y de nivel portador. El protocolo de iniciación de sesión
(SIP) [8] se utiliza como protocolo de señalización estándar que establece, controla,
modifica y finaliza sesiones de voz, vídeo y mensajería entre dos o más participantes
[9,10]. Los servidores de señalización relacionados en la arquitectura se denominan
funciones de control del estado de la llamada (CSCF) y se distinguen por sus
funcionalidades específicas. La funcionalidad relacionada con la autenticación,
autorización y contabilidad (AAA) proporcionada dentro del IMS se basa en el
protocolo IETF DIAMETER [11] y en el control de crédito DIAMETER [12] y se
implementa en el servidor de abonado doméstico (HSS) y en la arquitectura de
tarificación 3GPP (debido a su complejidad, no se describe en este capítulo). El HSS
constituye el nexo organizativo entre las CSCF y los servidores de aplicaciones
(AS), mientras que la señalización en tiempo real entre las CSCF y los AS se basa
en SIP utilizando la interfaz de control de servicios IMS (ISC). La comunicación
entre el HSS y un AS se basa en DIAMETER. Desde la perspectiva del , un SDP
basado en SOA actúa como un simple servidor de aplicaciones.
Mediante la definición de entidades lógicas que se conectan entre sí a través de
protocolos estandarizados, se ha creado una arquitectura plug-and-play que ofrece la
posibilidad de situar físicamente cada función en distintas ubicaciones y montar un
IMS con funciones de distintos proveedores.

Gestor de Interacción de Capacidades de Servicio (SCIM)

3GPP ha introducido SCIM [13] como una función dentro del dominio del servidor de
aplicaciones SIP de IMS para gestionar las interacciones entre servidores de
aplicaciones. Sin embargo, las funcionalidades de gestión de interacciones de
servicio de SCIM no están especificadas, y la investigación en este campo está en
curso. Básicamente, hay dos formas diferentes de conseguir dicha funcionalidad: (1)
un despachador de peticiones dentro del entorno de ejecución, o (2) un gestor de
interacciones en la interfaz ISC entre la S-CSCF y varios servidores de aplicaciones.
Mientras que la primera solución forma parte de la próxima especificación SIP
Servlet 1.1 (JSR 289)
[14] denominado "Enrutador de aplicaciones" y sólo se especifica para
implementaciones conformes con JSR 289, esta última se considera un tema abierto.

Habilitador IMS
En esta sección describimos el concepto de habilitador de aplicaciones para el IMS
y distinguimos entre un habilitador de aplicaciones general y un habilitador de
identidad específico que está siendo estandarizado por el 3GPP.
314 Manual del subsistema multimedia fP (fM£)

Habilitador de aplicaciones
De forma similar a los bloques de construcción independientes del servicio (SIB),
que forman parte del modelo conceptual de las redes inteligentes, durante los
últimos años la Open Mobile Alliance (OMA) ha definido habilitadores de servicio
para el subsistema multimedia IP. La idea nació inicialmente durante la
especificación de un servicio push-to-talk over cellular (PoC) [15], un servicio de
comunicación de tipo walkie-talkie entre varios pares móviles basado en el protocolo de
Internet (IP) que utiliza SIP, el protocolo de transferencia en tiempo real (RTP) y el
protocolo de control de transferencia en tiempo real (RTCP) [16]. PoC utiliza la
presencia, la gestión de grupos y la mensajería instantánea como habilitadores para
proporcionar información tanto a los usuarios como al servicio PoC. Esto llevó,
además de a la estandarización de PoC, a la definición de SIMPLE de presencia (SIP
for instant messaging and presence leveraging extensions) [17] para presencia,
mensajería instantánea y gestión de documentos XML (XDM).
[18] para la gestión de grupos y listas. La PdC como servicio disponible
públicamente nunca tuvo una aceptación real fuera del mercado estadounidense,
pero el concepto de habilitadores abstractos de aplicaciones se utiliza ahora
ampliamente. Otros habilitadores de aplicaciones que no están estandarizados por la
OMA pero que deberían formar parte de todas las capas de abstracción de red son el
control de llamadas y el control de conferencias. Otros habilitadores deberían ser la
tarificación y, en función de las capacidades subyacentes de la red, la mensajería
heredada, como el servicio de mensajes cortos (SMS) y el servicio de mensajes
multimedia (MMS) o la localización. La figura 13.3 ofrece una visión general de las
interfaces relacionadas con IMS para los habilitadores de aplicaciones.

La interfaz ISC se encuentra entre la implementación del servidor habilitador

y el núcleo IMS. Proporciona al habilitador de servicios control de
llamadas SIP/SDP, suscripción y notificación relacionadas con eventos
SIP, mensajería SIP, etc.

Habilitador de aplicaciones IMS

Sh/Dh

Ro
Ut

Rf

Mb
Gm
ISC

Núcleo IMS

FIGURA 13.3
Interfaces de los habilitadores de servicios IMS con el núcleo IMS.
La integración de la gestión financiera en las plataformas de 315
prestación de servicios

La interfaz Sh se encuentra entre el AS y el HSS en el núcleo IMS.

Proporciona al habilitador de aplicaciones operaciones de lectura y
escritura de datos de usuario relacionados con el IMS. También
proporciona funciones de suscripción y notificación de cambios en los
datos de usuario.
La interfaz Dh se establece entre el AS y la función de localización de
abonados (SLF). Es bastante similar a la interfaz Sh y la utilizan las
implementaciones de habilitadores para obtener la dirección del HSS que
gestiona un usuario concreto en la red cuando hay varios HSS.
La interfaz Ut se establece entre el terminal y la implementación del servidor
del habilitador. Proporciona al equipo de usuario (UE) un conjunto de
operaciones que permiten configurar datos específicos relacionados con el
usuario en el habilitador de servicios. Los datos específicos del usuario
constituyen, entre otros, la gestión de la configuración, como las listas de
presencia y las reglas de autorización. El protocolo utilizado en la interfaz
Ut se basa en el protocolo de acceso a la configuración XML (XCAP) [19].
La interfaz Ro proporciona al habilitador de servicios una interfaz de tarificación
basada en eventos para el sistema de tarificación en línea en el núcleo IMS.
El protocolo utilizado en la interfaz Ro es DIAMETER.
La interfaz Rf proporciona al habilitador de servicios una interfaz con el
sistema de tarificación offline en el núcleo IMS. El protocolo utilizado en
la interfaz Rf es DIAMETER.
La interfaz Gm se encuentra entre el UE y el núcleo IMS. Proporciona al
habilitador de servicios control de llamadas SIP/SDP, suscripciones y
notificaciones relacionadas con eventos SIP, mensajería SIP, etc.
La interfaz Mb proporciona al habilitador de servicios flujos de medios de
paquetes en el plano de usuario sobre IP a través del núcleo IMS. RTP y
RTCP son los protocolos utilizados en la interfaz Mb.

Habilitador de identidad
Con la especificación de la arquitectura de arranque genérica (GBA) [20], el 3GPP
ha especificado un habilitador de identidad específico para el IMS que permite
autorizar servicios no IMS mediante el uso de credenciales almacenadas en una
tarjeta inteligente basada en un módulo de identidad de abonado (SIM). Las
identidades telco (por ejemplo, el URI SIP de un usuario) se comprueban durante un
proceso de registro y luego se codifican en la señalización de red del operador. Sin
embargo, no existe una forma bien definida de transportar información de atributos a
servicios de terceros en la web. Las redes IMS transportan una cabecera de identidad
afirmada a todos los servicios basados en IMS para todo el tráfico SIP; sin embargo,
para autenticar la interacción de servicios HTTP puros, los operadores siguen
confiando muy a menudo en combinaciones de nombre de usuario y contraseña.
También existe un medio de validar mutuamente a los interlocutores de
comunicación digital basado en la información almacenada (por ejemplo, en una
tarjeta inteligente y en una base de datos de usuarios de telecomunicaciones) [21].
La GBA ha sido adoptada por muchos otros grupos, como ETSI TISPAN, y utiliza
esta posibilidad para arrancar redes seguras.
316 Manual del subsistema multimedia fP (fM£)

conexiones HTTP y derivar credenciales a corto plazo de las credenciales a largo

plazo almacenadas en una tarjeta inteligente y el HSS para afirmar identidades
también para el tráfico HTTP.

Abstracción de red
La IN se impulsó conceptualmente explotando la llamada a procedimiento remoto
(RPC) y la programación funcional, pero el mundo de las TI se ha orientado hacia la
orientación a objetos. Los lenguajes de programación orientados a objetos, como
C++ y Java, han dado lugar a nuevos conceptos de middleware que han permitido
implantar plataformas de prestación de servicios escalables y distribuidas y han
proporcionado abstracción de los detalles de los protocolos subyacentes de
señalización y transporte de red.
Las API de telecomunicaciones se introdujeron a mediados de los noventa; tenían
básicamente los mismos objetivos que las IN, pero se basaban en conceptos
informáticos más nuevos: las tecnologías orientadas a objetos y las tecnologías de
middleware distribuido relacionadas, como CORBA (arquitectura de intermediario de
petición de objetos comunes) del Grupo de Gestión de Objetos (OMG) y la invocación
de métodos remotos (RMI) de Java, que en combinación con C++ y Java,
proporcionaban la base para implantaciones de servicios bastante flexibles. Las
normas API de telecomunicaciones relacionadas, como Parlay, la arquitectura de
servicio abierto 3GPP (OSA) y las API Java para redes integradas (JAIN), tienen
como objetivo facilitar la implementación de servicios de telecomunicaciones en
comparación con la IN tradicional, abstrayéndose de los detalles del protocolo de
señalización de las redes de telecomunicaciones subyacentes (como el protocolo de
usuario RDSI (ISUP), SIP o incluso el protocolo de aplicación IN (INAP)). Estas API
se han definido en los últimos años de forma orientada al mercado y ofrecen
funciones relacionadas con las telecomunicaciones, como control de llamadas,
conferencias, mensajería, localización, tarificación, presencia y definición de
grupos.
La idea básica de estas API era que las AS albergaran el acceso a la lógica de la
aplicación.
La aplicación se conecta a estas API a través de una conexión de red segura,
proporcionada por una pasarela de servicios de red dedicada. Los servidores de
aplicaciones podrían ser operados por el operador de la red o, eventualmente,
dependiendo del modelo de negocio, por terceros. Con respecto a este último
enfoque, las capacidades de la red podrían exponerse a terceros para aprovechar su
creatividad y crear modelos de negocio beneficiosos tanto para los operadores como
para los proveedores de aplicaciones en caso de que las API se normalizaran y
publicaran a nivel mundial; se establecería una competencia entre operadores y
proveedores de aplicaciones. La figura 13.4 muestra el uso de una pasarela
Parlay/OSA.
Otro aspecto importante de estas API era su apertura inherente (es decir, su
extensibilidad funcional a lo largo del tiempo). Es posible añadir nuevas operaciones
e interfaces API, si es necesario, para hacer frente a las demandas del mercado y la
innovación tecnológica. Por eso se han definido interfaces especiales, denominadas
interfaces marco, que permiten registrar y descubrir (nuevas) interfaces y realizar
acuerdos de nivel de servicio (SLA).
Aunque esta tecnología era muy prometedora, su aceptación en el mercado ha
tardado mucho tiempo porque la mayoría de los operadores de red aún no estaban
dispuestos a abrir sus redes a terceros. Además, las API aún estaban
La integración de la gestión financiera en las plataformas de 312
prestación de servicios
Aplicaciones (independientes de la
Aplicac Aplicac Aplicac
tecnología de red subyacente)
ión 1 ión 2 ión N
API Parlay/OSA

Pasarela

POTS/RDSI GSM/CDMA Internet/UMTS

Asignación a protocolos específicos de red

FIGURA 13.4
Pasarela Parlay para varias redes de acceso.

bastante compleja para los no expertos en telecomunicaciones y la orientación a

objetos era demasiado nueva para los ingenieros de telecomunicaciones
tradicionales.

API basadas en servicios web

Basándose en esta experiencia y en la aparición de un nuevo modelo de
programación de Internet de más alto nivel (a saber, las tecnologías de servicios
Web) centrado en el lenguaje de marcado extensible (XML), el WSDL, el inventario
universal de descripción y descubrimiento (UDDI) y el protocolo simple de acceso a
objetos (SOAP) [22] utilizado para las interacciones de los servicios Web, a
principios del nuevo milenio se desarrolló una versión simplificada de las API
Parlay/OSA basadas en CORBA: Parlay X. Parlay X ha sido especificado por el
Grupo Parlay, que, en el momento de escribir estas líneas, se está fusionando con la
OMA. El Grupo Parlay también ha sido respaldado por el 3GPP y hoy representa el
estado del arte de una API de servicios Web relacionados con las
telecomunicaciones.
Parlay X se basó en la observación de que Internet ha creado su propio mercado
real de servicios abiertos, que da lugar a la creación de muchos servicios
innovadores cada día, porque la base de programadores es enorme en lo que respecta
al uso de las principales tecnologías de programación de Internet. Así pues, el
pensamiento de Parlay X ha partido de ahí: el uso directo del paradigma de
programación de Internet a través de la tecnología de servicios Web. Parlay/OSA no
está definiendo su propio mid- dleware, sino que debe considerarse como un
conjunto específico de interfaces funcionales de servicios Web que proporcionan
funciones similares a la API clásica de Parlay/OSA, pero es mucho más fácil de usar
y de integrar en las aplicaciones de servicios Web existentes. La idea es que, en un
mundo de servicios web, los operadores de redes también proporcionen servicios
web de telecomunicaciones para hacer o recibir llamadas de telefonía, enviar y recibir
SMS, MMS o mensajes instantáneos, obtener información sobre la presencia de
usuarios concretos o cobrar transacciones específicas.
318 Manual del subsistema multimedia fP (fM£)

a la factura de telecomunicaciones. Estas capacidades se describen en WSDL

estándar; se utilizan tecnologías de servicios web clásicas para el registro y
descubrimiento de servicios (en concreto, UDDI), y SOAP para llamar a estas
interfaces.
En la actualidad, la mayoría de las plataformas Parlay OSA incluyen también una
pasarela Parlay X para exponer interfaces de telecomunicaciones a terceros. Las API
clásicas de Parlay/OSA se utilizan para la implementación de servicios internos del
operador sobre infraestructuras de red cambiantes.

Evaluación, aplicación y gestión del entorno y la política de

servicios de OMA
Las definiciones de varios habilitadores de servicios de aplicación por parte de la
OMA y la necesidad de una función de acceso general para el acceso a servicios de
terceros condujeron a la especificación del entorno de servicios de la OMA (OSE)
[23]. Define una capa habilitadora que incorpora componentes habilitadores
específicos que ofrecen interfaces northbound a aplicaciones que implementan cierta
lógica de aplicación. Estas aplicaciones residen en el dominio del operador o están
alojadas en el dominio de un tercero. Un componente habilitador puede formar parte
del OSE, o el OSE puede actuar como una aplicación superpuesta que ofrece
interfaces a otras funciones habilitadoras. La figura 13.5 ilustra la arquitectura
propuesta por la OMA.

Terceros - Dominio no fiable Proveedor de

servicios o
Dominio terminal
Implantació
Aplicaciones n de Aplicaciones
habilitadores
La aplicación emite un
La aplicación emite un solicitud a un
Aplicación de los
solicitud a un habilitador
activadores
habilitador emite una solicitud a otro
recurso habilitador Ejecutor de
Policy Enforcer aplica Policy Enforcer aplica políticas
políticas a petición Política políticas a petición entre aplica las políticas
(en función de los Ejecutor implementaciones de que se le solicitan
habilitadores habilitadores (dependiendo de los
disponibles) habilitadores
Solicitud adecuada Solicitud adecuada Implementación del
habilitador
alcanza el objetivo facilitador alcanza el activador de destino emite una solicitud a otro
recurso facilitador
...
Enlaces de servicios web Otros enlaces ...

Implantación de Implantación de Implantación de Implantació

habilitadores habilitadores habilitadores n de
habilitadores

La solicitud invoca la
función
A Recursos en recurso de destino de la
Operadores, terminales, proveedores de implementación del
servicios

FIGURA 13.5
OSE con aplicador de políticas.
La integración de la gestión financiera en las plataformas de 319
prestación de servicios

Básicamente, un OSE incorpora las interfaces de los servicios web y traduce las
peticiones de los servicios web directamente a la lógica del habilitador o a un
protocolo específico del habilitador (en el caso de IMS, principalmente SIP, DIAMETER
y XCAP para XDM). Cuando se escribió este capítulo, OMA no estandarizó ningún
mapeo a una tecnología de mensajería middleware específica, sino que dejó esto
abierto a la implementación de entornos de servicio específicos. Un habilitador
también podría ser una implementación no estandarizada hacia una plataforma de
telefonía específica o una plataforma IN. Además, un habilitador puede
implementarse con varios protocolos que conecten tecnologías NGN con redes
heredadas (por ejemplo, un habilitador de mensajería puede mapearse con SIP,
protocolo de mensajes cortos entre pares (SMPP) [24] para comunicarse con un
SMS-C para enviar SMS y MM-7 [25] para comunicarse con un MMS-C).
Según OMA, un OSE consta de varios elementos arquitectónicos:

• Un habilitador es una tecnología destinada a ser utilizada en el desarrollo,

despliegue u operación de un servicio; definida en una especificación o grupo
de especificaciones; y publicada como un paquete por OMA. Un habilitador
debe especificar una o más interfaces públicas. Algunos ejemplos de
habilitadores de OMA son la localización o la presencia.
• Las implementaciones de habilitadores son elementos del OSE que
representan una implementación de un habilitador (por ejemplo, en un
dominio de proveedor de servicios o en un dominio de terminal). Una
implementación de habilitador puede verse como una plantilla que
representa una implementación de cualquier habilitador (por ejemplo,
MMS o presencia) según lo definido por OMA.
• Las interfaces deben especificarse en un lenguaje neutro. Sin embargo, las
especificaciones también pueden definir enlaces específicos de lenguaje
para las interfaces. Los enlaces de interfaz de los habilitadores proporcionan los
formatos específicos (es decir, la sintaxis y los protocolos utilizados para
acceder a los habilitadores mediante lenguajes de programación o
protocolos de red concretos).
• Un aplicador de políticas es un elemento arquitectónico de OSE que
proporciona un mecanismo de gestión basado en políticas para proteger los
recursos de solicitudes no autorizadas y para gestionar el uso de estas
solicitudes.
• Una aplicación es una implementación de un conjunto relacionado de funciones
queper- forma una cierta lógica de aplicación, a menudo habilitando uno o
más servicios.

El aplicador de políticas (o componente de evaluación, aplicación y gestión de

políticas [PEEM], como la función ha sido denominada oficialmente por la OMA)
puede utilizarse para interceptar solicitudes de servicio de un dominio ajeno, así
como de cualquier otro solicitante de servicios, y determinadas reglas (políticas)
almacenadas en un repositorio. Las políticas pueden utilizarse básicamente para las
autori- zaciones de las solicitudes; es decir, las solicitudes de invocación de
servicios que son interceptadas por el PEEM se comprueban para verificar su
autorización y autenticación válidas. Además, el PEEM puede utilizarse para definir
capacidades de habilitación para la exposición basadas en políticas de solicitud.
Dependiendo del modelo de negocio, también se pueden aplicar diferentes reglas de
tarificación para las solicitudes de servicio a través de políticas específicas.
320 Manual del subsistema multimedia fP (fM£)

Operador de
telefonía móvil
Usuario Usuari Proveedor de red PEEM
A oB Servicio
(1) -Comprobaciones de
proveedores de red
El usuario envía el
servicio Usuario A Autorización
-Envía la identidad del La solicitud llega a un
Solicitar
usuario A tercero

-Obtener la identidad del usuario A Un tercero solicita

-Obtener perfil de usuario A la ubicación B del
-Obtener información de acceso y autorización del (3) usuario
-Mensaje para servicio
informar -Compruebe que el usuario A tiene permiso para
Usuario B que el acceder al servicio (4)
Usuario A desea
localizarle y solicitar -Comprobar la identidad del
la autorización del servicio
(6) (5) -Comprobar el perfil de servicio
-Comprobar que el servicio está
(7) permitido Acceder a la capacidad de
(8) ubicación
OK -Compruebe las políticas del usuario
(9) B
(10)
Usuario B Microteléfono
Calcula su (11) -Llega la autorización del
Posición usuario B
(12) para la
aplicación/usuario lo

El usuario A recibe el -Genera facturas y (13)

de B Información contable
Posición
(14)

FIGURA 13.6
Ejemplo de aplicación de localización basada en políticas con interacción del usuario.

La figura 13.6 muestra el uso de PEEM para una solicitud de servicio de terceros
originada en un dispositivo final de usuario.
En conclusión, una función PEEM constituye el principal componente integral de
un entorno de servicios OMA y proporciona funcionalidades adicionales basadas en
la política de definición del concepto de habilitador OMA. Un PEEM puede servir
como función de autenticación de una pasarela de acceso, pero sus capacidades son
mucho mayores en lo que respecta a la orquestación y manipulación de las
capacidades de los habilitadores. La OMA nombra dos lenguajes de expresión de
políticas diferentes: la política común del IETF [26] para políticas de autorización y
el lenguaje de ejecución de procesos de negocio (para servicios web) WSBPEL 2.0
definido por OASIS (Advanc- ing Open Standards for the Information Society) [27]
para la orquestación de habilitadores.

Corredor de servicios
Los componentes funcionales de la intermediación de servicios son diversos; es
probable que tengan diferentes plataformas de operaciones y gestión y, sin embargo,
tengan que interoperar entre sí (por ejemplo, para proporcionar un servicio integrado
de modelado e intermediación). Tradicionalmente, uno de los enfoques de esta
cuestión consiste en emplear una de las
La integración de la gestión financiera en las plataformas de 321
prestación de servicios

tecnologías de computación distribuida (por ejemplo, CORBA y DCOM) [28]. Sin embargo,
este enfoque implica un acoplamiento estrecho entre todas las partes implicadas y
puede requerir que utilicen la misma plataforma de proveedor. Se trata de serias
limitaciones, especialmente para las aplicaciones de intermediación de servicios,
cuya principal función es facilitar las asociaciones y la interoperabilidad entre un
número potencialmente elevado de servicios.
En cambio, los servicios web ofrecen un medio de integración flexible y poco
acoplado. Las interfaces WSDL codificadas en XML y los mensajes SOAP son
independientes de la plataforma y favorecen el desarrollo y las pruebas simultáneas.
El uso de HTTP como mecanismo de transporte significa que, en la mayoría de los ,
los mensajes SOAP pueden atravesar las fronteras de la red sin necesidad de realizar
cambios en las políticas y la configuración. Por ello, los servicios web son una
tecnología de integración ideal para realizar aplicaciones de intermediación de
servicios.
Un potente corredor de servicios es la principal función de orquestación de todos
los componentes de una arquitectura orientada a servicios. La activación dinámica
de servicios, el cumplimiento de servicios y la composición de servicios de
múltiples habilitadores de servicios requieren la participación de muchas funciones
de la red de un operador. El corredor de servicios interactúa con todos los
componentes conectados al bus de servicios y funciona como componente
vinculante entre los repositorios de servicios que ofrecen la descripción de los
servicios disponibles; PEEM para las políticas específicas de servicios y usuarios;
OSS y BSS para, por ejemplo, el aprovisionamiento, la supervisión de servicios
específicos o la activación de servicios; y los habilitadores de aplicaciones o
servicios.
Como principal motor de orquestación de servicios de un SDP basado en SOA, el
corredor de servicios debe ser capaz de:

• Orquestación de servicios: los habilitadores pueden encadenarse en

patrones predefinidos y ejecutarse mediante "guiones de orquestación", que
son una política compleja almacenada en PEEM, o utilizar lenguajes de
descripción de procesos para aplicar varias políticas a diferentes
habilitadores.
• Encadenamiento de servicios: se pueden encadenar varios habilitadores
para definir un nuevo habilitador de servicios más complejo.

En este sentido, los habilitadores amplían la noción de habilitadores de aplicaciones

que ofrecen las API de exposición, como Parlay X, y abarcan todos los servicios
conectados al bus de servicios empresariales (ESB). Esto ofrece la posibilidad de
mapear un ciclo de vida de servicio completo como un script de orquestación. El
lenguaje de orquestación elegido para nuestra arquitectura es WSBPEL 2.0. Sin
embargo, existen otras especificaciones de orquestación prometedoras, como la interfaz
coreográfica de servicios Web (WSCI) [29] estandarizada por el W3C, que es un
lenguaje de descripción de interfaces basado en XML que describe el flujo de mensajes
intercambiados por un servicio Web que interactúa con otros servicios Web. Además, el
lenguaje de modelado de procesos de negocio (BPML) ha sido propuesto por la
organización BPMI (Busi- ness Process Management Initiative), pero BPMI [30] dejó
de apoyarlo en favor de BPEL y se unió al OMG en 2005.
322 Manual del subsistema multimedia fP (fM£)

Integración de operaciones y sistemas de apoyo a la empresa

New Generation Operations Software and Systems (NGOSS) es un programa de
trabajo regido por el TeleManagement Forum (TMF) para ofrecer un marco de
trabajo que facilite la integración de los sistemas de apoyo a las operaciones y al
negocio en servicios basados en SOA. El objetivo de NGOSS es facilitar el rápido
desarrollo de soluciones OSS/BSS flexibles y de bajo coste de propiedad para
satisfacer las necesidades empresariales de la economía basada en Internet [31].
NGOSS se basa en los cinco principios siguientes:

Separación del proceso empresarial de la implementación de componentes. NGOSS

propone que los futuros procesos de OSS se gestionen como parte de la
infraestructura de servicios centralizada, utilizando un motor de flujo de
trabajo responsable de controlar los procesos empresariales entre las
aplicaciones. Por lo tanto, el motor de flujo de trabajo iniciaría un proceso
para una aplicación, que devolvería el control al motor de flujo de trabajo,
que a su vez llamaría a otra aplicación, y así sucesivamente. De este modo,
siempre es posible conocer el estado de los procesos individuales como
parte del flujo.
Sistema distribuido débilmente acoplado. Por "débilmente acoplado" se
entiende que cada aplicación es relativamente independiente de las demás
aplicaciones del sistema global. Por lo tanto, en un entorno poco acoplado,
una aplicación puede alterarse sin que la alteración afecte necesariamente a
las demás. Esto puede verse como la capacidad de "conectar y usar"
aplicaciones, donde son tan independientes que pueden cambiarse sin
afectar al comportamiento global del sistema. Este sistema distribuido hace
hincapié en que NGOSS no se implementa utilizando una única aplicación
monolítica para gestionar todas sus actividades, sino que utiliza un
conjunto de aplicaciones integradas y cooperativas que ofrecen API o
interfaces de protocolo bien definidas.
Modelo de información compartida. Esto implica la integración de OSS, pero
también, para las arquitecturas orientadas a servicios en general, significa
que los datos deben ser compartidos entre las aplicaciones. Para que esto
sea efectivo, o bien cada aplicación debe entender cómo cada otra
aplicación entiende/interpreta la parte de los datos que se comparte, o bien
debe haber un modelo común de los datos compartidos. Un único modelo
de información para los datos compartidos entre aplicaciones ofrece una
solución a este problema. La solución de la TMF se denomina modelo de
información/datos compartidos (SID) [32].
Infraestructura común de comunicaciones. NGOSS describe el uso de una
infraestructura común de comunicaciones (CCI). En este modelo, los OSS
interactúan con la CCI en lugar de hacerlo directamente sí. La CCI permite
que las aplicaciones trabajen juntas, ya que proporciona un canal de
comunicación común. De este modo, cada aplicación sólo necesita una
interfaz (con la CCI) en lugar de muchas (con otras ). El sitio
La integración de la gestión financiera en las plataformas de 323
prestación de servicios

CCI también puede prestar otros servicios, como seguridad, transmisión de

datos, etc.
Interfaces definidas por contrato. Dada la descripción anterior de cómo las
aplicaciones interactúan con la CCI, es obvio que se necesita una forma de
documentar esas interfaces en términos de la tecnología empleada (por
ejemplo, Java/JMS o servicios Web/SOAP) y también la funcionalidad de
la aplicación, los datos utilizados, las condiciones previas y posteriores, etc.
Las interfaces definidas por contrato de NGOSS proporcionan un medio
para documentar estas interfaces. Los contratos NGOSS pueden
considerarse extensiones de las especificaciones API. NGOSS se centra en
el uso de tecnologías de la información comerciales, en lugar de
tecnologías exclusivas del sector de las telecomunicaciones, como han
hecho en el pasado muchos sistemas de gestión heredados. Este enfoque
reduce significativamente los costes y mejora la reutilización del software y
la flexibilidad operativa, lo que permite a los sistemas basados en NGOSS
soportar una gama de nuevos servicios y nuevos entornos tecnológicos con
mayor facilidad. NGOSS hace hincapié en un enfoque orientado a los
servicios basado en la integración de contratos de colaboración bien
definidos.

Exposición de servicios para mash-ups basados en la web

Con el actual proceso de convergencia de las redes de acceso y aparición de nuevos
actores en el mercado de las telecomunicaciones, los operadores tradicionales
buscan nuevos modelos de negocio para aumentar sus ingresos. La reutilización de
un conjunto extensible de componentes de servicio existentes para crear
rápidamente nuevas aplicaciones impulsadas por el mercado ha sido un aspecto
clave de las plataformas de telecomunicaciones durante muchos años y cobra un
nuevo impulso con la definición de habilitadores de aplicaciones dedicados para las
NGN. Un ejemplo real es la solución BT Web21C SDK [33] de British Telecom,
que define una API para exponer funcionalidades específicas de la red central de
telecomunicaciones, como el envío/recepción de SMS o llamadas de voz y
funciones de conferencia, a desarrolladores de servicios de terceros que utilicen
servicios web. Los mash-ups se convirtieron en el sinónimo favorito para crear
aplicaciones en la Web 2.0 haciendo uso de servicios de terceros ya existentes. El
requisito clave para este tipo de integraciones es la apertura y accesibilidad de las
interfaces de programación de los servicios. La figura 13.7 muestra una posible
arquitectura mash-up de habilitadores de terceros basados en la Web y habilitadores
de tele-comunicaciones.
Utilizando un SDP basado en SOA que incorpore un API habilitador junto con
una función de exposición dedicada que proporcione control sobre el acceso al
servicio, como la función OMA PEEM anteriormente descrita, un operador de red
de telecomunicaciones está en posición de exponer su funcionalidad de red y de
aplicación de forma flexible. Además, el operador puede proporcionar un valor
añadido único a las aplicaciones de terceros mediante la definición de su propio
habilitador web.
324 Manual del subsistema multimedia fP (fM£)

Tele Atlas Google

Fuentes Mapas
cartográficas

Parlay X Web
AS Servido
r

Navegador web

Presencia Parlay X
Servidor Pasarela

HSS

I-CSCF S-CSCF

P-CSCF
SIP
Diameter HTTP/RSS
RPC/API
Servicios web/Parlay X

FIGURA 13.7
Mash-up entre telecomunicaciones y habilitadores web.

Web 2.0 para las telecomunicaciones

Los operadores que han implementado una capa habilitadora como parte de su
estrategia SDP son capaces de combinar dicha abstracción de red con un entorno
basado en OMA PEEM para ofrecer estos habilitadores a cualquier desarrollador en
Internet. No obstante, la mayoría de los desarrolladores Web de alto nivel están
acostumbrados a paradigmas de programación y estructuras de datos diferentes a los
que ofrecen, por ejemplo, las API Parlay X. Por lo tanto, podría ser necesario
proporcionar interfaces o habilitadores específicos para atender las necesidades de
los programadores de aplicaciones Web. Llamamos a estas interfaces Telco Web 2.0
Enabler, y consisten en
La integración de la gestión financiera en las plataformas de 325
prestación de servicios

de API Javascript que pueden incorporarse fácilmente a aplicaciones web basadas

en Ajax (Javascript asíncrono y XML).
Llamar a un servicio Web desde una aplicación Ajax está restringido a servicios
Web locales, debido a la política del mismo origen aplicada por los navegadores
Web modernos. Sin embargo, los servicios Web están acostumbrados a ser
consumidos más allá de los límites del servidor en puntos finales externos. Para
llamar a servicios Web externos desde Javascript, la solicitud de servicio debe
dirigirse a través de una pasarela que puede ofrecer un operador. Esta pasarela
proporciona una interfaz para el del lado del cliente, asignándolo a la interfaz
particular del servicio web externo. Así, todos los parámetros de una petición Ajax
entrante se pasan al punto final del servicio Web (por ejemplo, los habilitadores Parlay X).
El cliente Javascript accede a un único servidor como de costumbre, pero el servidor
puede llamar a servicios Web de forma remota.
Normalmente se accede a los servicios web a través de mensajes SOAP que son
difíciles de manejar con Javascript. La utilización de una pasarela permite sustituir
SOAP por cualquier protocolo, ya que éste puede traducirse dentro de la pasarela. De
este modo, se pueden utilizar formatos de descripción de datos más cómodos, como
la notación de objetos de Javascript (JSON) y XML simple, para facilitar el acceso a
los servicios web. Además, el acceso a los servicios web puede simplificarse
mediante la abstracción de la interfaz real de los servicios web. Por lo tanto, la
lógica de negocio subyacente de los servicios web puede ocultarse al desarrollador
de Javascript y la funcionalidad ofrecida puede ampliarse en el lado del servidor.
Por ejemplo, una llamada a un método Javascript desde una aplicación Web Ajax
podría iniciar una aplicación orquestada en
el PDE del operador.

Habilitador de identidad
El mundo de Internet está adoptando rápidamente posibilidades para representar
identidades digitales. (Un ejemplo es OpenID [34], que procede de la blogosfera,
donde ayudó a simplificar la autenticación de las entradas de blog, y que no deja de
crecer en un proceso de integración de base con otras soluciones de identidad o las
tarjetas de información de Microsoft. Éstas pueden utilizarse hoy en día con muchos
ordenadores mediante el selector de identidad CardSpace [35] y admiten explícitamente
la autentica- ción en un proveedor de identidad a través de tarjetas inteligentes). Ahora,
los operadores de telecomunicaciones empiezan a estudiar las posibilidades de
convertirse ellos mismos en proveedores de identidad.
Los proveedores de identidad emiten identidades digitales para sus usuarios;
debido al nivel de confianza que los usuarios deben tener en ellos (por ejemplo,
llegarán a saber a qué sitios web acceden los usuarios) y a los diferentes atributos
por los que responderán, hay muchos proveedores de identidad posibles. Por
ejemplo, las empresas pueden expedir identidades a sus clientes, los gobiernos
pueden avalar las identidades de sus ciudadanos o los emisores de tarjetas de crédito
pueden proporcionar identidades que permitan el pago. Además, los particulares
pueden utilizar identidades autoemitidas (que no son sensibles y no necesitan el
respaldo de otra autoridad) para conectarse a sitios web. El objetivo es establecer
una representación digital de las tarjetas que pueden encontrarse en las carteras de
los usuarios hoy en día y más allá para proporcionar datos verificados como la edad,
la solvencia o la ubicación.
326 Manual del subsistema multimedia fP (fM£)

Las telecos están en muy buena posición para convertirse ellas mismas en
proveedoras de identidad para soluciones centradas en el usuario, ya que se han
ocupado de la gestión de identidades a gran escala. Ya cuentan con la confianza de
los usuarios para no alterar su privacidad, y la arquitectura de arranque genérico
3GPP ofrece una opción segura para autenticar mutuamente a los usuarios y la red.
Aunque GBA también puede utilizarse para afirmar identidades para servicios
alojados en el propio operador, habrá muchos casos en los que un usuario pueda
reutilizar esa información de iden- tidad afirmada para presentarla a proveedores de
servicios de Internet (por ejemplo, para crear entradas de blog o pedidos en línea) de
forma sencilla desde un dispositivo móvil.

Conclusiones
Los principios de SOA llevan muchos años utilizándose en el ámbito de las
telecomunicaciones, aunque en las últimas décadas se han empleado distintos
términos para describir la idea de crear una red programable que ofrezca un mercado
abierto de servicios. En la actualidad, las API basadas en servicios web, incluidas las
interfaces Web 2.0 emergentes, representan el estado del arte de las
telecomunicaciones basadas en SOA, que van a integrarse con el IMS emergente.
Sin embargo, aún queda mucho por investigar y desarrollar en este campo, ya que el
reto consiste en ofrecer un entorno de servicios seguro y determinista, y no sólo el
entorno de servicios de mejor esfuerzo que conocemos hoy de Internet.
El Open SOA Telco Playground [36] es la extensión hacia el norte del FOKUS
Open IMS Playground [37] fundado en 2004. El IMS se considera hoy en día el
marco arquitectónico unificador para la provisión de servicios basados en IP sin
costuras sobre redes convergentes y la base hacia el sur para muchas plataformas de
prestación de servicios; por lo tanto, el Open SOA Telco Playground ofrece la
posibilidad de experimentar una arquitectura orientada a servicios sobre redes
convergentes. Sin embargo, esta zona de juegos independiente del proveedor no sólo
se limita a las redes de próxima generación, sino que también admite la prestación
de servicios sobre redes de telecomunicaciones fijas y móviles heredadas, así como
sobre Internet de próxima generación.
El principal objetivo de Open SOA Telco Playground es proporcionar capacidades
de servicio orientadas a las telecomunicaciones basadas en los principios SOA más
avanzados a un conjunto abierto de dominios empresariales. Este parque tecnológico
independiente de vendedores y proveedores representa un banco de pruebas abierto
para investigar, experimentar y validar el desarrollo, la orquestación, el
aprovisionamiento, la ejecución y la gestión de redes convergentes de próxima
generación y futuras aplicaciones de Internet basadas en principios SOA.
El Open SOA Telco Playground es proporcionado por el Departamento de
Infraestructuras de Red de Nueva Generación del Instituto Fraunhofer FOKUS y es
un componente integral del Laboratorio FOKUS SOA.
La integración de la gestión financiera en las plataformas de 322
prestación de servicios

Referencias
1. Newcomer, E., y G. Lomow. 2005. Understanding SOA with Web services. Read- ing, MA:
Addison Wesley.
2. Channabasavaiah, K., K. Holley y E. Tuggle, Jr. 2003. Migración a una arquitectura
orientada a servicios. IBM DeveloperWorks, [Link]
com/developerworks/library/ws-migratesoa/
3. W3C. Lenguaje de descripción de servicios web (WSDL) 1.1, [Link]
org/TR/wsdl
4. Arquitectura orientada a servicios. 2008. [Link]
arquitectura_orientada
5. 3GPP, TS 23.228 V7.6.0. 2006. Proyecto de asociación de tercera generación. Technical
specification group services and system aspects. Subsistema multimedia IP (IMS); etapa 2
(versión 7).
6. ETSI TISPAN WG. [Link]
7. Definición de liberación de habilitadores para IMS en OMA, Open Mobile Alliance. 2005.
OMA-ERELD-IMSinOMA-V1_0-20050809-A.
8. Schulzrinne, H. et al. 2002. RFC 3261 SIP: Protocolo de iniciación de sesión.
9. 3GPP, TS 23.218 V7.8.0. 2007. IP multimedia (IM) session handling; IM call model;
stage 2 (release 7).
10. 3GPP, TS 24.228 V5.15.0. 2006. Flujos de señalización para el control de llamadas
multimedios IP basados en el protocolo de iniciación de sesión (SIP) y el protocolo de
descripción de sesión (SDP); etapa 3.
11. Calhoun, P. et al. 2003. IETF RFC 3588 Protocolo base DIAMETER.
12. Hakala, H. et al. 2007. RFC 4006 Aplicación de control de crédito DIAMETER.
13. 3GPP, TS 23.002 V7.4.0. 2007. Arquitectura de red.
14. Proceso de la Comunidad Java. 2008. JSR 289: SIP Servlet v1.1.
15. Alianza Móvil Abierta (OMA). 2007. Enabler release definition for push-to-talk over
cellular. Versión candidata 2.0.
16. Schulzrinne, H. et al. 2003. IETF RFC 3550 RTP: Un protocolo de transporte para
aplicaciones en tiempo real.
17. Alianza Móvil Abierta (OMA). 2006. Documento de arquitectura Presence SIMPLE.
Versión aprobada 1.0.1.
18. Alianza Móvil Abierta (OMA). 2007. Arquitectura de gestión de documentos XML.
Versión candidata 2.0.
19. Rosenberg, J. 2007. IETF RFC 4825. The extensible markup language (XML) con-
figuration access protocol (XCAP).
20. 3GPP, TS 33.220 V7.10.0. 2007. Arquitectura de autenticación genérica (GAA);
arquitectura de arranque genérica.
21. Niemi, A. et al. 2002. IETF RFC 3310. Hypertext transfer protocol (HTTP) digest
authentication using authentication and key agreement (AKA).
22. W3C. SOAP versión 1.2 Parte 1: Marco de mensajería. [Link] org/TR/SOAP
23. Alianza Móvil Abierta (OMA). 2007. Entorno de servicio OMA. Approved ver- sion 1.0.4.
24. Short message peer-to-peer protocol specification v5.0. 2003.
25. 3GPP, TS 23.140 V6.14.0. 2006. Servicio de mensajería multimedia (MMS); descripción
funcional; etapa 2.
328 Manual del subsistema multimedia fP (fM£)

26. Schulzrinne, H. et al. 2007. RFC 4745 Política común: Un formato de documento para
expresar preferencias de privacidad.
27. OASIS Web services lenguaje de ejecución de procesos de negocio versión 2.0. 2007.
[Link]
28. COM: tecnologías del modelo de objetos componentes, [Link]
com/[Link]
29. W3C. Web service choreography interface (WSCI) 1.0, [Link] org/TR/wsci
30. Iniciativa de gestión de procesos empresariales. [Link]
31. Foro TeleManagement. 2004. Ciclo de vida y metodología de las NGOSS.
32. Foro de telegestión. 2008. NGOSS SID, [Link]
calPrograms/NGOSSSID/1684/[Link]
33. BT Web21C SDK. [Link]
34. OpenID. [Link]
35. Chappell, D. Presentación de Windows CardSpace. [Link] en-
us/library/[Link]
36. FOKUS Open SOA Telco Playground. [Link]
37. Parque infantil FOKUS IMS. [Link]
14
Orquestación de servicios en fM£

Anahita Gouya y Noël Crespi

CONTENIDO
Introducción ....................................................................................................................... 329
Gestión de conflictos de servicio en IMS ...................................................................... 330
Ejemplo de conflicto de servicio................................................................................ 331
Gestión de conflictos en los servicios ..................................................................... 331
Trabajos relacionados.............................................................................................. 332
Evitación de conflictos en los servicios: Negociación de servicios............... 332
Servicio Evitación de Conflictos: Descripción del servicio ...................... 333
Evitación de conflictos en los servicios: Modelos formales ......................... 333
Detección y resolución de conflictos de servicio: Fuera de línea ............. 334
Requisitos de IMS para la gestión de conflictos de servicio ................................. 335
Gestión de la composición de servicios en IMS ........................................................... 336
Ejemplos de composición de servicios ................................................................... 337
Gestión de la composición de servicios .................................................................. 338
Trabajos relacionados.............................................................................................. 338
Solución de gestión de la composición de servicios basada en OMA ..... 338
Gestión de la composición de servicios basada en OSA/Parlay
Solución ....................................................................................... 339
Gestión de la composición de servicios basada en ontologías
Soluciones .................................................................................... 339
Gestor de Interacción de Capacidades de Servicio (SCIM) ................. 340
Requisitos de IMS para la gestión de la composición de servicios ....................... 340
Conclusión ........................................................................................................................... 342
Referencias .......................................................................................................................... 343

Introducción
Durante la última década, la Unión Internacional de Telecomunicaciones-Sector de
Normalización de las Telecomunicaciones (UIT-T) dedicó especial interés a
identificar los requisitos de la red de próxima generación (NGN). Junto a estos , el
Proyecto de Asociación de Tercera Generación (3GPP) definió
329
330 Manual del subsistema multimedia fP (fM£)

una superposición de control de servicios totalmente IP, denominada subsistema

multimedia IP (IMS) [1], como instanciación de la NGN. El 3GPP adoptó el
protocolo de inicio de sesión (SIP) [2] como protocolo de señalización IMS para
gestionar el establecimiento de sesiones de extremo a extremo entre usuarios. El
IMS es una arquitectura genérica para ofrecer servicios multimedia y permite la
convergencia de redes y servicios en una única plataforma de servicios. En 2004, el
grupo de Protocolos y Servicios Convergentes de Telecomunicaciones e Internet
para Redes Avanzadas (ETSI TISPAN) del Instituto Europeo de Normas de
Telecomunicación (ETSI) empezó a hacer aportaciones al modelo NGN del UIT-T
para migrar las redes de conmutación de circuitos heredadas a las NGN
aprovechando el IMS del 3GPP en los sistemas cableados. Estas evoluciones son las
principales fuerzas motrices para que los operadores de redes avancen hacia la
implantación e integración de las NGN en sus plataformas.
Aunque las NGN aportan nuevas prestaciones a los servicios de telecomunicaciones
y redes, se enfrenta a una serie de insuficiencias. En este capítulo, nos centramos en
la cuestión de la gestión de la interacción de servicios como principal obstáculo para
la orquestación de servicios en el IMS. La orquestación de servicios es un medio de
controlar la interacción consecutiva entre servicios. Aunque varias funcionalidades
para el establecimiento de sesiones en el IMS están bien definidas, siguen existiendo
importantes retos para soportar la orquestación de servicios. Estos retos son dos: la
gestión de las interacciones negativas, que acaban en conflictos entre servicios, y la
gestión de las interacciones positivas, que permiten la composición de servicios.
La contribución de este capítulo es investigar los problemas de conflicto de
servicios y composición de servicios en el IMS, discutiendo los requisitos,
principios y retos correspondientes. En la siguiente sección, presentamos la
necesidad de un mecanismo de gestión de conflictos de servicios en el IMS y
repasamos los trabajos de investigación relacionados con este tema. Basándonos en
las carencias de estas propuestas, exponemos las directrices clave para diseñar un
mecanismo de gestión de conflictos de servicios en IMS. Asimismo, en la sección
"Gestión de la composición de servicios en el IMS", exploramos la cuestión de la
gestión de la composición de servicios. Tras ofrecer una visión de los trabajos
relacionados, se discuten las limitaciones de estas soluciones y se citan los
principales aspectos de un gestor de composición de servicios en el IMS. En la
conclusión de este capítulo, se discuten las perspectivas de los temas desarrollados y
se proponen varias pistas para los futuros trabajos de investigación en el ámbito de
la arquitectura de servicios de las NGN.

Gestión de conflictos de servicio en IMS

Los servicios de telefonía IP pueden enfrentarse al problema de conflicto de
servicios que se daba en las redes de telefonía tradicionales, denominado problema de
interacción de características. Este problema se produce cuando los servicios (o
características) invocados durante una sesión se comportan correctamente cuando se
procesan por separado e independientemente unos de otros, pero no
Orquestación de servicios en fM£ 331

cuando funcionan juntos. "Característica" se refiere aquí a una unidad de servicio

independiente que una red proporciona a sus abonados para enriquecer y
personalizar los servicios ofrecidos.
La restricción de llamadas, el desvío incondicional de llamadas y el filtrado de
llamadas de origen son algunas de las funciones de control de llamadas más
conocidas, con las siguientes definiciones:

La restricción de llamadas limita todas las llamadas salientes a los destinos

prohibidos definidos por la red.
El desvío de llamadas incondicional desvía todas las llamadas entrantes a otro
destino definido por el usuario.
El filtrado de llamadas de origen bloquea todas las llamadas salientes a los
destinos que están en la lista negra de la persona que llama.

Aunque se ha investigado mucho sobre la gestión de los conflictos entre servicios, la

aplicación de estas soluciones en el IMS sigue siendo un reto y es necesario seguir
investigando.

Ejemplo de conflicto de servicio

En el siguiente escenario, ilustrado en la Figura 14.1, se produce un conflicto de
servicios entre los servicios del llamante y el llamado:

Supongamos que Alicia quiere establecer una videollamada con Bob. Alice
dispone de un servicio de filtrado de llamadas de origen que bloquea todas las
salientes a usuarios finales que estén en la lista negra. Por otro lado, Bob tiene un
servicio de desvío de llamadas incondicional que envía todas las llamadas
entrantes a Ana. ¿Qué ocurre si Ana está en la lista negra de Alicia? En este , se
produce el siguiente conflicto entre el servicio de filtrado de llamadas de origen
de Alice y el servicio incondicional de desvío de llamadas de Bob: Si el servicio
de filtrado de llamadas de origen funciona correctamente tal y como se ha
definido para Alice, el servicio incondicional de desvío de llamadas quedará
desatendido. En caso contrario, si el servicio incondicional de desvío de llamadas
se comporta como está definido para Bob, entonces se ignorará el servicio de
filtrado de llamadas de origen de Alice.

Gestión de conflictos en los servicios

La gestión de los conflictos de servicio consiste en prevenirlos siempre que sea
posible o en y resolverlos. La prevención de conflictos de servicio consigue
imponiendo las restricciones necesarias a la plataforma de servicios y a los usuarios.
Estas restricciones se refieren principalmente a configuraciones de servicio extrañas,
imprecisión en las características del servicio, mala asignación de recursos, errores
de programación de aplicaciones de software y falta de interoperabilidad entre
sistemas de telecomunicación heterogéneos. Sin embargo, aunque las plataformas de
servicios y los usuarios finales respeten estas restricciones, es probable que se
produzcan conflictos de servicio.
En la literatura se consideran dos métodos para detectar y resolver conflictos de
servicio: offline y online. Varios conflictos de servicio pueden
332 Manual del subsistema multimedia fP (fM£)

2. Verificación de que 5. Reenvío

Alice todas las llamadas
no está llamando a entrantes a Anne.
Anne. Verificación: OK

Llamada de origen Desvío de

Proyección llamadas
Incondicional

1 3 4 6

Alice Ana Bob

FIGURA 14.1
Ejemplo de conflicto de servicio.

detectarse y resolverse antes de que se invoquen los servicios. Este mecanismo de

gestión se denomina offline. Sin embargo, debido al comportamiento impredecible
de los servicios, así como a la gran introducción de nuevos servicios, no todos los
conflictos de servicio pueden detectarse y resolverse fuera de línea. En otras
palabras, algunos conflictos se producen durante el tiempo de ejecución del servicio
y, por consiguiente, deben gestionarse en ese momento, es decir, en línea. Además,
denominamos "estático" a un mecanismo de detección y resolución de conflictos de
servicio si se basa en la información predecible y predefinida del servicio. Por otro
lado, los mecanismos de gestión basados en información de servicio en tiempo real
se denominan "dinámicos". En las secciones siguientes, presentamos una revisión
exhaustiva de los trabajos relacionados con este tema.

Trabajos relacionados
Los estudios de Keck y Kuehn [3] y Calder et al. [4] ofrecen una visión global del
trabajo realizado en este campo durante la década de 1990. El trabajo de Cameron et
al. [5] clasifica las causas de las interacciones de características (violación de las
suposiciones de características, limitaciones en el soporte de red y problemas en los
sistemas distribuidos como condiciones de tiempo y carrera) y presenta dos
enfoques generales para gestionar los conflictos de servicio: (1) evitar los con-
flictos mejorando la arquitectura de servicio y (2) dotar a la arquitectura de servicio
de métodos específicos de detección y resolución de conflictos de servicio.

Evitación de conflictos en los servicios: Negociación de servicios

Kolberg y Magill [6] proponen un mecanismo para evitar conflictos de servicio
basado en SIP en el que los usuarios finales negocian sus servicios disponibles antes
de la sesión.
Orquestación de servicios en fM£ 333

se establece la comunicación. Para conseguir esta , el llamante amplía la petición

INVITE, dirigida al destinatario, añadiendo a la petición una lista de sus servicios
así como las posibles acciones que el destinatario podría realizar si éste no está de
acuerdo con la lista de servicios indicada. Posteriormente, el destinatario puede
aceptar la llamada o seleccionar una de las acciones ofrecidas. También es posible
que el destinatario perfeccione algunas de las acciones propuestas y sugiera otras
nuevas a la persona que llama. A continuación, la persona que llama decidirá cuál de
las opciones es preferible. Esta negociación continúa hasta que el llamante y el
receptor se ponen de acuerdo sobre los servicios y las opciones correspondientes.
Este mecanismo garantiza que la sesión establecida entre los usuarios finales no se
encontrará con el problema del conflicto de servicios. Sin embargo, la principal
desventaja de esta propuesta es la falta de transparencia para las partes finales, ya
que deben participar en el proceso de gestión de conflictos de servicio. Además, las
partes finales deben confiar las unas en las otras durante el procedimiento de
negociación; de lo contrario, la negociación es vulnerable a muchos ataques, como
la usurpación de identidad o la denegación de servicio (un "hombre en el medio"
puede responder a la solicitud de invitación con una lista de servicios no válida,
provocando el fracaso de la negociación del servicio). Por último, esta propuesta
requiere que las partes finales acuerden una plantilla de negociación de servicios
para comprender el vocabulario de negociación utilizado.

Servicio Evitación de Conflictos: Descripción del servicio

Harada, Fujiwara y Ohta [7] proponen un método para evitar conflictos de servicio
basado en tablas de conflictos de servicio predefinidas que contienen una
descripción de los servicios. Estas especificaciones de servicios se envían a los terminales.
Por lo tanto, pueden producirse conflictos de servicio debido a la combinación de dos
especificaciones de servicio. Las combinaciones se almacenan en tablas que utilizan
diagramas de transacciones de estado para describir los posibles conflictos de
servicio, así como los mecanismos para evitarlos.
La aplicación experimental y la evaluación de esta propuesta confirman su
eficacia en términos de tiempo de proceso para evitar conflictos. Pero esta
proposición puede no ser flexible cuando se introducen nuevos servicios. De hecho,
las tablas de conflictos de servicios deben actualizarse periódicamente, y ponerlas al
día requiere esfuerzos adicionales por parte del método de evitación de conflictos de
servicios propuesto.

Evitación de conflictos en los servicios: Modelos formales

Chan y Bochmann [8] proporcionan un modelo formal de servicios SIP y conflictos
de servicio, utilizando un lenguaje de especificación y diseño (SDL) que cubre
algunas de las características importantes de los mensajes SIP, como el identificador
de llamada, los campos de cabecera de direccionamiento y el número de secuencia.
En esta propuesta, se discuten las siguientes estrategias de prevención de conflictos
de servicio: prevención de la contención y limitación de recursos, prevención de
interacciones incoherentes, prevención de nondeterminismo inesperado e
interacciones injustas, y prevención de inter-acciones de bloqueo (debido al
despliegue mutuo de servicios).
334 Manual del subsistema multimedia fP (fM£)

Mediante las clasificaciones de conflictos de servicio propuestas y las estrategias

de prevención de conflictos correspondientes, se supone que disminuirá el número
de posibles conflictos de servicio. Sin embargo, estas propuestas se enfrentan a
limitaciones en cuanto a la cuantificación de las instancias de conflicto de servicio y
sus comportamientos. Además, los modelos propuestos deben actualizarse
periódicamente para gestionar los conflictos que puedan surgir al introducirse
nuevos servicios.

Detección y resolución de conflictos de servicio: Fuera de línea

Chentouf, Cherkaoui y Khoumsi [9] proponen un método de detección y resolución
de conflictos de servicio que integra un agente gestor de interacción de funciones
(FIM) entre los usuarios finales y los proxies SIP. En esta propuesta, los usuarios
informan al FIM sobre su intención de ejecutar un servicio. A continuación, el FIM
pone en marcha el procedimiento de detección para verificar si este servicio
interactuará con los que ya se están ejecutando y que pertenecen a la misma sesión.
Si se detecta un conflicto, la FIM ordena al proxy que detenga el procesamiento de
la llamada y lanza el procedimiento de reso- lución.
Khoumsi [10] presenta un modelo formal basado en máquinas de estados finitos
para especificar los servicios y una metodología para detectar y resolver el conflicto
de servicios basándose en casos de conflicto predefinidos. En esta propuesta, los
conflictos de servicio se definen como estados indeseables de una máquina de
estados finitos. En cuanto al método de resolución, este modelo fuerza a los estados
indeseables a comportarse de forma aceptable.
Jouve, Gall y Coudert [11] presentan los servicios de telecomunicaciones en forma
de especificaciones operativas y definen un método para calcular la activación de
servicios y los posibles conflictos. Además, este trabajo propone un mecanismo para
adaptar estas especificaciones de servicio y métodos detección de conflictos a los
servicios basados en SIP.
Crespo, Carvalho y Logrippo [12] proponen un mecanismo distribuido de
resolución de conflictos para aplicaciones de Internet. En esta propuesta, se diseña
un asesor de resolución de interacciones que contiene la lista de servicios y los
conflictos potenciales que pueden ocurrir entre ellos. Cuando una aplicación
identifica varios servicios que pueden ejecutarse simultáneamente, la lista de estos
servicios se envía al asesor. Éste selecciona posteriormente los servicios a ejecutar
en base a políticas expresadas por conjuntos de fórmulas lógicas (a través de la
respuesta Advice) y la devuelve a la aplicación.
Kolberg y Magill [13] proponen un enfoque fuera de línea para describir los
servicios y definir las reglas para detectar los escenarios de conflicto de servicios. El
procedimiento de detección consiste en comparar las especificaciones de un servicio
con todas las variaciones de la especificación de otro servicio. Kolberg y Magill [14]
siguen este enfoque y proponen un mecanismo distribuido de detección y resolución
de conflictos de servicio que es aplicable a los servicios basados en SIP. En esta
propuesta, el comportamiento de los servicios se describe mediante una cabecera
SIP extendida. El servicio activado incluye esta cabecera SIP en el mensaje SIP. A
continuación, el siguiente servicio invocado compara los pares de los servicios
invocados para averiguar los conflictos. Esta comparación se basa en la
Orquestación de servicios en fM£ 335

reglas de detección de conflictos. Una vez detectado un conflicto, el algoritmo de

resolución predefinido decide sobre la desactivación de un servicio para resolver el
conflicto producido.
El principal inconveniente de estas propuestas es que se limitan a soluciones de
gestión de conflictos de servicios fuera de línea, y no pueden gestionarse los
conflictos que se producen en tiempo de ejecución del servicio.

Requisitos IMS para la gestión de conflictos de servicio

Por lo que sabemos, no se ha investigado lo suficiente sobre la gestión de conflictos
de servicio en el IMS. Sin embargo, como plano de control de servicios todo IP
líder, el IMS necesita una mayor consideración en este ámbito. Basándonos en las
lecciones aprendidas de trabajos anteriores, definimos los siguientes requisitos para
introducir un mecanismo de gestión de conflictos de servicios en el IMS:

• Adaptabilidad al IMS mediante mecanismos basados en SIP. Dado que los

conflictos de servicio se producen durante la invocación de servicios en el
IMS y que los mecanismos de establecimiento de sesión e invocación de
servicios del IMS se basan en SIP, cualquier solución para los conflictos de
servicio debe basarse en SIP. Además, la naturaleza basada en SIP de dicha
solución le proporcionará mecanismos extensibles para integrar nuevos
servicios y los aspectos relevantes de la gestión de conflictos de servicio.
• Transparencia para las partes finales. En lugar de proporcionar a las partes
finales mecanismos para resolver los conflictos de servicio, este
mecanismo debería incluirse en el núcleo del SGI. La ventaja de este
enfoque radica principalmente en la flexibilidad del IMS para realizar
modificaciones funcionales sin involucrar a las partes finales en este
procedimiento.
• Eficiencia sin un impacto considerable en el tiempo de establecimiento de la
sesión. Dado que el mecanismo de gestión de conflictos de servicio
interviene durante la fase de establecimiento de sesión, debe respetar las
restricciones en tiempo real de las sesiones SIP.

Para cumplir estos requisitos, tal y como se ilustra en la Figura 14.2, los estándares
IMS deberían incluir las siguientes mejoras funcionales:

• Introducir una entidad funcional para orquestar las invocaciones de servicio

y detectar y resolver los conflictos de servicio. Esta entidad funcional
puede definirse como un intermediario de servicios que intercepta los
mensajes intercambiados entre una S-CSCF en la capa de control de sesión
y un servidor de aplicaciones en la capa de servicio.
• Definir un procedimiento de detección y resolución de conflictos de
servicio basado en SIP en el corredor de servicios que, basándose en
información estática o dinámica, se ajuste a los requisitos definidos y
gestione los conflictos de servicio tanto offline como online.
336 Manual del subsistema multimedia fP (fM£)

S-CSCF Corredor de Servidor de

servicios aplicaciones

1) Evaluación iFC
2) Antes de la invocación del servidor
de aplicaciones, la solicitud debe ser
enrutada automáticamente al Service
Broker relacionado de la S-CSCF.

Offline Servicio
Gestión de conflictos

Servicio
Ejecución

Servicio en línea
Gestión de conflictos

FIGURA 14.2
Corredor de servicios para la gestión de conflictos de servicios en el IMS.

En el 3GPP se está llevando a cabo un esfuerzo de estandarización para definir la

arquitectura del intermediario de servicios y los procedimientos asociados [15].
Sin embargo, el progreso de este punto de trabajo ha sido lento y las discusiones
están todavía a un nivel muy alto. En la versión 8 del 3GPP sólo se
estandarizarán los principios básicos; la mayor parte del trabajo de especificación
se realizará en la versión 9.

Gestión de la composición de servicios en IMS

El 3GPP y el grupo de trabajo NGN de TISPAN siguen un enfoque modular para
definir los bloques de construcción de servicios independientes y autónomos,
denominados capacidades de servicio. Gracias a este modular, el IMS proporciona
capacidades de servicio que pueden ser utilizadas de forma independiente o
reutilizadas por distintos servidores de aplicaciones. Permitir esta interoperabilidad
y cooperación entre diferentes servicios permite enriquecer y personalizar los
servidores de aplicaciones basándose en las necesidades, preferencias y contextos
del usuario proporcionados por las capacidades de servicio. Además, esta
cooperación evita el solapamiento y la redundancia de las mismas funcionalidades
ofrecidas por las capacidades de servicio e implementadas por diferentes servidores
de aplicaciones. Por último, el mecanismo de composición reduce el tiempo de
comercialización de los servicios. Este concepto debería facilitar y abaratar la
integración y el despliegue de servidores de aplicaciones. Es especialmente
interesante que el IMS facilite este interfuncionamiento a nivel de servicio.
Orquestación de servicios en fM£ 332

Servidor de Servidor de Servidor de

videoconferencias e- mensajería
multipartito learning instantánea

Servidor Capacidad del Capacidad Servidor de Capacidad

de servicio de del Servicio capacidad de servicio
movilida conferencias de terminal de
d de Presencia mensajería
sesión

FIGURA 14.3
Ejemplo de composición de servicios.

para los proveedores de servicios terceros, que pueden ofrecer nuevos servidores de
aplicaciones compuestos de capacidades de servicio IMS.
En esta sección, tras presentar varios ejemplos de composición de servicios,
describimos los trabajos relacionados con la gestión de la composición de servicios.
A continuación, describimos los retos que plantea la introducción de una solución de
gestión de la composición de servicios compatible con IMS.

Ejemplos de composición de servicios

La Figura 14.3 ilustra algunas capacidades de servicio y los de aplicaciones que
pueden compartirlas y reutilizarlas. Por ejemplo, un servidor de aplicaciones de e-
learning utiliza la capacidad de servicio de presencia [16] para gestionar la
disponibilidad de los participantes en una clase de e-learning. Además, utiliza una
capacidad de servicio de conferencia [17] para establecer la conversación entre
ellos. Asimismo, los participantes en e-learning pueden transferir la sesión
multimedia de un terminal a otro (por ejemplo, de un teléfono móvil a un PC) a
través de la capacidad de servicio de movilidad de sesión siempre que lo deseen. El
servidor de capacidad del terminal puede cooperar con un servidor de aplicaciones
de e-learning para garantizar la compatibilidad del contexto que se enviará a los
usuarios finales en función de la capacidad de sus terminales. Un servidor de
aplicaciones de videoconferencia multipartita puede utilizar las mismas capacidades
de servicio para establecer una conferencia basada en la disponibilidad de los
participantes. Además, un servidor de aplicaciones de mensajería instantánea utiliza
la capacidad del servicio de presencia para transferir mensajes entre usuarios en
función de su estado de presencia. Soporte
338 Manual del subsistema multimedia fP (fM£)

esa cooperación entre servicios apelará a mecanismos que adapten las interacciones
entre ser- vicios y gestionen la composición de los servicios.

Gestión de la composición de servicios

Como plataforma abierta de control de servicios, el IMS es un paso hacia la con-
vergencia de la red al tiempo que intenta apoyar la cooperación satisfactoria entre
servidores de aplicaciones y componentes de servicios a través de diferentes redes.
De hecho, mediante la composición de servicios, se pueden lograr todo tipo de
escenarios de interfuncionamiento de servicios independientemente de las
funcionalidades de control subyacentes. La gestión de la composición de servicios
consiste principalmente en poner a disposición de los servidores de aplicaciones las
capacidades de servicio, controlar el acceso de los distintos servidores de aplicaciones a las
capacidades de servicio y gestionar las interacciones entre los servidores de aplicaciones y
las capacidades de servicio respetando la confidencialidad del contexto del usuario.
Además, hay que tener en cuenta que la eficacia de un servidor de aplicaciones
compuesto depende en gran medida no sólo de las preferencias del usuario, sino
también del contexto (condiciones y limitaciones de la red) en el que el usuario
accederá al servidor de aplicaciones. En consecuencia, esto permitirá que los
servidores de aplicaciones sean adaptables y fácilmente reconfigurables tanto a las
preferencias del usuario como a las de la red.

Trabajos relacionados
En la literatura y en las normas se especifican varias soluciones para lograr la
composición de servicios. A continuación, repasamos estas soluciones y analizamos
su capacidad para realizar el interfuncionamiento de servicios en el IMS.

Solución de gestión de la composición de servicios basada en OMA

La Open Mobile Alliance (OMA) [18] es el punto focal para el desarrollo de
entidades de servicios móviles (denominadas habilitadores) y garantiza la
interoperabilidad sin fisuras de los servicios entre distintos dispositivos, proveedores
de servicios y operadores de red. La cooperación entre la OMA y el 3GPP permite a
la OMA aprovechar las capacidades del IMS de forma interoperable especificando
los habilitadores de servicios emergentes, como el habilitador de servicios de
mensajería instantánea y presencia (IMPS) [19], el habilitador de servicios push-to-talk
sobre celular (PoC) [20] y el habilitador de servicios de juegos de la OMA [21]. En
estos ejemplos de servicio, la OMA aplica interfaces de programación de
aplicaciones (API) para gestionar la composición de habilitadores de servicio y
capacidades inherentes al IMS, como las capacidades de servicio de presencia y
mensajería [22].
Sin embargo, la cooperación entre servicios sólo se limita a los habilitadores
OMA. Además, las especificaciones no contemplan cómo hacer posible que
diferentes servidores de aplicaciones compartan y reutilicen las capacidades de los
servicios. Por ejemplo, la OMA no especifica cómo la capacidad del servicio de
presencia que se utiliza en el IMPS de la OMA puede ser compartida y reutilizada
por el PoC de la OMA o por los habilitadores del servicio de juegos de la OMA. Por
último, el soporte de un entorno multiprotocolo
Orquestación de servicios en fM£ 339

por la OMA para seguir cumpliendo con la naturaleza basada en SIP del IMS
introduce características adicionales de adaptación de protocolo.

Solución de gestión de la composición de servicios basada en OSA/Parlay

El Grupo Parlay [23] es un consorcio multivendedor fundado para desarrollar API
abiertas e independientes de la tecnología que permitan el desarrollo de aplicaciones
que operen en múltiples entornos de plataformas de red. Parlay es independiente del
protocolo y su objetivo es abstraer las capacidades de la red en un conjunto de API
que permitan a los servicios y aplicaciones acceder a la funcionalidad de la red
principal de forma transparente.
Aunque la arquitectura OSA/Parlay pretende permitir la integración de
capacidades de servicio especificadas por diferentes organismos de normalización,
no puede aplicarse directamente como medio para la gestión de la composición de
servicios en el IMS. De hecho, para adaptar la arquitectura OSA/Parlay al IMS, debe
utilizarse una pasarela Parlay sobre los componentes IMS, a través de la API Parlay.
En este caso, la pasarela debe traducir los métodos de la API Parlay a los mensajes
SIP. Además, las funcionalidades definidas sobre la pasarela Parlay cubren
únicamente las cuestiones de control de acceso a servicios y descubrimiento de
servicios. No se especifica la gestión de la posición común de los servicios ni la
forma en que deben compartir bloques de construcción de servicios comunes. Por lo
tanto, es necesario un entorno abierto de convergencia de servicios para utilizar los
servicios basados en Parlay en un entorno de red distribuida. Por último, la solución
basada en OSA/Parlay implica una fuerte dependencia de los servicios de los
definidos en los estándares OSA/Parlay.

Soluciones de gestión de la composición de servicios basadas en ontologías

Otra línea de investigación se centra en los mecanismos basados en ontologías para
permitir las siguientes funciones: descripción de servicios, descubrimiento de servicios,
invocación de servicios y composición e interoperación de servicios.
Yokohata et al. [24] proponen un método de gestión de composición de servicios
utilizable en entornos de Internet móvil. Este método utiliza una ontología de
lenguaje Web para servicios (OWL-S) para modelar escenarios de servicio y definir
una secuencia de elementos de servicio a invocar. La ontología OWL-S se compone
de tres partes principales: perfil de servicio (describe el servicio), modelo de proceso
(presenta las restricciones de interacción con este servicio) y base de servicio
(detalla los medios de interacción con este servicio). Una vez modelados los
servicios, un motor de composición de servicios traduce el escenario, encuentra los
elementos de servicio apropiados (basándose en la semántica y las situaciones o
contextos del usuario) e invoca los elementos de servicio a través de interfaces de
servicios Web.
En Tarkoma et al. [25] se propone otro mecanismo de composición de servicios
basado en ontologías. Utiliza la ontología y las tecnologías de la Web semántica
para la gestión integrada del conocimiento en plataformas de servicios móviles. Esta
propuesta permite una adaptabilidad dinámica a las necesidades de los usuarios.
Además, se garantiza la interacción automática de los servicios móviles.
340 Manual del subsistema multimedia fP (fM£)

Sin embargo, los modelos de servicio representados por estos mecanismos

basados en ontologías tienen que hacer frente a limitaciones a la hora de expresar la
definición de los servicios y sus necesidades y comportamientos. Además, el motor
de composición de propuesto debe actualizarse periódicamente para garantizar la
interoperabilidad de los nuevos servicios con la plataforma de servicios.

Gestor de Interacción de Capacidades de Servicio (SCIM)

El 3GPP introdujo SCIM [26] como una función dentro del dominio del servidor de
aplicaciones SIP del IMS para gestionar las interacciones entre servidores de
aplicaciones. Sin embargo, las funcionalidades de SCIM no están especificadas y la
investigación en este campo está en curso.
El trabajo descrito en la referencia [27] presenta diferentes formas de diseñar
SCIM, tales como:

un despachador de peticiones dentro del entorno de ejecución local para las

lógicas de vicio;
un gestor de interacciones entre los componentes que implementan proxies
SIP o agentes de usuario;
un gestor de interacciones entre capacidades de servicio expuestas mediante
abstracciones del IMS basadas en el lenguaje de definición de servicios
web (WSDL) y en el protocolo simple de acceso a objetos (SOAP); y
un gestor de interacción entre las funciones SIP y los componentes del sistema
señalización heredado.

La elección entre estos diferentes comportamientos del SCIM depende de las

cuestiones tecnológicas y de modelo de negocio de los diferentes proveedores de
servicios y todavía se considera un tema abierto.
Araki, Yamamoto y Sweeney [28] proponen una plataforma de servicios de
entretenimiento en grupo que se ocupa de los requisitos de aprovisionamiento de los
servicios de entretenimiento móvil y les proporciona un mecanismo dinámico de
composición de servicios. El SCIM se utiliza en esta plataforma de servicios de
entretenimiento en grupo con las siguientes funcionalidades:
establecimiento/recuperación del contexto de usuario, aprovisionamiento de
servicios e invocación de servicios. Sin embargo, el SCIM definido en esta
propuesta debe ampliarse para cubrir la interoperabilidad entre componentes de
servicio.
Para superar las limitaciones de estas solucionesen la siguiente sección
presentamos los requisitos para dotar al IMS de un mecanismo de gestión de la
composición de servicios.

Requisitos IMS para la gestión de la composición de servicios

La cooperación entre servicios requiere un mecanismo de composición de servicios
en el IMS. Este mecanismo implica las siguientes características:
Orquestación de servicios en fM£ 341

Servidor de Servidor de Servidor de

videoconferencias e- mensajería
multipartito learning instantánea

Gestión del
acceso a los Políticas de red
servicios

Gestor de
Composición del servicio Plantilla de composición de servicios Interacción
Gestión: Base de datos de
Estática Capacidades
& de Servicio
(SCIM)
Dinámico Repositorio de servicios

Acceso a los servicios

Gestión Perfil de usuario y servicio

Servidor Servidor de Servidor Servidor de Servidor de

de conferenci de capacidad mensajer
movilida as presenci de ía
d de a terminales
sesión

FIGURA 14.4
SCIM para gestionar la composición de servicios en el IMS.

• La solución de gestión de la composición de servicios para el IMS debe

respetar la arquitectura abierta del IMS, en la que se admiten de forma
flexible diferentes servicios en diferentes redes.
• Este mecanismo debe ser adaptable al IMS. Esta adaptabilidad puede
lograrse utilizando enfoques de gestión de interoperabilidad de servicios
compatibles con SIP.
• Esta solución debe ser extensible a la introducción de servicios innovadores
y personalizados.

Para alcanzar estos objetivos, como se ilustra en la Figura 14.4, SCIM podría
acoplarse a un algoritmo de gestión de composición de servicios. Las dos funciones
principales de este algoritmo incluyen:
342 Manual del subsistema multimedia fP (fM£)

• Gestión del acceso a los servicios. Esta función controla el acceso de

servidores de aplicaciones a las capacidades del servicio. Este control
consiste en autenticar los servidores de aplicaciones (a través de las
políticas de red y los acuerdos de servicio entre operadores de red y
proveedores de servicios) y autorizar el acceso al servicio. Este control es
necesario, sobre todo cuando un servicio de terceros desea utilizar una
capacidad de servicio de la red.
• Gestión de la composición de servicios. Esta función controla la
reutilización de las capacidades de servicio por parte de los servidores de
aplicaciones. Este control puede ser estático (es decir, basado en una
plantilla de composición de servicios predefinida que indique qué servidor
de aplicaciones necesita qué capacidad de servicio en qué condición). Por
ejemplo, un servidor de aplicaciones de e-learning debe estar compuesto
por un servidor de presencia, un servidor de mensajería y un servidor de
conferencias. En este ejemplo el conjunto sucesivo de capacidades de
servicio que utilizará el servidor de aplicaciones de e-learning se presentará
estáticamente en una plantilla de composición de servicios. Sin embargo,
no todos los servicios integrados pueden definir su composición de forma
estática. Por ejemplo, dependiendo del entorno contextual, un servidor de
conferencias multimedia puede ponerse en contacto con el servidor de
capacidades del terminal para enviar los medios adecuados a los usuarios
según las características de sus terminales. Por lo tanto, la cooperación
entre el servidor de conferencias multimedia y el servidor de capacidad del
terminal depende de las preferencias del usuario y difícilmente puede ser
estática. Por lo tanto, en este ejemplo, el servidor de capacidad del terminal
debe estar disponible dinámicamente (y a petición del usuario) para el
servidor de conferencias multimedia. En consecuencia, se requiere un
mecanismo dinámico de gestión de la composición de servicios.

Conclusión
Las NGN han surgido en los dos últimos años como medio para prestar servicios a
los usuarios en redes heterogéneas. Junto a estas innovaciones, como principal
superposición de control de servicios de las NGN, el IMS está especificado para
gestionar la prestación de servicios multimedia. Sin embargo, las especificaciones
IMS actuales adolecen de deficiencias críticas a la hora de interactuar con los
servicios. Dicha interacción de servicios puede ser negativa o positiva. Las
interacciones de servicio negativas dan lugar a conflictos entre servicios y acaban
con comportamientos inesperados de los mismos. Las interacciones positivas, en
cambio, permiten crear servicios enriquecidos compuestos por bloques modulares de
servicios.
A la luz del crecimiento de IMS hacia una plataforma única de control de
servicios, la falta de gestión de la interacción de servicios es inaceptable. El análisis
desarrollado en este capítulo sobre las normas del modelo de referencia de las NGN,
principalmente sobre
Orquestación de servicios en fM£ 343

Las especificaciones del IMS han puesto de manifiesto la insuficiencia de las

normas para gestionar las interacciones entre servicios. A partir de un estudio
exhaustivo de los trabajos de investigación relacionados, se definen los requisitos y
principios para introducir un mecanismo inteligente de orquestación de servicios en
el IMS.
Dado que el IMS es un estándar en evolución y que los servicios NGN son
testigos de crecientes evoluciones e innovaciones, existen muchas perspectivas en la
dirección de la gestión de la interacción de servicios IMS. El primer paso puede ser
implantar el corredor de servicios y el SCIM en la plataforma IMS.

Referencias
1. 3GPP, TS 23.2281. Subsistema multimedia IP (IMS), 3GPP TS 23.228.
2. Rosenberg, J. et al. 2002. SIP: Protocolo de iniciación de sesión, IETF RFC 3261.
3. Keck, D. O., y P. J. Kuehn. 1998. El problema de la interacción entre características y
servicios en los sistemas de telecomunicaciones: A survey. IEEE Transactions on Software
Engi- neering 24(10):779-796.
4. Calder, M., M. Kolberg, E. H. Magill y S. Reiff-Marganiec. 2003. Feature interaction: A
critical review and considered forecast. The International Journal of Computer and
Telecommunications Networking 41(1):115-141.
5. Cameron, E. J., N. D. Griffeth, Y.-J. Lin, M. E. Nilson, W. K. Schnure y H. Velthuijsen.
1993. A feature-interaction benchmark for IN and beyond. IEEE Communication Magazine
31(3):64-69.
6. Kolberg, M., y E. H. Magill. 2001. Gestión de incompatibilidades entre servicios
desplegados en redes basadas en IP. IEEE Intelligent Networks 2001:360-370.
7. Harada, D., H. Fujiwara y T. Ohta. 2006. Evitación de interacciones de características en
tiempo de ejecución. IEEE International Conference on Software Engineering Advances:6-
12.
8. Chan, K. Y., y G. V. Bochmann. 2003. Methods for designing SIP services in SDL with
fewer feature interactions. En Feature interaction in telecommunications and software
systems VII, 59-77. Amsterdam. Amsterdam: IOS Press.
9. Chentouf, Z., S. Cherkaoui y A. Khoumsi. 2003. Implementing online fea- ture interaction
detection in SIP environment: Early results. IEEE International Conference on
Telecommunications 2003:515-521.
10. Khoumsi, A. 1997. Detección y resolución de interacciones entre servicios de redes
telefónicas. En Feature interaction in telecommunications networks IV, 78-92. Amsterdam:
IOS Press.
11. Jouve, H., P. L. Gall y S. Coudert. 2005. An automatic offline feature interaction detection
method by static analysis of specifications. En Feature interactions in telecommunications
and software systems VIII, 131-146. Amsterdam. Amsterdam: IOS Press.
12. Crespo, R. G., M. Carvalho y L. Logrippo. 2006. Resolución distribuida de interacciones
de características para aplicaciones de Internet. Elsevier Computer Networks 51(2): 382-
397.
13. Kolberg, M., y E. H. Magill. 2002. A pragmatic approach to service filtering between call
control services. The International Journal of Computer and Telecommunications
Networking 38(5):591-602.
344 Manual del subsistema multimedia fP (fM£)

14. Kolberg, M., y E. H. Magill. 2007. Managing feature interactions between distributed SIP
call control services. Elsevier Computer Networks 51(2):536-557.
15. 3GPP, TR 23.810. Estudio sobre los impactos en la arquitectura de la intermediación de servicios.
16. 3GPP, TS 24.141. Servicio de presencia utilizando el subsistema de red central (CN) IP
multimedia (IM), 3GPP TS 24.141.
17. 3GPP, TS 24.147. Conferencing using IP multimedia (IM) core network (CN)
subsystem, 3GPP TS 24.147.
18. Alianza Móvil Abierta. Disponible en [Link]
19. OMA-IMPS. Definición de la versión del habilitador para IMPS, V1.3, OMA-ERELD-IMPS
-V1_3-20070123-A.
20. OMA-PoC. Enabler release definition for push-to-talk over cellular, V 1.0.1, OMA-
ERELD-PoC-V1_0_1-20061128-A.
21. OMA-Juegos. Enabler release definition for game services, V 1.0, OMA-ERELD- Games-
Services-V1_0-20030612-C.
22. 3GPP, TS 23. 140. Servicio de mensajería multimedia (MMS), Descripción funcional.
23. Parlay. Disponible en [Link]
24. Yokohata, Y., Y. Yamato, M. Takemoto y H. Sunaga. 2006. Service composition architecture
for programmability and flexibility in ubiquitous communication networks. Simposio
internacional del IEEE sobre aplicaciones y talleres de Internet.
25. Tarkoma, S., C. Prehofer, A. Zhdanova, K. Moessner y E. Kovacas. 2007. SPICE: Evolving
IMS to next-generation service platforms. Simposio internacional del IEEE sobre
aplicaciones y talleres de Internet.
26. 3GPP, TS 23.002. Arquitectura de red.
27. dev2dev. Service Capability Interaction Management (SCIM) in IMS. http://
[Link]/blog/mpalmete/archive/2006/02/service_capabil.html
28. Araki, Y., A. Yamamoto, y M. Sweeney. 2007. Dynamic community entertain- ment service
composition on next-generation mobile network IP multimedia sub- system. IEEE
International Symposium on Applications and the Internet Workshops.
29. Cortez, M., J. R. Ensor, y J. O. Esteban. 2004. Sobre el rendimiento de SIP. Bell Labs
Technical Journal 2004:155-172.
30. Crespi, N. 2006. A distributed mechanism to resolve dynamically feature inter- action in the
UMTS IP multimedia subsystem. Taller internacional sobre aplicaciones y servicios en
redes inalámbricas.
15
Servicio de mensajería
instantánea y presencia
(fMP£)

Whai-En Chen

CONTENIDO
Introducción ....................................................................................................................... 345
Mensaje instantáneo (MI) ................................................................................................ 346
Servicio de Presencia (PS) .................................................................................................. 348
Servicio de presencia 3GPP IMS ......................................................................................... 356
Debate y conclusiones ...................................................................................................... 360
Acuse de recibo ................................................................................................................. 361
Referencias .......................................................................................................................... 361

Introducción
El servicio de mensajería instantánea y presencia (IMPS) es un tema candente y
popular en los círculos de Internet. Muchas aplicaciones IMPS, como ICQ, MSN, Yahoo!
Messen- ger y Google Talk, están muy extendidas y se utilizan para comunicaciones
a corto plazo y casi en tiempo real. En los últimos , el IMPS ha cambiado el
comportamiento comunicativo. Con IMPS, los usuarios conocen la información de
presencia de sus amigos y, por tanto, pueden elegir la forma más eficaz (por
ejemplo, voz o mensaje instantáneo) de comunicarse. IMPS es una de las
aplicaciones estrella entre los servicios all-IP.
Dado que SIP (protocolo de iniciación de sesión) [1] es el principal protocolo de
señalización en el 3GPP (3rd Generation Partnership Project) IMS (subsistema
multimedia IP), el 3GPP también adopta las extensiones SIP propuestas por el grupo
de trabajo SIMPLE (SIP for instant messaging and presence leveraging extensions)
del IETF (Internet Engineering Task Force) como protocolo de señalización para
IMPS. En las extensiones SIP, se utiliza el método SIP MESSAGE para enviar
mensajes instantáneos. Los métodos PUBLISH, SUBSCRIBE y NOTIFY se utilizan para
el servicio de presencia [6,9]. El formato de datos de los cuerpos de mensaje para
mensajería instantánea

345
346 Manual del subsistema multimedia fP (fM£)

UA1 Servidor SIP UA2

1. MENSAJE
2. MENSAJE

3. 200 OK
4. 200 OK

FIGURA 15.1
Un ejemplo de envío de mensajes instantáneos.

y un servicio de presencia se especifican utilizando texto plano y PIDF (formato de

datos de información de presencia) [5], respectivamente.
Este capítulo utiliza varios ejemplos para presentar los métodos SIP, los campos
de cabecera y el formato de datos de las extensiones SIP. Basado en las
especificaciones 3GPP TS
23.228 [16] y TS 23.141 [15], este capítulo analiza la arquitectura del servicio de presencia
en el 3GPP IMS. A continuación, utiliza un flujo de mensajes para introducir los
procedimientos del servicio de presencia en el IMS. Por último, este capítulo analiza
los problemas y las soluciones existentes del IMPS.

Mensaje instantáneo (MI)

Un mensaje instantáneo (IM) se transfiere utilizando el método SIP MESSAGE, que
es una extensión de SIP definida en IETF RFC 3428 [17]. A diferencia de la voz sobre
IP (VoIP), un mensaje instantáneo es independiente y, por lo tanto, no requiere
negociar las direcciones IP o los números de puerto para las sesiones multimedia
posteriores. En su lugar, los mensajes instantáneos se envían directamente a los
destinos a través de servidores de mensajería instantánea. Al recibir una solicitud de
MENSAJEuna UA SIP (agente de usuario) responderá con un 200 OK o una
respuesta 202 Aceptada, que indica que la UA SIP ha recibido el mensaje de solicitud
SIP. Este mensaje 200 OK o 202 Accepted no indica que el usuario haya visto esta
solicitud de MENSAJE porque el usuario puede estar lejos del ordenador (es decir,
de la UA SIP).
Una petición MESSAGE debe contener los campos de cabecera Content-Type y
Content-Length para identificar el tipo y la longitud del cuerpo del mensaje; sin
embargono contiene el campo de cabecera Contact. Además, el formato del cuerpo
del mensaje puede ser un formato basado en texto o un formato de extensiones de
correo de Internet multiuso (MIMEs). En la Figura 15.1 se ilustra el flujo de
mensajes para la transferencia de MI.
En la Figura 15.1 hay dos UA SIP (UA1 y UA2) y un servidor SIP. El URI SIP
(identificador universal de recursos) y el nombre de dominio de la UA1 son
"user1@[Link] " y "[Link]", respectivamente. El URI SIP y
el nombre de dominio para UA2 son "user2@[Link] " y "user2pc.
Servicio de mensajería instantánea y presencia 342
(fMP£)

01 MENSAJE sip:user2@[Link] SIP/2.0

02 Via: SIP/2.0/TCP [Link];branch=z9hG4bK776sgdkse

03 Max-Forwards: 70

04 De: sip:user1@[Link];tag=49583

05 Para: sip:user2@[Link]

06 Call-ID: asd88asd77a@[Link]

07 CSeq: 1 MENSAJE

08 Content-Type: text/plain

09 Contenido-Longitud: 17

10

11 Joe. ¿Qué tal estás?

FIGURA 15.2
Un ejemplo de mensaje SIP MESSAGE.

[Link]", respectivamente. El nombre de dominio del servidor SIP es

"[Link]". Supongamos que UA1 y UA2 han registrado sus direcciones de
contacto (es decir, direcciones IP) en el servidor SIP. UA1 intenta enviar un mensaje
instantáneo a UA2. El procedimiento se describe a continuación:

Primer paso. Dado que UA1 no dispone de la dirección IP de UA2, envía la

solicitud SIP MESSAGE al servidor SIP utilizando el URI de UA2.
Paso 2. Al recibir la solicitud SIP, el servidor SIP recupera la dirección IP de
UA2 de su base de datos de registro y reenvía este mensaje a UA2.
Paso 3. UA2 responde con un mensaje 200 OK a UA1 después de recibir el
mensaje correctamente. Basándose en el campo de cabecera Via, el mensaje 200
OK se devuelve a UA1 a través del servidor SIP.
Paso 4. El servidor SIP transmite el mensaje de respuesta a UA1 basándose en
el campo de cabecera Via.

La Figura 15.2 muestra la solicitud de MENSAJE SIP entregada en el paso 1 de la

Figura 15.1. Los lectores pueden ver un ejemplo del mensaje instantáneo basado en
texto en esta figura. La información detallada se describe a continuación.
El Request-URI (es decir, user2@[Link]) en la línea de inicio identifica el SIP URI
del destinatario (es decir, UA2). Para recibir la respuesta enviada desde UA2, UA1
añade su nombre de dominio (es decir, la dirección de contacto) en un campo de
encabezado Via. El campo de cabecera Max-Forwards limita el número máximo de
saltos (es decir, 70 saltos) en los que se puede enviar una respuesta.
348 Manual del subsistema multimedia fP (fM£)

este mensaje puede ser retransmitido al destinatario. Los campos de cabecera From
y To presentan los URI SIP del emisor y del destinatario, respectivamente. El campo
de encabezado CSeq identifica el orden de la transacción (es decir, MENSAJE 1). El
campo de cabecera Content-Type indica que este mensaje es un mensaje de texto
plano, y la longitud del mensaje (es decir, 17) se especifica en el campo de cabecera
Content-Length. Los campos de cabecera SIP y el cuerpo del mensaje SIP están
separados por CRLF. La última línea, "Joe, ¿cómo estás?", es el contenido de este
mensaje instantáneo.
En general, los mensajes instantáneos se utilizan para intercambiar información
entre un grupo específico de usuarios. A diferencia del correo electrónico, los
mensajes instantáneos suelen enviarse casi en tiempo real, y muchas aplicaciones de
mensajería instantánea están asociadas a servicios de presencia. Los usuarios de
mensajería instantánea conocen el estado (es decir, conectado o desconectado) de
sus amigos y envían mensajes instantáneos a los amigos conectados. La información
detallada del servicio de presencia (PS) se detalla en la siguiente sección.

Servicio de Presencia (PS)

A través del servicio de presencia, los usuarios pueden cambiar el estado de sus
paquetes de eventos (por ejemplo, de "conectado" a "ocupado") y suscribirse a los
estados de los paquetes de eventos de sus amigos. La primera función se implementa
mediante el método SIP PUBLISH, y la segunda mediante los métodos SIP SUBSCRIBE
y NOTIFY. Esta sección describe los procedimientos de estos métodos SIP y, a
continuación, utiliza un ejemplo para demostrar el flujo de mensajes detallado.
Al igual que el mensaje REGISTER, un mensaje PUBLISH permite a un usuario
crear, modificar o eliminar su estado. Dado que un usuario puede tener varios
agentes de usuario (por ejemplo, ordenador portátil y PDA) para publicar sus
propios estados, no basta con utilizar la cuenta del usuario como único identificador.
Para resolver este problema, se proponen dos nuevos campos de cabecera (SIP-Etag
y SIP-If-Match) para identificar el estado específico del evento. Cada mensaje PUBLISH,
excepto el primer mensaje PUB- LISH, debe contener un campo de cabecera SIP-If-
Match para actualizar, modificar o eliminar el estado del paquete de eventos.
Cuando el servidor SIP recibe un mensaje PUB- LISH, actualiza el estado del
evento basándose en el campo de cabecera SIP-If-Match. El servidor SIP genera
entonces otro identificador, rellena este identificador en un campo de cabecera SIP-
Etag, y responde con este SIP-Etag al usuario a través de un mensaje 200 OK.
La operación específica de un mensaje PUBLISH determina el estado del
y el campo de cabecera SIP-If-Match. Los detalles se enumeran en la Tabla 15.1.
Cuando un usuario inicia sesión en el servicio de presencia, se envía un mensaje
PUBLISH inicial al servidor PS para crear una publicación de estado suave [10].
Este mensaje PUBLISH contiene el cuerpo del mensaje PIDF para describir el
estado del evento y un campo de cabecera Expires para identificar el tiempo de vida
sugerido del estado del evento. El servidor PS puede disminuir o aceptar el valor del
tiempo de vida y responder con el con-
Servicio de mensajería instantánea y presencia 349
(fMP£)

TABLA 15.1
Contenido de un mensaje PUBLISH
Operación Cuerpo del mensaje SIP-if-match Valor de caducidad
Inicial Sí No >0
Actualizar No Sí >0
Modifique Sí Sí >0
Eliminar No Sí =0

al agente de usuario PS a través de un mensaje 200 OK. Antes de que expire el valor
del campo de cabecera Expires especificado en el mensaje 200 OK, el UA deberá
retransmitir un mensaje PUBLISH para mantener el estado del evento en el servidor
PS. De lo contrario, el estado del evento será eliminado por el servidor PS una vez
expirado el tiempo de vida.
El mensaje PUBLISH para actualizar el estado del evento debe incluir un campo
de cabecera SIP- If-Match para especificar qué entidad del usuario debe actualizarse.
Para ahorrar recursos de red, el mensaje PUBLISH de actualización puede contener un
campo de cabecera Expires, pero no contiene el cuerpo del mensaje. Al igual que el
refresco, el mensaje PUBLISH para modificar el estado del evento contiene un
campo de cabecera SIP-If-Match. A diferencia del refresco, este mensaje PUBLISH incluye
el cuerpo del mensaje para actualizar el estado del evento. Antes de que el usuario se
desconecte del servicio de presencia, el agente de usuario PS debe enviar un
mensaje PUBLISH con los campos de cabecera SIP-If-Match y Expires para
eliminar el estado de eventos. En este mensaje, el valor del campo de cabecera
Expires es 0, indicando que el estado de evento debe ser eliminado. Similar al
mensaje PUBLISH para refrescar, este PUBLISH no incluye un cuerpo de mensaje.
Al recibir un mensaje PUBLISH, el servidor PS responde con un mensaje 200 OK
a la UA. El mensaje 200 OK contiene el campo de cabecera Expires para confirmar
el tiempo de vida del estado del evento y un campo de cabecera SIP-Etag. El formato
PIDF definido en el RFC 3863 [13] incluye el estado básico (es decir, abierto y cerrado) de
un usuario. Para proporcionar un ampliado, el grupo de trabajo SIMPLE del IETF
define otros formatos ampliados como "extensiones de presencia enriquecidas para
el formato de datos de información de presencia" e "información de contacto para el
formato de datos de información de presencia". Los lectores pueden consultar el
RFC 4480 [12] y el RFC 4482 [11] para obtener más información. En la Figura 15.3
se muestra un ejemplo de PIDF.
La primera línea especifica que el formato está basado en XML (extensible
markup language) versión 1.0 y esquema de codificación id UTF (UCS/unicode
transfor- mation format)-8. El elemento <presence> contiene una declaración de
espacio de nombres (es decir, xmlns) para indicar el espacio de nombres en el que se
basa el cuerpo del mensaje de presencia. Para el documento de presencia conforme a
RFC 3863 [13], el espacio de nombres es "urn:ietf:params:xml:ns:pidf". Una tupla
de presencia es transportada por el elemento <tuple> que consiste en un elemento
obligatorio <status> y uno o más elementos opcionales. En el ejemplo de la Figura
15.3, el elemento <status> va seguido de un elemento opcional <contact>, un
elemento opcional <note> y un elemento opcional <timestamp>. La raíz de una
"applica-
350 Manual del subsistema multimedia fP (fM£)

01 <?xml version="1.0" encoding="UTF-8"?>

02 <presencia xmlns="urn:ietf:params:xml:ns:pidf "entidad="pres:user1@[Link]">

03 <tupla id="sg89ae">

04 <estado>

05 <básico>abrir</básico>

06 </status>

07 <contacto priority="0.8">[Link]

08 <note xml:lang="es">¡No molestar por favor!</note> 09

<timestamp>2007-10-27T[Link]Z</timestamp>

10 </tuple>

11 </presencia>

FIGURA 15.3
Un ejemplo del formato PIDF.

tion/pidf+xml" es un elemento <presence> (línea 02) asociado al espacio de

nombres de la información de presencia. El elemento <presence> debe incluir un
atributo entity. Este atributo identifica la URL (localizador universal de recursos) de
la entidad de presencia que publica este mensaje. El elemento <tuple> contiene un
identificador único (es decir, el atributo id) para distinguir diferentes elementos
<tuple> en el mismo elemento <presence>. El elemento <status> es un elemento
hijo del elemento <tuple>. Dentro del elemento <status>, un <basic> contiene la
cadena "open", que significa que la presencia está disponible para recibir mensajes
instantáneos.
Por otro lado, si la cadena está cerrada, es posible que la presentidad no reciba un
mensaje instantáneo. El elemento <contact> contiene una URL de la dirección de
contacto de la presentidad. El elemento <contact> tiene un atributo priority que
indica la prioridad relativa de esta dirección de contacto. El valor del atributo
priority está comprendido entre 0 y 1, y cuanto mayor sea el valor, mayor será la
prioridad. El elemento <note> proporciona los comentarios legibles identificados
por un atributo xml:lang. En este ejemplo, el valor del atributo xml:lang es "en", lo
que significa que el comentario se presenta en inglés. El elemento <timestamp>
contiene la fecha y la hora en que se modificó el estado de esta tupla. El valor de
este elemento sigue el formato fecha-hora definido en RFC 3339 [18]. En este
ejemplo, 2007-10-27T[Link]Z representa 49 minutos y 29 segundos después de la
hora 16 del 27 de octubre de 2007, en UTC (hora estándar del Pacífico).
Los mensajes SIP SUBSCRIBE y NOTIFY se utilizan para suscribirse y notificar el
estado de los paquetes de eventos entre los usuarios y el servidor PS. El servidor PS
puede ser un servidor sin estado o un servidor con estado. El servidor sin estado no
almacena los estados de los eventos de los usuarios. Así, cada mensaje SUBSCRIBE es
directamente
Servicio de mensajería instantánea y presencia 351
(fMP£)

a la UA PS destinataria. Por otro lado, el servidor PS stateful almacena en caché los

estados de los eventos para los usuarios. El servidor PS recuperará los estados de su
base de datos y responderá con mensajes NOTIFY si los estados se encuentran y no
han caducado. En este capítulo utilizaremos, por ejemplo, el servidor PS con estado.
Cuando un usuario intenta suscribirse a un evento, la UA PS del usuario envía un
mensaje SUBSCRIBE con los campos de cabecera Event y Expires. El campo de
cabecera Evento especifica el estado del evento al que el usuario desea suscribirse.
El campo Expires especifica la duración de la suscripción. Una vez que el servidor
PS recibe este mensaje, decide si acepta o no la suscripción. A continuación, el
servidor PS responde con un mensaje NOTIFY con el campo de cabecera
Subscription- State para informar a la UA PS de los resultados de la suscripción.
Tenga en cuenta que la admisión de la suscripción se transmite en el mensaje
NOTIFY en lugar de en un mensaje 200 OK. El valor del campo de cabecera
Subscription-State puede ser activo, pendiente o finalizado. El valor "activo"
significa que la se ha realizado correctamente y que la información de presencia (es
decir, el estado del evento) se transmite en el mismo mensaje NOTIFY. El valor
"pendiente" representa que la suscripción sigue esperando la decisión del usuario. El
valor "terminada" significa que la suscripción ha sido rechazada y el motivo del
rechazo también se transmite en el mensaje NOTIFY. Por ejemplo, el valor "noresource"
en el parámetro event-reason-value significa que el evento suscrito no existe.
El servidor PS confirma la duración de la suscripción mediante un mensaje 200
OK con el campo de cabecera Expires. El servidor puede disminuir o aceptar el
valor de duración sugerido por el PS UA que envía el mensaje SUBSCRIBE. Antes
de que expire la duración de la suscripción (especificada en el campo de cabecera
Expires), el PS UA deberá retransmitir un mensaje SUBSCRIBE para actualizar la
subscripción. El abonado puede cancelar la suscripción enviando un mensaje SUBSCRIBE
con el valor 0 en el campo Expires de la cabecera. El PS UA suscrito (es decir, el
prescriptor) puede cancelar la suscripción enviando un mensaje NOTIFY con el
valor "terminated" en el campo de cabecera Subscription-State.
La Figura 15.4 muestra los flujos de mensajes para el servicio de presencia. En
este ejemplo, los URIs SIP y los nombres de dominio son los mismos que en la
Figura 15.1. Además, el servidor SIP es capaz de realizar las funciones de un
servidor PS. Además, el servidor SIP es capaz de realizar las funciones de un
servidor PS. Supongamos que UA1 permite a UA2 suscribirse a sus estados de
eventos. En este ejemplo, UA1 está fuera de línea y UA2 intenta suscribirse al
estado de eventos de UA1. Los procedimientos detallados se describen a
continuación:

Paso 1. La UA2 envía un mensaje SUBSCRIBE para obtener el estado de la UA1.

UA2 envía un mensaje SUBSCRIBE para obtener el estado de UA1.
Basándose en el Request-URI (es decir, UA1@[Link]), este mensaje se
envía al servidor SIP (es decir, el servidor PS). Una vez recibido el mensaje
SUBSCRIBE, el servidor responde con un mensaje 200 OK a UA2 para
indicar que el mensaje SUBSCRIBE se ha recibido correctamente.
Segundo paso. Dado que UA1 permite a UA2 suscribirse a sus estados de
eventos, el servidor envía un mensaje NOTIFY con el estado de UA1 (es
decir, cerrado, lo que significa desconectado) a UA2. Al recibir el mensaje
NOTIFY, UA2 responde con un 200 OK al servidor SIP.
352 Manual del subsistema multimedia fP (fM£)

UA1 Servidor UA2

SIP

1. SUSCRIBETE
1. 200 OK
2. NOTIFICAR

2. 200 OK

3. PUBLICAR

3. 200 OK

4.
NOTIFICAR
4. 200 OK
5. PUBLICAR
5. 200 OK

6. PUBLICAR

6. 200 OK
7.
NOTIFICAR
7. 200 OK

FIGURA 15.4
Un ejemplo del flujo de mensajes del servicio de presencia.

Paso 3. La UA1 se conecta al servicio de presencia y envía un mensaje

PUBLISH para cambiar su estado de cerrado (es decir, desconectado) a
abierto (es decir, conectado). UA1 inicia sesión en el servicio de presencia
y envía un mensaje PUBLISH para cambiar su estado de cerrado (es decir,
desconectado) a abierto (es decir, conectado). El servidor SIP responde con
un 200 OK para acusar recibo del mensaje PUBLISH.
Paso 4. El servidor SIP detecta que el estado de UA1 ha cambiado e informa a
UA2 mediante el envío de un mensaje NOTIFY. Al recibir el mensaje
NOTIFY, UA2 responde con un mensaje 200 OK.
Paso 5. Asumiendo que el tiempo de vida de la publicación está a punto de
expirar, UA1 envía un mensaje PUBLISH para refrescar su estado. Nótese
que este mensaje PUBLISH no incluye un cuerpo de mensaje. Al recibir el
mensaje PUBLISH, el servidor SIP responde con un mensaje 200 OK a UA1.
Como el estado de eventos de UA1 no ha cambiado, el servidor SIP no notifica a
UA2.
Pasos 6 y 7. UA1 cierra la sesión del servicio de presencia y envía un mensaje
PUBLISH con el valor 0 en el campo de encabezado Expires al servidor
SIP. El servidor SIP elimina el estado de eventos de UA1, responde con un
mensaje 200 OK a UA1 y envía un mensaje NOTIFY a UA2 para actualizar
el estado de abierto a cerrado. UA2 responde entonces con un 200 OK al
servidor SIP.

A continuación se describen varios ejemplos de los mensajes mencionados en los

pasos anteriores.
Servicio de mensajería instantánea y presencia 353
(fMP£)

01 SUSCRIBIRSE sip:user1@[Link] SIP/2.0

02 Via: SIP/2.0/TCP [Link];branch=z9hG4bKnashds7

03 Para: <sip:user1@[Link]>

04 De: <sip:user2@[Link]>;tag=12341234

05 Call-ID: 12345678@[Link]

06 Cseq: 1 SUSCRIBIRSE

07 Max-Forwards: 70

08 Caduca: 3600

09 Evento: presencia

10 Contacto: sip:user@[Link]

11 Contenido-Longitud: 0

FIGURA 15.5
Ejemplo de mensaje SUBSCRIBE.

La Figura 15.5 muestra el mensaje SUBSCRIBE entregado en el paso 1 de la

Figura 15.4. En la línea de inicio, el campo de cabecera Request-URI especifica el URI del
agente de usuario suscrito (es decir, UA1). El campo de cabecera Via registra el
nombre de dominio del UA2, que se utiliza para reenviar el mensaje de respuesta
(por ejemplo, el mensaje 200 OK). Los campos de cabecera To, From y Call-ID se
utilizan para identificar el dia- log. El campo de cabecera CSeq indica que el mensaje es
SUBSCRIBE y el número de secuencia es 1. El campo de cabecera Max-Forwards (es decir,
70) limita el máximo de saltos en la ruta de reenvío. El campo de cabecera Expires
indica la duración (es decir, 3.600 segundos) de la suscripción sugerida por UA2. El
campo de cabecera Evento identifica que el estado del evento suscrito es la presencia
de UA1. El campo de cabecera Contacto contiene el nombre de dominio de UA2.
Dado que este mensaje SUBSCRIBE no contiene ningún cuerpo de mensaje, el
valor del campo de cabecera Content-Length es 0.
La Figura 15.6 ilustra el mensaje NOTIFY enviado desde el servidor SIP a la UA2. El
servidor SIP utiliza este mensaje para notificar a UA2 los resultados de la suscripción.
El campo de cabecera Request-URI especifica que este mensaje NOTIFY se envía a
UA2. El campo de cabecera Via es el nombre de dominio del servidor SIP. Los campos
de encabezado To y From son UA2 y UA1, respectivamente. El campo de cabecera
Call-ID registra el identificador de la transacción SIP. Tenga en cuenta que el campo de
encabezado Call-ID (es decir, 12345678@[Link]) y la etiqueta (es decir,
12341234) del campo de encabezado To del mensaje NOTIFY deben coincidir con el
Call-ID y la etiqueta
354 Manual del subsistema multimedia fP (fM£)

01 NOTIFICAR sip:user2@[Link] SIP/2.0

02 Via: SIP/2.0/TCP [Link];branch=z9hG4bK8sdf2

03 Para: <sip:user2@[Link]>;tag=12341234

04 De: <sip:user1@[Link]>;tag=abcd1234

05 Call-ID: 12345678@[Link]

06 Cseq: 1 NOTIFY

07 Max-Forwards: 70

08 Evento: presencia

09 Estado de la suscripción: active; expires=3599

10 Contacto: sip: [Link]

11 Content-Type: application/pidf+xml

12 Content-Length: ...

13 [documento PIDF]

FIGURA 15.6
Ejemplo de mensaje NOTIFY.

del campo de cabecera From en el mensaje SUBSCRIBE, lo que significa que estos dos
mensajes están en el mismo diálogo. El campo de cabecera CSeq indica que el
mensaje es NOTIFY y el número de secuencia es 1. El campo de cabecera Max-Forwards
(es decir, 70) limita el máximo de saltos en la ruta de reenvío. El campo de
encabezado Event identifica que el estado del evento notificado es la información de
presencia de UA1. El campo de cabecera Sub- scription-State indica que la suscripción
está "activa" y expirará a los 3.599 segundos. El campo de cabecera Contact es el
nombre de dominio del servidor SIP. El campo de cabecera Content-Type especifica
que el formato del cuerpo del mensaje utiliza PIDF, y el campo de cabecera Content-
Length presenta el número de caracteres totales del cuerpo del mensaje.
La figura 15.7 ilustra el mensaje PUBLISH enviado desde UA1 al servidor SIP.
Este mensaje se envía cuando UA1 inicia sesión en el servicio de presencia. Como se trata
de un mensaje PUBLISH inicial, este mensaje no contiene el campo de cabecera
SIP-If- Match. De forma similar a los mensajes REGISTER, UA1 rellena su URI en
el campo de cabecera Request-URI y su nombre de dominio (es decir,
[Link]) en el campo de cabecera Via. Los campos de cabecera To
y From son los mismos (es decir, el URI de UA1). El campo de cabecera Call-ID
especifica el identificador de la transacción, y el campo de cabecera CSeq especifica
que este mensaje es un mensaje PUBLISH y que el número de secuencia es 1. El campo
de cabecera Max-Forwards (es decir, 70) limita el número máximo de saltos en la ruta de
reenvío. El campo de cabecera Expires indica
Servicio de mensajería instantánea y presencia 355
(fMP£)

01 PUBLICAR sip:user1@[Link] SIP/2.0

02 Via: SIP/2.0/TCP [Link];branch=z9hG4bK652hsge

03 Para: <sip: user1@[Link]>

04 De: <sip:user1@[Link]>;tag=1234wxyz

05 Call-ID: 81818181@[Link]

06 CSeq: 1 PUBLICAR

07 Max-Forwards: 70

08 Caduca: 3600

09 Evento: presencia

10 Content-Type: application/pidf+xml

11 Content-Length: ...

12 [documento PIDF]

FIGURA 15.7
Ejemplo de mensaje PUBLISH.

duración sugerida de la publicación. En este ejemplo, la duración de esta

publicación es de 3.600 segundos. El campo de cabecera Event especifica el paquete
de eventos modificado. El campo de cabecera Content-Type especifica que PIDF es el
formato del cuerpo del mensaje, y el campo de cabecera Content-Length presenta el
número de caracteres totales del cuerpo del mensaje.
La figura 15.8 muestra el mensaje 200 OK que se utiliza para responder al
mensaje PUBLISH. La línea de inicio identifica este mensaje como un mensaje 200
OK y CSeq especifica que este mensaje es un acuse de recibo para el mensaje
PUBLISH con el número de secuencia 1. Basándose en el campo de cabecera Via, el
mensaje 200 OK se reenvía a UA1. Los campos de cabecera To, From y Call-ID se copian
del mensaje PUBLISH. El campo de cabecera SIP-ETag especificado por el servidor
SIP registra el identificador para las actualizaciones posteriores. El campo de
cabecera Expires especifica la duración del estado del evento. La duración se reduce
de 3.600 segundos a 1.800 segundos, lo que significa que el servidor SIP eliminará
el estado transcurridos 1.800 segundos.
El servicio de presencia en el 3GPP IMS adopta extensiones SIP (por ejemplo,
MES- SAGE, SUBSCRIBE, PUBLISH y NOTIFY) como mensajes de señalización.
Para ahorrar batería y ancho de banda inalámbrico, el 3GPP introduce dos nuevos
componentes (es decir, el servidor de listas de presencia y el servidor de presencia) en
la arquitectura de referencia del servicio de presencia. La arquitectura y el flujo de
mensajes para el servicio de presencia 3GPP se elaboran en la siguiente sección.
356 Manual del subsistema multimedia fP (fM£)

01 SIP/2.0 200 OK

02 Via: SIP/2.0/TCP [Link];branch=z9hG4bK652hsge; received=[Link]

03 Para: <sip:user1@[Link]>;tag=1a2b3c4d

04 De: <sip:user1@[Link]>;tag=1234wxyz

05 Call-ID: 81818181@[Link]

06 Cseq: 1 PUBLICAR

07 Etiqueta SIP: dx200xyz

08 Caduca: 1800

FIGURA 15.8
Un ejemplo del mensaje 200 OK.

Servicio de presencia 3GPP IMS

La Figura 15.9 ilustra la arquitectura de referencia del servicio de presencia 3GPP IMS.
El servicio de presencia 3GPP consta de siete elementos, entre los que se incluyen los
mandantes, el equipo de usuario (UE), el servidor de listas de presencia, el proxy de
presencia observador, el proxy de presencia presencial, el servidor de presencia y un
servidor de abonado doméstico (HSS).

Un mandante (Figura 15.9; a,h) es un usuario en servicio de presencia. En

función de su comportamiento, puede ser un observador o un presenciador,
o puede desempeñar ambos papeles. Por ejemplo, cuando una entidad de
seguridad solicita una suscripción, desempeña el papel de observador. Si la
entidad interesada publica la información de presencia, desempeña el papel
de presente.
El UE (Figura 15.9; b,i) es un equipo del mandante (por ejemplo, un teléfono móvil o
una PDA). La aplicación watcher (Figura 15.9; c) y el agente de usuario de
presencia (Figura 15.9; j) son las aplicaciones que se ejecutan en el UE y se
encargan de solicitar las suscripciones y la publicación de la información
de presencia, respectivamente.
El servidor de listas de presencia (Figura 15.9; g) mantiene varias listas (por
ejemplo, las listas de amigos) para los mandantes. Por ejemplo, con el
servidor de listas de , los mandantes pueden recuperar sus listas de amigos
desde el servidor de listas de presencia en cualquier UE. Además, el
servidor de listas de presencia puede ayudar a un UE a suscribirse a todos
sus amigos utilizando un solo mensaje SUBSCRIBE.
El proxy de presencia del observador (Figura 15.9; d) y el proxy de presencia de
la presen- cia (Figura 15.9; k) consisten en funciones de control de sesión de
llamada (CSCF) y residen en las redes domésticas del observador y de la
presen- cia, respectivamente. Una CSCF proporciona las funciones de proxy
SIP para el control de mensajes SIP. Un CSCF puede ser un proxy CSCF (P-
CSCF), un interrogador
Servicio de mensajería instantánea y presencia 352
(fMP£)

Mas
Red doméstica de vigilantes g Servidor de listas de
cota
2 presencia
3 Pw

b UE1 d Vigilante Presencia Proxy

Pw
a Principal c Aplicación Watcher 1 e P-CSCF f S-CSCF

4 Pw
9
Px
Inicio Red de Presencia o HSS(HLR) 5

i UE2 k Presencia Presencia Proxy

Pep
h Principal j Agente de usuario de 7 1 P-CSCF m S-CSCF n I-CSCF
presencia

6 Pwp
Peu
8 p Servidor de
presencia

FIGURA 15.9
Arquitectura de referencia para soportar el servicio de presencia en el 3GPP IMS.

CSCF (I-CSCF), o una CSCF servidora (S-CSCF). La I-CSCF determina cómo

encaminar las llamadas entrantes a la S-CSCF y, a continuación, al UE de
destino. Es decir, la I-CSCF sirve de punto de contacto de la red IMS para
ocultar al mundo exterior la configuración, capacidad y topología de la red
IMS. La P-CSCF contiene funciones limitadas de traducción de direcciones
para reenviar las solicitudes a la I-CSCF. La se encarga de autorizar los
recursos portadores de la red (que visita el equipo de usuario). Al ejercitar
el registro IMS, se asigna una S-CSCF para dar servicio al . Esta S-CSCF
soporta las interacciones de señalización con el UE para el establecimiento
de llamadas y el control de servicios suplementarios (por ejemplo, solicitud
de servicios y autenticación). El S-CSCF también actúa como registrador
SIP para almacenar las direcciones de contacto del UE. En este ejemplo, el
diálogo es inicializado por el watcher a la presentidad. Por lo tanto, el
proxy de presencia del observador incluye la P-CSCF (Figura 15.9; e) y la
S-CSCF (Figura 15.9; f). El proxy de presencia de la presentidad incluye I-
CSCF (Figura 15.9; n), S-CSCF (Figura 15.9; m), y P-CSCF (Figura 15.9; l).
El servidor de abonado doméstico (Figura 15.9; o) consta de la funcionalidad IMS y
es la base de datos maestra que contiene toda la información de abono
relacionada con el usuario.
El servidor de presencia (Figura 15.9; p) almacena y gestiona la información de
presencia de la presentidad. Al recibir un mensaje SUBSCRIBE, el servidor
de presencia recuperará la información de presencia de la presentidad de su
base de datos y comprobará si la información ha caducado. Si no lo está,
358 Manual del subsistema multimedia fP (fM£)

el servidor de presencia proporciona la información de presencia al

suscriptor (es decir, al observador). Además, el servidor de presencia
soporta la política de autorización de suscripción, que le permite aceptar o
rechazar una suscripción de los observadores específicos.

Los componentes anteriores están interconectados por varias interfaces definidas

en la especificación 3GPP TS 23.002 [14]. Las interfaces Pw (Figura 15.9; 1,3,4), Pep
(Figura 15.9; 7) y Pwp (Figura 15.9; 6) se implementan en base a SIP y se utilizan para la
entrega de mensajes SIP SUBSCRIBE, NOTIFY y PUBLISH. Las interfaces Pet y Peu
son la interfaz Ut, que se implementa basándose en el protocolo de transferencia de
hipertexto (HTTP) y se utiliza para configurar el servidor de listas de presencia y el
servidor de presencia. La interfaz Px es la interfaz Cx, que se implementa basándose
en el DIAMETRO o parte de aplicación móvil (MAP). El proxy de presencia presentity
utiliza la interfaz Px para recuperar la información de los usuarios desde el HSS.
El flujo de mensajes del servicio de presencia en IMS es diferente al de SIP.
Además de los procedimientos de autenticación definidos en IMS, hay dos
elementos (es decir, el servidor de lista de presencia y el servidor de presencia)
propuestos en el servicio de presencia 3GPP. El servidor de lista de presencia ayuda
a un observador a suscribirse a la información de presencia para los URI de una lista
de amigos, y el servidor de presencia ayuda a un presencial a responder a la
suscripción de presencia. La figura 15.10 ilustra un ejemplo de flujo de mensajes
para el servicio de presencia 3GPP.
En la Figura 15.10, UE1 es un observador y UE2 es un presentista. Supongamos que
UE2 está en la lista de amigos de UE1 (es decir, el URI es UE2@presence_server) y
permite a UE1 suscribirse a su información de presencia. UE1 y UE2 residen en
redes móviles diferentes. En la inicialización, UE2 ha publicado su información en
el servidor de presencia. El procedimiento detallado se describe a continuación:

Pasos 1 y 2. UE1 envía un mensaje SUBSCRIBE al proxy de presencia

watcher a través de la interfaz Pw. Al recibir el mensaje SUBSCRIBE, el proxy
de presencia del vigilante reenvía este mensaje al servidor de listas de
presencia. El servidor de listas de presencia almacena la solicitud de
suscripción y responde con un mensaje 200 OK a UE1 a través del proxy
de presencia vigilante (es decir, P-CSCF y S-CSCF).
Paso 3. A continuación, el proxy de presencia del vigilante recupera la lista de
amigos de UE1 de su base de datos y envía los mensajes SUBSCRIBE a las
URI de la lista de amigos. En este ejemplo, el mensaje se envía al URI de UE2
(es decir, UE2@presence_server). Como UE1 y UE2 residen en redes móviles
diferentes, este mensaje se entrega primero al proxy de presencia de UE2 (es
decir, I-CSCF, S-CSCF y P-CSCF). A continuación, el proxy de presencia de
presencia reenvía el mensaje SUBSCRIBE al servidor de presencia. Al recibir
el mensaje SUBSCRIBE, el servidor de presencia responde con un 200 OK al
servidor de lista de presencia para acusar recibo del mensaje SUBSCRIBE.
Servicio de mensajería instantánea y presencia 359
(fMP£)

Red doméstica de Inicio Red de Presencia

vigilantes
Presencia Vigilante Lista de Presencia
UE1 presencias Presencia Servidor de UE2
Proxy presencia
Servidor Proxy
1
1
SUSCRIBIRSE
1 200
1 200
2
NOTIFICA
R
2 200 OK 2 200 OK
3
SUSCRIBIRSE3
SUSCRIBIRSE

3
SUSCRIBIRSE
3 200 OK
3 200
3 200
4
4
NOTIFICA
R
4 200 OK
4 200 OK
5
5
NOTIFICA
R 5 200
6
6
PUBLICAR
6 200 OK
6 200
7
7
NOTIFICA
R
7 200 OK
7 200
8
8
NOTIFICA
R 8 200

FIGURA 15.10
Flujo de mensajes del servicio de presencia 3GPP.

Paso 4. El servidor de presencia recupera la información de presencia de UE2

de su base de datos y comprueba si el tiempo de vida de la información ha
caducado. Suponiendo que no haya caducado, el servidor de presencia
envía la información de presencia de UE2 al servidor de listas de presencia
mediante un mensaje NOTIFY. A continuación, el servidor de listas de
presencia responde con un 200 OK para acusar recibo del mensaje
NOTIFY.
Tenga en cuenta que el servidor de listas de presencia ha obtenido la
información de presencia de UE2.
Paso 5. Para reducir el consumo de energía, el servidor de listas de presencia
puede fusionar varios mensajes NOTIFY en un solo mensaje y enviar este
mensaje integrado a UE1. Para simplificar, en este ejemplo, el servidor de
listas de presencia envía directamente el mensaje NOTIFY a UE1. Este
mensaje NOTIFY se entrega al proxy de presencia del observador y, a
continuación, a UE1. Al recibir el mensaje NOTIFY, UE1 responde con un
mensaje 200 OK al servidor de listas de presencia.
Paso 6. Supongamos que UE2 cambia el estado de la información de
presencia. UE2 envía un mensaje PUBLISH al servidor de presencia. El
servidor de presencia almacena el estado en su base de datos y responde
con un mensaje 200 OK a UE2.
360 Manual del subsistema multimedia fP (fM£)

Pasos 7 y 8. El servidor de presencia detecta que la información de presencia

de UE2 ha cambiado. El servidor de presencia invoca un mensaje NOTIFY
a UE1. El mensaje NOTIFY se envía al servidor de listas de presencia y
éste lo reenvía a UE1. Al recibir el mensaje NOTIFY, UE1 conoce la
información de presencia de UE2 y responde con un mensaje 200 OK.

Observa que en este ejemplo el servidor de listas de presencia y el servidor de

presencia son servidores con estado y gestionan la información de presencia para el
observador (UE1) y el presenciador (UE2), respectivamente. Con estos dos
servidores, los dos UE tendrán una mayor duración de la batería y un menor
consumo de ancho de banda porque el servidor de listas de presencia y el servidor de
presencia ayudan a los UE a procesar la mayoría de los mensajes en lugar de
reenviarlos a los UE.

Debate y conclusiones
El IMPS es uno de los servicios más populares en las redes all-IP. Los
comportamientos de comunicación originales (por ejemplo, teléfono o correo
electrónico) cambian con el uso del IMPS. Los usuarios de IMPS pueden conocer la
información de presencia de sus amigos y elegir la forma adecuada de contactar con
ellos. Sin embargo, también surgen los problemas del IMPS. En los servicios VoIP,
los mensajes SIP se utilizan para intercambiar información de medios, como
direcciones IP, números de puerto y códecs. Sin embargo, los mensajes instantáneos
basados en SIP utilizan mensajes SIP para entregar los datos de comunicación
reales. Por tanto, los problemas de seguridad de los servicios instantáneos basados
en SIP son mayores que los de otros servicios basados en SIP (por ejemplo, VoIP).
Para resolver este problema, los usuarios de MI pueden utilizar TLS (seguridad de la
capa de transporte) para establecer una conexión segura o S/MIME (MIME de
seguridad) para cifrar el cuerpo del mensaje. Como TLS encripta todo el mensaje
SIP, incluidos los campos de cabecera y el cuerpo del mensaje, cada servidor SIP
debe desencriptar el mensaje SIP y procesar los campos de cabecera. En otras , TLS
es un mecanismo salto a salto. Si el usuario de mensajería instantánea desea
disponer de seguridad de extremo a extremo, deberá utilizar S/MIME para cifrar el
cuerpo del mensaje. Los lectores pueden consultar los documentos RFC 4346 [19], RFC3850
[20] y RFC 3851 [21] para obtener más información sobre TLS y S/MIME.
Basándose en la descripción de este , los principales problemas de presencia
son cómo reducir el número de mensajes de presencia entre un UE y un IMS y cómo
reducir el consumo de ancho de banda. Para la primera cuestión, varias propuestas
[2,3] reducen el número de mensajes SUB- SCRIBE y NOTIFY. Por ejemplo, la
suscripción en estado blando puede cambiarse por la suscripción en estado duro
estableciendo el valor de los campos de cabecera Expires en 232. Además, el servidor
de presencia puede enviar los mensajes NOTIFY sólo cuando cambie la información
de presencia o el estado. En otras palabras, el servidor de presencia no enviará un
mensaje NOTIFY cuando se actualice el tiempo de vida de la información de
presencia.
Servicio de mensajería instantánea y presencia 361
(fMP£)

El tamaño de un documento PIDF simple, que describe el estado de un pre-

sentimiento, es de unos 200-500 bytes. Por ejemplo, cambiar el estado de abierto a
cerrado requiere 275 bytes. En el caso de los documentos aplicados a los for- mats
de extensión [11,12], el tamaño del documento completo puede superar los 1.000
bytes. Para resolver este problema, el servidor de presencia o el UE sólo pueden
notificar o publicar las partes modificadas de un documento [4,7,8]. Esto reducirá el
tamaño de los mensajes NOTIFY y PUBLISH.
En resumen, este capítulo ha utilizado ejemplos para demostrar las extensiones
SIP para mensajería instantánea y servicio de presencia. Además, se ha presentado
la arquitectura de referencia y el flujo de mensajes del servicio de presencia para el
3GPP IMS. Los lectores pueden obtener conocimientos previos de las secciones
anteriores. En la última sección, este capítulo señala los problemas y varias
soluciones existentes; los lectores pueden estudiar estos problemas más a fondo.

Acuse de recibo
El autor agradece a R.-H. Liou por su ayuda en la recopilación de los ejemplos de
este capítulo. Este trabajo ha sido patrocinado en parte por el NSC 96-2218-E-197-
004, el proyecto NCHC y el proyecto MoE.

Referencias
1. Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M.
Handley y E. Schooler. 2002. SIP: Protocolo de iniciación de sesión. RFC 3261, IETF.
2. Khartabil, H., E. Leppanen, M. Lonnfors y J. Costa-Requena. 2006. An extensible markup
language (XML)-based format for event notification filtering, RFC 4661.
3. Khartabil, H., E. Leppanen, M. Lonnfors y J. Costa-Requena. 2006. Func- tional
description of event notification filtering, RFC 4660.
4. Lonnfors, M., J. Costa-Requena, E. Leppanen y H. Khartabil. 2006. Session initiation
protocol (SIP) extension for partial notification of presence information, borrador-ietf-
simple-partial-notify-08.
5. Lonnfors, M., E. Leppanen, H. Khartabil y J. Urpalainen. 2006. Extensión del formato
de datos de información de presencia (PIDF) para presencia parcial, draft-ietf-simple-
partial-pidf-format-08.
6. Niemi, A. 2004. Session initiation protocol (SIP) extension for event state publi- cation,
RFC 3903.
7. Niemi, A. 2006. An extension to session initiation protocol (SIP) events for issu- ing
conditional subscriptions, draft-niemi-sip-subnot-etags-02.
8. Niemi, A., M. Lonnfors y E. Leppanen. 2007. Publicación de información de presencia
parcial, draft-ietf-simple-partial-publish-06.
362 Manual del subsistema multimedia fP (fM£)

9. Roach, A. B. 2006. Session initiation protocol (SIP)-specific event notification, RFC

notification extension for resource lists, RFC 4662.
10. Rosenberg, J. 2004. A presence event package for the session initiation protocol (SIP), RFC
3856.
11. Schulzrinne, H. 2006. CIPID: Información de contacto en formato de datos de
información de presencia, RFC 4482.
12. Schulzrinne, H., V. Gurbani, P. Kyzivat y J. Rosenberg. 2005. RPID: Rich pres- ence
extensions to the presence information data format (PIDF), RFC 4480.
13. Sugano, H., S. Fujimoto, G. Klyne, A. Bateman, W. Carr y J. Peterson. 2004. Presence
information data format PIDF, RFC 3863.
14. 3GPP TS 23.002. Arquitectura de red.
15. 3GPP TS 23.141. Servicio de presencia; Arquitectura y descripción funcional; etapa 2.
16. 3GPP TS 23.228. Subsistema multimedia IP (IMS); etapa 2.
17. Campbell, B., J. Rosenberg, H. Schulzrinne, C. Huitema y D. Gurle. 2002. Session initiation
protocol (SIP) extension for instant messaging, RFC 3428.
18. Klyne, G., y C. Newman. 2002. Fecha y hora en Internet: Timestamps, RFC 3339.
19. Dierks, T., y E. Rescorla. 2006. Protocolo de seguridad de la capa de transporte (TLS)
versión 1.1, RFC 4346.
20. Ramsdell, B., Ed. 2004. Secure/multipurpose Internet mail extensions (S/ MIME)
version 3.1 certificate handling, RFC 3850.
21. Ramsdell, B., Ed. 2004. Secure/multipurpose Internet mail extensions (S/ MIME)
version 3.1 message specification, RFC 3851.
16
Servicios £ multipartitos en el
subsistema fP Multimedia

Iván Vidal, Ignacio Soto, Francisco Valera, Jaime

García y Arturo Azcorra

CONTENIDO
Introducción ...................................................................................................................... 363
Consideraciones sobre los servicios multipartitos en IMS......................................... 364
Funcionalidades de Control de Sesión en Escenarios Multipartitos ......................... 366
Establecimiento de la sesión ................................................................................... 367
Enrutamiento de la señalización SIP ......................................................... 367
Negociación de la descripción de la sesión ............................................370
Configuración del Servicio de Entrega Multicast habilitado para QoS
..................................................................................................... 374
Suscripción a grupos multicast en el equipo de usuario iniciador ........ 376
Conclusión de la sesión Establecimiento ................................................ 376
Notificación del estado de la sesión multimedia multipartita ............. 377
Anulación del establecimiento de sesión.................................................................378
Liberación de la sesión ............................................................................................ 380
Conclusiones ...................................................................................................................... 381
Referencias ........................................................................................................................ 382

Introducción
El desarrollo y despliegue de las nuevas redes celulares de tercera generación (3G)
han introducido un nuevo paradigma de comunicación en el mercado de las
telecomunicaciones. Se ofrecen nuevas infraestructuras de acceso de banda ancha a
los usuarios finales, que pueden acceder a una gran variedad de nuevos servicios con
independencia de su ubicación. En este contexto, el IP desempeña un papel clave, ya
que soporta el transporte de datos en las comunicaciones en las que intervienen
equipos móviles de usuario (UE), que obtienen acceso a Internet a través del
dominio de paquetes en la red 3G. De este modo, el final puede acceder a cualquier
servicio de Internet como si fuera un usuario de red fija.

363
364 Manual del subsistema multimedia fP (fM£)

acceso de banda ancha (por ejemplo, una línea de abonado digital, xDSL). Ejemplos
de estos servicios son la navegación por Internet, el correo electrónico o las
aplicaciones de descarga de contenidos. De este modo, el dominio de paquetes en
redes 3G hace posible la convergencia entre Internet y el mundo celular.
El paradigma de la comunicación de datos en las redes 3G introduce la posibilidad
de establecer una comunicación IP directa entre dispositivos móviles. Esta
funcionalidad, ya presente en el entorno de Internet, abre nuevas y apasionantes
posibilidades en el desarrollo de servicios y aplicaciones de próxima generación
para el ámbito de las comunicaciones móviles. En particular, permite aplicaciones
peer-to-peer para la comunicación entre usuarios en el mundo móvil. Además, la
introducción del IMS (subsistema multimedia IP) en el dominio de paquetes del
sistema de telecomunicaciones de modo universal (UMTS) proporciona las
funcionalidades de control necesarias para ofrecer servicios multimedia con
requisitos de calidad de servicio (QoS), servicios que tradicionalmente se han
ofrecido a través de redes con conmutación de circuitos.
Por otra parte, varios servicios que se están definiendo actualmente para las redes
UMTS implican el intercambio de medios no sólo entre pares de usuarios, sino
también entre varios usuarios. En este capítulo nos centraremos en estos servicios
multipartitos. Algunos ejemplos son los servicios push-to-talk y de conferencia. Sin
embargo, las especificaciones desarrolladas hasta la fecha por el 3rd Generation
Partnership Project (3GPP) no proporcionan un mecanismo general para soportar la
negociación de estos servicios, ya que las soluciones presentadas actualmente son
específicas para cada servicio. Además, en estas soluciones se considera un enfoque
basado en unidifusión para entregar los medios en el plano de usuario, normalmente
enviando la información a un nodo central donde se replica para cada participante en
el servicio. Esta solución, como mostraremos en este capítulo, presenta problemas
de eficiencia relacionados con el uso de recursos portadores en las redes de
transporte.
El resto de este capítulo se estructura como sigue. La sección siguiente
detalla algunas consideraciones generales sobre la especificación actual de los
servicios multipartitos que se desarrollan en el ámbito de IMS. Se describe aquí un
enfoque alternativo para la implementación de estos servicios y se analizan las
principales ventajas e inconvenientes relacionados con esta solución. En
"Funcionalidades de control de sesión en escenarios multipartitos" se especifican los
procedimientos de señalización del protocolo de iniciación de sesión (SIP)
necesarios en el plano de control para la implementación de la solución presentada.
Finalmente, la última sección describe las principales conclusiones de este capítulo.

Consideraciones sobre los servicios multipartitos en IMS

La arquitectura IMS se ha definido para proporcionar al usuario acceso a una amplia
gama de servicios, que se implementan mediante servidores de aplicaciones (AS).
Además, las funcionalidades de control de sesión permiten el establecimiento de
sesiones multimedia entre los equipos de usuario, sobre las que se pueden establecer
comunicaciones avanzadas entre pares.
Servicios £ multipartitos en el subsistema fP Multimedia 365

Pueden prestarse servicios entre pares (por ejemplo, telefonía o videoconferencia).

Estos servicios implican la transmisión directa de medios entre las partes
participantes en el servicio en el plano de datos.
Por otro lado, algunos de los servicios que se prevén en el futuro de las redes
móviles 3G implican el intercambio de medios entre múltiples partes partícipes.
Ejemplos típicos de estos servicios son los de pulsar para hablar y los de
conferencia. Sin embargo, las especificaciones desarrolladas actualmente por el
3GPP para estos servicios no admiten la provisión de una plataforma genérica capaz
de prestar eficientemente estos servicios al usuario final.
Por un lado, las especificaciones desarrolladas actualmente para el IMS no
contemplan funcionalidades de control de sesión para sesiones multimedia que
impliquen el intercambio de información entre múltiples participantes. Por tanto, el
IMS no soporta el establecimiento de una sesión multimedia entre múltiples UEs, y
normalmente los procedimientos asociados al control de sesión en servicios
multiparte dependen del servicio. Este hecho se traduce en un incremento del coste
asociado al desarrollo de nuevos servicios multipartitos, lo que finalmente podría
afectar a las futuras oportunidades de despliegue.
Por otro lado, las especificaciones desarrolladas por el 3GPP para servicios
multipartitos siguen considerando un esquema de transmisión basado en tecnologías
unicast para los medios en el plano de usuario. En este esquema, el tráfico de datos
se envía desde cada UE a un nodo central, donde se replica y transmite utilizando un
transporte unicast a cada UE participante en el servicio. Esta solución suele
aumentar la carga de tráfico en la red y ofrece soluciones menos escalables en
términos de usuarios y servicios.
El desarrollo de nuevas funcionalidades de control de sesión en el IMS para
apoyar la gestión de sesiones multimedia entre múltiples UEs proporciona un
mecanismo flexible que facilita el desarrollo de nuevos servicios multiparte en el
entorno de red móvil 3G. Estas nuevas funcionalidades permiten establecer una
sesión multimedia entre múltiples UEs en el IMS. En esta sesión multimedia se
puede prestar el servicio multipartito. De este modo, ya no son necesarios
procedimientos de control específicos para cada servicio, lo que supone una
solución rentable en términos de desarrollo.
Por otra parte, los problemas relacionados con el incremento de la carga de tráfico
en la red resultante de la replicación del tráfico a múltiples destinos pueden
minimizarse utilizando tecnologías de transmisión basadas en la multidifusión a
nivel de red. La introducción de estas técnicas de multidifusión a nivel de red
presenta varias ventajas:

• una mayor eficiencia de transmisión en las redes troncales que

interconectan los distintos nodos de soporte GPRS (servicio general de
radiocomunicaciones por paquetes) de pasarela (GGSN), así como en las
redes centrales y de acceso radioeléctrico UMTS. Al utilizar la
multidifusión a nivel de red, los paquetes IP se distribuyen adecuadamente
por las redes troncales, replicándose sólo si es realmente necesario. En las
redes centrales y de acceso radioeléctrico UMTS, los medios podrían
transmitirse desde los GGSN a los UE mediante contextos compartidos del
protocolo de paquetes de datos (PDP);
366 Manual del subsistema multimedia fP (fM£)

• mejor escalabilidad, en términos de usuarios y servicios, como

consecuencia lógica del punto anterior y debido a que en la multidifusión a
nivel de red no existe un nodo central que reciba todo el tráfico de datos (lo
que podría convertirse en un cuello de botella);
• mejor tolerancia a los fallos. En el de unidifusión, el tráfico de datos se
envía a un nodo central que replica los medios, por lo que se convierte en
un punto aislado de fallo. En el enfoque basado en multidifusión a nivel de
red, el tráfico de datos se distribuye adecuadamente a través de las redes
troncales hacia los GGSN que prestan servicio al UE, sirviendo como
mecanismo de enrutamiento multidifusión encargado de proporcionar la
robustez necesaria ante fallos en nodos y enlaces; y
• compatibilidad con los servicios de Internet basados en tecnologías de
entrega multicast a nivel de red (estos servicios podrían entregarse
directamente al UE en el entorno UMTS).

Sin embargo, el uso de tecnologías de entrega multicast a nivel de red para la

transmisión de tráfico de datos en el plano de usuario implica que los GGSNs deben
implementar el soporte del protocolo de gestión de grupos de Internet (IGMP) [2],
permitiendo así al UE indicar su disposición a recibir los medios correspondientes a
grupos multicast específicos, así como algunos mecanismos de enrutamiento
multicast, por ejemplo, el modo de multidifusión disperso independiente del
protocolo (PIM-SM) [3]. Esto puede aumentar la carga de procesamiento en cada
GGSN, pero en general disminuye la carga de tráfico recibida en un GGSN cuando
atiende a varios UE que participan en el mismo servicio.
Vidal et al. [4] proponen extensiones a las funcionalidades de control de sesión en
el IMS para soportar un escenario multipartito y describen un procedimiento
genérico de establecimiento de sesión que permite establecer una sesión multimedia
entre múltiples participantes. En [4], los medios se distribuyen en el plano de
usuario mediante tecnologías de entrega multicast a nivel de red. La siguiente
sección muestra una visión general de esta propuesta y la amplía con el resto de
funcionalidades de control de sesión que son necesarias para gestionar sesiones
multimedia en el IMS en las que participan múltiples UEs.

Funciones de control de sesión en escenarios multipartitos

Esta sección cubre las extensiones a los procedimientos de control de sesión que se
describen en las especificaciones 3GPP para el IMS ([1] y [5]), con el fin de
soportar el control de sesiones multimedia en las que participan múltiples UEs.
Estas sesiones multimedia soportan la implementación de servicios peer-to-peer (por
ejemplo, videoconferencia) donde el tráfico de datos se intercambia en el plano de
usuario, entre los UEs participantes en el servicio, mediante tecnologías multicast a
nivel de red. En esta sección asumimos que una conectiv- dad IP 3GPP.
Servicios £ multipartitos en el subsistema fP Multimedia 362

(IP-CAN), con una red de acceso de radio terrestre UMTS (UTRAN) y el dominio
de paquetes UMTS. Además, se asume que cada UE que participa en una sesión
multimedia multiparte ha establecido un contexto PDP de señalización dedicado
para soportar el intercambio de mensajes de señalización SIP entre el UE y su
correspondiente función de control de sesión de llamada proxy (P-CSCF).
El resto de esta sección se organiza como sigue. En la siguiente subsección, se
describen las extensiones de las funcionalidades de control IMS relacionadas con los
procedimientos de establecimiento de sesiones multimedia. La siguiente subsección
indica los procedimientos asociados con la cancelación del proceso de
establecimiento de sesión, por ejemplo, debido a la falta de recursos en las redes de
transporte. Por último, "Liberación de sesión" cubre los procedimientos de
liberación de la sesión multimedia iniciada por la red o por el equipo de usuario.

Establecimiento de la sesión
En esta sección se describen los procedimientos para ampliar la señalización de
control IMS con el fin de apoyar el establecimiento de sesiones multimedia entre
varios usuarios. Al igual que en una sesión IMS normal establecida entre dos UE, lo
primero que debe hacer el UE iniciador para establecer la sesión multimedia es crear
un diálogo SIP. Este diálogo se utiliza para permitir la ejecución de los
procedimientos de control de sesión adecuados, proporcionando una relación de
señalización entre el UE iniciador y el resto de UEs implicados en el servicio. Esta
relación de señalización soportará la negociación de las características de los
diferentes componentes de medios que se intercambiarán durante la sesión. Como se
verá en este subapartado, esto permitirá dos procedimientos fundamentales:

• la reserva de los recursos de calidad de servicio necesarios en el plano de

usuario para la correcta entrega de cada componente multimedia; y
• la configuración del servicio de entrega multidifusión a nivel de red para
cada componente multimedia de la sesión multimedia multipartita.

La figura 16.1 muestra, el punto de vista del UE iniciador, la señalización SIP

correspondiente a las funcionalidades de establecimiento de sesión que se describen
en este subapartado. La figura 16.2 muestra estos procedimientos desde el punto de
vista de cada UE de destino.

Enrutamiento de la señalización SIP

Para establecer el diálogo SIP, el UE del usuario iniciador debe enviar una petición
INVITE a los UEs que pertenecen a los usuarios finales que quiere involucrar en la
ejecución del servicio (punto 1 en las figuras 16.1 y 16.2). Esta solicitud INVITE
contendrá la lista de identificadores uniformes de recursos SIP (URI) que
corresponden a los usuarios finales con los que se desea contactar. Cada URI SIP es
una identidad pública de usuario en el IMS. La petición INVITE contiene también el
URI SIP donde
368 Manual del subsistema multimedia fP (fM£)

UE P-CSCF S-CSCF AS

(1) INVITE INVITE INVITE

La INVITE se replica para
cada usuario de destino

INVITE
INVITE Enviar a cada UE de destino
Sess. Cada UE de destino
(2)
Progreso
responde
Sess. Progreso con un S. Progress

Evaluación la respuesta SDP

Sess. Sess. Progreso

Sess.
(3) Progreso Progreso
PRACK PRACK
PRACK
PRACK se replica para
cada usuario de destino

PRACK
Reserva de recursos PRACK Enviar a cada UE de destino
y suscripción a OK Cada UE de destino
grupos de OK
multidifusión responde con un OK
(4
)

Evaluación de la

OK respuesta SDP OK
OK
ACTUALI ACTUALI
(5) ACTUALIZACIÓN
ZACIÓN
ZACIÓN UPDATE se replica para cada
usuario de destino

ACTUALIZACIÓN
ACTUALI Enviar a cada UE de destino
ZAR
OK (6) Primera respuesta OK
OK recibida
Evaluación de la
carga útil SDP en la
OK respuesta OK
OK
OK (7)
Primera respuesta RINGING
ANILLO recibida
ANILLO ANILLO TIMBRE
TIMBRE (8)
Primera respuesta OK
OK recibida a la solicitud
(INVITAR) OK (INVITAR) INVITE

Evaluación la respuesta SDP

OK OK
OK (INVITAR) (9)
(INVITAR) (INVITAR)
NOTIFICAR
(10) NOTIFICAR NOTIFICAR
(11) ACK ACK ACK
OK OK OK
El ACK se replica para
cada usuario de destino

ACK
ACK Enviar a cada UE de destino

FIGURA 16.1
Establecimiento de sesión, lado iniciador.

el UE iniciador desea ser contactado para más peticiones en el diálogo; este SIP URI
se indica en la cabecera de contacto de la petición. La solicitud se enruta a la
función de control de sesión de llamada de servidor (S-CSCF) asignada al usuario
iniciador, pasando por la P-CSCF, mediante los mecanismos de enrutamiento
habituales en el IMS.
La S-CSCF realiza los procedimientos de provisión de servicios. Estos
procedimientos consisten en comprobar el contenido de la solicitud INVITE con
Servicios £ multipartitos en el subsistema fP Multimedia 362

respecto a un conjunto de parámetros.

Servicios £ multipartitos en el subsistema fP Multimedia 369

I-CSCF S-CSCF P-CSCF UE

Solicitud INVITE
INVITE INVITE
Recibido INVITE INVITE (1)

Enviar al Sess. Progreso Sess. Progreso (2)

Sess. Progreso Sess. Progreso
iniciador
UE
Solicitud PRACK PRACK PRACK (3)
PRACK recibida

Enviar al OK (4)
iniciador OK OK
OK
UE
Reserva de recursos

Solicitud de ACTUALI (5)

ACTUALIZACIÓN ACTUALI ACTUALI
ZACIÓN ZACIÓN
Recibido ZACIÓN
Enviar al OK (6)
iniciador OK OK
UE (7)
Enviar al ANILLO Destino UE
ANILLO ANILLO Alerta al
iniciador
UE usuario

el
(10) Establecimien
Enviar al OK (INVITE) OK (INVITE) to de la
iniciador OK (INVITE)
Sesión
UE y el UE se suscribe a
Solicitud ACK ACK ACK los grupos de
ACK (11)
recibida

FIGURA 16.2
Establecimiento de sesión, lado de destino.

criterios de filtrado asociados a la identidad pública del usuario iniciador. Como

resultado de esta comprobación, la S-CSCF verificará que la petición INVITE debe
ser procesada en un servidor de aplicaciones específico para aplicaciones multiparte:
el servidor de aplicaciones multiparte (MAS). Los criterios de filtrado pueden
definirse de forma que se compruebe si el método de la petición es INVITE, el caso
de la sesión es originando, y la petición INVITE contiene una lista de URIs SIP.
El MAS es un agente de usuario SIP back-to-back (B2BUA), tal y como se define
en Rosen- berg et al. [6]. Se compone de un agente de usuario cliente (UAC) y un
agente de usuario servidor (UAS). Ambos UAs están conectados por cierta lógica
específica del servicio. La Fig. 16.3 muestra la arquitectura funcional de la B2BUA.
Tras recibir la petición INVITE, la B2BUA realiza las siguientes acciones:

• Genera un SIP URI que identifica de forma única la sesión multimedia

multiparte. La cabecera de contacto de la solicitud INVITE se establece en
este URI SIP.
• Asigna una dirección IP multicast a cada componente multimedia definido
en la oferta del protocolo de descripción de sesión (SDP). De este modo,
cada componente multimedia se asigna a un grupo multidifusión. Esto
permite que diferentes equipos de usuario de destino con diferentes
capacidades acepten y se suscriban a los componentes de medios que
admiten y pueden aceptar. Cada dirección IP de multidifusión permanecerá
asignada a un componente multimedia mientras la sesión multimedia
multipartita siga establecida.
320 Manual del subsistema multimedia fP (fM£)

B2BUA

Lógica de servicio

Solicitud SIP Solicitud SIP UAS

UAC UAS UAC
Respuesta SIP Respuesta SIP

FIGURA 16.3
Arquitectura funcional B2BUA.

• Replica la solicitud INVITE para cada identidad de usuario pública indicada

en la lista de URI SIP. Para cada solicitud INVITE generada, el URI de
destino (campo Request-URI en la línea de inicio) se establece en el URI
SIP correspondiente a la réplica.

Por último, cada solicitud INVITE se encamina correctamente a su destino mediante

los procedimientos habituales de enrutamiento IMS.
Cuando un equipo de destino recibe la solicitud INVITE, responde con una
respuesta de sesión SIP en curso. Esta respuesta contiene una cabecera de contacto, que
indica el URI SIP en el que el UE de destino desea ser contactado para futuras
solicitudes en el diálogo. La respuesta de sesión en curso se reenvía a la MAS mediante los
procedimientos de enrutamiento habituales del IMS. Como se explicará más , la
MAS espera a recibir todas las respuestas de sesión en curso de los equipos de
destino. Cada respuesta recibida de un equipo de usuario establece un diálogo SIP
entre la MAS y los equipos de usuario.
Con todas estas respuestas, el MAS genera una única respuesta de sesión en
curso, que se envía al UE iniciador. En esta respuesta, la cabecera de contacto se
establece en el URI SIP que se ha creado previamente para la sesión multimedia
multiparte. Esta respuesta de sesión en curso genera a su vez un diálogo de
señalización SIP entre el MAS y el UE iniciador.
Por lo tanto, el intercambio INVITE-Session in Progress crea un diálogo de señalización
SIP entre el MAS y cada equipo de usuario que participa en la sesión multimedia
multipartita. Estos diálogos se utilizarán para enrutar otras solicitudes SIP enviadas
durante la ejecución de los procedimientos de control asociados a la sesión
multimedia multipartita.

Negociación de la descripción de la sesión

Durante el procedimiento de establecimiento de sesión, los UE participantes deben
llegar a un acuerdo sobre la descripción de los diferentes componentes multimedia
que formarán parte de la sesión multimedia multipartita. Para ello, en el IMS se
utiliza el SDP [7] y el modelo de oferta/respuesta [8] del SDP. En Vidal et al. [4], se
describe una propuesta que, siguiendo las especificaciones contenidas
Servicios £ multipartitos en el subsistema fP Multimedia 321

Iniciador
MAS
UE

INVITE
1ª oferta PDE INVITE
A cada UE de destino
1ª oferta PDE
Sesión en Primera sesión en curso
1ª respuesta SDP recibida
e MAS espera hasta
recibir todas las
respuestas de Session in
Progess

Sesión en curso
1ª respuesta SDP combinada
PRACK
2ª oferta PDE PRACK
A cada UE de destino
2ª oferta PDE
OK
Primer OK recibido
2ª respuesta SDP

e MAS espera a
recibir suficientes
respuestas OK para
confirmar cada
componente
multimedia

OK
2º PDE Combinado Respuesta

FIGURA 16.4
Negociación de la descripción de la sesión.

en Rosenberg y Schulzrinne [8], soporta la negociación de la sesión multimedia

multipartita. Esta propuesta se indica brevemente a continuación (en la Figura 16.4
se muestra una visión general):

• El UE iniciador incluye una oferta SDP en la solicitud INVITE. La oferta

describe los componentes multimedia que el iniciador desea intercambiar
en la sesión multimedia multiparte. Para cada componente multimedia, el
UE iniciador incluye, entre otras cosas, la lista de formatos admitidos (por
ejemplo, códecs), los requisitos de ancho de banda y la información de
direccionamiento (es decir, el puerto de transporte al que debe transmitirse
el componente multimedia). La oferta SDP es modificada por el MAS, que
incluye una dirección IP multicast para cada componente multimedia. Por
último, la oferta SDP modificada se incluye en cada solicitud INVITE
enviada a los UE de destino.
• Cada UE de destino responde a la oferta SDP con una respuesta SDP, que
se incluye en una respuesta de sesión SIP en curso. En esta respuesta SDP,
el equipo de destino puede descartar cualquier componente multimedia
(poniendo el puerto de transporte a cero). Para cada componente de medio
aceptado,
322 Manual del subsistema multimedia fP (fM£)

el UE de destino indica en la respuesta SDP el conjunto de formatos

soportados de entre los que estaban presentes en la oferta. Dado que el
mensaje Sesion in Progress es una respuesta provisional SIP, no se envía de forma
fiable según los procedimientos SIP habituales. Para resolver este problema,
en el IMS se utiliza una extensión del protocolo SI definida por el Internet
Engineering Task Force (IETF) en Rosenberg y Schulzrinne [9]. De esta
forma, la respuesta de sesión en curso se envía de forma fiable al equipo de
usuario de destino.
• Las respuestas de sesión en curso se reenvían a la MAS. Cuando esta entidad
funcional recibe todas las respuestas, genera una nueva respuesta de sesión
en curso para la solicitud INVITE recibida del equipo de usuario iniciador.
Esta respuesta SIP contiene una respuesta SDP, formada por la
combinación de las diferentes respuestas SDP recibidas de los UE de
destino. Esta respuesta SDP se genera de la siguiente manera
• Para cada componente multimedia incluido en la oferta SDP, si alguna
respuesta SDP acepta el componente multimedia, entonces se descarta
en la respuesta SDP combinada. En caso contrario, se acepta el
componente multimedia.
• Para cada componente multimedia aceptado, el MAS obtiene los
formatos que se indicarán en la respuesta SDP combinada. Sólo se
incluirán en la aquellos formatos que hayan sido aceptados por todos
los equipos de usuario que hayan aceptado el componente multimedia.
Si no hay formatos comunes para un componente multimedia, éste se
descarta en la respuesta SDP combinada.
• Por último, la respuesta SDP incluye, para cada componente de
medios, la dirección IP multidifusión asignada previamente por el
MAS.
La MAS espera hasta un tiempo preconfigurado, Ts-prog, para recibir
todas las respuestas de Sesión en curso. Una vez transcurrido el
tiempo, la MAS genera la respuesta de sesión en curso con las
respuestas SDP recibidas hasta ese momento. Si no se recibe una
respuesta de sesión en curso de un equipo de destino, éste
simplemente se elimina de la lista de participantes en la sesión
multipartita.
• Tras recibir la respuesta de sesión en curso de la MAS (que contiene la
respuesta SDP combinada), el equipo de usuario iniciador genera una
segunda oferta SDP, de acuerdo con los siguientes procedimientos:
• Para cada componente multimedia aceptado en la respuesta SDP
combinada, se selecciona un único formato de entre los contenidos en
la respuesta. Cada uno de estos componentes de medios se incluye en
la segunda oferta SDP con el formato seleccionado. El componente de
medios también incluye información sobre los requisitos de ancho de
banda, la dirección IP de multidifusión asignada por el MAS y el
puerto que se indicó en la primera oferta SDP.
Servicios £ multipartitos en el subsistema fP Multimedia 323

• Si un componente multimedia se descarta en la respuesta SDP

combinada, también se descarta en la segunda oferta SDP.
Según Rosenberg y Schulzrinne [9], la recepción de la respuesta Session
in Progress debe confirmarse con una petición PRACK (punto 3 en las
figuras 16.1 y 16.2). Esta petición PRACK se utiliza para enviar la
segunda oferta SDP. Por lo tanto, la selección de un único formato
para cada componente de medios implica un segundo intercambio
de oferta/respuesta SDP. Este intercambio es necesario porque, si
se seleccionaran varios formatos, la reserva de recursos tendría que
hacerse para el más restrictivo (el que demande más recursos),
aunque probablemente se utilice finalmente un formato menos
restrictivo en la sesión.
• Tras recibir la solicitud PRACK, el MAS genera una nueva solicitud PRACK para
cada UE de destino que siga participando en la sesión multipartita. Cada
solicitud PRACK incluye una segunda oferta SDP, que se genera de forma
independiente para cada UE de destino siguiendo el siguiente esquema:
• Un componente multimedia será propuesto en la segunda oferta SDP si
ha sido aceptado por el UE de destino en la primera respuesta SDP y si
aparece como propuesto en la segunda oferta SDP recibida del UE
iniciador. La descripción del componente multimedia es la que se
recibió del UE iniciador en la segunda oferta SDP.
• En caso contrario, el componente multimedia se descarta en la segunda
oferta SDP.
• Cada UE de destino recibe la solicitud PRACK que contiene la segunda
oferta SDP. Finalmente, cada UE acepta esta oferta SDP y la confirma con
una segunda respuesta SDP. Esta respuesta SDP se incluye en la respuesta
SIP OK a la petición PRACK (punto 4 de las figuras 16.1 y 16.2).
• Por último, las respuestas OK, cada una de las cuales contiene una
respuesta SDP, se reciben en la MAS. La MAS esperará hasta que reciba
suficientes respuestas SDP para confirmar que cada componente de medios
que fue aceptado previamente por el UE iniciador en la segunda oferta SDP
es aceptado por al menos un UE de destino. Cuando esto ocurre, la MAS
genera una segunda respuesta SDP combinada. Esta respuesta SDP acepta todos
los componentes multimedia propuestos previamente por el equipo de
usuario iniciador en la segunda oferta SDP. La descripción de cada
componente de medios aceptado es la indicada por el equipo de usuario
iniciador en dicha oferta.
• El MAS envía la respuesta SDP combinada en una respuesta SIP OK al UE
iniciador. Si, después de un tiempo de espera predefinido, Tok, el MAS no
ha recibido suficientes respuestas SDP para confirmar todos los
componentes de medios, se asume que la ruta de comunicación a los UE de
destino que aceptaron los componentes de medios no confirmados no está
disponible.
324 Manual del subsistema multimedia fP (fM£)

ya no está disponible, y la respuesta SDP combinada descarta esos com-

ponentes. Además, este conjunto de equipos de usuario se elimina de la
lista de equipos de usuario participantes.

Una mejora de este esquema, en caso de que no hubiera formatos comunes para
un componente multimedia específico entre todos los equipos de usuario
participantes, consistiría en seleccionar el conjunto de formatos que maximizara el
número de equipos de usuario de destino capaces de intercambiar el componente.
Otra solución más compleja podría consistir en introducir facilidades de
transcodificación en el plano de usuario.

Configuración del servicio de entrega multidifusión con QoS habilitada

Una vez concluida la negociación de la descripción de la sesión, el equipo de
usuario de cada participante ha llegado a un acuerdo sobre los distintos parámetros
que describen los componentes multimedia que forman parte de la sesión
multimedia multipartita. A continuación, cada UE debe activar los contextos PDP
necesarios para transportar el tráfico asociado a cada componente multimedia que ha
acordado intercambiar y garantizar que se proporciona la QoS necesaria a cada uno
de ellos. Así, la activación de contextos PDP es un proceso de reserva de recursos,
que se inicia por separado desde cada UE. Específicamente, será iniciado por el UE
iniciador después de enviar la petición PRACK; del mismo modo, será iniciado por
cada UE de destino después de enviar la respuesta OK a la petición PRACK.
Cada UE activará hasta dos contextos PDP para cada componente multimedia que
haya acordado intercambiar:

• un contexto PDP secundario para la transmisión del tráfico asociado con el

componente multimedia en la dirección del enlace ascendente (es decir,
desde el UE al GGSN); y
• un contexto PDP compartido para la transmisión del tráfico de datos
asociado al componente multimedia en la dirección del enlace descendente
(es decir, desde el GGSN al UE). Este contexto PDP será compartido entre
todos los equipos de usuario participantes que, siendo servidos por el
mismo GGSN, activen el contexto PDP. De este modo, el tráfico
multidifusión asociado a un componente de medios se distribuye de forma
eficiente en las redes de acceso radioeléctrico y de núcleo UMTS.

Así, el esquema propuesto proporciona una reserva de recursos eficiente para la

sesión multimedia multipartita por las siguientes razones:

• Cada UE realiza una reserva de recursos independiente para cada

componente multimedia, basada en la activación de contextos PDP. De este
modo, el equipo de usuario puede reservar de la red de transporte los
recursos de calidad de servicio estrictamente necesarios para la correcta
entrega de los componentes multimedia que ha acordado intercambiar.
Servicios £ multipartitos en el subsistema fP Multimedia 325

• A cada componente de medios se le asignan los recursos de QoS realmente

necesarios mediante (posiblemente) un contexto PDP de enlace ascendente
y un contexto PDP de enlace descendente compartido.

No obstante, la activación de un contexto PDP puede fallar, por ejemplo, debido a

la falta de recursos en la red de acceso radioeléctrico. Por lo tanto, el
establecimiento de la sesión no puede completarse con éxito hasta que el proceso de
reserva de recursos haya concluido correctamente. En general, podemos afirmar que,
en un servicio multipartito, la activación de los contextos PDP necesarios debe ser
completada con éxito por el UE iniciador y un UE de destino antes de alertar al
usuario de destino correspondiente de la sesión entrante. Esta restricción garantiza
que ya se ha realizado una reserva adecuada de QoS de extremo a extremo cuando
un usuario es alertado por su UE, asegurando así que la sesión puede establecerse
entre éste y el UE iniciador.
En una sesión IMS regular uno a uno, también se impone esta restricción, que se
hace cumplir mediante una extensión SIP definida por el IETF en Camarillo,
Marshall y Rosenberg [10] y Camarillo y Kyzivat [11]. Esta extensión permite
integrar los mecanismos de reserva de recursos en la ejecución del protocolo SIP.
Para , se inserta cierta información, conocida como precondiciones, en las cargas
útiles SDP de los mensajes SIP intercambiados entre los UEs iniciador y destino.
Esta información describe las restricciones de QoS que deben cumplirse
previamente para completar el establecimiento de la sesión. Por lo tanto, el UE de
destino retrasa el proceso de alerta del usuario de destino (y por lo tanto el
establecimiento de la sesión) hasta que se cumplan todas sus precondiciones y las
precondiciones indicadas por el UE iniciador.
En el escenario multipartito, este mecanismo de condiciones previas también se
utiliza siguiendo, entre otros, los procedimientos que se explican a continuación:

• El UE iniciador incluye condiciones previas en la oferta SDP de la primera

solicitud INVITE. El no modifica estas condiciones previas al generar la
solicitud INVITE para cada UE de destino.
• Cada UE de destino incluye precondiciones en la respuesta SDP contenida
en la respuesta de sesión en curso. En esta , cada UE también indica su
deseo de recibir una confirmación del UE iniciador al completar el
procedimiento de reserva remota de recursos. El MAS no modifica estas
precondiciones en la primera respuesta SDP combinada.

Por último, si la reserva de recursos concluye con éxito en el lado del iniciador, el
UE iniciador envía una nueva oferta SDP, indicando que las condiciones previas
para la sesión multimedia multipartita se han cumplido en su lado. Esta oferta SDP
se incluye en una solicitud SIP UPDATE que se envía al MAS (punto 5 de las
figuras 16.1 y 16.2). La MAS genera una nueva solicitud UPDATE para cada UE de
destino. A su vez, cada UE de destino responde a la solicitud UPDATE con una
respuesta SIP OK (punto 6 de las figuras 16.1 y 16.2), que se envía a la MAS (punto
5 de las figuras 16.1 y 16.2).
326 Manual del subsistema multimedia fP (fM£)

también contiene una respuesta SDP que indica el estado de la reserva de recursos
en el lado de destino. El MAS envía una respuesta OK a la solicitud UPDATE
enviada por el usuario iniciador una vez que recibe la primera respuesta OK de un
UE de destino.
Cuando un usuario de destino finaliza su reserva de recursos locales y una vez que
recibe la solicitud UPDATE, puede reanudar el proceso de establecimiento de sesión.

Suscripción a grupos de multidifusión en el equipo de usuario iniciador

Tras enviar la solicitud UPDATE, el equipo de usuario iniciador puede a los grupos
de multidifusión asociados a los componentes multimedia que ha acordado
intercambiar. Para ello, el UE iniciador utiliza el protocolo IGMP ejecutado entre el
GGSN y el UE. Los mensajes IGMP se intercambiarán a través del contexto PDP de
señalización dedicado. El GGSN, a su vez, deberá ejecutar algún protocolo de
enrutamiento multicast (por ejemplo, PIM-SM) para solicitar la recepción de los
medios correspondientes a los grupos multicast cuya suscripción solicitan los UEs
servidos.

Conclusión de la sesión Establecimiento

Suponiendo que un UE de destino ha concluido su reserva de recursos locales y ha
recibido la solicitud UPDATE, puede continuar con el procedimiento de
establecimiento de sesión. En este punto, el UE de destino puede, opcionalmente,
empezar a alterar el usuario de destino (por ejemplo, reproduciendo algún tono de
llamada en el UE). En ese caso, envía una respuesta SIP RINGING a la petición
INVITE hacia el MAS (punto 7 en las figuras 16.1 y 16.2).
La MAS, tras recibir este mensaje SIP, generará una nueva respuesta RINGING
que será enviada hacia el UE iniciador. La recepción de futuras respuestas RINGING
de los UEs de destino no implicará la generación de más mensajes de señalización
SIP en la MAS.
Por último, cuando la sesión es aceptada por un usuario de destino, su UE realiza
las siguientes acciones:

• Se suscribe a los grupos multidifusión asociados a los componentes

multimedia que ha acordado intercambiar.
• Envía una respuesta SIP OK a la solicitud INVITE hacia la MAS, indicando
que la sesión se ha establecido en el lado de destino (punto 8 en las figuras
16.1 y 16.2).

Tras recibir el primer mensaje SIP OK, el MAS genera una nueva respuesta OK
que se envía al UE iniciador. Así, desde el punto de vista del UE iniciador, esta
respuesta significa que al menos un destino ha aceptado la sesión multimedia
multipartita y que puede iniciarse la transmisión de medios multidifusión en el plano
de usuario. Por último, el equipo de usuario de destino confirma
Servicios £ multipartitos en el subsistema fP Multimedia 322

la recepción de la respuesta OK con una solicitud SIP ACK (punto 10 en las Figuras
16.1 y 16.2).

Notificación del estado de la sesión multimedia multipartita

En este punto, la sesión multimedia se ha establecido entre el UE iniciador y un UE
de destino. El problema ahora es que la respuesta SIP OK, recibida por el UE
iniciador, no contiene carga útil SDP y, por lo tanto, no hay información disponible
en este momento en el lado del iniciador sobre los componentes multimedia
aceptados por el UE de destino. Para resolver este problema, se utiliza el marco de
notificación de eventos específico de SIP (véase Roach [12]). Este mecanismo
permite a una entidad suscribirse a la información de estado asociada a un recurso.
La entidad que realiza el seguimiento del estado del recurso envía una solicitud
NOTIFY que contiene la información de estado solicitada. Si el estado cambia, se
envía una nueva solicitud NOTIFY a la entidad suscrita. La información de estado
transmitida en la solicitud NOTIFY se define en un documento que se designa
paquete de eventos.
En concreto, en Rosenberg, Schulzrinne y Levin [13], un paquete de eventos
se definió para conferencias estrechamente acopladas, permitiendo a una entidad
suscribirse al estado de este tipo de conferencias. Este paquete de eventos se utiliza
en la solución propuesta para comunicar información útil sobre el estado de la sesión
a cada participante en la sesión multimedia multipartita. Esta información incluye la
especificación de los componentes multimedia que han sido acordados por cada UE
que participa en la sesión multimedia multipartita.
Por lo tanto, la recepción de la primera respuesta OK a una petición INVITE en la
MAS es una suscripción implícita del UE iniciador y del UE de destino que envió la
respuesta OK al estado de la sesión multimedia multiparte, que será notificado
mediante este paquete de eventos. De este modo, una vez recibida la respuesta OK
en MAS, éste envía una petición SIP NOTIFY (punto 10 en las figuras 16.1 y 16.2)
que contiene el estado de la sesión multimedia multipartita al UE iniciador y al UE
de destino. De este modo, los UE de iniciación y destino reciben información sobre
los componentes multimedia para los que pueden empezar a transmitir medios. El
receptor confirma cada solicitud NOTIFY con una respuesta OK (punto 11 en las
figuras 16.1 y 16.2).
Las futuras respuestas OK a las solicitudes INVITE recibidas en el MAS implican
la
suscripción implícita del equipo de usuario de destino que envió la respuesta al
estado de la sesión multimedia multipartita. Cualquier cambio en este estado -por
ejemplo, cuando un UE se incorpora a la sesión o la abandona- se notifica a los UE
suscritos, que siempre están informados del estado actual de la sesión multimedia.
De este modo, los equipos de usuario suscritos también pueden empezar a transmitir
tráfico asociado a un componente multimedia en pausa, si algún equipo de usuario
que haya aceptado el componente multimedia se incorpora a la . Del mismo
modopueden dejar de transmitir tráfico para un componente multimedia si no
receptores disponibles en algún momento de la sesión.
 UE P-CSCF S-CSCF AS
328 Manual del subsistema multimedia fP (fM£)
INVITE INVITE INVITE
La INVITE se replica
para cada usuario de
destino

(1) INVITE Enviar a cada UE de destino

INVITE
Sess. Progreso Cada UE de destino responde
(2) con una S. Progreso
Sess. Progreso
Evaluación de la respuesta
SDP

Sess. Progreso Sess. Progreso

Sess.
PRACK
PRACK
Progreso

PRACK
(3) PRACK se replica para
Reserva de recursos Enviar a cada UE de destino
cada usuario de destino
Fallo

CANCEL
AR
OK CANCEL
(4) AR
OK CANCEL
AR
OK (5) Para cada UE de destino

CANCEL
AR
OK
Enviar a un equipo de
CANCELA destino
R OK OK Respuesta recibida
para CANCELAR

Primera respuesta 487

487 recibidos
(6)
para INVITE
ACK
Enviar a cada UE de destino
487
ACK
487 (7)
ACK
487
ACK
487
OK

FIGURA 16.5
Cancelación de sesión por el UE iniciador.

Cancelación del establecimiento de la sesión

En la subsección anterior se han descrito los procedimientos de establecimiento de
sesión. Esta subsección cubre los escenarios en los que la sesión no puede
establecerse con uno o todos los UE de destino, por ejemplo, porque no hay
suficientes recursos en la interfaz de radio del UE para cubrir las demandas de QoS
de la sesión multimedia multiparte.
La figura 16.5 muestra el caso en el que el equipo de usuario iniciador no puede
continuar con establecimiento de la sesión multimedia debido a la falta de recursos
de calidad de servicio en la red.
Servicios £ multipartitos en el subsistema fP Multimedia 329

UE P-CSCF S-CSCF AS

(1) Respuesta recibida de

400-699 UE de destino A UE
ACK de destino
(2)
400-699
ACK

400-699 (3)
ACK
400-699
ACK
400-699
OK
Si no quedan UE de destino

NOTIFICA (4)
NOTIFICA NOTIFICA R (5) A cada UE de destino
R R NOTIFÍQUESE A que ha Aceptado el
Establecimiento de la sesión
OK OK OK

Si se establece la sesión

FIGURA 16.6
Rechazo de sesión por el UE de destino.

red de acceso de radio. En este , la sesión debe cancelarse porque el progreso del
proceso de establecimiento depende del UE iniciador. Como puede verse en la
figura, el equipo de usuario iniciador cancela el procedimiento de establecimiento de
sesión mediante una petición SIP CANCEL. Esta solicitud de CANCELACION se
con- firma con una respuesta SIP OK salto a salto por cada proxy SIP que recibe la
solicitud. Cuando la solicitud de CANCELACIÓN SIP llega al MAS, éste genera una
nueva solicitud de CANCELACIÓN para cada equipo de usuario de destino. Cuando
un equipo de destino recibe la solicitud de CANCELACIÓN, confirma la solicitud
con una respuesta OK y responde a la solicitud INVITE con una respuesta 487
(solicitud finalizada). Cuando se recibe la primera respuesta 487 en el MAS, éste
genera una nueva respuesta 487 para la solicitud INVITE recibida del UE iniciador y
la envía allí. La respuesta 487 se confirma salto a salto con una solicitud ACK. De
este modo, se cancela el establecimiento de sesión.
La figura 16.6 muestra el caso en el que el equipo de destino no puede aceptar el
establecimiento de la sesión, por ejemplo, porque el usuario no está accesible en el
equipo o no hay suficientes recursos disponibles en la red de acceso de radio. En
este , el equipo de destino responde a la solicitud INVITE con una respuesta de error
SIP (códigos de estado entre 400 y 699). Esta respuesta se confirma salto a salto
mediante una solicitud ACK. Cuando la respuesta de error llega al MAS, su
comportamiento depende del estado de la sesión. Si la sesión no se ha establecido
entre el equipo de usuario que inicia la sesión y ninguno de los equipos de usuario
de destino, entonces si el equipo de usuario que inicia la sesión es el único equipo de
usuario participante que queda en la sesión, el MAS debe finalizar el
establecimiento de la sesión enviando una respuesta de error al equipo de usuario
que inicia la sesión (esta respuesta de error puede seleccionarse entre el conjunto de
respuestas de error que se indican a continuación).
380 Manual del subsistema multimedia fP (fM£)

UE P-CSCF S-CSCF AS

Caso 1

(1) BYE Recibido de

BYE
Destino UE
BYE
OK
OK A UE de destino
NOTIFICA (2) A cada UE de destino que
NOTIFICA R
NOTIFIC NOTIFICA haya aceptado el
R
AR R (4) Establecimiento de la
OK OK
OK sesión

Caso 2

(1) BYE
BYE
BYE
OK (2) A cada UE de destino
OK
OK NOTIFIQUE A que ha Aceptado el
Establecimiento de
Sesión

Caso 3

(1) BYE
BYE
BYE
OK (2)
OK
OK BYE A cada participante UE

FIGURA 16.7
Escenarios de liberación de sesiones.

respuestas recibidas de los UE de destino). De lo contrario, si la sesión está

actualmente establecida entre el UE de inicio y un conjunto de UE de destino, el
MAS debe notificar al UE de inicio y a ese conjunto de UE de destino los cambios
en el estado de la sesión, pero la sesión establecida puede continuar normalmente.

Liberación de la sesión
Esta subsección cubre brevemente los escenarios de liberación de sesión que pueden
ocurrir mientras se establece la sesión multimedia multiparte. Estos escenarios se
muestran en la Figura 16.7.
El primer caso corresponde al escenario en el que un UE de destino desea
abandonar la sesión multimedia multipartita. En este caso, el equipo de destino
envía una solicitud BYE al MAS. Una vez que el MAS recibe esta solicitud BYE, la
confirma con una respuesta SIP OK y notifica el cambio de estado de la sesión al
UE iniciador y al conjunto de UE que han aceptado el establecimiento de la sesión.
De esta forma, se consigue un procedimiento flexible de liberación de sesión
Servicios £ multipartitos en el subsistema fP Multimedia 381

adecuada para cualquier aplicación multipartita. Tras recibir la NOTIFY, el equipo

de usuario de destino podrá decidir si permanece o no en la sesión multimedia
multipartita. En este último , se enviará una nueva solicitud SIP BYE al MAS.
El segundo caso corresponde al escenario en el que el UE iniciador abandona la
sesión multimedia multipartita. En este caso, el UE iniciador envía una solicitud
BYE al . Tras recibir la solicitud BYE, el MAS la confirma con una respuesta SIP
OK y notifica el cambio de estado de la sesión al resto de los UE que han aceptado
el establecimiento de la sesión. Es posible que la aplicación multipartita ordene
finalizar la sesión multipartita multimedios cuando el UE iniciador abandone la
sesión (esto ocurre, por ejemplo, en el servicio push-to-talk sobre celular [PoC]
cuando se están estableciendo sesiones ad hoc). La información de estado incluida
en el cuerpo de la solicitud NOTIFY contiene suficiente información para determinar
si el UE que abandona la sesión es el que inició su establecimiento. Por lo tanto, la
solución propuesta es adecuada para hacer frente a este tipo de aplicaciones.
Por último, el último caso corresponde al escenario en el que un equipo de usuario
(no necesariamente el que inicia la sesión) abandona la sesión y el resto de equipos
de usuario participantes aún no han aceptado el establecimiento de la sesión. En este
caso, el MAS finaliza la sesión multimedia multipartita enviando una solicitud SIP
BYE a cada uno de los restantes equipos de usuario participantes.

Conclusiones
El IMS es una arquitectura basada en IP diseñada para proporcionar un conjunto de
funcionalidades esenciales que soporten la prestación de los servicios multimedia de
próxima generación que se prevén en el futuro de las redes 3G. En este contexto,
este capítulo ha introducido los problemas asociados a la prestación de servicios
multipartitos en el ámbito del IMS. Se han identificado los principales
inconvenientes asociados a la especificación actual de estos servicios y se ha
descrito una solución alternativa a las propuestas presentadas por el 3GPP. Esta
solución consiste en ampliar las funcionalidades de control de sesión en el IMS y
prestar el servicio mediante tecnologías de multidifusión a nivel de red en el plano
de usuario. De este modo, se proporciona una plataforma genérica que facilita el
desarrollo de servicios multipartitos en el IMS. Se han analizado las ventajas e
inconvenientes de utilizar la multidifusión a nivel de red como servicio de entrega.
Por último, el capítulo describe las principales extensiones definidas en los
procedimientos de control IMS para el establecimiento de sesiones multipartitas, la
cancelación del establecimiento de sesiones multipartitas y los procedimientos de
liberación de sesiones multipartitas. Obsérvese que, aunque hemos descrito el
trabajo en el contexto de la arquitectura UMTS, las funcionalidades del plano de
control también son aplicables a un acceso fijo con soporte IMS (arquitectura de red
de próxima generación).
382 Manual del subsistema multimedia fP (fM£)

Referencias
1. Proyecto de Asociación de 3ª Generación. 2006. 3GPP TS 23.228 versión 7.5.0: Sistema
digital de telecomunicaciones celulares (fase 2+); sistema universal de
telecomunicaciones móviles (UMTS); subsistema multimedia IP (IMS); fase 2.
2. Cain, B., S. Deering, I. Kouvelas, B. Fenner y A. Thyagarajan. 2002. Protocolo de
gestión de grupos de Internet, versión 3. RFC 3376 (norma propuesta). Actualizado por
RFC 4604.
3. Estrin, D., D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacob- son, C.
Liu, P. Sharma y L. Wei. 1998. Protocol independent multicast-sparse mode (PIM-SM):
Protocol specification. RFC 2362 (experimental). Obsoleto por RFC 4601.
4. Vidal, I., I. Soto, F. Valera, J. García y A. Azcorra. 2007. IMS signaling for mul- tiparty
services based on network level multicast. 3rd EURONGI Conference on Next Generation
Internet Networks, 21-23 de mayo, pp. 103-110, Trondheim, Noruega.
5. Proyecto de Asociación de 3ª Generación. 2006. 3GPP TS 24.229 v7.5.1: Technical spec-
ification group core network and terminals; IP multimedia call control proto- col based
on session initiation protocol (SIP) and session description protocol (SDP); stage 3
(release 7).
6. Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks,
M. Handley, y E. Schooler. 2002. SIP: Protocolo de iniciación de sesión. RFC 3261 (norma
propuesta). Actualizado por los RFC 3265, 3853 y 4320.
7. Handley, M., V. Jacobson y C. Perkins. 2006. SDP: Protocolo de descripción de sesión. RFC
4566 (norma propuesta).
8. Rosenberg, J., y H. Schulzrinne. An offer/answer model with session descrip- tion
protocol (SDP). RFC 3264 (norma propuesta).
9. Rosenberg, J., y H. Schulzrinne. 2002. Fiabilidad de las respuestas provisionales en el
protocolo de iniciación de sesión (SIP). RFC 3262 (norma propuesta).
10. Camarillo, G., W. Marshall, y J. Rosenberg. 2002. Integración de la gestión de recursos y el
protocolo de iniciación de sesión (SIP). RFC 3312 (propuesta). Actualizado por RFC 4032.
11. Camarillo, G., y P. Kyzivat. 2005. Actualización del marco de condiciones previas del
protocolo de iniciación de sesión (SIP). RFC 4032 (norma propuesta).
12. Roach, A. B. 2002. Session initiation protocol (SIP)-specific event notification. RFC 3265
(norma propuesta).
13. Rosenberg, J., H. Schulzrinne y O. Levin. 2006. A session initiation protocol (SIP) event
package for conference state. RFC 4575 (norma propuesta).
17
fM£-Based Conferencing £ervices: Un enfoque
de ingeniería

Alessandro Amirante, Tobia Castaldi, Lorenzo

Miniero y Simon Pietro Romano

CONTENIDO
Introducción ...................................................................................................................... 384
CONFIANCE: una arquitectura de conferencia centralizada de código abierto
habilitada para IMS ..................................................................................... 385
Hacia un marco de conferencias distribuidas compatible con IMS ................ 386
Escenario de conferencia centralizada ................................................................ 386
Escenario de conferencia distribuida................................................................... 388
DCON: un marco para conferencias distribuidas ........................................................ 389
Requisitos marco .................................................................................................... 390
Diseño del marco.....................................................................................................391
DCON y la arquitectura IMS................................................................................ 392
Aplicación de DCON ....................................................................................................... 392
Interacción Interfocus ............................................................................................ 394
Servidor ....................................................................................................... 394
Cliente ......................................................................................................... 395
Análisis de escalabilidad de DCON ................................................................................. 397
Consideraciones preliminares ............................................................................... 397
Escenario centralizado .......................................................................................... 398
Escenario distribuido ............................................................................................. 400
Análisis comparativo, consideraciones y comentarios ..................................... 406
Trabajos relacionados....................................................................................................... 406
Conclusiones y trabajo futuro ......................................................................................... 407
Agradecimientos............................................................................................................... 408
Referencias ........................................................................................................................ 408

En este capítulo presentamos una implementación real de un marco de conferencia

distribuida compatible con el subsistema de red central multimedia IP.
383