2015 IEEE/ACM 8th International Conference on Utility and Cloud Computing
The Origin and Trustworthiness of Data in Smart City Applications
Aseel Alkhelaiwi
Department of Computer Science
University College Cork (UCC)
Cork, Ireland
aa8@cs.ucc.ie
Abstract— Mobile devices and their sensors facilitate the
development of a large range of environment-sensing
applications and systems. Crowd sensing is used to feed
smart city applications with anonymous but still relevant
data. The quality and success of smart city applications
depend on several aspects of user involvement, such as data
trust and information about data origin. However, with the
anonymity and openness of crowd sensing, smart city
applications are exposed to untrustworthy and malicious
data that can lead to poor decisions. In this paper, we
propose a cloud architecture for smart city applications that
includes, as a core service, a reputation system for
evaluating the trustworthiness of crowd sensing data. This
service will run locally, as close to the crowd as possible, for
example, on wireless local area network (WLAN) access
points (AP). Additionally, data stored in the cloud is
traceable by its origin information.
Keywords-crowd sensing; smart city applications; cloud;
trust; data origin
I. INTRODUCTION
Mobile devices, with their sensing capabilities, e.g.,
global positioning systems (GPS), accelerometers,
cameras, microphones, etc., are a rich source of
environment sensing data. Crowd sensing, which involves
anonymous crowd data contribution, can be used to
develop a wide range of applications and systems. These
include smart city applications that focus on improving
the citizen’s quality of life, such as through better traffic
management and effective disability support. However,
due to the limited resources of mobile devices, sensed
data are usually offloaded and processed in data centers -
clouds. Cloud computing involves providing resources to
a client on an on-demand basis by using Internet
connectivity. Mobile cloud computing (MCC) has the
added benefit of being a motivating technology for crowd
sensing by uploading a large amount of sensed data from
mobile phones and other sensors to the cloud to be
processed by smart city applications. The success of smart
city applications depends on the users’ involvement.
However, with the open nature of crowd sensing and high
user contributions, smart city applications can be exposed
to untrustworthy and malicious data. For example, some
users may unintentionally contribute incorrect data simply
because the mobile device was in the wrong position or
the sensor had gone out of calibration. Other users may
978-0-7695-5697-0/15 $31.00 © 2015 IEEE
978-1-4503-3890-5/15
DOI 10.1109/UCC.2015.60
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY MADRAS. Downloaded on June 08,2021 at 09:29:37 UTC from IEEE Xplore. Restrictions apply.
Dan Grigoras
Department of Computer Science
University College Cork (UCC)
Cork, Ireland
d.grigoras@cs.ucc.ie
contribute data that serve their own interest e.g., a leasing
agent who sends fabricated low noise readings in order to
sell a particular property. Therefore, smart city
applications are useless for citizens in the community if
the data contributions cannot be trusted. Thus, the
trustworthiness of data contributed by users/devices must
be evaluated to identify a malicious contribution, i.e.,
ensuring data trustworthiness is essential to satisfying
successful smart city applications [1].
Another key aspect is the possibility of tracing the
origin of data without affecting contributors’ privacy.
Over time, clouds store large amounts of data that will be
used by many different applications. If data are wrong and
there is no information about their origin, not only will
applications return incorrect results, but there is also no
way of identifying the source(s) of the errors. Therefore,
we consider that data traceability should be another
feature of smart city applications processing crowd
sensing data. This new feature of mobile cloud
architecture is important, even in the presence of a trust
system as an additional check, identify and correct
mechanism.
In this work, we propose a reputation system for
evaluating the trustworthiness of the sensor data
contributed by users/devices. This reputation system is
different from previous work, discussed in section III.
Instead of having the reputation system deployed in the
cloud, its service will run locally, as close to the crowd as
possible, for example, on wireless local area network
(WLAN) access points (AP). Local processing of crowd
data has several benefits, especially in reducing the
amount of traffic and data filtering. This service allocation
on APs is reasonable in a city Wi-Fi network that is
designed to support the community. We make the
following specific contributions:
• A cloud-centered smart city architecture that
includes trust and data traceability services is
proposed.
• We argue for the need for a reputation system in
participatory sensing applications to assess the
trustworthiness of user-contributed data. We
propose a reputation system that is located in the
proximity of data contributors using, for
376
 example, WLAN APs.
