近距离移动智能终端的协同计算机制

宋峥　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