Trust Functions

I have implemented five functions in order to compute the trust value. These functions are implemented on different elements of our trust model such as the MP, the AP and our server.

Function is responsible for computing the trust value of an AP based on past experience of the owner of the MP and this trust value is stored in the MP. where “n” is the number of ratings the user gives about the “AP”. This function aggregates on the MP all the past ratings of the user and its result will be in the range of [0; 1].

Function is responsible for aggregating all the ratings sent by all the users who have used the AP, where “m” is the number of users who have used the “AP” and who have a trust value higher than or equal to 0.5. It computes the trust value of the AP and it is implemented on the server’s side with its results in the range of [0…1].

(3) Function is responsible for computing the Friendshipfactor between the users. We consider nblink as the level of friendship. As we do not know in which context two users have become friends, we need to add a weight which we call the Friendshipfactor. The argument nblink defines the number of hops between two friends, and it is likely to be inferior or equal to 6

according to the theory of Small World [40]. The result of this function is further used in the computation of the recommendations, and it is implemented on our server.

Function is responsible for computing the recommendations coming from the users’ friends, and it takes into account the function . We consider “U” to be all the friends of the user “B” and the “Friendshipfactor” to be the specific weight of that friendship. The argument “f” is the total number of friends of the user “B” and “AP” represents the AP. This function is implemented using some of the same functionalities as the Facebook platform. When a user asks for a recommendation, the Facebook platform will compute his friend list and send it back to the server, where the function is stored and the recommendation will be computed. Our solution does not keep friendship relationships on our server, but we use Facebook to get the friendship relationship of a user.

Function is responsible for computing the trust value of an AP when the user has several hotspots available. The android application uses this function to compute the trust value of each AP available. The variable represents the weight of the trust

value computed on the server’s side. The variable represents the weight of the trust value computed on the user’s side and the variable represents the weight of the recommendations coming from friends.

The values of variables ß, γ, λ and K were chosen based on results obtained with our functions. After testing several values of these variables, the values define above gave me the best results during simulations.

As in any other reputation systems, we must take into account the trustworthiness of the users; as some of them try to cheat by providing assessments that do not correspond to the real performance of the AP. Table 4 summarises all the possible cases, of which only one needs Trust Management. To deal with this case, each user has a trust value stored on the server’s side. At the beginning, all users will have their trust value set to 0.5 and it will be increased by increments of 0.01 each time the user rates a hotspot without cheating. The user’s trust value will be between 0 and 1, and when the trust value of the user reaches 0.99 their trust value cannot increase anymore; even if the user rates a hotspot without cheating. Each time the user tries to cheat; their trust value will decrease to 0. This punishment will encourage users to behave appropriately and not to cheat. The user will be able to rate a hotspot as “Bad” if and only if her trust value is equal to or higher than 0.5. In the case when the evaluation rating from the user is

“Bad” and the server’s evaluation is “Bad”, we have two sub cases:

 If the user is the only one connected to the hotspot:

If the user has a trust value equal to or higher than 0.5, then we will accept their rating; but if the trust value of the user is lower than 0.5, then we will reject their rating.

 If the user is not the only one connected to the network:

o If the user has a trust value equal to or higher than 0.5, then the server will compare the QoS evidence of other users using the same hotspot at the same time. If the evaluation of the rest of the users is not the same, then we will reject this particular user’s evaluation and the user will be considered a cheater and we will decrease her trust value. But if the trust value of the user is not higher than 0.5, then we will reject the user’s rating.

o If there is more than one user connected to a hotspot and all of them rate it as “Bad”, these ratings will be validated only at the end of the day. At the end of the day if the hotspot receives only “Bad” ratings, then we will validate them. That means that it really is a

“Bad” hotspot; or it is a “Good” hotspot, but only cheaters were connected to this hotspot. If during the day the hotspot receives some “Good” ratings, then at the end of the day if the number of “Good” ratings is lower than the “Bad” ratings, we will validate the

“Bad” ratings; and if the number of “Good” ratings is higher than the number of “Bad” ratings, we will reject these bad ratings because in this case they will be considered suspicious, as we can be sure that when a user rates a hotspot as “Good”, she cannot cheat.

Chapter 5. Implementation and Evaluation of our HotspotTrust Framework

We have implemented our functions and validated our solution with AnyLogic, which is a simulation tool that supports the most common simulation methodologies such as System Dynamics, Process-centric (a.k.a. Discrete Event) and Agent Based modelling. It is based on a Real-time UML and Java object-oriented language.

In Section 5.1, we present the simulator using AnyLogic and the model set-up. In Section 5.2, we describe the validation methodology employed. In Section 5.3, we present the scenario and the results of the simulation with our trust metrics; and finally in section 5.4 we compare the results of our solution to two well-known trust metrics: EigenTrust and Salem metrics.