NETWORK ANALYZER FOR

NETWORKSIMULATOR-2
USING JAVA
Contents
Abstract

1. Introduction

1.1 Purpose

1.2 Abbreviations

1.3 Definitions

1.4 Project Schedule

2. Project Description

2.1 Problem Definition

2.2 Problem Description

2.2.1 Why NS-2

2.2.2 Network Simulator NS-2

2.2.1.1 Users View of NS

2.2.1.2 Architectural View of NS

2.2.1.3 NS Trace Format

2.2.3 Trace Analysis

2.2.2.1 Trace Support

2.2.2.2 Trace Graph Format

2.2.2.3 Trace Analysis Example

 2.2.2.3.1 Understanding the Trace file

2.2.2.3.2 Sample Graph

2.2.4 Simulation Stages

2.2.3.1 Simulation Result Processing

2.2.3.1.1 Trace files processing

2.2.3.1.2 Wired Networks

2.2.3.1.2.1 Trace format of Wired Network

2.2.3.1.3 Wireless Networks

2.2.3.1.3.1 Old Wireless Trace format

2.2.3.1.3.2 New Wireless Trace format

3. Requirements

3.1 Software Requirements

3.2 Hardware Requirements

4. Design aspects

4.1 Basic idea of design

4.2 Expected output

5. Coding

6. Results

7. Conclusions

8. Future work

9. References
 ABSTRACT

Establishing the computer networks in the different peripherals is cost

effective. The performance of the network may not be as good as the one estimated

before the installation and this may sometimes lead to changing of the peripherals.

Therefore it is always better to have a simulation of the network using a computer than

the actual establishment

We have many of simulators likes NS2, GLOMOSIM, SWANS etc. meant

exclusively for network simulations which helps us in estimating the performance of

network without the cost involvement. After having simulated the network, it can be

analyzed for its performance. This approach directs us to take a proper decision about

actual establishment of the network.

One of the foremost problems with the beginners of ns2 is what to do with the

enormous data provided by the trace files. Very little documentation is available which

will help the users of ns2 in extracting the required data and thus calculating parameters

like one-way delay, throughput etc. Besides calculating parameters, one is more

interested in observing the graph which gives instantaneous results.

NANS is the utility which brings all these features into one and from now onwards,

strives to eliminate the entire problem associated with it

 1. INTRODUCTION

1.1 Purpose

Continuous networks development, higher and higher functionality requirements have

created the need for tools that could monitor network transmissions and analyse them.

We have many simulators like NS2, GLOMOSIM, SWANS etc. meant exclusively for

network simulations which helps us in estimating the performance of network without the

cost involvement. After having simulated the network, it can be analyzed for its

performance. This approach directs us to take a proper decision about actual

establishment of the network.

One of the foremost problems with the beginners of ns2 is what to do with the enormous

data provided by the trace files. Very little documentation is available which will help the

users of ns2 in extracting the required data and thus calculating parameters like one-way

delay, throughput etc. Besides calculating parameters, one is more interested in observing

the graph which gives instantaneous results.

This paper describes Trace graph a data presentation system for Network Simulator -2
 Trace graph system provides many options for analysis, has capabilities to calculate

many parameters characterizing network simulation. The NS2 simulator leaves lot of

statistical data as the output of a particular simulation. Using this data that particular

network can be analyzed for its performance. This analysis may include the capturing of

Information from the simulator and drawing the graphs

1.2 Abbreviations

NS - Network Simulator

TCP - Transmission Control Protocol

CBR - Control Bit Rate

ACK - Acknowledgement

RTT - Round Trip Time

TCL - Tool Command Language

OTCL - Object Tool Command Language

VINT - Virtual Inter Network Test board

LBNL - Laurence Berkeley National Laboratory

MANET - Mobile Ad-hoc Network

NAM - Network Animator

1.3Definitions

Wired Networks: A Wired network is a network with physical cables connecting each

system together.

Wireless Networks: The term wireless networking refers to technology that enables two

or more computers to communicate using standard network protocols, but without

network cabling.

Adhoc Networks: Adhoc networks are mobile wireless networks that have no fixed

infrastructure. There are no fixed routers instead each node acts as a router and forwards

traffic from other nodes.

MANETs: A MANET is a type of ad-hoc network with rapidly changing topology.

MANETS are wireless network formed by a collection of mobile nodes without any pre

established infrastructure

Routing: Mapping of the packets from source to destination is called Routing.

Simulator: A device that enables the operator to reproduce or represent under test

conditions phenomena likely to occur in actual performance.

Simulation: is an imitation of some real thing, state of affairs, or process. The act of

simulating something generally entails representing certain key characteristics or

behaviors of a selected physical or abstract system.

NS: The Network Simulator ns-2 is a discrete event simulator, which means it simulates

such events as sending, receiving, forwarding and dropping packets. The events are

sorted by time (seconds) in ascending order.

TCP: A protocol developed for the internet to get data from one network device to

another; "TCP uses a retransmission strategy to insure that data will not be lost in

transmission". It is used to establish connection-oriented, sequenced and error-free

sessions over IP networks. TCP offers reliability by providing reliable packet delivery.

