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

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.

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.

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.

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...

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.

-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.

16.

17.

18.

19.

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.

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 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

-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