【论文阅读】HeteroEdge: Taming The Heterogeneity of Edge Computing System in Social Se

时间 2019-11-30

标签论文阅读 heteroedge taming heterogeneity edge computing system social 繁體版

原文原文链接

HeteroEdge：克服社会感知中边缘计算系统的异质性问题

ABSTRACT 摘要

社交感知是由人或周围的设备采集物理世界信息，来进行应用。边缘计算推动着计算、服务和数据由云转移到IOT边缘设备。二者的结合带来一系列问题，其中一个关键问题就是边缘设备的异质性（计算能力、运行时环境、网络接口和硬件设备），这给资源管理带来难度。举的例子包括在不一样平台上屏蔽明显的异构性，在具备不一样资源的设备上分配具备复杂要求的相互依赖的任务，以及适应边缘设备的动态和多样化的上下文。本文中，提出了一个新的资源管理框架——HeteroEdge，来解决异构性问题，经过：1）提供一个统一的接口来抽象设备信息（硬件、操做系统、CPU）和2）有效地管理异构设备上的任务分配。将HeteroEdge应用于真实世界的异构设备中，测试了两个app后，得出HeteroEdge与目前的技术相比，能够减小42%端到端延迟和至少22%能量节约。程序员

CCS CONCEPTS

• Human-centered computing → Collaborative and social computing; • Computing methodologies → Distributed computing methodologies; • Computer systems organization → Embedded and cyber-physical systems;算法

•以人为本的计算→协做和社交计算; •计算方法→分布式计算方法; •计算机系统组织→嵌入式和网络物理系统;编程

KEYWORDS 关键字

edge computing, social sensing, resource management, heterogeneity, supply chain后端

边缘计算，社交感知，资源管理，异构性，供应链安全

1 INTRODUCTION 介绍

一个一直的社交感知解决方案的弊端是数据计算和分析人物大部分都在后备服务器进行（专用服务器或云），这会致使额外带宽消耗和没必要要的延迟。边缘计算使计算、数据和服务前置到边缘处。服务器

SSEC的优点是：1）提供一个更经济并大规模的边缘计算解决方案，2）SSEC设备造成移动传感器网络，以完成对基础设施/静态传感器具备挑战性的传感任务，3）SSEC适用于延迟敏感的应用，4）SSEC减小了后端服务器过载的风险，避免了系统的单点失败。网络

SSEC也有许多须要研究的挑战，好比边缘用户的不合做、隐私和安全顾虑以及奖励机制的设计等。本文聚焦于异构性的挑战。因为边缘设备不一样的计算能力、运行环境和硬件设备，使得很难讲协做人物分配到这些设备中去。以前的研究如HTCondor和FemtoCloud也解决了异构性问题，可是这些解决方案并不能适用于SSEC由于有如下技术上的问题：多线程

Pronounced Heterogeneity 显著的异构性： SSEC的异构性比普通的分布式/云系统更加显著由于，1）设备属于我的，没法进行彻底控制和了解，2）SSEC设备的异构程度比假设执行同类任务或同构架构的分布式或云计算系统更为显著。过去为某一特定硬件和操做系统设计的应用没法直接应用在异构的系统中。所以须要资源管理来支持各类社交人物来使资源利用率达到最大化。架构

Complex Task-Resource Mapping 复杂的任务-资源映射： 第二个挑战是指将具备多样化资源需求的相互依赖的社会感知任务有效地分配给SSEC中具备复杂延迟能量权衡的异构设备的复杂性。首先，社交传感任务一般很复杂，须要异构的硬件资源（例如，某些任务须要传感器，某些任务须要GPU）。其次，边缘设备一般具备多种硬件组件配置（例如，GPU，单核CPU，多核CPU，传感器）。第三，难以在完成具备重要任务依赖性的协做社交感知任务中协调异构边缘设备。最后，各类任务分配策略可能会产生能量成本和延迟开销之间的复杂权衡（例如，将任务分配给GPU可能会产生更少的延迟，但与将任务分配给CPU相比，能耗更高）。鉴于上述独特性复杂性，咱们发现利用异构设备的现有资源管理方案（例如HTCondor、CoGTA和FemtoCloud）没法解决SSEC中复杂的任务映射问题。app

Dynamic Context 动态上下文： 第三个挑战是指边缘设备可能具备不一样的动态上下文环境。上下文环境指的是边缘设备的详细状态（例如，设备的位置，CPU/存储器利用率和电池状态），其常常随着系统运行而随时间改变。重要的是跟踪SSEC中的上下文信息以优化许多运行时决策（例如，任务分配，激励调整）。现有的边缘计算系统一般假设系统中的中央控制器具备关于全部边缘设备的上下文信息的所有知识，这在SSEC中是不实际的，缘由有两个。首先，最终用户能够最终控制其边缘设备，并决定应用程序应该看到哪一种类型的上下文。例如，若是设备的电池电量不足，选择在SSEC应用程序中共享GPU资源的用户可能会改变主意。其次，它经过实时跟踪确切的CPU使用率和其余上下文环境来引入显着的同步开销（例如，边缘设备必须不断地将其状态更新到服务器）。所以，缺少一种容许最终用户自我配置并为应用程序提供有用的动态上下文的方法。

