Download D_UCY_WP4_41_c2, Specification on E2E UMTS simulator

34900
Deliverable D4.1
Specification of Simulation Environment
Project Number:
SEACORN
IST-2001-34900
Project Title:
SEACORN
CEC Deliverable Number:
34900/UCY/DS/041/c1
Contractual Date of Delivery to CEC:
August 2002
Actual Date of Delivery to CEC:
October 2002
Title of Deliverable:
Specification of Simulation Environment
WP contributing to the Deliverable:
WP4
Nature of the Deliverable:
R
Deliverable Security Class:
Editors:
CO
Josephina Antoniou, Chrysostomos Chrysostomou and
Nestor Jacovides
Abstract:
This deliverable describes the specifications of the simulation environment selected for the system level simulations of the SEACORN project. A primary objective of this project is to evaluate
the performance of the Enhanced UMTS network at the system level. Specification of the simulation environment is important in order to achieve the project goals of accuracy, public acceptance, and reusability of the simulation models.
Three candidate simulation environments are considered, Optimal Network Simulator (OPNET),
Objective Modular Network Testbed in C++ (OMNeT++), and Network Simulator version 2 (NS2). NS-2 is selected as the most suitable simulation environment for the system level simulations of the SEACORN project. This selection is justified by considering the simulator’s structure, components, ease of modification, and support for parallelization. Developments in
OPNET and OMNeT++ will also be closely monitored.
Keywords:
Enhanced UMTS, System Level Simulations, Simulation Environment, Parallelization
Simulation of Enhanced UMTS Access and Core Networks
Page i
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
Executive Summary
One of SEACORN’s main objectives is to develop a high performance simulator for dynamic
system level simulation and characterisation of Enhanced UMTS access and core networks.
This simulator will enable the evaluation of capacity gain, Radio Resource Management (RRM)
mechanisms, Quality of Service (QoS) provisioning, and other parameters associated with the
performance of Enhanced UMTS networks. Workpackage 4 (WP4) is responsible for the system
level simulations. The simulation environment for the system level simulations of an Enhanced
UMTS network is addressed in this deliverable and its specifications are elaborated.
WP4 will provide system level simulations using existing simulation tools. The simulations will
be based on fast and accurate simulation methods for multi-user and multi-rate traffic. To
achieve reliable and significant results, WP4 needs to develop a powerful, parallel simulation
environment that enables Enhanced UMTS network performance evaluation with the necessary
level of system detail. The duration of the simulations needs to be maintained within acceptable
time limits in order to obtain tractable results. The software environment that will support these
simulations needs to satisfy the above requirements, with criteria such as: granularity in models,
protocol model richness, dynamic definition of network topology, user-friendly programming
model, debugging and tracing support, widely accepted efficient performance, source availability, support for mobility of nodes, ability to run large simulations, and support for parallel execution.
This deliverable introduces candidate simulation environments that can be used to satisfy the
requirements of WP4. It reviews existing simulation tools focussing on the three most promising:
NS-2, OPNET, and OMNeT++. NS-2 is selected by WP4 as the system level simulation environment.
Justification for using NS-2 to develop the simulation model is given by considering the criteria
mentioned above, in conjunction with certain simulator characteristics required such as: the
technical structure of the simulation environment, the DiffServ module, the error model, agents,
mobility and wireless support, tracing and debugging support, radio propagation models, routing
mechanisms, transport and application models, support for parallelization, open source, and
support of the large user community. A short discussion is also presented on the inputs and
outputs of the simulator; a basic set of system level simulator assumptions is given to allow
comparison, as well as the need for validation.
Simulation of Enhanced UMTS Access and Core Networks
Page ii
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
List of Contributors
Name
Company
Address
Phone/Fax/E-mail
Josephina Antoniou
University of Cyprus
+357 22 892230/31
+357 22 339062
[email protected]
Chrysostomos Chrysostomou
University of Cyprus
Andreas Pitsillides
University of Cyprus
Nestor Jacovides
University of Cyprus
Stavros Tsiakkouris
University of Cyprus
75 Kallipoleos Av.,
P.O. Box 20537,
CY-1678,
Nicosia,
Cyprus.
75 Kallipoleos Av.,
P.O. Box 20537,
CY-1678,
Nicosia,
Cyprus.
75 Kallipoleos Av.,
P.O. Box 20537,
CY-1678,
Nicosia,
Cyprus.
75 Kallipoleos Av.,
P.O. Box 20537,
CY-1678,
Nicosia,
Cyprus.
75 Kallipoleos Av.,
P.O. Box 20537,
CY-1678,
Nicosia,
Cyprus.
Simulation of Enhanced UMTS Access and Core Networks
+357 22 892230/31
+357 22 339062
[email protected]
+357 22 892230/31
+357 22 339062
[email protected]
+357 22 892230/31
+357 22 339062
[email protected]
+357 22 892230/31
+357 22 339062
[email protected]
Page iii
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
Table of Contents
EXECUTIVE SUMMARY.............................................................................................................................. II
LIST OF CONTRIBUTORS ......................................................................................................................... III
TABLE OF CONTENTS .............................................................................................................................. IV
LIST OF FIGURES ...................................................................................................................................... VI
LIST OF TABLES ....................................................................................................................................... VI
LIST OF ACRONYMS ................................................................................................................................ VII
1.
INTRODUCTION ................................................................................................................................... 1
2.
GOALS FOR THE ENHANCED UMTS SYSTEM LEVEL SIMULATIONS ......................................... 2
3.
CRITERIA FOR CHOOSING THE SIMULATION ENVIRONMENT .................................................... 2
4.
SELECTION OF SYSTEM LEVEL SIMULATOR ................................................................................. 3
5.
NS-2 – AN OVERVIEW......................................................................................................................... 6
5.1
HISTORY OF NS-2 ............................................................................................................................ 6
5.2
COMPONENTS OF NS-2 .................................................................................................................... 6
5.2.1
Analysis ................................................................................................................................... 7
5.2.2
Network Animator, nam .......................................................................................................... 7
6.
FEATURES OF THE SIMULATION ENVIRONMENT ......................................................................... 8
6.1
A TECHNICAL VIEW OF THE SIMULATOR STRUCTURE .......................................................................... 8
6.2
SIMULATOR INITIALISATION.............................................................................................................. 10
6.3
LINK OBJECTS ................................................................................................................................ 10
6.4
DIFFERENTIATED SERVICES (DIFFSERV) MODULE ............................................................................ 10
6.5
CONSIDERING INTEGRATED SERVICES (INTSERV) ............................................................................ 11
6.6
AGENTS ......................................................................................................................................... 11
6.7
ERROR MODEL ............................................................................................................................... 11
6.8
NS-2 W IRELESS AND MOBILITY SUPPORT ....................................................................................... 12
6.8.1
The Basic Wireless Model in NS-2 ....................................................................................... 12
6.8.2
Network Components in a Mobile Node ............................................................................... 12
6.8.3
Wireless Tracing ................................................................................................................... 13
6.8.4
Mobile IP ............................................................................................................................... 13
6.8.5
Mobile IPv6 ........................................................................................................................... 13
6.9
RADIO PROPAGATION MODELS ....................................................................................................... 13
6.10 ROUTING ....................................................................................................................................... 14
6.11 TRANSPORT PROTOCOLS AND APPLICATIONS .................................................................................. 14
6.12 PARALLEL DISTRIBUTED NS (PDNS) .............................................................................................. 15
6.12.1 Parallelization........................................................................................................................ 15
6.12.2 Parallelized Network Simulation ........................................................................................... 15
6.13 MODIFICATIONS OF EXISTING NS-2 SOFTWARE ................................................................................ 16
6.13.1 Ease of Software Modifications ............................................................................................ 16
6.13.2 Conceptual Need for Software Modification ......................................................................... 16
6.14 SUPPORT ....................................................................................................................................... 16
7.
SYSTEM SIMULATOR ASSUMPTIONS............................................................................................ 18
8.
SIMULATOR REQUIREMENTS ......................................................................................................... 17
Simulation of Enhanced UMTS Access and Core Networks
Page iv
34900
8.1
9.
Deliverable D4.1
Specification of Simulation Environment
SEACORN
SIMULATOR INPUTS AND OUTPUTS .................................................................................................. 17
VALIDATION ...................................................................................................................................... 20
10. CONCLUSION .................................................................................................................................... 21
11. BIBLIOGRAPHY ................................................................................................................................. 21
Simulation of Enhanced UMTS Access and Core Networks
Page v
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
List of Figures
Figure 5-1: NS-2 components from [2]. ........................................................................................................ 7
Figure 5-2: An example plot by nam from [3]. .............................................................................................. 8
Figure 6-1: The directory structure in NS-2 from [2]. .................................................................................... 9
Figure 6-2: The TclObject class structure from [2]. ...................................................................................... 9
List of Tables
Table 4-1: Comparison of NS-2, OPNET and OMNeT++ ............................................................................ 5
Table 6-1: The main classes found in the “tclcl” directory of NS-2............................................................... 9
Table 6-2: Components of a mobile node in NS-2. .................................................................................... 12
Table 7-1: System Level Simulation assumptions. .................................................................................... 20
Simulation of Enhanced UMTS Access and Core Networks
Page vi
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
List of Acronyms
AC
AODV
ARP
BS
CDMA
CN
CPICH
DARPA
DES
DiffServ
DSDV
DSR
DSSS
FTP
GUI
HSDPA
HTTP
IDCC
IEEE
IntServ
IP
LOS
MAC
MPI
NAM
NLOS
NS-2
NSF
OMNeT++
OPNET
PADS
PC
PDNS
PLM
PS
PSM
PVM
QoS
RAN
RED
RIO
RMD
RRM
RTIKIT
SEACORN
SIR
SPF
SRM
TCP
TDMA
TORA
Admission Control
Ad-Hoc on Demand Distance Vector
Address Resolution Protocol
Base Station
Code Division Multiple Access
Core Network
Common Pilot Channel
Defence Advanced Research Projects Agency
Discrete Event based Simulator
Differentiated Services
Destination-Sequenced Distance Vectoring
Dynamic Source Routing
Direct Sequence Spread Spectrum
File Transfer Protocol
Graphical User Interface
High Speed Downlink Packet Access
Hyper Text Transfer Protocol
Integrated Dynamic Congestion Controller
Institute of Electrical and Electronics Engineers
Integrated Services
Internet Protocol
Line-of-Sight
Medium Access Control
Message Passing Interface
Network AniMator
No Line of Sight
Network Simulator version 2
National Science Foundation
Objective Modular Network Testbed in C++
OPtimal NETwork Simulator
Parallel and Distributed Simulation
Power Control
Parallel Distributed Network Simulator
Packet Pair Receiver-Driven Layered Multicast
Packet Scheduling
Parallel Simulation Model
Parallel Virtual Machine
Quality of Service
Radio Access Network
Random Early Detection
RED with In and Out
Radio Management in DiffServ
Radio Resource Management
Run-Time Infrastructures KIT
Simulation of Enhanced UMTS Access and Core Networks
Signal to Interference Ratio
Shortest Path First
Scalable Reliable Multicast
Transmission Control Protocol
Time Division Multiple Access
Temporally-Ordered Routing Algorithm
Simulation of Enhanced UMTS Access and Core Networks
Page vii
34900
UDP
UE
UMTS
UTRAN
VINT
W-CDMA
WLAN
WPx
Deliverable D4.1
Specification of Simulation Environment
SEACORN
User Datagram Protocol
User Equipment
Universal Mobile Telecommunications System
UMTS Terrestrial Radio Access Network
Virtual InterNetwork Testbed
Wideband Code Division Multiple Access
Wireless Local Area Network
Workpackage x
Simulation of Enhanced UMTS Access and Core Networks
Page viii
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
1. Introduction
SEACORN investigates additions and modifications to the UMTS network that satisfy the need
for a capacity increase in the access network, flexibility in the core network, and supplementary
integrated services that the standardized UMTS network is not able to provide.
One of the main issues that SEACORN deals with is to achieve a real-time1 dynamic simulation
environment that enables the evaluation of the capacity gain, RRM mechanisms, QoS provisioning, and other parameters associated with the performance of Enhanced UMTS networks.
This issue is addressed in WP4 by performing system level simulations in which the behaviour
of an overall end-to-end network is captured. This includes the dynamic user behaviour (e.g.,
mobility and variable traffic demands), the radio interface, the radio access network, and the
core network at appropriate levels of abstractness.
More specifically, the objectives of WP4 are to integrate the simulation results from WP2 and
WP3 as a comprehensive study of the various parameters affecting the integrated planning process of a UMTS network. Several reference scenarios will be developed providing all necessary
inputs from the independent simulation activities of WP2 and WP3. The results obtained will be
integrated to give a global view of the process. To allow realistic simulation scenarios to be assessed, the simulator should be designed to run parallel on supercomputers and workstation
clusters.
The simulation environment for the system level simulations will be NS-2, a non-commercial,
publicly available, open source, object-oriented simulator written in C++ with an OTcl interpreter
as a front-end. Other simulators considered are OPNET and OMNeT++, which have certain
competing features and will be closely monitored.
In selecting a suitable simulation environment, we have to keep in mind the need for software
modification and expandability since the idea of an Enhanced UMTS network is not yet finalised
as a concept or standardised as a network structure. An open source simulation environment
that can be easily modified, such as NS-2, is desired as it can support the development of additional models that are necessary to realize a simulator for an Enhanced UMTS network.
This deliverable specifies the simulation environment at the system level. The data format and
interface with the link level and network and transport level simulators are described in the
companion deliverable, D4.2.
1
Network simulators are commonly event-driven, tracking time down to the packet level.
Simulation of Enhanced UMTS Access and Core Networks
Page 1
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
2. Goals for the Enhanced UMTS System Level Simulations
WP4 aims at creating a system level simulation environment of an Enhanced UMTS Network.
The simulator developed should satisfy certain criteria and achieve specific goals as outlined in
Annex 1 - “Description of Work” [1]. In particular, the simulator should:
 Include the effects of mobility into the performance evaluation.
 Allow comparison of different simulation approaches and analytical simplifications for
