Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Zero-configuration networking wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Computer network wikipedia , lookup
Network tap wikipedia , lookup
Distributed firewall wikipedia , lookup
Deep packet inspection wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Airborne Networking wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
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