为了解决上述挑战，提出了一个名为HeteroEdge的新资源管理框架，以克服SSEC的异质性。特别是开发了一种基于供应链的新型任务映射模型，该模型容许异构边缘设备经过优化的延迟-能量权衡来协做完成复杂且相互依赖的社会传感任务。HeteroEdge经过开发硬件和运行时抽象模块来解决SSEC设备的明显异构性和动态上下文挑战。在真实世界的SSEC测试平台上实现了HeteroEdge的系统原型，该测试平台由RaspberryPi3，Nvidia Jetson TX2，Jetson TK1板和我的计算机组成。HeteroEdge使用两个真实的社会传感应用程序进行评估：灾难损失评估和协做流量监控。将HeteroEdge与边缘计算系统中使用的最早进的资源管理方案进行了比较。结果代表，方案在延迟和能耗方面实现了显着的性能提高：使应用的端到端延迟下降了42％，边缘设备的节能下降了22％。

2 RELATED WORK 相关工做

2.1 Social Sensing and Edge Computing 社交感知和边缘计算

因为低成本移动传感器的普及和无处不在的互联网链接，社会感知受到了极大的关注。大量社会感知应用对延迟很敏感，即具备实时要求。此类应用的例子包括智能交通系统，环境感知以及灾害和紧急响应。传统的社交传感应用将全部计算任务推送到远程服务器/云，当网络带宽有限且通讯延迟很高时，这对于延迟敏感的应用来讲可能很是无效。边缘计算系统经过将计算任务卸载到边缘设备来补充传统的集中式社交传感解决方案，从而显着下降通讯成本和应用延迟。社交传感基础边缘计算（SSEC）由如下几个关键技术趋势实现：i）我的拥有的物联网设备变得愈来愈强大，其中一些甚至具备与传统边缘计算系统中的专用服务器相似的计算能力。所以，将计算直接推送到边缘设备而不是专用远程服务器或cloudlet是一种日益增加的趋势;ii）移动支付的普及为普通人提供了一种更方便的方式，经过在其物联网设备上提供备用资源来完成社会传感任务，从而得到激励。本文关注SSEC系统中的异质性挑战。

2.2 Resource Management in Edge Computing 边缘计算中的资源管理

资源管理是边缘计算系统中的一个基本问题，而且已经开发了许多解决方案来解决这个问题。大多数当前的资源管理方案采用集中式方法，采用中央决策者在系统中分配任务。这种方法在边缘计算系统中失败，由于在边缘计算系统中，设备可能会从新提供必要的信息来完成集中任务映射。已经开发了分散的任务映射方案与激励机制相结合以解决上述限制。然而，这些方案假设计算节点具备同构的任务执行接口而且在很大程度上忽略了边缘设备的异构性。

2.3 Distributed System with Heterogeneous Computing Nodes 有异构计算节点的分布式系统

异构计算节点克服异构性已被肯定为分布式系统中的关键任务。过去已经开发出各类解决方案，以解决资源异质性或网络异质性问题。然而，过去的方案受到两个主要限制：i）他们作出了强有力的假设，即任务只须要同质的计算资源（即CPU和内存），这在SSEC中是不正确的，由于复杂的社会传感任务可能须要多样化传感器，CPU和GPU等资源; ii）他们假设边缘设备始终与计算任务兼容，这在SSEC中也不必定正确，其中边缘设备可能具备不一样的运行时环境，例如OS和软件依赖性。相比之下，HeteroEdge框架明确地模拟了异构边缘设备，并使用基于经济学的新模型管理系统中的多样化资源。

2.4 IoT Middleware IOT中间件

如今正在提出理论与已有的关于IOT中间件的文献相关。IOT中间件的目标是链接异构的IOT设备，使得通讯变得可能。这些物联网中间件解决方案中存在着重要的知识差距，在很大程度上忽略了在我的拥有的日益强大且无处不在的边缘设备上执行计算任务的潜力。HeteroEdge专一于在物联网系统中的异构边缘设备上提供可靠的计算能力，以完成传统上在后端/云中完成的计算密集型任务（例如，基于深度学习的推理，图像处理）。这种“以计算为中心”的重点不一样于提供传统感应中心物联网中间件解决方案的以“互连性和互操做性”为中心。当下的以计算为中心的解决方案也有一眼严重缺陷：1）许多有计算能力的IOT设备都被我的全部而且这些设备存在严重的运行时异构，2）并无考虑计算任务的异构性和相互依赖性，3）没有彻底忽略硬件组件配置的多样性。

3 PROBLEM FORMULATION 问题提出

SSEC结构如图1所示。边缘设备 $ED = {E_1, E_2...E_X}$ ，边缘服务器

。这些边缘设备能够执行感测任务（例如，使用相机传感器收集图像数据），计算任务（例如，运行图像分类算法）或经过无线网络接口执行数据传输。经过具备不一样的系统架构（例如，X86，ARM），操做系统（例如，Windows，Linux），硬件（例如，具备/不具备GPU，传感器）和网络接口（例如，WiFi），假设边缘设备是异构的。，蓝牙）。本地边缘服务器做为具备各类网络接口的通用网络集线器，全部边缘设备均可以与本地边缘服务器通讯。

