# Protecting Hybrid ITS Networks: A Comprehensive Security Approach
## 3 Proposed Approach
### Proposed Architecture
#### 3.1.2 Message Exchange Scenarios  
The scenarios contemplated for exchanging messages with security guarantees are illustrated in Figures 8-10. These message exchanges assume the configuration of a security  
Figure 7: Architecture of the proposed approach.  
protocol (MFSPV or DLAPP) to protect and deprotect (verify) a message. The numerical sequence in each figure represent the order of actions performed.  
Firstly, the sequential flow when the OBU generates a message in the G5 network is described in Figure 8. The step-by-step is as follows: (1) The OBU generates the ITS message, protects it with the configured security protocol and transmits it via G5. (2) An RSU receives the message and validates it. If the message is valid, the RSU processes and publishes it in the broker. Otherwise, it discards it. (3) The broker receives the message and sends it to all interested consumers. (4) Each interested smartphone receives and verifies the message. If it is successfully verified, then it is processed.  
Figure 9 represents the inverse, i.e., the sequential flow when a smartphone generates a message. The step-by-step is as follows: (1) The smartphone that generates the ITS message protects with the configured protocol and publishes it. (2) The broker receives the message and sends it to all interested consumers. (3) When an RSU or another smartphone receives the message, it undergoes verification. If the validation is successful, the message is processed. RSUs also transmit it via G5 for reception by other ITS-Ss. In the case of validation failure, both RSUs and smartphones discard the message, which is not propagated to the G5 network. (4) OBUs receive the message via G5 and verify it.  
Figure 8: Flow diagram when an OBU generates a message, including the actions’ order.  
Figure 10: Flow diagram when the RSUs generate a message, including the actions’ order.  
Figure 9: Flow diagram when a smartphone generates a message, including the actions’ order.  
Finally, the sequential flow when the RSU generates a message is described in Figure 10. The step-by-step is as follows: (1) The RSU generates the ITS message, protects it and sends it to G5 and cellular networks. (2) The broker and OBUs receive the message sent by the RSU. The broker sends it to all interested consumers. Conversely, the OBUs verify the message. If valid, they process it. (3) Each interested smartphone receives and verifies the message. If it is successfully verified, then it is processed.  
Note that from the point of view of smartphones, their reception service is identical if the message is generated by the RSU or the OBUs. The same goes for the OBU; its reception logic is identical whether the messages were generated by the RSU or smartphones. This is no longer true for RSUs, as they act as an intermediary between the cellular and G5 networks. RSUs have a service to handle messages from each network. Moreover, it can be observed that there is no need to interact with the CA in any of the scenarios presented. This occurs because both protocols, MFSPV [14] and DLAPP [13], decentralise it so that there is no communication with the CA during the message exchange process.