ES2315415T3

ES2315415T3 - Procedimiento y dispositivo para la supervision mediante filtros para servicios multidifusion ip.

Info

Publication number: ES2315415T3
Application number: ES02783421T
Authority: ES
Inventors: Esa Jalonen; Matti Puputti
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2001-11-28
Filing date: 2002-11-25
Publication date: 2009-04-01
Anticipated expiration: 2022-11-25
Also published as: US7512084B2; EP1474875A4; EP1474875A2; AU2002347487A1; EP1474875B1; US20050120378A1; ATE413022T1; WO2003047148A2; WO2003047148A3; DE60229667D1; AU2002347487A8

Abstract

Un método que comprende, en un nodo de recepción: detectar un mensaje (206, 302), donde el mensaje comprende una dirección de un grupo de multidifusión y una solicitud para unirse a o abandonar el grupo de multidifusión; como respuesta a la detección del mensaje, determinar y recuperar (208, 306) un parámetro de filtro de una tabla de información de servicios del nodo de recepción necesario para recibir la transmisión de multidifusión, la tabla de información de servicios incluyendo parámetros de filtro; e implementar o eliminar (212, 310), respectivamente, un filtro según el parámetro de filtro recuperado, caracterizado porque la tabla de información de servicios incluye información de estado de filtro que indica si el filtro está habilitado actualmente.

Description

Procedimiento y dispositivo para la supervisión mediante filtros para servicios de multidifusión IP.

Campo de la invención

La invención se refiere a la implementación de un filtro en un receptor de radiodifusión digital y, más en particular, a un método para activar un filtro de este tipo en un receptor DVB-T de tal manera que sea independiente del software cliente que quiera acceder a los datos.

Antecedentes de la invención

Las señales de vídeo y audio digitales, sincronizadas en la forma de un programa (o servicio), pueden transmitirse a través de una red como datos de multidifusión. En una red de multidifusión, tal como DVB-T, un terminal de transmisión distribuye normalmente datos a la red de manera que cualquier nodo de recepción que desee recibir un servicio de datos dado puede subscribirse al mismo. De esta manera, el terminal de transmisión no establece enlaces punto a punto entre una pluralidad de nodos de recepción; se transmite una copia de datos de radiodifusión y múltiples receptores pueden ver el mismo material. Una ventaja que el protocolo de red de multidifusión tiene sobre otros protocolos de redes de distribución de datos es que la cantidad de datos relativamente grande necesaria para transmitir películas o similares, sólo se envía una vez a los nodos de conmutación de la red, y después se reenvía a varios terminales de recepción a lo largo de la red.

Cada servicio de datos digitales emitido desde el terminal de transmisión se segmenta en un flujo de elementos empaquetados. En un sistema de multidifusión, normalmente se transmiten múltiples servicios de datos sobre el mismo medio o canal de comunicación. Cada paquete de flujo de transporte en este canal contiene información de cabecera y una carga útil con datos de servicio de multidifusión, por ejemplo, partes de una película. Los terminales de recepción usan la información de cabecera para reensamblar los paquetes que transportan el servicio deseado y para descartar paquetes no deseados.

Aunque un protocolo de multidifusión elimina la necesidad de que el terminal de transmisión gestione múltiples conexiones y reduce la necesidad de que la red maneje una gran cantidad de datos redundantes, los nodos de recepción de multidifusión requieren un método más sofisticado para clasificar los datos relevantes que el de los nodos de red punto a punto. Tal como se ha expuesto anteriormente, un gran número de servicios pueden multiplexarse en el mismo canal de datos, lo que supone una carga significativa en la pila de protocolos de la red de cada terminal de recepción que debe clasificar los datos. Un reto para los nodos de recepción es clasificar la pluralidad de paquetes de datos disponibles y determinar y aceptar datos deseados ignorando al mismo tiempo los paquetes no deseados.

La solución para resolver esta limitación es que un nodo de recepción realice una doble inspección para asegurar la entrega exacta de paquetes. Tablas ubicadas en cada nodo de recepción realizan un seguimiento de la información relacionada con cada paquete, en particular el identificador de programa (PID, program identifier) y la dirección de control de acceso al medio (MAC, media access control) DVB. Cuando un software cliente en el nodo de recepción inicia una solicitud para un servicio, el receptor aplica un filtro para inspeccionar un canal de datos para datos de multidifusión. El filtro usa inicialmente un hardware de interfaz de red para examinar el campo PID de la cabecera, que contiene suficiente información para eliminar la mayoría de los paquetes no deseados. Después de que un paquete haya ascendido dentro de la pila de protocolos basándose en la información del campo PID, el software examina la dirección MAC de cada paquete para determinar si forma parte realmente del servicio deseado. Aunque este sistema no es perfecto, consigue una reducción significativa del análisis de paquetes mediante software.

Con el fin de implementar de manera satisfactoria el proceso de selección de paquetes expuesto anteriormente, el software del nodo de recepción debe activar el filtro en cuanto el cliente solicite un servicio dado. Normalmente, un filtro de este tipo se activa cuando el software cliente comunica una solicitud al receptor a través de una interfaz de programación, solicitando que cada aplicación cliente esté escrita específicamente para fines del receptor DVB-T. Además, con el fin de evitar el análisis mediante software de paquetes innecesarios y de, por lo tanto, optimizar el rendimiento del receptor, los filtros deben eliminarse en cuanto no sean necesarios.