首先讨论任务模型。假设社交传感应用有Z个工做 $Job=\{J_1,J_2,...J_Z \}$ ，这些任务由服务器在每一个感知周期开始时初始化。每一个工做将原始感知输入数据转换为最终的分析结果。采用基于框架的任务模型，该模型经常使用于实时系统，其中做业被按期初始化并具备相同的时段和期限。Δ表明每一个工做的deadline，每一个工做包含M个管道有依赖性质的任务。每一个任务包含四元组 $τ_i=\{{VI}_i ,{VO}_i ,{WCET}_{i,x},R_i\}$ ， ${VI}_i$ 是数据规模, ${VO}_i$ 是输出规模, ${WCET}_{i,x}$ 是将任务分配给时在最坏状况下的执行时间(WCET)（1 ≤ x ≤ X）,是完成任务时获得的回报。任务的依赖性以一个任务依赖图为模型：

定义1.任务依赖定义图( $G_{task}$ )：一个有向图 $G_{task}=(V_{task},L_{task})$ ， $V_i∈V_{task}$ 表明任务τi，边( $τ_i→τ_j)∈L_{task}$ 表明的输入依赖于的输出。

对于一个给定的应用，假设在每个感知环节中一共有N个任务 {τ1, τ2, ..., τN }（Z个工做）

如图2，在灾难损坏评估应用中，一系列边缘设备的任务是在天然灾难中提供毁坏严重程度的报告。工做被定义为特定感兴趣位置的损害严重程度的推断，每个工做能够拆分为一个任务序列，包括：1）手机现场的原始图片数据，2）预处理图片，3）推断严重程度。因为SSEC异构的特性，单个的设备可能不能处理一个社交传感工做的所有任务。在图中，一个智能手机选择了2号任务，手机原始数据，但不能有效地处理图片为最终结果由于低效的GPU能力。所以它将图片卸载到附近的设备（一台笔记本）来进一步处理。在这个场景中，手机和电脑互相知足而且协做地完成一个社交传感任务，这个任务离开任何一方都没办法单独完成，由于电脑没有照片传感器而智能手机没有足够的计算能力。

将边缘的通讯信道变成通讯图模型：

定义2.通讯图（ $G_{com}$ ）：一个无向图 $G_{com}= (V_{com}, L_{com})$ ， $V_{com}$ 是全部边缘设备和边缘服务器的集合， $L_{com}$ 定义了通讯信道， $(E_x,E_y)∈L_{com}$ 表示与能够直接相互通讯。同时也有 $(E_x,E_S)∈L_{com}$ , ∀1 ≤ x ≤ X。

HeteroEdge的设计目标是以一种最优的方式编排SSEC系统中的边缘设备来执行社交感知和计算任务，以使端到端的延迟最小化和能量节约达到最大化。将端到端延E2E迟定义为：

定义3.工做的端到端延迟：Jz中全部任务处理传感器测量数据所用的总时间，它包括Jz的总计算时间和总通讯开销。

上述目标能够表述为多目标约束优化问题：

最小： $\sum_{x=1}^X ex$ （能量最小目标）

最小：, ∀1 ≤ z ≤ Z （应用的服务质量目标）（1）

使Gtask和Gcom获得知足（任务和通讯限制）。其中是一个感知周期中边缘设备的能量消耗。

最后提出了一些模型中的其余假设：1）假设边缘设备没有恶意或者不懒惰，2）假设边缘设备在感知周期中不会退出或加入系统，3）假设边缘用户为了得到回报愿意提供他们的计算资源能能源。同时在第6节也讨论了若是这些假设不成立要如何处理。

4 THE HETEROEDGE FRAMEWORK 架构

这一章主要讲了 HeteroEdge框架的系统设计和技术细节。如图3， HeteroEdge主要包含了三个主要模块：1）一个运行时抽象模块，2）一个硬件抽象模块，3）一个任务映射模块。运行时抽象模块和硬件抽象模块抽象了边缘设备的异构细节而且给社交感知应用提供了一个统一资源池。任务映射模块将互相依赖的社交感知任务以一种延迟能耗最优的方法分配给异构硬件资源。

4.1 Runtime Abstraction Module 运行时抽象模块

引入Docker容器技术，它是一个操做系统能免的虚拟电脑程序。它抽象了设备的硬件细节，而且提供了一个轻量级、便携式和表现很好地沙盒来安装应用程序。程序员为每个社交感知应用的将全部必要的基础和操做系统自己包装到一个Docker容器中，并将容器镜像上传到Docker存储库中。任何有安装了Docker引擎的边缘设备均可以从存储库下载镜像文件并运行社交感知应用程序。由于Docker容器是能够单独使用的，所以应用开发工程师和设备全部者都不须要担忧它们自己的硬件、操做系统或运行时环境。HeteroEdge的任务执行模块容许SSEC系统中的边缘设备给程序员提供相同的接口而且提供写一次导出运行的特征。

4.2 Hardware Abstraction Module 硬件抽象模块

硬件抽象模块将硬件异构的特殊细节进行抽象隐藏。受工做队列框架启发，将一个设备的硬件能力表示为一系列工人。咱们将完成传感任务的工人分为三类：CPU工人、GPU工人和传感器工人。每一个工人与一个可见标记和一个与处理社交感知任务的最坏任务执行估计时间相关的能力描述符相关联。将工人以下定义：

定义4.CPU工人：一个CPU工人表明了一个空闲的计算线程，为简单起见，咱们假设每一个内核一个线程。工人数量反映了设备同时处理多个社会感知任务的能力。

