Wednesday, March 24, 2010

Traffic creation in Ns2 and Secenarios

Hi everybody

Here I give the Link where you can download the Tcl scripts regarding the Traffic generation in Ns2 as well as the Scenarios .
This will help to know the Traffic creation in Ns2 .

http://hotfile.com/dl/34402030/a7070ed/scenarios.rar.html

http://hotfile.com/dl/34402106/5bf2ab6/traffic.rar.html

I have many Projects related to NS2 day by day I will keep on Posting Check Regularly.
Enjoy the Network Simulation.

Any Queries comment it.

Friday, March 19, 2010

Let us know about 802.15.4 and ZigBee Routing Simulation

Basic
1) Version: P802.15.4/D18
2) Simulation Platform: NS 2.26 or above
Code Size
1) C++ Source Codes: 12k lines
2) Tcl Scripts: 500 lines
• Functionality
1) Pure CSMA-CA and Slotted CSMA-CA
2) Legacy application support (802.11b compatible)
3) Star and Peer-to-Peer topologies
4) Beacon enabled and non-beacon enabled modes
5) Beacon tracking and synchronization

Functionality
– Association and Disassociation
– Peer-to-Peer Tree and Cluster Tree Formation
– Direct and Indirect (data polling and extraction)
transmissions
– Energy Detection (ED)
– Clear Channel Assessment (CCA)
– Link Quality Detection (LQD)
– Multiple channel support
– Channel Scan (ED/Active/Passive/Orphan)
– Filtering (channel, beacon, duplication, interference, etc.)
– Simulation Tracing
– Deterministic Error Models (Node/Link)
– Enhanced Nam Animation

SSCS Interface

$node sscs startPANCoord

– This command can be used to start a new PAN, and the
corresponding node will serve as the PAN coordinator.
– If some parameters are omitted, the default values shown above
will be assumed.

– Examples:
• $node_(0) sscs startPANCoord
• $node_(0) sscs startPANCoord 1 2 2
• $node sscs startDevice = 0>
– This Command can be used to start a device or coordinator.
– If some parameters are omitted, the default values shown above
will be assumed.

Examples:

• $node_(0) sscs startDevice 0 //device

• $node_(0) sscs startDevice //coor., non-beacon

• $node_(0) sscs startDevice 1 1 1 //coor., beacon enabledLR

• $node sscs startCTPANCoord

– Similar to “startPANCoord”, except it is used to start a
Cluster Tree based PAN.

• $node sscs startCTDevice 1>

– Similar to “startDevice”, except it is used to start a Device
in a Cluster Tree based PAN.

• $node sscs startBeacon

– Start to transmit beacons if originally in non-beacon mode,
or change the beacon order and superframe order if
originally in beacon mode.

• $node sscs stopBeacon
– Stop the transmission of beacons


Further Tutorials and demo codings and Installation procedure can downloaded from here
http://hotfile.com/dl/33586869/ec7b5a8/wpan_zbr.rar.html

Wednesday, March 10, 2010

Installation Procedure of NS2 in Ubuntu

Installing ns2.32 on Ubuntu7.10

This article works fine for Installing ns2.31 on Ubuntu 7.04 but for ns2.32 it needs some minor changes so I will repeat the commands with these changes so that others may save time repeating this work

Download ns-allinone-2.32 and Install

$ wget http://nchc.dl.sourceforge.net/sourceforge/nsnam/ns-allinone-2.32.tar.gz

$ tar -xzvf ns-allinone-2.32.tar.gz

$ cd ns-allinone-2.32

$ sudo apt-get install build-essential autoconf automake libxmu-dev

If an error raising Package autoconf is not available or something similar then this post may help you for fixing that

(If previous command still generate some errors, and if it does, restart your computer and try the following step :)

$ sudo apt-get install -f build-essential libxt-dev libxt6 \

libsm-dev libsm6 libice-dev libice6 libxmu-dev

If an error raising Package autoconf is not available or something similar then this post may help you for fixing that

Now run this command

$./install

Set environment variables

$ gedit ~/.bashrc

Add the following lines to the end of it. Remember replace "/your/path" by something like "/home/purple"




# LD_LIBRARY_PATH

OTCL_LIB=/your/path/ns-allinone-2.32/otcl-1.13

NS2_LIB=/your/path/ns-allinone-2.32/lib

X11_LIB=/usr/X11R6/lib

USR_LOCAL_LIB=/usr/local/lib

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OTCL_LIB:$NS2_LIB:$X11_LIB:$USR_LOCAL_LIB

# TCL_LIBRARY

TCL_LIB=/your/path/ns-allinone-2.32/tcl8.4.15/library

USR_LIB=/usr/lib

export TCL_LIBRARY=$TCL_LIB:$USR_LIB

# PATH

XGRAPH=/your/path/ns-allinone-2.32/bin:/your/path/ns-allinone-2.32/tcl8.4.15/unix:/your/path/ns-allinone-2.32/tk8.4.14/unix

NS=/your/path/ns-allinone-2.32/ns-2.32/

NAM=/your/path/ns-allinone-2.32/nam-1.13/

