last update @ 2008-08-05 10:25
The power of ns is the capability to simulate dynamic network environments and the expected network performance. The performance can be greatly improved by choosing an appropriate networking protocol and ns provides already several MANETs for evaluation.
However, the grade of realism of these performace predictions greatly depends on the specific performance of the MANET which itself greatly depends on the underlying node mobility model. Without an appropriate mobility model for the simulated scenario at hand, the performance prediction is rather general.
During my research I came to face this exact challenge and hence started to look into mobility scenarios for my area of interest: Unmanned Aerial Vehicles. For my research I developed three mobility scenarios for the ns2 simulator which I would like to share here, hoping to get more people to evaluate their protocols against these scenarios.
On this page I would like to collect information related to these mobility scenarios as well as provide first steps as on how to use them in ns2.
last update @ 2008-08-05 10:25
An archive containing my mobility scenarios can be downloaded from here.
From here on I assume that ns2 (the scenarios as of now do not work with ns3 yet) is installed and operational. I will refer to the ns installation directory (e.g. /home/johndo/ns-allinone-2.33/ns-2.33/) simply as $NS. It might be useful to create a corresponding environmental variable. In Linux simply execute export NS=/home/johndo/ns-allinone-2.33/ns-2.33/.I will also use ~ to refer to the users home directory (e.g. /home/johndo/). johndo obviously is a dummy name for the actual user account name.
last update @ 2008-08-05 10:25
The archive provides three different mobility scenarios, each in a different subfolder:
According to the scenario, each scenario subfolder contains a TCL script (ns2sim-XXX.tcl), that utilizes the cooresponding scenario. For a quick check if everything is running, one can simply execute these scripts with ns:
:~/UAV_scenarios/NonIntrusiveSurveillance> ns ns2sim-nis.tcl
:~/UAV_scenarios/CoordinatedApproach> ns ns2sim-cap.tcl
:~/UAV_scenarios/ExpandingSearch> ns ns2sim-exs.tcl
The default TCL scripts utilize the MANET protocol AODV, which comes with ns. After the simulation is completed, the results are stored in a trace file. The name of the trace file is composed from the scenario and the MANET protocol utilized, e.g. nis-AODV.tr.
The archive also provides a matching network traffic file: m0m1.traffic. This file is invoked from within the scenario TCL scripts and creates a traffic pattern that mimics the basic network traffic which UAVs in the GT UAV Research Facility create.
The Toilers research group has created a visualization tool for ns: iNSpect. The archive provides configuration files for iNSpect which allow either a simple play back of the scenario via (e.g. for the nis scenario)
:~/UAV_scenarios/NonIntrusiveSurveillance> iNSpect -m nis-iNSpect.config nis-iNSpect.motion,
or a visualization of the actual simulation results:
:~/UAV_scenarios/NonIntrusiveSurveillance> iNSpect -t nis-iNSpect.config nis-AODV.tr.
Please note that the last part might not be completely correct - which I attribute to my limited understanding of ns trace files. If you can improve this part anyhow, please let me know!
iNSpect is openly available, just email Dr. Tracy Camp (tcamp@mines.edu) from Toilers or visit their website at http://toilers.mines.edu/Public/NsInspect.
last update @ 2008-08-05 10:25
The scenarios are created in several steps. The first and major part comes from the MATLAB scripts motion_generator_XXX.m. These scripts call other scripts (writeConfigFile.m, writeMotionFile.m) and ns tools (calcdest) in order to create the appropriate input files for ns and iNSpect.
Each MATLAB script has two major areas for settings: %% General Settings and %% Motion Specific Settings. The former has identical options in all scenarios, the latter scenario specific settings.
Altering the core of a scenario is not necessarily intended and hence not straight forward. The concept is that the motion of each node is composed by stitching together predefined path segments (wp in the scripts). This stitching is defined via the trajectories for each vehicle (tp in the scripts). On top of that, the exact position of a node in a cluster of nodes is depending on its role. There are main UAVs (MUAV) and supporting UAVs (SUAV). The MATLAB script FormationFlightOffset.m computes an offset for each waypoint on a trajectory and TrajectoryStiching.m creates the final list of waypoints for each vehicle (wpV).
ns accepts motion commands in the form of "at time T start moving along the vector CURRENT_POSITION-to-XYZ with velocity V". In order to compute a smooth path for the previously computed trajectories, the script then starts computing the necessary times and velocity vectors. This large data structure (data in the scripts) is then handed to writeMotionFile.m in order to create a ns understandable input file. writeMotionFile.m also invokes calcdest in order to compute the GOD information and place them into the motion file for ns.
writeMotionFile.m and writeConfigFile.m then also create files for iNSpect. A different file is necessary as iNSpect expects motion information to be in chronological order whereas ns expects motion information to be in reverse chronological order.
Changing the TCL scripts follows the usual rules for any other wireless scenario in ns. Of a particular importance are the settings
as they interact with the scenario. val(nn) has to be set to the sum of MUAV+SUAV+1. The +1 is the node necessary to represent the control station for the UAVs. val(motion) needs to point to the actual scenario motion file that writeConfigFile.m created for ns. For the nis scenarios this would be nis-ns2_GOD.motion, for example. val(traffic) similarly needs to point to the file containing the network data traffic information. In order to simulate GT UAV Research Facility traffic m0m1.traffic can be used.