PARUL INSTITUTE OF TECHNOLOGY

ELECTRONICS AND COMMUNICATION ENGINEERING DEPARTMENT

OPEN ENDED PROBLEM
Name :
Class :
Date :

Subject:
Code :
Er.No. :

PATEL JAY C
ME SEM-II

WMC
2720501
140870705004

Aim:
Show that if n=4, a cell can be split into four smaller cells, each with half the radius and 1/16 of the
transmitter power of the original cell. If the extensive measurements show that the path loss exponent
is 3, how should the transmitter power be changed in order to split a cell into four smaller cells? What
impact will this have on the cellular geometry? Explain your answer and provide drawings that show
how the new cells would fit within the original macrocells.

Solution:

Let, R be the original radius of the cell before it is splitted; Pt1 its transmitted power and Pr
be the received power at the boundary.

Pr old cell boundry Pt1 R n

Now, let the cell be splitted with the radius half the original cell; then, it will be divided
into 4 cells. This is illustrated in the diagram.

Original Cell

When Cell is Splitted

a
R

a/2

R/2

R
Pr New cell boundry Pt 2
2

where Pt1 and Pt2 are the transmit powers of the larger and smaller cell base stations, respectively, and
n is the path loss exponent.

pt 2

pt1
2n

If we take n = 4 and set the received powers equal to each other, then

pt 2

pt1
16

In other words, the transmit power must be reduced by 12 dB in order to fill in the original coverage
area with microcells, while maintaining the S/I requirement.

Assuming Square Cell, we can show that when cell radius is made half, its area will be splitted into 4
equal parts.
And when path loss component n = 3,

pt 2

pt1
8

In other words, for n=3,the transmit power must be reduced by 9 dB in order to fill in the original
coverage area with microcells, while maintaining the S/I requirement.

Aim:

Solution:

When d>>(ht+hr), phase difference between the two paths

= (4hthr d), from the two ray model
d=(4hthr /)Tani= (ht+hr)/d < tan 5
(ht+hr)/ (4hthr /) <tan5
For hr=2m,=6.261,=0.333m,ht>2/(4
x 2 x tan5/0.333 x 6.261)-1
htmin= 37.7m

Aim:
Analyze any wireless network of your choice using different routing algorithms covered in
syllabus using NS-2 .

Solution:

Simulation of AdHoc Networks

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
Plante research group at INRIA Sophia-Antipolis. Currently ns-3 is in development phase. It
is
an
event
based
network
simulator.
(http://www.wikipedia.org/ns.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 users 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 othernode 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 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 architectures 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.
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 link is another major compound object in NS. When a user creates a 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 link object.
Packets dequeued from a queue are passed to the Delay object that simulates the 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 dstnodes 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 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 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 packets 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).

Radio Propagation Model

It uses Friss-space attenuation (1/r2) at near distances and an approximation to Two ray
Ground (1/r4) at far distances. The approximation assumes specular reflection off a flat
ground plane.

Antenna
An omni-directional antenna having unity gain is used by mobilenodes.

Description of Tcl Commands used:

1. The set and val( ) keywords are used to initialize the configuration parameters,
as shown below.
set val(chan) Channel/WirelessChannel

2. The new keyword is used to create a new object reference to a particular class, as
shown below.
set ns [new Simulator]

3. The open keyword is used to open a file in the given r/w/x mode. If that particular
file does not exist, it is created and opened, as shown below.
set tf [open wireless.tr w]

4. The trace-all function is used to trace the events in the opened trace file (*.tr).

5. The namtrace-all-wireless function is to trace the events in the nam file created
(*.nam).
6. The load_flatgrid function is used to load the topography value of the simulation,
like 1000 x 1000, as shown below.
$topo load_flatgrid 1000 1000

7. The create-god function is used to create the General Operations Director.

8. The node-config function is used to configure the node by setting in it the
configuration parameters.
9. The attach-agent function is used to link one agent/application to another
node/agent respectively.
10. The setdest function is used to set the position of the node at a particular time.
11. The start and stop keywords are used to start and stop the application
respectively.
12. The proc keyword is used to indicate a procedure or a function.
13. The flush-trace function is used to flush the traced events into the trace files.
14. The run keyword is used to run the file.

Topology Diagram and Simulation Parameters

Topology Diagram and Simulation Parameters

Application
starts at 0.5 sec

stops at 1000 sec

Simulation Time 1000 sec
Topography = 1000 x 1000
Node Movement:
Time

Node

(x, y, z)

10

(500, 900, 0)

50

(500, 100, 0)

