Tesis MacDonald PDF

INSTITUTO TECNOLGICO AUTNOMO DE MXICO
Servicios Personalizados de Multimedia Ofrecidos Sobre

la Plataforma IP Multimedia Subsystem
T E S I S
QUE PARA OBTENER EL TTULO DE
INGENIERO EN TELEMTICA
P R E S E N T A
ALTON KENNETH MACDONALD HERNNDEZ
MXICO, D.F. 2009

Con fundamento en los artculos 21 y 27 de la Ley Federal del Derecho
de Autor y como titular de los derechos moral y patrimonial de la obra titu-
lada Servicios Personalizados de Multimedia Ofrecidos Sobre la
Plataforma IP Multimedia Subsystem, otorgo de manera gratuita y per-
manente al Instituto Tecnolgico Autnomo de Mxico y a la Biblioteca Ral
Baillres Jr., autorizacin para que fijen la obra en cualquier medio, incluido el
electrnico, y la divulguen entre sus usuarios, profesores, estudiantes o terceras
personas, sin que pueda percibir por tal divulgacin una contraprestacin.
Alton Kenneth MacDonald Hernndez
FECHA
FIRMA
A mi madre.
Agradecimientos
Quiero agradecer la ayuda que me proporcion mi asesor, el Mto. Rodolfo

Cartas Ayala, en la recoleccin de informacin y sus amplias sugerencias en
la escritura de este documento. Al Dr. Jos Alberto Domingo Incera Diguez
por las crticas y sugerencias hechas a mi trabajo de tesis y por sus valiosos
comentarios durante nuestras plticas. A toda la facultad del departamento de
Sistemas Digitales por el conocimiento que me han brindado, en especial al Dr.
Federico Jos Kuhlmann Rodrguez por el apoyo que me ha brindado a travs de
la carrera al revisar formatos y trmites poco comunes. Al Mto. Uciel Fragoso
Rodrguez por su apoyo en fallas de conectividad presentadas en el Laboratorio
de Redes Avanzadas. Y al Mto. Jorge Luis Ojeda que sin su generosidad no
hubiera sido posible implementar el gateway telefnico de la maqueta usada en
este trabajo de tesis.
Quiero adems agradecer a todas las personas que me han permitido cono-
cerlas y aprender de ellas, pero sobre todo que me han brindado su amistad
durante mi estancia en el ITAM. A mis amigos les pido una disculpa por haber-
me ausentado tanto tiempo. Y finalmente, quiero agradecer a mi familia que han
soportado mis errticos ciclos de sueo durante la escritura de este documento.
Resumen
La convergencia digital se vuelve cada da ms importante tanto para los

operadores como los usuarios. Los usuarios han aumentado sus exigencias y
los operadores han visto la necesidad de adaptarse ante estas nuevas exigencias.
Las Redes de Siguiente Generacin (Next Generation Networks: NGN) proponen
solucionar estos problemas al migrar del decadente modelo del Sndrome Silo
al revolucionario modelo de Plataforma de Entrega de Servicios. Se presenta la
plataforma IP Multimedia Subsystem (IMS) cmo la primer implementacin de
una Plataforma de Entrega de Servicios en la adopcin de redes NGN.
Este trabajo de tesis analiza la relacin entre estos conceptos y cmo dan
luz a IMS. Tambin se analiza la operacin de servicios Servicios Basados en
Localizacin (Location Based Services: LBS) dentro de este contexto para me-
jorar la Calidad de Experiencia (Quality of Experience: QoE) presenciada por
los usuarios. Se logr implementar la oferta de LBS personalizados sobre IMS.
Este documento detalla la construccin de una maqueta IMS. Adems descri-
be el diseo e implementacin de servicios LBS usando los bloques de servicio
proporcionados por la maqueta.
ndice general
1. Introduccin 1
1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Justificacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Trabajos Relacionados . . . . . . . . . . . . . . . . . . . . . . . 6
1.6. Organizacin del Documento . . . . . . . . . . . . . . . . . . . . 8
2. Marco Conceptual 9
2.1. Redes de Siguiente Generacin . . . . . . . . . . . . . . . . . . . 9
2.1.1. Definicin . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2. Arquitectura NGN . . . . . . . . . . . . . . . . . . . . . 12
2.1.2.1. Plano de Transporte . . . . . . . . . . . . . . . 12
2.1.2.2. Plano de Servicio . . . . . . . . . . . . . . . . 13
2.1.3. Transicin Hacia NGN . . . . . . . . . . . . . . . . . . . 14
2.2. Modelos de Entrega de Servicio . . . . . . . . . . . . . . . . . . 15
2.3. IP Multimedia Subsystem . . . . . . . . . . . . . . . . . . . . . 17
2.3.1. Orgenes de IMS . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2. Arquitectura IMS . . . . . . . . . . . . . . . . . . . . . . 18
2.3.3. Componentes IMS . . . . . . . . . . . . . . . . . . . . . 20
2.3.3.1. Repositorios de Informacin . . . . . . . . . . . 20
2.3.3.2. CSCF . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.3.3. P-CSCF . . . . . . . . . . . . . . . . . . . . . 21
2.3.3.4. I-CSCF . . . . . . . . . . . . . . . . . . . . . . 22
2.3.3.5. S-CSCF . . . . . . . . . . . . . . . . . . . . . . 22
vi
NDICE GENERAL NDICE GENERAL
2.3.3.6. Servidores de Aplicaciones . . . . . . . . . . . 22

2.3.4. Usuarios dentro de IMS . . . . . . . . . . . . . . . . . . 23
2.3.4.1. Identificacin Pblica de Usuario . . . . . . . . 23
2.3.4.2. Identificacin Privada de Usuario . . . . . . . . 23
2.3.4.3. Perfil de Servicio . . . . . . . . . . . . . . . . . 24
2.3.5. Tarificacin . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.5.1. Tarificacin Fuera de Lnea . . . . . . . . . . . 24
2.3.5.2. Tarificacin En Lnea . . . . . . . . . . . . . . 25
2.3.5.3. Tarificacin Basada en Flujos . . . . . . . . . . 25
2.3.6. Tecnologas y Protocolos Usados . . . . . . . . . . . . . 25
2.3.6.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.6.2. SIP . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.6.3. Session Description Protocol . . . . . . . . . . 29
2.3.6.4. Diameter . . . . . . . . . . . . . . . . . . . . . 29
2.3.6.5. RTP/RTCP y H.323 . . . . . . . . . . . . . . 30
2.3.6.6. IPSec y TLS . . . . . . . . . . . . . . . . . . . 30
2.4. Servicios Basados en Localizacin . . . . . . . . . . . . . . . . . 30
2.4.1. Mtodos de Localizacin . . . . . . . . . . . . . . . . . . 31
2.4.1.1. GPS . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.1.2. Asistida Va Red Celular . . . . . . . . . . . . 31
2.4.1.3. Asistida Va Puntos de Acceso . . . . . . . . . 32
2.4.2. Presencia . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.3. XDMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.4. Documento de Presencia . . . . . . . . . . . . . . . . . . 34
2.4.5. XCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.6. RLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3. Construccin de la Maqueta IMS 37

3.1. Objetivos y Requerimientos . . . . . . . . . . . . . . . . . . . . 37
3.2. Dominios IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3. Gateway PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4. Servidor de Contenidos . . . . . . . . . . . . . . . . . . . . . . . 41
3.5. Servidor de Presencia . . . . . . . . . . . . . . . . . . . . . . . . 42
3.6. Clientes IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.7. Topologa Fsica . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.8. Evaluacin de la Maqueta . . . . . . . . . . . . . . . . . . . . . 48
3.8.1. Telefona Tradicional . . . . . . . . . . . . . . . . . . . . 48
vii
3.8.2. Telefona Celular Mvil . . . . . . . . . . . . . . . . . . 49

3.8.3. Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4. Diseo de LBS Personalizados 53

4.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2. Gua Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.1. Diseo de Alto Nivel . . . . . . . . . . . . . . . . . . . . 55
4.2.2. Flujo de Mensajes SIP . . . . . . . . . . . . . . . . . . . 56
4.3. Cartelera Personalizada . . . . . . . . . . . . . . . . . . . . . . 58
4.3.1. Diseo de Alto Nivel . . . . . . . . . . . . . . . . . . . . 59
4.3.2. Flujo de Mensajes SIP . . . . . . . . . . . . . . . . . . . 60
4.3.3. Archivos XML y XSD . . . . . . . . . . . . . . . . . . . 61
4.4. Clculo de Distancia en Metros . . . . . . . . . . . . . . . . . . 62
4.5. Actualizaciones de Localizacin . . . . . . . . . . . . . . . . . . 62
4.6. Modelo de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . 63
5. LBS Personalizados 65
5.1. Herramientas Utilizadas . . . . . . . . . . . . . . . . . . . . . . 65
5.2. Modificaciones al Diseo . . . . . . . . . . . . . . . . . . . . . . 67
5.2.1. Mtodo REFER . . . . . . . . . . . . . . . . . . . . . . 68
5.2.2. Mtodo UPDATE . . . . . . . . . . . . . . . . . . . . . 70
5.3. Implementacin del AS para Servicios LBS . . . . . . . . . . . . 72
5.3.1. Interaccin con la Base de Datos . . . . . . . . . . . . . 73
5.3.2. Contenedor HTTP . . . . . . . . . . . . . . . . . . . . . 74
5.3.3. Contenedor SIP . . . . . . . . . . . . . . . . . . . . . . . 75
5.3.4. Procesamiento de XML . . . . . . . . . . . . . . . . . . 76
5.3.5. Construccin de la Cartelera . . . . . . . . . . . . . . . . 76
5.3.6. Consultas XCAP . . . . . . . . . . . . . . . . . . . . . . 77
5.4. Notificaciones de Localizacin . . . . . . . . . . . . . . . . . . . 78
5.5. Cambios a los Dominios . . . . . . . . . . . . . . . . . . . . . . 79
5.5.1. Configuracin del P-CSCF . . . . . . . . . . . . . . . . . 79
5.5.2. iFC para IPTV . . . . . . . . . . . . . . . . . . . . . . . 80
5.5.3. iFC para LBS . . . . . . . . . . . . . . . . . . . . . . . . 81
5.6. Cambios al Cliente . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.7. Escenario de Pruebas . . . . . . . . . . . . . . . . . . . . . . . . 82
5.8. Destinos e Itinerarios . . . . . . . . . . . . . . . . . . . . . . . . 83
5.9. Visualizacin del Funcionamiento . . . . . . . . . . . . . . . . . 84
viii
6. Conclusiones y Lneas Futuras 87

6.1. Acerca de la Maqueta IMS . . . . . . . . . . . . . . . . . . . . . 87
6.2. Acerca de los Servicios LBS . . . . . . . . . . . . . . . . . . . . 90
6.3. Desarrollo de un Cliente IMS Mvil . . . . . . . . . . . . . . . . 91
6.4. Conclusiones Finales . . . . . . . . . . . . . . . . . . . . . . . . 92
6.5. Lneas Futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7. Referencias Bibliogrficas 95
Apndices
A. Instalacin de la Maqueta IMS 101

A.1. Dominios IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A.2. Gateway PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
A.2.1. Hardware: Tarjeta Digium . . . . . . . . . . . . . . . . . 103
A.2.2. Software: Asterisk . . . . . . . . . . . . . . . . . . . . . 105
A.2.3. Configuracin Adicional . . . . . . . . . . . . . . . . . . 106
A.3. Servidor de Contenidos . . . . . . . . . . . . . . . . . . . . . . . 107
A.3.1. Darwin Streaming Server . . . . . . . . . . . . . . . . . 107
A.3.2. UCT IPTV Streaming Server . . . . . . . . . . . . . . . 107
A.4. Servidor de Presencia . . . . . . . . . . . . . . . . . . . . . . . . 108
A.4.1. OpenSIPS . . . . . . . . . . . . . . . . . . . . . . . . . . 108
A.4.2. OpenSIPS-mi-proxy . . . . . . . . . . . . . . . . . . . . 110
A.4.3. OpenXCAP . . . . . . . . . . . . . . . . . . . . . . . . . 111
A.5. Servidores de Aplicaciones . . . . . . . . . . . . . . . . . . . . . 112
A.5.1. Presencia . . . . . . . . . . . . . . . . . . . . . . . . . . 114
A.5.2. IPTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
A.5.3. Gateway PSTN . . . . . . . . . . . . . . . . . . . . . . . 115
A.5.4. Perfil de Servicio . . . . . . . . . . . . . . . . . . . . . . 115
B. Ejecucin de los Servicios LBS 116

B.1. Sailfin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
B.2. UCT IMS Client . . . . . . . . . . . . . . . . . . . . . . . . . . 117
B.3. P-CSCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
B.4. SIPp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Glosario 121
ix
ndice de figuras
2.1. Arquitectura NGN . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2. Modelo Vertical (Sndrome Silo) . . . . . . . . . . . . . . . . . . 16
2.3. Modelo Horizontal (Plataforma de Entrega de Servicios) . . . . 17
2.4. Arquitectura IMS . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5. Formato de Mensaje SIP . . . . . . . . . . . . . . . . . . . . . . 27
2.6. Localizacin Relativa Usando la Sectorizacin de Antenas . . . 32
2.7. Servidor de Presencia . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1. Ncleo IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2. Diseo del Gateway PSTN . . . . . . . . . . . . . . . . . . . . . 41
3.3. Diseo del Servidor de Contenidos . . . . . . . . . . . . . . . . 42
3.4. Diseo de XDMS . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5. Topologa Fsica de la Maqueta IMS . . . . . . . . . . . . . . . 45
3.6. Entrega de Contenido . . . . . . . . . . . . . . . . . . . . . . . 47
3.7. Curiosidades del Servicio de Roaming . . . . . . . . . . . . . . . 50
4.1. Mensajes SIP Generados por el Gua Virtual . . . . . . . . . . . 57

4.2. Mensajes Generados por la Cartelera Personalizada . . . . . . . 60
4.3. PIDF de los Gneros Preferidos . . . . . . . . . . . . . . . . . . 61
4.4. Definicin XSD del Formato de las Actualizaciones de Localizacin 63
5.1. Primera Modificacin al Diseo . . . . . . . . . . . . . . . . . . 69

5.2. Diseo Final de los LBS Personalizados . . . . . . . . . . . . . . 71
5.3. Terminacin del Contenido LBS . . . . . . . . . . . . . . . . . . 72
5.4. Base de Datos Usado por el AS . . . . . . . . . . . . . . . . . . 73
5.5. Interaccin con la Base de Datos . . . . . . . . . . . . . . . . . 74
x
NDICE DE FIGURAS NDICE DE FIGURAS
5.6. Visualizacin de los Destinos Tursticos y Usuarios . . . . . . . 75

5.7. Generacin de Notificaciones de Localizacin . . . . . . . . . . . 79
5.8. Rutas que Recorren los Usuarios . . . . . . . . . . . . . . . . . 84
5.9. Entrega del Servicio al Usuario 1 . . . . . . . . . . . . . . . . . 85
5.10. Entrega del Servicio al Usuario 2 . . . . . . . . . . . . . . . . . 85
5.11. Entrega del Servicio a los Usuarios 3 y 4 . . . . . . . . . . . . . 86
A.1. Cableado para RJ45 a RJ11 . . . . . . . . . . . . . . . . . . . . 104

A.2. Configuracin de la Lista de Reproduccin . . . . . . . . . . . . 107
xi
ndice de cuadros
2.1. Cdigos de Estado SIP . . . . . . . . . . . . . . . . . . . . . . . 27

2.2. Mtodos SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3. Ejemplo de Documento de Presencia . . . . . . . . . . . . . . . 34
3.1. Funcionalidades Ofrecidas Bajo Esquema PSTN/ISDN . . . . . 49

3.2. Funcionalidades Ofrecidas Bajo Esquema de Telefona Celular
Mvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3. Funcionalidades Ofrecidas Bajo Esquema Internet . . . . . . . . 51
4.1. Actualizaciones de las Coordenadas Geogrficas . . . . . . . . . 63
5.1. Trigger Points Definidos para el Servidor de Contenidos . . . . 80

5.2. Trigger Points Definidos para los Servicios LBS Personalizados . 81
A.1. Inicializacin de la Variable CLASSPATH Usado por HSS . . . 102

A.2. Puertos Usados por los Dominios IMS . . . . . . . . . . . . . . 103
A.3. Modificacin al Cdigo de Asterisk . . . . . . . . . . . . . . . . 105
A.4. Puertos Usados por Asterisk . . . . . . . . . . . . . . . . . . . . 106
A.5. Traduccin de SIP-URI a RTP . . . . . . . . . . . . . . . . . . 108
A.6. Sustitucin de Valores en el Archivo opensipsctlrc . . . . . . . 109
A.7. Construccin de la BD Usado por OpenSIPS . . . . . . . . . . . 109
A.8. Modificacin para que OpenSIPS Inicie Automticamente . . . 110
A.9. Instalacin de OpenSIPS-mi-proxy . . . . . . . . . . . . . . . . 111
A.10.Prerequisitos para Instalar OpenXCAP . . . . . . . . . . . . . . 111
A.11.Integracin de OpenXCAP y OpenSIPS . . . . . . . . . . . . . 113
A.12.Puertos Usados por el Servidor de Presencia . . . . . . . . . . . 113
xii
NDICE DE CUADROS NDICE DE CUADROS
A.13.Valores del Trigger Point para el AS de Presencia . . . . . . . . 114

A.14.Valores del Trigger Point para el Servidor de Contenidos . . . . 115
A.15.Valores del Trigger Point para el Gateway PSTN . . . . . . . . 115
B.1. Primera Modificacin al Cdigo del Cliente . . . . . . . . . . . . 117

B.2. Segunda Modificacin al Cdigo del Cliente . . . . . . . . . . . 118
B.3. Modificacin a la Configuracin del P-CSCF . . . . . . . . . . . 118
B.4. Script Usado para Iniciar SIPp . . . . . . . . . . . . . . . . . . 119
B.5. Formato del CSV con Coordenadas . . . . . . . . . . . . . . . . 119
B.6. Mensajes PUBLISH generados por SIPp . . . . . . . . . . . . . 120
xiii
Captulo 1
Introduccin
Este Captulo expone la situacin actual de los operadores ante la migracin

hacia Redes de Siguiente Generacin (Next Generation Networks: NGN) y cmo
la plataforma IP Multimedia Subsystem (IMS) intenta suavizar dicha migracin.
Adems presenta el objetivo, alcance y justificacin del trabajo realizado en esta
tesis. Finalmente incluye un esquema explicando la organizacin del documento.
1.1. Antecedentes
Anteriormente los servicios definan las tecnologas de red. Las Redes Te-
lefnicas Tradicionales (Public Switched Telephone Networks: PSTNs) fueron
diseadas para proveer servicios de voz. A su vez, las teledifusoras desplegaron
sus redes para ofrecer servicios de video. El Protocolo de Internet (Internet Pro-
tocol: IP) fue diseado para compartir archivos y recursos en un ambiente de
colaboracin. Los servicios nicamente eran accesibles desde las redes que los
ofrecan; la posibilidad de entregar servicios de voz, video o datos era altamente
dependiente de la red de acceso y de transporte. Actualmente, las redes de ac-
ceso cuentan con la tecnologa que les permite realizar la entrega de contenido
anteriormente no contemplado, lo cual ha motivado un cambio en las exigencias
de los usuarios. El usuario tiene la expectativa de tener acceso a cualquier servi-
cio desde cualquier lugar, haciendo irrelevante la red que provee dicho servicio
[48]. Esto complica enormemente el trabajo de los operadores ya que sus redes
no fueron diseadas para soportar mltiples tipos de flujo.
1
1.1. Antecedentes Captulo 1. Introduccin
La creciente demanda de servicios bajo contextos hasta hace poco impensa-

bles, junto con las altas velocidades brindadas por tecnologas de banda ancha
han dado vida a la llamada convergencia digital. Dicha convergencia surge a
partir de tres puntos: (1) no existe una diferencia fundamental entre los dispo-
sitivos de cmputo y los dispositivos de transmisin de datos; (2) no existe una
diferencia fundamental entre la transmisin de datos, voz y video; (3) las lneas
que dividen un dispositivo de cmputo y una red se desvanecen [49]. La realiza-
cin de estos puntos se ve reflejado en un cambio radical donde los operadores
aspiran por ofrecer cualquier tipo de servicio desde sus propias redes. A su vez,
los usuarios, al ver que todos los operadores cuentan con la capacidad de ofrecer
los mismos servicios, esperan poder usar cualquier dispositivo para acceder a su
informacin desde las distintas redes de acceso. Como consecuencia, el usuario
percibe la red como un ente transparente.
La convergencia no funciona bajo el modelo tradicional donde el servicio
depende de la red de acceso. Las Redes de Siguiente Generacin (Next Gene-
ration Networks: NGN) introducen un nuevo modelo donde los servicios son
independientes de las tecnologas que la transportan. stas buscan solucionar
los obstculos que enfrentan las redes tradicionales en la convergencia digital.
Existen dos principales tecnologas o redes de transporte que pueden ser usadas
para construir una NGN: las redes basadas en la conmutacin de circuitos y
aquellas basadas en la conmutacin de paquetes. Por s solas ninguna de estas
redes son suficientes para fomentar la convergencia ni la transicin a redes NGN.
Las redes de conmutacin de circuitos, a pesar de garantizar una alta disponi-
bilidad y Calidad de Servicio (Quality of Service: QoS), desperdician recursos
ya que reservan un canal durante toda una sesin, sin importar cmo se utiliza.
Las redes de conmutacin de paquetes basados en IP, a pesar de permitir mayor
trfico en canales del mismo ancho de banda, se ven perjudicadas por su entrega
basado en el mejor esfuerzo [14]. Es decir, la velocidad de transmisin y ancho
de banda en un momento dado depende del trfico presente en la red. Como
consecuencia, la red se encarga de transportar, ms no garantizar la integridad
ni la entrega de datos. Tampoco se garantiza la entrega secuencial de paquetes,
perjudicando la QoS; no se cuenta con un esquema de tarificacin que permita
cobrar por los recursos utilizados; y tampoco permite la integracin de distintos
servicios [14].
IP Multimedia Subsystem (IMS) es una propuesta de Third Generation Part-
nership Project (3GPP) como parte de su Release 5 y ha sido mejorada en los
Release 6 y 7 [14]. IMS fue diseado para controlar sesiones de multimedia en-
2
tre usuarios, pero su maduracin ha adoptado cuatro objetivos principales: (1)

combinar las ltimas tendencias tecnolgicas; (2) lograr el paradigma del inter-
net mvil; (3) proporcionar una plataforma comn que permita la creacin de
servicios multimedia; (4) crear un mecanismo que aumente ingresos debido a su
uso en redes mviles [14]. 3GPP con la ayuda del Internet Engineering Task
Force (IEFT) han definido el funcionamiento de IMS con tecnologas abiertas.
La razn que se opt por usar tecnologas abiertas provenientes del mundo IP
fue que el Internet ha mostrado un enorme nivel de crecimiento e innovacin el
cual no es posible en ambientes cerrados como los utilizados en las PSTN y el
mundo de telefona celular. Puesto en marcha sobre el Protocolo de Internet ver-
sin 6 (Internet Protocol v6: IPv6), IMS se ha convertido en una Plataforma de
Entrega de Servicios permitiendo el despliegue rpido de servicios baratos; sta
es otra razn por la cual se opt por usar tecnologas abiertas ya que cualquiera
puede ofrecer nuevos servicios sobre IMS y el operador puede conjuntar dichos
servicios con los que ya tiene a su disposicin, generando servicios novedosos
en poco tiempo y con costos mnimos [16]. Esta cooperacin y la Plataforma
de Entrega de Servicios que brinda IMS son fundamentales en la creacin de
servicios de comunicaciones avanzadas [16].
IMS describe en conjunto cmo usar varias tecnologas para la creacin de
una Plataforma de Entrega de Servicios. Adems de IPv6, IMS hace uso del
Protocolo de Inicializacin de Sesin (Session Initiation Protocol: SIP) para el
manejo de sesiones y la implementacin de sealizacin. Maneja los flujos mul-
timedia con los protocolos Real-Time Transport Protocol (RTP) y Real-Time
Transport Control Protocol (RTCP). Utiliza varios otros protocolos, pero stos
cuatro son los ms relevantes para la creacin de una Plataforma de Entrega de
Servicios, ya que brindan los planos de transporte, control y servicio. Los planos
de control y transporte se encargan de la negociacin de QoS, autenticacin del
usuario y control de la sesin. El plano de servicio define los mecanismos para la
ejecucin de servicios de telecomunicaciones bsicas como mensajera, voz, video
y presencia. IMS permite migrar el mundo analgico al digital conservando lo
mejor de ambos mundos, mejorando el desempeo de los protocolos IP y SIP
para aplicaciones multimedia, estableciendo sesiones y brindando la sealizacin
carente en IP [48].
Uno de los propsitos de una Plataforma de Entrega de Servicios es facilitar
la creacin de nuevos servicios proporcionando bloques bsicos adaptables. La
manera que IMS permite tal creacin es por medio de Servidores de Aplica-
ciones (Application Servers: AS), los cuales forman los bloques de servicio que
3
componen la plataforma. La creacin de servicios se convierte en la tarea de

ensamblar distintos AS de una manera original, generando servicios novedosos.
Este modelo permiti las innovaciones que tenemos hoy en da en el Internet.
IMS, al contar con un AS de presencia que registre las preferencias y localiza-
cin del usuario, cuenta con una gran herramienta que permite la creacin de
servicios personalizados. La negociacin de protocolos entre el Equipo Terminal
del Usuario (User Equipment: UE) e IMS permite que la red sea ms inteligente
y detecte desde la interfaz que utiliza el usuario hasta la red fsica desde donde
acede a los servicios, dicha informacin permite optimizar los flujos y servicios
que le ofrece al usuario, habilitando un trato personalizado al usuario. La red se
volver transparente hacia el usuario, logrando cumplir uno de los objetivos de
la convergencia digital en NGN.
Los operadores, al adoptar IMS como su infraestructura para NGN, gozan
de dos principales beneficios: (1) no tendrn que dar mantenimiento a dos redes,
la analgica y digital; (2) aumentarn sus ingresos debido a las facilidades de
innovacin que brinda un sistema abierto como es el Internet. Los usuarios al
ver realizada la convergencia y la amplia gama de nuevos servicios encontra-
rn nuevas maneras de explotar las facilidades que brinda IMS [14]. Al facilitar
sustancialmente la creacin de nuevos servicios IMS podr, adems de brindar
una mejora en QoS, tambin ofrecer una mejor Calidad de Experiencia (Qua-
lity of Experience: QoE), con un mayor catlogo de servicios [18]. La principal
motivacin para implementar IMS es que ofrece grandes ventajas, tanto para
los consumidores como para los operadores. IMS es el primer paso hacia la con-
vergencia total, permitiendo un mejora en la calidad de servicio y el contenido
ofrecido al usuario final.
La mayora de los operadores tienen planeado migrar su infraestructura ha-
cia IMS para finales del 2011 [15, 33] lo cual dar vida a NGN y redes mviles de
Cuarta Generacin (4G). En el 2006 se tena proyectado que se invertira la can-
tidad de 10.1 mil millones de dlares en la investigacin y desarrollo de IMS [15].
Afortunadamente, instituciones como el Fraunhofer Institute for Open Commu-
nications Systems (FOKUS) estn desarrollando implementaciones del ncleo
IMS usando Software Libre y Abierto (Free and Open Source Software: FOSS)
lo que permite a cualquiera probar las funcionalidades de IMS en sus propios
laboratorios. FOKUS, adems de contar con un prototipo de la implementacin
ms novedosa de IMS, se ve respaldada por las inversiones de grandes empresas
como HP, T-Mobile, NTT DoCoMo, Ericsson, Intel y OpenCloud, entre otras.
4
1.2. Objetivo Captulo 1. Introduccin
1.2. Objetivo
El objetivo de este trabajo de tesis es desarrollar y ofrecer servicios per-
sonalizados de multimedia con la ayuda de Servicios Basados en Localizacin
(Location Based Services: LBS) explotando los distintos bloques de servicio que
provee IMS. Dichos servicios se ofrecen sobre una maqueta IMS construida a
partir de herramientas FOSS.
1.3. Alcance
La maqueta se construy a partir de herramientas FOSS ya existentes co-
mo son Open IMS Core elaborado por el Fraunhofer Institute for Open Com-
munications Systems (FOKUS) y se utiliz el cliente IMS desarrollado por el
Communications Research Group de la Universidad de Cape Town (UCT). Se
ofrecen servicios con la ayuda de diversos AS. La construccin de la maqueta
se llev a cabo en el Laboratorio de Redes Avanzadas del Instituto Tecnolgico
Autnomo de Mxico (ITAM). Los servicios personalizados desarrollados son
ofrecidos en tiempo real hacia clientes IMS, los cuales se encuentran en diversas
computadoras donde se simula su movimiento mediante actualizaciones en sus
coordenadas geogrficas.
1.4. Justificacin
La tendencia que siguen los modelos NGN hacia un mundo Todo-IP ha
remarcado las carencias que posee el protocolo IP para soportar el transporte de
multimedia, ofrecer QoS, seguridad, confiabilidad y diversas otras habilidades
ya existentes en redes de conmutacin de circuitos como PSTN. IMS surge como
la solucin a los problemas de sealizacin presentes en un mundo Todo-IP,
permitiendo la implementacin eficiente de servicios convergentes [52].
IMS permite el rpido despliegue de servicios novedosos con tecnologas exis-
tentes. Tambin, promueve la convergencia en todas las capas del modelo de
Interconexin de Sistemas Abiertos (Open Systems Interconnection: OSI), ya
que la entrega de los servicios es independiente de la tecnologa usada en la capa
fsica y el dispositivo que lo accede [19].
Sin embargo, actualmente el simple hecho de tener todos los servicios sobre
IP, no es suficiente para la adopcin masiva de IMS [52]. En vista de atraer
5
1.5. Trabajos Relacionados Captulo 1. Introduccin
al pblico hacia un operador que ha invertido en IMS, se requiere ofrecer ser-

vicios novedosos que explotan la infraestructura que ste brinda. El propsito
de este trabajo es explorar la factibilidad de ofrecer servicios novedoso usando
las herramientas que brinda IMS, enfocndose sobre servicios personalizados de
multimedia.
Como se haba mencionado, los servicios personalizados basados en locali-
zacin toman ventaja de la red transparente que aporta IMS y presentan una
nueva manera de interactuar con el usuario. La importancia que presentan los
LBS bajo este contexto motiv su implementacin dentro de IMS, en vez de
conformarse por cualquier otro tipo de servicio factible bajo IMS.
La construccin de la maqueta IMS, adems de proporcionar la base y las
herramientas necesarias que facilitan la creacin de los servicios personalizados
a realizar, tambin trae una aportacin adicional a la comunidad ITAM. Permi-
tir la exploracin del modelo NGN tanto para los propsitos de este proyecto
como para proyectos futuros que requieran de dicha infraestructura. Aquellos
interesados podrn apoyarse sobre el trabajo realizado en este proyecto, ya sea
para agregarle funcionalidad o bien como un ambiente de pruebas sobre el cual
realizar futuros proyectos.
1.5. Trabajos Relacionados

En el 2006 Lian Wu y Anders Hagelskjr Aasgaard [58] abordan el tema de
migracin de servicios empresariales de Voz sobre IP (Voice over IP: VoIP) y
SIP a soluciones IMS en su Tesis de Maestra. Se enfocan en definir las princi-
pales diferencias entre la implementacin y el diseo de soluciones empresariales
y cmo stas se pueden integrar al funcionamiento de IMS. Mencionan los pro-
blemas de interconexin y compatibilidad al momento de que las soluciones
empresariales hacen uso de la infraestructura de un operador IMS. Se concen-
tran en resolver especficamente el escenario donde el usuario desea acceder a
los soluciones de su empresa pero se encuentra registrado con un operador IMS.
Proponen un plan de trabajo que incorpora cuatro soluciones que se implemen-
tan bajo tres etapas de migracin dependiendo de la cantidad de operadores IMS
en funcionamiento. En la primer etapa casi no hay operadores IMS y la solucin
consiste en redirigir la sesin del usuario hacia la empresa. En la segunda etapa
existen algunos operadores IMS y se proponen dos soluciones. La primera con
un UE inteligente que le notifica a la empresa acerca de su cambio de estatus.
6
1.5. Trabajos Relacionados Captulo 1. Introduccin
La segunda requiere de un convenio entre la empresa y el operador donde la

