ES2648087T3 - Procedimiento de difusión en continuo adaptativa - Google Patents

Procedimiento de difusión en continuo adaptativa Download PDF

Info

Publication number
ES2648087T3
ES2648087T3 ES10306160.2T ES10306160T ES2648087T3 ES 2648087 T3 ES2648087 T3 ES 2648087T3 ES 10306160 T ES10306160 T ES 10306160T ES 2648087 T3 ES2648087 T3 ES 2648087T3
Authority
ES
Spain
Prior art keywords
client
multicast
unicast
server arrangement
channel
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
ES10306160.2T
Other languages
English (en)
Inventor
Tom Van Caenegem
Randall Sharpe
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.)
Alcatel Lucent SAS
Original Assignee
Alcatel Lucent SAS
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 Alcatel Lucent SAS filed Critical Alcatel Lucent SAS
Application granted granted Critical
Publication of ES2648087T3 publication Critical patent/ES2648087T3/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/80—Responding to QoS
    • 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/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Procedimiento para proporcionar un servicio de difusión en continuo desde una disposición de servidor (SA) a al menos un cliente (C1) de una pluralidad de clientes (C1,...,Cn), comprendiendo el procedimiento una distribución de dicho servicio de difusión en continuo desde dicha disposición de servidor (SA) a dicho al menos un cliente (C1) a través de una conexión de unidifusión (SCU1, UCD1), una etapa de comunicación, mediante dicha disposición de servidor (SA) a todos los clientes (C1,...Cn) de dicha pluralidad de la disponibilidad de al menos un canal de multidifusión (MC1,..., MCm), una etapa de conexión, mediante dicho al menos un cliente (C1) a uno (MC1) de dicho al menos un canal de multidifusión (MC1,..., MCn), caracterizado porque dicho servicio de difusión en continuo es un servicio de difusión en continuo adaptativa y porque durante dicha conexión de multidifusión dicho al menos un cliente aún permanece conectado a dicha disposición de servidor (SA) a través de dicha conexión de unidifusión (SCU1, UCD1).

Description

5
10
15
20
25
30
35
40
45
50
55
DESCRIPCION
Procedimiento de difusión en continuo adaptativa PROCEDIMIENTO DE DIFUSIÓN EN CONTINUO ADAPTATIVA
La presente invención se refiere a un procedimiento para proporcionar un servicio de difusión en continuo desde una disposición de servidor a al menos un cliente de una pluralidad de clientes. Solicitud de patente internacional publicada WO2009/130541 desvela un procedimiento para la conmutación desde una transmisión de unidifusión de un programa a una transmisión de multidifusión del programa.
El artículo "Reliable Multicast Transport Protocol (RMTP)" de Sanjoy Paul, Krishan K. Sabnani, John C.-H. Lin y Supratik Bhattacharyya, Diario en Áreas Seleccionadas en Comunicaciones de IEEE, Vol. 15, N.° 3, abril de 1997, p. 407-421, presenta el diseño, implementación y rendimiento de un protocolo de transporte de multidifusión fiable RMTP. RMTP es a base de una estructura jerárquica en la que receptores se agrupan en regiones o dominios locales y en cada dominio hay un receptor especial llamado un receptor designado (DR) que es responsable del envío de acuses de recibo periódicamente al transmisor, para el procesamiento de acuses de recibo desde receptores en su dominio y para retransmitir paquetes perdidos a los correspondientes receptores. Ya que paquetes perdidos se recuperan mediante retransmisiones locales en contraposición a retransmisiones desde el transmisor original, se reduce significativamente la latencia extremo a extremo y también se mejora el rendimiento general. También ya que únicamente los DR envían sus acuses de recibo al transmisor, en lugar de todos los receptores enviando sus acuses de recibo al transmisor, se genera un único acuse de recibo por región local, y esto evita implosión de acuse de recibo. Receptores en RMTP envían sus acuses de recibo a los DR periódicamente, simplificando de este modo recuperación de error. Además, paquetes perdidos se recuperan mediante retransmisiones de repetición selectivas, conduciendo a rendimiento mejorado con el coste de mínimo almacenamiento en memoria intermedia en los receptores.
El artículo "Layered Video Multicast with Retransmissions: Evaluation of Hierarchical Rate Control" de Xue Li, Sanjoy Paul y Mostafa Ammar, presentado en Infocom 98, y publicado en la 17a conferencia conjunta anual de Actas de sociedades de informática y de comunicaciones de iEEe, IEEE San Francisco, XP010270383, p. 1062-1072, ISBN 978-0-7803-4383-2, desvela un sistema para la distribución de video usando codificación por capas por la Internet. Las dos contribuciones claves del sistema son (1) mejorar la calidad de recepción dentro de cada capa retransmitiendo paquetes perdidos dado un límite superior de tiempo de recuperación y aplicando un esquema de punto de reproducción adaptativo para ayudar a lograr más retransmisión satisfactoria y (2) adaptar a congestión de red y heterogeneidad usando mecanismo de control de tasa jerárquica. Al contrario de control de tasa basado en transmisor y basado en receptor existente en el que toda la información sobre la congestión de red está disponible o bien en el transmisor o replicada en los receptores, el mecanismo de control de tasa jerárquica distribuye la información entre el transmisor, receptores y algunos agentes en la red de una forma tal que cada entidad mantiene únicamente la información relevante para sí misma.
Difusión en continuo adaptativa es una solución por la que contenido de vídeo se divide en fragmentos y en el que se pone a disposición diferentes resoluciones o niveles de calidad para cada fragmento de video mediante un servidor por ejemplo N resoluciones están disponibles para cada fragmento de video. Un cliente continuamente supervisa la cantidad de ancho de banda disponible, y por ejemplo solicitará/descargará de http ese fragmento que representa una resolución particular del vídeo para el que hay suficiente ancho de banda disponible en la conexión entre el cliente y el servidor. Solicitando fragmentos uno tras otro en resoluciones posiblemente diferentes, esto puede resultar en una experiencia de video fluida incluso aunque varíe el ancho de banda. Generalmente esto se hace a través de una conexión de unidifusión y protocolo de acompañamiento entre el cliente y el servidor.
La solución anterior podría usarse también para difusión en continuo en directo. Sin embargo, para eventos en directo muy populares, que pueden atraer un gran número de clientes, la solución de unidifusión puede ya no ser sostenible por un número de razones. Una primera se refiere al consumo de ancho de banda que podría exceder la capacidad disponible en los enlaces de red corriente abajo del servidor. Además, puede alcanzarse el límite de rendimiento de pico del servidor o la red. El coste para distribuir este tráfico de unidifusión también puede llegar a ser muy alto para el proveedor de servicio de contenido en directo ya que tendrían que cruzarse múltiples redes y enlaces entre pares.
Es por lo tanto un objeto de las realizaciones de la presente invención proporcionar una solución que resuelva los problemas anteriormente mencionados.
De acuerdo con las realizaciones de la presente invención este objeto se logra por medio de un procedimiento para proporcionar un servicio de difusión en continuo desde una disposición de servidor a al menos un cliente de una pluralidad de clientes, comprendiendo el procedimiento una distribución de dicho servicio de difusión en continuo desde dicha disposición de servidor a dicho al menos un cliente a través de una conexión de unidifusión, una etapa de comunicación, mediante dicha disposición de servidor a todos los clientes de dicha pluralidad de la disponibilidad de al menos un canal de multidifusión, una etapa de conexión, mediante dicho al menos un cliente a uno de dicho al menos un canal de multidifusión, caracterizado porque dicho servicio de difusión en continuo es un servicio de
5
10
15
20
25
30
35
40
45
50
55
difusión en continuo adaptativa y porque durante dicha conexión de multidifusión dicho al menos un cliente aún permanece conectado a dicha disposición de servidor a través de dicha conexión de unidifusión.
De esta manera, desde la perspectiva de cliente, un modo de difusión en continuo de unidifusión inicial puede ser seguido por un modo de difusión en continuo de multidifusión, tras el anuncio de esta posibilidad por la disposición de servidor a todos los clientes a través de mensajes de señalización desde la disposición de servidor a todos los clientes por ejemplo en una conexión de señalización de unidifusión o ya en un canal de multidifusión, siendo el último o bien un canal de señalización de multidifusión especializado o un canal de multidifusión para ambos proporcionando metadatos de señalización así como contenido de difusión en continuo. Este anuncio o comunicación del modo de multidifusión puede hacerse por ejemplo tras la detección, mediante la disposición de servidor, de condiciones de sobrecarga. Ya que difusión en continuo de datos de multidifusión es mucho más eficiente en estas situaciones en las que muchos clientes necesitan los mismos datos simultáneamente, esta conmutación de difusión en continuo de unidifusión a multidifusión resolverá entonces los problemas de sobrecarga en la disposición de servidor y/o en la red.
Sin embargo, en cualquier momento el cliente puede aún solicitar datos y metadatos del Servidor de Unidifusión incluido en la disposición de servidor en la conexión de unidifusión ya que el cliente permanece conectado al servidor de unidifusión también a través de la conexión de unidifusión, sin tener necesariamente que solicitar y/o recibir datos y metadatos. Esto presenta una ventaja adicional en caso de que se encuentren problemas en el cliente durante este modo de multidifusión. De hecho, la disponibilidad del canal de comunicación de unidifusión activo habilitará que el cliente responda mucho más rápido a algunos problemas adicionales encontrados durante la transmisión de multidifusión, habilitando por ejemplo una rápida recuperación de errores de datos perdidos durante la transmisión de multidifusión.
En una realización la comunicación de la disponibilidad del modo de multidifusión mediante dicha disposición de servidor tiene lugar tras la detección de problemas de distribución de unidifusión mediante la disposición de servidor. Esta comunicación por lo tanto puede tener lugar a través de señalización usando la conexión de unidifusión para el cliente o a través de un canal de señalización de multidifusión separado. Esta comunicación por lo tanto puede ordenar al cliente que se una a uno de los canales de multidifusión ofrecidos que portan datos y opcionalmente también metadatos, implicando que el cliente ya no debería esperar que sus solicitudes de datos se sirvan en la conexión de unidifusión.
Sin embargo, debido a la disponibilidad restante de la conexión de unidifusión, eventos de error relacionados con al menos un paquete faltante en dicho al menos un cliente mientras recibe paquetes en modo de multidifusión, pueden aún comunicarse a dicho servidor a través del protocolo de unidifusión perteneciente a dicha conexión de unidifusión.
Esta disponibilidad restante del canal de señalización de unidifusión y datos puede resultar entonces en una recuperación de errores fluida ya que los datos faltantes pueden proporcionarse ahora rápidamente desde la disposición de servidor al cliente a través de este canal de datos de unidifusión, mientras la propia señalización puede tener lugar usando el canal de señalización de unidifusión.
En otra realización dicho al menos un cliente se adapta adicionalmente para determinar la causa de dicho al menos un paquete faltante de tal forma que, en caso de que dicho al menos un cliente tiene por ejemplo determinados problemas de ancho de banda en dicho canal de multidifusión, dicho al menos un cliente puede conmutar a un modo de multidifusión diferente.
Esta conmutación desde una conexión de multidifusión a otra conexión de multidifusión puede tener lugar directamente o a través de una fase de distribución de datos de unidifusión intermedia.
La presente invención también se refiere a realizaciones de una disposición de servidor y un cliente, para la cooperación para realizar las realizaciones del procedimiento anteriormente mencionadas.
Adicionalmente se exponen variantes en las reivindicaciones adjuntas.
Se ha de indicar que el término 'acoplado', usado en las reivindicaciones, no debería interpretarse como que es limitante a únicamente conexiones directas. Por lo tanto, el alcance de la expresión 'un dispositivo A acoplado a un dispositivo B' no debería limitarse a dispositivos o sistemas en los que una salida de dispositivo A se conecta directamente a una entrada de dispositivo B. Significa que existe una trayectoria entre una salida de A y una entrada de B que puede ser una trayectoria que incluye otros dispositivos o medios.
Se ha de indicar que la expresión 'que comprende', usada en las reivindicaciones, no debería interpretarse como que es limitante a medios listados posteriormente. Por lo tanto, el alcance de la expresión 'un dispositivo que comprende medios A y B' no debería limitarse a dispositivos que consisten únicamente en componentes A y B. Significa que, con respecto a la presente invención, los componentes únicamente relevantes del dispositivo son A y B.
5
10
15
20
25
30
35
40
45
50
55
60
Los anteriores y otros objetos y características de la invención serán más evidentes y la propia invención se entenderá mejor haciendo referencia a la siguiente descripción de una realización tomada en conjunción con los dibujos adjuntos en los que:
la Figura 1 muestra una realización de una disposición de servidor acoplada a una pluralidad de clientes y adaptada para proporcionar la conmutación de unidifusión a multidifusión
la Figura 2 muestra una realización detallada de un procedimiento para una implementación de cliente capaz de recibir datos y metadatos de Difusión en Continuo Adaptativa de Http relacionados con el mismo contenido/flujo o bien en modo de unidifusión o en modo de multidifusión, y que explica la conmutación de unidifusión a modo de multidifusión y viceversa.
La descripción y dibujos ilustran meramente los principios de la invención. Por lo tanto, se apreciará que los expertos en la materia podrán idear diversas disposiciones que, aunque no se describen o muestran explícitamente en el presente documento, incorporan los principios de la invención y se incluyen dentro del espíritu y ámbito. Adicionalmente, todos ejemplos enumerados en el presente documento tienen principalmente por objeto expresamente ser únicamente para fines pedagógicos para ayudar al lector en el entendimiento de los principios de la invención y los conceptos contribuidos por el(los) inventor(es) para promover la técnica, y deben interpretarse como que son sin limitación a tales específicamente ejemplos enumerados y condiciones. Además, todas las declaraciones en el presente documento enumerando principios, aspectos y realizaciones de la invención, así como ejemplos específicos de la misma, se conciben para incluir equivalentes de la misma.
Los expertos en la materia deberían apreciar que cualquier diagrama de bloque en el presente documento representa vistas conceptuales de circuitería ilustrativa que incorpora los principios de la invención. De manera similar, se apreciará que cualquier gráfica de flujo, diagrama de flujo, diagramas de transición de estados, seudocódigo y similares representan diversos procedimientos que pueden representarse sustancialmente en medio legible por ordenador y así ejecutados mediante un ordenador o procesador, se muestre explícitamente o no tal ordenador o procesador.
La Figura 1 muestra una disposición de servidor SA, que incluye un servidor de contenido de unidifusión UCC, un servidor de señalización de unidifusión UCS y una fuente de multidifusión MCS. Estos son generalmente parte de diferentes servidores físicos y por lo tanto pueden ubicarse a grandes distancias entre sí. Los diferentes módulos UCS, UCC y MCS sin embargo están vinculados juntos a través de un contenido común y descripción de contenido asociada, a menudo indicados como metadatos, que reciben todos de una fuente cS de contenido/metadatos común. Todos los módulos pueden acoplarse a una pluralidad de clientes indicados C1,...,Ci hasta CN. En el caso específico de uso del protocolo de difusión en continuo adaptativa de http, estos clientes por lo tanto son clientes hAs. Tanto servidor de señalización de unidifusión UCS como servidor de contenido de unidifusión UCC también pueden incorporarse en un único servidor de unidifusión. Sin embargo, como ya se ha mencionado, en otras realizaciones pueden ser parte de dos diferentes unidades. La fuente de multidifusión MCS puede generar múltiples flujos de multidifusión. Una fuente de multidifusión MCS de este tipo generalmente es capaz de proporcionar los metadatos de señalización de multidifusión, así como el contenido a los dispositivos acoplados a la misma. Los metadatos opcionalmente también pueden señalizarse en un canal de multidifusión de señalización especializado. Esta situación se muestra en la Figura 1 en la que se proporciona un canal de multidifusión opcional MC0 de este tipo y que se adapta para transportar únicamente metadatos a los clientes. En otras realizaciones todos los metadatos de multidifusión se proporcionan a través de los datos comunes y canales de multidifusión de señalización MC1 a MCm. Tanto servidor de metadatos de unidifusión UCS como fuente de multidifusión MCS pueden por lo tanto proporcionar metadatos, siendo datos de señalización, habilitando de este modo que un cliente se conecte a y reciba diferentes representaciones del mismo flujo/contenido, esté en modo por petición para el modelo de servidor de unidifusión y en modo por proposición para el modelo de fuente de multidifusión.
La fuente de multidifusión MCS por lo tanto también es parte de la disposición de servidor SA. En general la fuente de multidifusión comprende un dispositivo de hardware y software diferente comparado con los servidores de unidifusión, y en general, pero no necesariamente, se ubica en diferentes ubicaciones.
Cada cliente C1 a CN por lo tanto puede considerarse como que se acopla la disposición de servidor SA a través de a canal de señalización de unidifusión, un canal de datos de unidifusión y uno o más canales de multidifusión que sirven para intercambiar tanto señalización de multidifusión como datos. Para el cliente 1 representado estos canales se indican respectivamente SCU1 para el canal de señalización de unidifusión para el cliente 1, UCD1 para el canal de datos de unidifusión para el cliente 1 y MC1 para el canal de multidifusión para el cliente 1. En la realización de la Figura 1 el cliente 1 también se conecta a MCS a través del canal de señalización de multidifusión MC0.
Dependiendo del modo que se usa para la distribución de los datos desde la disposición de servidor SA hacia los clientes, se usa cualquiera de los canales de señalización. Por lo tanto, en caso de que provisión de datos tenga lugar en modo de unidifusión, se usa el canal de señalización de unidifusión. En caso de que la provisión de datos tenga lugar en modo de multidifusión, se usa el canal de señalización de multidifusión, ya sea el canal de señalización especializado como se representa en la realización de la Figura 1, ya sea uno de los canales de multidifusión de datos/señalización habituales MC1 a MCm.
5
10
15
20
25
30
35
40
45
50
55
En caso del protocolo HAS, el servidor de contenido de unidifusión UCC se adapta para enviar segmentos HAS a clientes HAS en caso de que un cliente HAS haya solicitado, a través del canal de señalización de unidifusión, en cualquier momento aquellas representaciones del contenido deseado para el que hay disponible suficiente ancho de banda. Una solicitud de este tipo también se indica como una operación "por petición". El servidor de señalización de unidifusión UCS se adapta adicionalmente para generar metadatos, siendo datos de señalización, que se renuevan continuamente. Estos metadatos de señalización proporcionan entre otros la información de ubicación de los fragmentos de datos de contenido en servidor UcC. En paralelo la fuente de multidifusión también puede proporcionar metadatos de señalización.
La unidifusión y las conexiones de datos de multidifusión se muestran como canales de datos separados en esta figura. Sin embargo, normalmente permanecerán al mismo enlace de comunicación de datos físico en el lado de cliente que puede ser cualquier tipo de enlace de comunicación de datos por ejemplo cableado o inalámbrico, a través de satélite, fibra... usando cualquier tipo de portadora o protocolo de comunicación que soporte tanto transmisión de datos de unidifusión como multidifusión. Similarmente la conexión de metadatos de señalización de unidifusión puede proporcionarse por medio de la misma conexión física entre el cliente y el servidor, como la que proporcionó la transferencia de datos de unidifusión. La diferencia entre estas conexiones únicamente se sitúa en el servidor de nivel de protocolo y el cliente por lo tanto puede acoplarse o interconectar mediante cualquier tipo de red de comunicaciones, sea fija o móvil o satélite... que soporte estas conexiones.
La transferencia de datos normalmente comienza en modo de unidifusión entre el servidor y los diferentes clientes, ya que este modo proporciona la mayor versatilidad. El cliente recupera los metadatos, que incluyen la información de ubicación de los datos de unidifusión y la información de ubicación del UCC, conectándose al servidor de señalización de unidifusión UCS. La transferencia de datos normalmente se inicia por la solicitud del cliente, después del análisis e interpretación de la información de metadatos.
El servidor de distribución de datos de unidifusión UCC por consiguiente comenzará la transmisión de datos, en modo de unidifusión al cliente solicitante, a través de la conexión de datos de unidifusión. Para fines de difusión en continuo adaptativa pueden estar disponibles varias representaciones de contenido, relacionadas con una resolución particular. El cliente puede solicitar en cualquier momento esas representaciones sobre la base de ancho de banda disponible en el enlace de comunicación entre servidor y cliente y recursos disponibles en el cliente. Estas realizaciones se describirán en párrafos adicionales.
En paralelo la fuente de multidifusión MCS también proporciona a los clientes con información de metadatos que mencionan la disponibilidad de uno o más canales de multidifusión para difusión en continuo de datos. En algunas realizaciones están disponibles varios de tales canales de multidifusión, posiblemente, pero no necesariamente relacionados con los diferentes canales de unidifusión o conexiones en términos de ancho de banda disponible. En otras realizaciones únicamente está disponible un canal de multidifusión.
Un cliente por lo tanto puede aprender de los metadatos recibidos desde la fuente de multidifusión MCCS, que el mismo contenido en cualquiera una o más representaciones también están disponible en canales de multidifusión originados por esta fuente.
El cliente por lo tanto puede decidir conectar a un canal de multidifusión y no recuperar nunca más sus datos desde el servidor de distribución de contenido de unidifusión UCC. Esta decisión puede tomarse sobre la base de un algoritmo de decisión/política de cliente por ejemplo porque el servidor UCS responde con una respuesta de error a una solicitud de datos de unidifusión que indica al cliente que debería conectarse a un flujo de multidifusión.
Durante esta conmutación de modo de conexión de unidifusión a un modo de multidifusión, un cliente no debería experimentar ninguna perturbación en la experiencia de visionado en el caso de que los datos se refieran a video.
Adicionalmente, cuando un cliente se conecta a un flujo de multidifusión, debería ser posible aún que este cliente se recupere de pérdida de paquete accidental de tal forma que el cliente puede solicitar cualquier dato faltante en modo de unidifusión. Una realización para la realización de esta característica se analizará con referencia a la Figura 2.
En caso de que se proporcionen múltiples canales de multidifusión que transportan el mismo contenido, pero un formato de representación diferente, la conmutación de un canal de multidifusión a otro también debería ser posible por iniciativa del cliente. De nuevo, esto no debería interrumpir los datos normales por ejemplo conversión de video debido a pérdida de paquetes importantes o información durante esta conmutación. Esto podría ajustarse por ejemplo teniendo un cliente siempre primero conexión con el servidor de contenido de unidifusión UCC en modo de unidifusión, solicitando de este modo ciertos datos de contenido, después de dejar el canal de multidifusión anterior y antes de conectar al siguiente canal de multidifusión.
La Figura 2 muestra una realización detallada del procedimiento, para una implementación usando protocolo de difusión en continuo adaptativa de http, abreviado como HAS. Esta realización también se proporciona para una multitud de modos de unidifusión y multidifusión, cada uno perteneciente a una restricción de ancho de banda particular del enlace entre el cliente y el servidor y entre la fuente de multidifusión y los clientes.
5
10
15
20
25
30
35
40
45
50
55
Esta realización del procedimiento comienza con la provisión de la información de las URL, siendo URL la abreviatura de localizador de recurso universal, a los diferentes clientes, de acuerdo con este protocolo HAS. Esto se refiere a mensajes de señalización, que incluyen información de metadatos, significando que proporciona datos de sobrecarga con respecto a los datos reales a proporcionar. Estos datos de sobrecarga en este caso por lo tanto contienen identificadores o localizadores de dónde recuperar los diferentes datos de acuerdo con los diferentes modos, tanto en unidifusión como en multidifusión. Estos datos de sobrecarga o señalización se proporcionan a través de tanto canales de señalización de unidifusión como multidifusión respectivamente SCU1 a SCUN (el último no mostrado en la Figura 1) y MC0 para los datos de multidifusión, a todos los clientes, y se llama "archivos de manifiesto".
Estos archivos de manifiesto incluyen URL y metadatos para los siguientes fragmentos de video en todas las resoluciones disponibles y se renuevan continuamente en el flujo de multidifusión, así como en los datos de señalización de unidifusión. En la Figura 2 estos se indican por lo tanto como "archivos de manifiesto" y por lo tanto pueden contener las URL asociadas con los fragmentos de datos disponibles, también pueden contener ubicaciones correspondientes dentro del flujo de multidifusión, por ejemplo por medio de un intervalo de Número de Secuencia RTP, cuando se usa el protocolo RTP para transportar los datos en multidifusión. Este intervalo de número de secuencia RTP puede indicar el Número de Secuencia RTP en el flujo de multidifusión, abreviado en la Figura 2 como flujo MC, en el que comienzan los datos de fragmento de video asociados y el Número de Secuencia RTP en el flujo de multidifusión en el que finalizan los datos de fragmento de video asociados. Esto puede ser ventajoso para fines de retransmisión: cuando se detectan uno o más paquete(s) RTP faltante(s), a base de esta información de manifiesto el cliente puede convertir el SN RTP faltante en una solicitud de intervalo de bytes para un fragmento que puede solicitarse en la conexión (http) de unidifusión, cuando se hace seguimiento de cuántos datos (en bytes) del fragmento corrupto ha recibido ya el cliente en multidifusión. Esto se explicará adicionalmente en una parte posterior del presente documento.
Los clientes comienzan la recuperación de datos en modo de unidifusión. En caso de que varios modos de unidifusión estén disponibles, estos clientes recuperarán inmediatamente los datos de acuerdo con el modo que se adapta a sus restricciones de ancho de banda, en las URL correctas, de acuerdo con el protocolo de difusión en continuo adaptativa de http.
Los clientes adicionalmente supervisan continuamente si su memoria intermedia está lo suficientemente llena. Si no es el caso, esto es probablemente indicativo de una falta de ancho de banda suficiente en el enlace entre el cliente y el servidor. En ese caso, el cliente normalmente comenzará a solicitar los siguientes segmentos a otra URL con una representación codificada de tasa de bits más baja del contenido, para la recuperación de los siguientes fragmentos.
En caso de que la memoria intermedia de cliente estuviera lo suficientemente llena durante un periodo de tiempo más largo, el cliente adicionalmente comprueba si el ancho de banda disponible se mantiene lo suficientemente constante o estable. Si ambas condiciones se cumplen, significando que el enlace de comunicaciones entre servidor y cliente tiene suficiente ancho de banda y este ancho de banda está disponible para un periodo de tiempo lo suficientemente largo, por ejemplo 10 segundos, entonces el cliente puede decidir conmutar al modo de multidifusión para la recuperación de datos. En caso de que únicamente esté disponible una conexión de multidifusión, el ancho de banda de esta conexión por lo tanto tiene que ser preferentemente menor o igual que el ancho de banda disponible en el enlace entre el servidor y el cliente. En la Figura 2, este ancho de banda se indica como "X".
El cliente a continuación recupera los datos en modo de multidifusión proporcionando por ejemplo un mensaje IGMP/MLP, siendo la abreviatura de Protocolo de Multidifusión de Grupo de Internet/Protocolo de Escucha de Multidifusión, a la red entre el cliente y la fuente de multidifusión. El cliente adicionalmente continuamente comprueba la pérdida de paquetes. Este mensaje se transmite a la disposición de servidor SA.
En caso de que se detecte una pérdida de paquete de este tipo, el cliente realiza un análisis para comprobar si esta pérdida de paquete se debió o no a problemas de congestión. Si el cliente estima que congestión es la causa principal de la pérdida de paquetes, el cliente se desconectará del modo de multidifusión y continuará en un modo de unidifusión apropiado de acuerdo con el ancho de banda medido. Para recuperar los datos comenzando desde el paquete perdido, el cliente tiene que determinar la URL correcta desde la que recuperar también este paquete particular. Una forma posible de realizar esto es embebiendo la conversión entre ubicaciones de contenido de unidifusión por ejemplo URL con intervalos de bytes y ubicaciones de contenido de multidifusión, por ejemplo, URL de multidifusión y números de secuencia RTP, en los metadatos de archivo de manifiesto, como se mencionó anteriormente.
En caso de que el cliente detectase pérdida de paquete, pero se determinó en cualquier caso que no se debió a problemas de congestión, el cliente puede simplemente solicitar este paquete faltante. Esto puede hacerse a través del uso de un servidor de retransmisión especializado, por ejemplo, un servidor de retransmisión RTP. Como alternativa el cliente puede solicitar el paquete faltante a través de un procedimiento de obtención de http con intervalo de bytes a la URL de unidifusión del fragmento de datos asociado.
En caso de que no se observe pérdida de paquete, y en caso de que se proporcionen varios canales de multidifusión, el cliente puede comprobar si podría ser o no oportuno incluso conectarse a un canal de multidifusión que emite en flujo una representación de datos a una tasa de bits mayor.
Para habilitar una experiencia fluida similar como con difusión en continuo adaptativa de http de unidifusión que 5 implica sin interrupción del servicio como paralización de pantalla y salto de trama/GOP, ningún fragmento de video o datos debería perderse cuando se conmuta de un flujo de Multidifusión que porta una cierta resolución de los contenidos a otro flujo de multidifusión que porta una resolución diferente. Sin embargo, en la práctica, fragmentos de video estarán incompletos cuando dejen un flujo multidifusión y a continuación se unan a otro flujo de multidifusión directamente.
10 Una posible solución es entonces que el cliente primero solicite al servidor de unidifusión un fragmento (completo) de la otra resolución después de dejar la anterior multidifusión y antes de unirse al nuevo flujo de multidifusión, en el que el cliente esperó para dejar la 1a multidifusión hasta que se recibieron todos los datos restantes del último fragmento recibido. Como alternativa es posible usar retransmisiones, o bien por medio de protocolo RTP/RTCP o por medio de http como se ha explicado anteriormente, cuando se conmuta a un flujo de multidifusión de resolución 15 diferente. De esta manera se obtiene una conmutación directa de multidifusión X a multidifusión Y, mientras cualquier paquete faltante se recupera en modo de unidifusión. Este es un medio reactivo para conseguir datos faltantes del 1er fragmento (parcialmente) recibido en el nuevo flujo MC, en el que el cliente esperó para dejar la ia multidifusión hasta que se recibieron todos los datos de un fragmento de datos.
Mientras los principios de la invención se han descrito anteriormente en conexión con aparatos específicos, debe 20 entenderse claramente que esta descripción se hace únicamente a modo de ejemplo y no como una limitación en el alcance de la invención, como se define en las reivindicaciones adjuntas.