UMTS traffic simulations.
 Provide new, fast, and accurate simulation methods for multi-user and multi-rate traffic
that are applicable in highly advanced network simulation tools.
 Enable Enhanced UMTS network performance evaluation with a necessary level of system detail. This needs to be achieved at acceptable simulation times and the results obtained must be reliable.
Each of these goals imposes some initial requirements on the simulation environment that will
host the Enhanced UMTS system level simulations. The simulation environment needs to allow
for code adjustments and additions. Consequently, it either needs to be open source or have
the source easily available to developers. Furthermore, the simulation environment has to support: (i) several traffic models, (ii) mobility of nodes, (iii) analysis methods, and (iv) parallelization
as a core set of features. The goals of the simulation are a starting point in setting the criteria for
the simulation environment selection.
3. Criteria for Choosing the Simulation Environment
The search for the right simulation environment has followed some basic guidelines as there are
many “state-of-the-art” simulation environments2 available, both publicly and commercially.
Some of the major commercially available network simulators are:
 OPNET
 QualNet
 COMNET III
Some of the major non-commercially, publicly available network simulators are:
 NS-2
 OMNeT++
 TANGRAM II
 Parsec
 SMURPH
 Ptolemy
2
The development of a custom made simulator was dismissed as impractical due to the short project timescales, the complexity
and associated high cost, the high risk factor, the need for validation, acceptance by the networking community, and the availability
of suitable “off-the-shelf” simulation environments.
Simulation of Enhanced UMTS Access and Core Networks
Page 2
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
Criteria and guidelines followed for the selection of the simulation environment include the ability of the simulator to provide: granularity in models, protocol model richness, dynamic definition
of network topology, user-friendly programming model, debugging and tracing support, widely
accepted efficient performance, source availability, support for mobility of nodes, ability to run
large simulations, and support for parallel execution. The simulator itself has to be user-friendly,
must provide a hierarchical architecture to ensure flexibility, and should have a large and active
user community. Based on these criteria, three simulators were identified and are discussed
next.
4. Selection of System Level Simulator
The selection of the system level simulator takes into account a few of the characteristics of the
simulators such as: their support for mobile networking, the programming model of each environment, the ability of the environment to run large networks, and their support for parallel execution. Table 4-1 presents a comparison of the three simulators considered for selected criteria
identified.
Criteria
Mobile Networking
NS-2
OPNET
OMNeT++
Link Layer, MAC, network interface, radio
propagation models,
antennas (ARP, IEEE
802.11, Preamblebased TDMA, DSSS
radio interface, Free
space, Two Ray Ground
Reflection and Shadowing radio propagation
models, energy model,
omni-directional antenna)
Link Layer, MAC, network interface, radio
propagation models,
antennas (IEEE
802.11- WLAN, IEEE
802.15, Bluetooth, IEEE
802.16 Broadband
Wireless Access for
MAC protocol development)
Link Layer, MAC, network interface, radio
propagation models,
antennas (currently
under development)
Ad-hoc routing protocols (DSDV, DSR,
TORA, AODV)
Simulation of Enhanced UMTS Access and Core Networks
Page 3
34900
Programming
Model
Deliverable D4.1
Specification of Simulation Environment
Object-oriented, eventdriven simulator, written
in C++, with an OTcl
interpreter as a frontend.
C++ is fast to run but
slower to change, making it suitable for detailed protocol implementation.
OTcl runs much slower
but can be changed
very quickly (and interactively), making it ideal
for simulation configuration.
Object-oriented modelling approach, offers a
development environment that includes powerful graphical editors
with full access to
source code in standard
C (Proto-C).
OPNET's run time
scales linearly with the
number of events.
Platforms supported:
Windows 2000/NT/XP,
UNIX (Solaris, HP-UX)
Platforms supported:
Several UNIX flavours
(FreeBSD, Linux,
SunOS, Solaris), Windows 95/98 /2000
/NT/XP
SEACORN
OMNeT++ is a discrete
event simulation tool. It
is primarily designed to
simulate computer networks, multi-processors
and other distributed
systems, but it may be
useful for modeling other systems too. It is
unique in the fact that it
supports both
thread/coroutine-based
programming and finite
state machines.
Platforms supported:
OMNeT++ has been
developed on Linux, but
it works just as well on
most UNIX systems and
on Win32 platforms
(Windows 2000/NT/XP
recommended)
Model Hierarchy Levels
NS-2 does not offer a
simulation model structure abstracting behaviour at network, node
and process level (as
some other simulators
can)
The simulation model is
hierarchically structured
in three distinct levels –
network level (subnetwork nesting possible),
node level (no nesting),
and process level (no
nesting)
OMNeT++ models may
consist of hierarchically
nested modules. The
logical structure of the
system modelled can
replicate the actual system since the depth of
module nesting does
not have limits
Simulation
modes
Discrete simulation
mode
Discrete, Analytic, and
Hybrid simulation
modes.
Discrete simulation
mode
Documentation
Poor: Recent model
additions to simulator
are not well documented. Incomplete, unstructured, often untrustworthy documentation of
contributed models.
Satisfactory documentation of core functionality
Large user community,
open source code.
There is a high possibility that a large population of users will validate the simulation
models developed.
Supports memory, Tcl,
C++, and mixed
Tcl/C++ debugging and
off-line animation.
Very good: extensive
documentation, model
usage guides, methodology case-studies etc.
Good: detailed user
manual. Not many contributed models are currently available in order
to be able to comment
on the quality of the
documentation of such
models.
Large user community,
open source code for
protocol models (not for
simulation kernel).
Supports command-line
debugging and off-line
animation.
Small user community
to validate models.
Debugging achieved by
linking the Graphical
User Interface (GUI)
library with the debugging and tracing capability into the simulation
executable.
Validation, Debugging and
Tracing
Simulation of Enhanced UMTS Access and Core Networks
Page 4
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
Ability to run
large networks
Main constraints:
memory and CPU time.
OPNET’s hierarchical
approach simplifies the
specification and representation of large and
complex systems.
OMNeT++, due to its
hierarchical structure,
can simulate very largescale networks. The
limit is the virtual
memory capacity of the
computer system used.
Parallel Execution
PDNS (Parallel/Distributed NS)
The PADS research
group at Georgia Tech
has developed extensions and enhancements to the NS-2 simulator to allow a network
simulation to be run in a
parallel and distributed
fashion, on a network of
workstations.
Tested on 32 systems,
with a 32000-node network topology (simulating 1000 nodes on each
of the 32 systems).
The new Parallel Simulation Model (PSM) that
was recently added to
OPNET provides easy
parallelization and is
fully documented in the
OPNET model usage
guides.
Parallel Virtual Machine
(PVM) based simulation
supported. Message
Passing Interface (MPI)
based parallel simulation modules are nearing completion.
Table 4-1: Comparison of NS-2, OPNET and OMNeT++
NS-2 is mainly considered against the commercially available OPNET and the publicly available
OMNeT++ network simulators. OPNET and NS-2 are considered to be the most likely choices
since competence with OMNeT++ is limited among SEACORN partners.
NS-2 is publicly available whereas OPNET is commercially available on a yearly renewable contract basis. Recently, OPNET has introduced the UMTS model which will be closely monitored
for its acceptance by the research community. As a public domain simulator, NS-2 has a large
user community and is widely recognized and accepted as an efficient and accurate network
simulation tool. There is a high possibility that a large population of users will validate the simulation models developed as part of SEACORN since it is common practice to publish simulation
scripts. OMNeT++ is a discrete event simulation tool primarily designed to simulate computer
networks, multiprocessors, and other distributed systems, with limited user community at present.
One of the main objectives of NS-2 is to provide a collaborative network simulation environment. It is freely distributed and open source, hence, allowing the sharing of code, protocols,
and models. This accommodates the comparison and evaluation of competing protocols and
models that are under consideration. Collaboration among NS-2 users results in an increased
confidence in the simulation results obtained since more people investigate and analyse the
simulation models developed.
NS-2 is an object-oriented simulator written in C++ with an OTcl interpreter as a front-end. The
reason for using two programming languages is flexibility. Detailed simulations of protocols require a system programming language which can efficiently manipulate bytes and packet headers, and implement algorithms that run over large data sets. C++ is fast to run but slower to
change. Therefore, it is suitable for detailed protocol implementation. A large part of network
research involves fine-tuning certain parameters and configurations and quickly exploring different scenarios of interest. In this case, OTcl is used as it can be changed very quickly and interactively. The tradeoff for this convenience is longer simulation times.
Simulation of Enhanced UMTS Access and Core Networks
Page 5
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
Inside the SEACORN consortium, NS-2 is already used extensively as the simulation tool for
WP3. Furthermore, other working groups have advanced knowledge in the use of NS-2. Consequently, there exists more expertise in NS-2 compared to OPNET and OMNeT++. Based on
these grounds, and after evaluating the comparative advantages of the network simulation tools
currently available, NS-2 has been chosen as the most appropriate system level simulation environment for the SEACORN project. OPNET and OMNeT++ have certain competing features
and will be closely monitored.
5. NS-2 – An Overview
NS-2 is an event driven simulator, where the event is selected as the packet. Currently, the
simulator is single-threaded and only one event can be executed at a given time. The scheduler
runs by selecting the next earliest event, executing it to completion, and returning to execute the
next event.
5.1 History of NS-2
The Network Simulator started as a variant of the REAL network simulator in 1989. Major US
organizations support the development of the Network Simulator including DARPA and NSF.
The Network Simulator was enhanced by the VINT project from DARPA in 1995, resulting in the
development of the Network Simulator version 2 (NS-2). Currently, NS-2 is maintained at
USC/ISI and updated information about NS-2 can be found at its main website
http://www.isi.edu/nsnam/ns/.
Being a result of non-centralised collaborative work, documentation for NS-2 is, unfortunately,
neither complete nor totally structured. This makes it difficult for a new user to gain competency
on it. However, there is a large community of NS-2 users sharing information and complementing one another’s knowledge.
The “ns Manual”, formerly known as “ns Notes and Documentation,” provides reference documentation for NS-2.
5.2 Components of NS-2
NS-2 is made up of several components which help to obtain a more complete simulation in
terms of programming flexibility, visualisation, and understanding.
The primary component is ns, the actual simulator. This provides the software backup for programming network models. The programming environment provides an interactive mode because the front-end OTcl interpreter allows for the direct programming of the simulator. It is also
possible, and often times more efficient, to simply use a text editor to write the scripts and run
them from a terminal’s command line.
The second component is the network animator or nam. This is a simple animator with twodimensional (2D) graphics that help the user visualize and monitor the simulation both as a
whole, and as individual components. The GUI only requires the trace files (created from the
simulation scripts) as input.
Pre-Processing and Post-Processing are also important components of NS-2. Examples of PreProcessing are traffic and topology generators3. An example of Post-Processing is simple trace
analysis, i.e., xgraph, often developed using scripting languages such as awk, Perl and Tcl.
The diagram in Figure 5-1 can better illustrate the structure of NS-2.
3
The topology generators currently discussed in literature have limitations, as they do not support the generation of large “realistic”
network topologies. We will monitor further research in this area.
Simulation of Enhanced UMTS Access and Core Networks
Page 6
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
Figure 5-1: NS-2 components from [2].
To initiate the simulator an Otcl script is written. When the script is executed, it is interpreted by
an OTcl interpreter that runs as a front-end of the simulator. While the script is being interpreted, it is linked to the appropriate objects and classes from the NS-2 simulator library. The linking
is done with both OTcl and C++ source code. When the interpreter invokes a C++ method, it
expects the result to be sent back to a specific private variable before it recognizes the C++
method as valid.
In this manner the basic translation of the script is achieved and the simulation can execute.
Tracing during the simulation can capture the simulation results in two different ways. If the purpose of tracing is the visualization of the script, then there is an option of tracing for the network
animator (nam). However, if the purpose is to perform analysis of the behaviour described by
the script, then a different command captures the appropriate measures in a file and also provides the option of generating a comparison graph.
5.2.1
Analysis
There are a number of ways of collecting output or trace data in a simulation in order to obtain
meaningful performance metrics from a simulation. Usually, trace data is collected and stored in
a file so that it can be post-processed and analysed.
There are two types of monitoring capabilities currently supported by NS-2. The first one is
called “traces” and it records each individual packet as it arrives, departs, or is dropped at a particular link or queue. Trace objects are configured in a simulation as nodes in the network topology.
NS-2 objects called “monitors” provide the second type of monitoring capability. These “monitors” record counts of various metrics of interest such as: packet and byte arrivals, departures
and packet failures. Monitors can record counts associated with each packet, or on an aggregated per-flow basis using a flow monitor. “Monitors” are supported by a separate set of objects
that are created and inserted into the network topology around queues.
The user has the option of modifying the trace file format but the default format provided by NS2 is backward compatible with the output files in NS-1 so that NS-1 post-processing scripts can
still be used.
5.2.2
Network Animator, nam
nam is an animation tool for viewing network simulation traces and real world packet trace data.
nam was designed to read simple animation event commands from a potentially large trace file.
Large animation data sets are handled by keeping a minimum amount of that information in
memory. The commands are kept in a file and re-read whenever necessary.
Simulation of Enhanced UMTS Access and Core Networks
Page 7
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
To use nam, the trace file with the appropriate format needs to be produced. This can be done
during the simulation by adding the appropriate “namtrace” command to the simulation script.
When the trace file is generated, it is in a format that can be readily used by nam. When the
simulation is executed, nam first reads the trace file and plots the appropriate topology. Then it
stops and waits for the user to invoke the graphical user interface to start the animation. The
graphical user interface allows for multiple animations to be running under the same nam instance. Generating external animations from nam is also possible. Animations can be saved
and converted to animated gifs or mpeg movies.
nam is object-oriented in structure similar to the rest of NS-2, and it performs the animations
with abstract objects as its building blocks. The objects used in nam are classes that represent
nodes, links, queues, data packets and agents.
Figure 5-2 presents a picture of a simple plot by nam to illustrate the 2D graphics generated. It
represents a simple four-node topology and packets flow from the two left-oriented nodes
through the middle node, to the right-oriented node. The vertical bar represents the queue
length. Note that the issue of scalability to large networks precludes its use for overall system
wide simulations. However, specific aspects of the system behaviour can be visualised to aid in
the understanding of newly proposed protocols and algorithms.
Figure 5-2: An example plot by nam from [3].
6. Features of the Simulation Environment
This section highlights selected features of the NS-2 simulator, relevant to the SEACORN project.
6.1 A Technical View of the Simulator Structure
NS-2 is an object-oriented tool. Consequently, it encapsulates concepts within independent objects linked together within a system hierarchy. As already mentioned, NS-2 is written in C++
with an OTcl interpreter as a front-end. This fact reflects closely on the structure of the simulator.
NS-2 supports a class hierarchy in C++ for the C++ code, and simultaneously a similar class
hierarchy within the OTcl interpreter for obvious reasons. Naturally, the two class hierarchies
are closely linked together, and actually from the user’s point of view there is a one-to-one correspondence between a class in the C++ hierarchy and a class within the OTcl interpreter hierarchy. A generalised visualization of the directory structure of NS-2 can be seen in Figure 6-1.
Simulation of Enhanced UMTS Access and Core Networks
Page 8
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
Figure 6-1: The directory structure in NS-2 from [2].
The code that interfaces with the OTcl interpreter resides in the “tclcl” directory. The rest of the
code is found in the “ns-2” directory.
The main classes found in the “tclcl” directory can be seen in Table 6-1. The hierarchical structure of one of these classes and its components can be seen in Figure 6-2. The tree structure
shown closely reflects the hierarchy policy of the software. It also shows the position of the “Ns”
Simulator object in the overall structure as well as part of its “descendant” tree.
Class Name
Tcl
TclObject
TclClass
TclCommand
EmbeddedTcl
InstVar
Class Description
Contains the methods that C++ code will use to access the interpreter
This is the base class for all simulator objects that are also mirrored in the C++ hierarchy
Defines the interpreted class hierarchy (OTcl class) and the methods to permit the user
to instantiate TclObjects
This is used to define simple global interpreter commands
Contains the methods to load higher-level built-in commands that make configuring simulations easier
Contains methods to access C++ member variables as OTcl instance variables
Table 6-1: The main classes found in the “tclcl” directory of NS-2.
Figure 6-2: The TclObject class structure from [2].
Simulation of Enhanced UMTS Access and Core Networks
Page 9
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
The object-oriented approach of NS-2 and the hierarchical structure of its classes, e.g. see Figure 6-2, allows additions and modifications to NS-2. For example different network architectures, such as Radio Management in DiffServ (RMD), and protocols, such as Integrated Dynamic Congestion Controller (IDCC), can be incorporated into the simulation model.
6.2 Simulator Initialisation
The class Simulator is a Tcl class. It provides a set of interfaces for configuring a simulation and
for choosing the type of event scheduler used to drive the simulation.
A simulation script usually begins by creating an instance of the class Simulator. Nodes, links
and topologies are subsequently created by calling various methods. The creation of a new
simulation object requires the following operations to be performed by the initialisation procedure:
 Initialise packet format.
 Create a scheduler.
 Create a “null” agent.
