ES2670419T3 - Método y sistema para la difusión virtual adaptativa de contenido digital - Google Patents

Método y sistema para la difusión virtual adaptativa de contenido digital Download PDF

Info

Publication number
ES2670419T3
ES2670419T3 ES15202716.5T ES15202716T ES2670419T3 ES 2670419 T3 ES2670419 T3 ES 2670419T3 ES 15202716 T ES15202716 T ES 15202716T ES 2670419 T3 ES2670419 T3 ES 2670419T3
Authority
ES
Spain
Prior art keywords
client
asn
nodes
network
client nodes
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
ES15202716.5T
Other languages
English (en)
Inventor
Mattias Bergstrom
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.)
System73 Inc
Original Assignee
System73 Inc
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 System73 Inc filed Critical System73 Inc
Application granted granted Critical
Publication of ES2670419T3 publication Critical patent/ES2670419T3/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
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/125—Shortest path evaluation based on throughput or bandwidth
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
    • H04N21/64738—Monitoring network characteristics, e.g. bandwidth, congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1877—Measures taken prior to transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/0816—Configuration setting characterised by the conditions triggering a change of settings the condition being an adaptation, e.g. in response to network events
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0882—Utilisation of link capacity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0888—Throughput
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0894—Packet rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/121—Shortest path evaluation by minimising delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/123—Evaluation of link metrics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H04L45/3065—Route determination based on the nature of the carried application for real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/823—Prediction of resource usage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/83—Admission control; Resource allocation based on usage prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/251—Learning process for intelligent management, e.g. learning user preferences for recommending movies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/22—Alternate routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/70—Routing based on monitoring results
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/127—Avoiding congestion; Recovering from congestion by using congestion prediction

Abstract

