CS432 Handouts

Network Modeling and Simulation

MIDTERM
Topic (1 to 84)

Made by Yasir Ejaz

(MCP , MCSE , MCSA , CCNA)
0321 5253058
[[email protected]]
Network Modeling and Simulation
Course code CS432
Credits 3+0
Instructor
Dr. Ali Hammad Akbar
Lecturing style
Video lectures of short
duration
(5-7 minutes)
Network Modeling and Simulation
Evaluation
 Quizzes
 Assignment
 Simulation modules
 Mid-term and final
Network Modeling and Simulation
Enter the complex world
of networks
• Can we simplify it?
• Or at least the discussion
of it?
Network Modeling and Simulation
Knowing me
 Wireless Networks
 Distributed Systems
 Enterprise Network
 Broadband Access
 Machine-to-Machine
 Protocols and Models
Network Modeling and Simulation
Knowing you
Need for NeMS

In this module
Let us explore the need and
motivation to perform
Network
Modeling and Simulation
(NeMS)
Need for NeMS

Technology Landscape
(1 of 4)
Communications systems:
Evolving rapidly
User demands:
High performance networks
Service providers: Rapidly
expanding their network
infrastructure
Need for NeMS

Technology Landscape
(2 of 4)
Network researchers face the
protocol war
Developing new
communications
techniques, architectures and
capabilities
Need for NeMS

Technology Landscape
(3 of 4)
Equipment vendors:
Release new devices with
increasing capability and
complexity
Need for NeMS

Technology Landscape
(4 of 4)
Technology developers and
OEMs:
Developing NG equipment
Need for NeMS

Stakeholders challenges
Network developer
Network Designer

Operational Engineer

Architect
Need for NeMS
Network designer/
developer
 How do I satisfy the QoS
demands of users amidst
emerging technologies and
techniques viz a viz legacy
counterparts?
Need for NeMS
Network Engineer in
operations
 What is the right approach to
solving my problem?
 Do I buy latest device from
company X that claims to solve
all my problems?
 Do I replace underlying
technology of my system with
the latest generation?
Need for NeMS
Next Generation Network
Architect
 How do I know how this new
approach will interact with
already existing protocols?

 How do I build confidence in

the utility of this approach
without producing and
deploying the technology?
 Need for NeMS
No

 Prototyping & empirical

 testing
 Trial field deployment
 Modeling and Simulation
 (M & S)
 Analysis
END

Cost Abstraction
What is NeMS?

In this module
We shall understand NeMS as
a single concept and break it
further down
 What is modeling?

 What is simulation?
What is NeMS?
 Network Modeling and
Simulation is often considered
a single term.
Simulation is
 Imitation of behaviour of real-

world system
 Computational re-enactment

 According to rules described in

model
What is NeMS?
 Modeling precedes simulations
 Together they form an
iterative process
 Approximate the real world
systems
 What is NeMS?

Stop Start

Design unsatisfactory:
Reconsider

Validation Modeling
Thru For
Simulation System

System Design
What is NeMS?
 Consider a simple signal
detection circuit
What is NeMS?
 Its simulation could give out
– Correct result
– Incorrect result
– No result
Why!
What is NeMS?
 Because its behaviour has to
be governed by its model
– Transceiver design
(Detection theory)
– Digital circuit (Boolean
algebra)
What is NeMS?

Model
 Logical representation
– Complex entity
– System
– Phenomena
– Process
What is NeMS?

Network Model
 In communications
– Analytical representation
– Mathematical form
– State Machine
– Closed or approximate
form
 What is NeMS?

Computer Simulation
 Computer software
– Reproduces behavior
– Certain degree of accuracy
– Provides visual insight

End
What is Model?

In this module

We shall learn
 What is a computer model?

 What are types of models?

What is Model?

Computer Model
 A template on which a
computer program runs
• Inputs
• Outputs
• Behaviour
•Model definition
 Descriptive

 Analytical

 Mathematical

 Algorithmic
What is Model?

Types of computer models

 Stochastic vs Deterministic
 Continuous vs discrete
 Steady state vs Dynamic
 Local or Distributed
 Linear or nonlinear
 Open or closed
What is Model?

Stochastic vs
Deterministic
 Deterministic models have
no randomness
 Given input always

produces same output

 Defined as a state

machine Most common

type of computer model
What is Model?

Stochastic vs Deterministic
 Stochastic models don't have
unique input–output
mapping
 Unpredictable execution
 Associated simulations are
pseudo-random using
random number generators
 Not widely employed
What is Model?

Continuous vs Discrete
•State variables assume
any value in continuous
•State variables assume only
discrete values in discrete-state
models
 Continuous or discrete-time

models
•Discrete computer models need
clocks and timers
What is Model?
Steady state vs Dynamic
 Steady state models establish
input-output relation in
equilibrium
 Simpler

 Dynamic models integrate

internal changes to the
system with changing inputs
 Complex
What is Model?
Local or Distributed
•A distributed model would
require multiple computing
platforms
 Distributed networking

 Need synchronization

 Better emulate real world

•Local models require single

platform
 Simpler to implement
What is Model?
Linear or Nonlinear
•A model that maps inputs to
outputs linearly is simpler
•Nonlinear models involve
complex functions
 Difficult to implement
What is Model?
Open or Closed
•Open model define and require
external inputs
•A model that does not take
external inputs is closed
 Automated systems
 What is Model?
Stochastic Continuous Linear
Deterministi Discrete Nonlinear
c

A B
C

Supra-modeling
A+B'+C
A'+C'

End
Modeling Perspective & Intra-Model Relation

In this module

We shall learn
 What needs to be modeled?

 Which is the most suitable

model?
 How to do most appropriate

modeling?
Modeling Perspective & Intra-Model Relation
Model only what you
understand
• Utility of model is as good as
it mimicks real world system
• Knowledge of system is pre-
requisite
• Wireless model requires
 Free space path loss

 Hidden terminal

 Absorption
Modeling Perspective & Intra-Model Relation
Understand Your Model
• Your model has
 Your perspective

 Your assumptions

 Your analytics/maths

• Caching server
 Response time

 Infinite buffer

 Queuing theory
Modeling Perspective & Intra-Model Relation

Caching server

Client Web Server

End-to-end response time

Average Response Time = Average

Number in System / Average
Throughput
Modeling Perspective & Intra-Model Relation
Model what you need & no
more
• Underdefined model
– Simplified analysis
– Easier Simulations
– But, untrustworthy
• Overdefined model
– Harder to realize
– Complex analysis
– Long run simulations
– Very reliable
– But, increased error
Modeling Perspective & Intra-Model Relation

Oversimplistic

Practical

A B C

Unachievable

Modeling Fidelity
End
A. Poor utility
B. Optimum utility
C. Marginal increase in utility
What is Simulation?

In this module

We shall understand
 Simulated outputs
 What is Simulation?

Computer
Software
{
Modeled Inputs Simulated Outputs
Algorithms
Routines
}

Modeling and Simulation

Terminologies
 What is Simulation?

Parameter Explanation

BER PER, Throughput

delay

Simulated outputs
 What is Simulation?

Parameter Explanation

Throughput File transfer delay

Simulated outputs
 What is Simulation?

Parameter Explanation

Packet overhead Network efficiency

Simulated outputs
What is Simulation?

In this module

We shall explore and learn

 A simple use-case

 What is its simulation?

 What are modeling and

simulation terminologies
What is Simulation?

Please recall that

 Simulations are pieces of
computer software
 Implement algorithms

 Take inputs

 Give outputs
 What is Simulation?

A simple use case: One-hop Communication Network

 What is Simulation?

Computer
Software
{
Modeled Inputs Simulated Outputs
Algorithms
Routines
}

Modeling and Simulation

Terminologies
 What is Simulation?

Parameter Explanation

Signal Power Received Power,

dBm BER, PER

Modeled inputs
 What is Simulation?

Parameter Explanation

Waveform Type BER, PER

Analog/Digital

Modeled inputs
 What is Simulation?

Parameter Explanation

FEC BER, PER, ReTX

Hamming code

Modeled inputs
 What is Simulation?

Parameter Explanation
Retransmission Throughput, Delay
Protocol
GoBackN
Selective Repeat

Modeled inputs
 What is Simulation?

Parameter Explanation

Channel Model Received Power,

AWGN, Rayleigh BER, PER
Rician

Modeled inputs
 What is Simulation?

Parameter Explanation

Mobility Model MAC and IP routing

Random waypoint
Gauss Markov

Modeled inputs
 What is Simulation?

Parameter Explanation

Traffic Model Offered Load and

queue behaviour

Modeled inputs
 What is Simulation?

Parameter Explanation

Network Topology Connectivity,

coverage

Modeled inputs
 What is Simulation?

Parameter Explanation

BER PER, Throughput

delay

Simulated outputs
 What is Simulation?

Parameter Explanation

Throughput File transfer delay

Simulated outputs
 What is Simulation?

Parameter Explanation

Packet overhead Network efficiency

Simulated outputs
Simulation Building Process

In this module

We shall explore and learn

 Simulation building process

 Inside computer

 Simulation run
Simulation Building Process

Remember!
 One hop communication
scenario
Simulation building process
 Entities
 Wireless computers

and their packets (multiple

instances)
 WiFi AP (single instance)
Simulation Building Process

Simulation building process

 Entities (continued...)
 Traffic generator (single

instance)
 Creates wireless computers

and their packets

Simulation Building Process

Simulation building process

 States
 WiFi AP (idle or busy)

 Each computer generates a

number of packets
 Each packet successful/failed
Simulation Building Process

Simulation building process

 Events
 Wireless computer creation

 Packet generation

 Wireless AP activity

 Each packet successful/failed

Simulation Building Process

Simulation building process

 Queues
 Frames waiting in output queue
of wireless computer
 Frames (Packet) at WiFi AP input
queue
Simulation Building Process

Simulation building process

 Random realizations
 Packet lengths

 No of frames per

wireless computer
 No. of wireless

computers
 BER and PER

 Packet drop ratio

in WiFi AP input queue

Simulation Building Process

Simulation building process

 Distributions
 Uniform/Gaussian
 Packet lengths
 No of frames per
 wireless computer
 Simulation Building Process
Start
measurements
Iteration = 0 What happens Model
Entities
inside the State
Read input ()
Direct

Write output ()
Initialization ()
Print status ()
computer variables
States
++ Iteration
Events
Timing ()
Print status ()
Queues
Scheduling
Event Type = Type 1 Event routine of Type 1
disciplines
Randomness
Distributions
Event Type = Type 2 Event routine of Type 2

Event Type = Type 3 Event routine of Type 3

Generated output < Report Generation

Required output

End
 Simulation Building Process
Simulation run
 Inputs created/initialized
 Events of transmission,
reception and noise occur
 Randomness causes queues to
behave and err
 Packet successes/failures
 Simulation logs/compiles
outputs

End
Components of Simulator
In this module

We shall determine
 Components of a typical

simulator
 Their relationship and

organization
Components of Simulator

Simulations run on
simulator
 A self-contained program
 Event queue
 Simulation clock
 State variables
 Event routines
 Input routine
 Report generation routine
 Initialization routine
 Main program
Components of Simulator

Event queue
 Number of events in an ordered
list
 Determines complexity
 Total simulation time
Components of Simulator

Simulation clock
 Global variable
 Clock ticks (constant and small
increments)
 Time driven
 Events occurring

within incrementing time are

of interest
 Event driven
 Time is fast forwarded to the

occurrence of event
Components of Simulator

State variables
 Together define the state of the
system
Components of Simulator

Event routines
 Handle the occurrence of event
 Event creation
 Event action
 Updates state variables
 Updates event queue
Components of Simulator

Input routines
 Provide user interface
(UI)
 Takes parameters

 Passes to main program

Components of Simulator

Report generation routine

 Calculates results
 Provides to user interface

(UI)
Components of Simulator

Initialization routine
 Initializes
 State variables

 Global variables

 Statistical variables
Components of Simulator

Main program
 Calls other routines
 Initializes and terminates
simulation
Types of Simulations

In this module

We shall summarize
 Performance evaluation

techniques
 Types of simulations
Types of Simulations

Performance Evaluation
Techniques (PETs)
 Simulation: behavior of
interconnected subsystems &
subprocesses
 Evaluation: measure of

an aggregate systemic
property
 Efficient and confident
Types of Simulations

PETs
Direct measurement
 Not abstracted

 Incorporate real workload

 Maps to real world

 Only available for operational

system
 Behavioral sensitivity
 End-to-end not possible
Types of Simulations
 Types of Simulations
Simulation
Types

Monte Carlo
Trace driven
simulation

Discrete Continuous
events events
Types of Simulations

Monte Carlo
 No time axis
 Model probabilistic phenomena
that do not change with time
Types of Simulations

Trace driven
 Ordered list of events
as input
 Expected outputs!
Types of Simulations

Continuous event
 States change to inputs
at non discrete times
 Consequently has a very large

number of outputs and state

changes
 Generally transformed into

discrete event simulations

Types of Simulations

Discrete event
 No events between intervals
Finite events and output
Common Simulation Pitfalls

In this module

We shall understand
 General and programming

mistakes
 Simulation inaccuracies

 Misleading results
Common Simulation Pitfalls

When to simulate!
 Analytical model not feasible
(complex)
 Analytical model not possible

(too simple)
 Simulate to verify analysis

 Otherwise simulations

are unnecessary
Common Simulation Pitfalls

When not to simulate!

 Analytical model gives good
enough representation
 Simulation takes months
 Simulation is expensive
 Simulation is non-scalable
Common Simulation Pitfalls

General mistakes
 Inappropriate levels of details
 Improper selection of

programming language
 Unverified models

 Improper initial

conditions
Common Simulation Pitfalls

General mistakes
(continued...)
 Short run times
 Poor random number

generators
 Inadequate time

estimate
 No achievable goals
Common Simulation Pitfalls

General mistakes
(continued...)
 Incomplete mix of essential
skills
 Inadequate level of user
participation
 Inability to manage simulation
project
Common Simulation Pitfalls

Simulation inaccuracies
 Over reliance on link budget
methods for abstraction
 Overly simplistic modeling of

radio
layers
Common Simulation Pitfalls

In this module

We shall understand
 General and programming

mistakes
 Simulation inaccuracies

 Misleading results
Common Simulation Pitfalls

General mistakes
Inappropriate levels of details
 Include what is relevant

 Too fine simulations

computationally heavy
– Many interdependent
parameters
– Difficult to assess
their interplay
 Tip: Necessity & sufficiency
Common Simulation Pitfalls

General mistakes
Improper programming language
 Scope & type of simulation

determine
best choice
 Object oriented vs procedural

– Types/diversity of
simulation parameters
 Interpreted vs compiled

– Machine dependence
– Speed
Common Simulation Pitfalls

General mistakes
Unverified models
 Programming is non trivial

 Semantic mistakes

 make simulations get

 Wrong results

 Misleading results

 Modular verification a

must
Common Simulation Pitfalls

General mistakes
Improper initial conditions
 Initial condition not steady state

 Often a late realization

 Surprisingly wrong

results
 May never converge
Common Simulation Pitfalls