The packet format initialisation sets up field offsets within packets used in the entire simulation.
The scheduler runs the simulation in an event-driven manner and may be replaced by alternative schedulers which provide somewhat different semantics.
6.3 Link Objects
NS-2 provides the users with several link models in the form of abstract objects. More specifically, in NS-2 a link actually consists of the combination of an output queue and the model of the
actual communication link. Both, dynamic and non-dynamic links can be created. Dynamic links
encapsulate the possibility of link failure. Examples of different types of links are:
 FQLink (Fair Queuing).
 CBQLink (Class Based Queuing).
 IntServLink (IntServ).
The following example uses the “IntServLink” link:
$ns duplex-intserv-link <n1> <n2> <bw> <delay> <sched> <signal> <adc>
This creates a duplex link between nodes “n1” and “n2,” with specified bandwidth and delay.
This type of queue implements a scheduler with a two-level service priority. The type of IntServ
queue is given by <sched> with admission control unit type of <adc> and signal module of type
<signal>. The link objects are an example of the simplicity offered by the NS-2 models without having to compromise their rich functionality. Additionally, one can modify or create new
models of the link objects, as for example for a particular radio interface.
6.4 Differentiated Services (DiffServ) Module
DiffServ is an IP QoS architecture based on packet marking that allows packets to be prioritised
according to user requirements. It is expected to offer aggregate QoS (‘soft’ QoS guarantees) to
differentiated service classes.
The DiffServ module in NS-2 has three major components.
Simulation of Enhanced UMTS Access and Core Networks
Page 10
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
 Policy, which is specified by network administrator about the level of service a class of
