ES2429222B1

ES2429222B1 - Método y nodo de extremo para distribuir flujo continuo de contenido en tiempo real en una red de distribución de contenido

Info

Publication number: ES2429222B1
Application number: ES201130760A
Authority: ES
Inventors: Armando Antonio GARCIA MENDOZA; Xiaoyuan Yang; Parminder Chhabra; Arcadio PANDO CAO; Pablo Rodriguez Rodriguez
Original assignee: Telefonica SA
Current assignee: Telefonica SA
Priority date: 2011-05-12
Filing date: 2011-05-12
Publication date: 2014-06-05
Anticipated expiration: 2031-05-12
Also published as: ES2429222A1; AR086340A1; WO2012152817A1; US20140165118A1; CL2013003224A1; EP2708009A1; BR112013028992A2

Abstract

Método y nodo de extremo para distribuir flujo contínuo de contenido en tiempo real en una red de distribución de contenido.#El método comprende la gestión y entrega de un flujo continuo en tiempo real solicitado usando una arquitectura basada en P2P, en el que los iguales que intercambian contenido entre sí son nodos de extremo de una CDN. La entrega del flujo continuo en tiempo real solicitado a uno o más usuarios finales se realiza desde uno o más de dichos nodos de extremo. El flujo continuo en tiempo real solicitado se divide en segmentos que obtienen los nodos de extremo de servicio, preferiblemente, de nodos de extremo de entorno y/o del servidor original del flujo continuo en tiempo real usando un algoritmo de planificación y dependiendo de la disponibilidad de segmentos del mismo.#El nodo de extremo está diseñado para implementar el método de la invención.

Description

MÉTODO Y NODO DE EXTREMO PARA DISTRIBUIR FLUJO CONTINUO DE CONTENIDO EN TIEMPO REAL EN UNA RED DE DISTRIBUCIÓN DE CONTENIDO

Campo de la técnica

La presente invención se refiere, en general, en un primer aspecto, a un método para distribuir flujo continuo de contenido en tiempo real en una red de distribución de contenido (CON), y más particularmente a un método que comprende la gestión y entrega de un flujo continuo en tiempo real solicitado según una arquitectura basada en P2P (peer-to-peer, de igual a igual), en el que los iguales son nodos de extremo (también denominados servidores de contenido) de dicha CON.

Un segundo aspecto de la invención se refiere a un nodo de extremo para una CON diseñado para implementar el método del primer aspecto.

Estado de la técnica anterior

Los sistemas de igual a igual (P2P) han tenido éxito a la hora de distribuir archivos a un gran número de usuarios. Los sistemas P2P también se usan ampliamente para la distribución de contenido de vídeo incluyendo descargas de vídeo (en las que es necesario que los usuarios descarguen todo el archivo de vídeo antes de poder ver el vídeo) y transmisión en flujo continuo de medios en tiempo real (tal como Coolstreamíng). Recientemente se han diseñado nuevos sistemas [1, 1O, 11] para permitir una experiencia de vídeo bajo demanda (VoO; Vídeo on Demand) usando P2P. Sin embargo, tales servicios asumen de manera implícita que los usuarios visualizan el contenido desde el inicio hasta el final a la tasa de reproducción. El soporte de la funcionalidad de OVO (pausa/reanudar, saltar hacia delante o hacia atrás a través del vídeo) es un requisito natural para la mayor parte de los sistemas de VoO. Aunque muchos sistemas centralizados populares (denominados así porque ofrecen un flujo continuo dedicado entre el servidor de contenido de un propietario de contenido y el usuario final solicitante) como Youtube [19], Netflix [20] y sistemas de cine en casa ofrecen funcionalidad de búsqueda, las funciones de OVO se ignoran en gran parte por muchos de los sistemas de VoO P2P.

El diseño de los sistemas de VoO basados en P2P con funcionalidad de OVO no es trivial debido a la falta de sincronización entre los usuarios finales que reduce la oportunidad para la compartición basada en P2P. A medida que los usuarios van saltando por un vídeo, disminuye su posibilidad de compartición y es necesario proporcionar contenido desde el servidor original que almacena la copia maestra del contenido para garantizar una buena experiencia de visualización para el usuario. Un buen diseño requiere un retardo reducido al realizar las operaciones de OVO y una tasa de reproducción mantenida al tiempo que se minimiza la cantidad de datos proporcionados por el servidor original. Esto implica hallar los iguales adecuados, planificar el contenido para su intercambio en el momento adecuado, una tarea de diseño que no es trivial. Aunque es de difícil ejecución en un entorno de VoO, los objetivos del diseño son similares para una solución de transmisión en flujo continuo en tiempo real. La implementación de soluciones basadas en P2P es relativamente más fácil de implementar en un entorno de transmisión en flujo continuo en tiempo real sin una carga mantenida en el servidor original puesto que proporcionan iguales con numerosas oportunidades para compartir contenido. Sin embargo, una solución de este tipo aún proporciona desafíos considerables a la hora de encontrar los iguales adecuados para planificar el intercambio de datos entre los iguales.

Los primeros sistemas de entrega de vídeo basados en P2P se construyeron para transmisión en flujo continuo de vídeo en tiempo real e incluían superposiciones basadas en árboles tales como Slípstream, y superposiciones basadas en mallas, tales como Coolstreamíng y PPLíve. Los sistemas P2P de vídeo de próxima generación se diseñaron para soportar V o O, entre los que se incluyen BitOS [11 ], BASS [10], Redcarpet [1], Toast [14]. Por ejemplo, BiToS divide los bloques que faltan en dos conjuntos (prioridad baja y prioridad alta), y planifica peticiones de manera correspondiente desde iguales y el servidor. BASS amplía BitTorrent para proporcionar servicios de V o O, con una alta dependencia del servidor. En [1], los autores muestran los beneficios de codificación de red para simplificar el problema de planificación de segmentos y proporcionar servicios de VoO de alta calidad. En [6], los autores presentan una formulación analítica del impacto de diversas políticas de planificación para optimizar el rendimiento de VoO. En [3], los autores describen los desafíos a los que se enfrenta un sistema de VoO P2P comercial desplegado por PPLive y proponen algoritmos de planificación, replicación y descubrimiento de contenido para afrontar estos desafíos.

Recientemente, [12] [7] y [2] han analizado algunos de los problemas que pueden surgir a la hora de diseñar sistemas P2P que soportan una funcionalidad similar a OVO. En particular, [12] introdujo el concepto de anclajes para realizar una prebúsqueda de datos en puntos previamente definidos del vídeo y permitir saltos a tales puntos. En Bulletmedia [2], los autores propusieron un almacenamiento en caché proactivo más agresivo, que crea de manera proactiva múltiples copias de cada segmento en una superposición, reduciendo así la dependencia de la fuente. El objetivo es garantizar que todos los bloques se repliquen en la superposición, independientemente de cuándo el conjunto de iguales activos en la superposición requerirá que soporten una reproducción actual. En [7] proponen un protocolo gossíp a través de un anillo, en el que cada igual mantiene algunos vecinos próximos así como algunos vecinos remotos siguiendo un radio de ley exponencial, y muestran a través de simulaciones que pueden gestionar búsquedas aleatorias.

