The Role of NCTUns for Communication Engineering

Abstract

NCTUns is a simulation tool which is very significant for communication engineering. It is a real-life application program by which we can study of network behaviors and performance analysis. It is a method that can be used to describe or predict how a system will operate given certain choices for the controllable inputs and randomly generated values for the probabilistic inputs [1]. I will briefly introduce in this paper the Capabilities and Features and also discuss about Mechanism and Design of NCTUns for Communication Engineering.

1. Introduction

This network simulator is an open source that enables to modifymodules codes of software for communication engineering. This software has a well developed graphical user interface. Here, external host (e.g., hubs or switches) has been used for data transmission. In this case real external data flows are obtainable, which are directed to various type of networks in communication engineering. Regarding to simulation results conclusions has been made.

NCTUns is developed by National ChiaoTung University [2]. NCTUns simulates the hardware characteristics of network devices, the protocol stacks employed in these devices (e.g., the bridge learning protocol used in a switch), and the implementation of application programs on these devices. This tool provides network utility programs for communication engineering to make digital or hard copies for personal or classroom. These topologies specify network parameters, monitoring traffic flows, gathering statistics about a simulated network, etc.

Simulation is one of the most commonly used quantitative approaches to decision making. It is a method for learning about a real system by experimenting with a model that represents the system. The simulation model contains the mathematical expressions and logical relationships that

describe how to compute the value of the outputs given the values of the inputs. Any simulation model has two inputs: controllable inputs and probabilistic inputs. Simulation is not an optimization technique. It is a method that can be used to describe or predict how a system will operate given certain choices for the controllable inputs and randomly generated values for the probabilistic inputs [1].

NCTUns is a technique where a program simulates the behavior of a network. The program performs this simulation either by calculating the interaction between the different virtual network entities (hosts/routers, data links, packets, etc) using mathematical formulas, or actually capturing and playing back network parameters from a real production network. Using this input, the behavior of the network and the various applications and services it supports can be observed in a test lab. Various attributes of the environment can also be modified in a controlled manner to asses these behaviors under different conditions. When a simulation program is used in conjunction with live applications and services in order to observe end-to-end performance to the user desktop, this technique is also referred to as network emulation.

Network simulators are used to predict the behavior of networks and applications under different situations. Researchers use network simulators to see how their protocols would behave if deployed. It is typical to use a network simulator to test routing protocols, MAC (Medium Access Control) protocols, transport protocols, applications etc. Companies use simulators to design their networks or applications to get a feel for how they will perform under current or projected real-world conditions.

2. Capabilities and Features of NCTUns

The NCTUns is a high-fidelity and extensible network simulator and emulator capable of simulating various protocols used in both wired and wireless IP networks. Its core technology is based on the novel kernel re-entering methodology invented by Prof. S.Y. Wang when he was pursuing his Ph.D. degree at Harvard University. Due to this novel methodology, NCTUns provides many unique advantages that cannot be easily achieved by traditional network [3]. In the following, we briefly explain its capabilities and features.

It directly uses the real-life Linux’s TCP/IP protocol stack to generate recording method simulation results. By using a novel kernel re-entering simulation methodology, a real-life UNIX (e.g., Linux) kernel’s protocol stack can be directly used to generate high-fidelity simulation results.

It can use any real-life presented or to-be-developed UNIX application program as a traffic generator program without any adjustment. Any real-life program can be run on a simulated network to generate network traffic. This enables a researcher to test the functionality and performance of a distributed application or system under various network conditions. Another important advantage of this feature is that application programs developed during simulation studies can be directly moved to and used on real-world UNIX machines after simulation studies are finished. This eliminates the time and effort required to port a simulation prototype to a real-world implementation if traditional network simulators are used.

It can use any real-life UNIX network configuration and monitoring tools. For example, the UNIX route, ifconfig, netstat, tcpdump, traceroute commands can be run on a simulated network to configure or monitor the simulated network.

Its setup and procedure of a simulated network and application programs are exactly the same as those used in real-world IP networks. For example, each layer-3 interface has an IP address assigned to it and application programs directly use these IP addresses to communicate with each other. For this reason, any person who is familiar with real-world IP networks can easily learn and operate NCTUns in a few minutes. For the same reason, NCTUns can be used as an educational tool to teach students how to configure and operate a real-world network.

