TraCI: An Interface for Coupling Road Traffic and Network Simulators

Axel Wegener1 , Michał Piórkowski2 , Maxim Raya2 , Horst Hellbrück1 , Stefan Fischer1 and Jean-Pierre Hubaux2
1 Institute of Telematics, University of Luebeck, Germany

{wegener, hellbrueck, fischer}@itm.uni-luebeck.de

2 LCA Lab, EPFL, Lausanne, Switzerland

{michal.piorkowski,maxim.raya,jean-pierre.hubaux}@epfl.ch

Keywords: Vehicular Ad-Hoc Networks (VANETs), Net- ditions, they will adjust their speed accordingly. In return, this
work Simulation, Node Mobility will also affect other vehicles, including those that are not part
of the VANET.
Abstract Several tools are available for network simulations: e.g.
Vehicular Ad-Hoc Networks (VANETs) enable communica- ns2 [2], JiST/SWANS [3] or Shawn [4]. But none of them
tion among vehicles as well as between vehicles and roadside qualifies as a VANET simulator (as is the case with ns2 or
infrastructures. Currently available software tools for VANET GloMoSim for ad-hoc networks), mainly because none of
research still lack the ability to asses the usability of vehic- them allows to evaluate how the networking applications in-
ular applications. In this article, we present Traffic Control fluence mobility. They are mostly concerned about assessing
Interface (TraCI) a technique for interlinking road traffic and the performance of routing, forwarding, MAC layer proto-
network simulators. It permits us to control the behavior of cols, etc. of VANETs under realistic but unmodifiable mobil-
vehicles during simulation runtime, and consequently to bet- ity scenarios. The common approach to integrate mobility is
ter understand the influence of VANET applications on traffic to either rely on stand-alone road traffic simulators, such as
patterns. SUMO [5], Vissim [6], MatSim [7], TRANSIMS [8], or to
In contrast to the existing approaches, i.e., generating mo- use collected mobility traces specific to some geographical
bility traces that are fed to a network simulator as static input region [9, 10]. Tools with such functionalities can be found
files, the online coupling allows the adaptation of drivers’ be- in [11–13].
havior during simulation runtime. This technique is not lim- We address the problem of application-centric mobility-
ited to a special traffic simulator or to a special network sim- oriented evaluation of VANETs by proposing TraCI: Traffic
ulator. We introduce a general framework for controlling the Control Interface. Specifically, we suggest an open-source
mobility which is adaptable towards other research areas. architecture that couples two simulators: a road traffic and a
We describe the basic concept, design decisions and the network simulator. In such a realistic simulation setup, mobil-
message format of this open-source architecture. Addition- ity patterns are not pre-established as fixed trace files. Instead,
ally, we provide implementations for non-commercial traffic the traffic and network simulators are connected in real time
and network simulators namely SUMO and ns2, respectively. by TraCI thus enabling the control of mobility attributes of
This coupling enables for the first time systematic evaluations each simulated vehicle. Thus, the movement of each vehicle
of VANET applications in realistic settings. can be influenced by the VANET application running inside
the network simulator. We claim that this approach will allow
to fully evaluate VANET applications in realistic scenarios.
1. INTRODUCTION
Our contribution is the new open-source architecture for
VANETs appear to be the most promising applications of
coupling traffic and network simulators that aims to achieve
mobile ad-hoc networks and will have a strong impact on road
two goals:
traffic efficiency and safety as provisioned by the Intelligent
Transportation System (ITS) community [1]. 1. To create a generic API for controlling a traffic simulator
An exhaustive evaluation of VANET applications requires so that a road traffic simulator can be coupled with a
more than a deep understanding of information generation network simulator or any other simulator that needs to
and networking aspects within VANETs. It is just as impor- control the road traffic.
tant to investigate how vehicular applications affect the move-
ment of vehicles, because as a consequence of a more exten- 2. To set a ground for a framework for implementing
sive knowledge of the surrounding traffic patterns (as reported VANET applications that can influence vehicle move-
by VANET applications) drivers will adapt their driving strat- ment during runtime [13].
egy – ranging from speed changes to route selection. This new
driver behavior might cause again a change in traffic patterns. The paper is organized as follows. In Section 2. we present
For example, if drivers are warned about hazardous road con- the related work. In Section 3. we introduce the concept of

CNS '08 155 ISBN 1-56555-318-7

mobility primitives that set the ground for mobility com-
mands used in our framework. Next, we describe the pro-
posed system architecture. We devote the Section 4. to the
data exchange protocol, which is the main ingredient of our
architecture. We present the implementation details in Sec-
tion 5. and evaluate the performance of TraCI design choices
in Section 6. Finally, in Section 7. we conclude the paper.

