Monday, November 15, 2010

Reduction of Rekeyying process to overcome Security

Hello Peoples

Here This topic is to discuss the overhead problem while continuous rekeying, The experts can suggest idea are the students can discuss about that , actually using the Tree structure other than that new ideas needed . share with us

Monday, October 11, 2010

Installation of Wimax in NS2.31

Hello Guys

First of all i like to apologies for delay posting in Ns2 , because busy with my Research area. Now i like to share some thoughts in Wimax 3G, here iam going to give the installation of Wimax in ns 2.31

1) at present the UMTS and the Wimax 3G research going on the Area6 but now iam posting for startup people to implement the wimax

2) download ns-allinone-2.31


wimax implementation ....

The patch file is only provided for ns-2.31.

a- Using the ns-allinone installation
step1: install the patch by running "patch -p0 step2: re-run "./configure ; make clean ; make" in the ns-2.31 directory.

b- From the ns-2.31 directory
step1: install the patch by running "patch -p1 step2: re-run "./configure ; make clean ; make" in the ns-2.31 directory.

download file from here

Monday, September 20, 2010

RSA algorithm in Ns2

RSA This algorithm is used in cryptography Technique in that RSA is added along with it. These are procedures followed

Key generation

RSA involves a public key and a private key. The public key can be known to everyone and is used for encrypting messages. Messages encrypted with the public key can only be decrypted using the private key. The keys for the RSA algorithm are generated the following way:

