978‐1‐4673‐1269‐1/12/$31.00 ©2012 IEEE

IDENTIFICATION OF THE VARIABLES CAUSING THE DELAY IN CHANGING CHANNEL

IPTV SERVICE - STATE OF THE ART. Ernesto López González (1), Alberto Correa Castrillón (2), Andres Navarro Cadavid (3).

erlopez@emcali.com.co, alcorrea@emcali.com.co, anavarro@icesi.edu.co. (1) MGIT . Universidad ICESI. Santiago de Cali, Colombia. (2) MGIT . Universidad ICESI. Santiago de Cali, Colombia. (3) MGIT . Universidad ICESI. Santiago de Cali, Colombia.

Abstract - Currently, the IPTV service has been able to satisfy the expectation of entertainment and interactivity demanded by the market users, the proper performance of the service involves the solution to a set of challenges inherent IP environment, such as correction loss and delay information Multicast in the signal. This article reviews the most important techniques used to solve the delay in changing channel IPTV service cataloging solutions such as invasive or not, according to the form of bond equipment and / or multicast flows for such a solution. Palabras claves - Cambio de canal, aceleración Multicast, calidad de la experiencia, velocidad de bits.

I. INTRODUCCION.

IPTV ha logrado perfilarse como un servicio integrador de medios clásicos de comunicación (voz, datos y video), llevando a otro nivel las aplicaciones soportadas por estos (VoIP, Internet, Video Streaming, etc.), permitiéndole al usuario establecer un alto grado de interactividad entre las mismas al ofrecer un compendio de estos servicios como un solo producto de cara al cliente (1): Guía electrónica programable (EPG), Personalización de canales, Video en demanda (VoD), Búsqueda web, Envió y recepción de e-mails, Aplicaciones centralizadas para la grabación de video digital (DVR), Mensajería instantánea (tipo chat); Generación, Identificación, Desvió, y Conferencia de llamadas telefónicas; Juegos en demanda (GoD), Sistemas de alerta basados en convergencia IP, Video vigilancia; y todo esto bajo una único punto de vista para cliente: un servicio de televisión (2).

Al realizar el disfrute de los servicios brindados con IPTV, el usuario puede experimentar cierto tipo de deterioros sobre la señal de video recibida, los cuales afectan directamente la calidad percibida por el mismo, dichos detrimentos generalmente son causados por dos factores: a) los deterioros causados a partir de la fuente Multicast. b) y la degradación que sufre la señal toda vez que realiza el trayecto desde la fuente hasta el usuario.

II. DETERIOROS CAUSADOS POR LA

FUENTE DE EMISION MULTICAST.

Como se observa en la figura 1, estos deterioros están directamente relacionados con la etapa de digitalización y compresión de la señal de audio/video desde la fuente y la interacción entre las múltiples señales a codificar/multiplexar (3) previas a ser enviadas a la red de transporte. En este caso los principales factores que afectan la señal codificada previa interacción con la capa de transporte son (4): los errores de transmisión provenientes de la señal fuente hacia la etapa de compresión y digitalización, formato de compresión empleado, la reducción de resolución horizontal en pro de emplear una tasa de bits constante baja (afectando directamente la nitidez del video) (5), el rango de búsqueda del vector de movimiento (6) donde búsquedas amplias aumentan la calidad, pero incrementan el procesamiento del codificador y retardos del mismo.

Figura 1. Sistema general de video Streaming para

servicio de IPTV (4). Otro aspecto fundamental en este orden de criterios, es la longitud del grupo de imágenes GOP del paquete en el Transport Stream (7): GOPs pequeños aumentan los anchos de banda requeridos pero disminuyen el tiempo de cambio canal (debido a la cantidad de tramas I enviadas), GOPs grandes mejoran la calidad de compresión disminuyendo efectivamente el ancho de banda, pero aumenta el tiempo de cambio de canal (aumenta el tiempo de sincronización de la trama I), GOPs dinámicos pueden mejorar el cambio de

978‐1‐4673‐1269‐1/12/$31.00 ©2012 IEEE

escenas, pero este tipo de configuración no es gestionable en todos los tipos de Set-top Box, además esta configuración puede aumentar la latencia al acarrear tiempos de cambio de canal variables.

