ARTÍCULO ORIGINAL

Evaluación de la QoS en redes HFC para la distribución de aplicaciones de televisión digital interactiva (TDI)

Evaluation of QoS in HFC networks to distribution of interactive digital television (ITV) applications

Diego Rueda Pepinosa*, Wilmar Campo, Iván Taimal Narváez, José L. Arciniegas H.

Grupo de Ingeniería Telemática - GIT. Facultad de Ingeniería Electrónica y Telecomunicaciones. Universidad del Cauca. Calle 5 No. 4-70. Popayán, Colombia.

^*Autor de correspondencia: teléfono: + 57 + 1 + 284 50 16, correo electrónico: dfrueda@unicauca.edu.co. (D. Rueda)

(Recibido el 12 de enero de 2012. Aceptado el 23 de mayo de 2012)

Resumen

Las aplicaciones desarrolladas para Televisión Digital interactiva (TDi) consumen recursos adicionales en las redes de telecomunicaciones. Es por tanto necesario realizar un análisis y evaluación de los protocolos y recursos de la red de telecomunicaciones utilizados para asegurar el correcto funcionamiento de este tipo de aplicaciones, cuando entren a competir con otros servicios que se distribuyen simultáneamente. Este artículo presenta un análisis y evaluación de los parámetros de desempeño de la red Hibrida de Fibra y Coaxial (HFC, Hybrid Fiber Coaxial), cuando aplicaciones de T-Learning comparten los recursos de red con otros servicios tales como HTTP, FTP y VoIP. Para ello, se propone un modelo de simulación en el que se analiza el throughput, la pérdida de paquetes, el retardo y el jitter en la red HFC ante diferentes configuraciones de los parámetros que ofrece el protocolo de especificación de la interfaz de servicios de datos sobre cable (DOCSIS, Data Over Cable Service Interface Specification) para brindar mejor Calidad de Servicio (QoS, Quality of Service).

Palabras clave: Televisión Digital interactiva (TDi), T-Learning, HFC, DOCSIS, QoS

Abstract

Applications developed for Interactive Digital Television (iTV) generate a consumption of additional resources to telecommunications network. It is therefore necessary do an analysis and evaluation of protocols and resources of the telecommunications network used to ensure the proper functioning of such applications, when they come to compete for network resources with other services that are distributed on the network simultaneously. In this paper, we present the analisys and evaluation of the performance parameters of the HFC network, when T-Learning applications share network resources with other services such as HTTP, FTP and VoIP. For this purpose, we propose a simulation model which analyzed the throughput, packet loss, delay and jitter on the HFC network when changing the parameter settings offered by the DOCSIS protocol to provide QoS.

Keywords: Interactive Digital Television (iTV), T-Learning, HFC, DOCSIS, QoS

Introducción

Este artículo hace parte de los resultados de los proyectos EDiTV [1] y ST-CAV [2] los cuales están siendo ejecutados por la Universidad del Cauca (Popayán-Colombia) en asociación con las Universidad Autónoma de Occidente (Cali- Colombia) y la Universidad de Oviedo (Gijón- España). El proyecto permitió la implementación del laboratorio de televisión digital interactiva en la Universidad del Cauca, para propósitos de investigación, específicamente en el campo del aprendizaje a través de la TDi conocido como T-Learning [3] . En este contexto las aplicaciones para T-Learning se desarrollaron bajo la especificación europea Digital Video Broadcasting - Multimedia Home Platform (DVB-MHP) [4] , siendo los cursos de T-Learning una combinación de diferentes tipos de materiales de aprendizaje: videos, animaciones, texto, imágenes y páginas DVB-HTML [3] .

Para el desarrollo de este trabajo se utilizó la red HFC, la cual garantiza los canales de broadcast y de retorno para la TDi sin la necesidad de usar otra red [5, 6] . En un entorno de T-Learning, los usuarios interactúan con las aplicaciones a través del control remoto del set top box (STB). El STB está encargado de la recepción, decodificación de la señal y ejecución de las aplicaciones de TDi para su posterior visualización en el televisor, de este modo, los usuarios son capaces de enviar datos o solicitar información de acuerdo al diseño de las aplicaciones de T-Learning.

