CN103412795B - 一种面向移动智能终端的协同下载任务调度方法及系统 - Google Patents

Abstract

本发明提供一种面向移动智能终端的协同下载任务调度方法，包括：1）根据协同下载的各移动智能终端的历史下载量，确定各所述移动智能终端当前的下载任务量，以使得各所述移动智能终端的当前预期任务总量趋于均衡，所述移动智能终端的当前预期任务总量是该所述移动智能终端的历史下载量与当前任务量之和；2）各所述移动智能终端根据步骤1）所确定的当前的下载任务量，通过蜂窝网链路下载相应资源，并通过本地无线网络在协同下载的所述移动智能终端之间分享所下载的资源。本发明可在支持终端动态地加入到协同团体的同时，避免各终端消耗的蜂窝网流量差异过大。

Description

一种面向移动智能终端的协同下载任务调度方法及系统

技术领域

本发明涉及移动互联网技术领域，具体地说，本发明涉及一种面向移动智能终端的协同下载任务调度方法及系统。

背景技术

随着流媒体在智能手机的应用越来越广泛，智能手机用户对于流媒体应用的需求越来越大。然而，由于当前的蜂窝网系统较为频繁的链路波动以及较高的丢包率，单个智能手机的蜂窝网下载能力将很难提供高质量的流媒体资源以及保证流媒体播放的流畅。

与此同时，随着多样化接口终端的不断发展，当前几乎所有主流的智能手机设备均具有蜂窝网络接口（例如：3G/4G网络接口）以及本地无线接口（例如：WiFi接口或蓝牙接口）。多样化接口使得智能手机同时具备了多种网络连接方式，增加了数据获取的途径。

结合上述的当前流媒体应用现状，为了尽可能地保证流媒体应用较好的服务质量，有人提出了一种智能手机的协同下载方案。在该方案中，多个基于共同兴趣，并且物理距离相邻的智能手机，协同下载并相互分享同一个流媒体文件。比如在同一地点，多个距离相近的智能手机用户想观看同一个视频。这些智能手机用户将组成一个协同下载团体，每个智能手机设备同时使用其具有的蜂窝网络接口与本地无线接口。通过蜂窝网络接口从远程的视频服务器分别下载该视频文件的不同数据块，通过本地无线接口进行数据的共享。这种智能手机协同模式将会显著地降低观看视频时中断的概率，大大地提升智能手机流媒体应用的用户体验。

然而，目前的协同下载方案还存在各种缺陷。例如：由于蜂窝网流量资费较为昂贵，为保证公平性，有的协同下载方案中智能手机需要在下载开始前加入到协同团体，并且各智能手机需要同时开始流媒体的下载，这导致该方案缺乏灵活性，实际使用中受到很大的限制。另一些协同下载方案虽然允许智能手机动态地加入协同团体，但它们容易导致各智能手机消耗的蜂窝网流量的差异巨大，所以也难以推广。

因此，当前迫切需要一种既能够允许移动智能终端动态地加入协同团体，又能避免各移动智能终端消耗的蜂窝网流量差异过大的协同下载解决方案。

发明内容

本发明的任务是提供一种能够克服上述缺陷的解决方案。

为实现上述发明目的，本发明提供了一种面向移动智能终端的协同下载任务调度方法，包括下列步骤：

1）根据协同下载的各移动智能终端的历史下载量，确定各所述移动智能终端当前的下载任务量，以使得各所述移动智能终端的当前预期任务总量趋于均衡，所述移动智能终端的当前预期任务总量是该所述移动智能终端的历史下载量与当前任务量之和；

2）各所述移动智能终端根据步骤1）所确定的当前的下载任务量，通过蜂窝网链路下载相应资源，并通过本地无线网络在协同下载的所述移动智能终端之间分享所下载的资源；

3）重复步骤1）至2）直至下载完毕。

其中，所述步骤1）还包括：根据调度模型求出使得目标函数最大且满足约束条件的解，这个解作为当前进行协同下载的所述移动智能终端当前的任务量；所述调度模型的目标函数是所有进行协同下载的所述移动智能终端的收益函数的总和，移动智能终端的所述收益函数是以该移动智能终端的当前累计下载量为自变量的函数f，且该函数f具有一阶导数单调递减、二阶导数为负的特性。

其中，所述步骤1）还包括：所述调度模型的约束条件包括：各个进行协同下载的移动智能终端当前的任务量不超过该移动智能终端当前的蜂窝网链路下载能力。

其中，由一个移动智能终端发起协同下载，发起协同下载的移动智能终端作为调度终端，所述步骤1）中，由所述调度终端根据调度模型求得每个当前进行协同下载的移动智能终端当前的任务量，并将其分配给每个当前进行协同下载的移动智能终端。

其中，所述步骤1）中，所述函数f为log函数。

其中，分成多个任务周期进行协同下载，每个任务周期均包括调度周期和下载周期，所述步骤1）包括下列子步骤：

11）进入调度周期，设定当前的总任务量区间；

12）根据调度模型求出使得目标函数最大且满足约束条件的解，将所求得的解作为每个当前进行协同下载的所述移动智能终端当前的任务量；其中，所述约束条件还包括：各个当前进行协同下载的所述移动智能终端当前的任务量的总和处于所述步骤11）所设定的当前的总任务量区间之内。

其中，所述步骤11）中，所述总任务量区间的上界与当前进行协同下载的所述移动智能终端的数目N正相关。

其中，所述步骤11）中，所述总任务量区间的上界Δx_max为B_vT×(1+ln(N))，其中N为当前进行协同下载的所述移动智能终端的数目，B_v为当前所下载的文件的比特率，T为播放所下载文件过程的一个周期的时长。

其中，所述步骤11）中，所述总任务量区间的下界Δx_min为αB_vT，其中N为当前进行协同下载的所述移动智能终端的数目，B_v为当前所下载的文件的比特率，T为播放所下载文件过程的一个周期的时长，α为大于1的调节系数。

其中，所述步骤2）中，下载结束时记录各个进行协同下载的所述移动智能终端的所完成的任务量，并更新各个进行协同下载的所述移动智能终端的历史下载量。

其中，所述调度模型采用KKT算法求解。

其中，所述步骤11）中，所有协同下载的所述移动智能终端对于当前网络状况进行测试，获取当前可用的下载链路速率信息并将其发送给调度终端。

本发明还提供了一种面向移动智能终端的协同下载任务调度系统，包括：蜂窝基站、调度装置和与蜂窝基站连接的多个下载装置；各下载装置之间通过本地无线网络互联，所述调度装置与下载装置互联；所述调度装置，用于根据协同下载的各移动智能终端的历史下载量，确定各所述移动智能终端当前的下载任务量，以使得各所述移动智能终端的当前预期任务总量趋于均衡，所述移动智能终端的当前预期任务总量是该所述移动智能终端的历史下载量与当前任务量之和；所述下载装置，用于使各所述移动智能终端根据调度装置所确定的当前的下载任务量，通过蜂窝网链路下载相应资源，并通过本地无线网络在协同下载的所述移动智能终端之间分享所下载的资源。

与现有技术相比，本发明具有下列技术效果：

1、本发明在有效提高移动智能终端的资源下载能力的同时，避免各移动智能终端消耗的蜂窝网流量差异过大。

2、本发明中，各协同的移动智能终端能够在文件协同下载的过程中动态地加入到协同团体中，不需要固定相同的加入时间，具有很强的灵活性。

3、本发明能够保证协同下载的视频播放流畅，特别适合于流媒体的协同下载和播放。

附图说明

以下，结合附图来详细说明本发明的实施例，其中：

图1示出了本发明一个实施例中所涉及的动态的流媒体协同场景；

图2示出了本发明一个实施例中确定各协同终端任务量的方法的流程图；

图3示出了本发明一个实施例中调度终端获取其他协同终端的链路信息的示意图；

图4示出了本发明一个实施例中调度终端向各普通协同终端发送相应的任务量信息，以及各普通协同终端向调度终端提交实际所完成的下载量信息的示意图；

图5示出了当整个协同过程结束之后，9个随机加入的协同终端（包括最初协同的调度终端）各自蜂窝网的数据下载量；

图6示出了整个协同过程中协同团体从蜂窝网下载数据总量随时间变化的曲线；

图7示出了整个协同过程中协同终端蜂窝网下载数据量的详细变化。

具体实施方式

根据本发明的一个实施例，针对动态的流媒体协同场景，提供了一种面向移动智能终端的协同下载任务调度方法。

图1示出了本实施例的面向移动智能终端的协同下载的一个应用场景。该场景中包括普通协同终端和调度终端。图1中A为调度终端，它在时刻t1发起协同下载，它负责信息收集、决策计算以及任务分配相关的操作，同时在协同下载的过程中它也作为协同终端使用，可以看做一个特殊的协同终端。B、C、D、E则作为分别于协同下载过程的不同时刻t₂、t₃、t₄、t₅分别加入协同团体的协同终端。在协同下载过程中所有的协同终端（包括普通协同终端以及执行协同下载任务的调度终端）均通过蜂窝网络接口（3G）连接视频服务器进行对应视频数据块的下载，然后再通过本地连接（WiFi）与协同团体中其余协同终端进行所下载视频数据的分享传输。

基于上述面向移动智能终端的协同下载任务调度系统，还提供了一种流媒体协同下载任务调度的方法，该方法包括以下步骤：

步骤1：协同下载发起时，由整个流媒体协同的发起者充当协同团体的调度终端，该调度终端请求得到本次协同下载的视频信息，具体过程包括以下几步：

步骤11：调度终端构造视频文件信息请求消息，并发送给远程视频服务器；

其中请求消息可以通过标准的报文格式来实现，其消息格式如下面表1所示：

表1

请求消息类型

视频文件ID

其中，请求消息类型用于标识该消息为请求视频文件的消息。视频文件ID用于标识视频文件，本实施例中采用视频文件的128位的哈希编码作为视频文件ID。

步骤12，视频服务器接收到调度终端请求消息，然后向该调度终端发送应答消息，消息格式如表2所示：

表2

回复消息类型

视频文件大小

视频文件数据块数目

视频文件解码率

其中回复消息类型标识该消息为回复视频文件请求的消息类型，视频文件大小表示该视频文件的尺寸大小，由于视频文件通常划分成等长的数据块，视频文件数据块数目表示该视频文件由多少个等长数据块组成，视频文件解码率表示单位时间内播放视频数据的大小。

步骤13：调度终端将服务器返回的信息提取之后，即维护该视频文件的数据块队列，包含已下载的数据块队列以及未下载的数据块队列。当相应的数据块下载完成之后，这个数据块就从未下载数据块队列转移到已下载数据块队列。

完成步骤1后，协同团体开始通过多个任务周期来下载所需的视频文件。每个任务周期均包括调度周期和下载周期。任务周期、调度周期和下载周期的时长可以固定，也可以根据需要灵活调整，这是本领域技术人员易于理解的。任务周期中，协同团体中的所有终端同步，即所有终端在同一时刻进入调度周期或下载周期。

步骤2：协同团体进入调度周期。调度周期中，调度终端根据各协同终端对当前视频的历史下载量和当前链路状态（例如当前链路下载速率），基于调度模型确定各协同终端在当前下载周期的下载任务量，其中各协同终端的历史下载量根据各协同终端在各下载周期结束时的实际统计的下载量得出。下载周期中，各协同终端根据调度终端所确定的下载任务量从蜂窝网下载相应的数据块，并在当前下载周期结束时统计本周期的实际下载数据量。

根据本发明的一个实施例，参考图2，调度周期中，确定各协同终端任务量的方法包括以下子步骤：

步骤21：每个调度周期开始时，所有协同智能终端对于当前网络状况进行测试，获取当前可用的下载链路速率信息；所有协同终端构造当前各自的链路状态消息，并发送给调度终端，其消息格式如表3所示：

表3

请求消息类型

当前链路下载速率

其中图3示出了调度终端获取其他协同终端的链路信息的示意图。

步骤22：调度终端确定当前下载周期内整个协同团体的总下载任务量区间。在一个优选实施例中，确定总下载任务量的过程具体包括下列子步骤：

步骤221：根据步骤21收集到的所有协同终端的网络状态信息确定总体任务的下界。该下界值Δx_min为该周期内整个协同团体需要下载的最少任务量，以保证视频播放的流畅。

整个团体中协同终端的数目为N，针对该视频比特率B_v，在周期T时间内的下界值Δx_min为αB_vT。其中α为大于1的调节系数，主要用于考虑到本地共享时数据传输的延迟，因此在总体最少下载任务量上做一定量的视频缓存数据，从而避免由于视频数据块的缺失造成播放的不流畅。参数α与周期长度T均可根据实际的网络情况与所下载的视频大小信息而定。较差的网络环境可设置相对于较大的α值，而视频文件较大的时候，可设置较大的周期长度T。

