ES2995486T3

ES2995486T3 - Content delivery

Info

Publication number: ES2995486T3
Application number: ES21755770T
Authority: ES
Inventors: Rory Turnbull; Timothy Stevens; Stephen Appleby
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 2020-08-19
Filing date: 2021-08-06
Publication date: 2025-02-10
Anticipated expiration: 2041-08-06
Also published as: GB2598295B; EP4201001B1; US20230216905A1; WO2022037972A1; EP4201001A1; GB2598295A; US11729232B2; CN116034572B; GB202012951D0; CN116034572A

Abstract

Se describe un método de entrega de contenido a un dispositivo cliente. En particular, el método se puede aplicar a redes de entrega híbridas de unidifusión/multidifusión, donde el contenido es proporcionado por un servidor de contenido a un proxy raíz, y ese proxy raíz entrega el contenido a los proxies perimetrales a través de multidifusión. Sin embargo, las solicitudes de ese contenido en forma de solicitudes HTTP GET desde un dispositivo cliente son recibidas por un proxy perimetral, que posteriormente envía una solicitud HTTP HEAD para la información de encabezado asociada con ese contenido directamente al servidor de contenido. El servidor de contenido responde a través de unidifusión con una respuesta adecuada a la solicitud HTTP HEAD, que es recibida por el proxy perimetral. El proxy perimetral toma la respuesta junto con la carga útil del segmento de contenido recibido a través de multidifusión, para generar un segmento de contenido específico del cliente para su entrega al dispositivo cliente a través de unidifusión. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Distribución de contenidos

Campo de la invención

Esta invención se refiere al campo de la distribución de contenidos usando una combinación de unidifusión y multidifusión.

Antecedentes de la invención

Cada vez se retransmiten más contenidos en directo a través de HTTP (o HTTPS). Los eventos en directo populares generan una demanda extremadamente volátil, lo que da lugar a una relación pico a media muy elevada en los volúmenes de tráfico. Por ejemplo, el gráfico 100 de la Figura 1 muestra un ejemplo de volúmenes de tráfico en puertas de enlace cercanas al borde de una red móvil tomados durante la competición futbolística Euro 2016. La gráfica 102 muestra los volúmenes de tráfico en un día (miércoles 15 de junio) sin fútbol y la gráfica 104 muestra los volúmenes de tráfico al día siguiente (jueves 16 de junio) cuando había un partido de fútbol (Inglaterra contra Gales). Ambas gráficas muestran más o menos los mismos volúmenes de tráfico a lo largo del día, salvo que la Gráfica 104 tiene un importante pico adicional de tráfico entre las 14:00 y las 16:00 horas, debido a que los clientes están reproduciendo el partido de fútbol.

Esta elevada relación pico a media plantea un reto particular en el borde de la red, donde tales picos pueden causar una degradación de la calidad de la experiencia de los usuarios.

Lo más habitual es que los contenidos se distribuyan a través de Internet usando pares de solicitud/respuesta HTTP (o HTTPS). Las aplicaciones cliente enviarán una solicitud HTTP a un servidor y se devolverá una respuesta con el contenido solicitado. Tales solicitudes/respuestas son de naturaleza unidifusión.

HTTP(S) puede usarse para transmisión de vídeo. Normalmente, el cliente obtendrá un archivo de manifiesto que permitirá determinar las URL de los archivos individuales que contienen segmentos de vídeo. A continuación, el cliente solicitará estos segmentos en secuencia y los concatenará para formar un flujo continuo para su reproducción. Cada segmento de vídeo también puede estar disponible a diferentes tasas de transferencia de bits para permitir que la velocidad de vídeo se adapte al rendimiento de la red disponible. Esta técnica es conocida como streaming adaptativo basado en el protocolo HTTP (HTTP Adaptive Streaming (HAS)).

Para los usuarios que vean el mismo evento, tal como un partido de fútbol en directo, cada cliente hará sus propias solicitudes HTTP y obtendrá sus propias respuestas HTTP, a pesar de que una gran parte del contenido que se les distribuya dentro de las respuestas HTTP será idéntica entre los clientes. El resultado es un uso muy ineficiente de la red.

