Towards trusted mobile ad hoc clouds

Towards Trusted Mobile Ad-Hoc Clouds
Ahmed Hammam, Samah Senbel
College of Computing and Information Technology
Arab Academy for Science and Technology and Maritime Transport
Cairo, Egypt
ahmed@hammam.me, senbel@aast.edu
Abstract—Most current cloud provisioning involves a data
center model, in which clusters of machines are dedicated to
running cloud infrastructure software. Ad-hoc mobile clouds, in
which infrastructure software is distributed over resources
harvested from machines already existing and used for other
purposes, are gaining popularity. In this paper, we propose a trust
management system (TMC) for mobile ad-hoc clouds. This system
considers availability, neighbors’ evaluation and response quality
and task completeness in calculating the trust value for a node. The
trust management system is built over PlanetCloud which
introduced the term of ubiquitous computing. EigenTrust algorithm
is used to calculate the reputation trust value for nodes. Finally, a
performance test was executed to prove the efficiency of the
proposed TMC in term of execution time, and detecting node
behavior.
Keywords: Ad-Hoc Clouds, Reputation, Trust management.

I.

INTRODUCTION

Cloud computing introduced a high scalable computing
architecture, that provides everything as a service "XAAS".
This architecture opened the door to new applications and
solutions. Generally, cloud computing is based on the existence
of huge datacenters, which need internet connection to reach its
services. But, there are some applications which require
scalable computing in absence of internet connection, such as
in natural crises, to reach computing resources. That drives to
ad-hoc cloud, where resources are harvested from machines
already in existence within a network. And the increase in
computing power of mobile devices led to the use of mobile
ad-hoc clouds. In this type of architecture, resources are owned
by users who cannot be trusted and may be malicious. To solve
this problem, trust management systems were developed.
A new architecture was introduced that forms ad-hoc
mobile clouds [8, 9]. This architecture is based on a “spatiotemporal” calendering mechanism that automatically adjusts
resources to each cloud. Client agents' calendars is stored in
resource servers “RS” which allows them to pick suitable
members to form clouds. However, cloud agents need to verify
that participants are reliable, available, and not malicious. To
solve this, a reputation trust management system is proposed.
This system will allow cloud agents to select client agents
based on a calculated trust value that reflects its honesty.
To simulate the proposed reputation Trust management
system, the “P2P Trust Simulator” [13] was used to simulate
the transactions between cloud agent and client agents and to
calculate trust values. The next section provides an overview of

the related work in this field of research. In section III, a brief
description of the “PlanetCloud” [8] system is given. In section
IV, the proposed trust system for ad-hoc mobile clouds TMC is
described. Section V describes the system performance test and
displays the results that were obtained, and section VI
concludes this work and provides at a glance a view of the
future work.
II.

RELATED WORK

A. Mobile Cloud Computing
“Mobile Cloud” is an ad-hoc cloud that utilizes the
increase of mobile devices power. A model was introduced for
cloud [7], in which infrastructure software is distributed over
resources harvested from machines already in existence within
an enterprise. In contrast to the data center cloud model that in
which resources dedicated exclusively to the cloud. Ad hoc
cloud allows partial virtualization of non-dedicated hardware
based in distributed voluntary resources.
“Mobile Cloud Computing (MCC)” was defined in
surveys [2, 3] as a composition of mobile technology and cloud
computing infrastructure where data and the related processing
takes place in the cloud and then can be accessed through a
mobile device. Or in which mobile device is being part of the
cloud by voluntarily provides its resource to the cloud
provisioning system.
As a development of SETI@HOME concept a new Cloud
infrastructure Architecture is introduce [4]. In this architecture
Commercial/business and the volunteer/scientific viewpoints
coexist. This infrastructure is able to provide adequate
resources to satisfy user requests also taking into account QoS
requirements. This Architecture was built on resources
voluntarily by their owners or administrators, following a
volunteer computing approach and provided to users through a
cloud-service interface.
PlanetCloud, a new architecture was introduced for forming
ad-hoc mobile clouds. It is designed especially for emergency
and critical situations [8, 9]. We chose this architecture to build
our trust management system on because it has resource
servers (RS) which are distributed servers that are used to store
spatio-temporal calendar and other information. RS can be
used to store trust values for client agents’ to be used by cloud
agents in the cloud formation request. PlanetCloud is described
in more details in the next section.