En [21] los autores determinan los intercambios fundamentales y las limitaciones sobre la carga del servidor original y la experiencia de usuario usando rastros de salto de usuario final en tiempo real obtenidos a partir de un despliegue de un sistema real para validar sus opciones de diseño. Mediante el uso de patrones de salto de usuario final realistas y una implementación de trabajo, muestran que es posible conseguir una experiencia de usuario muy buena sin sobrecargar de manera agresiva el sistema.

Muchas CON usan o bien la solución de servidor de medios de transmisión en flujo continuo de Microsoft [17] o bien el servidor de medios flash de Adobe [18] para distribuir flujos continuos de contenido en tiempo real. Los servidores en ambos casos proporcionan un flujo continuo a cada uno de los usuarios finales solicitantes. También aprovechan la transmisión en flujo continuo dinámica y multidifusión IP.

Tanto Octoshape [22] como Rawflow [16] son sistemas basados en P2P que se usan para distribuir contenido a usuarios finales solicitantes. Los usuarios finales que usan Octoshape descargan un complemento (plug-ín) basado en P2P que se utiliza a continuación por los anfitriones de usuario final para distribuir contenido.

Para Rawflow [16], los usuarios finales conocidos como clientes de distribución de contenido inteligente (ICD; lntellígent Content Dístríbutíon) contactan con el servidor de ICD y comienzan a recibir el flujo continuo desde el mismo. El reproductor en el usuario final reproduce el flujo continuo a medida que lo recibe el cliente de ICD. Los clientes de ICD se unen para formar una red. Un cliente de ICD también acepta conexiones desde otros clientes en la red a los que puede retransmitir parte de o todo el flujo continuo que recibe según se solicita. El cliente de ICD monitoriza la calidad del flujo continuo que recibe y, con cualquier reducción de calidad o pérdida de conexión, busca de nuevo en la red para detectar recursos disponibles mientras continúa dando

servicio al reproductor de medios desde su memoria intermedia. La memoria

intermedia evita la interrupción de la reproducción y garantiza que la experiencia del

usuario final no se vea afectada.

Problemas con las soluciones existentes:

5: La mayor parte de operadores CON usan o bien el servidor de medios de

transmisión en flujo continuo de Microsoft o bien el servidor de medios flash de Adobe

para distribuir contenido. El proveedor de servicios CON también tiene poco control

sobre la forma en que estas soluciones utilizan la red y tiene pocas oportunidades para

optimizar la red para la entrega de contenido, más aún en el caso de flujos continuos

1O: en tiempo real.

Varios sistemas basados en P2P presentados anteriormente se centran o bien

en cómo realizar una prebúsqueda de contenido por todo el enjambre o bien en cómo

los iguales deben estar relacionados entre sí, y usan simulaciones para evaluar

patrones de saltos aleatorios simples, que podrían afectar al diseño del sistema. La

15: prebúsqueda agresiva podría dar como resultado un desperdicio de los recursos del

servidor original y de los iguales si no se producen saltos de usuario final (más aún

para un flujo continuo en tiempo real), y correlacionar iguales es sólo una parte del

espacio de diseño y requiere una combinación cuidadosa con otras opciones de

diseño tales como políticas de planificación inteligente o estrategias de control de

20: admisión eficaces. Además, el uso de los sistemas anteriores en una CON para

distribuir contenido en tiempo real presenta desafíos excepcionales, puesto que los

usuarios esperan vídeos de alta calidad con experiencia de usuario de tipo TV incluso

cuando se realizan operaciones de OVO.

La mayor parte de las soluciones basadas en P2P se basan en usuarios finales

25: que se comportan como iguales para participar en la distribución de contenido. Esto

requiere que los nodos de extremo o bien descarguen una aplicación o bien

descarguen un complemento para el explorador para formar parte de la red de

distribución de contenido. Las soluciones P2P puras usan por tanto recursos

informáticos del usuario final, una infraestructura poco fiable por lo que respecta a una

30: distribución de contenido fiable.

Mediante el uso de recursos informáticos en los usuarios finales, los

distribuidores de contenido desplazan su parte del coste de ancho de banda a los

usuarios finales, una práctica que no proporciona un ancho de banda fiable (o

suficiente) para un intercambio de contenido de alta calidad. Además, como parte de la

aceptación del usuario final para usar un software de este tipo, dicho software también se reserva el derecho de ampliar el alcance de lo que dicho software puede realizar en un sistema de usuario final [22] dando como resultado una acción impredecible en el usuario final (tal como deshabilitar el software). Dado lo imprevisible de tales sistemas para distribuir contenido en tiempo real, ello implica que no pueden atraer a suficientes usuarios para conseguir una masa crítica para formar parte de una infraestructura fiable para la transmisión en flujo continuo en tiempo real.

Descripción de la invención

Es necesario proporcionar una alternativa al estado de la técnica existente que cubra las lagunas encontradas en la misma, en particular las encontradas en los diseños CON existentes que soportan transmisión en flujo continuo en tiempo real que sobrecargan el servidor original que se carga con la distribución de un flujo continuo en tiempo real de este tipo.

Para ello, la presente invención se refiere, en un primer aspecto, a un método para distribuir flujo continuo de contenido en tiempo real en una red de distribución de contenido, que comprende proporcionar, una entidad de dicha red de distribución de contenido, o CON, un flujo continuo en tiempo real solicitado a al menos un usuario final, en el que el método se guía por una arquitectura basada en P2P.

Según el método de la invención, la gestión y entrega de dicho flujo continuo en tiempo real solicitado se realiza usando una arquitectura basada en P2P, en el que los iguales son nodos de extremo de dicha CON que intercambian contenido entre sí, en el que la entrega de dicho flujo continuo en tiempo real solicitado a dichos uno o más usuarios finales se realiza desde al menos uno de dichos nodos de extremo.

En una realización preferida, el método comprende obtener, dicho nodo de extremo, dicho flujo continuo en tiempo real solicitado por fragmentos o segmentos en los que previamente se ha dividido, desde un servidor original y/o desde nodos de extremo de entorno, dependiendo de su disponibilidad.

Otras realizaciones del método del primer aspecto de la invención se describen según las reivindicaciones 2 a 22, y en una sección posterior relativa a la descripción detallada de varias realizaciones.

Un segundo aspecto de la invención se refiere a un nodo de extremo para una CON que comprende un módulo de flujo continuo en tiempo real que implementa un planificador que incluye un módulo predictor del punto de reproducción en tiempo real, un módulo gestor de descarga P2P y un módulo servidor de flujo continuo en tiempo real, para distribuir flujo continuo de contenido en tiempo real realizando las acciones del método del primer aspecto de la invención según la realización descrita en la reivindicación 13 adjunta.

