Mobile Information Systems

Mobile Information Systems / 2016 / Article
Special Issue

Security and Privacy Challenges in Vehicular Cloud Computing

View this Special Issue

Research Article | Open Access

Volume 2016 |Article ID 9083608 | https://doi.org/10.1155/2016/9083608

Zhipeng Tang, Anfeng Liu, Zhetao Li, Young-june Choi, Hiroo Sekiya, Jie Li, "A Trust-Based Model for Security Cooperating in Vehicular Cloud Computing", Mobile Information Systems, vol. 2016, Article ID 9083608, 22 pages, 2016. https://doi.org/10.1155/2016/9083608

A Trust-Based Model for Security Cooperating in Vehicular Cloud Computing

Academic Editor: Miao Wang
Received22 Jun 2016
Accepted07 Sep 2016
Published12 Oct 2016

Abstract

VCC is a computing paradigm which consists of vehicles cooperating with each other to realize a lot of practical applications, such as delivering packages. Security cooperation is a fundamental research topic in Vehicular Cloud Computing (VCC). Because of the existence of malicious vehicles, the security cooperation has become a challenging issue in VCC. In this paper, a trust-based model for security cooperating, named DBTEC, is proposed to promote vehicles’ security cooperation in VCC. DBTEC combines the indirect trust estimation in Public board and the direct trust estimation in Private board to compute the trust value of vehicles when choosing cooperative partners; a trustworthy cooperation path generating scheme is proposed to ensure the safety of cooperation and increase the cooperation completion rates in VCC. Extensive experiments show that our scheme improves the overall cooperation completion rates by 6~7%.

1. Introduction

Many new applications have been raised on the vehicular technology by V2V (Vehicle-to-Vehicle) and V2I (Vehicle-to-Infrastructure) communications [15]. Recently, several researches related to the combination of cloud computing and vehicular networks [4, 5] are proposed. A Platform as a Service (PaaS) model provides cloud services for mobile vehicles [68]. Hussain et al. describe architectures of Vehicular Clouds (VC), namely, Vehicles using Clouds (VuC) and Hybrid Clouds (HC), in which vehicles play roles of cloud service providers and clients, respectively [9]. Vehicular Cloud Computing (VCC) is one of the most promising paradigms [1, 4, 911]. VCC, which consists of vehicles cooperating the resources of computing, has a significant impact on applications [9, 11]. However, VCC is different from the traditional cloud infrastructure and requires a sophisticated security and privacy protection approach because the legitimate users and attackers have the same privileges [1, 4, 1219].

One of the promising applications in VCC is performing tasks by vehicles’ cooperation. This application, which is more difficult than the existing ones in depth and breadth, has important significance: in the traditional Delay Tolerant Network (DTN) and Peer-to-Peer Network, it can only disseminate information. But, in VCC, not only can this application disseminate information, but also it can do more practical work, such as delivering packages, luggage, and credentials [1, 4, 10, 11].

Taxi network is a typical scenario of VCC. Each taxi in this scenario is regarded as a vehicle which can share information by communicating in a point-to-point manner and accessing internal broadcast by communication devices. From the perspective of traditional view, taxis can be modeled as mobile nodes in DTN. However, more applications can be achieved when modeled in VCC. In particular, when performing a task, vehicle can apply for cooperating with several vehicles, which will improve service quality and reduce resource consumption. Listed below are several concrete examples. (a) Vehicle has received a user request and promised to pick up a passenger in street at timestamp , but traffic jam has made it impossible for vehicle to finish this task. In this situation, vehicle can request vehicle to perform this task. There are two preconditions when selecting vehicle . First, vehicle has ability to fulfil this task; second, vehicle should be trustworthy. (b) Vehicle has received a user request and promised to perform a task which cannot be finished by itself individually, such as picking up a tourist group. In this situation, vehicle should select reliable vehicles and send cooperation request to them for performing this task together. (c) Vehicle has received a user request and promised to deliver an important package to person in street . In real scenario, this task has to be performed by cooperation of several vehicles. For instance, first, vehicle delivers this package to vehicle ; then vehicle delivers it to vehicle ; finally, vehicle delivers it to person . This process forms a cooperation path. In order to guarantee the safety of the package, how to select trustworthy vehicles in cooperation path is a challenging problem.

