近距離移動智能終端的協同計算機制

宋崢　EliTilevich

摘要：提出使用智能移動設備之間的本地化協作彌補“云—端”協作的缺陷，可以以極低的成本實現設備性能的提升，降低設備網絡通信和能量消耗。針對智能設備本地化協作中面臨的設備異構性的問題，提出了一種解釋型語言和相應中間件支持，用于開發智能終端間的協作應用，并對協作應用提供運行時的支持。另外，還提出了移動智能設備協作領域面臨的開放性研究的一些問題。

關鍵詞： 移動智能設備的協作； 設備異構性； 資源查詢語言和中間件

移動智能終端被用來泛指人生活中使用的，具有一定人機交互能力、計算能力、網絡連接能力的電子設備。目前移動智能設備種類繁多，功能也日益分化，包括以滿足人日常通信和網絡連接需求為主的智能手機；電量較多、屏幕較大且方便閱讀、處理器性能更強的平板電腦；以傳感器信息采集目的為主的穿戴式設備；以及各種用于家居、工業的片上系統以及車載終端等。

移動智能終端的常見特征是體積較小，由電池供電。由于設備體積限制，移動智能終端往往無法采用高功耗高性能的芯片，且電池電量有限。因此，對移動設備上所執行任務的用戶等待時間和電量消耗的優化一直是移動計算中較為重要研究方向之一。

1 云—端計算

“云—端”計算[1]是近年來的研究熱點方向，其具體含義是：通過將計算量大的程序上傳到遠程性能強大的服務器（云）執行，將結果回傳至本地設備（端）顯示。以智能終端棋類游戲的人機對弈為例：終端上傳目前所有棋子的位置，服務器端負責計算優化的下一步選擇，將最優的下一步策略回傳至本地。通過將復雜的計算上傳至云端計算性能強大的服務器執行，移動設備可以節省能量消耗，并降低用戶的等待時間。

云—端計算在實際應用中，往往通過在服務器端啟動與本地環境操作系統相同的虛擬機，將本地應用中的代碼傳輸至云端執行[2]。該實現機制使移動應用的開發者不需要考慮復雜的部署問題和服務器端程序開發，通過簡單的操作即優化移動應用的響應速度和能量消耗。

然而，云—端計算有如下缺陷：

（1）本地傳感器信息的收集無法由遠程服務器端執行。當程序中含有獲取傳感器信息并進一步處理時，由于云無法獲取本地的感知信息，此類程序無法上傳至云執行。

（2）當程序處理對象數據龐大時候，上傳至云處理會消耗大量網絡資源。如需要上傳的數據是高清圖像時，其將占據大量的網絡帶寬，給用戶造成使用成本的提高，為運營商網絡造成壓力。文獻[3]中對云端執行的能量進行了建模，推導出計算量、上傳數據量與能耗變化的關系，證明了當上傳數據較大時，云— 端計算會消耗大量用戶帶寬和能量。

（3）出于對隱私的考慮，部分用戶擔心通過不安全的無線網絡將隱私的數據上傳至云服務器上會極大增加隱私泄露的風險。

與此同時，隨著移動智能終端性能和擁有量不斷提升，大量智能移動終端存在空閑時隙，個人、家庭往往同時擁有多個、多種類的移動設備，云—端計算可被智能移動終端的互相協作所替代，為移動設備提供所需要的額外資源。

2 移動智能終端協同的應用

2.1 網絡增強

視頻流協作共享[4]最早在2012年提出：當位置接近的移動設備請求同一視頻時，服務器將視頻切分成幾部分，分別發送給各個設備，然后由設備間由近距離傳輸方式互相傳輸所缺少的視頻切片，組成視頻。這樣做的優點是：網絡總體流量較小，且近距離Wi-Fi/藍牙傳輸速度相對于運營商網絡較快，降低了網絡負載，減少了用戶等待的時間。

從節省能耗的角度，文獻[5]中提出使用藍牙網絡，由簇頭結點收集近距離網絡數據包，并通過無線局域網絡（WLAN）發送至互聯網。該方法相比于各個結點獨立通過WLAN連接互聯網而言，降低了各結點用于網絡數據傳輸的能量消耗。

