ES2378468T3 - Método que permite impedir la distribución de un doble flujo de datos de multidifusión - Google Patents

Método que permite impedir la distribución de un doble flujo de datos de multidifusión Download PDF

Info

Publication number
ES2378468T3
ES2378468T3 ES06804924T ES06804924T ES2378468T3 ES 2378468 T3 ES2378468 T3 ES 2378468T3 ES 06804924 T ES06804924 T ES 06804924T ES 06804924 T ES06804924 T ES 06804924T ES 2378468 T3 ES2378468 T3 ES 2378468T3
Authority
ES
Spain
Prior art keywords
stb
multicast
channel
igmp
leave
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES06804924T
Other languages
English (en)
Inventor
Dawei Yu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Application granted granted Critical
Publication of ES2378468T3 publication Critical patent/ES2378468T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)

Abstract

Un método para impedir la emisión simultánea de dos flujos de datos de multidifusión, que comprende: en su activación, la composición y el envío por un decodificador de protocolo Internet, IP STB, de un mensaje Leave del protocolo de gestión de grupo Internet, IGMP, en función de la información relacionada con el canal memorizada en el IP STB; a la recepción del mensaje Leave de IGMP procedente del IP STB, la interrupción por un multiplexor de acceso de línea de abonado digital, DSLAM, de la transmisión de flujos de datos de multidifusión al IP STB correspondiente al mensaje Leave de IGMP enviado por el IP STB.

Description