The examples listed above can be summarized as the following application scenario: vehicle has received a user request for performing certain tasks. These tasks not only include the traditional applications in DTN [2022], such as relaying information, but also can be extended to physical request, such as delivering objects. However, for some reason, vehicle cannot fulfil the task by itself. In order to finish this task, it sends request for cooperation to vehicles which are willing to offer help. In the cases when vehicles which received the cooperation request still cannot fulfil the tasks by themselves, they will further send this cooperation request to other vehicles recursively to request from them to offer help to finish the remaining tasks, which forms a nontrivial cooperation path.

Figure 1 illustrates a concrete example of the summarized application scenario: when vehicle receives a user request of delivering a package to person in street as soon as possible. If vehicle can finish this whole task by itself, it will provide services to user directly, which forms a trivial cooperation path whose length is 1 hop, namely, a hop from user to vehicle . If vehicle cannot deliver the package to person directly, vehicle will finish what it can do and then send messages to other vehicles to ask if they are willing to cooperate to perform the rest of the task. Vehicles that give positive response form a set . Vehicle will select several trustworthy vehicles in set and send cooperation request to them. Assume vehicle has received cooperation request from vehicle . If vehicle can finish the whole task by itself, it will provide services to requestor vehicle directly. If vehicle still cannot finish the task by itself, it will do what it can do and further recursively send the cooperation request to other vehicles just like vehicle . This recursive process forms a nontrivial cooperation path. Every cooperation path corresponds to a solution to user request.

There are several challenges in this application scenario. (a) The first challenge is lack of trust information. How to choose trustworthy vehicles is a vital problem in this application scenario. However, there are thousands of vehicles in a metropolis. It is unrealistic for a vehicle to have trust information of all vehicles in the metropolis. In fact, for a certain vehicle, the reliability of most of vehicles is unknown. When a vehicle needs cooperation to perform a task, such as delivering a package, the phenomenon of lack of trust information makes choosing trustworthy cooperative vehicles difficult. (b) The second challenge is ensuring the safety and success of tasks. In traditional communication network, such as DTN, we can encrypt information to ensure the safety and privacy. Even if the encrypted information is destroyed by attackers, we still can retransmit this information to ensure the task’s reliability [2026]. Things are different in VCC; physical objects can also be delivered in this paradigm. Irreversible loss will be made if the physical objects are ruined by malicious vehicles.

In this paper, a trust-based model is proposed to promote the secure cooperation in VCC. Listed below are the contributions of this paper.

(1) A double board based trust estimation and correction (DBTEC) scheme is proposed to predict the reliability of vehicles and guide the selection of trustworthy cooperative vehicles in a more effective manner. In traditional scheme, vehicles use information acquired in direct interactions with other vehicles to update the trust information of other vehicles. But in DBTEC scheme, Public board is introduced to enrich the method of acquiring trust information. Every vehicle stores the service quality and trust information of other vehicles, which are acquired in the direct interactions with other vehicles, in their own storage, called Private board. In addition, they use Public board, which stores public estimated service quality for other vehicles reported by all vehicles in cloud to update and correct the trust information stored in Private board. The method of updating and correcting trust information from Public board, called trust value estimation model, is based on the following inference: the information acquired from direct interaction is trustworthy; vehicles can use this information as touchstone to confirm if a certain vehicle is trustworthy. Then, based on the public estimated service quality related to the trustworthy vehicle in Public board, vehicles can update and correct the trust information of other vehicles in Private board and use the revised trust information to guide their future selection of cooperative partners.

(2) A new method of constructing cooperation path is proposed in this paper. In traditional scheme, the cooperation path is fixed once it is constructed. This static method is not suitable for VCC. In this paper, we propose a dynamic cooperation path construction scheme. In the proposed scheme, every vehicle dynamically searches and selects cooperative vehicles and constructs new node in cooperation path by analyzing the feedback of detections. The new vehicles will recursively repeat this process until finishing the task.

(3) Extensive theoretical analysis and simulation have been made to prove the effectiveness of this paper from aspects of security and reliability.

The rest of this paper is organized as follows. In Section 2, related works are reviewed. In Section 3, the system model, threat model, and problem statement are described. In Section 4, the DBTEC schemes are proposed. Section 5 gives the analysis of experimental results. We conclude this paper in Section 6.

