ISSN 0798 1015

Vol. 40 (Nº 3) Año 2019. Pág. 16

Análisis del servicio IPTV soportado por una red WiFi

Analysis of the IPTV service supported by a WiFi network

CAMPO-Muñoz, Wilmar Y. 1; LÓPEZ, Nicolás 2; ASTAIZA, Evelio 3

Recibido: 22/08/2018 • Aprobado: 15/12/2018 • Publicado 28/01/2019

Contenido

1. Introducción

1. Introducción

El Focus Group IPTV define la Televisión sobre el protocolo IP (IPTV) como un servicio multimedia que incluye televisión, video, audio, texto, gráficos y datos repartidos sobre una red gestionable basada en IP para proveer el nivel requerido de calidad de Servicio (QoS), calidad de experiencia (QoE), seguridad, interactividad y confiabilidad  (Kawamori, 2008). IPTV se basa en la tecnología de videostreming demandando una gran cantidad de ancho  de banda el cual debe ser soportado por las redes de acceso actualmente desplegadas (D. O. Trujillo, 2016), como son las redes cableadas y las redes inalámbricas. Estas condiciones deben mantenerse hasta el usuario final  por las diferentes arquitecturas de red que se implementen para soportar el servicio de IPTV. El inconveniente principal de este  servicio es el elevado consumo de recursos necesarios para su procesado y transmisión. La evolución tecnológica ha permitido el incremento del ancho de banda de las tecnologías utilizadas para la transmisión, así como de los recursos disponibles. Sin embargo, este incremento también sucede en la parte de los usuarios debido a la alta penetración de la tecnología de videostreaming, provocando que este elevado consumo de recursos sea un factor de especial relevancia. Además, los proveedores ofrecen cada día contenidos de mayor calidad, provocando un incremento en el consumo de ancho de banda el cual debe ser soportado por las redes desplegadas a nivel de área local como son las redes WiFi.

Las redes WiFi se han convertido en la red más desplegada a nivel local en universidades, hogares y oficinas. En  (Brognara, 2016) se estimó para el 2015 una penetración del WiFi del 80% en corea del sur, entre 70 y 60% en países de Europa occidental y de un 60% en estados unidos. Así, en este artículo se presenta la construcción y validación un modelo estadístico de tráfico que permita conocer el comportamiento del servicio IPTV sobre este tipo de tecnología. Además, se presentan los métodos diseñados para la extracción de tramas de video a partir de capturas de tráfico real, la construcción de un servicio IPTV sobre una red WiFi simulada y la determinación del número máximo de clientes soportados por el servicio IPTV en una red WiFi.

Obtener un modelo del tráfico de red requiere evaluar distintos escenarios de transmisión y determinar características propias de cada escenario; estas características permiten concluir cuales son las mejores condiciones para ofrecer un servicio a través de una red de datos, de igual forma se observan las condiciones mínimas de operación y las condiciones de saturación de la red. De acuerdo a lo anterior, es posible resaltar que la información contenida en el modelo de tráfico es de carácter fundamental para planear, administrar y dimensionar una red funcional que permita conocer los requerimientos mínimos para poder desplegar el servicio de IPTV sobre una red WiFi  (Mok, 2003).

Finalmente el artículo está organizado de la siguiente forma: en la sección dos se presenta la implementación del servicio IPTV, la selección y conversión de contenido multimedia y la  experimentación con la red WiFi. En la sección tres se presenta el modelo de simulación, donde se incluye el diseños de aplicaciones para ser soportados sobre la herramienta de investigación  y los procesos de validación. En la sección 4 se presentan los resultados y análisis de la investigación. Finalmente en la sección cinco se presentan las conclusiones.

