mobile systems m - unibo.it

17/04/2018

1

Qualnet – Mobile Systems M 1 1

Mobile Systems M

Alma Mater Studiorum – University of Bologna CdS Laurea Magistrale (MSc) in Computer Science Engineering

Mobile Systems M course (8 ECTS)

II Term – Academic Year 2017/2018

Qualnet a Wireless Network Simulator

Andrea Reale & Paolo Bellavista

http://lia.disi.unibo.it/Courses/sm1718-info/

http://lia.disi.unibo.it/Staff/PaoloBellavista/

Qualnet – Mobile Systems M 2

INTRODUCTION Simulation and Qualnet








17/04/2018

2


Simulation

Reproduction of the behavior of a complex system

Abstraction from inessential details

Focus on parameters and aspects of relevance for the system

F e e d b a ck

Complex System

Model

Execution

Results


Simulation Purposes and Usage

Real system is too expensive to implement

The maximum level of detail is not necessary

Measurement of indicators that are otherwise hard to be observed

Need of slowing down or accelerate time of execution

17/04/2018

3


Taxonomy of Simulation Tools

Static vs Dynamic Static: time is not a “relevant” variable in the

model

Dynamic: it considers time passing-by

Continuous vs Event-based (discrete events)

Continuous: time goes on after fixed constant intervals

Event-based: time goes on only when significant events occur (e.g., reception of a packet)


Validation of a Simulation Tool

A model adopted in a simulation may generate results that are very different from real measurements

Errors in the model

Not considered “details” that were relevant

Validation of a model

Comparison of simulation results with real measurements of the same indicators

17/04/2018

4


Network Simulators

Models for computer networking Nodes, routers, switches, links, …

Communication protocols between nodes

Execution of scenarios that would be highly expensive in terms of hw, time, and practical deployment issues New protocols or variants of existing protocols

Complex network topologies

Simpler to freely tune node characteristics and to measure evaluation parameters in order to optimize settings


Qualnet: a Discrete Event-based Wireless Network Simulator

17/04/2018

5


Qualnet: Primary Characteristics

Commercial product

Spin-off of an opensource project at UCLA

Accurate and fat models for protocols at any stack layer

Models for radio propagation (pathloss, shadowing, fading)

802.11, 802.15.4, 802.16, GSM/UMTS, …

RIP, DSR, AODV, …


Qualnet: Strengths

Scalability Parallel execution over multiple processors (or over

multiple hosts, with proper licensing)

Configurable tradeoff detail vs. performance Very detailed models Possibility to abstract from unnecessary and undesired

details to speed up execution

Portability Linux, MacOs X, and Windows (32 and 64 bit)

Extensibility Possibility to develop new models at any layer Possibility to easily interface with external sw

17/04/2018

6


NETWORK SIMULATION WITH QUALNET Scenarios definition and results analysis


Qualnet: Architecture

Qualnet Simulation Kernel

Model Libraries

GUI ToolsCommand Line

Interface

External

Interfaces

&

Dynamic

APIs

17/04/2018

7


Scenario

Scenario: description of a network that can be “executed” by the simulator. It includes: Topology: nodes, physical links between nodes Network interfaces (number, type, physical model) Protocols for each interface (physical, MAC, network,

routing) Models for node mobility “Environmental” model: terrain characteristics, meteorological

features, … Batteries, models for energy consumption, … Models for antennas

…


Simulation Workflow

Definizione Scenario

Esecuzione con Qualnet

Analisi Risultati

GUI: Designer

CLI

scenario.config

scenario.stat

<trace>

scenario.trace

GUI: Animator

CLI

GUI: Analyzer

GUI: Tracer

Scenario Definition

Qualnet Execution

Result Analysis

17/04/2018

8


Input: file .config

Complete description of the scenario to be simulated

It may include other additional files .app: describes the application protocols at nodes

.nodes: describes positioning and mobility of nodes

Creation Via GUI through Qualnet Designer

