5.1 Introduction

As more people are moving toward urban areas, cities need to be made smarter to optimally address problems like resource limitation, maintenance of healthy neighborhood, and so on. Many of the problems are dynamic in nature, for example, predicting traffic pattern on a day [1], finding empty space in a parking lot, reporting from disaster situations, or detecting the presence of dangerous pollutants [2]. To measure these in a centralized manner, expensive infrastructure is needed to be maintained. Nowadays, smart mobile phones are quite efficient in sensing tasks as well as computing and can also be extended easily to the Internet of Things (IoT), for instance, smartphones, music players, sensor-embedded gaming systems, and in-vehicle sensing devices (GPS, OBD-II) [3]. These devices have many built-in sensors like accelerometer, gyroscope, digital compass, light sensor, Bluetooth as proximity sensor [4], and so on and hence are potentially important sources of sensed data. This trend is even rising as more sensors will be incorporated into the smart devices, for instance, sensors needed for healthcare applications. These devices also come with some computational facilities as well as capability of uploading data to the Internet.

Thus instead of providing complex infrastructure, smart devices from citizens could be utilized for their own benefit. Consequently, mobile crowd-sensing (MCS) is defined in [3] as a category of applications “where individuals with sensing and computing devices collectively share data and extract information to measure and map phenomena of common interest.” Here citizens and/or their mobile devices act both as sensors and actuators [5]. This can be viewed as a variant of mobile sensor networks, which rely on people's smartphones utilizing the sensors integrated in these devices. Smart devices are uncontrolled mobile sensors as mobility is determined by the device owners [6].

MCS if utilized effectively can make the cities smarter. The concept of smart city is based on “ideas of supporting infrastructure through the use of data and the importance of deploying processes that respond to that data” [7]. There are many applications of smart city like smart infrastructure, smart home, smart grid, smart transportation, and so on. However, smart citizen closes the loop by participating in sensing and actuation using their smartphones [8]. MCS may link infrastructure to its operations in smart cities [9]. Commercial organizations may be very much interested in collecting mobile sensing data to learn more about customer behavior. Government bodies may also be interested in collecting sensing data to know about road conditions, air pollution, and so on. Citizens may themselves be interested for various reasons like they can take precautions before entering an area. The idea of MCS can be applied in social, environmental, and infrastructure context [3]. However, before deployment of such applications, the desirable properties of such a system in the context of smart city need to be identified along with its associated challenges.

Consequently in this chapter we plan to focus on the scope of crowd-sensing for smart cities. Crowd-sensing literature is reviewed thoroughly in the following section. The challenges of crowd-sensing in the context of smart city are discussed in Section 5.3 followed by a brief overview of existing frameworks in Section 5.4. Finally Section 5.5 concludes with a hint of open issues in this direction of research.

5.2.1 Categories of Crowd-sensing

Based on the sensing pattern, crowd-sensing applications can in general be classified into two categories: personal sensing and community sensing. In personal sensing, the aim is to capture information mainly related to the smart device's user, for instance, monitoring user activities or individual's carbon footprint. While in community sensing, data is collected from smartphones of many individuals in order to monitor environmental phenomena around a region, for example, traffic congestion level.

Community sensing can further be subdivided into participatory sensing and opportunistic sensing, depending on the mode of user involvement. In participatory sensing users join the task of sensing, whereas in opportunistic sensing, sensing takes place seamlessly without any user intervention [2]. This is summarized in Figure 5.1. Thus community sensing involving the crowd is known as MCS. Crowd-sensing benefits from the pervasive dominance of smart devices including smartphones, tabs, and so on in order to collect large-scale sensor data [3, 14].

5.2.2 Architecture of Mobile Crowd-sensing

