Study of a platooning use case in a dense urban scenario

S T U D Y O F A P L AT O O N I N G U S E C A S E I N A D E N S E U R B A NS C E N A R I O

antonio vera llop

Supervisor: Rajesh Sattiraju

Fachbereich Elektro- und InformationstechnikLehrstuhl für Funkkommunikation und Navigation

Technische Universität KaiserslauternProf. Dr.-Ing. Hans D. Schotten

May 2015

[ June 29, 2015 at 10:04 – classicthesis ]

Antonio Vera Llop: Study of a platooning use case in a dense urbanscenario,© June 2015


A B S T R A C T

Vehicular networking and intra-/inter- vehicular informationexchange has become one of the most recent and researchedcommunication topics. The idea behind vehicular networking isto create mobile networks in roads and cities using vehicles andcomplementary structures, if required.

Currently vehicular networks are not yet 100% real. Despite studiesshowing that they are possible, there are still many problems inthe adaptation to real world. It is for this reason that in recentyears plenty of different tools, frameworks and simulators havearisen allowing the simulation and behaviour analysis of thesenetworks. One of the tools offering most accuracy and variety interms of results is Veins (Vehicles in Network Simulator). Oneof the vehicular simulation applications available through Veins isPlatooning which is the main application used in this study. Theanalysis and computation of the obtained results by Veins can alsobe easily complemented with other tools like Matlab and R.

This study evaluates a use case of platooning in an urbanscenario, where cars benefit of bus lanes. The results obtained inthe simulations are very satisfactory and could be useful in futureresearch to determine whether or not platooning in urban scenarioscan become a reality.

iii


A C K N O W L E D G M E N T S

I would like to express my special appreciation and thanks tomy advisor Rajesh Sattiraju. Thank you for your support andintroduction to the world of research. I would also like to thank myfriends and family for standing at my side all of this time. Withoutyou it would not have been possible.

iv


C O N T E N T S

i introduction to vehicular comunications 1

1 the beginning of vehicular networks 2

1.0.1 Related work 3

1.1 Thesis goals 5

1.2 Thesis outline 5

ii vehicular communications technologies

overview 7

2 v2v communication technologies 8

2.1 Inter-vehicles communication 8

2.2 Intra-vehicles communications 10

2.3 Communication modes 12

2.4 Applications 15

2.5 Challenges 16

iii evaluation of v2v frameworks 18

3 v2v simulators 19

3.1 Taxonomy of simulators 19

3.2 Mobility Generators (Traffic Simulators) 20

3.3 Communication networks simulators 21

3.4 VANETs Integrated Simulators 22

3.5 Hybrid VANETs Simulators 23

3.6 Veins Simulator 24

3.6.1 Traffic simulator: SUMO 25

3.6.2 Network Simulator: OMNet++ 28

iv simulations and results 30

4 evaluation of platooning in a dense urban

scenario 31

4.1 KPI’S 31

4.2 Entities of a Platoon 32

4.3 Controller Models 32

4.3.1 CC 33

4.3.2 ACC 33

4.3.3 CACC 34

4.4 Platoon Maneuvering 35

4.4.1 Join Maneuvering 35

4.5 Particularities of PLEXE 36

4.5.1 Platooning Capabilities in SUMO 36

4.5.2 Platooning Protocols and Applications inVeins 37

4.6 Evaluation of the Controller parameters 39

4.6.1 Simulation set up 39

4.6.2 Results 39

4.6.3 Results evaluation 42

v


contents vi

4.7 Use of Platooning in urban environments 43

4.7.1 Map set up 43

4.7.2 Network set up 43

4.7.3 Explanation of the join maneuversimulation 43

4.7.4 Dense urban traffic simulation 46

4.7.5 Results 46

4.8 Conclusion 49

4.9 Future work 51

v appendix 52

a software installation 53

a.1 Installing Omnet++ 53

a.2 Downloading Plexe extension 53

a.3 Building SUMO 54

a.4 Building Plexe Veins 54

a.4.1 Installing R 54

b simulation settings 56

b.1 First Simulation 56

b.2 Second Simulation 58

b.2.1 Map set up 58

b.2.2 Network set up 59

b.3 Procesing data 60

c plots 62

bibliography 67


L I S T O F F I G U R E S

Figure 1 Chapter 2 board diagram 8

Figure 2 IEEE 1609 WAVE protocol architecture 10

Figure 3 Simulator example 19

Figure 4 Taxonomy of simulators 20

Figure 5 Mobility Generators 21

Figure 6 Network Simulator 22

Figure 7 Veins www.ccs-labs.org/~dressler/projects/veins/Last visit Juny 2015 24

Figure 8 car-following diagram 27

Figure 9 Platooning www.bbc.com/future/story/20130409-robot-truck-platoons-roll-forward Last visit:Juny 2015 31

Figure 10 Controllers 32

Figure 11 State machines of the sample join maneuver:joiner 36

Figure 12 State machines of the sample join maneuver:leader 36

Figure 13 Simulatons Flowchart 38

Figure 14 Time to reach the platoon (4 vehicles) 40

Figure 15 Time to reach the platoon (7 vehicles) 41

Figure 16 First part of the join maneuver 44

Figure 17 Second part of the join maneuver 44

Figure 18 Last part of the join maneuver 45

Figure 19 CO2 emission plots 47

Figure 20 CO2 emission (sinusoidal plots) 48

Figure 21 Plots of the results 50

Figure 22 Ideal trend 51

Figure 23 omnetpp.ini file (joinManeuverPlatoonexample) 56

Figure 24 SUMO GUI: Freeway example 57

Figure 25 Route file 58

Figure 26 sumo.cfg file 59

Figure 27 JoinManeuverApp.cc 59

Figure 28 Plot changing bandwidth in a 4 carsplatoon 62

Figure 29 Plot changing psi in a 4 cars platoon 63

Figure 30 Plot changing C1 in a 4 cars platoon 64

Figure 31 Plot changing bandwidth in a 7 carsplatoon 65

Figure 32 Plot changing C1 in a 7 cars platoon 66

vii


L I S T O F TA B L E S

Table 1 Standards in Intra-vehiclescommunications 11

Table 2 Communication modes/Technologies 13

Table 3 Taxonomy of applications 15

Table 4 Requirements 16

Table 5 Use cases 16

Table 6 Network and road traffic simulationparameters 39

Table 7 CO2 emission saving in the platoon 48

Table 8 CO2 emission total saving 49

viii


A C R O N Y M S

AP Acces Point

CAN Controller Area Network

CARAVAN Communications Architecture for Reliable AdaptiveVehicular Ad Hoc Networks

CW Contention Window

DSRC Dedicated Short Range Communications

DSDV Destination Sequenced Distance Vector

EDCA Enhanced Distributed Channel Access

GPS Global Positioning System

ISO International Standardization Organization

I2V Infrastructure-to-Vehicle

ITS Intelligent Transport Systems

IVC Inter-Vehicular Communications

LTE Long Term Evolution

MANET Mobile Ad-Hoc Network

OBE On-Board Equipment

OE Original Equipment

OLSR Optimized Link State Routing Protocol

PCV Positive Crankcase Ventilation

QoS Quality of Service

RSE Roadside Equipment

TCP Transmission Control Protocol

USB Universal Serial Bus

UWB UltraWideband

V2I Vehicle-to-Infrastructure

V2V Vehicle-to-Vehicle

VANET Vehicular Ad-Hoc Network

Veins Vehicles in network simulation

ix


acronyms x

Wi-Fi Wireless Fidelity

WiMAX Worldwide Interoperability for Microwave Access

WSN Wireless Sensor Network


Part I

I N T R O D U C T I O N T O V E H I C U L A RC O M U N I C AT I O N S


1T H E B E G I N N I N G O F V E H I C U L A R N E T W O R K S

Throughout the 1950s and 1960s governments in the UnitedStates conducted studies on the numerous sources of air pollutionthe results of which attributed a significant portion of pollution toautomobiles. The PCV system was the first attempt to reduce pollutioncaused by automobiles marking the beginning of the use of electronicin cars. It was first installed in all new 1961-car models sold inCalifornia. By 1964, almost every car sold in the U.S. was equippedwith PCV, which quickly became standard equipment for all vehiclesworldwide.

The development of electronics in vehicles continued in theearly 1970s, with the use of radio, an alternator (diodes) anda voltage regulator which controlled the alternator. Owing toadvances in semiconductors and related system control software,automotive electronics have had enormous technological innovationin the last 30 years reaching a high degree of complexity. Theseinnovations not only monitor mechanics and motor parameters, butalso improve and facilitate driving, avoiding accidents with theuse of sensors and external cameras. Social needs and the fastdeveloping technology will lead to changes in the way mobile andwireless communication systems are used. Users will be providedwith a wide variety of applications and services, ranging frominformation and entertainment services, increased safety and efficientuse of transportation, to completely new industrial and professionalapplications. Many challenges arise in attempting to achive thisgoal, such as the very high data rates, and the very dense crowdsof users, with higher requirements on the end-to-end performanceand user-experience. The very low latency, very low energy cost,and massive number of devices are other examples of challengesthat these application areas have to face. Notwithstanding, the keychallenge and end goal remains efficient mobility. All this will be thebasis of the foundation in the future 5G communications systems.

Official 5G requirements have not yet been defined, but operators,manufacturers and academic institutions are already beginning toimagine various outcomes. Expectations are that 5G provides auniform flow rate of, at least 1 Gbit/s, with a maximum ofabout 10 Gbit/s, and a couple of milliseconds of latency, whichwill provide a highly reliable service. In Europe, Mobile andwireless communications consortium Enablers for the Twenty-twentyInformation Society (METIS) focuses its efforts in laying thefoundations for the 5G systems. They hope 5G provides a trueexperience unlimited mobile ubiquity through enhanced terminalswith artificial intelligence capabilities. It is also expected to facilitatethe activities of new applications in areas such as eHealth and

2


the beginning of vehicular networks 3

machine to machine communication. As for network requirements,the 5G needs to set interoperability without interfaces betweenexisting and future standards. The increasing demand for mobiletraffic will lead to the development of new ways to improve thecapacity, and the dense small cell deployment, traffic optimizationand the use of download schemes. Energy consumption steadilyincreasing in wireless networks requires new checks and savings.Finally, given the complexity and heterogeneity of these networks,there will be a need of autonomous management of such networks.

Devices are becoming more powerful and numerous. In the future,in addition to devices such as smartphones, tablets and gameconsoles, wireless outlook includes cars, smart grid terminals andhealth monitoring devices, among others. Estimated device to devicetraffic will increase 24 times between 2012 and 2017. Therefore, inorder to provide service to all this demand, the 5G must providehigh bandwidth, meet strict requirements for quality of service(such as extremely low latency and video compression with no loss)and implement improved security mechanisms. Given the diversityof the types of traffic, ranging from sending periodic data to thetransmission of high quality videos, efforts will be needed to manageradio resources efficiently.

The evolution towards 5G require changes not only in the radioaccess network, but also in the core of the network, which willrequire new design approaches in order to provide connectivity toa growing number of users and devices. Networking via software,whose standardization is being done in the Open NetworkingFoundation, adopts the separation of control and data. Therefore,by centralizing and programming, the transfer settings can beautomated to a large extent. Introducing a new software as a solution,is much faster than installing a new special device with a particularfunction. This solution helps to improve the adaptability and facilitatenetwork scalability. Software-based solutions play a key role in thedevelopment of network kernels. Thus, by a simple operation, it ispossible to add new functions to the network.

