# Distributed Reputation for Accurate Vehicle Misbehavior Reporting (DRAMBR)
## 4 System Model
### Workflow and DRAMBR Phases
#### 4.4.2 Process 2: Online Reporting (OR)  
To send an MR to the RS, \(Rep_{\text{Veh}}\) may use different communication channels for reporting \(Tar_{\text{Veh}}\). In line with TS 103 759-V2.1.1 standards [16], the following communication protocols are considered for establishing the connection between V2I:  
* DSRC short via RSU or a cellular network link (3G, 4G, or 5G). * A wireless or wired connection at an electric vehicle charging station. * A Wi-Fi hotspot that offers Internet access, such as in a parking lot or a private hotspot at home. * Running the Vehicle On-Board Diagnostic (OBD) port and a diagnostic system at the inspection workshop or service garage. Upon connectivity, the following subphases have to be performed to complete the process of the OR. RS Communication: Vehicles establish a secure connection with the RS either via RSUs or directly. In order to achieve such a communication within the RS during the MR submission process, the ISO 15118 standard requires Transport Layer Security (TLS) function for secure communication between vehicle and infrastructure as mandatory. With TLS handshake, vehicles and RS are securely authenticated, and cryptographic algorithms (cipher suite parameters) are defined. These steps are utilized to generate the TLS master key to encrypt and decrypt the communication messages between vehicles and RS in order to achieve the secure communication (authentication, integrity, and confidentiality). 2. MR Reporting: Once the communication is verified, \(Rep_{\text{Vehs}}\) submits the stored MRs. This phase ensures that local evaluations feed into the global trust framework by enabling the RS to update the reputation and notify the rest of the network about the detected misbehaving vehicles. Base on the offline observations discussed in Table 3, we consider four reporting conditions, as outlined in Table 4. We analyze the main containers of the MR format, as previously explained and illustrated in Figure 5. The MR is composed of three containers: 1. Header: Includes the fundamental data that an MR should have, such as MR generation time, \(Rep_{\text{Veh}}\) id, \(T_{\text{Var}}\) id, and MR type. 2. Source: Includes the misbehavior results where the \(Rep_{\text{Veh}}\) flags the \(T_{\text{Var}}\) if the received \(M_{\text{sg}}\) shows implausibilities. 3. Evidence: Contains the \(T_{\text{Var}}\)**ch**\(M_{\text{sg}}\) and the \(Rep_{\text{Veh}}\)\(M_{\text{sg}}\) or any \(M_{\text{sg}}\) from the neighboring \(Rep_{\text{Veh}}\) if believed helpful. The evidence could also include other supported information like a Local Dynamic Map (LDM), or direct sensor data from the \(Rep_{\text{Veh}}\) OBUs. The detailed evidence for misbehavior vehicles that required by the MA is further explained in [13]. Having outlined the main containers of the MR format, we now turn our attention to the expected three versions of the received MR by the RS based on this format:  
* Base MR: This basic version includes only the header and the source containers without any evidence. * Beacon MR: In this version, the \(Rep_{\text{Veh}}\) includes a base MR and the suspicious \(T_{\text{Var}}\)**ch**\(M_{\text{sg}}\) as evidence. * Evidence MR: This version contains a detailed report with more complete misbehavior information depending on the type of plausibility checks failure. For example, if the \(T_{\text{Var}}\)**veh** failed the speed consistency, the \(Rep_{\text{Veh}}\) includes all related inconsistent \(M_{\text{sg}}\) in the \"Evidence Container\" for deeper investigation. \begin{table}
\begin{tabular}{p{142.3 pt} p{142.3 pt} p{142.3 pt}} \hline \hline
\begin{tabular}{} \end{tabular} \\ \hline \hline \end{tabular}
\end{table} 
Table 4: \(Rep_{\text{Vehs}}\) Reporting Conditions and RS Actions. These MR versions support an efficient reporting process by allowing the RS to aggregate evidence and send a single comprehensive MR to the MA, reducing network overhead and ensuring accurate incident tracking. 3.