CBR: CBR is a term used in telecommunications, relating to the quality of service

compared with variable bit rate. CBR is useful for streaming multimedia content on

limited capacity channels since it is the maximum bit rate that matters, not the average, so

CBR would be used to take advantage of all of the capacity.

ACK: ACK is a message sent to acknowledge the receipt of an error free data packet

from a remote machine. Acknowledgment is service that is used by TCP, to transmit data

reliably in an IP environment.

TCL: TCL is an interpreted language that operates, like Perl, within its own shell.

OTCL: Tcl script language with Object-oriented extensions.

 2. PROJECT DESCRIPTION

2.1 Problem Definition

Establishing the computer networks in the different peripherals is cost effective. The

performance of the network may not be as good as the one estimated before the

installation and this may sometimes lead to changing of the peripherals. Therefore it is

always better to have a simulation of the network using simulators likes NS2,

GLOMOSIM, SWANS etc. meant exclusively for network simulations which helps us in

estimating the performance of network without the cost involvement. Here we are using

NS2. After having simulated the network with NS2, it can be analyzed for its

performance. This approach directs us to take a proper decision about actual

establishment of the network.

The main problem is that NS-2 doesnt provide any visualization options for simulation

results (trace files) analysis. Because of this reason trace graph NS-2 data presentation

system was created. This paper describes Trace graph a data presentation system for

Network Simulator NS-2. The simulator doesnt have any options implemented to
analyse simulations results so its hard to use it. Trace graph system provides many

options for analysis; it has capabilities to calculate many parameters characterizing

network simulation, and statistical reports, saves calculation results to text files and to

process its own script files to do all the calculations automatically.

2.2 Problem Description

2.2.1 Why NS2:

In the past ten years computer networks have been significantly

developed, especially the largest one the Internet. Nowadays networks have more and

more workstations, the transmission speed increases and the connections capabilities rise.

Continuous networks development, higher and higher functionality requirements have

created the need for tools that could monitor network transmissions and analyse them.

There have been developed network simulators, which help to design and test various

kinds of networks, protocols, etc. A simulator for communication networks developed at

LAURENCE BERKELEY NATIONAL LABORATORY (LBNL) within the VINT

project. It fast became a property of the entire research community, where everyone can

add its own modules, and contributes to the development of the simulator. The first

version of NS was experimental. Now we are working with the second version called NS-

2.The simulator works under UNIX and Windows system platforms and is mainly used

for network research. It is widely used all over the world The main advantage of

simulations is low cost of development and implementation in comparison to

experimental tests in real environment. The main problem is that ns-2 doesnt provide
any visualization options for simulation results (trace files) analysis. Because of this

reason Trace graph ns-2 data presentation system was created in year 2001 and has

been developed for a year and a half. This paper describes Trace graph a data

presentation system for Network Simulator ns-2. The simulator doesnt have any options

implemented to analyse simulations results so its hard to use it. Trace graph system

provides many options for analysis, has capabilities to calculate many parameters

characterizing network simulation, e.g. delay, RTT, throughput, sequence number,

processing time, to plot 250 various graphs, and statistical reports, to save calculations

results to text files and to process its own script files to do all the calculations

automatically. Trace graph has become very popular and is used by many ns-2 users.

2.2.2 Network Simulator NS-2

The Network Simulator ns-2 is a discrete event simulator, which means it simulates

such events as sending, receiving, forwarding and dropping packets. The events are

sorted by time (seconds) in ascending order. The NS project is now a part of the

VINT PROJECT that develops tools for simulation results display, analysis and

converters that convert network topologies generated by well-known generators to

NS formats. Currently, NS (version 2) written in C++ and OTcl (Tcl script language

with Object-oriented extensions developed at MIT) is available. It is implemented in

C++. For simulation scenario and network topology creation it uses OTcl (Object

Tool Command Language).

2.2.2 .1 Users View of NS

Figure 1. Simplified User's View of NS

As shown in Figure 1, in a simplified user's view, NS is Object-oriented Tcl (OTcl) script

interpreter that has a simulation event scheduler and network component object libraries,

and network setup (plumbing) module libraries (actually, plumbing modules are

implemented as member functions of the base simulator object). In other words, to use

NS, you program in OTcl script language. To setup and run a simulation network, a user

should write an OTcl script that initiates an event scheduler, sets up the network topology

using the network objects and the plumbing functions in the library, and tells traffic

sources when to start and stop transmitting packets through the event scheduler. The term
"plumbing" is used for a network setup, because setting up a network is plumbing

possible data paths among network objects by setting the "neighbor" pointer of an object

to the address of an appropriate object. When a user wants to make a new network object,

he or she can easily make an object either by writing a new object or by making a

compound object from the object library, and plumb the data path through the object.

This may sound like complicated job, but the plumbing OTcl modules actually make the

job very easy. The power of NS comes from this plumbing. Another major component of

NS beside network objects is the event scheduler. An event in NS is a packet ID that is

unique for a packet with scheduled time and the pointer to an object that handles the

event. In NS, an event scheduler keeps track of simulation time and fires all the events in

