SafeSmart: A VANET system for faster responses and increased safety in time-critical scenarios

An important use case for Vehicular Ad-hoc Networks (VANETs) is its application in the warning systems of emergency vehicles (EV). VANET-based vehicle-to-infrastructure (V2I) communication can be used to exchange important data and information between traffic lights and EVs, by means of transceivers at both ends. This communication helps in reducing the risks of accidents and also saves valuable time through an optimized orchestration of the traffic lights. This paper outlines the system design of an EV warning system that makes use of V2I communication. The system has been extensively studied in state-of-the-art simulators, such as SUMO and OMNeT++, in a huge variety of scenarios, where metrics for both time and safety have been collected. The results show that SafeSmart is highly effective in reducing trip times as well as increasing the overall safety of EVs in emergency scenarios.


I. INTRODUCTION
Recent studies [1] show that in the United States, 466 ambulance crashes were reported for the period from May 1, 2007, to April 30, 2009. Of these incidents, 76.8% resulted in injuries to people inside or outside ambulances and 16.9% resulted in fatalities. A total of 982 persons were injured and a further 99 were killed. The causes of these accidents were mainly driver error and road conditions. Ambulances, police cars, fire trucks and other similar emergency vehicles (EV) all make use of sound and visual devices (e.g., blue lights and sirens) to warn other road users to allow clear access to their destination. In a real-world scenario, drivers often have difficulty locating the EV and deciding on the best avoidance maneuver, often reacting too late or in the wrong way. Situations of this type can easily result in serious accidents and critically delay the EV in reaching its destination.
This situation becomes even more serious when ordinary vehicles and EVs are stuck in a traffic jam when the traffic lights are red. While EVs do have priority at traffic lights, they are also susceptible to the traffic conditions. The traffic equipment can also offer additional help to provide safe and smooth traffic flow for the EVs. Wireless sensor devices in the context of V2I communication can be fitted in both the EVs and in traffic lights to create a reliable channel for the exchange of control messages in determining the state of the traffic light signal.
VANET is an emerging technology for an intelligent transport system (ITS) that enables Vehicle to Vehicle (V2V) and Vehicle to Infrastructure (V2I) communication by using advances such as location-aware applications [2], as well as various IEEE and ETSI standards, such as IEEE 802.11p [3]. V2X communications are currently supported by standards based on IEEE 802.11p, such as ITS-G5, in Europe, and Dedicated Short Range Communication (DSRC), in USA. It is also possible to use LTE-based V2X technologies, such as LTEV2X. There has been much discussion as to which of the options provides better results, some of which are shown in [4] and [5]. This work focuses on the ITS-G5 based on the results presented by [5], which state that IEEE 802.11p performs better in situations with irregular message sizes and time intervals.
Vehicular environments impose a set of new requirements on today's wireless communication systems. The main reason for this is that vehicular safety communications applications do not tolerate long delays in connection establishment. Additionally, the high dynamic of the vehicles' movement and the complex roadway environment present challenges at the physical layer level.
The hypothesis considered here assumes that, if a VANET system can be designed to allow V2I communication between two separate wireless transceivers (one on the EV and the other in the traffic light system), such a vehicle can assume control of the traffic light signal state. The equipment capable of controlling the traffic lights will be located at the intersections and is called a roadside unit (RSU). This ability to control the traffic light solves a traffic jam obstacle scenario, where the vehicles in the path of the EV can move with the traffic signal open. This situation allows the EV to move faster and in a safer manner, in contrast to a normal situation scenario, where the drivers of the other vehicles would need to take evasive action, even when the traffic is stopped. Similarly, such messages could be used for traffic light pre-emption where the traffic lights switch to green in the direction of the EV, while blocking the crossing directions.
The proposed solution, named SafeSmart 1 , consists of a system that uses the current infra-structure of the transceivers in traffic lights and the features of ITS-G5 to provide communication between the emergency vehicles and the traffic lights. To provide a suitable environment for testing and deployment of the system, the VEINS framework is used, which combines features of OMNeT++ [6] integrated development and graphical runtime environment, with SUMO [7] traffic simulator.
The developed simulation is also used to evaluate the SafeSmart system, as well as the results obtained from the tests. A comprehensive analysis of the data collected from the experiments is also provided.
The rest of this paper is organized as follows. Section II discusses related research. Section III addresses the open challenges. Section IV presents the design, the prototype and in-depth details of the proposed system. The experiments, simulations, metrics and the experimental details are presented in Section V. Section VI presents a detailed analysis of the collected results and Section VII concludes the paper with a summary of the findings with recommendations and ideas for future work.