定义5.GPU工人：一个GPU工人表明了边缘设备中一个空闲的GPU。

定义6.传感器工人：一个传感器工人表明了一个可用的传感器。传感器工人有这种类型，好比GPS、录像机、照相机、加速器等。

边缘设备的工人共同定义设备的上下文。咱们假设边缘设备在系统运行或用户更改系统配置时不断更改工人的集合。在感知周期的设备E1的工做池是{1，CPU，可见，Alg1：500ms，Alg2：1500ms}，{1，GPU，不可见，Alg1：500ms，Alg2：100ms}，{ 1，传感器-摄像头，可见，灵敏度：10毫秒}，{1，传感器-GPS，可见，NA}，其中Sens，Alg1和Alg2是社交感知工做的任务序列。可见和不可见是用户设置的标志，表示他们愿意向应用程序公开工做人员。

硬件抽象模块的好处有三方面：i）异构边缘设备集经过将设备映射到工人，为社会传感应用程序造成统一的同构工做池;ii）终端用户能够注册和控制他们但愿为特定社交传感应用提供的工做人员以保护其隐私;iii）边缘设备能够容易地跟踪它们本身的动态状态，并为SSEC中的运行时决策和优化提供必要的上下文信息。

4.3 A Supply Chain-based Task Mapping Module 供应链任务映射模型

上述运行时和硬件抽象模块旨在为社交传感应用程序提供“同构”资源池和执行接口。然而，在SSEC中执行任务映射仍然具备挑战性，由于：1）任务是异构的而且具备复杂的执行要求（例如，传感任务只能在具备兼容传感器的设备上完成，计算任务可能须要特定的计算资源，如GPU）;2）咱们模型中的计算资源也是异构的（例如，某些设备有传感器而有些设备没有;有些设备配备GPU而其余人不配备;）3）各类任务分配策略可能会在能源成本和延迟开销之间产生复杂的权衡。

开发了基于供应链的任务映射模型，以解决上述挑战。为了适应供应链模型来解决任务映射问题，开发了几个新颖的技术组件。特别地，咱们提出了一种新颖的供应链图形映射技术和节点分解组件，以使用有向供应链图来共同模拟异构任务、计算资源以及能量和延迟之间的权衡。这两种技术的结合减小了寻找最优任务映射策略的复杂问题，该策略优化了延迟-能量权衡等价于寻找供应链图中的最短路径。咱们还设计了一种新的博弈论自私路由算法，以找到具备有界性能保证的最优任务映射策略。下面详细说明这些组件。

4.3.1 Supply Chain Graph Mapping. 供应链图映射

咱们的解决方案是经过观察咱们的问题与经济学中的供应链模型之间的映射来推进的。供应链问题涉及将天然资源，原材料和组件转化为交付给最终客户的成品。为了成为最终产品，原材料必须在具备不一样能力的不一样工厂/设施中运输和加工（例如，采购，制造，包装，组装）。在HeteroEdge中，咱们将原始传感测量视为“原材料”，将传感设备视为原材料的“供应商”。原材料必须经过一组工厂（即边缘装置）加工成为最终产品（即最终结果）。咱们指的是原材料通过的一系列工厂/设备，直到做为供应链路径到达消费者。工厂必须经过将处理过的材料彼此发送以进行进一步处理来协同工做。边缘服务器能够被视为最终产品的“消费者”。特别是，原始传感数据→计算节点→边缘服务器的链是供应链模型中原材料→工厂→消费者的精确映射。

形式上，咱们能够将任务映射问题映射到供应链图Gsc =（Vsc，Lsc）。供应链图由一组表明异构边缘设备的“设备节点”组成。每一个设备节点都与处理任务的计算延迟和能源成本相关联。除了设备节点，咱们还添加了一些“源节点” 源节点表示“提供”由社交感测应用决定的原始感测数据的位置。目标节点表示接收最终结果的边缘服务器（供应链的使用者）。咱们还定义了一组连接来表示边缘设备之间的通讯通道。链路l∈Lsc与传输延迟和能量成本相关联。

供应链图的一个例子如图4所示。它涉及三个任务（一个传感任务，两个计算任务）和三个边缘设备的社会传感工做。设备功能表显示边缘设备能够执行的任务。为了模拟任务依赖性，咱们将供应链分为多个阶段。在每一个阶段，咱们列出能够执行相应任务的全部设备。例如，阶段1表示从两个位置收集原始数据的“感知任务”。列出全部设备，由于设备A可以从位置1收集数据，而设备B和C可以从位置2收集数据。下一阶段，设备B和C能够执行计算任务（A1）。在最后阶段，设备C能够执行最终任务（A2）。注意边缘服务器ES被添加到计算任务的全部阶段，由于边缘设备咱们老是能够选择将计算任务卸载到边缘服务器上。咱们使用虚线表示“无成本”连接（例如，在同一设备上进行通讯），并使用实线表示与延迟和能源成本相关的通讯。

目标是找到从每一个源到目的地的最佳路线（即供应链路径），以最小化整体延迟和能量消耗。设表示从源节点到目的节点t的供应链路径。是的总成本（包括在的设备节点上的数据传输和处理期间的延迟和能量成本）。目标是找到：