Crowd-sensing mostly follows a pull model where a server (deployed by a government agency or a commercial organization) decides to execute a task and assign it to the smart devices of the crowd. The server usually chooses the devices where the sensing task is to be executed. A typical architecture of crowd-sensing is shown in Figure 5.2. The users may agree to the task and start sensing (participatory) or the device may automatically respond (opportunistic) to the request and send the sensed data to the server through the Internet (periodically). Cloud services may be integrated here to store and apply analytics on such huge amount of sensing data from citizens. The information extracted from these data is sent to the task designer, which can be a commercial organization or government agency as shown in Figure 5.2. Thus it can be viewed as a three-tier architecture where in tier 1, the sensing tasks are actually deployed and data is sent to tier 2 that constitutes the server and/or cloud services. This tier is responsible for task assignment, user profiling (deciding about whom to assign the task depending on user credentials), and data analytics to extract necessary information from data. This information is finally sent to the government agency or commercial organization at tier 3. This tier is responsible for designing the task and decision-making. Though for social crowd-sensing applications, tier 1 and 3 devices are the same. Thus tier 2 plays an important role in processing huge data from tier 1 devices and sending output either back to tier 1 or to tier 3, depending on the application. Cloud services could be utilized here for faster task execution.

National Institute of Standards and Technologies (NIST) defines the cloud [15]: Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This new computing model is enabled due to the availability of virtually unlimited storage and processing capabilities. In the cloud, these virtualized resources can be leased in an on-demand fashion or as general utilities. Also it can host services to be delivered over the Internet. A cloud service has three distinct characteristics that differentiate it from traditional hosting.

1. 1. On demand - Services on cloud are available on demand.
2. 2. Elastic - The resources or services provided by cloud varies with varying demand.
3. 3. Low (no) headache: Services and resources are mainly managed by the cloud service provider, and the service consumer (at tier 1 and/or tier 3 in Figure 5.2) only needs a computing device with Internet access.

In the crowd-sensing context, not only a vast number of smartphones may provide data to the cloud but also the sensors of a smartphone can generate large data over time, which is called big data. The real challenge is to analyze these data to build the knowledge base and ultimately the ability to respond to the world with greater intelligence. Hadoop is an open-source cloud computing environment created and maintained by the Apache project for distributed programming on commodity hardware.

The tasks performed by the devices lying in the different tiers are summarized in Figure 5.3. As shown in the figure, there may be a feedback from tier 3 to tier 1 through tier 2 about alert. For instance, in [16], crowd-sensing-based real-time public transport information service is implemented, and its front-end Android application, called TrafficInfo, is discussed in detail. The authors also proposed a publish/subscribe (pub/sub) communication model (using Extensible Messaging and Presence Protocol (XMPP)) for crowd-sensing applications for the smart city context. They considered the smartphone users as both publisher and consumer of data (prosumers). A service provider residing between the producer and consumer intercepts crowd-sensed data, processes it, and publishes meaningful information to the interested consumers.

Alternatively, the smart devices of the crowd may also initiate the task by requesting task execution at the server and sending sensed data. For example, while entering a polluted region, a person may proactively send this information to the server. The server may initiate sensing application and assign it to the smart devices around the region, collect data, process it and publish the level of pollution to the government authority, and may warn the citizens moving toward that region if the presence of any dangerous pollutant is detected. Thus tier 2 devices are responsible for task assignment, data storage, and analytics, whereas tier 3 devices are responsible for designing a task and deciding about its outcome. Analysis of users of tier 1 devices is also done by tier 2 devices such as user profiling and task registration.

5.2.3 Applications of Mobile Crowd-sensing in Smart City

Crowd-sensing applications for smart cities may be classified into three domains: infrastructure, environment, and social [3]. Applications involving measurement of large-scale phenomena related to public infrastructure fall into the first category. In environmental applications, participatory sensing is used to monitor natural environment like pollution levels in a city. In social applications individuals share sensed information among themselves so tier 1 and tier 3 devices (of Figure 5.2) are the same here. The overall classification of the applications is shown in Figure 5.4. Description of each category is presented below.

5.2.3.3 Social Applications