El tráfico generado por las aplicaciones de T-Learning demanda un consumo adicional de los recursos de la red HFC que debe ser analizado, razón por la cual es necesaria una adecuada configuración del protocolo DOCSIS, para asegurar el correcto funcionamiento de las aplicaciones de TDi cuando compitan por los recursos de la red con otros servicios, que se distribuyen simultáneamente. La contribución de este trabajo es el análisis y evaluación de los parámetros de desempeño de la red HFC cuando aplicaciones de TDi comparten recursos de la red con otros servicios tales como HTTP, FTP y VoIP. Para ello, se planteó un modelo de simulación en el que se analizó el throughput, la pérdida de paquetes, el retardo y el jitter en la red HFC ante diferentes configuraciones de los flujos de calidad de servicio y la prioridad de tráfico, como parámetros que ofrece el protocolo DOCSIS para brindar QoS [5] . Este artículo es la continuación de [6] , donde se presentaron los trabajos relacionados y la base teórica que sustenta esta investigación.

Caso de estudio

Se desarrolló una aplicación para un programa de televisión educativo que permite la solicitud de información adicional al mismo (texto y/o imágenes). Esta aplicación de TDi llamada EDiTV0, habilita contenidos adicionales a lo largo de la trasmisión del programa, los cuales son accedidos por medio de opciones que el usuario puede seleccionar con el control remoto para interactuar con el servidor de aplicaciones del sistema de T-Learning. Cuando se hace la solicitud de información, la pantalla del televisor se divide en diferentes secciones [2, 7] . En una de ellas el video continúa reproduciéndose y en las otras se presenta la información solicitada por el usuario.

Modelo de simulación

En [8] y [9] los autores describen el proceso de modelado usando como herramienta de simulación OPNET Modeler [10] , que fue la utilizada en esta investigación. El proceso de modelado es necesario para construir el escenario de red con diferentes servicios, analizar su comportamiento y variar los parámetros de configuración sin que la experiencia del usuario se vea afectada.

En la figura 1 se presenta el modelo de red HFC en el cual se simuló la aplicación EDiTV0, y los servicios HTTP, FTP y VoIP. Este modelo de red HFC permitió la simulación de diferentes configuraciones de los parámetros de QoS del protocolo DOCSIS, evaluando combinaciones de los mismos y obteniendo la que mejor se aplica a sendos servicios. Cabe señalar que todos los elementos de red que conforman el modelo son soportados por la herramienta OPNET Modeler, al igual que el modelo del protocolo DOCSIS [11] .

Modelo del cliente de la aplicación de TDi

Para modelar el tráfico de los clientes de la aplicación EDiTV0, en el laboratorio de TDi se realizaron capturas del tráfico generado por el comportamiento de los usuarios, cuando realizan solicitudes de información al servidor de aplicaciones. Se determinaron los parámetros de las Funciones de Densidad de Probabilidad (FDP) que describen su comportamiento, cuya validación se realizó a través de la prueba de bondad de ajuste de Kolmogorov-Smirnov. El proceso para encontrar el modelo de tráfico de las aplicaciones se describe en [11] . EDiTV0 permite la solitud de un contenido con información de tipo texto (archivo XML1), y después de un intervalo de tiempo (tiempo entre peticiones) se permite la solicitud de un contenido conformado por texto (archivo XML2) y por una imagen. Este proceso de intercambio de información entre el servidor de aplicaciones de TDi y el STB se realiza mediante el protocolo HTTP. En la tabla 1 se presentan los parámetros de las FDP del modelo de tráfico de la aplicación objeto de estudio según los resultados obtenidos en [11] .