It simulates many special and new types of networks. The supported types include Ethernet-based fixed Internet, IEEE 802.11(b) wireless LANs, mobile ad hoc (sensor) networks, GPRS cellular networks, optical networks (including both circuit-switching and busrt-switching networks), IEEE 802.11(b) dual-radio wireless mesh networks, IEEE 802.11(e) QoS wireless LANs, Planned and active mobile ad hoc networks, and 3dB beam width 60-degree and 90-degree directional antennas.

It simulates different networking devices. For example, Ethernet hubs, switches, routers, hosts, IEEE 802.11 (b) wireless stations and access points, WAN (for purposely delaying/dropping/reordering packets), obstacle (block/attenuate wireless signal, block mobile nodes’ movement, block mobile nodes’ views), GPRS base station, GPRS phone, GPRS GGSN, GPRS SGSN, optical circuit switch, optical burst switch and boundary routers, IEEE 802.11(b) dual-radio wireless mesh access point, IEEE 802.11(e) QoS access points and mobile stations, etc.

It can be used as an emulator. An external host in the real world can exchange packets (e.g., set up a TCP connection) with nodes (e.g., host, router, or mobile station) in a network simulated by NCTUns. Two external hosts in the real world can also replace their packets via a network simulated by NCTUns. This feature is very useful as the function and performance of real-world devices can be experienced under various simulated network conditions.

It simulates different protocols. For example, IEEE 802.3 CSMA/CD MAC, IEEE 802.11 (b) CSMA/CA MAC, IEEE 802.11(e) QoS MAC, IEEE 802.11(b) wireless mesh network routing protocol, learning bridge protocol, spanning tree protocol, IP, Mobile IP, RIP, OSPF, UDP, TCP, RTP/RTCP/SDP, HTTP, FTP, Telnet, etc.

It simulates a network swiftly. By combining the kernel re-entering methodology with the discrete-event simulation methodology, a simulation job can be finished quickly.

It generates repeatable simulation results.

If the user fixes the random number seed for a simulation case, the simulation results of a case are the same across different simulation runs even if there are some other behavior (e.g., disk I/O) occurring on the simulation machine.

It provides a highly-integrated and specialized GUI environment. This GUI can help a user (1) sketch network topologies, (2) construct the protocol modules used inside a node, (3) specify the moving paths of mobile nodes, (4) plot network performance graphs, (5) playing back the animation

of a logged packet transfer trace, etc. All these operations can be easily and spontaneously done with the GUI.

Its simulation engine adopts open-system architecture and is open source. By using a set of module APIs provided by the simulation engine, a protocol developer can easily implement his (her) protocol and integrate it into the simulation engine. NCTUns uses a simple but effective syntax to describe the settings and configurations of a simulation job. These descriptions are generated by the GUI and stored in a suite of files. Normally the GUI will automatically transfer these files to the simulation engine for execution. However, if a researcher wants to try his (her) novel device or network configurations that the current GUI does not support, he (she) can totally avoid the GUI and generate the suite of report files by himself (herself) using any text editor (or script program). The non-GUI-generated suite of files can then be manually fed to the simulation engine for execution.

Figure 2.1 Screenshot of performance monitor

It supports remote and concurrent simulations. NCTUns adopts a distributed architecture. The GUI and simulation engine are separately implemented and use the client-server model to communicate. Therefore, a remote user using the GUI program can remotely submit his (her) simulation job to a server running the simulation engine. The server will run the submitted simulation job and later return the results back to the remote GUI program for analyses. This scheme can easily support the cluster computing model in which multiple simulation jobs are performed in parallel on different server machines. This can increase the total simulation throughput.

3. Mechanism and Design of NCTUns

NCTUns adopts a distributed architecture. For understanding the mechanism and design of NCTUns , need to discuss the following eight components.

