STEPS TO INSTALL NS2 ON MAC

Now a days, MAC OS conquering the world. So it is needed to adapt software to be compatible with MAC OS. Older NS2 versions are not compatible with this and also installing is little bit harder because of necessity of setting and configuring too many setup and configuration files. But after researches and latest upgrades, it is easy to install new version of ns2[ns2.35 RC8] on mac os.  For installing ns2, we need a developer package called as "XCODE". And we can download it easily from apple developer website http://developer.apple.com/xcode/ 

So, first download xcode and after that download NS2 version from following link; http://www.isi.edu/nsnam/dist/release-2.35/RC8/

Installation Steps

1. Download and install xcode.

2. Download ns-2.35-RC8.tar.gz.and untar it using command.

3. Execute the command ./install inside the directory i.e 

    cd Desktop  
    cd ns-allinone-2.35-RC8
    ./install

The installation procedure will take a few minutes..........

4. After compleating the installation type the following command in the command window

    gedit ~/.bashrc

5. Now an editor window appears,please copy and paste the follwing codes

export PATH=$PATH:/home/user/Desktop/ns-allinone-2.35-RC8/bin:/home/user/Desktop/ns-allinone-2.35-RC8/tcl8.5.8/unix:/home/user/Desktop/ns-allinone-2.35-RC8/tk8.5.8/unix

and also one more path called LD_LIBRARY_PATH
export LD_LIBRARY_PATH= <paths>

6. Save and close the text editor and then type the following command on the terminal

    source ~/.bashrc

7. Close the terminal window and start a new terminal window and now change the directory to ns-2.35 and validate ns-2.35 by exicuting the following command ( it takes 30 to 45 minutes)

    cd ns-2.35
    ./validate

8.  If the installation is successful, then you will be able to see % at the command prompt while typing the following command

    ns

9. Now type

    exit

CONTIKIi OS WITH COOJA SIMULATOR: A Framework For IOT Simulation

Contiki is an open source OS for networked and memory constrained systems with a focus on low power wireless Internet of things devices. It mainly deals with tiny low cost micro controllers and sensors which are connect to the internet. The major use of contiki is that street lighting systems, sound monitoring for smart cities, radiation monitoring systems, and alarm systems. Contiki is preffered because it supports various internet standards , dedicated hardwares, rapid developments, active community for help and also big commercial and customer support with open source licence. This was created by Adam Dunkels in 2002 and further development were done by Texas Instruments, Atmel, Cisco, ENEA, ETH Zurich, Redwire, RWTH Aachen University, Oxford University, SAP, Sensinode, Swedish Institute of Computer Science, ST Microelectronics, Zolertia, and many others. The name Contiki comes from Thor Heyerdahl's famous Kon-Tiki raft. Despite providing multitasking and a built-in TCP/IP stack, Contiki only needs about 10 kilobytes of RAM and 30 kilobytes of ROM. A full system, complete with a graphical user interface, needs about 30 kilobytes of RAM.

Instant Contiki is an entiredevelopment environment for contiki and it is a linux based virtual machine and that runs in VMWare Player. It has development tools, compilers, and simulators used in Contiki development installed. In real, contiki is a complex software, but cooja and instant contiki make it simple to install and start with.

For more, Click here

SETTING UP TINYOS AND NS2 IN UBUNTU-BASED SYSTEMS

TinyOS is an open source software component-based operating system and platform targeting wireless sensor networks (WSNs). TinyOS is an embedded operating system written in the nesC programming language as a set of cooperating tasks and processes. It is intended to be incorporated into smartdust. TinyOS started as a collaboration between the University of California, Berkeley in co-operation with Intel Research and Crossbow Technology, and has since grown to be an international consortium, the TinyOS Alliance.

INSTALL TINY OS

To get a copy of TinyOs and its dependencies.
sudo apt-add-repository "deb http://tinyos.stanford.edu/tinyos/dists/ubuntu natty main"
apt-get update
apt-get install tinyos-2.1.2 python-dev automake subversion g++

Now we have the dependencies we can get a more up-to-date version.
cd ~
mkdir -p local/src
cd local/src
svn checkout http://tinyos-main.googlecode.com/svn/trunk/ tinyos-2.x

cd tinyos-2.x/tools
./Bootstrap
./configure --prefix=$HOME/local
make all
make install

Add to bottom of .profile
export PATH=$HOME/local/bin:$PATH
export TOSROOT=$HOME/local/src/tinyos-2.x
export TOSDIR=$TOSROOT/tos
export MAKERULES=$TOSROOT/support/make/Makerules
export CLASSPATH=$TOSROOT/support/sdk/java/tinyos.jar:.
export PYTHONPATH=.:$TOSROOT/support/sdk/python:$PYTHONPATH
export PATH=$TOSROOT/support/sdk/c:$PATH
export MOTECOM=serial@/dev/ttyUSB0:115200

For AODV
Extract system and interfaces from NST-AODV.tar.gz into ~/local/src/tinyos-2.x/tos
Extract libraries into ~/local/src/tinyos-2.x/tos/system

Copy over modified files
To reject packets with failed CRC errors
Modify $TOSROOT/support/sdk/python/tos.py
if crc != packet_crc:
    print "Warning: wrong CRC! %x != %x %s" % (crc, packet_crc, ["%2x" % i for i in packet])
    return None

For permission to write to the USB port
sudo usermod -a -G dialout USERNAME

Errors

Fatal error: Python.h
If you get /opt/tinyos-2.1.1/tos/lib/tossim/tossim_wrap.cxx:139:20: fatal error: Python.h: No such file or directory compilation terminated.
Change PYTHON_VERION from 2.5 to 2.7 in /opt/tinyos-2.1.1/support/make/sim.extra

No permissions to write to the USB port
Either just chmod 777 the USB port, however this needs to be done each time the device is plugged in or you can add the current user to the dialout group.

NST-AODV
In AODV.h put "#include <message.h>"
Make sure the code you are compiling has "component PrintfC"

Contiki

Install guide

