CN105103518B - 将内容从源传递到目的地的方法和装置、计算机可读介质 - Google Patents

将内容从源传递到目的地的方法和装置、计算机可读介质 Download PDF

Info

Publication number
CN105103518B
CN105103518B CN201480018223.9A CN201480018223A CN105103518B CN 105103518 B CN105103518 B CN 105103518B CN 201480018223 A CN201480018223 A CN 201480018223A CN 105103518 B CN105103518 B CN 105103518B
Authority
CN
China
Prior art keywords
content
host
stream
multicast
data flow
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201480018223.9A
Other languages
English (en)
Other versions
CN105103518A (zh
Inventor
V·卡斯基延
D·瑙克
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Publication of CN105103518A publication Critical patent/CN105103518A/zh
Application granted granted Critical
Publication of CN105103518B publication Critical patent/CN105103518B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/06Generation of reports
    • H04L43/062Generation of reports related to network traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/52Network services specially adapted for the location of the user terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/64Addressing
    • H04N21/6405Multicasting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/64Addressing
    • H04N21/6408Unicasting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/472End-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/47208End-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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (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)。
组播技术可以用于通过确保直到到其预期目的地的路径在网络拓扑中分裂为止在网络中不复制内容,来更有效地分发内容。
点播内容的传递造成特定问题,然而,由于多个用户在不同时间可以请求相同内容,并且每个用户都可能希望在媒体重放期间暂停或者倒回内容流。通过单播传递这种点播内容使得用户能够在任何时间开始查看流并且暂停和倒回流。然而,所有内容的单播在大多数网络中是不希望的,因为它导致在网络上发送的内容的大量复制并且消耗大量网络带宽。
使用组播传递技术将点播内容传递到多个终端主机存在困难;例如,对于在随后阶段希望加入流的单个用户,不能暂停或者倒回组播流,这可能是摄取(uptake)点播内容时的情况。这可能导致新主机必须建立并且接收针对该内容的单播流,而不管组播流可能相对于该段内容的开始在时间上提前多么少。
发明内容
第一方面提供了一种在内容传递网络中将内容从源传递到目的地的方法,该方法包括以下步骤:接收对一项内容的请求;识别或者建立包括所述内容的第一副本的第一组播流;识别或者建立包括内容的第二副本的至少一个第二组播流,内容的第二副本从内容的第一副本的相应部分时移时间M;确定用于内容的需求配置(demand profile),该需求配置包括以下各项中的至少一个并且可选地包括以下各项中的多个:在先前时间段内对内容的请求的数量的测量;在随后时间段内对内容的预期请求的数量的预测;在网络中的请求目的地的地理或者拓扑分布的确定;以及基于需求配置,选择使用多个时间交错的组播流传递内容。
因此,多个组播流被用于将特定段内容传递到已请求该内容的目的地。
如果内容的一个或更多个组播流已经存在于网络中,则这些组播流可以被识别和用作内容到目的地的传递的一部分。如果用于该段内容的时间交错的组播流不存在,则这些组播流可以被创建用于内容的传递。如果例如特定段内容在网络中首先可用时被设置为组播流,则用于该特定段内容的第一组播流可能已经存在于网络中。如果多个用户在随后时间请求特定段内容,或者如果内容拥有者确定该内容的第二时间延迟广播版本对于网络可用,则用于该特定段内容的第二广播流可能已经存在于网络中。然而,在实现上述方法之前,每个目的地仅订阅(subscribe)这些组播流中的一个。
因此,需求配置可以考虑对内容的先前请求的速率和/或质量,例如,在过去半小时内对内容的请求的数量或者在过去一小时内的请求速率、以及速率在过去一小时内改变的方式。另选地或者另外地,模型可以预测在未来时间段内的请求的可能数量;例如,如以下更详细描述的,可以设计模型,以预测在释放一段内容之后或者在用于该内容的广告之后接收到的请求的数量。模型可以考虑诸如时刻的因素和/或者关于用于先前段类似内容的需求配置的历史信息。可选地,需求配置由上述因素的组合构成。
在特定实施方式中,传递内容包括以下步骤:指导目的地加入第一组播流和第二组播流以接收内容。因此,网络中的组件可以选择使用多个时移组播模式传递内容,并且因此,可以通过指示目的地组件订阅特定多个组播流来指导目的地组件相应地获得内容。
可选地,在选择使用多个组播流传递内容之前,获得关于目的地的能力的信息。特别地,可以检查目的地接收多个组播流的能力和目的地的缓冲容量,以确定目的地能够接收并且缓冲足够内容,以使得能够在该模式下进行内容传递。
在一些实施方式中,该方法还包括以下步骤:识别或者建立包括内容的第三副本的第三组播流,内容的第三副本从内容的第一副本的相应部分时移时间P,可选地,其中P等于2M。因此,三个或更多个的多个时移组播流可以被用于传递内容,并且这些流可以被时移规则间隔。使用的组播流越多,内容可以被越快地传递到目的地,并且越多目的地可以使用相同流来接收内容。
可选地,该方法还包括以下步骤:识别或者建立至少一个进一步组播流,其中,每个组播流包括从先前流中的内容的副本时移时间M的内容的副本。因此,多个组播流可以被用于内容传递。时间M在每个流之间可以是相同的或者可以是不同的。
在一些实施方式中,该方法还包括以下步骤:在单播流中将内容的一部分发送到目的地。如果在接收到对内容的请求之前,多个组播流已经开始在网络中传递内容,则这些现有组播流可以被用于内容传递。然而,如果所有这些流都已经开始,则在内容开始时将存在不由任何组播流传递的一部分。该部分可以在单播流中被直接发送到目的地,如以下更详细描述的。
在一些实施方式中,在组播网络中,在源处接收请求并且确定需求配置,该源可以是内容服务器或者源指定路由器S-DR。在其它实施方式中,在内容传递网络中的源与目的地之间的中间网络组件处,接收请求并且确定需求配置。
在一些实施方式中,在组播网络中,目的地包括主机或者主机指定路由器H-DR。主机可以是与内容的最终用户或者消费者相关的最终用户终端,或者可以是给用户设备供应内容的中间设备。例如,目的地可以是在接收用于流传输到用户终端(诸如,互联网连接的电视机、计算机、平板或电话)的内容的家庭网络内的集线器。
在一个实施方式中,第二组播流可以从时间M开始进入该段内容。因此,该流可能遗漏流的前M分钟,使得有效地组播在第一流前面的内容,而不是相对于第一流在时间上被延迟。
该方法的实施方式还可以包括以下步骤:识别接收相同段内容的网络中的其它目的地,并且指示至少一个其它目的地加入至少第一组播流或者第二组播流。在这种实施方式中,第二流可以在该内容中的最早接收目的地已经到达的该部分内容处开始。
以上描述了系统的实施方式的多个方面。对本领域技术人员清楚的是,这些方面中的每个方面都可以被独立地实现。然而,这些方面被可选地彼此结合地实现,以提供多个优点作为更大系统的一部分。一个方面的特征可以被直接应用至系统的其它方面。此外,方法特征可以被直接应用至装置的多个方面。
特别地,在上述所有方面中,在组播网络中,目的地可以是主机或者主机指定路由器H-DR。主机可以是与内容的最终用户或者消费者有关的最终用户终端,或者可以是给用户设备供应内容的中间设备。例如,目的地可以是接收用于流传输到用户终端(诸如,互联网连接的电视机、计算机、平板或电话)的内容的家庭网络内的集线器。
类似地,在上述所有方面中,源可以是在网络中供应内容的设备,或者可以是网络中的处理内容到目的地的路由的智能路由组件。内容可以穿过智能路由组件,或者该组件可以控制网络中的其它组件(诸如,源),以实现在此描述的方法。
此外,在以上阐述的所有方面中,内容可选地是视频内容和/或音频内容,特别是响应于来自用户的请求传递的点播内容。然而,本领域技术人员将理解,在此描述的系统和方法同样可以应用至用于分发数据(诸如,文本或图像数据)或软件的网络。
附图说明
下面将参照附图更详细地描述系统的实施方式,附图中:
图1是可以实现本系统的多个方面的示例性网络的示意图;
图2示意性地示出根据一个实施方式的多个时间延迟的组播流;
图3是根据一个实施方式的在接收主机处缓冲的组播流的示意图;
图4是根据一个实施方式的触发时间交错的组播内容流的方法的示意图;
图5a示出根据一个实施方式的可能(potential)树分发拓扑;
图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示出组播网络800,该组播网络800包括多个源810、812、814,每个源都能够经由网络将内容提供或者供应给主机816、818、820。源连接到源指定路由器(S-DR)830、832,其管理从源到网络中的组件的内容的传递。
网络还包括多个中间路由器(IR)836、838,其将组播流(连同其它网络业务)从源810、812、814传送到主机816、818、820。IR可以包括用于特定组播流的一个或更多个会合点(RP)834。RP 834是网络中的路由器,除非下游路由器处于源特定模式,用于特定组的组播数据通过RP 834传递到所有下游路由器。也就是说,下游路由器或者主机824、818通过RP834加入组播流。因此,下游组播树以RP 834为中心。
最接近主机或者目的地的路由器可以被称为主机指定路由器(H-DR)822、824。去往特定主机816的组播流经过相关H-DR 822,并且主机使用IGMP发送其H-DR请求,以加入特定组播组或者从其删除。
通过进一步示例,在组播组G中组播内容的源812遍及网络广播用于该内容的广告消息。主机H2 818接收广告并且希望接收组播数据。主机818将指定它希望加入的组播流的组播地址的IGMP加入请求(如在广告消息中详述的)连同其成员资格信息一起发送到其H-DR 824。H-DR 824通常基于通过网络回到用于内容的S-DR 830的最短路径来建立回到内容的源812的组播树。然而,在大多数操作模式下,即使这些IR提供回到S-DR 830的更短路径,组播树也必须经过用于该组播流的指定RP 834,而不经过其它IR 838。H-DR 824朝向用于具有活动下游成员的每个组的组特定RP 834发送周期性加入/删除消息。
如果组播树已经将内容传递到其它主机,则H-DR 824简单地建立返回到现有组播树的分支。如果该主机在网络的该区域中首先请求内容,则该树可以被建立返回到S-DR830。组播树在图1中由虚线840指示。一旦组播树被建立,组播内容就可以沿着树向下被传递至H-DR 824,并且从那里传递到请求主机818。
在基于PIM-SM的组播系统中,当主机指定路由器(主机-DR)从其主机中的一个接收到成员资格报告以加入组G时,主机-DR使用其单播协议查找作为在最短路径上朝向RP(会合点树,RPT)或源(最短路径树,SPT)的下一跳的邻居的地址。当中间路由器通过相同请求从下游路由器接收加入/删除消息时,执行相同动作。它们使用单播协议的路由度量作为与度量偏好相关的MRIB路由度量,度量偏好反映用来获悉该成本的方法(即,每个单播协议具有相关度量偏好值,并且如果度量偏好值相同,则可以仅比较度量成本)。具有最低成本的下一跳邻居被选择作为上游邻居,加入/删除消息被发送到该上游邻居。加入/删除消息(由于其一直行进到RP或者源)触发每个路由器中的组相关路由条目的创建。被建立到RP或源的该反向路由被用于在从RP或源到终端主机的下游方向上路由组播数据分组的流。
组播树840上的每个路由器都将路由条目保持在内部数据库(诸如,组播路由信息库(MRIB))内,该内部数据库包括诸如源地址、组地址、接收分组的进入接口、以及沿着组播树向下向前发送分组的输出接口的列表的信息。定时器、标志位和其它信息也可以被存储在MRIB条目中。
为了离开组播组G,主机818将删除请求发送到H-DR 824,然后该H-DR 824通过组播树向上传播,以拆卸(tear down)树的直到该树需要将组播数据传递到其它主机的点的分支。
在诸如图1所示的网络中,第一主机H1在时间T可以请求单段内容。该内容由源S发出,该源S在操作PIM-SM或者等效组播路由协议的网络中被连接到源指定路由器(源DR或者S-DR)。主机使用IGMP等进行成员资格管理。内容流本身持续X分钟,并且会话结束时的未来时间T+X可以被称为T1。该段内容可以是已普及并且现在正被多个用户以每个请求之间的相对短时间间隔请求的新闻条目或者电影。如果组播流开始用于第一个用户,则在多个其它用户加入到该组以观看该内容的预期中,该组播流不能被停止或暂停用于每个新主机,以追赶最远点。这导致组播不可能用于该场景。然而,在此描述了一种多个时间交错的组播流被触发以将一段内容散布到多个主机,使流从在时间T请求的第一流位置开始的方法。在随后时间点,每个组播树服务所有这些主机的子集,但是该组中的每个主机成员实际上可以播放在流本身中的不同点。在PIM-SM的情况下,我们称这为“追赶”能力,其由源或者到网络的接口(诸如,源DR)提供。智能(intelligence)可以被部署在源或其接口中并且还被部署在该组的主机中。源决定主机订阅一个或更多个组播流中的哪一个,并且可以使用单播流传输协议请求来将其传输回主机。
本系统的单个主机可以在不同接口上同时接收多个组播流,所有组播流都由上层协议缓冲并且重组。每个组播流都从相同流但是从视频中的不同点同时传递内容,例如,如图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分钟之后,该流将开始传递N分钟以前在S(T)的开始处接收到的分组。类似地,在时间M-N之后,流S(T+M)将开始传递在(M-N)分钟和M分钟以前分别从S(T+N)和S(T)接收到的分组。这意味着在时间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的起点。在部分A1、A2和A3之后,部分A4被接收和缓冲,并且被输出给用户。然而,因为在本示例中没有更多组播流,主机将继续接收流S(T)并且将继续输出部分A4,直到它到达内容结束。
本领域技术人员将清楚的是,以上给出的示例可以根据系统的要求和能力并且基于以下阐述的一些标准和技术考虑被修改和改变。例如,每个主机都能够接收并缓冲多于或少于4个流,或者网络可以将用于单段内容的可用流的数量限制到小于4个。
本系统的实现可以包括以下特征中的一些或所有:第一,终端主机应该被布置成缓冲所要求的数量的分组,在该情况下,多达M分钟进入流;第二,在源与主机之间可以提供通信机制;第三,源可以被布置成管理何时触发用于同一段内容的新组播流;第四,源可以被布置成确定主机必须订阅多少和哪个组播流,这可以使用预测数据分析能力来实现,并且可以考虑到主机的数据传递容量(是否存在同时支持内容的四个流的链路(3个流来自组播,1个流来自单播),或者用户是否愿意等待传递这些分组花费的时间);以及第五,终端主机可以被布置成控制何时删除给定组播树,如上所述。这些元素中的每个元素可以被独立地提供,并且每个元素在此被单独地描述。然而,元素可以彼此结合地被实现以提供组播系统和方法,也如上所述。
源和主机可以实现用于通信的协议。实时流传输协议(RTSP)、超文本传输协议(HTTP)等可以被用于此目的。当主机在RTSP建立消息中发送对给定统一资源标识符(URI)的请求时,进入网络的源或其代理/接口可以通过重定向进行响应,以发布组播流的新URI。另选地,源可以使用Set_Parameter、Get_Parameter或Annouce的组合,在会话期间公布从媒体服务器到主机的该改变,以触发主机移动到另一组。在HTTP中,交替组播URI的通信可以在使用HTTP刷新头部的URI重定向方法中从媒体服务器被传送到主机。类似方法可以被设计用于其它协议栈。另选地,外部实体可以被部署成执行所有以上任务并且向源和主机两者传输动作。这是使用中心而不是分布式智能实体的相同技术的另一个实施方式。
智能还可以不被部署在媒体服务器(即,数据源)上,而是接近媒体服务器部署。这种实施方式可以被实现,其中,媒体服务器是不可访问的(例如,由内容提供者控制),在这种情况下,网络操作者可以部署进入源的接口,其处理在此描述的任务并且用作具有到源的该扩展能力的代理。在PIM-SM的情况下,这可以是作为源的第一跳的路由器(即,源-DR)。为了便于此后参考,我们将假定在源端上的智能被部署在源本身。这些变化被包含在保护范围中。
现在描述用于触发多个时间交错的流的方法。如下所述,存在针对如何以及何时应该触发组播流的多个选择。在下述方法中,为同一段点播内容创建多个组播流,使得如果大主机组在不同时间请求该内容,则根据它们的能力和所预测的网络性能,该主机组的不同子集可以请求订阅一个或者多个组播流。然后,不能由组播覆盖的各个变化可以根据它们的能力被单播到主机,如上所述。
因为每个组播流在网络中本质上是内容的时间交错的复制,当这可以被避免时,不希望产生流。因此,可以利用一些智能选择性地作出何时触发新组播流的决定。以下方法(尽管被独立地描述)在同一系统中可以在不同时间被实现,或者可以彼此结合地被实现,因此例如,如果流还未通过实现第二方法的算法被触发,则根据首先描述的方法可以每N分钟生成一个流。
第一种可能方法是以规则间隔(每N分钟)触发组播流。这是周期性的,但是可能不是自适应的。
在第二种方法中,考虑请求主机的能力触发流。在每个间隔(间隔(M))之间,在主机加入和离开该组时,主机组经历改变。这意味着如果每个主机订阅一个或者更多个并行但时间交错的流时,该间隔可以被选择为使得大多数主机可以缓冲在该时段内请求的分组。
例如,根据主机组在给定评估时段的分布,90%的主机能够总计保持2小时的内容。如果大多数主机订阅3个平行时间交错的组播流,则3个流之间的间隔必须被选择为使得在前2个小时结束时,不由于缓冲溢出导致来自最老流的数据被丢弃。除了主机订阅的流的数量和针对该数据速率的主机的缓冲容量之外,该算法还可以考虑由媒体播放器消耗分组的速率(可以缓冲的播放的最大时间)。如果主机可以仅总计缓冲2小时的内容,则假设该主机订阅已被生成直到它加入为止的每个流,流的周期性必须使得在2小时内,所有流还未传递比由播放器消耗的数据更多的数据。如果流之间的间隔太大,则在提供追赶组播流的单播流首先被播放之后,主机的缓冲容量将不足以订阅流并且缓冲所有接收到的内容以在随后时间播放。组播流中的随后分组将被丢弃,这意味着间隙存在于播放中并且必须用差播放质量填充或者重新请求丢弃的数据块。这被解释用于单个主机——用于给定段内容的整个间隔(M)可以从组中的所有主机的分布推导,并且选择间隔以使得大多数主机可以从多个流获益。
在第三种方法中,新流也可以基于所预测的摄取模式被生成。例如,如果操作者知晓大多数消费者在晚上观看内容(例如,电影),则因为摄取将是最少的,在白天期间可以充分不触发流。
组播流的预测触发的另一个示例如下。如果源监视到20个主机的小网络中的11个主机在先前时间段(比如15分钟)内请求一段内容,则对于持续两小时的内容,它可以基于该网络中的更多主机也可能请求相同数据的预测,触发从在第12个主机的加入时的起点开始的组播流。该方法是预测性的并且不结合现有单播流作用,而是将未来单播流的数量最小化到所追赶的单个组播流。
应用将现有多个紧密间隔的单播流组合到为单个主机追赶(catch up)的单个组播流的第四种方法。另选地,组播流可以被回顾性地触发,以从先前时间点播放。在方法3的示例中,创建在最远点处开始进入流的组播流,即在15分钟处(其是第一主机将在流中的位置),以一直运行到结束,并且为剩余主机触发追赶协议。该结果是在最多15分钟之后,所有单播追赶都将完成,避免了通过10个不必要单播流复制数据,并且所有前11个主机将播放从组播流的开始接收的存储在缓冲器中的内容。这将在图4中进一步解释,图4示出均接收相同内容的四个主机H1、H2、H3和H4。
主机H4是最远进入流的(即,它是请求内容的第一个主机)。因此,组播流在该点(即,15分钟进入内容)开始,并且当组播流被传递并缓冲用于重放时,其它3个主机H1、H2和H3使用单播追赶到该点,以同时填充它们的缓冲器。当播放器播放所缓冲的分组并且最终到达15分钟进入视频时,播放器进一步移动到流中,其中,将开始播放通过组播传递的内容。类似地,为了所有主机更快地加入被传递到H4的流,例如在主机H3到达内容中的点(12分钟进入内容)处可以建立第二暂时组播流。因此,分钟12-15可以被同时传递到H1、H2和H3,并且该组播流可以在15分钟时被那些主机删除,这是因为主机已从被传递到H4的流向前接收分钟15。因此,多个时间交错的组播流可以回顾性地被生成。
使用上述四种决定方法中的一个可以生成任意数量的组播流。另选地,如果有的话,熟练的用户能够设计一种在第一个组播流之后何时触发新组播流的算法。
一旦确定组播流应该如上所述那样被触发并且它们之间的时间间隔已被计算,新流就被触发,并且下面将描述用于这样做的一种方法。
触发新流的决定位于源或者网络中的代理处(特别是如果源对于在此描述的组播使能器是不可访问的)。假设PIM-SM在适当时作为组播路由协议,为了使新组播流可行,应该在源处创建针对该流的会话描述文件,并且其源-DR应该向会合点(RP)登记,告知其存在。
我们假设源通过从实现诸如组播地址动态客户端分配协议(MADCAP)的现有地址分配服务器获得组地址,以及使用用于每个可用组播流的URI将该情况告知主机,控制到其流的成员资格。为了简单起见,我们假设源流与组地址之间的1对1映射:单个组的所有成员可能从一个时间交错的流接收内容,相同成员也可以订阅另一组地址,其中,它们可能接收相同内容的另一个时间交错的流。另选地,将多个不同内容流的组合映射到组地址也是可以的。这种动态地址分配可以结合本系统被实现。然而,由于我们仅考虑一段内容的时间交错版本,我们假设组地址到时间交错的内容流的简单1:1分配策略。
源使用实时流传输协议(诸如,RTSP的Announce、Redirect、Get/Set_Parameter消息)将其新URI传输到请求主机。另选地,HTTP流传输可以是适当的或者是任何其它专有协议栈。然后,主机解析到由源分配的流的新URI并且将其IGMP加入(未经请求的成员资格报告)发送到其指定路由器(DR)。该请求使用现有树构建方法朝向RP或者源逐跳行进,之后创建组播树分支,并且在主机处在下游接收内容。
每个上述方法都可以被用作触发新组播流的条件。可以使用它们中的任一个或者组合。它们也可以在追赶场景之外被使用,例如,根据应用,当可能时处理固定实时数据流传输,并且减少单播数据复制。触发多个组播流的方法是可以被看作内容发布之后的方法的独立实体,而不管内容如何被主机组订阅。上述示例展示了在固定流场景中以及灵活流传输场景中,在触发多个时间交错的流时部署这种智能的优点。在灵活流传输的情况下,如果在接收到的组播内容中的当前播放时间在未来,则主机必须缓冲该内容(如果追赶可应用),并且在使用单播追赶到组播开始的点之后,当媒体播放器需要时,播放该内容。用于纯粹在发布(publish)模式(无需追赶)下应用该系统的网络域之外的一个示例是影响飞行娱乐的广播。在内容广播内的另一个示例是使用该方法来影响重复放映的滞后时间,例如,频道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)的决定算法的计算结果的变量。
在此描述的方法中的下一个步骤是决定哪个主机将订阅哪个可用组播流,之后是接收特定段点播内容的请求。下面描述可以被考虑以进行分配的因素和选项。
注意,内容发布模式不需要如上述规定那样用于使该方法可应用。考虑到下面解释的各种因素,这是可以针对给定发布模式(pattern)管理用于主机组的订阅模式的独立订阅模型系统。在下面描述的示例中,我们假设存在使用任意标准集合生成的用于单段内容的很多时间交错的可用流。
网络被划分为两种类型:一种类型是网络足够小,使得各个组播树重叠或者共享公共链接,并且另一种类型是树本身是相对稀疏的,并且可能在地理上跨网络分布。在图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)并且建立新分支的树的努力。这些是可以由操作者基于它们的网络资源的缺乏进行的权衡。
从网络可靠性的角度,第三种方法接近组分配。例如,如果源知晓关于S(T+M)的关键链路之一的计划中断(outage),如果中断将不影响不同的树(诸如,S(T+N)),则可能选择将主机放在不同的树(诸如,S(T+N))上。另选地,评价可靠性的更复杂方法是计算用于给定树的主机成员的端到端性能度量的分布,并且使用该方法为给定主机确定穿过具有良好网络性能的最佳可能性的树的流。该方法不必须考虑视频本身的位置和所传递的视频中的单播到组播片段的比例,而是更多集中于给用户提供具有最少分组丢失、抖动和延迟的可靠体验。该方法还可以被扩展,使得源使用可预测模型来计算树或分支的性能(如果从单播协议知晓新主机的端到端通路),并且为给定主机作出最佳树选择。我们更早的发明描述了多个方法和因素,以考虑针对给定会话要求评估给定路线的网络性能。我们使计算每个树的聚合网络性能度量的能力适于决定针对主机的树分配以接收所要求的内容。
第四种方法最适于各个组仅通过网络的空闲(clear)部分传播的网络。图5中示出这种网络的可能结构。因为请求内容的主机的物理位置,导致这种网络出现。最左边的主机可能在S(T)上,而在中间树上的主机可能正在接收S(T+M),并且右边的主机可能接收S(T+N)。当然,在真实网络中可能不发生组播树的这种严苛划界,如果网络的三个部分中的每个部分都针对其本地主机集合表现最好,但是针对来自树的大数量跳处的主机呈现很差的网络传递性能,则可能性存在。例如,传递到左边的主机组的S(T)树比使一个树分支一直向下游流到网络右侧的主机的子网的树可能具有更好的性能,其可能由S(T+N)更好地服务。如果支持用于S(T+M)的树的网络正在遭受由于其它服务导致的拥塞,这特别被加重。在这种场景下,操作者可以决定作出以下假设:到主机集的跳数与期望用于主机集的性能成反比——跳数越大,端到端性能越差。这种方法也适合操作者不希望具有经由网络从组播树展开的多个树分支的网络,因此通过并行链路增加数据复制,并且相反更偏向于使更窄的树更深入到网络中。
因此,主机的地理位置可以用来选择为该段内容分配哪个组播流。在以上简单示例中,由于右边的主机的RP和对应树最接近右边的主机,所以右边的主机更可能变为接收S(T+N)的组的成员。
对此进行计算的技术将来自主机的最少跳数与必须选择的各种树进行比较,并且挑选具有最短路径的树。
在第五种方法中,主机到流的分配结合一种或更多种上述决定方法。例如,源可以将主机分配给S(T+N),并且单播N分钟的视频,这是因为其缓冲容量仅可以支持N分钟该视频(假设以分组被传递的速率立即重放)。如果知晓由于拥塞导致的影响树传递S(T+M)时的网络性能问题,即使视频的单播部分在后者中被最小化,也可能选择S(T+N)而不是S(T+M)。在另一个示例中,主机可能被分配给最接近其地理位置的组,以避免穿过存在拥塞的网络的一部分。网络操作者可以按照任何偏好顺序使用任何或所有以上考虑(降低网络负荷、组管理策略、网络资源可靠性或基于地理位置的分配)。如果权重因子被分配给这些因素中的每个因素,则可以每个主机组合为每个树计算聚合度量,具有最佳度量值的树可以被选择并且被传输到主机以触发成员资格。
一旦选择了主机应该订阅的流,源就可以使用单播流传输协议消息来传输将由主机媒体播放器使用的URI的列表。虽然在本此描述了多个URI方案,但是其它方法可以替代该方案,以将组地址传输到主机,该主机使用该组地址变为该组的成员,以接收单个时间交错的组播流。使用组地址,上层协议将JoinHostGroup请求传递到IP层。由用于组播(上层协议到IP互动和IGMP扩展)的扩展IP模块管理IGMP成员资格。然后,IGMP被用于将IGMP未经请求的成员报告发送到具有它希望订阅的组地址的主机的DR。然后,主机-DR使用该信息构造到主机-DR的组播树分支用于该组。成员资格可以是(*,G)或(S,G)状态,并且如在RFC 4601和RFC 2362中解释的,进行组播路由。
主机还使用RTSP/RTP/RTCP(或等效)会话来接收单播流,以覆盖它希望的内容持续时间。包括从特定位置请求流的方法的这些流传输协议本身是现有技术。上面已经解释了当数据复制出现在缓冲器中时主机逐渐删除多个组播流的方法。上层协议将LeaveHostGroup请求发送到IGMP模块,然后该IGMP模块将LeaveHostGroup请求发送到主机-DR(或者静静地等待其成员资格超时)。这导致加入/删除消息从主机-DR朝向组播源或者RP被发送,清除相关(*,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、内容的数据速率
优化使得当为其用户生成最少数量的流时,每个主机都可以尽快地下载内容。例如,为了使主机在一分钟内具有整个流,我们将需要在重放点之间创建115个具有1分钟时间差的组播流。用户将需要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分钟获得一个请求。平均起来,不超过5个主机在单播上追赶,并且单播流将不长于30分钟。
然而,关于到达率的平均分布的该假设可能不成立。考虑到我们也具有关于该内容的摄取的知识。例如,我们知晓在内容变得可用之后,在第一小时内平均每5分钟4个请求,以及在第二小时内每12分钟1个请求。如果我们使用针对4个流的先前重放时间,则在30分钟间隔内可以具有多达8个单播流。
现在我们添加另一个约束:在任一时间具有少量单播流。
为了满足该约束,我们可以使用用户消耗信息使4个流的开始时间偏移,以最小化在单播上要求用于随后请求的持续时间。如果我们每20分钟触发一个新流(使在第一小时和第二小时内的主机的分布(3:1)匹配),我们再次在任一时间具有平均不多于5个单播流,并且1小时的缓冲容量仍然充足。源在时间0触发流,流具有在0、20、40和60分钟处的重放点。因为一旦流在115分钟时到达结束位置,我们就可以开始新流,所以将不花费多于55分钟用于新流开始。
注意,触发多个流的该发布模型从内容发布者的角度来看是独立的,并且不需要用于将流分配给主机的订阅模型。事实上,在触发多个流时部署智能并且使用完全不同的策略实现到这些流的主机成员资格是可以的。另外,注意,触发多个流的该方法也可以在固定流传输场景中(即,不追赶)中使用。在这种场景下,主机仅可以从它订阅的点接收内容(不可以倒回或快进)。在这种情况下,使各种流的开始时间偏移的目的是利用关于主机的知识来最小化当在已经开始之后加入组播流时主机平均丢失的内容的持续时间。
以下示例性方法展示了一个或更多个组播流到主机的分配。
假设一段内容以2Mbps的数据速率持续115分钟并且可用流时间交错15分钟。将存在8个同时可用流以便主机从中选择。(不存在对由源生成的流的数量的限制。)
从开始请求内容的主机H1具有5Mbps的链路容量以及350MB的缓冲容量(大约存储该内容20分钟)。该主机不能订阅进入视频多于15分钟的可用组播流。使得来自H1的请求在12分钟时进入由源触发的最新流S'的开始。因为它仅缓冲20分钟,H1将必须订阅S'。然后,它必须追赶12分钟的内容,首先给用户回放,之后可以回放经由组播接收的内容。还必须在该点拆卸单播会话(使用RTSP Teardown等),以确保不继续接收已经来自组播的前12分钟之后的数据的副本。
我们具有拥有10Mbps的链路容量和1GB的缓存容量(大约1小时的该视频)的另一个主机H2。H2从起点请求内容,在10分钟之后进入最新流(S')的开始。假设网络提供者的目的是在其链路和缓冲容量的条件下尽可能快地给予用户内容。因此,它请求H2订阅S'以及在S'之前30(S30)分钟、60(S60)分钟和90(S90)分钟开始的流。这意味着主机将在30分钟时间段内接收所有内容。还需要来自源的单播会话用于前10分钟的内容。在前10分钟内,链路利用率是10Mbps,并且然后在15分钟内降至8Mbps,并且在最后5分钟流传输内降至6Mbps。任何其它流组合都将导致更长下载持续时间。
现在我们给出基于传送流的各种组播树的网络性能进行多个流的分配的示例。我们假设每个树仅转发一个时间交错的流,但是这可以在现实生活场景中被扩展。假设目前存在传送每个视频一个时间交错的流的3个组播树。当主机H3请求单播URI时,源必须用由源为它选择的使主机指向各个树的URI来回复。
源为每个组播树计算性能分数。存在可以用于计算该性能分数的多个度量。例如,显式拥塞通知的改变速率、ECN通知、平均分组丢失、平均抖动、跨所有链路的平均吞吐量、到RP的平均跳数、从请求主机到最接近组播树成员的跳数、平均端到端延迟等。在此被作为平均值的所有度量还可以是跨网络的分布——这增加了以下得分的复杂性,但是遵循相同原则。也可以存在从表示它们的健康状态的路由器推导出的度量。例如,如果输出分组的数量与输入分组的数量之间的差异增加,则这意味着路由器不能以它接收分组的速率推送分组——该值(作为每类服务的进入分组的总数的百分比)可以用作路由器的健康状态的测量值。考虑到例如检测QoS降低的方法,这些度量中的一些可以是预测性的。可以存在考虑树本身的形状的其它度量,并且认为一些树形状比其它树形状更好。用于计算“树健康状态”分数的度量的实际集合可以是依赖于应用程序和操作者的,并且我们的以上列表仅是指示性列表。
对于以上每个度量,我们具有被用于使从网络接收的度量与其如何“好”的指示匹配的多个质量等级。例如,针对给定等级的服务的最大可接受分组丢失可以是0.1%。因此,从0%丢失逐渐到0.1%丢失(具有0.02%丢失的步幅大小)导致5个质量等级。使输入度量与该比例(scale)匹配,并且给其分配质量值。分配给给定度量的等级数量反映该度量对于整个分数的重要性(参见以下)。我们针对我们使用的所有度量执行该步骤,以计算树健康状态分数。
对于该示例,我们使用以下质量等级(等级的上限不属于该等级)从分组丢失、延迟和抖动计算该分数:
分组丢失(可接受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。
如果关键性能指示符与组成员资格而不是组播树的健康状态相关,则该示例也可行。每个源都可以具有由组分数(类似于这里的健康状态分数)反映的组管理的策略,然后,该组分数可以用于以预期方式扩展或者缩小组播树的大小并且更改组播树的形状。源也可以根据为每个现有组获得的分数,将现有组成员移动至另选组。
对内容传递网络的以上论述中的参考不应该以限制方式被解释。根据本发明的方法可以在能够支持单播和组播的任何通信网络内被实现。此外,根据本发明的方法的使用不限于音频或者视频内容数据,并且可以被用于发送其它类型的数据。
由于本发明可以在路由器或其它设备内的软件上被实现,所以可以将传统路由器(或设备)升级为可以执行根据本发明的方法的路由器。计算机代码可以经由下载(例如经由互联网或者在一些物理媒体(例如,DVD、CD-ROM、USB存储棒等)上)被部署到调制解调器(或者路由器)。
本发明提供了用于在网络(特别是组播网络)中分发内容的方法和系统。一种方法包括在内容传递网络中将内容从源传递到目的地。对一项内容的请求被接收,并且第一组播流被识别或建立,第一组播流包括内容的第一副本。至少一个第二组播流也被识别或者建立,第二流包括内容的第二副本。内容的第二副本从内容的第一副本的相应部分时移时间M。然后,使用第一组播流和第二组播流这二者将内容传递到目的地。

Claims (11)

1.一种在内容传递网络中将内容从源传递到目的地的方法,所述方法包括以下步骤:
接收对一项内容的请求;
识别或者建立包括所述内容的第一副本的第一组播流;
识别或者建立包括所述内容的第二副本的至少一个第二组播流,所述内容的所述第二副本从所述内容的所述第一副本的相应部分时移时间M;
确定用于所述内容的需求配置,所述需求配置包括以下各项中的至少一个并且可选地包括以下各项中的多个:
在先前时间段内对所述内容的请求的数量的测量;
在随后时间段内对所述内容的预期请求的数量的预测;
请求目的地在所述网络中的地理或者拓扑分布的确定;以及
基于所述需求配置,选择使用多个时间交错的组播流传递所述内容,
其中,在单播流中将所述内容的一部分发送到所述目的地。
2.根据权利要求1所述的方法,其中,传递所述内容包括以下步骤:指导所述目的地加入所述第一组播流和所述第二组播流以接收所述内容。
3.根据权利要求1或者权利要求2所述的方法,其中,在选择使用多个组播流传递所述内容之前,获得关于所述目的地的能力的信息。
4.根据权利要求1或者权利要求2所述的方法,所述方法还包括以下步骤:识别或者建立包括所述内容的第三副本的第三组播流,所述内容的所述第三副本从所述内容的所述第一副本的相应部分时移时间P。
5.根据权利要求4所述的方法,其中,P等于2M。
6.根据权利要求1或者权利要求2所述的方法,所述方法还包括以下步骤:识别或者建立至少一个进一步的组播流,其中,各个组播流包括从先前流中的所述内容的副本时移时间M的所述内容的副本。
7.根据权利要求1或者权利要求2所述的方法,其中,在所述源处接收所述请求并且确定所述需求配置。
8.根据权利要求1或者权利要求2所述的方法,其中,在所述内容传递网络中的所述源与所述目的地之间的中间网络组件处接收所述请求并且确定所述需求配置。
9.根据权利要求1或者权利要求2所述的方法,其中,在组播网络中,所述目的地包括主机或者主机指定路由器H-DR。
10.一种计算机可读存储介质,所述计算机可读存储介质存储计算机程序,当该计算机程序由处理器执行时实现根据权利要求1至9中的任一项所述的方法。
11.一种在内容传递网络中将内容从源传递到目的地的装置,其被配置成在使用时实现根据权利要求1至9中的任一项所述的方法。
CN201480018223.9A 2013-03-28 2014-03-27 将内容从源传递到目的地的方法和装置、计算机可读介质 Active CN105103518B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP13250040.6A EP2785005A1 (en) 2013-03-28 2013-03-28 Content distribution system and method
EP13250040.6 2013-03-28
PCT/GB2014/000124 WO2014155046A1 (en) 2013-03-28 2014-03-27 Content distribution system and method

Publications (2)

Publication Number Publication Date
CN105103518A CN105103518A (zh) 2015-11-25
CN105103518B true CN105103518B (zh) 2019-10-01

Family

ID=48092863

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201480018223.9A Active CN105103518B (zh) 2013-03-28 2014-03-27 将内容从源传递到目的地的方法和装置、计算机可读介质

Country Status (4)

Country Link
US (1) US10084883B2 (zh)
EP (2) EP2785005A1 (zh)
CN (1) CN105103518B (zh)
WO (1) WO2014155046A1 (zh)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2819364A1 (en) 2013-06-25 2014-12-31 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
EP2819419A1 (en) 2013-06-25 2014-12-31 British Telecommunications public limited company Content distribution system and method
US9769695B2 (en) * 2014-11-04 2017-09-19 Cisco Technology, Inc. Adaptive quality of service for wide area network transport
US20170295086A1 (en) * 2016-04-12 2017-10-12 Dell Software Inc. Single tier routing
US20170295077A1 (en) * 2016-04-12 2017-10-12 Dell Software Inc. Optimal service provider selection
EP3316587A1 (en) * 2016-10-27 2018-05-02 Thomson Licensing Method for managing staggercast transmissions in a communication network comprising a central device and a plurality of user terminals
EP3685598A4 (en) 2017-09-20 2021-04-14 JRD Communication (Shenzhen) Ltd MULTI-BROADCASTING PROCESS, BASE STATION AND USER EQUIPMENT AND STORAGE CAPACITY DEVICE
CN110417735B (zh) * 2019-06-24 2020-09-11 特斯联(北京)科技有限公司 一种智慧城市流媒体管理网络及其方法
CN111200789B (zh) * 2020-01-07 2022-04-26 中国联合网络通信集团有限公司 一种业务数据的传输方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
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
CN101060617A (zh) * 2007-05-22 2007-10-24 华为技术有限公司 一种视频点播控制方法、客户端设备和切换控制装置

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
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
CN101326790A (zh) * 2005-12-13 2008-12-17 艾利森电话股份有限公司 用于经由不同承载类型分发内容的技术
US8613024B2 (en) * 2005-12-13 2013-12-17 United Video Properties, Inc. Cross-platform predictive popularity ratings for use in interactive television applications
US8332899B2 (en) * 2009-06-04 2012-12-11 Centurylink Intellectual Property Llc Dynamic VOD channel allocation based on viewer demand
CN102137277B (zh) * 2010-08-17 2014-04-30 华为技术有限公司 实现交互式轮播频道的方法、装置及系统
US20140168277A1 (en) * 2011-05-10 2014-06-19 Cisco Technology Inc. Adaptive Presentation of Content

Patent Citations (2)

* Cited by examiner, † Cited by third party
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
CN101060617A (zh) * 2007-05-22 2007-10-24 华为技术有限公司 一种视频点播控制方法、客户端设备和切换控制装置

Also Published As

Publication number Publication date
WO2014155046A1 (en) 2014-10-02
CN105103518A (zh) 2015-11-25
US20160057249A1 (en) 2016-02-25
US10084883B2 (en) 2018-09-25
EP2979423A1 (en) 2016-02-03
EP2785005A1 (en) 2014-10-01
EP2979423B1 (en) 2019-06-12

Similar Documents

Publication Publication Date Title
CN105103518B (zh) 将内容从源传递到目的地的方法和装置、计算机可读介质
CN105075218B (zh) 分发内容的方法、网络设备和计算机可读存储介质
US10484440B2 (en) Content distribution system and method
CN105340216B (zh) 在目的地处从内容递送网络接收一条内容的方法
Wichtlhuber et al. TRANSIT: Supporting transitions in Peer-to-Peer live video streaming
Liang et al. Incentivized peer-assisted streaming for on-demand services
US10284920B2 (en) Content distribution system and method based on information relating to destination capability and network conditions
Yang et al. Software-defined multimedia streaming system aided by variable-length interval in-network caching
US10356482B2 (en) Content distribution system and method
CN101715118B (zh) 视频点播服务的流量管理的方法和系统
Wen et al. QoS Supported IPTV Service Architecture over Hybrid‐Tree‐Based Explicit Routed Multicast Network

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