步骤222：根据步骤21收集到的所有协同终端的网络链路状态信息确定总体任务的上界。该上界值Δx_max为该周期内整个协同团体需要下载的最多任务量。

整个团体中协同终端的数目为N，针对该视频比特率B_v，在周期T时间内的上界值Δx_max为B_vT×(1+ln(N))。这样可以基于协同者的数目动态地调整任务量的上界，使任务量的上界与协同者数目N正相关，这样有利于合理地利用所有协同者的蜂窝网链路资源。需要说明的是，上述确定每个周期总下载任务量上界的方法不是唯一的，在其它实施例中也可以通过其它方法，确定任务量的上界，使其与协同者数目N正相关，这是本领域技术人员容易理解的。

综合上述步骤，在第i个调度周期，可以根据相应的实际网络链路状态信息确定该周期内总体下载任务的区间，其中表示在i周期内，协同终端r通过蜂窝网接口连接视频服务器所完成的下载任务，总体下载任务 $\mathrm{\Δx}\left(i\right)=\underset{r=1}{\overset{N}{\mathrm{\Σ}}}{\mathrm{\Δx}}_r^i$ 的区间为： ${\mathrm{\αB}}_{v}T\≤\mathrm{\Δx}\left(i\right)=\underset{r=1}{\overset{N}{\mathrm{\Σ}}}{\mathrm{\Δx}}_r^i\≤B_{v}T\×(1+\ln \left(N\right)).$

步骤23：调度终端确定该周期内整个协同团体中所有协同者各自的下载任务量。其中，调度终端本身也作为协同者之一，承担相应的任务量。

在确定协同者各自的下载任务量时，让之前贡献量大的节点后续任务相对较少，从而确保整个协同过程中所有协同者的公平性，防止各个协同者完成的视频数据下载任务差异过大。根据本发明的一个实施例，其包括下列子步骤：

步骤231：调度终端收集每个协同终端在过去的所有周期内所完成的累计下载任务量，该记录以及步骤21收集到的所有协同终端的网络链路状态信息作为调度模型的输入参数，用于在下个调度周期计算各协同终端的在下一个周期的下载任务量。

步骤232：根据步骤231中的输入参数，确定调度模型的约束条件，具体如下约束条件（其中S为整个协同过程中总体调度周期，R为当前周期中总体协同终端，B_l为协同终端所对应的蜂窝链路下载能力）：

当前周期的总任务量不大于预设的最大任务量，即：

$\underset{r\∈R}{\mathrm{\Σ}}{\mathrm{\Δx}}_r^i\≤{\mathrm{\Δx}}_{\max },\∀i\∈S---\left(1\right)$

当前周期的总任务量不小于预设的最小任务量，即：

$\underset{r\∈R}{\mathrm{\Σ}}{\mathrm{\Δx}}_r^i\≥{\mathrm{\Δx}}_{\min },\∀i\∈S---\left(2\right)$

当前周期的任务量不超过当前蜂窝链路的最大下载能力，即：

${\mathrm{\Δx}}_r^i\≤B_l,r:l\∈r,\∀r\∈R,\∀l\∈L,\∀i\∈S---\left(3\right)$

当前周期的任务量不小于0，即：

${\mathrm{\Δx}}_r^i\≥0,\∀r\∈R.---\left(4\right)$

步骤233：定义协同终端所下载的视频数据量为整个协同团体的收益，基于步骤232中的约束条件建立一个最大化收益的优化模型，其目标函数即为每个协同终端所贡献的收益，表示为收益函数为第r个协同者在第i个周期后的历史下载量，即从首个周期到第i个周期的下载量之和。目标函数（优化函数）的形式如下：

$\max \underset{r\∈R}{\mathrm{\Σ}}{U}_r\left(x_r^i\right)=\max \underset{r\∈R}{\mathrm{\Σ}}{U}_r(x_r^{i-1}+{\mathrm{\Δx}}_r^i)---\left(5\right)$

步骤234，由于考虑到公平性原则，需要保证各个协同终端在整个协同过程中所通过蜂窝网络所下载的视频数据差异尽可能小。此时定义的目标函数需要具备一阶导数单调递减、二阶导数为负的特性，从而保证在整个协同过程中，后续加入的协同终端将会分担之前加入协同终端的下载任务。因此采用log函数来表示目标函数，故其具体的调度优化模型的形式如下：