the event queue scheduled for the current time by invoking appropriate network

components, which usually are the ones who issued the events, and let them do the

appropriate action associated with packet pointed by the event. Network components

communicate with one another passing packet; however this does not consume actual

simulation time. All the network components that need to spend some simulation time

handling a packet (i.e. need a delay) use the event scheduler by issuing an event for the

packet and waiting for the event to be fired to itself before doing further action handling

the packet. For example, a network switch component that simulates a switch with 20

microseconds of switching delay issues an event for a packet to be switched to the

scheduler as an event 20 microsecond later. The scheduler after 20 microseconds

dequeues the event and fires it to the switch component, which then passes the packet to

an appropriate output link component. Another use of an event scheduler is timer. For

example, TCP needs a timer to keep track of a packet transmission time out for
retransmission (transmission of a packet with the same TCP packet number but different

NS packet ID). Timers use event schedulers in a similar manner that delay does. The only

difference is that timer measures a time value associated with a packet and does an

appropriate action related to that packet after a certain time goes by, and does not

simulate a delay.

2.2.2.2 Architectural View of NS

Figure 2. Architectural View of NS

Figure 2 shows the general architecture of NS. In this figure a general user (not an NS

developer) can be thought of standing at the left bottom corner, designing and running

simulations in Tcl using the simulator objects in the OTcl library. The event schedulers

and most of the network components are implemented in C++ and available to OTcl

through an OTcl linkage that is implemented using tclcl. The whole thing together makes
NS, which is a OO extended Tcl interpreter with network simulator libraries. This section

briefly examined the general structure and architecture of NS. At this point, one might be

wondering about how to obtain NS simulation results. As shown in Figure 1, when a

simulation is finished, NS produces one or more text-based output files that contain

detailed simulation data, if specified to do so in the input Tcl (or more specifically, OTcl)

script. The data can be used for simulation analysis ( simulation result analysis examples

are presented in later sections)or as an input to a graphical simulation display tool called

Network Animator (NAM) that is developed as a part of VINT project. NAM has a nice

graphical user interface similar to that of a CD player (play, fast forward, rewind, pause

and so on), and also has a display speed controller.} Furthermore, it can graphically

present information such as throughput and number of packet drops at each link, although

the graphical information cannot be used for accurate simulation analysis.

2.2.2.3 NS Packet Format

A NS packet is composed of a stack of headers, and an optional data

space (see Figure 3). A packet header format is initialized when a Simulator object is

created, where a stack of all registered (or possibly useable) headers, such as the common

header that is commonly used by any objects as needed, IP header, TCP header, RTP

header (UDP uses RTP header) and trace header, is defined, and the offset of each header

in the stack is recorded. What this means is that whether or not a specific header is used,

a stack composed of all registered headers is created when a packet is allocated by an

agent, and a network object can access any header in the stack of a packet it processes

using the corresponding offset value.

 Fig

ure 3. NS Packet Format

Usually, a packet only has the header stack (and a data space pointer that is null).

Although a packet can carry actual data (from an application) by allocating a data space,

very few application and agent implementations support this. This is because it is

meaningless to carry data around in a non-real-time simulation. However, if you want to

implement an application that talks to another application cross the network, you might

want to use this feature with a little modification in the underlying agent implementation

Another possible approach would be creating a new header for the application and

modifying the underlying agent to write data received from the application to the new

header.

Simple ns script:

EXAMPLE:

set ns [new Simulator]

set nf [open out.nam w]

 $ns namtrace-all $nf

