一种多用户场景下的移动边缘计算任务卸载方法与流程

本发明涉及一种多用户场景下的任务卸载方法，涉及移动计算系统的处理技术领域。

背景技术

移动互联网和物联网的高速发展和具有高级功能的新式移动应用程序的快速发展给移动计算系统带来了巨大的压力。然而，移动设备的有限处理能力和电池容量成为实现这种要求的障碍。移动边缘计算(mobileedgecomputing,mec)已经成为解决这个问题的有希望的技术，与使用远程公共云的传统云计算系统相比，它提供了无线接入网络内的计算能力。通过将计算密集型任务从移动设备卸载到附近的mec服务器，计算体验质量(包括延迟和设备能耗)可以大大提高。然而，mec系统的效率在很大程度上取决于所采用的计算卸载策略，需要考虑到计算任务和无线信道的特点来精心设计。

技术实现要素：

本发明要解决的技术问题：本发明的目的是提供一种多用户场景下的移动边缘计算任务卸载方法，以降低移动设备的反应时延和能耗。

本发明为解决上述技术问题采取的技术方案是：

一种多用户场景下的移动边缘计算任务卸载方法，所述多用户场景是多个移动设备和mec服务器相连，每个移动设备可选择该移动设备和mec服务器之间的多条信道中的一个进行通信，mec服务器通过主干网与中心云服务器相连；

具体过程为：

步骤一、多用户场景任务卸载模型构建

构建多用户场景下的任务卸载模型，多用户场景下的任务卸载模型包括通信模型、计算任务模型，以及计算任务负载模型；

步骤二、基于博弈论的两阶段任务卸载策略

第一段阶卸载策略是：决定卸载是在移动设备上还是在mec服务器上执行，第二段阶卸载策略是：当mec服务器资源不足时进行决定是在mec服务器上等待还是在中心云服务器上执行。

在步骤一中，多用户场景下的任务卸载模型的构建过程为：

通信模型的构建

通信模型包括移动设备、mec服务器以及中心云服务器；

移动设备与mec服务器：移动设备和mec服务器之间通过无线进行通信；假设每个基站有m条信道，那么信道的集合可以表示为μ＝{0,1,…,m-1}，

移动设备：对于第一阶段移动设备n的决策结果，用符号an来表示，其中an∈{-1}∪μ；当an＝-1时，表示此时的计算任务在移动设备的本地cpu上执行；当an∈{m}时，表示此时的计算任务通过信道an卸载到mec服务器上执行；对于第二阶段的决策结果，用符号xn来表示。其中xn∈{0,1}；当xn＝1时表示在mec服务器上执行，即使mec资源不足，那么继续在mec的队列中等待；如果xn＝0，表示任务继续卸载到中心云服务器上执行；

对于所有的移动设备，可得到一个决策结果向量a＝(a1,a2,…,an)以及x＝(x1,x2,…,xn)；根据决策结果向量可计算每条信道的上传数据率(datarate)：

其中w为信道的带宽，qn表示移动设备的发射功率，gn,s表示移动设备n和基站s之间的信道增益，表示背景噪音功率；

移动设备与mec服务器之间的下传数据率和上传数据率相同；

mec服务器与中心云服务器：mec服务器和中心云服务器通过主干网进行有线连接；其中，使用符号rac来表示mec服务器和中心云服务器之间的传输数据率，并且假设这一数据在整个系统执行过程中不变，即对于每一个需要卸载到中心云服务器上执行的任务，具有相同的数据传输率；

计算任务模型

计算任务模型使用一个三元组来表示：其中bn表示计算任务需要的数据量，所述数据包括程序代码、输入参数，如果需要卸载到mec服务器上执行，那么这部分数据需要通过移动设备的tu模块上传到服务器上；dn表示计算任务所需的计算量，用cpu的操作数来表示；rn表示计算任务的结果数据，如果使用任务卸载的话需要从mec服务器上下传到移动设备；

计算任务负载模型，包括

(1)本地计算模型

当用户n决定在本地执行计算任务tn时，涉及到的过程只有移动设备本地cpu执行计算任务，假设移动设备的计算能力是计算任务在本地执行的时间如下：

执行计算任务的能量消耗表示为：

其中cn表示移动设备本地cpu的功率；

通过计算任务的延迟和能耗，建立一个计算任务在本地cpu执行时的整体负载模型：

