内容递送的制作方法

1.本发明涉及使用单播和多播的组合来进行内容递送的领域。


背景技术：

2.越来越多的实况内容使用http(或https)被流传输。流行实况事件驱动极不稳定的需求，从而导致通信量的非常高的峰均比。例如，图1中的图表100示出了在欧洲2016足球比赛期间取得的靠近移动网络边缘的网关处的通信量的示例。标绘图102示出了在没有足球赛的情况下一天(6月15日星期三)的通信量，并且标绘图104示出了第二天(6月16日星期四)当英格兰与威尔士比赛时的通信量。这两个标绘图粗略示出了一天中相同的通信量，但是标绘图104具有介于约14:00时到16:00时之间的显著附加通信量峰值除外，这是由客户流传输足球比赛而产生的。
3.这种高峰均比引起了对网络边缘的特别挑战，其中这种峰值可能导致用户体验质量的降级。
4.最常见地，使用http(或https)请求/响应对来通过互联网递送内容。客户端应用将向服务器发送http请求，并且将返回包含所请求的内容的响应。这种请求/响应本质上是单播。
5.可以将http(s)用于视频流传输。通常，客户端将获得清单文件，该清单文件将允许确定包含视频片段的单独文件的url。然后，客户端将按顺序请求这些片段，并将它们连结以形成用于回放的连续流。各个视频片段也可以以不同的比特率来获得，以允许视频速率自适应网络吞吐量。这种技术被称为http自适应流传输(has)。
6.对于观看同一事件(诸如实况足球比赛)的用户，各个客户端皆将作出其自己的http请求并得到其自己的http响应，即使在http响应内向它们递送的内容的大部分在这些客户端之间是相同的。这导致对网络的非常低效的使用。
7.然而，如果接入网络能够使用多播而不是单播来进行内容递送，那么可以显著降低图1所示的实况内容峰值的影响。此外，在接入网络中使用多播还可以显著降低对内容递送网络服务器的峰值需求。
8.已经存在解决这种问题的解决方案，其中使用代理将多播路径插入到客户端与内容服务器之间的另外单播路径中。这类混合解决方案的示例包括：“ip multicast adaptive bit rate architecture technical report”oc-tr-ip-multi-arch-c01-161026,26/10/2016,by cable labs；3gpp specifications,23.246(mbms architecture and functional description),26.346(mbms protocols and codecs)and 26.347(mbms apis)；以及dvb document a176,“adaptive media streaming over ip multicast”,(8th march 2018)。
9.图2示出了这类解决方案的概括示例。
10.在图2中，示出了向客户端装置204a、204b以及204c提供内容(诸如视频)的内容服务器202。将多播代理x 206和三个代理y 208a、y 208b以及y 208c插入到内容服务器202与
客户端装置之间的另外单播路径中。代理x 206从内容服务器202获取单播内容，并且使该单播内容经由多播可获得。代理y接收多播内容，并且可以使该多播内容通过单播用于任何请求客户端装置。所有客户端装置将接收它们对片段请求的相同响应，这是因为所有代理y从代理x接收到同一多播内容。可以将代理y定位于客户端装置内，或者定位于单独装置内，或者可以仅有取决于设立的单个代理y。
11.在这样的解决方案中，代理x被预先配置成充当客户端，并且独立地做出对内容片段的请求并且将整个响应分派到多播网络中。代理x是通过首先请求清单文件，然后及时请求该清单文件内描述的内容片段来做到这一点的。在一些情况下，内容服务器在提供内容之前，可能需要客户端装置利用有效凭证来认证它们自己。这是通过向代理x提供能够访问来自内容服务器202的内容的有效凭证来完成的。因此，使用在代理x 206处配置的凭证而不是由单独客户端装置提供的任何凭证来完成认证。代理x 206就像伪客户端一样有效地起作用。
12.而且，在这样的布置中，难以确定代理x应当以什么速率来通过多播发出内容。通常，现有布置已经获知或者访问指定可获的内容和关联速率的清单。在一些解决方案中，对清单进行操纵，以使客户端仅具有选定速率的可见性，这将所有客户端限制成选择单个内容速率，从而使得直接递送该内容。然而，这种解决方案不适当地支持http自适应流传输，并且如已经识别的，需要对清单的访问。
13.其它布置也遭受类似问题。


技术实现要素：