2. RELATED WORK
In recent years new simulation tools for VANETs have
been developed; these tools can be classified into three differ-
ent approaches. The first approach uses real maps to generate
random waypoint mobility traces [14, 15] or more realistic Figure 1. System architecture and an operation example of
traces [10]. The second approach uses integrated road traffic the command-response exchange between the network and
and network simulators, i.e., a network simulator with em- the traffic simulator presented as a timeline diagram. This
bedded realistic mobility component, such as [16–18]. The example shows an exchange of four TraCI messages, two
third approach couples a commercial traffic simulator with a commands: [SetMaxSpeed] and [SimulationStep] and two re-
network simulator [19, 20]. sponses: [Status] and [Status, MoveNode, MoveNode]. It cor-
Note that only the second and the third approach have the responds to a scenario when two vehicles exchange VANET
potential to evaluate VANETs at application-centric level un- messages and one of them decides to adjust its maximum
der realistic scenarios.However, the major shortcoming of the speed.
existing tools is that the information exchanged between ve-
hicles cannot influence their whereabouts. The only exception
in the class of integrated simulators is a framework proposed
To better understand the concept of mobility primitives,
by Wang et al. [18]. It allows for controlling vehicle move-
let us consider the Road Condition Warning application that
ments by using an intelligent driving behavior module, coded
belongs to the class of Vehicle-to-Vehicle Decentralized En-
in the agent logic that simulates the vehicle. Our solution is
vironmental Notification applications as proposed by the
more generic, because it is based on a different architecture,
Car2Car Communication Consortium (C2C-CC) [21]. A ve-
which allows us to use various road traffic as well as network
hicle that detects an incident immediately starts broadcast-
simulators. In the class of the coupled traffic and network
ing a specific warning message to nearby vehicles; this mes-
simulators there are two exceptions, [19, 20]. They achieve
sage includes the type of warning, its location and occurrence
necessary real-time coupling between two simulators, VIS-
time. Each vehicle that receives such a warning may adjust its
SIM or CARISMA (for road traffic) and ns2 (for communi-
movement accordingly. For example, while approaching the
cation). But it remains unclear what features are supported
scene, a vehicle may first slow down, then change the lane
to control the traffic simulation. Furthermore, both VISSIM
and finally speed up.
and CARISMA are commercial products that are not pub-
In order to identify all mobility primitives specific to
licly available. Our open-source system architecture allows
VANETs, we studied the set of vehicular applications pro-
researchers to couple non-licenced, as well as licensed, tools
posed by C2C-CC. In Table 1, we present a taxonomy of
that are widely used in both the ITS and VANET communi-
VANET applications, i.e., use cases and the associated mobil-
ties.
ity primitives. The complex mobility patterns of a driver can
be represented by a certain sequence of mobility primitives
3. APPROACH proposed here. We rely on these mobility primitives to spec-
3.1. Mobility Primitives ify the set of atomic mobility commands used by the network
simulator to control movements of vehicles. The detailed def-
Any complex mobility pattern, which is a result of a de-
inition of these commands is presented in Section 4.
cision taken by a driver, can be decomposed into a sequence
of mobility primitives such as ‘change speed’, ‘change lane’,
‘change route’, etc. These mobility primitives are indepen- 3.2. System Architecture
dent from VANET applications. They depend on macroscopic TraCI avoids the creation of mobility traces prior to the
(road network topology, speed limits, etc.), as well as mi- ad-hoc network simulation. Both simulators run concurrently,
croscopic (current vehicle speed, location, etc.) mobility con- whereby the ad-hoc network simulator controls the road traf-
straints. fic simulator. Therefore, we extend the road traffic simula-

ISBN 1-56555-318-7 156 CNS '08

Table 1. VANET application taxonomy proposed by the Car-to-Car Communication Consortium [21] and the resulting mobil-
ity primitives.
Mobility Primitives
Application Type Use Cases
Change speed Stop Change lane Change route Change target
Traffic Congestion Warning + + + +
V2V Cooperative Forward Collision Warning + + +
Awareness Cruise Control + +
Intersection Collision Warning + +
Pre-Crash Sensing + + +
V2V Unicast
Approaching Emergency Vehicle + + +
Exchange
Merging Assistance + + +
Road Condition Warning + + +
Low Bridge Warning +
V2V
Freezing Bridge/ Road Warning +
Decentralized
Work Zone Warning + + +
Environmental
Fog Zone Warning +
Notification
Post Crash Warning + + + +
Incident Detection + + + + +
Curve Speed Warning +
I2V
Speed Limit Warning +
Communication
Stop Light Assistance + +