Método que permite impedir la distribución de un doble flujo de datos de multidifusión
CAMPO DE LA TECNOLOG�?A
La presente invención se refiere a la tecnología de televisión de protocolo de Internet y en particular, a un método para impedir la emisión simultánea de dos flujos de multidifusión y un decodificador de protocolo de Internet (IP STB).
ANTECEDENTES DE LA INVENCIÓN
La televisión de protocolo de Internet (IPTV) es un nuevo medio de prestación de servicios interactivos personalizados sobre la base de la tecnología de Internet. La TV de radiodifusión (BTV) es el servicio básico en un sistema de IPTV y el servicio más contrastado en el sector. En consideración de las previsiones de programas, anuncios de marcas y espacios comerciales, los operadores suelen establecer un canal por defecto de activación para difundir las previsiones de programas, anuncios de marcas y espacios comerciales, de modo que los contenidos se difundan a través del canal por defecto a la activación y se reciban tan pronto como se active el decodificador de IP (STB). El canal por defecto a la activación se suele establecer en el canal 1.
BTV es un servicio basado en la multidifusión y que depende del protocolo de rutas de multidifusión, del protocolo de gestión de grupos de Internet (IGMP) y del protocolo mandatario de IGMP, etc., que se soportan por dispositivos de la red. Cuando un sistema de IPTV transmite flujos de programas de multidifusión a una red de acceso, los encaminadores en la red suelen cumplir con el protocolo de ruta de multidifusión y los dispositivos de la red, en la red de acceso, cumplen el protocolo mandatario de IPMP.
Un IP STB es un dispositivo de terminal de usuario en un sistema IPTV y la memorización en el IP STB suele almacenar una lista de canales que contiene las direcciones IP de multidifusión, los números de puertos de multidifusión y otra información relacionada con el canal en los canales que un usuario está autorizado a ver. Cuando un usuario está recibiendo un servicio de BTV, su IP STB busca primero la dirección de multidifusión y el número de puerto de multidifusión del canal que el usuario desea ver dentro de la lista de canales en función de la instrucción dada por un dispositivo de control a distancia, en cuyo momento el IP STB compone un mensaje Report de IGMP en función de los requisitos de REC2236 y solicita incorporarse a un grupo de multidifusión correspondiente y por último, el IP STB recibe el flujo de datos de multidifusión procedente de una red fuente de servicio IPTV después de que los dispositivos de la red de todos los niveles hayan realizado el protocolo mandatario de IGMP.
Cuando el usuario desea conmutar a otro canal, el IP STB compone primero un mensaje Leave de IGMP en función de los requisitos de RFC2236 para abandonar el grupo de multidifusión actual, de modo que cese la transmisión del flujo de datos de multidifusión del canal actual; en tal caso, el IP STB busca la dirección de multidifusión y el puerto de multidifusión del canal que el usuario desea ver a partir de la lista de canales y compone un mensaje Report de IGMP en función de los requisitos de RFC2236 para incorporarse a un nuevo grupo de multidifusión correspondiente y entonces, el flujo de datos de multidifusión del nuevo canal se transmite al IP STB.
Cuando el IP STB se conmuta desde el servicio BTV a otro servicio, el IP STB compone primero un mensaje Leave de IGMP en función de los requisitos de RFC2236 para abandonar el grupo de multidifusión actual, de modo que cesa la transmisión del flujo de datos de multidifusión del canal actual; a continuación, el IP STB envía un mensaje de informe correspondiente en función de la instrucción recibida del usuario para obtener un nuevo servicio.
Cuando un IP STB, en la técnica anterior, necesita reiniciarse debido a una anomalía funcional (interrupción repentina de la alimentación, pulsación indebida de la tecla de encendido por una persona, etc.) mientras se realiza el servicio de BTV, la solución técnica, en la técnica anterior, consiste en enviar un mensaje Report de IGMP para incorporarse al grupo de multidifusión del canal por defecto a la activación del servicio BTV directamente después de que se active el IP STB, sin importar si el flujo de datos de multidifusión, que fue transmitido cuando se produjo la anomalía, haya cesado de funcionar.
En el preciso momento en que se produce dicha anomalía, el IP STB no es capaz de enviar un mensaje Leave de IGMP para abandonar el grupo de multidifusión actual. Mientras tanto, existe una muy pequeña probabilidad de que el grupo de multidifusión actual sea el canal por defecto a la activación y la probabilidad es igual a 1/ número total de programas de BTV que un usuario está autorizado a ver.
Cuando el IP STB se activa y envía directamente un mensaje Report de IGMP para incorporarse al grupo de multidifusión del canal por defecto a la activación, el flujo de datos de multidifusión, que fue transmitido cuando se produce la anomalía, se suele seguir transmitiendo al IP STB, porque el multiplexor de acceso de línea de abonado digital (DSLAM), que envía el flujo de datos de multidifusión al IP STB, es incapaz de conocer la situación del IP STB cuando se produjo la anomalía funcional del IP STB. En las aplicaciones prácticas, un DSLAM ha de enviar una interrogación de consulta general del IGMP y una interrogación específica del grupo para cerciorarse de si un IP STB, en el grupo de multidifusión actual, está activo o no.
RFC2236 define que el intervalo, para el mensaje de consulta de IGMP, es de 125 segundos y el tiempo de respuesta máximo a un mensaje de consulta de IGMP es de 10 segundos. RFC2236 no define la duración de la espera de un dispositivo, después de que se transmita una consulta general y luego, transmite un mensaje de consulta específica del grupo (variando la longitud del intervalo con dispositivos de fabricantes diferentes, que suele ser una consulta específica del grupo enviada 20 segundos después de que se envíe un mensaje de consulta de IGMP) o el número de veces de envío y la magnitud del intervalo de las consultas específicas del grupo (dispositivos desde fabricantes diferentes realizan establecimientos diferentes, que suele ser una consulta específica del grupo que se envía dos veces con un intervalo de 4 segundos).
Si el IP STB sufre una anomalía funcional después de que el DSLAM haya enviado un mensaje de consulta de IGMP y antes de que el IP STB reenvíe un mensaje de respuesta correspondiente, el DSLAM enviará el mensaje de consulta de IGMP una vez más y enviará, dos veces, además, un mensaje de consulta específica del grupo para comprobar si el elemento del grupo de multidifusión, con anomalía funcional, ha abandonado el grupo de multidifusión; a continuación, el DSLAM cesará la transmisión del flujo de datos de multidifusión que se transmite al IP STB cuando sufre dicha anomalía. Es decir, si el IP STB sufre una anomalía después de que el DSLAM haya enviado una consulta general y antes de que el IP STB reenvíe un informe correspondiente, la transmisión del flujo de datos de multidifusión que se transmite al IP STB cuando sufre una anomalía operativa el IP STB continuará durante unos 144 segundos.
Si el IP STB sufre la anomalía cuando el DSLAM envía un mensaje de consulta de IGMP y el IP STB reenvía un mensaje de respuesta correspondiente, el DSLAM enviará el mensaje de consulta de IGMP dos veces, una vez más, y enviará, además, un mensaje de consulta específica del grupo para comprobar si el elemento del grupo de multidifusión que sufre la anomalía ha abandonado el grupo de multidifusión; a continuación el DSLAM cesará la transmisión del flujo de datos de multidifusión que se transmite al IP STB cuando el IP STB sufre dicha anomalía. Es decir, si el IP STB sufre una anomalía cuando el DSLAM envía un mensaje de consulta de IGMP y el IP STB reenvía un mensaje de respuesta correspondiente, la transmisión del flujo de datos de multidifusión, que se transmite al IP STB cuando el IP STB sufre una anomalía, continuará durante aproximadamente 269 segundos.
Puede llegarse a la conclusión, a partir de lo anteriormente expuesto, de que cuando un IP STB sufre una anomalía operativa, la transmisión del flujo de datos de multidifusión al IP STB continuará durante aproximadamente 144 a 269 segundos.
Además, cuando ocurre la anomalía, un IP STB necesita aproximadamente 20 segundos para su reinicio, efectuará la composición de un mensaje Report de IGMP y solicitará su incorporación al grupo de multidifusión del canal por defecto a la activación, después de que el flujo de datos de multidifusión del canal por defecto a la activación se hubiere enviado al IP STB. Evidentemente, esto causará la situación en la que el flujo de datos de multidifusión que el IP STB ha estado recibiendo cuando el IP STB sufre la anomalía y el flujo de datos de multidifusión del canal por defecto a la activación se emiten al IP STB de forma simultánea y la situación se denomina emisión simultánea llamada de dos flujos de multidifusión.
La emisión simultánea de dos flujos de multidifusión suele durar de 124 a 249 segundos (o 119 a 254 segundos en algunos casos extremos). La emisión simultánea de dos flujos de multidifusión da lugar a dos consecuencias perjudiciales: en primer lugar, el ancho de banda total de dos flujos de multidifusión suele exceder el ancho de banda operativo del servicio proporcionado para un usuario por un sistema de IPTV, lo que da lugar a importantes pérdidas de paquetes en los flujos de multidifusión transmitidos al IP STB, reflejado en mociones congeladas y mosaicos; en segundo lugar, puesto que existen dos flujos de multidifusión transmitidos a un IP STB simultáneamente, resultará afectada la prestación de servicios de IP STB, que causa una reproducción brusca del IP STB al menos e incluso un reinicio anormal del IP STB.
La técnica anterior proporciona, además, tres documentos de solicitud de patente de EP: D1 (EP 1 119 134), D2 (EP 1 427 132) y D3 (EP 1 429 489).
D1 da a conocer un método y aparato para controlar las suscripciones del grupo de multidifusión controlante en donde, cuando un encaminador recibe notificación para cesar el soporte de un grupo de multidifusión particular, el flujo de datos con respecto a ese grupo de multidifusión se mantiene inicialmente en el enlace de comunicación que acopla el encaminador a los concentradores, se emiten consultas a los concentradores sobre el enlace de comunicación para determinar si el soporte continuado del grupo particular es deseado, o no, por cualesquiera concentradores acoplados al enlace de comunicación y si, mientras se espera una respuesta positiva a las consultas emitidas, se recibe una petición de incorporación a un grupo de multidifusión adicional, se examina la disponibilidad de ancho de banda, en el enlace de comunicaciones, para determinar si un ancho de banda apropiado está disponible para soportar la adición del grupo recientemente solicitado y si no está disponible un ancho de banda apropiado para soportar el grupo recientemente solicitado, uno o más grupos que están pendientes de terminación se seleccionan para una terminación anticipada con el fin de hacer disponible más ancho de banda para soportar la adición del grupo recientemente solicitado.
D2 da a conocer un método de gestión de conexiones de multidifusión IP en una red que presenta un nodo de red y una pluralidad de usuarios finales, comprendiendo dicho método las etapas de: (a) recibir, en un nodo de red, un mensaje Join (Incorporación) del grupo IGMP desde un dispositivo de usuario final servido por la red; (b) comparar, en el nodo de
la red, una dirección MAC, obtenida a partir del mensaje Join del dispositivo de usuario final con otra dirección MAC obtenida a partir de un mensaje Join anterior para el cual existe una conexión de multidifusión IP al nodo de la red; (c) la iniciación, por el nodo de la red en respuesta a una coincidencia resultante de la comparación, de un GSQ desde el grupo de la petición de Join anterior de coincidencia y (d) la terminación, en función de un resultado del procesamiento de GSQ que indica que ya no necesita una conexión al grupo, de la conexión al grupo.
D3 da a conocer un método un gestión de conexiones de multidifusión IP en una red de comunicaciones que tiene uno o más nodos de red conectados a una pluralidad de dispositivos de usuario final, que comprende las etapas de: (a) la recepción, en un nodo de la red, de un mensaje Join del grupo IGMP desde un dispositivo de usuario final servido por la red; (b) la comparación, en el nodo de la red, de una dirección MAC, obtenida a partir del mensaje Join, del dispositivo de usuario final con otra dirección MAC obtenida a partir de un mensaje Leave (Abandono) pendiente para el que existe una conexión de multidifusión IP al nodo de la red; (c) la determinación, por el nodo de la red, de si cualquier otro dispositivo de usuario final está escuchando, o no, al grupo de multidifusión del mensaje Leave pendiente y (d) la iniciación, en función de que ningún otro dispositivo de usuario final esté a la escucha del grupo de multidifusión y en función de una coincidencia resultante de dicha comparación, y una acción de abandono del grupo facilitada para dicho dispositivo de usuario final en la conexión de multidifusión IP.
En resumen, en la técnica anterior, dos flujos de multidifusión se pueden emitir a un IP STB simultáneamente durante un largo periodo de tiempo, lo que degrada, en gran medida, la calidad de imagen y puede incluso causar que el IP STB se reinicie de modo anormal. Esta circunstancia operativa influirá en la experiencia del usuario, en gran medida, y disminuirá la satisfacción del usuario.
SUMARIO DE LA INVENCIÓN
La presente invención da a conocer un método para impedir la emisión simultánea de dos flujos de multidifusión que causa un grave daño a la calidad de la imagen e incluso una reiniciación anormal de un IP STB en la técnica anterior y un IP STB para la puesta en práctica del método.
La solución técnica según la presente invención se consigue como se indica a continuación.
Un método para impedir la emisión simultánea de dos flujos de multidifusión incluye el proceso siguiente:
al activarse, un IP STB compone y envía un mensaje Leave de IGMP en función de la información relacionada con el canal, memorizada en el IP STB;
a la recepción del mensaje Leave de IGMP desde el IP STB, un DSLAM interrumpe la transmisión del flujo de datos de multidifusión al IP STB correspondiente al mensaje Leave de IGMP enviado por el IP STB.
La información relacionada con el canal, memorizada en el IP STB, incluye una dirección IP de multidifusión y un número de puerto de multidifusión de un grupo de multidifusión del canal, que el usuario ha estado viendo antes de que se desactive el IP STB y la información se memoriza en una memoria NVM del IP STB.
Un método para impedir la emisión simultánea de dos flujos de multidifusión, que comprende:
al activarse un IP STB, el IP STB negocia con un servidor de acceso de banda ancha por intermedio de los protocolos pertinentes y al IP STB se asigna una dirección IP para la comunicación por el servidor de acceso de banda ancha después de una negociación satisfactoria;
el servidor de acceso de banda ancha notifica a un multiplexor de acceso de línea de abonado digital, DSLAM, por intermedio de un mensaje u otro medio de que el IP STB ha accedido correctamente a la red;
a la recepción de la notificación desde el servidor de acceso de banda ancha, el DSLAM tiene conocimiento de que el IP STB ha accedido correctamente a una red, el DSLAM consulta si existe un flujo de datos de multidifusión que se transmite al IP STB y si existe un flujo de datos de multidifusión transmitido al IP STB, el DSLAM interrumpe la transmisión del flujo de datos de multidifusión al IP STB.
Un método para impedir la emisión simultánea de dos flujos de multidifusión, que comprende:
al activarse un IP STB, el IP STB negocia con un servidor de acceso de banda ancha por intermedio de los protocolos pertinentes y al IP STB se le asigna una dirección IP para la comunicación por el servidor de acceso de banda ancha después de una negociación satisfactoria;
el IP STB compone un mensaje Report de IGMP en función del contenido de la lista de canales memorizada en el IP STB y envía el mensaje Report de IGMP a un multiplexor de acceso de línea de abonado digital, DSLAM, que solicita su incorporación al grupo de multidifusión del canal por defecto a la activación;
5 El método comprende, además, el proceso:
el IP STB compone y envía un mensaje Report de IGMP en función del contenido de una lista de canales memorizada en el IP STB y se incorpora a un grupo de multidifusión de un canal por defecto a la activación.
10 El método comprende, además, el proceso:
en función de una instrucción de usuario recibida, realizar al menos una de las operaciones siguientes: conmutación de canales, conmutación a un servicio no de BTV y desconexión.
15 La operación realizada es la conmutación de canales y la conmutación de canales comprende el proceso de:
enviar el mensaje Leave de IGMP para abandonar un grupo de multidifusión actual;
buscar una dirección IP de multidifusión y un número de puerto de multidifusión de un canal elegido por un usuario en 20 una lista de canales;
componer un mensaje Report de IGMP en un función de la dirección IP de multidifusión y el número de puerto de multidifusión encontrado y enviar el mensaje Report de IGMP para la incorporación a un nuevo grupo de multidifusión.
25 La dirección IP de multidifusión, el número de puerto de multidifusión y la información de verificación memorizada en el IP STB se actualizan con la información correspondiente del nuevo grupo de multidifusión cuando el IP STB se incorpora al nuevo grupo de multidifusión;
o, el IP STB determina si un canal elegido por el usuario es el canal por defecto a la activación y si el canal elegido no es
30 el canal por defecto a la activación, la dirección IP de multidifusión, el número de puerto de multidifusión y la información de verificación memorizada en el IP STB se actualizan con la información correspondiente del nuevo grupo de multidifusión; en caso contrario, la información memorizada en el IP STB no ha de actualizarse.
La dirección IP de multidifusión, el número de puerto de multidifusión y la información de verificación se memorizan en un
35 fichero de información en un sistema de ficheros de la memoria NVM o se memoriza en un bloque en el sistema de ficheros de la memoria NVM.
La información memorizada en el IP STB se almacena en una lista de canales en una memoria del IP STB, incluyendo una dirección IP de multidifusión y números de puertos de multidifusión de todos los canales que un usuario está
40 autorizado para ver;
el proceso de composición y envío del mensaje Leave de IGMP comprende el proceso siguiente: compone y envía múltiples mensajes Leave de IGMP en función de las direcciones IP de multidifusión y de los números de puertos de multidifusión de todos los canales en la lista de canales, uno a uno.
45 La presente invención da a conocer, además, un IP STB, que está configurado para componer y enviar un mensaje Leave de IGMP en función de la información relacionada con el canal, memorizada en el propio IP STB al ser activado, hasta que el DSLAM interrumpa la transmisión del flujo de datos de multidifusión al IP STB correspondiente al mensaje Leave de IGMP.
50 La información relacionada con el canal, memorizada en el IP STB, comprende una dirección IP de multidifusión y un número de puerto de multidifusión de un grupo de multidifusión del canal que el usuario ha estado viendo antes de que se desactive el IP STB y la información se memoriza en una memoria no volátil, NVM, del IP STB.
55 En comparación con la práctica en la técnica anterior, el método dado a conocer por la presente invención impide la emisión simultánea de dos flujos de multidifusión y de este modo, elimina las consecuencias desfavorables que resultan de la emisión simultánea de dos flujos de multidifusión, incluyendo la pérdida de calidad de la imagen e incluso la reiniciación anormal de un IP STB y por lo tanto, se mejorará la experiencia de los usuarios y aumentará la satisfacción del usuario de manera distintiva.
60 BREVE DESCRIPCIÓN DE LOS DIBUJOS
La Figura 1 es un diagrama de flujo de las operaciones de IP STB según una primera forma de realización de esta invención;
La Figura 2 es el diagrama de flujo de las operaciones de IP STB, según una segunda forma de realización de esta invención;
La Figura 3 es el diagrama de flujo de las operaciones de IP STB, según una tercera forma de realización de esta invención;
La Figura 4 es el diagrama de flujo de las operaciones de IP STB, según una cuarta forma de realización de esta invención y
La Figura 5 es el diagrama de flujo de las operaciones de IP STB, según una quinta forma de realización de esta invención.
FORMAS DE REALIZACIÓN DE LA INVENCIÓN
Una descripción detallada de la presente invención se da a conocer, a continuación, haciendo referencia a los dibujos adjuntos y a formas de realización específicas.
Según las formas de realización de la presente invención, a la activación de un IP STB, se transmite primero un mensaje Leave de IGMP con el fin de abandonar el grupo de multidifusión al que ha pertenecido el IP STB cuando ocurrió la anomalía funcional, de modo que se impida, en su raíz, la emisión simultánea de dos flujos de multidifusión.
La Figura 1 es el diagrama de flujo de las operaciones de IP STB según una primera forma de realización de esta invención. Según se representa en la Figura 1, cuando se activa un IP STB, IP STB compone y envía, primero, un mensaje Leave de IGMP en función de la información memorizada en el IP STB para abandonar el grupo de multidifusión al que ha pertenecido el IP STB cuando se produjo la anomalía para el IP STB. La información memorizada en el IP STB comprende la dirección IP de multidifusión y el número de puerto de multidifusión del grupo de multidifusión del último canal elegido por el usuario antes de que se desactivara el IP STB (o se desactive en una condición de anomalía). A la recepción del mensaje Leave de IGMP desde el IP STB, el DSLAM interrumpe la transmisión del flujo de datos de multidifusión correspondiente al mensaje Leave de IGMP al IP STB, en donde el flujo de datos de multidifusión es el flujo de datos de multidifusión que fue transmitido al IP STB cuando se produjo la anomalía funcional al IP STB.
Evidentemente, cuando fue desactivado accidentalmente un IP STB, mientras estaba realizando el servicio de BTV, el IP STB puede abandonar, sin brusquedad, el grupo de multidifusión al que ha pertenecido el IP STB cuando el IP STB fue desactivado mediante el método anterior en su activación. Después de lo anterior, el IP STB podrá componer, además, un mensaje Report de IGMP en función del contenido de la lista de canales memorizada en el IP STB y enviar el mensaje Report de IGMP para incorporar el canal por defecto a la activación. A continuación, el IP STB puede continuar con las operaciones de seguimiento incluyendo la conmutación de canales, la conmutación a un servicio no de BTV o la interrupción en función de las instrucciones del usuario.
La Figura 2 es el diagrama de flujo de las operaciones de IP STB de una segunda forma de realización de esta invención. En condiciones normales, un IP STB está provisto de una memoria no volátil (NVM) en donde se configura un sistema de ficheros y en el sistema de ficheros, un fichero denominado SaveInfo.txt (u otros nombres) se suele crear para memorizar información. En las aplicaciones prácticas, el fichero SaveInfo.txt se puede utilizar para memorizar la dirección IP de multidifusión, el número de puerto de multidifusión y la información de verificación del grupo de multidifusión al que pertenece actualmente el IP STB.
Según se representa en la Figura 2, a la activación, un IP STB comprueba primero si existe un fichero denominado SaveInfo.txt y si existe dicho fichero, el IP STB abre el fichero para obtener la información que contiene y luego, cierra el fichero SaveInfo.txt. Cuando la información obtenida ha superado la verificación, el IP STB compone un mensaje Leave de IGMP en función de la información según el formato de mensaje Leave de IGMP definido por RFC2236 y envía el mensaje Leave de IGMP. Si no existe ningún fichero denominado SaveInfo.txt, se debe crear y luego cerrar un fichero SaveInfo.txt.
En consecuencia, se interrumpe la transmisión del flujo de datos de multidifusión, que fue transmitido al IP STB cuando se produjo la anomalía operativa y se impide la emisión simultánea de dos flujos de multidifusión en la técnica anterior.
Cuando se envía el mensaje Leave de IGMP, el IP STB compone un mensaje Report de IGMP en función de la dirección IP de multidifusión y de la información de puerto de multidifusión del canal por defecto a la activación en la lista de canales del IP STB y envía el mensaje Report de IGMP con el fin de la incorporación del grupo de multidifusión del canal por defecto a la activación. A continuación, el IP STB abre el fichero SaveInfo.txt, que está memorizado en el IP STB, realiza la escritura de la dirección IP de multidifusión, del número de puerto de multidifusión y la información de verificación del canal por defecto a la activación en el fichero SaveInfo.txt y cierra el fichero. A continuación, el flujo de datos de multidifusión, proporcionado por el IP STB para el usuario, es el programa de multidifusión del canal por defecto a la activación.
Mientras se realiza el servicio de multidifusión del canal por defecto a la activación, el IP STB puede recibir las tres instrucciones siguientes:
1.
instrucción de conmutación de canales (conmutación entre servicios de BTV);
2.
instrucción de conmutación de servicios (conmutación entre un servicio de BTV y un servicio no de BTV proporcionado por el IP STB);
3.
instrucción de interrupción operativa.
Para las tres instrucciones anteriores, el IP STB puede realizar los procesos de gestión correspondientes según se indica a continuación:
Cuando se recibe una instrucción de conmutación de canales, el IP STB realiza un primer proceso de gestión que incluye las etapas de: el envío de un mensaje Leave de IGMP por el IP STB para abandonar el grupo de multidifusión actual, la búsqueda, en función de la instrucción desde un controlador distante, de la dirección de multidifusión y del número de puerto de multidifusión del canal correspondiente a la instrucción desde la lista de canales memorizada en el IP STB, la composición de un mensaje Report de IGMP en función de la dirección de multidifusión y del número de puerto de multidifusión obtenidos y el envío del mensaje Report de IGMP; a continuación, la apertura del fichero SaveInfo.txt, el borrado operativo del contenido del fichero, la escritura en el fichero SaveInfo.txt de la dirección IP de multidifusión, del número de puerto de multidifusión y de la información de verificación del canal después de la conmutación y cierre del fichero.
Se puede llegar a la conclusión de que la información en el fichero SaveInfo.txt se debe actualizar con la dirección IP de multidifusión, el número de puerto de multidifusión y la información de verificación del nuevo canal cada vez durante una conmutación de canales. La actualización del fichero SaveInfo.txt es importante. Y es evidente que, si el nuevo canal al que se conmuta el IP STB es el canal por defecto a la activación, no se necesita actualizar el fichero SaveInfo.txt.
Cuando se recibe una instrucción de conmutación de servicios, el IP STB realiza un segundo proceso de gestión que comprende las etapas de: el envío de un mensaje Leave de IGMP por el IP STB cuando el IP STB se conmuta desde un servicio de BTV a un servicio no de BTV, para abandonar el grupo de multidifusión actual y el envío de un mensaje correspondiente en función de la instrucción recibida para solicitar un servicio no de BTV.
Cuando se recibe una instrucción de interrupción, el IP STB realiza un tercer proceso de gestión que comprende las etapas de: el envío de un mensaje Leave de IGMP por el IP STB para abandonar el grupo de multidifusión actual y la realización del proceso de interrupción operativa.
Cuando el IP STB ha completado la conmutación de canales, podrá recibir, además, una instrucción de conmutación de servicios (conmutación desde un servicio de BTV a un servicio no de BTV) o una instrucción de interrupción operativa. Si se recibe una instrucción de conmutación de servicios, el IP STB realiza el segundo proceso de gestión anterior; si se recibe una instrucción de interrupción operativa, el IP STB realiza el tercer proceso de gestión anterior.
Cuando el IP STB ha conmutado desde un servicio de BTV a un servicio no de BTV puede recibir, además, una instrucción de conmutación desde un servicio no de BTV a un servicio de BTV o una instrucción de interrupción operativa. Si se recibe una instrucción de conmutación desde un servicio no de BTV a un servicio de BTV, el IP STB realiza un proceso similar al primer proceso de gestión, en donde la etapa de enviar un mensaje Leave de IGMP para abandonar el grupo de multidifusión actual queda omitida; si se recibe una instrucción de interrupción operativa, el IP STB realiza directamente el proceso de interrupción.
El proceso representado en la Figura 2 se realiza sobre la base de que existe un sistema de ficheros en la memoria no volátil NVM. Cuando no existe ningún sistema de ficheros en la red NVM, la dirección IP de multidifusión y el número de puerto de multidifusión del grupo de multidifusión actual se pueden memorizar en un bloque del IP STB como en otra forma de realización de la presente invención y la información se memoriza, se lee y se actualiza por intermedio de las funciones de interfaz de operaciones de memorización en bloque.
Además, en el proceso representado en la Figura 2, cuando la dirección IP de multidifusión, el número de puerto de multidifusión y la información de verificación se memorizan en el fichero SaveInfo.txt, el canal por defecto a la activación y otros canales se consideran como iguales. De hecho, si el IP STB está realizando el servicio de BTV del canal por defecto a la activación cuando se produce una anomalía funcional y si el IP STB se incorpora al grupo de multidifusión del canal por defecto a la activación al producirse dicha activación, según el principio de multidifusión, no habrá dos flujos de transmisión del canal por defecto a la activación transmitidos al IP STB, por lo que no será necesario memorizar la dirección IP de multidifusión, el número de puerto de multidifusión y la información de verificación del canal por defecto a la activación en el proceso de servicio de un IP STB.
Por ejemplo, cuando se activa el IP STB y se incorpora al grupo de multidifusión del canal por defecto de activación por primera vez, la etapa de escritura de la dirección IP de multidifusión, del número de puerto de multidifusión y de la
información de verificación del canal por defecto a la activación en el fichero SaveInfo.txt (o un bloque) se puede omitir en estas circunstancias. Además, después de que el IP STB se ha conmutado a otro canal y antes de que la dirección IP de multidifusión, el número de puerto de multidifusión y la información de verificación del nuevo canal se memoricen en el fichero SaveInfo.txt, se puede realizar una etapa de determinar si el canal de multidifusión actual es el canal por defecto a la activación y si el canal de multidifusión actual es el canal por defecto a la activación, se puede omitir la etapa de escritura de la dirección IP de multidifusión, del número de puerto de multidifusión y de la información de verificación del canal por defecto a la activación en el fichero SaveInfo.txt (o un bloque); en caso contrario, la dirección IP de multidifusión, el número de puerto de multidifusión y la información de verificación de nuevo canal serán objeto de escritura en el fichero SaveInfo.txt (o un bloque).
En condiciones normales, una lista de canales se memoriza en el dispositivo de almacenamiento de un IP STB y la lista de canales almacena las direcciones IP de multidifusión, los números de puertos de multidifusión y otra información relacionada con el canal con respecto a todos los canales para los que un usuario está autorizado para ver.
En el proceso representado en la Figura 2, un método que incluye una etapa de memorización de información relacionada en el sistema de ficheros en la memoria NVM, se da a conocer para garantizar que se envíe un mensaje Leave de IGMP antes de un mensaje Report de IGMP, proporcionándose también una solución alternativa en caso de que no exista ningún sistema de ficheros en la memoria NVM; además, se da a conocer un método en el que las direcciones IP de multidifusión, los números de puerto de multidifusión y la información de verificación del canal por defecto a la activación no necesitan memorizarse en el fichero SaveInfo.txt; además, la información de verificación se tomará también en consideración. Por lo tanto, el proceso de trabajo del IP STB, representado en la Figura 2, es efectivo y funcionalmente estable.
Es evidente que el proceso representado en la Figura 2 está memorizando las direcciones IP de multidifusión, los números de puertos de multidifusión y la información de verificación del canal mientras se realiza un servicio de BTV; cuando un IP STB se reinicia después de una interrupción anormal, el IP STB accede a la información relacionada memorizada para componer un mensaje Leave de IGMP y envía el mensaje Leave de IGMP antes de enviar un mensaje Report de IGMP, de modo que se impida la emisión simultánea de dos flujos de multidifusión.
La Figura 3 es el diagrama de flujo de las operaciones de IP STB de una tercera forma de realización de esta invención. Según se representa en la Figura 3, cuando se activa un IP STB en una situación aleatoria (incluyendo una situación anormal), el IP STB compone múltiples mensajes Leave de IGMP, cada uno de los cuales corresponde a un canal que el usuario está autorizado a observar, en función del contenido de la lista de canales memorizada en el IP STB y envía los mensajes Leave de IGMP uno a uno. Por intermedio de dicho método, el IP STB puede abandonar inicialmente el grupo de multidifusión al que pertenecía cuando se produjo la anomalía.
A continuación, el IP STB compone un mensaje Report de IGMP en función de la dirección IP de multidifusión y de la información de puerto de multidifusión del canal por defecto a la activación en su propia lista de canales y envía el mensaje Report de IGMP y se incorpora al grupo de multidifusión del canal por defecto a la activación.
A continuación, el IP STB puede continuar las operaciones de seguimiento incluyendo la conmutación de canales, la conmutación a un servicio no de BTV o la interrupción operativa, en función de las instrucciones del usuario recibidas.
Se puede deducir que el proceso representado en la Figura 3 pasará a la lista de canales y garantiza que los mensajes Leave de IGMP correspondientes de todos los canales para los que el usuario está autorizado a ver se enviarán uno a uno, por lo que la transmisión del flujo de datos de multidifusión que prosigue después de que ocurra la anomalía para el IP STB podría quedar interrumpida. Suponiendo que un usuario está autorizado para ver 100 canales de multidifusión, el tiempo que dedica un IP STB en el envío del mensaje Leave de IGMP correspondiente a uno de los 100 canales puede ser menor que un milisegundo. Con la capacidad de DSLAM y tomando en consideración la congestión de la red, el intervalo del mensaje Leave de IGMP se puede establecer en un milisegundo, de modo que todos los mensajes de Leave de IGMP se pueden enviar dentro de 0,1 segundos después de que active el IP STB; de este modo, el IP STB tarda muy poco tiempo en interrumpir la transmisión del flujo de datos de multidifusión que continúa después de que se produzca la anomalía para el STB.
Se puede deducir de lo anterior que en los métodos representados en las Figuras 1 a 3, un IP STB envía un mensaje Leave de IGMP, como iniciativa, para impedir la emisión simultánea de flujos de multidifusión.
De hecho, las entidades de comunicación, en el lado de la red, pueden cesar, en iniciativa, la transmisión del flujo de datos de multidifusión que prosigue después de que ocurra la anomalía al IP STB para impedir la emisión simultánea de flujos de multidifusión. Los procesos detallados se representan en la Figura 4 y en la Figura 5.
La Figura 4 es el diagrama de flujo de las operaciones del IP STB según una cuarta forma de realización de esta invención. Según se representa en la Figura 4, cuando un IP STB se activa en una situación aleatoria (incluyendo una situación anormal), el IP STB negocia con un servidor de acceso de banda ancha por intermedio de protocolos pertinentes y el servidor de acceso de banda ancha asigna una dirección IP para la conmutación del IP STB después de A la recepción de la notificación desde el servidor de acceso de banda ancha, el DSLAM consulta si existe la transmisión
5 de un flujo de datos de multidifusión al IP STB actualmente y, si existe una transmisión de un flujo de datos de multidifusión al IP STB en este momento, el DSLAM cesa la transmisión al IP STB. Y cuando el IP STB ya no recibe un flujo de datos de multidifusión desde el DSLAM, el IP STB compone un mensaje Report de IGMP en función del contenido de la lista de canales memorizada en el propio IP STB y envía el mensaje Report de IGMP para incorporar el grupo de multidifusión del canal por defecto a la activación.
10 Evidentemente, si el DSLAM determina que no existe ningún flujo de datos de multidifusión transmitido al IP STB, el DSLAM puede continuar con otras operaciones en la técnica anterior. En este caso, el IP STB puede seguir componiendo y enviando un mensaje Report de IGMP en función del contenido de la lista de canales memorizada en el IP STB y se incorpora al grupo de multidifusión del canal por defecto a la activación.
15 La Figura 5 es el diagrama de las operaciones de IP STB, según una quinta forma de realización de esta invención. Según se representa en la Figura 5, cuando un IP STB es activado en una situación aleatoria (incluyendo una situación anormal), el IP STB negocia con un servidor de acceso de banda ancha por intermedio de protocolos pertinentes y el servidor de acceso de banda ancha asigna una dirección IP para la comunicación del IP STB después de una
20 negociación satisfactoria; a continuación, el IP STB compone un mensaje Report de IGMP en función del contenido de la lista de canales memorizada en el IP STB y envía el mensaje Report de IGMP, con la solicitud de incorporación del grupo de multidifusión del canal de conmutación al estado activo por defecto.
A la recepción del mensaje Report de IGMP desde el IP STB, el DSLAM consulta si existe un flujo de datos de
25 multidifusión que se transmite actualmente al IP STB y, si existe, en ese momento, un flujo de datos de multidifusión transmitiéndose al IP STB, el DSLAM cesa la transmisión al IP STB y podrá rechazar, además, la admisión del IP STB para incorporarse al grupo de multidifusión del canal por defecto a la activación; en caso contrario, el DSLAM permite al IP STB incorporarse al grupo de multidifusión del canal por defecto a la activación. Y cuando el IP STB ya no recibe un flujo de datos de multidifusión desde el DSLAM, el IP STB compone un mensaje Report de IGMP en función del
30 contenido de la lista de canales memorizada en el IP STB y envía el mensaje Report de IGMP para incorporar el grupo de multidifusión del canal por defecto a la activación.
Se puede concluir, a partir de las representaciones de la Figura 4 y de la Figura 5, que cuando un IP STB se activa después de una interrupción operativa anormal, un DSLAM, en el lado de la red, puede cesar, en forma de iniciativa, la 35 transmisión del flujo de datos de multidifusión que continúa después de que ocurra la anomalía al IP STB, de modo que se impida la emisión simultánea de dos flujos de multidifusión.
La presente invención puede dar a conocer, además, un IP STB y un DSLAM para poner en práctica el método antes citado.
40 En resumen, el método dado a conocer por las formas de realización de la presente invención impide la emisión simultánea de dos flujos de multidifusión en la técnica anterior y de este modo, elimina las consecuencias desfavorables de la emisión simultánea de dos flujos de multidifusión, incluyendo la pérdida de calidad de la imagen e incluso la reiniciación anormal de un IP STB y por lo tanto, se mejorarán las experiencias de los usuarios y se aumentará la
45 satisfacción del usuario en forma distintiva.

