Trust Models for Efficient Communication in
Mobile Cloud Computing
Florin Pop, Oana-Maria Citoteanu, Ciprian Dobre, Valentin Cristea, Mocanu Bogdan
Computer Science Department, University Politehnica of Bucharest, Romania
Emails: florin.pop@cs.pub.ro, citoteanu.oana@gmail.com, ciprian.dobre@cs.pub.ro, valentin.cristea@cs.pub.ro, mocanu.bogdan.costel@gm
Abstract—Aici pun abstractul meu
Taking in consideration the large amount of data processed
by distributed systems formed by servers and mobile devices,
managing such large dimension of data has become a very
challenging issue with high impact on the end-user. Therefore,
the management process of such systems can be achieved in an
efficient way by using uniform overlay networks interconnected
through secure and efficient routing protocols. The aim of this
paper is to continue the research presented in the Trust Models
for Efficient Communication in Mobile Cloud Computing paper
with new models of network overlays, written in UPB.
de aici trebuie modificata idea
This paper describes a new model for resource trust manage-
ment in Mobile Cloud systems. It uses a bio-inspired structure
for constructing the overlay in a honeycomb structure. Then
we introduce a model for resource trust management based on
feedback, which is very similar to peer-to-peer trust management
systems like EigenTrust, R2Trust, SuperTrust or TrustMe. Based
on overlay construction and trust value computation, we propose
a general flow for a resource request in Mobile Cloud systems
logically organized as a honeycomb structure. We evaluate the
proposed solution using simulation and the obtained results
highlights the performance of proposed auto-adaptive overlay
that can be use as a content distribution platform in Mobile
Cloud systems.
Index Terms—Resource Management; Overlay Networks; Ef-
ficient Communication; Trust Management; Mobile Cloud; Peer-
to-Peer Systems
I. I NTRODUCTION
The emerging number of mobile devices in the recent
years and the highly developed computing infrastructure called
Cloud Computing has determined a new very interesting and
challenging domain in the field of research in Computer
Science called Mobile Cloud Computing (MCC). MCC bring
together cloud computing with the mobility offered by the
mobile devices such phones, tablets, laptops and many others.
The most important challenges of MCC are concerning the
performance through battery life of bandwidth, the environ-
ment and security. Due to the fact that the number of users
for this kind of services is increasing exponentially new
business has arrived. The application markets offers the end
users services in Mobile Commerce, Mobile Learning, Mobile
Health-care and Mobile Gaming.
A Mobile Peer-to-Peer Networks is a group of devices that
communicate to each other in a decentralized way via wireless
communication technologies like IEEE 802.11, Bluetooth or
Ultra Wide Band.
The structure of the overlay network has a bio-inspired
topology, a honeycomb. This model has been chosen because it
offers a fixed structure that can scale really well and support a
big number of users and it is auto-adaptive. Another objective
is to find an efficient way of forming the honeycomb structure
and to study how well it behaves when content is distributed
[19]. Another objective is to find a way of computing and
storing the trust values of active users in a network, and to
see how these values evolve according to the behavior of the
users that joined a mobile network.
Mobile Cloud systems are characterized by availability,
massive scalability, robustness and flexibility. They are highly
adaptive, capable of self-organization and can offer load
balancing and fault tolerance. Some of their features are:
efficient data search, redundant storage, hierarchical naming,
anonymity, trust and authentication. Because the nodes inside
a mobile network system can join the system and leave at any
moment without announcing their exit, the structure on which
the system is build has to be able to respond in a quick and
efficient manner to these changes.
In the past years there has been a growing interest in
the scientific community for human-operated handheld de-
vices. Unfortunately, even though battery technology has been
steadily improving, it has not been able to keep up with
the rapid growth of power consumption of mobile systems.
Mobile Cloud Computing (MCC) tries to extend the battery
life by offloading the execution of power-hungry tasks onto
clouds. An Auto-Adaptive Overlay Network for MCC, using
opportunistic sharing of computing resources, can solve such
problems, by opportunistically spreading tasks in the network
of devices. Previous experiments on human mobility and social
interaction, using Bluetooth, WiFi, ZigBee and other small-
and medium-range wireless communication protocols for co-
location tracking, show the feasibility of establishing oppor-
tunistic connections with mobile devices in close proximity
[22]. A first step in this direction has been taken at UPB.
HYCCUPS is a preliminary platform developed at UPB to
evaluate the feasibility of resource sharing in case of co-
located smartphones [23]. It focuses on reducing the overall
consumed power of the interconnected devices. The main
differentiating factor from other platforms is that the offloading
decision is taken considering both mobility and availability
of a node to offload a task, and not neglecting the overall
quality of experience of the users which are part of the cloud.
We primarily use the reduction of overall execution time
for mobile applications, reduction in power consumption, the
increase in robustness in case of failures, the enhance for user
experience, and uncertain sensor data as measure of progress.
The research in this paper is a new step towards optimization
of HYCCUPS’s running engine.
The paper has the following structure. Section 2 presents
the structure of auto-adaptive honeycomb overlay network by
presenting its role for Mobile Cloud, the network topology,
the routing algorithm and the overlay construction. Section 3
presents the resource trust management considering decentral-
ized approach and describes the trust solution for honeycomb
structure. The general flow for a resource request is also
described in Section 3. Section 4 presents the experimental
results that are split into two categories: overlay construction
and trust computation. Section 5 presents conclusion, future
work an a short case study about cases in which several users
are disconnected from the system, and the honeycomb ends up
being split in different parts. Related work and similar projects
and examples are presented in all sections.
II. R ELATED W ORK
In this section it will be presented a dig into the reputation
trust management in decentralized Peer-to-Peer networks.
A good overview regarding reputation on Peer-to-Peer sys-
tems has been created by the authors of [4]. In this paper it is
presented a useful taxonomy of Peer-to-Peer reputation models
composed by gathering of information, ranking the peers and
rewarding the peers.
Having a good trust metric based on Social-Networks is a
major challenge because of the reputation ranking depends on
the peers social position. Therefore, the most dangerous peers
are the front ones. In paper [1], the authors proposed a better
approach entitled Poisonwater for Social-Network based trust
metrics that is resistant to front peers attack than Eigentrust
and Powertrust. In comparison the Poisonwater can mitigate
front peers attack by 20
Another interesting approach regarding building good trust
relationships in decentralized Peer-to-Peer systems is pre-
sented in paper [2], where the authors proposed new model of
trust based on Reputation and Risk evaluation. This model
is suitable for defending against simple malicious attacks,
collusive attacks and strategic attacks.
In paper [3] is presented a new trust model that extends the
D-S theory, that improves the filtering of false recommenda-
tions and the dynamic adaptive to strategic behaviors.
Reputation management in Peer-to-Peer networks based on
Distributed Hash Tables (DHT) is the main idea of paper [5].
The authors of this article proposed an algorithm that permits
the peers in the network to get individual ranking values for
each node based on knowledge exchange.
Due to the high increase of the mobile devices in the
market, an important category of decentralized systems can
be considered the Mobile Peer-to-Peer networks. Creating
trust and manage reputation in this kind of networks is a
great challenge. Therefore the authors of [6] realized a brief
Fig. 1. Node coordinates
overview of four trust management schemes for Mobile Peer-
to-Peer systems and further proposed a new reputation trust
management schema entitled M-trust.
Concerning the hybrid Peer-to-Peer networks, the authors
of [7] suggested a Super-peer trust model called SuperTrust
that determines the peers to cooperate based on the common
interests. Therefore, peers that share less things in common
with others are likely to interact with others more frequently.
This model can handle with success several attacks like SM,
DM and CM attack.
III. SECTIUNEA 3
A. Routing Algorithm in Overlay Network
The honeycomb is formed inside a three-axis system: Ox,
Oy and Oz. Each node is assigned a unique coordinate in
the system. The coordinates change by following the edges
parallel to the respective axis.
For example, if from the current node, defined by (u, v, w),
we move on an axis parallel with Ox, the neighboring node
will have the same coordinate on Oy and Oz, and the Ox
coordinate will be changed by 1, depending on the direction.
If the vector formed by joining the initial node with the second
one has the same direction as Ox, then the x coordinate
will be incremented, giving the new position (u + 1, v, w).
If it is pointed in the opposite direction, the value must be
decremented (u − 1, v, w).
Figure 3 contains the coordinates of the nodes from the first
2 chains of the honeycomb structure.
Let (u1 , v1 , w1 ) and (u2 , v2 , w2 ) be two nodes of the system
and ∆x = u2 − u1 , ∆y = v2 − v1 and ∆z = w2 − w1 . Then,
the shortest path between the nodes will be given by |∆x|
edges parallel to Ox, |∆y| edges parallel to Oy and |∆y|
edges parallel to Oz. When routing a message, the distance
on each axis between the nodes must be shortened. First, the
Ox coordinates will be compared, and, if the values differ, and
there is a path that will shorten the distance, the message will