部分移動設備并不具備有運營商網絡（3G/4G）接入能力，網絡數據的共享尤為重要。文獻[6]中提出了使用藍牙進行組網，通過Wi-Fi發送數據流，由有運營商網絡接入能力的設備作為其他設備的代理。

2.2 計算能力增強

如某人想從手機相冊中搜索和某人的合影。由于圖像檢索計算量較大，當手機中照片數量較多時，檢索會消耗大量時間。如通過3G/4G網絡將圖像發送至云端進行檢索，則需要消耗大量網絡帶寬費用和能耗。此時，如能通過Wi-Fi將相冊中圖像分發至此人所攜帶的pad或筆記本電腦上，由計算性能較強的多個設備同時執行圖像檢索任務，將大大縮短任務的執行時間，如圖1所示。

2.3 環境相關增強

谷歌、蘋果等眾多公司均推出了智能手表、智能手環、智能眼鏡等穿戴式設備，其不同于智能手機等傳統移動終端的重要作用是可以收集用戶環境數據感知。通過連接其他移動智能終端和穿戴式設備，可將穿戴式設備中采集的數據交給移動智能終端進行數據處理分析，其較為典型的例子是Apple Watch將慣性傳感器信息傳遞給手機，用手機應用收集用戶的每日運動信息。另一個可能的例子是，目前室內定位多采用記步方式：手機可準確提取用戶運動的步數，然而手機所攜帶的方向傳感器往往會引入偏差。由于智能眼鏡能準確體現人頭部的運動，而人頭部的方向基本與人運動方向一致，通過收集智能眼鏡中攜帶的方向傳感器的讀數可以提高室內記步定位方式的精度。從能量的角度考慮，可以由手機向智能眼鏡提供全球定位系統（GPS）信息（如圖2）。

相同的移動智能設備，由于所處的位置不同，也存在相互協作的可能性。其較為典型的例子是：當演唱會上觀眾想從其他角度觀看一些當前角度無法看到的細節時，可以通過與其他觀眾的手機合作，使用Wi-Fi/藍牙分享其他手機所捕獲的畫面[7]。另一個例子是：使用多個手機，對用戶演講的聲音進行采集，并合成為立體聲[8]。

3 移動智能終端協同中間件

3.1 移動應用對中間件和解釋型語言

的需求

相比于傳統云—端計算而言，近距離設備間協作的特點如下：

（1）通信復雜。與傳統的使用網絡連接的程序不同，使用近距離協作的程序其可選通信方式多樣，通信流程較為復雜，且通信過程受到的影響因素較多。

（2）任務執行需跨平臺。目前銷量最大的智能終端包含3種操作系統：安卓、iOS和WinPhone。不同操作系統之間編程語言、系統調用差異比較大。

（3）任務執行需根據動態環境進行優化。程序執行時，需要根據周圍環境（信道質量，設備數量，設備情況，設備移動性）進行大量優化，保證執行可靠性和執行效率。

在上述典型應用中，部分應用的實現機制已在其論文中有所介紹。然而，通過對已經公開的實現機制進行研究，我們發現絕大部分實現需要復雜的代碼對通信進行控制，且所有實現均局限于相同操作系統設備間的協作。

為了方便應用開發人員使用周圍設備所提供的資源開發新型應用，我們提出了一種設備協作的語言和對該語言支持的中間件，即程序員通過一種聲明式的語言，用簡單的腳本表達需要完成的任務；中間件接受各種應用的資源需求腳本，屏蔽不同操作系統、通信方式和執行時環境的差異，向周圍設備提供盡可能穩定的共享資源，完成共享任務。

3.2 資源查詢語言的設計

我們提出了一種用于臨近設備協作的解釋型程序設計語言——資源查詢語言（RQL）。RQL的存在有兩個作用：應用程序通過RQL通知系統中間件所需要的資源；原移動終端通過RQL通知附近移動終端其資源需求。對應其功能，RQL的設計需要滿足3個需求：

（1）跨平臺性。可運行于不同的平臺上，并切入不同語言構建的移動應用中。