traffic should receive in the network.
 Edge router, which marks packets with a code point according to the policy specified.
 Core router, which examines the code point marking of the packets and forwards them
accordingly.
The DiffServ module attempts to restrict complexity to the edge routers only. It supports four
classes of traffic, each of which has three options of dropping precedence, allowing for different
treatment of traffic within a single class. To achieve the differentiation of services, several strategies may be adopted. For example, during periods of congestion, low priority packets can be
discarded more often than high priority packets, in accordance with a given strategy (e.g., Random Early Detection (RED), RED with In and Out (RIO), Fuzzy-RED, etc).
NS-2 implements a strategy in which packets in a specific class are enqueued into a RED
queue, which in turn contains three virtual queues, one for each drop precedence. Different
RED parameters can be configured for different virtual queues, causing packets from one virtual
queue to be dropped more frequently than packets from another virtual queue. A packet with
lower dropping precedence is given better treatment in times of congestion because it is assigned a code point that corresponds to a virtual queue with relatively lenient RED parameters.
Several models and simulation scenarios of RED variants were contributed to NS-2.
Recently, architectural modifications to DiffServ were also proposed, such as RMD, to provide
“better” QoS support.
Note that a detailed study of the network architectures and protocols for SEACORN is examined
in WP3 and made available to WP4.
6.5 Considering Integrated Services (IntServ)
IntServ is supported through procedures that provide attributes to the queue elements of the
links. An example of such command was presented in Section 6.3, Link Objects.
In contrast to DiffServ that is supported by NS-2 as an independent module, IntServ is only
supported as part of several independent contributions, extensions, and attributes to other objects.
6.6 Agents
Agents represent endpoints where network layer packets are constructed or consumed and are
used in the implementation of protocols at various layers. The “Agent” class is partly implemented in C++ and partly implemented in OTcl.
The C++ class includes enough internal state to assign various fields to a simulated packet before it is sent. This state includes several variables such as self-address, destination node, and
packet size. Any class derived from the “Agent" class may modify these variables. The class
also supports packet generation and reception.
NS-2 supports the creation and manipulation of agents by using already existing agent models
or developing new ones using OTcl. Furthermore, simulated applications may be implemented
on top of protocol agents.
6.7 Error Model
The error model of NS-2 simulates link-level errors or loss by one of two ways.
 Marking the packet’s error flag.