Fig. 2. Route messages
be routed through there. If either of the previous conditions
isn’t met, the Oy coordinate will be checked, and lastly, the
Oz coordinates.
Thus, a message sent between nodes A(4, −2, 0) and
B(1, −1, 1) will pass through the following nodes, in this
order: (4, −2, 0) → (3, −2, 0) → (3, −1, 0) → (2, −1, 0) →
(2, −1, 1) → (1, −1, 1).
A message from A(4, −2, 0) to C(3, 2, −3) will have the
following path: (4, −2, 0) → (3, −2, 0) → (3, −1, 0) →
(3, −1, −1) → (3, 0, −1) → (3, 0, −2) → (3, 1, −2) →
(3, 1, −3) → (3, 2, −2).
The path sent between two nodes can differ depending on
the direction. For example, a message between C (3,2,-3) and
A (4,-2,0) will pass through the following nodes: (3, 2, −3) →
(3, 1, −3) → (4, 1, −3) → (4, 0, −3) → (4, 0, −2) →
(4, −1, −2) → (4, −1, −1) → (4, −2, −1) → (4, −2, 0).
These paths are marked in Figure 4 with arrows.
B. Overlay Network Construction
Solution for overlay network construction is similar to
approach presented in [3] for peer-to-peer networks. The
authors describe a way of constructing a honeycomb overlay
by splitting the nodes of a chain into 2 different layers,
called rings. Each node of the system is uniquely identified
by computing a general index constructed from the values of
the chain, ring and index within each ring. The indexes from
the interior chains are assigned so that they are identical to the
ones from the exterior ring of the previous chain. Each new
node is added inside a chain in a clock-wise direction, until
this is completed, and then the next chain is formed.
A new construction method is proposed in this paper. It
makes use of the chains of the honeycomb, the indexes
within each chain, which are set in a clockwise direction and
the coordinates from the three-axis system. The connection
algorithm is constructed by using the lemma given in [4]:
nodes of a honeycomb of size k can be coded by integer triples
(u, v, w), such that k+1 ≤ u, v, w ≤ k and 1 ≤ u+v+w ≤ 2.
Two nodes (u1 , v1 , w1 ), and (u2 , v2 , w2 ) are connected by
an edge if: |u2 − u1 | + |v2 − v1 | + |w2 − w1 | = 1. The
coordinates of the neighbors of any node can be obtained by
traveling across edges: (±1, 0, 0), (0, ±1, 0) and (0, 0, ±1).
Considering a node (u, v, w), we can compute a list of possible
coordinates for its neighbors: (u + 1, v, w), (u, v + 1, w),
(u, v, w + 1), (u − 1, v, w), (u, v − 1, w), (u, v, w − 1).
Out of these six triplets, only three define real neighbors.
The correct coordinates are the ones that respect the relation
1 ≤ u + v + w ≤ 2.
All the nodes of the honeycomb are divided into two
categories: white and black. They are placed so that any
edge will connect two nodes of different color. If a node is
white, then all its neighbors will be black. Considering a black
node, the vectors that connect it to his white neighbors are:
x+ = (1, 0, 0), y + = (0, 1, 0) and z + = (0, 0, 1). And the
ones connecting a white node to black ones: x− = (−1, 0, 0),
y − = (0, −1, 0) and z − = (0, 0, −1). If a white node has
the following coordinates (u, v, w), then its neighbors are:
(u − 1, v, w), (u, v − 1, w) and (u, v, w − 1) (Eq.4). The
neighbors of a black node are: (u + 1, v, w), (u, v + 1, w)
and (u, v, w + 1) (Eq.5).
The nodes are connected as follows. The first chain of the
system is C0 . Each new node is added on the current chain, in
clock-wise direction until the chain is completed. The index
of the first node on each chain is 0. The last value depends
on the total number of nodes of the chain (see Eq.3).
The first node of the chain is placed on the Ox axis. It
takes on the role of a SuperNode (SN) and is responsible with
computing the node’s coordinates inside his chain.
IV. R ESOURCE T RUST M ANAGEMENT
Mobile Cloud systems are currently widely known and used
for sharing information: audio, video, images, binary files
or simple text files using different Clouds. They also have
been used in e-commerce applications like: e-Bay, Amazon,
Yahoo!Auction or Edeal.
According to [5], there is no universally accepted definition
for trust in computer science. In [6], it is defined as “The
belief the trusting agent has in the trusted agent’s willingness
and capability to deliver a mutually agreed service in a given
context and in a given time slot”. Solution from [5] offers
the following definition “the belief that an entity is capable
of acting reliably, dependably, and securely in a particular
case”.
In [6] we can also find the definition of reputation: “an
aggregation of the recommendations from all of the third-party
recommendations agents and their first, second and third hand
opinions as well as the trustworthiness of the recommendation
agent in giving correct recommendations to the trusting agent
about the quality of the trusted agent”.
The trust value is asymmetric, transitive and dynamic. It
is complex because there are many ways of computing its
value: as local or global, based on a single transaction or
on the history of the node’s interactions. It is asymmetric
because the trusting node assigns its value to the trusted node
based on its previous behavior. This means that the value is