Claims (14)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    REIVINDICACIONES
    1. Procedimiento para proporcionar un servicio de difusión en continuo desde una disposición de servidor (SA) a al menos un cliente (C1) de una pluralidad de clientes (C1,...,Cn), comprendiendo el procedimiento una distribución de dicho servicio de difusión en continuo desde dicha disposición de servidor (SA) a dicho al menos un cliente (C1) a través de una conexión de unidifusión (SCU1, UCD1), una etapa de comunicación, mediante dicha disposición de servidor (SA) a todos los clientes (C1,...Cn) de dicha pluralidad de la disponibilidad de al menos un canal de multidifusión (MC1,..., MCm), una etapa de conexión, mediante dicho al menos un cliente (C1) a uno (MC1) de dicho al menos un canal de multidifusión (MC1,..., MCn),
    caracterizado porque dicho servicio de difusión en continuo es un servicio de difusión en continuo adaptativa y porque durante dicha conexión de multidifusión dicho al menos un cliente aún permanece conectado a dicha disposición de servidor (SA) a través de dicha conexión de unidifusión (SCU1, UCD1).
  2. 2. Procedimiento de acuerdo con la reivindicación 1 en el que dicha etapa de comunicación mediante dicha disposición de servidor (SA) tiene lugar tras la detección de problemas de distribución de unidifusión mediante dicha disposición de servidor (SA).
  3. 3. Procedimiento de acuerdo con la reivindicación 1 o 2 en el que dicha etapa de comunicación mediante dicha disposición de servidor (SA) se realiza a través de un canal de señalización de multidifusión (MC0).
  4. 4. Procedimiento de acuerdo con cualquiera de las anteriores reivindicaciones 1-3 en el que dicho al menos un canal de multidifusión (MC1,...,MCn) se adapta para transportar tanto metadatos de señalización como contenido.
  5. 5. Procedimiento de acuerdo con cualquiera de las reivindicaciones 1 a 4 en el que, en caso de un evento de error relacionado con al menos un paquete faltante por dicho al menos un cliente mientras recibe en modo de multidifusión, dicho evento de error se comunica a dicha disposición de servidor (SA) a través de un protocolo de unidifusión perteneciente a un modo de unidifusión en dicha conexión de unidifusión (SCU1, UCC1).
  6. 6. Procedimiento de acuerdo con la reivindicación 5 en el que, tras la recepción mediante dicha disposición de servidor (SA) de dicha comunicación de evento de error, la disposición de servidor (SA) se adapta para identificar el al menos un paquete faltante para la distribución a dicho al menos un cliente a través de dicho al menos un canal de unidifusión (UC1).
  7. 7. Procedimiento de acuerdo con la reivindicación 5 en el que, en caso de que dicho al menos un cliente ha determinado que no suceden problemas de ancho de banda en dicho canal de multidifusión, dicho al menos un cliente se adapta para solicitar otro canal de multidifusión con mayor calidad.
  8. 8. Disposición de servidor (SA) adaptado para recepción de contenido desde una fuente de contenido (CS) y para proporcionar un servicio de difusión en continuo de dicho contenido a al menos un cliente (C1) de una pluralidad de clientes (C1,...,CN) acoplados a dicha disposición de servidor (SA), a través de una conexión de unidifusión (SCU1,UCD1), estando dicha disposición de servidor adicionalmente adaptada para comunicar a todos los clientes (C1,...Cn) de dicha pluralidad de la disponibilidad de al menos un canal de multidifusión (MC1,..., MCm), para proporcionar la distribución de datos de multidifusión tras recibir desde dicho al menos un cliente (C1) una confirmación de conexión a uno de dicho al menos un canal de multidifusión (MC1), caracterizado porque dicho servicio de difusión en continuo es un servicio de difusión en continuo adaptativa y porque dicho servidor se adapta adicionalmente para, durante la distribución de multidifusión de datos, aún recibir de dicho al menos un cliente mensajes en dicha conexión de unidifusión (SCU1, UCD1).
  9. 9. Disposición de servidor (SA) de acuerdo con la reivindicación 8 estando adicionalmente adaptada para comunicar la disponibilidad de dicho al menos un canal de multidifusión tras detectar problemas de distribución de unidifusión a dicho al menos un cliente (C1).
  10. 10. Disposición de servidor (SA) de acuerdo con la reivindicación 8 o 9 estando adicionalmente adaptada para comunicar la disponibilidad de dicho al menos un canal de multidifusión a través de un canal de señalización de multidifusión (MC0).
  11. 11. Disposición de servidor (SA) de acuerdo con cualquiera de las anteriores reivindicaciones 8 a 10, estando adicionalmente adaptada para recibir de dicho cliente (C1) una comunicación de evento de error relacionada con un paquete faltante en dicho cliente mientras recibe en modo de multidifusión, estando la disposición de servidor (SA) adicionalmente adaptada para identificar el al menos un paquete faltante para distribución a dicho al menos un cliente (C1) a través de dicho al menos un canal de unidifusión (UC1).
  12. 12. Cliente (C1) adaptado para recibir un servicio de difusión en continuo de una disposición de servidor (SA) a través de una conexión de unidifusión (SCU1, UCD1), estando dicho cliente (C1) adicionalmente adaptado para recibir una comunicación desde la disposición de servidor (SA) anunciando la disponibilidad de al menos un canal de multidifusión (MC1,..., MCm), estando dicho cliente adicionalmente adaptado para conectar a uno (MC1) de dicho al menos un canal de multidifusión (MC1,..., MCn), caracterizado porque dicho servicio de difusión en continuo es un servicio de difusión en continuo adaptativa y dicho cliente se adapta adicionalmente para, cuando se conecta a dicho
    al menos un canal de multidifusión, aún permanecer conectado a dicha disposición de servidor (SA) a través de dicha conexión de unidifusión (SCU1, UCD1).
  13. 13. Cliente (C1) de acuerdo con la reivindicación 12, estando adicionalmente adaptado para comunicar un evento de error relacionado con al menos un paquete faltante mientras recibe en modo de multidifusión, a dicha disposición de
    5 servidor (SA) a través de un protocolo de unidifusión perteneciente a un modo de unidifusión en dicha conexión de unidifusión (SCU1, UCD1).
  14. 14. Cliente (C1) de acuerdo con cualquiera de las anteriores reivindicaciones 12-13, estando adicionalmente adaptado para solicitar otro canal de multidifusión con mayor calidad, tras no detectar problemas durante dicha distribución de multidifusión.
    10