Sin embargo, si la red de acceso fuera capaz de usar multidifusión para la distribución de contenidos en lugar de unidifusión, a continuación, el impacto de los picos de contenido en directo que se muestran en la Figura 1 podría reducirse significativamente. Es más, el uso de la multidifusión en la red de acceso también podría reducir significativamente los picos de demanda en los servidores de la Red de Distribución de Contenidos.

Ya existen soluciones que abordan este problema, donde se inserta una ruta multidifusión en una ruta que por otra parte sería unidifusión entre un cliente y un servidor de contenido mediante proxies. Ejemplos de tales soluciones híbridas incluyen: "IP Multicast Adaptive Bit Rate Architecture Technical Report" OC-TR-IP-MULTI-ARCH-C01-161026, 26/10/2016, de Cable Labs; especificaciones 3GPP, 23.246 (MBMS Architecture and functional description), 26.346 (MBMS Protocols and codecs) y 26.347 (MBMS APIs); y documento DVB A176, "Adaptive Media Streaming over IP Multicast", (8 de marzo de 2018). Estas soluciones híbridas pueden usarse para la distribución de contenidos a una tasa de transferencia de bits adaptativa multidifusión (mABR, por sus siglas en inglés).

La Figura 2 muestra un ejemplo generalizado de tales soluciones híbridas.

En la Figura 2, se muestra un servidor de contenido 202 que proporciona contenido tal como vídeo a los dispositivos cliente 204a, 204b y 204c. Se insertan un Proxy multidifusión X 206 y tres Proxies Y 208a, 208b y 208c en la ruta unidifusión entre el servidor de contenido 202 y los dispositivos cliente. El Proxy X 206 adquiere un contenido unidifusión del servidor de contenido 202 y los pone a disposición a través de multidifusión. El Proxy Y recibe el contenido multidifusión y puede ponerlo a disposición por unidifusión en cualquier dispositivo cliente que lo solicite. Todos los dispositivos cliente recibirán respuestas idénticas a sus solicitudes de segmentos, ya que el mismo contenido multidifusión es recibido por todos los Proxies Y del Proxy X. Los Proxies Y pueden estar situados en los dispositivos cliente, o dispositivos separados, o puede haber un único Proxy Y, dependiendo de la configuración.

En tal solución, el Proxy X está preconfigurado para actuar como cliente y de forma independiente realiza solicitudes de segmentos de contenido y envía la respuesta completa a la red multidifusión. Para ello, el Proxy X solicita primero un archivo de manifiesto y, a continuación, realiza las peticiones oportunas de los segmentos de contenido descritos dentro del mismo. Todos los dispositivos cliente recibirán respuestas idénticas a sus solicitudes de segmentos, ya que el mismo contenido multidifusión es recibido por todos los Proxies Y del Proxy X. Tenga en cuenta que los Proxies Y pueden estar situados en los dispositivos cliente, o dispositivos separados, o puede haber un único Proxy Y, dependiendo de la configuración.

Este mecanismo no permite que los dispositivos cliente envíen información específica del cliente o de la sesión al servidor de contenido y también imposibilita que las respuestas enviadas a los dispositivos cliente contengan información específica del cliente o de la sesión del servidor de contenido. La información específica de la sesión puede incluir tokens de autenticación, firmas de URL, cookies o información de estado tal como el punto de reproducción actual.

Es más, el servidor de contenido es normalmente una caché en borde de CDN que, por lo demás, tendría visibilidad del número de solicitudes que se realizan y del número de respuestas que está entregando. Esta información se usa para la supervisión, medición y análisis del servicio y a menudo es crucial para el negocio del operador de la CDN, por ejemplo, para la garantía del servicio, facturación, etc.

Con la arquitectura de multidifusión híbrida mencionada anteriormente, independientemente del número de dispositivos cliente que consuman contenidos, sólo hay una única solicitud realizada por el Proxy X y una única respuesta correspondiente del servidor de contenido. Es evidente que esto plantea problemas al proveedor de contenidos a la hora de determinar la demanda real de sus contenidos.

Muchas otras disposiciones híbridas unidifusión-multidifusión y las soluciones de mABR en general, tienen un problema semejante.

La solicitud de patente internacional WO2016/107733 describe métodos para convertir un flujo de multidifusión en segmentos de unidifusión. En particular, los identificadores de secuencia se generan basándose en un campo de referencia de reloj en los paquetes de la secuencia de transporte que componen el flujo de multidifusión. Cada vez que se calcula un nuevo identificador de secuencia, se genera un nuevo segmento de unidifusión y se le asigna el nuevo identificador de secuencia. Los paquetes de flujo de transporte se colocan en el nuevo segmento hasta que se procesa un paquete que provoca que se genere un nuevo identificador de secuencia, momento en el que se genera otro nuevo segmento y los paquetes se colocan en ese segmento.

Csaba Okrona "What is a HTTP HEAD Request Good for? Some uses", 27 de agosto de 2011, XP055139472 describe qué son las solicitudes HEAD y cómo se pueden usar.

Sumario de la invención

El objetivo de los aspectos de la presente invención es proporcionar un mecanismo mejorado de distribución de contenidos.

Según un aspecto de la invención, se proporciona un método, según la reivindicación 1 independiente, para distribuir contenidos a un dispositivo cliente en una red que comprende una pluralidad de dispositivos cliente, en donde dicho contenido comprende una secuencia de segmentos, comprendiendo dicho método:

i) recibir en un primer elemento de red uno o más segmentos procedentes de un servidor de contenido enviados a través de multidifusión;

ii) recibir en el primer elemento de red una solicitud de un segmento de un dispositivo cliente, en donde la solicitud comprende una solicitud HTTP GET;

iii) en respuesta a la solicitud recibida, enviar mediante el primer elemento de red una solicitud HTTP HEAD al servidor de contenido;

iv) recibir una respuesta a la solicitud HTTP HEAD en el primer elemento de red a través de unidifusión; v) generar un segmento que comprende la cabecera de la respuesta recibida y una carga útil procedente de uno o más segmentos recibidos;

vi) enviar el segmento generado al dispositivo cliente a través de unidifusión.

La solicitud HTTP HEAD corresponde efectivamente a la solicitud HTTP GET. La solicitud HTTP HEAD puede comprender información específica de la sesión. La respuesta a la solicitud HEAD también puede comprender información específica de la sesión. La solicitud HTTP HEAD puede enviarse directamente al servidor de contenido.

La cabecera y la carga útil pueden emparejarse usando un identificador asociado con la cabecera y un identificador correspondiente asociado con la carga útil.

Uno o más segmentos pueden almacenarse en caché en el primer elemento de red.

La respuesta a la solicitud HEAD no puede contener una parte de carga útil.

El contenido puede ser un contenido de vídeo.

Según otro aspecto de la invención, se proporciona un elemento de red, según la reivindicación 9 independiente, para gestionar la distribución de contenidos a través de una red a un dispositivo cliente, dicho elemento de red adaptado en funcionamiento para: recibir uno o más segmentos de un servidor de contenido enviados a través de multidifusión; recibir una solicitud de un segmento de un dispositivo cliente, en donde la solicitud comprende una solicitud HTTP GET; enviar, en respuesta a la solicitud recibida, una solicitud HTTP HEAD al servidor de contenido; recibir una respuesta a la solicitud HTTP HEAD a través de unidifusión; generar un segmento que comprende la cabecera de la respuesta recibida y una carga útil de uno de los uno o más segmentos recibidos; enviar el segmento generado al dispositivo cliente a través de unidifusión.

Otras realizaciones preferidas se exponen en las reivindicaciones dependientes.

En los ejemplos de la invención, los dispositivos cliente tienen la ventaja de poder compartir información específica de la sesión con los servidores de contenido, tal como tokens de autenticación, firmas de URL, cookies e información de estado. Los servidores de contenido también son conscientes de los dispositivos cliente individuales como resultado de las solicitudes HTTP HEAD recibidas y, por lo tanto, son capaces de proporcionar análisis e información de facturación.

Tenga en cuenta que las cabeceras en las respuestas a las solicitudes HEAD son normalmente mucho más pequeñas que las cargas útiles en los segmentos de multidifusión, por lo que a pesar del uso de solicitudes HEAD y respuestas, sigue habiendo un ahorro significativo de ancho de banda mediante el uso de multidifusión para las cargas útiles. Breve descripción de los dibujos

Para una mejor comprensión de la presente invención se hará referencia ahora a modo de ejemplo únicamente a los dibujos adjuntos, en los que:

La Figura 1 es un gráfico que muestra el volumen de tráfico de una red en distintos días;

La Figura 2 es un diagrama de red de una solución general anterior;