Different technologies are complemented to achieve the commongoal of providing a ubiquitous service through 5G mobile networks.Clearly, there is enormous potential for the exploitation of thespectrum bands of higher frequencies, the multi-antenna techniquesand the development of small cells, followed by the schemes thatreduce energy consumption in mobile networks. The Wi-Fi also hasgreat potential as access technology support.

1.0.1 Related work

The following section enumerates and explains the research andprojects taken into account for this study.

When researching information concerning vehicularcommunications, and new communication technologies, the


the beginning of vehicular networks 4

most predominant result is the METIS project. The main goalof METIS is to generate a European consensus on the future globalmobile and wireless communications system. It provides valuableand timely contributions to pre-standardization and regulationprocesses, and ensures European leadership in mobile and wirelesscommunications.

Developing a concept for the future mobile and wirelesscommunications system which supports the connected informationsociety is one of the most important goals of this project. METISfundamentally provides new solutions to fit the needs beyond 2020,which are basically new network topologies, radio links, multi-node,and spectrum usage techniques to support the high number ofdevices in a small area and high data rates required [15].

Research from the University of Karlsruhe [16] is also in thefronline of the telecomunications world. Traffic Telematics is anapplication of Telematics in Intelligent Transportation focusedon the development of transportation applications based ongathered traffic information. It also describes the methodology andprotocols managing the transmission, reception and handling ofinformation between vehicles and road infrastructures.

Information on communication modes, vehicular equipment,vehicular security communications and roads can be found inVehicle Safety Communications: Protocols Security and Privacy[17].This publication provides an up-to-date, in-depth look at thecurrent research, design, and implementation of vehicular securitycommunications. Improving traffic safety has been a top concern fortransportation agencies around the world and the focus of heavyresearch and development efforts sponsored by both governmentsand private industries. Cooperative vehicle systems which usesensors and wireless technologies to reduce traffic accidents can playa major role in making the world’s roads safer. This book providedhighly interesting information for the study:

Vehicle Safety Communications: Protocols Security and Privacy[17]It gives an overview of traditional vehicle safety issues, the evolutionof vehicle safety technologies, and the need for cooperative systemswhere vehicles work together to reduce the number of crashes ormitigate damage when crashes become unavoidable. It describesfundamental issues in cooperative vehicle safety and recent advancesin technology to enable cooperative vehicle safety. Some of theserecent advances mentioned include:

- The history and current status of 5.9 GHz Dedicated Short RangeCommunications (DSRC) technology and standardization, discussingkey issues in applying DSRC to support cooperative vehicle safety.

-Features and in-depth overview of on-board equipment (OBE) androadside equipment (RSE) by describing sample designs to illustratethe key issues and potential solutions.

-Takes on security and privacy protection requirements andchallenges, including how to design privacy-preserving digital


1.1 thesis goals 5

certificate management systems and how to evict misbehavingvehicles.

- Coverage of vehicle-to-infrastructure (V2I) communications likeintersection collision avoidance applications and vehicle-to-vehicle(V2V) communications like extended electronic brake lights andintersection movement assist.

The most relevant research, projects and papers to the thesis inhand are those brought about by Christoph Sommer and FalkoDressler. Most of their recent work contains plenty of information,results and conclusions which prove very useful to this study. Thetextbook written by these authors provides almost all the requiredinformation in order to understand the simulators that have be usedin this study: Vehicular Networking [11]. It also gives very accurateand useful information on vehicular communications, as well as anin-depth description of the main tool used in this study: Veins.

The following references provide further explanation about howVeins works, which communication models it uses, the ray modelswhich are available and its set-backs. It also includes some researchon new Veins extensions (LTE) and the benefits and disadvantages ofbidirectional coupled networks[2], [9], [3], [1], [5] and [7].

The following are very useful papers on PLEXE performance, howthe PLEXE extension is installed for Veins, as well as how to run theexamples [6], [10] and [4]. They also include metrics about speeds,distances and accelerations of the vehicles which use platooning. Thisinformation has been very useful for our simulations.

1.1 thesis goals

The goal of this thesis is to evaluate a vehicular comunication testcase using a coupled simulation provided by Veins. The goals set forthis thesis can be summarised under the folowing bullets:

• To generate a traffic mobility vehicular model using SUMOcreating realistic traffic cases having downloaded real city mapsas the results depend on how accurate and realistic the trafficgenerated is.

• To use network simulation tools, such as Veins, to evaluate aparticular test case. The files and code used will need alterationin order to create the desired network for the test case.

• To compute the results obtained and form a judgment on theevaluated case.

1.2 thesis outline

Chapter 1: Introduction to the concept of vehicular communicationsand a comprehensive view on related state of the art, as well asoutlines of the goals of this thesis.


1.2 thesis outline 6

Chapter 2: In-depth view on the numerous use cases in vehiculartechnology and communication. This chapter describes intra andinter-vehicular communication and the differences between these, aswell as exposng the challenges that V2V communications will have toface in the future.

Chapter 3: Explanation of the use of simulators currently availablealong with their advantages/pitfalls in the context of vehicularcommunications as well as a more detailed description of the toolschoosen for this thesis.

Chapter 4: A simplified description of platooning followed by anevaluation of the test case performed: platooning in a highway and acity scenario.

Chapter 1 offers a general idea about past, present and future ofvehicular communications, states the related research and projectstaken into account for this thesis as well as enumerating the generalgoals for the thesis. The next chapter describes the current technologypresent in V2V communications.


Part II

V E H I C U L A R C O M M U N I C AT I O N ST E C H N O L O G I E S O V E RV I E W


2V 2 V C O M M U N I C AT I O N T E C H N O L O G I E S

This chapter is centered mainly on vehicular technologies and itslayout can be viewed in the diagram in Figure 2.1.

Figure 1: Chapter 2 board diagram

The aim of vehicular communication is intra- and inter-vehicularexchange of information. Inter-vehicle communication (IVC)comprises a wireless network in which cars, smart traffic signals androadside units send, receive and retransmit signals.

The usefulness of these networks lies in the provision of a numberof new services which are collectively called Intelligent TransportSystems (ITS). Thanks to the ITS vehicles have more and betterinformation on traffic conditions and can access services and data toimprove ride comfort for passengers (such as VoIP, video on demand,etc.). In addition to this, it is also possible to obtain enriched locationinformation so that navigation systems based on GPS can improvetheir effectiveness.

As well as improving driving and transport to that which iscurrently known and in use, such networks open the door to newmechanisms which aim to simplify the task of driving and increaseroad safety. Thus, through these networks it may be possible toprovide vehicle driver assistance or even can achieve automaticdriving.

2.1 inter-vehicles communication

During the last few years intra- and inter-vehicular communicationhas attracted a lot of attention. Voice and data communicationhave become important for road traffic telematics as well as forentertainment purporses. It is for this reason that the majority ofcar manufacturers build multimedia communication into their latestdevices.

8


2.1 inter-vehicles communication 9

WAVE and Wi-Fi are the two most common technologies ininter-vehicular communication. However Wi-Fi is not so widely useddue to safety reasons. MANET and VANETs are quite similar in thatinformation needs to be transported through moving nodes in ageographic area. Due this similarity many of the early works suggeststhat the same algorithms can be used in VANETs again. However thereare some significant differences to be mentioned. Node density, inMANETs has always been assumed to be constant. Mobility in VANETsis much more predictable and connectivity is much more dynamicin VANETs, specifically in urban environments due to quick changesof network connectivity caused by buildings and other obstacles thatblock the radio communication.

Many of the VANET routing approaches build upon Wi-Fi. Bothinfrastructure based networking, and ad-hoc functionalities areprovides by IEEE 802.11 protocol. Plenty of studies exist on theusability of Wi-Fi (IEEE 802.11a/b/g) for vehicular networkingdemonstrating the causes which limit the usability of Wi-Fi onvehicular networks (multi-path effects, speed-dependent signalfading, AP usage not optimized).

In Figure 2.2 we can see an overview of the IEEE 1609 WAVEprotocol. Normally IEEE 802.11p describes the lower protocol layers,and WAVE include the full protocol stack. IEEE 802.11p is the basisof the WAVE protocol stack. It defines the physical and MAC layer.

The PHY is quite similar to IEEE 802.11a, it also operates inthe 5 GHz band using orthogonal frequency-division multiplexing(OFDM). To minimize the multi-path effects, IEEE 802.11p doublesall timing parameters and reduces the channel bandwidth to 10 MHzinstead of 20 MHz thus guaranteeing reliability of transmissionseven for vehicles driving at more than 200 km/h. On the otherhand the throughput is reduced from 6-54 Mbit/s to 3-27 Mbit/sand the communication range is up to 1000m given the maximumtransmission power of 800mW.

MAC layer include randomized MAC addresses, QoS support(provided by integrating the IEEE 802.11e enhanced distributedchannel access (EDCA) mechanism) and a new ad-hoc mode. EDCA

allows a faster access to wireless channel because it supportsshorter interframe spaces for high-priority messages and reduces decontention window (CW) for higher-priority messages.

Due the high expectation of vehicular networking to provideroad-safety solutions to help prevent crashes and fatalities,responsible regulatory bodies worldwide have allocate a specificspectrum for IVC. Europe has regulated five 10 MHz channelsdedicated to IVC using a frequency range in the 5.9 GHz band.Between these channels we can find a single control channel (CCH)which is used for management and safety information by means ofbroadcast.

Probably the most critical problem in vehicular networking is thescalability. A first step was to identify the upper capacity limitsfor unicast communication in ad-hoc networks. This fixed upper


2.2 intra-vehicles communications 10

Figure 2: IEEE 1609 WAVE protocol architecture

boundary cannot be reached using other routing strategies, so thesolution was to include broadcast and multicast communication.

2.2 intra-vehicles communications

Wireless communication techniques can also be used to performautomotive functions inside a vehicle. This section addresses how thisis done and summarizes possible uses in the future. There are severalwireless standards that can be utilized for intra-vehicle use: "IEEE802.15.1 - Bluetooth", "IEEE 802.15.3 - UltraWideband (UWB), highdata rate", and "IEEE 802.15.4 - ZigBee, low data rate". A comparisonof the three standards is shown in Table 2.1.

Bluetooth has several advantages which make it the mostcommonly used intra-vehicle standard today. It is a proventechnology which transmits voice and data, and is relatively cheap.It also has low power requirements and can penetrate obstacles suchas walls. It has a large installed base and a guaranteed latency, aswell as a stable specification. Automobile components and modules,normally connected by electrical signal wires, are increasingly beingreplaced by wireless signals. A reduction of 50% in the amount ofsignal wires is the goal. Typically, an automobile contains about 8

meters of wiring, so this would be a lot of wireless signals. A hybridcontaining wired clusters of automobile components and wirelessinter-cluster connections are becoming more common. An instrumentdash panel is an example of a cluster.

There are advantages to the hybrid wireless concept, such as theweight reduction due to the replacement of the signal wires, aswell as simpler electrical wiring. The maintenance of the electricalsubmodules would also be easier. A systems approach to this idea