其中系数和分别表示移动设备n在卸载决策时计算任务延迟和能耗的权重；两个系数满足如下关系：

当较大时，表示此时移动设备n更关注于计算任务的延迟，对延迟比较敏感；而当更大时，则表示此时移动设备n的电量较低；

(2)mec服务器计算模型

当移动用户决定将计算任务卸载到mec服务器上执行时，首先移动设备需要将计算任务tn通过合适的信道上传到mec服务器上，然后mec服务器代替移动设备来执行具体的任务；计算任务需要经过三个步骤才能最终完成：任务上传、云端执行以及结果回传；

多用户的场景下在任务上传阶段，每个移动设备需要选择一条与mec服务器进行通信的信道；

在任务上传阶段，移动设备n需要额外的延迟以及能量消耗来完成任务的卸载；移动设备首先需要选择一条信道来上传计算任务的数据，可得到上传任务时的延迟如下：

其中bn表示此时移动设备需要上传的数据量，rn(a)表示移动设备n所选的信道的数据率；移动设备在上传计算任务时，tu模块需要消耗一定的能量，如下所示：

其中qn表示移动设备n的发射功率，而ln表示移动设备在发射一定数据之后额外需要消耗的能量；

当移动设备n将计算任务成功上传到mec服务器上时，就开始了计算任务执行的过程；假设mec服务器分配给移动设备n的虚拟机的计算能力是计算任务在mec服务器上的执行时间可表示为：

当mec服务器上的计算能力不能满足所有用户的计算需求时，后序的用户计算任务需要在mec服务器进行第二阶段的决策；如果第二阶段决策在mec处等待，执行时间可表示为：

其中twait表示由于mec计算资源不足而导致的排队延迟；当mec计算资源足够时，twait＝0；其中，当mec资源不足时twait的计算采用基于排队论的mec服务器等待时间进行预测

计算结果进行回传的时间可以表示为：

移动设备接收结果能耗可表示为：

其中pn为移动设备的接收功率，在mec服务器上执行的综合延迟按下式计算：

在mec服务器上执行的综合能耗可得：

(3)中心云服务器计算模型

如果第二阶段选择卸载到中心云服务器上执行，那么整体延迟可以表示为：

其中和分别表示任务从mec上传到中心云服务器、在中心云服务器上执行以及从中心云服务器上回传结果到mec的时间；

其中是中心云服务器的计算能力；

(4)服务器综合负载模型

计算任务在mec服务器或中心云服务器上执行时的整体负载如下：

式中的系数和与本地计算负载模型含义相同，而xn是第二阶段的决策结果。

基于排队论的mec服务器等待时间预测的过程为：

根据排队论中的little法则，平衡条件下，任务在mec服务器等待的平均时间为系统的平均等待队长除以任务的平均进入率，即：

其中是平均等待队长，而是任务的平均进入率；这两个参数的测量需要在mec服务器端进行；

对于在每个时间槽t内统计此时在mec处等待的任务数nt-c，随着时间的增加计算平均等待队长：

nt代表t时刻所有的任务数，c是mec服务器同时能服务的用户数，二者相减就是需要排队的任务数；

其中nt是t时刻的全部任务数，同时得到任务平均进入率：

其中n0是决策开始时系统内的任务数，而不是系统初始时的任务数。

在步骤二中，基于博弈论的两阶段任务卸载策略的过程为：

利用得到的服务器综合负载模型来解决多用户场景下的任务卸载问题，将这个问题转化为一个多用户的博弈问题，然后给出求解问题的方法；

步骤1、确定优化目标

在一个多用户场景下尽可能使通过任务卸载达到有益状态的用户数最多，这一优化目标可以通过下面的公式表示：

满足：

其中是一个指示函数，定义如下：

步骤2、构建多用户博弈模型

令a-n＝(a1,…,an-1,an+1,…,an)表示所有用户中除了用户n之外的决策结果；如果用户n得到了其他所有人的决策结果a-n，用户n就需要基于已有的信息进行卸载决策，an＝-1时在本地cpu执行，an≥0时选择一条信道进行任务卸载；

决策的依据如下：

其中zn(an,a-n)表示用户n的负载函数，定义如下：

г＝(ν,{an}n∈n,{zn}n∈n)，其中ν是用户集，an是策略集，zn是每个用户得到的最小计算负载。