proc finish {} {

global ns nf

$ns flush-trace

close $nf

exec nam out.nam &

exit 0

$ns at 5.0 "finish"

$ns run

Above script is a simple minimum script for any tcl file.

First two lines will create and open network simulator and nam.

The procedure finish is to finish execution.

2.2.3 Trace Analysis

2.2.3.1 Trace Support

There are number of ways of collecting output or trace data on a simulation. Generally,

trace data is either displayed directly during execution of the simulation, or (more

commonly) stored in a file to be post-processed and analyzed. There are two

primary but distinct types of monitoring capabilities currently supported by the

simulator. The first, called traces, record each individual packet as it arrives, departs,

or is dropped at a link or queue. Trace objects are configured into a simulation as

 nodes in the network topology, usually with a TCL channel object hooked to

them, representing the destination of collected data (typically a trace file in the

current directory). The other types of objects, called monitors, record counts

associated with all packets. To support traces, there is a special common header

included in each packet. It presently includes a unique identifier on each packet, a

packet type field, a packet size field, and an interface label.

2.2.3.2 Trace Graph Formats

we presently discuss two networks

wired trace formats

Normal trace format(wired )

Wireless trace formats:

Old wireless trace formats

New wireless trace formats

AODV routing protocol trace formats

DSDV routing protocol trace formats

DSR routing protocol trace formats

TORA routing protocol trace formats

 Mobile node movement and energy trace formats

The various traces begin with a single character or abbreviation that indicates the type of

trace, followed by a fixed or variable trace format. The tables listing the trace formats

differ between fixed and variable trace formats:

For fixed trace formats, the table lists the event the triggers the trace under the

Event heading and the characters that start the trace under the Abbreviation

heading. The format is listed across the last two columns, and the type and value

for each element of the format are listed beneath under the Type and Value

headings. Some events have multiple trace formats.

For variable trace formats, the table lists the event the triggers the trace under the Event

heading and the characters that start the trace under the Abbreviation heading. The

last three columns list the possible flags, types, and values for the event under the

Flag, Type, and Value headings.

Normal trace formats

Event Abbreviation Type Value
Normal Event r: Receive %g %d %d %s %d %s %d %d.%d %d.%d %d %d
d: Drop double Time
e: Error
int Source Node
+: Enqueue
-: Dequeue int Destination Node
string Packet Name
int Packet Size
string Flags
int Flow ID
int Source Address
 int Destination Address
int Sequence Number
int Unique Packet ID

Depending on the packet type, the trace may log additional information:

Event Type Value

%d 0x%x %d %d
int Ack Number
TCP Trace hexadecimal Flags
int Header Length
int Socket Address Length
%.2f %.2f %.2f %.2f
double Source Latitude
Satellite Trace double Source Longitude
double Destination Latitude
double Destination Longitude

Trace Format of Wired Network:

Event Abbreviation Type Value

%g %d %d %s %d %s %d %d.%d %d.%d %d %d
double Time
int Source Node
int Destination Node
r: Receive string Packet Name
d: Drop int Packet Size
Normal Event e: Error
+: Enqueue string Flags
-: Dequeue int Flow ID
int Source Address
int Destination Address
int Sequence Number
int Unique Packet ID

2.2.3.3 Trace Analysis Example:

This section shows a trace analysis example.

2.2.3.3.1 Understanding the Trace file:

Figure 4.Trace Format Example

Trace/Enque - A packet arrival ( usually at a queue )

Trace/Deque - A packet departure( usually at a queue )

Trace/Drop - Packet drop ( packet delivered to a drop-target )

Trace/Recv - Packet receive event at the destination node of a link.

Each trace line starts with an event (+, -, d, r) descriptor followed by the simulation time

(in seconds) of that event, and from and to node, which identify the link on which the

event occurred. The next information in the line before flags (appeared as "------" since

no flag is set) is packet type and size (in Bytes). Currently, NS implements only the

Explicit Congestion Notification (ECN) bit, and the remaining bits are not used. The next

field is flow id (fid) of IPv6 that a user can set for each flow at the input OTcl script.
Even though fid field may not used in a simulation, users can use this field for analysis

purposes. The next two fields are source and destination address in forms of "node.port".

The next field shows the network layer protocol's packet sequence number. Note that

even though UDP implementations do not use sequence number, NS keeps track of UDP

packet sequence number for analysis purposes. The last field shows the unique id of the

packet.

Having simulation trace data at hand, all one has to do is to transform a subset of the data

of interest into a comprehensible information and analyze it.A tracefile called "out.tr"

will be produced.This out.tr will be used for our simulation analysis. Figure 4shows the

trace format and example trace data from "out.tr".

2.2.3.3.2:Sample Graph
This section showed an example of how to generate traces in NS, how to interpret them,

and how to get useful information out from the traces. In this example, the post

simulation processes are done in a shell prompt after the simulation.

2.2.4 Simulation Stages

To create new objects, protocols, and routing algorithms or to modify them ns-2 C++

source code has to be changed. The simulator supports wired, wireless(new and old

trace),wired cum wireless. Figure 5shows the ns-2 system architecture on a simple block

diagram. One of the blocks represents Trace graph. With ns-2 comes Network Animator ,

a visualization tool for packets flows. It only shows generated packets movement

as an animation, so this is not enough to do simulation results analysis. The simulator

users have to create their own programs to process the results trace files [1]. The ns-2

output data contains a lot of complicated information about simulation. There are a few
trace file formats and each of them can have various versions, so it can be hard to find out

how to extract necessary data. This is the reason why Trace graph is so useful. It makes

trace file processing very simple.

Fig. 5 Simulation stages

2.2.4.1.1 Trace Files Processing:

.Trace graph supports the following ns-2 trace file formats:

1) wired,
Normal trace format

2)wireless (old and new trace),

Simple wireless
New wireless

NS-2 provides abundant implementations of protocols used in wired and wireless

networks.

2.2.4.1.2 Wired Networks:

A Wired network is a network with physical cables connecting each system together.

Wired networks are almost always faster and less expensive than wireless
networks. Once connected, there is little that can disrupt a good wired connection.

TCP, UDP, multicast are the transportation protocols used in wired networks.

Web, ftp, telnet, CBR, stochastic are the traffic sources used .

In wired networks firstly we create the event scheduler (simulator) and set

up the tracing and then create the network topology and set up the routing. We will

create connection in the transport layer and create the traffic in the application layer and

start the scheduler to postprocess the data.

Advantages over wireless networks:

Throughput - A wired network offers 100Mb/s or 1000Mb/s connection speeds

while a wireless offers only 11Mb/s or 54Mb/s connection speeds.

Non-Shared - network connection speed is independent of one another so multiple