In social crowd-sensing, participants share their produced data with each other through a server (tier 2 device in Figure 5.2). Such a database provides better understanding of community-related problems. For example, microblogs [17], which is a universal platform where users can share the information they have sensed about a region (e.g., tourist spots) and also real-time questions about a certain venue, can be entertained. Such a platform can also be utilized for spreading short-term news or advertisements. However this is more related to crowdsourcing. In DietSense [18], individuals take pictures of what they eat and share it within a community to compare their eating habits. This can be utilized for a community of diabetics to watch other diabetics and control their diet or provide suggestions. This again involves both crowd-sensing as well as crowdsourcing.

Crowd-sensing is used in applications like BikeNet [19] where individuals measure location and bike route quality based on parameters like content on route, bumpiness of ride, and so on. Data collected is analyzed to obtain the “most” bikeable routes.

In [20], opportunistically captured images and audio clips from smartphones are exploited to link place visits with place categories like store and restaurant. The framework presented in the work combines signals based on location and user trajectories (using Wi-Fi/GPS) and maps it with visual and audio place “hints” mined from opportunistic sensor data. For instance, words spoken by people, text written on signs, or objects recognized in the environment can indicate a particular place. In this way, community of users may get feedback about a place.

Comparison of the crowd-sensing applications is summarized in Figure 5.5. Most of these applications are found to be beneficial to the community. GPS seems to be an indispensable sensor for applications in the infrastructure domain due to its accuracy in specifying location. However GPS is very power-hungry sensor, and it does not work indoor though a person spends most of his/her time indoor. Notably most of the applications designed are for the benefit of a community or society.

5.3.1 Task Assignment Problem

Few works have been done on task assignment and displaying results [14] in crowd-sensing though there are many challenges to overcome. While crowdsourcing is aimed to utilize collective intelligence of the crowd to solve complex tasks by breaking them down to smaller tasks, crowd-sensing splits the responsibility of gathering correct information to the crowd. Toward this, a geo-social model of MCS is proposed in [5] that is based on a distributed architecture for task design, assessment, and execution. According to [39], a task can be defined as a representation of a crowdsensing campaign to gather sensing indicators (considered relevant) at the desired quality level and with the desired coverage. In this work, the authors associated different parameters with task like acceptance window, that is, how long the task will be available for users to accept; description of the task; duration, that is, the maximum time allowed to the user to finish task execution; and so on. The task life cycle as described in the work is given in Figure 5.7. Any geo-social task remains inactive and hidden from user unless the device reaches the desired area. The task execution is at user's discretion. So this kind of task assignment works only for participatory sensing. A geo-social task can only get completed at the desired region.

A task can also be paused and still get completed in due time. However pause state need not be synchronized with the server; only the relevant states like running, successful, failed, and ignored states are transparently synchronized with the server via the notion of soft state. Tasks are actually assigned to mobile devices through pub/sub communication model in most crowd-sensing applications.

In [5] a framework McSense is proposed for MCS where three task assignment policies are discussed, namely,

• • Random policy - This policy selects the set of crowd users to employ as a random group of available people in the whole city.
• • Attendance policy - This policy exploits the knowledge of the citizens who have previously visited the area for significant time. It ranks citizens according to duration of previous visits.
• • Recency Policy - This policy prefers users who have recently visited the sensing task area.

For each policy, smart devices whose battery level is below a certain threshold, called battery threshold, at task starting time are not considered for better task reliability. Workers ratio, that is, the percentage of candidate workers that will receive the task assignment, is another parameter considered in the work. For instance, initially for a task, workers ratio may be kept higher, but with user profiling, for a particular assignment policy lesser workers ratio may suffice later on.

In case of opportunistic sensing, the smartphones register with the server in tier 2. Once registration is complete, data streaming starts following push-or-pull model as discussed in [40]. In most crowd-sensing tasks especially for opportunistic sensing, due to high volume of data, cloud services can be utilized as server in tier 2 to store and effectively control tasks [41].

