TICTOC1The 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. Create a topology file named tictoc2.ned ii. Create another file named txc2. AND ADDING DEBUGGING In tictoc2 we will learn how to make the model look prettier in the GUI.cc .TICTOC2 OUTPUT) (REFINING THE GRAPHICS. These are the steps: i. 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. ini. create a topology file named tictoc3. create a file named omnetpp. TICTOC3 (ADDING STATE VARIABLES) In this step we add a counter to the module. After complete all the steps. Then. launch the simulation.iii. and delete the message after ten exchanges. Press the run button to start the simulation. Firstly.ned . These are the steps: i. ii.cc. After it reaches zero. iii. create a file named txc3.ini. We set the variable to 10 in initialize() and decrement in handleMessage(). on every message arrival. the simulation will run out of events and terminate. . Press the run button to start the simulation. Create another file named omnetpp. launch the simulation. Then. that is. After complete all the steps. you can follow as the counter keeps decrementing until it reaches zero.ned. bool. string.iv. These are the steps: i. Double-click on tic's icon. or xml. As you continue running the simulation. Create a NED file named tictoc4. The data type can be numeric. then choose the Contents page from the inspector window that pops up. Module parameters have to be declared in the NED file. 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). . ini supports wildcards.ini. Create a file named txc4. The difference between * and ** is that * will not match a dot and ** will. and parameters assigned from NED files take precedence over the ones in omnetpp.t*c. Press the run button to start the simulation.*. Then. we could have used Tictoc4. .limit=5 or Tictoc4. Note that because omnetpp. create another file named omnetpp.limit=5 or **.ini.ii. iv.cc iii. Launch the simulation.limit=5 with the same effect. i.e. Hold messages for some time before sending it back timing is achieved by the module sending a message to itself (i. Later we can use these types when defining the submodules in the network.. 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).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. 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) . cc. to remember the message we use for timing and message whose processing delay we are simulating. event and tictocMsg to the class. tic and toc immediately sent back the received message. Create a NED file named tictoc6. In OMNeT++ such timing is achieved by the module sending a message to itself. Create a file named txc6.TICTOC6 (MODELING PROCESSING DELAY) In the previous models. These are the steps: i. . We added two cMessage * variables. otherwise they are ordinary message objects).ned ii. Here we'll add some timing: tic and toc will hold the message for 1 simulated second before sending it back. Such messages are called self-messages (but only because of the way they are used. These are the steps: i. to make use of this feature we have to read the parameter in handleMessage() every time we use it. Press run button to start the simulation.ini. Then. After complete all the steps. create another file named omnetpp. TICTOC7 (RANDOM NUMBERS AND PARAMETERS) In this step we'll introduce random numbers. Module parameters are able to return random variables.iii. however. Create a NED file named tictoc7.ned . launch the simulation. We change the delay from 1s to a random value which can be set from the NED file or from omnetpp.ini. you'll get exactly the same results. Then. We'll assign the parameters in omnetpp. Create a file named txc7.cc iii.ii. You can try that no matter how many times you re-run the simulation. This is important for reproducible simulations.ini file. This is because OMNeT++ uses a deterministic algorithm to generate random numbers. and initializes it to the same seed. create an omnetpp.ini. . The basic scenario is similar to the previous ones: tic and toc will be tossing a message to one another. This time we'll have separate classes for tic and toc. After complete all the steps. launch the simulation. TICTOC8 (TIMEOUT. CANCELLING TIMERS) In order to get one step closer to modelling networking protocols. When the timer expires. However.ned ii. So. toc will "lose" the message with some nonzero probability. we'll assume the message was lost and send another one.cc. Then create another file named txc8. tic will start a timer whenever it sends the message. Create a file named tictoc8.iv. The function of bubble() call in the code is toc'll display a callout whenever it drops the message. the timer has to be cancelled. If toc's reply arrives. let us transform our model into a stop-and-wait simulation. . These are the steps: i. and in that case tic will have to resend it. We delete the original when toc's acknowledgement arrives. 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. TICTOC9 (RETRANSMITTING THE SAME MESSAGE) In this step we refine the previous model. create omnetpp. To make it easier to visually verify the model. Launch the simulation. we'll put the corresponding code into two new functions. In order to avoid handleMessage() growing too large. This is OK because the packet didn't contain much. we'll include a message sequence number the message names. Then. What we do here is keep the original packet and send only copies of it.iii. generateNewMessage() and sendCopyOf() and call them from handleMessage().ini file. These are the steps: . There we just created another packet if we needed to retransmit. .cc iii. Create a file named tictoc9. launch the simulation. Lastly. Then. create omnetpp.ini.ned ii.i. Create a file named txc9. and connected them. For now. with the help of the . tic[0] will generate the message to be sent around. Here we created 6 modules as a module vector. Create a file named tictoc10. i. First of all. This is done in initialize(). we'll keep it simple what they do: one of the nodes generates a message. the Txc module will need to have multiple input and output gates. and the others keep tossing it around in random directions until it arrives at a predetermined destination node. The size of the vector (the number of gates) will be determined where we use Txc to build the network.ned. The [ ] turns the gates into gate vectors.cc. ii. Create a file named txc10. In this version. The NED file will need a few changes.TICTOC10 (MORE THAN TWO NODES) Now we'll make a big step: create several tic modules and connect them into a network. its handleMessage() will delete the message. Create omnetpp. The meat of the code is the forwardMessage() function which we invoke from handleMessage() whenever a message arrives at the node. launch the simulation TICTOC11 (CHANNELS AND INNER TYPE DEFINITIONS) Our new network definition is getting quite complex and long. We should create a channel type which specifies the delay parameter and we will use that type for all connections in the network. . especially the connections section. Then. iii. and sends out message on that gate. It is possible to create types for the connections (they are called channels) similarly to simple modules. It draws a random gate number (size() is the size of the gate vector). The first thing we notice is that the connections always use the same delay parameter. When the message arrives at tic[3].getIndex() function which returns the index of the module in the vector. Let's try to simplify it.ini file. ned. Based on the figure below.ini file.cc iii. You can use simple modules as inner types too. Then. Create a file named tictoc11. ii. as you have noticed we have defined the new channel type inside the network definition by adding a types section. create a file named txc11. It is called as a local or inner type. .These are the steps: i. launch the simulation. After complete all the steps. Create omnetpp. if you wish. This type definition is only visible inside the network. One for each direction. create a file named tictoc12. These are the steps: i.TICTOC12 (USING TWO-WAY CONNECTIONS) If we check the connections section a little more. Create a file named txc12. ii. .cc. Firstly. we will realize that each node pair is connected with two connections. so let's use them.ned. OMNeT++ 4 supports two way connections. We have to define two-way (or so called inout) gates instead of the separate input and output gates we used previously. we draw a random destination. These are the steps: i. After complete all the steps.ini file.iii.ned . launch the simulation TICTOC13 (DEFINING OUR MESSAGE CLASS) In this step the destination address is no longer hardcoded tic[3] -. Create a file named tictoc13. and we'll add the destination address to the message. Create an omnetpp. cc. iii. iv.ini and launch the simulation. so we let OMNeT++ generate the class for us. Create a make file named txc13.ii. opp_msgc is invoked and it generates tictoc13_m. The best way is to subclass cMessage and add destination as a data member. Create a file named omnetpp.msg. The makefile is set up so that the message compiler. They will contain a generated TicTocMsg13 class subclassed from cMessage.msg. Hand-coding the message class is usually tedious because it contains a lot of boilerplate code. the class will have getter and setter methods for every field. The message class specification is in tictoc13. .h and tictoc13_m. Create another file named tictoc13.cc from the message declaration. Create a file named tictoc14. Then. create a file named tictoc14. To get an overview at runtime how many messages each node sent or received.ini file and launch the simulation. iii.TICTOC14 (DISPLAYING THE NUMBER OF PACKETS SENT/RECEIVED) These are the steps: i. TICTOC15 (ADDING STATISTICS COLLECTION) .cc.msg.ned ii. we've added two counters to the module class: numSent and numReceived. Create an omnetpp. Then. make another file named txc14. sort of a time series).ned file and tictoc15. For example. When you begin a new simulation. We'll record in the hop count of every message upon arrival into an output vector (a sequence of (time. Then.ini. The recordScalar() calls in the code below write into the Tictoc150. you can specifically disable/enable vector in omnetpp. For that. ii. in the finish() function. and you can also specify a simulation time interval in which you're interested (data recorded outside this interval will be discarded). create another file named txc15. minimum. To handle this situation. hopCountVector. i. and write them into a file at the end of the simulation. Create tictoc15. not when it's stopped with an error.vec) and a histogram object (which also calculates mean.sca file. the Tictoc15-0.vec. These are the steps: i.e.vec/sca file gets deleted.cc. etc) to the class. . With a large simulation model or long execution time.record() call writes the data into Tictoc15-0. finish() gets invoked on successful completion of the simulation. you may be interested in the average hop count a message has to travel before reaching its destination. we add an output vector object (which will record the data into Tictoc15-0. the existing Tictoc15-0.value) pairs.vec file may grow very large.The previous simulation model does something interesting enough so that we can collect some statistics. Scalar data (collected by the histogram object in this simulation) have to be recorded manually.msg. maximum values per node. We also calculate mean. standard deviation. Then we'll use tools from the OMNeT++ IDE to analyse the output files. iii. and you can open their inspectors (double-click). There is no need for the cOutVector and cLongHistogram classes either. In the module inspector's Contents page you'll find the hopCountStats and hopCountVector objects. They will be initially empty -. we can safely remove all statistic related variables from our module.ini file and launch the simulation. First of all.run the simulation in Fast (or even Express) mode to get enough data to be displayed. Create omnetpp. TICTOC16 MODEL) (STATISTIC COLLECTION WITHOUT MODIFYING YOUR We will re-write the statistic collection introduced in the last step to use signals. We will . You can also view the data during simulation. and also the signals and statistics it provides. These are the steps: i. we must register all signals before using them. ii. The last step is that we have to define the emitted signal also in the NED file. We need to define our signal.msg and txc16. . Besides. its input and output gates.need only a single signal that carries the hopCount of the message at the time of message arrival at the destination.cc. The best place to do this is the initialize() method of the module. The arrivalSignal is just an identifier that can be used later to easily refer to our signal. Create tictoc16. 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. No problem.iii.2. Just open the INI file and modify the statistic recording. Then. Now we have just realized that we would like to see a histogram of the hopCount on the tic[1] module. We can add our histogram and remove the unneeded vector recording without even touching the C++ or NED files. 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. iv.1. launch the simulation . – modular and open-architecture simulation environment – with strong GUI support and – an embeddable simulation kernel . – component-based.CONCLUSIONS • OMNeT++: discrete event simulation system • OMNeT++ is a – public-source.