General mistakes
Short run times
 Strong dependence on Initial

conditions
 Don't achieve true

steady state
Common Simulation Pitfalls

In this module

We shall understand
 General and programming

mistakes
 Simulation inaccuracies

 Misleading results
Common Simulation Pitfalls

General mistakes
Poor random number generators
 Lacking pseudo-random

sequence leads to predictability

 Wrong choice of seed value

could cause inadvertent

correlation between processes
– Use celebrated RNGs
Common Simulation Pitfalls

General mistakes
Inadequate time estimate
 Models overstate the

simulations
– Implementations get
delayed
 Software development life

cycle must assess model

complexity
Common Simulation Pitfalls

General mistakes
No achievable goals
 Goals not defined

– Tangible output
analysis
– Logs and trace files
 Goals are unreal

– Affects simulation
complexity and
implementation
Common Simulation Pitfalls

General mistakes
Incomplete mix of essential
skills
 Domain knowledge

 Statistics

 Programming

 Project management

 Past experience
Common Simulation Pitfalls

General mistakes
Inadequate level of user
participation
 From modeling to

implementation
 UI design

 Output analysis
Common Simulation Pitfalls

General mistakes
Inability to manage
simulation project
 Simulations are not

monolithic
 Need software engineering

tools
– Multivariate design
– Code management
– Track changes
Common Simulation Pitfalls

In this module

We shall understand
 General and programming

mistakes
 Simulation inaccuracies

 Misleading results
Common Simulation Pitfalls

Simulation inaccuracies
Over reliance on link budget
methods for abstraction
 Link budget losses overly static

– Fair enough for steady state

analysis
– Dynamic analysis not
possible
 Results are misleading
Common Simulation Pitfalls

Simulation inaccuracies
Overly simplistic modeling of
radio layers
 Lowest layer often ignored

– No bit level BER & delay

 Often the Achilles heel

 Wrong results in highly dynamic

use cases
 Common Simulation Pitfalls

Solve the !

Inappropriate levels Short run times

No
of details Clear Improper initial
Improper selection of goals conditions
programming language Short run times
Inadequate time Poor RNG No SE tools
estimate
Unverified models

Lacking essential skills No user

Link/radio layers participation
Development of Systems Simulation
In this module

We shall understand
 The process of development of

systems simulations
 Development life cycle
 Development of Systems Simulation
A “Still I am not dead yet!” scenario

Available Not available

h = height (feet) Mass of object
t = time in motion (seconds) Air resistance
v = initial velocity (feet per second, + is up) Location of object
s = initial height (feet)
a = acceleration (feet per second per second)
Development of Systems Simulation
A “Still I am not dead yet!” scenario

/* Height of an object moving under gravity. */

/* Initial height s and velocity v constants. */
main()
{
float h, v = 100.0, s = 1000.0;
int t;
for (t = 0, h = s; h >= 0.0; t++)
{
h = ( -16.0 * t * t) + (v * t) + s;
printf(“Height at time %d = %f\n ”, t, h);
}
}
Development of Systems Simulation
A “Still I am not dead yet!” scenario
Development of Systems Simulation
Development Process
 Problem formulation
 Data collection & analysis
 Simulation development
 Model validation,
verification, & calibration
 “What-if” analysis
 Sensitivity estimation
Development of Systems Simulation
Development Process
Problem formulation
 Identify controllable and

uncontrollable inputs
Development of Systems Simulation
Development Process
Data collection & analysis
 What to collect

 How much to collect

 Cost and accuracy trade

off
Development of Systems Simulation
Development Process
Simulation development
 Codify, codify and codify!
Development of Systems Simulation
 Development Process
Model validation,
verification, & calibration
 Validation

 Is it the right system?

 Emulates real phenomenon

Development of Systems Simulation
 Development Process
Model validation,
verification, & calibration
 Verification

 Are we building the system

right?
 Implementation must

correspond to the model

Development of Systems Simulation
 Development Process
Model validation,
verification, & calibration
 Calibration

 Parameter estimation

 Tweaking/tuning to ensure

that simulated data

follows real data
Development of Systems Simulation
Development Process
“What-if” analysis
 Performance measures

with different inputs

Development of Systems Simulation
Development Process
Sensitivity analysis
 Relative importance of

different parameters with

respect to output
 Even with respect to

each other
Development of Systems Simulation
Life cycle of Simulation Development
Recommended Text and References

In this module

We shall assess
 NeMS coverage of contents

 Most suitable resources

 Text books

 References Books

 Online Resources
Recommended Text and References

NeMS contents cover

 Well known mathematical
models, equations and
forms
 Widely used simulation
tools and code reusability
 Their inter-relationship
Recommended Text and References

NeMS contents don't

cover
 Mathematical derivations
from scratch
 Programming dexterity
Recommended Text and References

Uptill now
Basics of NeMS
 Mohsen Guizani et al,

“Network Modeling and

Simulation” John Wiley ,
2010.
Recommended Text and References

Uptill now
Basics of NeMS
 Jack Burbank et al, “An

Introduction to Network
Modeling & Simulation for
the Practicing Engineer”
John Wiley , 2011.
Recommended Text and References

Uptill now
Basics of NeMS
 John A. Sokolowski &
Catherine M. Banks,
“Modeling and Simulation
Fundamentals” John Wiley ,
2010.
Recommended Text and References
Next Roadmap (1 of 2)
 Recommended Text and References
Next Roadmap (2 of 2)
 TicToc tutorial
 OMNET++ Manual
 Website: https://omnetpp.org
 INET Framework for OMNeT++
 OMNET++ Wiki
 Mixim Sourceforge Page
Introduction to OMNET++

In this module

We shall cover
 What is OMNET++?

 How to get a free

copy?
 How to compile and install on

Windows?
 Running for the first

time
Introduction to OMNET++

What is OMNET++
 Objective Modular Network
Testbed in
C++
– Simulation kernel
– Component-based
simulation library
• A framework, not a simulator
 Designed to create &

simulate any network

Introduction to OMNET++

Simulation Kernel
Introduction to OMNET++

Getting a free copy

 www.omnetpp.org
 Download the latest release

(4.6 in our case)

omnetpp-4.6-src-windows.zip
 Complete folder

– C++ compiler
– CMD line build
environment
•Download source code
Introduction to OMNET++

Compile & Install

 Compiling and installing on
Windows self-contained
 Enter OMNeT++ folder that you
unzipped
 Run the file called
Mingwenv.cmd

Minimum GNU environment for Windows

compilers provide access to functionality
of Microsoft C runtime and some
language-specific runtimes
Introduction to OMNET++

Compile & Install

 When terminal appears, enter
the commands
./configure
make
Build process produces
debug and release
binaries

Debug is elaborate
but slow
Release is optimized
and fast
Introduction to OMNET++

Debug mode
 Does not optimize the binary it
produces
 Source code and generated
instructions relationship is
complex
 Allows accurate breakpoints
setting
 Allows code step-through one
line at a time
 Compiled with full symbolic
debug information
Introduction to OMNET++

Release mode
 Enables optimizations
 Generates instructions without
any debug data
 Lots of code could be completely
removed or rewritten
 Resulting executable may not
match with written code
 Introduction to OMNET++

Running first time

 OMNeT++ comes with an Eclipse-based Simulation IDE
 Type omnetpp
 Introduction to OMNET++

Select the default workspace

 A workspace is a logical collection of projects
 A workspace called p2p may contain only peer to peer
applications
Overview of OMNET++

In this module

We shall cover
 Design of OMNET++

 Model structure
 Overview of OMNET++

Design of OMNET++
Requirements Design features
Hierarchical Simulation
Large Scale Simulations
Models

Reusable components

Reduce debugging time Provide visualization

Generate input and output

Open data interface
using common sw tools
Model development and
Provide IDE
analysis to be unified
Overview of OMNET++

Model Structure
 Model consists of modules
 Modules communicate with
message passing
 Modules are C++ files
– Implement simulation class
library
– Run in simulation kernel
 Module types
– Simple (active modules)
– Compound
 Overview of OMNET++

Model Structure
 Simple modules can be grouped into compound modules and
so forth
 Modules communicate through gates (connections)
– Directly between modules or through intermediaries
 Overview of OMNET++

Model Structure
 No. of hierarchy levels not limited

No of components

Types of components
 Overview of OMNET++

Model Structure
 Gates
– Input output interfaces of modules
– Allow message passing
– Linked via connection (TPROP, RDATA, BER)

1. Define
Module
types

2. Instantiate
3. Network implements system model
them
 Overview of OMNET++

Model Structure
 Channels
– Connection types with specific properties
– Reusable at several places
– StandardHost talking to another StandardHost via an Ethernet cable

1. Define
Module
types

2. Instantiate
3. Network implements system model
them
 Overview of OMNET++

Model Structure
 Message; tuple (time stamp, arbitrary data, ...)
 Network; A compound module with no external gates

1. Define
Module
types

2. Instantiate
3. Network implements system model them
Overview of OMNET++

Module Parameters
 Pass configuration data to
simple modules
 Define model topology
 String, numeric, boolean
 Constants, random
numbers
 Expressions as
references
Overview of OMNET++

Module Parameters
Logical Architecture of OMNET++ Simulation Program

In this module

We shall cover
 Internal architecture of

OMNET++
 Contents of the Simulation

Library
Logical Architecture of OMNET++ Simulation Program

Internal Architecture
 OMNeT++ simulation programs possess a modular structure
Logical Architecture of OMNET++ Simulation Program

Model Component
Library
 Consists of the code of compiled
simple and compound modules
Logical Architecture of OMNET++ Simulation Program

Internal Architecture
 OMNeT++ simulation programs possess a modular structure
Logical Architecture of OMNET++ Simulation Program

Simulation Kernel & SIM

Class Library (1 of 2)
 Modules are instantiated and
concrete simulation model is built
by the simulation kernel
 SIM covers most of the common
simulation tasks through classes
– Generate random number
(distributions)
– Queues (FIFO, priority)
Logical Architecture of OMNET++ Simulation Program

Simulation Kernel & SIM

Class Library (2 of 2)
 Messages (hold arbitrary data
structures)
 Routing (explore topology,
generate graph data structure)
Logical Architecture of OMNET++ Simulation Program

Internal Architecture
 OMNeT++ simulation programs possess a modular structure
Logical Architecture of OMNET++ Simulation Program

Envir, Cmdenv and Tkenv

Libraries
 Simulation executes in an
environment
 Defines and determines
 Where input data come from

 Where simulation results go to

 What happens to debugging

output
 Controls the simulation execution

 How model is visualized

Logical Architecture of OMNET++ Simulation Program

Internal Architecture
 OMNeT++ simulation programs possess a modular structure
Overview of OMNET++

In this module

 We shall cover
 Introduction to NED Language
 Graphical Editor
Overview of OMNET++

What is NED Language?

 A network description language
 Creates network topologies in
OMNeT++
 You create alternately create
topology graphically as well
 Correspondingly NED source
code is automatically
generated
Overview of OMNET++

Typical Ingredients of
NED description
 Network definitions
 Compound module
definitions
 Simple module declarations
Overview of OMNET++

Network Definition
 Network definitions are
compound modules
– Self-contained
simulation models
Overview of OMNET++

Simple Module
Declaration
 Describes the interface of
modules
– Gates
– Parameters
Overview of OMNET++

Compound module
definitions
 Declaration of external
interface
– Gates
– Parameters
 Definition of
– Submodules
– Their interconnections
 Overview of OMNET++

Let us create a topology called My_Network using

Graphical Editor

Network name
=
My_Network
 Overview of OMNET++

Module name
=
My_Module
 Overview of OMNET++

Compound module
name=
standardHost
 Overview of OMNET++

Inside
standardHost
More About NED Language

In this module

We shall cover more

details about NED
 Inheritance

 Interfaces

 Packages

 Inner types
More About NED Language

 Inheritance
 Modules and channels can be
subclassed
 Derived modules and channels
may add
– New parameters
– Gates
 Similarly compound modules
may add
– New submodules
– Connections
 More About NED Language

Examples

Simple Compound
Module GenericTCPClientApp BaseHost

Derived
FTPApp BaseHost + WebClientApp
(Extended)
Module
More About NED Language

Interface instantiation
 Module and channel interfaces
can be used as a placeholder
– where normally a module
or channel type would be
used
 Concrete module or channel
type determined
– At network setup time by a
parameter
 More About NED Language

Example

MobileHost compound module

Design time IMobility

Run time
ConstantSpeedMobility RandomWayPointMobility
More About NED Language

Packages
 Addresses name clashes
between different models
 Simplifies specifying which NED
files are needed by a specific
simulation model
 More About NED Language

Example

package book.simulations;
Package is a mechanism to organize various classes and files. The simulation
project inside of OMNeT++ is called "Book" and this NED file is found in the
"simulations" folder of the
Project.
Configuring OMNET++ Simulations
In this module

We shall understand
 Need for separating
models and
experiments
 Configuring simulations

 INI files

 OMNET++ INI file

editor
Configuring OMNET++ Simulations

Separation of Model and

Experiments
 Always good practice to try to
separate different aspects of
simulation
 Model topology
– NED file
– MSG file
 Model behavior
– C++ code
 Provides cleaner model
Configuring OMNET++ Simulations

Configuring simulations
 How to capture the effect of
different inputs?
– Run to run variables
 C++ and NED code do not have
such variables
 INI files provide a mechanism to
specify these parameters
– omnet.ini
Configuring OMNET++ Simulations

INI File Syntax

 Basically an ASCII text file
 Consists of
 Key-value pairs

<key>=<value>
 Configuring OMNET++ Simulations
INI File Editor
 INI File Editor lets the user configure simulation models for execution
 Both form-based and source editing
Configuring OMNET++ Simulations

INI File Editor

 Considers all NED declarations
 Simple modules

 Compound modules

 Channels, etc

 Fully relates this information to

the INI file contents
 Editor knows which INI file keys
match which module
parameters
 Configuring OMNET++ Simulations
My_Network Example omnet.ini
wildcarded as **
[General] No of Apps
network = book.simulations.My_Network
#We will make standardHost a TCP Session Application in order for it to
communicate#
**.standardHost.numTcpApps = 1
**.standardHost.tcpApp[0].typename = "TCPSessionApp"
**.standardHost.tcpApp[0].connectAddress = "standardHost1"
**.standardHost.tcpApp[0].connectPort = 1000
#We will make standardHost1 a TCP Echo Application, this means that it will send
an echo packet once it receives a packet.
**.standardHost1.numTcpApps = 1
**.standardHost1.tcpApp[0].typename = "TCPEchoApp"
**.standardHost1.tcpApp[0].localPort = 1000
**.standardHost1.tcpApp[0].echoFactor = 3.0
#**.ppp[*].queueType = "DropTailQueue"
#**.ppp[*].queue.frameCapacity = 10
#**.eth[*].queueType = "DropTailQueue"
 Configuring OMNET++ Simulations
