Tesis MacDonald

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 titulada Servicios Personalizados de Multimedia Ofrecidos Sobre la Plataforma IP Multimedia Subsystem, otorgo de manera gratuita y permanente 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 conocerlas 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 haberme 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 mejorar 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 describe el diseo e implementacin de servicios LBS usando los bloques de servicio proporcionados por la maqueta.
ndice general
1. Introduccin 1.1. Antecedentes . . . . . . . . . 1.2. Objetivo . . . . . . . . . . . . 1.3. Alcance . . . . . . . . . . . . 1.4. Justificacin . . . . . . . . . . 1.5. Trabajos Relacionados . . . . 1.6. Organizacin del Documento . 1 1 5 5 5 6 8 9 9 11 12 12 13 14 15 17 18 18 20 20 21 21 22 22
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
2. Marco Conceptual 2.1. Redes de Siguiente Generacin . . . . . . . . 2.1.1. Definicin . . . . . . . . . . . . . . . 2.1.2. Arquitectura NGN . . . . . . . . . . 2.1.2.1. Plano de Transporte . . . . 2.1.2.2. Plano de Servicio . . . . . 2.1.3. Transicin Hacia NGN . . . . . . . . 2.2. Modelos de Entrega de Servicio . . . . . . . 2.3. IP Multimedia Subsystem . . . . . . . . . . 2.3.1. Orgenes de IMS . . . . . . . . . . . 2.3.2. Arquitectura IMS . . . . . . . . . . . 2.3.3. Componentes IMS . . . . . . . . . . 2.3.3.1. Repositorios de Informacin 2.3.3.2. CSCF . . . . . . . . . . . . 2.3.3.3. P-CSCF . . . . . . . . . . 2.3.3.4. I-CSCF . . . . . . . . . . . 2.3.3.5. S-CSCF . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
vi
NDICE GENERAL
NDICE GENERAL
2.3.3.6. Servidores de Aplicaciones . . . . 2.3.4. Usuarios dentro de IMS . . . . . . . . . . . 2.3.4.1. Identificacin Pblica de Usuario . 2.3.4.2. Identificacin Privada de Usuario . 2.3.4.3. Perfil de Servicio . . . . . . . . . . 2.3.5. Tarificacin . . . . . . . . . . . . . . . . . . 2.3.5.1. Tarificacin Fuera de Lnea . . . . 2.3.5.2. Tarificacin En Lnea . . . . . . . 2.3.5.3. Tarificacin Basada en Flujos . . . 2.3.6. Tecnologas y Protocolos Usados . . . . . . 2.3.6.1. IPv6 . . . . . . . . . . . . . . . . 2.3.6.2. SIP . . . . . . . . . . . . . . . . . 2.3.6.3. Session Description Protocol . . . 2.3.6.4. Diameter . . . . . . . . . . . . . . 2.3.6.5. RTP/RTCP y H.323 . . . . . . . 2.3.6.6. IPSec y TLS . . . . . . . . . . . . 2.4. Servicios Basados en Localizacin . . . . . . . . . . 2.4.1. Mtodos de Localizacin . . . . . . . . . . . 2.4.1.1. GPS . . . . . . . . . . . . . . . . . 2.4.1.2. Asistida Va Red Celular . . . . . 2.4.1.3. Asistida Va Puntos de Acceso . . 2.4.2. Presencia . . . . . . . . . . . . . . . . . . . 2.4.3. XDMS . . . . . . . . . . . . . . . . . . . . . 2.4.4. Documento de Presencia . . . . . . . . . . . 2.4.5. XCAP . . . . . . . . . . . . . . . . . . . . . 2.4.6. RLS . . . . . . . . . . . . . . . . . . . . . . 3. Construccin de la Maqueta IMS 3.1. Objetivos y Requerimientos . . . 3.2. Dominios IMS . . . . . . . . . . . 3.3. Gateway PSTN . . . . . . . . . . 3.4. Servidor de Contenidos . . . . . . 3.5. Servidor de Presencia . . . . . . . 3.6. Clientes IMS . . . . . . . . . . . 3.7. Topologa Fsica . . . . . . . . . 3.8. Evaluacin de la Maqueta . . . . 3.8.1. Telefona Tradicional . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
22 23 23 23 24 24 24 25 25 25 25 26 29 29 30 30 30 31 31 31 32 32 33 34 35 35 37 37 38 39 41 42 44 45 48 48
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
vii
NDICE GENERAL
NDICE GENERAL
3.8.2. Telefona Celular Mvil . . . . . . . . . . . . . . . . . . 3.8.3. Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Diseo de LBS Personalizados 4.1. Introduccin . . . . . . . . . . . 4.2. Gua Virtual . . . . . . . . . . 4.2.1. Diseo de Alto Nivel . . 4.2.2. Flujo de Mensajes SIP . 4.3. Cartelera Personalizada . . . . 4.3.1. Diseo de Alto Nivel . . 4.3.2. Flujo de Mensajes SIP . 4.3.3. Archivos XML y XSD . 4.4. Clculo de Distancia en Metros 4.5. Actualizaciones de Localizacin 4.6. Modelo de Negocio . . . . . . .
49 50 53 53 54 55 56 58 59 60 61 62 62 63 65 65 67 68 70 72 73 74 75 76 76 77 78 79 79 80 81 81 82 83 84
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
5. LBS Personalizados 5.1. Herramientas Utilizadas . . . . . . . . . . 5.2. Modificaciones al Diseo . . . . . . . . . . 5.2.1. Mtodo REFER . . . . . . . . . . 5.2.2. Mtodo UPDATE . . . . . . . . . 5.3. Implementacin del AS para Servicios LBS 5.3.1. Interaccin con la Base de Datos . 5.3.2. Contenedor HTTP . . . . . . . . . 5.3.3. Contenedor SIP . . . . . . . . . . . 5.3.4. Procesamiento de XML . . . . . . 5.3.5. Construccin de la Cartelera . . . . 5.3.6. Consultas XCAP . . . . . . . . . . 5.4. Notificaciones de Localizacin . . . . . . . 5.5. Cambios a los Dominios . . . . . . . . . . 5.5.1. Configuracin del P-CSCF . . . . . 5.5.2. iFC para IPTV . . . . . . . . . . . 5.5.3. iFC para LBS . . . . . . . . . . . . 5.6. Cambios al Cliente . . . . . . . . . . . . . 5.7. Escenario de Pruebas . . . . . . . . . . . . 5.8. Destinos e Itinerarios . . . . . . . . . . . . 5.9. Visualizacin del Funcionamiento . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
viii
NDICE GENERAL
NDICE GENERAL
6. Conclusiones y Lneas Futuras 6.1. Acerca de la Maqueta IMS . . . . . 6.2. Acerca de los Servicios LBS . . . . 6.3. Desarrollo de un Cliente IMS Mvil 6.4. Conclusiones Finales . . . . . . . . 6.5. Lneas Futuras . . . . . . . . . . . 7. Referencias Bibliogrficas Apndices
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
87 87 90 91 92 93 95
A. Instalacin de la Maqueta IMS A.1. Dominios IMS . . . . . . . . . . . . . A.2. Gateway PSTN . . . . . . . . . . . . A.2.1. Hardware: Tarjeta Digium . . A.2.2. Software: Asterisk . . . . . . A.2.3. Configuracin Adicional . . . A.3. Servidor de Contenidos . . . . . . . . A.3.1. Darwin Streaming Server . . A.3.2. UCT IPTV Streaming Server A.4. Servidor de Presencia . . . . . . . . . A.4.1. OpenSIPS . . . . . . . . . . . A.4.2. OpenSIPS-mi-proxy . . . . . A.4.3. OpenXCAP . . . . . . . . . . A.5. Servidores de Aplicaciones . . . . . . A.5.1. Presencia . . . . . . . . . . . A.5.2. IPTV . . . . . . . . . . . . . A.5.3. Gateway PSTN . . . . . . . . A.5.4. Perfil de Servicio . . . . . . . B. Ejecucin de los Servicios LBS B.1. Sailfin . . . . . . . . . . . . . B.2. UCT IMS Client . . . . . . . B.3. P-CSCF . . . . . . . . . . . . B.4. SIPp . . . . . . . . . . . . . . Glosario
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
101 101 103 103 105 106 107 107 107 108 108 110 111 112 114 114 115 115 116 116 117 118 119 121
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
ix
ndice de figuras
2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 4.1. 4.2. 4.3. 4.4. 5.1. 5.2. 5.3. 5.4. 5.5. Arquitectura NGN . . . . . . . . . . . . . . . . . . . . . . Modelo Vertical (Sndrome Silo) . . . . . . . . . . . . . . . Modelo Horizontal (Plataforma de Entrega de Servicios) . Arquitectura IMS . . . . . . . . . . . . . . . . . . . . . . . Formato de Mensaje SIP . . . . . . . . . . . . . . . . . . . Localizacin Relativa Usando la Sectorizacin de Antenas Servidor de Presencia . . . . . . . . . . . . . . . . . . . . . Ncleo IMS . . . . . . . . . . . . . . Diseo del Gateway PSTN . . . . . . Diseo del Servidor de Contenidos . Diseo de XDMS . . . . . . . . . . . Topologa Fsica de la Maqueta IMS Entrega de Contenido . . . . . . . . Curiosidades del Servicio de Roaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 16 17 19 27 32 33 38 41 42 43 45 47 50 57 60 61 63 69 71 72 73 74
Mensajes SIP Generados por el Gua Virtual . . . . . . . . . . . Mensajes Generados por la Cartelera Personalizada . . . . . . . PIDF de los Gneros Preferidos . . . . . . . . . . . . . . . . . . Definicin XSD del Formato de las Actualizaciones de Localizacin Primera Modificacin al Diseo . . . . Diseo Final de los LBS Personalizados Terminacin del Contenido LBS . . . . Base de Datos Usado por el AS . . . . Interaccin con la Base de Datos . . . x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NDICE DE FIGURAS
NDICE DE FIGURAS
5.6. Visualizacin de los Destinos Tursticos y Usuarios 5.7. Generacin de Notificaciones de Localizacin . . . . 5.8. Rutas que Recorren los Usuarios . . . . . . . . . . 5.9. Entrega del Servicio al Usuario 1 . . . . . . . . . . 5.10. Entrega del Servicio al Usuario 2 . . . . . . . . . . 5.11. Entrega del Servicio a los Usuarios 3 y 4 . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
75 79 84 85 85 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 . . . . . . . . . . . . . . . . . . . . . . . 2.2. Mtodos SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Ejemplo de Documento de Presencia . . . . . . . . . . . . . . . 3.1. Funcionalidades Ofrecidas Bajo Esquema PSTN/ISDN . . . . . 3.2. Funcionalidades Ofrecidas Bajo Esquema de Telefona Celular Mvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3. Funcionalidades Ofrecidas Bajo Esquema Internet . . . . . . . . 4.1. Actualizaciones de las Coordenadas Geogrficas . . . . . . . . . 5.1. Trigger Points Definidos para el Servidor de Contenidos . . . . 5.2. Trigger Points Definidos para los Servicios LBS Personalizados . A.1. Inicializacin de la Variable CLASSPATH Usado por HSS A.2. Puertos Usados por los Dominios IMS . . . . . . . . . . . A.3. Modificacin al Cdigo de Asterisk . . . . . . . . . . . . . A.4. Puertos Usados por Asterisk . . . . . . . . . . . . . . . . . A.5. Traduccin de SIP-URI a RTP . . . . . . . . . . . . . . . A.6. Sustitucin de Valores en el Archivo opensipsctlrc . . . . A.7. Construccin de la BD Usado por OpenSIPS . . . . . . . . A.8. Modificacin para que OpenSIPS Inicie Automticamente A.9. Instalacin de OpenSIPS-mi-proxy . . . . . . . . . . . . . A.10.Prerequisitos para Instalar OpenXCAP . . . . . . . . . . . A.11.Integracin de OpenXCAP y OpenSIPS . . . . . . . . . . A.12.Puertos Usados por el Servidor de Presencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 28 34 49 50 51 63 80 81 102 103 105 106 108 109 109 110 111 111 113 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. B.2. B.3. B.4. B.5. B.6. Primera Modificacin al Cdigo del Cliente . Segunda Modificacin al Cdigo del Cliente Modificacin a la Configuracin del P-CSCF Script Usado para Iniciar SIPp . . . . . . . Formato del CSV con Coordenadas . . . . . Mensajes PUBLISH generados por SIPp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 118 118 119 119 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 Telefnicas 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 Protocol: 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 acceso 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 servicio 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 impensables, 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 dispositivos 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 realizacin 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 Generation 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 disponibilidad 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 Partnership 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-
1.1. Antecedentes
tre usuarios, pero su maduracin ha adoptado cuatro objetivos principales: (1) combinar las ltimas tendencias tecnolgicas; (2) lograr el paradigma del internet 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 versin 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 multimedia 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 Aplicaciones (Application Servers: AS), los cuales forman los bloques de servicio que
1.1. Antecedentes
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 localizacin 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 encontrarn 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 (Quality 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 convergencia 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 hacia 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 cantidad de 10.1 mil millones de dlares en la investigacin y desarrollo de IMS [15]. Afortunadamente, instituciones como el Fraunhofer Institute for Open Communications 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.
1.2. Objetivo
1.2.
Objetivo
El objetivo de este trabajo de tesis es desarrollar y ofrecer servicios personalizados 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 como son Open IMS Core elaborado por el Fraunhofer Institute for Open Communications 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 existentes. 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
1.5. Trabajos Relacionados
al pblico hacia un operador que ha invertido en IMS, se requiere ofrecer servicios 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 localizacin 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. Permitir 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 principales diferencias entre la implementacin y el diseo de soluciones empresariales y cmo stas se pueden integrar al funcionamiento de IMS. Mencionan los problemas de interconexin y compatibilidad al momento de que las soluciones empresariales hacen uso de la infraestructura de un operador IMS. Se concentran 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 implementan 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.
1.5. Trabajos Relacionados
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 soluciones 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 migracin. 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 Seccin 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 posible 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 Mosmondor [10] publican un artculo acerca de cmo construir un servicio LBS dentro 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.
1.6. Organizacin del Documento
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.
Captulo 2
Marco Conceptual
Este Captulo presenta un bosquejo de Redes de Siguiente Generacin (Next Generation Networks: NGN), IP Multimedia Subsystem (IMS) y Servicios Basados en Localizacin (Location Based Services: LBS), as como los distintos modelos 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 telecomunicaciones: los operadores y los Proveedores de Servicios de Internet (Internet Service Providers: ISPs) [43], cada uno con sus respectivas ventajas y desventajas en la entrega de servicios. Los operadores poseen la infraestructura fsica para ofrecer servicios de telecomunicaciones y la capacidad de garantizar la entrega de servicios. Este grupo se compone por empresas que ofrecen televisin restringida, telefona fija y mvil; sus redes se basan en la conmutacin de circuitos, 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 necesariamente 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 formatos. 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 califica 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 demanda 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
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 permiten 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 telecomunicaciones. 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 Telecommunications 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 restricciones 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 sealizacin 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
2.1.2.
Arquitectura NGN
Como ya se ha mencionado, las redes NGN no poseen una arquitectura fsica 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 interactuar 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 Network 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
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 encargado 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 recursos 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 infraestructura 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 servicios. 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
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 contrario: 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 redes 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 requiere 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
Paso 1 Convergencia: Tener la habilidad de ofrecer cualquier tipo de servicio 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 planean 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
Figura 2.2: Modelo Vertical (Sndrome Silo) [11] silos comparten la misma informacin. Esta redundancia de informacin, adems 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 Expenditure: 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
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 convergencia digital y los elementos que aporta en esta crucial tarea; adems se explica cmo este forma una Plataforma de Entrega de Servicios y las tecnologas en las que se basa para lograrlo.
17
2.3.1. Orgenes de IMS
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 trabajando 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 funcionamiento 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 multimedia; (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
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 servicios 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. Representados 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
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 interconectan 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 protocolos 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, Authorization and Accounting: AAA) que garantiza una comunicacin segura entre el usuario y sus servicios, o bien entre distintas funciones que requieren mtodos sofisticados para asegurar la autenticidad de la sealizacin intercambiada. 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 necesario 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 para realizar AAA; adems contiene informacin acerca de los distintos servicios
20
que tienen habilitados as como el Serving-CSCF (S-CSCF) al que se registraron, 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 redes 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 llamadas 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 comenzar 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 tradicional, se requiere ajustar a las necesidades regulatorias de emergencia (como son llamadas al 911 y servicios de operador) [11]; P-CSCF se encarga de detectar 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 generadas 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; dentro 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 correspondientes [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 consultando 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 comunicacin 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
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 particular 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 componen 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 dominio 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 Identifier (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 sealizacin 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 simultneamente. 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
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 subscripcin, 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 informacin 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 servicio 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
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 dichos flujos de servicio [38]. Este esquema puede ser aprovechado para definir polticas de cobranza especializadas dependiendo del tipo de servicio que consuma el usuario.
2.3.6.
Tecnologas y Protocolos Usados
La construccin de los componentes IMS se realiza con tecnologas abiertas tomadas del mundo del Internet. IETF y 3GPP trabajan en conjunto para mejorar las carencias actuales de estas tecnologas. El uso de los protocolos descritos 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 Translation: 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 enfrentarse 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 transicin 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 protocolo 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 respuestas (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 mtodo 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 encabezados 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 dominio 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 Recurso 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 100 - 199 200 - 299 300 - 399 400 - 499 500 - 599 600 - 699 Estatus Provisional (Informational) Success Redirect Client Error Server Error Global Failure Significado muestra informacin adicional mensaje enviado exitosamente mensaje fue redirigido error generado por parte del cliente error generado por parte del servidor error generado globalmente
Cuadro 2.1: Cdigos de Estado SIP 27
Nombre ACK BYE CANCEL INFO INVITE NOTIFY OPTIONS PRACK PUBLISH REGISTER SUBSCRIBE UPDATE MESSAGE REFER
Significado Notifica la aceptacin de un INVITE Concluye la sesin Cancela una solicitud pendiente Transporta sealizacin PSTN Establece una sesin Notifica acerca de eventos ocurridos Solicita las capacidades del servidor Notifica la aceptacin de un Response provisional Sube informacin al servidor Realiza el mapeo entre el SIP-URI y una direccin IP Solicita ser notificado acerca de eventos Modifica alguna caracterstica de las sesiones Contiene un mensaje de texto 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 modificaciones 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 enrutar los mensajes SIP 2.3.6.3. Session Description Protocol
SDP [7, 24] es un protocolo a nivel de aplicacin encargado de describir sesiones de multimedia [38]. Incluye toda la informacin necesaria para establecer una sesin entre UEs, como son las capacidades de los dispositivos, los protocolos 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 repeticiones 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, puertos 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
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 referencia 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 operadores. 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 Localizacin (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 personalizados dependiendo de sus actividades sociales y laborales.
30
2.4.1. Mtodos de Localizacin
Un ejemplo prctico e ilustrativo de un LBS es el concepto de un StickyNote 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 ofrecer 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 Positioning System: GPS), (3) apoyndose en las redes de acceso o (4) una combinacin 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 estaciones 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 funcionamiento 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]. Desarrollado 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
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 localizacin del usuario [26]. Obviamente se requiere conocer previamente la localizacin de los Puntos de Acceso (Access Points: APs). stos generalmente estn registrados 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]. Dicha 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 donde los usuarios notifican a los dems su estado de disponibilidad con el fin de
32
2.4.3. XDMS
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 adems 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 informacin 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
es implementado como un AS que soporta XML Configuration Access Protocol (XCAP) y Resouce List Server (RLS). La Figura 2.7 muestra la relacin existente 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 eXtensible 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 Formato 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. Estos 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 informacin que contienen [14]. Los PIDF definen tres principales atributos de las presentidades:
1 2 3 4 5 6 7 8 9 10 <?xml version ="1.0" encoding ="UTF -8"?> <presence xmlns ="urn:ietf:params:xml:ns:pidf" entity =" pres:alice@astrea.ipv6.itam.mx"> <tuple id=" abc123"> <status > <basic >open </basic > </status > <contact priority ="0.8" > tel :+525556284000 </ contact > </tuple > </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
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 masivas y genricas de informacin: XML Configuration Access Protocol (XCAP). XCAP [40, 42] hace uso de XML para almacenar los datos en el servidor de presencia 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 monitoreo 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 presentidades 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 usuarios [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 pueden 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
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 Autnomo de Mxico (ITAM) con el fin de proporcionar los bloques de servicio de telecomunicaciones bsicos sobre los cuales se apoyan los servicios personalizados 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 interdominio, (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 dominios 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 realizar 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 intradominio. Habilitar dichos servicios se hace posible con la inclusin de los Repositorios de Informacin y las funciones del CSCF (ver Seccin 2.3.3). El Fraunhofer 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 conectando 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
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 software) al momento de ofrecer soluciones empresariales de VoIP. Yao se enfoca en analizar los problemas de compatibilidad originados en distintos UEs al momento 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
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 parmetros 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 encuentra la posibilidad de contar con una operadora virtual, buzn de voz, llamadas 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 dentro 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 operador de telefona digital que puede comunicarse con los dominios IMS usando los protocolos SIP y H.323.
40
3.4. Servidor de Contenidos
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 ofrecer 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
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 diferentes. 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) almacenar 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 herramientas permite la construccin de un XDMS capaz de ofrecer servicios de 42
3.5. Servidor de Presencia
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 encargado de garantizar una comunicacin exitosa entre RLS y XCAP. Su funcin es actuar como proxy habilitando a OpenSIPS la funcionalidad de manejar datos 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
2. Utilizar OpenSIPS-mi-proxy y OpenXCAP para comunicarse directamente 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 usuarios. 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 nicamente 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 funcionalidades. 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 servicios 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 configuracin 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
Servicios de Presencia: Habilidad de administrar documentos va HTTP, generar y recibir eventos SIP enviados al RLS, y permite consultar informacin 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 Avanzadas 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
3.7. Topologa Fsica
multimedia de manera satisfactoria en Caronte ocasionado por el cuello de botella 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 comunicacin 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
3.7. Topologa Fsica
(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 intercambiar 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 mismo 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
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 Avanzadas 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 permite visualizar de manera inmediata cmo se compara la maqueta IMS contra los operadores de telefona tradicional y celular mvil y contra los servicios de terceros 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 funcionalidades 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 mltiples 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
PSTN Video Llamadas 1:1 Intra-Dominio Video Llamadas 1:1 Inter-Dominio Video Llamadas 1:N Intra-Dominio Video Llamadas 1:N Inter-Dominio Gateway PSTN DTMF Sealizacin y Multimedia Independientes
IMS (Release 7) SI SI SI SI SI SI SI
Maqueta IMS SI SI NO NO SI 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 S49
3.8.3. Internet
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 Seccin 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 Roaming Push To Talk over Cellular Mensajera Instantnea (1:1) Modo Pager Mensajera Instantnea (1:N) Modo Pager IMS (Release 7) SI SI SI SI Maqueta IMS NO NO 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
3.8.3. Internet
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 Mensajera Instantnea Mensajera Instantnea Mensajera Instantnea Mensajera Instantnea IPTV VoD IPv4 IPv6 RLS XCAP/XDMS QoS (1:1) Modo Sesin (1:N) Modo Sesin (1:1) Modo Pager (1:N) Modo Pager IMS (Release 7) SI SI SI SI SI SI SI SI SI SI SI Maqueta IMS SI NO SI NO SI SI SI NO SI 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 funcionalidad y robustecer la entrega de mensajes de sesin. La maqueta IMS adems provee ciertas funcionalidades que no pueden catalogarse dentro de los rubros anteriores. Con la ayuda de Asterisk la maqueta
51
3.8.3. Internet
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 funcionalidad 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 telecomunicaciones los convierten en candidatos ideales para ofrecer servicios novedosos al usuario final. Bajo este contexto, los usuarios descritos en este Captulo pertenecen 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 dependencia 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 telecomunicaciones que proporciona la maqueta IMS para probar la factibilidad de desarrollar servicios usando la metodologa propuesta por IMS. Esto es, la creacin 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 permiten aadir un mayor nivel de personalizacin en los servicios dependiendo de la localizacin del usuario. En resumen, los servicios desarrollados ofrecen contenido 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
en dichos destinos; por ejemplo, es mejor visto entablar una conversacin telefnica 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
Gracias a que el servicio funciona nicamente con notificaciones, la inicializacin 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 servicio. 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 transferencia. 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 Streaming 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
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
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 preferencias 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. Ahora 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 polticas 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 documentos 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 necesarias 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 gustan 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 funcionalidad 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
La Figura 4.2 ilustra la secuencia de mensajes intercambiados por los componentes 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 preferencias 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. rad(x) = x 180 (4.1)
distP re = sin rad(latU E) sin rad(latDest) + cos rad(latU E) cos rad(latDest) cos rad(longU E + longDest) distancia = arc cos distP re 180 111189.577
(4.2)
(4.3)
4.5.
Actualizaciones de Localizacin
La Figura 4.4 muestra una visualizacin del archivo XSD definiendo el formato 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
Figura 4.4: Definicin XSD del Formato de las Actualizaciones de Localizacin

1 2 3 4 5 6 <?xml version ="1.0" encoding ="UTF -8"?> <location xmlns:xsi=" http :// www.w3.org /2001/ XMLSchema -instance" xsi: noNamespaceSchemaLocation =" location.xsd"> <placeName >ITAM </ placeName > <latitude >19.344585 </ latitude > <longitude > -99.199812 </ longitude > </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
comparacin con el costo de las sesiones multimedia. Por otro lado, el AS recibe ganancias al cobrarle una renta semanal al turista 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 planeacin 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 consultar 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 herramienta 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 estabilidad 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 generacin de mensajes SIP, permitiendo complementar al cliente UCT con simples archivos de configuracin. 66
5.2. Modificaciones al Diseo
Ericsson recientemente liber al pblico una herramienta llamada Ericsson Service Development Studio (SDS) 4.1 [20], la cual puede ser usada para desarrollar aplicaciones y soluciones IMS. Esta herramienta implementa la pila de protocolos de IMS, permitiendo al desarrollador enfocarse en la lgica del servicio. 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 proporciona 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 adicionales. 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 concepto 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 identificaron dos fallas, relacionadas con el cliente UCT. Dichas fallas radican en el tratamiento de dos mensajes SIP (UPDATE y REFER) que no implementan el estndar 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. Simplemente 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 mtodo 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
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 manera 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 incorporados 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 delegar 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 soportado por el cliente y en teora este mtodo puede ser utilizado para actualizar el
68
5.2.1. Mtodo REFER
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 Contenidos. 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
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 ocasion 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, ocasionando 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 alternativas 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 cliente es mediante una llamada comn y corriente con el mtodo INVITE seguido por los mensajes requeridos para negociar las capacidades de multimedia. Este 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 usuario, 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 determinar 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
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 pa71
5.3. Implementacin del AS para Servicios LBSCaptulo 5. LBS Personalizados
ra establecer una sesin SIP con el Servidor de Contenidos. No se establece 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 Contenidos. 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 ejemplifica 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
5.3.1.
Interaccin con la Base de Datos
Antes que nada, se consider que el AS potencialmente va a manejar la informacin de una cantidad indefinida de localidades (destinos tursticos y/o cines) los cuales poseen distintos tipos de contenidos. Adems, trabajar con una cantidad 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 informacin 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
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 encarga 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 desarrollado 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
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 tursticos. 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 Listener 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
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 correspondiente. 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 sintctico correcto de XML al momento de procesar los mensajes PUBLISH generados 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 disponibles. 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 servicio 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 pe76
5.3.6. Consultas XCAP
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 pelculas construidas con la ayuda de la clase NodoPelicula. cinemexParser: Es una clase que consulta la pgina web de Cinemex y construye 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. Posteriormente 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. Teniendo 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. Dichas 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 documentos 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 Servidor de Presencia, ste tiene que actuar como cliente. En vez de implementar
77
5.4. Notificaciones de Localizacin
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 operativo 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 realizar 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 geogrficas 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 cantidad infinita de archivos CSV con cualquier conjunto de coordenadas geogrficas
78
5.5. Cambios a los Dominios
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 dominio 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 configuracin del P-CSCF, aadindole una excepcin que permite la entrada de dichos mensajes.
79
5.5.2. iFC para IPTV
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 mensajes 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 Contenidos 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 desde 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 identificndolo como tal. El Cuadro 5.1 muestra la nueva configuracin del Trigger Point. Seccin Principal Trigger Point 1 Campo Condition Type CMF SIP Method SIP Header SIP Header Content SIP Header SIP Header Content SIP Header SIP Header Content Valor Disjunctive Normal Format INVITE To .*iptv.titania.ipv6.itam.mx.* From .*lbs.titania.ipv6.itam.mx.* Server lbs.titania.ipv6.itam.mx (Glassfish SIP v1.0.0)
Trigger Point 2
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
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 Principal Trigger Point 1 Campo Condition Type CMF SIP Method SIP Method SIP Header SIP Header Content SIP Header SIP Header Content Valor Conjunctive Normal Format PUBLISH SUBSCRIBE Event location To .*lbs.titania.ipv6.itam.mx.*
Trigger Point 2
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 Seccin 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
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 mensaje 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 construy 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
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, Universidad, 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
(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 entrega 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 sesin 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 ubicar 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 Figura 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 operadores 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 Sndrome 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 personalizados 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 telecomunicaciones 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 entidad para formar un XDMS. Este proceso tuvo sus obstculos que fueron resueltos. 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 funcionamiento 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 permita actualizar sus PIDFs hacia el servidor XDMS. Se propone robustecer su manejo del protocolo HTTP de tal manera que evolucione a soportar 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 mejora 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
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 identidades 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, soportan 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 particular 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
posibilidad de utilizar la maqueta construida en este trabajo de tesis dentro de un ambiente de produccin empresarial. Sin embargo, se considera que las aportaciones 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 exitosamente 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 respeta 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 decisin 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 operaciones 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 especficas a los componentes modulares que provee. La entrega de los contenidos
90
6.3. Desarrollo de un Cliente IMS Mvil tulo 6. Conclusiones y Lneas Futuras Cap
personalizados fue satisfactorio. Incluso en el ambiente de simulacin los servicios son bastante atractivos ya que expone la flexibilidad con la que cuenta IMS al habilitar la entrega de nuevos servicios. Adems, exportar la funcionalidad 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 momento 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 establecidas 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 mejorar 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 sobre 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
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 generacin peridica de mensajes PUBLISH. 4. Contar con una interfaz amigable que pueda activar o desactivar la actualizacin 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 Development Studio (SDS) 4.1 [20], la cual puede ser encontrada en la red gratuitamente.
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 personalizacin, lo cual permite adaptar las herramientas a condiciones a las cuales no fueron diseadas.
92
6.5. 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 Seccin 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 cinematogrfico que desea ver a partir de la cartelera entregada.
93
6.5. Lneas Futuras
9. Desarrollar un cliente mvil que pueda aprovechar todas las funcionalidades de la maqueta y los servicios LBS personalizados.
94
Captulo 7
Referencias Bibliogrficas
[1] 3GPP: IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services; Stage 1. TS 22.173, 3rd Generation 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 Generation 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 Common IP Multimedia Subsystem (IMS). TS 21.202, 3rd Generation Partnership Project (3GPP), May 2008. http://www.3gpp.org/ftp/Specs/htmlinfo/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-ietfmmusic-sdp-capability-negotiation-09, Internet Engineering Task Force, Jul 2008. http://www.ietf.org/internet-drafts/draft-ietfmmusic-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 Composition in IMS: A Location Based Service Example. En Wireless Pervasive 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 Platform: 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. 1999. http://www.rfc-editor.org/rfc/rfc2543.txt. [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) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document 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, International 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 Recommendation H.323, International Telecommunication Union Telecommunications 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 Communications 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.rfceditor.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 Representing Resource Lists. RFC 4826, Internet Engineering Task Force, May 2007. http://www.rfc-editor.org/rfc/rfc4826.txt. [40] J. Rosenberg: The Extensible Markup Language (XML) Configuration Access Protocol (XCAP). RFC 4825, Internet Engineering Task Force, May 2007. http://www.rfc-editor.org/rfc/rfc4825.txt. [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.rfceditor.org/rfc/rfc3261.txt. [42] J. Rosenberg y J. Urpalainen: An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources. Internet-Draft draft-ietf-simple-xcapdiff-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 Potentials. 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 Interworking Requirements. RFC 4123, Internet Engineering Task Force, Jul 2005. http://www.rfc-editor.org/rfc/rfc4123.txt. [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: Presence 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 International Conference on Testbeds and research infrastructures for the development 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 herramienta OpenIMS Core elaborado por FOKUS. Estos dominios forman el corazn 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 Cuadro 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
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 necesario 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 respectivamente.
102
A.2. Gateway PSTN
Funcin P-CSCF I-CSCF S-CSCF HSS (Diameter)
Nmero de Puerto Ocupado 4060 5060 6060 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 funcionamiento correcto de este AS requiere la instalacin y configuracin del hardware y software que lo componen. Adems es necesario realizar unas pequeas modificaciones 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 adicionales 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/libpri1.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 dahditools 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
A.2.2.
Software: Asterisk
Primero es necesario bajar el cdigo fuente de Asterisk de la direccin http://downloads.digium.com/pub/asterisk/releases/asterisk1.4.22.tar.gz. Despus de descomprimir el archivo y antes de compilar es necesario hacer una pequea modificacin al cdigo para habilitar el intercambio 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 14080 14081 14082 14083 14084 14085 14086 14087 14088 14089 14090 14091 14092 /* Find out what they require */ required = get_header(req , "Require "); if (! ast_strlen_zero(required)) { required_profile = parse_sip_options(NULL , required); if (required_profile && required_profile != SIP_OPT_REPLACES) { /* At this point we only support REPLACES */ // transmit_response_with_unsupported (p, "420 Bad extension ( unsupported)", req , required); ast_log(LOG_WARNING ," Received SIP INVITE with unsupported required extension: %s\n", required); p->invitestate = INV_COMPLETED; if (!p->lastinvite) sip_scheddestroy(p, DEFAULT_TRANS_TIMEOUT ); // return -1; } }
Cuadro A.3: Modificacin al Cdigo de Asterisk Ahora se va compilar el cdigo e instalar Asterisk junto con archivos de configuracin 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 mdulo 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 interfaz web encargado de configurar automticamente la tarjeta Digium, adems de 105
A.2.3. Configuracin Adicional
automatizar el proceso de configuraciones complejas. Despues de instalar exitosamente la interfaz, es posible configurar Asterisk desde la direccin http: //hebe.ipv6.itam.mx:8088/asterisk/static/config/index.html. La interfaz 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 realizando llamadas entre sus distintos clientes (SIP, PSTN e IMS). El Cuadro A.4 muestra los puertos que utiliza Asterisk durante su funcionamiento. Funcin Peticiones SIP Peticiones H.323 Servidor Web Nmero de Puerto Ocupado 5060 1720 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
A.3.
Servidor de Contenidos
Este AS se descompone en DSS para la entrega de contenidos y UCT Advanced 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 direccin 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
1 2 3 4
<key -value_pair > <key >channel1 </key > <value >rtsp :// vesta.ipv6.itam.mx/channel1.sdp </value > </key -value_pair >
Cuadro A.5: Traduccin de SIP-URI a RTP El componente UCT IPTV Streaming Server del AS es disponible va mensajes 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 construye a partir de la integracin de tres herramientas: OpenSIPS, OpenSIPSmi-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 detallados 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 contaba 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 paquetes disponibles en la direccin http://opensips.org/pub/opensips/1.4.4/
108
A.4.1. OpenSIPS
packages/debian/stable/ (versiones ms recientes se encuentran en la direccin http://opensips.org/pub/opensips/latest/packages/debian/). Despues se instalaron los paquetes con la herramienta gdebi con el fin de instalar automticamente las dependencias. Los mdulos que requiere OpenSIPS dentro de la maqueta para su funcionamiento correcto en la maqueta son: jabber, 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 # DBENGINE=MYSQL # DBNAME=opensips # DBRWUSER=opensips # DBRWPW=opensipsrw Valor Nuevo DBENGINE=MYSQL DBNAME=xcap DBRWUSER=xcapAdmin 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 proporcionada arriba y agregar los cuatro usuarios que se crearon por default cuando se crearon los dominios IMS. Esto se hace con cinco simples instrucciones mostradas en el Cuadro A.7
1 2 3 4 5 opensipsdbctl create opensipsctl add alice@astrea.ipv6.itam.mx alice opensipsctl add bob@astrea.ipv6.itam.mx bob opensipsctl add alice@titania.ipv6.itam.mx alice 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 mdulos que necesita cargar en memoria y finalmente las reglas con las que interpreta 109
A.4.2. OpenSIPS-mi-proxy
las peticiones. Esta configuracin es bastante compleja y se puede consultar a detalle en la direccin http://www.opensips.org/Resources/Documentation. Se recomienda comenzar con el archivo de configuracin localizado en la direccin 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 automticamente 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 2 3 4 5 6 7 8 9 10 11 check_fork () { if grep -q "^[[: space :]]* fork [[: space :]]*=[[: space :]]* no.*" /etc/ opensips/opensips.cfg; then echo "Not starting $DESC: fork=no specified in config file; run / etc/init.d/opensips debug instead" exit 1 fi if test ! -d $HOMEDIR ; then mkdir $HOMEDIR chown -R ${USER }:${GROUP} $HOMEDIR fi }
Cuadro A.8: Modificacin para que OpenSIPS Inicie Automticamente
A.4.2.
OpenSIPS-mi-proxy
Este componente reemplaza un mdulo defectouso de OpenSIPS. Su instalacin 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
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 2 3 4 wget http :// download.ag -projects.com/agp -debian -gpg.key apt -key add agp -debian -gpg.key apt -get update 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 2 3 sudo -s apt -get update 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
Ahora se baja el cdigo fuente de OpenXCAP y se instala en el sistema. No se instala del manejador de paquetes porque ste genera conflictos y rompe la integridad del sistema. El cdigo fuente se encuentra en la direccin http://download.ag-projects.com/XCAP/ como un archivo comprimido (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 sistema 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 dependen 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 Cuadro A.11 Para tener un cliente que puede actualizar correctamente los PIDFs dentro 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 momento 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 OpenSIPS 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
1 2 3 4 5 6 7 8 9 10 11 12 13 14
[Server] root = https :// presence.astrea.ipv6.itam.mx/xcap -root@titania.ipv6. itam.mx/ root = https :// presence.astrea.ipv6.itam.mx/xcap -root@astrea.ipv6.itam .mx/ root = https :// presence.astrea.ipv6.itam.mx/xcap -root/ default_realm = astrea.ipv6.itam.mx [Authentication] authentication_db_uri = mysql :// xcapAdmin:xcap@localhost/xcap [Database] storage_db_uri = mysql :// xcapAdmin:xcap@localhost/xcap [OpenSIPS] xmlrpc_url = http :// presence.astrea.ipv6.itam.mx :8888/ RPC2/
Cuadro A.11: Integracin de OpenXCAP y OpenSIPS Funcin Peticiones XCAP (HTTPS) Peticiones XML-RPC Peticiones SIP Nmero de Puerto Ocupado 443 8888 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
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 servicios 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 Principal Trigger Point 1 Trigger Point 2 Campo Condition Type CMF SIP Method SIP Method SIP Header SIP Header Content Valor Conjunctive Normal Format PUBLISH SUBSCRIBE Event .*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
Seccin Principal Trigger Point 1 Trigger Point 2
Campo Condition Type CMF SIP Method SIP Header SIP Header Content
Valor Conjunctive Normal Format INVITE To .*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 Principal Trigger Point 1 Trigger Point 2 Campo Condition Type CMF SIP Method SIP Method SIP Header SIP Header Content Valor Conjunctive Normal Format INVITE INFO To .*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 desarrollados 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 saber 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 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 void ims_process_ack(eXosip_event_t *je) { Call *ca; sdp_message_t *remote_sdp; if (find_call(je ->did , &ca) < 0) return ; /* Extract information from message */ message_extract_call_info(ca , je ->ack); if (ca ->content_indirected) { } else { sprintf(display , "ACK Received\n\nCall established with :\n %s < %s>", ca ->from_name , ca ->from_uri); set_display(display); state = IN_CALL; start_rtp_session(je); }
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
1 2 3 4 5 6 7
8 9 10 11 12 13
sprintf(display , "Content indirected to:\n %s\n\n", ca -> content_indirection_uri ); if (strstr(ca ->content_indirection_uri , "rtsp :")) { strcat(display , "Attempting to open RTSP stream ...\n"); printf (" Attempting to open RTSP stream ...\n"); rtsp_start_session(ca ->content_indirection_uri ); sprintf(display , "200 OK Received\n\nRTSP session established with :\n< %s>", ca -> content_indirection_uri ) ; set_display(display); state = IN_CALL; /* Destroy any existing pipeline */ if (GST_IS_ELEMENT(ca ->ringingPipeline)) destroyRingingPipeline(ca); }
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 Cuadro B.3 son las que se tienen que aadir al archivo de configuracin para permitir la entrada de dichos mensajes.
515 516 517 518 519 520 521 522 523 524 route[Orig_Standalone] { log(1,">>
Orig_Standalone\n");
#modificacion para aceptar actualizaciones de localizacin if (method == "PUBLISH" && !P_is_registered () && ! P_assert_identity ()) { P_enforce_service_routes (); break; }
Cuadro B.3: Modificacin a la Configuracin del P-CSCF
118
B.4. SIPp
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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 #!/ bin/bash PUERTO=`sudo netstat -tunap | grep uctimsclient | awk '{print $4}' | sed 's/0.0.0.0:// ' ` if [[ $PUERTO = "" ]]; then echo "No esta corriendo uctimsclient. Necesita estar corriendo y estar registrado a un Dominio IMS" exit fi if [[ $1 = "" ]]; then echo "Se necesita especificar un usuario" exit else USUARIO=$1 fi DOMINIO=ècho $USUARIO | sed 's/.*@//'` NOTIFICACIONES=`wc -l $USUARIO.csv | awk '{print $1}'` 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 usuario;dominio;latitud;longitud; Ejemplo alice;astrea.ipv6.itam.mx;19.344585,-99.199812;
Cuadro B.5: Formato del CSV con Coordenadas
119
B.4. SIPp
El segundo archivo adicional define el escenario con el que se simula la generacin 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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 <?xml version ="1.0" encoding ="UTF -8"?> <scenario name =" Simulacion Movimiento"> <send > <![CDATA[ PUBLISH sip:lbs.[ field1] SIP /2.0 Via: SIP /2.0/ UDP [local_ip ]:[ local_port -49152]; rport;branch =[ branch] Route: <sip:orig@scscf .[ field1 ]:6060;lr > From: <sip:[ field0]@[field1]>;tag=[ call_number] To: <sip:[ field0]@[field1]> Call -ID: [call_id] Cseq: 1 PUBLISH Content -Type: application/xml+location Max -Forwards: 70 User -Agent: UCT IMS Client Content -Disposition: render;handling=required Expires: 3600 Event: location Content -Length: [len] <?xml version ="1.0" encoding ="UTF -8"?> <location xmlns:xsi=" http :// www.w3.org /2001/ XMLSchema -instance" xsi:noNamespaceSchemaLocation =" http :// lbs.titania.ipv6.itam. mx :8145/ LBS_AS/location.xsd"> <latitude >[ field2]</latitude > <longitude >[ field3 ]</longitude > </location > ]]> </send > <recv response ="200"/ > </scenario >
22 23 24 25 26 27 28
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, Authorization 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 (DualTone 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 Network). 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 Telecommunications 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 Reference 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 Interconnect). 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 Format). 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 Procedure Call) ver XML y XCAP. 43 XSD Definicin Esquema de XML (XML Schema Definition). 34, 61, 62, 76, 77, 88
125

Tesis MacDonald

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tesis MacDonald

Transféré par

Droits d'auteur :

Formats disponibles

INSTITUTO TECNOLGICO AUTNOMO DE MXICO

Servicios Personalizados de Multimedia Ofrecidos Sobre la Plataforma IP Multimedia Subsystem

Alton Kenneth MacDonald Hernndez

1.5. Trabajos Relacionados

1.5. Trabajos Relacionados

1.6. Organizacin del Documento

Organizacin del Documento

Redes de Siguiente Generacin

2.1. Redes de Siguiente Generacin

Captulo 2. Marco Conceptual

Captulo 2. Marco Conceptual

2.1.2. Arquitectura NGN

Captulo 2. Marco Conceptual

Figura 2.1: Arquitectura NGN [29]

2.1.2. Arquitectura NGN

Captulo 2. Marco Conceptual

2.1.3. Transicin Hacia NGN

Captulo 2. Marco Conceptual

Transicin Hacia NGN

2.2. Modelos de Entrega de Servicio

Captulo 2. Marco Conceptual

Modelos de Entrega de Servicio

2.2. Modelos de Entrega de Servicio

Captulo 2. Marco Conceptual

2.3. IP Multimedia Subsystem

Captulo 2. Marco Conceptual

2.3.1. Orgenes de IMS

Captulo 2. Marco Conceptual

2.3.2. Arquitectura IMS

Captulo 2. Marco Conceptual

de las funciones que ofrece IMS son:

Figura 2.4: Arquitectura IMS [19]

2.3.3. Componentes IMS

Captulo 2. Marco Conceptual

2.3.3. Componentes IMS

Captulo 2. Marco Conceptual

2.3.3. Componentes IMS

Captulo 2. Marco Conceptual

puede localizarse dentro o fuera del dominio IMS. 2.3.3.4. I-CSCF

2.3.4. Usuarios dentro de IMS

Captulo 2. Marco Conceptual

Usuarios dentro de IMS

Captulo 2. Marco Conceptual

2.3.6. Tecnologas y Protocolos Usados

Captulo 2. Marco Conceptual

Tecnologas y Protocolos Usados

2.3.6. Tecnologas y Protocolos Usados

Captulo 2. Marco Conceptual

2.3.6. Tecnologas y Protocolos Usados

Captulo 2. Marco Conceptual

Cuadro 2.1: Cdigos de Estado SIP 27

2.3.6. Tecnologas y Protocolos Usados

Captulo 2. Marco Conceptual

2.3.6. Tecnologas y Protocolos Usados

Captulo 2. Marco Conceptual

2.4. Servicios Basados en Localizacin

Captulo 2. Marco Conceptual

Servicios Basados en Localizacin

2.4.1. Mtodos de Localizacin

Captulo 2. Marco Conceptual

Captulo 2. Marco Conceptual

Captulo 2. Marco Conceptual

Figura 2.7: Servidor de Presencia

2.4.4. Documento de Presencia