The rest of this paper is organized as follows. Section
II presents the background and motivation for the work.
Related work is summarized in Section III. Section IV
provides an overview of the system architecture. The
proposed method is given in section V and the discussion
in section VI. Section VII concludes the paper.
II. BACKGROUND AND MOTIVATION
A. Smart City Application
The concept of a smart city has been introduced as the
application of pervasive computing models to urban
spaces that focus on developing city network
infrastructures, optimizing traffic and transportation and,
generally, improving citizens’ quality of life. Emerging
technologies, such as mobile devices, wireless networks,
cloud computing and vehicular networking, promote the
development of urban computing within smart cities by
enabling tracking and sensing using people’s mobile
devices [2]. Therefore, citizen contribution is an important
feature of the system and becomes a requirement for the
effective implementation of the smart city concept.
B. Crowd Sensing
Mobile devices and their sensors have led to sophisticated
context-aware applications and systems. This area has
captured a large amount of interest in how users’ mobile
phones can contribute sensor data towards enabling
environmental awareness (e.g., air pollution and
transportation), community awareness, healthcare
awareness, etc.
Context awareness is considered the first generation of
sensing and defined by Pascoe as the ability of devices to
sense, interpret and respond to aspects of a user's local
environment [3]. Today, crowd sensing, the second
generation of sensing, is receiving a lot of attention. It
refers to the acquisition of sensor data from multiple (not
only one) mobile devices, generally corresponding to the
same geographic area. There are some approaches, such
as mobile sensing [4] and public sensing [5], that are
similar in definition or goals to crowd sensing and are
sometimes used interchangeably in the field.
C. Motivation
Ultimately, the trustworthiness of the contributed data and
establishing the origin of those data are very important in
any crowd sensing application in order for the users (i.e.,
data consumers) to use the data confidently. We consider
that detecting the trustworthiness of data is a major
challenge, which, when overcome, will help guarantee the
success of the crowd sensing application. The following
377
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY MADRAS. Downloaded on June 08,2021 at 09:29:37 UTC from IEEE Xplore. Restrictions apply.
are some scenarios in which evaluating data is very
important:
1) Events Reporting: Users could report events that
occurred in malls, universities and other public places and
share them with others. However, malicious users could
try to fabricate the appearance of a crowd at an event in
order to promote it [6].
2) Road Repairs: Suppose the City Hall of city “X”
launched a mobile application that helped users to send
photographs and locations of the roads that need to be
repaired in their neighborhood. Malicious users could
fabricate images in order to have their neighborhood
repaired first [7].
3) Traffic Warning: Suppose there were an
application that received traffic jam warnings from users
in a specific location and distributed these alerts to other
drivers. Untrustworthy users could send false warnings
for some location to reduce traffic congestion for
themselves [8-9].
III. RELATED WORK
A widely used approach to the efficient assessment of
the trustworthiness of sensed data received from different
users is to use a reputation system [1]. Researchers [10]
have proposed a reputation system for participatory
sensing applications that measures user trust by giving a
reputation value to each user for his/her contributed data.
They adopt a similar architecture to the Reputation-based
Framework for Sensor Networks (RFSN) [11], a
reputation framework for traditional embedded wireless
sensor networks. The downside of this system is that the
trust value of any user is only computed by taking into
account the historical behavior of that user, unlike our
approach, in which the trust value is calculated regardless
of the previous contributions.
In the proposed Wi-Fi sensing system for smart city
applications, the authors [12] address the trustworthiness
of the data published in their system by forming
endorsement links between users so that the users can
submit reviews of Wi-Fi hotspots along with the data
publishers. Their system is different to ours in that
trustworthiness is actually calculated in the cloud by the
number of submitted reviews and the number of
endorsements earned, not by testing the data itself (in
their case, the strength of the Wi-Fi).
Another system addressing the trustworthiness of
crowdsourcing systems, called Trustworthy Sensing for
Crowd Management (TSCM), has been proposed [13] as a
cloud-centric crowd management scheme. TSCM adopts
 the MSensing auction and incentives system for smart
