Your SlideShare is downloading. ×
0
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Intro omnetpp-if13-published
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Intro omnetpp-if13-published

803

Published on

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.

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.

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
803
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
83
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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  

×