tor by a TraCI-Server and the network simulator by a TraCI- However, given that the simulation time step is usualy very
Client. These two components communicate over a TCP con- short - for traffic efficiency applications approximately 1[s]
nection. The general system architecture is depicted in Fig- and for safety applications - 0.1[s], this kind of drawback is
ure 1 negligible.
Once the TCP connection is established, the network sim- When the simulation ends either in the traffic or the net-
ulator controls the traffic simulator via the data exchange work simulator, it closes the TCP connection. This causes the
protocol, which enables movement changes for each simu- other simulator to stop too.
lated vehicle. Thus, it is possible to instantaneously adjust
the movement of individual vehicles due to information gen- 4. PROTOCOL DETAILS
erated within the VANET. As described in the previous section, a TCP connection be-
Data exchange between the simulators is controlled by the tween the mobility generator and network simulator is used
network simulator that sends commands as requests to the for the exchange of data. Both the network and the road traf-
road traffic simulator. Upon reception of the commands, the fic simulator use TraCI messages (cf. Figure 2) to bundle, re-
traffic simulator performs actions that result in one or more spectively, a set of commands or responses.
responses to each command.
0 7 8 15
To ensure time synchronization between both simulators, 
Message length including
the network simulator sends periodically, every simulation Header
this header
step, e.g. 1[s], a command to the road traffic simulator that
Length

contains the actual simulation time plus one simulation step Identifier
Command0
(cf. Section 4.2.). The road traffic simulator performs the next Command0 content
simulation step and sends the resulting vehicle positions back ..
.
to the network simulator. Those vehicle positions are con- Length

Identifier
verted into linear movements by the network simulator, so Commandn−1
Commandn−1 content
that all vehicles reach their positions at a time instant as spec-
ified by the traffic simulator (cf. Section 4.4.).As a small Figure 2. TraCI message format: TraCI messages are com-
drawback of this method, the actual execution of the atomic posed of a small header and a variable number of commands.
mobility commands is delayed by one simulation step, since
the road traffic simulator is always one simulation step ahead. The TraCI message, as depicted in Figure 2, consists of a

CNS '08 157 ISBN 1-56555-318-7

small header that contains the overall message length includ- • Scenario is used for getting scenario parameters, mainly
ing the message header, followed by a variable number of at simulation setup time. These are x- and y- dimensions
commands. Each command starts with its length and identi- as well as the expected number of network nodes.
fier, coded as an unsigned byte sequence. By definition, com-
mands with identifiers ∈ [0, 127] are commands from the net- • Position Conversion converts between different types
work simulator to the mobility generator. The respective re- of positions, e.g., to map a Cartesian coordinate to an
sponses have an identifier ∈ [128, 255]. These identifiers are appropriate position on the road network.
given in the header of each command’s section. The content • Driving distance calculates the path and estimated time
of each command depends on the particular command type. to get from one position to another based on the under-
The commands and corresponding responses can be split lying road network.
into three functional groups. The first group controls the sim-
ulation run: Due to the wide range of these commands, we will wait
for users’ real needs and deliver the lacking features when
• Simulation Step is called periodically by the network required.
simulator to let the traffic simulator perform the simula- We describe the single commands and responses of the first
tion up to the next time period. In addition to a Status two groups in the following subsections, taking their seman-
response, a Move Node response for each equipped ve- tics and syntax into account. Therefore, the used data types
hicle is expected as the answer. are introduced beforehand. Due to space limits, we refer the
reader to [22] for environmental commands and their full ref-
• Status is sent as a reply to every request command. It erences.
contains a status flag and a descriptive text.