B. Trust Management System
Mobile ad-hoc networks MANET is a group of mobile
devices that are connected through wireless link. These nodes
are Self-organization which means they are autonomous, with
no fixed infrastructure or centralized administrative node. And
each node can move in any direction independently from other
devices. This network has main three constraints Bandwidth,
Computer power and Battery power. Ad-hoc cloud is built on
resources that are collected from a network. Network in this
case is MANET like in which the physical layer is mapped to
mobile devices “client agents”. The neighborhood
relationships are among these client agents that are in the radio
range. Two Trust management systems for MANET were
proposed in [14, 15]. A comparison between TMC and these
two systems is provided in section IV.
To build an effective Trust management there is a need to
outline various issues involved in the design of reputationbased P2P system [10]. To answer the question of how trust
can be applied in distributed computing [1, 12], an
investigation has been conducted in trust management systems
proposed for cloud computing. The proposed models/systems
have been compared with each other based on a selected set of
cloud computing parameters.
Another Trust Management System architecture was
introduced for cloud computing marketplace [5]. This
architecture reflects the multi-faceted nature of trust
assessment by considering multiple attributes, sources and
roots of trust. It aims at supporting customers to identify
trustworthy services providers as well as trustworthy service
providers to stand out.

III.

PLANETCLOUD IN BRIEF

PlanetCloud [7, 8] is an architecture that was developed to
enable resource provisioning and dynamic “spatio-temporal”
resource calendaring to form ad-hoc cloud. It aims to utilize the
increased number of mobile devices available to provide "ondemand" scalable distributed computing capability, especially
in critical situations. This architecture has three main
components “Client Agent”, “Cloud Agent” and “Resource
Server” (RS). Each of these components will be discussed in
brief:
A. Client Agent
Client agent is the application used by the user who has a
resource which he is willing to share. This application manages
the client spatio-temporal resource calendar: which resource
can be shared and when. It handles incoming requests for cloud
formation, notifies a user of the next incoming clouds, connects
with all other agents involved in the cloud formations, and
synchronizes the calendar’s content with the Resource Server's
data.
B. Cloud Agent
Cloud agent is the application used by the user who wants
to form a cloud. This application is deployed on a high
capability client to manage and store the data related to spatiotemporal calendars for all clients within a cloud. The cloud
agent uses local data repository to store the user profiles, and
spatio-temporal calendars of clients within a cloud. This
application can query data repositories in “RS” for extra
information.

To build a reputation trust management system a reputation
algorithm is required to calculate reputation values. EigenTrust
algorithm had been introduced [6] to be used in P2P networks
to decrease the number of downloads of inauthentic files. It
computes agent trust scores in P2P networks through repeated
and iterative multiplication and aggregation of trust scores
along transitive chains until the trust scores for all agent
members of the P2P community converge to stable values. By
these global reputation values to choose the peers from whom
they download, the network effectively identifies malicious
peers and isolates them from the network.
A decentralized trust management middleware for ad-hoc,
peer-to-peer networks had been introduced [11]. In this middle
ware, reputation information of each peer is stored in its
neighbors and piggy-backed on its replies to requests for data
or services. This middleware relies on the lack of network
structure to manage reputation information in a secure way.
C. Simulator
To conduct the performance test a general-purpose
evaluation framework is used [13]. This framework introduced
to evaluate reputation management for distributed systems,
peer-to-peer (P2P) networks, and ad-hoc mobile computing.
We chose this framework because it was built specially to
evaluate reputation algorithms in P2P and ad-hoc networks.
And it provides a mechanism to plug new algorithms.

Figure 1: PlanetCloud Architecture. [9]
C. Resource Server
Distributed RSs operate on the updated data from clients’
calendars and clouds data, which are stored in a data
repository. The RS provides resource forecasting using an
implemented prediction unit. It has a data store that is used to

store calendars and other information and it has other three sub
components, "Information Bases" where it stores information
about cloud formation requests and users’ information,
"Account manager" which contains billing information and
"Synchronizer" that synchronize data between RSs and users.