Fig. 3. Relationship model
computed for each node, it doesn’t describe the relationship
between the two nodes. The following scenario describes the
transitivity property: if we have three nodes A, B and C for
which A trusts B and B trusts C, then A will trust C by a
value computed based on its trust for B and B’s trust for C.
Trust is considered to be dynamic because its value is changed
based on every transaction made, so that if a node starts to
send corrupted information, its trust value can be lowered. In
[7] the relationship between trust and reputation is described,
and a computation model is presented in which the trust is
mathematically computed based on the cooperative actions of
a node towards another in a given context (see Figure 5).
Reputation is defined as perception formed through past
actions about the intentions and norms of a node. And trust
as a subjective expectation that a node has towards another,
based on the previous behavior and history. The flow of the
system is the following: an exchange takes place based on the
trust value. After it is completed, the reputation is updated and
the trust value recomputed and so on.
A. Decentralized Systems
This type of systems uses several users within the system
to store, compute and serve the trust values of other users.
Usually the users are required to give feedback after each
transaction. The algorithms for computing the actual trust
value are much more complex than in the systems previously
mentioned. Since the identity of the users that hold the trust
value is unknown, each system offers a way of initially as-
signing these holders, and ways to route the messages through
the system, so that the values can be properly updated. Some
examples of decentralized trust management systems are:
EigenTrust [12], R2Trust [20], SuperTrust [13] and TrustMe
[21]. Overview. Usually, when a new user joins the system,
a few users are assigned with keeping track of his behavior.
One of the most important rules there are, is that the user itself
cannot compute own trust value. Another is that there is no
way of making sure that all of the users that respond to the trust
value request are not malicious. This means that when a user
needs to interact with another, it is best to consider multiple
responses, and to filter the ones that look like anomalies.
The EigenTrust algorithm [12] has been developed for a
distributed file sharing system over peer-to-peer system. After
each transaction takes place, it is rated so that the trust values
can be updated. A user is considered malicious, and his trust
value is decreased if it doesn’t send the requested data, or if
the data it sends is corrupt or fake.
The system follows five design concepts. It is self-policing,
which means the users themselves enforce the shared ethics,
and not a centralized system. Each per is assigned an opaque
identifier so that it can remain anonymous. The status of
newcomers is lower than that of peers that have displayed
good behavior. This is needed so that malicious peers won’t
be encouraged to simply create a new identity when their trust
value becomes too low. A minimal overhead is introduced by
the messages passed inside the system. The system’s security
takes into consideration the existence of colluding peers.
There is two types of trust values that are computed: a
local one and a global one. The former is computed based
on the direct interaction a peer has with others. And the latter
is based on the local values assigned to the peer by others.
Each feedback is weighted based on the global reputation of
the peer that gave the value. The pseudo code of the algorithm
used to compute the reputation by EigenTrust [12] is described
below.
The managers that compute and store the trust values use
a distributed hash table (DHT). The unique ID of the peer
(consisting of the IP address and port) is hashed in order to
assign a peer its managers. The peers know the hash function,
so all the peers in the system know who the managers of a
certain peer are. The algorithm for computing the global trust
value converges fast. Less than 10 exchanges of updated trust
values are needed.
In order not to flood the trusted peers with requests, since
they would be chosen every time, the peers with which to
interact with are chosen based on probability. This is also
necessary in order to allow the newcomers of the system
to increase their trust values. The set of peers which have
downloaded files from peer i is Ai , and the ones from which
peer i has downloaded files is Bi .
• cij is the normalized local reputation value;
• tik represents the trust that peer i places in peer k;
• pi is a pre-trusted peer.
Each peer i from the system has to execute the following
steps:
1: Query all peers j ∈ Ai for t0j = pj ;
2: while δ <  do
(k+1) (k) (k)
3: Compute ti = (1 − a)(c1i t1 + c2i t2 + . . . +
(k)
cni tn ) + api ;
(k+1)
4: Send cij ti to all peers j ∈ Bi ;
(k+1) (k)
5: Compute δ = |ti − ti |;
(k+1)
6: Wait for all peers j ∈ Ai to return cij ti ;
7: end while
The main objective of SuperTrust system is to protect the
security of peers and that of the trust values. The feedback
given is not decrypted when the peers rate the transactions, or
when the results are aggregated [13]. The anonymity of the
peers remains hidden even in the case in which the feedback is
revealed. This is important so that the malicious peers cannot
launch attacks on the peers that reported low trust values for
them.
Another important issue that is treated is that the given
feedback cannot be modified or deleted.
 For a feedback to be considered valid, the peer has to prove
