HAL Id: hal-00524322
https://hal.archives-ouvertes.fr/hal-00524322
Submitted on 7 Oct 2010
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entic research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diusion de documents
scientiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
Vehicular networks emulation
Anthony Buisset, Bertrand Ducourthial, Farah El Ali, Soane Khalfallah
To cite this version:
Anthony Buisset, Bertrand Ducourthial, Farah El Ali, Soane Khalfallah. Vehicular networks emu-
lation. International Conference on Computer Communication Networks - ICCCN 2010, Aug 2010,
Switzerland. �hal-00524322�
Vehicular networks emulation
A. Buisset, B. Ducourthial, F. El Ali, S. Khalfallah
(1) Université de Technologie de Compiègne (2) CNRS Heudiasyc UMR6599,
Centre de Recherche de Royallieu, B.P. 20529, Compiègne, France
(corresponding author: ducourth@utc.fr)
Abstract—Many applications and protocols are planned for
the so-called Intelligent Transportation Systems (ITS). Most of
them are supposed to work in dynamic networks, such as the
vehicular ad hoc networks (VANET). However, designing and
studying distributed applications and protocols in such networks
is not easy. Analytical studies suffer from the lack of pertinent
models. Simulations are often far from reality. Road experiments
are generally limited, due to their complexity.
In this paper, we present an environment that emulates the
vehicular networks. It allows to reproduce road experiments
without further developments of the studied prototypes. These
protocols can be tested with more complex road traffic. The
impact of the communication range and the dynamics of the
network can be studied. Some comparisons with road tests and
simulations show the advantage of such an emulation framework.
I. INTRODUCTION
Nowadays, Intelligent Transport Systems (ITS) attract much
attention. ITS applications do indeed increase road safety
and transport efficiency, limit the impact of vehicles on the
environment, improve the overall productivity... A lot of inter-
vehicle applications are considered; most of them rely entirely
or partially on the vehicular network: emergency facilities,
crash prevention, collision avoidance, traffic jam management,
Internet access, infotainments (travel and tourist information,
chats, distributed games...).
However the Vehicular Ad hoc Network (VANET) ex-
hibits characteristics that are dramatically different from many
generic MANET (Mobile Ad hoc networks) [1]. The topology
varies very frequently due to vehicle movement or connection
losses. The loss rate is often high. The speed, the density and
the type of movement depends on the kind of roads. New
and specific protocols are often required to reach acceptable
performances, and important open issues remain to be solved.
It is worth noting that the design and the study of new
protocols or distributed applications is not easy. Analytical
studies require accurate models to take into account the dy-
namics of the network. However it is not easy to model all the
variations (speed, density, topology, loss rates...). Analytical
studies are generally used for highway scenarios, where the
network dynamics are low or at least predictable.
Simulations can take into account complex road traffic,
generated by specific traffic generators. However simulation
requires some simplifications regarding the propagation model,
or the studied protocols, which are generally far from those
used on the road. The performances obtained by simulation
are then often different from real measures. Simulations are
generally used for scalability studies and comparisons.
Road experiments give accurate performance measures in
realistic situations. However they generally involve few ve-
hicles and remain quite rare. Indeed such experiments are
tedious; they require many people, vehicles and equipment.
Moreover, they are generally not reproducible because the
scenario depends on the other vehicles. Also, the inter-vehicle
distances are difficult to control, and wireless communications
are subject to environmental factors, including weather and
trucks... Road experiments are generally used for punctual
measures and proof of concepts.
As we can see, there is a lack of tools facilitating the
design and the study of protocols and applications dedicated
to vehicular networks. Analytical studies, simulations and real
experiments all have their limitations, which are enforced by
the dynamics of vehicular networks.
In this paper, we show that emulation is a convenient way
to study such networks. During an emulation, some parts are
real, while some others are artificially reproduced by several
means. We present a powerful framework, named airplug-emu,
which is very close to real road experiments while still easy
to use. It allows fast prototyping and accurate performance
measures.
The Airplug-emu framework is based on the Airplug soft-
ware suite dedicated to the study of dynamic networks and
road experiments [2]. We summarize this software architecture
in Section III. We show how such an architecture can be
used to emulate the vehicular network in Section IV. In
Section V, we explain how realistic mobility scenarios can
be built, thanks to the GPS application. The emulation tool,
called EMU, is detailed in Section VI. Comparisons with road
tests and simulations are analyzed in Section VII. Concluding
remarks end the paper. We shall now begin by summarizing
related work.
II. R
ELATED WORK
Overview. An emulator is a tool that combines real and
artificial implementation (simulated or emulated). A lot of
studies show that emulation is interesting both for wireless
and wired network emulation. This paper deals with wireless
emulation. Wireless network emulators allow quick indoor
deployment and protocol testing without requiring physically
moving the nodes. According to [3], emulators can be sorted
in two categories: physical layer emulators and MAC layer
emulators. We will now follow up by summarizing related
work in both categories, to target the differences and position
our work.
Physical layer emulators. In physical layer emulators, all
the network layers, except the physical one, are real. The
physical layer can be emulated by attenuating the signal using
programmable Radio Frequency (RF) attenuators [4]. Other
emulators use RF wires to connect two pairs of nodes [5],
[6], [7]. This type of connectivity does not allow to take into
account the impact of outside factors, such as interferences
due to multipath. Moreover, these emulators do not implement
mobility simulation. The physical layer emulator EWANT [5]
can attenuate the sent signal of the sender using RF wires
while emulating the node mobility thanks to different antennas.
The emulator MiNT [7] takes into account interferences using
non programmable radio signal attenuators and handles the
mobility by positioning nodes on remote controlled robots.
The emulator ORBIT [8] attenuates the sent signal by
injecting white Gaussian noise in the environment. It relies
on a grid of 400 nodes in a 20 m
2
area. The nodes mobility
is simulated by a server that activates different nodes at
different times. The activated node corresponds approximately
to the geographical location the node would have at the same
moment in time.
In [9], another technique is used for emulating the physical
layer: the radio signal is digitized, modified to add radio
propagation effects and re-injected into the network interfaces.
MAC layer emulators. Concerning the MAC layer emula-
tors, all the network layers are real, except the physical and
the MAC ones. MAC layer emulation permits to determine
whether a node should receive a packet or not. In other terms,
if in the emulator, a node is in the neighborhood of other
nodes, then it should receive the packets coming from these
nodes. In the other cases, all the received packets are deleted.
This emulation is performed by using a filter tool, either
centralized [10], [11], [12] or distributed into each node of
the network, using iptables [13], [14] or specific filter
tools [15], [16].
In addition to the unique admission control of a packet,
other features can be added to the filter tool, such as accep-
tance or suppression, modification or delay of the received
packets [17], [18]. In this type of emulator, the real system
behavior is measured and used as input of the filter tool.
Hybrid emulators. Lastly, hybrids emulators are proposed
in [19], [20], [21], [7]. These emulators combine emulation,
real equipment and/or simulation. For instance, higher network
layers can be simulated using a network simulator while low
layers operate on real wireless devices.
Airplug-emu, the emulation framework presented in this
paper, is mainly a MAC layer emulator, designed for vehicular
ad hoc network studies. It can also be hybrid, by allowing the
integration of real wireless links in the emulation.
III. A
RCHITECTURE FOR ROAD EXPERIMENTS: AIRPLUG
The airplug-emu emulation framework is part of the Airplug
software suite [22], designed for experimentation in dynamic
ad hoc networks [23], [2]. It relies on a core program and a set
of applications. We summarize here its main characteristics.
The core program named Airplug manages the inter-
applications communications, either local-to-the-host or inter-
vehicle. The applications (GPS and PRO in Figure 1) are
plugged on top of the core program; they reach the network
through Airplug. The core program and the applications run
in independent user-space processes for robustness and porta-
bility reasons.
GPS
NETWORK
1
2
Airplug
PRO
Operating System
Network interfaces
PRO
Airplug
GPS
Operating System
Network interfaces
process
stdin
pipe
stdout
Fig. 1. Airplug architecture, intra- (1) and inter- (2) vehicle communications.
The communications are handled in the easiest and most
robust way, by using standard input and output for receiving
and sending messages respectively. This guarantees complete
independence from the programming language used to develop
the applications. For each process launched by Airplug, the
standard input and output are redirected from and to Airplug
by pipes (Figure 1). Thus, each time a process writes in
its standard output, Airplug receives the data, and each time
Airplug writes in the pipe, the process can read the data from
its standard input. Since the network interfaces are handled by
Airplug, the applications access the network in the same way
they would to communicate with other local applications, by
writing in their standard output. Airplug forwards the data to
the network interface, preventing any network resources abuse
by bugged applications.
Messages use a specific addressing format, well adapted to
dynamic networks. The destination of a message is specified
with an area and the name of the destination application. This
addressing scheme is closed to the one in the WAVE Short
Messages Protocol (WSMP) [24].
The area can be local (keyword LCH for localhost) or
external (in other words composed by cars in the neighbor-
hood; keyword AIR), or both (keyword ALL). But it can also
be more specific (name or address of a nearby vehicle). A
message coming from a given application can be sent to many
other applications by filling in the destination application field
with the keyword ALL. However, by default an application A
receives only messages addressed to it and sent by a local
application B. To receive messages sent by B addressed to
ALL applications, A must first subscribe to the messages of B
by contacting Airplug. Similarly, to receive messages sent by
a remote application C, the application must first subscribe to
them, even if they where sent directly to it. This registering
system (relative confidence locally, and limited confidence
remotely) allows an application to control its receptions. It also
increases the architecture’s robustness by avoiding chained
problems in case of bugged applications.
It is worth noting that the design of new protocols as well
as cross-layering architectures is facilitated, by programing in
user-space. Airplug can bypass the operating system protocol
stack using raw sockets.
IV. F
ROM ROAD TO EMULATION: AIRPLUG FACILITIES
The Airplug architecture has been designed to offer a
simple, portable and robust framework for experimenting in
vehicular networks (and in any other dynamic network). In
this section, we explain that such an architecture is also very
convenient for network emulation.
Since applications run in independent processes and com-
munications rely on standard input/output, the network can be
emulated using shell facilities. For example, communications
(1) and (2) in Figure 1 can simply be reproduced in a shell
by the command:
./gps | ./pro | ./pro
A bidirectional link between two applications such as PRO ↔
PRO can be emulated with named pipes:
mkfifo link1 link2 creates 2 named pipes
./pro < link1 > link2 launches first app. PRO
./pro < link2 > link1 launches second app. PRO
Mobility is emulated by changing pipe redirects, by deletion or
by creation. In order to avoid packet loss, a gateway is inserted,
using the cat command: by temporarily freezing this process,
messages are stored in its input pipe while its output pipes are
modified. The following script creates a loop of two vehicles
running the protocol PRO, and then inserts a third vehicle.
To create a network connecting two vehicles in a loop:
mkfifo in1 in2 out1 out2 gtw1 gtw2 Pipes
./pro < in1 > out1 & Creates the vehicles
./pro < in2 > out2 &
cat out1 > gtw1 &
Connectes the gateway
pid_cat1=$! ($! = process id. of the last process)
cat out2 > gtw2 & ; pid_cat2=$!
tee in1 < gtw2 & ; pid_tee1=$! Creates the loop
tee in2 < gtw1 & ; pid_tee2=$!
tee in1 & Starts the communications
To create a third vehicle to be inserted in the loop:
mkfifo in3 out3 gtw3
./pro < in3 > out3 &
cat out3 > gtw3 & ; pid_cat3=$!
To freeze the gateways and new connections:
old_pidtee1=$pid_tee1 ; old_pidtee2=$pid_tee2
kill -STOP $pid_gtw1 $pid_gtw2 $pid_gtw3
tee in2 in3 < gtw1 & ; pid_tee1=$!
tee in1 in3 < gtw2 & ; pid_tee2=$!
tee in1 in2 < gtw3 & ; pid_tee3=$!
To unfreeze the gateways and to remove old connections:
kill -CONT $pid_gtw1 $pid_gtw2 $pid_gtw3
kill -KILL $old_pidtee1 $old_pidtee2
As we can see, simple shell scripts can easily reproduce
dynamic network topologies. No modification is required for
the applications and protocols, providing they have been
developed with the Airplug rules (independent processes and
communications using standard input and output). Such scripts
are very convenient, robust and powerful for prototyping.
Nevertheless, their writing has to be automated when scenarios
become complex and when real vehicle locations have to be
used. This is the aim of the EMU program, presented below.
V. G
ENERATING REALISTIC TRAJECTORIES: THE GPS APP.
In order to populate the emulated vehicular network with
realistic vehicle locations, we developed the GPS application.
The GPS application is above all an acquisition tool, able
to retrieve geographic locations when receiving NMEA frames
from a GPS device connected to the computer. As an Airplug
compatible application, it allows in real time to send the
current vehicle location to local applications that subscribed
to it.
In order to reproduce road tests in a lab, the GPS application
can save the locations in a file during the road tests. Then,
when using the GPS application in a shell script that emulates
the vehicular network, it can read the file of locations at a
given frequency, and write them in its standard output to send
them to connected applications.
However, a road test relies on fewer vehicles than the
number desired during the emulation. To circumvent this
problem, the GPS application can generate new realistic tra-
jectories starting from a file of locations obtained on the
road. Generated locations are calculated using a weighted
barycenter from each successive pair of positions read in the
file. This barycenter is modified by a random factor, truncated
if necessary to prevent the new position from leaving the
interval between the two original positions. This avoids sudden
reverses while adding some irregularity in the node movement.
The generated locations can be saved in a file and/or written
in the standard output to be sent to connected applications.
Thanks to this feature, a single log obtained on the road can
lead to long realistic convoys of vehicles in the emulation.
VI. E
MULATION TOOL: THE EMU APPLICATION
In this section, we describe the EMU application. It auto-
mates the emulation and offers powerful features.
Overview. The EMU application aims to perform realistic
experiments of protocols and applications designed for vehic-
ular networks. With EMU, the applications and protocols to
be studied run on independent processes as they do during
road experiments, without any modification. EMU handles all
the communications, either intra- or inter-vehicle, by using the
shell facilities, as explained in Section IV. This application is
written in Tcl/Tk and runs on a Linux PC. Several computers
can be used in order to introduce real links instead of emulated
ones (hybrid emulation).
Scenario. The scenario of the test is described in an XML
file, that indicates the number of vehicles, the size of the
geographic area, the applications and protocols running in
each vehicle, the trajectory of each vehicle, and so on. The
trajectories are produced with the GPS applications, by using
real positions as explained in the previous section. However,
EMU accepts other input for node mobility, produced by
traffic generators such as VanetMobiSim [25]. The Network
Simulator format is also accepted. This allows to compare
road experiments and simulations with the emulation, as we
shall do in the next section.
Link. EMU reads the position of each node in the network
with a user-defined frequency. The communication links are
determined by the wireless communications range (user-
defined) and a random factor hazard. If the distance between
two vehicles is less than range × hazard, then there is a
link. The hazard permits to add (or not) a variation in the
antenna scope (to avoid perfect discs). It is also possible to
use node-specific ranges, which is useful for some VANET
security studies. The links affected by the movement of a node
v are determined by checking each node position located in the
range of v. Node locations are stored in lists sorted by x and y
axis; the algorithm complexity is generally lower than O(n
2
)
because neighbors of v are searched in a square centered on
v with a side equal to 2 × range. This avoids checking each
pair of nodes at each move.
Network emulation. The emulation of the dynamic network
generalizes the scheme explained in Section IV. For each
vehicle, EMU launches the applications and protocols specified
in the XML file with the related command line, so that they
run in independent processes (TST and HOP in Figure 2).
The standard input of these processes are connected to a
reception process RCP and their standard output are connected
to a directional process DIR. The first one receives all the
inter- and intra-communications. The second one forwards the
messages either for local applications or for neighbor vehicles
through the gateway process GTW.
pipe
RCP
TST
HOP
DIR GTW
from
neighbors
to
neighbors
process
stdin
stdout
Fig. 2. Two applications (TST and HOP) in an emulated vehicle.
The RCP process is a Tcl shell script that forwards intra-
vehicle messages. The GTW process is implemented with the
cat command. As previously explained, it is used to change
the inter-vehicle connections without packet losses (if a perfect
network is desired): first GTW is frozen, next the inter-vehicle
links are changed, and then GTW is unfrozen and the messages
waiting in its input are sent without losses. The DIR process
is a Tcl shell script that analyzes the header of the messages
sent by the local applications in order to determine whether
they should be sent locally (keyword LCH) or to neighbor cars
(keyword AIR) or both (keyword ALL).
Realistic emulation. All inter-process links including inter-
vehicle links (from a GTW process on vehicle A to a RCP
process on vehicle B) rely on shell named pipes. In order to
reproduce the conditions of communication observed on the
road, the RCP process can delay or lose inter-vehicle messages.
It then accepts two parameters (delay and lossrate); such
values can be measured during road experiments.
It is also possible to run an emulated vehicle on another
computer, thanks to the remote mode. In this mode, the
messages generated by a remote application reach the others
through a socket. This socket can be established on any real
network (Ethernet, 802.11a/b/g/p and so one) in order to
include real links in the emulation (hybrid emulation).
Fig. 3. Emulation of the DDS application on a convoy of 9 vehicles generated
by the GPS application from a real GPS trajectory obtained on road N131,
Compiègne, France. We can see the DDS applications running on vehicles 1
and 10, as well as parameters of EMU. Maps by OpenStreetMap.org.
Output. The EMU application offers several outputs, which
can be used simultaneously. First, it provides a graphical
representation of the moving vehicles as well as the links
between them. When the positions are read from GPS co-
ordinates, EMU downloads OpenStreetMap tiles [26] in order
to geographically locate mobile nodes (see Figure 3). This
display is useful to validate generated mobility scenarios and
to study the network topology depending on the range and
the reliability criteria (which can be changed on-line).
Second, EMU is able to launch the applications of all
vehicles. An option allows to iconify some of them in order to
focus on the most interesting for the current study. This is the
main use of EMU (Figure 3). It allows to test applications in
an environment similar to the road. Communication links are
modified as the emulation progresses and the vehicle positions
change. The messages that are exchanged between applications
and protocols circulate through named pipes, either inside
emulated vehicles, or between emulated vehicles. Each vehicle
can be set to delay or loose messages in order to reproduce
wireless communication links. The dynamics of the network
