Emulating End-to-End Losses and Delays for Ad Hoc Networks

Abstract

Ad hoc networks have gained place in the research area recently. There are many researches regarding different topics related to such networks, such as routing, media access control, security, scalability, and many others. There are two usual methods to test and evaluate ad hoc networks performance: simulations and real test-beds. A network emulator is a tradeoff between pure simulations and real test-beds. Here, we propose a multi-hop wireless ad hoc network emulator that uses the advantages of network simulator (NS-2) and traffic shaping tool (DummyNet), that we called SEDLANE [simple emulation of delay and loss for ad hoc networks environment]. SEDLANE is a network emulator that is based on TCP behaviour characteristics. Using SEDLANE, we can emulate a whole multihop ad hoc network through the data packet loss and round trip time (RTT) values over the TCP connection. SEDLANE helps testing and evaluating ad hoc network protocols using very simple and inexpensive test-bed configuration. The results confirm that; introducing SEDLANE within a simple configuration network (possibly 2 nodes) gives exactly the same results as those obtained when simulating such networks.

Full text

Page 1

Emulating End-to-End Losses and Delays
for Ad Hoc Networks
Alaa Seddik-Ghaleb
Networks and Multimedia Systems
Research Group (LRSM),Ecole
Nationale Superieure d’Informatique
pour l’industrie et l’Entreprise (ENSIIE),
8 allee Jean Rostand, 91025 Evry
CEDEX - France
Email: seddik@ensiie.fr
Yacine Ghamri-Doudane
Networks and Multimedia Systems
Research Group (LRSM), Ecole
Nationale Superieure d’Informatique
pour l’industrie et l’Entreprise (ENSIIE),
18 allee Jean Rostand, 91025 Evry
CEDEX - France
Email: ghamri@ensiie.fr
Sidi-Mohammed Senouci
France Telecom R&D
2 Av. Pierre Marzin,
22307 Lannion, France
Email: sidimohammed.senouci@
orange-ft.com


Abstract— Ad hoc networks have gained place in the research
area recently. There are many researches regarding different
topics related to such networks, such as routing, media access
control, security, scalability, and many others. There are two
usual methods to test and evaluate ad hoc networks performance:
simulations and real test-beds. A network emulator is a tradeoff
between pure simulations and real test-beds. Here, we propose a
multi-hop wireless ad hoc network emulator that uses the
advantages of Network Simulator (NS-2) and traffic shaping tool
(DummyNet), that we called SEDLANE [Simple Emulation of
Delay and Loss for Ad Hoc Networks Environment]. SEDLANE
is a network emulator that is based on TCP behaviour
characteristics. Using SEDLANE, we can emulate a whole
multihop ad hoc network through the data packet loss and
Round Trip Time (RTT) values over the TCP connection.
SEDLANE helps testing and evaluating ad hoc network protocols
using very simple and inexpensive test-bed configuration. The
results confirm that; introducing SEDLANE within a simple
configuration network (possibly 2 nodes) gives exactly the same
results as those obtained when simulating such networks.
I.
INTRODUCTION
A wireless ad hoc network consists of independent nodes
that communicate through the wireless channel without the
need of a network infrastructure or a centralized administration.
Due to its specific nature, many researches have been
performed so that new network protocols and applications are
introduced. Thus, it is important to evaluate these new
protocols and applications within an ad hoc network
environment. Generally, the following two ways can be used in
order to achieve that evaluation:
•
Building a real test-bed for ad hoc networks with the
desired network conditions, protocols and applications.
Although that this method is very realistic, it is
expensive to set up. Actually, no researches were done
in a scale beyond a dozen nodes.
•
Using a network simulator, such as NS-2 [1].
Simulating a network is always easier than
constructing a real testbed. On the other hand, the
simulator traffic is generated by traffic models that
some times do not match real applications’ behaviour.
Also, some performance parameters cannot be
evaluated through simulations (mainly, node related
performance parameters such as CPU usage and
computational energy consumption).
TCP throughput could be calculated using the RTT delay
and data packet loss over the connection. Floyd et al. [2] and
Ott et al. [3] propose a model that estimates the throughput of a
TCP connection under known delay and loss conditions as
follows:

l
M
rTCP
∗
∗
=
τ
22. 1
(1)
Where: rTCP is the TCP connection throughput, M is the
maximum packet length, τ is the round trip time of the
connection and l is the average loss measured during the
lifetime of the connection. From such a model, one can say that
TCP performance depends mainly on RTT values and loss
rates. Hence, in order to evaluate the performance of TCP
variants or application and protocols running above them, we
can use an emulator that introduces RTT and losses according
to realistic network performance scenarios.
In this paper, we propose a multi-hop wireless ad hoc
network emulator that uses the TCP trace files of NS-2 [1] in
order to introduce the effect (loss rates, and RTT values) of
multi-hop wireless ad hoc network into a well-known traffic
shaping tool ”Dummynet” [4]. If we take into consideration
that most network experimentations begin with simulations, it
would be useful to extend the simulation results beyond the
scope of the simulator capabilities by using an emulator that
uses the same network circumstances (through the network
simulator trace file). Since it is easier to control the network
environment using simulation tool, we take this advantages by
generating the desired scenarios within an ad hoc network
environment using NS-2 (as a simulation tool) and then we
inject its trace files into dummynet (as a traffic shaping tool) to
apply the same effects on a real traffic scenario, as if we had
had constructed a real multi-hop wireless ad hoc network
environment. Hence, we obtain a Simple Emulation of Delay
and Loss for Ad Hoc Networks Environment (SEDLANE).
1-4244-0353-7/07/$25.00 ©2007 IEEE
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2007 proceedings.

Page 2