• Move Node contains a movement information for one 4.1. Data Types
vehicle. It serves as a response to the Simulation Step To save the computation time, our protocol does not use
command to transfer the mobility into the network sim- structural information within its messages as XML does. In-
ulator. stead, all messages are composed of a stream of elementary
data types. These elementary data types are byte, integer,
Commands from the second group represent the atomic float, double and string.
mobility primitives identified for the use cases in Section 3. All numeric data types are interpreted as signed, only for
They are used to affect the behavior of a single vehicle. the datatype byte exists an unsigned counterpart.
In addition, we introduce the composed data type position
• Set Maximum Speed limits vehicle’s speed or removes that is based on the aforementioned elementary data types.
such a limit (change speed primitive). We use two different types of position representations: Carte-
sian 3D positions and positions on a road map. The former
• Stop Node causes a vehicle to stop and wait for a period format is necessary, since in the vast majority of the network
of time at a certain position as soon as the vehicle gets simulators the Cartesian coordinates are used to represent
there (stop primitive). node’s position. The latter format can be used for example at
the application layer (implemented also in the network simu-
• Change Lane fixes a vehicle to a specific lane for a cer-
lator), where information about map location can be required
tain amount of time.
to perform application-specific actions. To specify which rep-
• Change Route causes the traffic simulator to reroute an resentation is used, a ubyte identifier is put in front of each
individual vehicle by setting a particular travel time for position (later on referred to as PositionType).
a road segment. 3D Position. In most cases, network simulators work with
3D coordinates to describe node positions.
• Change Target changes the destination of a vehicle.
ubyte float float float
The environmental commands that give access to the simu- 00000011 X Y Z
lation scenario form the third group. The simulation scenario
is maintained mainly by the traffic simulator, as it holds the
road map, points of interest, building footprints, traffic lights, The ubyte identifier for 3D positions is 0x03. It is fol-
public transportation and so on. Depending on the network lowed by three float variables describing the Cartesian X,
simulation’s focus, a subset of this information is required Y and Z coordinates.
within the network simulation as well. We currently support Road Map Position. To relieve the network simulator
the following set of environmental commands. from converting Cartesian coordinates to positions on a road

ISBN 1-56555-318-7 158 CNS '08

map, vehicles’ positions can be reported directly as road map It is up to the network simulator to decide if the simula-
positions. tion needs to be stopped after receiving an error or not imple-
mented status.
ubyte string float ubyte
00000100 RoadId Pos LaneId 4.4. Response Move Node (Id 0x80)
integer double position
NodeId TargetTime Position
Road map positions have an identifier of 0x04. RoadId
identifies an edge, i.e., a road segment on the road map graph;
Pos describes the node’s position in longitudinal direction in The network simulator receives Move Node responses as
the range of [0, LengthRoadId ). LaneId contains the driving replies to the command Simulation Step. Each active, i.e,
lane on the road segment. Those are numbered sequentially moving vehicle, which is identified by its nodeId, results in
starting with zero from the rightmost lane. Note that lanes in one Move Node response. These must be converted into lin-
opposite direction are identified by a different RoadId. In fu- ear movements by the network simulator to ensure that each
ture work, more representations may be added, e.g. NMEA- node reaches its Position at TargetTime. The representation
0183 standardized GPS-positions or geographic coordinates of the Position is interpreted according to the requested Posi-
using latitude and longitude. tionType of the Simulation Step command.

4.2. Command Simulation Step (Id 0x01) 4.5. Command Set Maximum Speed (Id 0x11)
integer float
double ubyte
NodeId MaxSpeed
TargetTime PositionType

This command causes the vehicle identified by NodeId to

This command is sent repetitively by the network simu- limit its speed to an individual maximum of MaxSpeed.
lator at each simulation step (e.g., every second) to retrieve The traffic simulator is responsible for slowing down the
actual node positions and to make sure that the simulation vehicle in a proper way according to its mobility model. To
times are synchronized between both simulators. It triggers remove an individual speed of a vehicle, this command is
the traffic simulator to simulate the next simulation step up to called with a negative value for MaxSpeed.
TargetTime, that is the actual simulation time of the network
simulator plus one simulation step.
After simulating, the traffic simulator replies with a Status
4.6. Command Stop Node (Id 0x12)
response as described in Section 4.3. and a collection of Move integer position float double
Node responses – one for each active node – as stated in Sec- NodeId StopPosition Radius WaitTime
tion 4.4. The returned node positions are either 3D or road
map representations according to the requested PositionType Using the Set Maximum Speed command, a vehicle can be
(cf. also Section 4.1.). All these responses are bundled as one stopped immediately by setting its speed to zero. To stop a ve-
TraCI message. hicle sometime in the future at a predetermined position, the
Stop Node command can be used. It allows to set a position
4.3. Response Status where a node stops for an amount of time, whenever it gets
ubyte string there.
Result Description Regarding the mobility model, stopping a vehicle requires
some time. The traffic simulator is responsible for following
its models and for influencing a node in a proper way, so that
This response acknowledges each command; it includes a it is able to stop at the desired position.
Result and a Description. In contrast to all other commands The Stop Node command refers to the vehicle identified by
and responses, the identifier of the Status response is not the field NodeId. Its StopPosition can be given in any posi-
fixed, but refers to the identifier of the respective command tion representation. As most simulators are time discrete, it is
that is acknowledged. typically not feasible to hit a position exactly. Thus, a circular
The Result value is set to 0x0 in case of success or to 0xFF stoppage area is defined by a Radius around the stop position.
if the requested command failed. If the requested command Once the node stops, it waits for a period of time (WaitTime),
is not implemented in the traffic simulator, a status of 0x01 is by setting its maximum speed to zero, before it goes ahead on
returned. Additionally, a Description text must be added. its route.

