CN113475085B - 多播辅助传送 - Google Patents

多播辅助传送 Download PDF

Info

Publication number
CN113475085B
CN113475085B CN202080016920.6A CN202080016920A CN113475085B CN 113475085 B CN113475085 B CN 113475085B CN 202080016920 A CN202080016920 A CN 202080016920A CN 113475085 B CN113475085 B CN 113475085B
Authority
CN
China
Prior art keywords
content
agent
unicast
request
response
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
CN202080016920.6A
Other languages
English (en)
Other versions
CN113475085A (zh
Inventor
R·特恩布尔
S·阿普尔比
T·史蒂文斯
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 CN113475085A publication Critical patent/CN113475085A/zh
Application granted granted Critical
Publication of CN113475085B publication Critical patent/CN113475085B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/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/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26616—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for merging a unicast channel into a multicast channel, e.g. in a VOD application, when a client served by unicast channel catches up a multicast channel to save bandwidth
    • 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
    • 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/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2183—Cache memory
    • 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/21—Server components or server architectures
    • H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
    • 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
    • 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/643—Communication protocols
    • H04N21/64322—IP
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Abstract

描述了一种使用本文称为“多播辅助单播传送”(MAUD)的方法通过网络传送内容的方法，因为多播网络被用于辅助而不是替代其它单播路径。客户端设备通过单播向内容服务器请求内容。这些单播请求在被第二代理发送到内容服务器之前，全部通过单播经由第一代理和第二代理发送。将包含所请求内容的响应从内容服务器通过单播发送回第二代理。第二代理处理接收到的单播响应并通过多播流将响应发送到第一代理。第一代理处理接收到的响应并通过单播将它们发送到发出请求的客户端设备。

Description

多播辅助传送
技术领域
本发明涉及使用单播和多播组合的内容传送领域。
背景技术
越来越多的实况内容正在使用HTTP(或HTTPS)进行流传输。流行的实况事件推动了极其不稳定的需求，导致业务量的峰均比非常高。例如，图1中的图表100示出了2016年欧洲杯足球比赛期间获取的接近移动网络边缘的网关处的业务量示例。曲线图102示出了没有足球的一天(6月15日星期三)的业务量，并且曲线图104示出了有足球比赛(英格兰对威尔士)的第二天(6月16日星期四)的业务量。两个曲线图都示出了一天中大致相同的业务量，除了曲线图104在大约1400小时至1600小时之间有一个显著的额外业务峰值(这是由于客户流传输足球比赛造成的)之外。
这种高峰均比在网络边缘处提出了一个特殊挑战，在该网络边缘处，这种峰值会导致用户体验质量的下降。
最常见的是，内容是使用HTTP(或HTTPS)请求/响应对通过因特网传送的。客户端应用将向服务器发送HTTP请求，并且包含所请求内容的响应被返回。这种请求/响应本质上是单播的。
HTTP可以用于视频流传输。通常，客户端将获得清单文件，该文件将允许确定包含视频片段的各个文件的URL。然后，客户端将会依次请求这些片段，并将它们连接起来形成连续的流以供回放。每个视频片段也可以以不同的比特率提供，以允许视频速率适应网络吞吐量。这种技术称为HTTP自适应流传输(HAS)。
对于观看相同事件(诸如实况足球比赛)的用户，每个客户端将会进行自己的HTTP请求并得到自己的HTTP响应，即使在HTTP响应内传送给这些客户端的大部分内容在它们之间是相同的。这导致网络的使用效率非常低。
但是，如果接入网络能够使用多播而不是单播来进行内容传送，则图1中示出的实况内容峰值的影响可以显著减少。此外，在接入网络中使用多播还可以显著减少对内容传送网络服务器的峰值需求。
解决此类问题的解决方案已经存在，其中使用代理将多播路径插入到客户端与内容服务器之间的其它单播路径中。此类混合解决方案的示例包括：“IP MulticastAdaptive Bit Rate Architecture Technical Report(IP多播自适应位速率架构技术报告)”OC-TR-IP-MULTI-ARCH-C01-161026，2016年10月26日，Cable Labs；3GPP规范，23.246(MBMS架构和功能描述)、26.346(MBMS协议和编解码器)和26.347(MBMS APIs)；以及DVB文档A176，“Adaptive Media Streaming over IP Multicast(跨IP多播的自适应媒体流传输)”，(2018年3月8日)。
图2示出了此类混合解决方案的通用示例。
在图2中，示出了向客户端设备204a、204b和204c提供内容(例如，视频)的内容服务器202。多播代理X 206和三个代理Y 208a、208b和208c被插入到内容服务器202与客户端设备之间的其它单播路径中。代理X 206从内容服务器202获取单播内容并使其经由多播可用。代理Y接收多播内容，并可以通过单播将其提供给任何发出请求的客户端设备。所有客户端设备将接收到对其片段的请求的相同响应，因为所有代理Y都从代理X接收到相同的多播内容。代理Y可以位于客户端设备内，也可以位于单独的设备中，或者根据设置可能存在单个代理Y。
在此种解决方案中，代理X被预先配置为充当客户端，并独立地请求内容片段并将整个响应分派到多播网络中。代理X通过首先请求清单文件，然后及时请求其中描述的内容片段来实现这一点。在某些情况下，内容服务器可能会在提供内容被服务之前要求客户端设备使用有效凭证对它们自己进行认证。这是通过向代理X提供能够访问来自内容服务器202的内容的有效凭证来实现的。因此，使用在代理X 206处配置的凭证而不是由各个客户端设备提供的任何凭证来实现认证。代理X 206有效地充当伪客户端。
因此，代理X作为客户端运行，从而向内容服务器请求内容并将响应通过多播推送到代理Y。客户端设备将从代理Y请求内容，这与代理X向内容服务器做出的请求无关。换言之，对从客户端设备到代理Y的内容的请求不会被传递到代理X，该代理X被配置为代表客户端设备做出对该内容的请求。这意味着存在一种可能的竞争状况，其中，客户端设备在代理X已经请求媒体片段并将这些片段推送回代理Y之前经由代理Y请求这些媒体片段，这可能导致某些内容被传送到代理Y两次(一次通过单播，并且一次通过多播)。这可以通过以下方式来解决：延迟来自代理Y的响应直到相关片段到达，或者操纵返回到客户端设备的清单以确保代理X能够在客户端设备做出请求之前请求和推送内容。两种解决方案都不是最优的。
此外，代理X仅根据清单文件中包含的信息向内容服务器请求内容。清单文件将包含有关片段持续时间的信息，并且代理X将使用它以期望速率做出请求。客户端设备将类似地运行，尽管片段请求的定时将由客户端缓冲区的充满度来确定，该缓冲区在接收到片段数据时被填充并在视频被解码和呈现时被清空。但是，清单文件中发布的片段持续时间可能与实际持续时间不完全匹配。这将导致代理X的片段请求间隔与客户端设备的片段请求间隔不匹配。这可能会导致客户端缓冲区的缓冲区下溢，从而导致视频播放回放停滞。
内容服务器通常是CDN边缘缓存，并且在正常运行时，CDN提供商可以看到做出的请求的数量和它正在服务的响应的数量。此信息用于服务监测、计量和解析，并且通常对CDN运营商的业务至关重要(例如，用于服务保障和计费等)。使用上述混合架构，无论消费内容的客户端设备数量如何，都仅存在代理X做出的单个请求和对应的单个响应。这显然会影响已建立的CDN操作(诸如此处描述的那些操作)。
发明内容
本发明的示例的目的是提供一种改进的内容传送方法。
根据本发明的一个示例，提供了一种在包括多个客户端设备的网络中向客户端设备传送内容的方法，所述方法包括：
i)在第一网络节点处，通过单播从所述客户端设备中的一者接收对内容的请求，并且通过单播向第二网络节点发送该请求；
ii)在第二网络节点处，从所述第一网络节点接收所述对内容的请求，并且然后通过单播向内容服务器发送对应的请求；
iii)在所述第二网络节点处，通过单播从所述内容服务器接收请求的内容，并且作为响应通过多播向所述第一网络节点发送接收到的内容；
iv)在所述第一网络节点处，从所述第二网络节点接收所述内容，并且通过单播向发出请求的客户端设备发送所述内容。
来自所述客户端设备中的一者的所述请求是HTTP GET请求。由第二网络节点发送的对应的请求可以是HTTP GET请求。另选地，对应的请求可以是HTTP HEAD请求。
在第二网络节点处接收的内容可以被缓存在所述第二网络节点处。此外，所缓存的内容可以被提供给请求该内容的其它客户端设备。
在第二节点处接收到的所请求的内容可以被重新格式化并通过多播推送到第一网络节点。
内容可以是媒体内容，并且还可以包括视频序列。
根据本发明的又一示例，提供了一种用于在包括多个客户端设备的网络中向客户端设备传送内容的系统，所述系统包括第一网络节点和第二网络节点，其中，
所述第一网络节点适于通过单播从所述客户端设备中的一者接收对内容的请求，并且通过单播向第二网络节点发送该请求；
所述第二网络节点适于从所述第一网络节点接收所述对内容的请求，并且然后通过单播向内容服务器发送对应的请求；
所述第二网络节点还适于在所述第二网络节点处通过单播从所述内容服务器接收所请求的内容，并且作为响应通过多播向所述第一网络节点发送接收到的内容；并且
所述第一网络节点还适于从所述第二网络节点接收所述内容，并且通过单播向发出请求的客户端设备发送所述内容。
在本发明的示例中，几乎不需要对客户端设备或内容服务器进行修改，它们可以以常用方式分别请求内容和对请求的响应。
在先前的混合系统中，第二代理服务器(代理X)需要被配置有内容服务的详细信息，以便它可以获取清单文件，并通过处理清单文件并做出适当片段请求以类似于客户端的方式运行。相比之下，在本发明的示例中，第二代理服务器不需要访问清单文件，而是由请求该片段的领先客户端设备同步驱动。这解决了客户端设备和代理X异步运行所产生的两个早期问题，这会导致延迟增加和缓冲区下溢。
为了让CDN运营商能够看到所有片段请求，第二代理服务器可以将除了第一个片段请求(其将是GET请求)之外的所有片段请求作为HEAD请求来传递。这将使CDN运营商能够获得他们需要的统计数据，而无需提供完整的响应。
由于本发明的示例在不知道清单文件的情况下运行，它们将在清单文件被混淆(例如YouTube)、专有、加密或以某种其它方式隐藏的情况下工作。这些示例在媒体片段级别运行，从而减小了第二代理服务器(代理X)的复杂性，因此使部署更加直接。
附图说明
为了更好地理解本发明，现在将仅以示例的方式参考附图，其中：
图1是示出不同日期的网络上的业务量的图表；
图2是一般现有解决方案的网络视图；
图3是示出本发明的示例的主要组成部分的网络视图；
图4是本发明的示例中的初始处理的消息流视图；
图5是本发明的示例中的处理的另一部分的消息流视图；
图6是示出在本发明的示例中如何针对多播使用建立代理中的一者的消息流视图；
图7是示出在本发明的示例中的一旦在两个代理之间已经建立多播就向客户端设备做出内容请求的消息流视图；
图8示出了在本发明的示例中的如何在响应中修改报头的示例；
图9是在本发明的示例中的针对代理中的一者的处理的流程图；
图10是在本发明的示例中的针对代理中的一者的处理的流程图；以及
图11示出了在本发明的示例中的来自内容服务器的响应、以及所得到的携带修改后的报头的分组和携带有效载荷的QUIC分组流的格式。
具体实施方式
本发明在此参照特定示例进行描述。然而，本发明不限于这些示例。
本发明的示例提供了一种使用此处被称为“多播辅助单播传送”(MAUD)的方法通过网络传送内容的方法，因为多播网络用于辅助而不是替代其它单播路径。客户端设备通过单播从内容服务器请求内容。这些单播请求在被第二代理发送到内容服务器之前，全部通过单播经由第一代理和第二代理来发送。包含所请求内容的响应从内容服务器通过单播发送回第二代理。第二代理处理接收到的单播响应并通过多播流将响应发送到第一代理。第一代理处理接收到的响应并通过单播将它们发送到发出请求的客户端设备。第一代理还缓存响应，并且可以将它们发送到随后请求该内容的其它客户端设备，而不必将这些请求转发到内容服务器。
一旦已经标识出一定数量的客户端设备可能请求相同的内容，就在第二代理与第一代理之间建立多播流。因此，在通过单播被发送到多个客户端设备之前，单个多播流可以被用于在第二代理与第一代理之间携带内容。
图3示出了“多播辅助单播传送”(MAUD)网络的主要组成部分。网络300包括内容服务器302；代理X 306；代理Y 308a、308b和308c；客户端设备304a、304b和304c；以及多播控制器312。内容服务器302向请求实体(诸如，客户端设备)提供内容(例如，视频)。内容服务器302可以位于内容传送网络(CDN)内，并且可以存在多于一个内容服务器。代理X 306可以通过单播与内容服务器302通信。代理X 306还可以通过单播和多播两者与代理Y 308a、308b和308c通信。代理Y可以位于客户端设备内、单独的设备(诸如，家庭网关)中，或者根据设置可能存在单个代理Y。
注意，在图3中，使用实线标记双向单播通信路径，使用虚线标记单向多播通信路径，并且使用点划线标记控制接口通信路径。控制接口通信路径在多播控制器312与网络中的其它元件之间携带控制消息收发/命令。
假设客户端设备正在运行相应的客户端应用，这些客户端设备是内容请求源。为简单起见，下文中的术语客户端设备用于指代运行客户端应用的客户端设备。客户端设备可以对内容服务器302处保存的内容做出HTTP单播请求。在本发明的示例中设置了用于传送该内容的机制，其中描述了多播辅助单播递送(MAUD)方法。
多播控制器312(MCC)监测代理X和代理Y的运行以确定哪些业务应该使用多播辅助(MAUD)，并相应地控制代理。因此，在本发明的示例中，客户端设备可以通过单播从内容服务器302直接接收一些业务，并使用MAUD从内容服务器302接收其它业务。
客户端设备做出的对内容的许多HTTP请求将不会利用MAUD，而是被直接发送到内容服务器。
可能受益于MAUD的、来自客户端设备的对内容的其它请求被重定向到代理Y中的一者，或者由代理Y中的一者简单地拦截。
可以使用多种众所周知的技术中的任何一种将代理Y插入到HTTP路径中，例如，使用来自内容服务器302的HTTP重定向。在这种情况下，内容服务器302将被配置为使得不会对潜在流行内容的请求直接提供服务，而是将其重定向到合适的代理Y。例如，内容服务器302可以用指示临时重定向的HTTP状态代码307来响应，而不是提供正常响应。这邀请客户端设备对内容服务器在其响应中提供的新URL做出新请求，从而能够向代理Y发出请求。这种技术允许内容服务器和代理Y存在于不同的域中，通常情况下就是这样。
在HTTP路径中插入代理Y的其它机制包括：将代理Y配置为透明代理(尽管所有请求都被该代理拦截，并且仅适用于未加密的业务)；将代理Y配置为转发代理(其中客户端设备通过明确配置将其请求直接发送给代理Y)；DNS劫持(其中DNS服务器被配置为针对关注域供应代理Y的IP地址)；以及清单操纵(其中清单文件被重写，以便直接向代理Y做出请求)。
现在参考图4，其示出了针对初始MAUD处理的客户端设备304a、代理Y 308a、代理X306、多播控制器312和内容服务器302之间的消息流视图。
在步骤400中，客户端设备304a做出对内容的HTTP GET请求。该请求被代理Y 308a接收。然后，在步骤402中，代理Y 308a通过控制接口路径(参见图3的点划线)向多播控制器312发送消耗报告。消耗报告包括有关通过代理传递的HTTP请求/响应对的信息，例如，HTTP请求的URL。
在步骤404中，代理Y 308a还将HTTP GET请求转发到内容服务器302。内容服务器302以包含所请求内容的HTTP响应进行响应。该响应由代理Y 308a接收并被发送到客户端设备304a。然后，该内容可以被客户端设备304a查看。
注意，到目前为止，所有HTTP请求和响应本质上都是单播的。
现在，应进一步注意，对相同内容的请求可能由其它客户端设备发出。这在例如实况足球比赛期间是典型的。在这种情况下，图4的处理将由数个客户端设备和相关联的代理Y重复，各个代理Y向多播控制器312发送该代理Y的相应客户端设备的消耗报告。
多播控制器312使用接收到的报告来决定从给定的代理Y群体报告的HTTP请求是否证明了针对其响应使用多播。这样的代理Y群体被称为“群组(cohort)”。假设满足特定条件(例如，大于请求相同内容的客户端设备的特定数量)，多播控制器312将配置代理X和任何相关代理Y(即，群组)用于进行多播辅助传送。
图5示出了将单个代理Y 308a添加到群组以进行多播辅助传送的处理的消息流视图，该处理最初发生在步骤500中。注意在实践中，将有许多客户端设备做出请求，并且因此存在将可能遵循相同逻辑并被添加到同一群组的许多相关联的代理Y。
在步骤500中，多播控制器312将代理Y 308a添加到群组。在步骤502中，多播控制器312通过向代理Y 308a发送设定HTTP请求路由的指令来实现这一点，由此，与特定URL路径/模式/字符串匹配的请求被定向到代理X 306。
例如，多播控制器312可能向代理Y 308a发送“t2-btsport-live-hls-prod.akamaized.net”作为匹配模式。然后，与该模式匹配的、始于客户端设备的对URL的任何请求都将被重定向到代理X 306。该URL不必完全匹配，而只需包含匹配模式。例如，客户端设备可以请求URL，诸如针对清单的https://t2-btsport-live-hls-prod.akamaized.net/out/u/bts1/bts1_7.m3u8或针对视频片段的https://t2-btsport-live-hls-prod.akamaized.net/out/u/bts1/bts1_7_15055280.ts？m＝1543850508m＝1543850508。代理Y 308a会将这些请求转发到代理X 306，因为它们具有至少部分与多播控制器312在步骤502中指定的模式匹配的URL。
然后，在步骤504中，多播控制器312还向代理Y 308a发送提供多播监听器的指令。该指令告知代理Y 308a准备接收多播，因为代理X可能会选择通过多播发送一些响应(例如，对代理Y已发送到代理X的请求的响应，来自匹配的“t2-btsport-live-hls-prod.akamaized.net”模式)。多播监听器使代理Y向多播控制器指定的多播地址发出IGMP加入命令。多播可能会也可能不会到达此接口，这取决于代理X选择发送的内容(参见稍后有关代理X设定的讨论)。
注意，步骤502和步骤504可以作为单个步骤来实现：多播控制器发送到代理Y的监测匹配模式的指令也可以告知代理Y提供多播监听器。
然后，在步骤506中，当客户端设备304a接下来发送对内容的HTTP GET请求时，该请求被代理Y 308a接收，并且代理Y 308a检查它是否与步骤502中设置的匹配模式匹配。在这种情况下，它是匹配的。可选地，代理Y 308a可以在步骤508中向多播控制器312发送消耗报告(如在步骤402中)，并且在步骤510中将HTTP GET请求重定向到代理X 306上(而不是直接到内容服务器302)。
在步骤512中，代理X 306将接收到的HTTP GET请求发送到内容服务器302。在步骤514中，内容服务器302通过在HTTP响应中将所请求的内容发送到代理X 306来进行响应。在步骤516中，代理X 306将该响应转发到代理Y 308a。然后，在步骤518中，该响应由代理Y308a转发到客户端设备304a。
截止目前，所描述的处理示出了如何设定代理Y 308a以将某些HTTP请求转发到代理X(步骤502)，并且还将其自身提供为准备好接收多播业务的多播监听器(步骤504)。但是，此时还没有多播业务，因为代理X 306尚未被配置为发送任何多播业务。到目前为止，所有HTTP请求和响应本质上都是单播的。
现在参考图6。在步骤600中，为了允许代理X 306使用多播作为对满足步骤502中设置的匹配模式的请求的响应的返回路径，多播控制器312发送指示代理X对内容服务器发送的某些响应使用多播的指令。在步骤602中，多播控制器配置代理X，以通过选择文件或MIME类型来标识那些响应。例如，指令可以是仅对包含视频MIME类型(例如，“video/mp4”或“video/MP2T”)的响应使用多播辅助。其它文件类型将仅通过单播发送。所以在此示例中，即使对应的请求满足来自步骤502的URL匹配模式，文本、清单、图像(所有非视频MIME类型)也将通过单播发送。
在另选示例中，可以基于特定的Etag或一系列Etag来选择响应。Etag(实体标签)是HTTP 1.1规范的一部分并用于唯一地标识响应有效载荷。
在此之后，代理X和代理Y能够使用多播辅助单播传送来传送HTTP响应，所得到的可能通信路径如图3所示——注意代理X与代理Y之间的单播路径和多播路径的组合，但是客户端设备与代理Y之间以及代理X与内容服务器之间只有单播路径。
在图5和图6的步骤已经完成之后，系统准备好向做出满足预定匹配模式的内容请求的客户端设备提供多播辅助(参见上面的步骤502)。
下面是多播辅助的两个示例。
第一种方法是通用方法，其中内容请求通过单播从客户端设备传递到内容服务器，并且向客户端设备传递回响应，但是响应在返回路径的一部分上是通过多播携带的。第二种方法是将响应进一步拆分为两个组成部分，一个通过多播传送，而另一个通过单播传送。
第一种通用方法如图7所示。
图7示出了客户端设备请求满足预定匹配模式的内容的消息流视图(参见上面的步骤502)，并因此在多播辅助下进行处理。图7遵循图4、图5和图6，其中均建立了群组，并将代理X和代理Y配置为分别发送和监听多播业务。
在图7中，示出了首次从内容服务器请求一段内容的“第一客户端”的消息流，稍后是在一段时间后请求相同内容的另一个客户端的消息流，以及进一步地示出了客户端稍后(相较于第一客户端)请求相同内容但应用了计费/监测技术的消息流。
在步骤700中，从第一客户端开始，客户端304a通过单播向代理Y 308a发送对内容的HTTP GET请求。该请求由代理Y 308a接收，并且代理Y 308a检查它是否与步骤502中设置的匹配模式匹配。在这种情况下，它是匹配的。可选地，代理Y 308a可以向多播控制器312发送消耗报告(未示出)。在步骤702中，代理Y 308a通过单播将HTTP GET请求发送到代理X306。在步骤704中，代理X 306通过单播将接收到的HTTP GET请求发送到内容服务器302。
在步骤706中，内容服务器302通过单播在HTTP响应中将所请求的内容发送到代理X 306来进行响应。
在步骤708中，代理X 306通过多播将响应转发到代理Y 308a(假设响应满足如图6中设置的多播辅助的内容类型准则)。可以使用合适的装帧类型(诸如QUIC、FLUTE、ROUTE等)重新格式化响应并将其通过多播从代理X 306推送到代理Y。在此示例中，使用QUIC分组，这些分组通过多播UDP携带并被发送到代理Y。
QUIC分组由代理Y 308a接收，其中这些QUIC分组由代理Y 308a处理，以在通过单播被发送到客户端设备304a之前提取原始HTTP响应。注意，HTTP响应也由代理Y 308a缓存，以服务于作为已建立群组的一部分请求它的其它客户端设备。
因此，当随后的客户端设备(请求与步骤700中请求的内容相同的内容并且也由代理Y 308a提供服务的客户端设备)请求相同的内容时，代理Y 308a可以使用缓存的响应来响应该请求，而无需将该请求发送到内容服务器。这在步骤720中示出，步骤720示出了去往代理Y 308a的HTTP GET请求以及从代理Y回来的HTTP响应，而没有任何请求被转发到代理X306或内容服务器302。
步骤730至步骤738示出了一个示例，其中使用HTTP HEAD请求将随后客户端针对内容做出的请求传送到内容服务器，这允许内容服务器跟踪内容请求而无需以实际内容进行响应。因此，步骤730示出了发送到代理Y 308a的针对(之前缓存的)内容的HTTP GET请求，其中代理Y 308a使用HTTP响应进行响应，该HTTP响应具有来自该代理Y 308a的缓存的所请求内容。然而，在步骤734中，代理Y 308a另外将接收到的HTTP GET请求发送到代理X。在步骤736中，响应于HTTP GET请求，代理X 306向内容服务器302发送HTTP HEAD请求。在步骤738中，HTTP HEAD请求导致内容服务器302返回响应的报头，但不返回有效载荷(因此原始HTTP GET请求中所请求的内容不包括在响应中)。
注意，代理X可以在步骤708中通过多播将响应发送到作为同一个已建立群组的成员的其它代理Y(例如308b和308c)。这些其它代理Y可以缓存此内容，并将其提供给从这些代理Y请求该内容的任何客户端设备。
在上述方法中，不可能发送针对不同客户端设备不同的响应，因为多播路径用于向所有客户端设备传送相同的内容。
在本文描述的多播辅助单播传送的第二种方法中，通过将对HTTP GET请求的(单播)响应分成两个组成部分来克服这个问题：一个组成部分包含对于群组的不同成员可能不同的所有元素(通常是来自响应的报头)；第二个组成部分包含对于群组的所有成员相同的元素(通常是包含所请求内容的有效载荷)。相同组成部分通过多播传送，而个体组成部分使用上述布置通过单播传送。
因此，来自客户端设备的初始HTTP单播请求经由关联的代理Y和代理X被转发到内容服务器。然而，来自内容服务器的单播响应在被发送之前由代理X拆分成两个组成部分：不同组成部分通过单播被发送到与发出请求的客户端设备相关联的代理Y，而相同组成部分通过多播被发送到群组中的所有代理Y。两个组成部分的重组由相关联的代理Y处理，重组响应通过单播发送到客户端设备。
被发送到客户端设备的重组响应与代理Y将初始单播请求直接转发到内容服务器并通过单播直接从内容服务器接收到的将被提供给客户端设备的响应相同。这是当前方法的重要特征，因为客户端设备与内容服务器之间的所有会话信息都将被保留。因此，它不需要代理X凭借自身权力(提供其自身验证等)来以客户端设备的方式运行，因为代理X转发来自客户端设备的请求，其自身的凭据完好无损，其中可能包括认证凭据。在许多实际关注的情况下，所有会话特定信息都包含在HTTP报头中，而响应有效载荷可能由许多端点共享。
虽然下面的示例描述了一种方法，其中相同组成部分位于初始响应的有效载荷中，报头中具有不同的元素，但本领域技术人员将理解，相同的方法可以应用于响应中不符合完美报头/有效载荷拆分的其它分解。
返回图6，在本文描述的处理之后，代理X 306和代理Y 308a(以及群组中的其它代理Y)能够使用多播辅助单播传送来传送HTTP响应。群组中接下来做出对内容的给定请求的第一个成员将触发多播辅助的使用，以通过多播从代理X 306向作为相关群组成员的所有代理Y传送响应的有效载荷，并通过单播从代理X 306向与发出请求的客户端设备304a相关联的代理Y 308a传送响应的报头。当代理Y接收到有效载荷时，它会将其存储在内部缓存中以备处理。
应注意，上述顺序可能会有变化。例如，控制器可以在它指示任何代理Y加入群组之前指示代理X使用多播。逻辑结果仍将相同，但是在从单播到多播辅助传送的过渡期间不同组成部分上的负载可能不同。
现在讨论来自内容服务器302的响应可以如何被代理X 306分成两个组成部分并通过两个单独的传送路径传送到代理Y以进行重组。
在这个示例中，代理X生成客户端特定组成部分，该客户端特定组成部分包含来自内容服务器的原始响应的报头部分，但不包括来自原始响应的有效载荷，并进一步包括对报头字段的以下修改：
·‘Content-Length’属性被设定为零，以指示不存在有效载荷；
·附加属性(X-Content-Length)，用于指示原始‘Content-Length’属性的值；以及
·附加属性(X-Content-Id)，用作内容标识符，以标识相关联的有效载荷。
代理X还生成对应的公共组成部分，该对应的公共组成部分中包含来自内容服务器的原始响应的有效载荷。客户端特定组成部分中使用的同一内容标识符(X-Content-Id)在通过多播发送到代理Y之前也被包括在公共组成部分中。由于公共组成部分不包含HTTP报头，因此内容标识符需要被附加到公共组成部分，例如可以使用合适的装帧类型(诸如QUIC、FLUTE、ROUTE等)来实现。在以下示例中，使用了QUIC。
图11示出了HTTP响应1100、所得到的携带来自HTTP响应的修改后的报头的HTTP分组1200以及所得到的携带有效载荷的QUIC分组流的格式的示例。
HTTP响应1100包括报头部分1110(客户端特定组成部分)和有效载荷部分1112(公共组成部分)。
所生成的HTTP响应1200包括来自HTTP响应1000的报头1110，但是该报头1110如之前描述的那样被修改。该修改后的报头包括在此处被标记为1202的内容标识符“X-Content-Id”。该HTTP响应将由代理X通过单播发送到代理Y。
QUIC分组流包括4个QUIC分组1310、1312、1314和1316。QUIC分组中的每一者包括QUIC报头和QUIC有效载荷。有效载荷1112被携带在QUIC分组有效载荷中。然而，由于HTTP有效载荷通常比QUIC有效载荷大得多，因此HTTP有效载荷1112被拆分成分段A、B、C和D，并被携带在相应的QUIC分组1310、1312、1314和1316中。QUIC报头中的每一者还包括内容标识符“X-Content-Id”1311、1313、1315和1317。QUIC报头中的“X-Content-Id”与HTTP分组的修改后的报头中的“X-Content-ID”1102具有相同的值。最终QUIC分组报头中的FIN位被设定为表示QUIC分组序列的结束。任何其它HTTP响应都将具有携带有效载荷但具有新的内容标识符的对应QUIC分组流。
QUIC分组通过多播UDP来传送并被发送到代理Y。代理Y接收到QUIC分组并使用“X-Content-Id”属性来标识需要重新组合的QUIC有效载荷(A、B、C和D)来生成原始HTTP响应有效载荷。一旦重新生成，有效载荷就使用X-Content-ID作为关键字(key)被存储在代理Y中的缓存中，以供以后使用。
针对单播分组和多播分组使用同一内容标识符允许将客户端特定组成部分链接到对应的公共组成部分并随后与对应的公共组成部分重新组合。内容标识符可以由代理X生成并唯一地标识有效载荷。稍后将更详细地讨论内容标识符的生成。
将客户端特定组成部分通过单播从代理X发送到与发出请求的客户端设备304a相关联的相关代理Y 308a。将公共组成部分通过多播从代理X发送到相关群组中的所有代理Y(或由其订阅)。
现在，当代理Y 308a接收到对HTTP请求的单播响应时，由于X-Content-Id属性的存在，它会将其标识为需要附加处理。为了生成可以被转发到客户端设备304a的响应，代理Y 308a反转在代理X处对报头所做的修改。具体而言，代理Y将通过使用在X-Content-Length字段中保存的值将Content-Length字段恢复成其原始值，并移除两个附加属性。将X-Content-Id用作检索关键字，以从先前存储在缓存中的那些有效载荷中标识正确的有效载荷，其中存储在缓存中的每个有效载荷都由X-Content-Id属性编索引。然后将所标识的有效载荷与所恢复的报头重新组合，以生成由内容服务器302向代理X 306发送的原始响应的准确副本。
然后，可以将该响应通过单播发送到客户端设备304a。
图8示出了如何在从内容服务器302通过代理X 306和代理Y 308a发送到客户端设备304a的响应中修改报头的示例，为了清楚起见，省略了未修改的字段。响应800是从内容服务器302到代理X 306的，Content-Length字段被设定为“8590288”，并且Content-Type字段被设定为“Video/MP2T”。
此处假设代理X 306先前已被设置成(参见图6)对“Video/MP2T”类型的所有内容使用多播辅助。因此，当代理X 306通过单播接收到响应800时，它通过添加其它报头字段X-Content-Length来创建新响应802，并将长度从原始Content-Length字段复制到X-Content-Length中，并且然后将Content-Length的值设定为零。代理X还将报头字段X-Content-Id添加到响应802中，并将其值设定为用于有效载荷的内容标识符，此处是“123/321”。将新响应802通过单播发送到代理Y 308a。虽然通过多播单独发送的有效载荷未在图7中示出，但应注意，它将被分配有与响应802中使用的相同的X-Content-Id值“123/321”。
在代理Y 308a处，使用X-Content-Id作为关键字来正确地链接对应的组成部分，将响应802与有效载荷重组。一旦重组完成，对HTTP响应报头的更改将被反转。因此，由代理Y通过单播向客户端设备304a提供包括报头804和携带所请求内容的有效载荷的响应，其中报头804与原始报头800相同。
来自客户端设备的触发使用多播辅助的对给定段内容的第一个请求与来自其它客户端设备的对相同内容的后续请求被不同地对待。这是因为后续请求不应导致代理X通过多播重新发送相同的响应有效载荷，在群组的生命周期内已经传输了响应于第一个请求的有效载荷。注意，代理X可以多次发送相同段内容，但每个群组实例只能发送一次。
此外，如果已经将对给定段内容的响应有效载荷通过多播发送到群组，那么理想情况下，代理X不应从内容服务器进一步请求该内容，因为它将会被代理X丢弃。另选地，代理X可以发出HTTP HEAD请求，以便可以接收到会话特定报头信息，参见下面的步骤904。
用于确定响应有效载荷是否已经通过多播发送的方法是维护请求/响应记录的历史，每个记录包含来自每个请求和对应响应的数据子集。一个这样的历史将与每个群组相关联。
历史中的每条记录都将包括请求的URL和内容标识符，内容标识符唯一地标识了响应的有效载荷。内容标识符可以是X-Content-Id，它用于链接报头和有效载荷组成部分，如图8所示。代理X负责(例如从代理Y请求或内容服务器的响应中)生成内容标识符，并将其分配给客户端特定组成部分和公共组成部分。
方便的是，如果内容服务器提供了一个内容标识符，该内容标识符可以简单地是“实体标签”(Etag)值，该Etag值用于唯一地标识响应有效载荷。如果它们存在，它们将被包括在HTTP响应的报头中。
图9是示出代理X 306响应来自代理Y 308a的对内容的HTTP GET请求的逻辑的流程图。
在步骤900中，代理X 306从代理Y 308a接收对由URL指定的一段内容的HTTP GET请求。
在步骤902中，代理X查询与代理Y 308a关联的群组的历史。如果请求中使用的URL在历史中不存在，则处理进行到步骤808，在步骤808处，代理X将从代理Y 308a接收到的HTTP GET请求转发到内容服务器。
另一方面，如果请求中使用的URL存在于适当群组的历史中，则处理进行到步骤904，在步骤904处，代理X 306向内容服务器发送HTTP HEAD请求。HTTP HEAD请求将导致内容服务器返回响应的报头，而不是有效载荷(因此原始HTTP GET请求中所请求的内容不被包括在响应中)。
在步骤906中，代理X 306将生成与响应相关联的内容标识符(例如，使用响应的报头中的任何Etag)并将生成的内容标识符与存储的与请求的URL相对应的历史进行比较。如果存在匹配，则处理进行到步骤807，在步骤807处代理X将具有零长度有效载荷的修改后响应返回到代理Y 308a，并且将不会通过多播推送内容有效载荷，因为根据历史它已经被发送。
如果为该请求生成的内容标识符与历史记录中的内容标识符不匹配，则处理进行到步骤908，在步骤908处代理X向内容服务器发送HTTP GET请求以获得有效载荷。这与在步骤900中从代理Y 308a接收到的请求相同。所接收到的响应是单播HTTP响应，包括报头和有效载荷。
在步骤910中，代理X检查从内容服务器接收的响应是否满足文件类型准则，如步骤702中所设置的。例如，文件/MIME类型准则可以是“Video/MP2T”，并且因此如果响应确实包含“Video/MP2T”MIME类型有效载荷，然后处理进行到步骤912。否则，如果响应不包含“Video/MP2T”MIME类型有效载荷，则处理进行到步骤911。
因此，在步骤911中，整个HTTP响应(报头和有效载荷)通过单播被发送到代理Y308a，并且处理完成。
而在步骤912中，HTTP响应被拆分成客户端特定组成部分(报头)和公共组成部分(有效载荷)。如前所述，报头和有效载荷两者都被分配了合适的内容标识符。在通过单播将报头发送到代理Y 308a之前，还如前所述地修改该报头(参见上文，其中报头800被修改为报头802)。而将有效载荷通过多播推送到包括代理Y 308a的整个群组。
处理从步骤912进行到步骤914。
在步骤914中，在代理X处，添加/更新请求/响应对的历史记录。
注意，在某些情况下，内容服务器不会提供Etag值并且可能不接受HTTP HEAD请求。在这种情况下，可以改为使用所请求内容的URL，但如果使用相同的URL来引用更改的内容，这会导致问题，例如HTTP实况流传输(HLS)清单可能发生的情况。另选地，一种效率较低但更可靠的方法是让代理X始终向内容服务器发送HTTP GET请求(而不使用HTTP HEAD请求)，并从返回的有效载荷得出其自身的内容标识符(例如，哈希值)。
图10是示出代理Y 308a从客户端设备接收HTTP GET请求的处理以及它如何使用缓存的有效载荷来辅助生成响应的流程图。
在步骤1000中，代理Y 308a通过单播从客户端设备接收对一段内容的HTTP GET请求。
在步骤1002中，代理Y 308a进行检查以确定请求是否满足预定匹配模式。如上文关于步骤502所述，包含匹配模式的请求将用多播辅助进行处理，并因此在步骤1004中被转发到代理X。
然而，如果该请求不包含匹配模式，则处理在不尝试多播辅助的情况下继续并前进到步骤1003。在步骤1003中，通过单播将接收到的HTTP GET请求直接发送到内容服务器。来自内容服务器的响应也通过单播发送，并且在接收到该响应之后，代理Y 308a通过单播将该响应发送到客户端设备。
相反，在步骤1004中，HTTP GET请求由代理308a发送到代理X 306，并获得响应。然后，在步骤1006中，代理Y 308a检查响应是否包含“X-Content-Id”属性，该属性指示接收到的响应受制于多播辅助，其中在该响应中传送客户端特定组成部分并且分开地传送相同组成部分。
如果响应不包含“X-Content-Id”属性，则该响应不会受制于多播辅助(并且因此该响应没有被拆分为客户端特定组成部分和公共组成部分)，并且因此整个响应是通过单播直接发送到客户端设备。
然而，如果响应确实包含“X-Content-Id”属性(报头现在将类似于例如802)，则处理进行到步骤1008，在步骤1008中进行检查，以确定代理Y 308a是否已经接收到由响应中的等于“X-Content-Id”的内容标识符来标识的对应的公共组成部分。代理Y 308a通过检查其缓存来实现这一点，缓存是公共组成部分被存储的地方，其中内容标识符作为关键字。如果不存在具有相同“X-Content-Id”的缓存项，则处理进行到步骤1003，在步骤1003中通过单播将接收到的HTTP GET请求直接发送到内容服务器。来自内容服务器的响应也通过单播被发送，并且在接收到该响应之后，代理Y 308a通过单播将该响应发送到客户端设备。
如果存在具有相同“X-Content-Id”的缓存项，则处理进行到步骤1010，在步骤1010中，使用X-Content-Id作为关键字来链接对应的报头和有效载荷组成部分，将响应报头与有效载荷重组。(在步骤912中由代理X)对HTTP响应报头所做的更改也被反转。因此，由代理Y生成包括报头(参见804)和携带所请求内容的有效载荷的新响应，并且在步骤1012中，将该新响应通过单播发送到客户端设备304a。
这个新响应在客户端设备304a看来与由内容服务器304发送到代理X的响应相同，即使该响应所采用的路径对于相应的客户端特定组成部分和公共组成部分是在单播和多播上拆分开的。
注意，在所描述的示例中使用的术语“单播”一般旨在涵盖点对点通信服务。类似地，术语“多播”旨在涵盖点对多点服务(包括广播服务)。
一般而言，在此应注意，虽然以上描述了本发明的示例，但在不脱离所附权利要求所限定的本发明范围的情况下，可以对所描述的示例进行多种变化和修改。本领域技术人员将认识到对所述示例的修改。