A modo de antecedente, se hace referencia a "Digital Video Broadcasting (DVB)" Normas ETSI Standards, Instituto Europeo de Normas de Telecomunicaciones (European Telecommunications Standards Institute), Sophia-Antipo, FR, vol. BC, no. V111, Septiembre de 2001 (09/2001), XP014004985 ISSN: 0000-0001; Deering Cisco Systems W Fenner AT&T Research H Haberman IBM S: "Multicast Listener Discovery (MLD) for IPv6" Norma IETF, Grupo de Trabajo de Ingeniería de Internet (Internet Engineering Task Force), IETF, CH, Octubre de 1999 (10/1999), XP015008493 ISSN: 0000-0003, y "Digital Video Broadcasting (DVB)" Normas ETSI, Instituto Europeo de Normas de Telecomunicaciones, Sophia-Antipo, FR, vol. BC, no. V111, Agosto de 2001 (08/2001), XP014004072 ISSN: 0000-0001.

Es deseable obtener un método para activar y eliminar un filtro que sea independiente de interfaces de programación especiales.

Léxico

DVB-T: Radiodifusión de vídeo digital terrestre (Digital Vídeo Broadcast-Terrestrial)

IGMP: Protocolo de gestión de grupos de internet (Internet Group Management Protocol)

IP: Protocolo de Internet (Internet Protocol)

IPv4: Versión 4 del Protocolo de Internet (Internet Protocol Version 4)

IPv6: Versión 6 del Protocolo de Internet (Internet Protocol Version 6)

MAC: Control de acceso al medio (Media Access Control)

MLD: Descubrimiento de oyentes de multidifusión (Multicast Listener Discovery)

PID: Identificador de programa (Program identifier)

SI: Información del servicio (Service Information)

SIT: Tabla de información de servicios (Service Information table); obsérvese que ésta no es la tabla que almacena la SI en la norma DVB.

UDP: Protocolo de datagramas de usuario (User Datagram Protocol)

\vskip1.000000\baselineskip

Resumen de la invención

Los problemas identificados anteriormente pueden solucionarse por la invención definida en las reivindicaciones posteriores y se consigue un avance técnico en la técnica proporcionando métodos activados por eventos para implementar o eliminar un filtro utilizado en la recepción de una transmisión de multidifusión, tal como una transmisión DVB-T.

Un método a modo de ejemplo para implementar un filtro incluye: detectar un mensaje, tal como un mensaje IPv6 MLD, donde el mensaje comprende una dirección de un grupo de multidifusión y una solicitud para unirse al grupo de multidifusión para recibir una transmisión de multidifusión; como respuesta a la detección del mensaje, determinar un parámetro de filtro (por ejemplo, un número PID y/o una dirección MAC) necesario para recibir la transmisión de multidifusión; e implementar el parámetro de filtro para recibir la transmisión de multidifusión.

Un método a modo de ejemplo para eliminar un filtro utilizado en la recepción de una transmisión de multidifusión incluye: detectar un mensaje, donde el mensaje comprende una dirección de un grupo de multidifusión y una solicitud para abandonar el grupo de multidifusión; como respuesta a la detección del mensaje, determinar un parámetro de filtro necesario para recibir la transmisión de multidifusión; y eliminar el parámetro de filtro.

También se desvelan métodos alternativos en los que la implementación o eliminación del filtro se basa en la detección de llamadas directas a procedimientos, tales como una llamada Setsockopt. Un método a modo de ejemplo de utilización de llamadas directas a procedimientos para implementar un filtro para su utilización en la recepción de una transmisión multidifusión incluye: detectar una llamada directa a procedimientos, donde la llamada directa a procedimientos comprende una dirección de un grupo de multidifusión y una solicitud para unirse al grupo de multidifusión para recibir una transmisión de multidifusión; como respuesta a la detección de la llamada directa a procedimientos, determinar un parámetro de filtro necesario para recibir la transmisión de multidifusión; e implementar el parámetro de filtro para recibir la transmisión de multidifusión.

De manera ventajosa, según varias realizaciones de la presente invención, los cambios en el filtro no requieren una interfaz de programación especial entre una aplicación cliente y un receptor de la red de multidifusión y, por lo tanto, no requieren que la aplicación cliente esté escrita específicamente para fines del receptor de red de multidifusión.

Otros aspectos adicionales de la presente invención resultarán evidentes a lo largo de la siguiente descripción y haciendo referencia a los dibujos adjuntos.

\vskip1.000000\baselineskip

Breve descripción de los dibujos

La fig. 1A es un diagrama de bloques de una red a modo de ejemplo en la que puede utilizarse la presente invención;

la fig. 1B es un diagrama de bloques que describe los cambios que tienen lugar en el paquete en el receptor DVB en una realización de la presente invención;

la fig. 2 es un diagrama de bloques a modo de ejemplo del proceso requerido para que un terminal de recepción se una a un grupo de multidifusión;

la fig. 3 es un diagrama de bloques a modo de ejemplo del proceso requerido para que un terminal de recepción abandone un grupo de multidifusión;

la fig. 4 es un diagrama de bloques a modo de ejemplo de la relación entre la tabla de oyentes UDP y la SIT;

la fig. 5 es un diagrama de flujo de proceso que describe una realización a modo de ejemplo de la invención que sondea la tabla de oyentes UDP;

la fig. 6 es un diagrama de flujo de proceso que describe una realización a modo de ejemplo de la invención que detecta eventos IGMP;