г表示多用户计算任务卸载决策博弈；

给出所述博弈中的纳什均衡，具体为

定义：决策结果集在多用户计算任务卸载决策博弈中是一个纳什均衡，如果在决策结果集a^*的情况下，没有一个用户可以通过改变自己的决策结果来降低自己的计算负载；即：

多用户计算任务卸载决策博弈存在一个纳什均衡，同时可以通过有限次数的迭代达到纳什平衡状态；

而对于决定进行卸载的用户，需要进行第二阶段的决策，xn通过如下公式得到：

步骤3、基于两阶段任务卸载算法求解纳什均衡，其过程为：

步骤一：无线干扰测量

通过下式计算每个信道的接收功率：

然后基站将每个信道的接收功率发送给所有的移动设备；每个移动设备n都可以通过下面的公式计算干扰：

对于移动设备n选择的信道an(t)，所得的干扰等于信道总接收功率减去移动设备n的功率；对于其他信道，干扰就是那条信道的接收功率；

步骤二：mec等待延迟预测

mec服务器需要对平均等待时间进行预测：当满足服务需求时，等待时间twait＝0；当不满足服务需求时，就需要根据公式进行预测，并将这个数据随同步骤一中的无线干扰发送给移动设备；

步骤三：卸载决策更新

每个移动设备在阶段一中都得出了每条信道的干扰，在阶段二中得到了在mec服务器处的等待延迟，在卸载决策更新中，每个移动设备利用每条信道的干扰和等待延迟这两个数据结合如下公式计算最佳响应集δn(t)，是δn(t)中元素；

如果计算得到的δn(t)非空，说明这个移动设备还没有达到纳什均衡状态，可以通过更新决策来降低计算负载；那么这个移动设备就会选择一个决策结果来向基站发送rtu信号；基站接收到所有的rtu信号后，会随机选择一个或多个互不影响的移动设备来允许决策更新，其他没有收到ua信号的移动设备在下一个时间槽内将不会更新自己的决策；同时对于需要等待的用户，需要根据公式(2-26)进行第二阶段的决策；那么经过有限次数的迭代之后，所有的移动设备将会达到纳什均衡状态，也就是说没有一个移动设备可以通过更新自己的决策来达到降低计算负载的目的。

本发明的有益效果是：

为了应对这样的多用户使用场景下的新挑战，本发明建立一个多用户场景下个性化的任务卸载的模型，包括任务模型、通信模型以及计算负载模型。同时，为了满足过多用户的计算需求，在只有mec服务器的一层卸载场景下，添加一层中心云(centralizedcloud,cc)，以满足过多的计算需求。通过综合考虑单个用户的个性化，建立基于个性化的任务负载模型满足多用户场景下的个性化需求。模型建立之后，引入博弈论的相关知识将多用户任务卸载问题转化为一个博弈问题，通过证明这个博弈问题存在纳什均衡，获得问题的解决方案，最终通过得到纳什均衡获得问题的解，并得出多用户场景下的两阶段任务卸载策略。本发明在保证用户的服务质量以及公平性的前提下，同时兼顾用户的个性化需求。

附图说明

图1为随着迭代次数的增加，处于有益的卸载状态的用户数图；

图2为不同用户数下系统达到纳什均衡所需要的迭代次数曲线图；

图3为随着迭代次数的增加用户的负载变化图；

图4为不同方案下处于有益的任务卸载用户数对比图，在图4中上方的英文的含义由上至下依次为：两阶段任务卸载，忽略排队延迟，云上执行；

图5为tco与iwd细节对比图，在图5中上方的英文的含义由上至下依次为：两阶段任务卸载，忽略排队延迟，提升；

图6为不同方案下系统平均整体负载对比图，在图6中上方的英文的含义由上至下依次为：本地执行，忽略排队延迟，两阶段任务卸载，云上执行。

具体实施方式

具体实施方式一：如图1至6所示，本实施方式所述的一种多用户场景下的移动边缘计算任务卸载方法的具体实现过程为：

1、当移动边缘计算和基站联合部署的时候，每个mec服务器需要服务不止一个移动用户。每个移动设备需要通过无线接入网和mec服务器进行网络通信，而mec服务器又可以通过主干网络与远端的中心云服务器连接。如果当多个设备通过一条信道和mec服务器进行通信时，设备之间的相互干扰也会增大，任务卸载到mec服务器上执行反而不如本地执行。同时，部署在网络边缘的mec服务器资源有限，并不能同时满足过多数量的计算需求。