（2）可擴展性。隨著設備計算存儲和感知能力的增強，將會出現越來越多的依賴于RQL執行的任務。因此，RQL的設計要求其易于擴展。

（3）簡短。由于RQL同時被用于設備間任務信息的傳輸，我們對RQL的設計要求可以盡量簡短，以節約傳輸時間和臨近設備上的執行時間。

我們對RQL的設計構想如下：某一句RQL腳本由動詞、名詞和副詞組成。其中動詞表示執行的操作，目前包含pull、push、exec和bind。其中pull代表將文件發送至所選擇設備；push表示將文件（或者運行結果）發回至原設備；exec表示在協助的其他設備上執行，bind表示等待協助設備上某值的更新，并將更新的數值發送回原設備。名詞由[device owner/][device_type：/]resource_type/resource_name組成。其中，device_owner和device_type均為可選，供程序員設置需要的設備的擁有者和設備的類型；Resource_type和resource_name為必選項，用于標示用戶所需要的資源類型和資源名字。副詞用于表示用戶優化的目標和限制等。

以如下兩個應用為例，來說明RQL在移動協作應用中的使用方式。

（1）當某應用運行在智能眼鏡上，需要得到30 s內所有的GPS位置的變化，并實時將位置顯示在地圖上。由于目前智能眼鏡設備并沒有嵌入消耗大量電量的GPS芯片，該應用需要從眼鏡攜帶者所擁有的其他移動設備中獲得GPS讀數。此應用開發者所需要寫的RQL腳本是：

“Bind trusted：sensor/Location-accuracy= GPS-t=30 --opt=accu”

其中，bind表達等待協助設備上數據更新；-t=30表示執行時間為持續30s；sensor/Location表示需要的傳感器類型；trusted表明計劃選擇可信的設備（同一個人擁有的，或者臨近認識的人所擁有的設備），副詞--opt=accu表示優化目標為使收到的GPS盡量準確。

（2）如2.2中所述例子，當應用開發者希望從相冊中檢索含有某特定特征的圖像時，其RQL腳本應為：“pull alg/facerecognization-t album/1.jpg-s target.jpg -- opt=time”，

其中，pull代表將執行結果返回至當前設備；alg/facerecognization代表所執行的算法；-s， -t代表算法的輸入；--opt=time表明優化目標為最小化執行時間。

3.3中間件的設計

為了按應用開發者的意愿執行RQL腳本，為應用程序提供所需要的資源，需要在不同的平臺上部署中間件，實現對RQL的支持。中間件的基本流程如圖3所示，其中，中間件的主要任務包括：

（1）解釋RQL腳本。應用程序通過設備內通信（ICC）將RQL語言發送至中間件，由中間件中RQL腳本解釋器對腳本進行詞法分析，并校驗RQL的有效性。對于有效RQL腳本，在本地中間件新建任務，加入任務隊列中。

（2）任務廣播和目標設備選擇。根據RQL腳本的語義，選擇最符合要求通信信道廣播任務，并接受周圍設備的反饋，完成從有反饋的設備里選擇目標設備的流程。以上文所述RQL腳本為例，由于任務1執行設備（device_owner）部分選擇了trusted，而可信任設備往往由同一人所同時攜帶（某人既戴智能眼鏡，又攜帶智能手機），因此此時廣播信道可選擇低功耗藍牙廣播（BTLE）；由于任務2目標是優化執行速度，且對任務執行的設備無要求，因此廣播信道可選擇WiFiP2P廣播，以盡可能獲得更多設備完成相關任務。

當其他設備上的中間件通過周期性對藍牙信道和WiFiP2P信道的監聽得到任務需求廣播時，其根據自身設備的實時屬性（設備使用情況，剩余電量）以及用戶設置權限，選擇是否回復該任務。

一段時間后，原設備收集所有回復，并從回復中選擇合適的一個或多個設備執行任務。這里需要說明的是，為了防止本地多個任務的發布和回復互相干擾，廣播和回復時均包含任務隊列中的任務ID。

（3）建立連接，執行任務，回傳結果。被選擇用于任務執行的智能移動終端與原設備建立連接，并接受完整的RQL以及任務相關數據，如文件、照片等。通過中間件所下載/保存的相關程序包執行該任務，并將結果通過通信信道回傳給原始設備的中間件。原始設備的中間件通過設備內通信方式通知原始程序。