Claims (11)

1.一种在包括多个客户端设备的网络中向客户端设备传送内容的方法，所述方法包括：
i)在第一网络节点处，通过单播从所述客户端设备中的一者接收对内容的请求，并且通过单播向第二网络节点发送该请求；
ii)在第二网络节点处，从所述第一网络节点接收所述对内容的请求，并且然后通过单播向内容服务器发送对应的请求；
iii)在所述第二网络节点处，通过单播从所述内容服务器接收所请求的内容，并且作为响应，通过多播向所述第一网络节点发送接收到的内容；
iv)在所述第一网络节点处，从所述第二网络节点接收所述内容，并且通过单播向发出请求的客户端设备发送所述内容。
2.根据权利要求1所述的方法，其中，来自所述客户端设备中的一者的所述请求是HTTPGET请求。
3.根据权利要求1所述的方法，其中，所述对应的请求是HTTP GET请求。
4.根据权利要求1所述的方法，其中，所述对应的请求是HTTP HEAD请求。
5.根据权利要求1至4中任一项所述的方法，其中，在所述第二网络节点处接收的所述内容被缓存。
6.根据权利要求5所述的方法，其中，将缓存的内容提供给请求该内容的其它客户端设备。
7.根据权利要求1至4中任一项所述的方法，其中，在所述第二网络节点处接收到的所述请求的内容被重新格式化并通过多播推送到所述第一网络节点。
8.根据权利要求1至4中任一项所述的方法，其中，所述内容是媒体内容。
9.根据权利要求8所述的方法，其中，所述媒体内容包括视频序列。
10.根据权利要求1至4中任一项所述的方法，其中，所述第一网络节点和所述第二网络节点是代理服务器。
11.一种在包括多个客户端设备的网络中向客户端设备传送内容的系统，所述系统包括第一网络节点和第二网络节点，其中
所述第一网络节点适于通过单播从所述客户端设备中的一者接收对内容的请求，并且通过单播向第二网络节点发送该请求；
所述第二网络节点适于从所述第一网络节点接收所述对内容的请求，并且然后通过单播向内容服务器发送对应的请求；
所述第二网络节点还适于在所述第二网络节点处通过单播从所述内容服务器接收请求的内容，并且作为响应，通过多播向所述第一网络节点发送接收到的内容；以及
所述第一网络节点还适于从所述第二网络节点接收所述内容，并且通过单播向发出请求的客户端设备发送所述内容。
CN202080016920.6A 2019-02-27 2020-02-26 多播辅助传送 Active CN113475085B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP19159748.3 2019-02-27
EP19159748 2019-02-27
PCT/EP2020/054993 WO2020173984A1 (en) 2019-02-27 2020-02-26 Multicast assisted delivery