SEDLANE allows emulating a multi-hop wireless ad hoc
network of any scale in a virtual way and with any mobility
scenario without the need of physically moving the ad hoc
nodes. SEDLANE does not need any additional knowledge of
a new emulating tool. It uses the well-known and free network
simulation (NS-2) and traffic shaping (Dummynet) tools.
Additionally, it is an inexpensive tool and does not need a
special hardware setup. This tool enables us to test the
performance of network protocols and applications (transport
layer and above) at the end points of any wireless ad hoc
network (emulated by SEDLANE). Our aim is to test the end-
to-end nodes’ performance that cannot be obtained while using
simulations, such as hardware related parameters (i.e.
computational energy cost at end points). SEDLANE allows
for evaluating the tested applications when running in real
situations. The entire wireless ad hoc network environment is
emulated using only one machine (e.g. a particular machine
installed in the middle of the two communication end points or
even one of the communication end-points can also play this
role). SEDLANE represents network nodes’ mobility, ad hoc
routing protocol, and TCP connection throughput through RTT
values (delay) and data packet loss within the network.
Our goal is to propose a simple emulator that helps in
evaluating new ad hoc network applications and protocols
running above TCP. From that point of view, we characterize a
useful ad hoc network emulator by the following features:
•
•
Simple and easy to implement.
Does not require any specific or expensive networking
hardware.
•
•
The tests must be controlled and repeatable.
The ability to emulate different ad hoc network
parameters (ad hoc routing protocols, nodes’ mobility,
and TCP connection throughput) using a small set of
emulated variables (delay and loss).
•
Emulating multi-hop wireless ad hoc network of any
size using a small number of physical machines.
The remainder of this paper is organized as follows: after
presenting the motivation behind our work in section II, section
III overviews dummynet and its main function, section IV
presents SEDLANE. In sections IV-A and IV-B we describe
the main operation modes of SEDLANE and the calculation
algorithms used. Section V introduces the validation results of
SEDLANE. Finally, we summarize main results and give some
ideas for future work in section VII.
II.
RELATED WORK
According to the above ad hoc emulator features, we will
discuss, in this section, the most known emulators in order to
find the one that meets our requirements. User Mode Linux
(UML) [5] is a system that can be used for emulating wireless
networks. It allows using several independent Linux instances
each running an adapted version of a complete Linux kernel in
user mode, providing a shared network environment through
the base Linux system. In [6] the authors stats that, UML
emulation performance is severely reduced, when used to
create wireless ad hoc network emulations, due to the fact that
UML runs in user mode and privileged operating system
functions must be emulated by the underlying kernel running
on the real hardware. In addition, UML offers only a virtual
Ethernet interface and not a virtual WLAN wireless interface
(i.e. a 802.11b interface). UML itself emulates only a single
wireless node. To emulate an entire network, a central
controlling instance is required to monitor and control all UML
instances. MobiEmu [7] is one of such central control solutions
that emulate a basic wireless network based on UML.
MobiEmu have a separate physical machine for each emulated
node. These limitations made UML and MobiEmu non-
scalable and hence not satisfying the requirements of our work.
ModelNet [8] was initially developed for testing large-scale
distributed services for wired wide-area network environments.
ModelNet architecture is composed of Edge Nodes and Core
Nodes. Edge Nodes in ModelNet can run arbitrary
architectures and operating systems. They run native IP stacks
and function in the way they would in real environments with
the exception that they are configured to route IP traffic
through ModelNet cores. Whereas, Core Nodes run a modified
version of FreeBSD to emulate topology-specific hop-by-hop
network characteristics. To decrease the number of edge
machines required for large-scale evaluations, ModelNet
architecture employs Virtual Edge Nodes (VNs). VNs enable
the multiplexing of multiple application instances on a single
edge machine, with each instance getting its own unique IP
address. ModelNet edge machines use internal IP addresses
(10.*), thus the number of interfaces that can be multiplexed
onto an edge node is not limited by IP address space
limitations, but rather by the amount of computational
resources (e.g. threads, memory) that a target application uses.
ModelNet configures all VNs to route their traffic through a
particular ModelNet core. Like ModelNet, MobiNet [9]
architecture is composed of edge nodes and core nodes. The
edge nodes support a variety of platforms and operating
systems. As in ModelNet, edge nodes in MobiNet host multiple
virtual nodes (VNs) to allow for large-scale emulations.
MobiNet cores emulate wireless network behaviour at multiple
layers while eventually routing packets to the edge node
hosting the destination VN. MobiNet incorporates mobile
wireless ad hoc network characteristics (i.e. nodes’ mobility
behaviour, routing module, and MAC layer collisions).
Although that the number of physical devices required in
ModelNet and MobiNet is reduced, and the platform seems to
be well developed for mobile wireless ad hoc environments
emulation, its setup remains complex, with respect to our
requirements. One of our major goals is to simplify ad hoc
network emulation allowing for easy evaluation of end-to-end
applications and protocols. Mobile Network Emulator (MNE)
[10] uses a static network infrastructure to interconnect
devices. Each device has two interfaces, where one acts as a
mobile emulation control channel while the other is used for
the emulated wireless network. The latter can be an actual
wireless interface, allowing for some lower layer effects (such
as collisions) to be taken into account as well. Information
about topology changes is sent through the control channel,
causing the nodes to set or remove iptables-rules accordingly,
similar to the way it is done in MobiEmu. The main problem of
this approach is that it still needs a separate device for each
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2007 proceedings.

Page 3