Claims (11)

  1. REIVINDICACIONES
    1. Un método para impedir la emisión simultánea de dos flujos de datos de multidifusión, que comprende:
    en su activación, la composición y el envío por un decodificador de protocolo Internet, IP STB, de un mensaje Leave del protocolo de gestión de grupo Internet, IGMP, en función de la información relacionada con el canal memorizada en el IP STB;
    a la recepción del mensaje Leave de IGMP procedente del IP STB, la interrupción por un multiplexor de acceso de línea de abonado digital, DSLAM, de la transmisión de flujos de datos de multidifusión al IP STB correspondiente al mensaje Leave de IGMP enviado por el IP STB.
  2. 2.
    El método según la reivindicación 1, en donde la información relacionada con el canal, memorizada en el IP STB, comprende una dirección IP de multidifusión y un número de puerto de multidifusión de un grupo de multidifusión del canal que el usuario verá antes de la desconexión del IP STB y la información está memorizada en una memoria no volátil, NVM, del IP STB.
  3. 3.
    Un método para impedir la emisión simultánea de dos flujos de datos de multidifusión, que comprende:
    a la activación de un decodificador de protocolo Internet, IP STB, la negociación por el IP STB con un servidor de acceso de banda ancha por intermedio de protocolos pertinentes y la asignación al IP STB de una dirección IP para la comunicación por el servidor de acceso de banda ancha después de una negociación satisfactoria;
    la notificación por el servidor de acceso de banda ancha a un multiplexor de acceso de línea de abonado digital, DSLAM, por intermedio de un mensaje u otro medio, que el IP STB haya accedido correctamente a la red;
    a la recepción de la notificación desde el servidor de acceso de banda ancha, el DSLAM tiene conocimiento de que el IP STB ha accedido correctamente a una red, el DSLAM interroga para conocer si se está transmitiendo un flujo de datos de multidifusión al IP STB; en el caso de que se transmita un flujo de datos de multidifusión al IP STB, el DSLAM cesa la transmisión del flujo de datos de multidifusión al IP STB.
  4. 4. Un método para impedir la emisión simultánea de dos flujos de datos de multidifusión, que comprende:
    al activarse un decodificador de protocolo Internet, IP STB, la negociación por el IP STB con un servidor de acceso de banda ancha por intermedio de protocolos pertinentes y la asignación al IP STB de una dirección IP para la comunicación por el servidor de acceso de banda ancha después de una negociación satisfactoria;
    la composición, por el IP STB, de un mensaje Report de IGMP en función del contenido de la lista de canales memorizada en el IP STB y el envío del mensaje Report de IGMP a un multiplexor de acceso de línea de abonado digital, DSLAM, que solicite incorporarse al grupo de multidifusión del canal por defecto a la activación;
    a la recepción del mensaje Report de IGMP, procedente del IP STB, la interrogación por el DSLAM de si un flujo de datos de multidifusión se transmite, o no, al IP STB; en el caso de que se transmita un flujo de datos de multidifusión, el DSLAM cesa una transmisión de flujo de datos de multidifusión al IP STB.
  5. 5.
    El método según cualquiera de las reivindicaciones 1 a 4 que comprende, además:
    la composición y el envío de un mensaje Report de IGMP, por el IP STB, en función del contenido de una lista de canales memorizada en el IP STB y la incorporación a un grupo de multidifusión de un canal por defecto a la activación.
  6. 6.
    El método según cualquiera de las reivindicaciones 1 a 4 que comprende, además:
    en función de una instrucción de usuario recibida, la realización de al menos una de las operaciones siguientes: la conmutación de canales, la conmutación a un servicio no BTV y la desactivación.
  7. 7.
    El método según la reivindicación 6, en donde la operación realizada es la conmutación de canales y dicha conmutación de canales comprende:
    el envío del mensaje Leave de IGMP para abandonar un grupo de multidifusión actual;
    la búsqueda de una dirección IP de multidifusión y de un número de puerto de multidifusión de un canal elegido por un usuario dentro de una lista de canales;
    la composición de un mensaje Report de IGMP en función de la dirección IP de multidifusión y del número de puerto de multidifusión encontrado y el envío del mensaje Report de IGMP para incorporarse a un nuevo grupo de multidifusión.
  8. 8. El método según la reivindicación 7, en donde la dirección IP de multidifusión, el número de puerto de multidifusión y la información de verificación memorizada en el IP STB se actualizan con la información correspondiente del nuevo grupo de multidifusión cuando el IP STB se incorpora al nuevo grupo de multidifusión;
    5 o el IP STB determina si un canal elegido por el usuario es, o no, el canal por defecto a la activación, y si el canal elegido no es el canal por defecto a la activación, la dirección IP de multidifusión, el número de puerto de multidifusión y la información de verificación memorizada en el IP STB se actualizan con la información correspondiente del nuevo grupo de multidifusión; si no es así, no ha de actualizarse la información memorizada en el IP STB.
    10 9. El método según la reivindicación 2, 7 u 8, en donde la dirección IP de multidifusión, el número de puerto de multidifusión y la información de verificación se memorizan en un fichero de información en un sistema de ficheros de la NVM o memorizada en un bloque en el sistema de ficheros de la NVM.
  9. 10. El método según la reivindicación 1, en donde la información memorizada en el IP STB se memoriza en una lista de
    15 canales en una memoria del IP STB, que incluye una dirección IP de multidifusión y números de puertos de multidifusión de todos los canales que un usuario está autorizado a ver;
    el proceso de componer y enviar el mensaje Leave de IGMP comprende la composición y el envío de múltiples mensajes Leave de IGMP en función de las direcciones IP de multidifusión y de los números de puertos de multidifusión de todos
    20 los canales dentro de la lista de canales, uno a uno.
  10. 11. Un decodificador de protocolo Internet, IP STB, que está configurado para componer y enviar a un multiplexor de acceso de línea de abonado digital, DSLAM, un mensaje Leave de IGMP del protocolo de gestión de grupo Internet, en función de la información relacionada con el canal memorizada en el propio IP STB, a la activación del IP STB, de forma
    25 que el DSLAM cese la transmisión de flujo de datos de multidifusión al IP STB correspondiente al mensaje Leave de IGMP.
  11. 12. El IP STB según la reivindicación 11, en donde la información relacionada con el canal, memorizada en el IP STB, comprende una dirección IP de multidifusión y un número de puerto de multidifusión de un grupo de multidifusión del
    30 canal que el usuario ha estado observando antes de que se desactive el IP STB y la información se memoriza en una memoria no volátil, NVM, del IP STB.
    Componer y enviar un mensaje Leave de IGMP en función de la información memorizada en el IP STB
    Componer un mensaje Report de IGMP para la incorporación del grupo de multidifusión del canal de activación por defecto
    Continuar con las operaciones de seguimiento en función de las instrucciones del usuario
    Continuar
    Figura 1
    Comprobar si existe un fichero denominado Saveinfo.txt
    Crear un fichero
    Abrir el fichero Saveinfo.txt, obtener la información
    Saveinfo.txt y luego cerrar
    y cerrar el fichero
    el fichero recientemente creado
    Comprobar si la información es válida
    Componer un mensaje Leave de IGMP en función de la información obtenida y enviar el mensaje Leave de IGMP
    Componer un mensaje Report de IGMP en función delcontenido de la lista de canales para incorporar el grupo de multidifusión del canal de activación por defecto
    Abrir el fichero Saveinfo.txt, borrar su contenido, escribir en el fichero Saveinfo.txt la dirección IP de multidifusión, el número de puerto de multidifusión y la información de verificación del canal de activación por defecto y cerrar el fichero
    Conmutar a un servicio no de BTV
    Conmutar entre canales
    Enviar un mensaje Leave de IGMP para abandonar el grupo de multidifusión actual
    Enviar un mensaje Report de IGMP en función de una instrucción desde un controlador remoto y del contenido de la lista de canales para incorporar un nuevo grupo de multidifusión
    Abrir el fichero Saveinfo.txt, borrar su contenido, escribir en el fichero Saveinfo.txt la dirección IP de multidifusión, el número de puerto de multidifusión y la información de verificación del canal actual y cerrar el fichero
    Conmutar a un servicio no de BTV Desactivar
    Enviar un mensaje Leave de IGMP Enviar un mensaje Leave depara abandonar el grupo de IGMP para abandonar el grupo multidifusión actual de multidifusión actual
    Realizar un servicio no de BTV Desactivar
    Desactivar Desactivar
    Enviar un mensaje Leave de IGMPpara abandonar el grupo de multidifusión actual
    Desactivar
    Figura 2 Activar
    Componer múltiples mensajes Leave de IGMP, en turnos, en función delcontenido de la lista de canales memorizada en el IP STB y enviar los mensajes Leave de IGMP
    Componer un mensaje Report de IGMP en función del contenido de la lista de canales memorizada en el IP STB y enviar el mensaje Report de IGMP para la incorporación del grupo de multidifusión del canal de activación por defecto
    Realizar servicios por intermedio de la operación normal de STB
    Fin
    Figura 3 Activar
    El IP STB negocia con un servidor de acceso de banda ancha para obtener una dirección IP para comunicación
    El servidor de acceso de banda ancha notifica a un DSLAM que el IP STB consiguió acceder a la red
    Determinar si existe, o no, un flujo de datos de multidifusión que se transmite al IP STB
    El DSLAM cesa la transmisión del flujo de datos de multidifusión al IP STB
    El IP STB compone un mensaje Report de IGMP en función del contenido de la lista de canales y envía el mensaje Report de IGMP para la incorporación del grupo de multidifusión del canal deactivación por defecto
    Figura 4 Activar
    El IP STB negocia con un servidor de acceso de banda ancha para obtener una dirección IP para comunicación
    El IP STB compone un mensaje Report de IGMP en función del contenido de la lista de canales y envía el mensaje Report de IGMP
    Determinar si existe, o no, un flujo de datos demultidifusión que se transmite al IP STB
    El DSLAM cesa la transmisión del flujo de Al IP STB se le permite la incorporación del datos de multidifusión al IP STB grupo de multidifusión del canal de activación por defecto
    Figura 5
