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
Wednesday, February 24, 2010
Friday, February 12, 2010
DRAND
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/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
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.
TinyOS
• Software will be released soon.
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/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
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
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.
TinyOS
• Software will be released soon.
Wednesday, February 10, 2010
IMPLEMENTATION OF WIMAX IN NS2
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.
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.
Overview
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
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
Analysis
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.
Overview
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
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
Analysis
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.
Subscribe to:
Posts (Atom)