Simulation of Enhanced UMTS Access and Core Networks
Page 11
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
 Using more complicated statistical and empirical models.
The unit of error may be specified in different ways, i.e., in terms of packets, in terms of bits, or
in terms of time, in an effort to allow for support of a wide variety of models.
The different error models can be configured to be used over both wired and wireless networks.
One of the latest additions to NS-2 is the multi-state error model contributed by Jianping Pan.
This specific model implements time-based error state transitions.
6.8 NS-2 Wireless and Mobility Support
Currently, a UMTS or Enhanced UMTS model does not exist in NS-2. However, several contributed models addressing wireless and mobility issues exist. These may be usefully employed by
the WP4 system level simulator.
6.8.1
The Basic Wireless Model in NS-2
The implementation of the mobile node is central to the concept of a wireless model. The basic
model consists of a mobile node at the core with several additional features such as the ability
of the mobile node to move within a given topology and the ability of the user to create a wireless topology. The wireless model is implemented as a split object in NS-2 since it is derived
from the main node class.
The user who wants to create a wireless network has to first define the mobile node structure or
configuration. Creating node movements is a bit more complicated. Even though the node is
designed such that it can move in a three-dimensional (3D) structure, it is assumed to always
move in two dimensions.
6.8.2
Network Components in a Mobile Node
The Network stack for a mobile node consists of a link layer, an Address Resolution Protocol
(ARP) module connected to the link layer, an interface priority queue, a Medium Access Control
(MAC) layer, and a network interface, all connected to the channel. These network components
are created and integrated in OTcl. Each of the components is briefly described in Table 6-2.
Component
Link Layer
ARP
Interface Queue
MAC Layer
Tap Agents
Network Interfaces
Radio Propagation
Model
Antenna
Description
The link layer for mobile nodes has an ARP module connected to it, which resolves
all IP to hardware (MAC) address conversions
The ARP module receives queries from the link layer about IP to Ethernet address
resolutions
This is implemented as a priority queue, which gives priority to routing protocol
packets, inserting them at the head of the queue
The standard-based implementation uses both physical and virtual carrier sense
If the particular MAC protocol permits it, the tap will haphazardly be given all packets received by the MAC layer before address filtering is done
The network interface layer serves as a hardware interface, which is used by mobile nodes to access the channel
It uses Friss-space attenuation model at near distances and an approximation to
Two-Ray Ground reflection model at far distances
Mobile nodes use an omni-directional antenna having unity gain
Table 6-2: Components of a mobile node in NS-2.
Simulation of Enhanced UMTS Access and Core Networks
Page 12
34900
6.8.3
Deliverable D4.1
Specification of Simulation Environment
SEACORN
Wireless Tracing
In an effort to merge wireless tracing with the NS-2 tracing, the format of the trace file has been
modified. The new trace format is backwards compatible with the old trace format and includes
the following fields:
 Event type. This field describes the type of event taking place at the node and can be one
