POLITECNICO DI TORINO

Computer network design

Omnet++ laboratories
Academic year 2014/15

Paolo Giaccone
Version: January 7, 2015
c 2014

Contents
1 Laboratory #1
1.1 Starting the lab . . . . . . . .
1.2 Overview of shell commands
1.3 Tasks . . . . . . . . . . . . .
1.4 Ending the lab . . . . . . . .
1.5 Persistent file system . . . . .

3
3
3
4
5
5

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

2 Laboratory #2
2.1 Methodology . . . . . . . . . .
2.2 The M/M/1 model . . . . . . . .
2.2.1 Code development . . .
2.2.2 NED file . . . . . . . . .
2.2.3 Simple modules in C++
2.2.4 Configuration file . . . .
2.3 Tasks . . . . . . . . . . . . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

6
. 6
. 6
. 6
. 7
. 7
. 10
. 10

3 Laboratory #3
3.1 Transmission on a communication channel .
3.2 Tasks . . . . . . . . . . . . . . . . . . . . . .
3.3 Parametric study when running the simulation
3.4 Simulation results . . . . . . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

12
12
12
13
13

4 Laboratory #4
16
4.1 Scheduling policies of Internet traffic . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5 Laboratory #5
18
5.1 Go-back-N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6 Laboratory #6
20
6.1 ALOHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.3 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter 1

Laboratory #1
Aim of this lab is to become familiar with Linux environment and to start the Tictoc tutorial in
Omnet++.

1.1 Starting the lab

To access the lab, you must follow the following steps:
1. Login on the Windows PC, available at any LAIB, with the official Politecnico credentials
(sMATRICOLA@studenti.polito.it)
2. Start a browser, visit https://vdilinux.polito.it/ and click on User portal
3. Authenticate using your official account with username sMATRICOLA and the corresponding password. Leave polito.it as domain name.
4. The virtual machine to run is conede (and not ubu). Click on the green arrow (Run VM)
below conede virtual machine
5. Double click on the VM and click on Apri (bottom). Now choose Selezionare il programma da un elenco di programmi installati in the launcher and select VirtViewer
desktop client.
6. Enjoy linux.
If needed, both username and password in Linux are corso.

1.2 Overview of shell commands

As preliminary requirement, you must be familiar with the text editor gedit (left command bar)
and with basic terminal commands, available when clicking on Terminal (left command bar).
The most useful terminal commands are reported in the following list. The student is recommended to revise each of them.
1. ls to list folder contents. E.g. ls -lrt
2. cd to change directory. E.g. cd Mycode
3. cp to copy files and directory. E.g. cp -r Mycode /mount/backup
3

4. mv to move or rename files/directories. E.g. mv Dummy MM1

5. mkdir to create a directory. E.g. mkdir draft code
6. rm and rmdir to remove files and/or directories. E.g. rm -rf draftcode
7. gedit to edit a file. E.g. gedit tx1.cc
8. man to get the manual of a command. E.g. man ls
9. > to redirect the standard output of a process. E.g. ./Tictoc > sim.out
10. cat to print the file content. E.g. cat sim.out
11. less to show the file content with up/down scrolling capabilities. E.g. less sim.out
12. grep to select all the lines matching a given pattern. E.g. grep SAMPLE sim.out
13. command1 | command2 to pipeline the output of command1 to the input of command2.
E.g. cat sim.out | grep SAMPLE
14. zip to compress files and directories into a single file E.g. zip -r backup.zip Mycode
Hint: Use the tab key to complete file names.

1.3 Tasks
1. Open the Tictoc tutorial documentation on Firefox, with the link available in the bookmark
toolbar
2. Create a new directory Mycode/Lab1 to develop your code. A local copy of the code for
the tutorial is also available under Mycode/Tictoc.
3. Follow word-by-word the instructions 1. Getting started and 2. Enhancing the 2-node
TicToc, from step 1 to step 7. Do not proceed further unless you have already finished
with all the required tasks.
4. What is the variable/method to retrieve the current simulation time?
5. What is the difference between normal mode and express mode for running the simulations?
6. How is it possible to evaluate the delay experienced by a message just received? (hint:
find the proper method within cMessage class)
7. Any time a message is received by a module, use EV << . . . <<endl in the C++ code
to log (in the same line): the current simulation time, the cumulative number of messages
received by the module and the current delay experienced by the message. What is the
code to implement such logging system? Where are these log messages visible?
8. How is it possible to run one simulation directly in the command line? In this case, how
is it possible to show EV on the standard output? (hint: see Sec.10.2 and then disable
express mode as in Sec.24.1).
9. Modify the code to simulate 4 nodes connected with a unidirectional cycle topology and
the message sent along the cycle. Show the corresponding ned file.
10. How is it possible to set a maximum simulation time in omnetpp.ini?
4