Breve descripción de los dibujos

Las ventajas y características anteriores, y otras, se entenderán de manera más completa a partir de la siguiente descripción detallada de realizaciones, con referencia a los dibujos adjuntos, que deben considerarse de manera ilustrativa y no limitativa, en los que:

la figura 1 es un diagrama secuencial para implementar transmisión en flujo continuo en una CON del proveedor de servicios según el método del primer aspecto de la invención; y

la figura 2 muestra el módulo de transmisión en flujo continuo en tiempo real del nodo de extremo del segundo aspecto de la invención, compuesto por tres submódulos.

Descripción detallada de varias realizaciones La terminología y definiciones que pueden ser útiles para entender las diferentes realizaciones de la presente invención son las siguientes:

-: PoP: Un punto de presencia es una demarcación artificial o punto de interfaz entre dos entidades de comunicación. Es un punto de acceso a Internet que aloja servidores, conmutadores, encaminadores y agregadores de llamadas. Los ISP (Internet Servíce Províder; proveedor de servicios de Internet) normalmente tienen múltiples PoP.

-: Red de distribución de contenido (CON): Esto se refiere a un sistema de nodos (u ordenadores) que contienen copias de contenido de cliente que está almacenado y situado en diversos puntos en una red (o Internet pública). Cuando se replica contenido en diversos puntos en la red, el ancho de banda se utiliza mejor a lo largo de la red y los usuarios tienen tiempos de acceso más rápidos al contenido. De este modo, el servidor original que contiene la copia original del contenido no experimenta atascos.

-URL: En términos sencillos, el Uníform Resource Locator (URL, localizador uniforme de recursos) es la dirección de una página web en la world-wíde web. No hay

dos URL idénticos. Si son idénticos, apuntan al mismo recurso.

-: Contenedor: Un contenedor es un compartimento lógico para un cliente que contiene el contenido del cliente CON. Un contenedor o bien establece un enlace entre el URL del servidor original y el URL de la CON o bien puede contener el propio contenido (que se carga en el contenedor en el punto de entrada). Un nodo de extremo replicará archivos desde el servidor original a archivos en el contenedor. Cada archivo en un contenedor puede correlacionarse exactamente con un archivo en el servidor original. Un contenedor tiene varios atributos asociados con él -el tiempo desde y el tiempo hasta que el contenido es válido, geobloqueo de contenido, etc. También se utilizan mecanismos para garantizar que se transmitan automáticamente nuevas versiones del contenido en el servidor original al contenedor en los nodos de extremo y se eliminen versiones antiguas.

-: Un cliente puede tener tantos contenedores como desee. Un contenedor es realmente un directorio que contiene archivos de contenido. Un contenedor puede contener subdirectorios y archivos de contenido dentro de cada uno de estos subdirectorios.

-: Geolocalización: Es la identificación de ubicaciones geográficas reales de un dispositivo conectado a Internet. El dispositivo puede ser un ordenador, dispositivo móvil o un aparato que permita la conexión a Internet para un usuario final. Los datos de geolocalización de la dirección IP (Internet Protocol; protocolo de Internet) pueden incluir información tal como país, región, ciudad, código postal, latitud/longitud de un usuario.

-: Unidad de negocio (OB; Operatíng Business): Un OB es un área geográfica arbitraria en la que está instalada la CON del proveedor de servicios. Un OB puede operar en más de una región. Una región es un área geográfica arbitraria y puede representar un país, o parte de un país o incluso un conjunto de países. Un OB puede estar compuesto por más de una región. Un OB puede estar compuesto por uno o más ISP. Un OBtiene exactamente una instancia de servidor de topología.

-: ID de partición: Es una correlación global de prefijos de dirección IP con números enteros. Se trata de una correlación uno a uno. Por tanto, no hay dos OB con el mismo PIDen su dominio.

A continuación se describe cada componente de los subsistemas del proveedor de servicios CON. La infraestructura consiste en servidores originales, rastreadores, nodos de extremo y punto de publicación.

-: Punto de publicación: Cualquier cliente CON puede interaccionar con la

infraestructura del proveedor de servicios CON únicamente a través del punto de publicación (también denominado a veces punto de entrada para mayor simplicidad). El punto de publicación ejecuta una interfaz de servicios web con usuarios de cuentas registradas para crear/borrar y actualizar contenedores.

Un cliente CON tiene dos opciones para cargar contenido. El cliente puede o bien cargar archivos en el contenedor o bien dar los URL de los archivos de contenido que residen en el sitio web del cliente CON. Una vez que la infraestructura CON descarga el contenido, los archivos se mueven a otro directorio para su postprocesamiento. Las etapas de postprocesamiento implican comprobar la consistencia de los archivos y si hay algún error. Sólo entonces se mueve el archivo descargado al servidor original. El servidor original contiene la copia maestra de los datos.

Para contenido en tiempo real, el cliente CON sólo proporciona a la CON un URL del flujo continuo en tiempo real.

-: Nodo de extremo: Un nodo de extremo es la entidad que gestiona la comunicación entre usuarios finales y la infraestructura CON. Esencialmente es un servidor HTTP personalizado.

-: Archivo hdr/hdx: En transmisión en flujo continuo en tiempo real, cuando se divide contenido (de cualquier formato), se crean dos tipos de archivos, los archivos hdr y hdx. Un archivo hdr es en realidad un archivo de cabecera que contiene información de cabecera sobre los medios, resolución, tasa de transmisión de bits, etc. y el archivo hdx es una memoria intermedia circular de URL de segmentos del flujo continuo en tiempo real original que residen en el divisor en tiempo real.

-: Rastreador: El rastreador es la entidad clave que permite la inteligencia y coordinación de la infraestructura del proveedor de servicios CON. Para ello, un rastreador mantiene (1) información detallada acerca del contenido en cada nodo de extremo y (2) recopila estadísticas de uso de recursos periódicamente de cada nodo de extremo. Mantiene información tal como el número de bytes salientes, número de bytes entrantes, número de conexiones activas para cada contenedor, tamaño del contenido proporcionado, etc.

-Servidor original: Es el servidor en la infraestructura del proveedor de servicios CON que contiene la copia maestra de los datos. Cualquier nodo de extremo que no tenga una copia de los datos puede solicitarla del servidor original. El cliente CON no tiene acceso al servidor original. La infraestructura del proveedor de servicios CON mueve los datos desde el punto de publicación al servidor original tras realizar comprobaciones de seguridad en los datos descargados.

Para contenido en tiempo real, el divisor en tiempo real sirve como servidor original. Su memoria intermedia limita la cantidad de contenido en tiempo real almacenado en el divisor en tiempo real. Esto permite a un usuario final realizar operaciones de OVO en un flujo continuo en tiempo real durante una duración igual o no superior al tamaño de la memoria intermedia.