presencia del usuario se comparte entre ambos. En la tercer etapa la mayora de
los operadores tienen una infraestructura IMS. La solucin de esta ltima etapa
consiste en hacer uso del filtrado de servicios empleado por IMS para habilitar
la entrega de las soluciones empresariales al usuario. Wu y Aasgaard proponen,
ms no implementan estas soluciones. Sin embargo, su anlisis demuestra su
factibilidad bajo las etapas de migracin que plantean.
La Tesis de Maestra de Fei Yao [59] aborda el tema de la interoperabilidad
entre las herramientas OpenIMS Core y Asterisk al momento de ofrecer solucio-
nes empresariales de VoIP. Yao se basa en el trabajo de [58] para implementar
la solucin del UE inteligente que presentada en la segunda etapa de migra-
cin. Analiza los problemas de compatibilidad originados bajo este contexto y
se enfoca en evaluar la funcionalidad y rendimiento de OpenIMS Core. Logra
implementar parcialmente la solucin ya que logra registrar clientes SIP dentro
de IMS, pero no pudo habilitar la entrega de servicios empresariales. La Sec-
cin 3.3 describe a mayor detalle los problemas que se enfrent Yao y cmo se
lograron solucionar en este trabajo de tesis.
En el 2008 Leonard Broman [12] describe como implementar el prototipo de
una plataforma IMS en su Tesis de Maestra. Tiene como objetivo implementar
y evaluar la mayora de las funcionalidades posibles dentro de su maqueta IMS.
La maqueta la logra construir a partir de herramientas FOSS. Utiliza OpenIMS
Core como el ncleo. Hace uso de la herramienta OpenSER para probar que
se puede integrar servicios de presencia existentes dentro de IMS. OpenXCAP
es utilizado para administrar grupos de usuarios. Finalmente, implementa un
mdulo de mensajera instantnea como un AS. Broman demuestra que es po-
sible construir una maqueta IMS a partir de estas herramientas y se encarga de
analizar los efectos que tienen los dispositivos de Traduccin de Direcciones de
Red (Network Address Translation: NAT) ante esta infraestructura.
En el 2008 Agata Brajdic, Ozren Lapcevic, Maja Matijasevic y Miran Mos-
mondor [10] publican un artculo acerca de cmo construir un servicio LBS den-
tro de la infraestructura de IMS. Integran servicios de localizacin y presencia
para formar un servicio de un Sticky-Note Virtual [10]. Dicho LBS se compone a
partir de la integracin de herramientas existentes, ya sea disponibles al pblico
o bien implementadas previamente por alguno de ellos. Publican este artculo
como prueba de concepto para demostrar que la integracin de servicios en IMS
se puede realizar de manera prctica.
7
1.6. Organizacin del Documento Captulo 1. Introduccin
1.6. Organizacin del Documento

Captulo 1: Introduccin al tema de tesis y sus antecedentes. Se expone el
objetivo, alcance y justificacin del proyecto.
Captulo 2: Definicin y marco terico de NGN, IMS y LBS. Se exponen
los distintos modelos de entrega de servicio, y cual de estos se requiere
para desplegar IMS. Finalmente, presenta la importancia que poseen los
servicios personalizados en la convergencia digital.
Captulo 3: Diseo e implementacin de la maqueta IMS. Se detallan los
objetivos y componentes que requiere la maqueta para proporcionar un
ambiente de pruebas que sirve para desarrollar los servicios personalizados
implementados en este trabajo de tesis.
Captulo 4: Expone el diseo de alto nivel de los servicios personalizados,
basando el funcionamiento de stos en servicios LBS. Se describen los casos
de uso bajo que atacan los servicios desarrollados y se presenta un esquema
para su tarificacin
Captulo 5: Describe las herramientas utilizadas en la implementacin de
los servicios, los obstculos enfrentados y como se resolvieron. Tambin se
describe los cambios requeridos por la maqueta para incluir los servicios
personalizados.
Captulo 6: Conclusiones, resultados y trabajo futuro. Se presentan puntos

de partida para mejorar tanto la maqueta como los servicios personalizados
desarrollados.
Captulo 7: Listado de las referencias bibliogrficas usadas en la escritura
de este documento.
Apndice A: Detalla de manera general la instalacin de la maqueta IMS
a partir de cero. Incluyendo la instalacin y configuracin de todos los
componentes de la maqueta.
Apndice B: Detalla de los cambios requeridos por el dominio IMS y el

cliente para interactuar con los servicios LBS. Tambin incluye los pasos
para iniciar los servicios y configurar las actualizaciones de localizacin.
8
Captulo 2
Marco Conceptual
Este Captulo presenta un bosquejo de Redes de Siguiente Generacin (Next

Generation Networks: NGN), IP Multimedia Subsystem (IMS) y Servicios Basa-
dos en Localizacin (Location Based Services: LBS), as como los distintos mo-
delos y protocolos que componen dichos conceptos. Se presentan las relaciones
existentes entre cada uno de sus elementos y cmo stos en conjunto permiten
dar un paso adelante hacia la convergencia y los servicios personalizados.
2.1. Redes de Siguiente Generacin

En el mundo actual existen dos principales proveedores de servicios de teleco-
municaciones: los operadores y los Proveedores de Servicios de Internet (Internet
Service Providers: ISPs) [43], cada uno con sus respectivas ventajas y desven-
tajas en la entrega de servicios. Los operadores poseen la infraestructura fsica
para ofrecer servicios de telecomunicaciones y la capacidad de garantizar la en-
trega de servicios. Este grupo se compone por empresas que ofrecen televisin
restringida, telefona fija y mvil; sus redes se basan en la conmutacin de cir-
cuitos, lo que permite un control de los contenidos y garantas sobre niveles de
calidad y disponibilidad. El segundo grupo se diferencia en que los ISPs no ne-
cesariamente poseen una infraestructura fsica, por lo que generalmente utilizan
la infraestructura de los operadores para ofrecer servicios a los usuarios finales;
trabajan sobre una red basada en la conmutacin de paquetes. Los ISPs, en
contraste a los operadores, no ofrecen servicios, sino que los usuarios poseen la
9
2.1. Redes de Siguiente Generacin Captulo 2. Marco Conceptual
libertad de acceder a servicios de terceros, donde pagan una renta mensual fija
independiente del servicio que hayan accedido.
Las polticas de cobranza accesibles presentadas por los ISPs han abierto
un nuevo medio por el cual los negocios puedan alcanzar a sus clientes [48]. El
nivel de desarrollo de servicios y aplicaciones atractivos sobre Internet ha sido
gigantesco. La falta de restricciones de interconexin en Internet ha producido
una enorme gama de servicios. Lamentablemente la entrega de dichos servicios
no puede ser garantizada bajo el esquema actual de infraestructura de redes por
la naturaleza del Protocolo de Internet (Internet Protocol: IP). IP trabaja bajo
la nocin de mejor esfuerzo. Esto es, enva paquetes con la esperanza de que
stos lleguen a su destino, sin embargo, no ofrece una manera de garantizar la
entrega correcta en el tiempo, ni la integridad de los paquetes. Por consiguiente,
los ISPs no cuentan con herramientas que permita garantizar la Calidad de
Servicio (Quality of Service: QoS) entre distintas redes [14, 48].
Las nuevas generaciones de usuarios no solo exigen la convergencia, sino que
tambin han cambiado las reglas que seguan los operadores al modificar los
trminos y expresiones que ellos mismos empleaban [48]. El trmino acceso ya
no significa lo mismo que antes; anteriormente se refera al tipo de tecnologa
que conectaba el usuario con la red del operador, ahora significa tener acceso a
las preferencias, informacin y servicios del usuario. El usuario espera que la red
sea inteligente, que tenga la capacidad de reconocerlo como persona y no como
un dispositivo ms donde tiene la misma informacin repetida en distintos for-
matos. Espera que la red se adapte a sus necesidades; la red deber responder al
trfico que genera y no viceversa. La movilidad ha pasado a la historia y ha sido
sustituido por la ubicuidad; trmino usado para expresar la interconectividad
transparente entre los diversos dispositivos del usuario, as como la informacin
que pueden desplegar [48]. La tecnologa de acceso se vuelve irrelevante para
el usuario; ste espera tener acceso a sus diversas fuentes de informacin sin
importar el dispositivo que utilice, ni desde dnde lo utiliza. Surge el trmino
de Calidad de Experiencia (Quality of Experience: QoE) donde el usuario cali-
fica la calidad de la red segn lo agradable que sea interactuar con el. La QoE
se logra a travs de una solucin integrada de servicio y soporte al cliente que
deja satisfecho al cliente. sta no puede medirse como la QoS. Surge la deman-
da de servicios y multimedia personalizado. Ya no se desea la difusin masiva
de contenidos que un empresario cree que el usuario quiere ver, sino contenido
personalizado que se entregue nicamente a quienes lo deseen.
Las expectativas de las nuevas generaciones de usuarios, junto con los proble-
10
2.1.1. Definicin Captulo 2. Marco Conceptual
mas de competencia que presentan los ISPs han obligado los operadores a buscar
una alternativa a su modelo de negocio actual. Si continan con un modelo de
negocio moribundo, los operadores estn destinados a volverse nicamente redes
de acceso [16]. Para evitar esto los operadores se encuentran con los siguientes
retos: (1) convertirse en ms que simples ISPs y (2) aplicar un modelo de negocio
que se base en las necesidades de los clientes [43]. Las redes actuales no permi-
ten vencer estos obstculos. Primero se tiene que cambiar el mtodo utilizado
para desplegar servicios, sto se explicar ms a fondo en las Secciones 2.2 y
2.3. Las NGN proponen un nuevo modelo de red inteligente capaz de adaptarse
a las necesidades de sus usuarios, no al revs. La red se volver transparente y
permitir cumplir con las exigencias presentadas por la convergencia.
2.1.1. Definicin
El trmino NGN es usado con creciente frecuencia en el mundo de las tele-
comunicaciones. Sin embargo su definicin es tan amplia que permite distintas
interpretaciones. Esto presenta una ventaja en el sentido de que no limita una
NGN a una cierta arquitectura fsica. Por otro lado, exto ha permitido que los
operadores propongan sus distintas infraestructuras como NGN.
La Unin Internacional de Telecomunicaciones (International Telecommuni-
cations Union: ITU) propone la siguiente definicin de NGN: Una red basada
en la conmutacin de paquetes capaz de proveer servicios de telecomunicaciones
y aprovechar el uso de banda ancha y QoS, donde las funciones de servicio sean
independientes de las tecnologas de transporte. Ofrece el acceso sin restriccio-
nes a distintos proveedores de servicios. Soporta movilidad donde los usuarios
cuentan con servicios ubicuos y continuos provenientes desde sus proveedores de
servicios. [28] Adems, una NGN debe tener la capacidad de: (1) independizar
el acceso a la red al proveer interfaces abiertas; (2) separar los planos de seali-
zacin y transporte; (3) manejar una variedad de esquemas de identificacin que
pueden ser traducidas a direcciones IP la cuales pueden ser enrutadas dentro de
redes IP; (4) permitir convergencia de servicios entre telefona mvil y fija; (5)
independencia entre los servicios y las tecnologas de transporte; (6) cumplir con
requerimientos regulatorios como son las llamadas de emergencia, la seguridad
y privacidad.
11
2.1.2. Arquitectura NGN Captulo 2. Marco Conceptual
2.1.2. Arquitectura NGN

Como ya se ha mencionado, las redes NGN no poseen una arquitectura f-
sica que las caracterice, sin embargo, poseen una arquitectura lgica que sirve
como gua para su implementacin. La Figura 2.1 muestra el diagrama de dicha
arquitectura. En el lado izquierdo del diagrama se ubica el Equipo Terminal
del Usuario (User Equipment: UE) y las funciones de mantenimiento; del lado
derecho se encuentran otras redes, ya que las NGNs tienen que saber cmo in-
teractuar con otras redes mientras sean una minora. Lo primero que especifica
este nuevo modelo es la separacin del plano de servicio y transporte con la
finalidad de hacer los servicios independientes de los protocolos de transporte.
Figura 2.1: Arquitectura NGN [29]
2.1.2.1. Plano de Transporte

Adems de ser el responsable de llevar a cabo el transporte de informacin
dentro de la red, el plano de transporte debe permitir la interconectividad con
otras redes va interfaces abiertas. Se descompone en dos subsistemas el Net-
work Attachment Subsystem (NASS) y Resource and Administration Control
Subsystem (RACS) [43].
NASS es responsable de establecer las reglas con las cuales se comunica el
UE con la red [43]. Esto se logra mediante la autenticacin y autorizacin de
12
2.1.2. Arquitectura NGN Captulo 2. Marco Conceptual
las configuraciones del UE junto con la asignacin dinmica y reservacin de

recursos va IP. NASS es el encargado de configurar la red en funcin de las
necesidades del UE.
RACS se encarga de reservar los recursos que requiere el UE, as como la
administracin y control de dichos recursos [43]. RACS esencialmente es el en-
cargado de establecer las polticas entre los planos de sealizacin, multimedia
y distintos gateways para lograr reservar los recursos que requiere el usuario.
Adems es el responsable de administrar la creacin y destruccin de dichos re-
cursos de manera ptima. El funcionamiento de RACS es mucho ms extenso y
especfico que el funcionamiento de NASS. Sin embargo, la descripcin de dicho
subsistema no es esencial dentro del desarrollo de ste trabajo de tesis, por lo
cual no se entrar a mayor detalle.
2.1.2.2. Plano de Servicio

Lo revolucionario de NGN es la separacin del plano de servicio del plano de
transporte. Ha dado vida a una nueva manera de desarrollar y ofrecer servicios
donde el despliegue de stos no requiere la construccin desde cero de una in-
fraestructura diseada especficamente para dichos servicios [43]. Este concepto
se profundizar en la Seccin 2.2. El plano de servicio de NGN se divide en dos
principales secciones: (1) el perfil de los usuarios y (2) subsistemas encargados
de ofrecer los servicios.
La convergencia requiere una red inteligente que identifique a usuarios y
no a dispositivos. Despus de todo, los usuarios, vistos desde el punto de vista
de la red, son un conjunto de UEs con un determinado numero de servicios
disponibles y preferencias que describen cmo desean la entrega de los servicios
segn el dispositivo con el cual se conectan a la red. Por esta razn se incluye
el perfil de los usuarios en el plano de servicio. Es el encargado de almacenar
toda la informacin acerca del usuario, incluyendo el los servicios a los que est
suscrito y sus preferencias en cuanto a la interaccin deseada con la red.
Los subsistemas con los que cuenta una NGN para cambiar radicalmente la
entrega de servicios son el subsistema PSTN/ISDN Emulation and Simulation
(PES), IMS y otros subsistemas. stos ltimos no estn definidos dentro de la
arquitectura NGN, pero pueden ser cualquier subsistema capaz de ofrecer servi-
cios. PES, como su nombre lo dice, se encarga de emular y simular los servicios
digitales que ofrece la telefona tradicional. La simulacin permite a clientes que
cuentan con el Protocolo de Inicializacin de Sesin (Session Initiation Protocol:
13
2.1.3. Transicin Hacia NGN Captulo 2. Marco Conceptual
SIP) tener acceso a servicios de la Red Telefnica Tradicional (Public Switched

Telephone Network: PSTN) y Red Digital de Servicios Integrados (Integrated
Services Digital Network: ISDN), mientras que la emulacin permite lo contra-
rio: que clientes PSTN/ISDN tengan acceso a servicios nicamente disponibles
a clientes SIP [43].
IMS es un subsistema esencial dentro de NGN, ya que es el responsable de
ofrecer servicios multimedia va sesiones SIP; sin la ayuda de IMS no se puede
emular ni simular servicios PSTN/ISDN de una manera sencilla. Adems, logra
la convergencia en las capas de servicio, control y conectividad dentro la red [19].
Permite la interconectividad de redes y servicios con interfaces y tecnologas
abiertas. Es una Plataforma de Entrega de Servicios que permite el desarrollo
y despliegue rpido de nuevos servicios novedosos (las distintas plataformas de
entrega de servicios se explican con mayor profundidad en la Seccin 2.2).
2.1.3. Transicin Hacia NGN

Las redes actuales fueron desarrolladas para proveer servicios especficos.
La alta dependencia que poseen dichos servicios a su red de origen complica la
tarea de migrarlos a otras redes. Por eso, la creacin (o migracin) de nuevos
servicios han sido ofrecidos como valor agregado y no garantizan la calidad ni
disponibilidad que ofrecen sus contrapartes. El proceso de adaptar flujos nuevos
a redes viejas obliga los operadores a seguir una tendencia donde sus ingresos
son dedicados al mantenimiento a su reds y a realizar parches a los protocolos
de transporte; esta tendencia no basta en el modelo NGN, los ingresos de los
operadores debern ser usados para desarrollar servicios atractivos y mejorar
los servicios actuales [43, 48]. Esto presenta un enorme obstculo para las re-
des NGN. Afortunadamente, nuevas tecnologas, particularmente aquellas que
trabajan sobre IP, han permitido avances enormes para disminuir la brecha de
convergencia de servicios, incluyendo mayor ancho de banda y acceso mvil
inalmbrico.
Las NGNs cambiarn el modelo de negocios actual. Para lograr esto se requie-
re una Plataforma de Entrega de Servicios que sea capaz de soportar mltiples
tipos de flujos y atenderlos adecuadamente (este nuevo paradigma se presenta
en la Seccin 2.2). El nuevo modelo debe satisfacer y mejorar una QoE hacia
el usuario, no concentrarse en mantener una QoS que el proveedor aprecia y el
usuario no. Para lograr la transicin hacia NGNs los operadores deben seguir
los siguientes pasos [43]:
14
2.2. Modelos de Entrega de Servicio Captulo 2. Marco Conceptual
Paso 1 Convergencia: Tener la habilidad de ofrecer cualquier tipo de ser-

vicio en cualquier tipo de infraestructura de red (mejor conocido como
convergencia de servicios). Incrementar el ancho de banda disponible a
los usuarios y permitir el acceso ubicuo. Este punto prcticamente se ha
realizado [43].
Paso 2 Migracin a IP: Tener la capacidad de ofrecer todos los servicios bajo
IP en un ambiente donde ste pueda ser manejable para garantizar la
entrega de servicios y permita adems manejar calidad y seguridad. Falta
poco para lograr que todos los operadores pasen a este punto [43]. Con la
ayuda de IMS esto se puede agilizar.
Paso 3 Creacin de Planos NGN: Este es el paso que los operadores pla-
nean concluir para finales del 2011 [15, 33], consiste en separar el plano de
servicio del plano de transporte. Despus el plano de servicio debe contar
con una plataforma que permita el desarrollo rpido y eficiente de nuevos
servicios.
2.2. Modelos de Entrega de Servicio

Antes de poder introducir el nuevo modelo para ofrecer servicios del cual
se ha estado haciendo referencia en este documento, es esencial profundizar
sobre el que ha operado hasta hoy en da: el modelo vertical (tambin conocido
como el Sndrome Silo). El diseo de los servicios comienza desde las capas
ms bajas donde se van desarrollando las funciones bsicas que conforman el
servicio, stas se van colocando una sobre la otra hasta formar el servicio que
se desea ofrecer [11]. La Figura 2.2 ayuda a visualizar mejor esta composicin.
En otras palabras, el diseo y construccin de un nuevo servicio se lleva a cabo
empezando siempre desde cero. La estructura del servicio forma un silo donde
el diseo y funcionamiento de cada capa es altamente dependiente de sus capas
inferiores y superiores.
El sndrome silo es el responsable de la falta de innovacin que se observa en
los ambientes cerrados de los operadores. La alta dependencia entre los mdulos
(o capas) de los silos dificulta hasta los cambios ms mnimos; de hecho, dichas
modificaciones son tan complejas que no valen la pena, y no suelen ser llevadas a
cabo. Al crear esta alta dependencia, los silos se aislan imposibilitando compartir
informacin entre ellos. Muchas veces, a pesar de ofrecer servicios distintos, los
15
2.2. Modelos de Entrega de Servicio Captulo 2. Marco Conceptual
Figura 2.2: Modelo Vertical (Sndrome Silo) [11]
silos comparten la misma informacin. Esta redundancia de informacin, ade-

ms de desperdiciar recursos, genera problemas administrativos, ya que no hay
manera de saber el silo que contiene los datos ms recientes de los usuarios.
Adems, al no poder reutilizar elementos de silos ya existentes, se genera ms
trabajo para los desarrolladores de servicios. La optimizacin y mejoras a los
silos no se pueden implementar de otra manera ms que empezando desde cero,
esto retrasa la creacin y adopcin de mejores servicios. Lo ms relevante para
los operadores es que el sndrome silo les proporciona enormes Gastos de Capital
(Capital Expenditure: CAPEX) y Gastos de Operacin (Operational Expendi-
ture: OPEX) debido a que cada silo requiere de especialistas que sepan cmo
trabaja para darle mantenimiento. Gran parte de los ingresos actuales de los
operadores se invierten en mantener silos que se derrumban ante exigencias que
ya no logran cumplir.
La manera de solucionar los problemas que presenta el sndrome silo es con
un modelo horizontal que integre todos los posibles mdulos de los silos a un
mismo nivel, permitiendo un acceso fcil a ellos donde la creacin de nuevos
servicios o aplicaciones sea la simple tarea de juntar los mdulos en distintas
combinaciones [11]. La Figura 2.3 ejemplifica este cambio con un diagrama.
Al contar con todas las herramientas para la creacin de servicios, el modelo
horizontal se convierte en una plataforma cuya funcin es agilizar la creacin y
16
2.3. IP Multimedia Subsystem Captulo 2. Marco Conceptual
Figura 2.3: Modelo Horizontal (Plataforma de Entrega de Servicios) [18]
despliegue de servicios.
2.3. IP Multimedia Subsystem

IMS es la Plataforma de Entrega de Servicios ideal para pasar a un modelo
horizontal ya que cuenta con funciones genricas que pueden ser utilizadas por
cualquier servicio dentro de una red [19]. Dichas funciones genricas no requieren
de especialistas en silos; basta con tener el conocimiento genrico de los servicios,
no el conocimiento de la infraestructura sobre la que trabajan [18]. IMS es el
elemento crucial para lograr la transicin hacia las NGNs. Forma la primer
propuesta por parte de la Open Mobile Alliance (OMA) para la creacin de una
Plataforma de Entrega de Servicios capaz de manejar distintos flujos en la red.
Es el encargado de administrar, enrutar e interconectar NGNs con la pluralidad
existente de redes actuales con interfaces abiertas. IMS permitir minimizar los
costos de los operadores y las tarifas de los usuarios al reducir el CAPEX y
el OPEX. Adems, acelera la innovacin de servicios, al reducir el Tiempo de
Lanzamiento al Mercado (Time to Market: TTM), contando con bloques de
servicio que son mezclados para la creacin de nuevas aplicaciones.
Esta Seccin presenta cmo IMS permite agilizar la transicin hacia la con-
vergencia digital y los elementos que aporta en esta crucial tarea; adems se
explica cmo este forma una Plataforma de Entrega de Servicios y las tecnolo-
gas en las que se basa para lograrlo.
17
2.3.1. Orgenes de IMS Captulo 2. Marco Conceptual
2.3.1. Orgenes de IMS

A pesar de ser un principal catalizador para el despliegue de redes NGN, IMS
[13, 5] fue creado bajo la visin de los operadores de telefona mvil. Surge como
una solucin para integrar servicios del Internet con redes de telefona mvil.
Su propsito es formar una arquitectura independiente del medio de acceso que
permita la interconexin con los usuarios de la telefona fija y mvil [38]. A
diferencia de los sistemas celulares de Tercera Generacin (3G) que ya cuentan
con conectividad hacia Internet, IMS busca una mejor integracin que permita
el control de QoS en el tipo de contenido que se le entrega al usuario. IMS
fue diseado para controlar sesiones de multimedia entre usuarios, as como
brindarle al operador la capacidad de adaptar su modelo de negocio para cobrar
adecuadamente segn el contenido que consuma el usuario, asegurando una QoE
y una reduccin de precios con un nuevo modelo de negocios.
Diversas organizaciones han sido atradas por la visin de IMS, algunas tra-
bajando en conjunto para aportar mejoras tecnolgicas, mientras que otras han
adaptado el modelo a sus propias necesidades. Por ejemplo, la versin de Third
Generation Partnership Project 2 (3GPP2) parte de las especificaciones de IMS
Release 5 y modifica nicamente las especificaciones acerca de la tecnologa de
acceso [14]. En cambio el Internet Engineering Task Force (IEFT) con la ayuda
del Third Generation Partnership Project (3GPP), han definido el funciona-
miento de IMS con tecnologas abiertas. OMA ha situado a IMS como una pieza
fundamental en su modelo de una Plataforma de Entrega de Servicios [11]. La
maduracin de IMS ha adoptado cuatro objetivos principales: (1) combinar las
ltimas tendencias tecnolgicas; (2) lograr el paradigma del internet mvil; (3)
la creacin de una plataforma comn que permita la creacin de servicios mul-
timedia; (4) la creacin de un mecanismo que aumente ingresos debido a su uso
en redes mviles [14].
2.3.2. Arquitectura IMS

Gracias a que 3GPP no estandariza nodos sino funciones, la arquitectura
de IMS consiste en una coleccin de funciones unidas por interfaces abiertas
estandarizadas [14]. Estas funciones pueden ser vistas como una conglomeracin
de funciones, o bien situadas dentro del plano lgico que las describe. IMS se
encarga del transporte y sealizacin de sesiones multimedia; adems provee las
herramientas necesarias para formar una Plataforma de Entrega de Servicios al
tener definidas funciones para ciertos servicios y aplicaciones bsicas. Algunas
18
2.3.2. Arquitectura IMS Captulo 2. Marco Conceptual
de las funciones que ofrece IMS son:
Figura 2.4: Arquitectura IMS [19]
1. Bases de datos que contienen informacin del usuario, as como los servi-
cios que tiene habilitado. Uno de ellos es representado por Home Subscriber
Server (HSS) en la Figura 2.4.
2. Control de llamadas y sesiones capaz de ofrecer telefona tradicional bajo
el dominio IP. Forman el ncleo de IMS al controlar los flujos existentes
dentro de l. Se emplea primordialmente en establecer reglas de ruteo. Son
representados por Call/Service Control Function (CSCF) en la Figura 2.4.
3. Servidores de Aplicaciones (Application Servers: AS) que forman bloques
bsicos capaces de ofrecer distintos servicios de telecomunicaciones. Repre-
sentados por el plano de servicios de la Figura 2.4, entre ellos se encuentran
servicios de telefona, correo de voz, videoconferencias, video en demanda
y presencia, entre otros.
4. Funciones de pasarela (gateway) hacia PSTN, como hacia otras redes.

Representados por Media Gateway Control Function (MGCF) y Media
Gateway (MGW) en la Figura 2.4.
19
2.3.3. Componentes IMS Captulo 2. Marco Conceptual
5. Funciones para controlar, procesar y transportar multimedia. stas no se

logran apreciar en la Figura 2.4, pero se sitan en los planos de control y
conectividad.
Existe una definicin para cada una de las interfaces abiertas que interco-
nectan las distintas funciones de IMS. Como la descripcin de cada una de estas
interfaces esta fuera de los objetivos de esta tesis, se mencionar nicamente
que estas interfaces se dividen en tres principales grupos, cada uno encargado
de lo siguiente:
1. Transporte de multimedia, que se logra con la ayuda de distintos protoco-

los dependiendo del dispositivo que accede al servicio. Dichos protocolos
podran ser Real-Time Transport Protocol (RTP) o H.323.
2. Sealizacin entre las funciones y el UE que permite establecer una sesin

SIP con el usuario.
3. Autenticacin, Autorizacin y Contabilizacin (Authentication, Authori-

zation and Accounting: AAA) que garantiza una comunicacin segura en-
tre el usuario y sus servicios, o bien entre distintas funciones que requieren
mtodos sofisticados para asegurar la autenticidad de la sealizacin in-
tercambiada. Dicho proceso de AAA se logra con la ayuda del protocolo
Diameter.
2.3.3. Componentes IMS

Para lograr una mejor comprensin de IMS y su funcionamiento no es nece-
sario explicar cada uno de los elementos que conforman su arquitectura. Basta
con profundizar sobre los componentes que forman el ncleo de IMS en el plano
de control e interconexin (HSS y CSCF) y los componentes que forman el plano
de servicios (AS).
2.3.3.1. Repositorios de Informacin

El Home Subscriber Server (HSS) registra toda la informacin acerca de los
usuarios y servicios dentro de un dominio IMS [14, 38]. El HSS registra todos
los distintos perfiles, identidades y credenciales que conforman los usuarios pa-
ra realizar AAA; adems contiene informacin acerca de los distintos servicios
20
que tienen habilitados as como el Serving-CSCF (S-CSCF) al que se registra-

ron, permitiendo saber su punto de conexin y habilitar servicios de itinerancia
(roaming). En cuanto a los servicios, contiene reglas para permitir o negar su
acceso de manera automtica. Para permitir la interconexin con distintas re-
des tambin cuenta con parmetros de calidad que permiten la comunicacin
exitosa entre clientes de distintas tecnologas de acceso [38]. En caso de que un
solo HSS no tenga la capacidad de almacenar toda esta informacin se cuenta
con un Service Location Function (SLF) el cual es una simple relacin entre los
usuarios y servicios cuya administracin se delega al HSS. Esto permite escalar
la funcionalidad de los repositorios de informacin al repartir los registros entre
varis HSS y administrar los registros mediante un SLF.
2.3.3.2. CSCF
Call/Service Control Function (CSCF) es la funcin que controla las lla-
madas y sesiones dentro de IMS. Se encarga de establecer, destruir y enrutar
llamadas, tratando stas como sesiones SIP. Por s solo proporciona un ambiente
para ofrecer servicios de telefona tradicional dentro del dominio IP. Junto con
HSS forma el ncleo de IMS el cual permite migrar la telefona tradicional del
mundo de circuitos al mundo de paquetes. Para cumplir con esta tarea exigente
CSCF se descompone en tres funciones especializadas: Proxy-CSCF (P-CSCF),
Interrogating-CSCF (I-CSCF), y S-CSCF.
2.3.3.3. P-CSCF
Proxy-CSCF (P-CSCF) acta como un proxy SIP entre el UE y el dominio
IMS [14]. Tiene cuatro principales funciones las cuales son empleadas para co-
menzar y finalizar la comunicacin entre el UE y el dominio IMS. Se encarga de
realizar la compresin del protocolo SIP con el objetivo de minimizar el uso del
ancho de banda de la red de acceso. Autentica al usuario, evitndole esta tarea
a las dems funciones CSCF al realizar asociaciones de seguridad con Internet
Protocol Security (IPSec), permitiendo garantizar la integridad de los mensajes
SIP intercambiados. Es el encargado de establecer las polticas que reservan los
recursos multimedia necesarios, as como garantizar la QoS solicitada va Policy
Decision Function (PDF). Dado que IMS piensa reemplazar la telefona tradi-
cional, se requiere ajustar a las necesidades regulatorias de emergencia (como
son llamadas al 911 y servicios de operador) [11]; P-CSCF se encarga de detec-
tar estas llamadas y enrutarlas con el trato especial que exigen [38]. El P-CSCF
21
puede localizarse dentro o fuera del dominio IMS.
2.3.3.4. I-CSCF
Interrogating-CSCF (I-CSCF) se encarga de interrogar las solicitudes gene-
radas por los usuarios con el fin de determinar el dominio IMS o Serving-CSCF
(S-CSCF) destino al cual se dirige la sesin para ser atendida exitosamente; den-
tro de esta capacidad se incluye la obtencin del nombre del siguiente elemento
que atender la solicitud. Adicionalmente determina si el S-CSCF cuenta con
la capacidad necesaria para atender las solicitudes despues de consultar con el
HSS [38]. El I-CSCF normalmente se encuentra en las orillas de cada dominio
IMS, aunque es posible que se encuentre fuera del dominio. Cuando se decide
ocultar la topologa de la red mediante tcnicas Topology Hiding Internetwork
Gateway (THIG), el I-CSCF se encarga de encriptar los encabezados correspon-
dientes [14].
2.3.3.5. S-CSCF
Serving-CSCF (S-CSCF) es la funcin ms importante del CSCF ya que se
encargada de enrutar las llamadas y sesiones hacia su destino final. Adems de
que se encarga de comunicar al usuario con el AS (salvo aquel que fue contactado
por el I-CSCF). Primeramente verifica la autenticidad de los usuarios consul-
tando al HSS, despus registra la localizacin del usuario en el HSS haciendo
un mapeo entre la direccin IP del que acede el usuario y su identidad pblica,
finalmente verifica que el usuario tenga activado el servicio al cual desea acceder
[38].
2.3.3.6. Servidores de Aplicaciones