Extensive researches have been done on the topic of trust computing and inference [2730] and they have been applied to various networks, such as Peer-to-Peer (P2P) file-sharing networks [31, 32], service network [1, 9, 18], wireless sensor networks (WSNs) [30], crowd sensing network [3], and social networks [28]. The aim of trust computing and inference is to select cooperative partner using computed trust value information [29]. Kamvar et al. [31] proposed trust computing and inference scheme in the Peer-to-Peer (P2P) file-sharing networks based on historical uploads, which is called EigenTrust. Inferring trust information through historical behaviors is a common method used in networks. In EigenTrust scheme, to encourage legitimate and trustworthy behaviors and improve the network’s overall performance, some privilege is given to trustworthy objects. The main difficulties of EigenTrust are that, when applying it to distributed network, it is difficult to share trust information with others. This proposal mainly concentrates on P2P file-sharing networks. However, in a dynamic environment, such as vehicular ad hoc networks (VANETs), this proposal is not feasible.

Haddadou et al. give a dynamic solution based on reputation model for vehicles in [27], which differs from the solution in [31]. The basic idea of [27] is to add a category criterion to drivers.

However, the amount of trust information acquired in direct interactions is limited. In a large network, the number of nodes can be up to thousands. So the trust information acquired from direct interactions is sparse in that network. Judging the reliability of vehicles only using direct interactions will lead to cold start problem. There are several definitions of cold start. The main idea of cold start is that when a new object enters the network, because of the deficiency of trust information acquired from interactions, it is hard to judge if a vehicle is malicious, which makes choosing a right cooperative partners difficult [28]. To overcome the cold start problem, researchers introduce the concepts of direct trust information and indirect trust information. Direct trust information is acquired in the direct interactions between two objects. Indirect trust information is the trust information inferred from other objects’ recommendation trust information. For example, object has no direct interactions with object , but object has directly interacted with object . Assuming that object ’s trust value to object is and object recommends object to object with trust value , object can infer that the trust value to object is from the recommendation trust information. Combining direct trust information and indirect trust information enhances the computation of trust value [28], but how to effectively compute the trust value is a complicated issue, which needs an extensive research.

The traditional application in VCC is disseminating information. For example, Rostamzadeh et al. propose a safe and reliable trust-based framework for disseminating information in vehicular networks [29]. With the advance of crowd sensing network, Internet of Vehicles, and Internet of Everything, delivering physical objects is becoming an emergent application in society. The safety and reliability of delivering physical objects are important requirement in this application, which becomes a key issue in research. This paper discusses this issue in detail.

3. The System Model and Problem Statement

3.1. System Model

Suppose that there are registered vehicles. is the set of vehicles. All vehicles will move randomly in a limited area.

There are two kinds of service requests in VCC: user requests and cooperation requests. The major difference between them is that user requests are generated by users, but cooperation requests are generated by vehicles. The following paragraphs describe these two kinds of requests.

Typical instances of user requests include delivering packages, picking up passengers, or tourist group with minimized costs. Vehicles can accept user requests and provide services to requestors for some payment. Once vehicles’ accepted user requests cannot be finished by themselves, they will select several trustworthy vehicles which are willing to provide services and send cooperation request to them.

Once those vehicles receive cooperation requests, they will cooperate to provide services together. These vehicles still may not be able to fulfil the tasks by themselves and further send cooperation requests to other trustworthy vehicles recursively. This recursive process will form a nontrivial cooperation path (see Figure 1(b)).

All cooperation path forms set in which is a trivial/nontrivial cooperation path. is the number of cooperation paths in VCC. The length of cooperation path is , which is equal to the number of cooperation requests generated to finish a task. A cooperation path can be subdivided to many subcooperation paths, whose starting nodes are one of the nodes in the paths and ending nodes are the original paths’ ending nodes; this concept will be used in Section 4.4.

The quality of service (QoS) can be modeled as a value between 0 and 1 called service quality. Different vehicles can provide different quality of service. For vehicle , its service quality is . The set of service quality of all vehicles is .

Vehicles in can be categorized into two types: normal vehicles and malicious vehicles. Malicious vehicles will use various means to strive for the opportunities of providing services, such as reporting mendacious trust value or service quality and colluding with other malicious vehicles. Once malicious vehicles get the opportunities, they will screw the service requests up in various manners, such as colluding with other malicious vehicles to provide low-quality services or destroy packages, to disrupt the network, and to benefit themselves. Assume that the first vehicles in are malicious, which consist of set . The remaining vehicles are normal, which consist of set . Obviously, .

In order to prevent malicious vehicles from disrupting the network, normal vehicles should avoid sending cooperation requests to them. They store the estimated trust value and estimated service quality for other vehicles in storage, called Private board, and use this information to guide the selection of trustworthy vehicles when sending cooperation requests. As will be illustrated in Section 4.3, the Private board of vehicle can be modeled by two sets:where is the estimated service quality of recorded by and is the estimated trust value of recorded by . Several timestamps (, , and ) are also recorded to trace the recording time.

