边缘网络中QoS感知的应急多设备协同机制

2019-05-22 09:26邢婷魏小敏李梦宇
无线互联科技 2019年6期
关键词:边缘计算

邢婷 魏小敏 李梦宇

摘 要:随着物联网的快速发展,越来越多的设备连接到互联网中。云计算可以有效满足非实时和高计算量业务的需求,但在低延迟业务方面存在很大的问题。因此,研究人员引入边缘计算来弥补云计算的不足,并将这一理念应用于许多场景之中。文章将边缘计算应用于对延迟要求较高的应急救援场景。首先,提出了一种基于边缘的应急救援架构,该架构包括3层:云层,边缘层和设备接入层,救援任务的完成需要各层次之间的合作。设备接入层对应物理环境中的各项资源设备,包括救援人员、无线设备和救援车辆等,文章研究基于服务质量(Quality of Service, QoS)的复合业务多设备选择问题,提出了一种基于QoS的多设备协同选择机制(MDSA),并将其与传统的分配算法进行比较。仿真结果表明,MDSA在丢包和能耗等方面具有良好的性能。

关键词:边缘计算;QoS;应急救灾;多设备协同

近年来,频发的灾害给人们的生命财产造成了严重的损失,灾害已经成为影响经济发展和社会安定的不可忽视因素。人们越来越重视灾害应急管理领域的研究,尤其是应急资源调度方面。应急资源调度是应急管理的核心环节,主要研究如何在灾害发生时迅速有效地利用智能决策理论和计算机辅助工具,选择一套最佳的应急资源分配方案。该分配方案能够使得分散的所需资源尽快到达应急地点,使应急活动得以尽快进行,从而最大限度地减少突发性灾害带来的经济损失和人员伤亡[1]。

在信息技术高速发展的今天,应急资源调度也逐渐与先进的通信技术结合起来,实现更好的资源调度方案。灾难现场拥有很多实时信息,例如道路阻塞、坍塌状况、温度、湿度等,这些信息对于救灾具有指导性的意义,如果缺乏对于信息的采集,盲目进行资源分配将会浪费救援时间,缺乏救援效果。此外,灾难救援时间非常宝贵,高效资源调度需要完成快速信息获取和分析,从而得出资源调度方案。因此,建设一个实时高速的信息传输与分析系统是高效应急资源调度的保障。

尽管当下网络传输速率已经有了很大的改进,但在灾害场景中,缺乏有效站点对于通信的支持,实现灾难现场与救援中心的高带宽实时通信还是比较困难。边缘计算作为一种新兴的通信模式,通过在网络边缘搭建服务平台,将原本中心节点提供的应用程序、数据资源或计算服务分解为若干部分,并各自分散到边缘节点进行处理,这种就近提供计算服务的方式能够满足快速连接、实时分析、快速响应等方面的技术和应用需求。边缘计算的出现实现了云计算的去中心化,能够有效避免长距离传输造成的时间及带宽浪费,同时也降低了云中心的计算负荷[2]。

在本文中,我们将边缘计算应用于紧急救援。这个场景需要较短的响应时间和大量的数据来制定决策。通过这种方式可以提高紧急救援的效率。本文具体研究如下:

(1)本文提出一种协作分层体系结构。在该架构中,计算任务可由云边缘协调进行处理。低级服务决策过程可以从云中心移动到网络边缘,一些基本的数据可以在本地处理,减少通信带宽的需求。

(2)基于该分层体系结构,我们讨论了网络边缘的服务决策过程。在移动应急决策方面,我们从QoS的角度引入了一种选择机制来将服务分配给适当的物理设备来执行。在丢包率和网络能耗方面,实验数据显示该策略具有较好的性能。

1 基于QoS的多设备协同机制

1.1 体系结构