connections do not hinder total throughput of individual network

connections.

Disadvantages over wireless networks:

Many cables - It may be expensive and cumbersome to run many cables between

computer systems. It may also be complicated adding new systems to the

network.

Maintainability - When changes need to be made to the network such as

relocation of computer systems it may be difficult to move the cabling required

for the network.

Mobility - When using a notebook which is required to be connected to the

network a wired network will limit the logical reason of purchasing a notebook in
the first place.
3.4 Constraints: The typical problems we face when trying to run large simulations in ns,

the main constraints being that of memory and cpu-time. Of the different performance

metrics, the three significant ones highlighted here are

1) Start-up time or the time taken before the actual simulation can start,

Start-up time can be defined as the time overhead required before the actual

simulation can start in ns.

The start-up time consists of the following time-slices:

time to parse thru user script, creating topology, traffic etc

time to setup (initializing and configuring ns that consists of:)

o time to reach upto the RouteLogic procedure route-compute {}

o time to parse thru array of links and store link costs

o time to compute the next-hop by routelogic

o time taken to parse thru nodelist and populate each classifier in each node

with the next-hop information

Thus we find that start-up times mainly consist of time taken to compute routes

and create routing tables.

Run-time or how long it takes for the simulation to complete

 Run-time is the time taken for the simulation to complete. The ways to reduce run-time are as

follows:

a. Turn off all tracing like trace-all and namtrace-all if tracing on ALL links

are not required.

b. Several abstraction methods discussed below under "Memory Usage" also

can be applied for reducing run-times as well.

c. Some techniques like pre-filtering, currently at an early stage of

investigation, is expected to result in significant reduction in run-times for

large simulations.

3) Memory requirement for the simulation

One of the most common problem that people face while running large

simulations is running out of memory

Packet-headers in ns

Different types of packet headers are defined for different protocols in ns. And

by default, ns includes ALL these packet headers in EVERY packet in a simulation.

Thus by default each packet-header in ns, by default becomes heavy-weight which will

continue to increase as more protocols are added in ns. One way to significantly reduce

memory requirement, especially for packet intensive large simulations, is to remove

unused packet headers.

4) Ns 2 can only be implemented either in Windows or UNIX , no other operating

system supports this ns2 installation.

5) Our project aims to implement only normal, wired, wireless trace file formats. Satellite

and other formats are not implemented

2.2.4.1.3 Wireless network:

The term wireless networking refers to technology that enables two or more

computers to communicate using standard network protocols, but without network

cabling. Strictly speaking, any technology that does this could be called wireless

networking. In wireless network nodes can move, no explicit links are used to

connect nodes. There are two kinds of wireless networks: There are two kinds of

wireless networks:

2.2.4.1.3.1 Old Wireless Trace format:

Event Abbreviation Type Value

Wireless Event s: Send %.9f %d (%6.2f %6.2f) %3s %4s %d %s %d [%x %x %x
%x]
r: Receive
d: Drop %.9f _%d_ %3s %4s %d %s %d [%x %x %x %x]
f: Forward double Time
int Node ID
double X Coordinate (If Logging Position)
double Y Coordinate (If Logging Position)
string Trace Name
string Reason
int Event Identifier
string Packet Type
int Packet Size
hexadecimal Time To Send Data
hexadecimal Destination MAC Address
 hexadecimal Source MAC Address
hexadecimal Type (ARP, IP)

Wireless traces begin with one of four characters followed by one of two different trace

formats, depending on whether the trace logs the X and Y coordinates of the mobile node.

New Wireless Trace Format

. Similar to the old format, in the new format wireless traces begin with one of four

characters. The first letter of flags with two letters designates the flag type:

N: Node Property

I: IP Level Packet Information

H: Next Hop Information

M: MAC Level Packet Information

P: Packet Specific Information

2.2.3 4.1.3.2 New Wireless Trace Format:

Event Abbreviation Flag Type Value

Wireless s: Send -t double Time (* For Global Setting)
Event r: Receive -Ni int Node ID
d: Drop
f: Forward -Nx double Node X Coordinate
-Ny double Node Y Coordinate
-Nz double Node Z Coordinate
-Ne double Node Energy Level
 Network trace Level (AGT, RTR, MAC,
-Nl string
etc.)
-Nw string Drop Reason
-Hs int Hop source node ID
-Hd int Hop destination Node ID, -1, -2
-Ma hexadecimal Duration
-Ms hexadecimal Source Ethernet Address
-Md hexadecimal Destination Ethernet Address
-Mt hexadecimal Ethernet Type
-P string Packet Type (arp, dsr, imep, tora, etc.)
-Pn string Packet Type (cbr, tcp)

Note that the value for the -Hd flag may be -1 or -2. -1 means that the packet is a

broadcast packet, and -2 means that the destination node has not been set. -2 is typically

seen for packets that are passed between the agent (-Nl AGT) and routing (-Nl RTR)

levels

Depending on the packet type, the following flags may be used:

-Ps int Sequence Number

-Pa int Acknowledgment Number
TCP Trace
-Pf int Number Of Times Packet Was Forwarded
-Po int Optimal Number Of Forwards
-Pi int Sequence Number
CBR Trace -Pf int Number Of Times Packet Was Forwarded
-Po int Optimal Number Of Forwards

