MX2011003464A - Dispositivo de red y metodo para establecer una sesion de iptv. - Google Patents

Abstract

La presente invención se relaciona con un dispositivo de red y un método en el dispositivo de red. El dispositivo de red comprende un conector para conectarse a una red local, un servidor para proporcionar a un descodificador que se localiza en la red local información sobre el contenido disponible y una dirección en la red local en donde el contenido está disponible desde un módulo representante IPTV para concordar el contenido de un contenido IPTV para que sea accesible desde un servidor IPTV que se localiza en una segunda red, la segunda red está conectada con la primera red con un dispositivo de compuerta, en donde el descodificador solicita el contenido en una dirección y recibe un contenido de IPTV del servidor de IPTV.

Description

DISPOSITIVO DE RED Y METODO PARA ESTABLECER UNA SESION DE IPTV CAMPO DE LA INVENCION La presente invención se relaciona de manera general con IPTV y en particular con un dispositivo y un método para establecer una sesión de IPTV.

ANTECEDENTES DE LA INVENCION Se pretende que esta sección introduzca al lector a los diversos aspectos del ámbito los cuales se pueden relacionar con diversos aspectos de la presente invención que se describen y/o reivindican en lo siguiente. Se considera que está discusión será útil para proporcionar al lector información antecedente para facilitar una mejor comprensión de los diversos aspectos de la presente invención. En consecuencia, debe entenderse que estas afirmaciones deben leerse bajo esa perspectiva y no es admisión de técnica anterior.

La televisión por protocolo de Internet, IPTV, generalmente se distribuye de manera extremo a extremo entre un servidor de IPTV y clientes de IPTV. Un cliente que se localiza en una red casera tiene acceso al contenido de IPTV en un servidor de IPTV que se localiza en la Internet. El servidor no se localiza en la red casera. Cada uno del cliente localizado en la red casera se conecta individualmente al servidor para obtener contenido de IPTV. El cliente se registra en una dirección de multidifusión utilizando, por ejemplo, el protocolo de administración de grupo de Internet, IGMP, como se especifica en IETF RFC 2236.

El consorcio de la industria de difusión de video digital ha especificado un modelo de referencia para la red casera. Este es el "DVB-HN (Home Network) Reference Model Phase 1; DVB Document A109; February 2007" y a continuación se denominará como DVB-HN. DBV-HN propone un modelo de referencia para la red casera para el transporte de una corriente de transporte MPEG-2 basada en servicios de DVB sobre una red basada en IP. Las corrientes de transporte MPEG-2 se suministran entre otras sobre la red de acceso de banda ancha utilizando los protocolos DVB IP fase 1 que se especifican en "Transport of MPEG 2 Transport Stream (TS) Based DVB Services over IP Based Networks; DVB Document A086 Rev, 3; March 2007", también denominada como ETSI TS 102 034 vi.3.1, e indicada como DVB-IP en lo siguiente. En particular, DVB-IP define un mecanismo de descubrimiento de servicio y selección (SD&S) para DVB basado en servicios A/B sobre redes IP bidireccionales . El descubrimiento de servicio es un mecanismo que permite el descubrimiento de servicios DVB-IV disponibles sobre redes IP bidireccionales. El descubrimiento de servicio proporciona la presentación de una lista de los servicios con información en el receptor, lo que permite al usuario seleccionar un servicio y tener acceso a un servicio seleccionado .

La figura 1 ilustra una red casera de acuerdo con DVB-HN. Comprende una compuerta 1 casera, también indicada en lo siguiente como HG que comprende un medio de enrutado para interconectar una red 5 casera a una red 7 de acceso. Un STB 2 de IPTV conectado a la red 5 casera tiene acceso al contenido sobre un servidor 6 de IPTV a través de la red 7 de acceso. El STB de IPTV comprende un módulo 21 de cliente SD&S y el servidor comprende un módulo 61 servidor de SD&S. Una vez que el servicio ha sido descubierto y seleccionado por el STB de IPTV, se suministra una corriente 8 de IPTV al STB de IPTV sobre la red de acceso. Se envía en modo de multidifusión, utilizando un protocolo de transporte de tiempo real (RTP) , de acuerdo con IETF RFC 3550.

