Saturday, 16 March 2013

NS-3

NS-3

        Work on ns-3 began in the 2004-05 timeframe. A team led by Tom Henderson (University of Washington), and also including George Riley (Georgia Tech), Sally Floyd (International Computer Science Institute), and Sumit Roy (University of Washington), applied for and received funding from the U.S. National Science Foundation (NSF) to build a replacement for ns-2, called ns-3. Around the same time, the Planete research team at INRIA Sophia Antipolis, including principally Mathieu Lacage and Walid Dabbous, began to explore a replacement for ns-2, with an initial emphasis on IEEE 802.11 Wi-Fi models. Lacage's initial simulator was named Yet Another Network Simulator (yans).

             The two efforts combined, and discussions on the design of ns-3 started on the ns-developers mailing list in February 2005. Specifically, on February 22, 2005, Tom Henderson made a post on ns-developers mailing list saying We intend to have some discussions on how some of ns-2 might be either refactored or forked as part of a future development effort (in parallel, for now, with maintenance of the existing code tree). Some of the main goals included building better support for network emulation and reuse of implementation code, to better integrate the tool with testbed-based research. In the process of developing ns-3, it was decided to abandon backward-compatibility with ns-2, mainly due to the high maintenance overhead that would have resulted. The new simulator would be written from scratch, using the C++ programming language.
Development of ns-3 began on July 1, 2006.The software core was largely written by Mathieu Lacage, borrowing also from the yans simulator, the Georgia Tech Network Simulator (GTNetS) built by George Riley, and ns-2. A framework for generating Python bindings (pybindgen) and use of the Waf build system were contributed by Gustavo Carneiro.
The first release, ns-3.1 was made in June 2008, and afterwards the project continued making quarterly software releases, and more recently has moved to three releases per year. ns-3 made its fifteenth release (ns-3.15) in the third quarter of 2012.
Current status of the three versions is:
  • ns-1 is no longer developed nor maintained,
  • ns-2 is only maintained, and
  • ns-3 is actively developed.

Design

         ns-3 is built using C++ and Python and scripting is available with both languages. The ns-3 library is wrapped to python thanks to the pybindgen library which delegates the parsing of the ns-3 C++ headers to gccxml and pygccxml to generate automatically the corresponding C++ binding glue. These automatically-generated C++ files are finally compiled into the ns-3 python module to allow users to interact with the C++ ns-3 models and core through python scripts.

NS3

NS3

        Work on ns-3 began in the 2004-05 timeframe. A team led by Tom Henderson (University of Washington), and also including George Riley (Georgia Tech), Sally Floyd (International Computer Science Institute), and Sumit Roy (University of Washington), applied for and received funding from the U.S. National Science Foundation (NSF) to build a replacement for ns-2, called ns-3. Around the same time, the Planete research team at INRIA Sophia Antipolis, including principally Mathieu Lacage and Walid Dabbous, began to explore a replacement for ns-2, with an initial emphasis on IEEE 802.11 Wi-Fi models. Lacage's initial simulator was named Yet Another Network Simulator (yans).

             The two efforts combined, and discussions on the design of ns-3 started on the ns-developers mailing list in February 2005. Specifically, on February 22, 2005, Tom Henderson made a post on ns-developers mailing list saying We intend to have some discussions on how some of ns-2 might be either refactored or forked as part of a future development effort (in parallel, for now, with maintenance of the existing code tree). Some of the main goals included building better support for network emulation and reuse of implementation code, to better integrate the tool with testbed-based research. In the process of developing ns-3, it was decided to abandon backward-compatibility with ns-2, mainly due to the high maintenance overhead that would have resulted. The new simulator would be written from scratch, using the C++ programming language.
Development of ns-3 began on July 1, 2006.The software core was largely written by Mathieu Lacage, borrowing also from the yans simulator, the Georgia Tech Network Simulator (GTNetS) built by George Riley, and ns-2. A framework for generating Python bindings (pybindgen) and use of the Waf build system were contributed by Gustavo Carneiro.
The first release, ns-3.1 was made in June 2008, and afterwards the project continued making quarterly software releases, and more recently has moved to three releases per year. ns-3 made its fifteenth release (ns-3.15) in the third quarter of 2012.
Current status of the three versions is:
  • ns-1 is no longer developed nor maintained,
  • ns-2 is only maintained, and
  • ns-3 is actively developed.

Design

         ns-3 is built using C++ and Python and scripting is available with both languages. The ns-3 library is wrapped to python thanks to the pybindgen library which delegates the parsing of the ns-3 C++ headers to gccxml and pygccxml to generate automatically the corresponding C++ binding glue. These automatically-generated C++ files are finally compiled into the ns-3 python module to allow users to interact with the C++ ns-3 models and core through python scripts.

Routing protocol in NS2

Routing protocol


  • A formula used by routers to determine the appropriate path ontowhich data should be forwarded
  • It also specifies how routers report changes and share information with the other routers in the network that they can reach
  •  This decides whether the network should dynamically adjust tochanging conditions, otherwise all routing decisions have to be predetermined and remain static
  •  NS2 can simulate both static and dynamic techniques


Approaches to routing

 Static routing

  • Routing table is created when a router boots for first time.Once decided, the route cannot be altered
  •  Network problems such as link down, congested router cannot be solved

Dynamic routing

  •  The routing table is created with initial routing decisions and updates itself when there is a change in network condition
  •  This is clearly better but complex than static routing

 

Routing Algorithm

To calculate shortest path between two routers:
  •  Knowledge about the whole network
  •  Sharing information with neighbors
i) Periodic sharing
ii) Share when network has any changes

Types:

1) Distance vector routing
2) Link state routing


Distance Vector routing

  • Uses Bellman-ford algorithm to calculate path
  •  Suitable for small and medium sized network
  •  Calculates path based on link cost
  •  Routing based on calculating the direction and distance to any link in a network
  •  Direction refers to a port that leads to the next router along the path to the destination, and distance is a metric that indicates the number of hops to the destination


 Link state routing

  •  Information is exchanged about its neighborhood with all other routers in the network
  • Sharing the information is called flooding.
  •  Sharing period interval is much longer (say for DVR is 30 secs, in LSR is 30 min)
  •  Packet cost based on security levels, traffic, state of the link

Routing schemes

  •  Classification is based on Message Delivery Semantics
  •  Unicast – to single specified node by the host
  •  Multicast – to a group of nodes that have expressed interest in receiving messages
  •  Broadcast – to all nodes in the network

Routing in NS-2

Routing protocol


  • A formula used by routers to determine the appropriate path ontowhich data should be forwarded
  • It also specifies how routers report changes and share information with the other routers in the network that they can reach
  •  This decides whether the network should dynamically adjust tochanging conditions, otherwise all routing decisions have to be predetermined and remain static
  •  NS2 can simulate both static and dynamic techniques


Approaches to routing

 Static routing

  • Routing table is created when a router boots for first time.Once decided, the route cannot be altered
  •  Network problems such as link down, congested router cannot be solved

Dynamic routing

  •  The routing table is created with initial routing decisions and updates itself when there is a change in network condition
  •  This is clearly better but complex than static routing

 

Routing Algorithm

To calculate shortest path between two routers:
  •  Knowledge about the whole network
  •  Sharing information with neighbors
i) Periodic sharing
ii) Share when network has any changes

Types:

1) Distance vector routing
2) Link state routing


Distance Vector routing

  • Uses Bellman-ford algorithm to calculate path
  •  Suitable for small and medium sized network
  •  Calculates path based on link cost
  •  Routing based on calculating the direction and distance to any link in a network
  •  Direction refers to a port that leads to the next router along the path to the destination, and distance is a metric that indicates the number of hops to the destination

 Link state routing

  •  Information is exchanged about its neighborhood with all other routers in the network
  • Sharing the information is called flooding.
  •  Sharing period interval is much longer (say for DVR is 30 secs, in LSR is 30 min)
  •  Packet cost based on security levels, traffic, state of the link
 

Routing schemes

  •  Classification is based on Message Delivery Semantics
  •  Unicast – to single specified node by the host
  •  Multicast – to a group of nodes that have expressed interest in receiving messages
  •  Broadcast – to all nodes in the network

Friday, 15 March 2013

Installing ZRP protocol in NS2

  •             The general suggestion is not to use Ubuntu 11.10 (or 11.04) for NS2.
If you must use Ubuntu, then version 10.04 will do. The default OS for ns2 is CentOS 5.7
( All ns2 versions were created and tested on CentOS / RHEL.)

 But : You can have as many versions of ns2 as you want, installed at the same time.
Just do not add any of them to a PATH*.

  •               No ns-2.33 or any other version ns-2.27.....2.34 can be installed on Ubuntu 11.10.



Steps
-------
1-  First  put (ns-allinone-2.33_ZRP.tar.gz , PatchZRP.patch and patchmyZRP.sh) in Ns-allinone-2.33 directory.

2-  Give this command:  cd ns-allinone-2.33/ && patch -p1 < PatchZRP.patch

3- Give this one:  touch ns-2.33/common/packet.h && touch ns-2.33/trace/cmu-trace.h

4- Go to Ns-allinone-2.33 and give this command: tar xvf ns-allinone-2.33_ZRP.tar.gz

5- Go to Ns-allinone-2.33/ns-2.33 and I give this: make -k 

ZRP patching on Ns-2.33

  •             The general suggestion is not to use Ubuntu 11.10 (or 11.04) for ns2.
If you must use Ubuntu, then version 10.04 will do. The default OS for ns2 is CentOS 5.7
( All ns2 versions were created and tested on CentOS / RHEL.)

 But : You can have as many versions of ns2 as you want, installed at the same time.
Just do not add any of them to a PATH*.

  •               No ns-2.33 or any other version ns-2.27.....2.34 can be installed on Ubuntu 11.10.



Steps
-------
1-  First  put (ns-allinone-2.33_ZRP.tar.gz , PatchZRP.patch and patchmyZRP.sh) in Ns-allinone-2.33 directory.

2-  Give this command:  cd ns-allinone-2.33/ && patch -p1 < PatchZRP.patch

3- Give this one:  touch ns-2.33/common/packet.h && touch ns-2.33/trace/cmu-trace.h

4- Go to Ns-allinone-2.33 and give this command: tar xvf ns-allinone-2.33_ZRP.tar.gz

5- Go to Ns-allinone-2.33/ns-2.33 and I give this: make -k 

Sunday, 13 November 2011

X-graph in NS2 - xgraph for throughput -xgraph from trace file - xgraph command

Xgraph is easy and very Useful.

Xgraph in NS2
  •  Xgraph draws a graph on a Display device.
  • Display upto 64 Independent data sets using  different colors
  • The input data can be read from either data file or from standard input if no files are specified
  • It annotates the graph with a title, axis labels grid lines or tick marks, grid labels, and  legend.
Windows Interface
  • The interface used to specify the size and location of this window depends on the window manager currently in use.
  • Once the window has been opened, all of the data sets will be displayed graphically with a legend in the upper right corner of the screen.
  • Xgraph also presents three control buttons in the upper left corner of each window.
Xgraph command options       
  • -geometry WxH (Geometry)
  •  Specifies the initial size and location of the Xgraphwindow.
  •  -bar (BarGraph) Specifies that vertical bars should be drawn from the data points to a base point which can be specified with -brb.
  •  -brb <base> (BarBase) 
  •  This specifies the base for a bar graph. By default, the base is zero.
  • -brw <width> (BarWidth)
  •  This specifies the width of bars in a bar graph. The amount is specified in the user’s units. By default, a bar one pixel wide is drawn.
Xgraph Command:Execution
  • xgraph DataFile.txt –geometry 400x400,  Here DataFile.txt can be Replaced with trace file generated from Ns-2.this command will show the graph using X and Y co-ordinates with Geometry of 400X400
  • xgraph DataFile.txt –geometry 400x400 –bar –brb 2 –brw 0.5 –tk –bb –nl –bg white –t “Example_Xgraph” –x “Xaxis” –y “Yaxis” . This command will generate Bar Graph.
  • Xgraph DataFile.txt DataFile2.txt –bg white –tk –bb –m -M –t “Marker” –geometry  800x400.This command used to compare the two Files and generated graph
Awk and Xgraph
  • Awk programming is used to generate the detailed analysis of NS-2 trace file.
  • Metric's like Throughput,end-to-end Delay,Jitter,NRL,Packet Delivery ratio can be calculated using Awk scripts. Generate output's  by changing scenario files.
  • Keep these outputs in a Text file in the Form of X and Y co-ordinates .for example, you can keep No_of _mobile nodes on X-axis and PDF on Y-axis. 
Xgraph of two Trace files in NS2
  • Xgraph can generated using Two files .This graph will show the comparison of two files with different data 
  • command :Xgraph DataFile.txt DataFile2.txt –bg white –tk –bb –m -M –t “Marker” –geometry  800x400
  • Like wise One can compare two Routing Protocols and evaluate the best among them. For example comparison of AODV performance with DSDV in MANET. 
Sample Xgraph Generation ---->Node size vs PDR 

  • Create a text file named  PDRvsNODE.txt and keep the data as like the below format .First column represent node size, (5 ,10,20,30,40,50) and 2 nd column specifies pdr that you got after running pdr.awk scipt for no of nodes set in your tcl file . Location of the text file need to specified clearly while you are running the command.

5  99.5
10 99.7
20 99.0
30 95.6
40 94.8
50 95.9



Once you created text file and kept this data ,Run the command 

Xgraph PDRvsNODE.txt   –bg white –tk –bb –m -M –t “Marker” –geometry  800x400


That's it!!! You arrived your destination successfully.