2.2 intra-vehicles communications 11

Bluetooth ZigBee UWB

Range 10 meters 10 meters < 10 meters

Data Rate Medium Low High

Throughput Medium Low High

Interference Good Good Excellent

Media Voice/Data Data Video/Radar

Power Req 1mW <1mW 200uW

Security Good Good Excellent

Tx Penetration Good Good Excellent

Mode FHSS DSSS DS, MBOA

Frequency 2.4GHz .8, .9, 2.4 GHz 3, 1-10.6GHz

Channels 23 or 79 1, 10 or 16 Evolving

Error Correct 8-bit,16 bit 16 CRC Evolving

Link BW 1MHz 20-250KHz 120MHz-1GHz

Table 1: Standards in Intra-vehicles communications

replaced an initial component-level approach to the point where inactuality international standards and off-the-shelf components arebeing used whenever possible. The implementation is evolving fromdesktop PCs, toggle switches, and lamps, to microcontroller cards,LEDs, silicon chips, auto sensors and actuators, as well as autotransducers.

During the late 1980’s, a serial communication bus called theController Area Network (CAN) was developed. It was used inthe automotive industry. Sensors, actuators, devices, switches, anddisplays can communicate over a CAN bus at speeds up to 1

Mbps. CAN has now been standardized as ISO 11898 by theInternational Standardization Organization. There are more than1500 implementations of this standard. The hardware/ softwareimplementation is being restructured so it can function as a physicallayer below the CAN bus. This will allow the existing v networksto evolve to a wireless communication mode using Bluetoothtechnology.

Wireless network behavior, under different conditions, is beingevaluated by performance and reliability models. Various factors canbe observed within these models:

• Interferences from other networks

• Electromagnetic environmental signals that could potentialyaffect the wireless network performance and

• High speed vehicular traffic effects on the wireless network

• Possibility that electronic noise from spark plugs and otherswitching devices effect the wireless network


2.3 communication modes 12

Infotainment, telematics, and mobile commerce are the mostprominent application areas for Bluetooth, Wi-Fi, and WiMAX. TheOriginal Equipment (OE) market for Bluetooth is expected to growsteadily from 2006 to 2012, while the OE market penetration forWiFi and WiMax should emerge during this time. High-end luxurysedans and SUVs are expected to become the first vehicles to adoptthese technologies in North America. The fact that there are manydifferent wireless network technologies in vehicles should stimulatethe market’s growth as the market matures. Bluetooth, Wi-Fi, WiMAX,UWB, ZigBee, and wireless Universal Serial Bus (USB) are some ofthe new wireless technologies that are offering automakers andtheir suppliers many possibilities to enhance the potential of theirproducts.

2.3 communication modes

This section will describe all the different communication modeswe can find on vehicular communications. The criteria used todifferentiate between the choice of communication mode are forexemple the number of receivers of the message, the need ofadditional infrastructures and whether the communication is director not.

V2V broadcast: in a V2V local broadcast a vehicle sends messagesto all vehicles within its communication range. To support thiscommunication mode one needs to take into account that theneighbouring vehicles change very frequently and that the range ofa vehicle is not very wide. Therefore depending on the security andimportance of the message the means by which it is transmitted canbe by bluetooth or Wi-Fi. However, most common in applications likecollision avoidance (a local broadcast to inform neighboring cars ofan accident) is DSRC.

V2V Multi-hop dissemination: in multi-hop dissemination messagesfrom one vehicle are relayed by other cars to reach vehicles that areoutside the source vehicle communication range. Depending on thenumber of hops (which affects to the latency) this communication canbe used to support hard or soft safety application. If for example thenumber of hops is very low, multi-hop dissemination can be used tosupport applications such as Emergency Electronic Brake Light. Onthe other hand if the number of hops is higher, it can be used tosoft safetey purposes such as the distribution of hazardous road andtraffic information.

I2V Local Broadcast: in this communication mode externalinfrastructure (roadside infrastructure) is required from whichvehicles receive local broadcast. The information of this messages canbe for example about traffic, dangerous road conditions or securitycredetials. There are two options in the implementation of thiscommunication mode. One is through short-range radio transceivers



deployed along the roadside and the other using cellular, satellite, ordigital radio broadcast services.

V2I Bidirectional Communications: vehicles require a lot ofservices for plenty of applications like navigation, email, electronictransactions or media download. To support this mode, both long anshort-range radios are valid. V2I communications can also be usedto broadcast messages from a vehicle to a group of vehicles throughinfrastructure application servers.

Mode DSRC Wi-Fi Bluetooth 3G 4G LTE

V2V local broadcast Yes Yes Impractical With a server With a server

V2V multi-hop Yes Yes Impractical With a server With a server

I2V local broadcast Yes Yes Impractical Not offered

by all

network

operators

Not offered

by all

network

operators

V2I bidirectional Yes Yes Impractical Yes Yes

Table 2: Communication modes/Technologies

The fact that there is a wide range of different application scenariosis the reason why there is such a huge number of protocols forVANETs.

Topology-based routing determines the network topology eitherin advance (proactive) or on demand (reactive). Hybrid versionsalso exist. Examples that include proactive routing protocols areDestination Sequenced Distance Vector (DSDV) and Optimized LinkState Routing Protocol (OLSR). The idea of all proactive routingprotocols is to determine the network topology before sending anydata packets. When a node system starts, firstly is initiates itsrouting protocol and exchanges routing protocol messages with allneighboring nodes. Depending on the degree of dynamics and thefrequency of the messages it might take a while to update the networktopology. When a packet is about to be sent the routing protocol looksfor a path to the destination node. This route could be expensive interms of routing protocols overhead.

On the other hand we have routing protocols based on othercharacteristics and resources, like high node mobility, which isa weak spot in old MANET routing solution. Nowadays manyapproaches have been developed to forward messages accordingto the store-carry-forward principle. This approach can be verysuccessful depending on the mobility patterns of the nodes in thenetwork. Energy is another characteristic used in routing protocols.This has been studied in wireless sensor networks (WSNs). It ishowever irrelevant in VANETs. The last characteristic to be mentionedis the geographic coordinates. They may replace the classical



assessment used in MANETs (ID-based routing). Ad-hoc routing willnot be realizable in most IVC scenarios. The general idea is tomake use of broadcast communication, and only re-broadcast theinformation if necessary. Clearly in extreme cases the network canbe overloaded when a few nodes are participating, but this canbe solved using some application-layer intelligence. This concept ofbroadcasting in vehicular communications has become known also asbeaconing. An example of the usage of this communication mode isan application called city alarm, which consists in sending an alertmessage to all the vehicles in a spread area.

ID or address-based routing using MANET protocols are not the bestchoice for VANETs. That is the reason why vehicles use a differentaddress information known as geographic coordinates. Given thatsatellite navigation systems are such a basic instrument in vehiclesone can assume that accurate geographic position information willbe available in the near future.

Greedy routing: messages that use geographic location as adestination address. In greedy routing each forwarding step routingis performed on the basis of neighbourhood information oridentifying the node which is closest to the destination (in termsof geographic distance), instead of the classic routing using somerouting table entries. This routing is very sensitive to the so-called“dead end” problem.

Virtual coordinates: due the possible inefficiency of dead ends apossible alternative is a hierarchical solution which can be furtherextended to completely switch to virtual coordinates on the overlayby performing some coordinate transformation. This solves the deadend problem at the cost of quite substantial efforts for topologymanagement.

Geo assisted forwarding: the main idea is that vehicles are able toroute packets “around the corner” if required. Vehicles will routethe packet using a relay node located exactly at the intersectionto make the communication possible. This is especially useful inurban environments where normally the line-of-sight communicationis blocked.


2.4 applications 15

2.4 applications

This section deals with a taxonomy of applications based on thenature of the messages, as shown below in Table 3.

Soft Safety Hard Safety Mobility Connectivity Convenience

Icy BridgeBlind Spot

Warning

Live Traffic

Updates

Media

Download

Point-of

Interest

Notifications

Disabled

Vehicle

Forward

Collision

Warning

Route

GuidanceEmail

Tickets and

Reservations

Construction

Zone

Emergency

Electronic

Brake Light

Off-Board

Navigation

Social

Networking

Intersection

Movement

Assist

Platoonig

Table 3: Taxonomy of applications

The main aim of hard safety applications is to avoid imminentcrashes or minimize the damage when crashes become unavoidable.These applications impose the most stringent requirements on thecommunication system in terms of latency and reliability.

Soft safety applications are less time-critical as they increase driversafety but do not require immediate driver reaction. Some examplesof soft safety applications are: icy roads, construction zones and trafficjams.

Mobility applications are used to improve traffic flow. One exampleof these mobility applications is the one which is evaluated in chapter4, Platooning.

The aim of both connectivity and convenience applications is tomake driving more enjoyable and to provide greater safety.

The two tables below expose some of the requirements as well as avariety of use cases of all the applications mentioned above.


2.5 challenges 16

Application Latency Reliability # Vehicles Area Persistence

Information

Query

x x xxx xxx

Hazard

Warning

xxx xx xx xxx

ACC, Brake

Light

xxx xx x x

Cooperative

Awareness

xx xxx x x x

Platooning xxx xxx xx xx x

Intersection

Assistence

xxx xxx xx x x

Table 4: Requirements

Application Distance Time Recipient

Hazard

Warning

250m 10s All

Location

vased service

1.5Km Weeks Subscribers

City Wide

Alarm

20Km Hours All

Travel Time

Information

5Km Minutes All

File Sharing 250m Minutes-Hours Subscribers&peers

Interactive

Services

1.5Km Minutes Subscribers

Table 5: Use cases

2.5 challenges

The development of sensors, processing and electronic devices alongwith advanced codes and protocols opened up new horizons in thecar industry all over the globe. Transceiver equipment in vehicles withcommunication protocols allowed for the potential to achieve a vastclass of applications in vehicular networking, some of which havebeen mentioned above. Despite the strong promises in improvingroad travelling efficiency by means of inter-vehicle communicationthere are still a number of difficulties to be faced. The most crucialchallenges of vehicular communication applications are as follows.

The main mission of IVC systems is to exchange data betweenvehicles equipped with on-board sensors and transceiver systems. Anevent differentiation block is required to filter and aggregate the inputdata so as to reduce the amount of transmitted data.


2.5 challenges 17

In actuality very few cars are equipped with IVC systems. Due tothe long lifetime of existing cars the growing rate of equipped carswill be slow, and also something to keep in mind for the future.

Once the point is reached where almost all cars are equippedanother issue to face is the flexibility of IVC systems as these systemsare based on a car-to-car communication and a sparse and densepresence of cars will cause different penetration and data transferrate.

Safety of IVC systems is the highest priority since they deal withhuman life. Any malfunction in IVC systems may cause a threatto all people involved. Therefore, to avoid any possible systemmanipulation high security protocols for IVC systems should beconsidered. These network protocols should be compatible with allapplications. In addition, user privacy needs to be protected from anyunauthorized access. An example for this is a proposed architecturefor security in communication called Communications Architecturefor Reliable Adaptive Vehicular Ad Hoc Networks (CARAVAN) thegoal of which is to develop protocols that protect the network frompossible threats.

