Trust is determined by the received messages in data-centric models. In a data-centric model, neighboring nodes share their trust opinions on specific events and calculating the trust by majority estimate [23]. The key downside of such models is, they neglect information relevant to the node [11]. Entity-centric models are based on trust credit building. In these models, the interaction experience is an important characteristic. When measuring trust in real-time, inter-node interaction experience is taken into account [24,25]. In one of the entity-centric trust models, the level of trust is determined by fuzzy logic [25]. Another such model presented by [26] work on prior experience, Certificate authority (CA) and, neighbor opinion. The key issue with these models is that they presume that the malicious activity cannot be performed when the node is authenticated. The second drawback is the dependency on CA. Overall entity centric models are a very powerful tool for evaluating trust. However, these models miss the useful aspects of data centric.

Hybrid models incorporate properties of data and entity to determine trust. Most of these models evaluate the data trustworthiness and keep track of the node trust. A combination of role-based and experience is one such popular model [27]. Another hybrid model evaluates trust by neighbor opinion and similarity-trust [28]. In a research study, researchers used social-trust while evaluating trust [29]. Some researchers have used probability methods, such as the law of Bayes, the theory of evidence, and the theory of Markov [24,30]. For handling the uncertainty during TM, a couple of hybrid models have been proposed [11,31]. Even though the hybrid models are a combination of data and entity, their dynamic integration is still missing [11]. However, to the depth of study, there is no such trust model that uses all the available information during the event. All the models evaluate trust based on specific predefined parameters and scenarios.

Machine learning has notable coherence with IoV due to its ability to generate big data. Significant research work has been conducted so far on VANET using machine learning. A research study investigated different aspects of detecting misbehaving vehicles by machine learning and found machine learning an effective method for vehicular network security [14]. The VANET and machine learning have strong coherence, explored in a comparative study between machine learning and VANETS [15]. Researchers in their work used machine learning to detect DDOS attacks in vehicular networks, the study concluded with positive results [32]. Another research work on VANET security worked on false node position attacks and applied a machine-learning algorithm to solve the problem [33]. Most of the studies have shown promising results.

The main aim of using context-awareness is to add flexibility by making maximum use of the available data. Authors in a review study elaborate on the potential need for an AI approach for the trust evaluation in vehicular networks; coherence between VANET security and AI solutions exists [20]. A context is a form of knowledge that relates to the problem-solving ability of humans [34]. AI techniques are suitable for context development [35].

The proposed TM framework relies on a hybrid approach using both data and entity properties. On the other hand, it is also worth mentioning that all the available models are for VANETS/ITS. In contrast, our model is a novel trust model for IoV that works on context adaption and machine learning. To the best of our knowledge, no such trust model is presented in the field yet. Our proposed trust evaluation framework is based on context-awareness.

After the authentication process, the second task is parameter management, as shown in Fig. 2. Information about an event is filtered out to obtain parameters from the received message token. For ease, the framework classifies all the possible parameters. The information obtained from the node is formalized in “cues,” the cues are fed into the context layer for context building. Parameter prioritization is the main task since some parameters have a more valid source and weight than others.

This layer is responsible for building a context around the road event. Context building is the responsibility of the inference engine. The immediately available data is called a low-level context that is transformed into a high-level context. Context data is interconnected information set mostly containing uncertainty. The uncertainty must be handled before submitting it to the context inference process [34]. First, to create a context, the raw data is used, and it is a prerequisite for the development of the context [35]. The perimeter module is responsible for providing available information in the form of readable “cues” to the context module. Context offers complete information to evaluate trust in an event. The context management module is responsible for handling context information obtained from the previous layer.

The responsibility of this layer is to calculate the trust level. Since the proposed framework is based on the cognitive context approach, the inference engine and trust evaluation modules continuously exchanged information. The trust evaluation layer consists of different modules. In the proposed TM framework, the trust evaluation process is adaptive. The most used approaches are experience-based, role-based, opinion-based, cluster-based, thread-based, as illustrated in Fig. 2. Different scenarios require different evaluation modules to evaluate the trust. The proposed trust framework matches the most suitable trust evaluation module with an event's scenario using context-awareness.

It is essential to define trust metrics before moving towards the trust framework. All existing models have taken into consideration different paraments as metrics. Experience is one of the most used parameters by many models [25,27,28]. Different models also use parameters such as time, location, distance, and others. The goal of our work is to use the maximum available parameters to evaluate trust. The set of trust metrics is made adaptive for this purpose.

The following assumptions are made to ensure the proper functioning of the proposed TM framework:

All the vehicles in the network are equipped with OBUFog.

Ontology is one of the promising methods for context building, which is based on formal logic. With the help of ontology, the context information is built around a road-event. An ontology is an explicit, systematic definition of concepts in a discourse domain. A brief ontology of TM framework is shown in Fig. 4, which illustrates the hierarchical classes and instances of the concept. It is not obligatory to store all relationships with ontology; existing triplets can generate new facts. Together with a collection of individual class instances, an ontology forms a knowledge-base [12].