of four types (send, receive, drop, forward).
 General tag. This field may stand for time or it may be a global setting.
 Node Property Tag. This field denotes the node properties like node-id, the level at which
tracing is being done like agent, router, or MAC.
 Packet Information at IP level. Tags at this level include, source address, source port
number, destination address, destination port number, packet type, packet size, flow id
etc.
 Next hop info. This field provides next hop information.
 Packet info at MAC level. This field gives information about the Mac layer such as duration, Ethernet type etc.
 Packet info at “Application level.” This field presents the packet information at the application level.
6.8.4
Mobile IP
Mobile IP has recently been implemented and integrated in the NS-2 mobile Networking components, by Sun Microsystems.
The “MobileIP” model consists of home agents and foreign agents, and has mobile hosts moving between their home and foreign agents. These home and foreign agents are, essentially,
base-station nodes. The mobile hosts can be treated as the mobile nodes that have been previously described within this document.
6.8.5
Mobile IPv6
The Mobile IPv6 protocol aims to advertise the current location in the topology to all its correspondent nodes.
Mobile IPv6 processing is implemented as a set of new NS-2 agents and a set of existing NS-2
classifiers. Nodes that need Mobile IPv6 capabilities also comprise separate objects for encapsulation, decapsulation, routing header processing, etc. This requires changes to the way NS-2
nodes are configured.
This is different from the “MobileIP” model mentioned earlier. Mobile IP capabilities can be easily attached on a node object by simply turning on the Mobile IP flag. This flag is an attribute of
every mobile node.
6.9 Radio Propagation Models
The radio propagation models are used to predict the received signal power of each packet. At
the physical layer of each wireless node, there is a receiving threshold. When a packet is received its signal power is compared to a specified threshold. If the signal power is below the receiving threshold, it is marked as error and dropped by the MAC Layer.
There are three propagation models in NS-2: the free space model, the Two-Ray Ground reflection model, and the shadowing model.
Simulation of Enhanced UMTS Access and Core Networks
Page 13
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
The free space propagation model assumes ideal propagation conditions, i.e., there is only one
clear line-of-sight (LOS) path between the transmitter and the receiver. Clearly, a single LOS
path between two nodes is never the only means of propagation, however, it provides a simple
model for obtaining some initial results.
The Two-Ray Ground reflection model considers both the direct path and a ground reflection
path. This model is capable of giving a more accurate prediction compared to the free space
model.
The shadowing model takes into account multi-path propagation effects, also known as fading
effects. The free space and the Two-Ray Ground reflection models predict the received power
as a deterministic function of distance. Consequently, they represent the communication range
as an ideal circle. When multi-path propagation effects are considered it can be seen that in reality, the received power at a certain distance is a random variable. The shadowing model is a
general, widely used model.
Note that a detailed study of the radio interface, such as propagation parameters, coding techniques, adaptive antennas, will be studied in WP2 and made available to WP4.
6.10 Routing
NS-2 supports three major routing categories. These are unicast routing, multicast routing and
hierarchical routing.
In unicast routing, there are two issues to point out. Firstly, four different routing strategies are
used. These are protocol specific configuration parameters, static routing, session routing, dynamic routing, and manual routing. Static and session routing use Dijkstra’s all-pairs Shortest
Path First (SPF) algorithm. One type of dynamic routing is the Distributed Bellman-Ford (or Distance Vector) algorithm.
In multicast routing, there are four protocol specific configuration mechanisms. “Centralized Multicast,” is a sparse mode implementation of multicast. “Dense Mode” is an implementation of a
dense-mode-like protocol. “Shared Tree Mode,” is a version of a shared tree multicast protocol.
“Bi-directional Shared Tree Mode” is an experimental version of a bi-directional shared tree protocol.
Hierarchical Routing was mainly devised to reduce memory requirements of simulations over
large topologies. A topology is broken down into several layers of hierarchy, hence, downsizing
the routing table.
6.11 Transport Protocols and Applications
NS-2 has a plethora of implemented transport mechanisms and applications. The transport side
offers and documents four main categories of transport agents: User Datagram Protocol (UDP),
Transmission Control Protocol (TCP), Scalable Reliable Multicast (SRM), and Packet Pair Receiver-Driven Layered Multicast (PLM).
There are two major types of TCP agents, one-way agents, and a two-way agent. One-way
agents are further subdivided into a set of TCP senders and receivers. The two-way agent is
symmetric in the sense that it represents both a sender and receiver. However, this is not completely finalised. The NS-2 implementation of the PLM protocol is done both in C++ and OTcl.
The PLM “Packet Pair” generator is written in C++ and the PLM core machinery is written in
OTcl.
On the application side, there are traffic generators and simulated applications. Telnet and the
File Transfer Protocol (FTP) are the two simulated application classes that currently exist. Web
traffic and the Hyper Text Transfer Protocol (HTTP) protocol are separate categories within the
applications’ spectrum.
Simulation of Enhanced UMTS Access and Core Networks
Page 14
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
Other transport protocols and applications can be defined, e.g., in WP1 and WP3, and included
in the system level simulator.
6.12 Parallel Distributed NS (PDNS)
One of the goals of WP4 is to implement the system level simulation on a high-performance distributed platform. Consequently, the choice of simulation environment has to support parallelization.
6.12.1 Parallelization
Parallelization as a concept, is the idea of allocating the work that could take up a lot of resources and time on one processor to many processors, by giving a small task on each processor and combining the different outputs. This typically results in faster execution times.
Parallelizing an experiment or a simulation refers to executing it on several processors at the
same time, in order to execute the experiment faster. It may use any of shared memory multiprocessor systems or networked nodes, including some fast communicating clusters.
The goal of parallel simulation is to partition the system being simulated into relatively independent subsystems that communicate with each other in a simple manner and to simulate
each subsystem on a different processor. There is a natural correspondence between the physical system (e.g., network) and the logical system (e.g., simulator).
Distributing an experiment or a simulation means using networked nodes for either parallel or
remote simulation, or both.
The term “distributed” simulation, however, refers specifically to the process of parallelizing a
discrete event simulation. In other words, running a single discrete event simulation on a parallel computer is referred to as distributed simulation.
NS-2 can support parallelization and, in addition, provides a PDNS module that provides
straightforward interface commands to simplify the process of parallelizing a simulation script. In
effect, the PDNS model offers the ability to run an NS-2 simulation, which is by definition a discrete event simulation, in a distributed manner.
PDNS was added to NS-2 by the PADS research group at Georgia Tech. This research group
also prepared an extensive library of support software known as RTIKIT. This software supports
several aspects of the parallel and distributed implementations of network simulations such as
global virtual time management, group data communications, and message buffer management.
6.12.2 Parallelized Network Simulation
The purpose of PDNS is to minimize the modifications needed to be made to standard NS-2
source code in order to parallelize a script. Hence, the addition of PDNS to NS-2 does not affect
users who had been using older versions of NS-2 and do not need the parallelization tool for
their purposes. The modifications to non-parallelizable NS-2 code can be grouped into two categories:
 Modifications to NS-2 event processing.
 Extensions to NS-2 OTcl Syntax.