CNS '08 159 ISBN 1-56555-318-7

4.7. Command Change Lane (Id 0x13) the Network Simulator (ns2) [2] as the wireless ad-hoc net-
integer byte float work simulator. Both simulators are well established in the
research community.
NodeId Lane Time
SUMO is an open-source, portable, microscopic road traf-
fic simulator, designed to handle large road networks. It is
Using the command Change Lane, a vehicle identified by also a multimodal simulator, i.e., it is capable of processing
NodeId can be forced to move to another Lane for an amount different types of traffic (buses, cars, etc.). As in most of the
of Time. After the given Time, the constraint is removed. If available traffic simulators the mobility model in SUMO is
the road segment changes while a vehicle drives on a fixed based on a car following model, especially the model pro-
lane, it gets fixed to the corresponding lane on the succeeding posed by Krauss [23].
road segment. If this does not exist, the constraint is removed, Ns2 is the most widely used network simulator in the mo-
which allows the vehicle to use all lanes again. bile ad-hoc network community. It provides extensions with
more accurate and up-to-date models [24], including a wire-
4.8. Command Change Route (Id 0x30) less interface adjusted according to the IEEE 802.11p draft
integer string
(the envisioned technology for VANETs) and probabilistic ra-
double
dio wave propagation.
NodeId RoadId TravelTime Although we focus our implementation effort on the afore-
mentioned simulators, we would like to stress that our frame-
The command Change Route allows a vehicle identified work is neither limited to a special road traffic simulator nor
by NodeId to react to certain traffic situations by adapting its to a special network simulator. We demonstrate this by pro-
route. Therefore, an individual (estimated) TravelTime for an viding an additional TraCI-Client implementation for the al-
appointed road segment (RoadId) is set. Under the normal op- gorithmic centric ad-hoc network simulator Shawn [4]. Fur-
eration, an estimated travel time for all road segments is used thermore, a TraCI-Client implementation for JiST/SWANS
according to their length and allowed speed. This accords to [3] is currently conducted. We would like to refer the reader to
the mode of operation of today’s route guidance systems. the TraCI wiki [22] for more implementation details and the
The travel times set by this command are only visible to the latest version of the protocol. The actual download of SUMO,
given vehicle and a new route is calculated before the simu- patches for ns2 as well as other simulation tools that provide
lation continues. TraCI are also available.
By setting a negative travel time, a typical travel time for
that road segment is restored. To mark a road as blocked, a 5.1. Simulation Run
near infinite travel time should be used. As in our approach the traffic simulator acts as a server,
it must be started first. SUMO provides two additional
4.9. Command Change Target (Id 0x31) command-line parameters used for starting it in TraCI-Server
integer String mode.
NodeId RoadId • --port <int> Sets the server port on which SUMO
listens for an incoming connection. If set, the simulation
is triggered by using the Simulation Step command.
The Change Target command is used to change the destina-
tion of a vehicle (NodeId). It needs the road segment (RoadId) • --penetration <float> Defines the ratio of ve-
that is the new target. Before the traffic simulator continues its hicles (between 0 and 1) that are equipped with a radio
simulation, a route to the modified destination is calculated. interface. This value defaults to 1.
In Figure 1, we present a simple example of TraCI message
exchange that corresponds to the simulation scenario, where In the case of ns2 as network simulator, the TraCI-Client is
set up inside the TCL script that also configures the network
two vehicles communicate over VANET and one of them de-
scenario. The following code instantiates a TraCI-Client ob-
cides to adjust its speed. ject that is responsible for the connection to a TraCI-Server.
Using set-remoteHost and set-remotePort, the
5. IMPLEMENTATION connection to the TraCI-Server is specified. Afterwards, the
As our main goal is to offer an open-source tool that is time interval for calls of the Simulation Step command is set
modular, and thus easily extensible, we have chosen two and the startSimStepHandler starts the periodic Sim-
ulation Step commands. The TCP connection is established
open-source simulators to implement the TraCI framework
automatically.
for VANETs. We have selected the Simulation of Urban MO-
bility simulator (SUMO) [5] as the road traffic simulator and set traciC [new TraCIClient]

