KR20170101287A - 디지털 콘텐츠의 적응적 가상 방송을 위한 방법 및 시스템 - Google Patents
디지털 콘텐츠의 적응적 가상 방송을 위한 방법 및 시스템 Download PDFInfo
- Publication number
- KR20170101287A KR20170101287A KR1020177020882A KR20177020882A KR20170101287A KR 20170101287 A KR20170101287 A KR 20170101287A KR 1020177020882 A KR1020177020882 A KR 1020177020882A KR 20177020882 A KR20177020882 A KR 20177020882A KR 20170101287 A KR20170101287 A KR 20170101287A
- Authority
- KR
- South Korea
- Prior art keywords
- nodes
- asn
- video
- overlay
- client
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 44
- 230000003044 adaptive effect Effects 0.000 title description 18
- 238000013135 deep learning Methods 0.000 claims abstract description 6
- 101150014732 asnS gene Proteins 0.000 claims description 84
- 238000011144 upstream manufacturing Methods 0.000 claims description 21
- 238000012544 monitoring process Methods 0.000 claims description 16
- 201000008217 Aggressive systemic mastocytosis Diseases 0.000 claims 1
- 230000001934 delay Effects 0.000 abstract description 3
- 230000011664 signaling Effects 0.000 description 31
- 230000008569 process Effects 0.000 description 14
- 235000008694 Humulus lupulus Nutrition 0.000 description 13
- 238000013459 approach Methods 0.000 description 12
- 230000006854 communication Effects 0.000 description 11
- 238000004891 communication Methods 0.000 description 11
- 230000006870 function Effects 0.000 description 10
- 230000008859 change Effects 0.000 description 8
- 230000001413 cellular effect Effects 0.000 description 6
- 238000004458 analytical method Methods 0.000 description 5
- 230000003111 delayed effect Effects 0.000 description 5
- 239000000835 fiber Substances 0.000 description 5
- 230000000694 effects Effects 0.000 description 4
- 230000004044 response Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000006835 compression Effects 0.000 description 3
- 238000007906 compression Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 238000003491 array Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 238000006731 degradation reaction Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 101150012579 ADSL gene Proteins 0.000 description 1
- 102100020775 Adenylosuccinate lyase Human genes 0.000 description 1
- 108700040193 Adenylosuccinate lyases Proteins 0.000 description 1
- 238000013528 artificial neural network Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 238000010924 continuous production Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000010899 nucleation Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000036961 partial effect Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000003997 social interaction Effects 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000000844 transformation Methods 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- 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
- 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
- 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
-
- H04L47/823—
-
- 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
-
- H04L65/4076—
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Multimedia (AREA)
- Environmental & Geological Engineering (AREA)
- Databases & Information Systems (AREA)
- Computing Systems (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
본 발명의 가상 방송 시스템은 기반이 되는 네트워크 내의 컴포넌트 상호연결들의 자주 변하는 혼잡 레벨들의 예측들에 기초하여 동적으로 재구성되는 오버레이 네트워크들을 따라 노드들 사이의 디지털 콘텐츠의 라우팅을 최적화한다. 스트리밍 비디오를 인터넷을 통해 많은 수의 동시 사용자들에게 전달하는 것과 관련하여, 본 발명은 혼잡한 ASN 피어링 포인트들의 제한된 용량을, 그 ASN 피어링 포인트들을 거치는 혼잡 레벨들을 예측하고, 그 예측들에 기초하여, 동적으로 재구성된 오버레이 네트워크들을 따라 비디오 콘텐츠의 라우팅을 최적화하기 위해 딥 러닝 기법들을 이용하는 것에 의해, 효율적으로 사용한다. 가상 방송 시스템은 예정되지 않은 이벤트들은 물론 예정된 이벤트들을 핸들링하고, 실황 이벤트들은 물론 녹화된 이벤트들을 스트리밍하며, 많은 수의 동시 시청자들 간에 일관성있는 QoE를 유지하는 확장성 높은 방식으로 그 이벤트들을 최소한의 지연으로 실시간으로 스트리밍한다.
Description
관련 출원의 상호 참조
본 출원은 2014년 12월 26일에 출원된 미국 가특허 출원 제62/096,938호 - 그의 개시내용은 이로써 그 전체가 본원에 기재된 것처럼 참고로 포함됨 - 를 우선권 주장한다.
본 발명은 일반적으로 기반이 되는 네트워크의 노드들 간에 디지털 콘텐츠를 전달하기 위한 오버레이 네트워크 아키텍처에 관한 것으로서, 보다 상세하게는 기반이 되는 네트워크 내의 컴포넌트 상호연결부들에서의 빈번히 변하는 혼잡 레벨들의 예보들에 기초하여 동적으로 재구성되는 오버레이 네트워크들을 따라 있는 노드들 간의 디지털 콘텐츠의 라우팅을 최적화하는 가상 방송 시스템에 관한 것이다.
네트워크 혼잡
유선 및 무선 네트워크 트래픽이 계속하여 기하급수적으로 늘어날 때, 네트워크 내의 컴포넌트들 사이의 공유 링크들 또는 상호연결부들의 유한한 용량이 점점 더 중요하고 골치아픈 문제로 되고 있다. 더욱이, 네트워크 트래픽이 변할 때 이 공유 링크들에서의 혼잡 레벨이 동적이고 큰 변동성을 겪기 때문에, 이러한 혼잡은 임의의 주어진 때에 측정하기가 어렵고 단기적으로도 예측하기가 특히 어렵다.
이 문제는 점점 인구가 늘고 있는 지역들에 있는 공유 도로들 및 고속도로들의 교차로들에서의 교통 혼잡의 문제와 얼마간 유사하다. 기존의 GPS 내비게이션 및 교통 통제 시스템들이 이 교차로들에서의 현재 혼잡을 측정하고, 개개의 운전자들을 이러한 혼잡을 우회하게 경로 재설정하기 위해 최적의 경로들을 계산하는 반면, 임의의 특정의 운전자에 대한 최적의 경로를 미리 예측할 수 있는 그들의 능력이 교통 혼잡의 변동적인 성질에 의해 방해를 받는다.
Netflix와 같은 단일의 회사가 피크 인터넷 트래픽의 1/3 초과를 차지할 때, 인터넷을 통해 동시에 디지털 정보(특히 대량의 선형 데이터)를 전달하는 회사들은 인터넷 혼잡의 점점 더 변동적인 성질을 얼마간 해결해야만 한다. 이와 유사하게, 모바일 음성 및 데이터 사용량이 급증함에 따라, 규제된 RF 스펙트럼의 제한된 이용가능성은 고 대역폭 모바일 애플리케이션들을 개발하는 회사들에 특히 중요하다.
본 발명의 특정의 적용분야가 인터넷을 통해 스트리밍 비디오를 많은 수의 동시 사용자들에게 전달하는 것과 관련하여 본원에 기술되어 있지만, 본 발명의 원리들이 네트워크 컴포넌트들 사이의 공유 링크들의 제한된 용량이 디지털 포맷으로 변환될 수 있는 임의의 유형의 정보(예컨대, 오디오, 영상, 3D 모델 등)의 라우팅을 제약하는 다수의 다른 상황들에서 똑같이 적용된다. 본 발명의 다른 잠재적인 적용분야들은 (임의의 주어진 시점에서 기반이 되는 네트워크 내의 공유 링크들의 혼잡 레벨과 관련한), 예를 들어, VoIP, 회사 화상회의, 가상 현실, 멀티플레이어 게임, 및 각종의 다른 대역폭 집약적 적용분야들을 포함한다.
이하에서 보다 상세히 논의될 것인 바와 같이, 본 발명은 인터넷과 같은 기반이 되는 네트워크 내의 컴포넌트 링크들에서의 제한된 용량 또는 "네트워크 혼잡"의 문제를 "해결"하지는 않지만, 그 대신에 그 링크들에서의 혼잡 레벨들의 예측들에 기초하여 동적으로 재구성되는 오버레이 네트워크들의 노드들 간의 디지털 콘텐츠의 라우팅을 최적화하기 위해 그 링크들에 걸쳐 네트워크 트래픽을 모니터링하고 분석함으로써 그 제한된 용량을 효율적으로 사용한다.
비디오 스트리밍 이벤트
인터넷 및 IP 기반 라우팅의 등장 이후로, 인터넷을 통해 비디오를 스트리밍하는 많은 접근법들이 나왔다. 그들의 상대적 장점들 및 단점들을 논의하기 전에, 해결될 문제를 한 걸음 물러나서 살펴보는 것이 도움이 된다. 비디오 콘텐츠를 인터넷을 통해 배포하기 위해, 비디오 콘텐츠가 먼저 포착되고 디지털화되어야만 한다. 비디오 콘텐츠를 "실황으로(live)" 포착되고(또는 디지털적으로 발생되고) 인터넷을 통해 배포되는 "이벤트"라고 생각할 수 있다. 본원에서 비디오 이벤트라고 하는 것은 비디오와 오디오 둘 다는 물론, 임의의 연관된 메타데이터의 포착 또는 발생을 포함한다.
비디오 이벤트들이 예정된 것이거나 예정되지 않은 것일 수 있다. 예를 들어, "수퍼 볼"은 그의 발생 시각이 미리 알려져 있다는 점에서 예정된 이벤트인 반면, 다른 이벤트들(예컨대, 자연 재해, 유아의 첫 걸음, 또는 심지어 VOD(video on demand))은 그들이 사전 경고가 거의 또는 전혀 없이 발생할 수 있다는 점에서 예정되지 않은 것이다.
비디오 콘텐츠가 디지털화된 비디오 파일을 발생시키기 위해 전체로서 포착될 수 있고, 이어서 임의의 다른 유형의 파일이 (예컨대, FTP(file transfer protocol)를 통해) 전송될 때 디지털화된 비디오 파일이 인터넷을 통해 배포된다. 그렇지만, 이러한 "파일 전송" 접근법은 수신자가 비디오 콘텐츠를 시청(재생)하는 것에 지연을 부과한다 - 즉, 수신자는 비디오 콘텐츠를 시청하기 전에 파일 전체가 전송될 때까지 기다려야만 한다 -. 디지털화된 비디오의 파일 크기들이 비교적 큰 경우에, 이 지연은 상당할 수 있다.
비디오 콘텐츠가 따라서, 콘텐츠가 여전히 송신되고 있는 동안 사용자들이 콘텐츠를 계속하여 수신하고 시청할 수 있도록, 종종 사용자들에게 "스트리밍"된다. 본질적으로, 비디오 콘텐츠는 사용자들에게 전달되는 작은 파일들 또는 "비디오 세그먼트들"(예컨대, 길이가 1 내지 10초임) - 수신될 때 사용자들이 시청하기 시작할 수 있음 - 의 순서화된 선형 스트림(ordered linear stream)으로 분할된다. 연속적인 비디오 콘텐츠 스트림을 지연 또는 지터 없이 시청하기 위해, 각각의 비디오 세그먼트가 일정한 간격을 두고 - 예컨대, 30 fps(frames per second)로 - 재생되어야만 한다. 그렇지만, 이전 세그먼트의 재생이 끝나기 전에 각각의 세그먼트가 수신된다면, 비디오 세그먼트들이 일정한 간격을 두고 수신될 필요가 없다는 것에 유의해야 한다.
이벤트가 예정된 것이든 예정되지 않은 것이든 간에, 이벤트가 "실황으로"(즉, 이벤트가 발생할 때) 스트리밍되거나 이벤트의 발생 이후 언제라도 스트리밍하기 위해 "녹화"될 수 있다. 예를 들어, 수퍼 볼이 포착되고 이벤트가 발생할 때 실황으로 스트리밍되거나, 나중에 스트리밍하기 위해 녹화될 수 있을 것이다.
마지막으로, 이벤트가 예정된 것이든 예정되지 않은 것이든 간에, 그리고 이벤트가 녹화되거나 이벤트가 발생할 때 실황으로 스트리밍되든 간에, 이벤트가 "실시간"으로(즉, 송신기로부터 수신기로 대체로 지각가능하지 않은 지연을 갖고) 스트리밍되거나 수초 또는 심지어 수분 동안 전송이 지연될 수 있다. 예를 들어, 인터넷을 통하지만 실시간으로 스트리밍되지 않는 텔레비전 프로그램(예컨대, 야구 경기)의 시청자들은 서로 상이한 때에, 또는 케이블 또는 위성을 통해 방송된 동일한 프로그램을 보고 있는 시청자들과 상이한 때에 스트리밍된 이벤트를 경험할 수 있다. 이러한 지연들(특히 몇 초 초과인 경우)은, 네트워크 중심 메트릭들(예컨대, 라우터들 또는 다른 네트워크 자원들에 의해 야기되는 패킷 지연, 패킷 손실, 또는 지터)에 기초한 성능 척도인 "QoS(quality of service)"와 달리, 사용자의 "QoE(quality of experience)" - 즉, 사용자 중심 또는 애플리케이션 레벨 품질 관점 - 를 떨어뜨릴 수 있다.
예를 들어, (지터 또는 다른 비디오 아티팩트들 이외에도) 시청자들이 동일한 이벤트를 상이한 때에 경험한다는 사실로 인해 시청자들 사이의 사회적 상호작용이 제약될 수 있다. 이것은 오늘날 아주 많은 (예정된 또는 예정되지 않은) 이벤트들이 아주 많은 상이한 방식들로 - 휴대폰들과 데스크톱 및 랩톱 컴퓨터들을 통해서는 물론, 끊임없이 발전하는 영역의 소비자 전자 디바이스들을 통해 액세스가능한 방송 라디오 또는 텔레비전으로부터 소셜 미디어 및 다른 인터넷 서비스들에 이르기까지 - 실시간으로 전달될 때 특히 문제가 된다.
따라서 비디오 스트리밍 시스템이 예정되지 않은 이벤트들은 물론 예정된 이벤트들을 핸들링하는 것, 실황 이벤트들은 물론 녹화된 이벤트들을 스트리밍하는 것, 그리고 시청자들에게 일관성있는 QoE를 제공하기 위해 그 이벤트들을 최소 지연으로 스트리밍하는 것이 바람직하다. 더욱이, 스트리밍 비디오 이벤트의 동시 시청자들의 수가 증가함에 따라, 일관성있는 QoE를 유지하는 것이 엄청난 문제가 된다. 그 때문에, 확장성이 임의의 이러한 시스템의 핵심 설계 목표이다.
최근의 비디오 스트리밍 기술의 발전에도 불구하고, 인터넷의 인프라스트럭처의 역사적인 "특별한(ad hoc)" 발전은 여전히 인터넷 기반 비디오 스트리밍에 상당한 장애물들 - 그 중 중요한 것은, 예측하기 어려운 가끔씩의 그리고 인터넷에 걸쳐 있는 위치들에서의 네트워크 혼잡을 초래하는 일관성없는 QoS임 - 을 제공한다. 본 발명의 주요 목적이 스트리밍 비디오 이벤트들의 시청자들에 대한 일관성있는 QoE를 유지하는 것이지만, 이 목적이 궁극적으로 제거될 수 없는 인터넷에 걸친 네트워크 혼잡에 의해 제약된다.
기반이 되는 인터넷 아키텍처
ARPANET(인터넷 프로토콜 스위트(Internet protocol suite) 또는 TCP/IP를 구현하는 최초의 패킷 교환 네트워크) 및 나중의 NSFNET으로 시작하여, 인터넷 "백본(backbone)"은 통제를 분산시키고 정보가 그의 원하는 목적지에 도달하기 위한 대안의 통신(라우팅) 경로들을 제공함으로써 신뢰성 또는 "탄력성(resiliency)"을 제공하는 중복적인 "네트워크들의 네트워크 "(즉, 인터넷)이도록 설계되었다. 그러나, 라우터들 및 다른 공유 네트워크 자원들 간의 상이한 경로들을 따라가는 패킷들에 대해, 인터넷을 통해 일관성있는 QoS 또는 QoE를 유지하는 것은 극히 어려운 문제로 남아 있다.
인터넷 백본이 진화하고 민영화됨에 따라, 전통적인 백본 네트워크들과 장거리 전화 통신사업자들이 소유하고 있는 백본 네트워크들 사이에 중복 및 중첩이 나타났다. 본 명세서의 목적상, 우리는 고객들에게 직접 또는 다른 소규모 "ISP(internet service provider) 네트워크들을 통해 데이터를 전송하는 대규모 "공공(public)" 네트워크들과 데이터를 그 자체들 사이에서만 전달하거나, 대규모 ISP들 사이의 통로로서 역할하지만 데이터를 고객들에게 직접 제공하지 않는 대규모 "사설(private)" 백본 네트워크들을 구분한다. 어느 경우든지, 이러한 대규모 공공 및 사설 네트워크들은 전형적으로 광섬유 트렁크 라인(fiber-optic trunk line)들(예컨대, 네트워크 용량을 증가시키기 위해 함께 번들링된 다수의 광섬유 케이블들)을 통해 상호연결된 "광섬유 링(fiber ring)"으로서 구현된다.
라우팅을 위해, 최다 네트워크 트래픽을 전달하는 최대 네트워크 제공자들(예컨대, 대규모 ISP들 및 사설 백본 네트워크들)은 "AS(autonomous system)" - 그 각각은 "ASN(autonomous system number)"을 할당받음 - 라고 알려진 IP 라우팅 프리픽스(IP routing prefix)들의 블록들을 할당받는다. 우리는 이 회사들이 소유하고 있는 대규모 광섬유 링들 각각을 ASN이라고 지칭한다. ASN들의 수가 근래에, 15년 전의 대략 5000개의 ASN들로부터 오늘날 전세계에 걸쳐 50,000개 초과의 ASN들로, 급격히 증가했다. 앞서 언급된 바와 같이, 많은 대규모 네트워크 제공자들은 또한 고객들에게 서비스하지 않지만 그 자신의 "공공 ASN들" 또는 다른 제공자들이 소유하고 있는 공공 ASN들에 연결될 수 있는 백본 광섬유 링 네트워크들(즉, 사설 ASN들)을 소유하고 있다.
상이한 회사들이 ASN들을 소유하고 있기 때문에, 그들은 ASN들에 걸쳐 그리고 전세계 인터넷 전체에 걸쳐 인터넷 트래픽의 라우팅을 용이하게 하기 위해 서로 계약을 체결한다. 각각의 ASN은, "BGP(border gateway protocol)"라고 알려진 라우팅 프로토콜을 이용하여, 다른 ASN에의 액세스를 제어하기 위해 종종 "피어링 포인트(peering point)"라고 지칭되는 라우터들의 뱅크를 이용한다. 임의의 주어진 ASN은 다수의 상이한 ASN들에 연결하기 위해 다수의 피어링 포인트들을 이용할 수 있다. 상호연결된 ASN들은 지리적으로 인접해 있을 수 있거나, 멀리 떨어져 있을 수 있으며, 큰 거리에 걸쳐 있는(예컨대, 국가들 또는 심지어 대양들에 걸쳐 있는) 긴 광섬유 트렁크들을 통해 연결될 수 있다. 공공 ASN들은 또한 "사설 ASN들" 또는 백본 네트워크들을 통해 상호연결될 수 있다.
ASN들 내에서 그리고 ASN들에 걸쳐 QoS를 모니터링하는 것은 극히 어렵다. 대규모 네트워크 제공자들은 그들의 ASN들 내에서의 라우팅 및 성능 정보(동적 혼잡 메트릭들을 포함함)의 상당 부분을 독점적인 것으로서 유지한다. BGP 라우터에의 TCP/IP 연결이 구축될 때 (현재 BPG 버전 4의) "오픈 메시지 포맷(Open Message Format)"이 특정 정보의 "데이터 덤프(data dump)"를 제공하지만, 이 메커니즘은 현실적인 문제로서 그다지 유용하지 않다. 많은 BGP 라우터들이 오픈 메시지 포맷을 지원하지 않는 반면, 다른 것들은 그것을 그냥 턴오프시킨다. 더욱이, 정보는 전형적으로 5분 늦은 것인데, 이는 인터넷에 걸쳐 혼잡 레벨들이 얼마나 자주 변하는지를 고려하면 비교적 긴 시간이다.
이러한 많은 양의 인터넷 트래픽이 ASN들을 상호연결시키는 비교적 고 대역폭의 피어링 포인트들을 거쳐 흐르기 때문에, 이 피어링 포인트들은 종종, ASN들 내의 "라스트 마일(last mile)" 문제(즉, 최종 사용자들과 그들의 "게이트웨이" ISP들 사이의 비교적 보다 낮은 대역폭의 유선 및 무선 연결에 걸친 혼잡) 이외에, 임의의 주어진 때에 인터넷에 걸친 혼잡의 상당 부분의 주요 "병목지점들" 또는 원인들이다.
예를 들어, ASN 피어링 포인트에 걸친 트래픽 부하가 증가할 때 피어링 포인트의 각각의 측면에 있는 ASN들에 있는 라우터들이 혼잡해진다. 환언하면, 이 라우터들은 RAM, CPU 및 다른 제한된 용량의 공유 자원들의 높은 이용율을 경험한다. 이 자원들에 대한 증가된 수요는 이 피어링 포인트들에 걸친 성능(예컨대, 비트 레이트)을 떨어뜨리고, 궁극적으로 손실된 데이터 패킷들을 초래할 수 있다. 인터넷에 걸친 네트워크 트래픽이 중앙에서 제어되지 않기 때문에, 임의의 주어진 때에 인터넷에 걸쳐 자주 변하는 "피어링 포인트 혼잡" 레벨들을 예측하기가 어렵다.
ASN들 내에서 그리고 ASN들에 걸쳐 일관성있는 QoS를 보장할 수 없는 경우, 스트리밍 비디오 이벤트들의 시청자들에 대해 일관성있는 QoE를 유지하는 것이 아주 어렵게 된다. 인터넷을 통해 비디오를 스트리밍하는 임의의 시스템은, 특히 아주 많은 인터넷 트래픽이 흐르는 ASN 피어링 포인트들에서, 공유 라우터들의 끊임없이 변하는 혼잡 레벨들 및 신뢰할 수 없음을 겪는다. 비디오를 인터넷을 거쳐 그리고 특히 이 ASN 피어링 포인트들을 거쳐 많은 수의 동시 시청자들에 스트리밍할 때 이 문제가 악화된다.
기존의 비디오 스트리밍 접근법
인터넷을 통해 비디오를 스트리밍하는 다양한 접근법들이 지난 수십년에 걸쳐 발전하였으며, (인터넷 위에) 오버레이 네트워크 토폴로지들을 발생시키고 이 오버레이 네트워크들을 따라 있는 네트워크 노드들 사이에서 비디오 콘텐츠를 전달하는 상이한 기법들을 특징지우고 구별하기 위해 광범위한 용어가 이용된다. 상이한 접근법들을 비교할 때, GPS 내비게이션 비유로 잠시 돌아가서, 임의의 2개의 지점들 또는 노드들 사이에서 이동하는 데 필요한 시간에 영향을 미치는 인자들 - 즉, 거리, 속력 및 혼잡(전형적으로 상이한 경로를 따라 경로 재설정하는 것에 의해 해결됨) - 을 살펴보는 것이 도움이 된다.
인터넷 상에서 패킷들을 라우팅하는 것과 관련하여, 거리(또는 지리적 근접성)는 직접적인 관련성이 없는데, 그 이유는 패킷들이 거의 광속으로 이동하기 때문이다. 그렇지만, 속력은 경로를 따라 마주치게 되는 정류소들 또는 장애물들의 수, 또는 이와 관련하여 2개의 노드들 사이의 중간 라우터들에서 마주치게 되는 "홉들"의 수에 의해 영향을 받는다. 이와 같이, 2개의 노드들은, 그들의 지리적 근접성에 관계없이, 비교적 적은 홉들만큼만 떨어져 있는 경우 서로 "근방에"("네트워크 근접성" 내에) 있다고 말해질 수 있다. 2개의 노드들 사이의 경로를 따라 있는 중간 노드들에서의 혼잡은 전체적인 이동 시간에 영향을 미치고, 트래픽을 동적으로 재라우팅하는 것 - 즉, 2개의 노드들 사이의 경로를 결정하는 오버레이 네트워크들을 동적으로 재구성하는 것 - 에 의해 해결될 수 있다. 이하에서 논의될 것인 바와 같이, 이 인자들은 인터넷을 통해 비디오를 스트리밍하는 상이한 접근법들 간의 주요 차이점들을 설명하는 역할을 한다.
인터넷 외에 비디오를 전달하는 가장 흔한 방법은 - 예컨대, 전용 케이블 또는 위성 인프라스트럭처를 통해 - 비디오 스트림(예컨대, 텔레비전 프로그램)을 "발신 지점(point of origin)"으로부터 모든 목적지 시청자들로 동시에 "브로드캐스팅"하는 것이다. LAN에서 정보를 모든 네트워크 노드들로 브로드캐스팅하기 위해 네트워크 허브들이 이용될 수 있지만, 인터넷을 통해 스위치들 및 라우터들을 거쳐 비디오 세그먼트들의 패킷들을 브로드캐스팅하는 것은 아주 비실용적이고 비효율적이다. 대부분의 네트워크 사용자들은 임의의 주어진 비디오 콘텐츠의 "채널"을 시청하는 것에 관심이 없을 것이고, 비디오 세그먼트들을 다른 라우터들로 브로드캐스팅하는 라우터들이 쉽게 압도될 것이기 때문에 발신 지점 근방에서 상당한 혼잡이 발생할 것이다. 브로드캐스트 해결책은 인터넷을 통해 단일의 발신 지점으로부터 언제라도 채널에 합류할 수 있는 많은 수의 동시 시청자들에게 비디오 콘텐츠 채널을 전달하는 데 전혀 실현가능하지 않다.
대안의 "멀티캐스트" 접근법은 각각의 비디오 세그먼트를 인터넷을 거쳐 발신 지점으로부터 미리 정의된 노드들의 그룹들로 동시에 스트리밍하는 것을 포함한다. 이 접근법도 마찬가지로 인터넷을 통한 대규모 비디오 배포에는 비실용적이다. 더욱이, 멀티캐스팅 기능을 갖는 전용 라우터들과 같은, 특수 인프라스트럭처가 필요하며, 이것도 또한 비실용적이고 대규모 상업적 사용을 위해 엄청나게 비용이 많이 든다.
브로드캐스트 및 멀티캐스트 기법들과 달리, 비디오 스트리밍에 대한 "유니캐스트" 기법은 (예컨대, 정의된 목적지 노드 IP 주소와 TCP/IP 연결을 구축하는 것에 의해) 발신 지점으로부터 단일의 목적지 노드로 비디오 세그먼트들을 송신하는 것을 포함한다. 그러나, 많은 수의 유니캐스트 패킷들을 각각의 시청측 노드(viewing node)에 전달하는 것이 또한 발신 지점에 또는 그 근방에 있는 라우터들을 재빨리 압도할 것이고, 이러한 많은 수의 동시 전송들을 핸들링하기에 충분한 대역폭을 제공하는 것의 엄청난 비용은 말할 것도 없이, 앞서 살펴본 이유들 중 다수로 인해 일관성있는 QoS를 달성하지 못할 것이다.
(Netflix와 YouTube와 같은) 일부 VOD 회사들은 일반적으로 고가의 "에지 서버(edge-server)" 인프라스트럭처에 의존하는 유니캐스트 접근법의 변형들을 이용하고 있다. 이 접근법(때때로 CDN(content delivery network)이라고 지칭됨)은 인터넷에 걸쳐 많은 물리적 서버들을 설치하는 것 및 각각의 비디오 콘텐츠 채널의 사본들을 각각의 서버에 배포하는 것을 포함한다. 그 결과, 시청측 노드들은 원하는 비디오 콘텐츠를 (네트워크 근접성 내에 있는 - 시청측 노드로부터 단지 비교적 적은 홉들만큼 떨어져 있는 -) 근방의 서버로부터 수신할 수 있다.
각각의 에지 서버는 전형적으로 상당한 대역폭과 계산 능력을 가지며, 본질적으로 개별적인 비디오 콘텐츠 소스 - 근방의 시청측 노드들은 이로부터 임의의 시점에서("주문 시에") 임의의 비디오 콘텐츠 채널을 획득할 수 있음 - 를 구성한다. 물리적 인프라스트럭처를 추가하는 이 접근법은 보다 많은 사람들이 인기있는 목적지들에 보다 신속하게(보다 적은 방향전환들 및 보다 느린 도로들에서 보다 적은 시간이 소비되는 것에 의해) 도달할 수 있게 하기 위해 부가의 고속도로들 및 진출로들을 건설하는 것과 얼마간 유사하다.
상이한 사용자들이 전형적으로 임의의 주어진 때에 상이한 비디오 채널들을 보고자 하지만, VOD 시스템들은 특정의 비디오 이벤트가 많은 수의 동시 시청자들로 스트리밍되어야만 하는 "피크" 수요 기간들(예컨대, 인기있는 텔레비전 시리즈의 마지막 회)에 가끔 직면하고, 이는 최대 스트리밍 비디오 회사의 인프라스트럭처조차도 압도할 수 있다 - 또는 적어도 그로 인해, (즉, 보다 흔한 비피크 수요의 기간들 동안) 빈번히 과소 사용되는 고가의 인프라스트럭처의 비효율적인 "최악의(worst-case)" 배치를 초래함 -. 대안의 VOD 해결책들은 (예를 들어, 미국 특허 공개 제2008/0059631호에서 논의된 바와 같이) 비디오 콘텐츠를 복제하여 네트워크 노드들 자체 간에 배포하는 것에 의해 고가의 에지 서버 인프라스트럭처를 필요없게 하려고 시도하였다.
고가의 에지 서버 인프라스트럭처가 있는 경우 또는 없는 경우, 이 VOD 해결책들 중 어느 것도 예정되지 않은 비디오 이벤트들에 대한 QoS 문제를 해결하지 않는데, 그 이유는 그들 모두가 - 근방의 비디오 콘텐츠 소스를 보장하기 위해 - 미리 알려져 있는 콘텐츠를 갖는 인터넷 전체에 걸쳐 있는 "프리-시딩(pre-seeding)" 에지 서버들 또는 시청측 노드들에 의존하기 때문이다. 실황의 예정되지 않은 이벤트를 스트리밍하는 것은, 이 VOD 시스템들 중 어느 것에 의해서도 해결되지 않는 문제인, 이 에지 서버들 또는 시청측 노드들 모두에게로의 비디오 콘텐츠의 실시간 동시 전달을 필요로 할 것이다.
보다 최근에, 몇몇 유니캐스트 기반 비디오 스트리밍 표준들(예컨대, "WebRTC")이 어떤 플러그인들도 필요로 함이 없이 데스크톱과 모바일 웹 브라우저들 간의 비디오의 "점대점" 스트리밍을 용이하게 하도록 발전하였다. 많은 기존의 스마트폰들은 물론, 데스크톱과 랩톱 컴퓨터들은 브라우저간 비디오 스트리밍을 지원하는 WebRTC 라이브러리들은 물론, 시청측 노드가 그의 대역폭 및 CPU 능력을 실시간으로 검출하고 그 메트릭들의 변화들에 적응하기 위해 보다 낮은 또는 보다 높은 "비트 레이트"를 자동으로 요청할 수 있게 하는 "적응적 스트리밍" 라이브러리들을 포함한다.
적응적 스트리밍 구현들은, 그 중에서도 특히, Apple의 "HLS(HTTP Live Streaming)", Microsoft의 "Smooth Streaming" 그리고 "MPEG-Dash" ISO 표준을 포함한다. 전형적인 점대점 비디오 스트리밍 시나리오에서, 수신측 노드는, 다가오는(예컨대, 다음의 8개의) 비디오 세그먼트들의 각각의 이용가능한 비트 레이트 버전의 위치들을 포함하는, "매니페스트 파일(manifest file)들"을 HTTP 서버에 주기적으로 요청한다. 예를 들어, 각각의 비디오 세그먼트가, 그의 해상도에 관계없이, 본질적으로 동일한 양의 시간 내에 전달되도록 하기 위해, 각각의 비디오 세그먼트는, 상이한 스트리밍 비트 레이트들(대역폭)을 필요로 하는 상이한 "비디오 해상도들"을 반영하는, 1080p, 720p 및 480p 버전들로 이용가능할 수 있다.
(WebRTC를 지원하는 웹 브라우저들에 있는) 표준의 HTML5 비디오 플레이어들은, 비디오 콘텐츠를 재생하기 시작하기 전에, 전형적으로 3개의 비디오 세그먼트들을 버퍼링한다. 그들은 각각의 비디오 세그먼트에 대해 HTTP 요청을 HTTP 서버로 송신하기 위해 현재 매니페스트 파일을 사용한다. 송신측 노드는 이어서 수신측 노드의 웹 브라우저에서의 재생을 위해 WebRTC 표준들에 따라 (작은 "청크들"로 된) 각각의 비디오 세그먼트를 수신측 노드로 "푸시"한다. 수신측 노드가 적응적 스트리밍 구현들을 지원하고, 최근의 비디오 세그먼트들을 수신하는 데 필요한 시간이 상당히 증가하거나 감소하고 있다고 결정하는 경우, 수신측 노드는 매니페스트 파일에서의 선택 항목들 중에서 보다 낮은 또는 보다 높은 비트 레이트의 비디오 세그먼트들을 요청하는 것을 자동으로 시작한다. 환언하면, 수신측 노드는 그가 요청하는 비디오 세그먼트들의 해상도를 변화시키는 것에 의해 시간의 경과에 따라 그의 실제 대역폭에 "적응"한다.
비디오 프레임의 "해상도"는 그의 폭 x 높이(예컨대, 1920 x 1080 또는 1080p)의 척도 또는 프레임 내의 픽셀들의 수인 반면, 그의 "비트 레이트"는 송신기로부터 수신기로 전송되는 초당 비트 수(bps)를 지칭한다. 예를 들어, 매초마다 30개의 1080p-해상도 비디오 프레임이 전달되고(30 fps(frames per second)) 각각의 컬러 픽셀이 24 비트를 포함하는(24 bpp(bits per pixel)) 경우, 비트 레이트는 거의 1.5 Tbps(1,492,992,000 bps - 즉, 1,492,992,000 = (1920 x 1080 ppf(pixels per frame)) x (24 bpp) x (30 fps) - 일 것이다.
표준의 비디오 코덱들은 보다 낮은 유효 비트 레이트들(예컨대, 3 Mbps)을 생성하기 위해 압축(예컨대, MPEG2 압축) 및 다른 비디오 인코딩 기법들을 이용한다. 이상의 내용을 고려하여, "비트 레이트"와 "해상도"는 보다 높은 또는 보다 낮은 해상도의 비디오 프레임들을 제공하는 것에 의해 유효 비트 레이트를 증가시키거나 감소시킬 수 있다는 점에서 높은 상관관계가 있다. 따라서, 이 용어들이 이와 관련하여 본원에서 얼마간 서로 바꾸어 사용될 수 있다.
WebRTC 및 적응적 스트리밍 표준들은 거의 모든 스마트폰 사용자가 실황 비디오 이벤트들을 포착하고 스트리밍할 수 있게 하고 또한 - 다른 개개의 스마트폰 사용자들로부터 다수의 비디오 콘텐츠를 호스팅하는 대규모 회사들까지에 이르는 - 이러한 사용자들이 다른 발신 지점으로부터 인터넷에 거쳐 발신되는 스트리밍 비디오 채널에 합류하게 할 수 있다. 그렇지만, 이 표준들은 점대점 비디오 스트리밍을 위해 설계되어 있고, 인터넷을 거쳐 많은 수의 동시 시청자들로 비디오 채널을 스트리밍하는 "비디오 전달" 문제를 해결하지 못한다.
이 문제를 해결하기 위해, 일부 비디오 스트리밍 회사들(예컨대, StreamRoot)은 전형적으로 비디오 콘텐츠가 하나의 시청측 노드로부터 다른 시청측 노드로 중계되는 "P2P(peer-to-peer)" 또는 메시 네트워크 토폴로지(때때로 "피어캐스팅(peercasting)"이라고 지칭됨)를 포함하는 접근법을 채택하였다. 비디오 스트리밍과 관련하여, 이 용어들은 시청측 노드들이 스트리밍 비디오 콘텐츠를 분산 방식으로 서로에게 중계할 수 있게 하는 인터넷 위에 구성된 오버레이 네트워크들을 지칭하기 위해 서로 바꾸어 사용될 수 있다. 그렇지만, 스트리밍 비디오를 많은 수의 동시 시청자들에 전달하는 것이, 예컨대, 파일 전송 또는 파일 공유 응용분야들에 대한, P2P 또는 메시 네트워크 토폴로지의 비스트리밍 사용들과 구별되어야만 한다.
P2P 비디오 스트리밍 시스템들은 비디오 콘텐츠 채널을 인터넷을 통해 단일의 발신 지점으로부터 많은 수의 동시 사용자들에 전달한다. 이러한 시스템들은, 그들의 분산된 특성이 (예컨대, 콘텐츠를 다른 노드들을 통해 재라우팅하는 것에 의해) 개개의 장애 지점들로부터의 복원을 용이하게 하고, 보다 많은 노드들이 네트워크에 추가되기 때문에(즉, 보다 많은 그리고 보다 나은 라우팅 "중계" 옵션들이 이용가능하게 되기 때문에) 그들의 신뢰성 및 성능이 실제로 개선된다는 점에서, 탄력성이 있기도 하고 확장성이 있기도 하는 경향이 있다.
새로운 노드들이 비디오 채널에 합류하거나 기존의 노드들이 채널을 떠날(시청하는 것을 중단함) 때, P2P 비디오 스트리밍 시스템들은 오버레이 네트워크의 토폴로지를, 어느 정도, 동적으로 재구성해야만 한다 - 즉, 새로운 노드들을 수용하기 위해 네트워크 노드들 간의 라우팅 경로들 중 적어도 일부를 수정해야만 한다 -. 예를 들어, 새로운 노드가 추가될 때, 새로운 노드가 비디오 콘텐츠를 수신할(그리고 중계할) 근방의 기존 노드들을 선택하기 위해 그의 지리적 위치가 고려될 수 있다.
그러나, "피어"노드들이 그들의 지리적 근접성에만 기초하여 선택되는 경우, 그들은 - 예컨대, 상이한 ASN들에 존재하는 경우 - 여전히 서로 비교적 "멀리 떨어져" 있을 수 있다(그리고 네트워크 근접성 내에 있지 않을 수 있음). 그 결과, 그들 사이의 트래픽은 하나 이상의 어쩌면 혼잡한 피어링 포인트들을 지나갈 수 있다. 예를 들어, 가까운 지리적 근접성 내에 있는 2개의 노드들 간의 실제 지연시간이 그 노드들 각각과 지리적으로 멀리 떨어진 노드 사이의 지연시간들의 합을 초과할지도 모른다. 이 현상은 때때로 "TIV(triangle inequality violation)"라고 지칭되며, 이는 디지털 콘텐츠를 ASN 피어링 포인트들을 거쳐 오버레이 네트워크의 노드들 사이에서 전달하기 위해 BGP 라우팅에 의존하는 것의 단점들을 나타낸다.
기존의 P2P 비디오 스트리밍 시스템들에서의 이 문제에 대한 하나의 이유는 그들이 인터넷의 기반이 되는 아키텍처와 "호환가능"하도록 구성되어 있지 않다는 것이다. 인터넷 위에 구축된 임의의 오버레이 네트워크 토폴로지는, 앞서 살펴본 무수히 많은 QoS 문제들과 같은, (새로운 노드들 또는 사라지는 노드들 이외의) 많은 차단 또는 장애 지점들의 영향을 여전히 받는다. 특히 ASN 피어링 포인트들에서, 인터넷의 기본적인 QoS 변동성을 해결하지 못하는 것에 의해, 이러한 시스템들은 그들의 사용자들에게 일관성있는 QoE를 제공함에 있어서 커다란 장애물들에 직면한다.
이와 같이, (GPS 네비게이션 시스템들과 같은) 기존의 P2P 비디오 스트리밍 시스템들은 피어 중계 노드(peer relay node)들을 선택하기 위해 (네트워크 근접성보다는) 지리적 근접성에 의존하고, 혼잡이 발생하면 "사후"에만 트래픽을 재라우팅한다. 더욱이, 동시 사용자들에게로의 선형 데이터의 실시간 스트리밍은 GPS 네비게이션 시스템들에서는 없는 부가의 제약조건 - 콘텐츠가 각각의 노드에 "동시에"도착해야만 함 - 을 부과한다. (보다 높은 속도의 경로들을 제공하기 위해 고속도로들 및 진출로들을 건설하는 것과 유사한) 에지 서버 및 다른 물리적 인프라스트럭처 접근법들은 비용이 많이 들고 또한 예정되지 않은 이벤트들 및 임의의 특정 이벤트의 높은 동시 사용률의 문제들을 적절하게 해결하지 못한다.
따라서, 앞서 논의된 단점들을 해결하고, 클라이언트 노드들에 일관성있는 QoE를 제공하기 위해, 오버레이 네트워크들을 생성하고 동적으로 재구성함에 있어서 (특히, 아주 많은 인터넷 트래픽이 흐르는 ASN 피어링 포인트들에서의) 인터넷의 기반이 되는 아키텍처를 고려하는 디지털 콘텐츠 전달 시스템이 필요하다.
본 발명에 따르면, 신규의 방법들 및 아키텍처들의 다양한 실시예들이, (1) 기반이 되는 네트워크의 컴포넌트들(예컨대, ASN들 및 그들을 상호연결시키는 피어링 포인트들)을 상호연결시키는 공유 링크들의 맵 - 컴포넌트들 중 하나의 컴포넌트 내의(예컨대, ASN 내의) 각각의 노드의 위치를 포함함 - 을 유지하는 것; (2) 기반이 되는 네트워크(인터넷) 위에 구축된 하나 이상의 오버레이 네트워크들을 따라 그 공유 링크들(ASN 피어링 포인트들)을 지나가는 노드들 사이의 네트워크 트래픽을 모니터링함으로써 메트릭들을 발생시키는 것; (3) 시간의 경과에 따라 변하는 공유 링크들(ASN 피어링 포인트들)의 용량을 반영하는 혼잡 레벨들을 예측하기 위해 시간의 경과에 따라 메트릭들 및 맵을 분석하는 것; 및 (4) 오버레이 네트워크들을 따라 클라이언트 노드들 사이의 디지털 콘텐츠의 최적의 경로들을 발생시키기 위해, 예측된 혼잡 레벨들에 기초하여, 오버레이 네트워크들의 토폴로지를 동적으로 재구성하는 것에 의해, 기반이 되는 네트워크(예컨대, 인터넷) 상의 노드들의 사용자들에게 일관성있는 QoE를 제공하는 디지털 콘텐츠 전달 시스템에 대해 개시되어 있다.
본 발명의 "가상 방송"시스템의 특정의 실시예들이 (에지 서버들 또는 다른 고가의 물리적 인프라스트럭처를 필요로 하지 않으면서) 하나 이상의 비디오 콘텐츠 채널들 - 각각의 비디오 콘텐츠 채널은 단일의 발신 지점으로부터 상이한 때에 채널에 합류할 수 있는 어쩌면 많은 수의 동시 시청자들로 실시간으로 스트리밍됨 - 의 시청자들에게 일관성있는 QoE를 제공하는 것과 관련하여 본원에 기술된다. 이하에서 보다 상세히 설명될 것인 바와 같이, 우리는 동시 사용자들에게로의 선형 콘텐츠의 유니캐스트 스트리밍과 관련하여 "가상 방송"이라는 용어를 사용한다. 사용자들의 관점에서 볼 때, 콘텐츠를 라우팅하기 위해 유니캐스트 스트리밍이 이용되지만, 사용자들이 콘텐츠를 "동시에" 수신한다는 점에서, 콘텐츠가 사용자들에게 "브로드캐스팅"된다. 본 발명의 다른 실시예들이, 네트워크 컴포넌트들 사이의 공유 링크들의 제한된 용량이 디지털 포맷으로 변환될 수 있는 임의의 유형의 정보의 라우팅을 제약하는 다수의 다른 상황들에서, 본 기술분야의 통상의 기술자에게 명백할 것이다.
본 명세서의 목적상, 다수의 상이한 채널들을 동시에 수신하는 단일의 노드는, 각각이 단일의 채널에 의해 정의되는, 개별적인 오버레이 네트워크들 상의 별개의 노드로 간주될 수 있다. VOD와 관련하여, 특정의 프로그램의 각각의 개별적인 "방영(showing)"은 그 자체의 시청측 노드들의 네트워크를 갖는 개별적인 채널로 간주될 수 있다.
본 발명의 시스템은 예정되지 않은 이벤트들은 물론 예정된 이벤트들을 핸들링하는 것, 실황 이벤트들은 물론 녹화된 이벤트들을 스트리밍하는 것, 그리고 - 인터넷의 QoS 변동성에 영향을 받는 인터넷 위에 구축된 오버레이 네트워크들에서 구현되고 있음에도 불구하고 - 많은 수의 동시 사용자들 간에 일관성있는 QoE를 유지하는 확장성이 높은 방식으로 그 이벤트들을 최소의 지연으로 실시간으로 스트리밍하는 것을 할 수 있다. (특히 임의의 주어진 ASN 내의) 동시 사용자들의 수가 증가함에 따라 시스템의 성능과 사용자들의 QoE가 실제로 개선된다.
클라이언트-서버 아키텍처는 서버측 라우팅 결정을 중앙집중화하는 데 이용된다. 비디오 콘텐츠의 분산 스트리밍 전달은 비디오 콘텐츠가 각각의 비디오 채널의 시청측 노드들 간에 중계(즉, 시청측 노드들로 "푸시")될 수 있게 하는 동적으로 재구성가능한 P2P 오버레이 네트워크들을 통해 이루어진다. 클라이언트 노드들은 비디오를 시청하거나 재생하기 위해 표준의 HTML5 비디오 플레이어들(대부분의 데스크톱 및 모바일 웹 브라우저들에 내장되어 있음)를 이용할 수 있고, 비디오 세그먼트들의 수신을 관리하는 것과 그 비디오 세그먼트들을 다른 노드들로 중계하는 것은 물론, 다양한 성능 메트릭들을 모니터링하는 것과 같은, 부가의 기능을 구현하기 위해 (Javascript와 같은) 커스텀 임베디드 코드에 의존한다. 다른 실시예들에서, 이러한 기능 중 일부 또는 전부가 커스텀 애플리케이션 또는 모바일 앱에 통합될 수 있다.
본 발명의 시스템은 데스크톱 및 모바일 웹 브라우저들 간의 "점대점" 비디오 스트리밍을 용이하게 하고, 보다 낮은 또는 보다 높은 비트 레이트의 비디오 세그먼트들을 자동으로 요청하는 것에 의해 노드 대역폭의 변화들에 적응한다. 일 실시예에서, 가상 방송 시스템은 웹 브라우저 플러그인들을 필요로 함이 없이 비디오 스트리밍을 용이하게 하기 위해 그리고 노드들이, 대역폭 및 CPU 용량과 같은, 그들의 수행 능력을 검출할 수 있게 하기 위해, WebRTC 및 적응적 스트리밍 표준들(HLS, MPEG-Dash 또는 Smooth Streaming 등)을 비롯한, 유니캐스트 표준들을 이용한다.
각각의 이벤트가, 다수의 동적으로 재구성가능한 오버레이 네트워크들을 통한 동시 사용자들에게로의 각각의 채널의 "발신 지점" 전달("point-of-origin" delivery)을 위해, 중앙 "가상 방송 서버"에 제공된다. 이벤트들은, 가상 방송 서버로 완전한 파일들로서 전송되든 실황으로 스트리밍되든 간에, 거의 모든 소스(CDN 포함)로부터 획득될 수 있다. WebRTC를 이용하는 실시예들에서, WebRTC를 구현하는 스마트폰을 갖는 임의의 사용자는, 오버레이 네트워크들을 통해 사용자들에 차후에 전달하기 위해, 녹화된 비디오 이벤트들을 업로드하거나 이벤트들을 실황으로 포착하여 가상 방송 서버에 업로드할 수 있다(또한 가상 방송 서버로부터 스트리밍되는 다른 채널들을 시청할 수 있음).
가상 방송 서버는, 일 실시예에서, 각각의 채널에 대한 발신 지점 - 이로부터 비디오 세그먼트들이 인터넷 위에 구축된 동적으로 재구성가능한 오버레이 네트워크들을 통해 전달됨 - 으로서 역할하는 "POI 콘텐츠 서버"를 포함한다. 비디오 세그먼트들은 전형적으로, 비디오 이벤트의 발신측 게시자(originating publisher)에 의해 결정되는 바와 같이, 크기가 고정되어 있다(예컨대, 1 내지 10초). 비디오 세그먼트들은 클라이언트 노드들에 의해 시청되고, 오버레이 네트워크들에 의해 정의된 경로들을 따라 노드에서 노드로 "푸시"(즉, WebRTC 표준에 따라 개별 고정 크기 "청크들"로서 중계)된다. 일 실시예에서, 각각의 비디오 세그먼트는 MPEG2 전송 프로토콜을 통해 스트리밍될 때 최대 효율을 위해 UDP 데이터그램 "패킷"의 크기와 일치하도록 64KB 청크들로 분할된다.
대부분의 경우에 비디오 세그먼트들이 각각의 클라이언트 노드로 효과적으로 푸시되지만, 일 실시예에서, 클라이언트 노드는 비디오 세그먼트의 청크들 모두가 제 시간에 도착하지 않았다는 것을 검출할 수 있고, (즉, "폴백" 피딩 위치("fallback" feeding location)인) POI 콘텐츠 서버에 비디오 세그먼트를 요청하기 위해 현재 매니페스트 파일을 이용할 수 있다.
각각의 노드가 POI 콘텐츠 서버에 의해 이용가능하게 되는 채널에 합류하려고 할 때, 노드는 (다른 실시예에서, 가상 방송 서버의 도움을 받아) 그 노드가 존재하는 특정의 ASN을 결정한다. 가상 방송 서버는, 이 ASN 피어링 포인트들에서의 혼잡 레벨들의 예측들에 기초하여 동적으로 재구성되는 오버레이 네트워크들 간의 채널 콘텐츠의 라우팅을 최적화하기 위해, 인터넷(ASN들 및 다양한 피어링 포인트 상호연결부들을 포함함)의 동적 "ASN 상호연결 맵" 및 다양한 모니터링된 성능 메트릭들과 함께, 이 "ASN 위치" 정보를 이용한다. 다른 실시예에서, 가상 방송 서버는 또한 이 프로세스를 돕기 위해, 각각의 노드의 ASN 위치에 부가하여, 각각의 노드의 지리적 위치를 이용한다.
일 실시예에서, 오버레이 네트워크들의 토폴로지들은 시청측 노드들 간의 비디오 세그먼트들의 라우팅 경로들을 정의하고, 채널의 각각의 비디오 세그먼트에 대해 (전체적으로 또는 부분적으로) 동적으로 재구성된다. 다른 실시예에서, 그들은 비디오 세그먼트의 각각의 청크에 대해 (전체적으로 또는 부분적으로) 동적으로 재구성된다. 이러한 방식으로, 비디오 채널의 각각의 비디오 세그먼트에 대한 최적의 라우팅 경로들을 결정함에 있어서 인터넷의 아키텍처(또한 ASN 피어링 포인트들에서의 예측된 혼잡 레벨들)가 고려된다. 다른 실시예에서, 오버레이 네트워크들을 따라 있는 경로들 중 일부 또는 전부가 (이러한 경로들이 최적이 아닐지라도) 비디오 세그먼트들을 제시간에 전달할 수 있는 경우, 이러한 경로들은, 미리 정의된 혼잡 문턱값이 충족되거나 다른 충분히 중대한 문제가 식별될 때까지, 재구성되지 않는다.
일 실시예에서, 클라이언트 노드들은, 예를 들어, 인터넷에 걸친 라스트 마일 문제들 및 QoS 문제들(ASN 피어링 포인트들에서의 혼잡을 포함함)은 물론, 가상 방송 시스템 자체의 하나 이상의 채널들의 동시 시청자들의 수로 인한 혼잡과 관련된 성능 문제들을 모니터링한다. 그들은 인터넷을 거쳐 그리고 ASN들을 거쳐 지정된 사이트들과 접촉하는 데 필요한 시간은 물론, 비디오 세그먼트들을 다른 노드들로 중계하는 데 필요한 시간을 모니터링한다. 클라이언트에 의해 모니터링된 메트릭들은 동적 라우팅 결정을 내리는 데 사용하기 위해 가상 방송 서버로 전달된다. 일 실시예에서, 가상 방송 서버는 표준의 WebSocket 프로토콜들을 통해 클라이언트 노드들과 통신하기 위해 "시그널링 서버(Signaling Server)"를 포함한다.
클라이언트 노드들은 임의로, 사용자들이 비디오 이벤트를 포착하여 가상 방송 서버에 실시간으로 업로드할 수 있게 하는, "업로더(Uploader)"를 포함한다. 임의의 클라이언트 노드로부터 가상 방송 서버로의 경로가 다수의 ASN들을 지나갈 수 있기 때문에, 비디오 이벤트의 스트리밍을 용이하게 하고 패킷들이 중간 라우터들에서 지연되거나 차단되는 것을 방지하기 위해 커스텀 "샤워링(showering)" 프로토콜이 사용된다. 일 실시예에서, 클라이언트 노드들은 또한 가상 방송 서버 상의 "스플래시 추출기(Splash Extractor)" 검색 엔진을 통해 "동향(trending)"이벤트들(본원에서 "스플래시(splash)들"이라고 지칭됨)를 검색하고 볼 수 있으며, 스플래시 추출기 검색 엔진은 스플래시들을 식별하고, 사용자 검색들에 기초하여, 사용자들이 그렇지 않았으면 POI 콘텐츠 서버를 통해 이용가능하게 되지 않을 동향 이벤트들을 인터넷을 통해 스트리밍하고 볼 수 있게 한다.
채널에 합류하라고 요청할 때, 노드들이 그들의 중계 능력 - 즉, 그들의 연결 유형(예컨대, 3G 또는 4G 셀룰러, WiFi, LAN 등)은 물론 그들의 CPU, 운영 체제 및 메모리 구성들과, 시간의 경과에 따라 모니터링되는 다른 고정된 그리고 가변적인 성능 메트릭들을 비롯한, 다양한 인자들로부터 추론되는, 그들의 신뢰할 수 있는 "업스트림" 대역폭 - 에 기초하여 가상 방송 서버에 의해 분류된다. 일 실시예에서, 노드들은 그들의 상대 중계 능력에 기초하여 3개의 레벨들로 분류된다. 최저 레벨 노드들("C" 노드들)은 비디오 세그먼트들을 시청할 수는 있지만 다른 노드들로 중계할 수는 없다. 중간 레벨 노드들("B" 노드들)은 비디오 세그먼트들을 시청할 수도 있고 ASN 내에서 중계할 수도 있다. 최고 레벨 노드들("A" 노드들)은 비디오 세그먼트들을 시청할 수 있고 ASN들 내의 다른 A 노드들로는 물론 ASN들을 거쳐 다른 A 노드들로 중계할 수 있다.
다른 실시예에서, 노드 분류들이, 예를 들어, 모니터링된 성능 메트릭들 및 주어진 분류의 보다 많은 또는 보다 적은 중계 노드들에 대한 시스템의 현재 요구사항들에 기초하여, 동적으로 변경될 수 있다. 그에 부가하여, 비디오 세그먼트들을 중계하기에 충분한 A 노드들이 ASN 내에 존재하는 경우, A 노드는, B 노드로 취급될 것이지만, 필요한 경우(예컨대, 기존의 A 노드들이 채널을 떠나는 경우) A 노드로 격상될 수 있다는 것을 나타내는, "B:A"노드로 지정될 수 있다. 일 실시예에서, 개별 노드가 (좋든 나쁘든 간에) 성능의 현저한 변화를 나타내는 경우, 노드가 (예컨대, B 노드로부터 C 노드로, 또는 그 반대로) 재분류될 수 있고, 문제가 해결될 때, 그의 초기 분류로 복원될 수 있다.
다른 실시예에서, 클라이언트 노드들이 비디오 세그먼트의 청크들을 다수의 다른 노드들로 중계하고 그들로부터 수신할 수 있게 하기 위해 클라이언트 노드들은 (예컨대, 그들의 능력 및 클라이언트 성능 메트릭들에 기초하여) 다수의 "슬롯들"을 할당받는다. 이 실시예에서, 클라이언트 노드들은 단지 하나의 "피딩"노드로부터 비디오 세그먼트를 수신하지만, 그 비디오 세그먼트를 다수의 다른 클라이언트 노드들에 "피드"하거나 중계할 수 있다. A 노드들은 최대 8개의 중계 슬롯들 - 4개는 동일한 ASN 내의 A 노드들로 중계하기 위한 것이고, 4개는 다른 ASN들에 있는 A 노드들로 -즉, ASN 피어링 포인트를 거쳐 - 중계하기 위한 것임 - 을 할당받는다. B:A 및 B 노드들은 그들의 ASN 내의 다른 클라이언트 노드들(즉, 다른 B:A, B 및 C 노드들)로 중계하기 위한 최대 8개의 슬롯들을 할당받는다. 다른 실시예에서, 클라이언트 노드는 다수의 다른 클라이언트 노드들에 의해 (예컨대, 다수의 착신 슬롯들에 청크들을 번갈아 나오게 하는 것에 의해) 피드될 수 있다. 이 기법은 보다 높은 성능이 요구되는 높은 비트 레이트(예컨대, 4K)의 비디오 스트림들에 대해 이용될 수 있다.
다른 실시예에서, 특정 노드들은 (예를 들어, 그들의 능력 및 클라이언트 성능 메트릭들에 기초하여) 단일의 피더 노드(feeder node)로부터 비디오 세그먼트의 다수의 해상도들을 수신할 수 있다(또는, 대안의 실시예에서, 상이한 피더 노드들로부터 상이한 해상도들을 수신할 수 있다). 이 노드들의 업스트림 대역폭이 충분한 경우, 그들은 "폴리캐스팅(polycasting)"노드들로 간주될 수 있고, 필요한 정도까지, 비디오 세그먼트의 그 다수의 해상도들을 하나 이상의 지정된 노드들에 중계하거나 피드할 수 있다.
오버레이 네트워크들의 동적 재구성을 용이하게 하기 위해, 가상 방송 서버는 ASN 피어링 포인트들에 걸쳐 혼잡 레벨을 예측하기 위해 - 즉, 짧은 시간(예컨대, 1분) 후의 ASN 피어링 포인트의 혼잡 레벨을 예측하기 위해 - 성능 메트릭들을 계속하여 분석하는 "딥 매퍼(Deep Mapper)" 딥 러닝 엔진(deep learning engine)을 이용한다. 일 실시예에서, A 노드들 사이의 - 예컨대, ASN 내의 하나의 A 노드로부터 다른 ASN 내의 A 노드로의 - 각각의 잠재적인 ASN간 경로(inter-ASN path)에 대해 예측된 "혼잡 값(congestion value)"이 발생된다. 다른 실시예에서, 혼잡 값은 각각의 A 노드들의 쌍 사이의 최적의 경로에 대한 예측된 혼잡 레벨을 반영한다.
일 실시예에서, 가상 방송 서버는 ASN간(inter-ASN) 및 ASN내(intra-ASN) 오버레이 네트워크들 둘 다를 발생시키고 (전체적으로 또는 부분적으로) 동적으로 재구성하기 위해 - 예컨대, ASN들 내에서뿐만 아니라 ASN들에 걸쳐 하나의 노드로부터 다른 노드로 푸시될 비디오 세그먼트들에 대한 최적의 경로를 결정하기 위해 - "오버레이 네트워크 생성기(Overlay Network Creator)"를 이용한다. 이 실시예에서, 오버레이 네트워크 생성기는 각각의 노드가 이용할 수 있는 이용가능한 슬롯들의 수는 물론, 각각의 노드가 수신하거나 중계할 수 있는 해상도들의 수를 고려한다.
오버레이 네트워크 생성기는, A 노드들의 토폴로지를 나타내는, ASN간 "가상 데이터 트렁크(Virtual Data Trunk)" 오버레이 네트워크를 (딥 매퍼의 도움을 받아) 발생시키고 동적으로 재구성한다. 환언하면, 오버레이 네트워크 생성기는 A 노드들 및 비디오 세그먼트가 ASN들 내의 그리고 (특히) ASN들에 걸쳐 있는 그 A 노드들 사이에서 - 즉, 어쩌면 혼잡한 ASN 피어링 포인트들을 통해 - 따라갈 링크들 또는 라우팅 경로들을 나타낸다.
가상 데이터 트렁크는 (ASN들 내에 있는 것은 물론 ASN들에 걸쳐 있는) (예컨대, 현재 매니페스트 파일을 사용하여) 근방의 POI 콘텐츠 서버에 각각의 비디오 세그먼트를 요청하라고 지시받을 A 노드들의 세트는 물론, 그들 각각이 비디오 세그먼트를 푸시할 A 노드들의 세트 등을 식별한다. 그 결과, 그 비디오 세그먼트는 시청측 노드를 포함하는 모든 ASN에 걸쳐 확산될 것이다. 각각의 시청측 노드에 도달하기 위해, 세그먼트는 또한 시청측 노드들을 갖지 않는 중간 사설 백본 ASN들을 거쳐 이동할 수 있다.
오버레이 네트워크 생성기는 또한, ASN 내의 A 노드들로부터 그 ASN 내의 B:A, B 및 C 노드들로 비디오 세그먼트를 중계하기 위해, 하나 이상의 ASN내 "스웜(Swarm)" 오버레이 네트워크들을 발생시킨다. 이 스웜 오버레이 네트워크들은 각각의 비디오 세그먼트에 대해(또는, 대안의 실시예에서, 비디오 세그먼트의 각각의 청크에 대해) (전체적으로 또는 부분적으로) 동적으로 재구성될 수 있다. 일 실시예에서, ASN 내의 각각의 스웜 오버레이 네트워크는 비디오 세그먼트를 수신하고, 시청하며 그 스웜 계층구조 내의 노드들 사이에서 중계(C 노드들은 제외)하는 B:A, B 및 C 노드들의 (ASN 내의 A 노드에 대한) 계층적 토폴로지를 나타낸다.
따라서, 본 발명의 가상 방송 시스템 및 방법은, 이러한 주요 혼잡 지점들에서의 혼잡 레벨들의 예측들에 기초하여 동적으로 재구성되는 가상 데이터 트렁크 및 스웜 오버레이 네트워크들의 노드들 사이에서의 디지털 콘텐츠의 라우팅을 최적화하기 위해 네트워크 트래픽을 모니터링하고 분석하는 것에 의해 ASN 피어링 포인트들 및 다른 주요 혼잡 지점들에서의 제한된 용량을 효율적으로 사용하고, 그로써 시스템 사용자들 간에 일관성있는 QoE를 유지한다.
도 1은 인터넷 위에 동적으로 구성된 본 발명의 오버레이 네트워크들의 일 실시예를 나타내는 그래프;
도 2는 본 발명의 클라이언트 스트리밍 비디오 디바이스의 주요 클라이언트측 컴포넌트들의 일 실시예를 나타낸 블록도.
도 3은 본 발명의 가상 방송 서버의 주요 서버측 컴포넌트들의 일 실시예를 나타낸 블록도.
도 4는 본 발명의 동적 비디오 스트리밍 프로세스의 일 실시예를 나타낸 플로차트.
도 2는 본 발명의 클라이언트 스트리밍 비디오 디바이스의 주요 클라이언트측 컴포넌트들의 일 실시예를 나타낸 블록도.
도 3은 본 발명의 가상 방송 서버의 주요 서버측 컴포넌트들의 일 실시예를 나타낸 블록도.
도 4는 본 발명의 동적 비디오 스트리밍 프로세스의 일 실시예를 나타낸 플로차트.
본 발명의 시스템들 및 방법들의 상세한 실시예들이 첨부 도면들에 예시되고 이하에서 기술된다. 먼저 본 발명이 도면들을 참조하여 이하에서 논의되는 특정의 실시예들로 제한되지 않는다는 것에 유의해야 한다.
앞서 살펴본 바와 같이, 본 발명의 특정의 적용분야가 인터넷을 통해 스트리밍 비디오를 많은 수의 동시 사용자들에 전달하는 것과 관련하여 본원에 기술되어 있지만, 본 발명의 원리들이 네트워크 컴포넌트들 사이의 공유 링크들의 제한된 용량이 임의의 유형의 디지털 콘텐츠의 라우팅을 제약하는 다수의 다른 상황들에서 똑같이 적용된다.
인터넷을 통해 스트리밍 비디오를 전달하는 것과 관련해서도, 본원에 기술되는 클라이언트 노드들과 서버 컴포넌트들 사이의 기능의 할당은 설계 절충안들의 결과이며, 이 기능의 상당 부분은 본 발명의 사상을 벗어남이 없이 클라이언트측 컴포넌트들과 서버측 컴포넌트들 간에 재할당될 수 있다. 이와 유사하게, 클라이언트측 기능이 단일의 모듈식 컴포넌트에 할당되거나 다수의 상이한 컴포넌트들에 걸쳐 분산될 수 있고, 하나 이상의 독립형 애플리케이션들 또는 모바일 앱들로서, 또는 독립형 애플리케이션들 또는 앱들과 Javascript 또는 다른 스크립팅 또는 프로그래밍 언어들의 조합으로서 구현될 수 있다. 더욱이, 서버측 컴포넌트들은 단일의 하드웨어 서버 상에, 또는 다수의 상이한 서버들에 걸쳐 구현될 수 있다. 이러한 기능은 또한 단일의 소프트웨어 모듈에 통합되거나 하나 이상의 하드웨어 서버들에 걸쳐 분산된 상이한소프트웨어 모듈들 간에 할당될 수 있다.
마지막으로, 표준의 프로토콜들 및 라이브러리들(예컨대, HTTP, WebSocket, WebRTC, STUN 및 다양한 적응적 스트리밍 표준들)이 이용되는 그 실시예들에서, 이러한 표준의 프로토콜들 및 라이브러리들 중 일부 또는 전부에 의해 제공되는 기능이, 본 발명의 사상을 벗어나지 않으면서, 다른 표준의 또는 독점적 구현들로 대체될 수 있다.
오버레이 네트워크
도 1은 인터넷 위에 매핑된 본 발명의 오버레이 네트워크들(100)의 일 실시예를 나타내는 그래프이다. 인터넷 자체가 무수히 많은 상이한 방식들로 예시될 수 있지만, 도 1은 인터넷을, 피어링 포인트들(120)을 통해 상호연결된, ASN(110) 광섬유 링들의 세트로서 예시하고 있다. 임의의 시점에서 특정의 비디오 채널을 시청하는 개개의 클라이언트 노드들이 각각의 ASN(110) 내부에 예시되어 있다. 비록 도 1에 도시되어 있지는 않지만, 다수의 채널들, 그리고 따라서 다수의 오버레이 네트워크들(100)의 세트들이 (일 실시예에서) 동시에 활성일 수 있다.
앞서 살펴본 바와 같이, 가상 데이터 트렁크 오버레이 네트워크는, ASN(110)(직접 연결됨) 내에 있는 것은 물론 (즉, 피어링 포인트들(120)을 통해) ASN들(110)을 거치는, A 노드들(130) 사이의 상호연결들(175)을 나타낸다. 백본 커넥터(195)는, 어떤 상업적 노드들도 포함하지 않고 2개의 공공 ASN들(110)을 상호연결시키기만 하는 사설 ASN(도시되지 않음)을 통한, 2개의 ASN들(110) 사이의 A 노드들의 상호연결부를 나타낸다. 예를 들어, 백본 커넥터(195)는 ASN(110-f) 내의 A 노드(130)를 ASN(110-e)의 A 노드(130)와 연결시키는 것으로 도시되어 있다. 이 시나리오에서, 이 2개의 A 노드들(130) 사이의 트래픽은 다수의 "사설" 피어링 포인트들(120)(또는 사설 ASN들과의 다른 독점적 연결들)를 통해 이동할 수 있다.
앞서 언급된 바와 같이, 일 실시예에서, 2개의 상이한 공공 ASN들(110) 내의 A 노드들(130) 사이의 (즉, 피어링 포인트(120)를 통한) 연결들(175)의 경우와 같이, 이러한 연결들의 성능이 종단점들(즉, 2개의 A 노드들(130))에서만 모니터링될 수 있다. 동일한 ASN(110) 내의 2개의 A 노드들(130) 사이의 연결(175)을 따라가는 트래픽은, 어쩌면 혼잡한 피어링 포인트(120)를 통과하지 않기 때문에, ASN들(110)을 거치는 트래픽보다 비교적 더 빠를 가능성이 있을 것이다. A 노드들(130)로의/로부터의 백그라운드 커넥터(195) 및 연결들(175)이 단방향 화살표들로 예시되어 있지만, 이들은, 도 1에 예시된 모든 클라이언트 노드들 사이에서 양방향 연결이 지원된다는 사실에도 불구하고, 현재 단방향 라우팅 경로들만을 반영한다.
본 발명의 임의의 2개의 클라이언트 노드들 사이의 모든 트래픽이 공공 인터넷을 거쳐 가고, 따라서 QoS에 영향을 미치는 다양한 중간 라우터들(도시되지 않음)을 통과한다는 것에 유의해야 한다. 시스템은 ASN(110) 내에서는 물론 ASN들(110)(그리고 따라서 하나 이상의 피어링 포인트들(120))에 걸친 QoS 효과들을 모니터링한다. 일 실시예에서, 이러한 ASN내 및 ASN간 트래픽은 (가상 방송 서버의 지시에 따라) 각각의 클라이언트 노드에 의해 모니터링되고, (A 노드들(130) 사이의 가상 데이터 트렁크 오버레이 네트워크 및 ASN(110) 내의 각각의 A 노드(130)로부터 그 ASN(110) 내의 B(및 B:A) 노드들(140) 및 C 노드들(150)로의 스웜 오버레이 네트워크들을 비롯한) 오버레이 네트워크들(100)이 나타내는 노드들 및 라우팅 경로들의 동적 재구성을 위해 가상 방송 서버로 전달된다.
도 1은, 이 오버레이 네트워크들(100)의 "현재 상태"가 주어진 경우, 클라이언트 노드들 사이에서 비디오 세그먼트가 따라가는 다양한 라우팅 경로들을 나타낸다. 환언하면, 도 1은, 일 실시예에서, 각각의 비디오 세그먼트에 대해(그리고, 대안의 실시예에서, 비디오 세그먼트의 각각의 청크에 대해) 동적으로 재구성될 수 있는 이 오버레이 네트워크들(100)의 현재 토폴로지를 예시한다. 임의의 특정 비디오 세그먼트에 대해, 오버레이 네트워크들(100)이 (전체적으로 또는 부분적으로) 재구성될 수 있거나 그렇지 않을 수 있는데, 그 이유는 이 결정이 시간의 경과에 따라 수집된 성능 메트릭들에 적어도 부분적으로 의존할 것이기 때문이라는 것에 유의해야 한다.
ASN(110-c)은, POI 콘텐츠 서버(도시되지 않음)가 ASN(110-c)에 또는 근방에(예컨대, 하나 또는 2개의 다른 ASN들(110)을 거쳐) 존재하고, 오버레이 네트워크들(100)을 따라 한 채널을 통해 비디오 세그먼트들의 스트리밍을 개시하기 위해 현재 비디오 세그먼트를 A 노드(130-a)로 전달하라는 HTTP 요청에 응답하는 시나리오를 나타낸다. 이하에서 보다 상세히 논의될 것인 바와 같이, POI 콘텐츠 서버는 전형적으로 각각의 비디오 세그먼트를 동일한 또는 근방의 ASN(110) 내의 다수의 요청측 A 노드들(130)에 전달할 것이고, 이 A 노드들(130)은 차례로 비디오 세그먼트를 오버레이 네트워크들(100)을 따라 다수의 다른 노드들로 푸시할 것이며, 그 결과 임의의 주어진 시점에서 클라이언트 노드들에 전달되고 그들로부터 중계되는 비디오 세그먼트들의 청크들의 다수의 동시 사본들의 "재배포"가 있게 된다.
이 시나리오에서, A 노드(130-a)는 비디오 세그먼트를 2개의 다른 A 노드들(130) - 하나는 ASN(110-c) 내에 있고 다른 하나는 피어링 포인트(120)를 거쳐 ASN(110-a) 쪽에 있음 - 로 중계한다. 앞서 살펴본 바와 같이, 가상 데이터 트렁크 오버레이 네트워크는 비디오 세그먼트가 ASN들(110) 내에서 그리고 ASN들(110)을 거쳐 A 노드들(130) 간에 중계될 때 따라가는 라우팅 경로들을 나타낸다. 이와 같이, 이 시나리오에서, 비디오 세그먼트는 ASN(110-c) 내의 다수의 A 노드들(130) 사이에서뿐만 아니라, ASN(110-a)으로부터 다양한 피어링 포인트들(120)을 거쳐 다수의 직접 상호연결된 ASN들(즉, 110-a, 110-d, 110-f 및 110-g)로 중계되고, 이들로부터 비디오 세그먼트는 가상 데이터 트렁크 오버레이 네트워크의 다수의 홉(hop)들을 거쳐 다른 ASN들(110)로 추가로 중계된다.
이하에서 보다 상세히 설명될 것인 바와 같이, ASN(110) 내에서 요구되는 A 노드들(130)의 수는, 그 ASN(110) 내의 다른 클라이언트 시청측 노드들의 수는 물론 (그들의 분류, 열린 슬롯(open slot)들의 수 및 시간의 경과에 따라 모니터링된 성능 메트릭들에 의해 결정되는 바와 같은) 그들의 상대 능력과 같은, 다양한 인자들에 의존할 것이다. 예를 들어, ASN들(110-b, 110-f, 110-i 및 110-j) 각각이 단일의 A 노드(130)만으로 예시되어 있지만, 그들은 피드할 상이한 수의 다른 클라이언트 노드들을 갖는다(ASN(110-f) 내의 단일의 다른 노드와 ASN(110-i) 내의 다수의 다른 노드들을 비교).
노드의 모니터링된 업스트림 대역폭이 몇 개의 노드들에 직접 피드할 것인지(즉, 몇 개의 발신 슬롯(outgoing slot)들이 사용될 것인지)를 결정함에 있어서의 주요 인자이지만, 이 중계들이 얼마나 신속하게 수행되는지(전형적으로 1ms 미만)가 주어지면 (비디오 세그먼트를 하나의 노드로부터 다음 노드로, 이하 마찬가지로 중계하는) ASN(110) 내의 노드들의 "체인(chain)"의 길이가 크게 관련이 없다는 것을 인식하는 것이 중요하다. 예를 들어, 외부 ASN들(110)(ASN(110-g) 및 ASN(110-j)) 내의 2개의 A 노드들은 물론 ASN(110-1) 내의 2개의 B 노드들(130)에 직접 피드하는, ASN(110-i) 내의 단일의 A 노드는 4개의 발신 슬롯들을 사용한다(이 실시예에서, 비교적 높은 모니터링된 업스트림 대역폭을 반영함). 그러나, ASN(110-i) 내의 단일의 A 노드로부터 간접적으로 피드되는 B 노드들(140)과 C 노드들(150)의 긴 체인은 그의 업스트림 대역폭의 반영이 아니다.
각각의 ASN(110) 내에, 비디오 세그먼트를 그 ASN (110) 내에서 각각의 A 노드(즉, 스웜 오버레이 네트워크의 "루트"노드)로부터 그 스웜 오버레이 네트워크 내의 다양한 B(및 B:A) 노드들(140) 및 C 노드들(150)로 중계하기 위해 하나 이상의 스웜 오버레이 네트워크들이 발생된다(이 실시예에서, 각각의 비디오 세그먼트에 대해 동적으로 재구성됨). (ASN(110-h)에 예시된 2개의 스웜 오버레이 네트워크들과 비교하여) 단지 하나의 스웜 오버레이 네트워크가 ASN(110-c)에 예시되어 있지만, 각각의 ASN(110) 내에 발생된 스웜 오버레이 네트워크들의 수(그리고 각각의 스웜 오버레이 네트워크의 내부 토폴로지)는 그 ASN(110) 내의 클라이언트 시청측 노드들의 수는 물론 현재 및 과거의 성능 메트릭들, 열린 슬롯들의 수 등과 같은, 다양한 인자들에 의존할 것이다.
앞서 살펴본 바와 같이, ASN(110-b) 내의 A 노드(130-b)와 같은, 클라이언트 노드는 다수의 다른 클라이언트 노드들로부터(이 경우에, 상이한 ASN들(110-a 및 110-d) 내의 2개의 다른 A 노드들(130)로부터) 비디오 세그먼트를 수신할 수 있다. 일 실시예에서, 이 2개의 다른 피딩 노드들은 성능 이유로 비디오 세그먼트의 청크들을 A 노드(130-b)로 송신하는 것을 교대로 행한다 - 예컨대, 그 이유는 이 청크들이, 보다 상세히 설명될 것인 바와 같이, 혼잡 레벨들이 연속적으로 모니터링되는 피어링 포인트들(120)을 거치기 때문이다 -. 다른 실시예들에서, 이것이 중복성을 위해 행해질 수 있다 - 예컨대, 그 이유는 (피어링 포인트들(120)의 혼잡과는 별도로 또는 그에 부가하여) 과거의 성과 메트릭들에 기초하여 피딩 노드들의 신뢰성이 의심스러울 수 있기 때문이다 -.
성능 메트릭들이 모니터링되고, 비디오 세그먼트들이 중계되며, 오버레이 네트워크들(100)이 동적으로 재구성되는 방법들은, 이 방법들을 구현하는 주요 클라이언트측(도 2) 및 서버측(도 3) 기능 컴포넌트들의 논의 이후에, 도 4와 관련하여 이하에서 보다 상세히 탐구된다.
클라이언트 스트리밍 비디오 디바이스
도 2를 참조하면, 클라이언트 디바이스(200)는 본 발명의 클라이언트 스트리밍 디바이스의 주요 컴포넌트들의 일 실시예를 나타낸다. 클라이언트 디바이스(200)는 데스크톱 또는 랩톱 컴퓨터는 물론, 스마트폰 또는 다른 모바일 디바이스, 또는, 스트리밍 비디오와 같은, 스트리밍 콘텐츠를 핸들링할 수 있는 거의 모든 다른 소비자 전자 디바이스로서 구현될 수 있다. 클라이언트 디바이스(200)는, 본 기술분야에 널리 공지되어 있는, CPU(212), 메모리(214), 운영 체제(216), 네트워크 어댑터(217), 디스플레이(218) 및 카메라(219)를 비롯한, 어떤 표준의 하드웨어 및 소프트웨어 컴퓨팅 컴포넌트들 및 관련 주변기기들(210)을 포함한다. 클라이언트 디바이스(200)는 네트워크 노드가 되기 위해 그리고 스트리밍 비디오 콘텐츠를 수신하고, 디스플레이하며 본 발명의 가상 방송 시스템의 다른 네트워크 노드들 사이에서 중계하기 위해, 어떤 표준의 라이브러리들(220)과 함께, 이 컴포넌트들 및 주변기기들(210)을 이용한다.
본 발명은 디바이스들 사이에서 비디오 콘텐츠를 스트리밍하는 것을 용이하게 하기 위해 이용될 수 있는 네트워크 프로토콜들 및 다른 기능을 구현하는 어떤 표준의 라이브러리들(220)(대부분의 스마트폰들은 물론 많은 다른 컴퓨팅 디바이스들에도 있음)을 이용한다. 예를 들어, 어떤 플러그인들도 필요로 함이 없이 비디오 콘텐츠가 2명의 스마트폰 사용자들 사이에서 스트리밍되고 그들의 모바일 웹 브라우저들 상에 디스플레이될 수 있다. 표준의 라이브러리들(220)은 (비디오 콘텐츠를 스트리밍하기 위한 브라우저간 통신을 용이하게 하는) WebRTC(222) API들, (클라이언트 대역폭 및 CPU 용량의 변화들의 실시간 검출에 "적응"하기 위해 스트리밍 비트 레이트들의 자동 조정을 가능하게 하는), 그 중에서도 특히, HLS, MPEG-Dash, 및 Smooth Streaming과 같은, 다양한 적응적 스트리밍(224) 구현들, (단일의 TCP/IP 연결을 통한 고속 양방향 클라이언트-서버 통신을 용이하게 하는) WebSocket(226) 프로토콜, 및 (웹 서버들과 클라이언트 웹 브라우저들 사이의 덜 빈번한 표준의 통신을 위한) HTTP(228)를 포함한다.
클라이언트 디바이스(200)는 또한 스트리밍 디지털 콘텐츠를 시청하거나 재생하기 위해 표준의 플레이어(232)(일 실시예에서, 표준의 HTML5 웹 브라우저(230)에 통합된 표준의 비디오 플레이어)를 포함한다. 다른 실시예들에서, 표준의 플레이어(232)는 독립형 데스크톱 애플리케이션 또는 스마트폰 앱에 통합되어 있다. 표준의 HTML5 웹 브라우저(230)를 이용하는 것의 하나의 장점은 표준의 라이브러리들(220) 중 다수가 웹 브라우저들에서 작동하도록 설계되어 있고 따라서 독립형 데스크톱 애플리케이션 또는 스마트폰 앱을 필요로 할 어떤 플러그인들 또는 다른 커스텀 기능을 필요로 하지 않는다는 것이다.
더욱이, 웹 브라우저들은 또한 (어떤 클라이언트 브라우저 플러그인들도 필요로 함이 없이, 예를 들어, 웹페이지의 일부로서 표준의 웹 서버로부터 전달되는) 표준의 웹 브라우저 기능을 보완하기 위해 자주 사용되는, Javascript와 같은, 클라이언트측 스크립팅 언어들을 지원한다. 일 실시예에서, 클라이언트 디바이스(200)의 비표준의 주요 컴포넌트들(통신기(Communicator)(270), 성능 모니터(240), 수신기(250), 중계기(Relayer)(260) 및 업로더(Uploader)(280)를 포함함)은 Javascript로 구현되고, 콘텐츠 어레이들(255)은 그 Javascript 코드에 의해 발생되고 유지된다. 그렇지만, 이 컴포넌트들 중 일부 또는 전부가 본 발명의 사상을 벗어남이 없이 다른 프로그래밍 언어들로 그리고 독립형 데스크톱 애플리케이션들 또는 스마트폰 앱들로 구현될 수 있다는 것에 유의해야 한다.
표준의 라이브러리들(220)은, 비디오 콘텐츠를 비롯한, 콘텐츠의 일반 점대점(유니캐스트) 스트리밍을 용이하게 한다. 클라이언트 디바이스(200)의 비표준의 주요 컴포넌트들은 본 발명의 가상 방송 시스템에 의해 구현되는 디지털 콘텐츠 전달 아키텍처의 클라이언트측 측면들을 해결한다. 일 실시예에서, 스트리밍 프로토콜은 콘텐츠의 라우팅이 클라이언트-서버 아키텍처를 통해 중앙집중화되는 WebRTC(222) 위에 구축되고, 콘텐츠 자체는 동적으로 재구성가능한 P2P 오버레이 네트워크들을 통해 분산 방식으로 스트리밍(노드로부터 노드로 푸시)된다.
클라이언트 디바이스(200)의 사용자는 먼저 각종의 상이한 방식들로 - 예컨대, 이메일에서의 또는 웹페이지 상의 링크들을 통해, 또는 심지어 독립형 데스크톱 애플리케이션 또는 스마트폰 앱 내로부터 - 하나 이상의 콘텐츠 채널들을 만날 수 있다. 일 실시예에서, 가상 방송 서버(300)(도 3과 관련하여 이하 보다 상세히 논의됨)는 채널들의 모음을 갖는 표준의 HTML5 웹페이지를 HTML5 웹 브라우저(230)에 전달한다. 이 "채널 웹페이지"는, (예컨대, WebRTC(222) 및 적응적 스트리밍(224) 라이브러리들을 사용하여) 시그널링 서버(330)와는 물론 다른 클라이언트 노드들과 통신하는 것은 물론, 비디오 세그먼트들의 청크들을 이러한 노드들로부터 수신하고, 처리하며 이러한 노드들로 중계하는 것을 포함하는, 클라이언트 디바이스(200)의 비표준의 컴포넌트들의 기능을 구현하기 위해 HTML5 웹 브라우저(230)에 의해 해석되는 독점적 Javascript 코드를 포함한다.
채널 웹페이지 내의 채널 링크를 클릭할 때, 사용자는 현재 스트리밍되고 있는 특정의 비디오 콘텐츠 채널에 합류하라는 요청을 발생시키거나, 다른 실시예에서, 나중의 미리 정의된 시점("합류 요청")에서 스트리밍하기 시작할 것이다. 가상 방송 서버(300)의 시그널링 서버(330)는 합류 요청에 대해 통신기(270)를 통해 클라이언트 디바이스(200)와 WebSocket(226) 연결을 구축하려고 시도하는 것으로 응답한다. 도 3과 관련하여 이하에서 보다 상세히 논의될 것인 바와 같이, 가상 방송 서버(300)는, 클라이언트 디바이스(200)가 비디오 콘텐츠를 수신하고 중계하기 위해 가상 방송 서버(300)와 WebSocket(226) 연결을 그리고 다른 클라이언트 디바이스들(200)과 WebRTC(222) 연결들을 구축할 수 있도록, (예컨대, NAT 방화벽 안쪽에 있는) 클라이언트 디바이스(200)의 공공 IP 주소를 발견하기 위해 "STUN"(322) 프로토콜을 이용한다.
본원에서 논의되는 실시예들에서, 클라이언트 디바이스(200)는 임의의 주어진 때에 단지 하나의 비디오 채널에 합류한다. 다른 실시예들에서, 클라이언트 디바이스(200)는 본 발명의 사상을 벗어남이 없이 다수의 채널들에 동시에 합류할 수 있다.
클라이언트 디바이스(200)는 단일의 TCP/IP 연결을 열린 채로 유지하면서 메시지들의 신속한 교환을 용이하게 하기 위해 시그널링 서버(330)와의 양방향 통신을 위한 통신기(270)를 이용한다. 이하에서 보다 상세히 논의될 것인 바와 같이, 이러한 통신은, (i) 클라이언트 디바이스(200) 능력(예컨대, OS, 웹 브라우저 및 연결 유형 - 3G, 4G, WiFi, LAN 등)에 관한 초기 정보를 가상 방송 서버(300)에 제공하는 것, (ii) 가상 방송 서버(300)가 오버레이 네트워크들(100)을 통한 비디오 세그먼트들의 후속하는 WebRTC(222) 노드간 스트리밍을 위한 클라이언트 노드 연결을 검증할 수 있게 하는 것, 및 (iii) 가상 방송 서버(300)와 실시간 동적 모니터링 정보(이하에서 논의되는 바와 같이, 성능 모니터(240)를 통해 획득됨)를 교환하는 것을 비롯한, 다양한 목적들을 위해 이용된다.
일 실시예에서, 채널 웹페이지에 포함된 이 Javascript 코드는 또한 클라이언트 디바이스(200)가 (비디오 세그먼트들을 수신하지만, 그들을 다른 클라이언트 노드들로 중계하지 않는) C 노드인지를 결정하기 위해 클라이언트 디바이스(200)의 능력을 분석하고, 이 정보를 시그널링 서버(330)에 제공한다. 다른 실시예들에서, 클라이언트 디바이스(200)의 어떤 능력이, 클라이언트 디바이스(200)가 C 노드인지를 결정하는, 가상 방송 서버(300)로 송신된다.
이 Javascript 코드는 또한 표준의 플레이어(232)에 의한 재생을 위해 수신기(250)에 의한 비디오 세그먼트들의 수신을 관리하기 위해 POI 콘텐츠 서버(380)와의 통신을 용이하게 한다. 이 프로세스는, 사실상, 표준의 WebRTC(222) 및 적응적 스트리밍(224) 기능을 이용하는, 표준의 점대점 비디오 스트리밍 시나리오의 확장이다.
일 실시예에서, 표준의 웹 브라우저(230)는 앞서 기술된 바와 같이 주기적으로 매니페스트 파일들을 요청하기 위해 채널 웹페이지로부터의 독점적 Javascript 코드를 해석한다. 이러한 표준의 HTTP 요청들은, 매니페스트 파일들을 제공하는, POI 콘텐츠 서버(380)로 보내진다. 표준의 웹 브라우저(230)는 또한, 앞서 논의된 바와 같이(예컨대, 대역폭의 변화가 검출될 때) 이 비디오 세그먼트들의 보다 높은 또는 보다 낮은 비트 레이트의 버전들을 비롯한, 비디오 세그먼트들 자체를 매니페스트 파일에 명시된 위치들에 요청하기 위해 표준의 적응적 스트리밍(224) 라이브러리들을 이용한다.
비디오 세그먼트들에 대한 이 요청들은 채널 웹페이지로부터의 독점적 Javascript 코드에 의해 가로채기된다 - 즉, 그 이유는 각각의 비디오 세그먼트가 오버레이 네트워크들(100)의 다른 (피더(feeder)) 노드로부터 클라이언트 디바이스(200)로 푸시되기 때문이다(클라이언트 디바이스(200)가 HTTP "풀(pull)" 요청을 개시할 필요가 없게 함). (이하에서 보다 상세히 논의되는) 일 실시예에서, 가상 방송 서버(300)는, 클라이언트 디바이스(200)가 가능한 한 빨리 비디오 콘텐츠를 재생하기 시작할 수 있게 하기 위해 하나 이상의 초기 비디오 세그먼트들이 클라이언트 디바이스(200)에 푸시되도록, 합류 요청이 수신된 직후에 클라이언트 디바이스(200)를 오버레이 네트워크들(100)에 (그리고 따라서 채널에) 추가한다.
수신기(250)가 각각의 비디오 세그먼트의 청크들을 수신할 때, 수신기(250)는 비디오 세그먼트들의 수신 및 재생은 물론, 비디오 세그먼트들을 (클라이언트 디바이스(200)가 C 노드로 지정되지 않은 경우) 다른 클라이언트 노드들로 중계하는 것을 용이하게 하기 위해 콘텐츠 어레이들(255)을 발생시킨다. 수신기(250)는 청크들을, 표준의 플레이어(232)에 의해 유지되는 3-세그먼트 버퍼에 제공되는, 완전한 비디오 세그먼트로 편집하기 위해 수신 어레이(256)를 발생시킨다. 비디오 세그먼트에 대한 HTTP 요청을 가로채기할 때, 수신기(250)가 완전한 비디오 세그먼트가 수신 어레이(256)에 아직 없다고 결정하면, 비디오 세그먼트가 매니페스트 파일에 명시된 대체(또는 "폴백") 위치(즉, POI 콘텐츠 서버(380))에 요청될 것이다. 표준의 플레이어(232)의 관점에서 볼 때, 표준의 플레이어(232)는 표준의 HTTP 요청들에 응답하여 비디오 세그먼트들을 수신하고, 비디오 세그먼트들이 실제로는 오버레이 네트워크들(100)을 통해 클라이언트 디바이스(200)에 푸시되고 있다는 것을 알지 못한다.
더욱이, 일 실시예에서, 수신기(250)는 또한 (표준의 플레이어(232)가 매니페스트 파일을 통해 통상의 방식으로 이러한 요청을 하는지에 관계없이) 클라이언트 디바이스(200)가 핸들링할 수 있는 비트 레이트를 (통신기(270)를 통해) 시그널링 서버(330)에 전달하기 위해 적응적 스트리밍(224) 라이브러리들을 이용한다. 예를 들어, 클라이언트 디바이스(200)가 자신의 대역폭의 일시적인 상당한 저하를 경험하면(그 결과 비디오 세그먼트가, 필요하게 되기 전에, 수신 어레이(256)로 도착하지 않음), 클라이언트 디바이스(200)는 하나의 (폴백) 비디오 세그먼트를 POI 콘텐츠 서버(380)에 요청하고, 이어서 오버레이 네트워크들(100)을 통해 후속하는 보다 낮은 해상도의 비디오 세그먼트들을 푸시받을 수 있다. 그의 비트 레이트가 정상으로 돌아오면, 클라이언트 디바이스(200)는 문제가 발생하기 전과 마찬가지로 보다 높은 해상도의 비디오 세그먼트들을 푸시받을 수 있다.
앞서 살펴본 바와 같이, 일 실시예에서, 가상 방송 서버(300)는, (ASN들 내에서 그리고 ASN들을 거쳐 A 노드들 사이의) 가상 데이터 트렁크 오버레이 네트워크들 및 (ASN 내의 각각의 A 노드로부터 그 ASN 내의 다른 노드들로의)스웜 오버레이 네트워크들을 비롯한, 각각의 비디오 세그먼트에 대한 오버레이 네트워크들(100)을 동적으로 재구성한다. 클라이언트 디바이스(200)가 (비디오 세그먼트들을 수신하지만 그들을 다른 클라이언트 노드들로 중계하지 않는) C 노드로 분류되지 않는 한, 중계기(260)는 자신이 그 비디오 세그먼트를 중계할 노드 또는 노드들에 관해 (그가 합류한 비디오 채널의 각각의 비디오 세그먼트에 관련한) 지시들을 가상 방송 서버(300)로부터 수신할 것이다. 도 1을 참조하여 앞서 논의된 바와 같이, 클라이언트 디바이스(200)가 A, B:A 또는 B 노드인지에 관계없이, 클라이언트 디바이스(200)는 비디오 세그먼트를 다수의 다른 클라이언트 노드들로 중계하도록 요구받을 수 있다.
비디오 세그먼트들의 길이(예컨대, 1 내지 10초)는 적응적 스트리밍(224) 표준들에 따라 비디오 콘텐츠의 생성자에 의해 정의된다. 중계기(260)는 (시그널링 프로토콜을 요구하지 않는) WebRTC(222) 표준의 "RTCDataChannel" 컴포넌트에 따라 청크들을 푸시함으로써 비디오 세그먼트를 각각의 지정된 목적지 클라이언트 노드로 중계할 것이다.
일 실시예에서, 각각의 비디오 세그먼트는 MPEG2 전송 프로토콜을 통해 스트리밍될 때 최대 효율을 위해 UDP 데이터그램("패킷")의 크기와 일치하도록 64KB 청크들로 분할된다. 클라이언트 디바이스(200)는 UDP "패킷들"을 한 번에 하나의 청크씩 송신하고 수신한다(WebRTC(222) 표준에 따라 필요할 때 TCP로 폴백함). 예를 들어, 1초의 비디오 세그먼트는 약 625개의 청크들을 포함한다(약 5000 Kbps를 생성하는 1080p H.264 인코더를 가정함).
수신기(250)가 각각의 비디오 세그먼트의 청크들을 수신할 때, 수신기(250)는, 그 청크들을 편집하여 완전한 비디오 세그먼트들을 구성하기 위해, 수신 어레이(256)를 발생시킨다. 중계기(260)는 그 청크들을 지정된 목적지 클라이언트 노드들로 송신(중계)할 목적으로 그 청크들을 편집하기 위해 중계 어레이(257)를 발생시킨다. 이러한 방식으로, 중계 어레이(257)는 비디오 세그먼트의 착신 및 발신 청크들을 위한 버퍼로서 기능한다. 이하에서 논의될 것인 바와 같이, 성능 모니터(240)는 비디오 세그먼트 전체를 각각의 지정된 목적지 클라이언트 노드로 스트리밍하는 데 필요한 시간을 추적하고, (오버레이 네트워크들(100)을 동적으로 재구성함에 있어서의 차후의 사용을 위해) 그 메트릭을 다시 가상 방송 서버(300)에 보고한다.
일 실시예에서, 수신측 클라이언트 노드는, 클라이언트 디바이스(200)와 같은, 단일의 피딩 노드로부터 비디오 세그먼트를 수신한다. 다른 실시예에서, 다수의 잠재적인 피딩 노드들이 가상 방송 서버(300)에 의해 선택되고, (예컨대, 현재 대역폭 또는 다른 모니터링된 성능 메트릭들에 기초하여) "상위 2개의"후보들을 협상하기 위해 그 자신들 간에 통신하며, 이어서 청크들을 지정된 수신측 클라이언트 노드로 송신하는 것을 교대로 행한다.
다른 실시예에서, 각각의 비디오 세그먼트의 다수의 상이한 해상도들(예컨대, 1080p, 720p 및 480p)이 A 노드들 간에 푸시되고, 가상 방송 서버(300)는 (예컨대, 이하에서 상세히 논의되는 바와 같이, 그 다른 노드들의 능력에 기초하여) 그 해상도들 중 어느 것을 그 스웜 오버레이 네트워크 내의 다른 노드들로 푸시해야 하는지를 각각의 스웜 오버레이 네트워크의 루트에 있는 A 노드에 지시한다.
수신기(250)가 재생을 위한 비디오 세그먼트의 청크들을 수신하고 있으며 중계기(260)가 그 청크들을 다른 지정된 클라이언트 노드들로 스트리밍하고 있는 동안, 성능 모니터(240)는 가상 방송 서버(300)에 의해 지시된 바와 같이 다양한 정적 및 실시간 동적 성능 메트릭들을 수집하고, 이러한 메트릭들을 시그널링 서버(330)를 통해 다시 가상 방송 서버(300)에 연속적으로 제공한다.
앞서 살펴본 바와 같이, 이러한 메트릭들은 다음 비디오 세그먼트의 라우팅을 최적화하도록 오버레이 네트워크들(100)을 동적으로 재구성하기 위해 가상 방송 서버(300)에 의해 사용된다. 상세하게는, 성능 메트릭들은 클라이언트 노드들을 분류 및 재분류하는 데, 비디오 세그먼트들을 다른 클라이언트 노드들로 중계하기 위한 슬롯들을 할당 및 할당 해제하는 데, 비디오 세그먼트들의 어느 해상도들이 수신되어 다른 클라이언트 노드들로 중계될 수 있는지를 결정하는 데, 그리고 궁극적으로 오버레이 네트워크들(100)이 동적으로 재구성될 때 클라이언트 노드들 사이의 라우팅 경로들의 서브셋을 수정하는 데 사용된다. 이 성능 메트릭들이 가상 방송 서버(300)에 의해 이용되는 정확한 방식은 도 3과 관련하여 이하에서 보다 상세히 논의될 것이다.
운영 체제, 브라우저 및 연결의 유형(예컨대, 3G 또는 4G 셀룰러, WiFi, LAN 등)과 같은, 정적 성능 메트릭들은 자주 변경될 가능성이 없으며 전형적으로 클라이언트 디바이스(200)에 의한 초기 합류 요청 시에만 시그널링 서버(330)에 보고된다(그렇지만, 변화 - 예컨대, 3G로부터 4G로의 셀룰러 연결의 변화 - 가 있는 경우에 그들이 보고될 것이다).
동적 정보가 연속적으로(즉, 수집될 때) 모아져 보고될 수 있지만, 일 실시예에서 "오버헤드"(이 동적 메트릭들을 모니터링하여 시그널링 서버(330)에 보고하는 빈도)가 비디오 자체의 전달(즉, 청크들을 클라이언트 디바이스(200)로 그리고 그로부터 스트리밍하는 것)의 "페이로드" 또는 성능에 영향을 미치지 않도록 보장하기 위해 다양한 트레이드오프들이 고려된다. 일 실시예에서, 이러한 메트릭들이 다음 비디오 세그먼트에 대해서만 사용되는 반면, 다른 실시예들에서는, 현재 비디오 세그먼트의 전달 동안 다음 청크(또는 다수의 청크들)에 대한 변경들이 수행될 수 있다.
일 실시예에서, 두 가지 유형의 동적 성능 모니터링이 수행된다. 첫 번째 유형의 동적 성능 모니터링은, 클라이언트 디바이스(200)가 존재하는 ASN 내에서는 물론 ASN을 거쳐, 인터넷 상의 기지의 사이트들까지의(예컨대, 야후 웹 서버, 가상 방송 서버 등까지의) "핑(ping)"시간들(또는 다른 유사한 측정들)을 포함한다. 개별적으로, 이러한 메트릭들은 클라이언트 디바이스(200)의 성능에 대한 통찰력을 제공하는 동시에, 클라이언트 디바이스(200)가 존재하는 ASN 내에서는 물론 특정의 피어링 포인트들을 통해 ASN들을 거치는 QoS에 대한 부가의 통찰력을 제공한다. (A 노드들 사이의) 가상 데이터 트렁크 오버레이 네트워크가 (피어링 포인트들에서의 혼잡으로 인해) 비교적 더 큰 관심사이지만, ASN 내에서의 혼잡도 관련성이 있다(그 이유는 ASN 내에서의 혼잡이, 예를 들어, ASN 내의 스웜 오버레이 네트워크들 중 하나 이상의 스웜 오버레이 네트워크들의 적어도 일부의 동적 재구성을 필요로 할 수 있기 때문이다).
다른 유형의 동적 성능 모니터링은 비디오 세그먼트를 하나의 클라이언트 노드로부터 다른 클라이언트 노드로 중계하는 데 필요한 총 시간을 포함한다. 일 실시예에서, 각각의 노드(C 노드는 제외)는 그가 비디오 세그먼트의 첫 번째 청크를 지정된 목적지 클라이언트 노드로 송신한 "시작" 시각은 물론, 그 비디오 세그먼트의 마지막 청크가 수신된 후의 "종료" 시각을 기록한다(예컨대, 그 이유는 WebRTC(222) 표준이 각각의 패킷의 검증을 제공하기 때문이다). 성능 모니터(240)는 (노드가 송신하는 각각의 비디오 세그먼트에 대한) 이 총 시간을 시그널링 서버(330)로 송신한다. 이 메트릭은 또한 클라이언트 디바이스(200)의 개별 성능뿐만 아니라 (예컨대, 클라이언트 디바이스(200)가 ASN 피어링 포인트를 거쳐 다른 A 노드에 피드하는 A 노드인 경우에) 그의 ASN 내에서는 물론 ASN들을 거치는 혼잡 레벨에 관한 통찰을 제공할 수 있다.
일 실시예에서, 클라이언트 디바이스(200)의 사용자가 또한 비디오 콘텐츠의 생성자일 수 있다. 대부분의 경우에, 이 시나리오의 결과, 사용자들이 "언제 어디서나" 비디오 이벤트들을 포착할 수 있게 하는, 스마트폰 카메라들(카메라(219) 등)의 품질이 지속적으로 높아지게 된다. 그러나, 데스크톱 또는 랩톱 컴퓨터들은 물론 스마트폰들의 사용자들이 녹화된 비디오 이벤트를 다른 소스들로부터 획득하는 것이 또한 가능하다.
문제는 클라이언트 디바이스(200)가 그의 비디오 콘텐츠를 인터넷을 통해, 다수의 ASN들을 거쳐 많은 홉들만큼 떨어져 있을 수 있는, 가상 방송 서버(300)로 어떻게든 스트리밍해야만 한다는 것이다. 업로더(280)는 UDP 패킷들이 중간 라우터들에서 지연되거나 차단되는 것을 방지하도록 설계된 독점적 "샤워링" 프로토콜을 통해 이 문제를 해결한다. 일 실시예에서, 업로더(280)는, 보다 제한된 클라이언트측 Javascript 기능에 의존하는 것이 아니라, 클라이언트 디바이스(200) 상의 전용 스마트폰 앱을 통해 구현된다.
이 샤워링 프로토콜을 구현하기 위해, 업로더(280)는 가상 방송 서버(300)와 TCP/IP 연결을 구축하고, 이용가능한 최대 IP 패킷 크기들("MTU(maximum transmission unit)")을 전달하기 위해 UDP "버스트(burst)들"을 이용한다. 그러나, 연속적인 UDP 스트림들은 (단일의 라우터 포트를 통해 송신되든 다수의 라우터 포트들을 거쳐 배포되든 관계없이) 종종 중간 라우터들에 의해 "DOS(denial of service) 공격으로서 탐지되고, 따라서 차단된다. 더욱이, 이러한 UDP 스트림들은 라우터의 할당된 메모리(예컨대, FIFO 큐)를 오버플로(overflow)시킬 수 있는데, 그 이유는 라우터들이 전형적으로 (보다 통상적인 TCP 패킷들과 달리) UDP 패킷들이 수신되고 있는 동안에만 UDP 패킷들을 위한 메모리를 할당하기 때문이다.
이 장애물들을 해결하기 위해, 업로더(280)는 UDP 패킷들을 다수의 포트들(예컨대, 일 실시예에서 6개의 포트들) 간에 분산시킬 뿐만 아니라, DOS 공격으로서 탐지되는 것을 방지하기 위해 임의의 개별 포트를 통해 송신되는 패킷들을 지연시킨다. 일 실시예에서, 각각의 포트에서의 지연은 DOS 공격으로서 탐지되는 것을 방지할 정도로 길고, 라우터들이 충분한 메모리를 할당할 수 있게 할 정도로 길지만, 비디오 세그먼트를 다수의 ASN들을 거쳐 전달하기에 충분한 대역폭을 제공할 정도로 짧으며 UDP 스트림의 끝으로서 인지되는 것을 방지할 정도로 짧다(이는 라우터가 UDP 패킷들을 위한 메모리를 할당하는 것을 중단시키고 본질적으로 "UDP 패킷들을 버리게" 할 것이다).
업로더(280)는 이러한 방식으로 각각의 비디오 세그먼트를 가상 방송 서버(300)에 전달하기 때문에, 가상 방송 서버(300)는, 마치 이 비디오 콘텐츠가 보다 전통적인 CDN으로부터 수신된 것처럼, 이 비디오 콘텐츠를 오버레이 네트워크들(100)을 따라 재배포하기 위한 채널을 발생시킨다. 다른 실시예에서, 가상 방송 서버(300)가 클라이언트 노드 - 이 클라이언트 노드의 현재 비디오 세그먼트가 오버레이 네트워크들(100)을 따라 제시간에 도착하지 않음 - 에 대한 비디오 세그먼트의 폴백(fallback) 발신 지점 소스인 비교적 드문 시나리오에서, 가상 방송 서버(300)는 이 독점적 샤워링 프로토콜을 이용한다.
가상 방송 서버
도 3은 본 발명의 가상 방송 서버(300)의 주요 서버측 컴포넌트들의 일 실시예를 나타낸다. 앞서 살펴본 바와 같이, 가상 방송 서버(300)의 컴포넌트들이 단일의 물리적 하드웨어 서버에 예시되어 있지만, 이 컴포넌트들의 기능이 본 발명의 사상을 벗어나지 않으면서 다수의 상이한 물리적 하드웨어 디바이스들 및 상이한 소프트웨어 모듈들 간에 재할당될 수 있다.
가상 방송 서버(300)는, 대부분의 하드웨어 서버들에서 발견되는 표준의 하드웨어/소프트웨어(310) - 예컨대, CPU(312), 메모리(314), 운영 체제(316), 네트워크 어댑터(317) 및 디스플레이(318) - 와 같은, 어떤 표준의 기능을 포함한다. 특정 실시예들에서, 가상 방송 서버(300)는 또한, 예를 들어, (i) 클라이언트 노드들이 비디오를 다른 클라이언트 노드들로 송신하고 그들로부터 수신하는 것은 물론, 가상 방송 서버(300)와 연결들을 구축할 수 있도록, NAT 방화벽 안쪽에 있는 클라이언트 디바이스들(200)의 공공 IP 주소들을 발견하는 것을 용이하게 하는, STUN(322) 프로토콜("Session Traversal Utilities for NAT"); (ii) 단일의 TCP/IP 연결을 통한 고속 양방향 클라이언트-서버 통신을 용이하게 하는, WebSocket(326) 프로토콜; 및 (iii) 표준의 HTML5 웹 브라우저(230)와 같은, 클라이언트 웹 브라우저들과의 덜 빈번한 표준의 통신을 위해 이용되는, HTTP(328)를 포함할 수 있는, 표준의 라이브러리들(320)을 이용한다.
가상 방송 서버(300)는, 클라이언트 노드들로부터 획득된 성능 메트릭들을 연속적으로 분석하고, 오버레이 네트워크들(100)을 따라 있는 그 클라이언트 노드들 간에 배포되는 비디오 콘텐츠 채널들에 대한 라우팅 경로들을 동적으로 재구성할지라도, WebRTC(222) 및 적응적 스트리밍(224) 표준들을 지원할 필요가 없는데, 그 이유는 가상 방송 서버(300)가 오버레이 네트워크들(100) 상의 클라이언트 노드가 아니기 때문이다.
가상 방송 서버(300)는 오버레이 네트워크들(100)에 대한, 상세하게는 가상 데이터 트렁크 오버레이 네트워크에 대한 "채널 생성자(channel originator)" 발신 지점으로서 역할한다. 일 실시예에서, POI 콘텐츠 서버(380)는 비디오 세그먼트들에 대한 HTTP 요청들을 발행하기 위해 하나 이상의 근방의 A 노드들(가능한 경우, 바람직하게는 그의 ASN에 있음)을 지정한다. 이 A 노드들은 사실상 가상 데이터 트렁크 오버레이 네트워크의 루트로서 역할하며, 각각의 비디오 세그먼트를 ASN들 내에 있는 다른 A 노드들로 그리고 ASN들을 거쳐 다른 A 노드들로 그리고 궁극적으로 각각의 ASN 내의 스웜 오버레이 네트워크들을 통해 다른 노드들로 푸시한다.
POI 콘텐츠 서버(380)를 참조하여 이하에서 보다 상세히 기술될 것인 바와 같이, 이러한 "채널 생성(channel origination)" 기능은 브라우저간 비디오 스트리밍을 목표로 하는 표준의 WebRTC(222) 및 적응적 스트리밍(224) 라이브러리들의 사용을 필요로 하지 않는다. 앞서 살펴본 바와 같이, POI 콘텐츠 서버(380)는 또한 오버레이 네트워크들(100)을 따라 현재 비디오 세그먼트를 제시간에 수신하지 않는 클라이언트 노드들에 대한 비디오 세그먼트들의 가끔의 대체(폴백) 소스로서 역할한다. 이러한 클라이언트 노드들은 POI 콘텐츠 서버(380)가 요청된 비디오 세그먼트를 그들로 송신하는 것으로 응답하는 HTTP 요청들을 발행한다.
또한 앞서 살펴본 바와 같이, POI 콘텐츠 서버(380)는, 비디오 콘텐츠가 업로더(280)를 통해 클라이언트 디바이스(200)로부터 또는 보다 전통적인 CDN으로부터 획득되는지에 관계없이(그리고 비디오 콘텐츠가 가상 방송 서버(300)로 실시간으로 스트리밍되는지 나중에 스트리밍하기 위해 미리 제공되는지에 관계없이), (일 실시예에서) 모든 비디오 채널들에 대한 발신 지점으로서 역할한다.
채널 관리자(Channel Admin)(385)는 각각의 채널을 설정하고 유지하는 일을 맡고 있는 반면, POI 콘텐츠 서버(380)는 클라이언트 노드들로 채널로서 스트리밍하기 위한 비디오 콘텐츠 자체를 준비한다. 일 실시예에서, 채널 관리자(385)는 인터넷을 통해 POI 콘텐츠 서버(380)에 의해 전달하기 위한 그리고 특정의 채널에 합류하고자 하는 클라이언트 디바이스들(200)로부터의 합류 요청들에 응답할 때 시그널링 서버(330)에 의해 사용하기 위한 채널 웹페이지를 발생시키고 유지한다.
지원을 위해, (예컨대, 특정의 지역에서 지원 요청들이 있을 때) 채널 특정 및 지역 특정 문제들이 해결될 수 있도록 클라이언트 디바이스들(200)이 문제들을 겪고 있는 개별 시청자들은 물론 모든 비디오 채널들의 실황 모니터링을 위한 "플레이아웃 센터(playout center)"를 지원하기 위해 "시청자 지원 콘솔(viewer support console)"이 채널 관리자(385)에 의해 구축되고 유지된다. 이 지원 기능들에는 물론 (예컨대, CDN에 있는) 비디오 콘텐츠의 발신자들에 유용한 데이터를 제공하기 위해 "채널 분석"의 실시간 모니터링이 또한 채널 관리자(385)에 의해 유지된다. 예를 들어, 분석은 각각의 비디오 채널 및 오버레이 네트워크들(100)을 따라 있는 네트워크 노드들의 현재 상태는 물론, 비디오 비트 레이트들, 혼잡 지점들, 노드 지연시간 등에 관련된 라스트 마일 및 다른 문제들에 관한 실시간 메트릭들을 포함한다.
마지막으로, 시그널링 서버(330)가 (예컨대, 채널에 합류하는 것, 클라이언트에 의해 모니터링된 성능 메트릭들을 제공하는 것, 중계 타겟(relay target)들에 대한 라우팅 및 해상도 또는 비트 레이트 변화들을 획득하는 것 등에 관한) 그와 클라이언트 디바이스들(200) 간의 통신을 용이하게 하는 데 필요한 현재 정보를 갖도록, 비디오 채널들을 관리하고 시그널링 서버(330)와 인터페이싱하기 위해 "채널 관리"기능이 제공된다.
스플래시 추출기(390)를 제외한, 도 3에 예시된 나머지 서버측 기능이, 간단함을 위해, 단일의 비디오 콘텐츠 채널과 관련하여 기술될 것이다. 그렇지만, 이 기능이, 일 실시예에서, 임의의 주어진 때에 다수의 채널들에 대해 그리고 다양한 디지털 콘텐츠에 대해, 동시에 수행된다는 것에 유의해야 한다.
클라이언트 노드들이 비디오 채널에 액세스하기 전에, 비디오 콘텐츠는 다수의 보다 낮은 해상도의 비디오 세그먼트들의 스트림들을 생성하도록 트랜스코딩된다. 일 실시예에서, POI 콘텐츠 서버(380)는 클라이언트 디바이스들(200) 내의 표준의 HTML5 웹 브라우저들(230)과 통신할 수 있는 HTTP(228) 서버로서 구현된다. 빈번한 양방향 통신(예컨대, 라우팅 변화들, 성능 데이터 등의 교환)을 위해 클라이언트 디바이스들(200)과 WebSocket(225) 연결들을 구축하는 시그널링 서버(330)와 달리, POI 콘텐트 서버(380)는 매니페스트 파일들, 오버레이 네트워크들(100)을 통해 제시간에 도착하지 않은 가끔의 비디오 세그먼트들 등에 대한 표준의 HTML5 웹 브라우저들(230)로부터의 비교적 드문 클라이언트 HTTP(228) 요청들에 응답한다.
앞서 살펴본 바와 같이, POI 콘텐츠 서버(380)는 또한 - 즉, 근방의 A 노드들(가상 데이터 트렁크 오버레이 네트워크의 루트에, 전형적으로 POI 콘텐츠 서버(380)와 동일한 ASN에, 또는 하나 또는 2개의 홉들 내에 있음)로부터의 비디오 세그먼트들에 대한 HTTP 요청들에 응답하는 것에 의해 - 그의 보다 높은 대역폭의 채널 생성 기능을 구현하기 위해 HTTP(228) 프로토콜에 의존한다. 다른 실시예들에서, 이 비디오 세그먼트들은 WebRTC(222) 및 적응적 스트리밍(224) 표준들에 따라, 또는 다른 비디오 스트리밍 기법들(앞서 논의된 바와 같은 업로더(280)에 의해 사용되는 샤워링 프로토콜을 포함함)을 통해 그 A 노드들로 푸시된다.
일 실시예에서, POI 콘텐츠 서버(380)는 비디오 콘텐츠를 3개의 상이한 해상도들(1080p, 720p 및 480p)로 트랜스코딩하는 반면, 다른 실시예들에서, 모든 비디오 콘텐츠에 대한 단일의 고정 해상도를 비롯하여, 다양한 다른 보다 높은 그리고 보다 낮은 해상도들(예컨대, 4K, 360VR, 180VR, 240p 등)이 지원된다. 원래의 소스 비디오가 보다 낮은 해상도(예컨대, 720p)로 제공되는 경우, 그 비디오 채널에 대해 720p 및 480p 해상도들만이 지원될 수 있다. 이 기능은, 클라이언트 성능 메트릭들의 분석에 기초하여 (앞서 논의된 바와 같이) 클라이언트 노드들에 의해 또는 가상 방송 서버(300)에 의해 개시되는지에 관계없이, 적응적 비트 레이트 스트리밍을 용이하게 한다.
일 실시예에서, POI 콘텐츠 서버(380)는 HTTP 요청에 응답하여 각각의 비디오 세그먼트의 모든 이용가능한 버전들(예컨대, 3개의 상이한 해상도들)을 하나 이상의 근방의 노드들(전형적으로 A 노드들)에 제공함으로써 채널을 개시하고, 이는 오버레이 네트워크들(100)을 따라 각각의 비디오 세그먼트를 푸시하는 것을 개시한다. 다른 실시예에서, 이 노드들은, 모든 클라이언트 노드가 적응적 스트리밍(224) 능력을 이용할 수 있도록, 모든 버전들을 B 노드들(그리고 B:A 노드들)로 그리고 궁극적으로 C 노드들로 중계한다. 이하에서 보다 상세히 설명되는 바와 같이, 다수의 해상도들을 다른 노드들로 중계하는 노드들은 비디오 세그먼트의 이 다수의 버전들을 오버레이 네트워크들(100)을 통해 다른 클라이언트 노드들로 "폴리캐스팅"한다.
POI 콘텐츠 서버(380)가 (HTTP 요청들에 응답하여) 비디오 세그먼트들을 하나 이상의 근방의 노드들에 제공하는 것에 의해 채널을 개시하지만, 모든 클라이언트 시청측 노드들은 사실상 각각의 비디오 세그먼트를 동시에 수신하고 시청한다 - 즉, 이전 비디오 세그먼트의 재생이 종료되기 전에 각각의 비디오 세그먼트가 오버레이 네트워크들(100)을 지나간다면, 클라이언트 시청측 노드들 모두는 동기되어 있다 -. 이 실시예에서 클라이언트 디바이스들(200)이 적어도 3개의 비디오 세그먼트들을 버퍼링하기 때문에, 비디오 세그먼트가 가끔 지연되는 경우에 이 버퍼는 얼마간의 "허용 오차(margin for error)"를 제공한다. 더욱이, 다른 실시예에서, POI 콘텐츠 서버(380)가 채널을 처음으로 "방송"하기 시작할 때, 부가의 버퍼링을 제공하기 위해 채널의 개시가 지연될 수 있다. (예컨대, 비디오 세그먼트가 오버레이 네트워크들(100)을 통해 제시간에 도착하지 않았기 때문에) 클라이언트 디바이스(200)가 폴백 POI 콘텐츠 서버(380)에 대해 직접 비디오 세그먼트에 대한 요청을 발행할 때, 예를 들어, 그 비디오 세그먼트가 하나 이상의 ASN들을 거쳐가는 경우, 이 버퍼가 필요할 수 있다.
앞서 살펴본 바와 같이, POI 콘텐츠 서버(380)는 또한 클라이언트 디바이스(200)로부터의 요청들에 응답하여 주기적인 매니페스트 파일들을 제공한다. 이 매니페스트 파일들이 표준의 HTTP(328) 프로토콜들을 통해 전달되지만, 매니페스트 파일들은 비디오 세그먼트들보다 비교적 작고 훨씬 덜 시간에 민감(time critical)하다. 일 실시예에서, 각각의 매니페스트 파일은 다양한 이용가능 비트 레이트들의 다음 8개의 비디오 세그먼트들의 위치를 식별해준다. 이 실시예에서, 위치들은 POI 콘텐츠 서버(380) 상의 폴백 위치들인데, 그 이유는 비디오 세그먼트들이 오버레이 네트워크들(100)을 통해 각각의 클라이언트 디바이스(200)로 푸시되기 때문이다.
비디오 콘텐츠 채널이 (POI 콘텐츠 서버(380)에서 시작하는) 스트리밍을 위한 준비가 되면, 시그널링 서버(330)는 클라이언트 디바이스들(200)로부터의 합류 요청들을 기다린다. 클라이언트 디바이스(200)로부터 그 채널에 대한 합류 요청을 수신할 때, 시그널링 서버(330)는, 그 클라이언트 디바이스(200) 상에 존재할 수 있는 임의의 NAT 방화벽을 통해 WebSocket(326) 연결을 구축할 수 있도록 위해, STUN(322) 프로토콜에 의존한다. 더욱이, 그 클라이언트 디바이스(200)의 공공 IP 주소를 식별하는 것에 의해, 시그널링 서버(330)는 (예컨대, 비디오 세그먼트를 그 클라이언트 디바이스(200)로 중계하기 위해) 그 공공 IP 주소를 다른 클라이언트 노드들에 제공할 수 있다.
WebSocket(326) 연결이 구축되면, 클라이언트 디바이스(200)는, 일 실시예에서, 클라이언트 디바이스(200)가 C 노드인지(예컨대, 이 실시예에서 셀룰러 연결들에 대해 가정됨)를 비롯한, 그의 능력(예컨대, OS, 웹 브라우저 및 연결 유형 - 3G, 4G, WiFi, LAN 등 -)에 관한 정보를 시그널링 서버(330)에 제공한다. 클라이언트 디바이스(200)는 또한 그의 ASN 위치를 시그널링 서버(330)에 제공하고, 이는 클라이언트 디바이스(200)를 오버레이 네트워크들(100)에 추가하기 위해 나중에 사용될 것이다.
일 실시예에서, 시그널링 서버(330)는, 클라이언트 디바이스(200)가 가능한 한 빨리 채널의 비디오 콘텐츠를 재생하기 시작할 수 있도록, (오버레이 네트워크들(100)을 통한) 클라이언트 디바이스(200)에의 하나 이상의 초기 비디오 세그먼트들의 전달에 우선순위를 부여한다. 이 프로세스를 개시하기 위해, 시그널링 서버(330)는 오버레이 네트워크 생성기(350)로 제어를 넘기고, 오버레이 네트워크 생성기(350)는 클라이언트 디바이스(200)를 그의 ASN 내의 스웜 오버레이 네트워크에 추가한다(예컨대, 그 ASN 내의 B 노드에게 비디오 세그먼트들을 클라이언트 디바이스(200)로 중계하라고 지시하는 것에 의함). 클라이언트 디바이스(200)가 여전히 분류되지 않았으며, 아직 어떤 비디오 세그먼트들도 다른 클라이언트 노드들로 중계하지 않을 것임에 유의해야 한다. 그러나, 오버레이 네트워크들(100)의 일부인 것에 의해, 클라이언트 디바이스(200)는 비디오 세그먼트들을 수신하는 것 및 채널의 비디오 콘텐츠를 재생하는 것을 시작할 수 있는 것은 물론, 클라이언트 성능 메트릭들을 수집할 수 있으며, 이는 그의 분류를 용이하게 할 수 있다.
시그널링 서버(330)는 이어서 (그의 WebSocket(326) 연결을 통해) 클라이언트 디바이스(200)의 업스트림 및 다운스트림 대역폭을 획득한다. (시그널링 서버(330)가 클라이언트 디바이스(200)의 ASN 위치를 알고 있을지라도) 연결이 다수의 ASN들을 거칠 수 있기 때문에, 이 메트릭이 그다지 유용하지 않다는 것에 유의해야 한다. 보다 관련성있는 메트릭은 클라이언트 디바이스(200)와 그 자신의 ASN 내의 다른 클라이언트 노드들 간의 통신에 관련될 것이다.
클라이언트 디바이스(200)로부터(그리고 다른 클라이언트 노드들로부터)(클라이언트 디바이스(200) 상의 성능 모니터(240)에 의해 수집된) 클라이언트 성능 정보를 수신할 때, 시그널링 서버(330)는, 초기 분석 및, 이하에서 설명되는 바와 같이, 클라이언트 노드들을 동적으로 재분류하고 다음 비디오 세그먼트에 대해 오버레이 네트워크들(100)을 재구성함에 있어서 오버레이 네트워크 생성기(350) 및 딥 매퍼(360)에 의한 차후의 사용을 위해, 그 정보를 성능 추적기(340)로 포워딩한다. 성능 추적기(340)는 각각의 클라이언트 노드의 성능을 모니터링하고 클라이언트 노드가 여전히 "얼라이브(alive)"인지를 결정한다. 예를 들어, 클라이언트 디바이스(200)가 연결을 닫고 채널을 떠났거나, 문턱 양의 시간 내에 "핑"에 응답하지 않으면, 클라이언트 디바이스(200)는 (의도적이든, 또는 하드웨어 또는 소프트웨어 장애의 결과로서든 간에) 채널을 떠난 것으로 간주될 것이다. 성능 추적기(340)는 또한 클라이언트 성능 메트릭들을 과거 성능 DB(Historical Performance DB)(345)에 저장하기에 그리고 오버레이 네트워크 생성기(350) 및 딥 매퍼(360)에 의해 사용하기에 적절한 포맷으로 변환한다.
일 실시예에서, 오버레이 네트워크 생성기(350)는 또한, 딥 매퍼(360)의 도움을 받아, 현재 및 과거의 클라이언트 성능 메트릭들(과거 성능 DB(345)에 유지됨)을 평가하고, 각각의 비디오 세그먼트에 대해, 동적으로 (i) 클라이언트 노드들을 재분류하고 (ii) (비디오 세그먼트를 A 노드들 사이에서, ASN들 내부에서 그리고 ASN들을 거쳐 중계하기 위한) 가상 데이터 트렁크 오버레이 네트워크 및 (비디오 세그먼트를 ASN 내의 각각의 A 노드로부터 그 ASN 내의 어떤 다른 B:A, B 및 C 노드들로 중계하기 위한) 스웜 오버레이 네트워크를 비롯한, 오버레이 네트워크들(100)을 발생시키고 재구성하는 것에 의해 라우팅 경로들을 최적화하는 연속적인 프로세스를 맡고 있다. 오버레이 네트워크들(100)의 토폴로지는, 오버레이 네트워크 생성기(350) 및 딥 매퍼(360)에 의해 사용하기 위해, 오버레이 네트워크 DB(375)에 유지된다.
새로 추가된 클라이언트 디바이스(200)로부터 수신된 성능 메트릭들에 대해, 오버레이 네트워크 생성기(350)는 클라이언트 디바이스(200)를 처음으로 분류하기 위해 그 메트릭들을 이용한다. 일 실시예에서, 이 프로세스는 또한 (클라이언트 노드들이 채널에 합류할 때뿐만 아니라) 모든 비디오 세그먼트에 대해 클라이언트 노드들을 잠재적으로 재분류하는 데 사용된다. 클라이언트 노드들이 전형적으로 그다지 자주 재분류되지 않지만, 클라이언트는 (예컨대, 가정용 전자레인지 또는 다른 간섭으로 인해) 일시적인 대역폭 저하를 경험할 수 있다. 또한, (예컨대, 중복성을 위해, 또는 채널을 떠나는 클라이언트 노드들로 인해) 보다 많은 A 노드들이 필요할 때, B:A 노드들이 A 노드들로 업그레이드될 수 있다. ASN 내에서 또는 ASN들에 걸쳐 검출되는 다른 문제들은 또한 어떤 노드들이 재분류되어야 하는 것을 필요로 할 수 있다.
오버레이 네트워크 생성기(350)는, 다른 클라이언트 노드들로부터 푸시된 비디오 세그먼트들의 청크들을 (착신 슬롯들을 통해) 수신할 수 있고 그 비디오 세그먼트들의 청크들을 (발신 슬롯들을 통해) 다른 클라이언트 노드들로 중계할 수 있도록, 착신 및 발신 슬롯들(즉, 네트워크 포트들)을 클라이언트 디바이스(200)에 할당한다. WebRTC(224) 표준은 256개의 착신 및 발신 포트들(슬롯들)을 지원하지만, 일 실시예에서 (클라이언트 디바이스(200) 상에서 재생될 수 있는 비디오 콘텐츠의 품질을 최대화하기 위해) 단일의 착신 슬롯만이 할당되고 (오버레이 네트워크들(100)을 통한 처리율을 최대화하고 광범위한 클라이언트 디바이스들(200) 및 제한된 대역폭 연결들을 지원하기 위해) 최대 8개의 발신 슬롯들이 할당된다. 앞서 살펴본 바와 같이, A 노드들은 비디오 세그먼트들을 ASN 피어링 포인트들을 거쳐 다른 A 노드들로 중계하기 위한 4개의 발신 슬롯들과, 비디오 세그먼트들을 그의 ASN 내의 다른 A 노드들로 중계하기 위한 4개의 발신 슬롯들을 할당받는다. 이하에서 설명될 것인 바와 같이, 할당된 슬롯들 모두가 임의의 주어진 시점에서 꼭 사용되는 것은 아니다.
오버레이 네트워크 생성기(350)는 분류 프로세스를 용이하게 하기 위해 클라이언트 디바이스(200)의 다운스트림 및 업스트림 대역폭을 분석한다. 앞서 살펴본 바와 같이, 클라이언트 디바이스(200)가 셀룰러 연결(3G, 4G 또는 심지어 LTE)을 통해 합류하면, 클라이언트 디바이스(200)는 비디오 세그먼트들을 중계하기에는 너무 신뢰할 수 없는 것으로 자동으로 간주되고, 따라서 C 노드로서 분류된다. 다른 실시예들에서, 이러한 자동 분류는 어떤 셀룰러 연결들(예컨대, 3G)로 제한되거나, 완전히 제거될 수 있다.
일 실시예에서, 오버레이 네트워크 생성기(350)는 추가적인 분류를 용이하게 하기 위해, (1) LAN 연결들(예컨대, 100/100), (2) 광섬유 연결들(100/50), (3) ADSL 연결들(100/20), 케이블 연결들 (100/10) 및 WiFi 연결들(크게 다를 수 있음)을 비롯한, 전형적인 다운스트림/업스트림 대역폭 카테고리들(단위: Mbps)을 이용한다. 이 실시예에서, 클라이언트 디바이스(200)가 아직 C 노드로 간주되지 않고 적어도 50 Mbps의 업스트림 대역폭을 가지면, 클라이언트 디바이스(200)는 처음에 A 노드로서(또는 딥 매퍼(360)가 그의 ASN에 어떤 부가의 A 노드들도 필요하지 않다고 나타내는 경우, B:A 노드로서) 분류된다. 그렇지 않으면, 클라이언트 디바이스(200)가 B 노드로서 분류될 것이다.
이하에서 논의될 것인 바와 같이, 오버레이 네트워크 생성기(350)는, (존재하는 경우) 오버레이 네트워크들(100)을 동적으로 재구성해야만 하는 정도를 결정하기 전에 사용할 수 있는 이용가능한 발신 슬롯들의 수를 계산하기 위해, (일 실시예에서) 클라이언트 디바이스(200)의 업스트림 대역폭을 추가로 분석한다. 오버레이 네트워크 생성기(350)는 또한 클라이언트 디바이스(200)가 다수의 해상도들을 수신 및/또는 폴리캐스팅할 수 있는 정도를 결정한다.
일 실시예에서, 클라이언트 노드의 다운스트림 대역폭 전체가 그의 단일의 착신 슬롯을 위해 이용되는 반면, 그의 업스트림 대역폭의 1/3만이 그의 발신 슬롯들 사이에서 비디오 세그먼트들을 중계하기 위해 이용된다. 그의 업스트림 대역폭 전체가 이용되지 않는데, 그 이유는 비디오 세그먼트들을 중계하는 것이 클라이언트 디바이스(200)가 다른 애플리케이션들을 위해 사용하고 있는 TCP/IP 및 다른 연결들을 방해할 수 있기 때문이다.
오버레이 네트워크 생성기(350)는, 클라이언트 디바이스(200)가 그의 단일의 착신 슬롯을 통해 지원할 수 있는 해상도들의 수를 결정하기 위해, 클라이언트 디바이스(200)(C 노드로서 분류되더라도)의 다운 스트림 대역폭을 분석한다. 예를 들어, 1080p가 3Mbps의 비트 레이트를 필요로 하고, 720p가 1.5Mbps의 비트 레이트를 필요로 하며, 480p가 500Kbps의 비트 레이트를 필요로 하면, 클라이언트 디바이스(200)는 3개의 해상도들 전부를 지원하기 위해서는 적어도 5 Mbps, 1080p와 720p를 지원하기 위해서는 적어도 4.5Mbps, 1080p만을 지원하기 위해서는 적어도 3Mbps, 720p와 480p를 지원하기 위해서는 적어도 2Mbps, 720p만을 지원하기 위해서는 적어도 1.5Mbps, 그리고 480p만을 지원하기 위해서는 적어도 500Kbps의 다운스트림 대역폭을 필요로 할 것이다. 일 실시예에서, 500Kbps 미만의 비트 레이트들은 지원되지 않을 것이다. 다른 실시예들에서, 보다 낮은 해상도들이 지원될 수 있고, 대역폭 요구사항들을 줄이기 위해 다른 기법들(예컨대, 보다 큰 압축, 상이한 비디오 포맷들 등)이 이용될 수 있다.
앞서 살펴본 바와 같이, 일 실시예에서, A, B:A 및 B 노드들은 또한 다수의 해상도들을 그의 발신 슬롯들 중 하나 이상을 통해 다른 노드들로 중계할 수 있는 폴리캐스팅 노드들로 간주될 수 있다. 이와 관련하여, 오버레이 네트워크 생성기(350)는 클라이언트 디바이스(200)가 다른 클라이언트 노드들로 중계할 수 있는 해상도들의 수를 결정하기 위해 클라이언트 디바이스(200)의 업스트림 대역폭을 분석한다.
클라이언트 노드가 이 실시예에서 그의 업스트림 대역폭의 1/3만을 이용할 수 있기 때문에, 클라이언트 디바이스(200)는 3개의 해상도들 전부를 폴리캐스팅하기 위해서는 (발신 슬롯당) 적어도 15 Mbps, 1080p and 720p를 폴리캐스팅하기 위해서는 (발신 슬롯당) 적어도 13.5 Mbps, 1080p만을 폴리캐스팅하기 위해서는 (발신 슬롯당) 적어도 9 Mbps, 720p와 480p를 폴리캐스팅하기 위해서는 (발신 슬롯당) 적어도 6Mbps, 720p만을 중계하기 위해서는 (발신 슬롯당) 적어도 4.5Mbps, 그리고 480p만을 중계하기 위해서는 (발신 슬롯당) 적어도 1.5Mbps의 업스트림 대역폭을 필요로 할 것이다.
클라이언트 디바이스(200)는 그가 수신하지 않은 해상도를 중계할 수 없다. 더욱이, 클라이언트 디바이스(200)의 폴리캐스팅 능력은, 이하에서 설명되는 바와 같이, 다른 클라이언트 노드들이 다수의 해상도들을 수신할 수 있는 것과 관련하여 고려된다. 그러나, 앞서 살펴본 바와 같이, 클라이언트 디바이스(200)는, 그의 대역폭의 상당한 변화들을 경험할 때 비디오 세그먼트들의 보다 낮은 또는 보다 높은 해상도 버전들을 요청하기 위해, 적응적 스트리밍(224) 구현들을 이용한다. 클라이언트 디바이스(200)는, 비디오 세그먼트의 다수의 상이한 해상도들을 수신하면, 단순히 수신한 최고 해상도를 재생할 것이다.
클라이언트 디바이스(200)가 C 노드가 아니라고 가정하면, 오버레이 네트워크 생성기(350)는, 클라이언트 디바이스(200)의 업스트림 대역폭을 분석하는 것은 물론, 클라이언트 디바이스(200)가 다수의 해상도들을 폴리캐스팅할 수 있는 정도를 고려하는 것에 의해, 클라이언트 디바이스(200)가 사용할 수 있는 이용가능한 발신 슬롯들의 수를 계산한다. 예를 들어, 클라이언트 디바이스(200)가 100 Mbps의 업스트림 대역폭을 가지는 LAN 연결을 갖는 A 노드로 분류되는 경우, 클라이언트 디바이스(200)는 그의 ASN 내에서는 물론 ASN들을 거쳐 비디오 세그먼트들을 폴리캐스팅하기 위해 단지 약 6개의 발신 슬롯들을 이용할 수 있다. 이 실시예에서, 오버레이 네트워크 생성기(350)는 ASN들을 거쳐 다른 A 노드들로 폴리캐스팅하기 위해 4개의 슬롯들을 할당할 것이고(이 ASN간 슬롯들에 우선순위를 부여함), 그의 ASN 내의 다른 A 노드들로 폴리캐스팅을 위해 나머지 2개의 슬롯들을 남겨둔다. 다른 실시예들에서, 본 발명의 사상을 벗어남이 없이 이 할당들이 물론 달라질 수 있다.
이와 유사하게, 클라이언트 디바이스(200)가 10 Mbps의 업스트림 대역폭을 가지는 케이블 연결을 갖는 B:A 또는 B 노드로서 분류되는 경우, 클라이언트 디바이스(200)는 720p와 480p 해상도들을 폴리캐스팅하기 위해 또는 1080p만을 송신하기 위해 단지 하나의 발신 슬롯을 이용할 수 있다. 일 실시예에서, (노드들이 그 해상도를 수신할 수 있는 정도로) 보다 높은 품질의 해상도들에 우선순위가 부여되고, 따라서 1080p만을 위해 하나의 슬롯이 할당될 것이다. 여기에서도 역시, 본 발명의 사상을 벗어남이 없이 이 할당들이 달라질 수 있다.
클라이언트 디바이스(200)를 분류하고 (다수의 해상도들을 폴리캐스팅하는 것을 포함하여) 이용될 수 있는 슬롯들의 수를 결정하였으면, 오버레이 네트워크 생성기(350)는 라우팅 경로들을 최적화하기 위해 오버레이 네트워크들(100)을 동적으로 재구성할 정도를 결정하고, 클라이언트 디바이스(200)가 A 노드이면, 오버레이 네트워크 생성기(350)는 먼저 A 노드들 사이의 각각의 ASN간 경로에 대한 혼잡 레벨들을 딥 매퍼(360)로부터 획득할 것이고(이하에서 보다 상세히 논의됨), 이어서 클라이언트 디바이스(200)를 포함하도록 가상 데이터 트렁크 오버레이 네트워크의 적어도 일부를 동적으로 재구성할 것이다.
예를 들어, 가중 경로들의 세트(각각의 경로는 "혼잡 레벨"가중치를 가짐)가 주어지면, 오버레이 네트워크 생성기(350)는 (예를 들어, GPS 네비게이션 경로 설정과 유사하게) 비디오 세그먼트를 A 노드들 간에 배포하는 최적의 경로를 결정하기 위해 표준의 경로 탐색 기법들을 이용한다. 그렇지만, 이 프로세스가 다수의 중계 슬롯들 - 예컨대, ASN 내의 A 노드들로 중계하는 A 노드들에 대한 4개의 발신 슬롯들, 그리고 ASN 피어링 포인트를 거쳐 A 노드들로 중계하는 A 노드들에 대한 4개의 발신 슬롯들)의 사용에 의해 약간 복잡하다는 것에 유의해야 한다. 그러나, 이것은 A 노드가 단지 하나의 발신 슬롯을 가지는 가장 간단한 경우의 약간의 변형에 불과하다. 환언하면, 오버레이 네트워크 생성기(350)는 가상 데이터 트렁크 오버레이 네트워크의 발생 또는 재구성 동안 열린(사용되지 않은) 슬롯들의 수를 추적하고, 어떤 사용되지 않은 열린 슬롯들도 더 이상 갖지 않으면, 특정의 A 노드를 중계 소스로서 할당하는 것을 중단한다.
클라이언트 디바이스(200)가 B:A 또는 B 노드이면, 오버레이 네트워크 생성기(350)는 클라이언트 디바이스(200)가 존재하는 ASN에 있는 ASN간 스웜 오버레이 네트워크들 중 일부 또는 전부를 동적으로 재구성한다. 그 ASN 내에 다수의 A 노드들이 있는 경우, 그들의 서로 간의 경로들은 가상 데이터 트렁크 오버레이 네트워크의 일부로서 결정될 것임에 유의해야 한다. 일 실시예에서, (충분한 슬롯들이 이용가능한 경우) 스웜 오버레이 네트워크를 생성하기 위해 하나의 A 노드만이 이용될 것인 반면, 다른 실시예들에서는, 다른 노드들이 다수의 A 노드들 간에 똑같이 할당되거나 상대 업스트림 대역폭 또는 다른 메트릭들에 기초하여 분산될 수 있다.
임의의 특정 A 노드들 및 ASN 내의 나머지 B, B:A 및 C 노드들과 관련하여, 이 노드들은 먼저 그들의 분류에 기초하여(즉, B:A, 이어서 B, 이어서 C) 그리고 이어서 그들의 상대 대역폭(즉, 앞서 기술된 바와 같이, 사용될 수 있는 이용가능한 슬롯들의 수)에 기초하여 순위가 매겨진다. 각각의 노드가 단일의 피더 노드만을 가지면, 스웜 오버레이 네트워크가 이 실시예에서 계층구조인 것에 유의한다. 다른 실시예들에서 비계층적 "메시"스웜들에 대해 유사한 기법들이 이용될 수 있다.
이 계층적 스웜 실시예에서, 프로세스는, 이용될 수 있는 특정 수의 발신 슬롯들(예컨대, 2개의 발신 슬롯들)을 가질, 루트 A 노드에서 시작한다. 그 슬롯들은 계층구조의 다음 레벨 - 예컨대, 사용될 수 있는 가장 많은 수의 이용가능한 슬롯들을 갖는 2개의 B:A 노드들 - 로 라우팅될 것이다. 이 경로들이 결정되면, 그 노드들의 이용가능한 발신 슬롯들은 가장 많은 수의 이용가능한 슬롯들을 갖는 나머지 B:A 노드들로 라우팅될 것이다. 이 프로세스는 모든 경로들이 결정될 때까지 계층구조를 따라(B 노드들 그리고 마지막으로 C 노드들을 통해) 계속된다.
ASN 내의 노드들 사이의 중계의 비교적 높은 속도(1 ms 미만)를 고려할 때 임의의 클라이언트 노드 아래에 있는 체인의 길이(예컨대, 각각이 단일의 발신 슬롯을 갖는, 100개의 클라이언트 노드들)가 비교적 거의 중요하지 않다는 것에 유의한다. 1초의 비디오 세그먼트가 주어지면, 수백 개의 노드들로 된 체인이 (ASN 내의 많은 노드들이 다수의 발신 슬롯들을 지원할 가능성이 있기 때문에 드물지만) 여전히 수용될 수 있다. 노드들 모두가 스웜에 포함될 수는 없는 경우(예컨대, 0개의 이용가능한 슬롯을 갖는 C 노드들과 B 노드들이 고려되지 않은 경우), 이용가능하게 될 때 할당될, 그 ASN에서의 열린 슬롯들을 갖는 부가의 노드들이 필요할 것이다. 그 사이에, 이러한 노드들은 비디오 세그먼트들을 POI 콘텐츠 서버(380)에 요청하도록 지시받을 것이다.
(예컨대, 다음 1분에 대한) ASN 피어링 포인트들을 거치는 혼잡 레벨들을 예측하고 정량화하는, 딥 매퍼(360)로 돌아가기 전에, ASN 피어링 포인트 혼잡의 유의성(significance)을 이해하기 위해 BGP 라우팅 프로토콜들의 한계들을 이해하는 것이 도움이 된다. BGP 라우터들은 "라우팅 시에" 혼잡을 결정하고 예측 능력을 갖지 않는다. BGP 라우터들은 그 자신의 라우터들만을 인식하고, 지연시간은 ASN 피어링 포인트를 거쳐 "1홉 떨어져 있음"이다. BGP 라우터들은, 다수의 ASN 피어링 포인트들을 거쳐 다수의 홉들만큼 떨어져 있을 수 있는, 임의의 최종 목적지에 대한 홉 수 또는 지연시간을 알지 못한다. 다수의 ASN 피어링 포인트들의 선택 항목이 주어지면, BGP 라우터들은 본질적으로 현재 최대 이용가능 대역폭을 갖는 것(즉, 열린 슬롯 및 1홉 떨어져 있는 최저 지연시간을 갖는 것)을 선택한다.
이와 달리, 딥 매퍼(360)는 인터넷의 기반이 되는 아키텍처에 대한 그의 지식을 이용한다. 일 실시예에서, 딥 매퍼(360)는, 도 1에 개략적으로 예시된 바와 같이, 인터넷의 ASN 상호연결 맵(ASN들 및 그들의 다양한 피어링 포인트 상호연결들을 포함함)을 유지한다. 이 맵은 자주 변하지는 않지만, 일 실시예에서, 이러한 드문 변화들을 포착하기 위해 매 5분마다 모니터링된다.
그렇지만, 이 ASN들 위에 구축되는 오버레이 네트워크들(100)은 가상 방송 서버(300)에 의해 (예컨대, 앞서 논의된 바와 같이 클라이언트측 모니터링을 통해) 빈번하게 분석되고 어쩌면 매 비디오 세그먼트마다(예컨대, 일 실시예에서 매 초마다)를 재구성된다. 그렇지만, 실제적으로, 오버레이 네트워크들(100)은 실제로는 보장될 때에만 - 예컨대, 새로운 노드들이 채널에 합류하거나 채널을 떠날 때뿐만 아니라 (과거 성능 DB(345)에 유지되는 현재 및 과거의 정보에 기초하여) 충분한 문제들이 검출될 때에도 - 수정된다.
예를 들어, 일 실시예에서 다수의 내부 "혼잡 문턱값들"이 이용된다. ASN 내에서 또는 특정의 클라이언트 디바이스(200)에 특유한 비교적 낮은 혼잡 문턱값의 초기 검출 시에, 오버레이 네트워크 생성기(350)는 클라이언트 디바이스(200) 또는 ASN에 "표시"할 뿐이고, (예컨대, 다음 비디오 세그먼트에서) 문제가 반복되는지를 알아보기 위해 기다린다. 그러한 경우, 오버레이 네트워크 생성기(350)는 그 클라이언트 노드(또는 그 "문제가 되는" ASN 내의 모든 클라이언트 노드들)로 중계되는 다음 비디오 세그먼트의 해상도(그리고 따라서 비트 레이트)를 낮출 수 있다. 궁극적으로, 문제가 악화되면(예컨대, 보다 높은 혼잡 문턱값을 초과하면), 오버레이 네트워크들(100)의 일부분(예컨대, ASN 내의 서브셋 IP 범위)이 동적으로 재구성될 수 있다. 마지막으로, ASN 전체, 또는 아마도 가상 데이터 트렁크 오버레이 네트워크 자체가 동적 재구성을 필요로 할 수 있다.
어느 경우든지, 이 혼잡 문턱값들의 목표는, 비디오 세그먼트들이 손실되게 하는 또는 심지어 클라이언트 노드들이 POI 콘텐츠 서버(380)의 폴백 위치로부터 비디오 세그먼트를 획득하는 것에 의존하게 하는 보다 중대한 문제들로 악화되기 전에, 문제들을 사전 대응적으로 식별하고 교정하는 것이다.
인터넷의 ASN 상호연결 맵 및 오버레이 네트워크들(100) 상의 노드들의 ASN 위치에 대한 인식을 유지하고 이 노드들의 현재 및 과거의 성능을 실시간으로 모니터링하는 것에 의해, 딥 매퍼(360)는 임의의 클라이언트 노드가 비디오 세그먼트를 멀리 떨어진 클라이언트 노드(예컨대, 다수의 ASN 피어링 포인트들을 거쳐 많은 홉들만큼 떨어져 있음)로 불필요하게 중계할 가능성을 최소화한다. 예를 들어, 일 실시예에서 초기의 문제로서, 가상 데이터 트렁크 오버레이 네트워크는 하나의 A 노드로부터 동일한 ASN 내의 또는 단일의 ASN 피어링 포인트를 거쳐 근방의 ASN 내의 다른 A 노드로 비디오 세그먼트들을 (가능할 때마다) 라우팅하는 경향이 있다.
그렇지만, 단일의 홉들 모두가 똑같이 생성되는 것은 아니다. 예를 들어, 딥 매퍼(360)는 시간의 경과에 따라(과거 성능 DB(345)에 유지되는 클라이언트 성능 메트릭들에 기초하여) "ASN 1"과 "ASN 2" 사이의 피어링 포인트가 혼잡해지고 있다는 것을 "알" 수 있고, "ASN 1"로부터 "ASN 3"을 거쳐 "ASN 2"로의 2-홉 경로가 실제로는 현재의 1-홉 경로보다 더 빠르다고(또는 최근 및 과거의 동향들에 기초하여 아주 가까운 장래에 보다 빨라질 것이라고) "예측"할 수 있다. 피어링 포인트들을 거치는 A 노드들의 실제의 현재 및 과거의 성능에 기초하여 피어링 포인트 혼잡을 정량화하는 것에 의해, 딥 매퍼(360)는 - 어쩌면 매 비디오 세그먼트마다 또는 적어도 피어링 포인트 혼잡이 (내부 문턱값에 기초하여) 이러한 변화들을 필요로 할 때 - 가상 데이터 트렁크 오버레이 네트워크의 토폴로지의 동적 재구성을 용이하게 할 수 있다.
일 실시예에서, 딥 매퍼(360)는 1 내지 10의 척도 - 1은 예측된 단기 혼잡의 최저 레벨이고 10은 최고 레벨임 - 를 이용하여 각각의 A 노드들의 쌍(동일한 ASN에 또는 상이한 ASN들에 존재하는지에 관계없음)에 대한 혼잡을 정량화한다. 앞서 살펴본 바와 같이, 오버레이 네트워크 생성기(350)는, A 노드들 사이의 상이한 잠재적 경로들을 비교하고 가장 효율적인 경로(즉, 최저 "가중 홉" 경로)를 결정하기 위해, 이 혼잡 레벨 "점수(score)"를 이용한다. 그 결과, POI 콘텐츠 서버(380)로부터 (가중 홉들로 측정된) 가장 "멀리 있는" A 노드들은 비디오 세그먼트가 POI 콘텐츠 서버(380)로부터 이러한 A 노드들까지 가상 데이터 트렁크 오버레이 네트워크를 지나가는 데 필요한 시간의 양을 최소화할 것이다.
일 실시예에서, 각각의 A 노드들의 쌍에 대해, 딥 매퍼(360)는 하나의 A 노드로부터 다른 A 노드로의 각각의 경로에 대한 예측된 혼잡 레벨 점수를 발생시키고, 이어서 그 A 노드들의 쌍에 적용될 최저 혼잡 레벨 점수를 선택하며, 이를 오버레이 네트워크(350)로 반환한다. 다른 실시예들에서, 딥 매퍼(360)는 (하나의 A 노드에서 다른 A 노드로의 각각의 경로에 대해, 평균, 메디안 등과 같은) 그 예측된 혼잡 레벨 점수들의 상이한 함수를 발생시킨다.
딥 매퍼(360)는, 일 실시예에서, 과거 성능 DB(345)에서 유지되는 성능 메트릭들을 연속적으로 분석하고, (예컨대, 앞으로 1분 후의) ASN 피어링 포인트들을 거치는 혼잡 레벨을 예측하는 딥 러닝 엔진이다. 임의의 딥 러닝 엔진과 마찬가지로, 딥 매퍼(360)가, 그 피어링 포인트들을 거치는 A 노드들 간의 트래픽과 관련하여, ASN 피어링 포인트들의 거동을 모델링하기 위해 다수의 비선형 변환들 이용한다는 것에 유의해야 한다.
앞서 살펴본 바와 같이, 딥 매퍼(360)는 사실상 그 피어링 포인트들을 거치는 인터넷 트래픽의 대부분을 모니터링할 수는 없고, 시간의 경과에 따라 이러한 트래픽이 그 피어링 포인트들을 거쳐 A 노드들 사이의 ASN간 홉들에서 가지는 효과만을 모니터링한다. 보다 많은 성능 메트릭들이 획득됨에 따라, 딥 매퍼(360)는 (예컨대, 그렇지만 이 실시예에서 역시 모니터링되는, 전형적으로 훨씬 덜 혼잡한 ASN내 홉들과 비교하여) 이러한 ASN간 홉들에 필요한 시간 - 이는 이어서 상대 혼잡 레벨로서 정량화됨 - 을 더 잘 예측할 수 있다.
피어링 포인트들의 혼잡 레벨이 아주 동적이기 때문에, 이러한 예측들은 짧은 기간 동안만 정확할 수 있다. 그러나, 이 분석이 연속적으로 수행되고 다음 1초의 비디오 세그먼트에 대해 변할 수 있으면, 예측이 오랜 기간 동안 정확해야한다는 것은 중요하지 않다.
일 실시예에서, 딥 매퍼(360)는 처음에(즉, 많은 클라이언트 성능 메트릭들이 획득되기 전에) 아주 조악한 정보에 기초하여 ASN 피어링 포인트들을 정량화한다. 예를 들어, ASN이 1000개의 피어링 포인트들을 가지면, 그 ASN은 6개의 피어링 포인트들을 갖는 다른 ASN보다 훨씬 더 빠를 가능성이 있는 백본이라고 가정될 수 있다. 보다 많은 클라이언트 성능 메트릭들이 획득됨에 따라, 이 ASN 피어링 포인트 혼잡 레벨들이 보다 정확하게 될 것이다. 다른 실시예에서, 새로운 채널을 "신속히 시작(jump start)"하기 위해 다수의 "러닝 노드(learning node)들"이 배치된다. 이 러닝 노드들은 비디오를 시청하지 못하는 송신 전용 노드이고, 딥 매퍼(360)가 그렇게 하지 않은 것보다 더 빨리 보다 정확한 예측을 시작할 수 있도록, 클라이언트 성능 정보를 신속하게 제공하기 위해서만 배치된다.
더욱이, 일 실시예에서, 딥 매퍼(360)는 또한 ASN내 혼잡을 고려하는데, 그 이유는 이것이 예를 들어, ASN 내의 부가의 A 노드들 그리고 따라서 부가의 스웜 오버레이 네트워크들의 생성에 대한 필요성을 암시할 수 있기 때문이다. 예를 들어, ASN 내의 많은 클라이언트 노드들이 시간이 지남에 따라 비디오 세그먼트들을 획득하는 데 점차적으로 더 오랜 시간이 걸리는 경우, 딥 매퍼(360)는 부가의 A 노드들이 필요하다는 것을 나타내기 위해 ASN에 표시하고, 오버레이 네트워크 생성기(350)는 하나 이상의 B:A 노드들을 A 노드들로 "격상"시킬 수 있으며, 그 결과 가상 데이터 트렁크 오버레이 네트워크의 부분 재구성이 이루어지고, 궁극적으로 ASN 내에 새로운 스웜 오버레이 네트워크들을 필요로 한다. 다른 실시예에서, 딥 매퍼(360)는 각각의 ASN 내에서 딥 러닝 기법들을 적용하고, 오버레이 네트워크 생성기(350)가 ASN내 스웜 오버레이 네트워크들을 발생시키는 것을 돕는다.
따라서, 오버레이 네트워크 생성기(350)와 딥 매퍼(360)는, 불필요하게 멀리 떨어진 경로들을 거치는(즉, 다수의 ASN 피어링 포인트들을 거치는) 비디오 세그먼트들의 중계들을 최소화하기 위해, 인터넷의 기반이 되는 아키텍처(ASN 상호연결 맵) 및 그 아키텍처 위에 오버레이된 클라이언트 노드들의 ASN 위치에 기초하는 (오버레이 네트워크들(100)을 통한) 클라이언트 노드들 간의 경로들을 구축하기 위해 서로 협력한다. 더욱이, 오버레이 네트워크 생성기(350) 및 딥 매퍼(360)는 또한, 클라이언트 디바이스들(200)에 의해 획득된 실시간 클라이언트 성능 메트릭들을 연속적으로 분석하기 위해 그리고 이러한 메트릭들이 (종종 ASN 피어링 포인트들에서의 혼잡으로 인한) 중대한 문제들을 나타내는 경우에 오버레이 네트워크들(100)을 동적으로 재구성하기 위해, 서로 협력한다. 그 결과, 인터넷의 QoS 변동성이 모니터링될 수 있고, "발생하기 전에"(딥 매퍼(360)에 의해 발생되는 예측된 혼잡 레벨들에 기초하여) 이러한 문제들을 우회하게 동적으로 재라우팅함으로써 (특히 ASN 피어링 포인트들에서의) 혼잡의 클라이언트 노드들에 대한 영향이 최소화될 수 있다.
일 실시예에서, 가상 방송 서버(300)는 동향 비디오 이벤트들("스플래시들")을 식별하는 것 및 사용자들이 이러한 이벤트들의 도메인을 검색하여 원하는 스플래시 결과를 POI 콘텐츠 서버(380)로부터 비디오 채널로서 즉각 스트리밍할 수 있게 하는 것(여기서 이러한 채널은 그렇지 않았으면 가상 방송 서버(300)로부터 이용가능하지 않았음)을 위한 스플래시 추출기(390) 검색 엔진을 포함한다.
일 실시예에서, 스플래시 추출기(390)는 - 예컨대, Twitter, RSS Feeds, Reddit 및 수만개의 온라인 잡지들에 대한 API들을 통해 - 다수의 뉴스 소스들로부터 연속적으로 데이터를 수집한다. 평균적으로, 수천개의 독특한 "현재 이벤트들"이 매 시간마다 이러한 소스들에서 나타난다. 스플래시 추출기(390)는, 이러한 동향 이벤트들(스플래시들)을 식별하고 POI 콘텐츠 서버(380)를 통해 획득되고 스트리밍될 수 있는 관련 비디오들을 찾아내어 추출하기 위해, 신규의 자동화된 방법을 이용한다.
스플래시 추출기(390)는 스플래시들을 검출하기 위해 "노름으로부터의 편차(deviation from the norm)"를 식별한다. 예를 들어, 뉴스 소스들의 도메인에서, 예를 들어, 표준의 Levenshtein 비교 알고리즘을 이용하여 (정규화된 데이터를 필요로 함이 없이) 기준선이 만들어진다. 평균적으로, 특정의 주제가 실제로 동향을 나타내지 않는 한, 몇 개 이하의 소스들이 단기간 내에 동일한 "주제"(즉, 키워드들의 모음)을 논의할 것이다. 그 시점에서(예컨대, 15개 이상의 소스들이 짧은 기간 내에 동일한 주제를 논의할 때), 그 주제는 편차 그리고 따라서 스플래시로서 식별된다.
스플래시 추출기(390)는 이어서 - 일 실시예에서, "스플래시 관련"기사들로부터 독특한 키워드들을 학습하고 예측하기 위해 표준의 신경망 기법들을 이용하는 것에 의해 - 그 소스들로부터의 "가장 중요한"키워드들(예컨대, 일 실시예에서 40개의 키워드들)을 추출한다. 이 키워드들은 이어서 (예컨대, 뉴스, 스포츠 등으로) 분류되고 빈도수에 의해 순위가 매겨진다.
스플래시 추출기(390)는 이어서 각각의 스플래시에 관련된 비디오들이 있는지 소셜 미디어를 검색하기 위해 그 키워드들을 사용하고, 그 잠재적인 스플래시 비디오 채널들과 연관된 관련 텍스트를 인덱싱한다. 사용자들은 이어서 그 인덱스를 검색하거나, 스플래시 비디오 이벤트들의 카테고리들을 단순히 브라우징할 수 있다. (검색되었는지 브라우징되었는지에 관계없이) 결과를 선택할 때, 사용자는 원하는 비디오를 즉각 스트리밍할 수 있다. 일 실시예에서, 사용자가 비디오의 현재 소스에 단순히 링크되는 반면, 다른 실시예에서, 비디오가 가상 방송 서버(300)를 통해 획득되고, POI 콘텐츠 서버(380)로부터 스트리밍된다(예를 들어, 많은 수의 동시 사용자들이 동일한 스플래시 비디오 채널을 요청하는 경우 유용함).
동적 비디오 스트리밍 프로세스
본 발명의 가상 방송 시스템의 주요 클라이언트측 및 서버측 컴포넌트들을 논의하였으며, 도 4의 플로차트(400)는 이 컴포넌트들이 어떻게 동적으로 상호작용하는지를 나타낸다. 환언하면, 플로차트(400)는 이러한 컴포넌트들에 의해 구현되는 본 발명의 동적 스트리밍 프로세스의 일 실시예를 나타낸다. 이 프로세스의 상당 부분이 이벤트 기반이고 선형이 아니기 때문에, 플로차트(400)가 클라이언트측 기능과 서버측 기능 간의 상호작용의 관점에서 단계들을 나타낸다는 것에 유의해야 한다.
단계(401)는, 비디오 이벤트가 클라이언트 노드(예컨대, 클라이언트 디바이스(200) 상의 스마트폰 카메라(219))에 의해 포착되거나 디지털적으로 발생되거나 외부 소스로부터 획득되는, 업로더(280)에 의해 수행되는(그리고 앞서 기술된) 프로세스를 나타낸다. 어느 경우든지, 클라이언트(예컨대, 클라이언트 디바이스(200))는 이어서 그 비디오 이벤트의 비디오 세그먼트들을 (실황으로 포착된 것이든 녹화된 것이든 간에) 가상 방송 서버(300)로 스트리밍한다.
비디오 이벤트들이 클라이언트들로부터 또는 보다 전통적인 CDN으로부터 획득되든 간에(그리고 그들이 녹화되든 실황으로 스트리밍되든 간에), 가상 방송 서버(300)는, 단계(410)에서, 앞서 논의된 바와 같이, POI 콘텐츠 서버(380)로부터 실황으로 스트리밍하기 위한 각각의 비디오 채널을 준비한다. 이 시점에서, 일 실시예에서, 채널 웹페이지가 발생되고 궁극적으로 잠재적인 클라이언트 노드와 만난다. 클라이언트 디바이스(200)의 사용자가 원하는 채널을 클릭할 때, 합류 요청이, 클라이언트 능력(운영 체제, 브라우저, 연결 등의 유형 등)과 함께, 시그널링 서버(330)로 송신된다. 대안적으로, 클라이언트 디바이스(200)의 사용자는 (앞서 논의된 바와 같이) 동향 스플래시 비디오 이벤트를 만나고 (단계(410)에서) POI 콘텐츠 서버(380)로부터 비디오 채널로서 스트리밍하기 위한 그 비디오 이벤트를 선택한다.
단계(412)에서, 시그널링 서버(330)는 (예컨대, 클라이언트의 공공 IP 주소를 식별하기 위해 STUN(322) 프로토콜을 이용하는 것에 의해) 채널에의 클라이언트 연결을 검증하고, 이어서 클라이언트 상에 존재할 수 있는 임의의 NAT 방화벽을 통해 WebSocket(326) 연결을 구축하며, 나중에 비디오 세그먼트를 그 클라이언트로 중계하기 위한 다른 클라이언트 노드들에 그 공공 IP 주소를 제공한다. 시그널링 서버(330)는 이어서, (아직 분류되지 않은) 클라이언트를 오버레이 네트워크들(100) 상의 노드로서 추가하는, 오버레이 네트워크 생성기(350)로 제어를 넘기고, 사용자가 단계(415)에서 비디오 채널을 즉각 시청하기 시작할 수 있도록 (단계(414)에서) 초기 비디오 세그먼트들이 오버레이 네트워크들(100) 상의 노드로부터 클라이언트로 푸시될 것이다
시그널링 서버(330)는 이어서, 단계(416)에서, 클라이언트 디바이스(200)를 A, B:A, B 또는 C 노드로서 분류하고, 단계(430)에서, 클라이언트 디바이스(200)를 네트워크 토폴로지에 포함하도록 ASN간(가상 데이터 트렁크) 및 ASN내(스웜) 오버레이 네트워크들(100)을 동적으로 재구성하기 위해 오버레이 네트워크 생성기(350) 및 딥 매퍼(360) 둘 다를 이용한다. 시그널링 서버(330)는 이어서 비디오 세그먼트들을 클라이언트 디바이스(200)로 중계하기 시작하기 위해 관련 경로 정보를 다른 클라이언트 노드들에 제공한다.
POI 콘텐츠 서버(380)는, 단계(435)에서, 이어서 현재의 (재구성된) 오버레이 네트워크들(100)을 따라 비디오 채널의 발신 지점인 그 노드들로 비디오 세그먼트들을 스트리밍하기 위해 근방의 노드들(전형적으로 A 노드들)로부터의 HTTP 요청들에 응답하고, 각각의 비디오 세그먼트는, 클라이언트 디바이스(200)로 중계되어 그에 의해 시청될 때까지, 노드로부터 노드로 중계된다.
클라이언트 디바이스(200)가 채널의 각각의 비디오 세그먼트를 시청하기 위해 청크들을 수신하고, 단계(450)에서, 그들을 편집하는 동안(그리고 어쩌면 또한, 단계(440)에서, 청크들을 다른 지정된 클라이언트 노드들로 중계하는 동안), 클라이언트 디바이스(200)는 또한, 성능 모니터(240)와 관련하여 앞서 논의된 바와 같이, 단계(425)에서 그의 성능을 모니터링하고, 클라이언트 성능 메트릭들을 시그널링 서버(330)에 제공한다. 그에 부가하여, 각각의 비디오 세그먼트가 요청될 때, 이 요청들이 단계(455)에서 (일 실시예에서, 수신기(250)에서의 클라이언트 Javascript 코드에 의해) 가로채기되는데, 그 이유는, 앞서 논의된 바와 같이, 비디오 세그먼트들이 오버레이 네트워크들(100)을 따라 클라이언트 디바이스(200)로 푸시되기 때문이다. 단계(455)로부터 단계(425)로의 화살표는 단순히 단계(425)에서의 모니터링 프로세스가, 비디오 세그먼트들의 청크들의 수신, 시청 및 중계와 동시적인, 연속적인 프로세스라는 것을 나타낸다.
또한 앞서 살펴본 바와 같이, 클라이언트 디바이스(200)는, 비디오 세그먼트들이 다른 클라이언트 노드들로부터 클라이언트 디바이스(200)로 푸시되더라도, POI 콘텐츠 서버(380)에 매니페스트 파일들(예컨대, 다음 8개의 비디오 세그먼트들의 위치들을 포함함)에 대한 HTTP 요청들을 주기적으로 개시한다. 때로는, 비디오 세그먼트가 제시간에 도착하지 않으면, 클라이언트 디바이스(200)는 폴백 위치인 POI 콘텐츠 서버(380)에 직접 그 비디오 세그먼트를 요청할 것이다. 더욱이, 때로는, 적응적 스트리밍(224) 표준들에 따라, 클라이언트 디바이스(200)는 또한, (예컨대, 그의 성능 레벨들의 변화를 검출할 때) 후속 비디오 세그먼트들에 대한 수정된 비트 레이트를 요청하기 위해, POI 콘텐츠 서버(380)에 접촉할 수 있다. 그렇지만, 앞서 살펴본 바와 같이, 수신기(250)는 이러한 요구를 보다 일찍 잘 검출하고, 오버레이 네트워크들(100)을 통해 이러한 변경들을 수행하기 위해 가상 방송 서버(300)에 접촉하여, 피딩 클라이언트 노드에게 보다 낮은 또는 보다 높은 해상도의 비디오 세그먼트들을 클라이언트 디바이스(200)로 (즉, 그의 요청에 응답해서가 아니라) 자동으로 푸시하라고 지시할 수 있다.
단계(452)에서, POI 콘텐츠 서버(380)는 이러한 HTTP 요청들에 응답하고, 요청된 매니페스트 파일들 및 폴백 비디오 세그먼트들을 클라이언트 디바이스(200)에 전달한다. 앞서 살펴본 바와 같이, 비트 레이트들의 변화는 오버레이 네트워크들(100)을 통해 해결되고 (그리고 단계(430)에서), 그 결과 보다 낮은 또는 보다 높은 해상도의 비디오 세그먼트들이 클라이언트 디바이스(200)로 푸시된다.
단계(454)는 성능 추적기(340), 오버레이 네트워크 생성기(350) 및 딥 매퍼(360)에 의해 수행되는 연속적인 프로세스(일 실시예에서, 각각의 비디오 세그먼트에 대해 수행되고 앞서 상세히 기술됨)를 포함한다. 이 단계(454)에서, 클라이언트 성능 정보가 연속적으로 업데이트되고, 필요한 경우, (단계(454)로부터 단계(430)로의 화살표에 의해 나타낸 바와 같이) 단계(430)에서, 오버레이 네트워크들(100)이 동적으로 재구성되고, 새로운 라우팅 정보가 시그널링 서버(330)를 통해 관련 중계 노드들에 제공된다.
마지막으로, 단계(460)에서, 스플래시 추출기(390)는 클라이언트 디바이스들(200)의 사용자들이 브라우징하거나 검색할 수 있는 동향 스플래시 비디오 이벤트들을 연속적으로 식별하고, 이어서 앞서 논의된 바와 같이 즉각적인 시청을 위해 스트리밍한다.
본 발명이 본원에서 첨부 도면들에 예시된 바와 같은 특정 실시예들을 참조하여 기술되었다. 본 개시내용을 고려하여, 본원에 개시된 개념들의 부가 실시예들이 본 기술분야의 통상의 기술자에 의해 본 발명의 범주 내에서 안출되고 구현될 수 있다는 것을 잘 알 것이다.
Claims (13)
- 다수의 애플리케이션 ASN들 및 ASN 피어링 포인트(ASN peering point)들을 포함하는 광역 네트워크 상의 노드들 간에 동시에 디지털 콘텐츠를 적응적으로 라우팅하는 가상 방송 시스템으로서, 상기 ASN 피어링 포인트들은 그 ASN 피어링 포인트들을 거치는 네트워크 트래픽이 변동함에 따라 빈번하게 변하는 혼잡 레벨들을 나타내고, 상기 가상 방송 시스템은:
상기 ASN들 및 그들을 상호연결시키는 상기 피어링 포인트들의 맵과, ASN 내에서의 노드들의 위치들을 저장하는 메모리;
하나 이상의 오버레이 네트워크들을 따라가는 네트워크 트래픽에 대한 성능 메트릭들을 모니터링하는 성능 추적기(performance tracker) - 상기 메트릭들은 상기 ASN 피어링 포인트들에서의 혼잡을 포함함 -; 및
시간의 경과에 따라 상기 메트릭들 및 상기 맵을 분석하고 시간의 경과에 따라 상기 ASN 피어링 포인트들의 변하는 용량을 반영하는 혼잡 레벨들을 예측하는 딥 러닝 엔진(deep learning engine);
상기 노드들 간에 데이터를 전달하기 위한 상기 광역 네트워크를 통한 라우팅 경로들을 정의하는 오버레이 네트워크 토폴로지를 저장하는 데이터베이스; 및
상기 오버레이 네트워크를 따라 상기 노드들 사이에서 상기 디지털 콘텐츠를 라우팅하기 위한 최적의 경로들을 발생시키기 위해 상기 예측된 혼잡 레벨들에 기초하여 상기 오버레이 네트워크 토폴로지를 동적으로 재구성하는 오버레이 네트워크 생성기(overlay network creator)를 포함하는, 가상 방송 시스템. - 제1항에 있어서, 상기 오버레이 네트워크는 노드들의 중계 능력을 나타내는 성능 메트릭들에 기초하여 노드들을 분류하고, 데이터 세그먼트들을 중계하는 능력을 갖지 않는 노드들은 제3 부류에 할당되고, ASN 내에서 데이터 세그먼트들을 중계하는 능력을 갖는 노드들은 제2 부류에 할당되며, ASN 내에서는 물론 ASN들을 거쳐서도 데이터 세그먼트들을 중계하는 능력을 갖는 노드들은 제1 부류에 할당되고; 상기 오버레이 네트워크 생성기는 노드들이 디지털 콘텐츠의 청크들을 다른 노드들로 중계하고 그들로부터 수신할 수 있게 하기 위해 상기 노드들에 슬롯들을 할당하는, 가상 방송 시스템.
- 제1항에 있어서, 또한 상기 성능 추적기는 상기 노드들의 상기 성능 메트릭들을 추가로 모니터링하고 그들을 상기 딥 러닝 엔진 및 오버레이 네트워크 생성기에 의한 사용을 위해 저장하는, 가상 방송 시스템.
- 제1항에 있어서, 상기 오버레이 네트워크 토폴로지는 상기 제1 부류 내의 상기 노드들 및 비디오 세그먼트가 ASN들 내에서 그리고 ASN들을 거쳐 상기 제1 부류 내의 노드들 사이에서 따라가는 라우팅 경로들을 나타내는 하나 이상의 ASN간 오버레이 네트워크(inter-ASN overlay network)들을 포함하는, 가상 방송 시스템.
- 제1항에 있어서, 상기 오버레이 네트워크 토폴로지는 비디오 세그먼트를 상기 제1 부류 내로부터 상기 제2 및 제3 부류들을 갖는 노드들로 중계하기 위한 하나 이상의 ASM내 오버레이 네트워크(intra-ASM overlay network)들을 포함하는, 가상 방송 시스템.
- 제3항에 있어서, 상기 노드들의 상기 성능 메트릭들은 기지의(known) 사이트들까지의 핑(ping) 시간들 및 디지털 콘텐츠 세그먼트를 중계하기 위한 총 시간을 포함하는, 가상 방송 시스템.
- 다수의 애플리케이션 ASN들 및 ASN 피어링 포인트들을 포함하는 광역 네트워크 상의 노드들 간에 동시에 디지털 콘텐츠를 적응적으로 라우팅하는 가상 방송 방법으로서, 상기 ASN 피어링 포인트들은 그 ASN 피어링 포인트들을 거치는 네트워크 트래픽이 변동함에 따라 빈번하게 변하는 혼잡 레벨들을 나타내고, 상기 가상 방송 방법은:
상기 ASN들 및 그들을 상호연결시키는 상기 피어링 포인트들의 맵과, ASN 내에서의 노드들의 위치들을 유지하는 단계;
상기 노드들 간에 데이터를 전달하기 위한 상기 광역 네트워크를 통한 라우팅 경로들을 정의하는 오버레이 네트워크 토폴로지를 발생시키는 단계;
상기 하나 이상의 오버레이 네트워크들을 따라가는 네트워크 트래픽에 대한 성능 메트릭들을 모니터링하는 단계 - 상기 메트릭들은 상기 ASN 피어링 포인트들에서의 혼잡을 포함함 -;
시간의 경과에 따라 상기 ASN 피어링 포인트들의 변하는 용량을 반영하는 혼잡 레벨들을 예측하기 위해 시간의 경과에 따라 상기 메트릭들 및 상기 맵을 분석하는 단계; 및
상기 오버레이 네트워크들을 따라 상기 노드들 사이에서 상기 디지털 콘텐츠를 라우팅하기 위한 최적의 경로들을 발생시키기 위해 상기 예측된 혼잡 레벨들에 기초하여 오버레이 네트워크 토폴로지를 동적으로 재구성하는 단계를 포함하는, 가상 방송 방법. - 제7항에 있어서, 하나 이상의 오버레이 네트워크들의 토폴로지들을 발생시키는 단계는 적어도:
노드들의 중계 능력을 나타내는 성능 메트릭들에 기초하여 노드들을 분류하는 단계로서, 데이터 세그먼트들을 중계하는 능력을 갖지 않는 노드들은 제3 부류에 할당되고, ASN 내에서 데이터 세그먼트들을 중계하는 능력을 갖는 노드들은 제2 부류에 할당되며, ASN 내에서는 물론 ASN들을 거쳐서도 데이터 세그먼트들을 중계하는 능력을 갖는 노드들은 제1 부류에 할당되는 단계; 및
노드들이 디지털 콘텐츠의 청크들을 다른 노드들로 중계하고 그들로부터 수신할 수 있게 하기 위해 상기 노드들에 슬롯들을 할당하는 단계를 포함하는, 가상 방송 방법. - 제4항에 있어서, 하나 이상의 오버레이 네트워크들의 토폴로지들을 발생시키는 단계는 상기 제1 부류 내의 상기 노드들 및 비디오 세그먼트가 ASN들 내에서 그리고 ASN들을 거쳐 상기 제1 부류 내의 노드들 사이에서 따라가는 라우팅 경로들을 나타내는 하나 이상의 ASN간 오버레이 네트워크들을 발생시키는 단계를 추가로 포함하는, 가상 방송 방법.
- 제8항에 있어서, 하나 이상의 오버레이 네트워크들의 토폴로지들을 발생시키는 단계는 비디오 세그먼트를 상기 제1 부류 내로부터 상기 제2 및 제3 부류들을 갖는 노드들로 중계하기 위한 하나 이상의 ASM내 오버레이 네트워크들을 발생시키는 단계를 추가로 포함하는, 가상 방송 방법.
- 제7항에 있어서, 상기 오버레이 네트워크들은 미리 정의된 혼잡 문턱값이 초과될 때 동적으로 재구성되는, 가상 방송 방법.
- 제7항에 있어서, 상기 노드들의 상기 성능 메트릭들은 기지의 사이트들까지의 핑 시간들 및 디지털 콘텐츠 세그먼트를 중계하기 위한 총 시간을 포함하는, 가상 방송 방법.
- 제7항에 있어서, 노드들의 성능 메트릭들에 기초하여 노드들을 분류하는 단계는 노드들의 중계 능력들을 결정하기 위해 상기 노드들의 다운스트림 및 업스트림 대역폭을 분석하는 단계를 포함하는, 가상 방송 방법.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020227037918A KR20220151224A (ko) | 2014-12-26 | 2015-12-23 | 디지털 콘텐츠의 적응적 가상 방송을 위한 방법 및 시스템 |
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201462096938P | 2014-12-26 | 2014-12-26 | |
| US62/096,938 | 2014-12-26 | ||
| US14/848,268 | 2015-09-08 | ||
| US14/848,268 US9769536B2 (en) | 2014-12-26 | 2015-09-08 | Method and system for adaptive virtual broadcasting of digital content |
| PCT/IB2015/002604 WO2016103051A1 (en) | 2014-12-26 | 2015-12-23 | Method and system for adaptive virtual broadcasting of digital content |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020227037918A Division KR20220151224A (ko) | 2014-12-26 | 2015-12-23 | 디지털 콘텐츠의 적응적 가상 방송을 위한 방법 및 시스템 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20170101287A true KR20170101287A (ko) | 2017-09-05 |
| KR102462384B1 KR102462384B1 (ko) | 2022-11-03 |
Family
ID=55066402
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020227037918A KR20220151224A (ko) | 2014-12-26 | 2015-12-23 | 디지털 콘텐츠의 적응적 가상 방송을 위한 방법 및 시스템 |
| KR1020177020882A KR102462384B1 (ko) | 2014-12-26 | 2015-12-23 | 디지털 콘텐츠의 적응적 가상 방송을 위한 방법 및 시스템 |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020227037918A KR20220151224A (ko) | 2014-12-26 | 2015-12-23 | 디지털 콘텐츠의 적응적 가상 방송을 위한 방법 및 시스템 |
Country Status (10)
| Country | Link |
|---|---|
| US (3) | US9769536B2 (ko) |
| EP (3) | EP4160993A1 (ko) |
| JP (2) | JP6612355B2 (ko) |
| KR (2) | KR20220151224A (ko) |
| CN (1) | CN107223325B (ko) |
| ES (2) | ES2930016T3 (ko) |
| HK (1) | HK1249973A1 (ko) |
| MX (1) | MX370809B (ko) |
| PL (1) | PL3038323T3 (ko) |
| WO (1) | WO2016103051A1 (ko) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2019164250A1 (ko) * | 2018-02-20 | 2019-08-29 | 삼성전자 주식회사 | 완전 연결 네트워크의 데이터 입력 및 출력을 제어하는 방법 및 장치 |
| WO2019245181A1 (ko) * | 2018-06-20 | 2019-12-26 | 네이버 주식회사 | 적응형 데이터 전송을 위한 방법 및 시스템 |
| KR20200037015A (ko) * | 2018-09-28 | 2020-04-08 | 한국과학기술원 | 컨텐츠 인지 신경망을 이용하여 실시간으로 적응형 비디오를 전송하는 방법 및 장치 |
Families Citing this family (77)
| 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 |
| US10142386B2 (en) * | 2014-10-29 | 2018-11-27 | DLVR, Inc. | Determining manifest file data used in adaptive streaming video delivery |
| 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 |
| WO2017117264A1 (en) | 2015-12-29 | 2017-07-06 | Echostar Technologies L.L.C | Remote storage digital video recorder streaming and related methods |
| 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 |
| GB201612361D0 (en) * | 2016-04-19 | 2016-08-31 | Cisco Tech Inc | Routing to content in an IP network |
| US11509570B2 (en) | 2016-05-13 | 2022-11-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Resource usage in a multipath network |
| US10046236B2 (en) * | 2016-06-13 | 2018-08-14 | Sony Interactive Entertainment America, LLC | Browser-based cloud gaming |
| WO2017215733A1 (en) * | 2016-06-14 | 2017-12-21 | 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 |
| CN110771122A (zh) * | 2017-06-20 | 2020-02-07 | 瑞典爱立信有限公司 | 使内容传送网络能够处理非预期流量激增的方法和网络节点 |
| US10673715B2 (en) * | 2017-07-20 | 2020-06-02 | Servicenow, Inc. | Splitting network discovery payloads based on degree of relationships between nodes |
| WO2019037074A1 (zh) * | 2017-08-25 | 2019-02-28 | 深圳市瑞立视多媒体科技有限公司 | 虚拟现实交互系统、方法及计算机存储介质 |
| CA3075832A1 (en) | 2017-09-15 | 2019-03-21 | Imagine Communications Corp. | Systems and methods for playout of fragmented video content |
| KR102305615B1 (ko) * | 2017-10-03 | 2021-09-27 | 소니그룹주식회사 | 업 링크 스트리밍을 위한 네트워크 지원 |
| 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 |
| 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 |
| TWI680661B (zh) * | 2018-07-20 | 2019-12-21 | 茂傑國際股份有限公司 | 加值遠端顯示服務的無線路由伺服裝置及方法 |
| 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 |
| US12022306B2 (en) * | 2019-05-31 | 2024-06-25 | 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 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6275470B1 (en) * | 1999-06-18 | 2001-08-14 | Digital Island, Inc. | On-demand overlay routing for computer-based communication networks |
| US7388841B2 (en) * | 2003-10-20 | 2008-06-17 | Mitsubishi Electric Research Laboratories, Inc. | Selecting multiple paths in overlay networks for streaming data |
Family Cites Families (31)
| 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 |
| 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 |
| 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 | 인하대학교 산학협력단 | 노드 가용도 예측 기반의 그리드 네트워크 혼잡 제어 장치및 방법 |
| JP4893828B2 (ja) | 2007-06-29 | 2012-03-07 | 富士通株式会社 | ネットワーク障害検知システム |
| WO2009049680A1 (en) | 2007-10-18 | 2009-04-23 | Ericsson Hungary Ltd | 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 |
| AU2014257769B2 (en) * | 2013-04-25 | 2017-05-11 | Hive Streaming 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 |
-
2015
- 2015-09-08 US US14/848,268 patent/US9769536B2/en active Active
- 2015-12-23 WO PCT/IB2015/002604 patent/WO2016103051A1/en active Application Filing
- 2015-12-23 KR KR1020227037918A patent/KR20220151224A/ko not_active Application Discontinuation
- 2015-12-23 CN CN201580071161.2A patent/CN107223325B/zh active Active
- 2015-12-23 MX MX2017008157A patent/MX370809B/es active IP Right Grant
- 2015-12-23 KR KR1020177020882A patent/KR102462384B1/ko active IP Right Grant
- 2015-12-23 JP JP2017552535A patent/JP6612355B2/ja active Active
- 2015-12-24 EP EP22190650.6A patent/EP4160993A1/en not_active Withdrawn
- 2015-12-24 ES ES17186964T patent/ES2930016T3/es active Active
- 2015-12-24 EP EP17186964.7A patent/EP3264722B1/en active Active
- 2015-12-24 EP EP15202716.5A patent/EP3038323B1/en active Active
- 2015-12-24 ES ES15202716.5T patent/ES2670419T3/es active Active
- 2015-12-24 PL PL15202716T patent/PL3038323T3/pl unknown
-
2016
- 2016-12-29 HK HK18108411.4A patent/HK1249973A1/zh unknown
-
2017
- 2017-08-16 US US15/678,826 patent/US10225619B2/en active Active
-
2019
- 2019-01-17 US US16/250,570 patent/US10992998B2/en active Active
- 2019-10-30 JP JP2019197141A patent/JP6839746B2/ja active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6275470B1 (en) * | 1999-06-18 | 2001-08-14 | Digital Island, Inc. | On-demand overlay routing for computer-based communication networks |
| US7388841B2 (en) * | 2003-10-20 | 2008-06-17 | Mitsubishi Electric Research Laboratories, Inc. | Selecting multiple paths in overlay networks for streaming data |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2019164250A1 (ko) * | 2018-02-20 | 2019-08-29 | 삼성전자 주식회사 | 완전 연결 네트워크의 데이터 입력 및 출력을 제어하는 방법 및 장치 |
| US11755904B2 (en) | 2018-02-20 | 2023-09-12 | Samsung Electronics Co., Ltd. | Method and device for controlling data input and output of fully connected network |
| WO2019245181A1 (ko) * | 2018-06-20 | 2019-12-26 | 네이버 주식회사 | 적응형 데이터 전송을 위한 방법 및 시스템 |
| KR20190143072A (ko) * | 2018-06-20 | 2019-12-30 | 네이버 주식회사 | 적응형 데이터 전송을 위한 방법 및 시스템 |
| US12003797B2 (en) | 2018-06-20 | 2024-06-04 | Naver Corporation | Method and system for adaptive data transmission |
| KR20200037015A (ko) * | 2018-09-28 | 2020-04-08 | 한국과학기술원 | 컨텐츠 인지 신경망을 이용하여 실시간으로 적응형 비디오를 전송하는 방법 및 장치 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP3038323B1 (en) | 2018-02-28 |
| US10992998B2 (en) | 2021-04-27 |
| KR20220151224A (ko) | 2022-11-14 |
| MX2017008157A (es) | 2018-02-13 |
| EP3264722B1 (en) | 2022-08-17 |
| BR112017013811A2 (pt) | 2018-02-27 |
| US20160192029A1 (en) | 2016-06-30 |
| ES2930016T3 (es) | 2022-12-05 |
| EP3264722A1 (en) | 2018-01-03 |
| KR102462384B1 (ko) | 2022-11-03 |
| US10225619B2 (en) | 2019-03-05 |
| CN107223325A (zh) | 2017-09-29 |
| EP4160993A1 (en) | 2023-04-05 |
| JP2018507660A (ja) | 2018-03-15 |
| JP6612355B2 (ja) | 2019-11-27 |
| JP2020039140A (ja) | 2020-03-12 |
| WO2016103051A1 (en) | 2016-06-30 |
| ES2670419T3 (es) | 2018-05-30 |
| JP6839746B2 (ja) | 2021-03-10 |
| HK1249973A1 (zh) | 2018-11-16 |
| PL3038323T3 (pl) | 2018-08-31 |
| US20190158930A1 (en) | 2019-05-23 |
| US9769536B2 (en) | 2017-09-19 |
| US20170347157A1 (en) | 2017-11-30 |
| EP3038323A1 (en) | 2016-06-29 |
| CN107223325B (zh) | 2021-03-26 |
| MX370809B (es) | 2020-01-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10992998B2 (en) | Method and system for adaptive virtual broadcasting of digital content | |
| KR102569433B1 (ko) | 예상 오버레이 네트워크 아키텍처 | |
| US9838724B2 (en) | Media distribution network for live streaming | |
| Mukerjee et al. | Practical, real-time centralized control for cdn-based live video delivery | |
| CN113301096B (zh) | 内容分发网络中节点间数据传输方法、系统及节点设备 | |
| CN103945198A (zh) | 一种控制视频监控系统流媒体路由的系统和方法 | |
| Bouten et al. | A multicast-enabled delivery framework for QoE assurance of over-the-top services in multimedia access networks | |
| Huang et al. | Design of a P2P live multimedia streaming system with hybrid push and pull mechanisms | |
| Ozcelik et al. | Chunk Duration--Aware SDN-Assisted DASH | |
| Khalid et al. | An SDN-based device-aware live video service for inter-domain adaptive bitrate streaming | |
| Dubin et al. | Hybrid clustered peer-assisted DASH-SVC system | |
| Bouten et al. | An autonomic delivery framework for HTTP adaptive streaming in multicast-enabled multimedia access networks | |
| US20140181261A1 (en) | Method and apparatus for providing efficient transmission of streaming video through a complex ip network | |
| BR112017013811B1 (pt) | Método e servidor de broadcast virtual de conteúdo digital | |
| Heikkinen et al. | Dynamic and intelligent sand-enabled cdn management | |
| Seung et al. | Randomized routing in multi-party internet video conferencing | |
| Mann et al. | cStream: Cloud based high performance video delivery network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A201 | Request for examination | ||
| E902 | Notification of reason for refusal | ||
| E701 | Decision to grant or registration of patent right |