2、基于上述，给出多用户场景下的任务卸载方法的具体技术方案。

2.1多用户场景任务卸载模型构建

为了方便问题的研究，接下来构建多用户场景下的任务卸载模型，包括通信模型、计算任务模型，以及计算任务负载模型。

2.1.1通信模型

移动设备与mec服务器：移动设备和mec服务器之间通过无线进行通信。假设每个基站有m条信道，那么信道的集合可以表示为μ＝{0,1,…,m-1}，对于第一阶段移动设备n的决策结果，我们可以用符号an来表示，其中an∈{-1}∪μ。当an＝-1时，表示此时的计算任务在移动设备的本地cpu上执行；当an∈{m}时，表示此时的计算任务通过信道an卸载到mec服务器上执行。对于第二阶段的决策结果，用符号xn来表示。其中xn∈{0,1}。当xn＝1时表示在mec服务器上执行，即使mec资源不足，那么继续在mec的队列中等待；如果xn＝0，表示任务继续卸载到中心云服务器上执行。这样，对于所有的移动设备，我们可以得到一个决策结果向量a＝(a1,a2,…,an)以及x＝(x1,x2,…,xn)。有了这个决策结果向量之后，我们就可以计算每条信道的上传数据率(datarate)：

其中w为信道的带宽，qn表示移动设备的发射功率，gn,s表示移动设备n和基站s之间的信道增益，表示背景噪音功率。

根据上面的公式，我们可以看出，如果有太多的移动设备选择同一条信道与基站进行通信，相互之间的干扰会很大，导致上传数据率降低，就会增加通信的延迟。同时我们假设，移动设备与mec服务器之间的下传数据率和上传数据率相同。

mec服务器与中心云服务器：mec服务器和中心云服务器通过主干网进行有线连接。其中，我们使用符号rac来表示mec服务器和中心云服务器之间的传输数据率，并且假设这一数据在整个系统执行过程中不变，即对于每一个需要卸载到中心云服务器上执行的任务，具有相同的数据传输率。

2.1.2计算任务模型

为了便于以后问题的描述，这里构建一个计算任务模型。对于一个计算任务，我们可以使用一个三元组来表示：其中bn表示计算任务需要的数据量，这里的数据包括程序代码、输入参数等，如果需要卸载到mec服务器上执行，那么这部分数据需要通过移动设备的tu模块上传到服务器上；dn表示计算任务所需的计算量，使用cpu的操作数来表示；rn表示计算任务的结果数据，如果使用任务卸载的话需要从mec服务器上下传到移动设备。移动设备可以使用程序调用图分析技术得到计算任务的bn、dn和rn。为了满足个性化的需求，我们给出不同类型的应用，每种应用具有不同的数据。有了这些数据，我们就可以分析计算任务在本地和云上执行的延迟和能耗，从而建立多用户场景下延迟和能耗负载模型。

2.1.3个性化的计算任务负载模型

在已有的大多数卸载策略中，优化的因素要么是降低计算延迟，要么是降低电池能量消耗，或者一刀切的将延迟与能耗放在一起整体考虑而忽略了每个用户都是具有不同需求的个体。因此在这部分中，我们尝试建立一个个性化的计算任务负载模型，通过这个模型，充分尊重并满足每个用户的个性化需求。

(1)本地计算模型

当用户n决定在本地执行计算任务tn时，涉及到的过程只有移动设备本地cpu执行计算任务。假设移动设备的计算能力是(也就是说cpu每秒的操作数)，为了更加符合现实意义，这里每个移动设备的计算能力是不同的。这样，计算任务在本地执行的时间如下：

执行计算任务的能量消耗可以表示为：

其中cn表示移动设备本地cpu的功率。

有了计算任务的延迟和能耗模型，我们就可以建立一个计算任务在本地cpu执行时的整体负载模型：

其中系数和分别表示移动设备n在卸载决策时计算任务延迟和能耗的权重。两个系数满足如下关系：

当较大时，表示此时移动设备n更关注于计算任务的延迟，对延迟比较敏感；而当更大时，则表示此时移动设备n的电量较低，为了增加移动设备的使用时间更关注于计算任务的能耗。这样，移动用户可以根据自身当时的具体情况适当选择权重系数。