phones [14] and improves it by presenting the reputation
awareness and trustworthiness of the smart phone users.
Moreover, user reputation is updated regularly in the
cloud in TSCM, where reputation is used as a basis to pay
users and assign tasks for them. The reputation score
calculation depends on the accuracy of the sensed data.
The authors’ system performs the auction and the
calculation of the trustworthiness in the cloud, while our
system undertakes the calculation of trust locally.
Furthermore, in their case, the cloud receives all the
sensing data, whether trusted or not, from users, whereas
in ours only the sensed data from users with a trust value
above a specific threshold are sent to the cloud.
ARTSense [15] is a framework that addresses the
problem of trust and anonymity in participatory sensing
systems. The trustworthiness of the sensing data is
calculated using a trust assessment algorithm. Their
algorithm is similar to ours as they use different weighting
factors (location, time, sensor mode and traveling mode)
to build trust but concentrate on anonymous user
reputation levels and preserving privacy for users. Unlike
our system, ARTSense performs the anonymity and trust
algorithm in the cloud.
CrowdSC [16] is a crowdsourcing framework that
uses citizen participation in the context of a city. It
transforms queries into simple tasks: collect, filter the data
provided by users, and provide as well as return the
results to the user. To make the right assessment of the
data, the authors propose a three-step process. The data
collection step collects photos from participants. The data
selection step asks other participants to select the photo
that best represents the problem. Finally, the data
assessment step asks participants to assess each photo
selected from the data selection step. The proposed
system performs all of these steps for assessing data
Figure 1: Cloud architecture for smart city applications.
378
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY MADRAS. Downloaded on June 08,2021 at 09:29:37 UTC from IEEE Xplore. Restrictions apply.
contributed by users in the cloud, which means that the
cloud will receive both useful and useless data during the
process, which is impractical, and not the case with our
approach. All of the above systems use a cloud/server to
compute the trustworthiness of the data contributed. In
our proposed system, the trustworthiness calculations
take place locally in, for example, WLAN APs or a local
server.
IV. THE SYSTEM ARCHITECTURE
A. Definitions of Trust and Reputation
In this work, we use “trust” and “reputation” as
separate views, following another work [17]. The term
“trust” relates to building the user’s trust and level of
reliability in his/her current contribution accumulated by
an AP, i.e., data sensing contributions performed in a
specific period of time, such as one day. Reputation
management takes place in the cloud to update the user
reputation for all of his/her contributions regularly.
Therefore, trust is a value calculated in an AP over a
period of time, alongside the sensed data. On the other
hand, reputation is a value calculated in the cloud,
whereby the cloud takes the new trust value received from
the AP for a specific user and adds it to the previous
reputation to update the reputation value for this particular
user. In other words, the history is considered in the
reputation calculation process, not in the trust process.
B. Smart City Architecture
In our system, there are four components that
correspond to the four cloud-centric layers [18] in smart
cities (Fig. 1).
1) Sensor Data Producers
A subset of users, from two to what we call a crowd, in
a particular area installs an application called “SenseAll”
 on their mobile devices, which then start sensing different