1.4 Ending the lab

1. Backup: Since the VM looses any new file when rebooted, it is mandatory to backup all
the source files and data at the end of the class on the network filesystem. Follow
the instructions in Sec. 1.5 to create and manage a permanent storage.
2. Logout: At the end of the backup, you must shutdown the VM and logout from the VM
User portal.

1.5 Persistent file system

The local file system is not permanent and will be completely cleared after rebooting the VM.
To access a permanent storage, available on a network file system, you can do the following:
1. Open the file manager (Nautilus) - home folder, on your top-left. If you click with the
middle key, you can open multiple instances of Nautilus.
2. Double click on link CoNeDe (Computer Network Design)
3. Use as login credential: Username: s0X (with X being your matricola) (without @polito.it
or @studenti.polito.it), Domain: POLITO.IT (in capital letters), Password: usual one to
access the Windows PC. Suggested option: Remember forever.
4. If asking for key-ring credentials, use corso as password.
5. With Nautilus, create a new folder with the name SX (with X being your matricola). If
you prefer the command line, you can access the NFS mounted under /.gvfs/conede/
6. Copy all your local files to your NFS folder. Symbolic links will not be copied, but do not
worry about this issue.
7. Check that all the files have been copied as expected.
8. From the host Windows PC, it is possible to mount CoNeDe network file system (using
the same credential above) and copy to an external usb storage.
Note that an alternative possibility is to exploit some web email access (i.e. by sending an
email to yourself) or web storage (as Dropbox) to backup all your work, directly from Firefox.

Chapter 2

Laboratory #2
Aim of this laboratory is to code completely the model of an M/M/1, to learn how to collect
simulation samples and to analyze them at the end of the simulation.

2.1 Methodology
To design the simulator and code quickly it, we recommend to follow exactly this sequence of
steps:
Step 1. Define the ned file to describe the composition of modules to build the network
and their parameters.
Step 2. Define the cc files to code each simple module.
Step 3. Define the ini file.
Step 4. Run and debug the simulator. If needed, reviconsider the previous steps.

2.2 The M/M/1 model

Consider a continuous time M/M/1 queueing model, i.e. with Poisson arrivals and a single
server with exponential distributed service times. The input parameters are the average
interArrivalTime (measured in s) and the average serviceTime (measured in s). The
main performance metrics to compute are
the basic statistics (average, minimum, maximum, standard deviation) of the total delay
the average arrival rate, throughput and loss probability
the temporal evolution of the queue size and of the packet delay

2.2.1

Code development

Before starting the actual coding, create a new directory inside Mycode, called MM1.
1
2
3

cd /Mycode/
mkdir MyMM1
cd MyMM1

As preliminary task, develop the simulator. You can use the following examples as initial
version of the code.
6

2.2.2

NED file

Create a single ned file mm1.ned based on the template dummy.ned and define:
the composition of the network model in terms of simple modules
the parameters and gates for each simple module
One possible solution could be the following.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

// *** mm1.ned ***

simple Generator {
parameters:
volatile double interArrivalTime; // sec
@display("i=block/source");
gates:
output out;
}
simple Queue {
parameters:
volatile double serviceTime; // sec
@display("i=block/queue");
gates:
input in;
output out;
}
simple Sink {
parameters:
@display("i=block/sink");
gates:
input in;
}
network MM1 {
submodules:
gen: Generator;
queue: Queue;
sink: Sink;
connections:
gen.out --> queue.in;
queue.out --> sink.in;
}

2.2.3

Simple modules in C++

Create one .cc file for each simple module using dummy.cc as template. It is recommended to
substitute the word Dummy within each cc file with the name of the class, either by using the
string replacement of gedit or directly by using sed command. E.g.
1

sed s/Dummy/NewClassName/g dummy.cc > newclassName.cc

In the following we report a possible implementation of the three simple modules included in
the network.
Message generator
Hint: understand carefully how the different messages are generated.
1
2
3
4
5
6
7
8

