Lecture and Tutorial on Simulation and Modelling Networks in general and with OMNeT++ in particular. Given at the Informatica Feminale summer school in Bremen, Germany, August 2013.

1. Network
Modeling
and
Simulation
with
OMNeT++
Dr.
Anna
Förster
anna.foerster@ieee.org
Informa4ca
Feminale,
Bremen
August
2013

2. Copyright
Dr.
Anna
Förster
2013
What
is
simulation?
3
Image
sources:
Wikipedia

3. Network
Simulation
• A
program
models
the
behavior
of
a
network
by
calcula4ng
the
interac4on
between
the
individual
en44es
(nodes)
either
with
the
help
of
mathema4cal
formulas
or
by
capturing
and
playing
back
real
world
observa4ons.
• What
is
network
emula4on?
• When
simula4on
is
combined
with
real-­‐4me
applica4ons.
Copyright
Dr.
Anna
Förster
2013
• What
is
network
simula4on?
4

4. Hardware-­‐independent
studies
Environment-­‐independent
studies
Low-­‐cost
Fast
evalua4on
of
many
different
scenarios
and
parameter
seQngs
• Repeatability
of
experiments
• Visibility
of
experiments
(debugging)
• Step-­‐wise
adding
of
complexity
possible
•
•
•
•
Copyright
Dr.
Anna
Förster
2013
Simulation
-­‐
Advantages
5

5. • Simula4on
can
only
mimic
reality,
can
never
reach
its
complexity
• Targeted
environment
might
not
be
covered
in
simula4on
models
(and
comes
usually
at
a
surprise!)
• Real
hardware
with
its
proper4es
(interrupts,
failures,
baYery
failures,
…)
is
not
captured
• Slight
differences
in
simula4on
seQngs
result
in
completely
different
behavior
–
error-­‐prone
process!
Copyright
Dr.
Anna
Förster
2013
Simulation
-­‐
Disadvantages
6

6. Simulation
Basics
•
•
•
•
•
Time
Network
par4cipants
or
nodes
Con4nuous
processes
at
the
nodes
Connec4ons
between
nodes
and
their
proper4es
Informa4on
exchange
between
nodes
Copyright
Dr.
Anna
Förster
2013
• The
following
basics
need
to
be
simulated:
7

7. Simulating
Time
• Real-­‐4me
simula4on
• Discrete
Event
based
simula4on
• Events
of
a
system
are
ordered
in
a
simulated
4me
and
processed
in
order.
(Markov
chain)
Copyright
Dr.
Anna
Förster
2013
• Real
4me
is
used
to
simulate
events
and
the
development
of
a
system.
Oaen
combined
with
emula4on,
real
world
hardware,
etc.
8

8. Simulating
Time
-­‐
Example
• A
single
node
with
a
life4me
of
1
year
• Every
10
minutes,
the
node
sends
out
a
message
(blinking?)
Start
of
life4me
Regular
blinking
• Real
4me
simula4on:
– Time
factor
1:1,
length
of
simula4on
1
year,
blinking
every
10
minutes,
most
of
the
4me
the
simula4on
is
inac4ve
(wai4ng)
– Time
factor
1:525600,
length
of
simula4on
1
hour,
blinking
every
approx.
1
msec.
• Event
based
simula4on:
– No
4me
factors,
only
events
are
processed.
Blinking
constantly!
Copyright
Dr.
Anna
Förster
2013
4me
9

9. Simula4on
4me
is
not
real
4me!
Events
get
ordered
in
a
queue
by
their
4me
The
processing
of
one
event
takes
zero
simula4on
4me
One
event
gets
completely
processed,
before
another
can
start
• No
going
back
in
simula4on
4me!
• Each
event
can
schedule
another
events,
but
only
in
the
future!
•
•
•
•
Copyright
Dr.
Anna
Förster
2013
Time
properties
in
event
based
simulation
10