Summary of https://github.com/g-oikonomou/contiki-sensinode/wiki/Prepare-your-System
Grab the latest tarball of the SDCC source from http://sourceforge.net/projects/sdcc/files/snapshot_builds/sdcc-src/ and extract the folder somewhere. Now do the following.
cd SDCC
wget https://github.com/g-oikonomou/contiki-sensinode/wiki/contiki-sdcc.patch
patch -p0 < contiki-sdcc.patch
sudo apt-get install libboost-graph-dev flex bison
./configure --disable-gbz80-port --disable-z80-port --disable-ds390-port --disable-ds400-port --disable-pic14-port --disable-pic16-port --disable-hc08-port --disable-r2k-port --disable-z180-port --disable-sdcdb --disable-ucsim
make
sudo make install
cd ..
git clone https://github.com/g-oikonomou/contiki-sensinode.git
cd contiki-sensinode/examples/cc2530dk/
make

All done!

NS-2

I have currently implemented a Ns-2 application, aimed to connect Ns-2 which is written in C++ and Tcl to Python in order to provide a simple way to develop scenarios.

Ubuntu 10.10 Installation
If it cant find sources add 'deb-src http://uk.archive.ubuntu.com/ubuntu/ oneiric universe' to '/etc/apt/sources.list'.
sudo apt-get build-dep ns2
apt-get source ns2
cd ns2-2.35~RC6
gedit ./common/mobilenode.cc
gedit Makefile.in
./configure
make

Self-Defined Packets
Some programming tips for applications which are defining their own packet structures is to include 'agent_->set_pkttype(PT_CBR);' into the body of the application. I think this is only needed if the underlying agent is UDP, as this will tag all the packet types as UDP, which are classified as non-data packets, and thus will not cause routing protocols such as AODV to attempt route recovery.
802.15.4 Broadcast Bug
Another interesting bug that I found was when causing 20 nodes in the same proximity to broadcast at the exact same instant, whilst using the 802.15.4 physical layer.
This causes a 'Program received signal SIGFPE, Arithmetic exception' error, which is at 'lq = (int)(tmpf * 128);' in 'wpan/p802_15_4phy.cc:499'.
The line before this calculates tmpf which is 'tmpf = p->txinfo_.RxPr/RXThresh_;', with RxPr being in watts (according to here).
Normally this is around 0.000192w, but in this case jumps to 0.281838w, which then causes an error when later cast to an integer. This could perhaps be fixed by checking the overflow condition first, however simply removing the highly unlikely simultaneous broadcasting should do the trick.
802.15.4 AODV Sending Limit
So all seems well, however after some time my simulations just stopped receiving packets. This was interesting as it's the same sequence of data being sent at the same time intervals every period. After some investigation I found a way to make the simulation work, but I'm not sure of the side effects.
In p802_15_4phy.cc, on line 509 do a check to see if HDR_LRWPAN(p)->rxTotPower == 0 and if it is set lq2 to 255. This is due to the following step sometimes causing a division by 0 error on this line.
In the same file, on line 772 override the "else if (p != rxPkt)" by putting && false in the if, or similar. According to the comment this section checks if the packet is corrupted or un-detectable, so this modification will most likely have side effects, but for now it works.
Other Fixes
For the random TCL error below when using 802.11 comment out 'tcl.evalf("%s reset-state", str);' at common/mobilenode.cc:205
_o1725 off
ns: _o1728 reset-state: 
(_o1728 cmd line 1)
invoked from within
"_o1728 cmd reset-state"
invoked from within
"catch "$self cmd $args" ret"
invoked from within
"if [catch "$self cmd $args" ret] {
set cls [$self info class]
global errorInfo
set savedInfo $errorInfo
error "error when calling class $cls: $args" $..."
(procedure "_o1728" line 2)
(SplitObject unknown line 2)
invoked from within
"_o1728 reset-state"
Still working on the remaining 802.15.4 errors.
Quick install guide
apt-get source ns2
apt-get package-dep ns2
gedit ns.../common/mobilenode.cc
gedit Makefile.in
./configure
make

For More: Click here
For TinyOS Programming, Click here

CONGESTION WINDOW "cwnd" IN NS2

In TCP Networks, the most important factor that determines behavior is its congestion window size. In NS2, we can handle it with using cwnd command. In NS, every TCP type classes have a variable named "cwnd" that contains the congestion window size of the TCP Module. In here we can use 'set' command to return a value. 

We can write it as;

set  tcp1  [new  Agent/TCP/Reno]

set  cwnd1  [ $tcp1  set  cwnd_ ]

To obtain TCP's CWND value frquently;

• We can easily make the NS simulation system repeatedly read the value (say, after every 0.1 sec of simulation time).
• Schedule a read operation repeatedly

Proc plotWindow {tcpSource outfile} {

     global ns

     set now [$ns now]

     set cwnd [$tcpSource set cwnd_]

  #  Print TIME CWND   for  gnuplot to plot progressing on CWND   

     puts  $outfile  "$now $cwnd"

     $ns at [expr $now+0.1] "plotWindow  $tcpSource  $outfile"

  }

• The procedure plotWindow takes a paramter tcpSource which is a TCP agent.So you can use the procedure to plot the CWND from any number of TCP flows.

• The procedure plotWindow takes an output file ID outfile.You should first open an output file (or use "stdout") in the main program.

Examining progressing of CWND in TCP (Reno)

#Make a NS simulator   

  set ns [new Simulator]

  # Define a 'finish' procedure

  proc finish {} {

     exit 0

  }

  # Create the nodes:

  set n0 [$ns node]

  set n1 [$ns node]

  set n2 [$ns node]

  set n3 [$ns node]

  set n4 [$ns node]

  set n5 [$ns node]

  # Create the links:

  $ns duplex-link $n0 $n2   2Mb  10ms DropTail

  $ns duplex-link $n1 $n2   2Mb  10ms DropTail

  $ns duplex-link $n2 $n3 0.3Mb 200ms DropTail

  $ns duplex-link $n3 $n4 0.5Mb  40ms DropTail

  $ns duplex-link $n3 $n5 0.5Mb  30ms DropTail

  # Add a TCP sending module to node n0

  set tcp1 [new Agent/TCP/Reno]

  $ns attach-agent $n0 $tcp1

  # Add a TCP receiving module to node n4

  set sink1 [new Agent/TCPSink]

  $ns attach-agent $n4 $sink1

  # Direct traffic from "tcp1" to "sink1"

  $ns connect $tcp1 $sink1

  # Setup a FTP traffic generator on "tcp1"

  set ftp1 [new Application/FTP]

  $ftp1 attach-agent $tcp1

  $ftp1 set type_ FTP               (no necessary)

  # Schedule start/stop times

  $ns at 0.1   "$ftp1 start"

  $ns at 100.0 "$ftp1 stop"

  # Set simulation end time

  $ns at 125.0 "finish"    (Will invoke "exit 0")   

  ##################################################

  ## Obtain CWND from TCP agent

  ##################################################

  proc plotWindow {tcpSource outfile} {

     global ns

     set now [$ns now]

     set cwnd [$tcpSource set cwnd_]

  ###Print TIME CWND   for  gnuplot to plot progressing on CWND

     puts  $outfile  "$now $cwnd"

     $ns at [expr $now+0.1] "plotWindow $tcpSource  $outfile"

  }

  $ns  at  0.0  "plotWindow $tcp1  stdout"   // Start the probe !!    

  # Run simulation !!!!

  $ns run