3. Requirements:
 3.1 Hardware Requirements:

Processor : Pentium IV or equivalent processor

RAM : 512MB or more

Hard Disk : 6GB or more

3.2 Software Requirements:

Operating System : Windows Xp (sp2), DOS

Software : JAVA, NS2

4. Design Aspects

The designers goal is to produce a model or representation of an entity that will

later be built.
4.1 Basic Idea of Design:

There are two major phases to design any process. The first one is diversification

and the second one is convergence.

Diversification is the acquisition of repertoire of alternatives, the raw materials of

design are components, component solution, and knowledge all contained in catalos,

textbooks, and the mind. During convergence, the designer chooses and combines

appropriate elements from this repertoire to meet design objectives, as stated in

requirements document and as agreed to by the customer. The second phase is the gradual

elimination of all but one particular configuration of components and thus the creation of

the final product. Using one of a number of design methods the design task produces

a data design, an architectural design, an interface design and a component design. The

data design transforms the information domain model created during analysis into data

structures that will be required to implement the software. The architectural design

defines the relationship between major structural elements of the software, the design

patterns that can be used to achieve the requirements that have been defined for the

system, and the constraints that effect the way in which architectural patterns can be

applied. The interface design describes how the software communicates within itself,

with systems that interoperate with it, and with humans who use it. The component level

design transforms structural elements of the software architecture into a procedural

description of software components.

 6.Coding
Trace
file

Read file

Tokenize
Calculate
Collect
Display
Calculate Throughput
Collect Throughput Calculate
Find Calculate
different connections (one wayDisplayThroughput
Throughput (RTT)
sequence
Collect
Display sequence
Collect delay
Calculate
Display
data Collect
CallRTT (delay)
to collect
Display data
data RTT Throughput
RTT data (RTT)
data data
(RTT) data
number
sequencedata delay data data data Delay) data (RTT) data
Options explanation:

TRACE FILE: This is the input for out project

READ FILE: Reads the trace file

 TOKENIZE: Stores the trace file data in temporary arrays .Here we split the trace

information in to tokens based on the number of fields present in the trace file

format specified

FINDDIFFDIELDS: Separates the trace file information and stores the required

fields in a temporary array. And displays them in the list box

CALL TO COLLECT DATA: This method calls the following methods based on

the selected parameters

CALC SEQUENCE NUMBER DATA: This method calls the following

methods

COLLECT SEQUENCE NUMBER DATA : collects the required

data for calculation of sequence number data from the given trace

file and stores in temporary file

DISPLAY SEQUENCE NUMBER DATA The generated temporary

file is used to generate the graph using crystal report

CALC DELAY DATA: This method calls the following methods

COLLECT DELAY DATA: collects the selected fields in list box

from temporary array and check the event field required of delay

data from the given trace file and stores in temporary file
 DISPLAY DELAY DATA: The generated temporary file is used to

generate the graph using crystal report

CALC RTT DATA: This method calls the following methods

COLLECT RTT DATA: collects the required data for calculation of

RTT data from the given trace file and stores in temporary file

DISPLAY RTT DATA: The generated temporary file is used to

generate the graph using crystal report

CALC THRU PUT (ONE WAY): This method calls the following methods

COLLECT THRU PUT (ONE WAY): collects the required data for

calculation of thru put for one way delay data from the given trace

file and stores in temporary file

DISPLAY THRU PUT (ONE WAY): The generated temporary file

is used to generate the graph using crystal report

CALC THRU PUT (RTT): This method calls the following methods
 COLLECT THRU PUT (RTT): collects the required data for

calculation of thru put for RTT data from the given trace file and

stores in temporary file

DISPLAY THRU PUT (RTT): The generated temporary file is used

to generate the graph using crystal report

7. SCREEN SHOTS
Sample trace files

1.1.1. simple wired trace file

+ 0.1 1 2 cbr 1000 ------- 2 1.0 3.1 0 0