II. RELATED WORKS
Vehicular communication applications are often cited as a VANET use case. Related research has dealt with VANET 1 Available at: https://github.com/e-k-d/Safesmart_80211p technology being specifically applied to EVs applications. In [8], the authors design an EV warning system that utilizes V2V and V2I communication. With prototype testing using a detailed video analysis, the evaluation of the system by experts showed that it can help to make EVs trips safer and faster, thus potentially saving lives.
The paper is very relevant for this current work since it demonstrates the need to develop and analyze these types of systems. It also shows that a simpler and more straightforward solution that does not need to communicate with other vehicles, but only with the sensors in the traffic lights, can improve the response trip times of the EVs.
In [9] a novel collaborative V2I interaction with the "automated emergency vehicle greenlight" (AEVGL) function is presented. The authors' approach combines traffic light infrastructure with DSRC over IEEE 802.11p to avoid accidents involving EVs at intersections. They use communication to pre-emptively switch traffic lights to red for crossing traffic to allow safe passage of the approaching EV. This feature shows much potential for improving safety, comfort, and efficiency.
The paper cited above is based on the same concept and explores much the same application scenario at road intersections as in the present study. However, unlike the solution presented by the authors above, the proposed SafeSmart directly uses the ITS-G5 protocol and obviates the negotiation mechanisms that allow the EV to cross the intersection and reduce the response trip time. It also increases traffic safety as well as the safety of the people and vehicles involved.
In [10], the authors discuss and implement a messaging system between EVs and RSUs to facilitate the arrival at the nearest hospital. A proof of concept has been implemented to show the proposal is viable. Although the proposal differs from SafeSmart in that it does not orchestrate the traffic lights, showing that the implementation is viable is important. To deploy a system such as SafeSmart, it would be necessary to implement it on real devices, which is viable according to the authors.
The authors of [11] have conducted an extensive study regarding the improvements in trip times of ambulances using V2X communications. The distance ran by the ambulance comparing the case using their proposed algorithm with the regular siren was increased by approximately 17%, which is a promising result. However, all the tests were conducted on an artificial grid map, which is not the most realistic case. The results may show some disparity between those obtained from other, more complex and realistic scenarios.
The work reported in [12] deals with reducing the response time of the emergency vehicles and changing the traffic lights status by employing communication technologies. The contribution of this paper twofold: first, the effect of the changing traffic lights status to green for emergency cars is investigated by using traffic simulator (SUMO). Second, the authors use OMNET++ (Network Simulator) to simulate the mentioned scenario as a VANET (with 802.11p standard) by using Veins framework to run SUMO and OMNET++ in parallel. This study has developed a Veins framework by adding a new module to OMNET++ to consider the traffic lights which are simulated in SUMO. This paper uses Manhattan realistic map to describe the mentioned program, then uses a realistic map and realistic traffic situations found in Cologne, Germany, to validate the proposal. The response time for emergency cars in the city of Cologne is investigated. Then this scenario is investigated using network simulator OMNET++ and Veins framework. The probability of beacon delivery in a real large area is obtained for emergency cars. VANET simulation and traffic simulation results have been compared. The results show that vehicle to vehicle communication can be implemented in the real world by using 802.11p which helps to make roads safer and more navigable In [13] the proposed application uses the peculiarities of the VANETs to advise of dangerous or emergency situations with V2V and V2I message exchange. IEEE 802.11p is the standard on which the communication is based, that provides the PHY and MAC layers. The performance of the application is evaluated over many simulations executed in different scenarios. Using the application, an emergency response could intervene in a timely manner because intervention decreases. The advantage provided by the application is greater when there are more vehicles in the road network. The average speed of the emergency vehicle running the application is higher. A better and more realistic vehicle generation model would be useful to obtain more accurate results about application performance.
In contrast to the solutions presented in the above works, the system proposed here is based on a simple and efficient communication system that uses minimal computational effort (e.g., no V2V communication or AEVGL function) and uses V2I communication based on the ETSI standardization documents about information on the surrounding vehicles, road infrastructure [14] and control of traffic lights [15] to assist the EVs' transportation.
The work reported in [8] was used to provide a solid basis on how to setup and develop the VANET system proposed in this current work. The authors outline a comprehensive design for an emergency vehicle warning system that makes full use of inter-vehicle communication, but also makes use of the roadside infrastructure, like traffic lights. With prototype testing using a detailed video analysis, the evaluations of the system by experts showed that, overcoming technological challenges, this system is ready for deployment. This paper is extremely relevant to the work presented here, since it demonstrates the need for developing and analysing these types of systems.
In context aware applications, other VANETs systems also focused on exploring the current traffic infra-structure combined with V2I communication to perform analysis of mobile autonomous agents with different degrees of intelligence. The goal was to allow them to make use of the positioning information of wireless sensors in the vehicles to decide their movement during opportunistic connections among the nodes in a VANET system [16]. Given this work's simu-lation results provide information about how valuable the use of context information is to achieve an efficient system behaviour, this approach can also have its use extended to the scenario of emergency vehicles in VANETs.
The IEEE 802.11p standard [17] used for VANETs is seen as the standard for intelligent transportation systems (ITS) due to its easy deployment, the maturity of the technology, which is based on the popular WiFi standard, and low cost. The advantages of this type of technology can be seen in works such as [18], in which the authors assess and optimize the performance of ITS-G5 for time-critical safety conflict scenarios between vehicles and VRUs (vulnerable road users). The protocol has also proven its efficiency and adaptability when applied to a real-world testbed [19] with the Information-Centric Networking (ICN) paradigm. In this context, the vehicle s connection data is addressed by name instead of location, providing a good fit for scenarios which are characterized by a high degree of mobility.
Nevertheless, IEEE 802.11p presents some issues and challenges that need to be addressed. Security is one of the main problems faced by the protocol standard. Visible Light Communication (VLC) is a promising complementary technology that has the potential to address DSRC problems. In [20] the authors developed a simulation platform to investigate the security vulnerabilities of hybrid DSRC-VLC platoon in the presence of outside attackers. Results demonstrate that, although VLC limits the effect of adversaries, hybrid architectures still suffer from the packet falsification and replay attacks. To counter act these kinds of attacks, the authors in [21] and [22] propose a trust establishment mechanism to punish misbehaving vehicles (e.g., acting as a black hole or sending false alerts). The general idea is to eliminate dishonest nodes from the network, ensuring that high detection ratios of malicious behavior. The authors make use of standardized messages such as CAM and DENM, which makes the proposed solution suitable for all kinds of applications. The mechanism proposed by the authors is scenario agnostic, having performed well even in the worst-case scenarios. Considering emergency scenarios, it is of utmost importance to prevent malicious nodes from tampering with the well-functioning of the system, since human lives could be at stake. This could possibly be achieved by integrating a trust-based approach like the one proposed by the authors.
Quality of service (QoS) and queue management are also critical issues for the broadcast scheme of IEEE 802.11p systems in VANETs. The authors in [23] performed an analysis that reveals that the lack of binary exponential backoff and retransmission in ITS-G5 systems results in poor QoS performance during heavy traffic load, especially for large VANETs. Therefore, a model that provides traffic control guidelines to maintain good QoS performance for VANETs, using 2-dimensional Markov chain, integrates the broadcast scheme of the 802.11p system and the queuing process into one model.
Since its development and deployment in VANET systems, IEEE 802.11p suffers the problem of trying to coexist in VOLUME 4, 2016 the same frequency channel that WiFi occupies. To support the increasing need for WiFi gigabit links, the IEEE 802.11ac technology introduced 80 MHz and 160 MHz channels, leading to an extended WiFi channelization at 5 GHz, spanning over up to 5.9 GHz. However, this frequency band also accommodates the 70 MHz spectrum reserved for IEEE 802.11p technology. As many other researchers have addressed this major practical problem, the authors in [24] present and evaluate these two coexistence protocols and illustrate WiFi potential interference to safety related ITS applications by identifying three zones of awareness relevant for coexistence. At shorter distances, there are not many problems; at long distances, there is high ITS packet loss due to interference from WiFi -even though long distances are not critical for safety related applications; but at medium distances the problems with the two protocols become more complicated. The presented solution for this issue involves the improvement of the performance of both protocols by setting the WiFi channel non-usage time and Clear Channel Assessment (CCA) to be equal (or at least similar) to the periodicity of ITS-G5 packets, whenever a single IEEE 802.11p packet is detected by the network.
Observing the current trend in research on VANETs systems, it is interesting to note that in recent years, the fields of entertainment applications and urban sensing have gained more attention [25] than other themes that were more popular in the mid 2000s, such as efficiency and safety applications. In the future intelligent society, the potential value of VANETs is unpredictable, thus this type of network is worth further exploration and research, specifically in three fields: architecture, algorithm and application [26]. In the context of architecture, the main research issue focuses on designing an integrated system architecture that can make use of multifarious technologies (e.g., IEEE 802.11p DSRC, WAVE, ITS-G5, WiFi, or 3G/4G) and heterogeneous vehicular networks. For the algorithm part of a VANET, it is necessary to consider that, due to nonpersistent network connections, the end-toend communication path may not exist. Therefore, advanced algorithms need to be designed with low communication delay, low overhead, and low time complexity. Finally, from the applications perspective, safety systems are still the key research trend in VANETs, due to the requirement for continuous awareness of the road ahead. Even so, it is interesting to note that the most popular vehicular mobile applications in the Android marketplace do not follow VANETs application guidelines. Therefore, both researchers and developers need to do more work on the standards and security of VANETs applications.