$\max \underset{r\∈R}{\mathrm{\Σ}}\log \left(x_r^i\right)=\max \underset{r\∈R}{\mathrm{\Σ}}\log (x_r^{i-1}+{\mathrm{\Δx}}_r^i)---\left(6\right)$

基于以下的约束条件：

当前周期的总任务量不超过预设的最大任务量，即：

$g_1\left(x\right)=\underset{r\∈R}{\mathrm{\Σ}}{x}_r^i-(\underset{r\∈R}{\mathrm{\Σ}}{x}_r^{i-1}+{\mathrm{\Δx}}_{\max })\≤0---\left(7\right)$

当前周期的总任务量不小于预设的最小任务量，即：

$g_2\left(x\right)=(\underset{r\∈R}{\mathrm{\Σ}}{x}_r^{i-1}+{\mathrm{\Δx}}_{\min })-\underset{r\∈R}{\mathrm{\Σ}}{x}_r^i\≤0---\left(8\right)$

当前周期的任务量不超过当前蜂窝链路的最大下载能力，即：

$g_3\left(x\right)=x_r^i-x_r^{i-1}-B_l\≤0---\left(9\right)$

当前周期的任务量不小于0，即：

$g_4\left(x\right)=x_r^{i-1}-x_r^i\≤0---\left(10\right)$

由于目标函数为严格的凸函数，其约束条件的函数g均为严格的凹函数，因此必然存在一个使得目标函数最大化且满足所有的约束条件的最优解x^*。定义λ_i作为基于约束条件的拉格朗日算子，具体形式如下：

$\frac{\∂f}{{\∂x}_j}\left(x^{*}\right)-\underset{j}{\mathrm{\Σ}}{\mathrm{\λ}}_j\frac{{\∂g}_j}{{\∂x}_k}\left(x^{*}\right)=0,\∀k---\left(11\right)$

${\mathrm{\λ}}_i{g}_i\left(x^{*}\right)=0,\∀k---\left(12\right)$

步骤235：对步骤234中凸优化的调度模型进行相应的形式变换，变换之后其对偶形式如下：

$L(x,\mathrm{\λ})=\max \underset{r\∈R}{\mathrm{\Σ}}\log \left(x_r^i\right)-{\mathrm{\λ}}_0(\underset{r\∈R}{\mathrm{\Σ}}{x}_r^i-(\underset{r\∈R}{\mathrm{\Σ}}{x}_r^{i-1}+{\mathrm{\Δx}}_{\max }))-\underset{r\∈R}{\mathrm{\Σ}}{\mathrm{\λ}}_r(x_r^i-(B_l+x_r^{i-1}))---\left(13\right)$

再将其拆分成为两个独立的子问题，其具体形式如下：

$\max \underset{r\∈R}{\mathrm{\Σ}}\log \left(x_r^i\right)-{\mathrm{\λ}}_0\left(\underset{r\∈R}{\mathrm{\Σ}}{x}_r^i\right)-\underset{r\∈R}{\mathrm{\Σ}}{\mathrm{\λ}}_r{x}_r^i---\left(14\right)$

