TICTOC1

The first simulation tutorial is tictoc1. a network that consists of two nodes. One of the nodes will create a packet, and the two nodes will keep passing the same packet back and forth. We'll call the nodes "tic" and "toc".

These are the steps for Tictoc1:

i. Firstly, create a new Omnet++ Project named tictoc1. ii. Then, create a topology file named tictoc1.ned. A topology file is a text file that identifies the

network's nodes and the links between them.

This code will be read from bottom up. Let’s translate this code.

Tictoc1 is a network, which is assembled from two submodules, tic and toc. tic and

toc are instances of the same module type called Txc1. We connect tic's output gate

(named out) to toc's input gate (named in), and vica versa. There will be a 100ms

propagation delay both ways.

Txc1 is a simple module type. Txc1 has one input gate named in, and one output

gate named out (simple ... { ... }).

iii. Then, implement the functionality of the simple module Txc1. The file name is txc1.cc

From this code, we can say that:

In initialize() we create a message object (cMessage), and send it out on gate out.

Since this gate is connected to the other module's input gate, the simulation kernel

will deliver this message to the other module in the argument to handleMessage(),

after a 100ms propagation delay assigned to the link in the NED file. The other

module just sends it back (another 100ms delay), so it will result in a continuous

ping-pong.

iv. Then, create a file named omnetpp.ini

v. After complete all the steps above, run the simulation. Press the run button to start the

simulation.

TICTOC2 (REFINING THE GRAPHICS, AND ADDING DEBUGGING OUTPUT)

In tictoc2 we will learn how to make the model look prettier in the GUI. We assign the "block/routing"

icon and paint it cyan for tic and yellow for toc. This is achieved by adding display strings to the NED file.

These are the steps:

i. Create a topology file named tictoc2.ned

ii. Create another file named txc2.cc

iii. Then, create a file named omnetpp.ini. After complete all the steps, launch the simulation.

Press the run button to start the simulation.

TICTOC3 (ADDING STATE VARIABLES)

In this step we add a counter to the module, and delete the message after ten exchanges.

These are the steps:

i. Firstly, create a topology file named tictoc3.ned

ii. Then, create a file named txc3.cc. We set the variable to 10 in initialize() and decrement in

handleMessage(), that is, on every message arrival. After it reaches zero, the simulation will

run out of events and terminate.

iii. Create another file named omnetpp.ini. After complete all the steps, launch the simulation.

Press the run button to start the simulation.

iv. Double-click on tic's icon, then choose the Contents page from the inspector window that

pops up. As you continue running the simulation, you can follow as the counter keeps

decrementing until it reaches zero.

TICTOC4 (ADDING PARAMETERS)

In this step you'll learn how to add input parameters to the simulation: we'll turn the "magic number" 10

into a parameter and add a boolean parameter to decide whether the module should send out the first

message in its initialization code (whether this is a tic or a toc module).

These are the steps:

i. Create a NED file named tictoc4.ned. Module parameters have to be declared in the NED

file. The data type can be numeric, string, bool, or xml.

ii. Create a file named txc4.cc

iii. Then, create another file named omnetpp.ini. Note that because omnetpp.ini supports

wildcards, and parameters assigned from NED files take precedence over the ones in

omnetpp.ini, we could have used Tictoc4.t*c.limit=5 or Tictoc4.*.limit=5 or **.limit=5 with

the same effect. The difference between * and ** is that * will not match a dot and ** will.

iv. Launch the simulation. Press the run button to start the simulation.

TICTOC5 (MODELING PROCESSING DELAY)

If we take a closer look at the NED file we will realize that tic and toc differs only in their parameter

values and their display string. We can create a new simple module type by inheriting from another one

and specifying or overriding some of its parameters. In our case we will derive two simple module types

(Tic and Toc). Later we can use these types when defining the submodules in the network.

i. Hold messages for some time before sending it back timing is achieved by the module

sending a message to itself (i.e., self-messages)

ii. We "send" the self-messages with the scheduleAt() function

iii. handleMessage(): differentiate whether a new message has arrived via the input gate or the

self-message came back (timer expired)

TICTOC6 (MODELING PROCESSING DELAY)

In the previous models, tic and toc immediately sent back the received message. Here we'll add some

timing: tic and toc will hold the message for 1 simulated second before sending it back. In OMNeT++

such timing is achieved by the module sending a message to itself. Such messages are called self-

messages (but only because of the way they are used, otherwise they are ordinary message objects).

These are the steps:

i. Create a NED file named tictoc6.ned

ii. Create a file named txc6.cc. We added two cMessage * variables, event and tictocMsg to the

