H. Lin et al. / Future Generation Computer Systems 52 (2015) 125–136 127
increasing their reputation then consider it when selecting multi-
point relay nodes. In addition, the model also detects nodes behav-
ing selfishly after selection according to the final decision of the
detection basing on a weighted decision where the most trusted
node has the leading contribution.
Singh et al. [13] presented a trust evaluation framework to
calculate trust on service providers in a cloud computing environ-
ment. The model takes into consideration three views to calcu-
late final trusts which are consumers self trust on service provider,
friends trust on service provider and third party’s trust on ser-
vice provider. Kim et al. [9] proposed a trust management mecha-
nism for reliable data integration, management and applications
in MCC. The mechanism suggested a method to quantify a one-
dimensional trusting relation based on the analysis of telephone
call data from mobile devices. And then, it integrated the inter-
user trust relationship in MCC. Hammam et al. [14] proposed a
trust management system (TMC) for mobile ad-hoc clouds to ver-
ify that participants are reliable, available, and not malicious. The
TMC considered availability, neighbors evaluation and response
quality and task completeness and calculated the reputation trust
value for nodes through EigenTrust algorithm. Chen et al. [10] pro-
posed a global social trust model building system in MCC to pro-
vide trustworthy communicating path and helps address security
issues with increased trustworthiness of user behaviors. The model
described the implicit call behavioral graph formed by users inter-
actions with call and rated these relationships to form a dynamic
local cloud trust. And then, it discussed the propagation and aggre-
gation of local trust values for global social cloud network.
All existing reputation mechanisms or trust models are based
on the direct observation of layer-specifics to evaluate the node
reputation, thus ignoring many key factors of reputation in other
layers such as node forwarding behaviors at the network layer,
channel collisions at the MAC layer and channel quality measures
at the physical layer. Also, none of them take into account the
malicious behavior of the recommendation nodes within the
recommendation reputation evaluation. In addition, none of them
pay attention to the reputation with privacy as a main concern.
Therefore, it is still an open problem and a challenging task
to design a cross-layer and privacy preserving based efficient
reputation mechanism for WM-MCC to defend against the internal
multi-layer, bad mouthing and information disclosure attacks.
3. Reliable recommendation and privacy-preserving based
cross-layer reputation mechanism RP-CRM
In this section, a novel reliable recommendation and privacy
preserving based cross-layer reputation mechanism named RP-
CRM for WM-MCC is extended from our previous work [21–23].
The structure of RP-CRM is described in Fig. 2, which includes three
components: cross-layer reputation fusion center (CRFC), reputa-
tion databases (RD) and reputation computation module (RCM).
The RCM is responsible for the direct reputation computation on
different layers and stores the results into the corresponding RD.
Then, the RD provides direct reputation to the specific layer fi-
nal reputation fusion (SFRF) module in CRFC to compute the spe-
cific layer final reputation and provides the value to the cross-layer
final reputation fusion (CFRF) module in CRFC. Finally, the CFRF ex-
ecutes the cross-layer final reputation fusion according to the spe-
cific requirements from the different layers.
The RP-CRM consists of four phases: reputation query, specific
layer reputation computation and update, cross-layer final reputa-
tion computation, and malicious node classification and manage-
ment.
Fig. 2. The structure of RP-CRM.
3.1. Reputation query
The reputation query phase is to query the request and reply
node reputation through direct or recommended way.
When node x wants to select a neighbor node to provide ser-
vice such as relay, it will send a request message to the neigh-
bor nodes. Each neighbor node such as y receiving the request will
first execute the requester identification function as shown in Al-
gorithm 1 to evaluate x’s reputation and judges whether it is a ma-
licious node. If the requester identification function cannot make
a decision, y will execute the recommendation reputation query
function described in Algorithm 2 to query x’s reputation from its
neighbor nodes. Once receiving the reply messages from its neigh-
bors, y will start the recommendation reputation computation and
the final reputation computation processes in Sections 3.2.2, 3.2.3
and 3.3. If x is considered to be a malicious node, it will be punished
or isolated according to the malicious node classification and man-
agement scheme in Section 3.4. Otherwise, y will send x an accept
message.
After receiving the affirmative response from its neighbors, x
will also execute the above mentioned query process to evaluate
the repliers reputation and decide whether to select or select which
nodes as the service providers.
Algorithm 1: Requester Identification
Input: Requester x’s mac address, sl and sc
Output: x is a malicious node or not
begin
Requester x sends a request(mac, sl, sc, broadcast, TTL = 1);
Requester x sends a request(mac, sl, sc, broadcast, TTL = 1);
x’s neighbor nodes such as y receives the request message;
If (x’ssl > TH
down
sl
) ∧ (x’ssc > TH
down
sc
) then
y executes the Direct Reputation Computation and returns
the result as:
R
Direct
= Direct_reputation (mac, sl, sc);
Else
y drops the request message;
If (R
Direct
> TH
upper
direct
) then
R
Final
= R
Direct
;
Else If (TH
down
direct
< R
Direct
< TH
upper
direct
) then
y executes the Recommendation Reputation Query Function;
y executes the Recommendation Reputation Computation;
y executes the Final Reputation Computation and gets the R
Final
;
Else
R
Final
= −1;
If (R
Final
< TH
down
final
) then
x is considered as a malicious node and will be isolated;
Else If (TH
down
final
< R
Final
< TH
upper
final
) then
x will be punished by decreasing its reputation value;
Else
x is considered as a trustworthy node;
y sends accept(x, y’s mac, y’s sl, y’s sc)tox;
end