a. The first component is the GUI program by which a user edits a network topology, configures the protocol modules used inside a network node, specifies mobile nodes’ initial location and moving paths, plots performance graphs, plays back the animation of a packet transfer trace, etc.b. The second component is the simulation engine program, which provides basic and useful simulation services (e.g. event scheduling, timer organization, and packet manipulation, etc.) to protocol modules. We call a machine on which a simulation engine program resides a “simulation server.”c. The third component is the set of various protocol modules, each of which implements a specific protocol or function (e.g., packet scheduling or buffer management). All protocol modules are C++ classes and are compiled and linked with the simulation engine program.d. The fourth component is the simulation job dispatcher program that can simultaneously manage and use multiple simulation servers to increase the aggregate simulation throughput. It can be run on a separate machine or on a simulation server.e. The fifth component is the coordinator program. On every simulation server, the “coordinator” program must be run up. The coordinator should be alive as long as the simulation server is alive. When a simulation server is powered on and brought up, the coordinator must be run up. It will register itself with the dispatcher to join in the dispatcher’s simulation server farm. When the status (idle or busy) of the simulation server changes, it will notify the dispatcher of the new status. This enables the dispatcher to choose an available simulation server from its simulation server farm to service a job.

When the coordinator receives a job from the dispatcher, it forks a simulation engine process to simulate the specified network and protocols. It may also fork several real-life application program processes specified in the job. These processes are used to generate traffic in the simulated network. When the simulation engine process is alive, the coordinator communicates with the dispatcher and the GUI program on behalf of the simulation engine process. For example, the simulation engine process needs to periodically send its current simulation clock to the GUI program. This is done by first sending the clock information to the coordinator and then asking the coordinator to forward this information to the GUI program. This enables the GUI user to know the progress of the simulation. During a simulation, the GUI user can also on-line set or get an object’s value (e.g., to query or set a switch’s current switch table). Message exchanges that occur between the simulation engine process and the GUI program are all relayed via the coordinator.f. The sixth component is the kernel patches that need to be made to the kernel source code so that a simulation engine process can run on a UNIX machine correctly. Currently NCTUns 5.0 runs on Red-Hat’s Fedora Core 9, whose kernel is Linux 2.6.25.g. The seventh component is the various real-life user-level application programs. Due to the novel kernel-reentering simulation methodology, any real-life existing or to-be developed application program can be directly run up on a simulated network to generate realistic network traffic.

h. The eighth component is the various user-level daemons that are run up for the whole simulation case. For example, NCTUns provides RIP and OSPF routing daemons. By running these daemons, the routing entries needed for a simulated network can be constructed automatically. As another example, NCTUns provides and automatically runs up several emulation daemons when it is turned into an emulator. Due to this distributed design, a remote user can submit his (her) simulation job to a job dispatcher, and the dispatcher will then forward the job to an available simulation server for execution. The server will process (simulate) the job and later return the results back to the remote GUI program for further analyses. This scheme can easily support the server farm model in which multiple simulation jobs are performed concomitantly on different simulation servers.

In addition to the above “multi-machine” mode, another mode called the “single machine” mode is supported. In such a mode, all of these components are installed and run on a single machine. Although in this mode different simulation jobs cannot be run concurrently on different machines, since most users have only one machine to run their simulations, this mode may be more appropriate for them. In fact, it is the default mode after the NCTUns package is installed.

The performance of NCTUns was discussed detail in [11].Here, In this paper has been provided some cases which we can use in communication engineering.

4. Several Screen-shots of NCTUns

Some screenshots of NCTUns are given in the next page to give readers a quick idea about NCTUns in several cases of communication engineering. In communication engineer we can use both fixed connection and mobile connection. In both cases NCTUns is very important.

For fixed ConnectionHere, in this paper is provided some very important design in next page for fixed connection.

Opening Screen

All time when a client launches the GUI program, the next starting screen in the next page will explode up.

0

Fig 4.1: The opening screen of NCTUns.

Topology Editor

The topology editor provides a suitable and spontaneous way to graphically create a network topology. A constructed network can be a fixed wired network or a mobile

wireless network. For ITS applications, a road network can also be constructed. Due to the user-friendly design, all GUI operations can be performed easily and spontaneously.

Fig 4.1: The screen of topology editor.

Figure 4.1 Screenshot of topology editor

Characteristic Dialog Box

A network tool (node) has many attributes. Setting and modifying the attributes of a network node can be easily done by double-clicking the icon of a network node. An attribute dialog box pertaining to this node will explosion up. A user can then set the device’s attributes in the dialog box.

also the length indicator; for HTTP, the length indicator can change from one SDU to the next.Although it standard instructs the CS to use PHS rules, the WiMAX does not specify how andwhere such rules are created. It is left to a higher-layer entity to create the PHS rules.Figure 9.2 shows the basic operation of header suppression in WIMAX. When an SDU