la fig. 7 es un diagrama de flujo de proceso que ilustra una realización a modo de ejemplo que detecta mensajes de descubrimiento de oyentes de multidifusión (MLD) para llevar a cabo la creación/eliminación del filtro.

la fig. 8 es un diagrama de flujo de proceso que ilustra una realización a modo de ejemplo que detecta llamadas directas a procedimientos para llevar a cabo la creación/eliminación del filtro.

\vskip1.000000\baselineskip

Descripción detallada

En la siguiente descripción de diversas realizaciones, se hace referencia a los dibujos adjuntos que forman parte de la misma y en los que se muestra a modo de ilustración diversas realizaciones en las que puede ponerse en práctica la invención. Debe entenderse que pueden utilizarse otras realizaciones y que pueden realizarse modificaciones estructurales y funcionales sin apartarse del alcance de la presente invención.

La figura 1A describe una red de multidifusión básica que tiene al menos un terminal de transmisión 102 tal como un servidor de difusión de datos (datacast server) y un nodo de recepción 103. En esta realización, el nodo de recepción incluye un receptor DVB-T 104 y una máquina cliente 106. La máquina cliente 106 puede ser un ordenador personal, un descodificador, un dispositivo inalámbrico de mano, tal como un teléfono móvil, o similares, con un dispositivo de visualización para ver los datos que están emitiéndose. Además, debe entenderse que en este tipo de red normalmente está presente una pluralidad de nodos de recepción. Sin embargo, múltiples nodos de recepción están omitidos de la figura 1A por motivos de simplicidad. La máquina cliente 106 también está acoplada al terminal de transmisión 102 a través de una red bidireccional, tal como una red GSM o GPRS, para, por ejemplo, transmitir solicitudes de servicios al terminal de transmisión 102.

En una red de multidifusión del tipo mostrado en la figura 1A, el terminal de transmisión 102 divide cada programa en paquetes permitiendo colocar una pluralidad de programas en un canal de datos común. El terminal de transmisión transmite una pluralidad de paquetes en la forma de un flujo de elementos empaquetados en el que cada paquete incluye parámetros de filtro en la forma de un identificador de programa (PID) y una dirección de control de acceso al medio (MAC) DVB. El receptor 104 del nodo de recepción 103 identifica los paquetes deseados a partir de una pluralidad de paquetes de datos en el canal de multidifusión usando parámetros de filtro. En particular, la identificación de paquetes es un proceso de dos etapas que tiene lugar en el receptor, donde la primera etapa es una selección rudimentaria mediante hardware y la segunda etapa es una identificación positiva en software.

La figura 1B describe la relación entre paquetes utilizada por los paquetes de flujo de transporte, los paquetes de encapsulación DVB multiprotocolo y los paquetes IP enviados por receptor a la máquina cliente. El paquete de flujo de transporte es un paquete de 188 bytes que contiene una cabecera 122 de 4 bytes y una carga útil 124 de 184 bytes; éstos son los paquetes enviados por el transmisor DVB-T. Cuando se recibe este paquete, el receptor examina este paquete de flujo de transporte usando hardware, y selecciona cada paquete del flujo cuyo PID coincida con los criterios que el filtro haya identificado. Después, el receptor extrae del paquete la información de flujo de transporte, normalmente en software, para acceder al paquete de encapsulación multiprotocolo DVB. Este paquete contiene una cabecera que transporta una dirección MAC 126 única, una sección de datagrama que contiene datos 128, y una sección de suma de comprobación 130 para fines de corrección de errores. El receptor examina la dirección MAC y acepta todos los paquetes que sean parte del programa deseado.

Usar un filtro de dos etapas del tipo descrito minimiza la carga en la pila de protocolos del receptor y del cliente, puesto que el hardware puede examinar rápidamente el PID. Mediante este análisis por hardware, se elimina una parte significativa de paquetes no deseados sin que entren en la pila de protocolos. Se conocen en la técnica otros métodos de selección de paquetes mediante nodos de recepción.

Una vez que el receptor determina que el paquete DVB es parte del programa deseado, se extrae la encapsulación DVB para producir un paquete IP. El paquete IP está compuesto por una cabecera 132 y por una carga útil 134 y puede aceptarse rápidamente por la máquina cliente. La relación entre los tres paquetes se describe de manera descendente en la figura 1B desde el paquete de flujo de transporte hasta el paquete IP.

Además, una realización alternativa incluye conectar un receptor DVB-T a un terminal portátil, tal como un asistente digital personal mediante un cable USB, o usando un receptor DVB de tipo PCMCIA junto con un PC cliente. Todavía en otra realización, el receptor DVB-T está integrado totalmente dentro de un terminal móvil, tal como un teléfono móvil, acoplando el receptor DVB a través de un bus interno a la CPU del teléfono.

Todavía en otra realización, un sistema de este tipo puede ser software que, cuando se ejecute en un PC cliente que tenga una interfaz a un receptor DVB-T, indicará automáticamente al receptor que se suscriba a un servicio dado.

La figura 2 muestra el proceso mediante el cual un nodo de recepción solicita acceder a un flujo de multidifusión y comienza a capturar información de ese flujo según una realización de la presente invención. En la etapa 202, la máquina cliente abre un socket IP de multidifusión para la recuperación de datos cuando una aplicación en la máquina cliente solicite datos de multidifusión. En la etapa 204, el receptor asocia este socket con un número de puerto. En este punto del proceso, se crea una entrada en la tabla de oyentes UDP.