为了解决上述目标函数，咱们执行i）节点分解统一了链路的计算成本和数据传输成本。此步骤将供应链问题转化为多源最短路径问题; 2）一种自私的路由算法，容许工做自私地选择路径来解决多源最短路径问题。

4.3.2 Node Decomposition. 节点分解

对于图4所示的供应链图问题，任务映射的目标是为供应商s1和s2找到最佳路径（具备最小延迟和能源成本）。为了解决这个问题，咱们首先将供应链图转换为统一图，方法是将全部成本与边相关联，并扩展设备节点以对设备的异构工做者进行建模。转换须要考虑如下场景。

具备单个CPU工做器的设备： 咱们将设备节点转换为虚拟节点： $v^{IN}$ 表示“进入”一个工厂（边缘设备）， $v^{OUT}$ 表示“退出”。咱们在 $v^{IN}$ 和 $v^{OUT}$ 之间建立了一个“虚拟连接”，而且该连接与在CPU工做器上执行任务的延迟和能量成本相关联。该场景的节点分解如图5（a）所示。

具备多个CPU工做器的设备： 多个CPU工做器表明边缘设备的多线程功能，这增长了建模能源成本的复杂性。使用线性能量模型，其中功耗=基本能量+额外能量消耗×线程数，其中基本能量表示CPU的默认能量消耗，与所使用的核心数无关。为了对此进行建模，除了 $v^{IN}$ 和 $v^{OUT}$ 以外，还引入了一个额外的中间虚拟节点 $v^{MID}$ 。建立从 $v^{IN}$ 到 $v^{MID}$ 的连接以模拟基本能量消耗（没有延迟）。此连接还有一个容量 $l^{cap}$ 表示核心数。连接容量表示能够同时经过链路而不会致使任何额外的基本能量成本的供应链路径的数量。例如，三核设备的容量为3，其中三个任务能够同时在设备上运行，只有1个单位的基本能耗加上每一个工人能耗的三个额外单位。还建立了从 $v^{MID}$ 到 $v^{OUT}$ 的虚拟连接，虚拟连接的数量与边缘设备v的工做者数量相同。多个虚拟连接意味着设备能够同时处理多个任务。该场景的节点分解如图5（a）所示。

具备GPU工做程序的设备： 具备GPU和3个CPU核心的设备的节点分解如图5（b）所示。在许多状况下，GPU须要至少一个额外的CPU核心才能运行程序。所以将一名CPU工做人员专用于具备GPU工做程序的设备，而其他的CPU工做人员能够处理其余任务。

在上述节点分解以后，问题变成了多源最短路径问题，其目标是找到从源到目的地的最佳供应链路径，从而最小化路径上链路的成本。特别地，供应链路径由一组链路组成，其中每一个链路 $l∈P_{z}$ 与两种类型的成本相关联：延迟和能量消耗。为简单起见咱们使用 $\pi^{delay}_{l}$ 来表示链路l的延迟成本， $\pi^{energy}_{l}$ 表示l的能源成本。而后有目标：

其中λ是一个标量，用于调整边缘设备能耗的重要性与应用的总延迟之间的关系。

上述目标的一个问题是能量成本的最小化很大程度上取决于边缘设备的能量分布，而且每每对低功率设备不公平。例如，考虑边原因低功率移动设备（例如，5W）和高功率笔记本电脑（例如，300W）组成的状况，上述目标函数将尝试将尽量多的计算任务推送到移动设备以节省笔记本电脑的能量，为移动手机用户带来不良状况。为了解决这个问题，咱们将能耗标准化以下：

其中是设备在感测周期中能量消耗，长度Δ指感知周期长度， $power_{x,max}$ 表示设备的最大功率。

4.3.3 A Selfish Routing Algorithm for Optimal Supply Chain.最优供应链的自私路由算法。

等式（3）中的目标是一个重要的问题。直观地说，每一个供应商（工做）均可以自私地选择最小化其自身成本的路径。然而，若是两个供应商选择相同的路线，则路径可能会变得拥挤，这将引入额外的延迟和能量成本。开发了一种新的供应链自私路由（SCSR）方案来解决这个问题。 SCSR计划基于博弈论框架，容许每一个工做自私地选择路线以最大化其自身效用，同时考虑其余玩家的策略。 SCSR计划的好处有三个：1）简单有效; 2）它为收敛和执行开销提供了理论保证，这对延迟敏感应用相当重要; 3）它能够很好地协调大量任务，以同时识别最佳的执行设备。首先在SCSR中定义一些术语。

设表示全部做业的供应链路径，是工做的任务映射策略（即供应链路径）。咱们使用 $P_{-z}$ 来表示除以外的全部工做选择的策略。对于做业，咱们定义权重来表示其工做量，假设该工做量与原始传感数据的大小成比例。还将 $d(l),l∈L_{sc}$ 定义为在其策略中选择连接的全部做业。从，咱们将的加权拥塞率定义为中全部路径的权重之和，即 $N(l)=\sum^{z∈d(l)}(w_z-(l^{cap}-1))$ 。而后能够将策略的利用率计算为：

基于利用率计算函数，咱们说若是不能经过ε单向从改变其路径来进一步下降成本，即，则工做知足其路径。若是每一个工做获得知足，那咱们说达到ε-纳什均衡。当ε=0时，平衡被称为纯纳什均衡（PNE）。纳什均衡可使用基于最佳响应动力学的贪婪算法达到。在算法1中总结了算法。（纳什均衡Nash Equilibrium：在一策略组合中，全部的参与者面临这样一种状况，当其余人不改变策略时，他此时的策略是最好的。也就是说，此时若是他改变策略他的支付将会下降。）

