移动群智感知即服务架构

移动群智感知即服务：面向感知云应用的平台

摘要

以消费者为中心的移动设备（如智能手机）是位于互联网边缘的一类新兴设备。利用志愿者及其移动设备作为（感知）数据采集渠道，被称为移动群智感知（MCS），这带来了诸多挑战，特别是在感知资源贡献者的管理方面，包括处理其订阅、随机且不可预测的加入与退出，以及节点波动等问题。

为了促进并加速这一趋势的（商业）利用，本文提出采用一种面向服务的方法来应对移动群智感知应用将应用部署到感知云基础设施中，实现移动群智感知应用领域与基础设施领域的解耦。为此，我们提供了实现这种新型移动群智感知范式的构建模块，从云的分层视角来看，该模块可被定义为平台服务，即移动群智感知即服务（MCSaaS）。本文提出了一种原型实现，作为所提出的框架的蓝图和概念验证，同时通过采用合适的与移动性相关的用例对MCSaaS范式 的有效性进行了评估，以验证该概念，并通过广义随机Petri网的建模方法进行了分析。关键词：云, 物联网, 基础设施即服务, 志愿贡献, 传感器与执行器, 移动群智感知, 运行时定制。

1. 引言和动机

当前趋势，特别是针对信息物理系统和物联网（IoT），表明实现普及性服务最有吸引力的方向之一来自机会式和参与式感知范式，例如移动群智感知（MCS）。MCS 利用智能手机和其他便携式设备的广泛存在，使用户和社区群体能够共同共享来自设备上感知资源的数据，以测量共同关注的现象，并利用社会动态。贡献者还有可能通过元数据将上下文信息附加到原始数据中。这种由社区驱动的感知趋势由不同层次的机器交互推动，包括数据通信、采集、处理和挖掘。从移动设备发起众包和感知任务，让设备所有者作为志愿参与者加入，有可能使最终用户同时成为贡献者和消费者大量（经过整理的）数据。

然而，要实现MCS范式的广泛应用，仍需解决若干关键问题[1, 2]。首先，需要一种统一的架构来支持MCS应用，以实现软件组件的可重用性，从而缩短上市周期。现有的MCS应用通常作为独立的应用程序构建，而诸如资源参与等共性挑战却每次被重复应对，或根本未被处理。移动操作系统（OS）和传感器硬件的异构性进一步加剧了这一问题。其结果是，感知与处理活动通常会在以下两种情况下导致类似任务的重复执行：(i) 在单个设备（贡献节点）内为不同的MCS应用执行，造成能源耗尽；(ii) 在多个邻近设备之间执行，导致后端带宽使用和处理需求的急剧上升。这两种情况均凸显出一种不可扩展的部署模型。

此外，移动群智感知应用依赖于每个贡献者完成本地部署任务。尽管大多数MCS应用需要足够数量的贡献者才能被视为有用，但应用采纳受限于用户跟踪和安装新推出应用的速度。根据近期报告，这一速度相当低；例如，2014年苹果应用商店中提供的120万个应用程序中，近80%几乎没有下载量1。以志愿者方式提供资源是大规模利用MCS范式的主要限制之一，因为它自然带来了与贡献流失相关的约束。对于MCS应用而言，这就产生了对“营销”策略的需求，旨在增加订阅数量，激励、保留并奖励贡献者通过激励措施吸引潜在贡献者。然而，即使注册活动（或机制，例如信用奖励系统）可能非常有效，订阅过程通常表现出缓慢而平滑的动态特性。因此，在获得大量感知数据流之前，可能会经历显著的时间延迟。这一问题可能严重限制MCS范式的应用范围，使其仅适用于少数拥有广泛且长期建立的潜在贡献者社区的应用。

从另一个角度来看，另一项重要趋势是将物联网推向面向服务和云计算范式 [3, 4, 5]。在这种观点下，云不仅是一种用于存档来自普及性物联网基础设施的感知数据的技术，更是一种在管理底层资源和物时应采用的模型和范式。

遵循这一物联网‐云研究方向，本文提出了一种新颖的平台，用于机会式（大规模）利用为MCS应用贡献的资源，以进一步了解MCS范式是否确实能够在物联网环境中大规模应用。所提出的方法通过为潜在的MCS创业者提供一个公平的竞争环境，实现对截然不同的底层生态系统的同质化访问，从而克服了上述若干难题。为此，我们识别出关于（无人协助的）MCS应用传播的两类问题：（i）基础设施相关的，主要集中在注册和管理自愿贡献节点的机制，以及抽象化感知资源并实现统一访问的机制；以及（ii）应用相关的，主要致力于与使能基础设施交互的机制，请求所需 的感知资源，并在获得资源后，将MCS应用部署到资源托管节点上。通过这种方式，我们能够像在云环境中一样，将基础设施资源（供给）与应用需求（需求）解耦，从而使开发、部署和运维完全独立。

为了实现这一新型MCS方法，采用了在[6],中提出的感知与执行即服务（SAaaS）框架作为底层（基础设施领域）使能技术。SAaaS基于面向服务且受云启发的方法，可根据需求从底层（贡献的）物理节点收集并弹性提供（虚拟）感知与执行资源。本研究扩展并调整了SAaaS范式，以实现MCS应用程序的快速部署并简化其运维，实际上提供了一个移动群智感知即服务（MCSaaS）平台。

从(SA)即服务的角度来处理MCS具有诸多优势。基于SAaaS模型所提供的能力，对感知资源进行虚拟化和定制化，允许多个平台/应用提供商同时利用设备池。提供MCSaaS可进一步简化单个设备或设备池内的感知与处理活动的供给。此外，将MCS应用程序与基础设施解耦，促进了感知基础设施提供商的角色发展，该提供商负责注册并管理贡献节点，以及在其之上的平台提供商作为中介，连接（i）前者与（ii）MCS应用提供商，使后者能够专注于应用程序本身，而将关于需求（资源类型、可用性等）的考虑和实施交由平台处理。

在本文中，我们对所提出的MCSaaS方法进行了高层概述，并描述了不同的架构元素及其交互。此外，我们还强调了所提出的框架的益处与传统MCS方法不同，(i) 通过以MobiCSOS栈形式实现的MCSaaS框架原型，并对真实世界应用部署进行仿真；以及(ii) 使用广义随机Petri网 （GSPN）[7]进行建模。

本工作的主要贡献可以归纳为：
一种新颖的（基于云的）面向服务的MCS范式，即MCSaaS；
•一个用于移动群智即服务平台堆栈的参考架构；
•一个MCSaaS原型实现，即MobiCSOS，开发了诸如节点波动管理等基本机制，作为所提出方法的概念验证；
基于简单真实场景和大规模分析模型，对Android移动设备上的 MCSaaS潜力进行的初步评估。

本文的其余部分组织如下。第2节概述了相关工作。第3节聚焦于整体 MCS场景，描述并阐述了我们提出的MCSaaS方法的动机，而第4节介绍了基础设施元素。第5节讨论了MCSaaS平台的主要特性，第6节探讨了应用程序配置与部署问题，而第7节则关注MobiCSOS的实现细节。第8节讨论了面向城市交通应用场景的MCS应用在MCSaaS辅助下的部署，并基于仿真场景和广义随机Petri网模型进行了数值评估，结论在第9节中给出。