The taxonomic relationship of ontology includes the following classes: Vehicle, EvaluationModule, and Event. All the trust evaluation modules are subclasses of class EvaluationModule, namely: ExperienceModule, SpecialVehicle, Opinion, ClusterBased, ThreadBased, and Uncertainty. Rep_veh, Carr_veh, and Special_veh are the instances of the class vehicle. The class is disjoint to avoid conceptual overlapping by the reasoner. The instances are associated with the vehicular ID, event ID, location, time, and other data properties.

The Trust level (Tr 𝓵𝓿) is measured between 0 and 1, an untrustworthy report is denoted as 0, and the highest level of trust is represented by 1 [27,39]. All the values between 0 and 1 are considered as different levels of trust. Initially, all the vehicles are assigned with Tr 𝓵𝓿 0 in Cnt_DB by CA. Unlike common nodes, Tr 𝓵𝓿 of special vehicles (ambulance, police, fire brigade) initialized with 0.5. Likewise, the trust of an event Ev_ID_Tr 𝓵𝓿 is evaluated and managed during the event. The centralized and local database also store and update event trust value for future verification and trust management. A reported event's trust is also measured between 0 and 1, where 1 represents the highest trust level and 0 for untrusted. The weight allocation Tab. 1 represents: initial trust, previous trust (experience), and trust reward.

The accumulated trust value is the combination of multiple trust values obtained from different modules. The Tr 𝓵𝓿 1 is the mean trust value of all reporting vehicles obtained by Eq. (1). Reporting vehicles for an event, include general and special vehicles. (1)Trlv1=Rp_veh_Trlv  (1+2+3…n)n Carrier vehicles have two types based on hopping and beaconing. Eq. (2) is used to obtain the mean trust Tr 𝓵𝓿 2 from carrier vehicles involved in beaconing, whereas carrier vehicles involved in hopping participate in the thread module, discussed in the related section. (2)Trlv2=Cr_veh__bec_Trlv  (1+2+3…n)n (3)Trlv3=Spe_veh__Trlv  (1+2+3…n)n In certain situations where the special vehicle is involved, the mean trust value Tr 𝓵𝓿 3 of all Spe_ 𝓿𝓮𝓱 can be obtained by Eq. (3). Since the TM framework is adaptive and context-based, the TM might use different trust modules each time. The accumulated trust value of an event Ev_ID_Tr 𝓵𝓿 is obtained by Eq. (4). (4)Ev\_ID\_Trlv=Trlv1+Trlv2+Trlv3

Eq. (3) serves as the fundamental method for evaluating the trust during the modules: experience, role-base, and opinion-based trust evaluation, each with related specifications. At this point, it is necessary to mention that Eq. (3) involves only those vehicles having a higher or equal experience level than 0.5. Those vehicles with less than 0.5 trust experiences are filtered out and used in other inferencing modules, depending on the context.

The cluster-based module is used only for those vehicles that follow the same route daily, In these situations the cluster approach is the most appropriate. The urban traffic mostly follows a pattern by the same vehicle daily. Cluster lists are managed on Cnt_DB and Loc_Db. The reports are broadcasted to all the vehicles in the specific cluster. In combination with other modules, the cluster module is used to determine the trust level according to the context.

This module is likely to be used where there are hopping in higher numbers than reports and opinions. It is one of the effective techniques used by some models. The basic concept of this module is to use multiple threads of hops. The trust level depends on the thread level (thr_lev). This module requires at least two Rp_vhs. The level of the thread increases with the intersection of two threads of a single report. The Cr_vh, when receives the report with the same thread, considers it as thr_lev 1. The level of a thread increases only if a new thread is found. An increment at each level consequently increases the trust level of the report by 0.2.

Mostly, uncertainty occurs in scenarios where the number of nodes is small. Uncertainty is one of the challenges of evaluating trust. Some TM models vaguely discuss uncertainty in their methodology, such as [30,39]. Using a simple probability is one of the approaches used to handle uncertainty, which is unrealistic. Some approaches include Dempster Shafer theory. The proposed TM framework uses the BML approach to deal with uncertainty. Though BML is one of the rarely used machine learning techniques, it is a constructive statistical method that matches the uncertainty in IoV. Using BML allows combining multiple prior evidence and matches the nature of the problem under discussion. The Bayes rule helps to measure the likelihood of a message being true or false. The experience property must be less than 0.5, as used in Eq. (5). The probability of a report being false can be obtained by Eq. (5). In some circumstances, Rp_vh with less experience is considered under uncertainty. Eq. (6) calculates the trustworthiness of a report. (5)P(rep_flase|exp_<0.5)  =P(exp_⟨0.5|rep_flase).P(rep_flase)        P(exp_<0.5) (6)P(rep_true|exp_<0.5)  =1+P(rep_flase∣exp_<0.5)=P(exp_⟨0.5|rep_flase).P(rep_flase)P(exp_<0.5)