ES10306160.2T 2010-10-25 2010-10-25 Procedimiento de difusión en continuo adaptativa Active ES2648087T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP10306160.2A EP2445162B1 (en) 2010-10-25 2010-10-25 Method For Adaptive Streaming

Publications (1)

Publication Number Publication Date
ES2648087T3 true ES2648087T3 (es) 2017-12-28

Family

ID=43558183

Family Applications (1)

Application Number Title Priority Date Filing Date
ES10306160.2T Active ES2648087T3 (es) 2010-10-25 2010-10-25 Procedimiento de difusión en continuo adaptativa

Country Status (2)

Country Link
EP (1) EP2445162B1 (es)
ES (1) ES2648087T3 (es)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9848029B2 (en) * 2012-12-28 2017-12-19 Opentv, Inc. Highly-scalable data transmission
US10165035B2 (en) 2013-03-19 2018-12-25 Saturn Licensing Llc Content supplying device, content supplying method, program, and content supplying system
US9774465B2 (en) * 2014-12-24 2017-09-26 Intel Corporation Media content streaming
WO2017041827A1 (en) * 2015-09-08 2017-03-16 Telefonaktiebolaget Lm Ericsson (Publ) Streaming session continuation
US11659222B2 (en) 2018-08-14 2023-05-23 Comcast Cable Communications, Llc Adaptive multicast streaming
WO2021142702A1 (en) * 2020-01-16 2021-07-22 Mediatek Singapore Pte. Ltd. Methods and apparatus of uplink feedback and retransmission for nr multicast services

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102017516A (zh) * 2008-04-24 2011-04-13 爱立信电话股份有限公司 媒体分发的系统和方法