Due to the high relative speed of the nodes the duration ofcommunication connection between nodes might be less than asecond. This implies that data transfer time should be as short aspossible.

This chapter describes the existing and future technologies forvehicular communications. With a more accurated knowledge ofpresent technology the following chapters focus on the tools availablefor test case simulations and deciding which is the most appropiatefor the study in hand.


Part III

E VA L U AT I O N O F V 2 V F R A M E W O R K S


3V 2 V S I M U L AT O R S

The possibility of running simulations without having to implementreal live experiments leads to results without the need of greatinvestments or the production of expensive infrastructures. Theresults obtained from these simulations can be used to make someideas become a reality such as the reduction of traffic congestion,improvement of road security, etc.

One of the biggest problems a mobility study faces is to acquirerealistic vehicular motion in the simulations. Furthermore thesemotion models have to be dynamically reconfigurable to reflect theeffects of a particular communication protocol.

Figure 3: Simulator example

There is a lack of coordination in this area as each researchgroup tries to develop a model motivated by its own particularneeds. This causes a slowdown in the process of obtaining a realisticmotion model. However, the motion models and tools available haveimproved a lot lately triggering a deeper research of more complexscenarios and increasingly large as well as more accurate analysis ofVANET protocols and applications.

This chapter involves an evaluation of all the simulators (mobilityand network) which can be used presently, the aim of which is to tryto find the best choice to run the simulations for this study, namelyplatooning.

3.1 taxonomy of simulators

VANETs are a particular case of MANETs, in which nodes have highspeed mobility and a limited degree of freedom in the movementpatterns. This is why one of the main goals in vehicular simulationsis to have a mobility model which reflects real traffic behaviour.

19


3.2 mobility generators (traffic simulators) 20

Figure 4: Taxonomy of simulators

Furthermore, there is a need to create scenarios where vehicularcommunication could change mobility and this mobility improve thecapacity of the network, which is why interaction between a mobilitymodel and a network simulator is needed.

Isolated Simulators: these initially sought to provide control ofnetwork simulators enabling simulators to load mobility patterns.The problem these simulators present is that the patterns have tobe generated previously to the simulation during which modificationis not possible. Therefore there is no interaction between the trafficsimulator and network simulator.

Integrated Simulators: in order to solve the interaction problempreviously mentioned an approach is to substitute both for a unifiedsimulator so as to obtain an interaction. The set-back to this is thata simpler system is created and quality of the network simulator islost.

Hybrid Simulators: there is a connection via an interface betweensimulators making the disturbance of mobility or network patternspossile as they are working in parallel. However, the computationalload required could be elevated.

3.2 mobility generators (traffic simulators)

The development of these simulators began when it became necessaryto model conflictive points in highways or urban crossings. There aresome limitations to using these simulators together with vehicularnetworks. The first is that they were created to simulate transportand traffic, therefore their design is not perfectly suitable for mobilitypatterns and networks simulators. The second limitation is thecomplexity of their calibration. These simulators have a very highrealism level requiring a lot of parameters therefore making thismethodology inefficient for a VANET simulation.

mobitools : Is a suite of mobility developed in Java using real mapscreating traces of mobility, the display MobiView (applicationthat allows to access NASA Landsat images) and a module to


3.3 communication networks simulators 21

Figure 5: Mobility Generators

calculate the effects of transmission. Similarly, it is compatiblewith ns-2, in addition to Google Maps and TIGER.

mitsimlab : Is is a microsimulation laboratory for analysis anddesign of dynamic traffic management systems which consistsof two main components, a Traffic Management System (TMS)and a microscopic traffic simulator (MITSIM).

citymob : Is a mobility pattern generator for VANETs designed to beused with the ns-2 simulator.

straw : It provides the most accurate simulation results by usinga vehicular mobility model on real USA cities, based on theoperation of real vehicular traffic.

texas : Is an intersection model traffic simulator the code of whichis available on internet. It can be used as previous evaluationof new intersection designs or to simulate changes in theenvironment of present intersections.

sumo : Allows the simulation of big road networks, either importingtopologies from different sources or by the creation of apersonal map.

In deciding which mobility generator suits the study in hand best theattributes which are most important to be taken into account includethe availability of an open code, versatility and the posibility ofworking with several network simulators. Hence, SUMO seems to bethe most appropiate mobility generator to fulfill all these conditions.

3.3 communication networks simulators

The behavior of the network and the various applications andservices can then be observed in a test lab using simulators. Variousattributes of the environment can also be modified in a controlledmanner to assess how the network would behave under differentconditions. This section describes the most important networksimulators (freeware).


3.4 vanets integrated simulators 22

Figure 6: Network Simulator

ns-2 : Is a discrete event simulator targeted at networking research.Ns provides substantial support for simulation of TCP, routing,and multicast protocols over wired and wireless (local andsatellite) networks. As it has been commented before Monarchproject expanded its horizon to wireless networks.

glomosim : Global Mobile Information SystemSimulator (GloMoSim) is a network protocolsimulation software that simulates wireless and wired networksystems. GloMoSim is designed using the parallel discreteevent simulation capability provided by Parsec, a parallelprogramming language. GloMoSim currently supportsprotocols for a purely wireless network.

gtnets : The Georgia Tech Network Simulator (GTNetS) is afull-featured network simulation environment that allowsresearchers in computer networks to study the behavior ofmoderate to large scale networks, under a variety of conditions.The design philosophy of GTNetS is to create a simulationenvironment that is structured much like actual networks arestructured. For example, in GTNetS, there is clear and distinctseparation of protocol stack layers.

omnet++: It is an extensible and modular C++ based tool dedicatedmainly for the creation of network simulations. Sensornetworks, wireless ad-hoc networks and photonic networks arealso included.

As coupling SUMO and OMNet++ is a possibility these seem tobe the best option as chosen framework for the simulation to beevaluated.

3.4 vanets integrated simulators

This section deals with the integrated simulators tools for VANET

simulations which are openly available to the research community.


3.5 hybrid vanets simulators 23

These integrated systems use a single model which includes bothmobility and network simulation.

ns3 : Is a discrete-event network simulator for Internet systemstargeted primarily for research and educational use. Ns-3 hasbeen developed to provide an open, extensible networksimulation platform for networking research and education.In brief, ns-3 provides models of how packet data networkswork and perform, and provides a simulation engine for usersto conduct simulation experiments. Some of the reasons touse ns-3 include to perform studies which are more difficultor not possible to perform with real systems, to study systembehaviour in a highly controlled, reproducible environment,and to learn about how networks work.

nctuns The NCTUns is a high-fidelity and extensible networksimulator and emulator capable of simulating various protocolsused in both wired and wireless IP networks, including IEEEWAVE 802.11p media access layer. Its core technology isbased on the novel kernel re-entering methodology inventedby Prof. S.Y. Wang when he was pursuing his Ph.D. degreeat Harvard University. Due to this novel methodology, NCTUnsprovides many unique advantages that cannot be easilyachieved by traditional network simulators such as ns-2 andOPNET. 6

Integrated simulators have a unified simulator resulting in simplersystems and loss of quality of the network simulator. Thesecharacteristics rule them out as an option for the study of this thesis.

3.5 hybrid vanets simulators

Integrated simulators offer some advanced features for vehicularmobility modelling and network capabilities. On the other hand theyare limited by a complex set up and low performance. A goodalternative is to associate both network and mobility simulatorscreating hybrid MANETs simulators.

mobireal : Is a novel network simulator for ubiquitous society withmobile devices. It can simulate realistic mobility of humansand automobiles, and enables to change their behaviourdepending on a given application context. Therefore, onecan get more detailed performance evaluation of networkapplications, routing protocols, infrastructure and so on whichexisting simulators cannot evaluate well. MobiREAL can easilydescribe mobility of nodes with C++. A probabilistic rule-basedmodel is adopted to describe behaviour of mobile nodes, whichis often used in cognitive modelling of human behaviour. Theproposed model enables the description of how mobile nodeschange their destinations, routes and speeds/directions basedon their positions, surroundings (obstacles and neighbouring


3.6 veins simulator 24

nodes), information obtained from applications, and so on. Theproblem that restricts its use is that it is not free software.

trans (Traffic and Network Simulation Environment): It is a GUItool that integrates traffic and network simulators (SUMOand ns2) to generate realistic simulations of Vehicular Ad hocNetworks. TraNS allows the information exchanged in a VANET

to influence the vehicle behaviour in the mobility model. Forexample, when a vehicle broadcasts information reporting anaccident some of the neighbouring vehicles may slow down. Itsuse is very wide and also very popular. It is able to couple ns-2networks and SUMO and its mobility traces are very realistic.

veins : It consists of a network simulator based on OMNET ++events and SUMO microscopic mobility generator, workingengagingly and real time. This tool will be discussed morethoroughly further on. However, it is described briefly inthis taxonomy simulators analysis and compared with othersimilar systems, specifically with TraNS. TraNS achievesinterconnection between SUMO and ns-2 using an active loopthrough which the network simulator sends control commandsto traffic. This allows to stop vehicles and / or modify theirroutes. However, the control of the time simulation has not beenconsidered on TraNS. The development process of TraNS hasbeen discontinued.

Figure 7: Veins www.ccs-labs.org/~dressler/projects/veins/ Last visit Juny2015

After having exposed the current simulators available (mostly freesoftware) a decision must be taken on the tools to be used thisstudy. It seems that the VANETs simulation is best suited by hybridsimulators such as TraNS and Veins. Both of these use SUMO as atraffic simulator. TraNS uses ns-2 as a network simulator and VEINSuses OMNeT++. Both are very valid options. However, most of theprevious researchers on platooning use Veins as the main simulator.There is plenty of information and references available as to whyVeins is the simulator of choice when aiming to create the mostrealistic simulation possible.

3.6 veins simulator

this section describes how vehicular simulations are made usingVEINS. As mentioned before, this simulator uses two importantsimulation tools: SUMO (traffic simulator) and OMNet++ (networksimulator), including also a communication module to make thecommunication between both simulators possible. It is considered an



extension of SUMO and is called TraCI. We will analyse every blockof the VEINS environment: first SUMO, then VEINS and finally wewill pay special attention to the communication module.

3.6.1 Traffic simulator: SUMO

A wrong approach would be to believe that traffic could be describedthrough departure time, route and duration, but this is completelyfalse. Traffic is hardly conditioned by individual mobility, so, neitherdeparture time nor routes are prefixed. This is a problem to modeltraffic, especially in private travels. This means that even complexmathematical formulas in some cases are unable to describe aparticular movement.

Both the human desire to leave and go somehwere else and themovement of the vehicle on the street have a strong and clearinfluence on traffic. Moreover, both factors influence each other: theload of roads (streets) depends on the departure times of drivers andtheir turn determines the speed of movement. The network load hasan effect on the departure times of drivers, because they desire tomove quickly and know the time of arrival at the desired destination.Apart from this, traffic is influenced by other parameters such asweather conditions, infrastructure or other incidents that may beaffecting the system.

