CN105075218B - 分发内容的方法、网络设备和计算机可读存储介质 - Google Patents

分发内容的方法、网络设备和计算机可读存储介质 Download PDF

Info

Publication number
CN105075218B
CN105075218B CN201480018773.0A CN201480018773A CN105075218B CN 105075218 B CN105075218 B CN 105075218B CN 201480018773 A CN201480018773 A CN 201480018773A CN 105075218 B CN105075218 B CN 105075218B
Authority
CN
China
Prior art keywords
content
multicast
host
source
unicast
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
CN201480018773.0A
Other languages
English (en)
Other versions
CN105075218A (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 CN105075218A publication Critical patent/CN105075218A/zh
Application granted granted Critical
Publication of CN105075218B publication Critical patent/CN105075218B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/026—Details of "hello" or keep-alive messages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/83—Admission control; Resource allocation based on usage prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5061—Pools of addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5069—Address allocation for group communication, multicast communication or broadcast communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • 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/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • 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/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2408—Monitoring of the upstream path of the transmission network, e.g. client requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/251—Learning process for intelligent management, e.g. learning user preferences for recommending movies
    • H04N21/252—Processing of multiple end-users' preferences to derive collaborative 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/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/47202—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 content on demand, e.g. video on demand
    • 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/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)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Human Computer Interaction (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

分发内容的方法、网络设备和计算机可读存储介质。一种在内容递送网络中从源分发内容的方法，所述方法包括：监视对内容项的传送的请求；获得关于所述内容的未来需求的预测；应用单播至多播切换决定算法，切换决定算法考虑未来需求的预测并且被设置为确定至少一个条件是否被满足；并且，根据单播至多播切换决定算法的结果，开始针对内容项的多个单播数据流到一多播数据流的转换。

Description

分发内容的方法、网络设备和计算机可读存储介质
技术领域
本发明涉及多播路由的领域。
背景技术
诸如音频和/或视频的数字媒体可以以单播或多播传输模式在数据通信网络上从源到主机(终端用户)进行流式传输。示例应用包括电视和视频服务(包括所谓的“点播”服务)以及视频会议。在单播传输中，媒体从源到由唯一的地址确定的单个网络目的地被流传输。在多播传输中，媒体在单个传输中同时从源到一组主机被流传输。
多播网络分为以下两部分操作：一个是使用诸如因特网组成员协议(IGMP)的协议管理对组的主机的成员，并且第二个是管理对在网络中预订内容源的组的路由器的成员。本领域的技术人员将理解，存在许多使用不同技术以建立组成员树的多播路由协议。本工作是可适用的，但绝不限于，独立多播协议-稀疏模式(PIM-SM)路由，RFC 4601。
在单播模式中，当主机(终端用户)需要一段媒体内容时，它使用带有它想接收的所述内容或播放列表的统一资源标识符(URI)的媒体流协议发送请求。典型的协议的示例包括无状态HTTP流或者有状态的实时流协议(RTSP)。RTSP通常使用实时传输协议(RTP)来传送内容本身，然而HTTP在它的对GET消息的响应中使用HTML主体传送内容。这使用IP来封装并且被路由到媒体服务器。然后，使用单播将内容发送到主机。如果高速缓存就位，则继对该段内容的进一步请求被指向高速缓存而不是数据源之后，对短时间段内的同一内容的多个请求触发对内容的缓存过程。然而，每个源从高速缓存或者源接收数据的单播流。这通过网络导致数据复制，期望该数据复制最小化以便对网络容量进行更有效的使用。触发多播是解决该问题的一种方法。
按照惯例，这样的触发响应于被交叉的上和/或下使用阈值被反应性地发起。如果上阈值被超过，那么传输从单播切换到多播。当使用低于下阈值时，那么传输返回到单播。
发明内容
根据本发明的第一方面，提供了一种在内容递送网络中从源分发内容的方法，该方法包括：监视对内容项的传送的请求；获得针对所述内容的未来需求的预测；应用单播至多播切换决定算法，切换决定算法考虑未来需求的预测并且被设置为确定至少一个触发条件是否被满足；并且根据单播至多播切换决定算法的结果，开始针对内容项的多个单播数据流到一多播数据流的转换，其中，针对所述内容的未来需求的预测是基于与针对所述内容的实际需求无关的数据。与对所述内容的实际需求无关的数据包括从社会数据源获得的数据和/或从搜索引擎获得的数据。
通过以这种方式使用未来需求的预测，多播流可以主动地和自主地被发起，从而改善网络资源的分配。
可选地，该方法还可以包括保持针对所述内容项的针对指向所述源的所述请求的统计记录，并且使用所述记录中的至少某些所述数据来获得所述未来需求的预测。
通过例举的方式，未来需求的预测可以是基于先前时间段上的激活的会话的数量。另选地，它可以是基于先前时间段上的激活的会话的平均数量，通过在所述时间段内的时刻确定激活的会话的数量以及确定其平均来评价激活的会话的平均数量。
未来需求的预测可能被限定于一天的时间(例如，关于每小时的新闻广播)、和/或一周的天。
可选地，切换决定算法可以考虑统计记录中的数据。
可选地，切换算法可以考虑统计记录中的一个或多个参数，所述参数选自包括以下项的组：激活的会话的当前数量；在给定的时间段期间对所述内容的请求的总数；平均会话持续时间；会话过早地结束的概率；所述内容的数据大小。
该方法还可以包括保持选自包括以下项的组的一个或多个背景动作：周期性地选择引导路由器不考虑在网络中正进行多播；候选引导路由器将他们的候选状态告知给所选择的引导路由器；多播路由器向彼此发送“hello”消息，而不考虑在网络中正进行多播。
可选地，将多个单播流转换为多播流的过程可以包括：生成组地址系统；创建针对将被切换到多播的内容的会话描述信息；并且将主机加入多播数据流。
转换过程还可以包括生成关于所述内容的多播特定的统一资源指示符。
生成组地址系统可以包括分配针对每个统一资源标识符的一组地址，或者为主机组和源的每个地理位置组合分配组地址。
此外，生成组地址系统可以包括使用一组现有的组地址，或使用动态的地址池。另选地，可以从地址分配服务器接收一组地址。
转换过程还可以包括在被发送到各自的会合点的登记消息中封装来自源的分组。
如果主机已经请求单播数据流并且还没有开始接收该流，则转换过程还可以包括响应于发送到主机处的浏览器的代码嵌入新的多播统一资源标识符，或者向主机发送包括组地址或者统一资源标识符的消息以获得该组地址。
如果主机已经开始接收单播流，则转换过程还可以包括使用反向信道来向主机发送组地址或者统一资源标识符以获得组地址。如果RTSP正被用于单播中，则该过程还可以包括使用宣告(Announce)、重定向或者设置参数(Set_Parameter)请求向主机宣布变化。
此外，转换过程可以包括响应于来自主机的请求使得多播内容在给定的时间开始。
另选地，如果HTTP正在被用于单播中，转换过程还可以包括响应于来自主机的针对流方法的当前状态的请求，提供新的统一资源标识符或者主机可以建立成员关系的组地址。
转换过程还可以包括触发支持多播的扩展的IP模块的上层协议以发出成员加入请求。
可选地，转换过程还可以包括响应于主机检测到正经由单播和经由多播接收到基本上相同的内容，终止单播会话，从而对网络容量进行更有效的使用。
可以在诸如路由器(具体地，源的指定路由器)或服务器的网络设备上或者通过诸如路由器(具体地，源的指定路由器)或服务器的网络设备执行上述方法。
根据接收关于内容项的请求，该方法还可以包括服务器确定是否任何其它服务器具有关于所述内容的任何激活的会话并且，如果有，合并对不同的服务器进行的多个会话请求，使得单个服务器处理多个会话请求。该合并的多个会话请求可以足够触发多播，然而，在合并之前，由单独的服务器处理的会话请求的数量可能还没有完成。因此，该合并过程可以进一步改善网络资源的分配。
可选地，触发条件可以包括针对内容的预测的未来需求的阈值。
根据本发明的第二方面，提供了一种具有配置成根据本发明的第一方面执行方法的逻辑的网络设备(例如，路由器或服务器)。
根据本发明的第三方面，提供了一种计算机可实现指令产品，该计算机可实现指令产品包括用于使得可编程计算设备实现本发明的第一方面的方法或者被配置为本发明的第二方面的网络设备的计算机可实现指令。
在此描述了系统的许多实施方式。对本领域的技术人员清楚的是，这些实施方式中的每一个可以被独立地实现。然而，实施方式彼此结合更好地实现以提供多个优点作为大型系统的一部分。一个实施方式的优选特征可以被直接应用于系统的其它实施方式。此外，方法特征可以被直接应用于装置的方面。
具体地，在上述所有方面中，在多播网络中，目的地可以是主机或者主机指定路由器(H-DR)。主机可以是与末端用户或者内容的消费者有关的末端用户终端，或者可以是向用户的设备供应内容的中间设备。例如，目的地可以是接收用于流传输到诸如互联网连接的电视机、计算机、平板或电话的用户的终端的内容的家庭网络内的集线器。
类似地，在上述所有方面中，源可以是在网络中供应内容的设备，或者可以是处理到目的地的内容的路由的网络中的情报路由部件。内容可以穿过情报路由部件，或者部件可以控制网络中的其它部件(诸如，源)以实现在此描述的方法。
此外，在上述的所有实施方式中，内容优选地是视频内容和/或者音频内容，具体地响应于来自用户的请求传送的点播内容。然而，技术人员将理解，本文描述的系统和方法同样可以被应用于网络针对诸如文本或图像数据的数据或软件的分发。
附图说明
下面将仅通过示例的方式并且参照附图描述本发明的实施方式，其中：
图1是具有多个单播流的网络的示意图；
图2是其中多个单播流已经被转换为自主多播的图1的网络的示意图；
图3示出了在源的指定路由器上操作的“多播使能器”；
图4示出了与多播使能器相关的切换算法的操作；
图5示出了与多播使能器相关的预测算法的操作；以及
图6是根据一个实施方式的实现多播路由的网络的示意图。
具体实施方式
本实施方式代表对于将本发明付诸实践的申请人所已知的最佳方式。然而，它们并不是实现该目的唯一方式。
定义
如在此使用的下面术语具有下面的定义：
主机：从可以通过单播或者多播传送的源请求一些内容的末端用户设备。
源：经由单播发送到主机或者经由多播推入网络的一些内容的提供者。
内容：电子媒介，包括但不限于视频文件/流、线性TV、音频文件/流(会议、广播、播客)、大文件下载等。
播放器：在可以从源下载内容并且将其显示在主机处的主机上运行的软件程序。可以经由浏览器插件(例如，Adobe Flash播放器)将播放器嵌入到网页中。
固定流：以顺序的方式经由一些下载或者流机制进行一段内容的传输。主机将从向前与由源的请求的接收一致的特定的起始位置接收内容。主机不能从该起始位置之前请求内容。
灵活流：以顺序的方式经由一些下载或者流机制进行一段内容的传输。主机自由地从任意起始位置请求内容并且可以在内容中的位置之间自由切换，导致当前内容传送到主机以在所请求的位置停止和恢复。
DR：指定路由器。
网络体系结构
在图6中示意性地示出了本系统的方面可以被实现于其中的网络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或者类似协议被用于对于多播组管理路由器的成员，该多播组预订网络中的内容源。
图6示出了多播网络800，该多播网络800包括多个源810、812、814，每个源能够经由网络向主机816、818、820提供或者供应内容。源连接到在网络中管理从源到部件的内容的传送的源指定路由器(S-DR)830、832。
网络也包括许多将多播流从源810、812、814携带(与其它网络业务一起)到主机816、818、820的中间路由器(IR)836、838。IR可以包括针对特定的多播流的一个或多个会合点(RP)834。RP 834在网络中是路由器，针对特定组的多播数据通过该路由器传递给所有下游路由器，除非下游路由器处于源特定模式。也就是，下游路由器或者主机824、818通过RP834加入多播流。因此，下游多播树集中在RP 834上。
最接近主机或者目的地的路由器可以被称为主机指定路由器(H-DR)822、824。去往特定的主机816的多播流穿过相关的H-DR 822，并且主机发送给它的H-DR请求以使用IGMP从特定的多播组加入或者删除。
通过进一步举例的方式，在多播组G中多播内容的源812为该内容遍及网络广播告知消息。主机H2 818接收告知并且希望接收多播数据。主机818将指定它希望加入的多播流的多播地址的IGMP加入请求(如告知消息中所详述的)连同它的成员信息一起发送给它的H-DR 824。H-DR 824通常基于通过网络回到针对内容的S-DR 830的最短路径建立返回到内容的源812的多播树。然而，在大多数操作模式下，多播树必须穿过为该多播流指定的RP834，即使这些IR将提供回到S-DR 830的更短的路径，也不通过其它IR 838。H-DR 824针对具有激活的下游成员的每个组向组特定RP 834发送周期的加入/删除消息。
如果多播树已经向其它主机递送内容，H-DR 824简单地建立返回现有的多播树的分支。如果该主机在网络的那个区域中是首先请求内容的，则树可以被建立返回到S-DR830。在图6中由虚线840指示多播树。一旦多播树已经被建立，多播内容可以沿着树向下被递送至H-DR 824，并且从这里到提出请求的主机818。
在基于PIM-SM的多播系统中，当主机指定路由器(主机-DR)从它的主机中的一个接收到成员报告以加入组G的时候，它使用它的单播协议查寻作为在最短路径上朝向RP(会合点树，RPT)或源(最短路径树、SPT)的下一跳的邻居的地址。当中间路由器接用相同的请求从下游路由器收加入/删除消息时，相同的动作被执行。他们使用单播协议的路由度量作为与反映通过其该成本被获悉的方法的度量偏好相关的MRIB路由度量(即，每个单播协议具有相关的度量偏好值，并且如果度量偏好值是相同的则度量成本只能被比较)。具有最低成本的下一跳邻居被选作加入/删除消息被发送至的上游邻居。加入/删除消息(由于其一直行进到RP或者源)触发每个路由器中组相关路由条目的创造。被建立到RP或源的该反向路由被用于在从RP或源到末端主机的下游方向上路由多播数据分组的流。
多播树840上的每个路由器用内部数据库(诸如，多播路由信息库(MRIB)，其包括诸如源地址、组地址、接收数据分组的入接口以及分组应该被发送至的、以便沿着多播树向下传送的出接口列表的信息)保持路由条目。定时器、标志位和其它信息也可以被存储在MRIB条目中。
为了离开多播组G，主机818向H-DR 824发送删除请求，该H-DR 824然后通过多播树向上传播以拆卸树的该分枝直到该树需要向其它主机递送多播数据的点。
“多播使能器”的概述
我们提出了一种被称为"多播使能器"的新颖的实体，该实体基于预测数据分析使得网络在单播模式下操作以自主地切换到多播模式。当多个用户在实时流模式(例如，新闻项目或者不允许特技模式操作的体育竞赛的实时流)下或者作为渐进式下载请求一段流行的内容时，这是特别有用的。我们在我们的示例中使用PIM-SM，但是原理也可以被翻译成其它多播路由协议。我们利用由源的指定路由器(在此后，源-DR首先从源向主机或者会合点(RP)跳跃)收集的数据。我们监测在源-DR处对于给定的URI的请求的命中率，以及社会数据源以通过多播树以反应性和预测性的形式触发若干针对源的单播数据流到单个多播流的转换。我们假设所有网络元素运行单播路由协议、主机支持IGMP以及网络支持PIM-SM中的路由器。
多播使能器的功能可以被分布跨越源-DR和主机-DR PIM路由器或集中运行，评估触发条件并且当它们都满足时发出进入网络的动作。我们假设其中情报被放置在主机和彼此通信的源节点中的分布式系统。
图1和图2示出了由多播使能器使得能够进行的转换，其中图1示意性地示出具有多个单播流的网络，并且图2示意性地示出其中单播流已经自主地切换到多播的相同的网络。
通过例示的方式，在图1中，网络链路L1和L2携带相同数据的四个副本(由不同类型的虚线表示)到主机H1、H2、H5和H6。在我们的多播使能器的操作之后，数据流将看作如图2所示。仅有作为多播流动的数据的一个副本，伴随着主机H1、H2、H5和H6已经使用IGMP预订针对该流的相关的组。很明显，当可能使得更好地使用网络容量时阻止在网络中的数据复制。通过多播树将(以最短路径树(SPT)或者RP树(RPT)两者的形式)多个单播流简化为来自源的单个流给主机提供了更好的服务质量，代替他们必须彼此竞争以通过链路共享消耗相同的数据。
决定机制
该部分描述了由多播使能器评估的用于从单播切换到多播的触发条件。
当主机从源请求内容时，它连接到URI(例如，http://www.youtube.com/watch？v＝AvbSMBKBZgY)以从源youtube.com请求视频文件。通常通过用户选择显示在网页浏览器中的网页中的链接或者通过进入它进入可以播放所请求的内容的播放器来触发URI请求。典型的播放器是微软的Windows媒体播放器、开源播放器VLC、苹果公司的QuickTime、或经由JavaScript嵌入到网页并且在主机上使用Adobe Flash浏览器插件以播放内容的Flash播放器。许多播放器可以被用作主机上的独立软件或者用作在网络浏览器(如，因特网浏览器(Internet Explorer)或火狐浏览器(Mozilla Firefox))内的网页中显示内容的浏览器插件。上述YouTube URI将导致Flash视频文件在浏览器窗口中被播放。注意，尽管我们使用浏览器情况作为示例，但是本工作同样地应用于例如TV机顶盒情况。两种情况之间的变化主要在于用于数据传输的协议栈，并且在本工作中，我们仅从底层协议指定所需要的功能。
通常经由单播进行从源到主机的下载作为渐进式HTTP下载。媒体内容在一个HTML文件的主体中被返回。媒体的编码被提供为允许浏览器或播放器识别针对内容的正确的处理器的MIME类型。传输内容的该方法不允许主机暂停或者终止服务器上的重放，因为HTTP是无状态的。通过使用连接到内容文件的元数据，渐进式下载可以允许用户在任何时间充分寻找和导航，而不需要完整文件下载。通过使用带宽限制(指定文件应当被传送的比特率)，可能仅传送将被查看的量的内容，防止浪费带宽。
供替代的选择将经由诸如实时流协议(RTSP)、实时传输协议(RTP)、或者需要专用的播放器和服务器的实时控制协议(RTCP)的流协议提供内容视频。如果使用如RTSP的流协议，那么由播放器最初请求的URI可以指向包含多个指向内容文件的URI的列表文件。播放器然后决定以哪个顺序播放哪个文件或者允许用户从这些播放列表项目中选择和在这些播放列表项目之间切换。播放一些内容的请求也将经由超文本传输协议(HTTP)被发送到源，但是代替单一的URI，该请求将被嵌入在HTTP上运行的特殊的协议。
下文提供用于经由RTSP请求内容的示例。C表示客户端(主机)以及S表示服务器(源)。客户端发送DESCRIBE请求，接着是SETUP和PLAY请求。DESCRIBE请求包括RTSP URL(rtsp：//...)以及可以被处理的类型的应答数据。针对UDP(弃用并且很少使用)和TCP传输两者，用于RTSP协议的默认端口是554。该应答包括演示说明，通常为会话描述协议(SDP)格式。其中，演示说明列出用聚合的URL控制的媒体流。在典型的情况下，存在用于音频或视频的一个媒体流。
C-＞S：DESCRIBE rtsp：//example.com/media.mp4 RTSP/1.0
CSeq：2
S-＞C：RTsP/1.0 200 OK
CSeq：2
Content-Base：rtsp：//example.com/media.mp4
Content-Type：applica-ion/sdp
Content-Length：460
m＝video 0RTP/AVP 96
a＝control：streamid＝0
a＝range：npt＝0-7.741000
a＝length：npt＝7.741000
a＝rtpmap：96MP4V-ES/5544
a＝mimetype：string；″video/MP4V-ES″
a＝AvgBitRate：integer；304018
a＝StreamName：string；″hinted video track″
m＝audio 0 RTP/AVP 97
a＝control：streamid＝1
a＝range：npt＝0-7.712000
a＝length：npt＝7.712000
a＝rtpmap：97 mpeg4-generic/32000/2
a＝mimetype：string；″audio/mpeg4-generic″
a＝AvqBitRate：integer；65790
a＝StreamName：string；″hinted audio track″
SETUP请求指定单一媒体流如何必须被传送。这在发送PLAY请求之前必须被完成。该请求包括媒体流URL和传输说明符。该说明符通常包括用于接收RTP数据(音频或视频)的本地端口以及用于RTCP数据(元信息)的另一个端口。服务器应答通常确认所选择的参数，并且填充在缺少部分(诸如，服务器的选择的端口)中。在可以发送聚合的播放请求之前，每个媒体流必须使用SETUP被配置。
C～＞S：SETUP rtsp：//example.com/media.mp4/streamid＝0RTSP/1.0
CSeq：3
Transport：RTP/AVP；unicast；client_port＝8000-8001
S～＞C：RTsP/1.0 200 OK
CSeq：3
Transport：RTP/AVP；unicast；client_port＝8000-
8001；server_port＝9000-9001
Session：12345678
PLAY请求将引起一个或所有媒体流被播放。可以通过发送多个PLAY请求堆积播放请求。URL可以是聚合的URL(以播放所有媒体流)，或单一媒体流URL(以播放仅那个流)。范围可以被指定。如果没有指定范围，则从开始播放流并且播放到末尾，或者，如果流被暂停，则在暂停的点处恢复。
C-＞S：PLAY rtsp：//example.com/media.mp4 RTSP/1.0
CSeq：4
Range：npt＝5-20
Session：12345678
S-＞C：RTSP/1.0 200 OK
CSeq：4
Session：12345678
RTP-Info：
url＝rtsp：//example.com/media.mp4/streamid＝0；seq＝9810092；rtpti
me＝3450012
存在针对允许客户端暂停或终止播放内容的RTSP的其它命令。
在该工作中，我们将考虑大量的主机从源请求相同的内容的情况。我们假设所有主机从相同位置播放内容，即内容以固定流的某种形式被传送，并且在源仍播放出固定流(即，它已经完成之前)的同时主机可以在任何时间加入该流。我们进一步假设源经由单播向每个主机传送内容作为单个固定流。
为了经由单播提供相同内容的许多相同的副本浪费了网络带宽。因此，在网络运营商的兴趣内以检测这种情况，并且由一个多播副本替换该内容的许多单播副本。
考虑被连接到源并且提供到源的互联网接入的网关路由器。如果该路由器被多播嵌入，则在多播情况下它将变成源的源DR。我们现在指定源DR可以如何检测许多单播固定流正在作为前导被播放出以切换到多播。
本质上，并且参照图3、图4和图5，多播使能器10(例如，在源DR 12上或在别处运行)监视针对源14的关于一段媒体内容的请求，并且获得关于该特定内容的未来需求34的预测。考虑未来需求34的预测，多播使能器10确定单播至多播切换算法22的结果。如果切换算法22的结果是触发条件被满足，则它启动(24)关于正讨论的内容的多个单播数据流到一个多播数据流的转换。如果切换算法的结果是触发条件没有被满足，则它保留多个单播数据流并且不启动到多播的转换(26)。
更详细地，源DR 12的多播使能器10监视针对源14的所有请求，并且保持URI的表TURI和相关的计数器以及其它值(见下面表1)。表TURI可以被存储在多播使能器10的表存储模块16内或者在别处(例如，在经由网络连接的分离的设备上)。源DR 12优选地也考虑如果在负载平衡情况下可以从不同的源传送相同的内容。只要这些源被连接到相同的源-DR，这可以例如通过剥去URI的第一部分(例如，www.example.com、www1.example.com、www2.example.com都映射到example.com)被完成。
每当经由来自互联网上的一些主机的进入请求检测到URI，该表中的条目就被创建或者更新。源DR检查URI是否已经存储在表中，如果没有，它创建新的条目并且将计数器设置为1。如果条目存在，则计数器增加。源DR也保持与URI的下载相关的会话的列表。每当会话被终止，相应URI的计数器就减小。
如果URI代表在更长的时间段上可用的内容，则源DR也可以收集针对每个URI的附加的细节。这将是例如如果该内容代表每小时播放出的有规律地重复的一段内容的情况。这可能是内容针对每次播出而改变的每小时新闻节目或再次每15分钟提供的电影等。这些额外的细节可以是持续时间或内容的大小、被请求的内容的过去频率、在特定时刻被请求的内容的概率、由于主机停止接收内容会话被提前终止的概率、在会话的数量属于阈值之外之前播放出的内容的平均持续时间等。所有这些细节可以被源DR使用以决定是否或何时启动多播，如在图4的流程图中所示意性地示出的以及如关于切换算法22在以下更详细地描述的。
表TURI也可以包括关于对所讨论的内容的未来需求的预测信息。如图5中所示意性地示出的，在源DR(例如，在多播使能器10的需求预测模块18中)上或者在别处运行的预测算法28可以监视内容消耗和正被请求的内容的类型。基于TURI中的细节(例如，数据30)或者通过使用附加信息，该算法可以预测与URI有关的一段内容有多受欢迎，并且这可以被用于当第一个请求到来时立即开始多播，否则被用于改变何时切换到多播的决策策略。附加信息32可以来自社交网络，通过过滤例如用于内容推荐的Facebook或者Twitter业务、或新闻内容可以针对可以指向新闻节目具有高的被请求的机会等的事实的事件(例如，旧金山大地震)被过滤。趋势数据也可以从搜索引擎获得。通常，这些技术在内容推荐器引擎中是公知的。来自这种引擎的信息可以被用于修改另外仅基于历史数据的未来内容请求的预测。算法28使用这种信息来生成针对非常受欢迎的一段内容的似然值34，并且这种似然值可以依次被源DR使用以修改它的用于将内容传送切换至多播的策略。
表1：表TURI的示例
表1的关键词(以及下面的表2和表3)：
N＝激活的会话的当前数量
MC/UC＝多播(MC)或单播(UC)
C24＝前24小时的计数
CW＝上周的计数
P＝会话过早结束的概率
S＝大小(MB)
AD＝平均会话持续时间(分钟)
PS0...23＝一天的时间对内容的预测的需求
(条目的向量：小时.分钟：预测的会话的数量)
表1包括针对TURI中预测信息的一个示例。表1的最后一列包括在接下来的24个小时内每小时的预测会话数量。可以由许多类型的预测算法计算这些数字。一种非常简单的方法是在最后例如3天的每个完整的小时给激活的会话计数，并且使用激活的会话的平均数作为对接下来24小时时段的预测。将每小时地更新这些数字。也可能针对内容的类型使用更长期的平均。例如，通过测量新的电影的卷绕(take-up)，有可能生成针对可以被用于估计针对一天的每个小时的所请求的会话的数量的最初几天的典型的观看轮廓(见表1的最后一列)。可以使用本领域的技术人员已知的其它更复杂的预测算法。
示例：每小时地计算针对内容URI的需要，其中，Nt是在时间t的需要计数。
如图3所示，源DR使用TURI决定一些内容的传送是否应该被切换至多播。例如，如果会话的当前数量超过某一阈值(例如，20)，并且预期的/预测的平均持续时间足够长(例如，10分钟)，以及过早地结束会话的概率小于某一概率(例如，0.5)等，则当前经由单播服务的一些内容URI可以被切换至多播。针对该实施方式，我们假设下面简单的切换逻辑使用t作为该天的当前小时并且使用当前和预测的信息(其它更复杂的决定逻辑可以被实现)：
IF没有多播AND N>20AND AD>10AND P<0.5AND S>100AND PS(t+1)>N/2
THEN切换至多播
ELSE继续单播
每当计数器针对还没有在多播上的URI增加，决定逻辑就针对该URI再次被调用。
随着触发条件被满足在网络中采取以下动作：
该部分描述一旦触发条件被满足就采取的动作。
这里有两组可以进行的动作以便成功地从单播切换至多播。由于，在目前优选的实施方式中，我们使用现有的PIM-SM建树法，候选的RP(C-RP)和候选的引导路由器(C-BSR)可能已经建立。组地址尚未被分配，因为这依赖于此时的预订需求。鉴于此，以下的背景动作被保持以最小化针对转换所花费的时间。在另一个实施方式中，一旦多播工作，就可以部分地或者全部地进行这些动作，但是我们的方法使在多播条件被满足和它在网络中是完全可操作的之间的延时最小化。
1.周期性地进行BSR选择而不考虑在网络中正进行多播。
2.C-RP向所选择的BSR告知它们的候选资格，同时将组地址设为”0”，使得当PIM路由器加入网络时BSR可以生成引导消息。
3.即使所有业务保持单播，启用了PIM的路由器也向彼此发送Hello消息。这导致它们具有当多播被触发时用于组到RP映射的RP集合。随后，当主机加入各自的组时仅加入/删除消息需要被传播。
一旦我们提出的多播使能器决定将一段内容(基于URI)从单播切换至多播到X个主机，如下的其它动作被我们提出的多播使能器触发。我们假设所有主机具有选择连接到主机存在的本地子网的主机DR，如在RFC 2362和RFC 4601中所提出的。
1.组地址系统被生成。存在许多方法做这件事。一种方法是为每个URI分配一个组地址。这可能导致大量的组地址是可用的。在另一种方法中，可以为每个主机组和源的地理位置组合分配组地址，使得组地址的哈希函数生成最接近于源和组成员两者的RP，使得RPT结构更有效。多播地址动态客户端分配协议(MADCAP)在RFC2730被提出，用以主机请求并且被分配多播组地址。
这里已经存在通过IANA的永久的多播地址分配。如果用户具有指定的范围的可用性，这样的一个实现可以跨越在网络上传递的所有内容使用该现有的组地址的集合。另选地，可以使用可以被再用作从管理的范围崩溃组的动态的地址池。
地址分配服务器管理这方面并且向源DR针对它的单播源地址返回组地址。使用源单播地址、RP集合(使用到“ALL-PIM-ROUTERS”的引导消息被充满)、组地址和哈希掩码，使用在RFC 4601中描述的现有的哈希函数方法进行RP到组的映射。
2.源DR创建针对相同的内容的所需要的会话描述信息(会话描述协议)，现在将被切换至多播模式。根据这对于客户端重新预订多播流来说是否是必要的，也触发源以生成针对该内容的多播特定的URI。
已经决定切换到针对给定的媒体流的多播的源DR接着将登记消息中针对该流的来自源的到来的分组封装到相应的RP。注意，如果单个源保存许多内容片段并且源DR已经决定完全地切换到多播，则相应的源DR根据组地址登记带有各自RP的每个内容片段。另选地，如果仅一些内容流被切换到多播，那么源DR仅处理针对这些流的登记消息。
如果没有组已经由此点被创建，则RP向源发送登记-停止，但是创建至源的SPT路由表项而没有输出接口。
3.存在针对主机加入多播流的两种可能情况。它可以具有现有的单播会话，伴随着媒体服务器使用诸如RTSP/RTP的媒体流协议集合，或者当它第一次请求来自源的内容时它可以被分配多播组信息以立刻连接。当多播会话已经被建立时后者是可适用的，并且主机很乐意接收当前被传送的数据(例如，实时流/TV而没有追赶服务)。我们将分别考虑这些情况中的每个情况：
a.来自主机的新鲜的请求
主机请求单播流，而不知道多播流或它的组地址的存在。鉴于存在几个包括只有特定的殊媒体服务器实现才有的专有的那些的媒体流和控制协议，我们指定一个必须实现从服务器到应当经由多播预订服务的客户端进行通信的方法。这可以通过在响应于客户端浏览器的HTML中嵌入新的多播URI或者在单播请求被服务器/源DR接收到之后使用响应消息来进行，该服务器/源DR给客户端提供组地址字符串或URI以获得这种方法。例如，当浏览器请求该链接时，服务器改变链接到内容流的HTML字符串，使得主机被直接映射到多播流而不用进一步交换。
b.将现有的单播流传递到多播树
这需要从源/源DR到主机的实时反馈，需要它以建立新的多播会话。其具体的实现依赖于针对具体的媒体流实现的协议栈。如果反向信道针对服务器是可用的以向客户端发送命令，这可以被用于发出新的多播组地址字符串或URI以获得此。另选地，如果RTSP正被用于单播中，则源使用宣告、重定向或者设置参数(Set_Parameter)消息来请求向主机宣布该变化。主机也可以被设置以进行周期的获得参数(Get_Parameter)请求以证实针对它的会话的当前多播/单播状态。也可能主机请求内容以在给定的时间开始，使得流可以从转换已经被触发的点继续进行。该特征无法被用于固定流下载中，但是我们稍后将返回于此。如果使用HTTP，则主机可以被配置成周期性地请求流方法的当前状态，其中，媒体服务器/源DR用新的URI或者主机随后必须建立成员关系的组地址对该当前状态进行响应。
两个步骤的结果是上层协议触发扩展的IP模块(RFC 1112)，该扩展的IP模块(RFC1112)支持多播以向它的直接连接多播路由器发出成员加入请求。大多数主机实现下文中在我们的实施方式中将使用的但是消息本身是协议相关的IGMP。
带有特定的组地址的IGMP成员报告(IGMP加入)被发送至主机DR。这导致在主机DR中从它的停用状态变化到JoinDesired(*,G)或者JoinDesired(S.G)状态(实现-相关)。针对该变化创建路由条目。
随后，主机DR使用已知的哈希函数触发朝向RP或源的a(*,G)或(S,G)加入/删除消息。是否触发RPT或SPT的选择依赖于实现。我们覆盖RPT所需要的设置，从其很好地理解SPT。RFC 362和RFC 4601中覆盖了所有这些动作以及何时使用每个选项。本工作的创新的方面是基于我们的预测的分析方法触发多播功能的网络的自主的能力。详细的实施方式是基于PIM-SM的示例。
加入/删除消息基于单播路由协议(OSPF、IS-IS、RIP是这种的示例)逐跳的朝向RP或源行进。使用原始的多播方法完成建立树的该方面。随后，RP或源开始从所请求的时间范围(如果可适用)向主机多播内容。在这一点上，主机接收相同的内容的两个副本。
完成到多播的切换的最后的方面是主机去检测相同的内容的多个副本被正被接收的能力。这可以通过媒体播放器使两个流(在不同的接口上接收的，由上层协议指定)彼此匹配并且使用模式检测以识别一个流等同于另一个流。明显地，除了由于网络拥塞的性质和逐跳传递导致的流之间的潜在的时延变化之外，传输中的错误应该被考虑。
另外，值得注意的是接收到的两个流在时间上不是精确地匹配的情况。在该实施方式中，我们假设所有主机接收相同的实时流并且基本上是同步的。然而，由于网络延时，分组可以在不同的时间到达主机，导致单播流和多播流之间的小的时间差。接收主机必须能够使用它的缓冲能力或者对于媒体播放器使可用的上层协议从一个流转换到另一个流。主机的缓冲器可以存储两个流上到来的分组，如果是支持的/可应用的则潜在地也请求丢失的块，同时仅向用户播放一个同步的流，直到两个流交叠。如该协议所指示的，一旦这已经被实现，不考虑单播流是在通过多播树接收的流之前还是之后，主机必须结束与源的单播会话。在RTSP中，例如，这是通过向服务器发送拆卸消息(Teardown message)来完成的。如果对于多播来说转换无法被实现，则主机可以发出离开该组的IGMP，这导致它的组成员被终止并且在该接口上不再接收多播。另选地，可以使用单播故障修复机制。
注意，当我们使用PIM-SM、IGMP和RTSP或HTTP作为示例时，我们的目的是覆盖该功能而不是阻止在主机、路由器和媒体服务器之间向后和向前发送特定的消息。
上述过程的结果是已经用情报加强源/源DR以决定根据内容的使用和它的预测需求自主地触发网络中的多播。我们的系统的发明的方面是智能能力和机制以使用称为“多播使能器”的新颖的实体自主地触发从多个单播流到单个多播流的切换，并且它的效果是触发多播树的构建以及对于该树的源/主机成员。当我们假设这里的单个建树机制时，其它实施方式也可以使用多个多播树。
来自多个源的相同的内容流的合并
该部分描述了可以如何使用由内容服务器的源DR应用的技术将从多于一个的内容服务器被发送的多个相同的流合并到单个服务器上。
我们考虑具有来自一个以上的内容服务器的可用的相同的内容片段的附加的复杂性。鉴于到目前为止我们已经描述的，客户端将(潜在地通过负载平衡器)被单独地指向这些服务器中的每个。这可以导致两个内容服务器可以潜在地分别发送x个和y个会话的情况，这里x和y值两者都没有达到满足触发多播的条件，但是在单个内容服务器上(x+y)个会话的组合实际上将触发多播。我们提供优化该条件的解决方案。
我们提出当在源DR处从客户端接收到请求时，发现包括该内容的副本的哪个DR当前具有针对该段内容的激活的会话。这通过使用诸如HTTP的协议来完成，以向其它源DR宣布给定的请求已经到达生成该告知的源DR。例如，对于在两个内容服务器A和B上是可用的内容X，到达服务器A的请求触发从服务器A到B的消息，宣布对内容X的请求已经到达服务器A。服务器B在接收到该请求时验证它的多播表(上述表1)以确定在到客户端的会话中内容X当前是否被发送。在这一点上，内容是否作为单播或多播正被发送并不重要。
然后，我们可以具有两种情况：一种是服务器B不具有针对该内容的激活的会话(即，不存在具有特定内容片段的其它服务器)，在这种情况下，服务器A继续处理如上所述的请求，好像它是内容X的仅有的提供商。它可以根据规定的条件将该内容作为单播提供给请求客户端(例如，所谓的C)，开始新的多播流或者如上所述给用户预订现有的多播流。
然而，如果服务器B在其表格中不具有针对内容X的现有的会话，那么它将该信息返回到服务器A。服务器A现在向客户端C发出带有针对服务器B的地址的重定向消息。一旦客户端向服务器A发送对内容X的请求，则该内容服务器继续处理该请求，好像它是内容X的仅有的提供者。
使用该机制，我们合并会话请求使得单个片段的内容将由一个内容服务器服务，并且当相关条件被满足时，多播将从该内容服务器被触发。当当前会话结束时，对内容X的下一个请求将被发送到两个内容服务器的两者之一(例如，由负载平衡器所确定)。这导致这样的系统，即，只要内容服务器继续发送一段内容，它将经由从其它源DR重定向继续接收所有对该段内容的请求，并且将必须将该内容提供给客户端。当在内容服务器上没有针对一段内容的更多激活的会话时，下一个请求将由下一个分配的内容服务器服务，该内容服务器接着将是针对未来会话的主要的合并点，直到没有更多激活的会话。
工作的示例
这里我们提供在现有的RTSP会话上切换到多播会话的示例，假设后面的请求触发多播，并且网络必须参与到包括建立针对现有的内容用户的成员的多播模式下，该内容用户被源切换到多播流并且随后终止现有的单播流。
尽管多播在网络中不是激活的，我们针对该示例假设一些背景任务被实施。当多播没有被开启时实施这些任务一直不是必要的，但是当触发条件最后被满足的时候执行它们可能减少全部操作的时间。这是如在标题为“来自多个源的相同的内容的合并“的上述部分中所描述的。我们考虑使用针对单播和多播两者的局部范围的地址的专用网络。BSR被周期性地选择，C-RP使用以”0”作为它们的组地址的C-RP-Adv消息向BSR告知它们的候选资格。BSR有规律地向“ALL-PIM-ROUTERS”灌注引导消息以向休眠的PIM路由器传达RP设置，使得当一旦多播必须被进行而不需要必须等待RP设置被发送给它们时，它们可以执行组到RP映射哈希函数。第三，DR选择使用断言消息规律地发生以确保每个子网或本地主机的组具有当需要时可以接收它们的成员报告的多播使能的路由器。第四，使用到彼此的周期的Hello消息保持PIM路由器是活动的。可以在PIM-SM RFC 4601和RFC 2362中发现执行这些任务的方法论和选项。
现在考虑由主机H1(地址：10.1.4.10)请求的到源S(IP地址：192.168.10.10)的固定流，这在浏览器(rtsp://example.com/application/contentStream)上使用提供给H1的URI已经被解决。我们称该固定流为C1。假设该URI映射到仅一个源地址以便避免由负载平衡器引入的复杂性。另外假设主机支持RTSP。媒体播放器使用RTSP设置消息触发对该URI的请求。该流的设置、播放和控制是现有技术并且可以从RFC2326理解。
表2：在来自H1的请求之后从TURI提取，时间是t＝16.58
在稍后的时间，主机H2(IP地址：10.1.4.11)也请求相同的URI。这再次触发评估逻辑。根据表2，我们现在具有TURI中的以下参数：N＝20、AD＝97、P＝0.01、S＝567、PSt+1＝P18＝233。
使用我们的评估逻辑
IF不是多播AND N>20AND AD>10AND P<0.5AND S>100AND PSt+1>N/2
THEN切换至多播
ELSE继续单播
导致将流切换至多播，并且导致更新TURI中的行，如表3所示。
表3：在来自H2的请求之后从TURI提取，并且结果切换至多播，时间是t＝17.01
除此之外，源也建立诸如表4中所示的一个的记录，该记录保持关于给定片段的内容的用户的信息(URI)。
表4：简单的URI主机映射表
源可以针对来自初始RTSP请求的被请求的URI登记主机的IP地址。然而，最好有一种用于获得关于主机继续成为给定的组的成员(并且因此仍然接收固定流)的知识的方法。该信息可以通过作为RTSP的一部分发送的保持激活的消息被获得，其向源通知来自给定会话的数据仍然正被消耗。该信息被用于针对现有的单播接收器触发针对该段内容从单播至多播的迁移(如下)。
如果可能，相同的数据可以针对多播成员被收集，尽管注意到这接着不同于没有给定组的所有主机的知识的传统的PIM-SM/IGMP方法。如果可以从主机-DR或IGMP探听设备(如果到位)周期性地收集继续的主机成员到组的数据(并且因此内容)，则它可以用于触发返回在这些主机上的单播，多播应当在后来的时间里不再被期望。如果在网络中存在一种以更通用的哪个主机DR预订哪个组的知识仍然可以从所存储的数据可推导的方式聚集成员的方法，则这也可以被用来代替。
根据上述评价，源DR在网络中现在必须针对内容流C1触发多播。
针对源DR的第一步是触发针对该URI的组地址的生成。我们假设存在实现MADCAP并且动态地给针对该URI的组分配239.192.10.1的地址的地址分配服务器(连同针对单播的DHCP一起部署的)。该地址与源DR协商如RFC 2730中所述的。
假设在该网络系统中存在N个RP元素，其单播地址已经被BSR传送给源DR。源DR现在执行哈希函数以确定登记消息必须被发送至的RP。登记消息(在多播被触发的时钟时间开始封装针对该URI的来自源的数据分组)被逐跳单播至RP。假设在成员已经登记到该组之前此过程发生，RP创建针对该源的多播路由条目并且发送回登记-停止。
源必须也触发针对多播流要被生成的新的SDP文件，并且创建新的URI以便进入该流，以便未来的主机请求该URI。假设新的URI生成为rtsp://example.com/application/contentStream？mcplaycmd。在媒体服务器中创建多播SDP。
使用将URI映射到主机、由源或者它的DR保持的上述表，我们发现H1当前消耗内容C0。我们使用RTSP发出宣告、设置参数(Set_Parameter)或周期的获得参数(Get_Parameter)响应组合以将新的多播URI传递到H1。注意，设置新的URI的机制是仅主机源管理的一部分，而不是针对网络本身的功能。此工作覆盖响应于触发条件而不是仅仅切换到媒体服务器上的新的URI的并假设网络已经能够多播而在网络中触发的动作。
H1中的IP模块假设被扩展以包括多播兼容性和IGMP支持。新的RTSP控制消息触发上层协议以向IGMP发出加入主机组(JoinHostGroup)(239.192.10.1，接口)，该IGMP然后向其主机DR(IP地址：10.1.4.1)发送成员报告(MembershipReport)。假设在主机DR中触发了(*,G)状态变化，但是如果特定的源地址是重要的并且SPT将被建立，它也能触发(S，G)变化。这在主机DR中触发了加入期望(JoinDesired)(*,239.192.10.1)，该主机DR然后使用哈希函数将其映射到相关的RP。加入/删除消息被发送至该RP，并且在其路径中的每个跳中创建(*,G)状态。这基于PIM-SM利用的单播协议在多播路由信息库(MRIB)、树信息库(TIB)和多播转发信息库(MFIB)中创建相关的路由条目。
当RP从针对组239.192.10.1的主机DR 10.1.4.1接收该PIM加入/删除消息时，它向源发送(192.168.10.10,239.192.10.1)加入消息，创建通过其数据流向RP的本地SPT。这随后多播到主机DR，并且最终发送至H1。
在该状态下，H1接收数据的两个副本-一个通过单播RTSP会话并且另一个通过多播会话。主机使用数据分组匹配以识别该复制何时出现。它也确定两个流之间的时间延迟，并且确认它是否具有足够地缓冲两个流直到交叠出现的能力。如果由于过多的延迟这是不可能的，则该主机H1可能不能有益于多播会话并且可能必须离开该组。然而，在我们的示例中，我们假设主机可以按需求缓冲并且开始无缝地向用户播放多播流。
一旦这是成功的，单播RTSP会话就必须被终止。这通过直接向源发送拆卸消息来完成(包括在RFC 2326中)。在后期单播对话应当再次被请求，知道源单播URI和它的IP地址，新的会话可以被建立。
新的主机H3(IP地址：10.1.4.12)现在向源发送单播RTSP消息，请求相同URI的内容。然而，多播流针对该内容C0当前是就位的，该内容C0可以在请求的原始的浏览器网页中被提交给H3(通过变更HTML以用多播URI代替单播URI)或者作为用多播URI对带有重定向消息的初始RTSP建立消息进行的响应。主机H3将解决该URI并且以与H1相同的方式向其主机DR发送IGMP加入。源DR向它的表添加H3的IP地址并且更新它的URI成员列表，并且添加该信息以更新它的决定机制以触发到多播的切换。
在前面的讨论中，对内容传送网络的引用不应该以严格的方式被解释。根据本发明的方法可以在任何能够支持的单播和多播的通信网络内被实现。此外，根据本发明的方法的使用不限于音频或者视频内容数据，并且可以被用于传送其它类型的数据。
由于本发明可以被实现于路由器、服务器、或其它设备内的软件上，所以使传统的装置升级为可以执行根据本发明的方法的装置是可能的。计算机代码可以经由下载(例如，经由网络，或在一些物理介质(例如，DVD、CD-ROM、USB记忆棒等)上)被部署到装置。
本发明提供了一种在内容递送网络中从源分发内容的方法，所述方法包括：监视对内容项的传送的请求；获得关于所述内容的未来需求的预测；应用单播至多播切换决定算法，切换决定算法考虑未来需求的预测并且被设置为确定至少一个条件是否被满足；并且，根据单播至多播切换决定算法的结果，开始关于内容项的多个单播数据流到多播数据流的转换。

Claims (14)

1.一种在内容递送网络中从源分发内容的方法，所述方法包括：
监视对内容项的传送的请求；
获得针对所述内容的未来需求的预测；
应用单播至多播切换决定算法，所述切换决定算法考虑所述未来需求的预测并且被设置为确定至少一个触发条件是否被满足；并且
根据所述单播至多播切换决定算法的结果，开始针对所述内容项的多个单播数据流到一多播数据流的转换，其中，针对所述内容的未来需求的所述预测是基于与针对所述内容的实际需求无关的数据；并且
所述方法还包括保持选自包括以下项的组的一个或多个背景动作：
周期性地选择引导路由器而不考虑在所述网络中正进行多播；
候选引导路由器将他们的候选资格告知给所选择的引导路由器；
协议独立多播路由器向彼此发送“hello”消息，而不考虑在所述网络中正进行多播；
其中，所述方法在服务器上或通过所述服务器来执行，所述服务器是第一服务器，并且在接收到针对内容项的请求时，所述方法还包括在任何其它服务器具有针对所述内容的任何激活的会话的情况下建立所述第一服务器，并且合并针对所述其它服务器进行的多个会话请求，使得通过所述第一服务器来处理所述多个会话请求。
2.根据权利要求1所述的方法，其中，与针对所述内容的实际需求无关的所述数据包括从社会数据源获得的数据和/或从搜索引擎获得的数据。
3.根据权利要求1所述的方法，所述方法还包括：保持针对所述内容项的针对指向所述源的所述请求的统计记录，并且使用所述记录中的至少某些所述数据来获得所述未来需求的预测。
4.根据权利要求3所述的方法，其中，所述切换决定算法考虑所述记录中的数据。
5.根据权利要求4所述的方法，其中，所述切换决定算法考虑所述记录中的一个或多个参数，所述参数选自包括以下项的组：
激活的会话的当前数量；
在给定的时间段期间对所述内容的请求的总数；
平均会话持续时间；
会话过早地结束的概率；
所述内容的数据大小。
6.根据权利要求1所述的方法，其中，所述多个单播数据流到所述多播数据流的转换包括：
生成组地址系统；
创建针对将被切换到多播的所述内容的会话描述信息；并且
将主机加入所述多播数据流。
7.根据权利要求6所述的方法，其中，生成组地址系统包括为主机组和源的每个地理位置组合分配组地址，使得所述组地址的哈希函数生成最接近于所述源和组成员两者的会合点。
8.根据权利要求6所述的方法，其中，生成组地址系统包括使用现有的组地址集合，或其中生成组地址系统包括使用动态的地址池。
9.根据权利要求6所述的方法，其中，关于将主机加入所述多播数据流的步骤，所述主机已经请求了单播数据流并且还没有开始接收所述流。
10.根据权利要求6所述的方法，其中，关于将主机加入所述多播数据流的步骤，所述主机已经开始接收单播流。
11.根据权利要求6所述的方法，所述方法还包括响应于来自所述主机的请求使得多播内容在给定的时间开始。
12.根据权利要求6所述的方法，所述方法还包括响应于所述主机检测到正经由单播和经由多播接收到基本上相同的内容来终止单播会话。
13.一种被配置成执行如前述权利要求中的任一项所述的方法的网络设备。
14.一种包括计算机可实现指令的计算机可读存储介质，所述计算机可实现指令在被可编程计算设备执行时，实现根据权利要求1至12中任一项所述的方法，其中，所述可编程计算设备被配置为根据权利要求13所述的网络设备。
CN201480018773.0A 2013-03-28 2014-03-27 分发内容的方法、网络设备和计算机可读存储介质 Active CN105075218B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP13250041.4 2013-03-28
EP13250041.4A EP2785006A1 (en) 2013-03-28 2013-03-28 Content delivery system and method
PCT/GB2014/000119 WO2014155041A1 (en) 2013-03-28 2014-03-27 Content delivery system and method

Publications (2)

Publication Number Publication Date
CN105075218A CN105075218A (zh) 2015-11-18
CN105075218B true CN105075218B (zh) 2019-10-01

Family

ID=48092864

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201480018773.0A Active CN105075218B (zh) 2013-03-28 2014-03-27 分发内容的方法、网络设备和计算机可读存储介质

Country Status (4)

Country Link
US (1) US10270821B2 (zh)
EP (2) EP2785006A1 (zh)
CN (1) CN105075218B (zh)
WO (1) WO2014155041A1 (zh)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015101402A1 (en) * 2013-12-31 2015-07-09 Telecom Italia S.P.A. Congestion management in a multicast communication network
CN106233735B (zh) * 2014-03-31 2020-10-02 英国电讯有限公司 管理多播视频传送的方法
EP2940958A1 (en) * 2014-04-29 2015-11-04 Alcatel Lucent Methods and devices for responding to a streaming request, access node and method for operating the same
US10051067B2 (en) * 2014-10-01 2018-08-14 Avaya Inc. Abstract activity counter
EP3051769B1 (en) * 2015-01-27 2018-03-14 Alcatel Lucent Dynamic switching to broadcast transmission of multimedia content over a mobile communication network
CN106302310A (zh) * 2015-05-12 2017-01-04 中兴通讯股份有限公司 一种发布应用方法、装置、服务器、终端及系统
WO2017125150A1 (en) 2016-01-20 2017-07-27 Telefonaktiebolaget Lm Ericsson (Publ) Switching between unicast and multicast in a content delivery network
CN107820218B (zh) * 2016-09-14 2020-06-26 华为技术有限公司 报文传输方式的设定方法及设备
WO2018122009A1 (en) * 2017-01-02 2018-07-05 Philips Lighting Holding B.V. A lighting system for controlling an led array
US20180242230A1 (en) * 2017-02-19 2018-08-23 Alcatel-Lucent Usa Inc. Switching between unicast service and multicast-broadcast service
US10248891B2 (en) 2017-06-20 2019-04-02 At&T Intellectual Property I, L.P. Image prediction
US10348647B2 (en) 2017-12-13 2019-07-09 Cisco Technology, Inc. Graceful designated router handoff
US10904590B2 (en) * 2018-05-23 2021-01-26 Otter Network, LLC Method and system for real time switching of multimedia content
US11424961B2 (en) * 2018-09-14 2022-08-23 Hewlett Packard Enterprise Development Lp Exporting the device sharing attribute for host devices from a wireless controller to a switch
CN111327534B (zh) * 2018-12-13 2022-06-14 浙江宇视科技有限公司 一种跨域单播转组播传输方法及装置
US11683666B2 (en) 2019-06-18 2023-06-20 Nokia Technologies Oy Data transmission
US11638057B2 (en) 2019-08-30 2023-04-25 British Telecommunications Public Limited Company Content delivery
US11601295B2 (en) * 2019-09-23 2023-03-07 Juniper Networks, Inc. Content delivery with reliable multicast using a redundant unicast overlay network
US11871238B2 (en) * 2020-03-16 2024-01-09 Dell Products L.P. Aiding multicast network performance by improving bootstrap messaging
GB2602270B (en) * 2020-12-18 2023-03-29 British Telecomm Content delivery
US20220368747A1 (en) * 2021-05-11 2022-11-17 Siden, Inc. Method And System For Delivering Real-Time Content Using Broadcasting And Unicasting
CN117478920A (zh) * 2022-07-20 2024-01-30 中兴通讯股份有限公司 直播数据传输方法及其系统、电子设备、存储介质
CN117785541A (zh) * 2024-02-27 2024-03-29 荣耀终端有限公司 一种数据处理方法及电子设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101326790A (zh) * 2005-12-13 2008-12-17 艾利森电话股份有限公司 用于经由不同承载类型分发内容的技术

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7937485B2 (en) * 2004-08-31 2011-05-03 At&T Intellectual Property I, L.P. Streaming gateway
US7886056B2 (en) * 2005-06-29 2011-02-08 International Business Machines Corporation Method and apparatus for workload management of a content on demand service
US9060208B2 (en) * 2008-01-30 2015-06-16 Time Warner Cable Enterprises Llc Methods and apparatus for predictive delivery of content over a network
EP2478454A4 (en) * 2009-09-15 2015-07-29 Comcast Cable Comm Llc CONTROL PLANE ARCHITECTURE FOR MULTICAST BUFFER MEMORY FILLING
US20110228772A1 (en) * 2010-03-19 2011-09-22 Brocade Communications Systems, Inc. Providing multicast services without interruption upon a switchover

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101326790A (zh) * 2005-12-13 2008-12-17 艾利森电话股份有限公司 用于经由不同承载类型分发内容的技术

Also Published As

Publication number Publication date
EP2979422A1 (en) 2016-02-03
EP2785006A1 (en) 2014-10-01
EP2979422B1 (en) 2019-06-12
WO2014155041A1 (en) 2014-10-02
US20160080446A1 (en) 2016-03-17
US10270821B2 (en) 2019-04-23
CN105075218A (zh) 2015-11-18

Similar Documents

Publication Publication Date Title
CN105075218B (zh) 分发内容的方法、网络设备和计算机可读存储介质
Wang et al. AMES-cloud: A framework of adaptive mobile video streaming and efficient social video sharing in the clouds
CN105103518B (zh) 将内容从源传递到目的地的方法和装置、计算机可读介质
US7975282B2 (en) Distributed cache algorithms and system for time-shifted, and live, peer-to-peer video streaming
US10484440B2 (en) Content distribution system and method
CN106464680A (zh) 内容分发网络中的带宽管理
Wichtlhuber et al. TRANSIT: Supporting transitions in Peer-to-Peer live video streaming
US9674245B2 (en) Content distribution system and method
AlSaeed et al. Multicasting in software defined networks: A comprehensive survey
CN102651824B (zh) 用于传输多媒体信息的方法和用于处理多媒体信息的设备
US10284920B2 (en) Content distribution system and method based on information relating to destination capability and network conditions
EP3014892B1 (en) Content distribution system and method
US20120084815A1 (en) Method for providing multicast services
Neugebauer et al. Overview and Trends of Video Streaming over IP

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