Besides Private board, In DBTEC schemes, all vehicles can access a public cloud storage space, called Public board, anywhere and selectively report their estimated service quality for other vehicles to it. Vehicles can use the information in Public board to update the estimated trust value stored in Private board. As will be illustrated in Section 4.3, the Public board can be modeled by two matrices, and , where records the public estimated service quality reported by vehicles and records the reporting timestamps.

Note that estimated service quality is selectively reported to Public board, which means some service quality information may not be updated to Public board. Several reasons may result in this phenomenon: privacy protection, avoiding revenge, and network interruption.

3.2. Threat Model

There are malicious vehicles in VCC, which consist of set ; four possible malicious behaviors are listed below. These malicious behaviors can be combined to form sophisticated malicious models, such as providing unstable services. In Section 5.3, five malicious models are introduced to analyze the performance of DBTEC schemes.

(1) Report False Self-Estimated Service Quality to Public Board When Registering. High-quality service is wanted by users. Normal vehicles and users tend to choose vehicles providing high-quality services as cooperative partners. Normal vehicle reports true service quality it can provide, which is called self-estimated service quality, to Public board when registering. Malicious vehicles can deceive normal vehicles by reporting mendacious self-estimated service quality to Public board; this deception method is effective especially in the stage of cold start, in which trust information is deficient.

(2) Slander Normal Vehicles. As described above, normal vehicles and users tend to choose vehicles providing high-quality services as cooperative partners. Slander normal vehicles by reporting estimated service quality lower than normal level to Public board will reduce the probability that normal vehicles get opportunities of providing services, which increase the malicious vehicles’ opportunity indirectly.

Generally speaking, this can be regarded as a kind of collusion attack since all malicious vehicles can benefit from cooperatively slandering normal vehicles and acquire much more opportunities to provide services.

(3) Collude with Malicious Vehicles by Praising Malicious Partners. This is a stronger collusion attack than the previous one since it has direct impacts on confusing normal vehicles. It praises malicious vehicles by reporting estimated service quality above their normal level to Public board, which can directly increase malicious vehicles’ opportunities of providing services.

(4) Malicious Vehicles Camouflage Themselves as Normal Vehicles by Acting Like Them in Most of Time. Malicious vehicles can pretend to be normal vehicles by behaving just like them and provide unstable services. In this malicious scenario, the malicious vehicles behave normally generally. However, sometimes they will act some malicious behavior to benefit themselves. Because of the camouflage, this attack is hard to find.

3.3. Problem Statements

The application scenario considered in this paper is as follows: in Vehicular Cloud Computing (VCC), vehicles will receive user’s service requests and provide services to them. In the process of providing services to users, if vehicles can finish the task, they will provide services directly to users, which forms a trivial cooperation path whose length is 1 hop (see Figure 1(a)). But vehicles may not be able to finish the task by themselves for some reason. In this case, vehicles will choose several trustworthy vehicles which are willing to offer help and send cooperation request to them. Vehicles which receive cooperation request still may not be able to completely finish the task by themselves. They will recursively send cooperation requests to other vehicles until the task is finished. The recursive process of completing tasks forms a nontrivial cooperation path (see Figure 1(b)). A cooperation path corresponds to a solution to user request in this application scenario. Specifically, the cooperation path is trivial in the case when vehicle which receives the user request can finish the user request directly and no further cooperation happened. The key challenge of this application scenario is how to select vehicles, which can guarantee the success of the service and maximize the quality of service for cooperation.

In the process of cooperation, vehicles may wrongly choose malicious vehicles for cooperation, which will lead to the failure of the cooperation. We refer to selecting a vehicle to cooperate as a choice. A wrong choice means selecting a malicious vehicle for cooperation. A right choice means selecting a normal vehicle for cooperation. If there exists a wrong choice in a cooperation path, we say this cooperation path is failed. There are three aims in the application scenario to overcome the challenge described above.

(1) Minimize Failure Rate of Cooperation. Assume that all cooperation paths in VCC form set , where is the set of successful cooperation paths and is the set of failed cooperation paths. So the number of cooperation paths is and the number of failed cooperation paths is . The failure rate of cooperation is defined as and we should minimize it:

