A comparative study of network simulators: NS and OPNET

PDF

Download

Open document

Flip pages

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content A COMPARATIVE STUDY OF NETWORK SIMULATORS:
NS AND OPNET
by
Garima Goel
A Thesis Presented to the
FACULTY OF THE GRADUATE SCHOOL
UNIVERSITY OF SOUTHERN CALIFORNIA
In Partial Fulfillment of the
Requirements for the Degree
MASTER OF SCIENCE
ELECTRICAL ENGINEERING (COMPUTER NETWORKS)
May 2004
Copyright 2004 Garima Goel
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
UMI Number: 1421769
INFORMATION TO USERS
The quality of this reproduction is dependent upon the quality of the copy
submitted. Broken or indistinct print, colored or poor quality illustrations and
photographs, print bleed-through, substandard margins, and improper
alignment can adversely affect reproduction.
In the unlikely event that the author did not send a complete manuscript
and there are missing pages, these will be noted. Also, if unauthorized
copyright material had to be removed, a note will indicate the deletion.
UMI
UMI Microform 1421769
Copyright 2004 by ProQuest Information and Learning Company.
All rights reserved. This microform edition is protected against
unauthorized copying under Title 17, United States Code.
ProQuest Information and Learning Company
300 North Zeeb Road
P.O. Box 1346
Ann Arbor, Ml 48106-1346
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
ACKNOWLEDGEMENTS
I would like to acknowledge the support and guidance of my advisors, Dr.
C.-C. (Jay) Kuo, Dr. Antonio Ortega, Dr. Melvin Astrahan. I would also like to thank
my mentors, Fang Liu and Lei Huang for their help.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
TABLE OF CONTENTS
Acknowledgements ii
List of Tables iv
List of Figures v
Abstract vii
1. Introduction 1
1.1 Desirable Features of Network Simulators 3
1.2 Overview of NS - Network Simulator 6
1.2.1 NS Architecture 7
1.3 Overview of OPNET 10
1.3.1 Modeling in OPNET 10
1.3.2 OPNET Models 12
1.3.3 OPNET Tools 13
1.4 Overview of Wireless LAN Protocol 14
2. Simulations performed inNS and OPNET 16
2.1 Simulation Scenario 16
2.2 Assumptions 17
2.3 Simulation Parameters 18
2.4 Simulation Discussion 18
2.5 Simulation Results 20
2.6 Simulation Analysis 27
2.7 Comparison between wireless modules of 30
NS and OPNET
3. Comparison between NS and OPNET 31
3.1 Comparisons 31
3.2 Advantages of NS 33
3.3 Disadvantages of NS 34
3.4 Advantages of OPNET 34
3.5 Disadvantages of OPNET 35
4. Conclusion 36
5. References 38
1 1 1
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
LIST OF TABLES
Table 1.1 Protocol and Application Support in NS 6
Tabic 2.1 Simulation parameters 18
Table 2.2 DSSS parameters set inNS 19
Table 2.3 DSSS parameters set in OPNET 19
Table 2.4 Throughput and data dropped inNS 21
Table 2.5 Throughput and data dropped in OPNET 21
Table 2.6 Comparison of wireless LAN modules of 30
NS and OPNET
Table 3.1 Comparison between NS and OPNET 31
IV
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
LIST OF FIGURES
Figure 1.1 Mirroring of C++ and OTcl object hierarchies 8
Figure 1.2 NS architecture 9
Figure 1.3 OPNET Models supported at different layers 12
Figure 1.4 OPNET tools at each step of simulation cycle 13
Figure 2.1 Simulation Topology 17
Figure 2.2 Throughput in Mbps for channel bit rate of 1 Mbps 21
inNS
Figure 2.3 Throughput in bps for channel bit rate of 1 Mbps in 21
OPNET
Figure 2.4 Throughput in Mbps for channel bit rate of 2Mbps 23
inNS
Figure 2.5 Throughput in bps for channel bit rate of 2Mbps in 23
OPNET
Figure 2.6 Throughput in Mbps for channel bit rate of 24
5.5Mbps inNS
Figure 2.7 Throughput in bps for channel bit rate of 5.5Mbps 24
in OPNET
Figure 2.8 Throughput in Mbps for channel bit rate of 11Mbps 25
inNS
Figure 2.9 Throughput in bps for channel bit rate of 11Mbps 25
in OPNET
Figure 2.10 Data dropped in Mbps for channel bit rates 1, 2, 26
5.5, 11Mbps inNS
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
LIST OF FIGURES
Figure 2.11 Data dropped in bps for channel bit rates 1, 2, 5.5, 26
11Mbps in OPNET
Figure 2.12 Code fragment of mac-802 1 l.cc file of NS 28
Figure 2.13 Code fragment of wlan_mac.pr.c file of OPNET 29
VI
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
ABSTRACT
Network simulators play a significant role in network research that involves
the validation of the behavior of existing protocols, the development of new
protocols, and performance comparison of different algorithms and architectures. A
number of commercial and academic simulators are currently available for network
research and development, including REAL, GlomoSim, JavaSim, NS (Network
Simulator), SSFNet and OPNET (Optimized Network Engineering Tool). They are
used for modeling, simulation, data collection and analysis of various types of
network products, protocols and system architectures. This work investigates two
popular discrete-event simulators used in the network community, NS and OPNET.
The architecture, modeling efficiency, simulation performance, analytical capability,
protocols and applications of NS and OPNET are compared. This work is significant
because a comparative study between NS and OPNET has not been undertaken in
much detail before. It provides a guide to researchers for choosing the appropriate
simulator depending on their simulation requirements.
V ll
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
CHAPTER 1
Introduction
Computer Networks play an important role in today’s world. The Internet’s
rapid growth has led to the development of new protocols and applications. To
develop, test, and diagnose these network protocols - researchers use network
simulators. Network simulators simulate hosts, routers, servers, application programs
that generate network traffic and network utility programs that configure and gather
statistics about a simulated network. Network simulators are used both in academic
study and industrial research and development. The two widely used network
simulators are NS and OPNET.
NS is predominantly used in the academic environment while OPNET in the
industrial environment. My thesis work comprises an in-depth comparison between
NS and OPNET network simulators in terms of their architecture, modeling
efficiency, simulation performance, analytical capability, and protocols and
applications support. It is of significance because such comparative study has not
been undertaken in significant detail before. My work provides a guide to researchers
and developers for choosing the appropriate network simulator depending on their
simulation requirements.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Chapter 1 lists the desirable features of network simulators that form the
basis of my comparative study. It gives an overview of the NS simulator and OPNET
simulator. To compare the simulation performance, I simulated wireless LAN
module in both NS and OPNET since it was recently added to both the simulators.
An overview of wireless LAN protocol is given in Chapter 1. Actual simulations
with their results and analysis for wireless LAN module are presented in Chapter 2.
The detailed comparison of wireless modules of NS and OPNET is also given in this
chapter. Chapter 3 gives a comparison of NS and OPNET simulators in terms of
their architecture, modeling efficiency, analytical capability and protocols and
applications support. Finally, I put forth my conclusions in Chapter 4.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
1.1 Desirable Features of Network Simulators
A number of commercial and academic network simulators are available to
the research community. Some simulators target a particular type of protocol or
network. For example, NETSIM is designed for the study of Local Area Networks
(LANS). Others, like NS, OPNET and GlomoSim are capable of simulating a wide
range of networks and protocols. In order to provide researchers with a rich
inffastracture for validating and developing new protocols, I feel that all simulators
should possess the following desirable features: -
a) Accuracy - Since simulators just emulate the real world scenarios, they suffer
from inherent fallacies in depicting the actual results. For some simulations, protocol
behavior rather than the accuracy of results is of more concern to a researcher. For
example, to study RED (Random Early Detection) behavior, the RTT (Round Trip
Time) calculation for a packet need not be very precise. Whereas, it would be
necessary to have a precise RTT calculation for comparing the throughputs of two
different communication links.
b) Analytical capability - A simulator that provides graphical plots like histograms,
distribution curves etc. rather than numerical values will be easier to use for the
researchers.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
c) Reproducibility - Researchers often need to run multiple simulations for the same
experiment in order to derive meaningful conclusions. The network simulator, thus,
should be reliable in the sense that it should produce similar results for same inputs
on each run.
d) Efficient modeling - A simulator should have the ability to model various kinds
of nodes, links and network protocols. It should be an easily reconfigurable network
simulator with a user-friendly interface.
e) Low memory and processing requirements - Computer resource limitations,
such as memory and processing time limit the number of nodes, links or protocol
agents that can be simulated. A network simulator, which can avoid unnecessary
detail and exploit parallelism, will be more scalable and useful.
f) Flexibility - A network simulator should be highly modular and flexible in design.
This gives the researchers an ability to simulate multiple scenarios with less effort.
g) User friendliness - An interactive GUI (graphical user interface) of the simulator
helps the user to model, simulate and analyse various simulation scenarios easily.
h) Protocols and applications support - A simulator should provide a good support
for various networks, protocols and applications.
i) Ease of Learning - A simple and easy-to-leam simulator helps the user to use the
capabilities of the simulator easily. It reduces the learning time for a novice.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
j) Extensibility - A simulator should have an extensible design so that the
researchers can add new protocols and application modules, and can customize it
according to their simulation requirements.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
1.2 Overview ©f NS - Network Simulator
NS stands for Network Simulator. It is a packet-level discrete event
simulator. It started as a variant of REAL network simulator in 1989 and is currently
used extensively in conducting network research in academic environments. NS
provides substantial support for simulation of TCP, routing, and multicast protocols
over wired and wireless (local and satellite) networks. I have used the current release
version of NS -2.26 for my comparative study. It has support for the following
protocols and applications; -
Transport Protocols - TCP, UDP
Multicast Transport - DSR, PIM, SRM, RPM
Wireless Networking - Distance Vector and Link State, Ad-Hoc Routing
protocols. Multi-hop routing protocols (DSR, AODV, TORA, DSDV)______
Application-level Protocols ~ HTTP, FTP, Telnet
MAC protocols - 802.3, 802.11, TDMA
Scheduling disciplines - Drop Tail, FIFO, RED, CBQ, WFQ, SFQ, DRR
Different traffic characterizations - Poisson, Exponential, Pareto, CBR
Sensor Networks - Directed Diffusion, G a f_____
Satellite Networks
Measurement of Statistics - Throughput, Delay, Jitter, Packet Drops
Emulation
Table 1.1 Protocol and Application Support in NS
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
1.2.1 NS Architecture
NS Duality model
NS employs a split-programming model. Its detailed protocol
implementations (packet forwarding, routing etc.) and low-level event processing are
done in fast to run and slow to change, compiled language, C++. Whereas,
generation of simulation scenarios is done in slow to run and fast to change
interpreted Tcl script. Tcl procedures are used for start and stop events, network
failure, statistics gathering and network configuration. For building reusable models,
object-oriented extension of Tcl, OTcl is used. Tcl interpreter has been extended
(OTcl) with commands to create the network topology of links, nodes and agents.
New objects in OTcl interpreted class hierarchy are mirrored in C++ compiled class
hierarchy.
Tcl with classes (TclCL) is an extension of OTcl that provides object linkage
between C++ and OTcl. Figure 1.1 depicts the mirroring of Otcl objects in C++
object hierarchy.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
C-H- Objects
cfb
Otcl Objects
C-H-/Otcl Split
Objects
Figure 1.1 Mirroring of C++ and OTcl object hierarchies - [ISIl]
NS Simulation Engine
NS is a discrete-event simulator. The simulator is single-threaded and has one
event in execution at any given time. If multiple events are scheduled to execute at
the same time, their execution is performed in the first scheduled- first dispatched
manner. It does not support partial execution of events or pre-emption. NS presently
supports four event schedulers- list, heap, calendar, and real-time. Event schedulers
are written in C++.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
NS Network Components
The network components consist of various kinds of nodes, links, traffic
generators, queuing disciplines and protocol agents. These network components are
specified as C++ objects.
Figure 1.2 depicts the overall NS architecture.
Event
Scheduler
ns-2
tclcl
o
O 2
3 ®
T3 ?
§ i
otcl
tclS.O
Figure 1.2 NS architecture - [ISIl]
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
1.3 Overview of OPNET
OPNET (Optimized Network Engineering Tool) is a commercial network
simulator marketed by OPNET, Inc. and introduced in 1987. It is a discrete-event
simulator which can simulate a large range of communication systems from a single
LAN to global satellite networks. It is used by researchers and developers to build
specification models, run simulation and analyse the results in order to measure
performance of various kinds of networks. OPNET has four major components: -
a) Event Driven Simulation Engine
b) Set of Application Interfaces implemented as C libraries
c) Large Library of Protocol modules
d) Graphical tools and Editors
I have used the current release version of OPNET - 8.1 for the comparative study.
1.3.1 Modeling in OPNET
OPNET employs hierarchical object-based modeling - paralleling the
structure of actual communication networks. It basically divides the modeling
environment into three domains: -
10
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
a) Network Domain: - It is at the highest level of the hierarchy. Its role is to define
the topology of the communication network consisting of communicating entities
called nodes. The capabilities and the behavior of each node are defined by
specifying a node model using the Node Editor. A network model may make use of
any number of node models. OPNET modeler in conjunction with Radio version
supports the simulation of fixed as well as mobile and satellite nodes. It supports
simplex and duplex point-to-point links, bus links and radio links.
b) Node Domain: - Its role is to model the communication devices that can be
interconnected at the network level. The nodes could be of various kinds such as
routers, bridges, terminals, file servers, workstations, satellites etc.
c) Process Domain: - The behavior of processor and queue modules of nodes is
specified in Process Domain with the help of Process Editor. Process Editor uses
Proto-C, which is a combination of State Transition Diagram, embedded C/C-H-
statements and a library of kernel procedures to express the process models.
11
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
1.3.2 OPNET Models
E-mail, FTP, HTTP, Print, Remote Login, Database Application
Layer
i
TCP UDP Transport Layer
i
BGP, EIGRP, IGRP, IS-IS, OSPF, RIP, IP, RSVP,
IPX
Network Layer
1
ATM, Ethernet, FDDI, Frame Relay, LANE,
LAPB, Token Ring, X.25, Spanning Tree Bridge
(STB), Spatial Reuse Protocol (SRP), Wireless
LAN (802.11)
Data Link
Layer
Figure 1.3 OPNET Models supported at different layers
Figure 1.3 depicts the specific models supported by OPNET 8.1 at each layer.
OPNET also supports queuing disciplines such as FIFO, LIFO, RR, shortest first job,
priority queuing. It has support for a number of traffic characterizations like Pareto,
Exponential, CBR, Poisson, and Uniform. It supports simulation of satellite and
sensor networks too. In addition to this it supports IP multicasting, PNNI, MPLS and
ISDN modeling.
12
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
1.3.3 OPNET Tools
OPNET has number of tools or editors for specifying the model to be
simulated. It has different tools for each step of the simulation cycle - model
building, running simulations, and analyzing results.
The model-specification editors are organized in hierarchical fashion. The
functions of the tools at each level are shown in the following figure: -
Simulation Tool - Define and run simulation
Debugging Tool - Debug the simulations
Running Simulation
Network Editor - Define physical topology of the network
Node Editor - Define communication devices
Process Editor - Define logical flow of processors and queues
Model Building
Probe Editor - Specify output data to be collected
Analysis Tool - Display graphical output
Filter Tool - Process the output data
Animation Viewer - Observe dynamic behavior
Analyzing Results
Figure 1.4 OPNET tools at each step of simulation cycle
13
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
1.4 Overview of Wireless LAN protocol
IEEE 802.11 is a protocol standard for wireless local area networks
consisting of both the physical layer (PHY) and the medium access control (MAC)
layer. IEEE 802.11 offers three physical layer implementations - Infrared (IR),
Direct Spread Spectrum Sequence (DSSS) and Frequency Hopping Spread Spectrum
(FHSS). The MAC architecture is composed of two coordination functions- Point
Coordination Function (PCF) and Distributed Coordination Function (DCF).
Coordination function is defined as the function that determines, within a Basic
Service Set (BSS), when a station is enabled to transmit and/or receive Protocol Data
Units at MAC level (MPDUs) through the wireless channel. DCF, based on
CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) is the primary
access method, which provides contention - based shared access to the medium.
Retransmission of collided packets is managed according to binary exponential back
off rules. PCF is an altemative access scheme for time-bounded data transmissions,
which contains a point coordinator to determine which station has the right to
transmit using a polling scheme.
DCF employs two techniques for packet transmission. The core mechanism is
Basic Access Method. Under the basic access method, a station, when ready for a
new data frame transmission, first senses the channel status. The station can proceed
with its transmission if the channel is determined to be idle for a time interval of
14
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
DIFS (DCF Inter- Frame Space). After the data frame is successfully received at the
destination, the receiver must send an acknowledgement frame (ACK). If the channel
is found to be busy, the station defers its transmission and continues to sense the
channel until it is idle. After the channel is idle for a DIFS, the station chooses a
random number as a back-off timer. The back-off timer is decreased by one for each
idle slot, stopped if the channel is sensed busy, and then reactivated if the channel is
idle again and remains idle for more than one DIFS time duration. When the back-off
timer reaches zero, the data frame is transmitted. The choice of the random number
for the back-off timer is based on the binary exponential back-off algorithm, where a
station chooses any of the numbers between 0 and w-1 v\fiere w is the contention
window. The value of w depends on the number of transmissions failed for a packet.
At the first transmission attempt, w is set to CWmin called minimum contention
window. After each unsuccessful transmission, the value of w increases
exponentially until it reaches and then stays at CWmax = 2'Tn CWmin. The values
CWmax and CWmin are physical layer specific. DCF also provides altemative way
of transmitting data frames that involve transmission of RTS (Request to Send) and
CTS (Clear to Send) prior to actual data transmission. RTS and CTS are used to
reserve the channel between the transmitter and the receiver. The RTS frame is
transmitted by a station, which needs to transmit a data packet. The receiving station
responds with a CTS frame after a SIFS (short inter-frame space) period. Once the
RTS/CTS are exchanged successfully, the sender then transmits its data frame.
15
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
CHAPTER 2
Simulations performed in NS and OPNET
2.1 Simulation Scenario
I simulated a wireless LAN campus network in NS and OPNET consisting of
a small number of nodes: -5, which are able to communicate with each other directly.
The network is an independent BSS of wireless workstations. Each workstation runs
wireless LAN protocol and implements CSMA/CA MAC level protocol for collision
avoidance. In my simulation scenario, there are no hidden nodes. Thus, there is no
need to enable RTS/CTS mechanism for channel access.
For NS, I generated my simulation scenario by writing a Tcl script .1 changed
wireless LAN parameters in file mac-802_ll.cc according to my requirements. The
results were viewed using XGraph. For OPNET, I used existing node models for
wireless station. I used Network Editor for the specification of topology and
Parameter Editor for specification of simulation parameters. Probe Editor was used
to specify the results to be collected. Results were viewed in Analysis Configuration
window.
Based on the experience in running my simulations, I analyse and investigate
the pros and cons of wireless LAN module of each simulator. This analysis thus
gives an insight into the scope of improvement for each simulator.
16
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
802.11 Wireless LAN
Independent BSS
250m X 250m
Node 1
Node 2 Node 3
Node 4
Figure 2.1 Simulation Topoiogy
2.2 Assumptions
a) Independent BSS
b) Channel is noiseless
c) No hidden stations
d) Fixed sized packets
e) Fixed packet generation rate
f) No mobility of nodes
g) Small coverage area
17
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
2.3 Simulation Parameters
Input Parameters
Number of stations 5
Coverage Area 250m X 250m
Physical layer DSSS
Channel bit rate 1,2, 5.5 ,11Mbps
Short Retry Limit 7 slots
Long Retry Limit 4 slots
Fragmentation Threshold 2346 bytes
RTS Threshold 3000 bytes
Traffic Distribution CBR
Packet Size 1000 bytes
Packet type UDP
Traffic Rate 1Mbps
Traffic Start Time 5 sec
Simulation Time 120 sec
Table 2.1 Simulation parameters
Performance Metrics
a) Network Throughput
b) Total data dropped in the network
2.4 Simulation Discussion
The simulation traffic was generated at each station using CBR traffic generator that
generated fixed sized packets (1000 bytes) at the rate of 1Mbps. Simulations were
run for the channel bit rates of - 1Mbps, 2Mbps, 5.5Mbps, and 11Mbps.
18
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
NS
The parameters for DSSS physical layer were set to the values as shown in
Table 2.2. The values confirm to IEEE 802.11 standard. These parameters were set
in mac 802-11 .h file.
CWMin 31
CWMax 1023
SlotTime 20us
CCATime lOus
Propagation Delay 2us
RxTxTumaroundTime 5us
SIFSTime lOus
PLCPPreambleLength 144bits
PLCPHeaderLength 48bits
PLCPDataRate 1Mbps
Table 2.2 DSSS parameters set in NS
OPNET
The parameters for DSSS physical layer were set to the values as shown in
Table 2.3.The values confirm to IEEE 802.11b standard. These parameters were set
in wlan mac.pr.c file.
Slot Time 20us
SBFS lOus
PLCPOverheadControl 192us
FLCPOverheadData 192us
CWmin 31
CWmax 1023
Table 2.3 DSSS parameters for OPNET
19
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
2.5 Simulation Results
For each of the simulations in NS, the graphs for the network throughput (in
kbps) are given in Fig. 2.2, 2.4, 2.6, and 2.8. X-axis represents the simulation time
and Y-axis represents the throughput in Mbps. The graph for data dropped (in Mbps)
is given in Figure 2.10. X-axis represents the simulation time and Y-axis represents
the data dropped in Mbps. The average throughputs, throughput efficiency (average
throughput/channel bit rate), data dropped at different channel bit rates are tabulated
in Table 2.4. For each of the simulations in OPNET, the graphs for the network
throughput (in bps) are given in Fig. 2.3, 2.5, 2.7, and 2.9. X-axis represents the
simulation time and Y axis represents the throughput in bps. The graph for data
dropped (in bps) is given in Figure 2.11. X-axis represents the simulation time and Y
axis represents the data dropped in bps .The average throughputs, throughput
efficiency, data dropped at different channel bit rates are tabulated in Table 2.5.
20
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Channel Bit Rates Average
throughput
Throughput
Efficiency
Data
Dropped
1Mbps 0.6Mbps 60% 0 Mbps
2Mbps 1.0Mbps 50% 0 Mbps
5.5Mbps 1.7Mbps 30% 0 Mbps
11Mbps 2.0Mbps 18% 0 Mbps
Table 2.4 Throughput and data dropped in NS
Channel Bit Rates Average
throughput
Throughput
Efficiency
Data
Dropped
1Mbps O.SMbps 80% 0Mbps
2Mbps 1.5Mbps 75% 0Mbps
5.5Mbps 3.3Mbps 60% 0Mbps
11Mbps 5.0Mbps 46% 0Mbps
Table 2.5 Throughput and data dropped in OPNET
21
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Close Hdcpii About
V k 1 0 '
600.00DO-
500,0100-':
400.0000--
3 0 0 .0 0 0 0 --
2 0 0 .0 0 0 0 --;
; 00.0000"
0 0000
0.0000 20 0300
X Graph
cutl'O tr
40 0000 60.0000 80.0000 100.0000 ■ 1 0 co co
Figure 2.2 Throughput in Mbps for channel bit rate of 1Mbps in NS
a i i i i i i
__
--------------
S'BiiiffllBlii - mmms i i
........
200 .DDO _ 200,000 ^
____
------------
1m 2Ds
Figure 2.3 Throughput in bps for channel bit rate of 1Mbps in OPNET
22
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Cfesel Hdcpif A
Y
1 O O D C ...........
x c Sraph
SiiFioF-
% . ■ 5000..............
r, vnnn..............
I B i l i l l l B I I I
0.0000 -----
0.0000 20 0000 4G.r 000 o o r 000 80.0000 100. O O O O ISO o o c o
Figure 2.4 Throughput in Mbps for channel bit rate of 2Mbps in NS
.-.-I I :ir
-i *
■ jr.. I I -
Figure 2.5 Throughput in bps for channel bit rate of 2Mbps in OPNET
23
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
C ic i5 ‘ -b ru t
) 8
1.6000-
1 4C00-
1 2000 -
5.0000-
o e c -0 0 -
O R C O f i-
0 4000-
GiCOC-
coooc
‘ ‘ •
1
I
W K m S I § iM 9 S ^
X Graph
cliftO.t, '
0.0000 20C0CC 4COOOO 60.0000 60.0000 100 0C00 120.0000
Figure 2.6 Throughput in Mbps for channel bit rate of 5.5 Mbps in NS
Ws'f-ls*: ■ : IAN r hr-'u-T.i-.pf ;hii-n2'oi-.l
I A N . i III < > < i a | l i | k i i l ( l i i l - . • . ■ - 4 } • I V/ii •-!»
1 io = ?u .::0 )u
■ i "
■ —
Figure 2.7 Throughput in bps for channel bit rate of 5.5Mbps in OPNET
24
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Iloie AI;out
1 500&--
1 o eo o -
0.5G00-
..........i
I J I j i d l l l l i j
__
X Graph
oijt'C tr
0.0000
0.0000 ........ 20.0000............ .40 QOQP O O ^M ..........80.0000 lOOiOOQOI
Figure 2.8 Throughput in Mbps for channel bit rate of 11Mbps in NS
123 0C00
o ou
5 iOU.Ul^D
4,000,000
i!.cur.i,=jo3
1 ,o c j:,ijo n
. T I■ ■ : .-iuc-:r’r = = j ' ,ljii j/'ier;.-j
r o
T
■- • ■ 4 1 - ■ .. 2 1 1
!
am
Figure 2.9 Throughput in bps for channel bit rate of 11Mbps in OPNET
25
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Close H ctcpy About
Vx 10"3
400 O O G O -
aaa:® s® :
-0 .0 G 0 0
200.0000*-
4 O & 0 O O O > : S
Figure 2.10 Data dropped in Mbps for channel bit rates 1,2, 5.5,11Mbps in NS
I
i r
Wiresles® LAM.Dat^ Dropped Cbits-'secJ
* I W l « I A I N . I »4«f a« I k| < l > | l «■ H« • ^
1 ooo
0,S?5
0.750
o .e z s
Q.500
0,-375
0.250
0.125
0.000
:s;S > K i;s;S
S Q rn :# S S :;,i
l_
1 m 20s
Figure 2.11 Data dropped in bps for channel bit rates 1 ,2 ,5 .5 ,11Mbps in OPNET
26
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
2.6 Simulation Analysis
As we can see from Table 2.4 and 2.5, the data dropped remains at 0 Mbps
for all the data rates in both NS and OPNET. This is the expected behavior since
there are very few stations and they are implementing CSMA/CA collision
avoidance mechanism for channel access. So, there are no drops due to collisions.
Also, the channel was noiseless, so there were no drops due to corruption of packets.
As we can see from Table 2.4, the average throughput and throughput
efficiency values for NS is 50 - 60%. In real network scenarios, the maximum
throughput that can be achieved is 70 - 80% of the channel bandwidth [Junl], [Liul].
The maximum throughput achieved is 2Mbps (at channel bit rate 11Mbps) which is
also the maximum data rate supported by 802.11 implementation.
Table 2.5 shows that the throughput values for OPNET at the rates of 1Mbps,
2Mbps and 5.5Mbps are consistent with the expected results since the maximum
throughput achievable in IEEE 802.11b is 70-80% of the channel bandwidth [Junl],
[Liul]. OPNET gives throughput of 5.0 Mbps for channel bit rate 11Mbps. The
throughput efficiency is low (46%) in this case since the maximum network load
(from all 5 stations) is 5Mbps at any instant. Thus, IEEE 802.11b module
implemented in OPNET is able to support 1, 2, 5.5,11Mbps data rates for DSSS.
As explained earlier, according to IEEE 802.11 standard, a station senses the channel
before transmission of a frame. If the channel is sensed to be idle for the
27
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
duration of DIFS, then it should immediately transmit the frame. The code fragments
that implement the deference before transmission in NS and OPNET are given in Fig
2.12 and Fig. 2.13 respectively. NS defers for DIFS and backs off for random
number of slots after sensing the medium idle. This is not according to the IEEE
802.11 standard. OPNET immediately transmits the frame if the station is idle for
DIFS time which is according to the IEEE 802.11 standard.
As seen in Fig 2.12, NS incorrectly sets the deference time to DIFS + random
integer where random integer is randomized in the interval of 0 to w. w can take
values from CWmin to CWmax. Since, the values of CWmin and CWmax fall in the
range of 31 to 1023, the deference time value in case of NS can be large at times. I
suspect that it is the cause of reduction in throughput values of NS simulations.
/* If the medium is IDLE, we must wait for a DIFS Space before transmitting.*/
if(mhBackoff_.busyO = 0) {
if(is_idle()) {
/*
* If we are already deferring, there is no
* need to reset the Defer timer.
*/
if(mhDefer_.busy() = 0) {
rTime = (Random: irandomQ % cw_J * (phymib_->SlotTime);
mhDefer_.start(difs_ + rTime);
}
}
Figure 2.12 Code fragment of mac-802_Il.cc file of NS
28
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
if (READY_TO_HlANSMIT)
{
!* If the medium was idling for a period equal or longer than*/
/* DIFS time then we don't need to defer.*/
if(MEDIUM_IS_IDLE && !IN_CFP)
{
/* We can start the transmission immediately.*/
wlan_flags->immediate_xmt = OPCTRUE;
backoff_slots = 0;
}
Figure 2.13 Code fragment of wlan_mac.pr.c file of OPNET
Also, NS does not prompt the user for higher channel bit rates - 5.5Mbps and
11Mbps that are not supported by IEEE 802.11 implementation. It simulates 802.11
with bit rates higher than 2 Mbps that is erroneous.
We can conclude from the above results and the code fragments that NS -
2.26 does not implement wireless LAN module as accurately as OPNET. . Although
OPNET does not implement physical layer specifications of IEEE 802.11, yet it
gives results, which are close to the expected results, using some approximations.
These issues are clearly documented in OPNET manual.
29
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
2.7 Comparison between wireless modules of NS and OPNET
NS and OPNET are still being developed with more and more modules being
added frequently. Table 2.6 compares the wireless LAN modules of NS and OPNET.
This comparison is based on the current modules supported in NS-2.26 and OPNET -
8.1. This comparison is made after reading the source code of wireless LAN
modules and running the simulations in both the simulators.
Points of
Comparison
NS OPNET
Access Control 1. Distributed Coordination
Function (DCF)
2. Point Coordination function
(PCF)
1.DCF
2. PCF
MAC layer
protocols
802.11 802.11b
Frame
Exchange
1. DATA/ACK for broadcast
packets
2. RTS/CTS/DATA/ACK
pattern for unicast packets
1. Minimal frame exchange -
DATA/ACK
2. Optional frame exchange-
RTS/CTS for media
reservation
Deference and
Backoff
CSMA/ CA with binary
exponential backoff
CSMA/CA with binary
exponential backoff^
Link Layer Link layer handles fragmentation
/ re-assembly and runs ARP
MAC layer interface handles
ARP and fragmentation /
reassembly
Physical Layer Simulates actual physical layer
specifications of 802.11
Doesn’t simulate actual
physical layer specifications of
802.11b
Data Rate 1, 2 Mbps as in IEEE 802.11 1,2,5.5,11 Mbps as in IEEE
802.11b
Table 2.6 Comparison of wireless LAN ofNS and OPNET
30
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
CHAPTER 3
Comparison between NS and OPNET
3.1 Comparisons
Points of Comparison NS OPNET
Does it have an
integrated GUI?
No. Uses NAM for
packet-level animation
and topology layout.
Yes. Has tools to specify
topology and to plot and
analyse time series,
histograms and probability
functions for simulation
results.
Does it have open source
architecture?
Yes. Yes.
Is it freely available? Yes. No. It is expensive,
commercial software that
requires license.
Is it easy to leam and
use?
No. Due to lack of proper
documentation and
integrated GUI for
generating network
scenarios, it is not easy to
leam and use.
Yes. Due to very detailed
documentation and
excellent graphical
modeling, it is easier to
leam and use.
Can it run on multiple
platforms?
Yes. Yes.
Is it object-oriented in
design?
Yes. Yes.
Is it hierarchical in
design?
No. Yes.
Does it have
performance monitor to
easily plot performance
curves?
No. Has ability to gather
performance metrics. But,
requires some graphical
display softwares (like
XGraph) for displaying
the performance curves.
Yes. Has in-built support
for collecting performance
metrics and displaying
performance curves.
Table 3.1 Comparison between NS and OPNET
31
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Point of Comparison NS OPNET
Can it support remote
simulations?
Yes. Supports remote
simulations.
No. Does not support
remote simulations.
Does it have efficient
simulation engine?
Yes. Uses discrete-event
simulator.
Yes. Uses discrete-event
simulation and also
supports hybrid
simulations to reduce time
and memory requirements.
Can the simulator
support parallel
simulations on multiple
processors?
No. Does not support
parallel simulations.
Yes. Supports parallel
simulations on multiple
processors.
Can it log wired and
wireless packet transfers
and later use a packet
animation player to
replay them?
Yes. Collects packet level
traces. The trace file
records the information
about packet transfer in
ASCn text format that can
be used by NAM.
No. Changes have to be
made to source code to
record packet transfers.
Can new protocols be
easily added to the
simulation engine to
enhance its capability?
Yes. Because of non-
hierarchical design, it
requires less effort to add
or modify a protocol.
No. Requires lot of efforts
to add or modify a
protocol since changes are
to be made at each level of
hierarchy.
Can application
programs use the real-
life BP address scheme
and meaning to send
packets?
No. Uses its own
addressing scheme (32bits
for node-id and 8 bits for
port-id). Also, supports
hierarchical addressing.
Yes. Uses real-life IPv4
addresses
Can it support
simulation of satellite
and sensor networks?
Yes. Yes.
Can it support
emulation?
Yes. No
Can it simulate large
networks?
Yes. But, it takes more
time. Also, it requires
more amount of disk space
to store the packet trace
files.
Yes. But, it takes more
time. Also, it requires
more amount of disk space
to store the simulation
result files.
Table 3.1 Comparison between NS and OPNET continued
32
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
3.2 Advantages of NS
a) Open Source and Free - NS is publicly available and has open source
architecture. This allows researchers to add new protocol modules and users to
customize existing protocol modules according to their simulation needs.
b) Multi-platform Support - Most UNIX and UNIX-like systems: - Linux, Free
BSD, Sun OS/Solaris, HP/SGI, Windows 95/98/NT/ME/2000 are supported.
c) Object Oriented - High-level objects represent entire network whereas low-level
objects represent components like queues and de-multiplexers. Such an object-
oriented design makes it easy to implement variants of existing protocols.
d) Extensibility - It is easy to add new protocols and generate more network
scenarios with the help of its split-programming model. This makes NS extensible.
e) Dynamic Configuration - Simulation configurations are expressed as programs
in Tcl language rather than as a static configuration. This helps in generating
multiple scenarios with less effort and time.
f) Good protocol and applications support - It has support for various kinds of
protocols and applications.
33
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
3 3 Disadvantages of NS
a) Complicated Source Code - NS source code is not properly documented. Thus, it
takes time to understand its implementation.
b) Time-Consuming - NS supports sequential and non-distributed simulations that
degrade its performance. It is not suited for running very large-scale simulations
because it takes a lot of time.
c) Non-interactive Simulation - NS does not have a GUI of its own. It uses NAM
(Network Animator) to graphically represent the results. NAM uses huge trace files,
which is another drawback.
d) Bugs - NS is still in research phase and there are still bugs in it.
e) Learning Difficulty - NS consists of huge protocol library. It requires a lot of
leaming on the user’s part because of the lack of a GUI, which becomes even more
difficult with little documentation publicly available.
3.4 Advantages of OPNET
a) Excellent GUI - OPNET has a comprehensive collection of tools for simulation
modeling and result display and analysis. It can plot and analyse time series,
histograms, probability functions, parametric curves and confidence intervals.
34
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
b) Highly Efficient simulation engine - OPNET also provides an option of using
hybrid simulations in order to improve the simulation performance by combining the
accuracy of discrete-event simulation with the speed of analytical modeling.
c) Hierarchical Object-based design - Its hierarchical and object-oriented design is
useful in modeling, simulating and debugging complex network scenarios.
d) Multi-platform support - Can be used on SUN, Windows 95/98/2000/NT, HP-
UX, Silicon graphics.
e) Open Source Architecture - The source code of OPNET models is open to
public. This, together with the detailed documentation, gives an opportunity to
researchers to develop new protocols and application models for OPNET.
3.5 Disadvantages of OPNET
a) Expensive and commercial - OPNET may not be suitable for academic research
tasks since it is expensive and requires license.
b) Less flexible - Because of OPNET’s hierarchical design, it requires more effort to
add or modify a module since the changes are to be incorporated at each level of
hierarchy.
35
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
CHAPTER 4
Conclusion
OPNET is more suitable for industrial environment since it is commercial
software. It is easy to leam and use. It has excellent documentation, graphical
interface and analytical capabilities. The modeling in OPNET is much easier as
compared to NS. Different scenarios can be generated very quickly and the results
for each of them can be plotted and compared graphically. Its hierarchical design
makes it very modular. It has the ability to accurately simulate wide range of
networks and protocols. But, it is expensive and is not freeware. Its hierarchical
design makes it less flexible, which inhibits its use in research tasks. OPNET is less
open in incorporating the rapidly emerging technologies since users cannot directly
contribute to its models due to its commercial nature. It would be certainly helpful
for academic researchers if a lighter and inexpensive version of OPNET is made
public.
NS is still in research phase and has bugs in some of its modules. However,
NS provides a comprehensive network simulation environment. It can be widely
used to simulate various network scenarios. NS is more suitable for research
purposes in academic environment since it is open source and free. This gives the
researchers the flexibility to develop new models as well as modify existing ones
according to their research needs. NS can easily embrace the emerging technologies
36
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
because numerous users across the globe are able to directly incorporate their
contributions. It suffers from some drawbacks like inaccuracy in results, inadequate
documentation, less user-friendliness and analytical capability. These areas certainly
need improvement.
37
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
REFERENCES
[Chatl] P. Chatzimisios, V. Vitsas and A.C. Boucouvalas, “Throughput and delay
analysis of IEEE 802.11 protocol”, in Proceedings of the 5* IEEE International
Workshop on Network Appliances, 2002.
[lEEEl] IEEE 802.11, 1999 Edition (ISO/IEC 8802-11; 1999) IEEE Standards for
Information Technology - Telecommunications and Information Exchange between
Systems- Local and Metropolitan Area Network - Specific Requirements - Part 11:
Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications.
[ISIl] Information Science Institute - University of Southem California, University
of Califomia - Berkeley, Xerox PARC, Network Simulator, NS-2 Home
page “http://www.isi.edu/nsnam/ns”.
[Junl] Jangeun Jun, Pushkin Peddabachagari, and Mihail Sichitiu, “Theoretical
Maximum Throughput of IEEE 802.11 and its Applications”, in Proceedings of the
Second IEEE Intemational Symposium on Network Computing and Applications,
2003.
[Liul] Jason Liu, David M. Nicol, L. Felipe Perrone, Michael Liljenstam, “Towards
high performance modeling of the 802.11 wireless protocols” in Proceedings of the
Winter Simulation Conference, 2001.
[OPNl] OPNET technical documentation.
38
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Asset Metadata

Creator Goel, Garima (author)

Core Title A comparative study of network simulators: NS and OPNET

Contributor Digitized by ProQuest (provenance)

School Graduate School

Degree Master of Science

Degree Program Electrical Engineering (Computer Networks)

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag Computer Science,engineering, electronics and electrical,OAI-PMH Harvest

Language English

Advisor Astrahan, Melvin (committee member), Kuo, C.-C. Jay (committee member), Ortega, Antonio (committee member)

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c16-314982

Unique identifier UC11336795

Identifier 1421769.pdf (filename),usctheses-c16-314982 (legacy record id)

Legacy Identifier 1421769.pdf

Dmrecord 314982

Document Type Thesis

Rights Goel, Garima

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the au...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus, Los Angeles, California 90089, USA