ES2877338T3 - Procedimiento, sistema y dispositivos para mejorar la entrega de contenidos multimedia - Google Patents

Procedimiento, sistema y dispositivos para mejorar la entrega de contenidos multimedia Download PDF

Info

Publication number
ES2877338T3
ES2877338T3 ES18382919T ES18382919T ES2877338T3 ES 2877338 T3 ES2877338 T3 ES 2877338T3 ES 18382919 T ES18382919 T ES 18382919T ES 18382919 T ES18382919 T ES 18382919T ES 2877338 T3 ES2877338 T3 ES 2877338T3
Authority
ES
Spain
Prior art keywords
server
domain name
message
dns
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
ES18382919T
Other languages
English (en)
Inventor
Pablo Jorge Hernandez
Hila Francisco José Cano
Padros Antoni Silvestre
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.)
Telefonica SA
Original Assignee
Telefonica SA
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 Telefonica SA filed Critical Telefonica SA
Application granted granted Critical
Publication of ES2877338T3 publication Critical patent/ES2877338T3/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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1006—Server selection for load balancing with static server selection, e.g. the same server being selected for a specific client
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • 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
    • 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
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1014—Server selection for load balancing based on the content of a request
    • 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/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1025—Dynamic adaptation of the criteria on which the server selection is based
    • 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/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1031—Controlling of the operation of servers by a load balancer, e.g. adding or removing servers that serve requests
    • 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/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H04L2101/35—Types of network names containing special prefixes

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Un procedimiento para mejorar la entrega de contenidos multimedia a equipos de usuario final en una red de entrega de contenidos que comprende varios servidores, el procedimiento comprende: - Un primer servidor recibe un primer mensaje de un equipo de usuario final, el mensaje incluye un Localizador Universal de Recursos, URL, que incluye un primer nombre de dominio; - Tras recibir dicho primer mensaje, el primer servidor determina si dicho primer nombre de dominio incluye un identificador de un servidor de la red de entrega de contenidos, denominado identificador de anclaje, y en caso contrario, el primer servidor devuelve al equipo del usuario final un mensaje de redirección que comprende un URL e incluye un segundo nombre de dominio en el URL, siendo dicho segundo nombre de dominio el resultado de añadir al primer nombre de dominio un identificador de anclaje que identifica al primer servidor; estando el procedimiento caracterizado porque: cuando un dispositivo de Sistema de Nombres de Dominio, DNS, de la red de entrega de contenidos recibe una solicitud de resolución de nombre de dominio para un nombre de dominio que incluye dicho identificador de anclaje, el dispositivo DNS devuelve un mensaje de respuesta a la solicitud de resolución de nombre de dominio, incluyendo la dirección de Protocolo de Internet, IP, del primer servidor, independientemente del nivel de congestión de dicho servidor, siempre que el primer servidor esté disponible.

Description