Manually, in particular useful for complex and articulated scenarios (e.g., with high numbers of nodes)


Input: file .config

Each line in the file specifies a parameter of the simulation

Format:

[<scope>] <param> [<index>] <value>

scope: it specifies to which simulation objects a parameter has to be applied. A parameter may be defined for one of these scopes: global, node, subnet, and interface

param: identifier name of the parameter

index: for parameters that may have multiple instances, it specifies to which instance the parameter refers to (opt)

value: parameter value. Format and type may change

17/04/2018

9


example.config Radio Channels

…

SIMULATION-TIME 12H

COORDINATE-SYSTEM CARTESIAN

TERRAIN-DIMENSION (1500, 1500)

NODE-POSITION-FILE example.nodes

MOBILITY RANDOM-WAYPOINT

# RADIO CHANNELS (a single channel, indexed 0)

PROPAGATION-CHANNEL-FREQUENCY[0] 2400000000

PROPAGATION-PATHLOSS-MODEL[0] TWO-RAY

PROPAGATION-SHADOWING-MODEL[0] LOGNORMAL

PROPAGATION-SHADOWING-MEAN[0] 4dB

PROPAGATION-LIMIT[0] -111.0 dB

PROPAGATION-MAX-DISTANCE[0] 0


example.config - Subnet

NETWORK-PROTOCOL IP IP-QUEUE-TYPE[0] FIFO SUBNET N8-1.0 { 1 thru 10} # creates nodes and interfaces [N8-1.0] PHY-MODEL PHY802.11b [N8-1.0] MAC-PROTOCOL MACDOT11 [N8-1.0] ROUTING-PROTOCOL AODV LINK N8-2.0 {10, 11} [N8-2.0] LINK-PHY-TYPE WIRED [N8-2.0] LINK-MAC-PROTOCOL MAC802.3 # MAC802.3|ABSTRACT [N8-2.0] NETWORK-PROTOCOL IP [N8-2.0] ROUTING-PROTOCOL BELLMANFORD APP-CONFIG-FILE example.app

17/04/2018

10


example.config Result


Output: Scenario Statistics

Text-based file .stat

Each line has the following format:

<id>, <addr>, <index>, <layer>, <proto>, <param> = <value>

id: node identifier

addr: IP address of the interface on which the protocol runs (opt)

index: it distinguishes multiple instances of the same protocol (opt)

layer: PHY, MAC, NETWORK, TRANSPORT, APPLICATION

proto: protocol name to which the statistics value refers to

param: descriptive identifies of the statistics

value: statistics value

17/04/2018

11


Output: Trace File

Traces of exchanged messages for each protocol It is possible to choose, selectively, which layers and/or

protocols have to be traced XML file: <rec>

<rechdr></rechdr>

<recbody></recbody>

</rec>

<rec> Entry for a single traced packet <rechdr> Registration header <recbody> Packet header (one or multiple if encapsulated)


example.trace

<trace_file> <head> … </head> <body> … <rec> <rechdr> 3 0 3.3584881 7 4 2 <action> 1 0 </action> </rechdr> <recbody> <udp> 519 519 36 0 </udp> <recbody> </rec> … </body> </trace_file>

Node 3 sends to node 0 a message originated by protocol 4 (cbr) at simulation time 3.35s. The message is traced by protocol 2 (udp) and the associated action is #1 (send)

Source port: 519 Destination port: 519 Length: 36 bytes Checksum: N/A

17/04/2018

12


GUI Tools: Qualnet Architect

Two usage modes

Design Mode Creation of scenarios via drag&drop of visual

components

Generation of text file with the configuration

Visualize Mode Scenario execution

Animations and visualization of (some) parameters in real-time


GUI Tools: Qualnet Architect (Design Mode)

17/04/2018

13


GUI Tools: Qualnet Architect (Visualize Mode)


GUI Tools : Qualnet Analyzer

Parsing of statistics file (.stat) generated by the experiments

