ns2 coding for wireless bandwidth estimation
#1

pls send the source code for the performance evaluation of vanet uing IEEE802.11p DCF protocol
Reply
#2

ns2:

ns or the network simulator (also popularly called ns-2, in reference to its current generation) is a discrete event network simulator. It is popular in academia for its extensibility (due to its open source model) and plentiful online documentation. ns is popularly used in the simulation of routing and multicast protocols, among others, and is heavily used in ad-hoc networking research. ns supports an array of popular network protocols, offering simulation results for wired and wireless networks alike. It can be also used as limited-functionality network emulator. ns is licensed for use under version 2 of the GNU General Public License.

ns was built in C++ and provides a simulation interface through OTcl, an object oriented dialect of Tcl. The user describes a network topology by writing OTcl scripts, and then the main ns program simulates that topology with specified parameters. The NS2 makes use of flat earth model in which it assumes that the environment is flat without any elevations or depressions. However the real world does have geographical features like valleys and mountains. NS2 fails to capture this model in it.

Many researchers have proposed the additions of new models to NS2. Shadowing Model in NS2 attempts to capture the shadow effect of signals in real life, but does that inaccurately. NS2's shadowing model does not consider correlations: a real shadowing effect has strong correlations between two locations that are close to each other. Shadow fading should be modeled as a two dimensional log-normal random process with exponentially decaying spatial correlations.