emulated wireless host and then do not allow for emulating
large ad hoc networks.
EMWIN [11] improves the issue with the number of
physical machines by allowing each node to have several
network interfaces, each acting as a separate wireless node.
EMWIN intends to provide emulation of some MAC layer
effects by introducing an additional emulated MAC (eMAC)
layer. Again, due to a relatively high number of machines
required, this approach is still impractical for our needs.
Other emulation tools also exist in the literature [12] [13]
[14]. Although these tools offer some interesting features, their
scalability remains limited. Furthermore, none of the emulation
tools presented above emulates an ad hoc network taking into
consideration the TCP connection characteristics.
III. OVERVIEW OF DUMMYNET
Dummynet is a traffic shaping tool that has been originally
designed for testing networking protocols [4]. Through
dummynet, we can enforce delays, packet losses, queue and
bandwidth limitations. Figure 1 illustrates the main function of
dummynet. Dummynet is entirely controlled by the system’s
ipfw (IP Fire-Wall) commands and a set of sysctl (System
Control) variables. The ipfw commands help the user defining
the rules to be applied by dummynet on the packets crossing a
particular network interface on its input or output. Unlike many
other traffic shaping packages, dummynet has a very little
overhead. All processing is done within the kernel and no data
copying involved in moving packets through pipes. Dummynet
implements the concept of pipes, which is defined as a
communication channel between the source and the
destination. It is capable of handling thousands of pipes. Each
packet will be manipulated according to the rules associated
with each pipe (communication channel), and a packet can
undergo several rules. We can use the same command to
configure different network parameters, such as bandwidth,
delay, queue size, and packet loss. For more details about
dummynet configurations and control, refer to [4].
Our decision to use dummynet was based on the fact that,
dummynet helps implementing data packet loss and traffic
delay constrains easily within the system’s kernel.
Additionally, with minimum processing overhead.
IV. SIMPLE EMULATION OF DELAYS AND LOSSES FOR

AD HOC NETWORKS ENVIRONMENT [SEDLANE]
The main idea of SEDLANE is to configure the dummynet
pipes (defining rules) through NS-2 trace files. To do so,
SEDLANE uses the NS-2 TCP trace file to identify the classes
of packets by gathering together the packets that have almost
the similar RTT values. Then, SEDLANE dedicates one pipe,
or communication channel, for each group of packets. Packet
loss percentage can be either calculated from NS-2 TCP trace
file or NS-2 standard trace file; and then can be applied to
dummynet pipes. Hence, according to the identified classes of
packets, RTT values, and the loss rates that are distributed
among classes, SEDLANE dynamically generates the
dummynet rules to be applied on the packets. Figure 2
illustrates the SEDLANE operation while the different
algorithms used by SEDLANE are described below.