Graphics visualization of statistics

Simple tools for aggregation and analysis

Personalization of graphics, charts, …

17/04/2018

14


GUI Tools: Qualnet Packet Tracer

Parsing of .trace files generated by the experiments

Table-oriented visualization of trace information

Search and filtering based on multiple criteria

e.g., sender port, TTL, destination node, protocol


HOW TO DEVELOP IN QUALNET Implementing new models and protocols

17/04/2018

15


Qualnet: Development Env

Qualnet Kernel and Model Libraries written in C++ Actually, C++ object orientation is scarcely exploited Good knowledge of C language is largely sufficient to

understand (and write) most simulation code

Source code is available for some kernel parts and the protocols of Model Libraries Possibility to modify existing protocols to adapt them

to specific needs Useful guidelines for the development of new models


Event-based Simulation

Event Handler

Event Queue

Event queue, ordered based on increasing event timestamp

One at a time, the events are taken from the queue and processed

Event processing may generate other events, which are inserted in order in the queue

17/04/2018

16


Event Types in Qualnet

Packet Event Used to simulate packet exchange between nodes Used to simulate transfer of packets through different

protocol layers of the same node

Timer Event Used to simulate time-out or alarms (frequent case in

protocol management)

Timer Event and Packet Event in Qualnet are represented by a single data structure: Message They are managed by simulator kernel in a homogenous

way About terminology, any event can be called as a

“Message” in Qualnet


Message Data Structure

typedef struct message_str {

…

short layerType; // e.g. APPLICATION_LAYER

short protocolType; // e.g. CBR

short instanceId; // e.g. 1515 (port)

short eventType; // e.g. MSG_APP_CBR_NEXT_PKT

…

char *packet; // Payload (also NULL)

int virtualPayloadSize; // e.g. 42

…

std::vector<MessageInfoHeader> infoArray;

…

} Message;

17/04/2018

17


Layering

Qualnet implements message management based on layers The considered layers are the lowest ones in the OSI stack

Each message has its own type, which is defined by a given protocol

Each protocol belongs to one layer Any message is dispatched based on:

Message type Protocol that defines it Layer which the protocol a belongs to Destination node of the message


Dispatcher and Layering

NodeEvent Dispatcher

Application LayerEvent Dispatcher

Transport LayerEvent Dispatcher

Network LayerEvent Dispatcher

MAC LayerEvent Dispatcher

PHY LayerEvent Dispatcher

IPv6 ED

IPv4 ED

TCP ED

UDP ED

MY_APP ED

HTTP ED

RIP ED

UMTS MAC ED

802.11 MAC ED

UMTS MAC ED

802.11 MAC ED

NODE LEVEL PROTOCOL LAYER LEVEL PROTOCOL LEVEL

HNDL_1

HNDL_2

MESSAGE LEVEL

17/04/2018

18


Dispatcher and Layering

NodeEvent Dispatcher

Application LayerEvent Dispatcher

Transport LayerEvent Dispatcher

Network LayerEvent Dispatcher

MAC LayerEvent Dispatcher

PHY LayerEvent Dispatcher

IPv6 ED

IPv4 ED

TCP ED

UDP ED

MY_APP ED

HTTP ED

RIP ED

UMTS MAC ED

802.11 MAC ED

UMTS MAC ED

802.11 MAC ED

NODE LEVEL PROTOCOL LAYER LEVEL PROTOCOL LEVEL

HNDL_1

HNDL_2

MESSAGE LEVEL


Protocol Structure

Any protocol defines a set of events that it states to be able to manage

One or more handlers manage occurring events

An “Event Dispatcher” has the role of invoking the proper handler when new messages are received

17/04/2018

19


Protocols as State Machines

Initialization

Wait for Events Event Handler

Finalization

event

Simulation Clock Start

Simulation Clock End

EV

EN

TD

ISP

AT

CH

ER


Packet Event and Inter-layer Communication

