网络发起的内容流式传输控制的制作方法
网络发起的内容流式传输控制的制作方法
【专利摘要】描述了用于实现对分段内容从递送节点到至少一个客户端的流式传输的网络发起的控制的方法和系统，所述客户端被配置成基于清单文件而访问所述分段内容的至少部分，其中方法可以包括：接收第一清单文件，其标识一个或多个段和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述至少一个客户端发送所述一个或多个段；响应于所述第一清单文件的所述接收，提供信道建立信息；以及基于所述控制信道建立信息而在所述至少一个客户端和与所述内容递送节点相关联的控制信道服务器功能之间建立至少一个流式传输控制信道，所述至少一个客户端被配置用于经由所述流式传输控制信道接收至少一个清单文件更新消息。
【专利说明】网络发起的内容流式传输控制
【技术领域】
[0001]本发明涉及控制内容的流式传输(streaming)，并且特别地，尽管并不排他地，涉及用于实现对分段内容的流式传输的网络发起的控制的方法，用于在用于控制分段内容的接收的内容处理设备中使用的客户端，用于实现对分段内容的流式传输的网络发起的控制的控制信道服务器功能和数据结构和使用这样的方法的计算机程序产品。
【背景技术】
[0002]目前数目日益增加的视频流式传输技术利用所谓的内容分段，其中内容数据(例如视频数据)被逻辑地或虚拟地拆分成多个段文件(segment file)或流，因此生成分段的内容。段文件可以涉及包括内容数据的文件，其可以通过文件获取协议(例如HTTP或FTP)来获取。类似地，段流可以涉及包括内容数据的流，其可以通过流式传输协议(例如RTSP/RTP或HAS)来获取。段文件或流(以下简短地也称作为段)可以单独地递送到客户端，但是当在客户端处重组时，它们提供无缝的视频流。
[0003]在内容分段过程期间，生成所谓的清单(manifest)文件，其标识段并且描述不同段与其中可以获取段的一个或多个位置之间的关系。可以以若干表示提供分段内容，例如在例如分辨率、音频通道的数目和/或不同的比特率方面不同的相同内容的替换版本。所有表示在时间上对准，使得不同表示的段可以无缝地互换。以不同表示的分段内容的流式传输称作为自适应流，其中可以使用诸如HTTP自适应流(HAS)和有关协议之类的自适应流协议。
[0004]HAS通过传输由来自web (网络)服务器的客户端独立请求的分段的视频来实现借助于HTTP协议的(实时)视频的递送。存在各种商用和标准化的HAS协议，诸如Apple HTTPLive Streaming (实时流式传输)http://tools.1etf.0rg/html/draft-pantos_http-live-streaming-07、Microsoft Smooth Streaming (平滑流式传输)http://www.1is.net/download/ SmoothStreaming、Adobe HTTP Dynamic Streaming (动态流式传输)http://www.adobe, com/products/ httpdynamicstreaming、3GPP-DASH TS 26.247 Transparentend-to-end Packet-switched Streaming Service (PSS)(透明端到端分组交换流式传输服务(PSS)) ；Progressive Download and Dynamic Adaptive Streaming over HTTP](渐进式下载和通过HTTP的动态自适应流)和MPEG Dynamic Adaptive Streaming over HTTP(MPEG 通过 HTTP 的动态自适应流)MPEG DASH IS0/IEC 23001-6。
[0005]分段内容可以被用于动态地适配于改变的带宽要求，例如通过从高质量视频流切换到低质量视频流。而且，分段内容还可以允许流行和不太流行的(视频)段之间的区分。例如，典型地，与视频的开头相关联的内容(诸如预告片)将比结束处的内容更常被观看(并且因此更流行)。类似地，对于一些使用情况，低比特率低质量的视频内容(例如最低分辨率HAS段)将很可能比高质量内容(例如高分辨率HAS段)更频繁地被下载，高质量内容可以从接收设备花费或要求得更多或需要更多带宽。以上提到的分段内容的属性可以被内容递送网络(content delivery network,⑶N)有利地使用，其可以被配置成将内容递送给消费者。CDN可以例如将流行的、更频繁请求的内容段存储在CDN中的多个递送节点处，使得可以减少带宽问题并且保证高效的递送。⑶N控制功能(⑶NCF)可以集中地管理⑶N内的位置，以下称作为递送节点，其中可以获取(得到)与内容项(诸如视频或电影)相关联的内容段。
[0006]尽管许多不同的流式传输协议(诸如RTP/RTSP或RTMP)可以被用于实现将(分段)内容流式传输到客户端，但是HTTP或基于HTTP的流式传输协议在CDN内最广泛地使用。这些流式传输协议使用标准HTTP (无缝的客户端-服务器协议)以请求和接收来自不需要新的功能并且允许段被透明地高速缓存的服务器的内容段。而且，不像是大多数其它的流式传输解决方案，HTTP业务本身通常不会被防火墙或网络地址翻译器(NAT)自动阻挡。
[0007]而且，基于HTTP的流式传输不是基于会话的。这意味着HTTP服务器不需要为它服务的各种客户端维持会话。这样HTTP服务器架构可以保持简单。然而，与HTTP是客户端发起的协议这一事实结合的这种无会话的性质还意味着HTTP服务器(例如CDN中的递送节点)不能够发起与客户端的通信。
[0008]为了使得客户端能够访问(下载/获取)存储在CDN中的段，客户端被提供有包括均被段标识符(例如段文件名)和段位置(段定位符)标识的段的列表的所谓的清单文件，所述段位置例如是URL，其指向其中可以访问(获取)段的网络节点。取决于特定⑶N和/或实现方式，预定义的清单文件可以连同相关联的段一起存储在CDN的一个或多个(递送)节点上，或者清单文件可以在用户请求时由CDN动态生成。
[0009]这样，当消费者(客户端设备)请求特定分段内容项(诸如视频)时，CDN可以应请求而识别存储(递送)节点上的清单文件，所述(递送)节点适于实现请求的内容项到消费者(设备)的递送。可替换地，CDN可以生成标识一个或多个递送节点的新的清单文件，所述一个或多个递送节点合起来适于将请求的内容段递送给消费者。随后，CDN可以响应于消费者的请求客户端(设备)而发送所生成的清单文件。
[0010]在内容段的流式传输期间，⑶N中的网络配置或负载分布可以改变。例如，⑶N的节点中的故障或过载可以导致其中CDN中的一个或多个递送节点不再能够递送在清单文件中标识出的内容段的情形。同样在其它情形中，例如在即将发生过载情形中，可能需要通过将在流式传输过程期间将特定内容段递送给特定消费者(内容接收设备)的任务从一个递送节点转移到CDN的另一个递送节点或甚至转移到另一个CDN中的递送节点来防止过载情形。一方甚至可以想象到，当特定消费者的客户端设备改变其位置时，使现在作为更加接近的节点的另一个递送节点从原始节点接管流式传输还可以是更加有利的。可能需要或许可将段递送到客户端中的改变的递送网络中的其它事件(即触发网络中的负载平衡机制)是计划停机、服务器迁移、CDN迁移等等。
[0011]在已知方法中，段到客户端的递送中的这样的改变可以以若干方式实现。在一些情况中⑶N可以使用例如HTTP重定向方案，以便将针对段的请求重定向到期望的递送节点。然而，这样的方案可能需要并触发针对客户端未来将请求的每个段的单独的重定向响应消息(简单地称作为重定向)，或甚至每个请求的段多个重定向响应消息，从而引起网络中信令负载的显著增加。这在当大量消费者依赖于相同递送节点并且同时请求和获取相同内容时的情况中尤为相关。不仅附加信令负载可能淹没CDN的部分或全部，而且重定向可能导致在客户端侧的不可接受的服务中断，这是因为单独的内容段的递送由于重定向而突然被延迟。因此重定向方案可能不能够有效地防止由于网络配置中的改变(由于例如递送节点故障)所致的服务中断。在其中例如在客户端设备处几乎不缓存内容的情形中，在发生多个重定向的情形中，或者在新的目标递送节点相比于先前的一个而位于距离客户端设备相当大的距离处的情形中，服务中断可能更明显。
[0012]可替换地，⑶N可以基于新的网络配置而生成用于客户端的新近更新的清单文件。然而，由于其本身性质，HTTP协议不允许服务器侧(例如CDN)直接和或主动发起这样的新近更新的清单文件到客户端的传输，或者可替换地，发起针对这样的新近更新的清单文件的客户端请求。客户端是否接收更新的清单文件完全取决于请求这样的更新的客户端(然而其不知道网络配置中的(未决的)改变)的发起。同样地，如果例如⑶N将会以比存在于先前提供到客户端的清单文件中的更高的表示使得分段内容流可用，客户端没有办法得知这一点并且不能够从这样的更高质量流获益。即便客户端将会被配置成例如周期性地请求清单文件更新，这样的更新方案也不能有效地(快速地)特别地对网络配置中的改变进行反应并且避免由于这样的改变所致的服务中断。如果这样的更新频率将会与突然需要的配置改变精确一致，这将仅仅是巧合的。另外，实现非常高的更新频率(其利用基于HTTP的请求-响应信令机制)，具有以下缺陷:其导致相当大的网络中的开销信令负载以及客户端和网络节点上的处理器负载，甚至在没有配置改变(例如分段内容到客户端的递送中的改变)被需要或可推荐的时段期间亦是如此。
[0013]因此，在本领域中存在对实现对将内容流式传输到客户端的改进的控制的方法和系统的需要。
【发明内容】
[0014]本发明的目的是减少或消除现有技术中已知的缺陷中的至少一个。在第一方面中本发明可以涉及用于实现对分段内容从递送节点到至少一个客户端(优选为诸如MPEGDASH兼容自适应流客户端之类的HTTP自适应流(HAS)客户端)的流式传输的网络发起的控制的方法。该方法可以包括以下步骤中的至少一个:接收第一清单文件，优选地，所述清单文件包括用于标识一个或多个段的一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述至少一个客户端发送与所述段标识符相关联的一个或多个段；向客户端提供信道建立信息；和/或，基于所述提供的信道建立信息，在所述至少一个客户端与网络(优选为与所述一个或多个递送节点中的至少一个相关联的控制信道服务器功能)之间建立至少一个流式传输控制信道。在实施例中，步骤可以由客户端执行。在另一个实施例中，所述至少一个客户端可以被配置用于经由所述流式传输控制信道接收至少一个清单文件更新消息。可替换地，除了指示清单文件更新的可用性的更新消息之外，控制信道可以被网络(例如控制信道服务器功能)用于传送与段内容的流式传输相关联的服务器或网络侧事件的消息。这样的事件可以涉及不能通过清单文件更新传送或者对于其而言将这些传送到与清单文件更新分离的客户端可能更恰当(例如更快)的信息(例如参数)。在这样的实施例中，客户端可以可替换地被配置用于接收和/或处理这些其它事件消息。在另一个实施例中，所述至少一个客户端可以被配置成基于清单文件而访问所述分段内容的至少部分。在另外的实施例中，通过客户端对清单文件的接收可以触发客户端建立与网络的流式传输控制信道，优选地基于所提供的信道建立信息，其中流式传输控制信道使得网络(例如CDN)能够主动为客户端提供清单文件更新消息，其指示清单文件更新的可用性。清单文件更新消息可以通过控制信道被主动发送到客户端而无需客户端首先向网络发送(HTTP)请求。这样，在客户端上执行的流式传输过程可以对网络配置中的改变和/或网络问题(例如突出的过载情形或网络故障)迅速做出反应，由此现在使得网络能够抢先发信号告知客户端。通过实现控制信道，可以缓解和/或克服现有技术类型分段流式传输解决方案所基于的已知(HTTP)请求-响应机制的限制和缺点，其中的一些在背景章节中进行了完全透彻的论述。
[0015]在实施例中，该方法可以包括针对至少一个清单文件更新消息而监视所述流式传输控制信道。在该实施例中，客户端可以连续地针对来自网络的更新消息而监视信道，使得保证通过客户端对这样的更新消息的迅速响应。该监视过程可以例如作为流式传输过程期间的后台过程执行。
[0016]在实施例中，该方法可以包括以下步骤中的至少一个:检测清单文件更新消息；以及，可选地，响应于所述清单文件更新消息获取第二清单文件的至少部分。在另一个实施例中，该方法还可以包括:基于所述第二清单文件而请求段流或文件。因而，由客户端从网络接收的清单文件更新消息可以发信号通知客户端更新的清单文件被需要和/或可用，并且流式传输过程应当或可以基于该更新的清单文件而继续。这里，清单文件中的更新可以由于网络配置中的改变和/或诸如网络故障或网络过载之类的网络问题而被需要。这样，网络可以响应于网络中的某个事件高效和主动地发起对流式传输过程的控制。在现有技术的基于HTTP的分段流式传输解决方案中，其按照定义是需要从客户端首先发起的基于HTTP的请求和响应机制，对流式传输过程的这样的主动网络发起的控制简直是不可能的。
[0017]在实施例中，可以将所述信道建立信息的所述至少部分提供给所述第一清单文件中的所述客户端，可替换地，可以将其在单独的消息中提供给客户端。在另外的实施例中，所述信道建立信息的所述提供包括用所述信道建立信息对客户端进行预配置。在一个实施例中，所述信道建立信息可以包括用于定位网络中的控制信道服务器功能的服务器位置信息，优选为至少一个URL。因而，清单文件可以包括建立控制信道所需的信息的至少部分。
[0018]在实施例中，所述清单文件更新消息的所述至少部分可以包括第二清单文件的至少部分。在该实施例中，流式传输控制信道可以被用于传输清单文件中的更新的部分。在另一个实施例中，所述清单文件更新消息可以包括用于定位和请求所述第二清单文件的至少部分的清单文件位置信息，优选为至少一个URL。这样，网络可以以简单且高效的方式告知客户端哪里可以获取更新的清单文件(或其部分)。
[0019]在一个实施例中，所述流式传输控制信道可以基于WebSocket协议而建立。在实施例中，内容递送网络(CDN)实体、优选为控制信道服务器功能，和客户端可以包括被配置成使用WebSocket协议和信道建立信息来在客户端与所述CDN实体之间建立流式传输控制信道的HTTP WebSocket API。WebSocket连接通常使用标准HTTP端口 80和443，使得数据可以容易地穿过防火墙和NAT，但是还可以使用其它端口。另外，协议提供可缩放的解决方案，因为它具有低消息开销。而且，WebSocket是基于HTTP的，使得可以消除或至少大体上减少与穿过防火墙相关联的问题。而且，它提供了其它协议的隧道传输(tunneling)的可能性。
[0020]在实施例中，基于流式传输协议、优选为基于HTTP的流式传输协议或其派生物将所述分段内容的所述至少部分递送到所述至少一个客户端。在另一个实施例中，可以使用SIP协议、XMPP协议和/或其组合来建立流式传输控制信道。
[0021]在另一个方面中，本发明可以涉及用于实现对分段内容从递送节点到至少一个客户端的流式传输的网络发起的控制的方法，其中所述方法可以包括以下步骤中的至少一个:递送清单文件，所述清单文件包括用于标识一个或多个段的一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向至少一个客户端发送与所述段标识符相关联的一个或多个段；接收对于在与所述一个或多个内容递送节点相关联的控制信道服务器功能和所述至少一个客户端之间建立流式传输控制信道的请求；和/或，建立所述至少一个流式传输控制信道。在一个实施例中，所述控制信道服务器功能可以被配置成向所述客户端发送至少一个清单文件更新消息。在另一个实施例中，所述客户端可以被配置成基于清单文件而访问所述分段内容的至少部分。在另一个实施例中，清单文件可以包括一个或多个段标识符和/或用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述至少一个客户端发送与所述一个或多个段标识符相关联的一个或多个段。
[0022]在实施例中，所述一个或多个递送节点的所述至少第一部分的所述至少部分可以被配置为属于第一内容递送网络(⑶NI)的第一递送节点，所述第一内容递送网络(⑶NI)被配置成向所述客户端递送所述段的至少第一部分；和/或，所述递送节点的至少第二部分可以被配置为属于第二内容递送网络(CDN2)的第二递送节点，所述第二内容递送网络(⑶N2)被配置成向所述客户端递送所述段的至少第二部分。因而，在该实施例中，由第二、另外的⑶N向客户端递送段的至少部分。
[0023]在实施例中，所述方法可以包括:监视一个或多个网络参数，优选为与关联于所述一个或多个递送节点的过载、即将发生的过载、故障或网络配置改变相关联的所述一个或多个网络参数中的至少一个；在满足与所述网络参数相关联的一个或多个预定条件的情况下，生成清单文件更新消息；以及，可选地，向所述至少一个客户端发送所述清单文件更新消息。
[0024]在实施例中，所述方法可以包括:确定与所述第一和/或第二递送节点中的一个或多个相关联的过载、即将发生的过载、故障或网络配置中的改变；识别从与确定的过载、即将发生的过载、故障或网络配置改变相关联的所述一个或多个第一和/或第二递送节点获取或预期获取段的一个或多个客户端；确定与所述识别出的客户端的至少部分相关联的一个或多个流式传输控制信道；以及，可选地，通过所述一个或多个流式传输控制信道向所述识别出的客户端的至少部分发送清单文件更新消息。
[0025]在实施例中，所述过载、故障或网络配置改变的所述至少部分可以与属于第二CDN2的所述第二递送节点的至少一个相关联。在另一个实施例中，所述方法可以包括:所述第二⑶N2向所述第一⑶NI发送过载通知、故障通知或网络配置改变通知，所述过载或故障通知包括与所述过载或故障相关联的一个或多个第二递送节点标识符。
[0026]在实施例中，所述方法可以包括:将客户端递送信息存储在第一⑶N数据库中，所述客户端递送信息包括以下中的至少一个:流式传输控制信道标识符；客户端标识符，优选为与所述客户端相关联的IP地址；与主控在所述清单文件中引用的一个或多个段的递送节点相关联的递送节点标识符；内容递送网络标识符；和/或，清单文件标识符。
[0027]在又一方面中，本发明可以涉及用于实现对与至少第一和第二内容递送网络(CDN1、CDN2)相关联的分段内容到一个或多个客户端的流式传输的网络发起的控制的方法，所述第一⑶NI与第一控制信道服务器功能相关联并且所述第二⑶N2与第二控制信道服务器功能相关联，其中所述方法可以包括以下步骤中的至少一个:生成与分段内容相关联的第一清单文件，所述第一清单文件包括一个或多个段和用于定位与所述第一 CDNl相关联的一个或多个内容递送节点的位置信息；和/或，向所述第二控制信道服务器功能请求与所述分段内容相关联的第二清单文件，其中所述第二清单文件可以包括一个或多个段和/或用于定位与所述第二 CDN2相关联的一个或多个内容递送节点的位置信息；基于所述第一和第二清单文件以及可选地信道建立信息而生成另外的清单文件；基于所述信道建立信息而在所述至少一个客户端与所述第一控制信道服务器功能之间建立至少第一流式传输控制信道，其中所述第一控制信道服务器功能可以被配置成生成清单文件更新消息并且经由所述流式传输控制信道向所述客户端发送所述消息。
[0028]在另外的方面中，本发明可以涉及用于在内容处理设备中使用的客户端，其中所述客户端可以被配置用于:向所述服务器发送对于递送分段内容的请求；接收清单文件，所述清单文件包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述至少一个客户端发送与所述一个或多个段标识符相关联的一个或多个段；被提供有第一信道建立信息；和/或，基于所述提供的第一信道建立信息而在所述至少一个客户端和与所述第一⑶NI相关联的所述控制信道服务器功能之间建立第一流式传输控制信道。在一个实施例中，所述至少一个客户端被配置用于从所述第一控制信道服务器功能接收至少一个清单文件更新消息。
[0029]在一方面中，本发明可以涉及与递送节点相关联的用于实现分段内容从所述递送节点到一个或多个客户端的网络发起的受控传输的控制信道服务器功能，其中所述控制信道服务器功能可以被配置用于以下步骤中的至少一个:接收对于将分段内容递送到所述一个或多个客户端的至少一个请求；生成至少一个清单文件，其包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息以及可选地信道建立信息，所述一个或多个内容递送节点被配置成向所述客户端发送与所述一个或多个段标识符相关联的一个或多个段；向所述客户端发送所述至少一个清单文件；以及，参与基于所述信道建立信息的在所述至少一个客户端与所述控制信道服务器功能之间的至少第一流式传输控制信道的设立或建立。在一个实施例中，所述控制信道服务器功能还可以被配置成生成清单文件更新消息并且经由所述第一流式传输控制信道向所述客户端发送所述消息。
[0030]在一个实施例中，所述生成所述至少一个清单文件可以包括:
提供一个或多个第一段标识符和用于定位第一内容递送网络(⑶NI)中的一个或多个内容递送节点的第一位置信息；向第二内容递送网络请求一个或多个第二段标识符和用于定位所述第二内容递送网络(CDN2)中的一个或多个内容递送节点的第二位置信息；分别基于所述一个或多个第一和第二段标识符以及第一和第二位置信息的至少部分而生成所述清单文件。
[0031 ] 在另一个实施例中，所述控制信道服务器功能还可以被配置成:从所述第二内容递送网络接收过载通知；以及，响应于所述过载通知经由所述第一流式传输控制信道向所述客户端发送清单文件更新消息。
[0032]在另外的方面中，本发明可以涉及用于在如上文所描述的客户端中使用的数据结构，优选为清单文件，其中所述数据结构可以包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述客户端发送与所述一个或多个段相关联的一个或多个段；所述数据结构还包括所述信道建立信息的至少部分。在一个实施例中，所述信道建立信息可以包括与包括控制信道服务器功能的网络节点相关联的位置信息，优选为一个或多个URL，所述控制信道服务器功能被配置用于与所述客户端建立流式传输控制信道。
[0033]本发明还涉及包括软件代码部分的计算机程序产品，所述软件代码部分被配置用于当运行在计算机的存储器中时，执行根据如上文所描述的方法步骤中的任一个的方法步骤。
[0034]将参照附图进一步图示本发明，所述附图将示意性地示出根据本发明的实施例。将理解，本发明不以任何方式被限制到这些特定实施例。
【专利附图】
【附图说明】
[0035]图1描绘了客户端与服务器之间的传统HAS会话的概览。
[0036]图2描绘了根据本发明的一个实施例的客户端与服务器之间的协议流。
[0037]图3描绘了根据本发明的实施例的客户端侧过程流。
[0038]图4描绘了根据本发明的实施例的服务器侧过程流。
[0039]图5A-5C描绘了根据本发明的各种实施例的客户端与服务器之间的协议流。
[0040]图6描绘了根据本发明的实施例的内容流式传输系统。
[0041]图7描绘了用于在根据本发明的实施例的内容流式传输系统中使用的消息流。
[0042]图8描绘了与根据本发明的一个实施例的递送连续性节点(DCN)功能相关联的过程流。
[0043]图9描绘了用于在根据本发明的另一个实施例的内容流式传输系统中使用的消息流。
[0044]图10描绘了用于在根据本发明的又一实施例的内容流式传输系统中使用的消息流。
[0045]图11描绘了用于在根据本发明的另外的实施例的内容流式传输系统中使用的消息流。
[0046]图12描绘了根据本发明的实施例的内容流式传输系统。
[0047]图13描绘了用于在根据本发明的再一实施例的内容流式传输系统中使用的消息流。
[0048]图14描绘了根据本发明的一个实施例的清单文件。
【具体实施方式】
[0049]图1描绘了被配置成通过诸如HAS流式传输协议之类的流式传输协议进行通信的终端中的客户端130与媒体服务器132之间的传统HAS协议流的概览，其包括响应和请求协议消息134、136。这里，终端可以一般地涉及内容处理设备，例如(移动)内容播出设备，诸如电子平板、智能电话、笔记本、媒体播放器等。在一些实施例中，终端可以是机顶盒或内容存储设备，其被配置用于处理和临时存储内容以供内容播出设备未来消费。类似地，媒体服务器可以是内容提供商或内容递送网络(CDN)的部分或者与其相关联。
[0050]协议流可以开始于用户选择去往网站上的视频的链接(步骤102)，其中URL可以(例如通过重定向)指向清单文件。清单文件可以与特定数据结构有关，所述特定数据结构包括构建分段视频文件的段标识符(例如段文件名)和用于定位一个或多个网络节点的关联的位置信息(例如URL)，所述一个或多个网络节点被配置成向客户端(递送节点)递送段；或者可替换地，与能够确定其可能能够递送标识的段的一个或多个网络节点的网络节点有关。在又一实施例中，位置信息还可以指向网络节点上的位置。例如，URL关联的段可以指向在一个递送节点中定义的不同文件夹。
[0051]对优选包括在清单文件中的段的引用(reference)可以包括段标识符和/或用于定位段的与段标识符相关联的位置信息。
[0052]清单文件还可以包括描述段之间的时间和/或空间关系的信息。这样的文件可以使用特定文件扩展名存储和标识，例如.mf、.xml和.m3u8。客户端然后可以发送HTTP获取(GET)请求以从服务器获得清单文件(步骤104)。作为响应，服务器可以通过向客户端发送清单文件而进行响应(步骤106)。客户端此后解析清单文件以获得与请求的视频相关联的段的位置(步骤108)。
[0053]客户端请求来自在清单文件中描述的位置的视频的第一段并且服务器通过向客户端发送所请求的段来对请求进行响应(步骤110、112)。基于清单文件，可以获取若干段(步骤114、116)。然后，在某个时间量之后，客户端可以确定(例如基于预定义的定时器到期，或者客户端几乎达到实时流中的清单文件的结束)是时候更新清单文件并且可以向它已经从其获得初始清单的相同位置发送请求(步骤118)。更新的清单文件此后被发送到客户端(步骤120)，其再次被客户端通过开始解析经更新的清单文件而被处理(步骤122)。
[0054]如早前已经论述的，这样的传统HAS内容流式传输系统不允许对客户端与服务器之间的流式传输过程的基于服务器的控制。它不允许在难以预测并且其中需要流式传输配置的直接适配的特别情形中的控制。
[0055]图2描绘了根据本发明的一个实施例的客户端与服务器之间的协议流。具体地，图2描绘了与用于将来自媒体服务器232的内容流式传输到客户端230的诸如HTTP自适应流(HAS)协议之类的流式传输协议相关联的协议流。
[0056]客户端可以包括流式传输客户端功能248，其处理用于通过视频播出功能246播出的流，以及控制信道客户端功能244 (CCCF)0类似地，媒体服务器可以包括用于将媒体流式传输到流式传输客户端功能248的流式传输服务器功能242。媒体服务器还可以包括在服务器232中或与服务器232相关联的控制信道服务器功能(CCSF)，例如HAS控制信道服务器功能234，所述服务器232被配置成发起CCSF与CCCF 244之间的流式传输控制信道236的建立，其中流式传输控制信道可以被用于在分段内容238到客户端的流式传输期间在客户端与服务器之间交换流式传输控制信息，特别是，源自服务器的到客户端的流式传输控制信息。
[0057]这里，过程可以以如图1中的相同方式开始，即用户点击去往网站上的视频的链接，其中URL可以(例如通过重定向)指向清单文件(步骤200 )。客户端可以发送HTTP获取请求以从服务器获得清单文件并且服务器可以通过向客户端发送清单文件(在该情况中，XML文件)来对其进行响应(步骤202、204)，客户端随后解析清单文件以获得组成请求的内容流的段的位置(步骤206)。然而在该特定情况中，服务器中的CCSF被配置成将信道建立信息插入在清单文件中，这允许客户端中的CCCF和服务器中的CCSF建立流式传输控制信道。
[0058]基于嵌入在清单文件中的信道建立信息，客户端中的CCCF可以例如向服务器中的CCSF发送信道建立请求(步骤208)以用于建立服务器到客户端流式传输控制信道。在一个实施例中，CCCF和CCSF可以包括被配置成使用WebSocket协议和信道建立信息来建立客户端与服务器之间的流式传输控制信道的HTTP WebSocket API。WebSocket连接通常使用标准HTTP端口 80和443，使得数据可以容易地传递防火墙和NAT，但是还可以使用其它端口。
[0059]WebSocket协议的使用在⑶N和HAS的上下文内具有若干优势，诸如用于可缩放性的低消息开销，用于协议汇聚和防火墙的穿过的HTTP的使用，以及其它协议的隧道传输的可能性。在另一个实施例中，使用会话发起协议(SIP) (http://tools.1etf.0rg/html/rfc3261)，其中客户端可以包括SIP用户代理并且服务器是SIP应用服务器。
[0060]在又一实施例中，使用可扩展消息传递和存在协议(XMPP) (http://www.1etf.0rg/rfc/ rfc3920.txt)，其中客户端可以包括XMPP客户端并且服务器包括XMPP服务器。SIP 和 XMPP 协议消息二者可以通过根据 draft-1bc-rtcweb-sip-websocket-OO 和 draft-moffitt-xmpp-over-websocket-ΟΟ的WebSocket隧道传输。在图5A-5C中提供针对不同协议的实施例的更加详细的描述。
[0061]在流式传输控制信道的建立期间，可以在CCCF和CCSF之间交换信道参数(步骤210)。另外，为了处理源自客户端的消息，CCSF可以创建专用信道处理过程(线程)(步骤212)。一旦建立流式传输控制信道214，客户端可以开始对标识在清单文件中的段进行流式传输的过程。流式传输过程可以基于HAS类型流式传输协议并且开始于包括与第一段segment_low-l.avi相关联的URL的HTTP获取请求(步骤216)。一旦第一段的递送被HTTP200 OK响应确认(步骤218)，客户端可以请求后续段segment_high-2.avi(步骤220、222)。
[0062]然后，媒体服务器中的CCSF可以决定对于客户端来说更新其清单文件是必要的。例如，CCSF可以检测可能的服务器过载或故障。它因此可以通过流式传输控制信道发送可选地包括指向新的清单文件的URL的清单更新信号(步骤224)。当接收到清单文件更新信号时，CCCF可以请求新的清单文件。当接收到新的清单文件时，客户端可以基于新的清单而继续流式传输(未示出)。
[0063]在一个实施例中，代替传递清单文件中的信道建立信息，信道建立信息可以被预安装到终端中或者可以经由单独的通信信道从另一个(网络)源获取。在这种情况中，当客户端接收到清单文件时，它触发获取信道建立信息的流式传输控制信道客户端功能以便建立流式传输控制信道，如参照图2步骤208-214描述的那样。
[0064]在另一个实施例中，媒体服务器可以被配置成将段流式传输到多个客户端，其中每个客户端与其自身的流式传输控制信道相关联以便实现网络发起的(例如服务器发起的)控制，如参照图2描述的那样。这样，服务器可以基于网络参数(例如网络业务或服务器的处理负载)而控制分段内容到多个客户端的流式传输。例如，在一个特定实施例中，不同客户端可以与不同订阅相关联，例如高级(premium)订阅和普通订阅。当与媒体服务器相关联的负载平衡功能240检测到负载上的增加时，它可以抢先通过用信号通知CCSF发起清单文件更新来降低它的负载，其中普通客户端(的至少其部分)被提供有使这些客户端请求与低速率和/或(较)低质量相关联的段的新的清单文件。
[0065]可以以各种方式实现清单文件更新。在一个实施例中，可以经由流式传输控制信道向客户端发送更新的清单文件的全部或至少部分。在另外的实施例中，CCSF可以向客户端(特别地，CCCF)发送清单更新触发，客户端通过向(默认)位置(例如原始媒体服务器)或向如清单文件更新触发中(例如，使用URL)所标识的新的位置(例如另外的媒体服务器)请求更新的或新的清单文件来进行响应。
[0066]图3描绘了根据本发明的实施例的客户端侧过程流。具体地，图3描绘了与在客户端上执行以用于段的获取和播出和用于提供如例如图2中描绘的通过流式传输控制信道的流式传输的服务器发起的控制的过程相关联的过程流。过程可以开始于客户端请求与特定分段内容项相关联的清单文件(步骤300)。清单文件可以包括段位置，而且还包括客户端用于建立流式传输控制信道的信道建立信息(诸如WebSocket URL和可能地用于指示例如WebSocket子协议的使用、WebSocket版本等的一些参数。当从服务器接收到清单文件时，客户端可以解析清单文件(步骤301和302)并且在客户端中开始至少两个不同的过程/线程:至少是由客户端中的媒体流式传输客户端功能执行以用于处理段获取和段的回放的第一过程以及由客户端中的CCCF执行以用于处理流式传输控制信道的第二过程。客户端可以使用在清单文件中描述的段位置以周期性地获取段并且将它们播出(步骤303)，直到检测到视频的结束为止(步骤304)。另外，客户端可以使用嵌入在清单文件中的信道建立信息以基于清单文件中描述的URL而向服务器发送信道建立请求(步骤305)并且在客户端(特别是客户端中的CCCF)与服务器(特别是与服务器相关联的CCSF)之间建立流式传输控制信道(步骤306)。然后，在段的流式传输和播出期间，CCCF针对来自服务器的传入消息而侦听(Iisten)流式传输控制信道(步骤307)。流式传输控制信道还可以用于从客户端到服务器的数据传输。
[0067]在来自服务器的传入消息的情况中，CCCF可以检查是否已经接收清单更新信号(清单更新触发)(步骤308)。如果已经接收这样的清单更新信号，CCCF可以请求更新的清单(要么来自它从其接收原始清单的位置要么来自清单更新触发消息中指定的URL)(步骤309)。在接收更新的清单文件之后，客户端对其进行解析(参见步骤302)并且更新段标识符和相关联的位置信息的列表。
[0068]图4描绘了根据本发明的实施例的服务器侧过程流。具体地，图4描绘了在媒体服务器上执行以用于将段流式传输到客户端并且用于使用流式传输控制信道提供对流式传输的网络发起的控制的过程的过程流。过程可以由媒体服务器上主控的各种功能执行，如例如参照图2描述的那样，即流式传输服务器功能、控制信道服务器功能以及，可选地，负载平衡功能。功能可以被配置成执行一个或多个过程以用于监视服务器负载、对来自客户端的段请求进行响应和建立并维护与客户端的流式传输控制信道。
[0069]例如，第一过程可以由监视对客户端向服务器发送的信道建立的请求的接收的媒体服务器中的CCSF执行(步骤402)。如果接收到这样的请求，CCSF可以建立流式传输控制信道并且发起信道处理过程，其中源自或发送到客户端的信息例如被适当地处理。第二过程可以由处理对来自客户端的针对清单文件和/或段的请求的接收的媒体流式传输服务器功能执行(步骤400)。如果接收到这样的请求，服务器可以向请求客户端发送所请求的信息(段和/或清单文件)(步骤401)。第三过程可以涉及监视网络负载信息和/或服务器负载信息的负载平衡功能。如果负载达到或接近某个(最大)阈值，它可以发信号通知CCSF选择用于清单文件更新的一个或多个客户端(步骤405)。作为响应，CCSF可以向所选客户端发送清单更新触发(步骤406)。
[0070]例如，在一个实施例中，与服务器相关联的负载平衡功能可以发信号通知CCSF发起清单文件更新以便降低服务器的处理负载。更新的清单文件指示客户端基于较低质量的段的而继续流式传输。在另一个实施例中，CCSF可以检测服务器过载或服务器故障并且作为响应发起清单文件更新以用于指示一个或多个客户端从另一个网络服务器获取段。
[0071]清单更新过程可以以若干方式实现。在一个实施例中，更新的清单文件可以由CCSF经由流式传输控制信道发送到客户端中的CCCF。在另一个实施例中，CCSF可以向客户端中的CCCF发送清单文件更新触发，其作为响应而向媒体服务器请求更新的或新的清单文件。在另外的实施例中，清单文件更新触发可以包括另外的媒体服务器的位置信息，例如URL，使得客户端可以基于该位置信息而向该另外的媒体服务器请求更新的或新的清单文件(步骤406)。
[0072]图5A-5C描绘了用于建立流式传输控制信道以用于实现网络发起的流式传输控制的的各种非限制性协议流。具体地，图5A描绘了类似于图2的消息流，其中HTTPWebSocket协议被用于建立流式传输控制信道。该过程可以开始于用户选择去往网站上的视频的链接，其中URL可以(例如通过重定向)指向清单文件(步骤500a)。作为响应，客户端可以发送HTTP获取请求以从服务器获得清单文件(步骤501a)，所述清单文件由服务器发送(在这种情况中以XML文件的形式)到客户端(步骤502a)。
[0073]客户端可以解析清单文件以获得构建视频的段的至少部分的位置(步骤503a)并且使用嵌入在清单文件中的信息以向服务器发送WebSocket建立请求(HTTP GET/WSws://…)(步骤504a)。在执行强制WebSocket握手之后(如在WS草案draft-1etf-hyb1-thewebsocketprotocol-17中详细描述的那样),服务器可以使用HTTP 101切换协议消息接受来自客户端的WebSocket请求(步骤505a)。然后，为了通过要创建的WebSocket处理传入消息，服务器可以创建专用过程/线程(步骤506a)从而建立WebSocket流式传输控制信道，其可以被用于提供服务器发起的流式传输控制(步骤507a)。
[0074]WebSocket协议允许通过尽力而为(best-effort)的因特网连接的全双工、双向通信。服务器和客户端二者可以在任何时间或甚至在相同时间通过流式传输控制信道发送数据。只有数据被发送而没有HTTP报头(header)的开销，从而急剧增加带宽。而且，由于WebSocket是基于HTTP的协议，它通常不会被防火墙或网络地址翻译器(NAT)自动阻挡。
[0075]图5B描绘了用于建立使用SIP协议的类似于图2的流式传输控制信道的消息流。该过程可以开始于用户选择去往网站上的视频的链接，其中URL可以(例如通过重定向)指向清单文件(步骤500b)。作为响应，客户端可以发送HTTP获取请求以从服务器获得清单文件(步骤501b)，所述清单文件由服务器发送(在这种情况中以XML文件的形式)到客户端(步骤 502b)。
[0076]客户端可以解析清单文件以获得组成视频的段的位置(步骤503b)并且使用嵌入在清单文件中的信息来向SIP应用服务器发送SIP邀请(INVITE)消息(步骤504b)。该信息可以被格式化为会话描述协议消息[http://www.1etf.0rg/rfc/rfc4566.txt]。服务器可以接受邀请消息并且用SIP 200 OK消息进行响应(步骤505b)。然后，为了处理通过要创建的SIP会话的传入消息，服务器可以创建专用过程/线程(步骤506b)从而建立基于SIP的流式传输控制信道，其可以被用于提供服务器发起的流式传输控制(步骤507b )。
[0077]图5C描绘了用于建立使用XMPP协议的类似于图2的流式传输控制信道的消息流。该过程可以开始于用户选择去往网站上的视频的链接，其中URL可以(例如通过重定向)指向清单文件(步骤500c)。作为响应，客户端可以发送HTTP获取请求以从服务器获得清单文件(步骤501c)，所述清单文件由服务器发送(在这种情况中以XML文件的形式)到客户端(步骤 502c)。
[0078]客户端可以解析清单文件以获得组成视频的段的位置(步骤503c)并且使用嵌入在清单文件中的信息(诸如XMPP服务器的Jabber标识符(JID))来通过XML流向XMPP服务器发送以一个或多个XML节(Stanza)的形式的XMPP会话请求消息(步骤505c)。XMPP服务器可以接受会话请求消息并且用会话创建结果消息进行响应(步骤506c)。然后，为了处理通过要创建的XMPP会话的传入消息，服务器可以创建专用过程/线程(步骤507c)从而建立基于XMPP的流式传输控制信道，其可以被用于提供服务器发起的流式传输控制(步骤508c)。
[0079]图6描绘了根据本发明的一个实施例的用于将分段内容递送到客户端的内容流式传输系统600。具体地，图6描绘了包括CDN的内容递送系统的架构概览，其被配置成提供对CDN中的一个或多个递送节点与一个或多个客户端之间的流式传输过程的网络发起的控制。网络发起的控制可以基于如参照图2-5描述的流式传输控制信道功能而实现。
[0080]在该实施例中，内容递送系统可以包括至少一个内容递送网络(⑶N) 602、经由传输网络600连接到一个或多个客户端603的内容源(CS)601。内容源可以涉及内容提供商系统(CPS)、内容准备系统或另一个CDN。CPS可以被配置成向消费者供应内容，例如音频项或视频标题，消费者可以使用客户端购买和接收内容。
[0081]客户端可以以运行在终端(即内容处理设备)上的软件程序来实现，例如诸如电子平板、智能电话、笔记本、媒体播放器等之类的(移动)内容播出设备。在一些实施例中，终端可以是机顶盒或内容存储设备，其被配置成处理和临时存储内容以供内容播出设备未来消费。
[0082]CDN可以包括递送节点(DN1、DN2 ) 611、612和至少一个中央CDN节点(CCN ) 610。每个递送节点可以包括控制器630、631和用于存储和缓存内容的高速缓存632、633或者与其相关联。每个CCN可以包括用于控制来自外部源(例如内容提供商或另一个CDN)的内容的摄取(ingest1n)的摄取功能(或内容起源功能，C0F) 620、用于维护关于内容存储在⑶N内的哪里的信息的内容位置数据库622和用于控制内容的一个或多个副本到递送节点的分发并且用于将客户端重定向到合适的递送节点(还称为请求路由的过程)的⑶N控制功能(⑶NCF) 621或者可以与其相关联。可以控制所述分发使得遍及⑶N，保证用于到客户端的内容递送的充足带宽。在一个实施例中，⑶N可以涉及如ETSI TS 182 019中描述的⑶N。
[0083]消费者可以通过向web入口(WP) 661发送请求来从CPS 660购买分段内容，例如视频标题，所述web入口 661被配置成提供标识可购买的视频标题的标题引用。响应于请求，客户端可以接收来自WP的标题引用的至少部分和能够递送所选内容⑶N的⑶NCF的位置信息(例如URL)。
[0084]⑶NCF可以发送与一个或多个递送节点相关联的客户端位置信息，所述一个或多个递送节点被配置成向客户端递送所选内容。可以在CDN中的一个递送节点上或者可替换地，在⑶N中的不同递送节点上主控所述段。例如，可以在⑶N中的多个递送节点上主控更流行的段，使得可以保证及时递送。通常，CDNCF可以选择CDN中最适于向客户端递送所选内容的递送节点。用于选择一个或多个递送节点的准则可以基于递送节点的处理负载和/或与客户端相关联的上下文信息:例如客户端的位置(IP地址)和/或客户端的订阅(例如如参照图2描述的高级订阅或普通订阅)。因而，这样，CDNCF可以动态地生成清单文件，其被优化以用于向客户端高效递送段。
[0085]客户端可以使用例如传统DNS系统而与CDN中的递送节点联系。另外，各种流式传输协议可以被用于向对流进行处理以供视频播出功能651播出的媒体流式传输功能652递送内容。这样的协议可以包括HTTP和RTP/RTCP类型流式传输协议。在优选实施例中，可以使用诸如HTTP自适应流(HAS)和有关协议之类的自适应流协议，诸如Apple HTTP实时流式传输、Microsoft平滑流式传输、Adobe HTTP动态流式传输、3GPP-DASH和MPEG通过HTTP的动态自适应流。
[0086]CDN被配置成摄取和分发分段内容。已知的分段流式传输系统可以基于时间分段，诸如HTTP自适应流(HAS)，其中内容可以组织在许多段(片或部分)中，其可以根据诸如MPEG或AVI之类的已知传输容器格式被格式化。
[0087]段之间的关系可以描述在清单文件中，其可以使用特定文件扩展名被存储和标识，例如.mf、.xml和.m3u8。清单文件还可以描述一个或多个递送节点上的不同段的位置和名称(段标识符)。可以从CDN中的多于一个的递送节点获取段，特别是流行段。而且，在某些情形中，段应当从另一个CDN域中的递送节点获取。将参照图12和13更加详细地描述该情形。CDNCF可以管理其中可以获取段的位置。为此，CDNCF可以使用内容位置数据库622。在一个实施例中，内容位置数据库可以涉及资产位置功能(ALF) JBETSI TS 182 019中描述的那样。
[0088]另外，⑶N可以包括递送连续性节点(DCN) 613，其被配置成建立和管理与客户端相关联的流式传输控制信道并且维护包括客户端和这些客户端连接到的一个或多个递送节点的数据库。DCN可以包括递送连续性管理功能(DCMF) 640。该功能可以执行用于监视源自⑶NCF的请求路由(RR)功能的通知的过程。DCN还可以包括用于监视来自客户端的信道建立请求并且与客户端中的控制信道客户端(CCCF)功能650建立流式传输控制信道的DCN中的控制信道服务器功能(CCSF) 641。
[0089]另外，在DCN中或与其相关联的递送连续性(DC)数据库642可以存储客户端信息(例如其IP地址)和清单文件信息(即段标识符(例如文件名)和主控这些段的递送节点的至少部分)。递送连续性管理功能(DCMF)可以监视源自⑶NCF或来自⑶N中的单独的网络监视功能的网络通知(例如(过)负载通知或故障通知)并且响应于这样的网络通知的接收而开始清单文件更新过程。参照图8描述关于DCN中的过程和功能的细节。
[0090]尽管在图6中DCN中的功能(即DCMF和CCSF)被实现在不同的节点(DCN)上，但是在另外的实施例中，这些功能还可以完全地或部分地实现在包括CDNCF和摄取功能的CCN610 上。
[0091]图7描绘了用于在根据本发明的实施例的内容流式传输系统中使用的消息流。具体地，图7描绘了用于在CDN类型内容流式传输系统中使用的消息流，所述CDN类型内容流式传输系统被配置成提供CDN中的一个或多个递送节点与一个或多个客户端之间的流式传输过程的网络发起的控制。在该实施例中，⑶N可以包括至少第一和第二递送节点(DN1、DN2)以及包括CDNCF、DCMF和CCSF的CCN，如参照图6描述的。
[0092]图7中的过程可以开始于用户选择去往网站上的视频的链接，其中URL可以(例如通过重定向)指向清单文件(步骤700)。基于选择，客户端可以向CDNCF发送HTTP获取请求以获得清单文件(步骤701)。CDNCF可以通过向客户端发送清单文件来对所述请求进行响应(步骤702)。在这种情况中，基于来自负载平衡功能的信息，CDNCF可以选择和/或生成包含对存储在第一递送节点DNl上的段的引用(例如段标识符和/或相关联的位置信息)的清单文件。另外，⑶NCF记录以下事实:它已经向特定客户端(由例如其IP地址定义)发送包含对特定一个或多个递送节点(的集合)(在该示例中，递送节点DNl)的引用的清单文件。为此，CDNCF可以存储与视频标题的至少部分相关联的客户端信息(例如客户端的IP地址)和清单文件信息(例如清单文件标识符清单ID)以及主控被递送连续性(DC)数据库中的清单文件引用的段的特定一个或多个递送节点(的集合)的位置信息以供未来使用(步骤
703)。
[0093]这里，清单文件标识符可以由数字标识并且递送节点可以由⑶N中已知的递送节点标识符标识。客户端可以解析清单文件以获得组成视频的段的位置(例如URL)(步骤
704)。另外，客户端中的CCCF可以使用清单文件中的信道建立信息以建立⑶N中的CCCF与CCSF之间的流式传输控制信道(步骤705a)(在CCCF与CCSF之间建立流式传输控制信道的过程参照图2和3加以描述，并且在此不重复)。
[0094]在流式传输控制信道的建立期间，CCSF可以通过使用存储在DC数据库中的信息来使信道建立请求与特定客户端和一个或多个相关联的递送节点相关(步骤705b)。特别地，CCSF可以针对为其建立流式传输控制信道的客户端(其中客户端可以被例如其IP地址标识)而查询DC数据库并且向属于客户端的数据库条目分配唯一流式传输信道标识符或信道ID (例如端口号或在使用WebSocket的情况中，WebSocket ID)。这样，CCSF能够使特定客户端-信道组合与特定的一个或多个递送节点(的集合)和/或清单文件相关。
[0095]一旦流式传输控制信道被建立，客户端可以通过向第一递送节点DNl请求第一段(在这种情况中为segment_low-l)(如在清单文件中也被引用的)来开始流式传输过程(步骤706)。递送节点DNl可以通过将请求的段流式传输到客户端来进行响应(步骤707)。
[0096]在流式传输过程期间，在某个时间点处，⑶NCF (包括用于监视⑶N中的递送节点的负载的负载平衡功能或与其相关联)可以注意到第一递送节点DNl上的负载接近(最大)阈值水平(步骤708)。CDNCF可以告知DCMF通过检查存储在DC数据库中的信息来检查哪些客户端正在使用第一递送节点DNl (步骤709)。DCMF然后可以决定将一些(或全部)客户端离开第一递送节点DNl而重定向到另一个、第二递送节点DN2,使得降低第一递送节点Dl的处理负载。为此，DCMF可以指示CCSF通过DCMF使用DC数据库中的信息选择的客户端的流式传输控制信道而发送清单更新触发(步骤710)。
[0097]当接收到清单更新触发时,客户端中的CCCF被触发而通过向⑶NCF发送清单请求来请求新的或更新的清单文件(步骤711)(以如参照步骤701描述的类似的方式)。CDNCF可以接收清单请求并且针对客户端而选择或生成新的或更新的清单文件并且向客户端发送该清单文件。
[0098]在一个实施例中，当生成新的或更新的清单文件时，CDNCF可以使用来自负载平衡功能的信息以便选择新的递送节点(同样参见步骤702)。另外，新的或更新的清单文件可以包含去往存储在第二递送节点DN2上的段的链接。
[0099]在一个实施例中，清单更新触发可以包括标识包括新的或更新的清单文件的另外的节点的位置信息，例如URL。在另一个实施例中，代替发送清单更新触发以发信号通知客户端获取新的或更新的清单文件，新的或更新的清单文件可以直接经由流式传输控制信道发送到客户端。在更新的清单文件被发送回到客户端之后，所述客户端使用新的或更新的清单文件恢复来自第二递送节点的段的流式传输(未示出)。
[0100]由于客户端已经接收到新的或更新的清单文件，⑶NCF可以通过执行如参照703描述的步骤来更新与DC数据库中的该客户端相关联的清单文件信息。这样，如果在未来的某个时间点处出现过载问题，CDNCF可能能够将客户端再次重定向到另一个递送节点。
[0101]图8描绘了与根据本发明的一个实施例的递送连续性节点(DCN)相关联的过程流。具体地，图8提供了可以在如参照图6描述的递送连续性节点(DCN)上主控的一个或多个功能的概览。DCN可以被配置成建立和管理与客户端相关联的流式传输控制信道并且维护列出客户端和它们连接到的一个或多个递送节点的表。在另一个实施例中，与DCN相关联的功能中的全部或至少部分可以在CCN上主控(参见图7、9、11和13)。
[0102]DCN可以包括递送连续性管理功能(DCMF)。该功能可以执行用于监视源自⑶NCF的请求路由(RR)功能的通知的过程(步骤800)。无论何时⑶NCF向客户端发送清单文件，或将客户端重定向到特定递送节点，CDNCF可以告知DCN客户端预期从哪些递送节点获取段(即在发送到客户端的清单文件中引用的递送节点，或客户端重定向到的递送节点)。当接收到通知时，DCN可以将向发送到该客户端的清单文件中引用的递送节点的至少部分分配特定客户端(由例如其IP地址标识)的条目添加到递送连续性(DC)数据库中(步骤801)。
[0103]另外，控制信道服务器功能(CCSF)可以监视来自客户端中的CCCF的信道建立请求(步骤802)。如果它接收到请求，它将开始基于适合的协议(例如WebSocket、SIP或XMPP)而建立流式传输控制信道的过程。
[0104]在流式传输控制信道的建立期间，CCSF可以针对为其建立流式传输控制信道的客户端(其中客户端可以被例如其IP地址标识)而查询DC数据库并且向属于客户端的数据库条目分配唯一流式传输信道标识符(例如端口号，或者在使用WebSocket的情况中，WebSocket ID)(步骤803)。DCMF然后可以执行用于监视例如来自⑶NCF、与⑶NCF相关联的负载平衡功能(步骤804)或单独的网络监视功能的网络过载通知或故障通知的网络通知的监视过程。在一个实施例中，过载或故障通知可以包括关于CDNCF想要重定向的客户端的数目的信息。
[0105]一旦DCMF从⑶NCF接收到这样的通知(要么涉及在其自身的⑶N中的递送节点要么涉及另一个CDN (未示出)中的递送节点)，它可以查询DC数据库以检查预期从与过载或故障通知相关联的递送节点获取段的客户端(步骤805)。DCMF然后可以选择要重定向的一个或多个客户端(步骤806)(该选择可以基于要重定向的客户端的数目，如上文参照步骤804描述的那样)。此后，DCMF可以查询它的数据库以便识别与所选客户端相关联的流式传输信道(使用例如流式传输信道标识符)并且通过这些信道中的每一个发送清单更新触发。
[0106]DMCF还可以被配置成监视源自客户端的消息。在一个实施例中，DMCF可以通过流式传输控制信道向客户端发送新的或更新的清单文件。
[0107]图9描绘了用于在根据本发明的另一个实施例的内容流式传输系统中使用的消息流。具体地，图9示出了用于与类似于图7的内容递送系统一起使用的消息流。然而在该实施例中，清单文件并不是通过CDNCF递送到客户端，而是通过递送节点自身。为此，递送节点(例如第一递送节点DNl)可以包括仅包含对该递送节点上的段的引用的清单文件。
[0108]图9中的过程可以开始于用户选择去往网站上的视频的链接，其中URL (例如通过从内容提供商的重定向)指向⑶NCF的请求路由(RR)功能(步骤900)。在客户端已经向⑶NCF发送HTTP获取请求(步骤901)之后，⑶NCF的RR功能可以基于例如从负载平衡功能获得的信息而选择适于向客户端递送请求的清单文件和相关联的分段内容的递送节点。CDNCF然后可以向客户端发送包含去往所选递送节点(在该特定示例中，第一递送节点DNl)上的清单文件的URL的HTTP重定向(REDIRECT)消息(步骤902)。
[0109]当重定向HTTP获取请求时，⑶NCF可以将客户端信息(例如客户端的IP地址)和清单文件信息(例如与视频标题的至少部分相关联的清单文件标识符或清单ID，以及主控被清单文件引用的段的特定的一个或多个递送节点(的集合)的位置信息)存储在递送连续性(DC)数据库中以供另外的使用(步骤903)。这里，清单文件标识符可以由数字标识并且递送节点可以由⑶N内已知的递送节点标识符标识。
[0110]当从⑶NCF接收到HTTP重定向消息时，客户端可以向与第一递送节点相关联的重定向消息中的URL发送新的HTTP获取消息(步骤904)。递送节点DNl随后通过向客户端发送请求的清单文件进行响应(步骤905)。
[0111]在已经接收到清单文件之后，客户端可以解析清单文件以获得组成视频的段的位置(步骤906)。客户端中的CCCF可以使用清单文件中的信道建立信息以建立CCSF与客户端之间的流式传输控制信道(步骤907a)(建立信道的过程在图2和3中描述并且在此不重复)。
[0112]在流式传输控制信道的建立期间，CCSF可以通过使用存储在DC数据库中的信息来使信道建立请求与特定客户端和相关联的递送节点相关(步骤907b)。特别地，CCSF可以针对为其建立流式传输控制信道的客户端(其中客户端可以例如由其IP地址标识)而查询DC数据库并且向属于客户端的数据库条目分配唯一流式传输信道标识符(例如端口号或，在使用WebSocket的情况中，WebSocket ID)。这样，CDN中的功能可以检查哪些客户端/信道组合正在使用哪些一个或多个递送节点(的集合)(例如在这种情况中，CDNCF可以检查到特定客户端正在使用第一递送节点DNl并且已经接收到特定清单文件)。
[0113]一旦流式传输控制信道被建立(如例如图2和3中所描述的那样)，客户端可以开始请求、接收和播出从第一递送节点DNl获得的段(步骤908)。在流式传输过程期间，在某个时间点处，CDNCF(其包括用于监视CDN中的负载递送节点的负载平衡功能或与其相关联)可以注意到第一递送节点DNl上的负载达到预定(最大)阈值水平(步骤909)。⑶NCF然后可以触发DCMF通过检查存储在DC数据库中的信息来确定哪些客户端与第一递送节点DNl相关联(步骤910)。基于该信息，DCMF可以决定将一些(或所有)客户端重定向离开第一递送节点DNl。
[0114]为此，它可以触发CCSF通过这些客户端的控制信道发送清单更新触发(步骤911)。为了确保客户端不从第一递送DNl (作为默认)接收它们的更新的清单，清单更新触发可以包括与新的或更新的清单文件相关联的URL (指向例如第二递送节点DN2)。清单更新触发的接收用信号通知客户端应当请求新的清单文件。它然后可以发送对与清单更新触发中引用的第二递送节点DN2相关联的URL的清单文件请求(步骤912)。第二递送节点DN2可以通过向客户端发送请求的清单文件来进行响应。
[0115]当接收到该清单文件时，客户端可以通过向第二递送节点DN2而不是第一递送节点DNl请求后续段来继续流式传输过程(步骤913)。由于客户端已经接收到新的或更新的清单文件，CDNCF可以通过执行如参照903描述的步骤来更新与DC数据库中的该客户端相关联的清单文件信息。这样，如果在未来的某个时间点中出现过载问题，CDNCF可能能够将客户端再次重定向到另一个递送节点。
[0116]因而，在图9中描绘的实施例中，包括用于建立客户端与CCSF之间的流式传输控制信道的信道建立信息的清单文件被存储在其中存储段的递送节点处。该实现方式提供了以下优势:一些负载和⑶NCF的复杂度被卸载到递送节点。在图7中，⑶NCF主控和/或生成清单文件，使得在每次更新清单文件时，负载被添加到CDNCF。在某些实现方式中，例如在针对实时内容的情况中，客户端发起的清单更新可能相当常出现，例如每30秒一次，从而大幅增加CDNCF上的负载。因而，通过将对客户端发起的清单请求进行响应的任务委托给递送节点，可以实现CDNCF的相当大的负载降低。
[0117]图10描绘了用于在根据本发明的又一实施例的内容流式传输系统中使用的消息流。具体地，图10描绘了类似于图7的消息流，然而代替使DCN功能添加到CDNCF，DCN位于单独的节点中。
[0118]图10中的过程可以开始于用户选择去往网站上的视频的链接，其中URL可以(例如通过重定向)指向在⑶NCF上主控的清单文件(步骤1000)并且客户端传输HTTP获取请求以从⑶NCF获得清单文件(步骤1001)。⑶NCF可以通过向客户端发送清单文件来对该请求进行响应。在该示例中，基于从负载平衡功能获得的信息，CDNCF可以选择包含对存储在第一递送节点DNl上的段的引用的清单文件(步骤1002)。
[0119]⑶NCF可以向DCN、特别是DCN中的DCMF发送通知，指示特定客户端(由例如其IP地址标识)已经被提供有包括对特定的一个或多个递送节点(的集合)的引用的新的或更新的清单文件(步骤1003)。DCMF可以将客户端信息(例如客户端的IP地址)和清单文件信息(例如与视频标题的至少部分相关联的清单文件标识符或清单ID，以及主控被清单文件引用的段的特定的一个或多个递送节点(的集合)的位置信息)存储在DC数据库中以供未来使用(步骤1004)。这里，清单文件标识符可以由数字标识并且递送节点可以由CDN内已知的递送节点标识符标识。
[0120]客户端可以解析清单文件以获得组成视频的段的位置(例如URL)(步骤1005)。另夕卜，客户端可以使用清单文件中的信道建立信息以建立到DCN的信道(步骤1006a)。(建立信道的过程在图2和3中描述并且在此不重复)。
[0121]在流式传输控制信道的建立期间，CCSF可以通过使用存储在DC数据库中的信息来使信道建立请求与特定客户端和相关联的一个或多个递送节点(的集合)相关。特别地，CCSF可以针对为其建立流式传输控制信道的客户端(其中客户端可以例如由其IP地址标识)而查询DC数据库并且向属于客户端的数据库条目分配唯一流式传输信道标识符(例如端口号或，在使用WebSocket的情况中，WebSocket ID)。这样，CDN中的功能(例如CDNCF、DCMF和CCSF)能够使特定客户端-信道组合与特定的一个或多个递送节点(的集合)相关。
[0122]一旦建立流式传输控制信道，流式传输客户端功能可以开始请求、接收和播出从第一递送节点DNl获得的段(步骤1007)。在流式传输过程期间，DCMF可以执行用于监视网络通知(例如来自CDNCF、与CDNCF相关联的负载平衡功能或网络监视功能的网络过载或故障通知)的监视过程。例如，在某个时间点处，包括用于监视全部递送节点的负载的负载平衡功能或与其相关联的CDNCF可以注意到DNl上的负载达到预定(最大)阈值(步骤1008)。
[0123]⑶NCF然后可以向DCMF发送过载通知，其指示第一递送节点DNl上的负载接近预定(最大)阈值。在一个实施例中，过载通知可以包括关于要重定向的客户端的数目的信息(步骤1009)。DCMF可以通过检查DC数据库中的清单文件信息来确定正在使用第一递送节点DNl的客户端(步骤1010)。
[0124]DCMF然后可以选择要重定向的客户端并且触发CCSF通过那些客户端的流式传输控制信道发送清单更新触发(步骤1011)。清单更新触发的接收可以用信号通知客户端通过以如参照步骤1001描述的类似的方式向CDNCF发送清单请求来请求新的清单文件(步骤1012)。
[0125]⑶NCF可以接收清单请求并且生成或选择适于客户端的新的清单文件(步骤1013)(例如通过咨询负载平衡功能)。在这种情况中，所选清单文件可以例如包含去往存储在第二递送节点DN2上的段的链接。所选清单文件然后可以被发送到客户端。当接收到新的清单文件时，客户端可以通过向第二递送节点DN2而不是第一递送节点DNl请求后续段来继续流式传输过程。
[0126]由于客户端已经接收到新的或更新的清单文件，其引用在不同递送节点(即第二递送节点DN2而不是第一递送节点DNl)上主控的段，⑶NCF可以更新与客户端相关联的DC数据库中的一个或多个条目。为了这样做，⑶NCF可以向DCN中的DCMF发送通知客户端已经被提供有新的或更新的清单文件(以与参照步骤1003描述的类似方式)。在接收到通知之后，DCMF可以将客户端信息和清单文件信息存储在DC数据库中(以与参照步骤1004描述的类似方式)。这样，CDNCF能够处理与第二递送节点DN2相关联的可能的另外的负载问题。
[0127]因而，图10中描绘的实施例在单独的网络节点DCN上实现用于建立和管理流式传输控制功能的功能，使得对CCN中的CDNCF的所需改变非常有限并且可以重用现有CDNCF实现方式，从而限制在向CDN添加流式传输控制信道功能时所涉及的成本。另外，如果客户端和相关联的活动流式传输控制信道的数目增加，仅DCN的容量而不是整个CDNCF的容量需要升级。该实施例因此提供了用于管理与CDN相关联的大数目的流式传输控制信道的可缩放的解决方案。
[0128]图11描绘了用于在根据本发明的另外的实施例的内容流式传输系统中使用的消息流。具体地，图11示出了类似于图7的消息流，然而代替使每个清单文件仅包括对单个递送节点的引用，清单文件可以包含对多个递送节点的引用。在该实施例中，CDNCF可以被配置成创建和主控清单文件。
[0129]该过程可以开始于用户选择去往网站上的视频的链接，其中URL可以(例如通过重定向)指向清单文件(步骤1100)并且客户端传输HTTP获取请求以从CDNCF获得清单文件(步骤1101)。已经从客户端接收到清单请求，CDNCF可以创建新的清单文件或者选择包括对不同递送节点上的段的引用的现有清单文件(1102)。例如在一个实施例中，清单文件可以包括对在第一递送节点DNl上主控的低质量段的引用，和对在第二递送节点DN2上主控的高质量段的引用。CDNCF可以使用与CDN中的递送节点相关联的负载信息(由负载平衡功能生成)和可选地客户端的位置信息(例如IP地址)以便选择最适于向客户端递送请求的段(的部分)的递送节点。在这种情况中，清单文件可以包括对至少第一递送节点DNl和第二递送节点DN2的引用。
[0130]⑶NCF可以向客户端发送清单文件(步骤1103)并且在DC数据库中存储将客户端信息(例如其IP地址)和清单文件信息(例如客户端的IP地址)和清单文件信息(例如与视频标题的至少部分相关联的清单文件标识符或清单ID，以及主控被清单文件引用的段的特定的一个或多个递送节点(的集合)的位置信息，在这种情况中第一和第二递送节点Dl和D2)(步骤1104)。这里，清单文件标识符可以由数字标识并且递送节点可以由⑶N内已知的递送节点标识符标识。
[0131]客户端可以解析清单文件以获得组成视频的段的位置(步骤1105)并且使用清单文件中的信道建立信息以建立客户端与CCSF之间的流式传输控制信道(步骤1106a)。(建立信道的过程在图2和3中描述并且在此不重复)。
[0132]在流式传输控制信道的建立期间，CCSF可以通过使用存储在DC数据库中的信息来使信道建立请求与特定客户端和相关联的一个或多个递送节点(的集合)相关。特别地，CCSF可以针对为其建立流式传输控制信道的客户端(其中客户端可以例如由其IP地址标识)而查询DC数据库并且向属于客户端的数据库条目分配唯一流式传输信道标识符(例如端口号或，在使用WebSocket的情况中，WebSocket ID)。这样，CDN中的功能可以使特定客户端-信道组合与特定的一个或多个递送节点(的集合)相关。
[0133]一旦建立流式传输控制信道，客户端可以通过请求、接收和播出源自第一和第二递送节点的段来开始流式传输过程(步骤1107)。在流式传输过程期间，在某个时间点处，包括用于监视CDN内的递送节点的负载的负载平衡功能或与其相关联的CDNCF可以注意到第一递送节点DNl上的负载达到或接近预定(最大)阈值(步骤1108)。⑶NCF然后可以触发DCMF通过检查DC数据库中的清单文件信息来检查哪些客户端与第一递送节点DNl相关联(步骤1109)。DCMF然后可以确定哪些客户端需要清单更新并且触发CCSF通过那些客户端的控制信道发送清单更新触发(步骤1110)。
[0134]清单更新触发可以发信号通知客户端它需要通过向CDNCF发送清单请求(参见步骤1101)来请求新的或更新的清单文件(步骤1111)。CDNCF接收清单请求并且创建或选择适于客户端的新的清单文件(参见步骤1102)(步骤1012)。在这种情况中，新的或更新的清单文件可以例如用与主控相同段的另一个递送节点DN (例如第三递送节点DN3)相关联的URL取代与第一递送节点DNl相关联的URL。与递送节点DN2相关联的URL不被取代，因为仅第一递送节点DNl在变得过载的危险中。CDNCF可以向客户端发送新的或更新的清单文件(步骤1113)，其可以更新其(内部)段列表并且通过请求在新的或更新的清单中列出的段来继续流式传输过程。
[0135]由于客户端已经接收到新的或更新的清单文件，⑶NCF可以通过执行如参照1104描述的步骤来更新DC数据库中的与该客户端相关联的清单文件信息。这样，如果在未来的某个点处出现过载问题，⑶NCF可能能够将客户端再次重定向到另一个递送节点。
[0136]因而，图11中描绘的实施例提供了以下优势:被单个清单引用的段可以分布在多个递送节点上，其中每个递送节点仅主控所有段的子集。这样的一个优势是其允许⑶N区分不同类型的段。在分段内容中某些段比其它段更加流行(更常被请求)。例如在时间分段的视频标题中，较早的段通常比较晚的段更常被请求。在另一个示例中，视频标题可以具有涉及不同视频质量的段，其中一些质量将比其它更流行。在这样的情况中，CDN可能在比不太流行的段更多的递送节点处主控更流行的段，从而提供附加的可缩放性和更高的效率。
[0137]图12描绘了根据本发明的另一个实施例的内容流式传输系统。具体地，图12图示了类似于参照图6描述的系统的基于CDN的内容递送系统。然而，在该实施例中系统包括至少两个互连的⑶N。具体地，内容流式传输系统包括经由⑶N互连接口 1264互连到至少第二⑶N 1204 (也称作为下游⑶N)的第一⑶N 1202 (也称作为上游⑶N)，其中每个⑶N被配置成提供CDN中的一个或多个递送节点与一个或多个客户端之间的流式传输过程的网络发起的控制。网络发起的控制可以基于如参照图2-5描述的流式传输控制信道功能而实现。
[0138]内容递送系统还可以包括经由传输网络600连接到主控客户端1203的一个或多个终端1204的内容源1201。内容源可以涉及内容提供商系统CPS、内容准备系统或另一个CDN0 CPS可以被配置成CPS可以被配置成向消费者供应内容(例如视频标题)，消费者可以使用包括对流进行处理以供视频播出功能1251播出的媒体流式传输功能1252的客户端购买和接收内容。
[0139]类似于图6，CDN可以包括递送节点1211、1212、1215和至少一个CCN 1210、1223。每个递送节点可以包括控制器1230、1231、1234和用于存储和缓存内容的高速缓存1232、1233、1235或者与其相关联。每个CCN可以包括用于控制来自外部源(例如内容提供商或另一个⑶N)的内容的摄取的摄取节点(或内容起源功能，C0F) 1220、1223、用于维护关于内容存储在CDN内的哪里的信息的内容位置数据库1222、1225和用于控制内容的一个或多个副本到递送节点的分发并且用于将客户端重定向到合适的递送节点(还称为请求路由的过程)的⑶N控制功能(⑶NCF) 1221、1224或者可以与其相关联。消费者可以通过向web入口(WP) 1261发送请求来从CPS 1260购买内容，例如视频标题，所述web入口 1261被配置成以与参照图6描述的类似方式提供标识可购买的内容项的标题引用。
[0140]⑶NCF可以管理其中可以使用内容位置数据库1222、1225来获取段的位置。另外，⑶N可以包括递送连续性节点(DCN) 1213、1216，其被配置成建立和管理与客户端相关联的流式传输控制信道并且维护包括客户端信息和这些客户端连接到的一个或多个递送节点的清单文件信息。DCN可以被配置为独立的DCN或集成在⑶NCF中。
[0141]DCN可以包括用于监视源自⑶NCF的请求路由(RR)功能的通知的递送连续性管理功能(DCMF) 1240、1243，监视来自客户端的信道建立请求并且与客户端中的控制信道功能1250建立流式传输控制信道的控制信道服务器功能(CCSF) 1241、1244 ;以及，在DCN中或与其相关联的递送连续性(DC)数据库1242、1245，其用于存储客户端信息(例如客户端的IP地址)和清单文件信息(即段标识符(例如文件名)和与主控这些段的递送节点的至少部分相关联的位置信息(例如URL))。
[0142]DCMF可以监视网络通知，例如过载或故障通知，其源自⑶NCF的请求路由(RR)功能，CDN中的单独的过载功能或网络监视功能，并且响应于这样的通知的接收而开始清单文件更新过程。以下将参照图13更加详细地描述清单文件更新过程的细节。
[0143]在图12的内容递送系统中，上游⑶N可以将段到客户端的递送的部分外包给下游CDN0例如，在一个实施例中，低质量段可以由第一 CDN A(被配置例如用于内容到移动设备的递送)定位和递送并且高质量段可以由第二⑶N B(被配置例如用于高质量段到支持HDTV技术的家庭媒体设备的递送)定位和递送。
[0144]当向下游⑶N外包段的递送的部分时，上游⑶N (或者具体地，上游⑶N的⑶NCF)可以开始用于生成包括对第一 CDN A中的一个或多个递送节点的引用和对第二 CDN B中的一个或多个递送节点的引用的清单文件的过程。这样的清单文件可以称作为CDN间清单文件。⑶N间清单文件还可以包括用于建立客户端与上游⑶N A之间的流式传输控制信道的信道建立信息。
[0145]在生成⑶N间清单文件的过程期间，信息可以在⑶N之间经由互连接口 1264进行交换。特别地，在⑶N间清单文件的生成期间，上游⑶N可以向下游⑶N请求关于外包给下游CDN的一个或多个段的位置信息。作为响应，下游CDN可以基于关于客户端的上下文信息而选择主控所请求的段的递送节点。例如，下游CDN可以选择在地理上最靠近客户端的位置的递送节点。该信息随后被发送到上游⑶N的⑶NCF以用于生成⑶N间清单文件。因而，图13中的内容递送系统被配置成动态地生成“个性化”CDN间清单文件。
[0146]一旦CDN间清单文件被生成和转发到客户端，客户端中的控制信道功能可以使用⑶N间清单文件中的信道建立信息与上游⑶N的DCN中的CCSF建立流式传输控制信道以及开始请求并且播出段。
[0147]在流式传输过程期间，DCMF可以从⑶NCF接收网络通知，例如(过)负载通知或故障通知，并且确定客户端应当被重定向到一个或多个其它的递送节点。网络通知可以涉及上游⑶N或下游⑶N中的网络问题情形。在后一种情况中，下游⑶N的⑶NCF可以经由互连接口 1264向上游⑶N的⑶NCF发送网络通知。
[0148]图13描绘了用于在根据本发明的再一实施例的内容流式传输系统中使用的消息流。具体地，图13示出了用于在如图12中描绘的内容递送网络中使用的消息流，其中清单文件可以包括对在与不同CDN相关联的不同递送节点上主控的段的引用。
[0149]该过程可以开始于用户选择去往网站上的视频的链接，其中URL (例如通过重定向)指向在与第一⑶N A相关联的第一⑶NCF上主控的清单文件(步骤1300)。该⑶N还可以称作为上游CDN。基于选择，客户端可以发送HTTP获取请求以从CDN A的CDNCF获得清单文件(步骤1301)。
[0150]在已经从客户端接收到清单请求之后，第一⑶NCF可以开始用于创建新的清单文件或者更新现有清单文件的过程，其中清单文件可以包括对与不同CDN相关联的不同递送节点上的段的引用(步骤1302)。例如，在一个实施例中，低质量段可以由第一⑶N A (被配置例如用于内容到移动设备的递送)定位和递送。该⑶N可以称作为上游⑶N。另外，高质量段可以由第二 CDN B(被配置例如用于高质量段到支持HDTV技术的家庭媒体设备的递送)定位和递送。该⑶N可以被称作为下游⑶N。包括至少对与第一⑶N A相关联的第一递送节点DNl和与CDN B相关联的第二递送节点DN2的引用的清单文件可以被称作为CDN间清单文件。该⑶N间清单文件还可以包括用于在客户端和与上游⑶N A相关联的第一⑶NCF之间建立流式传输控制信道的信道建立信息。
[0151]在一个实施例中，⑶N间清单文件可以基于以下过程而生成，其中上游⑶N A的第一⑶NCF请求下游⑶N B的第二⑶NCF提供对应该由⑶N B递送到客户端的预定数目的段的位置的引用。
[0152]第一⑶NCF然后可以向客户端发送⑶N间清单文件(步骤1303)其中第一⑶NCF可以在与第一 CDNCF相关联的DC数据库中存储与第一 CDN A相关联的客户端信息(例如其IP地址)和清单文件信息，其包括与视频标题的至少部分相关联的清单文件标识符或清单ID,以及主控被清单文件引用的段的特定的(一个或多个)递送节点(的集合)的位置信息)以及与第二⑶N B相关联的(一个或多个)递送节点(的特定集合)(步骤1304)。这里，段可以由文件名标识并且递送节点可以由递送节点标识符标识。这里清单文件标识符可以由数字标识并且递送节点可以由⑶N内已知的递送节点标识符标识。
[0153]因而，在⑶N间清单文件的生成期间，第一和第二⑶NCF之间的通信发生，使得-(尽管第二⑶NCF不知道⑶N间清单文件中的所有段)第二⑶NCF知道位于其一个或多个递送节点(的特定集合)上的预定数目的段可能由客户端在(不远的)未来请求。因此，第二⑶NCF可以将包括下游⑶N中的递送节点(在该示例中，第二递送节点DN2)连同对上游⑶N (在这种情况中，第一⑶NCF)的引用的⑶N间信息存储在与第二⑶N B相关联的DC数据库中，使得能够利用这些递送节点之一向第一 CDNCF通知任何网络问题，例如负载或故障问题(步骤1305)。
[0154]客户端可以解析⑶N间清单文件以便获得组成视频的段的位置(步骤1306)并且使用清单文件中的信道建立信息以建立第一 CDNCF与客户端之间的流式传输控制信道(步骤1307)(建立信道的过程在图2和3中描述并且在此不重复)。
[0155]在流式传输控制信道的建立期间，与第一⑶NI相关联的CCSF可以通过使用存储在第一 DC数据库中的信息来使信道建立请求与特定客户端和相关联的一个或多个递送节点(的集合)相关(步骤1309)。特别地，CCSF可以针对为其建立流式传输控制信道的客户端(其中客户端可以例如由其IP地址标识)而查询DC数据库并且向属于客户端的数据库条目分配唯一流式传输信道标识符(例如端口号或，在使用WebSocket的情况中,WebSocketID)。这样，第一⑶NI中的功能能够使特定客户端-信道组合与特定的一个或多个递送节点(的集合)相关。在流式传输控制信道的建立之后，客户端可以通过请求、接收和播出从与第一(上游)⑶N A相关联的第一递送节点DNl和与第二 (下游)⑶N B相关联的第二递送节点DN2 二者获得的段来开始流式传输过程(步骤1308)。
[0156]在流式传输过程期间，在某个时间点处，监视其自身的递送节点的第二 CDNCF可以注意到网络问题，例如在第二递送节点DN2中的网络故障或在第二递送节点DN2上的负载达到或接近预定(最大)阈值(步骤1309)。然后，基于DC数据库中的⑶N间信息，第二⑶NCF可以通过向第一⑶NCF发送网络通知(例如(过)负载通知或故障通知)来向第一⑶NCF通知网络问题。过载通知可以发信号通知第一⑶NCF对第二⑶N中的递送节点的引用、特别是对CDN间清单文件中列出的递送节点的引用的至少部分需要被更新(步骤1310)。
[0157]因而，当从第二⑶NCF接收到网络通知时，第一⑶NCF触发DCMF基于存储在与第一⑶N A相关联的DC数据库中的清单文件信息而检查已经向哪些客户端发送包含对第二递送节点DN2的引用的CDN间清单文件(步骤1311)。DCMF然后可以确定哪些客户端重定向并且触发CCSF经由需要被重定向的客户端的控制信道发送清单更新触发(步骤1312)。当接收到清单更新触发时，客户端将通过向第一 CDNCF发送清单文件请求(类似于步骤1301)来请求第一清单文件(步骤1313)。
[0158]第一 CDNCF接收清单请求并且将以如上文参照步骤1302描述的类似的方式与第二 CDNCF协作生成适于客户端的新的或更新的清单文件(步骤1314)。例如，在一个实施例中，第二⑶NCF可以用去往主控相同段的另一个递送节点(例如第四递送节点DN4)的URL取代引用第二 CDN中的(几乎)过载的递送节点(在这种情况中，第二递送节点)的URL，并且向第一⑶NCF发送这些引用。引用第一⑶N A中的递送节点DNl的URL不被取代，因为对于该递送节点，第一 CDNCF没有接收到过载信令。
[0159]第一⑶NCF可以向客户端发送更新的⑶N间清单文件(步骤1315)，其可以基于更新的清单文件而更新它内部的段列表并且通过请求来自新的清单中列出的URL的后续段来继续流式传输。
[0160]由于客户端已经接收到新的或更新的清单文件，第一⑶NCF可以通过执行如参照1304描述的步骤来更新DC数据库中的与该客户端相关联的清单文件信息。另外，第二CDNCF可以以如参照步骤1305描述的类似方式更新与第二 CDN B相关联的DC数据库中的包括下游CDN中的递送节点(在该示例中，第四递送节点DN4)连同对上游CDN (在这种情况中，第一⑶NCF)的引用的⑶N间信息。这样，如果在未来的某个点处出现⑶N B中的过载问题，第二⑶NCF可能能够将客户端再次重定向到另一个递送节点。
[0161]因而，图13中描绘的实施例提供了以下优势:允许分段内容分布在多个CDN上，其中每个CDN仅主控所有段的子集。该实施例提供了如参照图11论述的相同类型的优势，然而在该情况中不同的递送节点可以分布在多个CDN上。这样的另外一个优势是其允许上游⑶N将一些工作负载外包给另一个下游⑶N。该实施例还允许使用专用⑶N。例如，在一个实施例中，第一 CDN可以被配置和优化用于到移动设备的递送、主控大多数较低质量的段，而第二 CDN可以被配置和优化用于到HD播出设备的递送、主控大多数较高质量的段。
[0162]在上文描述的CDN实施例中主张，代替向通过请求更新的或新的清单文件而进行响应的客户端发送更新清单触发，新的或更新的清单文件(的部分)可以经由到客户端的流式传输控制信道直接发送到客户端。
[0163]图14描绘了根据本发明的一个实施例的清单文件。具体地，图14示出了包括对被配置成递送段的特定集合的递送节点的引用(例如URL)的清单文件的实施例。在该特定示例中，清单文件可以包括对段的两个不同集合的引用，例如低和高比特率段，其与存储在递送节点处的相同内容有关。清单文件还可以包括信道建立信息。在一个实施例中，信道建立信息可以包括提供对包括流式传输控制功能(或在CDN情况中，控制信道服务器功能)的网络节点的引用的信道目标参数1400。另外，在另一个实施例中，信道建立信息可以包括信道参数1402，即由流式传输控制功能/控制信道服务器功能使用的参数。例如，在WebSocket的情况中，参数可以指WebSocket子协议的使用、WebSocket版本等。
[0164]应该理解的是，与任何一个实施例有关地描述的任何特征可以单独使用，或与所描述的其它特征组合，并且还可以使用在与任何其它实施例的一个或多个特征的组合或任何其它实施例的任何组合中。本发明的一个实施例可以实现为用于与计算机系统一起使用的程序产品。程序产品的一个或多个程序定义实施例(包括本文所描述的方法)的功能，并且可以包含在各种计算机可读存储介质上。说明性计算机可读存储介质包括但不限于:(i )其上永久存储信息的非可写存储介质(例如计算机内的只读存储器设备，诸如CD-ROM驱动器可读的CD-ROM盘，闪速存储器、ROM芯片或任何类型的固态非易失性半导体存储器)；以及(ii )其上存储可变信息的可写存储介质(例如磁盒驱动器内的软盘或硬盘驱动器或任何类型的固态随机存取半导体存储器)。本发明不限于以上描述的实施例，其可以在随附权利要求的范围内变化。
【权利要求】
1.用于实现对分段内容从递送节点到至少一个客户端的流式传输的网络发起的控制的方法，所述方法包括: 接收第一清单文件，其包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述至少一个客户端发送与所述一个或多个标识符相关联的一个或多个段； 向客户端提供信道建立信息；以及， 优选地响应于在客户端处接收所述第一清单文件，基于所述提供的信道建立信息，在所述至少一个客户端和与所述递送节点相关联的控制信道服务器功能之间建立至少一个流式传输控制信道，所述至少一个客户端被配置用于经由所述流式传输控制信道接收至少一个清单文件更新消息。
2.根据权利要求1的方法，包括: 针对至少一个清单文件更新消息而监视所述流式传输控制信道。
3.根据权利要求1或2的方法，包括: 检测清单文件更新消息； 响应于检测到所述清单文件更新消息而获取第二清单文件的至少部分；以及，可选地， 基于所述第二清单文件而请求段流或文件。
4.根据权利要求1-3中任一项的方法，其中所述信道建立信息的至少部分被提供给所述第一清单文件中的所述客户端，优选地，所述信道建立信息包括用于定位网络中的所述控制信道服务器功能的服务器位置信息，优选为至少一个URL。
5.根据权利要求1-4中任一项的方法，其中所述清单文件更新消息包括第二清单文件的至少部分或者其中所述清单文件更新消息包括用于定位和请求所述第二清单文件的至少部分的清单文件位置信息，优选为至少一个URL。
6.根据权利要求1-5中任一项的方法,其中所述分段内容基于流式传输协议、优选为基于HTTP的流式传输协议或其派生物而被递送到所述至少一个客户端；和/或，其中所述流式传输控制信道基于WebSocket协议、SIP协议、XMPP协议和/或其组合而被建立。
7.用于实现对分段内容从递送节点到至少一个客户端的流式传输的网络发起的控制的方法，所述方法包括: 递送清单文件，其包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向至少一个客户端向所述至少一个客户端发送与所述一个或多个标识符相关联的一个或多个段； 接收对于在与所述一个或多个内容递送节点相关联的控制信道服务器功能和所述至少一个客户端之间建立流式传输控制信道的请求；以及， 建立所述至少一个流式传输控制信道，其中所述控制信道服务器功能被配置成向所述客户端发送至少一个清单文件更新消息。
8.根据权利要求7的方法，其中所述一个或多个递送节点的至少第一部分被配置为与第一内容递送网络(CDNl)相关联的第一递送节点，所述第一内容递送网络被配置成向所述客户端递送所述段的至少第一部分；和/或，所述递送节点的至少第二部分被配置为与第二内容递送网络(CDN2)相关联的第二递送节点，所述第二内容递送网络被配置成向所述客户端递送所述段的至少第二部分。
9.根据权利要求7或8的方法，包括: 监视一个或多个网络参数，优选为与关联于所述一个或多个递送节点的过载、即将发生的过载、故障或网络配置改变相关联的所述一个或多个网络参数中的至少一个； 在与所述网络参数相关联的一个或多个预定条件满足的情况下，生成清单文件更新消息；以及， 向所述至少一个客户端发送所述清单文件更新消息。
10.根据权利要求8或9的方法，包括: 确定与所述第一和/或第二递送节点中的一个或多个相关联的过载、即将发生的过载、故障或网络配置改变； 识别从与所述确定的过载、即将发生的过载、故障或网络配置改变相关联的所述一个或多个第一和/或第二递送节点获取或预期获取至少一个段的一个或多个客户端； 确定与所述识别出的客户端的至少部分相关联的一个或多个流式传输控制信道；以及， 通过所述一个或多个流式传输控制信道向所述识别出的客户端的至少部分发送清单文件更新消息。
11.根据权利要求10的方法，其中所述过载、即将发生的过载、故障或网络配置改变的所述至少部分与属于第二 CDN2的所述第二递送节点的至少一个相关联，所述方法包括: 所述第二 CDN2向所述第一 CDNl发送过载、故障或网络配置改变通知，所述通知包括与所述过载、故障或网络配置改变相关联的一个或多个第二递送节点标识符。
12.一种用于使用在用于控制对从至少一个递送节点发送的分段内容的接收的内容处理设备中的客户端，所述第一递送节点与第一控制信道服务器功能相关联，所述客户端被配置用于: 向所述至少一个递送节点发送对于递送分段内容的请求； 接收清单文件，其包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述至少一个客户端发送与所述段标识符相关联的一个或多个段； 被提供有信道建立信息；以及， 基于所述第一信道建立信息而在所述至少一个客户端与所述第一控制信道服务器功能之间建立流式传输控制信道，所述至少一个客户端被配置用于从所述第一控制信道服务器功能接收至少一个清单文件更新消息。
13.与用于实现对分段内容从所述递送节点到一个或多个客户端的流式传输的网络发起的控制的至少一个递送节点相关联的控制信道服务器功能，所述控制信道服务器功能被配置用于: 接收对于将分段内容递送到所述一个或多个客户端的至少一个请求； 生成至少清单文件，其包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息以及信道建立信息，所述一个或多个内容递送节点被配置成向所述一个或多个客户端发送与所述段标识符相关联的一个或多个段； 向所述一个或多个客户端中的至少一个发送所述第一清单文件；以及， 参与在所述至少一个客户端与所述控制信道服务器功能之间的至少第一流式传输控制信道的建立，所述建立基于所述信道建立信息；以及，可选地，所述控制信道服务器功能还被配置用于生成清单文件更新消息和/或用于经由所述第一流式传输控制信道向所述客户端发送所述消息。
14.根据权利要求13的控制信道服务器功能，其中生成所述至少一个清单文件包括: 提供一个或多个第一段标识符和用于定位第一内容递送网络(⑶NI)中的一个或多个内容递送节点的第一位置信息； 向第二内容递送网络请求一个或多个第二段标识符和用于定位所述第二内容递送网络(CDN2)中的一个或多个内容递送节点的第二位置信息； 分别基于所述一个或多个第一和第二段标识符以及第一和第二位置信息的至少部分而生成所述清单文件。
15.一种数据结构，优选为清单文件的至少部分，用于实现对分段内容的流式传输的网络发起的控制，所述数据结构包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述客户端发送与所述一个或多个段标识符相关联的一个或多个段；所述数据结构还包括所述信道建立信息的至少部分，优选地所述信道建立信息包括与包括控制信道服务器功能的网络节点相关联的位置信息，优选为一个或多个URL，所述控制信道服务器功能被配置成发起建立与所述客户端的流式传输控制信道的过程。
16.一种包括软件代码部分的计算机程序产品，所述软件代码部分被配置用于当运行在计算机的存储器中时，执行根据权利要求1-11中的任一项的方法步骤。
【文档编号】H04L29/06GK104137505SQ201280070832
【公开日】2014年11月5日 申请日期:2012年12月27日 优先权日:2011年12月29日
【发明者】R.范布兰登伯格, O.A.尼亚穆特, M.O.范德文特 申请人:皇家Kpn公司, 荷兰应用自然科学研究组织
【专利摘要】描述了用于实现对分段内容从递送节点到至少一个客户端的流式传输的网络发起的控制的方法和系统，所述客户端被配置成基于清单文件而访问所述分段内容的至少部分，其中方法可以包括：接收第一清单文件，其标识一个或多个段和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述至少一个客户端发送所述一个或多个段；响应于所述第一清单文件的所述接收，提供信道建立信息；以及基于所述控制信道建立信息而在所述至少一个客户端和与所述内容递送节点相关联的控制信道服务器功能之间建立至少一个流式传输控制信道，所述至少一个客户端被配置用于经由所述流式传输控制信道接收至少一个清单文件更新消息。
【专利说明】网络发起的内容流式传输控制
【技术领域】
[0001]本发明涉及控制内容的流式传输(streaming)，并且特别地，尽管并不排他地，涉及用于实现对分段内容的流式传输的网络发起的控制的方法，用于在用于控制分段内容的接收的内容处理设备中使用的客户端，用于实现对分段内容的流式传输的网络发起的控制的控制信道服务器功能和数据结构和使用这样的方法的计算机程序产品。
【背景技术】
[0002]目前数目日益增加的视频流式传输技术利用所谓的内容分段，其中内容数据(例如视频数据)被逻辑地或虚拟地拆分成多个段文件(segment file)或流，因此生成分段的内容。段文件可以涉及包括内容数据的文件，其可以通过文件获取协议(例如HTTP或FTP)来获取。类似地，段流可以涉及包括内容数据的流，其可以通过流式传输协议(例如RTSP/RTP或HAS)来获取。段文件或流(以下简短地也称作为段)可以单独地递送到客户端，但是当在客户端处重组时，它们提供无缝的视频流。
[0003]在内容分段过程期间，生成所谓的清单(manifest)文件，其标识段并且描述不同段与其中可以获取段的一个或多个位置之间的关系。可以以若干表示提供分段内容，例如在例如分辨率、音频通道的数目和/或不同的比特率方面不同的相同内容的替换版本。所有表示在时间上对准，使得不同表示的段可以无缝地互换。以不同表示的分段内容的流式传输称作为自适应流，其中可以使用诸如HTTP自适应流(HAS)和有关协议之类的自适应流协议。
[0004]HAS通过传输由来自web (网络)服务器的客户端独立请求的分段的视频来实现借助于HTTP协议的(实时)视频的递送。存在各种商用和标准化的HAS协议，诸如Apple HTTPLive Streaming (实时流式传输)http://tools.1etf.0rg/html/draft-pantos_http-live-streaming-07、Microsoft Smooth Streaming (平滑流式传输)http://www.1is.net/download/ SmoothStreaming、Adobe HTTP Dynamic Streaming (动态流式传输)http://www.adobe, com/products/ httpdynamicstreaming、3GPP-DASH TS 26.247 Transparentend-to-end Packet-switched Streaming Service (PSS)(透明端到端分组交换流式传输服务(PSS)) ；Progressive Download and Dynamic Adaptive Streaming over HTTP](渐进式下载和通过HTTP的动态自适应流)和MPEG Dynamic Adaptive Streaming over HTTP(MPEG 通过 HTTP 的动态自适应流)MPEG DASH IS0/IEC 23001-6。
[0005]分段内容可以被用于动态地适配于改变的带宽要求，例如通过从高质量视频流切换到低质量视频流。而且，分段内容还可以允许流行和不太流行的(视频)段之间的区分。例如，典型地，与视频的开头相关联的内容(诸如预告片)将比结束处的内容更常被观看(并且因此更流行)。类似地，对于一些使用情况，低比特率低质量的视频内容(例如最低分辨率HAS段)将很可能比高质量内容(例如高分辨率HAS段)更频繁地被下载，高质量内容可以从接收设备花费或要求得更多或需要更多带宽。以上提到的分段内容的属性可以被内容递送网络(content delivery network,⑶N)有利地使用，其可以被配置成将内容递送给消费者。CDN可以例如将流行的、更频繁请求的内容段存储在CDN中的多个递送节点处，使得可以减少带宽问题并且保证高效的递送。⑶N控制功能(⑶NCF)可以集中地管理⑶N内的位置，以下称作为递送节点，其中可以获取(得到)与内容项(诸如视频或电影)相关联的内容段。
[0006]尽管许多不同的流式传输协议(诸如RTP/RTSP或RTMP)可以被用于实现将(分段)内容流式传输到客户端，但是HTTP或基于HTTP的流式传输协议在CDN内最广泛地使用。这些流式传输协议使用标准HTTP (无缝的客户端-服务器协议)以请求和接收来自不需要新的功能并且允许段被透明地高速缓存的服务器的内容段。而且，不像是大多数其它的流式传输解决方案，HTTP业务本身通常不会被防火墙或网络地址翻译器(NAT)自动阻挡。
[0007]而且，基于HTTP的流式传输不是基于会话的。这意味着HTTP服务器不需要为它服务的各种客户端维持会话。这样HTTP服务器架构可以保持简单。然而，与HTTP是客户端发起的协议这一事实结合的这种无会话的性质还意味着HTTP服务器(例如CDN中的递送节点)不能够发起与客户端的通信。
[0008]为了使得客户端能够访问(下载/获取)存储在CDN中的段，客户端被提供有包括均被段标识符(例如段文件名)和段位置(段定位符)标识的段的列表的所谓的清单文件，所述段位置例如是URL，其指向其中可以访问(获取)段的网络节点。取决于特定⑶N和/或实现方式，预定义的清单文件可以连同相关联的段一起存储在CDN的一个或多个(递送)节点上，或者清单文件可以在用户请求时由CDN动态生成。
[0009]这样，当消费者(客户端设备)请求特定分段内容项(诸如视频)时，CDN可以应请求而识别存储(递送)节点上的清单文件，所述(递送)节点适于实现请求的内容项到消费者(设备)的递送。可替换地，CDN可以生成标识一个或多个递送节点的新的清单文件，所述一个或多个递送节点合起来适于将请求的内容段递送给消费者。随后，CDN可以响应于消费者的请求客户端(设备)而发送所生成的清单文件。
[0010]在内容段的流式传输期间，⑶N中的网络配置或负载分布可以改变。例如，⑶N的节点中的故障或过载可以导致其中CDN中的一个或多个递送节点不再能够递送在清单文件中标识出的内容段的情形。同样在其它情形中，例如在即将发生过载情形中，可能需要通过将在流式传输过程期间将特定内容段递送给特定消费者(内容接收设备)的任务从一个递送节点转移到CDN的另一个递送节点或甚至转移到另一个CDN中的递送节点来防止过载情形。一方甚至可以想象到，当特定消费者的客户端设备改变其位置时，使现在作为更加接近的节点的另一个递送节点从原始节点接管流式传输还可以是更加有利的。可能需要或许可将段递送到客户端中的改变的递送网络中的其它事件(即触发网络中的负载平衡机制)是计划停机、服务器迁移、CDN迁移等等。
[0011]在已知方法中，段到客户端的递送中的这样的改变可以以若干方式实现。在一些情况中⑶N可以使用例如HTTP重定向方案，以便将针对段的请求重定向到期望的递送节点。然而，这样的方案可能需要并触发针对客户端未来将请求的每个段的单独的重定向响应消息(简单地称作为重定向)，或甚至每个请求的段多个重定向响应消息，从而引起网络中信令负载的显著增加。这在当大量消费者依赖于相同递送节点并且同时请求和获取相同内容时的情况中尤为相关。不仅附加信令负载可能淹没CDN的部分或全部，而且重定向可能导致在客户端侧的不可接受的服务中断，这是因为单独的内容段的递送由于重定向而突然被延迟。因此重定向方案可能不能够有效地防止由于网络配置中的改变(由于例如递送节点故障)所致的服务中断。在其中例如在客户端设备处几乎不缓存内容的情形中，在发生多个重定向的情形中，或者在新的目标递送节点相比于先前的一个而位于距离客户端设备相当大的距离处的情形中，服务中断可能更明显。
[0012]可替换地，⑶N可以基于新的网络配置而生成用于客户端的新近更新的清单文件。然而，由于其本身性质，HTTP协议不允许服务器侧(例如CDN)直接和或主动发起这样的新近更新的清单文件到客户端的传输，或者可替换地，发起针对这样的新近更新的清单文件的客户端请求。客户端是否接收更新的清单文件完全取决于请求这样的更新的客户端(然而其不知道网络配置中的(未决的)改变)的发起。同样地，如果例如⑶N将会以比存在于先前提供到客户端的清单文件中的更高的表示使得分段内容流可用，客户端没有办法得知这一点并且不能够从这样的更高质量流获益。即便客户端将会被配置成例如周期性地请求清单文件更新，这样的更新方案也不能有效地(快速地)特别地对网络配置中的改变进行反应并且避免由于这样的改变所致的服务中断。如果这样的更新频率将会与突然需要的配置改变精确一致，这将仅仅是巧合的。另外，实现非常高的更新频率(其利用基于HTTP的请求-响应信令机制)，具有以下缺陷:其导致相当大的网络中的开销信令负载以及客户端和网络节点上的处理器负载，甚至在没有配置改变(例如分段内容到客户端的递送中的改变)被需要或可推荐的时段期间亦是如此。
[0013]因此，在本领域中存在对实现对将内容流式传输到客户端的改进的控制的方法和系统的需要。
【发明内容】
[0014]本发明的目的是减少或消除现有技术中已知的缺陷中的至少一个。在第一方面中本发明可以涉及用于实现对分段内容从递送节点到至少一个客户端(优选为诸如MPEGDASH兼容自适应流客户端之类的HTTP自适应流(HAS)客户端)的流式传输的网络发起的控制的方法。该方法可以包括以下步骤中的至少一个:接收第一清单文件，优选地，所述清单文件包括用于标识一个或多个段的一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述至少一个客户端发送与所述段标识符相关联的一个或多个段；向客户端提供信道建立信息；和/或，基于所述提供的信道建立信息，在所述至少一个客户端与网络(优选为与所述一个或多个递送节点中的至少一个相关联的控制信道服务器功能)之间建立至少一个流式传输控制信道。在实施例中，步骤可以由客户端执行。在另一个实施例中，所述至少一个客户端可以被配置用于经由所述流式传输控制信道接收至少一个清单文件更新消息。可替换地，除了指示清单文件更新的可用性的更新消息之外，控制信道可以被网络(例如控制信道服务器功能)用于传送与段内容的流式传输相关联的服务器或网络侧事件的消息。这样的事件可以涉及不能通过清单文件更新传送或者对于其而言将这些传送到与清单文件更新分离的客户端可能更恰当(例如更快)的信息(例如参数)。在这样的实施例中，客户端可以可替换地被配置用于接收和/或处理这些其它事件消息。在另一个实施例中，所述至少一个客户端可以被配置成基于清单文件而访问所述分段内容的至少部分。在另外的实施例中，通过客户端对清单文件的接收可以触发客户端建立与网络的流式传输控制信道，优选地基于所提供的信道建立信息，其中流式传输控制信道使得网络(例如CDN)能够主动为客户端提供清单文件更新消息，其指示清单文件更新的可用性。清单文件更新消息可以通过控制信道被主动发送到客户端而无需客户端首先向网络发送(HTTP)请求。这样，在客户端上执行的流式传输过程可以对网络配置中的改变和/或网络问题(例如突出的过载情形或网络故障)迅速做出反应，由此现在使得网络能够抢先发信号告知客户端。通过实现控制信道，可以缓解和/或克服现有技术类型分段流式传输解决方案所基于的已知(HTTP)请求-响应机制的限制和缺点，其中的一些在背景章节中进行了完全透彻的论述。
[0015]在实施例中，该方法可以包括针对至少一个清单文件更新消息而监视所述流式传输控制信道。在该实施例中，客户端可以连续地针对来自网络的更新消息而监视信道，使得保证通过客户端对这样的更新消息的迅速响应。该监视过程可以例如作为流式传输过程期间的后台过程执行。
[0016]在实施例中，该方法可以包括以下步骤中的至少一个:检测清单文件更新消息；以及，可选地，响应于所述清单文件更新消息获取第二清单文件的至少部分。在另一个实施例中，该方法还可以包括:基于所述第二清单文件而请求段流或文件。因而，由客户端从网络接收的清单文件更新消息可以发信号通知客户端更新的清单文件被需要和/或可用，并且流式传输过程应当或可以基于该更新的清单文件而继续。这里，清单文件中的更新可以由于网络配置中的改变和/或诸如网络故障或网络过载之类的网络问题而被需要。这样，网络可以响应于网络中的某个事件高效和主动地发起对流式传输过程的控制。在现有技术的基于HTTP的分段流式传输解决方案中，其按照定义是需要从客户端首先发起的基于HTTP的请求和响应机制，对流式传输过程的这样的主动网络发起的控制简直是不可能的。
[0017]在实施例中，可以将所述信道建立信息的所述至少部分提供给所述第一清单文件中的所述客户端，可替换地，可以将其在单独的消息中提供给客户端。在另外的实施例中，所述信道建立信息的所述提供包括用所述信道建立信息对客户端进行预配置。在一个实施例中，所述信道建立信息可以包括用于定位网络中的控制信道服务器功能的服务器位置信息，优选为至少一个URL。因而，清单文件可以包括建立控制信道所需的信息的至少部分。
[0018]在实施例中，所述清单文件更新消息的所述至少部分可以包括第二清单文件的至少部分。在该实施例中，流式传输控制信道可以被用于传输清单文件中的更新的部分。在另一个实施例中，所述清单文件更新消息可以包括用于定位和请求所述第二清单文件的至少部分的清单文件位置信息，优选为至少一个URL。这样，网络可以以简单且高效的方式告知客户端哪里可以获取更新的清单文件(或其部分)。
[0019]在一个实施例中，所述流式传输控制信道可以基于WebSocket协议而建立。在实施例中，内容递送网络(CDN)实体、优选为控制信道服务器功能，和客户端可以包括被配置成使用WebSocket协议和信道建立信息来在客户端与所述CDN实体之间建立流式传输控制信道的HTTP WebSocket API。WebSocket连接通常使用标准HTTP端口 80和443，使得数据可以容易地穿过防火墙和NAT，但是还可以使用其它端口。另外，协议提供可缩放的解决方案，因为它具有低消息开销。而且，WebSocket是基于HTTP的，使得可以消除或至少大体上减少与穿过防火墙相关联的问题。而且，它提供了其它协议的隧道传输(tunneling)的可能性。
[0020]在实施例中，基于流式传输协议、优选为基于HTTP的流式传输协议或其派生物将所述分段内容的所述至少部分递送到所述至少一个客户端。在另一个实施例中，可以使用SIP协议、XMPP协议和/或其组合来建立流式传输控制信道。
[0021]在另一个方面中，本发明可以涉及用于实现对分段内容从递送节点到至少一个客户端的流式传输的网络发起的控制的方法，其中所述方法可以包括以下步骤中的至少一个:递送清单文件，所述清单文件包括用于标识一个或多个段的一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向至少一个客户端发送与所述段标识符相关联的一个或多个段；接收对于在与所述一个或多个内容递送节点相关联的控制信道服务器功能和所述至少一个客户端之间建立流式传输控制信道的请求；和/或，建立所述至少一个流式传输控制信道。在一个实施例中，所述控制信道服务器功能可以被配置成向所述客户端发送至少一个清单文件更新消息。在另一个实施例中，所述客户端可以被配置成基于清单文件而访问所述分段内容的至少部分。在另一个实施例中，清单文件可以包括一个或多个段标识符和/或用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述至少一个客户端发送与所述一个或多个段标识符相关联的一个或多个段。
[0022]在实施例中，所述一个或多个递送节点的所述至少第一部分的所述至少部分可以被配置为属于第一内容递送网络(⑶NI)的第一递送节点，所述第一内容递送网络(⑶NI)被配置成向所述客户端递送所述段的至少第一部分；和/或，所述递送节点的至少第二部分可以被配置为属于第二内容递送网络(CDN2)的第二递送节点，所述第二内容递送网络(⑶N2)被配置成向所述客户端递送所述段的至少第二部分。因而，在该实施例中，由第二、另外的⑶N向客户端递送段的至少部分。
[0023]在实施例中，所述方法可以包括:监视一个或多个网络参数，优选为与关联于所述一个或多个递送节点的过载、即将发生的过载、故障或网络配置改变相关联的所述一个或多个网络参数中的至少一个；在满足与所述网络参数相关联的一个或多个预定条件的情况下，生成清单文件更新消息；以及，可选地，向所述至少一个客户端发送所述清单文件更新消息。
[0024]在实施例中，所述方法可以包括:确定与所述第一和/或第二递送节点中的一个或多个相关联的过载、即将发生的过载、故障或网络配置中的改变；识别从与确定的过载、即将发生的过载、故障或网络配置改变相关联的所述一个或多个第一和/或第二递送节点获取或预期获取段的一个或多个客户端；确定与所述识别出的客户端的至少部分相关联的一个或多个流式传输控制信道；以及，可选地，通过所述一个或多个流式传输控制信道向所述识别出的客户端的至少部分发送清单文件更新消息。
[0025]在实施例中，所述过载、故障或网络配置改变的所述至少部分可以与属于第二CDN2的所述第二递送节点的至少一个相关联。在另一个实施例中，所述方法可以包括:所述第二⑶N2向所述第一⑶NI发送过载通知、故障通知或网络配置改变通知，所述过载或故障通知包括与所述过载或故障相关联的一个或多个第二递送节点标识符。
[0026]在实施例中，所述方法可以包括:将客户端递送信息存储在第一⑶N数据库中，所述客户端递送信息包括以下中的至少一个:流式传输控制信道标识符；客户端标识符，优选为与所述客户端相关联的IP地址；与主控在所述清单文件中引用的一个或多个段的递送节点相关联的递送节点标识符；内容递送网络标识符；和/或，清单文件标识符。
[0027]在又一方面中，本发明可以涉及用于实现对与至少第一和第二内容递送网络(CDN1、CDN2)相关联的分段内容到一个或多个客户端的流式传输的网络发起的控制的方法，所述第一⑶NI与第一控制信道服务器功能相关联并且所述第二⑶N2与第二控制信道服务器功能相关联，其中所述方法可以包括以下步骤中的至少一个:生成与分段内容相关联的第一清单文件，所述第一清单文件包括一个或多个段和用于定位与所述第一 CDNl相关联的一个或多个内容递送节点的位置信息；和/或，向所述第二控制信道服务器功能请求与所述分段内容相关联的第二清单文件，其中所述第二清单文件可以包括一个或多个段和/或用于定位与所述第二 CDN2相关联的一个或多个内容递送节点的位置信息；基于所述第一和第二清单文件以及可选地信道建立信息而生成另外的清单文件；基于所述信道建立信息而在所述至少一个客户端与所述第一控制信道服务器功能之间建立至少第一流式传输控制信道，其中所述第一控制信道服务器功能可以被配置成生成清单文件更新消息并且经由所述流式传输控制信道向所述客户端发送所述消息。
[0028]在另外的方面中，本发明可以涉及用于在内容处理设备中使用的客户端，其中所述客户端可以被配置用于:向所述服务器发送对于递送分段内容的请求；接收清单文件，所述清单文件包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述至少一个客户端发送与所述一个或多个段标识符相关联的一个或多个段；被提供有第一信道建立信息；和/或，基于所述提供的第一信道建立信息而在所述至少一个客户端和与所述第一⑶NI相关联的所述控制信道服务器功能之间建立第一流式传输控制信道。在一个实施例中，所述至少一个客户端被配置用于从所述第一控制信道服务器功能接收至少一个清单文件更新消息。
[0029]在一方面中，本发明可以涉及与递送节点相关联的用于实现分段内容从所述递送节点到一个或多个客户端的网络发起的受控传输的控制信道服务器功能，其中所述控制信道服务器功能可以被配置用于以下步骤中的至少一个:接收对于将分段内容递送到所述一个或多个客户端的至少一个请求；生成至少一个清单文件，其包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息以及可选地信道建立信息，所述一个或多个内容递送节点被配置成向所述客户端发送与所述一个或多个段标识符相关联的一个或多个段；向所述客户端发送所述至少一个清单文件；以及，参与基于所述信道建立信息的在所述至少一个客户端与所述控制信道服务器功能之间的至少第一流式传输控制信道的设立或建立。在一个实施例中，所述控制信道服务器功能还可以被配置成生成清单文件更新消息并且经由所述第一流式传输控制信道向所述客户端发送所述消息。
[0030]在一个实施例中，所述生成所述至少一个清单文件可以包括:
提供一个或多个第一段标识符和用于定位第一内容递送网络(⑶NI)中的一个或多个内容递送节点的第一位置信息；向第二内容递送网络请求一个或多个第二段标识符和用于定位所述第二内容递送网络(CDN2)中的一个或多个内容递送节点的第二位置信息；分别基于所述一个或多个第一和第二段标识符以及第一和第二位置信息的至少部分而生成所述清单文件。
[0031 ] 在另一个实施例中，所述控制信道服务器功能还可以被配置成:从所述第二内容递送网络接收过载通知；以及，响应于所述过载通知经由所述第一流式传输控制信道向所述客户端发送清单文件更新消息。
[0032]在另外的方面中，本发明可以涉及用于在如上文所描述的客户端中使用的数据结构，优选为清单文件，其中所述数据结构可以包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述客户端发送与所述一个或多个段相关联的一个或多个段；所述数据结构还包括所述信道建立信息的至少部分。在一个实施例中，所述信道建立信息可以包括与包括控制信道服务器功能的网络节点相关联的位置信息，优选为一个或多个URL，所述控制信道服务器功能被配置用于与所述客户端建立流式传输控制信道。
[0033]本发明还涉及包括软件代码部分的计算机程序产品，所述软件代码部分被配置用于当运行在计算机的存储器中时，执行根据如上文所描述的方法步骤中的任一个的方法步骤。
[0034]将参照附图进一步图示本发明，所述附图将示意性地示出根据本发明的实施例。将理解，本发明不以任何方式被限制到这些特定实施例。
【专利附图】
【附图说明】
[0035]图1描绘了客户端与服务器之间的传统HAS会话的概览。
[0036]图2描绘了根据本发明的一个实施例的客户端与服务器之间的协议流。
[0037]图3描绘了根据本发明的实施例的客户端侧过程流。
[0038]图4描绘了根据本发明的实施例的服务器侧过程流。
[0039]图5A-5C描绘了根据本发明的各种实施例的客户端与服务器之间的协议流。
[0040]图6描绘了根据本发明的实施例的内容流式传输系统。
[0041]图7描绘了用于在根据本发明的实施例的内容流式传输系统中使用的消息流。
[0042]图8描绘了与根据本发明的一个实施例的递送连续性节点(DCN)功能相关联的过程流。
[0043]图9描绘了用于在根据本发明的另一个实施例的内容流式传输系统中使用的消息流。
[0044]图10描绘了用于在根据本发明的又一实施例的内容流式传输系统中使用的消息流。
[0045]图11描绘了用于在根据本发明的另外的实施例的内容流式传输系统中使用的消息流。
[0046]图12描绘了根据本发明的实施例的内容流式传输系统。
[0047]图13描绘了用于在根据本发明的再一实施例的内容流式传输系统中使用的消息流。
[0048]图14描绘了根据本发明的一个实施例的清单文件。
【具体实施方式】
[0049]图1描绘了被配置成通过诸如HAS流式传输协议之类的流式传输协议进行通信的终端中的客户端130与媒体服务器132之间的传统HAS协议流的概览，其包括响应和请求协议消息134、136。这里，终端可以一般地涉及内容处理设备，例如(移动)内容播出设备，诸如电子平板、智能电话、笔记本、媒体播放器等。在一些实施例中，终端可以是机顶盒或内容存储设备，其被配置用于处理和临时存储内容以供内容播出设备未来消费。类似地，媒体服务器可以是内容提供商或内容递送网络(CDN)的部分或者与其相关联。
[0050]协议流可以开始于用户选择去往网站上的视频的链接(步骤102)，其中URL可以(例如通过重定向)指向清单文件。清单文件可以与特定数据结构有关，所述特定数据结构包括构建分段视频文件的段标识符(例如段文件名)和用于定位一个或多个网络节点的关联的位置信息(例如URL)，所述一个或多个网络节点被配置成向客户端(递送节点)递送段；或者可替换地，与能够确定其可能能够递送标识的段的一个或多个网络节点的网络节点有关。在又一实施例中，位置信息还可以指向网络节点上的位置。例如，URL关联的段可以指向在一个递送节点中定义的不同文件夹。
[0051]对优选包括在清单文件中的段的引用(reference)可以包括段标识符和/或用于定位段的与段标识符相关联的位置信息。
[0052]清单文件还可以包括描述段之间的时间和/或空间关系的信息。这样的文件可以使用特定文件扩展名存储和标识，例如.mf、.xml和.m3u8。客户端然后可以发送HTTP获取(GET)请求以从服务器获得清单文件(步骤104)。作为响应，服务器可以通过向客户端发送清单文件而进行响应(步骤106)。客户端此后解析清单文件以获得与请求的视频相关联的段的位置(步骤108)。
[0053]客户端请求来自在清单文件中描述的位置的视频的第一段并且服务器通过向客户端发送所请求的段来对请求进行响应(步骤110、112)。基于清单文件，可以获取若干段(步骤114、116)。然后，在某个时间量之后，客户端可以确定(例如基于预定义的定时器到期，或者客户端几乎达到实时流中的清单文件的结束)是时候更新清单文件并且可以向它已经从其获得初始清单的相同位置发送请求(步骤118)。更新的清单文件此后被发送到客户端(步骤120)，其再次被客户端通过开始解析经更新的清单文件而被处理(步骤122)。
[0054]如早前已经论述的，这样的传统HAS内容流式传输系统不允许对客户端与服务器之间的流式传输过程的基于服务器的控制。它不允许在难以预测并且其中需要流式传输配置的直接适配的特别情形中的控制。
[0055]图2描绘了根据本发明的一个实施例的客户端与服务器之间的协议流。具体地，图2描绘了与用于将来自媒体服务器232的内容流式传输到客户端230的诸如HTTP自适应流(HAS)协议之类的流式传输协议相关联的协议流。
[0056]客户端可以包括流式传输客户端功能248，其处理用于通过视频播出功能246播出的流，以及控制信道客户端功能244 (CCCF)0类似地，媒体服务器可以包括用于将媒体流式传输到流式传输客户端功能248的流式传输服务器功能242。媒体服务器还可以包括在服务器232中或与服务器232相关联的控制信道服务器功能(CCSF)，例如HAS控制信道服务器功能234，所述服务器232被配置成发起CCSF与CCCF 244之间的流式传输控制信道236的建立，其中流式传输控制信道可以被用于在分段内容238到客户端的流式传输期间在客户端与服务器之间交换流式传输控制信息，特别是，源自服务器的到客户端的流式传输控制信息。
[0057]这里，过程可以以如图1中的相同方式开始，即用户点击去往网站上的视频的链接，其中URL可以(例如通过重定向)指向清单文件(步骤200 )。客户端可以发送HTTP获取请求以从服务器获得清单文件并且服务器可以通过向客户端发送清单文件(在该情况中，XML文件)来对其进行响应(步骤202、204)，客户端随后解析清单文件以获得组成请求的内容流的段的位置(步骤206)。然而在该特定情况中，服务器中的CCSF被配置成将信道建立信息插入在清单文件中，这允许客户端中的CCCF和服务器中的CCSF建立流式传输控制信道。
[0058]基于嵌入在清单文件中的信道建立信息，客户端中的CCCF可以例如向服务器中的CCSF发送信道建立请求(步骤208)以用于建立服务器到客户端流式传输控制信道。在一个实施例中，CCCF和CCSF可以包括被配置成使用WebSocket协议和信道建立信息来建立客户端与服务器之间的流式传输控制信道的HTTP WebSocket API。WebSocket连接通常使用标准HTTP端口 80和443，使得数据可以容易地传递防火墙和NAT，但是还可以使用其它端口。
[0059]WebSocket协议的使用在⑶N和HAS的上下文内具有若干优势，诸如用于可缩放性的低消息开销，用于协议汇聚和防火墙的穿过的HTTP的使用，以及其它协议的隧道传输的可能性。在另一个实施例中，使用会话发起协议(SIP) (http://tools.1etf.0rg/html/rfc3261)，其中客户端可以包括SIP用户代理并且服务器是SIP应用服务器。
[0060]在又一实施例中，使用可扩展消息传递和存在协议(XMPP) (http://www.1etf.0rg/rfc/ rfc3920.txt)，其中客户端可以包括XMPP客户端并且服务器包括XMPP服务器。SIP 和 XMPP 协议消息二者可以通过根据 draft-1bc-rtcweb-sip-websocket-OO 和 draft-moffitt-xmpp-over-websocket-ΟΟ的WebSocket隧道传输。在图5A-5C中提供针对不同协议的实施例的更加详细的描述。
[0061]在流式传输控制信道的建立期间，可以在CCCF和CCSF之间交换信道参数(步骤210)。另外，为了处理源自客户端的消息，CCSF可以创建专用信道处理过程(线程)(步骤212)。一旦建立流式传输控制信道214，客户端可以开始对标识在清单文件中的段进行流式传输的过程。流式传输过程可以基于HAS类型流式传输协议并且开始于包括与第一段segment_low-l.avi相关联的URL的HTTP获取请求(步骤216)。一旦第一段的递送被HTTP200 OK响应确认(步骤218)，客户端可以请求后续段segment_high-2.avi(步骤220、222)。
[0062]然后，媒体服务器中的CCSF可以决定对于客户端来说更新其清单文件是必要的。例如，CCSF可以检测可能的服务器过载或故障。它因此可以通过流式传输控制信道发送可选地包括指向新的清单文件的URL的清单更新信号(步骤224)。当接收到清单文件更新信号时，CCCF可以请求新的清单文件。当接收到新的清单文件时，客户端可以基于新的清单而继续流式传输(未示出)。
[0063]在一个实施例中，代替传递清单文件中的信道建立信息，信道建立信息可以被预安装到终端中或者可以经由单独的通信信道从另一个(网络)源获取。在这种情况中，当客户端接收到清单文件时，它触发获取信道建立信息的流式传输控制信道客户端功能以便建立流式传输控制信道，如参照图2步骤208-214描述的那样。
[0064]在另一个实施例中，媒体服务器可以被配置成将段流式传输到多个客户端，其中每个客户端与其自身的流式传输控制信道相关联以便实现网络发起的(例如服务器发起的)控制，如参照图2描述的那样。这样，服务器可以基于网络参数(例如网络业务或服务器的处理负载)而控制分段内容到多个客户端的流式传输。例如，在一个特定实施例中，不同客户端可以与不同订阅相关联，例如高级(premium)订阅和普通订阅。当与媒体服务器相关联的负载平衡功能240检测到负载上的增加时，它可以抢先通过用信号通知CCSF发起清单文件更新来降低它的负载，其中普通客户端(的至少其部分)被提供有使这些客户端请求与低速率和/或(较)低质量相关联的段的新的清单文件。
[0065]可以以各种方式实现清单文件更新。在一个实施例中，可以经由流式传输控制信道向客户端发送更新的清单文件的全部或至少部分。在另外的实施例中，CCSF可以向客户端(特别地，CCCF)发送清单更新触发，客户端通过向(默认)位置(例如原始媒体服务器)或向如清单文件更新触发中(例如，使用URL)所标识的新的位置(例如另外的媒体服务器)请求更新的或新的清单文件来进行响应。
[0066]图3描绘了根据本发明的实施例的客户端侧过程流。具体地，图3描绘了与在客户端上执行以用于段的获取和播出和用于提供如例如图2中描绘的通过流式传输控制信道的流式传输的服务器发起的控制的过程相关联的过程流。过程可以开始于客户端请求与特定分段内容项相关联的清单文件(步骤300)。清单文件可以包括段位置，而且还包括客户端用于建立流式传输控制信道的信道建立信息(诸如WebSocket URL和可能地用于指示例如WebSocket子协议的使用、WebSocket版本等的一些参数。当从服务器接收到清单文件时，客户端可以解析清单文件(步骤301和302)并且在客户端中开始至少两个不同的过程/线程:至少是由客户端中的媒体流式传输客户端功能执行以用于处理段获取和段的回放的第一过程以及由客户端中的CCCF执行以用于处理流式传输控制信道的第二过程。客户端可以使用在清单文件中描述的段位置以周期性地获取段并且将它们播出(步骤303)，直到检测到视频的结束为止(步骤304)。另外，客户端可以使用嵌入在清单文件中的信道建立信息以基于清单文件中描述的URL而向服务器发送信道建立请求(步骤305)并且在客户端(特别是客户端中的CCCF)与服务器(特别是与服务器相关联的CCSF)之间建立流式传输控制信道(步骤306)。然后，在段的流式传输和播出期间，CCCF针对来自服务器的传入消息而侦听(Iisten)流式传输控制信道(步骤307)。流式传输控制信道还可以用于从客户端到服务器的数据传输。
[0067]在来自服务器的传入消息的情况中，CCCF可以检查是否已经接收清单更新信号(清单更新触发)(步骤308)。如果已经接收这样的清单更新信号，CCCF可以请求更新的清单(要么来自它从其接收原始清单的位置要么来自清单更新触发消息中指定的URL)(步骤309)。在接收更新的清单文件之后，客户端对其进行解析(参见步骤302)并且更新段标识符和相关联的位置信息的列表。
[0068]图4描绘了根据本发明的实施例的服务器侧过程流。具体地，图4描绘了在媒体服务器上执行以用于将段流式传输到客户端并且用于使用流式传输控制信道提供对流式传输的网络发起的控制的过程的过程流。过程可以由媒体服务器上主控的各种功能执行，如例如参照图2描述的那样，即流式传输服务器功能、控制信道服务器功能以及，可选地，负载平衡功能。功能可以被配置成执行一个或多个过程以用于监视服务器负载、对来自客户端的段请求进行响应和建立并维护与客户端的流式传输控制信道。
[0069]例如，第一过程可以由监视对客户端向服务器发送的信道建立的请求的接收的媒体服务器中的CCSF执行(步骤402)。如果接收到这样的请求，CCSF可以建立流式传输控制信道并且发起信道处理过程，其中源自或发送到客户端的信息例如被适当地处理。第二过程可以由处理对来自客户端的针对清单文件和/或段的请求的接收的媒体流式传输服务器功能执行(步骤400)。如果接收到这样的请求，服务器可以向请求客户端发送所请求的信息(段和/或清单文件)(步骤401)。第三过程可以涉及监视网络负载信息和/或服务器负载信息的负载平衡功能。如果负载达到或接近某个(最大)阈值，它可以发信号通知CCSF选择用于清单文件更新的一个或多个客户端(步骤405)。作为响应，CCSF可以向所选客户端发送清单更新触发(步骤406)。
[0070]例如，在一个实施例中，与服务器相关联的负载平衡功能可以发信号通知CCSF发起清单文件更新以便降低服务器的处理负载。更新的清单文件指示客户端基于较低质量的段的而继续流式传输。在另一个实施例中，CCSF可以检测服务器过载或服务器故障并且作为响应发起清单文件更新以用于指示一个或多个客户端从另一个网络服务器获取段。
[0071]清单更新过程可以以若干方式实现。在一个实施例中，更新的清单文件可以由CCSF经由流式传输控制信道发送到客户端中的CCCF。在另一个实施例中，CCSF可以向客户端中的CCCF发送清单文件更新触发，其作为响应而向媒体服务器请求更新的或新的清单文件。在另外的实施例中，清单文件更新触发可以包括另外的媒体服务器的位置信息，例如URL，使得客户端可以基于该位置信息而向该另外的媒体服务器请求更新的或新的清单文件(步骤406)。
[0072]图5A-5C描绘了用于建立流式传输控制信道以用于实现网络发起的流式传输控制的的各种非限制性协议流。具体地，图5A描绘了类似于图2的消息流，其中HTTPWebSocket协议被用于建立流式传输控制信道。该过程可以开始于用户选择去往网站上的视频的链接，其中URL可以(例如通过重定向)指向清单文件(步骤500a)。作为响应，客户端可以发送HTTP获取请求以从服务器获得清单文件(步骤501a)，所述清单文件由服务器发送(在这种情况中以XML文件的形式)到客户端(步骤502a)。
[0073]客户端可以解析清单文件以获得构建视频的段的至少部分的位置(步骤503a)并且使用嵌入在清单文件中的信息以向服务器发送WebSocket建立请求(HTTP GET/WSws://…)(步骤504a)。在执行强制WebSocket握手之后(如在WS草案draft-1etf-hyb1-thewebsocketprotocol-17中详细描述的那样),服务器可以使用HTTP 101切换协议消息接受来自客户端的WebSocket请求(步骤505a)。然后，为了通过要创建的WebSocket处理传入消息，服务器可以创建专用过程/线程(步骤506a)从而建立WebSocket流式传输控制信道，其可以被用于提供服务器发起的流式传输控制(步骤507a)。
[0074]WebSocket协议允许通过尽力而为(best-effort)的因特网连接的全双工、双向通信。服务器和客户端二者可以在任何时间或甚至在相同时间通过流式传输控制信道发送数据。只有数据被发送而没有HTTP报头(header)的开销，从而急剧增加带宽。而且，由于WebSocket是基于HTTP的协议，它通常不会被防火墙或网络地址翻译器(NAT)自动阻挡。
[0075]图5B描绘了用于建立使用SIP协议的类似于图2的流式传输控制信道的消息流。该过程可以开始于用户选择去往网站上的视频的链接，其中URL可以(例如通过重定向)指向清单文件(步骤500b)。作为响应，客户端可以发送HTTP获取请求以从服务器获得清单文件(步骤501b)，所述清单文件由服务器发送(在这种情况中以XML文件的形式)到客户端(步骤 502b)。
[0076]客户端可以解析清单文件以获得组成视频的段的位置(步骤503b)并且使用嵌入在清单文件中的信息来向SIP应用服务器发送SIP邀请(INVITE)消息(步骤504b)。该信息可以被格式化为会话描述协议消息[http://www.1etf.0rg/rfc/rfc4566.txt]。服务器可以接受邀请消息并且用SIP 200 OK消息进行响应(步骤505b)。然后，为了处理通过要创建的SIP会话的传入消息，服务器可以创建专用过程/线程(步骤506b)从而建立基于SIP的流式传输控制信道，其可以被用于提供服务器发起的流式传输控制(步骤507b )。
[0077]图5C描绘了用于建立使用XMPP协议的类似于图2的流式传输控制信道的消息流。该过程可以开始于用户选择去往网站上的视频的链接，其中URL可以(例如通过重定向)指向清单文件(步骤500c)。作为响应，客户端可以发送HTTP获取请求以从服务器获得清单文件(步骤501c)，所述清单文件由服务器发送(在这种情况中以XML文件的形式)到客户端(步骤 502c)。
[0078]客户端可以解析清单文件以获得组成视频的段的位置(步骤503c)并且使用嵌入在清单文件中的信息(诸如XMPP服务器的Jabber标识符(JID))来通过XML流向XMPP服务器发送以一个或多个XML节(Stanza)的形式的XMPP会话请求消息(步骤505c)。XMPP服务器可以接受会话请求消息并且用会话创建结果消息进行响应(步骤506c)。然后，为了处理通过要创建的XMPP会话的传入消息，服务器可以创建专用过程/线程(步骤507c)从而建立基于XMPP的流式传输控制信道，其可以被用于提供服务器发起的流式传输控制(步骤508c)。
[0079]图6描绘了根据本发明的一个实施例的用于将分段内容递送到客户端的内容流式传输系统600。具体地，图6描绘了包括CDN的内容递送系统的架构概览，其被配置成提供对CDN中的一个或多个递送节点与一个或多个客户端之间的流式传输过程的网络发起的控制。网络发起的控制可以基于如参照图2-5描述的流式传输控制信道功能而实现。
[0080]在该实施例中，内容递送系统可以包括至少一个内容递送网络(⑶N) 602、经由传输网络600连接到一个或多个客户端603的内容源(CS)601。内容源可以涉及内容提供商系统(CPS)、内容准备系统或另一个CDN。CPS可以被配置成向消费者供应内容，例如音频项或视频标题，消费者可以使用客户端购买和接收内容。
[0081]客户端可以以运行在终端(即内容处理设备)上的软件程序来实现，例如诸如电子平板、智能电话、笔记本、媒体播放器等之类的(移动)内容播出设备。在一些实施例中，终端可以是机顶盒或内容存储设备，其被配置成处理和临时存储内容以供内容播出设备未来消费。
[0082]CDN可以包括递送节点(DN1、DN2 ) 611、612和至少一个中央CDN节点(CCN ) 610。每个递送节点可以包括控制器630、631和用于存储和缓存内容的高速缓存632、633或者与其相关联。每个CCN可以包括用于控制来自外部源(例如内容提供商或另一个CDN)的内容的摄取(ingest1n)的摄取功能(或内容起源功能，C0F) 620、用于维护关于内容存储在⑶N内的哪里的信息的内容位置数据库622和用于控制内容的一个或多个副本到递送节点的分发并且用于将客户端重定向到合适的递送节点(还称为请求路由的过程)的⑶N控制功能(⑶NCF) 621或者可以与其相关联。可以控制所述分发使得遍及⑶N，保证用于到客户端的内容递送的充足带宽。在一个实施例中，⑶N可以涉及如ETSI TS 182 019中描述的⑶N。
[0083]消费者可以通过向web入口(WP) 661发送请求来从CPS 660购买分段内容，例如视频标题，所述web入口 661被配置成提供标识可购买的视频标题的标题引用。响应于请求，客户端可以接收来自WP的标题引用的至少部分和能够递送所选内容⑶N的⑶NCF的位置信息(例如URL)。
[0084]⑶NCF可以发送与一个或多个递送节点相关联的客户端位置信息，所述一个或多个递送节点被配置成向客户端递送所选内容。可以在CDN中的一个递送节点上或者可替换地，在⑶N中的不同递送节点上主控所述段。例如，可以在⑶N中的多个递送节点上主控更流行的段，使得可以保证及时递送。通常，CDNCF可以选择CDN中最适于向客户端递送所选内容的递送节点。用于选择一个或多个递送节点的准则可以基于递送节点的处理负载和/或与客户端相关联的上下文信息:例如客户端的位置(IP地址)和/或客户端的订阅(例如如参照图2描述的高级订阅或普通订阅)。因而，这样，CDNCF可以动态地生成清单文件，其被优化以用于向客户端高效递送段。
[0085]客户端可以使用例如传统DNS系统而与CDN中的递送节点联系。另外，各种流式传输协议可以被用于向对流进行处理以供视频播出功能651播出的媒体流式传输功能652递送内容。这样的协议可以包括HTTP和RTP/RTCP类型流式传输协议。在优选实施例中，可以使用诸如HTTP自适应流(HAS)和有关协议之类的自适应流协议，诸如Apple HTTP实时流式传输、Microsoft平滑流式传输、Adobe HTTP动态流式传输、3GPP-DASH和MPEG通过HTTP的动态自适应流。
[0086]CDN被配置成摄取和分发分段内容。已知的分段流式传输系统可以基于时间分段，诸如HTTP自适应流(HAS)，其中内容可以组织在许多段(片或部分)中，其可以根据诸如MPEG或AVI之类的已知传输容器格式被格式化。
[0087]段之间的关系可以描述在清单文件中，其可以使用特定文件扩展名被存储和标识，例如.mf、.xml和.m3u8。清单文件还可以描述一个或多个递送节点上的不同段的位置和名称(段标识符)。可以从CDN中的多于一个的递送节点获取段，特别是流行段。而且，在某些情形中，段应当从另一个CDN域中的递送节点获取。将参照图12和13更加详细地描述该情形。CDNCF可以管理其中可以获取段的位置。为此，CDNCF可以使用内容位置数据库622。在一个实施例中，内容位置数据库可以涉及资产位置功能(ALF) JBETSI TS 182 019中描述的那样。
[0088]另外，⑶N可以包括递送连续性节点(DCN) 613，其被配置成建立和管理与客户端相关联的流式传输控制信道并且维护包括客户端和这些客户端连接到的一个或多个递送节点的数据库。DCN可以包括递送连续性管理功能(DCMF) 640。该功能可以执行用于监视源自⑶NCF的请求路由(RR)功能的通知的过程。DCN还可以包括用于监视来自客户端的信道建立请求并且与客户端中的控制信道客户端(CCCF)功能650建立流式传输控制信道的DCN中的控制信道服务器功能(CCSF) 641。
[0089]另外，在DCN中或与其相关联的递送连续性(DC)数据库642可以存储客户端信息(例如其IP地址)和清单文件信息(即段标识符(例如文件名)和主控这些段的递送节点的至少部分)。递送连续性管理功能(DCMF)可以监视源自⑶NCF或来自⑶N中的单独的网络监视功能的网络通知(例如(过)负载通知或故障通知)并且响应于这样的网络通知的接收而开始清单文件更新过程。参照图8描述关于DCN中的过程和功能的细节。
[0090]尽管在图6中DCN中的功能(即DCMF和CCSF)被实现在不同的节点(DCN)上，但是在另外的实施例中，这些功能还可以完全地或部分地实现在包括CDNCF和摄取功能的CCN610 上。
[0091]图7描绘了用于在根据本发明的实施例的内容流式传输系统中使用的消息流。具体地，图7描绘了用于在CDN类型内容流式传输系统中使用的消息流，所述CDN类型内容流式传输系统被配置成提供CDN中的一个或多个递送节点与一个或多个客户端之间的流式传输过程的网络发起的控制。在该实施例中，⑶N可以包括至少第一和第二递送节点(DN1、DN2)以及包括CDNCF、DCMF和CCSF的CCN，如参照图6描述的。
[0092]图7中的过程可以开始于用户选择去往网站上的视频的链接，其中URL可以(例如通过重定向)指向清单文件(步骤700)。基于选择，客户端可以向CDNCF发送HTTP获取请求以获得清单文件(步骤701)。CDNCF可以通过向客户端发送清单文件来对所述请求进行响应(步骤702)。在这种情况中，基于来自负载平衡功能的信息，CDNCF可以选择和/或生成包含对存储在第一递送节点DNl上的段的引用(例如段标识符和/或相关联的位置信息)的清单文件。另外，⑶NCF记录以下事实:它已经向特定客户端(由例如其IP地址定义)发送包含对特定一个或多个递送节点(的集合)(在该示例中，递送节点DNl)的引用的清单文件。为此，CDNCF可以存储与视频标题的至少部分相关联的客户端信息(例如客户端的IP地址)和清单文件信息(例如清单文件标识符清单ID)以及主控被递送连续性(DC)数据库中的清单文件引用的段的特定一个或多个递送节点(的集合)的位置信息以供未来使用(步骤
703)。
[0093]这里，清单文件标识符可以由数字标识并且递送节点可以由⑶N中已知的递送节点标识符标识。客户端可以解析清单文件以获得组成视频的段的位置(例如URL)(步骤
704)。另外，客户端中的CCCF可以使用清单文件中的信道建立信息以建立⑶N中的CCCF与CCSF之间的流式传输控制信道(步骤705a)(在CCCF与CCSF之间建立流式传输控制信道的过程参照图2和3加以描述，并且在此不重复)。
[0094]在流式传输控制信道的建立期间，CCSF可以通过使用存储在DC数据库中的信息来使信道建立请求与特定客户端和一个或多个相关联的递送节点相关(步骤705b)。特别地，CCSF可以针对为其建立流式传输控制信道的客户端(其中客户端可以被例如其IP地址标识)而查询DC数据库并且向属于客户端的数据库条目分配唯一流式传输信道标识符或信道ID (例如端口号或在使用WebSocket的情况中，WebSocket ID)。这样，CCSF能够使特定客户端-信道组合与特定的一个或多个递送节点(的集合)和/或清单文件相关。
[0095]一旦流式传输控制信道被建立，客户端可以通过向第一递送节点DNl请求第一段(在这种情况中为segment_low-l)(如在清单文件中也被引用的)来开始流式传输过程(步骤706)。递送节点DNl可以通过将请求的段流式传输到客户端来进行响应(步骤707)。
[0096]在流式传输过程期间，在某个时间点处，⑶NCF (包括用于监视⑶N中的递送节点的负载的负载平衡功能或与其相关联)可以注意到第一递送节点DNl上的负载接近(最大)阈值水平(步骤708)。CDNCF可以告知DCMF通过检查存储在DC数据库中的信息来检查哪些客户端正在使用第一递送节点DNl (步骤709)。DCMF然后可以决定将一些(或全部)客户端离开第一递送节点DNl而重定向到另一个、第二递送节点DN2,使得降低第一递送节点Dl的处理负载。为此，DCMF可以指示CCSF通过DCMF使用DC数据库中的信息选择的客户端的流式传输控制信道而发送清单更新触发(步骤710)。
[0097]当接收到清单更新触发时,客户端中的CCCF被触发而通过向⑶NCF发送清单请求来请求新的或更新的清单文件(步骤711)(以如参照步骤701描述的类似的方式)。CDNCF可以接收清单请求并且针对客户端而选择或生成新的或更新的清单文件并且向客户端发送该清单文件。
[0098]在一个实施例中，当生成新的或更新的清单文件时，CDNCF可以使用来自负载平衡功能的信息以便选择新的递送节点(同样参见步骤702)。另外，新的或更新的清单文件可以包含去往存储在第二递送节点DN2上的段的链接。
[0099]在一个实施例中，清单更新触发可以包括标识包括新的或更新的清单文件的另外的节点的位置信息，例如URL。在另一个实施例中，代替发送清单更新触发以发信号通知客户端获取新的或更新的清单文件，新的或更新的清单文件可以直接经由流式传输控制信道发送到客户端。在更新的清单文件被发送回到客户端之后，所述客户端使用新的或更新的清单文件恢复来自第二递送节点的段的流式传输(未示出)。
[0100]由于客户端已经接收到新的或更新的清单文件，⑶NCF可以通过执行如参照703描述的步骤来更新与DC数据库中的该客户端相关联的清单文件信息。这样，如果在未来的某个时间点处出现过载问题，CDNCF可能能够将客户端再次重定向到另一个递送节点。
[0101]图8描绘了与根据本发明的一个实施例的递送连续性节点(DCN)相关联的过程流。具体地，图8提供了可以在如参照图6描述的递送连续性节点(DCN)上主控的一个或多个功能的概览。DCN可以被配置成建立和管理与客户端相关联的流式传输控制信道并且维护列出客户端和它们连接到的一个或多个递送节点的表。在另一个实施例中，与DCN相关联的功能中的全部或至少部分可以在CCN上主控(参见图7、9、11和13)。
[0102]DCN可以包括递送连续性管理功能(DCMF)。该功能可以执行用于监视源自⑶NCF的请求路由(RR)功能的通知的过程(步骤800)。无论何时⑶NCF向客户端发送清单文件，或将客户端重定向到特定递送节点，CDNCF可以告知DCN客户端预期从哪些递送节点获取段(即在发送到客户端的清单文件中引用的递送节点，或客户端重定向到的递送节点)。当接收到通知时，DCN可以将向发送到该客户端的清单文件中引用的递送节点的至少部分分配特定客户端(由例如其IP地址标识)的条目添加到递送连续性(DC)数据库中(步骤801)。
[0103]另外，控制信道服务器功能(CCSF)可以监视来自客户端中的CCCF的信道建立请求(步骤802)。如果它接收到请求，它将开始基于适合的协议(例如WebSocket、SIP或XMPP)而建立流式传输控制信道的过程。
[0104]在流式传输控制信道的建立期间，CCSF可以针对为其建立流式传输控制信道的客户端(其中客户端可以被例如其IP地址标识)而查询DC数据库并且向属于客户端的数据库条目分配唯一流式传输信道标识符(例如端口号，或者在使用WebSocket的情况中，WebSocket ID)(步骤803)。DCMF然后可以执行用于监视例如来自⑶NCF、与⑶NCF相关联的负载平衡功能(步骤804)或单独的网络监视功能的网络过载通知或故障通知的网络通知的监视过程。在一个实施例中，过载或故障通知可以包括关于CDNCF想要重定向的客户端的数目的信息。
[0105]一旦DCMF从⑶NCF接收到这样的通知(要么涉及在其自身的⑶N中的递送节点要么涉及另一个CDN (未示出)中的递送节点)，它可以查询DC数据库以检查预期从与过载或故障通知相关联的递送节点获取段的客户端(步骤805)。DCMF然后可以选择要重定向的一个或多个客户端(步骤806)(该选择可以基于要重定向的客户端的数目，如上文参照步骤804描述的那样)。此后，DCMF可以查询它的数据库以便识别与所选客户端相关联的流式传输信道(使用例如流式传输信道标识符)并且通过这些信道中的每一个发送清单更新触发。
[0106]DMCF还可以被配置成监视源自客户端的消息。在一个实施例中，DMCF可以通过流式传输控制信道向客户端发送新的或更新的清单文件。
[0107]图9描绘了用于在根据本发明的另一个实施例的内容流式传输系统中使用的消息流。具体地，图9示出了用于与类似于图7的内容递送系统一起使用的消息流。然而在该实施例中，清单文件并不是通过CDNCF递送到客户端，而是通过递送节点自身。为此，递送节点(例如第一递送节点DNl)可以包括仅包含对该递送节点上的段的引用的清单文件。
[0108]图9中的过程可以开始于用户选择去往网站上的视频的链接，其中URL (例如通过从内容提供商的重定向)指向⑶NCF的请求路由(RR)功能(步骤900)。在客户端已经向⑶NCF发送HTTP获取请求(步骤901)之后，⑶NCF的RR功能可以基于例如从负载平衡功能获得的信息而选择适于向客户端递送请求的清单文件和相关联的分段内容的递送节点。CDNCF然后可以向客户端发送包含去往所选递送节点(在该特定示例中，第一递送节点DNl)上的清单文件的URL的HTTP重定向(REDIRECT)消息(步骤902)。
[0109]当重定向HTTP获取请求时，⑶NCF可以将客户端信息(例如客户端的IP地址)和清单文件信息(例如与视频标题的至少部分相关联的清单文件标识符或清单ID，以及主控被清单文件引用的段的特定的一个或多个递送节点(的集合)的位置信息)存储在递送连续性(DC)数据库中以供另外的使用(步骤903)。这里，清单文件标识符可以由数字标识并且递送节点可以由⑶N内已知的递送节点标识符标识。
[0110]当从⑶NCF接收到HTTP重定向消息时，客户端可以向与第一递送节点相关联的重定向消息中的URL发送新的HTTP获取消息(步骤904)。递送节点DNl随后通过向客户端发送请求的清单文件进行响应(步骤905)。
[0111]在已经接收到清单文件之后，客户端可以解析清单文件以获得组成视频的段的位置(步骤906)。客户端中的CCCF可以使用清单文件中的信道建立信息以建立CCSF与客户端之间的流式传输控制信道(步骤907a)(建立信道的过程在图2和3中描述并且在此不重复)。
[0112]在流式传输控制信道的建立期间，CCSF可以通过使用存储在DC数据库中的信息来使信道建立请求与特定客户端和相关联的递送节点相关(步骤907b)。特别地，CCSF可以针对为其建立流式传输控制信道的客户端(其中客户端可以例如由其IP地址标识)而查询DC数据库并且向属于客户端的数据库条目分配唯一流式传输信道标识符(例如端口号或，在使用WebSocket的情况中，WebSocket ID)。这样，CDN中的功能可以检查哪些客户端/信道组合正在使用哪些一个或多个递送节点(的集合)(例如在这种情况中，CDNCF可以检查到特定客户端正在使用第一递送节点DNl并且已经接收到特定清单文件)。
[0113]一旦流式传输控制信道被建立(如例如图2和3中所描述的那样)，客户端可以开始请求、接收和播出从第一递送节点DNl获得的段(步骤908)。在流式传输过程期间，在某个时间点处，CDNCF(其包括用于监视CDN中的负载递送节点的负载平衡功能或与其相关联)可以注意到第一递送节点DNl上的负载达到预定(最大)阈值水平(步骤909)。⑶NCF然后可以触发DCMF通过检查存储在DC数据库中的信息来确定哪些客户端与第一递送节点DNl相关联(步骤910)。基于该信息，DCMF可以决定将一些(或所有)客户端重定向离开第一递送节点DNl。
[0114]为此，它可以触发CCSF通过这些客户端的控制信道发送清单更新触发(步骤911)。为了确保客户端不从第一递送DNl (作为默认)接收它们的更新的清单，清单更新触发可以包括与新的或更新的清单文件相关联的URL (指向例如第二递送节点DN2)。清单更新触发的接收用信号通知客户端应当请求新的清单文件。它然后可以发送对与清单更新触发中引用的第二递送节点DN2相关联的URL的清单文件请求(步骤912)。第二递送节点DN2可以通过向客户端发送请求的清单文件来进行响应。
[0115]当接收到该清单文件时，客户端可以通过向第二递送节点DN2而不是第一递送节点DNl请求后续段来继续流式传输过程(步骤913)。由于客户端已经接收到新的或更新的清单文件，CDNCF可以通过执行如参照903描述的步骤来更新与DC数据库中的该客户端相关联的清单文件信息。这样，如果在未来的某个时间点中出现过载问题，CDNCF可能能够将客户端再次重定向到另一个递送节点。
[0116]因而，在图9中描绘的实施例中，包括用于建立客户端与CCSF之间的流式传输控制信道的信道建立信息的清单文件被存储在其中存储段的递送节点处。该实现方式提供了以下优势:一些负载和⑶NCF的复杂度被卸载到递送节点。在图7中，⑶NCF主控和/或生成清单文件，使得在每次更新清单文件时，负载被添加到CDNCF。在某些实现方式中，例如在针对实时内容的情况中，客户端发起的清单更新可能相当常出现，例如每30秒一次，从而大幅增加CDNCF上的负载。因而，通过将对客户端发起的清单请求进行响应的任务委托给递送节点，可以实现CDNCF的相当大的负载降低。
[0117]图10描绘了用于在根据本发明的又一实施例的内容流式传输系统中使用的消息流。具体地，图10描绘了类似于图7的消息流，然而代替使DCN功能添加到CDNCF，DCN位于单独的节点中。
[0118]图10中的过程可以开始于用户选择去往网站上的视频的链接，其中URL可以(例如通过重定向)指向在⑶NCF上主控的清单文件(步骤1000)并且客户端传输HTTP获取请求以从⑶NCF获得清单文件(步骤1001)。⑶NCF可以通过向客户端发送清单文件来对该请求进行响应。在该示例中，基于从负载平衡功能获得的信息，CDNCF可以选择包含对存储在第一递送节点DNl上的段的引用的清单文件(步骤1002)。
[0119]⑶NCF可以向DCN、特别是DCN中的DCMF发送通知，指示特定客户端(由例如其IP地址标识)已经被提供有包括对特定的一个或多个递送节点(的集合)的引用的新的或更新的清单文件(步骤1003)。DCMF可以将客户端信息(例如客户端的IP地址)和清单文件信息(例如与视频标题的至少部分相关联的清单文件标识符或清单ID，以及主控被清单文件引用的段的特定的一个或多个递送节点(的集合)的位置信息)存储在DC数据库中以供未来使用(步骤1004)。这里，清单文件标识符可以由数字标识并且递送节点可以由CDN内已知的递送节点标识符标识。
[0120]客户端可以解析清单文件以获得组成视频的段的位置(例如URL)(步骤1005)。另夕卜，客户端可以使用清单文件中的信道建立信息以建立到DCN的信道(步骤1006a)。(建立信道的过程在图2和3中描述并且在此不重复)。
[0121]在流式传输控制信道的建立期间，CCSF可以通过使用存储在DC数据库中的信息来使信道建立请求与特定客户端和相关联的一个或多个递送节点(的集合)相关。特别地，CCSF可以针对为其建立流式传输控制信道的客户端(其中客户端可以例如由其IP地址标识)而查询DC数据库并且向属于客户端的数据库条目分配唯一流式传输信道标识符(例如端口号或，在使用WebSocket的情况中，WebSocket ID)。这样，CDN中的功能(例如CDNCF、DCMF和CCSF)能够使特定客户端-信道组合与特定的一个或多个递送节点(的集合)相关。
[0122]一旦建立流式传输控制信道，流式传输客户端功能可以开始请求、接收和播出从第一递送节点DNl获得的段(步骤1007)。在流式传输过程期间，DCMF可以执行用于监视网络通知(例如来自CDNCF、与CDNCF相关联的负载平衡功能或网络监视功能的网络过载或故障通知)的监视过程。例如，在某个时间点处，包括用于监视全部递送节点的负载的负载平衡功能或与其相关联的CDNCF可以注意到DNl上的负载达到预定(最大)阈值(步骤1008)。
[0123]⑶NCF然后可以向DCMF发送过载通知，其指示第一递送节点DNl上的负载接近预定(最大)阈值。在一个实施例中，过载通知可以包括关于要重定向的客户端的数目的信息(步骤1009)。DCMF可以通过检查DC数据库中的清单文件信息来确定正在使用第一递送节点DNl的客户端(步骤1010)。
[0124]DCMF然后可以选择要重定向的客户端并且触发CCSF通过那些客户端的流式传输控制信道发送清单更新触发(步骤1011)。清单更新触发的接收可以用信号通知客户端通过以如参照步骤1001描述的类似的方式向CDNCF发送清单请求来请求新的清单文件(步骤1012)。
[0125]⑶NCF可以接收清单请求并且生成或选择适于客户端的新的清单文件(步骤1013)(例如通过咨询负载平衡功能)。在这种情况中，所选清单文件可以例如包含去往存储在第二递送节点DN2上的段的链接。所选清单文件然后可以被发送到客户端。当接收到新的清单文件时，客户端可以通过向第二递送节点DN2而不是第一递送节点DNl请求后续段来继续流式传输过程。
[0126]由于客户端已经接收到新的或更新的清单文件，其引用在不同递送节点(即第二递送节点DN2而不是第一递送节点DNl)上主控的段，⑶NCF可以更新与客户端相关联的DC数据库中的一个或多个条目。为了这样做，⑶NCF可以向DCN中的DCMF发送通知客户端已经被提供有新的或更新的清单文件(以与参照步骤1003描述的类似方式)。在接收到通知之后，DCMF可以将客户端信息和清单文件信息存储在DC数据库中(以与参照步骤1004描述的类似方式)。这样，CDNCF能够处理与第二递送节点DN2相关联的可能的另外的负载问题。
[0127]因而，图10中描绘的实施例在单独的网络节点DCN上实现用于建立和管理流式传输控制功能的功能，使得对CCN中的CDNCF的所需改变非常有限并且可以重用现有CDNCF实现方式，从而限制在向CDN添加流式传输控制信道功能时所涉及的成本。另外，如果客户端和相关联的活动流式传输控制信道的数目增加，仅DCN的容量而不是整个CDNCF的容量需要升级。该实施例因此提供了用于管理与CDN相关联的大数目的流式传输控制信道的可缩放的解决方案。
[0128]图11描绘了用于在根据本发明的另外的实施例的内容流式传输系统中使用的消息流。具体地，图11示出了类似于图7的消息流，然而代替使每个清单文件仅包括对单个递送节点的引用，清单文件可以包含对多个递送节点的引用。在该实施例中，CDNCF可以被配置成创建和主控清单文件。
[0129]该过程可以开始于用户选择去往网站上的视频的链接，其中URL可以(例如通过重定向)指向清单文件(步骤1100)并且客户端传输HTTP获取请求以从CDNCF获得清单文件(步骤1101)。已经从客户端接收到清单请求，CDNCF可以创建新的清单文件或者选择包括对不同递送节点上的段的引用的现有清单文件(1102)。例如在一个实施例中，清单文件可以包括对在第一递送节点DNl上主控的低质量段的引用，和对在第二递送节点DN2上主控的高质量段的引用。CDNCF可以使用与CDN中的递送节点相关联的负载信息(由负载平衡功能生成)和可选地客户端的位置信息(例如IP地址)以便选择最适于向客户端递送请求的段(的部分)的递送节点。在这种情况中，清单文件可以包括对至少第一递送节点DNl和第二递送节点DN2的引用。
[0130]⑶NCF可以向客户端发送清单文件(步骤1103)并且在DC数据库中存储将客户端信息(例如其IP地址)和清单文件信息(例如客户端的IP地址)和清单文件信息(例如与视频标题的至少部分相关联的清单文件标识符或清单ID，以及主控被清单文件引用的段的特定的一个或多个递送节点(的集合)的位置信息，在这种情况中第一和第二递送节点Dl和D2)(步骤1104)。这里，清单文件标识符可以由数字标识并且递送节点可以由⑶N内已知的递送节点标识符标识。
[0131]客户端可以解析清单文件以获得组成视频的段的位置(步骤1105)并且使用清单文件中的信道建立信息以建立客户端与CCSF之间的流式传输控制信道(步骤1106a)。(建立信道的过程在图2和3中描述并且在此不重复)。
[0132]在流式传输控制信道的建立期间，CCSF可以通过使用存储在DC数据库中的信息来使信道建立请求与特定客户端和相关联的一个或多个递送节点(的集合)相关。特别地，CCSF可以针对为其建立流式传输控制信道的客户端(其中客户端可以例如由其IP地址标识)而查询DC数据库并且向属于客户端的数据库条目分配唯一流式传输信道标识符(例如端口号或，在使用WebSocket的情况中，WebSocket ID)。这样，CDN中的功能可以使特定客户端-信道组合与特定的一个或多个递送节点(的集合)相关。
[0133]一旦建立流式传输控制信道，客户端可以通过请求、接收和播出源自第一和第二递送节点的段来开始流式传输过程(步骤1107)。在流式传输过程期间，在某个时间点处，包括用于监视CDN内的递送节点的负载的负载平衡功能或与其相关联的CDNCF可以注意到第一递送节点DNl上的负载达到或接近预定(最大)阈值(步骤1108)。⑶NCF然后可以触发DCMF通过检查DC数据库中的清单文件信息来检查哪些客户端与第一递送节点DNl相关联(步骤1109)。DCMF然后可以确定哪些客户端需要清单更新并且触发CCSF通过那些客户端的控制信道发送清单更新触发(步骤1110)。
[0134]清单更新触发可以发信号通知客户端它需要通过向CDNCF发送清单请求(参见步骤1101)来请求新的或更新的清单文件(步骤1111)。CDNCF接收清单请求并且创建或选择适于客户端的新的清单文件(参见步骤1102)(步骤1012)。在这种情况中，新的或更新的清单文件可以例如用与主控相同段的另一个递送节点DN (例如第三递送节点DN3)相关联的URL取代与第一递送节点DNl相关联的URL。与递送节点DN2相关联的URL不被取代，因为仅第一递送节点DNl在变得过载的危险中。CDNCF可以向客户端发送新的或更新的清单文件(步骤1113)，其可以更新其(内部)段列表并且通过请求在新的或更新的清单中列出的段来继续流式传输过程。
[0135]由于客户端已经接收到新的或更新的清单文件，⑶NCF可以通过执行如参照1104描述的步骤来更新DC数据库中的与该客户端相关联的清单文件信息。这样，如果在未来的某个点处出现过载问题，⑶NCF可能能够将客户端再次重定向到另一个递送节点。
[0136]因而，图11中描绘的实施例提供了以下优势:被单个清单引用的段可以分布在多个递送节点上，其中每个递送节点仅主控所有段的子集。这样的一个优势是其允许⑶N区分不同类型的段。在分段内容中某些段比其它段更加流行(更常被请求)。例如在时间分段的视频标题中，较早的段通常比较晚的段更常被请求。在另一个示例中，视频标题可以具有涉及不同视频质量的段，其中一些质量将比其它更流行。在这样的情况中，CDN可能在比不太流行的段更多的递送节点处主控更流行的段，从而提供附加的可缩放性和更高的效率。
[0137]图12描绘了根据本发明的另一个实施例的内容流式传输系统。具体地，图12图示了类似于参照图6描述的系统的基于CDN的内容递送系统。然而，在该实施例中系统包括至少两个互连的⑶N。具体地，内容流式传输系统包括经由⑶N互连接口 1264互连到至少第二⑶N 1204 (也称作为下游⑶N)的第一⑶N 1202 (也称作为上游⑶N)，其中每个⑶N被配置成提供CDN中的一个或多个递送节点与一个或多个客户端之间的流式传输过程的网络发起的控制。网络发起的控制可以基于如参照图2-5描述的流式传输控制信道功能而实现。
[0138]内容递送系统还可以包括经由传输网络600连接到主控客户端1203的一个或多个终端1204的内容源1201。内容源可以涉及内容提供商系统CPS、内容准备系统或另一个CDN0 CPS可以被配置成CPS可以被配置成向消费者供应内容(例如视频标题)，消费者可以使用包括对流进行处理以供视频播出功能1251播出的媒体流式传输功能1252的客户端购买和接收内容。
[0139]类似于图6，CDN可以包括递送节点1211、1212、1215和至少一个CCN 1210、1223。每个递送节点可以包括控制器1230、1231、1234和用于存储和缓存内容的高速缓存1232、1233、1235或者与其相关联。每个CCN可以包括用于控制来自外部源(例如内容提供商或另一个⑶N)的内容的摄取的摄取节点(或内容起源功能，C0F) 1220、1223、用于维护关于内容存储在CDN内的哪里的信息的内容位置数据库1222、1225和用于控制内容的一个或多个副本到递送节点的分发并且用于将客户端重定向到合适的递送节点(还称为请求路由的过程)的⑶N控制功能(⑶NCF) 1221、1224或者可以与其相关联。消费者可以通过向web入口(WP) 1261发送请求来从CPS 1260购买内容，例如视频标题，所述web入口 1261被配置成以与参照图6描述的类似方式提供标识可购买的内容项的标题引用。
[0140]⑶NCF可以管理其中可以使用内容位置数据库1222、1225来获取段的位置。另外，⑶N可以包括递送连续性节点(DCN) 1213、1216，其被配置成建立和管理与客户端相关联的流式传输控制信道并且维护包括客户端信息和这些客户端连接到的一个或多个递送节点的清单文件信息。DCN可以被配置为独立的DCN或集成在⑶NCF中。
[0141]DCN可以包括用于监视源自⑶NCF的请求路由(RR)功能的通知的递送连续性管理功能(DCMF) 1240、1243，监视来自客户端的信道建立请求并且与客户端中的控制信道功能1250建立流式传输控制信道的控制信道服务器功能(CCSF) 1241、1244 ;以及，在DCN中或与其相关联的递送连续性(DC)数据库1242、1245，其用于存储客户端信息(例如客户端的IP地址)和清单文件信息(即段标识符(例如文件名)和与主控这些段的递送节点的至少部分相关联的位置信息(例如URL))。
[0142]DCMF可以监视网络通知，例如过载或故障通知，其源自⑶NCF的请求路由(RR)功能，CDN中的单独的过载功能或网络监视功能，并且响应于这样的通知的接收而开始清单文件更新过程。以下将参照图13更加详细地描述清单文件更新过程的细节。
[0143]在图12的内容递送系统中，上游⑶N可以将段到客户端的递送的部分外包给下游CDN0例如，在一个实施例中，低质量段可以由第一 CDN A(被配置例如用于内容到移动设备的递送)定位和递送并且高质量段可以由第二⑶N B(被配置例如用于高质量段到支持HDTV技术的家庭媒体设备的递送)定位和递送。
[0144]当向下游⑶N外包段的递送的部分时，上游⑶N (或者具体地，上游⑶N的⑶NCF)可以开始用于生成包括对第一 CDN A中的一个或多个递送节点的引用和对第二 CDN B中的一个或多个递送节点的引用的清单文件的过程。这样的清单文件可以称作为CDN间清单文件。⑶N间清单文件还可以包括用于建立客户端与上游⑶N A之间的流式传输控制信道的信道建立信息。
[0145]在生成⑶N间清单文件的过程期间，信息可以在⑶N之间经由互连接口 1264进行交换。特别地，在⑶N间清单文件的生成期间，上游⑶N可以向下游⑶N请求关于外包给下游CDN的一个或多个段的位置信息。作为响应，下游CDN可以基于关于客户端的上下文信息而选择主控所请求的段的递送节点。例如，下游CDN可以选择在地理上最靠近客户端的位置的递送节点。该信息随后被发送到上游⑶N的⑶NCF以用于生成⑶N间清单文件。因而，图13中的内容递送系统被配置成动态地生成“个性化”CDN间清单文件。
[0146]一旦CDN间清单文件被生成和转发到客户端，客户端中的控制信道功能可以使用⑶N间清单文件中的信道建立信息与上游⑶N的DCN中的CCSF建立流式传输控制信道以及开始请求并且播出段。
[0147]在流式传输过程期间，DCMF可以从⑶NCF接收网络通知，例如(过)负载通知或故障通知，并且确定客户端应当被重定向到一个或多个其它的递送节点。网络通知可以涉及上游⑶N或下游⑶N中的网络问题情形。在后一种情况中，下游⑶N的⑶NCF可以经由互连接口 1264向上游⑶N的⑶NCF发送网络通知。
[0148]图13描绘了用于在根据本发明的再一实施例的内容流式传输系统中使用的消息流。具体地，图13示出了用于在如图12中描绘的内容递送网络中使用的消息流，其中清单文件可以包括对在与不同CDN相关联的不同递送节点上主控的段的引用。
[0149]该过程可以开始于用户选择去往网站上的视频的链接，其中URL (例如通过重定向)指向在与第一⑶N A相关联的第一⑶NCF上主控的清单文件(步骤1300)。该⑶N还可以称作为上游CDN。基于选择，客户端可以发送HTTP获取请求以从CDN A的CDNCF获得清单文件(步骤1301)。
[0150]在已经从客户端接收到清单请求之后，第一⑶NCF可以开始用于创建新的清单文件或者更新现有清单文件的过程，其中清单文件可以包括对与不同CDN相关联的不同递送节点上的段的引用(步骤1302)。例如，在一个实施例中，低质量段可以由第一⑶N A (被配置例如用于内容到移动设备的递送)定位和递送。该⑶N可以称作为上游⑶N。另外，高质量段可以由第二 CDN B(被配置例如用于高质量段到支持HDTV技术的家庭媒体设备的递送)定位和递送。该⑶N可以被称作为下游⑶N。包括至少对与第一⑶N A相关联的第一递送节点DNl和与CDN B相关联的第二递送节点DN2的引用的清单文件可以被称作为CDN间清单文件。该⑶N间清单文件还可以包括用于在客户端和与上游⑶N A相关联的第一⑶NCF之间建立流式传输控制信道的信道建立信息。
[0151]在一个实施例中，⑶N间清单文件可以基于以下过程而生成，其中上游⑶N A的第一⑶NCF请求下游⑶N B的第二⑶NCF提供对应该由⑶N B递送到客户端的预定数目的段的位置的引用。
[0152]第一⑶NCF然后可以向客户端发送⑶N间清单文件(步骤1303)其中第一⑶NCF可以在与第一 CDNCF相关联的DC数据库中存储与第一 CDN A相关联的客户端信息(例如其IP地址)和清单文件信息，其包括与视频标题的至少部分相关联的清单文件标识符或清单ID,以及主控被清单文件引用的段的特定的(一个或多个)递送节点(的集合)的位置信息)以及与第二⑶N B相关联的(一个或多个)递送节点(的特定集合)(步骤1304)。这里，段可以由文件名标识并且递送节点可以由递送节点标识符标识。这里清单文件标识符可以由数字标识并且递送节点可以由⑶N内已知的递送节点标识符标识。
[0153]因而，在⑶N间清单文件的生成期间，第一和第二⑶NCF之间的通信发生，使得-(尽管第二⑶NCF不知道⑶N间清单文件中的所有段)第二⑶NCF知道位于其一个或多个递送节点(的特定集合)上的预定数目的段可能由客户端在(不远的)未来请求。因此，第二⑶NCF可以将包括下游⑶N中的递送节点(在该示例中，第二递送节点DN2)连同对上游⑶N (在这种情况中，第一⑶NCF)的引用的⑶N间信息存储在与第二⑶N B相关联的DC数据库中，使得能够利用这些递送节点之一向第一 CDNCF通知任何网络问题，例如负载或故障问题(步骤1305)。
[0154]客户端可以解析⑶N间清单文件以便获得组成视频的段的位置(步骤1306)并且使用清单文件中的信道建立信息以建立第一 CDNCF与客户端之间的流式传输控制信道(步骤1307)(建立信道的过程在图2和3中描述并且在此不重复)。
[0155]在流式传输控制信道的建立期间，与第一⑶NI相关联的CCSF可以通过使用存储在第一 DC数据库中的信息来使信道建立请求与特定客户端和相关联的一个或多个递送节点(的集合)相关(步骤1309)。特别地，CCSF可以针对为其建立流式传输控制信道的客户端(其中客户端可以例如由其IP地址标识)而查询DC数据库并且向属于客户端的数据库条目分配唯一流式传输信道标识符(例如端口号或，在使用WebSocket的情况中,WebSocketID)。这样，第一⑶NI中的功能能够使特定客户端-信道组合与特定的一个或多个递送节点(的集合)相关。在流式传输控制信道的建立之后，客户端可以通过请求、接收和播出从与第一(上游)⑶N A相关联的第一递送节点DNl和与第二 (下游)⑶N B相关联的第二递送节点DN2 二者获得的段来开始流式传输过程(步骤1308)。
[0156]在流式传输过程期间，在某个时间点处，监视其自身的递送节点的第二 CDNCF可以注意到网络问题，例如在第二递送节点DN2中的网络故障或在第二递送节点DN2上的负载达到或接近预定(最大)阈值(步骤1309)。然后，基于DC数据库中的⑶N间信息，第二⑶NCF可以通过向第一⑶NCF发送网络通知(例如(过)负载通知或故障通知)来向第一⑶NCF通知网络问题。过载通知可以发信号通知第一⑶NCF对第二⑶N中的递送节点的引用、特别是对CDN间清单文件中列出的递送节点的引用的至少部分需要被更新(步骤1310)。
[0157]因而，当从第二⑶NCF接收到网络通知时，第一⑶NCF触发DCMF基于存储在与第一⑶N A相关联的DC数据库中的清单文件信息而检查已经向哪些客户端发送包含对第二递送节点DN2的引用的CDN间清单文件(步骤1311)。DCMF然后可以确定哪些客户端重定向并且触发CCSF经由需要被重定向的客户端的控制信道发送清单更新触发(步骤1312)。当接收到清单更新触发时，客户端将通过向第一 CDNCF发送清单文件请求(类似于步骤1301)来请求第一清单文件(步骤1313)。
[0158]第一 CDNCF接收清单请求并且将以如上文参照步骤1302描述的类似的方式与第二 CDNCF协作生成适于客户端的新的或更新的清单文件(步骤1314)。例如，在一个实施例中，第二⑶NCF可以用去往主控相同段的另一个递送节点(例如第四递送节点DN4)的URL取代引用第二 CDN中的(几乎)过载的递送节点(在这种情况中，第二递送节点)的URL，并且向第一⑶NCF发送这些引用。引用第一⑶N A中的递送节点DNl的URL不被取代，因为对于该递送节点，第一 CDNCF没有接收到过载信令。
[0159]第一⑶NCF可以向客户端发送更新的⑶N间清单文件(步骤1315)，其可以基于更新的清单文件而更新它内部的段列表并且通过请求来自新的清单中列出的URL的后续段来继续流式传输。
[0160]由于客户端已经接收到新的或更新的清单文件，第一⑶NCF可以通过执行如参照1304描述的步骤来更新DC数据库中的与该客户端相关联的清单文件信息。另外，第二CDNCF可以以如参照步骤1305描述的类似方式更新与第二 CDN B相关联的DC数据库中的包括下游CDN中的递送节点(在该示例中，第四递送节点DN4)连同对上游CDN (在这种情况中，第一⑶NCF)的引用的⑶N间信息。这样，如果在未来的某个点处出现⑶N B中的过载问题，第二⑶NCF可能能够将客户端再次重定向到另一个递送节点。
[0161]因而，图13中描绘的实施例提供了以下优势:允许分段内容分布在多个CDN上，其中每个CDN仅主控所有段的子集。该实施例提供了如参照图11论述的相同类型的优势，然而在该情况中不同的递送节点可以分布在多个CDN上。这样的另外一个优势是其允许上游⑶N将一些工作负载外包给另一个下游⑶N。该实施例还允许使用专用⑶N。例如，在一个实施例中，第一 CDN可以被配置和优化用于到移动设备的递送、主控大多数较低质量的段，而第二 CDN可以被配置和优化用于到HD播出设备的递送、主控大多数较高质量的段。
[0162]在上文描述的CDN实施例中主张，代替向通过请求更新的或新的清单文件而进行响应的客户端发送更新清单触发，新的或更新的清单文件(的部分)可以经由到客户端的流式传输控制信道直接发送到客户端。
[0163]图14描绘了根据本发明的一个实施例的清单文件。具体地，图14示出了包括对被配置成递送段的特定集合的递送节点的引用(例如URL)的清单文件的实施例。在该特定示例中，清单文件可以包括对段的两个不同集合的引用，例如低和高比特率段，其与存储在递送节点处的相同内容有关。清单文件还可以包括信道建立信息。在一个实施例中，信道建立信息可以包括提供对包括流式传输控制功能(或在CDN情况中，控制信道服务器功能)的网络节点的引用的信道目标参数1400。另外，在另一个实施例中，信道建立信息可以包括信道参数1402，即由流式传输控制功能/控制信道服务器功能使用的参数。例如，在WebSocket的情况中，参数可以指WebSocket子协议的使用、WebSocket版本等。
[0164]应该理解的是，与任何一个实施例有关地描述的任何特征可以单独使用，或与所描述的其它特征组合，并且还可以使用在与任何其它实施例的一个或多个特征的组合或任何其它实施例的任何组合中。本发明的一个实施例可以实现为用于与计算机系统一起使用的程序产品。程序产品的一个或多个程序定义实施例(包括本文所描述的方法)的功能，并且可以包含在各种计算机可读存储介质上。说明性计算机可读存储介质包括但不限于:(i )其上永久存储信息的非可写存储介质(例如计算机内的只读存储器设备，诸如CD-ROM驱动器可读的CD-ROM盘，闪速存储器、ROM芯片或任何类型的固态非易失性半导体存储器)；以及(ii )其上存储可变信息的可写存储介质(例如磁盒驱动器内的软盘或硬盘驱动器或任何类型的固态随机存取半导体存储器)。本发明不限于以上描述的实施例，其可以在随附权利要求的范围内变化。
【权利要求】
1.用于实现对分段内容从递送节点到至少一个客户端的流式传输的网络发起的控制的方法，所述方法包括: 接收第一清单文件，其包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述至少一个客户端发送与所述一个或多个标识符相关联的一个或多个段； 向客户端提供信道建立信息；以及， 优选地响应于在客户端处接收所述第一清单文件，基于所述提供的信道建立信息，在所述至少一个客户端和与所述递送节点相关联的控制信道服务器功能之间建立至少一个流式传输控制信道，所述至少一个客户端被配置用于经由所述流式传输控制信道接收至少一个清单文件更新消息。
2.根据权利要求1的方法，包括: 针对至少一个清单文件更新消息而监视所述流式传输控制信道。
3.根据权利要求1或2的方法，包括: 检测清单文件更新消息； 响应于检测到所述清单文件更新消息而获取第二清单文件的至少部分；以及，可选地， 基于所述第二清单文件而请求段流或文件。
4.根据权利要求1-3中任一项的方法，其中所述信道建立信息的至少部分被提供给所述第一清单文件中的所述客户端，优选地，所述信道建立信息包括用于定位网络中的所述控制信道服务器功能的服务器位置信息，优选为至少一个URL。
5.根据权利要求1-4中任一项的方法，其中所述清单文件更新消息包括第二清单文件的至少部分或者其中所述清单文件更新消息包括用于定位和请求所述第二清单文件的至少部分的清单文件位置信息，优选为至少一个URL。
6.根据权利要求1-5中任一项的方法,其中所述分段内容基于流式传输协议、优选为基于HTTP的流式传输协议或其派生物而被递送到所述至少一个客户端；和/或，其中所述流式传输控制信道基于WebSocket协议、SIP协议、XMPP协议和/或其组合而被建立。
7.用于实现对分段内容从递送节点到至少一个客户端的流式传输的网络发起的控制的方法，所述方法包括: 递送清单文件，其包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向至少一个客户端向所述至少一个客户端发送与所述一个或多个标识符相关联的一个或多个段； 接收对于在与所述一个或多个内容递送节点相关联的控制信道服务器功能和所述至少一个客户端之间建立流式传输控制信道的请求；以及， 建立所述至少一个流式传输控制信道，其中所述控制信道服务器功能被配置成向所述客户端发送至少一个清单文件更新消息。
8.根据权利要求7的方法，其中所述一个或多个递送节点的至少第一部分被配置为与第一内容递送网络(CDNl)相关联的第一递送节点，所述第一内容递送网络被配置成向所述客户端递送所述段的至少第一部分；和/或，所述递送节点的至少第二部分被配置为与第二内容递送网络(CDN2)相关联的第二递送节点，所述第二内容递送网络被配置成向所述客户端递送所述段的至少第二部分。
9.根据权利要求7或8的方法，包括: 监视一个或多个网络参数，优选为与关联于所述一个或多个递送节点的过载、即将发生的过载、故障或网络配置改变相关联的所述一个或多个网络参数中的至少一个； 在与所述网络参数相关联的一个或多个预定条件满足的情况下，生成清单文件更新消息；以及， 向所述至少一个客户端发送所述清单文件更新消息。
10.根据权利要求8或9的方法，包括: 确定与所述第一和/或第二递送节点中的一个或多个相关联的过载、即将发生的过载、故障或网络配置改变； 识别从与所述确定的过载、即将发生的过载、故障或网络配置改变相关联的所述一个或多个第一和/或第二递送节点获取或预期获取至少一个段的一个或多个客户端； 确定与所述识别出的客户端的至少部分相关联的一个或多个流式传输控制信道；以及， 通过所述一个或多个流式传输控制信道向所述识别出的客户端的至少部分发送清单文件更新消息。
11.根据权利要求10的方法，其中所述过载、即将发生的过载、故障或网络配置改变的所述至少部分与属于第二 CDN2的所述第二递送节点的至少一个相关联，所述方法包括: 所述第二 CDN2向所述第一 CDNl发送过载、故障或网络配置改变通知，所述通知包括与所述过载、故障或网络配置改变相关联的一个或多个第二递送节点标识符。
12.一种用于使用在用于控制对从至少一个递送节点发送的分段内容的接收的内容处理设备中的客户端，所述第一递送节点与第一控制信道服务器功能相关联，所述客户端被配置用于: 向所述至少一个递送节点发送对于递送分段内容的请求； 接收清单文件，其包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述至少一个客户端发送与所述段标识符相关联的一个或多个段； 被提供有信道建立信息；以及， 基于所述第一信道建立信息而在所述至少一个客户端与所述第一控制信道服务器功能之间建立流式传输控制信道，所述至少一个客户端被配置用于从所述第一控制信道服务器功能接收至少一个清单文件更新消息。
13.与用于实现对分段内容从所述递送节点到一个或多个客户端的流式传输的网络发起的控制的至少一个递送节点相关联的控制信道服务器功能，所述控制信道服务器功能被配置用于: 接收对于将分段内容递送到所述一个或多个客户端的至少一个请求； 生成至少清单文件，其包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息以及信道建立信息，所述一个或多个内容递送节点被配置成向所述一个或多个客户端发送与所述段标识符相关联的一个或多个段； 向所述一个或多个客户端中的至少一个发送所述第一清单文件；以及， 参与在所述至少一个客户端与所述控制信道服务器功能之间的至少第一流式传输控制信道的建立，所述建立基于所述信道建立信息；以及，可选地，所述控制信道服务器功能还被配置用于生成清单文件更新消息和/或用于经由所述第一流式传输控制信道向所述客户端发送所述消息。
14.根据权利要求13的控制信道服务器功能，其中生成所述至少一个清单文件包括: 提供一个或多个第一段标识符和用于定位第一内容递送网络(⑶NI)中的一个或多个内容递送节点的第一位置信息； 向第二内容递送网络请求一个或多个第二段标识符和用于定位所述第二内容递送网络(CDN2)中的一个或多个内容递送节点的第二位置信息； 分别基于所述一个或多个第一和第二段标识符以及第一和第二位置信息的至少部分而生成所述清单文件。
15.一种数据结构，优选为清单文件的至少部分，用于实现对分段内容的流式传输的网络发起的控制，所述数据结构包括一个或多个段标识符和用于定位一个或多个内容递送节点的位置信息，所述一个或多个内容递送节点被配置成向所述客户端发送与所述一个或多个段标识符相关联的一个或多个段；所述数据结构还包括所述信道建立信息的至少部分，优选地所述信道建立信息包括与包括控制信道服务器功能的网络节点相关联的位置信息，优选为一个或多个URL，所述控制信道服务器功能被配置成发起建立与所述客户端的流式传输控制信道的过程。
16.一种包括软件代码部分的计算机程序产品，所述软件代码部分被配置用于当运行在计算机的存储器中时，执行根据权利要求1-11中的任一项的方法步骤。
【文档编号】H04L29/06GK104137505SQ201280070832
【公开日】2014年11月5日 申请日期:2012年12月27日 优先权日:2011年12月29日
【发明者】R.范布兰登伯格, O.A.尼亚穆特, M.O.范德文特 申请人:皇家Kpn公司, 荷兰应用自然科学研究组织
最新回复(0)