CN106330751B - 异构网络传输下的资源动态请求时间窗口及终端缓存方法 - Google Patents

Abstract

本发明提供一种异构网络传输下的资源动态请求时间窗口及终端缓存机制，将原来宽带网络中的单向网络延迟修改为上下行的网络延迟，修改了请求时间窗口和缓存窗口大小的计算方法。客户终端通过网络中传输信令或发送ARQ消息的方法，获知当前宽带网络下的带宽和上下行延迟，通过宽带源内容的可获取时间和宽带信道的延迟，客户终端计算出发送请求提前缓存的时间区间及终端所需要的缓存窗口大小。最后，本发明给出了在旧的系统中Asset的Available_Time未给出的情况下，为了兼容性系统的处理方案。本发明解决了广播与宽带中组成的异构终端中内容因宽带拥塞而无法同步的问题，同时也减小了客户端由于缓存而带来的额外开销。

Description

异构网络传输下的资源动态请求时间窗口及终端缓存方法

技术领域

本发明涉及一种在异构网络传输下客户终端的资源动态时间请求窗口及缓存机制，具体的说，涉及一种确定终端请求发送媒体内容的时间区间，以及缓存窗口大小的分配方法。

背景技术

随着时代的变革，人们已不满足于仅仅依靠传统电视来获取信息和进行娱乐，更多的终端设备出现在我们面前，如连接互联网的PC、几乎人手一台的手机以及越来越普及的移动平板电脑等，这些新的产品已经在慢慢侵蚀传统电视业务的市场。随着移动通信和宽带无线技术的发展，以及多媒体业务的日益成熟，融合已成为信息通信业的发展潮流，它可以使用户能够便捷地接入网络，轻松地享用更丰富的媒体内容和多样化的服务。

与此同时，媒体内容的呈现将不只是简单的视频，音频，字幕，媒体类型将会越来越丰富多样。媒体来源也不只是特定的内容提供商，越来越多的制作者参与其中，包括很多个人用户同时也是内容的提供和制作者。这些来自不同提供者的内容存在着各种关联关系，为了满足不同用户的个性化需求，这些关联内容往往需要同步呈现。在此环境下，异构网络融合作为下一代网络发展的必然趋势，充分说明了未来的通信不再是某种特定的接入技术，而是多种接入技术并存、协同工作。

在由广播和宽带组成的异构网络环境下，终端呈现的媒体内容可同时从广播和宽带通道传输过来。对于此异构网络终端的呈现，有一种基于呈现信息—CI，CompositionInformation的多源内容分发机制。CI采用HTML5和XML等技术提供媒体数据的时间和空间信息，使得多媒体数据可以在终端进行多样化的呈现。

终端可以根据信令中的信息从服务器端请求相关内容，但是服务器端收到请求的时候，相关内容可能已经准备好，可能还没有。如果相关内容还没有准备好，终端的请求就会失败，然后再次请求，直到获得相关内容。这对终端是很大的负担，同时也会增加网络负担。

由于现在的宽带网络需要在多个节点对内容进行转发，因此存在网络延时大甚至网络阻塞等问题。因此需要在接收端提前对内容进行缓存，以应对终端内容无法播放或者媒体内容无法同步播放的问题。

缓存的引入又带来了新的问题，终端需要提前缓存多少的内容、从何时开始缓存，都会影响客户端设备的配置与系统的性能。因此客户端缓存窗口的大小和拉取缓存的时间成为一个亟待解决的问题。

中国专利申请CN201510064427.2，提供了一种在异构网络终端自适应地调整缓存窗口大小的方法，在中国专利申请CN201510064427.2基础上，进一步改进。

发明内容

在中国专利申请CN201510064427.2基础上，提供一种异构网络传输下的资源动态请求时间窗口及终端缓存机制，本发明解决了广播与宽带中组成的异构终端中内容因宽带拥塞而无法同步的问题，同时也减小了客户端由于缓存而带来的额外开销。

本发明是采用以下技术方案实现的：