/*** generator.cc ***/

#include <string.h>
#include <omnetpp.h>
class Generator : public cSimpleModule {
private:
cMessage *sendMsgEvent;
public:
Generator(); // constructor

9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

virtual Generator(); // destructor

protected:
virtual void initialize();
virtual void finish();
virtual void handleMessage(cMessage *msg);
};
Define_Module(Generator);
Generator::Generator() {
sendMsgEvent=NULL;
}
Generator::Generator() {
cancelAndDelete(sendMsgEvent);
}
void Generator::initialize() {
// create the "send" packet
sendMsgEvent=new cMessage("sendEvent");
// schedule the first event at random time
scheduleAt(par("interArrivalTime"), sendMsgEvent);
}
void Generator::finish() {
}
void Generator::handleMessage(cMessage *msg) {
cMessage *pkt;
simtime_t departure_time;
// create new packet
pkt = new cMessage("packet");
// sent to the output
send(pkt,"out");
// compute the new departure time
departure_time=simTime()+par("interArrivalTime");
// schedule the new packet generation
scheduleAt(departure_time, sendMsgEvent);
}

Queue
Hint: understand carefully how the messages are handled; check if all the special events
(arrival to an empty queue or services to consecutive messages) are managed correctly.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

/*** queue.cc ***/

#include <string.h>
#include <omnetpp.h>
class Queue : public cSimpleModule {
private:
// local variable
cQueue buffer;
cMessage *endServiceEvent;
simtime_t service_time;
public:
// constructor
Queue(); // constructor
virtual Queue(); // destructor
protected:
virtual void initialize();
virtual void finish();
virtual void handleMessage(cMessage *msg);
};
Define_Module(Queue);
Queue::Queue() {
endServiceEvent=NULL;
}
Queue::Queue() {
cancelAndDelete(endServiceEvent);
}
void Queue::initialize() {
endServiceEvent=new cMessage("endService");
}
void Queue::finish() {

30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

}
void Queue::handleMessage(cMessage *msg) {
cMessage *pkt;
// if msg is endServiceEvent, then
//
dequeue and send the pkt to the output
//
if another pkt is available in the buffer, then
//
start a new service
// if msg is a packet, then
//
enqueue the pkt
//
if server idling, then
//
start a new service
if (msg==endServiceEvent) {
// dequeue
pkt=(cMessage*)buffer.pop();
// send
send(pkt,"out");
if (!buffer.empty()) { // if another pkt is available
// start the service
service_time=par("serviceTime");
scheduleAt(simTime()+service_time,endServiceEvent);
}
} else { // msg is a packet
// enqueue
buffer.insert(msg);
// if the server is idling
if (!endServiceEvent->isScheduled()) {
// start the service
service_time=par("serviceTime");
scheduleAt(simTime()+service_time,endServiceEvent);
}
}
}

Packet sink
Hint: understand carefully how to record the measurements and what is the difference between
vector and scalar statistics.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

/*** sink.cc ***/

