【論文閱讀】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…

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。