En esta sección se detalla el diseño de soporte de transmisión en flujo continuo en tiempo real en una CON del proveedor de servicios que se basa en una arquitectura basada en P2P. Los nodos de extremo en el mismo centro de datos que proporcionan contenido en tiempo real se consideran iguales en este diseño. Sin embargo, los usuarios finales que solicitan contenido no se consideran iguales para la finalidad de distribuir contenido.

Esta invención se basa en una arquitectura P2P que permite a los nodos de extremo intercambiar contenido entre sí en un centro de datos. Como los nodos de extremo en un centro de datos están bien aprovisionados, no sufren las mismas limitaciones informáticas y de ancho de banda a las que se enfrentan los sistemas basados en P2P tradicionales [16][22] que se basan en usuarios finales como iguales.

A continuación se proporciona una descripción detallada de cómo un cliente CON puede configurar la distribución de contenido en tiempo real y cómo se trata una señal en tiempo real una vez que entra en una CON del proveedor de servicios. También se detalla la arquitectura del módulo de transmisión en flujo continuo en tiempo real en un nodo de extremo en una CON del proveedor de servicios y cómo los nodos de extremo intercambian contenido entre sí cuando es posible, y también cómo los nodos de extremo dan servicio a un usuario final solicitante.

A continuación se describe en detalle el diseño y la arquitectura de transmisión en flujo continuo en tiempo real en una CON del proveedor de servicios para algunas realizaciones.

Una vez que un flujo continuo en tiempo real está dentro del ecosistema del proveedor de servicios CON, se segmenta y se crea una lista de reproducción de los segmentos. Este segmentador sirve como servidor original para el flujo continuo en tiempo real. La lista de reproducción se reenvía a los nodos de extremo que hayan solicitado el flujo continuo en tiempo real. Una vez que los nodos de extremo reciben la lista de reproducción, intercambian los segmentos de la lista de reproducción entre ellos cuando es posible y obtienen los segmentos del servidor original cuando es necesario.

En primer lugar se detalla la manera en la que un flujo continuo en tiempo real se asocia en primer lugar con un contenedor en tiempo real que constituye la base para la entrega de flujos continuos en tiempo real.

Crear un contenedor en tiempo real

En este caso, se crea un contenedor en tiempo real y se asocian metadatos con el mismo. El propietario de contenido crea el contenedor en tiempo real en el gestor CON. Cuando se crea un contenedor en tiempo real, también se especifica la dirección del divisor en tiempo real para el flujo continuo en tiempo real.

El contenedor en tiempo real soporta crear, recuperar, actualizar y borrar llamadas a API (Applícatíon Programmíng Interface; interfaz de programación de aplicaciones) en un contenedor. El contenedor en tiempo real también soporta una diversidad de parámetros que permite al propietario de contenido (el cliente CON) establecer una serie de propiedades de distribución de contenido en el contenedor (es decir, fecha de inicio, fecha de finalización, geobloqueo, lista blanca, lista negra, formato del flujo continuo en tiempo real emitido, etc.). Una llamada a estadísticas en el contenedor recupera información estadística (bytes proporcionados por el flujo continuo CON en tiempo real).

Los metadatos para el tamaño de un segmento se definen en el momento en que se crea un contenedor. Para una explicación más sencilla, se usa un tamaño de segmento de 5 s. Además, se define una lista de reproducción de 12 segmentos. Así, una instancia de una lista de reproducción con una duración de un minuto tiene URL de 12 segmentos. Cada 30 s, se envía una lista de reproducción a los nodos de extremo. Este valor se elige para no sobrecargar el servidor original del flujo continuo en tiempo real para actualizar peticiones. Estos valores para duración de segmento y tamaño de lista de reproducción se usan con motivos ilustrativos únicamente y no restringen el alcance de la invención.

Además, se usa una API de nivel de archivo para gestionar el flujo continuo en tiempo real. Se usa una llamada a API de inicio/detención en un contenedor en tiempo real para o bien iniciar o bien detener un flujo continuo. Una llamada a API de estatus en un contenedor en tiempo real recupera el estatus actual de un flujo continuo en tiempo real.

Arquitectura de alto nivel para obtener el flujo continuo en tiempo real

En este caso, se describe una arquitectura de alto nivel para proporcionar un flujo continuo en tiempo real a un usuario final solicitante. La figura 1 muestra el diagrama secuencial para proporcionar un flujo continuo en tiempo real de este tipo.

En general, tres elementos CON están implicados en la distribución de un flujo continuo en tiempo real; el gestor CON, el divisor en tiempo real y el nodo de extremo.

El propietario de contenido crea un contenedor (o contenedor) en tiempo real y asocia metadatos con el contenedor. Esto se realiza a través del servidor de publicación en la CON del proveedor de servicios. El servidor de publicación se conecta con el gestor CON.

Una vez creado un contenedor en tiempo real, el gestor CON emite un comando al divisor en tiempo real para iniciar el flujo continuo en tiempo real. El divisor en tiempo real a su vez obtiene el flujo continuo en tiempo real de la fuente de flujo continuo en tiempo real. Cuando el divisor en tiempo real se pone en marcha, también inicia un segmentador. El segmentador está diseñado para crear segmentos a partir de un flujo continuo en tiempo real.

Una vez que el divisor en tiempo real se ha puesto en marcha, lanza un segmentador. El divisor en tiempo real empieza a descargar el flujo continuo desde la fuente de flujo continuo en tiempo real. El segmentador obtiene el flujo continuo en tiempo real en el divisor en tiempo real y genera segmentos a partir del flujo continuo en tiempo real recibido. Estos segmentos residen en un directorio de la máquina que alberga el divisor en tiempo real que a continuación actúa como servidor original para el flujo continuo en tiempo real. El divisor en tiempo real construye una lista de reproducción (que en realidad es una lista de URL) usando los segmentos creados a partir del flujo continuo en tiempo real. La lista de reproducción forma el contenido del archivo hdx.

Procesar el flujo continuo en tiempo real en el divisor en tiempo real y los nodos de extremo:

En este caso, se explican los detalles de cómo se procesa un flujo continuo en tiempo real en el divisor en tiempo real. El flujo continuo en tiempo real tiene un segmentador que se lanza una vez que se pone en marcha el divisor en tiempo real.

Una vez que el divisor en tiempo real obtiene un flujo continuo en tiempo real, pasa el

flujo continuo al segmentador.

Se divide una señal en tiempo real en el segmentador en segmentos, cada uno de 5 s de duración. Estos segmentos se usan para crear una lista de reproducción. Además, se crea un archivo de metainformación que tiene la siguiente información (a) tamaño de segmento (5 s), (b) primer y (e) último segmento, (d) tasa de transmisión de trama, (e) resolución, (f) tasa de transmisión de datos, etc. El divisor en tiempo real sirve como servidor original para flujos continuos en tiempo real.

