Transcript Porting AODV-UU to ns-2 and Enabling Trace

Porting AODV-UU to ns-2 and
Enabling Trace-based Simulation
Björn Wiberg
[email protected]
2003-02-05
Presentation Outline
• Proposed Goals
• Preview of Results
• Introduction to AODV-UU
• Introduction to the APE testbed
• Introduction to ns-2
• Porting AODV-UU to ns-2
• Enabling Trace-based Simulation
• Summary and Conclusions
• Questions
Proposed Goals
The main goals of the master’s thesis project:
• To port AODV-UU, the Uppsala University
implementation of the AODV (Ad hoc On-demand
Distance Vector) routing protocol to the ns-2 network
simulator
• To use log files from the APE (Ad hoc Protocol
Evaluation) testbed for performing trace-based
simulations of real-world experiments
• To compare results of trace-based simulations to
results of real-world experiments
Implicit Goals
• To find and correct possible bugs in AODV-UU
• To encourage the usage of AODV-UU by making it
available to the ns-2 community, and hence, a large
part of the research community
• To offer an alternative to the existing AODV
implementation in ns-2
• To get hands-on experience with ns-2, simulations
and simulation models
Preview of Results
• AODV-UU was successfully ported to the ns-2
network simulator. The ported version uses the same
code base as the conventional version.
• The ported version of AODV-UU is included with the
AODV-UU distribution.
• Trace-based simulations were performed using APE
testbed logfiles and a simple on/off connectivity
model between mobile nodes. Resulting packet
delivery ratios approximately 1.5% off real-world
figures.
Introduction to AODV-UU
• Linux implementation of the Ad hoc On-demand
Distance Vector (AODV) routing protocol
• Developed at Uppsala University
• Implements all mandatory and most optional features of
AODV, and adheres to the latest version 11 AODV draft
• Released under the GNU GPL (General Public License)
• Runs on Linux 2.4.x kernels
• User-space daemon maintains the routing table
• Packet processing and mangling using Netfilter
• Can be used on both laptops and PDAs
• Offers easy installation, stability and ease of use
Introduction to the APE testbed
• Linux-based Ad-hoc Protocol Evaluation testbed
• Developed at Uppsala University
• Suitable for real-world wireless ad-hoc networking
experiments (e.g. AODV-UU + laptops + WLAN cards)
• Uses script-based choreography to guide participants
through on-screen messages
• This allows for scenario reproducibility
• All network traffic is logged; logs are collected and
processed afterwards at a collect node
• Mobility patterns can be identified through a Virtual
Mobility metric, and connectivity can be tracked
• This allows scenarios to be ”fingerprinted”
Introduction to ns-2
• Network simulator (version 2) for a multitude of platforms
• Developed at UC Berkeley and USC ISI as part of the
VINT (Virtual InterNetwork Testbed) project
• For simulations of e.g. wired, wireless, ad-hoc and
satellite networks
• Very popular in the research community
• Uses OTcl script files as simulation scenarios
• Offers the ability to add more complex network objects
and functionality, usually written in C++
• Simulations are performed from the command line
• Generates trace files with per-packet information
• Offers a Network Animator (NAM) for visualization
Introduction to ns-2
Example simulation scenario script:
# Node 1 starts to move towards node 0
$ns_ at 50.0 "$node_(1) setdest 25.0 20.0 15.0"
$ns_ at 10.0 "$node_(0) setdest 20.0 18.0 1.0"
# Node 1 then starts to move away from node 0
$ns_ at 100.0 "$node_(1) setdest 490.0 480.0 15.0"
# Setup traffic flow between nodes
# TCP connections between node 0 and node 1
set tcp [new Agent/TCP]
$tcp set class_ 2
set sink [new Agent/TCPSink]
$ns_ attach-agent $node_(0) $tcp
$ns_ attach-agent $node_(1) $sink
$ns_ connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns_ at 10.0 "$ftp start"
Introduction to ns-2
Example visualization with NAM:
Porting AODV-UU to ns-2
Starting points:
• AODV-UU is written in C
• ns-2 mostly uses C++ for packet handling and OTcl
for scripting (e.g. simulation scenarios)
• Strong desire to reuse as much source code as
possible for the ported version of AODV-UU
• C code should be possible to compile with a C++
compiler without too much trouble
• The result should be a routing agent for mobile nodes
in ns-2
Porting AODV-UU to ns-2
Simple solution:
• Source code extraction and inclusion using
preprocessor directives and macros; e.g. #ifdef,
#ifndef, #define, #undef, #include
• Allows for easy construction of routing functionality in
ns-2 (AODV-UU routing agents) while preserving the
original source code
• Eases code maintenance as ns-2-specific code is
clearly marked
• A practical solution to the idea of a common code
base
Porting AODV-UU to ns-2
Problem areas:
• Packet handling is different in the simulator; all
packets arrive through a single receive method
• All interfacing with the Linux kernel must be removed
• Global variables should not be global
• Static variables not necessarily needed, and have
different semantics
• Per-node logging must be implemented
• Timers should rely on virtual time in the simulator
• Compilation issues; compiling, packaging and
distributing the AODV-UU routing agent
Porting AODV-UU to ns-2
Construction of the AODV-UU routing agent class:
1.
Header files needed from ns-2 and ”standard
includes” are included on a global level.
2.
AODV-UU parameters, global definitions and global
declarations are included on a global level.
3.
Method declarations from various AODV-UU software
modules are placed inside the routing agent class
using source code extraction.
This yields a routing agent class that can be instantiated.
Porting AODV-UU to ns-2
Integrating the AODV-UU routing agent with ns-2:
• OTcl code constructed for instantiation and setup of
the AODV-UU routing agent
• The AODV-UU routing agent is packaged as a library,
then included during linking of ns-2
Distributing the AODV-UU routing agent:
• As a patch to the original ns-2 source code tree,
applied by the end-user
• Patch included with the AODV-UU distribution
Results of AODV-UU Porting
•
•
•
•
•
An AODV-UU routing agent for mobile ad-hoc nodes in ns-2
An attractive replacement for the AODV routing agent
supplied with ns-2
Uses the same source code as the conventional version of
AODV-UU, with only minor differences in packet handling
Helped finding a few obscure bugs in AODV-UU, which
would probably not have been discovered otherwise
Should work on most platforms supported by ns-2, e.g. Sun
Solaris (although Linux is the main intended platform)
Limitations:
•
•
OTcl support code not part of ns-2; needs to be manually
integrated when new versions of ns-2 are released
AODV-UU routing agent currently limited to a flat addressing
scheme (but still suitable for mobile ad-hoc simulations)
Enabling Trace-based Simulation
• Simulation results may differ from real-world results
• An effect of limitations in simulation models
• Models are models!
Idea:
• Use APE testbed logfiles to extract connectivity
information.
• Modify connectivity between mobile nodes accordingly
during ns-2 simulations.
• See if this can help compensate e.g. for the Gray Zone
problem. In real-world experiments, wireless broadcasts
may reach a node although unicast transmissions do not.
This phenomenon does not appear in the ns-2 simulator.
Enabling Trace-based Simulation
Proposed solution:
• Extract connectivity information from APE testbed
logfiles
• Translate into simulation events
• Construct a custom error model for the simulator; it
should allow connectivity to be modeled (on/off)
• Place the error model between the network interface
and MAC layer of mobile nodes; similar to the
mackill utility included with the APE testbed, but for
simulations
Enabling Trace-based Simulation
Considerations:
• Step length for determining connectivity from APE
testbed logfiles needs to be chosen carefully
• Knowledge about expected network traffic can help
making this decision
• ”Incorrect” step length may cut off RTS / CTS / ACKs
in a simulation due to lack of user network traffic
• Single step length for all nodes?
• APE testbed logging not primarily intended for
wireless channel characteristics modeling
• Simulation scenario properties determine the
suitability of the proposed error model
Enabling Trace-based Simulation
Example application:
The Roaming Node scenario
(APE testbed + AODV-UU vs ns-2 + AODV-UU)
• Mobile node moves through the corridors of a building
and Pings a target node.
• Stationary nodes offer multi-hop connectivity to the
target node.
• Limited radio range forces mobile node to use different
stationary nodes during the scenario.
• Real-world experiments yield 91.9% Ping success ratio
• Simulations in ns-2 yield 98.8% Ping success ratio due
to the absence of Gray Zones
Results of Trace-based Simulation
• Different step lengths (1.0 s, 0.5 s, 0.1 s) were tried for
the Roaming Node scenario
• Expected network traffic: 10 Pings per second
• A step length of 0.5 seconds proved to work best for
this scenario
Real-world Ping success ratio: 91.9%
Initial simulation Ping success ratio: 98.8%
Trace-based simulation Ping success ratio: ≈ 93.3%
Difference (real-world vs trace-based simulation): ≈ 1.5%
Results of Trace-based Simulation
Advantages:
•
•
•
Simple error model that is easy to understand and use
Helps bring simulation results closer to real-world results
Can also be used to verify routing agent implementations in
the simulator
Limitations:
•
•
•
Difficulty of choosing the step length (pre-processing)
Single step length for all nodes (pre-processing)
Limited connectivity model; simple on/off, and connectivity
can really only be guaranteed by the underlying radio
propagation model
Summary and Conclusions
• AODV-UU was successfully ported to ns-2, and
attempts to minimize the differences between realworld experiments and simulations through the usage
of a common code base
• AODV-UU has proven to be a good replacement for
the AODV implementation that comes with ns-2
• Trace-based simulations may help tightening the gap
between real-world experiments and simulations
even further
• The thesis could help others working on routing agent
implementations for ns-2
• Some of the limitations should be possible to
overcome through continued implementation
 It has been a lot of work, and a lot of fun!