PATH=$PATH:$XGRAPH:$NS:$NAM

Let it take effect immediately:

$ source ~/.bashrc

Note: the step described above is important;otherwise, you cannot run ns successfully.

(or you can restart your X windows,i.e. logout and then login, or reboot your system, to make it work.)

Now,the installation has been completed.If you try:

$ ns

Then a "%" will appear on the screen.type "exit" to quit the mode and back to "$"


Validation

After these steps, you can now run the ns validation suite with

$ cd ns-2.32 $ ./validate

Monday, March 1, 2010

ZMAV

* NS-2 installations instructions:
o Download the source tarball here.
o Untar it in the "mac" directory of your ns top-level directory: (NS_INSTALL_DIRECTORY)/ns-2.26/mac. Warning: the package contains a slightly modified version of "mac.h", so if you have made changes to mac.h, please do a diff and incorporate the changes.
o Add an entry in the Makefile for zmac files: "mac/common-mac.o mac/zmacHCL.o mac/zmac-timers.o mac/common-mac-timers.o" and remove entries "mac/mac-802_11.o" and "mac/mac-timers.o" for the OBJ_CC target.
o Replace (NS_INSTALL_DIRECTORY)/ns-2.26/tcl/lib/ns-mobilenode.tcl with the given file here, the change is very minor, to allow packet tracing from the mac layer.

For the Source and Codings You can download from here

http://hotfile.com/dl/30721737/1e090d3/ZMAC.rar.html



* NS-2 execution instructions:

TDMA Setup

o Before using Z-MAC, some setup is required. For a given topology, Z-MAC requires each node to know its TDMA slot. This is achieved using DRAND, a distributed TDMA slot assignment algorithm.
o Consider a topology file, new-scen---, which denotes the X, Y and Z positions of nodes in the topology in tcl code. Here maxX and maxY represent the X and Y dimensions of the topology respectively, and N represents the number of nodes in the network. Such a file could be generated by the topology generator 'setdest' for large topologies, or could be hand-written). Note that this naming convention is important later, so please maintain it for the rest of this section.
o Run the drand application on this topology by following the execution instructions in the DRAND page above. Save the output in file, "new-scen-N-X-Y.out".
o This output file contains the information about the TDMA slots assigned to each node in the topology. We need a script to convert this information to Tcl code which can be input to the z-mac code. This is done by the following script: getZMACInput.py. Execute this script on the output file as follows:
+ python getZMACInput.py new-scen-N-X-Y 0
# "MAX_NEIGHBOR" is the value of MAX_NEIGHBOR defined in file mac/zmac.h, which defines the maximum number of two-hop neighbors allowed in the topology. The value used here and the value in mac/zmac.h should be the same, or else the program will fail. The current value used is 30.
+ this will create two files, "new-scen-N-X-Y.drand" and "new-scen-N-X-Y.maxcolor". "new-scen-N-X-Y.drand" contains the slot assignments, and "new-scen-N-X-Y.maxcolor" contains the frame size (which is the maximum slot number assigned to any node in the whole network).
o This completes the TDMA setup for Z-MAC. Three files should have been generated:
+ new-scen-N-X-Y
+ new-scen-N-X-Y.drand
+ new-scen-N-X-Y.maxcolor

TRANSMISSION EXPERIMENTS

o Now, download the tcl script tarball here
o Untar it in any location in your file-system.
o The file "simZMAC.tcl" is the main file for the simulation of Z-MAC. Run it as follows:
+ ns simZMAC.tcl -numsources .... -nn .....
+ simZMAC.tcl takes a number of arguments, which allow the user to specify different Z-MAC parameters (e.g. To, Tno, LCL/HCL modes, etc.). The specific details can be found in the README file in the tarball.
+ an output file can be specified as a parameter to simZMAC.tcl, and at the end of the simulation, performance statistics can be printed out.


NS-2