Los segmentos, metadatos y la lista de reproducción se descargan por el nodo de extremo a través de su módulo de descarga. En el nodo de extremo, el módulo de flujo continuo en tiempo real implementa un planificador que tiene tres módulos, un predictor del punto de reproducción en tiempo real, un módulo gestor de descarga P2P y un módulo servidor de flujo continuo en tiempo real. El predictor del punto de reproducción en tiempo real estima el segmento actual y la posición actual del flujo continuo con respecto al punto de flujo continuo en tiempo real para un usuario final que recibe un flujo continuo en tiempo real. El módulo gestor de descarga P2P se usa para obtener los segmentos en la lista de reproducción generada por el segmentador. Este módulo implementa un planificador que usa una combinación de política egoísta y política del menos frecuente localmente. La política egoísta obtiene segmentos en el entorno inmediato de la posición de reproducción actual. La política del menos frecuente localmente obtiene los segmentos que se reproducirán algo después en el futuro y hay pocos nodos de extremo en el entorno que tengan el segmento. La política egoísta garantiza que el nodo de extremo continuará ateniendo la solicitud sin interrupción mientras que la política del menos frecuente localmente garantiza que el nodo de extremo es altruista respecto a los nodos de extremo de su entorno. Esto permite al nodo de extremo dar servicio a sus vecinos de modo que no sea necesario que cada nodo de extremo de entorno obtenga los segmentos del archivo hdx del servidor original (en el caso del flujo continuo en tiempo real, el divisor de flujo continuo).

Es preferible tener el divisor en tiempo real cerca del elemento de difusión que envía el flujo continuo para evitar una pérdida de calidad en la transmisión del flujo continuo en tiempo real.

Iniciar y detener un flujo continuo en tiempo real:

Tal como se observa en la figura 1, el divisor en tiempo real se encarga de

obtener el flujo continuo en tiempo real del propietario de contenido. Una vez que el tiempo actual supera el tiempo de inicio del flujo continuo en tiempo real se dispara un evento en el divisor en tiempo real. Una consecuencia de este disparo es que la petición de flujo continuo en tiempo real se envía al propietario de contenido y el divisor en tiempo real recibe un flujo continuo en tiempo real.

Cuando el tiempo actual supera el tiempo de finalización del flujo continuo en tiempo real, se dispara un evento en el divisor en tiempo real que da como resultado el cierre de la conexión entre el divisor en tiempo real y el propietario de contenido.

La deshabilitación por parte del propietario de contenido de un contenedor en tiempo real también deshabilita un flujo continuo en tiempo real y cierra la conexión con el propietario de contenido.

Cómo los nodos de extremo construyen el flujo continuo en tiempo real:

Los nodos de extremo obtienen los metadatos del contenedor en tiempo real una vez creado. Esto permite a los nodos de extremo que están configurados para proporcionar un flujo continuo en tiempo real identificar el servidor original para el flujo continuo en tiempo real. Para proporcionar un flujo continuo en tiempo real a usuarios finales solicitantes, un nodo de extremo debe obtener los segmentos del servidor original del flujo continuo en tiempo real o de otros nodos de extremo en el mismo centro de datos. Para ello, un nodo de extremo usa su gestor de entorno, su unidad de descarga y su módulo de transmisión en flujo continuo en tiempo real.

La unidad de descarga en un nodo de extremo es responsable de todo el acceso a Internet (ya sean los nodos de entorno o el servidor original). El gestor de entorno en un nodo de extremo mantiene una lista de todos sus vecinos (en el mismo centro de datos). El rastreador proporciona la lista de direcciones IP de entorno a un nodo de extremo. El gestor de entorno también hace un seguimiento de todos los vecinos que tienen un determinado archivo (o segmento como en el caso de la transmisión en flujo continuo en tiempo real). A continuación se describe con más detalle el módulo de transmisión en flujo continuo en tiempo real.

El nodo de extremo tiene tres submódulos, tal como muestra la figura 2, que forman parte del módulo de transmisión en flujo continuo en tiempo real: el predictor del punto de reproducción en tiempo real, el gestor de descarga P2P y el servidor de flujo continuo en tiempo real. A continuación se define la función de cada uno de los

módulos en la unidad de transmisión de flujo continuo en tiempo real en el nodo de

extremo.

Predictor del punto de reproducción en tiempo real: Este módulo es responsable de la obtención del archivo hdr desde el divisor en tiempo real. Este archivo hdr contiene toda la información de metadatos de cabecera sobre el contenido en tiempo real: la tasa de transmisión de trama, resolución, tasa de transmisión de datos, primer y último segmento, etc.

Este módulo también obtiene el archivo hdr desde el divisor en tiempo real periódicamente. Este archivo tiene una lista de URL que el gestor de descarga P2P usa para obtener los segmentos individuales. Este módulo también se usa para estimar el punto de reproducción en tiempo real actual en el flujo continuo. Esto es especialmente útil si el archivo hdx se pierde o retarda. La recepción de un archivo hdx nuevo sincroniza la estimación local del punto de reproducción en tiempo real actual respecto al punto de reproducción en tiempo real, real, en el divisor en tiempo real que actúa como servidor original para el flujo continuo en tiempo real.

Gestor de descarga P2P: El archivo hdx contiene una lista de URL (cada uno de una duración de 5 s). El módulo de transmisión en flujo continuo en tiempo real conoce la posición actual del flujo continuo en tiempo real, el segmento actual que está visualizando el usuario y el tamaño de la memoria intermedia. Basándose en esta información, el archivo hdx y la información de entorno, el gestor de descarga P2P planifica las descargas de segmentos según el algoritmo de planificación descrito en [23]. En este caso, la planificación se basa en una combinación de planificación egoísta (que obtiene los segmentos necesarios para la reproducción inmediata) y planificación del primero menos frecuente (el nodo de extremo descarga los segmentos que están menos replicados entre los nodos de extremo de su entorno).

La memoria intermedia permite a un usuario final realizar operaciones de OVO en un flujo continuo en tiempo real. La duración en la que un usuario final puede retroceder en un flujo continuo en tiempo real está limitada sólo por el tamaño de la memoria intermedia en el nodo de extremo.

Cuando el gestor de descarga P2P descarga un segmento, permite al gestor de entorno local conocer la existencia del segmento nuevo. El gestor de entorno local informa a todos los demás nodos de extremo dedicados a la transmisión en flujo continuo en tiempo real acerca de la existencia del segmento recibido recientemente. No todos los vecinos van al divisor en tiempo real (servidor original) para descargar

todos los archivos en el hdx. Con un retardo aleatorio de [0-1] segundos, cada uno de

los vecinos realiza una petición de cada archivo en el hdx entre sí.