En la simulación de la aplicación de TDi en OPNET Modeler, se configuraron custom applications en estaciones de trabajo con las FDP y los perfiles que representan el comportamiento de un cliente de TDi durante el tiempo que interactúa con la aplicación EDiTV0. El perfil se configuró teniendo en cuenta que el productor del programa de televisión es quien define o habilita cuando se puede solicitar la información adicional del programa de televisión. De este modo en la simulación se configuraron 20 clientes de TDi, los cuales cada 2 minutos realizan la solicitud de información basados en el comportamiento estadístico de las aplicaciones presentado en tabla 1.

Modelo de los clientes para los servicios HTTP, FTP Y VoIP

Adicionalmente a los clientes de TDi, en la simulación se configuraron 20 clientes HTTP, 10 clientes FTP, y 4 usuarios de VoIP quienes establecen 2 conexiones activas entre sí. Los modelos de tráfico configurados en OPNET Modeler para los servicios HTTP, FTP y VoIP se presentan en la tabla 2 y fueron obtenidos en [12] .

Modelo de los servidores

El servidor de aplicaciones de TDi fue configurado para servir los archivos, y responder a las peticiones realizadas por los diferentes clientes mediante el protocolo HTTP. Este servidor se ubica en la cabecera del modelo de la red HFC y se conecta al CMTS por medio de una interfaz Ethernet. Además, en la cabecera de red se configuraron servidores FTP y HTTP para atender a sus respectivos clientes, como se puede observar en la figura 1.

Modelo del protocolo

En la tabla 3 se presenta la configuración del protocolo DOCSIS para el CMTS, la cual fue obtenida a partir de los estudios realizados en [6] y [11] . Nótese que los mecanismos de concatenación y fragmentación están habilitados. De esta manera, la concatenación facilita la transmisión de los pequeños paquetes ACK de TCP  en una única oportunidad de transmisión y la fragmentación permite un manejo adecuado  de los paquetes de gran tamaño generados por  FTP.

En los escenarios de simulación, la configuración de los parámetros de QoS del protocolo DOCSIS en los CM de los clientes HTTP y FTP fue Best Effort (BE) con una prioridad 7, siendo esta la más baja de todas, mientras que para los usuarios VoIP el flujo de servicio fue Unsolicited Grant Service (UGS) con Grant Size = 256 bytes y Nominal Grant Interval = 10ms [6] . Sin embargo, la configuración de los parámetros de QoS del protocolo DOCSIS en los CM asociados a los clientes de TDi fueron variados para determinar el comportamiento sobre los servicios.

Análisis de resultados

A continuación se presentan los resultados obtenidos a partir del modelo de simulación en el que se analizó el throughput, la pérdida de paquetes, el retardo y el jitter en la red HFC ante diferentes configuraciones de los parámetros de QoS del protocolo DOCSIS.

Efectos de la asignación de flujos de servicio del protocolo DOCSIS sobre aplicaciones de TDi

Con el fin de analizar los efectos de la asignación de flujos de servicio del protocolo DOCSIS (BE, nrtPS, rtPS y UGS), los clientes de TDi se configuraron con cada uno de estos [5] . Así, se comparó el funcionamiento de la aplicación EDiTV0 con el resto de servicios y se evaluó el desempeño de la red HFC ante esta configuración del protocolo para ofrecer QoS.

Inicialmente se obtuvo el throughput de la red en sentido ascendente figura 2.a y sentido descendente figura 2.b, ante la variación de los flujos de servicio de QoS en los clientes de TDi. Como se puede observar, el throughput en ambos sentidos disminuye cuando son configurados los flujos de servicio nrtpS, rtPS o UGS, mientras que para la configuración BE se obtiene la máxima transferencia de información en la red. Dicho comportamiento se debe a que los servicios BE, como HTTP y FTP, ven reducidos los slots de contienda y las oportunidades de transmisión cuando se asignan concesiones por sondeo periódico a los clientes (nrtpS, rtPS o UGS). En consecuencia el número de CM solicitando permisos de transmisión disminuye y por lo tanto la carga de tráfico decae. La peor situación se obtuvo cuando los clientes están configurados con el flujo de servicio UGS donde se observa que el tráfico en la red disminuye significativamente.

