230 likes | 639 Views
Presentation Outline. Proposed GoalsPreview of ResultsIntroduction to AODV-UUIntroduction to the APE testbedIntroduction to ns-2Porting AODV-UU to ns-2Enabling Trace-based SimulationSummary and ConclusionsQuestions. Proposed Goals. The main goals of the master's thesis project:To port
E N D
1. Porting AODV-UU to ns-2 and Enabling Trace-based Simulation Björn Wiberg
bjwi7937@student.uu.se
2003-02-05
2. 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
3. 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
4. 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
5. 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.
6. 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
7. 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”
8. 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 Ns-2 was developed at the University of California Berkeley and the University of Southern California Information Sciences Institute.
One of its main advantages (which may have contributed to its widespread usage) is that it is available free of charge.Ns-2 was developed at the University of California Berkeley and the University of Southern California Information Sciences Institute.
One of its main advantages (which may have contributed to its widespread usage) is that it is available free of charge.
9. Introduction to ns-2 Example simulation scenario script:
10. Introduction to ns-2 Example visualization with NAM: The picture shows an ad-hoc networking scenario using AODV-UU, visualized by NAM. All traffic in this scenario has to pass through an intermediate node, due to limited radio range.The picture shows an ad-hoc networking scenario using AODV-UU, visualized by NAM. All traffic in this scenario has to pass through an intermediate node, due to limited radio range.
11. 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 Yet another reason for performing the porting is the fact that the AODV implementation that comes with ns-2 is rather outdated.Yet another reason for performing the porting is the fact that the AODV implementation that comes with ns-2 is rather outdated.
12. 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
13. 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
14. Porting AODV-UU to ns-2 Construction of the AODV-UU routing agent class:
Header files needed from ns-2 and ”standard includes” are included on a global level.
AODV-UU parameters, global definitions and global declarations are included on a global level.
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.
15. 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
16. 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) Testing of AODV-UU in ns-2 was performed with good results. AODV-UU compares favorably to the AODV implementation that comes with ns-2. The most notable shortcoming of the AODV implementation that comes with ns-2 is its lack of recent AODV draft compliance.Testing of AODV-UU in ns-2 was performed with good results. AODV-UU compares favorably to the AODV implementation that comes with ns-2. The most notable shortcoming of the AODV implementation that comes with ns-2 is its lack of recent AODV draft compliance.
17. Enabling Trace-based Simulation Simulation results may differ from real-world results
An effect of limitations in simulation models
Models are models!
18. 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
19. 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
20. 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 Figures indicate results using the APE testbed with AODV-UU 0.5 and ns-2 2.1b8 with AODV-UU 0.5, respectively.Figures indicate results using the APE testbed with AODV-UU 0.5 and ns-2 2.1b8 with AODV-UU 0.5, respectively.
21. 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
22. 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 Step length considerations mainly concern the pre-processing stage which generates simulation events (commands to the error model), not the error model itself.
Future work on trace-based simulations would include gathering of more wireless channel characteristics from the APE testbed logfiles, if possible, to adopt more of the trace-based emulation approach.Step length considerations mainly concern the pre-processing stage which generates simulation events (commands to the error model), not the error model itself.
Future work on trace-based simulations would include gathering of more wireless channel characteristics from the APE testbed logfiles, if possible, to adopt more of the trace-based emulation approach.
23. Summary and Conclusions AODV-UU was successfully ported to ns-2, and attempts to minimize the differences between real-world 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! Sincere thanks to the entire CoRe (Communication Research) group at the Department of Computer Systems (DoCS) at Uppsala University.
Special thanks to Henrik Lundgren for organizing and supervising the master’s thesis project, Erik Nordström for AODV-UU, Stefan Lindström for help with C/C++ issues, and Christian Tschudin for kindly taking on the examination role.Sincere thanks to the entire CoRe (Communication Research) group at the Department of Computer Systems (DoCS) at Uppsala University.
Special thanks to Henrik Lundgren for organizing and supervising the master’s thesis project, Erik Nordström for AODV-UU, Stefan Lindström for help with C/C++ issues, and Christian Tschudin for kindly taking on the examination role.