一种异构网络传输下的资源动态请求时间窗口及终端缓存机制，针对已有的MMT中的信令，在MDP表、CI文件或MPU信令部分增加媒体内容的Available_Time及Asset_Size属性，使客户终端获知相应媒体内容能获取的时间；同时，客户终端通过网络中相应的方法确定当前宽带网络下的网络带宽及网络的上、下行延迟，通过宽带源内容的可获取时间和宽带信道的延迟，客户终端计算出发送请求提前缓存的时间区间及终端所需要的缓存窗口大小。

本发明在中国专利申请CN201510064427.2基础上，将原来宽带网络中的单向网络延迟修改为上下行的网络延迟，修改了请求时间窗口和缓存窗口大小的计算方法。客户终端通过网络中传输信令或发送ARQ消息的方法，获知当前宽带网络下的带宽和上下行延迟，通过宽带源内容的可获取时间和宽带信道的延迟，客户终端计算出发送请求提前缓存的时间区间及终端所需要的缓存窗口大小。最后，本发明给出了在旧的系统中Asset的Available_Time未给出的情况下，为了兼容性系统的处理方案。

采用本发明的技术方案，针对已有的MMT中的信令，通过在信令中加入新的属性，解决了因宽带中网络阻塞而导致的媒体内容难以同步的问题，从而解决因IP网络拥塞带来的同步问题。同时，考虑到对已有系统的兼容性，本发明也给出了在Asset的Available_Time未知的情况下，提前请求资源的方案。

附图说明

通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1是异构网络的模型示意图；

图2是计算客户端发送请求的动态时间窗口及终端分配的缓存窗口大小的流程图。

具体实施方式

下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进。这些都属于本发明的保护范围。

如今，基于异构网络的多样化终端呈现方式已成为发展的趋势。在观看高质量广播视频节目的同时，人们对于多样化的网络媒体服务的诉求也越来越高。在由广播和宽带网络组成的异构系统中，由CI来控制客户端播放广播与宽带内容的时间与空间布局，实现媒体内容的同步。一般来说，由广播通道过来的媒体内容有很小并且固定的延时，因此对于同步没有影响；而从宽带过来的媒体内容如音视频、字幕、多媒体应用等内容易受当前IP网络影响，产生较大且抖动的延时，给内容同步带来了问题；同时，从宽带过来的内容存在有效访问期的问题，即从某个时间点开始可以访问，到某个时间点前有效。因此本发明给出了内容的有效时间信息，并设计了一种在终端提前请求该信息的发送，并为相应内容分配缓存窗口的机制。

为了解决问题，首先在原有的信令或其他地方给每部分内容都加入一个新属性:Available_Time，用以说明宽带中待传送的该内容在内容提供商处准备好并可以开始传输的时间，以及结束访问时间。其赋值遵循如下规则：

1)时间未知

若服务器端还不能确定待传送的内容准备好的时间，则Available_Time赋值为"unknown"；同时为了考虑系统的兼容性，若服务器端发送的信令中未添加Available_Time属性，则终端解析为Available_Time为未知。

2)随时可以访问

若服务器端的媒体内容随时可以访问与发送，则Available_Time赋值为"anytime"。

3)某个特定时间开始后，一直有效

若服务器端的内容在某个特定时间开始后一直有效，则Available_Time赋值为该特定的UTC时间，即"UTC1"。

4)某个特定时间区域内有效

若服务器端的内容在某个特定的时间区间内可获取，则Available_Time赋值为该时间区间，即"UTC1--UTC2"，括号内为UTC。

对于Available_Time的解析工作在终端完成

同样可根据需要在信令或其他地方给每部分内容加入Asset_Size属性，用以表示该部分内容的大小。

新添加的属性，Available_Time和Asset_Size，在系统中的具体位置可以根据需要添加在不同地方。比如CI，MPT,MPU等。下面就以这几个位置为例给予介绍。

下面分别给出了在CI、MPT和MPU中添加Available_Time和Asset_Size属性的实例：

1)在CI中添加新的属性

若mediaSrc属性在MediaSync元素里，则将新添加的Available_Time和Asset_Size属性同样放在此元素中，如下：

若mediaSrc属性在MediaSync元素的子元素sourceList里，则新添加的Available_Time和Asset_Size属性放在相应的sourceList中，如下：