1. Choose two distinct prime numbers p and q.
* For security purposes, the integers p and q should be chosen uniformly at random and should be of similar bit-length. Prime integers can be efficiently found using a primality test.
2. Compute n = pq.
* n is used as the modulus for both the public and private keys
3. Compute φ(pq) = (p − 1)(q − 1). (φ is Euler's totient function).
4. Choose an integer e such that 1 < e < φ(pq), and e and φ(pq) share no divisors other than 1 (i.e., e and φ(pq) are coprime).
* e is released as the public key exponent.
* e having a short bit-length and small Hamming weight results in more efficient encryption. However, small values of e (such as e = 3) have been shown to be less secure in some settings.[4]
5. Determine d (using modular arithmetic) which satisfies the congruence relation d e \equiv 1\pmod{\varphi(pq)}.
* Stated differently, ed − 1 can be evenly divided by the totient (p − 1)(q − 1).
* This is often computed using the extended Euclidean algorithm.
* d is kept as the private key exponent.

The public key consists of the modulus n and the public (or encryption) exponent e. The private key consists of the private (or decryption) exponent d which must be kept secret.


* An alternative, used by PKCS#1, is to choose d matching e d ≡ 1 (mod λ) with λ = lcm(p-1,q-1), where lcm is the least common multiple. Using λ instead of φ(n) allows more choices for d. λ can also be defined using the Carmichael function λ(n).
* For efficiency the following values may be precomputed and stored as part of the private key:
o p and q: the primes from the key generation,
o d\mod (p - 1) and d\mod(q - 1),
o q^{-1} \mod(p).

[edit] Encryption

Alice transmits her public key (n,e) to Bob and keeps the private key secret. Bob then wishes to send message M to Alice.

He first turns M into an integer 0 < m < n by using an agreed-upon reversible protocol known as a padding scheme. He then computes the ciphertext c corresponding to:

c = m^e\,\bmod\,n

This can be done quickly using the method of exponentiation by squaring. Bob then transmits c to Alice.
[edit] Decryption

Alice can recover m from c by using her private key exponent d by the following computation:

m = c^d\,\bmod{\,n}.

Given m, she can recover the original message M by reversing the padding scheme.

(In practice, there are more efficient methods of calculating cd using the pre computed values above.)
[edit] A worked example

Here is an example of RSA encryption and decryption. The parameters used here are artificially small, but one can also use OpenSSL to generate and examine a real keypair.

1. Choose two prime numbers

p = 61 and q = 53 Make sure that these prime numbers are distinct.

2. Compute n = pq


3. Compute the totients of product. For primes the totient is maximal and equals the prime minus one. Therefore \varphi(pq) = (p-1)(q-1) \,

\varphi(61\cdot53) = (61 - 1)\cdot(53 - 1) = 3120\,

4. Choose any number e > 1 that is coprime to 3120. Choosing a prime number for e leaves you with a single check: that e is not a divisor of 3120.

e = 17

5. Compute d such that d e \equiv 1\pmod{\varphi(pq)}\, e.g., by computing the modular multiplicative inverse of e modulo \varphi(pq)\,:

d = 2753
since 17 · 2753 = 46801 and 46801 mod 3120 = 1, this is the correct answer.
(iterating finds (15 times 3120)+1 divided by 17 is 2753, an integer, whereas other values in place of 15 do not produce an integer. The extended euclidean algorithm finds the solution to Bézout's identity of 3120x2 + 17x-367=1, and -367 mod 3120 is 2753)

The public key is (n = 3233, e = 17). For a padded message m the encryption function is m^{17} \mod {3233} or abstractly:

c = m^e\mod {n}

The private key is (n = 3233, d = 2753). The decryption function is c^{2753} \mod {3233} or in its general form:

m = c^d\mod {n}

For instance, in order to encrypt m = 65, we calculate

c = 2790 = 65^{17}\mod {3233}

To decrypt c = 2790, we tap

m = 65 = 2790^{2753}\mod {3233}.

Both of these calculations can be computed efficiently using the square-and-multiply algorithm for modular exponentiation. In real life situations the primes selected would be much larger; in our example it would be relatively trivial to factor n, 3233, obtained from the freely available public key back to the primes p and q. Given e, also from the public key, we could then compute d and so acquire the private key.

These Procedures implemented in TCL coding to run in NS2 .For codings and queries please send the mail to admin.

NS2 Projects

Hello Everyone
sorry for not posting about NS2 about two months.I know many students facing difficulties in doing Projects in Ns2. Here iam helping out doing Projects in NS2 ,
I can help Masters,PHD students,UG students and also for Researchers.
But for doing the Projects Cost will be added .
The services will be available like Online chatting, Voice Chatting,Even remote connection and i will help you people to know about Ns2. Any networking Projects can be done in NS2.

For this please contact to this mail id :

still more post will be added on this blog keep reading, Ns2 Rocks.
still any doubts can ask me are can mail me I will clarify the doubts with my Best.

Tuesday, July 13, 2010

Ns2 in MAC Protocol

Several researchers have proposed simple medications of IEEE 802.11 to incorporate power control. The main idea of these power control schemes is to use different power levels for RTS-CTS and DATA-ACK. Specially, maximum transmit power is used for RTS-CTS, and the minimum required transmit power is used for ATA-ACK transmissions in order to save energy. However, we show that these schemes can degrade network throughput and can result in higher energy consumption than when using IEEE 802.11 without power control. We propose a power control protocol which does not degrade throughput and yields energy saving.

A power control mechanism that can be incorporated into the IEEE 802.11 RTS-CTS handshake. The scheme in allows a node, A, to specify its current transmit power level in the transmitted RTS, and allows receiver node B to include a desired transmit power level in the CTS sent back to A. On receiving the CTS, node A then transmits DATA using the power level specified in the CTS. This scheme allows B to help A choose the appropriate power level, so as to maintain a desired signal-to-noise ratio. A similar protocol is utilized, wherein the RTS and CTS packets are sent at the highest power level, and the DATA and ACK may be sent at a lower power level. We refer to this scheme as the BASIC power control MAC protocol. We found that the BASIC scheme has a shortcoming that can degrade the throughput. Furthermore, the BASIC

Scheme may potentially increase the energy consumption, instead of decreasing it. We elaborate a power-aware routing optimization, determines routes which consume low energy. PARO chooses a cost function based on the transmit power level at each hop on a

Route, to determine a low energy-consuming route between a pair of nodes. PARO also uses a power control MAC protocol similar to BASIC. Several other routing metrics. A power control protocol presented is also similar to the BASIC scheme. It maintains a table for the minimum transmits power necessary to communicate with neighbor nodes. This scheme allows each node to increase or decrease its power level dynamically. However, different power levels among nodes result in asymmetric links, causing col-
lesions’ power control protocol proposed in uses one control channel and multiple data channels. A control channel is used to assign data channels to nodes. An RTS, CTS,

RES (a special packet), and broadcast packets are transmitted through the control channel using the highest transmit power. By an RTS-CTS handshake, source and destination
Nodes decide which channel and what power level to use for data transmissions. On the reception of CTS, the source sends an RES to the destination to reserve a data channel.

Then, DATA and ACK transmissions occur on the reserved data channel using the negotiated power level from the RTS-CTS handshake. Transmit power is controlled according to packet size. The proposed scheme is based on the observation
that reducing transmission power can result in energy savings, but can also result in more errors. A higher bit error rate can lead to increased retransmissions, consuming more

Energy. Thus, the protocol chooses an appropriate transmission power level based on the packet size. An adaptive scheme is also presented in to choose MAC frame
Size based on the channel conditions. IEEE 802.11 may result in unfairness (performance degradation) for nodes which use lower transmission power than their neighbor nodes. Poojary et al. propose a scheme to improve the fairness. COMPOW selects a common power level at all nodes in the network to ensure bi-directional links. Each node runs several routing daemons, each at a different power level. The power level is chosen to be the smallest power level which achieves the same level of network connectivity as the highest power level.

Thursday, May 20, 2010

Self- Organized Public Key Management


A self-organized approach for public key certificates, which is similar to PGP , but unlike PGP it does not depend on the certificate directories for the distribution of certificates. In this key management service the need for the existence of a centralized certification authority is omitted and every node in the network is responsible for generating their keys, issuing, storing and distributing public key certificates. The key management scheme is said to be self-organized, as it does not require any external configuration or management.

The relationship between users of the system is denoted by a directed trust graph G (V, E), where the vertices represent the nodes and an edge E denotes a public key certificate.

The main working principle is, each user maintains a local repository, which contains a limited number of certificates selected by the users based on an algorithm. When a user u wants to verify the public key certificates of another user v, then they merge the local certificate repositories and user u tries to find a certificate chain to user v in the merged repository.

Following sub-sections discusses and analyses the various operations of the self organized key management scheme:

Generating Keys, Each user of the system generates its own public key and corresponding private key locally.

Issuing Certificates, Each user in the system has the capability to issue a public key certificate. Suppose user u gets a public key of another user v through a secure channel or from another user whom user u trusts. If a user u believes that a public key Kpub belongs to a user v, then it can issue a public key certificate for v, which is signed by u. The system assumes that users are honest and do not issue false certificates. So, if user u issues a public key certificate for user v, then there must exist a directed edge form vertex u to vertex v in the trust graph G (V, E)

Storing Certificates, As mentioned earlier, each user of the system maintains a local repository where it stores the public key certificates. The local repository consists of two parts; first, each user stores the certificates that it issues and the certificates issued to it. This is necessary, as in this process all the certificates that have been issued is stored at least once. Along with these each user stores a set of other certificates issued by other users. The later set of certificates is selected using a common algorithm. In terms of the system model, each user u selects a sub graph of the trust graph G (V, E) which consists of the outgoing edges and corresponding vertices from user u and an additional set of selected edges and corresponding vertices.


This key management scheme that does not require any existing infrastructure and nodes in the networks are responsible for issuing, distributing and storing certificates in a distributed manner. The key management service works like PGP, but instead of using separate directories, it uses the local repositories maintained by each user. Uses of public key cryptography ensure confidentiality and a decentralized approach means that there is no single point of failure. The proposal does not discuss about the scalability issue.

Some of the key points need to be mentioned regarding the efficiency of the proposed scheme:
• The proposed key management service lacks the certificate revocation mechanism, which is an important issue that should be considered.

• The authenticity of a received public key is achieved based on the probability of finding a certificate chain in the merged directory. Though, it was shown that the probability is always high if each user uses the same algorithm. Even though, all nodes may not be honest and issue false certificates. So, there is a risk using this type of model in applications where security and accountability is a prime issue.

• As discusses earlier that the proposed scheme is similar to PGP. Like PGP It has a problem in the initial stages of its execution before the number of certificates issued reaches to a certain number consider the scenario shown in fig, where a dashed line represent only friendship and a directed line represents a certificate. Now, if node 9 wants to communicate securely with node 1, it has to find a chain of certificate in the graph. But, as it is the initial stage and only nodes 2,8 and 9 have issued a certificate. So, node 9 has to wait for some other nodes to issue certificates to find a certificate chain between node 1 and 9

Key Distribution in Cluster Formation

Asymmetric decentralize approaches for key distribution

As key distribution based on a centralized key management server (i.e., Certification Authority) can leads the whole system to a single point of failure, the idea to share the :ask of key distribution in a distributed manner was attempted. The two schemes in the following sub sections, one is based on a partially distributed CA and another scheme uses a fully distributed certification authority (CA).
Partially distributed certification authority


A decentralized approach based on a public key infrastructure for key management where task of the CA is divided to a subset of nodes in the networks. Threshold Cryptography is used for establishing trust among the set of servers and the proposed key management service also uses share refreshing to achieve proactive security.


The task of the key management service is distributed over a certain number of nodes in the network called servers. The service as a whole has a service private key (skpriv) / public key (skpub). All the nodes in the system know the public key (skpub) of the service and trust any certificates that have been signed with the corresponding private key (skpriv). The normal nodes (i.e., client nodes), can requests to the key management service for other client's public key or for an update of its own public key. Fig shows the architecture of the key management services.

The n servers that are chosen arbitrarily, configured with an (n, H 1) threshold cryptographic scheme, where (n3t+ 1) and t is the maximum number of servers that can be compromised within a given period of time. Each server has its own public (Ki) / private key (ki) pair and knows the public key of all other servers. The private key of the service skpriv is divided into n shares (sl, s2, s3, s4 ..., sn) where each of the n servers gets one share each.


The key management scheme discussed ensures confidentiality as it uses threshold cryptography and the task of the CA is shared among some nodes. So, there is no single point of failure and authenticated nodes get the service done as and when requested. Thus, it ensures availability and by using share refreshing it keeps the shares of the secret key fresh. The key management service can changes its configuration to changing situations, which helps ensuring the scalability requirement.

Though the management technique is concrete and good one for distributing the task of a CA to a set of servers, it still have some lacking while implementing in a mobile ad hoc network environment from an efficiency point of view:

• The scheme do not addresses the issue of certificate revocation mechanism, which is very important for a service implementing public key infrastructure.

• It requires that all the server store certificates of all the nodes in the network. In that case, a new certificate is propagated to all the servers. Consider a segmentation of the network, and then a synchronization mechanism between the servers will be required.

• The use of public key and threshold cryptography requires a lot of computational tasks, which could consume the energies of small Energy constrained devices used in ad hoc networks.

• The availability of the key management service depends on an Assumption that in a given time at most t number of servers can be compromised, where t is the threshold parameter. So, higher the t is chosen, higher the security.

• The key management service requires that a given set of nodes do some specific task at a given time, which is suitable for a military environment. In a normal environment nodes may not behave in a pre- defined way

Tuesday, April 27, 2010

Wireless examples in Ns2

As many one requested iam posting wireless with many examples

Here iam posting the sample wireless examples the cluster formation methods
for cluster formation many algorithm are there but this is an simple basic wireless example one

Along with iam posting ping option in NS2 pinging of nodes

any ideas regarding in Ns2 can discuss here

Thursday, April 22, 2010

Cluster Formation In Manet

The cluster formation Every group of node is formed together and the arranged in one Group . The main purpose of cluster formation is the reduce the Transfer Rate and allocation of group in to subgroups and finally one leader will be selected.

For the Selection of Group various method will be used

1) Mine own favorite method is the Finding the near by neighbors and joined as the group
2) per group can have any no of nodes but mostly i assume 5 for maintanence
3) In cluster formation many groups can be made Inside cluster can also be made
4) Like tree structure also be made to reduce the level so reduce the traffic
5) These cluster formation many research are made iam also doing certain research and formed particular cluster formation with my algorithm along with existing and obtain a new one
6) Since it an combination two members i cannot post the algorithm in my Blog