III. CHALLENGES
VANET's characteristic features generate high speed, mobility constraints, and network issues. In the context of intervehicle communication for emergency vehicles, such features have an important impact on the design of these networks. Therefore, there are several open challenges that must be addressed, as mentioned in the works of [27]- [30]: • Dynamic network topology: High vehicle mobility causes rapid changes network topology and fluctuations in radio communication channels. The consequent topology changes also demand fast adaptation of the networking knowledge by the controller. To deal with this problem, techniques using fog computing and local controllers at network edges may be used, but they present portability issues. Most effective current solutions involve the predictions of a vehicle's future directions using machine learning tools. • Flow rule definitions and policies: In the network infrastructure of VANET systems, the forwarding tables mainly consists of the following three entries: (i) packet forwarding rules, (ii) one or more action corresponding each rule, and (iii) a set of counters associated with a data flow to keep track of the number of packets or bytes handled. However, the existing flow rules and policies in these types of networks need changes to handle the demands of VANET applications. For instance, the controllers could offload some of the tasks to the RSUs and BSs (base stations) which act as local controllers by sending general flow rules or policies instead of specific rules associated with a data flow. • Security and privacy aspects: In VANET systems, the controllers manage and control various networking resources, which makes it a priority to protect them from cyber attack. Dissemination of malicious information to the controller from adversaries can lead to severe accidents. In particular, DoS attacks present a dangerous threat to VANET systems, as attacks can be launched to stop controllers' operations. Hence, security vulnerabilities when integrating SDNs to VANET systems must be treated before these systems' deployment. • Scalability: Since nodes can join and leave the network at any time, scalability is a crucial issue in a VANET to maintain an acceptable degree of signal coverage. The prediction of the number of moving vehicles in a specific area and time of the day is very challenging. Therefore, in order to cope with an increasing number of nodes, the routing protocol should adapt to the network load. In this manner, hybrid protocols are a suitable solution specially when the network has less than 1000 nodes. • Energy efficiency: Recent VANET technologies demand energy conservation. Therefore, a good routing protocol for this kind of network should consume the least amount of power. Ad-hoc on-demand distance vector (AODV) and Optimized Link State Routing (OLSR) protocols have proven a suitable option for high-density networks with highly dynamic nodes. • Interworking with heterogeneous networks: The coexistence of heterogeneous V2X networks make necessary efficient interworking mechanisms that allow efficient communication between these networks. In the present scenario, the V2X networks have to compete with other type of communication systems such as cloud, 5G and Information-Centric Networking (ICN) applications.