DVB-HN también define el servicio de directorio de contenido que se define adicionalmente en "UPnP CDS: UPnP Content Directory Service Témplate Versión 1.01". UPnP CDS permite que los dispositivos localicen contenido que otros dispositivos pueden ofrecer. Casi cualquier tipo de contenido puede ser enumerado por medio de este servicio; por ejemplo canciones, películas, imágenes. Un cliente DVB- HN tal como el descodificador y anotado como HN STB en lo siguiente, utiliza este servicio de descubrimiento de contenido para tener acceso a servicios MPEG-2 sobre grabadoras de video personal que se localizan en la red casera. Habitualmente comprende un módulo de cliente CDS para realizar operaciones UPnP CDS. DVB-HN está reutilizando las lineas de guia DLNA e IEC 62481-1 Ed-1 e IEC 62481-2 Ed.l. IEC 62481-1 Ed-1 corresponde a "DLNA Networked Device Interoperability guidelines expanded March 2006 Volume 1: Architecture and Protocols". IEC 62481-2 Ed.l corresponde a "DLNA Networked Device Interoperability guidelines expanded March 2006 Volume 2: Media Format Profiles". En particular, un cliente DVB-HN es capaz de recuperar metadatos expuestos por un servidor DLNA al soportar CDS de UPnP. Soporta HTTP como transporte y protocolo de administración de sesión para recuperar contenido disponible en un servidor DLNA.

La figura 1 también ilustra distribución de contenido dentro de la red casera, de acuerdo con CDS de UPnP y DLNA. Un HN STB 3 tiene acceso al contenido sobre un servidor 4 HN que comprende un módulo 41 de servidor CDS. El HN STB comprende un módulo 31 cliente CDS que está adaptado para localizar el contenido sobre el módulo 41 servidor de CDS del servidor 4. Una vez que el contenido ha sido seleccionado en el servidor HN, una corriente 9 de HN después se suministra al STB de HN sobre la red casera. La corriente de HN es enviada en modo de unidifusión con el protocolo de transferencia de hipertexto (HTTP) de acuerdo con IETF RFC 2616. También se puede enviar utilizando RTP y se puede controlar por una sesión de protocolo (RTSP) de transmisión continua en tiempo real de acuerdo con IETF RFC 2326. Esta se dirige únicamente a HN STB.

De acuerdo con el estándar DVB-IPTV, un cliente quien desea recibir contenido IPTV implementa un módulo cliente SD&S. El cliente después es un STB de IPTV.

Un STB de HN que no comprende un módulo SD&S no puede recibir directamente una corriente IPTV. No obstante, la corriente IPTV puede ser accesible a través de una función de representante que se localiza en la compuerta. Se utiliza el protocolo de suministro RTP en la red casera y los módulos CDS y RTSP se integran en la compuerta casera. De esta manera, el descubrimiento se realiza gracias a CDS. La sesión RTSP es local a la red casera y la multidifusión debe ser convertida en una difusión para la STB de HN. No se realiza traducción de protocolo de transporte. En vez de utilizar RTP en casa, se puede utilizar HTTP; la traducción del protocolo de transporte es necesario en la compuerta, de RTP a HTTP. Esta traducción de protocolo de transporte se realiza además de la multidifusión a unidifusión cuando se realiza multidifusión a unidifusión .

En ambos casos, el HG necesita ser un dispositivo complejo. Debe procesar la totalidad de los metadatos SD&S, convertirlos en metadatos CDS y almacenar los metadatos resultantes en su memoria interna. Debe manejar sesiones RTSP de manera que un servidor RTSP complete la implementación. Debe convertir la corriente RTP la cual está en el modo de introducción en paquetes HTTP los cuales están en modo de extracción.

DESCRIPCION BREVE DE LA INVENCION La presente invención intenta corregir por lo menos parte de los inconvenientes relacionados con la compuerta completa en la técnica anterior al proporcionar un dispositivo que está dedicado a realizar las funciones de representante IPTV.

