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. ii. Firstly, create a new Omnet++ Project named tictoc1. 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 OUTPUT) (REFINING THE GRAPHICS, AND ADDING DEBUGGING 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. iii. We "send" the self-messages with the scheduleAt() function 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 Tictoc150.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 MODEL) (STATISTIC COLLECTION WITHOUT MODIFYING YOUR 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