Currently, PDNS has been tested on over thirty systems, with more than thirty thousand node
topologies. Tests were run on both the myrinet interconnected systems and the Ethernet
TCP/IP networks. Performance by using parallelization in simulations did not prove to be better
all the time but it usually gives varying simulation speedups, from minimum speedup to almost
perfect speedup.
Simulation of Enhanced UMTS Access and Core Networks
Page 15
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
6.13 Modifications of Existing NS-2 software
Modifying existing NS-2 libraries to build a simulator for Enhanced UMTS networks can be done
since the current framework, at least conceptually, allows this.
6.13.1 Ease of Software Modifications
Modifying NS-2 software is technically an easy task, assuming there exists the programming
expertise to perform these modifications. This is due to the fact that the simulator’s software is
public domain and the result of a collaborative effort of many programmers.
As stated previously, NS-2 is an open source environment and its framework allows for modifications and additions to be made. The NS-2 manual also suggests ways of achieving the modifications required. Close communication among NS-2 users is also an additional advantage.
There will be an effort to reuse as much NS-2 code as possible in developing the software for
the Enhanced UMTS system simulator. Modifications of the source code are possible in both
the C++ source code and the OTcl source code.
6.13.2 Conceptual Need for Software Modification
There is a conceptual need for software modification as the idea of Enhanced UMTS is not finalised as a concept or standardised as a network structure. Therefore, the additions will have to
model aspects of the Enhanced UMTS system concept that are not currently supported by NS2. As the answer to the question: “What exactly is Enhanced UMTS?” is still under investigation,
the new software components will be created at the best possible accuracy from the specifications agreed upon by the consortium.
For example, one of the main inputs to the simulation will consist of data that will lead to Signal
to Interference Ratio (SIR) estimations. This is not implemented in NS-2. Therefore, it will be
one of the main additions to the current core code structure. Also, implementations of power
control, dynamic channel allocation, and handover mechanisms are currently lacking.
6.14 Support
Support is divided in five main categories listed and explained below:
 Debugging Support – Debugging is supported at both the OTcl level and the C++ level.
Debugging can be performed separately at each level, but it is also possible to mix Tcl
and C++ debugging. Debugging, at the C++ level only, can be done using any standard
debugger. Memory debugging is also possible.
 Mathematical Support – The simulator includes a small collection of mathematical functions implementing random number generation and integration. This are is under continuous development by NS-2 users. Some classes that are currently finalised are: random
number generation, random variables, integrals, and ns-random.
 Trace and Monitoring Support – There are a number of ways of collecting output or trace
data on a simulation. The most usual way of dealing with output and trace data is to gather the appropriate information while a simulation executes and store it in a file. Post simulation, the data is collected from the appropriate file, analysed, and presented accordingly.
Monitors are supported by a different set of objects than traces. These objects are created
and inserted into the network topology around queues. They provide a place where arrival
statistics and times are gathered and, by making use of some other NS-2 mechanisms,
compute statistics over time intervals.
 Test Suite Support and Validation – Distribution of NS-2 contains many test suites, used
mainly for validation, especially if any modifications are made to the original NS-2 code.
Simulation of Enhanced UMTS Access and Core Networks
Page 16
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
This ensures that the changes have not affected any other parts of the NS-2 code. Test
suites can be written from scratch or by using one of the existing test suites as a template.
 Coding Support – The NS-2 manual includes guidelines for coding in the NS-2 environment. This includes recommended indentation style, some variable naming conventions,
error messages, advice for using C++ templates in NS-2, and some debugging tips.
7. Simulator Requirements
The requirements for a basic framework for system level simulations are addressed in this section, for capturing the dynamic end-to-end behaviour of an overall network, as well as the physical link level behaviour, through a separate link level simulator. The physical link level simulator
is address in SEACORN WP2.
The system level simulator includes the dynamic user behaviour (e.g., mobility and variable traffic demands), radio interface, Radio Access Network (RAN), and Core Network (CN) at an appropriate level of abstraction. Traditionally, system level simulators assume the air interface as
the bottleneck. Instead of considering only the air interface as the bottleneck, this system level
simulator aims to capture the overall end-to-end network behaviour (dynamic user behaviour,
radio interface, RAN, CN). The evaluation of the end-to-end system performance needs to incorporate the desired QoS measures as influenced by both the network behaviour and the radio
link. This perspective results from the all-IP network approach. In an all-IP network QoS is currently not guaranteed.
A Discrete Event based Simulator (DES) approach is taken for the development of the proposed
system level simulator, as opposed to the time based system level simulators, currently appearing in the literature. However, the physical link level behaviour is captured through a separate
time based link level simulator.
7.1
Simulator Inputs and Outputs
The simulator design follows a functional perspective. The modules comprising the simulator
are categorized according to their functionality in one of three groups: Control Mechanisms,
Mobile Environment, Characterization and Performance Evaluation. The inputs to these categories can be inputted internally, from other modules of the system level simulator, or externally,
from the WP2 and WP3 simulators and from the users. Due to the heterogeneity of the necessary inputs, the object-oriented approach offered by NS-2 is put into use to help minimize dependencies between heterogeneous inputs. The functional approach supported by NS-2 aids
the integration of these results with the system level simulator.
In the system level simulator, it is necessary to offer and assess the behaviour of different control mechanisms, which include Power Control (PC), Soft/Softer Handover, Admission Control
(AC) and Packet Scheduling (PS). The simulator will use several inputs, such as information
about the network state, the High Speed Downlink Packet Access (HSDPA) and link level information. The Mobile Environment, which includes the network layout and state, will accept user traffic characteristics and information about mobility from specified scenarios as well as physical parameters and channel behaviour information from the link level simulations. Performance
evaluation will consider the network traffic model, the network protocols and architecture from
the network and transport level simulations, and scenarios of traffic services and applications.
Network performance must enable the evaluation of coverage, capacity, RRM mechanisms,
protocols and architectures, and QoS (using metrics such as call blocking, call/packet dropping,
delay).
The Mobile Environment category contains the methods of generating a topology for a scenario
as well as the initialisation or redefinition of node properties. NS-2 allows UMTS nodes (Node
B’s and UE’s) to be distributed in a predefined grid that represents the simulation area. For the
Simulation of Enhanced UMTS Access and Core Networks
Page 17
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
basic simulator the cells are initially assumed to be circular with equal radii, but can be extended to hexagonal (or other) patterns.
Several factors influence the Mobile Environment. These include:

The specific propagation model used (NS-2 provides basic models and further propagation models will be integrated in the simulator).

Propagation delays between UE and UTRAN and between UTRAN and SGSN/GGSN.

The mobility scenario defined for the UEs.

Uplink and Downlink differences and how these are modelled.