the data repository of RSs. Table I contains sample
information. Cloud agent can use these trust values in the next
cloud formation to select the most high trusted client agents.
Other cloud agents can query updated trust values of client
agents from RSs data repository.

Figure 2: Proposed Trust System for mobile ad-hoc cloud
Figure 1 explains
“PlanetCloud”. RSs are
replicated through RSs.
directly communicate to
directly to client agents.
IV.

the high level architecture of
distributed not centralized, data are
Client agents and cloud agents can
RSs. Cloud agent can communicate

PROPOSED TRUST MANAGEMENT SYSTEM FOR AD-HOC
MOBILE CLOUD TMC

A. TMC System Design
The goal of the proposed system is to avoid the
participation of malicious client agents which would affect the
performance of the formed cloud. This is due to the fact that
this system is used in critical situations which require zero
tolerance with malicious behavior.
We propose a trust system for ad-hoc mobile cloud that
evaluates members of a cloud and computes trust value during
its interaction in a cloud. This trust value is stored in the cloud
agent’s local repository then it synchronizes these values with

Because these ad-hoc clouds are made up mainly from
mobile devices, the availability of the client agents is
considered. Also, the neighbors’ evaluation is considered,
because data are transferred from client agents to cloud agents
and vice versa, though a path formed of other client agents.
Malicious client agents cannot evaluate other client agents to
avoid affecting trust values. Moreover, response speed and
completeness of tasks are considered. Finally, the number of
clouds that the client agent participated in is taken in
consideration. After calculating the new trust value of a client
agent, it is stored in the RSs repository to be used in the next
selection process.
The EigenTrust algorithm was used to calculate the trust
value of each client agent during its participation in a cloud.
Figure 2 explains the proposed trust management system. In
the next paragraphs, the system workflow will be described.
If a cloud agent is forming his first cloud it sends requests
to RSs to form new cloud and set its preferences and settings.
RSs query its data store to find the most suitable client agents.

Then RSs send approval request to client agents. If a client
agent sends his approval to RSs, it checks if client agent is
complying with cloud formation settings and preference.
Next, the cloud agent can form his cloud and after a cloud
is formed, cloud agents start to evaluate cloud members and
receive each client’s neighbors’ evaluation to include it in the
final evaluation stored in the local data store, which is then
synchronized with RSs. This evaluation is used to calculate the
average trust value of each client agent to be used in next cloud
formation.
Table I: client agents’ information in RS / Cloud agent store

numbers of pre-Trusted users, good Behaving users and other
values for other malicious behaviors. Then it generates random
values for each node to match its assigned behavior. Then it
calculates number of good and bad transactions.
This simulator works in two steps. In first step, it generates
a trace file that contains nodes and its trust values also this file
contains the transactions between nodes and files this file is
generated based up on the parameters that are passed to trace
generator. In second step the trace file is used as an input for
trace simulator which will apply the reputation algorithm then
it write its output and statistics in a file this steps are shown in
figure 3.

Figure3 : Overview of evaluation architecture [13]
In the subsequent cloud formations, a cloud agent checks if
it can establish a connection to RSs then it will check trust
values for its trusted client agents only in RSs data store. Then
RSs will query the data store to query if the number of clients
to form the cloud is not covered by trusted client from cloud
agents. Then it request approval from client agents before
complete cloud formation request.
If the connection between cloud agent and RSs is not
established, Cloud agent queries its local data store for client
agents. Then it selects the client agents using the same criteria
used by RSs. Then it send approval request to client agents, if a
cloud agent accepts the cloud formation request it sends
confirmation to cloud agent. Then cloud agent forms its cloud
and then the client agent starts to evaluate its neighbor client
agents during its participation in the cloud as previously
described. And then cloud agent synchronizes trust values with
RSs once it can establish a connection with it. In Table II
system messages are listed with brief descriptions.
Message

Table II: System Messages
From
To
Description

Place Cloud
formation Order

Cloud Agent

RS

set cloud settings by cloud agents

Approval Request

Cloud Agent
/ RS

Client
Agent

Asks client agent to join a cloud

