用于数字内容的自适应虚拟广播的方法和系统与流程

相关申请的交叉引用

本申请要求于2014年12月26日提交的美国临时专利申请no.62/096,938的优先权，由此通过引用将其全文公开并入本文。

本发明一般涉及用于在底层网络的节点之间传送数字内容的覆盖网络架构，更具体地，涉及一种优化数字内容在沿着覆盖网络的节点之间的路由的虚拟广播系统，该覆盖网络是基于对底层网络内的组件互连处的频繁改变的拥塞级别的预报来动态地重新配置的。

背景技术：

网络拥塞

随着有线和无线网络流量持续呈指数增长，网络中组件之间的共享链路或互连的有限容量正变为越来越相关且令人不安的问题。此外，因为这些共享链路处的拥塞级别是动态的，并随着网络流量的下降和流动而遭受极大的不稳定性，所以这种拥塞难以在任何给定的时间进行测量，且甚至在近期也特别难以预测。

这个问题有点类似于人口稠密地区共享道路和高速公路的交叉路口处的交通拥堵问题。虽然现有的gps导航和交通控制系统测量这些路口的当前拥塞状态并计算各个司机绕过这种拥堵的重新路由的最佳路径，但这些系统事先为任何特定司机预测最佳路由的能力受到交通拥堵的不稳定特性的阻碍。

当诸如netflix之类的单个公司占互联网高峰流量的三分之一以上时，同时通过互联网提供数字信息(特别是大量线性数据)的公司必须以某种方式解决互联网拥塞的日益不稳定的特性。类似地，随着移动语音和数据使用的快速增加，受监管的rf频谱的有限可用性尤其受到开发高带宽移动应用的公司关注。

虽然本文中在通过互联网向大量并发用户传送流传输视频的上下文中描述本发明的特定应用，但是本发明的原理同样适用于网络组件之间的共享链路的有限容量约束了对可被转换为数字格式的任何类型的信息(例如，音频、图像、3d模型等)的路由的众多其他上下文。本发明的其它潜在应用包括例如voip、公司视频会议、虚拟现实、多玩家游戏以及各种其他带宽密集型应用(在任何给定时间点相对于底层网络内的共享链路的拥塞级别而言)。

如下面将更详细地讨论的那样，本发明并不“治愈”诸如互联网之类的底层网络内的组成链路处的有限容量或“网络拥塞”的问题，而是通过以下方式来有效地利用该有限容量：监视并分析那些链路上的网络流量，以优化数字内容在基于对那些链路上的拥塞级别的预报来动态重新配置的覆盖网络的节点之间的路由。

视频流传输事件

由于互联网和基于ip的路由的出现，出现了许多通过互联网流传输视频的方法。在讨论其相对优点和缺点之前，回顾并考虑正在解决的问题是有帮助的。要通过互联网分发视频内容，必须先对视频内容进行捕获和数字化。我们可以将视频内容描述为“实况地”捕获到(或数字地生成)并通过互联网分发的“事件”。本文中提及视频事件包括视频和音频二者以及关联的任何元数据的捕获或生成。

视频事件可以是调度的或非调度的。例如，“超级碗(superbowl)”是一个调度事件，因为它发生的时间是事先知道的，而其他事件(例如，自然灾害、幼儿的第一步、甚至视频点播“vod”)是非调度的，因为它们可能在很少或没有提前警告的情况下发生。

视频内容可以在随着传递任何其他类型的文件(例如，经由“ftp”或文件传输协议)一起通过互联网分发之前被全部捕获以生成数字化视频文件。然而，这种“文件传递”方法对接收者观看(播放)视频内容造成延迟，即，接收者必须等到整个文件已被传递才能观看视频内容。假设是文件大小相对较大的数字化视频，这种延迟可能很大。

因此，视频内容经常被“流传输”给用户，使得在内容仍然被发送的同时用户就可连续地接收和观看该内容。实质上，视频内容被分为多个小文件或“视频段”(例如，长度为1到10秒)构成的有序线性流，所述小文件或“视频段”被传送给用户，用户可以在接收它们时开始观看它们。为了观看无延迟或无抖动的视频内容的连续流，每个视频段必须以规律的间隔播放，例如每秒30帧(fps)。但是，要注意，视频段并不需要以规律的间隔接收，只要每个段在先前段的播放结束之前收到即可。

无论事件是调度的还是非调度的，它都可被“实况”(即，在事件发生时)流传输或被“预先录制”供在事件发生之后的任何时间流传输。例如，超级碗可以在事件发生时被捕获并流传输，或者被预先录制供在以后的时间流传输。

最后，无论事件是调度的还是非调度的，以及无论其是预先录制的还是在事件发生时实况流传输的，都可以“实时”地流传输(即，从发送者到接收者的延迟在很大程度上感觉不到)或者在传输中“延迟”几秒甚至几分钟。例如，通过互联网但不是实时流传输的电视节目(例如，棒球比赛)的观众可能在彼此不同的时间上体验该流传输的事件，或与观看通过线缆或卫星广播的同一节目的观众在不同时间上体验该流传输的事件。这种延迟(特别是如果超过几秒钟)可能会降低用户的“体验质量”(qoe)，即以用户为中心的或应用级视角的质量，这与“服务质量”(qos)形成对比，服务质量是基于以网络为中心的度量(例如，分组延迟、分组丢失或由路由器或其他网络资源引起的抖动)的性能测量。

例如，由于观众在不同时间经历相同事件这一事实，观众之间的社交互动可能受到限制(完全不同于抖动或其他视频伪像)。当通过许多不同的方式(从广播电台或电视到社交媒体和其他互联网服务，经由手机、台式机和膝上型计算机可访问的方式，以及经由消费电子设备的不断发展的领域的方式)实时传达许多事件(调度的或非调度的)的今天，这特别会成为问题。

因此，期望视频流传输系统处理非调度事件和调度事件，流传输实况的和预选录制的事件，以及以最小延迟实时流传输这些事件，以便为观众提供一致的qoe。而且，随着流传输视频事件的并发观众的数量增加，保持一致的qoe成为一个棘手的问题。为此，可扩展性是任何此类系统的关键设计目标。

尽管最近在视频流传输技术方面取得了进步，但是互联网基础设施的历史性的“adhoc”演进仍然对基于互联网的视频流传输造成了重大的障碍，不仅仅在于其不一致的qos，这还导致网络拥塞在时间上和在互联网上的位置很难预测。虽然本发明的一个关键目标是为流传输视频事件的观众保持一致的qoe，但是该目标受到互联网上基本上不能消除的网络拥塞的限制。

底层互联网架构

从arpanet(用于实现互联网协议组或tcp/ip的最早的分组交换网络)开始，以及随后的nsfnet，互联网“骨干(backbone)”被设计为冗余的“网络之网”(即互联网)，其通过分散控制和为信息提供备选通信(路由)路径以达到其期望目的地来提供可靠性或“弹性”。然而，对于在路由器和其他共享网络资源之间遵循不同路径的分组，在互联网上维持一致的qos或qoe仍然是一个非常困难的问题。

随着互联网骨干的演进和私有化，传统骨干网络与长途电话运营商拥有的骨干网络之间的冗余和重叠也发展了。出于本说明书的目的，我们区分大型“公共”网络和大型“私有”骨干网络，大型“公共”网络直接向用户提供数据或者通过其他较小的“互联网服务提供商”(isp)网络向用户提供数据，大型“私有”骨干网络仅在它们自身之间携带数据或者用作大型isp之间的渠道，但不直接向客户提供数据。在这两种情况中的任一情况下，这些大型公共网络和大型私有网络通常被实现为通过光纤干线(即多条光纤线缆捆绑在一起以增加网络容量)互连的“光纤环”。

出于路由目的，携带最大网络流量的最大网络提供商(例如，大型isp和私有骨干网络)被分配称为“自主系统”(as)的ip路由前缀块，其中每个ip路由前缀块被分配“自主系统号”(asn)。我们通过asn来指代这些公司拥有的每个大型光纤环。asn的数量近年来急剧增长，从15年前的大约5000个asn到今天全球超过50,000个asn。如上所述，许多大型网络提供商也拥有不为客户提供服务但可以连接到他们自己的“公共asn”或其他人所拥有的asn的骨干光纤环网(即私有asn)。

由于不同的公司拥有自己的asn，它们彼此签订协议，以促进跨越asn的和遍及全球互联网的互联网流量的路由。每个asn采用称为“边界网关协议”或bgp的路由协议，使用通常称为“对等点(peeringpoint)”的一组路由器来控制对另一asn的访问。任何给定的asn可以使用多个对等点来连接到多个不同的asn。互连的asn可以是地理上相邻的，或者可以相距很远，经由跨越很远距离的长光纤干线连接的(例如，跨国家甚至跨海洋)。公共asn也可以经由“私有asn”或骨干网络互连。

监视asn内部的和asn之间的qos是非常困难的。大型网络提供商将自己的asn内的大部分路由和性能信息(包括动态拥塞度量)保留为专有的。虽然(目前的bpg版本4的)“开放消息格式”在建立到bgp路由器的tcp/ip连接时提供了某些信息的“数据转储”，但这种机制在实际中并不是非常有用。许多bgp路由器不支持开放消息格式，而其他路由器则简单地将其关闭。此外，该信息通常是5分钟过时，考虑到互联网上拥塞级别变化的频繁程度，这是相对较长的时间。

由于这么大量的互联网流量流经用于互联asn的相对高带宽的对等点，所以这些对等点通常是关键“瓶颈”或者是在任何给定时间在互联网上的大部分拥塞的来源，这不同于asn内的“最后一公里”问题(即，最终用户与其“网关”isp之间相对较低带宽的有线和无线连接上的拥塞)。

例如，随着跨asn对等点的流量负载增加，对等点每侧的asn中的路由器变得拥塞。换言之，这些路由器经历着对ram、cpu和其他容量有限的共享资源的高利用率。对这些资源的增长的需求降低了这些对等点上的性能(例如，比特速率)，并且最终可能导致丢失数据分组。由于互联网上的网络流量不是集中控制的，所以很难预测在任何给定的时间互联网上的频繁变化的“对等点拥塞”级别。

如果不能保证在asn内和asn之间保持一致的qos，那么为流传输视频事件的观众保持一致的qoe变得非常困难。通过互联网流传输视频的任何系统都受到共享路由器的不可靠性和不断变化的拥塞级别的影响，特别是在流过非常多互联网流量的asn对等点处更是如此。当将视频通过互联网(特别是跨这些asn对等点)流传输给大量并发观众时，这个问题更加严重。

现有的视频流传输方案

在过去几十年中，通过互联网流传输视频的各种方案已经得到演进，其中，大量术语被利用来表征和区分用于生成(在互联网之上的)覆盖网络拓扑并在沿着这些覆盖网络的网络节点之间传送视频内容的不同技术。在比较不同的方案时，简单地回顾gps导航模拟并考虑影响在任何两个点或节点之间行进所需时间的因素，即距离、速度和拥塞(通常通过沿不同路径重新路由来解决)，这是有帮助的。

在互联网上路由分组的上下文中，距离(或地理邻近度)不是直接相关的，因为分组的行进接近光速。然而，速度受到沿着路由遇到的停靠点或路障的数量的影响，或者在这种上下文下，受到在两个节点之间的中间路由器处遇到的“跳(hop)”的数量的影响。因此，如果两个节点只隔着相对较少的跳数，则可以将其称为彼此“接近”(在“网络邻域”中)，而不管它们的地理邻近度如何。沿着两个节点之间的路径的中间节点处的拥塞会影响总体行进时间，并且可以通过动态地重新路由流量(即，动态地重新配置确定两个节点之间的路径的覆盖网络)来解决。如下面将要讨论的，这些因素用于阐明在互联网上流传输视频的不同方案之间的关键区别。