ES06804924T 2005-12-19 2006-10-13 Método que permite impedir la distribución de un doble flujo de datos de multidifusión Active ES2378468T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN200510121004 2005-12-19
CNB2005101210046A CN100536467C (zh) 2005-12-19 2005-12-19 Ip机顶盒的工作方法
PCT/CN2006/002698 WO2007071144A1 (fr) 2005-12-19 2006-10-13 Procédé permettant d'empêcher la distribution d'un double flux de données de multidiffusion

Publications (1)

Publication Number Publication Date
ES2378468T3 true ES2378468T3 (es) 2012-04-12

Family

ID=37133779

Family Applications (1)

Application Number Title Priority Date Filing Date
ES06804924T Active ES2378468T3 (es) 2005-12-19 2006-10-13 Método que permite impedir la distribución de un doble flujo de datos de multidifusión

Country Status (7)

Country Link
US (1) US7751395B2 (es)
EP (3) EP1965545B9 (es)
CN (2) CN100536467C (es)
AT (1) ATE542331T1 (es)
ES (1) ES2378468T3 (es)
FR (1) FR2895192B1 (es)
WO (1) WO2007071144A1 (es)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4765952B2 (ja) * 2007-02-15 2011-09-07 ソニー株式会社 マルチキャスト配信システム、クライアント機器、上位ルータ制御装置、コンテンツの表示方法およびプログラム
JP4752786B2 (ja) * 2007-02-15 2011-08-17 ソニー株式会社 マルチキャスト配信システムおよびマルチキャスト配信方法
US20090022064A1 (en) * 2007-07-18 2009-01-22 Moshe Oron Method and apparatus for monitoring multicast bandwidth to a user
KR100884061B1 (ko) 2007-08-30 2009-02-19 한양대학교 산학협력단 멀티캐스트 전송 환경에서의 그룹 탈퇴 방법 및 이를지원하는 장치
KR100895880B1 (ko) 2007-08-30 2009-04-30 한양대학교 산학협력단 멀티캐스트 전송 환경에서의 그룹 탈퇴 방법 및 이를지원하는 호스트 장치
CN100583997C (zh) * 2007-10-19 2010-01-20 深圳华为通信技术有限公司 网络电视的业务启动方法、装置和系统以及网络电视终端
BRPI0821104A2 (pt) * 2007-11-30 2015-06-16 Sharp Kk Dispositivo de recepção de transmissão
CN101494548B (zh) * 2009-03-02 2011-07-13 中兴通讯股份有限公司 减少网络电视组播断流时间的方法和装置
US9059919B1 (en) * 2011-03-28 2015-06-16 Symantec Corporation Systems and methods for preserving network settings for use in a pre-boot environment
CN102318272B (zh) * 2011-06-29 2013-12-18 华为技术有限公司 一种进程组中的异常组成员离开的方法
CN103581708A (zh) 2012-07-31 2014-02-12 中兴通讯股份有限公司 机顶盒开机广告播放的方法和系统

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6983478B1 (en) * 2000-02-01 2006-01-03 Bellsouth Intellectual Property Corporation Method and system for tracking network use
US20050028206A1 (en) * 1998-06-04 2005-02-03 Imagictv, Inc. Digital interactive delivery system for TV/multimedia/internet
US6826612B1 (en) * 1999-12-21 2004-11-30 Alcatel Canada Inc. Method and apparatus for an improved internet group management protocol
US20020150094A1 (en) * 2000-10-27 2002-10-17 Matthew Cheng Hierarchical level-based internet protocol multicasting
US20030145102A1 (en) * 2002-01-29 2003-07-31 Alcatel, Societe Anonyme Facilitating improved reliability of internet group management protocol through the use of acknowledge messages
US7272652B1 (en) * 2002-04-30 2007-09-18 Alcatel Lucent Facilitating accelerated processing of internet group management protocol messages
CN1675880A (zh) * 2002-08-16 2005-09-28 汤姆森许可公司 在多播数据存在时的下载最佳化
CN2583891Y (zh) * 2002-09-29 2003-10-29 上海广电信息产业股份有限公司 使机顶盒具有记录第一次使用时间的装置
US7254608B2 (en) * 2002-10-31 2007-08-07 Sun Microsystems, Inc. Managing distribution of content using mobile agents in peer-topeer networks
US20040090970A1 (en) * 2002-11-11 2004-05-13 Sanchez Cheryl A. Distribution of data flows to local loop subscribers by an access multiplexer
US7359939B2 (en) * 2002-12-06 2008-04-15 Alcatel Canada, Inc. Fast service restoration for lost IGMP leave requests
US7228356B2 (en) * 2002-12-12 2007-06-05 Alcatel Canada Inc. IGMP expedited leave triggered by MAC address
KR101081298B1 (ko) * 2003-03-20 2011-11-08 톰슨 라이센싱 위성 신호를 배치하고 분배하기 위해 멀티캐스트 ｉｐ 및이더넷을 활용하는 시스템 및 방법
EP1492381B1 (en) 2003-06-24 2007-01-10 Alcatel Digital subscriber line access network with improved authentication, authorization, accounting and configuration control for multicast services
SE0400825D0 (sv) * 2004-03-30 2004-03-30 Packetfront Sweden Ab Anordning och förfarande
US20070044123A1 (en) * 2005-08-16 2007-02-22 Alcatel System and method for smoothing channel changing in internet protocol television systems