class, to remember the message we use for timing and message whose processing delay we

are simulating.

iii. Then, create another file named omnetpp.ini. After complete all the steps, launch the

simulation. Press run button to start the simulation.

TICTOC7 (RANDOM NUMBERS AND PARAMETERS)

In this step we'll introduce random numbers. We change the delay from 1s to a random value which can

be set from the NED file or from omnetpp.ini. Module parameters are able to return random variables,

however, to make use of this feature we have to read the parameter in handleMessage() every time we

use it.

These are the steps:

i. Create a NED file named tictoc7.ned

ii. Create a file named txc7.cc

iii. Then, create an omnetpp.ini file. We'll assign the parameters in omnetpp.ini. You can try

that no matter how many times you re-run the simulation, you'll get exactly the same

results. This is because OMNeT++ uses a deterministic algorithm to generate random

numbers, and initializes it to the same seed. This is important for reproducible simulations.

iv. After complete all the steps, launch the simulation.

TICTOC8 (TIMEOUT, CANCELLING TIMERS)

In order to get one step closer to modelling networking protocols, let us transform our model into a

stop-and-wait simulation. This time we'll have separate classes for tic and toc. The basic scenario is

similar to the previous ones: tic and toc will be tossing a message to one another. However, toc will

"lose" the message with some nonzero probability, and in that case tic will have to resend it.

These are the steps:

i. Create a file named tictoc8.ned

ii. Then create another file named txc8.cc. The function of bubble() call in the code is toc'll

display a callout whenever it drops the message. So, tic will start a timer whenever it sends

the message. When the timer expires, we'll assume the message was lost and send another

one. If toc's reply arrives, the timer has to be cancelled.

iii. Then, create omnetpp.ini file. Launch the simulation.

TICTOC9 (RETRANSMITTING THE SAME MESSAGE)

In this step we refine the previous model. There we just created another packet if we needed to

retransmit. This is OK because the packet didn't contain much, but in real life it's usually more practical

to keep a copy of the original packet so that we can re-send it without the need to build it again. What

we do here is keep the original packet and send only copies of it. We delete the original when toc's

acknowledgement arrives. To make it easier to visually verify the model, we'll include a message

sequence number the message names. In order to avoid handleMessage() growing too large, we'll put

the corresponding code into two new functions, generateNewMessage() and sendCopyOf() and call

them from handleMessage().

These are the steps:

i. Create a file named tictoc9.ned

ii. Create a file named txc9.cc

iii. Lastly, create omnetpp.ini. Then, launch the simulation.

TICTOC10 (MORE THAN TWO NODES)

Now we'll make a big step: create several tic modules and connect them into a network. For now, we'll

keep it simple what they do: one of the nodes generates a message, and the others keep tossing it

around in random directions until it arrives at a predetermined destination node.

i. Create a file named tictoc10.ned. The NED file will need a few changes. First of all, the Txc

module will need to have multiple input and output gates. The [ ] turns the gates into gate

vectors. The size of the vector (the number of gates) will be determined where we use Txc

to build the network. Here we created 6 modules as a module vector, and connected them.

ii. Create a file named txc10.cc. In this version, tic[0] will generate the message to be sent

around. This is done in initialize(), with the help of the getIndex() function which returns the

index of the module in the vector. The meat of the code is the forwardMessage() function

which we invoke from handleMessage() whenever a message arrives at the node. It draws a

random gate number (size() is the size of the gate vector), and sends out message on that

gate. When the message arrives at tic[3], its handleMessage() will delete the message.

iii. Create omnetpp.ini file. Then, launch the simulation

TICTOC11 (CHANNELS AND INNER TYPE DEFINITIONS)

Our new network definition is getting quite complex and long, especially the connections section. Let's

try to simplify it. The first thing we notice is that the connections always use the same delay parameter.

It is possible to create types for the connections (they are called channels) similarly to simple modules.

We should create a channel type which specifies the delay parameter and we will use that type for all

connections in the network.

These are the steps:

i. Create a file named tictoc11.ned. Based on the figure below, as you have noticed we have

defined the new channel type inside the network definition by adding a types section. This

type definition is only visible inside the network. It is called as a local or inner type. You can

use simple modules as inner types too, if you wish.

ii. Then, create a file named txc11.cc

iii. Create omnetpp.ini file. After complete all the steps, launch the simulation.

TICTOC12 (USING TWO-WAY CONNECTIONS)

If we check the connections section a little more, we will realize that each node pair is connected with

two connections. One for each direction. OMNeT++ 4 supports two way connections, so let's use them.

These are the steps:

i. Firstly, create a file named tictoc12.ned. We have to define two-way (or so called inout)