Para esta investigación, la codificación empleada en IPTV utilizó como formato de comprensión MPEG. Los codificadores MPEG producen tres tipos de tramas, también llamadas imágenes, slice o frames organizadas como un grupo de imágenes GOP (Group of Pictures) que determina el orden de las mismas. Como primer tipo se tiene las tramas intra-frame o imágenes I,  la cuales no consideran la redundancia temporal pero si consideran la redundancia espacial consiguiendo una moderada compresión, también cabe destacar que son las tramas de mayor tamaño; el segundo grupo de tramas se denomina inter-frame o imágenes P, se codifican como predicción de la imagen I o P anterior, para la codificación se tiene en cuenta tanto la redundancia espacial como temporal. El último grupo son las inter-frame bidireccionales o imágenes B, las cuales son las de menor tamaño, se codifica la imagen I o P anterior y siguiente para tener referencia en compensación y estimación de movimiento, consiguen los niveles de compresión más elevados  (Fernando Boronat Seguí, 2009).

Según la cadena de valor del servicio IPTV  (Sánchez, 2008) sobre una red WiFi es necesario contar con diferentes etapas: selección de contenido, conversión de video, despliegue de una red WiFi y consumo de video en formato IPTV. Por otra parte, el proceso de análisis y estudio de tráfico se lleva a cabo a través de procesos adicionales al servicio. Las etapas de análisis de tráfico son: capturar las trazas de tráfico, filtrar las tramas del GOP, encontrar la función de distribución de probabilidad que permita caracterizar cada una de las tramas que componen el tráfico IPTV, modelar el sistema mediante procesos  de simulación, validarlo y extrapolarlo a escenarios complejos.

2.1. Selección y conversión de contenido multimedia

La diversidad en las características del contenido multimedia es un factor importante para modelar un escenario IPTV, donde un usuario o cliente consumirá videos de múltiples características de manera aleatoria. Para simular este ambiente de características aleatorias, se utilizaron siete videos de 30 segundos cada uno con diferentes características como las mostradas en la Tabla 1.

El conversor de video y audio elegido fue FFmpeg por ser de carácter libre y a diferencia de cualquier otro conversor permite control total a nivel de configuración, mediante líneas de comando, de todos los parámetros del contenido multimedia a ser transmitido por IPTV  (H. Zeng, 2016).

La conversión de los videos con FFmpeg requirió el diseño de dos scripts, encargados de generar los videos en definición estándar SDTV (Standard Definition Television) y alta definición HDTV (high definition television). Los scripts utilizados en la conversión de videos se observan en la Figura 1. Los scripts crean contenido con formato de IPTV, este formato establece que las tramas I aparecen cada 12 imágenes, a esto se le conoce como tamaño del GOP, mientras las tramas predictivas imágenes P, aparecen cada dos imágenes bidireccionales (Fernando Boronat Seguí, 2009). Cabe resaltar que en la conversión se especificó el tamaño del búfer en un valor de dos segundos para un buen funcionamiento del streaming en el servicio IPTV, con esto se evita que el cliente se encuentre sin datos durante la reproducción del video. Los videos se almacenan en un contenedor Transport Stream (.ts), los contenedores en los que se guarda la multimedia son archivos que pueden almacenar video, audio, imagen o subtítulos en un mismo archivo.

Tabla 1
Resumen de características del contenido multimedia

-----

Figura 1
Scripts para la conversión de videos con FFmpeg

2.2. Experimentación con la red WiFi

La red de distribución de datos es una red WiFi, la cual opera con los protocolos de comunicación inalámbrica IEEE 802.11 b/g. Como servidor de video se utilizó Live555MediaServer ya que es capaz de soportar el contenedor multimedia .TS. Para la captura de tráfico se utilizó el analizador de protocolos Wireshark, el escenario básico IPTV se observa en la Figura 2.  Para visualizar los datos de manera correcta en Wireshark es necesario conocer la cabecera del protocolo de transporte en tiempo real RTP (Real Time Transport Protocol) donde especifica la carga. Esta cabecera lleva un espacio de siete bits para especificar el tipo de dato que carga en el paquete. En este artículo se utilizó el tipo de datos MPEG-2, de esta forma se especifica el códec de video con el que se realiza el experimento. Para los datos con el códec MPEG-2, se utiliza el número RTP = 33 en el espacio de carga dinámica. Así, los paquetes fueron interpretados inmediatamente como MPEG TS.