2)在MPT中添加新的属性

可以在MPT表中为每个asset增加Asset_Size，描述其大小。

若内容有多个源地址，则为每个源地址中的该部分内容都分配一个Available_Time；若该内容只有一个源地址，则只为该地址的源内容分配一个Available_Time。具体实现方式可以有多种，下面给出两个示例。

A.在MPT中加入Available_Time_Type和MMT_Available_Time_info()，以四种情况为例子，我们可以分配Available_Time_Type两个比特，用以表征Avaliable_Time的四种情况，如果可获取时间的分类情况更多，可考虑分配更多比特。MMT_Available_Time_info()说明了媒体内容的可获取时间或可获取时间区间信息。MPT如下：

MP table Syntax

MMT_Available_Time_info Syntax

Available_Time_Type:这两个比特表明在可获取时间的类型，说明如下：

Value of Available_Time_Type

B.只在MPT中加入MMT_Available_Time_info()，MMT_Available_Time_info()说明了媒体内容的可获取时间或可获取时间区间信息。MPT如下：

MP table Syntax

MMT_Available_Time_info Syntax

available_begin和available_end的用法如下

3)在MPU中添加新的属性

在MPU中因为描述的是单个MPU的大小，故此处取mpu_size

动态分配缓存窗口大小的缓存机制设计思路如下：在专利“201510064427.2_一种在异构网络终端自适应地调整缓存窗口大小的方法”基础上,修改如下：CI文件中已有的属性已包括对象的正常开始呈现的时间—begin，同时可通过网络内发送HRBM message和ARQ消息的方法，可得到当前宽带网络下的上行延时—D_f,下行延时—D_t,宽带网络的带宽—Bandwidth。在信令中或其他地方加入宽带内容可获取时间的属性Available_Time和Asset_Size后：设定一个阈值Threshold，若下行延时D_t小于此阈值，则该延时可忽略不计，系统无需为宽带传输的媒体内容分配额外缓存；若D_t大于此阈值，则可通过具体方案中的方法确定请求提前发送宽带中媒体内容的时间区间，并为终端分配缓存窗口。若网络延时很大，内容提供商提供的Available_Time已不满足提前缓存保持同步的条件，则直接将该宽带通道传送的辅助内容丢弃。

具体方案如下(下面的步骤可以根据实际情况选用，组合)：

1)在信令中或其他地方加入对应内容的Available_Time和Asset_Size属性；

2)客户终端通过IP网络内的相应方法，如传输信令或发送ARQ消息，得到当前宽带网络的上行延时D_f，下行延时D_t与宽带网络的带宽Bandwidth；

3)客户端通过解析信令得到对应媒体内容的可获取时间—Available_Time，正常播放时间—begin以及对应内容的大小—Asset_Size；

4)若D_f<Threshold，则延时忽略不计；若D_t>Threshold，则通过如下方法计算出终端发送请求的时间窗口和终端分配的缓存大小：

①计算服务商传输一个内容单元所需要的时间：Data_Transfer_Time,此时间可由一个内容单元的大小和当前宽带环境下比特率来计算获取；

②若Available_Time为"unknown"或CI中并无此属性，则不进行处理；若Available_Time为"anytime"，则跳过此步骤进入③；若Available_Time为一个特定的UTC时间一个UTC时间的区间，则取最早的时间进行如下判断：

Available_Time+D_t+Data_Transfer_Time<begin (1)

若条件(1)不成立，则表明待传送的媒体内容可获取时间太晚，在当前网络的延时下不能及时到达终端，故丢弃此部分内容；若条件(1)成立，则表明当前网络延时带来的不同步问题可由提前缓存来解决，进行下一步计算；

③计算终端请求提前发送媒体内容的时间区间：

请求最早时间：

Earliest_Request_Time＝Available_Time-D_f (2)

请求最晚时间：

Latest_Request_Time＝begin-D_f-D_t-Data_Transfer_Time (3)

实际请求的时间介于两个时间点之间：

Earliest_Request_Time<Actual_Request_Time<Latest_Request_Time (4)

④终端选定一个请求时间后，则终端能够开始接受服务商数据的时间为：

