<?xml version="1.0" encoding="ISO-8859-1"?><article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<front>
<journal-meta>
<journal-id>1405-7743</journal-id>
<journal-title><![CDATA[Ingeniería, investigación y tecnología]]></journal-title>
<abbrev-journal-title><![CDATA[Ing. invest. y tecnol.]]></abbrev-journal-title>
<issn>1405-7743</issn>
<publisher>
<publisher-name><![CDATA[Universidad Nacional Autónoma de México, Facultad de Ingeniería]]></publisher-name>
</publisher>
</journal-meta>
<article-meta>
<article-id>S1405-77432008000300003</article-id>
<title-group>
<article-title xml:lang="es"><![CDATA[Reducción del retardo en el cambio de canal en servicios IPTV]]></article-title>
<article-title xml:lang="en"><![CDATA[Reduction of channel zapping delay in IPTV services]]></article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<name>
<surname><![CDATA[Moumtadi]]></surname>
<given-names><![CDATA[F.]]></given-names>
</name>
<xref ref-type="aff" rid="A01"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname><![CDATA[Escobar-Argota]]></surname>
<given-names><![CDATA[M.]]></given-names>
</name>
<xref ref-type="aff" rid="A01"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname><![CDATA[López-Moreno]]></surname>
<given-names><![CDATA[R.]]></given-names>
</name>
<xref ref-type="aff" rid="A01"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname><![CDATA[Landeros-Ayala]]></surname>
<given-names><![CDATA[S.]]></given-names>
</name>
<xref ref-type="aff" rid="A01"/>
</contrib>
</contrib-group>
<aff id="A01">
<institution><![CDATA[,UNAM Facultad de Ingeniería ]]></institution>
<addr-line><![CDATA[ ]]></addr-line>
</aff>
<pub-date pub-type="pub">
<day>00</day>
<month>09</month>
<year>2008</year>
</pub-date>
<pub-date pub-type="epub">
<day>00</day>
<month>09</month>
<year>2008</year>
</pub-date>
<volume>9</volume>
<numero>3</numero>
<fpage>217</fpage>
<lpage>229</lpage>
<copyright-statement/>
<copyright-year/>
<self-uri xlink:href="http://www.scielo.org.mx/scielo.php?script=sci_arttext&amp;pid=S1405-77432008000300003&amp;lng=en&amp;nrm=iso"></self-uri><self-uri xlink:href="http://www.scielo.org.mx/scielo.php?script=sci_abstract&amp;pid=S1405-77432008000300003&amp;lng=en&amp;nrm=iso"></self-uri><self-uri xlink:href="http://www.scielo.org.mx/scielo.php?script=sci_pdf&amp;pid=S1405-77432008000300003&amp;lng=en&amp;nrm=iso"></self-uri><abstract abstract-type="short" xml:lang="es"><p><![CDATA[En el artículo se analiza el retraso que se presenta en un sistema de IPTV cuando un usuario cambia de canal y se considera un nuevo algoritmo para reducirlo. Basado en el método de grupos adyacentes, se reduce el tiempo de adquisición del nuevo canal haciendo el pedido no solamente de ese canal, sino también de los canales adyacentes a él, tomando como principio que existe un ancho de banda suficiente y un principio de multicast de la transmisión (Chunglae, 2004). En la parte final del mismo, se comparan los resultados obtenidos contra los actuales y se identifican las posibilidades del algoritmo examinado.]]></p></abstract>
<abstract abstract-type="short" xml:lang="en"><p><![CDATA[This paper analyses the existing delay within an IPTV system when a user selects an other channel, and a new algorithm is used to reduce it. Based on the adjacent groups method, which reduces the time acquisition of a new channel placing the order not only for that channel but also for the adjacent channels. There are two principles under coonsideration, one that there exists a sufficient bandwidht, and the other, a multicast transmission (Chunglae, 2004). At the end of the paper, the obtained results are compared against the present ones and the possibilities of the algorithm are determined.]]></p></abstract>
<kwd-group>
<kwd lng="es"><![CDATA[IPTV]]></kwd>
<kwd lng="es"><![CDATA[método de Grupos Adyacentes]]></kwd>
<kwd lng="es"><![CDATA[retardo de cambio de canal]]></kwd>
<kwd lng="es"><![CDATA[HG]]></kwd>
<kwd lng="es"><![CDATA[IGMP]]></kwd>
<kwd lng="en"><![CDATA[IPTV]]></kwd>
<kwd lng="en"><![CDATA[Adjacent Groups method]]></kwd>
<kwd lng="en"><![CDATA[channel zapping delay]]></kwd>
<kwd lng="en"><![CDATA[HG]]></kwd>
<kwd lng="en"><![CDATA[IGMP]]></kwd>
</kwd-group>
</article-meta>
</front><body><![CDATA[ <p align="justify"><font face="verdana" size="4">Estudios e investigaciones recientes</font></p>      <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>      <p align="center"><font face="verdana" size="4"><b>Reducci&oacute;n  del   retardo  en   el  cambio de  canal en   servicios   IPTV</b></font></p>      <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>      <p align="center"><font face="verdana" size="3"><b>Reduction   of  channel  zapping  delay  in   IPTV services</b></font></p>      <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>      <p align="center"><font face="verdana" size="2"><b>F. Moumtadi, M. Escobar&#150;Argota, R. L&oacute;pez&#150;Moreno y S. Landeros&#150;Ayala</b></font></p>      <p align="center"><font face="verdana" size="2">&nbsp;</font></p>      <p align="justify"><font face="verdana" size="2"><i>Facultad de Ingenier&iacute;a, UNAM, M&eacute;xico E&#150;mails: </i><a href="mailto:fatimoum@hotmail.com" target="_blank">fatimoum@hotmail.com</a>, <a href="mailto:marlene_escobar_a@yahoo.com.mx">marlene_escobar_a@yahoo.com.mx</a>, <a href="mailto:ricardo_lopez&#8211;m@yahoo.com.mx" target="_blank">ricardo_lopez-m@yahoo.com.mx</a> y <a href="mailto:sland@fi&#8211;b.unam.mx" target="_blank">sland@fi-b.unam.mx</a></font></p>      <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>      ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2">Recibido: diciembre de 2006    <br>   Aceptado: enero de 2008</font></p>      <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>      <p align="justify"><font face="verdana" size="2"><b>Resumen</b></font></p>      <p align="justify"><font face="verdana" size="2">En el art&iacute;culo se analiza el retraso que se presenta en un sistema de IPTV cuando un usuario cambia de canal y se considera un nuevo algoritmo para reducirlo. Basado en el m&eacute;todo de grupos adyacentes, se reduce el tiempo de adquisici&oacute;n del nuevo canal haciendo el pedido no solamente de ese canal, sino tambi&eacute;n de los canales adyacentes a &eacute;l, tomando como principio que existe un ancho de banda suficiente y un principio de multicast de la transmisi&oacute;n (Chunglae, 2004). En la parte final del mismo, se comparan los resultados obtenidos contra los actuales y se identifican las posibilidades del algoritmo examinado.</font></p>      <p align="justify"><font face="verdana" size="2"><b>Descriptores: </b>IPTV, m&eacute;todo de Grupos Adyacentes, retardo de cambio de canal, HG, IGMP.</font></p>      <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>      <p align="justify"><font face="verdana" size="2"><b><i>Abstract</i></b></font></p>      <p align="justify"><font face="verdana" size="2"><i>This paper analyses the existing delay within an IPTV system when a user selects an other channel, and a new algorithm is used to reduce it. Based on the adjacent groups method, which reduces the time acquisition of a new channel placing the order not only for that channel but also for the adjacent channels. There are two principles under coonsideration, one that there exists a sufficient bandwidht, and the other, a multicast transmission (Chunglae, 2004). At the end of the paper, the obtained results are compared against the present ones and the possibilities of the algorithm are determined.</i></font></p>      <p align="justify"><font face="verdana" size="2"><b><i>Keywords: </i></b><i>IPTV, Adjacent Groups method, channel zapping delay, HG, IGMP</i></font></p>      ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2">&nbsp;</font></p>      <p align="justify"><font face="verdana" size="2"><b>Introducci&oacute;n</b></font></p>      <p align="justify"><font face="verdana" size="2">A lo largo de los &uacute;ltimos a&ntilde;os, el incremento del ancho de banda en las redes de telecomunicaciones ha posibilitado la adopci&oacute;n, por parte de los proveedores de servicios, del sistema de televisi&oacute;n IPTV (Internet Protocol Television), que gestiona la informaci&oacute;n de sus programas en un esquema multicast posibilitando al proveedor a no transmitir su programaci&oacute;n de manera ininterrumpida esperando que alg&uacute;n usuario se conecte al sistema, sino que el contenido &uacute;nicamente llegue al usuario cuando &eacute;ste lo solicite. Esta nueva modalidad exige un mayor ancho de banda disponible en el sistema, pero permite, en cambio, ofrecer de manera sencilla y eficiente servicios de televisi&oacute;n digital de siguiente generaci&oacute;n sobre redes de banda ancha como: Oferta ilimitada de canales de televisi&oacute;n digital y m&uacute;sica, programaci&oacute;n de pago por evento, video por demanda, grabaci&oacute;n personalizada de video, publicidad interactiva y servicios de informaci&oacute;n (Mu&ntilde;iz, 2005).</font></p>      <p align="justify"><font face="verdana" size="2">Estas ventajas se ven limitadas; por la necesidad de disminuir el retardo que se presenta cuando el usuario cambia el canal seleccionado, que puede variar de 2 a 3 seg (Full Service&#150; VDSL, 2002), (Cisco Systems, 2006a), a fin de asegurar la calidad de servicio.</font></p>      <p align="justify"><font face="verdana" size="2">La televisi&oacute;n digital tradicional por cable, basada en receptores de tipo STB (Set Top Box), tiene la capacidad de recibir todos los canales del sistema televisivo en forma simult&aacute;nea, lo que posibilita al usuario cambiar de canal sin retardos perceptibles. En contraposici&oacute;n, el sistema IPTV permite la gesti&oacute;n de flujos de canales individuales a la vez; la selecci&oacute;n de otro canal genera un nuevo flujo de informaci&oacute;n, lo que provoca un retardo en la transmisi&oacute;n de la se&ntilde;al (Mu&ntilde;iz, 2005), (Siemens Communications and Juuniper Networks, 2006).</font></p>      <p align="justify"><font face="verdana" size="2">En la actualidad, se han presentado varias propuestas para disminuir el retardo como: la reducci&oacute;n en el tiempo de implementaci&oacute;n del STB, optimizaci&oacute;n en el dise&ntilde;o de la red, decodificaci&oacute;n y desencriptaci&oacute;n de datos, los cuales representan el mayor porcentaje del retardo (Cisco Systems, 2006).</font></p>      <p align="justify"><font face="verdana" size="2">En este art&iacute;culo se trabaja s&oacute;lo en el retardo de la red, el cual se presenta &uacute;nicamente para IPTV, a trav&eacute;s de la implementaci&oacute;n del m&eacute;todo de grupos adyacentes.</font></p>      <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>      <p align="justify"><font face="verdana" size="2"><b>Arquitectura de IPTV y proceso de cambio del canal</b></font></p>      <p align="justify"><font face="verdana" size="2"><a href="/img/revistas/iit/v9n3/a3f1.jpg" target="_blank">La figura 1</a> muestra la arquitectura de red y los componentes del sistema IPTV. Esta topolog&iacute;a considera un esquema jer&aacute;rquico. En la parte receptora, la puerta de enlace del usuario HG (Home Gateway) contiene el flujo de todos los STB conectados a &eacute;l; el Multiplexor de acceso a la l&iacute;nea de abonado digital DSLAM (Digital Subscriber Line Access Multiplexer) concentra, a su vez, el flujo de todos los HG a &eacute;l directamente conectados y, por &uacute;ltimo, el LHR (Last Hop Router) concentra el flujo de todos los DSLAM's. En la parte transmisora, el FHR (First Hop Router) contiene el flujo de todos los canales del sistema IPTV, mientras que la cabecera del sistema (IPTV headend) es la encargada de distribuir, almacenar y administrar todos los contenidos multicast del sistema IPTV (Chunglae, 2004), (Full Service&#150;VDSL, 2002) y (Cisco Systems, 2006a).</font></p>      ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2">Para la uni&oacute;n a un flujo multicast, el STB usa el protocolo de gesti&oacute;n de grupos en Internet IGMP (Internet Group Management Protocol) (Fenner, 1997), que se encarga de enviar mensajes de entrada y abandono de grupo (Join&#150;Leave messages) al ruteador que le gestiona, el HG.</font></p>      <p align="justify"><font face="verdana" size="2">El HG responde a los mensajes de solicitud de membres&iacute;a (Membership query messages) que el DSLAM le solicita para verificar su estado por medio de los mensajes de reporte de membres&iacute;a (Membership report messages). El HG tambi&eacute;n utiliza IGMP, actuando como si fuera &eacute;l mismo un host. De esta manera si el canal solicitado en el mensaje de entrada al grupo ya est&aacute; disponible en el HG, &eacute;ste simplemente copiar&aacute; el flujo multicast y lo transmitir&aacute; inmediatamente al STB; si no, el proceso anterior se repite para los ruteadores siguientes, el DSLAM y el LHR. El LHR debe soportar tanto el IGMP para comunicarse con el DSLAM como el Protocolo Multicast Independiente de Baja Densidad (Protocol Independent Multicast Sparse&#150;Mode) PIM&#150;SM (Fenner et al., 2003) para comunicarse con el FHR. El LHR tambi&eacute;n env&iacute;a mensajes PIM&#150;SM al FHR para notificarle que el estado de membres&iacute;a a grupos multicast ha cambiado, logrando de esta manera que el flujo multicast correspondiente a un canal se detenga o se retransmita un nuevo flujo.</font></p>      <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>      <p align="justify"><font face="verdana" size="2"><b>M&eacute;todo de grupos adyacentes</b></font></p>      <p align="justify"><font face="verdana" size="2">El retardo en sistemas IPTV debe de entenderse como "el tiempo transcurrido entre el env&iacute;o del primer mensaje de abandono de grupo hasta la recepci&oacute;n del primer paquete de flujo multicast por parte del STB" (Chunglae, 2004), (Full Service&#150;VDSL, 2002) y (Cisco Systems, 2006a) y una de las propuestas actuales para reducir su magnitud es la aplicaci&oacute;n del m&eacute;todo de grupos adyacentes: asumiendo que el ancho de banda de la red de acceso (esto es, entre el LHR y el HG) es lo suficientemente grande como para soportar diversos flujos multicast de manera simult&aacute;nea, ante la solicitud por parte del STB de adquirir un nuevo canal mediante el env&iacute;o de un mensaje de entrada al grupo, el HG podr&iacute;a no s&oacute;lo enviar el mensaje de entrada correspondiente al grupo de ese canal, sino tambi&eacute;n para los grupos de los canales adyacentes (<a href="#f2">Figura 2</a>).</font></p>      <p align="center"><font face="verdana" size="2"><a name="f2"></a></font></p>      <p align="center"><font face="verdana" size="2"><img src="/img/revistas/iit/v9n3/a3f2.jpg"></font></p>      <p align="justify"><font face="verdana" size="2">De esta manera, los flujos multicast pertenecientes a los canales adyacentes del canal solicitado previamente por el STB estar&aacute;n siempre disponibles en el HG; cuando el STB solicite la adquisici&oacute;n de un canal adyacente, el HG podr&aacute; enviar el tr&aacute;fico multicast respectivo inmediatamente, lo que permite reducir considerablemente el retardo en el cambio de canal (Chunglae, 2004).</font></p>      <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>      <p align="justify"><font face="verdana" size="2"><b>Simulaci&oacute;n de la implementaci&oacute;n del m&eacute;todo de grupos adyacentes</b></font></p>      ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2">La simulaci&oacute;n fue desarrollada en el software Matlab y se realiz&oacute; en base al sistema mostrado en la <a href="/img/revistas/iit/v9n3/a3f1.jpg" target="_blank">figura 1.</a> Los elementos en conjunto representan s&oacute;lo una secci&oacute;n de un sistema para IPTV que da servicio a una gran cantidad de suscriptores. Cuando un STB cambie de canal se medir&aacute; el retardo en la adquisici&oacute;n de canal (Join latency) de acuerdo a la disponibilidad del canal deseado en los ruteadores; es decir, si el canal solicitado se encuentra disponible en el HG, el tiempo de adquisici&oacute;n ser&aacute; de 50 ms; si el mensaje de entrada al grupo tiene que viajar hasta el DSLAM, el tiempo ser&aacute; de 150 ms y si es hasta el LHR o FHR, ser&aacute; de 500 ms o 600 ms, respectivamente (Full Service&#150;VDSL, 2002) y (Cisco Systems, 2006b), (<a href="#f3">Figura 3</a>).</font></p>      <p align="center"><font face="verdana" size="2"><a name="f3"></a></font></p>      <p align="center"><font face="verdana" size="2"><img src="/img/revistas/iit/v9n3/a3f3.jpg"></font></p>      <p align="justify"><font face="verdana" size="2">El m&eacute;todo de grupos adyacentes fue aplicado con dos canales adyacentes, uno hacia arriba y otro hacia abajo, y se analiz&oacute; su influencia en el tiempo de cambio de canal que experimentan los usuarios.</font></p>      <p align="justify"><font face="verdana" size="2">Para la simulaci&oacute;n se tom&oacute; en cuenta que se realizan diez cambios de canal entre los tres STB's del sistema. Se eligi&oacute; un STB al azar para cada cambio. Los cambios de canal se efectuaron de dos formas distintas, cambios hacia canales aleatorios y cambios hacia canales adyacentes.</font></p>      <blockquote>        <p align="justify"><font face="verdana" size="2">Se analizaron cuatro escenarios diferentes:</font></p>        <p align="justify"><font face="verdana" size="2">1. Metodolog&iacute;a de cambio tradicional con cambios hacia canales adyacentes;</font></p>        <p align="justify"><font face="verdana" size="2">2. Metodolog&iacute;a de cambio mejorada con cambios hacia canales adyacentes;</font></p>        <p align="justify"><font face="verdana" size="2">3. Metodolog&iacute;a de cambio tradicional con cambios hacia canales aleatorios;</font></p>        ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2">4. Metodolog&iacute;a de cambio mejorada con cambios hacia canales aleatorios.</font></p>  </blockquote>      <p align="justify"><font face="verdana" size="2">Para representar la cantidad total de suscriptores del sistema IPTV se a&ntilde;adieron m&aacute;s usuarios al DSLAM, mismos que se cargaron al LHR m&aacute;s un flujo del 75% total de los canales en el LHR para mantener una configuraci&oacute;n PIM&#150;SM.</font></p>      <p align="justify"><font face="verdana" size="2">Sobre cada escenario se hicieron variar tanto el n&uacute;mero de usuarios como el de canales para analizar la influencia de estos en el tiempo de cambio de canal.</font></p>      <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>      <p align="justify"><font face="verdana" size="2"><b>An&aacute;lisis de resultados</b></font></p>      <p align="justify"><font face="verdana" size="2">Los resultados se presentan como el promedio de los diez cambios de canal para diez iteraciones del programa.</font></p>      <p align="justify"><font face="verdana" size="2"><a href="/img/revistas/iit/v9n3/a3f4.jpg" target="_blank">La figura 4</a> ilustra los resultados obtenidos para los escenarios 1 y 2 tomando en cuenta 100 canales y 50 usuarios. Se observa que al aplicar el m&eacute;todo de grupos adyacentes, existe una reducci&oacute;n considerable del tiempo de adquisici&oacute;n de canal cuando el usuario cambia a canales adyacentes. Con el m&eacute;todo tradicional se obtiene un promedio de las 10 iteraciones de alrededor de 380 ms. El tiempo de retardo con el m&eacute;todo de grupos adyacentes se mantiene constante y con un valor de 50 ms, debido a que los canales que son solicitados por los STB's est&aacute;n siempre disponibles dentro del HG; por lo tanto, el STB adquirir&aacute; el canal de forma instant&aacute;nea. La reducci&oacute;n que se alcanz&oacute; con el m&eacute;todo fue de 330 ms aproximadamente.</font></p>      <p align="justify"><font face="verdana" size="2"><a href="/img/revistas/iit/v9n3/a3f5.jpg" target="_blank">La figura 5 </a>ilustra los resultados para los escenarios 3 y 4 para los mismos 100 canales y 50 usuarios. Se observa que el retardo se mantiene en un promedio de 380 ms; esta vez, con el m&eacute;todo implementado se obtiene un retardo con un valor promedio aproximado de 200 ms, logrando una reducci&oacute;n del tiempo de adquisici&oacute;n cerca de 180 ms. Esta reducci&oacute;n del tiempo no es tan amplia como cuando se cambia a canales adyacentes, debido a que, con la disponibilidad de los canales adyacentes en el HG, el DSLAM o el LHR, los canales solicitados pueden o no estar disponibles en estos ruteadores.</font></p>      <p align="justify"><font face="verdana" size="2"><a href="/img/revistas/iit/v9n3/a3t1.jpg" target="_blank">La tabla 1</a> presenta los resultados de la simulaci&oacute;n al variar el n&uacute;mero de canales y el n&uacute;mero de usuarios.</font></p>      <p align="justify"><font face="verdana" size="2">Cuando aumentamos el n&uacute;mero de canales se aprecia un crecimiento en el retardo (<a href="/img/revistas/iit/v9n3/a3t1.jpg" target="_blank">Tabla 1</a>), debido a que es menos probable que el canal deseado est&eacute; siendo visto por alg&uacute;n otro usuario, por lo que el canal requerido se encontrar&aacute; disponible m&aacute;s lejos del usuario que solicita el canal. Por el contrario, el retardo disminuye si decrece el n&uacute;mero de canales, ya que es m&aacute;s probable que el canal deseado est&eacute; siendo visto por alg&uacute;n otro usuario, as&iacute; el canal requerido se encontrar&aacute; disponible m&aacute;s cerca del usuario que solicite el canal.</font></p>      ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2">Ahora bien, si en vez de variar el n&uacute;mero de canales variamos el n&uacute;mero de usuarios, al aumentar &eacute;stos se tiene una disminuci&oacute;n del tiempo de retardo, a causa de que ser&aacute; m&aacute;s factible que el canal deseado ya est&eacute; siendo visto por alg&uacute;n otro usuario del sistema, por lo que el canal se hallar&aacute; disponible m&aacute;s cerca del STB que hace la petici&oacute;n de adquisici&oacute;n. El retardo aumenta si disminuimos el n&uacute;mero de usuarios, ya que es menos probable que el canal requerido se halle m&aacute;s cerca del STB que lo demanda.</font></p>      <p align="justify"><font face="verdana" size="2">Para analizar mejor c&oacute;mo var&iacute;a el tiempo de adquisici&oacute;n de canal, respecto al n&uacute;mero de canales y al n&uacute;mero de usuarios con las dos metodolog&iacute;as de cambio de canal, se realizaron las gr&aacute;ficas de las <a href="/img/revistas/iit/v9n3/a3f6.jpg" target="_blank">figuras 6</a> y <a href="/img/revistas/iit/v9n3/a3f7.jpg" target="_blank">7</a> cuando los usuarios cambian a canales adyacentes y a canales aleatorios.</font></p>      <p align="justify"><font face="verdana" size="2"><a href="/img/revistas/iit/v9n3/a3f6.jpg" target="_blank">La figura 6</a> muestra las curvas para 25, 50 y 100 usuarios haciendo un barrido de canales bajo las condiciones de los escenarios 1 y 2. La diferencia entre los resultados obtenidos por ambas metodolog&iacute;as tambi&eacute;n se ilustra. Se aprecia que al aumentar el n&uacute;mero de canales el retardo aumenta desde 50 ms hasta un valor cercano a los 500 ms<sup><a href="#nota">1</a></sup>, disminuyendo al aumentar el n&uacute;mero de usuarios para la metodolog&iacute;a de cambio tradicional. Para la metodolog&iacute;a de cambio mejorada el retardo se mantiene constante en 50 ms<sup><a href="#nota">1</a></sup>. Para analizar el comportamiento de la reducci&oacute;n del tiempo de adquisici&oacute;n de canal empleando el m&eacute;todo de reducci&oacute;n se obtuvo la curva de la diferencia entre los resultados adquiridos con el m&eacute;todo tradicional y los adquiridos con el m&eacute;todo mejorado para 25, 50 y 100 usuarios; en esta &uacute;ltima gr&aacute;fica se puede apreciar qu&eacute; tanto beneficio otorga el m&eacute;todo de grupos adyacentes, el cual se incrementa conforme aumenta el n&uacute;mero de canales y conforme disminuye el n&uacute;mero de usuarios.</font></p>      <p align="justify"><font face="verdana" size="2"><a href="/img/revistas/iit/v9n3/a3f7.jpg" target="_blank">La figura 7 </a>muestra las curvas para 25, 50 y 100 usuarios haciendo un barrido de canales, ahora para los escenarios 3 y 4. La diferencia entre los resultados obtenidos por ambas metodolog&iacute;as tambi&eacute;n se ilustra. Se observa tambi&eacute;n que el retardo crece al aumentar los canales. Al aplicar el m&eacute;todo de grupos adyacentes se observa una peque&ntilde;a reducci&oacute;n del retardo. Se ilustra la diferencia entre los m&eacute;todos tradicional y mejorado, en donde se puede apreciar el ahorro de tiempo que se adquiere con el m&eacute;todo de grupos adyacentes, con respecto al m&eacute;todo tradicional de cambio de canal. Aqu&iacute; el m&aacute;ximo beneficio no se logra conforme al aumento del n&uacute;mero de canales, sino aproximadamente en el punto en el que el n&uacute;mero de canales es igual al doble del n&uacute;mero de usuarios, cuyo valor es cercano a 150 ms. Esto es porque con pocos canales se obtiene gran disponibilidad en el DSLAM, tanto para el m&eacute;todo tradicional como para el mejorado; conforme aumentan los canales la disponibilidad disminuye para los dos m&eacute;todos, pero m&aacute;s con el tradicional, de ah&iacute; que la curva aumenta hasta llegar al m&aacute;ximo beneficio. A partir de este punto, la gr&aacute;fica decrece debido a que la disponibilidad de canales disminuye, ahora m&aacute;s, con el m&eacute;todo de grupos adyacentes.</font></p>      <p align="justify"><font face="verdana" size="2"><a href="/img/revistas/iit/v9n3/a3f8.jpg" target="_blank">La figura 8</a> muestra las curvas para 50, 100 y 200 canales haciendo un barrido del n&uacute;mero de usuarios bajo las condiciones de los escenarios 1 y 2. La diferencia entre los resultados obtenidos por ambas metodolog&iacute;as tambi&eacute;n se ilustra. Observamos, para canales adyacentes, que al aumentar el n&uacute;mero de usuarios el retardo disminuye desde 500 ms hasta llegar al valor de 150 ms<sup><a href="#nota">2</a></sup> tanto para 50, 100 y 200 canales para la metodolog&iacute;a de cambio tradicional. Para la metodolog&iacute;a de cambio mejorada, el retardo se mantiene nuevamente constante en 50 &#91;ms&#93;. En la curva que muestra la diferencia entre los resultados obtenidos por los dos m&eacute;todos, se observa el beneficio logrado al aplicar el m&eacute;todo de grupos adyacentes, el cual decrece conforme aumenta el n&uacute;mero de usuarios y conforme disminuye el n&uacute;mero de canales.</font></p>      <p align="justify"><font face="verdana" size="2"><a href="/img/revistas/iit/v9n3/a3f9.jpg" target="_blank">La figura 9</a> muestra las curvas para 50, 100 y 200 canales, haciendo un barrido del n&uacute;mero de usuarios ahora para los escenarios 3 y 4. La diferencia entre los resultados obtenidos por ambas metodolog&iacute;as tambi&eacute;n se ilustra. Cuando los usuarios cambian a canales aleatorios el retardo disminuye al aumentar el n&uacute;mero de usuarios. Cuando el m&eacute;todo de reducci&oacute;n es aplicado se tiene una peque&ntilde;a reducci&oacute;n del tiempo de adquisici&oacute;n. Se observa nuevamente que el m&aacute;ximo beneficio del m&eacute;todo de grupos adyacentes, cuyo valor es cercano a 150 ms, se obtiene cuando el n&uacute;mero de usuarios es la mitad al n&uacute;mero de canales, debido a los hechos explicados anteriormente.</font></p>      <p align="justify"><font face="verdana" size="2">Finalmente, <a href="#f10">la figura 10</a> muestra un comparativo de los cuatro escenarios, primero para una variaci&oacute;n de canales y 50 usuarios, despu&eacute;s para 100 canales variando los usuarios.</font></p>      <p align="center"><font face="verdana" size="2"><a name="f10"></a></font></p>      <p align="center"><font face="verdana" size="2"><img src="/img/revistas/iit/v9n3/a3f10.jpg"></font></p>      <p align="justify"><font face="verdana" size="2">Se puede apreciar en ambos casos que con el m&eacute;todo tradicional, cambiando a canales adyacentes como a aleatorios, se tiene el mismo retardo, ya que el m&eacute;todo tradicional trata igual a los canales adyacentes como aleatorios.</font></p>      ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2">&nbsp;</font></p>      <p align="justify"><font face="verdana" size="2"><b>Conclusiones</b></font></p>      <p align="justify"><font face="verdana" size="2">Al implementar el m&eacute;todo de grupos adyacentes se obtiene una mejora considerable del retardo si se cambia a canales adyacentes; el retardo tendr&aacute; un valor constante igual al tiempo entre la transmisi&oacute;n del Join message y la recepci&oacute;n del primer paquete del  grupo  multicast,  correspondiente  al  nuevo canal enviado directamente del HG, por lo que el tiempo de adquisici&oacute;n ser&aacute; casi inmediato sin importar el n&uacute;mero de canales o el de usuarios.</font></p>      <p align="justify"><font face="verdana" size="2">En el caso de cambios a canales aleatorios, al implementar el m&eacute;todo de reducci&oacute;n, se logra una reducci&oacute;n del tiempo de adquisici&oacute;n que, si bien no es constante, se consigue la m&aacute;xima reducci&oacute;n de este tiempo cuando el n&uacute;mero de canales es igual al doble del n&uacute;mero de usuarios; fuera de estos valores el m&eacute;todo no ayudar&iacute;a mucho en la reducci&oacute;n del tiempo de cambio a canales aleatorios.</font></p>      <p align="justify"><font face="verdana" size="2">El m&eacute;todo s&oacute;lo servir&aacute; si el ancho de banda de la red de acceso es suficientemente grande para soportar diversos flujos multicast, de lo contrario, simplemente el m&eacute;todo afectar&iacute;a a la calidad de experiencia del usuario en vez de beneficiarla.</font></p>      <p align="justify"><font face="verdana" size="2">El m&eacute;todo de grupos adyacentes es un buen m&eacute;todo para reducir el tiempo de adquisici&oacute;n, que involucra una parte del tiempo de cambio de canal. No obstante, reducir los retardos de la red no es suficiente, sobre todo porque el mayor porcentaje del tiempo de cambio de canal concierne al proceso de decodificaci&oacute;n y al dise&ntilde;o e implementaci&oacute;n del STB. Estos aspectos merecen consideraciones especiales y probablemente, mejores dise&ntilde;os.</font></p>      <p align="justify"><font face="verdana" size="2">Reducir el retardo en el cambio de canal trae consigo un beneficio directo en la calidad de experiencia del usuario, permitiendo a los proveedores la captaci&oacute;n de m&aacute;s suscriptores al sistema y provocando el abaratamiento de las tarifas del servicio.</font></p>      <p align="justify"><font face="verdana" size="2">Adicionalmente, se propone como trabajos a futuro, el an&aacute;lisis estad&iacute;stico para la obtenci&oacute;n del ancho de banda utilizado por la red, de acuerdo a la popularidad de cada canal, al n&uacute;mero total de canales y de suscriptores. Tambi&eacute;n se propone la obtenci&oacute;n de los tiempos reales del retardo mediante la simulaci&oacute;n del sistema en un software de redes o con una maqueta del modelo para recabar los tiempos de acuerdo a la utilizaci&oacute;n del sistema y a la distancia entre los ruteadores multicast.</font></p>      <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>      <p align="justify"><font face="verdana" size="2"><b>Referencias</b></font></p>      ]]></body>
<body><![CDATA[<!-- ref --><p align="justify"><font face="verdana" size="2">Chunglae C. et <i>al. </i>Improvement of channel zapping time in IPTV services using the adjacent groups Join&#150;Leave method. In: 6th International Conference on Advanced Communication Technology, 2004, Vol. II, pp. 971&#150;975.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4242463&pid=S1405-7743200800030000300001&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">Cisco Systems (2006a). Managing delay in IP video networks, USA. Version 1.0.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4242464&pid=S1405-7743200800030000300002&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">Cisco Systems. (2006b). Cisco wire line video/IPTV solution design and implementation Guide, Release 1.1, USA, pp. 376.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4242465&pid=S1405-7743200800030000300003&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">Full Service&#150;VDSL. FS&#150;VDSL Specification, part 2, System Architecture Junio 2002. Full Service&#150;VDSL Committee.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4242466&pid=S1405-7743200800030000300004&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">Fenner B. et <i>al. </i>RFC 2362: Protocol independent multicast&#150;Sparse mode (PIM SM): Protocol specification. Internet Engineering Task Force, Oct 2003.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4242467&pid=S1405-7743200800030000300005&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">Fenner W. RFC 2236: Internet Group Management Protocol, Version 2. Internet Engineering Task Force, Nov 1997.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4242468&pid=S1405-7743200800030000300006&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">Mu&ntilde;iz I. Televisi&oacute;n IP: Una experiencia totalmente personalizada (en l&iacute;nea). Centro de Investigaci&oacute;n e Innovaci&oacute;n en Telecomunicaciones, A.C. (Fecha de consulta Julio 2005). Disponible en: <a href="http://www.cinit.org.mx/articulo.php?idArticulo=34" target="_blank">http://www.cinit.org.mx/articulo.php?idArticulo=34</a></font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4242469&pid=S1405-7743200800030000300007&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">Siemens Communications and Juniper Networks. High Quality and Resilient IPTV Multicast Architecture. Siemens Communications and Juniper Networks. 2006.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4242470&pid=S1405-7743200800030000300008&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><p align="justify"><font face="verdana" size="2">&nbsp;</font></p>      <p align="justify"><font face="verdana" size="2"><b>Semblanza de los autores</b></font></p>      ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2"><i>Fatima Moumtadi. </i>Obtuvo su maestr&iacute;a en sistemas de radiodifusi&oacute;n satelital y su doctorado en televisi&oacute;n en la Facultad de Radiodifusi&oacute;n y Televisi&oacute;n de la Universidad T&eacute;cnica de Comunicaciones e Inform&aacute;tica de Mosc&uacute;, Rusia (MTUCI). Se desarroll&oacute; profesionalmente en el &aacute;rea de Radiofrecuencia. Ha publicado art&iacute;culos en congresos y revistas nacionales e internacionales. Actualmente es profesora de carrera en el Departamento de Telecomunicaciones en la Facultad de Ingenier&iacute;a de la Universidad Nacional Aut&oacute;noma de M&eacute;xico.</font></p>      <p align="justify"><font face="verdana" size="2"><i>Marlene Escobar&#150;Argota. </i>Obtuvo su t&iacute;tulo de ingeniera de telecomunicaciones en la Facultad de Ingenier&iacute;a de la Universidad Nacional Aut&oacute;noma de M&eacute;xico. Actualmente trabaja en la empresa "Syspro Internacional".</font></p>      <p align="justify"><font face="verdana" size="2"><i>Ricardo L&oacute;pez&#150;Moreno. </i>Se t&iacute;tulo como ingeniero en telecomunicaciones en la Facultad de Ingenier&iacute;a de la Universidad Nacional Aut&oacute;noma de M&eacute;xico. A la fecha labora en una empresa que posee y opera redes metropolitanas de fibra &oacute;ptica llamada METRORED.</font></p>      <p align="justify"><font face="verdana" size="2"><i>Salvador Landeros&#150;Ayala. </i>Egres&oacute; de la Facultad de Ingenier&iacute;a, UNAM, con el t&iacute;tulo de ingeniero mec&aacute;nico electricista en el &aacute;rea de comunicaciones. Curs&oacute; la maestr&iacute;a en ciencias de la ingenier&iacute;a de telecomunicaciones en la Universidad Pennsylvania, Estados Unidos. Posteriormente, obtuvo el grado de doctor en ingenier&iacute;a el&eacute;ctrica en la Facultad de Ingenier&iacute;a, UNAM. Ha escrito art&iacute;culos que han sido presentados en congresos y revistas, tanto internacionales como nacionales. Fue miembro del Comit&eacute; de Becas de CONACYT, director del Sistema de Sat&eacute;lites Nacionales y jefe de la Divisi&oacute;n de Ingenier&iacute;a El&eacute;ctrica. Actualmente es jefe de la Divisi&oacute;n de Estudios de Posgrado de la Facultad de Ingenier&iacute;a, UNAM.</font></p>      <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>      <p align="justify"><font face="verdana" size="2"><a name="nota"></a><b>NOTA</b></font></p>      <p align="justify"><font face="verdana" size="2">1 Hay que recordar que estos valores se constituyen mediante el promedio de las 10 iteraciones hechas al programa.</font></p>      <p align="justify"><font face="verdana" size="2">2 A este valor tiende el retardo al aumentar los usuarios, debido a que el incremento lo hacemos directamente en el DSLAM.</font></p>      ]]></body><back>
<ref-list>
<ref id="B1">
<nlm-citation citation-type="confpro">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Chunglae]]></surname>
<given-names><![CDATA[C.]]></given-names>
</name>
</person-group>
<article-title xml:lang="en"><![CDATA[Improvement of channel zapping time in IPTV services using the adjacent groups Join-Leave method]]></article-title>
<source><![CDATA[]]></source>
<year></year>
<volume>II</volume>
<conf-name><![CDATA[ 6th International Conference on Advanced Communication Technology]]></conf-name>
<conf-date>2004</conf-date>
<conf-loc> </conf-loc>
<page-range>971-975</page-range></nlm-citation>
</ref>
<ref id="B2">
<nlm-citation citation-type="">
<collab>Cisco Systems</collab>
<source><![CDATA[Managing delay in IP video networks]]></source>
<year>2006</year>
</nlm-citation>
</ref>
<ref id="B3">
<nlm-citation citation-type="">
<collab>Cisco Systems</collab>
<source><![CDATA[Cisco wire line video/IPTV solution design and implementation Guide]]></source>
<year>2006</year>
<page-range>376</page-range></nlm-citation>
</ref>
<ref id="B4">
<nlm-citation citation-type="book">
<collab>Full Service-VDSL</collab>
<source><![CDATA[FS-VDSL Specification, part 2, System Architecture]]></source>
<year>Juni</year>
<month>o </month>
<day>20</day>
<publisher-name><![CDATA[Full Service-VDSL Committee]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B5">
<nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Fenner]]></surname>
<given-names><![CDATA[B.]]></given-names>
</name>
</person-group>
<article-title xml:lang="en"><![CDATA[RFC 2362: Protocol independent multicast-Sparse mode (PIM SM)]]></article-title>
<source><![CDATA[Protocol specification]]></source>
<year>Oct </year>
<month>20</month>
<day>03</day>
<publisher-name><![CDATA[Internet Engineering Task Force]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B6">
<nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Fenner]]></surname>
<given-names><![CDATA[W.]]></given-names>
</name>
</person-group>
<article-title xml:lang="en"><![CDATA[RFC 2236]]></article-title>
<source><![CDATA[Internet Group Management Protocol, Version 2]]></source>
<year>Nov </year>
<month>19</month>
<day>97</day>
<publisher-name><![CDATA[Internet Engineering Task Force]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B7">
<nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Muñiz]]></surname>
<given-names><![CDATA[I.]]></given-names>
</name>
</person-group>
<article-title xml:lang="es"><![CDATA[Televisión IP: Una experiencia totalmente personalizada (en línea)]]></article-title>
<source><![CDATA[]]></source>
<year></year>
<publisher-name><![CDATA[Centro de Investigación e Innovación en Telecomunicaciones, A.C.]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B8">
<nlm-citation citation-type="book">
<collab>Siemens Communications</collab>
<collab>Juniper Networks</collab>
<source><![CDATA[High Quality and Resilient IPTV Multicast Architecture]]></source>
<year>2006</year>
<publisher-name><![CDATA[Siemens Communications and Juniper Networks]]></publisher-name>
</nlm-citation>
</ref>
</ref-list>
</back>
</article>