La presente invención se relaciona con un dispositivo de red que comprende un conector para conectarse a una red local, un servidor para proporcionar a un descodificador que se localiza en la red local información sobre un contenido disponible y una dirección en la red local en donde el contenido está disponible desde y un módulo de representación IPTV para concordar el contenido con un contenido IPTV que sea accesible desde el servidor IPTV localizado en una segunda red, la segunda red se conecta con la primera red con un dispositivo de compuerta, en donde el descodificador solicita el contenido en la dirección y recibe un contenido de IPTV del servidor IPTV.

El dispositivo de red permite que un descodificador localizado en una red local tal como STB de HN reciba contenido IPTV de un servidor IPTV localizado fuera de la red local. El STB no es capaz de recibir directamente el contenido de IPTV del servidor IPTV. El dispositivo de red actúa como un representante entre el STB y el servidor. El STB incluso no tiene conocimiento de que el contenido es contenido de IPTV. Selecciona contenido disponible en el dispositivo de red. El contenido se presenta como un contenido multimedia, tal como un contenido de audio-video. En vez de proporcionar el contenido directamente al STB, el dispositivo de red activa la conexión al servidor IPTV, de manera que el STB recibe el contenido del servidor IPTV.

De acuerdo con una modalidad, si el contenido está disponible en el dispositivo de red, el representante IPTV, ante la recepción de una solicitud del descodificador para tener acceso al contenido, envía una solicitud para unirse a una sesión de IPTV con un servidor IPTV localizado en la segunda red, el contenido de IPTV después se distribuye al descodificador .

Si el contenido está disponible en el dispositivo de red, ese dispositivo envia directamente una solicitud al servidor IPTV para unirse a una sesión de IPTV.

De acuerdo con una modalidad, si el contenido está disponible en un segundo dispositivo, el representante IPTV indica al segundo dispositivo la sesión IPTV correspondiente al contenido.

Si el contenido está disponible en otro dispositivo, el representante IPTV vuelve disponible a ese dispositivo información respecto a la correspondencia entre el contenido y la corriente IPTV.

De acuerdo con una modalidad, el dispositivo de red comprende un servidor RTSP para habilitar el descodificador para que tenga acceso al contenido.

El STB establece una sesión de RTSP con el servidor RTSP del dispositivo de red para volver disponible la información.

De acuerdo con una modalidad, el dispositivo de red comprende un servidor HTTP para habilitar al descodificador para que tenga acceso al contenido.

· El STB establece una sesión con el servidor HTTP del dispositivo de red para volver disponible la información.

De acuerdo con una modalidad, el dispositivo de red comprende un servidor CDS para proporcionar información acerca del contenido disponible para el descodificador .

Otro objetivo de la invención es un método de un dispositivo de red para establecer una comunicación IPTV entre el descodificador que se localiza en una red local y un servidor IPTV que se localiza en una segunda red, la red local comprende una compuerta adaptada para conectar la red local a una segunda red, que comprende la etapa de proporcionar al descodificador información acerca del contenido disponible y una dirección en la red local en donde el contenido está disponible, si el contenido está disponible en el dispositivo de red, ante la recepción de una solicitud del descodificador para recibir el contenido envía una solicitud para unirse a una sesión IPTV con un servidor IPTV que se localiza en la segunda red, el contenido de IPTV se distribuye después al descodificador y si el contenido está disponible en un segundo dispositivo localizado en la red local, indica al segundo dispositivo la sesión de IPTV que corresponde al contenido, el contenido de IPTV después es distribuido al descodificador .

De acuerdo con una modalidad, el dispositivo de red indica al segundo dispositivo la sesión de IPTV que corresponde al contenido después de la recepción de una solicitud de ese segundo dispositivo.

Otro objetivo de la invención es un producto de programa de computadora que comprende instrucciones de código de programa para ejecutar las etapas del método de acuerdo con la invención, cuando el programa es ejecutado en una computadora. Mediante el término "producto de programa de computadora" se quiere indicar un soporte de programa de computadora el cual puede consistir no solo en un espacio de almacenamiento que contiene el programa tal como un disquete o un cásete sino también una señal tal como una señal eléctrica u óptica.