10. What
is
a
network
node?
• A
single,
independent
unit
in
an
environment:
a
body,
a
building,
an
organism,
a
device,
etc.
• The
node
acts
independently
of
all
other
nodes
in
the
network
• The
node
has
the
ability
to
communicate
with
other
nodes
• Typically
represented
by
a
box
Node
1
Node
2
Copyright
Dr.
Anna
Förster
2013
Simulating
network
nodes
11

11. • Con4nuous
processes:
aging,
baYery
levels,
etc.
• We
need
to
discre4ze
the
process:
• Define
a
variable
to
represent
the
current
level:
age,
baYery
level,
etc.
• Define
a
metric:
years
or
seconds,
percent
or
mA
• Define
a
4me
step
to
change
the
variable:
1
year,
10
seconds,
1
msec.
• How
precise
should
we
go?
• It
depends
on
the
processes
using
the
variable.
• For
example,
if
we
send
a
message
every
10
minutes
and
we
need
to
check
the
baYery
level
before
doing
it,
a
minute-­‐precise
4me
step
is
enough.
• On
the
other
side,
the
:me
step
precision
depends
on
the
variable
precision.
• For
example,
if
the
baYery
level
has
only
a
0
and
1
precision,
higher
4me
precision
is
advisable.
Copyright
Dr.
Anna
Förster
2013
Simulating
continuous
processes
at
the
node
12

12. • In
order
to
exchange
something,
we
first
need
a
connec4on
or
a
channel.
• Example
from
our
world:
voice
and
ears,
pictures
and
eyes,
things
and
hands.
• In
simula4on,
a
channel
is
a
way
to
exchange
something
between
two
nodes
(of
course,
only
virtual
things)
• Connec4ons
are
typically
represented
by
an
arrow
and
have
some
proper4es
Node
1
Node
2
Copyright
Dr.
Anna
Förster
2013
Connections
between
nodes
13

13. Connections
between
nodes
• Direc:on:
the
direc4on,
in
which
things
can
flow.
Could
be
unidirec4onal
or
bidirec4onal
• Latency:
4me
needed
for
the
exchanged
thing
to
pass
from
one
node
to
the
other
via
this
channel.
• Capacity:
how
many
things
at
once
can
pass
through
the
channel.
• Addi4onally,
we
need
a
way
to
send
things
from
the
nodes
to
that
channel.
We
usually
call
this
gates.
Real-­‐world
analogy
is
the
mouth
–
it
is
our
gate
from
our
brain
to
the
voice
channel.
• Gates
have
also
some
proper4es:
• One
gate
is
connected
to
exactly
one
channel
(link)
• A
gate
can
be
either
unidirec4onal
or
bidirec4onal
Copyright
Dr.
Anna
Förster
2013
• Proper4es
of
links:
14
Node
1
Node
2

14. Information
exchange
between
nodes
• Various
types
of
informa4on
or
things
can
be
exchanged:
Copyright
Dr.
Anna
Förster
2013
• Organic
viruses
or
generally
sicknesses
• Digital
media
like
SMS,
mail,
videos,
etc.
15

15. It
is
an
intui4ve
process,
not
a
science!
1. Iden4fy
your
nodes
–
organisms,
people,
devices,
buildings,
etc.
Don’t
forget:
they
are
independent
of
each
other!
• Good
example:
all
your
nodes
are
people.
Or:
some
of
your
nodes
are
smart-­‐phones,
others
are
laptops.
• Bad
example:
some
of
your
nodes
are
people,
others
are
laptops.
Or:
some
are
buildings,
others
are
smart-­‐phones
2. Iden4fy
the
communica4on
channels
and
iden4fy
their
proper4es
(direc4on,
latency
and
capacity)
3. Connect
any
two
nodes
which
are
able
to
communicate
to
each
other
with
an
individual
connec4on.
This
might
take
a
lot
of
gates
and
connec4ons!
4. Make
sure
that
both
nodes,
who
are
able
to
communicate
to
each
other,
can
process
the
same
type
of
informa4on.
For
example,
you
cannot
send
a
voice
mail
to
a
building
or
a
human
virus
to
a
smart-­‐phone.
Copyright
Dr.
Anna
Förster
2013
How
to
model
a
network
16