La Figura 3 es un diagrama de red que muestra en funcionamiento los principales componentes de un ejemplo de la presente invención;

La Figura 4 es un diagrama de flujo que resume las etapas de un ejemplo de la invención.

Descripción de las realizaciones preferidas

La presente invención se describe en el presente documento con referencia a ejemplos particulares. Sin embargo, la invención no se limita a tales ejemplos.

El alcance de la invención sólo queda definido por las reivindicaciones adjuntas.

Ejemplos de la presente invención proporcionan un método para distribuir contenidos a un dispositivo cliente. En particular, los ejemplos pueden aplicarse a redes de distribución híbridas unidifusión/multidifusión, donde un servidor de contenido proporciona un contenido a un proxy raíz y ese proxy raíz distribuye el contenido a proxies de borde a través de multidifusión. Sin embargo, las solicitudes de ese contenido en forma de solicitudes HTTP GET de un dispositivo cliente son recibidas por un proxy de borde, que posteriormente envía una solicitud HTTP HEAD para obtener información de cabecera asociada con ese contenido directamente al servidor de contenido. El servidor de contenido responde a través de unidifusión con una respuesta adecuada a la solicitud HTTP HEAD, que es recibida por el proxy de borde. El proxy de borde toma la respuesta junto con la carga útil del segmento de contenido recibido a través de multidifusión, para generar un segmento de contenido específico del cliente para su distribución al dispositivo cliente a través de unidifusión.

La Figura 3 muestra los principales componentes de un ejemplo de la presente invención. Los componentes reflejan los de las soluciones híbridas ejemplificadas en la Figura 2. Sin embargo, como resultará evidente en la descripción que se da a continuación, el funcionamiento de algunos de los componentes difiere.

Volviendo a la Figura 3, la red 300 comprende un servidor de contenido 302, un Proxy X 306 (también denominado proxy raíz), Proxies Y (también denominados proxies de borde) 308a, 308b y 308c, dispositivos cliente 304a, 304b y 304c y un controlador de multidifusión 312. El controlador de multidifusión 112 puede ayudar en el funcionamiento del Proxy X 306 y de los Proxies Y. El servidor de contenido 302 proporciona un contenido tal como vídeo a las entidades solicitantes, tales como los dispositivos cliente. El servidor de contenido 302 puede estar ubicado en una red de distribución de contenidos (CDN, por sus siglas en inglés) y puede haber más de un servidor de contenido. El Proxy X 306 puede comunicarse con el servidor de contenido 302 a través de unidifusión. El Proxy X 306 también puede comunicarse con los Proxies Y 308a, 308b y 308c, a través de multidifusión. Los Proxies Y pueden estar ubicados en los dispositivos cliente, en dispositivos separados (tal como una puerta de enlace doméstica) o puede haber un único Proxy Y dependiente de la configuración.

Se supone que los dispositivos cliente ejecutan las respectivas aplicaciones cliente, que son la fuente de las solicitudes de contenidos. Para mayor simplicidad, la expresión dispositivo cliente de aquí en adelante se usa para referirse a un dispositivo cliente que ejecuta una aplicación cliente. Los dispositivos cliente pueden realizar solicitudes HTTP (o HTTPS) de unidifusión de contenidos mantenidos en el servidor de contenido 302.

Los contenidos almacenados en el servidor de contenido 302 son normalmente contenidos multimedia (por ejemplo, un programa de televisión, una película o un canal de televisión lineal completo) que comprenden secuencias de vídeo codificadas según un estándar adecuado, tal como el estándar H.264 de la UIT. Las secuencias de vídeo se almacenan en forma de segmentos temporales secuenciales en el servidor de contenido 302, donde cada segmento equivale normalmente a entre 2 y 10 segundos de vídeo decodificado. Las secuencias de vídeo también pueden codificarse a una pluralidad de tasas de transferencia de bits o niveles de calidad, dando lugar a una pluralidad de secuencias codificadas, cada una codificada a una de una pluralidad de tasas de transferencia de bits. Tal disposición es normalmente propia de un servicio de streaming con tasa de transferencia de bits adaptativa.