Example
Application Name
[General]
network = book.simulations.My_Network
#We will make standardHost a TCP Session Application in order for it to
communicate#
**.standardHost.numTcpApps = 1
**.standardHost.tcpApp[0].typename = "TCPSessionApp"
**.standardHost.tcpApp[0].connectAddress = "standardHost1"
**.standardHost.tcpApp[0].connectPort = 1000
#We will make standardHost1 a TCP Echo Application, this means that it
will send #an echo packet once it receives a packet.
**.standardHost1.numTcpApps = 1
**.standardHost1.tcpApp[0].typename = "TCPEchoApp"
**.standardHost1.tcpApp[0].localPort = 1000
**.standardHost1.tcpApp[0].echoFactor = 3.0
#**.ppp[*].queueType = "DropTailQueue"
#**.ppp[*].queue.frameCapacity = 10
#**.eth[*].queueType = "DropTailQueue"
 Configuring OMNET++ Simulations
Example
Who to connect
[General] with whom
network = book.simulations.My_Network
#We will make standardHost a TCP Session Application in order for it to
communicate#
**.standardHost.numTcpApps = 1
**.standardHost.tcpApp[0].typename = "TCPSessionApp"
**.standardHost.tcpApp[0].connectAddress = "standardHost1"
**.standardHost.tcpApp[0].connectPort = 1000
#We will make standardHost1 a TCP Echo Application, this means that it
will send #an echo packet once it receives a packet.
**.standardHost1.numTcpApps = 1
**.standardHost1.tcpApp[0].typename = "TCPEchoApp"
**.standardHost1.tcpApp[0].localPort = 1000
**.standardHost1.tcpApp[0].echoFactor = 3.0
#**.ppp[*].queueType = "DropTailQueue"
#**.ppp[*].queue.frameCapacity = 10
#**.eth[*].queueType = "DropTailQueue"
 Configuring OMNET++ Simulations
Example
Which port to
[General] connect to
network = book.simulations.My_Network
#We will make standardHost a TCP Session Application in order for it to
communicate
**.standardHost.numTcpApps = 1
**.standardHost.tcpApp[0].typename = "TCPSessionApp"
**.standardHost.tcpApp[0].connectAddress = "standardHost1"
**.standardHost.tcpApp[0].connectPort = 1000
#We will make standardHost1 a TCP Echo Application, this means that it will send
#an echo packet once it receives a packet.
**.standardHost1.numTcpApps = 1
**.standardHost1.tcpApp[0].typename = "TCPEchoApp"
**.standardHost1.tcpApp[0].localPort = 1000
**.standardHost1.tcpApp[0].echoFactor = 3.0
#**.ppp[*].queueType = "DropTailQueue"
#**.ppp[*].queue.frameCapacity = 10
#**.eth[*].queueType = "DropTailQueue"
 Configuring OMNET++ Simulations
Example
Reply size =
[General] Echo Packet* EF
network = book.simulations.My_Network
#We will make standardHost a TCP Session Application in order for it to
communicate
**.standardHost.numTcpApps = 1
**.standardHost.tcpApp[0].typename = "TCPSessionApp"
**.standardHost.tcpApp[0].connectAddress = "standardHost1"
**.standardHost.tcpApp[0].connectPort = 1000
#We will make standardHost1 a TCP Echo Application, this means that it will send
#an echo packet once it receives a packet.
**.standardHost1.numTcpApps = 1
**.standardHost1.tcpApp[0].typename = "TCPEchoApp"
**.standardHost1.tcpApp[0].localPort = 1000
**.standardHost1.tcpApp[0].echoFactor = 3.0
#**.ppp[*].queueType = "DropTailQueue"
#**.ppp[*].queue.frameCapacity = 10
#**.eth[*].queueType = "DropTailQueue"
 Configuring OMNET++ Simulations
Example
Queuing behaviour
[General]
network = book.simulations.My_Network
#We will make standardHost a TCP Session Application in order for it to
communicate
**.standardHost.numTcpApps = 1
**.standardHost.tcpApp[0].typename = "TCPSessionApp"
**.standardHost.tcpApp[0].connectAddress = "standardHost1"
**.standardHost.tcpApp[0].connectPort = 1000
#We will make standardHost1 a TCP Echo Application, this means that it will send
#an echo packet once it receives a packet.
**.standardHost1.numTcpApps = 1
**.standardHost1.tcpApp[0].typename = "TCPEchoApp"
**.standardHost1.tcpApp[0].localPort = 1000
**.standardHost1.tcpApp[0].echoFactor = 3.0
#**.ppp[*].queueType = "DropTailQueue"
#**.ppp[*].queue.frameCapacity = 10
#**.eth[*].queueType = "DropTailQueue"
 Configuring OMNET++ Simulations
Example
Buffer Size
[General]
network = book.simulations.My_Network
#We will make standardHost a TCP Session Application in order for it to
communicate
**.standardHost.numTcpApps = 1
**.standardHost.tcpApp[0].typename = "TCPSessionApp"
**.standardHost.tcpApp[0].connectAddress = "standardHost1"
**.standardHost.tcpApp[0].connectPort = 1000
#We will make standardHost1 a TCP Echo Application, this means that it will send
#an echo packet once it receives a packet.
**.standardHost1.numTcpApps = 1
**.standardHost1.tcpApp[0].typename = "TCPEchoApp"
**.standardHost1.tcpApp[0].localPort = 1000
**.standardHost1.tcpApp[0].echoFactor = 3.0
#**.ppp[*].queueType = "DropTailQueue"
#**.ppp[*].queue.frameCapacity = 10
#**.eth[*].queueType = "DropTailQueue"
Configuring OMNET++ Simulations
Example
Building Simulation Programs
In this module

We shall cover
 Build Process

 How to build

 OMNET++ simulations
Building Simulation Programs
End-to-End Process
(Build + Configure+ Run + Analyze)
Building Simulation Programs

Process of Build
 Same as building
any C/C++ program from source
– All C++ sources need to be
compiled into object files
– All object files need to be
linked with
necessary libraries to get
• Executable
• Or shared library
 Building Simulation Programs

Using GUI Project Builder

 Initial build takes longer on indexing before building the project
 Dependency generation in the generated makefiles
– Classes, functions, methods, variables, macros
 Building Simulation Programs

Using Mingwenv
 Once you have the source files ( *.ned, *.msg, *.cc, *.h) in a directory
– Change the working directory to there
 Type

$ opp_makemake
 This will create a file named Makefile

 Type

$ make
 Your simulation program should build

A makefile is used to tell the compiler which source files

you want to compile. It'll also do things like name your
executable and place it in a specific location.
Building Simulation Programs
Where to next!
Running Simulations
In this module

We shall cover
 What is a simulation

run?
 Quick Run

 Creating run

configuration
Running Simulations

What is Simulation Run?

 Launch the built project make
file
Running Simulations

OMNET++ IDE Features

 Single runs
 Batch runs

 Run numbers

 Graphical mode (Tkenv)

 Command mode

(Cmdenv)
 Simulation configuration

 Recording event logs

 Debug support
Running Simulations

Quick Run
 In Project Explorer, select a
project
 Clicking Run button on the
toolbar
 Runs vary
– Folder
• Runs if single ini file
present
– ini file
• Use this as the main ini
file
– NED file
• Scan for available ini file
Running Simulations
Launch Configuration

Run omnet.ini
From /queuenet

queuenet Launch
Configuration
Running Simulations
Launch Configuration

One or more
ini files
Running Simulations
Launch Configuration

Run number
R=0
One omnet.ini
one exe
Running Simulations
Launch Configuration

Directories where
the NED files
are read from
Running Simulations
Where to next!
Animation and Tracing
In this module

We shall cover
 What is animation

of simulation?
 What is traceability of

simulation models?
 Object inspection

 Tkenv and its feature

set
Animation and Tracing
Animating Simulation(1 of
2)
OMNeT++ is capable of
 Animating

– Flow of messages on
network charts
 Reflecting

– State changes of the

nodes in the display
Animation and Tracing
Animating Simulation(2 of
2)
 Animation is automatic
 No programming need for

simulating engineer
 Suitable network simulations

– Rarely need fully

customizable animation
capabilities
Animation and Tracing
Simulation Tracing
 Simple modules may write
textual debug (trace)
information like printf()
 OMNET++ provides Module

output window
– Special window to
display output stream
 Eases following the module

execution
Animation and Tracing
Simulation Object
Inspection
 An object inspector is a GUI
window associated with a
simulation object
– Displays contents and
properties
 Three types
– Network Display
– Log Viewer
– Object Inspector
Animation and Tracing
Tkenv (1 of 2)
Tkenv is a graphical runtime
interface for simulations
 It provides
– Network visualization
– Message flow animation
– Log of message flow
– Display of textual module
logs
Animation and Tracing
Tkenv (2 of 2)
 Inspectors
 Visualization of statistics
– Histograms, etc. during
simulation execution
 Event log recording for later
analysis
 Animation and Tracing
Tkenv in action
Timeline
Object inspector
Future Events Set (FES) on log scale

Network Log
display viewer
Organizing and Performing Experiments
In this module

We shall understand
 Need for organizing experiments

 How to organize and perform

experiments
Organizing and Performing Experiments
Need for organizing
experiments
(1 of 4)
Stuart Kurkow, “MANET
Simulation
Studies:
The Incredibles,” ACM’s
MobileComputing and
Communications
Review, 9(4):
50-61, 2005
Organizing and Performing Experiments
Need for organizing
experiments
(2 of 4)
Repeatable
 Fellow researcher

should be able to
repeat
Unbiased
 Results must not be specific to

scenario
used in experiment
Organizing and Performing Experiments
Need for organizing
experiments
(3 of 4)
Rigorous
 Scenarios & conditions

for experiments must

be truly representative
Statistically sound
 Experiments results

must not violate mathematical

principles
 Organizing and Performing Experiments
Need for organizing experiments (4 of 4)

Courtesy:
 Organizing and Performing Experiments