DESCRIPCIÓN
Procedimiento, sistema y dispositivos para mejorar la entrega de contenidos multimedia
Campo técnico
La presente invención se refiere a la entrega de contenidos multimedia (especialmente vídeo, pero también texto, audio, software, o cualquier otro contenido o cualquier combinación de ellos) utilizando, por ejemplo, técnicas de flujo continuo adaptativo, en redes de comunicaciones. Más particularmente, la presente invención se refiere a un procedimiento y sistema y dispositivo para mejorar la entrega de contenidos en redes de comunicaciones, especialmente cuando se utiliza el flujo continuo adaptativo.
Antecedentes de la invención
Cada vez son más solicitados servicios como el vídeo a la carta, los servicios de televisión por Internet, las transmisiones de eventos en directo..., en los que se entrega un contenido multimedia a los usuarios finales en una sesión de comunicación (por ejemplo, mediante flujo continuo). Entre las técnicas de entrega de contenidos, el flujo continuo adaptativo es una de las más utilizadas.
El flujo continuo adaptativo, también llamado flujo continuo de tasa de bits adaptativa (ABR), es un mecanismo de entrega de vídeo a través de HTTP (Protocolo de Transporte de Hipertexto) ampliamente utilizado. Los proveedores de servicios y los operadores de redes despliegan el flujo continuo adaptativo normalmente como una característica de las redes de entrega de contenidos (CDN) para proporcionar una QoE (calidad de experiencia) ininterrumpida a los abonados (usuarios finales) en las redes, incluso con un ancho de banda fluctuante. Hay varios protocolos HTTP definidos por los grandes actores de la industria: HLS (HTTP Live Streaming) de Apple, HSS (HTTP Smooth Streaming) de Microsoft, HDS (HTTP Dynamic Streaming) de Adobe, DASH (Dynamic Adaptive Streaming HTTP) de MPEG... y comparten el mismo concepto básico de entrega a través de HTTP y adaptación del flujo continuo a las condiciones de reproducción. En el lado del servidor, un servidor de contenidos (por ejemplo, un servidor de vídeo) entrega un manifiesto o lista de reproducción que define un conjunto de flujos de velocidad de bits, cada uno de ellos compuesto por un número de fragmentos, que el servidor de vídeo también entrega. En el lado del cliente, un reproductor de vídeo (normalmente un dispositivo electrónico de usuario final) inicia la reproducción solicitando el manifiesto o la lista de reproducción, y solicitando secuencialmente los fragmentos necesarios para representar el vídeo. El fragmento solicitado corresponde a la tasa de bits que mejor se ajusta a las condiciones de descarga y al tiempo de visualización.
El reproductor de vídeo suele descargar pocos fragmentos para llenar un búfer interno, por lo que puede representar los fragmentos de vídeo ya descargados mientras avanza la reproducción del vídeo. En el caso de que el tiempo de reproducción de un fragmento aumente (por ejemplo, errores de red, movilidad del usuario, saturación del cliente...) el tiempo de descarga y representación de un fragmento puede ser mayor que el tiempo de visualización de ese fragmento. En ese caso, el buffer interno disminuye y el reproductor de vídeo debe solicitar fragmentos de menor tasa de bits (peor calidad), cuyo tamaño es menor y el tiempo de descarga y representación es más corto. Posteriormente, el tiempo de descarga puede mejorar y la tasa de bits solicitada por el cliente vuelve a ser mayor, para reproducir fragmentos de mejor calidad.
La entrega explicada de manifiestos y fragmentos suele hacerse con mensajes de petición y respuesta HTTP, debido al amplio soporte de este protocolo en casi cualquier dispositivo de consumo. Sin embargo, HTTP es un protocolo sin estado, por lo que cada petición se gestiona independientemente de las anteriores y esto no es un problema cuando el mismo servidor entrega las peticiones al cliente HTTP. Es decir, el flujo continuo adaptativo entrega secuencialmente fragmentos de vídeo a los reproductores de vídeo, y para evitar abrir una nueva conexión continuamente, el mismo servidor debe entregar todos los fragmentos a cada reproductor individual (por ejemplo, los dispositivos del usuario final). Sin embargo, la entrega de un flujo de vídeo a escala (por ejemplo, con mecanismos de equilibrio de carga) no suele ser realizada por el mismo servidor a cualquier cliente simultáneo. Las razones principales son las características del servicio de vídeo: la carga útil de entrega es alta en comparación con el contenido web, la mala experiencia del usuario en la visualización de vídeo cuando el contenido se retrasa, las solicitudes simultáneas de los usuarios para el mismo contenido (por ejemplo, eventos televisivos)...
Por ejemplo, un número de reproductores en el mercado resuelve continuamente el dominio del Localizador Universal de Recursos, URL (por Uniform Resource Locator en inglés) durante la sesión de vídeo y, en estos casos, si la resolución del dominio cambia (por ejemplo, para permitir el equilibrio de carga con otro servidor) el reproductor cierra la conexión y abre una nueva con otro servidor.
El cambio de servidor durante la sesión de vídeo implica la apertura de una nueva conexión y tiene otras consecuencias no deseadas, especialmente cuando el servidor está cerca del punto de saturación. Por ejemplo, cuando un transmisor de datos (un servidor de vídeo) informa de que está lleno de capacidad (cerca del punto de saturación), el rúter de petición deja de devolver su dirección IP (Protocolo de Internet) en la resolución de dominio. Entonces un número de usuarios finales ya conectados a ese transmisor se desconectan y se conectan a nuevos transmisores, provocando un efecto de avalancha. Esta avalancha era la responsable de un mayor tiempo de respuesta que podía derivar en un re-posicionamiento del reproductor, empeorando la experiencia del usuario al ver un contenido de vídeo o un canal de televisión.
Para evitar estos efectos no deseados, en la medida de lo posible, el mismo servidor debería entregar todos los fragmentos a cada uno de los reproductores (incluso en escenarios de saturación del servidor, éste no debería ser elegible para nuevas sesiones de vídeo, pero su IP debería seguir siendo devuelta para las sesiones de vídeo en curso).
Ya se conocen algunas soluciones del estado de la técnica para conseguir que el mismo servidor entregue (en la medida de lo posible) todos los fragmentos a cada uno de los reproductores durante una sesión de vídeo (también llamado enrutamiento pegajoso).
Por ejemplo, la patente de Estados Unidos US8239445 consigue este enrutamiento pegajoso mediante un mecanismo que modifica la ruta del URL añadiendo una marca (una cookie) que identifica unívocamente al usuario y, cuando éste solicita un contenido, el equilibrador de carga reconoce la marca y envía las peticiones al mismo servidor.
Otras soluciones del estado de la técnica son, por ejemplo, la patente estadounidense US8224986 B1 que propone un motor de contenidos que recibe una solicitud de contenidos de un cliente, genera un resultado en base a la solicitud de contenido, el resultado incluye uno de un valor de suministro de contenidos y un valor de redirección en respuesta a la solicitud de contenido, y proporciona selectivamente, al cliente, uno de (i) contenido cuando el resultado incluye el valor de suministro de contenidos, y (ii) un mensaje de redirección cuando el resultado incluye el valor de redirección, el mensaje de redirección incluye un nombre de dominio extendido que tiene un identificador de cliente que identifica al cliente.
La solicitud de patente europea EP1865684 A1 propone, en una red que interconecta una pluralidad de proveedores de contenidos y una pluralidad de clientes, proporcionando contenido a un cliente, cada uno de la pluralidad de proveedores de contenidos se acopla a al menos una red de entrega de contenidos de una pluralidad de redes de entrega de contenidos. El cliente se acopla a al menos a una de la pluralidad de redes de entrega de contenidos y una solicitud de contenido se envía desde el cliente a un nodo redirector que recibe solicitudes y un redirector en el nodo redirector proporciona una dirección para un servidor disponible para servir el contenido solicitado.
La solicitud de patente WO2014/159962 A1 divulga sistemas, procedimientos e instrumentos para seleccionar una puerta de enlace distribuida (D-GW) a través de una unidad inalámbrica de transmisión/recepción (WTRU). La WTRU puede estar configurada para detectar una solicitud de una dirección asociada con el contenido y puede recibir una lista de direcciones asociadas con el contenido. Si se incluye una dirección de la D-GW conectada actualmente en la lista de direcciones, la WTRU puede seleccionar la D-GW conectada actualmente. Si la dirección de la D-GW conectada actualmente no está en la lista de direcciones y una dirección de una D-GW de anclaje que no está conectada actualmente está incluida en la lista de direcciones, la WTRU puede seleccionar la D-GW que no está conectada actualmente.
Otras soluciones de la técnica anterior (como la utilizada por Akamai o la divulgada en la patente US8868756) propone el uso de cookies (llamadas “cookies adhesivas”) para mantener la sesión de video siempre con el mismo servidor. Y por ejemplo, Cisco logra el enrutamiento fijo almacenando para cada usuario individual que es el IP del servidor resuelto, y para las siguientes solicitudes de resolución de DNS utilizan esta información para devolver el mismo IP del servidor. Los mecanismos del estado de la técnica descritos requieren que la solicitud se encauce a nivel de HTTP, incluso fijando la IP del servidor en una redirección. Además, las soluciones del estado de la técnica implican varias otras deficiencias:
Los mecanismos de "cookies adhesivas" requieren que los reproductores acepten el uso de cookies y devuelvan para las siguientes peticiones la misma cookie devuelta anteriormente. La aceptación y el uso de cookies pueden no ser soportados por algunos dispositivos con reproductores ad hoc (por ejemplo, decodificadores) o podrían requerir la aceptación explícita del usuario. La presente invención no utiliza cookies y se basa únicamente en modificar el nombre de dominio del URL con una redirección HTTP. Las redirecciones forman parte de la RFP de HTTP, por lo que cualquier cliente HTTP estándar las soporta. El mecanismo utilizado por Cisco necesita almacenar y utilizar un mapa completo de usuarios y servidores IP, lo que dificulta el escalado de la resolución entre rúteres de petición distribuida o el tiempo de respuesta para una resolución rápida. Modificar el URL como se propone en el documento US8239445 implicaría cambiar el contenido del manifiesto/lista de reproducción para añadir el ancla a la declaración de fragmentos de URL, haciendo el conjunto más complejo y lento. Además, el mecanismo propuesto en US8239445 también implica el uso de cookies, lo que, como se ha dicho anteriormente, limita significativamente los reproductores en los que se puede aplicar, ya que algunos dispositivos no soportan las cookies (por ejemplo, al utilizar flujo de transmisión suave, la mayoría de los reproductores no soportan el uso de cookies).
Por lo tanto, existe la necesidad de un mecanismo de enrutamiento pegajoso mejorado con el fin de superar las limitaciones de las soluciones existentes del estado de la técnica.
Sumario
Los problemas encontrados en las técnicas del estado de la técnica son generalmente resueltos o eludidos, y las ventajas técnicas son generalmente logradas, por las realizaciones divulgadas que proporcionan un procedimiento, sistema y dispositivos para mantener el mismo transmisor (servidor) durante una sesión de video. La solución propuesta modifica el nombre de dominio añadiendo un ancla al URL, normalmente durante las redirecciones de enrutamiento de la solicitud; esta ancla permite al enrutador de la solicitud devolver la misma dirección IP del servidor para cualquier resolución de dominio durante una sesión de vídeo del reproductor.
En la invención propuesta, el enrutamiento de la petición utiliza un mecanismo de enrutamiento de peticiones del Sistema de Nombres de Dominio (DNS) para pegar al reproductor a un servidor usando un ancla, por lo que es diferente al mecanismo del estado de la técnica donde la petición es enrutada a nive1HTTP, incluso fijando la IP del servidor en una redirección. La invención propuesta permite no fijar la IP en la redirección y permitir el balanceo a un servidor diferente en los casos en los que el servidor no esté realmente disponible. Además, la invención propuesta no utiliza cookies para pegar el servidor (evitando los problemas mencionados en el estado de la técnica respecto al uso de cookies), sino que se basa únicamente en modificar el nombre de dominio del URL con una redirección HTTP. Las redirecciones forman parte del HTTP RFP (HTTP Solicitud de propuesta) por lo que cualquier cliente HTTP estándar lo soporta. Además, la invención propuesta (al contrario que el mencionado estado de la técnica de CISCO) no necesita almacenar este tipo de mapas y no necesita compartir información entre diferentes rúteres, incluso en diferentes lugares.
En consecuencia, algunas de las principales ventajas del mecanismo propuesto son:
Permite utilizar un mecanismo de enrutamiento de solicitudes basado en DNS.
Es inaccesible de los reproductores, ya que la resolución del dominio se implementa en las capas de Internet de cualquier dispositivo.
Al no utilizar cookies, no obliga a los reproductores a soportar este mecanismo (cookies).
En la presente invención, la ruta del URL no se modifica (sino sólo el nombre de dominio) lo que implica un mejor rendimiento especialmente en los protocolos de vídeo que utilizan fragmentos construidos a partir de un manifiesto. Modificar la ruta del URL (como se propone en el documento US8239445) implicaría cambiar el contenido del manifiesto/lista de reproducción para añadir el ancla a la declaración de fragmentos de URL.
En la presente invención, el ancla no identifica al usuario (al contrario que la solución propuesta en el documento US8239445), lo que hace que la solución sea más fácil de escalar.
En un primer aspecto, se propone un procedimiento para mejorar la entrega de contenidos multimedia a los equipos de los usuarios finales (en una red de entrega de contenidos que comprende varios servidores). La entrega se realizará a través de una o varias redes de comunicaciones utilizando cualquier técnica de entrega, por ejemplo, una técnica de flujo continuo y más concretamente una técnica de flujo continuo adaptativo. El procedimiento comprende:
- Un primer servidor (un servidor óptimo) que recibe un primer mensaje (por ejemplo, un mensaje HTTP y, más concretamente, un mensaje GET) de un equipo de usuario final, el mensaje incluye un URL que incluye un primer nombre de dominio (nombre de host);
- Tras recibir dicho primer mensaje, el primer servidor determina si dicho primer nombre de dominio incluye un identificador de un servidor de la red de entrega de contenidos, denominado identificador de anclaje, y en caso contrario, el primer servidor devuelve al equipo del usuario final un mensaje de redirección que incluye un segundo nombre de dominio en el URL, siendo dicho segundo nombre de dominio el resultado de añadir al primer nombre de dominio un identificador de anclaje que identifique al primer servidor (es decir, el servidor añade un identificador de sí mismo en el nombre de dominio como identificador de anclaje, si el nombre de dominio no incluye ya un identificador de anclaje del primer servidor o de otro servidor);
en el que, cuando un dispositivo de sistema de nombres de dominio, DNS, de la red de entrega de contenidos recibe una solicitud de resolución de nombre de dominio (del equipo de usuario final) para un nombre de dominio que incluye dicho identificador de anclaje, el dispositivo DNS (por ejemplo, un rúter) devuelve (al equipo de usuario) un mensaje de respuesta a la solicitud de resolución de nombre de dominio, incluyendo la dirección IP del primer servidor, independientemente del nivel de congestión de dicho servidor, siempre y cuando el primer servidor esté disponible (el servidor no esté caído y, en consecuencia, esté disponible para entregar un contenido). En otras palabras, es decir, el dispositivo DNS determina si dicho primer servidor está disponible y, en caso afirmativo, siempre devuelve la dirección IP de dicho primer servidor identificado por el identificador de anclaje, incluso cuando el servidor está congestionado.
El equipo del usuario final puede ser un teléfono móvil, una tableta, un teléfono inteligente, un ordenador, un ordenador personal, PC, un ordenador portátil o cualquier dispositivo electrónico capaz de recibir contenidos multimedia a través de la red de comunicación.
En una realización, los mensajes son mensajes HTTP.
En una realización, el primer nombre de dominio es un nombre de dominio redirigido, es decir, un nombre de dominio ya redirigido por otro servidor (no un nombre de host de solicitud original).
El primer mensaje puede ser un mensaje que solicita un manifiesto para una sesión de flujo continuo de contenido multimedia o un fragmento del contenido multimedia y en el que, si dicho primer nombre de dominio ya incluye un identificador de un servidor de la red de entrega de contenidos, el primer servidor envía el manifiesto o fragmento solicitado al equipo del usuario final. En una realización, el primer nombre de dominio es un nombre de dominio de solicitud original (es decir, una CDN canónica o un nombre de dominio de cliente). En esta realización, una mejora del enrutamiento de la solicitud puede estar habilitada en el primer servidor. En otra realización, el primer nombre de dominio no es un nombre de dominio de solicitud original.
En una realización, el dispositivo DNS es un enrutador (por ejemplo, un enrutador de solicitud de una red de entrega de contenidos).
En una realización, el primer nombre de dominio pertenece a un grupo de dominios específicos para los que se permite añadir un identificador de anclaje, (es decir, la redirección de anclaje sólo se permite a un grupo específico de nombres de dominio, no a cualquier nombre de dominio).
En una realización, el contenido multimedia es un contenido de vídeo.
En un segundo aspecto, se propone un dispositivo DNS según la reivindicación independiente 10, para mejorar la entrega de contenidos multimedia al equipo del usuario final en una red de entrega de contenidos que comprende varios servidores, estando el dispositivo caracterizado porque comprende:
- Un receptor para recibir (desde un equipo de usuario), a través de la red de entrega de contenidos, una solicitud de resolución de nombre de dominio para un nombre de dominio;
- Un transmisor para transmitir mensajes a través de la red de entrega de contenidos; comprendiendo el dispositivo un procesador configurado para:
- Determinar si dicho nombre de dominio incluye un identificador de anclaje que identifica un servidor; si es así, determinar si dicho servidor identificado por el identificador de anclaje está disponible y si dicho nombre de dominio incluye un identificador de anclaje que identifica un servidor y el servidor está disponible, enviar de vuelta utilizando el transmisor, un mensaje que responde a la solicitud de resolución de nombre de dominio que incluye una dirección IP del servidor identificado por el identificador de anclaje independientemente del nivel de congestión de dicho servidor.
En un tercer aspecto, se proporciona un sistema, según la reivindicación independiente 11, para mejorar la entrega de contenidos multimedia a equipos de usuario final en una red de entrega de contenidos, el sistema comprende - Un servidor que comprende:
- Un receptor para recibir, a través de la red de entrega de contenidos, un primer mensaje de un equipo de usuario final, el mensaje incluye un URL que incluye un primer nombre de dominio (redirigido);
- Un transmisor para transmitir mensajes a través de la red de entrega de contenidos;
- Un dispositivo DNS que comprende:
- Un receptor para recibir, a través de la red de entrega de contenidos, una solicitud de resolución de nombre de dominio para un nombre de dominio;
- Un transmisor para transmitir mensajes a través de la red de entrega de contenidos;
- el servidor que comprende un procesador configurado para, después de recibir dicho primer mensaje, determinar si dicho primer nombre de dominio incluye un identificador de un servidor de la red de entrega de contenidos, llamado identificador de anclaje, y en caso contrario, enviar de vuelta al equipo del usuario final utilizando su transmisor, un mensaje de redireccionamiento que incluye un segundo nombre de dominio en el URL, que es el resultado de añadir al primer nombre de dominio un identificador de anclaje que identifica al servidor;
- el dispositivo DNS que comprende un procesador configurado para:
determinar si el nombre de dominio incluido en el mensaje de solicitud de resolución de dominio incluye un identificador de anclaje que identifique a un servidor y, si dicho nombre de dominio incluye un identificador de anclaje que identifique a un servidor y el servidor está disponible, devolver mediante su transmisor un mensaje de respuesta a la solicitud de resolución de nombre de dominio que incluya una dirección IP del servidor identificado por el identificador de anclaje, independientemente del nivel de congestión de dicho servidor.
Un último aspecto de la invención se refiere a un medio de almacenamiento de datos digitales no transitorio, según la reivindicación independiente 12, para almacenar un programa de ordenador que comprende instrucciones que hacen que un ordenador que ejecuta el programa realice el procedimiento descrito anteriormente.
Breve descripción de los dibujos
Para completar la descripción que se está realizando y con el objeto de ayudar a una mejor comprensión de las características de la invención, de acuerdo con un ejemplo preferente de realización práctica de la misma, se acompaña a dicha descripción como parte integrante de la misma, un conjunto de dibujos en los que, a título ilustrativo y no limitativo, se ha representado lo siguiente:
La figura 1 muestra un diagrama esquemático de las principales transacciones de una sesión de flujo continuo de vídeo en una Red de Entrega de Contenidos según un primer escenario del estado de la técnica.
La figura 2 muestra un diagrama esquemático de las principales transacciones de una sesión de flujo continuo de vídeo en una Red de Entrega de Contenidos según un segundo escenario del estado de la técnica.
Las figuras 3a, 3b y 3c muestran un diagrama esquemático de las principales operaciones de una sesión de flujo continuo de vídeo según una realización de la invención.
La figura 4 muestra el número de reproductores HLS conectados a un servidor CDN específico durante un evento de fútbol en directo, cuando se aplica la solución propuesta según una realización de la invención.
En las figuras, los números de referencia similares se refieren a elementos similares.
Descripción de las realizaciones
Las presentes invenciones pueden materializarse en otros dispositivos, sistemas y/o procedimientos específicos. Las realizaciones descritas deben considerarse en todos los aspectos como meramente ilustrativas y no restrictivas. En particular, el alcance de la invención se indica en las reivindicaciones adjuntas y no en la descripción y las figuras. Los proveedores de servicios y los operadores de redes utilizan cada vez más la entrega de contenidos (y más concretamente el flujo continuo adaptativo), para entregar contenidos multimedia (por ejemplo, vídeo) a los usuarios finales a través de las redes de comunicaciones. Las redes de comunicaciones pueden ser redes de comunicaciones móviles (2G, 3G, 4G, LTE...) o cualquier otro tipo de redes de comunicaciones cableadas o inalámbricas. Las redes de entrega de contenidos (CDN) se utilizan a menudo para escalar la entrega de contenidos a través de una o más redes de comunicación y son muy útiles para el flujo continuo de vídeo. Este tipo de redes aprovechan el mecanismo DNS y HTTP para entregar el contenido al cliente sin problemas, dirigiendo la petición del usuario final a los servidores óptimos, dependiendo de diferentes criterios, como la carga de los servidores, la topología de la red, la disponibilidad del contenido... Los mecanismos para enrutar estas peticiones dependen de la tecnología e implementación de cada CDN, pero suelen basarse en características de HTTP y DNS (Sistema de Nombres Dinámico), como redireccionamientos, cabeceras, cookies, CNAME (Nombre Canónico)... Como cualquier petición de manifiesto (que define un conjunto de flujos de bits) o fragmento a través de HTTP se descarga con una petición diferente, el mecanismo de enrutamiento de peticiones de una CDN podría enrutar cada petición a diferentes servidores de la CDN. Como se ha explicado anteriormente, esta situación no es deseable desde el punto de vista de la CDN (peor rendimiento) y de la experiencia del usuario (las nuevas conexiones requieren más tiempo de descarga).
Hay dos enfoques principales para evitarlo:
Del lado del cliente: Algunos reproductores de vídeo (por ejemplo, los equipos de los usuarios finales) son conscientes del concepto de "sesión" de vídeo (en el sentido de que saben qué peticiones pertenecen a la misma sesión de vídeo, es decir, al mismo flujo de contenidos), y una vez que el primer manifiesto se dirige a un servidor óptimo, se establece la conexión HTTP y se descarga el manifiesto, las peticiones de los siguientes fragmentos se realizan al mismo servidor mientras éste responde adecuadamente a las peticiones.
Del lado de la CDN: El concepto de "sesión" de vídeo es gestionado internamente por la CDN, de manera que todas las peticiones al mismo contenido del mismo usuario final se dirigen al mismo servidor mientras ese servidor siga siendo óptimo para entregar esa sesión.
En el presente documento, una sesión de contenido (por ejemplo, una sesión de vídeo) se define como una serie de transacciones relacionadas para realizar una unidad de trabajo (transmitir un contenido específico a un usuario final específico)
Hoy en día hay varios reproductores, de tipo A, (reproductores de vídeo si el contenido entregado incluye vídeo) que implementan el enfoque del lado del cliente, y una vez que el proceso de enrutamiento de la solicitud ha devuelto el servidor óptimo el manifiesto ABR y los fragmentos se solicitan al mismo servidor. Esto se muestra en la figura 1, donde el reproductor (usuario final, 11) envía una petición de resolución de host (resolución de dominio) a un nodo (12) de la red (normalmente un rúter, llamado rúter de solicitud CDN), este nodo (tras un proceso de enrutamiento de peticiones) indica al usuario final que el servidor óptimo es un determinado servidor (servidor n, 13) y entonces el reproductor solicita el manifiesto y todos los fragmentos del contenido de vídeo al mismo servidor, como se muestra en la figura 1. En el presente documento, vamos a utilizar igualmente los términos reproductor, reproductor de vídeo o equipo de usuario final (o simplificando "usuario final") para referirnos al mismo concepto, el dispositivo electrónico utilizado por el usuario final para solicitar y reproducir el flujo continuo de vídeo. Dicho dispositivo electrónico puede ser un teléfono móvil, una tableta, un teléfono inteligente, un ordenador, un ordenador personal, PC, un ordenador portátil o, en general, un dispositivo electrónico que pueda comunicarse a través de una red de comunicaciones. Sin embargo, otros reproductores, los de tipo B, repiten algunos de los pasos de los mecanismos de enrutamiento de solicitudes, como resolver de nuevo el dominio redirigido o solicitar con el dominio original, durante una única sesión de vídeo. Para este segundo grupo de reproductores, el punto final óptimo (el servidor óptimo) devuelto por la CDN puede ser diferente en algunas circunstancias cada vez que los reproductores piden resolver el dominio. Esto se muestra en la figura 2, donde el reproductor (usuario final, 21) envía una solicitud para resolver el host/dominio (en otras palabras, para saber a qué nodo o servidor debe dirigirse para recibir los fragmentos de contenido de vídeo y/o el manifiesto) a un rúter de solicitud CDN (22) de la red, este nodo (después de un proceso de enrutamiento de la solicitud) le dice al reproductor que el servidor óptimo es un determinado servidor (servidor n, 23), el reproductor solicita el manifiesto a este servidor. Después de que el reproductor reciba el manifiesto, entonces repite el proceso de "resolver host", y esta vez el rúter 22, le dice al reproductor que el servidor óptimo (por ejemplo, debido a un cambio en las condiciones de tráfico o debido al equilibrio de carga) es ahora otro servidor (servidor m, 24). Este proceso puede repetirse y el servidor óptimo (al que el reproductor solicita los fragmentos de vídeo) puede cambiar de nuevo (como se muestra en la figura 2, donde después del fragmento 1, el rúter 22 le dice al reproductor que el servidor óptimo es el servidor n 23 de nuevo) dependiendo de las circunstancias específicas.
Dependiendo del enrutamiento de la solicitud de la CDN, estas circunstancias pueden variar, de modo que el servidor óptimo devuelto por la CDN puede variar durante una sesión de vídeo (para los reproductores de tipo B). Un caso típico es que la CDN deje de devolver un servidor específico como óptimo cuando el número de usuarios finales conectados al servidor haya alcanzado su límite, y entonces devuelva un servidor diferente. En este escenario, se observó el siguiente comportamiento en una Red de Entrega de Contenidos de un operador de telecomunicaciones:
Los reproductores de tipo B cambian a otro servidor (servidor m) cuando el primer servidor óptimo (servidor n) alcanza su límite (de saturación).
El número de usuarios en el servidor m aumenta hasta un número de reproductores superior a su límite, mientras que el número de reproductores conectados al servidor n disminuye, ya que los reproductores de tipo B han dejado de solicitar a ese servidor.
El reproductor tipo B vuelve a cambiar a un servidor óptimo diferente, que podría ser el servidor n si el número de reproductores ha disminuido y vuelve a estar por debajo de su límite.
El número de usuarios en el servidor n puede volver a sobrepasar su límite y el proceso de enrutamiento de solicitudes de alternación comienza de nuevo.
Esto se observó, por ejemplo, durante un evento de fútbol en directo, cuando el número de reproductores HLS conectados a un determinado servidor tenía un perfil en forma de diente de sierra (una y otra vez, pasando de aproximadamente 3000 a 4500 reproductores y luego bajando de nuevo a 3000 reproductores en un periodo de tiempo muy corto).
Así, surge un grave problema cuando los servidores de la CDN se acercan al punto de saturación (por ejemplo, en los momentos de mayor audiencia), lo que puede afectar a la experiencia de los usuarios finales (por ejemplo, provocando un efecto avalancha que es responsable de mayores tiempos de respuesta).
Estos y otros problemas se resuelven con la solución propuesta en el presente documento. En la solución propuesta, se añade un ancla al nombre de dominio del URL durante las redirecciones de enrutamiento de la petición (es decir, se modifica el nombre de dominio). El dominio (o nombre de dominio) en una petición HTTP es una cabeza específica también llamada HOST (por eso el nombre de dominio también se llama nombre de host). En una petición HTTP se incluye la ruta/localización del URL después del nombre de dominio. Este anclaje permite a un dispositivo DNS (por ejemplo, un rúter de peticiones) devolver la misma IP del servidor para cualquier resolución de dominio durante una sesión de vídeo del reproductor, aunque este servidor no puede ser elegible para otros nuevos usuarios finales debido a su nivel de carga. En el caso de que el servidor se caiga o no esté disponible, la resolución cambiaría devolviendo una IP de servidor diferente. Este mecanismo evita el cambio de servidor durante la sesión de vídeo, lo que es especialmente importante cuando el servidor está cerca del punto de saturación. En este punto, el servidor no debe ser elegible para nuevas sesiones de vídeo, pero su dirección IP debe seguir siendo devuelta para las sesiones de vídeo en curso. El ancla se puede añadir como una redirección adicional incluso con el servidor óptimo, que respondería con esta redirección en lugar de empezar a entregar la lista de reproducción/manifiesto. El enrutador de peticiones es el nodo de una CDN encargado de dirigir las peticiones al servidor óptimo. En una realización preferida de la presente invención, el enrutador de peticiones es un dispositivo DNS que realiza el anclaje cambiando el nombre de dominio (y también rastrea el estado de los puntos finales o servidores con el rastreador DNS). En general, el nodo que realiza este anclaje o pegado será un dispositivo DNS ya que se realiza cambiando el nombre de dominio. El rastreador DNS es una parte (un componente) de un dispositivo DNS que se encarga de rastrear los puntos finales para decidir cuál es el óptimo. Así, cuando en el presente texto se menciona que cierta acción es realizada por el rastreador DNS se quiere decir que es realizada por el dispositivo DNS (siendo el dispositivo DNS, en una realización, el rúter de peticiones de una CDN).
La figura 3 muestra un diagrama esquemático de las principales transacciones de una sesión de flujo continuo de vídeo según una realización de la invención. Como la cantidad de transacciones era demasiado elevada para ser vista claramente en una sola figura, se ha dividido en tres figuras (3a, 3b y 3c), siendo la figura 3b una continuación (en el tiempo) de la figura 3a y la figura 3c una continuación de la figura 3b. El diagrama completo debe verse como si comenzara en la figura 3a, continuara con la figura 3b y terminara en la figura 3c.
Las figuras 3a, 3b y 3c muestran un ejemplo de nodos de una red en la que se puede aplicar la presente solución, teniendo un carácter ilustrativo y no limitativo por lo que la presente solución puede ser utilizada en cualquier tipo de red que tenga diferente tipo, nombre y número de nodos que el ejemplo mostrado en las figuras 3a, 3b y 3c. En realidad, en las figuras 3a, 3b y 3c, por razones de simplicidad, sólo se muestran algunos nodos; sin embargo, una red real de entrega de contenidos tendrá más nodos (más DNS, puntos finales, equipos de usuario...).
En el ejemplo mostrado en las figuras 3a, 3b y 3c, hay un equipo de usuario final o reproductor de vídeo (usuario final 131), un nodo DNS ISP (proveedor de servicios de Internet) 32, un DNS TLD (dominio de nivel superior) 33, dos nodos DNS adicionales, por ejemplo rúteres de solicitud, (DNS R1 34, DNS R235) y tres puntos finales (EP1 36, EP237, EP338).
Los puntos finales pueden ser cualquier nodo electrónico (normalmente un servidor) que sea capaz de entregar (transmitir) el contenido de vídeo solicitado al usuario final. Los nodos DNS pueden ser cualquier servidor, rúter... que realice la resolución del dominio. La resolución de nombres de dominio es jerárquica, por lo que en una resolución completa de nombres de dominio suelen intervenir diferentes nodos DNS: primero un DNS ISP que enruta la petición de resolución a un DNS TLD (dominios de primer nivel como .com, .org...) que enruta la petición de resolución a otro DNS... hasta llegar al DNS que tiene la traducción final del nombre de dominio específico a la IP correspondiente al punto final (PE) al que el usuario final tiene que dirigirse para recibir el contenido de vídeo.
Para una mejor comprensión de la solución propuesta, se explicarán aquí los principales pasos de la transmisión de vídeo según una realización de la invención en un escenario ejemplar (mostrado en las figuras 3a, 3b y 3c).
En primer lugar (figura 3a), el equipo del usuario final (usuario final 1) envía un mensaje (301) con un nombre de dominio (899.cn.telefonica.com) para la resolución del nombre de dominio al ISP DNS, que pide (302) a un TLD DNS que indique (303) al ISP DNS la dirección IP del siguiente DNS (DNS R1) a consultar. El ISP DnS envía (304) la resolución del dominio al DNS R1 (que en este ejemplo es el que tiene la traducción final del nombre de dominio específico). El DNS R1 envía al DNS del ISP (305) las direcciones IP (en orden aleatorio) de dos posibles puntos finales (EP1 y EP2) dentro de la región del usuario final desde donde se puede solicitar el contenido de vídeo solicitado. El ISP DNS envía (306) dichas direcciones IP de ambos puntos finales al usuario final 1.
A continuación, el usuario final envía un mensaje "GET" (307) al primer punto final cuya dirección IP se ha recibido (EP1) para obtener el manifiesto (lista de reproducción) del contenido de vídeo solicitado. A continuación, el EP1 realiza una redirección regular y envía un mensaje de redirección (308) con un nuevo nombre de dominio al usuario final (en el mensaje de redirección el símbolo "_" significa redirección intrarregional). El usuario final envía (309) un mensaje de resolución de nombre de dominio (para el nuevo nombre de dominio, 899-p14-h33.1.cdn.telefonica.com) al DNS del ISP que lo encamina (310) al DNS R1. Este rastreador DNS aplica un mecanismo de selección de puntos finales regular y proporciona (311) las direcciones IP de los Puntos Finales más adecuados (dependiendo por ejemplo de la carga de los puntos finales o de cualquier otro factor; en este caso dichos puntos finales serán EP2 y EP3) al DNS del ISP, que los envía (312) en orden aleatorio al usuario final. El número de Puntos Finales (EP) suministrados por el d Ns dependerá de un parámetro de diseño del sistema (llamado por ejemplo numIPs) que especifica la cantidad de direcciones IP de los Puntos Finales (EP) devueltos por el DNS. En el ejemplo mostrado en las figuras 3a, 3b y 3c, "numIPs"=2 (pero puede tener cualquier valor 1, 2, 3, 4... dependiendo del diseño específico del sistema), lo que significa que el DNS devolverá las direcciones IP de los dos PE más adecuados.
Hasta ahora (301-312), todos los pasos explicados describían el mecanismo regular de enrutamiento de peticiones para seleccionar el servidor de vídeo óptimo. Ahora (313-XXX) se explicará cómo, para añadir la pegada al usuario, se añade el ancla al dominio con una redirección adicional, recibiendo finalmente el usuario final la primera pieza (fragmento) de contenido.
Tras recibir (312) las direcciones IP de los EP más adecuados (en este caso EP2 y EP3), el usuario final envía un mensaje "GET" (313) al primer Punto Final cuya dirección IP ha recibido (EP3) para obtener el manifiesto (lista de reproducciones) del contenido de vídeo solicitado. Cuando el EP3 recibe dicho mensaje "GET" del usuario final, aplica una redirección adicional (redirección de anclaje) añadiendo un parámetro o prefijo al delimitador (llamado prefijo de anclaje, identificador de anclaje o sólo anclaje) al punto final al que se va a pegar el usuario final para esta sesión de vídeo (dicho prefijo de anclaje será un identificador del punto final o servidor). Luego el EP3, envía un mensaje de redirección (314) incluyendo el ancla al usuario final. Como se puede ver en el mensaje 314, en este caso el ancla añadida al nombre de dominio es "aXX" que representa al servidor final EP3 (esto es sólo un ejemplo ilustrativo).
Como ya ocurrió anteriormente, cuando el usuario final recibe el mensaje de redirección con un nuevo nombre de dominio, el usuario final envía (315) un mensaje de resolución de nombre de dominio (para el nombre de dominio que incluye el ancla, en este caso, 899-p14-h33-aXX.1.cdn.telefonica.com) al DNS del ISP que lo encamina (316) al DNS apropiado (DNS R1). En este caso, el DNS (su rastreador) no aplica un mecanismo regular de selección de punto final, sino que identifica el prefijo de anclaje en el nombre de dominio como representante del punto final de anclaje (en este caso EP3) y si dicho punto final está disponible, el DNS lo selecciona (independientemente de si está congestionado o no). El DNS responderá a la resolución del nombre de dominio sólo con la dirección IP del punto final identificado por el prefijo de anclaje (en este caso EP3). Dicha dirección IP será enviada al DNS del ISP (317) y de ahí al usuario final (318).
Preferiblemente, el número de servidores a los que el servidor está pegado (anclado) es uno. Sin embargo, en una realización alternativa puede ser más de uno o puede existir un parámetro de diseño del sistema (llamado, por ejemplo, numIPs_stickiness o numIPs_anchored) que especifica la cantidad de Puntos finales (1,2, 3... ) a los que la sesión de vídeo está pegada (y, en consecuencia, la cantidad de direcciones IP devueltas por el DNS).
Tras recibir (318) la dirección IP del EP anclado (en este caso EP3), el usuario final envía un mensaje "GET" (319) al punto final para obtener el manifiesto (lista de reproducción) del contenido de vídeo solicitado. El PE recibe dicho mensaje g Et y gestiona la petición independientemente de si es el PE ancla o no (como el mensaje GET incluye un nombre de dominio con un prefijo de ancla, el punto final sabe que ya se ha añadido un ancla por lo que no debe redirigir de nuevo el mensaje como se ha hecho anteriormente). En otras palabras, el PE que recibe un nombre de dominio con un prefijo de ancla (identificador de ancla) sirve el contenido o manifiesto solicitado aunque el prefijo de ancla no corresponda a este PE, ya que si el dispositivo DNS ha devuelto esta dirección IP del punto final (con un prefijo de ancla que identifica a otro PE) es porque el PE identificado por el prefijo de ancla no está disponible (está caído); esto se hace para evitar un efecto alternación en las redirecciones. Así, el EP3 devuelve el manifiesto (320) al usuario final, el usuario final pide el primer fragmento del contenido de vídeo (321) al EP3 y el punto final devuelve el fragmento (322). A partir de este momento, el contenido es entregado continuamente por el mismo servidor de vídeo óptimo, a pesar de que este servidor pueda estar saturado (congestionado). Es decir, aunque el reproductor (usuario final) vuelva a resolver el último nombre de host durante la sesión de vídeo, el DNS volverá a devolver la misma dirección IP (del punto final anclado) y el usuario final solicitará el siguiente fragmento al mismo punto final. Esto se muestra en la figura 3b; tras recibir el primer fragmento, el usuario final decide resolver de nuevo el último nombre de host. Para ello, el usuario final envía (323) un mensaje de resolución de nombre de dominio (para el nombre de dominio que incluye el ancla 899-p14-h33-aXX.1.cdn.telefonica.com) al DNS del ISP que lo encamina (324) al DNS apropiado (DNS R1). En este caso, el DNS (su rastreador) no aplica un mecanismo regular de selección de punto final, sino que identifica el prefijo de anclaje en el nombre de dominio como representante del punto final de anclaje (en este caso EP3) y si dicho punto final está disponible, el DNS lo selecciona (independientemente de si está congestionado o no). El DNS responderá a la resolución del nombre de dominio sólo con la dirección IP del punto final identificado por el prefijo de anclaje, en este caso EP3 (como numIPsstickiness=1). Dicha dirección IP será enviada al DNS del ISP (325) y de ahí al usuario final (326). A continuación, el usuario final utiliza la dirección IP devuelta para solicitar el segundo fragmento del contenido de vídeo (327) a EP3 y el punto final devuelve el fragmento (328).
En el ejemplo mostrado en la figura 3b, después de entregar dicho segundo fragmento el punto final EP3 se congestiona (329). Sin embargo (como se muestra en la figura 3b), si el usuario final 1 decide resolver de nuevo el último nombre de host, el DNS devolverá al usuario final la dirección IP de EP3 (si está disponible, independientemente de que esté congestionado) y el usuario final pedirá el fragmento de vídeo a EP3 (véase la figura 3b, pasos 330, 331, 332, 333, 334 y 335), exactamente como ocurría antes de que el punto final EP3 estuviera congestionado.
Por lo tanto, en el mecanismo propuesto, cuando el servidor está congestionado, su dirección IP sigue siendo devuelta para las sesiones de vídeo en curso (evitando el cambio de servidor durante la sesión de vídeo); sin embargo, el servidor congestionado no debería ser elegible para nuevas sesiones de vídeo o nuevos usuarios finales.
Esto se muestra en la figura 3c, donde se observa que un nuevo usuario final (usuario final 2, 39) con un reproductor de pegajosidad, inicia una sesión de flujo continuo para el mismo contenido y, en este caso, desde el mismo PID (partición de red ID). En función de la dirección IP del usuario final, éste pertenecerá a un determinado PID (y sólo a uno). Gracias al ID de la partición de red, el rastreador DNS es capaz de asignar PE que están cerrados al usuario final (a nivel de red). Como se explicará ahora, este nuevo usuario será dirigido a un servidor de vídeo diferente, ya que el primero (EP3) está saturado de nuevos usuarios.
El nuevo equipo de usuario final (usuario final 2) envía un mensaje (336) con un nombre de dominio (899.cdn.telefonica.com) para la resolución del nombre de dominio al iSp DNS, que solicita (337) a un DNS apropiado (DNS R1) la resolución del dominio al DNS R1 (que en este ejemplo es el que tiene la traducción final del nombre de dominio específico). El DNS R1 envía al DNS del ISP (338) las direcciones IP (en orden aleatorio) de dos posibles puntos finales (EP1 y EP2) dentro de la región del usuario final desde donde se puede solicitar el contenido de vídeo solicitado. El ISP DNS envía (339) dichas direcciones IP de ambos puntos finales al usuario final 2.
A continuación, el usuario final 2 envía un mensaje "GET" (340) al primer punto final cuya dirección IP se ha recibido (EP1) para obtener el manifiesto (lista de reproducción) del contenido de vídeo solicitado. A continuación, el EP1, como la mejora del enrutamiento de la solicitud está desactivada, realiza una redirección regular y envía un mensaje de redirección (341) con un nuevo nombre de dominio al usuario final. El usuario final envía (342) un mensaje de resolución de nombre de dominio (para el nuevo nombre de dominio 899-p14-h33.1.cdn.telefonica.com) al DNS del ISP que lo enruta (343) al DNS R1. El rastreador DNS R1 aplica el mecanismo habitual de selección de puntos finales para seleccionar los más adecuados teniendo en cuenta que EP3 está congestionado, por lo que no se seleccionará EP3. El DNS R1 envía (344) las direcciones IP de dichos PE seleccionados al DNS del ISP, que los envía (345) en orden aleatorio al usuario final 2. Al igual que en el caso anterior, el número de Puntos Finales (PE) suministrados por el DNS dependerá de un parámetro de diseño del sistema (denominado, por ejemplo, numIPs) que especifica la cantidad de direcciones iP de los Puntos Finales (PE) devueltas por el DNS. En el ejemplo mostrado en las figuras 3a, 3b y 3c, "numIPs"=2 lo que significa que el DNS devolverá las direcciones IP de los dos PE más adecuados.
Tras recibir (345) las direcciones IP de los EP más adecuados (en este caso EP2 y EP1), el usuario final envía un mensaje "GET" (346) al primer Punto final cuya dirección IP ha recibido (EP2) para obtener el manifiesto (lista de reproducciones) del contenido de vídeo solicitado. Cuando el EP2 recibe dicho mensaje "GET" del usuario final, aplica una redirección adicional (redirección de anclaje) añadiendo un prefijo de anclaje (anchor prefix) al punto final al que se va a pegar el usuario final para esta sesión de vídeo (dicho prefijo de anclaje será y identificador del punto final o servidor). Luego el EP2, envía un mensaje de redirección (347) incluyendo el ancla al usuario final. Como se puede ver en el mensaje 347, en este caso el ancla añadida al nombre de dominio es "aYY" que representa al servidor final EP2 (esto es sólo un ejemplo ilustrativo). A partir de ahora (como se ha explicado anteriormente en el caso del usuario final 1 y el EP3, pasos 315-335), la sesión de flujo continuo del usuario final 2 se entregará desde el EP2 mientras esté disponible, incluso cuando el EP2 esté congestionado.
El mecanismo anterior se implementa en el dispositivo DNS (por ejemplo, el rúter de solicitud) y en el punto final (servidor de vídeo), como se explicará ahora.
- En el rúter de peticiones (un dispositivo DNS), el rastreador DNS devuelve la misma dirección IP del servidor de vídeo cuando el dominio está atascado, independientemente del nivel de carga del servidor. Sólo cuando el servidor no está disponible (o está deshabilitado o redirigido), se devuelve la dirección IP de un servidor diferente. Es decir, cuando el dispositivo DNS (el enrutador de peticiones) recibe un nombre de dominio (también llamado nombre de host) para la resolución del dominio, el dispositivo (el rastreador) determina si el nombre de host es un nombre de host anclado o no (es decir, determina si el nombre de host recibido incluye un ancla). Si el nombre de host no está anclado, el rastreador DNS aplica el mecanismo habitual de selección de puntos finales y devuelve las direcciones IP de los PE más adecuados. Si el nombre de host está anclado (incluye un prefijo de anclaje), el dispositivo DNS determina si el PE identificado por el prefijo de anclaje está desactivado o detenido. Si es así, el rastreador DNS aplica el mecanismo regular de selección de puntos finales y devuelve las direcciones IP de los PE más adecuados. Si no es así (el PE identificado por el prefijo de anclaje no está deshabilitado o redirigido), el rastreador responderá sólo con la dirección IP del PE(s) identificado por el prefijo de anclaje, si dicho PE está disponible. Si el PE no está disponible, el rastreador DNS aplica el mecanismo habitual de selección de puntos finales y devuelve las direcciones IP de los PE más adecuados.
- En el punto final (servidor de vídeo o, en términos más generales, servidor de contenidos), redirige añadiendo el ancla (redirección de anclaje) cuando el nombre de host recibido es el correspondiente a la selección óptima del punto final. Por ejemplo, cuando el servidor recibe un mensaje que solicita un manifiesto o un fragmento (mensaje GET), lee el nombre de host incluido en el mensaje (el parámetro Redir= True). Si el nombre de host es un nombre de host anclado (el nombre de host incluye un identificador de anclaje, el PE entrega el contenido solicitado (manifiesto o fragmento), independientemente de que el anclaje identifique o no a dicho Punto final; si el identificador de anclaje no identifica al PE sino a otro PE (PE anclado) significa que el PE anclado no está disponible y por eso el mensaje ha sido dirigido a este PE, por lo que en cualquier caso el PE entregará el contenido solicitado.
Si el nombre de host no es un nombre de host anclado (el nombre de host no incluye un identificador de anclaje) sino un nombre de host redirigido, significa que el punto final ya es el punto final óptimo dentro de todos los puntos finales disponibles y realiza una redirección de anclaje (es decir, devuelve un mensaje de redirección que incluye un identificador de anclaje que identifica este PE).
Normalmente, si el nombre de host es un nombre de host de solicitud original (o nombre de dominio), es decir, un nombre canónico de una CDN o un nombre de host de cliente, se suele realizar una redirección normal (no una redirección de anclaje) (incluyendo pid/hash). El nombre de host de la solicitud original es el nombre de dominio (nombre de host) incluido en la URLen la primera solicitud de contenido del usuario final. Este nombre de dominio de petición original puede ser un nombre de dominio CDN (por ejemplo, el CDN de un operador como Telefónica, cuyo nombre canónico a nivel de DNS es b1.cdn.telefonica.com o b99.cdn.telefonica.com como en el ejemplo o las figuras 3a, 3b y 3c) o puede ser un nombre de host de cliente (por ejemplo, cliente.com).
En una realización, existe una funcionalidad llamada mejora del enrutamiento de solicitudes en la CDN y si el nombre de host es un nombre de host de solicitud original y si esta funcionalidad está habilitada, se realiza la redirección del ancla. Es decir, en esta realización específica, si el nombre de host es un nombre de host de solicitud original, se determina si la mejora del enrutamiento de solicitudes está habilitada. Si es así, el PE realiza la redirección de anclaje, incluyendo pld+hash. Si no, se realiza la redirección normal (no la redirección de anclaje) (incluyendo pid/hash).
Como se ha dicho anteriormente, cuando el nombre de host es un nombre de host de solicitud original, se suele incluir en la redirección el PID (Partición de red ID) y el hash (que identifica un grupo de contenidos para distribuir equitativamente la entrega de contenidos entre los PE cercanos al usuario final).
A continuación, se va a exponer un ejemplo concreto (a título ilustrativo, no limitativo) para explicar mejor este proceso de punto final. Por ejemplo, en una realización el nombre de dominio original del URL es BX.cdn.telefonica.com (donde X es un valor que depende de la implementación específica, 99 en el caso revelado en las figuras 3a, 3b y 3c). Entonces, como el nombre de dominio es un nombre de host de solicitud original, se realiza una redirección normal que incluye un PID (por ejemplo, pY, donde Y es un valor que depende de la implementación específica, 14 en el caso revelado en la figura 3) y un hash (por ejemplo, hZ, donde Z es un valor que depende de la implementación específica, 33 en el caso revelado en las figuras 3a, 3b y 3c). Así, el nombre de dominio en dicha redirección es BX-pY-hZ.1.cdn.telefonica.com. Entonces, como se muestra en las figuras 3a, 3b y 3c, con dicho nombre de dominio se selecciona el PE óptimo y se envía un mensaje por parte del usuario final con dicho nombre de dominio (BX-pY-hZ.1.cdn.telefonica.com), a dicho PE óptimo si está disponible. Y, como el nombre de dominio no es un nombre de host original de la petición (sino un nombre de host redirigido), el PE hace la última redirección añadiendo el ancla (por ejemplo, aW, donde es W es un valor que identifica al PE, aXX en el caso expuesto en las figuras 3a, 3b y 3c); por lo que el nombre de dominio modificado con el ancla será Bx-Py-hZ-aW.1.cdn.telefonica.com.
Las realizaciones descritas deben ser consideradas en todos los aspectos como únicamente ilustrativas y no restrictivas, adjuntadas como parte integrante de las mismas, teniendo un carácter ilustrativo y no limitativo. Otras realizaciones con características alternativas pueden ser implementadas sin apartarse del alcance de la presente invención, que solo está definida por las reivindicaciones adjuntas.
Por ejemplo, en una realización alternativa, en la primera redirección (el nombre de dominio recibido es un nombre de host original de la solicitud), incluso cuando la mejora del enrutamiento de la solicitud está desactivada, se realizará la redirección anclada al PE óptimo. Esto permite utilizar sólo una redirección en lugar de dos durante todo el mecanismo de enrutamiento de solicitudes.
En otras realizaciones, la pegajosidad no se utilizará para todos los dominios, sino que puede configurarse para que se utilice sólo para dominios específicos. Esto permite evitar su uso en caso de que el dispositivo no soporte la redirección o sólo un límite bajo.
Con el mecanismo propuesto, el problema anteriormente explicado que afectaba a la experiencia de los usuarios finales cuando los servidores están cerca del punto de saturación (por ejemplo, durante los momentos de alta audiencia) se resuelve o al menos se minimiza. Esto se muestra, por ejemplo, en la figura 4, que muestra el número de reproductores HLS conectados a un servidor CDN específico durante un evento de alta audiencia (evento de fútbol en directo 17 de septiembre de 2017). Como se puede observar en la figura 4, el número de reproductores HLS conectados al servidor no muestra un perfil agresivo en forma de diente de sierra como se mostraba anteriormente cuando no se aplicaba la solución propuesta, sino que es bastante estable en torno a los 4000 usuarios por servidor, evitando el comportamiento problemático (efecto alternación, efecto avalancha) explicado anteriormente; ya que con la solución propuesta un único servidor está entregando el contenido a cada usuario individual durante toda la sesión de vídeo.
Aunque la mayoría de las realizaciones anteriores, la presente invención se ha explicado para sistemas de comunicación que utilizan técnicas de flujo continuo para la entrega de contenidos (y más concretamente técnicas de flujo continuo adaptativo), esto ha sido sólo un ejemplo. La invención propuesta podría aplicarse no sólo a las comunicaciones que utilizan flujo continuo adaptativo, sino a cualquier comunicación que implique el establecimiento de una sesión con peticiones consecutivas (por ejemplo, peticiones HTTPS). Gracias al mecanismo propuesto, los clientes pueden conservar la localización/redirección de la primera petición. Un experto en la materia reconocería fácilmente que los pasos de los diversos procedimientos descritos anteriormente pueden ser realizados por ordenadores programados. En este sentido, algunas realizaciones también pretenden cubrir dispositivos de almacenamiento de programas, por ejemplo, medios de almacenamiento de datos digitales, que son legibles por máquina o por ordenador y codifican programas de instrucciones ejecutables por máquina o por ordenador, en los que dichas instrucciones realizan algunos o todos los pasos de dichos procedimientos descritos anteriormente. Los dispositivos de almacenamiento de programas pueden ser, por ejemplo, memorias digitales, medios de almacenamiento magnético como discos y cintas magnéticas, discos duros o medios de almacenamiento de datos digitales ópticamente legibles. Las realizaciones también pretenden cubrir los ordenadores programados para realizar dichos pasos de los procedimientos descritos anteriormente.
El contenido y el contenido multimedia pueden referirse a cualquier tipo de material electrónico como música, vídeos, software, libros, presentaciones multimedia, imágenes, texto y otros datos electrónicos que pueden ser entregados como un flujo o transferidos, por ejemplo, a través de una red a uno o más usuarios.
La descripción y los dibujos se limitan a ilustrar los principios de la invención. Aunque la presente invención se ha descrito con referencia a realizaciones específicas, debe entenderse por los expertos en la materia que lo anterior y varios otros cambios, omisiones y adiciones en la forma y detalles de la misma pueden hacerse en ella sin apartarse del alcance de la invención como se define en las siguientes reivindicaciones. Además, todos los ejemplos que se recitan en el presente documento tienen como objetivo principal y expreso ser sólo para fines pedagógicos para ayudar al lector en la comprensión de los principios de la invención y los conceptos aportados por el (los) inventor(es) para promover la técnica, y deben interpretarse como sin limitación a tales ejemplos y condiciones específicamente recitados.
Los expertos en la materia apreciarán que cualquier diagrama de bloques aquí presente representa vistas conceptuales de circuitos ilustrativos que incorporan los principios de la invención. Del mismo modo, se apreciará que cualquier gráfico de flujo, diagramas de flujo, diagramas de transición de estado, pseudocódigo, y similares representan diversos procesos que pueden ser sustancialmente representados en un medio legible por ordenador y así ejecutados por un ordenador o procesador, independientemente de que dicho ordenador o procesador se muestre explícitamente.

Claims (12)

REIVINDICACIONES
1. Un procedimiento para mejorar la entrega de contenidos multimedia a equipos de usuario final en una red de entrega de contenidos que comprende varios servidores, el procedimiento comprende:
- Un primer servidor recibe un primer mensaje de un equipo de usuario final, el mensaje incluye un Localizador Universal de Recursos, URL, que incluye un primer nombre de dominio;
- Tras recibir dicho primer mensaje, el primer servidor determina si dicho primer nombre de dominio incluye un identificador de un servidor de la red de entrega de contenidos, denominado identificador de anclaje, y en caso contrario, el primer servidor devuelve al equipo del usuario final un mensaje de redirección que comprende un URL e incluye un segundo nombre de dominio en el URL, siendo dicho segundo nombre de dominio el resultado de añadir al primer nombre de dominio un identificador de anclaje que identifica al primer servidor;
estando el procedimiento caracterizado porque:
cuando un dispositivo de Sistema de Nombres de Dominio, DNS, de la red de entrega de contenidos recibe una solicitud de resolución de nombre de dominio para un nombre de dominio que incluye dicho identificador de anclaje, el dispositivo DNS devuelve un mensaje de respuesta a la solicitud de resolución de nombre de dominio, incluyendo la dirección de Protocolo de Internet, IP, del primer servidor, independientemente del nivel de congestión de dicho servidor, siempre que el primer servidor esté disponible.
2. Un procedimiento según la reivindicación 1, en el que el primer nombre de dominio es un nombre de dominio redirigido.
3. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que el primer mensaje es un mensaje que solicita un manifiesto para una sesión de flujo continuo de contenido multimedia o un fragmento del contenido multimedia y en el que, si dicho primer nombre de dominio ya incluye un identificador de anclaje de un servidor de la red de entrega de contenidos, el primer servidor envía el manifiesto o fragmento solicitado al equipo del usuario final.
4. Un procedimiento según cualquiera de las reivindicaciones anteriores en el que, el primer nombre de dominio no es un nombre de dominio de solicitud original.
5. Un procedimiento según la reivindicación 1, en el que el primer nombre de dominio es un nombre de dominio de solicitud original.
6. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que el dispositivo DNS es un rúter.
7. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que el primer nombre de dominio pertenece a un grupo de dominios específicos para los que se permite añadir un identificador de anclaje.
8. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que el contenido multimedia es un contenido de vídeo.
9. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que el equipo del usuario final es un teléfono móvil, una tableta, un teléfono inteligente, un ordenador, un ordenador personal, PC, un ordenador portátil o cualquier dispositivo electrónico que pueda recibir contenidos multimedia a través de la red de comunicación.
10. Un dispositivo de Sistema de Nombres de Dominio, DNS, para mejorar la entrega de contenidos multimedia a equipos de usuario final en una red de entrega de contenidos que comprende varios servidores, comprendiendo el servidor:
- Un receptor para recibir, a través de la red de entrega de contenidos, una solicitud de resolución de nombre de dominio para un nombre de dominio;
- Un transmisor para transmitir mensajes a través de la red de entrega de contenidos;
estando el servidor caracterizado porque comprende un procesador configurado para:
- Determinar si dicho nombre de dominio incluye un identificador de anclaje que identifica a un servidor; si es así, determinar si dicho servidor identificado por el identificador de anclaje está disponible, y si dicho nombre de dominio incluye un identificador de anclaje que identifica un servidor y el servidor está disponible, enviar de vuelta, usando el transmisor, un mensaje que responde a la solicitud de resolución de nombre de dominio que incluye una dirección de Protocolo de Internet, IP, del servidor identificado por el identificador de anclaje independientemente del nivel de congestión de dicho servidor.
11. Un sistema para mejorar la entrega de contenidos multimedia a equipos de usuario final en una red de entrega de contenidos, el sistema comprende:
- Un servidor que comprende:
- Un receptor para recibir, a través de la red de entrega de contenidos, un primer mensaje de un equipo de usuario final, incluyendo el mensaje un URL que incluye un primer nombre de dominio; - Un transmisor para transmitir mensajes a través de la red de entrega de contenidos;
- Un dispositivo de Sistema de Nombres de Dominio, DNS, que comprende:
- Un receptor para recibir, a través de la red de entrega de contenidos, una solicitud de resolución de nombre de dominio para un nombre de dominio;
- Un transmisor para transmitir mensajes a través de la red de entrega de contenidos;
- comprendiendo el servidor un procesador configurado para, después de recibir dicho primer mensaje, determinar si dicho primer nombre de dominio incluye un identificador de un servidor de la red de entrega de contenidos, llamado identificador de anclaje, y en caso contrario, enviar de vuelta al equipo del usuario final utilizando su transmisor, un mensaje de redireccionamiento que comprende un Localizador Universal de Recursos, URL, y que incluye un segundo nombre de dominio en el u Rl , que es el resultado de añadir al primer nombre de dominio un identificador de anclaje que identifica al servidor;
estando el sistema caracterizado porque:
- el dispositivo DNS que comprende un procesador configurado para:
determinar si el nombre de dominio incluido en el mensaje de solicitud de resolución de dominio incluye un identificador de anclaje que identifique a un servidor y, si dicho nombre de dominio incluye un identificador de anclaje que identifique a un servidor y el servidor está disponible, devolver mediante su transmisor un mensaje que responde a la solicitud de resolución de nombre de dominio que incluye una dirección de Protocolo de Internet, IP, del servidor identificado por el identificador de anclaje, independientemente del nivel de congestión de dicho servidor.
12. Un medio de almacenamiento de datos digitales no transitorio para almacenar un programa de ordenador que comprende instrucciones que hacen que un ordenador que ejecuta el programa realice el procedimiento según cualquiera de las reivindicaciones 1-9.
ES18382919T 2018-12-13 2018-12-13 Procedimiento, sistema y dispositivos para mejorar la entrega de contenidos multimedia Active ES2877338T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP18382919.1A EP3668052B1 (en) 2018-12-13 2018-12-13 Method, system and devices for improved multimedia content delivery

Publications (1)

Publication Number Publication Date
ES2877338T3 true ES2877338T3 (es) 2021-11-16

Family

ID=64901927

Family Applications (1)

Application Number Title Priority Date Filing Date
ES18382919T Active ES2877338T3 (es) 2018-12-13 2018-12-13 Procedimiento, sistema y dispositivos para mejorar la entrega de contenidos multimedia

Country Status (3)

Country Link
EP (1) EP3668052B1 (es)
BR (1) BR102019026713A2 (es)
ES (1) ES2877338T3 (es)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114629911A (zh) * 2022-04-18 2022-06-14 北京字节跳动网络技术有限公司 域名解析请求的处理方法、装置、设备、介质和程序产品

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6785704B1 (en) * 1999-12-20 2004-08-31 Fastforward Networks Content distribution system for operation over an internetwork including content peering arrangements
US8239445B1 (en) 2000-04-25 2012-08-07 International Business Machines Corporation URL-based sticky routing tokens using a server-side cookie jar
US8224986B1 (en) * 2002-03-07 2012-07-17 Cisco Technology, Inc. Methods and apparatus for redirecting requests for content
EP2974448A1 (en) * 2013-03-14 2016-01-20 Interdigital Patent Holdings, Inc. Anchor node selection in a distributed mobility management environment
US8751661B1 (en) 2013-11-20 2014-06-10 Linkedin Corporation Sticky routing

Also Published As

Publication number Publication date
EP3668052B1 (en) 2021-05-26
EP3668052A1 (en) 2020-06-17
BR102019026713A2 (pt) 2020-06-23

Similar Documents

Publication Publication Date Title
ES2586818T3 (es) Control de flujo de contenido tratado inicialmente en red
EP2897340B1 (en) Routing proxy for adaptive streaming
JP6231583B2 (ja) ネットワークを介するメディアストリーミングのためのトランスポートダイバーシティおよびタイムシフトバッファのサポート
US7818402B1 (en) Method and system for expediting peer-to-peer content delivery with improved network utilization
KR101670521B1 (ko) 콘텐츠 중심 네트워크를 통한 세션 이전
US10523723B2 (en) Method, system and various components of such a system for selecting a chunk identifier
US20120124191A1 (en) Managing tcp anycast requests
Detti et al. Mobile peer-to-peer video streaming over information-centric networks
Mansy et al. Characterizing client behavior of commercial mobile video streaming services
KR20150048179A (ko) 하이브리드 http 및 udp 콘텐츠 전달
US20150172354A1 (en) Content-delivery transfer for cooperative delivery systems
US9729663B2 (en) Dynamic/shared PMTU cache
BR112015004266B1 (pt) Método e sistema para entrega de um conteúdo audiovisual para um dispositivo de cliente
US20150172135A1 (en) Dynamic bandwidth allocation for cooperative delivery systems
ES2965183T3 (es) Procedimiento y sistema para la distribución de contenido audiovisual en vivo
WO2017182815A1 (en) Media data streaming method and apparatus
Luo et al. An incrementally deployable network architecture to support both data-centric and host-centric services
ES2877338T3 (es) Procedimiento, sistema y dispositivos para mejorar la entrega de contenidos multimedia
US8769047B1 (en) Delivery control for cooperative delivery systems
US11888692B2 (en) Methods and apparatus for monitoring content delivery
US20230362240A1 (en) Local preference in anycast cdn routing
US10425458B2 (en) Adaptive bit rate streaming with multi-interface reception
US11665380B2 (en) Methods and apparatus for receiving adaptive bit rate content and manifest for adaptive bit rate content
Nam et al. Towards dynamic network condition-aware video server selection algorithms over wireless networks
Zhang et al. Using P2P network to transmit media stream in SIP-based system