his NS Prog prints the (time, cwnd) to the terminal: click here

This NS Prog prints the (time, cwnd) to the output file "WinFile": click here

To plot the window progressing from "winfile", do:

UNIX>> gnuplot

gnuplot>> plot "WinFile" using 1:2 title "Flow 1" with lines 1

Note:

In case you wonder why the cwnd plot look so different, It's because the setting of some parameters.

Add the following statements to the simulation to get the one I used in class:

  # ########################################################

  # Set Queue Size of link (n2-n3) to 10 (default is 50 ?)

  # ########################################################

  $ns queue-limit $n2 $n3 10

  # ########################################################

  # TCP parameters:

  # ########################################################    

  $tcp1 set window_ 8000

  $tcp1 set packetSize_ 552

This NS Prog will draw the CWND: click here

Postscript: Analyzing multiple TCP flows

The easiest way to analyze the behavior of multiple TCP is to open one file to store the progression of one TCP agent's variable values.

 TCP Agents

  set tcp1 [new Agent/TCP/Reno]

  ...

  set tcp2 [new Agent/TCP/Reno]

  ...

  set outfile1  [open  "WinFile1"  w]

  set outfile2  [open  "WinFile2"  w]

  $ns  at  0.0  "plotWindow $tcp1  $outfile1"

  $ns  at  0.0  "plotWindow $tcp2  $outfile2"     

Plot data of  TCP 1 will be store in file "WinFile1"

Plot data of  TCP 2 will be store in file "WinFile2"

NETWORK EMULATOR: AN OVERVIEW

Emulators are characters with the emulation ability.Emulation means the ability to introduce the simulator into a live situation/network. Special objects within the simulator are capable of introducing live traffic into the simulator and injecting traffic from the simulator into the live network. There are two primary types of uses for such a facility, depending on whether the simulator appears to end stations as a router or as another end station. In the first case, live traffic can pass through the simulator (transparently to endpoints) and be affected by objects within the simulation, or by other traffic on the live network. In the second case, the simulator can include traffic sources or sinks that communicate with real-world entities. The first type of use is currently more developed than the second type.

The emulation facility can be subdivided into two modes:

• opaque mode -- live data treated as opaque data packets
• protocol mode -- live data may be interpreted/generated by simulator

In opaque mode, the simulator treats network data as uninterpreted packets. In particular, real-world protocol fields are not directly manipulated by the simulator. In opaque mode, live data packets may be dropped, delayed, re-ordered, or duplicated, but because no protocol processing is performed, protocol-specific traffic manipulation scenarios (e.g. ``drop the TCP segment containing a re transmission of sequence number 23045'') may not be performed. In protocol mode, the simulator is able to interpret and/or generate live network traffic containing arbitrary field assignments.

The interface between the simulator and live network is provided by a collection of objects including tap agents and network objects. Tap agents embed live network data into simulated packets and vice-versa. Network objects are installed in tap agents and provide an entry point for the sending and receipt of live data. Figure 1 illustrates how these objects are used for emulation. Both objects are described in the following sections.

 Interaction of emulator objects with the simulator

When using the emulation mode, a special version of the system scheduler is used: the RealTime scheduler. This scheduler uses the same underlying structure as the standard calendar-queue based scheduler, but ties the execution of events to real-time.

• OPAQUE MODEL

 Packets are passed through the simulator without being interpreted

The simulator acts like a router allowing real-world traffic to be passed through without being manipulated. The ns packet contain a pointer to the network packet. Network packets may be dropped, delayed, re-ordered or duplicated by the simulator. Opaque mode is useful in evaluating the behavior of real-world implementations when subjected to adverse network conditions that are not protocol specific.

• PROTOCOL MODEL

Packets are generated by a TCP agent that interacts transparently with a real-world TCP server.

The simulator is used as an end-point to generate TCP traffic. A TCP agent within ns interacts with a real-world TCP server and can receive data from the external application. nse allow supports ICMP, ARP and TCP NAT agents. The protocol mode can be used for end to end application testing, protocol and conformance testing.

Real-Time Scheduler

The real-time scheduler implements a soft real-time scheduler which ties event execution within the simulator to real time. Provided sufficient CPU horsepower is available to keep up with arriving packets, the simulator virtual time should closely track real-time. If the simulator becomes too slow to keep up with elapsing real time, a warning is continually produced if the skew exceeds a pre-specified constant ``slop factor'' (currently 10ms).

Tap Agents

The class TapAgent is a simple class derived from the base Agent class. As such, it is able to generate simulator packets containing arbitrarily-assigned values within the ns common header. The tap agent handles the setting of the common header packet size field and the type field. It uses the packet type PT_LIVE for packets injected into the simulator. Each tap agent can have at most one associated network object, although more than one tap agent may be instantiated on a single simulator node.

Network Objects

Network objects provide access to a live network (or to a trace file of captured network packets). There are several forms of network objects, depending on the protocol layer specified for access to the underlying network, in addition to the facilities provided by the host operating system. Use of some network objects requires special access privileges where noted. Generally, network objects provide an entrypoint into the live network at a particular protocol layer (e.g. link, raw IP, UDP, etc) and with a particular access mode (read-only, write-only, or read-write). Some network objects provide specialized facilities such as filtering or promiscuous access (i.e. the pcap/bpf network object) or group membership (i.e. UDP/IP multicast). The C++ class Network is provided as a base class from which specific network objects are derived. Three network objects are currently supported: pcap/bpf, raw IP, and UDP/IP. Each are described below.