在紧急场景下,急救中心需要大量的实时信息才能做出快速准确的决策和协调操作。然而,道路视频监控和交通信息的传输需要高带宽,远距离传输会减慢决策速度。因此,我们提出了一种基于边缘计算的体系结构来提高系统性能。该架构包括3层:云层、边缘层和设备访问层。云层是紧急命令和数据中心。指挥官在此做出高层次的决定,如救援计划,为现场救援人员提供远程培训等。边缘层是网络的边缘,通过在基础站点上部署边缘计算服务器,可以在边缘层中处理一些工作,例如视频管理和分析。通过这种方式,我们可以更好地利用通信带宽。此外,边缘层可以通过利用具有边缘计算功能的网关来支持一些低级决策。设备访问层主要指灾难现场,如道路视频监控,交通信息和移动紧急情况。灾难救援是一个复杂的过程,并不局限于这些部分。收集数据和执行服务是设备访问层的主要责任。移动突发事件是应急指挥的重要执行者。实际上,它可以看作是一个移动应急平台,包括救援人员,无线通信设备,传感器等。如何分配资源来执行服务也会影响救援工作的进度。在下面的部分中,我们描述了这个问题并提出了方法。

1.2 基于QoS的多设备选择算法

1.2.1 问题模型

本文提出的移动应急模型可以看作是移动Ad-hoc网络(MANET)的典型应用场景。具有智能设备的传感器、无线通信设备,和救援人员可以相互通信,不依赖于先前存在的基础设施,例如有线网络中的路由器或受管(基础设施)无线网络中的接入点[3]。双层服务映射模型如图1所示。

图1 双层服务映射模型

在救援过程中,当救援点请求一个服务,该服务可能由多个子服务组成并且需要多个物理设备来执行[4]。例如,用户请求监视环境的服务,它可以包括:监视位置表示为S1,监视温度表示为S2,烟雾监视表示为S3,环境质量监测表示为S4。

我们的目标是找到一套最佳的物理设备,这些设备可以协同支持服务并保持用户体验的质量。图1给出了一个双层模型来描述将服务分配给物理设备的场景。图示的子服务需要按顺序执行。例如,子服务S1需要S3和S2的结果。因此我们可以看到子服务之间的交互。设备层包括一些可调度资源,例如智能終端和传感器。它们之间存在网络链接,其中一些可以在服务层中执行子服务。此外,不止一个设备可以执行子服务,该图给出将子服务分配给设备的一种可能方式[5-6]。在接下来的部分中,我们将详细介绍两层模型,并尝试解决如何将服务层中的GSM(S,Q,L,B)映射到设备层中的GDM(D,R,E)的问题。

(1)SM服务层模型。服务层模型将网络中的服务定义为GSM(S,Q,L,B),由一组子服务,S={sv|v=1,…,V},子服务所需的一组资源Q={qv|v=0,1…,V}和子服务间的一组交互L={lu|u=0,1…,U}组成。sv是服务中的第v个子服务。V是服务总数。qv={qv,w|w=1,…,W}给出子服务需要多少资源,并由相应的权重值表示。qv,w在[0,1]范围内。W是资源类型的总数。lu是服务中的交互。U是子服务间的交互总数。B={bu|u=0,1…,U}是L={lu|u=0,1…,U}所需的带宽。

(2)DM设备层模型。DM(设备层模型)给出了设备层的结构,它被定义为无向图GDM(D,R,E),其中:

D={dk|k=0,1…,K}表示一组设备,R={rk|k=0,1…,K}表示每个设备的一组能力,E={ej|j=1,…,J}表示设备之间的一组通信链路。

在本文中,我们从QoS的角度选择最佳设备集。我们在(1)中定义了一个效益函数。Pi是可以执行第i个服务的一组设备。ρi,m是第i个服务的第m个质量指标。αi,m是第i个服务的第m个质量指标的权重。

F(i,Pi)=∑i∑mαi,m*ρi,m (1)

至于质量指标,不同的服务有不同的要求。本文主要针对两个方面,即距离和响应时间。它们是衡量服务质量的一般指标,我们在第4节中描述了细节。

同时,在公式(1)的基础上,建立了如(2)所示的数学模型。事实上,为了正确地分配服务,需要从GDM(D,R,E)中找到满足GSM(S,Q,L,B)和最佳质量需求的同构子图。