(2)mec服务器计算模型

当移动用户决定将计算任务卸载到mec服务器上执行时，首先移动设备需要将计算任务tn通过合适的信道上传到mec服务器上，然后mec服务器代替移动设备来执行具体的任务。

这样，计算任务需要经过三个步骤才能最终完成：任务上传、云端执行以及结果回传。多用户的场景下，在任务上传阶段，每个移动设备需要选择一条与mec服务器进行通信的信道。像大多数研究一样，这里由于计算结果比较小而忽略结果回传对整个分析过程的影响。

在任务上传阶段，移动设备n需要额外的延迟以及能量消耗来完成任务的卸载。移动设备首先需要选择一条信道来上传计算任务的数据，可以得到上传任务时的延迟如下：

其中bn表示此时移动设备需要上传的数据量，rn(a)表示移动设备n所选的信道的数据率。而移动设备在上传计算任务时，tu模块需要消耗一定的能量，如下所示：

其中qn表示移动设备n的发射功率，而ln表示移动设备在发射一定数据之后额外需要消耗的能量。这部分额外的能量消耗在所有的移动设备中是普遍存在的现象。

当移动设备n将计算任务成功上传到mec服务器上时，就开始了计算任务执行的过程。假设mec服务器分配给移动设备n的虚拟机的计算能力是这样，计算任务在mec服务器上的执行时间可以表示为：

当mec服务器上的计算能力不能满足所有用户的计算需求时，后序的用户计算任务需要在mec服务器进行第二阶段的决策。如果第二阶段决策在mec处等待，执行时间可以表示为：

其中twait表示由于mec计算资源不足而导致的排队延迟；当mec计算资源足够时，twait＝0。其中，当mec资源不足时twait的计算见2.1.4节。

而计算结果进行回传的时间可以表示为：

移动设备接收结果能耗可以表示为：

其中pn为移动设备的接收功率。这样，在mec服务器上执行的综合延迟可以这样计算：

在mec服务器上执行的综合能耗可得：

(3)中心云服务器计算模型

如果第二阶段选择卸载到中心云服务器上执行，那么整体延迟可以表示为：

其中和分别表示任务从mec上传到中心云服务器、在中心云服务器上执行以及从中心云服务器上回传结果到mec的时间。可以这样计算得到：

其中是中心云服务器的计算能力，这里认为全部相同。

(4)服务器综合负载模型

综上叙述，我们可以得到计算任务在服务器(mec服务器或中心云服务器)上执行时的整体负载：

这里系数和与本地计算负载模型含义一样，而xn就是第二阶段的决策结果。

2.1.4基于排队论的mec服务器等待时间预测

在这部分我们讨论当过多任务在mec服务器上排队等待时间的预测。根据4.2节的场景描述，我们知道mec服务器是一个单队列多服务的排队模型。根据排队论中的little法则(little’slaw)，平衡条件下，任务在mec服务器等待的平均时间为系统的平均等待队长除以任务的平均进入率，即：

其中是平均等待队长，而是任务的平均进入率。接下来就需要测量这两个参数。这两个参数的测量需要在mec服务器端进行。

对于我们可以在每个时间槽t内统计此时在mec处等待的任务数nt-c，随着时间的增加计算平均等待队长：

其中nt是t时刻的全部任务数。同时我们也可以得到任务平均进入率：

其中n0是决策开始时系统内的任务数，而不是系统初始时的任务数。

这样，我们就对任一时刻的等待时间进行了一个预测，这个预测值在第二阶段的决策中扮演着重要作用。

2.2基于博弈论的两阶段任务卸载策略

在这部分内容中我们尝试根据上面得到的负载模型来解决多用户场景下的任务卸载策略。将这个问题转化为一个多用户的博弈问题，然后给出求解问题的方法。

2.2.1有益的任务卸载

通过对上述通信模型和计算任务负载模型的考察，我们可以看出，当过多的移动设备选择同一条信道进行任务卸载的话，相互之间的干扰会变得非常严重，导致每台移动设备和基站之间的数据率降低，从而导致在上传计算任务数据时花费更多的时间，而在上传计算任务中花费过多时间又会导致移动设备更多的能耗。这种情况下移动设备更适合在本地执行任务来避免卸载任务产生的过多负载。