Pcap/BPF Network Objects

These objects provide an extended interface to the LBNL packet capture library (libpcap). The pcap library is available from LBNL here. This library provides the ability to capture link-layer frames in a promiscuous fashion from network interface drivers (i.e. a copy is made for those programs making use of libpcap). It also provides the ability to read and write packet trace files in the ``tcpdump'' format. The extended interface provided by ns also allows for writing frames out to the network interface driver, provided the driver itself allows this action. Use of the library to capture or create live traffic may be protected; one generally requires at least read access to the system's packet filter facility which may need to be arranged through a system administrator.

The packet capture library works on several UNIX-based platforms. It is optimized for use with the Berkeley Packet Filter (BPF) and provides a filter compiler for the BPF pseudomachine machine code. On most systems supporting it, a kernel-resident BPF implementation processes the filter code, and applies the resulting pattern matching instructions to received frames. Those frames matching the patterns are received through the BPF machinery; those not matching the pattern are otherwise unaffected. BPF also supports sending link-layer frames. This is generally not suggested, as an entire properly-formatted frame must be created prior to handing it off to BPF. This may be problematic with respect to assigning proper link-layer headers for next-hop destinations. It is generally preferable to use the raw IP network object for sending IP packets, as the system's routing function will be used to determine proper link-layer encapsulating headers.

Pcap/File Network Objects

These objects are similar to the Pcap/BPF objects, except that network data is taken from a trace file rather than the live network. As such, the notion of promiscuous mode and the naming of a particular interface (available to the BPF objects) are not available for the file objects. In addition, the ability to create trace files is still under development. This facility will provide the ability to create tcpdump-compatible trace files.

IP Network Objects

These objects provide raw access to the IP protocol, and allow the complete specification of IP packets (including header). The implementation makes use of a raw socket. In most UNIX systems, access to such sockets requires super-user privileges. In addition, the interface to raw sockets is somewhat less standard than other types of sockets. The class Network/IP provides raw IP functionality plus a base class from which other network objects implementing higher-layer protocols are derived.

UDP/IP Network Objects

These objects provide access to the system's UDP implementation along with support for IP multicast group membership operations.

Courtesy: NS2 Official

WI-MAX MODULE FOR NS 2.28 SIMULATOR

Introduction

The Network Simulator 2 (NS-2) is a popular discrete event simulator target at networking research. This tool can suport simulation of TCP, routing, and MAC protocols over wired and wireless networks. Although it's possible to simulate wireless local area network (IEEE 802.11), ad hoc networks and satellites networks, ns does not provide a WiMAX module. This project implements a WiMAX module based on the IEEE 802.16 standard for the ns-2 simulator, release 2.28. The focus of this implementation is the MAC layer and its mechanisms for bandwidth allocation and QoS support. The module implements the 802.16 five service flow types and their bandwidth request/grant mechanisms; moreover, it allows users to configure the QoS requirements of applications. Service flows are modeled by finite sate machines that capture how each service type react to different events. This module supports TDD mode and PMP topology. The wireless channel available in the ns-2 simulator is used. The module design was based on a module (http://portal.acm.org/citation.cfm?id=1273047) designed to simulate the DOCSIS standard. Although code reuse was possible, several modifications in the DOCSIS module code were necessary to make it compliant to the IEEE 802.16 standard.

Installation

To install the patch, follow the instructions below:

• Download the software ns-allinone-2.28 package
• Download the latest ns-2 WiMAX module source code.
•  Unzip the ns-2 WiMAX module source code file.
• Put the files from "mac" directory into ns-allinone-2.28\ns-2.28\mac.
• Put the files which are in common and tcl respectively into ns-allinone-2.28\ns-2.28\common and ns-allinone-2.28\ns-2.28\tcl.
• Modify the Makefile.in as follows;After the sentence mac/mac-802_3.o add:

1. mac/mac-802_16-base.o mac/mac-802_16-ss.o mac/mac-802_16-bs.o \
2. mac/mac-802_16-FSM.o mac/mac-802_16-timers.o \

• Go to the ns-allinone-2.28/ns-2.28 directory and execute "./configure", "make clean" and "make".

Download

• Download source code version 1.02 (08/07/2008)

Documentation

The paper "Simulator for WiMAX networks", accepted for publication in Simulation Modelling Practice and Theory, presents a detailed description for the WiMAX module.

Description of the WiMAX module available from the IEEE Xplore Digital Library and presented at PIMRC 2007, Athens, Greece.

Document of the WiMAX module implementation - Download pdf or View html

Description of the uplink scheduler implemented in the WiMAX module available from the IEEE Xplore Digital Library and presented at GLOBECOM 2007, Washington DC, USA.

For More, Click Here

DRIVER LESS CARS...........TESTING STARTED......!!!!

Imagine a town with crosswalks but no pedestrians, cars and trucks but no drivers. Welcome to Mcity, a fake "town" built by researchers who are testing out the driverless cars of the future.
The controlled test environment, which opened today (July 20) at the University of Michigan (U-M) in Ann Arbor, covers 32 acres (the size of about 24 football fields) and contains all the trappings of a real suburb or small city. There is an entire network of roads lined with sidewalks, streetlights, stop signs and traffic signals. There's even a "downtown" area complete with fake building facades and outdoor dining areas.The idea behind Mcity is simple: test out new driverless car innovations in a human-free environment before these technologies are unleashed in the real world."Mcity is a safe, controlled, and realistic environment where we are going to figure out how the incredible potential of connected and automated vehicles can be realized quickly, efficiently and safely," Peter Sweatman, director of the Mobility Transformation Center (MTC) at U-M, said in a statement.
The roads of Mcity are built to stand up to "rigorous, repeatable" testing, according to MTC officials. While Mcity drivers don't have to contend with real pedestrians, there will be one mechanical foot-traveler (a robotlike machine named Sebastian) that steps out into traffic to see whether the automated cars can hit the brakes in time. The simulated city also features a traffic circle, a bridge, a tunnel, some unpaved roads, and even a four-lane highway with entrance and exit ramps, according to a report by Bloomberg Business.
In addition to evaluating fully automated, or driverless, cars, the researchers also hope to test out so-called connected vehicles within Mcity's limits. Connected cars can either communicate with one another (vehicle-to-vehicle control, or V2V) or with pieces of equipment, such as traffic lights, that are located near roadways (vehicle-to-infrastructure control, or V2I).
Even the smallest details of Mcity have been planned out in advance to replicate conditions that connected and automated vehicles could face in the real world. For example, there are street signs covered up with graffiti, and faded yellow and white lane markings line the streets.
Mcity is just one part of a much larger project that MTC and its partner organizations are establishing in an effort to get a whole fleet of connected and driverless cars on the road in Ann Arbor by 2021. In addition to the fake city, MTC is also continuing to launch connected and semi-autonomous cars on real roadways. Eventually, the University of Michigan and the Michigan Department of Transportation said they hope to put 20,000 connected cars on the roads of southern Michigan.