其中:δi,m是第i个服务的第m个质量指标的最低要求。xp,v,k是一个0-1变量。 选择dk执行服务时设置为1,否则设置为0。yp,j也是一个0-1变量。当选择链接ej来执行服务时,它被设置为1,否则它被设置为0。

根据该模型,它是一个复杂的子图同态问题,我们在下面的部分介绍解决方案。

1.2.2 基于QoS的多设备选择方案MDSA

针对上一部分提出的问题,我们给出了一个具有广度优先搜索(Breadth First Search,BFS)和修剪机制知识的解决方案。该过程如图2所示。

该过程由两部分组成。第一部分是服务初始化。首先根据场景得到逻辑图GSM(S,Q,L,B)。以图1为例,逻辑图表示在(3)中。

根据逻辑图GSM(S,Q,L,B),我们得到以图GSM的邻接矩阵导出的以Su为根的BFS树。并且还生成执行服务的设备集NetTop={CDS,Gbit}的初始网络拓扑。CDS是定义为CDS=(dk1,dk2,…dki)。dki是执行第i个子服务的设备,相应的Gbit表示找到执行子服务的设备。例如,考虑式(3),我们得到一个执行序列(S1,S2,S3,S4),其中BFS树由S1生根。如果CDS=(dk1,dk2,dk3,NULL)

和Gbit=1 110,则表示有3个设备dk1,dk2,dk3可以执行服务S1,S2,S3,尚未找到执行服务S4的设备。因此,在开始时,NetTop=被设置为初始值,如CDS=(NULL,…,NULL)和Gbit=0…0。

设备选择过程如下。由生存时间控制的REQ_SEL数据包将在设备之间广播。作为第一接收器并且可以在执行序列中执行第一服务的设备被表示为服务开始节点,并且对REQ_SEL分组进行广播[7-10]。在k-hop内,接收REQ_SEL数据包的设备将检查是否有可用于执行特定服务的资源,如果它可以执行服务而不是终节点(执行最后一个服务的设备),将该设备的上下文放入REQ_SEL并广播REQ_SEL,直到找到服务端节点。如果设备是终节点,则形成ACK_SEL包并发送给用户构建初始UCS为(4),ρt,m表示为第t个解决方案中的第m个服务质量指标CDSt。最后,选择具有收益函数的最优集合,并使用REQ_ROU数据包,ACK_ROU数据包完成设备分配。

此外,在接收到ACK_SEL消息后,用户将构造UCS并根据(2)选择最佳的CDSi。由于多设备选择过程的问题模型是多目标函数,我们将计算过程分解为两个步骤,以简化计算的复杂度。首先,我们从UCS中选择ZCDS作为根据(2)的初步设备集。计算Z的公式如(5)所示。

这里,M是UCS的总数。λ设定为0.5。

之后,根据(2)中的第二个目标函数,我们从上述Z CDS中选择最佳协同Z作为实现服务的初始设备集。这里以图3为例。

步骤1:救援点请求组合服务,并且d1被表示为服务开始节点S1并广播REQ_SEL。

步骤2:收到REQ_SEL后,d2,d3,d10檢查是否满足S2的要求。d3和d10只转发REQ_SEL。d2可以将其信息添加到REQ_SEL中,然后广播REQ_SEL,生成UCS=((d1,d2,NULL,NULL,1 100),ρ1,1,ρ1,1,…,ρ1,m)。

步骤3:d7从d5接收REQ_SEL,d8从d6接收REQ_SEL,它们是服务终节点,因此发送REQ_ACK。最后,我们选择一个最优集合CDS并建立路由。

2 实验评估

2.1 实验环境

在模拟中,我们将从两个评估指标验证所提出机制的性能:服务距离,服务响应时间。我们给出这些质量指标的定义,定义服务距离是设备和用户间的平均距离。

2.1.1 服务距离

2.1.2 服务响应时间

其中Ti是服务i的响应时间,Tmax是用户可以接受的最长等待时间。