- 0.1 1 2 cbr 1000 ------- 2 1.0 3.1 0 0
+ 0.108 1 2 cbr 1000 ------- 2 1.0 3.1 1 1
- 0.108 1 2 cbr 1000 ------- 2 1.0 3.1 1 1
r 0.114 1 2 cbr 1000 ------- 2 1.0 3.1 0 0
+ 0.114 2 3 cbr 1000 ------- 2 1.0 3.1 0 0
- 0.114 2 3 cbr 1000 ------- 2 1.0 3.1 0 0
+ 0.116 1 2 cbr 1000 ------- 2 1.0 3.1 2 2
- 0.116 1 2 cbr 1000 ------- 2 1.0 3.1 2 2
r 0.122 1 2 cbr 1000 ------- 2 1.0 3.1 1 1
+ 0.122 2 3 cbr 1000 ------- 2 1.0 3.1 1 1
- 0.122 2 3 cbr 1000 ------- 2 1.0 3.1 1 1
+ 0.124 1 2 cbr 1000 ------- 2 1.0 3.1 3 3
- 0.124 1 2 cbr 1000 ------- 2 1.0 3.1 3 3
r 0.13 1 2 cbr 1000 ------- 2 1.0 3.1 2 2
+ 0.13 2 3 cbr 1000 ------- 2 1.0 3.1 2 2
- 0.13 2 3 cbr 1000 ------- 2 1.0 3.1 2 2
+ 0.132 1 2 cbr 1000 ------- 2 1.0 3.1 4 4
- 0.132 1 2 cbr 1000 ------- 2 1.0 3.1 4 4
r 0.138 1 2 cbr 1000 ------- 2 1.0 3.1 3 3
+ 0.138 2 3 cbr 1000 ------- 2 1.0 3.1 3 3
- 0.138 2 3 cbr 1000 ------- 2 1.0 3.1 3 3
r 0.138706 2 3 cbr 1000 ------- 2 1.0 3.1 0 0
+ 0.14 1 2 cbr 1000 ------- 2 1.0 3.1 5 5
- 0.14 1 2 cbr 1000 ------- 2 1.0 3.1 5 5
r 0.146 1 2 cbr 1000 ------- 2 1.0 3.1 4 4
+ 0.146 2 3 cbr 1000 ------- 2 1.0 3.1 4 4
- 0.146 2 3 cbr 1000 ------- 2 1.0 3.1 4 4
r 0.146706 2 3 cbr 1000 ------- 2 1.0 3.1 1 1
+ 0.148 1 2 cbr 1000 ------- 2 1.0 3.1 6 6
- 0.148 1 2 cbr 1000 ------- 2 1.0 3.1 6 6
r 0.154 1 2 cbr 1000 ------- 2 1.0 3.1 5 5
+ 0.154 2 3 cbr 1000 ------- 2 1.0 3.1 5 5
- 0.154 2 3 cbr 1000 ------- 2 1.0 3.1 5 5
r 0.154706 2 3 cbr 1000 ------- 2 1.0 3.1 2 2
+ 0.156 1 2 cbr 1000 ------- 2 1.0 3.1 7 7
- 0.156 1 2 cbr 1000 ------- 2 1.0 3.1 7 7
r 0.162 1 2 cbr 1000 ------- 2 1.0 3.1 6 6
+ 0.162 2 3 cbr 1000 ------- 2 1.0 3.1 6 6
- 0.162 2 3 cbr 1000 ------- 2 1.0 3.1 6 6
r 0.162706 2 3 cbr 1000 ------- 2 1.0 3.1 3 3
+ 0.164 1 2 cbr 1000 ------- 2 1.0 3.1 8 8

imple wireless trace file

s 0.267662078 _0_ RTR --- 0 message 32 [0 0 0 0] ------- [0:255 -1:255
32 0]
s 1.511681090 _1_ RTR --- 1 message 32 [0 0 0 0] ------- [1:255 -1:255
32 0]
M 10.00000 0 (5.00, 2.00, 0.00), (20.00, 18.00), 1.00
s 10.000000000 _0_ AGT --- 2 tcp 40 [0 0 0 0] ------- [0:0 1:0 32 0] [0
0] 0 0
r 10.000000000 _0_ RTR --- 2 tcp 40 [0 0 0 0] ------- [0:0 1:0 32 0] [0
0] 0 0
s 13.520299645 _0_ RTR --- 3 message 32 [0 0 0 0] ------- [0:255 -1:255
32 0]
s 15.315262986 _1_ RTR --- 4 message 32 [0 0 0 0] ------- [1:255 -1:255
32 0]
s 16.000000000 _0_ AGT --- 5 tcp 40 [0 0 0 0] ------- [0:0 1:0 32 0] [0
0] 0 0
r 16.000000000 _0_ RTR --- 5 tcp 40 [0 0 0 0] ------- [0:0 1:0 32 0] [0
0] 0 0
s 94.278068529 _0_ RTR --- 20 message 32 [0 0 0 0] ------- [0:255
-1:255 32 0]
r 94.278504547 _1_ RTR --- 20 message 32 [0 ffffffff 0 800] -------
[0:255 -1:255 32 0]
M 100.00000 1 (25.00, 20.00, 0.00), (490.00, 480.00), 15.00
s 100.000000000 _0_ AGT --- 21 tcp 40 [0 0 0 0] ------- [0:0 1:0 32 0]
[0 0] 0 0
r 100.000000000 _0_ RTR --- 21 tcp 40 [0 0 0 0] ------- [0:0 1:0 32 0]
[0 0] 0 0
s 100.000000000 _0_ RTR --- 21 tcp 60 [0 0 0 0] ------- [0:0 1:0 32 1]
[0 0] 0 0
r 100.000936054 _1_ AGT --- 21 tcp 60 [a2 1 0 800] ------- [0:0 1:0 32
1] [0 0] 1 0
s 100.000936054 _1_ AGT --- 22 ack 40 [0 0 0 0] ------- [1:0 0:0 32 0]
[0 0] 0 0
r 100.000936054 _1_ RTR --- 22 ack 40 [0 0 0 0] ------- [1:0 0:0 32 0]
[0 0] 0 0
s 100.000936054 _1_ RTR --- 22 ack 60 [0 0 0 0] ------- [1:0 0:0 32 0]
[0 0] 0 0
r 100.001984108 _0_ AGT --- 22 ack 60 [a2 0 1 800] ------- [1:0 0:0 32
0] [0 0] 1 0
s 100.001984108 _0_ AGT --- 23 tcp 1000 [0 0 0 0] ------- [0:0 1:0 32
0] [1 0] 0 0
r 100.001984108 _0_ RTR --- 23 tcp 1000 [0 0 0 0] ------- [0:0 1:0 32
0] [1 0] 0 0
s 100.001984108 _0_ RTR --- 23 tcp 1020 [0 0 0 0] ------- [0:0 1:0 32
1] [1 0] 0 0
s 100.001984108 _0_ AGT --- 24 tcp 1000 [0 0 0 0] ------- [0:0 1:0 32
0] [2 0] 0 0
r 100.001984108 _0_ RTR --- 24 tcp 1000 [0 0 0 0] ------- [0:0 1:0 32
0] [2 0] 0 0
s 100.001984108 _0_ RTR --- 24 tcp 1020 [0 0 0 0] ------- [0:0 1:0 32
1] [2 0] 0 0
r 100.006992162 _1_ AGT --- 23 tcp 1020 [a2 1 0 800] ------- [0:0 1:0
32 1] [1 0] 1 0
s 100.006992162 _1_ AGT --- 25 ack 40 [0 0 0 0] ------- [1:0 0:0 32 0]
[1 0] 0 0