5.3.2 User Profiling and Trustworthiness

User reliability and categorization of users based on trust are important to ensure correctness of collected data. The phenomenon or thing observed by crowd users may be termed as entities like temperature of a place at a time instant. Users provide observations about entities in crowd-sensing applications with the help of sensors and send it to the server, which is a tier 2 device. The observation of users is noisy and often contradicts with one another. The false observations may outnumber true observations in which case voting or averaging would not extract the truth. However, correlation among entities may be exploited to find out the true observation and hence plot reliable users as is done in [42]. Assessing user reliability degrees is very important as we need observation from a number of reliable users. In [42], the task of truth discovery is formulated as an optimization problem. The correlation between entities is exploited here to find out the truth as well as reliable users. For instance, temperature or pollution level of nearby places should not vary abruptly. Accordingly, the entities are partitioned into disjoint independent sets, and block coordinate descent is applied to solve the problem and find out the user reliability as well as the truth. The sequential design of algorithm is often inefficient to capture temporal correlations. Thus, if data is fed to a cloud environment, parallel implementation of the algorithm on MapReduce [43] could be designed as shown in the work.

User trustworthiness denotes the average reputation of a user over time. An adversary may first build reputation over time, and when it reaches a certain threshold (and hence get recruited for many crowd-sensing tasks), it may start to misbehave, which could be difficult to detect. In [44], user credibility is assessed from sensing activity, reports from review requests, and authorities. Anchor-based voting as in [8] can also be applied to identify trusted users. For voting, history data does not need to be stored but gets reflected in the trust calculation. Anchor nodes are considered to be 100% trusted but their sensing accuracy may vary due to malfunctioning. Anchor nodes are used to vote new users for their trustworthiness.

5.3.3 Incentive Mechanisms

Incentive mechanisms also ensure reliability of users as users tend to provide reliable data for good incentives. MCS system can be crippled if incentive mechanisms do not stimulate human participation. Incentives should be provided to reward cooperation. It can be monetary, gamification, or by other means like providing service, increased social recognition or visibility, and so on [5].

Monetary incentive is the most common form of incentives in crowdsourcing literature as well. It can depend on the number of sensors engaged in a task, power consumed by the sensors [6], and/or data transmission required for the task. Users may be rewarded after each task completion or it may depend on timely completion of a predetermined number of tasks. In [14], an MCS framework is proposed that uses monetary incentives to encourage user participation. Such incentives could be given after completion of each task or only after completing a predefined number of tasks.

In some works, the incentive is not monetary but in terms of service a user would get. For instance, in [17] a credit system is proposed as incentive so that users do not ask for others' participation unless they help others.

Many works are done on gamification of incentives. In [45], two incentive methods are compared experimentally: one is micro-payments where a small amount of money is paid for each task and the other is weighted lottery where the return is two times more than micro-payments if won. It was observed that for the crowdsourcers, weighted lottery was more attractive; however, micro-payments resulted in more productive users because of guaranteed payments. When enough users are not participating in an event, a small amount of monetary incentive may be rewarded to the group in order to attract the idle users of the community for future sensing tasks as in [46]. To stimulate user participation, in [47] a reverse auction-based dynamic pricing incentive mechanism is devised. Here users can participate in sensing tasks and sell their sensing data to a service provider for bid prices claimed by the users themselves. The user with minimum bidding price wins. However if a reliable user loses multiple times, s/he may leave the system. In order to prevent such possibility of starvation, the authors devised a mechanism called virtual participant credit (VPC). The server gives a virtual credit to the participants who lost in the reverse auction as a reward for their participation only. This can only be used for lowering bid price of future rounds thus increasing the winning probability of user for the future auction rounds. Such participation incentive maintains enough active bidders (i.e., desired level of participatory sensing service quality) and stabilizes the incentive cost by keeping the price competitions. The mechanism not only reduces the incentive cost for retaining the same number of participants but also removes the burden of accurate price decision for user data.