Un servidor de difusión virtual (300) adaptado para encaminar simultáneamente cada uno de una pluralidad de segmentos de contenido digital a una pluralidad de nodos cliente (200) de una red subyacente (110) para reproducción concurrente del segmento por la pluralidad de nodos cliente (200), comprendiendo el servidor de difusión virtual (300): a) una base de datos de red superpuesta (375) adaptada para almacenar una topología de red que representa un estado actual de una red superpuesta (100) creada en la parte superior de la red subyacente (110), en donde la topología de red de la red superpuesta (100) incluye: (i) cada uno de la pluralidad de nodos cliente (200), siendo cada nodo cliente un nodo tanto de la red superpuesta (100) como de la red subyacente (110), y siendo cada nodo cliente un nodo cliente de destino adaptado para recibir el segmento para la reproducción concurrente del segmento por la pluralidad de nodos cliente (200), y (ii) un conjunto de trayectorias de encaminamiento que cada segmento atraviesa a medida que se retransmite entre la pluralidad de nodos cliente (200) para facilitar la reproducción concurrente del segmento por todos los nodos cliente de destino, en donde (A) un subconjunto de los nodos cliente son nodos cliente de origen, además de ser nodos cliente de destino, adaptados para retransmitir el segmento a uno o más de los nodos cliente de destino, y (B) cada trayectoria de encaminamiento define un par de nodos cliente de origen y de destino; y b) un rastreador de rendimiento (340) adaptado para monitorizar métricas de tráfico de red entre la pluralidad de nodos cliente (200) a lo largo de la red superpuesta (100); en donde el servidor de difusión virtual (300) está caracterizado por que comprende adicionalmente: c) un motor de aprendizaje de profundidad (360) adaptado para (i) mantener (A) un mapa de interconexión de número de sistema autónomo, ASN, de la red subyacente (110), que incluye una pluralidad de ASN (110a -110j) interconectados por una pluralidad de puntos de pares de ASN (120), y (B) una localización de ASN de cada nodo cliente (200), en donde la localización de ASN identifica el ASN particular (110a - 110j) en el que está localizado ese nodo cliente (200), y (ii) predecir de manera continua y cuantificar niveles de congestión en los puntos de pares de ASN (120), basándose en un análisis de las métricas, el mapa de interconexión de ASN y la localización de ASN de cada nodo cliente (200), en donde los niveles de congestión previstos cambian a medida que sube y baja el tráfico de red a través de los puntos de pares de ASN (120); y d) un creador de red superpuesta adaptado para reconfigurar dinámicamente la topología de red de la red superpuesta (100), basándose al menos en parte en cambios en los niveles de congestión previstos cuantificados, modificando el conjunto de trayectorias de encaminamiento.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Método y sistema para la difusión virtual adaptativa de contenido digital Campo de la técnica
La presente invención se refiere en general a una arquitectura de red superpuesta para entregar contenido digital entre nodos de una red subyacente, y más particularmente a un sistema de difusión virtual que optimiza el encaminamiento de contenido digital entre nodos a lo largo de redes superpuestas que están reconfiguradas dinámicamente basándose en pronósticos de niveles de congestión que cambian de manera frecuente en interconexiones de componente en la red subyacente.
Descripción de la técnica relacionada
Congestión de red
A medida que el tráfico de red alámbrica e inalámbrica continúa expandiéndose exponencialmente, la capacidad finita de los enlaces o interconexiones compartidas entre componentes en una red cada vez se vuelve un problema más relevante y problemático. Además, puesto que el nivel de congestión en estos enlaces compartidos es dinámico y se ve sometido a una gran cantidad de volatilidad a medida que el tráfico de red sube y baja, tal congestión es difícil de medir en cualquier momento dado, y particularmente difícil de predecir incluso a corto plazo.
Este problema es un tanto análogo al de la congestión de tráfico en las uniones de intersección de carreteras y autopistas compartidas en áreas cada vez más pobladas. Aunque los sistemas de control de navegación y tráfico de GPS existentes miden congestión actual en estas uniones, y calculan trayectorias óptimas para reencaminar a conductores individuales alrededor de tal congestión, su capacidad para predecir una ruta óptima con antelación para cualquier conductor particular se ve obstaculizada por la naturaleza volátil de la congestión de tráfico.
Cuando una única compañía tal como Netflix representa más de un tercio del pico del tráfico de Internet, las compañías que entregan información digital a través de la Internet de manera concurrente (particularmente grandes cantidades de datos lineales) deben tratar de alguna manera la naturaleza cada vez más volátil de congestión de Internet. De manera similar, a medida que se dispara el uso de voz y datos móviles, la disponibilidad limitada de espectro de RF regulado es de asunto particular para las compañías que desarrollan aplicaciones móviles de alto ancho de banda.
Aunque se describe una aplicación específica de la presente invención en el presente documento en el contexto de entregar vídeo por flujo continuo a través de la Internet a grandes cantidades de usuarios concurrentes, los principios de la presente invención se aplican igualmente en numerosos otros contextos donde la capacidad limitada de enlaces compartidos entre componentes de red restringe el encaminamiento de cualquier tipo de información que pueda convertirse en un formato digital (por ejemplo, audio, imágenes, modelos de 3D, etc.). Otras aplicaciones potenciales de la presente invención incluyen, por ejemplo, VoIP, videoconferencia corporativa, realidad virtual, juegos multi-jugador y otras diversas aplicaciones de ancho de banda intensivo (con relación al nivel de congestión de enlaces compartidos en una red subyacente en cualquier punto en el tiempo dado).
Como se analizará en mayor detalle a continuación, la presente invención no "remedia" el problema de capacidad limitada o "congestión de red" en enlaces de componente en una red subyacente tal como Internet, sino que en su lugar hace uso eficaz de esa capacidad limitada monitorizando y analizando tráfico de red a través de aquellos enlaces para optimizar el encaminamiento de contenido digital entre nodos de redes superpuestas que se reconfiguran dinámicamente basándose en pronósticos de niveles de congestión en estos enlaces.
Eventos de vídeo por flujo continuo
Desde la llegada de la Internet y encaminamiento basado en IP, han surgido muchos enfoques para enviar vídeo por flujo continuo a través de la Internet. Antes de analizar sus ventajas y desventajas relativas, es útil dar un paso atrás y considerar el problema que se está tratando. Para distribuir contenido de vídeo a través de la Internet, en primer lugar debe capturarse y digitalizarse. Podemos caracterizar el contenido de vídeo como un "evento" que se captura "en directo" (o se genera digitalmente) y se distribuye a través de la Internet. Las referencias en el presente documento a eventos de vídeo incluyen la captura o generación tanto de vídeo como de audio, así como cualquier metadato asociado.
Los eventos de vídeo pueden ser planificados o no planificados. Por ejemplo, la "Super Bowl" es un evento planificado en que el tiempo de su aparición es conocido con antelación, mientras que otros eventos (por ejemplo, desastres naturales, unos primeros pasos de un niño pequeño, o incluso vídeo bajo demanda - "VOD") son no planificados en que pueden tener lugar con poco o ningún aviso con antelación.
El contenido de vídeo puede capturarse en su totalidad para generar un fichero de vídeo digitalizado antes de que se
5
10
15
20
25
30
35
40
45
50
55
60
65
distribuya a través de la Internet como se transfiere cualquier otro tipo de fichero (por ejemplo, mediante un "FTP" o protocolo de transferencia de ficheros). Sin embargo, un enfoque de "transferencia de fichero" de este tipo impone un retardo en la visualización (reproducción) del receptor del contenido de vídeo- es decir, el receptor debe esperar hasta que el fichero entero se haya transferido antes de visualizar el contenido de vídeo. Dado los tamaños de ficheros de vídeo digitalizado relativamente grandes, este retardo puede ser significativo.
El contenido de vídeo por lo tanto a menudo se "envía por flujo continuo" a usuarios de modo que pueden recibir de manera continua y ver el contenido mientras aún se está enviando. En esencia, el contenido de vídeo se divide en un flujo lineal ordenado de pequeños ficheros o "segmentos de vídeo" (porejemplo, de 1 a 10 segundos de longitud) que se entregan a usuarios que pueden empezar a verlos a medida que se reciben. Para ver un flujo continuo de contenido de vídeo sin retardo o interferencia, cada segmento de vídeo debe reproducirse a puestos regulares - por ejemplo, 30 fotogramas por segundo (fps). Obsérvese, sin embargo, que los segmentos de vídeo no necesitan recibirse a puestos regulares, con la condición de que cada segmento se reciba antes de que se haya concluido la reproducción del segmento anterior.
Un evento ya esté planificado o no planificado, puede enviarse por flujo continuo "en directo" (es decir, a medida que tiene lugar el evento) o "pre-grabarse" para enviar por flujo continuo en cualquier momento después de que haya ocurrido el evento. Por ejemplo, la Super Bowl podría capturarse y enviarse por flujo continuo a medida que tiene lugar el evento, o pre-grabarse para enviar por flujo continuo en un momento más tarde.
Finalmente, si un evento está planificado o no planificado, y si está pregrabado o se envía por flujo continuo en directo a medida que tiene lugar, puede enviarse por flujo continuo en "tiempo real" (es decir, con un retardo en gran medida imperceptible desde el emisor al receptor) o "retardarse" en el tránsito de segundos o incluso minutos. Por ejemplo, los observadores de un programa de televisión (por ejemplo, un juego de béisbol) que se envía por flujo continuo a través de la Internet, pero no en tiempo real, pueden experimentar el evento enviado por flujo continuo a diferentes momentos unos de los otros, o a diferentes momentos de observadores que ven la misma difusión de programa mediante cable o satélite. Tales retardos (particularmente si son más de unos pocos segundos) pueden reducir la "Calidad de Experiencia" (QoE) del usuario - es decir, una vista de calidad céntrica en el usuario o de nivel de aplicación, en contraste con una "calidad de servicio" (QoS), que es una medida de rendimiento basada en métricas céntricas en la red (por ejemplo, retardo de paquete, pérdida de paquete, o interferencia producida por encaminadores u otros recursos de red).
Por ejemplo, puede restringirse la interacción social entre observadores (completamente separada de interferencia u otros artefactos de vídeo) debido al hecho de que los observadores pueden experimentar el mismo evento a diferentes tiempos. Esto es particularmente problemático hoy en día cuando se comunican demasiados eventos (planificados o no planificados) en tiempo real de tantas maneras diferentes- de radio o televisión de difusión a medios sociales y otros servicios de Internet, accesibles mediante teléfonos móviles y ordenadores de sobremesa y portátiles, así como mediante un dominio constantemente en evolución de dispositivos electrónicos de consumo.
Es por lo tanto deseable que un sistema de vídeo por flujo continuo maneje eventos no planificados así como planificados, para enviar por flujo continuo eventos en directo así como pregrabados, y para enviar por flujo continuo aquellos eventos en tiempo real con mínimo retardo para proporcionar a los observadores con una QoE uniforme. Además, a medida que el número de observadores concurrentes de un evento de vídeo por flujo continuo aumenta, mantener una QoE uniforme se vuelve un problema enorme. Por esa razón, la escalabilidad es un objetivo de diseño clave de cualquier sistema de este tipo.
A pesar de los recientes avances en la tecnología de vídeo por flujo continuo, la evolución "ad hoc" histórica de la infraestructura de la Internet aún presenta obstáculos significativos al vídeo de flujo continuo basado en Internet, uno de ellos es una QoS no uniforme, que conduce a congestión de red a tiempos y localizaciones a través de la Internet que son difíciles de predecir. Aunque un objetivo clave de la presente invención es mantener una QoE uniforme para los observadores de eventos de vídeo por flujo continuo, este objetivo se restringe por congestión de red a través de la Internet que finalmente no puede eliminarse.
Arquitectura de Internet subyacente
Comenzando con ARPANET (la red de conmutación de paquetes más antigua en implementar el conjunto de protocolos de Internet, o TCP/IP), y más tarde NSFNET, la Internet "principal" se diseñó para ser una "red de redes" redundante (es decir, la Internet) que permite fiabilidad o "resistencia" descentralizando el control y proporcionando trayectorias de comunicación (encaminamiento) alternativas para que la información alcance su destino deseado. Además, con los paquetes siguiendo diferentes trayectorias entre encaminadores y otros recursos de red compartidos, mantener una QoS o QoE uniforme a través de la Internet sigue siendo un problema extremadamente difícil.
A medida que la parte principal de Internet evolucionó y se privatizó, se desarrolló la redundancia y solapamiento entre redes principales tradicionales y aquellas de propiedad de las operadoras de telefonía a larga distancia. Para los fines de esta especificación, distinguimos de redes "públicas" grandes que proporcionan datos a clientes
5
10
15
20
25
30
35
40
45
50
55
60
65
directamente, o mediante otras redes de "proveedor de servicio de internet" (ISP) más pequeñas, de redes principales "privadas" grandes que llevan datos únicamente entre ellas mismas, o sirven como un conducto entre grandes ISP, pero no proporcionan directamente datos a clientes. En cualquier caso, estas redes públicas y privadas grandes se implementan normalmente como "anillos de fibra" interconectados mediante líneas troncales de fibra óptica - es decir, múltiples cables de fibra óptica agrupados para aumentar la capacidad de red.
Para fines de encaminamiento, los proveedores de red más grandes que llevan el tráfico de red más pesado (por ejemplo, grandes ISP y redes principales privadas) se les asignan bloques de prefijos de encaminamiento de IP conocidos como "sistemas autónomos" (AS), cada uno de los cuales se le asigna un "número de sistema autónomo" (ASN). Hacemos referencia a los anillos de fibra grandes de propiedad de estas compañías como un ASN. El número de ASN ha crecido drásticamente en los últimos años, de aproximadamente 5000 ASN hace quince años a por encima de 50.000 ASN a lo largo del mundo hoy en día. Como se ha indicado anteriormente, muchos grandes proveedores de red también poseen redes de anillo de fibra principales (es decir, ASN privados) que no dan servicio a clientes, pero pueden conectarse a sus propios "ASN públicos" o aquellos de propiedad por otros.
Debido a que las diferentes compañías tienen propiedad de ASN, entran en acuerdos entre sí para facilitar el encaminamiento a través de los ASN y a través de toda la Internet global. Cada ASN utiliza un banco de encaminadores a menudo denominado como un "punto de pares" para controlar el acceso a otro ASN, empleando un protocolo de encaminamiento conocido como el "protocolo de pasarela de borde" o BGP. Cualquier ASN dado puede emplear múltiples puntos de pares para conectarse a múltiples diferentes ASN. Los ASN interconectados pueden estar geográficamente adyacentes, o pueden estar alejados, conectados mediante partes troncales de fibra largas que abarcan enormes distancias (por ejemplo, a través de países o incluso océanos). Los ASN públicos pueden también estar interconectados mediante "ASN privados" o redes principales.
Monitorizar QoS dentro y a través de los ASN es extremadamente difícil. Los proveedores de redes grandes mantienen la mayoría de la información de encaminamiento y rendimiento dentro de sus ASN (incluyendo métricas de congestión dinámicas) como propietaria. Aunque el "Formato de Mensaje Abierto" (de la Versión 4 de BPG actual) proporciona un "volcado de datos" de cierta información cuando se establece una conexión de TCP/IP a un encaminador de BGP, este mecanismo no es muy útil como una cuestión práctica. Muchos encaminadores de BGP no soportan el Formato de Mensaje Abierto, mientras que otros simplemente lo desconectan. Además, la información se encuentra normalmente 5 minutos desactualizada, que es un tiempo relativamente largo dada la frecuencia con la que los niveles de congestión cambian a través de Internet.
Debido a que una gran cantidad de tráfico de Internet de este tipo fluye a través de los puntos de pares de ancho de banda relativamente alto que interconectan ASN, estos puntos de pares a menudo son "cuellos de botella" claves o fuentes de la mayoría de la congestión a través de la Internet en cualquier tiempo dado, además del problema de la "última milla" en un ASN (es decir, congestión a través de las conexiones alámbricas e inalámbricas de ancho de banda relativamente inferior entre usuarios finales y sus ISP de "pasarela").
Por ejemplo, a medida que aumenta la carga de tráfico a través de un punto de pares de ASN, los encaminadores en los ASN en cada lado del punto de pares se vuelven congestionados. En otras palabras, estos encaminadores experimentan altas tasas de utilización de RAM, CPU y otros recursos compartidos de capacidad limitada. La petición aumentada sobre estos recursos reduce el rendimiento (por ejemplo, tasas de bits) a través de estos puntos de pares, y de manera eventual puede conducir a perder paquetes de datos. Debido a que el tráfico de red a través de la Internet no está controlado de manera central, es difícil predecir los niveles frecuentemente cambiantes de "congestión de punto de pares" a través de la Internet en cualquier momento dado.
Si no se puede garantizar una QoS coherente en y a través de los ASN, se vuelve muy difícil mantener una QoE uniforme para los observadores de eventos de vídeo por flujo continuo. Cualquier sistema que envía vídeo por flujo continuo a través de la Internet se ve sometido a no fiabilidad y niveles de congestión constantemente cambiantes de encaminadores compartidos, particularmente en puntos de pares de ASN a través de los cuales fluye demasiado tráfico de Internet. Este problema se agrava cuando se envía vídeo por flujo continuo a grandes números de observadores concurrentes a través de la Internet, y en particular a través de estos puntos de pares de ASN.
Enfoques de envío de vídeo por flujo continuo existentes
Diversos enfoques para enviar vídeo por flujo continuo a través de la Internet han evolucionado durante las últimas décadas, con una amplia gama de terminología empleada para caracterizar y distinguir diferentes técnicas para generar topologías de red superpuesta (en la parte superior de la Internet) y entregar contenido de vídeo entre nodos de red a lo largo de estas redes superpuestas. Al comparar diferentes enfoques, es útil volver brevemente a la analogía de navegación de GPS, y considerar los factores que afectan el tiempo requerido para recorrer entre cualesquiera dos puntos o nodos - es decir, distancia, velocidad y congestión (normalmente tratados por el reencaminamiento a lo largo de una trayectoria diferente).
En el contexto de encaminar paquetes en la Internet, la distancia (o proximidad geográfica) no es de relevancia directa puesto que los paquetes viajan cerca de la velocidad de la luz. La velocidad, sin embargo, se ve afectada por
5
10
15
20
25
30
35
40
45
50
55
60
65
el número de paradas u obstáculos encontrados a lo largo de una ruta, o en este contexto el número de "saltos" encontrados en encaminadores intermedios entre dos nodos. Por lo tanto, puede decirse que dos nodos están "cerca" entre sí (en "proximidad de red") si están separados únicamente por unos pocos saltos, independientemente de su proximidad geográfica. La congestión en nodos intermedios a lo largo de la trayectoria entre dos nodos afecta el tiempo de recorrido global, y puede tratarse reencaminando dinámicamente el tráfico- es decir, reconfigurando dinámicamente las redes superpuestas que determinan la trayectoria entre dos nodos. Como se analizará a continuación, estos factores sirven para ilustrar distinciones clave entre diferentes enfoques para enviar vídeo por flujo continuo a través de la Internet.
El método más común de entrega de vídeo fuera de la Internet es "difundir" un flujo de vídeo (por ejemplo, un programa de televisión) desde un "punto de origen" a todos los observadores de destino simultáneamente - por ejemplo, mediante infraestructura de cable o satélite especializada. Aunque pueden emplearse concentradores de red en una LAN para difundir información a todos los nodos de red, difundir paquetes de segmentos de vídeo a través de conmutadores y encaminadores a través de la Internet sería muy poco práctico e ineficaz. La mayoría de los usuarios de red no estarían interesados en ver cualquier "canal" de contenido de vídeo, y tendría lugar congestión significativa cerca del punto de origen ya que los encaminadores que difunden segmentos de vídeo a otros encaminadores se desbordarían rápidamente. Una solución de difusión simplemente no es factible para entregar un canal de contenido de vídeo a través de la Internet desde un único punto de origen a un gran número de observadores concurrentes que pueden unirse al canal en cualquier momento.
Un enfoque de "multidifusión" alternativo implica enviar por flujo continuo simultáneamente cada segmento de vídeo desde un punto de origen a grupos predefinidos de nodos a través de la Internet. Este enfoque es poco práctico de manera similar para distribución de vídeo a gran escala a través de la Internet. Además, se requiere infraestructura especializada, tal como encaminadores especializados con funcionalidad de multidifusión, que también es poco práctico y prohibitivamente costoso para uso comercial a gran escala.
En contraste a las técnicas de difusión y multidifusión, un enfoque de "unidifusión" para enviar vídeo por flujo continuo implica enviar segmentos de vídeo desde un punto de origen a un único nodo de destino (por ejemplo, estableciendo una conexión de TCP/IP con una dirección de IP de nodo de destino definida). Aunque entregar un gran número de paquetes de unidifusión de manera simultánea a cada nodo de visualización desbordaría también rápidamente los encaminadores en o cerca del punto de origen, y fallaría al conseguir una QoS uniforme por muchas de las razones observadas anteriormente, sin mencionar el enorme coste de proporcionar suficiente ancho de banda para manejar un gran número de transmisiones simultáneas de este tipo. El documento US2008263130 titulado "Apparatus, system and method of digital content distribution" desvela la técnica anterior con respecto a la entrega de flujo continuo de medios realizada de acuerdo con una red virtual definida a través de una infraestructura de red física y usando protocolos de multidifusión y/o unidifusión entre pares. También, un ejemplo de la técnica anterior es "Dynamic overlay routing based on available bandwidth estimation: A simulation study", Yong Zhu et al., que desvela funcionar sobre la estimación de ancho de banda disponible (avail-bw), y se centra en encaminamiento de superposición que selecciona trayectorias basándose en mediciones de avail-bw entre nodos de superposición adyacentes.
Algunas compañías de VOD (tales como Netflix y YouTube) han empleado variaciones de este enfoque de unidifusión que generalmente se basan en infraestructura de "borde-servidor" costosa. Este enfoque (en ocasiones denominado como una "red de entrega de contenido" o CDN) implica desplegar muchos servidores físicos a través de la Internet, y distribuir copias de cada canal de contenido de vídeo a cada servidor. Como resultado, los nodos de visualización pueden recibir contenido de vídeo deseado desde un servidor cercano "en proximidad de red- únicamente unos pocos saltos relativamente lejos de un nodo de visualización).
Cada servidor de borde normalmente tiene ancho de banda significativo y capacidades computacionales, y esencialmente constituye una fuente de contenido de vídeo separada desde la que los nodos de visualización cercanos pueden obtener cualquier canal de contenido de vídeo en cualquier punto en el tiempo ("bajo demanda"). Este enfoque de añadir infraestructura física es algo parecido a construir autopistas y rampas adicionales para posibilitar que un mayor número de personas alcancen destinos populares más rápidamente (con menos giros y menos tiempo gastado en carreteras más lentas).
Aunque diferentes usuarios normalmente desean ver diferentes canales de vídeo en cualquier momento dado, los sistemas de VOD ocasionalmente se enfrentan a periodos de demanda "pico" durante los cuales un evento de vídeo particular debe enviarse por flujo continuo a un gran número de observadores concurrentes (por ejemplo, un episodio final de una serie de televisión popular), que puede desbordar incluso la infraestructura de la compañía de envío de vídeo por flujo continuo más grande - o al menos dar como resultado un despliegue del "peor caso" ineficaz de infraestructura costosa que se infrautiliza de manera frecuente (es decir, durante periodos más comunes de demanda no pico). Las soluciones de VOD alternativas han intentado evitar la necesidad de infraestructura de borde- servidor costosa replicando y distribuyendo contenido de vídeo entre los mismos nodos de red (como se analiza, por ejemplo, en la Publicación de Patente de Estados Unidos N.° 2008/0059631).
Con o sin infraestructura de borde-servidor costosa, ninguna de estas soluciones de VOD trata el problema de QoS
5
10
15
20
25
30
35
40
45
50
55
60
65
para eventos de vídeo no planificados, ya que todos se basan en servidores de borde de "pre-diseminación" o nodos de visualización a través de toda la Internet con contenido conocido con antelación- para asegurar una fuente de contenido de vídeo cercana. Enviar por flujo continuo un evento no planificado en directo requeriría entrega concurrente en tiempo real de contenido de vídeo a todos estos servidores de borde o nodos de visualización, un problema no tratado por ninguno de estos sistemas de VOD.
Más recientemente, ciertas normas de envío de vídeo por flujo continuo basadas en unidifusión (por ejemplo, "WebRTC") han evolucionado para facilitar envío de vídeo por flujo continuo "punto a punto" entre exploradores web de sobremesa y móviles sin la necesidad de ningún módulo de extensión. Muchos teléfonos inteligentes existentes, así como ordenadores de sobremesa y portátiles, incluyen bibliotecas de WebRTC que soportan envío de vídeo por flujo continuo de explorador a explorador, así como bibliotecas de "envío por flujo continuo adaptativo" que posibilitan que un nodo de visualización detecte su ancho de banda y capacidad de CPU en tiempo real, y solicite automáticamente una "tasa de bits" inferior o superior para adaptare a cambios en estas métricas.
Las implementaciones de envío por flujo continuo adaptativo incluyen "Envío por flujo continuo en directo de HTTP" (HLS) de Apple, "Envío por flujo continuo suavizado" de Microsoft y la norma de la ISO "MPEG-Dash", entre otros. En un escenario de envío de vídeo por flujo continuo de punto a punto típico, un nodo de recepción solicita periódicamente desde un servidor de HTTP "ficheros de manifiesto", que incluyen las localizaciones de cada versión de tasa de bits disponible de segmentos de vídeo próximos (por ejemplo, los siguientes ocho). Por ejemplo, cada segmento de vídeo puede estar disponible en versiones de 1080p, 720p y 480p, que reflejan diferentes "resoluciones de vídeo" que requieren diferentes tasas de bits de flujo continuo (ancho de banda) para asegurar que se entrega cada segmento de vídeo en esencialmente la misma cantidad de tiempo, independientemente de su resolución.
Los reproductores de vídeo de HTML5 normalizados (en exploradores web que soportan WebRTC) normalmente almacenan en memoria intermedia tres segmentos de vídeo antes de que empiezan a reproducir contenido de vídeo. Usan el fichero de manifiesto actual para enviar una solicitud de HTTP a un servidor de HTTP para cada segmento de vídeo. El nodo de envío a continuación "inserta" cada segmento de vídeo (en pequeños "fragmentos") al nodo de recepción de acuerdo con normas de WebRTC para reproducción en el explorador web del nodo de recepción. Si el nodo de recepción soporta implementaciones de envío por flujo continuo adaptativo, y determina que el tiempo requerido para recibir segmentos de vídeo recientes está aumentando o reduciéndose significativamente, empieza automáticamente a solicitar segmentos de vídeo de tasa de bits inferior o superior de entre las opciones en el fichero de manifiesto. En otras palabras, se "adapta" a su ancho de banda real a través del tiempo variando la resolución de los segmentos de vídeo que solicita.
La "resolución" de un fotograma de vídeo es una medida de su anchura x altura (por ejemplo, 1920 x 1080 o 1080p) o número de píxeles en un fotograma, mientras que su "tasa de bits" se refiere al número de "bits por segundo" (bps) que se transmiten desde un emisor a un receptor. Por ejemplo, si se entregan 30 fotogramas de vídeo de resolución 1080p cada segundo (30 "fotogramas por segundo" o fps), y cada píxel de color contiene 24 bits (24 "bits por píxel" o 24bpp), entonces la tasa de bits sería igual a casi 1,5 Tbps (1.492.992.000 bps - es decir, 1.492.992.000 = (1920 x 1080 "píxeles por fotograma" o ppf) x (24 bpp) x (30 fps).
Los códecs de vídeo normalizados emplean compresión (por ejemplo, compresión MPEG2) y otras técnicas de codificación de vídeo para producir tasas de bits eficaces inferiores (por ejemplo, 3 Mbps). En vista de lo anterior, "tasa de bits" y "resolución" están altamente correlacionadas en que se puede aumentar o reducir la tasa de bits efectiva proporcionando fotogramas de vídeo de resolución superior o inferior. Usamos por lo tanto estos términos de una manera un tanto intercambiable en el presente documento en este sentido.
Las normas WebRTC y de envío por flujo continuo permiten virtualmente que cualquier usuario de teléfono inteligente capture y envíe por flujo continuo eventos de vídeo en directo, y también posibilitan que tales usuarios se unan a un canal de vídeo por flujo continuo que se origina desde otro punto de origen a través de la Internet- que varía de otros usuarios de teléfonos inteligentes individuales a grandes compañías que alojan una gama de contenido de vídeo. Estas normas están diseñadas, sin embargo, para envío por flujo continuo punto a punto, y no tratan el problema de "entrega de vídeo" de enviar por flujo continuo un canal de vídeo a grandes números de observadores concurrentes a través de la Internet.
Para tratar este problema, algunas compañías de vídeo por flujo continuo (por ejemplo, StreamRoot) han adoptado un enfoque que normalmente implica una topología de red "entre pares" (P2P) o red de malla en la que el contenido de vídeo se retransmite desde un nodo de visualización a otro (en ocasiones denominado como "difusión de pares"). En un contexto de envío de vídeo por flujo continuo, estos términos pueden usarse de manera intercambiable para hacer referencia a redes superpuestas configuradas en la parte superior de la Internet que posibilitan que los nodos de visualización retransmitan contenido de vídeo por flujo continuo entre sí en una forma distribuida. Entregar vídeo por flujo continuo a grandes números de observadores concurrentes debería distinguirse, sin embargo, de usuarios no de flujo continuo de una topología de P2P o red de malla, por ejemplo, para aplicaciones de transferencia de ficheros o compartición de ficheros.
5
10
15
20
25
30
35
40
45
50
55
60
65
Los sistemas de envío de vídeo por flujo continuo P2P entregan un canal de contenido de vídeo desde un único punto de un origen a grandes números de usuarios concurrentes a través de la Internet. Tales sistemas tienden a ser tanto resistentes como escalables, en que su naturaleza distribuida facilita la recuperación de puntos de fallo individuales (por ejemplo, reencaminando contenido mediante otros nodos), y su capacidad y rendimiento realmente mejora a medida que se añaden más nodos a la red (es decir, a medida que se hacen disponibles más y mejores opciones de "retransmitir" encaminamiento).
Cuando nuevos nodos se unen a un canal de vídeo o los nodos existentes dejan (detienen la visualización) el canal, los sistemas de envío de vídeo por flujo continuo P2P deben, hasta cierto punto, reconfigurar dinámicamente la topología de la red superpuesta- es decir, modificar al menos algunas de las trayectorias de encaminamiento entre nodos de red para alojar los nuevos nodos. Por ejemplo, cuando se añade un nuevo nodo, su localización geográfica puede considerarse en un esfuerzo para seleccionar nodos existentes cercanos desde los que recibirá (y a los que retransmitirá) contenido de vídeo.
Pero, si se seleccionan nodos "de pares" basándose simplemente en su proximidad geográfica, aún pueden estar relativamente "distantes" unos de los otros (y no en proximidad de red) - por ejemplo, si residen en diferentes ASN. Como resultado, el tráfico entre ellos puede cruzar uno o más puntos de pares potencialmente congestionados. Por ejemplo, la latencia real entre dos nodos en proximidad geográfica cercana puede superar la suma de las latencias entre cada uno de estos nodos y un nodo geográficamente distante. Este fenómeno a menudo se denomina como una "violación de desigualdad de triángulo" (TIV), que ilustra las desventajas de basarse en encaminamiento de BGP para entregar contenido digital entre nodos de una red superpuesta a través de puntos de pares de ASN.
Una razón para este problema con sistemas de envío de vídeo por flujo continuo P2P existentes es que no se deben interpretar como "compatibles" con la arquitectura subyacente de la Internet. Una topología de red superpuesta creada en la parte superior de la Internet se ve sometida aún a muchos puntos de perturbación o fallo (además de nodos nuevos o que desaparecen) tales como los numerosos problemas de QoS observados anteriormente. No tratando la volatilidad de QoS subyacente de la Internet, particularmente en puntos de pares de ASN, tales sistemas se enfrentan a obstáculos significativos al proporcionar a sus usuarios con una QoE uniforme.
Por lo tanto, los sistemas de envío de vídeo por flujo continuo P2P existentes (como los sistemas de navegación de GPS) se basan en proximidad geográfica (en lugar de en proximidad de red) para seleccionar nodos retransmisores de pares, y reencaminar tráfico únicamente "después del hecho" una vez que se encuentre congestión. Además, el envío por flujo continuo en tiempo real de datos lineales a usuarios concurrentes impone una restricción adicional no hallada en sistemas de navegación de GPS-el contenido debe llegar "simultáneamente" en cada nodo. El enfoque de borde-servidor y otros de infraestructura física (similar a la construcción de autopistas y rampas para proporcionar rutas de mayor velocidad) son costosos y también fallan al tratar adecuadamente los problemas de eventos no planificados y alto uso concurrente de cualquier evento particular.
Existe por lo tanto una necesidad de un sistema de entrega de contenido digital que trate las deficiencias anteriormente analizadas, y tenga en cuenta la arquitectura subyacente de la Internet (particularmente en puntos de pares de ASN a través de los cuales fluye demasiado tráfico de Internet) al generar y reconfigurar dinámicamente redes superpuestas para proporcionar nodos cliente con una QoE uniforme.
Sumario
La invención proporciona un servidor de difusión virtual de acuerdo con la reivindicación 1 y un correspondiente método de acuerdo con la reivindicación 6 y un nodo cliente de acuerdo con la reivindicación 11 y un correspondiente método realizado por el nodo cliente de acuerdo con la reivindicación 16.
De acuerdo con la presente invención, se desvelan diversas realizaciones de métodos y arquitecturas novedosos con respecto a un sistema de entrega de contenido digital que proporciona a los usuarios de nodos en una red subyacente (por ejemplo, la Internet) con una QoE uniforme: (1) manteniendo un mapa de enlaces compartidos que interconectan componentes de la red subyacente (por ejemplo, los ASN y los puntos de pares que los interconectan), incluyendo una localización de cada nodo en uno de los componentes (por ejemplo, en un aSn); (2) generar métricas monitorizando tráfico de red entre los nodos que cruzan estos enlaces compartidos (puntos de pares de ASN) a lo largo de una o más redes superpuestas creadas en la parte superior de la red subyacente (Internet); (3) analizar las métricas y el mapa durante el tiempo para pronosticar niveles de congestión que reflejan la capacidad variable de los enlaces compartidos (puntos de pares de ASN) a través del tiempo; y (4) reconfigurar dinámicamente la topología de las redes superpuestas, basándose en los niveles de congestión pronosticados, para generar rutas óptimas del contenido digital entre los nodos clientes a lo largo de las redes superpuestas.
Las realizaciones particulares del sistema de "difusión virtual" de la presente invención se describen en el presente documento en el contexto de proporcionar una QoE uniforme entre observadores de uno o más canales del contenido de vídeo, cada uno de los cuales se envía por flujo continuo en tiempo real desde un único punto de origen a potencialmente grandes números de espectadores concurrentes que pueden unirse al canal en diferentes tiempos (mientras se evita la necesidad de servidores de borde u otra infraestructura física costosa). Como se
5
10
15
20
25
30
35
40
45
50
55
60
65
explicará en mayor detalle a continuación, usamos el término "difusión virtual" en el contexto de envío por flujo continuo de unidifusión de contenido lineal a usuarios concurrentes. Desde la perspectiva de los usuarios, el contenido se "difunde" a ellos, en que reciben el contenido "simultáneamente", incluso aunque se emplee envío por flujo continuo de unidifusión para encaminar el contenido. Otras realizaciones de la presente invención serán evidentes para los expertos en la materia en numerosos otros contextos donde la capacidad limitada de los enlaces compartidos entre componentes de red restringe el encaminamiento de cualquier tipo de información que puede convertirse en un formato digital.
Para los fines de esta especificación, un único nodo que recibe múltiples canales diferentes simultáneamente puede considerarse un nodo distinto en redes superpuestas separadas, cada una definida por un único canal. En un contexto de VOD, cada "muestra" separada de un programa particular puede considerarse un canal separado que tiene su propia red de nodos de visualización.
El sistema de la presente invención puede manejar eventos no planificados así como planificados, enviar por flujo continuo eventos en directo así como pre-grabados, y enviar por flujo continuo aquellos eventos en tiempo real con mínimo retardo de una manera altamente escalable que mantiene una QoE uniforme entre grandes números de usuarios concurrentes - a pesar de implementarse en redes superpuestas creadas en la parte superior de la Internet que se ven sometidas a la volatilidad de QoS de la Internet. El rendimiento del sistema y la QoE de los usuarios realmente mejoran a medida que aumenta el número de usuarios concurrentes (particularmente en cualquier ASN dado).
Se emplea una arquitectura cliente-servidor para centralizar las decisiones de encaminamiento del lado del servidor. La entrega de contenido de vídeo de envío por flujo continuo distribuida se efectúa mediante redes superpuestas P2P dinámicamente reconfigurables que posibilitan que el contenido de vídeo se retransmita entre (es decir, "insertarse" a) los nodos de visualización de cada canal de vídeo. Los nodos cliente pueden emplear reproductores de vídeo HTML5 normalizados (creados en la mayoría de exploradores web de sobremesa y móviles) para visualizar o reproducir el vídeo, y basarse en código embebido personalizado (tal como Javascript) para implementar funcionalidad adicional, tal como gestionar la recepción de segmentos de vídeo y la retransmisión de estos segmentos de vídeo a otros nodos, así como monitorización de diversas métricas de rendimiento. En otras realizaciones, alguna o toda de tal funcionalidad puede integrarse en una aplicación personalizada o aplicación móvil.
El sistema de la presente invención facilita envío de vídeo por flujo continuo "punto a punto" entre exploradores web de sobremesa y móviles, y se adapta a cambios en el ancho de banda de nodo solicitando automáticamente segmentos de vídeo de tasa de bits inferior o superior. En una realización, el sistema de difusión virtual emplea normas de unidifusión, que incluyen WebRTC y normas de envío por flujo continuo adaptativo (tales como HLS, MPEG-Dash, o envío por flujo continuo suave) para facilitar el envío por flujo continuo sin la necesidad de módulos de extensión de explorador web, y para posibilitar que los nodos detecten sus capacidades de rendimiento, tales como ancho de banda y capacidad de CPU.
Cada evento se proporciona a un "servidor de difusión virtual" central para entrega de "punto de origen" de cada canal a usuarios concurrentes a través de múltiples redes superpuestas dinámicamente reconfigurables. Los eventos pueden obtenerse desde virtualmente cualquier fuente (incluyendo una CDN), ya se transfieran como ficheros completos o se envíen por flujo continuo en directo al servidor de difusión virtual. En las realizaciones que utilizan WebRTC, cualquier usuario con un teléfono inteligente que implementa WebRTC puede cargar eventos de vídeo pre-grabados, o capturar eventos en directo y cargarlos al servidor de difusión virtual (así como otros canales enviados por flujo continuo desde el servidor de difusión virtual) para entrega posterior a usuarios mediante las redes superpuestas.
El servidor de difusión virtual incluye, en una realización, un "servidor de contenido de POI" que sirve como el punto de origen para cada canal desde el cual se entregan segmentos de vídeo mediante las redes superpuestas dinámicamente reconfigurables creadas en la parte superior de la Internet. Los segmentos de vídeo están normalmente fijados en tamaño (por ejemplo, de 1 a 10 segundos), según se determina por el publicador originador del evento de vídeo. Los segmentos de vídeo se ven por nodos cliente y se "insertan" (es decir, se retransmiten como "fragmentos" de tamaño fijo individuales de acuerdo con la norma de WebRTC) de nodo a nodo a lo largo de las rutas definidas por las redes superpuestas. En una realización, cada segmento de vídeo se divide en fragmentos de 64 KB para adaptar el tamaño de un "paquete" de datagrama de UDP para máxima eficacia cuando se envía por flujo continuo mediante el protocolo de transporte de MPEG2.
Aunque se insertan segmentos de vídeo de manera eficaz a cada nodo cliente en la mayoría de los casos, un nodo cliente puede detectar, en una realización, que todos los fragmentos de un segmento de vídeo no han llegado a tiempo, y pueden utilizar el fichero de manifiesto actual para solicitar el segmento de vídeo desde el servidor de contenido de POI (es decir, como una localización de alimentación de "repliegue").
Como cada nodo busca unirse un canal puesto a disposición por el servidor de contenido de POI, el nodo determina (con asistencia desde el servidor de difusión virtual en otra realización) el ASN particular en el que reside el nodo. El
5
10
15
20
25
30
35
40
45
50
55
60
65
servidor de difusión virtual utiliza esta información de "localización de ASN", junto con un "mapa de interconexión de ASN" dinámico de la Internet (incluyendo los ASN y sus diversas interconexiones de punto de pares) y diversas métricas de rendimiento monitorizado, para optimizar el encaminamiento del contenido de canal entre redes superpuestas que se reconfiguran dinámicamente basándose en pronósticos de los niveles de congestión en estos puntos de pares de ASN. En otra realización, el servidor de difusión virtual también utiliza la localización geográfica de cada nodo, además de su localización de ASN, para ayudar en este proceso.
En una realización, las topologías de las redes superpuestas definen las trayectorias de encaminamiento de segmentos de vídeo entre los nodos de visualización, y se reconfiguran dinámicamente (en su totalidad o en parte) para cada segmento de vídeo de un canal. En otra realización, se reconfiguran dinámicamente (en su totalidad o en parte) para cada fragmento de un segmento de vídeo. De esta manera, la arquitectura de la Internet (así como los niveles de congestión previstos en puntos de pares de ASN) se tiene en cuenta al determinar las trayectorias de encaminamiento óptimas para cada segmento de vídeo de un canal de vídeo. En otra realización, si algunas o todas las rutas a lo largo de las redes superpuestas pueden entregar segmentos de vídeo a tiempo (incluso si tales rutas no son óptimas), a continuación tales rutas no se reconfiguran hasta que se cumple un umbral de congestión predefinido o se identifica otro problema suficientemente significativo.
En una realización, los nodos cliente monitorizan problemas de rendimiento relacionados, por ejemplo, a problemas de la última milla y problemas de QoS a través de la Internet (incluyendo congestión en puntos de pares de ASN), así como congestión resultante del número de observadores concurrentes de uno o más canales del mismo sistema de difusión virtual. Monitorizan el tiempo requerido para entrar en contacto con sitios designados a través de la Internet, y a través de ASN, así como el tiempo requerido para retransmitir segmentos de vídeo a otros nodos. Las métricas de cliente monitorizado se comunican al servidor de difusión virtual para uso al tomar decisiones de encaminamiento dinámico. En una realización, el servidor de difusión virtual incluye un "servidor de señalización" para comunicar con nodos cliente mediante protocolos de conector web normalizados.
Los nodos cliente incluyen opcionalmente un "cargador" que posibilita que los usuarios capturen un contenido de vídeo y lo carguen al servidor de difusión virtual en tiempo real. Debido a que la trayectoria desde cualquier nodo cliente al servidor de difusión virtual puede cruzar múltiples ASN, se emplea un protocolo de "lluvia" personalizado para facilitar el envío por flujo continuo del evento de vídeo, y evitar que se retarden paquetes o se bloqueen en encaminadores intermedios. En una realización, los nodos cliente pueden también alcanzar y visualizar eventos "de tendencia" (denominados en el presente documento como "pantallas de presentación") mediante un motor de búsqueda de "extractor de pantalla de presentación" en el servidor de difusión virtual que identifica pantallas de presentación y, basándose en búsquedas de usuario, proporciona a los usuarios con la capacidad de enviar por flujo continuo y visualizar eventos de tendencia a través de la Internet que no se ponen a disposición de otra manera mediante el servidor de contenido de POI.
Tras solicitar unirse a un canal, los nodos se clasifican por el servidor de difusión virtual basándose en sus capacidades de retransmisión - es decir, su ancho de banda "aguas arriba" fiable, que se infiere a partir de diversos factores, incluyendo su tipo de conexión (por ejemplo, celular 3G o 4G, WiFi, LAN, etc.) así como sus configuraciones de CPU, sistema operativo, explorador y memoria, y otras métricas de rendimiento fijas y variables monitorizadas a través del tiempo. En una realización, los nodos se clasifican en tres niveles basándose en su capacidad de retransmisión relativa. Los nodos de nivel más inferior (nodos "C") pueden ver segmentos de vídeo, pero no pueden retransmitirlos a otros nodos. Los nodos de nivel medio (nodos "B") pueden tanto ver como retransmitir segmentos de vídeo en un ASN. Los nodos de nivel más superior (nodos "A") pueden ver y retransmitir segmentos de vídeo a otros nodos A tanto dentro como a través de los ASN.
En otra realización, las clasificaciones de nodo pueden modificarse dinámicamente, por ejemplo, basándose en métricas de rendimiento monitorizado y las presentes necesidades del sistema para más o menos nodos retransmisores de una clasificación dada. Además, si existen suficientes nodos A en un ASN para retransmitir segmentos de vídeo, un nodo A puede designarse como un nodo "B:A", que indica que se tratará como un nodo B, pero puede elevarse a un nodo A si fuera necesario (por ejemplo, si los nodos A existentes dejan el canal). En una realización, si un nodo individual muestra un cambio en rendimiento significativo (para mejor o peor), el nodo puede volverse a clasificar (por ejemplo, de un nodo B a un nodo C, o viceversa), y, si y cuando el problema se resuelva por sí mismo, restaurarse a su clasificación inicial.
En otra realización, los nodos cliente asignan múltiples "puestos" (basándose, por ejemplo, en sus capacidades y métricas de rendimiento de cliente) para posibilitar retransmitirlos y recibir los fragmentos de un segmento de vídeo a y desde múltiples otros nodos. En esta realización, los nodos cliente reciben un segmento de vídeo desde únicamente un nodo "alimentador", pero pueden "alimentar" o retransmitir ese segmento de vídeo a múltiples otros nodos cliente. A los nodos A se les asigna hasta ocho puestos de retransmisión, cuatro para retransmitir a nodos A en el mismo ASN y cuatro para retransmitir a nodos A en otros ASN - es decir, a través de un punto de pares de ASN. A los nodos B:A y B se les asigna hasta ocho puestos para retransmitir a otros nodos cliente (es decir, otros nodos B:A, B y C) en su ASN. En otra realización, un nodo cliente puede "alimentarse" por múltiples otros nodos cliente (por ejemplo, alternando fragmentos entre múltiples puestos entrantes). Esta técnica puede emplearse para flujos de vídeo de alta tasa de bits (por ejemplo, 4K) en los que se requiere rendimiento superior.
5
10
15
20
25
30
35
40
45
50
55
60
65
En otra realización, ciertos nodos (basándose, por ejemplo, en sus capacidades y métricas de rendimiento de cliente) pueden recibir múltiples resoluciones de un segmento de vídeo desde un único nodo alimentador (o, en una realización alternativa, recibir diferentes resoluciones desde diferentes nodos alimentadores). Si el ancho de banda aguas arriba de estos nodos es suficiente, pueden considerarse nodos de "polidifusión" y, hasta el punto necesario, pueden retransmitir también o alimentar aquellas múltiples resoluciones de un segmento de vídeo a uno o más nodos designados.
Para facilitar la reconfiguración dinámica de las redes superpuestas, el servidor de difusión virtual emplea un motor de aprendizaje de profundidad de "mapeador de profundidad" que analiza continuamente métricas de rendimiento para predecir el nivel de congestión a través de los puntos de pares de ASN - es decir, para predecir el nivel de congestión de un punto de pares de ASN en un breve tiempo (por ejemplo, un minuto) en el futuro. En una realización, se genera un "valor de congestión" previsto para cada trayectoria inter-ASN potencial entre nodos A - por ejemplo, desde un nodo A en un ASN a un nodo A en otro ASN. En otra realización, el valor de congestión refleja el nivel previsto de congestión para la trayectoria óptima entre cada par de nodos A.
En una realización, el servidor de difusión virtual emplea un "creador de red superpuesta" para generar y reconfigurar dinámicamente (en su totalidad o en parte) tanto redes superpuestas inter-ASN como intra-ASN - por ejemplo, determinando una trayectoria óptima para segmentos de vídeo a insertarse desde un nodo a otro tanto en como a través de los ASN. En esta realización, el creador de red superpuesta considera el número de puestos disponibles que cada nodo puede utilizar, así como el número de resoluciones que cada nodo puede recibir o retransmitir.
El creador de red superpuesta genera y reconfigura dinámicamente (con la asistencia del mapeador de profundidad) una red superpuesta "troncal de datos virtual inter-ASN, que representa la topología de los nodos A. En otras palabras, representa los nodos A y los enlaces o trayectorias de encaminamiento que un segmento de vídeo seguirá entre estos nodos A en y (en particular) a través de los ASN - es decir, a través de puntos de pares de ASN potencialmente congestionados.
La parte troncal de datos virtual identifica el conjunto de nodos A que se ordenará que soliciten cada segmento de vídeo desde el servidor de contenido de POI cercano (por ejemplo, usando el fichero de manifiesto actual), así como el conjunto de nodos A al que cada uno de ellos insertará ese segmento de vídeo, y así sucesivamente (tanto en como a través de los ASN). Como resultado, ese segmento de vídeo se expandirá a través de cada ASN que contiene un nodo de visualización. Para alcanzar cada nodo de visualización, el segmento puede también recorrer a través de los ASN principales privados intermedios sin nodos de visualización.
El creador de red superpuesta también genera una o más redes superpuestas "de enjambre" intra-ASN para retransmitir un segmento de vídeo desde los nodos A en un ASN a los nodos B:A, B y C en ese ASN. Estas redes superpuestas de enjambre pueden reconfigurarse dinámicamente (en su totalidad o en parte) para cada segmento de vídeo (o para cada fragmento de un segmento de vídeo en una realización alternativa). En una realización, cada red superpuesta de enjambre en un ASN representa una topología jerárquica (con respecto a un nodo A en el ASN) de los nodos B:A, B y C que reciben, ven y retransmiten (con la excepción de los nodos C) el segmento de vídeo entre los nodos en esa jerarquía de enjambre.
Por lo tanto, el sistema de difusión virtual y los métodos de la presente invención hacen uso eficaz de capacidad limitada en puntos de pares de ASN y otros puntos clave de congestión monitorizando y analizando tráfico de red para optimizar el encaminamiento de contenido digital entre nodos de redes superpuestas troncales de datos virtuales y de enjambre que se reconfiguran dinámicamente basándose en pronósticos de niveles de congestión en estos puntos de congestión clave, manteniendo de esta manera una QoE uniforme entre usuarios de sistema.
Breve descripción de los dibujos
La Figura 1 es un gráfico que ilustra una realización de redes superpuestas de la presente invención configuradas dinámicamente en la parte superior de la Internet;
La Figura 2 es un diagrama de bloques que ilustra una realización de componentes del lado del cliente claves de un dispositivo de envío de vídeo por flujo continuo de cliente de la presente invención;
La Figura 3 es un diagrama de bloques que ilustra una realización de componentes del lado de servidor claves de un servidor de difusión virtual de la presente invención.
La Figura 4 es un diagrama de flujo que ilustra una realización de un proceso de envío de vídeo por flujo continuo dinámico de la presente invención.
Descripción detallada
Se describen a continuación realizaciones detalladas de los sistemas y métodos de la presente invención ilustrados
5
10
15
20
25
30
35
40
45
50
55
60
65
en las figuras adjuntas. Debería observarse al principio que la presente invención no está limitada a las realizaciones particulares analizadas a continuación con referencia a las figuras.
Como se ha indicado anteriormente, aunque se describe una aplicación específica de la presente invención en el presente documento en el contexto de entregar vídeo por flujo continuo a través de la Internet a grandes números de usuarios concurrentes, los principios de la presente invención se aplican igualmente en numerosos otros contextos donde la capacidad limitada de enlaces compartidos entre componentes de red restringe el encaminamiento de cualquier tipo de contenido digital.
Incluso en el contexto de entregar vídeo por flujo continuo a través de la Internet, la asignación de funcionalidad entre nodos cliente y componentes servidor descritos en el presente documento es el resultado de ajustes de diseño, y mucha de esta funcionalidad podría reasignarse entre componentes del lado de cliente y del lado de servidor. De manera similar, la funcionalidad del lado de cliente podría asignarse en un único componente modular o extenderse a través de múltiples diferentes componentes, y podría implementarse como una o más aplicaciones independientes o aplicaciones móviles, o como una combinación de aplicaciones independientes y Javascript u otros lenguajes de generación de guiones o programación. Además, los componentes del lado de servidor podrían implementarse en un único servidor de hardware, o a través de múltiples diferentes servidores. Tal funcionalidad podría integrarse también en un único módulo de software o asignarse entre diferentes módulos de software extendidos a través de uno o más servidores de hardware.
Finalmente, en aquellas realizaciones en las que se utilizan protocolos y bibliotecas normalizados (por ejemplo, HTTP, conector Web, WebRTC, STUN y diversas normas de envío por flujo continuo adaptativo), la funcionalidad proporcionada por alguno o todos tales protocolos y bibliotecas normalizadas podría sustituirse por otras implementaciones normalizadas o propietarias.
Redes superpuestas
La Figura 1 es un gráfico que ilustra una realización de redes superpuestas 100 de la presente invención mapeadas en la parte superior de la Internet. Aunque la propia Internet puede ilustrarse por sí misma en una multitud de diferentes maneras, la Figura 1 ilustra la Internet como un conjunto de anillos de fibra de ASN 110, interconectados mediante puntos de pares 120. Los nodos cliente individuales que ven un canal de vídeo particular en cualquier punto en el tiempo se ilustran dentro de cada ASN 110. Aunque no se muestra en la Figura 1, múltiples canales, y por lo tanto múltiples conjuntos de redes superpuestas 100, podrían estar activas (en una realización) simultáneamente.
Como se ha indicado anteriormente, una red superpuesta troncal de datos virtual representa las interconexiones 175 entre los nodos A 130, tanto en un ASN 110 (conectado directamente) y a través de los ASN 110 (es decir, mediante puntos de pares 120). El conector principal 195 ilustra la interconexión de nodos A entre dos ASN 110, mediante un ASN privado (no mostrado) que no incluye ningún modo comercial, sino simplemente interconecta dos ASN públicos 110. Por ejemplo, el conector principal 195 se muestra conectando un nodo A 130 en el ASN 110-f con un nodo A 130 en el ASN 110-e. En este escenario, el tráfico entre estos dos nodos A 130 puede recorrer a través de múltiples puntos de pares "privados" 120 (u otras conexiones propietarias con ASN privados).
Como se ha dicho anteriormente, en una realización, el rendimiento de tales conexiones puede monitorizarse únicamente en los puntos de extremo (es decir, los dos nodos A 130), como es el caso con las conexiones 175 entre nodos A 130 en dos ASN públicos diferentes 110 (es decir, mediante un punto de pares 120). El tráfico a lo largo de una conexión 175 entre dos nodos A 130 en el mismo ASN 110 será probablemente más rápido que el tráfico a través de los ASN 110, ya que no atraviesa un punto de pares 120 potencialmente congestionado. Aunque el conector secundario 195 y las conexiones 175 a/desde nodos A 130 se ilustran con flechas en un sentido, estas reflejan únicamente trayectorias de encaminamiento en un sentido actuales, a pesar del hecho de que se soporta conectividad en dos sentidos entre todos los nodos cliente ilustrados en la Figura 1.
Debería observarse que todo el tráfico entre cualesquiera dos nodos cliente de la presente invención atraviesa la Internet pública, y por lo tanto pasa a través de diversos encaminadores intermedios (no mostrados) que afecta a la QoS. El sistema monitoriza efectos de QoS tanto en un ASN 110 como a través de los ASN 110 (y por lo tanto uno o más puntos de pares 120). En una realización, tal tráfico intra-ASN e inter-ASN se monitoriza por cada nodo cliente (en la dirección del servidor de difusión virtual), y se entrega al servidor de difusión virtual para reconfiguración dinámica de los nodos y trayectorias de encaminamiento representadas por las redes superpuestas 100 (incluyendo la red superpuesta troncal de datos virtuales entre nodos A 130 y las redes superpuestas de enjambre desde cada nodo A 130 en un ASN 110 a los nodos B (y B:A) 140 y nodos C 150 en ese ASN 110).
La Figura 1 ilustra las diversas trayectorias de encaminamiento que sigue un segmento de vídeo entre nodos cliente dado un "estado actual" de estas redes superpuestas 100. En otras palabras, ilustra una topología actual de estas redes superpuestas 100 que, en una realización, puede reconfigurarse dinámicamente para cada segmento de vídeo (y, en una realización alternativa, para cada fragmento de un segmento de vídeo). Debería observarse que, para cualquier segmento de vídeo particular, las redes superpuestas 100 pueden o no reconfigurarse (en su totalidad o en
5
10
15
20
25
30
35
40
45
50
55
60
65
parte), ya que esta decisión dependerá al menos en parte de las métricas de rendimiento recogidas a través del tiempo.
El ASN 110-c ilustra un escenario en el que el servidor de contenido de POI (no mostrado) reside en el ASN 110-c o cerca (por ejemplo, a través de uno o dos otros ASN 110), y responde a una solicitud de HTTP para entregar el segmento de vídeo actual al nodo A 130-a para iniciar el envío por flujo continuo de segmentos de vídeo en un canal a lo largo de las redes superpuestas 100. Como se analizará en mayor detalle a continuación, el servidor de contenido de POI normalmente entregará cada segmento de vídeo a múltiples nodos solicitantes A 130 en el mismo ASN o cercano 110, y estos nodos A 130 a su vez insertan el segmento de vídeo a múltiples otros nodos a lo largo de las redes superpuestas 100, dando como resultado una "redistribución" de múltiples copias concurrentes de fragmentos de segmentos de vídeo que se entregan y se retransmiten desde nodos cliente en cualquier punto en el tiempo dado.
En este escenario, el nodo A 130-a retransmite el segmento de vídeo a otros dos nodos A 130 - uno en el ASN 110- c y otro a través de un punto de pares 120 al ASN 110-a. Como se ha indicado anteriormente, la red superpuesta troncal de datos virtuales representa las trayectorias de encaminamiento que un segmento de vídeo seguirá a medida que se retransmite entre nodos A 130 en y a través de los ASN 110. Por lo tanto, en este escenario, el segmento de vídeo se retransmite no únicamente entre múltiples nodos A 130 en el ASN 110-c, sino también desde el ASN 110-a a través de diversos puntos de pares 120 a múltiples ASN interconectados directamente ASN (es decir, 110-a, 110-d, 110-f y 110-g), desde los que se retransmite adicionalmente a través de múltiples saltos de la red superpuesta troncal de datos virtuales a otros ASN 110.
Como se explicará en mayor detalle a continuación, el número de nodos A 130 requerido en un ASN 110 dependerá de diversos factores, tal como el número de otros nodos de visualización cliente en ese ASN 110, así como sus capacidades relativas (como se determina por su clasificación, número de puestos abiertos y métricas de rendimiento monitorizadas a través del tiempo). Por ejemplo, los ASN 110-b, 110-f, 110-i y 110-j cada uno se ilustra con un único nodo A 130, incluso aunque tengan diferentes números de otros nodos cliente para alimentar (compárese con el otro nodo único en el ASN 110-f a los muchos otros nodos en el ASN 110-i).
Aunque el ancho de banda aguas arriba monitorizado de un nodo es un factor clave al determinar cuántos nodos alimentarán directamente (es decir, cuántos puestos salientes se usarán), es importante reconocer que la longitud de la "cadena" de nodos en un ASN 110 (que retransmite un segmento de vídeo desde uno al siguiente y así sucesivamente) es en gran medida poco relevante dado cómo de rápido se efectúan estas retransmisiones (normalmente muy por debajo de 1 ms). Por ejemplo, el único nodo A en el ASN 110-i, que alimenta directamente dos nodos A en los ASN externos 110 (ASN 110-g y ASN 110-j) así como dos nodos B 130 en el ASN 110-1, usa 4 puestos salientes (que refleja ancho de banda relativamente alto aguas arriba monitorizado en esta realización). Además, la cadena larga de nodos B 140 y nodos C 150 que se alimentan indirectamente desde el único nodo A en el ASN 110-i no es un reflejo de su ancho de banda aguas arriba.
En cada ASN 110, se generan una o más redes superpuestas de enjambre (reconfiguradas dinámicamente para cada segmento de vídeo en esta realización) para retransmitir el segmento de vídeo en ese ASN 110 desde cada nodo A (es decir, el nodo "raíz" de una red superpuesta de enjambre) a los diversos nodos B (y B:A) 140 y nodos C 150 en esa red superpuesta de enjambre. Aunque únicamente se ilustra una red superpuesta de enjambre en el ASN 110-c (en comparación con dos redes superpuestas de enjambre ilustradas en el ASN 110-h), el número de redes superpuestas de enjambre generadas en cada ASN 110 (y topología interna de cada red superpuesta de enjambre) dependerá de diversos factores, tal como el número de nodos de visualización cliente en ese ASN 110, así como métricas de rendimiento actuales e históricas, número de puestos abiertos, etc.
Como se ha indicado anteriormente, un nodo cliente, tal como el nodo A 130-b en el ASN 110-b, puede recibir un segmento de vídeo desde múltiples otros nodos cliente (en este caso desde otros dos nodos A 130 en diferentes ASN (110-a y 110-d). En una realización, estos otros dos nodos alimentadores alternan el envío de fragmentos del segmento de vídeo al nodo A 130-b por razones de rendimiento - por ejemplo, puesto que estos fragmentos cruzan puntos de pares 120, cuyos niveles de congestión se monitorizan continuamente, como se explicará en mayor detalle. En otras realizaciones, esto puede hacerse por fines de redundancia- por ejemplo, debido a que la fiabilidad de los nodos alimentadores puede ser cuestionable basándose en métricas de rendimiento histórico (aparte de o además de la congestión de los puntos de pares 120.
Los métodos mediante los cuales se monitorizan las métricas de rendimiento, se retransmiten segmentos de vídeo y se reconfiguran dinámicamente redes superpuestas 100, se exploran en mayor detalle a continuación con respecto a la Figura 4, siguiendo un análisis de componentes funcionales clave del lado del cliente (Figura 2) y del lado del servidor (Figura 3) que implementan estos métodos.
Dispositivo de envío de vídeo por flujo continuo de cliente
Volviendo a la Figura 2, el dispositivo cliente 200 ilustra una realización de componentes clave de un dispositivo de envío por flujo continuo cliente de la presente invención. El dispositivo cliente 200 puede implementarse como un
5
10
15
20
25
30
35
40
45
50
55
60
65
ordenador de sobremesa o portátil, así como un teléfono inteligente u otro dispositivo móvil, o virtualmente cualquier otro dispositivo electrónico de consumo que pueda manejar contenido de envío por flujo continuo, tal como envío de vídeo por flujo continuo. El dispositivo cliente 200 incluye ciertos componentes de hardware y software normalizados y periféricos relacionados 210, incluyendo una CPU 212, memoria 214, sistema operativo 216, adaptador de red 217, pantalla 218 y cámara 219, que son bien conocidos en la técnica. El dispositivo cliente 200 utiliza estos componentes y periféricos 210, junto con ciertas bibliotecas normalizadas 220, para hacerse un nodo de red, y para recibir, visualizar y retransmitir contenido de vídeo por flujo continuo entre otros nodo de red del sistema de difusión virtual de la presente invención.
La presente invención se aprovecha de ciertas bibliotecas normalizadas 220 (también halladas en la mayoría de los teléfono inteligentes, así como muchos otros dispositivos informáticos) que implementan protocolos de red y otra funcionalidad que puede emplearse para facilitar el envío por flujo continuo de contenido de vídeo entre dispositivos. Por ejemplo, el contenido de vídeo puede enviarse por flujo continuo entre dos usuarios de teléfonos inteligentes en sus exploradores web móviles sin requerir ningún módulo de extensión. Las librerías normalizadas 220 incluyen las API de WebRTC 222 (que facilitan la comunicación de explorador a explorador para enviar por flujo continuo contenido de vídeo), diversas implementaciones de envío por flujo continuo adaptativo 224, tal como HLS, MPEG- Dash, y envío por flujo continuo suavizado, entre otras (que posibilitan ajuste automático de tasas de bits de envío por flujo continuo para "adaptarse" a detección en tiempo real de cambios en ancho de banda de cliente y capacidad de CPU), el protocolo de conector web 226 (que facilita comunicaciones cliente-servidor en dos sentidos rápidas a través de una única conexión de TCP/IP) y HTTP 228 (para comunicaciones normalizadas menos frecuentes entre servidores web y exploradores web clientes).
El dispositivo cliente 200 también incluye un reproductor normalizado 232 (en una realización, un reproductor de vídeo normalizado integrado en un explorador web HTML5 normalizado 230) para ver o reproducir por envío de flujo continuo contenido digital. En otras realizaciones, el reproductor normalizado 232 está integrado en una aplicación de sobremesa independiente o aplicación de teléfono inteligente. Una ventaja de aprovechar el explorador web HTML5 normalizado 230 es que muchas de las bibliotecas normalizadas 220 están diseñadas para funcionar con exploradores web, y por lo tanto no requieren ningún módulo de extensión u otra funcionalidad personalizada que necesitaría una aplicación de sobremesa independiente o aplicación de teléfono inteligente.
Además, los exploradores web también soportan lenguajes de generación de guiones del lado del cliente, tales como Javascript, que se usa frecuentemente para complementar funcionalidad de explorador web convencional (entregada, por ejemplo, desde un servidor web normalizado como parte de una página web, sin requerir ningún módulo de extensión de explorador cliente). En una realización, los componentes clave no normalizados del dispositivo cliente 200 (incluyendo el comunicador 270, el monitor de rendimiento 240, el receptor 250, el retransmisor 260, y el cargador 280) se implementan en Javascript, y se generan series de contenido 255 y se mantienen por el código de Javascript. Debería observarse, sin embargo, que alguno o todos estos componentes pueden implementarse en otros lenguajes de programación, y en aplicaciones de sobremesa independientes o aplicaciones de teléfono inteligente.
Las bibliotecas normalizadas 220 facilitan el envío por flujo continuo punto a punto (unidifusión) de contenido, incluyendo contenido de vídeo. Los componentes clave no normalizados del dispositivo cliente 200 tratan los aspectos del lado del cliente de la arquitectura de entrega de contenido digital implementada por el sistema de difusión virtual de la presente invención. En una realización, se crea un protocolo de envío por flujo continuo en la parte superior de WebRTC 222 en el que el encaminamiento de contenido se centraliza mediante una arquitectura de cliente-servidor, y el mismo contenido se envía por flujo continuo en una forma distribuida (insertada de nodo a nodo) mediante redes superpuestas P2P dinámicamente reconfigurables.
Un usuario de dispositivo cliente 200 puede encontrar en primer lugar uno o más canales de contenido de diversas maneras diferentes - por ejemplo, mediante enlaces en un correo electrónico o en una página web, o incluso a partir de una aplicación de sobremesa independiente o aplicación de teléfono inteligente. En una realización, el servidor de difusión virtual 300 (analizado en mayor detalle a continuación con respecto a la Figura 3) entrega una página web HTML5 normalizada con una selección de canales al explorador web HTML5 230. Esta "página web de canal" incluye código de Javascript propietario que se interpreta por el explorador web HTML5 230 para implementar la funcionalidad de los componentes no normalizados del dispositivo cliente 200, que incluye comunicar con el servidor de señalización 330 así como con otros nodos cliente (por ejemplo, usando las bibliotecas de WebRTC 222 y envío por flujo continuo adaptativo 224), así como recibiendo, procesando y retransmitiendo fragmentos de segmentos de vídeo desde y hasta tales nodos.
Tras hacer clic en un enlace de canal en la página web de canal, el usuario genera una solicitud para unirse a un canal particular de contenido de vídeo que se está enviando por flujo continuo actualmente, o, en otra realización, empezará a enviarse por flujo continuo en un punto en el tiempo predefinido más tarde (una "solicitud de unión"). El servidor de señalización 330 del servidor de difusión virtual 300 responde a la solicitud de unión intentando restablecer una conexión de conector web 226 con el dispositivo cliente 200 mediante el comunicador 270. Como se analizará en mayor detalle a continuación con respecto a la Figura 3, el servidor de difusión virtual 300 emplea el protocolo "STUN" 322 para descubrir la dirección iP pública del dispositivo cliente 200 (porejemplo, por detrás de un
5
10
15
20
25
30
35
40
45
50
55
60
65
cortafuegos de NAT) de modo que el dispositivo cliente 200 puede establecer una conexión de conector web 226 con el servidor de difusión virtual 300, y conexiones de WebRTC 222 con otros dispositivos de cliente 200 para recibir y retransmitir contenido de vídeo.
En las realizaciones analizadas en el presente documento, el dispositivo cliente 200 se une únicamente a un canal de vídeo en cualquier momento dado. En otras realizaciones, el dispositivo cliente 200 puede unirse en múltiples canales de manera concurrente.
El dispositivo cliente 200 utiliza el comunicador 270 para comunicaciones bidireccionales con el servidor de señalización 330 para facilitar rápidos intercambios de mensajes mientras se mantiene una única conexión de TCP/IP abierta. Como se analizará en mayor detalle a continuación, tales comunicaciones se emplean para diversos fines, incluyendo (i) proporcionar al servidor de difusión virtual 300 con información inicial con respecto a las capacidades del dispositivo cliente 200 (por ejemplo, SO, explorador web y tipo de conexión - 3G, 4G, WiFi, LAN, etc.), (ii) posibilitar que el servidor de difusión virtual 300 verifique conectividad de nodo cliente para envío por flujo continuo inter-nodo de WebRTC 222 posterior de segmentos de vídeo mediante redes superpuestas 100, e (iii) intercambiar información de monitorización dinámica en tiempo real (obtenida mediante el monitor de rendimiento 240, como se analiza a continuación) con el servidor de difusión virtual 300.
En una realización, este código de Javascript contenido en la página web de canal también analiza las capacidades del dispositivo cliente 200 para determinar si es un nodo C (que recibe segmentos de vídeo, pero no lo retransmite a otros nodos cliente), y proporciona esta información al servidor de señalización 330. En otras realizaciones, se envían ciertas capacidades del dispositivo de cliente 200 al servidor de difusión virtual 300, que determina si el dispositivo de cliente 200 es un nodo C.
Este código de Javascript también facilita las comunicaciones con el servidor de contenido de POI 380 para gestionar la recepción de los segmentos de vídeo por el receptor 250 para reproducción por un reproductor normalizado 232. Este proceso es, de hecho, una extensión del escenario de envío de vídeo por flujo continuo punto a punto convencional, que aprovecha la funcionalidad de WebRTC 222 y envío por flujo continuo adaptativo 224 normalizados.
En una realización, el explorador web normalizado 230 interpreta el código de Javascript propietario desde la página web de canal para solicitar ficheros de manifiesto periódicamente como se ha descrito anteriormente. Tales solicitudes de HTTP normalizadas se dirigen al servidor de contenido de POI 380, que proporciona los ficheros de manifiesto. El explorador web normalizado 230 también se aprovecha de las bibliotecas de envío por flujo continuo normalizadas 224 para solicitar los mismos segmentos de vídeo desde las localizaciones especificadas en el fichero de manifiesto, que incluyen versiones de tasas de bits superior o inferior de estos segmentos de vídeo como se ha analizado anteriormente (por ejemplo, cuando se detecta un cambio en ancho de banda).
Estas solicitudes para segmentos de vídeo se interceptan por el código de Javascript propietario desde la página web de canal - es decir, puesto que cada segmento de vídeo se inserta al dispositivo cliente 200 desde otro (alimentador) nodo de redes superpuestas 100 (obviando la necesidad de que el dispositivo cliente 200 inicie una solicitud de "extracción" de HTTP). En una realización (analizada en mayor detalle a continuación), el servidor de difusión virtual 300 añade el dispositivo cliente 200 a las redes superpuestas 100 (y por lo tanto al canal) poco después de que se recibe la solicitud de unión, de modo que uno o más segmentos de vídeo iniciales se insertan al dispositivo cliente 200 para posibilitarle que empiece a reproducir el contenido de vídeo tan pronto como sea posible.
A medida que el receptor 250 recibe fragmentos de cada segmento de vídeo, genera series de contenido 255 para facilitar la recepción y reproducción de los segmentos de vídeo, así como la retransmisión de los segmentos de vídeo (si el dispositivo cliente 200 no está designado un nodo C) a otros nodos cliente. El receptor 250 genera una serie de recepción 256 para compilar los fragmentos en un segmento de vídeo completo, que se proporciona a la memoria intermedia de tres segmentos mantenida por el reproductor normalizado 232. Si, tras interceptar la solicitud de HTTP para un segmento de vídeo, el receptor 250 determina que el segmento de vídeo completo no está aún en la serie de recepción 256, entonces se solicitará el segmento de vídeo desde una localización alternativa (o "repliegue") especificada en el fichero de manifiesto (es decir, el servidor de contenido de POI 380). Desde la perspectiva del reproductor normalizado 232, recibe segmentos de vídeo en respuesta a solicitudes de HTTP normalizadas, y no tiene conocimiento de que los segmentos de vídeo se están realmente insertando al dispositivo cliente 200 mediante redes superpuestas 100.
Además, en una realización, el receptor 250 también se aprovecha de las bibliotecas de envío por flujo continuo adaptativo 224 para comunicar al servidor de señalización 330 (mediante el comunicador 270) la tasa de bits que el dispositivo cliente 200 puede manejar (independientemente de si el reproductor normalizado 232 realiza una solicitud de este tipo de la manera normal mediante el fichero de manifiesto). Por ejemplo, si el dispositivo cliente 200 experimenta una caída significativa temporal en su ancho de banda (que da como resultado que un segmento de vídeo no llegue en la serie de recepción 256 antes de que sea necesario), puede solicitar un (repliegue) segmento de vídeo desde el servidor de contenido de POI 380, y que a continuación se inserten posteriores segmentos de vídeo de resolución inferior mediante redes superpuestas 100. Una vez que la tasa de bits vuelve a normal, puede a
5
10
15
20
25
30
35
40
45
50
55
60
65
continuación insertarse segmentos de vídeo de resolución superior como se hizo antes de que tuviera lugar el problema.
Como se ha indicado anteriormente, en una realización, el servidor de difusión virtual 300 reconfigura dinámicamente las redes superpuestas 100 para cada segmento de vídeo, incluyendo redes superpuestas troncales de datos virtuales (entre nodos A en y a través de los ASN) y redes superpuestas de enjambre (desde cada nodo A en un ASN a otros nodos en ese ASN). A menos que el dispositivo cliente 200 se clasifique como un nodo C (que recibe segmentos de vídeo, pero no los retransmite a otros nodos cliente), el retransmisor 260 recibirá instrucciones desde el servidor de difusión virtual 300 (con respecto a cada segmento de vídeo del canal de vídeo al que se unió) considerando el nodo o nodos a los que retransmitirá ese segmento de vídeo. Como se ha analizado anteriormente con referencia a la Figura 1, si el dispositivo cliente 200 es un nodo A, B:A o B, puede consultarse para retransmitir el segmento de vídeo a múltiples otros nodos cliente.
La longitud de los segmentos de vídeo (por ejemplo, a partir de 1-10 segundos) se define por el originador del contenido de vídeo de acuerdo con normas de envío por flujo continuo adaptativo 224. El retransmisor 260 retransmitirá el segmento de vídeo a cada nodo cliente destino designado insertando fragmentos de acuerdo con el componente de "canal de datos de RTC" de la norma WebRTC 222 (que no obliga un protocolo de señalización).
En una realización, cada segmento de vídeo se divide en fragmentos de 64 KB para adaptar el tamaño de un datagrama de UDP ("paquete") para eficacia máxima cuando se envía por flujo continuo mediante el protocolo de transporte de MPEG2. El dispositivo cliente 200 envía y recibe "paquetes" de UDP un fragmento cada vez (replegándose a TCP cuando sea necesario por la norma de WebRTC 222). Un segmento de vídeo de 1 segundo, por ejemplo, contendría aproximadamente 625 fragmentos (suponiendo un codificador 1080p H.264, que produce aproximadamente 5000 Kbps).
A medida que el receptor 250 recibe fragmentos de cada segmento de vídeo, genera la serie de recepción 256 para compilar estos fragmentos y construir segmentos de vídeo completos. El retransmisor 260 genera la serie de retransmisión 257 para compilar estos fragmentos para el fin de enviarlos (retransmitirlos) a nodos cliente destino designados. De esta manera, la serie de retransmisión 257 actúa como una memoria intermedia para fragmentos entrantes y salientes de un segmento de vídeo. Como se analizará a continuación, el monitor de rendimiento 240 rastrea el tiempo requerido para enviar por flujo continuo el segmento de vídeo completo a cada nodo cliente destino designado, e informa esa métrica de vuelta al servidor de difusión virtual 300 (para uso posterior al reconfigurar dinámicamente redes superpuestas 100).
En una realización, un nodo cliente de recepción recibe un segmento de vídeo desde un único nodo de alimentación, tal como el dispositivo cliente 200. En otra realización, se seleccionan múltiples nodos de alimentación potenciales por el servidor de difusión virtual 300, y comunican entre ellos mismos para negociar los "dos mejores" candidatos (por ejemplo, basándose en el ancho de banda actual u otras métricas de rendimiento monitorizado), y a continuación alternan el envío de fragmentos al nodo cliente de recepción designado.
En otra realización, se insertan múltiples resoluciones diferentes (por ejemplo, 1080p, 720p y 480p) de cada segmento de vídeo entre nodos A, y el servidor de difusión virtual 300 dirige el nodo A a la raíz de cada red superpuesta de enjambre cuál de estas resoluciones insertar a los otros nodos en esa red superpuesta de enjambre (por ejemplo, basándose en las capacidades de estos otros nodos, como se analiza en mayor detalle a continuación).
Durante el tiempo en el que el receptor 250 está recibiendo los fragmentos de un segmento de vídeo para reproducción, y el retransmisor 260 está enviando por flujo continuo estos fragmentos a otros nodos cliente designados, el monitor de rendimiento 240 recopila diversas métricas de rendimiento dinámicas estáticas y en tiempo real como se dirige por el servidor de difusión virtual 300, y proporciona continuamente tales métricas de vuelta al servidor de difusión virtual 300 mediante el servidor de señalización 330.
Como se ha indicado anteriormente, tales métricas se usan por el servidor de difusión virtual 300 para reconfigurar dinámicamente redes superpuestas 100 para optimizar el encaminamiento del siguiente segmento de vídeo. En particular, las métricas de rendimiento se usan para clasificar y reclasificar nodos cliente, asignar y desasignar puestos para retransmitir segmentos de vídeo a otros nodos cliente, determinar qué resoluciones de segmentos de vídeo pueden recibirse y retransmitirse a otros nodos cliente, y finalmente modificar un subconjunto de las trayectorias de encaminamiento entre los nodos cliente cuando se reconfiguran dinámicamente las redes superpuestas 100. La manera precisa en la que se utilizan estas métricas de rendimiento por el servidor de difusión virtual 300 se analizará en mayor detalle a continuación con respecto a la Figura 3.
Las métricas de rendimiento estáticas, tales como el tipo de sistema operativo, explorador y conexión (por ejemplo, celular 3G o 4G, WiFi, LAN, etc.), no es probable que cambien de manera frecuente y normalmente se informan al servidor de señalización 330 únicamente después de la solicitud de unión inicial por el dispositivo cliente 200 (aunque se informarán en el caso de un cambio - por ejemplo, un cambio en conexión celular de 3G a 4G).
5
10
15
20
25
30
35
40
45
50
55
60
65
Aunque la información dinámica podría recopilarse e informarse en una base continua (es decir, a medida que se recoge), se tienen en cuenta diversos ajustes en una realización para asegurar que la "tara" (frecuencia de monitorización e información de estas métricas dinámicas al servidor de señalización 330) no afecta la "cabida útil" o rendimiento de la entrega del mismo vídeo (es decir, el envío por flujo continuo de fragmentos a y desde el dispositivo cliente 200). En una realización, tales métricas se usan únicamente para el siguiente segmento de vídeo, mientras que en otras realizaciones, pueden efectuarse cambios para el siguiente fragmento (o múltiples fragmentos) durante la entrega del segmento de vídeo actual.
En una realización, se realizan dos tipos de monitorización de rendimiento dinámico. El primero implica tiempos de "ping" (u otras mediciones similares) para conocer sitios en la Internet (por ejemplo, a un servidor web de Yahoo, servidor de difusión virtual, etc.), tanto en como a través del ASN en el que reside el dispositivo cliente 200. De manera individual, tales métricas proporcionan visión sobre el rendimiento del dispositivo cliente 200, mientras que de manera colectiva proporcionan visión adicional sobre QoS tanto en el ASN en el que reside el dispositivo cliente 200, como a través de los ASN mediante puntos de pares particulares. Aunque la red superpuesta troncal de datos virtuales (entre nodos A) es de relativamente mayor interés (debido a la congestión en puntos de pares), la congestión en un ASN también es relevante (ya que puede requerir, por ejemplo, reconfiguración dinámica de al menos parte de una o más de las redes superpuestas de enjambre en el ASN).
El otro tipo de monitorización de rendimiento dinámico implica el tiempo total requerido para retransmitir un segmento de vídeo desde un nodo cliente a otro. En una realización, cada nodo (distinto de los nodos C) registra el tiempo de "inicio" cuando envía el primer fragmento de un segmento de vídeo a un nodo cliente destino designado, así como el tiempo de "detención" después de que se recibió el último fragmento de ese segmento de vídeo (por ejemplo, debido a que la norma WebRTC 222 proporciona verificaciones de cada paquete). El monitor de rendimiento 240 envía este tiempo total (para cada segmento de vídeo que envía) al servidor de señalización 330. Esta métrica también puede proporcionar idea no únicamente con respecto al rendimiento individual del dispositivo cliente 200, sino también el nivel de congestión tanto en su ASN, como a través de los ASN (por ejemplo, si el dispositivo cliente 200 es un nodo A que alimenta otro nodo A a través de un punto de pares de ASN).
En una realización, el usuario del dispositivo cliente 200 puede ser también el originador de contenido de vídeo. En la mayoría de los casos, este escenario resulta de la calidad cada vez mayor de las cámaras de teléfonos inteligentes (tal como la cámara 219), que posibilitan que los usuarios capturen eventos de vídeo "en cualquier momento en cualquier tiempo". Pero, también es posible que los usuarios de ordenadores de sobremesa u ordenadores portátiles, así como teléfonos inteligentes, obtengan eventos de vídeo pregrabados desde otras fuentes.
El problema es que el dispositivo cliente 200 debe enviar por flujo continuo de alguna manera su contenido de vídeo a través de la Internet al servidor de difusión virtual 300, que puede estar a muchos saltos de distancia a través de múltiples ASN. El cargador 280 trata este problema mediante un protocolo de "lluvia" propietario designado para evitar que los paquetes de UDP se retarden o bloqueen en encaminadores intermedios. En una realización, el cargador 280 se implementa mediante una aplicación de teléfono inteligente especializada en el dispositivo cliente 200, a diferencia de basarse en una o más funcionalidades de Javascript del lado del cliente limitadas.
Para implementar este protocolo de lluvia, el cargador 280 establece una conexión de TCP/IP con el servidor de difusión virtual 300, y emplea "ráfagas" de UDP para entregar los tamaños de paquete de IP más grandes disponibles ("unidad máxima de transmisión" o MTU). Además, los flujos de UDP continuos (ya se envíen mediante un único puerto de encaminador o se distribuyan a través de múltiples puertos de encaminador) a menudo se detectarán por encaminadores intermedios como un ataque de "denegación de servicio" (DOS), y se bloquean de esta manera. Además, tales flujos de UDP pueden desbordar una memoria asignada del encaminador (por ejemplo, una cola de FIFO) puesto que los encaminadores normalmente asignan memoria para paquetes de UDP (a diferencia de paquetes de TCP más comunes) únicamente mientras se están recibiendo.
Para tratar estos obstáculos, el cargador 280 no distribuye únicamente paquetes de UDP entre múltiples puertos (por ejemplo, 6 puertos en una realización), también retarda los paquetes enviados en cualquier puerto individual para evitar que se detecten como un ataque de DOS. En una realización, el retardo en cada puerto es lo suficientemente largo para evitar la detección como un ataque de DOS, y lo suficientemente largo para posibilitar que los encaminadores asignen suficiente memoria, pero lo suficientemente corto para proporcionar suficiente ancho de banda para entregar un segmento de vídeo a través de múltiples ASN, y lo suficientemente corto para evitar ser percibidos como el final de un flujo de UDP (que provocaría que el encaminador deje de asignar memoria para paquetes de UDP y esencialmente "los descarte").
A medida que el cargador 280 entrega cada segmento de vídeo al servidor de difusión virtual 300 de esta manera, el servidor de difusión virtual 300 a continuación genera un canal para redistribuir este contenido de vídeo a lo largo de las redes superpuestas 100 como si se hubiera recibido desde una CDN más tradicional. En otra realización, el servidor de difusión virtual 300 emplea este protocolo de lluvia propietario en los escenarios relativamente poco frecuentes en los que es la fuente de punto de origen de repliegue de un segmento de vídeo para un nodo cliente cuyo segmento de vídeo actual no llegó a tiempo a lo largo de las redes superpuestas 100.
5
10
15
20
25
30
35
40
45
50
55
60
65
Servidor de difusión virtual
La Figura 3 ilustra una realización de componentes clave del lado del servidor de un servidor de difusión virtual 300 de la presente invención. Como se ha indicado anteriormente, aunque los componentes del servidor de difusión virtual 300 se ilustran en un único servidor de hardware físico, la funcionalidad de estos componentes puede reasignarse entre múltiples diferentes dispositivos de hardware físico y diferentes módulos de software.
El servidor de difusión virtual 300 incluye cierta funcionalidad normalizada, tal como el HW/SW normalizado 310, encontrado en la mayoría de los servidores de hardware - por ejemplo, una CPU 312, memoria 314, sistema operativo 316, adaptador de red 317 y una pantalla 318. En ciertas realizaciones, el servidor de difusión virtual 300 también se aprovecha de las bibliotecas normalizadas 320, que pueden incluir, por ejemplo, (i) el protocolo STUN 322 ("Utilidades Transversales de Sesión para NAT"), que facilitan el descubrimiento de direcciones IP públicas de dispositivos cliente 200 detrás de un cortafuegos de NAT, de modo que los nodos cliente pueden enviar y recibir vídeo a y desde otros nodos cliente, así como establecer conexiones con el servidor de difusión virtual 300; (ii) el protocolo de conector web 326, que facilita comunicaciones de cliente-servidor bidireccionales rápidas a través de una única conexión de TCP/IP; y (iii) HTTP 328, que se emplea para comunicaciones normalizadas menos frecuentes con exploradores web cliente, tal como el explorador web HTML5 normalizado 230.
El servidor de difusión virtual 300 no necesita soportar normas de WebRTC 222 y envío por flujo continuo adaptativo 224 puesto que no es un nodo cliente en las redes superpuestas 100, incluso aunque analiza de manera continua métricas de rendimiento obtenidas desde nodos cliente, y reconfigura dinámicamente las trayectorias de encaminamiento para los canales de contenido de vídeo distribuidos entre estos nodos cliente a lo largo de las redes superpuestas 100.
El servidor de difusión virtual 300 sirve como el punto "originador de canal" de origen para las redes superpuestas 100, en particular, para la red superpuesta troncal de datos virtuales. En una realización, el servidor de contenido de POI 380 designa uno o más nodos cercanos A (preferentemente en su ASN, si es posible) para emitir solicitudes de HTTP para segmentos de vídeo. Estos nodos A sirven de manera efectiva como la raíz de la red superpuesta troncal de datos virtuales, e insertan cada segmento de vídeo a otros nodos A en y a través de los ASN, y finalmente a otros nodos mediante las redes superpuestas de enjambre en cada ASN.
Como se describirá en mayor detalle a continuación con referencia al servidor de contenido de POI 380, tal funcionalidad de "origen de canal" no requiere uso de las bibliotecas WebRTC 222 y de envío por flujo continuo adaptativo 224 normalizadas que se dirigen a envío de vídeo por flujo continuo de explorador a explorador. Como se ha indicado anteriormente, el servidor de contenido de POI 380 también sirve como la fuente de segmentos de vídeo alternativa (repliegue) ocasional para nodos cliente que no reciben el segmento de vídeo actual a tiempo a lo largo de las redes superpuestas 100. Tales nodos cliente emiten solicitudes de HTTP a las que el servidor de contenido de POI 380 responde enviándoles el segmento de vídeo solicitado.
Como se ha indicado también anteriormente, el servidor de contenido de POI 380 sirve como el punto de origen para todos los canales de vídeo (en una realización), ya se obtenga el contenido de vídeo desde un dispositivo cliente 200 mediante el cargador 280 o desde una CDN más tradicional (y ya se envíe por flujo continuo al servidor de difusión virtual 300 en tiempo real, o se proporcione con antelación para envío por flujo continuo en un momento más tarde).
El administrador de canal 385 es responsable de establecer y mantener cada canal, mientras que el servidor de contenido de POI 380 prepara el mismo contenido de vídeo para enviar por flujo continuo como un canal a los nodos cliente. En una realización, el administrador de canal 385 genera y mantiene la página web de canal para entrega por el servidor de contenido de POI 380 a través de la Internet, y usa por el servidor de señalización 330 al responder a solicitudes de unión desde los dispositivos cliente 200 que buscan unirse a un canal particular.
Para fines de soporte, se establece una "consola de soporte de observador" y se mantiene por el administrador de canal 385 para soportar observadores individuales cuyos dispositivos cliente 200 están experimentando problemas, así como un "centro de reproducción" para monitorización en directo de todos los canales de vídeo de modo que pueden tratarse problemas específicos de canal y específicos de región (por ejemplo, a medida que se acumulan llamadas de soporte desde una región geográfica particular). La monitorización en tiempo real de "analíticas de canal" se mantiene también por el administrador de canal 385 para proporcionar datos útiles para estas funciones de soporte, así como para los originadores de contenido de vídeo (por ejemplo, en una CDN). Por ejemplo, las analíticas incluyen métricas en tiempo real con respecto al estado actual de cada canal de vídeo y los nodos de red a lo largo de las redes superpuestas 100, así como problemas de la última milla y otros relacionados con tasas de bits de vídeo, puntos de congestión, latencia de nodo, etc.
Finalmente, se proporciona la funcionalidad de "administración de canal" para gestionar los canales de vídeo e interconectar con el servidor de señalización 330 de modo que tenga información actual necesaria para facilitar sus comunicaciones con los dispositivos cliente 200 (por ejemplo, con respecto a unirse a un canal, proporcionar métricas de rendimiento monitorizado de cliente, obtener cambios de reencaminamiento y resolución o de tasa de bits para objetivos de retransmisión, etc.).
5
10
15
20
25
30
35
40
45
50
55
60
65
La funcionalidad del lado del servidor restante ilustrada en la Figura 3, con la excepción del extractor de pantalla de presentación 390, se describirá, por simplicidad, en el contexto de un único canal de contenido de vídeo. Obsérvese, sin embargo, que esta funcionalidad se realiza simultáneamente, en una realización, para múltiples canales en cualquier momento dado, y para diverso contenido digital.
Antes de que los nodos cliente accedan a un canal de vídeo, el contenido de vídeo se transcodifica para crear múltiples flujos de segmentos de vídeo de resolución inferior. En una realización, el servidor de contenido de POI 380 se implementa como un servidor de HTTP 228 que puede comunicar con exploradores web HTML5 normalizados 230 en los dispositivos cliente 200. A diferencia del servidor de señalización 330, que establece conexiones de conector web 225 con dispositivos cliente 200 para comunicaciones bidireccionales frecuentes (por ejemplo, intercambiar cambios de encaminamiento, datos de rendimiento, etc.), el servidor de contenido de POI 380 responde a solicitudes de HTTP de cliente relativamente poco frecuentes 228 desde exploradores web de HTML5 normalizados 230 para ficheros de manifiesto, segmentos de vídeo ocasionales que no llegaron a tiempo mediante las redes superpuestas 100, etc.
Como se ha indicado anteriormente, el servidor de contenido de POI 380 también se basa en el protocolo de HTTP 228 para implementar su funcionalidad de origen de canal de ancho de banda superior - es decir, respondiendo a solicitudes de HTTP para segmentos de vídeo desde nodos A cercanos (en la raíz de la red superpuesta troncal de datos virtuales, normalmente en el mismo ASN que el servidor de contenido de POI 380, o en uno o dos saltos). En otras realizaciones, estos segmentos de vídeo se insertan a estos nodos A de acuerdo con las normas de WebRTC 222 y envío por flujo continuo adaptativo 224, o mediante otras técnicas de envío de vídeo por flujo continuo (incluyendo el protocolo de lluvia usado por el cargador 280 como se ha analizado anteriormente).
En una realización, el servidor de contenido de POI 380 transcodifica contenido de vídeo en 3 resoluciones diferentes (1080p, 720p y 480p), aunque se soportan diversas otras resoluciones superiores e inferiores en otras realizaciones (por ejemplo, 4K, 360VR, 180VR, 240p, etc.), que incluyen una única resolución fija para todo el contenido de vídeo. Si el vídeo de la fuente original se proporciona a una resolución inferior (por ejemplo, 720p), entonces únicamente pueden soportarse resoluciones de 720p y 480p para ese canal de vídeo. Esta funcionalidad facilita el envío por flujo continuo de tasa de bits adaptativa, ya se inicie por los nodos cliente (como se ha analizado anteriormente) o por el servidor de difusión virtual 300 basándose en un análisis de métricas de rendimiento de cliente.
En una realización, el servidor de contenido de POI 380 inicia un canal respondiendo a una solicitud de HTTP para proporcionar todas las versiones disponibles (por ejemplo, 3 resoluciones diferentes) de cada segmento de vídeo a uno o más nodos cercanos (normalmente nodos A) que inician la inserción de cada segmento de vídeo a lo largo de las redes superpuestas 100. En otra realización, estos nodos retransmiten todas las versiones a nodos B (y nodos B:A), y finalmente a nodos C, de modo que cada nodo cliente puede aprovecharse de las capacidades de flujo continuo adaptativas 224. Los nodos que retransmiten múltiples resoluciones a otros nodos están realizando "polidifusión" a estas múltiples versiones de un segmento de vídeo a otros nodos cliente mediante las redes superpuestas 100, como se explica en mayor detalle a continuación.
Obsérvese que, mientras que el servidor de contenido de POI 380 inicia un canal proporcionando segmentos de vídeo a uno o más nodos cercanos (en respuesta a solicitudes de HTTP), todos los nodos de visualización cliente reciben de manera eficaz y ven cada segmento de vídeo simultáneamente - es decir, están todos en sincronización, con la condición de que cada segmento de vídeo atraviese las redes superpuestas 100 antes de que haya concluido la reproducción del segmento de vídeo anterior. Puesto que los dispositivos cliente 200 almacenan en memoria intermedia al menos 3 segmentos de vídeo en esta realización, esta memoria intermedia proporciona algún "margen de error" si se retardara ocasionalmente un segmento de vídeo. Además, en otra realización, la iniciación de un canal puede retardarse para proporcionar almacenamiento en memoria intermedia adicional cuando el servidor de contenido de POI 380 empieza en primer lugar a "difundir" el canal. Cuando un dispositivo cliente 200 emite una solicitud para un segmento de vídeo directamente desde el servidor de contenido de POI de repliegue 380 (por ejemplo, debido a que el segmento de vídeo no llegó a tiempo mediante las redes superpuestas 100), esta memoria intermedia puede ser necesaria, por ejemplo, si ese segmento de vídeo cruza uno o más ASN.
Como se ha indicado anteriormente, el servidor de contenido de POI 380 también proporciona ficheros de manifiesto periódicos en respuesta a solicitudes desde el dispositivo cliente 200. Aunque estos ficheros de manifiesto se entregan mediante protocolos de HTTP 328 normalizados, todos ellos son relativamente pequeños y bastante menos críticos en tiempo que los segmentos de vídeo. En una realización, cada fichero de manifiesto identifica la localización de los siguientes 8 segmentos de vídeo a diversas tasas de bits disponibles. En esta realización, las localizaciones son las localizaciones de repliegue en el servidor de contenido de POI 380 puesto que los segmentos de vídeo se insertan en cada dispositivo cliente 200 mediante las redes superpuestas 100.
Una vez que se ha preparado un canal de contenido de vídeo para envío por flujo continuo (empezando con el servidor de contenido de POI 380), el servidor de señalización 330 espera solicitudes de unión desde los dispositivos cliente 200. Tras recibir una solicitud de unión para ese canal desde un dispositivo cliente 200, el servidor de señalización 330 se basa en el protocolo STUN 322 para asegurar que puede establecer una conexión de conector
5
10
15
20
25
30
35
40
45
50
55
60
65
web 326 a través de cualquier cortafuegos de NAT que pueda estar presente en ese dispositivo cliente 200. Además, identificando la dirección de IP pública de ese dispositivo cliente 200, puede proporcionar esa dirección IP pública a otros nodos cliente (por ejemplo, para retransmitir un segmento de vídeo a ese dispositivo cliente 200).
Una vez que se establece una conexión de conector web 326, el dispositivo de cliente 200 proporciona al servidor de señalización 330 con información con respecto a sus capacidades (por ejemplo, SO, explorador web y tipo de conexión 3G, 4G, WiFi, LAN, etc.) incluyendo, en una realización, si el dispositivo cliente 200 es un nodo C (por ejemplo, supuesto para conexiones celulares en esta realización). El dispositivo cliente 200 también proporciona su localización de ASN al servidor de señalización 330, que más tarde se usará para añadir el dispositivo cliente 200 a las redes superpuestas 100.
En una realización, el servidor de señalización 330 prioriza la entrega de uno o más segmentos de vídeo iniciales al dispositivo cliente 200 (mediante las redes superpuestas 100) de modo que puede empezar a reproducir el contenido de vídeo del canal tan pronto como sea posible. Para iniciar este proceso, devuelve el control sobre el creador de red superpuesta 350, que añade el dispositivo cliente 200 a una red superpuesta de enjambre en su ASN (por ejemplo, dirigiendo un nodo B en ese ASN para retransmitir segmentos de vídeo al dispositivo cliente 200). Obsérvese que el dispositivo cliente 200 aún no se ha clasificado, y no retransmitirá aún ningún segmento de vídeo a otros nodos cliente. Pero, siendo parte de las redes superpuestas 100, el dispositivo cliente 200 puede empezar a recibir segmentos de vídeo y reproducir el contenido de vídeo del canal, así como recopilar métricas de rendimiento de cliente, que facilitará su clasificación.
El servidor de señalización 330 a continuación obtiene (mediante su conexión de conector web 326) el ancho de banda aguas arriba y aguas abajo del dispositivo cliente 200. Obsérvese que esta métrica no es demasiado útil, ya que la conexión puede cruzar múltiples aSn (incluso aunque el servidor de señalización 330 conozca la localización de ASN del dispositivo cliente 200). Una métrica más relevante se basará en comunicaciones entre el dispositivo cliente 200 y otros nodos cliente en su propio ASN.
Tras recibir la información de rendimiento de cliente (recopilada por el monitor de rendimiento 240 en el dispositivo cliente 200) desde el dispositivo cliente 200 (y desde otros nodos cliente), el servidor de señalización 330 reenvía esa información al rastreador de rendimiento 340 para análisis inicial y posterior uso por el creador de red superpuesta 350 y el mapeador de profundidad 360 al reclasificar dinámicamente nodos cliente y reconfigurar redes superpuestas 100 para el siguiente segmento de vídeo, como se explica a continuación. El rastreador de rendimiento 340 monitoriza el rendimiento de cada nodo cliente y determina si el nodo cliente está aún "vivo". Por ejemplo, si el dispositivo cliente 200 ha cerrado la conexión y dejado el canal, o no responde a un "ping" dentro de una cantidad de tiempo umbral, se considerará que ha dejado el canal (ya sea de manera intencionada, o como resultado de un fallo de hardware o software). El rastreador de rendimiento 340 también convierte las métricas de rendimiento de cliente en un formato apropiado para almacenamiento en la DB de rendimiento histórico 345, y uso por el creador de red superpuesta 350 y el mapeador de profundidad 360.
En una realización, el creador de red superpuesta 350 también es responsable, con la asistencia del mapeador de profundidad 360, del proceso continuo de evaluación de métricas de rendimiento de cliente actuales e históricas (mantenidas en la DB de rendimiento histórico 345) y dinámicamente, para cada segmento de vídeo (i) reclasificar nodos cliente y (ii) optimizar trayectorias de encaminamiento generando y reconfigurando las redes superpuestas 100, incluyendo la red superpuesta troncal de datos virtuales (para retransmitir el segmento de vídeo entre nodos A, en y a través de los ASN) y las redes superpuestas de enjambre (para retransmitir el segmento de vídeo desde cada nodo A en un ASN, a ciertos otros nodos B:A, B y C en ese ASN). La topología de las redes superpuestas 100 se mantiene en la DB de red superpuesta 375, para uso por el creador de red superpuesta 350 y el mapeador de profundidad 360.
Con respecto a las métricas de rendimiento recibidas desde el dispositivo cliente recién añadido 200, el creador de red superpuesta 350 utiliza estas métricas para clasificar inicialmente el dispositivo cliente 200. En una realización, este proceso se usa también para reclasificar potencialmente nodos cliente para cada segmento de vídeo (no solamente cuando se unen al canal). Aunque los nodos cliente no se reclasifican normalmente de manera muy frecuente, un cliente puede experimentar una caída temporal en ancho de banda (por ejemplo, de un microondas doméstico u otra interferencia). También, a medida que se requieren más nodos A (porejemplo, para redundancia, o debido a que los nodos cliente dejan un canal), los nodos B:A pueden actualizarse a nodos A. Otros problemas detectados en un ASN, o a través de los ASN, pueden requerir también que ciertos nodos se reclasifiquen.
El creador de red superpuesta 350 asigna al dispositivo cliente 200 puestos entrantes y salientes (es decir, puertos de red) de modo que puede recibir fragmentos de segmentos de vídeo (mediante puestos entrantes) insertados desde otros nodos cliente, y puede retransmitir (insertar) estos fragmentos de segmentos de vídeo (mediante puestos salientes) a otros nodos cliente. Aunque la norma de WebRTC 224 soporta 256 puertos (puestos) entrantes y salientes, únicamente un único puesto entrante se asigna en una realización (para maximizar la calidad de contenido de vídeo que puede reproducirse en el dispositivo cliente 200) y se asigna un máximo de 8 puestos salientes (para maximizar el caudal a lo largo de las redes superpuestas 100 y soportar una amplia gama de dispositivos cliente 200 y conexiones de ancho de banda limitadas). Como se ha indicado anteriormente, se asignan
5
10
15
20
25
30
35
40
45
50
55
60
65
nodos A a 4 puestos salientes para retransmitir segmentos de vídeo a otros nodos A a través de los puntos de pares de ASN, y 4 puestos salientes para retransmitir segmentos de vídeo a otros A en su ASN. Como se explicará a continuación, no todos los puestos asignados se usarán necesariamente en cualquier punto en el tiempo dado.
El creador de red superpuesta 350 analiza el ancho de banda aguas abajo y aguas arriba del dispositivo cliente 200 para facilitar el proceso de clasificación. Como se ha indicado anteriormente, si el dispositivo cliente 200 se une mediante una conexión celular (3G, 4G o incluso LTE), se considera automáticamente que es poco fiable para retransmitir segmentos de vídeo, y se clasifica por lo tanto como un nodo C. En otras realizaciones, una clasificación automática de este tipo puede limitarse a ciertas conexiones celulares (por ejemplo, 3G), o eliminarse por completo.
En una realización, el creador de red superpuesta 350 emplea categorías de ancho de banda aguas abajo/aguas arriba típicas (en Mbps) para facilitar clasificación adicional, que incluye: (1) conexiones LAN (por ejemplo, 100/100), (2) conexiones de fibra (100/50), (3) conexiones de ADSL (100/20), conexiones de cable (100/10) y conexiones WiFi, que pueden variar enormemente). En esta realización, si el dispositivo cliente 200 no se considera ya un nodo C, y tiene un ancho de banda aguas arriba de al menos 50 Mbps, se categoriza inicialmente como un nodo A (o como un nodo B:A si el mapeador de profundidad 360 indica que no se requieren nodos A adicionales en su ASN). De otra manera, se categorizará como un nodo B.
Como se analizará a continuación, el creador de red superpuesta 350 analiza adicionalmente el ancho de banda aguas arriba del dispositivo cliente 200 (en una realización) para calcular el número de puestos salientes disponibles que puede utilizar antes de que determine el punto hasta que (si lo hubiera) debiera reconfigurar dinámicamente las redes superpuestas 100. También determina el punto hasta que el dispositivo cliente 200 puede recibir y/o realizar polidifusión a múltiples resoluciones.
En una realización, el ancho de banda aguas abajo completo de un nodo cliente se utiliza para su único puesto entrante, mientras que únicamente se utiliza 1/3 de su ancho de banda aguas arriba para retransmitir segmentos de vídeo entre sus puestos salientes. Su ancho de banda aguas arriba total no se utiliza, ya que la retransmisión de segmentos de vídeo puede interferir con TCP/IP y otras conexiones que está usando el dispositivo cliente 200 para otras aplicaciones.
El creador de red superpuesta 350 analiza el ancho de banda aguas abajo del dispositivo cliente 200 (incluso si se clasifica como un nodo C) para determinar el número de resoluciones que puede soportar mediante su único puesto entrante. Por ejemplo, si 1080p requiere una tasa de bits de 3 Mbps, y 720p requiere una tasa de bits de 1,5 Mbps y 480p requiere una tasa de bits de 500 Kbps, entonces el dispositivo cliente 200 requeriría un ancho de banda aguas abajo de al menos 5 Mbps para soportar las 3 resoluciones, al menos 4,5 Mbps para soportar 1080p y 720p, al menos 3 Mbps para soportar 1080p únicamente, al menos 2 Mbps para soportar 720p y 480p, al menos 1,5 Mbps para soportar 720p únicamente, y al menos 500 Kbps para soportar 480p únicamente. En una realización, las tasas de bits inferiores a 500 Kbps no se soportarán. En otras realizaciones, pueden soportarse resoluciones inferiores, y pueden emplearse otras técnicas (por ejemplo, mayor compresión, diferentes formatos de vídeo, etc.) para reducir los requisitos de ancho de banda.
Como se ha indicado anteriormente, en una realización, los nodos A, B:A y B pueden considerarse también nodos de polidifusión que pueden retransmitir múltiples resoluciones a otros nodos mediante uno o más de sus puestos salientes. En este sentido, el creador de red superpuesta 350 analiza el ancho de banda aguas arriba del dispositivo cliente 200 para determinar el número de resoluciones que puede retransmitir a otros nodos cliente.
Puesto que un nodo cliente puede utilizar únicamente el 1/3 de su ancho de banda aguas arriba en esta realización, el dispositivo cliente 200 requeriría un ancho de banda aguas arriba de al menos 15 Mbps (por puesto saliente) para realizar polidifusión de todas las 3 resoluciones, al menos 13,5 Mbps (por puesto saliente) para realizar polidifusión a 1080p y 720p, al menos 9 Mbps (por puesto saliente) para enviar 1080p únicamente, al menos 6 Mbps (por puesto saliente) para realizar polidifusión a 720p y 480p, al menos 4,5 Mbps (por puesto saliente) para retransmitir 720p únicamente, y al menos 1,5 Mbps (por puesto saliente) para retransmitir 480p únicamente.
El dispositivo cliente 200 no puede retransmitir a una resolución que no recibe. Además, las capacidades de polidifusión del dispositivo cliente 200 se consideran en conjunto con la capacidad de otros nodos cliente para recibir múltiples resoluciones, como se explica a continuación. Pero, como se ha indicado anteriormente, el dispositivo cliente 200 emplea implementaciones de envío por flujo continuo adaptativo 224 para solicitar versiones de resolución inferiores o superiores de segmentos de vídeo a medida que experimenta cambios significativos en su ancho de banda. Si recibe múltiples resoluciones diferentes de un segmento de vídeo, simplemente reproducirá la resolución más alta que haya recibido.
Suponiendo que el dispositivo cliente 200 no es un nodo C, el creador de red superpuesta 350 calcula el número de puestos salientes disponibles que puede utilizar analizando su ancho de banda aguas arriba, así como considerando el punto hasta el cual puede realizar polidifusión de múltiples resoluciones. Por ejemplo, si el dispositivo cliente 200 se clasifica como un nodo A con una conexión de LAN que tiene un ancho de banda aguas arriba de 100 Mbps, puede utilizar únicamente aproximadamente 6 puestos salientes para realizar polidifusión de segmentos de vídeo
5
10
15
20
25
30
35
40
45
50
55
60
65
tanto en su ASN como a través de los ASN. En esta realización, el creador de red superpuesta 350 asignaría 4 puestos para realizar polidifusión a otros nodos A a través de los ASN (dando prioridad a estos puestos inter-ASN), dejando 2 puestos restantes para realizar polidifusión a otros nodos A en su ASN. En otras realizaciones, estas asignaciones podrían por supuesto variar.
De manera similar, si el dispositivo cliente 200 se clasifica como un nodo B:A o B con una conexión de cable que tiene un ancho de banda aguas arriba de 10 Mbps, podría utilizar únicamente 1 puesto saliente para realizar polidifusión de resoluciones de 720p y 480p, o enviar únicamente a 1080p. En una realización, se proporciona prioridad a resoluciones de calidad superior (hasta el punto que los nodos puedan recibir esa resolución), y por lo tanto un puesto se asignaría para 1080p únicamente. En este punto también, estas asignaciones podrían variar.
Habiendo clasificado el dispositivo cliente 200, y determinado el número de puestos que pueden utilizarse (incluyendo realizar polidifusión a múltiples resoluciones), el creador de red superpuesta 350 a continuación determina el punto hasta el cual reconfigurará dinámicamente las redes superpuestas 100 para optimizar las trayectorias de encaminamiento. Si el dispositivo cliente 200 es un nodo A, entonces el creador de red superpuesta 350 obtendrá en primer lugar desde el mapeador de profundidad 360 los niveles de congestión para cada trayectoria inter-ASN entre nodos A (como se analiza en mayor detalle a continuación), y a continuación reconfigurará dinámicamente al menos parte de la red superpuesta troncal de datos virtuales para incorporar el dispositivo cliente 200.
Por ejemplo, dado un conjunto de trayectorias ponderadas (teniendo cada trayectoria una ponderación de "nivel de congestión"), el creador de red superpuesta 350 emplea técnicas de búsqueda de trayectoria normalizadas para determinar la trayectoria óptima para distribuir un segmento de vídeo entre los nodos A (análogo, por ejemplo, a encaminamiento de navegación de GPS). Obsérvese, sin embargo, que este proceso es ligeramente complicado por el uso de múltiples puestos de retransmisión - por ejemplo, 4 puestos salientes para nodos A que retransmiten a los nodos A en un ASN, y 4 puestos salientes para los nodos A que retransmiten a los nodos A a través de un punto de pares de ASN. Además, esto es únicamente una ligera variación del caso más sencillo en el que un nodo A tiene únicamente 1 puesto saliente. En otras palabras, el creador de red superpuesta 350 rastrea el número de puestos abiertos (sin uso) durante la generación o reconfiguración de la red superpuesta troncal de datos virtuales, y detiene la asignación de un nodo A particular como una fuente de retransmisión una vez que ya no tiene ningún puesto abierto sin uso.
Si el dispositivo cliente 200 es un nodo B:A o B, el creador de red superpuesta 350 reconfigura dinámicamente alguna o todas las redes superpuestas de enjambre intra-ASN en el ASN en el que reside el dispositivo cliente 200. Obsérvese que, si hay múltiples nodos A en ese ASN, sus rutas entre sí se determinarán como parte de la red superpuesta troncal de datos virtuales. En una realización, únicamente se utilizará un nodo A para crear una red superpuesta de enjambre (si hay disponibles suficientes puestos), aunque en otras realizaciones, los otros nodos pueden asignarse igualmente entre los múltiples nodos A, o distribuirse basándose en el ancho de banda aguas arriba relativo u otras métricas.
Con respecto a cualesquiera nodos A particulares, y restantes nodos B, B:A y C en un ASN, estos nodos se organizan en primer lugar basándose en su clasificación (es decir, B:A, a continuación B, a continuación C), y a continuación basándose en su ancho de banda relativo (es decir, número de puestos disponibles que pueden utilizarse, como se ha descrito anteriormente). Obsérvese que la red superpuesta de enjambre es una jerarquía en esta realización, dado que cada nodo tiene únicamente un único nodo alimentador. Pueden emplearse técnicas similares para enjambres de "malla" no jerárquicos en otras realizaciones.
En esta realización de enjambre jerárquico, el proceso comienza con el nodo A raíz, que tendrá un cierto número de puestos salientes que pueden utilizarse (por ejemplo, 2 puestos salientes). Estos puestos se encaminarán al siguiente nivel de jerarquía - por ejemplo, los 2 nodos B:A con el número más alto de puestos disponibles que pueden utilizarse. Una vez que se determinan estas trayectorias, los puestos salientes disponibles de estos nodos se encaminarán a los restantes nodos B:A con el número más alto de puestos disponibles. Este proceso continúa hacia abajo de la jerarquía (a través de los nodos B, y finalmente los nodos C) hasta que se hayan determinado todas las trayectorias.
Obsérvese que la longitud de una cadena debajo de cualquier nodo cliente (por ejemplo, 100 nodos cliente, cada uno con un único puesto saliente) es relativamente poco preocupante dada la velocidad relativamente alta (muy por debajo de 1 ms) de un retransmisor entre nodos en un ASN. Dado un segmento de vídeo de 1 segundo, se adaptará aún cadenas de cientos de nodos (aunque sería raro, dado que muchos nodos en un ASN es probable que soporten múltiples puestos salientes). En el caso de que todos los nodos no pudieran incluirse en un enjambre (por ejemplo, si los nodos C y nodos B con 0 puestos disponibles no se contabilizaran), entonces podría haber una necesidad de nodos adicionales con puestos abiertos en ese ASN, que podrían asignarse a medida que se vuelvan disponibles. Mientras tanto, tales nodos se dirigirían para solicitar segmentos de vídeo desde el servidor de contenido de POI 380.
Antes de volver al mapeador de profundidad 360, que predice y cuantifica los niveles de congestión a través de
5
10
15
20
25
30
35
40
45
50
55
60
65
puntos de pares de ASN (por ejemplo, durante el siguiente minuto), es útil entender las limitaciones de protocolos de encaminamiento de BGP para apreciar el significado de congestión de punto de pares de ASN. Los encaminadores de BGP determinan congestión en "tiempo de encaminamiento" y no tienen capacidades predictivas. Tienen conocimiento únicamente de sus propios encaminadores, y la latencia "1 salto de distancia" a través de un punto de pares de ASN. Hay desconocimiento del número de saltos o latencia a cualquier destino final, que pueden ser múltiples saltos de distancia a través de múltiples puntos de pares de ASN. Dada una elección de múltiples puntos de pares de ASN, eligen esencialmente el que tiene más ancho de banda disponible en el momento (es decir, el que tiene un puesto abierto y la latencia más baja a 1 salto de distancia).
En contraste, el mapeador de profundidad 360 aprovecha su conocimiento de la arquitectura subyacente de la Internet. En una realización, el mapeador de profundidad 360 mantiene un mapa de interconexión de ASN de la Internet (incluyendo los ASN y sus diversas interconexiones de punto de pares), como se ilustra de manera aproximada en la Figura 1. Este mapa no cambia de manera frecuente, aunque se monitoriza, en una realización, cada 5 minutos para capturar tales cambios infrecuentes.
Las redes superpuestas 100 construidas en la parte superior de estos ASN se analizan, sin embargo, de manera frecuente (por ejemplo, mediante monitorización del lado del cliente como se ha analizado anteriormente), y se reconfigura potencialmente cada segmento de vídeo (por ejemplo, cada segundo en una realización) por el servidor de difusión virtual 300. En la práctica, sin embargo, las redes superpuestas 100 se modifican realmente únicamente cuando está justificado - por ejemplo, no únicamente cuando se unen nuevos nodos o dejan el canal, sino también cuando se detectan suficientes problemas (basándose en información actual e histórica mantenida en la DB de rendimiento histórico 345).
Por ejemplo, se emplean múltiples "umbrales de congestión" internos en una realización. Tras la detección inicial de un umbral de congestión relativamente bajo específico a un dispositivo cliente 200 particular o en un ASN, el creador de red superpuesta 350 simplemente "marca" el dispositivo de cliente 200 o aSn, y espera para observar si el problema vuelve a ocurrir (por ejemplo, en el siguiente segmento de vídeo). En caso afirmativo, puede reducir la resolución (y por lo tanto la tasa de bits) del siguiente segmento de vídeo retransmitido a ese nodo cliente (o todos los nodos cliente en ese ASN "problemático"). De manera eventual, si el problema empeora (por ejemplo, superando un umbral de congestión superior), a continuación una porción de las redes superpuestas 100 (porejemplo, un rango de subconjuntos IP en un ASN) puede reconfigurarse dinámicamente. Finalmente, un ASN entero, o quizás la misma red superpuesta troncal de datos virtuales, puede requerir reconfiguración dinámica.
En cualquier caso, el objetivo de estos umbrales de congestión es identificar y corregir problemas de manera proactiva, antes de que se degeneren en problemas más significativos que provoquen que se pierdan segmentos de vídeo, o incluso provocar que los nodos cliente hagan uso de obtener un segmento de vídeo desde la localización de repliegue del servidor de contenido de POI 380.
Manteniendo un conocimiento del mapa de interconexión de ASN de la Internet, y la localización de ASN de los nodos en las redes superpuestas 100, y monitorizando en tiempo real el rendimiento actual e histórico de estos nodos, el mapeador de profundidad 360 minimiza la probabilidad de que cualquier nodo cliente retransmitirá innecesariamente un segmento de vídeo a un nodo cliente distante (por ejemplo, a muchos saltos de distancia a través de múltiples puntos de pares de ASN). Por ejemplo, como un asunto inicial en una realización, la red superpuesta troncal de datos virtuales tenderá a encaminar segmentos de vídeo (cada vez que sea posible) desde el nodo A a otro nodo A en el mismo ASN o en un ASN cercano a través de un único punto de pares de ASN.
Sin embargo, no todos los saltos únicos se crean de manera igual. Por ejemplo, el mapeador de profundidad 360 puede "aprender" a través del tiempo (basándose en métricas de rendimiento de cliente mantenidas en la DB de rendimiento histórico 345) que un punto de pares entre el "ASN 1" y "ASN 2" se vuelve congestionado, y puede "predecir" que una ruta de 2 saltos desde el "ASN 1" al "ASN 3" al "ASN 2" es realmente más rápida que la ruta de 1 salto actual (o será más rápida en el futuro muy cercano basándose en tendencias recientes e históricas). Cuantificando la congestión de punto de pares basándose en rendimiento actual e histórico de nodos A a través de puntos de pares, el mapeador de profundidad 360 puede facilitar la reconfiguración dinámica de la topología de la red superpuesta troncal de datos virtuales - potencialmente para cada segmento de vídeo, o al menos cuando la congestión de punto de pares necesita tales cambios (basándose en umbrales internos).
En una realización, el mapeador de profundidad 360 cuantifica congestión con respecto a cada par de nodos A (si residen en el mismo ASN o en diferentes ASN), empleando una escala de 1 a 10, siendo 1 el nivel más inferior de la congestión a corto plazo prevista y siendo 10 el más alto. Como se ha indicado anteriormente, el creador de red superpuesta 350 utiliza esta "puntuación" de nivel de congestión para comparar diferentes rutas potenciales entre nodos A y determinar la ruta más eficaz (es decir, la ruta de "salto ponderado" más baja). Como resultado, los nodos A que están más "distantes" (en saltos ponderados) desde el servidor de contenido de POI 380 minimizarán la cantidad de tiempo necesario para que un segmento de vídeo atraviese la red superpuesta troncal de datos virtuales a tales nodos A desde el servidor de contenido de POI 380.
En una realización, para cada par de nodos A, el mapeador de profundidad 360 genera una puntuación de nivel de
5
10
15
20
25
30
35
40
45
50
55
60
65
congestión previsto para cada ruta desde un nodo A al otro, y a continuación selecciona la puntuación de nivel de congestión más baja para que se aplique a ese par de nodos A, que volverá a la red superpuesta 350. En otras realizaciones, el mapeador de profundidad 360 genera una función diferente de estas puntuaciones de nivel de congestión previstas (para cada ruta desde un nodo A al otro), tal como un promedio, una mediana, etc.).
El mapeador de profundidad 360 es, en una realización, un motor de aprendizaje de profundidad que analiza continuamente las métricas de rendimiento mantenidas en la DB de rendimiento histórico 345, y predice (por ejemplo, un minuto en el futuro) el nivel de congestión a través de los puntos de pares de ASN. Debería observarse que, como cualquier motor de aprendizaje de profundidad, el mapeador de profundidad 360 emplea múltiples transformaciones no lineales para modelar el comportamiento de puntos de pares de ASN, con respecto al tráfico entre nodos A a través de estos puntos de pares.
Como se ha indicado anteriormente, no puede monitorizar de manera efectiva el volumen del tráfico de la Internet que cruza estos puntos de pares, sino únicamente el efecto a través del tiempo de que tal tráfico tenga en los saltos inter-ASN entre nodos A a través de estos puntos de pares. A medida que se obtienen más métricas de rendimiento, la que mejor puede predecir el tiempo requerido para tales saltos inter-ASN, que se cuantifica a continuación como un nivel de congestión relativo (por ejemplo, en comparación con saltos intra-ASN que normalmente están bastante menos congestionados, aunque también se monitorizan en esta realización).
Debido a que el nivel de congestión de puntos de pares es demasiado dinámico, tales predicciones pueden ser únicamente precisas durante un breve periodo de tiempo. Pero, dado que este análisis se realiza en una base continua, y puede cambiar para el siguiente segmento de vídeo de 1 segundo, no es crítico que la predicción sea precisa durante un largo periodo de tiempo.
En una realización, el mapeador de profundidad 360 cuantifica inicialmente puntos de pares de ASN basándose en información muy basta (es decir, antes de que se obtenga una gran cantidad de métricas de rendimiento de cliente). Por ejemplo, si un aSn tiene 1000 puntos de pares, puede suponerse que es una parte principal que es probablemente mucho más rápida que otro ASN con 6 puntos de pares. A medida que se obtienen más métricas de rendimiento de cliente, estos niveles de congestión de punto de pares de ASN se harán más precisos. En otra realización, se despliegan múltiples "nodos de aprendizaje" para "iniciar el salto" a un nuevo canal. Estos nodos de aprendizaje son nodos de envío únicamente que no visualizan el vídeo, sino que se despliegan únicamente para proporcionar información de rendimiento de cliente rápidamente, de modo que el mapeador de profundidad 360 puede comenzar a realizar predicciones más precisas antes de lo que sería el caso de otra manera.
Además, en una realización, el mapeador de profundidad 360 también considera congestión de intra-ASN, ya que esto puede sugerir la necesidad, por ejemplo, para nodos A adicionales en un ASN, y por lo tanto la creación de redes superpuestas de enjambre adicionales. Por ejemplo, si muchos nodos cliente en un ASN están tomando más tiempo para obtener segmentos de vídeo a través del tiempo, el mapeador de profundidad 360 marca el ASN para indicar que se requieren nodos A adicionales, y el creador de red superpuesta 350 puede "promocionar" uno o más nodos B:A a nodos A, dando como resultado una reconfiguración parcial de la red superpuesta troncal de datos virtuales, y requiriendo finalmente nuevas redes superpuestas de enjambre en el aSn. En otra realización, el mapeador de profundidad 360 aplica técnicas de aprendizaje de profundidad en cada ASN, y ayuda al creador de red superpuesta 350 al generar redes superpuestas de enjambre intra-ASN.
Por lo tanto, el creador de red superpuesta 350 y el mapeador de profundidad 360 funcionan juntos para establecer rutas entre nodos cliente (mediante redes superpuestas 100) que están basadas en la arquitectura subyacente de la Internet (mapa de interconexión de ASN) y la localización de ASN de nodos cliente superpuestos en la parte superior de esa arquitectura, para minimizar retransmisores de segmentos de vídeo a través de rutas distantes innecesarias (es decir, a través de múltiples puntos de pares de ASN). Además, el creador de red superpuesta 350 y el mapeador de profundidad 360 también funcionan juntos para analizar continuamente métricas de rendimiento de cliente en tiempo real obtenidas por dispositivos cliente 200, y para reconfigurar dinámicamente las redes superpuestas 100 en el caso de que tales métricas revelen problemas significativos (a menudo debido a congestión en puntos de pares de ASN). Como resultado, la volatilidad de la QoS de Internet puede monitorizarse, y los efectos en los nodos cliente de congestión (particularmente en puntos de pares de ASN) pueden minimizarse reencaminando dinámicamente alrededor de tales problemas "antes de que tengan lugar" (basándose en los niveles de congestión previstos generados por el mapeador de profundidad 360).
En una realización, el servidor de difusión virtual 300 incluye un motor de búsqueda de extractor de pantalla de presentación 390 para el fin de identificar eventos de vídeo de tendencia ("pantallas de presentación"), y posibilitar que los usuarios busquen entre el dominio de tales eventos y enviar por flujo continuo inmediatamente un resultado de pantalla de presentación deseado como un canal de vídeo desde el servidor de contenido de POI 380 (donde tal canal no estaba disponible de otra manera desde el servidor de difusión virtual 300.
En una realización, el extractor de pantalla de presentación 390 recopila datos de manera continua desde múltiples nuevas fuentes - por ejemplo, mediante las API a Twitter, Fuentes RSS, Reddit, y decenas de miles de revistas en línea. De media, se revelan miles de distintos "eventos actuales" en tales fuentes cada hora. El extractor de pantalla
5
10
15
20
25
30
35
40
45
50
55
60
65
de presentación 390 emplea métodos automatizados novedosos para identificar tales eventos de tendencia (pantallas de presentación) y localizar y extraer vídeos relacionados que pueden obtenerse y enviarse por flujo continuo mediante el servidor de contenido de POI 380.
El extractor de pantalla de presentación 390 identifica "desviaciones de la norma" para detectar pantallas de presentación. Por ejemplo, se desarrolla una línea de base (sin requerir datos normalizados) empleando, por ejemplo, un algoritmo de comparación de Levenshtein normalizado entre el dominio de nuevas fuentes. De media, no más de unas pocas fuentes analizarán el mismo "tema" (es decir, una recopilación de palabras clave) en un breve periodo de tiempo, a menos y hasta que un tema particular sea de hecho de tendencia. En ese punto (por ejemplo, cuando 15 o más fuentes analizan el mismo tema en un breve periodo de tiempo), ese tema se identifica como una desviación, y por lo tanto una pantalla de presentación.
El extractor de pantalla de presentación 390 a continuación extrae las palabras clave "más importantes" desde estas fuentes (por ejemplo, 40 palabras clave en una realización) - en una realización, empleando técnicas de red neurales normalizadas para aprender y predecir las palabras clave distintas desde los artículos "relacionados con pantallas de presentación". Estas palabras clave se categorizan a continuación (por ejemplo, como noticias, deportes, etc.) y se clasifican por frecuencia.
El extractor de pantalla de presentación 390 a continuación usa estas palabras clave para buscar medios sociales para vídeos relacionados con cada pantalla de presentación, e indexa el texto relacionado asociado con estos canales de vídeo de pantalla de presentación potencial. Los usuarios pueden a continuación buscar en ese índice, o simplemente explorar las categorías de eventos de vídeo de pantalla de presentación. Tras seleccionar un resultado (ya se busque o explore), el usuario puede enviar por flujo continuo inmediatamente el vídeo deseado. En una realización, el usuario simplemente se enlaza a la fuente actual del vídeo, mientras que en otra realización, el vídeo se obtiene mediante el servidor de difusión virtual 300, y se envía por flujo continuo desde el servidor de contenido de POI 380 (útil, por ejemplo, si grandes números de usuarios concurrentes solicitan el mismo canal de vídeo de pantalla de presentación).
Proceso de envío de vídeo por flujo continuo dinámico
Habiendo analizado componentes clave del lado del cliente y del lado del servidor del sistema de difusión virtual de la presente invención, el diagrama de flujo 400 de la Figura 4 ilustra cómo estos componentes interactúan dinámicamente. En otras palabras, el diagrama de flujo 400 ilustra una realización de un proceso de envío por flujo continuo dinámico de la presente invención implementada por tales componentes. Debería observarse que, la mayoría de este proceso se acciona por eventos y es no lineal, el diagrama de flujo 400 ilustra etapas desde la perspectiva de la interacción entre funcionalidad del lado del cliente y del lado del servidor.
La etapa 401 ilustra el proceso realizado por el cargador 280 (y anteriormente descrito), en el que un evento de vídeo se captura por un nodo cliente (por ejemplo, una cámara de teléfono inteligente 219 en el dispositivo cliente 200) o se genera digitalmente u obtiene desde una fuente externa. En cualquier caso, el cliente (por ejemplo, el dispositivo cliente 200) a continuación envía por flujo continuo segmentos de vídeo de ese evento de vídeo (ya se capture en directo o esté pre-grabado) al servidor de difusión virtual 300.
Si se obtienen eventos de vídeo desde clientes o desde una CDN más tradicional (y ya estén pre-grabados o enviados por flujo continuo en directo), el servidor de difusión virtual 300, en la etapa 410, prepara cada canal de vídeo para enviar por flujo continuo en directo desde el servidor de contenido de POI 380, como se ha analizado anteriormente. En este punto, en una realización, se genera una página web de canal y se encuentra eventualmente por un nodo cliente potencial. Cuando un usuario de un dispositivo cliente 200 hace clic en un canal deseado, se envía una solicitud de unión al servidor de señalización 330, junto con las capacidades de cliente (tal como el tipo de sistema operativo, explorador, conexión, etc.). Como alternativa, un usuario de dispositivo cliente 200 puede encontrar un evento de vídeo de pantalla de presentación de tendencia (como se ha analizado anteriormente) y seleccionar ese evento de vídeo (en la etapa 410) para enviar por flujo continuo como un canal de vídeo desde el servidor de contenido de POI 380.
En la etapa 412, el servidor de señalización 330 verifica conectividad de cliente al canal (por ejemplo, empleando el protocolo STUN 322 para identificar la dirección de IP pública del cliente), y a continuación establece una conexión de conector web 326 a través de cualquier cortafuegos de NAT que pueda estar presente en el cliente, y más tarde proporciona esa dirección de IP pública a otros nodos cliente para retransmitir un segmento de vídeo a ese cliente. El servidor de señalización 330 a continuación devuelve el control a través del creador de red superpuesta 350, que añade el cliente (aún no clasificado) como un nodo en las redes superpuestas 100, desde las cuales los segmentos de vídeo iniciales se insertarán al cliente (en la etapa 414) de modo que el usuario puede empezar inmediatamente a observar el canal de vídeo, en la etapa 415.
El servidor de señalización 330 a continuación, en la etapa 416, clasifica el dispositivo cliente 200 como un nodo A, B:A, B o C, y, en la etapa 430, emplea tanto el creador de red superpuesta 350 como el mapeador de profundidad 360 para reconfigurar dinámicamente las redes superpuestas 100 inter-ASN (parte troncal de datos virtual) e intra-
5
10
15
20
25
30
35
40
45
50
55
ASN (de enjambre) para incorporar el dispositivo cliente 200 en la topología de red. El servidor de señalización 330 a continuación proporciona la información de ruta relevante a otros nodos cliente para empezar a retransmitir segmentos de vídeo al dispositivo cliente 200.
El servidor de contenido de POI 380, en la etapa 435, a continuación responde a las solicitudes de HTTP desde nodos cercanos (normalmente nodos A) para enviar por flujo continuo segmentos de vídeo a aquellos nodos como el punto de origen del canal de vídeo a lo largo de las redes superpuestas 100 actuales (reconfiguradas), retransmitiéndose cada segmento de vídeo de nodo a nodo hasta que se retransmita y visualice por el dispositivo cliente 200.
Cuando el dispositivo cliente 200 está recibiendo fragmentos y compilándolos, en la etapa 450, para ver cada segmento de vídeo del canal (y potencialmente también retransmitiendo fragmentos a otros nodos cliente designados, en la etapa 440), también está monitorizando su rendimiento en la etapa 425, como se ha analizado anteriormente con respecto al monitor de rendimiento 240, y proporciona métricas de rendimiento de cliente al servidor de señalización 330. Además, a medida que se solicita cada segmento de vídeo, estas solicitudes se interceptan en la etapa 455 (por código Javascript cliente en el receptor 250, en una realización) puesto que los segmentos de vídeo se están insertando al dispositivo cliente 200 a lo largo de las redes superpuestas 100, como se ha analizado anteriormente. La flecha de la etapa 455 a la etapa 425 simplemente indica que el proceso de monitorización en la etapa 425 es uno continuo, concurrente con la recepción, visualización y retransmisión de fragmentos de segmentos de vídeo.
Como se ha indicado también anteriormente, el dispositivo cliente 200 inicia periódicamente solicitudes de HTTP para ficheros de manifiesto (por ejemplo, que contienen las localizaciones de los siguientes 8 segmentos de vídeo) desde el servidor de contenido de pOi 380, incluso aunque se estén insertando segmentos de vídeo al dispositivo cliente 200 desde otros nodos cliente. De manera ocasional, si un segmento de vídeo no llega a tiempo, el dispositivo cliente 200 solicitará el segmento de vídeo directamente desde el servidor de contenido de POI 380 como una localización de repliegue. Además, en ocasiones, de acuerdo con las normas de envío por flujo continuo adaptativo 224, el dispositivo cliente 200 puede entrar en contacto también con el servidor de contenido de POI 380 para solicitar una tasa de bits modificada (por ejemplo, tras detectar un cambio en sus niveles de rendimiento) para segmentos de vídeo posteriores. Como se ha indicado anteriormente, sin embargo, el receptor 250 puede detectar bien tal necesidad antes, y entrar en contacto con el servidor de difusión virtual 300 para efectuar tales cambios mediante las redes superpuestas 100, dirigir un nodo cliente de alimentación para insertar segmentos de vídeo de resolución inferior o superior al dispositivo cliente 200 automáticamente (es decir, no en respuesta a su solicitud).
En la etapa 452, el servidor de contenido de POI 380 responde a tales solicitudes de HTTP, y entrega los ficheros de manifiesto solicitados y segmentos de vídeo de repliegue al dispositivo cliente 200. Como se ha indicado anteriormente, los cambios en tasas de bits se tratan mediante las redes superpuestas 100 (y en la etapa 430), dando como resultado segmentos de vídeo de resolución inferior o superior que se insertan al dispositivo cliente 200.
La etapa 454 abarca el proceso continuo (realizado para cada segmento de vídeo, en una realización, y descrito en detalle anteriormente) realizado por el rastreador de rendimiento 340, el creador de red superpuesta 350 y el mapeador de profundidad 360. En esta etapa 454, la información de rendimiento de cliente se actualiza de manera continua y, si es necesario, en la etapa 430 (como se indica por la flecha de la etapa 454 a la etapa 430), las redes superpuestas 100 se reconfiguran dinámicamente, y se proporciona información de nuevo encaminamiento a nodos retransmisores relevantes mediante el servidor de señalización 330.
Finalmente, en la etapa 460, el extractor de pantalla de presentación 390 identifica de manera continua eventos de vídeo de pantalla de presentación de tendencia, que los usuarios de los dispositivos cliente 200 pueden explorar o buscar, y a continuación enviar por flujo continuo para visualización inmediata como se ha analizado anteriormente.
La presente invención se ha descrito en el presente documento con referencia a realizaciones específicas como se ilustra en los dibujos adjuntos. Debería entenderse que, a la luz de la presente divulgación, pueden proporcionarse e implementarse realizaciones adicionales de los conceptos desvelados en el presente documento dentro del alcance de la presente invención por los expertos en la materia.

Claims (19)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    REIVINDICACIONES
    1. Un servidor de difusión virtual (300) adaptado para encaminar simultáneamente cada uno de una pluralidad de segmentos de contenido digital a una pluralidad de nodos cliente (200) de una red subyacente (110) para reproducción concurrente del segmento por la pluralidad de nodos cliente (200), comprendiendo el servidor de difusión virtual (300):
    a) una base de datos de red superpuesta (375) adaptada para almacenar una topología de red que representa un estado actual de una red superpuesta (100) creada en la parte superior de la red subyacente (110), en donde la topología de red de la red superpuesta (100) incluye:
    (i) cada uno de la pluralidad de nodos cliente (200), siendo cada nodo cliente un nodo tanto de la red superpuesta (100) como de la red subyacente (110), y siendo cada nodo cliente un nodo cliente de destino adaptado para recibir el segmento para la reproducción concurrente del segmento por la pluralidad de nodos cliente (200), y
    (ii) un conjunto de trayectorias de encaminamiento que cada segmento atraviesa a medida que se retransmite entre la pluralidad de nodos cliente (200) para facilitar la reproducción concurrente del segmento por todos los nodos cliente de destino, en donde (A) un subconjunto de los nodos cliente son nodos cliente de origen, además de ser nodos cliente de destino, adaptados para retransmitir el segmento a uno o más de los nodos cliente de destino, y (B) cada trayectoria de encaminamiento define un par de nodos cliente de origen y de destino; y
    b) un rastreador de rendimiento (340) adaptado para monitorizar métricas de tráfico de red entre la pluralidad de nodos cliente (200) a lo largo de la red superpuesta (100);
    en donde el servidor de difusión virtual (300) está caracterizado por que comprende adicionalmente:
    c) un motor de aprendizaje de profundidad (360) adaptado para
    (i) mantener
    (A) un mapa de interconexión de número de sistema autónomo, ASN, de la red subyacente (110), que incluye una pluralidad de ASN (110a -110j) interconectados por una pluralidad de puntos de pares de ASN (120), y
    (B) una localización de ASN de cada nodo cliente (200), en donde la localización de ASN identifica el ASN particular (110a - 110j) en el que está localizado ese nodo cliente (200),
    y
    (ii) predecir de manera continua y cuantificar niveles de congestión en los puntos de pares de ASN (120), basándose en un análisis de las métricas, el mapa de interconexión de ASN y la localización de ASN de cada nodo cliente (200), en donde los niveles de congestión previstos cambian a medida que sube y baja el tráfico de red a través de los puntos de pares de ASN (120);
    y
    d) un creador de red superpuesta adaptado para reconfigurar dinámicamente la topología de red de la red superpuesta (100), basándose al menos en parte en cambios en los niveles de congestión previstos cuantificados, modificando el conjunto de trayectorias de encaminamiento.
  2. 2. El servidor de difusión virtual (300) de la reivindicación 1, en el que cada nodo cliente está categorizado en una de una pluralidad de clasificaciones basándose en esa capacidad del nodo cliente para retransmitir los segmentos de contenido digital a otros nodos cliente, incluyendo la pluralidad de clasificaciones (a) una primera clasificación de nodos cliente adaptados para recibir segmentos desde, y retransmitir segmentos a, otros nodos cliente a lo largo de la red superpuesta (100) a través de los ASN (110a - 110j), (b) una segunda clasificación de nodos cliente adaptados para recibir segmentos desde, y retransmitir segmentos a, otros nodos cliente localizados únicamente en el mismo ASN (110a - 110j) y (c) una tercera clasificación de nodos cliente adaptados para recibir segmentos desde, pero no retransmitir segmentos a, otros nodos cliente.
  3. 3. El servidor de difusión virtual (300) de la reivindicación 1, en el que la red subyacente (110) es la Internet y los segmentos de contenido digital son segmentos ordenados de contenido de vídeo enviados por flujo continuo simultáneamente a la pluralidad de nodos cliente (200).
  4. 4. El servidor de difusión virtual (300) de la reivindicación 3, en el que un primer nodo cliente retransmite una pluralidad de diferentes versiones de contenido de vídeo a un segundo nodo cliente, teniendo cada versión una tasa de bits o una resolución diferentes.
  5. 5. El servidor de difusión virtual (300) de la reivindicación 1, en el que el creador de red superpuesta (350)
    5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    reconfigura dinámicamente la topología de red de la red superpuesta (100) cuando los niveles de congestión previstos cuantificados cumplen uno o más umbrales de congestión predefinidos.
  6. 6. Un método adaptado para encaminar simultáneamente cada uno de una pluralidad de segmentos de contenido digital a una pluralidad de nodos cliente (200) de una red subyacente (110) para la reproducción concurrente de ese segmento por la pluralidad de nodos cliente (200), comprendiendo el método las siguientes etapas:
    (a) almacenar una topología de red que representa un estado actual de una red superpuesta (100) creada en la parte superior de la red subyacente (110), en donde la topología de red de la red superpuesta (100) incluye:
    (i) cada uno de la pluralidad de nodos cliente (200), siendo cada nodo cliente un nodo tanto de la red superpuesta (100) como de la red subyacente (110), y siendo cada nodo cliente un nodo cliente de destino adaptado para recibir cada segmento para reproducción concurrente de ese segmento por la pluralidad de nodos cliente (200), y
    (ii) un conjunto de trayectorias de encaminamiento que cada segmento atraviesa a medida que se retransmite entre la pluralidad de nodos cliente (200) para facilitar la reproducción concurrente de ese segmento por todos los nodos cliente de destino, en donde (A) un subconjunto de los nodos cliente son nodos cliente de origen, además de ser nodos cliente de destino, adaptados para retransmitir cada segmento a uno o más de los nodos cliente de destino, y (B) cada trayectoria de encaminamiento define un par de nodos cliente de origen y de destino;
    y
    (b) monitorizar métricas de tráfico de red entre la pluralidad de nodos cliente (200) a lo largo de la red superpuesta (100);
    en donde el método está caracterizado por que comprende adicionalmente las siguientes etapas:
    (c) mantener:
    (i) un mapa de interconexión de ASN de la red subyacente (110), que incluye una pluralidad de ASN (110a - 110j) interconectados por una pluralidad de puntos de pares de ASN (120), y
    (ii) una localización de ASN de cada nodo cliente (200), en donde la localización de ASN identifica el ASN particular (110a - 110j) en el que está localizado ese nodo cliente (200);
    (d) predecir de manera continua y cuantificar niveles de congestión en los puntos de pares de ASN (120), basándose en un análisis de las métricas, el mapa de interconexión de ASN y la localización de ASN de cada nodo cliente (200), en donde los niveles de congestión previstos cambian a medida que sube y baja el tráfico de red a través de los puntos de pares de ASN (120);
    y
    (e) reconfigurar dinámicamente la topología de red de la red superpuesta (100), basándose al menos en parte en cambios en los niveles de congestión previstos cuantificados, modificando el conjunto de trayectorias de encaminamiento.
  7. 7. El método de la reivindicación 6, que comprende adicionalmente la etapa de categorizar cada nodo cliente en una de una pluralidad de clasificaciones basándose en esa capacidad del nodo cliente para retransmitir los segmentos de contenido digital a otros nodos cliente, incluyendo la pluralidad de clasificaciones (a) una primera clasificación de nodos cliente adaptados para recibir segmentos desde, y retransmitir segmentos a, otros nodos cliente a lo largo de la red superpuesta (100) a través de los ASN (110a - 110j), (b) una segunda clasificación de nodos cliente adaptados para recibir segmentos desde, y retransmitir segmentos a, otros nodos cliente localizados únicamente en el mismo ASN (110a - 110j) y (c) una tercera clasificación de nodos cliente adaptados para recibir segmentos desde, pero no retransmitir segmentos a, otros nodos cliente.
  8. 8. El método de la reivindicación 6, en el que la red subyacente (110) es la Internet y los segmentos de contenido digital son segmentos ordenados de contenido de vídeo enviado por flujo continuo simultáneamente a la pluralidad de nodos cliente (200).
  9. 9. El método de la reivindicación 8, en el que un primer nodo cliente retransmite una pluralidad de diferentes versiones de contenido de vídeo a un segundo nodo cliente, teniendo cada versión una tasa de bits o una resolución diferentes.
  10. 10. El método de la reivindicación 6, en el que la etapa de reconfigurar dinámicamente la topología de red de la red superpuesta (100) se realiza cuando los niveles de congestión previstos cuantificados cumplen uno o más umbrales de congestión predefinidos.
  11. 11. Un nodo cliente que es uno de una pluralidad de nodos cliente (200) de una red subyacente (110), la pluralidad de nodos cliente (200) adaptados para reproducción concurrente de cada uno de una pluralidad de segmentos de
    5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    contenido digital por la pluralidad de nodos cliente (200), comprendiendo el nodo cliente:
    (a) un receptor (250) adaptado para recibir cada segmento a lo largo de una red superpuesta (100) creada en la parte superior de la red subyacente (110);
    (b) un reproductor de contenido (232) adaptado para reproducción de cada segmento simultáneamente con reproducción de ese segmento por cada uno de la pluralidad de nodos cliente (200); y
    (c) un monitor de rendimiento (240) adaptado para generar métricas de tráfico de red entre la pluralidad de nodos cliente (200) a lo largo de la red superpuesta (100);
    en donde el nodo cliente está caracterizado por que comprende adicionalmente:
    (d) un retransmisor (260) adaptado para recibir información de encaminamiento que designa uno o más nodos cliente de destino a los que el nodo cliente retransmitirá posteriormente segmentos recibidos, y adaptado para retransmitir los segmentos recibidos posteriormente al conjunto de nodos cliente destino designados, en el que:
    (i) el conjunto de nodos cliente destino designados se genera basándose dinámicamente en niveles de congestión previstos en puntos de pares de ASN (120), que interconectan una pluralidad de ASN (110a - 110j), y
    (ii) los niveles de congestión previstos, que cambian a medida que sube y baja el tráfico de red a través de los puntos de pares de ASN (120), se determinan en parte basándose en una localización de ASN del nodo cliente que identifica el ASN particular (110a - 110j) en el que está localizado el nodo cliente.
  12. 12. El nodo cliente de la reivindicación 11, en el que el conjunto de nodos cliente destino designados se determina en parte categorizando el nodo cliente en una de una pluralidad de clasificaciones basándose en la capacidad del nodo cliente para retransmitir los segmentos de contenido digital a otros nodos cliente, incluyendo la pluralidad de clasificaciones (a) una primera clasificación de nodos cliente adaptados para recibir segmentos desde, y retransmitir segmentos a, otros nodos cliente a lo largo de la red superpuesta (100) a través de los ASN (110a - 110j), (b) una segunda clasificación de nodos cliente adaptados para recibir segmentos desde, y retransmitir segmentos a, otros nodos cliente localizados únicamente en el mismo ASN (110a - 110j) y (c) una tercera clasificación de nodos cliente adaptados para recibir segmentos desde, pero no retransmitir segmentos a, otros nodos cliente.
  13. 13. El nodo cliente de la reivindicación 11, en el que la red subyacente (110) es la Internet y los segmentos de contenido digital son segmentos ordenados de contenido de vídeo enviado por flujo continuo simultáneamente a la pluralidad de nodos cliente (200).
  14. 14. El nodo cliente de la reivindicación 13, en el que el nodo cliente retransmite una pluralidad de diferentes versiones de contenido de vídeo a otro de la pluralidad de nodos cliente (200), teniendo cada versión una tasa de bits o una resolución diferentes.
  15. 15. El nodo cliente de la reivindicación 11, en el que el conjunto de nodos cliente destino designados se modifica dinámicamente cuando los niveles de congestión previstos cumplen uno o más umbrales de congestión predefinidos.
  16. 16. Un método, realizado por un nodo cliente que es uno de una pluralidad de nodos cliente (200) de una red subyacente (110), adaptado para la reproducción concurrente de cada uno de una pluralidad de segmentos de contenido digital por la pluralidad de nodos cliente (200), comprendiendo el método las siguientes etapas:
    (a) recibir cada segmento a lo largo de una red superpuesta (100) creada en la parte superior de la red subyacente (110);
    (b) reproducir cada segmento simultáneamente con la reproducción de ese segmento por cada uno de la pluralidad de nodos cliente (200); y
    (c) generar métricas de tráfico de red entre la pluralidad de nodos cliente (200) a lo largo de la red superpuesta (100);
    en donde el método está caracterizado por que comprende adicionalmente las siguientes etapas:
    (d) recibir información de encaminamiento que designa un conjunto de uno o más nodos cliente de destino a los que el nodo cliente retransmitirá posteriormente segmentos recibidos; y
    (e) retransmitir los segmentos recibidos posteriormente al conjunto de nodos cliente destino designados, en donde:
    (i) el conjunto de nodos cliente destino designados se genera basándose dinámicamente en niveles de congestión previstos en puntos de pares de ASN (120), que interconectan una pluralidad de ASN (110a - 110j), y
    (ii) los niveles de congestión previstos, que cambian a medida que sube y baja el tráfico de red a través de los puntos de pares de ASN (120), se determinan en parte basándose en una localización de ASN del nodo cliente que identifica el ASN particular (110a - 110j) en el que está localizado el nodo cliente.
  17. 17. El método de la reivindicación 16, en el que el conjunto de nodos cliente destino designados se determina en parte categorizando el nodo cliente en una de una pluralidad de clasificaciones basándose en la capacidad del nodo cliente para retransmitir los segmentos de contenido digital a otros nodos cliente, incluyendo la pluralidad de clasificaciones (a) una primera clasificación de nodos cliente adaptados para recibir segmentos desde, y retransmitir 5 segmentos a, otros nodos cliente a lo largo de la red superpuesta (100) a través de los ASN (110a - 110j), (b) una segunda clasificación de nodos cliente adaptados para recibir segmentos desde, y retransmitir segmentos a, otros nodos cliente localizados únicamente en el mismo ASN (110a - 110j) y (c) una tercera clasificación de nodos cliente adaptados para recibir segmentos desde, pero no retransmitir segmentos a, otros nodos cliente.
    10 18. El método de la reivindicación 16, en el que la red subyacente (110) es la Internet y los segmentos de contenido
    digital son segmentos ordenados de contenido de vídeo enviado por flujo continuo simultáneamente a la pluralidad de nodos cliente (200).
  18. 19. El método de la reivindicación 18, en el que el nodo cliente retransmite una pluralidad de diferentes versiones de 15 contenido de vídeo a otro de la pluralidad de nodos cliente (200), teniendo cada versión una tasa de bits o una
    resolución diferentes.
  19. 20. El método de la reivindicación 16, en el que el conjunto de nodos cliente destino designados se modifica dinámicamente cuando los niveles de congestión previstos cumplen uno o más umbrales de congestión predefinidos.
    20