Observed outputs
This is the output obtained for the parameter one way delay Vs time
This is the output obtained for the parameter sequence number Vs time
This is the output obtained for the parameter RTT Vs time
This is the output obtained for the parameter Throughput (RTT) Vs time
This is the output obtained for the parameter Throughput(one way delay) Vs
time
DATA PRESENTATION

Simulation results can be analysed with the following graphs:

Cumulative sums of numbers of generated/sent/received/forwarded/dropped packets

or bytes vs. time,
Throughput of generating/sending/receiving/forwarding/dropping packets or bits vs.
time,
Packet size vs. minimal/average/maximal throughput of
generating/sending/receiving/forwarding/dropping packets or bits,
Packet ID or send/receive event time vs. jitter,
Throughput of sending/receiving bits vs. minimal/average/maximal delay,
Throughput of sending/receiving bits vs. minimal/average/maximal jitter,
Throughput of forwarding/receiving bits vs. minimal/average/maximal processing
time,
Throughput of sending bits vs. minimal/average/maximal Round Trip Time,
send/receive event time vs. number of intermediate nodes forwarding/receiving
packet,
Packet ID vs. generate/send/receive/forward/drop event time,
Packet sequence number vs. generate/send/receive/forward/drop event time,
Packet size vs. minimal/average/maximal delay,
Packet size vs. minimal/average/maximal processing time,
Packet size vs. minimal/average/maximal Round Trip time,
delay/jitter/processing time/RTT cumulative distribution,
delay/jitter/processing time/RTT frequency distribution,
Packet ID or send/receive event time vs. delay,
Packet ID or forward/receive event time vs. processing time,
Packet ID or send/receive event time vs. RTT,
3D graphs numbers of generated/sent/forwarded/received/dropped/lost packets or
bytes at all the nodes.

6. EXPANDING SYSTEM CAPABILITIES

Trace graph architecture enables implementing new system functions very easy. For
example adding a new graph can take only 10 minutes. The system could be expanded to
read other trace file formats like real network traces, e.g. a trace format converter could
be created for conversion to Trace graph format. Nodes movements with packets flows
2D/3D visualization could be added. More parameters from trace files could be used for
new graphs implementation. MATLAB environment enables to develop the system very
easy and very fast.
Future Work:

Simulation results can be analysed with the following graphs also:

cumulative sums of numbers of generated/sent/received/forwarded/dropped

packets or bytes vs. time,

throughput of generating/sending/receiving/forwarding/dropping packets or bits

vs. time,

packet size vs. minimal/average/maximal throughput of

generating/sending/receiving/forwarding/dropping packets or bits,

packet ID or send/receive event time vs. jitter,

throughput of sending/receiving bits vs. minimal/average/maximal delay,

throughput of sending/receiving bits vs. minimal/average/maximal jitter,

throughput of forwarding/receiving bits vs. minimal/average/maximal

processing time,
throughput of sending bits vs. minimal/average/maximal Round Trip Time,

send/receive event time vs. number of intermediate nodes forwarding/receiving

packet,

packet ID vs. generate/send/receive/forward/drop event time,

packet sequence number vs. generate/send/receive/forward/drop event time,

packet size vs. minimal/average/maximal delay,

packet size vs. minimal/average/maximal processing time,

packet size vs. minimal/average/maximal Round Trip time,

delay/jitter/processing time/RTT cumulative distribution,

delay/jitter/processing time/RTT frequency distribution,

packet ID or send/receive event time vs. delay,

packet ID or forward/receive event time vs. processing time,

packet ID or send/receive event time vs. RTT,