由于每个移动用户都是一个个体，每个个体会在多用户的场景下只会考虑自身的利益。这里的利益就是以最小的能耗和最短的延迟完成计算任务。下面定义有益的任务卸载概念：

定义1：给定一个多用户的任务卸载策略结果向量a，对于选择了卸载任务的用户n的决策结果an(an≥0)，如果用户通过卸载在mec服务器上执行计算任务的负载小于在本地执行计算任务的负载的话，那么就就称为这是有益的(即)任务卸载。

有益的任务卸载的概念在移动边缘计算的任务卸载策略中具有重要的意义。一方面，从移动用户的角度来看，一个用户不会将任务卸载到mec服务器上去执行而不能获得比本地执行更小的负载。只有通过将任务卸载到mec服务器上能够得到更小的负载，移动用户才有动机去进行卸载；另一方面，从mec服务器运营商的角度来看，如果更多的用户可以达到有益的任务卸载状态，就意味着mec服务器更多的用户，也就是意味着更高的收益。因此，我们可以通过计算负载(本地计算负载或者卸载到mec上进行计算的负载)以及根据有益的任务卸载概念来得出卸载策略。

有了有益的任务卸载这一概念，我们的一个目标就可以是在一个多用户场景下尽可能使通过任务卸载达到有益状态的用户数最多，这一模型可以通过下面的公式表示：

满足：

其中是一个指示函数，定义如下：

这时，多用户场景下任务卸载策略问题可以这样描述：多用户场景下使最多的用户通过计算任务卸载达到有益的卸载状态。然而，通过将这一问题转化为多个箱子的最大装箱问题，可以得出这一问题是np难的。下面来进行证明。

为了证明这个问题，首先引入多个箱子的最大装箱问题。给定n个物体，每个物体的重量是wi，i∈{1,…,n}，同时有m个箱子，每个箱子的容量是c，问题的目标是将物体装入箱子中，使得最多的物体能够被装在箱子中。问题可以描述如下：

满足：

我们已经知道，这个多物体的最大装箱问题是np难的。现在我们将用户的移动设备比作最大装箱问题中的物体，将信道比作最大装箱问题中的箱子，这样，物体的重量wi可以表示为wi＝qngn,s，而箱子的容量就可以表示为信道的数据率(datarate)。如果一个设备n选择了信道m，就可以解释为物体n装进了箱子m。而且如果这个设备达到了有益的任务卸载状态，那么就说明箱子m没有超过容量限制。这样，我们就把本章的问题转化为多物体的最大装箱问题。

因此，可以证明本章的问题是np难的通过传统的方式并不能得到一个完美的解。下面将这一问题转化为多用户的博弈问题。

2.2.2构建多用户博弈模型

接下来我们构建一个多用户的博弈模型。令a-n＝(a1,…,an-1,an+1,…,an)表示所有用户中除了用户n之外的决策结果。如果用户n得到了其他所有人的决策结果a-n，用户n就需要基于已有的信息进行卸载决策，要么在本地cpu执行(an＝-1)，那么选择一条信道进行任务卸载(an≥0)。决策的依据如下：

其中zn(an,a-n)表示用户n的负载函数，定义如下：

这样我们就可以构建多用户计算任务卸载决策博弈了。г＝(ν,{an}n∈n,{zn}n∈n)，其中ν是用户集，an是策略集，zn是每个用户得到的最小计算负载。接下来介绍这个博弈中的纳什均衡。

定义2：决策结果集在多用户计算任务卸载决策博弈中是一个纳什均衡，如果在决策结果集a^*的情况下，没有一个用户可以通过改变自己的决策结果来降低自己的计算负载。即：

根据已有的研究可以得出，多用户计算任务卸载决策博弈存在一个纳什均衡，同时可以通过有限次数的迭代达到纳什平衡状态。

而对于决定进行卸载的用户，需要进行第二阶段的决策。xn可以通过如下公式得到：

2.2.3基于两阶段任务卸载算法求解纳什均衡

接下来给出一个求解纳什均衡的两阶段任务卸载算法。

算法的设计相当于一个中心化的分布式任务。首先，系统中心的基站有时间同步功能，因此可以通过基站的时间来同步所有移动设备的操作。在每个时间槽内，所有的移动设备都尝试更新自己的决策结果来降低计算负载，但并不是所有的更新请求都能获得中心基站的许可，这样，在每个时间槽内，决策结果更新将有三个步骤：