Los clientes usan los archivos de manifiesto para identificar dónde se encuentran los segmentos (mediante una URL en el manifiesto). Así, un dispositivo cliente transmite una secuencia de vídeo usando el manifiesto para determinar a dónde dirigir las solicitudes de unidifusión secuenciales para cada segmento, a una tasa de transferencia de bits particular, según sea necesario. Tal disposición se usa en tecnologías de HTTP Adaptive Streaming como MPEG-DASH y HLS (HTTP Live Streaming) de Apple.

Aunque el servidor de contenido 302 y el Proxy X 306 se muestran en el presente documento como dos entidades separadas, en algunas disposiciones, las dos entidades podrían estar coubicadas o su funcionalidad podría ser proporcionada por un único servidor.

El controlador de multidifusión 312 (MCC) supervisa el funcionamiento del Proxy X y de los Proxies Y y puede controlar los proxies en consecuencia.

Así, la red 300 está dispuesta de tal manera que el Proxy X 306 funciona efectivamente en la raíz de un árbol de multidifusión, solicitando contenido del servidor de contenido a través de unidifusión, y empaquetando el contenido recibido para su transmisión a través de multidifusión a los Proxies Y. Los proxies Y se encuentran en el borde del árbol de multidifusión, recibiendo el contenido del Proxy X a través de multidifusión y almacenándolo en caché localmente (si procede). Los dispositivos cliente pueden realizar solicitudes HTTP GET de contenido a partir de un Proxy Y adecuado.

Los ejemplos de la presente invención exponen cómo se gestionan esas peticiones HTTP GET de manera que la información específica del cliente pueda pasar de un dispositivo cliente al servidor de contenido y viceversa, sin dejar de usar ventajosamente el mecanismo de distribución a través de multidifusión proporcionado entre el Proxy X y los Proxies Y.

La Figura 4 muestra un diagrama de flujo que resume las etapas del funcionamiento de los elementos de la Figura 3 en un ejemplo de la invención.

Comenzando por la etapa 400, el Proxy X 306 comienza a realizar peticiones HTTP GET para segmentos de contenido desde el servidor de contenido 302. El contenido puede ser, por ejemplo, un partido de fútbol en directo. Para ello, el Proxy X 306 puede obtener en primer lugar el archivo de manifiesto asociado al contenido y realiza solicitudes de segmentos de contenido detallados en el manifiesto. Estas solicitudes son normalmente solicitudes HTTP GET, que son de naturaleza unidifusión, con una solicitud realizada para cada segmento de contenido. El servidor de contenido 302 responde enviando el segmento de contenido solicitado en una respuesta HTTP al Proxy X 306. El manifiesto se actualiza periódicamente con los detalles de los nuevos segmentos de contenido, por lo que el Proxy X sigue solicitando segmentos de contenido posteriores hasta que no haya más segmentos enumerados en el manifiesto.

En la etapa 402, el Proxy X 306 pone a disposición en multidifusión los segmentos de contenido que ha recibido. Esto puede comenzar tan pronto como el Proxy X 306 haya recibido el primer segmento de contenido. El Proxy X 306 puede ya haber sido configurado (por ejemplo, bajo la instrucción del controlador de multidifusión 312) para que ciertos contenidos recibidos del servidor de contenido 302 sean transmitidos a través de multidifusión a los Proxies Y. Por ejemplo, cada programa puede colocarse en un canal de multidifusión diferente, definido por su propia dirección IP. La presencia de un nuevo programa y el canal de multidifusión pueden difundirse a los destinatarios potenciales, tales como los Proxies Y, usando técnicas convencionales. El Proxy X 308 empaqueta los segmentos de contenido recibidos para su transmisión por multidifusión y transmite los segmentos de contenido a través de multidifusión.

Ahora se describen las siguientes etapas con referencia al Proxy Y 308a y al dispositivo cliente 304a asociado, aunque se apreciará que otros Proxies Y (y dispositivos cliente asociados) puedan de forma adicional o alternativa estar sujetos al mismo método.

En la etapa 404, el Proxy Y 308a se une al grupo de multidifusión en el que el Proxy X 306 está transmitiendo los segmentos de contenido en la etapa 402. Esto puede iniciarse de antemano, por ejemplo, bajo instrucciones del controlador de multidifusión o en respuesta a una solicitud del mismo contenido por parte de un dispositivo cliente asociado, tal como el dispositivo cliente 304a. Una vez que se ha unido al grupo de multidifusión, el Proxy Y 308a comienza a recibir segmentos de contenido transmitidos a través de multidifusión por el Proxy X. Estos segmentos de contenido recibidos pueden almacenarse en caché en el Proxy Y 308a.

