Distributed Localization Scheme For Mobile Sensor Networks Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Localization is a significantly vital research issue in wireless sensor networks (WSNs) which mainly focuses on static sensor networks. Mobile sensors that are used to enlarge a sensed area depict the importance of designing a localization scheme in mobile sensor networks. This paper is a proposal of two schemes which increases the accuracy of localization in the previous scheme. First scheme is that, the normal nodes without geographical information has the ability to estimate their own locations with the help of known positions of anchor nodes which in turn helps in finding the locations of the one-hop normal nodes which is estimated from them. The second proposed scheme is that, it can estimate the moving direction of sensor nodes thereby increasing the accuracy level of localization. The quality of our scheme proposed is supported by the simulation results that the localization error in our proposed scheme is lower when compared to existing schemes in many of the mobility models and moving speeds.



Now a days, wireless sensor networks (WSNs) [1], [5] have been extensively used in a wide range of applications such as military operations, medical treatments, and the monitoring of the environment prevailing among the animals and their behavior in the forest. In many of the applications it was assumed that sensor nodes will have their positions known intact. For instance, the sensed data must go hand in hand with location information enabling the server to track the position of an expired event. Global Positioning System (GPS) equipment which is used to get the sensor's location is not cost effective expensive and it cannot be used indoors. Almost all applications require coarse localization accuracy, and that the cost effective solution is that anchor nodes (location aware nodes) of sensor network should come along with a GPS device, while the localization scheme helps the normal nodes (unaware of their location) get their positions automatically.

The localization schemes proposed earlier over this decade were designed for static sensor networks [11], [13], [14], [20], [26] most of which assume that sensors are nothing but mobile phones which know their own locations. In target tracking, the sensor nodes have been found to know their areas by tracking the locations of moving objects and that, the sensor nodes are found mobile in order to enlarge the sensing region, which explains the necessity of designing a localization scheme for mobile sensor networks. A Monte Carlo Localization (MCL) scheme specifically made for a mobile sensor network is proposed [12] in which, every sensor node is a mobile node. Every normal node collects the locations of its one-hop and two-hop anchor nodes by exchanging messages, and forms a new location set in almost all time slot.

The possible location set comprises various coordinates that help the normal node in locating others. The resulting possible locations are constrained by the communication range of anchor nodes and the region of location set in motion during the previous time slot, thereby handicapping the low anchor density in MCL, meaning the MCL fails to work well. By making use of the Monte Carlo method another range-free algorithm was designed and named as The Mobile and Static sensor network Localization (MSL) [19]. MSL uses the location estimation of all neighbors (not just anchor nodes) thereby improves the accuracy of location. The aforementioned designs and method are time-consuming since it is essential to keep sampling and filtering until enough samples are obtained to construct a new possible location set in every time slot. A bounding box (BB) method used to reduce the scope of searching the candidate samples is proposed in [22].

In this paper, we have a proposed a distributed localization approach to improve the localization error found in the previous methods. The proposed designed based on the Monte Carlo method. In this method, the possible locations of a normal node are constrained both from anchor nodes and from its one-hop normal nodes with calculated locations from the anchor nodes. Simulation results enables us to understand that the performance of my proposed scheme is better when compared to all of those previous schemes based on the fact that each normal node predicts its moving direction to drop some positions which can be neglected as impossible positions from the possible location set.



Table-Driven (or Proactive)

The nodes periodically exchange messages through a tabled list of routes to each destination in the network maintained by them. Initial delays before sending data are relatively very small as the routes to all destinations are always ready to use. There is a major demerit in this system when considering the bandwidth usage and network resources usage due to the routes that takes us to all destinations are always updated, even when they are not in use.

On-Demand (or Reactive)

This protocol is designed to overpower the demerit of the all time updated routes of the previous system. The major advantage in this system is that only when its necessary there happens the acquisition of the routing information. The overhead of maintaining unused routes is saved by calculating the needed routes on demand at each node, while on the other hand there will be a visible positive difference in the latency for sending data packets.


DSDV (Destination-Sequence Distance Vector)

Every entry in the DSDV routing table will have : an address to the end point, number of hops leading to the destination, the following hop address thereby comprising all the destinations that a node can communicate with. While there is a communication happening between the source(A) and the destination(B), it checks the routing table for the entry that contains destination address as B which takes the hop address C for it.