IV. SAFESMART SYSTEM A. GENERAL OVERVIEW
Since the main issue addressed in this work is to coordinate traffic lights to create a quicker path for EVs, it is important to focus on application scenarios involving traffic intersections, which form the most common scenario the system is supposed to deal with. The scenario detailed in Fig. 1 illustrates one possible intersection, which represents the core of the system's application scenario: two emergency vehicles coming from different directions reaching a road intersection at approximately the same time. Naturally, it is also possible that only one EV will be at the intersection at a given moment, but the system should be able to cope with conflict situations where more than one EV show up at the same time. The transmitter in the EV communicates with the traffic light controller, which can control the state of all the traffic lights located at the intersection. The transmitter will send to the controller relevant data containing information about the EV's status, such as position, speed, and direction. The controller will then decide which request to handle (in the event there are several) and proceed to coordinate the traffic lights, ensuring a quicker and safer journey for the EV.
A flowchart containing the necessary steps, functions and actions is presented in Fig. 2. This is the broader view of the system, which aids the understanding of the finality of the proposed algorithm.
After start-up, the system must run a set of diagnostics to ensure that the system is performing as intended. If a fault is detected, the system must be stopped to prevent unpredictable situations that could endanger drivers and pedestrians. Diagnostics must, of course, be run cyclically. After this first integrity check, the algorithm continues with the data sent from the EV transceiver. It is also necessary to consider a rare scenario where two or more EVs are requesting a preemption to the RSU at a traffic intersection. Therefore, our system checks this issue and the even more unlikely case where all the EVs arrive at the same time at the intersection. This requires a priority decision as to which EV will have its request handled (e.g., fire trucks have priority over police cars). When no priority can be determined, the first arriving EV will be processed. Finally, the algorithm reaches its main objective: the coordinated change of the traffic lights state. This phase also includes returning the traffic lights to normal operation after the request has expired or the EV has cleared the intersection.

B. IN-DEPTH VIEW
At this point, it is necessary for the RSU to receive relevant information from the EV, such as speed, intended route and position. With this information, the RSU can then proceed to decide how to orchestrate the changes in the traffic lights to fulfil the request made by the EV. Information such as speed and position can also be used to decide which request to process in case there are simultaneous requests from different EVs. The RSU will also be able to tell when the EV has crossed the intersection, which allows the RSU to either handle another pending request or return to the normal state if there are no more requests.
The intention here is to have a general system that can work in any kind of topology, and thus it conforms to the standard ISO 19091 as closely as possible. The standard VOLUME 4, 2016 defines the message, data structures, and data elements to support exchanges between the roadside equipment and vehicles to address applications that are aimed at improvements in safety, mobility, and environmental efficiency [31].
The RSUs are assumed to have a network connection with a back-office processing centre (BOPC), as specified in the standard. Through this connection, the RSUs will receive, among other information, a MAP message containing detailed static information regarding the intersection where they are located. Since RSUs only have a limited range of action in terms of management and geographical reach, it is not necessary for every RSU to have complete knowledge of the entire map. Area-wide management and control is a function delegated to the BOPC. Therefore, from this point on, it is assumed that the RSUs have only full knowledge of the topology of the relevant section of the map.
The EVs are assumed to be able to transmit basic safety messages (BSM) or cooperative awareness messages (CAM), as well as processing the relevant messages received from the RSUs. Communication between vehicles and infrastructure is also received by other vehicles as long as it is broadcast by the entities. Non-relevant messages, however, are discarded and V2V communication is not considered part of the proposed system.
Each EV must broadcast BSM/CAM messages containing, at the bare minimum, its location, speed, heading and directional signals. According to the standard, the commonly assumed transmission rate of these messages is 10 Hz, and this is used in SafeSmart. The communications range is also assumed to be 300m at maximum. A bigger range of communications would most likely have a positive impact on the system's performance.
The RSUs continuously broadcast their signal phase and timing (SPaT) message, which indicates the current and future state of the traffic signals to nearby vehicles. When an EV receives this message for the first time, it becomes aware that there is a RSU in the vicinity. Similarly, the EVs will also receive the MAP message from the RSUs, which was previously sent to them by the BOPC. It is for the vehicle to judge which messages are relevant given its intended trajectory, as it is possible that in certain situations one EV will "hear" multiple RSUs at the same time.
Once a vehicle approaches an intersection of interest, the vehicle must send a signal request message (SRM), which is broadcast from vehicles to infrastructure, to properly request preemption of the traffic lights. The EV will then calculate an estimated time of arrival (ETA), which will be used to decide which request the RSU should handle first. In SafeSmart, because the intention is to accommodate priority requests, the RSUs will handle the requests as soon as possible to prevent possible traffic jams from delaying the EVs. There is also a trade-off between the EV's trip time and disruption to the general traffic flow regarding earlier or later activation of the traffic lights. This could possibly be changed dynamically, depending on the traffic conditions. SafeSmart, however, focuses on the EVs. Then, after the RSU receives the SRM, it must acknowledge the request by sending a signal status message (SSM), which is broadcast by the RSU to the nearby vehicles. This message contains feedback to the vehicles regarding which requests are currently being handled. The SPaT message will also contain information about the current state to allow the drivers to take appropriate action.
It is important to realize that, due to the uncertainty in the communications, none of the entities can assume that their messages have been received and acknowledged by the other entities, unless there is explicit confirmation. The entities must constantly monitor the status of the intersection and the messages received by other entities to be able to act appropriately if the circumstances change (e.g., an incoming vehicle with higher priority forces the RSU to adopt a new state to attend to that request).
When the EV has finally cleared the intersection, the RSU can be alerted by either a specific message from the EV or through the BSM/CAM messages which are being broadcast continuously from the EVs. When this happens, the RSU can return to normal operation by returning all the controlled traffic lights to their normal state or proceed to handle the next request made by another EV which has not yet cleared the intersection. The requests are handled in a FIFO fashion, unless there are requests from EVs with higher priority.
Summarizing it: SafeSmart is an application running in the RSUs and emergency vehicles, which will communicate with each other to optimize the traffic conditions. The communication is made by using well-defined messages which comply with well-known standards, such as BSM/CAM. The proposed system is not tightly coupled to one specific type of message and follows the ISO 19091 standard for communications in applications related to signalized intersections. The functionality of SafeSmart follows the use cases provided in the standard, which means that it is a solution designed to work in a general case, not only for a specific scenario. This also means that it is possible to deploy SafeSmart in different regions, where different standards are used (i.e., USA and Europe).

