Same as step 2 in section 11.1 with the exception that you must issue a ”qmake inet.pro” instead of ”qmake inetNoTcp.pro”. Then change working path to $OTWLAN/otwlan/otcp and do the usual “qmake;make clean;make”.
Step 3 Build bin/otwlan
Do a “cd $OTWLAN/otwlan/src” and execute the sequence “qmake “CONFIG+=usetcp”
otwlan.pro; make clean; make”.
Step 4, 5, 6
Identical to the steps 4 to 6 in section 11.1.
11.3 Running the First Time
oTWLAN remembers its setting across sessions and this information in stored in a file. This function uses the Qt class QSettings which stores information under “$HOME/.config” on Linux.
We have assigned the organisation name gosikt and the application name otwlan. The absolute file name then becomes $HOME/.config/gosikt/otwlan.conf.
The first time the program starts this file is missing and you are requested to give some addition information. Set the project directory to $OTWLAN/otwlan and the simulation directory to
$OTWLAN/otwlan/examples/myfirstrun. The latter is a simple two node network that should run immediately without any additional configurations. Use the oTWLAN menu “Setting->Show” to inspect your configuration variables.
Figure 11.1 shows the variables specified by the otwlan.conf file. The [project].home must point to the $OTWLAN/otwlan because the program must have access to the files in the directory
$OTWLAN/otwlan/nedFiles. The simulationHomeDirectory should point to a valid simulator input data set as explained in chapter 5. However, wrong setting is not fatal. The program starts with an empty playground. Use “Project->Open” to open a valid data set.
FFI-rapport 2009/00911 111
Figure 11.1 The content of the otwlan.conf. A copy is supplied under $OTWLAN/otwlan.
12 Conclusions and Remarks
The oTWLAN software is developed under the FFI-project Fundamental Technologies and Trends in Information Security (GOSIKT) and is the first step towards developing a simulator that shall model NATO PKI in the tactical domain where the network nodes must rely on radio based communication with limited transmission capacity.
Model validation. Much effort has been made to validate the simulator. Chapter 9 simulated some scenarios where analytical expressions are available. Here we compared simulated results and theoretical results. As we progress towards multihop networks in chapter 10, analytical results become unavailable and the strategy was to gradually increase the complexity with the objective to detect abnormalities.
Scenario initialization. A common pitfall is not to initialise the simulation scenario correctly.
oTWLAN provides a set of graphical editors by which the user configure the simulator’s input data. These editors make some consistency checks and produce XML files that are processed by simulator kernel upon start. Practical experience has shown that the run-time checks done in the kernel catches most of the inconsistencies in the input data. However, they are trapped by
assert()-statement. This may be inconvenient for inexperienced users but was a shortcut we had to take due to lack of programming resources. Upon termination, oTWLAN produces a file
containing a set of counters, which is sampled data per node basis. Counters showed to be an
112 FFI-rapport 2009/00911
effective tool to detect erroneous setting of the input data. For example, if node N0, say, detects many CRC errors despite the fact it should not, this may indicate inappropriate setting of the power level in the network.
Output data analysis. Many simulators have no tools to do statistical analyses and some studies have pointed out that this is a practical problem [4,24]. By means of the open source project oProbe [2], oTWLAN inserts probe objects in the program code. These probes collect samples and perform data analysis of steady-state performance at run-time. The simulation process terminates automatically when the desired accuracy is reached. oTWLAN is an infinite horizon simulator, that is, we suppose as the simulator runs longer and longer, a limiting steady-state distribution independent of the initial state exists. If the transient period is set too short, biased results are produced. However, the statistical analysis package implemented tests the sampled data for correlation and automatically prolong the run length until a predefined upper limit is reached.
This technique solves the problem with correlated samples but also makes the simulator less sensitive to short setting of the transient period.
Software quality assurance. The source code has been compiled with “warn all” enabled and all warnings have been corrected. Memory leaks and use of un-initialised variables have been detected by means of valgrind. We have extensively used the assert()-statement in our code to detect fatal software errors as early as possible since this disburdens the debugging process. It also prevents producing simulation results from inconsistent or erroneous input data. When simulating a complex scenario, it is often impossible to detect errors in the simulator’s input data from the output data.
Object-oriented modelling. RF communication is modelled according to the real world where a wave propagates through air and experience a pathloss depending on the distance. All incoming RF waves to a receiver go through comprehensive analysis where interference, background noise and the air frame section considered determine the next receiver state. The benefit of this
approach is a good emulation of a real scenario. The drawback is a higher computational cost and networks larger than 200 nodes may run slowly depending on the connectivity.
Why not NS-2? The most used simulator in MANET research is NS-2 [27]. Some of the project team members have experience with the NS-2 and found it more attractive to develop a new simulator rather than modifying the NS-2 software. The focus for our research is MANETs for the military tactical domain where both the protocols and the radio solutions differ from what is modelled in NS-2. NS-2 also has some shortcomings with regard to structure. For example, NS-2 has no module concept as OMNeT++. The concept of modules appeared to be an efficient tool for structuring the simulator.
FFI-rapport 2009/00911 113