Abstract
The Internet of things is the next stage in the evolution of the Internet that is being materialized with the integration of billions of smart objects. The state-of-the-art communication technologies have enabled the previously isolated devices to become an active part of the Internet. This constant connectivity opens new avenues for novel applications such as the realization of social Internet of things and its subdomain the social Internet of vehicles. Socializing requires sharing of information that entails trust, especially in an open and broad social environment. This article highlights the key factors involved in conceptualizing an efficient trust model for social Internet of vehicles. Furthermore, it focuses on the unique challenges involved in designing the trust models for social Internet of vehicles. Several trust models exist in literature; however, most of the existing trust models are specific to their domains, for example, Internet of things, social Internet of things, or general vehicular networks. This article presents a brief review of the trust models that have the potential to be implemented in Social Internet of vehicles. Finally, the authors present an overview of how trending concepts and emerging technologies like blockchain and fog computing can assist in developing a trust-based social Internet of vehicles model for high-efficiency, decentralized architecture and dynamic nature of vehicular networks.
Keywords
Introduction
The Internet of things (IoT) is a revolutionary concept that is being materialized with the integration of numerous smart objects. Latest communication technologies have empowered remote devices and networks to become a dynamic part of the Internet. 1 The concept of IoV is derived from vehicular ad hoc networks (VANETs) that have been around for decades. In VANETs, vehicles establish a network by communicating with each other referred to as vehicle to vehicle (V2V) and with infrastructure referred to as vehicle to infrastructure (V2I). VANETs enable various applications to ensure road safety by managing traffic. 2 Advent in technology transmutes the concept of VANETs to IoV that unleashes possibilities of developing unique applications. In IoVs, each vehicle and road-side units (RSU) are Internet enabled and also capable of communicating with each other using dedicated short-range communication (DSRC). This approach enhances the capabilities of the nodes (vehicles, RSUs, etc.) to communicate with each other on a local network and with other networks globally through the Internet.
The cognizance of IoV has set a foundation for special forms of vehicular networks called social Internet of vehicles (SIoV) or sometimes referred to as vehicular social networks (VSN) 3 that has evolved from its parent domain social Internet of things (SIoT). 4 SIoT enables the smart objects to create and manage social relationships between them based on the constraints set by their owners. This way, SIoV is a sub-domain of the SIoT where the vehicles are considered smart objects. This ability of socializing empowers these vehicles to solve many problems s as service discovery (SD) in a network of heterogeneous vehicles to provide trustworthy services to the vehicles. Consequently, this helps realizing diverse applications that can significantly improve the safety on roads, enhance the driver experience, share common interests, and so on. In SIoV, a cluster of vehicles may have a communal interest or need that might assist by socializing with each other. 5 For example, a group of vehicles going to a community fair can socialize with each other by sharing information of traffic in the area, vacant car parking slots, alternate routes, accident warnings, and emergency exits. Similarly, school buses responsible for dropping kids to the school in the morning might socialize with each other by sharing information like school gate closure details, traffic details, school events, and security policies for transports entering and leaving the school premises. Another relevant example for SIoV system can be heavy vehicles (trucks) communicating with each other regarding entering and leaving hours of the city, maximum load capacity details, toll gates information, speed limits, and any other special instructions for heavy vehicles. All these examples depict socializing of vehicles based on their common interest, context, category, and various other aspects like intent for socializing, achieving goals, and enhancing social relationships and environmental factors.
SIoV is an enhanced form of IoV that provides all the benefits of IoV along with providing socializing in vehicular networks. In order to provide these extra features, SIoV requires additional resources like better communication technologies, enhanced security and privacy, more storage space, and high processing power. Table 1 illustrates the key features of IoV and SIoV and presents the major differences between the two. Some of these features are common between both IoV and SIoV, for example, dynamicity and mobility management, as vehicles are expected to be highly mobile in nature and capable of forming dynamic network topologies. However, in some cases, SIoV is expected to provide features that are not of much interest in a traditional IoV system, for example, social relationship and their management is of key interest to SIoV system as it sets the foundation for developing social apps for SIoV network.
Key features of IoV and SIoV.
QoS: quality of service.
The discovery of trustworthy services is the key to a secure and reliable SIoV. The trustworthiness of any service depends on the kind of relationship between vehicles and reputation of the vehicle that is offering a service. Normally, the trust management depends upon two general observations to assess the behaviors of the entities of the network. The first observation normally referred to as direct observation 6 is directly noted by the entity itself. For example, the previous interactions of the entity with another entity were not good based on the information exchanged between them. The second type of observation normally referred to as indirect observation is generally obtained by sharing observations with other entities in the network. For example, vehicles share their experience of data exchange with infrastructures in a particular area with other vehicles of the network. The rules of relationship management (RM) in SIoV are similar to human social networks. However, the SIoV poses unique challenges because of the dynamic nature of the vehicles and their network topology, device-based social interactions, and security and privacy concerns. Furthermore, due to an emerging domain, not much work has been done in the field of SIoV, which motivates the authors to provide a comprehensive review of trust management in SIoV. Following list highlights the contributions of this article:
Identify the factors affecting the design of a trust model in SIoV environment.
Highlight the major challenges involved in designing an efficient and reliable trust model for a highly dynamic and scalable SIoV system.
Provide an overview of existing trust models in other domains like IoT, SIoT and vehicular networks that have a potential to be implemented in SIoV.
Furnish a perspective on how trending concepts like blockchain and fog computing can assist in developing a trust-based SIoV model for high-efficiency, decentralized architecture and dynamic nature of vehicular networks.
The rest of this article is organized as follows: details of SIoV and its architecture are described in section “SIoV.” Section “Trust management in SIoV” focuses on the SIoV trust management and factors involved in managing the trust. Section “Challenges of trust management in SIoV” emphasizes the challenges involved in the design of an ideal trust management model for SIoV. Section “Existing trust models” presents an overview of exiting trust management models available in the literature. Section “Trending solutions for trust management in SIoV” highlights the trending solutions for the design of trust management model in SIoV. Finally, section “Conclusion” concludes this article.
SIoV
SIoV paradigm advocates to enable social interactions using direct or indirect communication between vehicles, vehicle components, infrastructure, and drivers’ and passengers’ handheld devices. Socializing of vehicles may differ from socializing of humans because of the nature of the interaction, prerequisites for the communication, and type of information. For example, when socializing, vehicles might be interested in information like vacant car parking slots, toll gates, traffic jams, alternate routes, and recovery services that might not be of key interest in human socializing. Figure 1 highlights some of the fundamental interests of SIoV; however, these interests depend upon various factors like context, location, clustering, vehicle type, velocity, road type, and network type.
Socializing in SIoV.
Architecture
The architecture of SIoV is not standardized and is subject to vague comprehensions that are inspired by the existing IoT architecture. The IoT architecture is simplified for sensing, network, and application layers, which have functions of data acquisition, data transfer, and offering middleware services, respectively. 7 However, SIoV is far more complex because of the inclusion of social interactions between vehicles and its dynamics. Therefore, SIoV requires more cognitive and pervasive computing for the effective and reliable provision of services. The SIoV architecture, as shown in Figure 2, identifies both VANET-based short-range communication and cloud-based communication. This section provides a brief introduction of operations of each layer of SIoV architecture.
SIoV architecture.
Data source layer
This layer collects dynamic data from the vehicle’s owner, sensors deployed in a vehicle, and other available environmental sensors. In SIoV, the owner of a vehicle may want to share specific information about him or his journey based on the trust-based relationships, for example, the information is shared to find colleagues and friends traveling on a same route or different people traveling in a rally or convoy may want to share a more personal goal-related information among them. The in-vehicle sensors provide data to sense the environment of the vehicle around it to help improving a journey and driving experience by providing auto-pilot and other auxiliary systems. Furthermore, in some scenarios, it becomes a need for vehicles to directly communicate with each other using short-range communication technology and share data between them based on the trust level, for example, when a smart vehicle sends data on behalf of another vehicle who could not find any other means to send data to the cloud. The environmental sensors sense data in the traffic environment that is helpful to avoid the risk of non-social and non-cooperative vehicles, for example, these sensors provide dynamic information about over speeding vehicles. Furthermore, these vehicles manage the SD to find available services, service composition (SC) to composed services, RM to manage their relationships, and trust management by storing previous experience of other vehicles to calculate their level of trustworthiness in a distributed trust management model.
Gateway layer
This layer consists of different gateway units such as a smart car module, RSU, and other gateways to enable the vehicles and other environmental sensors to send their sensed data for further processing. The smart car module gathers data from in-vehicle sensors and is able to directly communicate with other vehicles to dynamically find trustworthy services. It can also actuate different tasks based on the collected data, such as display the key information to the driver or execute a function based on the configuration to reduce the chances of any accident or long waiting time on the road. RSU provides the infrastructure support for those vehicles that do not have other means of communicating to the cloud. The environmental sensors require either direct communication link with RSU or use specific gateways to send their information.
Network layer
Network layer integrates the gateway layer to the cloud using different communication protocols. The smart car modules, because of their mobility, can use cellular 3G/4G networks or low-power wide area networks (LPWAN) to send their data to the cloud. 8 However, RSUs are static and can even rely on wireless local area network (WLAN) or Wi-Fi or combination of multiple technologies to communicate sensed data with the cloud according to the available networks and the demand.
Cloud layer
The cloud layer provides the required computing and storage for SIoV networks to process and analyze the data to offer trustworthy services. Furthermore, it manages the SD to assist applications to find available services, SC to mashup services to offer a composed service, RM to manage relationships between vehicles, and trust management by keeping track records of vehicles to calculate their level of trustworthiness in a centralized or distributed system. This layer relies on cloud-based technologies to offer virtualized software and hardware to meet the increased demand. 9 Furthermore, it also uses big-data technology to store and analyze massive amounts of data while maintaining the level of trust by preserving the privacy of the system users.
Application layer
The application layer consists of all SIoV-based applications that are based on consuming different cloud services. Some applications are open to most of the users, for example, real-time traffic on a junction. However, some applications could be related to some specific industry whose business model is based on the provision of value-added trustworthy services. These applications offer their own application programming interfaces (API) to offer their services to customers. A vehicle owner can get information and can remotely configure the vehicle’s level of openness and willingness.
Trust management in SIoV
Trust management is a mechanism of establishing a trust relationship between entities. It can be conceptualized in two forms: a process of making an entity trustworthy for other entities and a process of assessing trustworthiness of other entities from the perspective of a specific entity. Trust is considered an integral part of socializing, especially in SIoV where socializing vehicles are mostly foreign to each other. Establishing a trustworthy relationship between the vehicles can significantly reduce the discernment of risk and uncertainty. Trust is normally based on the context, and value of trust might vary in different situations even if participating vehicles are the same.
Trust factors
Trust in SIoV is dependent upon several factors like reputation, context, environment, goals, user expectations, social relationships, willingness to connect and timely evaluation as illustrated in Figure 3. Each factor plays a significant role in the design of an efficient and reliable trust model that can be implemented in a highly dynamic and scalable environment like SIoV. Figure 4 presents a holistic view of typical trust management model in SIoV.
Trust factors for social Internet of vehicles.
Holistic view of typical trust management system in social Internet of vehicles.
Reputation
Reputation is an opinion held by an object (human or machine) about another object. 10 Reputation plays a fundamental role in trust management of almost all the technological and non-technological systems. For example, before issuing a loan or a credit card to an applicant, bank validates the identity and reputation of the applicant about his previous financial obligations. In SIoV systems, trust among vehicles is highly dependent on how the vehicles are handling the information (received from sensors and on-board unit (OBU) and sent to other entities of the system). If information is not handled properly, serious inconvenience can occur. In SIoV, reputation is used to create trust among vehicles that have no prior knowledge of each other and hence use their experience from previous encounters along with the feedback from peers to evaluate the trustworthiness of the vehicles in the network. The system is expected to be responsible for calculating the reputation score for each entity based on its behavior. For example, a vehicle consistently providing accurate information about the traffic will have a higher reputation score than the vehicle that provides false or partially accurate traffic information. One of the key components of reputation-based trust systems is the behavior of the participating entities. The entities with good behavior are assigned higher reputation score by the system than the entities with bad or unpredictable behavior. The reputation score normally depicts the quality of the contribution of the entity to the overall system. In some reputation-based trust systems, the reputation score is calculated by integrating it with the old trust score of the entity. 11
A reputation score of an entity can be calculated directly or indirectly. A direct calculation of the reputation score is subjective in nature that is based on the previous direct interactions of the entities with each other without taking into account the observations of the neighboring entities. However, an indirect calculation of the reputation score is calculated by integrating the previous direct interactions and inputs of the neighboring entities. 12 Moreover, most of the reputation systems are based on positive, negative, and hybrid reputations. In positive reputation systems, the reputation score of an entity is calculated based on the positive behavior of the node. Similarly, negative reputation systems calculate the reputation score on the basis of negative behavior of the nodes. A hybrid reputation system analyzes both positive and negative behaviors of the entity before taking a final verdict on the reputation score. Several models have been proposed to calculate the reputation score of an entity for MANETs, VANETs, IoT, and general networking scenarios that can be adopted for SIoVs.
Table 2 illustrates the major efforts in the literature in this regard; however, the models presented in the literature are still lacking in various aspects like structure, parameters, metrics, and the overall domain of study. For examples, a Collaborative Reputation Mechanism Model 13 is designed for MANETs using decentralized approach by calculating direct, indirect, and functional requirements using compositional and reputational metrics. However, it does not provide the degree of the reputation, for example, positive, negative, and hybrid. Similarly, node reputation model 14 presents the degree of reputation but lacks in providing different parameters like direct, indirect, and functional reputation.
Models for calculating reputation scores.
VANET: vehicular ad hoc network; MANET: mobile ad hoc network; WANET: wireless ad hoc network.
Context
Context is the occurrence of an event or an idea that helps in fully understanding the situation. 19 Trust in SIoV is highly dependent on the contextual information between the vehicles. A vehicle can trust another vehicle in the network under certain circumstances but might not trust it under other conditions. For example, information sharing like “school crossing ahead” from one vehicle to another might be acceptable in urban areas but might not be considered valid information on highways. Similarly, providing speed limit of highways at urban areas might be out of context and can cause serious inconvenience for the drivers and the authorities. Vehicles are expected to trust other vehicles if they get contextual information based on their previous interactions. Time, location, activity, weather, distance, environment, and domains are different context parameters that can be considered while establishing trust between different vehicles. In SIoV, trust can be established based on certain contextual parameters, for example, the location information of vehicles. Some locations are more controlled and monitored than the others, and hence, vehicles in those premises can be caught if behave maliciously. Based on this fact, trust can be assigned to locations rather than vehicles. For example, if trust is associated with a vehicle, it is probable that vehicle A might not have a social relationship with vehicle B again. But in case of associating trust with location, there is a high probability that vehicles traveling in the same location will have more interactions. 20 However, the calculation of trust score based on contextual information is highly dependent on the application. Some applications might require a certain contextual parameter to calculate trust score as mentioned above in the case of location; however, some applications might require calculating trust score for the entities to ensure efficiency and reliability.
Environment
Environment is an external factor that can affect the trust process between vehicles in SIoV. Environment can create an uncertainty in the trust mechanism due to several varying factors like traffic conditions, state of infrastructure, mobility patterns, type of roads, system complexity, scalability, and kind of communication. For example, information sharing between vehicles can be disrupted by loss of communication that results in receiving incomplete information at recipient vehicle. Due to receiving incomplete information, the recipient might not be able to interpret the information as required that might give an impression to the recipient that sender is not sending the right information which would spoil the reputation of the sender vehicle and ultimately the trust. 21
In SIoV, system complexity can be an environmental factor that can affect trust process between different entities of the system. SIoV system should perform the required computations with less complications and high efficiency. In a dynamic environment like SIoV, efficiency of the system is directly proportional to the complication of the system. More complications in the system can reduce the overall efficiency. Similarly, data communication needs to anticipate the available standards and industry specifications in modulation schemes, media access protocols, packet routing algorithms, and services. 21 Moreover, unnecessary processing of data that causes critical delays for the reception of vital driving information should be avoided.
High scalability of SIoV system can be another environmental factor that can affect the trust management of the system. Growing number of vehicles on road escalates associated parameters with each entity of the system, for example, messages, sensor readings, relationships, drivers, passengers and pedestrian details, parking slot details, source and destination details, traffic information, traffic signal information, and data related to accidents. Trust and reputation score in a highly dense vehicular environment requires complex computations, fast processing, effective throughput, and efficient communication to avoid miscalculations. For instance, a vehicle entering an SIoV network might need to establish a trust relationship with other entities of the network by socializing with a decent number of entities to form a good reputation. However, with large number of entities in the system, with each entity sharing a lot of information, it might be challenging for the new entrant to share its information with other nearby entities of the network. Some of these challenges can be Limited Bandwidth (as many entities might be using communication channels at the same time), Information Processing capabilities (of the entity and of the system at large), Delay Tolerance (as many applications might be very sensitive to delays, e.g., emergency services), Calculation of Reputation Score (more the entities in the system, difficult it is to calculate reputation for each entity; especially for new entrant as it requires collecting reputation info of other entities of the network before calculating), and Updating the Trust Scores (stored on each entity and the system). 22 Due to all these challenges, if the system miscalculates the trust score of this new vehicle because of a slight mistake in the trust algorithm, it can spoil the reputation of the vehicle and ultimately the trust of other entities on this vehicle.
Goals
Goals are aims or desired results expected to be achieved by the objects. Goals in SIoV can be accomplishment of anticipated results by sharing information. Vehicles having mutual goals in SIoV can significantly improve the trust between them. For example, a common goal of vehicles in SIoV can be to share the information regarding traffic congestions on the roads to avoid traffic jams. Similarly, another goal can be finding vacant car parking slots in a shopping mall. Achieving this goal can improve the reputation of the vehicles and eventually the trust between them in a V2V communication.
Besides V2V relationship, an SIoV system supports V2I relationship that includes vehicle and infrastructure as participating entities. Vehicle and Infrastructure can have a common interest, and fulfillment of that interest can result in improved trust between them. For example, a vehicle meeting an accident can share this information with the RSU that can ultimately share this information with the authorities for sending the emergency vehicles to catch up with the situation. At the same time, RSU can share this information with other vehicles in the vicinity to avoid traffic jams. In this scenario, both vehicle that met an accident and the RSU have the mutual interest of informing the authorities about the accident. This would help in strengthening the mutual relationship between vehicle and RSU and eventually the trust between them. Besides having benefits, vehicles having comparable characteristics and communal features are normally influenced by similar inadequacy. 22 Manufacturers can benefit by mining the information about these failures shared by similar vehicles; however, heterogeneity and interoperability of SIoV makes it difficult for various manufacturers to operate homogeneously.
Expectations
Expectations of the vehicles are another crucial factor that affects the trust in SIoV. Receiving the expected information will increase the trust between vehicles that can enhance the productivity of the system. Therefore, the trust is influenced by a node’s subjective expectation to predict another node’s behavior. 23 For example, a smart parking application requesting information of vacant parking slots on a roadside from other vehicles is expecting to receive this information instead of receiving discount coupons of a nearby restaurant.
The expectations in SIoV is not limited to V2V relationship only and plays a vital role in V2I, V2P (vehicle to pedestrian), V2S (vehicle to sensor), and I2I (infrastructure to infrastructure) as well. Each entity of the system can have expectation from other entities depending upon the context. For instance, a speed management application of a vehicle on highway would expect to see the speed limitation on a highway from other vehicles and RSUs rather than some other irrelevant information. Fulfillment of expectations would improve the trust of entities on each other. A slight miscalculation from the entities about the expectations from other entities or miscalculation in delivery of expectations can dent the trust of the entities. SIoV is highly active in nature and entities of the system are aggressively socializing with each other at a single instance that associates several expectations with each entity. Hence, the trust score of an entity can drastically change if expectations of other entities are not met. System plays a vital role in keeping the trust score of each entity when it comes to setting expectations from the entities and delivery of expectations. Therefore, a highly efficient mechanism is required to calculate the trust score based on the expectations of the entities.
Social relationships
The social relationships and past social interactions between vehicles, their drivers, passengers and infrastructure impact the trust between vehicles. 24 A vehicle will trust other vehicle more if they had past collaboration to satisfy some application requirements. The past successful social interaction builds strong relationships between objects. This information can be stored at vehicles by creating social relationships information for future interactions. For example, an SIoV application will prefer to rely more on the information provided by vehicles with which the vehicle had past positive experience. The SIoT paradigm advocates such social relationships management. The trustworthiness is also positively affected by social relationships between their drivers. Vehicles in SIoV are required to trust other vehicles more if the other vehicle’s driver is in the social contact list of the owner of the vehicle. For example, if the driver’s social contact list shows that it contains the current driver of other vehicle, then the information provided by the other vehicle will be more trustworthy compared to other vehicles that are being driven by strangers. Similarly, the social relationships between passengers can also be availed to enrich the trust evaluation. The best way to acquire the social information of drivers and passengers is that they share their social relationship information directly with the trust manager. However, there are privacy concerns that can bring potential hurdles in this calculation. Another way could be to gather general social information of the drivers and passengers of other vehicles from different social platforms to get their interest details.
Willingness
The willingness is a crucial factor of social trust assessment for vehicle-to-vehicle communication. The willingness attribute highlights the behavior of a vehicle regarding sharing information. 25 This aspect explains the past active contributions of a vehicle to help other vehicles to meet their application requirements. The success of SIoV is based on socializing factor, because more social interactions will enable vehicles to get benefit of the paradigm. The willingness to collaborate and fulfill the information needs of other vehicles helps a vehicle improve its trustworthiness. For example, if a vehicle is actively contributing to the provision of services in an SIoV environment, then applications will rely more on the information provided by the vehicle compared to other vehicles. Therefore, trust of vehicles improves with its willingness to share information with other entities. However, the willingness factor is not just based on number of interactions, but it covers more precise and fine-grained information about the vehicle’s contribution in the provision of services required by other vehicles. Concisely, the principle will work to negatively impact a selfish vehicle’s trust. This factor motivates vehicles and drivers to share information to increase the reliability of SIoV. The willingness assessment requires information that can be either gathered from other vehicles or RSUs.
Timeliness of evaluation
The vehicles in an SIoV environment need to evaluate the trustworthiness of each other in a reasonable time to fulfill requirements of different applications by consuming shared information. 26 The evaluation of trust can be done at different times with the available information and the requirements of applications. The evaluation process consists of two stages: pre-evaluation, vehicles assess the trustworthiness of each other based on the available context information and their experience, the post-evaluation is based on the results of the task performed and the environment. The pre-evaluation depends on the architecture of a trust management system. The centralized cloud-based information provision system will be impractical for many applications, because of the latency and scalability issues. These systems are key in scenarios where the evaluating reputation is challenging due to scarcity of information. For example, if only two vehicles are traveling in an area for the first time and they want to evaluate trust of each other to fulfill the requirements of an application, then only centralized system can provide the required information to aid the evaluation. The distributed system has its merits of scalability, but the vehicles will have to either depend on RSU-based or V2V-based communication to get information for evaluation.
In some cases, the full trust evaluation might require time that might not be feasible for Quality of Service (QoS) requirements of an application. 26 Many applications in SIoV will be delay-sensitive and will require real-time data that can be affected by the evaluation time. Therefore, the trust evaluator will have to take into account the time required for evaluation to provide the timely assessment of the trust for such applications. In the post-evaluation, vehicles measure trustworthiness based on the results of the task performed and the environment. For example, while helping an application, a vehicle does not provide valid information to peers in the network; post evaluation of trustworthiness of other vehicles for this vehicle might result in bad reputation. In future, based on this bad reputation, the other vehicles might not trust this vehicle for sharing information.
Challenges of trust management in SIoV
The social relationships between vehicles enable wide array of applications for vehicles that can significantly enhance the organization of traffic on roads. However, socializing largely depends upon trust of entities on each other. Several trust models exist for IoT; however, not many trust models are available in literature for SIoV because of several challenges posed by SIoV due to its nature and operations. This section highlights the core challenges faced in designing the trust model for SIoV systems.
Architectural choices and deployment
The decision to choose between the available architecture choices for trust management in SIoV is difficult due to the challenges involved in each choice. 22 The lack of an agreed standard for storing and maintaining trust-based profiles of vehicles and other entities is key for effective and efficient deployment of an SIoV system. The available architectural choices are centralized and distributed. The centralized architecture creates, stores, and updates all trust-based information in the cloud infrastructure. Any vehicle that needs to get trust information about other entities will be required to request for information from the cloud. This architecture assumes that the cloud has enough computing and storage resources to offer reliable backup systems. Another assumption that the vehicles will be connected to the cloud anywhere and anytime demands very high availability of the communication systems. 27 However, the major limitation of such architecture is scalability because of the dynamicity of SIoV-based networks. For example, during peak hours, the number of requests from vehicles to the cloud to get the trust-based information about other vehicles in the network can take way longer than expected time. This situation is further aggravated when the same process will be repeated due to high mobility of the vehicles. However, the distributed architecture puts more burden on the vehicles to compute, store, and manage the trust-related information. 28 In the distributed architecture, if a vehicle does not has any trust-related information about another vehicle, then it should try to get that reputation information from other vehicles around it. The collected information is then analyzed by the vehicle to compute the trust itself. This poses an overhead of communication to keep the trust-related information relevant and up-to-date, as this information might need to be updated at every turn on a highway. Furthermore, a vehicle can only store information about a limited number of relevant vehicles in a context. The architectural choices expect unique roles and functionalities from different entities of SIoV that poses risks for its deployment, as there is no clear standard or agreed framework is available.
Scalability
SIoV should be scalable enough to support diverse services with varied quality-of-service (QoS) requirements even during busy periods. 26 The QoS requirements for SIoV applications vary, but there are many safety and other applications that are delay sensitive. An SIoV system is expected to support these applications by responding to their requests in a due time. SIoV is a network of different entities like vehicles, drivers, passengers, and infrastructure. The number of vehicles in an SIoV network changes dynamically and has potential to surge to a considerable level. This also increases the number of foreign (new) relationship between the vehicles. Consequently, new entities entering the network must develop their trust relationships with other entities. An SIoV system is expected to maintain its stability, efficiency, and functionality with increasing number of vehicles. 21 However, a sudden surge can affect the overall network performance of the communication technology that might result in inefficient data delivery and errors in communication. For example, the traffic can see a sudden flood of vehicles because of a football match in the area. As a result, the jitter in communication can become the root of user dissatisfaction. Moreover, incomplete or delayed data might result in spoiling the reputation of the entities and eventually the trust between them. The scalability is strongly related to the architecture of an SIoV trust management system. However, both centralized and distributed architectures may face this issue. The centralized architecture can result in increased delay and distributed architecture must deal with limited resources of vehicles as it is not feasible for them to store and update trust information of all the vehicles they had interacted.
General reputation and local knowledge
Reputation is considered one of the principal factors affecting the trust in SIoV as discussed in the previous section. Several reputation systems are available in the literature; however, no standard reputation system model is crafted for SIoV, which makes it challenging for the entities to trust other units in SIoV systems based on reputation. 12 Furthermore, the reputation of an entity is expected to change swiftly in SIoV due to dynamic nature of the system that requires frequent updates to the general reputation of the entity stored in the cloud. Trust model should be effectual and prompt enough to refresh the reputation of the entities in the allotted time window. As mentioned earlier, the reputation of an entity in SIoV is highly dependent on the context. For example, a vehicle might have a good reputation when it comes to providing traffic information; however, it might have a bad reputation while providing the vacant car parking information. Besides contextual information, reputation depends upon many other factors like number of associations, previous interactions, quantity and quality of information, and vehicle willingness to share information. In order to design a trust model for SIoV, all these factors related to reputation should be considered to efficiently estimate the reputation score of the entity. However, due to dynamic topologies in SIoV, substantial number of participating entities, requirements of high processing and substantial data storage, and rapid change in the associations due to high speed of vehicles, calculating reputation score is very challenging and requires an efficient algorithm, high computing environment, and fast processing resources. 11
SIoV supports centralized and decentralized architecture as mentioned earlier. In a traditional centralized architecture, maintaining trust is manageable when it comes to resources as cloud can provide virtually unlimited storage, high processing, and fast computing. However, centralized architecture has its own challenges like scalability. In a decentralized SIoV architectures, local storage of reputation systems at entities can expedite the entire process of trust management; however, due to limited storage and computing and processing resources, the whole reputation system cannot be localized. Nevertheless, SIoV embraces the sharing of resources; hence, entities are encouraged to communicate with other units in SIoV to keep themselves updated about recent trust information. Although centralized and decentralized architecture have their own pros and cons; a hybrid system can benefit from the advantages of both the models. However, this approach is still in its early stages of research and requires a lot of work before the actual implementation. 29
Context awareness
The context of vehicles affects a lot the way they evaluate trust. The trust model needs to be context-aware to effectively evaluate the trust for an entity. In SIoV, the dynamicity invalidates context and the trust model should address this aspect of carefully analyzing the validity of any context attributes. The context is multifarious and depends on various attributes such as preferences and social relationships of the vehicle’s owner, vehicle’s model, time, location, and the service in question. 30 The current location of a vehicle and the type of service it is looking for play a key role in changing the trust level. For example, if a vehicle is trying to evaluate trust for a service where only one vehicle is in the surroundings, then it can increase the trust value based on the urgency of the scenario. A reliable trust model needs real-time context information to adapt to the requirements of a service request that are more challenging to maintain in SIoV. Similarly, an emergency vehicle approaching an accident site to carry the injured driver to hospital might request the nearby RSU to provide the fastest route to the site. However, if RSU provides the information of the fastest route based on the traffic situation of the last week, the information might be different due to change in the date and time, and this out-of-context information provided to the emergency vehicle might result in hazardous situation. Furthermore, the out-of-context information provided to the emergency vehicle would result in losing the trust of the vehicle in that RSU.
Trust calculation in SIoV requires comprehensive contextual information which is a challenge due to scale and dynamicity of SIoV system. Contextual information itself is quite complicated due to wide range of factors involved, for example, location, time, system reliability, communication technologies, vehicle speeds, area, type of roads, kind of relationship between vehicles, routing protocols, driver information, and traffic information. SIoV system requires data analysis based on contextual requirements of application and services to ensure that unnecessary and redundant information is eradicated. However, in an enormous system like SIoV, where entities are generating tremendous amount of data at each instance, filtering of redundant information in a short span of time is quite challenging. Furthermore, besides filtering of information, data transmission to and from different entities of SIoV systems, for example, vehicles, infrastructures, pedestrians, and cloud, requires a delay that is currently unavoidable due to limitation of communication technologies. Similarly, in order to provide trust score of each entity to the other entity, the system needs to collect, process, and communicate this information in a very short interval of time due to dynamic, mobile, and heterogeneous nature of SIoV system which is very challenging. 20
Social relationships
The SIoV paradigm advocates idea of exploiting the social relationships among devices by adding friendship dimension to IoV. 3 Therefore, an SIoV-based trust management system should leverage the available social relationships between vehicles while evaluating the trust between them. However, the methodology of using these relationships in trust evaluation is challenging to define because of the availability and reliability of the social relationship information. A trust evaluation model needs reliable information about the social relationships of devices and their owners to effectively measure trust between two entities. The reliability of these relationships is quite a challenge to determine. For example, a vehicle wants to determine whether to trust information from another vehicle that is being driven by a social contact of its owner. The level of trust will have to be determined by its owner, as not all contacts in the social contact list are equally reliable. Human beings are connected through the online social media or communities based on common interests where they make friendships and develop trust for those relationships by sharing their personal data. However, the vehicles in SIoV create and maintain social relationships based on common owner, manufacturers, functionalities, services, and the quality of their measured data. 31 Furthermore, the indirect relationships, such as a friend’s social contact, can increase the trust between two devices. These social relationships among vehicles are dynamic, required to be updated, and are needed to be stored by a vehicle to improve its trust evaluation efficiency. The capability of a vehicle can become a constraint in processing, storing, and updating this social relationship–related information. For example, if a vehicle has already used its memory and is unable to store information related to the new social relationships, then system should have a way to determine how and where this information will be stored. The challenge is to come up with an opportunistic mechanism that can aid the trust evaluation based on whatever social information is available.
Dependability
Dependability comprised of multifaceted warranties of high availability, efficacy, timeliness, reliability, and security of the system. 32 The availability and reliability guarantee the resilience of the system in case of any fault or failure. The security warrants the safety by only allowing the authorized usage of the system. The efficacy and timeliness confirm that the system will always be able to provide service with a required level of QoS. For example, a vehicle will require determining the trustworthiness of other vehicles in real time if the application is delay sensitive. All these requirements put more tight deadlines for trust evaluations in a highly dynamic SIoV environment. In SIoV, the social relationships and other context attributes keep on changing at a great pace that require information to be updated and pre-fetched before these are requested. The validity of already calculated trust evaluation also needs to be verified. For example, a vehicle has calculated trust for another vehicle a week before should it recalculate the trust or use the same value. The validity period may depend on different context information such as type of road the vehicle is traveling and kind of application that requires the information. The challenge is to design such a smart strategy for an SIoV trust model that adaptively uses the available information to evaluate trust within acceptable probability depending on the context. The adoption of SIoV by a society is reliant on the level of dependability that its people perceive of the system. Therefore, it is indispensable to address the dependability of SIoV.
Privacy
Privacy is essential in the deployment and acceptance of SIoV systems. 33 Therefore, a trust management model should adhere to strict privacy policies to preserve privacy of users. SIoV entities share information among them and with the system’s cloud infrastructure. Due to the nature of SIoV, it is prone to several privacy issues like, location tracking, identity stealing, false information advertisement, personal information leakage and relationship disclosure, etc. From the trust management perspective, the attacks on privacy, for example, information leakage, can damage the reputation of the entities that can result in spoiling the trust relationship between them. Furthermore, the data generated by vehicles in SIoV have potential to divulge information about the social behavior of vehicles and their owners and interests that will potentially have great commercial value. Therefore, the challenge is to make sure that the privacy of SIoV users will remain intact.
A trust management model relies on information such as context information shared by vehicles to establish trust among them. To address privacy concerns, a SIoV trust model should clearly define information requirements for establishing trust in diverse scenarios. For example, a vehicle will have to share context information about its location to develop trust with other vehicles for safety application, but its driver information should not be disclosed in anyway; even if some application tries to collect driver information that is not eligible to do that based on its context, system should be able to warn the respective entity. The social relationships between vehicles can also influence the decision of what information should be shared. For example, a vehicle may be more open to share information with another vehicle that is being driven by its owner’s colleague or that regularly travels on the same route. It is more challenging to preserve privacy for the trust models that rely on information shared by vehicles in the vicinity. For example, a vehicle might not have any other peers in the vicinity to get trust information about each other. The only possibility left is to share some information to show willingness to establish trust relationship and consequently get the required information. The key challenge for a trust model remains to determine how much and what kind of information a vehicle should share in this scenario to establish trust? The other vehicle might be a greedy peer, may refuse to share information and misuse the acquired information from the vehicle. Although a system that preserves the privacy of information sharing hosts has been proposed, 34 it mainly focuses on the Internet hosts which report unwanted traffic, like malwares, advertisements, and spam, in a network. Moreover, parties managing cloud and fog units may disclose the confidential information about vehicles for commercial purposes. Also, other vehicles in the social circle of a vehicle can reveal its personal data such as identities, our trusted social circle, favorite relaxing spots on highway (where we can stop to have our breakfast each morning), our habits about how we manage our vehicle (e.g. after how long we take the vehicle for service), current state of our vehicle (e.g. oil condition, and fuel amount,.) to name a few.
Trust-related attacks
SIoV due to its enormous volume might be affected by general-security attacks like jam attack, false-attack, and reply-attack that can significantly affect the overall security of the system. However, in order to overcome such attacks, several techniques are available in the literature; one of which is presented in Fu et al. 35 that can be implemented on SIoV as the model is developed for vast heterogeneous IoT networks. Similarly, attacks like Man-in-the-Middle, impersonate, domain attacks, and distributed denial-of-service (DDoS) attacks can cause serious inconvenience to the entities of SIoV systems and hence require strict security. Several security solutions are available for similar domains like D2D in IoT that are applicable on SIoV and can enhance the overall security of the system. 36
Beside security attacks, an SIoV-based trust management model is susceptible to various trust attacks. A trust evaluation considers the feedback and reputation of a vehicle and its individual services that can be affected by various kinds of attackers. 37 The self-promoting, ballot stuffing, and whitewashing attacks try to improve the reputation of a vehicle and its services by self or group promotions. Some attacks negatively affect the reputation of a vehicle such as badmouthing and discriminatory attacks. The opportunistic service attacks are challenging to identify because it is difficult to predict the behavior of an attacker who is improving its reputation to be part of good or bad-mouthing attacks. The trust model should deal with the new entrants to the SIoV and employ a strategy to evaluate their trust. It is an arduous task to build profiles of different vehicles and predict their intentions in the context of millions of vehicles with a web of social relationships to take precautionary measures to avoid such trust attacks. However, a reliable trust model needs a safeguard to deal with these attacks.
When defining trust for new vehicles, there are two approaches that can be followed: either assign a default trust value to each newly coming vehicle or let them share information and eventually earn a trust value by themselves. The former scheme is susceptible to whitewashing attacks in which a malicious vehicle which has very low trustworthiness based on its performance may disappear from the network and try to join the network with a new identity, hence having default trust value which is higher than its original trust values earned with previous identity. The later scheme may lead the vehicles to share their personal information in order to gain trust from other vehicles on the road.
Trust of a vehicle can be measured based on its honesty, its willingness to cooperate and socialization with other vehicles, and community interest. 38 Honesty shows whether a node is honest while providing the requested information. The willingness to cooperate and socialize represents how much the vehicle is ready to dedicate its resources to help the requester. Community interest represents how close the trustor and trustee are related to each other, for example, same location, same manufacturer etc. When computing trust for a vehicle, all the above-mentioned parameters should be given equal share in the trust calculation in order to avoid any misuse of the weaknesses of trust computing algorithms. For example, a malicious vehicle can show higher level of cooperativeness with other vehicles and has a large community circle, whereas at the same time it is not honest when sharing information with other vehicles.
Some trust models like proposed in Nitti et al. 39 rely on the trustworthiness computed by the nodes about their immediate peers based on their own experience with them and recommendation received from their friends. The higher the trustworthiness value, the more trustworthy will be the node. Good mouthing and self-promotion can help the malicious nodes to increase their trust values in such scenarios. Moreover, bad-mouthing about legitimate nodes can decrease their trust levels, and consequently increasing the trust level of malicious nodes. It is challenging for the trust models to identify and exclude good mouthing and self-promotions in order to calculate precise trustworthiness.
Heterogeneity and interoperability
An ideal trust model should consider the diversity of vehicles and types of different possible data formats in SIoV. The wide range of vehicles from different manufacturer is supposed to have varied level of constraints. Some of these vehicles will have constraints in terms of energy and computing power and others might have limitations in storage and communication capabilities. 40 Besides these constraints, each entity of the SIoV system might have different services, for example, some vehicles might offer vacant car parking information, while others might offer upcoming toll gate information. The trust model required to be aware of the capabilities of heterogeneous devices and variety of data types to consider these during the trust evaluation.
Each entity of the SIoV system might require incongruent communication means and is capable of engendering discrete type of data. For example, in a V2V communication, vehicles supporting DSRC might not be able to communicate with each other if data sent by one vehicle is unrecognizable by another vehicle due to different data format and compression and encryption techniques, used by the manufacturers of the vehicles. Similarly, a high-beam sensor reading sent from vehicle A might not be understandable by vehicle B due to the absence of high-beam sensor in vehicle B that makes vehicle B incapable of computing and hence processing of this information. This incapability of vehicles to communicate or respond to queries of other vehicles due to heterogeneous nature and non-interoperable character might result in loss of trust. Hence, a trust model is required that enables heterogeneous entities of SIoV system to socialize with each other that can ultimately result in enhanced trustworthiness of these entities.
Quality of service
Quality of service (QoS) 26 is achieved by meeting the requirements of variety of services to ensure the quality of experience (QoE) 41 of SIoV users that leads to better adoption of the system. A vehicle in SIoV can discover many related services to complete a task and needs to select the most trustworthy service. However, QoS in SIoV is dependent on many factors like mobility, communication, application requirements, and traffic density. For example, a security personnel application that requires processing of videostreaming data to recognize the drivers to catch a fugitive on road will have a requirement of real-time processing of videostream through a service along with face recognition. Such applications require high QoS to avoid miscalculation that can lead to serious inconvenience for drivers and vehicles on the road and ultimately distrust of drivers on the system.
QoS-based trust helps the vehicle to consider the service reliability, competence, and efficiency as part of the trust evaluation. The task to get accurate information about services is time-consuming for the SIoV. However, the trust model will need this information to ensure that it will consider very specific attributes for each service to offer the required level of QoS.
Mobility and unpredictability
High mobility in SIoV is one of the key factors that makes it different from other peers like IoT and SIoT. Vehicular networks in general have this tendency of dynamic topology change that makes it difficult for the system to manage relationships between entities. For example, vehicle A might be a neighbor to vehicle B on a highway at one instance; however, this neighboring relationship might change quickly if vehicle A takes an exit from the highway. This changing relationship or association of vehicles on road can affect the trust of vehicles on each other due to high mobility. Besides changing network topology, mobility in SIoV can affect the overall processing, computing and communication capabilities. Trust management relies on fast processing, efficient computing and reliable communication capabilities of the system to deliver trust-based information to the entities without any delays. A slight delay in data delivery in delay-sensitive SIoV applications can be hazardous. For example, an ambulance carrying a critical patient to the hospital requesting a RSU about the traffic congestion based on its trust on RSU requires the information at brisk speed. However, if RSU does not provide this information on time and by the time RSU communicates this information to the ambulance, it might be stuck in the traffic that would result in loss of precious life. Several mobility models like random pattern and graph constrained are proposed in literature; however, these models do not reflect real behavior of traffic pattern, for example, some ignore real-time traffic, and others do not take into considerations the road intersection, traffic lights and pedestrian movements. Hence, a trust model is required based on a concrete mobility method that can manage the relationships, calculate reputation score, develop trust rating, and timely deliver this information to all the participating entities especially in delay-sensitive applications of SIoV system. 42
Unpredictability reflects the nature of vehicles in SIoV and adversely affects almost all other challenges. Many vehicles on the road are predictable to follow certain routes every day, but they tend to be unpredictable in many scenarios. For example, a vehicle traveling every day from the same source to the same destination is expected to take the same route. However, due to some maintenance issues, vehicle might take a different route to visit the nearby repair shop. This unpredictable behavior of the vehicle can adversely affect the trust of the system on vehicle. Consequently, the trust model cannot fully rely on the predictions of the system to identify such behavior. An SIoV trust model will be prone to produce unreliable evaluations by using the invalid information and must be able to overcome this issue while meeting the deadlines.
Ethics
The trust management model also requires addressing different socio-technology-based ethical issues. Besides all positive aspects, the trust model needs to ensure several critical points from social and political dimensions. The people will certainly be reluctant to share the personal data to avoid the feeling of paranoia, as their shared data could be potentially used and sold by corporates. An SIoV trust model will have to enable the acceptability of a system by providing elevated level of trust with the comfort, incentive, and freedom a society will gain from it. However, SIoV faces several ethical challenges like efficiency of SIoV system, privacy, inaccuracy of disseminated information, contextual data processing, unclear purpose of data collection, liability, all-time monitoring environment, system reliability, right of information dissemination among other peer entities, distributed control, use of collected data for advertisement, and fairness in resource allocation. All these ethical challenges in SIoV can affect the overall trust of the entities on the system and vice versa. For example, toll collection systems on highways authenticate vehicles through radio-frequency identification (RFID) stickers on their windscreens. In order to fetch available toll balance information from cloud, these systems require low latency due to high speed of the vehicles. Even a slight delay in fetching the toll information from cloud might result in serious traffic jams at highways and in some cases might result in severe accidents. An SIoV system should be efficient enough to avoid latency issues to gain the trust and confidence of different entities of the system and would hence avoid ethical concerns of the system inefficiency. Similarly, a speed monitoring camera capturing vehicle speed, vehicle registration number, vehicle details, and driver details might share this information with other companies, and those companies start sending advertisements to drivers based on this information will be unethical as the system has not taken a consent from the drivers. Such ethical concerns can seriously dent the trust of vehicles and drivers on the system. An ideal SIoV trust model needs to ensure its immunity against the big faults, cyber-attacks, privacy breaches, and information selling. 28
Existing trust models
Several trust models exist in literature for VANETs, MANETs, general vehicular networks, SIoT and broader IoT networks. Although most of the existing trust models are specific to their domains, some of the trust models have the potential to be implemented on SIoV in general. This section highlights the most suitable trust models that have a decent realization for SIoV networks. Table 3 presents the mapping of factors associated with the trust in SIoV and existing trust models, frameworks, and architectures as per the opinion of the authors of this article based on the review of literature. The trust factors are categorized further in reliability, quality of service (QoS), robustness, and social trust.
Mapping of trust-associated factors of SIoV and potential trust models.
IoT: Internet of things; SIoT: social Internet of things; VN: vehicular networks; VSN: vehicular social networks.
Currently, not many trust models are available in the literature that are specifically proposed for the SIoV networks. The authors in Gai et al. 24 proposed a Ratee-based Trust Management (RTM) system, where each entity of the system keeps its own reputation score collected from other entities during the previous interactions. Furthermore, the authors have proposed a reliable Certification Authority server to ensure fairness and robustness of the trust information. The presented model utilizes the relationships between the diverse entities of SIoV and calculates the reputation score of the entity at the ratee level instead of rater level to enhance the reliability of the trustworthiness. The results of their experiments exhibit high-speed information propagation and success rate as compared to rater-based technique. Furthermore, timely evaluation while calculating trustworthiness for the proposed model meets the demand of vehicular networks. However, this model does not take into consideration the contextual information which is significant to highly mobile environment like SIoV as context changes rapidly in such environment. Furthermore, privacy aspect has not been addressed in this model which is considered imperative when it comes to sharing personal information like driver details, vehicle details, and passenger details for calculating trust. Another trust model for VSN is proposed by the authors 43 that considers the trust principles for admission of an entity to a particular social group. The proposed model is probabilistic in nature that determines the probability of wrongful admissions of an entity in a social group. The mathematical analysis and simulation results of this work validate its aim to minimize the impact of malicious behaviors of the nodes in the social vehicular network. The proposed model could form social groups of entities having common interests (goals) and calculate an accurate trust evaluation of their behavior. Although the proposed model accurately calculates the trust, it lacks the calculation for dynamic behavior of vehicular network as the changes in the network at real time are not considered while calculating the trust. This inability of the model to dynamically calculate the trust of the entities makes it difficult to be implemented for SIoV systems as relationship and trust management in SIoV systems are highly ephemeral in nature.
Kamesh and Priya 44 have proposed a trust management scheme for identity anonymous vehicular networks to assure privacy. In order to evaluate the trustworthiness of the received data, the proposed scheme detects false location and time information provided by the entities of the network. The scheme operates in three phases. In the first phase, the entities calculate the confidence score of the message received from other entities about specific events. In the second phase, trust score for each received message for a particular event is calculated. Finally, in the last phase, the decision to accept a message with highest trust value is taken. The proposed scheme takes into consideration the context and complexity of the system to provide an efficient way of calculating the trust score for the entities. However, the proposed model does not consider the memory, processing, storage, and energy limitations of vehicular networks. The authors have proposed their model keeping these factors constant which is not the case in real-time vehicular networks. For example, in some cases, vehicles are not capable enough to process all the three steps mentioned in the allotted time due to low computational OBUs. Similarly, the authors have not taken into consideration the security and privacy factors which are one of the key factors in MANETs considering the broad spectrum of communication in such networks. Another model 45 based on Message Propagation and Evaluation takes into consideration environmental factors like system efficiency, complexity, and scalability to calculate the trust of entities. In this model, entities not only share information regarding road traffic, rules, speed limit or safety but also provide their estimation of information trustworthiness of other entities. The model enables peer entities to evaluate the information in a decentralized and cooperative manner by considering others’ opinions. Furthermore, the model effectively demonstrates defense against malicious messages and achieves an elevated level of scalability and effectiveness. However, the proposed model is effective only for a less dense vehicular environment and might not work for highly dense environment as authors are considering only few road parameters, but in real-life scenarios, road consists of several complex parameters. Some of these parameters might be operating communication channels in the vicinity, interpretation of various environmental sensors on road, and vehicular interpretation of received information. Similarly, the manuscript does not provide a detailed information of how the model would react to more sophisticated attack models like peer collusion attacks which is considered a future work for the proposed model.
Situation Aware Trust (SAT) 46 Architecture presents an architecture for highly dynamic environments to build trust among vehicles using three main components: attribute-based policy control, a proactive trust, and an email-based social network trust. The proposed architecture enables the setup of a decentralized trust framework that is best suited for vehicular networks. The deployment of SAT utilized cryptography, data trust, security policy enforcement, and social network trust, through a unique set of attributes for each entity of the network. The presented trust architecture employs social relationship between different entities of the vehicular network to establish trust in addition to cryptography-based trust management solutions. However, the model is more of a theoretical model and is missing the actual implementation in the real-life scenarios. Furthermore, the article does not tackle the privacy issues in a comprehensive way in developing a trust model for vehicular networks which is considered a key component of any trust management model. The proposed model only tackles privacy issues using the same model followed by traditional email privacy which might not be applicable on vehicular networks due to peculiar requirements of such a network, for example, high dynamicity, fast processing, rapid topology changes, and substantial number of participating entities. Similarly, an Attack-Resistant Trust (ART) management scheme 6 is presented for vehicular networks that handle security attacks and estimates the trustworthiness at both data and entity levels. The presented trust management model is claimed to be applicable to a wide range of vehicular network applications. In order to enhance road experience, it provides safety information to drivers on road, manages mobility at entity level, and protects against different environmental factors that can ultimately develop a better trust relationship between the entities. Furthermore, the model assesses trust at function and recommendation level that reflects how likely a node can behave as expected by fulfilling its functionality and how trustworthy are the recommendations of the entity about other peers. Although the proposed scheme handles the security attacks well in vehicular networks, it focuses on only three types of security attacks, namely, Simple Attack, Bad Mouth Attack, and Zigzag Attack. There are several other attacks that pose serious threats to vehicular networks, for example, DDoS, peer collusion attacks, timing attack, and Sybil attack, which are not covered in this manuscript. Furthermore, the authors have taken an assumption of RSUs being safe; however, most of the times, RSUs are affected by the security breaches from vehicles on road. The authors in Yang et al. 16 discussed the approach of cluster heads (CH) that are responsible for intra-cluster trust management. The authors introduced a trust-based anomaly detection scheme for intelligent vehicles on roads. The scheme enables the vehicles to detect abnormal vehicles and communicate this information to CH. A cluster-based trust evaluation algorithm that adapts Affinity Propagation Clustering is used to elect the most trustworthy CH based on evaluation. The scheme presented in the article uses reputation and willingness of the entities of the network to produce an efficient and robust trust management method. However, the model does not consider the overhead of calculating the trust management of CHs that requires extensive calculations which might not be possible for all the participating entities of the network due to their limited computational capabilities. Furthermore, the deployment cost for the proposed scheme is expected to be substantially high due to distributed servers and large number of RSUs required for calculating the historical reputation of the entities for better decision making.
To effectively manage trust in SIoT environments, few efforts in literature have included the social perspective in the equation of trust computation. One of the first distributed trust management protocols for SIoT 37 considers the social relationships between the device owners. There are three trust factors considered by the protocol: honesty that is determined by a node’s experience, cooperativeness based on the number of common friends, and community interest to reflect the degree of similar capabilities or common interest. However, the context information is not used by the protocol, which is essential to be considered in these environments. Nitti et al. 39 propose a subjective model for trust management in SIoT environments. The trust value is computed by each node based on its own experience and opinion of other common friends with the specific service provider. It also considers the relevance of transaction, willingness of a node by measuring its centrality, capabilities of a node as context information, and social relationships in the trust evaluation. The post-evaluation feedback system is also utilized to record the credibility and centrality of a node for future evaluations. In Atzori et al., 47 the author defines an objective trust model and employs the subjective model of Nitti et al. 39 The objective model provides a network-level view of trustworthiness of a node by storing trust information of each node in a Distributed Hash Table (DHT) managed by Pre-Trusted Objects (PTOs). Each node can query the DHT to get the trustworthiness information about other nodes. The PTOs ensure that malicious nodes will not be involved in the provision of the information. Furthermore, the PTOs will calculate the new trustworthiness values after each transaction and take into account the source of the feedback to avoid fake feedback. The effort assumes that these PTOs will not provide any services themselves. Even though the trust management is dependent on PTOs, the provision of such PTOs in SIoV environment is not addressed.
Another effort 48 proposes a centralized trust management protocol that stores reputation information in a central reputation server. This protocol considers the same owner social relationship to assign the base reputation to a new entrant in the system. Each node uses its credit to get services. The feedback is also used by the system to give credit to nodes and update the reputation information. However, this effort only considers owner relationship and ignores the other essential trust factors based on diverse social relationships. Authors in Truong et al. 49 proposes a centralized architecture to provide reputation, recommendation, and knowledge-based trust management of SIoT. The reputation is used to record the global opinions on the trustee, and the recommendation represents the opinions of the surrounding nodes. The knowledge is the information provided by the trustee to evaluate its trustworthiness based on trust factors: honesty, cooperativeness, community interest, and experience. However, the authors have suggested to use fog-based semi-distributed architecture to deal with the scalability issue, but its details are not covered. Furthermore, many trust factors and social relationships are overlooked by this effort. Similarly, Jayasinghe et al. 50 employ only recommendation and reputation of Truong et al. 49 to propose a distributed trust model. They have redefined the recommendation to be the opinions of social contacts and reputation as the opinion of other nodes in the network. However, the knowledge factors are not included in the trust computation because of their objectivity.
The study by Chen et al. 51 proposes a distributed trust management model that focused on minimizing computation and convergence time and maximizing application performance. The model considers three kinds of social relationships: direct friends list, list of frequently visited locations of social contacts, and experience list of nodes that the node has previously interacted. The design of model can also dynamically adjust weights of different trust factors in response to requirements of an application. The authors also simulated trust-based SC with and without constraints to assess the gains of the adaptive behavior. However, this model lacks the integration of reputation and willingness trust factors that are crucial to deal with advanced trust-based attacks. Another effort 52 employs the similar adaptive behavior to enhance a variation of an existing trust model. 47 This effort takes advantage of DHT-based data storage to store the trust-related information. An effort 53 proposes a trust model that is tailored for SIoT environments. It advocates that trust updates should consider the context and both trustee and trustor should do post-evaluations. The model also asserts that trustworthiness should be service-based instead of node-based and proposes conditional transitivity of trust. However, the effort lacks the detail about the weight of diverse types of social relationships among nodes. A theoretical trust model proposed in Truong et al. 54 considers three dimensions of trust: ability is concerned with the capability of a trustee to complete a task, benevolence is related to willingness and cooperativeness of a trustee, and integrity explains positive reputation of a trustee. The model covers the theoretical detail of different trust factors related to these dimensions. However, the model does not define social relationships-based trust factors, as it only abstractly mentioned social groups in reputation calculation.
The SIoT-related existing trust management models partially consider the utilization of social relationships to enhance the trust evaluation. However, the potential of using available social relationship information for trust management in an SIoT environment is still underutilized. Moreover, these efforts do not consider the dynamic properties of SIoV environments that can impact the efficiency and reliability of the existing SIoT-based models.
Trending solutions for trust management in SIoV
SIoV is an emerging field and has an immense potential when it comes to design and development of safety and non-safety applications for vehicular networks. However, trust management in SIoV is a critical issue that needs to be addressed as it can affect the overall performance of the system. Advent of smart and connected vehicles can improve the performance of the system by taking autonomous decisions without intervention of humans; however, these connected vehicles need to develop trust on each other before collecting information from their peers so that a reliable decision is made. The trending solutions are expected to set a foundation for future research in trust management of SIoV as they have potential of improving the efficiency, reducing latency, enhancing reliability, and finally the security and transparency of information.
As mentioned in the earlier sections, some efforts have been done to develop a trust management model for SIoV; however, this area is still open for research and hence can be improved by further utilizing the current state-of-the-art technologies such as Blockchain, Big Data Analysis, Artificial Intelligence, Network Security, Tactile Internet, and Fog Computing. Researchers in this area can benefit from these trending solutions to develop trust management models for SIoV that can assist in design of safety and non-safety applications for vehicles on road. This section provides a brief overview of two of such technologies, Blockchain and Fog Computing, along with a description on how these technologies can assist in developing a trust-based SIoV model for high-efficiency, decentralized architecture and dynamic nature of vehicular networks.
Blockchain-based trust solutions
According to Gartner’s report of 2017, blockchain is one of the most hyped technologies these days with massive use, applications, and adoptions. Fundamentally, blockchain is a distributed ledger system that offers a decentralized, trusted, secured approach to information and transaction sharing among stakeholders instantly with no intermediaries of centralized authority. 55 The blockchain is composed of a chain of blocks, whereby the header of the new block has the hash of the content of the previous block. This is the reason that data and transactions stored on the blockchain ledger are immutable and cannot be changed once stored into the ledger. Blockchain is the technology engine of today’s cryptocurrencies such as Bitcoin and has been successfully deployed in several transaction-related business applications including banking, insurance, property, logistics, food safety, and others due to its purported ability to validate in real time the authenticity of products and services.
In addition, it is possible to program the blockchain with smart contracts.56,57 Smart contracts are essentially code or algorithmic logic that get uploaded and run on the Ethereum blockchain network. In the context of SIoV, we envision the use of permission-less blockchain where it can be accessed by all parties; however, the access to the infrastructure elements as that of RSU, the cloud data, and InterPlanetary File System (IPFS) is governed through smart contracts. IPFS is basically a peer-to-peer distributed file system that is accessible by all. 55 The IPFS allows the storage of data in a decentralized and distributed way. IPFS hashes are used in the blockchain smart contracts to link and track the data. Blockchain-based trust management solution can use IPFS along with blockchain for storage of large amount of data originating from smart vehicles, as blockchain is a very expensive storage medium for large data.
Blockchain can offer practical solutions to many problems for SIoV systems, especially those related to trust. First, blockchain can provide instantly (without a centralized authority) a Global Unique Identifier (GUID) when assigning and allocating an address to SIoV vehicles and also to multiple IoT devices within a smart vehicle. A smart vehicle can have multiple GUIDs as they may contain multiple IoT devices with global accessibility. Second, by design, data transmitted by SIoV vehicles connected to the blockchain network will always be cryptographically proofed and signed by the true sender that holds a unique public key and GUID, thereby ensuring high security and integrity of transmitted data, as well as trust. Third, smart contracts of Ethereum blockchain allows for superior tracking, management, governance, and access control of smart vehicles, and their data are stored in the cloud or IPFS in a decentralized, trusted, and open manner. SIoV data can be collected, aggregated, and stored for further access in either IPFS or cloud through a cloud data broker. Sensitive data can be stored only in cloud data broker; however, publicly open data as that of registration and identity of smart vehicles, or shared data as routes, accidents, road conditions, can be stored for all with the IPFS system. Finally, and in general, the key features of blockchain and IPFS would also allow to better devise and design highly efficient solutions to solve other trust management issues related to SIoV secure transactions, logging, privacy, defense against attacks on data integrity, reputation and collusion, and protection of social relationships.
Figure 5 illustrates an architecture and topology of the envisioned future SIoV network, with smart vehicles communicating and access data through RSU which have access to IoT data in the cloud and also have interface to Ethereum blockchain network as well as IPFS file systems. Each vehicle on the system will have a unique Ethereum address with private and public keys, but will not communicate directly to the blockchain network. This can be a key feature to lessen the computational and processing overhead on smart vehicles and their IoT devices connected within them. In the architecture, Ethereum smart contracts govern access to data in the cloud as well access that are publicly stored in IPFS systems. The smart contracts through the RSU will have the ability to control access of a smart vehicle to IPFS systems, cloud data, as well as access to other vehicles. For example, the smart contract can have access control rules to instruct the RSU to provide access of data sorted in the RSU itself, cloud, or IPFS to certain vehicles and not others. The access to data can be specified permanently for a certain duration. Also, the smart contract can provide access to all or specific amount of data. A key feature of such a system is that all transactions and interactions among vehicles, cloud, or IPFS are all logged in a highly trusted and non-refutable way, with real-time transparency, traceability, and visibility.
Future SIoV leverging the capabilities of blockchain, IPFS, and cloud.
Fog computing–based trust solutions
Fog computing is a trending concept that allows computation at the edge of the network to offload the computation burden of resource-intensive vehicles from the cloud to the edge node. 30 Computations at fog (edge) node allow dynamic and scalable networks like vehicular networks to offer delay-sensitive applications, for example, emergency applications, real-time traffic monitoring, and vehicular multimedia applications that require high bandwidth and low latency. For example, going back to the same example, an SIoV application for authorities that require processing of videostreaming data to recognize the drivers in order to catch a fugitive on road will have a requirement of real-time processing of videostream along with face recognition. Such applications require high bandwidth and low latency to avoid miscalculation that can lead to serious inconvenience for drivers and vehicles on the road. If such information is to be processed by the cloud in a highly dynamic environment, there are chances that delay occurs during the communication, processing, or computation. A solution to this problem can be fog nodes that can assist in processing, computing, and communication of information at the edge of the node without transmitting information to the cloud.
Trust management models for SIoV can leverage the benefits of fog computing to deal with its dynamicity for context management and task offloading. As the entities in SIoV are highly dynamic in nature, the context of the information is of utmost importance as a slight change in the context might result in providing inappropriate information to the vehicles on road. Contextual information holds immense worth for trust. The trust score in vehicular networks can drastically change with the change in the context. For example, a vehicle in urban area might be interested in information of the traffic signals on the road; however, the same vehicle might not be interested in traffic signal information on a highway. An SIoV system providing out-of-context information to vehicles might lose the trust of the vehicle on the system. Similarly, a vehicle in an urban area providing information of the toll gates of the highway might lose trust of the SIoV system due to providing out-of-context information. The fog nodes, due to their limited processing, computing, communication, and storage capabilities might not be able to provide extensive information to the entities of SIoV system; however, an efficiently designed trust model deployed at fog node might assist in computing the trust score of the vehicles on-the-fly without interacting with the cloud on each computation. 58 Furthermore, storage of trust scores of the nearby vehicles and other entities of the system to the fog unit might help in disseminating this information to the entities without delays.
A typical arrangement of trust model using fog nodes in SIoV is illustrated in Figure 6. Due to limited capabilities of fog units as compared to the cloud which has virtually unlimited capabilities, the fog units need an efficient trust model that calculates and manages the trust score of the entities with less complications as high requirements for complexity demand more processing and computing resources.
A typical arrangement of SIoV for trust management using fog nodes.
Managing trust at fog nodes has several benefits. Reduced latency is one of the benefits while transmitting the information to and from the entities in SIoV, since the propagation hops and time are reduced due to availability of information at the fog nodes. Similarly, less bandwidth requirement is another benefit, since not all the data are required to be sent to the cloud for processing and storage. Finally, increased reliability and efficiency can be achieved by deploying more fog nodes to improve the coverage area and avoidance of single point of failure.
In summary, both of blockchain technology and fog computing can assist in devising systems and architectures that ensure highly decentralized, secure, and scalable trust management for smart SIoV vehicles. By design, all blockchain transactions and interactions (originating from SIoV and RSU nodes, as well as from fog or cloud processing nodes) are cryptographically and digitally signed and verified by all mining nodes. Also, all meta data of these transactions are immutable and stored with high integrity, resiliency, and traceability. This allows for building a highly credible SIoV trust ecosystem, involving no single point of trust, centralized intermediaries, or trusted third parties (TTP). Furthermore, fog computing paradigm allows for providing localized processing, storage, and networking to offer timely context management, localized decision making and processing, reliability, and proper scalability.
Conclusion
SIoV is a recent trend in the area of ITS inspired from SIoT- and cloud-based VANETs. In its early age of research, SIoV has various unexplored areas, and trust model is one of them. One of the major factors in socializing is trust of entities on each other and SIoV follows the same process when it comes to socializing with other units of the system. One of the contributions of this article is highlighting the factors that affect the design of a trust model for SIoV. Several factors have been explored along with their impact on drafting the trust model such as reputation, context, environment, goals, expectations, social contact, willingness, and timeliness of evaluation. Several challenges are posed for designing the trust model for SIoV due to its nature of the interaction, prerequisites for the communication, and type of information. This article emphasizes on the most critical challenges faced in designing a stable, reliable, efficient, and robust trust model for SIoV systems such as architectural choices and deployment, scalability, general reputation and local knowledge, context-awareness, social relationships, dependability, privacy, defense against trust attacks, QoS, mobility and unpredictability, current practical and general solutions, and ethics. Due to nature and scope of these challenges, a comprehensive research is required to study each challenge in the light of trust for SIoV that opens a wide horizon for future research in this area. This article explored the existing trust models that have the potential to be implemented in SIoV system since not many models are available for trust in SIoV. This overview of the existing trust models sets a foundation for future research in this area. Finally, a brief overview is provided on trending technologies such as Blockchain, and Fog Computing is given in the context of trust management to develop an efficient and reliable trust model for SIoV keeping in mind the dynamic and scalable nature of system.
Footnotes
Handling Editor: Paolo Bellavista
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) received no financial support for the research, authorship, and/or publication of this article.