La tabla de oyentes UDP es una tabla que realiza un seguimiento de cada conexión de datos que la máquina cliente tiene abierta actualmente. La tabla contiene entradas con información que permiten a un sistema realizar un seguimiento de los flujos de paquetes entrantes.

En una realización de la presente invención, una tabla de información de servicios (SIT) realiza un seguimiento de diversa información para su uso en la recuperación de datos de multidifusión. En particular, la SIT realiza un seguimiento de los números de puerto UDP, de los parámetros de filtro para identificar paquetes entrantes y del estado de filtro que indica si un filtro está actualmente habilitado. La información de esta tabla se actualiza según se necesite, tanto a partir de los cambios internos de estado del receptor, por ejemplo, la activación de un filtro, como a partir de la información de servicios transmitida por la red, por ejemplo, nuevos servicios disponibles.

En la etapa 206, el nodo de recepción se une a un grupo de multidifusión, normalmente transmitiendo un paquete IGMP "de solicitud de pertenencia a un grupo" a los nodos de conmutación en dirección hacia la red. En la etapa 208, los parámetros de filtro se recuperan de la tabla SIT y se reenvían, en la etapa 210, al receptor. En la etapa 212, el receptor implementa el filtro usando los parámetros de filtro.

La figura 3 muestra el proceso mediante el cual un nodo de recepción finaliza su pertenencia a un grupo de multidifusión. En la etapa 302, la máquina cliente abandona el grupo de multidifusión cuando la aplicación que accede a los datos determina que la conexión de multidifusión ya no es necesaria. Normalmente, esto se realiza enviando un mensaje de "abandono" IGMP a los nodos de conmutación en dirección hacia la red. En la etapa 304, la máquina cliente cierra el socket y borra la entrada de la tabla de oyentes UDP, finalizando de ese modo la conexión entre el software cliente y el flujo de datos de multidifusión. En la etapa 306, los parámetros de filtro se recuperan de nuevo de la SIT. Estos parámetros se reenvían al receptor en la etapa 308, el cual, en la etapa 310, elimina el filtro.

La figura 4 muestra la relación entre una SIT y una tabla de oyentes UDP que el nodo de recepción utiliza según una realización de la presente invención.

La tabla de oyentes UDP mantenida por la máquina cliente se usa normalmente como un índice de todas las señales UDP entrantes y de las direcciones IP locales que la máquina cliente haya asignado a las señales. Según una realización de la presente invención, la relación entre la SIT y la tabla de oyentes UDP se utiliza para permitir activar y eliminar los filtros sin ninguna interfaz de programación especial, tal como se describirá.

Haciendo referencia a la figura 4, la SIT 402 contiene un número de entradas 406a, 406b, 406c, correspondiendo cada una a un flujo de datos. Cada entrada 406 incluye un número de puerto, parámetros de filtro de un flujo de datos de multidifusión y el estado, activo o inactivo, de cualquier filtro que esté asociado con ese flujo. Los números de puerto tienen normalmente una longitud de 32 bits y los parámetros de filtro incluyen, pero no están limitados a, el PID y MAC. Los expertos en la materia entenderán que, aunque no se muestre en la figura 4, la SIT puede contener otros datos.

La tabla 404 de oyentes UDP contiene un número de entradas 408a, 408b, 408c, correspondiendo cada entrada a un puerto que está activo actualmente en la máquina. Cada entrada 408 incluye una dirección IP local y un número de puerto UDP. Los expertos en la materia entenderán que la tabla de oyentes UDP puede incluir otra información.

Las entradas de la tabla de oyentes UDP asociadas con datos de multidifusión están identificadas con un valor 0.0.0.0 como su dirección IP local. De ese modo, es fácil identificar todos los flujos de multidifusión abiertos actualmente con los que el receptor está conectado extrayendo todas las entradas de la tabla de oyentes UDP con este valor. Los puertos de multidifusión de la tabla UDP pueden compararse entonces con las entradas de multidifusión de la SIT, permitiendo de ese modo que el receptor determine el estado de todas las conexiones de multidifusión y establecer si hay que habilitar, eliminar o ignorar filtros.

La figura 5 es un diagrama de flujo que ilustra un método a modo de ejemplo mediante el cual un nodo de recepción gestiona filtros según una realización de la presente invención.

\newpage

En la etapa 502, la tabla de oyentes UDP se sondea para obtener una lista de todas las entradas que tengan 0.0.0.0 como su dirección IP local. Puesto que el sondeo de la tabla de oyentes UDP es continuo, las actualizaciones del estado de los filtros no requieren ningún disparador especializado. En una realización alternativa, la inspección continua de la tabla de oyentes UDP se sustituye por la detección pasiva de adiciones o eliminaciones en la tabla de oyentes UDP de cualquier dirección IP local que tenga un valor de dirección IP local de multidifusión.

En la etapa 504, la SIT se examina en busca de entradas que no se correspondan con las entradas de la lista UDP recopiladas en la etapa 502. Si existen entradas en la SIT que no se correspondan con las de la lista UDP, en la etapa 508, estas entradas SIT se examinan para determinar si tienen un estado "activo". Las entradas SIT que no estén en la lista UDP pero que tengan un estado activo son conexiones que se han cerrado y que, por consiguiente, ya no se necesitan. En la etapa 510, los filtros correspondientes a estas entradas se eliminan y sus estados se reinicializan a "inactivo". Este proceso, etapas 504 a 510, se repite después hasta que se haya determinado que todas las entradas SI se correspondan con una entrada UDP o estén "inactivas".