Courtesy: livescience

CONTROLLED DELAY ACTIVE QUEUE MANAGEMENT IN NS2

Hi Guys,

 Controlled Queue Delay is a modern AQM mechanism for solving buffer bloat[Persistently Full Buffer Problem]. The solution for persistently full buffers, AQM (active queue management), has been known for two decades but has not been widely deployed because of implementation difficulties and general misunderstanding about Internet packet loss and queue dynamics. Unmanaged buffers are more critical today since buffer sizes are larger, delay-sensitive applications are more prevalent, and large (streaming) downloads common. The continued existence of extreme delays at the Internet’s edge can impact its usefulness and hamper the growth of new applications.

This article aims to provide part of the bufferbloat solution, proposing an innovative approach to AQM suitable for today’s Internet called CoDel (for Controlled Delay, pronounced like “coddle”). This is a “no-knobs” AQM that adapts to changing link rates and is suitable for deployment and experimentation in Linux-based routers (as well as silicon).

In this post, we providing patch codes for CoDel along with ns2 versions.

To download patch, Click here

To download ns2, Click here

>> First untar ns2 and change directory to ns-allinone-2.35

>> Copy patch file into the folder and type following command in terminal

patch -pl < CoDel-ns-2.31.patch 

>> Then, Configure, Make & Install

For more, Click here

TOUR DE NS2: REVEALING PROGRAMMING STYLE

Friends,

Today we are going to have a look in why we run ns2 program as "ns program.tcl"?

Before that we have to go through basic C++ programmings in ns2.Consider a basic C++ instruction only program i .e for example; we are considering a program to calculate time taken for a packet travel from uppermost node to lower most node with the time taken to travel packet between each nodes (t) are constant (say t=1ms) and the number of nodes as n. (say n=10). And we have to find out overall time taken to reach packet to lowermost node. The C++ program new.cc is given below and after compiling we get a executable file "new".

//new.cc

main(){

float time = 0 , t = 1;

int i, n = 10;

 for(i = 1; i < n; i++)

time = time+i ;

printf("Overall time is  %f seconds.\n",time);

}

Now we execute the program from terminal, we can see the following results;

>> ./new

Overall time is 10.0 seconds.

But this programming style is not perfect. If the time to reach packet from one node to another is different and the number of nodes are changed then every time we have to change C++ program. To avoid this we can use input arguments. If we have more that one or two inputs we can provide it from terminal by using input arguments. For that normally we use argc and argv commands. The variable argc shows the number of input arguments and the variable argv contains all the inputs needed for programmer. The following C++ program shows it.

//new.cc

int main(int argc, char* argv[]) {

float time = 0, t = atof(argv[0]);

int i, n = atoi(argv[1]);

for(i = 1; i < n; i++)

time = time + i ;

printf("Overall time is %f seconds\n",time);

}

Now we execute the program from terminal, we can see the following results;

>> ./new 1 10

Overall time  is 10.0 seconds.

>> ./new 3 8

Overall time  is 24.0 seconds.

This programming scheme also have flexibility problem and which is inconvenient as input increases. So we went for most convenient form of  programming using configuration file. In this scheme the input data is used to pick input arguments. Consider a C++ program new.cc with configuration file con.txt and Function readArgFromFile(fp,a) reads the configuration file associated with a file pointer “fp,” and sets variables.

//new.cc

int main(int argc, char* argv[]) {

float time = 0, t[9];

FILE* fp = fopen(argv[1],"w");

int i, n = readArgFromFile(fp,a);

for(i = 1; i < n; i++)

time = time + i ;

printf("Overall time is %f seconds\n",time);

fclose(fp);

}

//con.txt

Number of node = 10

Time = 1 4 3 5 2 7 9 5 3

Now we execute the program from terminal, we can see the following results;

>> ./new con.txt

Overall time  is 30.0 seconds.

By modifying that con.txt file, we get various results.

Now we are looking towards the ns2 and i hope you all get some clue about what i am talking too. In ns2, we know that program is run by using command "ns programname.tcl". The TCL file programname.tcl is used as the input argument providing configuration file and  “ns” is a C++ executable file that generate after compiling using make and install function. The input configuration file specifies system parameters and all other configurations related to it.

I hope you all get it. 

Stay tuned for more updates........!!!!!!!!!

TOUR DE NS2: REVEALING SECRETS BEHIND COMMAND "MAKE" AND "MAKEFILE"

Friends,

We are decided to introduce a new segment in our blog named as "ToUr De Ns2" to get you more familiar with ns2 directories, folders and commands that we used in the ns2. We hope it gives you all a deep knowledge in ns2. We need all your supports and prayers. Comments and new ideas are welcomed.

Now we are going to have a deep look in command make. We all know that ns2 is a research tool. So all of the researchers are tried to customize files or to add new C++ modules in ns2 directory. During this time, it is necessary to recompile all the files that related or depend with it. So we need an effective command for recompilation of all files because manual recompilation is not possible. For that we here use a UNIX utility tool called as "make". This command has a significant role in development process. It keeps track of all the files created throughout the development process. By keeping track, it recompile the inter dependencies exist among these files; which may have been modified. The command syntax that we write in terminal to call is;

 make [-f filename]

Here make command recompiles the source code according to the descriptor file "filename" and the descriptor file is optional. So the command inside bracket is optional. By default the descriptor file is "Makefile". So if we not provided the filename, command automatically consider Makefile as descriptor file.