Los Servidores de Aplicaciones (Application Servers: AS) componen el plano
de servicios y aplicaciones de IMS. Su definicin es genrica con la finalidad
de impulsar la creacin de nuevos servicios y aplicaciones atractivas. A pesar
de que frecuentemente manejan diversos protocolos para habilitar la entrega
de contenidos especficos, hacen uso de SIP y el Protocolo de Descripcin de
Sesin (Session Description Protocol: SDP) para permitir entablar una comu-
nicacin exitosa con S-CSCF y establecer sesiones con sus usuarios registrados.
El cambio fundamental entre los AS y los servicios de Internet disponibles en
la actualidad es que los primeros poseen la habilidad de incorporarse a IMS con
22
2.3.4. Usuarios dentro de IMS Captulo 2. Marco Conceptual
la ayuda de SIP, mientras que los segundos carecen de esta funcionalidad. Los
AS proporcionan los bloques bsicos que ofrecen servicios de telecomunicaciones
dentro de IMS y permiten tapizar el plano de servicio con una rica gama de
nuevas herramientas (como mensajera, voz, video y presencia) para la creacin
de nuevos servicios con un mnimo esfuerzo. La creacin de servicios se convierte
en la tarea de juntar distintos AS de una manera original, generando servicios
novedosos.
2.3.4. Usuarios dentro de IMS

Toda red requiere identificar de manera nica a sus usuarios [14], en particu-
lar si tiene como objetivo mejorar la QoE como es el caso de IMS. Anteriormente
PSTN empleaba los nmeros telefnicos para identificar a sus usuarios. Bajo el
esquema de IMS los usuarios se identifican mediante Perfiles, los cuales se com-
ponen de al menos una Identificacin Privada de Usuario y un Perfil de Servicio
[38]. Adems, los usuarios dentro de IMS poseen dos tipos de identificaciones:
la pblica y la privada.
2.3.4.1. Identificacin Pblica de Usuario

La Identificacin Pblica de Usuario es aquella que se conoce fuera del do-
minio IMS del operador. En otras palabras, es la manera en que el usuario
se identifica ante el mundo. Esto permite que un usuario pueda utilizar varios
UEs con distintas funcionalidades y capacidades con la misma cuenta de usuario
[38]. Estos se componen de al menos un Telephone Universal Resource Identifier
(TEL-URI) [45] o bien un Session Initiation Protocol Universal Resource Iden-
tifier (SIP-URI) [14]. El formato de SIP-URI se presenta en la Seccin 2.3.6.2.
Dentro de IMS las identificaciones pblicas son empleadas para enrutar sea-
lizacin SIP [14]. Se pueden registrar simultneamente varias identificaciones
pblicas de manera implcita, ahorrando ancho de banda y recursos de red [14].
Adems esto permite utilizar el mismo UE con distintas identificacines simul-
tneamente.
2.3.4.2. Identificacin Privada de Usuario

La Identificacin Privada de Usuario es aquella que nicamente es conocida
por el dominio IMS del operador [38]. Es empleada para realizar la autenticacin
y suscripcin [14]. Dado que son empleadas primordialmente entre los UEs y el
23
2.3.5. Tarificacin Captulo 2. Marco Conceptual
operador, stas pueden o no ser conocidas por el usuario [14]. Es importante

mencionar que la Identificacin Privada no identifica al usuario, como lo hace
la Identificacin Pblica, sino que identifica su subscripcin dentro del dominio
IMS [38]. Un usuario puede poseer varias Identificaciones Pblicas, mientras
que nicamente puede poseer una Identificacin Privada [14], ya que sta posee
una subscripcin con el operador y puede tener distintos UEs para acceder a sus
servicios. A partir del Release 6 de IMS, un usuario puede tener ms de una subs-
cripcin, pero se contina respetando la relacin N:M entre las Identificaciones
Pblicas (N) y Privadas (M), donde N > M.
2.3.4.3. Perfil de Servicio

El Perfil de Servicio es un conjunto de informacin almacenado dentro del
HSS que detalla los servicios que tiene registrado el usuario [38]. Dicha infor-
macin es intercambiada entre el HSS y S-CSCF cuando un usuario solicita
acceder a cualquier servicio; nicamente le provee el servicio a los usuarios que
cumplen con los criterios definidos [38]. El perfil de servicio se descompone en
tres principales atributos [38]:
1. Identificacin Pblica: SIP-URI que identifica al servicio

2. Autorizacin de Servicio: reglas definiendo quienes pueden acceder al ser-
vicio
3. Criterio de Filtrado Inicial (Initial Filter Criteria: iFC): reglas empleadas
por S-CSCF para determinar la ruta hacia el AS que surte dicho servicio,
as como las condiciones en las que se puede acceder al servicio
2.3.5. Tarificacin
IMS tiene la ambiciosa tarea de establecer distintas polticas de cobranza
para los diversos escenarios que se le pueden presentar. Esta Seccin har una
breve descripcin de los distintos esquemas de tarificacin soportados por IMS
en su Release 6 presentados en Julio del 2005.
2.3.5.1. Tarificacin Fuera de Lnea

La Tarificacin Fuera de Lnea (Offline Charging), es aquella encargada de
cobrar por un servicio despus de que se haya consumido. En otras palabras,
24
2.3.6. Tecnologas y Protocolos Usados Captulo 2. Marco Conceptual
es un proceso que se encarga de obtener las variables de tarificacin despus

de que se haya concluido una sesin [38]. Adems, no interfiere en tiempo real
con dicha sesin [38]. Este esquema puede ser utilizado al momento de generar
peridicamente una factura que se le cobra al usuario.
2.3.5.2. Tarificacin En Lnea

La Tarificacin En Lnea (Online Charging), es aquella encargada de cobrar
por un servicio en tiempo real. El propsito de este esquema de tarificacin
es validar la cuenta financiera del usuario antes de permitirle el acceso a los
servicios o recursos de IMS [38]. Este esquema normalmente es usado al momento
de cobrar por servicios de pre-pagado.
2.3.5.3. Tarificacin Basada en Flujos

La Tarificacin Basada en Flujos (Flow-based Charging), es presentada por
IMS para establecer un esquema de tarificacin granular [38]. Este esquema
permite cobrar por flujos de servicio identificados por filtros de servicio [38].
Posteriormente se pueden aplicar polticas de cobranza especializadas para di-
chos flujos de servicio [38]. Este esquema puede ser aprovechado para definir
polticas de cobranza especializadas dependiendo del tipo de servicio que consu-
ma el usuario.
2.3.6. Tecnologas y Protocolos Usados

La construccin de los componentes IMS se realiza con tecnologas abier-
tas tomadas del mundo del Internet. IETF y 3GPP trabajan en conjunto para
mejorar las carencias actuales de estas tecnologas. El uso de los protocolos des-
critos en esta Seccin proporciona los planos de transporte, control y servicio
que requiere IMS. Es importante mencionar que IMS, al trabajar sobre una red
Todo-IP tambin puede trabajar con cualquier protocolo que est diseado
para su uso sobre IP.
2.3.6.1. IPv6
IMS fue concebido con el Protocolo de Internet versin 6 (Internet Protocol
v6: IPv6) en mente por dos principales razones: (1) su adopcin masiva iba a
requerir ms direcciones de las disponibles bajo el Protocolo de Internet versin
25
4 (Internet Protocol v4: IPv4); (2) requerira del uso de direcciones pblicas para
evitar los problemas que enfrentaban los protocolos SIP y RTP en presencia de
dispositivos de Traduccin de Direcciones de Red (Network Address Transla-
tion: NAT) [14]. Aunque por necesidades de mercado a partir del Release 6 se
incorpora compatibilidad con IPv4 [14], a pesar de que las decisiones y mejoras
a IMS son tomadas suponiendo el uso de IPv6.
Actualmente el principal problema de IMS sobre IPv4 se presenta al enfren-
tarse con dispositivos NAT. Aunque existen soluciones como bien lo demuestran
[12, 58, 59] ya sea mediante configuraciones especficas para cada cliente, o bien
utilizando el mismo NAT como gateway, el futuro de IMS depende de la transi-
cin hacia IPv6. Quizs la adopcin masiva de IMS ayude a lograr la transicin
hacia IPv6 en las empresas.
2.3.6.2. SIP
Los orgenes de SIP [25, 41] se remontan a 1992 cuando el IETF decidi
conveniente realizar conferencias de multimedia sobre el protocolo IP; en 1996
es usado con bastante frecuencia para realizar seminarios y conferencias; en 1999
se extiende su funcionalidad para realizar la sealizacin de Voz sobre IP (Voice
over IP: VoIP) [38]. SIP fue creado como un protocolo muy bsico, que debido a
su facilidad de uso y posibilidad de aadirle extensiones se convierte en el proto-
colo con la larga historia que tiene hoy en da y difcil documentacin. En cuanto
a su relevancia en IMS, SIP es el encargado de realizar toda la sealizacin entre
las funciones IMS que no requieren de AAA.
El funcionamiento de SIP se basa en el HyperText Transfer Protocol (HTTP)
[21], donde la comunicacin se realiza mediante solicitudes (Request) y respues-
tas (Response) entre cliente y servidor [14]. Los mensajes SIP siguen el formato
que muestra la Figura 2.5. La primer lnea del mensaje SIP contiene el mto-
do solicitado o bien su estatus dependiendo si ste es un Request o Response.
El Cuadro 2.2 profundiza sobre los mtodos que soporta SIP, mientras que el
Cuadro 2.1 muestra los valores de estado de los mensajes. Despus se incluyen
los encabezados obligatorios que identifican la sesin adems de los encabeza-
dos adicionales que pueden ser empleados por el mtodo indicado en la primer
lnea del mensaje SIP. Los encabezados de SIP son usados dentro de IMS para
establecer reglas definiendo las condiciones donde los servidores de aplicaciones
atienden las solicitudes correspondientes. Finalmente los mensajes SIP pueden
contener un cuerpo con informacin relacionada con los encabezados; por ejem-
26
Figura 2.5: Formato de Mensaje SIP [37]
plo, la notificacin de eventos, mensajes instantneos, y datos de sesin, entre

otros [38].
Como se menciona en la Seccin 2.3.4, SIP-URI se emplea dentro del domi-
nio de IMS para las Identidades Pblicas de Usuarios y como direccin lgica
dentro de la red. SIP-URI [41] se basa en la sintaxis del Identificador de Re-
curso Universal (Universal Resource Identifier: URI) [9] para hacer referencia a
cualquier elemento nico dentro del mundo IP. La sintaxis es la siguiente:
sip:usuario@proveedor:puerto;parametros;encabezados [38]
Dicha sintaxis permite identificar instantneamente al usuario, su proveedor

de servicios y parmetros adicionales; simplifica el proceso de realizar llamadas
Rango Estatus Significado

100 - 199 Provisional (Informational) muestra informacin adicional
200 - 299 Success mensaje enviado exitosamente
300 - 399 Redirect mensaje fue redirigido
400 - 499 Client Error error generado por parte del cliente
500 - 599 Server Error error generado por parte del servidor
600 - 699 Global Failure error generado globalmente
Cuadro 2.1: Cdigos de Estado SIP
27
Nombre Significado
ACK Notifica la aceptacin de un INVITE
BYE Concluye la sesin
CANCEL Cancela una solicitud pendiente
INFO Transporta sealizacin PSTN
INVITE Establece una sesin
NOTIFY Notifica acerca de eventos ocurridos
OPTIONS Solicita las capacidades del servidor
PRACK Notifica la aceptacin de un Response provisional
PUBLISH Sube informacin al servidor
REGISTER Realiza el mapeo entre el SIP-URI y una direccin IP
SUBSCRIBE Solicita ser notificado acerca de eventos
UPDATE Modifica alguna caracterstica de las sesiones
MESSAGE Contiene un mensaje de texto
REFER Indica al servidor enviar un Request
Cuadro 2.2: Mtodos SIP
para el usuario, ya que es ms fcil recordar nombres que secuencias de nmeros

como son las direcciones IP, o los nmeros telefnicos. Adicionalmente se le
puede aadir seguridad a SIP-URI mediante Transport Layer Security (TLS),
donde la diferencia en la sintaxis se percibe con el prefijo sips en vez de sip
[14, 38].
A pesar de que IMS es criticado por no usar una versin estndar de SIP [31],
ste es mejorado va propuestas del 3GPP al IETF para incorporar sus modifi-
caciones de SIP al siguiente Request for Comments (RFC) [14]. Las mejoras que
ha incorporado IMS a SIP son el uso de encabezados adicionales describiendo
las capacidades del cliente al momento de registrarse con el P-CSCF. Algunos
encabezados son:
1. Supported: contiene una lista de los mtodos que soporta el dispositivo

2. Require: contiene una lista de los mtodos que quiere utilizar el cliente
para comunicarse
3. Unsupported: contiene un mensaje de error de los mtodos que no soporta
el dispositivo; ste es enviado como respuesta al encabezado Require
28
4. Allow: contiene una lista de los mtodos que soporta el dispositivo; ste
es enviado como respuesta al encabezado Require
5. History-Info: permite rastrear el origen del mensaje SIP
6. P-Called-Party-ID: permite conservar el Request-URI despues de en-

rutar los mensajes SIP
2.3.6.3. Session Description Protocol

SDP [7, 24] es un protocolo a nivel de aplicacin encargado de describir se-
siones de multimedia [38]. Incluye toda la informacin necesaria para establecer
una sesin entre UEs, como son las capacidades de los dispositivos, los protoco-
los empleados para entregar multimedia y los puertos de comunicacin [14, 38].
Por s solo SDP no puede ser un protocolo ya que nicamente es una descripcin
de propiedades de sesin en forma de texto [14], por eso se incorpora dentro del
cuerpo de los mensajes INVITE de SIP que establecen la sesin. Contiene tres
tipos de informacin:
1. Descripcin de Sesin: contiene informacin correspondiente al nivel de

sesin como las direcciones IP y datos de usuarios [38].
2. Descripcin de Tiempo: contiene tiempos de inicio, fin y nmero de repe-

ticiones permitidas para indicar si la sesin est activa y la cantidad de
veces que se pueden retransmitir mensajes [38].
3. Tipo y Formato de Multimedia: contiene informacin de multimedia, puer-
tos empleados, y otros parmetros propios del tipo multimedia [38].
2.3.6.4. Diameter
Diameter [13] es desarrollado por el IETF para lograr las funciones de AAA
[38]. En IMS es usado para garantizar una comunicacin y sealizacin confiable
entre algunas funciones de IMS. Tambin se emplea por el S-CSCF para realizar
funciones AAA con el UE. SIP junto con Diameter forman el plano de control
de IMS, encargados de negociaciar la QoS, autenticacin del usuario y control
de sesiones.
29
2.4. Servicios Basados en Localizacin Captulo 2. Marco Conceptual
2.3.6.5. RTP/RTCP y H.323

Real-Time Transport Protocol (RTP) [47] y Real-Time Transport Control
Protocol (RTCP) [47] se encargan en conjunto de la entrega, monitoreo y QoS
de multimedia sobre IP. H.323 [30, 46] tambin tiene el mismo objetivo, con la
diferencia de que fue desarrollado por la ITU y no el IETF. Ambos son usados
bajo IMS para transportar multimedia; el uso de uno u otro depende de la red
de acceso en la cual se encuentra el usuario.
2.3.6.6. IPSec y TLS

Juntos Internet Protocol Security (IPSec) [32] y Transport Layer Security
(TLS) [17] son usados dentro del dominio IMS para garantizar la integridad
y confiabilidad de los mensajes en el plano de control. TLS, basado en Secure
Socket Layer (SSL) [23], es usado primordialmente para proteger los mensajes
SIP entre las distintas funciones IMS, as como aadirle seguridad a cualquier
tipo de informacin que viaje por la red [14]. IPSec a su vez se especializa en
agregar seguridad a los mensajes intercambiados entre el UE y los gateways [38].
2.4. Servicios Basados en Localizacin

La localizacin se conoce como la distancia geomtrica entre un punto en
un momento dado y un punto de referencia predeterminado, el mtodo de refe-
rencia con mayor aceptacin mundial es el uso de coordenadas geogrficas [26].
Por obvio que parezca, los usuarios mviles siempre han requerido de servicios
adicionales que conozcan su localizacin. Por ejemplo, establecer las reglas de
hand-over entre clulas, o permitir el servicio de roaming entre distintos opera-
dores.
Trasladando el concepto de localizacin a servicios de alto nivel se puede
ofrecer servicios muy atractivos; es ms, con la modificacin apropiada, incluso
se pueden ofrecer servicios personalizados. Los Servicios Basados en Localiza-
cin (Location Based Services: LBS) son aquellos cuyo funcionamiento o modo
de operacin depende de la localizacin del usuario [11]. En el caso de las NGN,
los LBS son empleados desde el escenario ms simple donde toma decisiones a
partir de la red de acceso en la que se encuentra el UE hasta los escenarios ms
complejos donde el usuario consume distintos servicios y contenidos personali-
zados dependiendo de sus actividades sociales y laborales.
30
2.4.1. Mtodos de Localizacin Captulo 2. Marco Conceptual
Un ejemplo prctico e ilustrativo de un LBS es el concepto de un Sticky-

Note Virtual [10]. Este servicio enva un Mensaje Corto (Short Message Service:
SMS) [4] a aquellos que entran a una rea determinada de la empresa con el
objetivo de comunicar informacin pertinente a esa rea por un determinado
perodo de tiempo. Este tipo de servicios tienen un enorme potencial para ofre-
cer servicios personalizados. Al saber los servicios que normalmente consume el
usuario en ciertas reas geogrficas se podrn ofrecer servicios en funcin del
comportamiento del usuario, logrando una personalizacin en los servicios.
2.4.1. Mtodos de Localizacin

Debido a que no todos los LBS requieren del mismo grado de precisin ni
poseen la misma tolerancia al retardo, se han desarrollado diversos mtodos
de localizacin [26]. Actualmente existen cuatro principales metodologas: (1)
preguntarle al usuario, (2) el Sistema de Posicionamiento Global (Global Posi-
tioning System: GPS), (3) apoyndose en las redes de acceso o (4) una combi-
nacin de (2) y (3) [26]. El primer punto lo descartamos ya que es imposible que
el usuario conozca su localizacin sin utilizar alguno de los otros puntos.
2.4.1.1. GPS
GPS funciona con base en 24 satlites en seis rbitas distintas y cinco es-
taciones de monitoreo esparcidos por el globo terrqueo [26]. En cada rbita
circulan cuatro satlites. En cualquier momento, el UE del usuario puede recibir
seales de por lo menos cinco y a lo ms once satlites a la vez [44]. Su fun-
cionamiento es bastante sencillo, ya que a partir de las seales que reciben de
los satlites el UE calcula distancias y estimaciones de posicin y tiempo en un
proceso llamado trilateracin [44]. La lgica es que se conoce tanto la distancia
entre la tierra y los satlites as como su localizacin en el espacio, por lo cual
determinar la localizacin del UE requiere de un simple clculo [26]. Desarro-
llado por el Departamento de Defensa de Estados Unidos, permite estimaciones
precisas de localizacin.
2.4.1.2. Asistida Va Red Celular

Otra popular alternativa es con la ayuda de la red telefnica celular. Las
estaciones base (antenas) celulares no cambian de lugar, su localizacin es fija,
por lo cual se puede hacer uso de varias tcnicas que permitan localizar los
31
2.4.2. Presencia Captulo 2. Marco Conceptual
Figura 2.6: Localizacin Relativa Usando la Sectorizacin de Antenas
usuarios de telefona celular. Sabiendo el identificador de la estacin base que

atiende al UE, y el retardo que experimenta la comunicacin entre ellos se puede
determinar la distancia entre el usuario y la estacin, conociendo su localizacin
con un cierto grado de error [26]. Adems la sectorizacin de las antenas permite
conocer la orientacin del usuario con respecto a la estacin base y mejorar la
precisin en el clculo de su localizacin [26]. El rea sombreada de la Figura 2.6
muestra la posible localizacin de un usuario utilizando este mtodo.
2.4.1.3. Asistida Va Puntos de Acceso

El Sistema de Posicionamiento Inalmbrico (Wireless Positioning System:
WPS) se apoya sobre los AS de las redes inalmbricas para obtener la localiza-
cin del usuario [26]. Obviamente se requiere conocer previamente la localizacin
de los Puntos de Acceso (Access Points: APs). stos generalmente estn regis-
trados en una base de datos mantenida por especialistas de datos encargados de
recolectar dicha informacin. Haciendo uso de un algoritmo bastante complejo
se puede calcular la localizacin del usuario con un buen nivel de precisin [26].
2.4.2. Presencia
Presencia se puede definir como la conectividad de una persona [11]. Di-
cha conectividad en el mundo de IMS se representa como el perfil dinmico del
usuario usado para representarse, controlar servicios y compartir informacin
[38]. El concepto de presencia tiene su origen en el Internet con los chats don-
de los usuarios notifican a los dems su estado de disponibilidad con el fin de
32
2.4.3. XDMS Captulo 2. Marco Conceptual
lograr una comunicacin ms personal en un ambiente poco personal [14]. La

presencia de los usuarios en el mbito NGN define al usuario y permite que
la red sea inteligente en cuanto al reconocimiento del usuario (en particular su
presencia) y no sus UEs. Con este conocimiento, la red posee la capacidad de
volverse transparente hacia el usuario cumpliendo uno de los objetivos de NGN.
Lo atractivo de IMS, y por consecuencia de NGN, es que permite ofrecer LBS
con la ayuda de AS que ofrezcan servicios de presencia. Estos servicios consisten
en el manejo de perfiles de presencia (conocidos como presentity o presentidad)
[14, 38], administran permisos para ver la presentidad de los usuarios, y ade-
ms tienen la capacidad de manejar informacin personalizada relacionado con
servicios adicionales.
2.4.3. XDMS
XML Document Manager Server (XDMS) [27] es el servidor encargado de
ofrecer servicios de presencia. Este servidor funciona como un repositorio de in-
formacin que administra los Formato de Documentos de Presencia (Presence
Information Data Format: PIDF)s y los documentos de presencia de los usuarios.
Para interactuar exitosamente con usuarios dentro del contexto de IMS, XDMS
Figura 2.7: Servidor de Presencia
33
2.4.4. Documento de Presencia Captulo 2. Marco Conceptual
es implementado como un AS que soporta XML Configuration Access Protocol

(XCAP) y Resouce List Server (RLS). La Figura 2.7 muestra la relacin exis-
tente entre todos los componentes que conforman un XDMS. Conociendo con
precisin los datos que almacena XDMS, as como su funcionamiento, fcilmente
se pueden disear y desarrollar servicios personalizados.
2.4.4. Documento de Presencia

El servidor de presencia guarda toda su informacin en archivos eXtensi-
ble Markup Language (XML) que describen tanto la presentidad de los usuarios
como las polticas que definen su uso dentro del servidor de presencia [14]. El For-
mato de Documentos de Presencia (Presence Information Data Format: PIDF)
[50] es un archivo Definicin Esquema de XML (XML Schema Definition: XSD)
que define el uso y configuracin de los documentos de presencia. El Cuadro 2.3
muestra un ejemplo del formato que siguen los documentos de presencia. Es-
tos documentos emplean un modelo minimalista en cuanto a que nicamente
registran la informacin necesaria con el fin de permitir una fcil reutilizacin
con otros protocolos y proveen una alta flexibilidad en cuanto al tipo de infor-
macin que contienen [14]. Los PIDF definen tres principales atributos de las
presentidades:
1 <?xml version ="1.0" encoding ="UTF -8"?>

2 <presence xmlns ="urn:ietf:params:xml:ns:pidf"
3 entity =" pres:alice@astrea.ipv6.itam.mx">
4 <tuple id=" abc123">
5 <status >
6 <basic >open </basic >
7 </status >
8 <contact priority ="0.8" > tel :+525556284000 </ contact >
9 </tuple >
10 </presence >
Cuadro 2.3: Ejemplo de Documento de Presencia
Servicio: Dependiendo del servicio que tenga activado se le pueden ofrecer al

usuario distintas modalidades de operacin y contenidos [14].
Dispositivo: Da conocer el UE usado por el usuario para acceder a la red, sirve
34
2.4.5. XCAP Captulo 2. Marco Conceptual
para determinar los tipos de contenidos que est dispuesto a recibir, o bien
las facilidades con las que cuenta ese dispositivo [14].
Persona: Muestra el estado de nimo del usuario, lo cual impacta directamente
en su disposicin para entablar una conversacin [14]. Esto generalmente
se traduce en un mensaje que refleja la disponibilidad del usuario.
2.4.5. XCAP
La diversidad de protocolos existentes para el intercambio de informacin es
una verdadera pesadilla, lo cual da lugar a la creacin de un protocolo sencillo
que utiliza tecnologas igualmente sencillas para administrar cantidades masi-
vas y genricas de informacin: XML Configuration Access Protocol (XCAP).
XCAP [40, 42] hace uso de XML para almacenar los datos en el servidor de pre-
sencia y del protocolo HTTP para transportar datos entre el UE y el servidor
de presencia [38]. Se recomienda aadir seguridad al protocolo XCAP usando
HyperText Transfer Protocol over SSL (HTTPS).
XCAP se encarga de transportar documentos XML (definidos por un PIDF)
los cuales sirven para determinar polticas en la entrega de servicio o bien mo-
nitoreo de presentidades. Lo extraordinario es que logra esto simplemente con
tres instrucciones: put, get, y delete que como sus nombres lo dicen, agregan,
quitan u obtienen los PIDFs almacenados en el servidor. La creacin de PIDFs
especializados permite definir servicios adicionales ofrecidos por el servidor de
presencia.
2.4.6. RLS
Resouce List Server (RLS) [39] es el servidor encargado de desplegar las pre-
sentidades de los usuarios a sus contactos. Para poder difundir adecuadamente
la informacin nicamente a los destinatarios deseados, RLS utiliza el concepto
de watchers; stos son usuarios quienes vigilan las presentidades de otros usua-
rios [14]. A su vez, los usuarios vigilados tienen la capacidad de decidir quin los
vigila especificando polticas de admisin en los PIDFs y almacenndolos en el
XDMS va XCAP [38]. Despus de establecer dichas polticas, los usuarios pue-
den autorizar o dar de baja watchers de una manera dinmica. De esta manera,
XDMS est ntegramente ligado al funcionamiento de RLS.
El funcionamiento del despliegue de informacin que maneja RLS consiste
en el intercambio de mensajes SIP donde los usuarios publican su presentidad
35
2.4.6. RLS Captulo 2. Marco Conceptual
en el servidor y ste le notifica la presentidad actual a watchers autorizados

[14, 38]. Posteriormente cualquier cambio a las presentidades de los usuarios
son actualizadas mediante la creacin de eventos en los mensajes SIP. RLS es la
ltima pieza requerida para ofrecer servicios personalizados ya que le proporciona
a IMS un AS capaz de ser controlado va mensajes SIP y permite el conocimiento
de presentidades las cuales sern usadas al momento de establecer polticas en
el diseo de servicios personalizados.
36
Captulo 3
Construccin de la
Maqueta IMS
Parte del alcance de este trabajo de tesis consiste en desplegar una maqueta
IMS dentro del Laboratorio de Redes Avanzadas del Instituto Tecnolgico Au-
tnomo de Mxico (ITAM) con el fin de proporcionar los bloques de servicio de
telecomunicaciones bsicos sobre los cuales se apoyan los servicios personaliza-
dos desarrollados. La construccin de una maqueta IMS le brinda al ITAM un
ambiente de desarrollo para futuros proyectos que requieran de la infraestructura
fsica que proporciona. Este Captulo se concentra en el diseo e implementacin
de la maqueta en el Laboratorio de Redes Avanzadas.
3.1. Objetivos y Requerimientos

Al ser IMS una plataforma de estndares abiertos, se decidi construir la
maqueta a partir de diversas herramientas de Software Libre y Abierto (Free
and Open Source Software: FOSS) con el propsito de desplegar una plataforma
sin limitaciones en cuanto a licencias y el uso que se le decida dar dentro de las
instalaciones del ITAM. La construccin se realiz a partir de herramientas
existentes que implementan cinco mdulos bsicos: (1) llamadas intra- e inter-
dominio, (2) pasarela (gateway) PSTN, (3) Servidor de Contenidos, (4) Servidor
de Presencia, (5) los clientes que hacen uso de la maqueta. Estos cinco mdulos
37
3.2. Dominios IMS Captulo 3. Construccin de la Maqueta IMS
cubren las necesidades y funcionalidades bsicas que provee una plataforma IMS
en el mbito empresarial.
3.2. Dominios IMS

Se decidi representar a dos operadores IMS dentro de la maqueta como do-
minios IMS. Al tener dos dominios IMS se puede analizar la interaccin existente
entre ellos y con los usuarios cuando stos hacen uso de los recursos de mltiples
operadores. El objetivo que se busca aqu es comprobar la funcionalidad de rea-
lizar llamadas intra- e inter-dominio; adems de demostrar que los usuarios de
la maqueta cuentan con servicios de roaming. Los dominios IMS cuentan con un
registro para administrar sus usuarios, adems de dictar las polticas de acceso
a los servicios con los que cuenta la maqueta.
Figura 3.1: Ncleo IMS [22]
El dominio IMS dentro de la maqueta se compone por el ncleo IMS, el

cual debe contar con los servicios bsicos que permiten realizar llamadas intra-
dominio. Habilitar dichos servicios se hace posible con la inclusin de los Reposi-
torios de Informacin y las funciones del CSCF (ver Seccin 2.3.3). El Fraunho-
fer Institute for Open Communications Systems (FOKUS) ha desarrollado una
herramienta llamada OpenIMS Core [22] que implementa el ncleo IMS. ste
cuenta con las subfunciones del CSCF (P-CSCF, I-CSCF y S-CSCF) y un HSS
como repositorio de informacin. La Figura 3.1 muestra los componentes que
aporta OpenIMS Core en la creacin de los dominios IMS. Las lneas conectan-
do los componentes de la Figura 3.1 sirven para ejemplificar como se comunica
cada componente entre s. El ncleo IMS sirve para dar cohesin a los AS con
38
3.3. Gateway PSTN Captulo 3. Construccin de la Maqueta IMS
la creacin de una Plataforma de Entrega de Servicios mediante su registro y la

definicin de polticas de acceso dentro de los dominios IMS.
3.3. Gateway PSTN

Para representar la interconectividad y compatibilidad que posee IMS con
otras tecnologas de red, se incluy un gateway telefnico que permite los clientes
de la maqueta interactuar con clientes PSTN. Se habilitaron llamadas de IMS a
PSTN y viceversa. Debido a que IMS utiliza el protocolo SIP como sealizacin,
se busc una Central Telefnica (Private Branch eXchange: PBX) que realizara
la conmutacin de llamadas a base de software; dicho software debe ser capaz
de realizar sealizacin tanto digital como analgica. La sealizacin digital
garantiza compatibilidad con IMS mediante sealizacin SIP; mientras que la
compatibilidad con PSTN se obtiene mediante el uso del Tono Doble de Multiple
Frecuencia (Dual-Tone Multi-Frequency: DTMF) y el Sistema de Sealizacin 7
(Signalling System 7: SS7). La interconexin de la maqueta con la red telefnica
interna del ITAM no requiere de funcionalidades especficas de SS7, por lo cual
basta con tener una PBX a base de software capaz de interpretar mensajes SIP
y seales DTMF.
La Tesis de Maestra de Fei Yao [59] aborda el tema de la interoperabilidad
entre las herramientas OpenIMS Core y Asterisk [35] (un PBX a base de soft-
ware) al momento de ofrecer soluciones empresariales de VoIP. Yao se enfoca en
analizar los problemas de compatibilidad originados en distintos UEs al momen-
to de ofrecer soluciones empresariales de VoIP a usuarios IMS. El ambiente de
pruebas descrito por Yao utiliza Asterisk para simular un proveedor de servicios
empresariales dentro de una maqueta IMS. Su anlisis consiste en evaluar la
interaccin de dichos servicios en los UEs de los usuarios de OpenIMS Core.
Su propuesta para la integracin de clientes SIP dentro de IMS consiste en
duplicar la funcionalidad del S-CSCF en dos entidades separadas. Un S-CSCF
que se dedica a procesar las peticiones de los usuarios IMS mientras que el
otro sirve como proxy para los usuarios que nicamente pueden intercambiar
mensajes SIP. En cambio, la integracin de servicios empresariales dentro de
IMS presenta complicaciones adicionales. A pesar de que Yao logra cumplir los
objetivos de su tesis al proponer una solucin a los problemas de compatibilidad
e interoperabilidad entre OpenIMS Core y Asterisk, no logr los resultados que
buscaba obtener, ya que en sus conclusiones menciona que la mejor integracin
39
3.3. Gateway PSTN Captulo 3. Construccin de la Maqueta IMS
es tener el ncleo IMS y Asterisk trabajando en paralelo para atender llamadas