En este punto, en la etapa 512, se escudriñan todas las entradas SI que coincidan con las entradas de la lista UDP. En particular, en la etapa 514, se examina el estado de las entradas SI. Si la entrada está "inactiva", entonces se aplica un filtro en la etapa 516 y el estado se establece como "activo". Si no hay entradas inactivas en la lista SI que se correspondan con la lista UDP, el control se devuelve a la etapa 502 y se repite el proceso de gestión de filtros. Las etapas descritas anteriormente garantizan que los filtros se eliminen rápidamente después de que el cliente haya cerrado la conexión de multidifusión, minimizando de ese modo la carga innecesaria en el sistema.

La secuencia de procesamiento en la presente invención no es crucial para el funcionamiento y, por tanto, las etapas desveladas en la figura 5 pueden reordenarse. Por ejemplo, las entradas UDP que coincidan con las entradas SI pueden disponerse primero (etapas 512 a 516), con la etapa de eliminación (etapa 510) al final de una iteración. Además, varias de estas etapas pueden procesarse en paralelo, de manera que la etapa 510 de eliminación puede ejecutarse simultáneamente con la etapa de aplicación de filtro (etapa 516). Además, no necesita generarse una lista de entradas que tengan que examinarse, sino que en su lugar puede procesarse una entrada SI o UDP a la vez.

La figura 6 es un diagrama de flujo que ilustra un método a modo de ejemplo en el que se usan mensajes IGMP que se originan en un nodo de recepción para determinar si es necesario añadir o eliminar un filtro. Los paquetes IGMP son señales de red que proporcionan información a los nodos de conmutación acerca de los nodos de recepción con los que están conectados. Este tipo de señal se usa para minimizar la carga en la red, garantizando que un flujo de datos sólo se repite si un oyente conectado al nodo va a suscribirse al mismo. Al detectar las señales IGMP transmitidas por el nodo de recepción, este método no requiere un sondeo repetitivo, solo una supervisión pasiva, con lo que se consigue una iniciación de filtro independientemente de cualquier interfaz de programación especial.

Haciendo referencia a la figura 6, en las etapas 602 y 604 el sistema detecta la recepción de un mensaje IGMP. Si se detecta una señal IGMP, entonces, en la etapa 606, la máquina cliente la examina para determinar la entrada de la SIT con la que se corresponde el mensaje IGMP. En la etapa 608, la máquina cliente determina si el mensaje IGMP es una solicitud para unirse a un grupo de multidifusión o una solicitud para abandonar un grupo de multidifusión.

Si en la etapa 608 se determina que la señal IGMP es una solicitud para unirse a un grupo, entonces, en la etapa 610, se examina el estado de filtro. Los filtros "activos" se ignoran, provocando que la máquina cliente supervise de nuevo el tráfico IGMP en la etapa 602. Si el estado de filtro en la etapa 610 es "inactivo", en la etapa 612 se activa un filtro basándose en los parámetros de filtro y la entrada en la SIT se actualiza para reflejar el nuevo estado "activo". Con el filtro activado, la exploración continúa en la etapa 602.

Si en la etapa 608 el mensaje IGMP es una solicitud para abandonar el grupo de multidifusión, entonces en la etapa 614 se determina el estado de la entrada SI con la que se corresponde el mensaje. Si el estado de la entrada es "inactivo" se ignora puesto que no hay ningún filtro que eliminar y continúa la detección en la etapa 602. Si el estado de la entrada es "activo", entonces, en la etapa 616, el filtro se elimina y el estado de la entrada se cambia a "inactivo". Con el filtro eliminado, la exploración continúa en la etapa 602.

Esta realización se basa en la detección pasiva de señales y por lo tanto su impacto en el rendimiento del sistema es mínimo.

La figura 7 es un diagrama de flujo de proceso que ilustra una realización a modo de ejemplo que detecta mensajes de descubrimiento de oyentes de multidifusión (MLD) para llevar a cabo la creación/eliminación de filtros.

En general, los mensajes MLD se usan por un nodo de conmutación IPv6 (por ejemplo, un encaminador (router)) para descubrir la presencia de oyentes de multidifusión (es decir, nodos de recepción) en sus enlaces directamente conectados. Cuando una aplicación cliente, tal como un reproductor de audio o de vídeo, desea recibir una transmisión de multidifusión (por ejemplo, archivos o flujos de datos), crea un socket, asocia el socket con un puerto de la máquina cliente y después se une a un grupo de multidifusión correspondiente a la transmisión de multidifusión de interés. Un grupo de multidifusión es el canal de transmisión para los datos emitidos. La aplicación se une al grupo de multidifusión transmitiendo un mensaje de Informe MLD, tal y como se describirá en detalle posteriormente, al servidor de difusión de datos 102 a través de la red 108. Para recibir la transmisión, se necesita un filtro (incluyendo parámetros tales como el número PID y la dirección MAC) para filtrar los paquetes IP del flujo de datos que se correspondan con la transmisión de multidifusión de interés. Por el contrario, cuando una aplicación cliente desea dejar de recibir una transmisión de multidifusión, abandona el grupo de multidifusión transmitiendo un mensaje de Finalización MLD, tal y como se describirá también posteriormente, y cierra el socket. Según la realización de la invención ilustrada en la figura 7, tal y como se describirá en detalle posteriormente, la máquina 102 cliente detecta mensajes MLD que se originan en una aplicación cliente y los utiliza para determinar si es necesario añadir un filtro en el receptor 104 para recibir una transmisión de multidifusión o borrarlo del receptor 104 debido a que la aplicación cliente haya dejado de recibir la transmisión de multidifusión.