III. DEGRADACIÓN DE LA SEÑAL EN EL TRAYECTO DESDE LA FUENTE HASTA EL USUARIO FINAL.

Los detrimentos sufridos por la señal Multicast hasta llegar al usuario final, están determinados por la forma y características de la ruta que deba seguir. La “forma” hace referencia a la “topología de la red”, la cual evidencia su desempeño a partir de la cantidad de equipos de conmutación y enrutamiento de paquetes que posea. Las características de los enrutamientos están basadas en las políticas aplicadas a las mismas (prioridades y optimización) y en las segmentaciones lógicas establecidas en las capas de la red (acceso, agregación y Core). Es de especial importancia considerar que la calidad de la red de “última milla”, para el caso de los enlaces de cobre, representa un porcentaje significativo en lo concerniente a la degradación de la señal Multicast, afectando de manera general los parámetros citados a continuación. Respecto a la cuantificación de los detrimentos de la señal Multicast, algunos de los parámetros más comunes (8) son:

• Relación de pérdida de paquetes IP (IPLR): relación del total de paquetes IP perdidos respecto al total de paquetes transmitidos.

• Relación de error de paquete IP (IPER): relación entre el total de paquetes erróneos respecto al total de los paquetes exitosos (resultante de la transferencia de paquetes IP).

• Retardo en la transferencia de paquetes IP (IPTD): retardo que abarca el resultado de paquetes con éxito y con errores a través de un segmento de la red, tiempo ( - ) cuando se presenta la transferencia de dos paquetes IP.

• Variación del retardo de paquetes IP (IPDV) (9): retardo respecto a una referencia métrica (retraso medio o mínimo) entre un par de paquetes, medidos desde un punto A hasta pasar por un punto B, también es definido como el retardo en una “vía” o un sentido, de los paquetes analizado.

• Retardo de cambio de canal (Zap time): retardo definido el diferencial de tiempo entre una petición hecha por el usuario para cambiar de canal Multicast y la visualización de la primera trama del canal requerido en la pantalla de su equipo de televisión (10).

A. Perspectiva del usuario y del proveedor de contenido televisivo respecto al Zapping.

El Zapping como variable degradante en el servicio de IPTV puede ser analizado bajo dos perspectivas: desde la perspectiva del cliente y del productor de contenido

televisivo. Desde la perspectiva del cliente, el Zapping es visto como una falla en la calidad del contenido adquirido (11), esta calidad experimentada QoE no está exenta de opiniones subjetivas y personales de la misma, variando según factores característicos del usuario (entorno social, contexto cultural, escolaridad, tipo de aplicación a emplear, etc.) (12) (13). Desde la perspectiva del productor de contenido televisivo, el Zapping es visto como la reacción de un conjunto de usuarios demográficamente catalogados (sexo, edad, ubicación geográfica, estrato social, etc.) ante la aceptación o no, de la combinación de ciertos contenidos emitíos a ciertas horas del día, bajo ciertos espacios publicitarios y la duración de los mismos; dando lugar a tres apreciaciones (13), según su naturaleza: i) desconexión física del individuo: cuando la persona abandona el recinto donde se encuentra el televisor, ii) desconexión mecánica: ocasionada a partir de dispositivos electrónicos ("controles remotos" o mandos a distancia, etc.), para llevar cabo el cambio de canal o filtrado de anuncio publicitario, iii) definiciones relativas a la desconexión psicológica: producida cuando la persona se expone al medio televisivo pero no dedica ninguna atención, razón por la cual el contenido televisivo es interrumpido. El enfoque del estado del arte de este documento concibe al retardo en el cambio de canal como un conjunto de factores propios de la red de telecomunicaciones adverso al QoE experimentados por el usuario al realizar interactividad cliente-servidor. Se cita lo anterior para reseñar que la respuesta del usuario, en lo concerniente a la exploración de canales, se conserva respecto a la transmisión análoga tradicional en modo Broadcast: realizando cambios aleatorios de canal y cambios de canal en modo Surfing el usuario realiza consultas cíclicas del canal adyacente hacia arriba (n+1) o hacia abajo (n-1) (14). El retardo en el cambio de canal puede ser entendido como la suma de retardos generados durante el proceso de despliegue del contenido televisivo, siendo entonces una sumatoria de retardos asociados (10), (15), (16):

• El retardo asociado a las condiciones de la red a través del transporte del contenido desde la fuente hasta el STB, vinculado generalmente al retardo en la petición IGMP de unión/abandono de canal (17).

• El retardo asociado a la administración del contenido a través de la adquisición de información clave para la decodificación del video dado que este es típicamente transmitido en MPEG-2, MPEG-4 (18), siendo importante obtener información como las tablas Program Map Table, Program Association Table y Content Access Table (20).

• El retardo asociado con la compresión y codificación del video a través del llenado del buffer del STB para proceder a la decodificación del video (10) (5), lo que incluye la adquisición

978‐1‐4673‐1269‐1/12/$31.00 ©2012 IEEE

de tramas I en el Transport Stream de video (20) (22).

IV. TENDENCIAS ACTUALES PARA

REDUCIR EL RETARDO DEL CAMBIO DE CANAL EN EL SERVICIO DE IPTV.

Uno de los principales factores que aportan retardo en lo concerniente al cambio de canal es la sincronización/alineación de las tramas I provenientes del servidor Multicast cuando el usuario realiza el cambio de canal, tal proceso de alineación es también conocido como RAP1 (14), definido como el tiempo en que tardan estas tramas para conformar un grupo de imágenes (GOP) antes de ser visualizadas. A continuación se presentan las propuestas solución para reducir el Zapping Delay.

A. Stream secundario de cambio de canal (21).

Enfoque que utiliza un segundo Stream asociado a cada canal Multicast a visualizar conteniendo solo tramas I y el audio asociado a las mismas y bajo Bit Rate. En esta técnica, cada canal crea un grupo Multicast denominado grupo Multicast secundario ICC2 (reducción a partir de la asistencia de un canal Unicast secundario para cada cambio de canal del usuario), el cual contiene solo tramas I retardadas 2,6 segundos respecto al Stream primario (original). El Stream secundario permitirá ver al cliente el video del nuevo canal mientras se realiza el llenado del buffer en Setup-box por parte del Stream primario (16).

Figura 2. Técnica de Stream secundario de cambio de

canal. En la figura 2 se describe las generalidades de esta técnica, la cual está basada en el envió de un segundo Flujo (grupo Multicast independiente), paralelo al Flujo original, el cual tiene como función complementar “más rápido” el proceso de sincronización de los RAP’s en el buffer del cliente (22); este Flujo posee una alta frecuencia de RAP’s, de modo que al usuario cambiar el canal, se sintoniza con este Flujo permitiéndole reducir el retardo de decodificación, al introducir con inmediatez la siguiente trama I necesaria para construir el primer GOP del canal deseado. En la figura 3, se muestran

1 Random Access Point 2Instant Channel Change.

dos versiones de esta solución a) para baja resolución y b) para alta resolución. En el caso de la sintonización en baja resolución se suele emplear RAP’s trimestrales (como se muestra en la figura 3a, la cual está compuesta de una trama I seguida de dos tramas P cada 0,5 segundos. Cuando el cliente cambia de canal, en el tiempo t recibirá la trama I del Flujo secundario (la cual es de baja resolución respecto al Flujo principal), las tramas siguientes del Flujo secundario P seguirán siendo insertadas en el buffer del cliente hasta que llegue una trama I al Flujo principal, cuando esto ocurra, el Flujo secundario es detenido.

Figura 3. Sintonización en el Flujo: a) baja resolución

y b) alta resolución.

Sintonización del cambio de canal a partir de servidor de sintonización Multicast (23).

Este servidor se ubica cerca al nodo de acceso de la red, tiene la cualidad de recibir todos los Flujos Multicast (canales) y almacenar cierta cantidad de periodos RAPs o GOPs de cada Flujo (de cada canal de contenido televisivo). En la figura 4 se observa el esquema general de este tipo de servidores dentro de la red.

Figura 4. Esquema general de sintonización de cambio