En condiciones normales de funcionamiento, un dispositivo cliente tal como el dispositivo cliente 304a realizaría solicitudes de unidifusión secuenciales de los segmentos de contenido recibidos por el Proxy Y 308a en la etapa 404 y, a continuación, decodificaría y reproduciría el contenido de manera normal. Sin embargo, los ejemplos de la invención modifican el funcionamiento normal como se expone en las etapas 406 a 414 siguientes.

En la etapa 406, el Proxy Y 308a recibe una solicitud HTTP GET para un segmento de contenido del dispositivo cliente 304a. El dispositivo cliente 304a usa un manifiesto adecuado para determinar hacia dónde dirigir las solicitudes HTTP GET para segmentos de contenido.

En la etapa 408, el Proxy Y 308a determina que el segmento de contenido solicitado es uno que ha recibido (en la etapa 404). Sin embargo, en lugar de responder con el segmento de contenido solicitado, el Proxy Y 308a modifica la solicitud HTTP GET a una solicitud HTTP HEAD correspondiente y transmite esa solicitud HTTP HEAD correspondiente a través de unidifusión al servidor de contenido 302. La solicitud HTTP HEAD es idéntica a la solicitud HTTP GET, salvo que la parte que responde no debe devolver un cuerpo de mensaje, es decir, en este ejemplo, el servidor de contenido no debe devolver el segmento de contenido que se solicita.

La solicitud HTTP HEAD puede incluir información específica de la sesión que permite al servidor de contenido 302 autenticar la solicitud y registrarla para su posterior análisis y facturación. Por ejemplo, un dispositivo cliente puede tener que iniciar sesión en el servidor de contenido con un nombre de usuario/credenciales de seguridad, lo que da lugar a que se proporcione un token de seguridad al dispositivo cliente, que éste deberá incluir a continuación en las solicitudes de segmentos posteriores (GET y HEAD).

Es más, tanto las solicitudes HTTP GET como HEAD contienen la dirección IP pública del remitente. El servidor de contenido puede usar esta dirección IP para decidir si permite o no la transmisión del contenido, por ejemplo, sólo desde direcciones IP con sede en el Reino Unido.

La solicitud HTTP HEAD es enviada por el Proxy Y 308a directamente al servidor de contenido 302. Como alternativa, la solicitud puede enviarse a través de Proxy X 306, con el Proxy X 306 reenviando a continuación la solicitud al servidor de contenido 302.

El servidor de contenido 302 recibe la solicitud HTTP HEAD y responde en consecuencia con un mensaje OK 200 enviado a través de unidifusión. La respuesta OK 200 incluye sólo una cabecera y no tiene carga útil, como se requiere para las respuestas a solicitudes HTTP HEAD. La cabecera de respuesta también puede contener información específica de la sesión. El Proxy Y 308a recibe el mensaje de respuesta transmitido por el servidor de contenido en la etapa 410.

En la etapa 412, el Proxy Y compara la respuesta HEAD recibida con la correspondiente carga útil recibida a través de multidifusión (de la etapa 404). El Proxy Y sustituye la cabecera genérica recibida del segmento de multidifusión por la cabecera específica de la sesión recibida a través de unidifusión de la respuesta HEAD, generando así un segmento de contenido específico de la sesión.

Este segmento de contenido generado se transmite a través de unidifusión al dispositivo cliente 304a en la etapa 414.

El dispositivo cliente 304a puede decodificar y reproducir este segmento de contenido o almacenarlo en memoria intermedia para decodificarlo y reproducirlo más tarde, dependiendo de la configuración del dispositivo cliente 304a.

A continuación, en la etapa 416, el dispositivo cliente puede solicitar el siguiente segmento de contenido de la secuencia al Proxy Y 308a y así el procesamiento vuelve a la etapa 406 y el método se repite hasta que el dispositivo cliente decida parar o hasta que se reciba todo el contenido.

El emparejamiento entre cabeceras y cargas útiles puede lograrse por varios métodos.

El Proxy X podría etiquetar los segmentos enviados por multidifusión con la URL de solicitud correspondiente, permitiendo al Proxy Y hacer coincidir las respuestas en su caché con las solicitudes realizadas por los dispositivos cliente.