With the proposal to achieve a simulation that takes into account allof these factors, the SMARTEST project was a collaborative initiativebetween different developed agencies and financed by the EuropeanCommission. Following the conclusions therein the Institute forResearch in Transport (German Aerospace Center) together withthe Applied Informatics Centre of Cologne (Germany) decided todevelop an open source tool that would satisfy the needs discovered.Thus was born in 2000 SUMO, which is an acronym for Simulationfor Urban MObility (Simulation for Urban Mobility). It is a packageopen source software for simulation of microscopic and multimodaltraffic code. The first characteristic that gives an idea of the mobilitymodel considers each vehicle as a distinct entity, increasing itscomputational load (as opposed with a macroscopic system, whichwould model only quantities of interest, such as vehicle density oraverage speed).

3.6.1.1 Basic Paradigms

SUMO is designed to simulate a road network traffic as big as acity, however it is also capable of modelling larger networks suchas highway systems. Since the simulation is multimodal, whichmeans that not only the movements of cars are modelled but alsopublic transport systems, the most basic component of simulationis an individual human being. This human being is described by adeparture time and route which it will take (which will be formed bysub-paths, which describe one way of traffic).



This implies that, for example, a person can drive to the nearestpublic transport station by car and continue its travel by other vehiclesor even on foot. However, movement on foot is not contemplatedin the simulation because this feature is irrelevant to the field ofVANETs.

As already stated, SUMO simulates traffic flow microscopically.This means that each vehicle moving by the simulated network ismodelled individually and is characterized by a certain position andvelocity. Per time interval, which has a duration of 1 second, theseparameters are updated depending on the vehicle position and thetopology of the track where the vehicle moves. The simulation ofvehicles is discretely in time and continuous in space, because themobility model used by SUMO is continuous.

3.6.1.2 SUMO Features

SUMO is in constant evolution and development as it is an opensource system. For the version used during the development of thisproject (the 0.22, but later will be discussed in more detail on this)the functions available to the simulator can be summarized roughlyin the following main points:

• Movement of vehicles in discrete time and continuous space

• Supports different types of vehicles

• Multilane roads

• Lane change

• Different modes of priority at intersections and traffic lights

• GUI (Graphic user interface)

• Supports road networks of tens of thousands of streets

• High speed performance (reaching 100,000 updates / secondper vehicle on a 1GHz)

• Interoperability with other applications in real time

• Supports import of topological maps for the road network

• Microscopic routes (each vehicle has its own)

• High portability (packages for Linux and Windows)

• High interoperability by using XML data

3.6.1.3 Mobility model

In SUMO an extension called Gipps model is used (invented anddescribed by Krauss). In this model, for each time instant the speedof the vehicle is adapted to the preceding vehicle. This results incollision-free behaviour for the following time intervals. This velocityv is calculated by the algorithm as follows:



v(t) = vp +g(t)·t− vp(t)

vb(v)

+ τ

Where

• v(t) is speed of the preceding vehicle at time t

• g(t) is the distance or gap to the preceding vehicle at time t

• τ is the reaction time of the driver (usually 1s)

• b is the deceleration function

The mobility model used in SUMO is a car-following model. Thediagram in Figure 8 explains the behaviour applied in this model.

Figure 8: car-following diagram

3.6.1.4 Topological maps

• Defined by the user manually, ie defining crosses and pointsbetween them the roads or streets), one by one

• Random

• Real maps by importation

3.6.1.5 Origin/destination

Equally, they can be user-defined, or be random

3.6.1.6 Intersections management

Traffic lights play an important role in the management ofintersections. Besides implemented basic priority rules intersectionscan also be controlled by traffic lights in the simulation.



3.6.1.7 Traffic generator

The traffic generator is responsible for the production of traffic. Thisis where the car-following paradigm is implemented. The modelassumes that the driver is subject to interaction with other vehicles,making the simulator resemble human behaviour.

Regarding the generation of routes the model does not distributevehicles statistically by the network; it uses daily plan data of driversin terms of travel and departure times. This data is loaded into thesimulator, but SUMO must however calculate routes itself from thedata. There is a specific module simulator in charge of reading timesof departure, points of origin and destination and calculates routesusing Dijkstra’s algorithm (1959).

Since street speed changes with traffic, the prior calculation toknow the traffic routes cannot be set to a real situation. In thiscase, obtaining the route is performed by the balancing algorithmUser Dynamic (Dynamic User Equilibrium) developed by ChristianGawron where the routing and simulation is repeated several timesto achieve a behaviour of the real world similar to the drivers.

3.6.2 Network Simulator: OMNet++

OMNeT++ is a discrete event simulator based on C++ for modellingcommunication networks, multiprocessors and other distributedsystems. Motivation to develop OMNeT++ arose from the need fora powerful tool based on discrete event simulation for use in theacademic, educational and commercial research-oriented institutionsfield. This tool is available to the public since September 1997, andits popularity has been increasing in the course of its developmentover the years. It is a project emerged in the Department ofTelecommunications at the University of Technology and Economics,Budapest (Hungary).

3.6.2.1 Modular structure

OMNeT++ model consists of hierarchical modules that communicatewith each other through message passing. The basic modules (calledsimple modules) are grouped into compound modules which can begrouped with other compounds, and so on without limitation; all ofwhich are contained in the higher level called system module. Allthese simple modules are instances of a basic module named "typemodule” which is who provides the basic functionality to deploymodules which compose the model.

Due to the hierarchical structure of this system, the messages(which may contain data structures) typically travel through chainsof connections between modules. The communication interfacesbetween the modules are called gates, which in turn are connectedto each other via connections.

Each connection has three associated parameters, which facilitatethe modelling of the communications network. These include the



propagation delay, error rate bit and the information transfer rate.This is done to customize the behaviour of each module and itsinteraction with others.

Chapter 3 describes the diferent kinds of network simulators andmobility generators that suit the simulations which will be describedin the next chapter. After analizing all the available tools, the decisionconcluded in using Veins for this study. Finally, what remains to beexplained are the simulations carried out by the study, the resultsachieved and the conclusions drawn.


Part IV

S I M U L AT I O N S A N D R E S U LT S


4E VA L U AT I O N O F P L AT O O N I N G I N A D E N S EU R B A N S C E N A R I O

The possibility of a self-driving vehicle as part of a road train startsbecoming real. This vehicle could drive solely by communicating withthe leading vehicle forming a platoon. Platooning can be described asa group of vehicles which drive automatically due to the controllersthey have installed allowing them to keep a constant distance with thepreceding vehicle. This group of cars is called platoon, and vehiclescan freely join or leave the platoon.

Figure 9: Platooning www.bbc.com/future/story/20130409-robot-truck-platoons-roll-forward Last visit: Juny 2015

4.1 kpi’s

Platooning has already been tested in highway scenarios. Thekey performance indicators to measure whether or not platooningimproves ordinary driving are:

• Fuel saving

• Security

• Travel time

The reduced drag of a car driving directly behind another saves fuel.The human factor is one of the main causes of car accidents, so ifthe driver is substituted by automatic driving, this risk is decreased.Mantaining a constant speed prevents jams, decreasing also traveltime.

Obviously, there are not only benefits. Reduction of freedomand questions like: Which is the role of the driver?, are someinconvenients in platooning. The maximum number of vehicles that

31


4.2 entities of a platoon 32

can conform a platoon differs between studies, but in most of casesapproximately 15 [8] is the maximum number of cars in a platoon.

4.2 entities of a platoon

In a conformed platoon 2 entities can be distinguished: leader andfollowers. The leader vehicle is the car that leads the platoon, andis also in charge of the management of numerous maneuvers thatmay occur in the platoon. Followers are all the cars which follow theleader.

There are three existing controllers:

• CC

• ACC

• CACC

Figure 10: Controllers

CC is already present in plenty of cars. It is in charge of mantaininga constant speed mainly in highways when there is not too muchtraffic. Modern cars are already provided with a radar-based system:Adaptive Cruise Control (ACC). This system is in charge of keeping asafety gap to the vehicle in front. ACC does not improve road trafficefficiency because of the size of the safety gaps it has to maintain.This is the reason that many projects have started working onits evolution: Cooperative Adaptive Cruise Control (CACC). CACCimproves safety, even while driving at small distances, because it usesIVC to enhance system’s reaction time.

4.3 controller models

In vehicles the independent control paramater for longitudinalmotion is the desired acceleraion xdesactuated by the car through thethrottle control (if the engine or brakes permit). Because of the laginduced by power-train dynamics, the actuation is not immediate. In


4.3 controller models 33

PLEXE this lag is modelled by a first order low-pass filter, and theresulting acceleration applied to the car is computed as:

x[n] = β·xdes[n] + (1− β)·x[n− 1] (1)

β =∆t

τ + ∆t(2)

As we can see the acceleration at simulation step n is computedbased on the desired accelaration, that is computed by the controller,and also taking into account the acceleration of the car in the previoussimulation step. τ is the time constant (in the simulation by defaultit is set to 0.5s), and ∆tis the SUMO update step in seconds. Theacceleration is limited to model physical limits: x∈[amin; amax].

4.3.1 CC

The first controller that PLEXE (an extension of Veins) provides isthe Cruise Control (CC), which is already available on plenty ofcommercial cars and allows the driver to select a desired speedautomatically maintained by the vehicle. The contol law is definedas:

xdes = −kp(x− xdes) + η (3)

Where:

• x is the current speed

• xdes is the desired speed

• kp is the gain of the proportional controller (default set to 1)

• η is a random disturbance taking into account imprecisions ofthe actuator and of the speed measure (default set to 0)

4.3.2 ACC

If a driver wants to avoid a collision when approaching a slowervehicle, he needs to manually disable the CC because the only inputsto the CC are the desired and actual speed. To improve this, high-endcars now include a radar or a laser scanner as well. When thesedevices detect a slower vehicle, they cause the vehicle to decelerate,and automatically maintain a safe distance. This is the AdaptiveCruise Control (ACC), and its control law is defined as:

xi-des = − 1T (ε + λδi)

δi = xi − xi−1 + li−1 + Txi ε i = xi − xi−1


4.3 controller models 34

Where:

• i identifies the controlled vehicle and i− 1 the vehicle in front.

• T is the time headway in seconds

• ε iis the relative speed between vehicle i and i− 1

• li−1is the length of the vehicle in front

• δi is the distance error, i.e., the difference between the actualdistance (xi − xi−1 + li−1) and the desired distance (Txi)

• λ is a design parameter strictly greater than 0 (default set to 0.1)

When the ACC is selected, the interaction between CC and ACC isimplemented as xdes = min(xCC, xACC). Which means that in the casethat if CC is mandating to accelerate to reach a desired speed, butACC is mandating to slow down because of there is a slower vehiclein front, the car will priorize the ACC. On the other hand if ACC ismandating to accelerate to follow the car in front but CC has reachedits desired speed, then CC will make the car “detach” from the onein front.

4.3.3 CACC

Controlers defined before are very useful complementing humanbehaviour, and also to control a platoon leader. But these controlersare not the most appropiate for followers. A platooning controller isstring stable when it is able to attenuate the propagation of motiondisturbances at the head of the platoon toward the tail of the platoon.The class of controllers able to realize platoon driving is knownas Cooperative Adaptive Cruis Control (CACC). In PLEXE we canfind two different CACCs. The CACC used in simulation is capableof maintaining a fixed speed-independent inter-vehicle distance. Itscontrol law of the i-th vehicle in the platoon is:

xi-des = α1 xi−1 + α2 x0 + α3 ε i + α4(xi − x0) + α5ε iε i = xi − xi−1 + li−1 + gapdesεi = xi − xi−1

Where:

• x0 is the acceleration of the leader

• x0 is the speed of the leader

• xi−1 is the acceleration of the preceding vehicle

• ε i is based on a constant desired distance gapdes in meters (5 bydefault)

The αi parameters are:


4.4 platoon maneuvering 35

• α1 = 1− C1

• α2 = C1

• α3 = −(2ξ − C1(ξ +√

ξ2 − 1))ωn

• α4 = −C1(ξ +√

ξ2 − 1)ωn

• α5 = −ω2n

C1is a weighting factor between the accelerations of the leader an thepreceding vehicle (default set to 0.5), ξ is the damping ratio (defaultset to 1), and ωn is the bandwidth of the controller (default set to0.2Hz).

As we did before, we will describe the iteraction of the CACC withthe CC. If a vehicle is farther than 20m from the one in front, thepolicy is the same as for ACC: xdes = min(xCC, xCACC), otherwisexdes = xCACC. Thus it is possible to have two different maxiumaccelerations, amax,CC, for the CC and the absolute maximum andminimum amax and amin representing the vehicle’s limit.

4.4 platoon maneuvering

A platoon has to be created, maintained, modified and disrupted.Therefore, platooning is not only about automated car following andstring stability. PLEXE allows one to test maneuvering on platoonsand the supporting protocols. Of all the maneuvering that exists inplatooning this study focuses mainly on the join maneuver.

4.4.1 Join Maneuvering

Platooning has plenty of maneuvers the most important of whichcould be considered to be, in terms of platoon creation, the joinmaneuver. This is when a car wishes to partake in a platoon. Whenthis happens, the vehicle approches the tail of the platoon and allthe rest must cooperate to enable this maneuver and coordinate thejoin. Figures 11 and 12 show the state machines of the sample joinmaneuver.

Vehicles which already belong to the platoon are not activelyinvolved in this maneuver. The “followers” are constantly receivingthe messages being exchanged, and are in charge of helping withthe platooning management like for instance informing drivers ofthe additional vehicle wanting to join the platoon. The leadingvehicle starts with the LEADING state and the joining vehicle startswith the IDLE state. Then the joiner requests the leader to join theplatoon (send_req), and changes to the WAIT REPLY state while theleader answers with the join_req primitive. In this primitive thereis information about the platoon such as lane, join position, etc.,and then the joining vehicle moves to the WAIT POSITION state.Using that data the joiner aproaches the last vehicle of the platoon,moving into the join position. Once the joiner reaches this position, it


4.5 particularities of plexe 36

Figure 11: State machines of the sample join maneuver: joiner

Figure 12: State machines of the sample join maneuver: leader

is notified to the leader and the vehicle is ready to join. Finally theleader sends back the confirmation and the joiner switches to CACC,closing its gap with its predecessor to the platoon inter-car distanceand the leader switches back to the LEADING state while the joinerto FOLLOW.

4.5 particularities of plexe

Both SUMO and Veins have been defined in the previous chapter.This section describes the details and changes applied to these twotools in order to enable platooning protocols and mobility.

4.5.1 Platooning Capabilities in SUMO

The main differences between a “clean” version of SUMO and theone that uses PLEXE is basically a new framework for car-following,



which enables both longitudinal control based on open or closed-loopcontrol of the acceleration and a simplified transversal controlto appropriately change lanes and obey platoon dynamics. Thesechanges make the Cruise Control (CC) available and accessible viaTraCI.

The user is free to modify the model to implement other CC orCACC models, but by default, CC uses the Krauss model to drivethe car, which is very useful to let a car join and leave the simulation(imitating human behaviour when a car enters and exits a highway).

The CC model in SUMO includes standard CC/ACC and oneadvanced CACC. Through the TraCI interface it is possible to accessthe model and modify its behaviour and get different information.For instance we can set desired speed xdes, headway time T, anddesired distance gap gapdes.

At runtime, the user can choose which component is controllingthe car, any CC, ACC, or CACC or any other controlling modelimplemented by the user itself. It is also possible to set differentbehaviours for the platoon leader:

• Constant or variable acceleration

• Constant or variable speed

• Emergency braking

4.5.2 Platooning Protocols and Applications in Veins

Veins provides a basic network stack. Every car is equiped withan IEEE 802.11p network interface card, and also an applicationlayer. In the code we can find a class named BaseProtocol, wherethe protocol layer is implemeted and the communication strategy toshare information among the vehicles in the platoon is defined. It alsoprovides functions to inherit classes like logging of statistics, sendingand receiving packets, and loading simulation parameters.

BaseApp is the class which controls the application layer. It is incharge of loading simulation parameters and passing data to theCACC via TraCI. Platooning applications decide which car is theleader of the platoon and which lane of the highway a car shouldtake.

Before focusing directly on the urban scenario test case findingthe appropiate parameters to be set in the controllers is primordial.Figure 13 is a flowchart with all the steps followed in the simulations.PLEXE is the main tool used for the simulations. It is an extensionwhich includes several enhanced capabilities that enable realisticstudies of platooning concepts and applications. Using Veins itis possible to simulate communication between vehicles and theirmobility within the road network. PLEXE integrates all necesarycomponents in order to study platooning.



Figure 13: Simulatons Flowchart


4.6 evaluation of the controller parameters 39

4.6 evaluation of the controller parameters

The goal of these simulaitons is to evaluate the viability of usingplatooning in urban areas. An evaluation of how CACC parametersaffect the join maneuver described in section 4.4.1 is the first stepin finding which values of these parameters are most suitable inan urban environment. The source code which will be used in thissimulation can be found under the veins-plexe-1.1 branch for Veins.

4.6.1 Simulation set up

The starting point will be the joinManeuver example which can befound in the example list on PLEXE. The map used in this sectionwill be the straight highway map. It can be found in the sumocfgdirectory of the joinManeuver example.

The parameters evaluated will be the 3 parameters of the CACC:ξ, C1, ωn. Simulations with diferent size of the platoon will be runalso to check whether or not size has an effect on the join maneuver.The two sizes of the platoon in this study are 4 and 6 cars, excludingthe joiner vehicle. All the value ranges can be set in the omnetpp.inifile, located in the main folder of the project. Table 6 shows the valuesof all the parameters and also the parameter ranges to be analyzed.Appendix B explains how to set all the simulations step by step.

Parameter Value

com

mun

icat

ion Path loss model Free space (α = 2.0)

PHY model IEEE 802.11pMAC model 1609.4 single channel (CCH)Frequency 5.89 GHzBitrate 6 MBit/s (QPSK R=1/2)Acces category AC_VIMSDU size 200 BTransmit power 20 dBm

mob

ility Leader’s speed 100 Km/h

Platoon size 4 and 7

Car length 4 mMaximum speed 120 Km/h

cont

rolle

rs

Engine lag τ 0.5 sWeighting factor C1 [0.1,1] step=0.1Controller bandwidth ωn [0.1,1]Hz step=0.1Damping factor ξ [1,10] step=1

Desired gap gapdes 5mDistance gain kd 0.7Speed gain ks 1

Table 6: Network and road traffic simulation parameters

4.6.2 Results

The goal of this study is the optimization of platoon creation in urbanscenarios. Platooning is more effective the longer a car stays in theplatoon, so the ideal would be for the joiner vehicle to reach theplatoon as fast as possible. The criterion to determine whether or notthe joiner vehicle belongs to the platoon is the distance between thejoiner and the last vehicle in the platoon. When that distance becomes



stable (less than 6 meters), one can assume the joiner belongs to theplatoon.

Figure 14 shows the plots obtained, by using Matlab (the process isfurther detailed in appendix B.3):

Figure 14: Time to reach the platoon (4 vehicles)

The results obtained when ξ changed (from 1 to 10) were that ina 100 seconds simulation the joiner only reached the platoon in thefirst case (ξ=1). So the plot is a single point when ξ=1, and the time toreach the platoon was 60.6 seconds. From the 2 plots above one canconclude that changing C1 does not significantly alter the time whichthe joiner vehicle needs to reach the last vehicle of the platoon. Thecurve of the time required versus bandwidth of the controller showedthat increasing the bandwidth affects the time to join the platoonconsiderably. A number of bugs were detected in the simulation whenthe value of the bandwidth was higher than 1.

Using the results obtained in “Operating Platoons On PublicMotorways: An Introduction To The SARTRE Platooning



Programme”[8] in which the maximum number of vehicles in aplatoon is assessed it is possible to build a more realistic simulation.Figure 15 shows the plots we obtain when the platoon is bigger. Inthis case there are 7 cars (6 plus the joiner):

Figure 15: Time to reach the platoon (7 vehicles)

The evaluation of the situation changing ξ is quite similar to the4 cars case because the joiner vehicle also reaches the platoon onlyin the case when ξ =1 (57.6 seconds). Both plots above are also quitesimilar to the 4 vehicles case. Comparing the first plot of Figure 13

(C1), there are 2 main differences. Firstly, the time to reach the platoonwhen C1 takes values from 0.1 to 0.7 is not constant (although, isalmost constant). Secondly, the time to reach the platoon is lower thatin a 4 cars platoon. These values in both plots are around 3-4 secondslower in comparision with the 4 cars platoon case because the joinervehicle starts both simulation cases (4 and 7 cars) on the same timestep.



4.6.3 Results evaluation

No significant changes were observed when the number of vehicleson the platoon increased from 4 to 7. However a longer platoon isa more realistic case than a 2, 3, 4 car platoon (maximum of 15).Therefore, in future, a 7 car platoon simulation will be considered. Allthe plots of the distance, acceleration and speed vectors can be foundin Appendix C. The next section explains how a join maneuver is runin an urban scenario. Distances in a city are much shorter than on ahighway causing cars to remain less time in the platoon. In order tonotice any advantages in terms of time and fuel economy it is crucialfor the joiner to reach the platoon as fast as possible and spend asmuch time as possible in it. The results of this section will be used todetermine which are the best values for an urban scenario.


4.7 use of platooning in urban environments 43

4.7 use of platooning in urban environments

Large cities have enabled special lanes in big streets for the exclusiveuse of buses and taxis. These lanes are an example of potentialplatoon lanes in urban environments. If a large part of the journeyto be made by a car coincides with a number of other cars as well asa bus line, then a platoon line may be established.

4.7.1 Map set up

A city map is needed in order to set up the next simulation. So as tonot complicate matters excessively it is better try to find a city areawithout complex intersections and crossings. A map of Barcelona(district of L’Eixample) was chosen for the simulation. Appendix B.2explanains how to download and set all the files properly.

4.7.2 Network set up

After setting up the traffic section of the simulation the next stepincludes the application layer of the controller. The changes appliedwill not be very significant yet are required for a correct run of thesimulation and to fix the bugs found. This will be explained furtheron. All the settings are detailed in the appendix B.2.

The CACC parameters were analyzed in the highway scenario. Atthis stage the only thing left is to set up the most suitable values ofthe CACC in the omnetpp.ini file The following are the values whichallow vehicles to join the platoon as fast as possible:

• ξ=1

• ωn=1 Hz

• C1=0.5