Algunos aspectos de alcance conmensurado con las modalidades descritas se establecen en lo siguiente. Debe entenderse que estos aspectos se presentan únicamente para proporcionar al lector con un resumen breve de algunas formas que puede tomar la invención y que estos efectos no se pretende que limiten el alcance de la invención. En realidad, la invención puede abarcar una diversidad de aspectos que pueden no establecerse en lo siguiente.

DESCRIPCION BREVE DE LAS FIGURAS La invención se comprenderá mejor y se ilustrará por medio de la siguiente modalidad y ejemplos de ejecución, que de ninguna manera son limitantes, con referencia a las figuras anexas, las cuales: La figura 1 ilustra una red casera de acuerdo con la técnica anterior; la figura 2 ilustra una red casera de acuerdo con · una primera modalidad; la figura 3 es un diagrama de bloques de un dispositivo sintonizador de acuerdo con las modalidades; la figura 4 es un diagrama de flujo de los mensajes utilizados para establecer una sesión IPTV entre un STB de HN y un servidor IPTV de acuerdo con una primera modalidad; la figura 5 es un diagrama de flujo de ' los mensajes utilizados para establecer una sesión IPTV entre un STB de HN y un servidor IPTV de acuerdo con una variante de la primera modalidad; la figura 6 ilustra una red casera de acuerdo con una segunda modalidad; la figura 7 es un diagrama de flujo de los mensajes utilizados para establecer una sesión de IPTV entre un STB de HN y un servidor IPTV, de acuerdo con una segunda modalidad; la figura 8 ilustra una red casera de acuerdo con una tercera modalidad; la figura 9 es un diagrama de flujo de los mensajes utilizados para establecer una sesión de IPTV entre un STB de HN y un servidor IPTV de acuerdo con una tercera modalidad; la figura 10 ilustra una red casera de acuerdo con una cuarta modalidad; y la figura 11 es un diagrama de flujo de los mensajes utilizados para establecer una sesión de IPTV entre un STB de HN y un servidor de IPTV, de acuerdo con una cuarta modalidad.

En las figuras, los bloques representados son entidades puramente funcionales y no necesariamente corresponden a entidades físicamente separadas. Específicamente, se pueden desarrollar en forma de hardware o elementos físicos o software o programa, o se pueden implementar o en uno o varios circuitos integrados.

DESCRIPCION DETALLADA DE LAS MODALIDADES PREFERIDAS El sistema de acuerdo con una primera modalidad de la invención se muestra en la figura 2. Un dispositivo de compuerta casero que comprende un módulo 1.1, de representante de IPTV, un módulo 1.2 de servidor RTSP y un módulo 1.3, de suministro de multidifusión a unidifusión, indicado como MC/UC. Un módulo 1.1 de representante IPTV se adapta para realizar las funciones de representante IPTV como se describe en lo siguiente. En particular, recibe solicitudes del servidor 1.2 RTSP para obtener la dirección de un canal. Ante la recepción de esta solicitud, envía una solicitud a un sintonizador como se describe en lo siguiente para obtener la dirección. El servidor RTSP de compuerta cumple con IETF RFC 2326, con un módulo para comunicarse con el representante IPTV, Además del sistema de la técnica anterior, el sistema comprende un dispositivo, un sintonizador 10 de banda ancha, también indicado como BBT o sintonizador en lo siguiente. El sintonizador comprende un módulo 101 de representante IPTV. Esta adaptado para realizar las funciones de representante de IPTV como se describe en lo siguiente. En particular, como se ilustra en la figura 4, administra la correspondencia entre el identificador de canal y la dirección de multidifusión . Ante la solicitud del representante de IPTV de compuerta para un canal, proporciona la dirección de multidifusión que corresponde al canal. La dirección de multidifusión ha sido recibida previamente por el cliente 105 de SD&S del sintonizador desde el servidor 61 de SD&S; después de la recepción por el cliente SD&S, la dirección de multidifusión se almacena en una base de datos y es accesible por el representante IPTV.

De acuerdo con la primera modalidad, el sintonizador comprende un módulo 102 de servidor CDS. Está adaptado para realizar las funciones de CDS con cualquier HN-STB de la red casera que comprenda un módulo cliente CDS.