Volviendo a la figura 7, en las etapas 702 y 704, la máquina cliente 106 espera la detección de un mensaje MLD generado por una aplicación cliente. Un controlador de dispositivo de interfaz de red de la máquina cliente 106 identifica mensajes MLD en paquetes IPv6 mediante un valor anterior de Cabecera Siguiente de 58. Un mensaje MLD incluye, entre otras cosas, un campo para el "tipo" de mensaje MLD. Para fines de la presente invención, los tipos de mensaje de interés son el mensaje de Informe y el mensaje de Finalización mencionados anteriormente. Los mensajes de Informe y de Finalización se identifican mediante un decimal 131 ó 132, respectivamente, en el campo del tipo. Los mensajes de Informe y de Finalización también incluyen un campo que contiene una dirección específica de grupo de multidifusión IPv6 que la aplicación cliente quiere escuchar o ha dejado de escuchar, respectivamente.

Si, en la etapa 704, se detecta un mensaje MLD, entonces, en la etapa 706, la máquina cliente realiza una consulta de las entradas de información de servicios en la base de datos 708 de información de servicios. La base de datos 708 incluye entradas para cada servicio disponible que está transmitiendo el servidor de difusión de datos 102. Cada entrada incluye preferentemente una dirección IP de multidifusión, un número de puerto, parámetros de filtro (por ejemplo, un número PID y una dirección MAC) y un indicador de estado de filtro. La información en la base de datos 708 se rellena y se actualiza según necesite el receptor 104 (por ejemplo, con un número de puerto asignado por la aplicación o máquina cliente 106 y el estado de filtro cambia para cada entrada) y el servidor de difusión de datos 102 (por ejemplo, con nuevas entradas para servicios recientemente disponibles). Aunque preferentemente reside en la máquina cliente 106, la base de datos 708 puede estar ubicada, en cambio, en una red tal como, por ejemplo, la red 108.

Volviendo a la etapa 706, la consulta de las entradas de información de servicios implica que la máquina cliente 106 transmita la dirección 710 de grupo de multidifusión a la base de datos de información de servicios 708 que, a su vez, devuelve una entrada de información de servicio 712 que tiene una dirección de grupo de multidifusión que coincide con la dirección transmitida 710. Además de la dirección IP de multidifusión coincidente, la entrada de información de servicio 712 incluirá un número de puerto, parámetros de filtro y un indicador de estado de filtro. En la etapa 714, la máquina cliente 106 determina el tipo de mensaje MLD o, más específicamente, si el mensaje MLD detectado en la etapa 704 es un mensaje de Informe 716 o un mensaje de Finalización 718.

Si el mensaje MLD es un mensaje de Informe 716, entonces, en la etapa 720, la máquina cliente 106 determina, a partir del indicador de estado de filtro en la entrada de información de servicio 712 devuelta, si el filtro está activo. Si está activo, entonces la máquina cliente 106 simplemente no necesita realizar ninguna acción y, en cambio, vuelve a la etapa 702 para esperar la detección de mensajes MLD adicionales. Sin embargo, si en la etapa 720 se determina que el filtro está inactivo, entonces, en la etapa 722, la máquina cliente 106 envía una solicitud al receptor 104 para activar el filtro usando los parámetros de filtro pertinentes. La solicitud puede incluir la dirección IP de multidifusión (u otro identificador) que el receptor 104 pueda usar para obtener los parámetros de filtro ya sea de la base de datos 708 o de otras tablas de información de servicios que puedan haberse recibido en una emisión del servidor de difusión de datos 102 (por ejemplo, DVB-T) y almacenado en el receptor 104. Como alternativa, la solicitud puede incluir los propios parámetros de filtro. Después, la máquina cliente 106 vuelve a la etapa 702 para esperar mensajes MLD adicionales.

Si en la etapa 714 se determina que el mensaje MLD es un mensaje de Finalización, la máquina cliente 106 determina a partir del indicador de estado de filtro recibido de la base de datos 708 si el filtro está inactivo. Si el filtro está inactivo, la máquina cliente 106 no necesita realizar ninguna acción. En cambio, la máquina cliente 106 vuelve a la etapa 702 para esperar la detección de mensajes MLD adicionales. Sin embargo, si el filtro está activo, entonces, en la etapa 726, la máquina cliente 106 envía una solicitud al receptor 104 para eliminar el filtro y vuelve a la etapa 702 para continuar supervisando la detección de mensajes MLD adicionales.

La figura 8 es un diagrama de flujo de proceso que ilustra una realización a modo de ejemplo que detecta llamadas directas a procedimientos para llevar a cabo la creación/eliminación de filtros.

Brevemente, en esta realización, una aplicación cliente que desee unirse a un grupo de multidifusión IP crea un socket, asocia ese socket con un número de puerto de la máquina cliente y después usa una llamada directa a procedimientos, tal como una llamada "Setsockopt", tal y como se describirá en detalle posteriormente, para convertirse en un miembro del grupo de multidifusión IP. Una aplicación cliente que desee finalizar una recepción de datos de multidifusión IP usa una llamada Setsockopt para finalizar su pertenencia al grupo de multidifusión IP, tal y como se describirá también posteriormente. La aplicación cliente envía llamadas Setsockopt desde la máquina cliente 106 al servidor de difusión de datos 102 a través de la red 108.