Generation 3 of ns has begun development as of July 1, 2006 and is projected to take four years. It is funded by the institutes like University of Washington, Georgia Institute of Technology and the ICSI Center for Internet Research with collaborative support from the Planète research group at INRIA Sophia-Antipolis. Currently ns-3 is in development phase. It is an event based network simulator. (http://wikipedians.htm).





ns is an object oriented simulator, written in C++, with an OTcl interpreter as a frontend. The simulator supports a class hierarchy in C++ (also called the compiled hierarchy in this document), and a similar class hierarchy within the OTcl interpreter (also called the interpreted hierarchy in this document). The two hierarchies are closely related to each other; from the user’s perspective, there is a one-to-one correspondence between a class in the interpreted hierarchy and one in the compiled hierarchy.

The root of this hierarchy is the class TclObject. Users create new simulator objects through the interpreter; these objects are instantiated within the interpreter, and are closely mirrored by a corresponding object in the compiled hierarchy. The interpreted class hierarchy is automatically established through methods defined in the class TclClass. user instantiated objects are mirrored through methods defined in the class TclObject. There are other hierarchies in the C++ code and OTcl scripts; these other hierarchies are not mirrored in the manner of TclObject.



Ad Hoc Networking:

A wireless ad hoc network is a decentralized wireless network. The network is ad hoc because it does not rely on a pre-existing infrastructure, such as routers in wired networks or access points in managed (infrastructure) wireless networks. Instead, each node participates in routing by forwarding data for other nodes, and so the determination of which nodes forward data is made dynamically based on the network connectivity. The earliest wireless ad hoc networks were the "packet radio" networks (PRNETs) from the 1970s, sponsored by DARPA after the ALOHAnet project.

The decentralized nature of wireless ad hoc networks makes them suitable for a variety of applications where central nodes can't be relied on, and may improve the scalability of wireless ad hoc networks compared to wireless managed networks, though theoretical and practical limits to the overall capacity of such networks have been identified. Minimal configuration and quick deployment make ad hoc networks suitable for emergency situations like natural disasters or military conflicts. The presence of a dynamic and adaptive routing protocol will enable ad hoc networks to be formed quickly.

In most wireless ad hoc networks the nodes compete to access the shared wireless medium, often resulting in collisions. Using cooperative wireless communications improves immunity to interference by having the destination node combine self-interference and other-node interference to improve decoding of the desired signal.

Wireless ad hoc networks can be further classified by their application:

* mobile ad hoc networks (MANETs)

* wireless mesh networks

* wireless sensor networks.

Mobile ad hoc Networks:

A mobile ad hoc network (MANET), sometimes called a mobile mesh network, is a self-configuring network of mobile devices connected by wireless links. Each device in a MANET is free to move independently in any direction, and will therefore change its links to other devices frequently. Each must forward traffic unrelated to its own use, and therefore be a router. The primary challenge in building a MANET is equipping each device to continuously maintain the information required to properly route traffic. Such networks may operate by themselves or may be connected to the larger Internet.

MANETs are a kind of wireless ad hoc networks that usually has a routeable networking environment on top of a Link Layer ad hoc network. They are also a type of mesh network, but many mesh networks are not mobile or not wireless. The growth of laptops and 802.11/Wi-Fi wireless networking have made MANETs a popular research topic since the mid- to late 1990s. Many 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.

* Vehicular Ad Hoc Networks (VANETs) are used for communication among vehicles and between vehicles and roadside equipment.

* Intelligent vehicular ad hoc networks (InVANETs) are a kind of artificial intelligence that helps vehicles to behave in intelligent manners during vehicle-to-vehicle collisions, accidents, drunken driving etc.

* Internet Based Mobile Ad-hoc Networks (iMANET) are ad-hoc networks that page link mobile nodes and fixed Internet-gateway nodes. In such type of networks normal ad-hoc routing algorithms don't apply directly.

Wireless Mesh Networks:

A wireless mesh network (WMN) is a communications network made up of radio nodes organized in a mesh topology. Wireless mesh networks often consist of mesh clients, mesh routers and gateways. The mesh clients are often laptops, cell phones and other wireless devices while the mesh routers forward traffic to and from the gateways which may but need not connect to the Internet. The coverage area of the radio nodes working as a single network is sometimes called a mesh cloud. Access to this mesh cloud is dependent on the radio nodes working in harmony with each other to create a radio network. A mesh network is reliable and offers redundancy. When one node can no longer operate, the rest of the nodes can still communicate with each other, directly or through one or more intermediate nodes.

The animation below illustrates how wireless mesh networks can self form and self heal. Wireless mesh networks can be implemented with various wireless technology including 802.11, 802.16, cellular technologies or combinations of more than one type. A wireless mesh network can be seen as a special type of wireless ad-hoc network. It is often assumed that all nodes in a wireless mesh network are immobile but this need not be so. The mesh routers may be highly mobile. Often the mesh routers are not limited in terms of resources compared to other nodes in the network and thus can be exploited to perform more resource intensive functions. In this way, the wireless mesh network differs from an ad-hoc network since all of these nodes are often constrained by resources.

Wireless mesh architecture is a first step towards providing high-bandwidth network over a specific coverage area. Wireless mesh architecture’s infrastructure is, in effect, a router network minus the cabling between nodes. It's built of peer radio devices that don't have to be cabled to a wired port like traditional WLAN access points (AP) do. Mesh architecture sustains signal strength by breaking long distances into a series of shorter hops. The intermediate nodes, not only boost the signal but cooperatively make forwarding decisions based on their knowledge of the network, i.e. performs routing. Such an architecture may, with careful design, provide high bandwidth, spectral efficiency, and economic advantage over the coverage area.

Example of three types of wireless mesh network:

* Infrastructure wireless mesh networks: Mesh routers form an infrastructure for clients.

* Client wireless mesh networks: Client nodes constitute the actual network to perform routing and configuration functionalities.

* Hybrid wireless mesh networks: Mesh clients can perform mesh functions with other mesh clients as well as accessing the network.

Wireless mesh network have a relatively stable topology except for the occasional failure of nodes or addition of new nodes. The traffic, being aggregated from a large number of end users, changes infrequently. Practically all the traffic in an infrastructure mesh network is either forwarded to or from a gateway, while in ad hoc networks or client mesh networks the traffic flows between arbitrary pairs of nodes.

This type of infrastructure can be decentralized (with no central server) or centrally managed (with a central server), both are relatively inexpensive, and very reliable and resilient, as each node needs only transmit as far as the next node. Nodes act as routers to transmit data from nearby nodes to peers that are too far away to reach in a single hop, resulting in a network that can span larger distances. The topology of a mesh network is also more reliable, as each node is connected to several other nodes. If one node drops out of the network, due to hardware failure or any other reason, its neighbors can find another route using a routing protocol.

Wireless Sensor Networks:

A wireless sensor network (WSN) consists of spatially distributed autonomous sensors to cooperatively monitor physical or environmental conditions, such as temperature, sound, vibration, pressure, motion or pollutants. The development of wireless sensor networks was motivated by military applications such as battlefield surveillance. They are now used in many industrial and civilian application areas, including industrial process monitoring and control, machine health monitoring, environment and habitat monitoring, healthcare applications, home automation, and traffic control.



Fig. 1 Sample Wireless Sensor Network

In addition to one or more sensors, each node in a sensor network is typically equipped with a radio transceiver or other wireless communications device, a small microcontroller, and an energy source, usually a battery. A sensor node, as shown in fig. 1, might vary in size from that of a shoebox down to the size of a grain of dust, although functioning "motes" of genuine microscopic dimensions have yet to be created. The cost of sensor nodes is similarly variable, ranging from hundreds of dollars to a few pennies, depending on the size of the sensor network and the complexity required of individual sensor nodes. Size and cost constraints on sensor nodes result in corresponding constraints on resources such as energy, memory, computational speed and bandwidth.

A sensor network normally constitutes a wireless ad-hoc network, meaning that each sensor supports a multi-hop routing algorithm (several nodes may forward data packets to the base station). In computer science and telecommunications, wireless sensor networks are an active research area with numerous workshops and conferences arranged each year.

Unique characteristics of a WSN include:

* Limited power they can harvest or store

* Ability to withstand harsh environmental conditions

* Ability to cope with node failures

* Mobility of nodes

* Dynamic network topology

* Communication failures

* Heterogeneity of nodes

* Large scale of deployment

* Unattended operation

* Node capacity is scalable,only limited by bandwidth of gateway node.

Sensor nodes can be imagined as small computers, extremely basic in terms of their interfaces and their components. They usually consist of a processing unit with limited computational power and limited memory, sensors (including specific conditioning circuitry), a communication device (usually radio transceivers or alternatively optical), and a power source usually in the form of a battery. Other possible inclusions are energy harvesting modules, secondary ASICs, and possibly secondary communication devices (e.g. RS-232 or USB).

The base stations are one or more distinguished components of the WSN with much more computational, energy and communication resources. They act as a gateway between sensor nodes and the end user.

Basic Wireless Model:

The wireless model essentially consists of the MobileNode at the core,with additional supporting features that allows simulations of multi-hop ad-hoc networks, wireless LANs etc. The MobileNode object is a split object. The C++ class MobileNode is derived from parent class Node. A MobileNode thus is the basic Node object with added functionalities of a wireless and mobile node like ability to move within a given topology, ability to receive and transmit signals to and from a wireless channel etc. A major difference between them, though, is that a MobileNode is not connected by means of Links to other nodes or mobilenodes.

Routing Protocols:

The four ad-hoc routing protocols that are currently supported are Destination Sequence Distance Vector (DSDV), Dynamic Source Routing (DSR), Temporally ordered Routing Algorithm (TORA) and Adhoc On-demand Distance Vector (AODV). The old APIs for creating a mobilenode depended on which routing protocol was used.

Creating Mobile Nodes:

Before creating the mobile nodes, their topology has to be manually defined. When the topology of the network to be simulated is drafted, then the first step would be to create the mobile nodes. Then the node movement is set. Then the agents and applications are defined for that particular network topology.

From the topology, a basic idea of the network to be simulated is obtained. For that topology, the node-config parameters are set first. This is shown below.

$ns node-config -adhocRouting $val(rp) \

-llType $val(ll) \

-macType $val(mac) \

-ifqType $val(ifq) \

-ifqLen $val(ifqlen) \

-antType $val(ant) \

-propType $val(prop) \

-phyType $val(netif) \

-channelType $val(chan) \

-topoInstance $topo \

-agentTrace ON \

-routerTrace OFF \

-macTrace OFF \

-movementTrace OFF

After setting the node configuration parameters, the actual nodes are created. The code for creating nodes is given below.

for { set j 0 } { $j < $val(nn)} {incr j} {

set node_($j) [ $ns_ node ]

$node_($i) random-motion 0 ;# disable random motion

}

Thus the mobile nodes are created.

Setting Mobile Node Movements:

The mobilenode is designed to move in a three dimensional topology. However the third dimension (Z) is not used. That is the mobilenode is assumed to move always on a flat terrain with Z always equal to 0. Thus the mobilenode has X, Y, Z(=0) co-ordinates that is continually adjusted as the node moves. There are two mechanisms to induce movement in mobilenodes. In the first method, starting position of the node and its future destinations may be set explicitly. These directives are normally included in a separate movement scenario file.

But the scenario can also be defined manually in the program.



The start-position and future destinations for a mobilenode may be set by using the following APIs:

$node set X_ <x1>

$node set Y_ <y1>

$node set Z_ <z1>

$ns at $time $node setdest <x2> <y2> <speed>

At $time sec, the node would start moving from its initial position of (x1,y1) towards a destination (x2,y2) at the defined speed. In this method the node-movement-updates are triggered whenever the position of the node at a given time is required to be known. This may be triggered by a query from a neighbouring node seeking to know the distance between them, or the setdest directive described above that changes the direction and speed of the node.

Topology Definition:

Irrespective of themethods used to generate nodemovement, the topography for mobilenodes needs to be defined. It should be defined before creating mobilenodes. Normally flat topology is created by specifying the length and width of the topography using the following primitive:

set topo [new Topography]

$topo load_flatgrid $val(x) $val(y)

where val(x) and val(y) are the boundaries used in simulation.

Procedure for Node Movement:

The movement of mobilenodes may be logged by using a procedure like the following:

proc log-movement {} {

global logtimer ns_ ns

set ns $ns_

source ../mobility/timer.tcl

Class LogTimer -superclass Timer

LogTimer instproc timeout {} {

global opt node_;

for {set i 0} {$i < $opt(nn)} {incr i} {

$node_($i) log-movement

}

$self sched 0.1

}

set logtimer [new LogTimer]

$logtimer sched 0.1

}

In this case, mobilenode positions would be logged every 0.1 sec.

Link:

A page link is another major compound object in NS. When a user creates a page link using a duplex-link member function of a Simulator object, two simplex links in both directions are created.



The output queue of a node is actually implemented as a part of simplex page link object. Packets dequeued from a queue are passed to the Delay object that simulates the page link delay, and packets dropped at a queue are sent to a Null Agent and are freed there. Finally, the TTL object calculates Time To Live parameters for each packet received and updates the TTL field of the packet.

Tracing:

In NS, network activities are traced around simplex links. If the simulator is directed to trace network activities (specified using $ns trace-all file or $ns namtrace-all file), the links created after the command will have the following trace objects. Users can also specifically create a trace object of type type between the given src and dst nodes using the create-trace {type file src dst} command.

When each inserted trace object (i.e. EnqT, DeqT, DrpT and RecvT) receives a packet, it writes to the specified trace file without consuming any simulation time, and passes the packet to the next network object.

Packet:

A NS packet is composed of a stack of headers, and an optional data space. A packet header format is initialized when a Simulator object is created, where a stack of all registered (or possibly useable) headers, such as the common header that is commonly used by any objects as needed, IP header, TCP header, RTP header (UDP uses RTP header) and trace header, is defined, and the offset of each header in the stack is recorded.



Usually, a packet only has the header stack (and a data space pointer that is null). Although a packet can carry actual data (from an application) by allocating a data space, very few application and agent implementations support this. This is because it is meaningless to carry data around in a non-real-time simulation. However, if you want to implement an application that talks to another application cross the network, you might want to use this feature with a little modification in the underlying agent implementation. Another possible approach would be creating a new header for the application and modifying the underlying agent to write data received from the application to the new header.

Commands at a Glance:

Following is a list of commands used in wireless simulations:

$ns_ node-config -addressingType <usually flat or hierarchical used for

wireless topologies>

-adhocRouting <adhoc rotuing protocol like DSDV, DSR,

-llType <LinkLayer>

-macType <MAC type like Mac/802_11>

-propType <Propagation model like

Propagation/TwoRayGround>

-ifqType <interface queue type like

Queue/DropTail/PriQueue>

-ifqLen <interface queue length like 50>

-phyType <network inteface type like

Phy/WirelessPhy>

-antType <antenna type like Antenna/OmniAntenna>

-channelType <Channel type like Channel/WirelessChannel>

-topoInstance <the topography instance>

-wiredRouting <turning wired routing ON or OFF>

-mobileIP <setting the flag for mobileIP ON or OFF>

-energyModel <EnergyModel type>

-initialEnergy <specified in Joules>

-rxPower <specified in W>

-txPower <specified in W>

-agentTrace <tracing at agent level turned ON or OFF>

-routerTrace <tracing at router level turned ON or OFF>

-macTrace <tracing at mac level turned ON or OFF>

-movementTrace <mobilenode movement logging turned

ON or OFF>

Network Components in Mobilenode:

The network stack for a mobilenode consists of a page link layer(LL), an ARP module connected to LL, an interface priority queue(IFq), a mac layer(MAC), a network interface(netIF), all connected to the channel. These network components are created and plumbed together in OTcl. Each component is briefly described here.



Link Layer The LL used by mobilenode is same as described in Chapter 14. The only difference being the page link layer for mobilenode, has an ARP module connected to it which resolves all IP to hardware (Mac) address conversions. Normally for all outgoing (into the channel) packets, the packets are handed down to the LL by the Routing Agent. The LL hands down packets to the interface queue. For all incoming packets (out of the channel), the mac layer hands up packets to the LL which is then handed off at the node_entry_ point.

ARP The Address Resolution Protocol (implemented in BSD style) module receives queries from Link layer. If ARP has the hardware address for destination, it writes it into the mac header of the packet. Otherwise it broadcasts an ARP query, and caches the packet temporarily. For each unknown destination hardware address, there is a buffer for a single packet. Incase additional packets to the same destination is sent to ARP, the earlier buffered packet is dropped. Once the hardware address of a packet’s next hop is known, the packet is inserted into the interface queue. The class ARPTable is implemented in ~ns/arp.{cc,h} and ~ns/tcl/lib/ns-mobilenode.tcl.



Interface Queue The class PriQueue is implemented as a priority queuewhich gives priority to routing rotocol packets, inserting them at the head of the queue. It supports running a filter over all packets in the queue and removes those with a specified destination address. See ~ns/priqueue.{cc,h} for interface queue implementation.



Mac Layer Historically, ns-2 (prior to release ns-2.33) has used the implementation of IEEE 802.11 distributed coordination function (DCF) from CMU. Starting with ns-2.33, several 802.11 implementations are available.

Tap Agents Agents that subclass themselves as class Tap defined in mac.h can register themselves with the mac object using method installTap(). If the particular Mac protocol permits it, the tap will promiscuously be given all packets received by the mac layer, before address filtering is done.



Network Interfaces The Network Interphase layer serves as a hardware interface which is used by mobilenode to access thechannel. The wireless shared media interface is implemented as class Phy/WirelessPhy. This interface subject to collisions and the radio propagation model receives packets transmitted by other node interfaces to the channel. The interface stamps each transmitted packet with the meta-data related to the transmitting interface like the transmission power, wavelength etc. This meta-data in pkt header is used by the propagation model in receiving network interface to determine if the packet has minimum power to be received and/or captured and/or detected (carrier sense) by the receiving node. The model approximates the DSSS radio interface (LucentWaveLan direct-sequence spread-spectrum).
Reply

Important Note..!

If you are not satisfied with above reply ,..Please

ASK HERE

So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page
Popular Searches: book on ns2 coding for wireless sensor network, tatamotors hierarchy, bandwidth code in ns2, code for bandwidth estimation in ns2, tatamotors of hierarchy, matlab coding for bandwidth compression, bandwidth estimation for tcp source code in ns2,

[-]
Quick Reply
Message
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  wireless communication notes by arun kumar pdf 2 1,359 11-06-2017, 11:50 AM
Last Post: mahantesh mm
  bus reservation system coding in netbeans 2 1,132 16-05-2017, 12:58 PM
Last Post: kamal A
Wink solution manual for principles of wireless networks by kaveh pahlavan free download 2 1,452 09-09-2016, 05:31 AM
Last Post: ignitedmind
  multiuser sms based wireless noticeboard ppt 2 701 22-07-2016, 04:06 PM
Last Post: dhanabhagya
  tcl source code for genetic algorithm to find the shortest path in ns2 2 811 21-07-2016, 03:04 PM
Last Post: dhanabhagya
  wireless ac power 230v line electrical appliances controlling system 2 815 15-07-2016, 02:14 PM
Last Post: jaseela123d
  ant colony optimization source code in ns2 2 754 12-07-2016, 11:26 AM
Last Post: jaseela123d
  source code of intrusion detection system in manet using ns2 2 816 09-07-2016, 03:18 PM
Last Post: seminar report asees
  wireless sensor networks previous year question papers with answers 1 750 02-07-2016, 03:33 PM
Last Post: visalakshik
  pso algorithm ns2 code 1 535 02-07-2016, 10:47 AM
Last Post: visalakshik

Forum Jump: