CN105340284B - 在内容递送网络中从源向目的地递送内容的方法 - Google Patents
在内容递送网络中从源向目的地递送内容的方法 Download PDFInfo
- Publication number
- CN105340284B CN105340284B CN201480036517.4A CN201480036517A CN105340284B CN 105340284 B CN105340284 B CN 105340284B CN 201480036517 A CN201480036517 A CN 201480036517A CN 105340284 B CN105340284 B CN 105340284B
- Authority
- CN
- China
- Prior art keywords
- content
- multicast
- stream
- host
- time
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/64—Addressing
- H04N21/6405—Multicasting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/242—Synchronization processes, e.g. processing of PCR [Program Clock References]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
- H04N21/25808—Management of client data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
- H04N21/25808—Management of client data
- H04N21/25841—Management of client data involving the geographical location of the client
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
- H04N21/47208—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting near-video-on-demand content
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/64—Addressing
- H04N21/6408—Unicasting
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Computer Graphics (AREA)
- Human Computer Interaction (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Information Transfer Between Computers (AREA)
Abstract
在内容递送网络中从源向目的地递送内容的方法。描述了用于在网络(具体地为组播网络)中分发内容的方法和系统。一种方法包括在内容递送网络中从源向目的地递送内容。接收对于一项内容的请求并且标识或建立第一组播流,该第一组播流包括所述内容的第一副本。还标识或建立至少一条第二组播流,该第二流包括所述内容的第二副本。所述内容的所述第二副本从所述内容的所述第一副本的对应部分时移了时间M。然后使用所述第一组播流和所述第二组播流二者将所述内容递送到所述目的地。
Description
技术领域
本系统涉及在网络中分发内容,在特定实施方式中,涉及在组播网络中分发点播内容。
背景技术
将大量的数据递送给多个用户或终端主机能够对网络强加显著负担。数据能够通过网络广播并由对获得该数据感兴趣的接收方拾取。然而,可能存在没有希望获得数据的接收方的网络的全部段,所以将数据广播到这些网络部分浪费网络带宽。另选的方法是使用单播方法来向仅已请求数据的那些用户直接发送数据。然而,这可能导致大量复制的内容通过网络发送,这再次可能引起网络的拥塞并影响在网络中发送的其它数据的可靠性和服务质量(QoS)。
组播技术能够被用来通过确保内容在网络中不被复制直至到其预定目的地的路径在网络拓扑中分离为止来在网络中更有效地分发内容。
然而,点播内容的递送提出特定问题,因为多个用户可以在不同的时间请求相同内容并且各个用户可能希望在媒体的重放期间暂停或倒回内容流。通过单播递送这种点播内容使得用户能够在任何时间开始查看流并且能够暂停和倒回流。然而,所有内容的单播在大多数网络中是不合需要的,因为它导致通过网络发送的内容的显著复制并消耗大量的网络带宽。
在使用组播递送技术来向多个终端主机递送点播内容时存在困难;例如,不能够为希望在后面的阶段加入流的单个用户暂停或倒回组播流,在摄取点播内容时情况可能是这样的。这可能导致新主机不得不为内容建立单播流并接收内容的单播流,而不论组播流从该条内容开始可能在时间上提前多少。
发明内容
在另一方面,提供了一种在内容递送网络中从源向至少一个目的地分发内容的方法,该方法包括以下步骤:
处理所述内容以生成用于传送所述内容的多条组播流,其中,所述内容的至少一部分由所述组播流中的多于一条组播流递送;
确定在不同的组播流中的所述内容的相同部分的传送之间的相对时移M;
处理所述多条组播流以实现在所述多条组播流中的所述内容的相同部分的传送之间的所述相对时移M;以及
使用所述组播流的子集来向所述目的地传送所述内容,其中,所述子集包括所述多条组播流中的所选择的至少两条组播流。
因此,所述方法能够实现在其之间具有所选择的时移的多条时移组播流的生成,这能够提供在网络中递送内容的有效方式。单个目的地加入多条组播流以使得内容被更快速地递送。
可选地,由在网络中或在源处实现的内容递送管理装置选择多条组播流中的所选择的组播流。因此,在网络中而非源处的组件选择用于递送内容的流。这能够使得网络能够控制内容如何被递送到目的地,使得网络组件能够管理在网络中的组播树的生长,并且在确定哪些流被用来递送内容时考虑诸如网络拥塞和拓扑信息这样的因素。
可选地,每一条组播流被配置为递送基本上全部内容。因此,单个组播流将足以接收内容,然而,使用多条流来递送同一条内容提供诸如本文所描述的那些优点。然而,本领域技术人员将理解的是,对于所选择的流,可能不必递送全部内容。例如,如果确定组播流是需要的,则所述流可以在进入内容半小时时开始。
如下面更加详细地描述的,时延M将取决于由网络确定的一个或更多个因素。然而,根据系统的要求和被递送的一条内容的长度,M可选地为若干分钟的量级。M可以为大约10分钟或30分钟。M可选地小于1个小时。
在一个实施方式中,在每一条组播流之间,相对时延M是相同的。因此,组播流可以以规则并且周期性的方式交错。
在一些实施方式中,在第一组播流和第二组播流之间的相对时延M1不同于在第二组播流和第三组播流之间的相对时延M2。例如,当对于一条内容的请求以高速率接收时,在不同的组播流之间的延迟可以是短的,例如,大约5分钟,使得若干条不同的组播流可用于递送内容。然而,当请求减慢时,在组播流之间的延迟可以被扩展,例如,扩展到大约半个小时,以提供多组播递送,但是递送给更少的目的地。
在一些实施方式中,基于所述至少一个目的地的缓冲容量和/或目的地能够同时接收的流的数量的确定而确定时延M、M1或M2。例如,如果目的地能够加入用于单条内容的三条组播流并且具有能够存储达1个小时的内容的缓冲,则目的地被指示加入的所述三条组播流能够在进入内容0分钟、30分钟和1个小时处开始。
所述至少一个目的地可以包括多个目的地,并且所述时延然后可以基于具有最小缓冲容量的目的地的缓冲容量、目的地的平均缓冲容量或目的地的模式缓冲容量而确定。
在一些实施方式中,基于对于内容的被预测的请求的模型而确定时延M、M1或M2。
可选地,被预测的请求的模型确定在后续时间段上的对于内容的请求的期望数量或期望速率。
进一步可选地,被预测的请求的模型确定在后续时间段上的请求的期望地理或拓扑分布。
在一些实施方式中,基于在前面时间段期间的对于内容的请求的速率而确定时延M、M1或M2。如上所述,当请求被以高速率接收时,在其之间具有更小的时延的更多的组播内容流可以被创建。
在一些实施方式中,基于在所述源和所述至少一个目的地之间的网络容量或可用性的量度而确定时延M、M1或M2。
可选地,基于上面提出的因素的组合而确定时延M。
在具体的实施方式中,所述方法还包括以下步骤:从目的地接收对于所述内容的请求;标识用于传送所述内容到目的地的组播流的子集;以及生成单播流,所述单播流用于向目的地传送所述内容的在所述组播流中不可用的一部分。具体地,如果多播流全部都已经在一定程度上进入内容,则通过传送所述内容的开始部分,向特定目的地传送的单播流可以补充组播流。
上面已经描述了本系统的实施方式的许多方面。对于本领域技术人员而言将清楚的是,可以独立地实现这些方面中的每一个。然而,这些方面可选地作为更大系统的一部分彼此相结合地实现以提供多个优点。一个方面的特征可以直接应用于本系统的其它方面。此外,方法特征可以直接应用于设备的各方面。
具体地,在以上所描述的所有方面中,在组播网络中,所述目的地可以是主机或主机指定路由器H-DR。所述主机可以是与所述内容的终端用户或消费者相关联的终端用户终端,或者可以是向用户的装置供应所述内容的中间装置。例如,所述目的地可以是家庭网络内的接收所述内容以用于流式传输到用户的终端(诸如连接互联网的电视、计算机、平板电脑或电话)的集线器。
类似地,在以上所描述的所有方面中,所述源可以是在所述网络中供应所述内容的装置,或者可以是所述网络中的处理内容到目的地的路由的智能路由组件。所述内容可以通过所述智能路由组件,或者所述组件可以控制所述网络中的其它组件(诸如源),以实现本文所描述的方法。
此外,在以上所陈述的所有方面中,所述内容可选地是视频内容和/或音频内容,具体地为响应于来自用户的请求而递送的点播内容。然而,技术人员应当了解,本文所描述的系统和方法能够同样地应用于用于分发数据(诸如文本或图像数据)或软件的网络。
附图说明
现在将参照附图更详细地描述本系统的实施方式,附图中:
图1是可以实现本系统的各方面的示例网络的示意图;
图2示意性地例示了根据一个实施方式的多个时间延迟的组播流;
图3是根据一个实施方式的在接收主机处缓冲的组播流的示意图;
图4是根据一个实施方式的触发时间交错的组播内容流的方法的示意图;
图5a例示了根据一个实施方式的潜在树分发拓扑;
图5b例示了根据另一实施方式的潜在树分发拓扑。
具体实施方式
如以上所陈述的,本文所描述的系统的各方面为同一条内容创建多个时间交错的组播流。在一些实施方式中,源使用智能数据分析来决定哪些主机应该订阅那些(一条或更多条)组播流中的哪些。源然后能够触发主机订阅所选择的流。主机重新组装从不同的起始点提供数据的多条流,并且一旦它们不再从组播树接收未复制的内容就离开所述组播树。这影响主机与组成员关系,并且还通过针对一条内容使网络中的单播流的数量最小化来导致对网络资源的更好使用。现在更详细地描述以上所陈述的元素中的每一个的实施方式,但是首先描述可以实现本系统的网络的实施方式。
在以下描述中,以下术语可以被使用并取本技术领域的技术人员将知道的普通含义。具体地:
主机:从源请求能够通过单播或组播递送的一些内容的终端用户或目的地。
源:经由单播向主机发送或者经由组播将其推送到网络中的内容的提供方。
内容:电子媒体,包括但不限于视频文件/流、线性TV、音频文件/流(会议、无线电、播客)、大文件下载等。
DR:指定路由器。
在图1中示意性地例示了可以实现本系统的各方面的网络800。组播网络能够被用来从多个内容服务器或源810、812、814中的一个向多个目的地或主机816、818、820中的每一个递送内容,诸如视频点播内容。能够将组播网络在概念上划分为两段,其中一段826包括主机和相邻路由器822、824,其使用诸如互联网组管理协议(IGMP)的协议进行通信以建立并管理主机的组播组成员关系。在IPv6网络中,网络的这个段使用组播侦听者发现(MLD)和ICMPv6(互联网控制消息协议)消息传送来操作,并且本文对IGMP和其它IPv4协议的参照旨在包括并包含等效的IPv6协议。
组播网络的另一概念性段828通常使用诸如通常为稀疏模式协议无关组播(PIM-SM)的协议,以在网络的其余部分中路由并实现从源810、812、814到与主机相邻的路由器822、824的组播。具体地,技术人员将知道的PIM-SM或类似的协议被用来管理路由器与在网络中订阅内容源的组播组的成员关系。
图1例示了包括多个源810、812、814(其中的每一个能够经由网络向主机816、818、820提供或供应内容)的组播网络800。这些源连接至源指定路由器(S-DR)830、832,其管理内容从源到网络中的组件的递送。
网络还包括将组播流(以及其它网络业务)从源810、812、814携带到主机816、818、820的许多中间路由器IR 836、838。这些IR可以包括用于特定组播流的一个或更多个汇聚点(RP)834。RP 834是网络中的针对特定组的组播数据用来传递到所有下游路由器的路由器,除非该下游路由器处于源特定模式。也就是说,下游路由器或主机824、818通过RP 834加入组播流。因此,下游组播树集中在RP 834上。
最靠近主机或目的地的路由器能够被称为主机指定路由器(H-DR)822、824。去往特定主机816的组播流通过所关联的H-DR 822,并且该主机使用IGMP来向其H-DR发送用于加入(join)特定组播组或从特定组播组中剪枝(prune)的请求。
通过另一示例,在组播组G中组播内容的源812在整个网络上广播针对该内容的通告消息。主机H2 818接收通告并希望接收组播数据。主机818向其H-DR 824发送指定它希望加入的组播流的组播地址的IGMP Join请求(如通告消息中所详述的)以及其成员关系信息。H-DR 824通常基于针对内容的通过网络回到S-DR 830的最短路径来构建回到内容的源812的组播树。然而,在大多数操作模式下,组播树也对于该组播流必须通过所指定的RP834,而不通过其它IR 838,即使其它IR 838将提供回到S-DR 830的更短路径。H-DR 824针对具有活动下游成员的各个组朝组特定RP 834发送周期性Join/Prune消息。
如果组播树已经在向其它主机递送内容,则H-DR 824简单地构建回到现有组播树的分支。如果主机是在网络的该区域中请求内容的第一个,则可以构建回到S-DR 830的树。组播树在图1中由虚线840指示。一旦已构建了组播树,就能够沿着树向H-DR 824并从那里向请求主机818递送组播内容。
在基于PIM-SM的组播系统中,当主机指定路由器(主机-DR)从其主机中的一个接收到用于加入组G的成员关系报告时,它使用其单播协议来查找作为朝RP的最短路径(汇聚点树,RPT)或朝源的最短路径(最短路径树,SPT)上的下一跳的邻居的地址。当中间路由器从具有相同请求的下游路由器接收到Join/Prune消息时执行相同动作。它们使用单播协议的路由度量作为MRIB路由度量,其与反映用来学习到这个成本的方法的度量偏好关联(即,各个单播协议具有关联的度量偏好值并且仅能够在度量偏好值相同的情况下比较度量成本)。具有最低成本的下一跳邻居被选为Join/Prune消息被发送到的上游邻居。Join/Prune消息随着它一直行进到RP或源而触发在各个路由器中创建组相关的路由条目。被构建到RP或源的这个反向路由被用来在从RP或源到终端主机的下游方向上路由组播数据分组的流。
组播树840上的各个路由器在诸如组播路由信息库(MRIB)的内部数据库内维护路由条目,所述路由条目包括诸如源地址、组地址、接收到分组的传入接口以及应该发送分组以便沿组播树向前发送的传出接口的列表这样的信息。还可以在MRIB条目中存储定时器、标志位和其它信息。
为了离开组播组G,主机818向H-DR 824发送Prune(剪枝)请求,其然后通过组播树向上传播以拆除该树直到需要树将组播数据递送到其它主机的点的那条分支。
在诸如图1所示的网络这样的网络中,第一主机H1可以在时间T处请求单条内容。这个内容由源S发起,所述源S连接至在网络中操作PIM-SM或等效的组播路由协议的源指定路由器(源-DR或S-DR)。这些主机将IGMP或类似物用于成员关系管理。内容流本身持续X分钟,并且当会话结束时的将来时间T+X可以被称作T1。该条内容可以是已受到欢迎并且现在由多个用户以各个请求之间的相对较短的时间间隔所请求的新闻项或电影。如果为第一用户开始了组播流,则预期多个其它用户加入到这个组以观看此内容,不能够停止或暂停它以便各个新主机追赶到最远点。这导致组播对于这个场景来说不是可能的。然而,本文描述了一种触发多个时间交错的组播流以将一条内容散布到多个主机、从而从在时间T处请求的第一流位置(即开头)开始流的方法。在后面的时间点处,各个组播树将服务所有这些主机的子集,但是这个组中的各个主机成员实际上可能正在放出流本身中的不同点。在PIM-SM的情况下,我们将这个称作“追赶”能力,由源或其进入网络的接口(诸如源-DR)提供。可以将智能部署在源或其接口中以及还在这个组的主机中。源决定主机订阅一条或更多条组播流中的哪些,并且能够使用单播流协议请求将这个传送回到主机。
本系统的单个主机能够在不同接口上同时接收多条组播流,全部通过上层协议来缓冲并重新组装。各条组播流将同时递送来自同一条流但是来自视频中的不同点的内容,例如如图2所例示的,一条流可能已在时间T处从开头开始了,下一条流在T+N处开始,并且另一条流在T+M(其迟于时间T+N)处开始。它们全部从内容的开头开始并将各自持续X分钟。用户在时间T+U处加入,其中U>M>N。源请求这个主机订阅所有流S(T)、S(T+N)和S(T+M),并且这个成员关系是成功的。主机现在开始在它开始缓冲的不同接口上同时接收三条流。
在T处开始的流(流S(T))将是通过视频最远的,同时在T+N处开始的流(流S(T+N))落后N分钟并且最后流S(T+M)从T落后M分钟。这意味着主机随着它接收到这个内容而缓冲它,并且从最终递送或输出已经通过另一条流递送的内容的这些流中剪枝(删去)。例如,在接收流S(T+N)达N分钟之后,这条流将开始递送已经在S(T)开始时N分钟以前接收到的分组。类似地,在时间M-N之后,流S(T+M)将开始递送已经分别从S(T+N)和S(T)起(M-N)分钟和M分钟以前接收到的分组。这意味着在时间T+N处,主机能够离开递送流S(T+M)的组,并且在时间T+M处,主机能够离开递送流S(T+N)的组。在时间上最近(在这种情况下为在T+M处)开始的组播流是被首先剪枝的流,因为前面的流已经在其开始时递送了相关分组。然而,从将不通过现有组播流S(T)、S(T+N)或S(T+M)中的任一个递送的内容开始仍然存在持续时间(U-M),因为它们全部在时间T+U之前从开头开始。最靠近视频的开始的流S(T+M)从放映开始将是(U-M)分钟。因此,从视频开始到进入流(U-M)分钟对应的分组通过单播发送到主机,因为它们在任何其它组播流上不可用。
在图2中,流210是在主机处向用户输出的流。在这条流上方提供了从中获得内容的各个特定部分的源流的指示。然而,技术人员应当了解,当内容的源从一条流改变到另一条流时,内容被无缝地输出给用户,而没有任何停顿或明显变化。
图3是被缓冲以便由接收主机输出的流的示意例示。当用户请求内容时从不同的流各自接收到段A1、A2、A3和A4。在时间U处从主机接收到对于内容的请求。时间长度为U-M的段A1被单播到主机,因为在接收到请求时所有的组播流已经通过内容中的这个点。在主机正在接收单播段A1的同时从流S(T+M)接收长度为M-N的段A2。段A2因此被主机缓冲直到被播放给用户的A1已结束为止,并且A2然后被输出给用户。与段A1和段A2的接收同时从流S(T+N)接收长度为T-N分钟的段A3。段A3因此也被缓冲以用于输出直到A1和A2已被输出为止。与段A1、A2和A3基本上同时地从组播流S(T)接收段A4的开头。段A4在段A1、A2和A3之后被接收和缓冲并输出给用户。然而,因为在这个示例中没有更多的组播流,所以主机将继续接收流S(T)并将继续输出段A4,直到它到达内容的终点为止。
对于本领域技术人员而言将清楚的是,可以根据系统的要求和能力并且基于下面所陈述的准则和技术考虑中的一些来修改和改变以上给出的示例。例如,各个主机可以能够接收并缓冲超过或少于4条流,或者网络可以将单条内容的可用流的数量限制为少于4。
本系统的实施方式可以包括以下特征中的一些或全部:首先,终端主机应该被布置为缓冲所需数量的分组,在这种情况下进入流最多M分钟;其次,可以在源与主机之间设置通信机制;第三,源能够被布置为管理何时对于同一条内容触发新组播流;第四,源能够被布置为确定主机必须订阅多少组播流和哪些组播流,这可以使用预测数据分析能力来实现并且可以考虑主机的数据递送容量(是否存在同时支持内容的四条流(3条来自组播,1条来自单播)的链路或者用户是否愿意等待递送这些分组花费的时间);以及第五,如上所述终端主机能够被布置为控制何时剪枝给定的组播树。可以独立地提供这些元素中的每一个,并且在本文中单独地对各个元素进行描述。然而,这些元素可以彼此相结合地实现以提供还如本文所描述的组播系统和方法。
源和主机可以实现用于通信的协议。实时流协议RTSP、超文本传输协议HTTP或类似物能够被用于此目的。当主机在RTSP建立消息中发送对于给定的统一资源标识符URI的请求时,源或其进入网络的代理/接口能够利用重定向响应来发出组播流的新URI。另选地,源能够使用Set_Parameter、Get_Parameter或Announce的组合来在会话期间将这个改变从媒体服务器发布到主机,以触发主机迁移到另一组。在HTTP中,能够在使用HTTP刷新报头的URI重定向方法中将供替换的组播URI的通信从媒体服务器传递到主机。能够为其它协议栈设计类似的方法。另选地,能够部署执行所有上述任务并向源和主机二者传送动作的外部实体。这是使用集中式而不是分布式智能实体的相同技术的另一实施方式。
不将智能部署在媒体服务器(即数据源)上而是替代地靠近它部署也是可能的。可以在媒体服务器是难以接近的(例如由内容提供方控制)的情况下实现这种实施方式,在此情况下网络运营商能够将接口部署到处理本文所描述的任务并作为对源具有这种扩展能力的代理的源中。在PIM-SM的情况下,这可能是作为源的第一跳的路由器,即源-DR。为了今后易于参照,我们将假定在源端处的智能被部署在源本身处。这些变化被包含在权利要求中。
现在描述用于触发多条时间交错的流的方法。如下面所陈述的,存在针对应该如何并何时触发这些组播流的许多选择。在下面所描述的方法中,为同一条点播内容创建多条组播流,使得如果大主机组将在不同的时间请求这个内容,则这个主机组的不同子集能够根据它们的能力和预测到的网络性能被请求订阅一条或更多条组播流。不能够通过组播覆盖的单独变化然后能够根据它们的能力像以上所描述的那样被单播到主机。
因为每个组播流本质上是在网络中的内容的时间交错的复制,所以人们不希望在能够避免这个时生成这些流。因此,能够利用一些智能选择性地做出何时触发新组播流的决定。以下方法尽管被独立地描述,但是可以在不同的时间被实现在在同一系统中或者可以彼此相结合地实现,所以例如如果尚未通过实现第二方法的算法触发流,则可以根据第一描述的方法每N分钟生成一条流。
第一潜在方法是以规则间隔(每N分钟)触发组播流。这是周期性的并且可能不是自适应的。
在第二方法中,考虑请求主机的能力触发流。在各个间隔(间隔(M))之间,主机组随着主机加入和离开组而经历变化。这意味着如果各个主机订阅一条或更多条并行但时间交错的流,则间隔能够被选择为使得大多数主机能够缓冲在该时段内所需的分组。
例如,根据主机组在给定评估时段下的分布,90%的主机可能能够总共保持2小时的内容。如果大多数主机订阅了3条并行时间交错的组播流,则必须选择3条流之间的间隔,使得到前2个小时结束时,由于缓冲溢出而不丢弃来自最旧流的数据。除主机订阅的流的数量以及主机针对这种数据速率的缓冲容量(能够被缓冲的放出的最大时间)之外,算法还能够考虑分组被媒体播放器消耗的速率。如果主机仅能够总共缓冲2小时的内容,则假定这个主机订阅已被生成直到它加入为止的各条流,则这些流的周期性必须是这样的,即,在2小时内,所有流尚未递送比能够由播放器消耗更多的数据。如果这些流之间的间隔太大,则主机的缓冲容量将不足以订阅流并缓冲所有接收到的内容,以在将追赶提供给组播流的单播流首先已被放出之后的后面的时间放出。将丢弃组播流中的后面的分组,这意味着间隙存在于放出中并且必须被以差放出质量填充或者重新请求所丢弃的数据块。已经针对单个主机对此进行了说明—给定的一条内容的总间隔(M)能够从组中的所有主机的分布得到并且选择间隔使得大多数主机能够受益于多条流。
在第三方法中,还能够基于预测到的摄取模式来生成新流。例如,如果运营商知道大多数消费者在晚上观看内容(例如电影),则可以不足以在白天期间触发流,因为摄取将是最小的。
组播流的预测触发的另一示例如下。如果源监测到小型网络的20个主机中的11个主机已在前面的时间段(比如说15分钟)内请求了一条内容,则对于持续两小时的内容,它能够基于这个网络中的更多主机还可能请求相同数据的预测来触发在第12个主机的加入时从开头开始的组播流。所述方法是预测的并且不作用以使现有单播流合并,而是替代地利用追赶使将来单播流的数量最小化为单个组播流。
第四方法是针对单独的主机从利用追赶使现有多条紧密间隔开的单播流合并到单条组播流中来应用的。另选地,能够追溯地触发组播流,以从先前时间点放出。在来自方法3的示例中,在进入流最远点处开始的组播流即在作为第一主机将在流中的地方的15分钟处被创建,以一直运行到终点并且对于剩余主机触发追赶协议。此结果是在最多15分钟之后,所有单播追赶将完成,已经避免了数据通过10个不必要的单播流的复制,并且所有前11个主机将放出从组播流开始接收到的存储在缓冲器中的内容。在例示了各自接收到相同内容的四个主机H1、H2、H3和H4的图4中进一步对此进行说明。
主机H4进入流最远(即它是已请求内容的第一主机)。因此组播流在这个点(即,进入内容15分钟)处开始,并且其它3个主机H1、H2和H3使用单播追赶到这个点,以随着组播流被递送和缓冲以用于重放时填充它们的缓冲器。当播放器放出经缓冲的分组并最终到达进入视频15分钟时,播放器更远地移动到流中,在那里它将开始放出通过组播递送的内容。类似地,为了所有主机更快地加入被递送给H4的流,可以例如在主机H3已在内容中到达的点(进入内容12分钟)处建立第二临时组播流。因此可以向H1、H2和H3同时递送12至15分钟,并且这个组播流可以由这些主机在15分钟处剪枝,因为这些主机将已经从被递送给H4的流接收到向前15分钟的流。因此,可以追溯地生成多条时间交错的组播流。
能够使用以上所描述的四种决定方法中的一种来生成任何数量的组播流。另选地,有经验的用户能够设计何时在第一组播流之后触发新组播流(若有的话)的算法。
一旦已经确定应该如以上所描述的那样触发组播流并且已经计算出它们之间的时间间隔,就触发新流并且在下面描述用于做这个的一种方法。
用于触发新流的决定存在于源或其进入网络的代理处(具体地在源难以接近这里所描述的组播使能器的情况下)。假定PIM-SM作为组播路由协议是适当的,为了使得能实现新组播流,应该在源处创建针对这条流的会话描述文件,并且其源DR应该向汇聚点RP注册,通告其存在。
我们假定源通过从实现诸如组播地址动态客户端分配协议MADCAP的现有地址分配服务器获得组地址以及使用可用组播流中的每一个的URI将此通告给主机来控制其流的成员关系。为了简单,我们在源流与组地址之间假定1对1映射:单个组的所有成员可能从一条时间交错的流接收内容,相同的成员在它们可能接收到相同内容的另一时间交错的流的情况下也能够订阅另一组地址。另选地,将许多不同的内容流的组合映射到组地址也是可能的。可以与本系统相结合地实现这种动态地址分配。然而,因为我们仅考虑一条内容的时间交错的版本,所以我们假定组地址到时间交错的内容流的简单1:1分配策略。
源使用诸如RTSP的Announce、Redirect、Get/Set_Parameter消息这样的实时流协议来将其新URI传送到请求主机。另选地,HTTP流可以是适当的或任何其它专有协议栈。主机然后将新URI分解为由源分配的流并且向其指定路由器(DR)发送其IGMP Join(非请求成员关系报告)。这个请求使用现有的树构建方法来朝RP或源逐跳行进,随后创建组播树分支并且在主机处下游接收内容。
上述方法中的每一个能够被用作用于触发新组播流的条件。能够使用它们中的任一个或组合。还能够在追赶场景外使用它们,例如以在可能时根据应用处理固定实况数据流并减少单播数据复制。触发多条组播流的方法是能够感知为内容发布幕后的方法的独立实体,而不论内容如何由主机组订阅。以上所描述的示例说明了在固定流场景中以及在灵活流场景中触发多条时间交错的流时部署这种智能的优点。在灵活流的情况下,如果被接收到的组播内容中的当前播放时间是在将来,则主机必须缓冲这个内容(如果追赶是可适用的话)并且由媒体服务器在它单播追赶到组播已开始的点之后按需放出所述内容。在网络域外面用于在纯粹发布模型(无追赶)中应用这个系统的示例是影响航班娱乐的广播。内容广播内的另一示例是使用这个方法来影响重复放映的滞后时间,例如频道4+1可以是频道4+20分钟。
对于以下描述的剩余部分,不管从上文使用的方法,假定了决定方法学的结果是这样的,即,3条流已被触发:在时间T、T+N和T+M处的S(T)、S(T+N)和S(T+M),其中M≥N并且S(T)将在任一个时间进入内容最远。在这个示例中,N和M是表示决定算法在间隔(M)内的计算结果的变量。
本文所描述的方法中的下一个步骤是紧跟用于接收一条特定点播内容的请求之后决定哪一个主机将订阅可用组播流中的哪一条。下面描述的是能够被考虑来进行分配的因素和选项。
注意,内容发布模型不必是如以上针对要应用的这个方法所规定的。考虑到下面所说明的各种因素,这是能够针对给定的发布模式来管理用于主机组的订阅模式的独立订阅模型系统。在下面所描述的示例中,我们假定单条内容存在使用准则的任何集合生成的许多时间交错的可用流。
网络被划分为两种类型:网络足够小以致各种组播树交叠或者共享公共链路的一种类型以及树本身相对稀疏并且潜在地在地理上跨越网络分布的另一种类型。这个的示例在图5中被示出。下面所陈述的最后方法最适合于后者。被使用的方法还可能取决于由运营商采取的方法。
注意,在一些实施方式中,源维护各条组播流进入视频的当前时间位置以及哪些用户在哪一条流上的映射的表。这个表在一些实施方式中能够如下表所陈述的那样被实现,下表示出了由源针对各个可用组播流维护的简单表。
注意,这与不必知道给定组的所有主机的传统方法不同。缺乏这个知识还暗示缺乏当前树结构的知识。这个信息在它可能的情况下能够被收集。如果存在在网络中按照仍然可从数据得到更通用的树结构的方式聚合成员关系的方法,则能够替代地使用这个。如果这个是适当的,则还能够从IGMP侦听装置而不是主机-DR收集数据。如果不在收集组成员关系信息,则以下方法中的一些在一些网络中可能不是可能的。
注意,在以下场景中,源确保主机具有链路容量和缓冲容量二者来接收许多流并存储它们直到放出为止。如果单条内容流被以2Mbps的数据数率发送并且主机的最后一跳仅能够支持2.5Mbps的最大速率(其中500Mbps被保留用于其它业务),则除非带宽共享技术被强加于递送给这个主机的各条流并且使视频开始的分组被主机优先处理,否则这个主机仅能够支持为了迅速放出应该提供视频的开头的一个组播频道。如果到主机的链路具有FTTC(光纤到路边)(下游≈60Mbps),则可用数据速率将高很多并且可能存在到这个主机的许多数据流。我们在我们的描述中假定链路容量不受限制。然而,应用能够触发成员关系的组播会话的数量可以根据链路容量的可用性而受限制。
在第一方法中,源试图向主机同时递送尽可能多的数据。源因此请求主机订阅尽可能多的可用流,在这种情况下为S(T)、S(T+N)和S(T+M)。源必须验证主机具有足够的缓冲容量来容纳这个,使得到媒体播放器已放出直到最旧流(S(T))开始为止的点时,仍然能够存储在S(T)上递送的最后分组。否则,S(T)的最近分组将在它们被放出之前被丢弃,因为缓冲器填满尚未被消耗的分组并且不能够存储S(T)的最新分组。当S(T)的这个段必须被消耗时这将在媒体中导致间隙,这必须在重放期间由上层重新递送或管理。
这个方法的优点可以是网络资源被完全消耗并且下载一结束就被释放。下载一完成主机就离开所有组播组,并且重放能够在任何时间处开始。这个方法最适合于不受限的链路容量以及能够存储比视频流的持续时间长的缓冲器。
在第二方法中,源能够根据它希望随着时间的推移而保留、增长或缩减哪些组来将主机分配给组。例如,如果消耗S(T)的主机的数量远超出消耗S(T+N)的主机的数量,则源可能决定随着时间的推移而缩减S(T+N)。这种行为由于组成员关系的变化的高速率而出现。如果最终终止了S(T+N)流过网络,则能够避免这个数据复制并且所有主机能够针对遗漏部分为后面的加入者(即其重放比S(T)更靠近流的开头的用户)利用单播追赶从S(T)获得它们的内容。还能够在单播追赶流与视频的总持续时间相比将不持续长持续时间的检查之后部署这个方法。例如,如果S(T)是这样的,即当前正在递送持续90分钟的视频的最后15分钟,则在它们能够从经缓冲的组播流消耗最后15分钟之前追赶在单播流时请求从开头达75分钟的视频的主机可能不值得向递送S(T)的树发送Join/Prune消息并且建立新分支的努力。这些是可以由运营商基于它们的网络资源的稀缺性做出的权衡。
第三方法从网络可靠性的观点解决组分配。例如,如果源知道关于S(T+M)的关键链路之一的计划中断,则它可能选择在中断不影响后者的情况下将主机放置在诸如S(T+N)的不同树上。另选地,评估可靠性的更复杂方法是计算针对给定树的主机成员的端到端性能度量的分布并且使用这个来确定对于给定主机在良好网络性能的最佳可能性情况下遍历树的流。这个方法未必考虑视频本身的位置以及单播段与组播段在递送的视频中的比例,但是更聚中于以最小分组损失、抖动和延迟给用户可靠体验。还能够扩展这个方法,使得源使用可预测模型来计算树或分支的性能(如果新主机的端到端路径是从单播协议中知道的)并且为给定主机做出最优树选择。我们早前的发明描述了用于考虑来针对给定会话要求评估给定路由的网络性能的方法和因素。我们采用这个能力来计算每个树的聚合网络性能度量以决定树分配以便主机接收所需的内容。
第四方法在通过网络的清晰部分严密地扩展各个组的网络中最适合。在图5中例示了这种网络的潜在结构。这种网络因为请求内容的主机的物理位置而出现。最左边的主机可能在S(T)上,然而中间树上的主机可能正在接收S(T+M)并且右边的主机可能接收S(T+N)。当然,组播树的这种十分明显的划界在真实网络中可能不发生,但是如果网络的三个部分中的每一个对于其本地主机集合表现最好但是对于在与树相距大量跳处的主机展现差网络递送性能则存在这种可能性。例如,到左边的主机组的S(T)树递送可能比使一个树分支一直向下游流到可能由S(T+N)更好地服务的在网络右侧的主机的子网的树具有更好的性能。这在对于S(T+M)支持树的网络正在遭受由于其它服务导致的拥塞的情况下特别加重。在这种场景中,运营商能够决定做出到主机集合的跳数与该主机集合所期望的性能成反比的假定,即,跳数越大,端到端性能越差。这种方法还适合这样的网络:运营商不希望具有从组播树通过网络展开的多个树分支,从而通过并行链路来增加数据复制并且将替代地更喜欢具有深入到网络中的更窄树。
主机的地理位置因此能够被用来选择为该条内容分配那些组播流。在上面的简单示例中,右边的主机更可能成为接收S(T+N)的组的成员,因为其RP和所对应的树最靠近它。
用于计算这个的技术是对从主机到必需从中选择的各个树的最少跳数进行比较并挑选具有最短路径的树。
在第五方法中,将主机分配给流组合上述决定方法中的一个或更多个。例如,源可能将主机分配给S(T+N)并单播N分钟的视频,因为其缓冲容量仅能够支持N分钟的这种视频(假定以递送分组的速率即时重放)。如果知道在递送S(T+M)的树中由于拥塞而影响网络性能问题,则即使在S(T+M)中使视频的单播段最小化了,也可能优于S(T+M)而选择S(T+N)。在另一示例中,主机可能被分配了最靠近其地理位置的组以便避免遍历具有拥塞的网络的一部分。网络运营商能够按任何优先顺序使用上述考虑事项中的任一个或全部(降低网络负荷、组管理策略、网络资源可靠性或基于地理位置的分配)。如果加权因数被分配给这些因素中的每一个,则能够针对各个树每主机组合计算聚合度量,并且具有最佳度量值的树能够被选择并传送到主机以触发成员关系。
一旦已经选择了主机应该订阅的流,源就能够使用单播流协议消息来传送要由主机媒体播放器使用的URI的列表。虽然在本文中描述了多个URI方案,但是其它方法可以代替这个来将组地址传送到主机,所述主机使用该组地址来成为这个组的成员以接收单个时间交错的组播流。在具有组地址后,上层协议将JoinHostGroup请求传递到IP层。IGMP成员关系由用于组播的扩展IP模块(上层协议与IP交互和IGMP扩展)来管理。IGMP然后被用来向主机的具有组播地址的DR发送主机希望订阅的IGMP非请求成员关系报告。主机-DR然后使用这个信息来构造到针对这个组的主机-DR的组播树分支。成员关系可以是(*,G)或(S,G)状态,并且如RFC4601和RFC 2362所说明的那样完成组播路由。
主机还使用RTSP/RTP/RTCP(或等效的)会话来接收单播流以覆盖它期望的内容持续时间。这些流协议本身(包括用于从特位置置请求流的方法的)是现有技术。上面已经说明了当在缓冲器中发生数据复制时主机逐渐剪枝多条组播流的方法。上层协议向IGMP模块发送LeaveHostGroup请求,所述IGMP模块然后向主机-DR发送LeaveGroup请求(或者静静地等待其成员关系超时)。这导致从主机-DR朝组播源或RP发送Join/Prune消息,从而清除相关的(*,G)、(S,G)或(*,*,RP)状态。对于这个组/源来说不再接收组播数据,即主机停止接收时间交错的内容的这条流。注意,这个离开处理由订阅了相同视频的多个时间交错的副本的主机来实现,使得在主机已经具有所需的分组序列的情况下避免不必要的网络使用。
假定了主机具有通过一个或更多个组成员关系来同时接收多条组播流/会话的能力。主机还应该能够处理来自多条流的分组在其用于重放的缓冲器中按时间顺序到正确的视频内容的重新组装,即主机应用使用在分组上标记的流中的位置以及给定组播流(S(T)、S(T+N)等)的开始时间,以将同时输入重新组装为正确顺序以得到正确的视频(如果存在诸如两个不同TV节目的正被下载的超过一条内容,则各自使用一个或更多条时间交错的组播流来下载)。这涉及知道图3中的单播流以及组播流S(T)、S(T+N)、S(T+M)在缓冲器中的开始位置以及在重放之前按正确顺序重新布置分组。
还注意,在一些实施方式中能够将现有的组播组订户迁移到不同的组播组(例如,从S(T+N)到S(T))并且从主机触发针对N分钟视频的追赶(RTSP或类似的)单播会话。组播组选择不限于在主机的请求的开始,而是也能够在流期间被执行。这例如在用户希望在重放期间暂停或倒回流的情况下或者在需要在网络中重新配置组播流的情况下可能是有用的。
现在更详细地陈述根据一个实施方式的本系统的操作的示例,从而说明系统触发多条流的能力。
假定这个示例中的内容流具有2Mbps的数据速率。假定有20个元件的已知网络的90%的主机具有存储1GB的缓冲容量(刚好超过1小时的此内容)。我们假定内容持续115分钟。
源现在需要决定是否并且多久触发新组播流。
源基于以下准则进行优化:
1.流过网络的时间交错的组播流的总数。例如,S(T)、S(T+N)和S(T+M)将是相同内容的3条流。网络能够利用相同内容的最大指定数量的组播流进行操作,使得使数据复制最小化。
2.用户下载这个视频的所有数据需要的最少时间。这取决于多少流是可用的以及主机的下游链路容量及其缓冲存储容量。
固定参数是:
1.主机的缓冲容量和链路容量
2.内容的数据速率
最优化是这样的,即在为流的用户生成最少数量的流的同时,各个主机能够尽可能迅速地下载内容。例如,为了让主机在一分钟内具有整条流,我们将需要创建在重复点之间具有1分钟的时间差的115条组播流。用户将需要230Mbps的下载容量。另一极端是仅生成1条流,这然后花费用户最多115分钟以2Mbps的数据速率下载(链路可能具有未使用的多余容量)。并且,在仅一条流可用的情况下,如果另一主机请求进入组播流100分钟的相同流,则单播追赶将持续最多100分钟。显然,这两个极端都是不合需要的。
我们具有以下约束:
缓冲容量:1GB
链路容量:9Mbps
组播流限制:10Mbps(即,不管组播流的数量都不允许内容提供方在任何时间通过这个网络在组播中发送超过10Mbps。这意味着这个内容能够在任何时间在2Mbps的数据速率下具有最多5条流。)
这个内容必须每小时至少一次具有一条新流。否则,大多数主机的缓冲容量是不足的。这意味着我们需要至少2条流。主机的链路容量支持4条流,其中1Mbps被保留用于其它业务。网络提供方因此决定每30分钟触发一条新流。因此,新流在释放具有0、30、60和90分钟的重放位置的内容时被触发,即,4条流在时间0处同时开始,第一条流从开始进入视频,第二条流在30分钟时进入视频等。为了与以上描述相关联,在90分钟时开始的流将是S(T),在60分钟时开始的流是S(T+N)并且在30分钟时开始进入视频的流将是S(T+M)。在这个示例中存在在0处开始的再一条流,我们称其为S(T+P),其中P>M>N。
假定每小时对于这个内容而言同等地分布的10个请求到达。这意味着我们平均每6分钟得到1个请求。平均来说,我们具有在单播上追赶的不超过5个主机,并且单播流将不比30分钟长。
然而,关于到达速率的相等分布的假定可能不成立。考虑到我们还知道关于这个内容的摄取的知识。例如,我们知道在内容变得可用之后的第一小时中平均来说每5分钟将有4个请求并且在第二小时内每12分钟有1个请求。如果我们对于4条流使用先前的重放时间,则我们能够在30分钟间隔内具有最多8条单播流。
现在我们添加另一约束:在任一时间具有少量的单播流。
为了满足这个约束,我们能够使用用户消耗信息来使4条流的开始时间偏斜,以对于后面的请求使在单播上所需的持续时间最小化。如果我们每20分钟触发一条新流(和主机在第一时和第二小时内的分布(3:1)匹配),则我们将再次在任一时间平均来说具有不超过5条单播流并且1小时的缓冲容量仍然是充足的。源在时间0处触发在0、20、40和60分钟处具有重放点的流。新流开始将不花费超过55分钟,因为一旦流在115分钟时到达终点位置我们就能够开始新流。
注意,用于触发多条流的这个发布模型从内容发布方的观点看是独立的并且不必被用于向用户分配流的订阅模型。实际上,智能是在触发多条流时部署的并且主机与这些流的成员关系完全使用不同的策略来完成。并且,注意,也能够在固定流场景中(即在没有追赶的情况下)使用触发多条流的这个方法。在这个场景中,主机仅能够从它订阅了内容的点接收内容(倒回或快进不可能)。在这种情况下,使各条流开始时间偏斜的目的然后将是利用关于主机的知识来使主机在加入组播流时在它已经开始之后平均来说将错过的内容的时续时间。
下面的示例方法说明了一条或更多条组播流到主机的分配。
假定一条内容在2Mbps的数据速率下持续115分钟并且可用流时间交错了15分钟。将存在8条同时可用的流用于主机从中选择。(对由源生成的流的数量没有限制。)
从开始请求内容的主机H1具有5Mbps的链路容量和350MB的缓冲容量(对于这个内容来说大约20分钟的存储)。这个主机不能够订阅进入视频超过15分钟的可用组播流。来自H1的请求是在由源触发的最近流S'开始后12分钟时做出的。因为它仅能够缓冲20分钟,所以H1将不得不订阅S'。它然后必须追赶12分钟的内容,首先将这个播放给用户,此后它能够重放通过组播接收到的内容。还必须在这个点处拆除(teardown)单播会话(使用RTSPTeardown或类似物),以确保它不继续从组播接收它已经具有的在前12分钟之后的数据的副本。
我们具有另一主机H2,H2具有10Mbps链路容量和1GB缓冲容量(大约1小时的这种视频)。H2在开始进入最近流(S')10分钟之后从开头请求内容。假定网络提供方的目标是在其链路和缓冲容量之下尽可能迅速地给予用户内容。因此,它请求H2订阅S'以及在S'之前30分钟(S30)、60分钟(S60)和90分钟(S90)开始的流。这意味着主机将在30分钟时段中接收到所有内容。对于内容的前10分钟还将需要来自源的单播会话。链路利用对于前10分钟来说将是10Mbps,然后降至8Mbps达15分钟,并且在流的最后5分钟内将降至6Mbps。流的任何其它组合导致较长的下载持续时间。
现在我们给出基于携带流的各种组播树的网络性能做出多条流的分配的示例。我们假定各个树仅转发一条时间交错的流,但是能够在真实生活场景中对此进行扩展。假定当前存在各自携带视频的一条时间交错的流的3个组播树。当主机H3请求单播URI时,源必须利用由源为主机选择的、将主机指向相应树的URI来应答。
源针对各个组播树计算性能分数。存在源能够被用来计算这个的许多度量。例如,显式拥塞通知、ECN通知、平均分组丢失、平均抖动、遍及所有链路的平均吞吐量、到RP的平均跳数、从请求主机到最近的组播树成员的跳数、平均端到端延迟等的变化的速率。这里被视为平均值的所有度量还可以是跨越网络的分布,这增加以下评分的复杂性但是遵循相同的原理。还可能存在表示从路由器得到的表示它们的健康状态的度量。例如,如果输出分组的数量与输入分组的数量之间的差增加,则这意味着路由器不能够以它接收分组的速率推出分组,这个值作为每个服务等级的传入分组的总数的百分比能够被用作路由器的健康状态的量度。考虑到例如检测QoS降级的方法,这些度量中的一些可以是预测的。可能存在考虑树本身的形状的其它度量并且评定一些树形状好于其它树形状。用来计算“树健康状态”分数的度量的时间集合可以是应用和运营商相关的,并且我们的以上列表仅是指示列表。
对于上述度量中的每一个,我们具有将被用来使从网络接收到的度量与它有多“好”的指示相匹配的许多质量等级。例如,针对给定服务等级的最大可接受的分组丢失可能是0.1%。因此,具有0.02%的步长大小、从0%丢失到0.1%丢失的梯度产生5个质量等级。传入度量与这个标量相匹配并且质量值被分配给它。分配给给定度量的等级的数量反映这个度量对总分数的重要性(参见下面)。我们对于我们使用来计算树健康状态分数的所有度量执行这个步骤。
对于这个示例,我们使用以下质量等级根据分组丢失、延迟和抖动来计算这个分数(等级的上界不属于该等级):
分组丢失(可接受的SLA:最大0.1%):
5:0-0.02%;4:0.02-0.04%;3:0.04-0.06%;2:0.06-0.08%;1:0.08-0.1%;其它0
抖动(可接受的SLA:最大2ms):
2:0-1ms;1:1-2ms;其它0
延迟(可接受的SLA:最大20ms):
5:0-4ms;4:4-8ms;3:8-12ms;2:12-16ms;1:16-20ms;其它0
假定针对3个可用树(将它们称作T1、T2、T3)的平均丢失、抖动和延迟的测量结果是:
T1:0.05%,1.5ms,15ms
T2:0.08%,2.0ms,18ms
T3:0.03%,1.5ms,13ms
一旦从评分卡获得了质量等级值,所有质量值的和就能够给予我们整个树健康状态的分数。
使用上述评分卡,我们对于T1获得6的分数,对于T2获得2的分数,并且对于T3获得7的分数。
我们已经构造我们的等级的方式意味着具有最高分数的树最适合于这个业务。对于主机H3我们的树选择将是T3。注意,T3将对应于特定时间交错的流。利用这种选择方法,必须将在T3上从成员关系的时间到组播流的错过时段单播到主机H3。
这个示例在关键性能指标涉及组成员关系而不是组播树的健康状态的情况下也将适用。各个源能够具有由组分数(与这里的健康状态分数类似)反映的组管理的策略,所述组分数然后能够被用来以期望的方式增长或缩减组播树的大小并且改变组播树的形状。源还能够根据针对各个现有组获得的分数来将现有组成员迁移到另选的组。
Claims (10)
1.一种在内容递送网络中从源向目的地递送内容的方法,该方法包括以下步骤:
源接收目的地对于一项内容的请求,所述目的地包括多个主机;
源针对所述多个主机中在第一时间请求所述内容的主机标识或建立包括所述内容的第一副本的第一组播流;
源针对所述多个主机中在晚于所述第一时间的时间请求所述内容的其它主机标识或建立包括所述内容的第二副本的至少一条第二组播流,所述内容的所述第二副本从所述内容的所述第一副本的对应部分时移了时间M;
生成单播流,所述单播流用于向所述目的地传送所述内容的在组播流中不可用的一部分;
使用所述第一组播流和所述第二组播流二者来将所述内容的其他部分递送到所述目的地,
其中,所述至少一条第二组播流是相对于所述第一组播流建立的临时组播流,所述至少一条第二组播流的所述内容的第二副本相对于所述第一组播流的所述内容的第一副本时移的所述时间M不是固定的,使得所述至少一条第二组播流允许所述多个主机中的所述其它主机更快地加入所述第一组播流。
2.根据权利要求1所述的方法,该方法还包括:确定针对所述内容的要求概括,以及,基于所述要求概括,推选使用多条时间交错的组播流来递送所述内容。
3.根据权利要求2所述的方法,其中,针对所述内容的所述要求概括包括以下各项中的至少一个,并且可选地包括以下各项中的多个:
在前面时间段中对于所述内容的请求的数量的量度;
对在后续时间段中对于所述内容的被期望的请求的数量的预测;
对提出请求的所述目的地在所述网络中的地理或拓扑分布的确定。
4.根据权利要求1所述的方法,其中,递送所述内容的步骤包括指导所述目的地加入所述第一组播流和所述第二组播流以接收所述内容。
5.根据权利要求1所述的方法,其中,在推选使用多条组播流来递送所述内容之前获得与所述目的地的能力相关的信息。
6.根据权利要求1所述的方法,该方法还包括标识或建立包括所述内容的第三副本的第三组播流,所述内容的所述第三副本从所述内容的所述第一副本的对应部分时移了时间N,其中,N等于2M。
7.根据权利要求1所述的方法,该方法还包括标识或建立至少一条另外的组播流,其中,各条组播流包括从先前流中的所述内容的所述副本时移了时间M的所述内容的副本。
8.根据权利要求1所述的方法,其中,在所述源处,所述请求被接收并且所述要求概括被确定。
9.根据权利要求1所述的方法,其中,在所述内容递送网络中的所述源与所述目的地之间的中间网络组件处,所述请求被接收并且所述要求概括被确定。
10.根据权利要求1所述的方法,其中,在组播网络中,所述目的地包括主机或主机指定路由器H-DR。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP13250076.0A EP2819419A1 (en) | 2013-06-25 | 2013-06-25 | Content distribution system and method |
EP13250076.0 | 2013-06-25 | ||
PCT/GB2014/000258 WO2014207427A1 (en) | 2013-06-25 | 2014-06-25 | Content distribution system and method |
Publications (2)
Publication Number | Publication Date |
---|---|
CN105340284A CN105340284A (zh) | 2016-02-17 |
CN105340284B true CN105340284B (zh) | 2020-02-28 |
Family
ID=48783141
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201480036517.4A Active CN105340284B (zh) | 2013-06-25 | 2014-06-25 | 在内容递送网络中从源向目的地递送内容的方法 |
Country Status (4)
Country | Link |
---|---|
US (1) | US10356482B2 (zh) |
EP (2) | EP2819419A1 (zh) |
CN (1) | CN105340284B (zh) |
WO (1) | WO2014207427A1 (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2819420A1 (en) | 2013-06-25 | 2014-12-31 | British Telecommunications public limited company | Content distribution system and method |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6211901B1 (en) * | 1995-06-30 | 2001-04-03 | Fujitsu Limited | Video data distributing device by video on demand |
CN101248666A (zh) * | 2005-08-26 | 2008-08-20 | 汤姆森许可贸易公司 | 使用动态广播调度的点播系统和方法 |
CN102137277A (zh) * | 2010-08-17 | 2011-07-27 | 华为技术有限公司 | 实现交互式轮播频道的方法、装置及系统 |
Family Cites Families (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5724646A (en) | 1995-06-15 | 1998-03-03 | International Business Machines Corporation | Fixed video-on-demand |
US6826612B1 (en) | 1999-12-21 | 2004-11-30 | Alcatel Canada Inc. | Method and apparatus for an improved internet group management protocol |
JP2003519987A (ja) | 1999-12-29 | 2003-06-24 | ゲートウェイ,インコーポレイテッド | ビデオ・オンデマンドを含むコンテンツのストリーミング能力を高める方法 |
US7107606B2 (en) | 2000-08-30 | 2006-09-12 | The Chinese University Of Hong Kong | System and method for highly scalable video on demand |
US8370507B1 (en) * | 2000-09-13 | 2013-02-05 | Rockstar Bidco Lp | System, device, and method for receiver access control in an internet television |
CN1240223C (zh) | 2000-12-13 | 2006-02-01 | 香港中文大学 | 经由网络递送媒体的方法与系统 |
US6970940B1 (en) | 2001-03-16 | 2005-11-29 | 3Com Corporation | System and method for distributing a single multicast multi-program audio stream over a network |
US7200669B2 (en) | 2001-07-31 | 2007-04-03 | Dinastech Ipr Limited | Method and system for delivering large amounts of data with interactivity in an on-demand system |
US7174384B2 (en) | 2001-07-31 | 2007-02-06 | Dinastech Ipr Limited | Method for delivering large amounts of data with interactivity in an on-demand system |
US7260640B1 (en) * | 2003-02-13 | 2007-08-21 | Unisys Corproation | System and method for providing an enhanced enterprise streaming media server capacity and performance |
US7698724B1 (en) | 2003-05-15 | 2010-04-13 | Cisco Technology, Inc. | Convergence processor for media streams |
US7349906B2 (en) | 2003-07-15 | 2008-03-25 | Hewlett-Packard Development Company, L.P. | System and method having improved efficiency for distributing a file among a plurality of recipients |
US8484308B2 (en) | 2004-07-02 | 2013-07-09 | MatrixStream Technologies, Inc. | System and method for transferring content via a network |
US7760659B2 (en) | 2004-08-05 | 2010-07-20 | Microsoft Corporation | Transmission optimization for application-level multicast |
US20060029093A1 (en) | 2004-08-09 | 2006-02-09 | Cedric Van Rossum | Multimedia system over electronic network and method of use |
US7788393B2 (en) | 2005-02-23 | 2010-08-31 | Cisco Technology, Inc. | Switching a client from unicasting to multicasting by increasing the unicast stream rate to the client |
US8140699B2 (en) | 2005-02-23 | 2012-03-20 | Cisco Technology, Inc. | Switching a client from unicasting to multicasting by simultaneously providing unicast and multicast streams to the client |
CN101326790A (zh) | 2005-12-13 | 2008-12-17 | 艾利森电话股份有限公司 | 用于经由不同承载类型分发内容的技术 |
US7839850B2 (en) | 2006-01-30 | 2010-11-23 | Juniper Networks, Inc. | Forming equal cost multipath multicast distribution structures |
CN101432991B (zh) | 2006-04-29 | 2013-01-30 | 汤姆森特许公司 | 基于互连网协议的无线网络中利用错位播放的多播会话的无缝切换 |
US8732559B2 (en) | 2006-07-25 | 2014-05-20 | Thomson Licensing | Recovery from burst packet loss in internet protocol based wireless networks using staggercasting and cross-packet forward error correction |
US20080077701A1 (en) | 2006-09-27 | 2008-03-27 | George Philip Kongalath | Synchronized data content delivery |
US20080109857A1 (en) | 2006-11-06 | 2008-05-08 | Nortel Networks Limited | Time-shifted broadcast delivery |
JP4723457B2 (ja) | 2006-11-06 | 2011-07-13 | 富士通株式会社 | 中継装置、無線通信システム及びマルチキャスト中継方法 |
WO2008120374A1 (ja) | 2007-03-29 | 2008-10-09 | Pioneer Corporation | コンテンツ配信システム |
CN101060617B (zh) * | 2007-05-22 | 2010-07-28 | 华为技术有限公司 | 一种视频点播控制方法、客户端设备和切换控制装置 |
US8001575B2 (en) * | 2007-08-21 | 2011-08-16 | Alcatel Lucent | Method of distributing video-on-demand over an internet protocol network infrastructure |
US8386629B2 (en) | 2007-12-27 | 2013-02-26 | At&T Intellectual Property I, L.P. | Network optimized content delivery for high demand non-live contents |
CN101965716A (zh) | 2008-01-10 | 2011-02-02 | 惠普开发有限公司 | 多路对等媒体流传送 |
US7975071B2 (en) | 2008-01-18 | 2011-07-05 | Microsoft Corporation | Content compression in networks |
WO2009152865A2 (en) | 2008-06-20 | 2009-12-23 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for ingesting media content in a peer-to-peer network |
US8332899B2 (en) * | 2009-06-04 | 2012-12-11 | Centurylink Intellectual Property Llc | Dynamic VOD channel allocation based on viewer demand |
CA2774363C (en) | 2009-09-15 | 2020-06-23 | Comcast Cable Communications, Llc | Dynamic content packaging |
US8392956B2 (en) | 2010-08-16 | 2013-03-05 | At&T Intellectual Property I, L.P. | Systems and methods for processing media content requests |
US9596095B2 (en) | 2011-07-29 | 2017-03-14 | Telefonaktiebolaget L M Ericsson (Publ) | Optimized near-simultaneous distribution of multimedia content |
EP2785005A1 (en) | 2013-03-28 | 2014-10-01 | British Telecommunications public limited company | Content distribution system and method |
EP2819420A1 (en) | 2013-06-25 | 2014-12-31 | British Telecommunications public limited company | Content distribution system and method |
EP2819345A1 (en) | 2013-06-25 | 2014-12-31 | British Telecommunications public limited company | Content distribution system and method |
EP2819364A1 (en) | 2013-06-25 | 2014-12-31 | British Telecommunications public limited company | Content distribution system and method |
-
2013
- 2013-06-25 EP EP13250076.0A patent/EP2819419A1/en not_active Ceased
-
2014
- 2014-06-25 WO PCT/GB2014/000258 patent/WO2014207427A1/en active Application Filing
- 2014-06-25 EP EP14736917.7A patent/EP3014892B1/en active Active
- 2014-06-25 CN CN201480036517.4A patent/CN105340284B/zh active Active
- 2014-06-25 US US14/392,239 patent/US10356482B2/en active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6211901B1 (en) * | 1995-06-30 | 2001-04-03 | Fujitsu Limited | Video data distributing device by video on demand |
CN101248666A (zh) * | 2005-08-26 | 2008-08-20 | 汤姆森许可贸易公司 | 使用动态广播调度的点播系统和方法 |
CN102137277A (zh) * | 2010-08-17 | 2011-07-27 | 华为技术有限公司 | 实现交互式轮播频道的方法、装置及系统 |
Also Published As
Publication number | Publication date |
---|---|
US20160134944A1 (en) | 2016-05-12 |
EP3014892B1 (en) | 2022-09-14 |
CN105340284A (zh) | 2016-02-17 |
EP2819419A1 (en) | 2014-12-31 |
US10356482B2 (en) | 2019-07-16 |
EP3014892A1 (en) | 2016-05-04 |
WO2014207427A1 (en) | 2014-12-31 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105340237B (zh) | 在内容递送网络中从源向至少一个目的地分发内容的方法 | |
EP2979423B1 (en) | Content distribution system and method | |
EP3014808B1 (en) | Content distribution system and method | |
US8386629B2 (en) | Network optimized content delivery for high demand non-live contents | |
US10270821B2 (en) | Content delivery system and method | |
EP3014891B1 (en) | Content distribution system and method | |
CN105340284B (zh) | 在内容递送网络中从源向目的地递送内容的方法 | |
Bouten et al. | An autonomic delivery framework for HTTP adaptive streaming in multicast-enabled multimedia access networks | |
Wen et al. | QoS Supported IPTV Service Architecture over Hybrid‐Tree‐Based Explicit Routed Multicast Network | |
Azgin et al. | A semi-distributed fast channel change framework for IPTV networks | |
Azgin et al. | Cooperative delivery techniques to support video-on-demand service in IPTV networks | |
Ragab | Peer-to-Peer Overlay Network for On-demand Video Streaming. | |
Fouliras | Data Dissemination in Mobile Environments |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |