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中复杂的任务映射问题。

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}$ ，边缘服务器 $ES$ 。这些边缘设备可以执行感测任务（例如，使用相机传感器收集图像数据），计算任务（例如，运行图像分类算法）或通过无线网络接口执行数据传输。通过具有不同的系统架构（例如，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}$ 是将任务分配给 $E_x$ 时在最坏情况下的执行时间(WCET)（1 ≤ x ≤ X）, $R_i$ 是完成任务时得到的回报。任务的依赖性以一个任务依赖图为模型：

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

对于一个给定的应用，假设在每一个感知环节中一共有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_y$ 可以直接相互通信。同时也有 $(E_x,E_S)∈L_{com}$ , ∀1 ≤ x ≤ X。

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

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

上述目标可以表述为多目标约束优化问题：

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

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

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

最后提出了一些模型中的其他假设：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被添加到计算任务的所有阶段，因为边缘设备我们总是可以选择将计算任务卸载到边缘服务器上。我们使用虚线表示“无成本”链接（例如，在同一设备上进行通信），并使用实线表示与延迟和能源成本相关的通信。

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

为了解决上述目标函数，我们执行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工作人员可以处理其他任务。

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

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

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

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

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

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

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

基于利用率计算函数，我们说如果不能通过ε单向从 $P_z$ 改变其路径来进一步降低成本，即 $u_z(P_z)≤u_z(P_z')+ε$ ，则工作满足其路径。如果每个工作得到满足，那我们说达到ε-纳什均衡。当ε=0时，平衡被称为纯纳什均衡（PNE）。纳什均衡可以使用基于最佳响应动力学的贪婪算法达到。在算法1中总结了算法。（纳什均衡Nash Equilibrium：在一策略组合中，所有的参与者面临这样一种情况，当其他人不改变策略时，他此时的策略是最好的。也就是说，此时如果他改变策略他的支付将会降低。）

4.3.4 Algorithm Analysis. 算法分析

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

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

并且潜在的功能具有以下属性：

在博弈论中，每当作业进行改进步骤时隐藏函数减少，即切换到另一策略以提高其利用率（即算法1中的第10-12行）。上述特性表明，每当作业通过从 $P_z$ 变为 $P_z'$ 而进行ε的改善步骤时，隐藏函数减小 $2×w_z×ε$ 。我们证明了SCSR算法的收敛性和上界如下:

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

证明. 在等式（6）中，我们有

其中 $w_ {max}$ 是 $w_z$ 的最大值，1≤z≤Z。假设 $w^{max}_z / w^{min}_z = O(n^C)$ ，其中 $w_ {min}$ 是 $w_z$ 的最小值，1≤z≤Z。我们有潜在函数 $Φ(P)$ 最多进行 $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所示，通过 $I^2C$ 总线连接到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…

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