ISBN 1-56555-318-7 160 CNS '08

 $traciC set-remoteHost localhost 35
$traciC set-remotePort 8888 1. Traces
30 2. TraCI
$traciC set-timeInterval 1.0 3. Static

Simulation runtime [min]

$traciC startSimStepHandler 25

Whenever a node is instantiated, it must be attached to the 20

TraCI-Client using the following line of code:
15
$traciC add-node $node($i)
10
To start the VANET application on a network node at the
5
moment the corresponding vehicle starts to move in the traffic
simulation, the corresponding ns2 agent must be registered 0
using start-on-move. To disable a network application 75 250 500 750 1000 1250 1500
when the vehicle leaves the simulation stop-on-halt is Equipped vehicles
used accordingly. Figure 3. Runtime comparison between traditional sequen-
tial execution of SUMO, traceExporter and ns2 (Traces) ver-
$traciC start-on-move $node($i) $agent($i)
$traciC stop-on-halt $node($i) $agent($i)
sus interactive run of SUMO and ns2 coupled by TraCI. A
ns2 simulation with static nodes serves as reference (Static).
A node’s behavior can be influenced using TCL as well as
C++. The following TCL code sends a Set Maximum Speed
command to the traffic simulator, so that $node($i) slows subset of operating vehicles will be equipped with it. Hence
down to zero: the penetration ratio of this technology will be far less than
100 %. We can simulate this using the proposed architecture
$traciC command-setMaximumSpeed $node($i) 0 by reporting only a portion of the 1500 vehicles to ns2. We
To make the same call from within C++ use the following measured the simulation runtime of the three approaches with
line of code: a varying number of equipped vehicles. The evaluation was
performed on a 3.4 GHz Intel Pentium D workstation with
TraCIClient::instance() 2 GB of RAM.
->commandSetMaximumSpeed(node, 0);
The results are shown in Figure 3, whereby each line de-
For the full reference, we refer the reader to [22]. picts one of the aforementioned approaches.
The ‘Traces’ curve shows the runtime as a sum of consec-
utive executions of SUMO, traceExporter and ns2. SUMO
6. EVALUATION
needs about 78 s to generate a netstate-dump file contain-
We show that our TraCI approach can compete with the
ing all the vehicle’s movements. This is fed into traceEx-
traditional way of using trace files and give thereafter an ap-
porter that converts it to a ns2 trace files with varying rates
plication example, where the TraCI approach allows to dy-
of equipped vehicles, resulting in different numbers of nodes
namically reroute vehicles.
that get into the ns2 simulation (about 10 min). Only the run-
At first, we compare three different kinds of mobility
time of ns2 depends on the number of nodes and reaches from
sources in a ns2 network simulation:
about 4 s for 75 nodes to about 21 min for 1500 nodes.
• Static. Nodes do not move during simulation. When using the ‘TraCI’ approach, SUMO and ns2 run in-
teractively and are connected through TraCI. We have to sum
• Traces. Mobility is generated prior to the network sim- up the particular runtimes of both simulators to obtain the
ulation. Thereby SUMO generates an output file that is simulation runtime, as depicted by the ‘TraCI’ curve in Fig-
converted to a ns2 trace file by using traceExporter. ure 3. SUMO, together with its TraCI-Server, needs between
38 s and 47 s depending on the number of equipped vehicles
• TraCI. Mobility is generated on-the-fly by SUMO that
that are reported to ns2 (between 75 and 1500). Ns2 together
is controlled via TraCI by ns2.
with its TraCI-Client consumes between 9 s (75 nodes) and
To benchmark only the influence of mobility sources, no 23 min (1500 nodes).
network packets are exchanged between the wireless network In the ‘static’ case, we have no mobility at all. This sim-
nodes inside the ns2 simulation. ulations serves as a reference showing the simulation time
The road traffic scenario is the same for all simulations. needed by the ns2 core itself.
1500 vehicles drive on a circular highway segment of 78.5 km The above results show that our TraCI approach competes
length (25 km diameter) for a duration of 2 h. At the time well with the traditional approach of using trace files. In com-
when the VANET technology will be on the market, only a parison to the runtime of ns2 in static case, it is obvious that

CNS '08 161 ISBN 1-56555-318-7

 50
Fixed traces
45 TraCI with 30% equipped vehicles
40
35

Travel time [min]