在互联网之外传送视频的最常见的方法是将视频流(例如，电视节目)从“起点(pointoforigin)”同时广播给所有目的地观众，例如经由专用线缆或卫星基础设施来广播。虽然网络集线器可能被用在lan中向所有网络节点广播信息，但在互联网上跨交换机和路由器广播视频段的分组将会是非常不切实际和低效的。大多数网络用户不会对观看视频内容的任何给定的“频道”感兴趣，并且由于向其他路由器广播视频段的路由器将被迅速压垮，在起点附近将会出现明显的拥塞。对于通过互联网将视频内容频道从单个起点传送给可能随时加入频道的大量并发观众而言，广播解决方案是不可行的。

备选的“多播”方案涉及将每个视频段从起点同时流传输给互联网上的预定义的节点组。这种方法对于通过互联网进行大规模视频分发同样不切实际。此外，需要专门的基础设施，例如具有多播功能的专用路由器，这对于大规模商业使用也是不切实际且昂贵的。

与广播和多播技术相比，视频流传输的“单播”方案涉及将视频段从起点发送给单个目的地节点(例如，通过与所定义的目的地节点ip地址建立tcp/ip连接)。但是，向每个观看节点同时传送大量单播分组也将会迅速压垮起点处或起点附近的路由器，并且由于上述许多原因而无法实现一致的qos，更不用说提供足够以处理这样大量的同时传输的带宽所需的巨大成本。

一些vod公司(如netflix和youtube)采用了这种单播方案的变体，其通常依赖于昂贵的“边缘服务器”基础设施。这种方案(有时称为“内容传送网络”或cdn)涉及在互联网上部署多个物理服务器，并将每个视频内容频道的副本分发给每个服务器。因此，观看节点可以从附近(在网络邻域内，即与观看节点仅相距相对较少的跳)的服务器接收所需的视频内容。

每个边缘服务器通常具有相当大的带宽和计算能力，并且基本上构成单独的视频内容源，附近的观看节点可以在任何时间点从该视频内容源(“按需”)获得任何视频内容频道。这种添加物理基础设施的方案有点类似于建造附加的高速公路和出口，以使更多的人能够更快地(较少的转弯和更少的时间花在较慢的道路上)到达热门目的地。

虽然不同的用户通常希望在任何给定时间观看不同的视频频道，但是vod系统偶尔会面临“高峰”需求时段，在此期间，特定的视频事件必须被流传输给大量的并发观众(例如，流行电视剧的最后一集)，这甚至可能压垮最大的流传输视频公司的基础设施，或者至少导致昂贵的基础设施的低效“最坏情况”部署，其中昂贵的基础设施经常未被充分使用(即在非高峰需求的更常见的时间段)。备选的vod解决方案已经尝试通过在网络节点本身之间复制和分发视频内容来避免对昂贵的边缘服务器基础设施的需求(例如，在美国专利公开no.2008/0059631中所讨论的)。

无论是否使用昂贵的边缘服务器基础设施，这些vod解决方案都不能解决非调度视频事件的qos问题，因为它们都依赖于“预播种(pre-seeding)”边缘服务器或者整个互联网上的观看节点预先知道内容，以确保附近的视频内容来源。流传输实况的非调度事件将需要将视频内容实时并发传送给所有这些边缘服务器或观看节点，这是这些vod系统中任何一个都没能解决的问题。

最近，某些基于单播的视频流传输标准(例如，“webrtc”)已得到演进，以促进台式机网络浏览器和移动网络浏览器之间视频的“点对点”流传输，而不需要任何插件。许多现有的智能手机以及台式计算机和笔记本计算机都包括webrtc库和“自适应流传输”库，其中webrtc库支持浏览器到浏览器视频流传输，以及“自适应流传输”库使观看节点能够实时检测其带宽和cpu容量，并自动请求较低或较高的“比特速率”来适配这些度量的改变。

自适应流传输实现包括苹果的“http实时流传输”(hls)、微软的“平滑流传输”和“mpeg-dash”iso标准等。在典型的点到点视频流传输场景中，接收节点周期性地向http服务器请求“清单文件”，所述清单文件包括即将到来的(例如，接下来的八个)视频段的每个可用比特速率版本所在的位置。例如，每个视频段可能存在1080p、720p和480p版本可用，不同版本反映出不同的“视频分辨率”，不同的视频分辨率需要不同的流传输比特速率(带宽)，以确保每个视频段不管其分辨率如何都在基本上相同的时间量内传送。

标准的html5视频播放器(在支持webrtc的网络浏览器中)通常会在其开始播放视频内容之前缓冲三个视频段。它们使用当前的清单文件向http服务器发送针对每个视频段的http请求。发送节点然后根据webrtc标准将每个视频段(以小“块”的形式)推送给接收节点供在接收节点的网络浏览器中回放。如果接收节点支持自适应流传输实现，并且确定接收最近的视频段所需的时间显著增加或减少，则它自动开始从清单文件中的选择中请求较低或较高比特速率的视频段。换言之，它通过改变其请求的视频段的分辨率来随时间“适配”其实际带宽。

视频帧的“分辨率”是帧的宽度x高度(例如，1920×1080或1080p)或一帧中的像素数量这样的度量，而其“比特速率”指代从发送方向接收方发送的“每秒比特”数(bps)。例如，如果每秒传输30帧1080p分辨率的视频(每秒30帧或30fps)，并且每个颜色像素包含24比特(每像素24比特或24bpp)，则比特速率将等于接近1.5tbps(1,492,992,000bps，即1,492,992,000＝(每帧1920x1080像素或1920x1080ppf)x(24bpp)x(30fps)。

标准视频编解码器采用压缩(例如，mpeg2压缩)和其他视频编码技术来产生较低的有效比特速率(例如，3mbps)。鉴于上述情况，“比特速率”和“分辨率”是高度相关的，因为可以通过提供更高或更低分辨率的视频帧来增加或减少有效比特速率。因此，在这点上，我们某种程度上可互换地使用这些术语。

webrtc和自适应流传输标准允许几乎任何智能手机用户捕获和流传输实况视频事件，并且还使得这样的用户能够加入源自互联网上的另一起点(范围从其他个人智能手机用户到拥有大量视频内容的大型公司)的流传输视频频道。然而，这些标准被设计用于点对点视频流，并且不解决向互联网上的大量并发观众流传输视频频道的“视频传送”问题。

为了解决这个问题，一些视频流传输公司(例如，streamroot)采用了一种通常涉及“点对点”(p2p)或网格网络拓扑的方案，其中视频内容从一个观看节点转发到另一观看节点(有时称为“peercasting”)。在视频流传输的上下文中，这些术语可以互换地用于指代配置在互联网之上的覆盖网络，其使得观看节点能够以分布式方式彼此中继流传输视频内容。然而，应该区分向大量并发观众进行的流传输视频传送与p2p或网格网络拓扑的非流传输使用(其例如用于文件传递或文件共享应用的)。

p2p视频流传输系统将来自单个起点的视频内容频道传送给互联网上的大量并发用户。这样的系统往往趋向于是弹性的和可扩展的，因为它们的分布式特性有助于从个别故障点恢复(例如，通过经由其他节点重新路由内容)，并且随着越来越多的节点被添加到网络，其可靠性和性能实际上得到改善(即，因为更多更好的路由“中继”选项变得可用)。

当新节点加入视频频道或现有节点离开(停止观看)该频道时，p2p视频流传输系统必须在某种程度上动态地重新配置覆盖网络的拓扑，即修改网络节点中的至少一些路由路径以适应新的节点。例如，当添加新节点时，在选择新节点将从其接收(和将向其中继)视频内容的附近的现有节点的努力中可以考虑新节点的地理位置。

但是，如果仅基于其地理邻近度来选择“对等”节点，则它们仍然可能彼此相对“远离”(而不是位于网络邻域内)——例如，如果它们驻留在不同的asn中的话。因此，它们之间的流量可能跨越一个或多个潜在拥塞的对等点。例如，在接近的地理邻域中的两个节点之间的实际等待时间可能会超过那些节点中的每一个与在地理上遥远的节点之间的延迟之和。这种现象有时被称为“三角不等式违例”(triangleinequalityviolation，简称tiv)，其示出了依靠bgp路由在跨asn对等点的覆盖网络的节点之间传送数字内容的缺点。

现有p2p视频流传输系统的这个问题的一个原因是它们未被构造为与互联网的底层架构“兼容”。建立在互联网之上的任何覆盖网络拓扑仍然受到许多中断或故障点(不同于新节点或消失的节点)的影响，如上面提到的众多qos问题。因为没有解决互联网的底层qos波动(特别是在asn对等点处的qos波动)，这样的系统在向其用户提供一致的qoe方面面临重大障碍。

因此，现有的p2p视频流传输系统(如gps导航系统)依靠地理邻近度(而不是网络邻近度)来选择对等中继节点，并且一旦遇到拥塞，仅在“事后”重新路由流量。此外，线性数据到并发用户的实时流传输施加了在gps导航系统中没有发现的额外约束——内容必须“同时”到达每个节点处。边缘服务器和其他物理基础设施方案(类似于建设高速公路和出口以提供更高速的路由)是昂贵的，并且也无法充分解决非调度事件和任何特定事件的高并发使用的问题。

因此，需要一种解决上述缺陷的数字内容传送系统，并且在生成和动态重新配置覆盖网络时考虑互联网的底层架构(特别是流过如此多的互联网流量的asn对等点处)，以便为客户端节点提供一致的qoe。

技术实现要素：

根据本发明，关于数字内容传送系统公开了新颖的方法和架构的各种实施例，该数字内容传送系统通过以下方式向底层网络(例如，互联网)上的节点的用户提供一致的qoe：(1)维护将底层网络的组件(例如，asn和将其互连的对等点)互联的共享链路的地图，包括组件之一内(例如，在asn内)的每个节点的位置；(2)通过监视沿着建立在底层网络(互联网)之上的一个或多个覆盖网络的使那些共享链路(asn对等点)交叉的节点之间的网络流量来生成度量；(3)随时间分析所述度量和所述地图，以预报反映共享链路(asn对等点)随时间改变的容量的拥塞级别；以及(4)基于所预报的拥塞级别动态地重新配置覆盖网络的拓扑，以生成数字内容在沿覆盖网络的客户端节点之间的最佳路由。

本文中在一个或多个视频内容频道的观看者之间提供一致的qoe的上下文中描述了本发明的“虚拟广播”系统的具体实施例，在所述上下文中每个频道都从单个起点向潜在大量并发观众(其可在不同时间加入该频道)进行实时流传输(同时避免对边缘服务器或其他昂贵的物理基础设施的需求)。如下面将更详细地解释的，我们在向并发用户进行线性内容的单播流传输的上下文中使用术语“虚拟广播”。尽管使用单播流传输来路由内容，但是从用户的观点来看，内容是“广播”给他们的，因为它们同时接收内容。在许多其他上下文中，本发明的其他实施例对于本领域技术人员将是明显的，在所述许多其他上下文中，网络组件之间的共享链路的有限容量限制了对可被转换为数字格式的任何类型的信息的路由。

出于本说明书的目的，并发地接收多个不同频道的单个节点可被认为是不同的覆盖网络上的不同节点，每个节点由单个频道定义。在vod上下文中，对特定节目的每个单独的“放映”可被认为是具有其自己的观看节点网络的单独频道。

本发明的系统能够处理未调度的事件和调度的事件，流传输实况事件和预先录制的事件，并且通过高度可伸缩的方式以最小的延迟实时流传输那些事件，其在大量的并发用户之间保持了一致的qoe，尽管是在建立在互联网上的受到互联网的qos波动影响的覆盖网络上实现的。系统的性能和用户的qoe实际上会随着并发用户的数量(特别是在任何给定的asn内)的增加而提高。

采用客户端-服务器架构来集中服务器端路由决策。通过动态可重新配置的p2p覆盖网络实现视频内容的分布式流传输，所述动态可重新配置的p2p覆盖网络支持视频内容在每个视频频道的观看节点之间被中继(即“推送”给观看节点)。客户端节点可能会使用标准的html5视频播放器(内置于大多数台式机网络浏览器和移动网络浏览器中)来查看或播放视频，并依靠自定义的嵌入式代码(如javascript)来实现附加功能，例如管理视频段的接收，将那些视频段中继给其他节点，以及监视各种性能度量。在其他实施例中，这些功能中的一些或全部可以集成到定制应用或移动app中。

本发明的系统有助于台式机网络浏览器和移动网络浏览器之间的“点到点”视频流传输，并通过自动请求更低或更高比特速率的视频段来适配节点带宽的变化。在一个实施例中，虚拟广播系统采用单播标准(包括webrtc和自适应流传输标准(例如hls、mpeg-dash或平滑流传输)以促进视频流传输，而不需要网络浏览器插件，并且使得节点能够检测它们的性能能力，如带宽和cpu容量。

将每个事件提供给中央“虚拟广播服务器”，以便“起点”通过多个动态可重新配置的覆盖网络将每个频道传送给并发用户。事件可以从几乎任何来源(包括cdn)获得，无论是作为完整文件传递还是实况流传输给虚拟广播服务器。在使用webrtc的实施例中，具有实现webrtc的智能手机的任何用户可以上载预先录制的视频事件，或者实况捕获事件并将其上载到虚拟广播服务器(以及查看从虚拟广播服务器流传输的其他频道)以供后续经由覆盖网络向用户传送。

在一个实施例中，虚拟广播服务器包括“poi内容服务器”，该“poi内容服务器”担当每个频道的起点，从该起点经由构建在互联网之上的的动态可重新配置的覆盖网络传送视频段。视频段通常是大小固定的(例如，从1到10秒)，该大小由视频事件的始发发行者确定。视频段被客户端节点观看，并沿着通过覆盖网络定义的路由逐节点地“推送”(即，根据webrtc标准，作为各个固定大小的“块”来中继)。在一个实施例中，当通过mpeg2传输协议流传输时，每个视频段被划分成64kb块以匹配udp数据报“分组”的大小，以获得最大的效率。

虽然在大多数情况下视频段被有效推送到每个客户端节点，但是在一个实施例中，客户端节点可能检测到视频段的所有块都没有及时到达，并且可以利用当前清单文件来向poi内容服务器(即，作为“回退”馈送位置)请求该视频段。

当每个节点寻求加入通过poi内容服务器可获得的频道时，该节点确定(在另一个实施例中，在虚拟广播服务器的协助下)该节点所驻留在的特定asn。虚拟广播服务器利用该“asn位置”信息，连同互联网的动态“asn互连地图”(包括asn及其各种对等点互连)以及各种监视到的性能度量，来优化频道内容在覆盖网络之间的路由，所述覆盖网络是基于对这些asn对等点处的拥塞级别的预报来动态重新配置的。在另一个实施例中，除了每个节点的asn位置之外，虚拟广播服务器还利用其地理位置来协助该过程。

在一个实施例中，覆盖网络的拓扑定义了视频段在观看节点之间的路由路径，并且针对频道的每个视频段是可动态(整体或部分)重新配置的。在另一个实施例中，它们被针对视频段的每个块来动态地(整体或部分地)重新配置。以这种方式，在确定视频频道的每个视频段的最佳路由路径时，考虑互联网的架构(以及asn对等点处的预报的拥塞级别)。在另一个实施例中，如果沿着覆盖网络的一些或所有路由能够及时地传送视频段(即使这样的路由是非最优的)，则不重新配置这样的路由，直到满足预定义的拥塞阈值为止，或者直到识别出另一足够严重的问题时才会重新配置路由。

在一个实施例中，客户端节点监视与例如互联网上的最后一英里问题和qos问题(包括asn对等点处的拥塞)以及由虚拟广播系统自身的一个或多个频道的并发观众的数量引起的拥塞相关的性能问题。它们监视联系互联网上的和跨asn的指定站点所需的时间，以及将视频段中继到其他节点所需的时间。将客户端监视到的度量传递给虚拟广播服务器，以用于进行动态路由决策。在一个实施例中，虚拟广播服务器包括通过标准网络套接字(websocket)协议与客户端节点通信的“信令服务器”。

客户端节点可选地包括“上载器”，所述上载器使用户能够捕获视频事件并将其实时上载到虚拟广播服务器。因为从任何客户端节点到虚拟广播服务器的路径可能跨多个asn，所以使用自定义“淋浴(showering)”协议来促进视频事件的流传输，并避免分组在中间路由器处被延迟或阻塞。在一个实施例中，客户端节点还可以通过虚拟广播服务器上的“泼溅提取器(splashextractor)”搜索引擎来搜索并查看“趋势”事件(这里称为“泼溅(splash)”)，所述搜索引擎识别泼溅，并且基于用户搜索向用户提供能够流传输和查看来自互联网上的趋势事件的能力，该能力通过poi内容服务器原本是不可用的。

在节点请求加入频道时，虚拟广播服务器基于节点的中继能力(即其可靠的“上游”带宽)对节点进行分类，该中继能力是根据各种因素推导出的，所述因素包括其连接类型(例如，3g或4g蜂窝、wifi、lan等)以及其cpu、操作系统、浏览器和内存配置，以及随时间监视到的其他固定的和可变的性能指标。在一个实施例中，根据节点的相对中继能力将节点分为三个级别。最低级别节点(“c”节点)可以查看视频段，但不能将视频段中继给其他节点。中间级别节点(“b”节点)可以查看视频段并在asn内中继视频段。最高级别节点(“a”节点)可以查看视频段并将视频段中继给asn内部的和跨越asn的其他a节点。

在另一实施例中，可以例如基于监视到的性能度量以及系统对于给定分类的更多或更少的中继节点的当前需求来动态地改变节点分类。另外，如果在asn内存在足够多的a节点来中继视频段，则可以将a节点指定为“b∶a”节点，指示它将被视为b节点，但是如果需要(例如，如果现有的a节点离开了频道)，则可以升级为a节点。在一个实施例中，如果单个节点在性能上表现出显著的改变(更好或更差)，则可以对该节点重新分类(例如，从b节点到c节点，反之亦然)，以及如果问题自身得到解决，则恢复到该节点的初始分类。

在另一实施例中，客户端节点被分配多个“时隙”(例如，基于其能力和客户端性能度量)，以使得它们能够向多个其他节点中继视频段的块以及从多个其他节点接收视频段的块。在该实施例中，客户端节点仅从一个“馈送”节点接收视频段，但是可以将该视频段“馈送”或中继给多个其他客户端节点。最多向a节点分配8个中继时隙，其中4个用于中继至同一asn内的a个节点，4个节点用于中继到其他asn中的a个节点，即跨越asn对等点。最多向b∶a和b节点分配8个时隙，用于中继到其asn内的其他客户端节点(即其他b∶a、b和c节点)。在另一实施例中，客户端节点可以由多个其他客户端节点(例如，通过将块在多个输入时隙之间交替)进行“馈送”。该技术可以用于需要更高性能的高比特速率(例如，4k)视频流。

在另一实施例中，某些节点(例如，基于其能力和客户端性能度量)可以从单个馈点节点接收视频段的多个分辨率(或在备选实施例中，从不同馈点节点接收不同分辨率)。如果这些节点的上游带宽足够，则它们可以被认为是“聚播(polycast)”节点，并且在所需的程度上还可以将视频段的这多个分辨率版本中继或馈送给一个或多个指定节点。

为了促进覆盖网络的动态重新配置，虚拟广播服务器采用“深度映射器”深度学习引擎，所述“深度映射器”深度学习引擎连续分析性能度量以预测跨asn对等点的拥塞级别，即预测将来短时间(例如，1分钟)内asn对等点的拥塞级别。在一个实施例中，针对a节点之间的每个潜在的asn间路径(例如，从一个asn中的一个a节点到另一个asn中的a节点)生成预测的“拥塞值”。在另一实施例中，拥塞值反映了每对a个节点之间的最佳路径的预测的拥塞级别。

在一个实施例中，虚拟广播服务器使用“覆盖网络创建器”来生成并(全部或部分地)重新配置asn间覆盖网络和asn内覆盖网络，例如确定用于将视频段在asn内和跨asn地从一个节点向另一个节点推送的最佳路径。在该实施例中，覆盖网络创建器考虑每个节点可以利用的可用时隙的数量以及每个节点可以接收或中继的分辨率的数量。

覆盖网络创建器生成并动态地重新配置(在深度映射器的帮助下)跨asn的“虚拟数据干线”覆盖网络，其表示a节点的拓扑。换言之，它表示a节点以及视频段将遵循的在asn内的和(特别地)跨asn的那些a节点之间(即通过潜在的拥塞asn对等点)的链路或路由路径。

虚拟数据干线识别将被指示从附近的poi内容服务器(例如，使用当前清单文件)请求每个视频段的a节点的集合以及每一个都将推送该视频段的a节点的集合等等(在asn内和跨asn)。因此，该视频段将分布在包含观看节点的每个asn上。为了到达每个观看节点，该段也可能行进通过没有观看节点的临时专用骨干asn。

覆盖网络创建器还生成一个或多个asn内“群组(swarm)”覆盖网络，以将视频段从asn内的a节点中继到该asn内的b∶a、b和c节点。可以针对每个视频段(或者在备选实施例中，针对视频段的每个块)来(整体或部分)动态地重新配置这些群组覆盖网络。在一个实施例中，asn内的每个群组覆盖网络表示b∶a节点、b节点和c节点的分层拓扑(相对于asn内的a节点而言)，该b∶a节点、b节点和c节点在该群组分层体系中的节点之间接收、观看和中继(除c节点外)视频段。

因此，本发明的虚拟广播系统和方法通过监视和分析网络流量以优化数字内容在虚拟数据干线覆盖网络和群组覆盖网络的节点之间的路由，有效地利用asn对等点和其他拥塞关键点的有限容量，其中该虚拟数据干线覆盖网络和群组覆盖网络是基于对这些拥塞关键点处的拥塞级别的预报来动态重新配置的，从而在系统用户之间保持一致的qoe。

附图说明

图1是示出在互联网之上动态配置的本发明的覆盖网络的一个实施例的图；

图2是示出本发明的客户端流传输视频设备的关键的客户端侧组件的一个实施例的框图；

图3是示出本发明的虚拟广播服务器的关键的服务器侧组件的一个实施例的框图。

图4是示出本发明的动态视频流传输过程的一个实施例的流程图。

具体实施方式

在附图中示出并在下面描述本发明的系统和方法的详细实施例。首先应当注意，本发明不限于下面参照附图讨论的具体实施例。

如上所述，虽然在本文中在通过互联网向大量并发用户传送流传输视频的上下文中描述本发明的特定应用，但是本发明的原理同样适用于许多其他上下文中，在这些其他上下文中，网络组件之间的共享链路的有限容量约束了对任何类型的数字内容的路由。

即使在通过互联网传送流传输视频的上下文中，本文描述的客户端节点和服务器组件之间的功能分配也是设计折中的结果，并且大部分功能可以在客户端侧组件和服务器侧组件之间重新分配，而不会背离本发明的精神。类似地，客户端侧功能可以被分配到单个模块化组件中或分散在多个不同的组件中，并且可以被实现为一个或多个独立的应用或移动app，或者实现为独立应用或app和javascript或其他脚本或编程语言的组合。此外，服务器侧组件可以在单个硬件服务器上实现或跨多个不同的服务器实现。这样的功能也可以被集成到单个软件模块中，或者被分配在跨一个或多个硬件服务器分布的不同软件模块之间。

最后，在使用标准协议和库(例如，http、网络套接字、webrtc、stun和各种自适应流传输标准)的那些实施例中，由这些标准协议和库中的一些或全部提供的功能可以用其他标准或专有实现来替换，而不背离本发明的精神。

覆盖网络

图1是示出映射在互联网之上的本发明的覆盖网络100的一个实施例的图。尽管互联网本身可以以各种不同的方式进行示出，但是图1示出了作为经由对等点120互连的asn110光纤环的集合的互联网。在每个asn110内示出了在任何时间点观看特定视频频道的各个客户端节点。虽然在图1中未示出，但是多个频道可以并发地激活以及因此多个覆盖网络集合100(在一个实施例中)可以并发地激活。

如上所述，虚拟数据干线覆盖网络表示asn110内的a节点130之间的互连175(直接连接)和跨asn110的a节点130之间的互连175(即，经由对等点120)二者。骨干连接器195示出了经由私有asn(未示出)的两个asn110之间的a节点的互连，其中所述私有asn不包括任何商业节点而仅互连两个公共asn110。例如，骨干连接器195被示出为连接asn110-f中的a节点130与asn110-e中的a节点130。在这种场景下，那两个a节点130之间的流量可行进通过多个“私有”对等点120(或与私有asn的其他专有连接)。

如上所述，在一个实施例中，这样的连接的性能可以仅在端点(即，两个a节点130)处监视，如两个不同的公共asn110中的a个节点130之间的连接175(即，经由对等点120)的情况。沿相同asn110中的两个a节点130之间的连接175的流量可能会比跨asn110的流量相对更快，因为它不会穿过可能拥塞的对等点120。虽然使用单向箭头示出了背景连接器195以及来自/去往a节点130的连接175，但是这些仅反映当前的单向路由路径，尽管在图1所示的所有客户端节点之间都支持双向连接。

应当注意，本发明的任何两个客户端节点之间的所有流量穿过公共互联网，并且因此通过影响qos的各种中间路由器(未示出)。系统监视asn110内的和跨asn110(以及因此跨一个或多个对等点120)的qos影响。在一个实施例中，这样的asn内流量和asn间流量由每个客户端节点(在虚拟广播服务器的方向)进行监视，并被传送给虚拟广播服务器，以用于动态重新配置由覆盖网络100(包括a节点130之间的虚拟数据干线覆盖网络和从asn110内的每个a节点130到该asn110内的b(以及b∶a)节点140和c节点150的群组覆盖网络)表示的节点和路由路径。

图1示出了在这些覆盖网络100的“当前状态”的情况下视频段在客户端节点之间所遵循的各种路由路径。换言之，它示出了这些覆盖网络100的当前拓扑，在一个实施例中，可以针对每个视频段(并且在备选实施例中，针对视频段的每个块)动态地重新配置这些覆盖网络100。应当注意的是，对于任何特定的视频段，覆盖网络100可以(整体或部分地)重新配置也可以不(整体或部分地)重新配置，因为该决定将至少部分取决于随时间收集的性能度量。

asn110-c示出了这样的场景，其中poi内容服务器(未示出)驻留在asn110-c中或附近(例如，跨一个或两个其他asn110)，并且响应于将当前视频段传送给节点130-a的http请求来发起在沿着覆盖网络100的频道上的视频段的流传输。如将在下面更详细地讨论的，poi内容服务器通常将每个视频段传送给相同或附近的asn110中的多个发出请求的a节点130，并且这些a节点130将进而把视频段推送给沿覆盖网络100的多个其他节点，得到在任何给定时间点被传送到客户端节点并从其中继的视频段的多个并发副本的“再分发”。

在这种情况下，a节点130-a将视频段中继给两个其他a节点130，其中一个在asn110-c内，另一个跨对等点120到asn110-a。如上所述，虚拟数据干线覆盖网络表示当在asn110内的和跨asn110的a节点130之间中继视频段时该视频段将遵循的路由路径。因此，在这种场景下，视频段不仅在asn110-c内的多个a节点130之间进行中继，而且也从asn110-a跨各个对等点120中继到多个直接互连的asn(即，110-a、110-d、110-f和110-g)，从该多个直接互连的asn，跨虚拟数据干线覆盖网络的多个跳进一步中继到其他asn110。

如将在下面更详细地解释的，asn110内所需的a节点130的数量将取决于各种因素，例如该asn110内的其他客户端观看节点的数量以及它们的相对能力(由它们的分类、开放时隙的数量和随时间监视到的性能度量来确定)。例如，asn110-b、110-f、110-i和110-j各自被示出为仅具有单个a节点130，即使它们具有不同数量的要馈送的其他客户端节点(将asn110-f中的单个其他节点与asn110-i中的许多其他节点进行比较)。

虽然监视的节点的上游带宽是确定其将直接馈送多少个节点(即，将要使用多少个输出时隙)的关键因素，但重要的是要认识到，考虑到这些中继的实现的快速程度(通常在1ms以下)，asn110内的节点“链”(将视频段从一个节点中继到另一个节点，依此类推)的长度在很大程度上是无关紧要的。例如，asn110-i中的直接馈送外部asn110(asn110-g和asn110-j)中的两个a节点以及asn110-i内的两个b节点130的单个a节点使用4个输出时隙(在本实施例中反映出相对较高的监视到的上游带宽)。然而，从asn110-i中的该单个a节点间接馈送的b节点140和c节点150的长链并不是其上游带宽的反映。

在每个asn110内，生成一个或多个群组覆盖网络(在该实施例中针对每个视频段动态地重新配置)，以在该asn110内将视频段从每个a节点(即群组覆盖网络的“根”节点)中继给该群组覆盖网络内的各个b(以及b∶a)节点140和c节点150。虽然在asn110-c(与asn110-h中所示的两个群组覆盖网络相比)中仅示出了一个群组覆盖网络，但是每个asn110内生成的群组覆盖网络的数量(以及每个群组覆盖网络的内部拓扑)将取决于各种因素，例如该asn110内的客户端观看节点的数量，以及当前性能度量和历史性能度量、开放时隙的数量等。

如上所述，诸如asn110-b中的a节点130-b之类的客户端节点可以从多个其他客户端节点(在这种情况下，从不同asn(110-a和110-d)中的两个其他a节点130)接收视频段。在一个实施例中，出于性能原因，这两个其他馈送节点向a节点130-b交替发送视频段的块，例如，因为这些块跨越了其拥塞级别被连续监视的对等点120，如将更详细地解释的。在其他实施例中，这可以出于冗余的目的而进行，例如，因为基于历史性能度量(不同于对等点120的拥塞，或作为对等点120的拥塞的补充)，馈送节点的可靠性可能是有问题的。

监视性能度量、中继视频段和动态重新配置覆盖网络100的方法将在下文关于图4更详细地探讨，这将在对实现这些方法的关键的客户端侧(图2)和服务器侧(图3)的功能组件的讨论之后进行。

客户流传输视频设备

转到图2，客户端设备200示出了本发明的客户端流传输设备的关键组件的一个实施例。客户端设备200可被实现为台式计算机或膝上型计算机以及智能手机或其他移动设备，或实际上能够处理流传输内容(例如流传输视频)的任何其它消费电子设备。客户端设备200包括本领域公知的某些标准硬件和软件计算组件以及相关外围设备210，包括cpu212、存储器214、操作系统216、网络适配器217、显示器218和相机219。客户端设备200利用这些组件和外围设备210连同某些标准库220一起成为网络节点，并且接收、显示和在本发明的虚拟广播系统的其他网络节点之间中继流传输视频内容。

本发明利用实现网络协议和其他可用于促进设备之间流传输视频内容的功能的某些标准库220(其也在大多数智能手机以及许多其他计算设备上发现)。例如，视频内容可以在两个智能手机用户之间流传输，并在其移动网络浏览器上显示，而无需任何插件。标准库220包括webrtc222api(其促进用于流传输视频内容的浏览器到浏览器的通信)、各种自适应流传输224实现(例如，hls、mpeg-dash和平滑流传输等(其使得能够自动调整流传输比特速率以“适配”对客户端带宽和cpu容量的改变的实时检测结果))、网络套接字226协议(其促进单个tcp/ip连接上的快速双向客户端-服务器通信)和http228(用网络服务器和客户端网络浏览器之间不怎么频繁的标准通信)。

客户端设备200还包括标准播放器232(在一个实施例中，集成到标准html5网络浏览器230中的标准视频播放器)以查看或播放流传输数字内容。在其他实施例中，标准播放器232被集成到独立的台式机应用或智能手机app中。使用标准html5网络浏览器230的一个优点是，许多标准库220被设计为与网络浏览器一起工作，且因此不需要任何插件或者独立的台式机应用或智能手机app原本需要的其他自定义功能。

此外，网络浏览器还支持客户端侧脚本语言，例如javascript，它经常用于补充标准网络浏览器功能(例如，从标准网络服务器作为网页的一部分传递，而不需要任何客户端浏览器插件)。在一个实施例中，客户端设备200的非标准关键组件(包括通信器270、性能监视器240、接收机250、中继器260和上载器280)在javascript中实现，并且内容阵列255由该javascript代码生成和维护。然而，应当注意，在不背离本发明的精神的情况下，这些组件中的一些或全部可以以其他编程语言且在独立的台式机应用或智能手机app中实现。

标准库220促进了包括视频内容在内的内容的通用点对点(单播)流传输。客户端设备200的非标准关键组件解决了本发明的虚拟广播系统实现的数字内容传送架构的客户端侧方面。在一个实施例中，流传输协议构建在webrtc222之上，其中内容的路由经由客户端-服务器架构进行集中，并且内容本身经由动态可重新配置的p2p覆盖网络以分布式方式(逐节点地推送)流传输。

客户端设备200的用户可能通过各种不同的方式首次遇到一个或多个内容频道，例如，通过电子邮件中的链接或网页上的链接，或者甚至是来自独立的台式机应用或智能手机app。在一个实施例中，虚拟广播服务器300(将在下面关于图3更详细地讨论)向html5网络浏览器230传送具有频道选择的标准html5网页。该“频道网页”包括由html5网络浏览器230解释以实现客户端设备200的非标准组件的功能的专有javascript代码，所述非标准组件的功能包括与信令服务器330以及其他客户端节点通信(例如，使用webrtc222和自适应流传输224库)，以及接收、处理以及从这些节点和向这些节点中继视频段的块。

在点击频道网页中的频道链接时，用户生成加入当前正在流传输的视频内容的特定频道的请求，或者在另一个实施例中，将在稍后的预定义时间点开始流传输(“加入请求”)。虚拟广播服务器300的信令服务器330通过尝试经由通信器270建立与客户端设备200的网络套接字226连接来响应加入请求。如下面将关于图3更详细地讨论的，虚拟广播服务器300使用“stun”322协议来发现客户端设备200的公共ip地址(例如，在nat防火墙之后)，以便客户端设备200可以建立与虚拟广播服务器300的网络套接字226连接，以及与其他客户端设备200的webrtc222连接，以用于接收和中继视频内容。

在本文讨论的实施例中，客户端设备200在任何给定时间仅加入一个视频频道。在其他实施例中，客户端设备200可以同时加入多个频道，而不背离本发明的精神。

客户端设备200利用通信器270与信令服务器330进行双向通信，以便于在保持单个tcp/ip连接打开的同时快速交换消息。如将在下面更详细地讨论的，这种通信被用于各种目的，包括：(i)向虚拟广播服务器300提供关于客户端设备200能力的初始信息(例如，os、网络浏览器和连接类型(3g、4g、wifi、lan等))，(ii)使虚拟广播服务器300能够验证客户端节点连接，以用于后续的视频段经由覆盖网络100的webrtc222节点间流传输，以及(iii)与虚拟广播服务器300交换实时动态监视信息(经由性能监视器240获得，如下所述)。

在一个实施例中，包含在频道网页中的该javascript代码还分析了客户端设备200的能力，以确定它是否是c节点(其接收视频段但不将它们中继到其他客户端节点)，并将该信息提供给信令服务器330。在其他实施例中，客户端设备200的某些能力被发送给虚拟广播服务器300，虚拟广播服务器300确定客户端设备200是否是c节点。

该javascript代码还便于与poi内容服务器380的通信，以管理接收机250对视频段的接收，以供标准播放器232播放。该过程实际上是标准点对点视频流传输场景的扩展，其利用标准webrtc222和自适应流传输224功能。

在一个实施例中，标准网络浏览器230解释来自频道网页的专有javascript代码以如上所述地周期性请求清单文件。这样的标准http请求被定向到提供清单文件的poi内容服务器380。标准网络浏览器230还利用标准自适应流传输224库向清单文件中指定的位置请求视频段本身，包括如上所述的这些视频段的更高或更低比特速率版本(例如，当检测到带宽改变时)。

针对视频段的这些请求被来自频道网页的专有javascript代码拦截，即，因为每个视频段是从覆盖网络100的另一(馈点)节点向客户端设备200推送的(消除了对客户端设备200发起http“拉”请求的需求)。在一个实施例中(下面更详细地讨论)，虚拟广播服务器300在接收到加入请求之后不久将客户端设备200添加到覆盖网络100(并且因此添加到频道)，使得一个或多个初始视频段将被推送到客户端设备200，以使其能够尽快开始播放视频内容。

随着接收机250接收每个视频段的块，它生成内容阵列255，以便于视频段的接收和回放，以及将视频段(如果客户端设备200未被指定为c节点)中继到其他客户端节点。接收机250生成接收阵列256以将块汇编成完整的视频段，该视频段被提供给由标准播放器232维护的三段缓冲器(three-segmentbuffer)。如果在拦截针对视频段的http请求时，接收机250确定完整视频段尚未在接收阵列256中，则将向清单文件中指定的备选(或“回退”)位置(即，poi内容服务器380)请求该视频段。从标准播放器232的角度来看，它响应于标准的http请求而接收视频段，并且不知道视频段实际上被经由覆盖网络100推送给客户端设备200。

此外，在一个实施例中，接收机250还利用自适应流传输224库来将客户端设备200可以处理的比特速率(无论标准播放器232是否以正常方式经由清单文件作出这样的请求)传递给信令服务器330(经由通信器270)。例如，如果客户端设备200经历其带宽的临时显著下降(导致视频段未在需要之前到达接收阵列256)，则它可以向poi内容服务器380请求一个(回退)视频段，然后通过覆盖网络100推送后续的低分辨率视频段。一旦其比特速率恢复正常，则其可以如同发生问题之前一样推送更高分辨率的视频段。

如上所述，在一个实施例中，虚拟广播服务器300针对每个视频段动态重新配置覆盖网络100，包括虚拟数据骨干覆盖网络(在asn内和跨asn的a节点之间)和群组覆盖网络(从asn内的每个a节点到该asn内的其他节点)。除非客户端设备200被分类为c节点(其接收视频段但不将其中继给其他客户端节点)，否则，中继器260将从虚拟广播服务器300接收关于它将会把该视频段中继到的哪个或那些节点的指令(针对其加入的视频频道的每个视频段)。如上参考图1所讨论的，无论客户端设备200是a节点、b∶a节点还是b节点，都可被要求将视频段中继给多个其他客户端节点。

视频段的长度(例如，从1秒到10秒)由视频内容的发起者根据自适应流传输224标准来定义。中继器260将通过根据webrtc222标准的“rtcdatachannel”组件(其不强制执行信令协议)推送块来将视频段中继给每个指定的目的地客户端节点。

在一个实施例中，当通过mpeg2传输协议流传输时，每个视频段被划分成64kb的块以匹配udp数据报(分组)的大小，以获得最大的效率。客户端设备200每次一个块地发送和接收udp“分组”(根据webrtc222标准，在需要时回退到tcp)。例如，1秒的视频段将包含大约625个块(假定为1080p的h.264编码器，其产生大约5000kbps)。

随着接收机250接收每个视频段的块，它生成接收阵列256，以汇编这些块并构建完整的视频段。中继器260生成中继阵列257以汇编这些块，以便将它们发送(中继)给指定的目的地客户端节点。通过这种方式，中继阵列257担当视频段的输入块和输出块的缓冲器。如下面将讨论的，性能监视器240跟踪将整个视频段传送到每个指定的目的地客户端节点所需的时间，并将该度量报告回虚拟广播服务器300(以用于动态重新配置覆盖网络100中的后续使用)。

在一个实施例中，接收客户端节点从单个馈送节点(例如客户端设备200)接收视频段。在另一个实施例中，虚拟广播服务器300选择多个潜在馈送节点，并且它们之间进行通信以协商“前两个”候选(例如，基于当前带宽或其他所监视的性能度量)，且然后向指定的接收客户端节点交替地发送块。

在另一个实施例中，在a节点之间推送每个视频段的多个不同分辨率(例如，1080p、720p和480p)，并且虚拟广播服务器300指向每个群组覆盖网络的根部处的具有这些分辨率的a节点，以向该群组覆盖网络内的其他节点推送(例如，基于那些其他节点的能力，如下文更详细讨论的)。

在接收机250正在接收用于回放的视频段的块并且中继器260正在将这些块流传输给其他指定的客户端节点期间，性能监视器240收集虚拟广播服务器300所指向的各种静态和实时的动态性能度量，并且经由信令服务器330连续地将这些度量提供回虚拟广播服务器300。

如上所述，虚拟广播服务器300使用这些度量来动态地重新配置覆盖网络100，以优化下一视频段的路由。特别地，性能度量被用于对客户端节点进行分类和重新分类，对用于将视频段中继给其他客户端节点的时隙进行分配和解除分配，确定视频段的哪些分辨率可被接收并中继给其他客户端节点，以及最终在覆盖网络100被动态重新配置时修改客户端节点之间的路由路径的子集。以下将参考图3更详细地讨论虚拟广播服务器300利用这些性能度量的精确方式。

静态性能度量(例如操作系统、浏览器和连接的类型(例如，3g或4g蜂窝、wifi、lan等)不太可能频繁改变，并且通常仅在客户端设备200请求初始加入时才向信令服务器330报告(尽管其在发生改变的情况下将被报告，所述改变如从3g到4g的蜂窝连接改变)。

当动态信息可以连续收集和报告时(即当其被搜集时)，在一个实施例中会考虑到各种折中，以确保“开销”(监视并向信令服务器330的报告这些动态度量的频率)不影响视频本身的传送(即，向客户端设备200流传输块和从客户端设备200流传输块)的“有效载荷”或性能。在一个实施例中，这样的度量仅用于下一个视频段，而在其他实施例中，当前视频段的传送期间的下一个块(或多个块)可能会受影响发生改变。

在一个实施例中，执行两种类型的动态性能监视。第一种类型涉及对在因特网上的位于客户端设备200所在的asn内部和跨asn的已知站点(例如，对yahoo网络服务器、虚拟广播服务器等)的“ping”时间(或其他类似的测量)。分别地，这样的度量提供对客户端设备200的性能的洞察，同时它们提供了对在客户端设备200所驻留的asn内以及经由特定对等点跨asn的qos的附加洞察。虽然虚拟数据骨干覆盖网络(在a节点之中)相对更加引人关注(由于对等点处的拥塞)，asn内的拥塞也是有意义的(因为，例如可能需要动态重新配置asn内的一个或多个群组覆盖网络的至少一部分)。

另一种类型的动态性能监视涉及将视频段从一个客户端节点中继到另一个客户端节点所需的总时间。在一个实施例中，每个节点(c节点除外)记录将视频段的第一块发送给指定的目的地客户端节点时的“开始”时间，以及在接收到该视频段的最后一个块后的“停止”时间(例如，因为webrtc222标准提供每个分组的验证)。性能监视器240将(针对其发送的每个视频段的)该总时间发送给信令服务器330。该度量还可以提供不仅与客户端设备200的单独性能有关而且与其asn内和跨asn的拥塞级别有关的洞察(例如，如果客户端设备200是跨asn对等点向另一a节点馈送的a节点)。

在一个实施例中，客户端设备200的用户也可以是视频内容的发起者。在大多数情况下，这种场景是由于智能手机相机(例如相机219)的质量不断提高，使用户可以“随时随地”捕捉视频事件。但是，台式机计算机或膝上型计算机以及智能手机的用户也可能从其他来源获得预先录制的视频事件。

问题是，客户端设备200必须以某种方式将其视频内容通过因特网流传输给虚拟广播服务器300，该虚拟广播服务器300可能跨多个asn相距许多跳。上载器280经由专有“淋浴”协议解决了这个问题，以避免在中间路由器处udp分组被延迟或阻塞。在一个实施例中，上载器280通过客户端设备200上的专用智能手机app来实现，而不是依赖于更有限的客户端侧javascript功能。

为了实现这种淋浴协议，上载器280与虚拟广播服务器300建立tcp/ip连接，并采用udp“突发”来传送可用的最大ip分组大小(“最大传输单元”或mtu)。然而，连续的udp流(无论是经由单个路由器端口发送还是分布在多个路由器端口上)通常将被中间路由器检测为“拒绝服务”(dos)攻击，并从而被阻塞。此外，这样的udp流可能溢出路由器的所分配的存储器(例如，fifo队列)，因为路由器通常只在接收到udp分组(而不是更常见的tcp分组)时才为udp分组分配存储器。

为了解决这些障碍，上载器280不仅在多个端口(例如，在一个实施例中，6个端口)中分布udp分组，还延迟在任何单独端口上发送的分组，以避免被检测为dos攻击。在一个实施例中，每个端口上的延迟长得足以避免被检测为dos攻击，并且长得足以使得路由器能够分配足够的存储器，但短得足以提供足够的带宽以跨多个asn传送视频段，并且短得足以避免被视为udp流的结束(这将导致路由器停止为udp分组分配内存，并且基本上“将其丢弃”)。

当上载器280以这种方式将每个视频段传送给虚拟广播服务器300时，虚拟广播服务器300然后生成频道，以便沿着覆盖网络100重新分布该视频内容，就好像其已经从更传统的cdn接收到的那样。在另一个实施例中，虚拟广播服务器300在相对不常见的场景中使用这种专有的淋浴协议，在该场景中，它是针对当前视频段沿着覆盖网络100没有及时到达的客户端节点的视频段的回退起点源。

虚拟广播服务器

图3示出本发明的虚拟广播服务器300的关键服务器侧组件的一个实施例。如上所述，虽然虚拟广播服务器300的组件被示出在单个物理硬件服务器中，但是在不背离本发明的精神的情况下，可以在多个不同的物理硬件设备和不同的软件模块之间重新分配这些组件的功能。

虚拟广播服务器300包括在大多数硬件服务器中发现的某些标准功能，例如标准hw/sw310，如cpu312、存储器314、操作系统316、网络适配器317和显示器318。在某些实施例中，虚拟广播服务器300还利用标准库320，标准库320可以包括例如：(i)stun322协议(“用于nat的会话遍历实用程序”)，其便于发现在nat防火墙之后的客户端设备200的公共ip地址，使客户端节点可以向其他客户端节点发送视频和从其他客户端节点接收视频，并建立与虚拟广播服务器300的连接；(ii)网络套接字326协议，其有利于通过单个tcp/ip连接的快速双向客户端-服务器通信；以及(iii)http328，其被用于与客户端网络浏览器(例如，标准的html5网络浏览器230)的不怎么频繁的标准通信。

虚拟广播服务器300不需要支持webrtc222和自适应流传输224标准，因为它不是覆盖网络100上的客户端节点，尽管它不断分析从客户端节点获得的性能度量，并动态地重新配置视频内容频道的在沿覆盖网络100的这些客户端节点之间分布的路由路径。

虚拟广播服务器300担当覆盖网络100(具体地，虚拟数据骨干覆盖网络)的“频道发起者”起点。在一个实施例中，poi内容服务器380指定一个或多个附近的a节点(优选地在其asn中，如果可能的话)来发布对视频段的http请求。这些a节点有效地担当虚拟数据骨干覆盖网络的根部，且将每个视频段推送给asn内和跨asn的其他a节点，并最终经由每个asn内的群组覆盖网络推送给其他节点。

如将在下面参考poi内容服务器380更详细地描述的，这种“频道发起”功能不需要使用针对浏览器到浏览器视频流传输的标准webrtc222和自适应流传输224库。如上所述，poi内容服务器380还担当未及时接收沿着覆盖网络100的当前视频段的客户端节点的偶尔的备选(回退)视频段来源。这样的客户端节点发出http请求，poi内容服务器380通过向这样的客户端节点发送所请求的视频段来响应该http请求。

如上所述，poi内容服务器380担当所有视频频道的起点(在一个实施例中)，无论视频内容是经由上载器280从客户端设备200获得的，还是从更传统的cdn获得的(以及无论是向虚拟广播服务器300实时流传输的，还是提前提供以在稍后流传输的)。

频道管理器385负责设置和维护每个频道，而poi内容服务器380准备视频内容本身以作为频道向客户端节点流传输。在一个实施例中，频道管理器385生成并维护频道网页，以由poi内容服务器380通过互联网传送，且由信令服务器330在响应来自客户端设备200的寻求加入具体频道的加入请求时使用。

为了支持目的，频道管理员385建立和维护“查看器支持控制台”，以支持其客户端设备200遇到问题的个人观众以及用于实时监视所有视频频道的“播出中心”可以解决信道特定的且区域特定的问题(例如，由特定地理区域产生的支持呼叫)。频道管理器385还维护对“频道分析”的实时监视，以提供对这些支持功能以及视频内容的发起者(例如在cdn处)有用的数据。例如，分析包括关于下述方面的实时度量：每个视频频道和沿覆盖网络100的网络节点的当前状态，以及与视频比特速率、拥塞点、节点等待时间等相关的最后一英里问题，等等。

最后，提供“频道管理”功能来管理视频频道并与信令服务器330进行接口连接，使得其具有促进其与客户端设备200通信所必需的当前信息(例如，关于加入频道，提供所监视的客户端的性能度量，获得中继目标的路由以及分辨率或比特速率变化等)。

除了泼溅提取器390以外，为了简单起见，将在单个视频内容频道的上下文中描述图3所示的剩余的服务器侧功能。然而，请注意，在一个实施例中，该功能是在任何给定时间针对多个频道以及各种数字内容并发执行的。

在客户端节点访问视频频道之前，视频内容被转码以创建多个较低分辨率的视频段流。在一个实施例中，poi内容服务器380被实现为能够与客户端设备200内的标准html5网络浏览器230通信的http228服务器。与信令服务器330(其与客户端设备200建立用于频繁双向通信的网络套接字225连接(例如交换路由更改、性能数据等))不同，poi内容服务器380对来自标准html5网络浏览器230的相对不频繁的客户端http228请求做出响应，所述客户端http228针对清单文件、偶尔的未及时经由覆盖网络100到达的视频段等等。

如上所述，poi内容服务器380还依赖于http228协议来实现其较高带宽频道发起功能，即，通过响应来自附近a节点(在虚拟数据干线覆盖网络的根部处，通常在与poi内容服务器380相同的asn中，或者在一或两跳内)的针对视频段的http请求。在其他实施例中，这些视频段按照webrtc222和自适应流传输224标准被推送给这些a节点，或者经由其他视频流传输技术(包括如上所述的由上载器280使用的淋浴协议)被推送给这些a节点。

在一个实施例中，poi内容服务器380将视频内容转码为3种不同分辨率(1080p、720p和480p)，而在其他实施例(例如，4k、360vr、180vr、240p等)中支持各种其它较高和较低分辨率，包括所有视频内容的单一固定分辨率。如果以较低分辨率(例如，720p)提供原始源视频，则针对该视频频道仅可支持720p和480p分辨率。该功能有助于自适应比特速率流传输，无论是由客户端节点(如上所述)发起还是由虚拟广播服务器300基于客户端性能度量的分析来发起。

在一个实施例中，poi内容服务器380通过响应http请求来发起频道，以将每个视频段的所有可用版本(例如，3个不同的分辨率)提供给一个或多个附近节点(通常为a节点)，该附近节点发起每个视频段的沿着覆盖网络100的推送。在另一个实施例中，这些节点将所有版本中继给b节点(以及b∶a节点)，并且最终中继给c节点，使得每个客户端节点可以利用自适应流传输224能力。将多个分辨率中继给其他节点的节点通过覆盖网络100将这些多个版本的视频段“聚播”给其他客户端节点，如下面更详细地解释的。

注意，虽然poi内容服务器380通过向一个或多个附近节点(响应于http请求)提供视频段来发起频道，但假设每个视频段在之前的视频段的回放已经结束之前穿过覆盖网络100，所有客户端观看节点同时有效地接收和查看每个视频段，即，它们都是同步的。因为本实施例中客户端设备200缓冲至少3个视频段，所以如果视频段偶尔被延迟，该缓冲器提供一些“出错余地”。此外，在另一实施例中，当poi内容服务器380首先开始“广播”频道时，可以延迟频道的发起以提供附加的缓冲。当客户端设备200直接从回退poi内容服务器380发出对视频段的请求时(例如，因为视频段没有经由覆盖网络100及时到达)，例如，如果该视频段跨一个或多个asn，则可能需要该缓冲器。

如上所述，poi内容服务器380还响应于来自客户端设备200的请求提供周期性清单文件。虽然这些清单文件是通过标准http328协议提供的，但它们与视频段相比相对较小且时间关键性低很多。在一个实施例中，每个清单文件识别接下来的8个视频段的各种可用比特速率的位置。在该实施例中，该位置是关于poi内容服务器380的回退位置，因为视频段经由覆盖网络100被推送给每个客户端设备200。

一旦视频内容的频道已准备好用于流传输(从poi内容服务器380开始)，信令服务器330等待来自客户端设备200的加入请求。在从客户端设备200接收到针对该频道的加入请求时，信令服务器330依赖于stun322协议来确保它可以通过可能存在于该客户端设备200上的任何nat防火墙来建立网络套接字326连接。此外，通过识别该客户端设备200的公共ip地址，可以将该公共ip地址提供给其他客户端节点(例如，用于将视频段中继给该客户端设备200)。

一旦建立了网络套接字326连接，客户端设备200向信令服务器330提供关于其能力(例如，os、网络浏览器和连接类型(3g、4g、wifi、lan等))的信息，在一个实施例中，包括客户端设备200是否是c节点(例如，在本实施例中假定用于蜂窝连接)。客户端设备200还向信令服务器330提供其asn位置，该asn位置稍后将用于将客户端设备200添加到覆盖网络100。

在一个实施例中，信令服务器330将去往客户端设备200的一个或多个初始视频段的传送(经由覆盖网络100)进行优先化，使得其可以尽快开始播放频道的视频内容。为了发起此过程，它将控制权转移到覆盖网络创建器350，覆盖网络创建器350将客户端设备200添加到其asn内的群组覆盖网络(例如，通过指示该asn内的b节点将视频段中继给客户端设备200)。注意，客户端设备200尚未被分类，并且还不会将任何视频段中继给其他客户端节点，但是通过成为覆盖网络100的一部分，客户端设备200可以开始接收视频段并播放频道的视频内容，以及收集将便于其分类的客户端性能度量。

信令服务器330随后通过其网络套接字326连接获得客户端设备200的上游和下游带宽。注意，该度量不是非常有用的，因为连接可以跨多个asn(即使信令服务器330知道客户端设备200的asn位置)。更相关的度量将涉及客户端设备200与其自己的asn内的其他客户端节点之间的通信。

在从客户端设备200(以及从其他客户端节点)接收客户端性能信息(由客户端设备200上的性能监视器240收集)时，信令服务器330将该信息转发给性能跟踪器340，以便覆盖网络创建器350和深度映射器360在动态重新分类客户端节点并为下一个视频段重新配置覆盖网络100时进行初步分析和后续使用，如下所述。性能跟踪器340监视每个客户端节点的性能，并确定客户端节点是否仍然“活着”。例如，如果客户端设备200已经关闭了连接并离开了频道，或者在阈值时间量内没有响应“ping”，则将被视为已经离开该频道(无论是有意地还是由于硬件或软件故障)。性能跟踪器340还将客户端性能度量转换为用于存储在历史性能db345中的适当格式，并由覆盖网络创建器350和深度映射器360使用。

在一个实施例中，覆盖网络创建器350还在深度映射器360的帮助下负责评估当前的和历史的客户端性能度量(维护在历史性能db345中)的连续过程，并针对每个视频段动态地(i)重新分类客户端节点，以及(ii)通过生成和重新配置覆盖网络100(包括虚拟数据干线覆盖网络(用于在asn内和跨asn的a节点之间中继视频段)和群组覆盖网络(用于从asn内的每个a节点将视频段中继给该asn内的某些其他b∶a、b和c节点))来优化路由路径。覆盖网络100的拓扑被维护在覆盖网络db375中，供覆盖网络创建器350和深度映射器360使用。

对于从新添加的客户端设备200接收到的性能度量，覆盖网络创建器350利用这些度量来初始地分类客户端设备200。在一个实施例中，该过程还用于针对每个视频段潜在地重新分类客户端节点(不仅仅是当他们加入频道时)。虽然客户端节点通常不经常被重新分类，但客户端可能经历带宽的暂时下降(例如，来自家庭微波或其他干扰)。此外，由于需要更多的a节点(例如，为了冗余，或由于离开频道的客户端节点)，b∶a节点可升级为a节点。在asn内或跨asn检测到的其他问题也可能要求将某些节点重新分类。

覆盖网络创建器350向客户端设备200分配输入时隙和输出时隙(即，网络端口)，使得其可以(经由输入时隙)接收从其他客户端节点推送的视频段的块，并且可以(经由输出时隙)中继(推送)视频段的这些块给其他客户端节点。虽然webrtc224标准支持256个输入和输出端口(时隙)，但是在一个实施例中仅分配单个输入时隙(以最大化可在客户端设备200上播放的视频内容的质量)，并且分配最多8个输出时隙(以最大化沿覆盖网络100的吞吐量，并支持广泛的客户端设备200和有限带宽连接)。如上所述，a节点被分配4个输出时隙用于将视频段跨asn对等点中继给其他a节点，以及4个输出时隙用于将视频段中继给其asn内的其他a节点。如下面将要解释的那样，在任何给定的时间点并不是所有分配的时隙必然被使用。

覆盖网络创建器350分析客户端设备200的下游带宽和上游带宽以便于分类过程如上所述，如果客户端设备200通过蜂窝连接(3g、4g或甚至lte)加入，则其自动被认为太不可靠而不能中继视频段，并因此被分类为c节点。在其他实施例中，这种自动分类可被限于某些蜂窝连接(例如，3g)，或被完全消除。

在一个实施例中，覆盖网络创建器350采用典型的下游/上游带宽(以mbps为单位)的类别以便于进一步分类，包括：(1)lan连接(例如100/100)，(2)光纤连接(100/50)，(3)adsl连接(100/20)、线缆连接(100/10)和wifi连接，其差别很大。在该实施例中，如果客户端设备200尚未被认为是c节点，并且具有至少50mbps的上游带宽，则其最初被分类为a节点(或者如果深度映射器360指示其asn中不需要附加的a节点，分类为b∶a节点)。否则，它将被分类为b节点。

如下面将要讨论的，覆盖网络创建器350还分析客户端设备200的上游带宽(在一个实施例中)，以计算在其确定其应该动态重新配置覆盖网络100的程度(如果有的话)之前其可以利用的可用输出时隙的数量。它还确定客户端设备200能够接收和/或聚播多个分辨率的程度。

在一个实施例中，客户端节点的完整下游带宽用于其单个输入时隙，而其上游带宽的仅1/3用于在其输出时隙之间中继视频段。由于视频段的中继可能会干扰客户端设备200正在为其他应用使用的tcp/ip连接和其他连接，因此不会利用其完整的上游带宽。

覆盖网络创建器350分析客户端设备200的下游带宽(即使被分类为c节点)来确定其可以通过其单个输入时隙支持的分辨率数量。例如，如果1080p需要3mbps的比特速率，720p需要1.5mbps的比特速率，且480p需要500kbps的比特速率，那么客户端设备200将需要至少5mbps的下游带宽来支持所有3分辨率，至少4.5mbps支持1080p和720p，至少3mbps仅支持1080p，至少2mbps支持720p和480p，至少1.5mbps仅支持720p，至少500kbps仅支持480p。在一个实施例中，不支持低于500kbps的比特速率。在其他实施例中，可以支持更低的分辨率，并且可以采用其他技术(例如更大的压缩，不同的视频格式等)来放宽带宽要求。

如上所述，在一个实施例中，a，b∶a和b节点也可被认为是可以经由其一个或多个输出时隙将多个分辨率中继给其他节点的聚播节点。在这方面，覆盖网络创建器350分析客户端设备200的上游带宽以确定其可以中继给其他客户端节点的分辨率的数量。

由于客户端节点在该实施例中仅可以利用其上游带宽的1/3，所以客户端设备200将需要至少15mbps(针对每个输出时隙)的上游带宽以聚播所有3个分辨率，至少13.5mbps(针对每个输出时隙)以聚播1080p和720p，至少9mbps(针对每个输出时隙)仅发送1080p，至少6mbps(针对每个输出时隙)以聚播720p和480p，至少4.5mbps(针对每个输出时隙)仅中继720p，以及至少1.5mbps(针对每个输出时隙)以仅中继480p。

客户端设备200不能中继其没有接收到的分辨率。此外，如下所述，结合其他客户端节点接收多个分辨率的能力来考虑客户端设备200的聚播能力。但是，如上所述，客户端设备200使用自适应流传输224实现来在视频段经历其带宽的显著变化时请求更低或更高分辨率的视频段版本如果它接收到视频段的多个不同分辨率，它将简单地播放它接收到的最高分辨率。

假设客户端设备200不是c节点，则覆盖网络创建器350通过分析其上游带宽并考虑其可以聚播多个分辨率的程度来计算其可以利用的可用输出时隙的数量。例如，如果客户端设备200被分类为具有上游带宽为100mbps的lan连接的a节点，则它可以仅利用约6个输出时隙以在asn内和跨asn聚播视频段。在该实施例中，覆盖网络创建器350将分配4个时隙用于跨asn向其他a节点进行聚播(给出这些asn间时隙优先级)，留下2个剩余的时隙用于向其asn内的其他a节点进行聚播。在其他实施例中，当然可以在不背离本发明的精神的情况下改变这些分配。

类似地，如果客户端设备200被分类为具有10mbps的上游带宽的电缆连接的b∶a或b节点，则它可以仅使用1个输出时隙来聚播720p和480p分辨率，或者仅发送1080p。在一个实施例中，给予更高质量的分辨率(在节点可以接收该分辨率的情况下)以优先，因此一个时隙将仅被分配用于1080p。这些分配也可以在不背离本发明的精神的情况下变化。

在已经分类了客户端设备200并且确定了可以利用的时隙数(包括聚播多个分辨率)，覆盖网络创建器350然后确定其将动态重新配置覆盖网络100以优化路由路径的程度。如果客户端设备200是a节点，则覆盖网络创建器350将首先从深度映射器360获得针对a节点之间的每个asn间路径的拥塞级别(如下面更详细地讨论的)，然后将会动态重新配置至少部分的虚拟数据干线覆盖网络以包含客户端设备200。

例如，给定加权路径集合(每个路径具有“拥塞级别”加权)，覆盖网络创建器350使用标准路径查找技术来确定用于在a节点之间分发视频段的最佳路径(类似于例如gps导航路由)。然而，要注意，通过使用多个中继时隙(例如，a节点用于中继到asn内的a节点的4个输出时隙，以及a节点用于跨asn对等点中继到a节点的4个输出时隙)，该过程稍微复杂化。然而，这仅仅是a节点仅具有1个输出时隙的最简单情况的轻微变化。换句话说，覆盖网络创建器350跟踪在虚拟数据干线覆盖网络的生成或重新配置期间所开放的(未使用)时隙的数量，并且一旦特定的a节点不再具有任何未使用的开放时隙就停止将其指派为中继源。

如果客户端设备200是b∶a或b节点，则覆盖网络创建器350动态地重新配置客户端设备200所驻留的asn中的asn内群组覆盖网络中的一些或全部。要注意，如果该asn内有多个a节点，则它们彼此之间的路由将被确定为虚拟数据干线覆盖网络的一部分。在一个实施例中，将仅使用一个a节点来创建群组覆盖网络(如果有足够的时隙可用)，而在其他实施例中，可以在多个a节点之间平等地分配该其他节点，或者基于相对上游带宽或其他度量来分配该其他节点。

对于任何特定的a节点，以及asn内的剩余b，b∶a和c节点，这些节点首先基于其分类(即b∶a，然后b，然后c)并然后基于其相对带宽进行排名(即，可以利用的可用时隙的数量，如上所述)。注意，考虑到每个节点仅具有单个馈点节点，在该实施例中，群组覆盖网络是分层结构。在其他实施例中，类似的技术可以用于非分层“网格”群组。

在该分层群组实施例中，该过程以根部a节点开始，该然后基于它们相对带宽将会具有可被利用的一定数量的输出时隙(例如，2个输出时隙)。这些时隙将被路由到层次结构的下一级，例如具有可被利用的最多可用时隙数的2个b∶a节点。一旦确定了这些路径，这些节点的可用输出时隙将被路由到具有最多可用时隙的剩余b∶a节点。该过程继续在层级中下降(通过b节点，且最后是c节点)，直到所有路径都被确定为止。

注意，在asn内的节点之间的中继具有相对较高的速度(远低于1毫秒)的情况下，在任何客户端节点(例如，各自具有单个输出时隙的100个客户端节点)下的链的长度具有相对较小的关注度。给定1秒的视频段，仍然可以容纳数百个节点的链(尽管它们将是罕见的，因为asn内的许多节点可能会支持多个输出时隙)。在所有节点不能被包括在群组中的情况下(例如，如果具有0个可用时隙的c节点和b节点保持不计算在内)，则将需要在该asn中具有开放时隙的附加节点，该附加节点将会当他们可用时被分配。在此期间，这样的节点将被引导以向poi内容服务器380请求视频段。

在转向深度映射器360之前(该映射器预测并量化跨asn对等点的拥塞级别(例如，针对下一分钟))，了解bgp路由协议的局限性以了解asn对等点拥塞的重要性是有帮助的。bgp路由器确定“路由时间”处的拥塞，并且没有预测能力。他们只知道自己的路由器，并且跨asn对等点等待时间“1跳”。他们不知道到任何最终目的地的跳数或等待时间，这可能是跨多个asn对等点相距多跳。给定多个asn对等点的选择，他们基本上选择当前具有最多可用带宽的那个(即，具有开放时隙且最短等待时间1跳的那个)。

相比之下，深度映射器360利用其对互联网底层架构的了解。在一个实施例中，如图1所示，深度映射器360维护互联网(包括asn及其各种对等点互连)的asn互连地图，如图1中粗略所示。该地图不会频繁变化，尽管在一个实施例中，每5分钟对其监视一次以捕捉这种不频繁的变化。

然而，在这些asn之上构建的覆盖网络100被频繁地分析(例如，通过如上所述的客户端侧监视)，并且潜在地由虚拟广播服务器300针对每个视频段来重新配置(例如，在一个实施例中，每一秒)。然而，实际上，覆盖网络100实际上仅在有保证的情况下进行修改，例如，不仅当新节点加入或离开频道时，而且当检测到足够的问题(基于历史性能db345中维护的当前信息和历史信息)时。

例如，在一个实施例中采用多个内部“拥塞阈值”。在初始检测到特定于具体客户端设备200或asn内的拥塞相对较低的阈值时，覆盖网络创建器350仅“标记”客户端设备200或asn，并且等待以看该问题是否重现(例如，在下一个视频段上)。如果重现，它可能会降低中继给该客户端节点(或该“问题”asn内的所有客户端节点)的下一个视频段的分辨率(以及因此的比特速率)。最终，如果问题变得更糟(例如，超过较高的拥塞阈值)，则覆盖网络100的一部分(例如，asn内的子集ip范围)可被动态地重新配置。最后，整个asn或者可能虚拟数据干线覆盖网络本身可能需要动态重新配置。

无论如何，这些拥塞阈值的目的是在问题恶化到导致视频段丢失或者甚至导致客户端节点不得不从poi内容服务器380的回退位置获得视频段的更严重问题之前，主动地识别和纠正问题。

通过保持知道互联网的asn互连地图以及覆盖网络100上节点的asn位置，并实时监视这些节点的当前和历史性能，深度映射器360最小化了任何客户端节点会不必要地将视频段中继给远程客户端节点(例如，跨多个asn对等点相距许多跳)的可能性。例如，在一个实施例中，作为初始事项，虚拟数据干线覆盖网络将倾向于将视频段(每当有可能)从一个a节点路由给相同asn中的另一个a节点或跨单个asn对等点的附近asn的另一a节点。

但是，并不是所有的单跳都是平均创建的。例如，深度映射器360可以随着asn1和asn2之间的对等点变得拥塞的时间进行“学习”(基于在历史性能db345中维护的客户端性能度量)，并且可以“预测”从“asn1”到“asn3”到“asn2”的2跳路由实际上比当前的1跳路由更快(或者基于最近趋势和历史趋势在不久的将来会更快)。通过基于跨对等点的a节点的实际当前性能和历史性能来量化对等点拥塞，深度映射器360可以促进虚拟数据干线覆盖网络的拓扑的动态重新配置(潜在地针对每个视频段，或者至少当对等点拥塞(基于内部阈值)需要这样的改变时)。

在一个实施例中，采用1到10的范围，深度映射器360针对每对a节点(无论它们是驻留在相同的asn还是在不同的asn中)对拥塞进行量化，其中，1是所预测的近期拥塞的最低级别且10是最高级别。如上所述，覆盖网络创建器350利用该拥塞级别“分数”来比较a个节点之间的不同潜在路由并且确定最有效的路由(即，最低的“加权跳”路由)。因此，与poi内容服务器380相距最“远”(在加权跳跃中)的a节点将最小化视频段从poi内容服务器380穿过虚拟数据干线覆盖网络到这样的a节点所需的时间量。

在一个实施例中，对于每对a个节点，深度映射器360生成针对从一个a节点到另一个a节点的每条路由的预测拥塞级别分数，然后选择要应用于该a节点对的最低拥塞级别分数，该分数被其返回给覆盖网络350。在其他实施例中，深度映射器360生成那些预测的拥塞级别分数(针对从一个a节点到另一个a节点的每条路由)的不同函数，例如平均值，中位数等。

在一个实施例中，深度映射器360是连续分析在历史性能db345中维护的性能度量的深度学习引擎，并且预测(例如，未来一分钟)跨asn对等点的拥塞级别。应该注意的是，像任何深度学习引擎一样，关于跨asn对等点的a节点之间的流量，深度映射器360采用多个非线性变换来对asn对等点的行为建模。

如上所述，不能有效地监视跨这些对等点的互联网流量的大部分，而只是有效地监视这种流量对跨这些对等点的a节点之间的asn间的跳的随时间的影响。获得越多的性能度量，越能够更好地预测这样的asn间的跳所需的时间，该时间然后被量化为相对拥塞级别(例如，与通常不太拥挤的asn内的跳相比，尽管如此，在本实施例中也进行监视)。

由于对等点的拥塞级别是如此动态，所以这种预测只能在短时间内准确。但是，考虑到这种分析是连续执行的，并且可能针对下一个1秒的视频段改变，所以预测在长时间内准确并不重要。

在一个实施例中，深度映射器360基于非常粗略的信息(即，在获得大量客户端性能度量之前)初始量化asn对等点。例如，如果asn具有1000个对等点，则可以假设它是一个骨干网，该骨干网可能比具有6个对等点的另一asn快得多。随着获得更多的客户端性能度量，这些asn对等点拥塞级别将变得更加准确。在另一个实施例中，部署多个“学习节点”以“跳转开始”新的频道。这些学习节点是不查看视频的仅发送节点，而是仅部署来快速提供客户端性能信息，使得深度映射器360可以比该情况本来的更早开始做出更准确的预测。

此外，在一个实施例中，深度映射器360还考虑asn内拥塞，因为这可以暗示例如asn内对附加a节点的需求，并因此对创建附加的群组覆盖网络的需求。例如，如果asn内的许多客户端节点随时间逐渐花费更长的时间来获得视频段，则深度映射器360标记该asn以指示需要附加的a节点，而覆盖网络创建器350可以将一个或多个b∶a节点“提升”为a节点，导致虚拟数据干线覆盖网络的部分重新配置，并最终要求asn内的新的群组覆盖网络。在另一实施例中，深度映射器360在每个asn内应用深度学习技术，并且协助覆盖网络创建器350生成asn内群组覆盖网络。

因此，覆盖网络创建器350和深度映射器360一起工作，以建立客户端节点之间的路由(经由覆盖网络100)，以最小化跨不必要的远距离路由(即跨多个asn对等点)对视频段的中继，其中，该路由基于互联网的底层架构(asn互连地图)和覆盖在该架构之上的客户端节点的asn位置。此外，覆盖网络创建器350和深度映射器360还一起工作，以持续地实时分析由客户端设备200获得的客户端性能度量，并在这些指标揭示出重大问题(通常是由于asn对等点处的拥塞造成)的情况下动态地重新配置覆盖网络100。因此，可以监视互联网的qos波动性，并且可以通过在问题“发生之前”围绕这些问题动态地重新路由(基于由深度映射器360生成的所预测的拥塞级别)，最大限度地减少对拥塞的客户端节点(特别是在asn对等点)的影响。

在一个实施例中，虚拟广播服务器300包括用于识别趋势视频事件(“泼溅”)的泼溅提取器390搜索引擎，并且使得用户能够在这些事件的域之间进行搜索且将所期望的泼溅结果的流作为视频频道从poi内容服务器380立即进行流传输(其中，这样的频道在虚拟广播服务器300处本来不可用)。

在一个实施例中，泼溅提取器390从多个新闻源连续地收集数据，例如，通过api到twitter、rssfeeds、reddit以及数以万计的在线杂志。平均而言，在这些来源中每小时都会显露出数千个不同的“当前事件”。泼溅提取器390采用新颖的自动化方法来识别这种趋势事件(泼溅)，并定位并提取可经由poi内容服务器380获得和流传输的相关视频。

泼溅提取器390识别“与规范的偏离”，以检测泼溅。例如，通过在新闻源的领域中采用例如标准的列文斯特比较算法开发了基线(无需规范化数据)。平均来说，除非具体话题的确是趋势，或直到具体话题的确是趋势为止，一些来源才会在短时间内讨论相同的“话题”(即关键字的集合)。在这一点上(例如，当15个或更多来源在短时间内讨论同一话题时)，该话题被识别为偏离(deviation)，并因此被识别为“泼溅”。

泼溅提取器390然后从这些来源中提取“最重要的”关键字(例如，在一个实施例中为40个关键字)，在一个实施例中，通过采用标准神经网络技术从“泼溅相关”文章中学习和预测不同的关键字。然后将这些关键词分类(例如，作为新闻，体育等)并按频率排序。

泼溅提取器390然后使用这些关键字搜索社交媒体以获得与每个泼溅有关的视频，并对与这些潜在的泼溅视频频道相关联的相关文本进行编索引。用户可以搜索该索引，或者只是浏览泼溅视频事件的类别。在选择结果(无论搜索的或浏览的)之后，用户可以立即流传输所期望的视频。在一个实施例中，用户简单地链接到视频的当前来源，而在另一实施例中，经由虚拟广播服务器300获得视频，并从poi内容服务器380流传输该视频(例如，如果大量的并发用户请求相同的泼溅视频频道，这是有用的)。

动态视频流传输处理

已经讨论了本发明的虚拟广播系统的关键客户端侧和服务器侧组件，图4的流程图400示出了这些组件如何动态交互。换言之，流程图400示出了由这些组件实现的本发明的动态流传输处理的一个实施例。应当注意，由于该过程的大部分是事件驱动的并且不是线性的，因此流程图400从客户端侧和服务器侧功能之间的交互的角度示出了步骤。

步骤401示出了上载器280(且在上面描述)中执行的处理，其中视频事件由客户端节点(例如，客户端设备200上的智能相机219)捕捉到或者数字地生成或者从外部来源获得。在任何情况下，客户端(例如，客户端设备200)然后将该视频事件的视频段(无论是实时捕捉的还是预先录制的)流传输给虚拟广播服务器300。

无论视频事件是从客户端还是从更传统的cdn(以及它们是被预先录制还是实况流传输的)获得的，虚拟广播服务器300在步骤410中准备每个视频频道以进行从poi内容服务器380的实况流传输，如上所讨论的。此时，在一个实施例中，频道网页被生成并最终由潜在的客户端节点遇到。当客户端设备200的用户点击所期望的频道时，连接请求将与客户端功能(诸如操作系统的类型、浏览器、连接等)一起发送给信令服务器330。备选地，客户端设备200的用户可以遇到趋势性的泼溅视频事件(如上所述)，并且选择该视频事件(在步骤410中)，以用于从poi内容服务器380作为视频频道来流传输。

在步骤412中，信令服务器330验证客户端与该频道的连接性(例如，通过采用stun322协议来识别客户端的公共ip地址)，然后通过客户端上可能存在的任何nat防火墙建立网络套接字326连接，并且稍后向其他客户端节点提供该公共ip地址以将视频段中继给该客户端。信令服务器330然后将控制转交给覆盖网络创建器350，覆盖网络创建器350将(尚未分类)的客户端作为节点添加到覆盖网络100上，从该覆盖网络100，初始视频段将被推送给客户端(在步骤414中)，使得在步骤415中，用户可以立即开始观看视频频道。

信令服务器330然后在步骤416中将客户端设备200分类为a、b∶a、b或c节点，并且在步骤430中，使用覆盖网络创建器350和深度映射器360二者来动态地重新配置asn间(虚拟数据干线)和asn内(群组)覆盖网络100，以将客户端设备200并入网络拓扑中。然后，信令服务器330向其他客户端节点提供相关的路由信息，以开始将视频段中继给客户端设备200。

poi内容服务器380然后在步骤435中，响应来自附近节点(通常为a节点)的http请求，作为沿着当前(重新配置的)覆盖网络100的视频频道的起点，将视频段流传输给那些节点，其中每个视频段被逐节点地中继，直到它被中继给客户端设备200并被其观看。

虽然客户端设备200正在接收块并进行汇编(compile)，但是在步骤450中，为了观看频道的每个视频段(并且潜在地还在步骤440中将块中继给其他指定的客户端节点)，在步骤425中，它还监视其性能(如上面关于性能监视器240所讨论的)，并且向信令服务器330提供客户端性能度量。此外，当请求每个视频段时，由于视频段被沿着覆盖网络100推送给客户端设备200(如上所述)，在步骤455中(在一个实施例中，由接收机250中的客户端javascript代码)拦截这些请求。从步骤455到步骤425的箭头仅仅表示步骤425中的监视处理是与视频段的接收、查看和中继同时进行的连续操作。

如上所述，即使视频段被从其他客户端节点推送给客户端设备200，客户端设备200也周期性地向poi内容服务器380发起请求清单文件(例如，包含接下来的8个视频段的位置)的http请求。偶尔，如果视频段没有及时到达，则客户端设备200将直接向poi内容服务器380请求该视频段来作为回退位置。此外，有时，根据自适应流传输224标准，客户端设备200还可以联系poi内容服务器380以请求修改的比特速率(例如，一旦检测到其性能级别的改变)，以用于后续视频段。然而，如上所述，接收机250可以更早地检测到这种需要，并且联系虚拟广播服务器300来通过覆盖网络100使这种改变生效，指示馈送客户端节点自动将更低或更高分辨率的视频段推送给客户端设备200(即不响应其请求)。

在步骤452中，poi内容服务器380响应这样的http请求，并将所请求的清单文件和回退视频段传送给客户端设备200。如上所述，比特速率的改变通过覆盖网络100(并且在步骤430中)来解决，导致更低或更高分辨率的视频段被推送给客户端设备200。

步骤454包括由性能跟踪器340、覆盖网络创建器350和深度映射器360执行的连续过程(在一个实施例中，针对每个视频段执行，并且在上面详细描述)。在该步骤454中，持续地更新客户端性能信息，并且如果需要，在步骤430(如从步骤454到步骤430的箭头所指示的)，覆盖网络100被动态地重新配置，并且新的路由信息被提供给相关的中继节点通过信令服务器330。

最后，在步骤460中，泼溅提取器390连续地识别趋势性的泼溅视频事件，然后如上所述地流传输以便立即观看，这些泼溅视频事件可被客户端设备200的用户浏览或搜索。

这里参照附图所示的具体实施例描述了本发明。应当理解，根据本公开，本领域技术人员可以在本发明的范围内设想和实现本文公开的概念的附加实施例。