Una llamada directa a procedimientos, tal como una llamada Setsockopt, es una llamada a funciones de la interfaz de programación de aplicaciones ("API", application programming interface) de sockets proporcionada por la pila TCP/IP, tal y como se conoce ampliamente en la técnica. La llamada setsockopt, en particular, permite a un programador manipular las opciones asociadas con un socket; está definida en el API de sockets y está normalizada en Ipv6. De hecho, es una norma en Ipv4. Según la realización ilustrada en la figura 8, tal y como se describirá adicionalmente en detalle más adelante, la máquina cliente 106 detecta llamadas Setsockopt que se hayan originado en la aplicación cliente y usa estas llamadas para determinar si es necesario implementar un filtro en el receptor 104 para recibir una transmisión de multidifusión o borrarlo del receptor 104 después de dejar de recibir la transmisión de multidifusión.

Volviendo a la figura 8, en las etapas 802 y 804, la máquina cliente 106 espera la detección de una llamada Setsockopt generada por una aplicación cliente. En particular, la pila IP entregará la información de la llamada Setsockopt a un controlador de dispositivo de interfaz de red de la máquina cliente 106, que genera después una solicitud de filtro. Una llamada Setsockopt contendrá diferente información dependiendo de si la llamada está enviándose para solicitar la unión a un grupo de multidifusión IP o para abandonar un grupo de multidifusión IP. Si se envía para solicitar la unión a un grupo de multidifusión IP, la llamada Setsockopt contendrá un identificador de socket (por ejemplo, para asociarse con un número de puerto), un parámetro para la unión al grupo de multidifusión IP (por ejemplo, IP_ADD_MEMBERSHIP) y una dirección de grupo de multidifusión IPv6 correspondiente al grupo de multidifusión IP al que la aplicación cliente desea unirse. Por el contrario, si la llamada Setsockopt se envía para abandonar un grupo de multidifusión IP, la llamada contendrá un identificador de socket, un parámetro para abandonar el grupo de multidifusión IP (por ejemplo, IP_DROP_MEMBERSHIP) y una dirección de grupo de multidifusión IPv6 correspondiente al grupo de multidifusión IP que la aplicación cliente desea abandonar.

Si, en la etapa 804, se detecta una llamada Setsockopt, entonces, en la etapa 806, la máquina cliente 106 realiza una consulta de las entradas de información de servicios de la base de datos 808 de información de servicios. Tal como se ha expuesto anteriormente en relación con la figura 7, la base de datos 808 incluye entradas para cada servicio disponible, y cada entrada incluye una dirección IP de multidifusión, un número de puerto, parámetros de filtro y un indicador de estado de filtro. La base de datos 808, aunque reside preferentemente en la máquina cliente 106, puede residir en cambio en una red tal como la red 108. La consulta a la base de datos realizada en la etapa 806 implica que la máquina cliente 106 transmita la dirección 810 de grupo de multidifusión a la base de datos de información de servicios 808. La base de datos 808 responderá con una entrada 812 que contiene una dirección de grupo de radiodifusión que coincide con la dirección 810 transmitida. Además de la dirección IP de multidifusión coincidente, la entrada 812 devuelta incluirá un número de puerto, parámetros de filtro y un indicador de estado de filtro.

En la etapa 814, la máquina cliente 106 determina si la llamada Setsockopt incluye un parámetro para solicitar la unión al grupo de multidifusión IP (por ejemplo, IP_ADD_MEMBERSHIP) o un parámetro para abandonar el grupo de multidifusión IP (por ejemplo, IP_DROP_MEMBERSHIP). Si la llamada Setsockopt incluye un parámetro IP_ADD_MEMBERSHIP, entonces, en la etapa 820, la máquina cliente 106 determina, a partir del indicador de estado de filtro de la entrada 812 de información de servicios devuelta, si el filtro está activo. Si está activo, entonces la máquina cliente 106 no necesita realizar ninguna acción y simplemente vuelve a la etapa 802 para esperar la detección de llamadas Setsockopt adicionales. Sin embargo, si en la etapa 820 se determina que el filtro es inactivo, entonces, en la etapa 822, la máquina cliente 106 envía una solicitud al receptor 104 para activar el filtro usando los parámetros de filtro incluidos en la entrada 812 de información de servicio que se devolvió como respuesta a la consulta a la base de datos que se produjo en la etapa 806. La solicitud puede incluir la dirección IP de multidifusión que el receptor 104 puede usar para obtener los parámetros de filtro de la base de datos 808 o de otras tablas de información de servicios almacenadas en el dispositivo 104 de recepción. Como alternativa, la solicitud puede incluir los propios parámetros de filtro reales. Después, la máquina cliente 106 vuelve a la etapa 802 para esperar la detección de otras llamadas de Setsockopt.

Si en la etapa 814 se determina que la llamada Setsockopt incluye un parámetro IP_DROP_MEMBERSHIP, la máquina cliente 106 determina si el filtro está inactivo. Si el filtro está inactivo, la máquina cliente 106 no necesita modificar ningún filtro en el receptor 104 y vuelve a la etapa 802 para esperar la detección de llamadas Setsockopt adicionales. Sin embargo, si el filtro está activo, entonces, en la etapa 826, la máquina cliente 106 envía una solicitud al receptor 104 para eliminar el filtro y después vuelve a la etapa 802 para esperar la detección de llamadas Setsockopt adicionales.