ES15202716.5T 2014-12-26 2015-12-24 Método y sistema para la difusión virtual adaptativa de contenido digital Active ES2670419T3 (es)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201462096938P 2014-12-26 2014-12-26
US201462096938P 2014-12-26
US14/848,268 US9769536B2 (en) 2014-12-26 2015-09-08 Method and system for adaptive virtual broadcasting of digital content
US201514848268 2015-09-08

Publications (1)

Publication Number Publication Date
ES2670419T3 true ES2670419T3 (es) 2018-05-30

Family

ID=55066402

Family Applications (2)

Application Number Title Priority Date Filing Date
ES15202716.5T Active ES2670419T3 (es) 2014-12-26 2015-12-24 Método y sistema para la difusión virtual adaptativa de contenido digital
ES17186964T Active ES2930016T3 (es) 2014-12-26 2015-12-24 Método y sistema para la difusión virtual adaptativa de contenido digital

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES17186964T Active ES2930016T3 (es) 2014-12-26 2015-12-24 Método y sistema para la difusión virtual adaptativa de contenido digital

Country Status (10)

Country Link
US (3) US9769536B2 (es)
EP (3) EP4160993A1 (es)
JP (2) JP6612355B2 (es)
KR (2) KR20220151224A (es)
CN (1) CN107223325B (es)
ES (2) ES2670419T3 (es)
HK (1) HK1249973A1 (es)
MX (1) MX370809B (es)
PL (1) PL3038323T3 (es)
WO (1) WO2016103051A1 (es)

Families Citing this family (78)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10931338B2 (en) 2001-04-26 2021-02-23 Genghiscomm Holdings, LLC Coordinated multipoint systems
US10644916B1 (en) 2002-05-14 2020-05-05 Genghiscomm Holdings, LLC Spreading and precoding in OFDM
US11381285B1 (en) 2004-08-02 2022-07-05 Genghiscomm Holdings, LLC Transmit pre-coding
US9912707B2 (en) 2014-07-31 2018-03-06 Istreamplanet Co. Method and system for ensuring reliability of unicast video streaming at a video streaming platform
US9826011B2 (en) 2014-07-31 2017-11-21 Istreamplanet Co. Method and system for coordinating stream processing at a video streaming platform
US9762934B2 (en) * 2014-11-04 2017-09-12 Electronics And Telecommunications Research Institute Apparatus and method for verifying broadcast content object identification based on web data
US9769536B2 (en) 2014-12-26 2017-09-19 System73, Inc. Method and system for adaptive virtual broadcasting of digital content
FR3034943B1 (fr) * 2015-04-07 2017-04-14 Streamroot Inc Procede de lecture en continu sur un equipement client d'un contenu diffuse au sein d'un reseau pair a pair
US9686576B2 (en) 2015-05-08 2017-06-20 Istreamplanet Co. Coordination of video stream timing in cloud-based video streaming system
US10164853B2 (en) * 2015-05-29 2018-12-25 Istreamplanet Co., Llc Real-time anomaly mitigation in a cloud-based video streaming system
FR3038180A1 (fr) * 2015-06-26 2016-12-30 Orange Adaptation d'un profil de transmission d'une communication web temps reel
US10594746B1 (en) * 2015-09-30 2020-03-17 Amazon Technologies, Inc. Connection service with network routing
US10735476B1 (en) 2015-09-30 2020-08-04 Amazon Technologies, Inc. Connection service with network routing
EP3398335A1 (en) * 2015-12-29 2018-11-07 Dish Technologies L.L.C. Methods and systems for adaptive content delivery
US10007591B2 (en) * 2016-01-29 2018-06-26 Sugarcrm Inc. Adaptive content balancing in a web application environment
US10122589B2 (en) * 2016-04-08 2018-11-06 Cisco Technology, Inc. Configuring the design of an industrial automation network
GB2549549B (en) * 2016-04-19 2020-12-23 Cisco Tech Inc A mapping database system for use with content chunks
CN109417509B (zh) * 2016-05-13 2021-07-13 瑞典爱立信有限公司 多路径网络中改善的资源使用
US10046236B2 (en) * 2016-06-13 2018-08-14 Sony Interactive Entertainment America, LLC Browser-based cloud gaming
US10965729B2 (en) * 2016-06-14 2021-03-30 Netent Product Services Ltd. Live streaming of media for low-latency applications such as live casino gaming applications
US10826805B2 (en) * 2016-07-11 2020-11-03 Acronis International Gmbh System and method for dynamic online backup optimization
US10405023B2 (en) * 2016-08-16 2019-09-03 At&T Intellectual Property I, L.P. Method and apparatus for providing video content using collaborative end points
US20180062935A1 (en) * 2016-08-25 2018-03-01 Futurewei Technologies, Inc. Hybrid approach with classification for name resolution and producer selection in icn
US10743004B1 (en) 2016-09-01 2020-08-11 Amazon Technologies, Inc. Scalable video coding techniques
US10743003B1 (en) * 2016-09-01 2020-08-11 Amazon Technologies, Inc. Scalable video coding techniques
US9641566B1 (en) * 2016-09-20 2017-05-02 Opentest, Inc. Methods and systems for instantaneous asynchronous media sharing
CN106548645B (zh) * 2016-11-03 2019-07-12 济南博图信息技术有限公司 基于深度学习的车辆路径寻优方法及系统
US10812598B2 (en) * 2016-12-30 2020-10-20 Akamai Technologies, Inc. Unified, browser-based enterprise collaboration platform
US10375453B2 (en) 2017-02-28 2019-08-06 Digital Broadcasting and Communications Network, LLC Device for industry-specific content streaming
US20180255114A1 (en) * 2017-03-06 2018-09-06 Vyu Labs, Inc. Participant selection for multi-party social media sessions
JP6749281B2 (ja) * 2017-03-23 2020-09-02 エヌ・ティ・ティ・コミュニケーションズ株式会社 ＩｏＴデバイス、シグナリングサーバ、メッセージバス管理サーバ、コネクション形成方法、及びプログラム
US10735268B2 (en) 2017-04-21 2020-08-04 System73 Ltd. Predictive overlay network architecture
KR102307447B1 (ko) * 2017-05-02 2021-09-30 삼성전자주식회사 네트워크 환경 모니터링에 기반하는 http 적응적 스트리밍 서버, 방법, 및 클라이언트 단말
US10243773B1 (en) 2017-06-30 2019-03-26 Genghiscomm Holdings, LLC Efficient peak-to-average-power reduction for OFDM and MIMO-OFDM
US10637705B1 (en) 2017-05-25 2020-04-28 Genghiscomm Holdings, LLC Peak-to-average-power reduction for OFDM multiple access
US10922606B2 (en) 2017-06-13 2021-02-16 International Business Machines Corporation Multi-directional reduction in large scale deep-learning
EP3643042A1 (en) * 2017-06-20 2020-04-29 Telefonaktiebolaget LM Ericsson (publ.) Methods and network nodes enabling a content delivery network to handle unexpected surges of traffic
US10673715B2 (en) 2017-07-20 2020-06-02 Servicenow, Inc. Splitting network discovery payloads based on degree of relationships between nodes
CN109313484B (zh) * 2017-08-25 2022-02-01 深圳市瑞立视多媒体科技有限公司 虚拟现实交互系统、方法及计算机存储介质
US10999611B2 (en) 2017-09-15 2021-05-04 Imagine Communications Corp. Systems and methods for playout of fragmented video content
CN109819285B (zh) * 2017-11-21 2021-09-21 北京乐我无限科技有限责任公司 一种直播方法、装置、电子设备及存储介质
WO2019125445A1 (en) * 2017-12-20 2019-06-27 Visa International Service Association Automated fault detecting control system
US10523979B2 (en) * 2017-12-21 2019-12-31 Vyu Labs, Inc. Streaming live video
CN108365981B (zh) * 2018-02-05 2020-12-01 柳州达迪通信技术股份有限公司 一种实现多信令协议异常号码或者异常协议的跟踪方法
US10791047B2 (en) * 2018-02-19 2020-09-29 Disney Enterprise Inc. Automated network navigation
KR20190099930A (ko) 2018-02-20 2019-08-28 삼성전자주식회사 완전 연결 네트워크의 데이터 입력 및 출력을 제어하는 방법 및 장치
WO2019164637A1 (en) 2018-02-23 2019-08-29 Futurewei Technologies, Inc. Advertising and programming preferred path routes using interior gateway protocols
US11381984B2 (en) * 2018-03-27 2022-07-05 Forescout Technologies, Inc. Device classification based on rank
WO2019190699A1 (en) 2018-03-28 2019-10-03 Futurewei Technologies, Inc. Method and apparatus for preferred path route information distribution and maintenance
JP2019138461A (ja) * 2018-04-13 2019-08-22 バルチラジャパン株式会社 リップシール、シールリング、シールリング装置及び船舶
US10979476B2 (en) 2018-04-16 2021-04-13 Infrared5, Inc. System and method for verifying and providing compensation for participation in real-time streaming of multimedia over a decentralized network
US10848553B2 (en) * 2018-04-16 2020-11-24 Infrared5, Inc. System and method for real-time secure multimedia streaming over a decentralized network
EP3785405A1 (en) * 2018-04-26 2021-03-03 Huawei Technologies Co., Ltd. Resource reservation and maintenance for preferred path routes in a network
WO2019212678A1 (en) 2018-05-04 2019-11-07 Futurewei Technologies, Inc. Explicit backups and fast re-route mechanisms for preferred path routes in a network
WO2019236221A1 (en) 2018-06-04 2019-12-12 Futurewei Technologies, Inc. Preferred path route graphs in a network
KR102080147B1 (ko) * 2018-06-20 2020-02-24 네이버 주식회사 적응형 데이터 전송을 위한 방법 및 시스템
TWI680661B (zh) * 2018-07-20 2019-12-21 茂傑國際股份有限公司 加值遠端顯示服務的無線路由伺服裝置及方法
KR102129115B1 (ko) * 2018-09-28 2020-07-02 한국과학기술원 컨텐츠 인지 신경망을 이용하여 실시간으로 적응형 비디오를 전송하는 방법 및 장치
CN109543818A (zh) * 2018-10-19 2019-03-29 中国科学院计算技术研究所 一种基于深度学习模型的链路评估方法和系统
CN109951392B (zh) * 2019-01-31 2021-07-02 武汉大学 一种基于深度学习的中大型网络智能路由选择方法
FR3094597B1 (fr) * 2019-03-27 2021-06-11 Streamroot Procédé de diffusion de contenus en streaming dans un réseau pair à pair
US11295239B2 (en) 2019-04-17 2022-04-05 International Business Machines Corporation Peer assisted distributed architecture for training machine learning models
US10924786B2 (en) * 2019-05-08 2021-02-16 Nanning Fugui Precision Industrial Co., Ltd. Method for shaping video streams and set-up box using the method
WO2020242898A1 (en) 2019-05-26 2020-12-03 Genghiscomm Holdings, LLC Non-orthogonal multiple access
US20220174521A1 (en) * 2019-05-31 2022-06-02 Apple Inc. Systems and methods for performance data streaming, performance data file reporting, and performance threshold monitoring
US11025987B2 (en) * 2019-08-15 2021-06-01 Hulu, LLC Prediction-based representation selection in video playback
CN112541147A (zh) * 2019-09-23 2021-03-23 北京轻享科技有限公司 一种内容发布管理方法及系统
CN111010341B (zh) * 2019-12-19 2020-10-27 南京大学 一种基于深度学习的覆盖网络路由决策方法
CN111294618B (zh) * 2020-03-12 2022-04-01 周光普 一种广播电视数据安全的监测系统及方法
CN112261421B (zh) * 2020-10-12 2022-11-15 Oppo广东移动通信有限公司 虚拟现实的显示方法、装置、电子设备及存储介质
US11812081B2 (en) 2020-11-02 2023-11-07 Hulu, LLC Session based adaptive playback profile decision for video streaming
CN112821940B (zh) * 2021-01-15 2022-08-30 重庆邮电大学 一种基于星间链路属性的卫星网络动态路由方法
US20230083701A1 (en) * 2021-09-15 2023-03-16 International Business Machines Corporation Automatically controlling resource partitions in advance of predicted bottlenecks for log streaming messages
CN113904974B (zh) * 2021-10-09 2023-08-15 咪咕文化科技有限公司 智能路由方法、装置及设备
JP2023081226A (ja) 2021-11-30 2023-06-09 株式会社リコー 通信管理装置、通信システム、通信管理方法、及びプログラム
CN114710436B (zh) * 2022-04-19 2023-02-07 电子科技大学 一种拓扑攻击下多域无人系统的拓扑重构方法
US20230396826A1 (en) * 2022-06-06 2023-12-07 Gathani APURVI Method of broadcasting real-time on-line competitions and apparatus therefor
US11606553B1 (en) * 2022-07-15 2023-03-14 RiversideFM, Inc. Hybrid media recording

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7086077B2 (en) * 1999-04-01 2006-08-01 Sedna Patent Services, Llc Service rate change method and apparatus
US6275470B1 (en) * 1999-06-18 2001-08-14 Digital Island, Inc. On-demand overlay routing for computer-based communication networks
US7117273B1 (en) 2000-01-25 2006-10-03 Cisco Technology, Inc. Methods and apparatus for maintaining a map of node relationships for a network
US7240124B2 (en) 2001-06-20 2007-07-03 Silver Beech Networks, Inc. System and method for transferring data on a network using a single route optimizer to define an explicit route and transfer the information related to the explicit route to a plurality of routers and a plurality of optimized routers on the network
US7613796B2 (en) 2002-09-11 2009-11-03 Microsoft Corporation System and method for creating improved overlay network with an efficient distributed data structure
US20050015511A1 (en) 2003-07-02 2005-01-20 Nec Laboratories America, Inc. Accelerated large data distribution in overlay networks
US7388841B2 (en) * 2003-10-20 2008-06-17 Mitsubishi Electric Research Laboratories, Inc. Selecting multiple paths in overlay networks for streaming data
US9325805B2 (en) 2004-08-02 2016-04-26 Steve J Shattil Content delivery in wireless wide area networks
US20070150498A1 (en) 2005-12-23 2007-06-28 Xerox Corporation Social network for distributed content management
US8509098B2 (en) 2006-04-28 2013-08-13 Alcatel Lucent Method and apparatus for identifying network connectivity changes in dynamic networks
US20080059631A1 (en) 2006-07-07 2008-03-06 Voddler, Inc. Push-Pull Based Content Delivery System
US8000239B2 (en) 2006-12-14 2011-08-16 Oracle America, Inc. Method and system for bandwidth allocation using router feedback
US9015342B2 (en) 2007-01-22 2015-04-21 Xerox Corporation Two-level structured overlay design for cluster management in a peer-to-peer network
CN100553229C (zh) * 2007-01-24 2009-10-21 中国科学院计算机网络信息中心 一种半覆盖自组织的动态组播路由方法
US20080263130A1 (en) * 2007-04-23 2008-10-23 Nir Michalowitz Apparatus, system and method of digital content distribution
KR100748187B1 (ko) 2007-06-01 2007-08-10 인하대학교 산학협력단 노드 가용도 예측 기반의 그리드 네트워크 혼잡 제어 장치및 방법
WO2009004701A1 (ja) 2007-06-29 2009-01-08 Fujitsu Limited ネットワーク障害検知システム、計測エージェント、監視サーバ、ネットワーク障害検知方法およびネットワーク障害検知プログラム
EP2215770B1 (en) 2007-10-18 2013-03-20 Telefonaktiebolaget L M Ericsson (publ) Merging of overlay networks in distributed data structures
US8565218B2 (en) 2008-06-05 2013-10-22 Hewlett-Packard Development Company, L.P. Flow path discovery in network to guarantee multiple metric QoS constraints
US20100027442A1 (en) 2008-07-31 2010-02-04 International Business Machines Corporation Constructing scalable overlays for pub-sub with many topics: the greedy join-leave algorithm
CN101547347B (zh) * 2009-04-30 2011-08-10 上海大学 可伸缩视频流的覆盖网络分层组播资源最优分配方法
US8848513B2 (en) 2009-09-02 2014-09-30 Qualcomm Incorporated Seamless overlay connectivity using multi-homed overlay neighborhoods
US8170016B2 (en) 2009-11-30 2012-05-01 At&T Intellectual Property I, Lp Packet flow offload to remote destination with routing bypass
US10158554B1 (en) 2012-02-29 2018-12-18 The Boeing Company Heuristic topology management system for directional wireless networks
US9654329B2 (en) 2012-05-04 2017-05-16 The Hong Kong University Of Science And Technology Content distribution over a network
WO2014173704A1 (en) * 2013-04-25 2014-10-30 Peerialism AB Method and device for centralized peer arrangement in p2p overlay networks
US8972992B2 (en) 2013-04-30 2015-03-03 Splunk Inc. Proactive monitoring tree with state distribution ring
US9537719B2 (en) 2014-06-19 2017-01-03 Palo Alto Research Center Incorporated Method and apparatus for deploying a minimal-cost CCN topology
WO2016089435A1 (en) 2014-12-03 2016-06-09 Hewlett Packard Enterprise Development Lp Updating a virtual network topology based on monitored application data
US9769536B2 (en) 2014-12-26 2017-09-19 System73, Inc. Method and system for adaptive virtual broadcasting of digital content
US10735268B2 (en) 2017-04-21 2020-08-04 System73 Ltd. Predictive overlay network architecture
US10705881B2 (en) 2017-05-12 2020-07-07 Red Hat, Inc. Reducing overlay network overhead across container hosts
US20190312810A1 (en) 2018-04-10 2019-10-10 System73 Ltd Adaptive overlay network architecture