[59].
Para los fines de ste trabajo de tesis, la solucin de Yao aporta la propuesta
de una posible integracin de servicios empresariales (especficamente aquellos
ofrecidos por Asterisk) dentro de una maqueta IMS. Esto es, Yao da la certeza de
poder utilizar Asterisk dentro de una maqueta IMS con limitada funcionalidad.
La maqueta construida para este trabajo de tesis mejora sobre los resultados
de Yao, logrando configurar Asterisk como un gateway hacia PSTN capaz de
conmutar las llamadas hacia los dominios IMS correctamente. Se mejor sobre
la funcionalidad obtenida en el trabajo de Yao, aadiendo a sta la capacidad
de integrar Asterisk y sus servicios al funcionamiento correcto de IMS como un
AS. Adems, se desarroll una configuracin personalizada dentro de Asterisk
que permite eliminar el S-CSCF adicional visto en el trabajo de Yao.
Lograr una mayor integracin que la obtenida por Yao requiere modificar
el cdigo fuente de Asterisk. Por default Asterisk revisa los encabezados de
SIP para rechazar aquellas solicitudes con parmetros que no soporta. Asterisk
trabaja con las especificaciones actuales de SIP. En cambio, IMS utiliza par-
metros adicionales a aquellos definidos en las especificaciones de SIP suponiendo
que sern adoptadas en la siguiente revisin del estndar. Esta incompatibilidad
obliga la configuracin default de Asterisk a rechazar las peticiones iniciadas por
los usuarios IMS. La modificacin al cdigo fuente elimina la verificacin que
realiza Asterisk, lo cual permite recibir y conmutar llamadas desde OpenIMS
Core. La construccin de este mdulo y sus modificaciones necesarias para una
integracin deseada en la maqueta se encuentran en [34].
Asterisk aporta varias funcionalidades a la maqueta, dentro de ellas se en-
cuentra la posibilidad de contar con una operadora virtual, buzn de voz, lla-
madas en espera, directorio y mltiples escenarios donde los clientes IMS se
comunican con clientes de distintos protocolos: SIP (sin IMS), H.323 y PSTN.
La Figura 3.2 muestra los distintos escenarios que se pueden lograr simular den-
tro de la maqueta IMS en cuanto a la compatibilidad con clientes de distintos
protocolos. Los usuarios de la red telefnica del ITAM pueden interactuar con
los usuarios de la maqueta IMS y viceversa. Asterisk tambin simula un opera-
dor de telefona digital que puede comunicarse con los dominios IMS usando los
protocolos SIP y H.323.
40
3.4. Servidor de Contenidos Captulo 3. Construccin de la Maqueta IMS
Figura 3.2: Diseo del Gateway PSTN
3.4. Servidor de Contenidos

Una maqueta IMS no puede estar completa sin tener la capacidad de ofrecer
servicios multimedia, por lo cual es necesario incluir un servidor responsable
de la entrega de contenido. Dicho servidor, adems de soportar tecnologas de
entrega de multimedia como son RTP y RTCP, debe ser capaz de comunicarse
con el ncleo IMS va mensajes SIP con el fin de establecer sesiones multimedia.
En lugar de buscar una herramienta que cuente con ambas funcionalidades se
opt por juntar dos herramientas para formar un AS que forma el Servidor de
Contenidos. Dicha solucin se realiza con la ayuda de Darwin Streaming Server
(DSS) [8] y UCT Advanced IPtv [55]. La Figura 3.3 muestra la interaccin entre
ambas herramientas y el usuario IMS. El usuario solicita el servicio al dominio
IMS mediante un mensaje SIP con el mtodo INVITE. El dominio IMS enva la
peticin al mdulo UCT IPTV del servidor de sontenidos el cual establece una
sesin SIP con el usuario y obtiene el canal RTP a partir del SIP-URI de la
peticin. Los mensajes SIP que intercambia con el usuario sirven para indicar
la localizacin del contenido, la cual es una direccin RTP del mdulo DSS
del Servidor de Contenidos. Finalmente, el usuario establece una sesin RTP
con DSS el cual le entrega el contenido solicitado. Al terminar la entrega del
contenido se concluyen las sesiones SIP y RTP establecidas con el usuario.
El Servidor de Contenidos le proporciona a la maqueta la capacidad de ofre-
cer servicios de Televisin va IP (IP Television: IPTV), Video en Demanda
(Video on Demand: VoD) y radio. En la prctica la composicin del Servidor
41
3.5. Servidor de Presencia Captulo 3. Construccin de la Maqueta IMS
Figura 3.3: Diseo del Servidor de Contenidos
de Contenidos presenta el problema de que sus mdulos no pueden colocarse

dentro del mismo servidor fsico, ya que operan sobre sistemas operativos dife-
rentes. Por lo tanto se decidi usar DSS desde una mquina corriendo Mac OS
X e instalar UCT Advanced IPtv en otra corriendo Linux. La configuracin del
Servidor de Contenidos consta de tres pasos:
1. Configuracin de playlists en DSS que ciclan infinitamente, simulando

canales de televisin tradicionales.
2. Instalacin de UCT Advanced IPtv y su configuracin que establece la
relacin entre el SIP-URI y el canal RTP.
3. Registrar el AS en los dominios IMS y definir los iFCs que habilitan el
servicio para usuarios registrados.
3.5. Servidor de Presencia

El Servidor de Presencia (XDMS) dentro de la maqueta sirve para cumplir
dos funciones: (1) ofrecer servicios de presencia a los clientes IMS y (2) almace-
nar sus preferencias para la entrega de servicios personalizados. Esta Seccin se
concentra en los requerimientos de XDMS. Tomando como base la Figura 2.7
detallada en la Seccin 2.4.3, se busc una solucin con herramientas FOSS que
permita llegar a una aproximacin de dicho diagrama. De todas las posibles
soluciones, la ms estable y viable result ser una combinacin de OpenXCAP
[6] y OpenSIPS [53] (anteriormente conocido como OpenSER). Estas dos he-
rramientas permite la construccin de un XDMS capaz de ofrecer servicios de
42
3.5. Servidor de Presencia Captulo 3. Construccin de la Maqueta IMS
RLS va SIP y la administracin de PIDFs va XCAP. La Figura 3.4 muestra

la manera que se comunican dichas herramientas con los clientes y ncleo IMS.
Figura 3.4: Diseo de XDMS
La Figura 3.4 muestra la inclusin de un elemento adicional llamado

OpenSIPS-mi-proxy que reemplaza un mdulo defectuoso de OpenSIPS encar-
gado de garantizar una comunicacin exitosa entre RLS y XCAP. Su funcin
es actuar como proxy habilitando a OpenSIPS la funcionalidad de manejar da-
tos va una interfaz XCAP. Adems su inclusin en XDMS logra garantizar la
integridad de informacin en los PIDFs ya que las modificaciones que realizan
OpenXCAP y OpenSIPS no son consistentes; este ltimo proporciona mayores
opciones de configuracin y formato, lo cual permiti personalizar los servicios
LBS. El protocolo de Ejecucin de Procedimiento Remoto XML (XML Remote
Procedure Call: XML-RPC) empleado entre OpenXCAP y OpenSIPS-mi-proxy
es el predecesor del Protocolo Sencillo de Aceso a Objetos (Simple Object Access
Protocol: SOAP) [54] usado por XCAP para invocar las operaciones put, get y
delete va consultas HTTP [57]. El motor tras el XDMS es OpenSIPS ya que es
quien implementa toda su lgica; nicamente utilizando los dems componentes
como interfaz para complementar la carencia del funcionamiento brindado por
OpenXCAP. El Servidor de Presencia cuenta con la siguiente funcionalidad:
1. Administrar los PIDFs de los usuarios.
43
3.6. Clientes IMS Captulo 3. Construccin de la Maqueta IMS
2. Utilizar OpenSIPS-mi-proxy y OpenXCAP para comunicarse directamen-

te con los usuarios al momento de actualizar los PIDF.
3. Comunicarse con el domino IMS como un AS.
4. Recibir las notificaciones de los eventos SIP generados por los usuarios.
5. Notificar a los watchers acerca de los cambios en la presencia de los usua-
rios.
La implementacin de XDMS en la maqueta caus muchos problemas ya

que existen varias herramientas FOSS que dicen ser una solucin XDMS, pero
no cuentan con todas las funcionalidades caractersticas de ellas. Algunas ni-
camente ofrecen servicios RLS o bien la administracin de PIDFs, sin embargo
no existe compatibilidad en los protocolos de comunicacin entre la mayora de
estas herramientas. Por eso fue que la mejor solucin fue construir el XDMS a
partir de las herramientas mencionadas previamente, ya que fue la alternativa
que requera de menos componentes y ofreca el mayor nmero de funcionalida-
des. La nica limitante que presenta la combinacin de OpenSIPS y OpenXCAP
para cumplir con la tarea de formar un XDMS es la opcin de definir PIDFs
personalizados.
3.6. Clientes IMS

Finalmente, es necesario contar con clientes que puedan aprovechar los ser-
vicios ofrecidos por la maqueta. El mejor candidato para los clientes IMS fue
elaborado por la Universidad de Cape Town (UCT) por dos principales razones:
(1) fue diseado especficamente para trabajar con el ncleo IMS desarrollado
por FOKUS y (2) su interfaz grfica cuenta con varias opciones de configura-
cin y acceso a distintos servicios. UCT IMS Client [56] posee las siguientes
cualidades atractivas para probar todas las funcionalidades de la maqueta:
Llamadas: Integracin de llamadas IMS marcando el SIP-URI del destinatario.

Mensajera Instantnea: Habilidad de realizar mensajes de sesin, as como
modo pager.
DTMF: Interfaz para generar sealizacin DTMF en mensajes SIP, til al
momento de probar compatibilidad con PSTN.
44
3.7. Topologa Fsica Captulo 3. Construccin de la Maqueta IMS
Servicios de Presencia: Habilidad de administrar documentos va HTTP, ge-

nerar y recibir eventos SIP enviados al RLS, y permite consultar informa-
cin bajo la faceta de watcher.
IPTV: Interfaz que permite el acceso a servicios multimedia como IPTV y

VoD.
3.7. Topologa Fsica

Debido a que todos los componentes de la maqueta estn compuestos por
herramientas FOSS, se opt por utilizar sistemas operativos de la misma ndole,
por lo tanto toda la maqueta esta montada sobre sistemas Linux y FreeBSD,
con la excepcin de DSS el cual se encuentra en la mquina Vesta corriendo Mac
OS X. La Figura 3.5 indica las mquinas utilizadas y el rol que desempean en
la maqueta.
Figura 3.5: Topologa Fsica de la Maqueta IMS
Se aprovech la topologa de red existente en el Laboratorio de Redes Avan-

zadas para colocar los componentes de la maqueta en ciertos segmentos de red
con el fin de simular varios escenarios que sirven para probar la robustez de la
maqueta y los servicios ante distintas condiciones de red. El primer escenario
simulado sirve para garantizar una mejor QoE en la entrega de los servicios a
Caronte. Este escenario se vio motivado por la incapacidad de recibir contenido
45
multimedia de manera satisfactoria en Caronte ocasionado por el cuello de bo-

tella de 2Mb/s que genera la conexin serial entre Cot1 y Cot2. Para solucionar
dicho problema se crearon dos rutas: (1) entre Hebe (Asterisk) y Caronte y (2)
entre Vesta (DSS) y Caronte. Para detalles acerca de la configuracin de las
rutas consultar [34]. La creacin de estas rutas obliga el contenido proveniente
desde Vesta y Hebe a viajar por el segmento de red 210. Estos cambios se ven
reflejados en una mejor QoE presenciada en Caronte.
Como consecuencia, las rutas estticas establecidas permiten simular tres
escenarios adicionales en la entrega de multimedia originado por el Servidor
de Contenidos. La Figura 3.6 ilustra dichos escenarios. En el escenario 1 los
flujos de sealizacin y multimedia se encuentran en el mismo segmento de red.
Este escenario sirve nicamente como prueba de concepto para demostrar que
la entrega sirve bajo las condiciones ms sencillas. En el escenario 2 los flujos
de sealizacin y multimedia atraviesan un router. Este escenario sirve para
demostrar que la entrega de contenido multimedia no se afectado por el retraso
inherente que presenta un router de capa tres. El escenario 3 permite ilustrar la
independizacin de los flujos de multimedia a los flujos de sealizacin dentro del
ambiente IMS. Los flujos sensibles al retraso, como son el audio y video, viajan
por el segmento de red 210 mientras que los flujos que no son sensibles, como es
la sealizacin, viajan por el segmento de red 211. Esta serie de tres escenarios
demuestra que IMS es robusto a la separacin de los flujos de sealizacin y
multimedia sin presentar complicacin alguna en la entrega de servicios.
Al colocar los clientes de la maqueta en distintos segmentos de red tambin
se crean escenarios que sirven para probar la interaccin y robustez de comuni-
cacin intra- e inter-dominio dentro de IMS. Se logran reproducir exitosamente
los siguientes escenarios intra-dominio:
Video llamadas donde el dominio IMS y los UEs se encuentran en el mismo

segmento de red.
Video llamadas donde los UEs se encuentran en el mismo segmento de
red, pero el dominio IMS se encuentra en un segmento distinto.
Video llamadas donde el dominio IMS y un UE se encuentran en el mismo
segmento de red mientras que el otro UE se encuentra en un segmento
distinto.
Video llamadas donde tanto el dominio IMS como los UEs se encuentran
cada uno en segmentos de red distintos.
46
(a) Escenario 1 (b) Escenario 2
(c) Escenario 3
Figura 3.6: Entrega de Contenido
Los escenarios inter-dominio generan ms trfico por el simple hecho de inter-

cambiar un mayor nmero de mensajes al momento de establecer una sesin SIP
entre dos dominios IMS. Estos escenarios son una extensin de los anteriores que
sirven para demostrar la escalabilidad de dominios IMS dentro de la maqueta.
Se logran reproducir exitosamente los siguientes escenarios inter-dominio:
Video llamadas donde los dominios IMS y los UEs se encuentran en el

mismo segmento de red.
Video llamadas donde los dominios IMS y un UE se encuentran en el mis-

mo segmento de red mientras que el otro UE se encuentra en un segmento
distinto.
Video llamadas donde los UEs se encuentran en el mismo segmento de
red, pero los dominios IMS se encuentra en un segmento distinto.
47
3.8. Evaluacin de la Maqueta Captulo 3. Construccin de la Maqueta IMS
3.8. Evaluacin de la Maqueta

Uniendo los bloques especificados anteriormente la maqueta logra construir
una Plataforma de Entrega de Servicios dentro del Laboratorio de Redes Avan-
zadas capaz de ofrecer servicios de telecomunicaciones bsicos. IMS propone
ofrecer como mnimo los servicios existentes del mundo de telefona tradicional,
celular y digital. La evaluacin de la maqueta IMS separa de manera lgica los
servicios y las funcionalidades existentes en tres rubros. Esta separacin permi-
te visualizar de manera inmediata cmo se compara la maqueta IMS contra los
operadores de telefona tradicional y celular mvil y contra los servicios de ter-
ceros disponibles desde la infrastructura de los ISPs. Las funcionalidades de la
maqueta IMS adems se comparan contra el Release 7 de IMS el cual en teora
soporta todas las funcionalidades descritas a continuacin. Los rubros en que se
divide esta evaluacin son los siguientes:
1. Funcionalidades ofrecidas bajo el esquema PSTN/ISDN.

2. Funcionalidades ofrecidas bajo el esquema de telefona celular mvil.
3. Funcionalidades ofrecidas bajo el esquema Internet.
3.8.1. Telefona Tradicional

El Cuadro 3.1 resume de manera concreta las funcionalidades que ofrece la
maqueta IMS del rubro de telefona tradicional. Para evaluar las funcionalidades
de las llamadas se realizaron varias sesiones multimedia probando cada uno de
los escenarios descritos en la Seccin 3.7. La funcionalidad del gateway telefnico
as como sealizacin DTMF se prob accediendo a los servicios y funcionali-
dades proporcionados por Asterisk. Como bien se puede apreciar, se cumplen
casi todos los requisitos de este rubro excepto las llamadas 1:N. Esto se debe
a una limitacin del cliente UCT IMS Client que no permite establecer mlti-
ples sesiones simultneas. En cuanto a la operacin de la maqueta, es posible
implementar esta funcionalidad de dos posibles maneras.
La primer alternativa es estableciendo un destinatario (SIP-URI) especial
que se encarga de establecer las sesiones SIP necesarias, lo cual es una solucin
demasiada compleja y requerir de un AS para dedicarse al procesamiento de
los destinatarios individuales. En dado caso este procesamiento se puede delegar
a Asterisk, para evitar la instalacin de nuevos AS. La segunda alternativa es
48
3.8.2. Telefona Celular Mvil Captulo 3. Construccin de la Maqueta IMS
PSTN IMS (Release 7) Maqueta IMS

Video Llamadas 1:1 Intra-Dominio SI SI
Video Llamadas 1:1 Inter-Dominio SI SI
Video Llamadas 1:N Intra-Dominio SI NO
Video Llamadas 1:N Inter-Dominio SI NO
Gateway PSTN SI SI
DTMF SI SI
Sealizacin y Multimedia Independientes SI SI
Cuadro 3.1: Funcionalidades Ofrecidas Bajo Esquema PSTN/ISDN
mucho ms sencilla y nicamente requiere modificar los encabezados que genera

el cliente al momento de realizar llamadas. Actualmente los clientes inician
una sesin SIP enviando un mensaje INVITE con el SIP-URI del destinatario.
Para habilitar llamadas 1:N es posible modificar el SIP-URI del mensaje de tal
modo que ste contenga ms de un destinatario. Esta solucin es ms viable en
particular porque SIP ya soporta esta funcionalidad nativamente.
Es importante mencionar que la validez del gateway PSTN dentro de la
maqueta IMS posee consideraciones especiales. Se mencion que un gateway
telefnico debe cumplir con la capacidad de entablar comunicaciones con tres
tecnologas distintas: SIP, DTMF y SS7. Asterisk posee manejadores (drivers)
para cada uno de estas tecnologas. Sin embargo, dado que el gateway PSTN
usado en la maqueta IMS se conecta con la red telefnica del ITAM, ste no
requiere del uso de SS7. Por lo tanto, el driver que permite a Asterisk hablar
SS7 no se incluy en la instalacin de Asterisk. Sin embargo, si se desea agregar
esta funcionalidad ms adelante al gateway PSTN basta con la instalacin del
driver apropiado.
3.8.2. Telefona Celular Mvil

Las funcionalidades con las que cuenta la maqueta en el mundo de telefona
celular no son tan extensas como las de PSTN/ISDN. Primero, el Cuadro 3.2
muestra que no se pueden ofrecer servicios de roaming. Esto se debe a una mala
configuracin de los dominios IMS. El escenario que ste debera de reproducir
es un flujo donde el registro del UE se comunica con el P-CSCF forneo y
posteriormente es atendido por el S-CSCF forneo. Curiosamente no funciona
as, despus de ser atendido por el P-CSCF forneo el registro es redirigida al S-
49
3.8.3. Internet Captulo 3. Construccin de la Maqueta IMS
CSCF local. La Figura 3.7 ejemplifica la diferencia entre los procesos descritos.
Es necesario realizar pruebas ms rigurosas para conocer porqu el P-CSCF
forneo no redirige el registro del UE correctamente, y corregir adecuadamente
esta falla.
(a) Flujo de Registro Esperado (b) Flujo de Registro Ocurrido
Figura 3.7: Curiosidades del Servicio de Roaming
El Cuadro 3.2 vuelve a mostrar que el cliente UCT IMS Client es incapaz
de generar mensajes SIP a varios destinatarios. La solucin a este problema se
obtiene de la misma manera descrita para realizar llamadas 1:N visto en la Sec-
cin 3.8.1. La funcionalidad de Push To Talk over Cellular se puede implementar
con un AS encargado de generar y procesar el contenido que ste requiere.
Telefona Celular Mvil IMS (Release 7) Maqueta IMS

Roaming SI NO
Push To Talk over Cellular SI NO
Mensajera Instantnea (1:1) Modo Pager SI SI
Mensajera Instantnea (1:N) Modo Pager SI NO
Cuadro 3.2: Funcionalidades Ofrecidas Bajo Esquema de Telefona Celular Mvil
3.8.3. Internet
Al igual que en los Cuadros 3.1 y 3.2, el Cuadro 3.3 vuelve a expresar las
deficiencias que posee el cliente UCT IMS Client al tratar de establecer sesiones
1:N. Gracias a que la mayora de la maqueta est montada sobre una ambiente
IP, se pudo lograr cumplir casi todos los objetivos de este rubro. Lo nico que
no se logr fue montar la maqueta sobre IPv6. Garantizar compatibilidad con
IPv6 requiere un anlisis riguroso de todos los componentes de la maqueta,
50
asegurando que su programacin cuenta con herramientas que puedan funcionar

correctamente sobre esta tecnologa. A pesar de que la maqueta cuenta con la
funcionalidad de XCAP y XDMS es importante sealar que existe una limitante
por parte de los clientes. El cliente UCT IMS Client por s solo es incapaz
de alimentar al XDMS con los PIDFs que definen el comportamiento de las
notificaciones RLS. Esto se debe a que OpenXCAP recibe peticiones HTTPS
mientras que el cliente genera peticiones HTTP, por lo tanto no cuenta con
las mtricas de seguridad necesarias para establecer una comunicacin exitosa
con el servidor. En cambio el cliente XCAPClient que viene includo con la
instalacin de la herramienta OpenXCAP s puede realizar la comunicacin con
el servidor y es de esta manera que se logra alimentar el XDMS con los PIDFs
de los usuarios.
Internet IMS (Release 7) Maqueta IMS

Mensajera Instantnea (1:1) Modo Sesin SI SI
Mensajera Instantnea (1:N) Modo Sesin SI NO
Mensajera Instantnea (1:1) Modo Pager SI SI
Mensajera Instantnea (1:N) Modo Pager SI NO
IPTV SI SI
VoD SI SI
IPv4 SI SI
IPv6 SI NO
RLS SI SI
XCAP/XDMS SI SI
QoS SI SI
Cuadro 3.3: Funcionalidades Ofrecidas Bajo Esquema Internet
Es importante mencionar que se puede robustecer la entrega de mensajes

instantneos en modo pager con la instalacin de un servidor Message Session
Relay Protocol (MSRP). Actualmente, el cliente UCT cuenta con mecanismos
bsicos de MSRP para intercambiar mensajes de sesin, sin embargo stos no
tienen la capacidad de ser entregados al usuario mientras no pertenezca a una
sesin. El uso de un AS dentro de la maqueta IMS permitir agregar esta fun-
cionalidad y robustecer la entrega de mensajes de sesin.
La maqueta IMS adems provee ciertas funcionalidades que no pueden ca-
talogarse dentro de los rubros anteriores. Con la ayuda de Asterisk la maqueta
51
tiene la capacidad de ofrecer todo tipo de servicios de telefona moderna, como

son llamadas en espera, correo de voz, conferencias y servicios de Respuesta de
Voz Interactivo (Interactive Voice Response: IVR), entre otros. Una funcionali-
dad atractiva, pero imposible de lograr con la versin actual (1.4.22) de Asterisk,
es habilitar servicios de mensajera instantnea hacia PSTN.
52
Captulo 4
Diseo de LBS
Personalizados
Para cubrir el objetivo de este trabajo de tesis se formularon dos servicios

personalizados: el primero ejemplifica las capacidades de un LBS sobre IMS,
mientras que el segundo se basa en un LBS y le aade variables que permiten
personalizar el servicio. Este Captulo se concentrar en explicar el diseo de
ambos servicios, as como sus requerimientos.
4.1. Introduccin
Partiendo de la idea de que IMS ser desplegado con gran aceptacin en el
mercado se puede suponer que ste sustituir la infraestructura de los operadores.
Adems, la alta penetracin que tienen los dispositivos mviles de telecomuni-
caciones los convierten en candidatos ideales para ofrecer servicios novedosos al
usuario final. Bajo este contexto, los usuarios descritos en este Captulo pertene-
cen a un dominio IMS y poseen la capacidad de moverse libremente. Los servicios
que consumen, as como la entrega de contenido, dependen de su localizacin y
las capacidades multimedia que poseen sus dispositivos fsicos (UE). Dicha de-
pendencia exige un modelo de entrega similar al ofrecido por los servicios LBS,
ya que conociendo los servicios que normalmente consume el usuario en ciertas
reas geogrficas se podrn ofrecer servicios en funcin de su comportamiento,
53
4.2. Gua Virtual Captulo 4. Diseo de LBS Personalizados
logrando una personalizacin y transparencia en su entrega.

Este escenario plantea los cimientos sobre los cuales se logra el objetivo
de ste trabajo de tesis: ofrecer servicios LBS sobre una plataforma IMS con el
propsito de mejorar la QoE del usuario, mediante la personalizacin de servicios
en la transparencia que ofrece una red convergente. Los servicios propuestos
por este trabajo de tesis se enfocan en el usuario final; no toman en cuenta
las necesidades o aplicaciones que puede tener una red convergente para los
usuarios empresariales. Esta decisin radica en la necesidad de renovar el modelo
de negocios. IMS, al ser una solucin tecnolgica innovadora, requiere de una
nueva mentalidad donde los procesos de negocio tambin se renuevan y se ofrecen
nuevos servicios al usuario. Por lo tanto la creacin de los servicios desarrollados
se abord desde el punto de vista de cmo mejorar la experiencia rutinaria de
los usuarios.
Se decidi implementar servicios que utilizan los bloques bsicos de teleco-
municaciones que proporciona la maqueta IMS para probar la factibilidad de
desarrollar servicios usando la metodologa propuesta por IMS. Esto es, la crea-
cin de los servicios se apoya sobre los bloques modulares proporcionados por
la maqueta al momento de disear su implementacin. La maqueta cuenta con
tres AS descritos en el Captulo anterior: un gateway telefnico, un Servidor de
Contenidos y un Servidor de Presencia. Los servicios desarrollados utilizan los
ltimos dos AS para cumplir con los requerimientos. Se utiliza el Servidor de
Contenidos como un proveedor de contenido multimedia y se utiliza el Servidor
de Presencia como una herramienta que permite personalizar el contenido. A su
vez, se decidi que los servicios adoptaran la lgica del LBS ya que stos permi-
ten aadir un mayor nivel de personalizacin en los servicios dependiendo de la
localizacin del usuario. En resumen, los servicios desarrollados ofrecen conteni-
do multimedia personalizado como un LBS. Estos tienen implementan un Gua
de Turista Virtual (referido como Gua Virtual el resto de este documento) y el
servicio de una Cartelera Personalizada.
4.2. Gua Virtual

En el mbito turstico existe una enorme gama de atracciones que abarca
museos, teatros, parques, zoolgicos, excursiones, bares, etctera. Cada uno de
estos destinos tursticos posee distintas reglas y normas sociales a seguir. Por lo
tanto, existen limitaciones en cuanto al tipo de contenido que se puede consumir
54
4.2.1. Diseo de Alto Nivel Captulo 4. Diseo de LBS Personalizados
en dichos destinos; por ejemplo, es mejor visto entablar una conversacin tele-
fnica en un lugar abierto a un lugar cerrado que exige silencio, como puede ser
un saln de pera. Estos simples escenarios sirven para ejemplificar la necesidad
de distintos tipos de contenido multimedia bajo condiciones que dependen de la
localizacin del usuario.
Los turistas, adems, son gente curiosa que generalmente no conocen su
destino y se encuentran en una bsqueda constante de informacin relacionada
con atracciones tursticas. Esta informacin se obtiene de diversas maneras:
desde preguntas a un desconocido en la calle, hasta solicitando la ayuda de un
gua de turistas. Desafortunadamente este mtodo no es el ptimo ya que el
ltimo posee un horario e itinerario predefinido al que el turista debe adaptarse.
El primer servicio desarrollado en este trabajo de tesis muestra el potencial que
tiene LBS en el mercado turstico. Se propone ofrecer un servicio de multimedia
personalizado que enriquezca las actividades que desee realizar el usuario en el
orden que ms le convenga. Adems se pretende dar a conocer nuevas atracciones
mediante el descubrimiento donde se le notifica al usuario las actividades y
eventos que suceden a su alrededor. El servicio de Gua de Turista Virtual
enriquece la QoE del usuario al recibir contenido bajo el contexto en el que se
encuentra segn su localizacin.
4.2.1. Diseo de Alto Nivel

El funcionamiento de este servicio supone que el usuario cuenta con un UE
capaz de notificar peridicamente su localizacin al dominio IMS. El servicio se
encuentra dentro de un AS capaz de recibir y enviar mensajes SIP. ste contiene
un registro de todos las atracciones tursticas que tienen contenido multimedia
asignado a ellas, as como sus coordenadas geogrficas. Cada vez que el AS
reciba una notificacin por parte del usuario compara las coordenadas de su
localizacin con las coordenadas dentro de su registro. Si encuentra una atraccin
turstica dentro de un radio de 50 metros de su localizacin activa el servicio
LBS, de lo contrario no hace nada. Dependiendo del tipo de contenido que tiene
asignado la atraccin turstica, el AS puede establecer una sesin multimedia
con el usuario o simplemente enviar un mensaje SIP (o su equivalente mensaje
SMS) con una breve descripcin del destino. Para el caso donde se establece una
sesin multimedia con el usuario; primero se solicita su permiso y posteriormente
se transfiere la sesin al AS donde se encuentra el Servidor de Contenidos para
entregarle el contenido multimedia deseado.
55
4.2.2. Flujo de Mensajes SIP Captulo 4. Diseo de LBS Personalizados
Gracias a que el servicio funciona nicamente con notificaciones, la iniciali-

zacin del servicio se puede definir con la primer actualizacin enviada por el
cliente. En este caso la inicializacin no requiere de ningn tratado especial ya
que las notificaciones son procesadas sin tomar en cuenta la suscripcin al ser-
vicio. Sin embargo, en el mbito empresarial sto no es suficiente ya que no hay
manera de controlar ni restringir el acceso al servicio por parte de terceros. La
inicializacin del servicio se puede realizar cuando el cliente enva un mensaje
SIP con el mtodo SUBSCRIBE al AS. Este mensaje ser procesado para evaluar
si el cliente tiene los permisos necesarios para ofrecerle el servicio.
La terminacin del servicio es iniciada por el cliente, ya que es quien controla
la sesin con el Servidor de Contenidos. Como bien se puede apreciar, el AS que
implementa el servicio del Gua Virtual nicamente se encarga de determinar
si el usuario est dispuesto a tener una sesin multimedia relacionada con su
localizacin en un momento dado. En caso de que ya no se desea el servicio del
Gua Virtual basta con dejar de notificar el AS con los cambios de localizacin.
4.2.2. Flujo de Mensajes SIP