aspects of the city (e.g., traffic, pollution levels, water
levels or leaks). We make the distinction between two
types of producer: non-malicious producers who produce
truthful data and malicious producers who send untruthful
data.
2) Access Points
The AP receives the sensed data and the user ID,
performs some processing on the data, inserts the data in a
log file, then calculates the trust of the user in terms of
this particular contribution depending on a number of
factors discussed in section V. The data are stored for a
period of time, e.g., one day or one week. After that time,
data are removed from the log file and sent to the cloud,
along with the user ID and the trust value.
3) Cloud Platform
A cloud computing platform provides databases in
which providers’ information, reputations, history and
sensed data are stored. Furthermore, the platform hosts a
number of smart city applications that use the sensed data
stored in the cloud. These applications are ready to be
installed/used by consumers.
4) Consumers
Consumers are people or private or public authorities
who consume the sensor data published by the sensor data
providers. There could be one, two or a large number of
consumers. Consumers need to register in the cloud in
order to use (i.e., install) smart city applications that
benefit from the sensor data stored in the cloud.
In our architecture, building trust is performed locally
in a log file that is located as close to the crowd as
possible, for example, in the WLAN AP, while the
reputation is saved in the database in the cloud. We are
proposing a protocol that involves the entire system
architecture presented in Fig. 1 and consists of the
following steps:
Step 1. Users will use an application called “SenseAll”
installed on their phones to start sensing their
surroundings after the authentication process is
completed.
Step 2. Users’ devices send data (photos, voice,
location, status, date or time), to the cloud using Wi-Fi
access networks.
Step 3. The sensed data, along with the user ID, are
received by the WLAN AP, where specific processing is
carried out.
379
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY MADRAS. Downloaded on June 08,2021 at 09:29:37 UTC from IEEE Xplore. Restrictions apply.
Step 4. In the WLAN AP, the sensed data, along with
the user ID, are cached, processed and inserted in a log
file for a period of time in order to build the trust (details
in section V), then the data are sent to the cloud.
Step 5. In the cloud, data are saved in the sensor
database along with the user ID. The reputation of the
particular user is updated when the trust value is received
and then saved in the reputation database. The user
reputation is updated every time the user sends sensed
data.
Step 6. The sensor database in the cloud is clustered to
other different databases to serve different aspects of the
city (traffic database, environment database, etc.).
Step 7. Smart city applications running in the cloud use
the different databases created in the cloud.
Step 8. The smart city applications are made available
to consumers’ clients. In other words, consumers will be
able to subscribe to the cloud and install the clients of
different smart city applications.
V. PROPOSED METHOD
When the sensed data are received, for instance, by the
AP, the data are cached and stored in a log file, along with
the user ID, for a determined period of time (e.g., one
day) in order to start building trust. We consider four
important factors for assessing trust with a weighting
parameter for every factor:
1) The user status (i.e. not moving, walking, or moving
fast) is an important factor that could affect the quality of
the sensed data being sent. The weighting parameter (S)
of every status is illustrated in Tab. 1. Every status is
given a weight according to the quality of the data
produced with it. For example, the quality of a picture
taken from a moving vehicle is different from that taken
when the user is stationary. In other words, pictures may
be shown to be blurry when someone is moving. Someone
taking a picture while walking will also have less chance
of taking a blurred picture than when running. Therefore,
the “not moving” status is accorded a higher weighting
than “walking”, “walking” has a higher weighting than
“running”, etc.
Table 1: User status weighting parameter.
User Status S
Not moving 0.2
Walking 0.15
Running 0.1
 Moving > 40 mph 0.05 After these factors are calculated, (1) is performed to
compute the trust for the contribution for user “u”:

2) The variety of sensed data will add more weight
when building trust. In other words, the weight parameter
is higher for a user who sends a photo along with a
recording and location than a user who sends a photo with
a location only. The weighting parameter for the different
sensors is shown in Tab. 2. The number assigned to every
sensing style depends on the degree of effort made by the
user. Recording voice notes and taking photos need more
effort from the user than location, since the location is
sent by default from the user’s mobile phone. In the
SenseAll application, the location needs to be turned on
before sensing in order to send the sensing data (voice,
photo).
Tu = e(Su + SSu + Nu + Simu) (1)
The value Tu ranges from (1.0) to (3.8). This value is
tested before sending it to the cloud (after the predefined
period of time, e.g., one day):
• If the value is below a specific threshold (below
or equal to 1.2, where this threshold is chosen
based on the lowest accepted trust value), then
the contribution will be discarded and the trust
value Tu is re-calculated in (2) and sent to the
cloud along with the user ID:
Tu = - eTu (2)

Table 2: Sensing style weighting parameter. Note that Tu in (2) is a negative number.

Sensing Style SS • If the value is above the threshold, then it will be

Location 0.05 sent to the cloud along with the user ID and the
Voice 0.2 sensed data. The user ID and the sensed data are
Photo 0.2 saved in the sensor database.

3) The user who contributes more to the sensing The trust value is considered in (3) to update the
activity will add more weight to his/her trustworthiness. If reputation value of this user in the reputation database:
one user sends sensed data regularly during a period of
time (the time before the log file is sent to the cloud), the Repu = Rep’u + Tu (3)
trustworthiness of this user and the data he/she sends will
be scored as 0.05 for every contribution, excluding the Where Repu is the new reputation value and Rep’u is the
current contribution. In other words, in our system, previous reputation value. The reputation is in the range
loyalty is an important factor. It is calculated for this from (0) to (100).
parameter for user “u”: Our intuition is that consecutive high trust values will
build a reputation, but one low trust value will ruin it. For
Nu = number of previous contributions in a example, user “X” downloads the SenseAll application,
predefined time * (0.05) agrees to turn the location on and wants to start sensing
data. He/She takes a photo while walking in an area of
4) Sensed data that are similar to each other are interest and sends it to the cloud. Before being received
beneficial to each other. For example, if user “X” and user by the cloud, the data are evaluated in the AP (or a local
“Y” are in the same location and send data that are similar server). User “X” will have a weight of 0.15 for user
to each other, this will add trust for both users. On the status, 0.05 and 0.2 for location and photo, respectively, 0
other hand, if the two users are in the same location but for the number of contributions made during the day
their data are in conflict, the sensed data of the user with (since this was the first) and 0 for similarity, as no similar
the higher reputation, from previous contributions, will be sensing data have been taken in that specific location.
considered and the other one will be discarded. Therefore, Then, Tx = e 0.4 = 1.4, which means the data of user “X”,
similar data will be weighted more heavily when along with his/her trust value Tx= 1.4 and user ID, are
calculating the trust value. This factor is calculated as sent to the cloud, as Tx is above the threshold. To illustrate
follows for user “u”: how the algorithm works in two different scenarios, see
the examples below:
Simu = ∑ u,u’∈ LOG, S’(u,u’)
Table 3: Trust and reputation for user "X".
Where u and u’ are two different users, LOG is the log
Day Day Day Day Day Day Day
file in the AP, S’ is the similarity factor that ranges from 1 2 3 4 5 6 7
(0) for no similarity and (0.1) for similarity. Trust 1.3 2.1 1.9 1.7 1.2 1.4 1.6
Reputation 1.3 3.4 5.3 7.0 3.7 5.1 6.7

380

Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY MADRAS. Downloaded on June 08,2021 at 09:29:37 UTC from IEEE Xplore. Restrictions apply.
 Example 1:
User “X” downloads the SenseAll application, agrees 



to share his/her location and wants to start sensing the 





  
 

environment in location “A”. During the first four days of 

sensing, shown in Tab. 3, he/she gains trust values that are 

above the threshold (1.2), which means that the reputation 

value is added every day (Day 1 = 1.3, Day 2 = 1.3 + 2.1 

= 3.4, Day 3 = 3.4 + 1.9 = 5.3, Day 4 = 5.3 + 1.7 = 7.0).

However, on the fifth day, the user sends data that have a 

trust value equal to the threshold, as the picture he/she


sends is corrupted and only the location counts.



Therefore, the trust value is calculated using (2):







1.2
Tx = - e = -3.3 

Figure 2: User "X" and user "Y" reputation values in one week.
And the reputation is calculated using (3):
And the reputation is calculated using (3):
Repx = 7.0 – 3.3 = 3.7
Repy = 1.5 – 3.3 = - 1.8
Note that one bad contribution will have a detrimental
effect on reputation (see Fig. 2). On the sixth and seventh Day 3:
days, the user contributes good data that improve the The trust value is calculated using (2):
reputation but the harm of that one bad contribution
cannot be recovered completely after two days. Ty = - e1.1 = -3.0

Table 4: Trust and reputation for user "Y". And the reputation is calculated using (3):
Day Day Day Day Day Day Day
1 2 3 4 5 6 7 Repy = (-1.8) – 3.0 = - 4.8
Trust 1.5 1.2 1.1 1.7 1.9 1.4 1.7
Reputation 1.5 -1.8 -4.8 -3.1 -1.2 .2 1.9 Then, as shown in Tab. 4, the user took three days to
recover from the two consecutive pieces of untrustworthy
data contributed (see Fig. 2). Therefore, in our approach,
Example 2: building trust takes time but contributing malicious data
User “Y” downloads the SenseAll application, agrees ruins a reputation.
to share his/her location, and wants to start sensing the
environment in location “B”. During the first day, shown
in Table 4, he/she contributes trusted data and has a VI. DISCUSSION
reputation value of 1.5. The data contributed on the We believe that our simple but effective approach will
following two days are below the threshold. This leads to reduce the amount of untruthful data in the cloud by a
negative reputation values that equate to a reputation of large degree, since data with low scores (below a specific
zero. The reputation value is treated as zero because there threshold), according to the factors presented, are
is no scale for negative numbers in our approach; we keep discarded and not sent to the cloud. Unfortunately, existing
them simply to make the reputation calculations. These solutions proposed in related works to solve the issue
are the calculations that occurred on the second and third mentioned in the scenarios in section II and others are
days. weak because they:
• either require offloading all sensed data to the
Day 2: cloud and evaluating the trustworthiness of
The trust value is calculated using (2): the data there, which is unnecessary traffic
and time consuming, or
Ty = - e1.2 = -3.3 • add significant overheads to users’ mobile
phones, since the processing and evaluation
takes place on the phone.

In our proposed solution, the sensed data are processed

and evaluated locally. Malicious data are immediately
discarded when discovered, and not sent to the cloud.

381

Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY MADRAS. Downloaded on June 08,2021 at 09:29:37 UTC from IEEE Xplore. Restrictions apply.
 Thus, we save more time and avoid traffic overheads when