$\max \left({\mathrm{\λ}}_0(({\mathrm{\Δx}}_{\max }+\underset{r\∈R}{\mathrm{\Σ}}{x}_r^{i-1})+\underset{r\∈R}{\mathrm{\Σ}}{\mathrm{\λ}}_r(B_l+x_r^{i-1})\right)---\left(15\right)$

对于以上(14)，(15)子问题均可运用较为常规的KKT（全称为Karush–Kuhn–Tucker）算法进行求解，KKT算法是解决凸优化的典型算法之一。

步骤24：调度终端将每个周期内各个协同终端的下载任务分配给所有协同终端。分配过程具体包括以下子步骤：

步骤241：调度终端根据步骤23中调度模型所计算的结果，将该周期内各个协同终端的详细下载任务构造成相应的任务消息，发送给协同终端。其消息格式如表4所示：

表4

请求消息类型

需要下载的视频数据块数目与编号

步骤242：协同终端收到任务分配消息之后，即回复确认消息，其消息格式如表5所示：

表5

回复消息类型

确认信息

步骤25：协同终端进行该周期内的视频数据的下载与分享。根据本发明的一个实施例，该过程包括下列子步骤：

步骤251：协同终端根据任务分配消息中所确立的自己的下载任务，通过蜂窝网络连接视频服务器，对相应的视频数据进行下载。

步骤252：当下载完成之后，每个协同终端通过WiFi，在协同团体所组成的无线广播域中进行视频下载数据的分享传输。

步骤26：下载周期结束时记录各个协同终端任务完成的数据量。该过程具体包括下列子步骤：

步骤261：协同终端将该周期内已完成的任务量发送给调度终端，其消息格式如表6所示：

表6

请求消息类型Type

该周期所完成的任务量

步骤262：调度终端收到该消息之后，提取其任务量字段并进行记录。

图4示出了调度终端向各普通协同终端发送相应的任务量信息，以及各普通协同终端向调度终端提交实际所完成的下载量信息的示意图。

步骤27：返回步骤21进入下一个调度周期，直至协同下载结束。

上述步骤21至步骤27周期性的进行。如果本周期内所有协同终端蜂窝网接口状态不变，则不需要重新建立下载任务和协同终端接口的匹配关系；如果本周期内某个协同终端蜂窝网接口变为不可用状态，将该调度周期内该协同终端未完成的视频数据下载任务重新归于视频未下载的数据块队列；如果本周期内某个协同终端蜂窝网接口重新变为可用状态，将重新对该协同终端分配下载任务。可以看出，移动智能终端（智能手机）在整个协同过程中可以不受时间限制加入到协同团体中，随即进行同一个视频文件的协同下载与分享，因此上述调度方法能够适应动态的流媒体协同场景。并且，上述实施例的调度方法中，在每个调度周期内具体的任务分配算法根据协同团体中每个协同者（包括调度终端和各协同终端）已下载的数据量、各个智能手机当前蜂窝网链路的状态，制定针对每个协同者下载任务量的决策方案，既考虑到了不同智能手机已完成任务量，又考虑到了蜂窝网下载能力的差异，在基于实际网络环境的约束条件下，尽可能地实现公平的任务分配，使得在一次协同下载（即下载和分享一个视频文件）完成之后，确保各智能手机协同者所消耗的蜂窝网流量的差异不大，从而达到一个相对公平的状态。需要强调的是，在动态的流媒体协同场景中，各智能手机往往是在不同时刻陆续加入协同团体的，上述实施例的调度方法能够很好地适应这种情形，使得协同下载完成时，不同时刻加入协同团体的智能手机使用蜂窝网的实际下载量都基本均衡，能够避免各智能手机消耗的蜂窝网流量差异过大。

另外，上述实施例的调度方法分周期调度的设计考虑到了无线网络环境中速率频繁波动的特性以及协同场景动态的特性。并且，通过设定每个周期的总任务量区间，可以有效地保证流媒体播放的流畅性。

下面给出基于上述实施例的一个实验。

实验参数设置如表7所示：

表7

参数描述	参数取值
		协同终端数目	9
周期长度	10s
		视频数据块大小	64KB
视频大小	256M
		视频比特率	256(KB/s)
WCDMA	176-224(KB/s)
		CDMA2000	176-224(KB/s)
TD-CDMA	176-224(KB/s)

实验中9个协同终端具有3类不同的蜂窝网制式（WCDMA，CDMA2000，TD-CDMA），均随机加入流媒体协同。每种制式的下载速率范围大致如上表上所示。当完成整个协同过程之后，其统计结果如下：

图5示出了当整个协同过程结束之后，9个随机加入的协同终端（包括最初协同的调度终端）各自蜂窝网的数据下载量。从图中可以看出，尽管9个协同终端的蜂窝网制式不同且加入协同的时间不同，最终其蜂窝网的数据下载量几乎相同。

图6示出了整个协同过程中协同团体从蜂窝网下载数据总量随时间变化的曲线。其中实线代表的是当前蜂窝网连续下载的数据量，虚线代表的是流畅的标准（连续下载数据量等于视频的解码率，本发明中该模型已经考虑到了本地传输的延迟）。从图6可见，此时蜂窝网连续的数据下载量远远高于流畅度的基准线，并且之间的差值越来越大。则表明在整个协同过程中，视频一直处于非常流畅的状态，这将大大提升用户体验。

图7示出了整个协同过程中协同终端蜂窝网下载数据量的详细变化。从图7中可以看出，当后续的协同终端用户（第六、七、八用户）加入之后，前面的协同终端用户（第一、三、五）蜂窝网的数据下载量明显减少。这也证明了本发明中调度模型将先前加入用户的蜂窝网下载任务分担给后续加入用户，从而使得最终的整个协同过程各个协同用户蜂窝网的下载量差异最小，从而提高公平性。

需要说明的是，上述实施例所采用的调度模型并不是唯一的。对于未知量为各协同者（包括调度终端和各协同终端）本周期的任务量所组成的向量，目标函数具备一阶导数单调递减、二阶导数为负的特性的调度模型，以当前链路状态和预设的当前周期的总任务区间为约束条件，求使得目标函数最大化的解，即可得出各协同者本周期的任务量。这种调度方式可以保证在整个协同过程中，后续加入的协同终端将会分担之前加入协同终端的下载任务。根据这个任务量进行调度，即可在动态的流媒体协同场景下（协同终端可在视频下载过程中自由加入协同团体的应用场景），使得各协同者的实际下载量基本均衡，避免各协同者消耗的蜂窝网流量差异过大，从而兼顾了灵活性与公平性，有利于面向移动智能终端的协同下载的推广。

上述实施例中，调度终端本身作为一个特殊的协同终端，与其它普通协同终端一起通过蜂窝网基站下载视频文件，与此同时，调度终端还用于在调度周期分配各协同终端（包括调度终端本身，以及其它普通协同终端）在当前下载周期的任务量，直至整个视频文件下载完毕。需要说明的是，本发明的调度方法并不依赖于调度终端，该调度方法也可以在无线局域网内的服务器或其它设备上实现。例如，在一个实施例中，调度方法所涉及的动态的流媒体协同场景包括调度装置和协同终端。调度装置可以是服务器或是其它具有本地无线网络的装置。协同终端均通过蜂窝网基站接入3G网络中，并与视频服务器连接。各协同终端之间通过本地无线网络互联。上述本地无线网络包括wifi网路或蓝牙网络。在协同下载过程中，通过蜂窝网络接口从远程的视频服务器分别下载该视频文件的不同数据块，通过本地无线接口在调度终端和各普通协同终端之间进行数据的共享。调度装置和各协同终端通过单跳广播的传输方式和团体中其他终端进行数据的交换传输。

另外，上述实施例分多个任务周期来下载视频文件，本领域技术人员易于理解，本发明也可以分成多个任务段来下载视频文件。例如，每个任务段下载一定数目的视频文件数据块，每个任务段均依次执行调度步骤和下载步骤，通过多个任务段即可完成整个视频文件的下载。每个任务段中，调度装置用于分配每个协同终端的任务量，分配任务量的方法如下：调度步骤中，根据各协同终端对当前视频的历史下载量，确定各协同终端在当前任务段的下载任务量，使得各协同终端的当前预期任务总量趋于均衡，协同终端的当前预期任务总量是该协同终端的历史下载量与当前任务量之和。其中各协同终端的历史下载量根据各协同终端在下载步骤结束时的实际统计的下载量得出。协同终端用于根据调度终端所确定的下载任务量从蜂窝网下载相应的数据块，并在当前下载步骤结束时统计本周期的实际下载数据量。每个协同终端所有下载步骤的实际下载数据量累加即可获得该协同终端的历史下载量。

最后应说明的是，以上实施例仅用以描述本发明的技术方案而不是对本技术方法进行限制，本发明在应用上可以延伸为其它的修改、变化、应用和实施例，并且因此认为所有这样的修改、变化、应用、实施例都在本发明的精神和教导范围内。

Claims (11)

1.一种面向移动智能终端的协同下载任务调度方法，包括下列步骤：

1)根据协同下载的各移动智能终端的历史下载量，确定各所述移动智能终端当前的下载任务量，以使得各所述移动智能终端的当前预期任务总量趋于均衡，所述移动智能终端的当前预期任务总量是该所述移动智能终端的历史下载量与当前任务量之和；其中，根据调度模型求出使得目标函数最大且满足约束条件的解，这个解作为当前进行协同下载的所述移动智能终端当前的任务量；所述调度模型的目标函数是所有进行协同下载的所述移动智能终端的收益函数的总和，移动智能终端的所述收益函数是以该移动智能终端的当前累计下载量为自变量的函数f，且该函数f具有一阶导数单调递减、二阶导数为负的特性；所述调度模型的约束条件包括：各个进行协同下载的移动智能终端当前的任务量不超过该移动智能终端当前的蜂窝网链路下载能力；