Receive_Time＝Actual_Request_Time+D_f+D_t (5)

终端到begin时间点之前接收数据的时间为：

Δt＝begin-Receive_Time (6)

⑤如果CI中给出了Asset_Size属性，则终端分配的缓存窗口大小为：

Buffer_Size＝min{Δt*bitrate，Asset_Size} (7)

若果CI中未给出Asset_Size属性，则终端分配的缓存窗口大小为：

Buffer_Size＝Δt*bitrate (8)

计算流程图见附图2，方案中用到的变量及其含义总结如下表：

下面给出一个实例：

已知客户端在接收到对应信令时系统的当前状态如下，此处设定Threshold为0.1s，Data_Transfer_Time一般依据当时data大小和比特率，这里取3s

该信令包含的一个图像和音频的文件信息如下：

当前的网络延时为10s，远大于0.1s的Threshold，说明10s的宽带延时是不可接受的，需要提前请求内容的发送。

对于Image.1，其可获取时间为北京时间4:59:50后的所有时间，但其可获取时间太靠后，不满足条件(1)，即不能再播放时将内容发送至终端，故此内容丢弃。

对于Audio.1，其可获取时间在北京时间4:59:20至4:59:50之间，其4:59:20满足条件(1)，故可由式(2)和(3)得到请求发送的时间区间：

Earliest_Request_Time＝2015-01-31T4:59:10+08:00

Latest_Request_Time＝2015-01-31T4:59:37+08:00

若取实际的请求时间为:

Actual_Request_Time＝2015-01-31T4:59:30+08:00

若当前比特率为200Kb/s,则可得各变量参数如下

Earliest_Request_Time	2015-01-31T4:59:10+08:00
		Latest_Request_Time	2015-01-31T4:59:37+08:00
Actual_Request_Time	2015-01-31T4:59:30+08:00
		Receive_Time	2015-01-31T4:59:50+08:00
Δt	20s
		Δt*bitrate	4M
Buffer_Size	2Mb

其中Buffer_Size取Δt*bitrate与Asset_Size的最小值，即2Mb。

故在此实例中，Image.1因为Available_Time时间点给定较晚丢弃，Audio.1可由CI中给定的Available_Time和Asset_Size得到终端应该提前请求发送的时间和应该准备的缓存窗口大小。

如果在旧的的系统中，接收方无法获知Asset的Available_Time，为了系统的兼容性，系统可采取如下处理方法：终端在begin时间之前某个合适的时刻发送一次请求(仅发送一次)，经过上行延时D_f之后，服务器端在时刻t收到请求：

a)如果时刻t在Asset的Available_Time之前且根据接收方的等待时间窗口大小判断出时间间隔较大，则服务器端发送消息给接收端，告诉接收端Asset的Available_Time。服务器于Available_Time发送Asset。

b)如果时刻t在Asset的Available_Time之前但根据接收方的等待时间窗口大小判断出时间间隔不大(，则服务器端直接等待至Available_Time然后直接发送Asset。

c)如果时刻t在Asset的Available_Time之后，则做如下判断：

t+D_t<Begin (9)

若(9)式成立，则表明现在发送Asseet接收方能按时接收下来，因此服务器端在当前时刻发送Asset，若(9)式不成立，则表明当前时刻发送Asset已晚，丢弃该Asset。

以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变形或修改，这并不影响本发明的实质内容。

Claims (3)

1.一种异构网络传输下的资源动态请求时间窗口及终端缓存方法，其特征在于，针对已有的MMT中的信令，在MDP表、CI文件或MPU信令部分增加媒体内容的Available_Time及Asset_Size属性，使客户终端获知相应媒体内容能获取的时间；同时，客户终端通过网络中相应的方法确定当前宽带网络下的网络带宽及网络的上、下行延迟，通过宽带源内容的可获取时间和宽带信道的延迟，客户终端计算出发送请求提前缓存的时间区间及终端所需要的缓存窗口大小；

在原有的MMT信令中给有需要的内容加入新的属性:Available_Time和Asset_Size，用以说明宽带中待传送的该内容在内容提供商处准备好并可以开始传输的时间以及该部分内容的大小；Available_Time赋值遵循如下规则：