Client Agent Accept

Cloud Agent

RS

Client Agent Accepts to join the
cloud

RS Confirm

RS

Cloud
Agent

Confirms that Client agent is
compliant with SLA and other cloud
roles that was set by cloud agent

Send evaluation

Client Agent

Cloud
Agent

Cloud Agent sends its evaluation of
its Neighbors

Synchronize

Cloud Agent

RS

Cloud Agent sends its new evaluation
of client agents and request to update
its local store with new computed
client agents trust values.

B. Simulator
“P2P Trust Simulator” [13] is used to execute performance
tests. It was originally implemented to be fed with fixed

In this simulator, new calculated trust values for nodes are
not used in the next rounds. To use this simulator in the
performance test it is needed use the calculated trust values in
next rounds. Also there is a need to dynamically detect nodes
behavior according its “Honesty” and “Response Quality” as
shown in Table III.
Numbers in Table III are guided by numbers in Table
1[13]. In this table Pre-trusted Client Agents referees to client
agents which are trusted by TMC or by cloud agent. Good
Client Agents are client agents which behave honestly during
the test round. Malicious Client Agents are client agents which
were not performing honestly during the test round. Client
Agent’s behavior is not detected are the agents which TMC
couldn’t categorize them into one of the previous behaviors.
A simulation of RSs behavior is done by storing and
retrieving these values for client agents to be used by cloud
agents. Client agent will be represented by a node and there is e
only one Cloud agent.
Pre-trusted client agents are detected in the start of a round.
The new client agent who didn’t participate in any cloud will
be assigned an initial trust value between 0 and 1, that is less
than a static value called new_trust_value_threshold. The
behavior of the new client agent can be controlled by changing
the new_trust_value_threshold value. Unlike the default “P2P
Trust Simulator” behavior, TMC detects client agents’
behavior from retrieved trust value “Honesty” and responsequality. Refer to Table III.
In Figure 4 explains the changes that had been done in the
simulator. Now it only has two arguments passed to it the
required nodes number and the selection strategy. Node
selection is done using passed selection strategy then selected
nodes are used in the trace simulator step. Then new
calculated trust values are updated. Finally statistics are written
to a file.

Table IV: Comparison between TMC and MANET Trust
Management systems
TMC

Figure 4: Overview of evaluation architecture after
enhancements

Buchegger,
S., et al. [14]

Velloso,
Pedro B., et
al. [15]

Calculation

Pre-trusted Client Agents

90-100%

90-100%

Good Client Agents

90-100%

70-100%

Client Agent’s behavior
is not detected

50-70%
0-50%

0-50%

each node for
every in radio
range

Stored centralized in RSs
and locally in cloud agents

Locally

Locally

Reusability

Reused by the TMC
system to recommend
client agents to cloud
agents

Used during
current network
session

Used during
current network
session

Exchange

between TMC and cloud
agents

between
neighbors nodes
only

between all
nodes in the
radio range

50-70%

Malicious Client Agents

node for
neighbors only

Store

Table III: Values used to detect user's type
User Type
ResponseHonesty%
quality%

Cloud agent for client
agents which participated
in a cloud and every client
agent for its neighbors

To calculate the trust value of a client, last trust (t) and
response-quality (r) values are loaded from database We also
take into consideration neighbor-evaluation (n) and
availability-evaluation (a) based on the user’s behavior.
100,000 transactions are generated to be used in the simulation
to calculate trust value(t). However, these values cannot exceed
the new_trust_value_threshold specified for a new member.
These values n, r and a are used in an Equation 1 to
calculate the final trust (t) value which is stored in RSs.

t = (0.3 × t ) + (0.1 × n ) + (0.2 × r ) + (0.4 × a )

(1)

We chose these weights for each element to reflect its
importance. The availability is the highest importance because
it is what makes the deference in mobile environment. The
second in its importance is the computed trust value that is
based on behavior of the client agent. The third in its
importance is response-quality based on response speed and
assigned task completeness, then finally neighbor-evaluation.
RSs client agent selection process is simulated, by ordering
client agents using their Honesty value, response-quality and
number of participation in the clouds. Then select from lists top
the number of client agents requested by cloud agent.
C. Comparison between TMC and Existing Trust
Management Systems for MANET
There exists number of trust management systems were
built for MANET. In the next table a comparison between
TMC and two trust management systems were built for
MANET. Table IV compares between TMC and trust
management systems [14, 15] in term of trust values
calculation, trust values store, trust values reusability, and trust
values exchange.