A. SEDLANE Operation Modes
We have two operation modes in which we can run
SEDLANE; the choice of using them depends on the user’s
experimentation methodology. We will show in the evaluation
study the advantages of each of these modes.
1) Simultaneous operation mode: In this mode of operation,
SEDLANE configures all
communication channels) at the same time, assigning each pipe
a different probability value that corresponds to the amount of
traffic sent with each RTT to the total amount of sent traffic (as
extracted from the NS-2 TCP trace file). SEDLANE operates
in simultaneous mode by default. This mode reflects the
normal operation mode of the system’s ipfw. Figure 3
describes this operation mode. As can be shown in the Figure,
using simultaneous operation mode applies all the ipfw rules
without time constrains. Thus, if the user needs to emulate an
ad hoc network for a time greater than that of the simulation
scenario, SEDLANE’s Simultaneous mode will be the right
choice.
ipfw rules (dummynet

Figure 1 The principle of Dummynet operation


Figure 2 The principle of SEDLANE Operation

Figure 3 SEDLANE Simultaneous operation mode

Figure 4 SEDLANE Sequential operation mode
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2007 proceedings.

Page 4

2) Sequential operation mode: In Sequential operation
mode, as shown in Figure 4, SEDLANE configures only one
ipfw rule at a time. Each rule will be flushed after a certain
”lifetime” (the time during which the simulated connection
remained at an RTT values) before a new rule (with a new RTT
and loss value) is configured. The ”lifetime” of each rule can
be either provided as a command line argument or extracted
from the NS-2 TCP trace file. In the first case, the provided
lifetime will be applied to all rules, one after another. Whereas
in the latter case, each rule will have a different lifetime
corresponding to that in the NS-2 TCP trace file. The algorithm
used to calculate the sequential delay values from the TCP
trace file will be explained later. In this operation mode,
SEDLANE emulates exactly the data found in the NS-2 TCP
Trace file, respecting the time of the simulation scenario. This
time can be controlled, by the user if necessary, by specifying it
at the command line. In some cases, the lifetime of an RTT
transition is too small that the effect can not be noticed. Then,
increasing that time may help making this effect more clear.
B. SEDLANE Algorithms
SEDLANE starts by reading NS-2 trace files, specified by
the user at the command line. According to data contained in
these files and command line arguments, SEDLANE decides
whether to trigger some calculation algorithms. Figure 5 shows
the principal SEDLANE calculation algorithms. These
algorithms will be discussed in details by the following.
1) Input Data from trace files: SEDLANE extracts the
following data from the NS-2 trace files specified by the user at
the command line.
•
•
•
•
•
•
•
2) Number of Pipes used by SEDLANE: This argument
defines the number of rules to be configured according to the
desired accuracy. Note that configuring a large number of rules
requires more CPU resources and might affect the performance
of the test-bed. If the”number of different RTT samples found
in the TCP trace file (k)” is equal to or less than this argument
(N), SEDLANE dedicates a dummynet pipe for each RTT
value. Otherwise, SEDLANE calculates new RTT values that
correspond to the maximum number of pipes to be used as
given by the user. Calculating the new RTT values is done
through RTT calculation algorithm, which will be explained in
the following section.
3) RTT Calculation Algorithm: If the ”number of different
RTT samples found in the TCP trace file” is greater than
”maximum number of pipes” defined by the user. SEDLANE
starts RTT calculation algorithm. This algorithm is used to
calculate new RTT samples from the original ones found in the
TCP trace file. These new values are calculated as shown in
Equation (2). Where; RTTnew1,2,..,n−1?are the new generated RTT
samples; RTTi and RTTi+1?are two original consecutive RTT
samples.
Number of different RTT samples found in the file.
Timestamp of each RTT transition.
Total data bytes transmitted and that of each RTT.
Total data bytes retransmitted and that of each RTT.
Total connection time.
Lifetime for each RTT.
Total data bytes dropped and that of each RTT.←
SEDLANE repeats the calculations until the new number
of RTT samples matches the defined number of pipes. It is
possible that the number of resulting ipfw rules be less than the
provided number of pipes. This comes from the fact that
SEDLANE does not allow configuring two consecutive pipes
with equal RTT values. Additionally, in simultaneous mode,
only unique RTT values are allowed, thus there will be one
rule per each unique RTT value.
Is
N< K?
yes
No
Probability
calculation
Algorithm
NS-2 Standard
Trace File?
No
NS-2 TCP
Trace File
Packet Loss Ratio (PLR)
calculation Algorithm
Extract data
(RTT values,
LifeTime)
RTT Calculation
Algorithm
Calculate Sent data
(total, per RTT value)
yes
Calculate Dropped data
bytes per RTT value
Calculate Retransmitted
data byte per RTT value
Is
N< K?
yes
Plr = loss/sent
No
Is
N< K?
yes
Prob=data sent per RTT/total
data sent
No
Launch IPFW
(dummynet configuration)
Operation
mode
Simultaneous Sequential
All IPFW pipes are configured
at the same time with respect
to the probability value of
each RTT.
IPFW pipes are configured one
at a time taking into
consederation the liftime of
each RTT.