4.7.3 Explanation of the join maneuver simulation

This section clarifies all the different parts of the simulations in theurban scenario and how cars behave in each part of the simulation.

The simulation consists of 4 different parts:The first one entails platoon formation, which drives along the

rightmost lane of the main street on the map. There is a car in aperpendicular street which is the joiner and after turning right, it willjoin the platoon.



Figure 16: First part of the join maneuver

The second part is when the car reaches the main street and detectsthat there is a platoon matching its route. It will then send the joinrequest to the leader vehicle or bus, in this case.

Figure 17: Second part of the join maneuver



In the third part the joiner vehicle reaches the platoon andcontinues its route with it.

The last part is when the route of the joiner vehicle and the platoonfinally differ causing the joiner car to leave the platoon and continueits route alone.

Figure 18: Last part of the join maneuver



4.7.4 Dense urban traffic simulation

The goal of these simulations is to compare CO2 emissions of thejoiner car, with CO2 emissions of a car driving the same route ina dense traffic situation (without using platooning). The simulationof this dense traffic will be only in the main street of the route,assuming that the CO2 emissions on the rest of the trip are the samein both cases. The plexe-veins project: sinPlatoon allows simulationof a dense traffic situation.

The idea of simulating high dense traffic in the main street isto force the vehicle to have a sinusoidal speed in that part of thesimulation. To perform that, we just have to add the desired routeto the route file of this example, change the number of cars (therewill not be any platoon in this simulation, just a single car), and forcea sinusoidal speed in the desired time steps (in the aplication layerfile of the project). The same emissions than in the join maneuversimulation will be assumed, when the vehicle is not in the main street.

The procedure is quite similar to all the set ups done previouslyand therefore will not be explained as in depth as in the other cases.The simulation is very simple yet it will be simulated at differentsfrequencies (meaning different traffic densities) to check how thisaffects the results.

4.7.5 Results

The results from the simulations described in the section 4.7 will becomputed an analyzed in this section. The steps taken to reach theresults are explained in Appendix B.

In Figure 20 are the plots of the CO2 emission vector of the joinervehicle versus time, in 4 differents simulations. The values of ξ andωn have been changed in each simulation. This has made it possibleto check the correctness of the results obtained from the section 4.6and wether they match in this new environment.



Figure 19: CO2 emission plots

The first peak of these plots belongs to the first part of thesimulation when the joiner vehicle first accelerates until it reaches thefirst intersection. After that there is a second acceleration because thevehicle receives the position to join the platoon (second part of thesimulation). Then the CO2 emission, more or less, stabilizes (thirdpart). The small variations are due to the platoon driving throughintersections. Finally, around the 80 seconds, the vehicle leaves theplatoon and turns left in an intersetion to continue its route (the thirdpeak of the plots).

In the plots where ξ=1 and ωn=1 Hz (plots 2 and 4), the pointwhen the fluctuations are smoother appears earlier than in plots 1

and 3. This means that the joiner vehicle reaches the platoon fasterwhen the parameters of the controller are choosen from simulationsin section 4.6

Figure 21 shows the CO2 emission vector plotted when thesinusoidal speed is simulated.



Figure 20: CO2 emission (sinusoidal plots)

These two plots show the CO2 emissions of a single car duringits trip. Every peak corresponds with the acceleration of the carto achieve sinusoidal speed. The peaks are not periodical becausewhen the car reaches an intersection it has to decelerate or acceleratedepending on the traffic lights or the speed limit.

The last step will be to integrate the curves in order to obtain thetotal CO2 emissions in each case and analyze the results. Table 7

shows the percentages of CO2 emissions saved in every frequencycase.

Frequency ξ=1 ξ=2

0.01Hz -13.9724% -22.1080%

0.02Hz 12.4041% 6.1514%

0.03Hz 19.8075% 14.0832%

0.04Hz 23.3598% 17.8891%

0.05Hz 21.0395% 15.4031

0.06Hz 5.0577% -1.7195%

0.07Hz 21.3831% 15.7713%

0.08Hz 31.8600% 26.9961%

0.09Hz 30.1010% 25.1115%

0.1Hz 28.4461% 23.3384%

Frequency ξ=1 ξ=2

0.11Hz 28.8733% 23.7961%

0.12Hz 28.0528% 22.9171%

0.13Hz 39.8456% 35.5517%

0.14Hz 37.3618% 32.8905%

0.15Hz 27.3106% 22.1218%

0.16Hz 31.0316% 26.1084%

0.17Hz 28.8640% 23.7862%

0.18Hz 35.9528% 31.3810%

0.19Hz 38.7235% 34.3495%

0.2Hz 30.2113% 25.2297%

Table 7: CO2 emission saving in the platoon


4.8 conclusion 49

Table 8 shows the percentage of time saved in the whole trip underthe assumption that the time spent in the platoon is a third of thejourney made by the vehicle.

Frequency ξ=1 ξ=2

0.01Hz -2.6651% -4.2168%

0.02Hz 2.9112% 1.4437%

0.03Hz 4.9701% 3.5338%

0.04Hz 6.0627% 4.6428%

0.05Hz 5.3407% 3.9100%

0.06Hz 1.1154% -0.3792%

0.07Hz 5.4457% 4.0165%

0.08Hz 9.0086% 7.6333%

0.09Hz 8.3565 % 6.9713%

0.1Hz 7.7643% 6.3702%

Frequency ξ=1 ξ=2

0.11Hz 7.9152% 6.5234%

0.12Hz 7.6265% 6.2303%

0.13Hz 12.3005% 10.9750%

0.14Hz 11.2137% 9.8717%

0.15Hz 7.3693% 5.9692%

0.16Hz 8.6985% 7.3185%

0.17Hz 7.9120% 6.5201%

0.18Hz 10.6235% 9.2726%

0.19Hz 11.8019% 10.4688%

0.2Hz 8.3967% 7.0121%

Table 8: CO2 emission total saving

4.8 conclusion

In summary, after finding which are the most suitable values for theCACC, running the join maneuver of platooning in a urban scenarioand comparing the CO2 emission values with a dense traffic situation,the obtained values can be found tables 8 and 9.

Two conclusions can be drawn from these tables. Firstly, that themore time is spent in the platoon (ξ=1) the less CO2 emission isexpelled by the vehicle. Secondly, that the more traffic there is onthe road (high frequencies) the higher the CO2 saving. Negativepercentages are obtained only when the frequency is very low,meaning that traffic is not dense at all, and that there is no CO2 savingwhen platooning is used under these conditions.

In conclusion, platooning should not be used when there is lowfrequency traffic on the road, as otherwise the CO2 emission ofthe hypothetic vehicle would be higher. When the frequency of thesimulated traffic is 0.06Hz there is a notable decrease in % of CO2

saving differing from the trend of the results. The reason for thisis that there is a bug on intersections causing the vehicle to brakeand accelerate in a short time period. This was observed runningthe simulation again and checking the speed values in every timestep with the debugger. For some reason this bug is not present inthe other simulations, which is why this value should not be takeninto account. The mean values obtained from both experiments are7.1084% (ξ=1), and 5.7044 (ξ=2). These results show that platooninghas a positive outcome in CO2 saving in urban scenarios.


4.8 conclusion 50

The results are plotted in Figure 22.

Figure 21: Plots of the results

High fluctuations can be noticed in frequencies from 0.08Hz to0.2. The inaccurate traffic model generated and the bug observed onintersections are responsible for this phenomenon. Figure 23, as wellas the first plot above, shows a curve of the ideal trend correspondingwith the next equation:

y = K1 ∗ (1− e−1/K2)


4.9 future work 51

Figure 22: Ideal trend

4.9 future work

The simulations brought about in this study are not as acurate ascould be hoped for. In order to make this more realistic and improvefuture ressearch aims to be taken into account include improving thetraffic model, running the simulations in the most realistic scenariopossible, and fixing the intersection bug found during the simulations.A more challenging future goal is to try to find the constants of theideal trend equation and see if there is a relationship between theparameters of the controllers.

The results of this study prove that the use of platooning in urbanenvironments is a viable option in reducing time of travel and CO2

emissions, at least in the proposed scenario. Fuel saving is the mostrelevant achivement of platooning in urban scenarios as it causes adirect decrease in costs. The use of platooning in high density trafficsituations has been shown to reduce time of travel.

This is only a first approach to platooning in cities, and furtherand more extense research will be necesary to prove whether or notplatooning can become a reality in urban scenarios.


Part V

A P P E N D I X


AS O F T WA R E I N S TA L L AT I O N

a.1 installing omnet++

OMNeT++ is the core part of the network simulation frameworkprovided by Veins. In here, we consider version 4.4.1. To buildOMNeT you will first need to install some libraries. On a Linuxsystem, type

• $ sudo apt-get install bison flex tk8.5-dev

Then you will need to add the OMNeT++ bin folder to your path, byadding to your .bash_rc or .profile

• export PATH=$PATH:$HOME/src/omnetpp-4.4.1/bin

After downloading OMNeT (source plus IDE) from the officialwebsite in your home folder, extract and compile it with

• $ cd

• $ tar xzf omnetpp-4.6-src.tgz

• $ cd omnetpp-4.6

• $ ./configure

• $ make

All the information needed to know how to work with this tool canbe found on the OMNet[13] website

a.2 downloading plexe extension

Plexe source code can be either downloaded in a tar.bz2 archive onthe PLEXE[14] website, or via git through the public repository. Toobtain the archive please visit the download page 4 . In there youwill find two files, plexe-veins-1.1.tar.bz2 and plexe-sumo-1.1.tar.bz2,containing a modified version of Veins and SUMO respectively.Download, place, and extract them in source folder by typing inyour terminal.

• $ cd

• $ cd src

• $ tar xjf plexe-veins-1.1.tar.bz2

• $ tar xjf plexe-sumo-1.1.tar.bz2

53


A.3 building sumo 54

a.3 building sumo

The procedure is similar for both Linux and Mac OS systems, butwith some small differences in the commands. SUMO depends onsome third party libraries which can be installed on a Linux machinewith

• $ sudo apt-get install libgdal-dev libproj-dev \ libxerces-c-devlibfox-1.6-dev libtool \ autoconf

After installing the dependencies, SUMO can be config- ured with

• $ cd ~/src/plexe-sumo

• $ make -f Makefile.cvs

• $ ./configure

On both systems, SUMO can then be built by simply typing make onthe command line. The final step is to add the SUMO bin directoryto your PATH. Add to your .bash_rc

• export PATH=$PATH:$HOME/src/plexe-sumo/bin

Now you should be able to run SUMO by typing either sumo orsumo-gui for the command line and the GUI version respectively.

a.4 building plexe veins

Building Plexe Veins is the simplest step. Just type the following onthe command line

• $ cd ~/src/plexe-veins

• $ make -f makemakefiles MODE=release

• $ make MODE=release

a.4.1 Installing R

R is a powerful statistical framework which can be used to parse,process, and plot data obtained through OMNeT++ simulations. Theplots in Figures 1a and 1b have been obtained with a few lines ofcode. To install R, open a terminal and type

• $ sudo apt-get install r-base

You will then need to install OMNeT++ package for R, ggplot2, andreshape. To install ggplot2 and reshape, open the R console andsimply type