De manera más general, el módulo representante de IPTV de sintonizador puede estar constituido en el módulo CDS.

La conversión de multidifusión a unidifusión se realiza en la capa 3, en la capa IP. La dirección IP de multidifusión se convierte en la dirección IP de unidifusión del dispositivo STB de HN de destino sin cambiar ninguna otra cosa en el paquete. El resto de los apilados de la capa de protocolo anterior tales como UDP y RTP, permanecen sin cambio a menos que se establezca en otro sentido explícitamente. El módulo 1.2 de servidor RTSP cumple con IETF RFC 2326.

La figura 4 muestra un diagrama de flujo de los mensajes utilizados para establecer una sesión IPTV entre un STB de HN y un servidor IPTV. El STB de HN navega en el sintonizador, utilizando los CDS, para verificar los servicios disponibles, etapa SI. Obtiene información del sintonizador de banda ancha de que una corriente IPV está disponible en el canal, el canal premium, etapa S2.

El STB de HN envía un mensaje RTSP SETUP (establecer RTSP) al servidor RTSP en la compuerta, etapa S3. El mensaje RTSP SETUP indica como debe ser transportada la corriente. El mensaje comprende información sobre la corriente y el canal. No tiene información sobre la corriente IPTV de red de acceso. El representante IPTV de compuerta después solicita esta información del representante IPTV de sintonizador, etapa S4, y el representante IPTV de sintonizador responde con las direcciones de multidifusión para esta sesión RTSP, etapa S5. La compuerta después puede realizar la conexión de multidifusión en el lado de red de acceso, y configurar su tabla de enrutado para dirigir los paquetes IPTV recibidos al STB de HN en el modo de unidifusion. En respuesta al RTSP SETUP, la compuerta envía un mensaje RTSP OK (RTSP CORRECTO) al STB de HN, etapa S6. El STB de HN después envía un mensaje RTSP PLAY (RTSP REPRODUCIR) al servidor RTSP, etapa S7, para provocar que la corriente sea reproducida. Esto hace que la compuerta se una a un grupo de multidifusión, etapa S8. Después, el módulo MC/UC recibe la corriente de multidifusión y convierte la corriente en una corriente de unidifusion que es enviada al STB de HN. Una corriente única, la corriente de unidifusion, se envía sobre la red casera. La corriente después se administra y se controla sobre la red casera. Por supuesto, la corriente puede no convertirse en unidifusion y se puede enviar como corriente de multidifusión sobre la red casera.

De acuerdo con la modalidad, la comunicación entre el representante IPTV de compuerta y el sintonizador se realiza utilizando mecanismos UPnP. El representante IPTV de compuerta no tiene conocimiento a priori de cuales CDS han sido proporcionadas por esta URL de RTSP o el STB de HN. De esta manera envía la solicitud a todos los CDS localizados en el HN, únicamente aquellos con conocimiento de esta URL de RTSP responderán al CDS. También es posible exponer los CDS que se relacionen con un servicio IPTV externo como unos CDS especiales con una etiqueta XML especial en su descripción de dispositivo (por ejemplo "IPTV CDS"). De esta manera, la compuerta únicamente dirige sus CDS para la solicitud. De acuerdo con una modalidad variante, también es posible incluir los identificadores de CDS en el URL de RTSP con el fin de que el representante IPTV de compuerta los recupere directamente. Por ejemplo, la siguiente URL comprende el identificador CDS 1234567890ABCDEF: rtsp: //192.168.0.12/CDS 1234567890ABCDEF/streams/PremiumChannel .mpg Los CDS del sintonizador realiza una acción de recuperación de los parámetros; Acción: GetConnectionParameters (obtención de parámetros de conexión) rgumento de ENTRADA: ConnectionString (cadena conexión (la URL de RTSP) . argumentos de SALIDA: Connectionlnfo (información de conexión) Este es un mensaje basado en XML, como se indica en lo siguiente: Solicitud: <?xml vers¡on="1.0" encoding <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas. mlsoap.org/soap/encoding "> <s:Body> <u:GetConnectionParameters xmlns:u="urn:schemas-upnp-org:service:ContentDirectoryService:1"> <ConnectionString> rtsp://192.168.0.12/streams/PremiumChannel.mpg </ConnectionString> </u:GetConnectionParameters> </s:Body> </s:Envelope> Respuesta <?xml version="1.0" encoding="utf-8"?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encodingr> <s:Body> <u:GetConnectionParametersResponse xmlns:u="urn:schemas-upnp-org:service:ContentDirectoryService:1 "> <Connectionlnfo> Multicast udp 224.12.34.56 </Connectionlnfo> </u: GetConnectionParametersResponse> </s:Body> </s:Envelope> De acuerdo con una variante a la primera modalidad, el STB de HN obtiene directamente, en la etapa S2, la información de dirección de multidifusión de una manera que está fuera del alcance de la invención. La información para que la compuerta se conecte a la corriente IPTV de difusión múltiple se incluye en la URL de RTSP proporcionada por el CDS. Como se india en la figura 5, el URL de RTSP comprende una parte "RTP" que indica que la corriente se basa en RTP y "224.12.34.56" que indica la dirección de multidifusión para encontrarla. El número de puerto también se puede agregar.

Posteriormente no hay comunicación necesaria entre la compuerta y el sintonizador; en esta modalidad, las etapas S4 y S5 no son necesarias. Ante la recepción de RTSP PLAY (RTSP REPRODUCIR) la compuerta se una al grupo de multidifusión.

De acuerdo con una segunda modalidad, los módulos tanto del servidor RTSP como del servidor CDS se localizan ambos dentro del dispositivo sintonizador, como se indica en la figura 6. La función de la compuerta casera después se centra en el enrutado de paquetes. Todas las tareas de descubrimiento y administración se realizan dentro del dispositivo de sintonizador. Nuevamente, únicamente una corriente, la corriente de unidifusión, es enviada sobre la red casera. La corriente también puede no ser convertida en unidifusión y se puede enviar como una corriente de multidifusión sobre la red casera.

Como se ilustra en la figura 7, la comunicación entre el sintonizador y la compuerta se limita a la unión del mensaje de multidifusión, etapa S16. El sintonizador indica la dirección de multidifusión a la cual conectarse y la dirección IP de destino del STB de HN. Con estas dos piezas de información, el HG puede realizar la conexión IGPM, etapa S17 y la conversión de multidifusión a unidifusión hacia el destino correcto dentro del HN.

De acuerdo con la modalidad, la comunicación entre el sintonizador y el HG se realiza utilizando mecanismos UPnP. El HG mantiene un módulo UPnP de representante IPTV especifico el cual tiene una acción específica para ser solicitada por el sintonizador para proporcionar dicha información: Action: SetConnectionParameters (Establecer parámetros de conexión) Argumentos de ENTRADA: JoinExternal (unión externa (la dirección de multidifusión a cual unirse) y SendToInternal (enviar a interno (las direcciones IP a las cuales enviar la corriente de unidifusión) .

Este es un mensaje basado XML, como se indica a continuación : Solicitud: <?xml vers¡on="1.0" encoding="utf-8"?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <s:Body> <u:SetConnectionParameters xmlns:u="urn:schemas-upnp-org:service:lptvproxy:1"> <JoinExternal>224.12.34.56</JoinExternal> <SendTolnternal>192.168.0.1 </SendTolnternal> </u:SetConnectionParameters > </s:Body> </s:Envelope> Respuesta <?xml version="1.0" encoding="utf-8"?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encodingr> <s:Body> <u:SetConnectionParametersResponse xmlns:u="urn:schemas-upnp-org:service:lptvProxy:1"> </u: SetConnectionParametersResponse> </s:Body> </s:Envelope> De acuerdo con una tercera modalidad, la corriente IPTV se convierte de RTP a HTTP y por supuesto para de multidifusión a unidifusión, como se indica en la figura 8. Esta conversión se realiza en la compuerta casera. La compuerta casera comprende un módulo 1.1 de representante IPTV, un módulo 1.3 MC/UC, un módulo 1.21 HTTP y un módulo 1.22 de conversión RTP/HTTP.

Como se ilustra en la figura 9, el servidor HTTP únicamente recibe una GET de HTTP del STB de HN. Este mensaje no mantiene información acerca de la corriente IPTV de red de acceso. El servidor HTTP después solicita esta información desde el CDS y el CDS responde con la dirección de multidifusion para esta sesión de HTTP. El HG después puede enviar la conexión de multidifusion en el lado de red de acceso y configurar su tabla de enrutado y traducción de protocolo de transporte para enviar los paquetes de IPTV multidifusión-RTP recibidos a STB de HN en el modo unidifusión-HTTP.

De acuerdo con una variante a la tercera modalidad, el STB de HN obtiene directamente en la etapa S2, las direcciones de multidifusion. La información para la compuerta para conectar la corriente IPTV de multidifusion se incluye en HTTP GET. En particular, comprende un parámetro "rtp" indicando que la corriente se basa en RTP, y "224.12.34.56" indica la dirección de multidifusion a la cual encontrar. También se puede agregar el puerto.

De acuerdo con una cuarta modalidad que se ilustra en la figura 10, un servidor HTTP se localiza dentro del dispositivo de sintonizador. La función de la compuerta casera después se centra en el enrutado de paquetes. Todas las tareas de descubrimiento y administración se realizan dentro del dispositivo sintonizador, como se ilustra en la figura 11. La corriente RTP se envia al dispositivo sintonizador de banda ancha el cual realiza la traducción de RTP a HTTP. Después envia la corriente HTTP al STB de HN.

En una variante a la cuarta modalidad, el HG no realiza conversión alguna de multidifusión a unidifusión. La corriente de multidifusión se dirige al sintonizador. La compuerta comprende un snooper de IGMP que espía los mensajes de IGMP desde el sintonizador al servidor IPTV, para saber a donde dirigir la corriente de multidifusión. Después, el sintonizador de banda ancha realiza la traducción RTP a HTTP y envia la corriente HTTP de unidifusión al CTB de HN.

De manera más general, el dispositivo 10 de sintonizador está representado funcionalmente en la figura 3. Comprende un módulo 10.2 de descubrimiento para proporcionar servicio y servicios de descubrimiento de contenido. De acuerdo con la primera modalidad, el medio de descubrimiento se proporciona con el módulo CDS.

Como se indica en las modalidades, el dispositivo sintonizador puede comprender un módulo 10.1 administrador para proporcionar administración de sesión en una red casera. De acuerdo con las modalidades, la administración de sesión se proporciona con RTSP o HTTP.

También puede comprender un módulo 10.3 de suministro para suministrar contenido, y en particular recibir contenido en modo de multidifusión desde el servidor IPTV y distribuir el contenido en modo unidifusión al cliente.

También comprende un procesador 10.4 y un módulo 10.5 de comunicación para interconexión con la red casera. En particular, el módulo 10.5 de comunicación es una interconexión Ethernet o una interconexión cableada para comunicarse respectivamente con una red Ethernet o con una red Wi-Fi. También puede ser una combinación de medios de comunicación de baja velocidad y alta velocidad.

El sintonizador puede estar interconstruido en cualquier dispositivo de la red casera, en particular en un STB. También puede ser un dispositivo autosustentable .

Una red casera no necesariamente es una red homogénea. Puede contener partes de alta velocidad tal como Ethernet rápida o Ethernet Gigabit, asi como partes de baja velocidad tal como Wi-Fi o Powerline. El sintonizador se puede proporcionar como un conjunto de dos cajas; un dispositivo que obtenga el CDS y las funciones de traducción de protocolo, pero no necesariamente las funciones de presentación y un dispositivo que proporciona las funciones de presentación, el STB de HN. La caja sintonizadora después puede conectarse a la compuerta casera en una interconexión de alta velocidad y el dispositivo de presentación se conecta en una interconexión de baja velocidad.

Las referencias descritas en la descripción, las reivindicaciones y los dibujos se proporcionan independientemente o en cualquier combinación apropiada. Cuando sea apropiada, las características se pueden implementar en hardware, software o una combinación de ambos .

Con referencia a la presente, los términos "una modalidad" o "la modalidad" significa que un rasgo, estructura o característica particular descrito en relación con la modalidad se puede incluir en por lo menos una implementación de la invención. La aparición de la frase "en una modalidad" en diversos lugares en especificación no necesariamente se refiere en todo momento a la misma modalidad ni son modalidades separadas alternativas que de manera necesaria sean mutuamente excluyentes de otras modalidades .

Los números de referencia que aparecen en la reivindicación son únicamente a modo de ilustración y no tendrán efecto limitante en el alcance de las reivindicaciones .

Claims (11)

REIVINDICACIONES

1. Dispositivo de red que comprende: un conector para conectarse a una red local, la red local comprende un dispositivo de compuerta adaptado para conectar la red local a una segunda red, un servidor para proporcionar, a un descodificador localizado en la red local, información sobre un contenido multimedia disponible y una dirección en la red local desde donde está disponible el contenido multimedia; y un módulo de representante IPTV que comprende un medio, ante la recepción de una solicitud del descodificador para recibir el contenido multimedia, información de la compuerta para unirse a una sesión de IPTV con un servidor IPTV que se localiza en la segunda red para recibir un contenido de IPTV que corresponde al contenido multimedia de manera que el dispositivo de compuerta envía el contenido IPTV recibido desde el servidor IPTV al descodificado .

2. Dispositivo como se describe en la reivindicación 2, en donde el módulo representante de IPTV comprende un medio para indicar a un segundo dispositivo localizado en la segunda red la sesión IPTV que corresponde al contenido multimedia de manera que el segundo dispositivo se une a una sesión IPTV.

3. Dispositivo como se describe en la reivindicación 1, en donde la solicitud para unirse es enviada al dispositivo de compuerta de manera que el dispositivo de compuerta se une a la sesión IPTV.

4. Dispositivo como se describe en cualquiera de las reivindicaciones precedentes, caracterizado porque comprende un servidor RTSP para habilitar para que el descodificador tenga acceso al contenido multimedia.

5. Dispositivo como se describe en cualquiera de las reivindicaciones precedentes, caracterizado porque comprende un servidor HTTP para habilitar al descodificador para que tenga acceso al contenido multimedia.

6. Dispositivo como se describe en cualquiera de las reivindicaciones precedentes, caracterizado porque comprende un servidor CDS para proporcionar información acerca del contenido multimedia disponible al descodificador .

7. Método en un dispositivo de red localizado en una red local para establecer una comunicación IPTV entre un descodificador que se localiza en la red local y un servidor de IPTV que se localiza en una segunda red, la red local comprende un dispositivo de compuerta adaptado para conectar la red local a una segunda red, el método comprende, en el dispositivo de red, las etapas de: proporcionar al descodificador información sobre un contenido multimedia disponible y una dirección en la red local en donde esté disponible el contenido multimedia, si el contenido multimedia está disponible en el dispositivo de red, ante la recepción de una solicitud desde el descodificador para recibir el contenido multimedia, informar a la compuerta para unirse a una sesión IPTV con un servidor de IPTV que se localice en la sequnda red para recibir un contenido de IPTV que corresponda al contenido multimedia, de manera que el dispositivo de compuerta envié el contenido IPTV recibido desde el servidor IPTV al descodificador .

8. Método como se describe en la reivindicación precedente, caracterizado porque si el contenido multimedia está disponible en el dispositivo de compuerta, indicar al dispositivo de compuerta la sesión de IPTV que corresponde al contenido multimedia.

9. Método como se describe en la reivindicación precedente, caracterizado porque indica al dispositivo de compuerta la sesión IPTV que corresponde al contenido multimedia después de recepción de una solicitud desde el dispositivo de compuerta.

10. Método como se describe en la reivindicación 7, en donde la solicitud para unirse es enviada al dispositivo de compuerta de manera que el dispositivo de compuerta se une a la sesión de IPTV.

11. Producto de programa de computadora, caracterizado porque comprende instrucciones de código de programa para ejecutar las etapas del método de acuerdo con la reivindicación 7, cuando el programa se ejecuta en una computadora.