7) so if want the cluster formation mail me I can help for the Codings

Friday, April 2, 2010

Wireless in Ns2 Example one


Here I like to post the Wireless in Ns2 .Mostly there are two types

1) Wired
2) Wireless

The main difference in coding extra antenna header files will be added in wireless as well as in the wired little bit tougher than the wireless one now iam posting wireless one in that any doubt you can contact me no problem

Enjoy learning NS2

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 .

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

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

– Association and Disassociation
– Peer-to-Peer Tree and Cluster Tree Formation
– Direct and Indirect (data polling and extraction)
– 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.


• $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

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

$ 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


Set environment variables

$ gedit ~/.bashrc

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
















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 "$"


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

$ cd ns-2.32 $ ./validate

Monday, March 1, 2010


* 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

* 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: Execute this script on the output file as follows:
+ python 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


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 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/ with this file: There is a small change to enable broadcast for DRAND packets.
o Replace ns2.26/trace/ 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).

Wednesday, February 24, 2010

The OS That Supports Ns2

1) Ubuntu all version especially 8.03 latest 9.01
2) Redhat 9 is perfect one for ns2
3) Centos we can install Ns2 some of terms will not be worked
4) Fedora Latest will be worked..for all these separate procedures to install

WINDOWS will support but better Linux will hold and stayed long without failing the Harddisk