Any protocol can generate and send messages Directed to a protocol on the same (or different) node

(most common for Timer Event) Directed to another node, by passing through the

underlying layers (exactly as in OSI)

Each layer manages the message, processes it, adds its own header, and propagates it to the lower layer At each step, proper delays may be added

17/04/2018

20


Packet Event: Layer-based Management

Application Layer

Transport Layer

Network Layer

MAC Layer

Physical Layer

Application Layer

Transport Layer

Network Layer

MAC Layer

Physical Layer

Propagation

Node A Node B

Allocate Message

Add Header

Add Header

Add Header

Remove Header

Remove Header

Remove Header

Free Message


Qualnet Message APIs

General-purpose APIs for event manipulation: MESSAGE_Send(Node*, Message*, clocktype)

MESSAGE_Alloc(Node*, int, int, int)

MESSAGE_Free(Node*, Message*)

MESSAGE_AddInfo(Node*, Message*, int, short)

MESSAGE_AddHeader(Node*, Message*, int, TraceProtocolType)

MESSAGE_RemoveHeader( … )

Specific APIs for APPLICATION Layer APP_UdpSendNewData( … )

APP_UdpNewHeaderVirtualDataWithPriority( ... )

17/04/2018

21


Example: Management of Hard Vertical Handover

Scenario A mobile device with two wireless interfaces

One IEEE 802.11 interface and one IEEE 802.16

Goal “In stable conditions” the device exploits only one of

the two interfaces

When received signal quality goes under a given threshold, the device tries to achieve better connectivity by using the other interface


State Diagram

IdlePeriodic Check

Handover Process

TIMER_UPDATE

TRIGGERCOMPLETED

Idle One active interface

Periodic Check Periodically the quality

of the received signal is controlled

Handover Process Both interfaces are

concurrently used, by keeping switched on the “best” of the two

17/04/2018

22


Simple Vertical Handover: Some Considerations

Peculiarities of the protocol

“Single host” protocol: it does not need to communicate with other nodes, only local info

At application level, but it also needs MAC-layer info (signal RSSIs)

Partial breaking of Qualnet layering


Model Definition: things to do

Defining Protocol identifier Type of managed events Employed data structures

Implementing Initialization function: allocation and initialization of the data

structures for the protocol Protocol dispatcher: event management and invocation of

proper handlers Event handler Finalization function: determination and printing of statistics,

deallocation of data structures

“Registering” the new functions on the manager of the appropriate layer

COSTANT

17/04/2018

23


Protocol Definition

Adding the new protocol in the list of the available application-level protocols

typedef enum { // include/application.h

…

APP_FTP_SERVER = 21,

…,

APP_HANDOVER_SIMPLE,

APP_PLACEHOLDER

} AppType;


Event Definition

Including the event types that the protocol aims to manage in the list of possible events

enum { // include/api.h

MSG_APP_CBR_NEXT_PKT,

…

MSG_APP_HANDOVER_UPDATE,

MSG_APP_HANDOVER_TRIGGER,

MSG_APP_HANDOVER_FINALIZE,

…,

MSG_DEFAULT

};

17/04/2018

24


Initialization and Finalization of the Protocol

Initialization function invoked for any instance of the protocol (e.g., for any instance at any node) Allocation and initialization of data structures properly

defined for the protocol Data structure saving in the state of the node to which

they refer to

Finalization function invoked for any instance of the protocol, at the end of the simulation Statistics collection and printing on output file .stat Deallocation of the data structures of the protocol


Initialization and Finalization

void HandoverInit(Node *node) {

HandoverData *hd;

hd = (HandoverData*) MEM_malloc(sizeof(HandoverData));

…

APP_RegisterNewApp(node, APP_HANDOVER_SIMPLE, hd);

timerMsg = MESSAGE_Alloc( node, APP_LAYER,

APP_HANDOVER_SIMPLE,

MSG_APP_HANDOVER_UPDATE);

MESSAGE_Send(node, timerMsg, HANDOVER_UPDATE_PERIOD);

}