Ahora se entrar en ms detalle acerca de los mensajes SIP intercambiados
entre cada uno de los componentes de la maqueta IMS. La Figura 4.1 ilustra la
secuencia de mensajes intercambiados por los componentes del servicio. Primero
se observa que los pasos 1 a 4 son generados por el UE y atraviesan por la
lgica del dominio IMS hasta determinar su destino: el AS donde radica el Gua
Virtual. Dichos mensajes son del tipo PUBLISH con el fin de notificar al AS los
cambios en su localizacin. El AS contesta al mensaje con otro con estatus 200
(OK) representados por los mensajes 5 a 8 de la Figura 4.1. Esta serie de pasos
concluye la actualizacin de las coordenadas geogrficas del usuario.
Despus de generar el mensaje OK, el AS determina si existe una atraccin
turstica cercana para continuar con el proceso. Los mensajes 9 a 14 sirven para
establecer una sesin multimedia con el UE del cliente. Despus de establecer
la sesin, el AS le enva un mensaje SIP con el mtodo REFER al cliente. Este
mensaje le indica al cliente que la sesin va ser transferida a otro usuario, en
este caso el otro usuario es el Servidor de Contenidos. El cliente, al recibir este
mensaje, reserva los recursos apropiados y se prepara para concluir la transfe-
rencia. En cuanto haya terminado sus procesos internos le notifica al AS que
esta listo para aceptar la transferencia con el mensaje 15. El AS confirma dicha
notificacin con el mensaje 16. Esta serie de pasos inician la sesin con el cliente
56
Figura 4.1: Mensajes SIP Generados por el Gua Virtual
y lo prepara para transferir su sesin al Servidor de Contenidos.

Posteriormente, los pasos 17 al 21 establecen una sesin con el mdulo del
Servidor de Contenidos encargado de recibir peticiones SIP (UCT IPTV Strea-
ming Server). El Gua Virtual construye un mensaje SIP con los datos del usuario
para que el Servidor de Contenidos le entregue multimedia al usuario y no al
AS. El mensaje 21 realiza una doble funcin: termina de iniciar la sesin SIP
con el Servidor de Contenidos y notifica al cliente que la transferencia de sesin
est completa. El mensaje OK que enva el Servidor de Contenidos contiene la
57
4.3. Cartelera Personalizada Captulo 4. Diseo de LBS Personalizados
informacin necesaria para que el cliente termine la transferencia de sesin.

Finalmente los pasos 22 a 23 sirven para establecer una sesin RTP con el
mdulo del Servidor de Contenidos encargado de entregar contenido multimedia
(DSS). En este momento se ha iniciado una sesin SIP y RTP entre el usuario
y el Servidor de Contenidos. Es importante mencionar que el Gua Virtual fue
quien inici la sesin de manera transparente; esto es, se ha desligado de la sesin
con el cliente y ya no es responsable de la sesin establecida entre el cliente y el
Servidor de Contenidos.
4.3. Cartelera Personalizada

El segundo servicio desarrollado muestra cmo la inclusin de variables de
presencia permite personalizar servicios LBS. Partiendo de las mismas premisas
que se tomaron en el diseo del servicio anterior, se aade un elemento adicional.
En el escenario anterior se supuso que las atracciones tursticas eran las que
ofrecan servicios de multimedia; sin embargo, esto tambin puede ser el caso
para cualquier centro recreativo. Adicionalmente, los centros recreativos cuentan
con una mayor diversidad de actividades y contenidos con la finalidad de atender
los gustos de la mayor parte de la poblacin. Por lo cual, entregarle al usuario
todo el contenido que pueden ofrecer estos centros recreativos genera un enorme
desperdicio de recursos dentro de la red, adems de ser una prdida de tiempo
para el usuario, ya que tiene que filtrar el contenido que a l le interesa. La
solucin que se busca es ofrecerle contenido e informacin til al usuario al
momento de acercarse a alguno de estos lugares.
Con el fin del presentar soluciones concretas en este trabajo de tesis, se hace
enfoque en los contenidos que ofrecen los cines. Como bien se sabe, los cines
poseen una cartelera donde el usuario elige consumir el contenido que ms le
agrade. Las decisiones que toman los usuarios acerca del gnero de pelcula que
desean ver se ven afectadas, entre otras cosas, por dos principales factores: (1)
su preferencia entre los gneros disponibles en el cine, y (2) su estado de nimo,
que bien puede afectar sus preferencias. Por ejemplo, a una persona pueden
gustarle las pelculas de accin cuando estresado y las de comedia cuando est
contento. Bajo este escenario se puede ver que la red necesita conocer un poco
a sus usuarios para tener la capacidad de ofrecerle un mejor servicio va la
personalizacin de contenidos. El escenario descrito previamente vuelve a caer
bajo las soluciones de un LBS. Sin embargo, no logra cumplirlo por s solo,
58
4.3.1. Diseo de Alto Nivel Captulo 4. Diseo de LBS Personalizados
ya que carece de informacin al momento tomar decisiones para personalizar el

contenido multimedia. La red puede conocer los estados de nimo de los usuarios
con la ayuda del Servidor de Presencia. Adems, si la red tuviera una manera de
conocer los gneros de las pelculas que prefiere el usuario, sta puede realizar
un filtrado y ahorrarle al usuario tiempo y esfuerzo.
4.3.1. Diseo de Alto Nivel

El funcionamiento y diseo de este servicio se asemeja mucho al servicio del
Gua de Turista Virtual, con la diferencia de que ste debe conocer las prefe-
rencias del usuario. La primera parte del diseo es exactamente la misma. El
usuario le notifica al AS su localizacin peridicamente hasta que ste detecta
un cine dentro de un radio de 50 metros de la localizacin del usuario. Aho-
ra el AS requiere obtener las preferencias del usuario. Dentro de IMS existen
dos principales repositorios de informacin donde se pueden almacenar dichas
preferencias. En el diseo se opt por usar el ms flexible de stos: el Servidor
de Presencia (XDMS). Las razones son sencillas: (1) el HSS que proporciona
OpenIMS Core es usado estrictamente por los dominios IMS y administra po-
lticas de acceso tanto de los usuarios como los servicios, e incluir informacin
adicional bajo este contexto no es adecuado ni modular como se busca en los
servicios que ofrece IMS; (2) el XDMS usado en la maqueta permite la opcin
de administrar cualquier tipo de informacin adems de que su almacenamiento
en PIDFs aadir un orden implcito al trabajar con archivos XML fciles de
comprender.
La definicin de PIDFs personalizados permite a los usuarios actualizar su
preferencia en gneros dentro del XDMS va actualizaciones XCAP con docu-
mentos XML. No es necesario entregarle esta informacin al XDMS al momento
de contratar el servicio ya que puede ser realizado posteriormente. Sin embargo,
sin esta informacin no es posible filtrar la cartelera y se le entrega la cartelara
completa al usuario. Por otro lado, el AS puede conocer dichas preferencias al
realizar una consulta XCAP al XDMS con el fin de filtrar los contenidos que se
ofrecern.
El servicio de Cartelera Personalizada cuenta con todas las variables necesa-
rias para ofrecerle contenido especializado al usuario con la ayuda de LBS. En
este momento consulta la cartelera del cine ms cercano al usuario y filtra los
resultados, quedndose nicamente con las funciones de los gneros que le gus-
tan al usuario. Despus de haber construido la cartelera se la manda al usuario
59
mediante un mensaje SIP del tipo MESSAGE. Con el propsito de aadir funcio-
nalidad y una mejor QoE hacia el usuario se le ofrece tambin la opcin de ver el
trailer (avance cinematogrfico) de la pelcula que tiene la mayor probabilidad
de gustarle basado en su preferencia de gneros. El resto de la lgica del AS se
vuelve a parecer al servicio del Gua Virtual en el sentido de que establece una
sesin de manera transparente con el usuario y el Servidor de Contenidos.
4.3.2. Flujo de Mensajes SIP
Figura 4.2: Mensajes Generados por la Cartelera Personalizada
60
4.3.3. Archivos XML y XSD Captulo 4. Diseo de LBS Personalizados
La Figura 4.2 ilustra la secuencia de mensajes intercambiados por los com-

ponentes del servicio el momento de implementar la Cartelera Personalizada.
El flujo y propsito de los mensajes son los mismos que se presentaron el la
Seccin 4.2.2, con la excepcin de los mensajes 9 a 14. Primero se reciben las
notificaciones de localizacin con los pasos 1 a 4, seguido por su contestacin
exitosa en los pasos 5 a 8. Se evala si la distancia entre el usuario y un cine
es menor a 50 metros para continuar con el flujo. En el caso exitoso, se obtiene
la cartelera desde el cine ms cercano. Posteriormente se consultan las prefe-
rencias del usuario en los pasos 9 y 10, obteniendo los documentos de presencia
del XDMS, A continuacin se filtra la cartelera original y se enva la nueva
cartelera al usuario en los pasos 11 a 14. Despus se inicia una sesin con el
cliente seguido por una negociacin de una transferencia en los pasos 15 a 22.
Posteriormente se inicia una sesin con el Servidor de Contenidos solicitando el
avance cinematogrfico candidato a ser visto por el usuario en los pasos 23 a 26.
Es importante notar que el AS trata de iniciar la sesin con las credenciales del
usuario. Finalmente se notifica al cliente la transferencia exitosa y se inicia la
sesin de multimedia entre el cliente y el Servidor de Contenidos en los pasos
27 a 29.
4.3.3. Tratatamiento y Especificacin de Archivos XML

y XSD Personalizados
El formato y contenido de los PIDFs almacenados en el XDMS deben estar
estandarizados con el fin de facilitar su uso y garantizar una integridad en la
informacin que contienen. Idealmente, el XDMS cuenta con una XSD usado
por el PIDF que define la informacin que puede contener y las restricciones
presentes en sus tipos de datos. Se aprovecha esta facilidad para almacenar los
gneros que ms le gusten a los usuarios dentro del XDMS como archivos XML.
La Figura 4.3 muestra una visualizacin del XSD que define los PIDFs con las
Figura 4.3: PIDF de los Gneros Preferidos
61
4.4. Clculo de Distancia en Metros Captulo 4. Diseo de LBS Personalizados
preferencias de los usuarios.
4.4. Clculo de Distancia en Metros

Los registros del AS contienen una lista de las atracciones tursticas y cines,
su localizacin en coordenadas geogrficas y el tipo de contenido multimedia que
entregan (texto, audio o video). Las coordenadas geogrficas de las atracciones
tursticas son usadas para calcular la distancia en metros entre el usuario y
los destinos con contenido multimedia asignado. El clculo que debe realizar el
AS para obtener la distancia se muestra en las Ecuaciones (4.1),(4.2) y (4.3).
La primera de ellas transforma las unidades de las coordenadas geogrficas de
grados a radianes. La segunda ecuacin utiliza la primer ecuacin para calcular
la longitud del segmento de arco entre las coordenadas geogrficas. La tercer
Ecuacin regresa las unidades a grados y se multiplica por la distancia en metros
que equivale a un grado longitudinal del globo terrqueo. Si el resultado de la
operacin final (Ecuacin 4.3) es menor a 50 se activa el servicio LBS.
x
rad(x) = (4.1)
180
distP re = sin rad(latU E) sin rad(latDest)

+ cos rad(latU E) cos rad(latDest) (4.2)
cos rad(longU E + longDest)
arc cos distP re 180

distancia = 111189.577 (4.3)

4.5. Actualizaciones de Localizacin

La Figura 4.4 muestra una visualizacin del archivo XSD definiendo el for-
mato que deben seguir las actualizaciones, mientras que el Cuadro 4.1 muestra
un ejemplo de los valores que puede contener el cuerpo del mensaje PUBLISH.
Es importante mencionar que la lnea 3 del ejemplo no se manda por el usuario,
sino que existe nicamente dentro del contexto del AS con el fin de asignarle
una referencia lgica a un par de coordenadas determinadas.
62
4.6. Modelo de Negocio Captulo 4. Diseo de LBS Personalizados
Figura 4.4: Definicin XSD del Formato de las Actualizaciones de Localizacin

2 <location xmlns:xsi=" http :// www.w3.org /2001/ XMLSchema -instance" xsi:
noNamespaceSchemaLocation =" location.xsd">
3 <placeName >ITAM </ placeName >
4 <latitude >19.344585 </ latitude >
5 <longitude > -99.199812 </ longitude >
6 </location >
Cuadro 4.1: Actualizaciones de las Coordenadas Geogrficas
4.6. Modelo de Negocio

Ambos servicios LBS personalizados diseados en este Captulo se encargan
de establecer una sesin entre el usuario y el Servidor de Contenidos de manera
transparente. Dicha transparencia obliga la participacin de mdulos adicionales
al momento de definir un modelo de negocio redituable. La funcin CSCF de los
dominios IMS determina los recursos que utiliza cada usuario dentro de la red.
El costo de dichos recursos se reparte entre el Servidor de Contenidos y el AS
desarrollado.
El Servidor de Contenidos se encarga de generar la factura que debe pagar
el AS por el acceso al contenido multimedia ofrecido al cliente. El AS se encarga
de generar una relacin entre los destinos y cines visitados por los usuarios.
Dicho listado sirve para ayudar a calcular el costo incidente de los usuarios.
Los mensajes de texto, como son las descripciones de los destinos tursticos
y la cartelera personalizada, se aaden a esta lista para calcular el costo que
genera cada usuario en la entrega de los servicios. Estos dos factores (la sesin
multimedia y la entrega del mensaje de texto) determinan la mayor parte del
gasto total para el AS. Los mensajes PUBLISH tambin generan un gasto en
63
4.6. Modelo de Negocio Captulo 4. Diseo de LBS Personalizados
comparacin con el costo de las sesiones multimedia.

Por otro lado, el AS recibe ganancias al cobrarle una renta semanal al tu-
rista que depende del costo que ste haya generado. La densidad de atracciones
tursticas por destino sirve para calcular dicha renta y proponer un esquema de
tarificacin correspondiente. Por ejemplo, se pueden definir tres densidades de
atracciones tursticas: baja, mediana y alta. Dependiendo del destino turstico
que visita el usuario, se le cobra la tarifa baja, mediana o alta. En cambio, al
cinfilo se le cobra una renta mensual fija que cubre los costos mencionados
previamente. Desde el punto de vista del usuario, nicamente se genera una
factura por el AS que incluye el cobro por el servicio y a entrega del contenido
multimedia.
Los operadores que tienen desplegados su infraestructura IMS pueden usar
los servicios LBS personalizados como incentivos para los nuevos usuarios. Con
este esquema de tarificacin adems se pueden promover las ventajas que ofrece
IMS sobre a competencia.
64
Captulo 5
Implementacin y
Evaluacin de los LBS
Personalizados
Este Captulo detalla la implementacin de los servicios LBS personalizados

diseados en este trabajo de tesis. Se desarrollaron tomando como base la pla-
neacin y diseo presentada en el Captulo 4. Tambin se expone el escenario de
pruebas bajo el cual trabajan los servicios personalizados. Finalmente se realiza
una evaluacin de los servicios ofrecidos.
5.1. Herramientas Utilizadas

Tanto la implementacin de los servicios LBS, como los clientes quienes
los consumen requieren de herramientas adicionales con las cuales no cuenta la
maqueta IMS. La implementacin del AS que ofrece los servicios LBS requiere
de un ambiente de desarrollo que pueda hacer uso de tecnologa SIP de una
manera medianamente sencilla. Por otro lado, el cliente (UCT IMS Client) con
el que cuenta la maqueta IMS no posee la habilidad de actualizar peridicamente
su localizacin, as como notificar al AS acerca de dichos cambios. Con la ayuda
de ciertos componentes de la maqueta IMS y algunas herramientas adicionales
se pudieron implementar exitosamente los servicios LBS personalizados.
65
5.1. Herramientas Utilizadas Captulo 5. LBS Personalizados
Dominios IMS proveen la infraestructura sobre la cual trabajan los servicios

LBS.
Servidor de Contenidos se encarga de la entrega del contenido multimedia
ofrecido por el AS que implementa los LBS.
Servidor de Presencia (XDMS) contiene las preferencias de los usuarios.
Dicha informacin es utilizada en la personalizacin de los servicios LBS.
En este caso se almacenan los gneros de pelculas que prefiere el usuario.
UCT IMS Client es el cliente con el cual interactan los servicios LBS.
XCAPClient es un cliente desarrollado en Python usado por el AS para con-
sultar los PIDFs de los usuarios.
Sailfin es una extensin de GlassFish [51] que hace uso de las herramientas que
ofrece Java Enterprise Edition para ofrecer soluciones con tecnologa SIP.
GlassFish es un AS empresarial desarrollado con FOSS. En el contexto de
este trabajo de tesis es la herramienta con la cual se desarroll el AS que
ofrece los servicios LBS.
SIPp fue creado con la intensin de medir el desempeo de aplicaciones SIP.
Pero gracias a la alta personalizacin que posee esta herramienta, es usado
de una manera creativa para complementar las insuficiencias del cliente
UCT en la actualizacin de coordenadas geogrficas, interpretadas como
localizacin por el AS. En el contexto de este trabajo de tesis es la herra-
mienta utilizada para actualizar la localizacin de los usuarios.
Se decidi utilizar este conjunto de herramientas gracias a que todas (excepto

Sailfin y SIPp) forman parte de la maqueta; lo cual indica que no requieren de
cambios drsticos para adaptarse al funcionamiento de los servicios LBS dentro
de IMS. A su vez, se opt por desarrollar el AS con Sailfin debido a la esta-
bilidad y escalabilidad que proporciona Java Enterprise Edition en soluciones
empresariales. Finalmente, en vez de construir un cliente desde cero capaz de
interactuar con los servicios LBS, se opt por encontrar la manera de actualizar
la localizacin de los usuarios sin realizar cambios al cliente. Esta actualizacin
es llevada a cabo por SIPp. La razn que se eligi esta herramienta se debe a que
posee la capacidad de definir escenarios altamente personalizados en la genera-
cin de mensajes SIP, permitiendo complementar al cliente UCT con simples
archivos de configuracin.
66
5.2. Modificaciones al Diseo Captulo 5. LBS Personalizados
Ericsson recientemente liber al pblico una herramienta llamada Ericsson

Service Development Studio (SDS) 4.1 [20], la cual puede ser usada para desa-
rrollar aplicaciones y soluciones IMS. Esta herramienta implementa la pila de
protocolos de IMS, permitiendo al desarrollador enfocarse en la lgica del servi-
cio. A pesar de que la herramienta de Ericsson es bastante completa, sta no se
utiliz en la implementacin de los servicios LBS por tres razones. La primera
radica en que no es propiamente una herramienta FOSS ya que no se propor-
ciona el cdigo fuente de ciertas funciones complejas. Este detalle traiciona el
alcance de este trabajo de tesis. La segunda razn radica en que la herramienta
se basa en las clases proporcionadas por Sailfin. Por lo tanto, la diferencia entre
la SDS y Sailfin consiste en que el primero cuenta con una interfaz amigable que
ayuda en el desarrollo de aplicaciones y aporta algunas funcionalidades adicio-
nales. La tercer y ltima razn se debe a que el enfoque de este trabajo de tesis
no tiene como objetivo la creacin de un cliente IMS. El enfoque radica en la
implementacin de los servicios LBS dentro del ambiente IMS. El desarrollo del
cliente sirve nicamente para probar dichos servicios y como prueba de concep-
to de que los servicios funcionan correctamente. Por lo tanto, la importancia de
un cliente integrado bajo este contexto es despreciable en comparacin con el
desarrollo de los servicios.
5.2. Modificaciones al Diseo

Durante el proceso cclico de implementacin y pruebas del AS se identifi-
caron dos fallas, relacionadas con el cliente UCT. Dichas fallas radican en el
tratamiento de dos mensajes SIP (UPDATE y REFER) que no implementan el es-
tndar satisfactoriamente. Los mensajes INVITE, RINGING (INVITE con estatus
180 o 183) y aquellos que contienen un SDP afirman que el cliente soporta todos
los mtodos SIP con el siguiente encabezado:
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Sin embargo, en la prctica el cliente no soporta el mtodo REFER. Simple-
mente no tiene programada una lgica que permita procesar ste mensaje, a
pesar de que afirma lo contrario dentro del SDP que genera. Adems, el cliente
no soporta todos los posibles escenarios bajo los cuales puede emplearse el mto-
do UPDATE. La falla en la que incurre el cliente para este caso no es tan grave ya
que s soporta parcialmente el mtodo UPDATE. Logra implementar la mayora
de los escenarios bajo los cuales puede emplearse dicho mtodo.
67
5.2.1. Mtodo REFER Captulo 5. LBS Personalizados
5.2.1. Mtodo REFER

Tras una sucesin de varias pruebas se descubri que el cliente responda
a todos los mtodos SIP ya sea de manera exitosa o con un estatus errneo,
excepto cuando el mtodo era REFER. Como bien se mencion en la Seccin 4.2.2,
el mtodo REFER provoca una serie de procesos internos dentro del cliente y se ve
obligado a contestar despus de haber realizado dichos procesos, o bien informar
acerca de un error. En la prctica, el cliente ni contesta el mensaje recibido ni
hace el intento de procesarlo. Esto llev a la hiptesis de que algo andaba mal en
el cliente. Sin embargo, hasta este momento no se haba definido si el problema
era propio del cliente u ocasionado por los encabezados enviados por el AS que
intentaba establecer la comunicacin, por lo cual se estudi su cdigo fuente
con el fin de mejorar los encabezados generados por el AS. Esta carencia de
funcionalidad indica la primer falla detectada en la implementacin del cliente.
Implementar dicho mtodo en el cliente requiere de un profundo conocimiento
acerca de su funcionamiento interno y serias modificaciones al tratamiento de
otros mensajes SIP para habilitar el flujo que transfiere llamadas.
Este descubrimiento dio lugar a la inquietud de porqu las transferencias
funcionan exitosamente con Asterisk si el cliente UCT no cuenta con el mtodo
que habilita dicha transferencia. Despus de todo, el diseo de los servicios se
bas en esta funcionalidad que brinda Asterisk hacia la maqueta IMS de ma-
nera exitosa. La razn es bastante sencilla, mas no obvia: Asterisk maneja la
transferencia de llamadas internamente debido a que implementa un PBX; por
otro lado, los clientes habilitan la transferencia mediante tonos DTMF in-
corporados dentro de los mtodos INFO de SIP. Asterisk se encarga de enrutar
las llamadas por las sesiones SIP (o canales siguiendo la terminologa Asterisk)
preestablecidas. De esta manera los clientes no se enteran de las transferencias
a bajo nivel, evitando por completo la necesidad de soportar el mtodo REFER.
Incorporar esta funcionalidad dentro del AS es inmensamente complicado, y de-
legar la funcionalidad a Asterisk es imprctico debido a la cantidad de mensajes
que se tendran que intercambiar para una operacin que en teora soporta SIP
nativamente.
Debido a que la transferencia de sesiones multimedia es crucial en el diseo
de los servicios LBS, se tuvo que optar por otro diseo. Tomando en cuenta que
ya se tena programada toda la lgica del servicio; se busc una alternativa que
requera el menor cambio al cdigo existente. Como el mtodo UPDATE es sopor-
tado por el cliente y en teora este mtodo puede ser utilizado para actualizar el
68
5.2.1. Mtodo REFER Captulo 5. LBS Personalizados
Figura 5.1: Primera Modificacin al Diseo
SDP durante una llamada [38], se modific el diseo. Ahora en vez de enviar un
mensaje REFER se manda un mensaje UPDATE con el SDP del Servidor de Conte-
nidos. El cambio consiste en iniciar la sesion con el Servidor de Contenidos, para
obtener el SDP y posteriormente reemplazar el SDP existente en la sesin con
el cliente con el del Servidor de Contenidos. El nuevo diseo es presentado por
Figura 5.1. Los cambios se pueden apreciar de manera grfica si se comparan
los mensajes 14 a 21 con aquellos de la Figura 4.1. Los mensajes 9 a 14 inician
una sesin con el cliente. Los mensajes 15 a 19 inician una sesin con el Servidor
de Contenidos para obtener el SDP. El mensaje 21 actualiza el SDP de la sesin
con el cliente.
69
5.2.2. Mtodo UPDATE Captulo 5. LBS Personalizados
5.2.2. Mtodo UPDATE

A pesar de que este ltimo diseo sigue los estndardes y toma en cuenta
que el cliente UCT efectivamente cuenta con un procedimiento para mensajes
UPDATE, no fue suficiente para lograr los objetivos de los servicios ya que esta
secuencia particular de mensajes mata al cliente. Este grave problema oca-
sion otra revisin al diseo y el funcionamiento a bajo nivel del cliente. Tras
un anlisis extenso del procedimiento de todos los mensajes SIP que soporta
el cliente se descubri la segunda falla en la implementacin del cliente: ste
nicamente procesa los mensajes UPDATE durante la inicializacin de una sesin;
no posee un procesamiento independiente para escenarios adicionales, ocasio-
nando su muerte cuando recibe el mensaje UPDATE del AS bajo un contexto
no esperado. Este descubrimiento oblig a redisear totalmente la entrega de
los servicios LBS personalizados, ocasionado principalmente por la falta de al-
ternativas existentes para actualizar el SDP de la sesin con el cliente. Antes
de volver a disear posibles soluciones, se opt por analizar detenidamente las
capacidades del cliente para evitar futuras sorpresas.
La nica manera de establecer una sesin de multimedia exitosa con el clien-
te es mediante una llamada comn y corriente con el mtodo INVITE seguido
por los mensajes requeridos para negociar las capacidades de multimedia. Es-
te escenario requiere forzosamente conocer de antemano el SDP del Servidor
de Contenidos. Sin embargo, dicho SDP depende de la localizacin del cliente,
por lo cual es necesario establecer previamente una sesin con el Servidor de
Contenidos. Organizando el orden de los mensajes intercambiados entre el AS
y los dems componentes resulta en una simplificacin significativa del diseo
de los servicios, ya que el flujo de los mensajes es ms lgico y secuencial que
el diseo original. El flujo de los mensajes intercambiados en el nuevo diseo se
puede apreciar a detalle en la Figura 5.2. Con el fin de simplificar y hacer ms
legible el diagrama se juntan los mdulos del dominio IMS en una sola entidad.
El proceso que implementa el AS es el siguiente:
1. El AS recibe notificaciones PUBLISH del cliente con la localizacin de usua-

rio, al cual contesta con un OK notificando al cliente que ha recibido la
actualizacin. Adems se actualiza la informacin en los registros del AS.
2. El AS procesa la informacin contenida dentro del mensaje para determi-
nar si est cerca de una localidad que ofrece contenido LBS. En el caso
exitoso se almacena el encabezado FROM recibido del cliente para poste-
70
5.2.2. Mtodo UPDATE Captulo 5. LBS Personalizados
Figura 5.2: Diseo Final de los LBS Personalizados
riormente entregarle contenido al mismo. En el caso contrario el AS no

hace nada.
3. El paso anterior permite conocer la localizacin y el contenido que tiene

asignado. Dicha informacin es convertida en un SIP-URI nico usado pa-
71
5.3. Implementacin del AS para Servicios LBSCaptulo 5. LBS Personalizados
ra establecer una sesin SIP con el Servidor de Contenidos. No se estable-

ce una sesin de multimedia entre los Servidores para evitar desperdiciar
recursos. Despus de establecer la sesin, el AS cuenta con el SDP del
Servidor de Contenidos el cual contiene el destino del contenido LBS que
ser ofrecido al usuario.
4. Se establece una sesin con el cliente usando el SDP del Servidor de Con-
tenidos. Esto permite establecer una sesin SIP entre el AS y el cliente;
mientras que por otro lado se establece una sesin RTP entre el cliente y
el Servidor de Contenidos.
A diferencia del diseo original de los servicios LBS, ste diseo requiere
definir la terminacin del servicio. Originalmente sto no era necesario ya que
la intencin era establecer una sesin nicamente entre el cliente y el Servidor
de Contenidos, desligando por completo el AS de la sesin de multimedia. Bajo
el nuevo diseo existen varias sesiones que se necesitan finalizar al momento de
concluir la entrega del contenido LBS. Dicho proceso de terminacin se ejempli-
fica en la Figura 5.3.
Figura 5.3: Terminacin del Contenido LBS
5.3. Implementacin del AS para Servicios LBS

En esta Seccin se describe el desarrollo del AS donde se implementan los
servicios LBS personalizados. Adems se presentan los consideraciones especiales
que se tomaron en cuenta para la implementacin de ciertos componentes del
AS.
72
5.3.1. Interaccin con la Base de Datos Captulo 5. LBS Personalizados
5.3.1. Interaccin con la Base de Datos

Antes que nada, se consider que el AS potencialmente va a manejar la infor-
macin de una cantidad indefinida de localidades (destinos tursticos y/o cines)
los cuales poseen distintos tipos de contenidos. Adems, trabajar con una canti-
dad indefinida de usuarios que actualizan su localizacin peridicamente. Tanto
los datos de los destinos como los usuarios representan informacin dinmica
que requiere almacenarse en una base de datos la cual puede ser accesda desde
el AS. Sailfin proporciona herramientas para facilitar la interaccin con diversos
manejadores de bases de datos. La base de datos creada es bastante sencilla,
ya que nicamente consta de dos tablas. La Figura 5.4 muestra el diagrama de
entidades que representa la base de datos usada.
Figura 5.4: Base de Datos Usado por el AS
Despus de crear la base de datos existe un par de preparativos necesarios

para que Sailfin pueda interactuar con ella. Desde la consola de administracin
de Sailfin se necesita crear un Connection Pool y JDBC Resource con la infor-
macin de la base de datos. Por otro lado se necesita crear con una Unidad
de Persistencia (Persistence Unit) desde el AS. Esto permiti crear seis clases
especializadas que juntas forman un Java Bean el cual es usado para interactuar
con la base de datos. A continuacin se presenta un breve resumen de la funcin
de cada clase desarrollada:
Destinos implementa una clase Entity usada para tener acceso directo a la
tabla Destinos. Permite manipular las tuplas individuales de dicha tabla.
Usuarios implementa una clase Entity usada para tener acceso directo a la
tabla Usuarios. Permite manipular las tuplas individuales de dicha tabla.
DestinosDBAO representa un Objeto de Aceso Directo a la Base de Datos

(Data Base Access Object: DBAO) donde se definen e implementan los
73
5.3.2. Contenedor HTTP Captulo 5. LBS Personalizados
mtodos de acceso particulares a la tabla Destinos accesibles desde el AS.

Requiere el uso de la clase Destinos.
UsuariosDBAO representa un DBAO donde se definen e implementan los
mtodos de acceso particulares a la tabla Usuarios accesibles desde el AS.
Requiere el uso de la clase Usuarios.
GestorDB implementa una clase Entity Manager que representa un Java

Bean. Hace uso de las clases DestinosDBAO y UsuariosDBAO para formar
una interfaz que permite separar la lgica del AS en capas.
ContextListener implementa una clase Servlet Context Listener el cual es

usado nicamente para crear y asignar la clase GestorDB al contexto de
un servlet.
La Figura 5.5 muestra un diagrama representando la comunicacin entre los

disitintos mdulos del AS y su interaccin con la base de datos.
Figura 5.5: Interaccin con la Base de Datos
5.3.2. Contenedor HTTP

Sailfin, al igual que GlassFish, permite la creacin de AS independientes al
situar stos en contenedores; adems, permite que stos sean ms complejos al
manejar contenedores separados para los protocolos SIP y HTTP. Sailfin se en-
carga de detectar la inicializacin del contenedor con la ayuda de un Listener
el cual manda llamar la clase ContextListener, brindndole acceso a la base de
datos desde el contenedor HTTP. El propsito de este contenedor en el AS desa-
rrollado sirve nicamente para visualizar la informacin de los destinos tursticos
y el movimiento de los usuarios. Dicho propsito se logra con dos pginas web.
La primera, despliega una lista de los destinos tursticos dados de alta junto con
74
5.3.3. Contenedor SIP Captulo 5. LBS Personalizados
una breve descripcin de los destinos, sus coordenadas geogrficas y el tipo de

contenido que tienen asignados. La segunda, muestra un mapa donde se puede
apreciar el movimiento de los usuarios y su cercana a los distintos destinos turs-
ticos. La Figura 5.6 muestra un ejemplo de esta visualizacin donde los usuarios
son representados con globos anaranjados (ashurado) y los destinos con globos
azules.
Figura 5.6: Visualizacin de los Destinos Tursticos y Usuarios
5.3.3. Contenedor SIP