The packets are sent from the source (A) to C which is then forwarded by it to B. C and the other intermediate nodes works in the same way until the packet reaches B. DSDV distinguishes the old from new by assigning a number to each entry in a sequential manner thereby prevents the loops thereof.

Routing information from DSDV are transferred using packets of two types namely full dump and incremental packet. The former is used to exchange the complete information each DSDV holds when they meet for the first time. From then on, they reduce the packet size by making use of the incremental packets to make notice of the changes made in the routing table. All the nodes in DSDV alters the routing information with time to time if new routes are found. For instance, if two routes are discovered, the one with larger sequence number or smaller hop count to destination in case of similar sequence numbered routes will be selected. DSDV has advantages of simple routing table format, simple routing operation and guarantee loop-freedom with the disadvantages being (i) overhead caused by periodical update (ii) waste of resource for finding all possible routes between each pair.

Advantages of DSDV:

simple routing table format.

simple routing operation and guarantee loop-freedom

Disadvantages of DSDV:

overhead caused by periodical update

resource wastage in finding routes as many as possible among each pair where only one route is used.


On-demand Routing Protocols

Routing information in on-demand trend is only created for destinations that are requested and Links are also monitored using periodical Hello messages. The source rediscovers the path in case of broken link in the path. Though on-demand strategy usually causes low overhead and are easily scalable, there will be more delay since the path is not ready always.

The following part talks about the AODV, DSR, TORA and ABR as characteristic protocols of on-demand trend.

AODV Routing

AODV stands for Ad hoc on demand distance vector routing (AODV) - a combination of DSDV and DSR. In AODV,

Each node maintains a routing table containing:

Active neighbor list: a list of neighboring nodes which makes active usage of this route entry. An immediate intimation is given to the neighbor node as and when the link is broken.

Destination address

Next-hop address in the way to the destination

Number of hops leading to the destination

Sequence number: for choosing route and prevent loop

Lifetime: time when that entry expires

There are two phases in AODV routing: Route Discovery and Route Maintenance. The routing table is referred, as and when there is a requirement to communicate with a destination. If the destination is seen, node sends the data in the similar way as in DSDV; else it begins the Route Discovery mechanism: Source node relays the Route Request packet to its neighbor nodes, which again rebroadcasts the broadcasted request to their neighbor nodes until a possible way to the destination is found. When RREQ is received by the intermediate node, the route to previous node is updated by the intermediate node and checks for: (i) a found entry which has a same destination with RREQ (ii) its sequence number is higher or equal to the same of RREQ. Else, it starts rebroadcasting RREQ. If found true, a RREP message is again sent to the source node and if RREP is routed back, the respective routing table is updated with the added next hop information by the node in the reverse path. If there is a receipt of similar RREQ as received before (checked by the sequence number) by the node, it leaves out the RREQ for preventing loop. If multiple RREP are received by the source node, one with greater sequence number is always selected. If multiple RREPs bear the same sequence number, the one with lower sum of hops to destination is chosen. Route Maintenance mechanism functions as the maintenance system of the route if found: Hello packets are sent periodically by each node to its neighbors to prove the availability. If a Hello packet is not received from a node in an interval, it is understood that link to particular node is broken. When a node does not receive any Hello messages, it will then nullify all of its related routes to the failed node and informs other neighbor using this node by Route Error packet. Route Discovery will have to be restarted if the source still needs to transmit the data to the destination in order to select a new path. AODV has many advantages and they are reducing the overhead control messages, low processing, quick adaptation to network topology change, highly scalable up to 10000 mobile nodes. Yet, there are disadvantages that AODV accepts only bi-directional links and there is noticeable time delay if a route has to be started, which in turn repairs the broken link.


DSR is a reactive routing protocol which has the capability of managing a MANET without the help of periodic table update messages unlike other table-driven routing protocols. The special and specific design of DSR is highly useful and desirable in multi-hop wireless ad hoc networks. The network is made self-organized and self-configured with the help of Ad-hoc protocol, which is done by avoiding the necessity for an already existing network administration or infrastructure.

The procedure to find a path is carried only when there is a necessity for it thereby restricting the bandwidth following the On-Demand Routing. Here, the sender is called as the source initiator and the path from the source to the destination node is called the source routing. The sender (source, initiator) determines the complete path from the source node to the destination node (Source Routing) and stores the address information of the intermediate nodes of the route within the packets.

In comparison, DSR is beacon-less than the other reactive routing protocols like ABR or SSA, which indicated that there are no hello-messages between the nodes to show or inform their presence to the other neighboring nodes.