(2) Minimize the Failure Rate of Choices. Similarly, assume that all choices in VCC form set , where is the set of right choices and is the set of wrong choices. So the number of choices is and the number of wrong choices is . The failure rate of choices is defined as and we should also minimize it:

(3) Maximize Quality of Service of All Cooperation Paths. We define the quality of service of a cooperation path as the minimum service quality provided by vehicles in the cooperation path. This definition is reasonable because of the Cannikin law. Assume that the quality of service of cooperation path is , where . Therefore the total quality of services is . We should maximize the average service quality of cooperation path:

In general, we can combine the above three optimization requirements and try to find a scheme which satisfies the following three formulas together in this application scenario of VCC:

Notations describes some important notations used throughout this paper.

4. DBTEC Schemes

4.1. Overview

The main contribution of DBTEC schemes is to combine Public board with Private board to guide the selection of cooperative vehicles. In traditional scheme, vehicles can only acquire trust information from direct interactions with other vehicles [28]. Unlike the traditional scheme, in DBTEC schemes, vehicle not only uses the information acquired in direct interaction but also uses trustworthy vehicles’ public estimated service quality stored in Public board. When vehicle needs to cooperate, it will choose a cooperative partner. DBTEC schemes use the information stored in Public board, which is a public information storage stored in cloud, to update the estimated trust value stored in vehicle ’s Private board and then uses updated Private board to further guide the selection of proper cooperative partners. In DBTEC schemes, vehicles with high estimated trust value in vehicle ’s Private board are called trustworthy. The trustworthy vehicles’ public estimated service quality stored in Public board is just like the touchstone used to test whether an unfamiliar vehicle is malicious. When vehicle trusts vehicle , DBTEC will check public estimated service quality for all vehicles reported by vehicle in Public board and all estimated service quality for vehicle reported by all vehicles to find the inconsistency and use the inconsistency to find malicious vehicles.

Compared with traditional scheme, DBTEC scheme has major advantages. One of them is overcoming the problem that trust information is deficient in the stage of cold start. In the stage of cold start, vehicles do not have enough trust information to guide the selection of cooperative partners, which will significantly increase the probability that malicious vehicles get the opportunity of providing services. DBTEC scheme uses the trust information we already have as a touchstone to check the consistency and inconsistency in Public board and further updates the Private board’s trust information. This process is just like diffusion of trust information; vehicles will get a lot of indirect information from the process, which will overcome the problem that trust information is deficient and increase the accuracy rate of selecting right vehicles.

Described below are the DBTEC schemes from high level.

As described in system model, there are vehicles in VCC. Different vehicles can provide different quality of service. For vehicle , its service quality is . Vehicles can be categorized into two types: malicious vehicles and normal vehicles. There are malicious vehicles in VCC. Public board is a public cloud storage which can be accessed by vehicles anywhere. All vehicles can report their estimated service quality for other vehicles to Public board. All vehicles store a Private board in which they keep their own estimated trust value and estimated service quality information for other vehicles.

For a normal vehicle , when vehicle receives a user request, it will check if it can be done by itself; if not, it will search for vehicles which are willing to perform this task, use trust value estimation model to update the information stored in Private board using the information stored in Public board, choose several cooperative vehicles using the synthesized score which is computed from the estimated trust information and service quality information stored in Private board, and send cooperation requests to them. After the cooperative vehicles provide services to vehicle , vehicle will rate the service quality of cooperative vehicles, update the estimated service quality information and trust information in Private board, and selectively report the estimated service quality to Public board.

For a malicious vehicle , it will use various methods to strive for the opportunities of providing services. Once malicious vehicles get these opportunities, they will screw the service requests up in various manners to disrupt the network and benefit themselves. Common malicious behaviors include reporting false self-estimated service quality, slandering normal vehicles, praising malicious partners, and providing unstable services (see Section 3.2).

Figure 2 illustrates a concrete example of the process of cooperation in DBTEC. A passenger in train station wants to hire a taxi; he sends user request by mobile phone to vehicle with blue shadow. Unfortunately, when vehicle is driving to train station, it encounters a traffic jam in a street. Obviously, it cannot finish the task by itself in time. It seeks neighboring vehicles which are willing to offer help and combines trust information stored in Private board with information stored in Public board to predict the reliability of these neighboring vehicles. Then it sends cooperation request to a trustworthy vehicle, namely, the vehicle with green shadow. The trustworthy vehicle drives to train station to pick up the passenger and send him to destination.

In the following subsections, we describe the Public board model, Private board model, behavior of normal vehicles, trust value estimation model, and cooperation path generating model, respectively.