30
25
20
Figure 4. Road traffic scenario used for the exemplary ap- 15
plication. It is composed of a circular two-way road, whereby 10
a detour exists between A and B. 5
0
30 45 60 75 90 105 120
introducing mobility does not significantly extend ns2’s run- Simulation time [min]
time at all. We even benefit from using TraCI, because no Figure 5. Mean time for travelling from A to B (cf. Figure 4).
netstate-dumps need to be written to a hard drive and con- By using TraCI, vehicles could dynamically use the detour to
verted afterwards. decrease the travel time.
After demonstrating the efficiency of the TraCI approach,
we build a simple application that dynamically reroutes ve-
hicles, according to local traffic conditions. Therefore, we to 25 min.
modify the aforementioned road traffic scenario as depicted Even if this exemplary VANET application is not opti-
in Figure 4. We add two opposite lanes for two-way traffic mized in any way, it shows the potential application domain
to allow for easier packet exchange in the VANET. An ad- TraCI clears the way for.
ditional road is connected to the main road between A and
B. It is twice as long (15 km) as the segment of main road
(7.5 km); thus it is normally unused, but can serve as detour. 7. CONCLUSIONS
To achieve the same traffic density, as in the previous test, the
overall number of vehicles is increased with the road size to We have presented TraCI, the interface for controlling
3000. road traffic simulators via a flexible and extendable request-
reply protocol. This kind of interlinking of two simulators
The VANET application – that is implemented in ns2 –
is required, for example, to perform realistic evaluation of
measures on each equipped vehicle the needed time to travel
VANET applications as specified in the TraNS framework
from A to B. After passing that road segment, the data dis-
[13]. Note that the approach is not limited to ad-hoc network
semination protocol AutoCast [25] is used to inform oncom-
simulations as the proposed mobility interface is generic to
ing vehicles about the measured travel time. When TraCI is
control the road traffic generator. Based on the taxonomy of
active, the VANET application on vehicles approaching A in-
VANET applications proposed by C2C-CC, we have derived
form SUMO by the Change Route command about the ex-
basic control commands for the road traffic simulation and
pected travel times. Thereupon, SUMO reroutes those vehi-
have implemented interfaces for SUMO and ns2 - two open-
cles to the detour.
source simulators developed by different research communi-
During the simulation, an accident on the main road blocks
ties.
one of the two lanes. This leads to a traffic jam, increasing the
travel time between A and B. We have evaluated the performance of TraCI and have
Figure 5 shows on the y-axis the resulting travel times demonstrated that it is even faster to couple a network sim-
throughout the simulation (x-axis) that are needed to pass ulator with the road traffic simulator instead of writing trace
the road segment between A and B taking into account the files first and run the network simulation in the next step, even
main road as well as the detour. Travel times in Figure 5 if we do not need a control loop during execution.
are averaged over 15 min of simulation time. The accident Using the TraCI interface one can even evaluate complex
happens after 60 min, followed by a traffic jam throughout VANET scenarios, such as accidents (e.g. by stopping cer-
the rest of the simulation. The curve named ‘Fixed traces’ tain vehicles at a certain time instant) or simulating hazardous
shows the scenario without TraCI; the mean travel time raises road conditions (e.g., by modifying the speed of vehicles
from about 5 min up to 40 min, since the detour could not be which have directly ‘witnessed’ such conditions).
used. The second curve ‘TraCI with 30 % equipped vehicles’ We currently use TraCI to implement and evaluate vari-
show the same scenario where 30 % of the vehicles partici- ous VANET applications proposed by C2C-CC [21]. In fu-
pate in the VANET and use the detour to drive round the traf- ture work, we will extend TraCI to support a larger diversity
fic jam; so that the mean travel time for all vehicles is limited of network and road traffic simulators.

ISBN 1-56555-318-7 162 CNS '08