A. SIMULATION ENVIRONMENT
To implement, test and simulate the SafeSmart system prototype, two simulators were used: OMNeT++ [6] (Objective Modular Network Testbed in C++), a modular, componentbased C++ simulation library and framework, primarily for building network simulators; and SUMO (Simulation of Urban Mobility) [7], an open source, highly portable, and continuous traffic simulation package designed to handle large road networks was also used in the system setup. Fig. 3 shows the test scenario being simulated in OM-NeT++ environment. Since OMNeT++ focuses on the communication aspects between each node (vehicle), the Halmstad map is displayed using simple polygons. OMNeT++ is responsible for the message exchanges between each vehicle, which represent a crucial part of the proposed experiment.
It is also where the statistics collection was implemented to measure the trip times and collect safety metrics of each EV. Fig. 4 shows the test scenario as it appears on the SUMO simulator. SUMO simulates the urban mobility and traffic features, including traffic lights and EVs behaviour. The simulation shows only mobility-related aspects and does not take into account the communication aspects.  Both simulators are connected by the Veins framework, which manages, runs and monitors the simulation. This is achieved by using a TCP socket, while using a protocol defined as Traffic Control Interface (TraCI) for this data exchange. It is often necessary to retrieve information from the mobility (SUMO) nodes to compute speed, position, desired manoeuvres, etc., and this is achieved using TraCI.
By using this framework it is possible to achieve a bidirectionally coupled simulation, where the effect of the road traffic location will impact on the network traffic simulation and vice versa. With this it is possible to simulate realistic scenarios and to analyse the impact of different levels of traffic as well as other factors in the system.

B. EXPERIMENT DESCRIPTION
To provide a realistic scenario where the SafeSmart solution can be further improved and deployed into the real-world, the city map of Halmstad in Sweden was chosen as the simulation scenario for the evaluation of the SafeSmart system. Since the core of the system involves activating traffic lights to ensure an improved traffic flow, the most important part of the map is the main avenue shown in Fig. 5, containing points A and B. Depending on the type of manoeuvre performed by the EV, it is possible that the proposed system could have different impacts on the results. Additionally, the existing route between points A and B of Fig. 5 contains four traffic lights and it is possible that routes of different length generate different results as to the benefits of the system. Therefore, the experiments aim to determine what factors affect the results, and under which circumstances the benefits are greater or lesser.
It is thus possible to test a wider range of scenarios using more than one route. The common focus, however, of these experiments is on the main avenue, where the traffic lights being tested are situated. Every route reaches at least one of the traffic lights located on the main avenue at some point, and there are no other traffic lights on any points of the routes. All routes were tested one hundred times each to ensure that the results are meaningful and statistically relevant.

