# Managing Emergency Situations in VANET Through Heterogeneous Technologies Cooperation
## 3 Architecture and Communication Protocol
### Protocol Communications  
The overall system is based on the _inter_ and _intra_ communications of sub-layers. We design a hierarchical architecture for better distribute the computational load allowing faster response to those events that may be responsible of congestions. The presented architecture is based on three different layers that perform traffic management tasks. Each layer can communicate with its surrounding layers exploiting dedicated interfaces. Then, a communication protocol uses these interfaces for sending messages between layers. It has been designed to reduce the amount of data transferred and delays. It is based on the following interfaces:  
**Inter-High-Layer Interface (IHLI):**: it defines rules for exchanging data between HRTM and LRTM layers;
**Intra-High-Layer Interface (INTHLI):**: This interface provides communication among LRTM systems;
**Inter-Low-Layer Interface (ILLI):**: it is used to exchange data between LRTM and RSUs, smart traffic lights and smart road signs;
**VANET Interface (VI):**: it is used by RSUs to communicate between them and to implement the V2V and V2I communication protocol;
**Low Layer Interface (LLI):**: it is used to allow communication between smart road elements and vehicles. These communications are useful for the whole system because of the vehicle flow monitoring.  
These interfaces, which are summarized in Figure 2, allow inter- and intra-layers communication exploiting heterogeneous technologies.  
In this section the behavior of vehicles is described in detail. When a vehicle begins its journey, it evaluates through the analysis of the map the Road_ID. It sends a Register message in a broadcast way. Several RSU may receive this message but only the RSU that has the task to manage that Road_ID registers the vehicle in a local data structure and generates an Acknowledgment message. This message will bring up also the other Road_ID managed by the RSU. Thus, no more register messages will be generated by the car that is traveling on those roads. If no acknowledgment is received within a given timeout then another register message is sent. This mechanism is shown in a timing diagram depicted in Figure 3.  
In case of an accident (e.g., collision between cars), we have designed the following protocol rules. In Figure 4 it is shown the collision management and the messages exchange between vehicles, LRTMs and HRTM. These procedures may help to improve the capability of the system to face with this kind of event. In particular, the event management is composed of several steps. In this scenario two vehicles generate a collision events, suddenly vehicle generates a beacon message to inform RSU device to spread this event in the area. Moreover, this message is sent towards the LRTM responsible of this area that starts to manage the events by updating the status of the lanes involved by the collisions. In particular, in Figure 4 only the LRTM system is involved in the management of the collision because its severity is low. In the scenario shown in Figure 4 local traffic management was not sufficient to solve traffic congestion. In this case, the HRTM can take global decision to reduce congestion in the area of collisions blocking or limit incoming flow from surrounding areas managed by different LRTMs. Also the message is propagated towards its neighbor LRTMs by using the INTHLI and towards HRTM by exploiting the IHLI. LRTMs provide to spread information about collision and LRTM decision in their area of interest. HRTM will take under consideration this message for the next map update process.