In [48] incentive mechanisms are devised based on Stackelberg games and contract theory. However, the mechanisms provided require either the complete information or the prior distributions of users' private types. Thus a priori knowledge is needed. This restriction is removed in [49] by exploiting bidding mechanism. Here (in [49]) the server announces a set of sensing tasks. Crowd users with different available time and sensing costs bid for these tasks. The authors designed mechanisms to optimally schedule the users achieving multiple performance objectives including truthfulness, individual rationality, provable approximation ratios, and computational efficiency simultaneously. The mechanism is shown to work for two underling scenarios:

• • when all users arrive at the same time (offline)
• • when users appear sequentially (online).

In [50, 51] game theoretic approaches are explored to devise incentive mechanisms though it is assumed that any sensing task can be done instantly. The nature of smartphone users opportunistically occurring in the area of interest is exploited [51]. This online approach is characterized by computational efficiency, individual rationality, and profitability. Here a user, appearing at a certain area of interest, receives available task descriptions from users. Then if it decides (according to the mechanism proposed) to carry out some tasks, it bids for the same. The server may accept the bidding and assign those tasks and payoff.

Summary of incentive mechanisms for MCS is presented in Figure 5.8.

5.3.4 Localized Analytics

An important issue of MCS is to decide about the information processing to be done in tier 1 devices itself. Depending on the type of applications, sensor readings need to be preprocessed before sending it to a server. For instance, in pothole detection application as described in [52], the presence of spikes is detected from 3-axis acceleration sensor data to determine potential potholes. Only when potholes are detected, relevant data need to be sent to the server. Local analytics may also help in data aggregation, thus consuming less energy and bandwidth because of the compact representation. Noise and redundant data may also be removed through local analytics. Here the trade-off between energy consumption due to local computation and that due to data transmission is to be taken care of as more local analytics may save size and frequency of data transmission. Two functions of local analytics have been identified in [3], namely:

1. 1. Data mediation - It involves filtering of outliers, elimination of noise, or filling in data gaps. For example, due to lack of line of sight, GPS samples acquired may not be accurate. Thus noise elimination or filling in data gaps by extrapolating samples may be required.
2. 2.

   Context inference - Sometimes it is important to detect the context in which the sensor readings are taken. This involves processing of some other sensor readings, for instance, to detect kinetic mode (walking, standing, jogging, running) of humans. Like a person may want to know if many joggers are there at a park so that s/he may go for jogging safely [40]. For this application, only data from joggers who are running is important to the server for analysis.

   The analytics performed for inferring context is mostly application specific. Hence if multiple crowd-sensing applications run on the same device, context inference could be computationally expensive for all of them though many may require readings from the same sensor or similar computation. Moreover, the health of the device in terms of remaining energy and current load should be taken into account before performing mining on the data.

5.3.5 Security and Privacy

MCS calls for many important concerns from citizen's point of view, such as the sharing of personal data (e.g., user location, ambient sound), can raise significant concerns about security and user privacy. As stated in [53], MCS applications potentially collect sensitive sensor data pertaining to individuals that can be used to detect behavioral patterns of individuals. For example, GPS sensor readings can be used to estimate traffic congestion levels and/or anomalies in a given community, but at the same time these can be used to infer private information like movement trajectory of an individual, routes they take during their daily commutes, and home and work locations. In [54], a reputation system based on the Gompertz function is proposed that estimates the trustworthiness of the collected data. Privacy can be preserved if sensing data is processed to make it anonymous and the private part of the data is removed before sending it to the server. However, as predicted in [55], it may cost energy and computation for the crowd-sensing devices. Rather privacy-preserving architecture for crowd-sensing must be designed. AnonySense [56] is such an architecture. It provides a new tasking language for context queries, which will be submitted by the crowd-sensing applications. These tasks are assigned to anonymous nodes, and eventually collected verifiable yet unlinkable reports are fed back to the applications. Consequently, in [57], a privacy-preserving approach for untrusted aggregator is proposed that delinks data from its source in a group of user's data. Thus it does not hide data and only shows specific aggregation results like conventional privacy-preserving approaches. This protocol shows individual data but achieves “-source anonymity” in the sense that an aggregator only learns that the source of any particular piece of data is one of users in a group. Thus any aggregation function can be applied on the data yet maintaining the privacy of individual users in the group. For a large pool of users having varying privacy requirements, authors categorize users in groups having similar privacy requirements.

The issues discussed above are not independent of each other. For instance, task assignment is very important as it decides whether localized analytics is needed by the task. Like for context-sensitive tasks, deciding about the context locally is very important. Moreover, incentives are also task specific and the amount and/or even type of incentive varies with tasks. However, the crowd is attracted by incentive mechanisms. Thus user profiling is driven by incentive mechanisms. Moreover, for tasks requiring localized analytics, it is important to attract trusted users being capable of sensing the context efficiently. Privacy of collected data should be preserved. Thus localized analytics is also a factor in profiling users. This is summarized in Figure 5.9.

These issues maps to the following challenges:

• • Strategies should be figured out to attract majority of citizens in terms of incentives (feedback from user profiling to task assignment). It may be money, social recognition, and so on [5].
• • Framing the data collection phase in a manner to reduce communication and storage overhead. For instance, text fields could be preferred than sending images and/or videos. Localized analytics may play a key role here.
• • Correctness of data should be ensured before assessing them. False positives need to be filtered out. This again depends on proper incentive mechanism.
• • How to reuse one sensor data for different applications in energy efficient manner [3].
• • Ensuring security and privacy of data.
• • Efficient data processing and aggregation poses an important challenge [41].

5.4.1 Here--Now Framework

Here--Now is an MCS framework for smart city applications where individuals want to know about a nearby place in terms of noise level, activity level, light intensity, and crowd intensity [40]. For instance, a person wants to select a quiet restaurant for peaceful discussion or a park for jogging where many joggers are there (for safety). Such framework uses opportunistic sensing to collect data from citizens. It correlates mobile sensory information to information from social media in real time. The design of the framework is shown in Figure 5.10. There are two entities in the framework - the crowd users and the cloud data provider. The crowd users are responsible for two functions - data collection and analysis, querying clients. The cloud data provider is responsible for context-aware data processing.

1. 1. Data collection and analysis - This module captures sensory data, performs real-time stream mining on the data, and uploads analyzed information to the cloud. To reduce the communication cost, only analyzed information from each device is sent to the cloud. Resource-aware clustering technique is applied to the collected sensor readings to identify significant changes in the situation. This module also includes the ability to plug in mobile activity recognition model. The authors used a neural network-based activity recognition model for recognizing four basic activities - walking, running, sitting, and driving - using the sensed accelerometer data. Thus only if a person is jogging at a park, his/her information would be meaningful for the query mentioned above.
2. 2. Context-aware processing - This module inferences situations using the real-time sensory and activity data collected from mobile users. As shown in Figure 5.10, any context reasoning engine can be integrated into Here--Now for inference. The authors used fuzzy situation inference (FSI) model, which integrates fuzzy logic into the probabilistic context spaces (CS) model. It combines the benefits of the CS model for supporting pervasive environments along with fuzzy logic to deal with uncertainty associated with human concepts and real-world situations.

Localized analytics for activity recognition is a big advantage in this framework as it only sends meaningful information to the cloud. However, continuous data streaming could be a bottleneck. Moreover, the accuracy of query results depends on availability of active users in desired places.

In [59], a similar framework named silent mobile sensing framework is proposed where the cloud server after statistical analysis publishes data on top of maps for better visualization. In this work, authors also considered data compression before uploading to the cloud server.

5.4.2 Crowd-sensing Framework based on XMPP