1) Figures of Merit
It is important to specify which results are to be collected and the factors that can affect them. There are two figures of merit proposed in this work. The first is a metric related to the time, in this case, the trip time. This metric measures the time an EV takes from the moment it spawns on the map to the moment it reaches its destination. Naturally, the desire is VOLUME 4, 2016 FIGURE 6. Traffic intersections in the emergency vehicle route.
for the system to reduce trip times as much as possible, as this would enable the EVs to reach their destinations faster.
The second figure of merit relates to safety, as it is hoped that the system will enable safer trips by the EVs as well. One of the most comprehensive metrics to measure the danger of imminent collisions is the time-to-collision (TTC) [32]. The lower the TTC, the more dangerous is the situation for the vehicles involved. The TTC is defined as the time two vehicles would take to collide if they maintained a constant speed and path. If two vehicles are not on a collision course, the TTC is infinite and not relevant. However, the raw TTC is not necessarily the best metric to evaluate the safety component of the simulations. It is easier to understand it with the aid of an example: two different situations, one in which the EV is exposed to a TTC of 1 second for a period of 1 second; the other one in which the EV is exposed to a TTC of 1 second for 2 seconds. It is easy to calculate that, in both cases, the average TTC is 1 second. However, considering that in the second case the EV was exposed to a relatively short TTC for a longer time, it is easy to realize that this case is less safe, where less safe means a higher risk of a collision. Therefore, in this work, the chosen safety metrics are two: TET (time exposed time-to-collision indicator) and the TIT (time integrated time-to-collision indicator), as defined by [33].
The TET metric is defined as the duration of the exposure to safety critical TTCs. In this work, the safety critical TTCs are the ones below the defined threshold of 5 seconds. According to [33], this threshold could be somewhere between 3 and 5 seconds. To avoid missing potentially interesting situations, a value of 5 seconds was chosen. Furthermore, the TET metric has been subdivided in this work. For instance, there are different variables to collect the TET metric of TTCs between 5 and 4 seconds, between 4 and 3 seconds, and so on. This way it is also possible to evaluate specifically the most critical TTCs and see how much the system impacts them.
The TIT metric can be better understood with reference to Fig. 7. The TIT metric takes into consideration the period of time the EV was exposed to a certain TTC, and how critical it is, provided it is below the defined threshold of 5 seconds. This is considered by adding, at each time instant, the absolute difference between the current TTC and the time threshold. For example, if at a certain moment there is a TTC of one second, the TIT will be incremented by the time threshold minus the TTC, multiplied by the period of the simulation step. In this case, the TIT would be increased by 4 seconds. Using these extended metrics, which are simply calculated and derived from the ordinary TTC has several advantages and enables a more detailed and meaningful safety analysis.

2) Simulation Factors
The factors which may affect the chosen figure of merit can be considered the input of the simulation, where any change in any one of them might produce a different output (in this case, the trip time). The inputs of the simulation are: • The map of where the simulation takes place: in this case, it is a part of the Halmstad map. This includes geometry and general parameters (e.g., maximum speed permitted, exclusive lanes). • The traffic lights: their set of states, how much time the lights stay in a particular state and whether SafeSmart is in use or not. • Vehicles: any kind of parameter that can effectively cause any difference in the behaviour of one or more vehicles (e.g., a set of vehicles which form the background traffic, types of vehicles (EV or passenger), spawn time, proposed route). In a more general scenario, there might be even more parameters that could affect trip times, such as probabilistic edge changes, for example. However, these are not being used and therefore are not considered in this work.
Since the simulations contain a huge number of variables, most of the input variables are to remain fixed during the tests. For instance, the network communication parameters remain the same in all the experiments. The chosen propagation model is the path loss model, which decreases the signal's power by adding attenuation over time, based on the distance and wavelength of the signal. The path loss exponent used is 2 and the transmission power is 20mW . The obstacle shadowing model used is the default one included in Veins, with 9 dB per cut and 0.4dB per meter. The obstacles were extracted and converted from OpenStreetMap [34], which contains data that mimics real-life cities for more realistic experiments. The higher layers use models of the DSRC/WAVE stack according to the standards.
However, there are several factors which are considered sufficiently interesting for inclusion in the analysis of the proposed system. These are: Due to the complexity of the simulations, especially with an increased amount of background traffic, it is possible that changes in any of the variables produce a hugely different outcome. This makes it very difficult to discern whether the system works well or not based only on a very small number of experiments. It is possible, for example, that an experiment using SafeSmart yields a worse trip time in specific cases, even if it ultimately improves the average trip times.
This can be seen with an example, presented in Figure 8. Assume that EV B arrives at the intersection before EV A. As it wants to turn left, it will likely have to activate the traffic light just ahead of EV A, which would cause the passenger vehicles ahead of EV A to stop. In the figure, only two vehicles are shown near each EV, but in scenarios with high traffic levels, there could be dozens of passenger vehicles.
With this example in mind, it is possible to observe that trip times are rather volatile. A change in one of the input variables might yield a very different result. The presented example is only one scenario, but similarly, even on scenarios without SafeSmart, the same effect might be seen. Adding one more vehicle or changing one vehicle's proposed route might result in a huge traffic jam at one of the intersections. This situation would certainly increase the trip times for EVs which have to go through that intersection, and possibly others.
Therefore, each different set of input variables yields a different scenario, and many different scenarios must be considered to reach a realistic conclusion as to whether the system improves the trip times or not. To achieve that, the proposed tests comprise four different levels as follows: focus is on the case of 1 EV, since several EVs coming from different directions at the same time is less likely to occur. It is important to notice that, even in the cases where only 1 EV is considered, the same application scenario could be extended to several EVs coming from the same direction since they would all be affected equally using SafeSmart; • Routes: the routes contain different numbers of traffic lights which the EV must traverse, and also different manoeuvres (e.g., turn left, turn right, straight ahead and U turn).
The results might also depend on the current state of the traffic lights. For example, if the EV is spawned when it might allow it to traverse a green wave, the improvement of SafeSmart could seem more limited. Therefore, to avoid this possible effect, all runs were distributed equally in a time frame that corresponds to the longest period of the traffic lights. For instance, the longest period of the traffic lights included in the simulation is 80 seconds, which means that the simulations included the EV(s) spawning in a starting time plus a time offset between 0 and 80 seconds. In this way it is possible to discount the possible influence that the period of the traffic lights might have. This also provides a more realistic evaluation of the system's performance, since there is no guarantee at which moment the EV will arrive at a given intersection.
There is also an interest in evaluating conflict scenarios, which is why one of the proposed simulation factors is the number of EVs. As mentioned earlier, considering that it is unlikely that several EVs will arrive at the same intersection, at the same time and from different directions, the focus is on cases with just one EV. However, it is also important to test and evaluate whether the network factors could also impact the results. Therefore, two cases, one with two EVs and one with three EVs are proposed. VOLUME 4, 2016 The general view of the routes is shown in 9. There are four traffic lights in the map. Different numbers of traffic lights will be tested with all types of proposed manoeuvres. From the starting point here, the shortest routes with only one traffic light do not allow the option of turning left. In this case it means that there will be only right turn, straight ahead and U-turn routes.