gates instead of the separate input and output gates we used previously.

ii. Create a file named txc12.cc.

iii. Create an omnetpp.ini file. After complete all the steps, launch the simulation

TICTOC13 (DEFINING OUR MESSAGE CLASS)

In this step the destination address is no longer hardcoded tic[3] -- we draw a random destination, and

we'll add the destination address to the message.

These are the steps:

i. Create a file named tictoc13.ned

ii. Create another file named tictoc13.msg. The best way is to subclass cMessage and add

destination as a data member. Hand-coding the message class is usually tedious because it

contains a lot of boilerplate code, so we let OMNeT++ generate the class for us. The

message class specification is in tictoc13.msg.

iii. Create a make file named txc13.cc. The makefile is set up so that the message compiler,

opp_msgc is invoked and it generates tictoc13_m.h and tictoc13_m.cc from the message

declaration. They will contain a generated TicTocMsg13 class subclassed from cMessage; the

class will have getter and setter methods for every field.

iv. Create a file named omnetpp.ini and launch the simulation.

TICTOC14 (DISPLAYING THE NUMBER OF PACKETS SENT/RECEIVED)

These are the steps:

i. Create a file named tictoc14.ned

ii. Then, create a file named tictoc14.msg. Then, make another file named txc14.cc. To get an

overview at runtime how many messages each node sent or received, we've added two

counters to the module class: numSent and numReceived.

iii. Create an omnetpp.ini file and launch the simulation.

TICTOC15 (ADDING STATISTICS COLLECTION)

The previous simulation model does something interesting enough so that we can collect some

statistics. For example, you may be interested in the average hop count a message has to travel before

reaching its destination. We'll record in the hop count of every message upon arrival into an output

vector (a sequence of (time,value) pairs, sort of a time series). We also calculate mean, standard

deviation, minimum, maximum values per node, and write them into a file at the end of the simulation.

Then we'll use tools from the OMNeT++ IDE to analyse the output files. For that, we add an output

vector object (which will record the data into Tictoc15-0.vec) and a histogram object (which also

calculates mean, etc) to the class.

These are the steps:

i. Create tictoc15.ned file and tictoc15.msg. Then, create another file named txc15.cc.

hopCountVector.record() call writes the data into Tictoc15-0.vec. With a large simulation

model or long execution time, the Tictoc15-0.vec file may grow very large. To handle this

situation, you can specifically disable/enable vector in omnetpp.ini, and you can also specify

a simulation time interval in which you're interested (data recorded outside this interval will

be discarded). When you begin a new simulation, the existing Tictoc15-0.vec/sca file gets

deleted.

ii. Scalar data (collected by the histogram object in this simulation) have to be recorded

manually, in the finish() function. finish() gets invoked on successful completion of the

simulation, i.e. not when it's stopped with an error. The recordScalar() calls in the code

below write into the Tictoc15-0.sca file.

iii. Create omnetpp.ini file and launch the simulation. You can also view the data during

simulation. In the module inspector's Contents page you'll find the hopCountStats and

hopCountVector objects, and you can open their inspectors (double-click). They will be

initially empty -- run the simulation in Fast (or even Express) mode to get enough data to be

displayed.

TICTOC16 (STATISTIC COLLECTION WITHOUT MODIFYING YOUR MODEL)

We will re-write the statistic collection introduced in the last step to use signals. First of all, we can

safely remove all statistic related variables from our module. There is no need for the cOutVector and

cLongHistogram classes either. We will need only a single signal that carries the hopCount of the

message at the time of message arrival at the destination.

These are the steps:

i. Create tictoc16.msg and txc16.cc. We need to define our signal. The arrivalSignal is just

an identifier that can be used later to easily refer to our signal. Besides, we must register all

signals before using them. The best place to do this is the initialize() method of the

module.

ii. The last step is that we have to define the emitted signal also in the NED file. Declaring

signals in the NED file allows you to have all information about your module in one place.

You will see the parameters it takes, its input and output gates, and also the signals and

statistics it provides.

iii.

Now we have just realized that we would like to see a histogram of the hopCount on the

tic[1] module. On the other hand we are short on disk storage and we are not interested

having the vector data for the first three module tic 0,1,2. No problem. We can add our

histogram and remove the unneeded vector recording without even touching the C++ or

NED files. Just open the INI file and modify the statistic recording.

iv. Then, launch the simulation

CONCLUSIONS

• OMNeT++: discrete event simulation system

• OMNeT++ is a

– public-source,

– component-based,

– modular and open-architecture simulation environment

– with strong GUI support and

– an embeddable simulation kernel