Embed Size (px)
Citation preview
EVALUACIÓN DE DESEMPEÑO DE ARQUITECTURAS DE SERVICIOS
MULTIMEDIA CONVERGENTES
CARLOS MARIO RESTREPO CRIOLLO
UNIVERSIDAD NACIONAL DE COLOMBIA FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS E INDUSTRIAL PROGRAMA DE MAESTRÍA EN INGENIERÍA - TELECOMUNICACIONES
BOGOTÁ, COLOMBIA 2018
EVALUACIÓN DE DESEMPEÑO DE ARQUITECTURAS DE SERVICIOS MULTIMEDIA
CONVERGENTES
CARLOS MARIO RESTREPO CRIOLLO
Tesis presentada como requisito parcial para optar al título de: Magíster en Ingeniería – Telecomunicaciones
DIRECTOR: Ph.D. OCTAVIO SALCEDO PARRA
Línea de investigación: Redes y Sistemas de Telecomunicaciones
UNIVERSIDAD NACIONAL DE COLOMBIA SEDE BOGOTÁ
FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS E INDUSTRIAL
PROGRAMA DE MAESTRÍA EN INGENIERÍA - TELECOMUNICACIONES BOGOTÁ
2018
A Victoria Restrepo, cuya existencia me inspiró a
llegar hasta el final del camino
Agradecimientos
Agradezco en primer lugar al profesor Octavio Salcedo, director de esta tesis y docente del programa
de Maestría, por sus precisas y trascendentales orientaciones a la hora de trazar el rumbo recorrido
durante el proceso de investigación. Su aporte en torno a la formulación del modelo de tráfico y de
la Evaluación de los resultados fue definitivo.
Asimismo, agradezco a la Facultad de Ingenierías de la Universidad Nacional de Colombia, por todo
el conocimiento recibido, así como la disposición de equipos, recursos bibliográficos, entre otros,
que hicieron posible esta investigación.
Finalmente, debo agradecer a mis padres, Mario Restrepo y Elsa Criollo, ya que sin su apoyo no habría sido posible sacar adelante este proyecto. A mi hermano, Luis Gabriel Restrepo, por sus aportes en el diseño de la solución al problema de investigación. A mi compañera de vida, Isabel Meza, por su acompañamiento y apoyo incondicional en los momentos más difíciles. A Rosa Ortega, quien junto a los anteriores, compartió los sacrificios que conlleva investigar en Colombia.
i
Resumen
El presente trabajo tiene como fin hacer una evaluación del desempeño en redes
de servicios multimedia convergentes, teniendo en cuenta la evolución que han
tenido las arquitecturas de este tipo de servicios en los últimos años, donde el
énfasis se ha puesto sobre las redes móviles en torno a VoLTE (Voice over LTE).
Esta arquitectura combina los componentes del Subsistema Multimedia IP (IMS) y
de LTE (Long Term Evolution). Para esto se presenta un modelo de red para la
evaluación de las métricas de desempeño que trata de implementar la mayor
cantidad de componentes de la arquitectura, un modelo de tráfico para la red
propuesta y unos resultados de simulación para la toma de decisiones en materia
de diseño. La red es simulada en ns-3, simulación permitió observar como al
aumentar la media del tiempo de servicio en servidores de casi cero a 10
milisegundos, se aumentan los retardos de extremo a extremo en aproximadamente
un 150%, mientras que cuando se pasa de una media de 10 milisegundos a una
media de 20 milisegundos, los retardos se incrementan en aproximadamente un
126%, sobre todo para los trayectos que incluyen la petición Invite. Esto lleva a
pensar que, en caso de que aumente mucho el tráfico, los retardos generados por
el tiempo de servicio en servidores pueden afectar seriamente el desempeño de la
red.
Palabras clave: IP Multimedia Subsystem (IMS), Voice over LTE (VoLTE), Session
Initiation Protocol (SIP), NS-3 simulator, Redes abiertas de colas.
Abstract This work has the purpose of evaluate performance of networks of multimedia
convergent services, taking into account the evolution of the architectures for this
kind of services in last years, where emphasis has been on mobile networks, mainly
on VoLTE (Voice over LTE). This architecture combines components of IP
Multimedia Subsystem (IMS) with Long Term Evolution (LTE). To achieve the
purpose, a network model for VoLTE architecture is presented for evaluating
performance metrics. Starting from a proposed network model, the traffic model is
simulated in NS-3 simulation tool, looking for checking the behavior of traffic in
contrast to the proposed model. As main result, it was observable that the increase
of time service rate in servers from almost cero to 10 milliseconds, results in the
increase of end-to-end delays by approximately a 150%. Whereas, when going from
a time service rate of 10 milliseconds to a rate of 20 milliseconds, the increase is
around a 126%, mainly for transactions that include an Invite Request. Then, it is
reasonable to think that, in case of a big increase of the traffic in network, the delays
generated by time service in servers may affect seriously the network performance.
Keywords: IP Multimedia Subsystem (IMS), Voice over LTE (VoLTE), Session
Initiation Protocol (SIP), NS-3 simulator, Open Network Queues.
Contenido
Resumen ......................................................................................................................................... i
Lista de Figuras ............................................................................................................................... ii
Lista de tablas ................................................................................................................................ iii
Lista de Símbolos y abreviaturas .................................................................................................... iv
Introducción .................................................................................................................................. 1
1. PROBLEMA DE INVESTIGACIÓN .............................................................................................. 3
1.1 Formulación del problema .............................................................................................. 3
1.2 Objetivo General ............................................................................................................ 5
1.3 Objetivos Específicos ...................................................................................................... 5
2. ESTADO DEL ARTE .................................................................................................................. 6
2.1 Conceptos básicos de convergencia de servicios sobre IMS ............................................ 6
2.2 Evolución de arquitecturas para servicios multimedia ..................................................... 9
2.2.1 De H.323 a SIP ......................................................................................................... 9
2.2.2 Arquitectura General IMS ..................................................................................... 11
2.2.3 Arquitecturas 3GPP y 3GPP2 ................................................................................. 15
2.2.4 Arquitectura ETSI TISPAN ...................................................................................... 17
2.2.5 Evolución LTE ........................................................................................................ 18
2.3 Trabajos relacionados ................................................................................................... 20
2.3.1 Convergencia a través de IMS ............................................................................... 20
2.3.2 Virtualización de IMS ............................................................................................ 23
2.3.3 Capacidad de la red IMS ........................................................................................ 24
2.3.4 Calidad de la experiencia y del servicio en IMS ...................................................... 25
2.3.5 Desempeño y modelos de tráfico para IMS ........................................................... 26
2.3.6 Síntesis ................................................................................................................. 27
2.4 Marco de Referencia .................................................................................................... 28
2.4.1 Simulación por eventos discretos .......................................................................... 28
2.4.2 Características NS-3 .............................................................................................. 31
3. MODELOS PARA LA EVALUACIÓN DE DESEMPEÑO ............................................................... 34
3.1 Modelo de red para la evaluación de desempeño ......................................................... 34
3.2 Modelo de tráfico ......................................................................................................... 35
4. IMPLEMENTACIÓN DE LA SIMULACIÓN ................................................................................ 39
4.1 Implementación del modelo de red .............................................................................. 39
4.2 Resultados de simulación ............................................................................................. 41
5. EVALUACIÓN Y DISCUSIÓN DE RESULTADOS ......................................................................... 49
6. CONCLUSIONES Y TRABAJO FUTURO .................................................................................... 51
A. Anexo: Código para la simulación ......................................................................................... 53
Preámbulo ............................................................................................................................... 53
Cabeceras SIP ........................................................................................................................... 54
Aplicaciones ............................................................................................................................. 55
Script de configuración ............................................................................................................ 57
BIBLIOGRAFÍA .............................................................................................................................. 60
ii
Lista de Figuras
Pág.
Figura 2.1 Arquitectura de referencia para la convergencia de servicios [3] 7
Figura 2.2 Componentes principales de la arquitectura IMS [3] 11
Figura 2.3 Señalización para registro de usuarios [3] 13
Figura 2.4 Señalización para establecimiento de sesión Operador 1 [3] 14
Figura 2.5 Señalización para establecimiento de sesión Operador 2 [3] 15
Figura 2.6 Arquitectura LTE [4] 19
Figura 2.7 Árbol de problemas 28
Figura 2.8 Ejemplo comunicación entre dispositivo móvil y dos estaciones base [36] 30
Figura 2.9 Componentes LTE en el proyecto LENA [36] 32
Figura 3.1 Modelo de red 35
Figura 3.2 Modelo de tráfico 36
Figura 3.3 Throughput vs Tasa de paquetes que ingresan a la red 38
Figura 4.1 Implementación en NetAnim 41
Figura 4.2 Trayecto I 42
Figura 4.3 Trayecto II 42
Figura 4.4 Trayecto III 43
Figura 4.5 Retardos en milisegundos con tasa de servicio 10 milisegundos 45
Figura 4.6 Retardos en milisegundos con tasa de servicio 20 milisegundos 46
Lista de tablas
Pág
Tabla 2-1: Comparación 3GPP vs 3GPP2 [6] 16
Tabla 4-1: Retardos (milisegundos) de las sesiones por trayectos 44
Tabla 4-2: Retardos (ms) con tiempo de servicio de media 10 milisegundos 45
Tabla 4-3: Retardos (ms) con tiempo de servicio con media 20 milisegundos 45
Tabla 4-4: Cantidad de transiciones entre nodos contiguos, 6 UEs 47
Tabla 4-5: Cantidad de transiciones entre nodos contiguos, 5 UEs 48
iv
Lista de Símbolos y abreviaturas
Símbolos con letras latinas
Símbolo Término Unidad SI Definición
pij Probabilidad de transición de la cola I a la j 1 Ecu. (1) a (6)
Símbolos con letras griegas
Símbolo Término Unidad SI Definición
λ01, λ02, Tasa de llegada de paquetes a la red Paq/seg Ecu. (1) a (6)
θi Throughput en la cola i Paq/seg Ecu. (1) a (6)
Abreviaturas
Abreviatura Término
LTE Long Term Evolution IMS IP Multimedia Subsystem 3GPP 3rd Generation Partnership Project
TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking
MSF Multi-Service Forum VoLTE Voice over LTE ISP Internet Service Provider IETF Internet Engineering Task Force SIP Session Initiation Protocol UMTS Universal Mobile Telecommunications System NGN Next Generation Networks UIT Unión Internacional de Telecomunicaciones TCP/IP Transport Control Protocol/Internet Protocol HTTP Hipertext Transfer Protocol PSTN Public Switched Telecommunication Network QoS Quality of Service CSCF Call Session Control Function HSS Home Subscriber Server AAA Authentication, Authorization and Accounting RTP Real-Time Protocol RTCP Real-Time Control Protocol KPI Key Performance Indicators KQI Key Quality Indicators UE User Equipment PGW Packet Data Network-Gateway
1
Introducción
El mundo de las telecomunicaciones transita inevitablemente hacia la convergencia
de servicios multimedia (voz, video, televisión, entre otros). La demanda de
servicios convergentes que puedan funcionar sobre cualquier dispositivo de
comunicaciones, es un fenómeno que continúa ampliando el mercado de servicios
de llamadas, mensajería instantánea, video conferencia, entre otros.
Es así como nació la necesidad de crear el Subsistema Multimedia IP o IMS (IP
Multimedia Subsystem), como herramienta fundamental para la convergencia de
redes y servicios. Por su importancia, varios grupos internacionales de
estandarización interesados en el tema construyeron arquitecturas para la
convergencia de servicios [1], entre ellos 3GPP (3rd Generation Partnership
Project), TISPAN (Telecommunications and Internet converged Services and
Protocols for Advanced Networking) y MSF (Multi-Service Forum).
Cada cuerpo de estandarización fue creando y perfeccionando su propia versión de
una arquitectura para IMS, dejando una parte común que es conocida como el IMS
Core. Sin embargo, algunas de estas nunca tuvieron despliegue comercial ni fueron
suficientemente exploradas [1]. Es así como 3GPP se fue imponiendo en el
mercado, al punto que los demás cuerpos internacionales de estandarización
decidieron concurrir en el proyecto 3GPP para hacer una sola arquitectura para la
convergencia de servicios multimedia. En particular el caso de MSF, por ejemplo,
dejó de reunirse en 2013, aunque aún tiene publicados en internet toda la
documentación que produjeron en los últimos años. La unificación de criterios ha
llevado a que VoLTE sea hoy la arquitectura imperante, desde el punto de vista
2
comercial, en materia de convergencia de servicios, fundamentalmente ligados a la
telefonía móvil.
Al realizar esta investigación se pretende actualizar y profundizar la evaluación de
desempeño de Arquitecturas de servicios multimedia convergentes, generando un
modelo de tráfico adaptado, una síntesis de métricas de rendimiento y unos
resultados de desempeño para la toma de decisiones en materia de diseño de red
IMS. En sí, se busca dar respuesta a la pregunta: ¿Cuál es el comportamiento en
desempeño de redes IMS basadas en arquitecturas de servicios multimedia
convergentes?
Con el fin de dar respuesta a este interrogante, el trabajo está organizado para que
en el capítulo 2 se plantee una revisión conceptual sobre la convergencia de
servicios y el Subsistema Multimedia IP (IMS), así como la presentación del Estado
del Arte y el Marco de Referencia. El capítulo 3 plantea los modelos de red y de
tráfico necesarios para el desarrollo de este proyecto. En el capítulo 4 se presenta
como fue implementada la red en el trabajo de simulación y en un prototipo físico,
así como los resultados de la evaluación de desempeño de la red planteada, tanto
en simulación como en el prototipo físico. Finalmente, en el capítulo 5 se contrastan
los resultados con otros trabajos que abordan el tema, mientras en el capítulo 6 se
presentan las conclusiones y el trabajo futuro.
3
1. PROBLEMA DE INVESTIGACIÓN
1.1 Formulación del problema
La tecnología IMS (Subsistema Multimedia IP), desde su creación en 1999, ha sido
el centro de grandes investigaciones académicas por la importancia que ha tenido
durante la evolución de las redes de telefonía celular, telefonía IP y todas las
relacionadas con contenido multimedia. El objetivo de crearla fue brindar servicios
multimedia sin importar el dispositivo o red desde el cual accedieran los usuarios a
este tipo de servicios [1, 3], aunque su aplicación más fuerte ha girado en torno a la
telefonía móvil y la telefonía IP. En un principio, diferentes organismos de
estandarización (TISPAN, 3GPP, 3GPP2, MSF, entre otros) crearon arquitecturas
propias para integrar varias redes, pero fundamentalmente para comunicar redes
por conmutación de circuitos con redes por conmutación de paquetes. En [1] se
hace una revisión de las arquitecturas de estos organismos de estandarización,
como funcionaban y qué requerimientos buscaban satisfacer. Con los años, algunos
de estos organismos desaparecieron o se debilitaron, pero 3GPP (Third Generation
Partnership Project) estaba al frente de la estandarización de la telefonía móvil, así
que logró mantenerse para el desarrollo de 4G y ahora 5G. La incorporación de IMS
a 2G y 3G fue complicada por las limitaciones en recursos de estas redes. Con el
despliegue de 4G se incorporó IMS definitivamente en la arquitectura, que es
conocida como VoLTE (Voice over LTE) y se caracteriza por combinar los
componentes de LTE con IMS para brindarle servicios multimedia a los usuarios
finales.
4
La arquitectura definida por 3GPP especifica entidades funcionales, lo cual abre la
posibilidad de infinitas posibles combinaciones de nodos físicos o modelos de red
para una implementación real de IMS, así que los estudios del comportamiento y
modelamiento de tráfico que se han hecho hasta ahora no logran cubrir todas estas
posibilidades. Adicionalmente, algunos estudios de tráfico se hicieron sobre
premisas que hoy han sido rebasadas por los avances tecnológicos, por la
disposición de mayor ancho de banda y de mayor capacidad de procesamiento de
los equipos de cómputo. Por eso es vigente profundizar el estudio del desempeño
de redes IMS, pero ahora enfocado en la arquitectura VoLTE y en la preparación
para 5G, que trae grandes retos en términos de las posibilidades que pueda tener
IMS de ser escalado y que responda al número de usuarios [5].
Una primera pregunta que aparece es: ¿Qué inconvenientes en la prestación de
servicios presentan las arquitecturas de redes de servicios multimedia
convergentes, frente a problemas como el retardo, el exceso de tráfico, entre otros?
Es por esto que el problema de investigación a abordar es la actualización y
profundización de la evaluación de desempeño de Arquitecturas de servicios
multimedia convergentes, generando un modelo de tráfico adaptado, una síntesis
de métricas de rendimiento y unos resultados de desempeño para la toma de
decisiones en materia de diseño de red IMS. Más concretamente, se hace necesario
adelantar un proceso experimental que dé respuesta a la siguiente pregunta: ¿Cuál
es el efecto en el desempeño de redes IMS basadas en arquitecturas de
servicios multimedia convergentes de acuerdo con su más reciente
evolución?
Para poder evaluar este efecto debe definir un modelo de tráfico que, de la mano
con unas métricas de rendimiento, se logre una evaluación del desempeño de una
red multimedia convergente. En este sentido, es necesario recoger las métricas más
comunes en los estudios realizados hasta el momento por los trabajos que han
hecho análisis de rendimiento sobre IMS. Entre ellas se encuentra: Retardo de
5
establecimiento de sesión (Session establishment delay), retardo de disposición de
llamada (Call Setup Delay), retardo punto a punto (End-to-End delay), utilización de
los servidores del core IMS, entre otros.
Es así como al final de proyecto idealmente se tendrían un modelo de tráfico
adaptado, una síntesis de métricas de rendimiento y unos resultados de desempeño
para la toma de decisiones en materia de diseño de red IMS.
1.2 Objetivo General
Evaluar el desempeño de los componentes del Subsistema Multimedia Ip en redes
basadas en las arquitecturas de servicios multimedia convergentes.
1.3 Objetivos Específicos
� Diseñar modelos de red con características que se ajusten a las arquitecturas
IMS.
� Especificar planes de pruebas con base en las métricas necesarias para la
recolección de los datos de desempeño de la red.
� Recolectar mediciones del desempeño de los componentes del Subsistema
Multimedia IP con base en las métricas definidas, a través herramientas de
simulación y emulación.
6
2. ESTADO DEL ARTE
2.1 Conceptos básicos de convergencia de servicios
sobre IMS
El concepto de convergencia consiste principalmente en la posibilidad de ofrecer
una serie de servicios sin importar la red mediante la cual se accede, logrando que
los usuarios puedan comunicarse entre sí a través de estos servicios.
Un servicio convergente se define como aquel que “permite al usuario acceder a la
información multimedia (voz, vídeo y datos) a través de una única interfaz, de forma
ubicua, transparente, con calidad adecuada, y en múltiples contextos” [2]. El
concepto de ubicuidad aquí se refiere a “que el usuario tenga capacidad de acceder
a su información y sus aplicaciones en cualquier lugar y desde cualquier red,
empleando cualquier terminal y, en su caso, otros dispositivos de interfaz
específicos. Este concepto exige fundamentalmente capacidad de movilidad y de
portabilidad de aplicaciones y contenidos, interconexión e interoperabilidad entre
plataformas y operadores en sus máximos niveles, y la presencia de redes de
proximidad que aíslen al terminal de la red de acceso que en cada momento sea
accesible” [2].
Aprovechando los avances que ha tenido Internet, uno de los propósitos de la
convergencia es lograr que servicios de telecomunicaciones tan utilizados como la
telefonía (voz, móvil o fija), broadcasting de video, entre otros, puedan ser ofrecidos
7
todos sobre redes IP (Internet Protocol). Teniendo como referencia el “stack” de
protocolos de TCP/IP, hoy todos los proveedores de internet (ISP, Internet Service
Provider) pueden transportar en sus redes video, voz y casi cualquier tipo de dato;
el siguiente paso es lograr que un servicio como el de telefonía, cuando se ofrezca
sobre redes IP, sea igual o mejor que el servicio actual de telefonía (sobre todo en
términos de QoS).
Es así como aparece IMS (IP Multimedia Subsystem) para lograr dicha convergencia, con una arquitectura de referencia como se muestra en la figura 2.1.
Figura 2-1: Arquitectura de referencia para la convergencia de servicios [3]
Uno de los principales servicios que ofrece el subsistema es el de presencia: cuando
se envían paquetes o mensajes sobre internet, prácticamente se puede enviar
cualquier tipo de dato (voz, video, etc.), pero el protocolo IP solo reconoce como
destino direcciones IP; con el servicio de presencia se asegura que el mensaje
llegue al usuario de destino exacto, sin importar la dirección IP o el dispositivo o red
8
de acceso que esté usando en ese momento, ya que con la información de
presencia y la señalización utilizada por IMS, el paquete llegará al destino con base
en el nombre e identificación del usuario de destino; si este usuario tiene múltiples
dispositivos conectados o habilitados para la conexión, IMS puede identificar cual
es el dispositivo correcto para el tipo de mensaje que se está comunicando (por
ejemplo, un dispositivo que pueda reproducir video, si el paquete es de video),
evitando así que un paquete llegue a un dispositivo que no puede utilizarlo y
simplemente se pierda. Así mismo, IMS permite que se desarrollen aplicaciones en
diferentes contextos, a las cuales todos los usuarios acceden gracias a que
comparten una red de contacto; es así como los contactos que guarda un usuario
no dependen de la aplicación que prefieren dichos contactos (listas de contactos
diferentes para cada aplicación), sino que depende más de una red de contactos
que puede ser implementada por el operador (ISP o una tercera parte), que ofrece
cualquiera de estas aplicaciones a sus usuarios; cuando aparezca una nueva
aplicación, el usuario no tiene que decirle a esta nuevamente cuáles son sus
contactos.
Cuando se crean las aplicaciones, los desarrolladores se han topado con una gran
cantidad de plataformas y capacidades tecnológicas diferentes en los dispositivos
de acceso que venden las diferentes compañías, lo cual lleva a crear miles de
versiones distintas de la aplicación. IMS logra superar este problema, ya que se
encarga de adaptar la aplicación a las características de los dispositivos de acceso,
logrando que el código de la aplicación se concentre en su “fin misional” y no se
preocupe por adaptarse a X o Y tecnología de acceso.
A pesar de todo esto, el uso más importante que se le puede dar a IMS está
relacionado con la migración que los operadores pueden hacer, de la telefonía por
conmutación de circuitos a una telefonía IP de bajo costo. Las arquitecturas
desarrolladas hasta el momento para la convergencia de servicios incluyen esta
capacidad entre las características de IMS.
9
2.2 Evolución de arquitecturas para servicios multimedia
2.2.1 De H.323 a SIP
Internet tuvo una gran evolución durante la década de los 80s, en la cual el servicio
más usado era el correo electrónico y las comunicaciones entre servidores; sin
embargo, es en la década de los 90s donde su explosión le permitió trascender del
mundo corporativo a los hogares de millones de familias, con la aparición de las
primeras páginas web, los exploradores de internet, los motores de búsqueda, entre
otros. Precisamente es en esta década que surge la inquietud inicial de transmitir
sobre esta red el servicio de telecomunicaciones más importante del momento: la
Telefonía. Tras poco menos de un siglo de evolución y miles de millones de usuarios
interconectados en todo el mundo, las redes de telefonía empezaban a migrar a la
era digital, lo cual permitió a los operadores de estas redes ofrecer servicios de
conexión a internet sobre sus redes. Pero rápidamente, con el desarrollo de
tecnologías más veloces que las redes telefónicas para transmitir los datos de
internet, se invirtió el concepto dando paso a la idea de transportar el servicio
telefónico sobre las redes de Internet.
Empezaron a aparecer tecnologías para la transmisión de voz sobre los protocolos
de Internet. Pero la inquietud no se redujo solo a la transmisión de la voz, también
era importante transmitir video, comunicar varios usuarios en Conferencia (también
en Video Conferencia), pensar en juegos con usuarios en línea, se debía tener la
posibilidad de transmitir imágenes, entre otros tipos de contenido multimedia que en
ese entonces solo se ofrecían a través de sistemas operativos de escritorio como
Windows. Fue entonces en los inicios de la década de los 90s que la UIT (Unión
Internacional de Telecomunicaciones) empezara a desarrollar las recomendaciones
serie H, destinadas a definir sistemas audiovisuales y multimedia.
En particular la recomendación H.323 en 1996 se encargó de definir las
características de los sistemas y equipos terminales para servicios audiovisuales
10
sobre redes de conmutación de paquetes. Ya que Internet era una red por
conmutación de paquetes, se convertiría prontamente en la red por excelencia sobre
la cual se iban a transportar este tipo de servicios. Sin embargo, la complejidad y
difícil implementación de H.323 llevarían a que el IETF (Internet Engineering Task
Force), como instituto internacional de estandarización de Internet, así como de
definición de sus protocolos, desarrollara el protocolo de inicio de sesión SIP
(Session Initiation Protocol) [2]. Este concretó los mecanismos para el
establecimiento de sesiones entre usuarios para el intercambio de contenido
multimedia sobre redes IP, de una forma más sencilla y eficaz; su similitud con el
intercambio request-response definido en HTTP lo hizo más atractivo para la
industria, razones por las cuales la UIT definió la creación de 3GPP (3rd Generetion
Partnership Project) como organismo para definir una nueva arquitectura que,
basada en el protocolo SIP, permitiera a los proveedores de servicios ofrecer
servicios multimedia [1, 2]. Hoy en día es más utilizado el protocolo SIP que la
recomendación H.323 para ofrecer servicios como Voz sobre IP, video conferencia,
entre otros.
De las sesiones del 3GPP nace IMS (IP Multimedia Subsystem), como un sistema
de servidores que intercambian requests y responses SIP para establecer sesiones
entre subscriptores. Sin embargo, se crearon otros organismos compuestos por
empresas del sector (fundamentalmente de Europa y Asia) ya que no hubo
consenso en la forma como IMS debía interconectarse con redes que en ese
momento eran preponderantes en el mercado, como la PSTN (red de telefonía
pública, en inglés Public Switched Telephony Network) e ISDN (red digital de
servicios integrados, en inglés Integrated Services Digital Network), entre otras.
Organismos como TISPAN (Telecommunications and Internet converged Services
and Protocols for Advanced Networking) y MSF (Multi-Service Forum) plantearon
funcionalidades para adaptar IMS al paradigma de Redes de Nueva Generación
NGN (New Generation Networks) definido por la UIT [5]. Hoy en día, estos
organismos han logrado unificarse en torno a 3GPP para definir una sola
11
arquitectura para IMS, la cual está orientada comercialmente hacia la telefonía
celular.
Además, en el standard SIP se definen unas cabeceras (Headers) para que cada
componente dentro del dominio SIP aplique mecanismos de enrutamiento,
intercambio de características de medios a través de RTP (Real-Time Protocol) y
RTCP (Real-Time Control Protocol), entre otras funciones.
Es así como SIP se convierte en la base de las arquitecturas para el intercambio
de recursos multimedia y H.323 fue abandonado con el tiempo.
2.2.2 Arquitectura General IMS
En la figura 2-2 se puede observar los componentes de la arquitectura IMS.
Figura 2-2: Componentes principales de la arquitectura IMS [3]
La UIT creó entonces el grupo 3GPP (3rd Generation Partnership Project) para
diseñar una arquitectura de servicios multimedia acorde con el paradigma de Redes
de Nueva Generación, grupo que posteriormente le daría vida a IMS (IP Multimedia
12
Subsystem). Aunque IMS es una tecnología que fue pensada para ofrecer servicios
multimedia para todo tipo de redes de acceso de los usuarios, su uso se ha hecho
particularmente útil para las redes de telefonía móvil. Es así como, a través de
diferentes Gateways, usuarios con diferentes dispositivos de comunicación pueden
utilizar servicios multimedia como llamadas, videoconferencia, mensajes de texto,
entre otros, para comunicarse entre sí, sin importar el tipo de red a través del cual
esté accediendo a estos servicios (redes inalámbricas como WLAN, redes móviles
como UMTS, redes cableadas como Ethernet, la red de telefonía fija PSTN, etc.).
Por un lado, se encuentra la red de acceso IP, la cual puede ser el servicio de
internet de un ISP (Internet Service Provider), una red WIFI, una red móvil, etc. Así
mismo se observa el core IMS compuesto por 3 servidores CSCF (Call Session
Control Function): el P-CSCF (Proxy-CSCF) el cual es el primer punto de contacto
con el usuario, el I-CSCF (Interrogating-CSCF) que es el punto de entrada al core
funcionando como un firewall que esconde la topología interna, y el S-CSCF
(Serving-CSCF) que concentra la mayoría de funciones de control de sesión
(registro, gatilleo de servidores de aplicaciones, etc.).
Se puede ver el HSS (Home Subscriber Server) que contiene la base de datos con
los perfiles de usuarios de servicios y la autenticación de los mismos, así como los
servicios de autorización y contabilidad [3]. Adicionalmente están los Servidores de
Aplicaciones (SIP-AS), los cuales se encargan de proveer servicios de valor
agregado a los usuarios.
La figura también muestra las interfaces mediante las cuales se comunican los
nodos. Estas interfaces son conjuntos de protocolos de diferentes capas. En el caso
específico de los servidores del core, estos utilizan SIP (Protocolo de inicio de
sesión) para comunicarse entre sí, el HSS usa protocolos como RADIUS o
DIAMETER para comunicarse con el resto de nodos, mientras que los SIP-AS
utilizan una interfaz ISC que también incluye a SIP para comunicarse con el core
[3].
13
El tráfico de señalización de las redes IMS es alto, lo cual genera en la mayoría de
los casos, retardos y problemas de rendimiento cuando los servicios son
demandados por un número alto de usuarios. En la figura 2.4 y 2.5 se puede
observar el tráfico producido por el registro de usuarios y por el establecimiento de
una sesión [3].
Figura 2-3: Señalización para registro de usuarios [3]
Es importante tener en cuenta que en estos flujos de señalización en las dos figuras
(2.4 y 2.5) son los que se presentarían en un escenario donde se trata de establecer
sesión entre dos usuarios que están en dominios diferentes. Se puede observar
nodos intermedios que aseguran la intercomunicación entre ambos dominios, así
que por razones ilustrativas se han separado los trayectos: desde el dominio inicial
hasta la frontera y desde la frontera hasta el dominio final.
14
Figura 2-4: Señalización para establecimiento de sesión Operador 1 [3]
15
Figura 2-5: Señalización para establecimiento de sesión Operador 2 [3]
2.2.3 Arquitecturas 3GPP y 3GPP2
IMS nace en el Release 5 de 3GPP. Este último definió sus estándares para redes
inalámbricas basándose en GSM (Global System for Mpbile Communication) y
GPRS (General Radio Packet Services), mientras que 3GPP2 se basó en CDMA-
2000 (Code Division Multiple Access, estándar norteamericano). La principal
motivación del nacimiento de IMS era unir Internet con las redes 3G de la Telefonía
móvil. Ambas arquitecturas compartieron en su inicio la característica de tener un
dominio CS para soportar servicios convencionales de redes por conmutación de
servicios, así como un dominio PS para soportar los nuevos servicios que siguen el
16
paradigma de conmutación de paquetes. IMS fue introducido en el dominio PS,
independiente del dominio CS, para desarrollar servicios de Voz sobre IP y cualquier
otro servicio que pudiera correr sobre IP. En el Release 6 se definieron dos
requerimientos muy importantes para IMS: primero, un principio de independencia
de acceso, en el cual los servicios fueran ofrecidos a los clientes sin importar la red
mediante la cual intentan acceder a dichos servicios; segundo, se debía soportar la
interconexión de la red móvil (que era la que más le interesaba a 3GPP) con otras
redes incluyendo internet [6].
Las arquitecturas tanto de 3GPP como de 3GPP2 son muy similares, debido a que
buscan objetivos similares; una parte muy importante de sus componentes solo
tienen nombres distintos, pero comparten las mismas funcionalidades. Entre las
diferencias se puede encontrar que 3GPP sólo admite Ipv6, mientras que 3GPP2
admite ambos Ipv4 e Ipv6.; así mismo, en 3GPP existe un componente funcional
llamado HSS que fundamentalmente guarda información relevante sobre todos los
subscriptores, tanto para el dominio CS como para el PS. Sin embargo, en 3GPP2
este componente se divide en dos, una parte encargada de la Autenticación,
Autorización y Contabilidad (AAA por sus siglas en inglés, Authetication,
Authorization and Accounting), mientras que la otra parte se encarga de cualquier
otra base de datos necesaria. Algunas diferencias se listan en la siguiente tabla [6].
Tabla 2-1: Comparación 3GPP vs 3GPP2 [6]
DIFERENCIAS 3GPP 3GPP2
Gestión de movilidad Tunneling capa 2 usando GPRS IP Móvil
Versión IP Solamente IPv6 IPv4 e IPv6 (opcional)
Seguridad de acceso Solamente IPSec Varias alternativas
GGSN/PDSN GGSN nunca cambia PDSN puede cambiar
Ubicación P-CSCF GGSN y P-CSCF siempre están
en la misma red
PDSN y P-CSCF pueden
estar en diferentes redes
Base de Datos HSS AAA
Smart Card UICC R-UIM
17
La idea era que IMS fuera utilizada por la ITU en la definición de NGN. Esto se
quedó en recomendaciones en la generalidad que hoy han ido perdiendo
protagonismo, opacados por nuevos paradigmas como “Internet de todas las Cosas
IoE (Internet of Everything)”, “Cloud Computing”, entre otras [6].
2.2.4 Arquitectura ETSI TISPAN
Dos organismos de estandarización se formaron para trabajar paralelamente a
3GPP en la convergencia de servicios: MSF (Multi-Service Forum, creado en 1998
y clausurado en 2013) y TISPAN (Telecommunication and Internet Converged
Services and Protocols for Advanced Networks, creado en 2003 y aun en
funcionamiento). El primero, MSF, fue una asociación de operadores y fabricantes
de la industria de las telecomunicaciones, que se unieron con el fin de buscar
acuerdos de interoperabilidad entre diferentes tipos de redes y servicios; partiendo
de esto, lograron un extenso compendio de recomendaciones, “White Papers”,
escenarios de pruebas, planes de pruebas y acuerdos de implementación que
sirven de referencia fundamentalmente para la interoperabilidad de redes móviles y
fijas. El segundo organismo (TISPAN) fue creado por la ETSI (European
Telecommunications Standars Institute) con el fin de construir estándares de
interoperabilidad bajo el paradigma de las redes de nueva generación NGN.
El NGN Release 1 se terminó en diciembre de 2015 y proporciona las normas
sólidas y abiertas que la industria requiere para el desarrollo, prueba e
implementación de la primera generación de sistemas NGN. TISPAN adoptó las
especificaciones 3GPP IMS para las aplicaciones basadas en SIP, pero también
añadió componentes funcionales y subsistemas para manejar las aplicaciones no-
SIP. Inicialmente TISPAN trabajó en la armonización del núcleo de IMS para redes
tanto inalámbricas como por cable; sin embargo, a principios de 2008, las
especificaciones comunes de IMS fueron transferidas al 3GPP para que una única
organización de estándares se responsabilizase de proporcionar un sistema común
de IMS adaptable a cualquier red (fija, 3GPP, CDMA200, etc.). Fue introducido en
la Release 7 del 3GPP.
18
El NGN Release 2 finalizó a principios de 2008 y añadió elementos clave para las
NGN, como IPTV basado y no basado en IMS, redes domésticas y dispositivos, así
como la interconexión de las NGN con las redes corporativas. TISPAN define dos
soluciones IPTV: un subsistema de IPTV centrado en la integración de soluciones
de mercado existentes en un entorno NGN, y una solución IPTV basada en IMS que
permite mezclar los servicios de televisión con otros servicios de
telecomunicaciones (por ejemplo, servicios de voz, presencia y los datos).
Ambos organismos definieron arquitecturas de Nueva Generación que incluyen
IMS, con algunos aspectos en común. Para TISPAN lo fundamental era desarrollar
el paradigma NGN y realizar los estándares necesarios para adaptar las nuevas
tecnologías a este paradigma. Sus más recientes trabajos giran en torno a la
adaptación de IPTV a NGN, concentrándose en temas como seguridad, calidad del
servicio, arquitectura detallada, servicios básicos, entre otros [4]. Aunque en [4] se
asegura que su arquitectura está hecha para ser implementada sólo por operadores
de telefonía fija (conmutación de circuitos), otras fuentes aseguran que, a pesar de
estar centrada en la evolución de redes basadas en conmutación de circuitos a
conmutación de paquetes, puede ser usada tanto por operadores de telefonía móvil
como de la fija. En el caso de los móviles, podrían utilizar la arquitectura TISPAN y
sus recomendaciones para conectar usuarios en redes IP con usuarios conectados
en redes tradicionales como PSTN, ISDN o GSM. Haciendo una revisión de las
publicaciones recientes de TISPAN, también se puede notar un fuerte énfasis en el
desarrollo de IPTV para IMS.
2.2.5 Evolución LTE
Después de 2010, IMS es acogido por el grupo GSMA (Asociación GSM) para
transportar los servicios de voz de GSM sobre IP. Esto lleva a que el grupo 3GPP
desarrolle LTE, una nueva arquitectura que evolucionó la arquitectura tradicional de
las redes móviles, tanto GSM como CDMA.
19
En la figura 2.6 se puede observar los componentes de LTE que corresponden al
acceso radio de los usuarios, así como aquellos necesarios para implementar
VoLTE (Voz sobre IP en LTE) y para conectar LTE con redes anteriores (2G o 3G).
El PDN-GW (Packet Data Network Gateway) es el que conecta la red de radio con
la red de paquetes, por lo cual es la compuerta de enrutamiento para salir a internet;
IMS se conecta con el PDN-GW para ofrecer servicios multimedia.
Figura 2-6: Arquitectura LTE [4]
Mientras fue evolucionando la nueva arquitectura propuesta por 3GPP, los
principales cambios estuvieron en la reducción del número de componentes e
interfaces, en comparación con UMTS y GSM. La red de radio incrementó
considerablemente la velocidad de transmisión y la eficiencia del manejo del ancho
de banda, lo cual permitió que muchos operadores ofrecieran servicios de datos a
mayor velocidad [4].
20
Los operadores móviles en la actualidad quieren migrar a la nueva tecnología LTE,
pero lo han hecho fundamentalmente para el tráfico y servicios de datos, ya que
tienen a la mayoría de sus subscriptores de voz en redes de anterior generación
como UMTS y GPRS, así que esperan poder explotar por un tiempo más la inversión
que hicieron en la infraestructura de generación anterior antes de dar el salto
definitivo a LTE, en la cual los servicios de voz serían trasladados a VoLTE (Voz
sobre LTE o Voice Over LTE) [4].
2.3 Trabajos relacionados
2.3.1 Convergencia a través de IMS
Como se expuso en secciones anteriores de este trabajo, organismos
internacionales de estandarización en el mundo de las telecomunicaciones han
hecho propuestas diferentes de arquitecturas para la convergencia de servicios,
entre las cuales también hay diferencias en algunos componentes y formas de
implementar IMS. Sin embargo, en los trabajos estudiados, se pudo observar que
siguen especificaciones de 3GPP y TISPAN (Telecommunication and Internet
Converged Services and Protocols for Advanced Networks).
Un tema que inicialmente se llevó la atención de los investigadores fue el análisis
de desempeño de redes con usuarios accediendo desde múltiples redes diferentes.
En [7] se hace una evaluación del desempeño de la plataforma OpenIMS core con
usuarios accediendo desde: Fast Ethernet, WIFI 802.11b y g, 3G CDMA y GPRS.
Como resultado final se encuentra que las tecnologías WLAN 802.11 b y g son las
que presentan el mejor rendimiento para los usuarios. 3G CDMA muestra resultados
más bajos en términos del rendimiento, pero aún aceptables. GPRS muestra
resultados que son inaceptables en calidad del servicio para los usuarios y de
requerimientos mínimos para los sistemas de comunicaciones de hoy en día. En [8]
también se hacen pruebas sobre 802.11 cuando se usan túneles IPSec en una
arquitectura de interconexión entre 3G y WLAN, así como el máximo número de
21
posibles conexiones en un Access Point AP sencillo sin degradar el nivel requerido
de Calidad de Servicio QoS para el tráfico multimedia. En [9] se realizaron pruebas
en una red real comparando el desempeño cuando se utilizan WIFI, UMTS, GPRS,
HSDPA como redes de acceso. Nuevamente se muestra en los resultados que
cuando se utiliza GPRS hay saturación del sistema debido a la señalización SIP.
Hasta aquí era muy importante ver como se lograba la comunicación entre distintas
tecnologías móviles ya desplegadas comercialmente, así como con WIFI que
empezaba a dominar el acceso a internet en el hogar.
Los trabajos [10] y [11] presentan una comparación entre redes IMS y redes SIP
puras sobre 3 diferentes servicios: Registro, llamadas y mensajería. Ambos trabajos
concluyen que las redes SIP puras tienen un nivel de señalización menos complejo
y, por tanto, generan menos tráfico y mejor rendimiento; sin embargo, las redes IMS
son más escalables para grandes volúmenes de usuarios y servicios más
complejos. Estos dos trabajos se centran en la arquitectura IMS propuesta por
TISPAN. El resto de trabajos se basan en las especificaciones de 3GPP.
En [12] se implementan, sobre redes en un ambiente de comunicaciones
vehiculares, servicios de mensajería instantánea, servicio de presencia y
notificación, registro y de-registro. Para este sistema se utilizan como redes de
acceso a WIFI y UMTS. Este trabajo muestra una red de servicios convergentes
sobre dos tipos de red particulares, para hacer encontrar internet móvil con telefonía
móvil. Aquí se empieza a explorar un tema no resuelto, que es la convergencia de
servicios para usuarios que están en movimiento.
En [13] se estudia el retardo generado por la señalización SIP en sistemas IMS
cuando se utilizan como redes de acceso a GSM, WLAN y PSTN, principalmente
en el establecimiento de la sesión. En todos los escenarios, el mejor rendimiento se
presenta cuando la red de acceso usada es WLAN. Cuando ambos UE acceden a
través de la PSTN, se presenta un desempeño solo superado por WLAN en el
tiempo de solicitud de establecimiento de llamada; en los tiempos de respuesta, de
liberación de la llamada y de Setup, PSTN es superado por la combinación de
22
acceso entre GSM y WiMAX. En todas las métricas de rendimiento, el escenario
que presenta peor rendimiento es cuando los UE acceden a través de GSM. En [14]
se hace el análisis del desempeño principalmente en el aumento de tráfico, en un
sistema IMS con redes de acceso: CDMA2000 (telefonía móvil) y WLAN (internet
inalámbrico). Se consideran dos escenarios para el análisis del tráfico: En el primero
el terminal móvil se mueve de una red CDMA2000 a la red WLAN, en el segundo el
usuario móvil vaga por la red WLAN mientras usa servicios IMS y puede regresar a
la red CDMA. En ambos escenarios el usuario pasa automáticamente a la red WLAN
cuando entra en su área de cobertura. Los resultados revelan que la integración de
estas dos redes en un radio de 100m incrementa la señalización IMS. Finalmente,
en [15] se estudia el tiempo de disponibilidad de sesión en un sistema que usa las
siguientes redes de acceso: PSTN, WLAN, GSM y WiMax. Primero se analiza el
rendimiento cuando ambos usuarios acceden desde el mismo tipo de red, y después
accediendo desde redes diferentes. Los resultados muestran que el mayor retardo
se presenta cuando se establece sesión entre dos usuarios GSM.
Hasta este momento se podía observar como las redes 2G y 3G generaban arduos
problemas para la implementación de servicios convergentes (incluso mayores a los
generados por el uso de redes fijas como PSTN e ISDN), mientras que WLAN,
WiMAX y Fast Ethernet eran redes de acceso que soportaban mucho mejor la
señalización para el establecimiento de sesiones multimedia.
Después de esto vino la implementación y despliegue de 4G, que trajo consigo
nuevas investigaciones, todas enfocadas en la nueva arquitectura VoLTE (Voice
over LTE). Las investigaciones insistieron en evaluar el desempeño de sistemas
IMS con varias redes de acceso (sistemas híbridos), pero ahora incluyendo 4G/LTE.
Un ejemplo de esto se ve en [16], donde se implementa una red híbrida LTE-
WIMAX-WLAN para revisar su interoperabilidad y se comparan los resultados de
desempeño con una red UMTS-WIMAX-WLAN, en una simulación sobre OPNET
Modeler.
23
2.3.2 Virtualización de IMS
Por otro lado, están aquellas que abordaron el problema de la virtualización de IMS
en la idea de escalarlo para atender un mayor número de usuarios y para superar
las dificultades en desempeño encontradas hasta el momento, como es el caso de
[5], [17]. En [5] se hace una revisión crítica de las arquitecturas propuestas para
“ennubar” IMS (Cloudifying IMS), que se confrontan con los retos de la convergencia
de servicios: escalabilidad, por la necesidad de incluir infraestructura física para
manejar los 10 a 100 veces más usuarios que exigirá 5G; latency, ya que las
aplicaciones cada vez toleran menos retardo que antes; eficiencia de recursos, ya
que IMS es instalado con una gran cantidad de recursos para soportar la demanda,
lo cual hace que estos recursos se use ineficientemente; “Follow-Me” que es un
concepto para el diseño de servicios que siguen a sus usuarios mientras se mueven
(actualmente, si un usuario requiere un servicio, se registra a un S-CSCF que lo
atiende mientras requiera el servicio; si el usuario se mueve, y por ende, debe ser
atendido por otro S-CSCF, debe de-registrarse del primero para registrarse en el
segundo, con las consecuencias de retardo y demás que esto implica); la principal
crítica a las arquitecturas revisadas es que ninguna se ocupa del reto “Follow-Me”,
pocas se ocupan del latency y la mayoría trata de resolver la escalabilidad con sus
problemas derivados, entre ellos, los retardos generados por la señalización de SIP
como protocolo basado en texto. En [17] se propone un diseño de un Sistema
dinámico de escalamiento (llamado ScalIMS implementado en JAVA) para cadenas
de servicio VNF (Virtual Network Function) geo-distribuidos, usando el caso de una
red IMS. El diseño del sistema de escalamiento combina aproximaciones proactivas
y reactivas para un escalamiento efectivo en costos de las cadenas de servicio. Se
evalúa el sistema usando experimentos físicos en una plataforma de emulación y
en una nube pública geo-distribuida.
En sintonía con estas investigaciones sobre virtualización, se han probado otros
métodos que combinan SDN (Software Defined Networks - Redes Definidas por
Software) con IMS para hacer control sobre el despliegue de servicios multimedia.
Tal es el caso de [18] y [19]. En el primero se implementa un controlador SDN para
hacer control sobre el tráfico IMS, basado en JAVA y que usa el protocolo
24
OpenFlow. En el segundo se presenta una nueva arquitectura basada en SDN para
el core LTE con el fin de mejorar la gestión de la calidad del servicio. Esta es
implementada y evaluada para un servicio de video a demanda VoD, midiendo la
calidad de la experiencia QoE en términos de la VMOS (Video Mean Opinion Score),
en una testbed que contiene componentes desarrollados en software abierto.
Además, se configuran unas políticas de Calidad del Servicio para definir
prioridades sobre el tráfico IMS y unos umbrales para el ancho de banda, pérdida
máxima de paquetes, retardo máximo, entre otras, aplicadas a diferentes tipos de
tráfico para mostrar la forma como el aumento del mismo impacta la VMOS.
2.3.3 Capacidad de la red IMS
Un tema también asociado con la superación de los retos que tiene la convergencia
de servicios es el de aumentar la capacidad de la red IMS y hacer más eficiente el
uso de sus recursos. Es así como en [20], [21], [22] y [23] se aborda este tema
desde diversas ópticas. En [20] se interconecta la plataforma IMS con los módulos
Hadoop para mejorar la capacidad de almacenamiento y procesamiento de los
servidores en el EPC (Evolved Packet Core), demostrando como se mejoraba el
desempeño en cuanto al delay, jitter y pérdida de paquetes. En [21] se analiza el
funcionamiento del core IMS para resolver problemas de conjugación de transporte
y flujos de señalización, presentando un modelo que permite calcular el volumen de
tráfico entrante desde una red heterogénea y su valor después de convertirlo a una
forma estándar de acuerdo con los requerimientos de la arquitectura IMS, para de
esta forma, definir el throughput necesario que debe tener la red IMS. En [22] se
describe la estructura del HSS (Home Subscriber Server) y se derivan ecuaciones
para definir el tamaño de su carga en escenarios propuestos; se usan cadenas de
markov y la fórmula C de Erlang como métodos para calcular el tamaño de la base
de datos. En [23] Se propone un mecanismo inteligente de distribución en IMS,
basado en métodos de decisión heurísticos, y un modelo de distribución de
probabilidad para desplegar streaming multimedia entre proveedores de servicio y
los clientes que cargan y descargan multimedia; se enfoca en mejorar tres
25
parámetros: Optimización del tiempo de carga de archivos multimedia, garantizar la
calidad de la experiencia para usuarios finales y la eficiencia en el IMS.
2.3.4 Calidad de la experiencia y del servicio en IMS
Precisamente en la misma línea de este último trabajo, se ha buscado profundizar
mucho en el estudio de la Calidad del Servicio y la Calidad de la Experiencia de los
servicios desplegados en la arquitectura VoLTE, como se muestra en [24], [25], [26]
y [27]. En [24] se caracteriza el desempeño LTE basándose en métricas de Calidad
de la Experiencia QoE, evaluando fundamentalmente los problemas que sienten los
usuarios finales durante una llamada de voz sobre IP, comparando los casos en que
se usa VoLTE, Skype (como servicio OTT-Over The Top), Hangouts y la red “legacy”
(2G o 3G). En [25] se definen tres procesos para el modelamiento de calidad de
experiencia: el primero es la implementación de modelos funcionales de una red
LTE para la evaluación de calidad de servicio y calidad de experiencia, un modelo
por cada servicio, luego en este artículo se presentan dos modelos; el segundo es
el establecimiento de una relación matemática de interdependencia entre los
parámetros de QoS y QoE para los servicios de tiempo real bajo estudio; el tercero
es simular y diseñar el modelo funcional LTE, con base en los dos procesos
anteriores, modelo cuyo fin es calcular valores de parámetros de QoS basándose
en factores de QoE deseados. Sin embargo, este trabajo solo se centra en el primer
proceso, ya que en [26] los mismos autores del anterior se concentran en el segundo
proceso, planteando un modelo para hallar las relaciones matemáticas entre QoS
KPI (Key Performance Indicators) y los QoE KQI (Key Quality Indicators), con el fin
de calcular el KQI como MOS a partir del Jitter y la pérdida de paquetes (KPIs). En
[27] se hace un estado del arte en el cual se establecen las bases para el studio de
mecanismos de QoS de extremo a extremo en IMS. Hay una sección de discusión
donde se plantea el problema central que gira en torno a proveer QoS consistente
de extremo a extremo sobre un servicio que se despliega entre dos operadores con
redes autónomas y cuyos dominios administrativos son administrados con sus
propias políticas; este problema también es la conclusión principal del trabajo,
después de revisar los estándares vigentes sobre Calidad de Servicio en IMS.
26
2.3.5 Desempeño y modelos de tráfico para IMS
Otro aspecto ampliamente abordado es modelar el tráfico en redes IMS. Los
trabajos anteriores, en su mayoría, hacen análisis del desempeño de algunos
componentes de las arquitecturas IMS, pero no es su prioridad elaborar un modelo
del tráfico de estas redes. Algunos de los que se van a presentar a continuación van
en la misma línea de hacer solamente análisis de desempeño de redes de servicios
convergentes bajo determinados escenarios, planteando métricas que es
importante tener en cuenta. Los otros sí se centran en presentar modelos de tráfico,
los cuales son de especial relevancia en ésta investigación por la necesidad de
actualizar los modelos propuestos hasta el momento con los avances tecnológicos.
En [28] y en [29] se propone un modelo analítico para el jitter en redes IMS y los
mecanismos para calcularlo, respectivamente. En [30] se hace un análisis del
desempeño de señalización SIP de VoLTE sobre sistemas de comunicación Mission
Critical; los criterios para medir el desempeño end-to-end de SIP fueron definidos
en el RFC 6076 [31], que además incluye métricas de desempeño para SIP en
aplicaciones VoIP para proveer Indicadores Clave de Desempeño (Key
Performance Indicators). En [32] se parte de la premisa de que el protocolo SIP
carece de un mecanismo apropiado para direccionar sobrecarga, causando graves
problemas en los SIP servers; el desempeño de los servidores SIP se degrada
durante los tiempos de sobrecarga debido a los mecanismos de retransmisión SIP,
por lo cual se propone un mecanismo que es una mejora del método de control de
sobrecarga basado en ventana (windows based) y definido en el RFC 6357 [33], en
el cual la ventana es usada para limitar la cantidad de mensajes generados por el
servidor Sip Proxy. La sobrecarga estudiada es la que se genera de servidor a
servidor, concluyendo que el protocolo SIP es ineficiente cuando enfrenta la
sobrecarga. Por tanto, cuando se incrementa el número de requests, se
incrementan los retardos de establecimiento de sesión, el throughput cae y en
consecuencia aumentan las tasas de retransmisón y las llamadas no exitosas.
27
Dos trabajos recientes han abordado el problema de modelar el tráfico en IMS.
Elaborados por los mismos autores, en [34] y [35] se hace una evaluación de los
valores promedio del Retardo de Configuración de Llamada (Call Setup Delay -
CSD) y del Retardo de Desconexión de Llamada (Call Disengagement Delay - CDS)
sobre escenarios diferentes. En [34] se evalúan los retardos en un escenario
multidominio IMS, ya que se busca corroborar en simulación un modelo
anteriormente elaborado desde el punto de vista analítico para interconexión de
dominios IMS, partiendo de la premisa de que el encolamiento es de tipo M/G/1. En
[35] se evalúan los retardos para un escenario de un solo dominio, pero el
encolamiento se asume de tipo-fase (Phase-Type) PH/PH/1, y se contrasta con
modelos analíticos elaborados sobre escenarios donde el encolamiento es M/G/1 y
G/G/1 en trabajos anteriores de los mismos autores. Esto muestra que aún es de
gran actualidad contrastar modelos analíticos con modelos de simulación centrados
en los esquemas de encolamiento, para ver cual se aproxima más a la realidad del
tráfico IMS.
2.3.6 Síntesis
La figura 2.7 muestra una síntesis jerárquica de los problemas abordados en los
trabajos relacionados. De abajo hacia arriba, un problema inferior es causa del
problema que le sucede hacia arriba; En sentido contrario, un problema superior es
consecuencia del problema inmediatamente debajo de él.
El problema central que se pretende resolver es la necesidad de actualizar y
profundizar la evaluación de desempeño de Arquitecturas de servicios multimedia
convergentes, generando un modelo de tráfico adaptado, una síntesis de métricas
de rendimiento y unos resultados de desempeño para la toma de decisiones en
materia de diseño de red IMS.
28
Figura 2-7: Árbol de problemas
2.4 Marco de Referencia
En esta sección se hará una revisión de los aspectos metodológicos que acotan
esta investigación y define sus alcances. En la primera parte se abordan aspectos
relativos a la simulación que son definitivos en la formulación del modelo de tráfico.
En la segunda parte se presentan algunos aspectos relativos al simulador que es
importante tener en cuenta a la hora de implementar los escenarios de simulación.
2.4.1 Simulación por eventos discretos
Los ingredientes esenciales de una simulación son [36]:
a. Modelo matemático del sistema físico que se quiere representar
b. Estados del modelo
c. Tiempo en el cual estos estados cambian
29
El modelo dicta, determinística o estocásticamente, la transición de los estados de
simulación basada en estados previos y en condiciones iniciales y entradas
establecidas.
La simulación por eventos discretos consiste en la formulación de transiciones de
estado como una secuencia de eventos que ocurren en “puntos” discretos en el
tiempo. Aunque el tiempo es una variable continua, la simulación por eventos
discretos lo asume como una variable discreta, debido a que el tiempo continuo es
muy difícil de simular y la lógica de computación del ordenador donde corre el
simulador es esencialmente discreta. Adicionalmente, las redes basadas en
conmutación de paquetes tienen un comportamiento basado en eventos que
ocurren en instantes de tiempo, lo cual hace que en un sistema como IMS, en donde
los servicios multimedia se comparten sobre redes de conmutación de paquetes, el
tiempo se pueda modelar como una variable discreta.
La simulación de eventos discretos nace de la teoría de sistemas de eventos
discretos, la cual es un marco conceptual matemático rigurosamente definido; en
este trabajo no se va a abordar a profundidad dicha teoría porque se sale de su
propósito y porque en su aplicación práctica se simplifica significativamente [37].
Para el tiempo, se deben tener en cuenta dimensiones diferentes de esta variable
que son referencia dentro de la simulación. Por un lado, está el tiempo físico, que
es el tiempo real del mundo físico, que por lo general es medido por el ordenador
en el formato que se requiera; por otro lado, está el tiempo de reloj (Wall-Clock time),
que es el tiempo medido que transcurre durante la simulación y es independiente
del tiempo físico; por último, está el tiempo de simulación, que es la representación
del tiempo físico dentro de la simulación. En este último caso el comportamiento es
muy peculiar, ya que el tiempo de simulación no se incrementa con base en un
periodo de tiempo regular, sino que salta de un instante de tiempo al siguiente
(instantes de tiempo discretos) mientras avanza cronológicamente a través de la
secuencia de eventos. Los instantes de tiempo pueden ser mapeados en el dominio
30
del tiempo físico continuo con un tipo de dato numérico de acuerdo con la precisión
que se requiera, por ejemplo, un número de punto flotante de dos decimales.
La relación entre el tiempo de reloj y el tiempo de simulación es muy importante
para lograr que la simulación no se aleje de la realidad. Para ilustrar esto se puede
revisar un ejemplo presentado en [36]: Se supone una comunicación de un
dispositivo móvil con dos estaciones base. En la figura 2.8 se muestra el orden y los
tiempos en los que se ejecutan los eventos.
Figura 2-8: Ejemplo comunicación entre dispositivo móvil y dos estaciones base [36]
Inicia entonces el evento 1 en el tiempo tsim=0 con una comunicación entre la
estación 1 y el dispositivo móvil como si ocurriera en un instante de tiempo, así como
el evento 2 que consiste en la recepción del paquete en el dispositivo móvil después
de un retraso de propagación de 0.001 ms. El tiempo de reloj muestra que, debido
a los retardos de procesamiento del ordenador donde está el simulador
ejecutándose, el tiempo real de ejecución del primero y segundo eventos es casi
1ms. El evento 3, que es la transmisión de un paquete de la estación 2 al dispositivo
móvil arranca después de tsim=1ms, razón por la cual no hay interferencia. Sin
embargo, si el evento 3 arrancara antes, se produciría interferencia entre las dos
estaciones producto del jitter entre el tiempo de reloj y el tiempo de simulación en el
cual están programados los eventos. Por la forma en que se programaron los
eventos en este ejemplo, después de la ejecución de los 8 eventos que se muestran
en la figura no se presenta interferencia, y la sensación que se presenta en la
simulación es que cada evento se ejecutó en el instante de tiempo programado. Sin
31
embargo, no tener en cuenta el jitter que produce el procesamiento de los eventos
del simulador puede llevar a errores e imprecisiones en los resultados de
simulación.
2.4.2 Características NS-3
Lo que se hará en este trabajo es simular a través de ns-3 (que es un simulador de
eventos discretos) los eventos de recepción y envío de paquetes en cada uno de
los nodos que hacen parte del modelo de red, definido más adelante en el capítulo
3. Para esto se utilizarán tres herramientas acompasadas entre sí: el conjunto de
estados de las variables, una lista sencilla de eventos y un reloj global de simulación.
El simulador ns-3 es un simulador de eventos discretos desarrollado en los
lenguajes de programación C++ y Python. Está compuesto por un considerable
número de clases que se instancian de acuerdo con la necesidad de la simulación,
con la siguiente clasificación:
� Las clases de Red se instancian para el diseño de la red que se quiere simular,
encontrando aquí clases para crear nodos (Nodes), interfaces (Devices), enlaces
(Channels), paquetes (Packets), colas (Queues), sockets, protocolos, entre otros
elementos de red comunes.
� Las clases de Core se instancian para aspectos claves de la simulación, tales
como punteros inteligentes, variables aleatorias, eventos, tiempo de simulación,
Trazado (Tracing), Callbacks para capturar métricas de simulación, programadores
(Schedulers), atributos para los elementos de red (Attributes, fundamentalmente
para elementos de red que heredan de la clase Object), entre otros.
� Las clases de Aplicación se instancian para crear aplicaciones que intercambian
los paquetes de acuerdo con lo que se quiera simular.
� Las clases de Protocolo se instancian para instalar protocolos de red ya
definidos en ns-3 en los nodos respectivos.
32
� Las clases Helper que se instancian para evitar que ciertas clases sean
implementadas o instanciadas directamente, facilitando la labor del programador y
evitando errores que puedan afectar el core.
� Las clases Mobility que se instancian cuando se requiere aplicar en la simulación
un modelo de movilidad para alguno de los nodos (sobre todo si son redes
inalámbricas).
� Otras clases que no tienen relevancia para el objeto del presente trabajo.
Adicionalmente, el simulador cuenta con un módulo para implementar LTE [38],
desarrollado por el proyecto LENA del Centro Tecnológico de Telecomunicaciones
de Catalunya (Centre Tecnològic de Telecomunicacions de Catalunya - CTTC),
del cual se usará la parte relacionada con el EPC (Evolved Packet Core). En la
figura 2.9 se pueden observar las partes de LTE que se pueden implementar con
este módulo del simulador.
Figura 2-9: Componentes LTE en el proyecto LENA [38]
33
Otra característica importante a tener en cuenta de ns-3 es que solo tiene
implementados protocolos de capa 1 (física) a capa 4 (transporte). Cualquier
protocolo de capa superior funciona como una aplicación. En este caso, toda la
lógica que comprende añadir y remover cabeceras SIP se hace mediante una
aplicación que hereda de la clase Application, que se encarga de determinar qué
decisiones toma cada nodo cuando recibe un paquete (sea una solicitud o una
respuesta), si lo reenvía, si modifica sus cabeceras, si lo descarta, etc.
Las cabeceras SIP tienen la característica de ser cadenas de texto (String), lo cual
lo hace un protocolo fácil de leer. Es así como para las cabeceras se definió en el
simulador unas clases que heredan de la clase Header, las cuales consisten
fundamentalmente en la gestión de estas cadenas de caracteres con longitud
dinámica.
34
3. MODELOS PARA LA EVALUACIÓN DE DESEMPEÑO
3.1 Modelo de red para la evaluación de desempeño
La primera pregunta que se debe responder es ¿Qué debe ser sometido a una
evaluación de desempeño? De forma general se ha dicho que se busca aquí evaluar
los componentes de una red de servicios convergentes, pero en detalle, se busca
también hacerlo sobre la base de la evolución de las arquitecturas hasta ahora
diseñadas para proveer este tipo de servicios. Al mismo tiempo es necesario evaluar
los componentes IMS, donde vale la pena revisar la conveniencia de implementar
algunas de las funcionalidades en nodos individuales o agruparlas, con base en
estudios anteriores sobre este tema también.
Como ya se ha expresado, la versión más evolucionada de las arquitecturas
definidas por 3GPP es VoLTE, luego el modelo de red aquí propuesto se basa en
esta arquitectura, combinando componentes IMS con los de SAE (System
Architecture Evolution) y los de E-UTRAN (Enhanced UMTS Terrestrial Radio
Access Network). La figura 3.1 muestra la red propuesta.
En el modelo se incluyen estas tres partes, adicionando un servidor “Asterisk” que
hace las veces de red de telefonía empresarial, pero que en el simulador
simplemente es un servidor que va a generar las solicitudes y respuestas
correspondientes de acuerdo con el plan de simulación. Esto tiene aplicaciones
reales en el mundo comercial hoy en día, donde una empresa u organización puede
necesitar comunicarse con uno de sus miembros que se encuentra fuera del alcance
35
de la red telefónica empresarial, pero que puede ser ubicado a través de su teléfono
celular.
Figura 3-1: Modelo de red
3.2 Modelo de tráfico
Haciendo un análisis inicial sobre la arquitectura VoLTE, se puede ver como se erige
sobre un entramado de servidores que toman las solicitudes (request) y las
respuestas (responses) para hacer una operación sobre ellas, operaciones que van
desde un simple reenvío (fowarding) hasta la toma de decisiones sobre el contenido
del paquete. Por esta razón, teniendo en cuenta la teoría clásica de teletráfico, se
puede afirmar que este tipo de sistemas se puede modelar como una red abierta de
colas (Open Queueing Network). Para ampliar la información sobre el
funcionamiento de estas redes, se puede consultar en [39]. Este razonamiento fue
aplicado en [40], trabajo en el cual se buscaba aplicar mecanismos de clasificación
y priorización de mensajes SIP sobre una red IMS, con el fin de descongestionar la
red; se aplica un algoritmo que agrupa los mensajes menos sensibles al retardo,
con sensibilidad mediana y los más sensibles, para después darles prioridad en el
encolamiento. En este trabajo se parte de una aproximación similar, pero en vez de
aplicar mecanismos de priorización, se analizan los componentes IMS en conexión
con los de LTE como una red abierta de colas. Se parte de premisas como que todo
el tráfico que va desde cualquier componente de IMS hacia los usuarios UE, debe
36
pasar por el P-CSCF. Además, todo el tráfico de señalización debe pasar por el S-
CSCF.
Figura 3-2: Modelo de Tráfico
En este trabajo, a diferencia de [40], si se tuvo en cuenta el HSS como un servidor
con su respectiva cola. La disciplina de todos los servidores es FIFO (como no se
tiene en cuenta QoS, no se usa PQ ni ninguna otra disciplina). Por ahora en términos
analíticos se parte de que las colas con M/M/1/N con buffer finito.
En la figura 3.2, los puntos entre las colas marcan la división de los flujos de salida
y la confluencia de flujos de paquetes de entrada. Así como se marcan flujos hacia
adelante (de derecha a izquierda), también se hace en sentido contrario, ya que
todos los servidores generan respuestas hacia los UEs. Las ecuaciones de balance
locales llevan a expresiones para el Throughput de la siguiente forma [39]:
1 01 21 2pθ λ θ= + (1) 2 12 1 32 3
p pθ θ θ= + (2)
3 23 2 43 4p pθ θ θ= + (3) 4 34 3 54 5 4h h
p p pθ θ θ θ= + + (4)
5 45 4 02pθ θ λ= + (5) 4 4h h
pθ θ= (6)
Como se puede observar en la figura 3.2, la variable λ01 representa la tasa de
paquetes que vienen de los UEs, mientras que λ02 representa la tasa de paquetes
37
que vienen de la central Asterisk. Deben incluirse ambas para lograr representar la
posibilidad de salidas de peticiones desde ambos extremos, así como el tráfico que
se genera por la generación de respuestas.
Es necesario utilizar herramientas software para encontrar las soluciones para el
anterior sistema de ecuaciones. A modo de ilustración, se presenta acá la solución
para el Throughput de la cola 1, que corresponde al eNB, así como la cola 4, que
corresponde al servidor S-CSCF:
�� =
−(−��� + ������� + ���� � − ������� �� + ��� �� − ������� �� +
��� �� − ������� �� )
(1 − ���� − ���� − � � + ����� � − �� + ���� �� + ���� �� −
�� + ���� �� + ���� �� )
� =−(−�������� − ���� + �������� + �������� )
(1 − ���� − ���� − � � + ����� � − �� + ���� �� + ���� �� −
�� + ���� �� + ���� �� )
Para los Throuhgput de todas las colas se pueden encontrar expresiones similares
a esta, en función de las probabilidades Pij de que un paquete vaya de la cola i a la
j. Al someter este sistema de ecuaciones a la herramienta Mathematica 10.1 Student
Version, asumiendo valores aleatorios para las probabilidades Pij, se obtuvieron las
siguientes expresiones para los throughputs de cada cola en función de la tasa de
llegadas de paquetes al sistema ���:
�� → 1.665��� + 0.333���
�� → 1.333��� + 0.666���
�� → 1.0 ��� + 1.0 ���
� → 0.762��� + 1.524���
�� → 0.333��� + 1.667���
�� → 0.0952��� + 0.1904���
El comportamiento de estos Throughputs en función de ��� y ��� se puede observar
en la figura 3.3. Es importante tener en cuenta que estos resultados son meramente
ilustrativos, ya que posteriormente en la simulación estos resultados podrían tener
otro comportamiento.
38
Figura 3-3: Throughput vs Tasa de paquetes que ingresan a la red
Esta gráfica nos muestra como el throughput se comporta como una rampa en un
espacio de 3 dimensiones. La rampa naranja corresponde a la cola 1, la cual obtiene
mayores valores de throughput cuando aumenta el tráfico desde los UEs. La rampa
azul corresponde a la cola 2 (P-GW), la roja a la 3 (P-CSCF) y la verde a la cola 4
(S-CSCF). La cola 5 tiene un comportamiento muy similar a la cola 1, solo que crece
en sentido contrario (es decir, obtiene mayores valores de Throughput cuando se
incrementa el tráfico desde la central Asterisk); por motivos de ilustración, no se
muestran en la figura la cola 5, por ser de comportamiento similar a la cola 1, ni la
cola 6, por tener valores demasiado bajos. La cola 4 es la que presenta los mayores
valores de Throughput para una buena parte del dominio de valores para ��� y ���,
debido a que es la cola que más tráfico recibe para los diferentes valores de las
tasas de ingreso de paquetes a la red. Sin embargo, sus valores de Troughput
dependen más del incremento del tráfico desde la central Asterisk que desde los
UEs.
El comportamiento que se ve en la gráfica se aproxima al comportamiento obtenido
en el proceso de simulación, donde se pudo observar que el nodo que más tráfico
concentra es el S-CSCF.
39
4. IMPLEMENTACIÓN DE LA SIMULACIÓN
4.1 Implementación del modelo de red
Como se mencionó en secciones anteriores, se utilizó la herramienta ns3 para
simular el modelo de red presentado en la sección 3.1. El simulador ns3 es un
conjunto de clases que se pueden instanciar a través de scripts en C++ para montar
la simulación. Todos los parámetros de la simulación son definidos en dichos scripts,
los valores que deben asumir los atributos de los componentes de red, si estos
valores son variables aleatorias o determinísticas, etc.
Teniendo esto en cuenta, se construyeron unas nuevas clases en C++ y un script
central que contiene toda la configuración y los pasos que debe seguir el simulador
ya en tiempo de simulación.
Las nuevas clases creadas fueron:
1. Una clase SipHeader, derivada de la clase Header de ns3, la cual tiene como
característica principal que maneja un buffer de caracteres de longitud dinámica.
Esto debido a que las cabeceras SIP viajan en los paquetes en texto plano
legible y sus longitudes son indeterminadas, luego era necesario crear una clase
con estas características.
2. Dos clases App, derivadas de la clase Application del simulador, las cuales se
encargan del envío y recepción de los paquetes entre los nodos. En estas clases
también se definen métodos para crear los requests y los responses (DoInvite,
DoAck, Do200Ok, etc.).
40
3. Por último está el script central que se basa en un ejemplo incluido en el
simulador, llamado lena-simple-epc.cc, el cual contiene los parámetros de
configuración de la red LTE y los módulos EPC. Partiendo de este ejemplo, se
complementó con la creación y configuración de los nodos IMS, los sockets que
comunican esos nodos para el intercambio de paquetes y todos los recursos
para realizar la captura de datos relacionados con el desempeño de la red.
Adicionalmente se usó la herramienta NetAnim, que es complemento del simulador,
que sirve para visualizar la ubicación de los nodos, sus conexiones y algunos datos
de simulación.
El módulo LTE del simulador incluye la posibilidad de simular los enlaces de radio
entre los UEs (User Equipments) y los eNBs (Enhanced Node B), asume que el S-
GW (Serving SAE Gateway) y el P-GW (Packet Data Network Gateway) están en
un mismo nodo, simula los enlaces S1-u entre los eNBs y el S/P-GW y además
instala los protocolos TCP/IP en los UEs.
Tal como en el modelo de red definido en el capítulo 3, en un extremo de la red se
ubican los UEs y al otro extremo se ubica un nodo Asterisk como destino. La idea
de esto es simular una comunicación entre la red celular LTE y una central telefónica
empresarial.
Una de las ventajas del simulador es que puede simular la implementación de UEs
de acuerdo con los escenarios que se requieran. Además podría escalarse a la
implementación de varios nodos para el core IMS (varios P-CSCF, varios S-CSCF),
tal como ocurre cuando la red se escala a millones de usuarios.
En el anexo se hace una aproximación más detallada al código, donde se pueden
observar las clases y objetos implementados, las librerías utilizadas, entre otros
detalles relevantes de la simulación.
A través de NetAnim, se puede ver la red de la siguiente forma, en un escenario
básico con solamente 2 eNBs y 3 UE por cada eNB.
41
Figura 4-1: Implementación en NetAnim
4.2 Resultados de simulación
Para la simulación se tuvieron en cuenta tres trayectos, descritos en la figura 4.2,
4.3 y 4.4. El primer trayecto mide el tiempo que toma una petición Invite (un usuario
quiere iniciar sesión con otro) en llegar hasta el destino sumado al tiempo que toma
la respuesta provisional 180 Ringing (El cliente accionó un mecanismo local de
ringing) en llegar al inicio.
42
Figura 4-2: Trayecto I
El segundo trayecto mide el tiempo desde la salida de una respuesta 200 Ok (el
cliente que recibe la llamada contesta, generando la respuesta 200 OK) y la llegada
de regreso de una petición ACK (la cual, a pesar de ser una petición, actúa como
Aknowledgement, como un notificador).
Figura 4-3: Trayecto II
43
El tercer trayecto mide el tiempo desde la salida de un mensaje Bye (el extremo o
UE que envía este mensaje quiere terminar la sesión) y la respuesta 200 Ok que
cierra el flujo multimedia.
Figura 4-4: Trayecto III
Uno de los aspectos importantes de ns-3 es el tiempo de simulación y la gestión de
los eventos. El simulador tiene una clase que se encarga de programar los eventos
y organizar su ejecución en el tiempo, con el método Schedule de la clase Simulator.
Este método recibe como parámetro el “Offset” de tiempo que transcurre entre el
momento actual de tiempo de simulación (es decir el tiempo que marca el reloj de
simulación en el momento en que es llamada la función) y el tiempo en el cual el
usuario requiere que se ejecute el evento. Es importante tener en cuenta que ns-3
simula el tiempo como si fuera continuo, pero en verdad es un simulador de tiempo
discreto con resolución de nanosegundos, en el cual el asigna el tiempo de
ejecución de un evento de acuerdo con lo que se configure en los scripts. Por
ejemplo, si un nodo recibe un paquete y se ejecuta un reenvío de ese paquete en
el mismo momento en que se recibió (como si no hubiera pasado el tiempo entre la
recepción del mensaje y su reenvío), en los tiempos de simulación se va a ver
44
reflejado de esta forma, aunque en términos reales el simulador haya tomado unos
milisegundos de tiempo real en procesar esta instrucción.
Un primer escenario que se planteó fue una red donde los servidores (nodos)
reciben los paquetes, los procesan y los reenvían en el mismo instante de tiempo
en que los reciben, usando Simulator::ScheduleNow(), o con un retardo fijo muy
bajo, cercano a cero. Este escenario permite medir los retardos que genera el viaje
de los paquetes a través de los enlaces, sumado a los retardos que genera el paso
por la red LTE.
Para este escenario se implementaron 3 UEs, dos conectados a un eNB1, mientras
el otro se conecta a otro eNB2. Dos de estos envían Invites (Sesión 1 y 3), el tercero
(Sesión 2) recibe un Invite desde la central. En la tabla I se muestran los tiempos en
milisegundos que toma enviar una petición y recibir una respuesta:
Tabla 4-1: Retardos (milisegundos) de las sesiones por trayectos
Trayectos Sesión 1 Sesión 2 Sesión 3
Salida Invite hasta llegada de 180 Ringing 124 129.93 115
Salida del 200 OK hasta llegada de ACK 96.98 97 96.98
Salida de Bye hasta llegada de 200 OK 98 79 97
Para un segundo escenario de simulación se implementó un retardo en los
servidores que simula el tiempo de procesamiento de los paquetes (tiempo de
servicio), el cual se generó como una variable aleatoria exponencial. Para este caso
se implementaron 6 UEs con 2 eNBs, donde 3 UEs envían los Invites (sesiones 1,
3 y 4), mientras los otros 3 reciben los Invites (sesiones 2, 5 y 6). La tabla 4.2
muestra los tiempos en los mismos trayectos cuando el tiempo de servicio en cada
servidor es una variable aleatoria exponencial con media de 100 milisegundos,
mientras la tabla 4.3 muestra los resultados para un tiempo de servicio como
variable aleatoria exponencial con media de 200 milisegundos:
45
Tabla 4-2: Retardos (ms) con tiempo de servicio exponencial de media 10 milisegundos
Trayectos Sesión 1 Sesión 2 Sesión 3 Sesión 4 Sesión 5 Sesión 6
Trayecto 1 315 226.53 330 309 318.77 285.63
Trayecto 2 125.95 139.72 189.83 164.96 241.11 187.28
Trayecto 3 139 179 164 153 180 174
Esta información se puede observar en la figura 4.5:
Figura 4-5: Retardos en milisegundos con tasa de servicio 10 milisegundos
Tabla 4-3: Retardos (ms) con tiempo de servicio exponencial con media 20 milisegundos
Trayectos Sesión 1 Sesión 2 Sesión 3 Sesión 4 Sesión 5 Sesión 6
Trayecto 1 713 514.14 669 651 595.8 607.09
Trayecto 2 286.85 308.03 217.67 254.77 215.47 157.35
Trayecto 3 181 144 239 255 244 233
315
226.53
330309
318.77
285.63
125.95139.72
189.83164.96
241.11
187.28
139
179
164 153
180 174
0
50
100
150
200
250
300
350
Sesión 1 Sesión 2 Sesión 3 Sesión 4 Sesión 5 Sesión 6
Trayecto 1 Trayecto 2 Trayecto 3
46
Esta información se puede observar en la figura 4-6:
Figura 4-3: Retardos en milisegundos con tasa de servicio 20 milisegundos
En estas tablas se puede observar el cambio drástico que se presenta cuando se
aumenta la media de las variables aleatorias exponenciales. Al comparar los
retardos pro trayecto en las tablas 4.1, 4.2 y 4.3, se puede observar como al
aumentar la media del tiempo de servicio en servidores de casi cero a 10
milisegundos, se aumentan los retardos de extremo a extremo en aproximadamente
un 150%, mientras que cuando se pasa de una media de 10 milisegundos a una
media de 20 milisegundos, los retardos se incrementan en aproximadamente un
126%, sobre todo para los trayectos que incluyen la petición Invite. Esto lleva a
pensar que, en caso de que aumente mucho el tráfico, los retardos generados por
el tiempo de servicio en servidores pueden afectar seriamente el desempeño de la
red.
Los tiempos de la tabla 4.3 son fuertes candidatos a activar mecanismos de
confiabilidad del protocolo SIP, que consisten en el reenvío de peticiones cuando
no se obtiene respuesta en un intervalo de tiempo determinado. Este escenario
713
514.14
669651
595.8 607.09
286.85308.03 217.67 254.77 215.47
157.35181
144
239255
244 233
0
100
200
300
400
500
600
700
800
Sesión 1 Sesión 2 Sesión 3 Sesión 4 Sesión 5 Sesión 6
Trayecto 1 Trayecto 2 Trayecto 3
47
debe evitarse ya que aumentan la congestión en el sistema. Está discusión será
abordada en la siguiente sección.
Hasta ahora solo se han abordado los retardos por trayectos. Otra métrica relevante
es el promedio de ocurrencia de transiciones entre nodos, es decir, la probabilidad
de que un paquete salga de un nodo y pase a otro.
Tabla 4.4: Cantidad de transiciones entre nodos contiguos, 6 UEs
Transición de paquetes Cantidad Promedio
De UE a PCSCF-L 21 0.11666667
De PCSCF-L a UE 21 0.11666667
De PCSCF-L a SCSF 21 0.11666667
De SCSCF a PCSCF-L 21 0.11666667
De SCSCF a HSS 6 0.03333333
De HSS a SCSCF 6 0.03333333
De SCSCF a PCSCF-R 21 0.11666667
De PCSCF-R a SCSCF 21 0.11666667
De PCSCF-R a Central 21 0.11666667
De Central a PCSCSF-R 21 0.11666667
TOTAL 180 1
La tabla 4.4 consolida el número de transiciones entre paquetes cuando se tienen
los 6 UEs y tres de ellos envían Invites (hacen petición para iniciar la sesión),
mientras los otros 3 reciben Invites de la central (responden a una petición de inicio
de sesión). El proceso de establecimiento de sesión más la transacción del BYE
para finalizarla, comprende 3 peticiones y 4 respuestas, que atraviesan los nodos
de acuerdo con lo que cada uno debe hacer sobre el paquete. Los HSS solo reciben
paquetes del S-CSCF y responden al mismo cuando el S-CSCF recibe un Invite, ya
que debe consultar datos de usuario, por eso siempre el número de transiciones
desde y hacia el HSS será mucho más bajo. Por otro lado, el hecho de que sea un
número par de UEs donde la mitad hace peticiones iniciales hacia la central y la otra
mitad las recibe de la central, hace que se equilibre el número de transiciones y se
48
presente una especie de distribución uniforme en las transiciones de paquetes entre
los nodos. Sin embargo, este es apenas un escenario posible entre muchos, por lo
cual en la tabla 4.5 se muestra, como ilustración, la pequeña diferencia que se
presenta cuando el número de UEs se reduce a 5 (un número impar).
Tabla 4-5: Cantidad de transiciones entre nodos contiguos, 5 UEs
Transición de paquetes Cantidad Promedio
De UE a PCSCF-L 18 0.12
De PCSCF-L a UE 17 0.11333333
De PCSCF-L a SCSF 17 0.11333333
De SCSCF a PCSCF-L 18 0.12
De SCSCF a HSS 5 0.03333333
De HSS a SCSCF 5 0.03333333
De SCSCF a PCSCF-R 17 0.11333333
De PCSCF-R a SCSCF 18 0.12
De PCSCF-R a Central 17 0.11333333
De Central a PCSCSF-R 18 0.12
TOTAL 150 1
Entre más dispar sea la relación entre UEs que envían Invites y que reciben Invites,
más va cambiando la probabilidad de cada transición. A pesar de esto, mientras
predominen peticiones y respuestas que atraviesan casi todos los nodos, como las
usadas en este trabajo, la distribución de esas probabilidades de transición se
acerca mucho a una distribución uniforme. Dentro del protocolo SIP e IMS existen
otro tipo de peticiones y respuestas que no necesariamente atraviesan todos los
nodos de extremo a extremo, así como escenarios más complejos en los que, al
usarse varios SCSCF o varios HSS (no uno solo como en esta simulación), los flujos
de tráfico también se vuelven más complejos.
49
5. EVALUACIÓN Y DISCUSIÓN DE RESULTADOS
Como se vio en el capítulo 2, en [32] se plantea que el desempeño de los servidores
SIP se degrada durante los tiempos de sobrecarga debido a los mecanismos de
retransmisión SIP. Cuando se utiliza el protocolo TCP para el transporte, los
mecanismos de retransmisión SIP no se activan, ya que TCP se encarga de la
retransmisión adecuada cuando se presenten problemas de pérdida de paquetes,
ya que es un protocolo orientado a la conexión; por otro lado, cuando se usa UDP,
se activan los mecanismos de retransmisión SIP para enfrentar la pérdida de
paquetes. Esto asegura algo muy importante para SIP, como es la certeza sobre la
llegada de las peticiones y las respuestas, pero tiene como contraparte la
sobrecarga de la red con más paquetes. En la simulación presentada, las
condiciones de los escenarios de simulación no dieron pie a la necesidad de activar
los mecanismos de retransmisión (a pesar de que se usó UDP), debido a que eran
pocos UEs. Sin embargo, en la tabla 4.2 del capítulo 4 se pudo observar como los
retardos de extremo a extremo (End-to-End) sugieren que en algunos casos si
habría esa necesidad, lo cual genera una degradación creciente del desempeño del
sistema, como se describe en [32].
Como también se mencionó en la sección 2.3.3, ha habido fuertes esfuerzos por
incrementar la capacidad de las redes IMS, como se observó en los trabajos [20] a
[23]. Con estos esfuerzos por mejorar el desempeño de los componentes IMS, se
puede pensar que la posibilidad de tener tiempo de servicio en servidores de 200
milisegundos no sería muy común en la práctica, lo cual mejora ostensiblemente el
desempeño del sistema y permite que se puedan implementar más UEs para la
50
misma red. A esto se suma que con las tecnologías de hoy se puede tener
servidores cuyo comportamiento es equivalente al de uno con buffer infinito, como
se aborda en [24 y [25]. Para NS-3, el tamaño máximo de una cola, por defecto, es
de 100 paquetes, pero se pueden lograr otras configuraciones.
Otras investigaciones insistieron en evaluar el desempeño de sistemas IMS con
varias redes de acceso (sistemas híbridos), tal como se mencionó en el capítulo 2
sobre [26]. El uso de una herramienta como NS-3 permite que se pueda alternar la
simulación presentada en este trabajo con otras como las combinadas en [26] y una
central como la que se propone aquí, para mejorar los resultados
Finalmente, en [40] se propone un modelo de red abierta de colas similar al
propuesto en la sección III. En [39] se explica en detalle las premisas teóricas sobre
las cuales se basan este tipo de modelos, donde se pueden ubicar entre otras:
1. El enrutamiento a través de la red es aleatorio
2. La fuente (source, que en este caso serían los extremos que traten de iniciar
sesión enviando peticiones Invite) produce tráfico con distribución Poisson
con tasa constante λ
3. El tiempo de servicio en todas las colas son variables aleatorias
exponenciales aleatorias independientes, con tasa (media) µi.
Tratar de modelar el tráfico SIP bajo estas premisas no parece muy apropiado. El
enrutamiento sólo es aleatorio cuando hay un alto número de peticiones para
establecimiento de sesión, donde es muy aleatoria la relación entre Invites enviados
en una dirección (de derecha a izquierda) con respecto a la dirección contraria. El
tráfico producido por la fuente es Poisson solo para los paquetes de las peticiones
Invite, pero no aplica para las respuestas ni para las peticiones subsecuentes a una
Invite, porque no se cumple la condición memoryless de la distribución Poisson. De
hecho, la probabilidad de que un paquete pase de un nodo a otro puede estar
relacionada o condicionada por el hecho de que hay una petición en curso, o porque
se produjo una transición hacia el nodo de donde parte el paquete.
Por estas razones se puede proyectar la necesidad de elaborar modelos de tráfico
que se acerquen más a la realidad de las redes dominadas por tráfico SIP.
51
6. CONCLUSIONES Y TRABAJO FUTURO
En este trabajo se presenta un modelo de tráfico para la arquitectura VoLTE, la cual
es hoy en día la arquitectura por excelencia para el despliegue de servicios
multimedia convergentes. Partiendo de un modelo de red, se somete a simulación
el modelo de tráfico propuesto, buscando contrastar los resultados en tiempo y en
comportamiento del tráfico con el modelo propuesto. Como resultado principal se
pudo observar como al aumentar la media del tiempo de servicio en servidores de
casi cero a 10 milisegundos, se aumentan los retardos de extremo a extremo en
aproximadamente un 150%, mientras que cuando se pasa de una media de 10
milisegundos a una media de 20 milisegundos, los retardos se incrementan en
aproximadamente un 126%, sobre todo para los trayectos que incluyen la petición
Invite. Esto lleva a pensar que, en caso de que aumente mucho el tráfico, los
retardos generados por el tiempo de servicio en servidores pueden afectar
seriamente el desempeño de la red, lo cual es de esperar en un tándem de colas
compuesto por un número importante de servidores que procesan los paquetes. Por
otro lado, haciendo un análisis detallado del comportamiento del tráfico, se concluye
que modelar este tipo de arquitecturas dominadas por tráfico SIP mediante una red
abierta de colas no es lo que más se acerca a la realidad del comportamiento del
tráfico, ya que hay que tener en cuenta posibles correlaciones entre las
probabilidades de transición del tráfico de un nodo a otro.
Por último, los módulos y aplicaciones SIP desarrolladas para NS-3 quedan como
base fundamental para investigaciones futuras que aborden casos como la
interconexión de diferentes dominios VoLTE, el aumento de UEs en la red (el
52
número de usuarios), entre otras muchas opciones de escenarios que se pueden
implementar sobre la base ya desarrollada en este trabajo.
Como trabajo futuro se puede ubicar la necesidad de escalar los componentes de
la red LTE para soportar la demanda de usuarios en las redes móviles actuales.
Esto puede incluir la evaluación de una red que contenga varios P-CSCF
(principalmente del lado más cercano al origen de tráfico) y varios S-CSCF. Es así
como, partiendo de la red propuesta en este trabajo, se puede buscar escalarla en
mayor cantidad de instancias de los nodos de red para evaluar el desempeño bajo
esas condiciones.
Por otro lado, se puede escalar el modelo de red aquí propuesto para la
implementación de un número más elevado de las funcionalidades planteadas en
las especificaciones de las arquitecturas de servicios convergentes.
Otra posibilidad importantísima de trabajo futuro es la evaluación de desempeño de
dos o más dominios VoLTE diferentes, lo cual de entrada implica la implementación
de funcionalidad que no se desarrolló en este trabajo por estar más allá de los
objetivos planteados. En un escenario interdominio, el papel fundamental es de los
nodos IMS especiales para tal fin.
53
A. Anexo: Código para la simulación
Preámbulo
Como ya se ha mencionado antes, NS-3 es un simulador basado en scripts, el cual
está compuesto por unas clases desarrolladas en C++ que deben ser instanciadas
para montar la simulación. En particular hay clases para instanciar objetos tipo
Nodo, Paquetes, Sockets, enlaces Point-to-Point (cableados), entre muchos otros.
Es así como, para la implementación de la simulación, se deben crear instancias de
las clases respectivas de acuerdo con el modelo y dar valor a los atributos con el fin
de establecer las configuraciones que deben tener para su comportamiento en la
red.
En el caso particular de una arquitectura VoLTE, NS-3 trae en su núcleo un
framework ya desarrollado para redes LTE, conocido como el LENA Project [23].
Sin embargo, esto no incluye los nodos IMS ni las cabeceras SIP, por lo cual fue
necesario hacer el desarrollo de los scripts necesarios para incluir estos nuevos
componentes.
Para las cabeceras SIP se creó una nueva clase heredera de Header, la cual se
utiliza para crear cabeceras y añadirlas o removerlas de los paquetes. Para
implementar el funcionamiento como tal de los componentes IMS (estructuración de
los paquetes, enrutamiento, agregación de cabeceras, entre otras) se creó una
clase heredera de Application, la cual contiene toda la lógica para el procesamiento
de los paquetes en cada nodo. Finalmente, se requiere de la organización de los
eventos en envío y recepción de paquetes para poder simular el establecimiento de
una sesión multimedia entre los User Equipments (UEs).
54
Cabeceras SIP
De acuerdo con el RFC 3261 [23] que especifica el Protocolo de Inicio de Sesión
SIP, éste es un protocolo basado en texto que utiliza el conjunto de caracteres
(Charset) Utf-8. Esto implica entonces que la unidad básica de los mensajes SIP
son caracteres de 8 bits cada uno. SIP es un protocolo de Petición-Respuesta
(Request-Response) similar a HTTP, con la diferencia que mientras en HTTP hay
un cliente y un servidor, en SIP todos los nodos (incluyendo los UEs en ambos
extremos) tienen el doble rol de ser clientes y servidores de peticiones o respuestas.
Luego, dependiendo de si el mensaje SIP enviado es una Request o una Response,
el contenido del mensaje cambia, pero fundamentalmente todas las cabeceras son
cadenas de caracteres.
Sin embargo, los paquetes en NS-3 almacenan los datos que transportan
serializados en código binario, así que el reto más importante en esta parte de la
simulación fue implementar una clase heredera de Header que al almacenar las
cabeceras en los paquetes serializara en código binario, y que al leer su contenido,
deserializara los bits a cadenas de caracteres nuevamente. La declaración se hizo
de la siguiente forma:
class SipHeader : public Header
{
public:
SipHeader ();
virtual ~SipHeader ();
void SetData (const uint8_t *data);
uint8_t GetData (void) const;
void SetSize (int m_size);
static TypeId GetTypeId (void);
virtual TypeId GetInstanceTypeId (void) const;
virtual void Print (std::ostream &os) const;
virtual void Serialize (Buffer::Iterator start) const;
virtual uint32_t Deserialize (Buffer::Iterator start);
virtual uint32_t GetSerializedSize (void) const;
private:
uint32_t size;
55
uint8_t *m_data;
};
El atributo privado m_data actúa como el buffer que almacena los caracteres de la
cabecera en forma de bytes. Se define como un puntero entero de tamaño 8 (8 bits)
y más adelante se realiza como un arreglo de tamaño dinámico con datos de este
tipo. Los métodos más relevantes son Print() y SetData, ya que en estos se
desarrollan las acciones de leer y escribir, respectivamente, los datos del Header.
Para la transformación de los caracteres en bits y viceversa, se utiliza una tradicional
y poderosa herramienta de C++ conocida como Casting:
Void SipHeader::Print (std::ostream &os) const {
const char *dato = reinterpret_cast<const char *> (m_data);
os << "\n";
for (uint32_t i=0; i<size; i++){
os << dato[i];
}
}
Void SipHeader::SetData (const uint8_t *data)
{
for (uint32_t i=0; i<size; i++){
m_data[i] = *(data+i);
}
}
Aplicaciones Como se mencionó anteriormente, la arquitectura IMS tiene como cimientos de su
construcción al protocolo SIP, que es un protocolo tipo Petición-Respuesta. Esto
implica que cada nodo debe estar en la capacidad de recibir, procesar y reenviar las
peticiones y respuestas que comparten los UEs en el proceso de establecer una
sesión SIP. Toda sesión SIP inicia con el envío de una Petición INVITE desde el UE
que quiere establecer comunicación, hacia un UE de destino. Después vienen las
56
respuestas del UE de destino que pueden ser un mensaje 180 RINGING, un 200
OK, un mensaje CANCEL o BYE para rechazar la llamada, etc.
Para esto se creó una clase que hereda de Application y que contiene los
métodos necesarios para crear los mensajes, enviarlos, recibirlos y procesarlos. Un
ejemplo de la declaración de una de estas clases es:
class AppScscf : public Application
{
public:
AppScscf ();
virtual ~AppScscf ();
static TypeId GetTypeId (void);
void Setup (Ptr<Socket> socket, Address address, Ptr<OutputStreamWrapper> stream);
void DoInvite (void);
void Do100Trying ();
void Do180Ringing ();
void Do200Ok ();
void DoAck ();
void DoBye ();
Ptr<Socket> GetSocket();
void SetTxAddress(Address address);
void SendPacket(Address inetadr);
void BindSock (Ptr<NetDevice> netdev);
void ScscfSink (Ptr<Socket> socket);
private:
virtual void StartApplication (void);
virtual void StopApplication (void);
Ptr<Socket> m_socket;
Address m_address;
Ptr<Packet> m_packet;
uint32_t m_packetsSent;
uint32_t m_packetsReceived;
bool m_running;
Ptr<OutputStreamWrapper> streamWrapper;
};
En este caso particular, el método ScsfSink() es utilizado para procesar los
mensajes recibidos, mientras SendPacket() es utilizado para reenviarlos, de
acuerdo con la decisión que tome el método ScsfSink() sobre cuál es el siguiente
salto.
57
Script de configuración
Toda simulación en NS-3 debe tener un script que contenga la implementación del
método Main(). En este método se define la configuración de todos los componentes
de la simulación. Por ejemplo, los nodos que componen la red se definen en líneas
como las siguientes:
Ptr<Node> pcscfLeft = CreateObject<Node> ();
Ptr<Node> scscf = CreateObject<Node> ();
Ptr<Node> pcscfRight = CreateObject<Node> ();
Ptr<Node> hss = CreateObject<Node> ();
Ptr<Node> destination = CreateObject<Node> ();
Ptr<Node> mediaLTE = CreateObject<Node> ();
Ptr<Node> mediaDest = CreateObject<Node> ();
La creación de los componentes de la red LTE, se definen de la siguiente forma: Ptr<LteHelper> lteHelper = CreateObject<LteHelper> ();
Ptr<EmuEpcHelper> epcHelper = CreateObject<EmuEpcHelper> ();
lteHelper->SetEpcHelper (epcHelper);
epcHelper->Initialize ();
Ptr<Node> pgw = epcHelper->GetPgwNode ();
El pgw (P-Gateway dentro de la arquitectura EPC) debe instanciarse en un objeto
aparte, extrayéndolo del núcleo LTE, debido a que este es el que se comunica con
los nodos del núcleo IMS. Después de la creación de todos los nodos de la red, se
deben crear los enlaces entre los nodos (con enlaces Point-to-Point donde van
enlaces cableados), se debe asignar direcciones IP a los nodos de forma estática,
para diferenciar los dominios de red a los que pertenece cada nodo, se deben
instalar protocolos IP en los nodos, entre otras configuraciones. Cuando se ha
comprobado que todos los nodos pueden enviar y recibir paquetes entre sí, se
procede a instalar una instancia de la aplicación en cada nodo, así como los sockets
que estarán escuchando para recibir mensajes:
AsciiTraceHelper scscfReceiver;
Ptr<OutputStreamWrapper> streamScscf = scscfReceiver.CreateFileStream
("epcPacketsScscfreceived.cwnd");
58
Ptr<Socket> slRxRqestSocket = Socket::CreateSocket (scscf, UdpSocketFactory::GetTypeId ());
slRxRqestSocket->Bind (plSinkAddress);
slRxRponsSocket->Bind (sdTxAddress);
Ptr<Socket> sdRxRqestSocket = Socket::CreateSocket (scscf, UdpSocketFactory::GetTypeId ());
sdRxRqestSocket->Bind (hlSinkAddress);
Ptr<AppScscf> slRequest = CreateObject<AppScscf> ();
slRequest->Setup (streamScscf);
scscf->AddApplication (slRequest);
slRxRqestSocket->SetRecvCallback(MakeCallback(&AppScscf::ScscfSink, slRequest));
slRxRponsSocket->SetRecvCallback(MakeCallback(&AppScscf::ScscfSink, slRequest));
sdRxRqestSocket->SetRecvCallback(MakeCallback(&AppScscf::ScscfSink, slRequest));
requestApps.Add (slRequest);
Los objetos de tipo OutputStreamWrapper sirven para capturar en archivos los
paquetes recibidos y comprobar que los mensajes llegan completos a cada nodo.
En el caso particular del S-CSCF, que recibe mensajes del P-CSCF, del HSS y del
Destino, debe tener un socket instalado y escuchando (Bind) en cada interface que
corresponde a su conexión con estos otros nodos.
Finalmente, se debe organizar la ejecución de los eventos en tiempo de simulación,
lo cual se hace de la siguiente manera:
requestApps.Start (Seconds(0.5));
Simulator::Schedule (Seconds (1.0), &AppScscf::DoInvite, ueAppInstance);
Simulator::Schedule (Seconds (1.2), &AppScscf::SendPacket, ueAppInstance, ulSinkAddress);
En este caso particular se muestra la organización de 4 eventos sencillos: el inicio
de ejecución de las aplicaciones, la configuración de un INVITE en alguno de los
UEs y su envío hacia una dirección específica. El método Start() (que es heredado
de la clase ApplicationContainer) usa por defecto el método Schedule() de la clase
Simulator, por lo cual no es necesario llamarla en este script. Por otro lado, los
otros métodos son de la clase AppScscf, por lo cual se debe usar el método
Schedule para programar la ejecución de sus métodos en el tiempo especificado.
Como último paso está la configuración del NetAnim, que se debe incluir también
dentro del Main():
AnimationInterface anim ("epcPruebaMedia-animation.xml");
AnimationInterface::SetConstantPosition (pcscfLeft, 530, 345);
anim.UpdateNodeDescription (pcscfLeft, "P-CSCF");
AnimationInterface::SetConstantPosition (scscf, 680, 345);
59
anim.UpdateNodeDescription (scscf, "S-CSCF");
AnimationInterface::SetConstantPosition (pcscfRight, 830, 345);
anim.UpdateNodeDescription (pcscfRight, "P-CSCF");
AnimationInterface::SetConstantPosition (hss, 680, 175);
anim.UpdateNodeDescription (hss, "HSS"); Con estas líneas se obtiene la ubicación de los nodos en el NetAnim tal como se
muestra en la figura 4.1.
60
BIBLIOGRAFÍA
[1] Quiza Montealegre Jhon Jair, “Modelo de red para la provisión de servicios convergentes por parte de operadores actuales de telefonía fija y/o móvil”, Tesis de Maestría, Universidad Nacional de Colombia, 2006. Disponible en http://www.bdigital.unal.edu.co/2988/#sthash.fv3XMjdI.dpuf
[2] Presidencia Española de la Unión Europea, “Una Sociedad de la Información para Todos. El Potencial de la Convergencia Tecnológica en el Desarrollo de la Sociedad de la Información”, Sevilla, 2002. p. 8-11
[3] Noldus R., Olsson U., Mulligan C., Fikouras I., Ryde A., Stille M., “IMS Application Developer’s Handbook”, Academic Press, 2014.
[4] Huidrobo, José M. “Comunicaciones móviles. Sistemas GSM, UMTS y LTE”. Editorial Algaomega. Páginas 224-225. México D.F., 2013.
[5] Abu-Lebdeh, M., Sahoo, J., Glitho, R., Tchouati, C.W. “Cloudifying the 3GPP IP
multimedia subsystem for 4G and beyond: A survey”. (2016). IEEE Communications Magazine, 54 (1), art. no. 7378432, pp. 91-97
[6] P. Agrawal, J. H. Yeh, J. C. Chen and T. Zhang, "IP multimedia subsystems in
3GPP and 3GPP2: overview and scalability issues" in IEEE Communications Magazine, vol. 46, no. 1, pp. 138-145, January 2008.
[7] Vingarzan D and Weik P (2006), "End-to-end performance of the IP multimedia
subsystem over various wireless networks", IEEE Wireless Communications and Networking Conference, 2006. WCNC 2006. Vol. 1, pp. 183-188. IEEE.
[8] A. A. Elmangosh, M. A. Ashibani and F. B. Shatwan, "Performance evaluation
of IMS multimedia telephony over wireless LANs", 2007 International Conference on IP Multimedia Subsystem Architecture and Applications, Bangalore, 2007, pp. 1-5.
[9] Balakrishna C (2009), "IMS experience centre A real-life test network for IMS
services", 5th International Conference on Testbeds and Research Infrastructures for the Development of Networks & Communities and Workshops, 2009, pp. 1-8. IEEE.
61
[10] Kellokoski J, Tukia E, Wallenius E, Hamalainen T and Naarmala J (2010), "Registration performance comparison between IP Multimedia
Subsystem and Session Initiation Protocol networks", In International Congress on Ultra Modern Telecommunications and Control Systems, October 2010, pp. 20-25. IEEE.
[11] Kellokoski J, Tukia E, Wallenius E, Hamalainen T and Naarmala J (2010), "Call
and messaging performance comparison between IMS and SIP networks", IEEE 4th International Conference on Internet Multimedia Services Architecture and Application, December 2010, pp. 1-5.
[12] Lequerica Roca I, Ruiz Ruiz AJ, Garcia Ruiz AS and Gomez Skarmeta AF (2010), "An IMS Based Vehicular Service Platform", IEEE 72nd Vehicular Technology Conference - Fall, September 2010, pp. 1-5. IEEE.
[13] Mahmood R and Azad MA (2010), "SIP messages delay analysis in
heterogeneous network", In 2010 International Conference on Wireless Communication and Sensor Computing (ICWCSC), January 2010. , pp. 1-5. IEEE.
[14] L. Saleem, R. Ghimire and S. Mohan, "An analysis of IP multimedia
subsystems for a hybrid network" 2010 IEEE 4th International Conference on Internet Multimedia Services Architecture and Application, Bangalore, 2010, pp. 1-6.
[15] Wagle SS, Doulamis N, Ade M and Ullah MG (2011), "Performance analysis
of IP Multimedia Subsystem (IMS) signaling in heterogeneous access
networks", In 2011 2nd International Conference on Wireless Communication, Vehicular Technology, Information Theory and Aerospace & Electronics Systems Technology (Wireless VITAE)., February, 2011, pp. 1-5. IEEE.
[16] R. A. Hamada, H. S. Ali and M. I. Abdalla, "Performance evaluation of a novel
IMS-based architecture for LTE-WIMAX-WLAN interworking" 2014 International Conference on Engineering and Technology (ICET), Cairo, 2014, pp. 1-6.
[17] J. Duan, C. Wu, F. Le, A. X. Liu and Y. Peng, "Dynamic Scaling of Virtualized,
Distributed Service Chains: A Case Study of IMS" in IEEE Journal on Selected Areas in Communications, vol. 35, no. 11, pp. 2501-2511, Nov. 2017.
[18] Z. Liu, J. Kim and J. O. Lee, "A model of SDN controllers supporting for
processing of flows based on the IMS," 17th Asia-Pacific Network Operations and Management Symposium (APNOMS), Busan, 2015, pp. 384-387.
[19] S. Khairi, M. Bellafkih and B. Raouyane, "QoS management SDN-based for
LTE/EPC with QoE evaluation: IMS use case" 2017 Fourth International Conference on SoftwareDefined Systems (SDS), Valencia, 2017, pp. 125-130.
62
[20] Y. Seraoui, B. Raouyane and M. Bellafkih, "An extended IMS framework with
a high-performance and scalable distributed storage and computing
system" 2017 International Symposium on Networks, Computers and Communications (ISNCC), Marrakech, 2017, pp. 1-6.
[21] O. I. Romanov, M. M. Nesterenko, L. A. Veres and Y. S. Hordashnyk, "IMS:
Model and calculation method of telecommunication network's capacity" 2017 International Conference on Information and Telecommunication Technologies and Radio Electronics (UkrMiCo), Odessa, 2017, pp. 1-5.
[22] Kellovsky, M., Baronak, I., Kavacky, M., Chromy, E., “The Optimal Sizing of
HSS Database in IMS”, 2017 Wireless Personal Communications, vol. 96, no. 4, pp. 5453-5466.
[23] Alejandro Cánovas, Miran Taha, Jaime Lloret, Jesús Tomás, “Smart resource
allocation for improving QoE in IP Multimedia Subsystems”, Journal of Network and Computer Applications, vol. 104, 2018, pp. 107-116.
[24] Jia, Y.J., Chen, Q.A., Mao, Z.M., Hui, J., Sontineni, K., Yoon, A., Kwong, S., Lau, K., “Performance characterization and call reliability diagnosis support for
voice over LTE”, Proceedings of the Annual International Conference on Mobile Computing and Networking, MOBICOM, 2015-September, pp. 452-463.
[25] Forconi, S., Vaser, M., “4G LTE architectural and functional models of Video
Streaming and VoLTE services”, International Conference on Ubiquitous and Future Networks, ICUFN, 2015-August, art. no. 7182650, pp. 787-792.
[26] M. Vaser and S. Forconi, "QoS KPI and QoE KQI Relationship for LTE VIdeo
Streaming and VoLTE Services", 9th International Conference on Next Generation Mobile Applications, Services and Technologies, Cambridge, 2015, pp. 318-323.
[27] Vargas, M., Cadena, E., “Review of Quality of Servie (QoS) mechanisms over
IP Multimedia Subsystems IMS”, Revista Científica Ingeniería y Desarrollo, Vol. 35, no. 1, 2017.
[28] B. A. Alassane and K. Karim, "An analytical jitter model in IMS network", 2016 IEEE 7th Annual Ubiquitous Computing, Electronics & Mobile Communication Conference (UEMCON), New York, NY, 2016, pp. 1-4.
[29] B. A. Alassane, K. Karim, N. I. Chervyakov, M. A. Deryabin, M. G. Babenko and M. N. Shabalina, "Jitter calculation in Core IMS," 2016 IEEE NW Russia
Young Researchers in Electrical and Electronic Engineering Conference
(EIConRusNW), St. Petersburg, 2016, pp. 112-115. [30] A. Ali, M. Alshamrani, A. Kuwadekar and K. Al-Begain, "Evaluating SIP
Signaling Performance for VoIP over LTE Based Mission-Critical
Communication Systems", 2015 9th International Conference on Next Generation Mobile Applications, Services and Technologies, Cambridge, 2015, pp. 199-205.
63
[31] D. Malas, A. Morton, “Basic Telephony SIP End-to-End Performance Metrics”, Request For Commments RFC 6076, AT&T labs, 2011.
[32] Montazerolghaem, A., Moghaddam, M.H.Y., “Design, implementation and
performance evaluation of a proactive overload control mechanism for
networks of SIP servers”, (2018) Telecommunication Systems, 67 (2), pp. 309-322.
[33] V. Hilt, E. Noel, “Design Considerations for Session Initiation Protocol (SIP) Overload Control”, Request For Comments RFC 6357, AT&T labs, 2011.
[34] Kaczmarek, S., Sac, M. “Verification of the analytical traffic model of a
multidomain IMS/NGN using the simulation model”. (2016) Advances in Intelligent Systems and Computing, 430, pp. 109-130.
[35] Kaczmarek, S., Sac, M. “Analysis of IMS/NGN Call Processing Performance
Using Phase-Type Distributions Based on Experimental Histograms” (2018) Advances in Intelligent Systems and Computing, 656, pp. 138-155.
[36] R. D. Ford, “A software testbed for simulation of cellular wireless networks”, tesis de maestría, Polytechnic Institute of New York University, 2012.
[37] J. Nutaro, Building Software for Simulation: Theory and Algorithms, with Applications in C++, Wiley, Dec. 2010.
[38] “ns-3 Model Library - LTE Models”, disponible en sitio web oficial https://www.nsnam.org/docs/doxygen/group__lte.html
[39] T. Robertazzi, Computer Networks and Systems: Queueing Theory and Performance Evaluation, 3rd Ed. New York, USA: Springer-Verlag, 2000. DOI: http://dx.doi.org/10.1007/978-1-4612-1164-8.
[40] J. B. Husic, E. Perenda, M. Hadzialic and S. Barakovic, "Performance
Modelling and Optimization of IP Multimedia Subsystem", 2013 European Modelling Symposium, Manchester, 2013, pp. 617-622.
![Restauración de arquitecturas de tierra by cedodal [Restauración de arquitecturas de tierra.pdf] (67 pages)](https://img.pdfslide.net/doc/110x75/55cf9872550346d03397b2c6/restauracion-de-arquitecturas-de-tierra-by-cedodal-restauracion-de-arquitecturas.jpg)