void HandoverFinalize(Node *node) {

HandoverData *hd = _HandoverRetrieveData(node);

if ( hd != NULL ) App_UnregisterAPP(node, data);

}

17/04/2018

25


Event Dispatcher

void HandoverProcessEvent(Node *node, Message *msg) {

switch(MESSAGE_GetEvent(msg)) {

case MSG_APP_HANDOVER_UPDATE:

HandoverPeriodcStatusUpdate(node, msg);

break;

case MSG_APP_HANDOVER_TRIGGER:

HandoverStartHandover(node, msg);

break;

case MSG_APP_HANDOVER_FINALIZE:

HandoverMakeDecision(node, msg);

break;

default:

ERROR_ReportError(“Unexpected event”);

}

}


Callback “Registration”

// main/application.cpp

void APP_InitializeApplications(Node *first, NodeInput *in)

{…

for (i=0; i< in.numLines; i++) {

…

else if (strcmp(appStr, “CBR”) == 0) { … }

else if (strcmp(appStr, “HANDOVER_SIMPLE”) == 0) {

…

node = MAPPING_GetNodePtrFromHash( … );

if (node != NULL) {

HandoverInit(node);

}

}

}

}

17/04/2018

26


Callback “Registration”

// main/application.cpp

void APP_ProcessEvent(Node *node, Message *msg) {

…

switch(msg->protocolType) {

case APP_ROUTING_BELLMANFORD:

…

case APP_HANDOVER_SIMPLE:

HandoverProcessEvent(node, msg);

break;

…

}

}

void APP_Finalize(Node *node) {

// Same concept…

}


Dynamic APIs

Monitoring and runtime modification of simulation variables (dynamic variables)

Any protocol/model has to define explicitly the variables that have to be exposed

(simplified) Directory service for instances of dynamic variables

Path of a dynamic variable has to be registered on the corresponding D_Hierarchy service

Dynamic variable has to be explicitly associated with the path via a specific library function

/node/129/interface/192.168.0.1/aodv/numRequestsInitiated

Internal software components can register callback functions to be notified of changes in dynamic variables

17/04/2018

27


External Interface API

It allows the creation of interfaces for the runtime interaction of external software with the simulator

QualNet offers (additional licensing) three different implementations of External Interface API: DIS (IEEE 1278), HLA (IEEE 1516), and STK

QualNet SimulationExternal Interface

External Entity

External Interface API


QualNet: Some Conclusions

Pros Large number of available models, very precise and detailed Wide freedom in configuring the most suitable tradeoff speed

vs. detail for simulations Excellent graphical tools Good manuals and documentation; online support forum that is

well done and very active Well organized and well written code

Cons Need to acquire several licenses in order to use different

models Missing detailed documentation of code (e.g., API doc) Community of developers is limited and less “collaborative” if

compared with other alternative options (see next slide)

17/04/2018

28


Network Simulators: in addition to QualNet?

NS-2 / NS-3 Opensource (GPL) simulators that are widespread and largely

employed, in particular in academic research NS-2 is well-known for its slow learning curve NS-3 is more usable than NS-2, but not equally rich of already

existing accurate models (anyway it is improving…)

OMNeT++ Academic Public License: free for academic purposes Not a network simulator, but a generic framework for discrete

event simulation Several packages available that contain models for network

simulation (INET) Fairly sophisticated language (NED) for the description of

simulation scenarios


I want to Practise with QualNet!

The University of Bologna has a QualNet license installed on a single host Developer Model Library (IEEE 802.3, IP, TCP, UDP, RIP, …)

Wireless Model Library (IEEE 802.11, MACA, DSR, …)

Advanced Wireless Model Library (IEEE 802.16)

Sensor Networks Model Library (IEEE 802.15.4)

UMTS Model Library

Possibility to use that host from remote With some limitations

mobile systems m - unibo.it

Documents