2)各所述移动智能终端根据步骤1)所确定的当前的下载任务量，通过蜂窝网链路下载相应资源，并通过本地无线网络在协同下载的所述移动智能终端之间分享所下载的资源。

2.根据权利要求1所述的面向移动智能终端的协同下载任务调度方法，其特征在于，由一个移动智能终端发起协同下载，发起协同下载的移动智能终端作为调度终端，所述步骤1)中，由所述调度终端根据调度模型求得每个当前进行协同下载的移动智能终端当前的任务量，并将其分配给每个当前进行协同下载的移动智能终端。

3.根据权利要求1所述的面向移动智能终端的协同下载任务调度方法，其特征在于，所述步骤1)中，所述函数f为log函数。

4.根据权利要求1所述的面向移动智能终端的协同下载任务调度方法，其特征在于，分成多个任务周期进行协同下载，每个任务周期均包括调度周期和下载周期，所述步骤1)包括下列子步骤：

11)进入调度周期，设定当前的总任务量区间；

12)根据调度模型求出使得目标函数最大且满足约束条件的解，将所求得的解作为每个当前进行协同下载的所述移动智能终端当前的任务量；其中，所述约束条件还包括：各个当前进行协同下载的所述移动智能终端当前的任务量的总和处于所述步骤11)所设定的当前的总任务量区间之内。