Also Published As

Publication number Publication date
WO2007071144A1 (fr) 2007-06-28
EP1965545B1 (en) 2012-01-18
EP2458791A3 (en) 2012-08-29
CN101160831A (zh) 2008-04-09
US7751395B2 (en) 2010-07-06
CN1852311A (zh) 2006-10-25
FR2895192B1 (fr) 2011-05-27
ATE542331T1 (de) 2012-02-15
EP1965545A4 (en) 2009-06-17
US20070147373A1 (en) 2007-06-28
EP2530878A1 (en) 2012-12-05
EP2458791A2 (en) 2012-05-30
EP2530878B1 (en) 2014-01-08
FR2895192A1 (fr) 2007-06-22
EP1965545B9 (en) 2012-04-18
CN101160831B (zh) 2010-05-19
EP2458791B1 (en) 2015-04-01
CN100536467C (zh) 2009-09-02
EP1965545A1 (en) 2008-09-03

Similar Documents

Publication Publication Date Title
ES2378468T3 (es) Método que permite impedir la distribución de un doble flujo de datos de multidifusión
ES2720029T3 (es) Método de gestión remota de un dispositivo y dispositivo correspondiente
US7953027B2 (en) Rerouting multicast traffic in response to detecting imminent network disruption
ES2678075T3 (es) Métodos y aparatos para la transmisión eficiente de ancho de banda de información de uso desde un conjunto de terminales en una red de datos
CN101422013B (zh) 用于动态存储媒体数据的设备和方法
US20130128719A1 (en) Controlling Multicast Source Selection in an Anycast Source Audio/Video Network
US10367680B2 (en) Network relay apparatus, gateway redundancy system, program, and redundancy method
US20060074968A1 (en) Electronic content distribution management methods and systems
US20080068990A1 (en) Method and apparatus for implementing multicast service
KR20080085838A (ko) 디지털 텔레비전 서비스를 전송하는 방법, 대응하는게이트웨이 및 네트워크
US8910197B2 (en) Update process for interface device based targeted information insertion
ES2402833T3 (es) Método y aparato para un servicio de difusión general/multidifusión fiable
US20080120677A1 (en) Method and system for ensuring continuous video services in a passive optical network
KR100999285B1 (ko) 멀티미디어 컨텐트 플로우들을 생성하고 분산 네트워크로전달하기 위한 방법 및 장치
CN112995750A (zh) 家庭路由器场景下实现iptv组播服务的方法及系统
EP1863219B1 (en) Method and system for processing abnormally becoming power off of a terminal of multicast user
WO2014051555A1 (en) Multicast message update
US20010052020A1 (en) Control system for network servers
KR20090025798A (ko) 홈네트워크 서버의 이중화 절체 처리 방법 및 그홈네트워크 서버
KR20150022440A (ko) Mac 주소를 이용하는 이더넷 네트워크 장치 및 방법
US11218523B2 (en) Method of providing information to an audio/video receiver device and corresponding apparatus
KR100649441B1 (ko) 데이터 통신 모뎀 장치 및 데이터 통신 모뎀 장치에설치되는 프로그램을 저장한 기록 매채