2. 基本概念和相关工作

2.1. 移动群智感知

MCS [1]是一种新兴趋势，处于志愿计算、基于群体的计算、物联网和感知范式的交叉点。它指的是一系列由社区驱动的感知方法，属于参与式[8]和/ 或机会式[9]类别，旨在吸引大规模的贡献者[2, 10]参与。参与式感知的特点是个人通过设备或（元）数据主动为特定应用做出贡献（例如拍摄照片），而机会式感知则更加自主，用户参与程度最低（例如对地理定位数据进行连续采样）。

从挖掘城市动态[11],到公共安全[12],、交通与环境监测[13, 14],、智能照明[15]以及智慧城市[16],等众多应用，均可采用MCS范式来实现。

现有的移动群智感知应用主要包含两个组件[1]：
i) 面向设备的，用于数据采集、按需执行本地分析以及数据传播，
ii) 后端，负责广泛的数据分析、存储和可视化任务。

2.2. 相关工作

尽管移动群智感知是一个相当新颖且正在兴起的课题，但已有许多研究涉及相关问题。该领域最早的研究工作从机会式、参与式、社交与群智感知范式方面提出并描述了这一方法。所有这些概念随后都被归入移动群智感知的范畴[1]。

迄今为止，已在不同场景下开发了多种MCS应用[18, 19, 13, 20]，表明MCS范式在直接或间接涉及众多利益相关者和大量用户的应用中具有实用性。这引起了学术界和商业界的关注，一方面开始开发新的中间件，以实现用于移动群智感知系统管理的机制和工具[21, 22]，另一方面正在研究MCS方法在科学应用中的潜在应用在商业领域中情况如此。因此，当前的现状凸显了需要采用合适的、能够为移动群智感知领域带来秩序的方法论和技术，通过工程实践和工具来探索该范式的未开发潜力。

针对前一节提出的问题，已有多个框架被提出以支持快速进行MCS应用开发与部署。AnonySense [23]是一个面向机会式和参与式感知的隐私感知框架。应用程序使用领域特定语言（AnonyTL）指定感知任务行为，然后将其提交给AnonySense组件和移动节点。该框架采用轮询模型进行任务分发。下载的任务会根据节点的上下文与其进行匹配。

Medusa [24]是一个编程框架，用于指定在智能手机和云上执行的感知任务的工作流程。它定义了Med‐Script编程语言，为群智感知任务的各个阶段以及流程控制提供高级抽象。此外，它还在云和智能手机之间提供了一个分布式运行时环境。

Pogo [25]提出了一种中间件，用于利用手机构建大规模感知测试平台。研究人员和设备所有者均可使用该中间件，但每类用户根据其角色以不同方式运行。Pogo依赖XMPP协议实现节点间的通信。实验通过 JavaScript编写。

Vita [26]支持多种MCS应用/任务的开发、部署和管理。它包含移动平台和云平台两部分。前者提供适当的服务（例如地图和定位），以支持感知任务的执行。该系统通过使用遗传算法和K‐均值聚类，优化将任务分配给一组用户或云服务器的过程。

云平台简化了移动群智感知应用程序的开发和部署，集成并存储上传的感知数据以及与系统运维相关的指标。

PRISM[27]也是一个用于群智感知应用的平台，允许将可执行的二进制文件部署到移动设备上。通过方法调用拦截技术对不可信应用进行沙箱隔离，以确保安全和隐私。PRISM采用基于推送的模型，实现应用程序向一组适当手机的自动部署。系统实现了高效追踪移动设备的功能，同时降低了隐私风险并减少了通信开销。

上述大多数框架提出了用于参与设备的硬件和操作系统抽象的定制语言，或指定了专用沙箱环境以实现应用程序的安全执行。尽管这种方式较为便捷，但由于仅向开发者提供预编程功能和软件模块，导致应用开发环境灵活性较差且功能受限。事实上，只有PRISM [27]支持原生MCS应用程序的部署（尽管传感器只能通过沙箱访问），同时还提供了参与设备的选择机制。由于没有从旨在利用感知基础设施的平台中分离出面向服务的模型，因此必须专门为该平台显式设计沙箱和硬件资源访问机制，而不是将这些任务委托给IaaS级框架。

关于感知应用与任务的部署，上述框架允许在所有参与设备上 indiscriminately 地进行快速安装和执行。此外，Medusa 提供了特定的奖励与激励机制以促进用户参与，同时允许智能手机所有者设定系统组件使用的限制然而，大多数这些框架并未提供用于目标选择参与设备的高级机制，尽管这一过程可显著提高可用资源利用的效率，并最小化对同一设备上运行的依赖MCS的服务的影响。这是由于缺乏可用于MCS并以受控方式利用的基础设施，资源仍需通过上述平台提供的专用机制进行注册。

最后，值得注意的是，上述框架均未将支持贡献流失作为平台提供的功能，以根据应用程序开发者和服务提供者的需求实现MCS应用用户群的按需扩展或缩减。

3. MCSaaS 范式

3.1. MCS即服务愿景

MCSaaS框架旨在解决现有MCS应用的一些基本局限性，例如开发者在资源参与方面需要进行显式且耗时的投入，而该框架转而支持由MCS应用服务提供商进行贡献者招募。具体而言，MCSaaS通过按需提供基础设施来解决这些问题。这样一来，MCS应用程序/服务提供商可以立即在其及时可用的资源上部署和运行其应用程序与服务，这些资源在为部署 MCS应用配置或定制后即可使用。该方法的另一个重要优势在于，由于范式转变的设计，大多数情况下可免费满足实时需求，因为通过提供一定保证数量的资源即可满足服务质量要求。

从高层次来看，该方法可以通过在功能和管理上将MCS应用/服务部署划分为两个领域来实现：i）基础设施领域，包括（嵌入式）感知设备，提供资源管理（中介、互操作性等）服务以及用于定制和部署MCS应用程序的设施；以及ii）应用领域，承载前端和后端（分析）服务，用于处理基础设施模块提供的（经过滤和预处理的）数据，利用基础设施/低层级的应用程序部署和数据/节点管理设施来实现MCS应用程序或服务。

这极大地影响了MCS范式，显著改变了场景‐通过引入新的利益相关者，并开辟更多的利用途径，不仅在研究方面，而且在商业层面（例如MCSaaS感知资源与服务的开放市场）均得以实现。

更具体地说，如图2所示，不同的应用服务提供商（MCS ASPs）可以利用 MCSaaS平台提供商所提供的设施，包括传统的、提供处理和存储资源的企业级基础设施提供商，即分别为基础设施即服务（IaaS）和数据即服务（DaaS）。在感知云下，描绘了几类基础设施贡献者：由于此处讨论的是软件即服务（SAaaS），因此所有者/管理员是贡献者，他们共享其控制下的资源，例如移动设备、个人数字助理或无线传感器网络（WSNs）。