de canal a partir de servidores de sintonización.

Cuando el cliente sintoniza el canal por primar vez, la sintonización empieza desde el ultimo RAP provisto por el Stream secundario; cuando el cliente realiza un cambio de canal, el servidor envía dos Flujos hacia el buffer del cliente: uno Multicast (contenido original) y otro Unicast (Flujo secundario, denotado con líneas punteadas en la figura 4 el cual emite el último RAP previamente almacenado (tramas I de baja o alta resolución, retrasadas n milisegundos equivalentes a la duración de n GOPs o RAPs); para prevenir traslapo de tramas I, el buffer del cliente tiene como prioridad recibir tramas I del Flujo principal.

978‐1‐4673‐1269‐1/12/$31.00 ©2012 IEEE

Sintonización del cambio de canal a partir de servidor de sintonización Unicast.

Al igual que el servidor de sintonización, este servidor recibe todos los flujos Multicast (canales) y realiza un Buffering (almacenamiento transitorio) del periodo actual del RAP de cada flujo. De modo que si un usuario requiere sintonizar un canal, este servidor inicia la emisión del canal solicitado a partir del último RAP almacenado. A diferencia del servidor de sintonización Multicast, el efecto secundario que el cliente percibirá, será una pequeña descompensación respecto al contenido en tiempo real, la cual está definida como 0 Offset RAP . En la figura 5 se observa el diagrama de este tipo de solución, donde se tiene que a diferencia del servidor de sintonización Multicast, este servidor tiene la cualidad de no agregar carga adicional en lo concerniente a la reducción del retardo en el cambio de canal, si se ubica lo más cerca posible al primer equipo de acceso desde el punto de vista del usuario (por ejemplo cerca al DSLAM o MSAN).

Figura 5. Servidor de sintonización Unicast.

B. Servidor de comunidades vecinas.

La solución que se plantea en (25) pretende acercar la distribución de video al cliente a través de servidores Proxy por “comunidades vecinas”. Estas comunidades estarían literalmente formadas por vecinos geográficos dentro de la red del operador para facilitar el cambio de canal, como se muestra en la figura 6. El controlador de la vecindad sería un servidor Proxy, quien controlaría qué usuarios pueden pertenecer a sus grupos: hacia la red del operador, el servidor Proxy haría la solicitud de canal cada vez que los usuarios lo requieran, y se presentaría como un único cliente ante el servidor de video; del lado de los usuarios vecinos, el servidor Proxy actuaría como controlador de la distribución del contenido e intérprete de los usuarios. El servidor Proxy debería usar Snooping en IGMP para actuar como pasarela y controlador de contenidos. Con esta solución se disminuye la carga sobre la ultima milla mientras se controla el retardo de unión/retiro del canal (mientras sea considerado favorito) (16), pero también se presenta la dificultad de que el servidor debe ser realizar cada solicitud nueva de acuerdo a las solicitudes del cliente, lo que implica que el primer cliente que solicite un canal recibirá todo el retraso de la transmisión desde su STB hasta el servidor de video real; si bien ahorra tráfico en la red y permite que se desplieguen rápidamente los

canales previamente solicitados (y mantenidos localmente), los canales que no han sido “vistos” previamente tendrían el retraso completo de la red, además de los costos de operación y mantenimiento por este tipo de servidores cercanos a los usuarios.

Figura 6. Servidor de comunidades vecinas.

C. Envió de canales adyacentes.

Una solución presentada en (14) plantea el envío de los canales adyacentes al canal que está siendo visualizado en el momento. Esto implica que cuando el STB solicita un canal debe recibir de manera adicional los dos canales adyacentes (n-1, n, n+1). Esto implica que en el STB siempre esté disponible el canal siguiente y anterior al canal desplegado; si bien esta solución permite despliegue rápido, el costo en ancho de banda es bastante alto. Para disminuir esta sobrecarga de ancho de banda, se plantea usar Picture in Picture, transmitiendo una versión “reducida” de la imagen del canal siguiente, encogiendo los requerimientos de ancho de banda para la transmisión. En (24) se indica que esta solución se usa de manera efectiva transmitiendo únicamente durante los periodos de Zapping y hasta un minuto después del evento, contando de manera adicional con el contenido directamente en la red de acceso, como se muestra en la figura 7.

Figura 7. Envío de Canales Adyacentes.

Esta solución presenta la desventaja de saturar el canal de transmisión en la red de acceso aún con la disminución de la calidad de la imagen haciendo de última milla un cuello de botella por el ancho de banda requerido, además es progresivamente complejo en la medida en que se incrementen el número de STB’s en el cliente y solo mejora el cambio de canal de manera progresiva.

978‐1‐4673‐1269‐1/12/$31.00 ©2012 IEEE

V. CONCLUSIONES Y CONSIDERACIONES.

Las técnicas anteriormente planteadas para reducir el retardo en el cambio de canal evidencian dos vertientes sobre las cuales se mueve el estado del arte: a) la primera consiste en la emisión de un Stream auxiliar proveniente desde el interior de la red (Core), encargado de emitir tramas I de mediana o baja resolución, a un Bit Rate acelerado, con el propósito de llenar rápidamente el buffer del cliente y así enmascarar el efecto visualizado en la terminal de video cuando se lleva a cabo el cambio de canal; b) la segunda vertiente radica en ubicar servidores de retransmisión cerca al IP-Dslam (externos a la capa Core y agregación) y enviar un segundo Stream auxiliar de tramas I, la diferencia de esta tendencia respecto a la anterior reside en no cargar la capa de agregación con estos Streams auxiliares. La estimación de estas técnicas en procura de solucionar el retardo en el cambio de canal está condicionada al tipo de enlace que se disponga en la última milla y a las cualidades disponibles en los equipos de acceso de la red: la dispersión geográfica de usuarios, aplicación de políticas para diferenciar tráfico a nivel ATM, caracterización de servicios adicionales y por lo tanto anchos de banda consumidos. Para medir el desempeño de la red multicast para la entrada al cliente final se tiene una serie de dispositivos comerciales, los cuales se ubican en la premisa del usuario (27), con el objeto de observar el comportamiento del servicio en el penúltimo tramo de red. Esta recomendación se realiza porque generalmente se conoce y mejora la calidad de la red núcleo y de la red de transporte, pero se omite la red de acceso, particularmente en la última milla (28), que es donde todos los planteamientos presentan sobrecarga en el ancho de banda y enfrentan un cuello de botella que puede hacer cualquier planteamiento inviable. VI. REFERENCIAS