#include <string.h>
#include <omnetpp.h>
class Sink : public cSimpleModule {
private:
// online stats
cStdDev delayStats;
cOutVector delayVector;
public:
Sink(); // constructor
virtual Sink(); // destructor
protected:
virtual void initialize();
virtual void finish();
virtual void handleMessage(cMessage *msg);
};
Define_Module(Sink);
Sink::Sink() {
}
Sink::Sink() {
}
void Sink::initialize() {
delayStats.setName("TotalDelay");
delayVector.setName("Delay");
}
void Sink::finish() {
recordScalar("Ave delay",delayStats.getMean());
recordScalar("Number of packets",delayStats.getCount());
}
void Sink::handleMessage(cMessage *msg) {

// compute queueing delay

simtime_t delay=simTime() - msg->getCreationTime();
// update stats
delayStats.collect(delay);
delayVector.record(delay);
// delete msg
delete(msg);

31
32
33
34
35
36
37
38

2.2.4

Configuration file

The file omnetpp.ini sets the simulation parameters.

1
2
3
4
5
6

# omnetpp.ini
[General]
network = MM1
sim-time-limit = 100s
**.interArrivalTime=exponential(1)
**.serviceTime=exponential(1)

2.3 Tasks
After developing the simulator, you must perform the following tasks and answer to the questions:
1. Run the simulation with GUI. What is the required command line?
2. Run the simulation without GUI. What is the required command line?
3. Analyze the simulation results collected under the directory results/. What is the value
of all the simulation results collected during the simulation? What is the duration of the
simulation?
Some possible hints to analyze the results are the following:
for the scalar statistics:

1
2
3

cd results
scavetool scalar -F csv -O simula-sca.txt *sca
less simula-sca.txt

for the vector statistics:

1
2
3
4
5
6
7
8

cd results
scavetool vector -F octave -O simula-vec.oct *vec
octave
octave:1> A=load("simula-vec.oct")
octave:2> A
octave:3> t=A.vectors.X
octave:4> delay=A.vectors.MM1_sink_Delay
octave:5> plot(t,delay)

4. If the parameters in the ned were not declared as volatile, what would be the effect on
the model?
5. Let us define as the average arrival rate (in pkt/s) and (in pkt/s) as the inverse of the
average service time T (in s/pkt). Now the normalized load is defined = /. Now plot
the average delay D, as a function of 2 (0, 1], for the loads from 0.1 to 0.9 (with step
0.1) and for the loads 0.95, 0.98, 0.99.
10

6. Plot in the same graph the average delay and the theoretical average delay, the latter
computed using the well-known M/M/1 formula:
DM M 1 =

T
1

7. (optional) Modify the code to select the service time according to some other distribution available in the simulator (e.g., constant, uniform and truncnormal). Do the delays
change? How?
8. (optional) Modify the code to limit the maximum queue size to maxQueueSize pkts.
What is the effect of this parameter on the delays? Under which load condition the
performances are affected by it?

11

Chapter 3

Laboratory #3
Aim of this laboratory is to understand how to model a communication channel with a given
datarate and to understand the effect of different datarates on the transmission of packets
along a path.

3.1 Transmission on a communication channel

Consider two personal computers (PC) connected throughout an Ethernet switch, as shown
in Fig. 3.1. Packets are generated in PC1 and then forwarded to the switch, which relays the
traffic to PC2. Assume:
packets are generated in PC1 according to a Poisson process;
the packet length is fixed and equal to 125 bytes;
the transmission rate of PC1 interface is 100 Mbps. The transmission rate of the switch
interface can be one of the following values: (a) 100 Mbps, (b) 10 Mbps and (c) 1 Gbps;
the propagation delay of both channels is 1 s.
PC1

Switch

PC2

transmission_rate1

transmission_rate2

propagation_time1

propagation_time2

Figure 3.1: Ethernet network connecting two PCs

3.2 Tasks
1. Draw the simulation model in terms of basic modules and connections.
2. Define the input parameters of each module and the attributes of each connection.
3. Define in details the messages exchanged by the modules and the self-messages, specifying if they are instances or derived classes of cMessage or cPacket.
12

4. Define precisely all the main data structures adopted in each basic module.
5. Following the methodology proposed in Sec. 2.1, develop the code to simulate the system.
6. Report all the developed code (ned, cc and ini files).
7. Explain the effect of the different values of transmission rate2 on the performance,
by plotting, as a function of offered load (measured in Mbps at PC1) for each value
of transmission rate2:
(a) the overall average delay
(b) the actual offered load in Mbps by the source
(c) the throughput in Mbps measured at PC2
(d) the average and variation coefficient of the interarrival time (Cv ) seen at PC2. As
a reminder, Cv is defined as: Cv = / where is the deviation standard. Note that
Cv = 1 for an exponentially distributed random variable.
8. Are there any cases for which the arrival process at PC2 appears to be deterministic (i.e.
with almost null variance)?
As optional task, repeat the same questions as before for uniformly distributed packet size
between 64 bytes and 1518 bytes.

3.3 Parametric study when running the simulation

As hint to optimize the simulation process, it is possible to exploit the options available in
omnetpp.ini (see Sec. 9.4 of Omnet++ manual) to vary one input parameters within a set of
possible values. As example:
1
2

# omnetpp.ini
**.serviceTime=exponential(${1,2,3,4}$)

3.4 Simulation results

We provide the final graphs just as a reference for a possible solution, for the case with
100 Mbps at both links.
Figs. 3.2-3.3 report the performance results after 1s of simulation, for packet size equal to
125 bytes. Instead, Figs. 3.4-3.5 report the performance results after 10s of simulation, for
packet size uniformly distributed between 64 and 1518 bytes.

13

100
90
1000
Average delay [s]

Throughput [Mbps]

80
70
60
50
40
30

100

20
10
0

10
0

20

40
60
Offered load [Mbps]

80

100

20

40
60
Offered load [Mbps]

80

100

100

80

0.8
Cv interarrival time

Average interarrival time [s]

Figure 3.2: Throughput and delay for packet size equal to 125 bytes

60
40

0.6
0.4
0.2

20
0

0
0

20

40
60
Offered load [Mbps]

80

100

20

40
60
Offered load [Mbps]

80

100

80

100

Figure 3.3: Interarrival time for packet size equal to 125 bytes

100
90

10000
Average delay [s]

Throughput [Mbps]

80
70
60
50
40

1000

30
100

20
10
0

20

40
60
Offered load [Mbps]

80

100

20

40
60
Offered load [Mbps]

Figure 3.4: Throughput and delay for packet size uniformly distributed between 64 and
1518 bytes

14

600
0.8
Cv interarrival time

Average interarrival time [s]

700

500
400
300
200

0.6
0.4
0.2

100
0

0
0

20

40
60
Offered load [Mbps]

80

100

20

40
60
Offered load [Mbps]

80

100

Figure 3.5: Interarrival time for packet size uniformly distributed between 64 and 1518 bytes

15

Chapter 4

Laboratory #4
Aim of this laboratory is to understand the effect of basic traffic engineering policies, based on
strict priority.

4.1 Scheduling policies of Internet traffic

Two hosts are connected to a server through an Ethernet switch, as shown in Fig. 4.1. The
switch is able to support different scheduling policy. Assume that:
all the Ethernet interfaces run at 100 Mbps.
for each link, the propagation delay is 5 s.
one traffic flow is generated in H1 and directed to the server, due to a CBR (Constant Bit
Rate) application:
the packet size is fixed and equal to 125 bytes;
the offered load is offered load (in Mbps).
one traffic flow is generated in H2 and directed to the server:
each packet is generated at application layer according to a Poisson process;
the packet size is uniformly distributed between 64 and 1518 bytes;
the offered load is offered load (in Mbps), i.e. the same as the other flow.

Figure 4.1: Network topology based on a switch supporting traffic scheduling policies

16

 the traffic within the switch is transmitted to the output interface according to different
scheduling policies. Consider the following scenarios:
RR, the traffic is served according to a Round Robin policy;
SP, the traffic is served according to a Strict Priority policy, with higher priority given
to the CBR traffic flow.

4.2 Tasks
1. Draw the simulation model in terms of basic modules and connections.
2. Define the input parameters of each module and the attributes of each connection.
3. Define in details the messages exchanged by the modules and the self-messages, specifying if they are instances or derived classes of cMessage or cPacket.
4. Define precisely all the main data structures adopted in each basic module.
5. Following the methodology proposed in Sec. 2.1, develop the code to simulate the system.
6. Report all the developed code (ned, cc and ini files).
7. For each of the two scheduling policies above (RR, SP), plot in function of offered load
in the range (0, 100] Mbps:
(a) the average throughput for each flow, observed at the server.
(b) the average and the coefficient of variation of the delay for each flow.
8. What is the effect of the scheduling policy on the throughput?
9. What is the effect of the scheduling policy on the delay?

17

Chapter 5

Laboratory #5
Aim of this laboratory is to understand the performance of a basic ARQ (Automatic Repeat
reQuest) protocol.

5.1 Go-back-N
Consider the network scenario shown in Fig. 5.1 where a source (H1) transfers a file to a
destination (H2) through a Go-back-N protocol. Assume that:
the interconnection between the two hosts is based on full-duplex Ethernet, with interfaces running at 100 Mbps;
for each link, the propagation delay is 100 s and the bit error probability is 8 10

7;

the transmission window is fixed and equal to tx window (packets);

the timeout at the source is timeout and it is reset at each new transmission;
each acknowledgment packet (ACK) is cumulative and reports the id of the next requested packet; it is sent by the destination every time a non-corrupted packet is received;
the file size is 100 Mbytes;
for the data transfer, each packet (PDU) is 1518 bytes long, but the actual payload (SDU)
is 1460 bytes long;
each ACK is carried by a packet which is 64 bytes long.

Figure 5.1: Network topology for Go-back-N adopting full-duplex Ethernet interconnection

18

5.2 Tasks
1. Draw the simulation model in terms of basic modules and connections.
2. Define the input parameters of each module and the attributes of each connection.
3. Define in details the messages exchanged by the modules and the self-messages, specifying if they are instances or derived classes of cMessage or cPacket.
4. Define precisely all the main data structures adopted in each basic module.
5. Following the methodology proposed in Sec. 2.1, develop the code to simulate the system.
6. Report all the developed code (ned, cc and ini files).
7. What is the packet error probability for a data packet and for an ACK packet?
8. What is the minimum value of timeout reasonable for this scenario when tx window= 1
packet? Is it compatible with the values of timeout adopted below?
9. Plot (i) the throughput in Mbps, (ii) the average number of transmissions per packet and
(iii) the packet loss probability, when varying tx window 2 {1, 2, 3, 4, 5, 6, 7, 8, 9, 10} packets and timeout= 350 s.
10. What is the effect of varying tx window?
11. Plot the throughput in Mbps when varying tx window 2 {1, 2, 3, 4, 5, 6, 7, 8, 9, 10} packets
and timeout= 700 s.
12. What is the effect of varying timeout?

19

Chapter 6

Laboratory #6
Aim of this laboratory is to understand the performance of an ALOHA access protocol in a
wireless communication system.

6.1 ALOHA
Consider a wireless network in which a basic ALOHA protocol is adopted as multiple access
protocol, where 3 transmitter nodes send data to the same receiver node. Assume that:
the physical-level transmission rate R of each transmitter varies between 1 Mbit/s and
54 Mbit/s, in function of the distance from the transmitter to the receiver, according to the
following formula:

54
R=
Mbit/s
dde
where d is the distance in meters, dxe is the highest integer x and bxc is the smallest
integer x.

a transmission queue is available at each node

packets are generated according to a Poisson process
all the transmitter nodes generate packets at the same rate offered load in Mbit/s,
independently from the physical-level transmission rate; the offered load accounts for
all the transmission attempts (both transmissions and re-transmissions)
the length of all the packets is fixed and equal to 125 bytes
the nodes are located in the coordinates shown in the maps of Fig. 6.1.
the propagation delay is non-negligible and can be computed based on the spatial distance between the nodes
losses occur at the receiver in case of total or partial interference between packets

20

Figure 6.1: Scenarios with 3 transmitters and one receiver: (left) map 1, (right) map 2

6.2 Tasks
1. Draw the simulation model in terms of basic modules and connections.
2. Define the input parameters of each module and the attributes of each connection.
3. Define in details the messages exchanged by the modules and the self-messages, specifying if they are instances or derived classes of cMessage or cPacket.
4. Define precisely all the main data structures adopted in each basic module.
5. Following the methodology proposed in Sec. 2.1, develop the code to simulate the system.
6. Report all the developed code (ned, cc and ini files).
7. Simulate the network corresponding to map 1 for 100 seconds. For each node, plot
the throughput (in Mbit/s) and the airtime fraction (i.e., the fraction of time the network
interface is busy), in function of the offered load (in Mbit/s) by each node.
8. Discuss the behavior of the airframe and of the throughput.
9. Simulate the network corresponding to map 2 for 100 seconds. For each node, plot
the throughput (in Mbit/s) and the airtime fraction (i.e., the fraction of time the network
interface is busy), in function of the offered load (in Mbit/s) by each node.
10. Discuss the behavior of the airframe and of the throughput. Why it is different from the
previous case?

6.3 Solutions
The following graphs are qualitative and reported only for self-evaluation.

21

0.45

Throughput per source [Mbps]

0.35
Airtime fraction

0.5

TX1
TX2
TX3

0.4

0.3
0.25
0.2
0.15
0.1
0.05
0

0.4
0.3
0.2
TX1
TX2
TX3
IDEAL

0.1
0

0.5
1
1.5
Offered load per source [Mbps]

0.5
1
1.5
Offered load per source [Mbps]

Figure 6.2: Performance under map 1 scenario

Throughput per source [Mbps]

0.8
Airtime fraction

0.25

TX1
TX2
TX3

0.9
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0

TX1
TX2
TX3
IDEAL

0.2
0.15
0.1
0.05
0

0.2
0.4
0.6
0.8
Offered load per source [Mbps]

0.2
0.4
0.6
0.8
Offered load per source [Mbps]

Figure 6.3: Performance under map 2 scenario

22