El contenedor SIP del AS desarrollado contiene la lgica presentada en las
Figuras 5.2 y 5.3. Es el encargado de procesar todos los mensajes SIP que recibe
para inicializar una sesin entre el Servidor de Contenidos y el usuario. Tambin
hace uso de la Ecuacin 4.3 presentada en el Captulo 4 para obtener la localidad
ms cercana al usuario, y as evaluar tanto el servicio LBS activado como el tipo
de contenido asignado. El contenedor SIP contiene una clase la cual se puede
descomponer en los siguientes tres procesos principales:
Inicializacin: Sailfin detecta la inicializacin del servlet y mediante un Liste-

ner que manda llamar la clase ContextListener brinda acceso a la base de
datos desde el contenedor SIP.
Procesamiento de Mensajes Request: Procesa los mensajes iniciados por
peticiones del usuario. Estas peticiones se limitan a los mensajes PUBLISH
75
5.3.4. Procesamiento de XML Captulo 5. LBS Personalizados
que actualizan la localizacin del usuario y los mensajes BYE que concluyen
la entrega del contenido LBS.
Procesamiento de Mensajes Response: Procesa los mensajes contestados
por peticiones propias. Bajo este proceso se inicia la sesin con el Servidor
de Contenidos, la sesin con el usuario y se entrega el contenido correspon-
diente. Aqu lo relevante es que los mensajes se procesan individualmente,
por lo cual su implementacin se garantiza siguiendo el flujo mostrado en
la Figura 5.2.
5.3.4. Procesamiento de XML

Ambos servicios LBS personalizados dependen enormemente del anlisis sin-
tctico correcto de XML al momento de procesar los mensajes PUBLISH gene-
rados por el cliente. El servicio de Cartelera Personalizada tambin requiere de
esta funcionalidad cuando procesa las preferencias de los usuarios al momento
de filtrar la cartelera. Con el motivo de atacar esta exigencia, se desarroll un
parser XML genrico capaz de procesar cualquier archivo XML a partir de su
XSD correspondiente. Teniendo esta herramienta, el AS es capaz de procesar y
validar las actualizaciones y preferencias de los usuarios con relativa facilidad.
Esto ocasion que se tuvieron que colocar los archivos XSD de localizacin y
preferencia dentro del contenedor HTTP del AS para siempre tenerlos disponi-
bles. Adicionalmente, se tuvo que modificar ligeramente el XML que contiene la
informacin para especificar la localizacin del nuevo XSD en su definicin de
esquema.
5.3.5. Construccin de la Cartelera

La falta de Servicios Web (Web Services) disponibles para ofrecer un servi-
cio de cartelera en Mxico gener la necesidad de desarrollar un procedimiento
para extraer la informacin deseada desde la pgina web de los cines. Para este
trabajo de tesis se decidi extraer dicha informacin desde Cinemex debido a
su gran penetracin en el mercado. La implementacin de este procedimiento se
realiz con la creacin de tres clases, las cuales se detalla su funcionamiento a
continuacin:
NodoPelicula: Sirve como una estructura de datos donde se almacena toda

informacin relevante acerca de la pelcula. Contiene el nombre de la pe-
76
5.3.6. Consultas XCAP Captulo 5. LBS Personalizados
lcula, el gnero, y una lista con los distintos horarios en que se exhibe la
pelcula.
Cartelera: Sirve como una estructura de datos que contiene una lista de pel-
culas construidas con la ayuda de la clase NodoPelicula.
cinemexParser: Es una clase que consulta la pgina web de Cinemex y cons-
truye una cartelera con la ayuda de la clase Cartelera.
La construccin de la cartelera implementada en la clase cinemexParser es

algo complejo. El nombre del cine se obtiene desde la base de datos del AS.
Posteriormente se consulta de manera automtica la cartelera del cine en la
pgina de Cinemex. La consulta devuelve cdigo HTTP que es procesado por
el AS. ste busca palabras claves que identifican a cada pelcula para construir
la cartelera y ordenarlo en un arreglo, deshacindose del cdigo HTTP. Poste-
riormente por cada pelcula se obtiene de manera automtica el horario de la
funcin ms prxima de las pelculas que conforman la cartelera. El gnero de
cada pelcula se realiza mediante una consulta adicional a otra pgina web de
Cinemex que contiene una breve sinopsis acerca de la pelcula y el gnero que es
extrado de manera automtica a partir del cdigo HTTP de la misma. Tenien-
do la cartelera completa se realiza un filtrado que permite su personalizacin al
nicamente incluir gneros que prefiere el usuario. Adicionalmente se ordenan
las pelculas en orden descendiente segn dichas preferencias.
5.3.6. Consultas XCAP

El nico elemento restante en la implementacin del AS es la obtencin de
las preferencias de los usuarios para el servicio de Cartelera Personalizada. Di-
chas preferencias se encuentran en el Servidor de Presencia como PIDFs. Debido
a una limitante presente en el Servidor de Presencia, no se puede manipular los
PIDFs personalizados ya que no se puede verificar la integridad de los docu-
mentos XML con la ayuda de XSDs locales. Por lo tanto, es necesario hacer uso
de un analizador sintctico (parser) genrico desarrollado en la Seccin 5.3.4.
En cuanto al almacenamiento del PIDF dentro del Servidor de Presencia, ste
cuenta con la capacidad de aceptar un registro de prueba sin la necesidad de
verificar su integridad.
Para que el AS pueda tener acceso a la informacin contenida dentro del Ser-
vidor de Presencia, ste tiene que actuar como cliente. En vez de implementar
77
5.4. Notificaciones de Localizacin Captulo 5. LBS Personalizados
un cliente XCAP dentro del AS, se opt por usar uno existente: XCAPClient.
Sin embargo, esto requiere de una interfaz por la cual el AS puede hacer uso del
cliente. Esto se solucion creando una clase que interacta con el sistema ope-
rativo permitiendo ejecutar el cliente y obtener la informacin que ste regresa.
Dicha informacin se encuentra en forma de XML el cual puede ser procesado
sin problema por el AS.
5.4. Notificaciones de Localizacin

Hasta este momento no se ha profundizado sobre la informacin que el UE
enva al AS cuando actualiza su localizacin. Dado que los clientes se encuentran
en el Laboratorio de Redes Avanzadas sin la posibilidad de salirse de sus confines,
la nica manera de crear el escenario planteado anteriormente es simular cliente
mviles en los equipos del Laboratorio de Redes Avanzadas. Dicha simulacin
se logra con la ayuda de un cliente dedicado que se encarga exclusivamente de
generar los mensajes SIP con el mtodo PUBLISH. Los mensajes se generan cada
cinco minutos con coordenadas predefinidas que aseguran una trayectoria que
incluye los destinos tursticos y cines registrados. Las coordenadas geogrficas
son enviadas en un archivo XML dentro del cuerpo del mensaje SIP.
El cliente dedicado se desarroll con la ayuda de un script encargado de rea-
lizar esta operacin. Su correcto funcionamiento requiere correr en una mquina
donde se ha iniciado el cliente UCT y registrado un usuario. El script recibe
como parmetro el SIP-URI del usuario registrado para posteriormente obtener
el puerto en que est corriendo el cliente, y procede a generar mensajes PUBLISH
peridicamente con la ayuda de SIPp. El script es responsable de construir los
parmetros con los cuales se ejecuta SIPp. Dichos parmetros son utilizados en
la construccin de los mensajes SIP que genera. El comportamiento de SIPp se
define dentro de un archivo XML que contiene el flujo de mensajes que ste
intercambia junto con instrucciones de cmo construir el mensaje SIP. A su vez,
el contenido de los mensajes SIP se obtienen de archivos Valores Separados por
Comas (Comma Separated Values: CSV) que contienen las coordenadas geo-
grficas con las cuales se simula el movimiento de los clientes. La Figura 5.7
ejemplifica este proceso de manera grfica.
Este diseo permite tener un XML genrico que construye los mensajes
PUBLISH con las especificaciones del sistema. A su vez se puede tener una canti-
dad infinita de archivos CSV con cualquier conjunto de coordenadas geogrficas
78
5.5. Cambios a los Dominios Captulo 5. LBS Personalizados
Figura 5.7: Generacin de Notificaciones de Localizacin
simulando el movimiento del cliente.
5.5. Cambios a los Dominios

An despus de implementar exitosamente el AS donde radican los servicios
LBS y desarrollar una metodologa donde el cliente actualiza su localizacin, no
es suficiente para poner en marcha los servicios personalizados. Primero se tiene
que permitir el acceso a los mensajes PUBLISH generados por SIPp al dominio
IMS. Despus es necesario modificar y crear los iFCs que definen la interaccin
con el AS. Esta Seccin se encarga de describir los cambios necesarios para
habilitar los servicios personalizados dentro de los dominios IMS.
5.5.1. Configuracin del P-CSCF

La funcin P-CSCF se encarga de validar los mensajes entrantes al domi-
nio IMS, imposibilitando la entrada de mensajes no registrados. Esto incluye
mensajes originados desde puertos en los cuales no se encuentra registrado un
usuario. Por lo tanto, el dominio IMS rechaza los mensajes generados por SIPp
al momento de actualizar la localizacin de los usuarios. Se modific la configu-
racin del P-CSCF, aadindole una excepcin que permite la entrada de dichos
mensajes.
79
5.5.2. iFC para IPTV Captulo 5. LBS Personalizados
5.5.2. iFC para IPTV

El iFC detecta la solicitud de los servicios a partir de expresiones regulares
que se encuentran como parmetros dentro de encabezados especficos de mensa-
jes SIP. Esta combinacin de condiciones se denomina con el nombre de Trigger
Point debido a que cuando se cumplen dichas condiciones dispara la entrega del
servicio correspondiente. Originalmente, el iFC usado por el Servidor de Conte-
nidos dentro del dominio IMS tiene Trigger Points configurados de tal manera
que nicamente se pueden iniciar sesiones con el Servidor de Contenidos por
usuarios registrados. Esto crea un conflicto al momento de iniciar la sesin des-
de el AS desarrollado ya que ste ni es un usuario ni esta registrado, por lo cual
es necesario modificar el Trigger Point del Servidor de Contenidos, aadindole
esta funcionalidad. Las nuevas reglas de filtrado incluyen una excepcin donde
el mensaje INVITE proviene del servidor y adems contiene un encabezado iden-
tificndolo como tal. El Cuadro 5.1 muestra la nueva configuracin del Trigger
Point.
Seccin Campo Valor
Principal Condition Type CMF Disjunctive Normal Format
SIP Method INVITE
Trigger Point 1 SIP Header To
SIP Header Content .*iptv.titania.ipv6.itam.mx.*
SIP Header From
SIP Header Content .*lbs.titania.ipv6.itam.mx.*
Trigger Point 2
SIP Header Server
SIP Header Content lbs.titania.ipv6.itam.mx (Glass-
fish SIP v1.0.0)
Cuadro 5.1: Trigger Points Definidos para el Servidor de Contenidos
El primer rengln del Cuadro 5.1 indica como se agrupan los Trigger Points.
El formato Disjunctive Normal Format le indica al iFC que la unin lgica
de los campos del Trigger Point se unen mediante el operador lgico AND. A
su vez, los Trigger Points se unen mediante el operador lgico OR. Traducido
en trminos humanos, el Cuadro 5.1 le indica al iFC que contesta solicitudes de
IPTV cuando recibe mensajes con el mtodo INVITE y un SIP-URI que contiene
el nombre del Servidor de Contenidos. Tambin contesta solicitudes cuando el
mensaje recibido proviene del AS desarrollados y se identifica como un servidor
80
5.5.3. iFC para LBS Captulo 5. LBS Personalizados
GlassFish.
5.5.3. iFC para LBS

Finalmente es necesario dar de alta el AS creado dentro de los dominios IMS.
Lo ms importante al momento de dar de alta los servicios LBS personalizados
es asegurarse de que las reglas de filtrado se ajusten al diseo e implementacin
detallado en este documento. El Cuadro 5.2 muestra el Trigger Point que debe
tener el AS para funcionar correctamente.
Seccin Campo Valor

Principal Condition Type CMF Conjunctive Normal Format
SIP Method PUBLISH
Trigger Point 1
SIP Method SUBSCRIBE
SIP Header Event
SIP Header Content location
Trigger Point 2
SIP Header To
SIP Header Content .*lbs.titania.ipv6.itam.mx.*
Cuadro 5.2: Trigger Points Definidos para los Servicios LBS Personalizados
El primer rengln del Cuadro 5.2 indica como se agrupan los Trigger Points.
El formato Conjuntive Normal Format le indica al iFC que la unin lgica de los
campos del Trigger Point se unen mediante el operador lgico OR. A su vez, los
Trigger Points se unen mediante el operador lgico AND. Traducido en trminos
humanos, el Cuadro 5.2 le indica al iFC que contesta solicitudes de LBS cuando
recibe mensajes con el mtodo PUBLISH o SUBSCRIBE. Los mensajes adems
deben ir dirigidos al AS y poseer un evento location (de localizacin).
5.6. Cambios al Cliente

El anlisis detallado de las capacidades del cliente realizado en la Sec-
cin 5.2.2 dio luz a un detalle curioso dentro del funcionamiento del cliente
al momento de iniciar sesiones de multimedia. Como ya se ha explicado en este
Captulo, el cliente UCT nicamente esta diseado para trabajar bajo escenarios
predefinidos, los cuales incluyen un conjunto limitado de flujos de mensajes SIP.
El cliente supone que nicamente va interactuar con el Servidor de Contenidos
81
5.7. Escenario de Pruebas Captulo 5. LBS Personalizados
cuando l es quien haya iniciado la sesin, lo cual es lgico ya que generalmente

un servidor responde a peticiones del cliente. Para el caso de los servicios LBS
personalizados, el AS inicia una sesin con el usuario ofrecindole el SDP del
Servidor de Contenidos. Este SDP no va incluido dentro del cuerpo del mensa-
je SIP como lo dictan los estndardes, sino que se encuentra en el encabezado
Content-Type definiendo el tipo de contenido que tiene el cuerpo inexistente del
mensaje. Dentro de dicho encabezado se encuentran las instrucciones necesarias
para redireccionar el cliente hacia el destino del contenido RTP que viene siendo
el servidor DSS. Esto, visto desde el punto de vista del cliente UCT, equivale a
ser llamado por el Servidor de Contenidos lo cual es imposible.
Cuando el cliente detecta que el destinatario de una llamada es el Servidor
de Contenidos, inicia una serie de procesos internos que le permite establecer
una sesin RTP con el servidor. Esta serie de procesos nicamente se realiza
cuando el ltimo mensaje procesado es del tipo ACK. Para habilitar la entrega de
contenido LBS hacia el cliente UCT se tuvo que modificar el cdigo fuente del
cliente para incluir este tratamiento especial cuando el ltimo mensaje procesado
equivale a un OK. Para lograr el funcionamiento correcto en el cliente adems
se tuvieron que modificar las variables de estado donde el cliente detecta que se
encuentra en una llamada y destruye el pipeline o canal por donde se escucha
el timbrado de la llamada.
5.7. Escenario de Pruebas

Para probar la factibilidad de ofrecer servicios LBS personalizados se cons-
truy un escenario virtual donde se simula el movimiento de los usuarios. El
escenario virtual consta de cuatro usuarios IMS y varios cines y atracciones
tursticas. Dos de ellos se trasladan a pie en el centro visitando atracciones
tursticas, mientras que los otros dos se trasladan dentro de un automvil en
busca de una buena pelcula. A continuacin se presenta una breve descripcin
del comportamiento de cada usuario dentro del escenario virtual.
Usuario 1: Es un turista que le gusta descubrir nuevas atracciones a su propio

ritmo. Encontrar nuevos destinos al azar le es ms agradable que contratar
un paseo turstico con itinerarios predefinidos. Esto lo ha motivado probar
su nueva suscripcin al Gua Virtual en el centro turstico de la Ciudad
de Mxico.
82
5.8. Destinos e Itinerarios Captulo 5. LBS Personalizados
Usuario 2: Al igual que el Usuario 1, le gusta ser un turista independiente.

Sin embargo, l prefiere recorrer parques. Recientemente el Usuario 1 le
recomend el servicio de Gua Virtual. Sabiendo que cerca de la Alameda
Central se encuentran algunas atracciones tursticas ha decidido visitar su
parque favorito de la Ciudad de Mxico para probar el servicio de Gua
Virtual. Inicia su prueba saliendo de la estacin del metro Bellas Artes.
Usuarios 3 y 4: Ambos son estudiantes del ITAM, que saliendo de clase han
decidido ir al cine. Al Usuario 3 le gustan las pelculas de terror y accin.
En cambio, al Usuario 4 le gustan las pelculas de drama y comedia. Esta
diferencia en gustos evita que concuerden inmediatamente acerca de la
pelcula que van a ver juntos. Para pasar el tiempo suelen recorrer varios
cines hasta decidir la pelcula que van a ver juntos. Su cinefilia ha motivado
los dos a suscribirse al servicio de Cartelera Personalizada.
5.8. Destinos e Itinerarios

En el centro histrico estn dados de alta seis atracciones tursticas en el
AS. Estas atracciones son: el Palacio de Bellas Artes, el Hemiciclo a Benito
Jurez, la Plaza de la Constitucin, el Templo Mayor y la Catedral y Sagrario
Metropolitano. El Usuario 1 recibe videos al visitar la Plaza de la Constitucin
y el Templo Mayor; adems recibe un mensaje de texto estando dentro de la
Catedral y Sagrario Metropolitano. El Usuario 2 recibe videos al pasar cerca del
Palacio de Bellas Artes y el Hemiciclo a Benito Jurez.
A su vez, hay cuatro cines dados de alta en el AS: Cinemex Manacar, Uni-
versidad, WTC y Parque Delta. Los Usuarios 3 y 4 visitan los cines Manacar,
WTC y Parque Delta. A pesar de que van juntos reciben carteleras y contenido
multimedia distinto gracias al filtrado personalizado que realiza el servicio LBS.
La Figura 5.8 muestra las rutas que recorren los usuarios, la localizacin y rea
de cobertura de las atracciones tursticas y cines. La escala de la ruta recorrida
por los Usuarios 3 y 4 no permite apreciar el rea de cobertura de los cines, por
lo cual nicamente se marca la localizacin de los cines con un cruce.
83
5.9. Visualizacin del Funcionamiento Captulo 5. LBS Personalizados
(a) Usuarios 1 y 2 (b) Usuarios 3 y 4
Figura 5.8: Rutas que Recorren los Usuarios
5.9. Visualizacin del Funcionamiento

Se presentan dos imgenes que permiten apreciar de manera grfica la en-
trega del servicio de Gua Virtual a los Usuarios 1 y 2. La Figura 5.9 muestra
la entrega de dicho servicio al Usuario 1. Del lado superior izquierdo se puede
ver la secuencia de menajes SIP intercambiado con el AS para establecer la se-
sin SIP y una notificacin de que se estableci una sesin RTP con el Servidor
de Contenidos. Del lado inferior izquierdo se muestran los mensajes de texto
que recibe el usuario notificndole de las atracciones tursticas. Estos mensajes
contienen una breve descripcin de la atraccin para que el usuario pueda ubi-
car el contenido multimedia dentro del contexto apropiado. Finalmente del lado
derecho se puede apreciar el video que representa el contenido multimedia.
La Figura 5.10 muestra la entrega del servicio de Gua Virtual al Usuario 2.
La diferencia entre esta imagen y la anterior radica en que la ltima presenta
la interfaz del cliente antes de aceptar la sesin SIP del AS. Adems de poder
apreciar los mensajes de texto y secuencia de mensajes SIP vistos en la Figu-
ra 5.10, la Figura 5.10 permite apreciar un poco de informacin adicional. Del
lado superior izquierdo se puede ver cmo el AS personaliza el SIP-URI con el
cual trata de establecer una sesin con el usuario. El SIP-URI permite que el
usuario sepa el nombre de la atraccin turstica antes de aceptar la entrega del
contenido.
84
Figura 5.9: Entrega del Servicio al Usuario 1
Figura 5.10: Entrega del Servicio al Usuario 2
Ahora se presentan dos imgenes que permiten evaluar la entrega del servicio
de Cartelera Personalizada. A pesar de que los Usuarios 3 y 4 recorren la misma
85
ruta a la misma hora. la Figura 5.11 muestra la diferencia entre las carteleras
que reciben debido al filtrado personalizado que emplea el servicio de Cartelera
Personalizada. El contenido multimedia que reciben es el avance cinematogrfico
de la primer pelcula de cada cartelera mostrada.
(a) Usuario 3 (b) Usuario 4
Figura 5.11: Entrega del Servicio a los Usuarios 3 y 4
86
Captulo 6
Conclusiones y Lneas
Futuras
Este trabajo de tesis expuso los obstculos con los que se enfrentan los opera-
dores al migrar sus redes actuales a las redes NGN. Se presentaron las ventajas
que ofrece el modelo de Plataforma de Entrega de Servicios sobre el actual Sn-
drome Silo. Adems se mostr cmo la plataforma IMS forma un principal
catalizador en la adopcin de redes NGN al proporcionar una Plataforma de
Entrega de Servicios construida a partir de soluciones abiertas. Adicionalmente,
se present lo atractivo y revolucionario que pueden ser los servicios LBS perso-
nalizados al momento de mejorar la QoE de sus usuarios en redes transparentes.
Este Captulo se encarga de resumir las aportaciones de este trabajo de tesis y
sus futuras lneas de trabajo.
6.1. Acerca de la Maqueta IMS

Sin duda es importante mencionar que sin la ayuda de herramientas abiertas
desarrolladas por FOKUS, UCT, Asterisk y varias otras organizaciones, hubiera
sido imposible realizar este trabajo. Se logr el alcance buscado en el despliegue
exitoso de una maqueta IMS que brinda las funcionalidades bsicas de telecomu-
nicaciones como una Plataforma de Entrega de Servicios dentro del Laboratorio
de Redes Avanzadas del ITAM. La dificultad en lograr el primer objetivo radi-
87
6.1. Acerca de la Maqueta IMS Captulo 6. Conclusiones y Lneas Futuras
ca en garantizar la interoperabilidad entre cada uno de los componentes de la

maqueta.
El conocimiento aportado por los trabajos previos de [12, 58, 59] redujo
enormemente el trabajo e investigacin al momento de definir los componentes
que juntos formaron la maqueta. Este trabajo de tesis logra construir sobre
las bases que proporcionan [59] y [12]. La maqueta contruida logra ofrecer una
mayor gama de servicios que la maqueta construida por [12]. Esto se debe en
gran parte a que ya existen mejores soluciones para IMS, como el soporte de
mensajera instantnea incluido con el cliente UCT, permitiendo ahorrar tiempo
en la acumulacin de servicios dentro de la maqueta.
Este trabajo logra unir las herramientas OpenSIPS y OpenXCAP en una en-
tidad para formar un XDMS. Este proceso tuvo sus obstculos que fueron resuel-
tos. Al momento de desplegar la maqueta se tuvo la desventaja que el proyecto
OpenSER se dividi en dos: OpenSIPS y Kamailio. El primero de ellos fue usado
para construir el Servidor de Presencia (XDMS) bajo condiciones no ideales. En
otras palabras, la inestabilidad de esta herramienta dificult enormemente la
construccin del AS debido principalmente a que no se garantizaba su funcio-
namiento correcto. Parece ser que despus de esta ruptura existir una mejor
integracin entre las herramientas OpenXCAP y OpenSIPS (las herramientas
usadas para construir el XDMS en la maqueta). Suponiendo un mejoramiento
en el soporte de sus funciones actuales, existen dos deficiencias que posee esta
solucin:
1. OpenXCAP carece la capacidad de manipular archivos XML que no estn

predefinidos en su programacin. Se propone una reestructuracin a sus
procesos internos para que el manejar de los archivos XSD sea modular,
permitiendo agregar fcilmente un sin fin de PIDFs personalizados.
2. El cliente UCT carece de un manejo de certificados digitales que le permi-
ta actualizar sus PIDFs hacia el servidor XDMS. Se propone robustecer
su manejo del protocolo HTTP de tal manera que evolucione a sopor-
tar el protocolo HTTPS. Esto reducira la necesidad de utilizar el cliente
XCAPClient para realizar dichas actualizaciones.
Aunque es posible solucionar estas deficiencias, cualquier modificacin o me-

jora debe ser solicitada como un parche a los desarrolladores. De lo contrario,
no es posible garantizar que las modificaciones al cdigo fuente sean vlidas en
las futuras versiones de estas herramientas.
88
6.1. Acerca de la Maqueta IMS Captulo 6. Conclusiones y Lneas Futuras
A diferencia del trabajo de [59], este trabajo de tesis logr habilitar la entrega
de servicios empresariales a los usuarios IMS. El servicio de directorio, llamadas
en espera, transferencia de llamadas y acceso a la red PSTN es posible usando
Asterisk cmo un AS. A pesar de que la maqueta cuenta con la implementacin
exitosa de un gateway telefnico, la interaccin entre Asterisk y los dominios
IMS posee fallas. Una de las propuestas de IMS es volver transparente la red
con la ayuda del registro simultneo de perfiles pblicos (ver Seccin 2.3.4).
Sin embargo, esta funcionalidad no se pudo reproducir dentro de la maqueta
IMS. Fei Yao [59] soluciona esto con dos S-CSCFs trabajando en paralelo a
Asterisk para lograr el registro simultneo. Este trabajo de tesis aborda este
problema de otra manera. En vez de realizar un registro simultneo, se delega
la responsabilidad de encontrar el usuario a Asterisk. Teniendo a su disposicin
una tabla de equivalencias, Asterisk es capaz de traducir el TEL-URI del usuario
IMS a su respectivo SIP-URI. Este proceso evita la necesidad de un registro
simultneo.
Las futuras lneas para mejorar este funcionamiento consisten en mejorar
la interaccin de registro entre los clientes UCT y los dominios desarrollados
por FOKUS. Actualmente el cliente nicamente se registra con una identidad
privada precisamente porque el dominio IMS es incapaz de registrar varias iden-
tidades de manera implcita. Esto requiere mejorar tanto el cdigo de OpenIMS
Core como la de UCT IMS Client.
Finalmente, se propone aadir funcionalidades a la maqueta para que sta
refleje fielmente una plataforma IMS en el mbito empresarial. La Seccin 3.8
ya aborda las posibles mejoras a la maqueta desplegada. Se har mencin de las
ms importantes:
1. Habilitar servicios de roaming en la maqueta.

2. Migrar todos los componentes e infraestructura de la maqueta a IPv6.
3. Desarrollar un AS capaz de ofrecer Push To Talk over Celular.
Algunos componentes de la maqueta, como son Asterisk y OpenSIPS, so-

portan el trfico y exigencias de un ambiente de empresarial. La integracin de
las herramientas OpenSIPS y OpenXCAP, a pesar de presentar sus problemas,
parece ser que pueden ser implementado en un ambiente de produccin. En par-
ticular esto se debe a que el motor detrs del XDMS es OpenSIPS. Sin embargo
el ncleo IMS no esta diseado para tener un alto rendimiento e inhabilita la
89
6.2. Acerca de los Servicios LBS Captulo 6. Conclusiones y Lneas Futuras
posibilidad de utilizar la maqueta construida en este trabajo de tesis dentro de

un ambiente de produccin empresarial. Sin embargo, se considera que las apor-
taciones y la robustez de la maqueta se puede aprovechar para futuros proyectos
que tienen como objetivo mejorar el rendimiento de la misma.
6.2. Acerca de los Servicios LBS

El objetivo de este trabajo de tesis se cumpli cuando se pudo ofrecer exito-
samente servicios LBS personalizados sobre la infraestructura que proporcion
la maqueta IMS. Como bien se report en la Seccin 5.2, el diseo original de
los servicios LBS no fue el que se implement. Esto se debe a varias suposiciones
falsas realizadas durante el diseo. Se realizaron dos graves errores que dieron
lugar a dichas suposiciones. El primero fue suponer que la implementacin res-
peta los estndardes al 100 %. El segundo fue suponer que el cliente UCT cuenta
con todas las funcionalidades y puede operar bajo todos los escenarios posibles.
Este error se agudiza cuando se toma en cuenta que el cliente est diseado
para trabajar especficamente bajo ciertas condiciones con OpenIMS Core y es
clasificado como una herramienta de prueba. Las lecciones aprendidas por este
mal diseo son las siguientes:
1. Un buen diseo facilita y acelera la implementacin de cualquier solucin

tecnolgica.
2. Al momento de disear una solucin tecnolgica es de suma importancia

no realizar ninguna especie de suposicin basada en la teora. Toda deci-
sin tomada en el diseo debe ser apoyada por bases y pruebas concretas
probadas tanto en la teora como en la prctica.
Sin embargo, redisear los servicios tuvo su lado positivo. Ahora las opera-
ciones lgicas por las cuales fluye el diseo son ms comprensibles a plena vista;
aunque la cantidad de operaciones haya aumentado (como sucedi con el flujo
de mensajes). Explicar los servicios LBS se vuelve una tarea ms sencilla ya que
no requiere demasiado conocimiento previo para saber que hace; mientras que
para saber como lo hace es otra historia.
Las facilidades que brinda IMS como Plataforma de Entrega de Servicios
agiliz la creacin de los servicios personalizados al delegar funcionalidades es-
pecficas a los componentes modulares que provee. La entrega de los contenidos
90
6.3. Desarrollo de un Cliente IMS Mvil
Captulo 6. Conclusiones y Lneas Futuras
personalizados fue satisfactorio. Incluso en el ambiente de simulacin los ser-

vicios son bastante atractivos ya que expone la flexibilidad con la que cuenta
IMS al habilitar la entrega de nuevos servicios. Adems, exportar la funcionali-
dad de los servicios a un ambiente mvil requiere de relativamente poco trabajo
gracias a su realizacin con tecnologas abiertas. La visualizacin grfica de los
usuarios y destinos sirve tanto como una herramienta administrativa como un
ejemplificacin perfecta de la operacin de los servicios fuera del ambiente de
pruebas.
El esquema de tarificacin presentado en la Seccin 4.6 propone un modelo
donde una parte del gasto es absorbida por el Servidor de Contenidos al momen-
to de cobrarle al cliente. Dicho modelo ya no es vlido con el nuevos diseo de
los servicios ya que (1) el AS tiene una mayor intervencin en las sesiones esta-
blecidas y (2) la sesin con el Servidor de Contenidos se inicia con la informacin
del AS, ya no con la del cliente. Esto complica el proceso de tarificacin por la
simple razn de que ya se estn utilizando recursos aunque el cliente rechace el
contenido LBS, mientras que en el diseo original esto no suceda. La manera
de resolver esto es depender completamente de la informacin obtenida por la
funcin CSCF. A partir de dicha informacin, el AS conoce el gasto que gener
en los recursos de la red y puede cobrar por el adecuadamente. Al Servidor de
Contenidos se le paga la cantidad correspondiente por el gasto generado en la
entrega del contenido multimedia. Al cliente se le sigue cobrando una renta fija
mnima por el uso de los servicios. Se le cobrar una renta adicional que depende
de la cantidad de sesiones RTP que consume.
6.3. Desarrollo de un Cliente IMS Mvil

Las funcionalidades adicionales propuestas en la Seccin 6.1 requieren mejo-
rar la capacidad que tiene el cliente UCT para hacer uso de ellas. Esta continua
modificacin ha motivado la creacin de un cliente propio capaz de mejorar so-
bre las funcionalidades que brinda el cliente UCT. Una mera reproduccin del
cliente no aporta nada nuevo, por lo cual se propone que tambin sea capaz de
correr sobre dispositivos celulares. Adems al correr sobre dispositivos mviles,
se podr probar el desempeo de los servicios LBS personalizados fuera de un
ambiente simulado. A continuacin se proporciona una lista de las caractersticas
mnimas con las que debe contar el cliente a desarrollar.
1. Capaz de reproducir todas las funcionalidades y capacidades del cliente
91
6.4. Conclusiones Finales Captulo 6. Conclusiones y Lneas Futuras
UCT dentro de la maqueta. Esto incluye la habilidad de registrarse a los

dominios IMS con autenticacin MD5, realizar video llamadas con clientes
SIP y PSTN, y soportar el envi y recepcin de actualizaciones de presencia
con el Servidor de Presencia.
2. Debe poder manejar certificados digitales con la finalidad de actualizar
correctamente sus PIDFs va HTTPS con el Servidor de Presencia.
3. Contar con un mecanismo para actualizar su localizacin mediante la ge-

neracin peridica de mensajes PUBLISH.
4. Contar con una interfaz amigable que pueda activar o desactivar la actua-
lizacin de coordenadas geogrficas.
5. Tener la flexibilidad de iniciar distintos tipos de sesiones de multimedia