4.3.4 Algorithm Analysis. 算法分析

SCSR是一种迭代算法，快速收敛对延迟敏感的社会传感应用相当重要。在这一小节中，咱们推导出迭代的上界直到收敛，并证实SCSR在多项式时间内收敛于PNE。咱们首先将SCSR映射到原子网络拥塞博弈中，其中每一个链路具备相同的成本。这能够经过将链路 $l∈L_{sc}$ 分红多个子链路来实现，其中每一个子链路具备单位成本。例如，假设原始链路成本具备最大标准成本K，而且单位成本为1.那么能够将成本标准化为K + 1个整数值，即[0,1,2，... K]，连接最多能够分为K个子连接。

众所周知，在原子网拥塞博弈中，存在隐藏函数：

而且潜在的功能具备如下属性：

在博弈论中，每看成业进行改进步骤时隐藏函数减小，即切换到另外一策略以提升其利用率（即算法1中的第10-12行）。上述特性代表，每看成业经过从变为而进行ε的改善步骤时，隐藏函数减少。咱们证实了SCSR算法的收敛性和上界以下:

定理4.1. SCSR算法收敛于ε-纳什均衡多项式时间而且以 $O(\frac{M×K×n^{2C}}{ε})$ 为界，其中C是一个常数。

证实. 在等式（6）中，咱们有

其中 $w_ {max}$ 是的最大值，1≤z≤Z。假设 $w^{max}_z / w^{min}_z = O(n^C)$ ，其中 $w_ {min}$ 是的最小值，1≤z≤Z。咱们有潜在函数最多进行 $O(\frac{M×K×n^{2C}}{ε})$ 步就变为零。所以，SCSR算法须要至多 $O(\frac{M×K×n^{2C}}{ε})$ 步骤才能收敛到纳什均衡。

以上证实显示了SCSR算法的效率。注意，ε是影响SCSR算法收敛时间的关键参数。 ε的选择实际上取决于参与池的大小和应用程序的性质：它控制任务映射的最优性和SCSR算法的效率之间的权衡。在咱们的实验中，咱们选择ε实际上给出了最好的延迟。咱们在5.6节中对SCSR算法的收敛性和可扩展性进行了更详细的分析。

5 EVALUATION 评估

在本节中，在真实世界边缘计算测试平台上对HeteroEdge进行了普遍的评估。经过两个真实的社交传感案例研究来展现评估结果：灾害损失评估和协做交通监控。结果代表，与最早进的技术相比，HeteroEdge在QoS和能效方面实现了显着的性能提高。

5.1 Evaluation Platform 评估平台

咱们在真实的SSEC平台上部署HeteroEdge框架，该平台由一组10个边缘设备和1个本地边缘服务器组成。特别是，咱们使用配备Intel E5-2600 V4处理器和16GB DDR4内存的PC工做站做为本地边缘服务器。边原因10个异构设备组成：2个Jetson TX2和2个来自Nvidia的Jetson TK1板（经常使用于便携式计算机，无人机和自动驾驶汽车），5个Raspberry Pi3 B型板和1个我的计算机。

图6显示了边缘设备的实现硬件平台。这些边缘设备表明不一样的系统架构，操做系统和硬件功能。咱们在表1中总结了它们的规格。全部设备和边缘服务器都经过本地无线路由器链接。 HeteroEdge系统是使用Python实现的。咱们利用TCP套接字编程实现边缘设备之间的可靠数据通讯。

5.2 Energy Measurement 能耗测试

监测能源消耗是咱们评估中的关键绩效标准。为了测量能耗，咱们使用了INA219电流传感器IC，如图7所示，经过总线链接到Arduino Uno微控制器板。INA219中的功率计算机制包括测量串联链接的感知电阻上的电压降，该电阻与要监控其能耗的设备的主电源轨串联。INA219放大电压降 $U_{sense}$ ，使用板载ADC将模拟读数转换为数字并计算瞬时功率 $P_{load}$ ， $P_{load} = \frac{U_{sense}}{R_{sense}}×U_{load}$ ，其中 $U_{load}$ 是主总线电压而 $R_{sense}$ 感知电阻器的电阻。

5.3 Experiment Setup 实验设置

咱们从最近的文献中选择如下表明性技术：

• 随机分配（Rand）：一种启发式计算分配方案，其中社会感知任务被随机分配给边缘设备。

• 贪婪最短路径（GSP）：一种启发式资源分配方案，其中每一个做业选择供应链图的最短路径，以最小化能量和延迟成本。

• 集中式边缘服务器分配（CES）：集中式资源管理方案，边缘设备将全部数据发送到本地边缘服务器进行处理。

•自下而上的博弈论任务分配（BGTA）：用于非合做边缘设备的博弈论边缘计算资源分配方案。它使用分布式虚拟算法，容许边缘设备自私地挑选任务并最终达成共识。

存在一些系统也能够利用异质计算资源，如HTCondor ，CoGTA 和FemtoCloud 。可是，这些系统中的同构任务假设并不像第1节中讨论的那样存在于咱们的问题设置中。所以，咱们不将它们做为基线包含在内。