V.

SYSTEM PERFORMANCE TEST

In this section, we simulate the behavior of TMC and
compare its results with plain PlanetCloud. We conduct a
performance tests. We used two versions of EigenTrust first
one EigenTrust-1 is as it was described in [6] while the second
version EigenTrust-2 uses snapshot comparisons to avoid
costly recalculation on every cycle.
In the performance test, the simulator was run using the
proposed system TMC 10 test rounds with each EigenTrust
version. Then the simulator was run another 10 test rounds
with plain PlanetCloud, under the same conditions. Then, the
three results are compared. The comparison is done between
the numbers of pre-trusted client agents, good behaving client
agents, malicious client agents and unknown behavior client
agents and between the execution times.
Pre-trusted client agents are trusted by the system before it
entered a round. Good behaving client agents are the agents
that have good behavior during a round. Malicious client
agents are the agents that have malicious behavior during the
round. Unknown behaving client agents are the agents that
system couldn’t categorize them into one of the previous
behaviors.
In each experiment there is a set of 1000 client agents to
select 100 clients out of them to form a cloud. Number of
performed transactions in each experiment is 100,000. In the
Performance Tests a machine that has Intel core I5 processor
and 8 GB RAM was used.
A. Performance Test
In this performance test, the new_trust_value_threshold
was set to be 0.7 which is near to the good type range Table III.
There is a set of 1000 client agents to choose 100 client agents
out of them. Number of transaction used was 100,000.
Figure 5 shows that the execution times of the ten rounds
with and without using TMC are very close, with the TMC
EigenTrust-1 system giving an enhancement of about 25%
while TMC EigenTrust-2 it gives around 40%. Figure 6 shows
that the number of pre-trusted client agents that entered the ten
rounds using TMC with the two EigenTrust versions are

increased from round to round more that those entered the
rounds without TMC. Also the total number of them using
TMC is more than it without using TMC. Figure 7 shows that,
the number of the good behaving client agents in each round
with using TMC is more than that number without using TMC.
Figures 8 and 9 show that TMC using the two versions of
EigenTrust detects and eliminates malicious and unknownbehavior client agents and that improves round after round.
We can conclude from these experiments that adding the trust
system to the existing PlanetCloud system will not only
improve the performance of the system, but will also provide a
reliable repository of client trust values which is useful in
assigning future cloud groups.
Figure 7: good behaving client agents.

Figure 5: execution Time comparison.

Figure 6: Pre-Trusted client agents.

Figure 8: malicious client agents.

Figure 9: Unknown Behaving client agents.
Finally based on this performance test state that TMC
enhance the performance of the PlanetCloud in term of
numbers of Pre-trusted Client Agents, good behaving client
agents, Malicious Client Agents and Client Agents with
unknown behavior. This will reflect positively on the cloud
performance, and was experimentally proven to be at least
20%.

VI.

CONCLUSION AND FURTURE WORK

The proposed system monitors the client agents’ behaviors
that join the ad-hoc clouds in the “PlanetCloud” to provide
better results for cloud agents by providing them by trusted
Client agents. Centralized store for this information may set
some limitation on forming new ad-hoc cloud, but already
cloud agents and client agents need to access RSs frequently to
read or update spatio-temporal calendar. And also cloud agents
have a local repository which can be used in cases that RSs are
not reachable. Scalability of PlanetCloud will not be affected
because Cloud agents just need to connect to RS in the
selection phase of client agents. RS are not interfered during
cloud sessions and cloud agents need only to synchronize its
new calculated values when it is possible. And it is possible for
cloud agents to depend on their local data store if they cannot
connect to RS.
We have shown that the number of good behaving client
agents and pre-trusted client agents is enhanced from one
round to the next. And on the long run large numbers of good
behaving, pre-trusted and bad behaving agents will be
identified and recorded in the RSs what will help cloud agents
to safely form clouds in low time cost especially in crises and
emergency situations.
Although EigenTrust algorithm is being used for many
years but it was chosen because its behavior is guaranteed and
well tested. But other algorithms like PowerTrust [16] and
PeerTrust [17] algorithms will be used in future work to
compare their results with EigenTrust results. Neighbors
evaluation is not covered in this paper and will be another point
to be covered in the future work.
REFERENCES
[1]