(RTP, playlists sobre HTTP, etctera).
El cliente mvil puede ser desarrollado con la ayuda de una herramienta de

Ericsson recientemente liberada al pblico llamada Ericsson Service Develop-
ment Studio (SDS) 4.1 [20], la cual puede ser encontrada en la red gratuitamen-
te.
6.4. Conclusiones Finales

Esta Seccin hace un breve resumen de las conclusiones realizadas en este
Captulo. Los objetivos de este trabajo de tesis se cumplieron exitosamente al
ver funcionar en armona todos los componentes de la maqueta y al presenciar
la entrega de los servicios LBS personalizados. Las desventajas de trabajar con
herramientas FOSS radican es su documentacin variada (sta puede ser buena
o mala sin precedente alguno) y en garantizar la estabilidad de sus componentes.
En cambio, las ventajas radican en los siguientes puntos:
Se obtiene un conocimiento profundo del funcionamiento de sus procesos,

permitiendo realizar un mejor diseo al conocer las vulnerabilidades.
Tener acceso a su cdigo fuente permite un mayor grado de personaliza-

cin, lo cual permite adaptar las herramientas a condiciones a las cuales
no fueron diseadas.
92
6.5. Lneas Futuras Captulo 6. Conclusiones y Lneas Futuras
Son herramientas gratuitas que no detienen su desarrollo por medio de

licencias.
Tanto la maqueta, como los servicios LBS tienen bastante potencial para
demostrar las facilidades que brindan IMS en la convergencia digital y la QoE
de sus usuarios. A pesar de todos los obstculos presentes en la construccin
de la maqueta y la implementacin de los servicios, se puede considerar que el
alcance que tuvo este trabajo de tesis super las expectativas al desplegar una
maqueta robusta y servicios atractivos. Finalmente, queda mencionar que la
maqueta IMS y los servicios LBS personalizados quedan a disposicin del ITAM
para su uso en futuros proyectos.
6.5. Lneas Futuras

Esta Seccin hace un breve listado de las futuras lneas de trabajo que ya
se han presentado en este Captulo para la maqueta IMS y los servicios LBS
personalizados.
1. Habilitar servicios de roaming en la maqueta.
2. Migrar todos los componentes e infraestructura de la maqueta a IPv6.

3. Instalar un servidor MSRP que sirva como un AS.
4. Desarrollar un AS capaz de ofrecer Push To Talk over Celular.

5. Implementar una interfaz (ya sea grfica o a base de un flujo de mensajes)
por la cual se administra el registro de los usuarios a los servicios LBS
personalizados.
6. Poner en marcha el esquema de traficacin presentado en la Seccin 4.6
junto con las consideraciones adicionales realizadas al final de la Sec-
cin 6.2.
7. Mejorar la entrega de los avances cinematogrficos. Permitiendo al usuario

la capacidad de elegir entre las pelculas de su cartelera personalizada.
8. Desarrollar una interfaz donde el usuario pueda elegir el avance cinema-

togrfico que desea ver a partir de la cartelera entregada.
93
6.5. Lneas Futuras Captulo 6. Conclusiones y Lneas Futuras
9. Desarrollar un cliente mvil que pueda aprovechar todas las funcionalida-

des de la maqueta y los servicios LBS personalizados.
94
Captulo 7
Referencias Bibliogrficas
[1] 3GPP: IP Multimedia Core Network Subsystem (IMS) Multimedia Telep-

hony Service and supplementary services; Stage 1. TS 22.173, 3rd Genera-
tion Partnership Project (3GPP), Sep. 2008. http://www.3gpp.org/ftp/
Specs/html-info/22173.htm.
[2] 3GPP: IP Multimedia Subsystem (IMS) Service Continuity; Stage 3. TS

24.237, 3rd Generation Partnership Project (3GPP), Sep. 2008. http:
//www.3gpp.org/ftp/Specs/html-info/24237.htm.
[3] 3GPP: IP Multimedia Subsystem (IMS); Stage 2. TS 23.228, 3rd Genera-
tion Partnership Project (3GPP), Sep. 2008. http://www.3gpp.org/ftp/
Specs/html-info/23228.htm.
[4] 3GPP: Technical realization of Short Message Service (SMS). TS 23.040,

3rd Generation Partnership Project (3GPP), Sep. 2008. http://www.
3gpp.org/ftp/Specs/html-info/23040.htm.
[5] 3GPP: Technical Specifications and Technical Reports relating to the Com-
mon IP Multimedia Subsystem (IMS). TS 21.202, 3rd Generation Partners-
hip Project (3GPP), May 2008. http://www.3gpp.org/ftp/Specs/html-
info/21202.htm.
[6] M. Amarascu, R. Klaver, L. Stanescu y D. Bilenko: OpenXCAP. http:

//openxcap.org/.
95
Captulo 7. Referencias Bibliogrficas
[7] F. Andreasen: SDP Capability Negotiation. Internet-Draft draft-ietf-

mmusic-sdp-capability-negotiation-09, Internet Engineering Task For-
ce, Jul 2008. http://www.ietf.org/internet-drafts/draft-ietf-
mmusic-sdp-capability-negotiation-09.txt.
[8] Apple: Darwin Streaming Server. http://developer.apple.com/
opensource/server/streaming/index.html.
[9] T. Berners-Lee, R. Fielding y L. Masinter: Uniform Resource Identifier

(URI): Generic Syntax. RFC 3986, Internet Engineering Task Force, Ene.
2005. http://www.rfc-editor.org/rfc/rfc3986.txt.
[10] A. Brajdic, O. Lapcevic, M. Matijasevic y M. Mosmondor: Service Com-
position in IMS: A Location Based Service Example. En Wireless Perva-
sive Computing, 2008. ISWPC 2008. 3rd International Symposium, pgs.
208212, 2008.
[11] M. Brenner y M. Unmehopa: The Open Mobile Alliance: Delivering Service
Enablers for Next-Generation Applications. J. Wiley & Sons, Chichester,
England; Hoboken, NJ, Abr. 2008.
[12] L. Broman: IMS Platform Prototype. Tesis de Maestra, Lule University

of Technology, Oct. 2008.
[13] P. Calhoun, J. Loughney, E. Guttman, G. Zorn y J. Arkko: Diameter Base

Protocol. RFC 3588, Internet Engineering Task Force, Sep. 2003. http:
//www.rfc-editor.org/rfc/rfc3588.txt.
[14] G. Camarillo y M. A. Garca-Martn: The 3G IP Multimedia Subsystem
(IMS) : Merging The Internet And The Cellular Worlds. J. Wiley & Sons,
Chichester, England; Hoboken, NJ, 2a ed., May 2006.
[15] Content Team BSNL Portal Intelligroup Asia Pvt. Ltd.: IMS Investment
To Reach $10.1 Billion in 5 yrs, Jun 2006. [http://portal.bsnl.in/
telecomnewsanalysis.asp?intNewsId=69133, accesado 12/10/08].
[16] A. Cuevas, J. I. Moreno, P. Vidales y H. Einsiedler: The IMS Service Plat-
form: A Solution For Next-Generation Network Operators To Be More
Than Bit Pipes. Communications Magazine, IEEE, 44(8):7581, 2006.
96
[17] T. Dierks y E. Rescorla: The Transport Layer Security (TLS) Protocol

Version 1.2. RFC 5246, Internet Engineering Task Force, Ago. 2008. http:
//www.rfc-editor.org/rfc/rfc5246.txt.
[18] Ericsson: IMS IP Multimedia Subsystem. White Paper, Oct. 2004.

[19] Ericsson: Introduction to IMS. White Paper, Mar. 2007.
[20] Ericsson AB: Ericsson Service Development Studio (SDS) 4.1.

http://www.ericsson.com/developer/sub/open/technologies/
ims_poc/tools/sds_40.
[21] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach y

T. Berners-Lee: Hypertext Transfer Protocol -- HTTP/1.1. RFC 2616,
Internet Engineering Task Force, Jun 1999. http://www.rfc-editor.
org/rfc/rfc2616.txt.
[22] Fraunhofer Institute for Open Communications Systems: Open IMS Core.
http://openimscore.org/.
[23] A. Frier, P. Karlton y P. Kocher: The SSL 3.0 Protocol. Informe tcnico.,
Netscape Communications Corp., Nov. 1996. http://www.mozilla.org/
projects/security/pki/nss/ssl/draft302.txt.
[24] M. Handley y V. Jacobson: SDP: Session Description Protocol. RFC 2327,
Internet Engineering Task Force, Abr. 1998. http://www.rfc-editor.
org/rfc/rfc2327.txt.
[25] M. Handley, H. Schulzrinne, E. Schooler y J. Rosenberg: SIP: Session

Initiation Protocol. RFC 2543, Internet Engineering Task Force, Mar.
[26] J. Hjelm: Creating Location Services for the Wireless Web. J. Wiley &
Sons, New York, Feb. 2002.
[27] M. Isomaki y E. Leppanen: An Extensible Markup Language (XML) Con-
figuration Access Protocol (XCAP) Usage for Manipulating Presence Do-
cument Contents. RFC 4827, Internet Engineering Task Force, May 2007.
http://www.rfc-editor.org/rfc/rfc4827.txt.
97
[28] ITU-T: General Overview of NGN. ITU Recommendation Y.2001, Interna-

tional Telecommunication Union Telecommunications Sector, Dic. 2004.
http://www.itu.int/itudoc/itu-t/com13/ngn/9_ww9.doc.
[29] ITU-T: NGN FG Proceedings. ITU Proceedings Parte II, International
Telecommunication Union Telecommunications Sector, Dic. 2005. http:
//www.itu.int/ITU-T/ngn/files/NGN_FG-book_II.pdf.
[30] ITU-T: Packet-Based Multimedia Communications Systems. ITU Recom-
mendation H.323, International Telecommunication Union Telecommuni-
cations Sector, Jun 2006. http://www.itu.int/rec/dologin_pub.asp?
lang=e&id=T-REC-H.323-200606-I!!PDF-E&type=items.
[31] John G. Waclawsky: IMS: A Critique Of The Grand Plan. Business Com-
munications Review, 35(10):5458, Oct. 2005.
[32] S. Kent y K. Seo: Security Architecture for the Internet Protocol. RFC
4301, Internet Engineering Task Force, Dic. 2005. http://www.rfc-
editor.org/rfc/rfc4301.txt.
[33] A. Lotsson: Expect 4G Telephony In 2012 Says Ericsson Research Head,
May 2004. [http://www.arnnet.com.au/article/65267/expect_4g_
telephony_2012_says_ericsson_research_head, accesado 12/10/08].
[34] A. K. MacDonald: Configuration and Deployment of an IMS Test Bed.
Reporte Tcnico. Laboratorio de Redes Avanzadas, Instituto Tecnolgico
Autnomo de Mxico (ITAM), Ago. 2009.
[35] Mark Spencer de Digium, Inc.: Asterisk, 1999. http://www.asterisk.
org/.
[36] J. V. Meggelen, L. Madsen y J. Smith: Asterisk: The Future of Telephony.
OReilly Media, Inc, 1005 Gravenstein Highway North, Sebastopol, CA,
2a ed., Ago. 2007.
[37] E. Oguejiofor, P. Bazot, B. Georges, R. Huber, C. Jackson, J. Kappel,
C. Martin, B. S. Subramanian y A. Sur: Developing SIP and IP Multimedia
Subsystem (IMS) Applications. IBM RedBooks, 1a ed., Feb. 2007.
[38] M. Poikselk, A. Niemi, H. Khartabil y G. Mayer: The IMS : IP Multimedia
Concepts and Services. J. Wiley & Sons, Chichester, England; Hoboken,
NJ, 2a ed., Jul 2006.
98
[39] J. Rosenberg: Extensible Markup Language (XML) Formats for Represen-

ting Resource Lists. RFC 4826, Internet Engineering Task Force, May
[40] J. Rosenberg: The Extensible Markup Language (XML) Configuration Ac-
cess Protocol (XCAP). RFC 4825, Internet Engineering Task Force, May
[41] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson,
R. Sparks, M. Handley y E. Schooler: SIP: Session Initiation Protocol.
RFC 3261, Internet Engineering Task Force, Jun 2002. http://www.rfc-
editor.org/rfc/rfc3261.txt.
[42] J. Rosenberg y J. Urpalainen: An Extensible Markup Language (XML)
Document Format for Indicating A Change in XML Configuration Ac-
cess Protocol (XCAP) Resources. Internet-Draft draft-ietf-simple-xcap-
diff-09, Internet Engineering Task Force, May 2008. http://www.ietf.
org/internet-drafts/draft-ietf-simple-xcap-diff-09.txt.
[43] J. L. Salina y P. Salina: Next Generation Networks: Perspectives and Po-
tentials. J. Wiley & Sons, Chichester, England; Hoboken, NJ, Feb. 2008.
[44] J. Schiller y A. Voisard: Location-Based Services. Morgan Kaufmann,
1a ed., May 2004.
[45] H. Schulzrinne: The tel URI for Telephone Numbers. RFC 3966, Internet
Engineering Task Force, Dic. 2004. http://www.rfc-editor.org/rfc/
rfc3966.txt.
[46] H. Schulzrinne y C. Agboh: Session Initiation Protocol (SIP)-H.323 Inter-
working Requirements. RFC 4123, Internet Engineering Task Force, Jul
[47] H. Schulzrinne, S. Casner, R. Frederick y V. Jacobson: RTP: A Transport
Protocol for Real-Time Applications. RFC 3550, Internet Engineering Task
Force, Jul 2003. http://www.rfc-editor.org/rfc/rfc3550.txt.
[48] S. Shepard: IMS Crash Course. McGraw-Hill, New York, 2006.
[49] W. Stallings: Data And Computer Communications. Prentice Hall, Upper
Saddle River, N.J., 2000.
99
[50] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr y J. Peterson: Pre-

sence Information Data Format (PIDF). RFC 3863, Internet Engineering
Task Force, Ago. 2004. http://www.rfc-editor.org/rfc/rfc3863.txt.
[51] Sun Microsystems, Inc.: GlassFish. https://glassfish.dev.java.net/.

[52] Telefnica I+D.: Las Telecomunicaciones y la Movilidad en la Sociedad de
la Informacin. AHCIET, Albadalejo, S.L., 1a ed., Feb. 2005.
[53] Voice Systems: OpenSIPS, 2008. http://www.opensips.org/.

[54] W3C: SOAP Version 1.2 Part 1: Messaging Framework (Second Edition).
W3C Recommendation, World Wide Web Consortium, Ene. 2002. http:
//www.w3.org/TR/soap12-part1/.
[55] D. Waiting, R. Good, R. Spiers y N. Ventura: Open source development

tools for IMS research. En TridentCom '08: Proceedings of the 4th Inter-
national Conference on Testbeds and research infrastructures for the deve-
lopment of networks & communities, pgs. 110, ICST, Brussels, Belgium,
Belgium, 2008. ICST (Institute for Computer Sciences, Social-Informatics
and Telecommunications Engineering).
[56] D. Waiting, R. Good, R. Spiers y N. Ventura: The UCT IMS client. En

5th International Conference on Testbeds and Research Infrastructures
for the Development of Networks & Communities and Workshops, 2009.
TridentCom 2009., pgs. 16, Washington, DC, Abr. 2009.
[57] D. Winer: XML-RPC Specification. Informe tcnico., Ene. 1999. http:

//www.xmlrpc.com/spec/index.html.
[58] L. Wu y A. H. Aasgaard: Migration of VOIP/SIP Enterprise Solutions

towards IMS. Tesis de Maestra, Agder University College, May 2006.
[59] F. Yao: OpenIMS and Interoperability with Asterisk/Sip Express VOIP

Enterprise Solutions. Tesis de Maestra, Agder University College, May
2007.
100
Apndice A
Instalacin de la Maqueta
IMS
A.1. Dominios IMS

Los dominios IMS se componen del ncleo IMS implementado con la herra-
mienta OpenIMS Core elaborado por FOKUS. Estos dominios forman el cora-
zn de la maqueta, ya que son quienes controlan las sesiones y flujos entre los
usuarios. La instalacin de los dominios requiere bajar el cdigo fuente de la
herramienta y compilarlo. La instalacin y configuracin de los dominios fueron
probados exitosamente sobre las versiones 6.06 y 8.04 de Ubuntu.
Para instalar los dominios IMS se puede apoyar en el manual electrnico
encontrado en la pgina http://www.openimscore.org/installation_guide
o bien el documento [34] que describe como construir la maqueta partiendo desde
cero.
Suponiendo que se logr instalar el dominio IMS exitosamente, es necesario
hacer una ligera modificacin al script que inicializa el HSS. Con su editor de
texto favorito abra el archivo /opt/OpenIMSCore/FHoSS/deploy/startup.sh.
Se necesita inicializar la variable CLASSPATH con el cdigo mostrado en el Cua-
dro A.1 y cambiar la ltima lnea de cdigo a la que muestra abajo:
java -cp $CLASSPATH de.fhg.fokus.hss.main.HSSContainer $1 $2 $3 $4 $5 $6 $7 $8 $9
101
A.1. Dominios IMS Apndice A. Instalacin de la Maqueta IMS
1 CLASSPATH ="/ usr/share/java/log4j.jar:/opt/OpenIMSCore/FHoSS/bin /:/ usr/

share/tomcat5 .5/ server/lib/tomcat -util.jar:/opt/OpenIMSCore/FHoSS/
tomcat/lib/commons -logging.jar:lib/xml -apis.jar:lib/xercesImpl.jar
:lib/xerces -2.4.0. jar:lib/xalan -2.4.0. jar:lib/tomcat -util.jar:lib/
tomcat -http.jar:lib/tomcat -coyote.jar:lib/struts.jar:lib/servlets -
default.jar:lib/servlet -api.jar:lib/naming -resources.jar:lib/
naming -factory.jar:lib/mysql -connector -java -3.1.12 - bin.jar:lib/
mx4j -3.0.1. jar:lib/log4j.jar:lib/junit.jar:lib/junitee.jar:lib/jta
.jar:lib/jsp -api.jar:lib/jmx.jar:lib/jdp.jar:lib/jasper -runtime.
jar:lib/jasper -compiler -jdt.jar:lib/jasper -compiler.jar:lib/
hibernate3.jar:lib/FHoSS.jar:lib/ehcache -1.1. jar:lib/dom4j -1.6.1.
jar:lib/commons -validator.jar:lib/commons -modeler.jar:lib/commons -
logging.jar:lib/commons -logging -1.0.4. jar:lib/commons -lang.jar:lib
/commons -fileupload.jar:lib/commons -el.jar:lib/commons -digester.
jar:lib/commons -collections -3.1. jar:lib/commons -beanutils.jar:lib/
cglib -2.1.3. jar:lib/catalina -optional.jar:lib/catalina.jar:lib/
c3p0 -0.9.1. jar:lib/base64.jar:lib/asm.jar:lib/asm -attrs.jar:lib/
antlr -2.7.6. jar"
Cuadro A.1: Inicializacin de la Variable CLASSPATH Usado por HSS
Para probar el funcionamiento correcto de cada uno de los dominios es ne-

cesario ejecutar cuatro procesos desde distintas terminales en el mismo sistema
como el usuario root. Los procesos a ejecutar son los siguientes:
/opt/OpenIMSCore/fhoss.sh
/opt/OpenIMSCore/icscf.sh
/opt/OpenIMSCore/pcscf.sh
/opt/OpenIMSCore/scscf.sh
El funcionamiento correcto del dominio se ver reflejado en la informacin

que despliegan estos procesos al momento de comunicarse entre s. Tambin
se podr hace uso de una herramienta web en el puerto 8080. El Cuadro A.2
muestra los puertos que utilizan las funciones del dominio IMS. Es importante
mencionar que los dominios IMS ya cuentan con usuarios de prueba llamados
sip:alice@DOMINIO y sip:bob@DOMINIO con las contraseas alice y bob res-
pectivamente.
102
A.2. Gateway PSTN Apndice A. Instalacin de la Maqueta IMS
Funcin Nmero de Puerto Ocupado

P-CSCF 4060
I-CSCF 5060
S-CSCF 6060
HSS (Diameter) 3868, 3869, 3870, 8080
Cuadro A.2: Puertos Usados por los Dominios IMS
A.2. Gateway PSTN

El Gateway PSTN se compone por un servidor Asterisk y una tarjeta de
Interconexin de Componente Perifrico (Peripheral Component Interconnect:
PCI) capaz de llenar la brecha entre el mundo digital y analgico. El funciona-
miento correcto de este AS requiere la instalacin y configuracin del hardware
y software que lo componen. Adems es necesario realizar unas pequeas mo-
dificaciones al cdigo fuente de Asterisk, lo cual obliga la compilacin tanto de
los drivers, como del mismo Asterisk. Se recomienda abordar esta Seccin con
un conocimiento bsico para compilar e instalar aplicaciones en linux a partir
de su cdigo fuente.
A.2.1. Hardware: Tarjeta Digium

Las especificaciones mnimas con las cuales debe contar la tarjeta es una
interfaz PCI, un puerto de Oficina de Intercambio Forneo (Foreign eXchange
Office: FXO), y compatibilidad garantizada con Asterisk. La tarjeta con la que
se cuenta en el Laboratorio de Redes Avanzadas es Digium Wildcard TDM400P
con tres puertos FXO y un puerto de Estacin de Intercambio Forneo (Foreign
eXchange Station: FXS) para un telfono analgico. Los puertos FXO adiciona-
les proporcionan la capacidad de aumentar la conectividad de Asterisk a otras
redes telefnicas.
Antes que nada es de vital importancia hacer dos cables que sirvan para
conectar la tarjeta Digium con puertos RJ45 al cableado PSTN con conectores
RJ11. La manera ms sencilla de hacer esto es modificando un cable Ethernet
estndar de tal manera que un extremo se convierte en el conector RJ11. Lo
nico de lo que se tiene que tener cuidad es asegurarse de que al momento de
juntar el cable con un cable telefnico es que el par de cables azules del cable
RJ45 se conecte a los cables rojo y verde como se muestra en la Figura A.1.
103
A.2.1. Hardware: Tarjeta Digium Apndice A. Instalacin de la Maqueta IMS
Figura A.1: Cableado para RJ45 a RJ11
La instalacin de la tarjeta consiste en compilar los drivers y herramientas