5.4 Case Study 1: Disaster Damage Assessment 案例研究1.灾害损失评估

第一个案例研究是灾害损失评估（DDA），其中参与者的任务是感知和评估在天然灾害期间是否发生了损坏（例如，由地震引发的坑洼和倒塌的房屋）以及在指定位置上的损坏程度如何。该应用程序的输出可为受灾地区的公民提供实时状况意识和及时警报。

咱们从Instagram和Twitter收集了2016年厄瓜多尔地震相关的2000张图片。咱们运行应用程序超过100个感应周期。图像按时间戳组织，并分红100个子集，每一个子集在一个感知周期中处理。应用中的社交感知工做包括如下总结的3个管道任务。

DDA的任务：i）配备有摄像机（例如，仪表板摄像机，UAV）的边缘设备的任务是捕获感兴趣的位置的实时图像; ii）使用来自原始图像的卷积神经网络（CNN）模型提取损伤检测图（DDM）特征; iii）使用算法评估DDM的损伤严重程度。

5.4.1 Quality of Service 服务质量。

在第一组实验中，咱们关注如何从应用程序方面实现目标。特别是，咱们评估全部比较方案的截止期限完成率（DHR）和端到端（E2E）延迟。 DHR定义为在截止日期内完成的任务的比率。结果如图8所示。咱们使用全部10个边缘设备并逐渐增长截止期限。咱们观察到HeteroEdge的DHR显着高于全部基线，而且是第一个在截止日期增长时达到100％的DHR。咱们将这种性能增益归功于咱们的SCSR算法，该算法找到了最佳的“供应链路径”，容许边缘设备搜索协做完成社交感知工做的最有效方式。

图9，根据工做数量不一样总结了全部方案的E2E延迟。咱们显示告终果的平均延迟和90％置信区间。咱们观察到，与基线相比，咱们的HetroEdge方案具备最小的E2E延迟和最小的置信区间。结果进一步证实了HeteroEdge知足应用程序的实时QoS要求的有效性。 HeteroEdge的性能增益是经过显式建模边缘设备（即动态工做池）的动态上下文并根据当前设备状态分配任务来实现的。

咱们发现HeteroEdge在上述实验中优于CES。这是由于CES经过将原始传感数据从边缘设备卸载到服务器而遇到了显着的传输延迟。此类数据传输延迟与服务器上可用的计算能力无关。相反，HeteroEdge在收集数据的边缘设备上执行计算任务。所以，HeteroEdge不须要在专用服务器上进行重要的资源配置，以超越集中式解决方案。相反，它经过充分探索边缘私有物联网设备的巨大计算能力，实现了更好的应用QoS性能。

5.4.2 Energy Consumption 能源消耗。

在第二组实验中，咱们关注边缘设备的能耗。如第4节所述，能量消耗被标准化以反映在完成全部计划社交感知工做时一个模式所消耗的电量比例。这种归一化的缘由是为了不不公平的状况，即最小化绝对能量最终将采用一种策略，该策略始终将大量计算从高功率设备推向低功率设备。边缘设备上的平均标准化能耗结果如表2所示。咱们使用全部10个边缘设备并将做业数量设置为10，将截止时间设置为3秒。咱们能够观察到，与除CES以外的全部其余基线相比，HeteroEdge消耗的能量显着减小。 CES在每一个边缘设备上消耗的能量最少，由于它只是将全部计算任务推送到本地边缘服务器。换句话说，CES方案利用边缘设备上的各类资源，并将额外负担推向服务器。结果代表，边缘设备能够在HeteroEdge下实现最长的电池寿命，这对于电源有限的边缘设备尤为重要。

5.5 Case Study 2: Collaborative Traffic Monitoring 案例研究2：协做流量监控

第二个案例研究是协做流量监测（CTM），其中社交传感应用程序的参与者使用我的移动设备（例如，移动电话，仪表板摄像机）来记录和分析当前的交通情况。例如，交通监控应用程序可让一组驾驶员使用他们的仪表摄像头拍摄车辆前方的交通视频，而后推断出道路的拥堵率。

咱们使用两辆车的仪表摄像头收集了视频数据。这些数据共包含30个视频片断，其中15个用于训练。咱们将应用程序划分为100个感应周期，每一个感知周期处理6秒的视频剪辑（每一个视频采样每周期15帧）。本申请中的社会感知工做包括如下总结的4个管道任务。

CTM的任务：i）交通视频信号的数据收集做为图像帧; ii）提取光流和定向梯度直方图（HOG）特征; iii）使用训练的SVM识别车辆计数来进行物体检测; iv）使用算法基于检测到的车辆推断总体交通情况。

5.5.1 Quality of Service 服务质量。咱们执行与以前案例研究中讨论的相似的实验。特别是，咱们根据DHR和E2E延迟评估全部方案。结果分别如图10和图11所示。咱们观察到与先前案例研究类似的HeteroEdge结果。这继续代表HeteroEdge方案能够在不一样的应用场景下提供所需的QoS。

5.5.2 Energy Consumption 能源消耗。边缘设备的能耗结果如表3所示。咱们观察到，咱们的方案继续为边缘设备提供比其余当前技术更多的节能。这再次证实了HeteroEdge经过为参与边缘设备提供更长的电池寿命而更加节能（“用户友好”）。

5.6 Convergence and Scalability 融合和可扩展性

