IT 17 085

Examensarbete 30 hpNovember 2017

An Urban Mobility Overlay for Evaluating Cellular Driven Vehicle Teleoperation

Yiqing Wang

Institutionen för informationsteknologiDepartment of Information Technology

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

An Urban Mobility Overlay for Evaluating CellularDriven Vehicle Teleoperation

Yiqing Wang

Cellular Driven Vehicle Teleoperation is far too expensive to deploy and implementin real life. Most research community use simulation as a solution. Nowadays mostevaluations are based on one simulator either for traffic or network. In order toguarantee the safety and accuracy for operating a vehicle at distance, in this project,we first did a state-of-art study of simulators and developed traffic and networkscenarios using microscopic traffic simulator SUMO (Simulator of Urban MObility)and accurate network simulator NS3 (Network Simulator 3) then integrated themtogether. To have the accurate result the scope of the traffic mobility model need tobe realistic and fulfill several requirements and we have accomplished all the generalrequirements needed such as map size, mobility obstacles (traffic congestion, cardensity, road regulation) and realism. The process of the work is presented in thisreport.

We evaluate the integrated scenario from aspects of feasibility, capacity andperformance and the result shows that it's feasible to use LTE network to teleoperateup to 5 vehicles with granted Quality of Service requirements in area of Kista. Adrawback of this project is the simulation is off-line. Furthermore, to simulate thebehavior of on-line simulation we include traffic congestion avoidance and we run thesimulation multiple times in small time scale.

Tryckt av: Reprocentralen ITCIT 17 085Examinator: Mats DanielsÄmnesgranskare: Edith NgaiHandledare: Aneta Vulgarakis

Popular Scientific Summary in Swedish

Cellulart driven fordonsteleoperation ar alldeles for dyr att distribuera och implementera

i verkligheten. Sa i de flesta forsknings sammanhang ar simulering en losning. I dagens

forskning ar utvarderingen baserad pa en simulering antingen for trafik eller natverk.

For att garantera sakerhet och noggrannhet for ett fordon i rorelse pa ett avstand, i detta

projektet, har vi forst studerat ”the state of art” av simulatorer och utvecklat trafik och

natverk scenarios med hjalp av microscopic traffic simulator SUMO (Simulator of Urban

MObility) och accurate network simulator NS3 (Network Simulator 3 ) sen integrerade

dem tillsammans. For att astadkomma ett noggrant resultat behovde omradet som

man undersokte vara realistiskt och uppfylla flertalet krav och vi hade genomfort alla de

generella kraven som behovdes sa som kartstorlek, mobilitetshinder (trangsel, fordons

tathet, vagreglering) och realism. Processen for arbetet beskrivet ovan ar presenterat i

denna rapport.

Vi utvarderar de integrerade scenariona fran de foljande aspekterna genomforbarhet,

kapacitet och prestanda och resultatet visar att det ar genomforbart att anvanda LTE

network for att utfora teleoperation upp till 5 fordon, med tillaten Quality of Service krav

i Kista omradet. En nackdel av detta projektet ar att det ar en off-line simulering. Vi-

dare, for att simulera beteendet av en on-line simulator inkluderade vi trangsel avvikande

atgarder sa att ”operatoren” andrar fordonets mobilitetsmonster medans simuleringen

ar korande, dessutom kordes multipla simuleringar.

Acknowledgements

This thesis is carried out in Ericsson Research in Kista and the process is quite informa-

tive. During the project work i experienced how research work is done in a real industrial

company.

I would like to sincerely thank my supervisor Aneta Vulgarakis, Senior Researcher at

Ericsson Research, for her great help and support all the way from developing of the

project to the report writing. I benefit a lot from your ideas, suggestions and comments.

I would also like to give thanks to my reviewer Edith Ngai, Associate Professor at

Uppsala University for her valuable help and support.

Also credits go to my co-worker Yifei Jin, Master student in Royal Institute of Technol-

ogy(KTH), for his remarkable contribution building the network scenario in the project.

As well as all the other people from the research group Cognitive Automation Lab:

Elena Fersman, Rafia Inam, Athanasios Karapantelakis and Kevin Wang. Thank you

for the time sharing with me and the support.

Once again Thank you all.

iv

“In a connected world, everything is possible.”

Quote from Ericsson’s site

Contents

Abstract ii

Acknowledgements iv

List of Figures vii

List of Tables viii

1 Introduction 1

1.1 Vehicular Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Vehicle-to-Everything . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Research Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Thesis Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background 5

2.1 Traffic Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 State of Art of Mobility Model . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Comparison of Traffic Simulator . . . . . . . . . . . . . . . . . . . 7

2.2 Vehicles Routing Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Heuristics in Routing: A* algorithm . . . . . . . . . . . . . . . . . 10

3 Implementation 13

3.1 Build Kista Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.2 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.1 Real-time Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.2 Off-line Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Evaluation 23

4.1 Simulation Summary of SUMO . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Conclusion and Future Work 27

v

vi

Bibliography 29

List of Figures

1.1 An example of V2I and V2V scenario use LTE . . . . . . . . . . . . . . . 2

1.2 An example of V2X scenario[1] . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Illustration of Simulation Framework . . . . . . . . . . . . . . . . . . . . . 4

2.1 Level of mobility model[2] . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 General concept map of mobility model generation[3] . . . . . . . . . . . 7

2.3 Example of Manhattan, Diagonal and Euclidean distance . . . . . . . . . 11

3.1 Select large area from OSM . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 JOSM view of Kista OSM file . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3 After Filtering Out Irrelevant Nodes . . . . . . . . . . . . . . . . . . . . . 15

3.4 After Filtering Out Irrelevant Nodes and Buildings . . . . . . . . . . . . . 15

3.5 Kista Scenario Road Network . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.6 Kista Scenario Topology with Polygons . . . . . . . . . . . . . . . . . . . 16

3.7 Kista Fading Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.8 Overview of steps to generate SUMO map file[4] . . . . . . . . . . . . . . 17

3.9 Bus Stop Location in Kista Scenario . . . . . . . . . . . . . . . . . . . . . 18

3.10 Example Bus Route No.178 from OSM . . . . . . . . . . . . . . . . . . . 18

3.11 Establishing a connection to SUMO[5] . . . . . . . . . . . . . . . . . . . . 19

3.12 Closing a connection to SUMO[5] . . . . . . . . . . . . . . . . . . . . . . . 20