that a transaction took place. And at most one feedback is
allowed for each transaction. In order to decrease the load on
the Super Peers (SPs) and to tolerate more failures, the system
is implemented as a K-redundant network. Each peer has a set
of n SNs that collect his feedback and aggregate the results
that other peers give about him.
The general flow is presented below:
1) Peer v sends a request for resource r to his SP;
2) The local SP forwards the request to neighboring SPs;
3) If a SP knows one of his peers has the resource, it
forwards this information to v along with the decrypted
trust value of that peer;
4) After receiving a sufficient number of responses, v
chooses the peer with the biggest trust value u;
5) After the transaction ends, v encrypts his feedback about
u and sends it to his SP;
6) When the SP receives the feedback, it forwards the
encrypted vote to its neighboring SPs;
7) The global trust value is updated without decrypting the
intermediate reports.
In order to be able to update the trust values, an encryption
function that allows computations with encrypted values is
used. All of the n SPs that are responsible for a peer share the
same decryption key. In order to make sure a single feedback
is considered for each transaction, when the peer submits its
vote, it attaches a time stamp to the message. All feedback are
considered invalid after a set period of time ∆t passes. The
messages are kept in a queue for that period of time, and when
the new trust value is computed, only the first is considered,
making it impossible to rate the same transaction twice.
Applicability to Honeycomb Overlay Network. The fixed
structure of the honeycomb allows efficient message routing
and assigning coordinates to nodes so that their anonymity can
be protected. By routing the messages to direct neighbors, only
these know the IPs of the nodes, which increases the system’s
security, and reduces the probability of attacks from malicious
nodes.
It also permits the choosing of managers, so that all the
nodes can compute their position within the system. This is
very important in order to reduce the number of messages
that are routed through the system, since the nodes can only
communicate only through direct neighbors. The managers can
be protected from malicious nodes by assigning them so that
they aren’t directly connected to the nodes whose trust values
they store and compute.
B. Proposed Model for the Honeycomb Overlay
When a new node joins the system, it receives a set of
coordinates. All the messages that are sent through the system
are routed based on these coordinates. This increases the
system’s security, since the only nodes who know the IP
addresses of others are the direct neighbors. But it has a down
point: nodes need to route messages that aren’t related to their
requests. The total number of routed messages needs to be kept
as little as possible so that nodes aren’t loaded with messages
that won’t bring them direct value. This requires employing
a routing algorithm that offers the shortest path between 2
nodes, when routing the messages.
The node that made the request for a certain resource rates
each interaction. It sends its feedback to the manager nodes
(MP) of the one, which replied with the resource. The feedback
is given based on the time interval in which the request is
completed, and on the validity of the data received. If the
received data is corrupted in any way, the lowest possible
trust value is given. By considering the response time for
the message in which a node announces it has the resource,
and the number of hops between the nodes, the trust value is
computed. If the distance is short, then the time interval in
which the transaction is expected to take place is smaller. If
the distance is bigger, the time interval is longer. If the node
sends the needed resource in a shorter or equal time to the
minimum computed time interval, then the trust value is the
biggest allowed. As more time passes over the computed limit,
the trust value decreases.
Trust Value. A simple way of computing the trust value
of a node is given in [14] where a solution for peer-to-
peer trust management is described. The new value is based
on the feedback received for the last transaction, but it
also takes into account all the feedback values previously
received: [T V new ] = [T V old ] + 1 (Eq.6) and {T V new } =
([T V old ]{T V }old + F )/[T V new ] (Eq.7), where the [T V ]
represents the number of feedback received for the node. The
feedback value is F , and {T V new } is the new trust value.
This way of computing the trust doesn’t account very well
for traitor nodes. After behaving correctly for a certain period
of time, they are able to make a large number of transactions
before their trust value is considerably lowered, as is shown in
the experimental results section of this paper. A new model is
proposed, that doesn’t depend on the number of transactions
that took place. It takes into consideration the current trust
value of the node that is based on the previously received
feedback, the current feedback value and the trust value of
the node that rated the transaction.
TYnew = αTYold + (1 − α)[TX F + (1 − TX )TYold ](Eq.8)
where:
new
• TY is the new trust value of the node;
old
• TY is the old trust value of the node;
• TX is the trust value of the node that gave the feedback;
• F is the feedback value.
All values are bound in the interval [0, 1]. The feedback
value is computed by taking into account the validity of the
data that has been sent and the time it took to fulfill the request.
If the file is corrupt (the checksum is wrong), then the feedback
value will be 0. Otherwise, the value will be computed based
on the time it took from the moment the initial request for the
resource has been made and the response that the node can
share it has been received. The general flow for a resource
request is described below.
 1) node A broadcasts a request for resource R;