[2]

[3]

[4]
[5]

[6]

[7]
[8]

[9]

Firdhous, Mohamed, Osman Ghazali, and Suhaidi Hassan. "Trust
Management in Cloud Computing: A Critical Review." arXiv preprint
arXiv:1211.3979 (2012).
Fernando, Niroshinie, Seng W. Loke, and Wenny Rahayu. "Mobile
cloud computing: A survey." Future Generation Computer
Systems (2012).
Dinh, Hoang T., et al. "A survey of mobile cloud computing:
architecture, applications, and approaches." Wireless Communications
and Mobile Computing (2011).
Distefano, Salvatore, and Antonio Puliafito. "Cloud@ Home: Toward a
Volunteer Cloud." IT Professional 14.1 (2012): 27-31.
Habib, Sheikh Mahbub, Sebastian Ries, and Max Muhlhauser. "Towards
a trust management system for cloud computing." Trust, Security and
Privacy in Computing and Communications (TrustCom), 2011 IEEE
10th International Conference on. IEEE, 2011.
Kamvar, Sepandar D., Mario T. Schlosser, and Hector Garcia-Molina.
"The eigentrust algorithm for reputation management in p2p networks."
Proceedings of the 12th international conference on World Wide Web.
ACM, 2003.
Kirby, Graham, et al. "An approach to ad hoc cloud computing." arXiv
preprint arXiv:1002.4738 (2010).
Khalifa, Ahmed, and M. Eltoweissy. "A global resource positioning
system for ubiquitous clouds." Innovations in Information Technology
(IIT), 2012 International Conference on. IEEE, 2012.
Khalifa, Ahmed, Riham Hassan, and Mohamed Eltoweissy. "Towards
Ubiquitous Computing Clouds." FUTURE COMPUTING 2011, The
Third International Conference on Future Computational Technologies
and Applications. 2011.

[10] Maini, Siddharth. "A Survey Study on Reputation-Based Trust
Management in P2P Networks." Reputation-based P2P Survey (2006):
1.
[11] Repantis, Thomas, and Vana Kalogeraki. "Decentralized trust
management for ad-hoc peer-to-peer networks." Proceedings of the 4th
international workshop on Middleware for Pervasive and Ad-Hoc
Computing (MPAC 2006). ACM, 2006.
[12] Ruohomaa, Sini, Lea Kutvonen, and Eleni Koutrouli. "Reputation
management survey." Availability, Reliability and Security, 2007.
ARES 2007. The Second International Conference on. IEEE, 2007.
[13] West, Andrew G., et al. "An evaluation framework for reputation
management systems." (2009).
[14] Buchegger, S., Le Boudec, J.-Y. “A Robust Reputation System for
Mobile ad hoc Networks. Technical Report.” IC/2003/50, EPFL-DIICA, (2003).
[15] Velloso, Pedro B., et al. "Trust management in mobile ad hoc networks
using a scalable maturity-based model." Network and Service
Management, IEEE Transactions on 7.3 (2010): 172-185.
[16] Rahbar, A. G. P., and O. Yang. "Powertrust: A robust and scalable
reputation system for trusted peer-to-peer computing." Parallel and
Distributed Systems, IEEE Transactions on 18.4 (2007): 460-473.
[17] Xiong, Li, and Ling Liu. "Peertrust: Supporting reputation-based trust
for peer-to-peer electronic communities." Knowledge and Data
Engineering, IEEE Transactions on 16.7 (2004): 843-857.

Towards trusted mobile ad hoc clouds

More Related Content

What's hot (18)

Viewers also liked (14)

Similar to Towards trusted mobile ad hoc clouds (20)

Recently uploaded (20)

Towards trusted mobile ad hoc clouds