DSR designed for MANETs have a negligible diameter somewhere between 5 and 10 hops which in turn constrains the nodes from moving at a higher speed, meaning they are forced to move in a moderate speed. The spine of DSR is Link-State-Algorithms that is each node is capable of storing the optimum way to the end destination. Also, if there happens an alteration in the network topology, this information is spread to the whole network by flooding.

DSR contains 2 phases

Route Discovery (finding a path)

Route Maintenance (maintaining a path)

Route Discovery

If there is a route from node A route cache to the destination E, this route is immediately used. Else the Route Discovery protocol is started:

The initiator, Node floods the network for a Route Request by sending Route Request packets.

If the same request is received before from the same target or is the address is already listed in the Route Record the node B discards the request.

A Route Reply is sent to the initiator if node B is found to be the target of the Route Discovery. The Route Reply will contain the information of the optimum path stating from the initiator leading to the target. if this Route Reply is received by the initiator, it stores this concerned route in its Route Cache to be used later while sending subsequent packets to this destination.

If node B is found not to be the actual target, it then send this Route Request to all of its neighboring nodes (with exception to the initiator).

Path-finding-process: Route Request & Route Reply

Route Maintenance

In DSR every node functions in a perfect manner by confirming the receipt of packets by all the nearest hops in the Source Route and that each and every packet is sent just once by a node (hop-by-hop routing). If a node cannot receive a packet, it is then resent up taking maximum attempts until receipt of confirmation from the following hop in the sequence, meaning the next hop.

A Route Error message is sent to the initiator if there is a failure in the retransmission. The Source Route then removes the same from its Route Cache. Therefore, the initiator will have the ability to check its Route Cache if there are any another possible route leading to the target. If the cache does not have any route of that sort, a Route Request is then broadcasted

if node D doesn't acknowledge, the node C will return a Route Error to the initiator A but after many number of requests.

the broken-link-route in the cache is deleted immediately after the receipt of the Route Error message. If A has some other route to E, the packets are sent immediately using the new route.

Otherwise. If everything is a failure, then the initiator A restarts the Route Discovery process.


Unlike other table-driven routing protocols the Reactive routing protocols does not have the necessity to occupy the network periodically to alter the routing table values. Control overhead is reduced by the efficient use of information in the Route cache by the intermediate nodes. The initiator finds the route only when there are no known route in the cache, which results in zero hello messages, which saves noticeable current and bandwidth.


A broken link is communicated only to the initiator, therefore the Route Maintenance protocol does not locally repair them. The major demerit of DSR protocol is that it is efficient in MANETs with less than 200 nodes. Collusions are created between the packets by the flooding of network; hence there is a condition for the nodes to move in a moderate speed. Another drawback is that, always there will be a small time delay at the beginning of every new connection as the initiator spends time finding the route to the target, which then paves the way for the rest.

2.2.3. TORA (Temporary Ordered Routing Algorithm)

TORA is based on the link reversal algorithm and that each node in TORA constructs and holds along a table carrying the distance and status values of all of the available links. Detail information can be seen at [38]. TORA has three routing mechanisms:

Route Creation: TORA uses the concept of "height'' to discover multiple routes to a destination. TORA network follows a downstream Communication that is from higher to lower node. When there is no route to destination, source node starts Route Creation by broadcasting the Query messages (QRY). QRY is continually broadcasted until it reaches the destination or intermediate node that has the route to the destination. A Update (UPD) message containing the height information will be broadcasted by the reached node. a larger height for itself than the height in UPD will be set the node that receives this UPD, and then broadcasts the same. This is called reversal algorithm and is found to create number of direct links from the originator to the destination.

Route Maintenance: If there is a broken link and it is discovered, nodes make a new reference height and broadcast it to their neighbors. Thereby all the nodes in the link will change their reference height and Route Creation is done to reflect the change.

Route Erasure: The invalid routes are erased by flooding the "clear packet" through the network.

The advantages of TORA are: The multiple paths to destination decreases the creation of route in link broken case therefore decreases the overhead and the time delay to the network. TORA is also found to be very effective on large and mildly congested network [9].

The drawbacks include, requiring node synchronization due to "height" metric and potential for oscillation. Besides that, TORA may not guarantee to find all the routes for reservation in some cases.




This system was developed with IBM compatible personal computer with Pentium IV processor.

Main processor : Pentium IV processor 1.13 GHz or higher