5.根据权利要求4所述的面向移动智能终端的协同下载任务调度方法，其特征在于，所述步骤11)中，所述总任务量区间的上界与当前进行协同下载的所述移动智能终端的数目N正相关。

6.根据权利要求5所述的面向移动智能终端的协同下载任务调度方法，其特征在于，所述步骤11)中，所述总任务量区间的上界Δx_max为B_vT×(1+ln(N))，其中N为当前进行协同下载的所述移动智能终端的数目，B_v为当前所下载的文件的比特率，T为播放所下载文件过程的一个周期的时长。

7.根据权利要求5所述的面向移动智能终端的协同下载任务调度方法，其特征在于，所述步骤11)中，所述总任务量区间的下界Δx_min为αB_vT，其中N为当前进行协同下载的所述移动智能终端的数目，B_v为当前所下载的文件的比特率，T为播放所下载文件过程的一个周期的时长，α为大于1的调节系数。

8.根据权利要求7所述的面向移动智能终端的协同下载任务调度方法，其特征在于，所述步骤2)中，下载结束时记录各个进行协同下载的所述移动智能终端的所完成的任务量，并更新各个进行协同下载的所述移动智能终端的历史下载量。

9.根据权利要求8所述的面向移动智能终端的协同下载任务调度方法，其特征在于，所述调度模型采用KKT算法求解。

10.根据权利要求7所述的面向移动智能终端的协同下载任务调度方法，其特征在于，所述步骤11)中，所有协同下载的所述移动智能终端对于当前网络状况进行测试，获取当前可用的下载链路速率信息并将其发送给调度终端。

11.一种面向移动智能终端的协同下载任务调度系统，包括：蜂窝基站、调度装置和与蜂窝基站连接的多个下载装置；各下载装置之间通过本地无线网络互联，所述调度装置与下载装置互联；

所述调度装置，用于根据协同下载的各移动智能终端的历史下载量，确定各所述移动智能终端当前的下载任务量，以使得各所述移动智能终端的当前预期任务总量趋于均衡，所述移动智能终端的当前预期任务总量是该所述移动智能终端的历史下载量与当前任务量之和；其中，根据调度模型求出使得目标函数最大且满足约束条件的解，这个解作为当前进行协同下载的所述移动智能终端当前的任务量；所述调度模型的目标函数是所有进行协同下载的所述移动智能终端的收益函数的总和，移动智能终端的所述收益函数是以该移动智能终端的当前累计下载量为自变量的函数f，且该函数f具有一阶导数单调递减、二阶导数为负的特性；所述调度模型的约束条件包括：各个进行协同下载的移动智能终端当前的任务量不超过该移动智能终端当前的蜂窝网链路下载能力；

所述下载装置，用于使各所述移动智能终端根据调度装置所确定的当前的下载任务量，通过蜂窝网链路下载相应资源，并通过本地无线网络在协同下载的所述移动智能终端之间分享所下载的资源。