Publications (2)

Publication Number Publication Date
CN113475085A CN113475085A (zh) 2021-10-01
CN113475085B true CN113475085B (zh) 2023-06-02

Family

ID=65635454

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202080016552.5A Active CN113475084B (zh) 2019-02-27 2020-02-24 多播辅助传送
CN202080016920.6A Active CN113475085B (zh) 2019-02-27 2020-02-26 多播辅助传送

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN202080016552.5A Active CN113475084B (zh) 2019-02-27 2020-02-24 多播辅助传送

Country Status (4)

Country Link
US (2) US11812115B2 (zh)
EP (2) EP3932082A1 (zh)
CN (2) CN113475084B (zh)
WO (2) WO2020173878A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3932082A1 (en) 2019-02-27 2022-01-05 British Telecommunications public limited company Multicast assisted delivery
GB2598295B (en) * 2020-08-19 2023-02-22 British Telecomm Content delivery
WO2024002598A1 (en) 2022-06-30 2024-01-04 British Telecommunications Public Limited Company Http redirection

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7281058B1 (en) * 2002-10-09 2007-10-09 Juniper Networks, Inc. Delivering and receiving multicast content across a unicast network
EP2597824A1 (en) * 2010-07-20 2013-05-29 Sharp Kabushiki Kaisha Proxy server, relay method, communication system, relay control program, and recording medium
EP2670109A1 (en) * 2012-06-01 2013-12-04 Alcatel Lucent Method, system and devices for multimedia delivering in content delivery networks
WO2014032036A1 (en) * 2012-08-24 2014-02-27 Akamai Technologies, Inc. Hybrid http and udp content delivery
EP2704391A1 (en) * 2012-08-27 2014-03-05 Broadpeak System and method for delivering an audio-visual content to a client device
CN106233735A (zh) * 2014-03-31 2016-12-14 英国电讯有限公司 多播流传输
US9673996B1 (en) * 2008-07-02 2017-06-06 Sprint Spectrum L.P. Redirection of a streaming media session in an anticipated failover scenario
US10129855B1 (en) * 2015-05-07 2018-11-13 Sprint Spectrum L.P. Systems and methods for efficient transmissions of multicast content to wireless devices