Como resulta evidente a partir de lo anterior, según varias realizaciones de la presente invención, los cambios en los filtros no requieren, de manera ventajosa, una interfaz de programación especial entre la aplicación cliente y el receptor 104 y, por tanto, no requieren que la aplicación cliente esté escrita específicamente para fines del receptor de multidifusión. Además, se proporciona un mecanismo eficaz para garantizar que los filtros sólo se creen cuando se necesiten y se eliminen cuando la aplicación cliente abandone el grupo de multidifusión. Como en la realización de la figura 6, las realizaciones de las figuras 7 y 8 se basan en la detección pasiva de señales (pero en un entorno IPv6 en lugar de en un entorno IPv4) y, por lo tanto, el impacto en el rendimiento del sistema es mínimo.

También se apreciará que los procesos ilustrados anteriormente, o partes de los mismos, pueden ponerse en práctica mediante dispositivos que no sean la máquina cliente 106. Por ejemplo, la máquina cliente 106 puede transmitir mensajes MLD o llamadas directas a procedimientos recibidos desde una aplicación cliente al receptor 104 que, a su vez, usa esta información para poner en práctica, por ejemplo, los procesos de las figuras 7 y 8.

Las diversas características y ventajas de la presente invención son evidentes a partir de la memoria descriptiva detallada y, por tanto, las reivindicaciones adjuntas pretenden cubrir todas las características y ventajas de la invención que están dentro del alcance de la invención.

Además, puesto que a los expertos en la materia se les pueden ocurrir numerosas modificaciones y variaciones, la presente invención no está limitada a la construcción y al funcionamiento exactos ilustrados y descritos en este documento.

Claims

1. Un método que comprende, en un nodo de recepción:

detectar un mensaje (206, 302), donde el mensaje comprende una dirección de un grupo de multidifusión y una solicitud para unirse a o abandonar el grupo de multidifusión;

como respuesta a la detección del mensaje, determinar y recuperar (208, 306) un parámetro de filtro de una tabla de información de servicios del nodo de recepción necesario para recibir la transmisión de multidifusión, la tabla de información de servicios incluyendo parámetros de filtro; e

implementar o eliminar (212, 310), respectivamente, un filtro según el parámetro de filtro recuperado,

caracterizado porque

la tabla de información de servicios incluye información de estado de filtro que indica si el filtro está habilitado actualmente.

2. El método según la reivindicación 1, en el que el mensaje es un mensaje de dispositivo de oyentes de multidifusión (MLD).

3. El método según la reivindicación 1, en el que el mensaje es un mensaje IGMP.

4. El método según la reivindicación 1, en el que el mensaje se detecta mediante un valor Cabecera Siguiente de 58 en una cabecera inmediatamente anterior.

5. El método según la reivindicación 1, en el que la solicitud para unirse al grupo de multidifusión comprende información en un campo de tipo del mensaje.

6. El método según la reivindicación 5, en el que la información es un decimal 131.

7. El método según la reivindicación 1, en el que implementar el parámetro de filtro incluye enviar una solicitud a un receptor para implementar el parámetro de filtro.

8. El método según la reivindicación 7, en el que el receptor es un receptor de radiodifusión de vídeo digital terrestre (DVB-T).

9. El método según la reivindicación 7, en el que enviar una solicitud al receptor para implementar el parámetro de filtro incluye enviar el parámetro de filtro.

10. El método según la reivindicación 1, en el que el método está implementado en un terminal de mano inalámbrico.

11. El método según la reivindicación 1, en el que el parámetro de filtro comprende un número de identificador de programa (PID) y una dirección de control de acceso al medio (MAC).

12. Un terminal (103), que comprende:

un dispositivo de memoria que almacena un programa; y

un procesador en comunicación con el dispositivo de memoria, el procesador operativo con el programa para:

detectar un mensaje (206, 302), en el que el mensaje comprende una dirección de un grupo de multidifusión y una solicitud para unirse a o abandonar el grupo de multidifusión;

como respuesta a la detección del mensaje, determinar y recuperar (208, 306) un parámetro de filtro de una tabla de información de servicios del terminal necesario para recibir la transmisión de multidifusión, la tabla de información de servicios incluyendo parámetros de filtro; e

caracterizado porque

13. El terminal según la reivindicación 12, en el que el terminal es un terminal de mano inalámbrico.

14. El terminal según la reivindicación 12 ó 13, en el que el mensaje es un mensaje de dispositivo de oyentes de multidifusión (MLD).

15. El terminal según la reivindicación 12 ó 13, en el que el mensaje es un mensaje IGMP.

16. El terminal según la reivindicación 12, en el que implementar el parámetro de filtro incluye enviar una solicitud a un receptor para implementar el parámetro de filtro.

17. El terminal según la reivindicación 16, en el que el receptor es un receptor de radiodifusión digital terrestre (DVB-T).

18. El terminal según la reivindicación 12, en el que el parámetro de filtro comprende un número de identificador de programa (PID) y una dirección de control de acceso al medio (MAC).

19. El terminal según la reivindicación 12, en el que el mensaje se detecta mediante un valor Cabecera Siguiente de 58 en una cabecera inmediatamente anterior.

20. El terminal según la reivindicación 12, en el que la solicitud para unirse al grupo de multidifusión comprende información en un campo de tipo del mensaje.

21. El terminal según la reivindicación 20, en el que la información es un decimal 131.

22. Un programa informático que se ejecuta en un procesador para realizar un método según una cualquiera de las reivindicaciones 1 a 12.