ES2586818T3 - Control de flujo de contenido tratado inicialmente en red - Google Patents

Control de flujo de contenido tratado inicialmente en red Download PDF

Info

Publication number
ES2586818T3
ES2586818T3 ES12818785.3T ES12818785T ES2586818T3 ES 2586818 T3 ES2586818 T3 ES 2586818T3 ES 12818785 T ES12818785 T ES 12818785T ES 2586818 T3 ES2586818 T3 ES 2586818T3
Authority
ES
Spain
Prior art keywords
client
manifest file
function
distribution
content
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES12818785.3T
Other languages
English (en)
Inventor
Ray Van Brandenburg
Omar Aziz Niamut
Mattijs Oskar Van Deventer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO
Koninklijke KPN NV
Original Assignee
Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO
Koninklijke KPN NV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO, Koninklijke KPN NV filed Critical Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO
Application granted granted Critical
Publication of ES2586818T3 publication Critical patent/ES2586818T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications

Abstract

Un método para permitir un control, a iniciativa de la red, de la difusión en flujo de contenido segmentado desde un nodo de distribución (232) a al menos un cliente (230), comprendiendo dicho método: recibir (204) un primer fichero de manifiesto que comprende uno o más identificadores de segmentos e información de localización que sirve para localizar uno o más nodos de distribución de contenido configurados para transmitir uno o más segmentos asociados con dichos uno o más identificadores a dicho al menos un cliente; proporcionar (210) información de establecimiento de canal al cliente; y establecer al menos un canal de control de difusión en flujo entre dicho al menos un cliente y una función de servidor para canales de control asociada con dicho nodo de distribución sobre la base de dicha información de establecimiento de canal proporcionada, estando dicho al menos un cliente configurado para recibir (224) al menos un mensaje de actualización del fichero de manifiesto por intermedio de dicho canal de control de difusión en flujo.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Control de flujo de contenido tratado inicialmente en red CAMPO DE LA INVENCION
La invencion se refiere al control de difusion en flujo de contenido y, en particular, pero no exclusivamente, a metodos para permitir un control, a iniciativa de la red, de la difusion en flujo de contenido segmentado, para un cliente para uso en un dispositivo de procesamiento de contenido para controlar la recepcion de contenido segmentado, una funcion de servidor para canales de control y una estructura de datos para permitir un control, a iniciativa de la red, de la difusion en flujo de contenido segmentado y un producto de programa informatico que utiliza dicho metodo.
ANTECEDENTES DE LA INVENCION
Actualmente, un numero cada vez mayor de tecnicas de difusion en flujo de video hacen uso de la asf denominada segmentacion de contenido en donde los datos de contenido, p.ej., datos de video, son logica o virtualmente divididos en varios flujos o ficheros de segmentos, con lo que se genera un contenido segmentado. Un fichero de segmentos se puede referir a un fichero que comprende datos de contenido, que se pueden recuperar por intermedio de un protocolo de recuperacion de ficheros, p.ej., HTTP o FTP. De modo similar, una difusion en flujo de segmentos se puede referir a una difusion en flujo que comprende datos de contenido que se pueden recuperar mediante un protocolo de difusion en flujo, p.ej., RTSp/RTP o HAS. Flujos o ficheros de segmentos (en adelante referidos en forma abreviada, como segmentos) pueden distribuirse a un cliente por separado, pero cuando se recombinan en el cliente proporcionan un flujo de video sin interrupciones.
Durante el proceso de segmentacion de contenido se genera un asf denominado fichero de manifiesto que identifica los segmentos y describe la relacion entre los diferentes segmentos y las localizaciones en donde pueden recuperarse los segmentos. Un contenido segmentado puede proporcionarse en varias presentaciones, p.ej., versiones alternativas del mismo contenido que difieren, a modo de ejemplo, en la resolucion, el numero de canales de audio y/o una tasa binaria diferente. Todas las presentaciones estan temporalmente alineadas de modo que los segmentos de diferentes presentaciones se puedan intercambiar sin interrupcion. La difusion en flujo de contenido segmentado en diferentes presentaciones se refiere como una difusion en flujo adaptativo en donde un protocolo de difusion en flujo adaptativo tal como difusion en flujo adaptativo de HTTP (HAS) y protocolos relacionados se pueden utilizar a este respecto.
HAS permite la distribucion de video (en directo) por medio del protocolo HTTP, transmitiendo la senal de video en segmentos que son demandados independientemente por el cliente desde un servidor de la web. Varios protocolos HAS comercializados y normalizados existen a este respecto, tales como Apple HTTP Live Streaming
http://tools.ietf.org/html/draft-pantos-http-live-streaming-07, Microsoft Smooth Streaming
http://www.iis.net/download/ SmoothStreaming, Adobe HTTP Dynamic Streaming
http://www.adobe.com/products/ httpdynamicstreaming, 3GPP- DASH TS 26.247 Servicio de difusion en flujo de paquetes conmutados (PSS) extremo a extremo transparente; Descarga progresiva y difusion en flujo adaptativa dinamico por intermedio de HTTP y difusion en flujo adaptativo dinamico de MPEG por intermedio de HTTP MPEG DASH ISO/IEC 23001-6).
Un contenido segmentado puede utilizarse para la adaptacion dinamica a exigencias de ancho de banda cambiantes, p.ej., conmutando desde una difusion en flujo de video de alta calidad a baja calidad. Ademas, un contenido segmentado puede permitir tambien discriminar entre segmentos (de video) populares y menos populares. A modo de ejemplo, en condiciones normales un contenido asociado con el inicio de un video (tal como trailer) sera observado con mas frecuencia (y por ello, sera mas popular) que el contenido al final. De modo similar para algunos casos de uso, un contenido de video de mas baja calidad de baja tasa binaria (p.ej., los segmentos hAs de la mas baja resolucion) probablemente seran descargados con mas frecuencia que el contenido de alta calidad (p.ej., segmentos HAS de mas alta resolucion) que pueden ser de mas alto coste o mas demandas desde el dispositivo de recepcion o que requiere mas ancho de banda. Las propiedades antes citadas del contenido segmentado pueden utilizarse ventajosamente por una red de distribucion de contenido (CDN), que este configurada para distribuir contenido a un cliente. Una red CDN puede, a modo de ejemplo, memorizar segmentos de contenido populares, mas frecuentemente demandados, en multiples nodos de distribucion en la red CDN de modo que se puedan reducir los problemas del ancho de banda y se garantice una distribucion eficiente. Una funcion de control de CDN (CDNCF) puede gestionar centralmente las localizaciones dentro de la red CDN, en adelante referidas como nodos de distribucion, en donde segmentos de contenido asociados con un elemento de contenido (tal como un video o pelfcula animada) puede recuperarse (obtenerse).
Aunque numerosos protocolos de difusion en flujo diferentes, tales como RTP/RTSP o RTMP, pueden utilizarse para poner en practica la difusion en flujo de contenido (segmentado) a un cliente, los protocolos de difusion en flujo de HTTP o protocolos basados en HTTP son los mas ampliamente utilizados dentro de una red CDN. Estos protocolos de difusion en flujo utilizan un protocolo HTTP estandar - un protocolo sin estado de cliente-servidor - para demandar y recibir segmentos de contenido desde un servidor sin necesidad de una nueva funcionalidad y
5
10
15
20
25
30
35
40
45
50
55
60
65
permitiendo que los segmentos sean captados de forma transparente. Ademas, a diferencia de muchas otras soluciones de difusion en flujo, el trafico de HTTP, como tal, no se suele bloquear automaticamente por los denominados 'cortafuegos' o traductores de direcciones de redes (NATs).
Ademas, la difusion en flujo basada en HTTP no esta basada en sesiones. Lo que antecede significa que el servidor HTTP no necesita mantener sesiones para los diversos clientes a los que esta sirviendo. De este modo, la arquitectura del servidor HTTP puede mantenerse simple. Sin embargo, esta naturaleza sin sesion combinada con el hecho de que HTTP es un protocolo a iniciativa del cliente significa tambien que un servidor HTTP, p.ej., un nodo de distribucion en una red CDN, no es capaz de iniciar la comunicacion con un cliente.
Con el fin de permitir a un cliente acceder (descargar/recuperar) segmentos memorizados en una red CDN, el cliente esta provisto de un asf denominado fichero de manifiesto que comprende una lista de segmentos estando cada uno de ellos identificado por un identificador de segmento (p.ej., un nombre de fichero de segmentos) y localizaciones de segmentos (localizadores de segmentos), p.ej., URL, que apuntan a un nodo de red en donde los segmentos pueden ser objeto de acceso (recuperarse). Dependiendo de la red CDN particular y/o de su puesta en practica, un fichero de manifiesto predefinido puede memorizarse en uno o mas nodos (de distribucion) de la red CDN, junto con los segmentos asociados, o un fichero de manifiesto puede ser generado, de forma dinamica, por la red CDN a peticion del usuario.
De este modo, cuando un consumidor (dispositivo de cliente) demanda un elemento de contenido segmentado particular (tal como un video), la red CDN puede, bajo demanda, identificar un fichero de manifiesto memorizado en un nodo (de distribucion) que es adecuado para permitir la distribucion del artfculo de contenido demandado al consumidor (dispositivo). Como alternativa, la red CDN puede generar un nuevo fichero de manifiesto que identifica uno o mas nodos de distribucion que, considerados juntos, son adecuados para distribuir los segmentos de contenido demandados al consumidor. Posteriormente, la red CDN puede enviar el fichero de manifiesto generado en una respuesta al cliente (dispositivo) demandante del consumidor.
Durante la difusion en flujo de los segmentos de contenido, puede cambiar la configuracion de la red o la distribucion de la carga en la red CDN. A modo de ejemplo, un fallo operativo o sobrecarga en un nodo de una red CDN puede dar lugar a una situacion en donde uno o mas nodos de distribucion en una red CDN ya no sean capaces de distribuir segmentos de contenido identificados en el fichero de manifiesto. Tambien en otras situaciones, p.ej., en una situacion de sobrecarga inminente, puede requerirse impedir una situacion de sobrecarga trasladando la tarea de distribuir un segmento de contenido particular a un consumidor particular (dispositivo receptor de contenido) durante el proceso de difusion en flujo desde un nodo de distribucion a otro nodo de distribucion de la red CDN o incluso a un nodo de distribucion en otra red CDN. Se puede imaginar incluso que cuando un dispositivo de cliente de un consumidor particular cambia su posicion, puede ser tambien mas conveniente tener otro nodo de distribucion, que es ahora el mas proximo, para asumir la difusion en flujo desde el nodo original. Otros eventos operativos en la red de distribucion que pueden requerir o garantizar un cambio u orden para la distribucion de segmentos a un cliente (esto es, iniciador de mecanismos de equilibrado de carga en la red) son paradas tecnicas planificadas, una Migracion de Servidor, una Migracion de red CDN, etc.
En metodos conocidos, dicho cambio en la distribucion de segmentos a un cliente puede realizarse de varias maneras. En algunos casos, una red CDN puede utilizar, a modo de ejemplo, un sistema de redireccionamiento de HTTP con el fin de redireccionar la demanda para un segmento al nodo de distribucion deseado. Dicho sistema, sin embargo, puede requerir e iniciar un mensaje de respuesta redirigido separado (simplemente referido como una redireccion) para cada segmento que el cliente demandare en el futuro, o incluso multiples mensajes de respuesta redirigidos por segmento demandado, con lo que se introduce un aumento importante de la carga de senalizacion en la red. Lo que antecede es de especial interes en el caso cuando una gran cantidad de consumidores dependen del mismo nodo de distribucion y se esta demandando y recuperando, simultaneamente, el mismo contenido. No solamente puede la carga de senalizacion adicional producir una sobrecarga operativa sobre partes o la totalidad de la red CDN, sino que los redireccionamientos pueden causar interrupciones del servicio inadmisibles en el lado del cliente, puesto que la distribucion de los segmentos de contenido individuales se retarda bruscamente como un resultado de los redireccionamientos. Por ello, el sistema de redireccionamiento puede no ser capaz de impedir efectivamente las interrupciones del servicio debido a cambios en la configuracion de la red (como resultado de, a modo de ejemplo, un fallo operativo del nodo de distribucion). Las interrupciones del servicio pueden ser mas importantes en situaciones en donde, a modo de ejemplo, poco contenido se memoriza en el dispositivo del cliente, en situaciones en donde se producen multiples redireccionamientos o en donde el nuevo nodo de distribucion objetivo es situado a una distancia considerablemente mayor respecto al dispositivo del cliente, en comparacion con la distancia anterior.
Como alternativa, la red CDN puede generar un fichero de manifiesto recientemente actualizado para el cliente sobre la base de la nueva configuracion de red. Sin embargo, debido a su propia naturaleza, el protocolo HTTP no permite al lado del servidor (p.ej., la red CDN) iniciar, de forma directa y/o proactiva, la transmision de dicho fichero de manifiesto recientemente actualizado al cliente o, como alternativa, iniciar una demanda de cliente para dicho fichero de manifiesto recientemente actualizado. Si el cliente recibe, o no, un fichero de manifiesto actualizado dependera completamente de la iniciativa del cliente (que, sin embargo, no tiene conocimiento de cambios
5
10
15
20
25
30
35
40
45
50
55
60
65
(pendientes) en la configuracion de la red) para demandar dicha actualizacion. De modo similar si, a modo de ejemplo, un en flujo de contenido segmentado se hiciere disponible por la red CDN en una mas alta presentacion que la que se presenta en el fichero de manifiesto anteriormente proporcionado al cliente, el cliente no tiene forma alguna de conocer esta situacion y no puede beneficiarse de dicha difusion en flujo de mas alta calidad. Aun cuando el cliente estuviera configurado para, p.ej., demandar periodicamente actualizaciones del fichero de manifiesto, dichos planes de actualizacion no pueden efectivamente (con rapidez) sobre una base ad hoc, reaccionar a cambios en la configuracion de la red y evitar las interrupciones del servicio debidas a dichos cambios. Sena simplemente una coincidencia si dicha frecuencia de actualizacion coincidiera exactamente con un cambio de configuracion imprevistamente necesario. Ademas, la puesta en practica de una muy alta frecuencia de actualizacion (que hace uso de un mecanismo de senalizacion de demanda de respuesta sobre la base del HTTP) tiene el inconveniente de dar lugar a una carga de senalizacion de sobrecarga considerable en la red y la carga del procesador en el lado del cliente y de la red, incluso durante periodos en los que no cambie ninguna configuracion (p.ej., cambios en la distribucion del contenido segmentado a un cliente) sean necesarios o recomendables.
El documento US 2011/0264727 publicado con fecha da a conocer un metodo para proporcionar a un cliente una lista de reproduccion de segmentos de contenido accesibles en un servicio de difusion en flujo en directo proporcionado en un formato de difusion en flujo adaptativo del protocolo HTTP. Por consiguiente, existe una necesidad en esta tecnica para metodos y sistemas, que permitan un mejor control de la difusion en flujo del contenido a un cliente.
SUMARIO DE LA INVENCION
Constituye un objetivo de la invencion reducir o eliminar al menos uno de los inconvenientes conocidos en la tecnica anterior. El alcance de la invencion se define por las reivindicaciones adjuntas. Formas de realizacion preferidas estan cubiertas por las reivindicaciones subordinadas.
La invencion se ilustrara, ademas, haciendo referencia a los dibujos adjuntos, que ilustran, de forma esquematica, formas de realizacion en conformidad con la invencion. Se entendera que la invencion no esta, en forma alguna, restringida a estas formas de realizacion espedficas.
BREVE DESCRIPCION DE LOS DIBUJOS
La Figura 1 ilustra una descripcion general de una sesion de HAS convencional entre un cliente y un servidor.
La Figura 2 ilustra un flujo de protocolo entre un cliente y un servidor en conformidad con una forma de realizacion de la invencion.
La Figura 3 ilustra un flujo de proceso del lado del cliente en conformidad con una forma de realizacion de la invencion.
La Figura 4 ilustra un flujo de proceso en el lado del servidor en conformidad con una forma de realizacion de la invencion.
Las Figuras 5A-5C ilustran flujos de protocolos entre un cliente y un servidor en conformidad con varias formas de realizacion de la invencion.
La Figura 6 ilustra un sistema de difusion en flujo de contenido en conformidad con una forma de realizacion de la invencion.
La Figura 7 ilustra un flujo de mensajes para uso en un sistema de difusion en flujo de contenido en conformidad con una forma de realizacion de la invencion.
La Figura 8 ilustra un flujo de procesos asociado una funcion de Nodo de Continuidad de Distribucion (DCN) en conformidad con una forma de realizacion de la invencion.
La Figura 9 ilustra un flujo de mensajes para uso en un sistema de difusion en flujo de contenido en conformidad con otra forma de realizacion de la invencion.
La Figura 10 ilustra un flujo de mensajes para uso en un sistema de difusion en flujo de contenido en conformidad con otra forma de realizacion de la invencion.
La Figura 11 ilustra un flujo de mensajes para uso en un sistema de difusion en flujo de contenido en conformidad con otra forma de realizacion de la invencion.
La Figura 12 ilustra un sistema de difusion en flujo de contenido en conformidad con una forma de realizacion de la invencion.
5
10
15
20
25
30
35
40
45
50
55
60
65
La Figura 13 ilustra un flujo de mensajes para uso en un sistema de difusion en flujo de contenido en conformidad con otra forma de realizacion de la invencion.
La Figura 14 ilustra un fichero de manifiesto en conformidad con una forma de realizacion de la invencion. DESCRIPCION DETALLADA DE LA INVENCION
La Figura 1 ilustra una descripcion general de un flujo de protocolos HAS convencionales entre un cliente 130 en un terminal y un servidor multimedia 132 que estan configurados para comunicarse por intermedio de un protocolo de difusion en flujo, tal como el protocolo de difusion en flujo HAS, que comprende mensajes de protocolos de respuesta y demanda 134,136. En este caso, un terminal puede referirse, en general, a un dispositivo de procesamiento de contenido, a modo de ejemplo un dispositivo de reproduccion de contenido (movil) tal como una tableta electronica, un telefono inteligente, una agenda electronica portatil, un reproductor multimedia, etc. En algunas formas de realizacion, un terminal puede ser un decodificador o dispositivo de almacenamiento de contenido configurado para procesar y memorizar temporalmente un contenido para su futuro consumo por un dispositivo de reproduccion de contenido. De modo similar, el servidor multimedia puede ser parte de, o estar asociado con, un proveedor de contenidos o una red de distribucion de contenidos (CDN).
El flujo de protocolos puede iniciarse por un usuario que selecciona un enlace a un video en un sitio web (etapa 102) en donde el localizador URL puede apuntar (p.ej., mediante un redireccionamiento) a un fichero de manifiesto. El fichero de manifiesto puede relacionarse con una estructura de datos especial que comprende identificadores de segmentos, p.ej., nombres del fichero de segmentos, creacion de un fichero de video segmentado e informacion de localizacion asociada, p.ej., URLs, para localizar uno o mas nodos de distribucion, que esten configurados para distribuir los segmentos a un cliente (nodo de distribucion); o, como alternativa, a un nodo de red que sea capaz de determinar uno o mas nodos de red que puedan ser capaces de distribuir un segmento identificado. En otra forma de realizacion, la informacion de localizacion puede apuntar tambien a posiciones en un nodo de red. A modo de ejemplo, los segmentos asociados a URLs pueden apuntar a diferentes carpetas definidas en un nodo de distribucion.
Una referencia a un segmento, preferentemente incluido en un fichero de manifiesto, puede comprender un identificador de segmento y/o informacion de localizacion asociada con el identificador de segmento para localizar el segmento.
El fichero de manifiesto puede comprender, ademas, informacion que describa la relacion temporal y/o espacial entre los segmentos. Dicho fichero puede memorizarse e identificarse utilizando una extension de nombre de fichero espedfica, p.ej., .mf, .xml and .m3u8. El cliente puede enviar luego una demanda HTTP GET para obtener el fichero de manifiesto a partir del servidor (etapa 104). En respuesta, el servidor puede responder enviando el fichero de manifiesto al cliente (etapa 106). A continuacion, el cliente realiza un analisis sintactico del fichero de manifiesto para obtener las localizaciones de los segmentos asociados con el video demandado (etapa 108).
El cliente demanda el primer segmento del video a partir de la localizacion descrita en el fichero de manifiesto y el servidor responde a la demanda enviando el segmento demandado al cliente (etapas 110, 112). Sobre la base del fichero de manifiesto, se pueden recuperar varios segmentos (etapas 114,116). A continuacion, transcurrido un determinado periodo de tiempo, el cliente puede determinar (p.ej., sobre la base del funcionamiento de un temporizador predefinido, o el cliente casi alcanzando el final del fichero de manifiesto en una difusion en flujo en directo) que es el momento de actualizar el fichero de manifiesto y puede enviar una demanda a la misma localizacion desde donde se ha adquirido el manifiesto inicial (etapa 118). Un fichero de manifiesto actualizado se envfa, a continuacion, al cliente (etapa 120), que puede procesarse de nuevo por el cliente iniciando el analisis sintactico del fichero de manifiesto actualizado (etapa 122).
Como ya se indico con anterioridad, dicho sistema de difusion en flujo de contenido HAS convencional no permite un control basado en un servidor del proceso de difusion en flujo entre el cliente y el servidor. No permite el control en situaciones ad hoc, que son diffciles de predecir y en donde se requiere la adaptacion directa de la configuracion de difusion en flujo.
La Figura 2 ilustra un flujo de protocolos entre un cliente y un servidor en conformidad con una forma de realizacion de la invencion. En particular, la Figura 2 ilustra un flujo de protocolos asociados con un protocolo de difusion en flujo tal como un protocolo de difusion en flujo adaptativo de HTTP (HAS) para la difusion en flujo de contenido desde un servidor multimedia 232 a un cliente 230.
El cliente puede comprender una funcion de cliente de difusion en flujo 248, que procesa el flujo para su reproduccion por una funcion de reproduccion de video 246, y una funcion de cliente de canal de control 244 (CCCF). De modo similar, el servidor multimedia puede comprender una funcion de servidor de difusion en flujo 242 para la difusion en flujo multimedia a la funcion de cliente de difusion en flujo 248. El servidor multimedia puede comprender, ademas, una funcion de servidor de canal de control (CCSF), p.ej., una funcion de servidor para
5
10
15
20
25
30
35
40
45
50
55
60
65
canales de control HAS 234, en o en asociacion con el servidor 232, que esta configurado para iniciar el establecimiento de un canal de control de difusion en flujo 236 entre la funcion CCSF y la funcion CCCF 244, en donde el canal de control de difusion en flujo puede utilizarse para intercambiar informacion de control de difusion en flujo entre el cliente y el servidor, en particular, difusion en flujo de informacion de control que tiene su origen en el servidor hacia el cliente, durante la difusion en flujo de contenido segmentado 238 al cliente.
En este caso, el proceso puede iniciarse en la misma manera ilustrada en la Figura 1, esto es, un usuario hace clic en un enlace para un video en un sitio web en donde el URL puede apuntar (p.ej., mediante un redireccionamiento) hacia un fichero de manifiesto (etapa 200). El cliente puede enviar una demanda de HTTP GET para obtener el fichero de manifiesto a partir del servidor y el servidor puede dar respuesta enviando el fichero de manifiesto (en este caso, un fichero XML) al cliente (etapas 202, 204), que posteriormente realiza un analisis sintactico del fichero de manifiesto para obtener las localizaciones de los segmentos que constituyen el flujo de contenido demandado (etapa 206). En este caso particular, sin embargo, la funcion CCSF en el servidor esta configurada para insertar informacion de establecimiento de canal en el fichero de manifiesto, lo que permite a la funcion CCCF en el servidor establecer un canal de control de la difusion en flujo.
Sobre la base de la informacion de establecimiento de canal integrada en el fichero de manifiesto, la funcion CCCF en el cliente puede enviar, a modo de ejemplo, una demanda de establecimiento de canal a la funcion CCSF en el servidor (etapa 208) para establecer un canal de control de difusion en flujo del tipo servidor a cliente. En una forma de realizacion, las funciones CCCF y CCSF pueden comprender una interfaz HTTP WebSocket API configurada para utilizar el protocolo WebSocket y la informacion de establecimiento de canal para establecer un canal de control de difusion en flujo entre el cliente y el servidor. Las conexiones de WebSocket suelen utilizar los puertos de HTTP estandar 80 y 443 de modo que los datos puedan transmitirse con facilidad superando los denominados “cortafuegos" y NATs, pero tambien se pueden utilizar otros puertos.
El uso del protocolo de WebSocket tiene varias ventajas dentro del contexto de la red CDN y de HAS, tal como una baja carga de mensajes para escalabilidad, el uso del protocolo HTTP para la convergencia de protocolos y para atravesar dichos cortafuegos y la posibilidad de la tunelizacion de otros protocolos. En otra forma de realizacion, se utiliza el denominado Protocolo de Iniciacion de Sesion (SIP) (
http://tools.ietf.org/html/rfc3261) en donde el cliente puede comprender un agente de usuario de SIP y el servidor es un servidor de aplicacion de SIP.
En otra forma de realizacion, se utiliza el denominado Protocolo de Presencia y de Mensajena Extensible (XMPP) (
http://www.ietf.org/rfc/ rfc3920.txt), en donde el cliente puede comprender un cliente de XMPP y el servidor comprende un servidor XMPP. Ambos mensajes de protocolos SIP y XMPP pueden ser tunelizados a traves de un protocolo WebSocket en conformidad con draft-ibc-rtcweb-sip-websocket-00 y draft-moffitt-xmpp-over-websocket-00. Una descripcion mas detallada de formas de realizacion para los diferentes protocolos se proporciona en las Figuras 5A a 5C.
Durante el establecimiento del canal de control de difusion en flujo, parametros del canal pueden intercambiarse entre las funciones CCCF y CCSF (etapa 210). Ademas, con el fin de gestionar los mensajes que tienen su origen en el cliente, la funcion CCSF puede crear un proceso de gestion de canales dedicado (thread) (etapa 212). Una vez que se establezca el canal de control de difusion en flujo 214, el cliente puede iniciar el proceso de difusion en flujo de segmentos identificados en el fichero de manifiesto. El proceso de difusion en flujo puede basarse en un protocolo de difusion en flujo de tipo HAS e iniciarse con una demanda de HTTP GET que comprende un URL asociado con el primer segmento segment_low-1.avi (etapa 216). Una vez que la distribucion del primer segmento sea confirmada por una respuesta HTTP 200 OK (etapa 218), el cliente puede demandar un segmento posterior segment_high-2.avi (etapas 220, 222).
A continuacion, la funcion CCSF en el servidor multimedia puede decidir que sea necesario para el cliente actualizar su fichero de manifiesto. A modo de ejemplo, la funcion CCCF puede detectar una posible sobrecarga del servidor o su fallo operativo. Por lo tanto, puede enviar una serial de actualizacion de fichero de manifiesto a traves del canal de control de difusion en flujo (etapa 224) incluyendo opcionalmente un URL apuntando a un nuevo fichero de manifiesto. A la recepcion de la senal de actualizacion del fichero de manifiesto, la funcion CCCF puede demandar el nuevo fichero de manifiesto. A la recepcion del nuevo fichero de manifiesto, el cliente puede continuar la difusion en flujo sobre la base del nuevo manifiesto (no ilustrado).
En una forma de realizacion, en lugar de transferir la informacion de establecimiento de canal en el fichero de manifiesto, la informacion de establecimiento de canal puede preinstalarse en el terminal o puede recuperarse por intermedio de un canal de comunicaciones separado desde otra fuente (red). En ese caso, cuando el cliente reciba el fichero de manifiesto, inicia operativamente la funcion de cliente de canal de control de difusion en flujo para recuperar la informacion de establecimiento de canal con el fin de establecer un canal de control de difusion en flujo segun se describe haciendo referencia a la Figura 2, en las etapas 208 a 214.
En otra forma de realizacion, el servidor multimedia puede estar configurado para difundir en flujo segmentos a multiples clientes, en donde cada cliente esta asociado con su propio canal de control de difusion en flujo con el fin de permitir, a iniciativa de la red, p.ej., a iniciativa del servidor, un control segun se describe haciendo referencia a la
5
10
15
20
25
30
35
40
45
50
55
60
65
Figura 2. De este modo, el servidor puede controlar la difusion en flujo de contenido segmentado a multiples clientes sobre la base de un parametro de red, p.ej., el trafico de red o la carga de procesamiento del servidor. A modo de ejemplo, en una forma de realizacion particular, diferentes clientes pueden estar asociados con diferentes suscripciones, p.ej., una suscripcion de nivel superior y una suscripcion normal. Cuando una funcion de equilibrado de carga 240 asociada con el servidor multimedia detecta un aumento en la carga, puede reducir, con caracter preventivo, su carga senalizando a la funcion CCSF que inicie una actualizacion del fichero de manifiesto en donde (al menos parte de los) clientes normales estan provistos de un nuevo fichero de manifiesto que hace que estos clientes demanden segmentos asociados con una calidad mas baja y/o baja tasa de transmision.
Una actualizacion del fichero de manifiesto puede realizarse de varias maneras. En una forma de realizacion, la totalidad o al menos parte de un fichero de manifiesto actualizado puede enviarse por intermedio del canal de control de difusion en flujo al cliente. En otra forma de realizacion, la funcion CCSF puede enviar una iniciacion de actualizacion del manifiesto a un cliente, en particular, la funcion CCCF, que da respuesta demandado un fichero de manifiesto nuevo o actualizado desde una localizacion (por defecto) p.ej., el servidor multimedia original, o desde una nueva localizacion, p.ej., un servidor multimedia adicional, segun se identifica en la iniciacion de actualizacion del fichero de manifiesto (p.ej., utilizando un URL).
La Figura 3 ilustra un flujo de procesos en el lado del cliente en conformidad con una forma de realizacion de la invencion. En particular, la Figura 3 ilustra un flujo de procesos asociados con procesos ejecutados en un cliente para la recuperacion y reproduccion de segmentos y para proporcionar un control, a iniciativa del servidor, de la difusion en flujo por intermedio de un canal de control de difusion en flujo, segun se ilustra, a modo de ejemplo, en la Figura 2. El proceso puede iniciarse por un cliente que demanda un fichero de manifiesto asociado con un elemento de contenido segmentado particular (etapa 300). El fichero de manifiesto puede comprender las localizaciones de segmentos pero tambien informacion de establecimiento de canal que se utiliza por el cliente para establecer el canal de control de difusion en flujo (tal como un WebSocket URL y posiblemente, algunos parametros para la indicacion p.ej., del uso de los subprotocolos de WebSocket, version WebSocket, etc.). A la recepcion del fichero de manifiesto desde el servidor, el cliente puede realizar un analisis sintactico del fichero de manifiesto (etapas 301 y 302) e iniciar al menos dos procesos/threads separados en el cliente: al menos un primer proceso ejecutado por la funcion del cliente de difusion en flujo multimedia en el cliente para gestionar la recuperacion de segmentos y la reproduccion de los segmentos y un segundo proceso ejecutado por la funcion CCCF en el cliente para gestionar el canal de control de difusion en flujo. El cliente puede utilizar las localizaciones de segmentos descritas en el fichero de manifiesto para recuperar periodicamente segmentos y para su reproduccion (etapa 303) hasta que se detecte el final del video (etapa 304). Ademas, el cliente puede utilizar la informacion de establecimiento de canal incorporada en el fichero de manifiesto para enviar una demanda de establecimiento de canal al servidor sobre la base de un URL descrito en el fichero de manifiesto (etapa 305) y para establecer un canal de control de difusion en flujo, entre el cliente, en particular la funcion CCCF en el cliente, y el servidor (etapa 306), en particular la funcion CCSF asociada con el servidor. A continuacion, durante la difusion en flujo y la reproduccion de los segmentos, la funcion CCCF escucha a traves del canal de control de difusion en flujo los posibles mensajes entrantes procedentes del servidor (etapa 307). El canal de control de difusion en flujo puede utilizarse tambien para la transmision de datos desde el cliente al servidor.
En caso de un mensaje entrante procedente del servidor, la funcion CCCF puede comprobar si se ha recibido, o no, una senal de actualizacion de manifiesto (iniciador de actualizacion de manifiesto) (etapa 308). Si se ha recibido dicha senal de actualizacion de manifiesto, la funcion CCCF puede demandar un manifiesto actualizado (desde la localizacion desde la que se recibio el manifiesto original o desde un URL especificado en el mensaje de iniciacion de actualizacion de manifiesto) (etapa 309). Despues de recibir el fichero de manifiesto actualizado, el cliente realiza su analisis sintactico (vease etapa 302) y actualiza la lista de identificadores de segmentos y la informacion de localizacion asociada.
La Figura 4 ilustra un flujo de procesos en el lado del servidor en conformidad con una forma de realizacion de la invencion. En particular, la Figura 4 ilustra un flujo de procesos de los procesos ejecutados en un servidor multimedia para la difusion en flujo de segmentos a un cliente y para proporcionar un control, a iniciativa de la red, de la difusion en flujo utilizando un canal de control de la difusion en flujo. Los procesos pueden ejecutarse por las diversas funciones existentes en el servidor multimedia segun se describe, a modo de ejemplo, haciendo referencia a la Figura 2, esto es, una funcion de servidor de difusion en flujo, una funcion de servidor para canales de control y, de modo opcional, una funcion de equilibrado de carga. Las funciones pueden configurarse para ejecutar uno o mas procesos para supervisar la carga del servidor, dando respuesta a la demanda de segmentos procedentes del cliente y estableciendo y manteniendo un canal de control de difusion en flujo con el cliente.
A modo de ejemplo, un primer proceso puede ejecutarse por una funcion CCSF en el servidor multimedia que supervisa la recepcion de una demanda de un establecimiento de canal enviada por un cliente al servidor (etapa 402). Si se recibe dicha demanda, la funcion CCSF puede establecer un canal de control de difusion en flujo e iniciar un proceso de gestion de canales en donde se procesa adecuadamente la informacion que tiene origen en el cliente o se envfa al cliente, a modo de ejemplo. Un segundo proceso puede ejecutarse por una funcion de servidor de difusion en flujo multimedia que gestiona la recepcion de demandas procedentes de un cliente para un fichero de manifiesto y/o segmentos (etapa 400). Si se recibe dicha demanda, el servidor puede enviar la informacion
5
10
15
20
25
30
35
40
45
50
55
60
65
demandada (segmentos y/o un fichero de manifiesto) al cliente demandante (etapa 401). Un tercer proceso se puede requerir a una funcion de equilibrado de carga que supervisa la informacion de carga de la red y/o informacion de carga del servidor. Si la carga alcanza o se aproxima a un determinado valor umbral (maximo), puede senalizar a la funcion CCSF para la seleccion de uno o mas clientes para una actualizacion del fichero de manifiesto (etapa 405). En respuesta, la funcion CCSF puede enviar iniciadores de actualizacion de manifiesto a los clientes seleccionados (etapa 406).
A modo de ejemplo, en una forma de realizacion, la funcion de equilibrado de carga asociada con el servidor puede senalizar a la funcion CCSF la iniciacion de una actualizacion de fichero de manifiesto con el fin de reducir la carga de procesamiento del servidor. El fichero de manifiesto actualizado da instrucciones al cliente para continuar la difusion en flujo sobre la base de segmentos de mas baja calidad. En otra forma de realizacion, la funcion CCSF puede detectar una sobrecarga del servidor o un fallo operativo del servidor y en respuesta, iniciar una actualizacion del fichero de manifiesto para dar instrucciones a uno o mas clientes para recuperar segmentos desde otro servidor de red.
El proceso de actualizacion de manifiesto puede realizarse de varias formas. En una forma de realizacion, el fichero de manifiesto actualizado puede enviarse por la funcion CCSF por intermedio del canal de control de difusion en flujo a la funcion CCCF en los clientes. En otra forma de realizacion, la funcion CCSF puede enviar un iniciador de actualizacion del fichero de manifiesto a la funcion CCCF en el cliente, que, en respuesta, demanda un fichero de manifiesto nuevo o actualizado desde el servidor multimedia. En otra forma de realizacion, el iniciador de actualizacion del fichero de manifiesto puede comprender informacion de localizacion, p.ej., un localizador URL, de un servidor multimedia adicional de modo que el cliente pueda demandar - sobre la base de esa informacion de localizacion - un fichero de manifiesto nuevo o actualizado desde ese servidor multimedia adicional (etapa 406).
Las Figuras 5A a 5C ilustran varios flujos de protocolos no limitadores para establecer un canal de control de difusion en flujo para hacer posible el control de difusion en flujo a iniciativa de la red. En particular, la Figura 5A ilustra un flujo de mensajes similar al de la Figura 2, en donde se utiliza el protocolo HTTP WebSocket para establecer el canal de control de difusion en flujo. El proceso puede iniciarse con un usuario seleccionando un enlace a un video en un sitio web en donde el URL puede adjuntar (p.ej., mediante una redireccion) a un fichero de manifiesto (etapa 500a). En respuesta, el cliente puede enviar una demanda de HTTP GET para obtener el fichero de manifiesto desde el servidor (etapa 501a), que se envfa por el servidor (en este caso, en la forma de un fichero XML) al cliente (etapa 502a).
El cliente puede realizar un analisis sintactico del fichero de manifiesto para obtener las localizaciones de al menos parte de los segmentos que crean el video (etapa 503a) y utilizar la informacion incorporada en el fichero de manifiesto para enviar una demanda de establecimiento de WebSocket (HTTP GET /WS ws://...) al servidor (etapa 504a). Despues de realizar el dialogo operativo obligatorio de WebSocket (segun se describe con detalle en Ws draft draft-ietf-hybithewebsocketprotocol-17), el servidor puede aceptar la demanda de WebSocket desde el cliente utilizando un mensaje de protocolo HTTP l0l SWITCHING PROTOCOLS (etapa 505a). A continuacion, con el fin de gestionar los mensajes entrantes a traves del asf creado WebSocket, el servidor puede crear un proceso/thread dedicado (etapa 506a) con lo que se establece un canal de control de difusion en flujo de WebSocket que puede utilizarse para proporcionar un control de difusion en flujo para iniciativa del servidor (etapa 507a).
El protocolo de WebSocket permite la comunicacion bidireccional, en duplex completo, a traves de una conexion de Internet sin garantfa de la calidad del servicio. Tanto el servidor como el cliente pueden enviar datos en cualquier momento, o incluso al mismo tiempo por intermedio del canal de control de difusion en flujo. Solamente se envfan los datos sin la sobrecarga de cabeceras de HTTP lo que aumenta, en gran medida, el ancho de banda. Ademas, puesto que WebSocket es un protocolo basado en HTTP no se suele bloquear automaticamente por 'cortafuegos' o traductores de direcciones de redes (NATs).
La Figura 5B ilustra un flujo de mensajes parametro de aplicacion establecer un canal de control de difusion en flujo similar al ilustrado en la Figura 2 utilizando el protocolo SIP. El proceso puede iniciarse con un usuario seleccionando un enlace a un video en un sitio web en donde el URL puede apuntar (p.ej., mediante una redireccion) a un fichero de manifiesto (etapa 500b). En respuesta, el cliente puede enviar una demanda de HTTP GET para obtener el fichero de manifiesto desde el servidor (etapa 501b) que se envfa por el servidor (en este caso, en la forma de un fichero XML) al cliente (etapa 502b).
El cliente puede realizar un analisis sintactico del fichero de manifiesto para obtener las localizaciones de los segmentos que constituyen el video (etapa 503b) y utilizar la informacion incorporada en el fichero de manifiesto para enviar un mensaje SIP INVITE al Servidor de Aplicacion de SIP (etapa 504b). Esta informacion puede formatearse como un mensaje de Protocolo de Descripcion de Sesion [
http://www.ietf.org/rfc/rfc4566.txt]. El servidor puede aceptar el mensaje INVITE y dar respuesta con un mensaje SIP 200 OK (etapa 505b). A continuacion, con el fin de gestionar los mensajes entrantes a traves de la sesion SIP creada, el servidor puede crear un proceso/thread dedicado (etapa 506b) estableciendo de este modo un canal de control de difusion en flujo basado en SIP que puede utilizarse para proporcionar un control de difusion en flujo a la iniciativa del servidor (etapa 507b).
5
10
15
20
25
30
35
40
45
50
55
60
65
La Figura 5C ilustra un flujo de mensajes para establecer un canal de control de difusion en flujo similar al ilustrado en la Figura 2 usando el protocolo XMPP. El proceso puede iniciarse con un usuario seleccionando un enlace a un video en un sitio web en donde el URL puede apuntar (p.ej., mediante una redireccion) a un fichero de manifiesto (etapa 500c). En respuesta, el cliente puede enviar una demanda de HTTP GET para obtener el fichero de manifiesto desde el servidor (etapa 501c),) que se envfa por el servidor (en este caso, en la forma de un fichero XML) al cliente (etapa 502c).
El cliente puede realizar un analisis sintactico del fichero de manifiesto para obtener las localizaciones de los segmentos que constituyen el video (etapa 503c) y utilizar la informacion incorporada en el fichero de manifiesto, tal como el Identificador de Jabber (JID) del servidor XMPP para enviar un mensaje de demanda de sesion XMPP en la forma de uno o mas XML Stanzas por intermedio de un flujo de XML al servidor XMPP s (etapa 505c). El servidor XMPP puede aceptar el mensaje de demanda de sesion y responder con un mensaje de respuesta de creacion de sesion (etapa 506c). A continuacion, con el fin de gestionar los mensajes entrantes para la sesion XMPP asf creada, el servidor puede crear un proceso/thread dedicado (etapa 507c) con lo que se establece un canal de control de difusion en flujo basado en XMPP que puede utilizarse para proporcionar un control de difusion en flujo a la iniciativa del servidor (etapa 508c).
La Figura 6 ilustra un sistema de difusion en flujo de contenido 600 para distribuir un contenido segmentado a un cliente en conformidad con una forma de realizacion de la invencion. En particular, la Figura 6 ilustra una descripcion general de arquitectura de un sistema de distribucion de contenido que comprende una red CDN, que esta configurada para proporcionar un control de los procesos de difusion en flujo a la iniciativa de la red entre uno o mas nodos de distribucion en la red CDN y uno o mas clientes. El control, a la iniciativa de la red, puede realizarse sobre la base de la funcionalidad del canal de control de difusion en flujo segun se describe haciendo referencia a las Figuras 2 a 5.
En esta forma de realizacion, el sistema de distribucion de contenido puede comprender al menos una red de distribucion de contenido (CDN) 602, una fuente de contenidos (CS) 601 conectada mediante una red de transporte 600 a uno o mas clientes 603. La fuente de contenidos puede relacionarse con un sistema de proveedores de contenidos (CPS), un sistema de preparacion de contenidos u otra red CDN. Un sistema CPS puede configurarse para ofrecer contenido, p.ej., un elemento de audio o un tftulo de video, a los consumidores, que pueden adquirir y recibir el contenido utilizando un cliente.
El cliente puede establecerse con un programa informatico que se ejecuta en un terminal, esto es, un dispositivo de procesamiento de contenido, p.ej., un dispositivo de reproduccion de contenidos (movil) tal como una tableta electronica, un telefono inteligente, una agenda notebook, un reproductor multimedia, etc. En algunas formas de realizacion, un terminal puede ser un decodificador o un dispositivo de memorizacion de contenidos configurado para procesar y memorizar temporalmente un contenido para futuro consumo por un dispositivo de reproduccion de contenidos.
Una red CDN puede comprender nodos de distribucion (DN1, DN2) 611, 612 y al menos un nodo CDN central (CCN) 610. Cada nodo de distribucion puede comprender o estar asociado con un controlador 630,631 y una memoria cache 632,633 para memorizar contenidos. Cada CCN puede comprender o puede asociarse con una funcion de ingestion (o funcion de origen de contenidos, COF) 620 para controlar la ingestion operativa de contenido a partir de una fuente externa, p.ej., un proveedor de contenidos u otra red CDN, una base de datos de localizaciones de contenidos 622 para mantener informacion sobre en donde se memoriza el contenido dentro de una red CDN y una funcion de control CDN de (CDNCF) 621 para controlar la distribucion de una o mas copias del contenido a los nodos de distribucion y para redireccionar a los clientes a nodos de distribucion adecuados (un proceso tambien conocido como enrutamiento de las demandas). La distribucion puede controlarse de modo que mediante el ancho de banda suficiente de CDN esta garantizada la distribucion de contenidos para un cliente. En una forma de realizacion, la red CDN puede referirse a una CDN segun se describe en ETSI tS 182019.
Un consumidor puede adquirir un contenido segmentado, p.ej., tftulos de video, desde un sistema CPS 660 enviando una demanda a un portal de la web (WP) 661, que esta configurado para proporcionar referencias de tftulos que identifican tftulos de video susceptibles de compra. En respuesta a la demanda, un cliente puede recibir al menos parte de las referencias de tftulos desde el portal WP e informacion de localizacion, p.ej., un localizador URL, de una CDNCF de una CDN, que sea capaz de distribuir el contenido seleccionado.
La funcion CDNCF puede enviar la informacion de localizacion del cliente asociada con uno o mas nodos de distribucion, que estan configurados para distribuir el contenido seleccionado al cliente. Los segmentos pueden alojarse en un solo nodo de distribucion en CDN o, como alternativa, en diferentes nodos de distribucion en CDN. A modo de ejemplo, mas segmentos populares pueden alojarse en multiples nodos de distribucion en CDN, de modo que pueda garantizarse la distribucion a su debido tiempo. En condiciones normales, la funcion CDNCF puede seleccionar nodos de distribucion en CDN, que sean los mas adecuados para distribuir el contenido seleccionado al cliente. Los criterios para seleccionar uno o mas nodos de distribucion pueden basarse en la carga de procesamiento de los nodos de distribucion y/o la informacion contextual asociada con el cliente: p.ej., localizacion del cliente (la direccion IP) y/o la suscripcion del cliente (p.ej., una suscripcion de nivel superior o una suscripcion
5
10
15
20
25
30
35
40
45
50
55
60
65
normal segun se describio con anterioridad haciendo referencia a la Figura 2). Por lo tanto, de este modo, la funcion CDNCF puede generar, de forma dinamica, un fichero de manifesto, que se optimiza para distribuir eficientemente segmentos al cliente.
Un cliente puede entrar en contacto con el nodo de distribucion en CDN utilizando, a modo de ejemplo, un sistema DNS convencional. Ademas, varios protocolos de difusion en flujo pueden utilizarse para distribuir el contenido a una funcion de difusion en flujo multimedia 652 que procesa el flujo para la reproduccion por una funcion de reproduccion de video 651. Dichos protocolos pueden incluir los protocolos de difusion en flujo del tipo HTTP y RTP/RTCP. En una forma de realizacion preferida, un protocolo de difusion en flujo adaptativo tal como difusion de flujo adaptativo de HTTP (HAS) y protocolos relacionados tales como Apple HTTP Live Streaming, Microsoft Smooth Streaming, Adobe HTTP Dynamic Streaming, 3GPP-DASH y MPEG Dynamic Adaptive Streaming a traves de HTTP pueden utilizarse a este respecto.
Las redes CDNs estan configuradas para admitir y distribuir un contenido segmentado. Los sistemas de difusion en flujo de contenido segmentado conocidos pueden basarse en una segmentacion temporal, tal como difusion en flujo adaptativa de HTTP (HAS), en donde puede organizarse el contenido en varios segmentos (elementos o partes), que pueden ser objeto de la operacion de dar formato en conformidad con un formato de contenedor de transporte conocido tal como MPEG o AVI.
La relacion entre los segmentos puede describirse en un fichero de manifiesto, que puede memorizarse e identificarse utilizando una extension y el nombre del fichero espedfica, p.ej., .mf, .xml y .m3u8. El fichero de manifiesto puede describir, ademas, las localizaciones y los nombres (identificadores de segmentos) de los diferentes segmentos en uno o mas nodos de distribucion. Los segmentos, en particular los segmentos populares, pueden recuperarse desde mas de un nodo de distribucion en una red CDN. Ademas, en algunas situaciones, deben recuperarse segmentos desde los nodos de distribucion en otro dominio de CDN. Dicha situacion se describira con mas detalle haciendo referencia a las Figuras 12 y 13. La funcion CDNCF puede gestionar las localizaciones en donde pueden recuperarse segmentos. Para esa finalidad, la funcion CDNCF puede utilizar la base de datos de localizaciones de contenidos 622. En una forma de realizacion, la base de datos de localizaciones de contenidos puede referirse como una Funcion de Localizacion de Contenidos (ALF), segun se describe en ETSI TS 182 019.
Ademas, la red CDN puede comprender un denominado Nodo de Continuidad de Distribucion (DCN) 613 que esta configurado para establecer y gestionar canales de control de difusion en flujo asociados con clientes y para mantener una base de datos que comprende los clientes y los nodos de distribucion a los que estan conectados estos clientes. La red DCN puede comprender una funcion de gestion de continuidad de distribucion (DCMF) 640. Esta funcion puede ejecutar un proceso para supervisar notificaciones que tienen su origen a partir de la funcion de enrutamiento-demanda (RR) de la funcion CDNCF. El nodo DCN puede comprender, ademas, una funcion de servidor para canales de control (CCSF) 641 en la DCN para supervisar las demandas de establecimiento de canal procedentes de clientes y para establecer un canal de control de difusion en flujo con una funcion de cliente de canal de control (CCCF) 650 en el cliente.
Ademas, una base de datos de continuidad de distribucion (DC) 642 en, o asociada con, la red DCN puede memorizar informacion del cliente (p.ej., su direccion IP) e informacion del fichero de manifiesto (esto es, identificadores de segmentos (p.ej., nombre de ficheros) y al menos parte de los nodos de distribucion que alojan estos segmentos). Una funcion de gestion de continuidad de distribucion (DCMF) puede supervisar las notificaciones de las redes, p.ej., notificaciones de sobrecarga o notificaciones de fallo operativo, con origen en la funcion CDNCF o desde una funcion de supervision de red separada en la CDN y para iniciar un proceso de actualizacion de fichero de manifiesto en respuesta a la recepcion de dicha notificacion de la red. Los detalles sobre los procesos y funciones en la DCN se describen haciendo referencia a la Figura 8.
Aunque en la Figura 6 las funciones en el nodo DCN, esto es, la funcion DCMF y la funcion CCSF se ponen en practica en un nodo separado, (el DCN), en otras formas de realizacion, estas funciones pueden ponerse en practica tambien de forma completa o parcial, en el CCN 610 que comprende la funcion CDNCF y la funcion de ingestion operativa.
La Figura 7 ilustra un flujo de mensajes para uso en un sistema de difusion en flujo de contenido en conformidad con una forma de realizacion de la invencion. En particular, la Figura 7 ilustra un flujo de mensajes para uso en un sistema de difusion en flujo de contenido del tipo CDN configurado para proporcionar un control, a la iniciativa de la red, de procesos de difusion en flujo entre uno o mas nodos de distribucion en CDN y uno o mas clientes. En esta forma de realizacion, el CDN puede comprender al menos un primer y un segundo nodos de distribucion (DN1, DN2) y un CCN que comprende una funcion CDNCF, una funcion DCMF y una funcion CCSF segun se describe haciendo referencia a la Figura 6.
El proceso en la Figura 7 puede iniciarse con un usuario seleccionando un enlace a un video en un sitio web en donde un localizador URL puede apuntar (p.ej., mediante una redireccion) a un fichero de manifiesto (etapa 700). A la seleccion, un cliente puede enviar una demanda HTTP GET a la funcion CDNCF para obtener el fichero de manifiesto (etapa 701). La funcion CDNCF puede dar respuesta a la demanda enviando un fichero de manifiesto al
5
10
15
20
25
30
35
40
45
50
55
60
65
cliente (etapa 702). En este caso, sobre la base de la informacion procedente de una funcion de equilibrado de carga, la funcion CDNCF puede seleccionar y/o generar un fichero de manifiesto que contiene referencias (p.ej., identificadores de segmentos y/o informacion de localizacion asociada) a segmentos memorizados en un primer nodo de distribucion DN1. Ademas, la funcion CDNCF registra el hecho de que ha enviado al cliente particular (definido, p.ej., por su direccion IP) un fichero de manifiesto que contiene referencias a un nodo de distribucion o (conjunto de) nodos de distribucion particulares (en este ejemplo, el nodo de distribucion DN1). Para dicha finalidad, la funcion CDNCF puede memorizar informacion del cliente (p.ej., la direccion IP del cliente) e informacion del fichero de manifiesto (p.ej., el identificador de fichero de manifiesto Manifest ID, asociado con al menos parte de un tftulo de video y la informacion de localizacion del nodo o del conjunto de nodos de distribucion particulares que alojan los segmentos que son objeto de referencia por el fichero de manifiesto en la base de datos de continuidad de distribucion (DC) para un uso adicional (etapa 703).
En este caso, el identificador del fichero de manifiesto puede identificarse por un numero y los nodos de distribucion pueden identificarse por identificadores de nodos de distribucion conocidos dentro de CDN. El cliente puede realizar un analisis sintactico del fichero de manifiesto para obtener las localizaciones de los segmentos (p.ej., URLs) que constituyen el video (etapa 704). Ademas, la funcion CCCF en el cliente puede utilizar la informacion de establecimiento de canal en el fichero de manifiesto para establecer un canal de control de difusion en flujo entre la funcion CCCF y la funcion CCSF en la CDN (etapa 705a) (el proceso de establecimiento del canal de control de difusion en flujo entre una funcion CCCF y una funcion CCSF se describe haciendo referencia a la Figura 2 y 3 y por ello aqu no se repite).
Durante el establecimiento del canal de control de difusion en flujo, la funcion CCSF puede establecer una correlacion de la demanda de establecimiento de canal con un cliente espedfico y uno o mas nodos de distribucion asociados utilizando la informacion memorizada en la base de datos DC (etapa 705b). En particular, la funcion CCSF puede consultar la base de datos DC para el cliente para el que se establece el canal de control de difusion en flujo (en donde el cliente puede identificarse p.ej., por su direccion IP) y asignar un identificador de canal de control de difusion en flujo unico o Channel ID, (p.ej., el numero de puerto o, en el caso de que se utilice WebSocket, un identificador WebSocket ID) a la entrada de la base de datos que pertenece al cliente. De este modo, la funcion CCSF es capaz de relacionar una combinacion de cliente-canal espedfica con un nodo de distribucion o un conjunto de nodos de distribucion particulares y/o un fichero de manifiesto.
Una vez que se establece el canal de control de difusion en flujo, el cliente puede iniciar el proceso de difusion en flujo demandando un primer segmento (en este caso, segment_low-1) procedente del primer nodo de distribucion DN1 (segun se refiere en el fichero de manifiesto) (etapa 706). El nodo de distribucion DN1 puede dar respuesta con una difusion en flujo del segmento demandado al cliente (etapa 707).
Durante el proceso de difusion en flujo, en algun punto en el tiempo, la funcion CDNCF (constituida o asociada con una funcion de equilibrado de carga para supervisar la carga de nodos de distribucion en CDN) puede notificar que la carga en el primer nodo de distribucion DN1 se aproxima a un nivel umbral (maximo) (etapa 708). La funcion CDNCF puede informar a la funcion DCMF para comprobar que clientes estan utilizando el primer nodo de distribucion DN1 comprobando la informacion memorizada en la base de datos DC (etapa 709). La funcion DCMF puede decidir, entonces, redireccionar algunos (o la totalidad) de los clientes que se alejan del primer nodo de distribucion DN1 a otro segundo nodo de distribucion DN2 de modo que se reduzca la carga de procesamiento del primer nodo de distribucion D1. Para dicha finalidad, la funcion DCMF puede dar instrucciones a la funcion CCSF para enviar un iniciador de actualizacion de manifiesto a traves de los canales de control de difusion en flujo de los clientes seleccionados con la funcion DCMF (etapa 710) utilizando la informacion contenida en la base de datos DC.
A la recepcion del iniciador de actualizacion de manifiesto, la funcion CCCF en el cliente se inicia operativamente para demandar un fichero de manifiesto nuevo o actualizado enviando una demanda de manifiesto a la funcion CDNCF (etapa 711) (en una forma similar a la descrita haciendo referencia a la etapa 701). La funcion CDNCF puede recibir la demanda de manifiesto y seleccionar o generar un fichero de manifiesto nuevo o actualizado para el cliente y enviar este fichero de manifiesto al cliente.
En una forma de realizacion, cuando se genera un fichero de manifiesto nuevo o actualizado, la funcion CDNCF puede utilizar informacion procedente de la funcion de equilibrado de carga con el fin de seleccionar un nuevo nodo de distribucion (vease tambien la etapa 702). Ademas el fichero de manifiesto nuevo o actualizado puede contener enlaces a segmentos memorizados en el segundo nodo de distribucion DN2.
En una forma de realizacion, el iniciador de actualizacion de manifiesto puede comprender informacion de localizaciones, p.ej., un localizador URL, que identifique un nodo adicional que comprende el fichero de manifiesto nuevo o actualizado. En otra forma de realizacion, en lugar de enviar un iniciador de actualizacion de manifiesto para senalizar al cliente la recuperacion de un fichero de manifiesto nuevo o actualizado, el fichero de manifiesto nuevo o actualizado puede transmitirse directamente por intermedio del canal de control de difusion en flujo al cliente. Despues de que el fichero de manifiesto actualizado se reenvfe al cliente, utiliza el fichero de manifiesto nuevo o actualizado para reanudar la difusion en flujo de segmentos desde el segundo nodo de distribucion (no ilustrado).
5
10
15
20
25
30
35
40
45
50
55
60
65
Puesto que el cliente ha recibido un fichero de manifiesto nuevo o actualizado, la funcion CDNCF puede utilizar la informacion de fichero de manifiesto asociada con ese cliente en la base de datos DC realizando la etapa segun se describe haciendo referencia a 703. De este modo, si en algun punto en el futuro se produce un problema de sobrecarga, la funcion CDNCF puede ser capaz de redireccionar el cliente de nuevo a otro nodo de distribucion.
La Figura 8 ilustra un flujo de procesos asociado con un Nodo de Continuidad de Distribucion (DCN) en conformidad con una forma de realizacion de la invencion. En particular, la Figura 8 proporciona una descripcion general de una o mas funciones que pueden alojarse en un nodo de continuidad de distribucion (DCN) segun se describe haciendo referencia a la Figura 6. El nodo DCN puede configurarse para establecer y gestionar canales de control de difusion en flujo asociados con clientes y para mantener una tabla en la que se enumeran los clientes y los nodos de distribucion a los que estan conectados. En otra forma de realizacion, la totalidad o al menos parte de las funciones asociadas con un DCN pueden alojarse en el CCN (vease Figuras 7, 9, 11 y 13).
El nodo DCN puede comprender una funcion de gestion de continuidad de distribucion (DCMF). Esta funcion puede ejecutar un proceso para supervisar la notificacion que tiene su origen a partir de la funcion de demanda- enrutamiento (RR) de la funcion CDNCF (etapa 800). Siempre que una funcion CDNCF envfe un fichero de manifiesto a un cliente, o redireccione un cliente a un nodo de distribucion particular, la funcion CDNCF puede informar al DCN sobre que nodos de distribucion el cliente tiene previstos para recuperar segmentos desde dichos nodos (esto es, los nodos de distribucion que son objeto de referencia en el fichero de manifiesto enviado al cliente, o el nodo de distribucion al que se redirecciona el cliente). A la recepcion de la notificacion, el nodo DCN puede anadir una entrada en una base de datos de continuidad de distribucion (DC) que asigna el cliente particular identificado por, p.ej., su direccion IP a al menos parte de los nodos de distribucion objeto de referencia en el fichero de manifiesto enviado a ese cliente (etapa 801).
Ademas, una funcion de servidor para canales de control (CCSF) puede supervisar las demandas de establecimiento de canal procedentes de una funcion CCCF en un cliente (etapa 802). Si se recibe una demanda, iniciara un proceso para establecer un canal de control de difusion en flujo sobre la base de un protocolo adecuado p.ej., WebSocket, SIP o XMPP.
Durante el establecimiento del canal de control de difusion en flujo, la funcion CCSF puede consultar la base de datos DC para el cliente para el que se establece un canal de control de difusion en flujo (en donde el cliente puede identificarse p.ej., por su direccion IP) y asignar un identificador de canal de difusion en flujo unico (p.ej., el numero de puerto o, en caso de que se utilice WebSocket, un identificador WebSocket ID) a la entrada de base de datos que pertenece al cliente (etapa 803). La funcion DCMCF puede ejecutar entonces un proceso de supervision para controlar las notificaciones de red, p.ej., notificaciones de sobrecarga de red o notificaciones de fallos operativos desde la funcion CDNCF, una funcion de equilibrado de carga asociada con CDNCF (etapa 804) o una funcion de supervision de red separada. En una forma de realizacion, una notificacion de sobrecarga o de fallo operativo puede incluir informacion respecto al numero de clientes a los que desea redireccionar la funcion CDNCF.
Una vez que la funcion DCMF recibe dicha notificacion (relativa a un nodo de distribucion en su propia CDN o un nodo de distribucion en otra CDN (no ilustrada)) a partir de la funcion CDNCF, puede consultar la base de datos DC para comprobar los clientes que esta previsto que recuperen segmentos a partir del nodo de distribucion asociado con la notificacion de sobrecarga o de fallo operativo (etapa 805). La funcion DCMF puede seleccionar entonces uno o mas clientes para ser redireccionados (etapa 806) (esta seleccion puede basarse en el numero de clientes objeto de redireccionamiento segun se describio con anterioridad haciendo referencia a la etapa 804). En adelante, la funcion DCMF puede consultar su base de datos con el fin de identificar los canales de difusion en flujo (utilizando, p.ej., el identificador de canal de difusion en flujo) asociados con los clientes seleccionados y enviar un iniciador de actualizacion de manifiesto por intermedio de cada uno de estos canales.
La funcion DMCF puede configurarse, ademas, para supervisar los mensajes que tienen su origen en el cliente. En una forma de realizacion, la funcion DMCF puede enviar un fichero de manifiesto nuevo o actualizado a traves del canal de control de difusion en flujo al cliente.
La Figura 9 ilustra un flujo de mensajes para uso en un sistema de difusion en flujo de contenido en conformidad con otra forma de realizacion de la invencion. En particular, la Figura 9 ilustra un flujo de mensajes para uso con un sistema de distribucion de contenido similar al representado en la Figura 7. En esta forma de realizacion, sin embargo, no se entregan ficheros de manifiesto por la funcion CDNCF a los clientes, sino que se realiza por los propios nodos de distribucion. Para esa finalidad, un nodo de distribucion, p.ej., primer nodo de distribucion nodo de distribucion DN1 puede comprender ficheros de manifiesto que solamente comprenden referencias a segmentos en ese nodo de distribucion.
El proceso en la Figura 9 puede iniciar con un usuario seleccionado un enlace a un video en un sitio web en donde el URL apunta (p.ej., mediante una redireccion desde un proveedor de contenidos) a una funcion de Enrutamiento de Demanda (rR) de una funcion CDNCF (etapa 900). Despues de que el cliente haya enviado una demanda HTTP GET a la funcion CDNCF (etapa 901), la funcion RR de la CDNCF puede seleccionar, sobre la base de p.ej., la informacion obtenida a partir de la funcion de equilibrado de carga un nodo de distribucion que sea adecuado para
5
10
15
20
25
30
35
40
45
50
55
60
65
distribuir el fichero de manifiesto demandado y el contenido segmentado asociado al cliente. La funcion CDNCF puede enviar luego al cliente un mensaje HTTP REDIRECT que contiene el URL para el fichero de manifiesto en el nodo de distribucion seleccionado (en este ejemplo particular, el primer nodo de distribucion DN1) (etapa 902).
Cuando se redirecciona la demanda de HTTP GET, la funcion CDNCF puede memorizar la informacion del cliente (p.ej., la direccion IP del cliente) y la informacion del fichero de manifiesto (p.ej., el identificador del fichero de manifiesto, o Manifest ID), asociado con al menos parte de un tftulo de video, y la informacion de localizacion del nodo de distribucion particular o del conjunto de nodos de distribucion que alojan los segmentos que son objeto de referencia por el fichero de manifiesto) en la base de datos de continuidad de distribucion (DC) para un uso adicional (etapa 903). En este caso, el identificador de fichero de manifiesto puede identificarse por un numero y los nodos de distribucion pueden identificarse por los identificadores de nodos de distribucion conocidos dentro de CDN.
A la recepcion del mensaje de HTTP REDIRECT procedente de la funcion CDNCF, el cliente puede enviar un nuevo HTTP gEt al URL en el mensaje REDIRECT asociado con el primer nodo de distribucion (etapa 904). El nodo de distribucion DN1 responde posteriormente enviando el fichero de manifiesto demandado al cliente (etapa 905).
Despues de haber recibido el fichero de manifiesto, el cliente puede realizar un analisis sintactico del fichero de manifiesto para obtener las localizaciones de los segmentos que constituyen el video (etapa 906). La funcion CCCF en el cliente puede utilizar la informacion de establecimiento de canal en el fichero de manifiesto para establecer un canal de control de difusion en flujo entre la funcion CCSF y el cliente (etapa 907a) (El proceso de establecimiento de canal se describe en las Figuras 2 y 3 y por ello no se repite aqu de nuevo).
Durante el establecimiento del canal de control de difusion en flujo, la funcion CCSF puede establecer una correlacion de la demanda de establecimiento de canal con un cliente espedfico y nodos de distribucion asociados utilizando la informacion memorizada en la base de datos DC (etapa 907b). En particular, la funcion CCSF puede consultar la base de datos DC para el cliente para el que se establece un canal de control de difusion en flujo (en donde el cliente puede identificarse p.ej., por su direccion IP) y asignar un identificador de canal de difusion en flujo unico (p.ej., el numero de puerto o, en caso de que se utilice WebSocket, un identificador WebSocket ID) a la entrada de la base de datos que pertenece al cliente. De este modo, las funciones en CDN pueden comprobar que combinaciones de cliente/canal estan utilizando que (conjunto de) nodos de distribucion (a modo de ejemplo, en este caso, CDNCF puede comprobar que el cliente particular esta utilizando el primer nodo de distribucion DN1 y ha recibido un fichero de manifiesto espedfico).
Una vez que se establece el canal de control de difusion en flujo (segun se describe, p.ej., en las Figuras 2 y 3), el cliente puede iniciar la demanda, la recepcion y la reproduccion de segmentos obtenidos desde el primer nodo de distribucion DN1 (etapa 908). Durante el proceso de difusion en flujo, en algun punto en el tiempo, la funcion CDNCF (que comprende o esta asociada con una funcion de equilibrado de carga para supervisar los nodos de distribucion de carga en CDN) puede notificar que la carga en el primer nodo de distribucion DN1 alcanza un nivel umbral (maximo) predeterminado (etapa 909). La funcion CDNCF puede iniciar, entonces, operativamente la funcion DCMF para determinar que clientes estan asociados con el primer nodo de distribucion DNl comprobando la informacion memorizada en la base de datos DC (etapa 910). Sobre la base de esta informacion, la funcion de DCMF puede decidir redireccionar algunos (o la totalidad) de los clientes alejados del primer nodo de distribucion DN1.
Para esa finalidad, puede iniciar operativamente la funcion CCSF para enviar un iniciador de actualizacion de manifiesto a traves de los canales de control de estos clientes (etapa 911). Con el fin de cerciorarse de que los clientes no reciben su manifiesto actualizado desde el primer nodo de distribucion DN1 (por defecto) el iniciador de actualizacion de manifiesto puede incluir un URL asociado con el fichero de manifiesto nuevo o actualizado (que apunte, a modo de ejemplo, a un segundo nodo de distribucion DN2). La recepcion de las senales de iniciacion de actualizacion de manifiesto, senaliza al cliente que debe demandarse un fichero de manifiesto nuevo. A continuacion, puede enviar una demanda de fichero de manifiesto al URL asociado con el segundo nodo de distribucion DN2 referido en el iniciador de actualizacion de manifiesto (etapa 912). El segundo nodo de distribucion DN2 puede dar respuesta enviando el fichero de manifiesto demandado al cliente.
A la recepcion de este fichero de manifiesto, el cliente puede continuar el proceso de difusion en flujo demandando segmentos posteriores desde el segundo nodo de distribucion DN2 en lugar del primer nodo de distribucion DN1 (etapa 913). Puesto que el cliente ha recibido un fichero de manifiesto nuevo o actualizado, la funcion CDNCF puede actualizar la informacion del fichero de manifiesto asociada con ese cliente en la base de datos DC realizando la etapa segun se describe haciendo referencia a 903. De este modo, si en algun punto del futuro se produce un problema de sobrecarga la funcion CDNCF puede ser capaz de redireccionar el cliente de nuevo a otro nodo de distribucion.
Por lo tanto, en la forma de realizacion ilustrada en la Figura 9, un fichero de manifiesto que comprende la informacion de establecimiento de canal para establecer un canal de control de difusion en flujo entre el cliente y la funcion CCSF se memoriza en el nodo de distribucion en donde se memorizan los segmentos. Esta puesta en practica proporciona la ventaja operativa de que parte de la carga y de la complejidad de la funcion CDNCF se descarga a los nodos de distribucion. En la Figura 7, la funcion CDNCF aloja y/o genera los ficheros de manifiesto
5
10
15
20
25
30
35
40
45
50
55
60
65
de modo que para cada vez que se actualiza un fichero de manifiesto se anade carga a la funcion CDNCF. En algunas puestas en practica, p.ej., en caso de contenido en directo, pueden ocurrir con bastante frecuencia actualizaciones de manifiesto a la iniciativa del cliente, p.ej., una vez cada 30 segundos, con lo que se aumenta notablemente la carga sobre la funcion CDNCF. Por lo tanto, delegando la tarea de dar respuesta a la demanda de manifiesto, a la iniciativa del cliente, hacia el nodo de distribucion se puede realizar una reduccion considerable de la carga de la funcion CDNCF.
La Figura 10 ilustra un flujo de mensajes para uso en un sistema de difusion en flujo de contenidos en conformidad con otra forma de realizacion de la invencion. En particular, la Figura 10 ilustra un flujo de mensajes similar al de la Figura 7; sin embargo, en lugar de tener la funcionalidad DCN anadida a la funcion CDNCF, DCN se localiza en un nodo separado.
El proceso en la Figura 10 puede iniciarse con el usuario seleccionando un enlace o un video en un sitio web en donde el URL puede apuntar (p.ej., mediante una redireccion) a un fichero de manifiesto alojado en la funcion CDNCF (etapa 1000) y la transmision de una demanda HTTP GET por el cliente para obtener el fichero de manifiesto desde la funcion CDNCF (etapa 1001). La funcion CDNCF puede dar respuesta a esta demanda enviando el fichero de manifiesto al cliente. En este ejemplo, sobre la base de la informacion obtenida a partir de la funcion de equilibrado de la carga, la funcion CDNCF puede seleccionar un fichero de manifiesto que contiene referencias a segmentos memorizados en el primer nodo de distribucion DN1 (etapa 1002).
La funcion CDNCF puede enviar una notificacion al DCN, en particular, a la funcion DCMF en DCN, indicando que a un cliente particular (identificado por p.ej., su direccion IP) se le ha proporcionado un nuevo fichero de manifiesto nuevo o actualizado que comprende referencias a un nodo de distribucion particular o un conjunto de nodos de distribucion particulares (etapa 1003). La funcion DCMF puede memorizar la informacion del cliente (p.ej., la direccion IP del cliente) y la informacion del fichero de manifiesto (p.ej., el identificador del fichero de manifiesto, o Manifest ID, asociado con al menos parte de un tttulo de video y la informacion de localizacion del nodo de distribucion particular o del conjunto de nodos de distribucion que alojan los segmentos que son objeto de referencia por el fichero de manifiesto) para su uso futuro (etapa 1004) en la base de datos DC. En este caso, el identificador del fichero de manifiesto puede identificarse por un numero y los nodos de distribucion pueden identificarse por los identificadores de nodos de distribucion conocidos dentro de CDN.
El cliente puede realizar un analisis sintactico del fichero de manifiesto para obtener las localizaciones (p.ej., localizadores URLs) de los segmentos que constituyen el video (etapa 1005). Ademas, el cliente puede utilizar la informacion de establecimiento de canal en el fichero de manifiesto para establecer un canal para DCN (etapa 1006a). (El proceso de establecer el canal se describe en las Figuras 2 y 3 y por ello no se repite aqrn de nuevo).
Durante el establecimiento del canal de control de difusion en flujo, la funcion CCSF puede establecer una correccion de la demanda de establecimiento de canal con un cliente espedfico y un conjunto de nodos de distribucion asociados utilizando la informacion memorizada en la base de datos DC (etapa 1006b). En particular, la funcion CCSF puede consultar la base de datos DC para el cliente para el que se establece un canal de control de difusion en flujo (en donde el cliente puede identificarse p.ej., por su direccion IP) y asignar un identificador de canal de difusion en flujo unico (p.ej., el numero de puerto o, en caso de que se utilice WebSocket, un identificador WebSocket ID) a la entrada de la base de datos que pertenece al cliente. De este modo, las funciones en CDN, p.ej., CDNCF, DCMF y CCSF son capaces de relacionar una combinacion de cliente-canal espedfica a un conjunto de nodos de distribucion particular.
Una vez que se establece el canal de control de difusion en flujo, la funcion del cliente de difusion en flujo puede iniciar la demanda, la recepcion y la reproduccion de los segmentos obtenidos a partir del primer nodo de distribucion DN1 (etapa 1007). Durante el proceso de difusion en flujo, la funcion DCMF puede ejecutar un proceso de supervision para controlar las notificaciones de la red, p.ej., notificaciones de sobrecarga o fallo operativo de la red desde la funcion CDNCF, una funcion de equilibrado de carga asociada con la CDNCF o una funcion de supervision de la red. A modo de ejemplo, en algun punto en el tiempo, la funcion CDNCF que comprende o esta asociada con una funcion de equilibrado de carga para supervisar la carga de todos nodos de distribucion puede notificar que la carga en el nodo de distribucion DN1 alcanza un valor umbral (maximo) predeterminado (etapa 1008).
La funcion CDNCF puede enviar luego una notificacion de sobrecarga a la DCMF indicando que la carga en el primer nodo de distribucion DN1 se esta aproximando a un valor umbral (maximo) predeterminado. En una forma de realizacion, una notificacion de sobrecarga puede comprender informacion respecto al numero de clientes objeto de redireccion (etapa 1009). La funcion DCMF puede terminar los clientes que estan utilizando el primer nodo de distribucion DN1 comprobando la informacion del fichero de manifiesto en la base de datos DC (etapa 1010).
La funcion DCMF puede seleccionar luego los clientes objeto de redireccion e iniciar operativamente la funcion CCSF para enviar un iniciador de actualizacion de manifiesto a traves de los canales de control de difusion en flujo de estos clientes (etapa 1011). La recepcion del iniciador de actualizacion de manifiesto puede senalizar al cliente la demanda de un nuevo fichero de manifiesto enviando una demanda de manifiesto a la funcion CDNCF en una forma
5
10
15
20
25
30
35
40
45
50
55
60
65
similar a la descrita con referencia a la etapa 1001) (etapa 1012).
La funcion CDNCF puede recibir la demanda de manifiesto y generar o seleccionar un nuevo fichero de manifiesto adecuado para el cliente (etapa 1013) (p.ej., consultando la funcion de equilibrado de carga). En este caso, el fichero de manifiesto seleccionado contiene, a modo de ejemplo, enlaces a segmentos memorizados en un segundo nodo de distribucion DN2. El fichero de manifiesto seleccionado puede enviarse luego al cliente. A la recepcion del nuevo fichero de manifiesto, el cliente puede continuar el proceso de difusion en flujo demandando segmentos posteriores desde el segundo nodo de distribucion DN2 en lugar del primer nodo de distribucion DN1.
Puesto que el cliente ha recibido un fichero de manifiesto nuevo o actualizado, que hace referencia a segmentos alojados en un nodo de distribucion diferente (esto es, el segundo nodo de distribucion DN2 en lugar del primer nodo de distribucion DN1), la funcion CDNCF puede actualizar la entrada o las entradas en la base de datos DC asociadas con el cliente. Para hacerlo asf, la funcion CDNCF puede enviar una notificacion a la funcion DCMF en DCN de que a un cliente se la ha proporcionado un fichero de manifiesto nuevo o actualizado (en un modo similar al que se describe con referencia a la etapa 1003). Despues de recibir la notificacion, la funcion DCMF puede memorizar la informacion del cliente y la informacion del fichero de manifiesto en la base de datos DC (en un modo similar al que se describe con referencia a la etapa 1004). De este modo, la funcion CDNCF es capaz de gestionar posibles problemas de carga asociados con el segundo nodo de distribucion DN2.
Por lo tanto, en la forma de realizacion ilustrada en la Figura 10, las funciones para establecer y gestionar una funcion de control de difusion en flujo se ponen en practica en un nodo de red separado, el DCN, de modo que los cambios requeridos para la funcion CDNCF en CCN sean muy limitados y se puedan reutilizar las realizaciones de CDNCF existentes con lo que se limita el coste implicado cuando se anade una funcionalidad de canal de control de difusion en flujo a un nodo CDN. Ademas, si aumenta el numero de clientes y los canales de control de difusion en flujo activos asociados, solamente necesita ampliarse la capacidad de DCN y no la capacidad de la funcion CDNCF completa. Esta forma de realizacion proporciona, de este modo, una solucion escalable para gestionar grandes numeros de canales de control de difusion en flujo asociados con un nodo CDN.
La Figura 11 ilustra un flujo de mensajes para uso en un sistema de difusion en flujo de contenido en conformidad con otra forma de realizacion de la invencion. En particular, la Figura 11 ilustra un flujo de mensajes similar al representado en la Figura 7, sin embargo, en lugar de tener cada fichero de manifiesto comprendiendo solamente referencias a un nodo de distribucion unico, un fichero de manifiesto puede contener referencias a multiples nodos de distribucion. En esta forma de realizacion, la funcion CDNCF puede configurarse para crear y alojar el fichero de manifiesto.
El proceso puede iniciarse con un usuario seleccionando un enlace a un video en un sitio web en donde el URL apunta (p.ej., mediante una redireccion) a un fichero de manifiesto (etapa 1100) y la transmision de un adema HTTP GET por el cliente para obtener el fichero de manifiesto desde la funcion CDNCF (etapa 1101). Habiendo recibido la demanda de manifiesto desde el cliente, la funcion CDNCF puede crear un fichero de manifiesto nuevo o seleccionar uno ya existente que comprenda referencias a segmentos en diferentes nodos de distribucion (1102). A modo de ejemplo, en una forma de realizacion, el fichero de manifiesto puede comprender una referencia a segmentos de baja calidad alojados en un primer nodo de distribucion DN1 y a segmentos de alta calidad alojados en un segundo de nodo de distribucion DN2. La funcion CDNCF puede utilizar informacion de carga (generada por un funcion de equilibrado de carga) asociada con los nodos de distribucion en CDN y, de manera opcional, la informacion de localizacion del cliente (p.ej., la direccion IP) con el fin de seleccionar nodos de distribucion, que sean los mas adecuados para la distribucion de (parte de) los segmentos demandados al cliente. En este caso, el fichero de manifiesto puede comprender referencias a al menos un primer nodo de distribucion DN1 y un segundo nodo de distribucion DN2.
La funcion CDNCF puede enviar el fichero de manifiesto al cliente (etapa 1103) y memorizar la informacion del cliente (p.ej., su direccion IP) y la informacion del fichero de manifiesto (p.ej., la direccion IP del cliente) y la informacion del fichero de manifiesto (p.ej., el identificador del fichero de manifiesto, o Manifest ID, asociado con al menos parte de un tftulo de video, y la informacion de localizacion del nodo de distribucion particular o del conjunto de nodos de distribucion que alojan los segmentos que son objeto de referencia por el fichero de manifiesto), en este caso, el primero y el segundo nodo de distribucion D1 y D2) en la base de datos DC (etapa 1104). En este caso, el identificador del fichero de manifiesto puede identificarse por un numero y los nodos de distribucion pueden identificarse por los identificadores de nodos de distribucion conocidos dentro de CDN.
El cliente puede realizar un analisis sintactico del fichero de manifiesto para obtener las localizaciones de los segmentos que constituyen el video (etapa 1105) y utilizar la informacion de establecimiento de canal en el fichero de manifiesto para establecer un canal de control de difusion en flujo entre cliente y la CCSF (etapa 1106a). (El proceso de establecer el canal se describe en las Figuras 2 y 3 y por ello no se repite aqrn de nuevo).
Durante el establecimiento del canal de control de difusion en flujo la funcion CCSF puede establecer una correccion de la demanda de establecimiento de canal con un cliente espedfico y un conjunto de nodos de distribucion asociados utilizando la informacion memorizada en la base de datos DC (etapa 1106b). En particular, la funcion
5
10
15
20
25
30
35
40
45
50
55
60
65
CCSF puede consultar la base de datos DC para el cliente para el que se establece un canal de control de difusion en flujo (en donde el cliente puede identificarse p.ej., por su direccion IP) y asignar un identificador de canal de difusion en flujo unico (p.ej., el numero de puerto, o en caso de que se utilice WebSocket, un identificador WebSocket ID) a la entrada de base de datos que pertenece al cliente. De este modo, las funciones en el nodo CDN pueden relacionarse con una combinacion de cliente-canal espedfica para un conjunto de nodos de distribucion particular.
Una vez que se establece el canal de control de difusion en flujo, el cliente puede iniciar el proceso de difusion en flujo demandado, recibiendo y ejecutando segmentos que tienen su origen en el primer y segundo nodo de distribucion (etapa 1107). Durante el proceso de difusion en flujo, en algun punto en el tiempo, la funcion CDNCF que comprende o esta asociada con una funcion de equilibrado de carga para supervisar la carga de los nodos de distribucion dentro del nodo CDN, pueden notificar que la carga en el primer nodo de distribucion DN1 alcanza o se proxima a un valor umbral (maximo) predeterminado (etapa 1108). La funcion CDNCF puede iniciar luego la funcion DCMF para comprobar que clientes estan asociados con el primer nodo de distribucion DN1 comprobando la informacion del fichero de manifiesto en la base de datos DC (etapa 1109). La funcion DCMF puede determinar entonces que clientes requieren una actualizacion del manifiesto e iniciar operativamente la funcion CCSF para iniciar la actualizacion de manifiesto a traves de los canales de control de esos clientes (etapa 1110).
El iniciador de actualizacion de manifiesto puede senalizar al cliente que necesita demandar un fichero de manifiesto nuevo o actualizado (etapa 1111) enviando una demanda de manifiesto por la funcion CDNCF (vease etapa 1101). La funcion CDNCF recibe la demanda de manifiesto y crea o selecciona un nuevo fichero de manifiesto adecuado para el cliente (vease etapa 1102) (etapa 1012). En este caso, el fichero de manifiesto nuevo o actualizado puede sustituir, a modo de ejemplo, los URLs asociados con el primer nodo de distribucion DN1 con un URLs asociados con otro nodo de distribucion DN que alojan los mismos segmentos (p.ej., el tercer nodo de distribucion DN3). Los URLs asociados con el nodo de distribucion DN2 no se sustituyen puesto que solamente el primer nodo de distribucion DN1 estaba en peligro de llegar a sobrecargarse. La funcion CDNCF puede enviar el fichero de manifiesto nuevo o actualizado al cliente (etapa 1113), que puede actualizar su lista (interna) de segmentos y continuar el proceso de difusion en flujo demandando segmentos listados en el manifiesto nuevo o actualizado.
Puesto que el cliente ha recibido un fichero de manifiesto nuevo o actualizado, la funcion CDNCF puede actualizar la informacion de fichero de manifiesto asociada con ese cliente en la base de datos DC realizado la etapa segun se describe con referencia 1104. De este modo, si en algun punto del futuro se produce un problema de sobrecarga, la funcion CDNCF puede ser capaz de redireccionar el cliente de nuevo a otro nodo de distribucion.
Por lo tanto, la forma de realizacion ilustrada en la Figura 11 proporciona la ventaja de que los segmentos objeto de referencia por un manifiesto unico pueden distribuirse entre multiples nodos de distribucion, en donde cada nodo de distribucion aloja solamente un subconjunto de todos los segmentos. Una ventaja de que lo antecede es que permite a un CDN distinguir entre diferentes tipos de segmentos. En el contenido segmentado, algunos segmentos son mas populares (mas frecuentemente demandados) que otros segmentos. A modo de ejemplo, en un tftulo de video segmentado temporal, los segmentos anteriores suelen ser mas frecuentemente demandados que los segmentos mas reciente. En otro ejemplo, un tftulo de video puede tener segmentos relacionados con diferentes calidades de video, en donde algunas calidades seran mas populares que otras. En tal caso, un CDN podna alojar los segmentos mas populares en mas nodos de distribucion que los segmentos menos populares, proporcionando asf una escalabilidad adicional y mas alta eficiencia.
La Figura 12 ilustra un sistema de difusion en flujo de contenido en conformidad con otra forma de realizacion de la invencion. En particular, la Figura 12 ilustra un sistema de distribucion de contenido basado en CDN que es similar al descrito con referencia a la Figura 6. En esta forma de realizacion, sin embargo, el sistema comprende al menos dos CDNs interconectados. En particular, el sistema de difusion en flujo de contenido comprende un primer CDN 1202 (tambien referido como CDN de flujo ascendente) interconectado por intermedio de una interfaz de interconexion de CDN 1264 a al menos un segundo CDN 1204 (tambien referido como el CDN de flujo descendente) en donde cada CDN esta configurado para proporcionar un control, a la iniciativa de la red, de procesos de difusion en flujo entre uno o mas nodos de distribucion en CDN y uno o mas clientes. El control a iniciativa de la red puede realizarse sobre la base de la funcionalidad del canal de control de difusion en flujo descrito con referencia a las Figuras 2 a 5.
El sistema de distribucion de contenidos puede comprender, ademas, en una fuente de contenidos 1201 conectada mediante una red de transporte 600 a uno o mas terminales 1204 que alojan un cliente 1203. La fuente de contenido puede realizarse con un sistema de proveedores de contenidos CPS, un sistema de preparacion de contenidos u otro CDN. Un sistema CPS puede configurarse para ofrecer contenido, p.ej., un tftulo de video a consumidores, que pueden adquirir y recibir el contenido utilizando un cliente que comprende una funcion de difusion en flujo multimedia 1252 que procesa el flujo para reproduccion por una funcion de reproduccion de video 1251.
De forma similar a la Figura 6, un CDN puede comprender nodos de distribucion 1211, 1212, 1215 y al menos un CCN 1210,1223. Cada nodo de distribucion puede comprender o estar asociado con un controlador 1230,1231, 1234 y una memoria cache 1232,1233, 1235 para memorizar contenidos. Cada CCN, puede comprender o puede estar asociado con un nodo de ingestion (o funcion de origen de contenido, COF) 1220,1223 para controlar la
5
10
15
20
25
30
35
40
45
50
55
60
65
ingestion operativa contenido procedente de una fuente exterior, p.ej., un proveedor de contenidos u otro CDN, una base de datos de localizacion de contenidos 1222,1225 para mantener informacion sobre en donde se memorizan contenidos dentro de un CDN y una funcion de control de CDN (CDNCF) 1221,1224 para controlar la distribucion de una o mas copias del contenido a los nodos de distribucion o para redireccionar a los clientes a nodos de distribucion adecuados (un proceso tambien conocido como enrutamiento de demandas). Un consumidor puede adquirir contenido, p.ej., tttulo de video, desde un sistema CPS 1260 enviando una demanda a un portal web (WP) 1261, que esta configurado para proporcionar referencias de tftulos identificando los elementos de contenidos, susceptibles de compra, en una forma similar a la descrita con referencia a la Figura 6.
La funcion CDNCF puede gestionar las localizaciones en donde pueden recuperarse segmentos utilizando la base de datos de localizaciones de contenidos 1222,1225. Ademas, un nodo CDN puede comprender un nodo de continuidad de distribucion (DCN) 1213,1216 que esta configurado para establecer y gestionar canales de control de difusion en flujo asociados con clientes y para mantener una base de datos que comprende informacion del cliente e informacion del fichero de manifiesto para los nodos de distribucion a los que estan conectados estos clientes. El nodo DCN puede configurarse como un DCN autonomo o integrarse en una funcion CDNCF.
El nodo DCN puede comprender una funcion de gestion de continuidad de distribucion (DCMF) 1240,1243 para supervisar las notificaciones que tienen su origen en la funcion de demanda-enrutamiento (RR) de la funcion de CDNCF, una funcion de servidor para canales de control (CCSF) 1241,1244 que supervisa las demandas de establecimiento de canal procedentes de clientes y para establecer un canal de control de difusion en flujo con una funcion de canales de control 1250 en el cliente y, una base de datos de continuidad de distribucion (DC) 1242,1245 en o asociada con el nodo DCN para memorizar informacion del cliente (p.ej., direccion IP de un cliente) y la informacion de fichero de manifiesto (esto es, identificadores de segmentos (p.ej., nombres de ficheros) e informacion de localizaciones (p.ej., URLs)) asociados con al menos parte de los nodos de distribucion que alojan estos segmentos.
La funcion DCMF puede supervisar la notificacion de la red, p.ej., notificaciones de sobrecarga o fallo operativo con origen desde la funcion de demanda-enrutamiento (RR) de la funcion CDNCF, una funcion de sobrecarga separada en el nodo CDN o una funcion de supervision de red y para iniciar un proceso de actualizacion de ficheros de manifiesto en respuesta a la recepcion de dicha notificacion. Los detalles del proceso de actualizacion del fichero de manifiesto se describiran, con mas detalle, haciendo referencia a la Figura 13.
En el sistema de distribucion de contenidos de la Figura 12, el nodo CDN de flujo ascendente puede proporcionar parte de la distribucion de segmentos a un cliente para el CDN de flujo descendente. A modo de ejemplo, en una forma de realizacion, segmentos de baja calidad pueden situarse y distribuirse por un primer CDN A (configurado, p.ej., para distribucion de contenido a dispositivos moviles) y segmentos de alta calidad pueden localizarse y distribuirse por un segundo CDN B (configurado p.ej., para distribucion de segmentos de alta calidad a dispositivos multimedia caseros que soportan tecnologfa HDTV).
Cuando se proporciona parte de la distribucion de los segmentos a un CDN de flujo descendente, el CDN de flujo ascendente (o en particular, la funcion CDNCF del CDN de flujo ascendente) puede iniciar un proceso para generar un fichero de manifiesto que comprende referencias a uno o mas nodos de distribucion en el primer CDN A y referencias a uno o mas nodos de distribucion en el segundo CDN B. Dicho fichero de manifiesto puede referirse como un fichero de manifiesto inter-CDN. El fichero de manifiesto inter-CDN puede comprender, ademas, informacion de establecimiento de canal para establecer un canal de control de difusion en flujo entre el cliente y el CDN A de flujo ascendente.
Durante el proceso de generacion del fichero de manifiesto inter-CDN, se puede intercambiar informacion entre nodos CDNs por intermedio de una interfaz de interconexion 1264. En particular, durante la generacion del fichero de manifiesto inter-CDN, el CDN de flujo ascendente puede demandar al CDN de flujo descendente informacion de localizacion con respecto a uno o mas segmentos respecto a donde se proporcionan para el CDN de flujo descendente. En respuesta, el CDN de flujo descendente puede seleccionar un nodo de distribucion que aloja los segmentos demandados sobre la base de la informacion contextual con respecto al cliente. A modo de ejemplo, el nodo CDN de flujo descendente puede seleccionar un nodo de distribucion, que esta geograficamente mas proximo a la localizacion del cliente. Esta informacion es posteriormente enviada a la funcion CDNCF del CDN de flujo ascendente para la generacion del fichero de manifiesto inter-CDN. Por lo tanto, el sistema de distribucion de contenido en la Figura 13 esta configurado para generar, de forma dinamica, un fichero de manifiesto inter-CDN "personalizado"
Una vez que un fichero de manifiesto inter-CDN es generado y reenviado a un cliente, la funcion del canal de control en el cliente, puede establecer un canal de control de difusion en flujo con la funcion CCSF en el DCN del CDN de flujo ascendente utilizando la informacion de establecimiento de canal en el fichero de manifiesto inter-CDN e iniciar la demanda y reproduccion de segmentos.
Durante el proceso de difusion en flujo, la funcion DCMF puede recibir una notificacion de red, p.ej., una notificacion de sobrecarga o una notificacion de fallo operativo, desde la funcion CDNCF y determinar que el cliente debe
5
10
15
20
25
30
35
40
45
50
55
60
65
redirigirse a uno o mas otros nodos de distribucion. Una notificacion de red puede relacionarse con una situacion de problema de red en el CDN de flujo ascendente o el CDN de flujo descendente. En este ultimo caso, la funcion CDNCF del CDN de flujo descendente puede enviar una notificacion de red por intermedio de la interfaz de interconexion 1264 a la funcion CDNCF del CDN de flujo ascendente.
La Figura 13 ilustra un flujo de mensajes para uso en un sistema de difusion en flujo de contenido en conformidad con otra forma de realizacion de la invencion. En particular, la Figura 13 ilustra un flujo de mensajes para uso en una red de distribucion de contenido segun se ilustra en la Figura 12, en donde el fichero de manifiesto puede comprender referencias a segmentos alojados en diferentes nodos de distribucion asociados con diferentes CDNs.
El proceso puede iniciarse con un usuario seleccionando un enlace a un video en un sitio web en donde el URL apunta (p.ej., mediante una redireccion) a un fichero de manifiesto alojado en una primera funcion CDNCF asociada con un primer CDN A (etapa 1300). Este CDN puede referirse tambien como el CDN de flujo ascendente. A la seleccion, el cliente puede enviar una demanda HTTP GET para obtener el fichero de manifiesto desde la funcion CDNCF de CDN A (etapa 1301).
Despues de haber recibido la demanda de manifiesto desde el cliente, la primera funcion CDNCF puede iniciar un proceso para crear un nuevo fichero de manifiesto o actualizar un fichero de manifiesto existente, en donde el fichero de manifiesto puede comprender referencias a segmentos en diferentes nodos de distribucion asociados con diferentes CDNs (etapa 1302). A modo de ejemplo, en una forma de realizacion, segmentos de baja calidad pueden localizarse y distribuirse por un primer CDN A (configurado, p.ej., para la distribucion de contenido a dispositivos moviles). Este nodo CDN puede referirse como el CDN de flujo ascendente. Ademas, segmentos de alta calidad pueden localizarse y distribuirse por un segundo CDN B (configurado, p.ej., para la distribucion de segmentos de alta calidad a dispositivos multimedia caseros que soportan tecnologfa hDtV). Este CDN puede referirse como el CDN de flujo descendente. Un fichero de manifiesto que comprende referencias a al menos un primer nodo de distribucion DN1 asociado con un primer CDN A y un segundo nodo de distribucion DN2 asociado con CDN B pueden referirse con un fichero de manifiesto inter-CDN. El fichero de manifiesto inter-CDN puede comprender, ademas, informacion de establecimiento de canal para establecer un canal de control de difusion en flujo entre el cliente y la primera funcion CDNCF asociada con el CDN A de flujo ascendente.
En una forma de realizacion, un fichero de manifiesto inter-CDN puede generarse sobre la base de un proceso en donde la primera funcion CDNCF del CDN A de flujo ascendente demanda a la segunda CDNCF del CDN B de flujo descendente proporcionar referencias para localizadores de aparcamiento de un numero predeterminado de segmentos que deben distribuirse al cliente por CDN B.
La primera funcion CDNCF puede enviar entonces el fichero de manifiesto inter-CDN al cliente (etapa 1303) en donde la primera funcion CDNCF puede memorizar informacion del cliente (p.ej., su direccion IP) e informacion del fichero de manifiesto, que comprende el identificador del fichero de manifiesto, o Manifest ID, asociado con al menos parte de un tftulo de video, y la informacion de localizacion del nodo de distribucion particular o del conjunto de nodos de distribucion que alojan los segmentos que son objeto de referencia por el fichero de manifiesto, que se asocian con el primer CDN A y un nodo de distribucion o un conjunto particular de nodos de distribucion asociados con el segundo CDN B en la base de datos DC asociada con la primera funcion CDNCF (etapa 1304). En este caso, los segmentos pueden identificarse por un nombre de fichero y los nodos de distribucion pueden identificarse por identificadores de nodos de distribucion. En este caso, el identificador del fichero de manifiesto puede identificarse por un numero y los nodos de distribucion pueden identificarse por identificadores de nodos de distribucion conocidos dentro del CDN.
Por lo tanto, durante la generacion del fichero de manifiesto inter-CDN, la comunicacion entre la primera y la segunda funcion CDNCF tiene lugar de modo que - aunque la segunda funcion CDNCF no tenga conocimiento de todos los segmentos en el fichero de manifiesto inter-CDN -, la segunda funcion CDNCF tiene conocimiento de que un numero predeterminado de segmentos localizados en un nodo de distribucion o un conjunto de nodos de distribucion particular puede demandarse por el cliente en un futuro (proximo). Por lo tanto, la segunda funcion CDNCF puede memorizar informacion inter-CDN que comprende los nodos de distribucion en CDN de flujo descendente (en este ejemplo, el segundo nodo de distribucion DN2) junto con una referencia al CDN de flujo ascendente (en este caso, la primera funcion CDNCF) en la base de datos DC asociada con el segundo CDN B de modo que sea capaz de notificar cualquier problema de la red p.ej., problemas de carga o de fallos operativos con o desde estos nodos de distribucion para la primera CDNCF (etapa 1305).
El cliente puede realizar un analisis sintactico del fichero de manifiesto inter-CDN con el fin de obtener las localizaciones de los segmentos que constituyen el video (etapa 1306) y utilizar la informacion de establecimiento de canal en el fichero de manifiesto para establecer un canal de control de difusion en flujo entre la primera funcion CDNCF y el cliente (etapa 1307). (El proceso de establecer el canal se describe en las Figuras 2 y 3 y por ello no se repite aqrn de nuevo).
Durante el establecimiento del canal de control de difusion de flujo, la funcion CCSF asociada con el primer CDN 1 puede establecer una correccion de la demanda de establecimiento de canal por un cliente espedfico y un conjunto
5
10
15
20
25
30
35
40
45
50
55
60
65
asociado de nodos de distribucion utilizando la informacion memorizada en la primera base de datos DC (etapa 1309). En particular, la funcion CCSF puede consultar la base de datos DC para el cliente para el que se establece un canal de control de difusion en flujo (en donde el cliente puede identificarse p.ej., por su direccion IP) y asignar un identificador de canal de difusion en flujo unico (p.ej., el numero de puerto o en caso de que se utilice WebSocket, un WebSocket ID) para la entrada de base de datos que pertenece al cliente. De este modo, las funciones en el primer CDN1 son capaces de relacionar una combinacion de cliente-canal espedfica con un conjunto particular de nodos de distribucion. Despues del establecimiento del canal de control de difusion en flujo, el cliente puede iniciar el proceso de difusion en flujo demandando, recibiendo y ejecutando segmentos obtenidos a partir del primer nodo de distribucion DN1 asociado con el primer CDN A (de flujo ascendente) y el segundo nodo de distribucion DN2 asociado con el segundo CDN B (flujo descendente) CDN B (etapa 1308).
Durante el proceso de difusion en flujo, en alguno punto en el tiempo, la segunda funcion CDNCF, que esta supervisando sus propios nodos de distribucion, puede notificar un problema de la red, p.ej., un fallo operativo de la red en el segundo nodo de distribucion DN2 o que la carga en el segundo nodo de distribucion DN2 alcanza o se aproxima a un valor umbral (maximo) penado (etapa 1309). A continuacion, sobre la base de la informacion de inter- CDN en la base de datos DC, la segunda funcion CDNCF puede notificar el problema de la red a la primera CDNCF enviando una notificacion de red, p.ej., una notificacion de sobrecarga o una notificacion de fallo operativo a la primera funcion CDNCF. La Nota sobrecarga puede senalizar a la primera funcion CDNCF que al menos parte de las referencias a los nodos de distribucion en el segundo CDN, en particular, en las referencias a los nodos de distribucion indicados en el fichero de manifiesto inter-CDN, necesitan actualizarse (etapa 1310).
Por lo tanto, a la recepcion de una notificacion de red desde la segunda funcion CDNCF, la primera funcion CDNCF inicia operativamente la DCMF para comprobar a que clientes se les ha enviado un fichero de manifiesto inter-CDN que contiene referencias al segundo nodo de distribucion DN2 (etapa 1311) sobre la base de la informacion de fichero de manifiesto memorizada en la base de datos DC asociada con el primer CDN A. la funcion DCMF puede determinar entonces a que clientes redireccionar e iniciar operativamente la funcion CCSF para enviar un iniciador de actualizacion de fichero de manifiesto por intermedio de los canales de control de los clientes, que necesitan redireccionarse (etapa 1312). A la recepcion del iniciador de actualizacion de manifiesto, el cliente demandara un nuevo fichero de manifiesto (etapa 1313) enviando una demanda de fichero de manifiesto a la primera funcion CDNCF (similar a la etapa 1301).
La primera funcion CDNCF recibe la demanda de manifiesto y generara un fichero de manifiesto nuevo o actualizado adecuado para el cliente (etapa 1314) en cooperacion con la segunda funcion CDNCF en una forma similar a la descrita con anterioridad haciendo referencia a la etapa 1302. A modo de ejemplo, en una forma de realizacion, la segunda funcion CDNCF puede sustituir los URLs que se refieren a los nodos de distribucion (casi) sobrecargados en el segundo CDN (en este caso, el segundo nodo de distribucion) con URLs para otro nodo de distribucion, p.ej., un cuarto nodo de distribucion DN4 que aloja los mismos segmentos y para enviar estas referencias a la primera funcion CDNCF. Los URLs que se refieren al nodo de distribucion DN1 en el primer CDN A no se sustituyen puesto que para ese nodo de distribucion no se recibio ninguna senalizacion de sobrecarga por la primera funcion CDNCF.
La primera funcion CDNCF puede enviar el fichero de manifiesto inter-CDN actualizado al cliente (etapa 1315), que puede actualizar su lista interna de segmentos sobre la base del fichero de manifiesto actualizado y continuar la difusion en flujo realizando demandas de los segmentos posteriores a partir de los URLs indicados en el nuevo fichero de manifiesto.
Puesto que el cliente ha recibido un fichero de manifiesto nuevo o actualizado, la primera funcion CDNCF puede actualizar la informacion de fichero de manifiesto asociada con ese cliente en la base de datos DC realizando la etapa segun se describe con referencia a 1304. Ademas, la segunda funcion CDNCF puede actualizar la informacion inter-CDN que comprende los nodos de distribucion en el CDN de flujo descendente (en este ejemplo, el cuarto nodo de distribucion DN4) junto con una referencia al CDN de flujo ascendente (en este caso, la primera funcion CDNCF) en la base de datos DC asociada con el segundo CDN B en un modo similar al descrito con referencia a la etapa 1305. De este modo, si en algun punto en el futuro ocurre un problema de sobrecarga en CDN B, la segunda funcion CDNCF puede ser capaz de redireccionar el cliente de nuevo a otro nodo de distribucion.
Por lo tanto, la forma de realizacion ilustrada en la Figura 13 proporciona la ventaja de que permite que el contenido segmentado sea distribuido entre multiples CDNs, en donde cada CDN aloja solamente un subconjunto de todos los segmentos. Esta forma de realizacion proporciona el mismo tipo de ventajas descritas con referencia a la Figura 11; sin embargo, en este caso, diferentes nodos de distribucion pueden distribuirse a traves de multiples CDNs. Una ventaja adicional de esta forma de realizacion es que permite a un CDN de flujo ascendente derivar alguna carga de trabajo para otro CDN de flujo descendente. Esta forma de realizacion permite, ademas, el uso de nodos CDNs especializados. A modo de ejemplo, en una forma de realizacion, un primer nodo CDN puede configurarse y optimizarse para distribuir a dispositivos moviles, alojando segmentos en su mayona de mas baja calidad, mientras que un segundo nodo CDN puede configurarse y optimizarse para distribuir a un dispositivo de reproduccion HD, que aloja segmentos de mas alta calidad en su mayona.
Conviene senalar que en las formas de realizacion de CDN anteriormente descritas, en lugar de enviar un iniciador
5
10
15
20
25
30
35
de manifiesto de actualizacion a un cliente que responde demandado un fichero de manifesto nuevo o actualizado, (parte de) del fichero de manifiesto nuevo o actualizado puede enviarse directamente al cliente por intermedio del canal de control de difusion en flujo para el cliente.
La Figura 14 ilustra, un fichero de manifiesto en conformidad con una forma de realizacion de la invencion. En particular, la Figura 14 muestra una forma de realizacion de un fichero de manifiesto que comprende referencias, p.ej., URLs, a un nodo de distribucion configurado para distribuir un conjunto particular de segmentos. En este ejemplo particular, el fichero de manifiesto puede comprender referencias a dos conjuntos diferentes de segmentos, p.ej., segmentos de baja y de alta tasa binaria, relacionados con el mismo contenido memorizado en un nodo de distribucion. El fichero de manifiesto puede comprender, ademas, informacion de establecimiento de canal. En una forma de realizacion, la informacion de establecimiento de canal puede comprender un parametro objetivo de canal 1400 que proporciona una referencia al nodo de red que comprende una funcion de control de difusion en flujo (o en el caso de CDN, una funcion de servidor para canales de control). Ademas, en otra forma de realizacion, la informacion de establecimiento de canal puede comprender parametros de canal 1402, esto es, parametros utilizados por la funcion de servidor para canales de control/funciones de control de difusion en flujo. A modo de ejemplo, en el caso de WebSocket, los parametros pueden referirse al uso de subprotocolos de WebSocket, version de WebSocket, etc.
Ha de entenderse que cualquier caractenstica descrita en relacion con cualquier forma de realizacion puede utilizarse por sf sola, o en combinacion con otras caractensticas descritas y puede utilizarse tambien en combinacion con una o mas caractensticas de cualquier otra de las formas de realizacion, o cualquier combinacion de cualquier otra de las formas de realizacion. Una forma de realizacion puede ponerse en practica como un producto de programa informatico para uso con un sistema informatico. Los programas del producto informatico definen funciones de las formas de realizacion (incluyendo los metodos aqrn descritos) y pueden contenerse en una diversidad de soportes de memorizacion legibles por ordenador por ordenador. Soportes de memorizacion legibles por ordenador ilustrativos incluyen, sin limitacion, a: (i) soportes de memorizacion no susceptibles de escritura (p.ej., dispositivos de memoria de solamente lectura dentro de un ordenador tal como discos CD-ROM legibles por una unidad de CD-ROM, memoria instantanea, circuitos integrados de memoria ROM o cualquier tipo de memoria de semiconductores no volatil de estado solido) en donde se memoriza de forma permanente la informacion; y (ii) soportes de memorizacion susceptibles de escritura (p.ej., discos flexibles dentro de una unidad de disquete o una unidad de disco duro o cualquier tipo de memoria de semiconductores de acceso aleatorio de estado solido) en donde se memoriza informacion modificable. La invencion no esta limitada a las formas de realizacion anteriormente descritas, que pueden variarse dentro del alcance de lo establecido en las reivindicaciones adjuntas.

Claims (14)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    REIVINDICACIONES
    1. Un metodo para permitir un control, a iniciativa de la red, de la difusion en flujo de contenido segmentado desde un nodo de distribucion (232) a al menos un cliente (230), comprendiendo dicho metodo:
    recibir (204) un primer fichero de manifiesto que comprende uno o mas identificadores de segmentos e informacion de localizacion que sirve para localizar uno o mas nodos de distribucion de contenido configurados para transmitir uno o mas segmentos asociados con dichos uno o mas identificadores a dicho al menos un cliente;
    proporcionar (210) informacion de establecimiento de canal al cliente; y
    establecer al menos un canal de control de difusion en flujo entre dicho al menos un cliente y una funcion de servidor para canales de control asociada con dicho nodo de distribucion sobre la base de dicha informacion de establecimiento de canal proporcionada, estando dicho al menos un cliente configurado para recibir (224) al menos un mensaje de actualizacion del fichero de manifiesto por intermedio de dicho canal de control de difusion en flujo.
  2. 2. El metodo segun la reivindicacion 1, en donde dicho establecimiento se establece en respuesta a la recepcion de dicho primer fichero de manifiesto a nivel del cliente.
  3. 3. El metodo segun la reivindicacion 1 o 2, que comprende:
    supervisar dicho canal de control de difusion en flujo para al menos un mensaje de actualizacion del fichero de manifiesto.
  4. 4. El metodo segun cualquiera de las reivindicaciones 1 a 3, que comprende: detectar un mensaje de actualizacion del fichero de manifiesto;
    recuperar al menos parte de un segundo fichero de manifiesto en respuesta a la deteccion de dicho mensaje de actualizacion del fichero de manifiesto.
  5. 5. El metodo segun cualquiera de las reivindicaciones 1 a 4, en donde al menos parte de dicha informacion de establecimiento de canal se proporciona a dicho cliente en dicho primer fichero de manifiesto.
  6. 6. El metodo segun cualquiera de las reivindicaciones 1 a 5, en donde dicha informacion de establecimiento de canal comprende informacion de localizacion de servidor que sirve para localizar dicha funcion de servidor para canales de control en la red.
  7. 7. El metodo segun cualquiera de las reivindicaciones 1 a 6, en donde dicho mensaje de actualizacion del fichero de manifiesto comprende al menos parte de un segundo fichero de manifiesto o en donde dicho mensaje de actualizacion del fichero de manifiesto comprende informacion de localizacion del fichero de manifiesto para localizar y para demandar al menos parte de dicho segundo fichero de manifiesto.
  8. 8. El metodo segun cualquiera de las reivindicaciones 1 a 7, en donde dicho contenido segmentado se distribuye a dicho al menos un cliente sobre la base de un protocolo de difusion en flujo basado en HTTP; y/o en donde dicho canal de control de difusion en flujo se establece sobre la base de un protocolo WebSocket, un protocolo SIP, un protocolo XMPP y/o sus combinaciones.
  9. 9. El metodo segun la reivindicacion 1, en donde al menos parte de dicha informacion de establecimiento del canal se proporciona a dicho cliente en un mensaje que es distinto del fichero de manifiesto.
  10. 10. Un dispositivo de procesamiento de contenido que comprende un cliente (230) para controlar la recepcion de contenido segmentado transmitido a partir de al menos un nodo de distribucion, estando dicho primer nodo de distribucion (234) asociado con una primera funcion de servidor para canales de control, con dicho cliente configurado para:
    transmitir (202) a dicho al menos un nodo de distribucion una demanda de distribucion de contenido segmentado;
    recibir (204) un fichero de manifiesto que comprende uno o mas identificadores de segmentos e informacion de localizacion para localizar uno o mas nodos de distribucion de contenido configurados para transmitir uno o mas segmentos asociados con dichos identificadores de segmentos al cliente;
    proporcionar (210) informacion de establecimiento de canal; y
    establecer un canal de control de difusion en flujo entre el cliente y dicha primera funcion de servidor para canales de control sobre la base de dicha informacion de establecimiento de canal,
    5
    10
    15
    20
    25
    30
    35
    40
    45
    recibir (224) al menos un mensaje de actualizacion del fichero de manifiesto a partir de dicha primera funcion de servidor para canales de control por intermedio de dicho canal de control de difusion en flujo.
  11. 11. Un dispositivo de procesamiento de contenido segun la reivindicacion 10, en donde dicha informacion de establecimiento de canal esta incluida en dicho fichero de manifiesto.
  12. 12. Una funcion de servidor para canales de control asociada con al menos un nodo de distribucion (234) para permitir un control, a iniciativa de la red, de la difusion en flujo de contenido segmentado a partir de dicho nodo de distribucion a uno o mas clientes, estando dicha funcion de servidor para canales de control configurada para:
    recibir (202) al menos una demanda para la distribucion de contenido segmentado para dicho uno o mas clientes;
    generar al menos un fichero de manifiesto que comprenda uno o mas identificadores de segmentos e informacion de localizacion que sirva para localizar uno o mas nodos de distribucion de contenido configurados para transmitir uno o mas segmentos asociados con dichos identificadores de segmentos a dichos uno o mas clientes e informacion de establecimiento de canal;
    transmitir (204) dicho primer fichero de manifiesto a al menos uno de dichos uno o mas clientes; y
    participar en el establecimiento (208, 210) de al menos un primer canal de control de difusion en flujo entre dicho al menos un cliente y dicha funcion de servidor para canales de control, estando dicho establecimiento basado en dicha informacion de establecimiento de canal; y dicha funcion de servidor para canales de control estando configurada, ademas, para generar un mensaje de actualizacion del fichero de manifiesto y para transmitir (224) dicho mensaje por intermedio de dicho primer canal de control de difusion en flujo a dicho cliente.
  13. 13. Una funcion de servidor para canales de control segun la reivindicacion 12, en donde la generacion de dicho al menos un fichero de manifiesto comprende:
    proporcionar uno o mas primeros identificadores de segmentos y primera informacion de localizacion para servir para localizar uno o mas nodos de distribucion del contenido en una primera red de distribucion de contenido (CDN1);
    demandar a una segunda red de distribucion de contenido uno o mas segundos identificadores de segmentos y una segunda informacion de localizacion que sirva para localizar uno o mas nodos de distribucion de contenido en dicha segunda red de distribucion de contenido (CDN2);
    generar dicho fichero de manifiesto sobre la base de al menos parte de dichos uno o mas primeros y segundos identificadores de segmentos y primera y segunda informacion de localizacion, respectivamente.
  14. 14. Un producto de programa informatico que comprende partes de codigo informatico configuradas para, cuando se ejecutan en la memoria de un ordenador, ejecutar las etapas del metodo segun una cualquiera de las reivindicaciones 1 a 9.
ES12818785.3T 2011-12-29 2012-12-27 Control de flujo de contenido tratado inicialmente en red Active ES2586818T3 (es)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
EP11196049 2011-12-29
EP11196049 2011-12-29
EP12156141 2012-02-20
EP12156141 2012-02-20
PCT/EP2012/076938 WO2013098317A1 (en) 2011-12-29 2012-12-27 Network-initiated content streaming control

Publications (1)

Publication Number Publication Date
ES2586818T3 true ES2586818T3 (es) 2016-10-19

Family

ID=47603565

Family Applications (1)

Application Number Title Priority Date Filing Date
ES12818785.3T Active ES2586818T3 (es) 2011-12-29 2012-12-27 Control de flujo de contenido tratado inicialmente en red

Country Status (10)

Country Link
US (2) US9723047B2 (es)
EP (2) EP2798816B1 (es)
JP (2) JP5977838B2 (es)
KR (1) KR101691709B1 (es)
CN (1) CN104137505B (es)
ES (1) ES2586818T3 (es)
HK (1) HK1200995A1 (es)
HU (1) HUE036024T2 (es)
PL (1) PL2798816T3 (es)
WO (1) WO2013098317A1 (es)

Families Citing this family (77)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2652933A1 (en) * 2010-12-15 2013-10-23 Telefonaktiebolaget L M Ericsson (PUBL) Streaming transfer server, method, computer program and computer program product for transferring receiving of media content
PL2798816T3 (pl) * 2011-12-29 2016-11-30 Inicjowane sieciowo sterowanie strumieniowego przesyłania zawartości
US9967302B2 (en) * 2012-11-14 2018-05-08 Samsung Electronics Co., Ltd. Method and system for complexity adaptive streaming
EP2936742B1 (en) * 2012-12-21 2019-10-09 Koninklijke KPN N.V. Low-latency streaming
US10142390B2 (en) * 2013-02-15 2018-11-27 Nec Corporation Method and system for providing content in content delivery networks
US9900629B2 (en) 2013-03-13 2018-02-20 Apple Inc. Codec techniques for fast switching with intermediate sequence
US9596170B2 (en) * 2013-03-14 2017-03-14 Level 3 Communications, Llc Dynamically optimizing content delivery using manifest chunking
JP6444398B2 (ja) 2013-07-03 2018-12-26 コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ セグメント化コンテンツのストリーミング
JP6419173B2 (ja) 2013-07-12 2018-11-07 キヤノン株式会社 プッシュメッセージ制御による適応型データストリーミング方法
US9628528B2 (en) * 2013-07-19 2017-04-18 Electronics And Telecommunications Research Institute Apparatus and method for providing content
CN103401942B (zh) * 2013-08-12 2016-05-04 网宿科技股份有限公司 内容分发网络节点实现web应用加速的方法和系统
JP6167323B2 (ja) * 2013-09-17 2017-07-26 株式会社Ｋｄｄｉ総合研究所 クライアント装置及びプログラム
CN105637472B (zh) * 2013-10-11 2019-03-19 华为技术有限公司 具有广义屏幕描述的屏幕内容共享系统的框架
JP6393475B2 (ja) * 2013-12-17 2018-09-19 エヌ・ティ・ティ・コミュニケーションズ株式会社 通信アダプタ装置、通信システム、トンネル通信方法、及びプログラム
US10313723B2 (en) 2014-01-29 2019-06-04 Koninklijke Kpn N.V. Establishing a streaming presentation of an event
JP6698553B2 (ja) * 2014-02-13 2020-05-27 コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ １つの要求メッセージに基づいたネットワーク・ノードへの多数のチャンクの要求
US9936001B2 (en) * 2014-02-14 2018-04-03 Red Hat, Inc. Geographic placement of application components by a multi-tenant platform-as-a-service (PaaS) system
US10298984B2 (en) 2014-03-17 2019-05-21 Telefonaktiebolaget Lm Ericsson (Publ) Network PVR
WO2015142102A1 (en) * 2014-03-20 2015-09-24 Samsung Electronics Co., Ltd. Method and apparatus for dash streaming using http streaming
US10523723B2 (en) 2014-06-06 2019-12-31 Koninklijke Kpn N.V. Method, system and various components of such a system for selecting a chunk identifier
US10033824B2 (en) * 2014-06-30 2018-07-24 Samsung Electronics Co., Ltd. Cache manifest for efficient peer assisted streaming
CN105227535B (zh) * 2014-07-01 2019-12-06 思科技术公司 用于边缘缓存和客户端设备的装置及方法
GB2528039A (en) * 2014-07-01 2016-01-13 Canon Kk Method for identifying objects across time periods and corresponding device
CN104486793A (zh) * 2014-08-26 2015-04-01 上海华为技术有限公司 一种数据传输方法及基站
CN107079013B (zh) 2014-10-14 2020-07-10 皇家Kpn公司 管理媒体流的并发流式传输
CN104363472A (zh) * 2014-10-20 2015-02-18 中兴通讯股份有限公司 基于hls的能力控制方法及服务系统和slb服务器
US10142386B2 (en) 2014-10-29 2018-11-27 DLVR, Inc. Determining manifest file data used in adaptive streaming video delivery
US9509742B2 (en) * 2014-10-29 2016-11-29 DLVR, Inc. Configuring manifest files referencing infrastructure service providers for adaptive streaming video
US10084838B2 (en) 2014-10-29 2018-09-25 DLVR, Inc. Generating and using manifest files including content delivery network authentication data
WO2016092831A1 (ja) * 2014-12-09 2016-06-16 日本電気株式会社 情報処理装置、情報処理方法、及び、記録媒体
JP2016129014A (ja) * 2015-01-01 2016-07-14 利仁 曽根 配信サーバ方法
FR3031862B1 (fr) * 2015-01-16 2017-02-17 Sagemcom Broadband Sas Procede de transmission d'un flux de donnees utilisant un protocole de diffusion en direct.
US9961004B2 (en) * 2015-02-18 2018-05-01 Viasat, Inc. Popularity-aware bitrate adaptation of linear programming for mobile communications
US9954930B2 (en) * 2015-08-06 2018-04-24 Airwatch Llc Generating content fragments for content distribution
WO2017061854A1 (en) * 2015-10-08 2017-04-13 Tradecast B.V. Client and method for playing a sequence of video streams, and corresponding server and computer program product
CN105898535A (zh) * 2015-12-30 2016-08-24 乐视致新电子科技（天津）有限公司 提高起播速度的方法、视频播放器及电子装置
US10291965B2 (en) * 2016-03-11 2019-05-14 DISH Technologies L.L.C. Television receiver authorization over internet protocol network
US20170272498A1 (en) * 2016-03-21 2017-09-21 Le Holdings (Beijing) Co., Ltd. Streaming media file distribution method and system
US10798205B2 (en) * 2016-04-13 2020-10-06 Facebook, Inc. Cache system for live broadcast streaming
US10193944B2 (en) * 2016-06-17 2019-01-29 Q Technologies Inc. Systems and methods for multi-device media broadcasting or recording with active control
US10313721B1 (en) * 2016-06-22 2019-06-04 Amazon Technologies, Inc. Live streaming media content using on-demand manifests
US10277929B1 (en) 2016-06-22 2019-04-30 Amazon Technologies, Inc. Live streaming media content using on-demand manifests
WO2018028986A1 (en) * 2016-08-11 2018-02-15 Telefonaktiebolaget Lm Ericsson (Publ) Improved adaptive bit rate streaming of live content
WO2018028985A1 (en) * 2016-08-11 2018-02-15 Telefonaktiebolaget Lm Ericsson (Publ) Improved adaptive bit rate streaming of live content with manifest update push notification or long poll
US11076199B2 (en) * 2016-09-29 2021-07-27 Reliance Jio Infocomm Limited Systems and methods for providing targeted content in an EMBMS stream to a user device
EP3526972A1 (en) * 2016-10-12 2019-08-21 Koninklijke KPN N.V. Enabling a media orchestration
US10623450B2 (en) * 2016-12-01 2020-04-14 Accenture Global Solutions Limited Access to data on a remote device
US20180191801A1 (en) * 2016-12-30 2018-07-05 Facebook, Inc. Adaptively updating content delivery network link in a manifest file
US10476943B2 (en) 2016-12-30 2019-11-12 Facebook, Inc. Customizing manifest file for enhancing media streaming
US10440085B2 (en) 2016-12-30 2019-10-08 Facebook, Inc. Effectively fetch media content for enhancing media streaming
US10701418B2 (en) 2017-02-14 2020-06-30 Level 3 Communications, Llc Systems and methods for resolving manifest file discontinuities
US10834230B2 (en) 2017-08-25 2020-11-10 International Business Machines Corporation Server request management
US10779015B2 (en) * 2017-09-27 2020-09-15 Cloudflare, Inc. Delivering video in a content delivery network
US20210084087A1 (en) * 2017-12-20 2021-03-18 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus for content delivery
US10904351B2 (en) 2018-03-04 2021-01-26 Netskrt Systems, Inc. System and apparatus for temporally and spatially aggregating connectivity to a mobile cache
US11128728B2 (en) 2018-03-22 2021-09-21 Netskrt Systems, Inc. Method and apparatus for walled garden with a mobile content distribution network
US11252253B2 (en) 2018-03-22 2022-02-15 Netskrt Systems, Inc. Caching aggregate content based on limited cache interaction
US11375036B2 (en) 2018-03-22 2022-06-28 Netskrt Systems, Inc. Method and apparatus to prioritize and schedule the distribution of learned content
US11399058B2 (en) 2018-03-22 2022-07-26 Netskrt Systems, Inc. Immutable ledger method and apparatus for managing the distribution of content
US11388252B2 (en) 2018-03-22 2022-07-12 Netskrt Systems, Inc. Micro-cache method and apparatus for a mobile environment with variable connectivity
US11140583B2 (en) * 2018-03-22 2021-10-05 Netskrt Systems, Inc. Transforming video manifests to enable efficient media distribution
US11323536B2 (en) 2018-03-22 2022-05-03 Netskrt Systems, Inc. Apparatus and method for trans-border movement of streaming media content
US11356530B2 (en) 2018-03-22 2022-06-07 Netskrt Systems, Inc. Leveraging mobile environment to distribute cache data
CN112106335B (zh) * 2018-04-30 2021-11-09 杜比国际公司 用于经由内容分发网络流式传输媒体数据的方法及系统
US11128896B2 (en) * 2018-08-27 2021-09-21 Comcast Cable Communications, Llc Secondary content delivery
JP2020080460A (ja) 2018-11-12 2020-05-28 日本電信電話株式会社 システム制御装置、システム制御方法、及びプログラム
EP4202734A1 (en) * 2019-03-26 2023-06-28 Google LLC Separating the authorization of content access and content delivery using multiple cryptographic digital signatures
US11222121B2 (en) * 2019-04-02 2022-01-11 Motional Ad Llc Secure boot of vehicular processors
WO2020243533A1 (en) * 2019-05-31 2020-12-03 Apple Inc. Systems and methods for performance data streaming, performance data file reporting, and performance threshold monitoring
CN112861031B (zh) * 2019-11-27 2024-04-02 北京金山云网络技术有限公司 Cdn中url刷新方法、装置、设备以及cdn节点
US11005908B1 (en) * 2019-12-10 2021-05-11 Amazon Technologies, Inc. Supporting high efficiency video coding with HTTP live streaming
US11250836B2 (en) * 2020-04-30 2022-02-15 Microsoft Technology Licensing, Llc Text-to-speech audio segment retrieval
JP2022021379A (ja) 2020-07-22 2022-02-03 株式会社リコー 情報機器、方法およびプログラム
RU2759595C1 (ru) * 2020-09-28 2021-11-15 Общество С Ограниченной Ответственностью "Джи-Кор Рус" Система отказоустойчивого транскодирования и выдачи прямых потоков в формате hls
FR3110312B1 (fr) 2021-01-13 2023-04-28 Jc Decaux Procédé et système d’affichage digital, dispositif d’affichage digital et serveur d’affichage digital
US11553017B1 (en) * 2021-03-09 2023-01-10 Nokia Technologies Oy Timed media HTTP request aggregation
CN115002036B (zh) * 2022-05-26 2023-07-25 国网河北省电力有限公司电力科学研究院 Ndn网络拥塞控制方法、电子设备及存储介质

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8464302B1 (en) * 1999-08-03 2013-06-11 Videoshare, Llc Method and system for sharing video with advertisements over a network
WO2001010127A1 (en) * 1999-08-03 2001-02-08 Videoshare, Inc. Method and system for sharing video over a network
US20080148330A1 (en) * 2000-02-03 2008-06-19 Gad Liwerant Method and system for sharing video over a network
US7526565B2 (en) * 2003-04-03 2009-04-28 International Business Machines Corporation Multiple description hinting and switching for adaptive media services
US20060212595A1 (en) * 2005-03-15 2006-09-21 1000 Oaks Hu Lian Technology Development (Beijing) Co., Ltd. Method and computer-readable medium for associating sequence numbers with data blocks for distribution of data in a peer-to-peer network
JP4705898B2 (ja) * 2005-09-26 2011-06-22 三星電子株式会社 ウェブ基盤制御システムにおけるサウンド情報伝送のための装置及び方法
US20070198482A1 (en) * 2006-02-21 2007-08-23 International Business Machines Corporation Dynamic data formatting during transmittal of generalized byte strings, such as XML or large objects, across a network
CN101086733A (zh) * 2006-06-08 2007-12-12 厉昱良 一种基于流式传输的多媒体自动播放装置
US9209934B2 (en) * 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
FR2907992A1 (fr) 2006-10-30 2008-05-02 Thomson Licensing Sas Procede de reprise d'une session de video a la demande
CN102067081B (zh) * 2008-03-31 2015-07-15 索尼公司 绑定单元声明文件
US20110191684A1 (en) * 2008-06-29 2011-08-04 TV1.com Holdings, LLC Method of Internet Video Access and Management
EP2467786B1 (en) 2009-08-17 2019-07-31 Akamai Technologies, Inc. Method and system for http-based stream delivery
GB2486126B (en) 2009-09-21 2014-01-08 Ericsson Telefon Ab L M Caching in mobile networks
US8468345B2 (en) 2009-11-16 2013-06-18 Microsoft Corporation Containerless data for trustworthy computing and data services
WO2011090715A2 (en) 2009-12-28 2011-07-28 Akamai Technologies, Inc. Edge server for format-agnostic streaming architecture
US20110161820A1 (en) * 2009-12-31 2011-06-30 John Lee Management of multimedia segment data over a communications network
WO2011087449A1 (en) * 2010-01-18 2011-07-21 Telefonaktiebolaget L M Ericsson (Publ) Methods and arrangements for http media stream distribution
JP5824465B2 (ja) 2010-02-19 2015-11-25 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Ｈｔｔｐストリーミングにおける適応のための方法と装置
US8667164B2 (en) 2010-04-26 2014-03-04 Samsung Electronics Co., Ltd. Method and apparatus for playing live content
US9497290B2 (en) * 2010-06-14 2016-11-15 Blackberry Limited Media presentation description delta file for HTTP streaming
US8806050B2 (en) * 2010-08-10 2014-08-12 Qualcomm Incorporated Manifest file updates for network streaming of coded multimedia data
US9271021B2 (en) * 2011-03-31 2016-02-23 Verizon Patent And Licensing Inc. Delivery of streaming media content
US9066138B1 (en) * 2011-05-10 2015-06-23 Arris Solutions, Inc. Replacing ads in HTTP-based manifest driven video transport
US9420534B2 (en) * 2011-06-28 2016-08-16 Telefonaktiebolaget Lm Ericsson (Publ) Technique for managing streaming media traffic at a network entity
US8769524B2 (en) * 2011-12-09 2014-07-01 Disney Enterprises, Inc. HTML directed adaptive features for mobile applications
EP3525474A1 (en) 2011-12-29 2019-08-14 Koninklijke KPN N.V. Controlled streaming of segmented content
PL2798816T3 (pl) * 2011-12-29 2016-11-30 Inicjowane sieciowo sterowanie strumieniowego przesyłania zawartości
US20130291002A1 (en) * 2012-04-25 2013-10-31 Cox Communications, Inc. Systems and Methods for Delivery of Media Content
US20140040026A1 (en) * 2012-05-04 2014-02-06 Adobe Systems Incorporated Systems and methods for including advertisements in streaming content
US9082092B1 (en) * 2012-10-01 2015-07-14 Google Inc. Interactive digital media items with multiple storylines

Also Published As

Publication number Publication date
JP6310513B2 (ja) 2018-04-11
JP2015510161A (ja) 2015-04-02
KR20140103338A (ko) 2014-08-26
US20170353522A1 (en) 2017-12-07
WO2013098317A1 (en) 2013-07-04
US20140379871A1 (en) 2014-12-25
EP2798816B1 (en) 2016-05-11
US10516717B2 (en) 2019-12-24
JP5977838B2 (ja) 2016-08-24
CN104137505B (zh) 2017-12-05
KR101691709B1 (ko) 2017-01-09
EP2798816A1 (en) 2014-11-05
HK1200995A1 (en) 2015-08-14
US9723047B2 (en) 2017-08-01
HUE036024T2 (hu) 2018-06-28
PL2798816T3 (pl) 2016-11-30
CN104137505A (zh) 2014-11-05
JP2016219032A (ja) 2016-12-22
EP3068102A1 (en) 2016-09-14
EP3068102B1 (en) 2017-11-08

Similar Documents

Publication Publication Date Title
ES2586818T3 (es) Control de flujo de contenido tratado inicialmente en red
US10609101B2 (en) Streaming of segmented content
US10439910B2 (en) Low-latency streaming
KR102299233B1 (ko) 콘텐츠 전달
US8046432B2 (en) Network caching for multiple contemporaneous requests
JP6231583B2 (ja) ネットワークを介するメディアストリーミングのためのトランスポートダイバーシティおよびタイムシフトバッファのサポート
RU2647654C2 (ru) Система и способ доставки аудиовизуального контента в клиентское устройство
EP2647212A1 (en) Method and apparatus for receiving multicast video using a playlist
WO2017182815A1 (en) Media data streaming method and apparatus
JP6059820B2 (ja) 低レイテンシ・ストリーミング
US10425458B2 (en) Adaptive bit rate streaming with multi-interface reception
ES2877338T3 (es) Procedimiento, sistema y dispositivos para mejorar la entrega de contenidos multimedia
Noh et al. Time-shifted streaming in a tree-based peer-to-peer system.
Mariappan et al. Home Screen Adaptive Next Generation Broadcasting Service using MSA-ABR