1. O’Driscoll, Gerard. Next Generation IPTV Services and Technologies. New Jersey : Wiley-Interscience, 2008. 2. NTSC-TV. NTSC-TV - Tutorials on TV Basics & more. NTSC-TV - Tutorials on TV Basics & more. [En línea] [Citado el: 05 de 01 de 2011.] www.ntsc-tv.com. 3. Challenges in IPTV. Delaney, Alan. United Kingdom : ERICSSON - IPTV Bussines Development, 2008. 4. A benchmark for fast cannel change In IPTV. Ivan Kopilovic, Marcel Wagner. s.l. : Nokia Siemens Networks GmbH & Co.KG, 2006. 5. Triple-play Services Quality of Experience (QoE) Requirements. DSL Forum. s.l. : DSL Forum, 2006, Technical Report TR-126.

6. Fuzzy Joint Encoding and Statistical Multiplexing of Multiple Video Sources with Independent Quality of Services for Streaming over DVB-H. Bouazizi, Imed. Gabbouj, Moncef. Rezaei, Mehdi. s.l. : IEEE, 2007. 7. ITS. Video Quality Research. Video Quality Research. [En línea] [Citado el: 21 de 9 de 2010.] http://www.its.bldrdoc.gov/n3/video/examples_of_digital_video_impair/index.php. 8. ITU-T Y.1544; Multicast IP performance parameters. ITU-T. s.l. : ITU-T, 2008. 9. RFC 3393, IP Packet Delay Variation Metric for IP Performance Metrics (IPPM). C. Demichelis [Telecomitalia Lab], P. Chimento [Ericsson IPI]. s.l. : IETF, November 2002. 10. Channel Change Delay in IPTV Systems. Uzunalioglu, Huseyin. s.l. : Alcatel-Lucent, 2009. 11. ITU-T. Definition of Quality of Experience (QoE). Bled, Slovenia : FG IPTV-IL-0050, Focus Group On IPTV, May 2007. 12. An Identification of Correlation between Network QoS and Video Quality Index for IPTV Services. Jaehyung Bae, Hong-Shik Park, Young Min Chin and Han-Choon Park. Daejon : IEEE, 2009. 13. ITU-T G.1080; Quality of experience requirements for IPTV services. ITU-T. s.l. : ITU-T, December 2008. 14. Caracterización de los individuos propensos al cambio de canal de televisión. Juan Carlos Gázquez-Abad, David Jiménez-Castillo, Elvira sáez-González, Manuel sánchez-Pérez. s.l. : Sistema de Información Científica Redalyc, Segundo trimestre 2000, Universia Bussines Review, Vols. ISSN: 1698-5117. 15. Improvement of Channel Zapping Time in IPTV Services Using the Adjacent Groups Join-Leave Method. Chunglae Cho, Intak Han, Yongil Jun and Hyeongho Lee. s.l. : IEEE, 2004. 16. DVB-Scene June 2010. DVB. s.l. : DVB, 2010, DVB-Scene. 17. Statistical Analysis of Multicast versus Instant Channel Changing Unicast IPTV Provisioning. Janevski, Tony. Vanevski, Zoran. s.l. : Telecommunications Forum, 2008. 18. IXIA Communications. IPTV - Channel Change Performance Testing. IPTV - Channel Change Performance Testing. [En línea] [Citado el: 10 de 12 de 2010.] http://www.ixiacom.com/library/test_plans/display?skey=iptv-channel-change. 19. An Implementation of the Broadband Home Gateway supporting Multi-Channel IPTV Service. Wan-Ki Park, Chang-Sic Choi, Youn-Kwae Jeong, Intark Han. s.l. : IEEE, 2006. 20. Generic coding of moving pictures and associated audio information: Systems. ISO/IEC International Organization for Standardization. s.l. : ISO, 2000, ISO/IEC13818-1:2000. . 21. A Unified Approach for Repairing Packet Loss and Accelerating Channel Changes in Multicast IPTV.