En la figura 3 se muestran las variaciones del retardo de la aplicación de TDi cuando se varía la configuración de flujo de servicio en los clientes. Obsérvese que sí los clientes se configuran con los flujos de servicio rtPS y nrtPS el retardo aumenta por encima de 200 ms, límite establecido en [13] para proporcionar QoS a las aplicaciones interactivas, llegando hasta 560 ms para la configuración rtPS y hasta 660 ms para la configuración nrtPS. Para la configuración UGS en los clientes de TDi la grafica de retardo no existe porque en ningún momento estos establecieron conexión con el servidor de aplicaciones de TDi. Este comportamiento se debe a que los flujos de servicio rtPS, nrtPS y UGS fueron pensados para servicios que necesitan de un acceso periódico para la transmisión de información, lo cual no ocurre con el tráfico generado por la aplicación de TDi. Por lo tanto, la mejor opción para reducir el retardo en la aplicación de TDi es la configuración con el flujo de servicio BE, para la cual el máximo retardo es de 11 ms.

Para los servicios HTTP y FTP, se puede ver en la figura 4.a y figura 4.b que el valor mínimo del retardo HTTP es de 400 ms y del retardo FTP es de 7 s. estos valores se obtuvieron cuando los clientes están configurados con el flujo de servicios BE. Para las configuraciones nrtPS, rtPS y UGS en los clientes de TDi, el retardo HTTP oscila entre 3,3 s, y 5,6 s, mientras que el retardo FTP aumenta con el tiempo sin llegar a un límite específico debido a que existe acumulación de paquetes en los clientes FTP por las reducidas oportunidades de transmisión que tienen.

Por su parte, el retardo y el jitter de VolP ante la configuración de los flujos de servicio BE, rtPS y nrtPS en los clientes no tienen variaciones representativas debido a que la VoIP está configurada con UGS, siendo este el flujo de servicio de mayor prioridad para garantizar las oportunidades de transmisión a los usuarios de VoIP mediante concesiones periódicas no solicitadas. En la figura 5.a se observa que el retardo VolP está alrededor de 7 ms, mientras que en la figura 5.b el jitter se encuentra cerca de 0,05 ms, valores que están por debajo del límite para proporcionar QoS de servicio según [13] . Sin embargo, cuando se configura UGS a los clientes de TDi no existen gráficas del retardo y jitter VolP puesto que se incrementa el número de concesiones no solicitadas que impiden establecer conexiones entre los usuarios de VoIP.

En la figura 6.a se observa que el retardo DOCSIS aumenta cuando los clientes de TDi están configurados con los flujos de servicios de nrtPS, rtPS y UGS, lo cual se debe principalmente al comportamiento del retardo FTP. Nótese en la figura 6.a que el menor retardo DOCSIS de 110 ms, se obtuvo cuando los clientes de TDi están configurados con el flujo de servicio BE.

En cuanto a la razón de pérdida de paquetes, en la figura 6.b se observa que esta disminuye cuando los clientes de TDi se configuran con los flujos de servicio nrtPS, rtPS y UGS, debido a que los clientes de otros servicios resignan sus oportunidades de transmisión y de acceso al medio, siendo incapaces transmitir sus datos. No obstante, con la configuración BE en los clientes de TDi existe transferencia de información para todos los usuarios de la red, a pesar que la razón de pérdida de paquetes se mantiene en promedio en 2,7 %.

Variación de la prioridad del tráfico DOCSIS asociada al flujo de servicio best effort sobre aplicaciones de TDi