2) All the available peers respond to A by sending their
coordinates;
3) For each response (ordered by response time), A will
send queries to 3 of the closest MNs to check the trust
value of the peers;
4) The MNs respond to the query with the trust value;
5) When A finds a peer B with an acceptable trust value,
it makes a resource request;
6) After the transaction is finished, A sends the feedback
to the 3 managers of B;
7) The initial MNs send the feedback value to the others;
8) All MNs update their values.
By requesting the trust values only from the closest man-
agers, the values reach faster, and fewer messages are sent
through the system. It also prevents the feedbacks to be
routed through the peer whose trust value was requested. This
increases the security and restricts the attacks of malicious
peers.
All the messages are routed through the system by following
the shortest path between the peers. The exception is repre-
sented by the messages that are routed from the first 3 MNs to
the other ones. These messages are routed so that the feedback
never crosses through the peer about whom the feedback is
given.
The trust managers are chosen when a peer joins the
system. Because the peers are assigned on each chain until
it is completed, this means that not all the managers can
be assigned from the beginning. As a new peer connects to
the system, it computes the peers from whom it should be
responsible, and queries the existent managers for the trust
values.
In order to minimize the number of sent messages, the only
broadcast message that can be sent is that for resource request.
To further optimize the system, the first request can be sent
only n hops through the system. If no answer is received, or
if the trust values of the peers that have the resource are too
small, the distance is doubled.
V. E XPERIMENTAL R ESULTS
The experimental results are split into two categories. First,
a way on how peers can connect to the system is shown, and
then the adaptive method on how the trust can be computed
will be presented.
A. Overlay Construction
For the construction of the overlay, two cases are taken
into consideration. When a new node wants to connect to
the system, it must first send the join message to the connect
node. This can be chosen from a random node that has already
connected to the system, or it can choose to connect to one
of the SNs.
Figure 6 shows the number of messages that are sent within
the system, in the worst-case scenario, until the new node finds
its own position within the honeycomb system. The number
of messages that are sent when choosing to connect to a SP is
Fig. 4. Adaptive trust - false feedback
Fig. 5. Adaptive trust false feedback
considerably lower than when connecting to a random node.
When connecting the first 600 nodes (the 10th chain), the
maximum number for messages sent in the first case is 9,
while in the second are 31.
B. Trust Management
Both methods for the trust management are shown below.
Two main scenarios will be considered: when a node first
connects to the system, and how a node behaves after a period
of time.
Adaptive Trust. Multiple values for α from (Eq.8) have been
considered. The first value considered is 7/8. This has been
chosen because it is the default value for computing the RTT
value for sending TCP packets [15].
The 7/8 value influences the trust values the least. When
a node first connects to the system, only after 7 transactions,
his value will be greater than 8. The 5/8 value requires only
2 transactions for the trust value to reach 8. For 3/4, it takes
4. The values for the malicious nodes can be seen as being
symmetrical.
The 3/4 value seems as the best choice for when a node first
joins the system. The correct nodes can gain a good trust value
in a relatively short period of time, and the malicious ones are
detected early. The 5/8 value hasn’t been chosen because if a
node receives a false feedback, then his trust value is lowered
too much. In order to gain a better perspective over how a
false feedback can influence a node, the following case has
been considered. The trust values for the nodes that give the
feedback are in the interval [0.87; 0.95]. The feedback values
range from [0.83; 0.95]. The initial trust of the node is 0.85.
The false feedback is given for the 3rd transaction and its
value is 0.3.
The blue series in Figure 7 contains the trust values for the
real feedback. The green one is for the false feedback and the
value α = 7/8 and the red one for α = 3/4. As it can be
seen, the trust value drops too much, from 0.85 to 0.74 in the
case of the false feedback for α = 3/4. So, in order for the
good nodes not to be easily influenced by malicious ones, the
α = 7/8 value is has been chosen.
VI. C ONCLUSION
This paper describes a basic solution for auto-adaptive
overlay network user for recourse trust management in Mobile
Cloud Computing. It can be extended to offer better security
mechanisms and to be fault tolerant. For the construction
of the auto-adaptive honeycomb overlay network for Mobile
Cloud users, two scenarios have been presented. Both have
advantages and disadvantages. If a new node connects to the
system by using a random node from the system, then the
number of messages that are sent is significantly greater but
the security is better since everybody doesn’t know the real
address of the Super Nodes. But, if a new Super Node were
attacked, it would only have impact over how new nodes are
added inside the system, and only for the last chosen Super
Node. So, if the information about which node has been added
to the system last is saved on other Super Nodes, then it
would only delay the new connections until a new Super
Node can take the place of the one that has been attacked.
We can conclude that it is preferred for the new nodes to be
able to connect to the existent Super Nodes. Two methods
for computing the new trust values for nodes have been
considered. The first one that takes into account the feedback
received for a transaction and the number of transactions and
a second one that considers the feedback value and the trust
value of the node that gave it. For the latter, multiple values
for have been considered in order to manage the impact
of the new feedback. Based on the experimental results, the
proposed model (Eq.8) with the value for =78 gives the best
results. The number of transactions doesn’t influence it, so the
system is protected against traitor nodes. In the current form
of proposed solution, the malicious nodes can take advantage
of the fact that when giving feedback; no proof for the fact
that the transaction took place is given.
ACKNOWLEDGMENT
The research presented in this paper is supported by
projects: CyberWater grant of the Romanian National Author-
ity for Scientific Research, CNDI-UEFISCDI, project number
47/2012 and SideSTEP - Scheduling Methods for Dynamic
Distributed Systems: a self-* approach, (PN-II-CT-RO-FR-
2012-1-0084.
We would like to thank the reviewers for their time and
expertise, constructive comments and valuable insights.
R EFERENCES
[1] Arduino project: http://arduino.cc/en/Guide/Introduction, and Raspberry
Pi project: http://www.raspberrypi.org/about.
[2] Ted talk by Catarina Molta in which she encourages collaboration
between different science branches
http://www.ted.com/talks/catarina mota play with smart materials.html
[3] Bogdan Ghit, Florin Pop, and Valentin Cristea. 2011. Using Bio-inspired
Models to Design Peer-to-Peer Overlays. In Proceedings of the 2011
International Conference on P2P, Parallel, Grid, Cloud and Internet
Computing (3PGCIC ’11). IEEE Computer Society, Washington, DC,
USA, 248-252.
[4] Ivan Stojmenovic. 1997. Honeycomb Networks: Topological Properties
and Communication Algorithms. IEEE Trans. Parallel Distrib. Syst. 8, 10
(October 1997), 1036-1042.
[5] Huaizhi Li; Singhal, M., Trust Management in Distributed Systems,
Computer , vol.40, no.2, pp.45,53, Feb. 2007
[6] Mekouar, Loubna, Youssef Iraqi, and Raouf Boutaba. Reputation-based
trust management in peer-to-peer systems: taxonomy and anatomy, Hand-
book of Peer-to-Peer Networking. Springer US, 2010. 689-732.
[7] Ding, Chen, Chen Yueguo, and Cheng Weiwei. 2009. A survey study
on trust management in P2P systems. Department of Computer Science,
School of Computing-National University of Singapore. Technical Report.
[8] Ling Liu and Malcolm Munro. 2012. Systematic analysis of centralized
online reputation systems. Decis. Support Syst. 52, 2 (January 2012),
438-449.
[9] Silaghi, Gheorghe Cosmin, Alvaro E. Arenas, and Luis Moura Silva.
2007. Reputation-based trust management systems and their applicability
to grids. Core-GRID Tech. Rep.: TR-0064.
[10] Paul Resnick, Richard Zeckhauser (2002), Trust among strangers in
internet transactions: Empirical analysis of eBay’ s reputation system, in
Michael R. Baye (ed.) The Economics of the Internet and E-commerce
(Adv. in App. Microec., Vol. 11), Emerald Group Publishing Limited,
pp.127-157.
[11] How do I leave Feedback? Description of E-bay’s feedback system,
http://pages.ebay.com/help/feedback/questions/leave.html.
[12] Sepandar D. Kamvar, Mario T. Schlosser, and Hector Garcia-Molina.
2003. The Eigentrust algorithm for reputation management in P2P
networks. In Proceedings of the 12th international conference on World
Wide Web (WWW ‘03). ACM, New York, NY, USA, 640-651.
[13] Tassos Dimitriou, Ghassan Karame, and Ioannis Christou. 2008. Su-
perTrust - a secure and efficient framework for handling trust in super
peer networks. In Proceedings of the 9th international conference on
Distributed computing and networking (ICDCN’08), Shrisha Rao, Mainak
Chatterjee, Prasad Jayanti, C. Siva Ram Murthy, and SanjOy Kumar Saha
(Eds.). Springer-Verlag, Berlin, Heidelberg, 350-362.
[14] Andreea Visan, Florin Pop, and Valentin Cristea. 2011. Decentralized
Trust Management in Peer-to-Peer Systems. In Proceedings of the 2011
10th International Symposium on Parallel and Distributed Computing
(ISPDC ‘11). IEEE Computer Society, Washington, DC, USA, 232-239.
[15] Transmission control protocol, protocol specification
http://tools.ietf.org/html/rfc793.
[16] Konstantinos Tserpes, Fotis Aisopos, Dimosthenis Kyriazis, Theodora
Varvarigou. 2012. A recommender mechanism for service selection in
service-oriented environments. Future Gener. Comput. Syst. 28, 8 (Octo-
ber 2012), 1285-1294.
[17] Talal H. Noor, Quan Z. Sheng, Sherali Zeadally, and Jian Yu. 2013. Trust
management of services in cloud environments: Obstacles and solutions.
ACM Comput. Surv. 46, 1, Article 12 (July 2013), 30 pages.
[18] Heiko Niedermayer, Ralph Holz, Marc-Oliver Pahl, and Georg Carle.
2009. On using home networks and cloud computing for a future internet
of things. In Proceedings of the Second Future internet conference on
Future internet (FIS’2009), Tanja Zseby, Reijo Savola, and Marco Pistore
(Eds.). Springer-Verlag, Berlin, Heidelberg, 70-80.
[19] Dan Chen, Lizhe Wang, Xiaomin Wu, Jingying Chen, Samee U. Khan,
Joanna Koodziej, Mingwei Tian, Fang Huang, and Wangyang Liu. 2013.
Hybrid modelling and simulation of huge crowd over a hierarchical Grid
architecture. Future Gener. Comput. Syst. 29, 5 (July 2013), 1309-1317.
[20] Chunqi Tian and Baijian Yang. 2011. R2Trust, a reputation and risk
based trust management framework for large-scale, fully decentralized
overlay networks. Future Gener. Comput. Syst. 27, 8 (October 2011),
1135-1141.
[21] Mustafa Al-Bakri, Manuel Atencia, and Marie-Christine Rousset. 2012.
TrustMe, I got what you mean!: a trust-based semantic P2P bookmarking
system. In Proceedings of the 18th international conference on Knowledge
Engineering and Knowledge Management (EKAW’12), Annette Teije, Jo-
hanna Vlker, Siegfried Handschuh, Heiner Stuckenschmidt, and Mathieu
d’Acquin (Eds.). Springer-Verlag, Berlin, Heidelberg, 442-445.
[22] A. Chaintreau, P. Hui, J. Crowcroft, C. Diot, R. Gass, and J. Scott.
Impact of human mobility on opportunistic forwarding algorithms. IEEE
Transactions on Mobile Computing, 6(6):606 - 620. IEEE Press, 2007.
[23] [23] R.-C. Marin and C. Dobre. Reaching for the clouds: Contextually
enhancing smartphones for energy efficiency. In Proceedings of the
Second ACM Workshop on High Performance Mobile Opportunistic
Systems, HP-MOSys ’13, pages 31 - 38, New York, NY, USA, 2013.
ACM.