Relationship between terminologies
Organizing and Performing Experiments
How to organize
experiments
(1 of 6)
Model
 The executable

 (C++ files & external libraries +

NED files
 Invariant for the

purpose of experimentation
 INI file not part of

model
Organizing and Performing Experiments
How to organize
experiments
(2 of 6)
Study
 One or more

experiments
to investigate a phenomenon
 Usually many experiments

 One or more models

Organizing and Performing Experiments
How to organize
experiments
(3 of 6)
Experiment
 Exploration of a parameter

space on a model
 Only and only one model
Organizing and Performing Experiments
How to organize
experiments
(4 of 6)
Measurement
 A set of simulation runs on

the same model with same

parameters
 Characterized by INI file

 But with different seeds

 May involve replication for

averaging out
Organizing and Performing Experiments
How to organize
experiments
(5 of 6)
Replication
 One repetition of a

measurement
 Replication can be

characterized by the seed

values it uses
Organizing and Performing Experiments
How to organize
experiments
(6 of 6)
Run
 One instance of

running the simulation

 Characterized by

 exact time/date

 computer (host name)

 Organizing and Performing Experiments
Example

Handover
optimization
for
Mobile IPv6
 Organizing and Performing Experiments
Example

Mobile IPv6
nodes
 Organizing and Performing Experiments
Example

Effect of
No. of hosts
Traffic load
 Organizing and Performing Experiments
Example

No of hosts
= 10
Load
= 3.8
Sequence Charts
In this module

We shall explore
 What are event log

tables?
 What are sequence

 charts?
Sequence Charts
Event Log Tables
(1 of 2)
 An eventlog file contains
― Tabulated log of messages

sent during simulation

 Between modules

 Self-messages (timers)

― Event details that prompts

such sending
or reception
Sequence Charts
Event Log Tables
(2 of 2)
 User can control
― Amount of data

recorded from
messages
― Start/stop time

― Which modules to include in

the log
Sequence Charts
Event Log File Creation (1 of
2)
 Type
$ record-eventlog = true
 Output placed in

/results directory
 Filename

${configname}-
${runnumber}.elog
 Sequence Charts
Event Log File Creation (2 of 2)
Using INI file event log configuration

Record event
Sequence Charts
Sequence Chart
 Displays eventlog files
in a graphical form
• Helps focus on causes
& consequences of
events/messages
• Helps users understand
― Complex simulation models

― Verify implementation for

desired behavior
Sequence Charts
Understanding the Legend

Simple module
Axis
Sequence Charts
Understanding the Legend

Compound module
Axis
Sequence Charts
Understanding the Legend

Axis with attached

vector data
Sequence Charts
Understanding the Legend

Module full path

as axis label
Sequence Charts
Understanding the Legend

Initialization event
Sequence Charts
Understanding the Legend

Self-message
processing event
Sequence Charts
Understanding the Legend

Message processing
event
Sequence Charts
Understanding the Legend

Event number
Sequence Charts
Understanding the Legend

Self-message
Sequence Charts
Understanding the Legend

Message send
Sequence Charts
Understanding the Legend

Message reuse
Sequence Charts
Understanding the Legend

Method call
Sequence Charts
Understanding the Legend

Message send
that goes far away
Sequence Charts
Understanding the Legend

Message name
Sequence Charts
Understanding the Legend

Method name
Sequence Charts
Understanding the Legend

Zero simulation
time region
Sequence Charts
Understanding the Legend

Simulation time
hairline
Sequence Charts
In this module

We shall understand
 Parts of sequence charts

 What is timeline?
 Types of timelines
 Interesting ways to
interpret sequence charts
Sequence Charts
Parts of Sequence Charts

Timeline gutters
Sequence Charts
Parts of Sequence Charts

Horizontal growth
w.r.t. time
Sequence Charts
Parts of Sequence Charts

Vertical growth
w.r.t. no. of modules
Sequence Charts
Parts of Sequence Charts

Modules, Events, Message Sends

Sequence Charts
What is Timeline?
 Simulation time mapped onto
the horizontal
axis
 Various ways

– Intervals between
interesting events
often of different magnitudes
 Example

– MAC (s)
– Higher layers (ms)
Sequence Charts
Types of Timeline
(1 of 2)
 Linear: simulation time
proportional to distance
measured in pixels
 Event number: event number
proportional to the distance
measured in pixels
Sequence Charts
Types of Timeline
(2 of 2)
 Step: distance between
subsequent events is same
 Nonlinear: distance between
subsequent events is
nonlinear function of
simulation time between
them
Sequence Charts
Interpreting Sequence
Charts
 Zero Simulation Time Regions
 Gutter
 Events
 Messages
 Displaying Module State on
Axes
 Sequence Charts
Zero Simulation Time Regions

Multiple events may occur at the same

simulation time
Gray background indicates that
the simulation time does not change
all events inside it have the same
simulation time
 Sequence Charts
Gutter

Vertical hairline Currently visible time

Time prefix value True time = in window =
2180 s + 2 s 60 ms 1.769 s ~ 2.4 s

Nonlinear time
 Sequence Charts
Events Processing

Self message proc

Initialization
Message proc

Receiving
Message proc
Sequence Charts
Messages

Message
 Sequence Charts
Displaying Module State on Axes

Color of axis changes as per the event

Output vector can be attached to an axis
IDLE for 0, TRANSMIT for 1
Recap: TicToc Tutorial
In this module

We shall cover TicToc tutorial to

recap
 Understanding NED file

 Understanding C++

file
 How to make the

project?
 Preparing INI file

 Launch the simulation

 Sequence chart
Recap: TicToc Tutorial
TicToc with 2-nodes
• Two nodes, Tic and Toc
• One node initializes by sending
a message
to the other
• Every time a node receives the
message
― Sends it back

• Continue indefinitely
― Till user stops
Recap: TicToc Tutorial
Creating an empty project
• Open the OMNeT++
IDE
• Navigate to File | New |
OMNeT++ Project
• Enter a Name for the project
• Next
 Recap: TicToc Tutorial
Select the Tictoc example file in the Examples folder
You have created Tictoc example project
Recap: TicToc Tutorial
Opening NED file
• In newly created
project, navigate to the
simulations folder in the Project
Explorer
• Open
Tictoc.ned
 Recap: TicToc Tutorial
Understanding toctoc1.ned
package example.simulations;
import example.Txc;
//
// Two instances (tic and toc) of Txc connected.
//
network Tictoc
{
submodules: Original simple
tic: Txc; module
toc: Txc;
connections:
tic.out --> {delay = 100ms;} --> toc.in;
tic.in <-- {delay = 100ms;} <-- toc.out;
}
Recap: TicToc Tutorial
Opening Simple Module
• Open project explorer
• Open src folder of this
project
• Open
Txc.ned
 Recap: TicToc Tutorial
Understanding Txc.ned
package example;
//
// Immediately sends out any message it receives. It can optionally
generate
// a message at the beginning of the simulation, to bootstrap the
process.
//
simple Txc Implements Txc.cc
{
parameters:
bool sendInitialMessage = default(false);
gates:
input in;
output out; One input gate
} One output gate
Recap: TicToc Tutorial
Opening Simple Module
• Open project explorer
• Open src folder of this
project
• Open
Txc.cc
 Recap: TicToc Tutorial
Understanding Txc.ned
#include "Txc.h" OMNET++
namespace example { Module
Define_Module(Txc); Initialize method
void Txc::initialize()
{
if (par("sendInitialMessage").boolValue())
{
cMessage *msg = new cMessage("tictocMsg");
send(msg, ""out"");
} HandleMessage
} method
void Txc::handleMessage(cMessage *msg)
{
// just send back the message we received
send(msg, "out"");
} Echo back
}; // namespace
 Recap: TicToc Tutorial
Understanding omnet.ini
[General]
network = Tictoc Starts the activity
cpu-time-limit = 60s
#debug-on-errors = true
**.tic.sendInitialMessage = true
Recap: TicToc Tutorial
Compiling &
Running on Tkenv
 Recap: TicToc Tutorial

Tictoc.tic

Tictoc.toc
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
Refine graphics &
 Tictoc2.ned
Add debugging output
• Txc2.cc
Extending TicToc
 Extending TicToc
Tictoc2.ned (1 of 2)
// "block/routing" icon to the simple module. All
submodules of type
// Txc2 will use this icon by default
//
simple Txc2
{
parameters:
@display("i=block/routing"); // add a default
icon
gates:
input in; Add icon
output out;
}
//
 Extending TicToc
Tictoc2.ned (2 of 2)
// Make the two module look a bit different with
colorization effect.
// Use cyan for `tic', and yellow for `toc'.
//
network Tictoc2
{
submodules: Change color
tic: Txc2 {
parameters:
@display("i=,cyan"); // do not change
the icon (first arg of i=) just colorize it
}
toc: Txc2 {
parameters:
@display("i=,gold"); // here too
}
connections:
 Extending TicToc
Txc2.cc (1 of 2)
class Txc2 : public cSimpleModule
{
protected:
virtual void initialize();
virtual void handleMessage(cMessage *msg);
};
Define_Module(Txc2); Debug
Message name
information
void Txc2::initialize()
{
if (strcmp("tic", getName()) == 0)
{
// The 'ev' object works like 'cout' in C++.
EV << "Sending initial message\n";
cMessage *msg = new cMessage("tictocMsg");
send(msg, "out");
}
}
 Extending TicToc
Txc2.cc (2 of 2)
void Txc2::handleMessage(cMessage *msg)
{
// msg->getName() is name of the msg object, here
it will be "tictocMsg".
EV << "Received message `" << msg->getName() <<
"', sending it out again\n";
send(msg, "out");
}
Debug
information
Extending TicToc
Tkenv output
Extending TicToc
Tkenv output
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
Add State Variables

• Add a counter as a class

member to the module
• Delete the message
after 10 exchanges
• Txc3.cc
 Extending TicToc
Txc3.cc (1 of 3)
class Txc3 : public cSimpleModule
{
private:
int counter; // Note the counter here
protected:
virtual void initialize();
virtual void handleMessage(cMessage *msg);
};
Define_Module(Txc3);
Counter
void Txc3::initialize()
{
// Initialize counter to ten. Let you examine the
counter = 10; variable under Tkenv.
WATCH(counter);
 Extending TicToc
Txc3.cc (2 of 3)

if (strcmp("tic", getName()) == 0)
{
EV << "Sending initial message\n";
cMessage *msg = new cMessage("tictocMsg");
send(msg, "out");
} Decrement counter
}
void Txc3::handleMessage(cMessage *msg)
{
// Decrement counter and check value.
counter--; If counter is zero,
if (counter==0) delete message
{
EV << getName() << "'s counter reached zero,
deleting message\n";
delete msg;
 Extending TicToc
Txc3.cc (3 of 3)

} Or show current
else counter value
{
EV << getName() << "'s counter is " <<
counter << ", sending back message\n";
send(msg, "out");
}
}
Extending TicToc
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
Adding parameters (1 0f
2)
• Add add input
parameters to the
simulations
– Count = 10 now into
a parameter that the
user can define
• tictoc4.ned
• Txc4.cc
• Omnet.ini
Extending TicToc
Adding parameters (1 0f
2)
– Boolean parameter
(decides if module
should send out first
message in its
initialization code)
• tictoc4.ned
• Txc4.cc
• Omnet.ini
 Extending TicToc
tictoc4.ned (1 of 2)
simple Txc4
{
parameters:
bool sendMsgOnInit = default(false); //
whether the module should send out a message on
initialization
int limit = default(2); // another parameter
with a default value
@display("i=block/routing");
gates: Simple module
input in;
output out; Parameters
} Send message on Initialization
Limit parameter
 Extending TicToc
tictoc4.ned (2 of 2)
// Adding module parameters.
//
network Tictoc4
{
submodules:
tic: Txc4 {
parameters:
sendMsgOnInit = true;
@display("i=,cyan"); Network
}
toc: Txc4 {
parameters:
sendMsgOnInit = false;
@display("i=,gold"); Assign values to
} parameters
 Extending TicToc
Txc4.cc

void Txc4::initialize()
{
// Initialize the counter with the "limit" module
parameter, declared in the NED file (tictoc4.ned).
counter = par("limit");

// we no longer depend on the name of the module

to decide whether to send an initial message
if (par("sendMsgOnInit").boolValue() == true)
{
EV << "Sending initial message\n";
cMessage *msg = new cMessage("tictocMsg");
send(msg, "out");
} Takes counter value
} From limit
Makes initialization
Independent of tic & toc
 Extending TicToc
Omnet.ini

Tictoc4.toc.limit = 5

// or Tictoc4.t*c.limit=5

// or Tictoc4.*.limit=5

// or **.limit=5

Value assignment to
limit parameter
Through ini file
(wildcard support)
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
Using Inheritance
 What is different
between tic and toc?
― Parameter values
― Display string
 Inheritance allows to
create a simple module
― Then derive modules
from it
• tictoc5.ned
 Extending TicToc
tictoc5.ned (1 of 4)
simple Txc5
{
parameters:
bool sendMsgOnInit = default(false);
int limit = default(2);
@display("i=block/routing");
gates:
input in;
output out;
} Base module

Generalized parameters
 Extending TicToc
tictoc5.ned (2 of 4)
simple Tic5 extends Txc5
{
parameters: Declare tic
@display("i=,cyan");
sendMsgOnInit = true; // Tic modules should
//send a message on init
}

Assign value
 Extending TicToc
tictoc5.ned (3 of 4)
simple Toc5 extends Txc5
{
parameters: Declare toc
@display("i=,gold");
sendMsgOnInit = false; // Tic modules should
// not send a message on init
}

Assign value
 Extending TicToc
tictoc5.ned (4 of 4)
network Tictoc5
{ Create network
submodules:
tic: Tic5; // the limit parameter is still unbound here.
We will get it from the ini file
toc: Toc5;
connections:

Use them as
submodule
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
Modeling processing
delay
 So far, no processing
delay in tictoc
 We need timer in
 Tictoc module to send
itself “Event” message
• tictoc6.ned
• txc6.cc
 Extending TicToc
Strategy
 Initialize after 5 seconds
 Hold the message for 1 simulated second
― Send a message to itself

― Send it back When to send

 Need to add two variables to the class
― event What to send
― tictocMessage

tic toc
5s 1s 1s
 Extending TicToc
tx6.cc (1 of 2)
void Txc6::initialize()
{
// Create the event object (ordinary message) for
//timing
event = new cMessage("event");
tictocMsg = NULL;
if (strcmp("tic", getName()) == 0)
EV << "Scheduling first send to t=5.0s\n";
tictocMsg = new cMessage("tictocMsg");
scheduleAt(5.0, event);
}
Defining event
}

Operation of event
 Extending TicToc
tx6.cc (2 of 2)
void Txc6::handleMessage (cMessage * msg)
{
if (msg==event)
{EV << "Wait period is over, sending back message\n";
send(tictocMsg, "out");
tictocMsg = NULL;
} Self message
Else
{
EV << "Message arrived, starting to wait 1 sec...\n";
tictocMsg = msg;
scheduleAt(simTime()+1.0, event);
}
}
External message
(from the other side)
Extending TicToc
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
Modeling processing
delay
 So far, no processing
delay in tictoc
 We need timer in
 Tictoc module to send
itself “Event” message
• tictoc6.ned
• txc6.cc
 Extending TicToc
Strategy
 Initialize after 5 seconds
 Hold the message for 1 simulated second
― Send a message to itself

― Send it back When to send

 Need to add two variables to the class
― event What to send
― tictocMessage

tic toc
5s 1s 1s
 Extending TicToc
tx6.cc (1 of 2)
void Txc6::initialize()
{
// Create the event object (ordinary message) for
//timing
event = new cMessage("event");
tictocMsg = NULL;
if (strcmp("tic", getName()) == 0)
EV << "Scheduling first send to t=5.0s\n";
tictocMsg = new cMessage("tictocMsg");
scheduleAt(5.0, event);
}
Defining event
}

Operation of event
 Extending TicToc
tx6.cc (2 of 2)
void Txc6::handleMessage (cMessage * msg)
{
if (msg==event)
{EV << "Wait period is over, sending back message\n";
send(tictocMsg, "out");
tictocMsg = NULL;
} Self message
Else
{
EV << "Message arrived, starting to wait 1 sec...\n";
tictocMsg = msg;
scheduleAt(simTime()+1.0, event);
}
}
External message
(from the other side)
Extending TicToc
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
Random numbers and
parameters
 Introduce random
numbers in simulation
– Randomly lose
packet
– Change delay from
1s to a random value
• txc7.cc
• tictoc7.ned
Or omnetpp.ini
 Extending TicToc
txc7.cc (1 of 2)
void Txc7::handleMessage(cMessage *msg)
{
if (msg==event)
{
EV << "Wait period is over, sending back
message\n";
send(tictocMsg, "out");
tictocMsg = NULL;
Lose the message
}
with 0.1 probability
else
{
if (uniform(0,1) < 0.1)
{
EV << "\"Losing\" message\n";

delete msg;
}
 Extending TicToc
txc7.cc (2 of 2)
else
{
// The "delayTime" module parameter set
// to "exponential(5)" in tictoc7.ned so
// we'll get a different delay every time.

simtime_t delay = par("delayTime");

EV << "Message arrived, starting to wait "

<< delay << " secs...\n";
tictocMsg = msg;
delay parameter
scheduleAt(simTime()+delay, event); coming from .ned
}
 Extending TicToc
tictoc7.ned
network = Tictoc7
# argument to exponential() is the mean

Tictoc7.tic.delayTime = exponential(3s)

mean
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
Timeout, cancelling
timers
 Getting closer to real
world working
protocols
 Stop-and-wait protocol
• txc8.cc
• tictoc8.ned
• omnetpp.ini
 Extending TicToc
Strategy
Timeout = 1
Send out “tictocMsg”

Toc
Initial Wait for Timeout
state Msg from resend Msg If probability > .1
toc
Lose Msg

Msg arrived
Wait for
cancel timer
Msg from
Resend message
tic
Tic
If probability < .1
Echo Msg
 Extending TicToc
txc8.cc (1 of 3)
void Tic8::initialize()
{
// Initialize variables. Initialize with timeout
= 1 to start operation
timeout = 1.0;
timeoutEvent = new cMessage("timeoutEvent");

// Generate and send initial message.

EV << "Sending initial message\n";

cMessage *msg = new cMessage("tictocMsg");
send(msg, "out");
scheduleAt(simTime()+timeout, timeoutEvent);
}
 Extending TicToc
txc8.cc (2 of 3)
void Tic8::handleMessage(cMessage *msg)
{
if (msg==timeoutEvent) timeout means we
{ have to re-send it
EV << "Timeout expired, resending and restarting
timer\n";
cMessage *newMsg = new cMessage("tictocMsg");
send(newMsg, "out");
scheduleAt(simTime()+timeout, timeoutEvent);
}
 Extending TicToc
txc8.cc (3 of 3)
else
{
// delete received message & cancel timeout event.

EV << "Timer cancelled.\n"; message arrived

cancelEvent(timeoutEvent); Ack received
delete msg;

//Ready to send another one.

cMessage *newMsg = new cMessage("tictocMsg");

send(newMsg, "out");
scheduleAt(simTime()+timeout, timeoutEvent);

}
}
Extending TicToc
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
Retransmitting same
message (1 of 2)
 So far we used
“tictocMsg”
 It was created afresh
everytime
– At tic
– At toc
Extending TicToc
Retransmitting same
message (2 of 2)
 In reality, original
packet needs to be
retransmitted
 Solution: Keep a copy
with tic
• txc9.cc
• tictoc9.ned
• omnetpp.ini
 Extending TicToc
Strategy
 Create two new functions
 Conditionally call them in tic and toc

generateNewMessage() sendCopyOf()

Tic Toc
 Extending TicToc
Txc9.cc (1 of 2)
void Tic9::handleMessage(cMessage *msg)
{
if (msg==timeoutEvent)
{
EV << "Timeout expired, resending message and
restarting timer\n";

sendCopyOf(message);

scheduleAt(simTime()+timeout, timeoutEvent);
}
Retransmit the same
packet
 Extending TicToc
Txc9.cc (2 of 2)
else // message arrived
{
// Acknowledgement received!
// Ready to send another one.

message = generateNewMessage();

sendCopyOf(message);

scheduleAt(simTime()+timeout, timeoutEvent);
}
Transmit a new
packet
 Extending TicToc
generateNewMessage()
{
// Generate a message with a different name every time.
char msgname[20];
sprintf(msgname, "tic-%d", ++seq);
cMessage *msg = new cMessage(msgname);
return msg;
} Increments seq no
and is value of %d
Prints the string on
Location of length 20
pointed by msgname Displays string which
is seq no as decimal
 Extending TicToc
sendCopyOf(cMessage *msg)
{
// Duplicate message and send the copy.

cMessage *copy = (cMessage *) msg->dup();

send(copy, "out");
} Creates & returns an
exact copy of msg
Value of copy
taken from msg
Casts return value of
dup() to a pointer of
cMessage type
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
More than 2 nodes (1 of
2)
 Create several tic
modules
 Connect them into a
network
 One of the nodes
generates a message
Extending TicToc
More than 2 nodes (2 of
2)
 Others toss it around
in random directions
 Until it arrives at a
predetermined
destination
 tictoc10.ned
 omnetpp.ini
 txc10.cc
 Extending TicToc
Tictoc10.ned (1 of 2)
simple Txc10
{
parameters:
@display("i=block/routing");
gates:
input in[]; // declare in[] and out[] to be
vector gates
output out[];
}

[ ] turns the gates

into gate vectors
 Extending TicToc
Tictoc10.ned (2 of 2)
network Tictoc10
{ size of the vector (no.
submodules: of gates) determined here
tic[6]: Txc10;
connections:
tic[0].out++ --> { delay = 100ms; } --> tic[1].in++;
tic[0].in++ <-- { delay = 100ms; } <-- tic[1].out++;
tic[1].out++ --> { delay = 100ms; } --> tic[2].in++;
tic[1].in++ <-- { delay = 100ms; } <-- tic[2].out++;
tic[1].out++ --> { delay = 100ms; } --> tic[4].in++;
tic[1].in++ <-- { delay = 100ms; } <-- tic[4].out++;
tic[3].out++ --> { delay = 100ms; } --> tic[4].in++;
tic[3].in++ <-- { delay = 100ms; } <-- tic[4].out++;
tic[4].out++ --> { delay = 100ms; } --> tic[5].in++;
tic[4].in++ <-- { delay = 100ms; } <-- tic[5].out++;
}
 Extending TicToc
Txc10.cc (1 of 3)
void Txc10::initialize()
{ tic[0] generates the
if (getIndex()==0) message to be sent around
{
// Boot the process scheduling the initial
message as a self-message.
char msgname[20];
sprintf(msgname, "tic-%d", getIndex());
cMessage *msg = new cMessage(msgname);
scheduleAt(0.0, msg);
}
}
 Extending TicToc
Txc10.cc (2 of 3)
void Txc10::handleMessage(cMessage *msg)
{ message arrives at tic[3]
if (getIndex()==3) (final destination!)
{
// Message arrived.
EV << "Message " << msg << " arrived.\n";
delete msg;
}
else
{
// We need to forward the message.
forwardMessage(msg);
}
}
 Extending TicToc
Txc10.cc (3 of 3)
void Txc10::forwardMessage(cMessage *msg)
{
// In this example, we just pick a random gate to
send it on.
// We draw a random number between 0 and the size of
gate `out[]'.
int n = gateSize("out");
int k = intuniform(0,n-1);

EV << "Forwarding message " << msg << " on port

out[" << k << "]\n";
send(msg, "out", k); Uniform distribution with
} Probability = 1/6
Extending TicToc
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
Channels & inner type
definitions (1 of 2)
 With growing topology
– We can improve
connection section
 tictoc11.ned
 omnetpp.ini
 txc11.cc
Extending TicToc
Channels & inner type
definitions (2 of 2)
 Connections with
same delay parameter
can be typified as
channel
 Such channel can then
be replicated between
gates
 Extending TicToc
Tictoc11.ned (1 of 2)
network Tictoc11
{ types section defines
types: new channel type
channel Channel extends ned.DelayChannel {
delay = 100ms;}

types definition only

visible inside network
(local or inner type)
 Extending TicToc
Tictoc11.ned (2 of 2)
connections:
tic[0].out++ --> Channel --> tic[1].in++;
tic[0].in++ <-- Channel <-- tic[1].out++;

tic[1].out++ --> Channel --> tic[2].in++;

tic[1].in++ <-- Channel <-- tic[2].out++;

tic[1].out++ --> Channel --> tic[4].in++;

tic[1].in++ <-- Channel <-- tic[4].out++;

tic[3].out++ --> Channel --> tic[4].in++;

tic[3].in++ <-- Channel <-- tic[4].out++;

tic[4].out++ --> Channel --> tic[5].in++;

tic[4].in++ <-- Channel <-- tic[5].out++;
}
Delay parameter for whole network easily changed
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
Using two-way
connections (1 of 2)
 So far, each node pair is
connected with two
connections
 Two-way connection can
reduce coding size
 tictoc12.ned
 txc12.cc
 omnetpp.ini
Extending TicToc
Using two-way
connections (2 of 2)
 We define two-way
(inout) gates
– Instead of in and out
gates
 Extending TicToc
Tictoc12.ned (1 of 2)
simple Txc12
{
parameters:
@display("i=block/routing");
gates:
inout gate[]; // declare two way connections
}

inout gate defined for

both incoming and
outgoing messages
 Extending TicToc
Tictoc12.ned (2 of 2)
connections:
tic[0].gate++ <--> Channel <--> tic[1].gate++;
tic[1].gate++ <--> Channel <--> tic[2].gate++;
tic[1].gate++ <--> Channel <--> tic[4].gate++;
tic[3].gate++ <--> Channel <--> tic[4].gate++;
tic[4].gate++ <--> Channel <--> tic[5].gate++;
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
Defining our message
class
 Instead of hardcoding
tic[3], we need flexibility
 Draw out a random
destination
 Add Destination address
 tictoc13.ned
 txc13.cc
 tictoc13.msg
 omnetpp.ini
 Extending TicToc
Strategy (1 of 2): Avoid boilerplate code writing

tictoc13.msg
subclasses cMessage
& adds destination as
a data member
 Extending TicToc
Strategy (2 of 2): Avoid boilerplate code writing

HeaderFile
generates
tictoc13_m.h
FileName ClassName
Included in
tictoc13.msg c++ code TicTocMsg13
CPlusPlusFile
The class has getter
and setter (mutator)
tictoc13_m.cc
Compiling and methods for every
linking field
 Extending TicToc
Txc13.cc (1 of 3)
TicTocMsg13 *Txc13::generateMessage()
{
// Produce source and destination addresses.

int src = getIndex(); // our module index Except itself

int n = size(); // module vector size
int dest = intuniform(0,n-2);
if (dest>=src) dest++; Msg shows
char msgname[20]; Addressing info
sprintf(msgname, "tic-%d-to-%d", src, dest);

// Create message object & set source and destination

field.
TicTocMsg13 *msg = new TicTocMsg13(msgname);
msg->setSource(src);
msg->setDestination(dest);
return msg;
 Extending TicToc
Txc13.cc (2 of 3)
void Txc13::handleMessage(cMessage *msg)
{
TicTocMsg13 *ttmsg = check_and_cast<TicTocMsg13 *>(msg);
if (ttmsg->getDestination()==getIndex())
{// Message arrived.
EV << "Message " << ttmsg << " arrived after " <<
ttmsg->getHopCount() << " hops.\n";
bubble("ARRIVED, starting new one!");
delete ttmsg; Only destination
// Generate another one. address responds
EV << "Generating another message: ";
TicTocMsg13 *newmsg = generateMessage();
EV << newmsg << endl;
Destination becomes
forwardMessage(newmsg);
source now
}
else // We need to forward the message. Its not the
{ forwardMessage(ttmsg); destination
}
}
 Extending TicToc
Txc13.cc (3 of 3)
void Txc13::forwardMessage(TicTocMsg13 *msg)
{
// Increment hop count.

msg->setHopCount(msg->getHopCount()+1);

// Same routing as before: random gate.

Output gate of
inout gate
int n = gateSize("gate");
int k = intuniform(0,n-1);

EV << "Forwarding message " << msg << "

on gate[" << k << "]\n";

send(msg, "gate$o", k);

}
Extending TicToc
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
Displaying no. of packets
sent/received
 No. of messages at each
node
 tictoc14.ned
 txc14.cc
 tictoc14.msg
 omnetpp.ini
 Extending TicToc
Txc14.cc (1 of 3)
class Txc14 : public cSimpleModule
{
private:
long numSent; Declared
long numReceived;
protected:
virtual void updateDisplay();

void Txc14::initialize()
{
// Initialize variables set to zero & WATCH'ed
numSent = 0; in initialize() method
numReceived = 0;
WATCH(numSent);
WATCH(numReceived);
 Extending TicToc
Txc14.cc (2 of 3)
void Txc14::handleMessage(cMessage *msg)
{
if (ttmsg->getDestination()==getIndex())
{ info appears
if (ev.isGUI()) above module
{ icons
updateDisplay();
}
}
}
 Extending TicToc
Txc14.cc (3 of 3)
void Txc14::updateDisplay() Similar to bubble
{ text but without
char buf[40]; bubble
sprintf(buf, "rcvd: %ld sent: %ld", numReceived,
numSent);
getDisplayString().setTagArg("t",0,buf);
}
 Extending TicToc
Object Inspector in Tkenv
Extending TicToc
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
Adding statistics
collection
 When packet traverses
multiple hops, it
becomes important to
collect network statistics
– Average hop count
– Max, min etc
 tictoc15.ned
 txc15.cc
 tictoc15.msg
 omnetpp.ini
 Extending TicToc
Strategy

Output Vector object

handleMessage()
(time, value)

Histogram object
(calculates mean,
SD etc)

//Results directory
Tictoc15-0.vec Tictoc15-0.sca
 Extending TicToc
Txc15.cc (1 of 3)
class Txc15 : public cSimpleModule
{
private: The finish() function is
long numSent; called by OMNeT++
long numReceived; at the end of the
cLongHistogram hopCountStats; simulation
cOutVector hopCountVector;
virtual void finish();

HopCountVector.record
outputs to vector file
 Extending TicToc
Txc15.cc (2 of 3)
void Txc15::handleMessage(cMessage *msg)
{
// Message arrived
int hopcount = ttmsg->getHopCount();
EV << "Message " << ttmsg << " arrived after "
<< hopcount << " hops.\n";
bubble("ARRIVED, starting new one!");

numReceived++;
hopCountVector.record(hopcount);
hopCountStats.collect(hopcount);
}

Update the statistics

 Extending TicToc
Txc15.cc (3 of 3)
void Txc15::finish()
{ EV << "Sent: " << numSent << endl;
EV << "Received: " << numReceived << endl;
EV << "Hop count, min: " <<
hopCountStats.getMin() << endl;
EV << "Hop count, max: " <<
hopCountStats.getMax() << endl;
EV << "Hop count, mean: " <<
hopCountStats.getMean() << endl; Records the statistics
EV << "Hop count, stddev: " << into the scalar result file
hopCountStats.getStddev() << endl; And displays “Hop count”
recordScalar("#sent", numSent);
recordScalar("#received", numReceived);

hopCountStats.recordAs("hop count");
}
Extending TicToc
Records the vector as time
series
Extending TicToc
Histogram during the
simulation run
Extending TicToc
In this module

We shall extend TicToc

tutorial
 Refine graphics, & add

debugging output
 Add state variables

 Add parameters

 Model processing delay

 And more!
 Extending TicToc

2. Refine graphics & 7. Random numbers & 12. Using two-way

add debugging output parameters connections

8. Timeout, 13. Defining our

3. Add state variables
Cancelling timers message class

9. Retransmitting 14. Displaying number of

4. Adding parameters
same message packets sent/received

15. Visualizing output

5. Using inheritance 10. More than two nodes scalars and vectors

6. Modeling processing 11. Channels & inner 16. Sequence charts and
delay type definitions event logs
Extending TicToc
Visualizing output scalars
& vectors
 OMNET++ allows to
visualize outputs of
scalar and vector files
– Filtering
– Processing
– Displaying
Extending TicToc

Vector data for node 0

and node 1 as time series
Extending TicToc
Applying mean operation
allows us to see how hop
count converges to average
Extending TicToc
scalar data recorded at the
end of the simulation shows
mean and maximum
Extending TicToc
Histogram of hop count
distribution
Analyzing Results
In this module

We shall cover
 What is simulations analysis?

 Analysis files

 Creating analysis files

 Using analysis editor

Analyzing Results

What is Simulation
Analysis?
 Analyzing simulation results is
lengthy and time consuming
process
 Result are recorded as scalar
values, vector values and
histograms
 User can apply statistical
methods
– Extract the relevant
information
– Draw conclusions
Analyzing Results

Analysis File (.anf)

 A file that automates the
steps to analyze the results
– Loading result files
– Filter them
– Transform data
– Chartify the results
Analyzing Results

Creating Analysis File

Quick way
 Double-click on the result file in the Project

Explorer View
 Open the New Analysis File dialog

– Folder and file name get prefilled

(according to location and name of
result file)
 Analyzing Results
Using the Analysis Editor
Input files Datasets Charts

Selecting input files Editing datasets Creating charts

Browsing input Computing vectors Editing charts

Filter expressions Computing scalars

 Analyzing Results
Using the Analysis Editor
Input files

Selecting input files

Browsing input

Filter expressions
 Analyzing Results
Using the Analysis Editor
Input files

Selecting input files

Browsing input

Filter expressions
 Analyzing Results
Using the Analysis Editor
Input files A filter expression is composed of atomic
patterns with the AND, OR, NOT operators
Selecting input files
It has the form <field_name> (<pattern>)

Example
Browsing input
module(**.sink) AND (name("queuing
time") OR
name("transmission time"))
Filter expressions
Results in queuing times and transmission
times that are written by modules
named sink.
 Analyzing Results
Using the Analysis Editor

Datasets

Editing datasets

Computing vectors

Computing scalars
 Analyzing Results
Using the Analysis Editor
Datasets
 Describe a set of input data, the processing applied to
them and the charts
 Displayed as a tree of processing steps and charts
 Nodes are used for
― Adding and discarding data

― Applying processing to vectors and scalars

― Selecting the operands of the operations

― Content of charts, and for creating charts

Editing Datasets
In this module

We shall understand
 How to edit datasets?

 Computing vectors

 Computing scalars

 Computation examples
 Editing Datasets
Datasets
 Describe a set of input data, the processing applied
to them and the charts
 Displayed as a tree of processing steps and charts
 Nodes are used for
― Adding and discarding data

― Applying processing to vectors and scalars

― Selecting the operands of the operations

― Content of charts, and for creating charts

 Editing Datasets
New elements can be added by dragging
elements from the palette on the right
 Editing Datasets
 Processing steps within a Group node only affect the group
 Allows branches to be created in the dataset
 A range of siblings can be grouped together by choosing “Group”
 Editing Datasets
What is Compute Vectors?
 Both Compute Vectors and Apply to Vectors nodes
compute new vectors from other vectors
 Editing Datasets
 Computations can be applied to the data by adding Apply to Vectors
/Compute Vectors/Compute Scalars nodes to the dataset
 Editing Datasets
What is Compute Scalars?
 The Compute Scalars dataset node adds new
scalars to the dataset whose values are computed
from other statistics in the dataset
 Editing Datasets
Determine loss through dividing received packets by
sent packets
Editing Datasets
Finally we are done!
Computation Examples 1
In this module

We shall take various

computation examples
 Bit rate

 Throughput

 Total received bytes

 Bytes received by hosts

 Average of peak delay

 Computation Examples 1
Bit rate
 Assume several source modules in the network that
generate CBR traffic
 Parameterized with packet length (in bytes) and
send interval (seconds)
 Both parameters saved as scalars by each module
(pkLen, sendInterval)
 To use the bit rate for further computations or charts
– Add a Compute Scalar node with the following
content to create an additional bit rate scalar for
each source module
Value: pkLen*8/sendInterval
Name: bitrate
 Computation Examples 1
Throughput
 Assume several sink modules record
rcvdByteCount scalars, and simulation duration is
saved globally as the duration scalar of the top-level
module.
 We are interested in the throughput at each sink
module
 We need to refer to the duration scalar by its
qualified name (prefix it with the full name of its
module)
 rcvdByteCount can be left unqualified
Value:8*rcvdByteCount/Network.duration
Name: throughput
 Computation Examples 1
Total Received Bytes
 We are interested in the total number of bytes
received in the network
 We can use the sum() function
 We store the result as a new scalar of the toplevel
module, Network.
Value: sum(rcvdByteCount)
Name: totalRcvdBytes
Module: Network
 Computation Examples 1
Bytes Received by Hosts
 If several modules record scalars named
rcvdByteCount
 We are only interested in the ones recorded from
network hosts
 you can qualify the scalar name with a pattern
Value: sum(**.host*.**.rcvdByteCount)
Name: totalHostRcvdBytes
Module: Network
 Computation Examples 1
Average of Peak Delay
 If several modules record vectors named end-to-
end delay
 We are interested in average of the peak end-to-
end delays experienced by each module
 We can use the max() function on the vectors to get
the peak
 Then we need mean() to obtain their averages

Value: mean(max('end-to-end delay'))

Name: avgPeakDelay
Module: Network
Computation Examples 2
In this module

We shall take various

computation examples
 Packet loss per client-server pair

 total number of

transport packets
 Modules with largest

RTTs
 Computation Examples 2
Packet loss per client-server pair
 3 clients (cli0, cli1, cli2) and 3 servers (srv0, srv1,
srv2) in the network
 Each client sends datagrams to the corresponding
server
 Packet loss per client-server pair computed from
the number of sent and received packets.
 We use the i variable to match the corresponding
clients and servers.
Value: Net.cli${i={0..2}}.pkSent -
Net.srv{i}.pkRcvd
Name: pkLoss
Module: Net.srv${i}
 Computation Examples 2
Total No. of Transport Packets
 When input scalars are recorded by different
modules
– We need the host variable to match TCP and
UDP modules under the same host
 Compute the total number of transport packets (the
sum of the TCP and UDP packet counts) for each
host
Value: ${host=**}.udp.pkCount +
${host}.tcp.pkCount
Name: transportPkCount
Module: ${host}
 Computation Examples 2
Modules with largest RTT (1 of 2)
 A network has various modules recording ping
round-trip delays (RTT)
 We want to count the modules with large RTT values
(where the average RTT is more than twice the
global average in the network)
 We need to do it in steps

Step 1:
Value: mean('rtt:vector')
Name: average
 Computation Examples 2
Modules with largest RTT (2 of 2)
Step 2:
Value: average / mean(**.average)
Name: relativeAverage

Step 3:
Value: count(relativeAverage)
Grouping: value > 2.0 ? "Above" : "Normal"
Name: num${group}
Module: Net
Simulation Models and INET
In this module

We shall cover
 What is a simulation

model?
 Types of Simulation Models

 INET
Simulation Models and INET
What is Simulation
Model?
 As we know that
OMNET++ is not a simulation
itself
 It is a framework that allows

other simulation frameworks

– To be created
– To be simulated
 Simulation frameworks are

simulation libraries
– Implement protocols
Simulation Models and INET
Types of Simulation Model
(1 of 2)
 Domain-specific functionality is
provided by model frameworks
– WSNs
– Ad-hoc networks
– Internet protocols,
– Performance modeling
– Photonic networks, etc.,
 Developed as independent
projects
Simulation Models and INET
Types of Simulation Model
(2 of 2)
 Reusability of models in
OMNeT++ is due to its
modular architecture
 Simulation models are easily
integrated into OMNET++

https://omnetpp.org/models
Simulation Models and INET
Some Well-known Types
 INET Framework
 OverSim
 Veins
 INETMANET
 MIXIM
 Castalia
Simulation Models and INET
INET (1 of 2)
 The INET Framework can be
considered the standard
protocol model library of
OMNeT++
 Contains models for the
Internet stack
― TCP, UDP, IPv4, IPv6, OSPF,

BGP, etc
Simulation Models and INET
INET (2 of 2)
 Wired and wireless link layers
― Ethernet, PPP, 802.11, etc)

 Support for mobility

 QoS support
― DiffServ, RSVP

 Several application models

 Maintained by OMNeT++
team officially
Simulation Models and INET
OverSim
 Overlay and peer-to-peer
network simulation
framework
 Contains several models for
 Structured
― Chord

― Kademlia

― Pastry

 Unstructured
― GIA
Simulation Models and INET
Veins
 Inter-Vehicular
Communication (IVC)
simulation framework
 It is a road traffic
microsimulation model
Simulation Models and INET
INETMANET
 Fork of INET framework
 Simulation framework for
mobile ad-hoc networks
 Written and maintained by
Alfonso Ariza.
Simulation Models and INET
MIXIM
 Modeling framework created
for
― Mobile wireless

― Fixed wireless

― WSNs

― BANs and VANs

― Ad-hoc networks

 Radiowave propagation
 Interference estimation
 Power consumption
 Wireless MAC protocols
Simulation Models and INET
CASTALIA
 Simulation framework for
networks of low-power
embedded devices
 Offers models for
― Temporal path loss

― Fine-grain interference

― RSSI calculation

― Physical process model

― Node clock drift

― MAC protocols
Design Tour of INET 1
In this module

We shall take a guided

Tour of INET to
 Understand how ARP works

in Ethernet environments
 Walk through features of

INET
 Peek into various

– Packets
– Queues
– Internal tables
Design Tour of INET 1

Why ARP scenario?

 While ARP is not the most
important protocol, it is very
interesting
 It relates to
– Ethernet
– IP
– And other higher layer
protocols
https://omnetpp.org/doc/inet/api-
current/neddoc/index.html
 Design Tour of INET 1
Scenario
 Client computer opens TCP session with server
 Rest of operations (including ARP) follow
– ARP has to learn the MAC address for the default router
Design Tour of INET 1

Usage Diagram for ARP

 Design Tour of INET 1

On simulation start
Ethernet autoconfiguration precedes
ARP
Design Tour of INET 2
In this module

We shall take a guided

Tour of INET to
 Understand how ARP works

in Ethernet environments
 Walk through features of

INET
 Peek into various

– Packets
– Queues
– Internal tables
Design Tour of INET 2

Entities at work
 Various compound modules interact
with each other
 TCP host on Ethernet
 Router
 TCP server
 How end-to-end transmission
takes place?
 Design Tour of INET 2
TCP Client
SYN sent
Activates
Network layer
that activates ARP
 Design Tour of INET 2
Router
ARP request
Activates
Router to send ARP
reply
 Design Tour of INET 2
TCP Server
ARP request/reply
Retrieve MAC addresses
at every hop till TCP
SYN request reaches in
IP packet at the server
that sends TCP
SYN/ACK
 Design Tour of INET 2
End-to-end transmission
Yellow: Node
Red: Collided and
transmitting on link
backing off
Design Tour of INET 3
In this module

We shall take a guided

Tour of INET to
 Understand how ARP works

in Ethernet environments
 Walk through features of

INET
 Peek into various

– Packets
– Queues
– Internal tables
Design Tour of INET 3

Ethernet Compound
Module
 In order to further understand how
INET works, let us explore Ethernet
(Compound Module)
 Consists of
― Arp

― Encap

― And Mac
 Design Tour of INET 3
Ethernet Compound Module
Right click to see the
module output
ARP)arpTest.client.eth[0
].arp
 Design Tour of INET 3
arpTest.client.eth[0].arp

module output
 Design Tour of INET 3
Inside ARP Packet
ARP Broadcast
Message
 Design Tour of INET 3
ARP Packet Class (Generated by .msg file)
This packet is
// file: ARPPacket.msg appended with
message ARPPacket broadcast address in
{ control info (a small
fields: data structure)
int opcode enum(ARPOpcode);
MACAddress srcMACAddress;
MACAddress destMACAddress;
IPAddress srcIPAddress;
IPAddress destIPAddress;
};
 Design Tour of INET 3

Packet Queue (Contains IP Packet)

This packet is
enqueued till ARP
resolution
Design Tour of INET 3

ARP Cache Build-up

Contents of ARP Cache
(entries with soft timers)
Introduction to top-down approach to modelling and
simulation
In this module

We shall understand
 What is top-down approach

to NeMS?
 Phased roll-out

 User-centric aspects
Introduction to top-down approach to modelling and
simulation

 Top-down approach
to NeMS
 Networks are complex to
design
 One-time design of
simulation is cumbersome
 Top-down: Phased roll-out
of model-simulate cycle
― Iterative
Introduction to top-down approach to modelling and
simulation
Rolling-out of model at every layer to Design
a Network

Application Throughput

Transport TCP variant

Network Router behaviour

Link LAN card, switch

and MAC protocol
Physical Modulation/Encoding
Introduction to top-down approach to modelling and
simulation
Design goodness (QoE) is user-centric aspects
Scalability Availability Performance Security
Manageability Usability Adaptability Affordability

Application

Transport

Network

Link

Physical
Introduction to top-down approach to modelling and
simulation
Strategy

Quantify Quality of Parameterize QoS

Experience (QoE) at each layer
Rules for Mathematical Reading

In this module

We develop an understanding
of
 Quantification

 Formalism

 Best practices to read

mathematical expressions
Rules for Mathematical Reading

What is mathematical modeling?

A Representation of an
object, a system, or an
idea in some form other
than that of the entity
itself.
(Shannon)
Rules for Mathematical Reading

Quantification
 The act of counting and
measuring that maps
human sense, observations
and experiences into
members of some set of
numbers
 Facts represented as
quantitative facts are the
basis of science
Rules for Mathematical Reading

Formalism
 Mathematics creates models
that have certain relationships
 Statements of mathematics
can be considered to be
statements about the
consequences of certain string
manipulation rules
Rules for Mathematical Reading

Best practices to read

mathematical expressions
(1 of 2)
A)Understanding math is like
understanding a foreign
language
B)Learn the formulas you
already understand
C)Always learn what the
formula will give you and the
conditions
Rules for Mathematical Reading

Best practices to read

mathematical expressions
(2 of 2)
D)Keep a chart of the formulas
you need to know
E)Math is often written in
different ways, but with the
same meaning
Rules for Mathematical Writing

In this module

We shall know
 Constituents of an equation

 Easy math writing

Rules for Mathematical Writing

What is an equation?
 A statement that the values of
two mathematical expressions
are equal
 indicated by “=” sign

 What is a formula then!

Rules for Mathematical Writing

Constituents of an
equation?
 Expressions consist of one or
more of these arguments
– Numerical constants
– Symbolic names
– Mathematical operators
– Functions
– Conditional expressions
Rules for Mathematical Writing

Easy math writing (1 of 3)

 2-3-4 rule
 Consider splitting every
– Sentence of more than 2
lines
– Sentence with more than
3 verbs
– Paragraph with more than
4 "long" sentences
Rules for Mathematical Writing

Easy math writing (2 of 3)

 Use mnemonics
– s for speed
– v for velocity
– t for time
Rules for Mathematical Writing

Easy math writing (3 of 3)

 Organize into segments
– An entity intended to
be read comfortably from
beginning to end!
 Segments are standalone

– Definite start
– Definite end
 Segments should be

represented linearly
 Rules for Mathematical Writing

Relationship between arguments of a

segment (1 of 3)

Hierarchical
 Rules for Mathematical Writing

Relationship between arguments of a

segment (2 of 3)

Nonlinear
with
crossing
Rules for Mathematical Writing

Relationship between arguments of a

segment (3 of 3)

Linear
Rules for Mathematical Writing

In this module

We shall know
 Constituents of an equation

 Easy math writing

Rules for Mathematical Writing

What is an equation?
 A statement that the values of
two mathematical expressions
are equal
 indicated by “=” sign

 What is a formula then!

Rules for Mathematical Writing

Constituents of an
equation?
 Expressions consist of one or
more of these arguments
– Numerical constants
– Symbolic names
– Mathematical operators
– Functions
– Conditional expressions
Rules for Mathematical Writing

Easy math writing (1 of 3)

 2-3-4 rule
 Consider splitting every
– Sentence of more than 2
lines
– Sentence with more than
3 verbs
– Paragraph with more than
4 "long" sentences
Rules for Mathematical Writing

Easy math writing (2 of 3)

 Use mnemonics
– s for speed
– v for velocity
– t for time
Rules for Mathematical Writing

Easy math writing (3 of 3)

 Organize into segments
– An entity intended to
be read comfortably from
beginning to end!
 Segments are standalone

– Definite start
– Definite end
 Segments should be

represented linearly
 Rules for Mathematical Writing

Relationship between arguments of a

segment (1 of 3)

Hierarchical
 Rules for Mathematical Writing

Relationship between arguments of a

segment (2 of 3)

Nonlinear
with
crossing
Rules for Mathematical Writing

Relationship between arguments of a

segment (3 of 3)

Linear
QoE—Usability

In this module

We shall explore
 What is usability?

 Some usability expressions

 Connotations of usability on

network model
 QoE—Usability

Everything starts with “You”

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Usability

What is usability? (1 of 2)
 Usability (Ub) is defined as the
ease of use with which
network users can access the
network and services
 Ergonomic and technological
facilitation
– Networks should make
users’ jobs easier
QoE—Usability

What is usability? (2 of 2)
 Some design decisions have a
negative affect on usability
– Strict security
 Some choices are user friendly
– WiFi
– DHCP
 QoE—Usability

Understanding usability

Sanjay Kumar Gupta, “Usability Models Based on Network Artifacts

for Rural Development” Int. J. Computer Technology &
Applications,Vol 4 (3),508-513

 Ub: Usability as ease of use

 Ue: Use effort
 Ub  1/Ue
QoE—Usability

Usability expressions
QoE—Usability

Connotations
 Usability (Ub) is expressed as a
function of network devices
 The top-down approach
implies that the assessment of
overall usability has to be
based on the performance of
– Hubs/switches
– Routers/gateways
QoE—Scalability

In this module

We shall explore
 What is Scalability?

 Scalability analysis

 Connotations of scalability

on network model
 QoE—Scalability

Ability to grow

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Scalability

What is scalability?
 Scalability refers to the ability
to grow (or add)
 Factors to be added
― Number of applications

― Number of sites

― Addressing at sites

― No. of users

― No. of servers
QoE—Scalability

Effects of growth
 Efficiency decreases with
increasing factors
– But increases with
increasing “other” factors
 Execution time increases with
increasing factors
– But decreases with
increasing “other” factors
 QoE—Scalability

Understanding efficiency & speed-up

 Execution time tends to vary with problem size
― Must be normalized when comparing network performance
at different traffic volumes

ERelative = T1  (No. of hosts  TNo of hosts)

SRelative = No. of hosts  E1

 QoE—Scalability

Understanding execution time

TimeExecution = TCompute + TComm + TIdle

Tmsg = ts + twL
QoE—Scalability

Connotations
 Scalability is expressed as a
function of factors in the
network
 This criteria affects the design
choices made for the network
model
QoE—Planning for Expansion

In this module

We shall understand
 Why plan to expand?

 Considerations for planning

 QoE—Planning for Expansion

Need to expand is ever increasing

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Planning for Expansion

Why plan?
 Expansion is unavoidable
 Unplanned expansion causes
performance degradation
– Execution time
– Efficiency
 Planning is necessary
– Preemption is key
– Late planning is no
planning
QoE—Planning for Expansion

Considerations for Planning

(1 of 2)
 Nodes and locations
– End hosts
– Switches
– Routers
 Equipment scalability
– No of ports
 Naming system
– Extensible tuple
(Node ID, Network ID)
 QoE—Planning for Expansion

Considerations for Planning (2 of 2)

 Application-specific protocol choices
Email File transfer, sharing & access
DB access & updating Web browsing
Network game Remote terminal
Videoconferencing Video on demand (VoD)
QoE—Expanding Access to Data

In this module

We shall understand
 What is data access?

 Metcalfe's law

 Application of the law

 Connotations
 QoE—Expanding Access to Data

Scalability without continued access to data

is futile

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Expanding Access to Data

Access to data
 Social networking has emerged
 Extranets need topology
definitions & dedicated
bandwidth allocation
– Classic 80-20 rule 
 Increased access
– Data available to more
departments
– Increased utilization of
network services
QoE—Expanding Access to Data

Metcalfe's Law
 Community value of a network
grows as the square of the
number of its users
 Often cited as an explanation
for the rapid growth of the
Internet
 QoE—Expanding Access to Data

Expression for Metcalfe's Law

 n(n − 1)/2 or O(n2) connections between “n” nodes
QoE—Expanding Access to Data
Manifestation of Metcalfe's Law
 Can be seen in network applications
QoE—Expanding Access to Data

Connotations
 Network model is more scalable
than the number of nodes and
servers in the topology
 The total traffic load generated
depends upon the user activity
QoE—Constraints on Scalability

In this module

We shall understand
 Parts of model

 Constraints of scalability

 Connotations
 QoE—Constraints on Scalability

The whole cannot be greater than the sum

of its parts (Apologies to Aristotle)

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Constraints on Scalability

Recall parts of model!

 Nodes
― Computing

― Memory

 Protocols
― Operation

― Message formats

 Devices
― Ports

― Specifications

 And more!
QoE—Constraints on Scalability

Identify their upper bounds

 Nodes
― N
max
 Protocols
― Operation: O
max
― Message formats: M
max
 Devices
― Ports: P
max
― Specifications: S
max
QoE—Constraints on Scalability

Maximum scaled up
network
 Given by MinMax decision rule
Min(Nmax,Omax,Mmax,Smax)
• The strength of the chain is
determined by the weakest link
QoE—Constraints on Scalability

Specific example
 Constrained addressing
― IPv4

― Top-level exhaustion occurred

on 31 Jan 2011
― 24 Sep 2015 for North

America
 Unconstrained addressing (for
now!)
― IPv6

 With everything as IoT, 2128 is

the constraint
QoE—Availability

In this module

We shall understand

 What is availability?
 Vs reliability
 Vs capacity
 Vs Redundancy
 Specifying availability
requirements
 QoE—Availability
The degree to which a system, subsystem or
equipment is in a specified operable and
committable state

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

 QoE—Availability
Everything may fail, not if but when!
 Networks Nodes Links
 Typical failure of components represented by the famous
QoE—Availability
Network Availability
Percent uptime per year,
month, week, day, or
hour to total time in that
period
– For example:
• 24/7 operation
• Network is up for 165
hours in the 168-hour
week
– Availability is 98.21%
QoE—Availability
Application
perspective
• Applications may require
different levels
– Real time
• Video/Audio
– Commerce
• Non-repudiable
transactions
– Non-real time
• Email
QoE—Availability
Availability vs
reliability
• Reliability is the ability of
a system to complete its
function
– accuracy
– error rates
– Stability
• Even if a system is
available does not mean
its reliable
QoE—Availability
Availability vs
capacity
• A system that runs out of
capacity becomes
unavailable
– ATM connection
admission control
– Regulates no. of cells
into network
• If capacity & QoS for
connection unavailable
– cells dropped
QoE—Availability
Availability vs
redundancy
• Redundancy is not a
goal
• It is provided to achieve
a level of availability
– Only a means!
QoE—Availability
Availability vs
resiliency
• How much stress can be
taken by network?
– Availability difficult to
maintain
– No. of failures that
make a system
unavailable
• How soon can a network
rebound?
– Availability difficult to
achieve
QoE—Disaster Recovery

In this module

We shall understand

 A disaster recovery scenario

 Redundancy for recovery
 Allocation model
 QoE—Disaster Recovery

Amat Victoria Curam (Latin)

Victory Loves Preparation

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

 QoE—Disaster Recovery

Benjamin B. M. Shao, “Allocating Redundancy to

Critical Information Technology Functions for Disaster
Recovery,” Proc. 10Th Americas Conference on
Information Systems, Aug. 2004

The question

How to allocate redundancy to IT functions such that

the overall survivability of these IT functions against
disasters is maximized and the cost remains under
budget.
QoE—Disaster Recovery
Redundancy
• Redundancy in
preparation for disasters
provides disaster
preparation
– Proactive prevention
– Reactive recovery
– Backup facilities
 QoE—Disaster Recovery
Redundancy Allocation Scenario
QoE—Disaster Recovery
Redundancy
Allocation Model (1 of
6)
• IT function can be
implemented by a
number of IT assets
– Computing hardware
– Communication links
– IT personnel, and
• other infrastructure
 QoE—Disaster Recovery
Redundancy Allocation Model (2 of 6)
 QoE—Disaster Recovery
Redundancy Allocation Model (3 of 6)
 QoE—Disaster Recovery
Redundancy Allocation Model (4 of 6)

At least one IT solution be selected

and allocated to each IT function
 QoE—Disaster Recovery
Redundancy Allocation Model (5 of 6)

Guarantees that the total costs of

Redundancy allocation not exceed
the budget limitation
QoE—Disaster Recovery
Redundancy
Allocation Model (6
of 6)
 m fails against d only
when all of its selected
solutions fail at same
time
– As long as one of the
selected solutions
survives, m would still
be operational
QoE—Specifying Requirements

In this module

We shall understand

 What is availability
specification?
 Per year (365 days)
 Per calendar year
 Per spurt
 QoE—Specifying Requirements

Measurable is achievable

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Specifying Requirements
Availability in %age
per annum
•Uptime of 99.70%
– 30 mins downtime
•Uptime of 99.95%
– 5 mins downtime
•Map onto totally deviant
requirements
QoE—Specifying Requirements
Availability in
calendar year
•Downtime on weekdays
– vs weekends
•Project deadlines
QoE—Specifying Requirements
Availability in spurts
 Staggered vs onetime
 99.70% uptime
― 30 minutes per year

― 10.70 sec per hour

 Acceptable for some users

not to others
 Allowed for few
applications
QoE—Five Nines Availability

In this module

We shall understand

 What is 5 9s?
 Impact on costs
 Example
 QoE—Five Nines Availability

The devil is in the details of availability

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Five Nines Availability
5 9s as best-case
availability (1 of 4)
•Some enterprises may want
99.999%
– 5 minutes downtime
per year
•Sometime or all the time?
– A million $ worth
question for managers
QoE—Five Nines Availability
5 9s as best-case
availability (2 of 4)
•Repair time inclusive or
exclusive
– In service upgrades
(hot-swaps) possible?
QoE—Five Nines Availability
5 9s as best-case
availability (3 of 4)
• Hardware manufacturers
provide 5 9s
• However sum is not equal
to parts
– Carrier and power
outages
– faulty software in
routers & switches
QoE—Five Nines Availability
5 9s as best-case
availability (4 of 4)
– Unexpected and
sudden increase in
bandwidth or server
usage
– Configuration
problems, human
errors (90% of all!)
– Security breaches, and
software glitches
 QoE—Five Nines Availability
Shifting Impact of 9s on time
Per Hour Per Day Per Week Per Year

99.999% .0006 .01 .10 5

99.98% .012 .29 2 105

99.95% .03 .72 5 263

99.90% .06 1.44 10 526

99.70% .18 4.32 30 1577

 QoE—Five Nines Availability
99.999% Availability might require
triple redundancy
ISP 1 ISP 2 ISP 3

Enterprise

One being active, one in hot standby ready to be used

immediately, one in standby or maintenance
QoE—Cost of downtime

In this module

We shall understand

 What is the impact of

downtime?
 Step-wise approach
 QoE—Cost of downtime
40 percent of companies that
shut down for three days failed within 36 months
(Contingency Planning and Management magazine)

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

 QoE—Cost of downtime

Source: Top Business Continuity Priorities for

2004.©EnvoyWorldWide - February, 2004
 QoE—Cost of downtime

Source: New England Disaster Recovery Information X-

Change (NEDRIX)
QoE—Cost of downtime
Step-wise approach to
measure downtime
cost
I.Identify Business Continuity
Components
II.Define What You Protect
III.Prioritize Business Functions
IV.Classify Outage Types,
V.Calculate cost
QoE—Cost of downtime
Identify Business
Continuity
Components
•People
•Property
•Systems
•Data
QoE—Cost of downtime
Define What You're
Protecting
 Define core competencies
― product, service, process,

or methodology
QoE—Cost of downtime
Prioritize Business
Functions
 Business functions
necessary to sustain that
core competency
― And associated IT

infrastructure
• 80% of available resources
restore 20 % systems,
applications, and data
QoE—Cost of downtime
Outage Types,
Frequencies, &
Duration
 Branch Outage
 Regional outage
 Data center outage
 National outage
 QoE—Cost of downtime
Calculate cost

Frequency x Duration x Hourly Cost = Lost Profits

 QoE—Cost of downtime
Example

 If there were 90 branch outages in an average year

― Each lasting an average of one-and-a-half hours

― Costing $300/hour

90 outages x 1.5 hours x $300/hour = $ 40,500

 Cost of branch outages for a year =$40,500
QoE—MTBF AND MTTR

In this module

We shall understand

 What is typical
representation of
availability?
 Availability of components
and service
 Example
 QoE—MTBF AND MTTR

Averaging out the availability

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—MTBF AND MTTR
Availability as MTBF
(1 of 3)
• Mean time bw failure
(MTBF) & mean time to
repair (MTTR)
• Component vs service
– Mean time bw service
outage (MTBSO)
– Mean time to recover
from service outage
(MTTSO)
QoE—MTBF AND MTTR
Availability as MTBF (2
of 3)
• Typical MTTF value is once
per 4000 hrs or 166.7 days
• Typical acceptable MTTR
value is one hour
Availability = MTBF/(MTBF +
MTTR)
4,000/4,001 = 99.98%
availability
QoE—MTBF AND MTTR
Availability as MTBF (3
of 3)
• MTBF with MTTR help to
assess frequency and length
of service outage
– Mean value must
be supported with variance
 QoE—MTBF AND MTTR

• The difference between MTTF and MTBF is the

assumption of the former that the system shall be
repaired while in the later the system is replaced
QoE—Network Performance

In this module

We shall understand

 How to define network

performance?
 Performance factors
 QoE—Network Performance

Composite metric that is end-to-end

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Network Performance

Definition
 An overall working
 Many different ways to
measure the performance
of a network
― Each network is different

in nature and design

 Modeled
 Simulated
 Measured
 QoE—Network Performance

Network
Performance

Efficiency Offered Load Delay

Accuracy Throughput Utilization

Response Optimum
Capacity
time Utilization
 QoE—Network Performance
The data-carrying capability of a circuit or network, usually
measured in bits per second (bps)

Efficiency Offered Load Delay

Accuracy Throughput Utilization

Response Optimum
Capacity
time Utilization
 QoE—Network Performance
The percent of total available capacity in use

Efficiency Offered Load Delay

Accuracy Throughput Utilization

Response Optimum
Capacity
time Utilization
 QoE—Network Performance
Maximum average utilization before network is considered
saturated

Efficiency Offered Load Delay

Accuracy Throughput Utilization

Response Optimum
Capacity
time Utilization
 QoE—Network Performance
Quantity of error-free data successfully transferred between
nodes/sec

Efficiency Offered Load Delay

Accuracy Throughput Utilization

Response Optimum
Capacity
time Utilization
 QoE—Network Performance
Sum of all the data all network nodes have ready to send at
particular time

Efficiency Offered Load Delay

Accuracy Throughput Utilization

Response Optimum
Capacity
time Utilization
 QoE—Network Performance
The amount of useful traffic that is correctly transmitted, relative
to total traffic

Efficiency Offered Load Delay

Accuracy Throughput Utilization

Response Optimum
Capacity
time Utilization
 QoE—Network Performance
An analysis of how much effort is required to produce a certain
amount of data throughput

Efficiency Offered Load Delay

Accuracy Throughput Utilization

Response Optimum
Capacity
time Utilization
 QoE—Network Performance
Time between a frame being ready for transmission from a node and delivery
of the frame elsewhere in the network
The amount of time average delay varies)

Efficiency Offered Load Delay

Accuracy Throughput Utilization

Response Optimum
Capacity
time Utilization
 QoE—Network Performance
The amount of time between a request for some network service
and a response to the request

Efficiency Offered Load Delay

Accuracy Throughput Utilization

Response Optimum
Capacity
time Utilization
QoE—Optimum Network Utilization

In this module

We shall understand

 What is optimum?
 What is optimum network
utilization?
– At WANs
– At LANs
– Typical values
 QoE—Optimum Network Utilization

Optimum is “As good as it gets”

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Optimum Network Utilization

Definition of optimum
 Selection of a best element
(with regard to some
criteria) from some set of
available alternatives
QoE—Optimum Network Utilization

Optimum network
utilization (1 of 4)
•How much % of bandwidth
capacity in a specific time
period?
•Time varying phenomenon
– Instantaneous,
averaged, weighted)
• Both goal & constraint
QoE—Optimum Network Utilization

Optimum network
utilization (2 of 4)
•Typical value is 70$%
– Exceeding this results in
performance
degradation
QoE—Optimum Network Utilization

Optimum network
utilization (3 of 4)
•WAN links utilization is more
crucial than LAN
– Pay per packet
•Compression, caching and
concatenation used to reduce
WAN utilization
QoE—Optimum Network Utilization

Optimum network
utilization (4 of 4)
•LANs are over-budgeted
– Fast Ethernet)
•Full-duplex vs half duplex
switches
•User activity levels
•LANs suffer from exceeding
utilization in switch-to-switch
QoE—Throughput

In this module

We shall understand

 What is throughput?
 Throughput vs offered load
 QoE—Throughput

Throughput = Goodput + Badput

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Throughput

Definition of throughput
•Quantity of error free data
transmitted/ sec
– Erroneous
transmissions futile
• Ideally, should be the same
as capacity
 QoE—Throughput
Deviation indicates the limitations of media type,
device and network
QoE—Throughput of devices

In this module

We shall understand

 What is throughput?
 Throughput vs offered load
 QoE—Throughput of devices

Simulation of devices and specifications is vendor

specific
Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Throughput of devices

Types of device
throughputs
•Inter-networking devices
give throughput as in
– TCP/IP: Packets per
second
– ATM: Cells per second
•Sizes vary from 53, 64 to
1518 Bytes
QoE—Throughput of devices

Example—CISCO devices
•Traffic generators-device-
traffic checkers in tandem
measure throughput
– Smaller packets give
better pps
 Cisco claims of 400 million

pps for the Cisco Catalyst

6500 switch
 QoE—Throughput of devices
CISCO claims throughput; which in actual is the
capacity
QoE—Application Layer Throughput

In this module

We shall understand

 Definition
 Factors affecting goodput

 Mathematical formulation
 QoE—Application Layer Throughput

Application layer uses lower layers unfairly

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Application Layer Throughput

Definition
•Application layer throughput
= goodput + badput
•Goodput vs badput
•Badput contributed by
retxns, header etc
– Fraction of packets that
collided/lost
• Fc = C/N
• Fc = L/N
QoE—Application Layer Throughput

Factors affecting
goodput (1 of 3)
•End-to-end error rates
•Protocol functions
(handshaking, windows, &
acks)
•Protocol parameters (frame
size, retx timers)
•pps rate of networking
devices
•Lost packets at networking
devices
QoE—Application Layer Throughput

Factors affecting
goodput (2 of 3)
•Workstation & server
performance factors:
– Disk-access speed
– Disk-caching size
– Device driver
performance
•Computer bus performance
(capacity/arbitration)
QoE—Application Layer Throughput

Factors affecting
goodput (3 of 3)
•Processor (CPU)
performance
•Memory performance
(access time for real and
virtual memory)
•Operating system
inefficiencies
•Application inefficiencies or
bugs
 QoE—Application Layer Throughput

An, Cheolhong, and Truong Q. Nguyen. "Error Resilient

Video Coding using Cross-Layer Optimization Approach."
IEEE Transactions on Multimedia 10 (2008): 1406-1418.
 QoE—Application Layer Throughput

Application layer
goodput
QoE—Application Layer Throughput

Connotations
•Application layer throughput
provides insight into “useful'
transmissions
– It relates resource
allocation down to
physical layer
throughput
QoE—Efficiency

In this module

We shall understand

 Definition
 Factors affecting efficiency

 Throughput vs efficiency

 Average efficiency
 QoE—Efficiency

Boiling water analogy

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Efficiency

Definition
•Application layer throughput
= goodput + badput
•Goodput vs badput
•Badput contributed by
retxns, header etc
– Fraction of packets that
collided/lost
• Fc = C/N
• Fc = L/N
QoE—Efficiency

Factors affecting
efficiency (1 of 3)
•Access protocols
– high number of users
showing activity
– Ethernet not efficient
at high collision rates
QoE—Efficiency

Factors affecting
efficiency (2 of 3)
•Frame size
– Using large frame is
useful for single user on
WAN links
•Serialization delay on WAN
links results in unfair
treatment
– for real-time shorter
frames enqueued in
router
 QoE—Efficiency

Factors affecting efficiency (3 of 3)

 QoE—Efficiency
Kleinrock, Leonard. "Creating a mathematical theory of
computer networks." Operations Research 50.1 (2002):
125-131.
If you scale capacity
more slowly than
throughput while
holding the average
response time
constant, then the
channel efficiency
(channel utilization)
will increase
 QoE—Efficiency
Average Efficiency
Latora, Vito, and Massimo Marchiori. "Efficient behavior of
small-world networks." Physical review letters 87.19 (2001):
198701.

 E(G) is the average efficiency of a network G

 n denotes the total nodes in a network
 d(i,j) denotes the shortest path between a node i and a
neighboring node j
QoE—Delay and Jitter

In this module

We shall understand

 Definition of delay
 Definition of delay variation
 QoE—Delay and Jitter

Applications might forgive delay but not jitter

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Delay and Jitter

Delay
•Voice and video applications
(especially interactive)
demand minimum delay
•Other applications such as
Telnet remote echo need
timed performance
 QoE—Delay and Jitter
Sources of packet delay

transmission
A
propagation

B
nodal
processing queueing

dnodal = dproc + dqueue + dtrans + dprop

QoE—Delay and Jitter

Delay variation (jitter)

• The amount of time
average delay varies
• Voice, video, and audio are
intolerant of delay
variation
QoE—Delay and Jitter
Source of jitter
QoE—Causes of Delay

In this module

We shall understand

 Causes of delay
 Effect of utilization on delay
 QoE—Causes of Delay

It is the small factors that matter the most

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Causes of Delay

Causes of Delay (1 of 3)
•Propagation
– Media type
– Length
•Transmission (serialization)
– 1024 Bytes on T1
•Switching delay
– upto 5-20 microsec for
64 Bytes frame
QoE—Causes of Delay

Causes of Delay (2 of 3)
•Router delay
– Look-up, router
architecture,
configuration
– Software features that
optimize the
forwarding of packets
•NAT, IPSEC, QoS, ACL
QoE—Causes of Delay

Causes of Delay (3 of 3)
•Queuing delay
– Dependent upon
utilization
Formula
Queue depth = Utilization/(1
– Utilization)
QoE—Causes of Delay
Queue Depth vs Utilization
QoE—Delay and Jitter
Implications of queuing delay

traffic intensity
QoE—Delay variation

In this module

We shall understand

 Definition of delay variation

(jitter)
 Types

 Measurement of jitter
 QoE—Delay variation
All animals are equal, but some animals are more equal
than others (George Orwell)

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Delay variation

Delay variation (1 of 2)
 Amount of time average
delay varies
 Voice, video, and audio are
intolerant of delay variation
 Tradeoffs needed for
efficiency for high-volume
applications versus low
QoE—Delay variation

Delay variation (2 of 2)
 Concept of jitter buffer to
smoothen out the jitter
 Variations on the input side
are smaller than the buffer
 Acceptable variation is 1-2%
of the delay
QoE—Delay variation

Jitter types (1 of 4)
 Jitter is quantified in two
ways
 Delay jitter
― bounds maximum

difference in total delay of

different packets
― Assumes source is

perfectly periodic
QoE—Delay variation

Jitter types (2 of 4)
 Used for Interactive
communication
 voice and video

teleconferencing
 Helps to translate to
maximum buffer size
needed at the destination
QoE—Delay variation

Jitter types (3 of 4)
 Second measure is rate
jitter
 Bounds difference in

packet delivery rates at

various times
 Measures difference
between minimal and
maximal inter-arrival times
(reciprocal of rate)
QoE—Delay variation

Jitter types (4 of 4)
 Useful measure for many
real time applications
 Video broadcast over the
net
 Slight deviation of rate
translates to only a small
deterioration in the
perceived quality
 QoE—Delay variation
Jitter Analysis Points
Kay, Rony. "Pragmatic network latency engineering
fundamental facts and analysis." cPacket Networks,
White Paper (2009): 1-31.
QoE—Delay variation
Measurement of jitter
QoE—Response Time

In this module

We shall understand

 Definition of response time

 Measuring points locations

 Mathematical form
 QoE—Response Time

Response time is relative phenomenon

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Response Time

Definition
•The amount of time
between a request for some
network service and a
response to the request
 QoE—Response Time
Measurement Points Locations
Tim R Norton. "End-To-End Response Time: Where to
Measure?" Computer Measurement Group Conference
Proceedings, 1999.
 QoE—Response Time
Measurement of Response Time
[1] Reinder J., Bril., System Architecture and Networking. TU/e
Informatica
[2] Sjodin, Mikael, and Hans Hansson. "Improved response-
time analysis calculations." Real-Time Systems Symposium,
1998. Proceedings., The 19th IEEE. IEEE, 1998.
 QoE—Response Time
Measurement of Response Time
 QoE—Response Time
Measurement of Response Time
Ceiling function represents maximum number of
pre-emptions by higher priority processes

Ri: worst case response (computation) time

Bi: maximum blocking time from lower priority processes
Ci: the worst case computation time
hp(i): the set of processes with higher priority than process i
Jj: the maximum jitter variation in activation times
(e.g. output of one task triggers a next task)
Tj: The period (or minimum inter-arrival time)
Cj:the worst case computation time
QoE—Security

In this module

We shall understand

 What is security?
 Implementation
 QoE—Security

Threat = Capability + Intention

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Security

Definition
 Protection of information
systems from threat
 Hardware

 Software

 Information on them

 Avoidance from
 Disruption

 Misdirection of the

services they provide

QoE—Security

Implementation
 Includes controlling physical
access to the hardware
 Protecting against harm via
 Network access

 Data

 Code injection
QoE—Security

Tradeoff
 Security and deployment
•Operational ease
•Too much secure:
bothersome inviting
workarounds
•Thumb rule: cost of security
implementation << cost of
recovering from security
lapse
QoE—Identifying Network Assets

In this module

We shall understand

 What are network assets?

 How to identify them?
 QoE—Identifying Network Assets

Know thy self

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Identifying Network Assets

Trusted Computing Base

 Rainbow series (Orange
book)
•Set of all hardware,
firmware, and/or software
components
•Critical to its security
•Bugs occurring inside
jeopardize security of entire
system
QoE—Identifying Network Assets

Bell-Lapadula Model
•Users as Subjects
•Predicates
– Devices and data as
Objects
•Process algebra provides the
action (verb) of subject over
predicates
QoE—Reconnaissance Attacks

In this module

We shall understand

 What is reconnaissance?
 How to measure and

quantify recy attack?

 QoE—Reconnaissance Attacks

Prevention is better than cure

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Reconnaissance Attacks

Definition
• Reconnaissance is a type of
computer attack
•Intruder engages with the
targeted system
– Gathers information
about vulnerabilities
QoE—Reconnaissance Attacks

Types
 Active
reconnaissance
 Port scanning

 Passive reconnaissance

 Sniffing

 War driving

 War dialing
 QoE—Reconnaissance Attacks

Targeted Threat Index

Hardy, Seth, et al. "Targeted threat index: Characterizing and
quantifying politically-motivated targeted malware."
Proceedings of the 23rd USENIX Security Symposium. 2014.
QoE—Reconnaissance Attacks

Targeted Threat Index

• Vulnerability of system
•Depends upon
– Target feature set
– Attacker methods
– Attacker aggressiveness
TTI = Method *
Implementation
QoE—Security Requirements

In this module

We shall understand

 How to quantify security

requirements?
 What is CVSS?

 How to use it?

 QoE—Security Requirements

Comprehensive planning is half success

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Security Requirements

Definition
•Enlist all the activities,
actions, hardware/software
• Confidentiality
• Integrity
• Authorization
• Authenticity
• Availability
• Encryption
 QoE—Security Requirements

Assessing Security Levels

Burchett, Ian. "Quantifying Computer Network Security."
(2011).
QoE—Security Requirements
QoE—Security Requirements

Common Vulnerability
Scoring System
 Provides a repeatable
quantitative score for
computer security
vulnerabilities
 QoE—Security Requirements

Vulnerability Compositing Method per Client

QoE—Manageability

In this module

We shall understand

 What is manageability?
 Manageability metric
 QoE—Manageability
SMART goals - Specific, Measurable, Achievable,
Realistic and Timely

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—Manageability

Definition
•The level of human effort
required to keep that system
operating at a satisfactory
level
– Deployment
– Configuration
– Upgrading
– Tuning
– Backup
– Failure recovery
 QoE—Manageability

Assessing Manageability
Candea, George. "Toward Quantifying System
Manageability." UseNix HotDep. 2008.
 QoE—Manageability

Manageability Metric

The notion of efficiency of management operations, which is

approximated by the time Timei the system takes to complete
Taski
Approximate complexity of a management task by the number
of discrete, atomic steps (Stepsi) required to complete Taski
QoE—Manageability

Commentary (1 of 3)
 Manageability is reduced
proportionally to how long
the management tasks take
 And to how many atomic
steps are involved in each
such task
QoE—Manageability

Commentary (2 of 3)
 The fewer steps there are,
the lower the exposed
complexity of the system
 The faster the management
tasks can be completed, the
lower the likelihood of
trouble
QoE—Manageability

Commentary (3 of 3)
 Less management a system
requires (i.e., the longer
TotalTimeeval for the same
Ntotal), the easier it is to
manage
 Equivalently, the less the
system needs to be
managed, the better
QoE—DoS Attack

In this module

We shall understand

 A simple DoS attack

 Counter strategy

 Analysis
 QoE—DoS Attack

DoS attacker = uncouth talkative person

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—DoS Attack

Definition
 An attempt to make a
machine or network
resource unavailable
 to its intended users,

 Temporarily
 Indefinitely
QoE—DoS Attack

Implementation
 Transmit a large number of
packets
 TCP Syn attack

 Ping attack

 Server crashing attack

 Large computational load
 QoE—DoS Attack
A Simple Attack Analysis
He, Changhua. Analysis of security protocols for wireless
networks. PhD Diss. Stanford University, 2005.
 QoE—DoS Attack
A Simple Attack Analysis
 Attack type: TCP SYN flooding DoS attacks
– n packets are used for attack

 Counter: Random drop queue 'Q'

Q = queue depth
Attack success probability
 P = 1 − (1 − 1/Q)
n

Attack failure probability

 1-P
QoE—DoS Attack
A Simple Attack Analysis
QoE—DoS Attack

In this module

We shall understand

 A simple DoS attack

 Counter strategy

 Analysis
 QoE—DoS Attack

DoS attacker = uncouth talkative person

Scalability Availability Performance Security

Manageability Usability Adaptability Affordability

QoE—DoS Attack

Definition
 An attempt to make a
machine or network
resource unavailable
 to its intended users,

 Temporarily
 Indefinitely
QoE—DoS Attack

Implementation
 Transmit a large number of
packets
 TCP Syn attack

 Ping attack

 Server crashing attack

 Large computational load
 QoE—DoS Attack
A Simple Attack Analysis
He, Changhua. Analysis of security protocols for wireless
networks. PhD Diss. Stanford University, 2005.
 QoE—DoS Attack
A Simple Attack Analysis
 Attack type: TCP SYN flooding DoS attacks
– n packets are used for attack

 Counter: Random drop queue 'Q'

Q = queue depth
Attack success probability
 P = 1 − (1 − 1/Q)
n

Attack failure probability

 1-P
QoE—DoS Attack
A Simple Attack Analysis