HDD Capacity : 40GB

Cache memory : 512 MB

Monitor : LG Digital Color Monitor

Keyboard : Samsung

Mouse : Logitech


Operating system : Fedora 8 (linux)

Scripting language : Network Simulator 2.33

Protocol developed : C++

Scripting : Tool Command Language



Network Simulator (NS2) is a part of the VINT project and a discrete event driven simulator developed at UC Berkeley. NS2 is developed as a collaborative environment and the major aim of NS2 is supporting networking education and research. It's a freeware and available as an open source in many institutes where people indulging in development and research make good use of it and thereby maintain and develop NS2. It mainly helps in development and design of new protocol and also used when different protocols are compared to bring out traffic evaluation report. It is available in many versions compatible with almost all Operating systems. To name some of it: Mac OS X, various derivatives of Linux, Windows and Solaris


NS2 is built using object oriented methods in C++ and OTcl (object oriented variant of Tcl.

Fig 5.1 Simplified User's View of Ns

As shown in Fig 5.1, the simulation scripts written in OTcl are interpreted by NS2. The simulation environment mainly consists of three components, namely setup module libraries, network components libraries and event scheduler objects.

The simulation is coded as an OTcl script and the network components are compiled together to setup and complete the simulation. When there arises a necessity for new network components, they can be implemented free of cost and brought to the viewers' simulation also. The other major component besides network components is the event scheduler, which is responsible for triggering events of the simulation like sending packets, starting and stopping tracing process. Few parts of NS2 are coded in C++ as its proven to be efficient. The control path which is in OTcl is treated separate from the data path which is in C++. The compiled Data path object is then sent to the OTcl interpreter through an OTcl linkage (tclcl) which maps methods and member variables of the C++ object to methods and variables of the linked OTcl object. OTcl objects controls the C++ objects. Hence it has been made possible to add methods and member variables to a C++ linked OTcl object.


Network Stimulator 2 (NS2)facilitate various functionalities for wired and wireless networks. It enables tracing and visualization also.

• The wired world supportable include

- Routing DV, LS, and PIM-SM.

- Transport protocols: TCP and UDP for unicast and SRM for multicast.

- Traffic sources: web, ftp, telnet, cbr (constant bit rate), stochastic, real audio.

- Different types of Queues: drop-tail, RED, FQ, SFQ, DRR.

- Quality of Service: Integrated Services and Differentiated Services.

- Emulation.

• The wireless world supportable include

- Ad hoc routing with different protocols, e.g. AODV, DSR, DSDV, TORA

- Wired-cum-wireless networks

- Mobile IP

- Directed diffusion

- Satellite

- Senso-MAC

- Multiple propagation models (Free space, two-ray ground, shadowing)

- Energy models

• Tracing

• Visualization

- Network Animator (NAM)

- Trace Graph

• Utilities

- Mobile Movement Generator

Fig 5.2 OTcl and C++: the duality MOBILE NETWORKING IN NS2.33

This section is about the wireless model. An adaptation of CMU's Monarch group's mobility .The first section deals with the original mobility model ported from CMU/Monarch group. This section covers the internals of a mobile node, various mechanisms in the routing process and network components that are part of the construction of a network stack for a mobile node. The components covered in this chapter are MAC Protocols, Address resolution protocol model (ARP). And this chapter talks fairly about Networks interfaces and Channels. This section also covers CMU trace support and Generation of node movement and traffic scenario files. Pure wireless LANs or multihop ad-hoc networks are simulated by the original CMU model. Combined simulations of wired and wireless networks are also made possible by making few more extensions which has made the MobileIP to be extended to the wireless model. THE BASIC WIRELESS MODEL IN NS

The Mobile Node is at the core of the wireless model. It facilitates added features, which supports and allows simulation of multi-hop ad-hoc networks, WLANs and more. The Mobile Node has a split object. The C++ class Mobile Node is derived from the parent node that makes it the basic Node object with added features of a mobile node which enables it move within a given topology, transmit signals with wireless channels. A notable difference between them is that mobile nodes are never connected using links. The other topics covered in this section are routing mechanism, their protocols like DSDV, AODV, TORA and DSR, process of creating network stack allowing channel access in them, detailed information about each component forming the stack, trace support and motion scenario generation for wireless simulations. MOBILE NODE: CREATING WIRELESS TOPOLOGY

Mobile Node is the basic nsNode object with additional functionalities which includes movement, ability to transmit and receive on a channel that makes it ready to be used for creating mobile, wireless simulation environments. The Mobile Node is a split object that is derived from the base class Node and the mobility features involve node movement, periodic position updates, maintaining topology boundary are implemented in C++ while plumbing of network components within Mobile Node (as like classifiers, dmux , LL, Mac, Channel etc) have been implemented in Otcl.

Table 5.1: Available Options for Node Configuration


Available Values



Address type

Flat, Hierarchical





Both Satellite and Wireless Oriented

Wired Routing



II Type



Mac Type

Mac/802_11,Mac/Csma/Ca, Mac/Sat/Unslotted/Aloha,Mac/Tdma


ifq Type

Queue/DropTail, Queue/Droptail/PriQueue


Phy Type




Available Values


Satellite Oriented





<bandwidth value, e.g "2MB">


Wireless Oriented

Adhoc Routing





Propagation/2RayGround,Propagation Shadowing



Propagation/2RayGround,Propagation Shadowing



Antenna/Omni Antenna



Channel/Wireless Channel,Channel/sat



<toplogy file>





Energy model

Energy model


Initial Energy

<value in joules>



<value in W>



<value in W>


Idle Power

<value in W>

























The average location of valid samples is used to calculate the location of a normal node. The location thus estimated will be close to its actual position if the valid samples are near to the actual position of the normal node. In this proposed MCL (IMCL) localization scheme, it comprise three constraints including anchor constraint, neighbor constraint, and moving direction constraint to confine the region of the valid samples near the actual position of the normal nodes. The assumptions made in this scheme are similar to that of MCL: time is discrete. Anchor nodes are a type of sensors that have knowledge about their locations in every time slot.

Anchor nodes informs their respective physical point of locations using which the other nodes estimate their own location, but the same happens only after collecting information from the other neighbouring nodes. Vmax refers to the maximum value of moving distance attribute of all nodes during a particular time slot and which will not exceed the same. R refers to the range of communication (fixed) of all the sensors.

The proposed IMCL constitutes three phases:

Sample selection

This phase involves the process of finding the sum of samples by each normal node by using the information from anchors regarding their respective location. Following which the selection process is done, where the possible location set is identified and chosen

Neighbor constraint exchange phase

This phase involves the broadcasting process, where all determined possible located region by all normal nodes are broadcasted to their respective neighboring node.

Refinement Phase

In this phase, the refinement of samples takes place, here the localization error is brought down by refining the samples by their respective neighbor constraint and direction of motion constraint.

And finally the location estimation is done by calculating the average of the location of the samples found in the location set. A detailed description about all the three phases is given below

4.1 Sample Selection Phase

Here, samples are selected by the normal nodes to represent its possible located positions by making use of the information of the locations of neighboring anchor nodes. circle with radius Vmax as center on each sample in the last time slot is used to select the samples.

The selected samples are then placed in the sampling region in a particular way such that the sampling points satisfy the anchors constraints that are near and far from it as shown in Fig. 1. A sampling point satisfying near anchor constraint implies that the point is located within the intersection region of near anchors. A sampling point satisfying farther anchor constraint implies that the point is within 2R communication range but is not in R communication range of the farther anchor. For instance, as we can see in the given Fig. 2 the valid samples which satisfy both anchor constraints (near and far) are the small triangles.

The samples are filtered out from the valid sample list to denote the possible positions of a normal node. Imagine, when there are more anchor constraints, the sampling area is shrunk to smaller size resulting in minimizing the distance between chosen samples. Considering a greater quantity of samples it becomes impossible to increase localization accuracy and the process ends up wasting memory space and noticeable cost of computation. Hence in IMCL, using the dynamical adjustment technique, a value directly proportional to the area of the sampling region is fixed as number of samples.

Figure 1. Example of ER

Generally the physical position of the anchor nodes are intimated by themselves to their neighboring one-hop nodes which is again sent to the next neighboring two-hop nodes. Each node will then decide on the number of sample based on the sampling region's size after gathering packets from anchors both near and far. Its usually uneasy figure out the resource-limited sensors as the sampling region is irregularly shaped. To overcome this difficulty, a rectangle is considered to calculate the number of samples, meaning the calculation is made using a rectangle encapsulating this sampling region named as ER and this ER is used in the place of actual or exact sampling region. The Node B makes sure that the legal node A only upon receipt of a legal authentication transmits the one-hop packet. The time stamp satisfies the need for time synchronization.

Usually the normal nodes make use of squares with edge length values 2R and 4R surrounding anchor nodes near and far. ER is the region overlapping this square region, this is clearly shown in fig. 1. Assuming that anchors A1, A2 (near anchors) and A3(far anchor) serves sensor N with packets, the sensor N locates the intersection area of A1 A2 and A3 in the region ER. The border values are considered to calculate the boundary value of region ER.

ER does not reveal the sampling region's shape, but it show the variations in the area of possible sampling regions.

k being the number of samples based on the area of ER, the same can be formulated as

k = [Max_ Num x (ER Area / ER Threshold)]

where ER Area - the area of ER

ER Threshold - the threshold value

Max_Num - the number of maximum samples

which is then calculated by normal nodes. K is set to Max_Num when ER Area >= ER Threshold to avoid the excess in the number of samples. In most situations every normal node will receive a near anchor constraint at least. ER Threshold is given value 4R2 which is the same as the area of ER encapsulated by a single neighboring anchor constraint. The number of samples are first calculated, after which each normal node tends to choose and carry k valid samples which are randomly generated from region having radius value Vmax. centered on samples found in the previous time slot and also found in the sampling region.

Figure. 2. The sample filtering procedure in the first time slot.

The final time slot of a normal node will have no normal node, the possible way to choose the first set is doing it by random selection process, choosing k samples for the region ER. Here an effective method is used where the area of region ER is equally divided into grids by normal nodes. The grids' length is fixed at 0:25 R, R being the radius of the communication range where the center points are considered to be the initial samples as in Fig 2. Then comes the verification process where the grids are scanned for its center point and checked if it can satisfy the anchor constraints near and far.

4.2 Neighbor Constraint Exchange Phase

Every normal node in the existing MCL, uses only constraints that aroused from anchor nodes which was proven to be weak when anchor density is low. When the anchors' information is found to be null or if its not known, normal nodes tends to estimate their respective position using samples chosen from recent previous time slot, and there will be a noticeable increase in localization error until the anchor nodes send the new location information to it. Here, in the proposed IMCL the normal nodes solely depends on the constraints that aroused from the anchor nodes and normal nodes in the nearby locations which in turn increases the accuracy in the localization value. Another problem is that the normal node has to locate itself within the communication range of the normal nodes near it. Moreover, the position of the normal node is found from the positional values of the nodes nearby, but there would definitely be a deviation in the values between the calculated and the actual position. The error in localization value tends to increase if the calculated values are directly used.

Fig. 3. The overlapping region centered on N1 and N2 versus the

overlapping region centered on EN1 and EN2.

As shown in fig 3. It is assumed that the calculated locations of the two neighboring normal nodes N1 and N2 are EN1 and EN2 respectively. It can be taken for granted the N3 will be positioned in the region overlapping the two circles centered on nodes N1 and N2. N3 will be taken as overlapping region of the two circles when EN1 and EN2 becomes the actual positions of N1 and N2. But there would be a variation in the overlapping region of N1 and N2 from the same of EN1 and EN2. Every normal node will transmit their own location instead of the calculated region to its neighbors, thereby reducing the error in localization formed from the nearby normal nodes.

4.3 Refinement phase

Refinement phase is defined as the phase where a node "refines samples selected in the sample selection phase". The constraints filter all the impossible samples, Including the received neighbour constraint which delivered from the normal neighbouring nodes and direction constraints attained by the predicted by the direction of the normal node. To maintain proper Valid number of samples, if any one sample does not meet the requirements then a normal node will replace it in order to validate. once received neighbour constraint a normal node check will be done to check whether it satisfied neighbour node or not.

Example as shown in the following figure;

In the following diagram, here N1 received two neighbour constraints from N2 and N3 and they are located at CN2 and CN3 approximately. Consider that S1 and S2 were the samples of node N1 which is select in the selection phase. Here if S1 is valid for the recipient N2 and N3.If S2 is invalid then it cannot not satisfy and hence new sample would be sent to replace S2.

Figure. 4. Sample refinement with neighbor constraint.

Figure. 5. The moving constraint formed with the estimated locations in

previous time slots t - 1 and t - 2.

The node in motion gets displaced from its tracks which results in noticeable deviation in direction in every time slot, the moving constraint can be used only if the following condition holds:

Defining Ct as the central point - calculated in exchange phase in time slot t. If Ct is found in the moving constraint range, the direction of motion will be line with two of the recent time slots. The error in localization can be decreased by adopting the moving constraint in the refinement phase. In Fig 5, if the central point Ct of a normal node is found in CNa, the moving constraint is adopted. On the other hand if the same is found in CNb, moving constraint is considered. If the moving constraint is taken into consideration, all samples of the normal mode should once be checked by the moving constraint. If the moving constraint as in Fig 5 is visible, sample S1 is valid where S2 becomes invalid. If Lt does not satisfy all constraints and to maintain enough samples, each normal node will create new valid samples to replace the invalid ones and the estimated location in current time slot t can be calculated by averaging the x-axis and y-axis values of all valid samples.


In this project, the researcher had employed Network simulator 2(NS2) stimulation tool. NS stimulation tool is used because of its wide range of facilities provided by it and also due its open code source availability which can be altered and extended. There are various Network Stimulator version available and the most up to date version is ns-2.1b9a while ns-2.1b10 is under study and development in this study.


Network simulator (NS) is an event stimulator targeted at networking research. Network stimulator delivers significant support to wireless and wired networks for the stimulation of TCP, routing and multicast protocols. Network stimulator is developed with the continuous help of the research and development. However, network stimulator had raised a considerable confidence but still there are some conflicts within it and they have been pointed out regularly and sorted out by the research and development.

Network stimulator is developed in C++ and there is an integration of OTcl1 interpreter which acts as a command and configuration interface. The C++ platform helps in detailed protocol implementation, which is faster to run but slower in change and on the side OTcl1 runs slowly and it can be changed much quickly, which is employed in stimulation configuration. Configuration using the split language program has the following advantage and disadvantage. The advantage is it permits faster generation of large scenarios. OTcl helps to simplify the usage of stimulator and the disadvantages is debugging in both languages while the stimulator is modified and extended.

NS helps in simulating the following:

1. Topology: Wired, wireless

2. Scheduling Algorithms: RED, Drop Tail,

3. Transport Protocols: TCP, UDP

4. Routing: Static and dynamic routing

5. Application: FTP, HTTP, Telnet, Traffic generators


Simulation -

OTcl Script

OTcl Interpreter

Simulation Results

C++ Libraries

Figure 5.1 Block diagram of Architecture of NS-2


This section describes about the components of NS, basically the compound network components. The illustration depicts a partial OTcl class hierarchy of NS that assists in the understanding of basic network components.

Figure 5.2 OTcl Class Hierarchy TclObject class is the root of the hierarchy

The OTcl class hierarchy initiates from the Tcl object and it is in the super class position of all the OTcl library objects such as timers, scheduler, network components and all other objects including objects related to name NAM. TclObject is the superior class basic networking objects which handle packets and also compose compound objects such as nodes and links. After the Ns Object it is further alienated to two sub class viz connector & Classifier, depends on the possible designed output paths. Connector class comprise objects that have only one output DATA path, and Classifier class comprises switching objects that have possible multiple output DATA paths.


TCL creates the methods to access and communicate with that interpreter by encompassing the actual instance of the OTcl interpreter. Tcl deliver operational methodology for the following ;

Instantiating a TCL reference.

Calling OTcl methodologies via interpreter

Revoke or send back final results to the interpreter

Reporting an error situation and so exit in uniform programmed method.

Data storage and look up

Providing direct access to the interpreter.

5.4.1 Instantiating a TCL reference.

For example: If a single Tcl instance class is declared in -tclcl/Tcl.cc is a static member variable and in this statement needed to access this instance is Tel& tel = Tcl::instance();

5.4.2 Calling OTcl Procedures:

There are four different methods to invoke an OTcl command via instance and according to the calling arguments the difference can be noted.

Here Each and every single command will deliver a string to interpreter and then the evaluation should be done by the interpreter in a global context.

If TCL_OK is the result, these methods will return to the caller. Else IF the interpreter sends back TCL_ Error, this methodology would be called as tkerror{}. Then the user could overload this method in order to disregard some types of errors selectively.

Sending results from/to the interpreter; If the interpreter calls a C++ method, then it would expect the result back in the private member variable, tcl-> result.

Error reporting and Exit: In this methodology errors will be reported in the complied code in an uniform determined way.


NS will establish the instance procedure, cmd{} for each and every Tcl object that is to be created and it acts as a hook to excecute methodology via compiled shadow object. The procedure cmd{} automatically call upon the method command{} of the shadow object, sending the function variables to cmd{} as an variable function vector for the command() methodology. The user could able to call upon the cmd{} methodology in two ways. There are as follows by clearly calling upon procedure, commanding the desired operations in first argument. In latter form more stimulation scripts may be employed.

In case of SRM - distance computation it can be one by compiled object and is frequently employed by the interpreted object. It will be normally called as $srm Object distance? (agent address) If there is no instance procedure invoke distance? The interpreter would call upon instane procedure unknown{}, described in the base clas Tcl object. The unknown procedure will call upon

$srmObject cmd distance? (agent Address) in order to perform the operation by the compliled object's command() procedure. Then the user can clearly call upon the operation directly.The behind to perform this action it may overload operation by employimg procedure of the same name.


Agent/SRM/Adaptive instproc distance? addr {

$self instvar distanceCache_($addr)

if![info exists distanceCache_($addr)] {

set distanceCache_($addr) [$self cmd distance? $addr]


set distanceCache_($addr)


The below code snippet shows how the command() method using SRMAgent::command()

int ASRMAgent::command(int argc, const char*const*argv) {

Tcl& tcl = Tcl::instance();

if (argc == 3) {

if (strcmp(argv[1], "distance?") == 0) {

int sender = atoi(argv[2]);

SRMinfo* sp = get_state(sender);

tcl.tesultf("%f", sp->distance_);

return TCL_OK; '



return (SRMAgent::command(argc, argv));

Observation based on the above code snippet:

The above functions are argued with two arguments. The first argument(argc) denotes the arguents made in the command line to the interpreter. The command line arguments vector (argv) includes of argv[0] contains the name of the method, "cmd" and argv[1] specify the required function. If the user particular any arguments, then they are located in argv[2...(argc - 1)]. The arguments are sent as strings. They should be changed to the proper or suitable data type. If the procedure is successfully matched, the match should return the result of the operation,command () itself must return either TCL_OK or TCL_ERROR to indicate success or failure as its return code. If it paired in this method , then it should invoke its parent 's command method & send back the consequent result . This would permit the user to receive functionality by having same in heritage properties as instance or compiled method. In this case this command is distinct for class with multiple inheritances, any one implementation method can be chosen from the following ;

1. They can be call upon one of the parental document and the results of the invocation should be returned.

2. They can choose the parental command method in a number sequences and first invocation results should be returned when it is successful. Else if no command was successful then they all should returned to error.


For NS in wireless devices, it should consists of the Mobile mode in the core with added supportive functionality which permits simulations from multihop ad-hoc networks, wireless Lans etc. The mobile node objective is usually a split object. The C++ class mobile node is imitative from the original parent class node. A mobile node is a usual node with additional functionalities for mobile node and wireless within a selected topology with functionalities like transmit signals (send and receive) in order to create a wireless channel environment etc. the difference between the two nodes is mobile nodes cannot connected to any other nodes by any links.The Class mobile node is imitative of the base parental node. The four ad hoc mobile routing protocols are supported by the following Dynamic Source Routing (DSR), Temporally ordered Routing Algorithm (TORA) and Adhoc On-demand Distance Vector (AODV) .

A mobile node in ns2 is defined by using the general structure

$ns node-config -adhocRouting $opt (adhocRouting)

-IIType $opt (II)

-macType $opt (mac)

-ifqType $opt (ifq) -ifqLen $opt (ifqlen)

-antType $opt (ant)

-proplnstance [new $opt (prop) -phyType $opt (netif)

-channel [new $opt (chan)]

-topolnstance $topo

-wiredRouting OFF

-agentTrace ON

-routerTrace OFF

-macTrace OFF

All the stated API Configures with a mobile node with respective values of ad hoc-routing protocol, network stack, channel, topography, propagation model, with wired routing turned on or off (essential by wired-cum-wireless scenarios) and tracing turned on or off at various levels (router, mac, agent).


WSNs applications must combine with the sensor node locations. Many localization schemes automatically estimate sensors' positions In order to get location information. In the mobile sensor networks, it is not that easy to implement the localization scheme due to the mobility of nodes. Thus, it has become a big challenge for the mobile sensor networks to develop a simple localization scheme with low error estimation.

In this research topic ,the researcher had proposed a distributed localization scheme called IMCL and this is for the better innovation in bringing accuracy than the previous schemes. We have incorporated two more sampling constraints, the neighbour constraint and moving direction constraint to improve the localization errors than the previous schemes.

Conculusion need to be typed lastely by the candidate: