Enabling performance and security simulation studies of intelligent traffic signal light control with VENTOS-HIL

JID:VEHCOM AID:100230 /FLA

[m5G; v1.261; Prn:30/01/2020; 14:36] P.1 (1-12)

Vehicular Communications ••• (••••) ••••••

1

67

Contents lists available at ScienceDirect

68

2

69

3

Vehicular Communications

4

70 71

5

72

6

www.elsevier.com/locate/vehcom

7

73

8

74

9

75

10

76

11 12 13

Enabling performance and security simulation studies of intelligent traffic signal light control with VENTOS-HIL

77 78 79 80

14 15 16 17 18 19

a

a

a

b

Bryan Ching , Mani Amoozadeh , Chen-Nee Chuah , H. Michael Zhang , Dipak Ghosal

c

a

22 23 24 25 26 27 28 29 30 31 32

82 83

Department of Electrical and Computer Engineering, University of California, Davis, CA, USA b Department of Civil and Environmental Engineering, University of California, Davis, CA, USA c Department of Computer Science, University of California, Davis, CA, USA

84 85 86

20 21

81

a r t i c l e

i n f o

Article history: Received 17 September 2019 Received in revised form 26 November 2019 Accepted 2 January 2020 Available online xxxx Keywords: VANET simulators Collaborative driving Simulated security attacks Traffic signal control V2X communication

33 34 35 36 37

87

a b s t r a c t

88

Vehicular Ad-hoc Network (VANET) simulators have gained widespread adoption in the research community given the fact that they can simulate near real life scenarios to evaluate driver-safety applications without endangering human lives. In this paper, we present the VEhicular NeTwork Open Simulator (VENTOS), a closed-loop VANET simulator that combines the capabilities of both communication network (OMNET++) and vehicular traffic simulators (SUMO). As an alternative to current proprietary VANET simulators, VENTOS is a free, open-source simulator that is designed for vehicular traffic flow analysis and can incorporate new control logic, such as intelligent traffic controller, collaborative driving, dynamic routing, and self-driving capability. VENTOS supports V2X (Vehicleto-Vehicle or Vehicle-to-Infrastructure) communication through dedicated short-range communication (DSRC) integration. This paper will give an overview of the VENTOS architecture and its extension, VENTOS-HIL, which supports hardware-in-the-loop emulation using physical devices such as On-Board Units (OBUs) or Roadside Units (RSUs). We then demonstrate how VENTOS can be utilized to simulate and evaluate the performance of multi-modal, adaptive traffic signal control (TSC) as well as to illustrate the security vulnerability of intelligent TSC in the presence of falsified data attacks. © 2020 Elsevier Inc. All rights reserved.

89 90 91 92 93 94 95 96 97 98 99 100 101 102 103

38

104

39

105

40

106 107

41 42

1. Introduction

43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

A vehicular ad-hoc network (VANET) is a communication network formed by a group of vehicles equipped with the necessary hardware and software that make V2X wireless communication possible. VANETs can use a number of wireless networking technology, which includes dedicated short-range communication (DSRC) [1], cellular networks [2], visible light communication [3], and emerging 5G technology. VANET enables a number of applications ranging from infotainment [4] to safety [5] and efficiency [6]. Additionally in VANETs, vehicles can act as both mobile sensors (i.e. collecting data) and mobile routers (i.e. relaying data) and are connected together to form a grid network that is suitable for distributed computing and data dissemination. Accurate simulation of VANETs is a challenging task, requiring both road traffic and network simulators. There is a large number of traffic and network simulators developed independently over the years. Since different VANET simulators can yield different results for different research applications, each research community

61 62 63 64 65 66

E-mail address: [email protected] (C.-N. Chuah). https://doi.org/10.1016/j.vehcom.2020.100230 2214-2096/© 2020 Elsevier Inc. All rights reserved.

relies on their own specific simulator. This issue is addressed in [7], in which they created a framework that allows users to switch between different VANET simulators to meet their applications’ needs. Road traffic simulators are responsible for generating mobility models that accurately reflect vehicular traffic. On the other hand, network simulators handle the wireless communication among the vehicles. Existing VANET simulation platforms fall into two categories: open-loop and closed-loop. In open-loop simulators, the mobility traces for each vehicle are treated as input for the network simulator as shown in Fig. 1. The main disadvantage to open-loop simulations, however, is that they are not capable of simulating dynamic traffic behavior changes as a result of dynamic information exchanges. For instance, vehicles need to update their traffic behavior, such as speed and route maneuvering of the vehicles, after receiving new information through V2X and V2V communications. On the other hand, closed-loop simulations have the road traffic and network simulators working closely together, in which the traffic simulator continually specifies the vehicles’ movements throughout the simulation [8]. The conclusions drawn from a VANET simulation highly depend on the underlying mobility model. In other words, a realistic mobility model ensures that

108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132

JID:VEHCOM

AID:100230 /FLA

[m5G; v1.261; Prn:30/01/2020; 14:36] P.2 (1-12)

B. Ching et al. / Vehicular Communications ••• (••••) ••••••

2

simulated using VENTOS. More specifically, Section 4 depicts a hardware-in-the-loop (HIL) emulation study of a traffic prioritization scheme for public transportation or emergency vehicles by supporting communication between on-board units (OBUs) and roadside units (RSU) co-located with TSC. Section 5 presents a simulation study comparing the performance of different traffic actuated (TSC) algorithms. Section 6 discusses the security vulnerabilities of intelligent intersections involving TSC algorithms. In Section 6, VENTOS is utilized to simulate and evaluate the impact of different security attack scenarios involving falsified messages between vehicles and TSC modules. Finally, Section 7 concludes the paper.

1 2 3 4 5 6 7 8 9 10 11 12

2. Related works

14 16 17

Fig. 1. Block diagram of VANET simulators’ coupling.

18

21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63

69 70 71 72 73 74 75 76 77 78 80 81

15

20

68

79

13

19

67

the results from simulations will carry over to real-world deployments. The connectivity and communication of VANET nodes are important for a wide array of applications, such as real-time traffic monitoring. In other mobile ad-hoc environments, node movement is often assumed to be random. In contrary, vehicular nodes are constrained to streets separated by various obstacles that can degrade signal strengths for node connectivity [9]. As discussed in [10], there are numerous vehicular mobility models, each classified as either macroscopic or microscopic. Macroscopic models focus more on the high-level view of vehicular traffic, which includes traffic density, traffic flow, and motion constraints. Microscopic models, on the other hand, are more concerned with the movement of each individual vehicle and how these individual vehicles interact with each other. Integrated VANET simulators, such as TraNS [11], iTETRIS [12], VSimRTI [13], and Veins [14], create a bidirectional interaction between a network and a road traffic simulator in a closed-loop fashion in order to exchange vehicle mobility data and to influence the vehicles’ behaviors. Application development in some integrated VANET simulators is done in a separate application simulator, such as MATLAB. The separate application simulator is then interfaced with the network or road traffic simulator using pipe, COM (Component Object Model), or network sockets. This paper introduces an integrated simulator, Vehicular Network Open Simulator (VENTOS), which is capable of simulating detailed information exchanges via VANET and microscopic vehicular movements. VENTOS has been successfully utilized to develop and evaluate platoon management protocols [15], study the security of connected vehicles [16,17], and evaluate dynamic vehicular traffic routing [18]. VENTOS comprises of the OMNET++1 network simulator and the SUMO2 road traffic simulator. The VENTOS framework had been presented at the 10th annual international conference on Ambient Systems, Networks, and Technologies (ANT) [19]. In the ANT paper, we demonstrate the use of VENTOS in studying the performance of different traffic signal control (TSC) algorithms and hardwarein-the-loop (HIL) support. This journal submission extends our previous work [19] by including simulated security attacks and demonstrates our simulator’s ability to incorporate real-life maps. The remainder of this paper is organized as follows. Section 2 discusses the various VANET simulators currently available in the research community. Section 3 describes the VENTOS architecture and its underlying network and traffic simulator components. Sections 4, 5 and 6 offer a few example applications that can be

64 65

1

66

2

Link to OMNET++ homepage: https://omnetpp.org/. Link to SUMO homepage: http://sumo.dlr.de/index.html.

The most important aspect of VANET simulators is that they require the integration of vehicular traffic and wireless network simulators. Research and development in VANET simulators have been conducted for years and each of these simulation platforms have varying degrees of vehicular modeling accuracy. In this section, we discuss the current state-of-the-art of VANET simulation platforms and their various functionalities. GrooveNet is one of the first VANET simulators, which offers various modes of operation, simulates different types of nodes, and loads real-world street map topologies. Operating in hybrid mode, GrooveNet can simulate scenarios involving both real and simulated vehicles. Using the US Census Bureau’s TIGER/Line map database, GrooveNet has access to real-world map topologies. Moreover, GrooveNet allows for Vehicle-to-Vehicle (V2V) communication through DSRC and Vehicle-to-Infrastructure (V2I) communication through cellular communication methods [20]. iTETRIS is an EU-funded simulation platform designed specifically for the implementation of language-agnostic cooperative Intelligent Transportation System (ITS) applications and services (i.e. iTETRIS can be integrated with ITS applications written in any language). Moreover, iTETRIS’s modules are standard compliant with European Telecommunication Standards Institute’s (ETSI’s) architecture for ITS Communication, which allows this simulation platform to produce realistic and large-scale ITS system modeling [12]. V2X Simulation Runtime Infrastructure (VSimRTI) is a powerful framework that allows users to seamlessly integrate and exchange simulators. VSimRTI’s flexibility allows users to select and couple simulators that more accurately represent their research scenarios. From the get-go, VSimRTI is packaged with ready-to-use traffic (e.g. VISSIM and SUMO) and network (e.g. JiST/SWANS and OMNeT++) simulators [13]. Vehicles in Network Simulation (Veins) is one of the most widely known VANET simulators in the research community. Similar to VENTOS, Veins integrates OMNET++ and Sumo into a hybrid simulation framework. Veins emphasized the importance that bidirectionally coupled network and traffic simulators have in V2X scenarios [14]. Extensions based on veins include Plexe [21], and Artery [22]. Plexe supports realistic simulations of automated carfollowing systems and platoon management protocols. Artery, on the other hand, follows the European specifications for V2X communication and implements the ETSI ITS-G5 protocol stack that supports short range communications dedicated to automotive intelligent transport systems (ITS) and road transport and traffic. VENTOS is an integrated VANET and vehicular traffic simulator that simplifies the configuration process and allows its users to test a multitude of complex simulation scenarios. Nodes can be added into the simulation, such as obstacles in the middle of the road and vehicles entering the simulation at various rates. Additionally, users can edit vehicle parameters and introduce new control logic to implement collaborative driving, such as cooperative automated cruise control (CACC) and platooning. VENTOS can be leveraged

82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132

JID:VEHCOM AID:100230 /FLA

[m5G; v1.261; Prn:30/01/2020; 14:36] P.3 (1-12)

B. Ching et al. / Vehicular Communications ••• (••••) ••••••

1

3

67

Table 1 Function comparison of the most relevant V2X simulators.

2 3 4

VENTOS

Veins

Plexe

Artery

V2X message exchange

Yes (WAVE) Yes Yes Yes Yes Yes Yes Partial Yes Yes

Yes (WAVE) No No No No No No No No No

Yes (WAVE) Yes Partial No No No No No No Yes

Yes (ITS-G5) No No No No No No No No No

5

ACC/CACC car-following models Platoon management (merge, split, entry, leave) Traffic signal control (TSC) algorithms Communication with Econolite COBALT Simulations of security attacks Hardware in the loop SAEJ2735 support Dynamic traffic routing Post processing scripts

6 7 8 9 10 11 12 13

68

Description

16 17 18 19 20 21

to study the impact of adversarial security attacks in collaborative driving and can simulate different classes of vehicular traffic and their responses in the presence of various traffic signal control (TSC) algorithms. Table 1 summarizes function comparisons of VENTOS and the most relevant V2X simulators that are still actively being developed/supported.

22 23

3. Vehicular network open simulator (VENTOS)

24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

VENTOS [23] is a simulator designed for vehicular traffic flow analysis and for modeling collaborative driving as well as interactions between vehicles and infrastructure through DSRC-enabled wireless communication. VENTOS is released as an open-source project to support the V2X research community in transportation engineering, control theory, and vehicular networking fields. Researchers can design and evaluate their own algorithms. VENTOS can be used as a toolbox to build more complex simulation frameworks by extending its code or by adding custom developed algorithms. Using a common tool like VENTOS makes the implemented algorithms and protocols more comparable. VENTOS has been used and cited by numerous researchers from different institutions.3 VENTOS couples two well-known simulators, SUMO and OMNET++, which are used for road traffic simulation and wireless communication simulation, respectively. Unlike some integrated VANET simulators, application simulation is done in the application layer of the network simulator. External libraries are linked with the application layer code and inter-process communication is achieved through network sockets. One can start a MATLAB engine from within a C++ program using the MATLAB Engine API for C++. In the following sections, we will discuss why we chose SUMO and OMNET++ for our system.

that supports various operating systems (Linux, Windows, and macOS). This program has been around since 2000 and has an active user base. SUMO supports microscopic simulation as well as multi-modal traffic (cars, pedestrians, bicycles, etc.). By using the Traffic Control Interface (TraCI) protocol, SUMO can communicate with external applications. Lastly, SUMO does not pose any strict limitations on the size of the simulation scenario. SUMO provides the TraCI which allows an external application to retrieve information from the traffic simulation or to influence the simulation behavior. TraCI uses a TCP-based client/server architecture in which SUMO acts as the TCP server and the external application acts as the TCP client. When started in TraCI mode, SUMO only prepares the simulation and waits for an external application to take control. SUMO provides and maintains the TraCI client library in C++ and Python. Other people have developed the TraCI client library in Matlab (TraCI4Matlab) [24] and the SOAP (TraaS) [25]. VENTOS provides another set of C++ APIs and allows you to develop more complex programs with less hassle. The above simulators do not have a physics engine due to their pure high-level nature. A physics engine provides very accurate vehicle dynamics in response to driver controls such as steering, throttling, and braking in a given environment. CarSim and PreScan are popular physics-based simulators that are widely used in the industry. They support a variety of vehicle sensors, such as radar and camera, for ADAS development. Integrating a physics-based simulator into a VANET simulator shown in Fig. 1 makes autonomous vehicle simulation possible but is out of the scope of this paper. MDDSVsim [26] is a traffic simulation platform for autonomous vehicles that integrates VISSIM as a microscopic multi-modal road traffic simulator, OPNET as a discrete event network simulator, and MRDS as a simulator for the physics of vehicles.

3.1. SUMO road-traffic simulator

3.2. OMNET++ network simulator

52 53 54 55 56 57 58 59 60 61 62 63

VANET simulation requires high-fidelity vehicle movements that can be obtained using microscopic road traffic simulators. A microscopic road traffic simulator should be able to handle a largescale network with high degrees of vehicle mobility. Vehicles can only move along streets according to a traffic model that defines the car-following and lane-changing behavior. A road traffic simulator should also incorporate vehicle emissions, fuel consumption, electric vehicle models, and driver behavior. There exist many commercial microscopic road traffic simulators, such as VISSIM and PARAMICS, but they require paid licenses. On the other hand, SUMO (Simulation of Urban Mobility) is widely accepted as a publicly available road traffic simulator among VANET researchers. SUMO is a free, open-source software

64 65 66

72 73 74 75 76 77 78 79 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 115 116

50 51

71

114

48 49

70

80

14 15

69

3

Link to publications list: http://maniam.github.io/VENTOS/#publication.

A network simulator, on the other hand, equips vehicles with a protocol stack that enables them to communicate with each other and with a Road Side Unit (RSU). The physical layer should support IEEE 802.11p and implements radio wave propagation models to accurately predict the path loss, multi-path fading, and shadowing effects of the wireless communication channels. Ideally, the physical layer should also support cellular networking, such as LTE, as well as visible light communication. Higher networking layers should support TCP/IP as well as the DSRC/WAVE protocol stack, including the SAE J2735 message sets. OMNET++ is a popular open source network simulator for non-commercial use. It comes with many simulation frameworks, which includes INET (TCP/IP stack) [27], MIXIM/Veins (DSRC/WAVE stack) [14], SimuLTE (LTE cellular network) [28], and CAN (Controller Area Network) [29]. Hence, OMNET++ is a good candidate for network simulation in VANET.

117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132

JID:VEHCOM

AID:100230 /FLA

[m5G; v1.261; Prn:30/01/2020; 14:36] P.4 (1-12)

B. Ching et al. / Vehicular Communications ••• (••••) ••••••

4

1. addNode: This module allows users to add fixed (RSUs, obstacles, etc.) and mobile (cars, pedestrians, bicycles, etc.) nodes. Furthermore, flows of vehicles as well as homogeneous and non-homogeneous platoons can all be inserted into the simulation. The user needs to define nodes in the addNode.xml file. The addNode module reads this file and decides which nodes should be inserted at the beginning of the simulation. 2. trafficControl: This module allows users to control the vehicular traffic by changing vehicles’ speeds, performing platooning maneuvers, etc. The speeds of vehicles can be changed according to a function of time in which the evaluation of this speed function is done using the ExprTk library [30]. Traffic control commands need to be defined in the trafficControl.xml file. The trafficControl module reads this file and decides how and when to affect the vehicular traffic.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 17

More detailed information about the XML file format can be found in the VENTOS manual [31].

18

Fig. 2. Simplified functional architecture of VENTOS.

4. Hardware-in-the-loop simulation example

22 23

3.3. VENTOS architecture

25 27 28 29 30 31 32 33 34 35 36 37 38 39

70 71 72 73 74 75 76 77 78 79 80 81 83 84 86 87

21

26

69

85

19

24

68

82

16

20

67

A simplified VENTOS architecture is shown in Fig. 2. VENTOS improves upon the state-of-the-art by implementing additional car-following models for vehicles with Automated Cruise Control (ACC) and CACC in SUMO, supporting many common TSC algorithms, and extending the TraCI commands for connecting to external applications. VENTOS is closely coupled with SUMO through TraCI, uses the mobility information of cars, pedestrians, and bicycles to perform realistic simulation, and can dynamically change the behavior of microscopic traffic simulations. Our simulator leverages Veins for IEEE 802.11p wireless V2X communication. Additionally, VENTOS has defined two modules that simplify the process of generating traffic demand and help users design more complex V2X scenarios more easily:

VENTOS can be extended to have HIL capabilities, which we will refer to as VENTOS-HIL. VENTOS-HIL is designed to emulate complex V2X scenarios by incorporating real hardware. Fig. 3 shows the functional architecture. Physical (On-board Units) OBUs and/or RSUs are connected to a computer that is running VENTOS. For each physical device connected to the computer, there is a corresponding virtual OBU or RSU in the simulation. Any actions performed on the physical devices are reflected in the simulation itself and vice versa. We demonstrate a VENTOS-HIL simulation using the Emergency Electronic Brake Light (EEBL) application in which two physical OBU devices are connected to the computer. The EEBL application enables a vehicle to broadcast a self-generated emergency brake event to surrounding vehicles. Upon receiving the event information, the receiving vehicle determines the seriousness of the event. If the event is deemed an emergency, then the EEBL system provides a warning to the driver to avoid a crash. This application

88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

40

106

41

107

42

108

43

109

44

110

45

111

46

112

47

113

48

114

49

115

50

116

51

117

52

118

53

119

54

120

55

121

56

122

57

123

58

124

59

125

60

126

61

127

62

128

63

129

64

130 131

65 66

Fig. 3. Functional architecture of VENTOS-HIL.

132

JID:VEHCOM AID:100230 /FLA

[m5G; v1.261; Prn:30/01/2020; 14:36] P.5 (1-12)

B. Ching et al. / Vehicular Communications ••• (••••) ••••••

5

sends an EB signal back to vehicle #2. Vehicle #2 subsequently does a hard break to prevent rear-end collision.

1 2 4

5. Simulation study of traffic signal control algorithms

6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

23

Fig. 4. HIL simulation using Emergency Electronic Brake Light (EEBL). (For interpretation of the colors in the figures, the reader is referred to the web version of this article.)

24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

is particularly useful when the driver’s line of sight is obstructed by other vehicles or by bad weather conditions (e.g. fog or heavy rain). This HIL simulation is implemented using one specific platform, Redpine Signals WaveCombo.4 However, due to the modular design of VENTOS, the concept can be easily extended to other platforms. The machine that is running VENTOS is connected to the board via Ethernet and VENTOS main simulator communicates with the board through SSH connection. The data and control instructions are exchanged between VENTOS and a small control program that is running on the board. In this simulation, there are four vehicles traveling in the same direction on a two-lane street. This scenario is simulated in VENTOS as shown in Fig. 4. One vehicle is equipped with OBU #1 and is denoted as the red car (Vehicle #1), while a second vehicle is equipped with OBU #2 and is denoted as the green car (Vehicle #2). These two vehicles are referred to as emulated vehicles. Vehicles #3 and #4 have not been equipped with physical OBUs and only exist in the simulated VENTOS environment as the two yellow vehicles. All vehicles can still interact with each other in the simulation through the 802.11p standard, regardless if they are equipped with physical OBU devices. Pressing the button on OBU #1 triggers a hard break on vehicle #1. OBU #1 generates an Emergency Break (EB) signal and sends it to vehicle #1.5 Vehicle #1 breaks hard as soon as it receives the EB signal. At the same time, OBU #1 creates a Basic Safety Message (BSM) [32] and passes it down the DSRC/WAVE protocol stack. The BSM frame is then sent to vehicle #1 where it is then broadcasted in the simulation environment. Vehicle #2 and #3 are in the coverage area of vehicle #1 and receive the BSM frame. Vehicle #3 reacts by slowing down to prevent a rear-end collision and vehicle #2 forwards the received BSM frame to OBU #2. The BSM frame goes up OBU #2’s DSRC/WAVE protocol stack to the application layer. The running program in the application layer flashes a visible LED or sounds an audible alert to notify the driver and

61 62 63 64 65 66

70 71

5

22

68 69

3

21

67

4

Please refer to the HIL simulation manual on the main VENTOS website (https:// maniam.github.io/VENTOS/#download) for more details on how to utilize the WaveCombo boards as OBU and RSU. 5 In real-world the signal is sent to the car through the CAN (Controller Area Network) bus, but we do not simulate it here.

VENTOS is capable of simulating multiple traffic signal control (TSC) algorithms, some of which are widely integrated in real-life intersections (e.g. fixed-time and traffic actuated). Other algorithms have been proposed in the research community (e.g. Adaptive Webster [33], Longest Queue First [34], and Oldest Job First [35]). In fixed-time signal control, the different light intervals are preset based on historical traffic demands. Traffic phases are scheduled in a non-conflicting manner. Traffic-actuated uses loop detectors and video cameras to measure the demand at intersections and adjusts the green time accordingly. This TSC allocates enough green time to phases in order to clear vehicles queued between the stop line and the upstream loop detector. Phases without any traffic demand are skipped. If additional traffic movement is detected, then the green time can be extended, but there is a limit as to how long a green time can be extended for [36]. In Adaptive Webster, the TSC adapts to the traffic intensity of the intersection and adjusts the green time accordingly. The Webster equation is used for calculating the optimum cycle length [33]. In Longest Queue First (LQF), phase selection is performed based on the queue size of each lane. The combination of non-conflicting movements with the largest total queue size obtains right-of-way priority. The green time allocated to the phases is proportional to the maximum queue size of each phase [34]. One issue with LQF is that certain lanes may experience starvation, which occurs when phases never get serviced (i.e. receive green time). Starvation happens in LQF when a phase has relatively low arrival rates, so the TSC does not consider it a priority. Oldest Job First (OJF) [35] is designed to reduce the overall delay by servicing the lane with the longest waiting time. Due to the internal calculations for determining the delay of each lane, OJF requires real-time speed and position data from vehicles. With these various algorithms, we can acquire operational data, such as the maximum queue size per lane, the average per-vehicle delay, and the intersection throughput. We can use this information to analyze the performance of each algorithm under different traffic demands. These simulations are useful for analyzing tradeoffs between performance (e.g., system throughput at an intersection) and cost (e.g., worst case delay of a vehicle) for different schemes, as well as serving as a proof of concept. Fig. 5 shows a multi-modal intersection with two incoming lanes per direction. VENTOS is capable of simulating much more complex scenarios, so this intersection can be modified or completely redesigned to fit the needs of a particular simulation. In addition to these conventional and well-known TSC algorithms, we can extend and modify VENTOS to handle our own specific research scenario. For example, we explored the idea of a single multi-modal traffic intersection scenario in which vehicles, bicycles, and pedestrians are all active entities. An active entity is capable of sending beacon messages, which is a small data packet that contains speed and vehicle class among other information, to the TSC. This allows the TSC to classify these different traffic types and more accurately estimate traffic parameters, such as queue length for each vehicle class in each lane. The results of our experiment can be seen in Fig. 6. We can see the performance (i.e. maximum queue size per lane, average delay per vehicle, and throughput) of Adaptive Webster, LQF, and the traffic actuated algorithms with and without active entities. From these results, we can see that introducing active entities does not affect the throughput. However, we can see performance improvements in both the maximum queue size per lane and average delay per vehicle. We

72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132

JID:VEHCOM

6

AID:100230 /FLA

[m5G; v1.261; Prn:30/01/2020; 14:36] P.6 (1-12)

B. Ching et al. / Vehicular Communications ••• (••••) ••••••

1

• Application layer attacks: These attacks affect the functionality

67

2

of a particular application such as message falsification, spoofing (masquerading), and replay attack to attack TSC algorithms or other collaborative driving protocols such as platoon management. • Network layer attacks: These attacks have the potential to affect the functionality of multiple user applications such as Denialof-Service (DoS).

68

3 4 5 6 7 8 10 11 12 13 14 15 16 17 18 19 20 21 22

Fig. 5. Multi-modal four-way intersection model in VENTOS.

24 25 26 27

attribute these improvements to the more accurate estimation of traffic parameters used in the TSC algorithms.

This section discusses the results of our simulations with two delay-based algorithms: Head-of-Line (HOL) and OJF. Both of these algorithms require V2X communication capabilities because vehicles must report their speed and delay information to the TSC. For the HOL algorithm, we are determining the vehicle with the highest delay value in each lane. The phase with the highest total HOL delay receives priority green time. We have previously discussed about the OJF algorithm in Section 5. Both of these delay-based scheduling algorithms are compared in single and multiple intersection scenarios. We calculate the delay of a vehicle from the time when the vehicle enters an intersection to the time when the vehicle crosses the intersection. Attacker vehicles can manipulate these TSC algorithms by reporting false delay times, which allows them to unfairly gain green light priority. Lastly, all intersections in the simulations are equipped with the max out concept. Max out ensures that an individual phase cannot hog all the green time. In other words, we prevent starvation in the other phases.

30

6. Simulation study of security attacks in intelligent intersections

31 32 33 34 35 36 37 38 39 40 41 42

71 72 73 74 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94

28 29

70

75

9

23

69

With TSC algorithms such as OJF and LQF, we have the potential to create more adaptive and intelligent traffic intersections. These algorithms, however, require the integration of wireless V2X communication. As we continue to advance in VANET-enabled smart transportation systems, it is becoming more important to understand the security vulnerabilities that come with them. By using VENTOS, we can study the security risks of TSC algorithms and the impact that attackers have on intelligent intersections. VENTOS can be used to simulate and study a wide range of security attacks, including application and network-layer attacks such as the following:

6.1. Simulation environment

95 96

For our security attack simulations, we have two different simulation environments: single intersection and multiple intersections. The single intersection is depicted in Fig. 5 and is comprised of eight lanes and four phases. These phases are shown in Fig. 8. A phase is a combination of non-conflicting movements. Although Fig. 5 depicts a multi-modal intersection, our simulations focus solely on passenger vehicles. For the multiple intersections simulation scenarios, we leveraged OpenStreetMaps (OSM) to import real-world maps into VENTOS. We selected a small section of San Francisco, and exported the map from OSM. This map is shown in Fig. 7. There are two traffic light intersections which are circled [in blue and red].

97 98 99 100 101 102 103 104 105 106 107 108

43

109

44

110

45

111

46

112

47

113

48

114

49

115

50

116

51

117

52

118

53

119

54

120

55

121

56

122

57

123

58

124

59

125

60

126

61

127

62

128

63

129 130

64 65 66

Fig. 6. Performance of different TSC algorithms with and without active detection in single-class traffic with balanced demand. Vehicle route distribution per direction is set to 70% through and 30% left turn.

131 132

JID:VEHCOM AID:100230 /FLA

[m5G; v1.261; Prn:30/01/2020; 14:36] P.7 (1-12)

B. Ching et al. / Vehicular Communications ••• (••••) ••••••

1

7

Table 2 Parameters for the single intersection examples.

2 3

Arrival rate (veh/hour) Attacker lanes Attacker spoof time (s) Lane length (meters) Total Sim hours per simulation (hours)

4 5 6 7

250(N/S); 500(E/w) North and South 2000 900(N/S/E/W) 3

9

tion environment, we strive to keep the simulation environment as close to reality as possible.

10 11 12

6.2. Single intersection with HOL

13 15 16 17 18

Fig. 7. Map of San Francisco that was exported from OSM for the multiple intersection simulation scenarios.

21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

69 70 71 72 73 75 76 77 78 79 80

14

20

68

74

8

19

67

The top intersection [circled in blue] contains only six lanes and three phases. The phases are shown in Fig. 9. The bottom intersection [circled in red] is identical to the one in our single intersection scenarios and to the one shown in Fig. 5 (i.e. eight lanes and four phases). The remaining eight intersections in Fig. 7 contains stop signs. Only the lanes that intersect the two traffic lights have vehicular traffic flows. There are a couple factors that make this OSM of San Francisco more realistic than our single intersection environment. First, the lane lengths of the San Francisco map are much shorter (i.e. 100-200 meters) compared to the lane lengths of the single intersection (i.e. 900 meters). Most intersections in the real world are shorter than 900 meters in length. We used 900 meters for our single intersection scenarios in order to simulate an infinite queue and to act as a proof of concept for security vulnerabilities. We switched over to a real-world map of two intersections in San Francisco in order to simulate a more practical scenario. Additionally, the stop signs add an extra layer of complexity in terms of how long it takes the vehicles to enter the traffic light intersection. Vehicles at the stop signs would need to yield to other cars approaching from opposing directions. With this multiple intersec-

For our first set of simulations, we implemented the HOL algorithm into our single intersection environment. Table 2 summarizes the parameters used. The East and West lanes are assumed to be busier than the North and South lanes. As such, the East and West lanes are given twice the arrival rate of that of the North and South lanes. Attacker vehicles can only arrive from the North and South directions. The delay spoof time for attacker vehicles is set to be an additional 2000 seconds. In other words, vehicles report 2000 seconds of delay in addition to the delay that is calculated from when they enter the intersection. The minimum green time for all phases is 60 seconds, while the maximum green time is 120 seconds. We ran three simulations for this set with three different attack rates each time: 0, 0.001, and 0.01. The results of the simulation scenario are depicted in Fig. 10. As expected, as the attack rate increases, the overall vehicle delay of the entire simulation increases as well. The significant increase in delay can be attributed to the attacker vehicles coming from the North and South directions. Since the North and South are the less busy lanes, they are scheduled green time less frequently. By introducing attackers into the North and South lanes, they gain green time priority more often and strip away valuable green time that the East and West lanes desperately need. When the North and South get schedule green time, they usually do not have vehicles crossing the intersection for the entire 60 or 120 seconds. Traffic demand in the North and South is simply too low. As a result, whenever the North and South unfairly gains priority green time due to attacker vehicles, the East and West directions suffer and accrue a lot of idle waiting time.

81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108

43

109

44

110

45

111

46

112

47

113

48

114

49

115

50

116

51

117 118

52 53

Fig. 8. Diagram of the four phases and eight lanes present in the single intersection environment.

119

54

120

55

121

56

122

57

123

58

124

59

125

60

126

61

127

62

128

63

129

64

130 131

65 66

Fig. 9. Diagram of the three phases and six lanes present in the multiple intersection environment.

132

JID:VEHCOM

AID:100230 /FLA

[m5G; v1.261; Prn:30/01/2020; 14:36] P.8 (1-12)

B. Ching et al. / Vehicular Communications ••• (••••) ••••••

8

1

67

2

68

3

69

4

70

5

71

6

72

7

73

8

74

9

75

10

76

11

77

12

78

13

79

14

80

15

81

16

82

17

83

18 19

Fig. 10. First results for the HOL algorithm implemented into the single intersection environment. The attack rate of 0.001 has 4 attackers, and 0.01 has 31 attackers.

22 23

Table 3 Minimum and maximum green times for a single intersection for both the HOL and OJF algorithms.

24 25 26 27

–

Left

Straight

Min Max

30 s 60 s

60 s 120 s

28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

85 86

20 21

84

We performed a second set of simulations. In real life traffic intersections, the left turn lanes are typically given less green time than the straight lanes. So in this next set of simulations, all parameters are kept the same from the previous set, except for the minimum and maximum green times. Table 3 reflects this change in green time. The results of this second set of simulations are depicted in Fig. 11. It is interesting to note that by varying the green times, the effects of the attackers have been mitigated to a certain degree. There is still a negative impact on the overall vehicle delays, but the impact is much less significant. A much higher attack rate is required before a noticeable increase in delay can be seen. As shown in Fig. 10, an attack rate of 0.001 was sufficient to see the adverse effects of vehicles spoofing delay times. In Fig. 11, we do not see a noticeable impact until we achieve an attack rate of 0.01. Nonetheless, the maximum delay is increasing in each simulation (ignoring the outliers).

6.3. Single intersection with OJF

87 88

For our next set of simulations, we implemented the OJF algorithm into our single intersection environment. The parameters are the same as the ones used in Section 6.2. The only difference is that the attack spoof time is now 5000 seconds. Occasionally, ordinary vehicles would be stuck in the intersection for more than the original spoof time of 2000 seconds even without attacker vehicles being present. This is due to the lanes being 900 meters long. By setting the spoof time to 5000 seconds, we ensure that the attacker vehicle actually steals the green light priority. Attacker vehicles can only arrive from the North and South directions. The minimum green time is summarized in Table 3. We ran three simulations for this set with three different attack rates each time: 0, 0.01, and 0.05. The results of the simulation scenario are depicted in Fig. 12. In the single intersection environment, HOL and OJF perform similarly. Both algorithms require a much higher attack rate in order to see the adverse effects from the attacker vehicles. We attribute this more robust behavior to the varying green times for left and straight lanes. However, by introducing a substantial amount of attackers (i.e. more than 250 attacker vehicles) with an attack rate of 0.05, we see that both the median and maximum vehicle delay values increase considerably, regardless of varying green times.

89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112

47

113

48

114

49

115

50

116

51

117

52

118

53

119

54

120

55

121

56

122

57

123

58

124

59

125

60

126

61

127

62

128

63

129

64

130 131

65 66

Fig. 11. Second results for the HOL algorithm implemented into the single intersection environment. The attack rate of 0.001 has 4 attackers, and 0.01 has 31 attackers.

132

JID:VEHCOM AID:100230 /FLA

[m5G; v1.261; Prn:30/01/2020; 14:36] P.9 (1-12)

B. Ching et al. / Vehicular Communications ••• (••••) ••••••

9

1

67

2

68

3

69

4

70

5

71

6

72

7

73

8

74

9

75

10

76

11

77

12

78

13

79

14

80

15

81

16

82

17

83 84

18 19

Fig. 12. Results for the OJF algorithm implemented into the single intersection environment. The attack rate of 0.01 has 43 attackers, and 0.05 has 257 attackers.

21 22 23 24 25 26

Table 4 Parameters for the multiple intersection examples. Arrival rate (veh/hour) Attacker lanes Attacker spoof time (s) Lane length (meters) Total Sim hours per simulation (hours)

300(N/S); 150(E/W) East and West 2000 200(N/S); <100(E/W) 3

27 28 29 30

6.4. Multiple intersections with HOL

31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

85 86

20

For our third set of simulations, we implemented the HOL algorithm into our multiple intersection environment. Table 4 summarizes the new set of parameters used in this third set of simulations. This time, the North and South are the busier directions and have been given twice the arrival rate of that of the East and West directions. Attacker vehicles now arrive from the East and West directions. The delay spoof time for attacker vehicles is set to be an additional 2000 seconds. 2000 seconds is sufficient because the lane lengths in the multiple intersection environment are relatively short. The minimum and maximum green times are shown in Table 5. The green times now vary based on which direction the car is traveling (i.e. North, South, East, or West). We ran three simulations for this set with three different attack rates each time: 0, 0.001, and 0.05. The results of the simulation scenario are depicted in Fig. 13.

Table 5 Minimum and maximum green times for the multiple intersections simulation environment. The less busy lanes (i.e. East and West) have shorter maximum green times.

87 88 89 90 91

–

Min (straight)

Max (straight)

North/South East/West

30 s 30 s

60 s 30 s

92 93 94

–

Min (left)

Max (left)

95

North/South East/West

15 s 15 s

30 s 15 s

96 97 98 99

The results are consistent with the previous simulations in terms of seeing an increase in overall delay. Due to the shorter lane lengths, the median delay value in the box plots are much lower than that of the single intersection simulations (e.g. Fig. 11). We still calculate delay from when the vehicle enters the traffic light intersection lanes to when it crosses that intersection. However, these vehicles could be waiting at the stop sign intersections leading up to the traffic light. We do not account for the extra delay outside the traffic light lanes, but this would be an important future work. Additionally, we noticed that there was almost no difference in overall delay between the 0.001 and 0.01 attack rates. However, by increasing the attack rate even more to 0.05, we see a serious degradation in vehicular traffic flow.

100 101 102 103 104 105 106 107 108 109 110 111 112

47

113

48

114

49

115

50

116

51

117

52

118

53

119

54

120

55

121

56

122

57

123

58

124

59

125

60

126

61

127

62

128

63

129

64

130 131

65 66

Fig. 13. Results for the HOL algorithm implemented into the multiple intersection environment. The attack rate of 0.001 has 7 attackers, and 0.05 has 151 attackers.

132

JID:VEHCOM

AID:100230 /FLA

[m5G; v1.261; Prn:30/01/2020; 14:36] P.10 (1-12)

B. Ching et al. / Vehicular Communications ••• (••••) ••••••

10

1

67

2

68

3

69

4

70

5

71

6

72

7

73

8

74

9

75

10

76

11

77

12

78

13

79

14

80

15

81

16

82

17

83 84

18 19

Fig. 14. First results for the OJF algorithm implemented into the multiple intersection environment. The attack rate of 0.001 has 11 attackers and 0.01 has 37 attackers.

21

6.5. Multiple intersections with OJF

22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

85 86

20

Finally, for our fourth set of simulations, we implemented the OJF algorithm into our multiple intersection environment. We use the same parameters as the third set of simulations, which is outlined in Table 4 and Table 5. We ran three simulations for this set with three different attack rates each time, 0, 0.001, and 0.01. The results of the simulation scenario are depicted in Fig. 14. With multiple intersections, the OJF algorithm seems to be much less susceptible to attacker vehicles. Even by introducing 37 attackers into the simulation, we only see a marginal increase in the overall vehicle delays. This is attributed to the smaller lane lengths and the current method we use to calculate the delay of the vehicles. We ran a second set of simulations with a few different parameters to see how the results would change. For this set, we increased the arrival rate in the North and South directions and decreased the minimum and maximum green times. The arrival rate in the North and South have been increased to 350, and the new green times are summarized in Table 6. The green times for this set of simulations have been reduced to better match the sizes of each lane. We ran four simulations for this set with four different attack rates each time, 0, 0.001, 0.005, and 0.01. The results of the simulation scenario are depicted in Fig. 15.

Table 6 Minimum and maximum green times for the second test of multiple intersections with OJF. The less busy lanes (i.e. East and West) have shorter maximum green times.

87 88 89 90 91

–

Min (straight)

Max (straight)

92

North/South East/West

20 s 20 s

40 s 20 s

93

–

Min (left)

Max (left)

North/South East/West

10 s 10 s

20 s 10 s

94 95 96 97 98

Shortening the green times allows less cars to cross the intersection. By doing so, we see a significant spike in the number of outliers. It is important to note that as we increase the attack rate, the maximum vehicle delays plateau around the same values. This behavior highlights the shortcomings of the current method we have in place for measuring delay in multiple intersections. An improvement would be to take into consideration the delays of the vehicles leading up to the traffic light lanes. 6.6. Summary of results TSC algorithms are being heavily researched for their benefits in improving vehicular traffic flow and reducing overall vehicle emis-

99 100 101 102 103 104 105 106 107 108 109 110 111 112

47

113

48

114

49

115

50

116

51

117

52

118

53

119

54

120

55

121

56

122

57

123

58

124

59

125

60

126

61

127

62

128

63

129 130

64 65 66

Fig. 15. Second results for the OJF algorithm implemented into the multiple intersection environment. The attack rate of 0.001 has 12 attackers, 0.005 has 29 attackers, and 0.01 has 54 attackers.

131 132

JID:VEHCOM AID:100230 /FLA

[m5G; v1.261; Prn:30/01/2020; 14:36] P.11 (1-12)

B. Ching et al. / Vehicular Communications ••• (••••) ••••••

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

sions. As we move towards a future of fully connected cars and autonomous vehicles, these scheduling algorithms are being significantly more crucial. There is, however, an increased risk of cyber attacks as vehicles become equipped with this wireless V2X communication capability. These cyber attacks have the potential to undermine, and even completely negate, the beneficial effects of these TSC algorithms. The security simulations that we presented and discussed in this section brings to light the need to develop countermeasures to malicious attackers. One such countermeasure is to ensure that traffic lights vary their maximum allotted green times for different phases. However, even by varying the green times, negative effects can still affect overall vehicle delays. Our simulations in our multiple intersection environment more accurately reflects traffic details in the real world. As such, by examining the HOL and OJF algorithms in our multiple intersection environment, we observe that the OJF algorithm is more robust. The vehicle delays plateau at a certain point with the OJF algorithm no matter how high the attack rate goes. These findings validate the results found by Yen et al. in [37], which were obtained via Matlab simulation that only incorporates the control logic and statistical arrival process, without realistic simulations of vehicular traffic, WAVE communications, or interactions between vehicles and intersection as done in VENTOS. In [37], they found that their delay-based algorithm, which is the same as our HOL algorithm, suffers drastically in performance when attacker vehicles are introduced. Their sum-ofdelay algorithm, which is our OJF algorithm, was not impacted too much by attackers.

30 31

7. Conclusions

32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

In this paper, we presented VENTOS, a closed-loop, integrated C++ VANET simulator. VENTOS couples two well-known simulators: SUMO for vehicular traffic mobility models and OMNET++ for wireless communication among the different nodes. The example applications involving VENTOS that we presented include (a) a simple HIL scenario that incorporates physical OBUs that interact with virtual vehicles in an EEBL application simulation, (b) a smart traffic intersection equipped with the capability to detect multimodal traffic using broadcast WAVE messages and different traffic light controllers, and (c) simulated security attacks within different intelligent intersection environments that studied the vulnerabilities of TSC algorithms. There are, however, many more applications that VENTOS can be applied towards. VENTOS continues to improve upon the state-of-the-art and has been used actively within the research community as reflected in the list of publications that acknowledge the use of the simulator.6 With its simplicity and ease of use coupled with its flexible and robust architecture, VENTOS can simulate countless realistic traffic scenarios. These research scenarios can be tested and analyzed for real-world deployment without endangering actual human lives.

54 55

Declaration of competing interest

56 57

None declared.

58 59 60

Acknowledgements

61 62 63

This work is supported in part by the National Science Foundation Grant CMMI-1301496.

64 65 66

6

Link to publications list: http://maniam.github.io/VENTOS/#publication.

11

References

67 68

[1] Y.J. Li, An overview of the dsrc/wave technology, in: International Conference on Heterogeneous Networking for Quality, Reliability, Security and Robustness, Springer, 2010, pp. 544–558. [2] K. Lee, J. Kim, Y. Park, H. Wang, D. Hong, Latency of cellular-based v2x: perspectives on tti-proportional latency and tti-independent latency, IEEE Access 5 (2017) 15800–15809. [3] A.-M. Cailean, B. Cagneau, L. Chassagne, V. Popa, M. Dimian, A survey on the usage of dsrc and vlc in communication-based vehicle safety applications, in: 2014 IEEE 21st Symposium on Communications and Vehicular Technology in the Benelux (SCVT), IEEE, 2014, pp. 69–74. [4] H.T. Cheng, H. Shan, W. Zhuang, Infotainment and road safety service support in vehicular networking: from a communication perspective, Mech. Syst. Signal Process. 25 (6) (2011) 2020–2038. [5] X. Wu, R. Miucic, S. Yang, S. Al-Stouhi, J. Misener, S. Bai, W.-h. Chan, Cars talk to phones: a dsrc based vehicle-pedestrian safety system, in: 2014 IEEE 80th Vehicular Technology Conference (VTC Fall), IEEE, 2014, pp. 1–7. [6] H. Noori, M. Valkama, Impact of vanet-based v2x communication using ieee 802.11 p on reducing vehicles traveling time in realistic large scale urban area, in: 2013 International Conference on Connected Vehicles and Expo (ICCVE), IEEE, 2013, pp. 654–661. [7] S. Ebers, S. Fischer Poster, Adapter framework for vanet simulators, in: 2014 IEEE Vehicular Networking Conference (VNC), IEEE, 2014, pp. 193–194. [8] B. Liu, B. Khorashadi, H. Du, D. Ghosal, C.-N. Chuah, M. Zhang, Vgsim: an integrated networking and microscopic vehicular mobility simulation platform, IEEE Commun. Mag. 47 (5) (2009). [9] D.R. Choffnes, F.E. Bustamante, An integrated mobility and traffic model for vehicular wireless networks, in: Proceedings of the 2nd ACM International Workshop on Vehicular Ad Hoc Networks, ACM, 2005, pp. 69–78. [10] J. Harri, F. Filali, C. Bonnet, Mobility models for vehicular ad hoc networks: a survey and taxonomy, IEEE Commun. Surv. Tutor. 11 (4) (2009). [11] M. Piorkowski, M. Raya, A.L. Lugo, P. Papadimitratos, M. Grossglauser, J.-P. Hubaux, Trans: realistic joint traffic and network simulator for vanets, ACM SIGMOBILE Mob. Comput. Commun. Rev. 12 (1) (2008) 31–33. [12] M. Rondinone, J. Maneros, D. Krajzewicz, R. Bauza, P. Cataldi, F. Hrizi, J. Gozalvez, V. Kumar, M. Röckl, L. Lin, et al., itetris: a modular simulation platform for the large scale evaluation of cooperative its applications, Simul. Model. Pract. Theory 34 (2013) 99–125. [13] B. Schünemann, V2x simulation runtime infrastructure vsimrti: an assessment tool to design smart traffic management systems, Comput. Netw. 55 (14) (2011) 3189–3198. [14] C. Sommer, R. German, F. Dressler, Bidirectionally coupled network and road traffic simulation for improved ivc analysis, IEEE Trans. Mob. Comput. 10 (1) (2011) 3–15. [15] M. Amoozadeh, H. Deng, C.-N. Chuah, H.M. Zhang, D. Ghosal, Platoon management with cooperative adaptive cruise control enabled by vanet, Veh. Commun. 2 (2) (2015) 110–123. [16] M. Amoozadeh, A. Raghuramu, C.-N. Chuah, D. Ghosal, H.M. Zhang, J. Rowe, K. Levitt, Security vulnerabilities of connected vehicle streams and their impact on cooperative driving, IEEE Commun. Mag. 53 (6) (2015) 126–132. [17] S. Ucar, S.C. Ergen, O. Ozkasap, Security vulnerabilities of ieee 802.11 p and visible light communication based platoon, in: 2016 IEEE Vehicular Networking Conference (VNC), IEEE, 2016, pp. 1–4. [18] H. Chai, H.M. Zhang, C.-N. Chuah, D. Ghosal, D. Smith, Dynamic traffic routing in a network with adaptive signal control, in: Transportation Research Board 95th Annual Meeting, 2017, pp. 64–85. [19] M. Amoozadeh, B. Ching, C.-N. Chuah, D. Ghosal, H.M. Zhang, Ventos: vehicular network open simulator with hardware-in-the-loop support, Proc. Comput. Sci. 151 (2019) 61–68. [20] R. Mangharam, D. Weller, R. Rajkumar, P. Mudalige, F. Bai, Groovenet: a hybrid simulator for vehicle-to-vehicle networks, in: 2006 Third Annual International Conference on Mobile and Ubiquitous Systems: Networking & Services, IEEE, 2006, pp. 1–8. [21] M. Segata, S. Joerer, B. Bloessl, C. Sommer, F. Dressler, R.L. Cigno, Plexe: a platooning extension for veins, in: 2014 IEEE Vehicular Networking Conference (VNC), IEEE, 2014. [22] R. Riebl, H.-J. Günther, C. Facchi, L. Wolf, Artery: extending veins for vanet applications, in: 2015 International Conference on Models and Technologies for Intelligent Transportation Systems (MT-ITS), IEEE, 2015. [23] M. Amoozadeh, Vehicular Network Open Simulator (VENTOS), more details can be found at this address: http://maniam.github.io/VENTOS/. [24] A.F.A. Gil, J. Espinosa, J.E. Espinosa, Traci4matlab: re-engineering the python implementation of the traci interface, in: SUMO2014-Modeling Mobility with Open Data, 2012, p. 145. [25] M. Krumnow, Sumo as a service–building up a web service to interact with sumo, in: Simulation of Urban MObility User Conference, Springer, 2013, pp. 62–70. ˇ D. Yang, M. Asplund, M. Bouroche, [26] N. O’Hara, M. Slot, D. Marinescu, J. Curn, S. Clarke, V. Cahill, Mddsvsim: an integrated traffic simulation platform for au-

69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132

JID:VEHCOM

12

1 2 3 4

[27] [28]

5 6

[29]

7 8 9

[30]

10 11 12 13 14

[31] [32]

AID:100230 /FLA

[m5G; v1.261; Prn:30/01/2020; 14:36] P.12 (1-12)

B. Ching et al. / Vehicular Communications ••• (••••) ••••••

tonomous vehicle research, in: The International Workshop on Vehicular Traffic Management for Smart Cities (VTM 2012), 2012. Automotive Linux Summit, How to begin V2X development on Linux, 2015. A. Virdis, G. Stea, G. Nardini, Simulating lte/lte-advanced networks with simulte, in: Simulation and Modeling Methodologies, Technologies and Applications, Springer, 2015, pp. 83–105. J. Matsumura, Y. Matsubara, H. Takada, M. Oi, M. Toyoshima, A. Iwai, A simulation environment based on omnet++ for automotive can–ethernet networks, in: Analysis Tools and Methodologies for Embedded and Real-time Systems, 2013, p. 1. A. Partow, C++ mathematical expression toolkit library (exprtk), sitio web personal, 2015. M. Amoozadeh, VENTOS manual, more details can be found at this address: https://goo.gl/rLdn2v. D. Committee, et al., Dedicated short range communications (dsrc) message set dictionary, Tech. Rep. J2735_200911, Soc. Automotive Eng., Warrendale, PA, USA, 2009.

[33] V. Gradinescu, C. Gorgorin, R. Diaconescu, V. Cristea, L. Iftode, Adaptive traffic lights using car-to-car communication, in: IEEE 65th Vehicular Technology Conference, 2007, VTC2007-Spring, IEEE, 2007, pp. 21–25. [34] K.M. Yousef, M.N. Al-Karaki, A.M. Shatnawi, Intelligent traffic light flow control system using wireless sensors networks, J. Inf. Sci. Eng. 26 (3) (2010) 753–768. [35] K. Pandit, D. Ghosal, H.M. Zhang, C.-N. Chuah, Adaptive traffic signal control with vehicular ad hoc networks (vanet), in: Special Section: Graph Theory and Its Application in Vehicular Networking, IEEE Trans. Veh. Technol. 62 (4) (2013) 1459–1471. [36] P. Koonce, et al., Traffic signal timing manual, Tech. Rep., Federal Highway Administration, United States, 2008. [37] C.-C. Yen, D. Ghosal, M. Zhang, C.-N. Chuah, H. Chen, Falsified data attack on backpressure-based traffic signal control algorithms, in: 2018 IEEE Vehicular Networking Conference (VNC), IEEE, 2018, pp. 1–8.

67 68 69 70 71 72 73 74 75 76 77 78 79 80

15

81

16

82

17

83

18

84

19

85

20

86

21

87

22

88

23

89

24

90

25

91

26

92

27

93

28

94

29

95

30

96

31

97

32

98

33

99

34

100

35

101

36

102

37

103

38

104

39

105

40

106

41

107

42

108

43

109

44

110

45

111

46

112

47

113

48

114

49

115

50

116

51

117

52

118

53

119

54

120

55

121

56

122

57

123

58

124

59

125

60

126

61

127

62

128

63

129

64

130

65

131

66

132