16. How
to
model
realistically
• Stay
real!
• Do
not
model
behavior,
which
is
impossible
in
the
real
world:
• Keep
the
same
level
of
detail
everywhere:
• Do
not
mix
smart-­‐phones
and
low-­‐level
hardware,
such
as
a
CPU.
• At
the
same
4me,
abstract
as
much
from
the
real
world
as
possible!
• Example:
you
want
to
model
a
network
of
people,
communica4ng
via
devices.
What
you
are
interested
in,
is
the
spread
of
informa4on
between
people.
Solu4on:
model
only
the
people,
do
not
care
of
the
means
of
communica4on.
Assume
the
communica4on
link
is
simple
and
can
pass
any
informa4on
between
the
people.
• Example:
same
as
above,
but
you
are
interested
in
understanding
what
kind
of
baYeries
you
need
to
provide
to
the
people
for
their
devices.
Solu4on:
you
need
to
go
deeper
in
detail
and
simulate
abstract
devices
with
proper4es
such
as
how
much
energy
they
need
to
exchange
a
piece
of
informa4on.
Copyright
Dr.
Anna
Förster
2013
• Receiving
data
faster
than
sending
• Smart-­‐phones
able
to
see
and
process
organic
viruses
• …
17

17. Design
Exercise
(1)
• Design
a
model
for
the
following
scenario:
• The
mother
and
the
father
can
give
commands
to
the
general
hea4ng
system,
to
the
window
opening/closing
system,
to
the
kitchen
devices
and
to
the
TV.
They
can
also
send
a
message
through
the
system
to
all
other
members,
which
will
be
displayed
on
the
screen
in
the
entrance
and
can
add/delete
items
to
the
joint
shopping
list.
• The
older
children
(e.g.
aged
12-­‐14)
can
give
commands
to
the
TV,
can
send
messages,
only
add
items
to
the
shopping
list
and
can
see
the
current
status
of
all
other
devices
• The
younger
children
can
only
see
the
current
status
of
all
devices,
can
send
messages
and
add
items
to
the
shopping
list,
which
are
however
marked
for
approval
by
the
parents.
Copyright
Dr.
Anna
Förster
2013
• A
family
owns
a
so
called
“smart
home”,
reachable
via
a
central
device
over
internet.
The
family
members
have
different
rights
and
can
reach
various
devices
in
the
house:
18

18. Design
Exercise
(2)
• You
are
interested
in
the
general
correctness
of
the
system
and
the
existence
of
all
needed
links
• You
need
to
be
able
to
inject
different
(also
faulty!)
commands
from
the
different
family
members
• You
need
to
be
able
to
observe
the
current
status
of
each
device
(incl.
the
message
screen
and
the
shopping
list)
Copyright
Dr.
Anna
Förster
2013
• Design
the
model,
given
that:
19

19. Design
Exercise
(3)
–
Solution
• End
user
device
with
level
of
trust
(rights)
• Central
smart
home
device
• Home
device
with
internal
status
(simply
a
list
of
possible
text
values)
Copyright
Dr.
Anna
Förster
2013
• Three
types
of
nodes
with
proper4es:
20