Como alternativa, se podrían usar Etags (Etiquetas de Entidad). Las Etags forman parte de la especificación HTTP 1.1 y se usan para identificar de forma unívoca las cargas útiles de respuesta). La Etag estará presente tanto en la cabecera genérica recibida a través de multidifusión como en la cabecera específica de la sesión recibida a través de unidifusión por el Proxy Y, por lo que las Etags correspondientes pueden usarse para emparejar las cargas útiles con las cabeceras correctas.

Podrían emplearse otros esquemas de etiquetado (personalizados) con el servidor de contenido 302 colocando cabeceras adicionales en las respuestas tanto al Proxy X como a los Proxies Y con el fin de facilitar el emparejamiento.

Aunque los ejemplos anteriores se han descrito con referencia a las solicitudes HTTP GET y HTTP HEAD, podrían usarse otros tipos de mensajes y protocolos que tengan la misma función.

En general, se observa en el presente documento que, si bien en lo que antecede describe implementaciones a modo de ejemplo, existen diversas variaciones y modificaciones que pueden realizarse a las implementaciones a modo de ejemplo descritas, siempre que estas variaciones y modificaciones se encuentren dentro del alcance de la presente invención, como se define en las reivindicaciones anexas. Un experto en la materia reconocerá las modificaciones a las implementaciones a modo de ejemplo descritas.

Claims

REIVINDICACIONES

1. Un método para distribuir un contenido a un dispositivo cliente (304a) en una red (300) que comprende una pluralidad de dispositivos cliente (304a, 304b, 304c), en donde dicho contenido comprende una secuencia de segmentos, comprendiendo dicho método:

i) recibir (404) en un primer elemento de red (308a) uno o más segmentos procedentes de un servidor de contenido enviados a través de multidifusión;

ii) recibir (406) en el primer elemento de red (308a) una solicitud de un segmento de un dispositivo cliente (304a), en donde la solicitud comprende una solicitud HTTP GET;

iii) en respuesta a la solicitud recibida, enviar (408) mediante el primer elemento de red (308a) una solicitud HTTP HEAD al servidor de contenido (302);

iv) recibir (410) una respuesta a la solicitud HTTP HEAD en el primer elemento de red (308a) a través de unidifusión; v) generar (412) un segmento que comprende la cabecera de la respuesta recibida y una carga útil procedente de uno o más segmentos recibidos;

vi) enviar (414) el segmento generado al dispositivo cliente (304a) a través de unidifusión.

2. Un método según la reivindicación 1, en donde dicha solicitud HTTP HEAD corresponde a la solicitud HTTP GET.

3. Un método según la reivindicación 1 o 2, en donde, en la etapa v), la cabecera y la carga útil se emparejan usando un identificador asociado con la cabecera y un identificador correspondiente asociado con la carga útil.

4. Un método según cualquier reivindicación anterior, en donde dicha solicitud HTTP HEAD comprende información específica de la sesión.

5. Un método según cualquier reivindicación anterior, en donde dicha respuesta comprende información específica de la sesión.

6. Un método según cualquier reivindicación anterior, en donde la solicitud HTTP HEAD se envía directamente al servidor de contenido.

7. Un método según cualquier reivindicación anterior, en donde uno o más segmentos se almacenan en caché en el primer elemento de red.

8. Un método según cualquier reivindicación anterior, en donde la respuesta no contiene una parte de carga útil.

9. Un elemento de red (308a) para gestionar una distribución de contenidos a través de una red (300) a un dispositivo cliente (304a), dicho elemento de red adaptado en funcionamiento para:

recibir (404) uno o más segmentos procedentes de un servidor de contenido (302) enviados a través de multidifusión; recibir (406) una solicitud de un segmento de un dispositivo cliente (304a), en donde la solicitud comprende una solicitud HTTP GET;

enviar (408), en respuesta a la solicitud recibida, una solicitud HTTP HEAD al servidor de contenido (302); recibir (410) una respuesta a la solicitud HTTP HEAD a través de unidifusión;

generar (412) un segmento que comprende la cabecera de la respuesta recibida y una carga útil procedente de uno o más segmentos recibidos;

enviar (414) el segmento generado al dispositivo cliente (304a) a través de unidifusión.