4.2. Public Board Model

All vehicles can access Public board, which is stored in cloud storage, anywhere. Public board stores the public estimated service quality for vehicle reported by vehicle , called , and the timestamp at which it was reported, called . Public board can be expressed by two matrices, and :

The scale of is between 0 and 1. is a neutral service quality estimation. When , the service quality is worse than normal level. Conversely, when , the service quality is better than normal level. is a value larger than or equal to 0. means no updating of estimated service quality has been committed and is still the initial value.

Vehicle can register to join VCC. For vehicle , it sends a registering request to Public board and report its own service quality , called self-estimated service quality, to it (service quality can be fake if the vehicle is malicious) when registering; Public board will store this service quality in and update the corresponding to 0. After reporting its own service quality to , Public board will pack all vehicles’ self-estimated service quality together and send it to vehicle ; vehicle will use this information as initial service quality to update Private board.

After initialization, Public board will handle the following two events:(1)If receiving estimated service quality for vehicle reported by vehicle , Public board will update the service quality stored in and timestamp .(2)If a certain vehicle inquires about the estimated service quality for vehicle reported by vehicle , Public board will pack the service quality and the corresponding timestamp as a tuple and send it to the vehicle.

The pseudocode of Public board is presented in Algorithm 1.

Initialize:
Initialize all scalars in with 0.5;
Initialize all scalars in with 0.
() While true
()  If   reports its estimated service quality value for
()   
()   Set to current timestamp
()  End If
()  If   inquires public estimated service quality value of
()   Send to
()  End If
() End While
4.3. Private Board Model

All vehicles store Private board in their own storage to guide the selection of trustworthy cooperative vehicles.

For vehicle , assume that its estimated service quality for vehicle is and its estimated trust value for vehicle is . Both of them will be stored in its Private board. In other words, vehicle ’s Private board records

The meaning of is similar to as described in Section 4.2. The scale of trust value is between 0 and 1. is a neutral trust value estimation. When , vehicle thinks vehicle is malicious. Conversely, when , vehicle thinks vehicle is normal.

Besides and , several timestamps are stored in vehicle ’s Private board: the timestamp at which vehicle updates and the timestamp at which vehicle updates because of trusting in vehicle (this timestamp can be divided into two subtimestamps: the subtimestamp at which vehicle updates from column perspective because of trusting in vehicle and the subtimestamp at which vehicle updates from row perspective because of trusting in vehicle ). In other words, besides and , vehicle records

These timestamps are stored to prevent updating Private board using the same information repeatedly.

4.4. Normal Vehicles

Every normal vehicle stores its own Private board and can access Public board anywhere.

When entering VCC, all normal vehicles will send a registering request to Public board, report their own self-estimated service quality to Public board, and then wait for the package sent by Public board which stores all vehicles’ self-estimated service quality to initialize its Private board.

After registering, for normal vehicle , it will receive a user request at some times. If vehicle can finish the user’s task, it will provide services to users directly, which forms a trivial cooperation path whose length is 1 hop (see Figure 1(a)). If vehicle cannot finish the task by itself for some reason, it will send messages to other vehicles to ask if they can cooperate to perform this task. Vehicles which give positive responses form set . Vehicle then uses trust value estimation models to update its own Private board using the information from Public board and uses the updated Private board to compute synthesized score. Vehicle will then send cooperation request to vehicles in with large synthesized score. Vehicles receiving cooperation request will provide service to vehicle . In the process of providing service, they may send cooperation request recursively to more vehicles. The recursive process will form a nontrivial cooperation path (See Figure 1(b)).

Note every cooperation path corresponds to a solution to a service request. The service quality of a cooperation path is defined as the minimum service quality provided by vehicles in cooperation path. Every cooperation path consists of many subcooperation paths whose starting node is an intermediate node in original path and ending node is the ending node of the original task.

After vehicles which received cooperation request finish the cooperation request from vehicle , vehicle will estimate the quality of this service, update its own Private board, and report the updated item to Public board selectively (they may not report it for self-protection or privacy-protection).

Concretely speaking, vehicle sends cooperation request to vehicle , vehicle may finish this task by itself or by further cooperation with other vehicles, and the service quality provided by vehicle for this cooperation request is , which is the minimum service quality in subcooperation path starting from vehicle (i.e., the original cooperation paths’ starting node is vehicle ). Vehicle will update to according to Formula (11), set to , and update to current timestamp simultaneously.