La unidad de descarga comprueba en primer lugar si el archivo solicitado está disponible en los discos locales. Si no está disponible en el disco local, comprueba con el gestor de entorno desde qué vecino puede obtener los datos. Sólo como último paso obtiene la unidad de descarga los datos del servidor original. Si hay un gran número de vecinos, introduciendo el retardo aleatorio, este esquema permite a los vecinos obtener los archivos en el hdx en gran medida uno de otro sin que todos los nodos de extremo sobrecarguen el servidor original.

Servidor de flujo continuo en tiempo real: El servidor de flujo continuo en tiempo real obtiene los segmentos del módulo gestor de descarga P2P y los combina para formar un flujo continuo en tiempo real. Este flujo se proporciona entonces al (a los) usuario(s) final( es) solicitante(s).

Los nodos de extremo solicitan la lista de reproducción en el archivo hdx periódicamente (cada 30 s). Aunque la lista de reproducción enviada desde el divisor en tiempo real se pierda o retarde, el nodo de extremo puede predecir los URL de la lista de reproducción basándose en la petición recibida con éxito previa (y el tiempo requerido para reproducir los segmentos en la lista). En realidad, los nodos de extremo conocen el tamaño del anillo de memoria intermedia que almacena los URL y el punto de reproducción actual de la ventana deslizante de la lista de reproducción).

Una vez que el usuario final solicita un flujo continuo en tiempo real, el nodo de extremo que proporcionará el contenido se identifica mediante el servicio de DNS del proveedor de servicios CON. El nodo de extremo solicitará entonces el flujo continuo en tiempo real al servidor original (divisor en tiempo real) y a otros nodos de extremo en el mismo centro de datos.

¿Cómo proporciona un nodo de extremo un flujo continuo en tiempo real?

Una vez que un usuario final solicita un flujo continuo en tiempo real, el nodo de extremo comprueba en primer lugar los metadatos del contenedor en tiempo real. El nodo de extremo garantiza entonces que el usuario final satisface los siguientes criterios:

-: El nodo de extremo comprueba en primer lugar la dirección IP del usuario

final para asegurarse de que el usuario final no está sujeto a geobloqueo.

-El nodo de extremo realiza una comprobación para asegurarse de que la petición del usuario final de un flujo continuo en tiempo real se recibe entre los

metadatos de tiempo de inicio y tiempo de finalización especificados para el

contenedor en tiempo real.

Una vez satisfechos los criterios anteriores, el nodo de extremo está listo para dar servicio a los usuarios finales solicitantes. El nodo de extremo ya tiene la dirección del divisor en tiempo real a partir de los metadatos del contenedor en tiempo real. Puesto que el divisor en tiempo real sirve como servidor original para el flujo continuo en tiempo real, el nodo de extremo realiza una petición del flujo continuo. Si un usuario final llega después del tiempo de finalización de un evento en tiempo real, la petición del flujo continuo en tiempo real se rechaza con un mensaje de error generado por el nodo de extremo.

Al recibir una petición de flujo continuo en tiempo real válida, el nodo de extremo obtiene en primer lugar el archivo hdr y obtiene periódicamente archivos hdx actualizados desde el divisor en tiempo real. El nodo de extremo construye entonces el flujo continuo en tiempo real tal como se comentó anteriormente y proporciona el flujo continuo al usuario final solicitante.

Realizar operaciones de OVO en un flujo continuo en tiempo real:

El nodo de extremo mantiene una memoria intermedia del flujo continuo en tiempo real. Esto permite a un usuario final realizar operaciones de OVO (retroceder para ver de nuevo un punto interesante en el evento) incluso en un flujo continuo en tiempo real. La duración durante la que un usuario final puede retroceder en el tiempo está limitada por el tamaño de la memoria intermedia en el nodo de extremo. Este tamaño de memoria intermedia es en realidad el mínimo de la memoria intermedia en el divisor en tiempo real y el nodo de extremo de servicio.

Una vez que un usuario final realiza operaciones de OVO (vuelve en el tiempo) en un flujo continuo en tiempo real, se reinicia el punto de reproducción actual. Sin embargo, el punto de reproducción en tiempo real actual del flujo continuo sigue avanzando (al igual que el último segmento que puede almacenarse en la memoria intermedia). Basándose en el algoritmo de [23] el gestor de descarga P2P descargará segmentos usando una estrategia que usa una combinación híbrida de política egoísta y política del menos frecuente localmente para planificar las descargas de segmentos basándose en el segmento actual que está reproduciéndose (y el tiempo de reproducción esperado de segmentos posteriores).

¿Qué sucede cuando el último usuario final abandona un nodo de extremo?

El nodo de extremo mantiene un recuento de referencia para todos los usuarios

finales que están visualizando un flujo continuo en tiempo real. Una vez que un usuario

final abandona (deja de visualizar) un flujo continuo en tiempo real, el nodo de extremo

cierra el socket con el usuario final y reduce el recuento de referencia para el flujo

continuo en tiempo real. Cuando el recuento de referencia es igual a cero, el nodo de extremo deja de

obtener el contenido de flujo en tiempo real del divisor en tiempo real.

Ventajas de la invención

El diseño de sistema tiene una serie de ventajas:

-: Al dividir un flujo continuo en tiempo real y crear una lista de reproducción, crea la impresión de obtener el archivo de un contenedor en un nodo de extremo.

-: Uso de algoritmos P2P (de múltiples fuentes) que permiten a los nodos de extremo en un centro de datos obtener segmentos del flujo continuo de vídeo unos de otros. Esto reduce significativamente la carga en el divisor en tiempo real (que sirve como servidor original para el flujo continuo en tiempo real).

-: El diseño del sistema de transmisión en flujo continuo en tiempo real usado en la CON es un sistema híbrido; usa P2P para obtener contenido de otros nodos de extremo cuando es posible y del divisor en tiempo real (el servidor original) cuando es necesario.

-: Al mantener una memoria intermedia en un flujo continuo en tiempo real en los nodos de extremo, se permite a un usuario final realizar operaciones de OVO en un flujo continuo en tiempo real (pausa, retroceder en el tiempo, etc.).

-: Al mantener una memoria intermedia en un flujo continuo en tiempo real en el divisor en tiempo real, los nodos de extremo pueden obtener contenido del divisor en tiempo real en respuesta a operaciones de OVO en un flujo continuo en tiempo real por parte de un usuario final.

-Uso de HTTP como mecanismo de transporte para entregar el flujo continuo en tiempo real desde un nodo de extremo a usuarios finales solicitantes. Un experto en la técnica puede introducir cambios y modificaciones en las

realizaciones descritas sin apartarse del alcance de la invención tal como se define en las reivindicaciones adjuntas.

Siglas y Abreviaturas

ADSL: Asymmetric Digital Subscriber Une; Línea de abonado digital asimétrica

CON: Content Distribution Network; Red de distribución de contenido

DNS: Domain Name Service; Servidor de nombres de dominio

PoP: Point of Presence; Punto de presencia

URL: Uniform Resource Locator; Localizador uniforme de recursos