REFERENCES [16] J. Härri, F. Filali, C. Bonnet, and Marco Fiore. Vanet-
[1] IEEE Intelligent Transportation Systems Society. MobiSim: Generating Realistic Mobility Patterns for
http://www.ieee.org/its. VANETs. In Proc. of VANET ’06 (Poster abstract),
pages 96–97, 2006.
[2] Kevin Fall and Kannan Varadhan. The ns manual, 1989–
2001. [17] Rahul Mangharam, Daniel S. Weller, Daniel D. Stan-
cil, Ragunathan Rajkumar, and Jayendra S. Parikh.
[3] JiST/SWANS: Java in Simulation Time/Scalable GrooveSim: A Topography-Accurate Simulator for Ge-
Wireless Ad hoc Network Simulator. ographic Routing in Vehicular Networks. In Proc. of
http://jist.ece.cornell.edu. VANET ’05, pages 59–68, 2005.
[4] Sandor P. Fekete, Alexander Kröller, Stefan Fischer, and [18] S.Y. Wang, C.L. Chou, Y.H. Chiu, Y.S. Tseng, M.S.
Dennis Pfisterer. Shawn: The fast, highly customizable Hsu, Y.W. Cheng, W.L. Liu, and T.W. Ho. NCTUns 4.0:
sensor network simulator. In Proc. of INSS ’07, 2007. An Integrated Simulation Platform for Vehicular Traffic,
Communication, and Network Researches. In Proc. of
[5] Daniel Krajzewicz, Michael Bonert, and Peter Wagner.
WiVec’07, 2007.
The Open Source Traffic Simulation Package SUMO. In
RoboCup 2006 Infrastructure Simulation Competition, [19] Stephan Eichler, Benedikt Ostermaier, Chritoph
Bremen, Germany, 2006. Schroth, and Timo Kosch. Simulation of Car-to-Car
Messaging: Analyzing the Impact on Road Traffic. In
[6] VISSIM: microscopic, behavior-based
Proc. of MASCOTS ’05, pages 507–510, September
multi-purpose traffic simulation program.
2005.
http://www.ptvamerica.com/vissim.html.
[20] Christian Lochert, Murat Caliskan, Björn Scheuer-
[7] MATsim: Multi-Agent Transport Simulation Toolkit.
mann, Andreas Barthels, Alfonso Cervantes, and Martin
http://www.matsim.org.
Mauve. Multiple Simulator Interlinking Environment
[8] TRANSIMS: Transportation Analysis Simulation Sys- for IVC. In Proc. of VANET ’05 (Poster abstract), pages
tem. http://www.ccs.lanl.gov/transims/index.shtml. 87–88, 2005.

[9] Richard M. Fujimoto, Randall Guensler, Michael P. [21] Roberto Baldessari, Bert Bödekker, Matthias Dee-
Hunter, Hao Wu, Mahesh Palekar, Jaesup Lee, gener, Andreas Festag, Walter Franz, C. Christo-
and Joonho Ko. CRAWDAD data set gat- pher Kellum, Timo Kosch, Andras Kovacs, Massimil-
ech/vehicular (v. 2006-03-15), March 2006. iano Lenardi, Cornelius Menig, Timo Peichl, Matthias
http://crawdad.cs.dartmouth.edu/gatech/vehicular. Röckl, Dieter Seeberger, Markus Straßberger, Hannes
Stratil, Hans-Jörg Vögel, Benjamin Weyl, and Wenhui
[10] Valery Naumov, Rainer Baumann, and Thomas Gross. Zhang. Car-2-Car Communication Consortium - Man-
An Evaluation of Inter-Vehicle Ad Hoc Networks Based ifesto (Version 1.1), August 2007. http://www.car-2-
on Realistic Vehicular Traces. In Proc. of MobiHoc ’06, car.org/index.php?id=570.
pages 108–119, 2006.
[22] Wiki for the Traffic Control Interface.
[11] Rapid Generation of Realistic Simulation for VANET. http://sumo.sf.net/wiki/index.php/TraCI.
http://www.csie.ncku.edu.tw/ klan/move/index.htm.
[23] Stefan Krauß. Microscopic Modeling of Traffic Flow:
[12] TraceExporter: Exports SUMO dumps as ns2 traces. Investigation of Collision Free Vehicle Dynamics. PhD
http://sumo.sourceforge.net/wiki/index.php/traceExporter. thesis, Universität zu Köln, April 1998.
[13] TraNS: Joint Traffic and Network Simulator - [24] Marc Torrent-Moreno. Inter-Vehicle Communications:
Application-centric framework for evaluation of Achieving Safety in a Distributed Wireless Environment:
VANETs. http://trans.epfl.ch. Challenges, Systems and Protocols. PhD thesis, Univer-
sitätsverlag Karlsruhe, 2007.
[14] Amit Kumar Saha and David B. Johnson. Modeling
Mobility for Vehicular Ad Hoc Networks. In Proc. of [25] Axel Wegener, Horst Hellbrück, Stefan Fischer, Chris-
VANET ’04 (Poster abstract), pages 91–92, 2004. tiane Schmidt, and Sándor Fekete. AutoCast: An Adap-
tive Data Dissemination Protocol for Traffic Informa-
[15] D. R. Choffnes and F. E. Bustamante. An Integrated tion Systems. In Proc. of VTC ’07, Baltimore, USA,
Mobility and Traffic Model for Vehicular Wireless Net- October 2007.
works. In Proc. of VANET ’05, pages 69–78, 2005.

CNS '08 163 ISBN 1-56555-318-7