概要
通過網(wǎng)絡通訊，將大量計算任務從移動設備遷移到功能強大的云服務器上，這一種移動云計算遷移技術可以降低設備的硬件限制，從而提供更高的性能并且節(jié)約能源。不同的應用對耗時和能耗的關注度各不相同。如果一個對延遲可容忍的作業(yè)被推遲到給定的時限，或者一個高效節(jié)能的網(wǎng)絡可用，傳輸時間都將延長。通訊信道可以變得更加節(jié)能、計算平臺的資源受限越來越少，這些改變都可以節(jié)約能耗。但是，如果節(jié)省下來的時間無法彌補額外的等待時間，則此策略將不那么有效。在此篇論文中，我們研究了兩種延遲遷移策略: 一種是部分遷移模型，其將計算任務從緩慢的遷移流程中釋放，并且可以在本地執(zhí)行；另一種是完整的遷移模型，可以通過蜂窩隊列而非WiFi隊列進行遷移。在這兩種模型中，我們最小化能量響應時間加權乘積(ERWP)度量。我們發(fā)現(xiàn)當WiFi網(wǎng)絡的可用性很低時，計算任務經(jīng)常放棄排隊。一般來說，對于延遲敏感的應用，在適當?shù)耐岁牪呗韵?，我們?yōu)先選擇部分遷移模型；而對于延遲容忍的應用，完整的遷移模型都有不錯的效果，當選擇較長的時限時，該模型優(yōu)于其他的模型。完整遷移模型在能耗方面效果最好，即使任務截止日期很長。當耗時最關鍵時，部分遷移模型的最優(yōu)截止時間和完整遷移模型的WiFi傳輸才有意義。如果是為了節(jié)約能耗，應該增長等待時間而不是進行本地計算或者使用蜂窩網(wǎng)絡。
關鍵詞: 移動云計算，移動任務卸載，異構網(wǎng)絡，能耗-性能折中，隊列模型
1 介紹
除去輕量級的互聯(lián)網(wǎng)應用，移動用戶對于移動設備上的計算密集型和耗能型應用的需求越來越多。然而，由于移動設備上資源受限，例如有限的計算容量、電池壽命和網(wǎng)絡連接，在這些設備上運行復雜應用是極為困難的。通過無線網(wǎng)絡將計算密集型任務從移動設備遷移到功能強大的云服務器上，可以有效緩解資源受限的移動設備和需要資源的移動應用之間的沖突，從而提升設備的性能。遷移還有一些潛在的好處，包括提升任務的響應速度以及減少處理任務的占用資源等。
對于那些需要在相當少量的數(shù)據(jù)上進行大量計算的應用而言，移動遷移技術是非常有效的。確切來說，該篇論文中我們只考慮那些上傳比下載數(shù)據(jù)量大的應用程序。那些圖像識別類的應用程序都是這樣的例子，比如光學文本識別或者圖像物體檢測。
不同類型的應用通常對時耗和能耗的關注度也各不相同
- 對延遲容忍的應用：許多應用程序(比如，iCloud，社交網(wǎng)絡，移動醫(yī)療保健和城市斷層攝影等)處理視頻、音頻、傳感數(shù)據(jù)或者通過網(wǎng)絡請求大型數(shù)據(jù)庫時都對網(wǎng)絡延遲不敏感。參與式傳感應用程序是數(shù)據(jù)密集型但對延遲容忍的應用程序中一個很好的例子。大量傳感器節(jié)點獲取的傳感器數(shù)據(jù)，創(chuàng)建了關于諸如個人資源消耗，飲食習慣和城市文獻等參數(shù)的知識體系[1]。數(shù)據(jù)通過蜂窩網(wǎng)絡或WiFi網(wǎng)絡從智能手機上傳到后端的云服務器上。某些非實時性的傳感器信息只有在設備進入節(jié)能網(wǎng)絡后，才會提交到服務器上[2]。用戶可以通過服務器端的網(wǎng)站瀏覽或搜索獲得的檔案。當在正常網(wǎng)絡覆蓋范圍之外(例如在蜂窩協(xié)議不可用的國外)旅游時，會出現(xiàn)如下的生活場景:用戶希望觸發(fā)某個任務以免忘記，但僅在回到工作場所時才需要其結果。一般而言，對于延遲可以容忍的應用來說，響應時間不那么重要，優(yōu)化能耗更關鍵。
- 對延遲敏感的應用:當在移動設備上運行對延遲敏感的應用時(比如，面部識別，視頻會議，車輛通信，身份認證)時，移動用戶需要與其正常認知能力相當?shù)目焖夙憫Ｒ虼?，為了獲得更好的用戶體驗，感知式應用應該控制其響應時間。通過計算節(jié)點的遠程執(zhí)行，任務遷移技術可以普遍地應用到感知式應用上?？焖俚捻憫獙@些應用很重要，在較短的網(wǎng)絡延遲(例如WiFi網(wǎng)絡)后，云服務上的任務卸載方案可以為這些應用提供更好的方式并且降低響應時間。
由于移動性，移動用戶很容易受到動態(tài)變化網(wǎng)絡條件的影響，這使得在移動環(huán)境中[3]做出好的遷移決策相當困難。移動網(wǎng)絡環(huán)境對遷移系統(tǒng)的性能有很大影響。因此，想要采取高效的遷移策略，我們通常需要對網(wǎng)絡環(huán)境有一個很好的了解。
移動設備通常具有用于數(shù)據(jù)傳輸?shù)亩鄠€無線接口，例如3G/4G或者WiFi，各個接口都有著不同的可用性、延遲和能耗。因此，將計算任務遷移到云服務器上有幾種不同的方式，例如通過高開銷的蜂窩連接，或者間歇可用的WiFi[4]。直到WiFi變得可用才進行遷移，這一舉措可以以額外的等待時間為代價來減少傳輸時間。節(jié)省下來的傳輸時間在未來的某一刻將直接轉變?yōu)楣?jié)省移動設備的電池電量[5]。然而，延遲遷移仍然是一個有爭議的話題，因為我們無法預知用戶愿意為延遲傳輸?shù)鹊绞裁闯潭萚6]。在該篇論文中，我們嘗試給出關于如何平衡不同場景(例如延遲容忍和延遲敏感應用)下的時耗和能耗的總體意見。我們開發(fā)了一個理論框架，通過使用隊列模型來處理延遲敏感任務和服務終端，從而獲得性能-能耗上的折中。這些模型可用于預測給定網(wǎng)絡環(huán)境部署條件下的平均性能和能耗。
該篇論文的主要工作如下:
- 我們提出了兩種用于延遲遷移云系統(tǒng)的分析隊列模型：部分模型和完整模型。還引入了非延遲的遷移模型以供比較[7]。
- 我們開發(fā)了一個分析框架，用于分析具有服務中斷的模型。從該框架中，我們獲得了在延遲遷移系統(tǒng)中的關鍵性能指標的閉合公式，例如能量響應時間加權乘積(ERWP)，它結合了其他先前研究的指標的優(yōu)點。
- 我們旨在回答以下的一系列問題：
i 給定時限，作為網(wǎng)絡參數(shù)和任務到達時間的函數(shù)，預期的響應時間和能耗是多少？
ii 如何選擇最佳的時限，以便為特定應用實現(xiàn)特定的能量-延遲權衡？
iii 給定多個模型，哪一個模型最適合根據(jù)ERWP指標獲得性能增益？
本文的剩余部分安排如下:第二節(jié)介紹了相關工作；第三節(jié)描述了延遲遷移模型的系統(tǒng)架構以及所考慮的指標；第四和五節(jié)展現(xiàn)了數(shù)學模型及其對部分和完整遷移模型的分析。基于ERWP指標的部分遷移模型分析在第四節(jié)中介紹。第五節(jié)提出并分析了完整的遷移模型。第六節(jié)基于移動網(wǎng)絡中的實際數(shù)值評估了指標和模型。第七節(jié)進行總結。
2 相關工作
本節(jié)討論了當前遷移系統(tǒng)的相關工作，包括如何縮短計算任務的完成時間、能耗以及兩者的結合，每個話題對應一個部分。移動設備上的時耗和節(jié)能問題變得越來越重要。許多研究工作致力于將計算遷移到遠程服務器上以便縮短執(zhí)行時間或節(jié)能。
2.1 縮短任務的完成時間
移動云遷移有時可以分為兩步：其中云通過近距離微云到達，而微云又連接到功能強大的云服務器上。Satyanarayanan[8]等人提出了一種基于虛擬機的移動計算云，智能手機通過WLAN連接到該云。假設到云的連接比到微云的連接具有更高的延遲和更低的帶寬。實質上，微云將移動設備作為微客戶端來訪問本地資源，而不是直接使用移動設備的資源并僅在需要時才進行計算遷移。
一種動態(tài)遷移的隨機模型[4]使用多種性能指標以及間斷可用的訪問連接進行工作。移動設備的移動特性和無線連接的不穩(wěn)定性，影響了在遷移系統(tǒng)控制下運行的普遍服務的預測性能。Ou[9]等人分析了移動無線環(huán)境下遷移系統(tǒng)的性能，并考慮到了系統(tǒng)故障與恢復，卻并未討論該如何采取遷移策略。另一個框架中[10]研究了使用寬帶預估技術進行遷移策略選取，該作者通過預測本地和遠程系統(tǒng)的帶寬，制定計算遷移的策略，該方案假設網(wǎng)絡可靠性不成問題，然而實際上網(wǎng)絡并不是一直可用。
2.2 節(jié)能
為了減少移動設備的能耗，移動遷移系統(tǒng)已經(jīng)存在了很多年。MAUI[11]是一個能夠使移動代碼部署到基礎設施上的能耗感知系統(tǒng)。通過權衡本地處理的能耗與遠程執(zhí)行的代碼和數(shù)據(jù)傳輸能耗，該系統(tǒng)可以最大程度上優(yōu)化設備能耗。該系統(tǒng)在運行時決定應該遠程執(zhí)行哪些方法，以便在移動設備網(wǎng)絡連接受限時節(jié)能。
Kumar[12]等人認為計算遷移有可能為移動用戶節(jié)約能耗，但并非所有應用在遷移到云服務器上后都能夠高效節(jié)能。取決于計算遷移節(jié)省下來的計算開銷是否由于額外的通信成本。對于那些大量通信、少量計算的任務而言，應該在移動設備上執(zhí)行本地計算，對于那些少量通信、大量計算的任務而言，需要在遠程計算。
一些作者在為將應用程序任務分配到移動設備本機還是云服務器上時，也考慮到了響應時間約束。時限對于大多數(shù)的交互式應用而言是很重要的。為了在節(jié)約能耗的同時滿足應用程序給定的時限，動態(tài)的計算任務遷移策略被提出[13][14]。這些方案在解決策略選擇問題上具有很低的復雜度(例如，確定哪些軟件組件在移動網(wǎng)絡環(huán)境下遠程執(zhí)行)
2.3 節(jié)時與節(jié)能結合
出于節(jié)約時間和能耗兩方面的考慮，一些作者提出了相應的解決方案。CloneCloud[15]使用了靜態(tài)分析和動態(tài)配置，在某指定計算和通信環(huán)境下，以細粒度自動劃分應用程序以便優(yōu)化執(zhí)行時間和能耗。然而，靜態(tài)的應用程序劃分[16][17]并不適用于網(wǎng)絡條件會發(fā)生重大變化的情況。由于異構的無線網(wǎng)絡環(huán)境、設備的移動性、云資源的不可用性等問題，網(wǎng)絡連接有時會變得斷斷續(xù)續(xù)。移動網(wǎng)絡中不穩(wěn)定的連接對遷移策略有很大影響。高通信延遲和能耗可能會使得本地執(zhí)行在特定情況下更有優(yōu)勢。
在[18]這篇論文中提出了通過在集中傳輸技術中來回切換以實現(xiàn)遷移的無縫操作技術。他們研究了當WiFi網(wǎng)絡僅間歇可用時，該如何權衡WiFi搜索的能耗與傳輸率。在[1][19]這兩篇論文中提出了如何選擇高效的延遲網(wǎng)絡，來優(yōu)化能耗與將數(shù)據(jù)傳輸拖延到移動設備處于高效網(wǎng)絡環(huán)境下的延遲之間的權衡。此外，延遲遷移還被用在沒有WiFi連接可用的情況下。某些連接會被堵塞，直到截止時間或者直到WiFi可用[20]。[21]中提出了延遲移動遷移的在線調度策略，使用WiFi傳輸?shù)臄?shù)據(jù)量盡可能最大化。高策略僅在數(shù)據(jù)傳輸超時的情況下使用蜂窩數(shù)據(jù)。
本文的工作是基于以上提到過的，對于移動云環(huán)境下間歇性可用網(wǎng)絡連接問題的有趣研究，旨在平衡不同的目標，例如最小響應時間、最小能耗等。我們明確考慮了用戶和應用程序的移動性，并研究了基于我們之前的工作[22][23][24],使用組合度量來解決這些異構問題。
3. 系統(tǒng)模型
這一節(jié)，我們基于網(wǎng)絡可用性模型，定義了兩種不同的延遲遷移模型，并且提出了一個全新的指標來獲得能耗-性能的折中。
3.1 網(wǎng)絡模型
圖1展示了我們所做的假設。我們假設蜂窩接口比WiFi有著更高的可用性，并且能夠為廣域的移動設備提供近乎全面的覆蓋，但是蜂窩接口比WiFi的數(shù)據(jù)傳輸率要低并且會消耗更多的傳輸能量。換句話說，我們假設WiFi在傳輸相同量的數(shù)據(jù)上要比蜂窩接口更快且更高效。為了便于分析移動遷移系統(tǒng)，我們假定對于移動用戶來說，蜂窩網(wǎng)絡任何時刻都可用，但是WiFi網(wǎng)絡取決于地理位置。移動用戶可以進出WiFi覆蓋區(qū)域。這些假設看起來在很多情況下都符合現(xiàn)實，并且這些假設構成了本論文的基礎。
我們通過ON-OFF交替更新過程[嵌入式1]來模擬WiFi連接狀態(tài)的時間變化，如圖2所示。On階段表示W(wǎng)iFi連接可用，OFF階段表示W(wǎng)iFi連接中斷。在后一階段，數(shù)據(jù)要么不被傳輸(由于接口空閑)，要么只能通過蜂窩網(wǎng)絡傳輸。每個ON周期的持續(xù)時間[嵌入式2]，可以假定是隨機變量的指數(shù)分布，并且與其他ON和OFF的持續(xù)時間無關。此外，WiFi可用率可以被定義成AR=[嵌入式3]。
3.2 延遲遷移模型
根據(jù)圖2所示的網(wǎng)絡可用性模型，我們定義了兩種不同的計算任務遷移模型，即后面將要提到的部分模型和完整模型。在延遲遷移時，時限與數(shù)據(jù)傳輸相關聯(lián)，并且移動設備只要到達有WiFi覆蓋的范圍，數(shù)據(jù)傳輸就會恢復，直到傳輸完成或者到達時限(以先到者為準)。如果時限到達時，傳輸任務仍未完成，剩余的任務將在本地執(zhí)行(部分遷移模型)或者將使用蜂窩網(wǎng)絡完成數(shù)據(jù)傳輸(完整遷移模型)。
部分遷移模型: 我們使用一個兩階段的隊列(快速階段:使用WiFi網(wǎng)絡, 慢速階段:使用蜂窩網(wǎng)絡)來將計算任務遷移到云服務器上。當WiFi網(wǎng)絡可用時，所有的可遷移任務都將通過WiFi網(wǎng)絡進行傳輸;否則，他們將通過蜂窩網(wǎng)絡進行傳輸，因為蜂窩網(wǎng)絡總是可用。我們在蜂窩網(wǎng)絡中重新設置了一個時限，如果任務在切換到某個WiFi AP之前到期，那么它將在本地繼續(xù)執(zhí)行，而不是在云服務器上遠程執(zhí)行。使用這種方案，我們將部分作業(yè)遷移到云服務器上，其余部分留在本地處理。
完整遷移模型: 當WiFi連接可用時，所有的可遷移任務都通過WiFi網(wǎng)絡傳輸，否則，他們要么延遲到給定的時限，要么通過蜂窩網(wǎng)絡進行遷移。通過這種方案，我們將所有的可遷移任務通過WiFi網(wǎng)絡或者蜂窩網(wǎng)絡進行遷移。
我們考慮延遲遷移中的隊列系統(tǒng)。移動設備、云服務器和無線網(wǎng)絡都可以當作是用來捕獲資源占用和系統(tǒng)延遲的隊列節(jié)點。移動設備執(zhí)行應用中的可遷移任務，既可以使用移動設備的本地處理器執(zhí)行，也可以通過計算任務遷移使用遠程的云服務架構。移動設備、蜂窩連接和WiFi連接被建模成M/M/1-FCFS隊列，遠程云建模成M/M/∞隊列，即作為一個延遲中心[26]。我們使用嵌入式4和嵌入式5對應到移動設備和云上的期望執(zhí)行時間。通過蜂窩網(wǎng)絡和WiFi將數(shù)據(jù)傳輸?shù)皆频念A期速率分別是嵌入式6和嵌入式7。
延遲遷移模型包含了帶退隊和服務中斷的排隊現(xiàn)象。在排隊時，退隊意味著一個計算任務在過期后，將要離開該隊列并加入到另一個隊列中。服務中斷字面意思是隊列中服務有一些非自愿的不連續(xù)性，這模擬了移動設備與系統(tǒng)中WiFi網(wǎng)絡的時斷時續(xù)現(xiàn)象[27]。我們的延遲計算任務遷移模型和延遲數(shù)據(jù)遷移的最大區(qū)別在于，不僅僅只有數(shù)據(jù)被傳輸?shù)皆粕?，任務本身也會在遠程的云服務器上執(zhí)行。通常情況下，遷移的數(shù)據(jù)在顯示前需要進一步分析或進行簡單地處理。
3.3 度量
這一小節(jié)，我們定義了一種新的指標，用于評估和優(yōu)化任務完成時間與能耗之間的權衡。
3.3.1 ERWS
能耗響應時間加權和(ERWS)指標是一個代價函數(shù)，定義為相應部分期望值的加權和。
公式1
E用來表示一個隨機變量的期望值，E(T)和E(e)是耗時和能耗的期望值，相應的，w(值域為0-1)是用來表示移動設備對耗時和能耗側重程度的權重參數(shù)。如果更關注性能，w應該小于0.5，如果更關注節(jié)能，w應該大于0.5，如果w恰好是0.5，說明既關注提高性能，又關注節(jié)約能耗。期望值取決于其估計值，即為平均值。
ERWS指標的優(yōu)勢在于分析上易于處理，因為期望隨著時間而增加，因此可以通過馬爾可夫決策過程來優(yōu)化[28]。從最小化的角度考慮，該指標可以將任意的遷移策略與最優(yōu)遷移策略相比較。然而，缺點在于該指標是兩種不同比例的指標的線性組合。
3.3.2 ERP
能耗響應時間乘積(ERP)被廣泛接受為獲得能耗-性能權衡的合適度量。它被定義如下
公式2
最小化ERP指標可被視為最大化"每焦耳上的性能"，性能被定義為每個時間單位上的作業(yè)量。
ERWS指標意味著，減少一個單位的平均響應時間與減少一個單位的平均能耗具有相同含義。相反的是，ERP指標是乘積，而不是將兩個完全不同比例的指標進行線性組合。換句話說，ERP指標不會受到不同比例帶來的比較上的影響。然而，由于ERP是兩個均值的乘積，在分析處理上會比較困難。
3.3.3 ERWP
為了克服上述的缺點，我們提出了一種名為能耗響應時間加權乘積的新指標，結合了ERWS和ERP的優(yōu)勢，它能夠很好地處理不同比例的指標，并且能夠有效地進行分析處理。ERWP指標在[29][30]引入，其定義如下:
公式3
我們將(3)式重寫如下嵌入式8，它繼承了ERWS指標的特點，可以為能耗和耗時賦予不同的權重，并且由于對數(shù)期望是會隨著時間的推移而增加的，因此該指標也易于分析。同樣的，在w=0.5的條件下，均值能耗和均值耗時將具有等價的影響，并且此時嵌入式9意味著ERWP指標擁有ERP指標的優(yōu)點，對不同的比例不敏感。
4 部分遷移模型
這一節(jié)，我們將分析具有服務退隊的部分遷移模型，這意味著任務一旦過期就會結束生命周期。我們首先基于網(wǎng)絡可用性模型制定分析模型，然后使用隊列分析來推導ERWP指標。
4.1 模型
圖3描繪了基于網(wǎng)絡可用性模型的延遲遷移模型。我們在兩階段(快與慢)馬爾可夫隨機環(huán)境中考慮一個調制的M/M/1隊列，并且處理延遲敏感性任務，即任務可能會中止遷移并在本地執(zhí)行。這些任務通過蜂窩連接或者WiFi網(wǎng)絡傳輸?shù)皆贫?。在兩種階段下振蕩的單服務隊列系統(tǒng)由Fon和Foff表示，意味著WiFi連接是可操作的。在該模型中，系統(tǒng)在任一階段的持續(xù)性都由一個隨機機制決定：如果系統(tǒng)當前在階段Fon，那么它會在一個平均時長嵌入式10的隨機時間內切換到階段Foff，如果當前在階段Foff，那么它會在平均時長嵌入式11的隨機時間后切換到另一個階段。我們假定到達系統(tǒng)的遷移任務服從參數(shù)為λ的泊松分布，那么調制過程嵌入式12決定了服務率
公式4
我們假定任務的平均大小是E(X)，快速階段(WiFi網(wǎng)絡)的傳輸率是sw，服務率是嵌入式13，它在服務任務時的耗能時pw，空閑時為0。相似的，慢速階段(蜂窩網(wǎng)絡)的對應傳輸速率為sc，服務率為嵌入式14，耗能為pc。在慢速階段，任務將變成延遲敏感類型。退隊時限Td在該階段與每項任務關聯(lián)。這就是說，一旦到達，每個任務都將激活一個獨立的計時器，該計時器服從退隊率r的指數(shù)分布。如果系統(tǒng)在任務到期前沒有將其環(huán)境從慢速階段改為快速階段，任務將從遷移隊列中被移除，并且假定在移動設備本地執(zhí)行，而不是遷移到云服務器上。
圖3表明該延遲遷移模型有三個隊列組成：遷移隊列(有兩個可交替的階段，蜂窩連接和WiFi連接)；表示移動設備上本地處理的本地隊列；表示在云上遠程處理的遠程隊列。
遷移隊列根據(jù)WiFi的可用性來互相地重置階段，從而更迭它的服務，WiFi由具有指數(shù)分布ON-OFF周期的可中斷泊松過程(IPP)控制。我們將間歇可用的WiFi熱點建模成一個偶爾服務器故障的FCFS隊列，既可能出現(xiàn)在WiFi網(wǎng)絡處理任務的On狀態(tài)，也可能出現(xiàn)在蜂窩網(wǎng)絡處理任務的OFF狀態(tài)(蜂窩連接假定持續(xù)可用)。然而，如果任務在蜂窩網(wǎng)絡中停留時間過長，那么它將退出遷移隊列，并在移動設備的本地執(zhí)行，如果一個任務在規(guī)定時限內完成了傳輸，該任務算是成功遷移。如果遷移失敗，任務將退出遷移隊列并加入本地隊列，以供本地處理，我們稱這樣的事件為退隊事件。
由于在進入服務之前沒有等待時間，云上的M/M/∞隊列有時被認為時延遲(有時是純延遲)站，延遲的概率分布就是服務時間的概率分布。
特別地，如果我們將服務率um和ur設置為∞，圖3的移動計算遷移模型將衰減為移動數(shù)據(jù)遷移，即對于到達的任務沒有進一步的執(zhí)行，所以，圖三中的隊列模型包括了移動計算遷移和移動數(shù)據(jù)遷移兩部分。
4.2 隊列分析
基于先前所做的假設，部分遷移模型可被建模成圖4中的2D馬爾科夫鏈。
具有蜂窩網(wǎng)絡的狀態(tài)表示為{c,i}，具有WiFi連接的狀態(tài)表示為{w,i}
參數(shù)i對應了系統(tǒng)中的任務數(shù)量(隊列或者服務中)。在WiFi階段，系統(tǒng)以uw的速率消耗，而在蜂窩階段，系統(tǒng)以uc+i*r的速率服務，因為這i個隊列任務中任一個都可能退出遷移隊列[20]。蜂窩和WiFi階段的平衡式如下
公式5a
公式5b
公式5c
公式5d
在某些WiFi不可用區(qū)域(僅有蜂窩連接)，訪問遷移系統(tǒng)的穩(wěn)態(tài)概率是嵌入式15。相似的，WiFi可用階段的穩(wěn)態(tài)概率是嵌入式16，等于可用率AR。
蜂窩和WiFi狀態(tài)的概率生成函數(shù)被定義為:
公式6
通過將((5C)和(5D))中i的每個表達式乘以z^n，并將這i個式子相應地求和并重新排列，我們可以得到
嵌入式17，其中嵌入式18。z1和z2是二次多項式嵌入式19，嵌入式20
4.2.1 一般情況
我們考慮圖3中描述的部分遷移模型，并假定退隊率r≠0.根據(jù)[32]，我們可以得到
公式7
公式8
我們可以定義嵌入式21，相應地，k1(z)和k2(z)表示如下
嵌入式22
通過定義k1(z),k2(z)和β(z)，得出T,U,V>0并且S<0。所以，Πc,0和Πw,0是正的。我們可以發(fā)現(xiàn)系統(tǒng)是可遍歷的。直觀上來講，如果我們設置參數(shù)λ≥0，μc≥0，μw≥0，ε＞0，η＞0并且Γ＞0，那么系統(tǒng)一直是穩(wěn)定的。中止過程，其總體速率隨著作業(yè)數(shù)量的增加而增加，防止了隊列長度的爆炸增長?；蛘哒f，系統(tǒng)只有在Πc,0和Πω,0為正并且其他參數(shù)都設置如上時才穩(wěn)定。
將μ定義如下μ=Πc·μc+Πω·μω，根據(jù)[32]，我們可以得到
公式9
公式10
如圖4所示，在慢速階段和快速階段每單位時間內的預期服務任務數(shù)量分別為嵌入式23和嵌入式24。因此，在慢速階段，由于任務的延遲敏感性而引發(fā)的中斷率可以給出
公式11
中斷率與蜂窩階段的退隊率和任務的平均數(shù)量成正比。
任務在移動設備上本地執(zhí)行的比率肯定等于中斷率，即嵌入式25。到達遷移隊列的任意任務離開并加入本地隊列的概率，即它將在本地執(zhí)行且不會被重新遷移的概率定義如下
公式12
Pr指的是概率操作符。
我們回想一下服務站的可用率表達如下：嵌入式26
4.2.2 一個極端的例子
當r->0時，圖3中間部分遷移模型將退化成圖5中的非延遲遷移模型。因為退隊率為0，因此該模型中沒有本地隊列。當網(wǎng)絡可用時，無論網(wǎng)絡質量如何，所有的任務都將立即遷移。由于可能會使用較差的網(wǎng)絡，該遷移模型會浪費能量[5]，并且與延遲遷移模型相比它做了分析。
將r設置為0解(5)中的方程組我們可得嵌入式27，嵌入式28并且可以證明g(z)在(0,1)上只有一個根z0。
經(jīng)過一些算術解析，我們可得
公式13
公式14
一旦πc,0和πw,0的值確定，概率生成函數(shù)就可以計算為:
公式15
公式16
假定嵌入式29，我們可以得到系統(tǒng)中的平均任務數(shù)量
公式17
4.3 基于指標分析
處理所有任務的能耗和耗時的總成本由遠程成本(將可遷移任務發(fā)送到云服務器，等待云服務完成任務計算并將計算結果返還給移動設備)以及本地成本(在移動設備本地執(zhí)行剩余的任務)。上行鏈路的傳輸引起的延遲通常主導了傳輸成本，因此我們忽略下行鏈路中的成本。
4.3.1 平均響應時間
根據(jù)Little定律，嵌入式30，平均響應時間可以計算如下
公式18
c,w,m,r分別代表了蜂窩網(wǎng)絡階段，WiFi傳輸階段，移動設備和遠程云服務。相應的，E[Nc]和E[Nw]分別是蜂窩網(wǎng)絡和WiFi網(wǎng)絡對應的平均任務數(shù)量，在(9)(10)中提到過。
由于本地隊列的到達率等于遷移隊列的中斷率，對于本地執(zhí)行而言，我們有嵌入式31。對于一個普通的M/M/1-FCFS隊列，移動設備的平均任務數(shù)量計算公式如下
公式19
其中嵌入式32是利用率。
對于一個M/M/∞隊列，由于進入云服務器上的遠程服務無須等待，遠程隊列的平均任務數(shù)量可計算如下
公式20
其中嵌入式33是遠程隊列的到達率。
4.3.2 平均能耗
我們假定每個服務器運作時以恒定功率pi操作，即移動設備只在系統(tǒng)中有計算任務時才消耗能量。因為嵌入式34是平均功耗，我們可以計算部分遷移模型的平均能耗，表達式如下:
公式21
在云服務器上遠程執(zhí)行的應用任務不會消耗本地設備的CPU。
相應的平均功耗計算表達式如下：
公式22
由于隊列的利用率是服務忙碌的概率，我們有嵌入式35，即能量消耗僅發(fā)生在服務器忙碌時。
由于本地執(zhí)行而消耗的能量取決于移動設備的處理速度，由于移動設備總是可用的，我們有
公式23
通過蜂窩網(wǎng)絡或WiFi網(wǎng)絡進行任務遷移而產(chǎn)生的平均能耗取決于傳輸?shù)墓呐c速率，我們有:
公式24
公式25
其中，pc和pw是蜂窩網(wǎng)絡和WiFi網(wǎng)絡的利用率，等價于對應網(wǎng)絡的繁忙率。根據(jù)圖4，他們可以被分別計算如下:
公式26
公式27
4.3.3 ERWP指標
能耗-響應時間加權乘積結合了加權乘積后的能耗指標與性能指標。我們的目標是最小化平均能耗和平均響應時間。更進一步的，通過將(18)和(23)代入(3)中，我們可以為延遲遷移模型顯式地制定ERWP指標：
公式28
我們的目標是尋找一個使得ERWP最小化的退隊率r*。請記住，退隊意味著延遲敏感任務放棄遷移并且切換到本地進行計算。
5. 完整遷移模型
這一小節(jié)我們將討論遷移所有計算任務的完整遷移模型?？赡艿脑捜蝿胀ㄟ^WiFi進行遷移，否則通過蜂窩網(wǎng)絡。
5.1 模型
如圖6所示，完整遷移模型包括兩個用于移動設備遷移的耦合隊列，即WiFi隊列和蜂窩隊列。這兩個隊列都由FIFO(先進先出)規(guī)則提供服務。所有達到系統(tǒng)的任務都默認由WiFi接口進行遷移。當任務使用WiFi網(wǎng)絡進行遷移時，由于WiFi鏈路的傳輸速度不穩(wěn)定，存在排隊現(xiàn)象。我們將WiFi熱點的間歇可用性建模成一個偶爾有服務宕機的FCFS隊列。服務器要么處于ON狀態(tài)處理存留任務，要么處于OFF狀態(tài)，不接收作業(yè)。我們假設在沒有WiFi連接期間，作業(yè)將退出隊列。
我們?yōu)槊恳豁椚蝿辗峙湟粋€退隊時限，該時限服從指數(shù)分布。任務根據(jù)它們距離時限的剩余時間(排隊時或處于隊首，但都在等待WiFi接口)以FCFS的順序調度。當WiFi隊列處于OFF狀態(tài)，任務會變成延遲敏感的，也就是說，每個任務，一旦到達，就會激活一個獨立的計時器，并且服從退隊率為r的指數(shù)分布。如果任務到期時網(wǎng)絡仍未將其環(huán)境由OFF狀態(tài)切換到ON狀態(tài)，該任務就將退出WiFi隊列，并被分發(fā)到蜂窩網(wǎng)絡上。如果WiFi隊列中的某個任務在到期之前就通過WiFi網(wǎng)絡傳輸完成，我們稱該作業(yè)成功遷移。如果遷移失敗，該任務將退出WiFi隊列并加入蜂窩隊列，以便通過蜂窩網(wǎng)絡立即傳輸，我們稱這種事件為一個退隊事件。
當任務通過蜂窩網(wǎng)絡傳輸?shù)皆品掌魃蠒r，由于蜂窩鏈路的傳輸速度不夠充足，可能會存在排隊現(xiàn)象。傳輸延遲(排隊和實際傳輸時間)與傳輸能耗方面的成本增加。因為蜂窩網(wǎng)絡總是存在，所以始終可以獲得一定程度上的服務。
遠程隊列是一個純延遲站，任務花費的時間服從均值為1/ur個單位時間的指數(shù)分布。
5.2 隊列分析
WiFi隊列是指通過WLAN網(wǎng)絡，將任務從移動設備遷移到云服務器上，該網(wǎng)絡被建模成一個提供間歇性可用服務的M/M/1-FCFS隊列。當故障服務器恢復時，將繼續(xù)為中斷服務提供服務，即已完成的任務不會丟失(參見數(shù)據(jù)傳輸恢復)[4]。我們做了常規(guī)但不那么切實際的假設，服務有時會失敗并且隨機時段后會恢復。WiFi隊列的馬爾可夫鏈如圖7所示，等價于在圖4中假設uc=0，πON=πw并且πOFF=πc。
具有WiFi連接的狀態(tài)表示為{ON, i}，沒有WiFi連接的狀態(tài)表示為{OFF, i}。在ON狀態(tài)下，系統(tǒng)以uw的速率服務，在OFF狀態(tài)下，以i·r的速率服務，因為i個排隊任務中任一個都有可能退出WiFi隊列。為這個鏈式編寫如下的平衡方程
嵌入式35
在將uc=0替換進k1(z)和k2(z)，得到
嵌入式36
根據(jù)[25]，我們可以得到
公式29
公式30
我們進一步有嵌入式37。將上述的表達式替換進(9)(10)中，可以得到WiFi隊列的平均任務數(shù)量為
公式31
公式32
所以，WiFi隊列的平均任務數(shù)量計算如下:
公式33
在圖7中，WiFi隊列的每單位時間內服務的預期任務量是嵌入式37。因此，在OFF期間由于延遲敏感而放棄的終止率為
公式34
其中終止率與OFF狀態(tài)下隊列中平均任務數(shù)量以及退隊率成正比。
發(fā)送給蜂窩網(wǎng)絡的任務比例必須等于終止率，即嵌入式38。到達WiFi隊列的任一作業(yè)將退出WiFi隊列的概率，即它將通過蜂窩網(wǎng)絡進行遷移的概率可以定義為
公式35
5.3 基于指標分析
這一節(jié)我們將在完整的遷移模型中推導出我們感興趣的指標，如平均響應時間、平均能耗以及兩者的指標的折中，能耗響應時間加權乘積。
5.3.1 平均響應時間
根據(jù)Little定律，嵌入式39，平均響應時間計算如下
公式36
其中E[Nw]是WiFi隊列中的平均任務數(shù)量(在(33)式中提到過)
蜂窩隊列是指通過蜂窩網(wǎng)絡將移動設備中的計算任務遷移到云服務器上，它被建模成一個M/M/1-FCFS隊列。因為蜂窩隊列的任務到達率等于WiFi隊列的任務終止率，即嵌入式40。該隊列中平均任務數(shù)量為：
公式37
其中嵌入式41是蜂窩隊列忙碌的概率。
因為所有的任務都將遷移到遠程的云服務器上，對于遠程云服務器傷的M/M/∞隊列而言，平均的任務數(shù)量可以計算如下
公式38
5.3.2 平均能耗
平均能耗計算如下
公式39
其中pw是可用WiFi處理任務的時間段，計算公式如下
公式40
如果覆蓋率嵌入式42，WiFi的可用率嵌入式43趨向于1.
5.3.3 ERWP指標
在我們的分析中，我們希望優(yōu)化ERWP指標，通過將(36)(39)代入到(3)中，我們可以將遷移分配的ERWP指標優(yōu)化表達式定義如下嵌入式44。
6 性能評估
在本節(jié)中，我們根據(jù)實際的遷移場景，使用之前提到過的延遲遷移模型并且比較了其分析結果。為了獲得真實的結果，我們從實驗中估算出模型參數(shù)。遷移過程包括了通信模型和遠程執(zhí)行模型，我們將進行一系列的實驗，以便在我們的模型中使用真實的通信參數(shù)。
6.1 移動網(wǎng)絡追蹤
實際無線網(wǎng)絡中的數(shù)據(jù)傳輸速率大多會隨時間而變化。它受信號質量變化以及其他用戶的影響。我們通過網(wǎng)絡和能量監(jiān)控在移動環(huán)境中收集真實的網(wǎng)絡記錄，并將這些記錄輸入到遷移模型中。
6.1.1 網(wǎng)絡監(jiān)控器
網(wǎng)絡監(jiān)控器收集無線連接狀態(tài)和可用帶寬的相關信息。它度量初始化時的網(wǎng)絡特性，并持續(xù)監(jiān)控環(huán)境變化。如[15]中所述，通過度量發(fā)送一定數(shù)據(jù)量所需要的時間，可以得到網(wǎng)絡的吞吐量。由于移動性質，無線連接的狀態(tài)可能經(jīng)常改變(例如，用戶移動到其他位置)。對于優(yōu)化器而言，獲取到關于無線連接的最新信息，對作出正確的遷移決策至關重要。
監(jiān)控器記錄了WiFi和3G接口的一些參數(shù)，包括每秒傳輸和接收的包，以及數(shù)據(jù)接收和傳輸速率。這些度量可以更好地估計當前網(wǎng)絡性能。
我們使用SpeedTest1來度量移動網(wǎng)絡帶寬。實際設備(參見表1)應用于具有各種移動通信網(wǎng)絡的移動云環(huán)境中。這里，我們度量如圖表2所示的具有代表性的場景下的無線帶寬分析。特別的，在2015年五月的某一周，我們帶著兩部配備有WiFi和蜂窩網(wǎng)絡接口的智能手機(小米紅米2和三星GalaxyS6)呆在室內或偶爾在校園中走動。此時間段內的數(shù)據(jù)已被采樣。
圖8和圖9繪制了度量過的移動網(wǎng)絡記錄。我們發(fā)現(xiàn)WiFi和蜂窩網(wǎng)絡(3G和LTE)的帶寬隨時間變化波動很大，并且難以預測。室內WiFi覆蓋情況良好，穩(wěn)定而快速。但是即便在相同的物理環(huán)境下，不同的移動設備也會記錄不同水平的傳輸速度。例如，三星S6在室內環(huán)境下的帶寬要比小米紅米2高得多。這是因為兩款設備配備了不同的硬件和軟件。用戶的移動性也對網(wǎng)絡連接的帶寬和質量又很大的影響。室外WiFi無線網(wǎng)絡信號強度很不穩(wěn)定，并且經(jīng)常出現(xiàn)間歇性連接，這使得它們有時可用有時不可用。相反，蜂窩網(wǎng)絡更加穩(wěn)定，并且提供了近乎全面覆蓋的連接。此外，與WiFi相比，蜂窩網(wǎng)絡可能會出現(xiàn)高延遲、高回傳(RTT)響應、緩慢的數(shù)據(jù)傳輸?shù)痊F(xiàn)象。我們注意到，在大多數(shù)設置下，下行鏈路的帶寬都要高出不少，有時會高出一大截。
6.1.2 能量監(jiān)控器
有兩種估算能耗的方法，軟件監(jiān)控或者硬件監(jiān)控。一些論文[11][36]使用了連接到智能手機電池上的功率計來建立能耗曲線。功能監(jiān)控器(例如，Monsoon監(jiān)控器)是一種，通過向移動設備提供一定程度的功率，來計量數(shù)據(jù)從移動設備傳輸?shù)皆品掌魃系哪芎谋O(jiān)控裝置。我們使用PowerTutor來計量應用的能耗。盡管PowerTutor不能像硬件能耗監(jiān)控器那樣提供準確的結果，但它提供的結果仍是合理的，并能為我們提供一些見解。PowerTutor為每個硬件組件都提供了詳細的能耗信息。
在圖10中我們可以看到能耗和傳輸時間都與傳輸文件的大小成比例地增加。傳輸?shù)攘康臄?shù)據(jù)，WiFi要比3G耗能更少，此外，設備通過每個通信網(wǎng)絡的能耗與其傳輸時間成比例。
6.2 數(shù)值分析
這本節(jié)中，我們將首先從實驗預測結果中推導出所需的參數(shù)，然后我們將使用這些參數(shù)分析模型。
不同的無線網(wǎng)絡接口在很多方面都有所不同，我們需要通過一些參數(shù)來簡單的刻畫這些不同。根據(jù)上文收集到的移動數(shù)據(jù)記錄，我們考慮一個簡單的場景，蜂窩網(wǎng)絡的傳輸率低于WiFi的傳輸率，即sc<sw，并且傳輸任務通過蜂窩鏈路的能耗要高于WiFi鏈路，即pc>pw。使用[5]中的實際度量記錄，將蜂窩網(wǎng)絡和WiFi網(wǎng)絡的平均數(shù)據(jù)比率設置成sc=200Kbps, sw=2Mbps。WiFi可用階段的平均持續(xù)時間為52分鐘(嵌入式45)，只有蜂窩網(wǎng)絡覆蓋階段的平均持續(xù)時間為25.4分鐘(嵌入式46)。因此可用率為67%。平均作業(yè)大小假設為10Mb。根據(jù)[37]的能耗模型，我們將功率系數(shù)分別設置為pc=2.5W, pw=0.7W, pm=2W。此外，假定總體的任務到達率是嵌入式47，移動服務率為嵌入式48，云服務率為嵌入式49。
我們首先分析了兩個延遲遷移模型的退隊概率。[38]中的可用率為11%。圖11顯示了，隨著WiFi網(wǎng)絡可用率增長，放棄遷移隊列(用于部分遷移模型，參見圖11a)或WiFi隊列(用于完整遷移模型，參見圖11b)的任務比例迅速下降。然而，在相同的時限Td下，完整遷移模型有比部分遷移模型高得多的退隊率(放棄遷移)。這可以用以下事實來解釋:部分遷移模型可以使用蜂窩網(wǎng)絡來傳輸數(shù)據(jù)，因此減少了遷移隊列中等待的作業(yè)數(shù)量。另一方面，如果將退隊時限延后1～2小時，任務更有可能通過WiFi網(wǎng)絡傳輸，因此，在任務到達率較低的情況下，退隊概率會越低。然而，在任務到達率較高的情況下，無論時限如何，退隊的概率都將保持不變。
平均響應時間包含了排隊時間以及服務時間。從圖12a中我們可以看出，部分遷移模型具有最低的平均響應時間，因為它在WiFi不可用時充分利用了慢速階段的蜂窩網(wǎng)絡。在更低的時限(Td<40分鐘)條件下，平均響應時間隨著時限的增加而減少，因為具有更長時限的任務更有可能通過WiFi網(wǎng)絡進行傳輸，從而導致了它較短的響應時間。然而在較高的時限條件下，平均響應時間會增加，因為具有較低時限的任務可以更快地李靠隊列，導致了較小的排隊延遲，從圖12b中我們可以看出，當退隊時限較小時，非延遲遷移模型在三者中的平均能耗最小，但隨著時限增長，完全遷移模型效果越來越好。這是因為WiFi網(wǎng)絡要比蜂窩網(wǎng)絡更加的迅速且高效。節(jié)約下來的服務時間可用為移動設備降低能耗。
請注意，退隊率的倒數(shù)對應于平均時限。因此在圖12a中的最短時限(約40分鐘)對應到了圖13a中ERWP的最小值(0.025)。
不同的應用通常對能耗和性能的關注度不同。我們使用ERWP指標，根據(jù)能耗和性能的權衡來比較三種不同的遷移模型。從圖13a中我們可以觀察到，當w很小時，部分遷移模型可以通過選擇最佳的退隊率r來實現(xiàn)最小的ERWP值。這表明當考慮響應時間更多一點時，最好選用部分遷移模型，相反，當考慮能耗更多一點時，應該選擇完整遷移模型。后者將從快速WiFi網(wǎng)絡節(jié)省下來的傳輸時間轉化為移動設備更低的電量消耗。如圖13b所示，當權重參數(shù)w很小時，隨著可遷移任務到達率的增長，三個遷移模型的效果都變差了。然而，非延遲遷移模型對任務到達率更加敏感。部分遷移模型總是可以達到最低的ERWP值。意味著當更加考慮響應時間時，最好用部分遷移模型，相反的，當更加考慮能耗是，應該在任務到達率較低時使用完整遷移模型。當任務到達率較高時，根據(jù)ERWP指標我們更應當使用非延遲遷移模型。
我們將退隊時限設置成2個小時并比較平均響應時間和平均能耗在任務到達率不同條件下的表現(xiàn)。如圖14a所示，由于排隊影響，平均響應時間隨著任務到達率的增長而增長。部分遷移模型的效果要比其他兩個模型個好很多，因為它在WiFi不可用階段充分使用了蜂窩網(wǎng)絡來遷移計算任務，而這反過來導致了圖14b中的高能耗。當任務到達率較低時，完整遷移模型要比非延遲遷移模型更加節(jié)能高效，而在任務到達率較高時，非延遲遷移模型更能節(jié)能。從圖11b中可以看到，隨著任務到達率的增長，更多的任務將終止WiFi隊列的排隊。這些任務隨即通過蜂窩網(wǎng)絡傳輸，導致了更多的能耗。
6.3 遷移實驗
為了驗證我們從上述模型分析中得出的見解，我們使用不同的時限以及不同的連接場景進行實驗。在該實驗中我們進行了如下的真實設置:一條預設置好的路徑，在此期間我們遵循預定好文件大小的文件傳輸隊列。我們在Google Nexus 5設備上進行了一系列實驗，每輪實驗都有不同的時限。目標是使用不同是時限，在不斷變化的WiFi覆蓋情況下測量大小的文件的上傳性能和能耗使用狀況。
步行路線可以在圖15中看到，路段用不同的顏色標記WiFi可用性，其中綠色部分表示W(wǎng)iFi可用，紅色部分表示沒有WiFi可用。發(fā)生文件上傳的位置在圖中用數(shù)字標記。相應的計算文件大小如下:50MB, 1MB, 10MB, 1MB, 10MB, 50MB。路程為5km，步行的平均速度為5.5km/h，步行持續(xù)了55分鐘。我們使用了幾組不同的延遲進行實驗:無延遲，30秒，30分鐘。
圖16展示了不同實驗組里耗電量隨時間的變化。這是主要的性能評估指標，因為延遲遷移的主要目標就是降低能耗。x軸顯示了相對于測試開始的以秒為單位的時間。均一化的耗電量在y軸上以百分比表示。在圖表頂部顯示了上傳的文件及其相應的文件大小以及WiFi可用性(藍色=可用，紅色=不可用)。這是一組不受干擾的實驗，表明了增長時限會降低能耗。以30秒的時限為例，第一次上傳10MB文件的30秒后電池容量明顯下降，這清楚地展現(xiàn)了3G接口的高能耗。
7 總結
在該篇論文中，我們開發(fā)了用于延遲移動云遷移的分析型隊列模型，通過選擇用于遷移的異構無線接口來實現(xiàn)WiFi網(wǎng)絡和蜂窩網(wǎng)絡的優(yōu)勢互補。我們基于ERWP指標對移動云遷移系統(tǒng)的能耗-性能權衡問題進行了最優(yōu)分析。該指標挖掘了能耗和性能的特征，我們的分析甚至包含了間歇性可用的訪問鏈路。
我們發(fā)現(xiàn)，當WiFi網(wǎng)絡的可用率(AR)相對較低時，放棄排隊的作業(yè)比例非常高。我們通過優(yōu)化ERWP指標來優(yōu)選退隊時限，以時限不同的能耗-性能權衡。對于延遲敏感的應用，當設置了一個適中的時限時，我們首選部分遷移模型，而對于延遲容忍應用而言，完全遷移模型效果更好，并且當時限較大時要優(yōu)于其他遷移模型。大體上我們認為，部分遷移策略更快，完整遷移模型更節(jié)能。
在優(yōu)化能耗時，完整遷移模型即使在時限非常長時效果也是最好的。只有當任務的響應時間高優(yōu)時，才能獲得ERWP指標權衡的合理結果。然后，可以在部分遷移模型中找到終止遷移的最佳時限，相應的，在完整遷移模型中找到終止WiFi傳輸?shù)淖罴褧r限。為了減少能耗，最好將等待時間放長，而不是在本地計算或者使用蜂窩網(wǎng)絡。我們所提出的隊列模型可用于描述復雜而逼真的遷移系統(tǒng)。
參考文獻
[1] M.-R. Ra, J. Paek, A. B. Sharma, R. Govindan, M. H. Krieger, and M. J. Neely, “Energy-delay tradeoffs in smartphone applications,” in Proc. 8th Int. Conf. Mobile Syst. Appl. Services, 2010, pp. 255–270.
[2] M. H. Cheung and J. Huang, “Dawn: Delay-aware Wi-Fi offload- ing and network selection,” IEEE J. Sel. Areas Commun., vol. 33, no. 6, pp. 1214–1223, Jun. 2015.
[3] K. Lee and I. Shin, “User mobility-aware decision making for mobile computation offloading,” in Proc. IEEE 1st Int. Conf. Cyber- Phys. Syst. Netw. Appl., 2013, pp. 116–119.
[4] E. Hyyti€a, T. Spyropoulos, and J. Ott, “Offload (only) the right jobs: Robust offloading using the Markov decision processes,” in Proc. IEEE 16th Int. Symp. World Wireless Mobile Multimedia Netw., 2015, pp. 1–9.
[5] K. Lee, J. Lee, Y. Yi, I. Rhee, and S. Chong, “Mobile data offload- ing: How much can WiFi deliver?” IEEE/ACM Trans. Netw., vol. 21, no. 2, pp. 536–550, Apr. 2013.
[6] F. Mehmeti and T. Spyropoulos, “Performance analysis of “on- the-spot” mobile data offloading,” in Proc. IEEE Global Commun. Conf., 2013, pp. 1577–1583.
[7] F. Rebecchi, M. D. De Amorim, V. Conan, A. Passarella, R. Bruno, and M. Conti, “Data offloading techniques in cellular networks: A survey,” IEEE Commun. Soc. Commun. Surveys Tuts., vol. 17, no. 2, pp. 580–603, Apr.–Jun. 2015.
[8] M. Satyanarayanan, P. Bahl, R. Caceres, and N. Davies, “The case for VM-based cloudlets in mobile computing,” IEEE Pervasive Comput., vol. 8, no. 4, pp. 14–23, Oct.–Dec. 2009.
[9] S. Ou, K. Yang, A. Liotta, and L. Hu, “Performance analysis of off- loading systems in mobile wireless environments,” in Proc. IEEE Int. Conf. Commun., 2007, pp. 1821–1826.
[10] R. Wolski, S. Gurun, C. Krintz, and D. Nurmi, “Using bandwidth data to make computation offloading decisions,” in Proc. IEEE Int. Symp. Parallel Distrib. Process., 2008, pp. 1–8.
[11] E. Cuervo, et al., “MAUI: Making smartphones last longer with code offload,” in Proc. 8th Int. Conf. Mobile Syst. Appl. Services, 2010, pp. 49–62.
[12] K. Kumar and Y.-H. Lu, “Cloud computing for mobile users: Can offloading computation save energy?” Comput., vol. 43, no. 4, pp. 51–56, 2010.
[13] D. Huang, P. Wang, and D. Niyato, “A dynamic offloading algo- rithm for mobile computing,” IEEE Trans. Wireless Commun., vol. 11, no. 6, pp. 1991–1995, Jun. 2012.
[14] W. Zhang, Y. Wen, and D. O. Wu, “Energy-efficient scheduling policy for collaborative execution in mobile cloud computing,” in Proc. IEEE INFOCOM, 2013, pp. 190–194.
[15] B.-G. Chun, S. Ihm, P. Maniatis, M. Naik, and A. Patti, “Clonecloud: Elastic execution between mobile device and cloud,” in Proc. 6th Conf. Comput. Syst., 2011, pp. 301–314.
[16] L. Wang and M. Franz, “Automatic partitioning of object-oriented programs for resource-constrained mobile devices with multiple distribution objectives,” in Proc. 14th IEEE Int. Conf. Parallel Dis- trib. Syst., 2008, pp. 369–376.
[17] L. Lei, Z. Zhong, K. Zheng, J. Chen, and H. Meng, “Challenges on wireless heterogeneous networks for mobile cloud computing,” IEEE Wireless Commun., vol. 20, no. 3, pp. 34–44, Jun. 2013.
[18] A. Rahmati and L. Zhong, “Context-for-wireless: Context- sensitive energy-efficient wireless data transfer,” in Proc. 5th Int. Conf. Mobile Syst. Appl. Services, 2007, pp. 165–178.
[19] P. Shu, et al., “eTime: Energy-efficient transmission between cloud and mobile devices,” in Proc. IEEE INFOCOM, 2013, pp. 195–199.
[20] F. Mehmeti and T. Spyropoulos, “Is it worth to be patient? Analy- sis and optimization of delayed mobile data offloading,” in Proc. IEEE INFOCOM, 2014, pp. 2364–2372.
[21] H. Deng and I.-H. Hou, “Online scheduling for delayed mobile off- loading,” in Proc. IEEE Conf. Comput. Commun., 2015, pp. 1867–1875.
[22] H. Wu, Q. Wang, and K. Wolter, “Tradeoff between performance improvement and energy saving in mobile cloud offloading sys- tems,” in Proc. IEEE Int. Conf. Commun. Workshops, 2013, pp. 728–732.
[23] H. Wu and K. Wolter, “Dynamic transmission scheduling and link selection in mobile cloud computing,” in Analytical and Stochastic Modeling Techniques and Applications. Berlin, Germany: Springer, 2014, pp. 61–79.
[24] H. Wu and K. Wolter, “Tradeoff analysis for mobile cloud offload- ing based on an additive energy-performance metric,” in Proc. 8th Int. Conf. Perform. Eval. Methodologies Tools, 2014, pp. 90–97.
[25] F. Mehmeti and T. Spyropoulos, “Performance analysis of mobile data offloading in heterogeneous networks,” IEEE Trans. Mobile Comput., vol. 16, no. 2, pp. 482–497, Feb. 2017.
[26] V. Cardellini, et al., “A game-theoretic approach to computation offloading in mobile cloud computing,” Math. Program., vol. 157, no. 2, pp. 421–449, 2016.
[27] Y. Kim, K. Lee, and N. B. Shroff, “An analytical framework to characterize the efficiency and delay in a mobile data offloading system,” in Proc. 15th ACM Int. Symp. Mobile Ad Hoc Netw. Com- put., 2014, pp. 267–276.
[28] A. Gandhi, V. Gupta, M. Harchol-Balter, and M. A. Kozuch, “Optimality analysis of energy-performance trade-off for server farm management,” Perform. Eval., vol. 67, no. 11, pp. 1155–1171, 2010.
[29] H. Wu, W. Knottenbelt, and K. Wolter, “Analysis of the energy- response time tradeoff for mobile cloud offloading using combined metrics,” in Proc. 27th Int. Teletraffic Congr., 2015, pp. 134–142.
[30] H. Wu and K. Wolter, “Analysis of the energy-performance trade- off for delayed mobile offloading,” in Proc. 9th Int. Conf. Perform. Eval. Methodologies Tools, 2015, pp. 250–258.
[31] S. Balsamo, G.-L. dei Rossi, and A. Marin, “Queueing networks and conditional product-forms,” in Proc. 7th Int. Conf. Perform. Eval. Methodologies Tools, 2013, pp. 204–213.
[32] N. Perel and U. Yechiali, “Queues with slow servers and impatient customers,” Eur. J. Oper. Res., vol. 201, no. 1, pp. 247–258, 2010.
[33] U. Yechiali, “Queues with system disasters and impatient custom- ers when system is down,” Queueing Syst., vol. 56, no. 3–4, pp. 195–202, 2007.
[34] U. Yechiali and P. Naor, “Queuing problems with heterogeneous arrivals and service,” Operations Res., vol. 19, no. 3, pp. 722–734, 1971.
[35] S. Kosta, A. Aucinas, P. Hui, R. Mortier, and X. Zhang, “Thinkair: Dynamic resource allocation and parallel execution in the cloud for mobile code offloading,” in Proc. IEEE INFOCOM, 2012, pp. 945–953.
[36] J.-A. Hong, S. Seo, N. Kim, and B.-D. Lee, “A study of secure data transmissions in mobile cloud computing from the energy con- sumption side,” in Proc. Int. Conf. Inf. Netw., 2013, pp. 250–255.
[37] N. Balasubramanian, A. Balasubramanian, and A. Venkatara- mani, “Energy consumption in mobile phones: A measurement study and implications for network applications,” in Proc. 9th ACM SIGCOMM Conf. Internet Meas. Conf, 2009, pp. 280–293.
[38] A. Balasubramanian, R. Mahajan, and A. Venkataramani, “Augmenting mobile 3G using WiFi,” in Proc. 8th Int. Conf. Mobile Syst. Appl. Services, 2010, pp. 209–222.