3.13 VSimRTI architecture[6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.14 Illustration of real-time simulation work flow between SUMO and NS3 . . 21

3.15 Illustration of off-time simulation work flow between SUMO and NS2[2] . 22

4.1 Traffic Condition in Google Maps at 8:00 am . . . . . . . . . . . . . . . . 24

4.2 Delay for Critical Stream in 10M Background Traffic . . . . . . . . . . . . 24

4.3 Packet Loss Ratio for Critical stream in 10M and 1M Background Traffic 25

4.4 Geometry location of antenna and vehicle route . . . . . . . . . . . . . . . 25

4.5 Packet Loss Ratio for non-Critical stream in 10M and 1M Back-groundTraffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.6 Capacity for Bus Router per eNB . . . . . . . . . . . . . . . . . . . . . . . 26

vii

List of Tables

2.1 Features of Main Stream Traffic Simulators-1 . . . . . . . . . . . . . . . . 9

2.2 Features of Main Stream Traffic Simulators-2 . . . . . . . . . . . . . . . . 9

2.3 Features of Main Stream Traffic Simulators-3 . . . . . . . . . . . . . . . . 9

3.1 Topology Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Number of Polygons in the Kista Scenario . . . . . . . . . . . . . . . . . . 16

3.3 Summary of Bus in the Kista Scenario . . . . . . . . . . . . . . . . . . . . 18

4.1 SUMO Simulation Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23

viii

Initials ix

CN Core Network

CQI Channel Quality Indicator

eNB Evoloved NodeB

HetVNET Heterogeneous Vehicular NETwork

LTE Long Term Evolution

QCI QoS Class Identifier

QoS Quality of Service

RAN Radio Access Network

RSSI Received Signal Strength Indicator

SUMO Simulation of Urban MOblity

UE User Equipment

VANET Vehicular Ad Hoc NETwork

V2X Vehicle to Xeverything

Chapter 1

Introduction

1.1 Vehicular Networking

As the consequence of rapid development of the wireless communication and the con-

cept of Internet-of-Things, vehicular communication has been gathering more and more

interests among the research community and industry during recent years. Many vehi-

cle manufactures have decided to include radio communication interface in their latest

model of vehicles. The number of cars with wireless transmitter is increasing and enor-

mous data are collected which will be beneficial for the whole society by contributing a

more efficient and safer traffic environment.

1.1.1 Vehicle-to-Everything

There are several vehicular communication types namely Vehicle-to-Vehicle(V2V), Vehicle-

to-Infrastructure(V2I), Vehicle-to-Network(V2N) and Vehicle-to-Pedestrian(V2P) with

focus on different aspects. For example V2V normally refers to the communication be-

tween vehicles with focus on safety. Information can be received by the vehicle nearby

to the event(accident, road congestion point, etc...) and send to the vehicle approaching

the incident to improve traffic efficiency and safety. V2I generally refers to the commu-

nication between vehicles and the network infrastructure with focus on traffic efficiency.

1

Initials 2

Figure 1.1: An example of V2I and V2V scenario use LTE

V2X(Vehicle-to-Everything)[1] contains any types of communication as long as any ve-

hicle is involved, either as source or destination. Different manufactures of vehicles can

communicate by using wireless communication through some standardized protocols and

interfaces so all the vehicles can be connected. V2X can enhance road safety and traffic

efficiency by collecting and providing information to all the participants in the traffic.

For example the road users can send the real time information to the traffic operator

who can use the data to give better control of traffic by sending route information to

other road users so they can make better decisions.

Figure 1.2: An example of V2X scenario[1]

1.2 Research Problem

Wireless technology plays import role in V2X. There are twp main stream standards used

in V2X network: Long-Term Evolution (LTE)[7] and IEEE 802.11P[8]. LTE is the latest

wireless communication technology, can provide peak speeds of downlink at 100Mbps

and uplink at 50Mbps(average user throughput at 5-12Mbps downlink/2-5 Mbps uplink)

permitting latency less than 5ms for small IP packets from User Equipment(UE) to

Radio Access Network(RAN) edge. LTE channel offers four times more bandwidth than

Initials 3

3G system from channel sizes down to 5MHz in increments of 1.5MHz[9]. Another

import feature of LTE is spectrum efficieny is improved which allows more data can be

transmitted in a given bandwidth[10]. IEEE 802.11p is a specific wifi standard using

5.9GHz frequency band. Compare to LTE it can provide direct communication with

very small latency for direct communication among nodes but lack of spatial coverage.

Consider the high data rates, capability and reliability LTE naturally becomes a better

choice for vehicular communication. Another advantage of LTE is the network infras-

tructure. LTE base stations(eNodeB) normally are located in much higher places, this

is helpful for our case by avoiding multi-path loss caused by vertical obstacles.

Every coin has two sides, on the other hand LTE network is suffering highly loaded

background traffic which may lead to some delay sensitive communications miss their

deadlines. Vehicle teleoperation requires a very responsive network between the control

room and the vehicle, the latency shall be in the range of tens of milliseconds to make

sure safety. Furthermore, the video streaming service from the camera in the vehicle

also put a high quality-of-service requirement[11]. LTE lacks of scheduling mechanism in

MAC layer for the QoS Class Identifier(QCI). Detailed descripition about LTE protocol

can be found in my co-worker Y.Jin’s thesis[12].

Before deploying system to the real world, simulation is essential so potential errors

to the system can be detected before implementation thus the system is predictable

and reliable. Only simulating the communication network is not complete to evaluate

the quality, attention to the dynamic vehicle mobility pattern needs to be paid such

as topology of road network and/or the speed change due to specific constrains. Our

research problem focuses on developing a real-time simulation testbed using LTE cellular

network and a microscopic urban mobility model, to evaluate the realization of different

QoS requirements during the teleoperation.

1.3 Thesis Objectives

In a recent publication[11], the authors evaluate the feasibility of vehicle teleoperation

using cellular network in an urban environment but it could not deal with network

changes based on the traffic information. Compare to their setup our improvement

will be including a unique microscopic traffic mobility model in order to simulate a

realistic traffic pattern so the result will be more accurate. The vehicle mobility will

be a combination of a deterministic model based on the city daily routine and a simple

stochastic model to cover the randomness. The traffic and network module will be

integrated together to evaluate the feasibility, performance and capacity. The whole

Initials 4

project is done by two master students one focus on the Network Simulator for full-layer

LTE and the other focus on the traffic simulator for microscopic mobility scenario. This

thesis is focused on the latter. The objectives of the thesis are the following:

• Do a state-of-art research and evaluate different traffic simulators to determine the

suitability in the simulation framework.

• Build a microscopic realistic traffic scenario of a given urban area. Our choice is

Kista, Stockholm.

• Integrate the developed traffic scenario with the LTE network scenario. The traffic

scenario will generate nodes following certain mobility models which are defined

by the real rode map topology, traffic parameters such as speed limit, lane changes

and vehicle density and so on. The integrated traffic and network simulator should

be in an closed feedback loop: Network simulator calculate the network using the

data(position, routes, speed, etc) provided from mobility model in traffic simulator,

the network simulator could give feedback to traffic simulator to change the vehicle

routes.

• Evaluate the network requirements for teleoperated vehicles in our integrated

testbed.

• Evaluate the performance of our integrated testbed for teleoperated vehicles.

• Evaluate the capacity of our integrated testbed for teleoperated vehicles.

Figure 1.3: Illustration of Simulation Framework

Chapter 2

Background

2.1 Traffic Modelling

Mobility model is a set of rules that regulate how the nodes(participants in the traffic)

will be generated and their moving pattern. Using a simple random generated mobility

model is a common practise for V2X research community in earlier years but obviously

such models is not accurate enough because they are ironing many microscopic traffic

factors such as car acceleration/braking, queuing in the intersection, which could affect

network performance greatly. The mobility model should be as realistic as possible to

describe the behavior of the traffic flow to make sure the network evaluation is accurate.

2.1.1 State of Art of Mobility Model

Mobility models are normally divided into either microscopic or macroscopic sometimes

mesoscopic perspectives. Macroscopic models focus on traffic flows and road topology

including constraints could affect the traffic movement such as traffic lights signals. It’s

mainly used by traffic engineers for traffic planning or road topology design. There are

also some research articles about mobility patterns in wireless cellular network[13][14] on

macroscopic scope. Mesoscopic model study the elements in small groups and another

microscopic model with focus on behaviour of individual member of traffic such as their

position , acceleration/deceleration, lane changing and so on. Since we want to build

a realistic scenario and study the communication performance, a microscopic mobility

model will be needed and suitable.

Jerome Harri et al[15] defined that ”a realistic mobility model should include : Accurate

and realistic topological maps;smooth deceleration and acceleration;obstacles; attraction

5

Initials 6

Figure 2.1: Level of mobility model[2]

points;simulation time;non-random distribution of vehicles and intelligent driving pat-

terns”. All these criteria seems relevant to our scenario and will be considered during

the implementation.

The approach to build mobility model varies. Synthetic model is the first and major

model that was used in the early studies. Researchers use mathematical models such as

stochastic models contain purely random motions, traffic stream models which vehicular

mobility as hydrodynamic phenomenon, car following modes that each driver is modeled

based on the vehicles ahead and furthermore queue models, behavior models, etc.[16].

But in reality the behaviour of the human drivers are not always following a single

pattern so a model is only meaningful for a specific behaviour study. Another approach

trace-based model is instead of using complex mathematics models and validating them,

but extracting generic mobility patter from movement traces. An interesting example

would be the mobility model from Tuduce and Gross[17]. They use real wireless LAN

data at ETH Zurich in Switzerland. They divide the area into squares and derive

the transition probabilities of adjacent squares by data from access points and their

analysis shows that ”the WLAN modes maps the real world mobility characteristics to

the abstract world of network simulators with a very small error”[18]. A major drawback

of this model is the data type. For example the motion trace observed for campus can

not be applied to streets so application is limited.

Initials 7

Figure 2.2: General concept map of mobility model generation[3]

We need to consider several microscopic criteria to set up the rules regarding how the cars

following other vehicles, how they overtaking and how they behave in the intersections.

They are all important for generate realistic scenario and have several widely used models

available. For example Krauss Model[19] for car following and Gipps Model[20] for Lane

Changing. After years of development, advanced traffic simulators start to be used such

as The Simulation of Urban MObility(SUMO) [21] and VISSIM(Verkehr In Stadten

SIMulationsmodell)[22] and they can be used to simulate urban mobility in microscopic

scope which is exactly what we need.

2.1.2 Comparison of Traffic Simulator

There are several traffic simulators available today to model vehicular mobility at macro-

scopic or/and microscopic level and each of them has advantages and disadvantages. The

most suitable one need to fulfill several simulator related criteria such as capability for

map formats, algorithms for intersection and routing, visualization for output etc. We

do not have hard requirements for all these criteria but some pre-defined criteria must

be focused for the selection. The traffic simulator for our project should be open-source,

support at least microscopic type, can handle multiple vehicles, has resource cheap GUI,

also suitable for integration with a network simulator.

The CitySim [23] simulator could simulate stochastic queue-based traffic flow in urban

area for city planning purpose with a 3D graphical user interface. It could be used

by authority to simulate comprehensive urban system to evaluate the traffic volumes,

emissions, atmospheric dispersion and noise within cities. It is open-source but it is not

a mainstream traffic simulator so there is not a big community behind it for us to seek

support and it’s not designed for integration with a network simulator.

The CARISMA [24] traffic simulator supports both microscopic and macroscopic models

and has an interesting feature which is support for real-time V2V communication. It

Initials 8

could exchange and synchronize data with a network simulator continuously using a TCP

connection. The limitation is the lane connection management in complex junction and

we have to pay to use the program.

The CANU Mobility Simulation Environment(CanuMobiSim) [25], is a flexible frame-

work for user mobility modeling in a variety of conditions. CanuMobiSim supports

maps in the Geographical Data Files (GDF) format and provides implementations of

several random mobility models. It features at both macroscopic and microscopic levels.

CanuMobiSim has an extension VANETMOBISIM. At macroscopic level, VanetMobiSim

support for multi-lane roads, separate directional flows, differentiated speed constraints

and traffic signs at intersections. At microscopic level, VanetMobiSim provides realistic

V2V and V2I interactions such as Fluid Traffic Model[26]. Moreover it can generate

trace files for network simulator but it’s not possible to control on-going simulation.

SUMO is an open source, highly portable, microscopic road traffic simulation package

designed to handle large road networks, developed by German Aerospace Center(DLR).

SUMO uses Krauss’s car following model [27] and Krajzewicz’s lane-changing model[28],

includes a stochastic traffic assignment by a probabilistic route choice. It can import

road map for large area in many digital formats for example OSM. We could configure

the routes by shortest-path or weighted-path. In microscopic view the detailed behavior

of every individual vehicle such as decreasing velocity before entering into junction could

have impact to the network performance. The road geometry we modelled is Kista center

area with higher complexity however SUMO is capable to simulate the realistic lane-

to-lane movement. Another import factor is that SUMO contains a parser to generate

traces file could be read by a network simulator and we can also control the vehicle during

the simulation in real-time. Accordingly, we can run network and traffic simulator

simultaneously and send instructions from networks simulator to SUMO using some

middle-ware. SUMO also have a efficient 2D GUI so we can present the result. However

there is one limitation when considering the integration with the network simulation:

The map in SUMO is in two-dimensional therefore it doesn’t take heights of the radio

obstacles into account. Luckily in the network simulator selected in this project we

could implement a fading model and calculate the realistic propagation path loss with

consideration of obstacles’ heights. SUMO is used by many research institutions so we

can have necessary supports from them. Consider all the criteria required we conclude

that SUMO is the best option for our simulation framework.

Initials 9

Table 2.1: Features of Main Stream Traffic Simulators-1

Open Source Microscopic Marcoscopic Map Captiable Multi Lane

VanetMobisim yes yes yes high yes

VISSIM[29] no yes yes high yes

TRANSIMS no yes yes high yes

BonnMotion[30] yes no yes high yes

SUMO yes yes yes high yes

CARISMA unknown yes yes high yes

MobiREAL[24] yes no yes high yes

CitySim yes no yes high yes

PARAMICS[31] no yes yes high yes

Table 2.2: Features of Main Stream Traffic Simulators-2

Source/Destination Position Path Computation NS support

VanetMobisim random, attraction Point density/Dijkstra/speed yes

VISSIM unknown unknown yes(cpp API)

TRANSIMS random random no

BonnMotion random, attraction point density/Dijkstra/A*[32]/user define no

SUMO random, attraction point density/Dijkstra/ yes(TraCI[33])

CARISMA random density/Dijkstra/A*/user define yes

MobiREAL random, attraction point random no

CitySim unknown unknown no

PARAMICS unknown unkown no

Table 2.3: Features of Main Stream Traffic Simulators-3

GUI Radio Obstacles Plattform

VanetMobisim yes yes java

VISSIM yes unknown c++

TRANSIMS yes random unknown

BonnMotion yes yes java

SUMO yes yes c++

CARISMA yes yes c++

MobiREAL yes no c++

CitySim yes unknown c++

PARAMICS yes unknown unknown

Initials 10

2.2 Vehicles Routing Algorithms

Routes planning is always an important factor for traffic planning and optimization. How

to reach destination from source point varies in traffic dynamics(road congestion/inci-

dents can happen) and the decision will affect simulation significantly. There are several

routing algorithm existing for example Genetic Algorithms[34], Tabu search[35], A* al-

gorithm and so on. The general process of how we implement dynamic traffic route

routing is as following:

Algorithm 1 Dynamic Traffic Routing

Input: input parameters Start Position, End Position, weight: travel time/speific

routes

Output: Routes to destination

Calculate the initial route according from origin to destination using chosen routing

algorithm.

for each intersection do

if destination reached then

Trip finished

else

Check traffic condition

if Incident happen and will affect the further path then

Remove the old routing table and re-calculate the new routes

else

Follow the existing routing table

return Routes to destination

2.2.1 Heuristics in Routing: A* algorithm

We use heuristics path finding to calculate the shortest path. We did the calculation

iterativly until converges to an equilibrium state. The key to calculate the path is the

equation below:

f (n) = g (n) + h (n) (2.1)

where g(n) is is the total distance and h(n) is the heuristic distance to the destination

node, n is the starting point. When we start the search, we check the nodes adjacent to

n and expand around until reach the destination. From n we create an open list, in the

beginning we only have one node in the list which is n itself, later more nodes will be

added, some nodes is in the path we are looking for, some are not and will be checked

later. The nodes around n will be checked first and the reachable ones will be added to

Initials 11

the open list and n will become their parent node. Then n will be removed from the

open list to the close list. Next step we need to chose one node from the open list, the

one with smallest f(n) value will be chosen and then go through the same process until

the destination is reached. However we can not guarantee this will always give us the

shortest path as it use heuristics to sort the queue in the open list. Normally there are

three heuristics to apply depending on the moving rules:

• Manhattan Distance

h (n) = abs (cur n.x− dest node.x) + abs (cur n.y − dest node.y) (2.2)

This is based on the street geography of Manhattan in New York City. We use

this when that allows 4 directions of movement.

• Diagonal Distance

h (n) = max {abs (cur n.x− dest.node) + abs (current n.y − dest.n)} (2.3)

We use this when that allows 8 directions of movement.

• Euclidean Distance

h (n) = sqrt (abs (cur node.x− goal.x) + abs (cur node.y − dest.y)) (2.4)

We use this when that allows any direction of movement.

Figure 2.3: Example of Manhattan, Diagonal and Euclidean distance

Furthermore we can give weights attributes during routing. A normal choice is use travel

time on each path the vehicle went through.

Initials 12

The algorithm we followed is called A* algorithm and is one of the best and popular

algorithm used in path-finding problems. If we do not use heuristic in path finding and

consider h always zero then this algorithm is also called Dijkstra algorithm[36]. SUMO

support real time interaction with the vehicle routes during the simulation through

TRACI interface and we implemented A* algorithm for path finding. The simulation

result shows it’s possible to change vehicle routes in real-time and that improved traffic

efficiency.

Chapter 3

Implementation

Now we have discussed and chose SUMO as the traffic simulator to build our microscopic

scenario for our testbed. In order to solve our research problems there are certain

requirements need to be fulfilled: First it need to describe an city area including different

road categories but not exceed the coverage of one LTE eNodeB. Second it need to

support complex mobility modelling to represent traffic-follow in urban area. Third

it should guarantee reality in microscopic level. Fourth it should be compatible with

another network simulator for integration. Also the scenario should have the capability

to re-use in some other user cases by the other research community.

3.1 Build Kista Scenario

3.1.1 Topology

The topology of Kista is a typical city urban area: a town center area surrounded by

several neighbourhoods which are divided in different functionalists (Residential/Com-

mercial/Occupation). In SUMO the road network is modeled using XML files. They

can be written by hand, define map primitives such as nodes and edges and then con-

nect them together, or the data can be imported from some other sources like Open-

StreetMap(OSM) directly. OSM is a free user-edit project that provided map over the

whole world. ”OpenStreetMap creates and provides free geographic data such as street

maps to anyone who wants them. The project was started because most maps you think

of as free actually have legal or technical restrictions on their use, holding back people

from using them in creative, productive, or unexpected ways.”[37]. We choose OSM not

only because it can provide road information but OSM also gathers information such as

building shapes, parking-lot,bus stops and many other Point of Interests(POI). These

13

Initials 14

information will be needed for generating traffic base on people’s daily activities. Lo-

cations and the geometries of some POIs can be used as obstacles in wireless signal

prorogation which is crucial concerning to our research problem.

Figure 3.1: Select large area from OSM

The map we downloaded from OSM contains more information than we need. So we

must manually select what we are interested in such as bus stops and work place locations

which can affect the traffic. We do this by using an open source OSM map editor Java

OpenStreetMap(JOSM)[38]. It allows to load and edit OSM data such as nodes, ways

as well as their relations and metadata tags.

Figure 3.2: JOSM view of Kista OSM file

From Figure 3.2 we can see that the original OSM file directly downloaded contains too

many nodes which made the map even difficult for us to observe. It is necessary to clean

up the redundant objects. JOSM[38] provides a command line tool osmfilter for that

propurse. We can filter out objects with specific tags using command for example:

./ osmfilter a.o5m --drop -tags=" oneway= name=" -o=plain_ways.o5m

Initials 15

Figure 3.3: After Filtering Out Irrel-evant Nodes

Figure 3.4: After Filtering Out Irrel-evant Nodes and Buildings

Now the map in JOSM is clear for us to work. The topology data is actually sufficient

for SUMO to run the simulation but the correctness and robustness is not guaranteed

so we need to manually check the following to enhance the map:

• All the streets have tag ”highway” which will be used by SUMO to set the speed

limit and the right of the lane.

• One-way roads are correctly defined.

• Number of lanes and connections in the intersections.

• Warnings from Netconvert for a smoonth simulation for example adjust the angle

of the roads.

It’s an iterative process between JOSM and NetEdit to go through all the steps men-

tationed above. Now after that the road map is good enough for SUMO to run the

simulation without any significant errors that can affect the traffic flows.

Figure 3.5: Kista Scenario Road Network

The figure above shows the road map of Kista Scenario covers about 2.13 km2 in urban

area. SUMO has its own network format for the map (.net.xml) so we need to convert

OSM file into SUMO network file to make SUMO recognize the map.Table 3.1 shows a

brief summary of the selected map topology.

Initials 16

Table 3.1: Topology Information

Total number of nodes 1190

Total number of edges 1123

Total edge length [km] 103.11

Total lane length [km] 122.99

The geometrical objects have been kept tract in the previous steps now we need to

implement them into our map as colored polygons in order for us to use and easier to

see through SUMO-GUI.

A vaild polygon in SUMO is described like this:

<poly id="<POLYGON_ID >" \\

type="<TYPENAME >" \\

color="<COLOR >" \\

fill="<FILL_OPTION >" \\

layer="<LAYER_NO >" \\

shape="<2D-POSITION >[ <2D-POSITION >]*"/ >

We use POLYCONVERT to convert the buildings and parking-lots from OSM file to

SUMO polygon file(.poly.xml). The polygons are stored as an upper layer compared to

the network file.

Table 3.2: Number of Polygons in the Kista Scenario

Buildings 242

Parking 22

Total 264

Figure 3.6: Kista Scenario Topology with Polygons

Initials 17

Figure 3.7: Kista Fading Map

Figure 3.2 summariz the general process to generate a SUMO map file.

Figure 3.8: Overview of steps to generate SUMO map file[4]

3.1.2 Mobility

Now we have built the network and could load it into SUMO but there will be no vehicle

running. In order to have a realistic microscopic traffic scenario the ACTIVITYGEN

tool[39] is used. It generate the traffic demand based on a population description. It

takes into account activities such as work, school and free-time. Transportation tool

can be feet, bus and cars. To be noticed that there are some traffic not covered by

Activitygen such as tourist from outside so we add 20% random traffic following uniform

distribution.

We use data published in the Internet by Swedish authority organization Stockholm

Kommun[40] and Tranfik Analys[33]. Number of vehicles running in the area selected

is estimated to approximately between 200,000 and 300,000 per day based on the pop-

ulation. 38 bus stops are added to the map as well as 11 bus routes. We extract the

location of bus stops and bus routes in OSM map. There is no tool available now to

automatly convert them into SUMO formate so we have to add them manually.

Initials 18

Figure 3.9: Bus Stop Location in Kista Scenario

Figure 3.10: Example Bus Route No.178 from OSM

Table 3.3: Summary of Bus in the Kista Scenario

Total Number of Bus Lines 11

Total Number of Bus Stops 38

Total Number of Buses 594

ACTIVITYGEN will generate staring and destination edges then we use duaRouter[41]

to complete all the edges in between. Moreover , we use a dynamic routing mechanism

for the vehicles to avoid road congestion. That means a vehicle will re-route using

Dijkstra algorithm every 5 minutes. When SUMO simulation is over we could see from

the summary that the dynamic routing mechanism can provide a smooth traffic flow.

3.2 Integration

Now the Kista mobility scenario is ready for the simulation and can be used together

with a network simulator such as NS3 or OMNet++ so we can evaluate the network per-

formance. There are two types of integration: The traditional way to do the integration

Initials 19

is first let SUMO produce a complete trace file and then let network simulator read the

trace file however not possible to control the traffic flow, we call this type of simulation

off-line simulation. The other type is real-time/on-line simulation which allows interac-

tion between SUMO and network simulator during the simulation so the most accurate

and efficient result could be given.

3.2.1 Real-time Simulation

In our testbed SUMO provides vehicle mobility model including nodes positions, speed

and routes as well as geometry road map. NS3 provides LTE cellular network model

and signal fading model during propagation. V2X simulation need to be realistic in

microscopic level(provide accurate information) and run in real-time to be useful(for

example during simulation re-routing if traffic congestion occurs or signal is weak). If

we had a feed-back loop in a live simulation we refer that as the real-time simulation.

The interface in SUMO for external communication TraCI(Traffic Control Interface)

is included in SUMO package. It gives access and pass the data between SUMO and

external applications. We can retrieve the current values of all objects in the simulation

such as vehicles or traffic light, also we can change the state of these objects on-line.

One example user case could be when we want to simulate a bus broke-down half way,

we could change the bus destination back to the bus depot during the simulation. TraCI

uses TCP connection with SUMO where SUMO acts as the server and listing to the

remote port for the coming connections. The figure below describes a basic flow of

establishing a connection to SUMO.

Figure 3.11: Establishing a connection to SUMO[5]

Initials 20

When the client connects to SUMO by a TCP connection through the configured port

it takes control of SUMO. The client needs to send commands to SUMO in every simu-

lation step and the objects in SUMO can be changed according to the instruction sent

from client. SUMO will also send corresponding acknowledge message as well as some

additional result back to the client.

Figure 3.12: Closing a connection to SUMO[5]

The connection can only be shut down by the client by sending a close command.

In order to have on-line interaction between SUMO and NS3 we need to use some middle-

ware for example The V2X Simulation Runtime Infrastructure (VSimRTI) [6]. IEEE

Standard for Modeling and Simulation(MS) High Level Architecture[42] describes stan-

dardized approach to combine simulators. The idea is to have a central management

component to receive, process and send data between different connecting simulators.

We need a such central infrastructure to manage the arbitrary simulators through some

interfaces. There are several projects can provide such kind of service[43]. VisimRTI

uses the concept of ambassador, inspired from HLA, together with each participating

simulators as a federate to build a Federation. Figure 3.13 illustrate the general VSim-

RTI architecture. Simulation run time infrastructure(RTI) is the essential part uses

ambassadors to communicate between SUMO and NS3. The communication is bidirec-

tional. Except interaction run time infrastructure also provides service for simulator

synchronization by a time management service. In RTI three modules are included:

Federation, time and interaction management. To attach a simulator federate we only

need to configure the federate ambassador interface to RTI. Even though each simulator

is independent but during the simulation all the events has time stamp regardless local

or remote. The reason is for synchronization. It enables the substitution of the most

relevant simulators for a realistic presentation of vehicle traffic, wireless communication

and the execution of V2X application. VsimRTI couples different simulators scenarios

Initials 21

and synchronizes them. Also several visualization and analysis tools are prepared for

VSimRTI.

Figure 3.13: VSimRTI architecture[6]

Yet another middle-ware framework project available is Online Vehicular Network Inte-

grated Simulation(OVNIS)[44] platform. It can couple together SUMO and NS3 so the

SUMO scenario is embedded in the mobility model of NS3. Accordingly corresponding

NS3 module could influence the traffic simulation such as reroute of the vehicles in the

mobility model. OVANIS achieved this by using TraCI interfce to create a sub-module

in NS3.

However when we try to implement the integration, we found that both OVNIS and

VSimRTI have only implemented 802.11p protocol stack not support LTE and they do

not consider fading pattern in the urban area neither for the simulation which violated

our research problem.

Figure 3.14: Illustration of real-time simulation work flow between SUMO and NS3

Initials 22

3.2.2 Off-line Simulation

Traffic simulators and network simulators are designed separately so they should be

controlled separately and can not be used directly together. Most network simulators

are able to generate random movements themselves but now it is possible to load mobility

scenario from traffic simulators so the vehicular network evaluation can be more accurate.

Figure 3.15: Illustration of off-time simulation work flow between SUMO and NS2[2]

For example CanuMobiSim[45] is a generic user mobility simulator which can provide

mobility scenarios in different infrastructure. The simulation need to run prior to the

network simulation and need to be parsed to a pre-defined trace format. During the

network simulation no changes to the mobility is allowed. A recent article (2015) by

Vladi.k, Tetsuya Oda and some other authors did a performance evaluation using a

simulation structure described above with SUMO and NS3. SUMO generates the move-

ment pattern of the vehicles which used by NS3 to analysis the performance of different

routing protocols[46].

Chapter 4

Evaluation

For evaluation of the integrated scenario, we focus on three aspects: Feasibility, Capacity

and Performance. When doing feasibility test, we calculate the delay of data flows with

different priority in one fixed route. In order to find the maximum number of busses our

scenario can handle we did capacity test. We sum up the simulation results from SUMO

and analyze. The performance of LTE network can be found in Y.Jin’s publication[12].

4.1 Simulation Summary of SUMO

A moving vehicle will be sent to teleport if some issues such as congestion occur that

stop the vehicle continue to the destination. In the end of simulation we could trace

the simulation detail though log files. Higher percentage of teleports indicate that the

traffic flow can not be moving smoothly. In our scenario it’s only around 3% so the

unexpected issues in the traffic scenario will not have significant influence to the network

performance. We achieve this by a dynamic re-routing mechanism. If a traffic congestion

occurs the vehicles will be automatically re-routed to avoid the congestion situation. This

is not always true in reality so we only configured 70% vehicles with re-routing set-up

and the rest 30% will stick to their routes no matter the traffic condition. We assume

this will not affect the realism of the scenario.

Table 4.1: SUMO Simulation Summary

Total simlation time [s] 86494

Number of vehicles loaded 25038

Teleports 921

23

Initials 24

To verify that the Kista Scenario can behave in a realistic way we use an external tool:

Typical Traffic from Google Maps[47].

Figure 4.1: Traffic Condition in Google Maps at 8:00 am

The green and red color represent the speed of the vehicle driving on that road from

normal speed to low speed. We compare the running simulation and the snapshots from

the typical traffic and the traffic condition is consistent so we can assume that the reality

of Kista scenario can be guaranteed.

4.2 Feasibility

The network requirements we have for teloperation are constant latency less than 50ms,

constant jitter, more than 99% connectivity guarantee with throughput reached GBR.

Figure 4.2: Delay for Critical Stream in 10M Background Traffic

Initials 25

We set priorities to different data flow types. Traffic Command flow has higher priority

than video flow so the traffic command flow(start from 10s) will affect the video trans-

mission. We could observe from figure 4.1 the video flow delay have more fluctuating

which is due to command packet, as well as channel fading and codes performance. But

it still can guarantee a delay less than 50ms and relatively small jitter. We send some

other dummy packets with lowest priority (start from 0.01s) and it has no affect for the

transmission of video flow. CQI also can cause fluctuation in delay as the time passing

by.

Figure 4.3: Packet Loss Ratio for Critical stream in 10M and 1M Background Traffic

It is important that traffic command should be always received by the vehicles in tel-

operation. So we need to make sure the command flow will never lose connectivity.

Observing figure 4.2 we could No matter how we change the background traffic through-

put, the video flow which have higher priority is not affected, only dummy background

traffic lost more packet itself. This is guaranteed by assigning GBR-bearer to the flow

with higher priority and NGBR-bearer to the flow with lower priority. NGBR-bearer

will only be served until GBR-bearer is fully served.

From perspective of the mobility, we have transmitting antenna located at (880,4100)

and moving vehicle has the route from (188,35,4454,56) to (968.36, 4094,65). The vehicle

will be closer to the antenna when approaching destination, which will result in more

guaranteed connectivity, optimized CQI and decreased PLR.

Figure 4.4: Geometry location of antenna and vehicle route

Initials 26

Figure 4.5: Packet Loss Ratio for non-Critical stream in 10M and 1M Back-groundTraffic

Since this is the feasibility test so we only simulated one bus route.

4.3 Capacity

The capacity of the scenario, which is maximum number of busses that the testbed can

handle without violate network requirements is another parameter we need to investi-

gate. We have one eNB in the network scenario and test different number of busses in

traffic scenario.

Figure 4.6: Capacity for Bus Router per eNB

We simulate up to nine buses in nine realistic bus routes in Kista area. ”Always Yes”

admission control strategy is implemented which means all UEs we put in the system

will be subscribed and served. After some test simulation runs we conclude that if we

have more than six busses the entire network will be ruined. Which packets will be drop

is defined by CQA scheduler mechanism. If we have several data flows with the same

pre-defined priority, the one with better CQI and shorter Head-of-line(HOL) delay[48]

will be given higher priority. So the system capacity will be decided by the UEs with

worst HOL.

Chapter 5

Conclusion and Future Work

As we stated the research problems in the beginning of the thesis: simulate and evaluate

the teleoperation of the vehicles using LTE cellular network. We set several objectives to

achieve that in a proper scientific research manner: The first is to do a state-of-art study

and choose the appropriate simulators. To achieve that we conduct a comparison based

on the study of exist research results and choose SUMO to build our traffic scenario.

The second object is to build the traffic scenario for Kista. The scenario we build has

following characters: It is built on real geographical topoogy and included different

areas such as residential and work place, city road and high way. It supports different

mobility modellings (both stochastic and deterministic). The whole scenario simulates

24 hours traffic movements. It is compatible with other traffic simulator for integration.

We emphasize the importance of the mobility modeling in wireless networking. Not

only the movements in geographical map is considered but also we take case as well the

importance of simulation accuracy by generating the movements under daily activities

distribution based on real statistic data. The presented scenario is repeatable that can

be easily applied to other user case for example in another city urban area, or to evaluate

with other wireless network protocol like IEEE 802.11p. Next object is to integrate the

traffic scenario together with network scenario build by my co-worker Yifei JIn. This is

the weakness of the project. We didn’t succeed in implementing the real-time simulation

due to the only suitable integration framework VSimRTI is not open-source and it has

not implemented complete LTE protocol stack so we can not configure and extend that

for our integrated scenario. To implement a new integration frame work would be beyond

the scope of this thesis project so we are forced to simulate the integrated scenario off-

line. However we make use of the emulation features from NS3 to extend the network

topology to remote host and elevate this to have user access network topology in remote

end. A good compensation we could do is to run the simulation many times in small

time scale so we have results very similar to real-time simulation behavior.

27

Initials 28

So far we have discussed the process of building a V2X simulation testbed framework

which is integrated by an accurate LTE network scenario and a realistic microscopic

traffic scenario. The simulation results show that it’s feasible by using LTE network

infrastructure to teleoperate up tp 5 vehicles per eNB with guaranteed QoS in Kista.

However, as mentioned above we have many assumptions, uncertainties and even weak-

nesses.

Future work will focus on developing the real-time simulation testbed and use it to

evaluate more scenarios, in which we could even develop an external control software

to send control command from internet to the LTE network. And we could extend

the scenario and consider some further user cases for example to develop a machine

intelligence traffic control system.

Bibliography

[1] Roberto Baldessari, Bert Bodekker, Matthias Deegener, Andreas Festag, Walter

Franz, C Christopher Kellum, Timo Kosch, Andras Kovacs, Massimiliano Lenardi,

Cornelius Menig, et al. Car-2-car communication consortium-manifesto. 2007.

[2] Matthias Rockl. itetris: The integrated wireless and traffic platform for real-time

road traffic management solutions. 2009.

[3] Marco Fiore, Fethi Filali, and Christian Bonnet. Vehicular mobility simulation with

vanetmobisim. Simulation, 87(4):275–300, 2011.

[4] http://sumo.dlr.de/wiki/Tutorials/Import_from_OpenStreetMap. Accessed:

2017-05-29.

[5] http://sumo.dlr.de/wiki/TraCI/Protocol. Accessed: 2017-05-29.

[6] https://www.dcaiti.tu-berlin.de/research/simulation/. Accessed: 2017-

05-29.

[7] Lte An Introduction. Lte – an introduction. 2014.

[8] Diego Llusia, Rafael Marquez, Juan Francisco Beltran, Catarina Moreira, and Jose

Pedro Do Amaral. Ieee 802.11p: Towards an international standard for wireless

access in vehicular environments. In Vehicular Technology Conference, 2008. Vtc

Spring, pages 2036–2040, 2008.

[9] Amit Kumar, Jyotsna Sengupta, and Yun Fei Liu. 3GPP LTE: The Future of

Mobile Broadband. Kluwer Academic Publishers, 2012.

[10] David Astely, Erik Dahlman, Anders Furuskar, Ylva Jading, Magnus Lindstrom,

and Stefan Parkvall. Lte: the evolution of mobile broadband. IEEE Communica-

tions magazine, 47(4), 2009.

[11] Rafia Inam, Nicolas Schrammar, Keven Wang, Athanasios Karapantelakis, Leonid

Mokrushin, Aneta Vulgarakis Feljan, and Elena Fersman. Feasibility assessment to

realise vehicle teleoperation using cellular networks. In Intelligent Transportation

29

Bibliography 30

Systems (ITSC), 2016 IEEE 19th International Conference on, pages 2254–2260.

IEEE, 2016.

[12] year=In progress Yifei Jin. Master thesis: Cellular network overlay evaluation for

vehicular teleoperation in an urban scenario.

[13] Derek Lam, Donald C Cox, and Jennifer Widom. Teletraffic modeling for personal

communications services. IEEE communications magazine, 35(2):79–87, 1997.

[14] John G Markoulidakis, George L Lyberopoulos, Dimitrios F Tsirkas, and Efs-

tathios D Sykas. Mobility modeling in third-generation mobile telecommunications

systems. IEEE personal communications, 4(4):41–56, 1997.

[15] Jerome Harri, Fethi Filali, and Christian Bonnet. Mobility models for vehicular ad

hoc networks: a survey and taxonomy. IEEE Communications Surveys & Tutorials,

11(4), 2009.

[16] Marco Fiore et al. Mobility models in inter-vehicle communications literature.

Politecnico di Torino, page 147, 2006.

[17] Cristian Tuduce and Thomas Gross. A mobility model based on wlan traces and

its validation. In INFOCOM 2005. 24th Annual Joint Conference of the IEEE

Computer and Communications Societies. Proceedings IEEE, volume 1, pages 664–

674. IEEE, 2005.

[18] Cristian Tuduce and Thomas Gross. A mobility model based on wlan traces and

its validation. In INFOCOM 2005. 24th Annual Joint Conference of the IEEE

Computer and Communications Societies. Proceedings IEEE, volume 1, pages 664–

674. IEEE, 2005.

[19] Venkatesan Kanagaraj, Gowri Asaithambi, C H Naveen Kumar, Karthik K Srini-

vasan, and R. Sivanandan. Evaluation of different vehicle following models under

mixed traffic conditions. In Conference of Transportation Research Group of India,

pages 390–401, 2013.

[20] Ioanna Spyropoulou. Simulation using gipps’ car-following model—an in-depth

analysis. Transportmetrica, 3(3):231–245, 2007.

[21] http://sumo.dlr.de/wiki/Simulation_of_Urban_MObility_-_Wiki. Accessed:

2017-05-29.

[22] http://vision-traffic.ptvgroup.com/en-uk/products/ptv-vissim/. Ac-

cessed: 2017-05-29.

Bibliography 31

[23] Darren Robinson, Frederic Haldi, Philippe Leroux, Diane Perez, Adil Rasheed,

and Urs Wilke. Citysim: Comprehensive micro-simulation of resource flows for

sustainable urban planning. In Building Simulation 2009: Eleventh International

IBPSA Conference, 2009.

[24] Stephan Eichler, Benedikt Ostermaier, Christoph Schroth, and Timo Kosch. Sim-

ulation of car-to-car messaging: Analyzing the impact on road traffic. In IEEE

International Symposium on Modeling, Analysis, and Simulation of Computer and

Telecommunication Systems, pages 507–510, 2005.

[25] http://vanet.eurecom.fr/. Accessed: 2017-05-29.

[26] Gabriella Bretti, Roberto Natalini, and Benedetto Piccoli. A fluid-dynamic traf-

fic model on road networks. Archives of Computational Methods in Engineering,

14(2):139–172, 2007.

[27] S. Krauss, P. Wagner, and C. Gawron. Metastable states in a microscopic model

of traffic flow. Phys.rev.e, 5(1997):5597–5602, 1997.

[28] Daniel Krajzewicz. Kombination von taktischen und strategischen einflussen in

einer mikroskopischen verkehrsflusssimulation. Fahrermodellierung in Wissenschaft

Und Wirtschaft Berliner Fachtagung Fur Fahrermodellierung, pages 104–115, 2009.

[29] http://vision-traffic.ptvgroup.com/en-us/products/ptv-vissim/. Ac-

cessed: 2017-10-09.

[30] http://sys.cs.uos.de/bonnmotion/. Accessed: 2017-10-09.

[31] http://www.sias.com/2013/sp/sparamicshome.htm. Accessed: 2017-10-09.

[32] Florian Diedrich, Klaus Jansen, Ulrich M Schwarz, and Denis Trystram. A sur-

vey on approximation algorithms for scheduling with machine unavailability. In

Algorithmics of Large Complex Networks, pages 50–64, 2013.

[33] http://www.trafa.se/. Accessed: 2017-05-29.

[34] A. E. Eiben, Paul Erik Raue, and Zsofia Ruttkay. Genetic algorithms with multi-

parent recombination. In Parallel Problem Solving from Nature - PPSN III, Interna-

tional Conference on Evolutionary Computation. The Third Conference on Parallel

Problem Solving from Nature, Jerusalem, Israel, October 9-14, 1994, Proceedings,

pages 78–87, 1994.

[35] Fred Glover. Future paths for integer programming and links to ar tifi cial intelli g

en ce. Computers Operations Research, 13(5):533–549, 1986.

Bibliography 32

[36] T. H. Cormen, C. E. Leiserson, R. L. Rivest, and C. Stein. Section 24.3: Dijkstra’s

algorithm. In Introduction To Algorithms, Second Edition, 2013.

[37] http://www.openstreetmap.org. Accessed: 2017-05-05.

[38] https://josm.openstreetmap.de/. Accessed: 2017-05-29.

[39] http://sumo.dlr.de/wiki/ACTIVITYGEN. Accessed: 2017-05-29.

[40] http://statistik.stockholm.se/omradesfakta/pdf/SDO01_SVE.pdf. Ac-

cessed: 2017-05-29.

[41] http://sumo.dlr.de/wiki/DUAROUTER. Accessed: 2017-06-09.

[42] Judith S Dahmann. High level architecture for simulation. In Distributed Interactive

Simulation and Real Time Applications, 1997., First International Workshop on,

pages 9–14. IEEE, 1997.

[43] https://www.nsnam.org/wiki/GSOC2012HLA. Accessed: 2017-05-29.

[44] https://github.com/agacia/ovnis. Accessed: 2017-05-29.

[45] http://canu.informatik.uni-stuttgart.de/mobisim/. Accessed: 2017-05-05.

[46] Vladi Kolici, Tetsuya Oda, Yuki Sugihara, Evjola Spaho, Makoto Ikeda, and

Leonard Barolli. Performance evaluation of a vanet simulation system using ns-

3 and sumo considering number of vehicles and crossroad scenario. In Innovative

Mobile and Internet Services in Ubiquitous Computing (IMIS), 2015 9th Interna-

tional Conference on, pages 22–27. IEEE, 2015.

[47] https://maps.googleblog.com/2012/04/get-typical-traffic-for-roads-not-just.

html. Accessed: 2017-09-07.

[48] M. J Karol, M. G Hluchyj, and S. P Morgan. Input versus output queueing on a

space-division packet switch. Communications IEEE Transactions on, 35(12):1347–

1356, 1987.