• install.packages(c(’ggplot2’, ’reshape’))

Once installation is complete, exit the console by hitting CTRL+Dtwice. Download the OMNeT++ R package 7 and then install it bytyping


A.4 building plexe veins 55

• $ R CMD INSTALL /path/to/download/omnetpp_0.2-1.tar.gz

on your terminal. Your R environment should now be correctly setup.


BS I M U L AT I O N S E T T I N G S

b.1 first simulation

This appendix explains how to set up the highway simulations. Startsexplaining how to set the desired values of the controller for the firstscenario.

The figure below shows the files where the range of values for thesimulations are set. This is the omnetpp.ini file of the joinManeuverproject. Values can be set just typing the next line.

Figure 23: omnetpp.ini file (joinManeuverPlatoon example)

*.node[*].appl.caccC1 = ${caccC1=0.1..1 step 0.1} #weghting factor(default 0.5)

This line could be translated as: set the C1 parameter of the CACCcontroller of every node (node[*]) to values from 0.1 to 1 in 0.1 steps.# it is only used to add notes (after # the code is not compiled).

To run the simulation first of all we have to use this comand in theterminal, to prepare the socket that connects Omnet++ with SUMO,so we open a terminal an type:

$ ./sumo-launchd.py -c /plexe-sumo/bin/sumo-gui

Is important to say that the SUMO version used, has manychanges from a clean SUMO version, therefore this version can bedownloaded from the plexe website[6].

56


B.1 first simulation 57

The graphic user interface only allows to run simulations one byone, so ,in order to run all the simulation in a row, we will use anotherterminal command. However, before that this is necesary to add thenext lines in the “freeway.sumo.cfg” that is located in the sumocfgdirectory of this same example:

<gui_only><start value="true"/></gui_only>

Then, everything is ready to launch the simulations. So the onlything left is change to the joinManeuverPlatoon directory and type inthe shell:

$ ./run -u Cmdenv -f omnetpp.ini -c JoinManeuver -G

After that the SUMO GUI come out and automatically will startrunning the simulation. It is possible to see how the simulationelapses in the SUMO GUI and check that all the SUMO files arecorreclty set (number of vehicles, lanes, speed, type of vehicles).

Figure 24: SUMO GUI: Freeway example

Once all these 30 simulations have finished, every run has 3

different files as outputs: .vec, .sca and .vci. All of them can be foundin the results directory. In the example already exists a tool to processand analyze the outputs of these simulations, it is a R script locatedin the analysis directory, which also need to be modified to load allthe files and plot the desired results. The acquired plots from thesescripts are:

• distance (between a car and the previous one)

• speed

• acceleration


B.2 second simulation 58

of every vehicles (available in Appendix C).

b.2 second simulation

The second scenario is a little bit more complex, so this appendixexplains how to download set and build the map and the network.

b.2.1 Map set up

SUMO has compability with .osm exported maps from Open StreetMap website[12], so we export map from the desired zone ofBarcelona, and we obtain the .osm file.

Second step will be convert this .osm file into a .xml file so we goto the /sumo/bin directory and type the next command:

$ netconvert –osm-files cityAreaPoly.osm -o cityAreaPoly.net.xml

We also need an aditional file that we create with this command:

$ polyconvert –net-file kl.net.xml –osm-files kl.osm –type-filetypemap.xml -o kl.poly.xml

After that the route file has to be created. Using the .rou.xml file inthe join maneuver example we create the our platooon route and ourjoiner route for our urban map. This route file looks like this:

Figure 25: Route file

The only thing remaining is create a .sumo.cfg file, referring to allthe files we create before:

Finally, we will check, whether or not, the routes and the maps wehave created, work correctly typing this on the terminal:

$ ./sumo gui -c sumofile.sumo.cfg


B.2 second simulation 59

Figure 26: sumo.cfg file

When we run this command, we can check in the GUI of SUMOthat the map has been built correctly and the cars drive through thecorrect routes.

b.2.2 Network set up

First of all we need to add 3 vehicles to the platoon, each one withthe correspondig id, set the platoon lane we are going to use in thesimulation, change the id of the last vehicle of the platoon (requiredto send to the joiner the correct position it has to join the platoon),set the time of the join maneuver request message, and also lead thejoiner to the correct lane on the exact time step when it has to leavethe platoon. Some of these changes can be seen on this figure:

Figure 27: JoinManeuverApp.cc


B.3 procesing data 60

To correct the bugs that force vehicles to change line, the next lineis necesary to change vehicle’s lane in the correct time step.

traci->commandSetFixedLane(traci->getExternalId(), 0);

b.3 procesing data

Matlab is the tool choosen to procees the data. Typing the next shellcommand is possible to filter the desired vectors from the .vec outputfile:

$ awk ’{if($1==number_of_desired_vector)print$4""$3}’<output_file_from_omnet.vec >output.txt

With this command the .txt file created, contains 2 columns.Distance values in the first column, and the corresponding simulationtime in the second column. With this format is easier to load the datainto matlab. After starting up matlab and chososing the workspacewhere all the .txt files created before are, the only thing left is run thisscript to process the data and obtain the plots:


B.3 procesing data 61

a=[’1’,’2’,’3’,’4’,’5’,’6’,’7’,’8’,’9’,’10’];time=zeros(1,10);for i=1:10;s1=’distance_’;if(i==10)s2=’0_0.2_0.5.txt’;elses2=’_0.2_0.5.txt’;ends3=strcat(s1,a(i));s4=strcat(s3,s2);H=load(s4);b=H(:,1);k=find(b<0);d=b;for j=1:length(k)d(k(j))=NaN;endc=H(:,2);y=find(d<6);if (length(y)>0)time(i)=c(y(1)-300);elsetime(i)=NaN;endendtime z=[1 2 3 4 5 6 7 8 9 10];plot(z,time)xlabel(’Psi’);ylabel(’Time to reach the platoon’);

This script allows to load all the data from Omnet++, process andplot the curves that shows us how much the time takes the joinervehicle to reach the platoon, versus all the values of the parametersassigned before. There is a few things that should be mentioned. Thefirst 10 seconds the joiner car still do not exists and in this case Omnetassigns the value -1 when that happens thats why have to fix that toprocess the data correctly. There is a first 30 seconds in the simulationwhen the scenario is being conformed and CACC is not working, sowe have to take away this 30 first seconds when we want to computethe time that needs the joiner to reach the platoon.

There are 6 different scripts to compute every output data form allthe values of the controller parameters. The differences between eachscript are minimum: name of the loaded files and value of the x axis.


CP L O T S

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

0.10.2

0.30.4

0.50.6

0.70.8

0.91

0 25 50 75 100time

acce

lera

tion

factor(nodeId)

0

1

2

3

4

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0.10.2

0.30.4

0.50.6

0.70.8

0.91

0 25 50 75 100time

dist

ance

factor(nodeId)

1

2

3

4

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

0.10.2

0.30.4

0.50.6

0.70.8

0.91

0 25 50 75 100time

spee

d *

3.6

factor(nodeId)

0

1

2

3

4

Figure 28: Plot changing bandwidth in a 4 cars platoon

62


plots 63

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

12

34

56

78

910

0 25 50 75 100time

acce

lera

tion

factor(nodeId)

0

1

2

3

4

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

12

34

56

78

910

0 25 50 75 100time

dist

ance

factor(nodeId)

1

2

3

4

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

12

34

56

78

910

0 25 50 75 100time

spee

d *

3.6

factor(nodeId)

0

1

2

3

4

Figure 29: Plot changing psi in a 4 cars platoon


plots 64

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

0.10.2

0.30.4

0.50.6

0.70.8

0.91

0 25 50 75 100time

acce

lera

tion

factor(nodeId)

0

1

2

3

4

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0.10.2

0.30.4

0.50.6

0.70.8

0.91

0 25 50 75 100time

dist

ance

factor(nodeId)

1

2

3

4

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

0.10.2

0.30.4

0.50.6

0.70.8

0.91

0 25 50 75 100time

spee

d *

3.6

factor(nodeId)

0

1

2

3

4

Figure 30: Plot changing C1 in a 4 cars platoon


plots 65

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

12

34

56

78

910

0 25 50 75 100time

acce

lera

tion

factor(nodeId)

0

1

2

3

4

5

6

7

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

12

34

56

78

910

0 25 50 75 100time

dist

ance

factor(nodeId)

1

2

3

4

5

6

7

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

12

34

56

78

910

0 25 50 75 100time

spee

d *

3.6

factor(nodeId)

0

1

2

3

4

5

6

7

Figure 31: Plot changing bandwidth in a 7 cars platoon


plots 66

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

−4

−2

0

2

0.10.2

0.30.4

0.50.6

0.70.8

0.91

0 25 50 75 100time

acce

lera

tion

factor(nodeId)

0

1

2

3

4

5

6

7

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0255075

100

0.10.2

0.30.4

0.50.6

0.70.8

0.91

0 25 50 75 100time

dist

ance

factor(nodeId)

1

2

3

4

5

6

7

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

100

120

140

0.10.2

0.30.4

0.50.6

0.70.8

0.91

0 25 50 75 100time

spee

d *

3.6

factor(nodeId)

0

1

2

3

4

5

6

7

Figure 32: Plot changing C1 in a 7 cars platoon


B I B L I O G R A P H Y

[1] On the Applicability of Two-Ray Path Loss Models for VehicularNetwork Simulation. (Cited on page 5.)

[2] Bidirection Coupled Network and Road Traffic Simulation for ImprovedIVC Analysis. (Cited on page 5.)

[3] A Simulator for Heterogeneous Vehicular Networks. (Cited onpage 5.)

[4] A Simulation Tool for Automated Platooning in Mixed HighwayScenarios. (Cited on page 5.)

[5] A Multi-Channel IEEE 1609.4 and 802.11p EDCA Model for theVeins Framework. (Cited on page 5.)

[6] PLEXE: A Platooning Extension for Veins. (Cited on pages 5

and 56.)

[7] Towards Realistic Simulation of Inter-Vehicle Communication: Models,Techniques and Pitfalls. (Cited on page 5.)

[8] Operating Platoons On Public Motorways: An Introduction To TheSARTRE Platooning Programme. (Cited on pages 32 and 41.)

[9] Progressing Toward Realistic Mobility Models in VANET Simulations.. (Cited on page 5.)

[10] Towards Inter-Vehicle Communication Strategies for PlatooningSupport. . (Cited on page 5.)

[11] Christoph Sommer & Falko Dressler. Vehicular Networking.Cambridge University Press, Cambridge, UK, 1st edition, 2015.(Cited on page 5.)

[12] Open Street Map. www.openstreetmap.org. (Cited on page 58.)

[13] OMNeT++. www.omnetpp.org. (Cited on page 53.)

[14] PLEXE. www.plexe.car2x.org. (Cited on page 53.)

[15] METIS Project. www.metis2020.org, May 2015. (Cited on page 4.)

[16] Karlsruhe University. www.hs-karlsruhe.de, May 2015. (Citedon page 4.)

[17] Luca Delgrossi & Tao Zhang. Vehicle Safety Communications:Protocols Security and Privacy. Online, 2012. (Cited on page 4.)

67


Date post:	27-Oct-2021
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Study of a platooning use case in a dense urban scenario

Documents