3.4 中間件實現中存在的問題

目前存在的三大主流移動終端操作系統包括安卓、iOS和Windows。其中，安卓系統允許中間件啟動后作為后臺進程，對周圍環境中可能存在的任務需求進行監聽。相反，由于iOS系統和Windows系統限制，可以在后臺運行的程序僅包括Calendar/mp3 player等，RQL的中間件無法在后臺監聽通信信道廣播的其他設備的協作請求。

一種可能的替代方案是所有設備均定期上傳位置至某控制服務器。當某設備有任務協作需求時，將需求通過網絡發送至控制服務器，由控制服務器選出在近距離通信范圍內的設備，向其推送通知。當iPhone和WinPhone接到通知時，會在任務欄提醒用戶，由用戶啟動中間件，完成后續任務代理流程。然而，該方法由于需要定期位置上傳，將帶來較大的額外能量消耗。

4 移動終端協作的開放性

研究問題

4.1 能耗和用戶響應時間的平衡

近距離傳輸的移動智能設備的協作，重要目的之一是節省移動終端的能量消耗，即通過將能耗較高的程序轉移至有較多電量的設備上運行，或者分散到多個設備上運行，降低對某單一設備的能量消耗。然而，相比于在設備上直接運行而言，設備間的協作需要建立連接，需要發送原始數據并將結果回傳，其時間消耗往往高于在設備上直接運行。

因此，這里需要對程序運行能耗，設備剩余能量以及程序運行時間和用戶滿意度的影響進行建模，在最大化降低能耗的同時，盡可能避免程序運行時間的快速增長，提高用戶們滿意度。

4.2 通信信道的選擇

使用Wi-Fi通信可以覆蓋較大的范圍（50～100 m），并可以將任務發布至盡可能多的設備。相比而言，低功耗藍牙通信覆蓋范圍較小（10～20 m）[10]，所能連接的設備數較少。因此，當發布任務需要多個設備協作完成時，應盡可能選擇Wi-Fi作為通信信道。另一方面，從文件傳輸角度來看，Wi-Fi的傳輸速度遠遠大于低功耗藍牙（BTLE）的傳輸速度。當有大量數據需要在兩個設備間傳輸時，選擇Wi-Fi作為通信信道較優。

然而，從能量角度而言，保持Wi-Fi連接的能耗遠遠大于保持低功耗藍牙連接的能耗。當任務為保持連接較長時間，實時獲得傳感器采樣時，選擇藍牙作為傳輸信道較優。

RQL僅僅代表了用戶對資源的需求，并未指定傳輸方式。在實際任務執行時，應根據周圍環境、設備信息以及任務要求和副詞所表達的約束條件以及 優化條件，選擇最優化的通信信道。

4.3 激勵機制

由于參與近距離協作的設備不僅僅包括同一持有人的設備，針對陌生設備，還需要通過制訂一定的激勵，鼓勵其共享資源，為周圍設備提供幫助。根據文獻[9]中的相關建議，有效的激勵機制需要滿足的條件包括：鼓勵用戶匯報真實成本和收益；用戶參與的激勵大于其消耗成本；任務分發者的收獲大于其付出的激勵。

RQL僅僅代表了用戶對資源的需求，并未指定傳輸方式。在實際任務執行時，應根據周圍環境、設備信息以及任務要求和副詞所表達的約束條件以及優化條件，選擇最優化的通信信道。目前參與式感知中的激勵機制是研究熱點，然而，缺乏在沒有中央服務器的控制下各設備獨立協作的激勵機制。

4.4 隱私保護與安全

設備協作中遇到的隱私保護和安全的問題是雙向的：如何保證原設備的隱私數據不泄露至周圍設備；如何保證任務承擔設備的隱私數據不被收集至原設備。為了確保用戶隱私信息不被泄露，可以考慮采用分級安全機制[11]：作為協助其他設備的設備而言，把任務發布者分為幾個級別，為每個級別設置每種傳感器、數據以及算法的使用權限；作為發布任務的設備而言，把可能的任務接受者也劃分為幾個級別，將不同的原始數據為每個級別設置不同的讀寫權限。