20. Working
with
OMNeT++
Source:
omnetpp.org
An
OMNeT++
model
is
build
from
components
(modules)
which
communicate
by
exchanging
messages.
Modules
can
be
nested,
that
is,
several
modules
can
be
grouped
together
to
form
a
compound
module.
When
crea4ng
the
model,
you
need
to
map
your
system
into
a
hierarchy
of
communica4ng
modules.
}
Define
the
model
structure
in
the
NED
language.
You
can
edit
NED
in
a
text
editor
or
in
the
graphical
editor
of
the
Eclipse-­‐based
OMNeT++
Simula4on
IDE.
}
The
ac4ve
components
of
the
model
(simple
modules)
have
to
be
programmed
in
C++,
using
the
simula4on
kernel
and
class
library.
}
}
}
Provide
a
suitable
omnetpp.ini
to
hold
OMNeT++
configura4on
and
parameters
to
your
model.
A
config
file
can
describe
several
simula4on
runs
with
different
parameters.
Build
the
simula4on
program
and
run
it.
You'll
link
the
code
with
the
OMNeT++
simula4on
kernel
and
one
of
the
user
interfaces
OMNeT++
provides.
There
are
command
line
(batch)
and
interac4ve,
graphical
user
interfaces.
Simula4on
results
are
wriYen
into
output
vector
and
output
scalar
files.
You
can
use
the
Analysis
Tool
in
the
Simula4on
IDE
to
visualize
them.
Result
files
are
text-­‐
based,
so
you
can
also
process
them
with
R,
Matlab
or
other
tools.
Copyright
Dr.
Anna
Förster
2013
}
21

21. Copyright
Dr.
Anna
Förster
2013
OMNeT++
IDE
22

22. simple Txc1 { !
!gates: !
!
!input in; !
!
!output out; !
} !
network Tictoc1 { !
!submodules: !
!
!tic: Txc1; !
!
!toc: Txc1; !
!connections: !
!
!tic.out --> { delay = 100ms; } --> toc.in;!
!
!tic.in <-- { delay = 100ms; } <-toc.out; !
} !
Copyright
Dr.
Anna
Förster
2013
Tic-­‐Toc
Step-­‐by-­‐Step
Tutorial
23

23. Defini3on
of
a
simple
module,
with
simple Txc1 { !
only
2
gates,
named
IN
and
OUT
!gates: !
!
!input in; !
!
!output out; !
} !
network Tictoc1 { !
!submodules: !
!
!tic: Txc1; !
!
!toc: Txc1; !
!connections: !
!
!tic.out --> { delay = 100ms; } --> toc.in;!
!
!tic.in <-- { delay = 100ms; } <-toc.out; !
} !
Copyright
Dr.
Anna
Förster
2013
Tic-­‐Toc
Step-­‐by-­‐Step
Tutorial
24

24. simple Txc1 { !
!gates: !
!
!input in; ! Defini3on
of
a
network,
consis3ng
of
two
sub-­‐modules,
both
of
type
Txc1
!
!output out; !
and
with
connec3ons
between
their
} !
gates
network Tictoc1 { !
!submodules: !
!
!tic: Txc1; !
!
!toc: Txc1; !
!connections: !
!
!tic.out --> { delay = 100ms; } --> toc.in;!
!
!tic.in <-- { delay = 100ms; } <-toc.out; !
} !
Copyright
Dr.
Anna
Förster
2013
Tic-­‐Toc
Step-­‐by-­‐Step
Tutorial
25

25. Tic-­‐Toc
Step-­‐by-­‐Step
Tutorial
#include <string.h> !
#include <omnetpp.h> !
class Txc1 : public cSimpleModule { !
!protected: !
!// The following redefined virtual function holds
the algorithm. !
!
!virtual void initialize(); !
!
!virtual void handleMessage(cMessage *msg); !
}; !
Copyright
Dr.
Anna
Förster
2013
Implementa3on
of
the
Txc1
module
–
header
file
26

26. Tic-­‐Toc
Step-­‐by-­‐Step
Tutorial
// The module class needs to be registered with OMNeT++ !
Define_Module(Txc1); !
void Txc1::initialize() { !
// Initialize is called at the beginning of the simulation. !
// To bootstrap the tic-toc-tic-toc process, one of the modules needs !
// to send the first message. Let this be `tic'. !
// Am I Tic or Toc? !
!
!if (strcmp("tic", getName()) == 0) { !
!
!// create and send first message on gate "out". "tictocMsg" is an !
!
!// arbitrary string which will be the name of the message object. !
!
!cMessage *msg = new cMessage("tictocMsg"); !
!
!send(msg, "out"); } } !
void Txc1::handleMessage(cMessage *msg) { !
// The handleMessage() method is called whenever a message arrives !
// at the module. Here, we just send it to the other module, through !
// gate `out'. Because both `tic' and `toc' does the same, the message !
// will bounce between the two. !
!
!send(msg, "out"); } !
Copyright
Dr.
Anna
Förster
2013
Implementa3on
of
the
Txc1
module
–
source
file
27

