基于约束的自适应QoE算法设计 ①

郑小兰

(福州理工学院，福建 福州 350506)

0 引 言

雾计算技术作为云计算技术的延伸主要部署在靠近用户侧。为提升雾架构的QoE，通常将载荷的计算移至本地实施。然而这样却付出了开销的代价。为此业界对此展开了相关研究。文献[1]提出了基于最小筛选的均衡机制(MB)。主张通过统计整个雾系统所有服务器节点的用户提请连接数，进而锁定连接规模最小的那个服务器节点来应对雾用户发起的任务请求。基于MB算法思路，文献[2]设计了基于权重最小化的均衡机制(WMB)。该机制考虑到了雾系统中服务器设备负载能力多变的客观情况而引入了权重参量。然而每一次雾用户提请任务的持续时间和任务所需消耗开销资源存在变数。对于每一个服务器设备而言，即便其和雾用户之间的响应连接与权重参量呈一定的比例关系，却依旧存在响应连接规模和负载能力不匹配的情形。故提出基于约束的自适应QoE算法设计。旨在以缩短雾用户等待计算响应时长为约束探讨服务器节点与任务请求的优化适配机制。

1 方案分析

自适应QoE算法目标是最小化响应终端用户任务请求的时延代价[3]。此处将算法部署的体系依次分为三层，分别是云数据中心层、雾节点层、终端用户层。在雾终端用户向距离其最接近的雾节点发起任务请求后，雾系统开始对雾节点展开计算资源评估。若评估结果显示无法受理任务请求则将该任务请求转发给与此雾节点相邻的其他雾层服务器，如此循环评估直至遍历到合适的雾服务器节点。若算得该雾节点具有足够的开销则可用于响应任务请求。用于响应任务请求的雾服务器将最终计算结果送至雾层中最接近于雾用户的那个雾服务器，进而将雾计算数值响应给发起任务请求的雾用户。要是雾层无法遍历到合适的雾节点，此任务请求将被向上提交到云数据中心层。经云层服务器节点计算处理后将结果下发至与该云节点最为接近的雾层中的雾服务器，然后再响应给雾终端用户。

2 算法设计和部署

评估一个服务器节点能否有足够的开销用于自适应地应对雾用户提请的任务计算请求，需综合分析下列几种情形。情形A：当CAll/σAll小于C(Ni)/σ(Ni)且RAll/σAll小于R(Ni)/σ(Ni)时，说明当前节点属于重载情形；情形B：当CAll/σAll大于C(Ni)/σ(Ni)且RAll/σAll大于R(Ni)/σ(Ni)时，说明当前节点属于轻载情形；情形C：当CAll/σAll大于C(Ni)/σ(Ni)且RAll/σAll小于R(Ni)/σ(Ni)，说明此时当前节点的连接规模虽小然而载荷度却依旧很大；情形D：当CAll/σAll小于C(Ni)/σ(Ni)且RAll/σAll大于R(Ni)/σ(Ni)，说明此时当前节点的连接规模虽大载荷度却反而很小。出现后面两种情形主要缘于SDN数据流呈现突发[5]特征，用户提请的任务请求规模、任务持续时长、服务器瞬时开销资源均是动态随机所致。

部署自适应QoE算法时可定义一个数组用于容纳情形B和情形D下的节点，逐个遍历数组中的节点直至为空。然后开始重新评估服务器的参数R(Ni)、RNull(Ni)、σ(Ni)、RAll、σAll、CAll，评估后若符合情形B和情形D的条件则可以放入数组内用于应对雾用户提请的任务计算请求。

图1 三种算法下的服务器载荷占用比

图2 三种算法下的服务器闲置负载占比

3 算法实施

基于约束的自适应QoE算法以终端雾用户可接受的等候时延为前提来降低服务器转发任务请求的频率。从QoE时延角度出发，应统筹考虑三种情形下雾层服务器执行任务请求时节点进行任务转发操作的频次，并尽可能地让任务请求在雾层中就能够得到顺利的响应。基于此思想，整个算法的实施过程做如下规划：

初始化自适应QoE算法各指标参量Mi、Ci、Bi并定义一个数组后，首先通过评估R(Ni)、RNull(Ni)进而求出σ(Ni)。其次，分别计算出σAll、CAll、RAll然后分析RAll/σAll和R(Ni)/σ(Ni)关系。如果前者小于后者，则返回至第一步骤；反之将Ni存放到数组内。随后判断数组内的节点是否为空。若非空数组则返回执行步骤一；若为空数组再分析是否还有终端用户发起任务请求。如果仍有则重返步骤一，如果没有待执行的任务请求则终止计算。

4 算法测试

选用Matlab作为自适应QoE算法的测试[6]环境。为云层配置15GHz的计算能力，雾层中雾服务器的计算能力配置为f(GHz)=[f1,…,fm]=[1.5、1、2.5、0.7、0.6、0.9、0.8、0.5]，一次任务传输的时延设置为Dt(s)=[0.02、0.17、0.1、0.19、0.09、0.1、0.08、0.06]。并为雾服务器f1和雾终端配置0.05s的任务传输时延。

图1曲线是三种算法机制下节点受理相同用户任务请求连接规模时，节点表现出的载荷占用比。由于MB算法并未顾及终端用户提请任务计算请求的数据规模，一味地将任务转发给连接数最少的节点来受理。这势必导致服务器节点载荷占用比的变化起伏不定。WMB虽然克服了MB所忽略的关键环节但未考虑到随机突发特征环境下，终端用户提请的任务数据规模存在多变情形所引发的载荷变化情况。QoE算法则是调用那些当前载荷度低于所有节点平均载荷度的节点。因此节点载荷度依然以最小的变化幅度徘徊在系统均值左右。

图2所示三条曲线描述了三种算法机制下的同一个终端用户发起任务计算请求后，服务器节点表现出的闲置负载占比变化情况。显而易见，由于只考虑用户请求连接规模忽略了不同节点性能存在差异问题，MB算法机制下的节点在载荷占比指标上很容易出现两个极端，要么很小要么很大，因此负载起伏不定。WMB算法思想是在MB基础上引入权重系数用于动态计算某些节点的优越性能。此机制下的节点载荷占比虽总体较为均衡但却付出了系统开销的代价。相比之下本文构思的QoE算法通过统筹考察节点的权重系数、连接规模、载荷度等来客观地动态地评估所有节点的载荷使用情况。QoE机制下的节点载荷占比基本徘徊在系统均值附近。

5 结 语

QoE算法的构思是从全局角度出发以时延控制为目标，为雾用户设计的一种自适应能力较强的算法方案。该方案通过引入权重参数为任务请求合理地计算出可用于响应的服务器节点。评估结果表明相对于传统研究方案，该QoE算法的部署具有良好的普适性。