步骤一：无线干扰测量

在这个阶段中，每个移动设备都会从基站那里得到所有信道的基本信息，移动设备可以通过这些信息计算信道的干扰。所有在此时选择卸载的移动设备(即an(t)≥0)会向基站发送一个标志信号，这个标志信号可以是这个移动设备所选择的信道id。基站收到所有的标志信号后，可以通过如下公式计算每个信道的接收功率：

然后基站将这些信息发送给所有的移动设备。这样，每个移动设备n都可以通过下面的公式计算干扰：

也就是说，对于移动设备n选择的信道an(t)，所得的干扰等于信道总接收功率减去移动设备n的功率；对于其他信道，干扰就是那条信道的接收功率。

步骤二：mec等待延迟预测

在这个阶段中，mec服务器需要对平均等待时间进行预测。当满足服务需求时，等待时间twait＝0；当不满足服务需求时，就需要根据公式(2-17)进行预测，并将这个数据随同步骤一中的无线干扰发送给移动设备。

步骤三：卸载决策更新

每个移动设备在阶段一中都得出了每条信道的干扰，在阶段二中得到了在mec服务器处的等待延迟，在这个阶段，每个移动设备利用上述数据再根据如下公式计算最佳响应集：

如果计算得到的δn(t)非空，说明这个移动设备还没有达到纳什均衡状态，可以通过更新决策来降低计算负载。那么这个移动设备就会选择一个决策结果来向基站发送rtu信号。基站接收到所有的rtu信号后，会随机选择一个或多个互不影响的移动设备来允许决策更新，其他没有收到ua信号的移动设备在下一个时间槽内将不会更新自己的决策。同时对于需要等待的用户，需要根据公式(2-26)进行第二阶段的决策。那么经过有限次数的迭代之后，所有的移动设备将会达到纳什均衡状态，也就是说没有一个移动设备可以通过更新自己的决策来达到降低计算负载的目的。这样，算法就解决了多用户场景下计算任务卸载决策问题。

3针对本发明效果的阐述

在这部分，根据上面的算法，通过模拟实验来进行验证。多用户的仿真场景如下：小区中心有一个mec服务器，这个服务器服务于小区的所有移动用户，并假设这个mec服务器具有有限的计算能力，只能同时服务一定数量的移动用户，如果超出，超出的用户就需要进行第二阶段的决策层。小区中需要服务的移动用户按照随机的概率分布在一定的范围内。

3.1模拟实验参数选择

对于仿真实验参数的选取，可以参考下表：

表3-1模拟实验参数选择

为了满足不同移动用户的个性化需求，这里选取了四种典型的移动计算任务，不同的任务对于延迟有不同的需求，同时不同任务的计算量以及数据量也有所不同。具体参数如下：

表3-2不同应用的参数选择

在仿真实验中，随机为每个移动用户选择一种任务类型，这样每个用户都有一个自己需要的数据量和计算量。

3.2模拟实验结果与分析

图1展示了在迭代过程中处于有益的卸载状态的用户数量：

从图1中可以看出，在迭代过程中，处于有益的卸载状态的用户数不断增加，最终达到一个稳定的状态，说明算法能够在有限次数(在这次仿真实验中是35次迭代)内达到纳什均衡状态，其中30个用户中有25个用户选择了任务卸载到mec服务器执行。

而图2展示了不同用户数的条件下系统达到纳什均衡状态所需要的迭代次数：

从图2中可以看出，随着用户数的增加，系统达到纳什均衡所需要的迭代次数也大概随着线性的趋势增加，说明本章所提出的的多用户分布式任务卸载算法具有很好的性能。

图3展示的是随着迭代次数的增加，所有用户负载的堆积折线图。从图3中可以看出，随着迭代次数的增加，用户的负载不断变化，但最终趋于稳定，系统整体达到一个平衡的状态，即处于多用户博弈的纳什均衡。同时，最上面一条线即系统整体负载变化图，负载不断降低，最终稳定。

接下来，将本发明提出的多用户两阶段任务卸载算法(two-phasecomputingoffloading,tco)与多种方案进行对比，来测试多用户任务卸载算法的性能。对比的方案如下：

(1)本地执行(localexecuted,le)：所用用户的任务均在移动设备本地执行，而不将任务卸载到服务器上；