Bibliografía

[1] S. Annapureddy, S. Guha, C. Gkantsidis, D. Gunawardena y P. Rodriguez. ls High-Quality VoD feasible using P2P Swarming. En WWW, 2007.

[2] B. Cheng, H. Jin y X. Liao. Supporting VCR functions in P2P VoD Services Using Ring-Assisted Overlays. En ICC, 2007.

[3] Y. Huang, T. Z. J. Fu, D.M. Chiu, J.C.S. Lui y C. Huang. Challenges, Design and Analysis of a Large-scale P2P VoD System. En Proc. of Sigcomm, 2008.

[4] A. Hu. Video-on-demand broadcasting protocols: A comprehensive study. En IEEE lnfocom, 2001.

[5] K. Almeroth, y M. Ammar. On the use of multicast delivery to provide a scalable and interactive Video-on Demand service. En Journal of Selected Areas in Communications, 1996.

[6] Y. Zhou, D. Chiu y J. Lui. A Simple Model for Analyzing P2P Streaming Protocols. En Proc. of ICNP, 2007.

[7] N. Vratonjic, P. Gupta, N. Knezevic, D. Kostic, A. Rowstron. Enabling DVD-Iike features in P2P Video-on-Demand-Systems. En ACM P2P-TV Workshop, 2007.

[8] A. Vahdat, K. Yocum, K. Walsh, P. Mahadevan, D. Kosti, J. Chase, D. Becker Scalability and Accuracy in a Large-Scale Network Emulator En Proc. of OSDI, 2002.

[9] C. Jin, Q. Chen, S. Jamin. lnet: Internet topology generator. Univ. de Michigan TR CSE-TR-433-00, 2000.

[1 O] C. Dana, D. Ll, D. Harrison, y C. Chuah. BASS: Bit-Torrent assisted streaming system for video-on-demand. MMSP, 2005.

[11] A. Vlavianos, M. lliofotou, y M. Faloutsos Enhancing BitTorrent for supporting streaming applications. En IEEE Global Internet, 2006.

[12] B. Cheng, X. Liu, Z. Zhang, y H. Jin. A Measurement Study of a Peer-to-Peer Video-on-Demand System. IPTPS 2007.

[13] P. Marciniak, N. Liogkas, A. Legout, E Kohler, quot;Small ls Not Always Beautiful,quot; En Proc. of IPTPS, 2008.

[14] Yung Ryn Choe, Derek L. Schuff, Jagadeesh M. Dyaberi, Vijay S. Pai,

lmproving VoD server efficiency with bittorrent En Proc. of IEEE Multimedia 5 2007.

[15] J.J.D. Mol, J.A. Pouwelse, M. Meulpolder, D.H.J. Epema, y H.J. Sips, Give-to-Get: Free-riding-resilient Video-on-Demand in P2P Systems, MMCN08

[16] Rawflow. En http:/ /en. wikipedia.org/wiki/Rawflow y http://www.rawflow.com

10 [17] Windows Media Services. En http://en.wikipedia.org/wiki/Windows_Media_Services y http://www.microsoft.com/windows/windowsmedia/forpros/server/server.aspx

[18] Adobe Flash Media Server Family,

http://www.adobe.com/products/flashmediaserver/ 15 [19] Youtube. En http://www.youtube.com

[20] Netflix. En http://www.netflix.com

[21] X. Yang, M. Gjoka, P. Chhabra, A. Markopoulou, y P. Rodriguez, quot;Kangaroo: Video Seeking in P2P Systemsquot;, En Proc. of IPTPS'09, Boston, EE.UU., abril de 2009

20 [22] Octoshape. En http://www.octoshape.com y http://en.wikipedia.org/wiki/Octoshape

[23] EP09382307.8, Method for Downloading Segments of a Video File in a Peer-To-Peer Network

Claims

REIVINDICACIONES

1.

Método para distribuir flujo continuo de contenido en tiempo real en una red de distribución de contenido, que comprende proporcionar, una entidad de dicha red de distribución de contenido, o CON, un flujo continuo en tiempo real solicitado a al menos un usuario final, estando el método caracterizado porque la gestión y entrega de dicho flujo continuo en tiempo real solicitado se realiza usando una arquitectura basada en P2P, en el que los iguales son nodos de extremo o servidores de contenido de dicha CON que intercambian contenido entre sí, y en el que la entrega de dicho flujo continuo en tiempo real solicitado a dicho al menos un usuario final se realiza desde al menos uno de dichos puntos finales, o nodo de extremo de servicio.
2.

Método según la reivindicación 1, en el que dichos nodos de extremo iguales están ubicados en el mismo centro de datos.
3.

Método según la reivindicación 1 ó 2, que comprende obtener, dicho nodo de extremo, dicho flujo continuo en tiempo real solicitado por fragmentos o segmentos en los que previamente se ha dividido el flujo continuo en tiempo real.
4.

Método según la reivindicación 3, que comprende obtener, dicho nodo de extremo, dichos segmentos de un flujo continuo en tiempo real desde un servidor original y/o desde nodos de extremo de entorno.
5.

Método según la reivindicación 4, en el que dicho servidor original es un divisor en tiempo real que comprende un segmentador, y comprendiendo el método dividir dicho flujo continuo en tiempo real por medio de dicho segmentador.
6.

Método según la reivindicación 5, que comprende generar una lista de reproducción de enlaces o URL de dichos segmentos por medio de dicho segmentador, y obtener, dicho nodo de extremo, dichos segmentos a través de dichos enlaces de la lista de reproducción.
7.

Método según la reivindicación 6, que comprende descargar, dicho al menos un nodo de extremo de servicio, dicha lista de reproducción de dicho divisor en tiempo real.
8.

Método según la reivindicación 6, que comprende reenviar, dicho divisor en tiempo real, dicha lista de reproducción a dicho al menos un nodo de extremo de servicio.
9.

Método según la reivindicación 8, en el que dichos enlaces de la lista de

reproducción se refieren sólo a parte de los segmentos de todo el flujo continuo en tiempo real, comprendiendo el método generar una nueva lista de reproducción con URL de nuevos segmentos y reenviar periódicamente dicha nueva lista de reproducción a cada uno de los nodos de extremo de servicio como una actualización enviada o bien tras una petición o bien automáticamente.

1O. Método según la reivindicación 7, 8 ó 9, que comprende: -crear, un propietario de contenido o cliente CON, un contenedor o contenedor en tiempo real, y asociar metadatos con el contenedor, asignar el URL del flujo continuo en tiempo real y la dirección del divisor en tiempo real a los metadatos de dicho contenedor en tiempo real; -emitir, el gestor CON del proveedor de servicios CON, un comando a dicho divisor en tiempo real para iniciar el flujo continuo en tiempo real una vez creado dicho contenedor en tiempo real; -el divisor en tiempo real, tras la recepción de dicho comando,:

-