4.5 最優化設備選擇

由于設備的異構性和移動性，在任務執行時，選擇不同的設備執行任務往往在能量消耗、任務的魯棒性、響應時間等方面產生不同的結果。一個可能的研究問題是：考慮到設備的性能、狀態和移動性，如何選擇最優化的設備或者設備組合，最小化任務執行的能量消耗，提高任務執行的魯棒性，降低任務的傳輸時間。

4.6 云—端計算與本地化設備協作

之間的選擇

云—端計算利用服務器資源，適用于大計算量、小數據傳輸量的應用，其典型應用是文字翻譯和下棋。本地化設備協作更適用于需要本地化傳感信息的應用或數據傳輸量較大的應用。如何根據任務的計算量、數據傳輸量和對本地傳感器的使用情況，結合設備狀態信息，作出對協同目標的選擇（服務器或附近的移動設備）也是一個重要的優化問題。

5 結束語

移動智能終端性能有限，傳統的改進方式是將任務上傳至服務器端執行。然而，由于傳統云—端計算存在各種問題，我們認為移動智能終端之間的本地化協作將是另一個可能的發展方向。文章首先對已有研究成果中收到本地化協作支持的應用進行了總結，并進一步提出了支持協作應用開發和協作應用運行的編程語言和中間件。最后，對移動終端協作方向的開放性研究問題進行了總結，提出了可能的研究子方向。

參考文獻

[1] LIU， J， PRIYANTHA B， HART T， RAMOS H S， and LOUREIRO A A and WANG Q. Energy Efficient GPS Sensing with Cloud Offloading[C]//in Proceedings of the 10th ACM Conference on Embedded Network Sensor Systems， Toronto， Canada， 2012： 85-98

[2] KWON， YOUNG-Woo， and ELI Tilevich. Energy-Efficient and Fault-Tolerant Distributed Mobile Execution[C]// 2012 IEEE 32nd International Conference on Distributed Computing Systems （ICDCS）， Macau， China， 2012

[3] BARBERA， MARCO， et al. To Offload or not to Offload？ The Bandwidth and Energy Costs of Mobile Cloud Computing[C]// in Proceedings of the IEEE INFOCOM 2013，Turink，Italy， 2013

[4] KELLER， LORENZO， et al. MicroCast： Cooperative Video Streaming on Smartphones[C]//in Proceedings of the 10th International Conference on Mobile systems， Applications， and Services， Ambleside， United Kingdom，2012

[5] Yoo， JONG-Woon， and KYU Ho Park. A Cooperative Clustering Protocol for Energy Saving of Mobile Devices with Wlan and Bluetooth Interfaces [J]. IEEE Transactions on Mobile Computing， 2011，10（4）： 491-504

[6] YU， TUO， et al. INDAPSON： An Incentive Data Plan Sharing System Based on Self-Organizing Network[C] // in Proceedings of INFOCOM 2014， 2014

[7] DE Sá， MARCO， DAVID A Shamma，ELIZABETH F， and CHURCHILL. Live Mobile Collaboration for Video Production： Design， Guidelines， and Requirements [J].Personal and ubiquitous computing， 2014，18 （3）： 693-707

[8] SUR， SANJIB， TENG W， and ZHANG X Y. Autodirective Audio Capturing Through a Synchronized Smartphone Array[C]//in Proceedings of the 12th Annual International Conference on Mobile Systems， Applications， and Services， Bretton Woods， USA， 2014

[9] YANG， DEJUN， et al. Crowdsourcing to Smartphones： Incentive Mechanism Design for Mobile Phone Sensing[C]//in Proceedings of the 18th Annual International Conference on Mobile Computing and Networking， Istanbul， Turkey， 2012

[10] The Range of WiFi and BT [EB/OL].

http：//www.pcworld.com/article/208778/Wi_Fi_Direct_vs_Bluetooth_4_0_A_Battle_for_Supremacy.html

[11] Multi-Level Security [EB/OL]. https：//en.wikipedia.org/wiki/Multilevel_security