DESCRIPTOR FILE: MAKEFILE:

This file contains the name of source codes that have to execute, their inter dependency and how the file is to recompile. These things are specified using a specific dependency rule or by using a particular arrangement code names called as dependency rule. It contain three components; target,depfile&command

The syntax is given as;

<target1> [<target2> ...] : <depfile1> [<depfile2> ...]

<command1> [<command2> ...]

Here, the target file is the file which is needed to be compile and depfile are the files which are dependency file which is specified after semicolon(:) and also file inside bracket are optional ones. And the line below that shows the command that to regenerate the target file.

Example: 

# makefile of channel

OBJS = main.o

COM = cc

channel : ${OBJS}

${COM} -o channel ${OBJS}

main.o : main.c

${COM} -c main.c

clean :

rm ${OBJS}

Here, the target file is channel and that depends the file main.o and which is showed in third line and on the forth line the command showed to execute the recompiling. And the process repeats in the following lines. Final two line shows the clean function which is used to clean the dependency object file that are not neede after the recompilation. The UNIX command “cc -c file.c” compiles the file “file.c” and creates an object file “file.o,” while the command “cc -o file.o” links the object file “file.o” and create an executable file “file.”.

NS2 MAKEFILE:

Makefile in the ns2 is located in the ns2.xx directory and while we open it we can see the details of files needed to recompile. And in that file, we can mainly see the following keywords;

• INCLUDES = : The files or items that seen inside this category is to be seen in ns2 environment.
• OBJ_CC = & OBJ_STL = : It constitute the entire ns2 object files.
• NS_TCL_LIB = : We have to add the Tcl files of  ns2.

If a new C++ module is developed, then its corresponding object file name with “.o” extension should be added in OBJ_CC and OBJ_STL and Tcl file name should be added NS_TCL_LIB.

If you created a new C++ module with corresponding files .cc,.h and .tcl (say new.cc,new.h and new.tcl) and also created a new folder new inside the ns2 directory. After this we have to to the following;
1. Include a string “-I./new” into the Line beginning with INCLUDES = in the “Makefile.”

2. Include a string “new/new.o” into the Line beginning with OBJ_CC = or OBJ_STL = in the “Makefile.”

3. Include a string “new/new.tcl” into the Line beginning with NS_TCL_LIB = in the “Makefile.”

4. Run “make” from the terminal.

After running “make,” an executable file “ns” is created and this file “ns” to run simulation.

Continue with a new topic in following posts......!!!!
Thank You.
Have a Nice day.

STATISTICAL ANALYSIS USING RANDOM SETTINGS IN NS2

While running ns2, we always get the same results as much we run with the same parameters. If we need to get different results for running with same parameters,we need to add some random property in our scripting. By using this property, we can check what goes wrong at an exact point. Normally in ns2, simulations are under three categories;

DETERMINISTIC SETTING

This setting is the default setting of ns2 and we get the same output in every run. This simulation scenario is usually convenient for debugging process and to locate errors that occurred in simulation codes or to study about complex nature of networks. So while running in deterministic setting, we will get same results on every time and which helps easy to analysis.

RANDOM SETTING

In case of a statistical analysis, we are forced to simulate a simulation scenario several times and to find out mean & variance. By using deterministic setting we are not able to do this because the variance is zero for that. So we have to provide randomness with every simulation running. This is done by using RNG [Random Number Generator]. This randomness is in two forms;

Single Stream Random Setting

By default, ns2 always have defaultRNG with seed value one(1). To provide randomness, we have to seed different simulation runs differently. In single stream random setting, we need only one RNG and we set different runs with different outputs by providing different values of  "k". i.e;

$defaultRNG seed <k>

and random generator use this seed value <k> as seed for generating randomness.

TCL SCRIPT:

$defaultRNG seed 101

set arrivalRNG [new RNG]

set arrival_ [new RandomVariable/Exponential]

$arrival_ set avg_ 5

$arrival_ use-rng $arrivalRNG

puts "Inter-arrival time Packet size"

for {set j 0} {$j < 5} {incr j} {

puts [format "%f " [$arrival_ value] ]

 }

OUTPUT:

Inter-arrival time

.056 

.234 

.090 

.678 

.456 

DESCRIPTION:

Here, a exponential random variable arrival_ is created and its parameters are provided in the following line. For specifying a RNG, we use OTCL command use-rng and to print the result we used command value.

Schematic Diagram

 Multiple Stream Random Setting

If we need more than one variable to provide randomness in simulation runs,we have to create different set of new RNG as per our requirements.

REFERENCE: 

Introduction to Network Simulator NS2 by Teerawat Issariyakul • Ekram Hossain; 2nd Edition

GREP FUNCTION: EASY SEARCH COMMAND

Friends,
     Now we are trying to explain a Linux command which helps you a lot in your researches. Its nothing but a simple command called as GREP. It is a powerful command which helps you to search a particular string or words from a file or from a folder and also in some cases it helps during trace file analysis.

SYNTAX

Here the syntax is;

grep <option> <string> <filename>

Here, this command search string within the file named as filename. If it is not given, then the command waits for the input from the keyboard and search for string.  For more about this Click here 

There are two important notes for <string>

• If it contains a white space,  embrace it with quotation marks ("")
• If it contains a special character such as “ or &, you can suppress it using backslashes (\” or \&)  to indication that this is a character

For example, If u need to search a word "apple" in a file named as word.txt. Then;

grep apple word.txt

In case of searching words in sub directories, Simply write as; 

                                                                      grep -r apple *

If you want to look a function is available with ns2 folder or not, simply you can search by using this command. For example if you want to find function  className::rt_resolve(ReturnType variableName)

You can find this function using grep:  grep -r ::rt_resolve( *

In case of searching a string with special character "&hdr_aodv", we can search it as;

 grep -r \&hdr_aodv *

if you’re interested only in the ns-2.35/aodv directory. Now ypu can search by using this:

grep rt_resolve aodv/*.*

Now you can filter the search by providing  the files extension along with the search.For example;

grep rt_resolve *.h  searches rt_resolve in .h files only.

While in the case of trace file analysis we can use it as follows;

cat out.tr | grep " 2 3 cbr " | grep ^r | column 1 10 | awk '{dif = $2 - old2; if(dif==0) dif = 1; if(dif > 0) {printf("%d\t%f\n", $2, ($1 - old1) / dif); old1 = $1; old2 = $2}}' > jitter.txt

This means that the "CBR packet receive" event at n3, selects time (column 1) and sequence number (column 10), and calculates the difference from last packet receive time divided by difference in sequence number (for loss packets) for each sequence number. i .e  for selecting particular value we can use this.

MOVE AND SUMO INSTALLATION FOR SIMULATING VANETS

For simulating a VANET , we need Simulation of Urban MObility and MOVE softwares.SUMO softwares creates the road maps, edges,curves and vehicle movement with the help of MOVE software.So we have to install both software and also need java development kit(jdk) for supporting MOVE software

MOVE INSTALLATION

1. First you have to install jdk,for that open terminal and write following commands;  

                                          $ sudo apt-get purge openjdk*  

                                         $ sudo add-apt-repository ppa:webupd8team/java

                                        $ sudo apt-get update

                                       $ sudo apt-get install oracle-java7-installer

2. After installing JDK 7 go to following link to download MOVE [Fill the data]

3. Download the  MOVE.JAR  file.

4. Open the application using JDK [otherwise right click and click properties set JDK as default]

SUMO INSTALLATION

1. Download software from this link; SUMO

2. Now install SUMO and for that click here

For more; click here

AQUA-SIM FOR UNDER WATER SENSOR NETWORKS

Recently underwater sensor network has emerged as a powerful technique for aquatic applications, and it has attracted more and more attention from the networking research community. To facilitate the research in underwater sensor networks, it is desirable to have a standard simulation platform to compare and evaluate different network designs, algorithms and protocols.

Although there are a couple of efforts on incorporating acoustic propagation models into the simulation of underwater acoustic networks, to the best of our knowledge, there is no complete packet level underwater network simulator published yet. There are several widely used packet level network simulators such as NS-2 and OPNET. However, they were developed for terrestrial radio wireless and/or wired networks, not for underwater sensor networks. They cannot be used for the simulation of underwater sensor networks without significant modifications for the following reasons: Firstly, acoustic communication is the commonly accepted method for underwater environments, while the propagation speed of acoustic signal in water is very slow (about 1500 m/s), significantly different from that of radio signal; secondly, the acoustic signal attenuation model is drastically different from that of radio signal, and thus acoustic channel models have to be incorporated; thirdly, underwater sensor networks are usually deployed in a three dimensional space, while these simulators usually only support two-dimensional deployment. Thus, the unique characteristics of underwater sensor networks make the existing network simulators unsuitable.

Developed simulator, called Aqua-Sim, for underwater sensor networks are developed on the basis of NS-2, Aqua-Sim can effectively simulate acoustic signal attenuation and packet collisions in underwater sensor networks. Moreover, Aqua-Sim supports three-dimensional deployment. Further, Aqua-Sim can easily be integrated with the existing codes in NS-2. Aqua-Sim is in parallel with the CMU wireless simulation package. As shown in the figure below, Aqua-Sim is independent of the wireless simulation package and is not affected by any change in the wireless package. On the other hand, any change to Aqua-Sim is also confined to itself and does not have any impact on other packages in NS-2. In this way, Aqua-Sim can evolve independently.

Advantages of Aqua-Sim

1. Discrete-event driven network simulator
2. Support 3D networks and mobile networks
3. Simulate underwater acoustic channels with high fidelity
4. Implement a complete protocol stack from physical layer to application layer

AQUA-SIM INSTALLATION 

1. First download aqua-sim by clicking here

2. Before installing Aqua-Sim, you should make sure that your linux system contains the essential libs for the installation of ns-allinone-2.30. Usually, it requires gcc/g++ complier, automake, X11 lib. To make Aqua3D works, some other packages, such as freeglut, GTK+ 2.0 and wxGTK-2.8.11, are also required .

3. All these packages can be installed from synaptic package manager.

4. Installing the dependencies: sudo apt-get install xorg-dev g++ xgraph

5. Copy and paste aqua-sim file wherever you want. Suppose you have pasted it in your home directory.

6. Double click on tar file to extract or use command: tar -xvf aqua-sim.tgz

7. Move into extracted folder: 

cd Desktop/Aqua-Sim-1.0/

./install

8. After running the installation process for a while, suddenly it turned out with an error saying "ld: libotcl.so: hidden symbol `__stack_chk_fail_local' isn't defined". 

9. After that edit a configuration file, so I opened the file Aqua-Sim-1.0/otcl-1.12/configure and searched for the line SHLIB_LD="ld -shared" inside it. Then I commented and added a different line as shown below.

#SHLIB_LD="ld -shared"

SHLIB_LD="gcc -shared"

10. Then run the command ./install again 

11. At the end of the installation process, as usual in NS2 installation, it asked for setting some environmental variables in system. So open the "/etc/profile" file and added the following lines at the end of the existing content and saved.

export PATH=$PATH:/home/asanka/Desktop/Aqua-Sim-1.0/bin:/home/asanka/Desktop/Aqua Sim-1.0/tcl8.4.13/unix:/home/asanka/Desktop/Aqua-Sim-1.0/tk8.4.13/unix

export LD_LIBRARY_PATH=/home/asanka/Desktop/Aqua Sim1.0/otcl-.12:/home/asanka/Desktop/Aqua-Sim-1.0/lib

export TCL_LIBRARY=/home/asanka/Desktop/Aqua-Sim-1.0/tcl8.4.13/library

12. Type; cd Aqua-Sim-1.0/ns-2.30

./validate

13. After the validation script finished the execution,run a sample TCL simulation script as shown below.

cd /ns-2.30/underwatersensor/uw_tcl

ns tmac-example.tcl

>> link for other possible errors:

link 1

link 2

>> User manual

NETWORK EMULATOR TOOL KIT [NEWT]

Searching for a tool to simulate a poor network connection? Here is the solution. It’s called Network Emulator Toolkit (NEWT) and is available in a 32 Bits version and a 64 Bits version of windows.

For Download, Click here

For More, Click here

HP NETWORK SIMULATOR: A COMWARE OS LEARNING TOOL

Comware v7 is a network operating system that runs on HP high-end network devices. The HP Network Simulator is an ideal Comware v7 learning tool, which allows users to create, configure, and connect simulated networks.

Benefits

Beginners – The HP Network Simulator tool is helpful for users who are new to networking and want to learn how to configure network devices (switches, routers), various topologies, or different routing and switching protocols and features.

Experienced users – The HP Network Simulator learning tool is helpful for users who have experience with non-HP networking devices and want to learn the Comware CLI and features.

Extra devices – Users can create devices using the HP Network Simulator and use them with their physical devices to configure and test topologies that aren’t configurable with just the physical devices they have. For example – A user wants to configure OSPF using 3 or more devices but has only 1 physical router. User can create 2 or more routers using the HP Network Simulator learning tool and connect the simulated devices with the physical device; and configure OSPF.

Certification Test Takers – The HP Network Simulator learning tool is also helpful for candidates who want to take HP Certification exams but don’t have access to physical HP devices to practice on.

For more,Click here

For download, Click here

OPEN SOURCE NETWORK EMULATORS FOR LINUX

Here we going to present a list of network emulators which worked on Linux platform. Network emulation is a technique where the properties of an existing, planned and/or non-ideal network are simulated using emulation of specific routers and other network equipment, as opposed network simulation where simplified mathematical models of data sources, channels and protocols are applied. The aim is educational, to develop skills in configuring network equipment, or scientific, to in order to assess performance, predict the impact of change, or otherwise optimize technology decision-making.

Cloonix

The Cloonix network simulator provides a relatively easy-to-use graphical user interface. Cloonix recommends KVM to create virtual machines but it also supports other virtualization technologies. Cloonix provides a wide variety of pre-built file systems that can be used as virtual machines and provides simple instructions for creating other virtual machine root file systems. Cloonix has an active development team, who update the tool every two or three months and who are very responsive to user input.

URL: http://clownix.net

For more click here

CORE

Common Open Research Emulator (CORE) provides a GUI interface and uses the Network Namespaces functionality in Linux Containers (LXC) as a virtualization technology. This allows CORE to start up a large number of virtual machines quickly. CORE supports the simulation of fixed and mobile networks.

CORE will run on Linux and on FreeBSD. CORE is a fork of the IMUNES network simulator, and it adds some new functionality compared to IMUNES.

URL: http://cs.itd.nrl.navy.mil/work/core/index.php

For more click here

GNS3

GNS3 is a graphical network simulator focused mostly on supporting Cisco and Juniper software. GNS3 has a large user base, made up mostly of people studying for Cisco exams, and there is a lot of information freely available on the web about using GNS3 to simulate Cisco equipment. GNS3 can also be used to simulate a network composed exclusively of VirtualBox and/or Qemu virtual machines running open-source software. GNS3 provides a variety of prepared open-source virtual appliances, and users can create their own.

URL: http://www.gns3.net

For more click here

IMUNES

A team of researchers at the University of Zagreb developed the Integrated Multi-protocol Network Emulator/Simulator (IMUNES) for use as a network research tool. IMUNES runs on the FreeBSD operating system and uses the kernel-level network stack virtualization technology provided by FreeBSD.

IMUNES supports a graphical user interface. It appears to work well and offers good performance, even when running IMUNES on a FreeBSD system running in a VirtualBox virtual machine.

URL: http://www.imunes.tel.fer.hr/ or http://www.imunes.net

For more click here

Marionnet

Marionnet Linux network simulator emulator is called as “virtual network laboratory” on its website. It allows users to define, configure and run complex computer networks on a host computer. It can simulate an Ethernet network complete with computers, routers, hubs, switchs, cables, and more. Marionnet seems designed to be used as an education tool and has an attractive graphical user interface, and some sample practice lab configurations. Marionnet does not provide a user manual but the user interface is fairly intuitive.

URL: http://www.marionnet.org/EN/

.For more click here

Mininet

Mininet open-source network simulator running on an Apple iMacMininet is designed to support research in Software Defined Networking technologies. It uses Linux network namespaces as its virtualization technology to create virtual switches and virtual nodes. The web site indicates that the tool can support thousands of virtual nodes on a single operating system. Mininet is most useful to researchers who are building SDN controllers and need a tool to verify the behavior and performance of SDN controllers. Knowledge of the Python scripting language is very useful when using Mininet.

The Mininet project provides excellent documentation and, judging from the activity on the Mininet mailing list, the project is actively used by a large community of researchers.

URL: http://www.mininet.org

For more click here

Netkit

Netkit open source single-area OSPF pre-configured lab. Netkit is a command-line based simulation tool that uses user-mode Linux to create the virtual machines. A full Linux OS can run on each machine. It has good documentation and the project’s web site has a long list of interesting lab scenarios to practice, with documentation for each scenario. It also appears to be actively supported by a small community and was last updated in 2011.

URL: http://wiki.netkit.org

For more click here

Psimulator2

Psimulator Linux Open-Source Graphical Network Simulator. Psimulator2 is a basic graphical network simulator that may be used to demonstrate basic IP networking concepts to students. It is not a fully-functional simulator because only a small sub-set of normal networking functionality is supported on each emulated node. It will run on any system that supports Java; including Windows, Mac OS, and Linux. It offers the ability to “capture” and “play back” data traffic generated by the simulation. The packets are displayed on the GUI as envelopes that move through the network.

URL: http://code.google.com/p/psimulator/

For more click here

Virtualsquare

Virtualsquare is an interesting effort to create a virtual network tool. The developers are building their own tools to create virtual networks, instead of re-using tools available in the common Linux distributions. There are no prepared labs available so users will have to learn the tool before creating lab scenarios for themselves. The project is well documented. It looks like a research project and Linux kernel or programming skills may be required to fully appreciate it. Virtualsquare is also the source of the Virtual Distributed Ethernet (VDE) program. VDE is used in some of the other network simulation tools.

URL: http://wiki.virtualsquare.org/wiki/index.php/Main_Page

VNX and VNUML

VNX linux open-source network simulator. VNX supports two different virtualization techniques and uses an XML-style scripting language to define the virtual network. It also supports chaining multiple physical workstations together to support distributed virtual labs that operate across multiple physical workstations. It is supported by a small community and has been updated within the past year. VNX replaces VNUML. The old VNUML web site still has sample labs and other content that would be useful when using VNX.

URL: http://www.dit.upm.es/vnx

For more click here

Courtesy: brianlinkletter.com