Better Linux is preferrable for Ns2

And Current NS3 also prefer Linux

Friday, February 12, 2010


DRAND: Distributed TDMA Scheduling for Sensor Networks

DRAND has been implemented on NS-2 (version 2.26) as well as the TinyOS platform for sensor networks

• NS-2 installations instructions:

o Download the source tarball
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 .
o Add entry for DRAND packet type in (NS_INSTALL_DIRECTORY)/ns-2.26/common/packet.h as "PT_DRAND" - sample .
o Replace ns2.26/mac/ with this file: There is a small change to enable broadcast for DRAND packets.
o Replace ns2.26/trace/ with with this file: This adds support for DRAND packets.

• NS-2 execution instructions:

o Download the tcl script tarball
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
o In case of difficulties, contact Ajit Warrier.

• Software will be released soon.

Wednesday, February 10, 2010


The ns-2 WiMAX PMP module is originally designed and developed by Netowrks & Distributed Systems Laboratory (NDSL) members, Computer Science and Information Engineering, Chang Gung University, Taoyuan, Taiwan, under advisory of Professor Jenhui Chen. All versions of WiMAX modules (current IEEE 802.16d and upcoming IEEE 802.16e and IEEE 802.16j) are freely download for any academic or industrial use. We welcome colleagues to report any bug founded in our provided version and give us some suggestions. All recommendations are welcome. You may directly contact Professor Jenhui Chen or our ns-2 WiMAX module support team members