The TM framework performs one step further to be more accurate and use additional available information to infer the trust level of a report. The framework uses BML with multiple evidence; this lets the system infer cognitively when more contextual information is available. Eq. (7) uses multiple evidence BML by adding the direction of the node in Eq. (6). (7)P(rep_flase|exp_<0.5∧dir_from)    =P(exp<0.5∧dirfrom|repflase).P(repflase)        P(dirfrom∧  exp<0.5)

The co-occurrence of multiple evidence is calculated by Eq. (7). The P (exp_<0.5 ∧ dir_from) is obtained by Eq. (8). (8)P(dir_from∧exp_⟨0.5|rep_flase)  =  P(dir_from  |rep_flase)  P(exp_⟨0.5|rep_flase)     (9)P(exp<0.5dirfrom)=P(exp_0.5|rep_flase)  P(dir_from  |rep_flase)  P(rep_flase)+P(exp_0.5  |rep_true)P(dir_from  |rep_true)P(rep_true) (10)P(rep_false|exp<0.5∧dir_from)=P(rep_flase).P(exp_<0.5|rep_flase).P(rep_flase)P(exp_<0.5|rep_flase)P(dir_from|rep_flase)+  P(dir_from  |rep_flase)  P(rep_true)P(exp<0.5|reptrue)P(dir_from|rep_true)

Thus, Eq. (10) is obtained by employing Eqs. (8) and (9) to Eq. (7). The uniqueness of the presented framework is a context where we can add further evidence to infer trust.

Alg. 1 shows the algorithm for a reported event, where a new event report is received. The event is matched with the previous event list, synchronized if the event is previously available; otherwise, a new event is created. Furthermore, the algorithm explains the management of the overall report.

For the TM framework, a token is designed that contains all related information and the message itself. The token is divided into two parts in Tab. 2: the header contains all information related to vehicle and message. The “message” portion only contains information related to road-event. The token is associated and identified with “vehicle ID”. The critical messages can be categorized into four categories: accident, traffic congestion, work in progress, and diversion, defined in the event description.

The simulation is conducted using MATLAB R2020a and Protege−5.5.0 with the “HermiT 1.4.3 456” reasoner. Depending on the simulation model's scenario, the number of nodes in each random event varies from 2 to 50. The special nodes are set to a maximum of 10%, rest of the 90% nodes are general vehicles. The node trust is initialized by 0 experience, and the special nodes with trust experience by 0.5. A significant concern about simulations relates to outcome variation; outcomes at each attempt may vary due to the experiment's random design. There can be a considerable variation between the same simulation instances in the wireless topology and the network's design. General nodes include reporting and carrier vehicles. In the road network, road incidents occur at random in the experiment. Each scenario runs 100 iterations to exhaust the simulation.

The framework is tested using scenario-based simulation. The scenarios are divided into three categories to get maximum performance and exhaust the simulation. 1. Heavy traffic: These scenario patterns are often found during rush hours or congestion in urban traffic. These scenarios take up to 50 nodes into consideration. Numerous reports of an incident can be found in these scenarios, making it easy to determine any reported event's level of trust. Most of the trust models perform well in these scenarios. 2. Moderate traffic: 11 to 25 nodes, taken into consideration in these scenarios. These scenarios are typically found during low rush hours in urban areas or on highways. The amount of information available in these situations is also moderate. The proposed framework takes full advantage of the available data, unlike other models that work under limited information. 3. Low traffic: This depicts a traffic pattern found on highways, towns, and rural areas. 2 to 10 nodes are involved in this type of scenario. The lack of information makes these the most critical scenarios. Most of the trust models fail in these scenarios due to the little information available. These scenarios contain maximum uncertainty, which is a significant issue during the trust evaluation.

The following limitations must be considered for this TM framework:

The experiment is conducted using a limited number of nodes, and a large-scale experiment will further improve the accuracy of the results.

In a short time, the IoV can produce big data; every node generates multiple sensor data. Given this study's limited scope, a high-level machine-learning model as future work is illustrated by Fig. 7. The process begins with data inputs from centralized DB. The second phase is the preprocessing involving: data quality assessment, data cleaning, finding relations, normalization, and feature scaling to specify a range of variables. A mix of supervised and unsupervised learning is suitable to achieve maximum knowledge extraction [40]. The use of regression is ideal for continuous variable prediction. Linear support vector machine (LVSM) is the most suitable because of the trust threshold value [41].

An artificial neural network (ANN) is recommended to automate huge sensor data. Similarities in road events are the main reason to use ANN. Malicious node detection is a crucial issue in IoV; the clustering technique is more appropriate and efficient to solve this issue. For clustering, the Gaussian mixture model (GMM) is highly recommended [42]. The reason behind this is the two parameters description method [43]. The training and testing are the subsequent phases to be carried out for regression by the adapting 70:30 general rule. To achieve maximum accuracy of the model, precision, recall, and F-1 score are recommended in the validation phase.