* NS-2 installations instructions:
o Download the source tarball here.
o Untar it in your ns top-level directory: (NS_INSTALL_DIRECTORY)/ns-2.26.
o Add an entry in the Makefile for DRAND files as "drandNS2/drandAgent.o" for the OBJ_CC target.
o Add entry for DRAND packet type in (NS_INSTALL_DIRECTORY)/ns-2.26/tcl/lib/ns-packet.tcl as "DRAND" - sample here.
o Add entry for DRAND packet type in (NS_INSTALL_DIRECTORY)/ns-2.26/common/packet.h as "PT_DRAND" - sample here.
o Replace ns2.26/mac/mac-802_11.cc with this file: There is a small change to enable broadcast for DRAND packets.
o Replace ns2.26/trace/cmu-trace.cc with with this file: This adds support for DRAND packets.
* NS-2 execution instructions:
o Download the tcl script tarball here
o Untar it in any location in your file-system.
o Execute simulation by the follwing command: "ns simple-wireless.tcl "
o File "simple-wireless.tcl" runs a simulation of nodes in a 300m x 300m area, distributed according to the wireless scenario generated by "scenario.tcl". Wireless options (link speed, antenna characteristics, transmission power, etc.) are in the "wirelessOpt.tcl" file.
o For generating the scenario file, use the CMU scenario generator included in the ns2 distribution: (NS_INSTALL_DIRECTORY)/ns-2.26/indep-utils/cmu-scen-gen/setdest. Also, note that the scenario should not contain any node motion, so please use the option "-p 0 -s 0"
o DRAND is composed of two phases - a "HELLO" phase, where nodes send beacons to each other to probe their network neighborhood, and the "DRAND" phase where the DRAND algorithm is run and a TDMA schedule is produced (For more details please refer to the paper "Randomized Dining Philosophers to TDMA Scheduling in Wireless Sensor Networks".
o DRAND output is as follows:
+ MESSAGE sID 82 mCt 15 rReq 0 rGra 0 mTime 27.826388 oneHopCount 7
MESSAGE sID 82 reqCt 1 graCt 7 rejCt 0 relCt 0 twoCt 7
MESSAGE sID 82 Round 20 maxC 0 twoHopMaxC 0 slotNum 11 roundDelay 0.023284 grantDelay 0.018388
+ Some of the noteworthy fields are:
# sID = Node ID
# mCt = Total messages transmitted
# mTime = Total time for the node to get its own time slot
# oneHopCount = Total number of nodes within one hop to this node
# slotNum = TDMA slot assigned by DRAND

Ad-hoc network

An ad-hoc (or "spontaneous") network is a local area network or other small network, especially one with wireless or temporary plug-in connections, in which some of the network devices are part of the network only for the duration of a communications session or, in the case of mobile or portable devices, while in some close proximity to the rest of the network. In Latin, ad hoc literally means "for this," further meaning "for this purpose only," and thus usually temporary.
The term has been applied to future office or home networks in which new devices can be quickly added, using, for example, the proposed Bluetooth technology in which devices communicate with the computer and perhaps other devices using wireless transmission.
One vendor offers an ad-hoc network technology that allows people to come to a conference room and, using infrared transmission or radio frequency (RF) wireless signals, join their notebook computers with other conferees to a local network with shared data and printing resources. Each user has a unique network address that is immediately recognized as part of the network. The technology would also include remote users and hybrid wireless/wire connections.

Jini is an approach to instant recognition of new devices in a network that would seem to make it easier to have an ad-hoc network.

Mobile ad-hoc network


A mobile ad-hoc network (MANet) is a kind of wireless ad-hoc network, and is a self-configuring network of mobile routers (and associated hosts) connected by wireless links – the union of which form an arbitrary topology. The routers are free to move randomly and organise themselves arbitrarily; thus, the network's wireless topology may change rapidly and unpredictably. Such a network may operate in a standalone fashion, or may be connected to the larger Internet.

Mobile ad-hoc networks became a popular subject for research as laptops and 802.11/Wi-Fi wireless networking became widespread in the mid- to late 1990s. Many of the academic papers evaluate protocols and abilities assuming varying degrees of mobility within a bounded space, usually with all nodes within a few hops of each other, and usually with nodes sending data at a constant rate. Different protocols are then evaluated based on the packet drop rate, the overhead introduced by the routing protocol, and other measures

In the next generation of wireless communication systems, there will be a need for the rapid deployment of independent mobile users. Significant examples include establishing survivable, efficient, dynamic communication for emergency/rescue operations, disaster relief efforts, and military networks. Such network scenarios cannot rely on centralized and organized connectivity, and can be conceived as applications of Mobile Ad Hoc Networks. A MANET is an autonomous collection of mobile users that communicate over relatively bandwidth constrained wireless links. Since the nodes are mobile, the network topology may change rapidly and unpredictably over time.

The network is decentralized, where all network activity including discovering the topology and delivering messages must be executed by the nodes themselves, i.e., routing functionality will be incorporated into mobile nodes.

The set of applications for MANETs is diverse, ranging from small, static networks that are constrained by power sources, to large-scale, mobile, highly dynamic networks. The design of network protocols for these networks is a complex issue. Regardless of the application, MANETs need efficient distributed algorithms to determine network organization, link scheduling, and routing. However, determining viable routing paths and delivering messages in a decentralized environment where network topology fluctuates is not a well-defined problem.

While the shortest path (based on a given cost function) from a source to a destination in a static network is usually the optimal route, this idea is not easily extended to MANETs. Factors such as variable wireless link quality, propagation path loss, fading, multiuser interference, power expended, and topological changes, become relevant issues. The network should be able to adaptively alter the routing paths to alleviate any of these effects.

Moreover, in a military environment, preservation of security, latency, reliability, intentional jamming, and recovery from failure are significant concerns. Military networks are designed to maintain a low probability of intercept and/or a low probability of detection. Hence, nodes prefer to radiate as little power as necessary and transmit as infrequently as possible, thus decreasing the probability of detection or interception. A lapse in any of these requirements may degrade the performance and dependability of the network.

The concepts and operational requirements associated with the current idea of MANETs are discussed in the mobile computing and networking literature, notably documents and standards developed by the MANET Working Group of the Routing Area of the Internet Engineering Task Force (IETF).