IP delay.
Power Control is an essential feature of any CDMA based cellular system. Without utilizing an
accurate Power Control mechanism, the system’s behaviour cannot be adequately assessed.
The main reasons for implementing a power control mechanism are the near-far problem, interference dependent capacity of the W-CDMA and the limited power source of the UE. In WCDMA systems the purpose of PC is mainly to reduce the intra-cell interference. Meeting these
targets requires optimisation of the radio transmission, i.e., the power of every transmitter is adjusted to the level required to meet the requested QoS. The task is complicated because of the
dynamic variation of the radio channel. Without PC, phenomena like fading and interference
drive down the system stability and ultimately degrade its performance dramatically.
AC is another one of the system level control mechanisms. Its main task is to estimate whether
a new call can have access to the system. The AC algorithms predict the load of the cell if the
new call is admitted and based on this algorithm the RNC grants or rejects access.
PS is a mechanism that becomes necessary due to the nature of traffic in a UMTS network,
both real time and non-real time. PS is a mechanism that controls and balances traffic. Real
time traffic and non-real time traffic need to be handled separately as they are controlled and
balanced in different ways.
The NS-2 simulator will be extended to incorporate the above control mechanisms.
The propagation models to be integrated in the system level simulator are the COST Action 231
models. The estimations applied in developing these models are based on the project COST
Action 231, and more precisely, on theoretical and empirical approaches and extensive measurements campaigns in European cities. The models created by the COST Action 231 are
based on the approaches of Walfisch, Ikegami and Hata models.
In the simulator, two propagation conditions will also be incorporated for building penetration
loss, Line of Sight (LOS) condition and No Line of Sight (NLOS) condition. The second condition
is more frequent but at the same time more complicated than the first one. Both conditions are
properly incorporated in the propagation models.
Performance evaluation methods attempt to conclude the effect of different coverage and capacity values on QoS as well as the effect of different architectures and protocols on QoS. QoS
is evaluated through metrics such as call blocking, call and packet dropping and delay, which
will be the main outputs of the simulator.
7.2
System Simulator Assumptions
To allow comparison between different network protocols and architectures, and assess and
compare the usefulness of proposed changes to a system, a set of well-known simulation assumptions should be used. These assumptions should be independent of the simulation tool, if
they will also allow comparison with the results obtained by different simulators. Such simulation
tools naturally differ, as often researchers design customised simulators, reflecting the level of
Simulation of Enhanced UMTS Access and Core Networks
Page 18
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
desired abstractness and focus, using different tools, and different platforms. It is therefore required that at system level, a set of parameters be kept the same. These parameters should be
harmonized and kept between different simulators for consistency reasons. It is worth noting
that it is usually not feasible for a detailed specification of these assumptions, since simulation
tools are usually quite different. Given this, there is considerable effort to identify and publicise
some commonly accepted simulation parameters. The Table 7-1 presents the system level simulation assumptions as presented in [11]. Within SEACORN we intend to use these parameters
as the defaults and for our basic simulations.
Simulation of Enhanced UMTS Access and Core Networks
Page 19
Deliverable D4.1
Specification of Simulation Environment
34900
SEACORN
Parameter
Explanation/Assumption
Comments
Cellular layout
Hexagonal grid, 3-sector sites
Provide your cell layout picture
Site to Site distance
2800 m
Antenna pattern
As proposed in [2]
Only horizontal pattern specified
Propagation model
L = 128.1 + 37.6 Log10(R)
R in kilometres
CPICH power
-10 dB
Other common channels
- 10 dB
Power allocated to HSDPA transmission, including associated signaling
Max. 80 % of total cell power
Slow fading
As modelled in UMTS 30.03, B
1.4.1.4
Std. deviation of slow fading
8 dB
Correlation between sectors
1.0
Correlation between sites
0.5
Correlation distance of slow fading
50 m
Carrier frequency
2000 MHz
BS antenna gain
14 dB
UE antenna gain
0 dBi
UE noise figure
9 dB
Max. # of retransmissions
Specify the value used
Fast HARQ scheme
Chase combining
BS total Tx power
Up to 44 dBm
Active set size
3
Maximum size
Specify Fast Fading model
Jakes spectrum
Generated e.g. by Jakes or Filter approach
Retransmissions by fast HARQ
For initial evaluation of fast
HARQ
Table 7-1: System Level Simulation assumptions.
8. Validation
Validation programs in NS-2 use test suites that are either already available by NS-2 or usually
based on an NS-2 test suite template. The test suites that are readily available are appropriate
Simulation of Enhanced UMTS Access and Core Networks
Page 20
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
for validating the correctness of already existing or newly added NS-2 modules and they are
distinguished in three separate components.
 A shell script to initiate the test.
 An NS-2 Tcl script to run through the tests defined.
 A subdirectory that contains the correct trace files generated by the test suite. These files
are used to verify whether the test suite runs correctly with the user’s version of NS-2.
Another option is for the user to write his or her own test suite by using one of the already provided test suites as a template. Following the structure of the NS-2 test suite, when a user
writes his or her own suite, the first step is to create a shell script. This is where the module to
be tested, the name of the NS-2 Tcl script, and the output subdirectory are specified. In the NS2 script the user needs to create several test cases. Each test case represents a simulation
scenario.
When the tests are executed, trace files are generated and saved to the output subdirectory.
These trace files are compared to the correct trace files that come with the test suite. If the
comparison indicates differences, the test fails, else it succeeds.
9. Conclusion
This deliverable describes the specifications of the simulation environment selected for the system level simulations of the SEACORN project. NS-2 is chosen to develop the Enhanced UMTS
system level simulator. Developments in both OPNET and OMNeT++ will also be closely monitored.
The specification of the NS-2 simulation environment is presented. Particular emphasis is
placed on the parameters and features relevant to the requirements of the SEACORN project
such as support for mobility, support for parallel simulations, ability to run large networks, and
open source environment. Collectively, we show that the parameters and features considered
justify the selection of the NS-2 simulator for the system level simulations.
10.
Bibliography
[1] "Description of Work," tech. annex, Information Societies Technology Programme, SEACORN, 2002.
[2] J. Chung, M. Claypool, “NS by Example,” Worcester Polytechnic Institute, http://nile.wpi.edu/NS/.
[3] “Tutorial for the Network Simulator ns,” Information Sciences Institute, University of Southern California, http://www.isi.edu/nsnam/ns/tutorial/index.html.
[4] R. Buyya, High Performance Cluster Computing: Programming and Applications, Prentice Hall PTR,
Upper Saddle River, NJ, 1999.
[5] R. M. Fujimoto, Parallel and Distributed Simulation Systems, John Wiley, New York, NY, 2000.
[6] The ns Manual, 2002.
[7] OPNET Technologies Inc., “OPNET Modeler Modeling Concepts,” Bethesda, MD, 2002.
[8] OMNeT++ Discrete Event Simulation System User Manual, 2001.
[9] D. Wu, E. Wu, J. Lai, A. Varga, Y. A. Sekercioglu, G. K. Egan, Implementing MPI based Portable
Parallel Discrete Event Support in the OMNeT++ Framework.
Simulation of Enhanced UMTS Access and Core Networks
Page 21
34900
Deliverable D4.1
Specification of Simulation Environment
SEACORN
[10] B. K. Szymanski et al., “Genesis: A System for Large-Scale Parallel Network Simulation,“ 16th Workshop on Parallel and Distributed Simulation, Washington, DC, May 2002, pp. 89.
[11] “Common HSDPA System Simulation Assumptions”. 3GPP TSG RAN WG1, TSGR1#15(00)XXXX.
Simulation of Enhanced UMTS Access and Core Networks
Page 22