Como se pudo observar la asignación de flujos de servicio nrtPS, rtPS y UGS en los clientes de TDi no proporcionaron mejoras a la transmisión del tráfico de aplicaciones de TDi sobre la red HFC, siendo el flujo de servicio BE el que mejor se adapta a la transmisión de este tipo aplicaciones. Por ello, con el fin de analizar los efectos de la prioridad del tráfico BE en la red HFC, los clientes de TDi fueron configurados con las prioridades del tráfico BE más alta (BE (0)) y más baja (BE (7)) para comparar el funcionamiento de la aplicación con el resto de servicios y evaluar el desempeño de la red HFC ante esta configuración del protocolo DOCSIS.

En la figura 7 se presenta el retardo de la aplicación de TDi ante variaciones en las prioridades del tráfico BE en los clientes de TDi. Nótese que al configurar la prioridad del flujo de servicio más baja (BE (7)), el retardo de la aplicación de TDi alcanza un valor de 11,5 ms mientras que al configurar una prioridad más alta (BE (0)) el retardo disminuye hasta los 5 ms mejorando el rendimiento de esta aplicación.

Debido a que los usuarios HTTP y FTP tienen configurado un flujo de servicio BE (7), el retardo HTTP y FTP se incrementó cuando se configuraron los clientes de TDi con prioridad más alta. Este resultado obedece a la preferencia por parte del CMTS a los paquetes pertenecientes al flujo de servicio BE (0) sobre los paquetes BE (7). Dicho comportamiento se puede observar en la figura 8.a y figura 8.b donde el máximo retardo HTTP alcanzó los 600 ms y el máximo retardo FTP los 10 s para cuando los clientes de TDi estuvieron configurados con BE (0).

Sin embargo, los clientes de VoIP al tener configurado el flujo de servicio de concesión no solicitada (UGS) tienen más privilegios sobre todos los niveles del servicio BE, por lo que el retardo y jitter de VoIP no tienen variaciones significativas. En este sentido, en la figura 9.a se puede apreciar que el retardo VoIP está entre 6,96 ms y 6,98 ms y en la figura 9.b que el jitter se encuentra alrededor de 0,05 ms. Dichos valores, están por debajo de los establecidos por [13] para garantizar la QoS para la VoIP.

Para analizar el retardo DOCSIS y la proporción de pérdida de paquetes es necesario tener en cuenta que en los tiempos de simulación 240 s y 480 s las conexiones de VoIP dejan de establecerse y se liberan los slots de contienda asignados al flujo de servicio UGS. Esta situación es aprovechada por las aplicaciones asignadas al flujo de servicio BE para realizar solicitudes de transmisión con mayor frecuencia, pero se genera un incremento en la probabilidad de colisión. Lo anterior se ve reflejado en un aumento del retardo DOCSIS y la razón de pérdida de paquetes tal y como se muestra en la figura 10. Sin embargo, cuando clientes de TDi se configuran con prioridad más alta (BE (0)) hay un mayor incremento en el retardo DOCSIS y en la razón de pérdida de paquetes, que si estos se configuran con la prioridad más baja (BE (7)).

Conclusiones

El análisis realizado a los parámetros de QoS del protocolo DOCSIS permitió determinar la configuración adecuada para proporcionar calidad de servicio a las aplicaciones de TDi en términos de retardo y pérdida de información, sin perjudicar el funcionamiento de servicios como VolP, HTTP y FTP. Por lo cual la red HFC es idónea para la distribución de aplicaciones de TDi.

Dentro de los efectos de la asignación de flujos de servicio de QoS como rtPS, nrtPS y UGS configurados sobre los clientes de TDi, se puede observar que afectan negativamente la distribución de las aplicaciones puesto que incrementan el retardo y la pérdida de información, debido a que estos fueron pensados para servicios que necesitan de un acceso periódico para la transmisión de información, y el tráfico generado por la aplicaciones de TDi objeto de estudio, no cumple con dicha característica.