FIGURE 9. General route overview
A visual representation of the conflict scenarios can be seen in Figure 10. Here there are three different defined routes, namely S2, C1 and C2. Route S2 is the same as the route which passes through two traffic lights and goes straight ahead, hence the name. This will allow comparisons between cases with and without conflict. Routes C1 and C2 have only been purposely inserted to cause a conflict. There are some interesting points about this test: first, it is worth noting that each one of the routes will activate the traffic light at the intersection in different ways. However, this does not necessarily mean they interfere with one another. In fact, closer analysis shows that C1 and C2 will activate the traffic lights in very similar ways, and they do not actually conflict with one another. However, both will attempt to stop vehicles coming from the direction of route S2 to ensure they can cross the intersection safely.
Another interesting point concerns the length of the routes. As Fig. 10 shows, C2 is the shortest of the routes, then C1 and the longest is S2. This most likely means that traffic on C2 would be the first to arrive at the intersection, and so the first to change the state of the traffic light. C1 would be next and finally, S2. Of course, traffic jams and other dynamic factors can alter this, but it likely that route S2 would be the route most affected in the conflict scenario.
There are two proposed conflict scenarios: one with S2 and C1 and another one involving all three routes. In the first scenario, it will be possible to assess how much impact route C1 will have on route S2. This is, of course, evaluating the worst-case-scenario in terms of conflict and time/safety improvement, considering that route S2 starts very close to the conflict area. This means that the conflict area represents 50% in terms of intersections contained on that route. The second scenario can then evaluate how much S2 is impacted with two different EVs, and determine whether routes C1 and C2 will impact one another. If there is major interference between routes C1 and C2, it might be because of communications interference, or other network-related issues, considering that their trajectories do not interfere with each other.
Furthermore, to make the tests more realistic, all experiments were conducted using the SUMO sublane model, which allows passenger vehicles (background traffic) to form a virtual middle lane to allow the EV to pass. This is considered important in modelling the willingness of drivers to react to EVs in real scenarios, as opposed to passively waiting in the traffic jam and blocking the path. Though this promotes realism, it does not solve all the traffic jam problems, some of which are unlikely to occur in real life. This has been attributed to a limitation of the simulators, and to try to mitigate it as much as possible, SUMO allows vehicles to be teleported to the next edge after it is stuck for a user-defined time at the same place. In the simulations performed here, this time was set as double the time of the longest traffic light phase to avoid vehicles being teleported while waiting for the traffic light to turn green.
Furthermore, EVs are allowed to cross on red traffic lights and exceed the road speed limit. In this case, EVs were allowed exceed the limit by 10%.