978‐1‐4673‐1269‐1/12/$31.00 ©2012 IEEE

Ali C. Begen, Neil Glazebrook , William Ver Steeg. s.l. : Cisco Systems, 2009. 22. ATSC Digital Television Standard: Part 4 – MPEG-2 Video System Characteristics. ATSC. s.l. : ATSC, 2009, Document A/53 Part 4:2009. 23. Multicast Instant Channel Change in IPTV Systems. Damodar Banodkar, K.K. Ramakrishnan, Shivkumar Kalyanaraman, Alexandre Gerber, Oliver Spatscheck. s.l. : IEEE, 2008. 24. Fast Eficient Channel Change. Boyce, Jill M y Tourapis, Alexis M. s.l. : IEEE, 2005. 25. Effect of Multicast on IPTV Channel Change Performance. Zlatan Begic, Melika Bolic , Himzo Bajric. s.l. : ELMAR, 2008. 26. Adding the Community to Channel Surfing A new Approach to IPTV Channel Change. Marie-José Montpetit, Henry Holtzman, Herb Calhoun. s.l. : Motorola, 2009. 27. Channel Smurfing. Crawford, John y Ramos, Fernando. s.l. : IEEE, 2010. 28. ITU-T G.1081 Performance monitoring points for IPTV. ITU-T. s.l. : ITU-T, 2008. 29. Packet Loss Characteristics of IPTV-like Traffic on Residential Links. Ellin, Martins. Perkins, Colin. s.l. : University of Glasgow, 2009. 30. Watching television over an IP network. M. Cha, P. Rodriguez, J. Crowcroft, S. Moon, and X. Amatrianin,. s.l. : ACM IMC, 2008. 31. Internet Multicasting of IPTV With Essentially-Zero Delay Jitter. Szymanski, T.H. y Gilbert, D. s.l. : IEEE, 2009, Dept. of Electr. & Comput. Eng.