Para las aplicaciones de TDi de solicitud de información adicional, donde el tiempo entre peticiones se distribuye de manera exponencial, la mejor opción de configuración de los parámetros de QoS del protocolo DOCSIS es clasificar dicho tráfico en el flujo de servicio BE con la prioridad más baja (BE (7)) para garantizar que los parámetros de desempeño como el retardo y pérdida de información sean mínimos, sin afectar el rendimiento general de la red HFC como se pudo comprobar con los resultados obtenidos de las simulaciones.

Agradecimientos

Este trabajo ha sido desarrollado con el apoyo y financiación de los proyectos EDiTV (ID 1103­393-20026) y ST-CAV (ID 1103-489-25425). Agradecimientos a Roberto García, profesor del Departamento de Informática de la Universidad de Oviedo (España) por su invaluable asesoría.

References

1. J. Arciniegas, J. Amaya, F. Urbano, W. Campo, R. Euscategui, A. García, X. García. ''EDiTV: Educación Virtual Basado en Televisión Interactiva para Soportar Programas a Distancia''. Revista de ciencia, educación, innovación y cultura apoyadas por redes de tecnología avanzada. Vol. 1. 2011. pp. 42-47.         [ Links ]

2. Proyecto ST-CAV: Servicios de T-Learning para Soportar una Comunidad Académica Virtual. Disponible en: http://www.unicauca.edu.co/stcav. Consultado el 1 de agosto de 2011.         [ Links ]

3. P. Aarreniemi, J. Tuominen. Experiences with an interactive learning environment in digital TV. Proceedings of the IEEE International Conference on Advanced Learning Technologies. Washington, Estados Unidos. 2004. pp. 296-300.         [ Links ]

4. A. Smith, S. Morris. Interactive TV Standards: A Guide to MHP, OCAP and JavaTV. Ed. Focal Press - Elsevier. Estados Unidos. 2005. pp. 1-611.         [ Links ]

5. Cable Labs. Data-Over-Cable Service Interface Specification, DOCSIS 1.1, Radio Frequency Interface Specification. Ed. Cable Labs. Estados Unidos. 2005. pp. 1-436.         [ Links ]

6. W. Campo, D. Rueda, I. Taimal, J. Arciniegas. ''Análisis del protocolo DOCSIS para la distribución de aplicaciones y contenidos de TDi en la red HFC''. Revista Avances en Sistemas e Informática. Vol. 6. 2009. pp. 119-132.         [ Links ]

7. W. Campo, G. Chanchí, F. Urbano, J. Arciniegas. Recomendaciones para el despliegue de contenidos de T-Learning. XI Congreso Internacional de Interacción Persona Ordenador. España. 2010. pp. 119-128.         [ Links ]

8. R. García, V. García, X. Pañeda, D. Melendi. ''Analysis and modelling of a broadband fiber access network with high peer-to-peer traffic load''. Simulation Modelling Practice and Theory. Vol. 14. 2006. pp. 506-526.         [ Links ]

9. D. Melendi, R. García, X. Pañeda, V. García. ''Modelling and simulation of a real Internet radio service''. Journal of Simulation. Vol. 5. 2010. pp. 111-122.         [ Links ]

10. OPNET Technologies. Specialized Models User Guide. Ed. Cisco Systems. Estados Unidos. 2005. pp. 1-246.         [ Links ]

11. D. Rueda, W. Campo, I. Taimal, J. Arciniegas. Caracterización de la distribución de contenidos de TDi en el canal interactivo de la red HFC. V Congreso Iberoméricano de Telemática - CITA 2009. Gijón, España. 2009. pp. 193-196.         [ Links ]

12. R. García. Desarrollo de un modelo de red con tecnología FTTX para transmisión de voz y datos, análisis del protocolo de acceso al medio y validación del tráfico generado. Tesis Doctoral. Área de Ingeniería Telemática. Universidad de Oviedo. Gijón, España. 2005. pp. 1-313.         [ Links ]

13. ITU-T. ITU-T Recommendation G.1010: End-user multimedia QoS categories. Ed. ITU-T. Suiza. 2001. pp. 1-18.         [ Links ]