Configurtion Parameters:
Channel Type : Wireless Channel
Radio propagation model : TwoRay Ground
Network Interface type : Wireless Phy
MAC Type : 802-11
Interface Queue Type : PriQueue
LinkLayer type : LL
Antenna model : Omni Antenna
Max. Pts in ifq : 50
No. of mobile nodes : 3
Routing Protocol : DSDV

Procedure
1. Initialize the network configuration parameters of the network to be simulated
using the 'set' keyword and the 'val()' keyword.
2. While initializing, the super class of the particular class is also denoted. The
example of an initialization is
set val(chan) Channel/WirelessChannel

3. The values of link layer type, interface queue length, the number of nodes and the

routing protocol variables can be directly given without any superclass.

ex.: set val(ll) LL
set val(nn) 3

4. Create an object (say, ns) for the Simulator class using the 'set' keyword, and 'new'
keyword.
set ns [new Simulator]

5. Create and open a trace file with write mode (i.e., w) using 'set' and 'open'
keywords.
set tf [open wireless.tr w]

6. Using the 'trace-all' function, set the ns object to trace all the events and write the
trace file created.
7. Create a nam file in write mode and using 'namtrace-all-wireless' function, with
arguments as the nam file handler and the topography values (here, 1000 x 1000),
the events traceds are put in nam file.
8. Create an object for the Topography class and give the values (1000 x 1000) in the
load_flatgrid' function.
9. Pass the value of the number of nodes to the 'create-god' function.
10. Set the values for the arguments of the 'node-config' function with all the
configuration parameter values.
11. Create the nodes 0, 1 and 2 using the 'set' and '$ns' keywords shown.
set node0 [$ns node]

12. Set the position of the nodes in the X_, Y_ and Z_ variables using 'set' keyword.
13. Create the TCP agent and attach it to node0 using the 'attach-agent' function.
14. Similarly create the object for FTP Application and attach it to the TCP object

using 'attach-agent' function.

15. Create the object for the TCP Sink and attach it to the node2 using 'attach-agent'
function.
16. Connect the TCP object to the TCPSink object using the 'connect' function.
17. Set the movement of node1 using 'at' keyword, specifying the time in seconds and
the position in x, y, z values using 'setdest' function.
18. The application start time and stop time are specified using the 'at' keyword along
with the 'start' and 'stop' keywords.
19. The Simulation stop time is indicated using the 'at' keyword and call the 'finish'
procedure.
20. Inside the 'finish' procedure, set the values ns, tf and tf1 as 'global'.
21. Call the 'flush-trace' function to write all the events traced in the trace files.
22. Close the trace file using 'close' function.
23. Execute the nam file using 'exec' keyword and put & at the end of the line.
24. Call the 'exit' function with parameter '0', and close the 'finish' procedure.
25. Run the simulation using the 'run' keyword.
26. Close the editor and run the .tcl file to get the output. Thus the simulation of adhoc
networks is made.

Program
set val(chan) Channel/WirelessChannel
set val(prop) Propagation/TwoRayGround
set val(netif) Phy/WirelessPhy
set val(mac) Mac/802_11
set val(ifq) Queue/DropTail/PriQueue
set val(ll) LL

set val(ant) Antenna/OmniAntenna

set val(ifqlen) 50
set val(nn) 3
set val(rp) DSDV
set ns [new Simulator]
set tf [open ex2_09hr002.tr w]
$ns trace-all $tf
set tf1 [open ex2_09hr002.nam w]
$ns namtrace-all-wireless $tf1 100 100
set topo [new Topography]
$topo load_flatgrid 100 100
create-god $val(nn)
$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
set node0 [$ns node]
set node1 [$ns node]
set node2 [$ns node]
$ns initial_node_pos $node0 10
$ns initial_node_pos $node1 10
$ns initial_node_pos $node2 10
$node0 set X_ 25.0
$node0 set Y_ 50.0
$node0 set Z_ 0.0
$node1 set X_ 50.0
$node1 set Y_ 50.0
$node1 set Z_ 0.0

$node2 set X_ 65.0

$node2 set Y_ 50.0
$node2 set Z_ 0.0
set tcp1 [new Agent/TCP]
$ns attach-agent $node0 $tcp1
set ftp [new Application/FTP]
$ftp attach-agent $tcp1
set sink1 [new Agent/TCPSink]
$ns attach-agent $node2 $sink1
$ns connect $tcp1 $sink1
$ns at 10.0 "$node1 setdest 50.0 90.0 0.0"
$ns at 50.0 "$node1 setdest 50.0 10.0 0.0"
$ns at 0.5 "$ftp start"
$ns at 1000 "$ftp stop"
$ns at 1000 "finish"
proc finish {} {
global ns tf tf1
$ns flush-trace
close $tf
exec nam ex2_09hr002.nam &
exit 0
}
$ns run

Output