27. NED
Network
source
(C++)
Module
Module
Module
Module
omnetpp.ini
Module
Copyright
Dr.
Anna
Förster
2013
Simple
Module
28
executable

28. Creating
Messages
• Duplicating a message before sending to
several gates or any other copy:!
cMessage *msg1 = msg->dup();!
!
Copyright
Dr.
Anna
Förster
2013
• Creating a new message:!
!
cMessage *msg = new cMessage(“message_name”);!
msg->setKind(MY_MESSAGE_TYPE);!
!
29

29. Sending
Messages
• Send
a
message
to
an
out/inout
gate:
• send(msg,
“gateOut”);
• scheduleAt(200.6f,
msg);
• Cancel
again
a
previously
scheduled
message:
• cancelEvent(msg);
Copyright
Dr.
Anna
Förster
2013
• Send
a
self
message:
30

30. Receiving
messages
• All
messages
are
received
in
handleMessage()
• Asking
for
the
incoming
gate:
• Asking
for
the
kind
(type):
• if
(msg-­‐>getKind()
==
MY_MESSAGE_TYPE)
• Asking
whether
it
was
a
self
message:
• if
(msg-­‐>isSelfMessage())
Copyright
Dr.
Anna
Förster
2013
• bool
arrivedAtGateName
=
msg-­‐>arrivedOn(“gate_name”,
index)
31

31. Asking
for
parameters
• Parameter
defined
in
NED:
“int
interval”
• Asking
for
the
value
of
it
in
the
implementa4on:
• More
secure:
• int
value
=
hasPar(“interval”)
?
par(“interval”)
:
10;
Copyright
Dr.
Anna
Förster
2013
• int
value
=
par(“interval”);
32

32. • endSimula3on()
–
ends
the
simula4on
immediately,
e.g.
in
case
of
a
fatal
error.
• recordScalar("Data",data)
–
records
a
data
item
into
an
external
file,
for
future
processing/representa4on
• bubble(”ERROR!
HELP!”)
–
presents
a
graphical
bubble
in
the
simula4on
with
the
given
text
• display
strings
–
each
module
has
a
display
string,
consis4ng
of
argument
tuples,
which
can
be
changed
also
at
run-­‐4me
–
see
the
documenta4on
of
display
strings
Copyright
Dr.
Anna
Förster
2013
Further
useful
things
33

33. • double
simTime()
–
returns
the
current
simula4on
4me.
• ev
–
outputs
debugging
informa4on
into
the
event
screen.
Example
of
usage:
ev
<<
getName()
<<
“:”
<<
“I
just
received
a
packet
with
ID
“
<<
id
<<
endl;
Copyright
Dr.
Anna
Förster
2013
Further
useful
things
34

34. Exercises
• Exercise
1:
create
your
own
copy
of
the
4c-­‐toc
tutorial,
called
*your-­‐name*TicToc.
Change
the
names
of
the
modules:
• Exercise
2:
create
a
new
parameter
called
period,
and
include
it
into
the
module
tac.
Read
the
value
of
the
parameter
in
tac.ini4alize
and
display
it
with
ev.
Copyright
Dr.
Anna
Förster
2013
• txc1
-­‐>
tac
• Tictoc1
-­‐>
Tictac
35

35. • Exercise
3:
Now
change
the
way
how
tac
works.
Instead
of
crea4ng
a
message
in
the
beginning
of
the
simula4on
and
leQng
it
bounce
between
the
nodes,
create
one
message
every
period
(the
parameter
from
Ex.2)
at
4c
and
delete
it
at
toc.
Copyright
Dr.
Anna
Förster
2013
Exercises
36