sending data to the cloud. Furthermore, in our approach,
we require that the location service in the mobile phone be
turned on before the user starts sensing in the SenseAll
application in order to support traceability. We believe
that, with traceability, smart city applications in the cloud
will benefit the most from the data sensed. In our
architecture, we overcame the issue of exposing user
identities to traceability by ensuring anonymity. This is
because user identities are not sent to the cloud in the first
place, since we only use application IDs assigned to every
contributing user, and these IDs are the ones sent to the
cloud.
VII. CONCLUSIONS
Smart cities run their applications with data contributed
by their inhabitants. Crowd sensing not only means
involvement and participation, but also raises issues of
data trust and origin. Indeed, a smart city cannot run on
untrustworthy data or be unable to trace data origin, as the
quality of its application results depends on these features.
In this paper, a smart city architecture that uses crowd
sensing is proposed. The problem of the trustworthiness of
the sensing data is addressed and we present our original
approach to solving the problem. Instead of offloading all
the sensed data to the cloud to make the evaluation there,
as all previous works suggest, the sensed data are
evaluated and processed locally (i.e., in local servers, APs,
etc.) before sending the data to the cloud. Malicious data
are then discarded and trusted data are sent to the cloud,
along with the trust value obtained by our approach, in
which the reputation is calculated using historic values
gained by this user. Therefore, we reduce traffic and
minimize the amount of time wasted. We also evaluate the
quality of the results of our solution.
As the next step, we will develop this approach further
and increase its effectiveness in reducing the amount of
untruthful data in the cloud in order for it to be used by
different smart city applications.
ACKNOWLEDGMENT
Aseel Alkhelaiwi’s research is funded by King Saud
University in Saudi Arabia.
REFERENCES
[1] K. L. Huang, S. S. Kanhere, and W. Hu, “A privacy-preserving
reputation system for participatory sensing,” Proc. 37th Conference on
Local Networks (LCN), pp. 10-18. Oct. 2012.
[2] J. Wan, D. Li, C. Zou, and K. Zhou, "M2M communications for
smart city: An event-based architecture," 2012 IEEE 12th International
Conference on Computer and Information Technology (CIT), pp. 895-
900, 2012.
[3] J. Pascoe, “Adding generic contextual capabilities to wearable
computers,” 2nd International Symposium on Wearable Computers, pp.
92-99, 1998.
382
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY MADRAS. Downloaded on June 08,2021 at 09:29:37 UTC from IEEE Xplore. Restrictions apply.
[4] D. Estrin, “Participatory sensing: applications and architecture
[internet predictions],” IEEE Internet Computing, vol. 14, no. 1, pp. 12-
42, 2010.
[5] D. Christin, A. Reinhardt, S. S. Kanhere, and M. Hollick, “A survey
in mobile participatory sensing applications,” Journal of System and
Software, vol. 84, no. 11, pp. 1928-1946, 2011.
[6] K. Toyama, R. Logan, and A. Roseway, “Geographic location tags
on digital images,” Proc. 11th ACM International Conference on
Multimedia. ACM, pp. 156-166, 2003.
[7] K. Benouaret, R. Valliyur-Ramalingam, and F. Charoy, “CrowdSC:
Building smart cities with large-scale citizen participation”, IEEE
Internet Computing Journal, vol. 17, Iss. 6, pp. 57-63, 2013.
[8] J. Herrera, D. Work, R. Herring, X. Ban, Q. Jacobson, and A. Bayen,
“Evaluation of traffic data obtained via GPS-enabled mobile phones:
The mobile century field experiment,” Transportation Research Part C:
Emerging Technologies, vol. 18, no. 4, pp. 568-583, 2010.
[9] J. White, C. Thompson, H. Turner, B. Dougherty, and D. Schmidt,
“Wreckwatch: Automatic traffic accident detection and notification with
smartphones,” Mobile Networks and Applications, vol. 16, no. 3, pp.
285-303, 2011.
[10] K. L. Huang, S. S. Kanhere and W. Hu, “Are you contributing
trustworthy data? The case for a reputation system in participatory
sensing,” Proc. of ACM (MSWiM ’10), 2010.
[11] S. Ganeriwal and M. Srivastava, “Reputation-based framework for
high integrity sensor networks,” ACM Transactions on Sensor Networks
(TOSN), vol. 4, No. 3, May 2008.
[12] F. Wu, T. Luo, J. C. J. Liang, “A crowdsourced WiFi sensing
system with an endorsement network in smart cities,” 2015 IEEE Tenth
International Conference on Intelligent Sensors, Sensor Networks and
Information Processing (ISSNIP), pp. 1-2, April 2015.
[13] B. Kantarci, H. T. Mouftah, “Trustworthy sensing for public safety
in cloud-centric Internet of Things,” IEEE Internet of Things (IoT)
Journal, pp. 360-368, July 2014.
[14] D. Yang, G. Xue, X. Fang, and J. Tang, “Crowdsourcing to
smartphones: Incentive mechanism design for mobile phone sensing,”
Proc. 18th Int. Conf. Mobile Comput. Netw., pp. 173-184, Aug. 2012.
[15] X. Wang, W. Cheng, P. Mohapatra, and T. Abdelzaher,
“ARTSense: Anonymous reputation and trust in participatory sensing,”
INFOCOM, 2013 Proceedings IEEE, pp. 2517-2525, April 2013.
[16] K. Benouaret, R. Valliyur-Ramalingam, and F. Charoy, “CrowdSC:
Building smart cities with large-scale citizen participation,” IEEE
Internet Computing Journal, vol. 17, Iss. 6, pp. 57-63, 2013.
[17] X. Wang, K. Govindan, and P. Mohapatra, “Collusion-resilient
quality of information evaluation based on information provenance,”
IEEE 8th Communications Society Conference on Sensor, Mesh and Ad
HocCommunications and Networks, 2011.
[18] C. Perera, A. Zaslavsky, P. Christen, and D. Georgakopoulos,
“Sensing as a service model for smart cities supported by Internet of
Things,” Trans. Emerging Telecommun. Technol., vol. 25, no. 1, pp. 81-
93, Jan. 2014.