XMPP realizes a pub/sub communication model [16, 60], where publications sent to a node are automatically multicast to the subscribers of that node. In [16], a crowd-sensing framework based on XMPP pub/sub model is proposed. In fact, the pub/sub model fits well with many crowd-sensing applications where the data is collected from crowd and analyzed and service is delivered to the crowd itself, for instance, smart transport service where the user standing at a bus stop may know about availability of seats or current position of the bus. As shown in Figure 5.11, here the crowd is the producer as well as the consumers of data also known as prosumers. However, there is a service provider entity mostly the cloud data provider that can play several roles at the same time like collecting data (consumer role) and storing and analyzing producers' data to offer (service provider role) value added service. Producers as shown in the figure publish raw data to the event nodes. Service providers intercept these data by subscribing to the raw event nodes, analyze it asynchronously, and publish cleaned up information or value-added service to the content nodes. Interested consumers receive the added value/service by subscribing to the appropriate content node(s) in an asynchronous manner.

5.4.3 McSense

In [5], an MCS platform, McSense, is proposed that is based on three-tier architecture as shown in Figure 5.12. Here the three entities are the following:

• • McSense mobile app - This component resides at the smart devices and receives task offers, allows users to accept them, and provides the tools to complete them by seamlessly configuring all needed sensors available on board. The task apps report their collected data to the McSense mobile app. In addition, the McSense mobile app may also collect data to profile users, devices, and regions. Upon completion sensed results and profiling data are uploaded to the McSense data back end, and incentives are received.
• • McSense data back end - This component resides in some server and receives data from the McSense mobile app. It stores and analyzes sensed data to evaluate task performance and profile technical and social dimensions of users. Task performance includes parameters like task completion time, number of users employed, and so on. However, for many tasks, data from several users need to be aggregated and collectively analyzed at the back end. Technical dimensions of user devices include number and type of sensors available on the smartphone, available battery, and so on. Social ones include relationship among users, frequency of users visiting the sensing task area, and so on.
• • McSense task control console - This component may be handled by city managers corresponding to tier 3 in Figure 5.2. It may reside as a web application, and, apart from data visualization, it offers two main functions: task design and task assignment. The task design component takes into account profiles stored in the data back end and task-related data (location, area, and duration) and evaluates the desired task completion time and workers ratio to complete the task with a desired probability. The task assignment component defines the optimal set of workers to carry out the sensing task. For example, assigning a task to a user typically spending much time in an area (as reflected in user profiles) increases its probability of success. The task assignment strategies of McSense are already detailed in Section 5.3.1.

The framework also talks about monetary or service incentives given to users. It is valid for participatory sensing. The authors implemented the framework and were shown to experiment with different types of task assignments. However, the need for localized analytics for better task processing may be considered.

5.4.4 Supporting Framework for Crowd-sensing Apps

In [61], a framework is proposed for supporting crowd-sensing applications in smart cities. The main focus of this work is to help the non-programmers design and deploy crowd-sensing applications. The framework is built on two entities: participant and initiator. Initiators are responsible for developing the application and asking for sensing data from participants. Participants may accept to sense and send data to a server. Both participant and initiator are smartphone users. The framework runs in two parts - configuring and assembling part and mobile crowd-sensing app runtime (CAR) part. In the configuring and assembling part, the app designer specifies the functionalities and constraints through XML-based language, which is used by a predefined campaign model to form the participant module, initiator module, and server side programs for both initiator and participants. The notable functionalities of CAR module include participant recruitment, energy- and cost-efficient sensing data collection, participant profile management, participant experience control, and location reliability verification.

The above mentioned frameworks are compared with respect to the issues mentioned in Section 5.3 and are summarized in Figure 5.13. Frameworks proposed in [14, 61] are for designers of crowd-sensing applications. These frameworks aim at abstracting the details of the execution and programming burden from users while providing an easy-to-learn user interface for designing applications. However, many works [5, 16, 40] focus on designing a framework for crowd-sensing applications itself. Money seemed to be a common incentive mechanism; however, some works like [40] indicate that the benefit goes to both the contributors and initiators of crowd-sensing applications.