VI. RESULTS & DISCUSSION
The first batch of results is presented in Table 1. These experiments comprised routes containing only the first traffic light, as proposed earlier. The table contains a description of which manoeuvre has been performed by the EV (bearing in mind that a left turn is not an option at that point on the map), how heavy the traffic was (expressed as cars per second) and the results for trip times and TIT for cases with SafeSmart enabled and disabled. Apart from enabling SafeSmart, all the parameters remain the same throughout the tests.
At first glance, the results might imply that there is no significant benefit using SafeSmart. However, the issue is not that SafeSmart did not impact the traffic in a meaningful positive or negative way. If the results of the cases with the least heavy traffic and the heaviest are compared, a very slight change can be observed in the trip times and TIT values, even in the cases where SafeSmart was not used. This means that the proposed increase in the traffic density did not impact significantly on the EVs and the surrounding traffic. This could be because the route is much too short and the EVs spawn too close to their destination, or because of the topology of the map, which might allow a consistent traffic flow in that part of the map. Therefore, even when SafeSmart is not used, the difference in the results is quite small and the cases involving a single traffic light will be ignored in the subsequent analysis. This is done without any loss of generality, since in a real situation, the EVs can be located at any place within the map, and it is unlikely they will be too close to their destination. Furthermore, SafeSmart had no negative impact in either of the proposed metrics, which means it is safe to use even in this very specific case where the EVs are near their destination points.
The results of the first of the more complex scenarios, where routes contain two traffic lights, is shown in Table 2, which has detailed numbers for the experiments. Figures 11  and 12 also present a visual representation of the trip time and TIT improvements in different scenarios, respectively.
In contrast to the scenarios with a single traffic light, in these scenarios, a considerable difference in the trip times can be seen as the traffic density increased. This is shown in the column "Trip Time (s)". This demonstrates that these cases are meaningful in terms of room for improvement, unlike the first case. Figures 11 and 12, show that in every single case there was considerable improvement in both trip times and TIT. This means that SafeSmart had no adverse effect on performance as represented by the two metrics previously defined. It also clearly improved the path of the EV in terms of time and safety. Note that Figure 12 is shown from a different perspective (and therefore the values of the axes are in a different order) for better readability. This is also valid for other Figures depicting TIT improvements, as the general trend seems to indicate fewer TIT improvements as traffic density increases.
Regarding the different manoeuvres, notably the left turn, routes showed the smallest improvement in TIT and the lowest peak value for trip time improvements, though they were still extremely satisfactory. The smallest improvement in trip time was 12.122% on the straight-ahead route, with 1 car per second. For the TIT metric, the smallest improvement was 44.673% in the left turn route with 4 cars per second. This clearly shows that SafeSmart had a very positive impact in both metrics in all the various tested scenarios containing two traffic lights. Continuing with the analysis for the cases with three traffic lights, considering the general trends shown in Figures 13 and  14, it is possible to say that all scenarios had a considerable improvement in the time and safety metrics. The results are, in fact, more consistent and even more positive than in the cases with two traffic lights.
Regarding the different manoeuvres, the results show a very similar trend when compared to the cases with two traffic lights. Once again, the left turn had a smaller improvement in TIT when compared to other manoeuvres. The trip time improvement shows similar values to the U-turn manoeuvre. This is not surprising considering that the start of the U-turn is very much the same as turning left, so it is understandable that they share common aspects in the results as well. Analysing the cases with four traffic lights, it is possible to see a much more uniform trend on all scenarios. This can be seen in Figures 15 and 16, which show improvements in  Table 4, all different manoeuvres had a similar improvement in most cases. Unlike in the previous cases, there seems to be less difference even in manoeuvres like left turn and u-turn. This is probably because the impact of the manoeuvre has been averaged out by the longer route, which  The conflict scenarios involve the three routes which were previously mentioned, namely S2, C1 and C2. The individual comparison between scenarios with and without conflicts can be seen in Figures 17 to 22, which show TIT and trip time metrics for all the conflict routes. Analysing route S2 (Figures 17 and 18), it is possible to notice that there is a significant decrease in the improvement of both trip time and TIT metrics. This is expected considering that S2 is considerably longer than C1 and C2, causing the EV in the S2 route to reach the intersection after the other routes. This leads to a certain delay in clearing the background traffic, which explains the smaller improvements. Still, even in this incisive conflict case, SafeSmart managed to improve both time and safety aspects of S2.
When analyzing C1 and C2, it is possible to see that the impact of the conflict scenarios was not as meaningful as it FIGURE 16. Results of TIT improvements for routes containing four traffic lights was in route S2. This is expected, considering that C1 and C2 can work together in a more cooperative fashion, meaning that they do not block each other's traffic flows. This can be visualized in Figure 10.
A further point of interest arises from the scenario with all three routes. Regarding the length of the routes, it is highly likely that C2 would arrive at the intersection before C1. This means that when C1 is within the communication range of the RSU, it is very likely that C2 would have already sent a request to alter the state of the traffic lights. If these two routes caused network interference in each other's communications, probably both (but at least one of them) would be negatively impacted by the conflict scenario. Considering that there was no significant impact on the scenarios with conflict, it can be concluded that communications interference does not present a problem for SafeSmart. It is already a very unlikely scenario that two EVs would arrive at an intersection at the same time and from different directions. Still, even in this unlikely scenario, SafeSmart performed  The results of the conflict scenarios are presented with more detail in Table 5. There is a column for each route and for each of the two metrics. Route C2 was only included in the scenario with three EVs, which is why the "Conflict x1" line is blank for this route.
It is important to note that even using SafeSmart there is still a considerable variability with the trip times. This is probably due to the traffic jams, such as those shown in Figure 23. Although using SafeSmart reduces the likelihood of traffic jams affecting the EV trip times, it does not eliminate them.

VII. CONCLUSION AND FUTURE WORK
This paper introduces SafeSmart, a VANET-based system for EV communication. The proposed algorithm closely followed the guidelines of ISO 19091, which means the system can be used in all scenarios contemplated by the standard, being a powerful and easily adaptable solution. There is FIGURE 18. Results of TIT improvements for route S2 under scenarios with and without conflict no single case of increased danger (expressed by the safety metric TIT) or time using SafeSmart. The conclusion to be drawn is that the system is extremely useful and safe for a multiplicity of real-life emergency scenarios.
As a future step, it is important to simulate and ensure that security mechanisms can be implemented alongside the proposed algorithm without compromising its functionality. The possibility of an attacker being able to alter the states of the traffic lights is extremely serious, therefore it is crucial that security mechanisms are deployed with SafeSmart in real-life scenarios.
In addition, it would be very useful to develop a dynamic traffic light control protocol to determine the best distance from which to activate the traffic lights. Activating them too soon could disrupt the traffic going in other directions, even causing traffic jams. Activating too late could cause problems for the EV since other road users might not have enough time to clear the path before the EV arrives and thus waste valuable time. It is also necessary to ensure  very useful in determining the impacts of different strategies. There is probably a compromise between background traffic disruption and optimizing the trip time/safety of an EV. Having metrics to quantify such interference would be important in finding an optimal solution. Furthermore, even more important than general traffic disruption is ensuring that the proposed system does not negatively affect the safety of the passenger vehicles. Collecting data to measure the safety using the proposed safety metrics is also an important next step. Finally, another form of interference that must also be considered is that caused to the communications by other vehicles broadcasting their own messages. As the penetration of V2X technology grows, the interference issue will become increasingly important. The simulations here have been conducted on the assumption that the only vehicles capable of vehicular communication are the EVs. For now, this might be (almost) true, but in the future, it is quite possible that there will be an entirely different scenario. This could affect the reliability of the system, as the range of communications would probably decrease in a scenario with many vehicles transmitting at the same time. However, for a small number of vehicles, it is clear from the experiments that interference had no significant impact on the results.