In Formula (11), is the threshold to check if the service quality and are close enough; and are parameters used to control the extent of change in . ; namely, the difference between and is large, which means the difference between estimated service quality of this cooperation and service quality of last cooperation (or the initial service quality of vehicle ) is large and therefore the service quality of vehicle , namely, , is not stable (or vehicle ’s initial service quality is false); we should decrease according to parameter . Conversely, means the service quality of vehicle , namely, , is stable (or vehicle ’s initial service quality is true); we should increase according to parameter .

The pseudocode of normal vehicles is presented in Algorithm 2.

Initialize:
Initialize all scalars in and with 0.5
Initialize all scalars in , and with 0
Register itself by reporting to Public board
Waiting for self-estimated service quality of other vehicles sent by Public board
() While true
() Move randomly in the area
()    If   receives a service request
()     If   can finish the request
()    Provide service to requestor directly
()     Else
()    Search vehicles willing to offer help
()    Update Private board using trust value estimation model
()    Compute synthesized score of vehicles in
()    Assume vehicles are needed to complete the task
()    Set as vehicles in with first largest synthesized score
()    Send cooperation request to vehicles in
()    For vehicle   in  
()     Receive service from vehicle with quality
()     
()     Set to current time stamp
()     Report service quality to Public board
()     
()     If  
()      
()     Else
()      
()     End If
()    End For
()   End If
()  End If
() End While
4.5. Trust Value Estimation Model

Trust value estimation model can update the information of Private board based on Public board to increase the precision of trust value estimation and guide the selection of cooperative vehicles. In particular, this model will take great effects when trust information is deficient, such as cold start stage.

Trust value estimation model is based on this observation: when vehicle trusts vehicle , the following statements are true:(1)The estimated service quality for vehicle stored in vehicle ’s Private board, namely, , is true.(2)Public board’s all estimated service quality reported by vehicle is true.

Vehicle uses this observation to update other vehicles’ trust value and estimated service quality in Private board and prevent malicious vehicles from taking part in cooperation. The following two rules describe the method.

Rule 1. For a certain vehicle with high trust value in vehicle ’s Private board, if the difference between and is large, where and and , decrease .
According to observation , the estimated service quality for vehicle stored in vehicle ’s Private board, namely, , is true. If the difference between and is large, it is likely that vehicle reports a false service quality to Public board, which is a malicious behavior; vehicle should decrease its trust value.

Rule 2. For a certain vehicle with high trust value in vehicle ’s Private board, if , in other words, has been updated, where and and , vehicle updates the Private board according to two cases.

Case 1. In the case where , in other words, has been updated, if the difference between and is large, decrease . If the difference between and is small, then check : if is small, then further decrease ; if is large, then further increase .
When the difference between and is large, according to observation , is close to real value, and therefore may deviate from the real value, which means vehicle provides different service quality to different vehicles maliciously. Vehicle should decrease .
When the difference between and is small, there are two cases to analyze: both vehicle and vehicle believe vehicle is malicious or both vehicle and vehicle believe vehicle is normal. We can use the estimated trust value for vehicle stored in vehicle ’s Private board, namely, , to distinguish the two cases. When is small, vehicle can infer that both vehicle and vehicle think vehicle is malicious; vehicle further decreases . Conversely, when is large, vehicle can infer that both vehicle and vehicle think object is normal; vehicle further increases .

Case 2. In the case where , in other words, has not been updated, if is large enough, make vehicle accept a virtual cooperation from vehicle whose service quality is : set as and update the trust value of vehicle according to this virtual cooperation using Formula (11).

According to observation , vehicle can update the estimated service quality for vehicle in Private board using , which is a trustworthy value when vehicle is trustworthy.

We will detail this model in the next two subsections. Section 4.5.1 will give a concrete scheme; DBTEC scheme with this section’s trust value estimation model is called DBTEC-1. Section 4.5.2 will improve the scheme to solve cold start problem; DBTEC scheme with this section’s improved trust value estimation model is called DBTEC-2.

4.5.1. DBTEC-1

We detail the trust value estimation model and propose a temporary detailed scheme called DBTEC-1 in this section, which will be further improved in the next subsection.

Below we detail the two rules listed above.

Rule 1. For vehicle with trust value in vehicle ’s Private board, if and , where , vehicle decreases to according to Formula (12) and updates to current timestamp.Condition guarantees that has been updated since initialization and vehicle will not update trust value using the same information repeatedly. is the subtimestamp at which vehicle updates from column perspective because of trusting in vehicle . In other words, this subtimestamp records the timestamp. Rule 1 is used to update trust value’s last time. means no updating has been committed to since using Rule 1 last time. Repeat updating using the same information will lead to error. Formula (12) means vehicle will decrease according to parameter if .