通过比较图1和图2，可以清楚地看出“传统”MCS场景与所提出的 MCSaaS场景之间的差异，这些差异已在表1中进行了总结，其中描述了 MCSaaS的主要参与者及其职责，以及他们角色的优缺点。更具体地说，在“传统”MCS领域（图1）中，潜在贡献者直接与MCS应用服务提供商（MCS ASP）交互以参与众包感知活动。而在图2所示的MCSaaS场景中，贡献者是节点所有者/管理员，他们通过向感知基础设施提供商（SaaS）注册，共享其控制下的资源，该过程可能通过适当的激励机制得以维持。

因此，贡献在较低层级进行管理，从而为资源共享提供了更大的自由度（如多个MCS应用程序的贡献、贡献配置文件、积分、金钱等），但这需要将资源控制权委托给基础设施提供商。因此，MCSaaS场景中引入了新的利益相关者，例如基础设施提供商（InP）和移动云计算即服务提供商（MCSaaS‐P），位于MCS应用服务提供商（MCS ASP）和贡献者之间。

表1：参与MCSaaS场景的参与者

贡献者。这带来了诸多益处，尤其有利于MCS应用服务提供商，他们可以快速开发并将应用程序部署到支持MCSaaS的基础设施上。

面向服务的供应模型是MCSaaS‐P的最佳供给方式向MCS ASP提供所需的资源，实现定制化设施的同时确保供给所需的服务水平。MCSaaS‐P可为一个或多个MCS应用程序/服务提供支持，并像传统MCS场景中一样透明地交付给MCS终端用户（EU）。为了使 MCSaaS‐P能够向MCS ASP提供所请求的感知资源，双方必须协商所需资源的集合，然后在达成协议后，ASP通过MCSaaS平台将MCS应用程序部署到由基础设施提供商（InP）提供的相应注册贡献节点集合上。该过程的详细信息见第6节。

3.2. 移动群智即服务平台堆栈

因此，本文提出的主要思想是采用一种面向云和服务的方法，以实现移动群智感知资源与服务的按需供给。通过这种方式，SA即服务感知云成为MCSaaS基础设施的一个支柱。此外，必须构建一个更高层次的类平台层，以提供资源管理（数据聚合、中介、互操作等）以及在此类基础设施之上部署和定制应用程序的服务。感知与执行资源在云中不再像当前移动云趋势中那样仅作为简单的终端节点存在，而是与传统云架构中的计算、存储和网络资源类似：被抽象化、虚拟化并在云中分组，从而通过融合云与物联网的潜力，释放新的增值服务。

因此，我们的目标是提供一个概念框架以及相应的软件栈，能够应对此类问题，同时整体上着眼于MCS即服务愿景。为此，我们采用了一种多层方法，如图3所示，该方法包含节点和基础设施云的分层架构。

在平台即服务（PaaS）之下，以及顶部的应用程序‐软件即服务（SaaS）之上，提出了一种方案。

在MCSaaS堆栈的较低层级，贡献者将其节点共享给基础设施提供商，这些提供商将节点纳入以提供（虚拟）感知和执行资源作为一种服务（ SAaaS）。此外，该层级还可选择性地包含计算（IaaS）和存储（DaaS）提供商。在基础的基础设施机制之上，MCSaaS云平台提供主要与MCS应用相关的虚拟资源配置、定制和管理的服务。MCSaaS平台可实现暴露由不同类别的基础设施提供商（即IaaS、DaaS、SAaaS）所提供的资源的功能。在更高层级上，MCS应用程序利用此类基础设施和平台设施，最终实现并提供SaaS 服务。然而，一个 MCS 应用服务提供商可能只是部署一个应用程序，用于收集和/或显示数据，而不一定将其构建成网络服务，或成为（由 MCS 驱动的）软件即服务提供商。

4. 基础设施

如前一节所述，MCSaaS场景可能涉及第三方为MCS应用的开发者提供所需的基础设施即服务/数据即服务资源，但本文重点关注任何以 MCS为中心的设施的主要构建模块：（移动）感知基础设施，其以面向服务的云资源形式呈现，即所谓的感知与执行即服务（SAaaS）。

SAaaS 是一种旨在基于移动设备和传感器网络中的传感器与执行器来构建感知基础设施的范式，以类似云计算的方式提供虚拟的感知与执行资源。更具体地说，它提供了基本的机制和工具，用于实现传感器与执行器云，服务提供者需要对其进行适当的扩展和定制，以实施增强的服务和供给模式。为此，需要解决的主要问题包括：感知与执行资源的抽象、虚拟化、定制、监控、服务等级协议和服务质量管理、订阅、节点波动与策略管理、注册、索引与发现、安全以及容错。

这促进了实现以下主要功能的软件栈设计：（i）传感器节点、智能手机或其他具备传感器和/或执行器的设备的参与，并使其能够在云环境中实现互操作；（ii）用于节点自管理、配置和适应的分布式机制与工具；（iii）用于启用和提供

管理贡献资源。

为了实现这一雄心勃勃的构想，即基于SAaaS范式的传感器云，在[6]中我们介绍了完整的堆栈以及架构模块的高级蓝图，其三个主要组件自下而上如图4所示：虚拟机监控器、自主执行器和志愿云管理器。

SAaaS 堆栈和模块覆盖图3中的两个较低层级：从提供对 MCSaaS PaaS 和移动群智感知 软件即服务软件应用程序和服务支持的云基础设施层，到涵盖edge设备的节点层。通过 SAaaS 堆栈，任何设备（无论是移动还是静态）以及任何传感器网络，无论其软件环境和操作系统如何，都可以参与群智感知活动。因此，下文中使用的术语 SAaaS node指配备有传感器的智能设备（如智能手机），或连接可能大量较小感知设备（即微小传感器节点）的前端（如传感器节点网络的网关）。

此外，由于SAaaS采用了一种以设备为中心的device-centric方法，提供了实际的感知与执行资源（即使经过多路复用和/或虚拟化），它使得原本在更高层级上未向MCSASP开放的定制和配置能力得以实现，从而可能探索此前被忽视的应用领域。

最底层的虚拟机监控器在单个节点级别运行，对可用的传感器进行抽象。该节点可以是资源丰富的独立设备（如智能手机），也可以是属于某个网络的嵌入式系统（如无线传感器网络）。虚拟机监控器的主要职责包括：通信和网络虚拟化原语、根据相关信息模型对设备与功能进行抽象描述、感知资源虚拟化、定制、隔离以及语义标注。

云模块以自治执行器和志愿云管理器的形式，处理与节点间交互相关的问题。前者负责节点内部的云策略执行、本地与全局策略冲突解决、覆盖层实例化协作、注册启动以及订阅记录保存，在适当情况下依据自主原则进行操作；后者则负责以下功能：通过Web服务接口暴露传感器云、订阅者及贡献资源的索引、服务等级协议（SLA）和服务质量（QoS）指标的监控。这些层级由此构成一个耦合的双层云堆栈，其中许多机制被划分到两个模块中，底层模块处理节点级操作和自组织特性，上层模块实现集中管理的云级方法。

事实上，以设备注册为例，较低的云模块是负责节点侧启动注册过程，包括与贡献者进行一次性交互（例如，用于排除或限制对某些设备托管资源的访问），通过将枚举资源的描述推送至云，以及记录该节点已成功订阅的任何云实例的记录保存。集中式模块则负责云侧对注册请求的接受或拒绝，以及资源（和相应节点）的资源索引，以向云的最终用户提供查询能力。

在此层级，将云模块之间的通信建立在广泛可用的物联网和机器对机器通信协议与服务（如WebSocket [28]）之上，意味着可以访问大量现有的小工具和个人设备，否则这些设备将无法被利用，除非对其固件特别是通信协议栈进行重大修改。这一选择直接影响移动群智应用开发者可能体验到的资源池扩展所带来的更广泛可能性。

5. 平台：MCSaaS模块

对于MCSaaS堆栈的设计，需要明确MCSaaS平台应提供哪些功能。

PaaS是云计算中位于IaaS和SaaS之间的中间服务模式，消费者通过使用提供商提供的工具、库等资源来创建软件，同时可控制软件的部署和配置设置。PaaS提供商通常为主基础设施（在本例中主要是SAaaS）提供大量辅助设施，例如网络、服务器、存储、传感器等。

像 MCSaaS 这样的平台必须满足移动群智感知领域的特定API需求，MCSaaS模块

作为在节点端点（例如移动设备）和云上均可利用的预过滤和预处理机制，同时考虑通信开销与本地计算之间的权衡。其他API将包括通用分析框架，这些框架仅在IaaS/DaaS层级被利用。与此相关的联邦、跨云或多云架构、隐私、安全和信任等问题本应属于MCSaaS的范畴，但在本次研究中尚未涉及。因此，应用托管和部署环境是此背景下的主要关注点。此外， PaaS通常还包括应用设计、应用开发与测试设施，以及面向开发者和集成者的典型服务，如团队协作、Web服务集成、数据库驱动的持久化、状态管理、应用版本控制、应用检测/性能分析和社区培育设施。

上述所有功能均集成于平台层的MCSaaS模块中，用于实现PaaS服务（见图5）。基础设施接口提供了与底层感知云交互的手段。可采用标准接口如OCCI [29]，或遵循多云方法的特定技术。在基础设施接口之上，定义了四个MCSaaS核心子模块，即云代理、编排器、Cus‐化服务和部署管理器。

传入的MCSaaS请求由平台接口转发至这些子模块。该接口应为 RESTful，并公开有用的实体抽象，例如应用程序包对象。该请求最初由编排器管理，编排器通过从请求中提取应用程序的高层工作流所编码的需求和依赖关系，来识别MCS应用程序所需的资源。此类服务在暴露的功能和相关API方面可遵循现有标准，例如TOSCA [30],。因此，编排器将迭代地与云代理交互，根据MCS应用服务提供商提供的上述需求，通过SA 即服务基础设施提供商提前规划感知设备的参与。在成功协商并为MCS应用程序分配所需资源后，定制服务和部署管理器将启动应用程序设置阶段。

定制服务主要专注于定制资源和（虚拟）设备，设置感知资源的具体底层参数，如占空比、采样频率和量程范围，以及用于托管MCS应用程序注入代码的软件环境的高层配置。这是通过将高层指令转换为统一的底层原语来实现的，这些原语仍以通用形式表达，最终传递给SA即服务进行进一步处理。部署管理器则旨在将所需模块部署到可用资源上，并使其适应宿主环境。可提供预配置包或捆绑包，其有效载荷可能包含完整的应用程序环境或其部分，甚至包括实现高级功能（如分析、接口、领域相关插件和附加组件）的额外工具。当后者的模块是初始实现的主要关注点，第6节描述了相关的工作流，第7节则在相应软件设计方面提供了更多细节。

6. 移动云计算应用的设置与部署

在提出的范式中，主要利益相关者（如图2所示）通过上述识别的模块和模块之间的行为与交互具有重要的实际意义。因此，与MCS应用程序在MCSaaS框架中的设置、部署和管理相关的主要活动通过以下活动图 （AD）进行描述。更具体地说，在描述这些主要活动时，考虑了与 MCSaaS‐P和MCS应用服务提供商相关的两个主要视角，分别包括：（i） 设置MCSaaS平台（第6.1节），以及（ii）在其上配置和部署特定的 MCS应用程序（第6.2节）。

6.1. MCSaaS平台设置

关于在可能存在安全隐患的基础设施（SA即服务）上实现平台即服务， 我们首先需要描述一个引导场景，在该场景中，必要的MCSaaS组件以与 平台即服务无关的方式被推送到移动设备。更具体地说，设想的交互方式 如下：MCSaaS提供商需要在一组可用的基础设施提供商中选择合适的基 础设施，以提供移动群智感知即服务。

随后进入引导阶段，MCSaaS‐P必须为通过SAaaS基础设施提供商预 订的每个移动设备启用支持，以便轻松部署MCS应用程序。为此，利用由 虚拟机监控器提供的SAaaS服务来部署节点端MCSaaS模块。

MCSaaS模块使贡献者能够选择其参与程度以及为MCS应用共享的资 源，即不仅包括纯SAaaS场景中的感知资源，还包括CPU时间、内存和/或 板载存储。此外，该模块负责与MCS应用部署相关的任务，即在图5中激 活终端节点，并随后与部署管理器协作，在接收和部署下一个MCS应用时， 执行前述关于本地计算和存储资源的选择。

上述方法除了避免了层叠（IaaS / PaaS）违规外，还使我们能够实现 移动端的SAaaS组件，仅需应对感知基础设施相关问题和SAaaS场景。这 种专注性也延续到了沙箱及其他安全相关机制方面，例如仅针对SAaaS相 关的感知资源使用和交互来处理用户规定的限制。

同样，由定制服务规定的任何节点端运维操作，将仅由引导环境处理， 从而导致为了开发某些安全相关机制，例如针对MCS应用访问各类用户数据的权限 检查，这些机制仅在此层级实现，即在MCSaaS引导组件本身中实现。

图6 描述了与平台设置相关的MCSaaS‐P活动，始于一个宏观步骤， 包括与基础设施的PaaS-enablement相关的所有操作，例如识别和选择潜 在的InPs、暴露相关API和服务端点。随后是平台前端配置阶段：这涉及 设置一个软件即服务实例，即为应用程序开发者提供的快速应用开发（ RAD）环境。一旦前端准备就绪，MCSaaS‐P即可“上线”并开始服务客 户，例如MCS应用服务提供商。

6.2. MCS应用程序配置与部署

MCS应用程序配置/部署由MCS应用服务提供商利用MCSaaS‐P提供 的服务完成，分为（i）应用协商与平台引导阶段，以及（ii）实际的应用 部署，分别在第6.2.1节和第6.2.2节中详细说明。

6.2.1. 协商和引导

图7描述了（由平台即服务中介的）应用程序协商和平台引导阶段。前者涉及确定应用程序所需的构建模块，即基础设施即服务/数据即服务/ 软件即服务资源，并包含开发者（或MCS应用服务提供商）将相应规划推 送到平台前端（resourceplanning）的阶段。随后是由云代理协调的需求‐ 约束匹配协商过程，可能涉及仍处于规划阶段的MCS‐ASP进行多次迭代 （requirement-constraint matching）。在达成一致并跟进后

在MCS ASP确认（confirm reservation）之后，需通过MCSaaS‐P（ platform bootstrap）与基础设施提供商（bootstrap module deployment） 之间的交互，将平台模块部署到所提供的感知资源中。因此，已预订的感 知资源的端点引用（EPR）将被反馈给MCSaaS‐P并进行存储（register resource EPR），同时预订信息被转发至MCS应用服务提供商（ storersvinf o）。

6.2.2. 部署

如图8所示，MCS应用程序的现场部署始于MCS应用服务提供商在可 用API（API选择）中进行选择，以支持基本和高级操作（例如预过滤、分 析）。随后是平台对MCS应用程序进行构件上下文化，以及针对特定应用 领域配置基础设施感知资源（应用域配置-）

tion），同时通过相应地连接基础设施终端节点来转换客户对资源和 APIs的约束（服务端点连接）。

然后，应用程序提交一组初始需求（require-mentpush），这是在第 6.2.1节中讨论的引导阶段期间获得的“配方”（包括高级代码）。此步骤 启动将构件部署（artif actdeployment）到虚拟机、存储对象以及在SAaaS 情况下部署到贡献者自有移动设备的过程（包括二进制文件、配置、系统 镜像等）。在后台，部署之前需将配方转换为构件，例如编译/打包，这部 分仍由部署管理器负责。端点的激活以及随后在已分配资源上对连接关系 的测绘（如图8对应的AD所示）（orchestration）由编排器负责。为了使编 排器的操作有效，甚至在大多数情况下可行，需要平台发起的激活和平行 （重新）连接，从而导致需要一种始终在线（任意时间）的推送至客户端 的消息传递通道。

每个已注册设备的通道，由与环境无关的双向异步交换原语提供支持。

随后，需要通过定制服务进行资源上下文化阶段，对底层资源进行配 置甚至定制，例如在适当情况下迭代调用SAaaS服务。测绘和特别是定制 过程可能导致初始需求与实际设置之间出现不匹配，因此可能需要与 MCS应用服务提供商进行多次迭代，以达成收敛或至少实现满意的权衡， 然后结束匹配过程。此外，MCS应用服务提供商可以开始提供门户或有用 的网络服务，在数据集共享服务部署中共享和可视化完整数据集或其任何 紧凑表示形式。这些数据集因此可提供给第三方（也可作为开放数据）， 使其能够围绕这些数据存储开发应用程序。

7. MCSaaS设计

接下来，我们将提供有关移动群智即服务平台堆栈实现的描述和一些 细节。

关于节点端运行时，感知API 和环境提供的通知子系统在我们的设计 中具有特别的相关性。前者对于 MCSaaS 而言是不透明的，因为其定制化 服务必须将传感器重新配置和调优请求传递给 SAaaS 设备端子系统；而后 者在云的两个层级都有用处，可最小化使用平台提供的基于云的机制实现 向设备的推送通信，避免处理可达性方面的边界情况，并避免总体上对网 络状况的跟踪。

编排器和云代理中的服务器端逻辑使用Java和Python开发，在面向 用户的交互模型方面采用了Servlet[31]，并通过RESTful端点作为云私 有接口与Python实现的机制进行对接。Apache Tomcat [32]用作Java servlet容器。例如，谷歌通知服务 谷歌云消息服务（GCM）[33],用于在安卓移动设备中交换（MCSaaS引 导）异步消息，以支持云发起的原语和运行时可定制机制，以及用于按需 激活基于WebSocket的子系统。这种对（部分）自定义通信总线的偏好源 于使用GCM所带来的固有限制（和成本），因为GCM并不适用于大有效 载荷（例如文件传输），而是专门为推送通知设计和推广的，在本例中也 用于信令。

就主要模块而言，中介负责跟踪资源预留，并将资源请求传递给编排 器。后者在当前实现中主要处理节点波动，即在MCSaaS级别上，针对系 统托管的任何MCS应用的活跃贡献者数量波动做出响应。具体而言，一旦 根据MCS开发者设定的参数，在某个区域内的该群体数量低于阈值，运行 在编排器中的节点波动管理例程便会查找同一区域内其他平台启用的节点， 通过GCM推送通知，以触发这些节点获取安装包、安装并启动相应的有效 载荷——即MCS应用程序。整个MCSaaS群体持续处于监控之下，因此任 何查询都可在零点几秒内得到响应。部署管理器的客户端组件负责监听传 入的有效载荷。

由服务器端逻辑标记，以便在应用程序下载到设备后自动安装。这使得应 用程序可以在无需用户干预的情况下进行安装，尽管在安装过程中某些窗 口仍会不可避免地短暂弹出（例如，每个窗口实例的显示时间少于一秒）。

图9 描述了基础设施和平台级框架子系统的布局，即移动群智感知开 放堆栈（MobiCSOS），重点关注最终用户（例如MCS应用服务提供商及 其他感兴趣的开发者）与传感器/执行器承载节点之间的通信。在节点侧， MobiCSOS边缘根据相应的执行实例，作为SA即服务客户端或MCS即服务 客户端，与操作系统资源和服务进行交互，并在SAaaS情况下，通过（受 控的）对感知API的访问，与（虚拟化的）感知与执行资源进行交互。它 是与云基础设施的连接点，允许最终用户管理托管在节点上的资源，即使 他们位于NAT或严格防火墙之后。这是通过MobiCSOS边缘与其云端对应组件 （即MobiCSOS MPlatf orm服务）之间基于GCM和WebSocket的通信来 确保的。MobiCSOS MPlatform服务同时充当志愿云管理器（SAaaS） 和中介（MCSaaS），作为OpenStack服务实现，为云用户提供远程预订 和管理SAaaS或MCS贡献资源的能力。这一过程既可以通过基于命令行的 客户端（即MobiCSOS命令行客户端）进行，也可以通过网页浏览器访问 MobiCSOS MPlatform服务提供的一组Servlet封装的RESTful API来完 成。

7.1. 节点侧组件

关于网络连接和存在性/可达性，WebSockets[28]是我们的首选技术， 它是一种基于HTTP的协议，通过基于HTTP的持久连接提供全双工TCP 通信。WebSocket的主要优势之一是其与网络无关，客户端只需允许出站 流量（通过Web标准端口）即可。这对于使用防火墙阻止与Web流量无关 的任何互联网连接的环境非常有利。

图10展示了更侧重于节点侧SAaaS组件的MobiCSOS架构，而图11展 示了与节点侧MobiCSOS组件的MCSaaS实例相关的架构。

在最低层的感知API抽象基础上，SAaaS节点端子系统需要通过一组 受虚拟化启发的库（称为MobiCSOS virt libraries）来中介访问。这些库提 供了读写传感器/执行器以及设置设备参数的接口，因此是SAaaS虚拟机监 控器的实际实现。此类操作为因此，将其置于适当的语义抽象级别，即根据预订情况锁定和释放资源， 并且该过程依赖于API粒度带来的约束，以及特定于感知和执行资源的约 束。

MobiCSOS边缘中心代表了板端软件架构的核心，因此可被视为 SAaaS自治执行器的中心组件，而同一组件的专用实例则托管在MCS即服 务客户端中。这两个实例中的引擎均通过WebSocket全双工通道和基于 GCM的消息传递与云进行交互（参见图12），分别向云发送和接收数据， 并执行用户通过云提供的命令。这些命令可能涉及与节点感知与执行资源 （通过MobiCSOS虚拟库）的通信，以及与操作系统资源和系统的交互

级别工具（例如文件系统、后台服务和活动、包管理器）。与云的通信由 SDK 提供的基于推送的消息传递原语确保，在我们的案例中，Android 下使用 GCM。

此外，一组 WebSocket 库（MobiCSOS wstunnel 库）使引擎能够 作为基于 WebSocket 的（反向）隧道服务器，连接到在云中运行的特定 WebSocket 服务器。这使得外部用户可以通过隧道直接访问内部服务， 其入站流量会自动转发到相应的内部后台服务。出站流量则被重定向到隧 道，最终到达连接至云中运行的 WebSocket 服务器的最终用户，以与节 点托管服务进行交互。

MCSaaS 通过 MobiCSOS 感知代理 获取对（虚拟）感知资源的（选 择性）访问权限，以及对移动设备托管服务和部分移动特别是包管理器，通过图中所示的相应代理进行交互。所有这些代理都与 边缘中心的软件即服务实例进行交互。

Edge子系统还提供了一个插件加载器，在MCSaaS实例中，该加载器 实现了节点侧机制以支持定制服务。自定义插件可以从云注入，并在插件 加载器上运行，以实现特定的用户定义原语，包括（沙箱化的）系统级交 互，例如与包管理器和/或启动时自动运行的服务进行交互。事实上，其中 一个与包管理器交互的插件，实现了MCSaaS部署管理器的节点侧对应部 分。

7.2. 云端架构

如前所述，在虚拟基础设施管理方面，OpenStack [34] 是参考技术。OpenStack 是大多数商业、内部和混合部署中云基础设施解决方案的核心， 同时也是一个完全开源的工具与框架生态系统，许多研究项目基于该生态 系统制定其云战略。因此，我们的目标是扩展 OpenStack 以管理感知与执 行资源，并支持移动群智感知平台。

MobiCSOS 云端架构（见图12）包含一个我们称为MPlatf orm的 OpenStack服务。MPlatform具有标准的OpenStack服务架构特征。MobiCSOS MPlatf orm控制器是该服务的核心，负责管理MobiCSOS MPlatf orm数据库，该数据库存储所有必需的信息，例如节点唯一标识符、 与SAaaS和/或MCSaaS用户及租户的关联关系、板卡属性以及硬件/软件 特性，并负责在各组件之间调度远程过程调用。

其他组件。实际上，该组件实现了中介和编排器逻辑，并与外部的临时服 务进行交互，这些临时服务提供定制和部署机制，其中包括一个持续集成 子系统的实例，即 Jenkins [35]。MobiCSOS MPlatf orm API为最终用户提供双重RESTful接口，一个 用于SAaaS，另一个用于MCSaaS，用户可以通过自定义客户端（ MobiCSOS MPlatf orm命令行客户端）和网页浏览器与服务进行交互。事 实上，OpenStack Horizon仪表板已以MobiCSOS仪表板的形式进行了增 强，暴露了MobiCSOS MPlatform服务及其他软件组件提供的所有功能。特别是，该仪表板还负责节点内部服务的访问，将用户重定向至 MobiCSOS MPlatf orm WS隧道代理。该软件是WebSocket服务器的封装 程序和控制器，节点通过使用MobiCSOS wstunnel库连接到该服务器。

同样，MobiCSOS MPlatf orm GCM代理 充当GCM桥接器在其他组件和节点之间，命令流（例如来自定制服务的命令流）由GCM代理进行中继。它将AMQP消息转换为GCM消息，反之亦然。遵循标准的 OpenStack理念，MPlatform组件之间的所有通信都通过网络上的 AMQP队列进行。这使得整个架构具有尽可能高的可扩展性，因为所有组 件都可以部署在不同的机器上，而不会影响服务功能。此外，可以实例化 多个tunnelagent以及多个GCM agent，每个代理在此情况下处理已注册移 动设备的一个子集。таким образом,можно также обеспечить избыточность и высокую доступность.

关于发现机制，这些机制是MPlatform控制器在注册可用资源时所经 历的注册阶段的核心。该设计基于物联网的AllJoyn [36]框架，这是一系 列标准和参考实现，其核心为一种源自DBus的应用协议，适用于消息传 递、服务通告以及服务发现，并通过选定的机制在可用传输上运行，在本 例中是通过支持MPlatform的WS隧道。

8. 移动群智感知应用程序案例研究

在本节中，我们讨论使用MCSaaS平台部署的MCS应用实例，以突出 MCSaaS的优势。为了将所提出的方法与传统移动群智感知进行比较，我 们在物联网/智慧城市场景中考虑了两个可能的用例，涉及两种不同的 MCS应用程序：（i）一个以社区为中心的多用途应用程序，用于路面坑 洞测绘；（ii）交通为墨西拿、米兰和雅典城区服务的监控应用程序（图13）。

墨西拿大学（UMe）、米兰理工大学（PMi）和雅典国家技术大学 （NTUA）的SAaaS（基础设施提供商，InPs）被用于部署场景中，根据 需要利用其私有的IaaS和DaaS提供商（例如由OpenStack驱动的UMe和 PMi PoliCloud [37]）。然而，任何私营或公共公司/机构（例如移动电信 运营商）都可以承担InP的角色。我们的SAaaS云利用来自志愿计算贡献 者（漫游用户）的智能手机传感器。在这些场景中，智能手机将非常有用， 因为它们配备了多种相关传感器，例如用于定位（GPS、GSM、WiFi） 和运动检测（陀螺仪），同时支持（常开型）互联网接入。漫游用户通过 发现并（非排他性地）订阅SAaaS云成为贡献者。

UMePMiNTUA MCSaaS‐P 根据图6所示的工作流程建立。在选择合 适的基础设施提供商（订阅服务、签署服务等级协议等）后， UMePMiNTUA 会发现、收集并暴露通用的（模板化的）Web服务端点 （统一资源标识符），通常用于RESTful调用，以及相应的API文档，并 将其集成到基于HTML5的快速应用开发集成环境中。

在此平台之上，路面坑洞测绘和交通监控应用程序由两个不同的 MCS应用服务提供商提供。贡献者可同时参与路面坑洞测绘和交通监控的 MCS应用，这正是本项目所期望的结果，也是推动该工作的主要驱动力之 一。移动群智感知终端用户（EU）（例如出租车司机）使用相应的移动 （或基于Web的）应用程序来获取所需信息。通常情况下，移动群智感知 终端用户（EU）也同时充当贡献者。

接下来，我们首先讨论如何使用所提出的MCSaaS平台来设置和部署 这两个MCS应用（第8.1节和第8.2节）。然后，在第8.3节中，(i) 报告 MobiCSOS原型在交通监控使用场景中的初步结果，以及 (ii) 通过分析模 型突出MCSaaS方法相较于传统移动群智感知的益处。

8.1. 路面坑洞测绘

一个路面坑洞测绘移动群智感知应用在启动后可自动收集道路状况信 息，无需人工干预。该应用仅需核心的加速度计和定位系统，用于采样检 测剧烈垂直位移和实现地理定位。通过移动群智感知方法收集、分析和聚 类来自不同用户的数据输入，可实现数据验证，包括去除异常值和消除误 报。

在当前的MCS应用部署场景中，坑洞应用仅需要一个用于Web用户界面的数据库和服务器。因此，在基础设施即服务/数 据即服务方面规划需求非常直接。另一方面，需要传输/协商的感知基础设 施的高层约束包括：（i）感知能力（至少包括加速度计和定位）；（ii） 地理区域；以及（iii）设备移动性（如车辆，包括自行车和汽车）。应用 程序设计阶段需要利用一组库和现成例程——这是快速应用开发环境中的 典型过程，例如用于移动端异常检测，以及可选的IaaS API（符合OGC或 M2M标准的REST调用）等，遵循平台即服务方法。

一旦应用程序发布，路面坑洞应用服务提供商（ASP）有两种主要选 择：直接在感兴趣的区域注册支持路面坑洞测绘服务的贡献者（传统移动 群智感知），或请求一个MCSaaS‐P（例如UMePMiNTUA）提供所需的 （车辆）感知资源。如上所述，在前一种情况下，用户注册可能较慢甚至 不成功；而在后一种情况下，MCS应用服务提供商可以立即访问感知基础 设施，但需支付相应服务（MCSaaS）的费用。通过以类似“云突发”的 方式结合这两种方法，当需要时（例如在给定时间约束内要求测绘准确性）， 路面坑洞应用服务提供商可按需使用UMePMiNTUA MCSaaS‐P提供的第 三方感知资源，以及由MCS直接招募的“自有”资源。

路面坑洞应用服务提供商需要与UMePMiNTUA MCSaaS‐P协商，以 获取在移动群智感知即服务平台/基础设施中部署路面坑洞测绘应用所需的 资源。如果协商成功，则需设置并配置UMePMiNTUA MCSaaS‐P提供的 感知资源，以便接收如图7所示的坑洞应用程序代码。

一旦开发者将设计阶段的输出（配方）提供给部署管理器，坑洞应用 程序的部署即开始；在此情况下，仅处理有限子集的二进制文件（例如， 兼容Android驱动的移动设备），并涉及感知资源（图8）。最后，在实 例化时，由应用程序提供或消费的终端节点被启用，编排器将配方中的 （抽象）连接映射到基础设施上。

8.2. 交通监控

MCS范式另一个应用可能是交通监控，这是一种基于移动贡献者的有 用服务实例，仍然与驾驶员相关，驾驶员也可作为潜在的消费者和/或生产 者，并且总体上处于同一领域。从MCS的角度来看，尽管感知活动类似于 路面坑洞测绘，例如仍主要由定位子系统和加速度计实现，但其需求却显 著不同。

由于总体交通流量和具体指标（例如当前巡航速度和减速频率等）需 要实时输入并更新，以确保服务真正有用，因此必须满足某些约束条件， 例如平均每区域最少贡献者数量，以保证交通监控采样的准确性。最重要 的是，该平台旨在根据需要自动部署多个MCS应用，使其能够并行执行， 因此路面坑洞测绘应用与交通监控应用在后台并发运行的场景是完全可行 且已被考虑在内的，同时仍能满足各应用程序的具体需求，例如仅在交通 监控中对积极贡献资源的可用性提出的实时约束。

后者实际上是平台编排能力的一个用例，典型示例如节点更替的管理， 这需要持续地加以处理，以提供预期的服务质量，或至少通过向开发者告 知每个区域当前（或最近）涉及的贡献者数量来实现优雅降级，换句话说， 在简化方案下，即为所显示指标的置信区间。

因此，依赖MCSaaS提供商UMePMiNTUA可能是确保交通监控服务 采样达到预定义准确性水平的唯一有效解决方案。在这种情况下，混合众 包感知‐MCS即服务解决方案也可能有效，利用UMeP‐MiNTUA MCSaaS‐P提供的（车辆）感知资源，补充和丰富交通监控应用服务提供 商通过传统移动群智感知注册流程所获取的信息。另一方面，从 UMePMiNTUA注册感知资源需遵循图7和图8中描述的协商以及部署/配置 阶段。

8.3. 测试与评估

为了证明MCSaaS模型相较于传统MCS模型的有效性，我们评估了： （i）用于部署交通监控应用的MobiCSOS栈的初步实现；以及（ii）相应 的广义随机Petri网模型。

8.3.1. MCS应用程序部署：一个概念验证

交通监控应用，此后称为MCS交通应用，属于基础设施MCS应用[1]的范畴。MCS交通应用的实现遵循与类似的基于社区的支持GPS的导航应用程序（例如Waze [38]），利用贡献者的GPS位置和 行驶时间，提供实时交通更新，如第8.2节所示。为了展示采用提出的范式 相较于当前MCS应用程序部署实践为MCS应用服务提供商带来的益处，本 文以MCS交通应用为例进行了说明，重点讨论了基于志愿者的贡献和节点 波动等问题。

测试场景. MCS交通应用需要通过GPS跟踪获取实时信息，以提供主干道 （服务区域）上（预期）行驶时间的更新。具体而言，主动探测车辆（贡 献者）的最低数量对于建立路段速度[39]估计的可靠性至关重要。路段是 指没有交叉口的连续道路路段，而路段速度是指车辆在单位时间内行驶的 距离。

我们考虑以下测试场景：车辆按照泊松过程进入服务区，行驶时间呈 正态分布[40]。我们假设需要至少10个探测车辆的数据，并以700秒为采样 周期，以确保路段速度估计的可靠性[39]。通过这种方式，交通监控应用 能够正确地估计和预测感兴趣区域的实际交通状况。

在我们的实验中，假设服务区内有平均150辆车辆。此外，我们假设 其中只有一部分车辆同时也是SAaaS贡献者（约8%），同样地，大约只有 5%的车辆是直接由ASP参与的MCS贡献者。这些数值是任意的，但由于 传统移动群智感知应用需要招募、参与并留住参与者，我们认为这样的假 设是合理的，甚至可能有些保守。

测试环境. 第7节中描述的MobiCSOS在MCSaaS和SaaS层面的原型实现已 被用于测试MCS交通应用的部署与运维。由于测试场景需要大量物理设备 而实际设备不足，因此采用仿真方式模拟MCS终端用户/贡献者（运行安 卓4.2 / API级别 8[41]）。我们选择Android不仅因其广泛可用性和普及 性，还因为其SDK和运行时环境提供的一些便利功能，例如仿真子系统 （使用Genymotion [42]）以及调试桥（ADB）[43]，可用于管理仿真实 例。通过Shell脚本编写的辅助函数，并结合ADB，用于设置测试场景 （如车辆移动性、参与度等），以及对仿真实例的供给和控制。

实验指标. 基于MCS交通应用程序的实验中研究了第3节讨论的两种不同场 景：（i）传统移动群智感知范式下的设想场景，以及（ii）由提出的 MCSaaS范式实现的场景。

我们基于服务区内作为活跃探测器的车辆平均数量随时间的变化来比 较这两种场景（贡献者数量）。为此，我们列举了（i）参与传统MCS场景 的移动群智感知贡献者（MCS‐C）；以及（iii）通过整个MobiCSOS架构 为交通监控应用做出贡献的MCSaaS贡献者（MCSaaS‐C）。MCSaaS贡 献者是软件即服务提供商（InP）所吸引的用户子集，被称为SAaaS贡献 者（SAaaS‐C）。

此外，我们通过测量MobiCSOS框架在平均情况下替换MCSaaS贡献 所需的时长，来量化资源波动的影响。离开服务区的移动群智即服务资源池恢复至MCS交通应用程序所需的数量。

结果与比较. 在MCSaaS场景中，由服务感知即服务提供商（基础设施提供 商）负责确保有持续且大量的贡献者参与MCSaaS‐P。然后， MCSaaS‐P需要根据应用需求（在本例中为MCS交通应用程序）保留至少 最低要求数量的移动群智感知贡献者。

贡献者数量: 对于采样周期集合，我们估计在传统MCS场景中平均有 5.8名贡献者，在MCSaaS系统中平均有9.2名贡献者，排除了500秒的预 热期。将MCSaaS场景的结果与传统场景进行比较，可以认为MCSaaS解 决方案成功地在服务区内吸引了贡献者，因为它大致满足了MCS交通应用 对活跃探测器数量的约束（需要10个探测器）。

所提出的方法在满足应用程序需求方面的有效性也在图14中得以体现， 该图是采样周期内仿真的一个快照，仅报告单个测试轨迹。在第20个时间 单位之后，发生了两次几乎同时发生的SAaaS贡献者离开事件，影响了 MCSaaS供给服务。然而，MobiCSOS框架能够迅速响应，并将移动群智 即服务资源池恢复到MCS交通应用所请求的10名贡献者/探测器。

资源波动： 通过实验，我们评估了由于资源波动功能导致MCSaaS系统实际替换离开系统的贡献者（MCSaaS‐C）平均存在6个时间单位（30 秒）的延迟。该延迟可分为四个时间段：

1) SAaaS服务器识别新贡献者到达并启动MCSaaS客户端安装过程所 需的时间；2) MCS即服务客户端安装时间；3) MCSaaS服务器识别新贡 献者到达并启动MCS交通应用安装所需的时间；4) 应用程序安装时间。

这种延迟也在图14的移动群智感知即服务曲线中有所体现，突出显示 在[0, 10]时间单位区间内。

在此评估中，我们忽略了传感器资源抽象和基础设施服务注册所带来 的开销，因为在[44]中我们测量了SAaaS层级上感知资源抽象开销的相关 指标，发现其在所有情况下均可忽略不计。

关于注册，可以将其视为一种典型的一次性（软件即服务级别）运维操作， 因此从长期来看并不十分关键。

由于测试平台的限制以及MobiCSOS框架的初步实现，无法对流失管 理在性能方面的影响进行定量、深入的评估。尽管如此，以下将报告基于 所进行实验的一些总体性定性观察。只要任何替换对应用透明（如 MCSaaS中通常的情况），资源波动（以及后续的资源更新）对拟提供服 务（即移动群智感知应用）性能的影响在设计上就相当有限。整体应用行 为可能取决于可用资源与请求资源之比随时间变化曲线的平滑程度，如交 通监控应用的情况。因此，在处理大量贡献设备丢失时，响应性尤为关键。应用部署时间取决于带宽和并发（非阻塞）扇出，基本保持恒定，不随需 替换设备数量成比例增加。

8.3.2. 建模和评估

为了进一步凸显MCSaaS方法相较于基本MCS模型的优势，我们设计 了两个简单的模型来表示待比较的范式，并通过Petri网进行了评估（图 15）。图15a中的MCS模型比图15b中的MCSaaS模型更复杂，因为它必须 考虑贡献者注册和节点波动管理，而在MCSaaS方法中，这些由SAaaS提 供商负责管理，前提是始终有足够的SAaaS贡献者满足应用程序的需求。

这一假设是相当现实的，因为如果通过特定激励措施加以引导，因此，SAaaS 贡献者群体应当非常庞大，数量级上远超支持单个应用程序 的贡献者群体。此外，结合 MCSaaS 设施提供的节点波动管理能力，应能 轻松确保始终有足够多的贡献者积极参与并为该应用程序贡献数据。

我们将一个通用的MCS应用程序表示为上述描述的路面坑洞测绘或交 通监控，通过处理来自特定感兴趣区域的数据来实现。因此，在图15a的 PN中，贡献节点存在四种可能的状态，这些状态由贡献者可用性（ Av/NAv）和在感兴趣区域中的位置（In/Out）组合而成。当一个节点可 用且在兴趣区域内时（PAv/In），该节点正在积极地为MCS应用程序贡献； 否则，若处于区域外或不可用，则不进行贡献（PAv/Out、 PNAv/In、 PNAv/Out）。新的贡献者可以订阅MCS系统（通过转移 TSubscribe），并以 以上所述的某种状态进入系统（PAv/In、 PAv/Out、 PNAv/In、 PNAv/Out）， 从而能够积极地支持仅当在感兴趣区域且可用时，才提供MCS服务（PAv/In）。因此，进入条 件通过为输入位置后的即时转换分配相应的权重来概率性指定：我们为到 PAv/In、 PAv/Out的转换分配较高的相等权重（4），假设80%的新订阅者 可立即贡献；而为 PNAv/In和 PNAv/Out关联较低的权重（1），意味着仅有 20%的新订阅者无法立即贡献。然后，一旦进入MCS系统，订阅者可以改 变其状态，变为可用/不可用，或进出感兴趣区域。在第一种情况下，转换 TJoin∗和 TLeave∗调节可用性变化，而转换 TEnter∗和 TExit∗分别表征进出 移动性。

另一方面，MCSaaS系统由SAaaS基础设施支持，如上所述，我们假 设由于存在大规模积极且受激励的贡献者群体，该基础设施始终能够为当 前场景向待部署的MCS应用程序暴露正确的感知资源子集（R）。事实上， 考虑到SAaaS‐enabled设备的大规模现场使用，关于存在传感器丰富、多 样化的可测量量以及采样技术的可用性假设可能成立，同时将主要与能力 抽象与发现相关的职责委托给SAaaS组件。因此，该模型主要表示节点流 失管理，其中用可用且在兴趣区域内的新贡献者（PAv/In）替换离开的贡 献者的过程被随机表征与量化（TReplacement），依据的是上述实验获得的 数值。通过这种方式， TJoin−In和 TLeave−Out仅针对MCSaaS系统表示活 跃贡献者（Av/In）的动态变化。

关于MCSaaS，在 R请求的感知资源时

表2：Petri网模型的参数（h−1）

如果提供（PAv/In−Act），该系统在感兴趣区域中还有 N 个可用资源，可 在节点更替（PAv/In−NAct）情况下用作备用。其他 S 贡献者（P¬AvIn） 可能会随后加入系统或进入感兴趣区域。

在我们使用的模型中，采用指数分布对这些行为进行随机表征，假设 所有相关事件都是由随机原因引起的，因此呈随机分布。通过这种方式获 得了两个广义随机Petri网模型。分布参数的选择也基于现有文献[45]。所 有变迁的速率如表2所示。请注意， λReplacement是通过上一节所述实验 （每30秒更换一次）获得的。需要强调的是，这些速率及其对应的分布是 标记依赖的，因为每一个都代表一个单独的活动或贡献者。这一点在图 15中通过在标记依赖的变迁附近标注#符号来表示。

图16所示的评估结果证明了MCSaaS方法的有效性。事实上