Also Published As

Publication number Publication date
US10225619B2 (en) 2019-03-05
US20160192029A1 (en) 2016-06-30
HK1249973A1 (zh) 2018-11-16
US20190158930A1 (en) 2019-05-23
JP2018507660A (ja) 2018-03-15
KR20170101287A (ko) 2017-09-05
EP4160993A1 (en) 2023-04-05
WO2016103051A1 (en) 2016-06-30
US20170347157A1 (en) 2017-11-30
JP6839746B2 (ja) 2021-03-10
PL3038323T3 (pl) 2018-08-31
EP3038323A1 (en) 2016-06-29
US10992998B2 (en) 2021-04-27
EP3264722A1 (en) 2018-01-03
BR112017013811A2 (pt) 2018-02-27
MX370809B (es) 2020-01-08
CN107223325A (zh) 2017-09-29
CN107223325B (zh) 2021-03-26
EP3264722B1 (en) 2022-08-17
KR102462384B1 (ko) 2022-11-03
MX2017008157A (es) 2018-02-13
US9769536B2 (en) 2017-09-19
JP2020039140A (ja) 2020-03-12
JP6612355B2 (ja) 2019-11-27
ES2930016T3 (es) 2022-12-05
KR20220151224A (ko) 2022-11-14
EP3038323B1 (en) 2018-02-28

Similar Documents

Publication Publication Date Title
ES2670419T3 (es) Método y sistema para la difusión virtual adaptativa de contenido digital
Mukerjee et al. Practical, real-time centralized control for cdn-based live video delivery
US8116235B2 (en) Peer-to-peer aided live video sharing system
US9838724B2 (en) Media distribution network for live streaming
CN110336843B (zh) 一种用于众包的内容分发方法、中心节点及边缘节点
US20150062285A1 (en) Multicast tree packing for multi-party video conferencing under sdn environment
US20130159547A1 (en) Data transfer system
CN110139119B (zh) 数字广播系统的p2p音频直播分发方法、装置及存储介质
Aubry et al. Green growth in NDN: Deployment of content stores
US20210021906A1 (en) Special network device
US20210021907A1 (en) Network arrangement using snds and slans
Malik et al. Experiences from a field test using ICN for live video streaming
Fouda et al. A novel P2P VoD streaming technique integrating localization and congestion awareness strategies
BR112017013811B1 (pt) Método e servidor de broadcast virtual de conteúdo digital
US20140181261A1 (en) Method and apparatus for providing efficient transmission of streaming video through a complex ip network
US20130151664A1 (en) Data transfer system
Fleury Streaming Media with Peer-to-Peer Networks: Wireless Perspectives: Wireless Perspectives
Rocha et al. BitCover: Enhanced BitTorrent for interactive VoD streaming over 5G and WiFi-Direct
Poderys Scalable Streaming Multimedia Delivery using Peer-to-Peer Communication
Seung et al. Randomized routing in multi-party internet video conferencing
Kariminasab A Simulation Study on Performance of Video-On-Demand Systems
Medina-López et al. P2PSP (Peer-to-Peer “Straightforward” Protocol)
da Silva Multiple Multicast Trees for media distribution