Rule 2. For a certain vehicle with trust value in vehicle ’s Private board, if , where , vehicle updates the Private board according to two cases.

Case 1. In the case where , in other words, has been updated, suppose that the difference between and is . If , vehicle decreases to according to Formula (13) and updates to current timestamp:if , vehicle updates to using Formula (15) and updates to current timestamp: means vehicle will decrease according to parameter if the difference between and is large (. means that if vehicle is likely to be a normal vehicle, we further increase according to parameter . The more trustworthy vehicle is, the larger amount of increment has. Conversely, if vehicle is likely to be a malicious vehicle, we further decrease according to parameter . The less trustworthy vehicle is, the larger amount of decrement has.

Case 2. In the case where , in other words, has not been updated, make vehicle accept a virtual cooperation from vehicle whose service quality is : set as , update the trust value of vehicle according to this virtual cooperation using Formula (11), and update to current timestamp.

The pseudocode of this scheme is presented in Algorithm 3.

) For    in  
()    If  
()     For    in  
()      If  
()     
()     If  
()      
()      Set to current time stamp
()     End If
()    End If
()   End For
()   For    in  
()    If  
()     If  
()      
()      If  
()       
()       Set to current time stamp
()      Else
()       
()       If  
()        
()       Else
()        
()       End If
()       Set to current time stamp
()      End If
()     Else
()      
()      If  
()       
()      Else
()       
()      End If
()      
()      Set to current time stamp
()     End If
()    End If
()   End For
()  End If
() End For
4.5.2. DBTEC-2

We further improve the performance of DBTEC-1 in this subsection.

In the beginning stage of VCC, deficiency of information will make many trust value estimation schemes invalid. This phenomenon is called cold start.

DBTEC-1 scheme cannot guide the selection of cooperative partner well when in stage of cold start because it can only take effect when vehicles’ trust value becomes larger than threshold . We can improve the original scheme based on this observation.

Unlike DBTEC-1, we no longer use an absolute threshold as a starting condition of trust value estimation scheme. We can adjust the influence of trust value estimation scheme according to the trust value of vehicles. The more trustworthy the vehicle is, the more influence it will have in trust value estimation scheme.

This improvement can significantly enhance the performance of DBTEC-1, especially in the stage of cold start, since it can address the trust information deficiency problem in cold start stage, in which most of the failed cooperation happened. DBTEC scheme with this improved trust value estimation model is called DBTEC-2, which is an improved version of DBTEC-1.

Below we introduce the improvement in detail.

According to the description above, two new parameters, and , are introduced into the scheme to control the influence of trust value estimation model. and can be computed according to the following two formulas:

When , vehicle is completely trustworthy and therefore the influence degree is corresponding to , which is the biggest influence degree. When , Formula (16) maps trust value ~ to ~. The larger is, the larger influence degree is. has similar conclusion. When , vehicle is completely trustworthy and therefore the influence degree is corresponding to , which is the biggest influence degree. When , Formula (17) maps trust value ~ to ~.

Below are the rules of the improved scheme.

Rule 1. For a certain vehicle with trust value in vehicle ’s Private board, compute and . If and , where , vehicle decreases to according to Formula (18) and updates to current timestamp.

Rule 2. For a certain vehicle with trust value in vehicle ’s Private board, compute and . If , where , vehicle updates the Private board according to two cases.

Case 1. In the case where , in other words, has been updated, suppose that the difference between and is . If , vehicle decreases to according to Formula (19) and updates to current timestamp:if , vehicle updates to using Formula (21) and updates to current timestamp:

Case 2. In the case where , in other words, has not been updated, make vehicle accept a virtual cooperation from vehicle whose service quality is : set as , update the trust value of vehicle according to this virtual cooperation using Formula (11), and update to current timestamp.

The pseudocode of this scheme is presented in Algorithm 4.

) For    in  
()   If  
()      Compute and
()       For    in  
()     If  
()      
()       If  
()        
()        Set to current time stamp
()     End If
()     End If
()   End For
()   For    in  
()    If  
()     If  
()      
()      If  
()       
()       Set to current time stamp
()      Else
()       
()       If  
()        
()       Else
()        
()       End If
()       Set to current time stamp
()      End If
()     Else
()      If  
()       
()       If  
()