Also Published As

Publication number Publication date
EP2445162A1 (en) 2012-04-25
EP2445162B1 (en) 2017-08-23

Similar Documents

Publication Publication Date Title
CA2564363C (en) Method and apparatus for group communication with end-to-end reliability
ES2648087T3 (es) Procedimiento de difusión en continuo adaptativa
US11057319B2 (en) System and method for recovery of packets in overlay networks
Rizzo et al. A Reliable Multicast data Distribution Protocol based on software FEC techniques
ES2630279T3 (es) Soporte para diversidad de transportes y memorias intermedias desplazadas en el tiempo para la transmisión continua de medios sobre una red
CN101867453B (zh) 一种rtp抗丢包的方法
EP1411688A2 (en) Method and apparatus for multicast data retransmission
BRPI0722125B1 (pt) Método, sistema e aparelho para correção de erro de encaminhamento adaptativo com pedido de repetição automática combinada para multitransmissão confiável em redes de área local sem fio
US20100214970A1 (en) Method and system for transmitting data packets from a source to multiple receivers via a network
KR20050049318A (ko) 패킷 에러 정정 장치 및 방법
ES2278226T3 (es) Sistema y metodo para proporcionar una recuperacion frente a errores para video codificado por fgs en flujo continuo en una red ip.
KR100240645B1 (ko) 멀티캐스트 통신의 패킷 오류 제어기 및 이를 이용한패킷 오류제어 방법
Zeng et al. Dynamic segmented network coding for reliable data dissemination in delay tolerant networks
JP2005065100A (ja) データ配信方法、中継装置及びコンピュータプログラム
Lifen et al. The performance study of transmitting MPEG4 over SCTP
Djukic et al. WLC12-4: Reliable and Energy Efficient Transport Layer for Sensor Networks
Liu et al. Network coding for p2p live media streaming
Lochin et al. Reliable data streaming over delay-tolerant networks (DTNs)
Park et al. Scalable and reliable overlay multicast network for live media streaming
Bortoleto et al. A semi-reliable multicast protocol for distributed multimedia applications in large scale networks
Wehbe et al. Fast packet recovery for pull-based p2p live streaming systems
Aggarwal et al. Enabling immersive experiences in challenging network conditions
Bortoleto et al. Large-scale media delivery using a semi-reliable multicast protocol
JP2021087036A (ja) 受信装置、配信システム、及びプログラム
WO2009097767A1 (zh) 提高组播可靠性的方法、系统和组播网络