原始論文來源 : mCloud: A Context-Aware Offloading Framework for Heterogeneous Mobile Cloud
簡介
行動雲端運算（Mobile Cloud Computing，MCC）已經成為一個把雲端運算技術的優勢，帶到行動裝置的知名應用。行動雲端運算(MCC)強調服務的可用性、性能增強和能源效率，而本篇論文提出一個名為mCloud的程式碼交付框架，框架由行動裝置(mobile device)、網路邊緣的小規模雲端資料中心(cloudlet)和公共雲服務(public cloud service)組成，目標在於改善行動雲端運算的表現和可用性。
行動裝置的情境對於行動雲端運算如何做出程式碼交付決策很關鍵，mCloud即對此研究了一個情境感知交付決策演算法(context-aware offloading decision algorithm)，該演算法會在要執行行動雲端運算時，選擇合適的無線傳輸媒介和雲端運算資源用來實際執行程式。除此之外，mCloud亦有做系統故障偵測與排除的研究。
研究結果顯示，mCloud架構和提出的決策演算法能夠基於行動設備的不同情境提供合適的無線傳輸媒介和雲端運算資源的決策，在縮短工作時間和節省能源方面取得顯著的降低，與現有的決策演算法相比，mCloud在提高服務可用性方面亦有所改進。
mCloud的系統架構
這邊主要說明在理解mCloud的系統架構時，需要先知道的一些知識點。
mCloud使用的雲端資源
mCloud使用的雲端資源總共有三種，分別是公共雲服務(public cloud service)、網路邊緣的小規模雲端資料中心(cloudlet)和行動隨意網路(mobile ad-hoc network，MANET)，以下說明它們各自的特點。
- Public Cloud Service
- 能提供大規模的算力和儲存空間
- 行動客戶端可用WiFi和衛星網路連接
- 有能力處理需要大量運算和資料傳遞的任務
- Cloudlet
- 屬於一種本地資料中心
- 由多核處理器組成叢集，並連結成大頻寬且低能耗的WLAN
- 有能力處理需要低延遲的任務
- MANET(mobile ad-hoc network)
- 由許多行動裝置藉由短距離通訊技術連結而成的網路結構
- 因為行動裝置的可移動性，所以屬於不穩定的網路
- mcloud當中採用的網路拓撲(Topology)是one-hop
除了雲端資源之外，在某些情境下，任務也有機會被mCloud的決策演算法分配在行動裝置本地執行。
mCloud的框架組成元件
mCloud框架實際由許多元件組成，並分屬於兩個部分，即客戶端(client)和雲端伺服器(cloud server)。
- 客戶端元件
- 情境感知器(context monitor)
- 決策模組(decision module)
- 任務管理器(task manager)
- 通訊管理器(communication manager)
- 故障排除(failure recovery)
- 雲端伺服器元件
- 通訊處理器(communication handler)
- 任務管理器(task manager)
- 其他行動雲端基礎建設
以下是對於各元件簡略的說明，詳細的元件說明請參見原始論文。
- 情境感知器(context monitor)
- 提供決策引擎各類的情境參數輔助決策制定
- 有三個主要情境感知的資料來源
- 程式分析器(program profiler)，以method level層級追蹤程式執行
- 裝置分析器(device profiler)，監測行動裝置的執行環境
- 網路分析器(network profiler)，非同步地監測行動裝置所處網路狀況
- 為節省間接成本、能耗，只有需要的時候，才會觀測目前的情境(on-demand strategy)
- 決策模組(decision module)
- 決定行動裝置的任務要如何根據情境分配執行
- 模組由兩個部分組成
- 成本估計(cost estimation)，估計在不同雲端資源的執行時間、客戶端的能源消耗
- 決策引擎(decision engine)，把成本估計結果傳入決策演算法，制定最後的決策
- 任務管理器(task manager)
- 接收來自決策引擎做出的決策，儲存任務的執行結果
- 根據上層資訊，主動收集相關資訊(如method library)，並打包交給通訊管理器
- 通訊管理器(communication manager)
- 負責裝置和雲端資源的溝通，使雲端資源根據決策執行任務
- 可以再細分成兩個部分
- 探知服務(discovery service)，週期性的監測目前可用的雲端資源
- 通訊處理器(communication handler)，處理客戶端和雲端基礎建設的連線、通訊資料
- 故障排除(failure recovery)
- 常見故障包含遠端節點崩潰、超出通訊距離和訊息掉包等
- 探知服務週期性監測雲端資源，當認定有故障發生就會觸發回復機制
- 故障可透過尋找其他可用雲端運算資源來排除，完全找不到就在本地運算
(圖片出自原始論文)
mClould的運作流程
在說明運作流程前，先稍微解釋mCloud如何計算任務交付到雲端運算資源和本地執行的成本，以及決策演算法制定決策使用的六大標準。
- 如何計算任務交付執行的成本
- 成本(C) = a×執行時間(D) + b×c×能源消耗(E)
- a和b總和為1，且a和b均需大於0，用來調整執行時間和能源消耗在成本考慮的重要性
- c是硬體參數，用來調整硬體設定對能源消耗的影響。
- 決策演算法制定決策的六大標準
- 不同雲端資源各自的能源消耗多寡
- 不同雲端資源、傳輸媒介的連線速度
- 不同雲端資源、傳輸媒介的可用性
- 資料從行動裝置傳遞到不同雲端資源的成本
- 不同雲端資源和行動裝置之間連線的壅塞程度
- 不同傳輸媒介的訊號品質
(但這六大標準對決策演算法在制定決策時的影響不是一樣的，後續會經由其他演算法算出每個標準對最終決策的影響權重。決定權重的過程稍微複雜，若有需要可以參考原始論文。)
mCloud框架的簡易運作流程如下:
- 客戶端送出交付請求(offloading request)到決策引擎。
- 情境感知器觀測目前的情境收集情境參數，並將情境參數傳給決策引擎。
- 通訊管理器透過探知服務，告知決策引擎目前可用的雲端資源。
- 任務管理器接收來自決策引擎做出的決策，主動收集相關資訊並打包產生任務資訊。
- 通訊管理器收到來自任務管理器的任務資訊，並把任務拆分成複數小任務準備做平行處理。
- 通訊管理器將這些小任務交付給雲端資源在遠端執行。
- 通訊管理器保持裝置和雲端資源的連線，等待收到任務的執行結果。
- 通訊管理器將平行處理的結果聚合並向上傳遞到任務管理器，同時將執行時間和能源消耗儲存到任務管理器的資料庫。
- 任務管理器將任務執行結果向上傳遞到決策引擎。
- 決策引擎將任務執行結果向上傳遞到客戶端。
(圖片出自原始論文)
mCloud的特點
- mCloud是以ThinkAir為原型進行實作和設計的框架。
- mCloud提出一個新穎的情境感知交付決策演算法。
- mCloud不同於其他框架，設定眾多使用情境，專注於各類型的雲端資源最佳化。
- mCloud提出一個具普遍性的成本估計模型(考量執行時間、能源消耗)。
- mCloud能輕鬆適應新加入的可用雲端資源且容易調整架構。
心得
目前看了2篇半的論文，我發現有沒有附上index terms在閱讀論文時會差很多，有放index terms的論文，我可以比較快就抓到論文的重點，像是這篇論文提出的新概念、改善的地方和應用的技術等，在看abstract之前，如果論文有附上index terms，我現在會選擇先看index terms。在論文的段落設計方面，我原本以為都是很制式要依照順序書寫(前2篇看的論文第二段都是Related Work)，看到第三篇論文才發現段落不一定都要依照制式，提供了我未來書寫論文做段落分隔的新思路。
在選擇研究方向方面，我原本有不小的壓力，因為要提出一個完全新穎且具突破性的技術或應用，對我來說可能不是件容易的事，不過在閱讀幾篇論文後，我認知到論文是可以從現有技術或應用進行延伸的，像是GeTrust就是從Chord P2P network做延伸，而mCloud是從ThinkAir做延伸。我還發現論文後面作者通常都會提出未來的可能研究方向，這樣看來或許研究方向就不是個難解的問題，問題反而是想做的是什麼方面的應用，不過我到現在都還沒有明確的答案。
最後，我還觀察到論文裡面一個蠻有趣的地方，就是實作結果和既存應用的比較，以GeTrust為例，它是2018年初發表的論文，在實作結果的部分，作者是拿GeTrust和FCTrust以及SecuredTrust進行比較，但FCTrust是在2008年提出，而SecuredTrust則是在2012年提出，我在想是不是這方面比較少人研究，所以才會選擇這兩個較舊的信任模型來比較，又或者是GeTrust與它們比較會讓圖表呈現比較好的結果，還是有其他可能的原因，我有點好奇實際上在寫實作結果時，拿來進行比較的相關技術或應用是怎麼被決定的。