一种异构媒体传输网络下的资源动态请求方法与流程

本发明涉及信息技术领域的异构媒体网络传输方法，具体地，涉及一种异构媒体传输网络下的资源动态请求方法。

背景技术：

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

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

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

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

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

同时，服务端如果太晚提供媒体内容，终端用户就无法及时取到相关资源，因此在特定的网络媒体服务下，服务端是否必要通知终端媒体准备好的时间，以及何时通知，也成为一个需要解决的问题。

中国专利申请CN201510064427.2，提供了一种异构网络终端自适应地调整请求时间窗口的方法。本发明在中国专利申请CN201510064427.2的基础上，进行进一步的改进。

技术实现要素：

本发明的目的是提供一种异构媒体传输网络下的资源动态请求方法，在中国专利申请CN201510064427.2基础上，实现异构媒体网络传输下服务端发送媒体资源信令以及终端动态请求该媒体资源时间窗口的机制。本发明解决了异构媒体网络传输中因网络拥塞等因素造成的媒体相关资源无法同步播放的问题。

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

一种异构媒体传输网络下的资源动态请求方法，针对已有的MMT中的信令，在MPT表、CI文件和MPU信令部分增加媒体内容的Available_Time，Available_Time使客户终端获知相应媒体内容能获取的时间；同时，客户终端确定当前网络下的网络带宽及网络的上、下行延迟，通过源内容的可获取时间和延迟，客户终端可以计算出不同服务端的情况下发送提前请求缓存内容消息的时间区间。

本发明在中国专利申请CN201510064427.2基础上，在信令MPT的MMT_general_location_info()的预留字段里添加了asset的可获取时间Available_Time信息，对于目前处理资源请求消息有不同处理方式的服务端，给出了不同的计算Available_Time时间窗口的方法。

优选地，所述方法在信令MPT的MMT_general_location_info()的预留字段里添加了asset的可获取时间Available_Time信息，具体为：

首先在原有的信令给每部分内容都加入新属性:available_begin和available_end，用以说明在当前网络中待传送的该内容在内容服务商处准备好并能开始传输的时间，以及结束访问时间；

MPT中的MMT_general_location_info()描述符提供了媒体资源和相关信令的来源信息，其中location_type为0x00～0x06和0x0C的取值对应的为asset资源的位置信息，0x07～0x0B的取值对应为信令来源的信息，0x0D～0x9F为给ISO预留的字段，0xA0～0xFF为给专用系统预留的字段，在预留的location_type字段中，加入不同位置来源的资源的可获取时间信息。

优选地，增加的定义字段available_begin和available_end，具体为：

available_begin：媒体资源的最早可获取时间；如果字段全部置0，表明此资源最早可获取时间未知；如果字段全部置1，表明此资源最早可获取时间早于当前时间；

available_end：媒体资源的最晚可获取时间；如果字段全部置0，表明此资源最晚的可获取时间未知；如果字段全部置1，表明此资源在准备好之后就一直可被获取。

其中available_begin和available_end的用法如下：

(1)如果某资源可在一个时间段内可被获取，新添加属性分别赋值为：

available_begin赋值为起始时间“UTC1”，available_end赋值为结束时间“UTC2”

(2)如果某资源在某时刻开始就一直可被获取，新添加的属性分别赋值为：

available_begin赋值为起始时间“UTC1”，available_end字段全部置1；

(3)如果某资源在任何时间内都可被获取，新添加的属性分别赋值为：

available_begin字段全部置1，available_end字段全部置1；

(4)如果某资源可获取的情况尚未知，新添加的属性分别赋值为：

available_begin字段全部置0，available_end字段全部置0。

与现有技术相比，采用本发明的技术方案：针对已有的MMT中的信令，通过在信令中加入新的属性，解决了在异构媒体网络传输中因网络延时较大而导致的媒体内容无法按时呈现或无法同步呈现的问题。

附图说明

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

图1是异构媒体网络的资源请求模型示意图；

图2是计算客户端发送请求的动态时间窗口的流程图；

图3是计算服务端发送信令的时间的流程图。

具体实施方式

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

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

本发明具体实施中包括以下三部分内容：

一.在MMT_general_location_info()描述符中添加资源的Available_Time信息

为了解决问题资源按时呈现及同步问题，首先在原有的信令或其他地方给每部分内容都加入新属性:available begin和available end，用以说明在当前网络中待传送的该内容在内容服务商处准备好并可以开始传输的时间，以及结束访问时间。

在中国专利申请CN201510064427.2中，已分别给出了在MPT、CI和MPU中添加Available_Time的方法，下面增加在MPT的MMT_general_location_info()描述符中添加可获取时间的方法及实例：

MPT中的MMT_general_location_info()描述符提供了媒体资源和相关信令的来源信息，其中location_type为0x00～0x06和0x0C的取值对应的为asset资源的位置信息，0x07～0x0B的取值对应为信令来源的信息，0x0D～0x9F为给ISO预留的字段，0xA0～0xFF为给专用系统预留的字段。为了考虑与以前系统的兼容性，选择在预留的location_type取值中，使用0xA0～0xA7这八个预留的取值，在每种location_type对应的字段中，所描述的位置信息的字段定义和0x00～0x06、0x0C一致，并且在每个描述位置信息字段的最后添加available_begin和available_end属性。

增加的定义字段available_begin和available_end如下：

MMT_general_location_info Syntax

available_begin–媒体资源的最早可获取时间。如果字段全部置0，表明此资源最早可获取时间未知；如果字段全部置1，表明此资源最早可获取时间早于当前时间；

available_end–媒体资源的最晚可获取时间。如果字段全部置0，表明此资源最晚的可获取时间未知；如果字段全部置1，表明此资源在准备好之后就一直可被获取；

其中available_begin和available_end的用法如下：

即：

(1)如果某资源可在一个时间段内可被获取，新添加属性分别赋值为：

available_begin赋值为起始时间“UTC1”，available_end赋值为结束时间“UTC2”；

(2)如果某资源在某时刻开始就一直可被获取，新添加的属性分别赋值为：

available_begin赋值为起始时间“UTC1”，available_end字段全部置1；

(3)如果某资源在任何时间内都可被获取，新添加的属性分别赋值为：

available_begin字段全部置1,available_end字段全部置1；

(4)如果某资源可获取的情况尚未知，新添加的属性分别赋值为：

available_begin字段全部置0，available_end字段全部置0。

对应于location_type此处使用0xA0～0xFF里的预留字段，也可使用0x0D～0x9F里的预留字段，新定义的location_type分别在0x00～0x06，0x0C这几种location_type的基础上增加了可获取时间的信息。

新添加的location_type说明如下：

Value of location_type

二.不同类型的服务端系统下客户终端时间请求窗口的计算方法

在专利CN201510064427.2中给出了客户终端解析信令得到媒体资源的Available_Time后，动态请求该资源的时间窗口：

(Earliest_Request_Time,Latest_Request_Time) (1)

请求最早时间Earliest_Request_Time：

Earliest_Request_Time＝Available_Time-Df (2)

请求最晚时间Latest_Request_Time：

Latest_Request_Time＝begin-Df-Dt-Data_Transfer_Time (3)

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

Earliest_Request_Time<Actual_Request_Time<Latest_Request_Time (4)

其中Df为当前媒体网络的上行延时，Dt为当前媒体网络的下行延时，Data_Transfer_Time为该服务端发送该媒体资源所需要的时间。

在实际应用中，一般有两种类型的服务端server，在收到资源请求时，A类型的服务端如果资源还未准备好，就直接返回错误信息，如HTTP server；B类型的服务端如果资源还未准备好，先不返回消息，等待资源准备就绪后就发送该资源，如MMT server。

专利CN201510064427.2中请求时间窗口的计算是针对A类型的服务端的。

现给出B类型服务端情况下的客户终端Available_Time的计算方法如下：

B类型服务端可以先接受请求消息，等待资源准备就绪后发送，因此客户终端只要解析信令得知某资源存在时即可发送请求资源的消息，因此对于B类型服务端的客户终端：

Earliest_Request_Time＝客户终端解析信令得知资源存在的时刻 (5)

Latest_Request_Time＝Begin–Data_Transfer_Time–Dt–Df (6)

三.服务端发送通知Available_Time信令的时间窗口计算方法

在某些媒体传输网络下，假定服务端获知某资源的Avaliable_Time的时刻为T0，此T0时刻可能较晚，导致发送端发出信令后，客户终端接收到相关信令的时间较晚，因此即使客户终端虽然计算出了正确的请求时间窗口，但当前时刻已经晚于Latest_Request_Time，因此请求资源仍然会失败。

在这种情况下，给定如下服务端确定发送信令时间的机制：

在服务端，通过同样的方法计算出客户终端动态请求资源的时间窗口，然后首先作如下判断：

T0+Dt<Latest_Request_Time (7)

若(7)式不成立，表明Receiver最早只能在Latest_Request_Time之后获取信令中的Available_Time属性，因此不能及时请求资源，故在这种情况下不发送相关信令；若(7)式成立，表明Receiver可以在Latest_Request_Time之前获取信令中的Available_Time属性，因此继续按如下方法获取发送信令时间的区间。

计算通知的最晚时间Latest_Notify_Time:

Latest_Notify_Time＝Latest_Request_Time-Dt (8)

则实际的发送信令的时间Actual_Notify_Time在如下区间：

T0<Actual_Notify_Time<Latest_Notify_Time (9)

其中Dt为当前网络的下行延时。

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