lanzar el segmentador; -comenzar con la descarga del flujo continuo en tiempo real desde el URL proporcionado por el propietario de contenido y reenviar el flujo continuo en tiempo real recibido al segmentador; -crear y almacenar los segmentos del flujo continuo en tiempo real en el segmentador, generar una lista de reproducción a partir de dichos segmentos y crear un archivo de cabecera de metainformación;

-

descargar, al menos un nodo de extremo de servicio, dicha lista de reproducción del flujo continuo en tiempo real, los segmentos de la lista de reproducción y dicho archivo de cabecera de metainformación desde el divisor en tiempo real y recibir actualizaciones periódicas de URL de la lista de reproducción desde el divisor en tiempo real.
11. Método según la reivindicación 1O, que comprende cerrar dicha conexión establecida al dispararse cualquiera de los siguientes eventos: -que el tiempo actual en el divisor en tiempo real supere el tiempo de finalización del flujo continuo en tiempo real especificado por el propietario de contenido en los metadatos de contenedor del flujo continuo en tiempo real; -que dicho flujo continuo en tiempo real se detenga porque el propietario de contenido deshabilite dicho contenedor en tiempo real a través de los metadatos de contenedor;

-

que el contenedor en tiempo real supere la duración durante la que puede

estar activo especificada por el propietario de contenido en los metadatos de

contenedor.
12. Método según la reivindicación 1O, en el que dicho archivo de cabecera de metainformación tiene al menos la siguiente información: tamaño de segmento, tasa de transmisión de trama del primer y el último segmento, resolución y tasa de transmisión de datos.
13. Método según la reivindicación 1 O ó 12, en el que dicho al menos un nodo de extremo de servicio comprende: -usar un módulo predictor del punto de reproducción en tiempo real para: -estimar el segmento y la posición del flujo continuo actualmente en reproducción con respecto al punto de flujo continuo en tiempo real, y -obtener dicho archivo de cabecera de metainformación como un archivo hdr y dicha lista de reproducción como URL de segmentos como un archivo hdx desde el divisor en tiempo real;

-

obtener los segmentos indicados en la lista de reproducción a la manera de P2P usando un módulo gestor de descarga que usa un algoritmo de planificación que usa información sobre segmentos presentes en otros nodos de extremo de su gestor de entorno y que también usa la información proporcionada por dicho módulo predictor del punto de reproducción en tiempo real, dicho archivo hdr, información sobre el tamaño de la memoria intermedia prevista para almacenar los segmentos; y -combinar los segmentos recibidos para formar un flujo continuo en tiempo real y proporcionar el flujo continuo a los usuarios finales solicitantes por medio de un módulo servidor de flujo continuo en tiempo real.
14.

Método según la reivindicación 13, en el que dicho algoritmo de planificación usado por dicho módulo de gestor de descarga P2P en un nodo de extremo se basa en una combinación de planificación egoísta para obtener los segmentos necesarios para la reproducción inmediata, y planificación del primero menos frecuente para descargar los segmentos que están menos replicados entre los nodos de extremo de su entorno.
15.

Método según la reivindicación 13 ó 14, que comprende comprobar, dicho módulo de gestor de descarga P2P, en primer lugar si el segmento solicitado
16.
17.
18.
19.
20.

está disponible en sus discos locales, y si no está disponible: -comprobar qué nodo de extremo de entorno tiene dicho segmento, y:

-

descargar el segmento requerido desde un nodo de extremo de

entorno que tenga el segmento, o

-

si ningún nodo de extremo de entorno tiene dicho segmento requerido,

descargar el segmento del divisor en tiempo real que actúa como

servidor original para el flujo continuo en tiempo real. Método según la reivindicación 15, que comprende usar, varios nodos de extremo participan en la transmisión en flujo continuo en tiempo real, cada uno sus módulos de gestor de descarga P2P respectivos para descargar segmentos unos de otros después de un retardo aleatorio pequeño e ir al servidor original del flujo continuo en tiempo real para descargar segmentos sólo como último recurso para garantizar una reproducción continua para un usuario final. Método según cualquiera de las reivindicaciones 13 a 16, que comprende informar, dicho módulo gestor de descarga P2P, al descargar un nuevo segmento, a los nodos de extremo de su entorno acerca de la existencia del nuevo segmento usando dicho módulo gestor de entorno. Método según la reivindicación 13, que comprende dimensionar dicha memoria intermedia prevista para almacenar los segmentos recibidos en el nodo de extremo para permitir que un usuario final realice operaciones de OVO en el flujo continuo en tiempo real proporcionado al mismo, incluyendo operaciones de rebobinado hasta el tamaño de la memoria intermedia. Método según la reivindicación 13, que comprende obtener, dicho módulo predictor del punto de reproducción en tiempo real de dicho nodo de extremo de servicio, dicho archivo de cabecera de metainformación una vez creado un contenedor en tiempo real por dicho propietario de contenido CON e iniciar, el divisor en tiempo real, el flujo continuo en tiempo real. Método según la reivindicación 19, que comprende proporcionar, dicho nodo de extremo, el flujo continuo en tiempo real a un usuario final solicitante sólo si no está sujeto a geobloqueo y la petición del usuario final de un flujo continuo en tiempo real se recibe entre los metadatos de tiempo de inicio y de tiempo de finalización del contenedor en tiempo real especificados por el propietario de contenido.
21. Método según cualquiera de las reivindicaciones anteriores, que comprende identificar el nodo de extremo que proporcionará el contenido solicitado a través del servicio de DNS de la CON en respuesta a un usuario final que solicita un flujo continuo en tiempo real.

5 22. Método según la reivindicación 1 O, que comprende mantener, dicho nodo de extremo de servicio, un recuento de referencia para todos los usuarios finales que visualizan el flujo continuo en tiempo real proporcionado, y: -una vez que un nodo de extremo empieza a dar servicio a un usuario final solicitante, aumentar el recuento de referencia para ese flujo continuo en

10 tiempo real en el nodo de extremo, y -una vez que un usuario final abandona un flujo continuo en tiempo real, cerrar el nodo de extremo que proporciona el flujo continuo en tiempo real, la conexión de socket con el usuario final y reducir dicho recuento de referencia para el flujo continuo en tiempo real en dicho nodo de extremo, y

15 -una vez que el recuento de referencia para un flujo continuo en tiempo real es igual a cero, dejar de obtener, el nodo de extremo que recibe el flujo continuo en tiempo real, el contenido de flujo continuo en tiempo real desde el divisor en tiempo real.
23. Nodo de extremo para una red de distribución de contenido, caracterizado

20 porque comprende un módulo de flujo continuo en tiempo real que implementa un planificador que incluye un módulo predictor del punto de reproducción en tiempo real, un módulo gestor de descarga P2P y un módulo servidor de flujo continuo en tiempo real, para distribuir flujo continuo de contenido en tiempo real realizando las acciones del método según la reivindicación 13.