1)时间未知

若服务器端还不能确定待传送的内容准备好的时间，则Available_Time赋值为"unknown"；若服务器端发送的信令中未添加Available_Time属性，则终端解析为Available_Time为未知；

2)随时可以访问

若服务器端的媒体内容随时可以访问与发送，则Available_Time赋值为"anytime"；

3)某个特定时间开始后，一直有效

若服务器端的内容在某个特定时间开始后一直有效，则Available_Time赋值为该特定的UTC时间，即"(UTC1)"；

4)某个特定时间区域内有效

若服务器端的内容在某个特定的时间区间内可获取，则Available_Time赋值为该时间区间，即"(UTC1)-(UTC2)"；

对于Available_Time的解析工作在终端完成。

2.根据权利要求1所述的异构网络传输下的资源动态请求时间窗口及终端缓存方法，其特征在于：终端能够获取的CI文件中已有的属性包括对象的正常开始呈现的时间—begin，同时通过网络内发送HRBM message或ARQ消息的方法，得到当前宽带网络下的上行延时—D_f、下行延时—D_t、宽带网络的带宽—Bandwidth；在信令中加入宽带内容可获取时间的属性Available_Time和Asset_Size后：设定一个阈值Threshold，若下行延时D_t小于此阈值，则该延时忽略不计，系统无需为宽带传输的媒体内容分配额外缓存；若D_t大于此阈值，则确定请求提前发送宽带中媒体内容的时间区间，并为终端分配缓存窗口；若网络延时很大，内容提供商提供的Available_Time已不满足提前缓存保持同步的条件，则直接将该宽带通道传送的辅助内容丢弃。

3.根据权利要求2所述的异构网络传输下的资源动态请求时间窗口及终端缓存方法，其特征在于：所述确定请求提前发送宽带中媒体内容的时间区间，并为终端分配缓存窗口，具体方案如下：

1)在信令中加入对应内容的Available_Time和Asset_Size属性；

2)客户终端通过网络内的相应方法，得到当前宽带网络的上行延时D_f、下行延时D_t与宽带网络的带宽Bandwidth；

3)客户端通过解析信令得到对应媒体内容的可获取时间Available_Time，正常播放时间begin以及对应内容的大小Asset_Size；

4)若D_t<Threshold，则延迟忽略不计；若D_t>Threshold，则通过如下方法计算出终端发送请求的时间窗口和终端分配的缓存大小：

①计算服务商传输一个内容单元所需要的时间：Data_Transfer_Time，此时间由一个内容单元的大小和当前宽带环境下比特率来计算获取；

②若Available_Time为"unknown"或CI中并无此属性，则不进行处理；若Available_Time为"anytime"，则跳过此步骤进入③；若Available_Time为一个特定的UTC时间区间，则取最早的时间进行如下判断：

Available_Time+D_t+Data_Transfer_Time<begin (1)

若条件(1)不成立，则表明待传送的媒体内容可获取时间太晚，在当前网络的延时下不能及时到达终端，故丢弃此部分内容；若条件(1)成立，则表明当前网络延时带来的不同步问题可由提前缓存来解决，进行下一步计算；

③计算终端请求提前发送媒体内容的时间区间：

请求最早时间：

Earliest_Request_Time＝Available_Time-D_f (2)

请求最晚时间：

Latest_Request_Time＝begin-D_t-D_f-Data_Transfer_Time (3)

实际请求的时间介于两个时间点之间：

Earliest_Request_Time<Actual_Request_Time<Latest_Request_Time (4)

④终端选定一个请求时间后，则终端能够开始接收服务商数据的时间为：

Receive_Time＝Actual_Request_Time+D_t+D_f (5)

终端到begin时间点之前接收数据的时间为：

Δt＝begin-Receive_Time (6)

⑤如果CI中给出了Asset_Size属性，则终端分配的缓存窗口大小为：

Buffer_Size＝min{Δt*bitrate，Asset_Size} (7)

若果CI中未给出Asset_Size属性，则终端分配的缓存窗口大小为：

Buffer_Size＝Δt*bitrate (8)。