Figura 2
Escenario básico WiFi para IPTV

La caracterización se realiza con datos capturados en el escenario real, cada video es caracterizado por seis funciones de distribución de probabilidad (FDP), correspondientes a los tipos de tramas (I, P, B), tres FDP representan el comportamiento del tamaño de las tramas y los otros tres representan los tiempos relativos de aparición de una trama. Las seis variables de los modelos no son representadas, necesariamente, por la misma FDP, cada distribución varía dependiendo de la información de los datos muestreados y son únicas para cada video; cabe resaltar que estos modelos están validados mediante la prueba de bondad y ajuste de Kolmogorov-Smirnov con un nivel de confianza del 95 %, la prueba se aplicó  para obtener los modelos estadísticos de 14 videos.

2.3.  Extracción de imágenes

El filtro usado en Wireshark para las imágenes o tramas es  mpeg-pes, muestra únicamente los paquetes en donde fue reconstruida la imagen, por lo tanto, se observan las características de tamaño total de la imagen, tiempo de llegada de la imagen y el tipo de información PES (Packetized Elementary Stream).  El tipo de trama que se capturó (I, P o B) no aparece de forma directa. Los paquetes siguen el estándar internacional ISO/IEC 13818-1  (13818-1:2018, 2018). Sin embargo, un análisis a los archivos .pcap (Packet Capture) capturados por Wireshark,  obtenidos del experimento reveló que las tramas no eran decodificados totalmente con el analizador de protocolos, por lo que se construyó un algoritmo que paliara esta dificultad, al cual se lo denomino mpegDeco.

La Figura 3, muestra el diagrama de flujo del programa mpegDeco, donde se destaca la búsqueda sintáctica de diferentes palabras, todas precedentes a la información a extraer, contenidas en un archivo externo, extraído desde Wireshark, que debe ser leído totalmente por el programa. El algoritmo de mpegDeco una vez tenga las tres características (tiempo de llegada, tamaño de la imagen y tipo de la imagen), organiza esta información para que pueda procederse a un análisis estadístico posterior.

Para el proceso de simulación se eligió NS-3 ya que es una herramienta de código abierto que permite la inclusión de software externo; es escalable, modular y funciona como emulador. Además, debido al creciente uso que ha tenido NS-3 en el ámbito investigativo, cuenta con un estado del arte reciente y extenso  (Y. Qun and Z. Jianbo, 2015)  (Campo-Muñoz, 2017). Para la construcción del escenario básico de simulación, es necesario diseñar una aplicación que simule el servidor y el cliente. El servidor debe ser capaz tomar los modelos de los videos y dar formato a los paquetes para que se ajusten a los observados en un paquete IPTV, el cliente debe tener la capacidad de comprender estos paquetes y la información contenida en estos.  

Figura 3
Diagrama de flujo de mpegDeco

El servidor en NS-3 es quien genera tráfico de datos, por lo tanto, es quien genera los paquetes. En la Figura 4, se observan las cabeceras que comparten los dos tipos de transmisiones; las cabecera Ethernet, IPv4 y UDP están configuradas previamente en NS-3 y se agregan a los paquetes, por otro lado, la cabecera RTP no se encuentra diseñada en NS-3 por lo que es necesario crearla a fin de dar a la simulación un comportamiento fiel a los sistemas reales.

Figura 4
Cabeceras de los paquetes de IPTV

3.1. Diseño de cabecera RTP

La cabecera RTP fue diseñada según el estándar RFC3550 RTP (H. Schulzrinne, 2003), en el diseño se garantizó el soporte a varios tipos de aplicaciones especificando el parámetro Payload Type de la cabecera. La cabecera diseñada también transporta el número de secuencia de cada paquete y el identificador de fuente de sincronización (SSRC - Synchronization source). La marca de tiempo transporta el tiempo en que fue creado el paquete durante la simulación de NS-3. En la Figura 5, se tiene un ejemplo de las cabeceras RTP, donde se compara la cabecera capturada de una transmisión real con la cabecera utilizada en la simulación, se observa un comportamiento similar entre ambas cabeceras, lo que hace que los escenario de simulación sean más realistas. 

