fields:
double txPowerDbm; // Radiated power in dBm with which this packet is transmitted.
double rxPowerDbm; // Power in dBm at the receiver antenna input double rxPowerW; // rxPowerDbm converted to W
double duration; // Time it takes to transmit the packet, in seconds!
double startedAt; // The time instance the wave reached the receiver antenna.
int srcNode; // The host identifier (>= 0) that sends this packet.
};
Figure 6.13 The attributes of the RF wave. The transmitter inserts the txPowerDbm while the channel control calculates the rxPower.
7 Tips and Tricks
This chapter offers a number of hints about the practical usage of oTWLAN.
7.1 Sanity Checks of the Input and Output Data
Sanity checks of the output data are to inspect a number of output files with the objective to find errors, either in the software or the input data files. One aid we have is the counters explained earlier in this document (cf. the OMNeT++ term scalars). A counter is a simple variable within the source code that counts something, e.g., a variable is incremented whenever a packet is lost, or a broadcast is received. The simulator has implemented many counters and they are written into the file counters_r1. The file name is tagged by the session run number it belongs to - “_r1”
in the example name emphasis that the file is an output from run number 1. Consider the three-node chain in Figure 7.1.
node 0 node 1 node 2
g1: pattern 0 -> 2
Figure 7.1 A chain of three nodes with one active traffic generator. The generator sends packets from end source 0 to end destination 2, and does not request use of ARQ.
Here is the output from the counters within the LLC layer:
sim.host[0].nic.llc::L2_LlcLayer:noOfSDUsReceived = 6000
72 FFI-rapport 2009/00911
This network is configured to have radio channels with an excellent SNR level and the offered traffic is far below the throughput capacity. Thus packet loss shall not occur. The counters confirm the following important facts about the network:
- node 2 shall only receive PDUs and no SDUs since its 3a layer shall not send data - node 0 shall only receive SDUs and no PDUs since the only traffic generator we have is
in node 0
- node 1 shall receive both SDUs and PDUs, and the numbers shall be identical.
- none of the nodes shall receive acknowledgement packets
The latter bullet is obvious because ARQ is disabled. However, a frequent cause of errors is incorrect setting of the traffic generators and additional checks against the counters often discover errors in the simulator’s input data. Additional aid you can use before starting the simulator’s kernel thread is the status widgets in Figure 7.2.
Figure 7.2 The XML Input File Status widget is activated by the meny ”View->XML File Status”.
7.2 How to simulate without the GUI part
We have so far described simulation runs from the GUI front-end where a single network scene is taken from a single setup directory. Often we have many different network scenes to simulate, and typically we want to start a bunch of simulations at Friday to have the results ready at Monday morning. Batch simulation without use of the GUI is possible when each network scene is specified in separate setup-directories. If you run the simulator as a console application (class GUI_SimWithoutGui) using the runSet and simDir arguments below then the program starts without the GUI:
yourBinName -runSet yourRunSet -simDir fullPathToSimulationHomeDirectory The yourRunSet confirms to the OMNeT++ syntax (1-5, 1,2,4, etc).
Assume you want to estimate throughput as function of the offered traffic at the three different power levels: {1W, 2W, 3W}. Then use the GUI front-end to create a home directory named
FFI-rapport 2009/00911 73
power1W, specify the offered traffic (run set 1 to 7), specify the other data and set the transmitting power to 1W. Copy this directory to two new directories named power2W and power3W, and set the transmitting power to 2W and 3W, respectively. Then you open a console/xterm window and writes24:
yourBinName - runSet 1-7 -simDir /home/tore/simulations/power1W yourBinName - runSet 1-7 -simDir /home/tore/simulations/power2W yourBinName - runSet 1-7 -simDir /home/tore/simulations/power3W
The outputs will be placed in power1W/output, power2W/output, power3W/output, respectively.
7.3 How to remove the GUI software
This situation occurs if you want to remove the GUI software (remember that simulation without the GUI is possible). Figure 7.3 shows the software dependency graph and we suggest that you start to remove the cpp-files prefixed by GUI. Use the compiler to determine the next steps.
OMNeT++
INET
Qt
oTWLAN kernel oTWLAN GUI
graphviz
oProbe oTCP
Figure 7.3 Software dependency graph. oTCP is an optional module.
7.4 How to remove the kernel part
This situation occurs if you want to reuse the source code that implements the input data editors.
We suggest you start out with the class GUI_MainWindow as basis for your software. KDevelop users shall establish a new project of the type <C++><QMake project><Qt4 Application> and create an object for the GUI_MainWindow in the main.cpp as we have in our source code. Then use the compiler to resolve missing classes and modify the code to prevent dependency of the class oProbe::OMNET_Thread.
24 Hint: Use a text editor to do a copy/paste into the console window, or write a script.
74 FFI-rapport 2009/00911