最后，咱们研究了HeteroEdge中资源管理方案（即SCSR）的收敛和计算开销。咱们将K = 1和单位成本设置为0.1以标准化链路成本。

图12和图13显示了当咱们改变设备数量时SCSR的平均迭代次数直到收敛。咱们观察到随着ε值的增长，迭代次数显着减小。这里ε控制改变策略的可能性。较低的值是，玩家更有可能在博弈中改变其策略，这一般须要更多迭代才能使算法达到收敛。随着设备数量的增长，曲线也显示出线性趋势。这些结果也验证了第4.3.4节中SCSR方案的收敛性分析。

图14显示了SCSR的执行时间。执行时间包括SCSR算法的运行时间以及边缘服务器和边缘设备之间的通讯延迟。咱们观察到随着边缘设备数量的增长，SCSR的执行时间几乎呈线性增加。上述结果再次证实了将HeteroEdge用于延迟敏感的社会传感应用的适用性。咱们注意到，当系统中边缘设备的数量变得很是大时，SCSR方案的执行时间可能仍然是一个很大的开销。这种可扩展性问题的可能解决方案是增长本地边缘服务器的数量，并在由同一本地边缘服务器协调的边缘设备集群中运行HeteroEdge。因为边缘计算系统愈来愈流行的层次结构，该解决方案在实际应用中很是实用。

6 CONCLUSION AND FUTURE WORK 总结和将来工做

本文介绍了HeteroEdge框架，以解决基于社会传感的边缘计算（SSEC）系统中解决异质性问题的基本挑战。咱们已经在真实世界边缘计算测试平台上实现了咱们提出的框架，包括Nvidia Jetson TK1，TX2，Raspberry Pi3板和我的计算机。两个真实社交感知应用程序的评估结果代表，与最早进的技术相比，HeteroEdge实现了显着的性能提高。咱们的工做有一些局限性值得进一步研究。首先，HeteroEdge引发了安全问题。特别是，咱们假设边缘设备是合做的。可是，这种假设可能不适用于存在恶意设备的状况：它们可能故意延迟任务执行，使其错过最后期限。经过在HeteroEdge中添加额外功能来跟踪边缘设备的正常行为并主动阻止已识别的延迟设备，能够缓解此问题。

其次，HeteroEdge是一种软实时任务分配方案，能够最大限度地减小系统延迟，而不是提供硬限期保证。这是因为几个因素形成的。首先，因为SSEC系统中复杂的计算和通讯环境，任务执行时间的最坏状况估计不精确。其次，纳什均衡解的收敛时间也是动态的，难以准确预测。在将来，咱们计划在HeteroEdge中探索更复杂的执行时间预测方案（例如，静态程序分析和窄谱基准）。

第三，HeteroEdge依靠容器化来提供边缘设备的运行时抽象。所以，设备是否能够集成到HeteroEdge中取决于HeteroEdge中使用的特定容器技术的兼容性。例如，在撰写本文时，最早进的Docker容器还没有支持Android和IOS系统。当前的HeteroEdge系统没法支持运行这些操做系统的移动设备。咱们预计HeteroEdge的便携性能够在将来扩展到手机。

第四，咱们发现HeteroEdge特别适用于社交传感应用，其中每一个设备上的异构硬件均可以充分利用（例如，在咱们的评估中研究的DDA和CTM应用）。可是，在某些状况下，HeteroEdge可能不是最佳选择。例如，若是不能进一步分割做业（例如，独立的可执行文件），则不可能使用异构设备来共享计算任务。此外，若是应用程序中原始传感数据的数量过小，使用HeteroEdge下降传输开销的好处将是微不足道的。在这两种状况下，基于云的解决方案可能更合适。此外，HeteroEdge不适用于具备严格期限要求的硬实时系统。这是由于HeteroEdge中的物联网设备可能具备不可靠的网络链接，而且私有设备上的执行时间可能很是动态且不可预测[8]。

最后，咱们当前的实验平台由有限数量的边缘设备组成，HeteroEdge的可扩展性方面值得进一步研究。 HeteroEdge具备保证纳什均衡的良好特性，而且在现实社会传感应用中具备快速收敛性。在将来的工做中，咱们计划进行额外的仿真研究，以使用专为异构边缘设备设计的中的仿真器来研究HeteroEdge的可扩展性。

文章大纲

文章出处

Daniel (Yue) Zhang, Yang Zhang, Md Tahmid Rashid, Xukun Li, Nathan Vance, and Dong Wang. “HeteroEdge: Taming The Heterogeneity of Edge Computing System in Social Sensing.” In ACM/IEEE IoT DI 2019. [Top IoT conference (Acceptance Rate: 28%)]

dl.acm.org/citation.cf…

下一步阅读方向

Daniel Zhang, Yue Ma, Chao Zheng, Yang Zhang, X Sharon Hu, and Dong Wang.2018. Cooperative-Competitive Task Allocation in Edge Computing for Delay-Sensitive Social Sensing. In 2018 IEEE/ACM Symposium on Edge Computing (SEC). IEEE, 243–259.
Daniel Yue Zhang, Dong Wang: An Integrated Top-down and Bottom-up Task Allocation Approach in Social Sensing based Edge Computing Systems. INFOCOM 2019: 766-774. dblp.uni-trier.de/pers/hd/w/W…