Figure 5 SEDLANE Operation Functions
2
2
21
1
2
1
++
+
+
=
+
=
ii
new
ii
new
RTTRTT
RTT
RTTRTT
RTT
2
)( ) 1
−
(
) 1
−
(
nn
new
RTTRTT
RTT
n
+
=
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2007 proceedings.

Page 5

4) Probability Calculation Algorithm: Probability is used
by dummynet to represent the probability of getting a match on
this rule if all other fields are correct. The probability assigned
to each ipfw rule depends on the SEDLANE’s operation mode:
either sequential or simultaneous. In sequential mode, each rule
will have a deterministic probability; since there is only one
rule present at a time. In simultaneous mode, the probability
assigned to each rule is the ratio of the transmitted data bytes
during a certain RTT lifetime to the total number of data bytes
transmitted over the connection, as extracted from the NS-2
TCP trace file. Equation (3) demonstrates how probability
values are calculated for each RTT sample. Where; probRTTiψis
the assigned probability for RTTi, txbytesRTTiψ is the data
transmitted during the RTTiψ Lifetime, and txbytestotalψis the
total data transmitted over the emulated connection. In case, the
number of RTT transitions in the trace file is higher than the
provided number of pipes, the probability of each new RTT
value is calculated according to Equation (4). Where probnew1?, is
the new generated probability; probiψ and probi+1? are two
original consecutive probability values; Nψ is the length of
original probability list; N−1?is the length of the new generated
probability list. The sum of the newly generated values is
always less than 1. Yet, since these are probability values, the
values will be adapted again so that their sum equals 1. This is
done by distributing the difference among the different
probabilities according to their respective values, as shown in
Equation (5). Where probnew1?is a new generated probability
value from Equation (4), probadapt1 is the adapted probability
value.
total
RTT
RTT
txbytes
txbytes
prob
i
i=




−






+
=
+
12
1
1
N
Nprobprob
prob
ii
new
∑
⋅=
new
newadapt
prob
probprob
1
11

The above process will continue till we have a number of
probability values that is equal to the number of pipes to be
configured.
5) Packet Loss Ratio Calculation Algorithm: In order to
calculate the packet loss ratio for each ipfw rule, SEDLANE
performs the following operations:
•
Calculate the amount of data transmitted with each
RTT.
•
Calculate the amount of data dropped or retransmitted
during the lifetime of each RTT.
•
Calculate the PLR for each RTT as the result of
dividing the corresponding amount of loss by the
amount of data sent.
These operations are detailed below.
Calculating the amount of transmitted data
SEDLANE calculates the amount of transmitted data for
each RTT: txbytesRTTψ, as well as the total amount of data
transmitted: txbytestotal. If the number of RTT values retrieved
from the NS-2 TCP trace file is greater than the provided
number of pipes, the following iteration takes place: A new list
of txbytesRTTψvalues is generated using Equation (6).
The algorithm then calculates the new sum of transmitted
data [as in Equation (7)]. Then, the algorithm maintains the
original total amount of transmitted data. This is done by
distributing the difference between the original sum txbytestotal
and the new sum txbytesnewTotalψamong the elements of the new
generated list according to their respective values [Equation
(8)]. Thus, after each iteration round, the total amount of
transmitted data will always equal txbytestotal. The iteration
above will continue till we have a number of txbytesRTT values
that is equal to the number of pipes to be configured.
2
) 1
+
()(
)(
+
=
iRTTi RTT
newi RTT
txbytes txbytes
txbytes
∑
=
newi RTTnewTotal
txbytes txbytes
)(
newTotal
totalnewi RTT
txbytes
adaptedi RTT
txbytes. txbytes
txbytes
)(
)(
=

Calculating the amount of lost data
SEDLANE adopts two methods to calculate lost data. By
default, SEDLANE uses NS-2 TCP trace file to calculate the
data packet loss ratio. It records the number of retransmitted
bytes during each RTT lifetime, and uses this value as the
amount of lost data. The retransmitted data bytes include data
bytes retransmissions due to retransmission time out (RTO)
and fast retransmit (FR). Alternatively, SEDLANE is able to
calculate the data packet loss ratio from the standard NS- 2
trace file. SEDLANE counts the amount of dropped data bytes
during the lifetime of each RTT, and uses this value as the
number of lost data. In case the number of RTT values
retrieved from the NS-2 TCP trace file is greater than the
provided number of pipes, SEDLANE executes the algorithm
explained in the previous section (IV-B.5) and maintains the
total amount of lost data similarly.
Calculating the Packet Loss Ratio
After determining the amount of transmitted data and lost
data for each pipe. Calculation of PLR is simple as in Equation
(9). Where; plrRTT(i)? is the packet loss ratio of RTTi;
lostbytesRTT(i) and txbytesRTT(i)? are the lost data bytes and
transmitted data bytes of RTTiψrespectively.
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2007 proceedings.