con los cuales el sistema operativo pueda hacer uso del nuevo hardware. Los
pasos descritos a continuacin se realizaron sobre Ubuntu 6.06; la instalacin
y configuracin para otra versin de Linux son similares. Primero es necesario
actualizar el kernel a la versin ms reciente que se encuentra el los repositorios
del manejador de paquetes. Despus se van a instalar los encabezados y el cdigo
fuente del kernel ya que los drivers requieren de dicha informacin para su
compilacin exitosa. El siguiente comando se encarga de instalar los encabezados
y el cdigo fuente:
apt-get install linux-source linux-headers-ùname -r`
Se van a descargar tres archivos comprimidos que contienen los drivers y

herramientas requeridos por el sistema operativo para controlar la tarjeta. Las
versiones ms recientes la momento de escribir este documento se encuentran
en las siguientes direcciones:
http://downloads.asterisk.org/pub/telephony/dahdi-linux/
dahdi-linux-current.tar.gz
http://downloads.asterisk.org/pub/telephony/dahdi-tools/
dahdi-tools-current.tar.gz
http://downloads.asterisk.org/pub/telephony/libpri/libpri-
1.4-current.tar.gz
Despus de descargar los archivos se deben descomprimir, compilar e instalar

en el sistema operativo. Gracias a que la instalacin de la herramienta dahdi-
tools detecta correctamente la tarjeta utilizada se puede hacer ms eficiente el
driver al comentar todas las lneas del archivo /etc/dahdi/modules excepto la
lnea que dice wctdm. A pesar de que los drivers ya quedaron instalados es mejor
configurarlos despus de instalar Asterisk para garantizar su funcionamiento
correcto.
104
A.2.2. Software: Asterisk Apndice A. Instalacin de la Maqueta IMS
A.2.2. Software: Asterisk

Primero es necesario bajar el cdigo fuente de Asterisk de la direc-
cin http://downloads.digium.com/pub/asterisk/releases/asterisk-
1.4.22.tar.gz. Despus de descomprimir el archivo y antes de compilar es
necesario hacer una pequea modificacin al cdigo para habilitar el inter-
cambio de llamadas con OpenIMS Core. Esta modificacin no es la ptima,
pero funciona. Se deben comentar las lneas 14,085 y 14,090 en el archivo
asterisk-1.4.22/channels/chan_sip.c. El Cuadro A.3 muestra como se
debera ver el bloque de cdigo modificado.
14079 /* Find out what they require */

14080 required = get_header(req , "Require ");
14081 if (! ast_strlen_zero(required)) {
14082 required_profile = parse_sip_options(NULL , required);
14083 if (required_profile && required_profile != SIP_OPT_REPLACES) {
14084 /* At this point we only support REPLACES */
14085 // transmit_response_with_unsupported (p, "420 Bad extension (
unsupported)", req , required);
14086 ast_log(LOG_WARNING ," Received SIP INVITE with unsupported
required extension: %s\n", required);
14087 p->invitestate = INV_COMPLETED;
14088 if (!p->lastinvite)
14089 sip_scheddestroy(p, DEFAULT_TRANS_TIMEOUT );
14090 // return -1;
14091 }
14092 }
Cuadro A.3: Modificacin al Cdigo de Asterisk
Ahora se va compilar el cdigo e instalar Asterisk junto con archivos de con-

figuracin de ejemplo. Para ste proyecto se habilitaron todas las aplicaciones,
codecs, formatos y funciones excepto las que dependen de odbc, speex, jabber,
gtalk, PostgreSQL, radius, sqlite, tds y H.323; ste ltimo se incluye con un m-
dulo adicional debido a unas fallas que presenta el driver default. Para habilitar
H.323 en Asterisk capaz de interactuar con clientes IMS y PSTN es necesario
bajar el driver chan_ooh323 de la direccin http://downloads.digium.com/
pub/asterisk/asterisk-addons-1.4.7.tar.gz.
Con el fin de facilitar la configuracin de Asterisk, se va instalar una inter-
faz web encargado de configurar automticamente la tarjeta Digium, adems de
105
A.2.3. Configuracin Adicional Apndice A. Instalacin de la Maqueta IMS
automatizar el proceso de configuraciones complejas. Despues de instalar exi-

tosamente la interfaz, es posible configurar Asterisk desde la direccin http:
//hebe.ipv6.itam.mx:8088/asterisk/static/config/index.html. La in-
terfaz se descarga con el siguiente comando:
svn checkout http://svn.digium.com/svn/asterisk-gui/branches/2.0

asterisk-gui
Posteriormente es necesario compilar e instalar la interfaz. Por ltimo, es

necesario generar las definiciones de los drivers y reiniciar los servicios de la
tarjeta Digium y Asterisk para que stos se puedan comunicar correctamente.
Esto se logra con las siguientes tres instrucciones:
sudo dahdi_genconf
sudo /etc/init.d/dahdi restart

sudo /etc/init.d/asterisk restart
El funcionamiento correcto del gateway PSTN se puede comprobar reali-

zando llamadas entre sus distintos clientes (SIP, PSTN e IMS). El Cuadro A.4
muestra los puertos que utiliza Asterisk durante su funcionamiento.

Peticiones SIP 5060
Peticiones H.323 1720
Servidor Web 8088
Cuadro A.4: Puertos Usados por Asterisk
A.2.3. Configuracin Adicional

Para terminar de configurar Asterisk a su totalidad se puede consultar [34].
Tambin se puede consultar [36] para obtener un conocimiento profundo acerca
de Asterisk en caso que se desea personalizar su configuracin.
106
A.3. Servidor de Contenidos Apndice A. Instalacin de la Maqueta IMS
A.3. Servidor de Contenidos

Este AS se descompone en DSS para la entrega de contenidos y UCT Advan-
ced IPtv para establecer sesiones SIP. Esta Seccin indica las configuraciones
necesarias para cada elemento.
A.3.1. Darwin Streaming Server

Desde la interfaz web (http://vesta.ipv6.itam.mx:1220) se crean tres
listas de reproduccin (playlists) que ciclan infinitamente simulando canales de
televisin tradicionales. La Figura A.2 muestra un ejemplo de la configuracin.
Figura A.2: Configuracin de la Lista de Reproduccin
A.3.2. UCT IPTV Streaming Server

La configuracin presentada a continuacin funciona para Ubuntu 8.04
en adelante. La instalacin consiste en bajar el archivo deb de la direc-
cin http://prdownload.berlios.de/uctimsclient/uctiptv_advanced1.
0.0.deb e instalarlo ya sea con la ayuda del comando gdebi o dpkg. Despues se
tienen que relacionar las listas de reproduccin creadas en la Seccin A.3.1 con
SIP-URIs que servirn para acceder a los canales va sesiones SIP. Los cambios
se realizan en el archivo /usr/share/uctiptv_advanced/key_value_file. El
Cuadro A.5 muestra un ejemplo del formato que deber seguir cada elemento
nuevo dentro del archivo de configuracin.
107
A.4. Servidor de Presencia Apndice A. Instalacin de la Maqueta IMS
1 <key -value_pair >

2 <key >channel1 </key >
3 <value >rtsp :// vesta.ipv6.itam.mx/channel1.sdp </value >
4 </key -value_pair >
Cuadro A.5: Traduccin de SIP-URI a RTP
El componente UCT IPTV Streaming Server del AS es disponible va men-

sajes SIP en el puerto 8010. Cada vez que se quiera usar este AS es necesario
correr el siguiente comando como root desde la terminal:
uctiptv_as /usr/share/uctiptv_advanced/key_value_file
A.4. Servidor de Presencia

El AS que implementa la funcionalidad del Servidor de Presencia se cons-
truye a partir de la integracin de tres herramientas: OpenSIPS, OpenSIPS-
mi-proxy y OpenXCAP. Cada una de estas se instalan de maneras distintas y
requieren una ligera modificacin para su integracin deseada. La instalacin
y configuracin de los componentes descritos en esta Seccin fueron probadas
exitosamente sobre Ubuntu 8.04. La instalacin y configuracin no funcionan
sobre versiones anteriores de Ubuntu. Existe la posibilidad de que los pasos de-
tallados a continuacin no sean necesarios en futuras versiones. Sin embargo,
puede usarse como marco de referencia al momento de detectar anomalas en el
funcionamiento de estos componentes.
Es importante mencionar que este AS se instal en un servidor que ya conta-
ba con un dominio IMS, por lo tanto la configuracin de los servidores listados en
esta Seccin no utilizan los puertos originales debido a que ya estaban ocupados
por el dominio. Las direcciones IP y nombres usados pertenecen a la maqueta
del Laboratorio de Redes Avanzadas, cualquier modificacin en la reproduccin
de esta maqueta requerir cambiar los nombres y direcciones IP de la misma.
A.4.1. OpenSIPS
Al momento de escribir este trabajo se descargaron todos los paque-
tes disponibles en la direccin http://opensips.org/pub/opensips/1.4.4/
108
A.4.1. OpenSIPS Apndice A. Instalacin de la Maqueta IMS
packages/debian/stable/ (versiones ms recientes se encuentran en la di-

reccin http://opensips.org/pub/opensips/latest/packages/debian/).
Despues se instalaron los paquetes con la herramienta gdebi con el fin de ins-
talar automticamente las dependencias. Los mdulos que requiere OpenSIPS
dentro de la maqueta para su funcionamiento correcto en la maqueta son: jab-
ber, mysql, presence, radius, xmlrpc y xmpp. Si se desea agregar funcionalidad
adicional se pueden instalar los dems paquetes.
Se le tiene que indicar a OpenSIPS el nombre de la base de datos donde
almacena su informacin. Adems se le debe configurar el usuario que tiene
acceso a ella, as como su contrasea. Esto se logra al reemplazar cuatro lneas en
el archivo /etc/opensips/opensipsctlrc. El Cuadro A.6 muestra los cambios
necesarios.
Valor Original Valor Nuevo
# DBENGINE=MYSQL DBENGINE=MYSQL
# DBNAME=opensips DBNAME=xcap
# DBRWUSER=opensips DBRWUSER=xcapAdmin
# DBRWPW=opensipsrw DBRWPW=xcap
Cuadro A.6: Sustitucin de Valores en el Archivo opensipsctlrc
El siguiente paso consiste en crear la base de datos con la informacin propor-

cionada arriba y agregar los cuatro usuarios que se crearon por default cuando
se crearon los dominios IMS. Esto se hace con cinco simples instrucciones mos-
tradas en el Cuadro A.7
1 opensipsdbctl create
2 opensipsctl add alice@astrea.ipv6.itam.mx alice
3 opensipsctl add bob@astrea.ipv6.itam.mx bob
4 opensipsctl add alice@titania.ipv6.itam.mx alice
5 opensipsctl add bob@titania.ipv6.itam.mx bob
Cuadro A.7: Construccin de la BD Usado por OpenSIPS
Despues se tiene que configurar las polticas de ruteo dentro de OpenSIPS

para que ste pueda realizar las funciones de RLS. Para hacer esto se le tiene que
indicar el puerto en el que va a escuchar las peticiones, su direccin IP, los mdu-
los que necesita cargar en memoria y finalmente las reglas con las que interpreta
109
A.4.2. OpenSIPS-mi-proxy Apndice A. Instalacin de la Maqueta IMS
las peticiones. Esta configuracin es bastante compleja y se puede consultar a de-

talle en la direccin http://www.opensips.org/Resources/Documentation.
Se recomienda comenzar con el archivo de configuracin localizado en la direc-
cin http://openxcap.org/wiki/Installation y modificar de acuerdo a sus
necesidades.
Finalmente se requiere modificar el archivo /etc/default/opensips para
indicarle a OpenSIPS que ya esta configurado. Esto se hace cambiando el valor
de la variable RUN_OPENSIPS a yes. Para correr este componente del XDMS
basta con ejecutar el comando opensips. Adicionalmente si se desea iniciar au-
tomticamente el servicio al momento de prender el sistema operativo se requiere
de una ltima modificacin en el archivo /etc/init.d/opensips, agregando
unas instrucciones al final de la funcin check_fork como se muestra en el
Cuadro A.8 entre las lneas 7 y 10:
1 check_fork ()
2 {
3 if grep -q "^[[: space :]]* fork [[: space :]]*=[[: space :]]* no.*" /etc/
opensips/opensips.cfg; then
4 echo "Not starting $DESC: fork=no specified in config file; run /
etc/init.d/opensips debug instead"
5 exit 1
6 fi
7 if test ! -d $HOMEDIR ; then
8 mkdir $HOMEDIR
9 chown -R ${USER }:${GROUP} $HOMEDIR
10 fi
11 }
Cuadro A.8: Modificacin para que OpenSIPS Inicie Automticamente
A.4.2. OpenSIPS-mi-proxy
Este componente reemplaza un mdulo defectouso de OpenSIPS. Su insta-
lacin consiste en agregar un repositorio al manejador de paquetes del sistema
operativo, agregar la firma digital del proveedor e instalar. Primero se debern
agregar las siguientes dos lneas en el archivo /etc/apt/sources.list:
deb http://ag-projects.com/debian unstable main
110
A.4.3. OpenXCAP Apndice A. Instalacin de la Maqueta IMS
deb-src http://ag-projects.com/debian unstable main
Posteriormente se baja la firma digital y se almacena junto con las firmas

vlidas del manejador de paquetes. El Cuadro A.9 muestra como realizar esta
operacin e instalar openSIPS-mi-proxy.
1 wget http :// download.ag -projects.com/agp -debian -gpg.key

2 apt -key add agp -debian -gpg.key
3 apt -get update
4 apt -get install opensips -mi -proxy
Cuadro A.9: Instalacin de OpenSIPS-mi-proxy
Este servicio se inicia cada vez que se prende el servidor. Para garantizar
la comunicacin entre OpenSIPS-mi-proxy y OpenXCAP se requiere modificar
el archivo de configuracin agregando la siguiente lnea al final del documento
/etc/opensips-mi-proxy/config.ini:
listen_url=http://148.205.208.108:8888
A.4.3. OpenXCAP
Debido a que OpenXCAP requiere de versiones ms recientes de algunas
bibliotecas con las que cuenta el manejador de paquetes de Ubuntu 8.04, es
necesario obligar el manejador a realizar la instalacin aunque ste no quiera.
Para esto primero se deshabilita el repositorio agregado en la Seccin A.4.2 para
instalar las dependencias. Esto se logra comentando las dos lneas agregadas en
el archivo /etc/apt/sources.list, seguido por las instrucciones marcadas en
el Cuadro A.10
1 sudo -s
2 apt -get update
3 apt -get install python python -central python -lxml python -zopeinterface
python -twisted -core python -twisted -web python -twisted -web2 python
-application python -gnutls python -sqlobject python -support python -
xml python -mysqldb
Cuadro A.10: Prerequisitos para Instalar OpenXCAP
111
A.5. Servidores de Aplicaciones Apndice A. Instalacin de la Maqueta IMS
Ahora se baja el cdigo fuente de OpenXCAP y se instala en el siste-

ma. No se instala del manejador de paquetes porque ste genera conflictos y
rompe la integridad del sistema. El cdigo fuente se encuentra en la direc-
cin http://download.ag-projects.com/XCAP/ como un archivo comprimi-
do (openxcap_VERSIN.tar.gz). Despues de compilar e instalar OpenXCAP es
importante copiar los archivos de configuracin con los siguientes dos comandos:
sudo cp config.ini.sample /etc/openxcap/config.ini

sudo cp debian/openxcap.init /etc/init.d/opensips
Para que OpenXCAP funcione correctamente bajo la versin del sis-

tema operativo con el que se esta trabajando se requiere modificar
el cdigo fuente instalado. Esto se logra comentando la lnea 48 del
archivo /usr/bin/openxcap que dice start_log() y la lnea 44 del
archivo /usr/lib/python2.5/site-packages/xcap/element.py que dice
sys.exit(1). Con estas modificaciones OpenXCAP ya puede funcionar, sin
embargo falta configurarlo. Primero se requiere instalar la herramienta openssl
para generar firmas y certificados digitales. Los campos de los certificados de-
penden de su organizacin.
Finalmente se tiene que configurar OpenXCAP para que pueda
interactuar con OpenSIPS. Se modifican unas lneas en el archivo
/etc/openxcap/config.ini cambiandolas por las que se muestran en el Cua-
dro A.11
Para tener un cliente que puede actualizar correctamente los PIDFs den-
tro de la maqueta es necesario volver a habilitar los repositorios aadidos en
la Seccin A.4.2 e instalar el cliente xcapclient. El funcionamiento correcto del
Servidor de Presencia se puede apreciar al momento actualizar los PIDFs con
el cliente instalado, y con las actualizaciones en los estatus de presencia al mo-
mento de correr el cliente UCT IMS Client. Finalmente la Cuadro A.12 muestra
los puertos que utiliza el Servidor de Presencia durante su funcionamiento. Es
importante mencionar que el puerto 8888 solo es usado entre los mdulos Open-
SIPS y OpenXCAP, y no deberan ser utilizados directamente por los clientes.
A.5. Servidores de Aplicaciones

Esta Seccin representa la etapa de cohesin que permite incorporar todos
los mdulos descritos previamente en la lgica y funcionamiento del dominio
112
A.5. Servidores de Aplicaciones Apndice A. Instalacin de la Maqueta IMS
1 [Server]
2 root = https :// presence.astrea.ipv6.itam.mx/xcap -root@titania.ipv6.
itam.mx/
3 root = https :// presence.astrea.ipv6.itam.mx/xcap -root@astrea.ipv6.itam
.mx/
4 root = https :// presence.astrea.ipv6.itam.mx/xcap -root/
5 default_realm = astrea.ipv6.itam.mx
6
7 [Authentication]
8 authentication_db_uri = mysql :// xcapAdmin:xcap@localhost/xcap
9
10 [Database]
11 storage_db_uri = mysql :// xcapAdmin:xcap@localhost/xcap
12
13 [OpenSIPS]
14 xmlrpc_url = http :// presence.astrea.ipv6.itam.mx :8888/ RPC2/
Cuadro A.11: Integracin de OpenXCAP y OpenSIPS

Peticiones XCAP (HTTPS) 443
Peticiones XML-RPC 8888
Peticiones SIP 5065
Cuadro A.12: Puertos Usados por el Servidor de Presencia
IMS. Es importante mencionar que los cambios descritos en esta Seccin son
necesarios por cada dominio IMS con la que cuenta la maqueta. La agregacin
de los AS en el funcionamiento de IMS es bastante sencillo y consta de cuatro
pasos:
1. Agregar el AS a los registros del HSS.

2. Agregar un Trigger Point dentro de los registros del HSS. ste define un
patrn que permite el S-CSCF detectar la solicitud del servicio dentro de
los encabezados de mensajes SIP predefinidos. El tipo de mensaje y el
patrn que identifica la solicitud dependen del funcionamiento lgico del
AS.
3. Unir el paso 1 y 2 con un iFC, permitiendo definir la ruta y el trato que
113
A.5.1. Presencia Apndice A. Instalacin de la Maqueta IMS
recibe el mensaje SIP hacia el AS.

4. Agregar el iFC a un Perfil de Servicio. ste Perfil permite administrar
los servicios que tienen registrados los usuarios, de tal modo que los ser-
vicios son habilitados para los usuarios que cuentan con dicho perfil y
deshabilitados para aquellos que no cuentan con l.
A.5.1. Presencia
Gracias a que la instalacin default de OpenIMS Core viene preconfigurado
con un AS de ejemplo, basta con modificarlo para agregar el primer AS a la
maqueta IMS. La primer modificacin al AS preconfigurado consiste en cambiar
las propiedades del servidor por las que posee el AS de presencia configurado en
la Seccin A.4. Se debe cambiar la direccin IP, el puerto y el nombre del AS
registrado en el men Services -> Application Servers. La segunda modificacin
consiste en actualizar el Trigger Point del AS para que coincida con los valores
mostrados en el Cuadro A.13.
Seccin Campo Valor

SIP Method PUBLISH
Trigger Point 1
SIP Method SUBSCRIBE
SIP Header Event
Trigger Point 2
SIP Header Content .*presence.*
Cuadro A.13: Valores del Trigger Point para el AS de Presencia
A.5.2. IPTV
Ahora, en vez de modificar las propiedades de un AS, stas se van a crear.
Lo bueno es que la creacin consiste en seleccionar la opcin Create del men, y
posee la misma complejidad que el ejemplo mostrado previamente. Primero se
va crear un AS con los valores del AS, esto es: direccin IP, puerto y nombre.
Posteriormente se va crear un Trigger Point con los valores que muestran el
Cuadro A.14. Finalmente se necesita crear un iFC uniendo la informacin creada
en estos pasos. La creacin del iFC consiste nicamente de asignarle un nombre
nico y definir el estatus de los usuarios que pueden tener acceso al servicio.
114
A.5.3. Gateway PSTN Apndice A. Instalacin de la Maqueta IMS
Seccin Campo Valor

Trigger Point 1 SIP Method INVITE
SIP Header To
Trigger Point 2
SIP Header Content .*iptv.astrea.ipv6.itam.mx.*
Cuadro A.14: Valores del Trigger Point para el Servidor de Contenidos
A.5.3. Gateway PSTN

Como ya se habr notado, lo nico que cambia al momento de agregar un
AS en la funcionalidad de un dominio IMS es la ubicacin del servidor en la red
(llmese direccin IP y puerto) y el Trigger Point que se define cuando se activa
dicha servicio. Para crear el AS del gateway PSTN dentro de los dominios IMS
se debe crear con la direccin IP que ste posee y el puerto por donde recibe
peticiones SIP (ver Cuadro A.4). Luego se crea el Trigger Point con los valores
que muestra el Cuadro A.15. Finalmente se crea el iFC como se hizo con los dos
ejemplos anteriores.
Seccin Campo Valor

SIP Method INVITE
Trigger Point 1
SIP Method INFO
SIP Header To
Trigger Point 2
SIP Header Content .*hebe.ipv6.itam.mx.*
Cuadro A.15: Valores del Trigger Point para el Gateway PSTN
A.5.4. Perfil de Servicio

Como paso final es necesario agregar los iFCs de cada uno de los AS creados
al Perfil de Servicio al cual estn registrados los usuarios IMS. Esto se logra
accesando la opcin Services -> Service Profiles y agregando los iFCs creados
en las secciones anteriores. Tambin es necesario asignarle una prioridad a los
distintos servicios dentro de los dominios accesando la opcin Services -> Shared
iFC Sets.
115
Apndice B
Ejecucin de los Servicios

LBS
Esta Seccin detalla brevemente como hacer uso de los servicios LBS desa-
rrollados en este trabajo de tesis.
B.1. Sailfin
Se desarroll el AS como un proyecto SIP con la ayuda de Netbeans. Existen
dos maneras de iniciar el servicio, el primero de ellos consiste en registrar e iniciar
el proyecto en Sailfin con la ayuda de las herramientas grficas de Netbeans.
El segundo consiste en eleminar el overhead adicional ocasionado por el uso de
Netbeans.
Para iniciar y terminar los servicios LBS desde la terminal se necesita sa-
ber el directorio donde radica la informacin del dominio, la cual puede ser
consultada en las propiedades del servidor desde Netbeans. La inicializacin y
terminacin de los servicios se realiza ejecutando el comando asadmin localizado
en el directorio /usr/local/sailfin/bin/ con los siguientes parmetros:
asadmin start-domain --domaindir DirectorioDomino NombreDominio
asadmin stop-domain --domaindir DirectorioDomino NombreDominio
116
B.2. UCT IMS Client Apndice B. Ejecucin de los Servicios LBS
El valor de las variables DirectorioDominio y NombreDominio usadas en

este trabajo de tesis fueron /home/alton y .sailfinDomain respectivamente.
B.2. UCT IMS Client

Para habilitar la recepcin del contenido multimedia de los servicios LBS se
necesita modificar el cdigo fuente del cliente. Dichas modificaciones se realizan
en el archivo ims_exosip_event_handler.c. Primero se incluye una condicin
que prueba si el SDP tiene una SIP-URI de redireccionamiento en el ltimo
mensaje OK recibido. Se agregan las lneas 829 a 833 y 848 como se muestra en
el Cuadro B.1.
817 void ims_process_ack(eXosip_event_t *je)

818 {
819
820 Call *ca;
821 sdp_message_t *remote_sdp;
822
823 if (find_call(je ->did , &ca) < 0)
824 return ;
825
826 /* Extract information from message */
827 message_extract_call_info(ca , je ->ack);
828
829 if (ca ->content_indirected)
830 {
831 }
832 else
833 {
834 sprintf(display , "ACK Received\n\nCall established with :\n %s
< %s>", ca ->from_name , ca ->from_uri);
835 set_display(display);
836 state = IN_CALL;
837 start_rtp_session(je);
838 }
Cuadro B.1: Primera Modificacin al Cdigo del Cliente
Ahora se agrega el procedimiento interno que establece la sesin RTP. El

cdigo mostrado en el Cuadro B.2 indica el cdigo que se debe colocar dentro
del caso verdadero de la condicin creada en el Cuadro B.1.
117
B.3. P-CSCF Apndice B. Ejecucin de los Servicios LBS
1 sprintf(display , "Content indirected to:\n %s\n\n", ca ->

content_indirection_uri );
2 if (strstr(ca ->content_indirection_uri , "rtsp :"))
3 {
4 strcat(display , "Attempting to open RTSP stream ...\n");
5 printf (" Attempting to open RTSP stream ...\n");
6 rtsp_start_session(ca ->content_indirection_uri );
7 sprintf(display , "200 OK Received\n\nRTSP session
established with :\n< %s>", ca -> content_indirection_uri )
;
8 set_display(display);
9 state = IN_CALL;
10 /* Destroy any existing pipeline */
11 if (GST_IS_ELEMENT(ca ->ringingPipeline))
12 destroyRingingPipeline(ca);
13 }
Cuadro B.2: Segunda Modificacin al Cdigo del Cliente
B.3. P-CSCF
Para habilitar la entrada de los mensajes PUBLISH generados por SIPp al
dominio IMS es necesario agregar unas lneas en el archivo de configuracin
/opt/OpenIMSCore/pcscf.cfg. Las lneas 519 a 524 mostradas en el Cua-
dro B.3 son las que se tienen que aadir al archivo de configuracin para permitir
la entrada de dichos mensajes.
515 route[Orig_Standalone]
516 {
517 log(1,">> Orig_Standalone\n");
518
519 #modificacion para aceptar actualizaciones de localizacin
520 if (method == "PUBLISH" && !P_is_registered () && !
P_assert_identity ())
521 {
522 P_enforce_service_routes ();
523 break;
524 }
Cuadro B.3: Modificacin a la Configuracin del P-CSCF
118
B.4. SIPp Apndice B. Ejecucin de los Servicios LBS
B.4. SIPp
Se desarroll un script, con el nombre simulacion_movimiento.sh, que
obtiene todas las variables necesarias para personalizar la configuracin de SIPp.
El script recibe como parmetro nicamente el usuario registrado en el cliente
UCT. Dicho script se puede apreciar en el Cuadro B.4.
1 #!/ bin/bash
2 PUERTO=`sudo netstat -tunap | grep uctimsclient | awk '{print $4}' |
sed 's/0.0.0.0:// ' `
3 if [[ $PUERTO = "" ]];
4 then
5 echo "No esta corriendo uctimsclient. Necesita estar corriendo y
estar registrado a un Dominio IMS"
6 exit
7 fi
8 if [[ $1 = "" ]];
9 then
10 echo "Se necesita especificar un usuario"
11 exit
12 else
13 USUARIO=$1
14 fi
15 DOMINIO=ècho $USUARIO | sed 's/.*@//'`
16 NOTIFICACIONES=`wc -l $USUARIO.csv | awk '{print $1}'`
17 sipp -sf publish.xml pcscf.$DOMINIO :4060 -inf $USUARIO.csv -r 1 -rp 5m
-m $NOTIFICACIONES -i ìfconfig eth0 | awk '/inet addr/ {split (
$2 ,A ,":"); print A[2]}'` -p èxpr $PUERTO + 49152 `
Cuadro B.4: Script Usado para Iniciar SIPp
El script requiere de dos archivos adicionales. El primero de ellos contiene los

campos con los cuales se construye el mensaje SIP. El nombre del archivo debe
seguir el patrn Usuario@Dominio.csv. Cada rengln debe seguir el formato
mostrado en el Cuadro B.5.
Formato Ejemplo
usuario;dominio;latitud;longitud; alice;astrea.ipv6.itam.mx;19.344585,-99.199812;
Cuadro B.5: Formato del CSV con Coordenadas
119
B.4. SIPp Apndice B. Ejecucin de los Servicios LBS
El segundo archivo adicional define el escenario con el que se simula la gene-

racin de mensajes SIP intercambiados con el AS. Hace uso del primer archivo
para construir los campos [fieldX]. Su contenido XML se puede apreciar en el
Cuadro B.6.

2 <scenario name =" Simulacion Movimiento">
3 <send >
4 <![CDATA[
5 PUBLISH sip:lbs.[ field1] SIP /2.0
6 Via: SIP /2.0/ UDP [local_ip ]:[ local_port -49152]; rport;branch =[
branch]
7 Route: <sip:orig@scscf .[ field1 ]:6060;lr >
8 From: <sip:[ field0]@[field1]>;tag=[ call_number]
9 To: <sip:[ field0]@[field1]>
10 Call -ID: [call_id]
11 Cseq: 1 PUBLISH
12 Content -Type: application/xml+location
13 Max -Forwards: 70
14 User -Agent: UCT IMS Client
15 Content -Disposition: render;handling=required
16 Expires: 3600
17 Event: location
18 Content -Length: [len]
19
21 <location xmlns:xsi=" http :// www.w3.org /2001/ XMLSchema -instance"
xsi:noNamespaceSchemaLocation =" http :// lbs.titania.ipv6.itam.
mx :8145/ LBS_AS/location.xsd">
22 <latitude >[ field2]</latitude >
23 <longitude >[ field3 ]</longitude >
24 </location >
25 ]]>
26 </send >
27 <recv response ="200"/ >
28 </scenario >
Cuadro B.6: Mensajes PUBLISH generados por SIPp
120
Glosario
3G Tercera Generacin de Telefona Celular. 18
3GPP Third Generation Partnership Project. 2, 3, 18, 25, 28

3GPP2 Third Generation Partnership Project 2. 18
4G Cuarta Generacin de Telefona Celular. 4
AAA Autenticacin, Autorizacin y Contabilizacin (Authentication, Autho-

rization and Accounting). 20, 26, 29
AP Access Point (AP). 32
AS Servidor de Aplicacion (Application Server). 35, 7, 19, 20, 2224, 3234,

36, 38, 4042, 44, 48, 50, 51, 5457, 5968, 7084, 88, 89, 91, 93, 103, 107,
108, 113116, 120
CAPEX Gastos de Capital (Capital Expenditure). 16, 17

CSCF Call/Service Control Function. 1922, 38, 63, 91, 122124
CSV Valores Separados por Comas (Comma Separated Values). 78
DBAO Objeto de Aceso Directo a la Base de Datos (Data Base Access Object).
73, 74
DSS Darwin Streaming Server. 41, 42, 45, 82, 107
121
Glosario Glosario
DTMF Sistema de Marcacin va Tono Doble de Multiple Frecuencia (Dual-

Tone Multi-Frequency). 39, 44, 48, 49, 68
FOKUS Fraunhofer Institute for Open Communications Systems. 4, 5, 38, 44,

87, 89, 101
FOSS Software Libre y Abierto (Free and Open Source Software). 4, 5, 7, 37,
42, 44, 45, 66, 67, 92
FXO Oficina de Intercambio Forneo (Foreign eXchange Office). 103
FXS Estacin de Intercambio Forneo (Foreign eXchange Station). 103
GPS Sistema de Posicionamiento Global (Global Positioning System). 31
HSS Home Subscriber Server. 1922, 24, 38, 59, 101, 113
HTTP HyperText Transfer Protocol. 26, 35, 43, 45, 51, 74, 76, 77, 88, 92
HTTPS HyperText Transfer Protocolover SSL. 35, 51, 88, 92
I-CSCF Interrogating-CSCF; ver CSCF. 21, 22, 38

IETF Internet Engineering Task Force. 3, 18, 25, 26, 2830
iFC Criterio de Filtrado Inicial (Initial Filter Criteria). 24, 42, 7981, 113115
IMS IP Multimedia Subsystem. 19, 1315, 1730, 32, 33, 3644, 4649, 51,
5356, 59, 6368, 70, 7982, 8793, 101, 102, 105, 106, 108, 109, 113115,
118
IP Protocolo de Internet (Internet Protocol). 13, 5, 10, 11, 1315, 19, 21, 22,
2530, 50, 108, 109, 114, 115, 122
IPSec Internet Protocol Security. 21, 30
IPTV Televisin va IP (IP Television), ver IP. 41, 45, 80
IPv4 Protocolo de Internet versin 4 (Internet Protocol v4); ver IP. 26
IPv6 Protocolo de Internet versin 6 (Internet Protocol v6); ver IP. 3, 25, 26,
50, 89, 93
122
Glosario Glosario
ISDN Red Digital de Servicios Integrados (Integrated Services Digital Net-

work). 14, 48, 49, 124
ISP Proveedor de Servicio de Internet (Internet Service Provider). 911, 48
ITAM Instituto Tecnolgico Autnomo de Mxico. 5, 6, 37, 39, 40, 49, 83, 87,
93
ITU Unin Internacional de Telecomunicaciones (International Telecommuni-

cations Union). 11, 30
IVR Respuesta de Voz Interactivo (Interactive Voice Response). 52
LBS Servicios Basados en Localizacin (Location Based Services). 59, 30, 31,
33, 43, 5355, 58, 59, 6268, 70, 72, 75, 76, 79, 8183, 87, 9094, 116, 117
MGCF Media Gateway Control Function. 19
MGW Media Gateway. 19

MSRP Message Session Relay Protocol. 51, 93
NASS Network Attachment Subsystem. 12, 13
NAT Traduccin de Direcciones de Red (Network Address Translation). 7, 26
NGN Redes de Siguiente Generacin (Next Generation Networks). 1, 2, 46,

8, 9, 1114, 17, 18, 30, 33, 87
OMA Open Mobile Alliance (OMA). 17, 18
OPEX Gastos de Operacin (Operational Expenditure). 16, 17

OSI Interconexin de Sistemas Abiertos (Open Systems Interconnection Refe-
rence Model). 5
P-CSCF Proxy-CSCF; ver CSCF. 21, 28, 38, 49, 50, 79
PBX Central Telefnica (Private Branch eXchange). 39, 68
123
Glosario Glosario
PCI Interconexin de Componente Perifrico (Peripheral Component Intercon-

nect). 103
PDF Policy Decision Function. 21
PES PSTN/ISDN Emulation and Simulation; ver PSTN y ISDN. 13
PIDF Formato de Documentos de Presencia (Presence Information Data For-
mat). 3335, 43, 44, 51, 59, 61, 66, 77, 88, 92, 112
PSTN Red Telefnica Tradicional (Public Switched Telephone Network). 1, 3,
5, 14, 19, 23, 28, 37, 39, 40, 44, 48, 49, 52, 89, 92, 103, 105, 106, 115, 124
QoE Calidad de Experiencia (Quality of Experience). 4, 10, 14, 18, 23, 45, 46,
54, 55, 60, 87, 93
QoS Calidad de Servicio (Quality of Service). 25, 10, 11, 14, 18, 21, 29, 30
RACS Resource and Administration Control Subsystem. 12, 13

RFC Request for Comments. 28
RLS Resouce List Server. 3436, 4345, 51, 109
RTCP Real-Time Transport Control Protocol. 3, 30, 41
RTP Real-Time Transport Protocol. 3, 20, 26, 30, 41, 42, 58, 72, 82, 84, 91,
92, 117
S-CSCF Serving-CSCF; ver CSCF. 21, 22, 24, 29, 3840, 49, 50, 89, 113
SDP Protocolo de Descripcin de Sesin (Session Description Protocol). 22, 29,
67, 69, 70, 72, 82, 117
SIP Protocolo de Inicializacin de Sesin (Session Initiation Protocol). 3, 6, 7,
14, 2023, 26, 2830, 35, 36, 3941, 4345, 4750, 5558, 60, 6568, 70, 72,
74, 75, 78, 8082, 84, 92, 106108, 113116, 119, 120
SIP-URI Session Initiation Protocol Universal Resource Identifier. 23, 24, 27,
28, 41, 42, 44, 48, 49, 71, 78, 80, 84, 89, 107, 117
SLF Service Location Function. 21
124
Glosario Glosario
SMS Mensaje Corto (Short Message Service). 31, 55

SOAP Protocolo Sencillo de Aceso a Objetos (Simple Object Access Protocol).
43
SS7 Sistema de Sealizacin 7 (Signalling System 7). 39, 49
SSL Secure Socket Layer. 30
TEL-URI Telephone Universal Resource Identifier. 23, 89

THIG Topology Hiding Internetwork Gateway. 22
TLS Transport Layer Security. 28, 30
TTM Tiempo de Lanzamiento al Mercado (Time to Market). 17
UCT Universidad de Cape Town. 5, 44, 51, 6668, 70, 78, 81, 82, 87, 88, 9092,
119
UE Equipo Terminal del Usuario (User Equipment). 4, 6, 7, 12, 13, 20, 21, 23,
24, 2935, 39, 46, 47, 49, 50, 53, 55, 56, 78
URI Identificador de Recurso Universal (Universal Resource Identifier). 27
VoD Video en Demanda (Video on Demand). 41, 45

VoIP Voz sobre IP (Voice over IP). 6, 7, 26, 39
WPS Wireless Positioning System (WPS). 32
XCAP eXtensible Markup Language (XML) Configuration Access Protocol.

34, 35, 43, 51, 59, 78, 125
XDMS XML Document Manager Server. 3335, 4244, 51, 59, 61, 66, 88, 89,
110
XML eXtensible Markup Language. 34, 35, 59, 61, 7678, 88, 120, 125
XML-RPC Ejecucin de Procedimiento Remoto XML (XML Remote Proce-
dure Call) ver XML y XCAP. 43
XSD Definicin Esquema de XML (XML Schema Definition). 34, 61, 62, 76,
77, 88
125

Tesis MacDonald PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tesis MacDonald PDF

Caricato da

Copyright:

Formati disponibili

INSTITUTO TECNOLGICO AUTNOMO DE MXICO

Servicios Personalizados de Multimedia Ofrecidos Sobre

ALTON KENNETH MACDONALD HERNNDEZ

MXICO, D.F. 2009

Alton Kenneth MacDonald Hernndez

Quiero agradecer la ayuda que me proporcion mi asesor, el Mto. Rodolfo

La convergencia digital se vuelve cada da ms importante tanto para los

2.3.3.6. Servidores de Aplicaciones . . . . . . . . . . . 22

3. Construccin de la Maqueta IMS 37

3.8.2. Telefona Celular Mvil . . . . . . . . . . . . . . . . . . 49

4. Diseo de LBS Personalizados 53

6. Conclusiones y Lneas Futuras 87

A. Instalacin de la Maqueta IMS 101

B. Ejecucin de los Servicios LBS 116

2.1. Arquitectura NGN . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1. Ncleo IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1. Mensajes SIP Generados por el Gua Virtual . . . . . . . . . . . 57

5.1. Primera Modificacin al Diseo . . . . . . . . . . . . . . . . . . 69

5.6. Visualizacin de los Destinos Tursticos y Usuarios . . . . . . . 75

A.1. Cableado para RJ45 a RJ11 . . . . . . . . . . . . . . . . . . . . 104

2.1. Cdigos de Estado SIP . . . . . . . . . . . . . . . . . . . . . . . 27

3.1. Funcionalidades Ofrecidas Bajo Esquema PSTN/ISDN . . . . . 49

4.1. Actualizaciones de las Coordenadas Geogrficas . . . . . . . . . 63

5.1. Trigger Points Definidos para el Servidor de Contenidos . . . . 80

A.1. Inicializacin de la Variable CLASSPATH Usado por HSS . . . 102

A.13.Valores del Trigger Point para el AS de Presencia . . . . . . . . 114

B.1. Primera Modificacin al Cdigo del Cliente . . . . . . . . . . . . 117

Este Captulo expone la situacin actual de los operadores ante la migracin

La creciente demanda de servicios bajo contextos hasta hace poco impensa-

tre usuarios, pero su maduracin ha adoptado cuatro objetivos principales: (1)

componen la plataforma. La creacin de servicios se convierte en la tarea de

al pblico hacia un operador que ha invertido en IMS, se requiere ofrecer ser-

1.5. Trabajos Relacionados

La segunda requiere de un convenio entre la empresa y el operador donde la

1.6. Organizacin del Documento

Captulo 6: Conclusiones, resultados y trabajo futuro. Se presentan puntos

Apndice B: Detalla de los cambios requeridos por el dominio IMS y el

Este Captulo presenta un bosquejo de Redes de Siguiente Generacin (Next

2.1. Redes de Siguiente Generacin

2.1.2. Arquitectura NGN

Figura 2.1: Arquitectura NGN [29]

2.1.2.1. Plano de Transporte

las configuraciones del UE junto con la asignacin dinmica y reservacin de

2.1.2.2. Plano de Servicio

SIP) tener acceso a servicios de la Red Telefnica Tradicional (Public Switched

2.1.3. Transicin Hacia NGN

Paso 1 Convergencia: Tener la habilidad de ofrecer cualquier tipo de ser-

2.2. Modelos de Entrega de Servicio

Figura 2.2: Modelo Vertical (Sndrome Silo) [11]

silos comparten la misma informacin. Esta redundancia de informacin, ade-

Figura 2.3: Modelo Horizontal (Plataforma de Entrega de Servicios) [18]

2.3. IP Multimedia Subsystem

2.3.1. Orgenes de IMS

2.3.2. Arquitectura IMS

de las funciones que ofrece IMS son:

Figura 2.4: Arquitectura IMS [19]

4. Funciones de pasarela (gateway) hacia PSTN, como hacia otras redes.

5. Funciones para controlar, procesar y transportar multimedia. stas no se

1. Transporte de multimedia, que se logra con la ayuda de distintos protoco-

2. Sealizacin entre las funciones y el UE que permite establecer una sesin

3. Autenticacin, Autorizacin y Contabilizacin (Authentication, Authori-

2.3.3. Componentes IMS

2.3.3.1. Repositorios de Informacin