用OPNET建立一个带无线通信设备和MANET的仿真环境,然后通过Matlab等统计分析工具分析实验结果。基于OPNET,构建了一个面积为100×150(Ti)的网络,包括60个异构设备。模拟过程中参数的详细信息如表1所示。为了观察MDSA与多用户的性能,模拟了具有1、4和8个用户的场景。此外,模拟各种最大速度(1、5、10、15和20 m/s)以显示MDSA适用于具有高移动性设备的环境。

2.2 結果分析

考虑到应急救援场景中救援点的网络体验和质量,MDSA的性能已经与基于成本的简单分配算法CDA进行了比较[5]。我们通过两个测量分析实验结果,包括能耗和丢包率。

(1)能耗:由于网络中终端设备的能量有限,高性能的多终端选择算法将有助于节省能源。如图4所示,与CDA相比,MDSA可以在情况4下节省0~22%的能耗。并且能量消耗得到显著改善,特别是当终端的移动速度增加或多个用户同时请求服务时。

(2)丢包率:图5给出了1个用户,4个用户和8个用户在不同场景下各种移动速度下的平均丢包率。在4个用户的情况下,结果表明随着终端移动速度的增加,MDSA的丢包率明显低于其他方法。在1个用户和8个用户的情况下,结果表明MDSA的性能比CDA好2%~16%。

3 结语

高效的应急救援在灾难中起着至关重要的作用。当前的应急通信系统面临多种挑战,例如带宽不足导致应急响应缓慢。我们引入了一种基于边缘计算的应急系统架构,可以将一些过程从云中心移动到网络边缘。作为事故现场的重要部分,移动应急决定了救援的效率。如何构建服务并为设备分配服务是值得我们关注的问题。在多设备协同过程中,服务质量将受到物理设备能力或网络拓扑动态的影响。为了向用户提供高质量的服务,保持服务的连续性和稳定性,本文提出了一种基于QoS的多设备协同选择机制,仿真结果表明,与CDA相比,我们的机制在能耗和丢包率方面具有较好的性能。

[参考文献]

[1]柴秀荣.灾害应急救助物资调度系统研究[D].合肥:中国科学技术大学,2009.

[2]张婷.灾害应急管理中的应急资源调度问题研究[D].合肥:合肥工业大学,2015.

[3]SUN Q,KONG F,ZHANG L,et al.Study on emergency distribution route decision making[C].Changchun:2011 International Conference on Mechatronic Science,Electric Engineering and Computer(MEC)2011.

[4]ZHAO T C,ZHOU S,GUO X Y.A cooperative scheduling scheme of Icloud and Internet cloud for delay-aware mobile cloud computing[C].San Diego:Proceeding IEEE Globecom Workshops,2015.

[5]HAUBENWALLER A,VANDIKAS K.Computations on the edge in the Internet of Things[J].Procedia Computer Science,2015(52):29-34.

[6]FLORES H,HUI P,TARKOMA S,et al.Mobile code offloading: from concept to practice and beyond[J].IEEE Communications Magazine,2015(3):80-88.

[7]CHEN X,JIAO L,LI W,et al.Efficient multi-user computation offloading for mobile-edge cloud computing[J].IEEE/ACM Transactions on Networking,2015(5):2795-2808.

[8]YOU C,HUANG K,CHAE H,et al.Energy-efficient resource allocation for mobile-edge computation offloading[J].IEEE Transactions on Wireless Communications,2017(16):1397-1411.

[9]SARDELLITTI S,SCUTARI G,BARBAROSSA S.Joint optimization of radio and computational resources for multicell mobile-edge computing[J].IEEE Transactions on Signal and Information Processing over Networks,2015(2):89-103.

[10]TALEB T,DUTTA S,KSENTINI A,et al.Mobile edge computing potential in making cities smarter[J].IEEE Communications Magazine,2017(3):38-43.

猜你喜欢
边缘计算
边缘计算综述:应用、现状及挑战
浅析边缘计算与智能制造装备
边缘计算下移动智能终端隐私数据的保护方法
从“边缘计算”看未来企业办公场景