The Neswork Simulator 2 (ns-2) is an open source tool for various network simulations. The ns-2 provides substantial supports for simulation of the TCP, routing, and multicast protocols covered wired and wireless networks. ns has been a kind of real networks simulator since 1989 and and has been evolved substantially over the past few years. In 1995, the ns development was supported by VINT project at LBL, Xerox PARC, UCB, and USC/ISI. Currently ns development is support through DARPA with SAMAN and through NSF with CONSER, both in collaboration with other researchers including ACIRI .

The Network Simulator 2 (ns-2) is a popular and powerful simulation tool for the simulation of packet-switched networks, which provides substantial support for simulation of TCP, routing, and MAC protocols over wired and wireless networks, such as wireless LANs, mobile ad hoc networks (MANETs), and satellite communications, etc, and is widely used in both academia and industry. Although many protocol modules have been implemented in the ns-2, the IEEE 802.16 broadband wireless access networks (BWANs) or WiMAX module has not been contributed yet. Thus, in this paper, we present our detailed design and implementation of the WiMAX module based on the IEEE 802.16 standard with the point-to-multipoint (PMP) mode for the ns-2. The implemented module comprises fundamental functions of the service-specific convergence sublayer (CS), the MAC common part sublayer (CPS), and the PHY layer. A simple call admission control (CAC) mechanism and the scheduler are also included in this module.

Tuesday, February 9, 2010

Multicasting Key Distribution With Cluster Formation In Ad Hoc Network

A key management scheme for large-scale distributed sensor networks is based on symmetric key pre-distribution. The key pre-distribution is the only practical option for the networks whose physical topology is unknown prior to deployment or changes fast after deployment.


The key management scheme relies on probabilistic key sharing among the nodes in the network and takes help of a simple shared-key discovery protocol for key distribution, revocation and node re-keying. In the proposed scheme an offline trusted third party pre initializes each node of the network with a key ring. The key ring is consists of k keys chosen randomly from a large pull of keys named P. As the keys are chosen randomly, some pair of nodes may not share a common key
Key rings are constructed from randomly chosen keys from the large key pool P and distributed to every node. Suppose a pair of node (B,F) does not have a shared key exist among them. But, (B, C) and (C, F) node pairs have shared key among them. Nodes Band F can use the path exists between them (i.e., which have pair-wise key-sharing of nodes (B, C) and (C, F)) to exchange a key that establishes a direct link. So, the main motivation is, it does not require having full shared-key connectivity as offered by pair wise private key sharing between every two nodes in the network.

Basic operations
The following sub-sections describe the basic operations of this key management scheme.

Key Distribution
The major part of the scheme deals with key distribution, which consists of three parts namely key pre-distribution, shared-key discovery and path-key establishment.

The process of key pre-distribution is done offline with an aim to ensure each node with a moderate number of keys in its key ring so that any two nodes share a key with a chosen probability. Followings tasks are done in this step:

• Generate a large pool of P keys and corresponding key identifiers.

• Select k key randomly from P to form a key ring.

• Load the key ring to a node.

• Save the key identifier of a key ring and associated sensor identifier on a trusted controller.

• Load controller nodes with the keys they share with individual nodes.

In the shared-key discovery phase a node tries to find a neighbor within its communication range to whom it shares key. Two nodes can discover if they have a shared-key by broadcasting the list of key identifiers of the keys on their key rings. So, if corresponding nodes share a key, they will find a common key identifier and communication between those neighboring nodes will be secured. But, as the keys are chosen randomly, same key can be shared by more than a pair of nodes

After the completion of shared-key discovery phase, some pairs of nodes can be found that do not share a key but connected by a path consist of node pairs that share a key. In the path-key establishment phase a path-key is assigned to those selected pairs of nodes. Path keys are chosen from the unassigned keys left in the key rings.

Key Revocation
Key revocation is necessary when a node in the network is compromised. When a node is compromised, the associated controller node broadcasts a message containing signed key identifiers to request revoking the corresponding keys. After receiving the revocation message, each node verifies the signature of the key identifiers finds those key identifiers in its key ring and removes the corresponding keys. Removal of keys certainly will affect some of the links to disappear and those nodes will have to restart the shared-key discovery phase and likely path-key establishment phase.

Re-keying is needed when a node wants to revoke its keys (i.e., self-revocation) or lifetime of a key expires. Re-keying does not require any network wide message broadcast from a controller node and hence simple. As like key revocation the affected nodes after expired keys are revoked, need to start the shared-key discovery phase and possibly path-key establishment phase


This key management scheme is simple and considers the low computational power of the nodes. Based on the operational requirement, design parameters can be adopted. Like for a higher probability of finding a shared key between any two nodes, higher number of keys should be required in a key ring and so as the size of the key pool.
Looking to the fact that ad hoc networks are dynamic in nature, network topologies cannot be determined before deployment, low energy constraint devices etc; a key pre distribution scheme would be a better solution.

The scheme uses symmetric encryption which is fast and requires less computational operations. It ensures confidentiality. The proposed key pre-distribution scheme requires the availability of a trusted third party (i.e., large key pool) in the initialization phase to pre-load each node with a key ring and corresponding key identifies. So, it is evident that if the trusted third party is compromised, whole network will be in secured. This could be a limitation to apply this technique in many ad hoc network scenarios. In most of the ad hoc network scenario nodes do not know each other before deployment and get to know each other when they meet. Consider the scenarios like an emergency rescue, battlefield communication and conferencing. It is very likely that nodes in these cases do not have any prior knowledge to which it is going to meet. So, it is impractical to contact to same trusted third party for pre-distribution of keys. So, sharing the key pre-distribution task to all the nodes such that each node contributes in the key pre-distribution phase would be a viable solution.

Saturday, January 23, 2010


NS (version 2) is an object-oriented, discrete event driven network simulator developed at UC Berkely written in C++ and OTcl. NS is primarily useful for simulating local and wide area networks. Although NS is fairly easy to use once you get to know the simulator, it is quite difficult for a first time user, because there are few user-friendly manuals. Even though there is a lot of documentation written by the developers which has in depth explanation of the simulator, it is written with the depth of a skilled NS user. The purpose of this project is to give a new user some basic idea of how the simultor works, how to setup simulation networks, where to look for further information about network components in simulator codes, how to create new network components, etc., mainly by giving simple examples and brief explanations based on our experiences. Although all the usage of the simulator or possible network simulation setups may not be covered in this project, the project should help a new user to get started quickly

NS is an event driven network simulator developed at UC Berkeley that simulates variety of IP networks. It implements network protocols such as TCP and UPD, traffic source behavior such as FTP, Telnet, Web, CBR and VBR, router queue management mechanism such as Drop Tail, RED and CBQ, routing algorithms such as Dijkstra, and more. NS also implements multicasting and some of the MAC layer protocols for LAN simulations. 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. This document talks briefly about the basic structure of NS, and explains in detail how to use NS mostly by giving examples. Most of the figures that are used in describing the NS basic structure and network components are from the 5th VINT/NS Simulator Tutorial/Workshop slides and the NS Manual (formerly called "NS Notes and Documentation"), modified little bit as needed. For more information about NS and the related tools, visit the VINT project home page.