14.本发明的示例的目的是提供一种改进的内容递送机制。
15.根据本发明的一个示例，提供了一种管理通过网络到客户端装置的内容递送的方法，其中，该内容包括多个片段，所述方法包括以下步骤：
16.i)在第一网络部件处接收来自客户端装置的对多个片段的单播请求；
17.ii)在第一网络部件处通过单播接收所请求的多个片段；
18.iii)确定针对各个给定片段的请求之间的时间间隔；
19.iv)确定各个给定片段的大小；
20.v)将递送速率估计为所述片段的总大小和与该片段相关联的时间间隔的总和的商；
21.vi)在第一网络部件处接收来自客户端装置的针对另一些片段的单播请求；
22.vii)通过多播向第一网络部件递送另一些片段，其中，被用于递送所述另一些片段的多播速率是所估计的递送速率的函数。
23.该递送速率可以是对多个片段计算的平均递送速率。
24.可以通过多播从第二网络部件向第一网络部件递送所述另一些片段。第一网络部件和第二网络部件可以是代理服务器。
25.确定各个片段的大小的步骤可以由第一网络部件来执行。可以将所估计的递送速率取为根据请求同一片段的多个客户端的平均估计递送速率。
26.所接收到的片段中的一个或更多个片段可以包括客户端专用数据以及可应用于多个客户端的公共数据，确定各个给定片段的大小的步骤可以包括确定公共数据的大小，
并且通过多播递送所述另一些片段的步骤可以包括使用多播速率通过多播来递送公共数据。
27.第一网络部件可以向内容服务器发送针对多个片段的单播请求。
28.该内容可以是媒体内容。该媒体内容可以包括视频序列。
附图说明
29.为了更好地理解本发明，现在针对附图，仅通过示例的方式来进行说明，其中：
30.图1是示出不同天的网络上的通信量的图表；
31.图2是一般现有解决方案的网络图；
32.图3是示出本发明的示例的主要组件的网络图；
33.图4是概括本发明的示例的步骤的流程图；
具体实施方式
34.本文中参照特定示例，对本发明进行了描述。然而，本发明不限于这样的示例。
35.本发明的示例提供了一种管理用于在混合单播/多播网络中递送内容的网络的方法，其中，内容是由客户端通过单播来请求的，但是该内容的全部或一些是部分地通过多播来递送的。客户端请求内容(采用片段的形式)并且经由第一代理通过单播接收响应(片段)。第一代理测量请求之间的时间以及关联的请求片段大小。将这些测量结果用于有效地确定由片段大小除以请求之间的时间而给出的单播请求速率。然后，后续请求的片段可以使用多播速率通过多播在路由的一部分上被递送至客户端，该多播速率被设定为单播请求速率的(例如，110％)的函数。通常，多播路径将从第二代理到第一代理。这允许以混合单播/多播布置来递送内容，其中，被用于多播路径的速率可以根据单播请求速率来设定，而无需知道或访问清单。
36.可以将本发明的示例应用于如上讨论的已知单播/多播混合网络，以及应用于在本技术人的专利申请ep19159748.3中阐述的发明，该专利申请描述了被称为“多播辅助单播递送”(multicast assisted unicast delivery，maud)的布置。在maud中，使用多播网络来辅助(而不是取代)另外单播路径。客户端装置通过单播从内容服务器请求内容。将包含所请求内容的响应分离成两个组分(component)：第一组分包含专用于单独客户端装置的要素(例如，会话专用数据)，而第二组分对于所有客户端装置是公共的(通常这是正被请求的视频内容)。第一组分可以通过单播被递送，第二组分可以通过多播被递送，并且稍后进行重新组合以形成原始响应。分离和重组是由经适当配置的代理服务器来处理的。可以将本发明的示例用于估计在代理服务器之间递送多播组分的速率。
37.图3示出了支持内容递送的“多播辅助单播递送”(maud)网络的主要组件。网络300包括：内容服务器302、代理x 306、代理y 308a、y 308b和y 308c、客户端装置304a、304b和304c、以及多播控制器312。内容服务器302向诸如客户端装置的请求实体提供诸如视频的内容。可以将内容服务器302定位于内容递送网络(cdn)内，并且可以有多于一个内容服务器。代理x 306可以通过单播与内容服务器302进行通信。代理x 306还可以通过单播和多播两者与代理y 308a、y 308b以及y 308c进行通信。可以将代理y定位于客户端装置内、定位于分离的装置(诸如家庭网关)中，或者可以是取决于设立的单个代理y。
38.注意，在图3中，将双向单播通信路径用实线进行标记，将单向多播通信路径用虚线进行标记，并且将控制接口通信路径用点划线进行标记。控制接口通信路径在多播控制器312与网络中的其它部件之间传送控制消息/命令。
39.假设客户端装置运行相应的客户端应用，这些客户端应用是内容请求的源。为简单起见，术语客户端装置从这里开始被用来指运行客户端应用的客户端装置。客户端装置可以对在内容服务器302处保持的内容进行http单播请求。
40.被保持在内容服务器302处的内容通常是包括根据诸如itu h.264标准的适当标准编码的视频序列的媒体内容(例如，tv节目、电影或整个线性tv频道)。将该视频序列以顺序时间片段的形式存储在内容服务器302中，其中各个片段皆通常等于2秒钟到10秒钟长的经解码视频。清单文件由客户端用来标识片段位于何处(根据清单中的url)。因此，客户端装置通过使用清单以根据需要依次确定在哪里引导各个片段的顺序单播请求，从而流传输视频序列。在诸如mpeg-dash和apple's hls(http实时流传输)的http自适应流传输技术中使用这种配置。
41.多播控制器312(mcc)监测代理x和代理y的操作，以确定哪个通信应当使用多播辅助(maud)，并且相应地控制代理。因此，在本发明的示例中，客户端装置可以直接通过单播从内容服务器302接收一些通信量，并且使用maud接收其它通信量。
42.客户端装置对内容作出的许多http请求将不利用maud，而是被直接发送至内容服务器。
43.来自客户端装置的可以受益于maud的对内容的其它请求被重定向至所述代理y中的一个代理，或者简单地被所述代理y中的一个代理拦截。
44.可以使用许多公知技术中的任一公知技术(诸如使用来自内容服务器302的http重定向)，将代理y插入http路径中。在这种情况下，内容服务器302将被配置成使得不直接提供对潜在流行内容的请求，而是相反将该请求重定向至适当的代理y。例如，代替提供正常响应，内容服务器302可以利用指示临时重定向的http状态码307来进行响应。这邀请客户端装置对内容服务器在该内容服务器的响应中提供的新url作出新请求，从而使得能够向代理y作出请求。该技术允许内容服务器和代理y存在于不同的域中，而情况通常就是如此。
45.在http路径中插入代理y的其它机制包括：被配置为透明代理的代理y(虽然所有请求都被它拦截，并且只对未经加密的通信量起作用)；被配置为前向代理的代理y(其中，客户端装置依靠被明确地配置成这样做来直接向代理y发送其请求)；dns劫持(其中dns服务器被配置成为关注域提供代理y的ip地址)；以及清单操纵(其中，清单文件被重写以使直接向代理y进行请求)。
46.图4示出了概括本发明的一般示例的步骤的流程图。
47.在步骤400开始，一个或更多个客户端装置请求内容片段(诸如被存储在内容服务器302处的电影)，并且经由代理y通过单播接收响应(片段)。例如，客户端装置304a进行http get请求，该请求实质上是针对内容片段的单播。各个http get请求皆包括可以从哪里检索该片段的url。在与内容相关联的清单文件中找到url。代理y 308a接收请求，并将该请求转发至内容服务器302。
48.内容服务器302以http响应进行响应，各个http响应皆包含所请求的片段。http响
应实际上也是单播响应。响应由代理y 308a接收并被发送至客户端装置304a。所接收到的片段然后可以由客户端装置304a查看。
49.客户端装置304a可以根据步骤400继续请求和接收片段，直到该内容的流传输完成。然而，在本发明的示例中，多播控制器312确定是否应当使用多播组来递送后续片段，以及还确定应当以哪种速率通过多播来发送这些片段。
50.因此，在步骤402中，代理y 308a测量在步骤400中从客户端装置304a接收到的针对片段sn的请求之间的时间间隔tn。例如，如果在t＝0s请求片段s0，在t＝6s请求s1，在t＝11s请求s2，在t＝18s请求s3，则针对片段s1的请求之间的时间间隔是t1＝6s，针对片段s2的请求之间的时间间隔是是t＝5s，针对片段s3的请求之间的时间间隔是是t＝7s。
51.代理y 308a还测量它接收的片段sn的对应大小。例如，片段s1可以是6mb，片段s2可以是5mb以及片段s3可以是7mb。
52.在步骤404中，代理y 308a向多播控制器312发送具有间隔和片段大小数据的消费报告，连同与通过代理的http请求/响应对相关的数据(例如，各个http请求的url)。消费报告可以以间隔(时间间隔或者在已经请求/接收到一定数量的片段之后)被发送至多播控制器312。
53.现在，到目前为止描述的http请求和响应本质上都是单播。然而，应注意，针对同一内容的请求可以由其它客户端装置来作出。例如，在实况足球比赛期间情况通常如此。代理y 308a以及其它代理y(308b或308c)在适当时为它们相应的客户端装置向多播控制器312发送消费报告，以使多播控制器312可以确定是否使用多播来帮助递送进一步内容。
54.在步骤406中，多播控制器312使用所接收到的报告来确定从代理y的给定群体报告的http请求是否证明多播的使用对于它们的响应是合理的。这种代理y的群体被称为“同组(cohort)”。假设满足某些条件(例如，大于请求同一内容的客户端装置的某一数量)，多播控制器312将通过设立适当的多播组来配置用于多播辅助递送的代理x和任何相关代理y(即，同组)。一旦设立了多播组，就使用多播将内容(所请求的片段)从代理x发送回代理y。
55.多播控制器312使用间隔和片段大小数据来估计由片段大小和片段间隔的商给出的单播请求速率：
[0056][0057]
在实践中，所估计的速率很可能是针对多个片段(例如，最近3个片段)取得的平均速率。平均速率可以被表示为：
[0058][0059]
其中，i和j是正被考虑的片段范围内的第一片段和最后片段。
[0060]
然后，可以将该估计速率用作对多播速率进行设定的基础。根据式(1)或(2)，将多播速率有效地设定为估计速率的函数：
[0061]
rate
multicast
＝fn(rate
unicast
)
ꢀꢀ
(3)
[0062]
例如，可以将多播速率设定在所估计的单播速率的110％。
[0063]
还应注意，来自式(1)和(2)的单播速率可以针对请求同一内容/片段的多个不同客户端装置来求平均。
[0064]
在步骤408中，多播控制器312可以通过发送代理y 308a指令以设立http请求路由来将代理y 308a添加至同组，由此将与特定url路径/模式/串匹配的请求定向至代理x 306。多播控制器312还发送代理y 308a指令以提供多播监听器。该指令告诉代理y 308a准备接收多播。多播监听器使代理y向由多播控制器指定的多播地址发出igmp加入命令。
[0065]
为了允许代理x 306将多播用于针对满足为代理y 306设立的匹配模式的请求的响应的返回路径，多播控制器312将代理x 306配置成将多播用于由内容服务器发送的某些响应。例如，该指令可以是仅将多播辅助用于包含视频文件或mime类型(诸如“视频/mp4”或“视频/mp2t”)的响应，从而仅通过多播发送包含视频通信的响应。在另选示例中，可以基于特定etag或etag范围来选择响应。etag(实体标签)是http1.1规范的部分，并且被用于唯一地标识响应有效载荷。
[0066]
代理x 306以及所述代理y中的一个或更多个代理y现在被配置为分别通过多播发送和接收内容。
[0067]
多播控制器312还发送代理x 306指令，以使用根据式(3)确定的多播速率，通过多播将数据从代理x 306发送至任何代理y。如上面所讨论的，可以将所使用的多播速率设定为在分数上高于基础估计单播速率，例如该估计单播速率的110％。
[0068]
该估计多播速率是这样的速率，即，需要以该速率发送内容片段来尝试和确保足够快地递送数据，以满足请求客户端装置的需求。否则，存在客户端装置将以比多播速率快的速率请求片段的风险。
[0069]
在步骤410中，客户端装置304a发送http get请求，并且在针对另一些片段的代理y 308a处接收该请求。代理y 308a检查以查看该请求是否与稍早阐述的模式匹配。匹配有效地意味着应当通过多播来实现该请求。假设所述请求与所述模式匹配，则代理y 308a将http get请求发送到代理x 306(而不是直接发送至内容服务器302)上。
[0070]
代理x 306将所接收到的http get请求发送至内容服务器302，该内容服务器以http响应中的所请求的片段来响应代理x 306。然后，代理x 306以式(3)得出的估计多播速率，通过多播发送这些片段(假设如上所述满足文件条件)。
[0071]
代理y 308a被配置成接收多播，并因此将从代理x 306接收通过多播发送的片段。然后，通过单播将所接收到的片段从代理y 308a发送至客户端装置304a。
[0072]
应注意，可以将设定多播速率的上述发明的示例应用于其它混合单播/多播布置。例如，本技术人的欧洲专利申请ep19159748.3阐述了一种被称为“多播辅助单播递送”(multicast assisted unicast delivery，maud)的装置。客户端装置通过单播从内容服务器请求内容。将包含所请求内容的响应分离成两个组分：第一组分包含专用于单独客户端装置的要素(例如，会话专用数据)，而第二组分对于所有客户端装置是公共的(通常这是正被请求的视频内容)。第一组分可以通过单播进行递送，第二组分可以通过多播进行递送，并且稍后进行重新组合以形成原始响应。通过多播递送的组分可以以根据如上所述的本发明的示例设定的速率来递送，其中，给定片段的大小被确定为公共数据的大小，并且通过多播递送的所述另一些片段包括公共数据。通常，客户端或会话专用数据是片段头部，而公共组分是片段的有效载荷部分。
[0073]
注意，在所描述的示例中使用的术语“单播”通常旨在覆盖点对点通信服务。类似地，术语“多播”旨在涵盖点对多点服务，包括广播服务。
[0074]
通常，本文中应注意，虽然上面描述了本发明的示例，但是在不脱离所附权利要求中限定的本发明的范围的情况下，存在可以对上述示例进行的许多变型例和修改例。本领域技术人员将认识到对所述示例的修改。