Figura 5
Comparación entre la cabecera RTP real y simulada

El número de secuencia de la cabecera real empieza la cuenta desde un número aleatorio mientras que en la simulación empieza desde uno, ver Figura 5. El número identificador de fuente de sincronización es un número aleatorio y todos los paquetes deben tener el mismo número durante la transmisión. La semejanza entre las cabeceras sirve para validar el funcionamiento del diseño de esta cabecera.

3.2. Aplicaciones del códec para NS-3

La Figura 6 muestra el diagrama de flujo del servidor de videostreaming que se diseñó para NS-3 con el códec MPEG-2. Las imágenes se crearon con la clase ns3::Packet ya que contienen funciones útiles para crear las tramas a partir de los modelos, también es útil para segmentar la trama y agregar las cabeceras. 

Figura 6
Diagrama de flujo del funcionamiento del servidor de videostreaming con MPEG-2

3.3. Diseño de la aplicación cliente

El cliente es un programa de tipo aplicación capaz de tomar los paquetes enviados desde el servidor, eliminar las cabeceras y reconstruir las imágenes enviadas. Para completar la comunicación entre el servidor y el cliente se instala un socket UDP en la aplicación cliente. Este socket toma los paquetes y los entrega directamente en la capa de aplicación del modelo TCP/IP.

3.4. Validación de las simulaciones

La validación de la simulación consistió en el empleo de técnicas como la comparación gráfica y cálculos estadísticos del error cuadrático medio (ECM) de los resultados simulados y reales. Estos procedimientos se realizaron sobre los datos adquiridos en el experimento para los tamaños y tiempos entre llegadas de cada tipo de trama en los estándares de calidad SDTV y HDTV.

La forma elegida para visualizar los datos reales y simulados en una misma figura es mediante las CDF, por lo que se contrastaron gráficamente las CDF de los datos prácticos y simulados pertenecientes al tamaño de las tramas. A partir de estas curvas se puede analizar el grado de semejanza y similitud entre lo que fue la realidad y la simulación. Además, el cálculo del ECM compara las CDF del modelo real con el resultado de la simulación. La Figura 7, muestra una de las CDF obtenidas del escenario de simulación comparada con la CDF del modelo real.

Figura 7
Curvas de contraste para los tamaños de tramas con
las CDF obtenidas del modelo real y el simulado

Para la validación de los tiempos relativos entre tramas se calcularon y graficaron las CDF tanto de los modelos reales como de los resultados de la simulación y luego se obtuvo un cálculo del error entre los tiempos de cada trama. La Figura 8 muestra una de las CDF obtenidas del escenario de simulación comparada con la CDF del modelo real.

Figura 8
Curvas de contraste para los tiempos relativos entre tramas con
la CDF obtenidas del modelo real y las corridas de simulación

La construcción del modelo de tráfico del servicio IPTV se realizó con base en datos adquiridos durante la propagación en un medio inalámbrico con el estándar 802.11b/g, en el cual se transmitió contenido multimedia del servidor al cliente. Este modelo permite describir y pronosticar el tráfico del servicio IPTV. El proceso de análisis parte de los resultados obtenidos de los experimentos con los dos escenarios implementados: el escenario real y el escenario de simulación. Del escenario de comunicaciones real, se obtiene como resultado el modelo de tráfico a partir de las características estadísticas de los videos; en el escenario de simulación se buscó un resultado que exprese el número máximo de clientes consumiendo el servicio IPTV sin que se sature el ancho de banda de la red WiFi bajo el estándar 802.11b/g.

4.1. Modelo de tráfico del servicio IPTV

En las Figuras 9.a y 9.b se observa el comportamiento del ancho de banda consumido y el throughput el cual fue calculado mediante la ecuación 1, para las calidades SDTV y HDTV, donde se cumple el principio de que el throughput es menor en magnitud con respecto al consumo total.

Otro aspecto o parámetro calculado fue el porcentaje de utilización de la red cuando el servicio IPTV estuvo en funcionamiento. Este parámetro es importante puesto que puede determinar un dimensionamiento y escalabilidad del servicio sin que este llegue a saturar el ancho de banda y demás recursos con los cuales trabaja. El cálculo de porcentaje de utilización de la red se llevó a cabo con la ecuación 2, cabe resaltar que a diferencia del throughput, la utilización de la red considera todo tipo de información que se envía al canal, es decir, cabeceras, paquetes perdidos, proceso de negociación, carga útil, entre otros  (Triviño, 2012). 

Figura 9
Contraste entre ancho de banda consumido Vs throughput

Con el objetivo de que el servicio IPTV no llegue a tener un mal funcionamiento por saturación del medio debido a un sobreuso de la red por parte del contenido multimedia que demanden los usuarios conectados, es útil emplear el parámetro del porcentaje de utilización de red. Este parámetro indica qué porcentaje de red consumirá cada tipo de video demandado por un solo usuario, esto permite determinar hasta qué punto puede llegar la escalabilidad en el número de clientes soportados. El porcentaje de utilización de red fue calculado para las calidades SDTV y HDTV.

En la Figura 10 se aprecia que la calidad de video HDTV tiene alta similitud en el comportamiento (formas de las curvas) comparada con la calidad SDTV.

Figura 10
Porcentaje de utilización en las dos calidades

Una forma alternativa de medir el rendimiento en una red es la cantidad de paquetes de datos que llegan de forma correcta desde un nodo hacia otro en la red; en la transmisión, los paquetes de datos pueden dañarse o alterarse por lo que un alto porcentaje de paquetes correctos significa un buen rendimiento de la red  (Red IRIS, 2016). Este parámetro fue adquirido de manera directa con Wireshark, el cual tiene la opción de analizar las estadísticas de la transmisión tales como paquetes por unidad de tiempo. Los valores promedio de ancho de banda, throughput, porcentaje de utilización de la red y número de paquetes por segundo se resumen en la Tabla 2.

El promedio de consumo de ancho de banda y el promedio de throughput están relacionados entre sí, el ancho de banda utilizado es la tasa total de la transmisión, mientras que el throughput es la tasa de información útil. La magnitud del throughput comparado con el ancho de banda es de 72,6%. Se concluye que el códec MPEG-2 ocupa el 30% del ancho de banda de la transmisión en información de cabeceras y control lo que demuestra su baja eficiencia.

Tabla 2
Valores promedio de parámetros para las calidades SDTV y
HDTV del servicio IPTV en una red WiFi con los modelos reales

Se calculó el porcentaje de utilización de la red para todos los videos para poder analizar el comportamiento de la red desde este parámetro. En la Tabla 3 se tiene que el porcentaje de utilización promedio es de 23,76 % y 29,88%, donde cada nuevo cliente ocupa este espacio del canal inalámbrico, por lo que se puede suponer que cuatro clientes utilizan aproximadamente el 95.04% y el 89,64% del canal WiFi con el estándar 802.11b/g. De esta forma, se deduce que el contenido multimedia podría llegar a ser escalable hasta cuatro clientes para la definición SDTV y tres clientes para HDTV.

4.2. Simulaciones con NS-3

La simulación de un escenario simple, es decir, un cliente y un servidor, permite observar si los modelos de los videos generan la misma intensidad de tráfico  que el servicio IPTV real, de forma que, al implementar un modelo de simulación se crea un método con el cual validar el modelo de tráfico  del servicio IPTV en una red WiFi. En la Figura 11, se observa el escenario básico compuesto de dos nodos inalámbricos y un punto de acceso con el estándar 802.11b/g, configurados de tal forma que puedan realizar transmisiones entre los nodos.

Figura 11
Escenario básico simulado en NS-3

El resultado de la latencia del canal inalámbrico en la simulación de NS-3 es de 1.05 ms. Valor esperado en redes WLAN  (T. Guo, 2011). En la Tabla 3 se observa el promedio de los valores de throughput, porcentaje de utilización del canal y el número de paquetes por segundo que se evidenciaron en la simulación. Estos cálculos se realizan con la información almacenada en los registros del cliente simulado, de forma análoga a la extracción de información del tráfico real con los archivos de Wireshark en el escenario real.

El valor de throughput en la simulación se calculó con la ecuación 1. Para calcular el porcentaje de utilización del canal se usa la ecuación 2, donde se toma el ancho de banda consumido por el video durante la simulación y luego se divide por el ancho de banda total del canal inalámbrico (11Mbps).

Tabla 3
 Valores promedio de parámetros para las calidades SDTV y HDTV
del servicio IPTV en una red WiFi con los modelos de simulación.

Para realizar el contraste entre los datos simulados y los datos reales, se emplea el cálculo del error estándar entre los valores de througput, porcentaje de utilización del canal y número de paquetes por segundo. En la Tabla 4 se tiene el resumen de los errores calculados para validar el funcionamiento del servicio IPTV en los modelos de simulación. Así de acuerdo a la Tabla 4 se puede concluir que los escenarios de simulación del servicio IPTV en una red WiFi son estadísticamente aproximados al escenario real (Kuehl, 2001). Este resultado demuestra que tanto el rendimiento de la red como el rendimiento del servicio IPTV se logra simular correctamente en NS-3 para una red con un único cliente y un único servidor.

Tabla 4
Resumen de errores promedio para los parámetros que miden el
desempeño de la red entre la transmisión real y la transmisión simulada

4.3. Número máximo de clientes en el escenario de simulación

El seguimiento constante al consumo de ancho de banda total permite observar cuando se alcanza el nivel de saturación del canal con el estándar 802.11b/g (11Mbps). Se observó un caso atípico en la simulación del video de características con poco color (video 3), con el cual se soportaron ocho clientes en la calidad SDTV, un número mucho mayor en comparación con las demás simulaciones, aun así, este valor no afectó significativamente el promedio de clientes al ser un caso aislado. En la Figura 13 se observa el consumo de ancho de banda simulado con las características del video 7, en este ejemplo en particular se tiene que la calidad estándar soporta cuatro clientes, ver Figura 12.a, mientras que, el video de alta definición es capaz de soportar hasta tres clientes, ver Figura 12.b.

Figura 12
Gráficos de consumo de ancho de banda para el escenario de simulación

En la Figura 12 se observa, en forma de escalones, el aumento progresivo de clientes en una simulación del servicio IPTV, lo que permite determinar el número máximo de transmisiones que puede soportar el canal. En la Tabla 5 se observan los resultados experimentales de los dos escenarios de simulación, los resultados de simular cada video son promediados para obtener la estimación de clientes que mejor se ajuste a los modelos de simulación, sin embargo, un resultado de 4,5 clientes no tiene sentido ya que el número de clientes está representado por una variable discreta que pertenece al dominio de los números naturales. Para obtener el número máximo de clientes se utiliza el valor estadístico de la moda, de esta forma se obtiene un resultado acorde a los valores esperados.

Tabla 5
Promedio y moda del número máximo de clientes
obtenidos con los modelos de simulación.

El resultado de los modelos de simulación para el número máximo de clientes que puede soportar el servicio IPTV en una red WiFi con el estándar 802.11b/g es: cuatro clientes para calidad SDTV y tres clientes para calidad HDTV.

Los datos obtenidos del throughput, ocupación de canal y tasa de paquetes por segundo, demuestra que el modelo de simulación diseñado tiene una buena aproximación a las observaciones realizadas en el experimento real. Además, se obtiene, mediante simulación, un valor estimado de la cantidad de clientes que puede atender el servicio IPTV en una red WiFi 802.11b/g de área local, lo que ofrece un punto de partida para el dimensionamiento y planificación detallada de redes para IPTV.

Se evidencio que la tecnología WiFi es capaz de soportar el servicio de IPTV tanto para definición estándar como para alta definición. Además, esta tecnología permite tener más de un cliente de manera simultánea alcanzando un total de cuatro y tres clientes para cada una de las definiciones respectivamente, para un ancho de banda digital de 11Mbps.

Se obtiene una representación del mundo real, esto es, el modelo de simulación, tal que permite incrementar el número de clientes hasta alcanzar el límite máximo soportado por la tecnología WiFi. El modelo de simulación permite tener en cuenta cada detalle del servicio de videostreaming, desde las cabeceras de los protocolos de capa superior las cuales fue necesario construir, hasta el encapsulamiento de cada una de las tres capas inferiores del modelo de interconexión de sistemas abiertos, las cuales ya son soportadas por la herramienta de simulación. Además,  gracias a los scripts de codificación de los videos que permiten eliminar la aleatoriedad del GOP es posible la reconstrucción del mismo, a través de las FDP que describen cada una de las tramas que componen el servicio de videostreaming.

13818-1:2018, I. (2018). Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems. Switzerland: ISO.

Alexa, A. (20 de 07 de 2018). cuadro24cineypublicidad. Obtenido de https://cuadro24cineypublicidad.wordpress.com/2012/11/01/canon-5d-iii-y-la-compresion-de-senal-de-video/

Brognara, R. (2016). Revolución Moble. Madrid: ESIC.

Campo-Muñoz, W. A.-H.-S. (2017). Modelado de tráfico del servicio de video bajo demanda mediante NS-3. DYNA,, 55-64.

D. O. Trujillo, G. E. (2016). Coding multimedia content using DASH standard. D. O. Trujillo, G. E. C. Golondrino, D. F. D. Dorado, W. Y. C. Muñoz anIEEE 11th Colombian Computing Conference (CCC), 1-7.

Fernando Boronat Seguí, M. G. (2009). IPTV: La televisión por internet (Tecnología). Madrid: Publicaciones Verticales.

H. Schulzrinne, S. C. (2003). RTP: A Transport Protocol for Real-Time Applications. New York: Columbia University.

H. Zeng, Z. Z. (2016). Research and Implementation of Video Codec Based on FFmpeg,. International Conference on Network and Information Systems for Computers (ICNISC), 184-188.

Kawamori, M. (2008). International Telecommunication Union. Obtenido de https://www.itu.int/en/ITU-T/gsi/iptv/Documents/tech/1002-Singapore-IDA-APT-WS-IPTV-Overview.pdf

Kuehl, R. O. (2001). Diseño de Experimentos: Principios estadísticos para el diseño y anális de investigaciones. Mexixo: Thomson Learning.

Mok, S. C. (2003). Un modelo de simulación del tráfico de una red de transmisión de datos. Revista Ingeniería, vol. 13, no. 1-2., 63–76.

Red IRIS. (2016). Herramientas de análisis de rendimiento de red.

Sánchez, A. G. (2008). Experiencias en IPTV. Interactic, 3-19.

T. Guo, C. H. (2011). Performance Evaluation of IPTV Over Wireless Home Networks,. IEEE Transactions on Multimedia, vol. 13, no. 5, pp. 1116-1126, Oct. 2011., 1116-1126.

Triviño, J. E. (2012). Introducción a la teória de Teletráfico. Bogotá: Universidad Nacional.

Y. Qun and Z. Jianbo. (2015). Development of remote video monitoring system based on TCP/IP. 10th International Conference on Computer Science & Education (ICCSE), Cambridge, 2015, pp. 596-600., 596-600.

1. Docente de la Universidad del Quindío. Programa de Ingeniería Electrónica. Ingeniero en Electrónica y Telecomunicaciones, MSc en Ingeniería, Área Telemática, Ph.D en Ingeniería Telemática. wycampo@uniquindio.edu.co

2. Ingeniero Electrónico. Programa de Ingeniería Electrónica. Universidad del Quindío. nlopezq@uqvirtual.edu.co   

3. Docente de la Universidad del Quindío. Programa de Ingeniería Electrónica. Ingeniero en Electrónica y Telecomunicaciones, MSc en Ingeniería, Área Electrónica y Telecomunicaciones, Ph.D en Ciencia de la Electrónica. eastaiza@uniquindio.edu.co