(2)云上执行(cloudcomputing,cc)：所有用户随机选择一条信道，然后通过这条信道将自己的计算任务卸载到mec服务器上去执行；

(3)忽略排队延迟(ignorewaitingdelay,iwd)：在mec服务器计算资源有限的情况下，本方案忽略用户卸载的任务在mec排队队列中的等待延迟，不管mec服务器是否有足够的计算资源，即总是在mec上执行而不继续卸载到中心云服务器。

在模拟实验中，我们对每种方案进行多次不同的实验，在每次实验中，移动用户数量n的选取为n＝15,20,…,50，同时假设mec服务器最多能够同时对30个用户进行服务。对每个n，我们都将实验重复进行100次，然后选择平均值作为最后的结果。如图4和图5所示。

图4展示了用户数不同的条件下，不同方案中处于有益的任务卸载用户数的情况。图4中没有方案le的数据，因为当所有的用户没有进行卸载而仅在本地进行执行的情况下，有益的任务卸载概念就没有意义了。从图中可以看出，在不同的用户数下，本章提出的多用户分布式任务卸载算法总能有最多的处于有益的任务卸载状态的用户数，比全部在云上执行增加了27.4％的处于有益的任务卸载状态用户数。而方案tco和方案iwd进行对比可以发现，当n≤30时，两者处于有益的任务卸载用户数相同，而当n>30时，虽然iwd中处于有益的任务卸载状态的用户数大于cc，但仍略小于tco。这是因为两者唯一的区别在于tco会考虑mec服务器的计算限制问题，当mec服务器资源不足时将进行两阶段决策。而iwd没有考虑这一点，即使mec服务器的计算资源已经不够进一步的任务卸载，iwd也将任务进行卸载，导致更多的排队延迟。

具体来看，图5展示了当用户数多于mec所能服务的最大用户数时，tco与iwd处于有益的任务卸载状态用户数对比：

从图中可以看出，虽然tco相比iwd在mec资源不足情况下有一定的性能提升，但提升很小。这是由于，当mec将任务进一步卸载到中心云服务器上时，需要通过主干网通信，而通信速率相比移动设备和mec之间的无线通信低很多，导致从mec服务器到中心云服务器之间的通信负载过高。但是本发明所提出的两层服务器卸载的结构在深入研究中具有重要的意义。比如，当有多个mec服务器与中心云服务器连接而每个mec服务器都服务多个用户时，这种两层服务器卸载结构在用户在多个mec服务器之间移动的情况下将具有很好的解决效果。由于时间与精力问题，这部分内容没有涉及。

图6展示了用户数不同的情况下，不同方案中系统整体负载的情况。从图6中可以看出，方案le具有最大的系统整体负载，而其余方案相对于方案le都降低了系统整体的负载，说明将任务卸载到云上执行能够明显给用户带来好处。在其余各个卸载策略中，本章提出的多用户分布式任务卸载算法具有最低的系统整体负载，比方案le平均降低67.5％的系统负载，性能提升效果很明显。与方案cc对比，由于方案cc将所有的任务都卸载到云上去执行，而没有考虑到用户相互之间的影响，导致一些卸载并不能带来性能的提升。和方案iwd对比，结果和图6类似，也是由于方案iwd忽略了在mec服务器中的等待延迟。

同时，本章提出的多用户两阶段任务卸载算法在需要进行卸载的时候仅仅将用户所必须的一小部分数据进行上传，而具体的决策仍在移动设备本地进行，这样就保证了数据的私有与安全。从上面的模拟实验的结果与分析中，我们可以得出如下的几个结论：

1.任务卸载是有必要的。如果任务不进行卸载，会带来巨大的负载。通过将任务卸载到云上执行，可以极大的降低任务执行的负载；

2.卸载策略在任务卸载中具有重要意义。合适的卸载算法能够明显降低系统负载，给移动用户和网络运营商都带来好处；

3.多用户两阶段任务卸载算法通过在第二阶段决策是否继续卸载到中心云服务器兼顾了mec服务器计算资源有限的问题，能更好的适应现实使用场景；

4.同时，多用户两阶段任务卸载算法充分考虑并满足了用户个性化的需求，通过权重因子将用户的不同关注点整合成一个任务执行负载，能够很好的满足用户的个性化需求。而用户可以根据自身的情况适当选择不同的权重。