Family Cites Families (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6782490B2 (en) * 1999-03-17 2004-08-24 At&T Corp. Network-based service for the repair of IP multicast sessions
US6574795B1 (en) * 1999-05-28 2003-06-03 Intel Corporation Reliable communication of data by supplementing a unidirectional communications protocol
US20020124262A1 (en) * 1999-12-01 2002-09-05 Andrea Basso Network based replay portal
DE60119866T2 (de) * 2000-09-27 2007-05-10 International Business Machines Corp. Vermittlungseinrichtung und verfahren mit getrennten Ausgangspuffern
US6973667B2 (en) * 2001-03-01 2005-12-06 Minerva Networks, Inc. Method and system for providing time-shifted delivery of live media programs
US20020143951A1 (en) * 2001-03-30 2002-10-03 Eyeball.Com Network Inc. Method and system for multicast to unicast bridging
US20030149792A1 (en) 2002-02-06 2003-08-07 Leonid Goldstein System and method for transmission of data through multiple streams
JP2004246632A (ja) * 2003-02-14 2004-09-02 Hitachi Ltd データ分配サーバ、プログラム及びネットワークシステム
KR100678223B1 (ko) * 2003-03-13 2007-02-01 삼성전자주식회사 통신시스템의 패킷 전송 장치 및 방법
EP1732272B1 (en) * 2004-03-30 2014-03-19 Panasonic Corporation Communication device and communication system
EP1675399A3 (en) * 2004-12-23 2009-04-29 Bitband Technologies Ltd. Fast channel switching for digital TV
WO2006091736A2 (en) * 2005-02-23 2006-08-31 Arroyo Video Solutions, Inc. Fast channel change with conditional return to multicasting
US8713195B2 (en) * 2006-02-10 2014-04-29 Cisco Technology, Inc. Method and system for streaming digital video content to a client in a digital video network
US7738905B2 (en) * 2007-01-22 2010-06-15 Alcatel-Lucent Usa Inc. Dynamic power allocation for unicast-multicast superposition in wireless broadcasting
US9106800B2 (en) * 2007-08-31 2015-08-11 At&T Intellectual Property I, L.P. System and method of monitoring video data packet delivery
US9032433B2 (en) * 2007-10-05 2015-05-12 Alcatel Lucent Personalized ad insertion during start over service
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
CN101753973B (zh) * 2008-12-12 2013-01-02 华为技术有限公司 一种频道切换方法、装置和系统
US9380091B2 (en) * 2012-06-12 2016-06-28 Wi-Lan Labs, Inc. Systems and methods for using client-side video buffer occupancy for enhanced quality of experience in a communication network
CN102026311A (zh) * 2009-09-15 2011-04-20 富士通株式会社 基站以及相邻基站信息发送方法
CN102111715B (zh) * 2009-12-23 2014-04-30 华为终端有限公司 一种多播广播业务的方法、装置及系统
US20130124683A1 (en) * 2010-07-20 2013-05-16 Sharp Kabushiki Kaisha Data distribution system, data distribution method, data relay device on distribution side, and data relay device on reception side
DE102010045683A1 (de) 2010-09-16 2012-03-22 Heidelberger Druckmaschinen Ag Kombinierte Unicast/Multicast Softwareübertragung
CN101969431B (zh) * 2010-09-28 2013-06-12 广东威创视讯科技股份有限公司 一种实现流媒体播放单播、多播无缝切换的方法
US9002717B2 (en) * 2010-12-03 2015-04-07 At&T Intellectual Property I, L.P. Method and apparatus for audio communication of information
US8537816B2 (en) * 2010-12-29 2013-09-17 Avaya, Inc. Multicast VPN support for IP-VPN lite
US9026671B2 (en) * 2011-04-05 2015-05-05 Qualcomm Incorporated IP broadcast streaming services distribution using file delivery methods
FR2981530B1 (fr) * 2011-10-12 2013-12-06 Broadpeak Passerelle, et procede, programme d'ordinateur et moyens de stockage correspondants
US9526091B2 (en) 2012-03-16 2016-12-20 Intel Corporation Method and apparatus for coordination of self-optimization functions in a wireless network
US8867514B2 (en) * 2012-03-20 2014-10-21 Qualcomm Incorporated System and method of infrastructure service discovery
DK2885903T3 (en) * 2012-08-14 2016-09-19 ERICSSON TELEFON AB L M (publ) Processing multimedia data
US20140153471A1 (en) * 2012-11-30 2014-06-05 Qualcomm Incorporated Allowing unicast subframe structure for embms
US9402107B2 (en) * 2013-03-15 2016-07-26 Time Warner Cable Enterprises Llc Apparatus and methods for delivery of multicast and unicast content in a content delivery network
US9781487B2 (en) * 2013-05-28 2017-10-03 Cellco Partnership Streaming multicast content to a television via a mobile device
WO2015049810A1 (ja) 2013-10-01 2015-04-09 株式会社電通 多視点動画配置システム
CN104660298A (zh) * 2013-11-25 2015-05-27 上海益尚信息科技有限公司 新型在单播和广播多播复用模式下映射导频信号的方法和装置
JP2015122640A (ja) * 2013-12-24 2015-07-02 日立金属株式会社 中継システムおよびスイッチ装置
GB2521845B (en) 2014-01-03 2021-07-07 British Broadcasting Corp Content delivery
WO2015150736A1 (en) * 2014-03-31 2015-10-08 British Telecommunications Public Limited Company Multicast streaming
US9756098B2 (en) * 2014-09-15 2017-09-05 Verizon Digital Media Services Inc. Multi-tenant over-the-top multicast
FR3030172B1 (fr) * 2014-12-11 2018-02-09 Sagemcom Broadband Sas Procede et dispositifs permettant une transmission d'un flux de donnees selon un mode de transmission multipoint
US10771583B2 (en) * 2014-12-29 2020-09-08 Akamai Technologies, Inc. Managing mobile device user subscription and service preferences to predictively pre-fetch content
EP3241326B1 (en) 2014-12-31 2019-07-24 British Telecommunications public limited company Improved multicast to unicast conversion
US9641578B2 (en) * 2015-04-02 2017-05-02 Arris Enterprises, Inc. Minimizing unicast bandwidth in an adaptive bit rate system
WO2016184646A1 (en) * 2015-05-20 2016-11-24 Nxt Solutions Ag Iptv in managed networks
US9871666B2 (en) 2015-06-25 2018-01-16 AvaLAN Wireless Systems, Inc. Intermediate unicast network and method for multicast data networks
US10250499B2 (en) 2015-08-27 2019-04-02 Koninklijke Kpn N.V. Multicast transmission using programmable network
KR102381335B1 (ko) 2016-10-18 2022-03-31 이엑스피웨이 모바일 사용자 장치들에 컨텐츠를 전송하는 방법
US11032095B2 (en) 2016-11-23 2021-06-08 Nokia Technologies Oy Method for optimized delivery of sub-service flows using broadcast/multicast
JP2018129599A (ja) 2017-02-07 2018-08-16 株式会社毎日放送 受信装置、受信方法、送信装置、及び送信方法
US10257077B1 (en) 2017-03-22 2019-04-09 Amazon Technologies, Inc. Hop-aware multicast in a mesh network
US11445000B2 (en) * 2018-11-30 2022-09-13 British Telecommunications Public Limited Company Multicast to unicast conversion
US10972761B2 (en) * 2018-12-26 2021-04-06 Purdue Research Foundation Minimizing stall duration tail probability in over-the-top streaming systems
US20190190971A1 (en) 2019-02-22 2019-06-20 Akamai Technologies Inc. Reducing latency in multicast delivery of content
EP3932082A1 (en) 2019-02-27 2022-01-05 British Telecommunications public limited company Multicast assisted delivery
GB201902640D0 (en) 2019-02-27 2019-04-10 British Telecomm Multicast assisted delivery
US11601295B2 (en) * 2019-09-23 2023-03-07 Juniper Networks, Inc. Content delivery with reliable multicast using a redundant unicast overlay network
GB2598295B (en) 2020-08-19 2023-02-22 British Telecomm Content delivery

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7281058B1 (en) * 2002-10-09 2007-10-09 Juniper Networks, Inc. Delivering and receiving multicast content across a unicast network
US9673996B1 (en) * 2008-07-02 2017-06-06 Sprint Spectrum L.P. Redirection of a streaming media session in an anticipated failover scenario
EP2597824A1 (en) * 2010-07-20 2013-05-29 Sharp Kabushiki Kaisha Proxy server, relay method, communication system, relay control program, and recording medium
EP2670109A1 (en) * 2012-06-01 2013-12-04 Alcatel Lucent Method, system and devices for multimedia delivering in content delivery networks
WO2014032036A1 (en) * 2012-08-24 2014-02-27 Akamai Technologies, Inc. Hybrid http and udp content delivery
EP2704391A1 (en) * 2012-08-27 2014-03-05 Broadpeak System and method for delivering an audio-visual content to a client device
CN106233735A (zh) * 2014-03-31 2016-12-14 英国电讯有限公司 多播流传输
US10129855B1 (en) * 2015-05-07 2018-11-13 Sprint Spectrum L.P. Systems and methods for efficient transmissions of multicast content to wireless devices

Also Published As

Publication number Publication date
WO2020173878A1 (en) 2020-09-03
US20220141542A1 (en) 2022-05-05
WO2020173984A1 (en) 2020-09-03
US20220141543A1 (en) 2022-05-05
CN113475085A (zh) 2021-10-01
CN113475084A (zh) 2021-10-01
EP3932082A1 (en) 2022-01-05
CN113475084B (zh) 2024-02-02
EP3932083A1 (en) 2022-01-05
US11812115B2 (en) 2023-11-07

Similar Documents

Publication Publication Date Title
US10205971B2 (en) Media data live broadcast method, device, and system
CN113475085B (zh) 多播辅助传送
US20130114597A1 (en) Proxy server, relay method, communication system, relay control program, and recording medium
US20240114065A1 (en) Content delivery
GB2583020A (en) Multicast assisted delivery
US20230275949A1 (en) Method and apparatus for processing multicast signal
CN116034572B (zh) 向客户端装置递送内容的方法和装置
GB2586637A (en) Content delivery
US20220345508A1 (en) Content delivery - setting the unicast rate
US20230254349A1 (en) Content delivery
US11638057B2 (en) Content delivery
WO2023052191A1 (en) Content delivery
CN118020311A (zh) 内容递送
WO2023104514A1 (en) Content delivery
WO2023052190A1 (en) Content delivery

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant