sensors Article
Mobile Autonomous Sensing Unit (MASU): A Framework That Supports Distributed Pervasive Data Sensing Esunly Medina 1 , David Lopez 1 , Roc Meseguer 1, *, Sergio F. Ochoa 2 , Dolors Royo 1 and Rodrigo Santos 3 1 2 3
*
Department of Computer Architecture, Universitat Politècnica de Catalunya, Barcelona 08034, Spain;
[email protected] (E.M.);
[email protected] (D.L.);
[email protected] (D.R.) Computer Science Department, Universidad de Chile, Beauchef 851, Edificio Norte, 3er Piso, Santiago 8370459, Chile;
[email protected] Department of Electrical Engineering, Universidad Nacional del Sur—CONICET, Bahia Blanca 8000, Argentina;
[email protected] Correspondence:
[email protected]; Tel.: +34-93-413-7102
Academic Editors: Vladimir Villarreal and Carmelo R. García Received: 8 May 2016; Accepted: 5 July 2016; Published: 9 July 2016
Abstract: Pervasive data sensing is a major issue that transverses various research areas and application domains. It allows identifying people’s behaviour and patterns without overwhelming the monitored persons. Although there are many pervasive data sensing applications, they are typically focused on addressing specific problems in a single application domain, making them difficult to generalize or reuse. On the other hand, the platforms for supporting pervasive data sensing impose restrictions to the devices and operational environments that make them unsuitable for monitoring loosely-coupled or fully distributed work. In order to help address this challenge this paper present a framework that supports distributed pervasive data sensing in a generic way. Developers can use this framework to facilitate the implementations of their applications, thus reducing complexity and effort in such an activity. The framework was evaluated using simulations and also through an empirical test, and the obtained results indicate that it is useful to support such a sensing activity in loosely-coupled or fully distributed work scenarios. Keywords: distributed pervasive data sensing; pervasive monitoring; mobile collaboration; software development framework
1. Introduction Pervasive monitoring allows capturing and characterizing people’s practices and patterns in various scenarios, such as learning, shopping or homecare. This monitoring requires the capture of data from different kinds of sensors, across the different situations and contexts that the people might encounter in their everyday lives. Although smartphones can be used to address this activity, these devices still have some limitations to perform pervasive monitoring; for instance: (1) their sensors are not very accurate; (2) the continuous sensing process involves a high energy cost [1], and their computing power is usually not enough to perform computationally intensive classifications and inference tasks (e.g., speech or image recognition) [2]. These limitations have promoted the appearance of both collaborative sensing techniques that help improve data quality and save energy [3–6], and also software platforms that help developers create monitoring applications for smartphones. Most these solutions involve the use of centralized components, or assume homogeneity of the devices’ capabilities or stability of the communication links among the participants [7–9]. These assumptions do not represent a limitation for conducting Sensors 2016, 16, 1062; doi:10.3390/s16071062
www.mdpi.com/journal/sensors
Sensors 2016, 16, 1062
2 of 27
some monitoring activities (e.g., crowdsensing [10] or participatory sensing [11]); however, they do for monitoring collaboration scenarios where the smartphone users perform loosely-coupled mobile interactions [12]; for instance, firemen performing first response activities or students involved in mobile learning activities. In order to support the development of distributed pervasive monitoring applications for this particular niche (i.e., loosely-coupled mobile work), we present a framework named Mobile Autonomous Sensing Unit (MASU) that is able to collect and share data among devices involved in smartphone-based pervasive sensing. Although this framework was initially conceived to support pervasive monitoring in mobile learning contexts, it can also be used to perform pervasive monitoring in a variety of work scenarios. The MASU framework was evaluated to determine its performance and usage costs in terms of energy, computation and network traffic. The evaluation included simulations and also an empirical test. The preliminary results indicate that this infrastructure is not only useful for data gathering and sharing, but also for reducing the battery consumption of the devices involved in the sensing tasks. The next section presents and discusses the related work. Section 3 describes the design of the proposed pervasive sensing framework, including its architecture, services, interaction protocols, messages and data retrieval mechanism. Sections 4 and 5 describe the evaluation process using simulation and an empirical test, respectively, and discuss the obtained results. Section 6 presents a comparison between well-known sensing frameworks and the one presented in this paper, by showing similarities and differences. Finally, Section 7 presents our conclusions and possible future work. 2. Related Work Pervasive applications that monitor loosely-coupled mobile work should consider the dynamism of the interaction context, in which smartphone users can be while performing a collaborative activity. Therefore, pervasive data sensing solutions should provide services for implicit and explicit data sharing, and these services should work in both infrastructure-based and ad hoc networks. Participatory sensing [2,11] usually involves the voluntary cooperation between smartphone users in order to collect, analyse and share information about their local context. These processes usually require explicit participation of the user, who is actively involved in the data collection process. An example of this voluntary information sharing is when an individual uses his smartphone to take a picture, provide descriptions of his particular context (e.g., in a meeting, cycling, etc.) or tags his current location (e.g., my favourite cafeteria, my brother’s place, etc.). Similarly, mobile crowdsensing [10,13,14] also requires user intervention to provide sensor information. However, it reuses user-entered data from Internet services and social networking sites. These capabilities have allowed people to become active participants of these processes and get a benefit for that. Some services based on these sensing paradigms allow people, for example to identify opportunities for hitchhiking [15] or to evaluate their personal security [16]. Typically, these sensing approaches use infrastructure-based communication that allows mobile sensors to access centralized data repositories, which are in charge of supporting the data sharing process. These approaches are not particularly designed to perform opportunistic sensing, where heterogeneous mobile devices (i.e., devices with distinct sensing capabilities) collaborate to provide each other with contextual data that each device alone could not otherwise sense. For this reason, a different sensing approach is also necessary. Opportunistic sensing [2,6], provides a method to capture contextual information automatically from sensors available in the smartphone. In this case, the user is not directly involved in the data collection process and the information is sensed unobtrusively. Although there are various applications that provide specific solutions for addressing particular problems, most of them are not easy to use in other contexts, and also require specialized development expertise. For this reason, the development of these types of applications requires to address various challenges related to the limitations of the communication networks and types of interactions in
Sensors 2016, 16, 1062
3 of 27
certain contexts, such as unstable communication links, devices heterogeneity, energy constraints, user mobility patterns, etc. There are also platforms that consider unstable communication scenarios and provide interaction autonomy to the devices participating in a sensing activity, for instance, by using mobile ad hoc networks (MANETs). Nevertheless, they do not take advantage of long-range communication infrastructures when they are available (e.g., Internet connections, cellular networks, etc.) [8,17], which limits the system capability to interact with remote components when they are available. Given the communication in MANETs is usually unstable, there are some proposals (e.g., to support mobile sensing task scheduling [9,18]) that are focused on reducing the data missing rate of mobile nodes, and thereby increasing the gathering rate of the required sensing data. Some other platforms, like Remora [19] and C-SPINE [20] are designed to exploit device proximity through body sensor networks (BSN). Neighbouring BSNs can opportunistically perform freeriding by using the overheard data from all in-range sensors. The contrary approach is adopted by middleware, like MobIoT [21], which support mobile collaborative sensing at a large scale. However, most these middleware have scalability limitations that are addressed by controlling the participation of redundant sensing devices. These solutions are limited to support pervasive sensing since they compel software designers to choose between short- or large-range data sensing. Using a hybrid approach platform like METIS [22] (an adaptive smartphone-based sensing system) it is possible to support social sensing by combining smartphones with other devices. This platform decides whether to perform sensing tasks on the local smartphone or on fixed remote sensors, considering the energy costs and the mobility patterns of the user. Following the same line, the middleware proposed in [23] supports collaborative sensing by allowing smartphones to delegate part of their sensing activities to other nearby devices. This leads to an overall reduction in the battery drain of the group of devices involved. Similarly, the CoMon [8] platform supports cooperation, by sharing sensed data among nearby smartphone users, to address the energy drain problem caused by continuous sensing and processing tasks required by monitoring applications. This platform is focused on the detection of potential collaborators (mobile users) and trying to maximize the mutual benefits for the people involved. These last three platforms only try to maximize the benefits of collaborative sensing (in terms of energy consumption) by using smartphones. The lack of capability to involve heterogeneous devices limits their support for pervasive sensing. Some other platforms, like EasiSee [24], have addressed quite well the sensing scenario by adopting a pervasive approach; in this case, for counting and classifying vehicles in real-time. However, the solution is ad hoc to the problem being addressed (e.g., it considers sensing activities conducted only by a camera and magnetic sensors), which limits its usefulness in other application scenarios. Provided that pervasive monitoring usually entails diverse types of sensing devices and is dynamic in terms of communication support and users mobility patterns, the monitoring platform should also provide context-awareness [25] and support for device heterogeneity (i.e., allowing interoperability and considering hardware and energy limitations). In this sense, most of the platforms described in this section include centralized components, require a stable communication link to access remote resources, do not support heterogeneous devices or are specific for a certain application domain. Any of these issues jeopardize the suitability of the platforms to support pervasive sensing in various application domains. Next section presents the MASU framework, which is proposed to deal with these issues. 3. The MASU Framework The MASU framework supports opportunistic mobile collaborative sensing activities performed over dynamic and distributed communication scenarios that include both stable and unpredictable communication links. This framework is based on what we call MASU units (potentially mobile nodes), which are smartphones or other devices that run the MASU software infrastructure and interact among them in a peer-to-peer fashion. These nodes not only can work autonomously and
Sensors 2016, 16, 1062
4 of 27
perform independent sensing tasks, but also interact opportunistically with other units to perform Sensors 2016, 16, 1062 4 of 27 collaborative sensing. In this sense, the framework allows nodes to act as both consumers and providers of sensing services while In preserving autonomy.allows The collaboration among a group ofand MASU collaborative sensing. this sense,their the framework nodes to act as both consumers sensing services while preserving their autonomy. The collaboration among a group of by units providers allows theofprovision of complex and high quality sensing services that could not be provided MASUsensing units allows the provision of complex quality sensing services that could not quality, be individual devices, due to limitations inand theirhigh capabilities (e.g., CPU, memory, sensor provided by individual sensing due to limitations in reason, their capabilities (e.g., CPU, memory, etc.) or to the high cost involved indevices, the sensing tasks. For this the interaction between various sensor quality, etc.) or to the high cost involved in the sensing tasks. For this reason, the interaction units enables a number of collaborative sensing services that are beneficial for the overall group of between various units enables a number of collaborative sensing services that are beneficial for the devices involved in terms of hardware resources, energy consumption and information quality. overall group of devices involved in terms of hardware resources, energy consumption and In order to model information quality.a variety of processes and services involved in a collaborative sensing activity, the MASU framework defines a number of and rolesservices played by different units. A role canactivity, be seen as In order to model a variety of processes involved in a collaborative sensing a particular set of services provided and/or of consumed by aby specific unit. A MASU unitbe can play the MASU framework defines a number roles played different units. A role can seen as one a or more particular roles within a collaborative sensing activity. Moreover, it can have various instances theorsame set of services provided and/or consumed by a specific unit. A MASU unit can playof one more within at a collaborative sensing activity. Moreover, it can in have various instances of collaborative the same type of roleroles activated the same time. A unit can also participate a number of parallel type of role activated at the same time. A unit can also participate in a number of parallel collaborative sensing activities, interacting simultaneously with units that are part of different activities and playing sensing activities,roles interacting simultaneously with units that part different activities andnode the same or different in them. In other words, a MASU unitarecan be of seen as an autonomous playing the same or different roles in them. In other words, a MASU unit can be seen as an playing one or more roles in various work sessions. autonomous node playing one or more roles in various work sessions. Figure 1 shows an overview of the MASU work scenario, when two collaborative sensing activities Figure 1 shows an overview of the MASU work scenario, when two collaborative sensing are being performed among a group of units. shows different groups groups of unitsofthat, activities are being performed among a groupItof units.two It shows two different unitsaccording that, to theaccording roles played them, provide and/or consume diverse diverse servicesservices withinwithin the activity they are to theby roles played by them, provide and/or consume the activity participating. In addition, one of the units is participating in both sensing activities so that they are participating. In addition, one of the units is participating in both sensing activities so that itit can contribute to and benefit from both them. can contribute to and benefit fromof both of them.
Figure 1. Overview of the MASU work scenario.
Figure 1. Overview of the MASU work scenario.
The process to conceive, develop and evaluate the MASU framework was inspired in the design
The process to conceive, and evaluate the MASU inspired in the design science research approachdevelop [26], which is a problem solvingframework process thatwas involves seven steps science research approach [26], which is problem that involves seven steps (guidelines) (guidelines) for finding a solution toathe stated solving problemprocess (an information system). Following these guidelines we defined thestated MASUproblem design (guideline 1) for addressing pervasive these sensing problem we for finding a solution to the (an information system).the Following guidelines (guideline 2). We evaluated the performance and capability of such a design using simulations and 2). defined the MASU design (guideline 1) for addressing the pervasive sensing problem (guideline also through an empirical test using a MASU-based application (guideline 3). The evaluation results We evaluated the performance and capability of such a design using simulations and also through indicated the framework was able to manage the device heterogeneity in a distributed way, an empirical test using a MASU-based application (guideline 3). The evaluation results indicated the considering various types of communication links among nodes; which represents a clear framework was able to manage the device heterogeneity in a distributed way, considering various contribution for the development of pervasive sensing solutions (guideline 4). The MASU design was typesrepresented of communication links amongcomponent nodes; which represents a clear contribution forsolutions the development using contextualized diagrams (guideline 5), and these design were of pervasive sensing solutions (guideline 4). The MASU design was represented using contextualized revised through periodic formal technical reviews [27] that helped us find effective solutions to the component 5),(guideline and these6).design were revised periodic formal design diagrams challenges (guideline of the system Finally,solutions the design results were through communicated to the technical reviews [27] involved that helped usMASU find effective the to design challenges the system technical audience in the evaluationsolutions process into order help them make anofeffective use of6). theFinally, framework 7). were communicated to the technical audience involved in the (guideline the (guideline design results MASU evaluation process in order to help them make an effective use of the framework (guideline 7).
Sensors 2016, 16, 1062
5 of 27
Sensors 2016, 16, 1062
5 of 27
The design evaluation methods used during the development of MASU were diverse; each one was The designon evaluation methods used development of MASU were diverse; each one chosen depending the development stageduring of thethe product. Particularly, architecture analysis (design was chosen depending on the development stage of the product. Particularly, architecture analysis inspections [27]) was used during system conception and evolution. Then simulations were utilized (design inspections [27]) was used during system conception and evolution. Then simulations were to determine the performance and capability of the system before implementing it. These properties utilized to determine the performance and capability of the system before implementing it. These of theproperties system were using black-box testing, and itsand usefulness was was evaluated using of the verified system were verified using black-box testing, its usefulness evaluated usinga real application scenario; particularly, a MASU-based application was developed to conduct a pervasive a real application scenario; particularly, a MASU-based application was developed to conduct a sensing process. The steps of the design science research approach followed in the development pervasive sensing process. The steps of the design science research approach followed in the and evaluation of the MASU framework areMASU described more in details in the nextinsubsections. development and evaluation of the framework are described more details in the next subsections.
3.1. System Architecture 3.1. System Architecture
The architecture of the MASU framework includes two separate layers (Figure 2): the Control TheSensing architecture the MASU framework two separate layers (Figure 2): the Control of Tier and the Tier,ofwhich interact amongincludes themselves and define two different categories Tier and the Sensing Tier, which interact among themselves and define two different categories of roles. This is a crosslayer architecture that enables interactions with other layers of the computing roles. This is a crosslayer architecture that enables interactions with other layers of the computing system, and benefits from the information that other layers may provide (i.e., hardware and network system, and benefits from the information that other layers may provide (i.e., hardware and network information). The particular pervasive sensing applications developed over MASU are in the upper information). The particular pervasive sensing applications developed over MASU are in the upper layer,layer, and therefore theythey consume thethe services by the theframework. framework. and therefore consume servicesprovided provided by
Figure 2. Architecture of the MASU Framework.
Figure 2. Architecture of the MASU Framework.
The Control Tier provides all the services required for the management and monitoring of the
The Control Tier provides the services required thewithin management and monitoring overall collaborative sensingall activity, coordinating the for tasks the activity and also amongof the different activities,sensing if required. This layer is also in charge of managing of resources within overall collaborative activity, coordinating the tasks within the theuse activity and also among each sensing device (MASU unit). different activities, if required. This layer is also in charge of managing the use of resources within Thisdevice layer includes each sensing (MASU two unit).roles: Manager and Monitor, which interact among themselves to coordinate the operation of this tier and provide the collaborative sensing services. Therefore, the This layer includes two roles: Manager and Monitor, which interact among themselves to Control Tier performs role selection and activation functions, and it also has control over the Sensing coordinate the operation of this tier and provide the collaborative sensing services. Therefore, Tier. This layer also monitors the state of the device’s hardware components, such as battery level, the Control Tier performs selection activation functions, and it(hardware also has control over the processor load, memoryrole available andand quality of the sensors available monitoring). Sensing Tier. This layer also state to of the the underlying device’s hardware as battery Moreover, it keeps trackmonitors of eventsthe related network components, infrastructure,such including level,topological processor changes, load, memory and quality the sensors (hardware monitoring). networkavailable traffic, congestion andof delay (networkavailable monitoring). Such monitoring Moreover, related toand themake underlying network infrastructure, including allows it thekeeps MASUtrack unitsofto events be context-aware appropriate role selection and activation topological changes, network traffic, congestion and delay (network monitoring). Such monitoring allows the MASU units to be context-aware and make appropriate role selection and activation decisions, as well as to adapt to the unpredictability of dynamic environments, activating or deactivating roles accordingly.
Sensors 2016, 16, 1062
6 of 27
Sensors 2016, 16, 1062
6 of 27
decisions, as well as to adapt to the unpredictability of dynamic environments, activating or deactivating roles accordingly. The Sensing Sensing Tier, Tier,which whichisisinincharge chargeofof performing specific data sensing sharing tasks, performing thethe specific data sensing andand sharing tasks, has has distinct Producer, Consumer, andThese Relay. These roles interact among four four distinct roles: roles: Producer, Consumer, Storage Storage and Relay. roles interact among themselves themselves theofprovision of complex sensing services. enabling theenabling provision complex data sensingdata services. 3.2. Node Node Structure Structure 3.2. The node MASU platform can play more the roles defined the framework. The noderunning runningthethe MASU platform can one playorone orofmore of the rolesindefined in the Figure 3 represents role composition structure of astructure MASU node. framework. Figure 3the represents the role composition of a MASU node.
Figure of aa MASU MASU node. node. Figure 3. 3. Structure Structure of
A node can also have various instances of the same role activated at the same time, but in A node can also have various instances of the same role activated at the same time, but in different different sensing sessions. These roles are dynamic and can evolve over time according to the sensing sessions. These roles are dynamic and can evolve over time according to the characteristics of characteristics of the network infrastructure, the mobility of the nodes, or changes in the number of the network infrastructure, the mobility of the nodes, or changes in the number of nodes involved in nodes involved in the activity. the activity. In order to conduct a collaborative sensing activity, it is necessary that at least two nodes are In order to conduct a collaborative sensing activity, it is necessary that at least two nodes are willing willing to collaborate, and such collaboration implies some benefit for the participating nodes. to collaborate, and such collaboration implies some benefit for the participating nodes. Otherwise, the Otherwise, the MASU units would be working independently, in autonomous mode. A node MASU units would be working independently, in autonomous mode. A node performing sensing performing sensing activities independently in a stand-alone fashion, would be at the same time activities independently in a stand-alone fashion, would be at the same time Producer and Consumer Producer and Consumer of its own sensing services. It would, therefore, only require the activation of its own sensing services. It would, therefore, only require the activation of particular Producer roles of particular Producer roles for the required services and the corresponding Consumers of such for the required services and the corresponding Consumers of such services. By contrast, in a scenario services. By contrast, in a scenario where a set of nodes is working collaboratively to perform a where a set of nodes is working collaboratively to perform a sensing activity, there can be diverse sensing activity, there can be diverse combinations on the number and type of roles that must be combinations on the number and type of roles that must be activated in different nodes, depending on activated in different nodes, depending on the requirements of the activity and on the characteristics the requirements of the activity and on the characteristics and capabilities of the participating devices. and capabilities of the participating devices. However, this collaborative sensing activity would However, this collaborative sensing activity would require that at least one Manager, one Monitor, require that at least one Manager, one Monitor, one Producer and one Consumer roles be activated one Producer and one Consumer roles be activated in the activity. in the activity. Typically, most nodes collaborating in a sensing activity will have at least a Consumer role Typically, most nodes collaborating in a sensing activity will have at least a Consumer role activated, because we assume that they will be interested in at least part of the sensed data. activated, because we assume that they will be interested in at least part of the sensed data. Nevertheless, if some of the MASU units participating in the activity are Internet of Things (IoT)-based Nevertheless, if some of the MASU units participating in the activity are Internet of Things devices, there can be cases where they would require the activation of a Consumer role (e.g., a shared (IoT)-based devices, there can be cases where they would require the activation of a Consumer role display receiving an image), but in other cases, they would only provide sensing services and would (e.g., a shared display receiving an image), but in other cases, they would only provide sensing not have any Consumer role active (e.g., sensors in smart buildings). services and would not have any Consumer role active (e.g., sensors in smart buildings). There can be two different kinds of Producer roles: Collector and Processor, depending on the There can be two different kinds of Producer roles: Collector and Processor, depending on the type of information that they generate or in the method used by them to obtain it. Moreover, Relay type of information that they generate or in the method used by them to obtain it. Moreover, Relay and Storage roles can be activated depending on the network conditions and on the characteristics of and Storage roles can be activated depending on the network conditions and on the characteristics of the sensing activity and of the participating nodes. the sensing activity and of the participating nodes. 3.3. Roles and Services 3.3. Roles and Services MASU units playing some roles can interact with each other by subscribing to the services MASU units playing some roles can interact with each other by subscribing to the services provided by specific roles. When a unit subscribes to a particular role, it is then, subscribing to all the provided by specific roles. When a unit subscribes to a particular role, it is then, subscribing to all the services provided by such a role. The role manager acts as coordinator of the collaborative sensing services provided by such a role. The role manager acts as coordinator of the collaborative sensing activity, and there can be various managers coordinating the activity. The monitors supervise the activity, and there can be various managers coordinating the activity. The monitors supervise the performance of MASU units. The producers perform sensing tasks using any of the sensors available
Sensors 2016, 16, 1062
7 of 27
Sensors 2016, 16, 1062
7 of 27
in the device. The consumers are typical service consumers that use the data sensed by the producers. performance of MASU units. The producers perform sensing tasks using any of the sensors available Theyincan directly the producers, and that also use through storages The storage the access device.this Thedata consumers are from typical service consumers the data sensedor byrelays. the producers. acts They as ancan active repository be subscribed to the datastorages obtained from the accessdata this data directlythat fromcan the producers, and also through or relays. Theproducers. storage The acts relays are in charge to retransmit recent data generated by producers, to consumers thatThe lost or as an active data repository that can be subscribed to the data obtained from the producers. could not receive the data sent by the producers properly. relays are in charge to retransmit recent data generated by producers, to consumers that lost or could Figure 4 shows ansent example a collaborative not receive the data by the of producers properly.sensing activity involving four MASU units and FigureThe 4 shows an examplethe of interactions a collaborative sensingroles. activity involving to four MASU unitsManager and various roles. arcs represent between According Figure 4, the various roles. The arcs represent the interactions between roles. According to Figure 4, the Manager activates all the roles present in the activity and also performs service monitoring over them. On the activates all the roles present in the activity and also performs service monitoring over them. On theand other hand, the Monitor performs network monitoring, service monitoring over the Manager other hand, the Monitor performs network monitoring, service monitoring over the Manager and hardware monitoring over the four participating units. In the activity we have two Producers: hardware monitoring over the four participating units. In the activity we have two Producers: one one acting as Collector and the other as Processor. In this case, the Processor receives the data acting as Collector and the other as Processor. In this case, the Processor receives the data sensed sensed previously by the Collector, performs some classification or inferences tasks and sends the previously by the Collector, performs some classification or inferences tasks and sends the resulting resulting information to the Storage. Finally, the Storage sends this information to the Consumer. information to the Storage. Finally, the Storage sends this information to the Consumer.
Figure 4. Interactions between MASU roles.
Figure 4. Interactions between MASU roles.
3.4. Internal Mechanisms
3.4. Internal Mechanisms
Three internal mechanisms govern the dynamic of the individual and collective work of the Three units. internal mechanisms govern themechanism. dynamic of the individual and collective work of the mobile Next we briefly explain these
mobile units. Next we briefly explain these mechanism. 3.4.1. Mechanisms for Role Selection and Activation
3.4.1. Mechanisms for Role Selection and Activation
Once the set of devices that will take part in the collaborative sensing activity is determined, all the participating units share Then, theysensing have toactivity select and activate the all Once the set of devices thattheir willhardware take partcapabilities. in the collaborative is determined, local roles in each tier. In this sense, we distinguish between two basic operations: (i) Role Selection the participating units share their hardware capabilities. Then, they have to select and activate the local and Activation in the Control Tier and (ii) Role Selection and Activation in the Sensing Tier. MASUand roles in each tier. In this sense, we distinguish between two basic operations: (i) Role Selection supports dynamic centralized or distributed approaches for conducting this operation. Table 1 shows Activation in the Control Tier and (ii) Role Selection and Activation in the Sensing Tier. MASU supports a summary of the methods followed for the selection of roles in the different Tiers, according to the dynamic centralized or distributed approaches for conducting this operation. Table 1 shows a summary role chosen for the Control Tier. If the role activated in the Control Tier is Dynamic Centralized, the of the methods followed for the selection of roles in the different Tiers, according to the role chosen for selection of roles in this Tier will be determined by the results of the election algorithm. Furthermore, the Control Tier. theinrole in we theonly Control Dynamic the in selection of roles due to the factIfthat thisactivated architecture haveTier one is manager, theCentralized, selection of roles the Sensing in this Tier will be determined by the results of the election algorithm. Furthermore, due to the Tier will be determined by such a manager. Nevertheless, if the role architecture of the Control Tier fact that isindistributed, this architecture we only oneofmanager, the selection roles inand thethat Sensing Tier and will be all the units thathave are part the collaborative sensingofactivity are active determined by such awill manager. if the role of the Control Tier is distributed, have connectivity play theNevertheless, roles of the Control Tier.architecture In addition, the Selection and Activation of roles in the Sensing Tier will be determined by the results of the consensus algorithm. all the units that are part of the collaborative sensing activity and that are active and have connectivity
will play the roles of the Control Tier. In addition, the Selection and Activation of roles in the Sensing Tier will be determined by the results of the consensus algorithm.
Sensors 2016, 16, 1062
8 of 27
Table 1. Role selection and activation mechanisms for the different role settings.
Control Tier Sensing Tier
Dynamic Centralized
Distributed
By leader election algorithm By the manager
All active units By consensus algorithm
3.4.2. Cost Function and Resource Optimization Before selecting and activating roles in the Sensing Tier, the Manager uses the information received from the MASU units to run a Cost Function. The output of this function will determine whether it would be beneficial for the whole group of units to work collaboratively or not. According to such output, the Manager will activate or not the Role Selection and Activation processes in the Sensing Tier. Consequently, if the output of the Cost Function is negative, there will not be collaborative activity and all the units will work independently. The Cost Function determines the viability and usefulness of performing collaborative sensing. The Cost Function is also associated with the results of the Resource Optimization Algorithm (ROA), which helps optimize the use of the resources of the whole group of participating units. The ROA algorithm runs every time that the MASU framework wants to initiate the Role Selection and Activation process in the Sensing Tier. Such an algorithm influences how roles are selected, calculating the estimated costs of the services provided by each one of the roles, and considering the specific requirements of the activity and the characteristics and state of the devices. The ROA determines, for a group of units, who has to activate a given role, who has to collect data from specific sensors and share the results with the rest of the members, etc. The ROA will also decide, between these two Producer units, which one have to capture data from microphone and which one have to sense GPS data. As a result, the rest of the units acting as consumers will deactivate their sensors and wait until they receive the sensed information from these two producer units. 3.4.3. Fault Tolerance Mechanisms Due to the dynamism and uncertainty of some network infrastructures, the MASU defines various fault tolerance mechanisms to deal with changes and failures in active roles that are taking part in a collaborative sensing activity. Such mechanisms can be classified into two categories: tolerant to role failure and tolerant to resource limitations. In order to detect a role failure, the framework monitors the state of each one of the roles that were activated to perform the activity. As explained previously, the manager role monitors the state and behaviour of the services offered by all the other roles. Similarly, both manager and monitor perform mutual service monitoring on each other. Concerning the mechanisms of tolerance to resource limitation (e.g., battery, memory or CPU) the monitor and manager keep track of any event in the collaborative activity: new units join, some disappear, others have poor network connectivity or run out battery, CPU or storage capacity, etc. If any of these changes occur, the Cost Function must be executed to determine the viability and usefulness of the collaborative sensing activity. If the output of this function is positive, the MASU framework will restart the Role Selection and Activation mechanisms for the Sensing Tier, reassigning roles as appropriated according to the results of the ROA algorithm. In the case that many new units join the collaborative sensing activity, it is possible that the cost required to share the sensed data is too high, and therefore the output of the Cost Function is negative. This situation would imply that the collaborative sensing activity is not beneficial for the overall group of participating units so that it has to end. However, this situation could be solved by creating two parallel sensing activities. 3.5. Control Messages In order to support the interaction among units, the MASU framework defines the following six types of messages of the Control Tier. The Unit Detection messages that are used to detect the units
Sensors 2016, 16, 1062 Sensors 2016, 16, 1062
9 of 27 9 of 27
that are present in the collaborative sensing regarding activity. Therefore, messages are present used to monitor changes in the composition of the activity, the units these and roles that are in such changes The in the composition of the activity, that regarding the by units roles areinformation present in such activity. activity. Device Information messages are used theand units to that share about their The Devicecapabilities, Information messages are used the units load to share about their hardware such as that battery level,byprocessor or information available memory. Thehardware Election capabilities, as battery processor load or available memory. Election that messages thatsuch are sent by thelevel, distributed leader election algorithm, used The to select the messages manager and are sent by the distributed leader election algorithm, used to select the manager and monitor roles in monitor roles in a dynamic centralized role architecture of the Control Tier. The Consensus messages a dynamic centralized role architecture of theofControl Tier. Tier, The Consensus messages thatcould are used in that are used in a distributed role architecture the Control so that all the managers agree a distributed roleofarchitecture the Control that all the managers agree on the selection on the selection roles in theofSensing Tier. Tier, The so Role Activation messagescould are only used in case of a of roles inCentralized the Sensing role Tier. architecture The Role Activation are only in case a Dynamic Dynamic of the messages Control Tier. Theyused are sent byof the manager Centralized to activate role architecture of the Tier. They are sent by manager activate roles in the Sensing Tier roles in the Sensing TierControl or to activate the Monitor if itthe fails. Finally,tothe Network Monitoring messages or to activate Monitor it fails. Finally, theisNetwork Monitoring a special type represents a the special typeif of message that necessary for themessages networkrepresents monitoring functions of messageby that necessary for the network monitoring functions performed by the monitor. performed theismonitor. 3.6. Data DataRetrieval RetrievalMechanism Mechanism 3.6. The interactions interactions between between the the different different roles roles of of the the Sensing Sensing Tier Tier enables enables the the MASU MASU units, units, The participating in to to collect and share datadata so that all the can have participating in the the collaborative collaborativesensing sensingactivity, activity, collect and share so that all units the units can the information required by the activity. These interactions are mediated by the Collaborative Sensing have the information required by the activity. These interactions are mediated by the Collaborative ModuleModule (CoSM),(CoSM), which iswhich in charge the data retrieval and allows differential activation of each Sensing is in of charge of the data retrieval and the allows the differential activation one of the ofroles the Sensing Tier (i.e., consumer, producer, storage and relay). of each oneroles of the of the Sensing Tier (i.e., consumer, producer, storage and relay). Thiscomponent component offers offers four fourbasic basicservices servicesfor forservice servicediscovery discovery[28] [28]and andinformation informationdistribution: distribution: This Publish, Find, Find,Subscribe, Subscribe,and andData DataDissemination. Dissemination.Figure Figure 5 shows structure CoSM, which Publish, 5 shows thethe structure of of CoSM, which is is composed by three main modules: the Sensing module, the Data Source Manager and the Data composed by three main modules: the Sensing module, the Data Source Manager and the Data Dissemination Manager. Manager. They They are are responsible responsible of of the the services services that thatenable enablethe thedifferential differential activation activation of of Dissemination the roles roles in in the the Sensing Sensing Tier. the type of the Tier. The TheSensing Sensingmodule moduleinteracts interactswith withthe theother othertwo twototodetermine determine the type data that a particular unit has to sense and the method that it will use to obtain such data. Next we of data that a particular unit has to sense and the method that it will use to obtain such data. Next we explain more more in in detail detail these these components. components. explain
Figure 5. Structure of the Collaborative Sensing Module (CoSM). Figure 5. Structure of the Collaborative Sensing Module (CoSM).
3.6.1. Sensing Module 3.6.1. Sensing Module The Sensing Module (SM) supports the data collection process. The data can be collected from The Sensing Module (SM) supports the data collection process. The data can be collected from the the sensors available on the MASU unit as well as retrieved from other units. For the MASU sensors available on the MASU unit as well as retrieved from other units. For the MASU framework framework a sensor is any hardware or software component that act as source of information. a sensor is any hardware or software component that act as source of information. Consequently, the Consequently, the SM module calls a number of services for accessing any type of sensor available SM module calls a number of services for accessing any type of sensor available on the unit. on the unit. This module can obtain raw data, e.g., from the unit’s physical sensors, but also high level This module can obtain raw data, e.g., from the unit’s physical sensors, but also high level information from other types of sensors. In the former case, a Collector role will be activated, while in information from other types of sensors. In the former case, a Collector role will be activated, while the latter the role played by the unit will be a Processor. The SM also enables the use of data shared in the latter the role played by the unit will be a Processor. The SM also enables the use of data shared by other units as data source and establishes (for every sensor in the unit) the way how it will obtain by other units as data source and establishes (for every sensor in the unit) the way how it will obtain the corresponding data. This way, the activation of particular Producer or Consumers roles can take the corresponding data. This way, the activation of particular Producer or Consumers roles can take place. Accordingly, the SM defines two basic data collection methods: direct and indirect. In the direct place. Accordingly, the SM defines two basic data collection methods: direct and indirect. In the direct method the unit is responsible for capturing data without relying on any other source. In the second method the unit is responsible for capturing data without relying on any other source. In the second case, the sensor receives and processes data that has been previously collected by other units. In the case, the sensor receives and processes data that has been previously collected by other units. In the former case the unit will play a producer role, whereas in the latter it will be a Consumer. former case the unit will play a producer role, whereas in the latter it will be a Consumer.
Sensors 2016, 16, 1062
10 of 27
Sensors 2016, 16, 1062
10 of 27
The SM allows both, remote and local activation of the all the sensing services. This fact facilitates The SM allows both, remote andunits local activation of the all sensing services. Thisactivities fact facilitates the activation of roles in the MASU by the manager forthe collaborative sensing as well the activation of roles in the MASU units by the manager for collaborative sensing activities as well as the independent operation of the units for individual sensing tasks. The SM also allows flexible as the independent operation of the units individual configuration of the sensing frequency andfor waiting times.sensing tasks. The SM also allows flexible configuration of the sensing frequency and waiting times. The data collection methods specified by the SM allow a selective distribution of data from The data collection methods specified by the SM allow a selective distribution of data from different sensors. That is, the MASU framework facilitates a flexible selection of the collection methods different sensors. That is, the MASU framework facilitates a flexible selection of the collection that will be used for each one of the sensors available on the units. For example, it can decide to use methods that will be used for each one of the sensors available on the units. For example, it can decide a direct method to capture data from the accelerometer of the unit but to use an indirect method to to use a direct method to capture data from the accelerometer of the unit but to use an indirect method capture GPS data. to capture GPS data. Figure 6 illustrates a data sharing process conducted by three different units. These units have Figure 6 illustrates a data sharing process conducted by three different units. These units have activated A shares sharesdata datafrom fromtwo twosensors. sensors. This data was collected directly activatedthree threekinds kindsof ofsensors. sensors. Unit Unit A This data was collected directly bybythe unit, which means that these sensors were activated in direct mode. On the other hand, the unit, which means that these sensors were activated in direct mode. On the other hand, thisthis unit activatedininindirect indirectmode, mode, receiving data from ofsensors the sensors ofC. Unit unitalso alsohas hasaa sensor sensor activated receiving data from one one of the of Unit In C. Inaddition, addition,Unit Unit B has sensors activated in indirect this unit will receive all the B has all all its its sensors activated in indirect mode.mode. Then, Then, this unit will receive all the data data from Units A and C. from Units A and C.
Figure 6. 6. Example Example of units. Figure ofdata datasharing sharingbetween between units.
3.6.2. Data Source Manager 3.6.2. Data Source Manager The Data Source Manager (DSM) is in charge of specifying the sensors that the unit will use to The Data Source Manager (DSM) is in charge of specifying the sensors that the unit will use collect the input data. The DSM enables the units to capture diverse types of data from different tosensors collect so thethat input data. The DSM enables the units to capture diverse types of data from different the MASU units can sense different kinds of information and share it with others. sensorsThe so that the MASU unitssupports can sensediverse different kinds of andsuch shareasit with others. MASU framework sensors orinformation data sources, IoT devices, The MASU framework supports diverse sensors or data sources, such as IoT devices, information information repositories, sensors in smart buildings and sensors embedded in commercial repositories, sensors insources smart buildings and sensors embedded in commercial smartphones. These sources smartphones. These must be able to provide information that is relevant for the applications must able(intoour provide that is is relevant relevant for for pervasive the applications and and usersawareness). (in our case, and be users case, information information that monitoring information that is relevant for pervasive monitoring and awareness). Moreover, as stated in [25], Moreover, as stated in [25], any modern mobile ubiquitous system must provide context-awareness any mobile ubiquitous must provide andmodern therefore information aboutsystem the environment that iscontext-awareness providing services and to thetherefore users (ininformation our case, about the environment that is providing services to the users (in our case, the of MASU unit). For the MASU unit). For this reason, the proposed framework supports a wide range data sources thatthis are necessary to provide context-awareness about the of MASU units (what we necessary previouslytocalled reason, the proposed framework supports a wide range data sources that are provide hardware monitoring) asthe well as useful information pervasivecalled monitoring in learning scenarios. context-awareness about MASU units (what we for previously hardware monitoring) as well weinformation specify the different categories of data sources that are supported: asNext, useful for pervasive monitoring in learning scenarios. Next, we specify the different categories of data sources thatdifferentiate are supported: Physical sensors: We can between three kinds of physical sensors: hardware sensors (e.g., accelerometer, GPSdifferentiate or compass), communication sensors (correspond to built-in Physical sensors: We can between three kinds of physical sensors: hardware communication interfaces like Bluetooth, infrared or Wi-Fi), and performance sensors sensors (e.g., accelerometer, GPS or compass), communication sensors (correspond to (that built-in determine battery level, or CPU/memory utilization). communication interfaces like Bluetooth, infrared or Wi-Fi), and performance sensors (that Virtual sensors: In this group we consider information that can be obtained from the device’s determine battery level, or CPU/memory utilization). applications and services; e.g., the screen status, the user’s touch inputs, applications status, log ‚ Virtual sensors: In this group we consider information that can be obtained from the device’s files and notifications. applications and services; e.g., the screen status, the user’s touch inputs, applications status, log Human-based sensors: We include in this category any custom application used to collect files and notifications. information that require explicit user intervention. These types of sensors require the
‚
Sensors 2016, 16, 1062
11 of 27
Human-based sensors: We include in this category any custom application used to collect 11 of 27 information that require explicit user intervention. These types of sensors require the participation of a human user to provide information and create new knowledge [29]. Human-based sensors participation of a human user to provide information and create new knowledge [29]. Humancomplement the implicit sensing process performed automatically by unobtrusive sensors. based sensors complement the implicit sensing process performed automatically by unobtrusive This way we can obtain both objective (e.g., a picture, a quantitative datum, etc.) and subjective sensors. This way we can obtain both objective (e.g., a picture, a quantitative datum, etc.) and (e.g., perception, etc.) information from the user. subjective (e.g., opinion, perception, opinion, etc.) information from the user. ‚ Context sensors: These are modules that collect informationrelated relatedtotothe the user context from Context sensors: These are modules that collect information user context [25][25] from existing repositories; for for instance, the user’s profile, preferences, schedule or performance indicators. existing repositories; instance, the user’s profile, preferences, schedule or performance ‚ Logical sensors: These sensors provide high-level information and they can combine data from indicators. a number Logical sensors: TheseInformation sensors provide information they can combine data from a of sources. fromhigh-level this category usuallyand involves some type of aggregation number of sources. Information from this usually involves some An typeexample of aggregation and processing to interpret the sensed datacategory and contextual information. of logical and processing interpretthat the interprets sensed dataraw anddata contextual information. An example logical sensors could be to a service from an accelerometer to infer of the type of sensors could be a service that interprets raw data from an accelerometer to infer the type of physical activity that the user is performing (e.g., sitting, walking, running, etc.). physical activity that the user is performing (e.g., sitting, walking, running, etc.). In the MASU framework there can be units that act as producers and consumers of the different In the MASU framework there can be units that act as producers and consumers of the different types of data that these categories of sensors provide. MASU units that use an indirect method to types of data that these categories of sensors provide. MASU units that use an indirect method to collect input data from any of these sensors will act as Consumers, whereas units that use a direct collect input data from any of these sensors will act as Consumers, whereas units that use a direct method will fulfil a particular Producer role. In this later case, the MASU units that sense data using method will fulfil a particular Producer role. In this later case, the MASU units that sense data using physical, virtual, sensors can canhave haveaacollector collectorororprocessor processor role, depending physical, virtual,human-based human-based or or context context sensors role, depending onon whether this data require some level of interpretation (e.g., classification, aggregation, processing, whether this data require some level of interpretation (e.g., classification, aggregation, processing, etc.) orornot. that retrieve retrievedata datafrom fromlogical logicalsensors sensors perform further etc.) not.On Onthe theother otherhand, hand, those those units units that to to perform further interpretation tasks always play a Processor role. interpretation tasks always play a Processor role. ‚
Sensors 2016, 16, 1062
3.6.3. Data 3.6.3. DataDissemination DisseminationManager Manager AsAsshown Manager (DDM) (DDM)establishes establishesthree three data shownininFigure Figure 7,7, the the Data Data Dissemination Dissemination Manager data dissemination andServer-Mediated. Server-Mediated. disseminationmechanisms: mechanisms:Broadcast, Broadcast, Point-to-Point Point-to-Point and
Figure7.7. Example Example scenario Figure scenarioof ofdata datadissemination. dissemination.
The broadcast and point-to-point mechanisms offer different methods to create peer-to-peer The broadcast and point-to-point mechanisms offer different methods to create peer-to-peer proximity networks amongst devices. It allows the MASU units to share information directly among proximity networks amongst devices. It allows the MASU units to share information directly among them, without depending on any centralized server. This fact opens up the possibility to integrate the them, without depending on any centralized server. factinteract opens with up the possibility to integrate MASU framework with IoT, allowing that the unitsThis could nearby networked objectsthe MASU framework with IoT, allowing that the units could interact with nearby networked objects and sensors. In the case of broadcast data dissemination, the data sent by a unit can be received byand all the others. On the other hand, the point-to-point mechanism only allow data transfer between
Sensors 2016, 16, 1062
12 of 27
sensors. In the case of broadcast data dissemination, the data sent by a unit can be received by all the others. On the other hand, the point-to-point mechanism only allow data transfer between pairs of units and therefore only the particular unit that was specified as destination of the data can receive and use it. Finally, the Server-Mediated data dissemination allows communication between units that are not in the same local network. This mechanism enables data transfer between two independent groups of units connected to different local networks but reachable through the Internet. For instance, this two groups could be units that are participating in two different collaborative sensing activities. Furthermore, the MASU framework can decide to make use of this server to perform some resource intensive aggregation, processing or classification tasks to optimize the use of local hardware resources of the units. 4. MASU Evaluation Using Simulations The first step in the MASU evaluation process was to determine its usefulness and performance under diverse networking, hardware and mobility conditions, by using simulations. Next we explain this process and the obtained results. 4.1. Simulations Setup In this process we used the ns-3 simulator [30], since it allows us to represent diverse scenarios and collect a number of metrics with the purpose of assessing the impact of the underlying network infrastructure, as well as the mobility patterns of the MASU units, on the framework performance. The ns-3 enables the configuration of the nodes that run the MASU framework, the communication network that supports them and the physical space where they are placed. Consequently, the hardware capabilities of the nodes, their wireless network interfaces, physical position and mobility patterns were configured using this simulation tool. We performed 20 simulations for each particular scenario, and each simulations lasted 20 min. 4.1.1. Nodes and Physical Space We defined a 360 m ˆ 360 m outdoor area to place the nodes. The size was set not only to allow the mobility of the nodes and the creation and evolution of different network topologies, but also considering that diverse everyday activities can take place in such a space. In this area, we placed 40 mobile nodes that represent the autonomous units running the MASU framework. We initially considered all nodes similar, having the same technical features. Therefore, these simulations do not consider the effect of device heterogeneity, which will be addressed in the evaluation of the system prototype. Particularly, we configured the nodes to have the capabilities of a phone equivalent to an iPhone 5 (Apple Inc., Cupertino, CA, USA) or a Samsung Galaxy S5 (Samsung Electronics Co., Suwon, Korea). These devices have an effective Wi-Fi communication range of approximately 80 m in open areas. Table 2 summarizes the general parameters configured in the ns-3 for the simulations. Table 2. Simulation general parameters. Parameter
Value
Simulation time Simulation area Number of nodes Node model Wi-Fi standard Propagation model Transmission power Transmission range
1200 s 360 m ˆ 360 m 40 iPhone 5 IEEE 802.11n YansWifiChannel 0.66 W 80 m
Sensors 2016, 16, 1062
13 of 27
4.1.2. Mobility Patterns The nodes’ movements were modelled using the BonnMotion tool [31], which includes well-known models that represent people’s mobility patterns [32]. For the simulations, the nodes’ speed was set between 0 m/s (static nodes) and 1.5 m/s (walking speed) and three mobility patterns were used: RandomWalk, SLAW, and Nomadic. Table 3 shows the parameters used for the setup of the mobility models considered. Table 3. Parameters of the mobility models of the nodes. Random Walk
Value
Maximum speed Maximum pause
1.5 m/s 60 s
SLAW
Value
Cluster ratio Maximum pause
25 m 60 s
Nomadic
Value
Avg. nodes per group Group size deviation Maximum speed Maximum pause Maximum distance
4 1 1.5 m/s 60 s 15 m
This configuration helped us simulate a dynamic network, where some existing communication links can be lost and new links can appear. Such a configuration represents a realistic scenario (e.g., opportunistic collaboration in a university campus) where people can move within the physical space, and eventually interact with other people that they meet. 4.1.3. Network Infrastructures We configured the simulator to use three different types of networks to support the communication between the nodes: Access Point (AP)-based, Terminal-to-terminal (T2T) and MANET. These wireless network infrastructures, based on the IEEE 802.11 standards, were set according to the proposals presented in [33,34], and they were adapted to be simulated on ns-3. Table 4 shows a detail of the configuration of the ns-3 simulator for the different types of User Datagram Protocol (UDP) messages interchanged in the three network infrastructures considered. Table 4. Message setup for AP, T2T and MANET networks. Variable
AP and T2T
Control messages Data messages
UDP broadcast UDP broadcast
Variable
MANET
Control messages Unit detection messages Data messages Routing protocol messages HELLO interval Transmission control interval
UDP broadcast UDP unicast UDP broadcast 2s 5s
4.1.4. Role Selection and Activation Methods The simulations consider Dynamic Centralized and Distributed role architectures. Therefore, we implemented the three methods defined in the framework for Role Selections and Activation in the
Sensors 2016, 16, 1062
14 of 27
Sensing and Control Tiers: (i) the manager decides; (ii) the leader election algorithm decides or (iii) the consensus algorithm decides. We implemented a distributed leader election algorithm based on the proposals presented in [35,36]. Similarly, the distributed consensus algorithm used in the simulator was based on [37,38]. Sensors 2016, 16, 1062
14 of 27
4.2. Simulation Results 4.2. Simulation Results Next we present the simulations results that show the behaviour of the Control Tier of the MASU Nextfor wethe present the simulations results that show behaviour of the Control Tier of the the MASU framework different network infrastructures andthe mobility patterns. It also considers costs framework for the different network infrastructures and mobility patterns. It also considers the costs of the actions performed by such a tier, in terms of network utilisation. In order to verify that the of theTier actions performed by such a tier, in terms of network utilisation. order to Centralized verify that the Control works as expected, we performed various simulations of theInDynamic and Control Tier works as expected, we performed various simulations of the Dynamic Centralized and the Distributed role architecture approaches considered by the MASU framework and compared the Distributed role architecture approaches considered by the MASU framework and compared them with a Fixed Centralized method (used as baseline), where there is no dynamic selection and them with a Fixed Centralized method (used as baseline), where there is no dynamic selection and activation of roles in the Control Tier. For both approaches we implemented real algorithms in order to activation of roles in the Control Tier. For both approaches we implemented real algorithms in order confirm that the MASU framework behaves as expected. In case of the Dynamic Centralized approach, to confirm that the MASU framework behaves as expected. In case of the Dynamic Centralized we implemented a distributed election algorithm for the selection of a Manager every time it fails. approach, we implemented a distributed election algorithm for the selection of a Manager every time Similarly, in the Distributed approach we implemented a distributed consensus algorithm for the it fails. Similarly, in the Distributed approach we implemented a distributed consensus algorithm for selection of a Producer when necessary. Next we present the evaluation of theofrole of the the selection of a Producer when necessary. Next we present the evaluation the architectures role architectures Control Tier considering different (i) network infrastructures and (ii) mobility patterns. of the Control Tier considering different (i) network infrastructures and (ii) mobility patterns. 4.2.1. Considering Different Network 4.2.1. Considering Different NetworkInfrastructures Infrastructures ForFor thisthis first setset of of simulations patternand andevaluated evaluatedthe the first simulationswe weused usedthe theRandomWalk RandomWalk mobility mobility pattern performance of the MASU framework for various network infrastructures: AP, T2T and MANET. performance of the MASU framework for various network infrastructures: AP, T2T and MANET. As As shown shown in in Figure Figure 8, 8, for for AP AP and and T2T T2T networks networks in in the the Dynamic Dynamic Centralized Centralizedand andthe theDistributed Distributed approaches, thetheaverage when no noControl ControlTier Tierwas wasactive. active. approaches, averagepresence presenceofofthe the Producer Producer increases, increases, when Nevertheless, in in thethe Fixed Centralized both types typesof ofnetworks networksare arenot notgood good Nevertheless, Fixed Centralizedmethod method the the results results for both enough when there is is less than presence,respectively. respectively.Notice Noticethat thatthe the enough when there less than6060and and70 70ofofaverage average Producer Producer presence, results obtained MANETs alwaysthe thesame, same,independently independently of of the the approach approach followed. results obtained forfor MANETs areare always followed.
Figure Performanceofofthe theControl ControlTier Tierfor for different different network network infrastructures. Figure 8. 8. Performance infrastructures.
These results show that the Dynamic Centralized and Distributed approaches considered in the These framework results showallow that the Centralized and Distributed approaches considered in the MASU oneDynamic to achieve significant improvements in comparison to a Fixed MASU framework allow one to achieve significant improvements in comparison to a Fixed Centralized Centralized approach. Next we evaluate the cost required for such improvements, in terms of the approach. Next we evaluate required forforsuch improvements, inand terms of the number of number of messages sent by the the cost algorithms used dynamic role Selection Activation. messages sent by the algorithms used for dynamic role Selection and Activation. For this evaluation, we considered the four (i.e., Unit Detection, Device Information, Election ForConsensus this evaluation, we of considered theoffour (i.e.,messages Unit Detection, Information, Election and messages) the six types control defined Device by the MASU framework as andwell Consensus messages) of the six types of messages defined by the networks MASU framework as the particular messages required by control the routing protocol in MANET (routing as well as theHowever, particularinmessages by the routing in MANET networksrequired (routing messages). the Devicerequired Information messages, weprotocol did not consider the messages for hardware monitoring becauseInformation we cannot measure changes theconsider hardware of the messages). However, in the Device messages, we didofnot thecomponents messages required in the simulator. We only the Device Information messagescomponents sent after a of role for devices hardware monitoring because weconsidered cannot measure changes of the hardware the Selection andsimulator. Activation process in considered the Sensing and/or in the Information Control Tiers messages takes place.sent Thus, we only devices in the We only the Device after a role included messagesprocess sent by in new that for the newplace. Manager selected. Selection andthe Activation thenetwork Sensingnodes and/or inare theunknown Control Tiers takes Thus, we only Therefore, the number of Device Information messages is associated with the number of nodes that are concurrently active when a new Manager is selected. Figure 9 shows a comparison of the number of messages required for the Dynamic Selection and Activation of roles in Fixed Centralized, Dynamic Centralized and Distributed role architectures of the Control Tier. These figures show that the number of messages is very similar for both Dynamic
Sensors 2016, 16, 1062
15 of 27
included the messages sent by new network nodes that are unknown for the new Manager selected. Therefore, the number of Device Information messages is associated with the number of nodes that are concurrently Sensors 2016, 16,active 1062 when a new Manager is selected. 15 of 27 Figure 9 shows a comparison of the number of messages required for the Dynamic Selection and Activation ofand rolesDistributed in Fixed Centralized, Centralized and of Distributed architectures Centralized approaches.Dynamic Nonetheless, the number messages role is slightly smaller of for the Tier. figures show thatcan thebe number of messages is very bothCentralized Dynamic theControl Fixed Centralized approach. This explained by the fact thatsimilar in the for Fixed Sensors 2016, 16, These 1062 15 of 27 Centralized andfirst Distributed Nonetheless, the the number of messages slightlyroles smaller approach, the node thatapproaches. join the network plays both Manager and the isMonitor and Centralized and Distributed approaches. Nonetheless, the number of messages is slightly smaller for for the such Fixeda Centralized approach. Thiscounting can be explained by the fact that in the Centralized when node fails, the system stop the messages that this node wasFixed monitoring. the Fixed Centralized approach. This can be explained by the fact that in the Fixed Centralized approach, the first node that join the network plays both the Manager and the Monitor roles and when approach, the first node that join the network plays both the Manager and the Monitor roles and such a node fails, the system stop counting the messages that this node was monitoring. when such a node fails, the system stop counting the messages that this node was monitoring.
(a)
(b)
(a)
(b)
(c)
(c) Figure 9. Cost of the different role architectures of the Control Tier for different network architectures. Figure 9. Cost of the different role architectures of the Control Tier for different network architectures. Figure 9. Cost of the different role architectures theDistributed. Control Tier for different network architectures. (a) Fixed Centralized; (b) Dynamic Centralized;of(c) (a) Fixed Centralized; (b) Dynamic Centralized; (c) Distributed. (a) Fixed Centralized; (b) Dynamic Centralized; (c) Distributed.
From Figure 9 we can conclude ofmessages messages required by the framework depends From Figure 9 we can concludethat thatthe the number number of required by the framework depends on the infrastructure, and correlated with the number of nodes thedepends network. onnetwork theFigure network infrastructure, anditthat itisispositively positively correlated with the number of nodes of theofnetwork. From 9 we can conclude the number of messages required by the framework Thus, AP infrastructures produce a smaller number of messages, followed by T2T and MANET Thus, AP infrastructures produce a smaller number of messages, followed by T2T and MANET on the network infrastructure, and it is positively correlated with the number of nodes of the network. networks. networks. Thus, AP infrastructures produce a smaller number of messages, followed by T2T and MANET networks. Considering Different Mobility Patterns 4.2.2. Considering Different Mobility Patterns 4.2.2.4.2.2. Considering Different Mobility Patterns In order to evaluate the impact of the units mobility patterns on framework performance we
In Inorder ordertotoevaluate evaluatethe theimpact impactofofthe theunits unitsmobility mobilitypatterns patternson onframework frameworkperformance performancewe we simulated nodes when there is no Control Tier available. Figure 10 shows the average presence of simulated available. Figure Figure10 10shows showsthe theaverage averagepresence presenceof simulatednodes nodes when when there there is is no Control Tier available. Producer considering the different network infrastructures and mobility patterns. RandomWalk and ofProducer Producer considering different infrastructures mobility patterns. RandomWalk considering thethe different network andand mobility patterns. RandomWalk Nomadic mobility patterns achieve anetwork similarinfrastructures percentage of presence of the Producer in AP and T2T and and Nomadic mobility patterns achieve a similar percentage of presence of the Producer in AP Nomadic mobility patterns achieve a similar percentage of presence the Producer in AP andand T2T networks, whereas Self-similar Least Action Walk (SLAW) achieves aof slightly higher percentage. T2T networks, whereas Self-similar Least Action Walk (SLAW) achieves a higher percentage. networks, whereas Self-similar Least Action Walk (SLAW) achieves a slightly percentage. Nevertheless, the improvement achieved by the SLAW mobility pattern is not significant. Nevertheless, Nevertheless,the theimprovement improvementachieved achievedby bythe theSLAW SLAWmobility mobilitypattern patternisisnot notsignificant. significant.
Figure 10. Presence of the Producer for different mobility patterns when no Control Tier is available.
On10. thePresence other hand, achieve the patterns maximum percentage, regardless of the Figure of theMANET Producernetworks for different mobility when no Control Tier is available. Figure 10. Presence of the Producer for different mobility patterns when no Control Tier is available. mobility pattern. These results suggest that more realistic mobility patterns yield to higher presence of Producer. This canMANET be explained due to the fact that patterns consider the social tendencyof the Onthethe other hand, networks achieve thesuch maximum percentage, regardless of human interactions and therefore people’s inclination to form groups. mobility pattern. These results suggest that more realistic mobility patterns yield to higher presence
of the Producer. This can be explained due to the fact that such patterns consider the social tendency of human interactions and therefore people’s inclination to form groups.
Sensors 2016, 16, 1062
16 of 27
On the other hand, MANET networks achieve the maximum percentage, regardless of the mobility Sensors 2016, 16, 1062 16 the of 27 pattern. These results suggest that more realistic mobility patterns yield to higher presence of Producer. can be explained due to the fact that such patterns consider the social tendency of27 Sensors 2016,This 16, 1062 16 of Then, we evaluated the performance of an ideal to Control Tier as well as the average presence of human interactions and therefore people’s inclination form groups. Consumers for the different mobility patterns considered. shows that the presence Then, evaluated the of an ideal ControlFigure Tier as as11 well asthe the average presenceof Then,we we evaluated the performance performance Control Tier well as average presence of slightly across mobility patterns and network In ofConsumers Consumersvaries forthe the different mobility patterns considered. Figureinfrastructures. presence ofof Consumers for different mobility patterns considered. Figure 11 shows shows that that the theaddition, presencethe performance of anslightly ideal Control in terms of presence of the Producer is similar all mobility Consumers across mobility patterns and infrastructures. InInfor addition, the Consumersvaries varies slightly acrossTier mobility patterns andnetwork network infrastructures. addition, the patterns in T2T and MANETs, while RandomWalk obtains slightly better results for AP networks. performance performanceofofan anideal idealControl ControlTier Tierininterms termsofofpresence presenceofofthe theProducer Producerisissimilar similarfor forall allmobility mobility Thus, the variation the results obtained for different mobility patterns are not significant. patterns inin T2T MANETs, while RandomWalk obtains slightly better results for patterns T2Tand andin MANETs, while RandomWalk obtains slightly better results forAP APnetworks. networks. Thus, significant. Thus,the thevariation variationininthe theresults resultsobtained obtainedfor fordifferent differentmobility mobilitypatterns patternsare arenot not significant.
Figure 11. Presence of the Producer and the Consumers for different mobility patterns using an ideal Control Tier. Figure11. 11.Presence Presenceofofthe theProducer Producerand andthe theConsumers Consumersfor fordifferent differentmobility mobilitypatterns patternsusing usingan anideal ideal Figure Control Tier. Control Tier. of the Simulation Results 4.2.3. Discussion
4.2.3.Discussion Discussion theSimulation Simulation Results All previous suggest Results that MANET networks can provide an interesting alternative to 4.2.3. ofofresults the support pervasive data sensing in dynamic scenarios, since they guarantee higher node presence Allprevious previousresults resultssuggest suggestthat thatMANET MANET networks canprovide provide aninteresting interesting alternative All networks can an alternative toto values (especially, Consumers since the Control Tier of the framework already deals with the supportpervasive pervasivedata datasensing sensinginindynamic dynamicscenarios, scenarios,since sincethey theyguarantee guaranteehigher highernode nodepresence presence support presence of Producers), regardless of the mobility patterns considered. Thisalready fact means that higher values (especially, Consumers since the Control Tier of the framework deals with the values (especially, Consumers since the Control Tier of the framework already deals with thedata presence data availability is possible using this types of networks since Consumers can receive from presence of Producers), regardless of the mobility patterns considered. This fact means that higher ofProducers Producers), regardless of fluctuations the mobility considered. This and fact means that conditions higher dataof regardless of the inpatterns theofcommunication links the mobility data availability is possible using this types networks since Consumers can receive data from availability is possible using this types of networks since Consumers can receive data from Producers the nodes. regardless of the fluctuations in the communication links and the mobility conditions of Producers regardless of the fluctuations the communication links the mobility conditions of the that nodes. The explanation for thisinhigh data accessibility canand be found in Figure 12. It shows more the The nodes. explanation for this high data accessibility can be found in Figure 12. It shows that more than than The 50% explanation of the time that the is accessibility present in thecan network it is in located more than one hop away thisProducer high data beisfound Figure 12.one It shows thatfrom more 50% of the the Consumers. time that thefor Producer iseven present in where the network it located more than hopthe away from There are cases the Consumers receive data from Producer than 50% of the time that the Producer is present in the network it is located more than one hop away the Consumers. There are hops even away. cases where the Consumers receive data from the Producer when it is when it isConsumers. at four or five There are even cases where the Consumers receive data from the Producer atfrom four the or five hops away. when it is at four or five hops away.
Figure12. 12.Percentage Percentageofofpresence presenceofofthe theProducer Producerversus versusthe thenumber numberofofhops hopsininMANET MANETnetworks. networks. Figure Figure 12. Percentage of presence of the Producer versus the number of hops in MANET networks.
These benefits of MANETs come at the expense of a higher number of messages that have to be These benefits of MANETs come at the expense of a higher number of messages that have to be transmitted over theofnetwork, ascome represented in Figure 13. This figure shows the average number of These over benefits MANETs at the expense a higher number of messages thatnumber have toof be transmitted the network, as represented in Figureof13. This figure shows the average messages that are transmitted over the network for different network infrastructures. The number transmitted the network,over as represented Figure 13. This figure shows the average numberofof of messages thatover are transmitted the networkinfor different network infrastructures. The number messages is significantly higher in MANETs due to the fact that the data messages transmitted from messages that are transmitted over the network for different network infrastructures. The number of the Producer to the Consumers UDP unicast 1). fact For this Producer has to sendfrom one messages is significantly higherare in MANETs due(1totothe thatreason, the datathe messages transmitted message to each one of the Consumers that are within the network. Thus, the number of data the Producer to the Consumers are UDP unicast (1 to 1). For this reason, the Producer has to send one messages haseach a direct with the that number activethe Consumers. contrast, in AP and T2T message to one correlation of the Consumers are of within network. By Thus, the number of data networks messages are UDP (1 of to active all) so Consumers. the number By of messages has positive messages the has data a direct correlation with broadcast the number contrast, in APa and T2T correlation with the number of active Producers. networks the data messages are UDP broadcast (1 to all) so the number of messages has a positive
Sensors 2016, 1062 Sensors 2016, 16,16, 1062
1717 ofof 2727
The higher cost related to the number of messages in MANETs is compensated by the fact that messages is significantly in MANETs to the that the receive data messages transmitted fromby these types of networks higher allow that a higher due number of fact units could the information sensed the Producer to the Consumers are UDP unicast (1 to 1). For this reason, the Producer has to send Producers. However, if the number of Consumers is too high, this cost could lead to network one message which to eachwould one ofalso the suppose Consumers are within the network. Thus, the number of data congestion, thatthat the MASU framework will not be able to work properly messages has a direct correlation withitthe number of active Consumers. By contrast, AP scalability and T2T under those conditions. As a result, would be necessary to find a solution to dealin with networks data with messages are number UDP broadcast (1 to sent all) so the number of messages has a positive problemsthe related the high of messages through the network in MANET. correlation with the number of active Producers.
Figure13. 13.Average Averagenumber numberofofmessages messagesfor fordifferent differentnetwork networkinfrastructures. infrastructures. Figure
5. MASU Empirical Evaluation The higher cost related to the number of messages in MANETs is compensated by the fact that In order to evaluateallow empirically the proposed framework, a fully distributed mobile application these types of networks that a higher number of units could receive the information sensed was implemented usingif MASU. The of framework provides a number of could services by Producers. However, the number Consumers is too high, this cost leadfor to automatic network collection and collaborative ofthe theMASU data gathered fromwill thenot device sensors. Such services congestion, which would alsodistribution suppose that framework be able to work properly facilitate the access to the sensors available on the device, enabling data collection and sharing under those conditions. As a result, it would be necessary to find a solution to deal with scalability betweenrelated deviceswith according to number the specifications of sent the Collaborative Sensingin Mechanism problems the high of messages through the network MANET. (CoSM) of the framework. 5. MASU Empirical Evaluation 5.1.In Role Selection and Activation Methods order to evaluate empirically the proposed framework, a fully distributed mobile application was implemented using MASU. The framework a number of services fordone automatic collection The implementation of the Role Selectionprovides and Activation processes was according to the and collaborative distribution of the data gathered from the device sensors. Such services facilitate the following procedure: access to the sensors available on the device, enabling data collection and sharing between devices The Manager is fixed for the duration of the collaborative sensing activity and it is responsible according to the specifications of the Collaborative Sensing Mechanism (CoSM) of the framework. of selecting and activating roles in the Sensing Tier (i.e., Consumer, Producer and Storage), sending messages to otherMethods units accordingly. 5.1. Role Selection and Activation When a new node accesses the network, it announces its state, capabilities and the sensing The implementation of the Role Selection and Activation processes was done according to the services that can provide. As a result, the Manager knows which sensors are available in the following procedure: network and therefore which units are suitable candidates to play Producer roles. In case that various units the requirements to play sensing a particular Producer the Manager ‚ The Manager is fixed for themeet duration of the collaborative activity and it role, is responsible of takes the decision considering the quality of the sensor and the battery level of the device. Thus, selecting and activating roles in the Sensing Tier (i.e., Consumer, Producer and Storage), sending the unitsto that have sensors with the highest quality and the highest battery level, will be selected messages other units accordingly. as Producers. ‚ When a new node accesses the network, it announces its state, capabilities and the sensing services that After specific As Producer is selected and activated, the Manager automatically activates canaprovide. a result,role the Manager knows which sensors are available in the network and Consumers of the information sensed by that Producer in all the units connected to the network. therefore which units are suitable candidates to play Producer roles. Consumers can receive information from Producers (i) periodically or (ii) only when the ‚ In case that various units meet the requirements to play a particular Producer role, the Manager information changes, receiving a notification as well as the new data when it is available. takes the decision considering the quality of the sensor and the battery level of the device. Thus, Every time a new node joins the network, the Manager starts the Role Selection and Activation the units that have sensors with the highest quality and the highest battery level, will be selected process in the Sensing Tier, activating a Consumer role in the new node. as Producers. The Manager selects and activates a unit to act as Storage of the data collected by a specific ‚ After a specific Producer role is selected and activated, the Manager automatically activates Producer. This unit stores all the information sent by such a Producer in a SQLite database. Consumers of the information sensed by that Producer in all the units connected to the network. Consumers receive data from the Storage periodically, according to the data rate specified by ‚ Consumers can receive information from Producers (i) periodically or (ii) only when the the Consumers in the data request. information changes, receiving a notification as well as the new data when it is available.
Sensors 2016, 16, 1062
‚ ‚ ‚
18 of 27
Every time a new node joins the network, the Manager starts the Role Selection and Activation process in the Sensing Tier, activating a Consumer role in the new node. The Manager selects and activates a unit to act as Storage of the data collected by a specific Producer. This unit stores all the information sent by such a Producer in a SQLite database. Consumers receive data from the Storage periodically, according to the data rate specified by the Consumers in the data request.
5.2. Data Gathering Methods Our prototype of the MASU framework implements three different methods for the provision of the data retrieval services (Publish, Find, Subscribe, and Data Dissemination services) included in the CoSM mechanism embedded in the MASU framework. The three methods implemented are: AllJoyn [39], CoAP [40] and GCM [41,42]. Alljoyn and CoAP offer different mechanisms to create a Peer-to-Peer proximity networks, enabling devices to share information directly among them, without depending on any centralized server. By contrast, if the devices are not physically close but they have Internet connectivity, they can share information using the GCM service, which is connected to the CoSM Server. Next we describe the implemented prototypes. 5.3. Prototypes Implementation Two different prototypes were developed in order to evaluate the performance of the framework using various implementation types, network infrastructures and data retrieval mechanisms. Table 5 summarizes the main features of both prototypes. The Prototype I was implemented using the Unity development platform [43], whereas the Prototype II was implemented as a native Android application. Provided that Unity is a cross-layer platform, the Prototype II was deployed for both Android and Windows OS. Table 5. Implementation details of the two prototypes. Implementation Aspect
Prototype I
Prototype II
Implementation Type Network infrastructure Mechanism for the P2P network creation Location of the Manager role Data gathering method Data message type
Embedded into Unity AP AllJoyn In the first node that joins Alljoyn TCP
Native Android application T2T AllJoyn In the node that acts as AP CoAP UDP unicast
Concerning the network infrastructures, the two prototypes provide distinct methods to create peer-to-peer proximity networks among MASU units. The Prototype I allows a group of units to connect to an existing AP, while the other configures automatically the first unit that joins the activity as AP to provide wireless access for the whole group of units. As a result, AP-based (AP) and Terminal-to-Terminal (T2T) networks are established, respectively. In both prototypes, the first unit that joins the network uses AllJoyn to create the peer-to-peer proximity network. Such a unit will also act as Manager for the overall duration of the collaborative sensing activity. Therefore, we have a Fixed Centralized role architecture of the Control Tier without any mechanism for the dynamic selection and activation of roles in such a tier. For this reason, these prototype implementations were useful only to evaluate the Sensing Tier of the MASU framework. 5.4. Evaluation Results The performance of the Sensing Tier, for both prototypes, was evaluated in terms of resource consumption and considering heterogeneous devices. In contrast to the simulation tests, the prototype evaluation considered devices with diverse capabilities. In order to do that, we deployed the prototype in different Android devices. We used smartphones and tablets with different OS versions and
Sensors 2016, 16, 1062
19 of 27
various kinds of CPU, battery and sensor chips. The features of the different types of devices used are detailed in Table 6. This device heterogeneity allows us to gain some insights about the changes in the performance of the framework across devices. Table 6. Devices used in the evaluation of the prototype. Sensors 2016, 16, 1062 A1, A2, A3 Device Type Model
Smartphone HTC Desire Table
B
C
D
E
Smartphone
Smartphone
Tablet
Tablet
HTCused One in the evaluation Samsung Note Google Nexus 7 6. Devices of II the prototype.
Android Version
A1,2.3.3 A2, A3
4.4.3 B
Device Type Chipset Model
Smartphone Qualcomm QSD 8250 Snapdragon HTC DesireS1
Smartphone Qualcomm APQ 8064T Snapdragon 600 HTC One
Android CPU Version
1 GHz2.3.3 Scorpion
Quad-core 1.7 GHz 4.4.3 Krait 300
Chipset
Qualcomm QSD 8250
Qualcomm APQ 8064T
4.4.2C
Smartphone Samsung Exynos 4412 Quad Samsung Note II Quad-core 1.6 GHz 4.4.2 Cortex-A9
4.4.4 D
19 of 27
Google Nexus 7 5.0.2 E
Tablet Tablet Nvidia Tegra 3 Nvidia Tegra 3 Google Nexus 7 Google Nexus 7 Quad-core 1.2 GHz Quad-core 1.2 GHz 4.4.4 5.0.2 Cortex-A9 Cortex-A9
Samsung Exynos
Nvidia Tegra 3
Nvidia Tegra 3
4412 Quad Snapdragon S1 Snapdragon 600where some The evaluation considered number of tests of devices sensed the environment and 1 GHz and othersQuad-core 1.7 GHz the Quad-core 1.6 GHz Quad-core 1.2 GHz ofQuad-core 1.2 shared the obtained data, only received sensed information. The duration all the tests CPU Scorpion Krait 300 Cortex-A9 Cortex-A9 GHz Cortex-A9 was 20 min, and in every test the battery of all the devices had the same charge level (100%). The tests performed consider an outdoor space, where the devices are moving arbitrarily at walking speed. theevaluation evaluationofofthe the Prototype I, the devices remained within coverage a fixed InInthe Prototype I, the devices remained within the the coverage zonezone of a of fixed AP. AP. By contrast, in the evaluation of the Prototype II, the devices are never outside the coverage zone By contrast, in the evaluation of the Prototype II, the devices are never outside the coverage zone of the of the that device actsorastheir AP mutual or theircoverage mutual coverage As both a result, both types tests do not device actsthat as AP zone. As zone. a result, types of tests doofnot consider considernetwork dynamictopologies network topologies diversepatterns. mobility patterns. dynamic or diverse or mobility
5.4.1.Benefits BenefitsofofCollaborative CollaborativeSensing Sensing 5.4.1. Next,we wepresent presentvarious varioustests testsdone doneusing usingthe thePrototype PrototypeI Itotoassess assessthe theusefulness usefulnessofofsharing sharingdata data Next, among MASU units, instead of working autonomously. Although this assessment only considers the among MASU units, instead of working autonomously. Although this assessment only considers the advantagesofofcollaborative collaborativesensing sensingininterms termsofofthe thebattery batteryconsumption, consumption,other otheraspects aspectsmust mustalso alsototo advantages betaken takeninto intoaccount, account,such suchasasbetter betterinformation informationquality qualityand andsocial socialwelfare welfare(the (thebenefit benefitofofthe theentire entire be community of users). community of users). First,we weevaluated evaluatedthe thebattery batteryconsumption consumptionproduced producedby byaasensing sensingactivity activityin indifferent differentdevices. devices. First, Figure14 14shows showsthe theresults resultsobtained obtainedwhen whenthe thedevices devicesare arenot notperforming performingany anysensing sensingororsharing sharing Figure activities, and also when they are sensing GPS data. This graph indicates that there is a significant activities, and also when they are sensing GPS data. This graph indicates that there is a significant cost in battery lifetime, duesensing to the operations. sensing operations. this cost differs across devices, incost battery lifetime, due to the Moreover,Moreover, this cost differs across devices, having the having the device A the highest cost. This difference in battery consumption can be caused by device A the highest cost. This difference in battery consumption can be caused by differences in the differences in the versions of theoroperating system or the GPS sensing chips. versions of the operating system the GPS sensing chips.
Figure Figure14. 14.Sensing Sensingcosts costsfor fordifferent differentdevices. devices.
Then,wewe evaluated the involved costs involved in a collaborative sensing activity considering Then, evaluated the costs in a collaborative sensing activity considering heterogeneous heterogeneous devices. Therefore, the total battery when sensing data devices. Therefore, we compared the we totalcompared battery consumption whenconsumption sensing data and transmitting it and transmitting it using the two local data retrieval mechanisms: AllJoyn and CoAP. We conducted two different sets of experiments, where four different devices share GPS data, using AllJoyn and CoAP, respectively. Figure 15 depicts the results when the device A1 is sensing and transmitting GPS data (Producer role) and devices A2, B and C are receiving it (Consumers). As expected, the energy consumption is higher in the transmitting device than in the receiving ones for both, AllJoyn and CoAP protocols. In addition, the energy consumption is higher when using AllJoyn than when using
Sensors 2016, 16, 1062
20 of 27
using the two local data retrieval mechanisms: AllJoyn and CoAP. We conducted two different sets of experiments, where four different devices share GPS data, using AllJoyn and CoAP, respectively. Figure 15 depicts the results when the device A1 is sensing and transmitting GPS data (Producer role) and devices A2, B and C are receiving it (Consumers). As expected, the energy consumption is higher in the transmitting device than in the receiving ones for both, AllJoyn and CoAP protocols. In addition, the energy consumption is higher when using AllJoyn than when using CoAP for both, transmitting and receiving devices. Nevertheless, for some receiving devices, the energy drain is very similar for both protocols. Notice that the battery consumption differs according to the device type, even when they have same role (Consumers) and protocol active. This shows the effect of the devices heterogeneity Sensors 2016, 16, on 1062the collaborative sensing activity. 20 of 27
Figure15. 15.Comparison Comparison of the overall collaborative sensing costs of AllJoyn andfor CoAP for different Figure of the overall collaborative sensing costs of AllJoyn and CoAP different devices. devices.
These results can be anticipated since the CoAP protocol is very simple and it is therefore, expected These results can be anticipated since the CoAP protocol is very simple and it is therefore, to consume less energy than a more complex protocol (like AllJoyn) that includes network and service expected to consume less energy than a more complex protocol (like AllJoyn) that includes network discovery functionalities. We then conducted a number of tests in order to verify the benefits of and service discovery functionalities. We then conducted a number of tests in order to verify the collaborative sensing. Unlike the previous tests, here we aim not only to evaluate the overall costs of benefits of collaborative sensing. Unlike the previous tests, here we aim not only to evaluate the collaborative sensing, but also to isolate the costs related to the data retrieval mechanisms used by the overall costs of collaborative sensing, but also to isolate the costs related to the data retrieval MASU framework. Thus, we intend to differentiate between the sensing costs (which are required mechanisms used by the MASU framework. Thus, we intend to differentiate between the sensing even when the units work in a stand-alone fashion) and the costs caused by the collaborative activity costs (which are required even when the units work in a stand-alone fashion) and the costs caused itself. For these tests, we considered the worst case scenario, that is, when sharing data using the most by the collaborative activity itself. For these tests, we considered the worst case scenario, that is, when energy-intensive protocol. Consequently, the application executing the MASU framework had only sharing data using the most energy-intensive protocol. Consequently, the application executing the the AllJoyn protocol activated. MASU framework had only the AllJoyn protocol activated. Figure 16 shows a comparison of the maximum, minimum and average energy consumption Figure 16 shows a comparison of the maximum, minimum and average energy consumption when: (i) they only have the prototype application (CoSP) running and (ii) the devices are only when: (i) they only have the prototype application (CoSP) running and (ii) the devices are only sensing GPS; (iii) they have the application running and the AllJoyn service active, but they are not sensing GPS; (iii) they have the application running and the AllJoyn service active, but they are not sharing any data. Thus, we intend to evaluate the cost of maintaining an AllJoyn session (16 mWh in sharing any data. Thus, we intend to evaluate the cost of maintaining an AllJoyn session (16 mWh in average), in comparison with the cost of sensing. These results also show that the cost of sensing GPS average), in comparison with the cost of sensing. These results also show that the cost of sensing GPS is considerably higher than the cost of using AllJoyn. is considerably higher than the cost of using AllJoyn. The second set of bars in Figure 16 shows the average cost of sensing and transmitting GPS data (corresponding to a Producer role) using AllJoyn, versus the cost of receiving it (Consumer). From the figure it is clear that the cost of sensing and transmitting is slightly higher than the cost of sensing GPS, whereas the cost of receiving information is smaller (15.06 mWh in average). This result indicates that there is an obvious benefit for the receiving device (GPS Consumer), while the cost in the transmitting device (GPS Producer) is relatively low, which clearly points to the advantages of collaborative sensing in terms of social welfare because there is some benefit for the overall group of users (3.41 mWh in average). It seems reasonable to think that, if number of devices increases, these benefits could increase too. Thus, we could compensate the communication cost introduced by maintaining the AllJoyn session. Nevertheless, further tests are needed to confirm this claim.
Figure 16. Evaluation of the cost of AllJoyn in a collaborative sensing activity.
The second set of bars in Figure 16 shows the average cost of sensing and transmitting GPS data (corresponding to a Producer role) using AllJoyn, versus the cost of receiving it (Consumer). From
Figure 16 shows a comparison of the maximum, minimum and average energy consumption when: (i) they only have the prototype application (CoSP) running and (ii) the devices are only sensing GPS; (iii) they have the application running and the AllJoyn service active, but they are not sharing any data. Thus, we intend to evaluate the cost of maintaining an AllJoyn session (16 mWh in average), in1062 comparison with the cost of sensing. These results also show that the cost of sensing GPS Sensors 2016, 16, 21 of 27 is considerably higher than the cost of using AllJoyn.
Figure 16. Evaluation of the cost of AllJoyn in a collaborative sensing activity.
Sensors 2016, 16, 1062 Figure 16. Evaluation of the cost of AllJoyn in a collaborative sensing activity.
21 of 27
The second set of bars in Figure 16 shows the average cost of sensing and transmitting GPS data 5.4.2.Battery BatteryConsumption Consumptionof of Producersand andConsumers Consumers 5.4.2. (corresponding to a ProducerProducers role) using AllJoyn, versus the cost of receiving it (Consumer). From Some additional tests were performed to evaluate theis energy costs ofProducer Producer and Consumer theSome figureadditional it is clear that the cost of sensing and transmitting slightly higher than the cost ofConsumer sensing tests were performed to evaluate the energy costs of and roles. We compared the performance of Producers and Consumers in case of high and low intensity GPS, whereas the cost of receiving information is smaller (15.06 mWh in average). This result roles. We compared the performance of Producers and Consumers in case of high and low intensity indicates that there is when anwhen obvious benefit for the receiving device (GPS Consumer), while thefrom cost in data sharing processes, sharing using AllJoyn. That is, the of sensing those data sharing processes, sharing datadata using AllJoyn. That is, the cost ofcost sensing from those sensors the transmitting device (GPS Producer) is relatively low, which clearly points to the advantages of sensors that generate low and high amounts of data, including the costs of sharing such data at low that generate low and high amounts of data, including the costs of sharing such data at low and high collaborative sensing in terms of social welfare because there is some benefit for the overall group of and high data rate, respectively. data rate, respectively. users (3.41 mWh in average). It seemswas reasonable to think that, if number of continuously devices increases, these The high intensity dataprocess process established sensing GPS data and sharing The high intensity data was established byby sensing GPS data continuously and sharing it benefits could increase too. Thus, we could compensate the communication cost introduced by it every time geolocation value changed. This implied that the GPS data was sent continuously every time geolocation value changed. This implied that the GPS data was sent continuously duedue to the AllJoyn session. Nevertheless, further tests are neededwere to confirm this claim. tomaintaining the high precision of the GPS sensor and also because the devices constantly moving.On Onthe the the high precision of the GPS sensor and also because the devices were constantly moving. other hand, the low intensity data sharing process was established by sending an audio file captured other hand, the low intensity data sharing process was established by sending an audio file captured fromthe thesmartphone smartphonemicrophone. microphone. from Figure17 17shows showsthe theresults resultsobtained. obtained.InIn the case high intensity data sharing process, Figure the case ofof high intensity data sharing process, thethe costcost of of sensing is slightly smaller than the cost of sensing and transmitting the data, but higher than the sensing is slightly smaller than the cost of sensing and transmitting the data, but higher than the cost cost of receiving it. Therefore, in case of high data-intensive Producers we can confirm usefulness of receiving it. Therefore, in case of high data-intensive Producers we can confirm the the usefulness of of sharing the sensed data using AllJoyn, even when the data is shared solely with one Consumer. sharing the sensed data using AllJoyn, even when the data is shared solely with one Consumer.
Figure17. 17.Comparison Comparison of the energy ofdata-intensive high data-intensive low data-intensive sharing Figure of the energy costscosts of high and low and data-intensive sharing processes. processes.
Contrarily, the cost of using AllJoyn for sharing small amounts of data, at a low transmission Contrarily, the cost of using AllJoyn for sharing small amounts of data, at a low transmission rate, is very high and considerably higher than the cost of sensing. For this reason, in case of low rate, is very high and considerably higher than the cost of sensing. For this reason, in case of low data-intensive Producers it would make much more sense to collect the information directly in the data-intensive Producers it would make much more sense to collect the information directly in the devices that are going to consume it. However, it seems reasonable to think that if the number of devices that are going to consume it. However, it seems reasonable to think that if the number of devices is high enough, this energy cost could be compensated. devices is high enough, this energy cost could be compensated. 5.4.3. Resource Consumption for an Increasing Number of Nodes 5.4.3. Resource Consumption for an Increasing Number of Nodes The evaluation of the Prototype I, provided various insights about the benefits of collaborative The evaluation of the Prototype I, provided various insights about the benefits of collaborative sensing and the involved costs. This evaluation represented a worst case scenario due to the poor sensing and the involved costs. This evaluation represented a worst case scenario due to the poor efficiency of the software implementation embedded in the Unity platform, as well as due to the higher costs of AllJoyn as data retrieval method. Therefore, we conducted various tests using the prototype II, which provides a more realistic experimentation scenario with a more efficient implementation. In this case, CoAP was used as data retrieval method having only one Producer and
Sensors 2016, 16, 1062
22 of 27
efficiency of the software implementation embedded in the Unity platform, as well as due to the higher costs of AllJoyn as data retrieval method. Therefore, we conducted various tests using the prototype II, which provides a more realistic experimentation scenario with a more efficient implementation. In this case, CoAP was used as data retrieval method having only one Producer and a number of Consumers active. In this scenario, the Producer senses GPS data, creates a CoAP service and sends the GPS coordinates to the Consumers subscribed to the service. Figure 18 shows the results of these tests when the Producer sends GPS sensed data to the Consumers every time that its location changes. The figure illustrates the CPU and energy consumption of both Consumers and Producers when the number of Consumers of GPS data increases. It shows that the CPU utilization of the Producer increases with the number of Consumers. This increment is mainly caused by the high number of CoAP messages that the Producer has to send due to the high change rate of the GPS data. Particularly, for each 20-min test, the Producer had to send around Sensors 2016,messages 16, 1062 22 of 27 900 CoAP to each Consumer.
(a)
(b)
Figure 18. Producers and Consumers resource utilization when sharing GPS data continuously. Figure 18. Producers and Consumers resource utilization when sharing GPS data continuously. (a) CPU utilization; (b) Battery Consumption. (a) CPU utilization; (b) Battery Consumption.
We can also observe in this figure that the energy cost of the Producer (GPS sensing and We can also observe in this figure that the energy cost of thewhereas Producer sensing transmitting) is slightly higher than the energy cost of sensing GPS, the(GPS energy cost ofand the transmitting) is slightly higher than the energy cost of sensing GPS, whereas the energy cost of Consumer (receiving information) is significantly smaller. This indicates that there is a clear benefit the Consumer (receiving information) is significantly smaller. This indicates that there is a clear benefit for the Consumers, while the cost for the Producer is relatively low. Nevertheless, there is a slight for the Consumers, while the cost for increasing the Producer relatively Nevertheless, there a slight battery consumption increase when theisnumber of low. Consumers. This was anisexpected battery consumption increaseofwhen increasing number of Consumers. This an expected result result because the amount energy should the increase when more devices arewas added to the system, because the amount of energy should increase when more devices are added to the system, due due to more the energy consumption required for the Wi-Fi subsystem maintenance. Despite this,toif more the energy consumption for the subsystem maintenance. Despite this, if we consider the overall batteryrequired consumption ofWi-Fi the system, we have an important reduction in we the consider the overall battery theone system, we have important reduction in we the use energy energy consumption (295 consumption mWh in totaloffor Producer andan four Consumers) when the consumption mWhthe in sensed total fordata, one instead Producer four data Consumers) when weOnce use the prototype for prototype for(295 sharing ofand sensing independently. again, this shows sharing the sensed instead of sensingIndata Once again, showsin the advantages the advantages of data, collaborative sensing. thisindependently. case, we achieved a 43% of this reduction battery drain, of collaborative sensing. In this case, we achieved a 43% of reduction in battery drain, considering considering the overall group of devices involved. Therefore, both Consumer and Producer the overall group of devices involved. Therefore, Consumer andProducer Producerisapplications are applications are energy-efficient and most of the both energy cost of the caused by GPS energy-efficient and most of the energy cost of the Producer is caused by GPS sensing. sensing. We also evaluated We also evaluatedthe theCPU CPUutilization utilizationwhen whenthe theConsumers Consumerscall callthe theCoAP CoAPservice serviceof ofthe theGPS GPS Producer periodically, every 60 s (Figure 19). In this case, the Producer does not send GPS data Producer periodically, every 60 s (Figure 19). In this case, the Producer does not send GPS data continuously. It only only sends sends every every 60 60ssthe thelast lastGPS GPSvalue valuemeasured. measured.This This means that, although continuously. It means that, although the the GPS sensor still active, the Producer only does a GPS reading every 60 s. Thus, the number of GPS sensor still active, the Producer only does a GPS reading every 60 s. Thus, the number of CoAP CoAP messages sent the Producer decreases significantly (around 20 messages for each Consumer). messages sent by thebyProducer decreases significantly (around 20 messages for each Consumer). As As a result, the CPU utilization of the Producer is significantly smaller than when it was sending a result, the CPU utilization of the Producer is significantly smaller than when it was sendingdata data continuously continuously(Figure (Figure18), 18),and andititincreases increasesvery veryslowly slowlywith withthe thenumber numberofofConsumers. Consumers.
Producer periodically, every 60 s (Figure 19). In this case, the Producer does not send GPS data continuously. It only sends every 60 s the last GPS value measured. This means that, although the GPS sensor still active, the Producer only does a GPS reading every 60 s. Thus, the number of CoAP messages sent by the Producer decreases significantly (around 20 messages for each Consumer). As a result, the CPU utilization of the Producer is significantly smaller than when it was sending data Sensors 2016, 16, 1062 23 of 27 continuously (Figure 18), and it increases very slowly with the number of Consumers.
Figure 19. Producers and Consumers CPU utilization when sharing GPS data periodically (low data Figure 19. Producers and Consumers CPU utilization when sharing GPS data periodically (low data transmission rate). transmission rate).
5.4.4. Resource Consumption of Storages and Relays 5.4.4. Resource Consumption of Storages and Relays In order to assess the CPU consumption of the Storage and Relay roles, we performed a test In order to assess the CPU consumption of the Storage and Relay roles, we performed a test where two Consumers subscribe to the GPS sensing services of a Producer and a Storage, where two Consumers subscribe to the GPS sensing services of a Producer and a Storage, respectively. respectively. This test is useful to evaluate the computational cost of both Storages and Relays since This test is useful to evaluate the computational cost of both Storages and Relays since such a cost is such a cost is only related with the rate at which Storages or Relays send data to Consumers. Sensors 2016, 16, 1062the rate at which Storages or Relays send data to Consumers. Therefore, it is23not of 27 only related with Therefore, it is not necessary to perform two separate tests to evaluate both types of roles. necessary to perform two separate tests to evaluate both types of roles. thistest testthe theStorage Storagerole rolewas wasassigned assignedtotothe thelast lastnode nodeentering enteringthe thenetwork. network.This ThisStorage Storage InInthis receives the GPS data sensed by the Producer every 60 s and sends such data to the Consumer receives the GPS data sensed by the Producer every 60 s and sends such data to the Consumer subscribedtotoititatatthe thesame samerate. rate. Results Results in in Figure Figure 20 20 show show how subscribed how the the CPU CPU utilization utilization in inthe theStorage Storageis slightly higher than the in the Consumer but significantly lower than in the Producer. In addition, is slightly higher than the in the Consumer but significantly lower than in the Producer. In addition, theCPU CPUutilization utilization of of both both Producers having one Producer andand two the Producers and and Consumers Consumersininthe thecase caseofof having one Producer Consumers only increases slightly when we add one Storage. In this case, we have three units two Consumers only increases slightly when we add one Storage. In this case, we have three units receivingthe theinformation informationgenerated generatedby by the the Producer Producer (i.e., (i.e., two two Consumers Consumers and receiving and one one Relay) Relay) but but at at a a lower lower cost cost for for the theProducer, Producer, reducing reducing its its CPU CPUutilization utilizationaa23. 23.These Theseresults resultsindicate indicatethe theusefulness usefulnessof including Storages or Relays when we have two Consumers and one of them cannot receivethe the of including Storages or Relays when we have two Consumers and one of them cannot receive information from the Producer properly. information from the Producer properly.
Figure20. 20.CPU CPUutilization utilizationofofProducers, Producers,Consumers Consumersand andStorages Storageswhen whensharing sharingGPS GPSdata dataperiodically periodically Figure with two Consumers. with two Consumers.
6. Comparing MASU with the Existing Frameworks 6. Comparing MASU with the Existing Frameworks Although the literature reports a large number of pervasive data sensing applications and Although the literature reports a large number of pervasive data sensing applications and platforms that are suitable in particular application domains, there is a lack of transversal support for platforms that are suitable in particular application domains, there is a lack of transversal support for fully distributed and heterogeneous solutions that allow to implement pervasive sensing in variety fully distributed and heterogeneous solutions that allow to implement pervasive sensing in variety of of scenarios. Table 7 shows the similarities and differences between MASU and other sensing scenarios. Table 7 shows the similarities and differences between MASU and other sensing frameworks. frameworks. Table 7. Comparison between MASU and other frameworks. Framework/Platform
Purpose or Use - General purpose platform.
METIS [22]
- It supports opportunistically offloading sensing by involving stationary sensors embedded in the environment.
Similarities with MASU - It supports continuous sensing and autonomy of the nodes. - Flexible (by gain threshold).
Differences with MASU - It requires instrumenting the sensing area. - The only criterion used to determine the sensing strategy is
Sensors 2016, 16, 1062
24 of 27
Table 7. Comparison between MASU and other frameworks. Framework/Platform
Purpose or Use -
METIS [22]
Darwin [6]
CoMon [8] -
General purpose platform. It supports opportunistically offloading sensing by involving stationary sensors embedded in the environment. Focused on saving energy. Collaborative reasoning framework. Uses machine-learning techniques specifically designed to run on sensor-enabled mobile phones. General purpose platform. It supports cooperative ambient monitoring through opportunistic cooperation among nearby mobile users. Focused on saving energy.
Similarities with MASU -
-
-
It supports device heterogeneity.
-
It supports continuous and distributed sensing. It supports nodes mobility, autonomy and sensing fault tolerance.
-
-
GCF [17]
-
General purpose platform. It supports opportunistic sharing of contextual information.
It supports continuous sensing and autonomy of the nodes. Flexible (by gain threshold).
-
It allows performing collaborative sensing involving distributed autonomous nodes. It uses various criteria for selecting the data sensing strategy.
Differences with MASU -
-
It does not support collaborative sensing, distributed/ad hoc solutions and autonomous nodes.
-
It does not support device heterogeneity and one-to-one interactions. The only criterion used to determine the sensing strategy is energy saving.
-
-
-
Remora [19]
-
C-SPINE [20]
-
EasiSee [24]
AnonySense [44]
-
It implements a body sensor network. It shares sensing information and classifiers for saving energy. It implements a body sensor network. It supports collaborative reasoning, computing and data fusion. It implements collaborative sensing; particularly for vehicle counting and classification. General-purpose platform. It opportunistically shares anonymized contextual information.
-
It allows collaborative sensing involving distributed autonomous nodes.
-
-
It supports distributed and ad hoc sensing. It supports groups of sensing devices.
-
-
-
It performs collaborative sensing.
It supports collaborative sensing.
It requires instrumenting the sensing area. The only criterion used to determine the sensing strategy is energy saving.
-
-
Focused on grouping devices. It does not provide device-to-device communication or support for device heterogeneity. It does not support long-range communication infrastructures. It does not support device heterogeneity and one-to-one or group interactions. The only criterion used to determine the sensing strategy is energy saving. It does not support long-range communication infrastructures. It implements collaborative sensing. It does not support long-range communication infrastructures. It supports only one-to-one interactions between stationary nodes. It uses centralized components. It supports ad hoc sensing, but using a centralized by registry.
As shown in Table 7, these frameworks use some centralize component, do not support devices heterogeneity or a hybrid communication space (short and large range communication infrastructures). This is not surprising since they were proposed to support sensing in scenarios where no pervasiveness is required. In this sense, the MASU platform represents a step forward in that direction. 7. Conclusions and Future Work Although the literature reports a large number of pervasive data sensing applications and platforms that are suitable in particular niches, there is a lack of transversal support for fully distributed data sensing, particularly when the sensed data need to be shared ad hoc and on demand fashion. This type of sensing can be used in various applications scenarios, like urban search-and-rescue processes, mobile learning activities and hospital work. Trying to contribute to address such a need, this paper proposes a framework, named Mobile Autonomous Sensing Unit (MASU), which provides a set of services that allows mobile devices to
Sensors 2016, 16, 1062
25 of 27
perform distributed pervasive data sensing, both in an autonomous and collaborative way. The design of the framework includes the definition of different roles that can be played by a group of devices that are performing collaborative sensing activities. Developers of this type of applications can take advantage of this framework, by reusing these services and reducing thus the risks and effort involved in the development process. The framework was evaluated using both simulations and empirical tests involving a software prototype. Both types of evaluations provided various insights on the performance of the framework under diverse hardware, networking and mobility conditions. The simulation results demonstrated that the social nature of human interaction can benefit the performance of the framework, since people’s mobility patterns contribute to have high availability of the information sensed by the mobile devices. In addition, the simulations helped us determine the costs of the collaborative sensing, in terms of network utilization. We also showed how Mobile Ad hoc Networks (MANETs) provide an interesting communication support that provides higher network connectivity due to their multi-hop features. Consequently, we demonstrated that MANETs can also contribute to the accessibility of the information sensed. Nevertheless, the simulations also revealed that MANETs have a slightly higher cost (in terms of number of control messages), but a considerably higher cost in terms of data messages due to the unicast nature of the communication, as well as due to the higher node connectivity. These facts could derive in scalability problems of the framework when using MANETs as communication support. Using the prototype, we evaluated the Sensing Tier of the framework. We showed the benefits of using the framework to perform collaborative sensing in terms of energy savings and social welfare in comparison to pure phone sensing, achieving a 43% energy savings for the overall system (Section 5.4.3). We also evaluated the costs associated with the use of the framework for collaborative sensing in terms of hardware resources of the participating devices. This evaluation considered some device heterogeneity since we used smartphone and tablets with diverse hardware specifications. Results from both types of evaluation methods provided empirical evidence on the usefulness of the proposed framework. These results provided valuable insights about the benefits of the proposed framework to support pervasive sensing in terms of resource optimization as well as about its limitations and associated costs. The obtained results in both evaluation experiences show that the services provided by the framework are suitable for supporting distributed pervasive data sensing, and also contributes to keep low the energy consumption of the mobile devices involved in the process. As a next step, we consider to develop a variety of these applications to assess more in-depth the impact of the MASU framework. Acknowledgments: This work has also been partially supported by Fondecyt (Chile), grant 1150252; by the Spanish Ministry of Science and Innovation (MCI) and FEDER funds of the EU under the contract TIN2013-47245-C2-1-R, by the European Community through the project Community Networks Testbed for the Future Internet (CONFINE): FP7-288535, and also by the Generalitat de Catalunya as a Consolidated Research Group 2014-SGR-881. Author Contributions: The development and evaluation of the MASU framework were led by Esunly Medina, David Lopez and Roc Meseguer. Sergio F. Ochoa, Dolors Royo and Rodrigo Santos evaluated the framework design and proposed improvements already implemented in the platform. Moreover, these last three authors supported the design of the MASU evaluation process, and the analysis and reporting of the results. Conflicts of Interest: The authors declare no conflict of interest. The founding sponsors had no role in the design and implementation of the proposed framework, in its evaluation, in the collection, analyses, or interpretation of the evaluation results; in the writing of the manuscript, and in the decision to publish the results.
References 1.
Balan, R.K.; Lee, Y.; Wee, T.K.; Misra, A. The challenge of continuous mobile context sensing. In Proceedings of the 6th International Conference on Communication Systems and Networks (COMSNETS), Bangalore, India, 6–10 January 2014; pp. 1–8.
Sensors 2016, 16, 1062
2. 3. 4.
5. 6. 7.
8.
9. 10.
11.
12. 13. 14. 15.
16. 17.
18. 19.
20. 21. 22. 23.
26 of 27
Rachuri, K.K. Smartphones Based Social Sensing: Adaptive Sampling, Sensing and Computation Offloading. Ph.D. Thesis, University of Cambridge, Cambridge, UK, 2012. Ding, A.Y. Collaborative Communication and Sensing for Mobile Systems. In Proceedings of the Doctoral Colloquium of Embedded Network Sensor Systems (SenSys), Rome, Italy, 11–14 November 2013. Lu, X.; Li, D.; Xu, B.; Chen, W.; Ding, Z. Minimum cost collaborative sensing network with mobile phones. In Proceedings of the 2013 IEEE International Conference on Communications (ICC), Budapest, Hungary, 9–13 June 2013; pp. 1816–1820. Lu, X.; Zhu, Y.; Li, D.; Xu, B.; Chen, W.; Ding, Z. Minimum payment collaborative sensing network using mobile phones. Wirel. Netw. 2014, 20, 1859–1872. [CrossRef] Miluzzo, E. Smartphone Sensing. Ph.D. Thesis, Dartmounth College Hanover, Hanover, NH, USA, 2011. Chon, Y.; Lane, N.D.; Li, F.; Cha, H.; Zhao, F. Automatically Characterizing Places with Opportunistic Crowdsensing Using Smartphones. In Proceedings of the 14th Conference on Ubiquitous Computing (UbiComp), Pittsburgh, PA, USA, 5–8 September 2012; pp. 481–490. Lee, Y.; Ju, Y.; Min, C.; Kang, S.; Hwang, I.; Song, J. CoMon: Cooperative Ambience Monitoring Platform with Continuity and Benefit Awareness. In Proceedings of the 10th International Conference on Mobile Systems, Applications, and Services (MobiSys), Ambleside, UK, 25–29 June 2012; pp. 43–56. Pournajaf, L.; Xiong, L.; Sunderam, V. Dynamic Data Driven Crowd Sensing Task Assignment. Procedia Comput. Sci. 2014, 29, 1314–1323. Guo, B.; Yu, Z.; Zhou, X.; Zhang, D. From participatory sensing to mobile crowd sensing. In Proceedings of the IEEE International Conference on Workshops of Pervasive Computing and Communications (PERCOM), Budapest, Hungary, 24–28 March 2014; pp. 593–598. Burke, J.; Estrin, D.; Hansen, M.; Parker, A.; Ramanathan, N.; Reddy, S.; Srivastava, M.B. Participatory sensing. In Proceedings of the Workshop on World-Sensor-Web (WSW): Mobile Device Centric Sensor Networks and Applications, Boulder, CO, USA, 31 October–3 November 2006. Ochoa, S.F.; Monares, A.; Ochoa, N.; Hervas, R.; Bravo, J. Understanding the Interaction Support for Mobile Work in an Emergency Room. Hum. Comput. Interact. Appl. Ser. 2014, 8512, 312–322. Ganti, R.K.; Ye, F.; Lei, H. Mobile crowdsensing: Current state and future challenges. IEEE Commun. Mag. 2011, 49, 32–39. [CrossRef] Guo, B.; Wang, Z.; Yu, Z.; Wang, Y.; Yen, N.Y.; Huang, R.; Zhou, X. Mobile crowd sensing and computing: The review of an emerging human-powered sensing paradigm. ACM Comput. Surv. 2015, 48, 7. [CrossRef] Tang, K.P.; Keyani, P.; Fogarty, J.; Hong, J.I. Putting people in their place: An anonymous and privacy-sensitive approach to collecting sensed data in location-based applications. In Proceedings of the Human Factors in Computing Systems (CHI), Montreal, QC, Canada, 22–27 April 2006; pp. 93–102. Carreño, P.; Gutierrez, F.R.; Ochoa, S.F.; Fortino, G. Supporting personal security using participatory sensing. Concurr. Comput. Pract. Exp. 2014, 27, 2531–2546. [CrossRef] De Freitas, A.A.; Dey, A.K. The Group Context Framework: An Extensible Toolkit for Opportunistic Grouping and Collaboration. In Proceedings of the 18th ACM Conference on Computer Supported Cooperative Work & Social Computing (CSCW), Vancouver, BC, Canada, 14–18 March 2015; pp. 1602–1611. Thejaswini, M.; Rajalakshmi, P.; Desai, U.B. Duration of stay based weighted scheduling framework for mobile phone sensor data collection in opportunistic crowd sensing. Peer-to-Peer Netw. Appl. 2016, 9, 721–730. Keally, M.; Zhou, G.; Xing, G.; Wu, J. Remora: Sensing Resource Sharing among Smartphone-Based Body Sensor Networks. In Proceedings of the 2013 IEEE/ACM 21st International Symposium on Quality of Service (IWQoS), Montreal, QC, Canada, 3–4 June 2013; pp. 1–10. Fortino, G.; Galzarano, S.; Gravina, R.; Li, W. A Framework for Collaborative Computing and Multi-Sensor Data Fusion in Body Sensor Networks. Inf. Fusion 2015, 22, 50–70. [CrossRef] Hachem, S.; Animesh, P.; Issarny, V. Service-Oriented Middleware for Large-Scale Mobile Participatory Sensing. Pervasive Mob. Comput. 2014, 10, 66–82. [CrossRef] Rachuri, K.; Efstratiou, C.; Leontiadis, I.; Mascolo, C.; Rentfrow, P.J. Smartphone Sensing Offloading for Efficiently Supporting Social Sensing Applications. Pervasive Mob. Comput. 2014, 10, 3–21. [CrossRef] Loomba, R.; Shi, L.; Jennings, B.; Friedman, R.; Kennedy, J.; Butler, J. Information Aggregation for Collaborative Sensing in Mobile Cloud Computing. In Proceedings of the 2nd IEEE International Conference on Mobile Cloud Computing, Services, and Engineering, Oxford, UK, 8–11 April 2014; pp. 149–158.
Sensors 2016, 16, 1062
24. 25. 26. 27. 28. 29. 30. 31.
32. 33. 34. 35.
36.
37.
38. 39. 40. 41. 42.
43. 44.
27 of 27
Wang, R.; Zhang, L.; Xiao, K.; Sun, R.; Cui, L. EasiSee: Real-Time Vehicle Classification and Counting via Low-Cost Collaborative Sensing. IEEE Trans. Intell. Transp. Syst. 2014, 15, 414–424. [CrossRef] Bellavista, P.; Corradi, A.; Fanelli, M.; Foschini, L. A Survey of Context Data Distribution for Mobile Ubiquitous Systems. ACM Comput. Surv. 2012, 44. [CrossRef] Hevner, A.R.; March, S.T.; Park, J.; Ram, S. Design science in information systems research. MIS Q. 2004, 28, 75–105. Travassos, G.; Shull, F.; Carver, J.; Basili, V. Reading Techniques for OO Design Inspections; Technical Report CS-TR-4353 and UMIACS-TR-2002-33; University of Maryland: College Park, MD, USA, 2002. Ververidis, C.N.; Polyzos, G.C. Service discovery for mobile ad hoc networks: A survey of issues and techniques. IEEE Commun. Surv. Tutor. 2008, 10, 30–45. [CrossRef] Ochoa, S.F.; Santos, R. Human-centric wireless sensor networks to improve information availability during urban search and rescue activities. Inf. Fusion 2015, 22, 71–84. [CrossRef] NS-3 Network Simulator. Available online: http://www.nsnam.org/ (accessed on 15 June 2016). Aschenbruck, N.; Ernst, R.; Gerhards-Padilla, E.; Schwamborn, M. BonnMotion: A Mobility Scenario Generation and Analysis Tool. In Proceedings of the Simulation Tools and Techniques (SIMUTools), Torremolinos, Malaga, Spain, 15–19 March 2010. Camp, T.; Boleng, J.; Davies, V. A survey of mobility models for ad hoc network research. Wirel. Commun. Mob. Comput. 2002, 2, 483–502. [CrossRef] Bruno, R.; Conti, M.; Gregori, E. Mesh networks: Commodity multihop ad hoc networks. IEEE Commun. Mag. 2005, 43, 123–131. [CrossRef] Rebecchi, F.; Dias de Amorim, M.; Conan, V.; Passarella, A.; Bruno, R.; Conti, M. Data Offloading Techniques in Cellular Networks: A Survey. IEEE Commun. Surv. Tutor. 2015, 17, 580–603. [CrossRef] Vasudevan, S.; Kurose, J.; Towsley, D. Design and analysis of a leader election algorithm for mobile ad hoc networks. In Proceedings of the 12th IEEE International Conference on Network Protocols (ICNP), Berlin, Germany, 5–8 October 2004; pp. 350–360. Masum, S.M.; Ali, A.A.; Bhuiyan, M.T.I. Asynchronous leader election in mobile ad hoc networks. In Proceedings of the IEEE 20th International Conference on Advanced Information Networking and Applications (AINA), Vienna, Austria, 18–20 April 2006; Volume 2, p. 5. Vollset, E.W.; Ezhilchelvan, P.D. Design and performance study of crash-tolerant protocols for broadcasting and reaching consensus in MANETs. In Proceedings of the 24th IEEE Symposium on Reliable Distributed Systems (SRDS), Orlando, FL, USA, 26–28 October 2005; pp. 166–175. Wu, W.; Cao, J.; Yang, J.; Raynal, M. Design and Performance Evaluation of Efficient Consensus Protocols for Mobile Ad Hoc Networks. IEEE Trans. Comput. 2007, 56, 1055–1070. [CrossRef] The AllJoyn Framework. Available online: https://allseenalliance.org/developers/learn/ (accessed on 15 June 2016). CoAP—Constrained Application Protocol Overview. Available online: http://coap.technology/ (accessed on 18 June 2016). Google Cloud Messaging for Android—Android Developers. Available online: http://developer.android. com/google/gcm/index.html (accessed on 18 June 2016). Yilmaz, Y.S.; Aydin, B.I.; Demirbas, M. Google cloud messaging (GCM): An evaluation. In Proceedings of the Global Communications—Symposium on Selected Areas in Communications (GC14 SAC) Internet of Things, Austin, TX, USA, 8–12 December 2014. Unity. Available online: http://www.unity3d.com (accessed on 15 June 2016). Shin, M.; Cornelius, C.; Peebles, D.; Kapadia, A.; Kotz, D.; Triandopoulos, N. AnonySense: A System for Anonymous Opportunistic Sensing. Pervasive Mob. Comput. 2011, 7, 16–30. [CrossRef] © 2016 by the authors; licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC-BY) license (http://creativecommons.org/licenses/by/4.0/).
